* H. Nikolaus Schaller hns@goldelico.com [200523 17:34]:
Since
commit 27d13da8782a ("w1: omap-hdq: Simplify driver with PM runtime autosuspend")
was applied,
I did see timeouts and wrong values when reading a bq27000 connected to hdq of the omap3. This occurred mainly after boot but remained and only sometimes settled down after several reads.
root@letux:~# time cat /sys/class/power_supply/bq27000-battery/uevent POWER_SUPPLY_NAME=bq27000-battery POWER_SUPPLY_STATUS=Discharging POWER_SUPPLY_PRESENT=1 POWER_SUPPLY_VOLTAGE_NOW=0 POWER_SUPPLY_CURRENT_NOW=0 POWER_SUPPLY_CAPACITY=0 POWER_SUPPLY_CAPACITY_LEVEL=Normal POWER_SUPPLY_TEMP=-2731 POWER_SUPPLY_TIME_TO_EMPTY_NOW=0 POWER_SUPPLY_TIME_TO_EMPTY_AVG=0 POWER_SUPPLY_TIME_TO_FULL_NOW=0 POWER_SUPPLY_TECHNOLOGY=Li-ion POWER_SUPPLY_CHARGE_FULL=0 POWER_SUPPLY_CHARGE_NOW=0 POWER_SUPPLY_CHARGE_FULL_DESIGN=0 POWER_SUPPLY_CYCLE_COUNT=0 POWER_SUPPLY_ENERGY_NOW=0 POWER_SUPPLY_POWER_AVG=0 POWER_SUPPLY_HEALTH=Good POWER_SUPPLY_MANUFACTURER=Texas Instruments
real 0m15.761s user 0m0.001s sys 0m0.025s root@letux:~#
Sometimes the effect did disappear after accessing the device multiple times, speed went up and results became correct.
All this indicates that some interrupts from the hdq controller are lost by the driver.
Enabling debugging revealed that there were spurious tx and rx timeouts, i.e. the driver does not always recognise interrupts. The main problem is that rx and tx interrupts share a single variable which was sometimes reset to 0 wiping out other interrupts. And it was overwritten by a second interrupt, independent of whether the previous interrupt was already processed or not.
This patch improves interrupt handling to avoid such races and loss of interrupt flags.
Good to hear you got it figured out :) Looks OK to me:
Acked-by: Tony Lindgren tony@atomide.com