On Fri, 15 Nov 2024 at 19:54, Akhil P Oommen <quic_akhilpo@xxxxxxxxxxx> 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@xxxxxxxxxxx> 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@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? > >> > >> 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
