drivers/w1/slaves/w1_bq27000.c

[Joerg Reisenweber]

[Lars-Peter Clausen Mo  2. November 2009]:
> > the one-wire.  Perhaps the timing still requires the FIQ anyway, or
> > perhaps there's some other limitation of which we are unaware.
> > -Mike (mwester)
> Hi
> 
> hdq is is indeed a quite timing sensitive protocol.

indeed, that's been the reason we had to use FIQ


> 
> A one looks like this
>            ______________
>  \_____/
> 0       1-50            190 ms
> 
> And a zero looks like this
>                         ______
>  \_____________/
> 0                 86-145  190 ms


us, not ms!!



> 
> 
> So one would implement a write similar to
> for each bit {
>     if (bit == 1) {
>         set_pin_low()
>        udelay(20)
>        set_pin_high()
>        udelay(170)
>     } else {
>         set_pin_low()
>         udelay(100)
>         set_pin_high()
>         udelay(90)
>     }
> }


as udelay() is used here, the code isn't duplicating above error


> 
> 
> The original concern was that with irqs enabled a irq could be
> triggered in between and the irq handler would run long enough to
> screw the transmission up. On the other hand a transaction of 8 bits
> takes 1.5 s 

That'd be *really* bad. According to above, this is ms then, not seconds


> so running with irqs disabled is no option either. 
> 
> Since hdq is an asynchronous protocol it gets even more complicated
> when reading values.
> 
> So the timer based FIQ implementation of the hdq protocol was chosen
> to ensure that the timing requirements are met.
> 
> The question now is, do we have interrupt handlers which run long
> enough to screw a transmission up. At the time when the hdq driver was
> written the accelerometer driver would do spi transactions inside of
> its irq handler, but this constraint is now gone.
> 
> And even if from time to time a transaction fails because of to much
> irqs kicking in we could, in case of an error, rerun the transaction
> to compensate.
> 
> Writing a gpio bitbanging hdq master shouldn't be to much of a
> problem, so we should at least try it. If it turns out that it is not
> reliable, we still can extend it to use a FIQ.
> 
> - Lars


Rethink, regarding above.

/j
-------------- 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/20091118/92493f06/attachment.pgp