mbox series

[0/2] PM: domains: Add control for switching back and forth to HW control

Message ID 20230628105652.1670316-1-abel.vesa@linaro.org (mailing list archive)
Headers show
Series PM: domains: Add control for switching back and forth to HW control | expand

Message

Abel Vesa June 28, 2023, 10:56 a.m. UTC
This is just a resend of [1]. This resend just adds the back story behind
the need for such a generic API as a cover letter. Also added my SoB tag
to Ulf's patch.

Some of the newer Qualcomm platforms support handing of the control of
some of the GDSCs (implemented as power domains in Linux) to some device
firmware. The idea behind such approach is that the firmware knows best
when such a power domain can be powered off or not and leads most of the
time to better power consumption.

At this point, if such GDSC provides HW control support, the current
implementation is switching to HW control right after the GDSC gets
powered on and it is left in HW control mode until right before the
request for power off is done. This needs to remain as is for now, as we
do not know for sure what each firmware expects from its related GDSCs.
For example, the venus driver expects the codec GDSCs to remain always
in HW control mode, otherwise the firmware would crush.

But in some cases, the consumer driver needs to switch back and forth.
And the explanation for such case is when a driver needs to interract
with the device (e.g. reading status bits) and the firmware doesn't
guarantee the GDSC will be enabled when in HW mode. Therefore, the
consumer would need to switch back to SW mode, do its thing, and then
switch again back to HW mode.

This is where the patch from Ulf comes in. It allows consumers that
actually need to control the HW/SW mode to do so.

The GDSC patch just implemets the set_hwmode op and sets it for each
GDSC that provides HW control mode.

[1] https://lore.kernel.org/all/20230627104033.3345659-1-abel.vesa@linaro.org/

Abel Vesa (1):
  clk: qcom: gdsc: Add support for set_hwmode_dev

Ulf Hansson (1):
  PM: domains: Allow devices attached to genpd to be managed by HW

 drivers/base/power/domain.c | 66 +++++++++++++++++++++++++++++++++++++
 drivers/clk/qcom/gdsc.c     | 22 +++++++++++++
 include/linux/pm_domain.h   | 15 +++++++++
 3 files changed, 103 insertions(+)

Comments

Rafael J. Wysocki June 28, 2023, 5:15 p.m. UTC | #1
On Wed, Jun 28, 2023 at 12:57 PM Abel Vesa <abel.vesa@linaro.org> wrote:
>
> This is just a resend of [1]. This resend just adds the back story behind
> the need for such a generic API as a cover letter. Also added my SoB tag
> to Ulf's patch.
>
> Some of the newer Qualcomm platforms support handing of the control of
> some of the GDSCs (implemented as power domains in Linux) to some device
> firmware. The idea behind such approach is that the firmware knows best
> when such a power domain can be powered off or not and leads most of the
> time to better power consumption.
>
> At this point, if such GDSC provides HW control support, the current
> implementation is switching to HW control right after the GDSC gets
> powered on and it is left in HW control mode until right before the
> request for power off is done. This needs to remain as is for now, as we
> do not know for sure what each firmware expects from its related GDSCs.
> For example, the venus driver expects the codec GDSCs to remain always
> in HW control mode, otherwise the firmware would crush.
>
> But in some cases, the consumer driver needs to switch back and forth.
> And the explanation for such case is when a driver needs to interract
> with the device (e.g. reading status bits) and the firmware doesn't
> guarantee the GDSC will be enabled when in HW mode. Therefore, the
> consumer would need to switch back to SW mode, do its thing, and then
> switch again back to HW mode.
>
> This is where the patch from Ulf comes in. It allows consumers that
> actually need to control the HW/SW mode to do so.
>
> The GDSC patch just implemets the set_hwmode op and sets it for each
> GDSC that provides HW control mode.
>
> [1] https://lore.kernel.org/all/20230627104033.3345659-1-abel.vesa@linaro.org/
>
> Abel Vesa (1):
>   clk: qcom: gdsc: Add support for set_hwmode_dev
>
> Ulf Hansson (1):
>   PM: domains: Allow devices attached to genpd to be managed by HW
>
>  drivers/base/power/domain.c | 66 +++++++++++++++++++++++++++++++++++++
>  drivers/clk/qcom/gdsc.c     | 22 +++++++++++++
>  include/linux/pm_domain.h   | 15 +++++++++
>  3 files changed, 103 insertions(+)
>
> --

I can queue up this series if I get an ACK for the second patch.
Ulf Hansson June 28, 2023, 9:55 p.m. UTC | #2
On Wed, 28 Jun 2023 at 19:15, Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Wed, Jun 28, 2023 at 12:57 PM Abel Vesa <abel.vesa@linaro.org> wrote:
> >
> > This is just a resend of [1]. This resend just adds the back story behind
> > the need for such a generic API as a cover letter. Also added my SoB tag
> > to Ulf's patch.
> >
> > Some of the newer Qualcomm platforms support handing of the control of
> > some of the GDSCs (implemented as power domains in Linux) to some device
> > firmware. The idea behind such approach is that the firmware knows best
> > when such a power domain can be powered off or not and leads most of the
> > time to better power consumption.
> >
> > At this point, if such GDSC provides HW control support, the current
> > implementation is switching to HW control right after the GDSC gets
> > powered on and it is left in HW control mode until right before the
> > request for power off is done. This needs to remain as is for now, as we
> > do not know for sure what each firmware expects from its related GDSCs.
> > For example, the venus driver expects the codec GDSCs to remain always
> > in HW control mode, otherwise the firmware would crush.
> >
> > But in some cases, the consumer driver needs to switch back and forth.
> > And the explanation for such case is when a driver needs to interract
> > with the device (e.g. reading status bits) and the firmware doesn't
> > guarantee the GDSC will be enabled when in HW mode. Therefore, the
> > consumer would need to switch back to SW mode, do its thing, and then
> > switch again back to HW mode.
> >
> > This is where the patch from Ulf comes in. It allows consumers that
> > actually need to control the HW/SW mode to do so.
> >
> > The GDSC patch just implemets the set_hwmode op and sets it for each
> > GDSC that provides HW control mode.
> >
> > [1] https://lore.kernel.org/all/20230627104033.3345659-1-abel.vesa@linaro.org/
> >
> > Abel Vesa (1):
> >   clk: qcom: gdsc: Add support for set_hwmode_dev
> >
> > Ulf Hansson (1):
> >   PM: domains: Allow devices attached to genpd to be managed by HW
> >
> >  drivers/base/power/domain.c | 66 +++++++++++++++++++++++++++++++++++++
> >  drivers/clk/qcom/gdsc.c     | 22 +++++++++++++
> >  include/linux/pm_domain.h   | 15 +++++++++
> >  3 files changed, 103 insertions(+)
> >
> > --
>
> I can queue up this series if I get an ACK for the second patch.

Thanks, but please hold on until you get additional confirmation from me.

I would like the consumer APIs that are being added in patch1 to have
a user. At least I want to see a plan for upstreaming one user of it,
before I think we should move forward. FYI, there are discussions
around this offlist too.

Kind regards
Uffe