drivers/w1/slaves/w1_bq27000.c

[Michael Trimarchi]

Hi all,

Lars-Peter Clausen wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Mike Westerhof wrote:
>   
>> Lars-Peter Clausen wrote:
>>     
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Michael Trimarchi wrote:
>>>
>>>       
>>>> Lars-Peter Clausen wrote:
>>>>
>>>> One wire is similar, but different from hdq, so one would at least
>>>> need an hdq gpio driver.
>>>>
>>>>   
>>>>         
>>>>> But is ok to try to use some that does't use FIQ, so somenthing
>>>>> like a gpio bitbang master?
>>>>>      
>>>>>           
>>> Sure. I would be happy if we could do it without using FIQ.
>>>  
>>>       
>> I expect everyone would - so it worries me a bit that the original
>> implementation was not done with simple gpio bitbanging.  It might
>> not be a bad idea to ping Andy to understand why he didn't choose
>> 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.
>
> A one looks like this
>            ______________
>  \_____/
> 0       1-50            190 ms
>
> And a zero looks like this
>                         ______
>  \_____________/
> 0                 86-145  190 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)
>     }
> }
>
>
> 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 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
>
>   
I have done these things:

create a new w1-gpio-hdq.c file to put the scan read write reset function
add to the bq27x000 the w1 registration as other possibility
create and register the platform data for the gta02

All seems to work expet the bitabng function that I will complete in 
next days.

Is ok for you?

Michael