* H. Nikolaus Schaller <hns@xxxxxxxxxxxxx> [200417 14:53]: > > > Am 17.04.2020 um 16:43 schrieb Andreas Kemnade <andreas@xxxxxxxxxxxx>: > > > > 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>: > >>> 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? You could sprinkle dev_info(dev, "%s\n", __func__) to the omap_hdq_runtime_suspend() and omap_hdq_runtime_resume() functions. > > 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. Well to me it seems that we have PM runtime handling properly implemented for all the functions in w1_bus_master omap_w1_master, so we should not have any consumers calling into the driver bypassing PM runtime. Maybe the PM runtime usecounts get unbalanced somewhere in the driver where we end up with driver permanently in disabled state? Regards, Tony
