* Preventing PM from suspending device
@ 2017-01-09 17:22 Niklas Söderlund
2017-01-11 23:19 ` Ulf Hansson
0 siblings, 1 reply; 10+ messages in thread
From: Niklas Söderlund @ 2017-01-09 17:22 UTC (permalink / raw)
To: Ulf Hansson, linux-pm; +Cc: Geert Uytterhoeven
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.
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.
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?
1. https://marc.info/?l=linux-pm&m=148397620011501&w=2
--
Regards,
Niklas Söderlund
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Preventing PM from suspending device
2017-01-09 17:22 Preventing PM from suspending device Niklas Söderlund
@ 2017-01-11 23:19 ` Ulf Hansson
2017-01-12 7:10 ` Geert Uytterhoeven
0 siblings, 1 reply; 10+ messages in thread
From: Ulf Hansson @ 2017-01-11 23:19 UTC (permalink / raw)
To: Niklas Söderlund; +Cc: linux-pm, Geert Uytterhoeven
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?
>
> 1. https://marc.info/?l=linux-pm&m=148397620011501&w=2
>
> --
> Regards,
> Niklas Söderlund
Kind regards
Uffe
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Preventing PM from suspending device
2017-01-11 23:19 ` Ulf Hansson
@ 2017-01-12 7:10 ` Geert Uytterhoeven
2017-01-12 17:02 ` Ulf Hansson
0 siblings, 1 reply; 10+ messages in thread
From: Geert Uytterhoeven @ 2017-01-12 7:10 UTC (permalink / raw)
To: Ulf Hansson; +Cc: Niklas Söderlund, linux-pm
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).
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Preventing PM from suspending device
2017-01-12 7:10 ` Geert Uytterhoeven
@ 2017-01-12 17:02 ` Ulf Hansson
2017-01-13 9:38 ` Geert Uytterhoeven
2017-03-29 19:28 ` Niklas Söderlund
0 siblings, 2 replies; 10+ messages in thread
From: Ulf Hansson @ 2017-01-12 17:02 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Niklas Söderlund, linux-pm
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! :-)
Kind regards
Uffe
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Preventing PM from suspending device
2017-01-12 17:02 ` Ulf Hansson
@ 2017-01-13 9:38 ` Geert Uytterhoeven
2017-03-29 19:28 ` Niklas Söderlund
1 sibling, 0 replies; 10+ messages in thread
From: Geert Uytterhoeven @ 2017-01-13 9:38 UTC (permalink / raw)
To: Ulf Hansson; +Cc: Niklas Söderlund, linux-pm
Hi Ulf,
On Thu, Jan 12, 2017 at 6:02 PM, Ulf Hansson <ulf.hansson@linaro.org> 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:
>>>> 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.
Related commits calling clk_enable() to keep modules awake:
- 6f46aedb9c85873b ("irqchip: renesas-irqc: Add wake-up support")
- ab82fa7da4dce5c7 ("gpio: rcar: Prevent module clock disable when
wake-up is enabled")
- 705bc96c2c15313c ("irqchip: renesas-intc-irqpin: Add minimal runtime
PM support")
Basically anything needed for wake-up needs to stay active, but should
not prevent the system from entering system suspend (i.e. cannot return
-EBUSY from its suspend function).
> 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! :-)
Thanks, and happy thinking!
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Preventing PM from suspending device
2017-01-12 17:02 ` Ulf Hansson
2017-01-13 9:38 ` Geert Uytterhoeven
@ 2017-03-29 19:28 ` Niklas Söderlund
2017-03-30 16:44 ` Ulf Hansson
1 sibling, 1 reply; 10+ messages in thread
From: Niklas Söderlund @ 2017-03-29 19:28 UTC (permalink / raw)
To: Ulf Hansson; +Cc: Geert Uytterhoeven, linux-pm
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Preventing PM from suspending device
2017-03-29 19:28 ` Niklas Söderlund
@ 2017-03-30 16:44 ` Ulf Hansson
2017-03-30 20:35 ` Niklas Söderlund
0 siblings, 1 reply; 10+ messages in thread
From: Ulf Hansson @ 2017-03-30 16:44 UTC (permalink / raw)
To: Niklas Söderlund; +Cc: Geert Uytterhoeven, linux-pm
On 29 March 2017 at 21:28, Niklas Söderlund
<niklas.soderlund@ragnatech.se> wrote:
> 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 :-)
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.
Sorry for the delay!
Br
Uffe
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Preventing PM from suspending device
2017-03-30 16:44 ` Ulf Hansson
@ 2017-03-30 20:35 ` Niklas Söderlund
2017-10-18 11:35 ` Geert Uytterhoeven
0 siblings, 1 reply; 10+ messages in thread
From: Niklas Söderlund @ 2017-03-30 20:35 UTC (permalink / raw)
To: Ulf Hansson; +Cc: Geert Uytterhoeven, linux-pm
Hi Ulf,
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:
> > 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 :-)
>
> 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.
Thanks again for thinking about this.
>
> Br
> Uffe
--
Regards,
Niklas Söderlund
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Preventing PM from suspending device
2017-03-30 20:35 ` Niklas Söderlund
@ 2017-10-18 11:35 ` Geert Uytterhoeven
2017-10-18 12:06 ` Ulf Hansson
0 siblings, 1 reply; 10+ messages in thread
From: Geert Uytterhoeven @ 2017-10-18 11:35 UTC (permalink / raw)
To: Niklas Söderlund, Ulf Hansson; +Cc: linux-pm
)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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Preventing PM from suspending device
2017-10-18 11:35 ` Geert Uytterhoeven
@ 2017-10-18 12:06 ` Ulf Hansson
0 siblings, 0 replies; 10+ messages in thread
From: Ulf Hansson @ 2017-10-18 12:06 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Niklas Söderlund, linux-pm
On 18 October 2017 at 13:35, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> )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).
That works, but as a matter of fact a have a slightly different idea
on how to perhaps better solve this. Allow me a couple of days, then I
respond to you.
Kind regards
Uffe
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2017-10-18 12:06 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-01-09 17:22 Preventing PM from suspending device Niklas Söderlund
2017-01-11 23:19 ` Ulf Hansson
2017-01-12 7:10 ` Geert Uytterhoeven
2017-01-12 17:02 ` Ulf Hansson
2017-01-13 9:38 ` Geert Uytterhoeven
2017-03-29 19:28 ` Niklas Söderlund
2017-03-30 16:44 ` Ulf Hansson
2017-03-30 20:35 ` Niklas Söderlund
2017-10-18 11:35 ` Geert Uytterhoeven
2017-10-18 12:06 ` Ulf Hansson
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.