Message-ID: <8d2092a6-e0c3-49ab-8a3e-64eb9051d353@kernel.org>
Date: Tue, 24 Dec 2024 09:51:17 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Akhil P Oommen <quic_akhilpo@...cinc.com>,
 Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
 Konrad Dybcio <konrad.dybcio@....qualcomm.com>, Rob Herring
 <robh@...nel.org>, Bjorn Andersson <andersson@...nel.org>
Cc: Rob Clark <robdclark@...il.com>, Sean Paul <sean@...rly.run>,
 Konrad Dybcio <konradybcio@...nel.org>,
 Abhinav Kumar <quic_abhinavk@...cinc.com>,
 Marijn Suijten <marijn.suijten@...ainline.org>,
 David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
 Viresh Kumar <vireshk@...nel.org>, Nishanth Menon <nm@...com>,
 Stephen Boyd <sboyd@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, linux-arm-msm@...r.kernel.org,
 dri-devel@...ts.freedesktop.org, freedreno@...ts.freedesktop.org,
 linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
 devicetree@...r.kernel.org
Subject: Re: [PATCH v2 2/3] dt-bindings: opp: Add v2-qcom-adreno vendor
 bindings

On 23/12/2024 22:31, Akhil P Oommen wrote:
> On 12/23/2024 5:24 PM, Dmitry Baryshkov wrote:
>> On Mon, Dec 23, 2024 at 12:31:27PM +0100, Konrad Dybcio wrote:
>>> On 4.12.2024 7:18 PM, Akhil P Oommen wrote:
>>>> On 11/16/2024 1:17 AM, Dmitry Baryshkov wrote:
>>>>> On Fri, 15 Nov 2024 at 19:54, Akhil P Oommen <quic_akhilpo@...cinc.com> wrote:
>>>>>>
>>>>>> On 11/15/2024 3:54 AM, Dmitry Baryshkov wrote:
>>>>>>> Hello Akhil,
>>>>>>>
>>>>>>> On Thu, 14 Nov 2024 at 20:50, Akhil P Oommen <quic_akhilpo@...cinc.com> wrote:
>>>>>>>>
>>>>>>>> On 11/1/2024 9:54 PM, Akhil P Oommen wrote:
>>>>>>>>> On 10/25/2024 11:58 AM, Dmitry Baryshkov wrote:
>>>>>>>>>> On Thu, Oct 24, 2024 at 12:56:58AM +0530, Akhil P Oommen wrote:
>>>>>>>>>>> On 10/22/2024 11:19 AM, Krzysztof Kozlowski wrote:
>>>>>>>>>>>> On Mon, Oct 21, 2024 at 05:23:43PM +0530, Akhil P Oommen wrote:
>>>>>>>>>>>>> Add a new schema which extends opp-v2 to support a new vendor specific
>>>>>>>>>>>>> property required for Adreno GPUs found in Qualcomm's SoCs. The new
>>>>>>>>>>>>> property called "qcom,opp-acd-level" carries a u32 value recommended
>>>>>>>>>>>>> for each opp needs to be shared to GMU during runtime.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cc: Rob Clark <robdclark@...il.com>
>>>>>>>>>>>>> Signed-off-by: Akhil P Oommen <quic_akhilpo@...cinc.com>
>>>>>>>>>>>>> ---
>>>>>>>>>>>>>  .../bindings/opp/opp-v2-qcom-adreno.yaml           | 96 ++++++++++++++++++++++
>>>>>>>>>>>>>  1 file changed, 96 insertions(+)
>>>>>>>>>>>>>
>>>>>>>>>>>>> diff --git a/Documentation/devicetree/bindings/opp/opp-v2-qcom-adreno.yaml b/Documentation/devicetree/bindings/opp/opp-v2-qcom-adreno.yaml
>>>>>>>>>>>>> new file mode 100644
>>>>>>>>>>>>> index 000000000000..6d50c0405ef8
>>>>>>>>>>>>> --- /dev/null
>>>>>>>>>>>>> +++ b/Documentation/devicetree/bindings/opp/opp-v2-qcom-adreno.yaml
>>>>>>>>>>>>> @@ -0,0 +1,96 @@
>>>>>>>>>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>>>>>>>>>>> +%YAML 1.2
>>>>>>>>>>>>> +---
>>>>>>>>>>>>> +$id: http://devicetree.org/schemas/opp/opp-v2-qcom-adreno.yaml#
>>>>>>>>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +title: Qualcomm Adreno compatible OPP supply
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +description:
>>>>>>>>>>>>> +  Adreno GPUs present in Qualcomm's Snapdragon chipsets uses an OPP specific
>>>>>>>>>>>>> +  ACD related information tailored for the specific chipset. This binding
>>>>>>>>>>>>> +  provides the information needed to describe such a hardware value.
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +maintainers:
>>>>>>>>>>>>> +  - Rob Clark <robdclark@...il.com>
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +allOf:
>>>>>>>>>>>>> +  - $ref: opp-v2-base.yaml#
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +properties:
>>>>>>>>>>>>> +  compatible:
>>>>>>>>>>>>> +    items:
>>>>>>>>>>>>> +      - const: operating-points-v2-adreno
>>>>>>>>>>>>> +      - const: operating-points-v2
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +patternProperties:
>>>>>>>>>>>>> +  '^opp-?[0-9]+$':
>>>>>>>>>>>>
>>>>>>>>>>>> '-' should not be optional. opp1 is not expected name.
>>>>>>>>>>>
>>>>>>>>>>> Agree. Will change this to '^opp-[0-9]+$'
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> +    type: object
>>>>>>>>>>>>> +    additionalProperties: false
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +    properties:
>>>>>>>>>>>>> +      opp-hz: true
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +      opp-level: true
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +      opp-peak-kBps: true
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +      opp-supported-hw: true
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +      qcom,opp-acd-level:
>>>>>>>>>>>>> +        description: |
>>>>>>>>>>>>> +          A positive value representing the ACD (Adaptive Clock Distribution,
>>>>>>>>>>>>> +          a fancy name for clk throttling during voltage droop) level associated
>>>>>>>>>>>>> +          with this OPP node. This value is shared to a co-processor inside GPU
>>>>>>>>>>>>> +          (called Graphics Management Unit a.k.a GMU) during wake up. It may not
>>>>>>>>>>>>> +          be present for some OPPs and GMU will disable ACD while transitioning
>>>>>>>>>>>>> +          to that OPP. This value encodes a voltage threshold and few other knobs
>>>>>>>>>>>>> +          which are identified by characterization of the SoC. So, it doesn't have
>>>>>>>>>>>>> +          any unit.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for explanation and other updates. I am still not happy with this
>>>>>>>>>>>> property. I do not see reason why DT should encode magic values in a
>>>>>>>>>>>> quite generic piece of code. This creates poor ABI, difficult to
>>>>>>>>>>>> maintain or understand.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Configuring GPU ACD block with its respective value is a requirement for each OPP.
>>>>>>>>>>> So OPP node seems like the natural place for this data.
>>>>>>>>>>>
>>>>>>>>>>> If it helps to resolve your concerns, I can elaborate the documentation with
>>>>>>>>>>> details on the GMU HFI interface where this value should be passed on to the
>>>>>>>>>>> hardware. Also replace "few other knobs" with "Delay cycles & Calibration margin"
>>>>>>>>>>> in the above doc.
>>>>>>>>>>
>>>>>>>>>> Usually the preference for DT is to specify data in a sensible way
>>>>>>>>>> rather than just the values being programmed to the register. Is it
>>>>>>>>>> possible to implement this approach for ACD values?
>>>>>>>>
>>>>>>>> Krzysztof/Dmitry,
>>>>>>>>
>>>>>>>> BIT(0)-BIT(15) are static configurations which doesn't change between
>>>>>>>> OPPs. We can move it to driver.
>>>>>>>>
>>>>>>>> BIT(16)-BIT(31) indicates a threshold margin which triggers ACD. We can
>>>>>>>> keep this in the devicetree. And the driver can construct the final
>>>>>>>> value from both data and send it to GMU.
>>>>>>>>
>>>>>>>> If this is acceptable, I will send the v3 revision.
>>>>>>>
>>>>>>> Can the upper bitfield have a sensible representation in DT (like uV
>>>>>>> or something similar)?
>>>>>>
>>>>>> Closest approximation is quantized voltage steps. So, unit-less.
>>>>>> Converting it to the exact voltage requires identifying the pmic voltage
>>>>>> steps and other stuffs which are outside of my expertise.
>>>>>>
>>>>>> It is convenient if we can abstract it as an integer which correlates
>>>>>> with the voltage margin that should be maintained for each regulator corner.
>>>>
>>>> Krzysztof,
>>>>
>>>> Could you please confirm if this approach would be acceptable?
>>>>
>>>> To reiterate, move the lower 16 bits which is same across OPPs to the
>>>> driver. Abstract the higher 16 bits as number of quantized voltage
>>>> margin when ACD mitigation gets triggered.
>>>
>>> I know I'm not Krzysztof, but given this is ultimately a magic value
>>> passed to the firmware, I'm a bit lukewarm on decomposing it and would
>>> rather see the entire 32b passed in a property, so that if a future
>>> target needs a different constant in the lower word, we don't have to
>>> pull our hair out again, trying to add more spaghetti logic to account
>>> for that.

I can also imagine future SoC not respecting existing interface and
switching to something new, duplicating the effort. All this is "driven
by downstream" approach... but sure, let's go with existing approach.



Best regards,
Krzysztof

Powered by blists - more mailing lists