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
Regards,
Andreas
