* H. Nikolaus Schaller <hns@xxxxxxxxxxxxx> [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@xxxxxxxxxxx>
