Received-SPF: pass (google.com: domain of linux-kernel+bounces-61320-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Message-ID: <d24a3372-8ee5-528d-09ac-86c64f0896e5@quicinc.com>
Date: Mon, 12 Feb 2024 16:03:08 +0530
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Subject: Re: [RFC 4/7] soc: qcom: Utilize qcom scmi vendor protocol for bus
 dvfs
Content-Language: en-US
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>
References: <20240117173458.2312669-1-quic_sibis@quicinc.com>
 <20240117173458.2312669-5-quic_sibis@quicinc.com>
 <7e48e51e-e16a-41b9-800d-960c627b8da6@linaro.org>
From: Sibi Sankar <quic_sibis@quicinc.com>
In-Reply-To: <7e48e51e-e16a-41b9-800d-960c627b8da6@linaro.org>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit


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