[ltp] Re: Generic battery interface

[Mark Underwood]

--- Shem Multinymous <multinymous@gmail.com> wrote:

> On 7/29/06, Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> wrote:
> > On Sat, 29 Jul 2006 01:10:40 +0300, Shem Multinymous said:
> > > On 7/28/06, Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> wrote:
> > > > Is there a reliable (or hack-worthy) way for the kernel to determine how
> > > > often the values are re-posted by the hardware?
> > >
> > > That's hardware-specific. Some drivers can know, others may just
> > > assume 1sec or 0.1sec or whatever.
> >
> > That smells suspiciously like "We need an API for the hardware-specific
> > bits f code to pass the generic bits a value for this..." (and the
> > hardware-specific part can either ask the battery, or return a
> > hard-coded "10 seconds" that somebody measured, or whatever)....
> 
> I don't think "update frequency" is a good abstraction. The hardware's
> update may not be variable and irrregular (e.g., event-based), and
> there's there's an issue of phase sync to avoid unnecessary latency.
> 
> The lazy polling approach I described in my last post to Vojtech
> ("block until there's  a new readout or N milliseconds have passed,
> whichever is later") looks like a more general, accurate and efficient
> interface.
> 

This sounds like a good idea. You could do a similar thing using sysfs by
providing a entry in sysfs which tells userland when the next update is going
to happen, the userland app can then decide to use this as it's next poll time
or not.

Mark

>   Shem
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 



		
___________________________________________________________ 
Yahoo! Photos – NEW, now offering a quality print service from just 7p a photo http://uk.photos.yahoo.com