On 24.12.2024 9:51 AM, Krzysztof Kozlowski wrote: > 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@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. > > 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. Yeah I'd much rather have the firmware contain borderline-blob data, but I guess the sw architecture accounts for easier DVFS table replacement instead Konrad
