Re: Preventing PM from suspending device

[Geert Uytterhoeven <geert@linux-m68k.org>]

)Hi Niklas, Ulf,

On Thu, Mar 30, 2017 at 10:35 PM, Niklas Söderlund
<niklas.soderlund@ragnatech.se> wrote:
> On 2017-03-30 18:44:20 +0200, Ulf Hansson wrote:
>> On 29 March 2017 at 21:28, Niklas Söderlund
>> <niklas.soderlund@ragnatech.se> wrote:
>> > 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:
>> >> > 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:
>> >> >>> 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 :-)
>>
>> Yes I have! :-) It's soon reaching my top of my TODO list.
>>
>> I realized that thinking isn't sufficient, I need to do some
>> prototyping to convince myself about the best approach.
>
> That's great news :-)
>
>>
>> Sorry for the delay!
>
> No worries, I'm not suffering from this since I can manage the clock
> directly from the driver. And as Geert explained the device is in an
> always on power domain. I just wanted to check in so that if a different
> solution is found I can remove the explicit clock handling.

In case you missed it: the issue turned out to be the R-Car PM Domain
driver(s) not proving gpd_dev_ops.active_wakeup() callbacks, cfr.
"[PATCH 00/10] PM / Domain: renesas: Fix active wakeup behavior"
(https://www.spinics.net/lists/linux-renesas-soc/msg19319.html).

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds