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@xxxxxxxxx> > >> Signed-off-by: Akhil P Oommen <quic_akhilpo@xxxxxxxxxxx> > >> --- > >> .../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@xxxxxxxxx> > >> + > >> +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? > > > -- With best wishes Dmitry
