Re: [RFC 4/7] soc: qcom: Utilize qcom scmi vendor protocol for bus dvfs

[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@xxxxxxxxxxx>
> >
> > 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@xxxxxxxxxxx>
> > Co-developed-by: Ramakrishna Gottimukkula <quic_rgottimu@xxxxxxxxxxx>
> > Signed-off-by: Ramakrishna Gottimukkula <quic_rgottimu@xxxxxxxxxxx>
> > Co-developed-by: Amir Vajid <avajid@xxxxxxxxxxx>
> > Signed-off-by: Amir Vajid <avajid@xxxxxxxxxxx>
> > Co-developed-by: Sibi Sankar <quic_sibis@xxxxxxxxxxx>
> > Signed-off-by: Sibi Sankar <quic_sibis@xxxxxxxxxxx>
> > ---
>
> [...]
>
>
> > +
> > +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