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=utf-8
From:   "H. Nikolaus Schaller" <hns@goldelico.com>
In-Reply-To: <20200417164340.3d9043d1@aktux>
Date:   Fri, 17 Apr 2020 16:52: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: <6430AF54-849E-456B-8DB0-B4478BBDB78D@goldelico.com>
References: <20191217004048.46298-1-tony@atomide.com> <7B8C7DD9-095B-48FC-9642-695D07B79E97@goldelico.com> <20200416184638.GI37466@atomide.com> <3197C3F0-DEB9-4221-AFBD-4F2A08C84C4C@goldelico.com> <20200417164340.3d9043d1@aktux>
To:     Andreas Kemnade <andreas@kemnade.info>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> Am 17.04.2020 um 16:43 schrieb Andreas Kemnade <andreas@kemnade.info>:
>=20
> On Fri, 17 Apr 2020 16:22:47 +0200
> "H. Nikolaus Schaller" <hns@goldelico.com> wrote:
>=20
>>> Am 16.04.2020 um 20:46 schrieb Tony Lindgren <tony@atomide.com>:
>>>=20
>>> * H. Nikolaus Schaller <hns@goldelico.com> [200416 15:04]: =20
>>>> Hi Tony,
>>>> it looks as if something with this patch is broken on GTA04. For =
v5.6 and v5.7-rc1.
>>>>=20
>>>> HDQ battery access times out after ca. 15 seconds and I get =
temperature of -273.1=C2=B0C...
>>>>=20
>>>> Reverting this patch and everything is ok again. =20
>>>=20
>>> Hmm OK interesting.
>>>=20
>>>> What is "ti,mode" about? Do we have that (indirectly) in =
gta04.dtsi?
>>>> Or does this patch need some CONFIGs we do not happen to have? =20
>>>=20
>>> Sounds like you have things working though so there should be no
>>> need for having ti,mode =3D "1w" in the dts.
>>>=20
>>>>> 	pm_runtime_enable(&pdev->dev);
>>>>> +	pm_runtime_use_autosuspend(&pdev->dev);
>>>>> +	pm_runtime_set_autosuspend_delay(&pdev->dev, 300); =20
>>>=20
>>> Care to check if changing pm_runtime_set_autosuspend_delay value
>>> to -1 in probe makes the issue go away? Or change it manually
>>> to -1 via sysfs.
>>>=20
>>> If that helps, likely we have a missing pm_runtime_get_sync()
>>> somewhere in the driver. =20
>>=20
>> Yes, it does! It suffices to set it to -1 for one readout.
>> Aything else I can test?
>>=20
> How does it depend on loaded drivers?
> Is it really mainline kernel + config + devicetree or something else?

Well, I can revert the patch on the same
kernel (5.6 or 5.7-rc1) + config + devicetree + user-space
and the problem is gone.

This means that something is different between the old and the new
version which makes the hdq access delayed and failing. Of course I
don't know the reason for it and what does influence it.

>=20
> Can you reproduce the problem with init=3D/bin/bash
> and then mount sysfs and modprobe omap_hdq?

I am not sure how quickly I can test such a setup.

> Regarding pm_runtime stuff I thought I have the worst case scenario.

What may make a difference is the sequence in which drivers are loaded.

BR,
Nikolaus