Re: [PATCH 1/4] dt-bindings: display/msm: sm8150-mdss: add DP node
On 27/03/2024 11:11, Krzysztof Kozlowski wrote: > On 26/03/2024 21:02, Dmitry Baryshkov wrote: >> As Qualcomm SM8150 got support for the DisplayPort, add displayport@ >> node as a valid child to the MDSS node. >> >> Signed-off-by: Dmitry Baryshkov >> --- > > Reviewed-by: Krzysztof Kozlowski If there is going to be resend, please switch to "contains" and only sm8150 compatible just like: https://lore.kernel.org/all/20240329-sm6350-dp-v2-2-e46dceb32...@fairphone.com/ (but no need to resend just for that) Best regards, Krzysztof
Re: [PATCH v2 2/3] dt-bindings: display: msm: sm6350-mdss: document DP controller subnode
On 29/03/2024 08:45, Luca Weiss wrote: > Document the displayport controller subnode of the SM6350 MDSS. > > Signed-off-by: Luca Weiss > --- Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH 2/3] dt-bindings: display: panel: visionox, vtdr6130: Add mode property
On 28/03/2024 12:11, Jun Nie wrote: > Add DSI mode property and compression mode property > > Signed-off-by: Jun Nie > --- > .../bindings/display/panel/visionox,vtdr6130.yaml | 8 > 1 file changed, 8 insertions(+) > Please use scripts/get_maintainers.pl to get a list of necessary people and lists to CC. It might happen, that command when run on an older kernel, gives you outdated entries. Therefore please be sure you base your patches on recent Linux kernel. Tools like b4 or scripts/get_maintainer.pl provide you proper list of people, so fix your workflow. Tools might also fail if you work on some ancient tree (don't, instead use mainline), work on fork of kernel (don't, instead use mainline) or you ignore some maintainers (really don't). Just use b4 and everything should be fine, although remember about `b4 prep --auto-to-cc` if you added new patches to the patchset. You missed at least devicetree list (maybe more), so this won't be tested by automated tooling. Performing review on untested code might be a waste of time, thus I will skip this patch entirely till you follow the process allowing the patch to be tested. Please kindly resend and include all necessary To/Cc entries. Best regards, Krzysztof
Re: [PATCH 1/4] dt-bindings: display/msm: sm8150-mdss: add DP node
On 26/03/2024 21:02, Dmitry Baryshkov wrote: > As Qualcomm SM8150 got support for the DisplayPort, add displayport@ > node as a valid child to the MDSS node. > > Signed-off-by: Dmitry Baryshkov > --- Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH 1/4] dt-bindings: display/msm: sm8150-mdss: add DP node
On 27/03/2024 09:52, Dmitry Baryshkov wrote: > On Wed, 27 Mar 2024 at 10:45, Krzysztof Kozlowski > wrote: >> >> On 26/03/2024 21:02, Dmitry Baryshkov wrote: >>> diff --git >>> a/Documentation/devicetree/bindings/display/msm/qcom,sm8150-mdss.yaml >>> b/Documentation/devicetree/bindings/display/msm/qcom,sm8150-mdss.yaml >>> index c0d6a4fdff97..40b077fb20aa 100644 >>> --- a/Documentation/devicetree/bindings/display/msm/qcom,sm8150-mdss.yaml >>> +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8150-mdss.yaml >>> @@ -53,6 +53,16 @@ patternProperties: >>>compatible: >>> const: qcom,sm8150-dpu >>> >>> + "^displayport-controller@[0-9a-f]+$": >>> +type: object >>> +additionalProperties: true >>> + >>> +properties: >>> + compatible: >>> +items: >>> + - const: qcom,sm8150-dp >>> + - const: qcom,sm8350-dp >> >> This does not look right. sm8350 has its own mdss binding file. > > So just a single entry here, even though SM8150 uses fallback compat string? Ah, wait, I misread, I thought it is enum. Best regards, Krzysztof
Re: [RFC PATCH 1/1] dt-bindings: display/msm: gpu: Split Adreno schemas into separate files
On 26/03/2024 21:05, Adam Skladowski wrote: > Split shared schema into per-gen and group adrenos by clocks used. > > Signed-off-by: Adam Skladowski > --- > .../devicetree/bindings/display/msm/gpu.yaml | 317 ++ > .../bindings/display/msm/qcom,adreno-306.yaml | 115 +++ > .../bindings/display/msm/qcom,adreno-330.yaml | 111 ++ > .../bindings/display/msm/qcom,adreno-405.yaml | 135 > .../bindings/display/msm/qcom,adreno-506.yaml | 184 ++ > .../bindings/display/msm/qcom,adreno-530.yaml | 161 + > .../bindings/display/msm/qcom,adreno-540.yaml | 154 + > .../bindings/display/msm/qcom,adreno-6xx.yaml | 160 + > .../display/msm/qcom,adreno-common.yaml | 112 +++ > 9 files changed, 1157 insertions(+), 292 deletions(-) One huge patch of 1150 insertions... please split it, e.g. first move the common parts to common schema and include it in msm/gpu. Then move device by device. > create mode 100644 > Documentation/devicetree/bindings/display/msm/qcom,adreno-306.yaml > create mode 100644 > Documentation/devicetree/bindings/display/msm/qcom,adreno-330.yaml > create mode 100644 > Documentation/devicetree/bindings/display/msm/qcom,adreno-405.yaml > create mode 100644 > Documentation/devicetree/bindings/display/msm/qcom,adreno-506.yaml > create mode 100644 > Documentation/devicetree/bindings/display/msm/qcom,adreno-530.yaml > create mode 100644 > Documentation/devicetree/bindings/display/msm/qcom,adreno-540.yaml > create mode 100644 > Documentation/devicetree/bindings/display/msm/qcom,adreno-6xx.yaml > create mode 100644 > Documentation/devicetree/bindings/display/msm/qcom,adreno-common.yaml > Best regards, Krzysztof
Re: [PATCH 1/4] dt-bindings: display/msm: sm8150-mdss: add DP node
On 26/03/2024 21:02, Dmitry Baryshkov wrote: > diff --git > a/Documentation/devicetree/bindings/display/msm/qcom,sm8150-mdss.yaml > b/Documentation/devicetree/bindings/display/msm/qcom,sm8150-mdss.yaml > index c0d6a4fdff97..40b077fb20aa 100644 > --- a/Documentation/devicetree/bindings/display/msm/qcom,sm8150-mdss.yaml > +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8150-mdss.yaml > @@ -53,6 +53,16 @@ patternProperties: >compatible: > const: qcom,sm8150-dpu > > + "^displayport-controller@[0-9a-f]+$": > +type: object > +additionalProperties: true > + > +properties: > + compatible: > +items: > + - const: qcom,sm8150-dp > + - const: qcom,sm8350-dp This does not look right. sm8350 has its own mdss binding file. Best regards, Krzysztof
Re: [PATCH v2 1/3] dt-bindings: display: msm: dp-controller: document X1E80100 compatible
On 22/02/2024 16:55, Abel Vesa wrote: > Add the X1E80100 to the list of compatibles and document the is-edp > flag. The controllers are expected to operate in DP mode by default, > and this flag can be used to select eDP mode. > > Signed-off-by: Abel Vesa > --- > Documentation/devicetree/bindings/display/msm/dp-controller.yaml | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml > b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml > index ae53cbfb2193..ed11852e403d 100644 > --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml > +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml > @@ -27,6 +27,7 @@ properties: >- qcom,sdm845-dp >- qcom,sm8350-dp >- qcom,sm8650-dp > + - qcom,x1e80100-dp >- items: >- enum: >- qcom,sm8150-dp > @@ -73,6 +74,11 @@ properties: >- description: phy 0 parent >- description: phy 1 parent > > + is-edp: > +$ref: /schemas/types.yaml#/definitions/flag > +description: > + Tells the controller to switch to eDP mode DP controller cannot be edp, so property "is-edp" is confusing. Probably you want to choose some phy mode, so you should rather use "phy-mode" property. I am sure we've been here... Anyway, if you define completely new property without vendor prefix, that's a generic property, so you need to put it in some common schema for all Display Controllers, not only Qualcomm. Best regards, Krzysztof
Re: [PATCH v2 1/3] dt-bindings: display: msm: dp-controller: document X1E80100 compatible
On 24/02/2024 23:34, Dmitry Baryshkov wrote: > On Thu, 22 Feb 2024 at 17:55, Abel Vesa wrote: >> >> Add the X1E80100 to the list of compatibles and document the is-edp >> flag. The controllers are expected to operate in DP mode by default, >> and this flag can be used to select eDP mode. >> >> Signed-off-by: Abel Vesa > > Rob, Krzysztof, Connor, gracious ping for the review. It would be > really nice to merge this patchset during the next cycle. It also > unbreaks several other patches. That's not a netdev... or do you have the same subsystem profile expecting reviews *from everyone* within two days? Best regards, Krzysztof
Re: [PATCH v2 1/7] dt-bindings: clock: Add Qcom QCM2290 GPUCC
On 23/02/2024 22:21, Konrad Dybcio wrote: > Add device tree bindings for graphics clock controller for Qualcomm > Technology Inc's QCM2290 SoCs. > > Signed-off-by: Konrad Dybcio > --- Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH v3 3/7] dt-bindings: arm-smmu: Document SM8650 GPU SMMU
On 16/02/2024 12:03, Neil Armstrong wrote: > Document the GPU SMMU found on the SM8650 platform. > > Signed-off-by: Neil Armstrong > --- > Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH v3 2/7] dt-bindings: arm-smmu: fix SM8[45]50 GPU SMMU if condition
On 16/02/2024 12:03, Neil Armstrong wrote:
> The if condition for the SM8[45]50 GPU SMMU is too large,
> add the other compatible strings to the condition to only
> allow the clocks for the GPU SMMU nodes.
>
> Fixes: 4fff78dc2490 ("dt-bindings: arm-smmu: Document SM8[45]50 GPU SMMU")
> Suggested-by: Dmitry Baryshkov
> Signed-off-by: Neil Armstrong
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
Re: [PATCH] arm64: dts: qcom: sm6115: fix USB PHY configuration
On 20/02/2024 22:23, Konrad Dybcio wrote:
> On 20.02.2024 18:31, Dmitry Baryshkov wrote:
>> The patch adding Type-C support for sm6115 was misapplied. All the
>> orientation switch configuration ended up at the UFS PHY node instead of
>> the USB PHY node. Move the data bits to the correct place.
>>
>> Fixes: a06a2f12f9e2 ("arm64: dts: qcom: qrb4210-rb2: enable USB-C port
>> handling")
>> Signed-off-by: Dmitry Baryshkov
>> ---
>
> So that's why UFS stopped working and I couldn't for the life of
> me guess why..
We discussed such cases in the past, because it is not the first (it's
3rd or 4th within last 1 - 1.5 years). I believe Bjorn should reject
patches which do not apply cleanly and ask to resubmit.
Mis-applied patch might cause issues which are tricky to debug.
Best regards,
Krzysztof
Re: [PATCH v3 1/4] dt-bindings: display/msm: Document the DPU for X1E80100
On 16/02/2024 18:01, Abel Vesa wrote: > Document the DPU for Qualcomm X1E80100 platform in the SM8650 schema, as > they are similar. > > Signed-off-by: Abel Vesa Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH 3/8] dt-bindings: msm: qcom,mdss: Include ommited fam-b compatible
On 21/01/2024 20:41, Adam Skladowski wrote: > During conversion 28nm-hpm-fam-b compat got lost, add it. > > Signed-off-by: Adam Skladowski > --- Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH] dt-bindings: display: msm: sm8650-mdss: Add missing explicit "additionalProperties"
On 02/02/2024 23:23, Rob Herring wrote: > In order to check schemas for missing additionalProperties or > unevaluatedProperties, cases allowing extra properties must be explicit. > > Signed-off-by: Rob Herring > --- > .../devicetree/bindings/display/msm/qcom,sm8650-mdss.yaml | 4 > 1 file changed, 4 insertions(+) > Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH 1/5] dt-bindings: display/msm: document MDSS on X1E80100
On 29/01/2024 14:18, Abel Vesa wrote: > Document the MDSS hardware found on the Qualcomm X1E80100 platform. > > Signed-off-by: Abel Vesa > --- Please document dependencies, including the ones not in the tree this is targeting. You have build failures, so that deserves some note. > .../bindings/display/msm/qcom,x1e80100-mdss.yaml | 249 > + > 1 file changed, 249 insertions(+) > Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH 2/5] dt-bindings: display/msm: Document the DPU for X1E80100
On 29/01/2024 14:18, Abel Vesa wrote: > Document the DPU for Qualcomm X1E80100 platform in the SM8650 schema, as > they are similar. > > Signed-off-by: Abel Vesa > --- > Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git > a/Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml > b/Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml > index a01d15a03317..f84fa6d5e6a2 100644 > --- a/Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml > +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml > @@ -13,7 +13,10 @@ $ref: /schemas/display/msm/dpu-common.yaml# > > properties: >compatible: > -const: qcom,sm8650-dpu > +items: Drop items, it's just "enum :" > + - enum: > + - qcom,sm8650-dpu > + - qcom,x1e80100-dpu Best regards, Krzysztof
Re: [PATCH 5/8] dt-bindings: drm/msm/gpu: Document AON clock for A506/A510
On 21/01/2024 20:41, Adam Skladowski wrote: > Adreno 506(MSM8953) and Adreno 510(MSM8976) require > Always-on branch clock to be enabled, describe it. > > Signed-off-by: Adam Skladowski > --- > Documentation/devicetree/bindings/display/msm/gpu.yaml | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/display/msm/gpu.yaml > b/Documentation/devicetree/bindings/display/msm/gpu.yaml > index b019db954793..9e36f54a5caf 100644 > --- a/Documentation/devicetree/bindings/display/msm/gpu.yaml > +++ b/Documentation/devicetree/bindings/display/msm/gpu.yaml > @@ -133,7 +133,7 @@ allOf: >properties: > clocks: >minItems: 2 > - maxItems: 7 > + maxItems: 8 I would prefer we start enforcing the order. The initial flexibility was because of conversion from the old bindings and dealing with some technical debt, AFAIU. This is requirement of new clock, so maybe better add dedicated if:then case which will be enforcing the order with always-on at the end. Best regards, Krzysztof
Re: [PATCH 3/8] dt-bindings: msm: qcom,mdss: Include ommited fam-b compatible
On 21/01/2024 20:41, Adam Skladowski wrote: > During conversion 28nm-hpm-fam-b compat got lost, add it. Please add Fixes tag and put this commit as first in your patchset or even as separate one. Best regards, Krzysztof
Re: [PATCH 2/8] dt-bindings: dsi-controller-main: Document missing msm8976 compatible
On 21/01/2024 20:41, Adam Skladowski wrote: > When all dsi-ctrl compats were added msm8976 was missed, include it too. > > Signed-off-by: Adam Skladowski > --- Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH v2 1/8] dt-bindings: display: msm: dp: declare compatible string for sm8150
On 11/12/2023 16:44, Dmitry Baryshkov wrote: > Add compatible string for the DisplayPort controller found on the > Qualcomm SM8150 platform. > > Signed-off-by: Dmitry Baryshkov > --- DT list... Best regards, Krzysztof
Re: [PATCH 1/9] dt-bindings: display: msm: dp: declare compatible string for sm8150
On 10/12/2023 00:21, Dmitry Baryshkov wrote: > Add compatible string for the DisplayPort controller found on the > Qualcomm SM8150 platform. > > Signed-off-by: Dmitry Baryshkov > --- Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH 1/9] dt-bindings: display: msm: dp: declare compatible string for sm8150
On 10/12/2023 00:21, Dmitry Baryshkov wrote: > Add compatible string for the DisplayPort controller found on the > Qualcomm SM8150 platform. > > Signed-off-by: Dmitry Baryshkov > --- Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH 1/3] dt-bindings: display: msm: dp-controller: document SM8650 compatible
On 07/12/2023 17:37, Neil Armstrong wrote: > Document the DisplayPort controller found in the Qualcomm SM8650 SoC, > the Controller base addresses and layout differ and thus cannot use > the SM8350 compatible as fallback. > > Signed-off-by: Neil Armstrong > --- Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [Freedreno] [PATCH 1/3] dt-bindings: display/msm: gpu: Allow multiple digits for patchid
On 30/11/2023 21:35, Luca Weiss wrote: > Some GPUs like the Adreno A305B has a patchid higher than 9, in this > case 18. Make sure the regexes can account for that. > > Signed-off-by: Luca Weiss > --- Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [Freedreno] [PATCH v2 02/12] dt-bindings: display: msm: Add reg bus and rotator interconnects
On 27/11/2023 16:28, Konrad Dybcio wrote: > Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there are > other connection paths: > - a path that connects rotator block to the DDR. > - a path that needs to be handled to ensure MDSS register access > functions properly, namely the "reg bus", a.k.a the CPU-MDSS CFG > interconnect. > > Describe these paths to allow using them in device trees and in the > driver. > > Signed-off-by: Dmitry Baryshkov > [Konrad: rework for one vs two MDP paths, update examples] > Signed-off-by: Konrad Dybcio > --- Thanks, looks good. Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [Freedreno] [PATCH v2 01/12] dt-bindings: display: msm: qcm2290-mdss: Use the non-deprecated DSI compat
On 27/11/2023 16:28, Konrad Dybcio wrote:
> The "qcom,dsi-ctrl-6g-qcm2290" has been deprecated in commit 0c0f65c6dd44
> ("dt-bindings: msm: dsi-controller-main: Add compatible strings for every
> current SoC"), but the example hasn't been updated to reflect that.
>
> Fix that.
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
Re: [Freedreno] [PATCH 06/12] dt-bindings: firmware: qcom, scm: Allow interconnect for everyone
On 25/11/2023 15:17, Konrad Dybcio wrote: > Every Qualcomm SoC physically has a "CRYPTO0<->DDR" interconnect lane. > Allow this property to be present, no matter the SoC. > > Signed-off-by: Konrad Dybcio > --- Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [Freedreno] [PATCH 05/12] dt-bindings: interconnect: qcom, msm8998-bwmon: Add QCM2290 bwmon instance
On 25/11/2023 15:17, Konrad Dybcio wrote: > QCM2290 has a single BWMONv4 intance for CPU. Document it. > > Signed-off-by: Konrad Dybcio > --- Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [Freedreno] [PATCH 03/12] dt-bindings: display: msm: qcm2290-mdss: Allow 2 interconnects
On 25/11/2023 15:17, Konrad Dybcio wrote: > In addition to MDP0, the cpu-cfg interconnect is also necessary. > Allow it. > > Signed-off-by: Konrad Dybcio > --- > Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git > a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml > b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml > index 3d82c00a9f85..51f3e9c34dfb 100644 > --- a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml > +++ b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml > @@ -36,10 +36,10 @@ properties: > maxItems: 2 > >interconnects: > -maxItems: 1 > +maxItems: 2 > >interconnect-names: > -maxItems: 1 > +maxItems: 2 You should describe the items in interconnects and interconnect-names in such case. The same for all other variants having two items here. Then this and other such patches should be squashed with previous. Best regards, Krzysztof
Re: [Freedreno] [PATCH 02/12] dt-bindings: display: msm: Add reg bus and rotator interconnects
On 25/11/2023 15:17, Konrad Dybcio wrote: > Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there are > other connection paths: > - a path that connects rotator block to the DDR. > - a path that needs to be handled to ensure MDSS register access > functions properly, namely the "reg bus", a.k.a the CPU-MDSS CFG > interconnect. > > Describe these paths bindings to allow using them in device trees and in > the driver > > Signed-off-by: Dmitry Baryshkov > [Konrad: rework for one vs two MDP paths] > Signed-off-by: Konrad Dybcio > --- Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [Freedreno] [PATCH 01/12] dt-bindings: display: msm: qcm2290-mdss: Use the non-deprecated DSI compat
On 25/11/2023 15:17, Konrad Dybcio wrote:
> The "qcom,dsi-ctrl-6g-qcm2290" has been deprecated in commit 0c0f65c6dd44
> ("dt-bindings: msm: dsi-controller-main: Add compatible strings for every
> current SoC"), but the example hasn't been updated to reflect that.
>
> Fix that.
>
> Fixes: 0c0f65c6dd44 ("dt-bindings: msm: dsi-controller-main: Add compatible
> strings for every current SoC")
> Signed-off-by: Konrad Dybcio
> ---
> Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git
> a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml
> b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml
> index 5ad155612b6c..3d82c00a9f85 100644
> --- a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml
> +++ b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml
> @@ -56,7 +56,9 @@ patternProperties:
>
> properties:
>compatible:
> -const: qcom,dsi-ctrl-6g-qcm2290
> +items:
> + - const: qcom,qcm2290-dsi-ctrl
> + - const: qcom,mdss-dsi-ctrl
You must also update the example here.
Best regards,
Krzysztof
[Freedreno] [PATCH] dt-bindings: display/msm: qcom, sm8150-mdss: correct DSI PHY compatible
Qualcomm SM8150 MDSS comes with a bit different 7nm DSI PHY with its own
compatible. DTS already use it:
sa8155p-adp.dtb: display-subsystem@ae0: phy@ae94400:compatible:0:
'qcom,dsi-phy-7nm' was expected
Signed-off-by: Krzysztof Kozlowski
---
.../devicetree/bindings/display/msm/qcom,sm8150-mdss.yaml | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/msm/qcom,sm8150-mdss.yaml
b/Documentation/devicetree/bindings/display/msm/qcom,sm8150-mdss.yaml
index a2a8be7f64a9..c0d6a4fdff97 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sm8150-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8150-mdss.yaml
@@ -69,7 +69,7 @@ patternProperties:
properties:
compatible:
-const: qcom,dsi-phy-7nm
+const: qcom,dsi-phy-7nm-8150
unevaluatedProperties: false
@@ -247,7 +247,7 @@ examples:
};
dsi0_phy: phy@ae94400 {
-compatible = "qcom,dsi-phy-7nm";
+compatible = "qcom,dsi-phy-7nm-8150";
reg = <0x0ae94400 0x200>,
<0x0ae94600 0x280>,
<0x0ae94900 0x260>;
@@ -318,7 +318,7 @@ examples:
};
dsi1_phy: phy@ae96400 {
-compatible = "qcom,dsi-phy-7nm";
+compatible = "qcom,dsi-phy-7nm-8150";
reg = <0x0ae96400 0x200>,
<0x0ae96600 0x280>,
<0x0ae96900 0x260>;
--
2.34.1
[Freedreno] [PATCH] dt-bindings: display/msm: qcom, sm8250-mdss: add DisplayPort controller node
Document the DisplayPort controller node in MDSS binding, already used
in DTS:
sm8250-xiaomi-elish-boe.dtb: display-subsystem@ae0: Unevaluated
properties are not allowed ('displayport-controller@ae9' was unexpected)
Signed-off-by: Krzysztof Kozlowski
---
.../bindings/display/msm/qcom,sm8250-mdss.yaml | 10 ++
1 file changed, 10 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/msm/qcom,sm8250-mdss.yaml
b/Documentation/devicetree/bindings/display/msm/qcom,sm8250-mdss.yaml
index 994975909fea..51368cda7b2f 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sm8250-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8250-mdss.yaml
@@ -52,6 +52,16 @@ patternProperties:
compatible:
const: qcom,sm8250-dpu
+ "^displayport-controller@[0-9a-f]+$":
+type: object
+additionalProperties: true
+
+properties:
+ compatible:
+items:
+ - const: qcom,sm8250-dp
+ - const: qcom,sm8350-dp
+
"^dsi@[0-9a-f]+$":
type: object
additionalProperties: true
--
2.34.1
Re: [Freedreno] [PATCH 4/8] dt-bindings: display: msm: document the SM8650 Mobile Display Subsystem
On 25/10/2023 09:35, Neil Armstrong wrote: > Document the Mobile Display Subsystem (MDSS) on the SM8650 Platform. > > Signed-off-by: Neil Armstrong > --- > .../bindings/display/msm/qcom,sm8650-mdss.yaml | 322 > + > 1 file changed, 322 insertions(+) > Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [Freedreno] [PATCH 3/8] dt-bindings: display: msm: document the SM8650 DPU
On 25/10/2023 09:35, Neil Armstrong wrote: > Document the DPU Display Controller on the SM8650 Platform. > > Signed-off-by: Neil Armstrong > --- Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [Freedreno] [PATCH 2/8] dt-bindings: display: msm-dsi-controller-main: document the SM8650 DSI Controller
On 25/10/2023 09:35, Neil Armstrong wrote: > Document the DSI Controller on the SM8650 Platform. > > Signed-off-by: Neil Armstrong Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [Freedreno] [PATCH 1/8] dt-bindings: display: msm-dsi-phy-7nm: document the SM8650 DSI PHY
On 25/10/2023 09:34, Neil Armstrong wrote: > Document the DSI PHY on the SM8650 Platform. > > Signed-off-by: Neil Armstrong Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [Freedreno] [PATCH v2 3/6] dt-bindings: display: msm: Add SDM670 MDSS
On 03/10/2023 12:31, Dmitry Baryshkov wrote: >>> +patternProperties: >>> + "^display-controller@[0-9a-f]+$": >>> +type: object >>> +additionalProperties: true >>> + >>> +properties: >>> + compatible: >>> +const: qcom,sdm670-dpu >>> + >>> + "^displayport-controller@[0-9a-f]+$": >>> +type: object >>> +additionalProperties: true >>> + >>> +properties: >>> + compatible: >>> +const: qcom,sdm670-dp >>> + >>> + "^dsi@[0-9a-f]+$": >>> +type: object >>> +additionalProperties: true >>> + >>> +properties: >>> + compatible: >>> +contains: >>> + const: qcom,sdm670-dsi-ctrl >>> + >>> + "^phy@[0-9a-f]+$": >>> +type: object >>> +additionalProperties: true >>> + >>> +properties: >>> + compatible: >>> +const: qcom,dsi-phy-10nm >> >> This does not look right. Why the compatible is generic, not SoC-specific? > > Because for 10nm DSI PHY we don't have SoC-specific compatibles other > than the ugly 8998 compat string. OK. Best regards, Krzysztof
Re: [Freedreno] [PATCH v2 3/6] dt-bindings: display: msm: Add SDM670 MDSS
On 03/10/2023 03:21, Richard Acayan wrote:
> Add documentation for the SDM670 display subsystem, adapted from the
> SDM845 and SM6125 documentation.
>
> Signed-off-by: Richard Acayan
> ---
> .../display/msm/qcom,sdm670-mdss.yaml | 287 ++
> 1 file changed, 287 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/msm/qcom,sdm670-mdss.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/msm/qcom,sdm670-mdss.yaml
> b/Documentation/devicetree/bindings/display/msm/qcom,sdm670-mdss.yaml
> new file mode 100644
> index ..9995b018cd9e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/msm/qcom,sdm670-mdss.yaml
> @@ -0,0 +1,287 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/msm/qcom,sdm670-mdss.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm SDM670 Display MDSS
> +
> +maintainers:
> + - Richard Acayan
> +
> +description:
> + SDM670 MSM Mobile Display Subsystem (MDSS), which encapsulates sub-blocks
> + like DPU display controller, DSI and DP interfaces etc.
> +
> +$ref: /schemas/display/msm/mdss-common.yaml#
> +
> +properties:
> + compatible:
> +const: qcom,sdm670-mdss
> +
> + clocks:
> +items:
> + - description: Display AHB clock from gcc
> + - description: Display core clock
> +
> + clock-names:
> +items:
> + - const: iface
> + - const: core
> +
> + iommus:
> +maxItems: 2
> +
> + interconnects:
> +maxItems: 2
> +
> + interconnect-names:
> +maxItems: 2
> +
> +patternProperties:
> + "^display-controller@[0-9a-f]+$":
> +type: object
> +additionalProperties: true
> +
> +properties:
> + compatible:
> +const: qcom,sdm670-dpu
> +
> + "^displayport-controller@[0-9a-f]+$":
> +type: object
> +additionalProperties: true
> +
> +properties:
> + compatible:
> +const: qcom,sdm670-dp
> +
> + "^dsi@[0-9a-f]+$":
> +type: object
> +additionalProperties: true
> +
> +properties:
> + compatible:
> +contains:
> + const: qcom,sdm670-dsi-ctrl
> +
> + "^phy@[0-9a-f]+$":
> +type: object
> +additionalProperties: true
> +
> +properties:
> + compatible:
> +const: qcom,dsi-phy-10nm
This does not look right. Why the compatible is generic, not SoC-specific?
> +
> +required:
> + - compatible
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +display-subsystem@ae0 {
> +compatible = "qcom,sdm670-mdss";
> +reg = <0x0ae0 0x1000>;
> +reg-names = "mdss";
> +power-domains = < MDSS_GDSC>;
> +
> +clocks = < GCC_DISP_AHB_CLK>,
> + < DISP_CC_MDSS_MDP_CLK>;
> +clock-names = "iface", "core";
> +
> +interrupts = ;
> +interrupt-controller;
> +#interrupt-cells = <1>;
> +
Please add interconnects. They do not have to be 100% exact with DTS
(unless interconnect header is not merged?). This is just an example.
> +iommus = <_smmu 0x880 0x8>,
> + <_smmu 0xc80 0x8>;
> +
> +#address-cells = <1>;
> +#size-cells = <1>;
> +ranges;
> +
Best regards,
Krzysztof
[Freedreno] [PATCH] dt-bindings: display: msm/dp: restrict opp-table to objects
Simple 'opp-table:true' accepts a boolean property as opp-table, so restrict it to object to properly enforce real OPP table nodes. Signed-off-by: Krzysztof Kozlowski --- .../devicetree/bindings/display/msm/dp-controller.yaml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml index a31ec9a4179f..f12558960cd8 100644 --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml @@ -80,7 +80,8 @@ properties: operating-points-v2: true - opp-table: true + opp-table: +type: object power-domains: maxItems: 1 -- 2.34.1
Re: [Freedreno] [PATCH v2 02/14] dt-bindings: display/msm/gmu: Allow passing QMP handle
On 08/08/2023 23:02, Konrad Dybcio wrote: > When booting the GMU, the QMP mailbox should be pinged about some tunables > (e.g. adaptive clock distribution state). To achieve that, a reference to > it is necessary. Allow it and require it with A730. > > Tested-by: Neil Armstrong # on SM8550-QRD > Tested-by: Dmitry Baryshkov # sm8450 > Signed-off-by: Konrad Dybcio > --- > Documentation/devicetree/bindings/display/msm/gmu.yaml | 7 +++ > 1 file changed, 7 insertions(+) Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [Freedreno] [PATCH v2 12/13] dt-bindings: drm/msm/gpu: Extend bindings for chip-id
On 27/07/2023 23:20, Rob Clark wrote:
> From: Rob Clark
>
> Upcoming GPUs use an opaque chip-id for identifying the GPU.
Examples?
Anyway, I think we should insist here of using something human-readable,
even if Qualcomm/Adreno internally use some weird numbers.
>
> Signed-off-by: Rob Clark
> ---
> Documentation/devicetree/bindings/display/msm/gpu.yaml | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/msm/gpu.yaml
> b/Documentation/devicetree/bindings/display/msm/gpu.yaml
> index 58ca8912a8c3..56b9b247e8c2 100644
> --- a/Documentation/devicetree/bindings/display/msm/gpu.yaml
> +++ b/Documentation/devicetree/bindings/display/msm/gpu.yaml
> @@ -13,6 +13,12 @@ maintainers:
> properties:
>compatible:
> oneOf:
> + - description: |
> + The driver is parsing the compat string for Adreno to
> + figure out the chip-id.
> +items:
> + - pattern:
> '^qcom,adreno-[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]$'
{8} should work?
Best regards,
Krzysztof
Re: [Freedreno] [PATCH v2] dt-bindings: qcom: Update RPMHPD entries for some SoCs
On 27/07/2023 14:21, Rohit Agarwal wrote: >>> https://lore.kernel.org/all/1689744162-9421-1-git-send-email-quic_rohia...@quicinc.com/ >> Please mention the dependency in patch changelog ---, so it is obvious >> for people applying it and also for the bot. > Sure. Will send a cover letter for this patch mentioning the changelogs > and will > keep the version as v2 since there no change at all in the patch. There is no need for cover letter for one patch. Best regards, Krzysztof
Re: [Freedreno] [PATCH v2] dt-bindings: qcom: Update RPMHPD entries for some SoCs
On 27/07/2023 13:19, Rohit Agarwal wrote: > > On 7/27/2023 4:46 PM, Rob Herring wrote: >> On Thu, 27 Jul 2023 14:39:13 +0530, Rohit Agarwal wrote: >>> Update the RPMHPD references with new bindings defined in rpmhpd.h >>> for Qualcomm SoCs SM8[2345]50. >>> >>> Signed-off-by: Rohit Agarwal >>> --- >>> Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml | 4 ++-- >>> Documentation/devicetree/bindings/clock/qcom,sm8350-videocc.yaml | 4 ++-- >>> Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml| 4 ++-- >>> Documentation/devicetree/bindings/clock/qcom,sm8450-dispcc.yaml | 4 ++-- >>> Documentation/devicetree/bindings/clock/qcom,sm8450-videocc.yaml | 4 ++-- >>> Documentation/devicetree/bindings/clock/qcom,sm8550-dispcc.yaml | 4 ++-- >>> Documentation/devicetree/bindings/clock/qcom,videocc.yaml | 4 ++-- >>> .../devicetree/bindings/display/msm/qcom,sm8250-dpu.yaml | 4 ++-- >>> .../devicetree/bindings/display/msm/qcom,sm8250-mdss.yaml | 8 >>> >>> .../devicetree/bindings/display/msm/qcom,sm8350-dpu.yaml | 4 ++-- >>> .../devicetree/bindings/display/msm/qcom,sm8350-mdss.yaml | 6 >>> +++--- >>> .../devicetree/bindings/display/msm/qcom,sm8450-dpu.yaml | 4 ++-- >>> .../devicetree/bindings/display/msm/qcom,sm8450-mdss.yaml | 8 >>> >>> .../devicetree/bindings/display/msm/qcom,sm8550-dpu.yaml | 4 ++-- >>> .../devicetree/bindings/display/msm/qcom,sm8550-mdss.yaml | 8 >>> >>> Documentation/devicetree/bindings/media/qcom,sm8250-venus.yaml| 4 ++-- >>> Documentation/devicetree/bindings/mmc/sdhci-msm.yaml | 4 ++-- >>> Documentation/devicetree/bindings/remoteproc/qcom,sm8350-pas.yaml | 6 >>> +++--- >>> 18 files changed, 44 insertions(+), 44 deletions(-) >>> >> My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' >> on your patch (DT_CHECKER_FLAGS is new in v5.13): >> >> yamllint warnings/errors: >> >> dtschema/dtc warnings/errors: >> Documentation/devicetree/bindings/remoteproc/qcom,sm8350-pas.example.dts:21:18: >> fatal error: dt-bindings/power/qcom,rpmhpd.h: No such file or directory >> 21 | #include >>| ^ >> compilation terminated. >> make[2]: *** [scripts/Makefile.lib:419: >> Documentation/devicetree/bindings/remoteproc/qcom,sm8350-pas.example.dtb] >> Error 1 >> make[2]: *** Waiting for unfinished jobs >> make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1500: >> dt_binding_check] Error 2 >> make: *** [Makefile:234: __sub-make] Error 2 >> >> doc reference errors (make refcheckdocs): >> >> See >> https://patchwork.ozlabs.org/project/devicetree-bindings/patch/1690448953-23425-1-git-send-email-quic_rohia...@quicinc.com >> >> The base for the series is generally the latest rc1. A different dependency >> should be noted in *this* patch. >> >> If you already ran 'make dt_binding_check' and didn't see the above >> error(s), then make sure 'yamllint' is installed and dt-schema is up to >> date: >> >> pip3 install dtschema --upgrade >> >> Please check and re-submit after running the above command yourself. Note >> that DT_SCHEMA_FILES can be set to your schema file to speed up checking >> your schema. However, it must be unset to test all examples with your schema. > This should be ignored as the patch that creates the new header is > already applied. > Please follow this series > > https://lore.kernel.org/all/1689744162-9421-1-git-send-email-quic_rohia...@quicinc.com/ Please mention the dependency in patch changelog ---, so it is obvious for people applying it and also for the bot. Best regards, Krzysztof
Re: [Freedreno] [PATCH v6 2/2] arm64: dts: qcom: sdm845-db845c: Mark cont splash memory region as reserved
On 26/07/2023 15:27, Amit Pundir wrote: > Adding a reserved memory region for the framebuffer memory > (the splash memory region set up by the bootloader). > > It fixes a kernel panic (arm-smmu: Unhandled context fault > at this particular memory region) reported on DB845c running > v5.10.y. > > Cc: sta...@vger.kernel.org # v5.10+ > Reviewed-by: Caleb Connolly > Signed-off-by: Amit Pundir > --- Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [Freedreno] [PATCH v5 2/2] arm64: dts: qcom: sdm845-db845c: Mark cont splash memory region as reserved
On 13/07/2023 18:52, Amit Pundir wrote: > Adding a reserved memory region for the framebuffer memory > (the splash memory region set up by the bootloader). > > Signed-off-by: Amit Pundir > --- I think your commit msg misses describing the actual problem, impact to users and finally cc-stable. Best regards, Krzysztof
Re: [Freedreno] [PATCH v5 1/2] dt-bindings: display/msm: mdss-common: add memory-region property
On 13/07/2023 18:52, Amit Pundir wrote: > Add and document the reserved memory region property in the > mdss-common schema. > > For now (sdm845-db845c), it points to a framebuffer memory > region reserved by the bootloader for splash screen. > > Signed-off-by: Amit Pundir > --- Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [Freedreno] [PATCH] dt-bindings: display: msm: sm6125-mdss: drop unneeded status from examples
On 26/07/2023 09:27, Krzysztof Kozlowski wrote: > On 25/07/2023 13:46, Marijn Suijten wrote: >> On 2023-07-25 12:16:10, Krzysztof Kozlowski wrote: >>> Example DTS should not have 'status' property. >>> >>> Signed-off-by: Krzysztof Kozlowski >>> --- >>> .../devicetree/bindings/display/msm/qcom,sm6125-mdss.yaml | 6 -- >> >> This is not needed: it has already been corrected in v3 and v4 of the >> respective series (among other changes) and the patches were only picked >> to a preliminary (draft) pull to get an overview of the outstanding work >> for this subsystem. That branch happens to be included in regular -next >> releases though. >> >> 6.6 drm/msm display pull: >> https://gitlab.freedesktop.org/drm/msm/-/merge_requests/69 >> v3: >> https://lore.kernel.org/linux-arm-msm/20230718-sm6125-dpu-v3-0-6c5a56e99...@somainline.org/ >> v4: >> https://lore.kernel.org/linux-arm-msm/20230723-sm6125-dpu-v4-0-a3f287dd6...@somainline.org/ > > What do you mean? The old code (one I am fixing) is in current next... > > If this was fixed, why next gets some outdated branches of drm next? > Each maintainers next tree is supposed to be fed into the next, without > delays. > Ah, I think I understood - some work in progress was applied to work-in-progress branch of drm/msm and this somehow got pushed to linux-next? How anyone is supposed to work on next branches if they are outdated or have stuff known to be incomplete? Best regards, Krzysztof
Re: [Freedreno] [PATCH] dt-bindings: display: msm: sm6125-mdss: drop unneeded status from examples
On 25/07/2023 13:46, Marijn Suijten wrote: > On 2023-07-25 12:16:10, Krzysztof Kozlowski wrote: >> Example DTS should not have 'status' property. >> >> Signed-off-by: Krzysztof Kozlowski >> --- >> .../devicetree/bindings/display/msm/qcom,sm6125-mdss.yaml | 6 -- > > This is not needed: it has already been corrected in v3 and v4 of the > respective series (among other changes) and the patches were only picked > to a preliminary (draft) pull to get an overview of the outstanding work > for this subsystem. That branch happens to be included in regular -next > releases though. > > 6.6 drm/msm display pull: > https://gitlab.freedesktop.org/drm/msm/-/merge_requests/69 > v3: > https://lore.kernel.org/linux-arm-msm/20230718-sm6125-dpu-v3-0-6c5a56e99...@somainline.org/ > v4: > https://lore.kernel.org/linux-arm-msm/20230723-sm6125-dpu-v4-0-a3f287dd6...@somainline.org/ What do you mean? The old code (one I am fixing) is in current next... If this was fixed, why next gets some outdated branches of drm next? Each maintainers next tree is supposed to be fed into the next, without delays. Best regards, Krzysztof
[Freedreno] [PATCH] dt-bindings: display: msm: sm6125-mdss: drop unneeded status from examples
Example DTS should not have 'status' property.
Signed-off-by: Krzysztof Kozlowski
---
.../devicetree/bindings/display/msm/qcom,sm6125-mdss.yaml | 6 --
1 file changed, 6 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/msm/qcom,sm6125-mdss.yaml
b/Documentation/devicetree/bindings/display/msm/qcom,sm6125-mdss.yaml
index 2525482424cb..479c82e6a0d8 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sm6125-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6125-mdss.yaml
@@ -95,8 +95,6 @@ examples:
#size-cells = <1>;
ranges;
-status = "disabled";
-
display-controller@5e01000 {
compatible = "qcom,sm6125-dpu";
reg = <0x05e01000 0x83208>,
@@ -170,8 +168,6 @@ examples:
#address-cells = <1>;
#size-cells = <0>;
-status = "disabled";
-
ports {
#address-cells = <1>;
#size-cells = <0>;
@@ -210,8 +206,6 @@ examples:
required-opps = <_opp_svs>;
power-domains = < SM6125_VDDMX>;
-
-status = "disabled";
};
};
...
--
2.34.1
Re: [Freedreno] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
On 12/07/2023 20:31, Sean Paul wrote: >>> 216 struct drm_device *ddev >>> 234 struct drm_device *drm_dev >>> 611 struct drm_device *drm >>>4190 struct drm_device *dev >>> >>> This series starts with renaming struct drm_crtc::dev to drm_dev. If >>> it's not only me and others like the result of this effort it should be >>> followed up by adapting the other structs and the individual usages in >>> the different drivers. >> >> I think this is an unnecessary change. In drm, a dev is usually a drm >> device, i.e. struct drm_device *. As shown by the numbers above. >> > > I'd really prefer this patch (series or single) is not accepted. This > will cause problems for everyone cherry-picking patches to a > downstream kernel (LTS or distro tree). I usually wouldn't expect > sympathy here, but the questionable benefit does not outweigh the cost > IM[biased]O. You know, every code cleanup and style adjustment is interfering with backporting. The only argument for a fast-pacing kernel should be whether the developers of this code find it more readable with such cleanup. Best regards, Krzysztof
Re: [Freedreno] [PATCH v2 1/8] dt-bindings: display/msm: Add reg bus and rotator interconnects
On 12/07/2023 14:11, Dmitry Baryshkov wrote: > From: Konrad Dybcio > > Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there are > other connection paths: > - a path that connects rotator block to the DDR. > - a path that needs to be handled to ensure MDSS register access > functions properly, namely the "reg bus", a.k.a the CPU-MDSS CFG > interconnect. > > Describe these paths bindings to allow using them in device trees and in > the driver > > Signed-off-by: Konrad Dybcio > Signed-off-by: Dmitry Baryshkov Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [Freedreno] [PATCH 1/2] dt-bindings: display/msm: qcom, sdm845-mdss: add memory-region property
On 12/07/2023 15:02, Amit Pundir wrote: > Add and document the reserved memory region property > in the qcom,sdm845-mdss schema. > > Signed-off-by: Amit Pundir Please keep consistent versioning, so this is new patch in v4. > --- > .../devicetree/bindings/display/msm/qcom,sdm845-mdss.yaml| 5 + > 1 file changed, 5 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/msm/qcom,sdm845-mdss.yaml > b/Documentation/devicetree/bindings/display/msm/qcom,sdm845-mdss.yaml > index 6ecb00920d7f..3ea1dbd7e317 100644 > --- a/Documentation/devicetree/bindings/display/msm/qcom,sdm845-mdss.yaml > +++ b/Documentation/devicetree/bindings/display/msm/qcom,sdm845-mdss.yaml > @@ -39,6 +39,11 @@ properties: >interconnect-names: > maxItems: 2 > > + memory-region: > +maxItems: 1 > +description: > + Phandle to a node describing a reserved memory region. Your description says nothing new. It's entirely redundant/obvious. Instead please describe what reserved memory is expected to be here. Best regards, Krzysztof
Re: [Freedreno] [PATCH 1/5] dt-bindings: display: msm: dp-controller: document SM8250 compatible
On 09/07/2023 06:19, Dmitry Baryshkov wrote: > It looks like DP controlled on SM8250 is the same as DP controller on > SM8350. Use the SM8350 compatible as fallback for SM8250. > > Signed-off-by: Dmitry Baryshkov > --- Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [Freedreno] [PATCH 11/12] dt-bindings: drm/msm/gpu: Extend bindings for chip-id
On 06/07/2023 23:10, Rob Clark wrote: > From: Rob Clark > > Upcoming GPUs use an opaque chip-id for identifying the GPU. Please use scripts/get_maintainers.pl to get a list of necessary people and lists to CC. It might happen, that command when run on an older kernel, gives you outdated entries. Therefore please be sure you base your patches on recent Linux kernel. You missed at least DT list (maybe more), so this won't be tested by automated tooling. Performing review on untested code might be a waste of time, thus I will skip this patch entirely till you follow the process allowing the patch to be tested. Please kindly resend and include all necessary To/Cc entries. Best regards, Krzysztof
Re: [Freedreno] [PATCH 03/14] dt-bindings: display/msm/gpu: Allow A7xx SKUs
On 28/06/2023 22:35, Konrad Dybcio wrote: > Allow A7xx SKUs, such as the A730 GPU found on SM8450 and friends. > They use GMU for all things DVFS, just like most A6xx GPUs. > > Signed-off-by: Konrad Dybcio > --- Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [Freedreno] [PATCH 02/14] dt-bindings: display/msm/gmu: Allow passing QMP handle
On 28/06/2023 22:35, Konrad Dybcio wrote: > When booting the GMU, the QMP mailbox should be pinged about some tunables > (e.g. adaptive clock distribution state). To achieve that, a reference to > it is necessary. Allow it and require it with A730. > > Signed-off-by: Konrad Dybcio > --- > Documentation/devicetree/bindings/display/msm/gmu.yaml | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/Documentation/devicetree/bindings/display/msm/gmu.yaml > b/Documentation/devicetree/bindings/display/msm/gmu.yaml > index 20ddb89a4500..9e6c4e0ab071 100644 > --- a/Documentation/devicetree/bindings/display/msm/gmu.yaml > +++ b/Documentation/devicetree/bindings/display/msm/gmu.yaml > @@ -64,6 +64,10 @@ properties: >iommus: > maxItems: 1 > > + qcom,qmp: > +$ref: /schemas/types.yaml#/definitions/phandle > +description: Phandle to the QMP mailbox mailbox would suggest you should use mailbox properties. Instead maybe "Always On Subsystem (AOSS)" or just use existing description. I assume it's exactly the same. Best regards, Krzysztof
Re: [Freedreno] [PATCH 01/14] dt-bindings: display/msm/gmu: Add Adreno 7[34]0 GMU
On 28/06/2023 22:35, Konrad Dybcio wrote: > The GMU on the A7xx series is pretty much the same as on the A6xx parts. > It's now "smarter", needs a bit less register writes and controls more > things (like inter-frame power collapse) mostly internally (instead of > us having to write to G[PM]U_[CG]X registers from APPS) > > The only difference worth mentioning is the now-required DEMET clock, > which is strictly required for things like asserting reset lines, not > turning it on results in GMU not being fully functional (all OOB requests > would fail and HFI would hang after the first submitted OOB). > > Describe the A730 and A740 GMU. > Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
[Freedreno] [PATCH] dt-bindings: cleanup DTS example whitespaces
The DTS code coding style expects spaces around '=' sign.
Signed-off-by: Krzysztof Kozlowski
---
Rob,
Maybe this could go via your tree? Rebased on your for-next:
v6.4-rc2-45-gf0ac35049606
---
.../bindings/arm/arm,coresight-cti.yaml| 18 +-
.../bindings/arm/keystone/ti,sci.yaml | 8
.../devicetree/bindings/display/msm/gmu.yaml | 2 +-
.../display/panel/samsung,s6e8aa0.yaml | 2 +-
.../display/rockchip/rockchip-vop.yaml | 4 ++--
.../bindings/iio/adc/ti,adc108s102.yaml| 2 +-
.../bindings/media/renesas,rzg2l-cru.yaml | 4 ++--
.../devicetree/bindings/media/renesas,vin.yaml | 4 ++--
.../devicetree/bindings/mtd/mtd-physmap.yaml | 2 +-
.../bindings/net/mediatek-dwmac.yaml | 2 +-
.../bindings/perf/amlogic,g12-ddr-pmu.yaml | 4 ++--
.../bindings/phy/mediatek,dsi-phy.yaml | 2 +-
.../remoteproc/amlogic,meson-mx-ao-arc.yaml| 2 +-
.../devicetree/bindings/usb/mediatek,mtu3.yaml | 2 +-
.../devicetree/bindings/usb/ti,am62-usb.yaml | 2 +-
15 files changed, 30 insertions(+), 30 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml
b/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml
index 0c5b875cb654..d6c84b6e7fe6 100644
--- a/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml
+++ b/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml
@@ -287,7 +287,7 @@ examples:
arm,trig-in-sigs = <0 1>;
arm,trig-in-types = ;
-arm,trig-out-sigs=<0 1 2 >;
+arm,trig-out-sigs = <0 1 2 >;
arm,trig-out-types = ;
@@ -309,24 +309,24 @@ examples:
trig-conns@0 {
reg = <0>;
-arm,trig-in-sigs=<0>;
-arm,trig-in-types=;
-arm,trig-out-sigs=<0>;
-arm,trig-out-types=;
+arm,trig-in-sigs = <0>;
+arm,trig-in-types = ;
+arm,trig-out-sigs = <0>;
+arm,trig-out-types = ;
arm,trig-conn-name = "sys_profiler";
};
trig-conns@1 {
reg = <1>;
-arm,trig-out-sigs=<2 3>;
-arm,trig-out-types=;
+arm,trig-out-sigs = <2 3>;
+arm,trig-out-types = ;
arm,trig-conn-name = "watchdog";
};
trig-conns@2 {
reg = <2>;
-arm,trig-in-sigs=<1 6>;
-arm,trig-in-types=;
+arm,trig-in-sigs = <1 6>;
+arm,trig-in-types = ;
arm,trig-conn-name = "g_counter";
};
};
diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
index 91b96065f7df..86b59de7707e 100644
--- a/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
+++ b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
@@ -96,8 +96,8 @@ examples:
compatible = "ti,k2g-sci";
ti,system-reboot-controller;
mbox-names = "rx", "tx";
- mboxes= < 5 2>,
- < 0 0>;
+ mboxes = < 5 2>,
+ < 0 0>;
reg-names = "debug_messages";
reg = <0x02921800 0x800>;
};
@@ -107,8 +107,8 @@ examples:
compatible = "ti,k2g-sci";
ti,host-id = <12>;
mbox-names = "rx", "tx";
- mboxes= <_proxy_main 11>,
- <_proxy_main 13>;
+ mboxes = <_proxy_main 11>,
+ <_proxy_main 13>;
reg-names = "debug_messages";
reg = <0x44083000 0x1000>;
diff --git a/Documentation/devicetree/bindings/display/msm/gmu.yaml
b/Documentation/devicetree/bindings/display/msm/gmu.yaml
index 029d72822d8b..65b02c7a1211 100644
--- a/Documentation/devicetree/bindings/display/msm/gmu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/gmu.yaml
@@ -225,7 +225,7 @@ examples:
#include
gmu: gmu@506a000 {
-compatible="qcom,adreno-gmu-630.2", "qcom,adreno-gmu";
+compatible = "qcom,adreno-gmu-630.2", "qcom,adreno-gmu";
reg = <0x506a000 0x3>,
<0xb28 0x1>,
diff --git
a/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.yaml
b/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.yaml
index 1cdc91b3439f..200fbf1c74a0 100644
--- a/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.yaml
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.yaml
@@ -74,7 +74,7 @@ examples:
vdd3-supply = <_reg>;
vci-supply = <_reg>;
reset-gpios = < 5 0>;
-power-on-delay= <50>;
+power-on-delay = <50>;
reset-delay = <100>;
init-delay = <100>;
panel-width-m
Re: [Freedreno] [PATCH 03/15] dt-bindings: clock: qcom, dispcc-sm6125: Require GCC PLL0 DIV clock
On 27/06/2023 11:02, Marijn Suijten wrote: > So deleting a new item at the end does not matter. But what if I respin > this patch to add the new clock _at the end_, which will then be at the > same index as the previous GCC_DISP_AHB_CLK? I think you know the answer, right? What do you want to prove? That two independent changes can have together negative effect? We know this. >>> >>> The question is whether this is allowed? >> >> That would be an ABI break and I already explained if it is or is not >> allowed. > > How should we solve it then, if we cannot remove GCC_DISP_AHB_CLK in one > patch and add GCC_DISP_GPLL0_DIV_CLK_SRC **at the end** in the next > patch? Keep an empty spot at the original index of GCC_DISP_AHB_CLK? I don't know if you are trolling me or really asking question, so just in case it is the latter: "No one is locked into the ABI. SoC maintainer decides on this. " Also: https://lore.kernel.org/linux-arm-msm/20230608152759.ga2721945-r...@kernel.org/ https://lore.kernel.org/linux-arm-msm/cal_jsqkoq+pdjupvyqdc7qcjgxp-kbag_o9e+zrfy7k-wrr...@mail.gmail.com/ https://lore.kernel.org/linux-arm-msm/20220602143245.ga2256965-r...@kernel.org/ https://lore.kernel.org/linux-arm-msm/20220601202452.ga365963-r...@kernel.org/ Any many more. Best regards, Krzysztof
Re: [Freedreno] [PATCH 03/15] dt-bindings: clock: qcom, dispcc-sm6125: Require GCC PLL0 DIV clock
On 27/06/2023 09:49, Marijn Suijten wrote: > On 2023-06-27 09:29:53, Krzysztof Kozlowski wrote: >> On 27/06/2023 08:54, Marijn Suijten wrote: >>> On 2023-06-27 08:24:41, Krzysztof Kozlowski wrote: >>>> On 26/06/2023 20:53, Marijn Suijten wrote: >>>>> On 2023-06-26 20:51:38, Marijn Suijten wrote: >>>>> >>>>>>> Not really, binding also defines the list of clocks - their order and >>>>>>> specific entries. This changes. >>>>>> >>>>>> And so it does in "dt-bindings: clock: qcom,dispcc-sm6125: Remove unused >>>>>> GCC_DISP_AHB_CLK"? >>>>> >>>>> Never mind: it is the last item so the order of the other items doesn't >>>>> change. The total number of items decreases though, which sounds like >>>>> an ABI-break too? >>>> >>>> How does it break? Old DTS works exactly the same, doesn't it? >>> >>> So deleting a new item at the end does not matter. But what if I respin >>> this patch to add the new clock _at the end_, which will then be at the >>> same index as the previous GCC_DISP_AHB_CLK? >> >> I think you know the answer, right? What do you want to prove? That two >> independent changes can have together negative effect? We know this. > > The question is whether this is allowed? That would be an ABI break and I already explained if it is or is not allowed. Best regards, Krzysztof
Re: [Freedreno] [PATCH 03/15] dt-bindings: clock: qcom, dispcc-sm6125: Require GCC PLL0 DIV clock
On 27/06/2023 08:54, Marijn Suijten wrote: > On 2023-06-27 08:24:41, Krzysztof Kozlowski wrote: >> On 26/06/2023 20:53, Marijn Suijten wrote: >>> On 2023-06-26 20:51:38, Marijn Suijten wrote: >>> >>>>> Not really, binding also defines the list of clocks - their order and >>>>> specific entries. This changes. >>>> >>>> And so it does in "dt-bindings: clock: qcom,dispcc-sm6125: Remove unused >>>> GCC_DISP_AHB_CLK"? >>> >>> Never mind: it is the last item so the order of the other items doesn't >>> change. The total number of items decreases though, which sounds like >>> an ABI-break too? >> >> How does it break? Old DTS works exactly the same, doesn't it? > > So deleting a new item at the end does not matter. But what if I respin > this patch to add the new clock _at the end_, which will then be at the > same index as the previous GCC_DISP_AHB_CLK? I think you know the answer, right? What do you want to prove? That two independent changes can have together negative effect? We know this. Best regards, Krzysztof
Re: [Freedreno] [PATCH 03/15] dt-bindings: clock: qcom, dispcc-sm6125: Require GCC PLL0 DIV clock
On 26/06/2023 20:53, Marijn Suijten wrote: > On 2023-06-26 20:51:38, Marijn Suijten wrote: > >>> Not really, binding also defines the list of clocks - their order and >>> specific entries. This changes. >> >> And so it does in "dt-bindings: clock: qcom,dispcc-sm6125: Remove unused >> GCC_DISP_AHB_CLK"? > > Never mind: it is the last item so the order of the other items doesn't > change. The total number of items decreases though, which sounds like > an ABI-break too? How does it break? Old DTS works exactly the same, doesn't it? Best regards, Krzysztof
Re: [Freedreno] [PATCH 03/15] dt-bindings: clock: qcom, dispcc-sm6125: Require GCC PLL0 DIV clock
On 26/06/2023 19:49, Marijn Suijten wrote:
> On 2023-06-26 18:10:44, Krzysztof Kozlowski wrote:
>> On 25/06/2023 21:48, Marijn Suijten wrote:
>>> On 2023-06-24 11:08:54, Krzysztof Kozlowski wrote:
>>>> On 24/06/2023 03:45, Konrad Dybcio wrote:
>>>>> On 24.06.2023 02:41, Marijn Suijten wrote:
>>>>>> The "gcc_disp_gpll0_div_clk_src" clock is consumed by the driver, will
>>>>>> be passed from DT, and should be required by the bindings.
>>>>>>
>>>>>> Fixes: 8397c9c0c26b ("dt-bindings: clock: add QCOM SM6125 display clock
>>>>>> bindings")
>>>>>> Signed-off-by: Marijn Suijten
>>>>>> ---
>>>>> Ideally, you'd stick it at the bottom of the list, as the items: order
>>>>> is part of the ABI
>>>>
>>>> Yes, please add them to the end. Order is fixed.
>>>
>>> Disagreed for bindings that declare clock-names and when the driver
>>> adheres to it, see my reply to Konrad's message.
>>
>> That's the generic rule, with some exceptions of course. Whether one
>> chosen driver (chosen system and chosen version of that system) adheres
>> or not, does not change it. Other driver behaves differently and ABI is
>> for everyone, not only for your specific version of Linux driver.
>>
>> Follow the rule.
>
> This has no relation to the driver (just that our driver adheres to the
> bindings, as it is supposed to be). The bindings define a mapping from
> a clock-names=<> entry to a clock on the same index in the clocks=<>
> array. That relation remains the same with this change.
Not really, binding also defines the list of clocks - their order and
specific entries. This changes.
Best regards,
Krzysztof
Re: [Freedreno] [PATCH 06/15] dt-bindings: display/msm: sc7180-dpu: Describe SM6125
On 25/06/2023 21:52, Marijn Suijten wrote:
> On 2023-06-24 11:12:52, Krzysztof Kozlowski wrote:
>> On 24/06/2023 02:41, Marijn Suijten wrote:
>>> SM6125 is identical to SM6375 except that while downstream also defines
>>> a throttle clock, its presence results in timeouts whereas SM6375
>>> requires it to not observe any timeouts.
>>
>> Then it should not be allowed, so you need either "else:" block or
>> another "if: properties: compatible:" to disallow it. Because in current
>> patch it would be allowed.
>
> That means this binding is wrong/incomplete for all other SoCs then.
> clock(-name)s has 6 items, and sets `minItems: 6`. Only for sm6375-dpu
> does it set `minItems: 7`, but an else case is missing.
Ask the author why it is done like this.
>
> Shall I send a Fixes: ed41005f5b7c ("dt-bindings: display/msm:
> sc7180-dpu: Describe SM6350 and SM6375") for that, and should maxItems:
> 6 be the default under clock(-name)s or in an else:?
There is no bug to fix. Or at least it is not yet known. Whether other
devices should be constrained as well - sure, sounds reasonable, but I
did not check the code exactly.
We talk here about this patch.
Best regards,
Krzysztof
Re: [Freedreno] [PATCH 03/15] dt-bindings: clock: qcom, dispcc-sm6125: Require GCC PLL0 DIV clock
On 26/06/2023 16:26, Marijn Suijten wrote:
> On 2023-06-26 11:43:39, Konrad Dybcio wrote:
>> On 25.06.2023 21:48, Marijn Suijten wrote:
>>> On 2023-06-24 03:45:02, Konrad Dybcio wrote:
On 24.06.2023 02:41, Marijn Suijten wrote:
> The "gcc_disp_gpll0_div_clk_src" clock is consumed by the driver, will
> be passed from DT, and should be required by the bindings.
>
> Fixes: 8397c9c0c26b ("dt-bindings: clock: add QCOM SM6125 display clock
> bindings")
> Signed-off-by: Marijn Suijten
> ---
Ideally, you'd stick it at the bottom of the list, as the items: order
is part of the ABI
>>>
>>> This isn't an ABI break, as this driver nor its bindings require/declare
>>> a fixed order: they declare a relation between clocks and clock-names.
>> Bindings describe the ABI, drivers implement compliant code flow.
>
> That is how bindings are supposed to be... However typically the driver
> is written/ported first and then the bindings are simply created to
Your development process does not matter for the bindings. Whatever you
decide to do "typically" is your choice, although of course I understand
why you do it like that. You can argument the same that "I never create
bindings in my process, so the driver defines the ABI".
> reflect this, and sometimes (as is the case with this patch)
> incorrectly.
>
> That, together with a lack of DTS and known-working device with it
> (which is why I'm submitting driver+bindings+dts in one series now!)
> makes us shoot ourselves in the foot by locking everyone into an ABI
> that makes no sense.
No one is locked into the ABI. SoC maintainer decides on this. However
unjustified ABI breaking or not caring about it at all is not the way to
go. It is not the correct process.
>
>>> This orders the GCC clock just like other dispccs. And the previous
>>> patch dropped the unused cfg_ahb_clk from the bindings, so all bets are
>>> off anyway.
>> Thinking about it again, the binding has not been consumed by any upstream
>> DT to date, so it should (tm) be fine to let it slide..
>
> Exactly, I hope/doubt anyone was already using these incomplete
> bindings. And again: the ABI here is the name->phandle mapping, the
> order Does Not Matter™.
No, it's not. Your one driver does not define the ABI. There are many
different drivers, many different operating systems and other software
components.
Best regards,
Krzysztof
Re: [Freedreno] [PATCH 03/15] dt-bindings: clock: qcom, dispcc-sm6125: Require GCC PLL0 DIV clock
On 25/06/2023 21:48, Marijn Suijten wrote:
> On 2023-06-24 11:08:54, Krzysztof Kozlowski wrote:
>> On 24/06/2023 03:45, Konrad Dybcio wrote:
>>> On 24.06.2023 02:41, Marijn Suijten wrote:
>>>> The "gcc_disp_gpll0_div_clk_src" clock is consumed by the driver, will
>>>> be passed from DT, and should be required by the bindings.
>>>>
>>>> Fixes: 8397c9c0c26b ("dt-bindings: clock: add QCOM SM6125 display clock
>>>> bindings")
>>>> Signed-off-by: Marijn Suijten
>>>> ---
>>> Ideally, you'd stick it at the bottom of the list, as the items: order
>>> is part of the ABI
>>
>> Yes, please add them to the end. Order is fixed.
>
> Disagreed for bindings that declare clock-names and when the driver
> adheres to it, see my reply to Konrad's message.
That's the generic rule, with some exceptions of course. Whether one
chosen driver (chosen system and chosen version of that system) adheres
or not, does not change it. Other driver behaves differently and ABI is
for everyone, not only for your specific version of Linux driver.
Follow the rule.
Best regards,
Krzysztof
Re: [Freedreno] [PATCH 10/15] dt-bindings: msm: dsi-phy-14nm: Document SM6125 variant
On 24/06/2023 15:48, Dmitry Baryshkov wrote: > On 24/06/2023 03:41, Marijn Suijten wrote: >> Document availability of the 14nm DSI PHY on SM6125. >> >> Signed-off-by: Marijn Suijten >> --- >> Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml >> b/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml >> index a43e11d3b00d..60b590f21138 100644 >> --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml >> +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml >> @@ -18,6 +18,7 @@ properties: >> - qcom,dsi-phy-14nm >> - qcom,dsi-phy-14nm-2290 >> - qcom,dsi-phy-14nm-660 >> + - qcom,dsi-phy-14nm-6125 > > Should we start using standard scheme, so "qcom,sm6125-dsi-phy-14nm" ? I guess the earlier the better. Best regards, Krzysztof
Re: [Freedreno] [PATCH 10/15] dt-bindings: msm: dsi-phy-14nm: Document SM6125 variant
On 24/06/2023 02:41, Marijn Suijten wrote: > Document availability of the 14nm DSI PHY on SM6125. > > Signed-off-by: Marijn Suijten > --- > Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml > b/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml > index a43e11d3b00d..60b590f21138 100644 > --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml > +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml > @@ -18,6 +18,7 @@ properties: >- qcom,dsi-phy-14nm >- qcom,dsi-phy-14nm-2290 >- qcom,dsi-phy-14nm-660 > + - qcom,dsi-phy-14nm-6125 If there is going to be next version: Should be rather ordered alphanumeric, so before 660. Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [Freedreno] [PATCH 07/15] dt-bindings: display/msm: Add SM6125 MDSS
On 24/06/2023 02:41, Marijn Suijten wrote: > Document the SM6125 MDSS. > > Signed-off-by: Marijn Suijten > --- Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [Freedreno] [PATCH 06/15] dt-bindings: display/msm: sc7180-dpu: Describe SM6125
On 24/06/2023 02:41, Marijn Suijten wrote: > SM6125 is identical to SM6375 except that while downstream also defines > a throttle clock, its presence results in timeouts whereas SM6375 > requires it to not observe any timeouts. Then it should not be allowed, so you need either "else:" block or another "if: properties: compatible:" to disallow it. Because in current patch it would be allowed. Best regards, Krzysztof
Re: [Freedreno] [PATCH 05/15] dt-bindings: display/msm: dsi-controller-main: Document SM6125
On 24/06/2023 02:41, Marijn Suijten wrote: > Document general compatibility of the DSI controller on SM6125. > > Signed-off-by: Marijn Suijten > --- > Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml | 2 ++ > 1 file changed, 2 insertions(+) Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [Freedreno] [PATCH 04/15] dt-bindings: clock: qcom, dispcc-sm6125: Allow power-domains property
On 24/06/2023 02:41, Marijn Suijten wrote: > On SM6125 the dispcc block is gated behind VDDCX: allow this domain to > be configured. > > Signed-off-by: Marijn Suijten > --- > Documentation/devicetree/bindings/clock/qcom,dispcc-sm6125.yaml | 5 + > 1 file changed, 5 insertions(+) Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [Freedreno] [PATCH 03/15] dt-bindings: clock: qcom, dispcc-sm6125: Require GCC PLL0 DIV clock
On 24/06/2023 03:45, Konrad Dybcio wrote:
> On 24.06.2023 02:41, Marijn Suijten wrote:
>> The "gcc_disp_gpll0_div_clk_src" clock is consumed by the driver, will
>> be passed from DT, and should be required by the bindings.
>>
>> Fixes: 8397c9c0c26b ("dt-bindings: clock: add QCOM SM6125 display clock
>> bindings")
>> Signed-off-by: Marijn Suijten
>> ---
> Ideally, you'd stick it at the bottom of the list, as the items: order
> is part of the ABI
Yes, please add them to the end. Order is fixed.
Best regards,
Krzysztof
Re: [Freedreno] [PATCH 02/15] dt-bindings: clock: qcom, dispcc-sm6125: Remove unused GCC_DISP_AHB_CLK
On 24/06/2023 02:41, Marijn Suijten wrote:
> The downsteam driver for dispcc only ever gets and puts this clock
> without ever using it in the clocktree; this unnecessary workaround was
> never ported to mainline, hence the driver doesn't consume this clock
> and shouldn't be required by the bindings.
>
> Fixes: 8397c9c0c26b ("dt-bindings: clock: add QCOM SM6125 display clock
> bindings")
> Signed-off-by: Marijn Suijten
> ---
In perfect would we would like to know whether hardware needs this clock
enabled/controlled, not whether some driver needs it. I understand
though that with lack of proper docs we rely on drivers, so:
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
Re: [Freedreno] [PATCH v6 05/12] dt-bindings: display/msm: Add SM6375 MDSS
On 06/06/2023 14:43, Konrad Dybcio wrote: > Document the SM6375 MDSS. > > Signed-off-by: Konrad Dybcio > --- > .../bindings/display/msm/qcom,sm6375-mdss.yaml | 215 > + > 1 file changed, 215 insertions(+) > Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [Freedreno] [PATCH v6 04/12] dt-bindings: display/msm: Add SM6350 MDSS
On 06/06/2023 14:43, Konrad Dybcio wrote: > Document the SM6350 MDSS. > > Signed-off-by: Konrad Dybcio > --- > .../bindings/display/msm/qcom,sm6350-mdss.yaml | 213 > + > 1 file changed, 213 insertions(+) > Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [Freedreno] [PATCH v5 04/12] dt-bindings: display/msm: Add SM6350 MDSS
On 23/05/2023 09:46, Konrad Dybcio wrote: > Document the SM6350 MDSS. > > Signed-off-by: Konrad Dybcio > --- > .../bindings/display/msm/qcom,sm6350-mdss.yaml | 214 > + > 1 file changed, 214 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml > b/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml > new file mode 100644 > index ..6674040d2172 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml > @@ -0,0 +1,214 @@ > +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/msm/qcom,sm6350-mdss.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Qualcomm SM6350 Display MDSS > + > +maintainers: > + - Krishna Manikandan > + > +description: > + SM6350 MSM Mobile Display Subsystem (MDSS), which encapsulates sub-blocks > + like DPU display controller, DSI and DP interfaces etc. > + > +$ref: /schemas/display/msm/mdss-common.yaml# > + > +properties: > + compatible: > +items: Drop items. It's just const. > + - const: qcom,sm6350-mdss > + > + clocks: > +items: > + - description: Display AHB clock from gcc > + - description: Display AXI clock from gcc > + - description: Display core clock > + > + clock-names: > +items: > + - const: iface > + - const: bus > + - const: core > + > + iommus: > +maxItems: 1 > + > + interconnects: > +maxItems: 2 > + > + interconnect-names: > +maxItems: 2 Are you sure you have two interconnects? Example is missing them. Best regards, Krzysztof
Re: [Freedreno] [PATCH v5 05/12] dt-bindings: display/msm: Add SM6375 MDSS
On 23/05/2023 09:46, Konrad Dybcio wrote: > Document the SM6375 MDSS. > > Signed-off-by: Konrad Dybcio > --- > .../bindings/display/msm/qcom,sm6375-mdss.yaml | 216 > + > 1 file changed, 216 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/msm/qcom,sm6375-mdss.yaml > b/Documentation/devicetree/bindings/display/msm/qcom,sm6375-mdss.yaml > new file mode 100644 > index ..3aa4f0470c95 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6375-mdss.yaml > @@ -0,0 +1,216 @@ > +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/msm/qcom,sm6375-mdss.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Qualcomm SM6375 Display MDSS > + > +maintainers: > + - Konrad Dybcio > + > +description: > + SM6375 MSM Mobile Display Subsystem (MDSS), which encapsulates sub-blocks > + like DPU display controller, DSI and DP interfaces etc. > + > +$ref: /schemas/display/msm/mdss-common.yaml# > + > +properties: > + compatible: > +items: > + - const: qcom,sm6375-mdss > + Same as 6350 - drop items. Similar concern about interconnects, although we don't have header file for them, so I assume we will fill it up later. Best regards, Krzysztof
Re: [Freedreno] [PATCH v5 03/12] dt-bindings: display/msm: sc7180-dpu: Describe SM6350 and SM6375
On 23/05/2023 09:46, Konrad Dybcio wrote: > SC7180, SM6350 and SM6375 use a rather similar hw setup for DPU, with > the main exception being that the last one requires an additional > throttle clock. > > It is not well understood yet, but failing to toggle it on makes the > display hardware stall and not output any frames. > > Document SM6350 and SM6375 DPU. > > Signed-off-by: Konrad Dybcio Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [Freedreno] [PATCH 1/2] dt-bindings: display: msm: dp-controller: document SM8550 compatible
On 01/06/2023 11:52, Neil Armstrong wrote: > The SM8550 & SM8350 SoC shares the same DP TX IP version, use the > SM8350 compatible as fallback for SM8550. > > Signed-off-by: Neil Armstrong > --- Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [Freedreno] [PATCH v8 01/18] dt-bindings: display/msm: gpu: Document GMU wrapper-equipped A6xx
On Mon, 29 May 2023 15:52:20 +0200, Konrad Dybcio wrote: > The "GMU Wrapper" is Qualcomm's name for "let's treat the GPU blocks > we'd normally assign to the GMU as if they were a part of the GMU, even > though they are not". It's a (good) software representation of the GMU_CX > and GMU_GX register spaces within the GPUSS that helps us programatically > treat these de-facto GMU-less parts in a way that's very similar to their > GMU-equipped cousins, massively saving up on code duplication. > > The "wrapper" register space was specifically designed to mimic the layout > of a real GMU, though it rather obviously does not have the M3 core et al. > > GMU wrapper-equipped A6xx GPUs require clocks and clock-names to be > specified under the GPU node, just like their older cousins. Account > for that. > > Signed-off-by: Konrad Dybcio > --- > .../devicetree/bindings/display/msm/gpu.yaml | 61 > ++ > 1 file changed, 52 insertions(+), 9 deletions(-) > Running 'make dtbs_check' with the schema in this patch gives the following warnings. Consider if they are expected or the schema is incorrect. These may not be new warnings. Note that it is not yet a requirement to have 0 warnings for dtbs_check. This will change in the future. Full log is available here: https://patchwork.ozlabs.org/patch/1787121 gpu@2c0: compatible: 'oneOf' conditional failed, one must be fixed: arch/arm64/boot/dts/qcom/sm8150-hdk.dtb arch/arm64/boot/dts/qcom/sm8150-mtp.dtb
Re: [Freedreno] [PATCH v2 1/3] dt-bindings: display: hdmi-connector: add hdmi-pwr supply
On 19/05/2023 20:40, Dmitry Baryshkov wrote: > Follow the dp-connector example and add hdmi-pwr supply to drive the 5V > pin of the HDMI connector (together with some simple glue logic possibly > attached to the connector). > > Reviewed-by: Laurent Pinchart > Acked-by: Krzysztof Kozlowski > Signed-off-by: Dmitry Baryshkov > --- Please use scripts/get_maintainers.pl to get a list of necessary people and lists to CC. It might happen, that command when run on an older kernel, gives you outdated entries. Therefore please be sure you base your patches on recent Linux kernel. You missed at least DT list (maybe more), so this won't be tested. Please resend and include all necessary entries. Best regards, Krzysztof
Re: [Freedreno] [PATCH 1/3] dt-bindings: display: hdmi-connector: add hdmi-pwr supply
On 07/05/2023 22:12, Dmitry Baryshkov wrote: > Follow the dp-connector example and add hdmi-pwr supply to drive the 5V > pin of the HDMI connector (together with some simple glue logic possibly > attached to the connector). > > Signed-off-by: Dmitry Baryshkov > --- Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [Freedreno] [PATCH 1/3] dt-bindings: display: hdmi-connector: add hdmi-pwr supply
On 08/05/2023 04:56, Laurent Pinchart wrote: > Hi Rob, > > On Sun, May 07, 2023 at 04:25:44PM -0500, Rob Herring wrote: >> On Sun, 07 May 2023 23:12:16 +0300, Dmitry Baryshkov wrote: >>> Follow the dp-connector example and add hdmi-pwr supply to drive the 5V >>> pin of the HDMI connector (together with some simple glue logic possibly >>> attached to the connector). >>> >>> Signed-off-by: Dmitry Baryshkov >>> --- >>> .../devicetree/bindings/display/connector/hdmi-connector.yaml | 3 +++ >>> 1 file changed, 3 insertions(+) >>> >> >> My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' >> on your patch (DT_CHECKER_FLAGS is new in v5.13): > > The issues below don't seem to be related to Dmitry's patch, are they ? No, can be ignored. Best regards, Krzysztof
Re: [Freedreno] [PATCH v3 05/12] dt-bindings: display/msm: Add SM6375 MDSS
On 05/05/2023 23:40, Konrad Dybcio wrote:
> Document the SM6375 MDSS.
>
> Signed-off-by: Konrad Dybcio
> ---
> .../bindings/display/msm/qcom,sm6375-mdss.yaml | 216
> +
> 1 file changed, 216 insertions(+)
>
Thank you for your patch. There is something to discuss/improve.
> +
> +examples:
> + - |
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +display-subsystem@5e0 {
> +compatible = "qcom,sm6375-mdss";
> +reg = <0x05e0 0x1000>;
> +reg-names = "mdss";
> +
> +power-domains = < MDSS_GDSC>;
> +
> +clocks = < GCC_DISP_AHB_CLK>,
> + < DISP_CC_MDSS_AHB_CLK>,
> + < DISP_CC_MDSS_MDP_CLK>;
> +clock-names = "iface", "ahb", "core";
> +
> +interrupts = ;
> +interrupt-controller;
> +#interrupt-cells = <1>;
> +
> +iommus = <_smmu 0x820 0x2>;
> +#address-cells = <1>;
> +#size-cells = <1>;
> +ranges;
> +
> +display-controller@5e01000 {
> +compatible = "qcom,sm6375-dpu";
> +reg = <0x05e01000 0x8e030>,
> + <0x05eb 0x2008>;
> +reg-names = "mdp", "vbif";
> +
> +clocks = < DISP_CC_MDSS_AHB_CLK>,
> + < GCC_DISP_HF_AXI_CLK>,
> + < DISP_CC_MDSS_MDP_CLK>,
> + < DISP_CC_MDSS_MDP_LUT_CLK>,
> + < DISP_CC_MDSS_ROT_CLK>,
> + < DISP_CC_MDSS_VSYNC_CLK>,
> + < GCC_DISP_THROTTLE_CORE_CLK>;
> +clock-names = "iface",
> + "bus",
> + "core",
> + "lut",
> + "rot",
> + "vsync",
> + "throttle";
Are you sure you have clocks in correct order? I see warnings...
Best regards,
Krzysztof
Re: [Freedreno] [PATCH v3 04/12] dt-bindings: display/msm: Add SM6350 MDSS
On 05/05/2023 23:40, Konrad Dybcio wrote: > Document the SM6350 MDSS. > > Signed-off-by: Konrad Dybcio > --- > .../bindings/display/msm/qcom,sm6350-mdss.yaml | 214 > + > 1 file changed, 214 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml > b/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml > new file mode 100644 > index ..6674040d2172 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml > @@ -0,0 +1,214 @@ > +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/msm/qcom,sm6350-mdss.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Qualcomm SM6350 Display MDSS > + > +maintainers: > + - Krishna Manikandan > + > +description: > + SM6350 MSM Mobile Display Subsystem (MDSS), which encapsulates sub-blocks > + like DPU display controller, DSI and DP interfaces etc. > + > +$ref: /schemas/display/msm/mdss-common.yaml# > + > +properties: > + compatible: > +items: Drop items > + - const: qcom,sm6350-mdss > + The Rob's bot warning can be ignored - it seems patch #1 was not applied. Best regards, Krzysztof
Re: [Freedreno] [PATCH v3 03/12] dt-bindings: display/msm: sc7180-dpu: Describe SM6350 and SM6375
On 05/05/2023 23:40, Konrad Dybcio wrote: > SC7180, SM6350 and SM6375 use a rather similar hw setup for DPU, with > the main exception being that the last one requires an additional > throttle clock. > > It is not well understood yet, but failing to toggle it on makes the > display hardware stall and not output any frames. > > Document SM6350 and SM6375 DPU. > > Signed-off-by: Konrad Dybcio > --- > .../bindings/display/msm/qcom,sc7180-dpu.yaml | 23 > +- > 1 file changed, 22 insertions(+), 1 deletion(-) > > diff --git > a/Documentation/devicetree/bindings/display/msm/qcom,sc7180-dpu.yaml > b/Documentation/devicetree/bindings/display/msm/qcom,sc7180-dpu.yaml > index 1fb8321d9ee8..630b11480496 100644 > --- a/Documentation/devicetree/bindings/display/msm/qcom,sc7180-dpu.yaml > +++ b/Documentation/devicetree/bindings/display/msm/qcom,sc7180-dpu.yaml > @@ -13,7 +13,10 @@ $ref: /schemas/display/msm/dpu-common.yaml# > > properties: >compatible: > -const: qcom,sc7180-dpu > +enum: > + - qcom,sc7180-dpu > + - qcom,sm6350-dpu > + - qcom,sm6375-dpu > >reg: > items: > @@ -26,6 +29,7 @@ properties: >- const: vbif > >clocks: > +minItems: 6 > items: >- description: Display hf axi clock >- description: Display ahb clock > @@ -33,8 +37,10 @@ properties: >- description: Display lut clock >- description: Display core clock >- description: Display vsync clock > + - description: Display core throttle clock > >clock-names: > +minItems: 6 > items: >- const: bus >- const: iface > @@ -42,6 +48,7 @@ properties: >- const: lut >- const: core >- const: vsync > + - const: throttle > > required: >- compatible > @@ -52,6 +59,20 @@ required: > > unevaluatedProperties: false > > +allOf: > + - if: > + properties: > +compatible: > + const: qcom,sm6375-dpu And the two other variants? Is the clock valid there or not? If not really, then you should have else: with maxItems: 6. > + > +then: > + properties: > +clocks: > + minItems: 7 > + > +clock-names: > + minItems: 7 If there is going new version - put allOf: before unevaluatedProperties:. Otherwise it is fine. > + > examples: >- | > #include > Best regards, Krzysztof
Re: [Freedreno] [PATCH v2 1/5] dt-bindings: display/msm: Add reg bus interconnect
On 18/04/2023 14:10, Konrad Dybcio wrote: > Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there's > another path that needs to be handled to ensure MDSS functions properly, > namely the "reg bus", a.k.a the CPU-MDSS interconnect. > > Gating that path may have a variety of effects.. from none to otherwise > inexplicable DSI timeouts.. > > Describe it in bindings to allow for use in device trees. > > Signed-off-by: Konrad Dybcio Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [Freedreno] [PATCH 1/5] dt-bindings: display/msm: Add reg bus interconnect
On 17/04/2023 17:30, Konrad Dybcio wrote: > Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there's > another path that needs to be handled to ensure MDSS functions properly, > namely the "reg bus", a.k.a the CPU-MDSS interconnect. > > Gating that path may have a variety of effects.. from none to otherwise > inexplicable DSI timeouts.. > > Describe it in bindings to allow for use in device trees. > > Signed-off-by: Konrad Dybcio > --- > Documentation/devicetree/bindings/display/msm/mdss-common.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/display/msm/mdss-common.yaml > b/Documentation/devicetree/bindings/display/msm/mdss-common.yaml > index ccd7d6417523..9eb5b6d3e0b9 100644 > --- a/Documentation/devicetree/bindings/display/msm/mdss-common.yaml > +++ b/Documentation/devicetree/bindings/display/msm/mdss-common.yaml > @@ -72,6 +72,7 @@ properties: > items: >- const: mdp0-mem >- const: mdp1-mem > + - const: cpu-cfg You added only interconnect-name, not actual interconnect. Best regards, Krzysztof
Re: [Freedreno] [PATCH v6 02/15] dt-bindings: display/msm: gpu: Document GMU wrapper-equipped A6xx
On 01/04/2023 13:54, Konrad Dybcio wrote: > The "GMU Wrapper" is Qualcomm's name for "let's treat the GPU blocks > we'd normally assign to the GMU as if they were a part of the GMU, even > though they are not". It's a (good) software representation of the GMU_CX > and GMU_GX register spaces within the GPUSS that helps us programatically > treat these de-facto GMU-less parts in a way that's very similar to their > GMU-equipped cousins, massively saving up on code duplication. > > The "wrapper" register space was specifically designed to mimic the layout > of a real GMU, though it rather obviously does not have the M3 core et al. > > GMU wrapper-equipped A6xx GPUs require clocks and clock-names to be > specified under the GPU node, just like their older cousins. Account > for that. > > Signed-off-by: Konrad Dybcio Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [Freedreno] [RFC PATCH 1/3] dt-bindings: display/msm/gpu: allow specifying MX domain A5xx
On 30/03/2023 00:24, Dmitry Baryshkov wrote: > Some a5xx Adreno devices might need additional power domains to handle > voltage scaling. While we do not (yet) have support for CPR3 providing > voltage scaling, allow specifying MX domain to scale the memory cell > voltage. > > Signed-off-by: Dmitry Baryshkov Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [Freedreno] [PATCH v2 2/4] arm64: dts: qcom: sm8450: remove invalid properties in cluster-sleep nodes
On 24/03/2023 20:57, Bjorn Andersson wrote: > On Fri, Mar 24, 2023 at 08:27:12PM +0100, Krzysztof Kozlowski wrote: >> On 24/03/2023 18:45, Bjorn Andersson wrote: >>> On Fri, Mar 24, 2023 at 10:28:47AM +0100, Neil Armstrong wrote: >>>> Fixes the following DT bindings check error: >>> >>> Is that because idle-state-name and local-timer-stop should not be >>> defined for domain-idle-states or are you just clearing out the >>> dtbs_check warning? >>> >>> According to cpu-capacity.txt local-timer-stop seems to have been a >>> property relevant for clusters in the past, was this a mistake in the >>> binding or did something change when this was moved to >>> domain-idle-states? >> >> I cannot find anything about local-timer-stop in cpu-capacity.txt. Where >> do you see it? >> > > Ohh, you're right it's only mentioned in the example. > > But idle-states.yaml documents the property for both cpus and clusters, > and it's used throughout the examples. > > Our cluster states are defined in domanin-idle-states instead of > idle-state, does this imply that the flag is no longer applicable > per cluster in this mode of operation? As you noticed their meaning is interleaving. For example on SC7280 we use arm,idle-state for cluster. But other Qualcomm platforms rather define clusters as domain-idle-states and in that case, nothing parses tgat flag. The flag is only for cpuidle dt_idle_states. For power-domains it was always ignored. Funny fact - both cpu/cluster idle-states and power-domain-idle-states will end up eventually in cpuidle-psci.c... Best regards, Krzysztof
Re: [Freedreno] [PATCH v2 2/4] arm64: dts: qcom: sm8450: remove invalid properties in cluster-sleep nodes
On 24/03/2023 18:45, Bjorn Andersson wrote: > On Fri, Mar 24, 2023 at 10:28:47AM +0100, Neil Armstrong wrote: >> Fixes the following DT bindings check error: > > Is that because idle-state-name and local-timer-stop should not be > defined for domain-idle-states or are you just clearing out the > dtbs_check warning? > > According to cpu-capacity.txt local-timer-stop seems to have been a > property relevant for clusters in the past, was this a mistake in the > binding or did something change when this was moved to > domain-idle-states? I cannot find anything about local-timer-stop in cpu-capacity.txt. Where do you see it? Best regards, Krzysztof
Re: [Freedreno] [PATCH v2 1/4] dt-bindings: display: msm: sm8450-mdss: Fix DSI compatible
On 24/03/2023 10:28, Neil Armstrong wrote:
> The DSI compatible changed between patchset revisions, but that wasn't
> reflected in the bindings. Fix it.
>
> Fixes: 0eda3c6cb1c5 ("dt-bindings: display/msm: add support for the display
> on SM8450")
> Signed-off-by: Neil Armstrong
> ---
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
Re: [Freedreno] [PATCH 7/8] arm64: dts: qcom: sm8450: remove invalid reg-names from ufs node
On 24/03/2023 08:26, Luca Weiss wrote:
> Hi Eric,
>
> On Fri Mar 24, 2023 at 7:52 AM CET, Eric Biggers wrote:
>> Hi Neil,
>>
>> On Thu, Mar 23, 2023 at 02:10:44PM +0100, Neil Armstrong wrote:
>>> Hi,
>>>
>>> On 23/03/2023 11:49, Krzysztof Kozlowski wrote:
>>>> On 23/03/2023 11:25, Neil Armstrong wrote:
>>>>> Fixes the following DT bindings check error:
>>>>> ufshc@1d84000: Unevaluated properties are not allowed ('reg-names' was
>>>>> unexpected)
>>>>>
>>>>> Signed-off-by: Neil Armstrong
>>>>> ---
>>>>> arch/arm64/boot/dts/qcom/sm8450.dtsi | 1 -
>>>>> 1 file changed, 1 deletion(-)
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi
>>>>> b/arch/arm64/boot/dts/qcom/sm8450.dtsi
>>>>> index ef9bae2e6acc..8ecc48c7c5ef 100644
>>>>> --- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
>>>>> +++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
>>>>> @@ -3996,7 +3996,6 @@ ufs_mem_hc: ufshc@1d84000 {
>>>>>"jedec,ufs-2.0";
>>>>> reg = <0 0x01d84000 0 0x3000>,
>>>>> <0 0x01d88000 0 0x8000>;
>>>>> - reg-names = "std", "ice";
>>>>
>>>> This is also part of:
>>>> https://lore.kernel.org/linux-arm-msm/20230308155838.1094920-8-abel.v...@linaro.org/#Z31arch:arm64:boot:dts:qcom:sm8450.dtsi
>>>> but I actually wonder whether you just missed some binding patch?
>>>
>>> I'm aware of Abel's RFC patchset to support shared ICE, but this is a
>>> cleanup of the current DT,
>>> and the current bindings schema doesn't document reg-names.
>>>
>>
>> The ufs-qcom driver accesses the "ice" registers by name, so the reg-names
>> can't
>> be removed from the device tree. A few months ago there was a patch to fix
>> the
>> device tree schema for qcom,ufs to include the reg-names. It looks like that
>> patch got missed, though:
>> https://lore.kernel.org/r/20221209-dt-binding-ufs-v2-2-dc7a04699...@fairphone.com
>
> Are you implying that I should resend the patch or something? Not sure
> who to bug about applying this patch.
Yes, you should. It has been almost three months...
Best regards,
Krzysztof
Re: [Freedreno] [PATCH 6/8] arm64: dts: qcom: sm8450: remove invalid npl clock in vamacro node
On 23/03/2023 14:13, Neil Armstrong wrote: > On 23/03/2023 11:47, Krzysztof Kozlowski wrote: >> On 23/03/2023 11:25, Neil Armstrong wrote: >>> Fixes the following DT bindings check error: >>> codec@33f: clocks: [[137, 57, 1], [137, 102, 1], [137, 103, 1], [137, >>> 70, 1]] is too long >>> codec@33f: clock-names: 'oneOf' conditional failed, one must be fixed: >>> ['mclk', 'macro', 'dcodec', 'npl'] is too long >>> >>> The implementation was checked and this npl clock isn't used for the VA >>> macro. >>> >> >> This does not look correct. DTS looks good, you miss some patches in >> your tree. > > I'm based on today's linux-next, Which is unfortunately not enough. Several things were fixed/added/changed and are pending. I brought the topic of pending branch few times on IRC for that reason. > while the other lpass macros uses the npl clock, > the lpass vamacro bindings doesn't document the npl clock. > > And I found no fixes whatsover to add the npl clock to bindings. Really? lore finds it easily: https://lore.kernel.org/all/20221118071849.25506-2-srinivas.kandaga...@linaro.org/ Best regards, Krzysztof
Re: [Freedreno] [PATCH 7/8] arm64: dts: qcom: sm8450: remove invalid reg-names from ufs node
On 24/03/2023 07:52, Eric Biggers wrote:
> Hi Neil,
>
> On Thu, Mar 23, 2023 at 02:10:44PM +0100, Neil Armstrong wrote:
>> Hi,
>>
>> On 23/03/2023 11:49, Krzysztof Kozlowski wrote:
>>> On 23/03/2023 11:25, Neil Armstrong wrote:
>>>> Fixes the following DT bindings check error:
>>>> ufshc@1d84000: Unevaluated properties are not allowed ('reg-names' was
>>>> unexpected)
>>>>
>>>> Signed-off-by: Neil Armstrong
>>>> ---
>>>> arch/arm64/boot/dts/qcom/sm8450.dtsi | 1 -
>>>> 1 file changed, 1 deletion(-)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi
>>>> b/arch/arm64/boot/dts/qcom/sm8450.dtsi
>>>> index ef9bae2e6acc..8ecc48c7c5ef 100644
>>>> --- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
>>>> +++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
>>>> @@ -3996,7 +3996,6 @@ ufs_mem_hc: ufshc@1d84000 {
>>>> "jedec,ufs-2.0";
>>>>reg = <0 0x01d84000 0 0x3000>,
>>>> <0 0x01d88000 0 0x8000>;
>>>> - reg-names = "std", "ice";
>>>
>>> This is also part of:
>>> https://lore.kernel.org/linux-arm-msm/20230308155838.1094920-8-abel.v...@linaro.org/#Z31arch:arm64:boot:dts:qcom:sm8450.dtsi
>>> but I actually wonder whether you just missed some binding patch?
>>
>> I'm aware of Abel's RFC patchset to support shared ICE, but this is a
>> cleanup of the current DT,
>> and the current bindings schema doesn't document reg-names.
>>
>
> The ufs-qcom driver accesses the "ice" registers by name, so the reg-names
> can't
> be removed from the device tree. A few months ago there was a patch to fix
> the
> device tree schema for qcom,ufs to include the reg-names. It looks like that
> patch got missed, though:
> https://lore.kernel.org/r/20221209-dt-binding-ufs-v2-2-dc7a04699...@fairphone.com
Exactly. This is why I never saw these warnings.
Neil, there are a lot of pending patches, so you need to be sure you run
dtbs_check with them applied.
Best regards,
Krzysztof
