Messages in this thread | | | Date | Mon, 12 Feb 2024 16:03:08 +0530 | Subject | Re: [RFC 4/7] soc: qcom: Utilize qcom scmi vendor protocol for bus dvfs | From | Sibi Sankar <> |
| |
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
| |