[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <6430AF54-849E-456B-8DB0-B4478BBDB78D@goldelico.com>
Date: Fri, 17 Apr 2020 16:52:15 +0200
From: "H. Nikolaus Schaller" <hns@...delico.com>
To: Andreas Kemnade <andreas@...nade.info>
Cc: Tony Lindgren <tony@...mide.com>,
Evgeniy Polyakov <zbr@...emap.net>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-omap <linux-omap@...r.kernel.org>,
Adam Ford <aford173@...il.com>,
"Andrew F . Davis" <afd@...com>, Vignesh R <vigneshr@...com>
Subject: Re: [PATCHv3] w1: omap-hdq: Simplify driver with PM runtime autosuspend
> Am 17.04.2020 um 16:43 schrieb Andreas Kemnade <andreas@...nade.info>:
>
> On Fri, 17 Apr 2020 16:22:47 +0200
> "H. Nikolaus Schaller" <hns@...delico.com> wrote:
>
>>> Am 16.04.2020 um 20:46 schrieb Tony Lindgren <tony@...mide.com>:
>>>
>>> * H. Nikolaus Schaller <hns@...delico.com> [200416 15:04]:
>>>> Hi Tony,
>>>> it looks as if something with this patch is broken on GTA04. For v5.6 and v5.7-rc1.
>>>>
>>>> HDQ battery access times out after ca. 15 seconds and I get temperature of -273.1°C...
>>>>
>>>> Reverting this patch and everything is ok again.
>>>
>>> Hmm OK interesting.
>>>
>>>> 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?
>>>
>>> Sounds like you have things working though so there should be no
>>> need for having ti,mode = "1w" in the dts.
>>>
>>>>> pm_runtime_enable(&pdev->dev);
>>>>> + pm_runtime_use_autosuspend(&pdev->dev);
>>>>> + pm_runtime_set_autosuspend_delay(&pdev->dev, 300);
>>>
>>> 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.
>>>
>>> If that helps, likely we have a missing pm_runtime_get_sync()
>>> somewhere in the driver.
>>
>> Yes, it does! It suffices to set it to -1 for one readout.
>> Aything else I can test?
>>
> 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.
>
> Can you reproduce the problem with init=/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
Powered by blists - more mailing lists