linux-kernel - Re: [PATCH v3 5/6] arm64: dts: qcom: sm6150: Add gpu and rgmu nodes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9971bd9b-88db-4628-b36b-de50c1619396@oss.qualcomm.com>
Date: Thu, 11 Dec 2025 02:40:52 +0530
From: Akhil P Oommen <akhilpo@....qualcomm.com>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
        Rob Clark <robin.clark@....qualcomm.com>, Sean Paul <sean@...rly.run>,
        Konrad Dybcio <konradybcio@...nel.org>,
        Dmitry Baryshkov <lumag@...nel.org>,
        Abhinav Kumar <abhinav.kumar@...ux.dev>,
        Marijn Suijten <marijn.suijten@...ainline.org>,
        David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Maxime Ripard <mripard@...nel.org>,
        Thomas Zimmermann <tzimmermann@...e.de>, Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Jessica Zhang <jesszhan0024@...il.com>,
        Dan Carpenter <dan.carpenter@...aro.org>,
        linux-arm-msm@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        freedreno@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, Jie Zhang <quic_jiezh@...cinc.com>
Subject: Re: [PATCH v3 5/6] arm64: dts: qcom: sm6150: Add gpu and rgmu nodes

On 12/6/2025 2:04 AM, Dmitry Baryshkov wrote:
> On Fri, Dec 05, 2025 at 03:59:09PM +0530, Akhil P Oommen wrote:
>> On 12/4/2025 7:49 PM, Dmitry Baryshkov wrote:
>>> On Thu, Dec 04, 2025 at 03:43:33PM +0530, Akhil P Oommen wrote:
>>>> On 11/26/2025 6:12 AM, Dmitry Baryshkov wrote:
>>>>> On Sat, Nov 22, 2025 at 03:03:10PM +0100, Konrad Dybcio wrote:
>>>>>> On 11/21/25 10:52 PM, Akhil P Oommen wrote:
>>>>>>> From: Jie Zhang <quic_jiezh@...cinc.com>
>>>>>>>
>>>>>>> Add gpu and rgmu nodes for qcs615 chipset.
>>>>>>>
>>>>>>> Signed-off-by: Jie Zhang <quic_jiezh@...cinc.com>
>>>>>>> Signed-off-by: Akhil P Oommen <akhilpo@....qualcomm.com>
>>>>>>> ---
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>> +			gpu_opp_table: opp-table {
>>>>>>> +				compatible = "operating-points-v2";
>>>>>>> +
>>>>>>> +				opp-845000000 {
>>>>>>> +					opp-hz = /bits/ 64 <845000000>;
>>>>>>> +					required-opps = <&rpmhpd_opp_turbo>;
>>>>>>> +					opp-peak-kBps = <7050000>;
>>>>>>> +				};
>>>>>>
>>>>>> I see another speed of 895 @ turbo_l1, perhaps that's for speedbins
>>>>>> or mobile parts specifically?
>>>>>
>>>>> msm-4.14 defines 7 speedbins for SM6150. Akhil, I don't see any of them
>>>>> here.
>>>>
>>>> The IoT/Auto variants have a different frequency plan compared to the
>>>> mobile variant. I reviewed the downstream code and this aligns with that
>>>> except the 290Mhz corner. We can remove that one.
>>>>
>>>> Here we are describing the IoT variant of Talos. So we can ignore the
>>>> speedbins from the mobile variant until that is supported.
>>>
>>> No, we are describing just Talos, which hopefully covers both mobile and
>>> non-mobile platforms.
>>
>> We cannot assume that.
>>
>> Even if we assume that there is no variation in silicon, the firmware
>> (AOP, TZ, HYP etc) is different between mobile and IoT version. So it is
>> wise to use the configuration that is commercialized, especially when it
>> is power related.
> 
> How does it affect the speed bins? I'd really prefer if we:
> - describe OPP tables and speed bins here
> - remove speed bins cell for the Auto / IoT boards
> - make sure that the driver uses the IoT bin if there is no speed bin
>   declared in the GPU.
> 

The frequency plan is different between mobile and IoT. Are you
proposing to describe a union of OPP table from both mobile and IoT?

Another wrinkle we need to address is that, so far, we have never had a
dt binding where opp-supp-hw property exist without the speedbin cells.
And that adds a bit of complexity on the driver side because, today, the
KMD relies on the presence of speed bin cells to decide whether to
select bin via opp_supp_hw API or not. Also, we may have to reserve this
combination (opp bins without speedbin cells) to help KMD detect that it
should use socinfo APIs instead of speedbin cells on certain chipsets.

-Akhil