Re: Preventing PM from suspending device

["Niklas Söderlund" <niklas.soderlund@ragnatech.se>]

Hi Ulf,

On 2017-01-12 18:02:40 +0100, Ulf Hansson wrote:
> On 12 January 2017 at 08:10, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > Hi Ulf,
> >
> > On Thu, Jan 12, 2017 at 12:19 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> >> On 9 January 2017 at 18:22, Niklas Söderlund
> >> <niklas.soderlund@ragnatech.se> wrote:
> >>> Hi Ulf and Linux PM,
> >>>
> >>> I have a question regarding if a driver can signal to the PM core that
> >>> it should not be suspended from its struct dev_pm_ops suspend callback.
> >>
> >> No. The driver/subsystem needs to deal this.
> >>
> >>> My use-case is the sh_eth driver which I have added Wake-on-Lan support
> >>> to, see [1]. In this driver I need to prevent the PM core to disable the
> >>> module clock to the device if WoL is enabled. Currently I call
> >>> clk_enable()/clk_disable() from the suspend/resume callbacks to modify
> >>> the usage count of the clock to prevent the clock from being switched
> >>> off by PM. This do not feel like the best solution to my problem.
> >>
> >> I am not sure I get this. Is someone else than the driver performing
> >> clk gateing/un-gating of the same clock?
> >>>
> >>> Is there a more generic way to let PM know that I'm fine with the system
> >>> being suspended and I have suspended as much as I can but I'm a wake up source
> >>> so could please not switch of my clock and power domain?
> >>
> >> Seems like a quite common issue, but before we go into more details,
> >> are you using genpd as the power domain? If not, what?
> >
> > The Ethernet device is part of a PM Domain, hence it's power-managed by
> > genpd.
> > On most SoCs, that PM Domain is a clock domain, so Runtime PM and system
> > suspend disable the device's module clock, the latter breaking WoL.
> > Calling clk_enable() from the suspend callback works around that.
> > On some SoCs, that PM Domain is both a clock domain and a power domain.
> > Calling clk_enable() from the suspend callback is not sufficient here, but
> > fortunately the power domain stays powered for another reason (it contains
> > the memory controller).
> 
> Thanks for the additional information, very useful.
> 
> Allow me to think of this a little bit, before I give any further
> suggestions. Indeed a very interesting use-case, well worth to think
> more about! :-)

I'm curious if you have had the opportunity to think about this. If not 
no rush, I'm just checking in :-)

> 
> Kind regards
> Uffe

-- 
Regards,
Niklas Söderlund