[RFC PATCH] bq27000_battery. Retains old value in ETIME error

[Joerg Reisenweber]

[Werner Almesberger Do  10. September 2009]:
> Michael Trimarchi wrote:
> > >Is there some explanation on why these timeouts happen and how long
> > >they can last?
> > I can't answer to theese question because I have no idea of the
> > hardware.
> 
> I think there are two questions:
> 
> - did you observe just isolated timeouts, or do they come in large
>   bursts ?
> 
> - can we imagine a scenario where you would get a lot of timeouts in
>   a row ?
> 
> You also mentioned on IRC that, sometimes, HDQ just reads back an
> invalid value, so you have to do a plausibility check, discard the
> bad value, and try again (or complain).
> 
> All this seems to point in the direction of needing a filter complex
> enough to justify a little user space library. Particularly the
> decision of what constitutes a plausible value isn't one the kernel
> should be asked to make.
> 
> Do we have some sort of library for such things already ? There are
> many things that are better done in user space than in the kernel,
> so it would be good to have a default location for them. In the
> absence of such a library, people will just pick the next best
> "default location" and try to put all the device-specific hacks
> into the kernel.
> 
> The API would then be a C function, not a sysfs file. It would be
> extra-nice to also have some simple command-line wrapper that
> comes with the library that would also let scripts and such easily
> benefit from the library.
> 
> With the filtering in the library, the kernel could just return an
> error if it detects a problem, and leave the proper policy (i.e.,
> keep the old value, extrapolate, pass the error to the application,
> etc.) to the library.
> 
> - Werner
> 
> 

As explained ad nauseum on irc and prev mails, system must not rely on CC 
readings. I.e. if system decides to shutdown based on a CC value, that is 
considered a wrong implementation.

I never seen long bursts of consecutive erroneous CC readouts. So probably a 
simple read-out-twice scheme would fix the issue.

E.g. by running vibrator (which is controlled by FIQ as well) on low power you 
can observe periodic glitches that can only be caused by irregularities if 
FIQ itself IMHO. Of course such glitches would cause a CC readout to fail. So 
instead of implementing sophisticated libs I recommend to check FIQ mechanism 
to eliminate those glitches.

cheers
jOERG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.openmoko.org/pipermail/openmoko-kernel/attachments/20090922/c9f091b0/attachment.pgp