On Fri, 15 Apr 2011, Alan Stern wrote: > On Fri, 15 Apr 2011, Guennadi Liakhovetski wrote: > > > On Fri, 15 Apr 2011, Alan Stern wrote: > > > > > On Fri, 15 Apr 2011, Guennadi Liakhovetski wrote: > > > > > > > Restore the initial RPM_SUSPENDED runtime pm status, when disabling, > > > > otherwise the following enable will not function. This happens, e.g., > > > > when unloading and reloading drivers. > > ... > > > > This certainly doesn't look right. Can you explain in more detail the > > > problem you are trying to solve? > > > > Yes, I can. On the first loading of an MMC driver, which does the standard > > > > pm_runtime_enable(&pdev->dev); > > ret = pm_runtime_resume(&pdev->dev); > > > > in .probe() and > > > > pm_runtime_disable(&pdev->dev); > > > > in .release() (see [1]), with an inserted card, on the first modprobe I > > see a full pm-runtime run down to platform_pm_runtime_resume() and to > > platform_pm_runtime_suspend() on rmmod. On a repeated modprobe > > platform_pm_runtime_resume() does not get called, because > > dev->power.runtime_status != RPM_SUSPENDED, instead, it is still > > RPM_ACTIVE, so, rpm_resume() exits prematurily. > > I see. And is it true that you really do want to set the status to > RPM_SUSPENDED without touching the hardware, i.e., without disabling > any clocks or gating any power supplies? I'd expected, that pm_runtime_disable() would do all the necessary suspending too in such a case. Isn't this "enable-resume-disable" sequence standard and shouldn't this suffice for the complete cycle? Thanks Guennadi > If so, then your release routine should simply do > > pm_set_suspended(&pdev->dev); > > after calling pm_runtime_disable(). There's no need to modify the > runtime PM core. > > Alan Stern > --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
