From: Sudeep Holla <sudeep.holla@arm.com>
To: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: andersson@kernel.org, viresh.kumar@linaro.org,
krzysztof.kozlowski+dt@linaro.org, rafael@kernel.org,
robh+dt@kernel.org, johan@kernel.org, devicetree@vger.kernel.org,
linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
Sudeep Holla <sudeep.holla@arm.com>,
linux-pm@vger.kernel.org
Subject: Re: [PATCH v4 0/3] qcom-cpufreq-hw: Add CPU clock provider support
Date: Tue, 8 Nov 2022 15:45:32 +0000 [thread overview]
Message-ID: <20221108154532.dvo3drvvkagkssab@bogus> (raw)
In-Reply-To: <20221102090818.65321-1-manivannan.sadhasivam@linaro.org>
On Wed, Nov 02, 2022 at 02:38:15PM +0530, Manivannan Sadhasivam wrote:
> Hello,
>
> This series adds clock provider support to the Qcom CPUFreq driver for
> supplying the clocks to the CPU cores in Qcom SoCs.
>
> The Qualcomm platforms making use of CPUFreq HW Engine (EPSS/OSM) supply
> clocks to the CPU cores. But this is not represented clearly in devicetree.
> There is no clock coming out of the CPUFreq HW node to the CPU. This created
> an issue [1] with the OPP core when a recent enhancement series was submitted.
> Eventhough the issue got fixed in the OPP framework in the meantime, that's
> not a proper solution and this series aims to fix it properly.
>
> There was also an attempt made by Viresh [2] to fix the issue by moving the
> clocks supplied to the CPUFreq HW node to the CPU. But that was not accepted
> since those clocks belong to the CPUFreq HW node only.
>
> The proposal here is to add clock provider support to the Qcom CPUFreq HW
> driver to supply clocks to the CPUs that comes out of the EPSS/OSM block.
> This correctly reflects the hardware implementation.
>
Just curious as who will be the consumer of this CPU clock information ?
Traditionally it was cpufreq that needed this information. But now with
this series, it is bit convoluted IMO as the clocks is depending on the
CPUFreq information indirectly and not used by cpufreq.
Whoever is the consumer of this clock, why can't they use cpufreq information ?
I did a quick check and couldn't find the info I am requesting here, sorry if
it is already answered/discussed. Please just point me the url.
--
Regards,
Sudeep
prev parent reply other threads:[~2022-11-08 15:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-02 9:08 [PATCH v4 0/3] qcom-cpufreq-hw: Add CPU clock provider support Manivannan Sadhasivam
2022-11-02 9:08 ` [PATCH v4 1/3] dt-bindings: cpufreq: cpufreq-qcom-hw: Add cpufreq clock provider Manivannan Sadhasivam
2022-11-02 9:08 ` [PATCH v4 2/3] arm64: dts: qcom: sm8450: Supply clock from cpufreq node to CPUs Manivannan Sadhasivam
2022-11-02 9:08 ` [PATCH v4 3/3] cpufreq: qcom-hw: Add CPU clock provider support Manivannan Sadhasivam
2022-11-07 22:30 ` Bjorn Andersson
2022-11-08 15:26 ` Manivannan Sadhasivam
2022-11-07 10:10 ` [PATCH v4 0/3] qcom-cpufreq-hw: " Viresh Kumar
2022-11-08 15:45 ` Sudeep Holla [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221108154532.dvo3drvvkagkssab@bogus \
--to=sudeep.holla@arm.com \
--cc=andersson@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=johan@kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=rafael@kernel.org \
--cc=robh+dt@kernel.org \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox