linux-kernel - Re: [PATCH v2 2/3] dt-bindings: opp: Add v2-qcom-adreno vendor bindings

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: <CAA8EJppy+V9m-t_qPEJh2iTkC7tyDcf2y8wD9vYoHtFSp=HrkQ@mail.gmail.com>
Date: Fri, 15 Nov 2024 21:47:52 +0200
From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To: Akhil P Oommen <quic_akhilpo@...cinc.com>
Cc: Krzysztof Kozlowski <krzk@...nel.org>, 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>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Bjorn Andersson <andersson@...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 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.

I'd say, this is up to the DT maintainers then.

>
> -Akhil.
>
> >
> >>
> >> -Akhil.
> >>
> >>>
> >>> I am still checking about this. Will get back.
> >>>
> >>> -Akhil
> >>>
> >>>>
> >>>>>
> >>>>>>
> >>>>
> >>>
> >>
> >
> >
>


-- 
With best wishes
Dmitry