[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0edf6829-3a23-7a75-a225-d69222ae2788@linaro.org>
Date: Fri, 17 Mar 2023 09:32:31 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Konrad Dybcio <konrad.dybcio@...aro.org>,
Will Deacon <will@...nel.org>,
Robin Murphy <robin.murphy@....com>,
Joerg Roedel <joro@...tes.org>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Andy Gross <agross@...nel.org>,
Bjorn Andersson <andersson@...nel.org>
Cc: Marijn Suijten <marijn.suijten@...ainline.org>,
linux-arm-kernel@...ts.infradead.org, iommu@...ts.linux.dev,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: arm-smmu: Document SM61[12]5 GPU SMMU
On 16/03/2023 22:59, Konrad Dybcio wrote:
>
>
> On 16.03.2023 20:29, Krzysztof Kozlowski wrote:
>> On 15/03/2023 11:52, Konrad Dybcio wrote:
>>> Both of these SoCs have a Qualcomm MMU500 implementation of SMMU
>>> in front of their GPUs that expect 3 clocks. Both of them also have
>>> an APPS SMMU that expects no clocks. Remove qcom,sm61[12]5-smmu-500
>>> from the "no clocks" list (intentionally 'breaking' the schema checks
>>> of APPS SMMU, as now it *can* accept clocks - with the current
>>> structure of this file it would have taken a wastefully-long time to
>>> sort this out properly..) and add necessary yaml to describe the
>>> clocks required by the GPU SMMUs.
>>
>>
>>> + properties:
>>> + compatible:
>>> + items:
>>> + - enum:
>>> + - qcom,sm6115-smmu-500
>>> + - qcom,sm6125-smmu-500
>>> + - const: qcom,adreno-smmu
>>> + - const: qcom,smmu-500
>>> + - const: arm,mmu-500
>>
>> If you drop the hunk later (from allOf:if), then what clocks do you
>> expect for non-GPU SMMU?
> Both 6115 and 6125 require no clocks under the APPS (non-GPU) SMMU.
> However, the list below uses a `contains:` which means I'd have
> to add a whole another hunk like
>
> - items:
> - enum:
> - qcom,sm6115-smmu-500
> - qcom,sm6125-smmu-500
> - const: qcom,smmu-500
> - const: arm,mmu-500
>
> and add another level of indentation to the previous one
>
> I figured skipping that was less messy (I think we discussed this
> once as well), but if you prefer to keep it strict, I can.
Nah, ok, it's fine.
Best regards,
Krzysztof
Powered by blists - more mailing lists