Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCHv3] w1: omap-hdq: Simplify driver with PM runtime autosuspend
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: text/plain; charset=us-ascii
From:   "H. Nikolaus Schaller" <hns@goldelico.com>
In-Reply-To: <20200422120418.49a40c75@aktux>
Date:   Wed, 22 Apr 2020 18:06:15 +0200
Cc:     Tony Lindgren <tony@atomide.com>,
        Evgeniy Polyakov <zbr@ioremap.net>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        linux-omap <linux-omap@vger.kernel.org>,
        Adam Ford <aford173@gmail.com>,
        "Andrew F . Davis" <afd@ti.com>, Vignesh R <vigneshr@ti.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6E3A50D9-0F15-4A56-8C5E-7CDC63E8AF9F@goldelico.com>
References: <3197C3F0-DEB9-4221-AFBD-4F2A08C84C4C@goldelico.com> <20200417164340.3d9043d1@aktux> <6430AF54-849E-456B-8DB0-B4478BBDB78D@goldelico.com> <20200417150721.GL37466@atomide.com> <8E062482-5D5D-4837-9980-D6C708DD24D4@goldelico.com> <20200420150802.GR37466@atomide.com> <D1A77603-11FB-407F-B480-82C57E742C51@goldelico.com> <20200421085336.32cf8ffe@aktux> <20200421180220.GB37466@atomide.com> <70F19A6E-7B36-4873-9364-F284A14EE3A0@goldelico.com> <20200421182017.GC37466@atomide.com> <D3E40A6A-39B8-4F3F-9ABC-28EAE8D623A6@goldelico.com> <20200422120418.49a40c75@aktux>
To:     Andreas Kemnade <andreas@kemnade.info>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi,

> Am 22.04.2020 um 12:04 schrieb Andreas Kemnade <andreas@kemnade.info>:
>=20
> On Tue, 21 Apr 2020 22:40:39 +0200
> "H. Nikolaus Schaller" <hns@goldelico.com> wrote:
>=20
>> Hi Tony,
>>=20
>>> Am 21.04.2020 um 20:20 schrieb Tony Lindgren <tony@atomide.com>:
>>>=20
>>>> 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. =20
>>>=20
>>> Well earlier hdq1w.c did not idle, now it does. =20
>>=20
>> Ah, I see!
>>=20
>>> If you just want to keep it enabled like earlier, you can just add =
something like: =20
>>=20
>> Well, I don't want it enabled, it just should work as before.
>> Ideally including all improvements :)
>>=20
>>>=20
>>> &hdqw1w {
>>> 	ti,no-idle;
>>> }; =20
>>=20
>> 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).
>>=20
>> So as if something needs to be shaken into the right position after
>> boot until it works.
>>=20
>=20
> What about reading battery with just omap_hdq loaded and then continue
> booting as usual, e.g. something like:
>=20
> have script init-bat.sh
> #!/bin/sh
> modprobe omap_hdq
> cat /sys/class/power_supply/bq27000_battery/uevent
> exec /sbin/init "$@"
>=20
> and then append to kernel parameters init=3D/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