drivers/w1/slaves/w1_bq27000.c

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

drivers/w1/slaves/w1_bq27000.c

Michael Trimarchi-3
Hi,

instead using the FIQ part we can try to use the w1_bq27000 one wire
protocol for 2.6.3x.

What do you think about?

Michael

Reply | Threaded
Open this post in threaded view
|

Re: drivers/w1/slaves/w1_bq27000.c

Lars-Peter Clausen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Trimarchi wrote:
> Hi,
>
> instead using the FIQ part we can try to use the w1_bq27000 one
> wire protocol for 2.6.3x.
>
> What do you think about?
>
> Michael
Well, we still need a one wire master. Which would probably be FIQ based.

- - Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkrum2QACgkQBX4mSR26RiM95ACcCLAjy13PSJgRDnh4T30sG6o+
VP8AmgNAvgo90tUiJQHT7d4eM8JhenRD
=M4Rf
-----END PGP SIGNATURE-----


Reply | Threaded
Open this post in threaded view
|

Re: drivers/w1/slaves/w1_bq27000.c

Michael Trimarchi-3
Lars-Peter Clausen wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Michael Trimarchi wrote:
>  
>> Hi,
>>
>> instead using the FIQ part we can try to use the w1_bq27000 one
>> wire protocol for 2.6.3x.
>>
>> What do you think about?
>>
>> Michael
>>    
> Well, we still need a one wire master. Which would probably be FIQ based.
>  
The gpio based is not ok or it's too slow?

Michel

> - - Lars
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkrum2QACgkQBX4mSR26RiM95ACcCLAjy13PSJgRDnh4T30sG6o+
> VP8AmgNAvgo90tUiJQHT7d4eM8JhenRD
> =M4Rf
> -----END PGP SIGNATURE-----
>
>
>  


Reply | Threaded
Open this post in threaded view
|

Re: drivers/w1/slaves/w1_bq27000.c

Michael Trimarchi-3
In reply to this post by Lars-Peter Clausen
Lars-Peter Clausen wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Michael Trimarchi wrote:
>  
>> Hi,
>>
>> instead using the FIQ part we can try to use the w1_bq27000 one
>> wire protocol for 2.6.3x.
>>
>> What do you think about?
>>
>> Michael
>>    
> Well, we still need a one wire master. Which would probably be FIQ based.
>  
I just rebased your tree on latest linux kernel and personally I will
try to use:
the w1 bitbang based. I need all the feuture of the latest kernel to try
to reuse
new pm framework
Michael

> - - Lars
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkrum2QACgkQBX4mSR26RiM95ACcCLAjy13PSJgRDnh4T30sG6o+
> VP8AmgNAvgo90tUiJQHT7d4eM8JhenRD
> =M4Rf
> -----END PGP SIGNATURE-----
>
>
>  


Reply | Threaded
Open this post in threaded view
|

Re: drivers/w1/slaves/w1_bq27000.c

Lars-Peter Clausen
In reply to this post by Michael Trimarchi-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Trimarchi wrote:

> Lars-Peter Clausen wrote: Michael Trimarchi wrote:
>
>>>> Hi,
>>>>
>>>> instead using the FIQ part we can try to use the w1_bq27000
>>>> one wire protocol for 2.6.3x.
>>>>
>>>> What do you think about?
>>>>
>>>> Michael
>>>>
> Well, we still need a one wire master. Which would probably be FIQ
> based.
>
>> The gpio based is not ok or it's too slow?
>
>> Michel
> - Lars
One wire is similar, but different from hdq, so one would at least
need an hdq gpio driver.

- - Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkruoUEACgkQBX4mSR26RiPapQCbBSBJUZunYZnA2mPZ8XNAkM2e
mQsAnj+G1G+WmuGYgmWN2Op/qk1kVBLN
=Kf/z
-----END PGP SIGNATURE-----


Reply | Threaded
Open this post in threaded view
|

Re: drivers/w1/slaves/w1_bq27000.c

Michael Trimarchi-3
Lars-Peter Clausen wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Michael Trimarchi wrote:
>  
>> Lars-Peter Clausen wrote: Michael Trimarchi wrote:
>>
>>    
>>>>> Hi,
>>>>>
>>>>> instead using the FIQ part we can try to use the w1_bq27000
>>>>> one wire protocol for 2.6.3x.
>>>>>
>>>>> What do you think about?
>>>>>
>>>>> Michael
>>>>>
>>>>>          
>> Well, we still need a one wire master. Which would probably be FIQ
>> based.
>>
>>    
>>> The gpio based is not ok or it's too slow?
>>>      
>>> Michel
>>>      
>> - Lars
>>    
> 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?

> - - Lars
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkruoUEACgkQBX4mSR26RiPapQCbBSBJUZunYZnA2mPZ8XNAkM2e
> mQsAnj+G1G+WmuGYgmWN2Op/qk1kVBLN
> =Kf/z
> -----END PGP SIGNATURE-----
>
>
>  


Reply | Threaded
Open this post in threaded view
|

Re: drivers/w1/slaves/w1_bq27000.c

Lars-Peter Clausen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Trimarchi wrote:

> Lars-Peter Clausen wrote: Michael Trimarchi wrote:
>
>>>> Lars-Peter Clausen wrote: Michael Trimarchi wrote:
>>>>
>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> instead using the FIQ part we can try to use the
>>>>>>> w1_bq27000 one wire protocol for 2.6.3x.
>>>>>>>
>>>>>>> What do you think about?
>>>>>>>
>>>>>>> Michael
>>>>>>>
>>>>>>>
>>>> Well, we still need a one wire master. Which would probably
>>>> be FIQ based.
>>>>
>>>>
>>>>> The gpio based is not ok or it's too slow? Michel
>>>>>
>>>> - Lars
>>>>
> 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.


- - Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkruowsACgkQBX4mSR26RiNfvgCeOROugNnrkZs2lr3FHEwKszfc
2xIAn1USDqBSK7WyhoCjMW6oJjD/S23j
=0KgY
-----END PGP SIGNATURE-----


Reply | Threaded
Open this post in threaded view
|

Re: drivers/w1/slaves/w1_bq27000.c

Mike Westerhof (mwester)
Lars-Peter Clausen wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Michael Trimarchi wrote:
>  
>> Lars-Peter Clausen wrote: Michael Trimarchi wrote:
>>
>>    
>>>>> Lars-Peter Clausen wrote: Michael Trimarchi wrote:
>>>>>
>>>>>
>>>>>          
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> instead using the FIQ part we can try to use the
>>>>>>>> w1_bq27000 one wire protocol for 2.6.3x.
>>>>>>>>
>>>>>>>> What do you think about?
>>>>>>>>
>>>>>>>> Michael
>>>>>>>>
>>>>>>>>
>>>>>>>>                
>>>>> Well, we still need a one wire master. Which would probably
>>>>> be FIQ based.
>>>>>
>>>>>
>>>>>          
>>>>>> The gpio based is not ok or it's too slow? Michel
>>>>>>
>>>>>>            
>>>>> - Lars
>>>>>
>>>>>          
>> 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)

Reply | Threaded
Open this post in threaded view
|

Re: drivers/w1/slaves/w1_bq27000.c

Lars-Peter Clausen
-----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


<http://dict.leo.org/ende?lp=ende&p=DEdPgA&search=guarantee>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkrvDOYACgkQBX4mSR26RiMXZACeJunCrGHisMVFaVOjZhF8qKk3
gl8AnR77+GNJrXp2pu7mqzkKNn/DCi5y
=pu/J
-----END PGP SIGNATURE-----


Reply | Threaded
Open this post in threaded view
|

Re: drivers/w1/slaves/w1_bq27000.c

Michael Trimarchi-3
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



Reply | Threaded
Open this post in threaded view
|

Re: drivers/w1/slaves/w1_bq27000.c

Lars-Peter Clausen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Trimarchi wrote:

> Hi all,
>
> 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
>
Hi Michael

Any news on this?

- - Lars

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkrzLBMACgkQBX4mSR26RiP6/wCfbeOzEsJLY507HR9kThPcSGor
MVMAnjCofRIzRNGhXXqGQiV9aO54beGK
=CtPK
-----END PGP SIGNATURE-----


Reply | Threaded
Open this post in threaded view
|

Re: drivers/w1/slaves/w1_bq27000.c

Michael Trimarchi-3
Hi,

Lars-Peter Clausen wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Michael Trimarchi wrote:
>  
>> Hi all,
>>
>> 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
>>
>>    
> Hi Michael
>
> Any news on this?
>
> - - Lars
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkrzLBMACgkQBX4mSR26RiP6/wCfbeOzEsJLY507HR9kThPcSGor
> MVMAnjCofRIzRNGhXXqGQiV9aO54beGK
> =CtPK
> -----END PGP SIGNATURE-----
>
>
>  
Sorry for the long delay but I'm full of work :)

I will back soon on this issue.

Michael

Reply | Threaded
Open this post in threaded view
|

Re: drivers/w1/slaves/w1_bq27000.c

Joerg Reisenweber
In reply to this post by Lars-Peter Clausen
[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

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: drivers/w1/slaves/w1_bq27000.c

Joerg Reisenweber
[Joerg Reisenweber Mi  18. November 2009]:

> [Lars-Peter Clausen Mo  2. November 2009]:
> > 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.
> >
> Rethink, regarding above.
especially I think we shouldn't be too concerned about disabling all IRQ for
1.5 MILLIseconds
/j

signature.asc (204 bytes) Download Attachment