[Gta04-owner] BMP085 driver in Linux 3.12.0 (Issue #487)

Dr. H. Nikolaus Schaller hns at goldelico.com
Sat Nov 9 10:22:31 CET 2013

Hi Benjamin,

Am 08.11.2013 um 23:59 schrieb Benjamin Deering:

> On 11/08/2013 05:00 PM, Dr. H. Nikolaus Schaller wrote:
>> Hi,
>> I have seen sometimes wrong values from the BMP085 sensor, but in most times they are ok [1].
>> It may look like this:
>> root at gta04:~# while true; do echo $(cat
>> /sys/bus/i2c/devices/2-0077/pressure0_input
>> /sys/bus/i2c/devices/2-0077/temp0_input); sleep 0.5; done
>> 94294 393
>> 94299 393
>> 94293 393
>> 94292 393
>> 94289 393
>> 94293 642
>> 100710 393
>> 94293 642
>> 100710 642
>> 100707 393
>> 94296 642
>> 100711 393
>> 94292 393
>> 94285 642
>> 100701 393
> Yes, I have seen that.  I should have posted my findings to the list a while ago.
> Last year (maybe longer ago) I protected the i2c access with a mutex and noticed that I still had to increase BMP085_TEMP_CONVERSION_TIME from 5ms from the datasheet to 8ms to make it work.
> In my 3.12 build (maybe 3.11?) it stopped working again.  I set  BMP085_TEMP_CONVERSION_TIME to 18ms (a made up number) so my barometer program (http://www.jeepingben.net/barom/) would work.  I assumed that just increasing the timeout was not a good solution so I stayed quiet hoping to have time to find a better solution later.

This report is great!!! It gives me an idea what is going wrong (not a solution).

If you set the conversion time to 18 ms, this translates into 2 jiffies (6 or 8 translates into 1; data sheet says '4.5m needed'). Then it works, meaning the wait will no longer time out too early.

Now comes the bug: The jiffie timer increments with a system interrupt every 10ms and the wait loop waits until the timer is initial-timer + delta. This means it waits for the nth jiffie interrupt. Not for a time delay. And "1" means essentially: end the loop after the next timer interupt occurs.

Since 8ms delay was converted into a +1 and the wait can be ending almost immediately! Long before 8ms have passed! It may be just 5us.

If you set a delay of at least 10ms (e.g. 18), then we wait for at least two timer interrupts and we do not read ADC data too early.

This means that the whole timer code is broken, unless one operates a 1000HZ system. There it would work.

So we should wait one jiffie more than calculated, which is similar to increasing the BMP085_TEMP_CONVERSION_TIME by 10 ms on a 100HZ system.

> If increasing the delay to make it work will be accepted upstream, then I say commit it and call the issue solved.

No, because this EOC interrupt handling is an extension that *we* have done for the GTA04 (I think inherited from the 3.7 kernel).

So it is not yet upstream at all. Upstream code uses a simple mdelay() where waiting 5ms is completely ok. We try to shorten this 5ms to what the ADC really did need, but extend it if there is no EOC. This is not likely to be accepted...

This means, we must solve it differently to get a chance to get it upstream. So adding the +1 will work with EOC but will be worse than the mdelay() without.

So we should either use the interrupt (and waiting 1 jiffie more just for the case that the interrupt does not happen) but fall back to mdelay(BMP085_TEMP_CONVERSION_TIME) if there is no EOC in use. And, we can then use the original value of 5ms for BMP085_TEMP_CONVERSION_TIME.

Attached is a patch that tries to do it right. I have also applied it to our 'master' branch.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-fixed-issue-with-100HZ-jiffies-where-a-waiting-time-.patch
Type: application/octet-stream
Size: 3325 bytes
Desc: not available
URL: <http://lists.goldelico.com/pipermail/gta04-owner/attachments/20131109/3504948e/attachment-0001.obj>
-------------- next part --------------

More information about the Gta04-owner mailing list