Re: [PATCHv3] w1: omap-hdq: Simplify driver with PM runtime autosuspend

[H. Nikolaus Schaller]

Hi,

> Am 22.04.2020 um 12:04 schrieb Andreas Kemnade <andreas@xxxxxxxxxxxx>:
> 
> On Tue, 21 Apr 2020 22:40:39 +0200
> "H. Nikolaus Schaller" <hns@xxxxxxxxxxxxx> wrote:
> 
>> Hi Tony,
>> 
>>> Am 21.04.2020 um 20:20 schrieb Tony Lindgren <tony@xxxxxxxxxxx>:
>>> 
>>>> Well, what helps is reverting the patch and using the old driver
>>>> (which did work for several years). So I would not assume that
>>>> there is a hardware influence. It seems to be something the new
>>>> driver is doing differently.  
>>> 
>>> Well earlier hdq1w.c did not idle, now it does.  
>> 
>> Ah, I see!
>> 
>>> If you just want to keep it enabled like earlier, you can just add something like:  
>> 
>> Well, I don't want it enabled, it just should work as before.
>> Ideally including all improvements :)
>> 
>>> 
>>> &hdqw1w {
>>> 	ti,no-idle;
>>> };  
>> 
>> I have added that and there might be a slightly different pattern
>> (unless that is just by luck): the first two or three attempts to
>> read the bq27xx/uevent did still time out. But then the next ones
>> worked fine (with a response time of ca. 65 .. 230 ms).
>> 
>> So as if something needs to be shaken into the right position after
>> boot until it works.
>> 
> 
> What about reading battery with just omap_hdq loaded and then continue
> booting as usual, e.g. something like:
> 
> have script init-bat.sh
> #!/bin/sh
> modprobe omap_hdq
> cat /sys/class/power_supply/bq27000_battery/uevent
> exec /sbin/init "$@"
> 
> and then append to kernel parameters init=/init-bat.sh

Interesting idea. But how would it help to identify the
issue?

I can confirm that after a while of attempting to read
the uevent it suddenly starts to work.

Then I can even swap the battery (and verify by looking
at the cycle count which changes).

I have some unconfirmed impression that it helps to run
two cat /sys/class/power_supply/bq27000_battery/uevent
in quick enough succession to get it out of the hickup mode.
This needs more test.

It would indicate that if a new omap_hdq_runtime_resume()
is called by the second open+read+close sequence before
the autosuspend (300ms) of the previous omap_hdq_runtime_suspend()
happens, something gets back in place for the second
omap_hdq_runtime_suspend().

BR and thanks,
Nikolaus