From: Sibi Sankar <quic_sibis@quicinc.com>
To: Konrad Dybcio <konrad.dybcio@linaro.org>, <sudeep.holla@arm.com>,
<cristian.marussi@arm.com>, <andersson@kernel.org>,
<jassisinghbrar@gmail.com>, <robh+dt@kernel.org>,
<krzysztof.kozlowski+dt@linaro.org>
Cc: <linux-kernel@vger.kernel.org>, <linux-arm-msm@vger.kernel.org>,
<devicetree@vger.kernel.org>, <quic_rgottimu@quicinc.com>,
<quic_kshivnan@quicinc.com>, <conor+dt@kernel.org>,
Amir Vajid <avajid@quicinc.com>
Subject: Re: [RFC 4/7] soc: qcom: Utilize qcom scmi vendor protocol for bus dvfs
Date: Mon, 12 Feb 2024 16:03:08 +0530 [thread overview]
Message-ID: <d24a3372-8ee5-528d-09ac-86c64f0896e5@quicinc.com> (raw)
In-Reply-To: <7e48e51e-e16a-41b9-800d-960c627b8da6@linaro.org>
On 1/18/24 01:58, Konrad Dybcio wrote:
>
>
> On 1/17/24 18:34, Sibi Sankar wrote:
>> From: Shivnandan Kumar <quic_kshivnan@quicinc.com>
>>
>> This patch introduces a client driver that interacts with the SCMI QCOM
>> vendor protocol and passes on the required tuneables to start various
>> features running on the SCMI controller.
>>
>> Signed-off-by: Shivnandan Kumar <quic_kshivnan@quicinc.com>
>> Co-developed-by: Ramakrishna Gottimukkula <quic_rgottimu@quicinc.com>
>> Signed-off-by: Ramakrishna Gottimukkula <quic_rgottimu@quicinc.com>
>> Co-developed-by: Amir Vajid <avajid@quicinc.com>
>> Signed-off-by: Amir Vajid <avajid@quicinc.com>
>> Co-developed-by: Sibi Sankar <quic_sibis@quicinc.com>
>> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com>
>> ---
>
> [...]
>
>
>> +
>> +struct cpufreq_memfreq_map {
>> + unsigned int cpufreq_mhz;
>> + unsigned int memfreq_khz;
>> +};
>
> Weird use of tabs
will fix it in the next re-spin.
>
> [...]
>
>> +static int get_mask(struct device_node *np, u32 *mask)
>> +{
>> + struct device_node *dev_phandle;
>> + struct device *cpu_dev;
>> + int cpu, i = 0;
>> + int ret = -ENODEV;
>
> Don't initialize ret here, return 0 instead of breaking and return
> enodev otherwise.
ack
>
>> +
>> + dev_phandle = of_parse_phandle(np, "qcom,cpulist", i++);
>> + while (dev_phandle) {
>> + for_each_possible_cpu(cpu) {
>> + cpu_dev = get_cpu_device(cpu);
>> + if (cpu_dev && cpu_dev->of_node == dev_phandle) {
>> + *mask |= BIT(cpu);
>> + ret = 0;
>> + break;
>> + }
>> + }
>
> of_cpu_node_to_id()
ack
>
>> + dev_phandle = of_parse_phandle(np, "qcom,cpulist", i++);
>> + }
>> +
>> + return ret;
>> +}
>
>
>> +
>> +static struct cpufreq_memfreq_map *init_cpufreq_memfreq_map(struct
>> device *dev,
>> + struct device_node *of_node,
>> + u32 *cnt)
>
> I really feel like this is trying to reinvent OPP..
>
> if you structure your entries like so:
>
> opp-0 {
> opp-hz = /bits/ 64 <12341234 43214321>;
> };
>
> you'll be able to use all the fantastic APIs that have been
> created over the years!
I didn't know listing multiple frequencies in a opp was allowed. We can
probably get away with it here since we just parse the data here and not
populate data in the opp core.
>
> [...]
>
>> + monitor->mon_type = (of_property_read_bool(monitor_np,
>> "qcom,compute-mon")) ? 1 : 0;
>> + monitor->ipm_ceil = (of_property_read_bool(monitor_np,
>> "qcom,compute-mon")) ? 0 : 20000000;
>
> What does it even mean for a monitor to be a compute mon?
>
When a monitor is marked compute-mon it means that the table is
followed religiously irrespective whether the instruction per miss
count threshold (ipm) is exceeded or not. Equivalent to having
a cpufreq map -> l3/DDR bw mapping upstream.
> There seem to be no dt-bindings for properties referenced in this
> driver, neither in the series nor in the dependencies. This is
> strictly required.
Ack
Thanks again for reviewing the series. :)
-Sibi
>
> Konrad
next prev parent reply other threads:[~2024-02-12 10:33 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-17 17:34 [RFC 0/7] firmware: arm_scmi: Qualcomm Vendor Protocol Sibi Sankar
2024-01-17 17:34 ` [RFC 1/7] dt-bindings: mailbox: qcom: Add CPUCP mailbox controller bindings Sibi Sankar
2024-01-17 19:53 ` Konrad Dybcio
2024-02-08 10:22 ` Sibi Sankar
2024-02-08 23:14 ` Konrad Dybcio
2024-02-12 5:48 ` Sibi Sankar
2024-01-30 17:12 ` Rob Herring
2024-02-08 10:28 ` Sibi Sankar
2024-02-08 15:58 ` Krzysztof Kozlowski
2024-02-28 17:37 ` Konrad Dybcio
2024-01-17 17:34 ` [RFC 2/7] mailbox: Add support for QTI CPUCP mailbox controller Sibi Sankar
2024-01-17 19:03 ` Dmitry Baryshkov
2024-01-17 17:34 ` [RFC 3/7] firmware: arm_scmi: Add QCOM vendor protocol Sibi Sankar
2024-01-17 19:09 ` Dmitry Baryshkov
2024-02-12 8:31 ` Sibi Sankar
2024-01-17 20:15 ` Konrad Dybcio
2024-01-17 20:31 ` Cristian Marussi
2024-02-08 11:44 ` Sibi Sankar
2024-02-09 22:45 ` Konrad Dybcio
2024-02-12 8:56 ` Sibi Sankar
2024-01-17 20:15 ` Konrad Dybcio
2024-01-18 17:22 ` Sudeep Holla
2024-02-12 9:14 ` Sibi Sankar
2024-02-12 17:39 ` Cristian Marussi
2024-02-29 14:16 ` Sudeep Holla
2024-02-29 14:24 ` Sudeep Holla
2024-01-17 17:34 ` [RFC 4/7] soc: qcom: Utilize qcom scmi vendor protocol for bus dvfs Sibi Sankar
2024-01-17 20:28 ` Konrad Dybcio
2024-02-12 10:33 ` Sibi Sankar [this message]
2024-01-17 20:41 ` Dmitry Baryshkov
2024-02-12 10:24 ` Sibi Sankar
2024-02-12 13:22 ` Dmitry Baryshkov
2024-02-20 15:07 ` Cristian Marussi
2024-02-28 17:31 ` Sibi Sankar
2024-02-29 14:27 ` Sudeep Holla
2024-02-20 16:19 ` Cristian Marussi
2024-02-29 14:41 ` Sudeep Holla
2024-01-17 17:34 ` [RFC 5/7] arm64: dts: qcom: x1e80100: Add cpucp mailbox and sram nodes Sibi Sankar
2024-01-17 17:34 ` [RFC 6/7] arm64: dts: qcom: x1e80100: Enable cpufreq Sibi Sankar
2024-01-18 15:25 ` Sudeep Holla
2024-02-12 9:28 ` Sibi Sankar
2024-01-17 17:34 ` [RFC 7/7] arm64: dts: qcom: x1e80100: Enable LLCC/DDR dvfs Sibi Sankar
2024-01-17 20:38 ` Konrad Dybcio
2024-02-12 10:05 ` Sibi Sankar
2024-01-17 20:47 ` Dmitry Baryshkov
2024-02-12 9:47 ` Sibi Sankar
2024-02-12 18:11 ` [RFC 0/7] firmware: arm_scmi: Qualcomm Vendor Protocol Cristian Marussi
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=d24a3372-8ee5-528d-09ac-86c64f0896e5@quicinc.com \
--to=quic_sibis@quicinc.com \
--cc=andersson@kernel.org \
--cc=avajid@quicinc.com \
--cc=conor+dt@kernel.org \
--cc=cristian.marussi@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=jassisinghbrar@gmail.com \
--cc=konrad.dybcio@linaro.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quic_kshivnan@quicinc.com \
--cc=quic_rgottimu@quicinc.com \
--cc=robh+dt@kernel.org \
--cc=sudeep.holla@arm.com \
/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;
as well as URLs for NNTP newsgroup(s).