Re: [PATCHv3] w1: omap-hdq: Simplify driver with PM runtime autosuspend

[Andreas Kemnade]

On Fri, 17 Apr 2020 16:22:47 +0200
"H. Nikolaus Schaller" <hns@xxxxxxxxxxxxx> wrote:

> > Am 16.04.2020 um 20:46 schrieb Tony Lindgren <tony@xxxxxxxxxxx>:
> > 
> > * H. Nikolaus Schaller <hns@xxxxxxxxxxxxx> [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?

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

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

Regards,
Andreas