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.
Interestingly, after reinstalling the version without ti,no-idle;
it did work well on the first boot but not afterwards. Like there
is some memory surviving powerdown and battery removal... But again,
it started to work after 6 or 7 failed attempts.
If only it weren't so time-consuming to perform such tests...
>> I need more time to understand and trace this issue on what it
>> depends... It may depend on the sequence some other modules are
>> loaded and what the user-space (udevd) is doing in the meantime.
>
> Yes would be good to understand what goes wrong here before we
> apply the ti,no-idle as that will block SoC deeper idle states.
>
> Regards,
>
> Tony
BR and thanks,
Nikolaus
