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@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. > > > > 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. Also obviously being non-Krzysztof, if we don't have a semantic value for the upper half I'm fine with having the magic value as a single instance instead of spreading it between two places. -- With best wishes Dmitry
