[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f59244eb-a05d-4aa4-89e8-81cfcbafe288@quicinc.com>
Date: Tue, 13 Feb 2024 18:38:55 +0530
From: Jagadeesh Kona <quic_jkona@...cinc.com>
To: Bjorn Andersson <andersson@...nel.org>, Abel Vesa <abel.vesa@...aro.org>
CC: "Rafael J. Wysocki" <rafael@...nel.org>,
Kevin Hilman
<khilman@...nel.org>,
Ulf Hansson <ulf.hansson@...aro.org>, Pavel Machek
<pavel@....cz>,
Len Brown <len.brown@...el.com>,
Greg Kroah-Hartman
<gregkh@...uxfoundation.org>,
Andy Gross <agross@...nel.org>,
Konrad Dybcio
<konrad.dybcio@...aro.org>,
Michael Turquette <mturquette@...libre.com>,
Stephen Boyd <sboyd@...nel.org>,
Stanimir Varbanov
<stanimir.k.varbanov@...il.com>,
Vikash Garodia <quic_vgarodia@...cinc.com>,
Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
Mauro Carvalho Chehab
<mchehab@...nel.org>,
Taniya Das <quic_tdas@...cinc.com>,
Dmitry Baryshkov
<dmitry.baryshkov@...aro.org>,
<linux-pm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<linux-arm-msm@...r.kernel.org>, <linux-clk@...r.kernel.org>,
<linux-media@...r.kernel.org>
Subject: Re: [PATCH v4 3/5] clk: qcom: gdsc: Add set and get hwmode callbacks
to switch GDSC mode
On 1/31/2024 5:49 AM, Bjorn Andersson wrote:
> On Tue, Jan 30, 2024 at 05:00:28PM -0600, Bjorn Andersson wrote:
>> On Mon, Jan 22, 2024 at 10:47:03AM +0200, Abel Vesa wrote:
>>> From: Jagadeesh Kona <quic_jkona@...cinc.com>
>>>
>>> Add support for set and get hwmode callbacks to switch the GDSC between
>>> SW and HW modes. Currently, the GDSC is moved to HW control mode
>>> using HW_CTRL flag and if this flag is present, GDSC is moved to HW
>>> mode as part of GDSC enable itself. The intention is to keep the
>>> HW_CTRL flag functionality as is, since many older chipsets still use
>>> this flag.
>>>
>>
>> This provides insight into why we end up with both HW_CTRL and
>> HW_CTRL_TRIGGER. This doesn't describe why this change is needed, but
>> rather just an implementation detail.
>>
>>> But consumer drivers also require the GDSC mode to be switched dynamically
>>> at runtime based on requirement for certain usecases. Some of these
>>> usecases are switching the GDSC to SW mode to keep it ON during the
>>> enablement of clocks that are dependent on GDSC and while programming
>>> certain configurations that require GDSC to be ON. Introduce a new
>>> HW_CTRL_TRIGGER flag to register the set_hwmode_dev and get_hwmode_dev
>>> callbacks which allows the consumer drivers to switch the GDSC back and
>>> forth between HW/SW modes dynamically at runtime using new
>>> dev_pm_genpd_set_hwmode API.
>>>
>>
>> This still expresses the need for HW_CTRL_TRIGGER in terms of "some
>> drivers need for some use case". We don't need these many words to say:
>> "Introduce HW_CTRL_TRIGGER for client drivers that need it."
>>
>>
>> I find that it would be useful to document that every time a GDSC is
>> turned on the mode will be switched to SW...
>>
>
> I believe I'm wrong here. Reading the patch again, I think we might
> retain the mode across a disable/enable cycle. I at least don't see
> anything explicit returning us to SW mode.
> > According to Linux though, the GDSC is off, so as described below, there
> will be no votes for supplying resources.
>
Yes, With HW_CTRL_TRIGGER flag, the GDSC mode gets switched only in new
set_hwmode_dev() callback when consumers explicitly call for it. This is
to ensure GenPD f/w's hwmode aligns with the actual GDSC mode in HW.
With the new API, the expectation is consumer drivers should move the
GDSC to SW control mode before disabling the GDSC, which ensures that,
GDSC is turned ON in SW mode every time.
Thanks,
Jagadeesh
> Regards,
> Bjorn
Powered by blists - more mailing lists