| 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 |
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.
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