Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230628105652.1670316-1-abel.vesa@linaro.org>
In-Reply-To: <20230628105652.1670316-1-abel.vesa@linaro.org>
From:   "Rafael J. Wysocki" <rafael@kernel.org>
Date:   Wed, 28 Jun 2023 19:15:42 +0200
Message-ID: <CAJZ5v0i-+b+oFOP92rhNw_UOKu3-QOy_-stQRa5X2HbaTq9XMA@mail.gmail.com>
Subject: Re: [PATCH 0/2] PM: domains: Add control for switching back and forth
 to HW control
To:     Abel Vesa <abel.vesa@linaro.org>
Cc:     "Rafael J . Wysocki" <rafael@kernel.org>,
        Kevin Hilman <khilman@kernel.org>,
        Ulf Hansson <ulf.hansson@linaro.org>,
        avel Machek <pavel@ucw.cz>, Len Brown <len.brown@intel.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Bjorn Andersson <andersson@kernel.org>,
        Andy Gross <agross@kernel.org>,
        Konrad Dybcio <konrad.dybcio@linaro.org>,
        Mike Turquette <mturquette@baylibre.com>,
        Stephen Boyd <sboyd@kernel.org>,
        Taniya Das <tdas@qti.qualcomm.com>, linux-pm@vger.kernel.org,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        linux-arm-msm@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Precedence: bulk

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.