* Re: [PATCH v4 4/7] dt-bindings: iio: accel: adxl345: Add spi-3wire
From: Lothar Rubusch @ 2024-03-26 20:17 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: lars, Michael.Hennerich, jic23, robh+dt, krzysztof.kozlowski+dt,
conor+dt, linux-iio, devicetree, linux-kernel, eraretuya
In-Reply-To: <b13ca51c-db57-4a09-b689-cf27265d348f@linaro.org>
On Tue, Mar 26, 2024 at 7:30 AM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 25/03/2024 23:09, Lothar Rubusch wrote:
> >>
> >>
> >>>
> >>>> the tags. The upstream maintainer will do that for tags received on the
> >>>> version they apply.
> >>>>
> >>>
> >>> I'm pretty sure we will still see further iterations. So, I apply the
> >>> tags in the next version, already scheduled. Ok?
> >>>
> >>>> https://elixir.bootlin.com/linux/v6.5-rc3/source/Documentation/process/submitting-patches.rst#L577
> >>>>
> >>>
> >>> Going over the books I feel it does not make sense to still mention
> >>> feedback ("Reveiewed-by") for the v1 or v2 of the patch here in a v5,
> >>> does it? Your link mentiones "However if the patch has changed
> >>
> >> I don't understand. When did you receive the tag? v3, right? So what do
> >> you mean by v1 and v2?
> >>
> >
> > V1: The first version of the 3wire patch. I have split the single
> > patch upon some feedback (yours?!) - V2... So, my current
> > interpretation is, that every feedback I need to mention as
> > Reviewed-by tag, no?
>
> What? Feedback is not review. It's clearly explained in submitting
> patches. Please read it.
>
Exactly. My missunderstanding here is this: Why did you send me a
reminder that I forgot to add "Reviewed-by" tag in your last mail?
Could you please clarify your last mail? You wrote:
"(...)
This is a friendly reminder during the review process.
It looks like you received a tag and forgot to add it.
If you do not know the process, here is a short explanation:
Please add Acked-by/Reviewed-by/Tested-by tags when posting new
versions, (...)"
AFAIK noone literally had told me: "please add a Reviewed-by me tag",
or did I miss something? I'm a bit lost here, sorry.
> Best regards,
> Krzysztof
>
^ permalink raw reply
* [RFC PATCH 1/1] dt-bindings: display/msm: gpu: Split Adreno schemas into separate files
From: Adam Skladowski @ 2024-03-26 20:05 UTC (permalink / raw)
Cc: phone-devel, ~postmarketos/upstreaming, Adam Skladowski,
Rob Clark, Abhinav Kumar, Dmitry Baryshkov, Sean Paul,
Marijn Suijten, David Airlie, Daniel Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, dri-devel,
freedreno, devicetree, linux-kernel
In-Reply-To: <20240326201140.10561-1-a39.skl@gmail.com>
Split shared schema into per-gen and group adrenos by clocks used.
Signed-off-by: Adam Skladowski <a39.skl@gmail.com>
---
.../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(-)
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
diff --git a/Documentation/devicetree/bindings/display/msm/gpu.yaml b/Documentation/devicetree/bindings/display/msm/gpu.yaml
index 40b5c6bd11f8..be29d85e597c 100644
--- a/Documentation/devicetree/bindings/display/msm/gpu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/gpu.yaml
@@ -5,7 +5,7 @@
$id: http://devicetree.org/schemas/display/msm/gpu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Adreno or Snapdragon GPUs
+title: Imageon 200 GPU
maintainers:
- Rob Clark <robdclark@gmail.com>
@@ -13,18 +13,6 @@ 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]$'
- - const: qcom,adreno
- - description: |
- The driver is parsing the compat string for Adreno to
- figure out the gpu-id and patch level.
- items:
- - pattern: '^qcom,adreno-[3-7][0-9][0-9]\.[0-9]+$'
- - const: qcom,adreno
- description: |
The driver is parsing the compat string for Imageon to
figure out the gpu-id and patch level.
@@ -32,88 +20,31 @@ properties:
- pattern: '^amd,imageon-200\.[0-1]$'
- const: amd,imageon
- clocks: true
+ clocks:
+ items:
+ - description: GPU Core clock
+ - description: GPU Memory Interface clock
- clock-names: true
+ clock-names:
+ items:
+ - const: core_clk
+ - const: mem_iface_clk
reg:
- minItems: 1
- maxItems: 3
+ items:
+ - description: base address of GPU device
reg-names:
- minItems: 1
- maxItems: 3
+ items:
+ - const: kgsl_3d0_reg_memory
interrupts:
- maxItems: 1
-
- interrupt-names:
- maxItems: 1
-
- interconnects:
- minItems: 1
- maxItems: 2
-
- interconnect-names:
- minItems: 1
items:
- - const: gfx-mem
- - const: ocmem
+ - description: interrupt of GPU device
- iommus:
- minItems: 1
- maxItems: 64
-
- sram:
- $ref: /schemas/types.yaml#/definitions/phandle-array
- minItems: 1
- maxItems: 4
+ interrupt-names:
items:
- maxItems: 1
- description: |
- phandles to one or more reserved on-chip SRAM regions.
- phandle to the On Chip Memory (OCMEM) that's present on some a3xx and
- a4xx Snapdragon SoCs. See
- Documentation/devicetree/bindings/sram/qcom,ocmem.yaml
-
- operating-points-v2: true
- opp-table:
- type: object
-
- power-domains:
- maxItems: 1
-
- zap-shader:
- type: object
- additionalProperties: false
- description: |
- For a5xx and a6xx devices this node contains a memory-region that
- points to reserved memory to store the zap shader that can be used to
- help bring the GPU out of secure mode.
- properties:
- memory-region:
- maxItems: 1
-
- firmware-name:
- description: |
- Default name of the firmware to load to the remote processor.
-
- "#cooling-cells":
- const: 2
-
- nvmem-cell-names:
- maxItems: 1
-
- nvmem-cells:
- description: efuse registers
- maxItems: 1
-
- qcom,gmu:
- $ref: /schemas/types.yaml#/definitions/phandle
- description: |
- For GMU attached devices a phandle to the GMU device that will
- control the power for the GPU.
-
+ - const: kgsl_3d0_irq
required:
- compatible
@@ -122,222 +53,24 @@ required:
additionalProperties: false
-allOf:
- - if:
- properties:
- compatible:
- contains:
- pattern: '^qcom,adreno-[3-5][0-9][0-9]\.[0-9]+$'
-
- then:
- properties:
- clocks:
- minItems: 2
- maxItems: 7
-
- clock-names:
- items:
- anyOf:
- - const: core
- description: GPU Core clock
- - const: iface
- description: GPU Interface clock
- - const: mem
- description: GPU Memory clock
- - const: mem_iface
- description: GPU Memory Interface clock
- - const: alt_mem_iface
- description: GPU Alternative Memory Interface clock
- - const: gfx3d
- description: GPU 3D engine clock
- - const: rbbmtimer
- description: GPU RBBM Timer for Adreno 5xx series
- - const: rbcpr
- description: GPU RB Core Power Reduction clock
- minItems: 2
- maxItems: 7
-
- required:
- - clocks
- - clock-names
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,adreno-610.0
- - qcom,adreno-619.1
- then:
- properties:
- clocks:
- minItems: 6
- maxItems: 6
-
- clock-names:
- items:
- - const: core
- description: GPU Core clock
- - const: iface
- description: GPU Interface clock
- - const: mem_iface
- description: GPU Memory Interface clock
- - const: alt_mem_iface
- description: GPU Alternative Memory Interface clock
- - const: gmu
- description: CX GMU clock
- - const: xo
- description: GPUCC clocksource clock
-
- reg-names:
- minItems: 1
- items:
- - const: kgsl_3d0_reg_memory
- - const: cx_dbgc
-
- required:
- - clocks
- - clock-names
- else:
- if:
- properties:
- compatible:
- contains:
- pattern: '^qcom,adreno-[67][0-9][0-9]\.[0-9]+$'
-
- then: # Starting with A6xx, the clocks are usually defined in the GMU node
- properties:
- clocks: false
- clock-names: false
-
- reg-names:
- minItems: 1
- items:
- - const: kgsl_3d0_reg_memory
- - const: cx_mem
- - const: cx_dbgc
-
examples:
- |
- // Example a3xx/4xx:
+ // Example imageon-200:
- #include <dt-bindings/clock/qcom,mmcc-msm8974.h>
- #include <dt-bindings/clock/qcom,rpmcc.h>
+ #include <dt-bindings/clock/imx5-clock.h>
#include <dt-bindings/interrupt-controller/irq.h>
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- gpu: gpu@fdb00000 {
- compatible = "qcom,adreno-330.2", "qcom,adreno";
+ gpu: gpu@30000000 {
+ compatible = "amd,imageon-200.0", "amd,imageon";
- reg = <0xfdb00000 0x10000>;
+ reg = <0x30000000 0x20000>;
reg-names = "kgsl_3d0_reg_memory";
- clock-names = "core", "iface", "mem_iface";
- clocks = <&mmcc OXILI_GFX3D_CLK>,
- <&mmcc OXILICX_AHB_CLK>,
- <&mmcc OXILICX_AXI_CLK>;
+ clock-names = "core_clk", "mem_iface_clk";
+ clocks = <&clks IMX5_CLK_GPU3D_GATE>,
+ <&clks IMX5_CLK_GARB_GATE>;
- interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <12>;
interrupt-names = "kgsl_3d0_irq";
-
- sram = <&gpu_sram>;
- power-domains = <&mmcc OXILICX_GDSC>;
- operating-points-v2 = <&gpu_opp_table>;
- iommus = <&gpu_iommu 0>;
- #cooling-cells = <2>;
- };
-
- ocmem@fdd00000 {
- compatible = "qcom,msm8974-ocmem";
-
- reg = <0xfdd00000 0x2000>,
- <0xfec00000 0x180000>;
- reg-names = "ctrl", "mem";
-
- clocks = <&rpmcc RPM_SMD_OCMEMGX_CLK>,
- <&mmcc OCMEMCX_OCMEMNOC_CLK>;
- clock-names = "core", "iface";
-
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0 0xfec00000 0x100000>;
-
- gpu_sram: gpu-sram@0 {
- reg = <0x0 0x100000>;
- };
- };
- - |
-
- // Example a6xx (with GMU):
-
- #include <dt-bindings/clock/qcom,gpucc-sdm845.h>
- #include <dt-bindings/clock/qcom,gcc-sdm845.h>
- #include <dt-bindings/power/qcom-rpmpd.h>
- #include <dt-bindings/interrupt-controller/irq.h>
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- #include <dt-bindings/interconnect/qcom,sdm845.h>
-
- reserved-memory {
- #address-cells = <2>;
- #size-cells = <2>;
-
- zap_shader_region: gpu@8f200000 {
- compatible = "shared-dma-pool";
- reg = <0x0 0x90b00000 0x0 0xa00000>;
- no-map;
- };
- };
-
- gpu@5000000 {
- compatible = "qcom,adreno-630.2", "qcom,adreno";
-
- reg = <0x5000000 0x40000>, <0x509e000 0x10>;
- reg-names = "kgsl_3d0_reg_memory", "cx_mem";
-
- #cooling-cells = <2>;
-
- interrupts = <GIC_SPI 300 IRQ_TYPE_LEVEL_HIGH>;
-
- iommus = <&adreno_smmu 0>;
-
- operating-points-v2 = <&gpu_opp_table>;
-
- interconnects = <&rsc_hlos MASTER_GFX3D &rsc_hlos SLAVE_EBI1>;
- interconnect-names = "gfx-mem";
-
- qcom,gmu = <&gmu>;
-
- gpu_opp_table: opp-table {
- compatible = "operating-points-v2";
-
- opp-430000000 {
- opp-hz = /bits/ 64 <430000000>;
- opp-level = <RPMH_REGULATOR_LEVEL_SVS_L1>;
- opp-peak-kBps = <5412000>;
- };
-
- opp-355000000 {
- opp-hz = /bits/ 64 <355000000>;
- opp-level = <RPMH_REGULATOR_LEVEL_SVS>;
- opp-peak-kBps = <3072000>;
- };
-
- opp-267000000 {
- opp-hz = /bits/ 64 <267000000>;
- opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
- opp-peak-kBps = <3072000>;
- };
-
- opp-180000000 {
- opp-hz = /bits/ 64 <180000000>;
- opp-level = <RPMH_REGULATOR_LEVEL_MIN_SVS>;
- opp-peak-kBps = <1804000>;
- };
- };
-
- zap-shader {
- memory-region = <&zap_shader_region>;
- firmware-name = "qcom/LENOVO/81JL/qcdxkmsuc850.mbn";
- };
};
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,adreno-306.yaml b/Documentation/devicetree/bindings/display/msm/qcom,adreno-306.yaml
new file mode 100644
index 000000000000..2d2b86edaed0
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,adreno-306.yaml
@@ -0,0 +1,115 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,adreno-306.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Adreno 3xx GPU
+
+maintainers:
+ - Rob Clark <robdclark@gmail.com>
+
+description:
+ Device tree bindings for Adreno 306 GPU.
+
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,adreno-306.0
+ required:
+ - compatible
+
+$ref: /schemas/display/msm/qcom,adreno-common.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - qcom,adreno-306.0
+ - const: qcom,adreno
+ reg:
+ items:
+ - description: base address of GPU device
+
+ reg-names:
+ items:
+ - const: kgsl_3d0_reg_memory
+
+ clocks:
+ items:
+ - description: GPU Core clock
+ - description: GPU Interface clock
+ - description: GPU Memory clock
+ - description: GPU Memory Interface clock
+ - description: GPU Memory Interface clock
+ - description: GPU 3D engine clock
+
+ clock-names:
+ items:
+ - const: core
+ - const: iface
+ - const: mem
+ - const: mem_iface
+ - const: alt_mem_iface
+ - const: gfx3d
+
+required:
+ - clocks
+ - clock-names
+ - power-domains
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ // Example a306 :
+
+ #include <dt-bindings/clock/qcom,gcc-msm8916.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ gpu@1c00000 {
+ compatible = "qcom,adreno-306.0", "qcom,adreno";
+
+ reg = <0x01c00000 0x20000>;
+ reg-names = "kgsl_3d0_reg_memory";
+
+ interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
+
+ clocks = <&gcc GCC_OXILI_GFX3D_CLK>,
+ <&gcc GCC_OXILI_AHB_CLK>,
+ <&gcc GCC_OXILI_GMEM_CLK>,
+ <&gcc GCC_BIMC_GFX_CLK>,
+ <&gcc GCC_BIMC_GPU_CLK>,
+ <&gcc GFX3D_CLK_SRC>;
+
+ clock-names = "core",
+ "iface",
+ "mem",
+ "mem_iface",
+ "alt_mem_iface",
+ "gfx3d";
+
+ power-domains = <&gcc OXILI_GDSC>;
+ iommus = <&gpu_iommu 1>, <&gpu_iommu 2>;
+
+ operating-points-v2 = <&gpu_opp_table>;
+
+ #cooling-cells = <2>;
+
+ gpu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-19200000 {
+ opp-hz = /bits/ 64 <19200000>;
+ };
+
+ opp-400000000 {
+ opp-hz = /bits/ 64 <400000000>;
+ opp-supported-hw = <0x1ff>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,adreno-330.yaml b/Documentation/devicetree/bindings/display/msm/qcom,adreno-330.yaml
new file mode 100644
index 000000000000..46ad110571cd
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,adreno-330.yaml
@@ -0,0 +1,111 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,adreno-330.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Adreno 3xx GPU
+
+maintainers:
+ - Rob Clark <robdclark@gmail.com>
+
+description:
+ Device tree bindings for Adreno 330 GPU.
+
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,adreno-305.18
+ - qcom,adreno-330.1
+ required:
+ - compatible
+
+$ref: /schemas/display/msm/qcom,adreno-common.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - qcom,adreno-305.18
+ - qcom,adreno-330.1
+ - const: qcom,adreno
+ reg:
+ items:
+ - description: base address of GPU device
+
+ reg-names:
+ items:
+ - const: kgsl_3d0_reg_memory
+
+ clocks:
+ items:
+ - description: GPU Core clock
+ - description: GPU Interface clock
+ - description: GPU Memory Interface clock
+
+ clock-names:
+ items:
+ - const: core
+ - const: iface
+ - const: mem_iface
+
+required:
+ - clocks
+ - clock-names
+ - power-domains
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ // Example a306 :
+
+ #include <dt-bindings/clock/qcom,gcc-msm8974.h>
+ #include <dt-bindings/clock/qcom,mmcc-msm8974.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ gpu@fdb00000 {
+ compatible = "qcom,adreno-330.1", "qcom,adreno";
+
+ reg = <0xfdb00000 0x10000>;
+ reg-names = "kgsl_3d0_reg_memory";
+
+ interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "kgsl_3d0_irq";
+
+ clocks = <&mmcc OXILI_GFX3D_CLK>,
+ <&mmcc OXILICX_AHB_CLK>,
+ <&mmcc OXILICX_AXI_CLK>;
+
+ clock-names = "core",
+ "iface",
+ "mem_iface";
+
+ power-domains = <&mmcc OXILICX_GDSC>;
+ iommus = <&gpu_iommu 0>;
+
+ sram = <&gmu_sram>;
+ operating-points-v2 = <&gpu_opp_table>;
+
+ #cooling-cells = <2>;
+
+ gpu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-27000000 {
+ opp-hz = /bits/ 64 <27000000>;
+ };
+
+ opp-200000000 {
+ opp-hz = /bits/ 64 <200000000>;
+ };
+
+ opp-320000000 {
+ opp-hz = /bits/ 64 <320000000>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,adreno-405.yaml b/Documentation/devicetree/bindings/display/msm/qcom,adreno-405.yaml
new file mode 100644
index 000000000000..d3bcf1dafe95
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,adreno-405.yaml
@@ -0,0 +1,135 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,adreno-405.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Adreno 4xx GPU
+
+maintainers:
+ - Rob Clark <robdclark@gmail.com>
+
+description:
+ Device tree bindings for Adreno 405 GPU.
+
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,adreno-405.0
+ required:
+ - compatible
+
+$ref: /schemas/display/msm/qcom,adreno-common.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - qcom,adreno-405.0
+ - const: qcom,adreno
+ reg:
+ items:
+ - description: base address of GPU device
+
+ reg-names:
+ items:
+ - const: kgsl_3d0_reg_memory
+
+ clocks:
+ items:
+ - description: GPU Core clock
+ - description: GPU Interface clock
+ - description: GPU Memory clock
+ - description: GPU Memory Interface clock
+ - description: GPU Memory Interface clock
+ - description: GPU 3D engine clock
+ - description: GPU RBBM Timer for Adreno 4xx series
+
+ clock-names:
+ items:
+ - const: core
+ - const: iface
+ - const: mem
+ - const: mem_iface
+ - const: alt_mem_iface
+ - const: gfx3d
+ - const: rbbmtimer
+
+required:
+ - clocks
+ - clock-names
+ - power-domains
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ // Example a405 :
+
+ #include <dt-bindings/clock/qcom,gcc-msm8939.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ gpu@1c00000 {
+ compatible = "qcom,adreno-405.0", "qcom,adreno";
+
+ reg = <0x01c00000 0x40000>;
+ reg-names = "kgsl_3d0_reg_memory";
+
+ interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
+
+ clocks = <&gcc GCC_OXILI_GFX3D_CLK>,
+ <&gcc GCC_OXILI_AHB_CLK>,
+ <&gcc GCC_OXILI_GMEM_CLK>,
+ <&gcc GCC_BIMC_GFX_CLK>,
+ <&gcc GCC_BIMC_GPU_CLK>,
+ <&gcc GFX3D_CLK_SRC>,
+ <&gcc GCC_OXILI_TIMER_CLK>;
+
+ clock-names = "core",
+ "iface",
+ "mem",
+ "mem_iface",
+ "alt_mem_iface",
+ "gfx3d",
+ "rbbmtimer";
+
+ power-domains = <&gcc OXILI_GDSC>;
+ iommus = <&gpu_iommu 1>, <&gpu_iommu 2>;
+
+ operating-points-v2 = <&gpu_opp_table>;
+
+ #cooling-cells = <2>;
+
+ gpu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-19200000 {
+ opp-hz = /bits/ 64 <19200000>;
+ };
+
+ opp-220000000 {
+ opp-hz = /bits/ 64 <220000000>;
+ };
+
+ opp-400000000 {
+ opp-hz = /bits/ 64 <400000000>;
+ };
+
+ opp-465000000 {
+ opp-hz = /bits/ 64 <465000000>;
+ };
+
+ opp-550000000 {
+ opp-hz = /bits/ 64 <550000000>;
+ };
+
+ opp-600000000 {
+ opp-hz = /bits/ 64 <600000000>;
+ };
+ };
+ };
+
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,adreno-506.yaml b/Documentation/devicetree/bindings/display/msm/qcom,adreno-506.yaml
new file mode 100644
index 000000000000..58e43a3c1c6d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,adreno-506.yaml
@@ -0,0 +1,184 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,adreno-506.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Adreno 506 GPU
+
+maintainers:
+ - Rob Clark <robdclark@gmail.com>
+
+description:
+ Device tree bindings for Adreno 506 GPU.
+
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,adreno-504.0
+ - qcom,adreno-505.0
+ - qcom,adreno-506.0
+ - qcom,adreno-510.0
+ required:
+ - compatible
+
+$ref: /schemas/display/msm/qcom,adreno-common.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - qcom,adreno-504.0
+ - qcom,adreno-505.0
+ - qcom,adreno-506.0
+ - qcom,adreno-510.0
+ - const: qcom,adreno
+
+ reg:
+ items:
+ - description: base address of GPU device
+
+ reg-names:
+ items:
+ - const: kgsl_3d0_reg_memory
+
+ clocks:
+ items:
+ - description: GPU Always-On clock
+ - description: GPU Core clock
+ - description: GPU Interface clock
+ - description: GPU Memory clock
+ - description: GPU Memory Interface clock
+ - description: GPU RBBM Timer for Adreno 5xx series
+
+ clock-names:
+ items:
+ - const: alwayson
+ - const: core
+ - const: iface
+ - const: mem
+ - const: mem_iface
+ - const: rbbmtimer
+
+required:
+ - clocks
+ - clock-names
+ - power-domains
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ // Example a506 :
+
+ #include <dt-bindings/clock/qcom,gcc-msm8953.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ zap_shader_region: memory@81800000 {
+ compatible = "shared-dma-pool";
+ reg = <0x0 0x81800000 0x0 0x2000>;
+ no-map;
+ };
+ };
+
+
+ gpu@1c00000 {
+ compatible = "qcom,adreno-506.0", "qcom,adreno";
+
+ reg = <0x01c00000 0x40000>;
+ reg-names = "kgsl_3d0_reg_memory";
+
+ interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
+
+ clocks = <&gcc GCC_OXILI_AON_CLK>,
+ <&gcc GCC_OXILI_GFX3D_CLK>,
+ <&gcc GCC_OXILI_AHB_CLK>,
+ <&gcc GCC_BIMC_GFX_CLK>,
+ <&gcc GCC_BIMC_GPU_CLK>,
+ <&gcc GCC_OXILI_TIMER_CLK>;
+
+ clock-names = "alwayson",
+ "core",
+ "iface",
+ "mem",
+ "mem_iface",
+ "rbbmtimer";
+
+ power-domains = <&gcc OXILI_GX_GDSC>;
+ iommus = <&gpu_iommu 0>;
+
+ nvmem-cells = <&speedbin_efuse>;
+ nvmem-cell-names = "speed_bin";
+
+ operating-points-v2 = <&gpu_opp_table>;
+
+ #cooling-cells = <2>;
+
+ gpu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-200000000 {
+ opp-hz = /bits/ 64 <200000000>;
+ opp-supported-hw = <0x1ff>;
+ };
+
+ opp-266670000 {
+ opp-hz = /bits/ 64 <266670000>;
+ opp-supported-hw = <0x1ff>;
+ };
+
+ opp-320000000 {
+ opp-hz = /bits/ 64 <320000000>;
+ opp-supported-hw = <0x1ff>;
+ };
+
+ opp-400000000 {
+ opp-hz = /bits/ 64 <400000000>;
+ opp-supported-hw = <0x1ff>;
+ };
+
+ opp-510000000 {
+ opp-hz = /bits/ 64 <510000000>;
+ opp-supported-hw = <0x1ff>;
+ };
+
+ opp-560000000 {
+ opp-hz = /bits/ 64 <560000000>;
+ opp-supported-hw = <0x1ff>;
+ };
+
+ opp-600000000 {
+ opp-hz = /bits/ 64 <600000000>;
+ opp-supported-hw = <0x1ff>;
+ };
+
+ opp-650000000 {
+ opp-hz = /bits/ 64 <650000000>;
+ opp-supported-hw = <0x185>;
+ };
+
+ opp-685000000 {
+ opp-hz = /bits/ 64 <685000000>;
+ opp-supported-hw = <0x100>;
+ };
+
+ opp-725000000 {
+ opp-hz = /bits/ 64 <725000000>;
+ opp-supported-hw = <0x100>;
+ };
+ };
+
+ zap-shader {
+ memory-region = <&zap_shader_region>;
+ firmware-name = "a506_zap.mdt";
+ };
+ };
+
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,adreno-530.yaml b/Documentation/devicetree/bindings/display/msm/qcom,adreno-530.yaml
new file mode 100644
index 000000000000..6d31697782f2
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,adreno-530.yaml
@@ -0,0 +1,161 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,adreno-530.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Adreno 530 GPU
+
+maintainers:
+ - Rob Clark <robdclark@gmail.com>
+
+description:
+ Device tree bindings for Adreno 530 GPU.
+
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,adreno-530.2
+ required:
+ - compatible
+
+$ref: /schemas/display/msm/qcom,adreno-common.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - qcom,adreno-530.2
+ - const: qcom,adreno
+ reg:
+ items:
+ - description: base address of GPU device
+
+ reg-names:
+ items:
+ - const: kgsl_3d0_reg_memory
+
+ clocks:
+ items:
+ - description: GPU Core clock
+ - description: GPU Interface clock
+ - description: GPU RBBM Timer for Adreno 5xx series
+ - description: GPU Memory clock
+ - description: GPU Memory Interface clock
+
+ clock-names:
+ items:
+ - const: core
+ - const: iface
+ - const: rbbmtimer
+ - const: mem
+ - const: mem_iface
+
+
+required:
+ - clocks
+ - clock-names
+ - power-domains
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ // Example a530 :
+
+ #include <dt-bindings/clock/qcom,gcc-msm8996.h>
+ #include <dt-bindings/clock/qcom,mmcc-msm8996.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interconnect/qcom,msm8996.h>
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ gpu_mem: memory@90f00000 {
+ compatible = "shared-dma-pool";
+ reg = <0x0 0x90f00000 0x0 0x100000>;
+ no-map;
+ };
+ };
+
+ gpu@b00000 {
+ compatible = "qcom,adreno-530.2", "qcom,adreno";
+
+ reg = <0x00b00000 0x3f000>;
+ reg-names = "kgsl_3d0_reg_memory";
+
+ interrupts = <GIC_SPI 300 IRQ_TYPE_LEVEL_HIGH>;
+
+ clocks = <&mmcc GPU_GX_GFX3D_CLK>,
+ <&mmcc GPU_AHB_CLK>,
+ <&mmcc GPU_GX_RBBMTIMER_CLK>,
+ <&gcc GCC_BIMC_GFX_CLK>,
+ <&gcc GCC_MMSS_BIMC_GFX_CLK>;
+
+ clock-names = "core",
+ "iface",
+ "rbbmtimer",
+ "mem",
+ "mem_iface";
+
+ power-domains = <&mmcc GPU_GX_GDSC>;
+ iommus = <&adreno_smmu 0>;
+
+ nvmem-cells = <&speedbin_efuse>;
+ nvmem-cell-names = "speed_bin";
+
+ operating-points-v2 = <&gpu_opp_table>;
+
+ interconnects = <&bimc MASTER_GRAPHICS_3D &bimc SLAVE_EBI_CH0>;
+ interconnect-names = "gfx-mem";
+
+ #cooling-cells = <2>;
+
+ gpu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-624000000 {
+ opp-hz = /bits/ 64 <624000000>;
+ opp-supported-hw = <0x09>;
+ };
+
+ opp-560000000 {
+ opp-hz = /bits/ 64 <560000000>;
+ opp-supported-hw = <0x0d>;
+ };
+
+ opp-510000000 {
+ opp-hz = /bits/ 64 <510000000>;
+ opp-supported-hw = <0xff>;
+ };
+
+ opp-401800000 {
+ opp-hz = /bits/ 64 <401800000>;
+ opp-supported-hw = <0xff>;
+ };
+
+ opp-315000000 {
+ opp-hz = /bits/ 64 <315000000>;
+ opp-supported-hw = <0xff>;
+ };
+
+ opp-214000000 {
+ opp-hz = /bits/ 64 <214000000>;
+ opp-supported-hw = <0xff>;
+ };
+
+ opp-133000000 {
+ opp-hz = /bits/ 64 <133000000>;
+ opp-supported-hw = <0xff>;
+ };
+ };
+
+ zap-shader {
+ memory-region = <&gpu_mem>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,adreno-540.yaml b/Documentation/devicetree/bindings/display/msm/qcom,adreno-540.yaml
new file mode 100644
index 000000000000..bb7ccb8ddc28
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,adreno-540.yaml
@@ -0,0 +1,154 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,adreno-540.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Adreno 5xx GPU
+
+maintainers:
+ - Rob Clark <robdclark@gmail.com>
+
+description:
+ Device tree bindings for Adreno 540 GPU.
+
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,adreno-508.0
+ - qcom,adreno-512.0
+ - qcom,adreno-540.1
+ required:
+ - compatible
+
+$ref: /schemas/display/msm/qcom,adreno-common.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - qcom,adreno-508.0
+ - qcom,adreno-512.0
+ - qcom,adreno-540.1
+ - const: qcom,adreno
+ reg:
+ items:
+ - description: base address of GPU device
+
+ reg-names:
+ items:
+ - const: kgsl_3d0_reg_memory
+
+ clocks:
+ items:
+ - description: GPU Interface clock
+ - description: GPU RBBM Timer for Adreno 5xx series
+ - description: GPU Memory clock
+ - description: GPU Memory Interface clock
+ - description: GPU RBCPR clock
+ - description: GPU Core clock
+
+ clock-names:
+ items:
+ - const: iface
+ - const: rbbmtimer
+ - const: mem
+ - const: mem_iface
+ - const: rbcpr
+ - const: core
+
+required:
+ - clocks
+ - clock-names
+ - power-domains
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ // Example a540 :
+
+ #include <dt-bindings/clock/qcom,gcc-msm8998.h>
+ #include <dt-bindings/clock/qcom,gpucc-msm8998.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ gpu@5000000 {
+ compatible = "qcom,adreno-540.1", "qcom,adreno";
+
+ reg = <0x05000000 0x40000>;
+ reg-names = "kgsl_3d0_reg_memory";
+
+ interrupts = <GIC_SPI 300 IRQ_TYPE_LEVEL_HIGH>;
+
+ clocks = <&gcc GCC_GPU_CFG_AHB_CLK>,
+ <&gpucc RBBMTIMER_CLK>,
+ <&gcc GCC_BIMC_GFX_CLK>,
+ <&gcc GCC_GPU_BIMC_GFX_CLK>,
+ <&gpucc RBCPR_CLK>,
+ <&gpucc GFX3D_CLK>;
+
+ clock-names = "iface",
+ "rbbmtimer",
+ "mem",
+ "mem_iface",
+ "rbcpr",
+ "core";
+
+ power-domains = <&rpmpd MSM8998_VDDMX>;
+ iommus = <&adreno_smmu 0>;
+
+ operating-points-v2 = <&gpu_opp_table>;
+
+ #cooling-cells = <2>;
+
+ gpu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-710000097 {
+ opp-hz = /bits/ 64 <710000097>;
+ opp-level = <RPM_SMD_LEVEL_TURBO>;
+ opp-supported-hw = <0xff>;
+ };
+
+ opp-670000048 {
+ opp-hz = /bits/ 64 <670000048>;
+ opp-level = <RPM_SMD_LEVEL_NOM_PLUS>;
+ opp-supported-hw = <0xff>;
+ };
+
+ opp-596000097 {
+ opp-hz = /bits/ 64 <596000097>;
+ opp-level = <RPM_SMD_LEVEL_NOM>;
+ opp-supported-hw = <0xff>;
+ };
+
+ opp-515000097 {
+ opp-hz = /bits/ 64 <515000097>;
+ opp-level = <RPM_SMD_LEVEL_SVS_PLUS>;
+ opp-supported-hw = <0xff>;
+ };
+
+ opp-414000000 {
+ opp-hz = /bits/ 64 <414000000>;
+ opp-level = <RPM_SMD_LEVEL_SVS>;
+ opp-supported-hw = <0xff>;
+ };
+
+ opp-342000000 {
+ opp-hz = /bits/ 64 <342000000>;
+ opp-level = <RPM_SMD_LEVEL_LOW_SVS>;
+ opp-supported-hw = <0xff>;
+ };
+
+ opp-257000000 {
+ opp-hz = /bits/ 64 <257000000>;
+ opp-level = <RPM_SMD_LEVEL_MIN_SVS>;
+ opp-supported-hw = <0xff>;
+ };
+ };
+ };
+
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,adreno-6xx.yaml b/Documentation/devicetree/bindings/display/msm/qcom,adreno-6xx.yaml
new file mode 100644
index 000000000000..89106ff2215f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,adreno-6xx.yaml
@@ -0,0 +1,160 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,adreno-6xx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Adreno 6xx GPU
+
+maintainers:
+ - Rob Clark <robdclark@gmail.com>
+
+description:
+ Device tree bindings for Adreno 600 series of GPU.
+
+select:
+ properties:
+ compatible:
+ contains:
+ pattern: '^qcom,adreno-[67][0-9][0-9]\.[0-9]$'
+ required:
+ - compatible
+
+$ref: /schemas/display/msm/qcom,adreno-common.yaml#
+
+properties:
+ compatible:
+ contains:
+ pattern: '^qcom,adreno-[67][0-9][0-9]\.[0-9]$'
+
+allOf:
+ - $ref: qcom,adreno-common.yaml#
+ - if:
+ properties:
+ compatible:
+ items:
+ - enum:
+ - qcom,adreno-610.0
+ - qcom,adreno-619.1
+ - const: qcom,adreno
+ then:
+ properties:
+ clocks:
+ minItems: 6
+ maxItems: 6
+
+ clock-names:
+ items:
+ - const: core
+ description: GPU Core clock
+ - const: iface
+ description: GPU Interface clock
+ - const: mem_iface
+ description: GPU Memory Interface clock
+ - const: alt_mem_iface
+ description: GPU Alternative Memory Interface clock
+ - const: gmu
+ description: CX GMU clock
+ - const: xo
+ description: GPUCC clocksource clock
+
+ reg-names:
+ minItems: 1
+ items:
+ - const: kgsl_3d0_reg_memory
+ - const: cx_dbgc
+
+ required:
+ - clocks
+ - clock-names
+ - power-domains
+ else:
+ properties:
+ clocks: false
+ clock-names: false
+ power-domains: false
+
+ reg-names:
+ minItems: 1
+ items:
+ - const: kgsl_3d0_reg_memory
+ - const: cx_mem
+ - const: cx_dbgc
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ // Example a6xx (with GMU):
+
+ #include <dt-bindings/clock/qcom,gpucc-sdm845.h>
+ #include <dt-bindings/clock/qcom,gcc-sdm845.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interconnect/qcom,sdm845.h>
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ zap_shader_region: memory@8f200000 {
+ compatible = "shared-dma-pool";
+ reg = <0x0 0x90b00000 0x0 0xa00000>;
+ no-map;
+ };
+ };
+
+ gpu@5000000 {
+ compatible = "qcom,adreno-630.2", "qcom,adreno";
+
+ reg = <0x5000000 0x40000>, <0x509e000 0x10>;
+ reg-names = "kgsl_3d0_reg_memory", "cx_mem";
+
+ #cooling-cells = <2>;
+
+ interrupts = <GIC_SPI 300 IRQ_TYPE_LEVEL_HIGH>;
+
+ iommus = <&adreno_smmu 0>;
+
+ operating-points-v2 = <&gpu_opp_table>;
+
+ interconnects = <&rsc_hlos MASTER_GFX3D &rsc_hlos SLAVE_EBI1>;
+ interconnect-names = "gfx-mem";
+
+ qcom,gmu = <&gmu>;
+
+ gpu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-430000000 {
+ opp-hz = /bits/ 64 <430000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_SVS_L1>;
+ opp-peak-kBps = <5412000>;
+ };
+
+ opp-355000000 {
+ opp-hz = /bits/ 64 <355000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_SVS>;
+ opp-peak-kBps = <3072000>;
+ };
+
+ opp-267000000 {
+ opp-hz = /bits/ 64 <267000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
+ opp-peak-kBps = <3072000>;
+ };
+
+ opp-180000000 {
+ opp-hz = /bits/ 64 <180000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_MIN_SVS>;
+ opp-peak-kBps = <1804000>;
+ };
+ };
+
+ zap-shader {
+ memory-region = <&zap_shader_region>;
+ firmware-name = "qcom/LENOVO/81JL/qcdxkmsuc850.mbn";
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,adreno-common.yaml b/Documentation/devicetree/bindings/display/msm/qcom,adreno-common.yaml
new file mode 100644
index 000000000000..592d45de6c0b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,adreno-common.yaml
@@ -0,0 +1,112 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,adreno-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Adreno common properties
+
+maintainers:
+ - Rob Clark <robdclark@gmail.com>
+
+description:
+ Device tree bindings for Adreno GPUs
+
+select:
+ false
+
+properties:
+ $nodename:
+ pattern: "^gpu@[0-9a-f]+$"
+
+ reg:
+ minItems: 1
+ maxItems: 3
+
+ reg-names:
+ minItems: 1
+ maxItems: 3
+
+ power-domains:
+ maxItems: 1
+
+ clocks:
+ minItems: 2
+ maxItems: 7
+
+ clock-names:
+ minItems: 2
+ maxItems: 7
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ maxItems: 1
+
+ interconnects:
+ minItems: 1
+ maxItems: 2
+
+ interconnect-names:
+ minItems: 1
+ maxItems: 2
+
+ iommus:
+ minItems: 1
+ maxItems: 64
+
+ sram:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ minItems: 1
+ maxItems: 4
+ items:
+ maxItems: 1
+ description: |
+ phandles to one or more reserved on-chip SRAM regions.
+ phandle to the On Chip Memory (OCMEM) that's present on some a3xx and
+ a4xx Snapdragon SoCs. See
+ Documentation/devicetree/bindings/sram/qcom,ocmem.yaml
+
+ operating-points-v2: true
+ opp-table:
+ type: object
+
+ zap-shader:
+ type: object
+ additionalProperties: false
+ description: |
+ For a5xx and a6xx devices this node contains a memory-region that
+ points to reserved memory to store the zap shader that can be used to
+ help bring the GPU out of secure mode.
+ properties:
+ memory-region:
+ maxItems: 1
+
+ firmware-name:
+ description: |
+ Default name of the firmware to load to the remote processor.
+
+ "#cooling-cells":
+ const: 2
+
+ nvmem-cell-names:
+ maxItems: 1
+
+ nvmem-cells:
+ description: efuse registers
+ maxItems: 1
+
+ qcom,gmu:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: |
+ For GMU attached devices a phandle to the GMU device that will
+ control the power for the GPU.
+
+required:
+ - reg
+ - reg-names
+ - interrupts
+ - iommus
+
+additionalProperties: true
--
2.44.0
^ permalink raw reply related
* [RFC PATCH 0/1] Split Adreno schemas
From: Adam Skladowski @ 2024-03-26 20:05 UTC (permalink / raw)
Cc: phone-devel, ~postmarketos/upstreaming, Adam Skladowski,
Rob Clark, Abhinav Kumar, Dmitry Baryshkov, Sean Paul,
Marijn Suijten, David Airlie, Daniel Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, dri-devel,
freedreno, devicetree, linux-kernel
Following recommendation from Dmitry Baryshkov this series split schema
into separate schemas per gpu family, as i don't really understand much
of yamls and dt-schema i decided to send this as RFC and if there
are any changes suggested i will be glad if these can be explained
to me in ELI5 format.
Adam Skladowski (1):
dt-bindings: display/msm: gpu: Split Adreno schemas into separate
files
.../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(-)
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
--
2.44.0
^ permalink raw reply
* [PATCH v10 2/2] dt-bindings: mtd: fixed-partition: Add binman compatibles
From: Simon Glass @ 2024-03-26 20:06 UTC (permalink / raw)
To: devicetree
Cc: Michael Walle, U-Boot Mailing List, Miquel Raynal, Tom Rini,
Rob Herring, linux-mtd, Simon Glass, Conor Dooley,
Krzysztof Kozlowski, Rafał Miłecki, Richard Weinberger,
Vignesh Raghavendra, linux-kernel
In-Reply-To: <20240326200645.1182803-1-sjg@chromium.org>
Add two compatibles for binman entries, as a starting point for the
schema.
Note that, after discussion on v2, we decided to keep the existing
meaning of label so as not to require changes to existing userspace
software when moving to use binman nodes to specify the firmware
layout.
Note also that, after discussion on v6, we decided to use the same
'fixed-partition' schema for the binman features, so this version
adds a new 'binman.yaml' file providing the new compatibles to the
existing partition.yaml binding.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v10:
- Drop binman,entry since it is likely not necessary
- Put the description back
Changes in v8:
- Switch the patch ordering so the partition change comes first
Changes in v7:
- Adjust MAINTAINERS entry
- Put compatible strings into the 'fixed-partition' binding
Changes in v5:
- Add mention of why 'binman' is the vendor
- Drop 'select: false'
- Tidy up the compatible setings
- Use 'tfa-bl31' instead of 'atf-bl31'
Changes in v4:
- Correct selection of multiple compatible strings
Changes in v3:
- Drop fixed-partitions from the example
- Use compatible instead of label
Changes in v2:
- Use plain partition@xxx for the node name
.../bindings/mtd/partitions/binman.yaml | 53 +++++++++++++++++++
.../bindings/mtd/partitions/partition.yaml | 21 ++++++++
MAINTAINERS | 5 ++
3 files changed, 79 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/partitions/binman.yaml
diff --git a/Documentation/devicetree/bindings/mtd/partitions/binman.yaml b/Documentation/devicetree/bindings/mtd/partitions/binman.yaml
new file mode 100644
index 000000000000..bb4b08546184
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/partitions/binman.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/partitions/binman.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Binman entries
+
+description: |
+ This corresponds to a binman 'entry'. It is a single partition which holds
+ data of a defined type.
+
+ Binman uses the type to indicate what data file / type to place in the
+ partition. There are quite a number of binman-specific entry types, such as
+ section, fill and files, to be added later.
+
+maintainers:
+ - Simon Glass <sjg@chromium.org>
+
+allOf:
+ - $ref: /schemas/mtd/partitions/partition.yaml#
+
+properties:
+ compatible:
+ enum:
+ - u-boot # u-boot.bin from U-Boot project
+ - tfa-bl31 # bl31.bin or bl31.elf from TF-A project
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@100000 {
+ compatible = "u-boot";
+ reg = <0x100000 0xf00000>;
+ align-size = <0x1000>;
+ align-end = <0x10000>;
+ };
+
+ partition@200000 {
+ compatible = "tfa-bl31";
+ reg = <0x200000 0x100000>;
+ align = <0x4000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mtd/partitions/partition.yaml b/Documentation/devicetree/bindings/mtd/partitions/partition.yaml
index 656ca3db1762..bb3c326c6588 100644
--- a/Documentation/devicetree/bindings/mtd/partitions/partition.yaml
+++ b/Documentation/devicetree/bindings/mtd/partitions/partition.yaml
@@ -118,3 +118,24 @@ then:
# This is a generic file other binding inherit from and extend
additionalProperties: true
+
+examples:
+ - |
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@100000 {
+ compatible = "u-boot";
+ reg = <0x100000 0xf00000>;
+ align-size = <0x1000>;
+ align-end = <0x10000>;
+ };
+
+ partition@200000 {
+ compatible = "tfa-bl31";
+ reg = <0x200000 0x100000>;
+ align = <0x4000>;
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index a848d6ca67e4..1eeb6ebde21f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3639,6 +3639,11 @@ F: Documentation/filesystems/bfs.rst
F: fs/bfs/
F: include/uapi/linux/bfs_fs.h
+BINMAN
+M: Simon Glass <sjg@chromium.org>
+S: Supported
+F: Documentation/devicetree/bindings/mtd/partitions/binman*
+
BITMAP API
M: Yury Norov <yury.norov@gmail.com>
R: Rasmus Villemoes <linux@rasmusvillemoes.dk>
--
2.34.1
^ permalink raw reply related
* [PATCH v10 1/2] dt-bindings: mtd: fixed-partitions: Add alignment properties
From: Simon Glass @ 2024-03-26 20:06 UTC (permalink / raw)
To: devicetree
Cc: Michael Walle, U-Boot Mailing List, Miquel Raynal, Tom Rini,
Rob Herring, linux-mtd, Simon Glass, Conor Dooley,
Krzysztof Kozlowski, Rafał Miłecki, Richard Weinberger,
Vignesh Raghavendra, linux-kernel
Add three properties for controlling alignment of partitions, aka
'entries' in fixed-partition.
For now there is no explicit mention of hierarchy, so a 'section' is
just the 'fixed-partitions' node.
These new properties are inputs to the Binman packaging process, but are
also needed if the firmware is repacked, to ensure that alignment
constraints are not violated. Therefore they are provided as part of
the schema.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Changes in v10:
- Update the minimum to 2
Changes in v9:
- Move binding example to next batch to avoid build error
Changes in v7:
- Drop patch 'Add binman compatible'
- Put the alignment properties into the fixed-partition binding
Changes in v6:
- Correct schema-validation errors missed due to older dt-schema
(enum fix and reg addition)
Changes in v5:
- Add value ranges
- Consistently mention alignment must be power-of-2
- Mention that alignment refers to bytes
Changes in v2:
- Fix 'a' typo in commit message
.../bindings/mtd/partitions/partition.yaml | 51 +++++++++++++++++++
1 file changed, 51 insertions(+)
diff --git a/Documentation/devicetree/bindings/mtd/partitions/partition.yaml b/Documentation/devicetree/bindings/mtd/partitions/partition.yaml
index 1ebe9e2347ea..656ca3db1762 100644
--- a/Documentation/devicetree/bindings/mtd/partitions/partition.yaml
+++ b/Documentation/devicetree/bindings/mtd/partitions/partition.yaml
@@ -57,6 +57,57 @@ properties:
user space from
type: boolean
+ align:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 2
+ maximum: 0x80000000
+ multipleOf: 2
+ description:
+ This sets the alignment of the entry in bytes.
+
+ The entry offset is adjusted so that the entry starts on an aligned
+ boundary within the containing section or image. For example ‘align =
+ <16>’ means that the entry will start on a 16-byte boundary. This may
+ mean that padding is added before the entry. The padding is part of
+ the containing section but is not included in the entry, meaning that
+ an empty space may be created before the entry starts. Alignment
+ must be a power of 2. If ‘align’ is not provided, no alignment is
+ performed.
+
+ align-size:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 2
+ maximum: 0x80000000
+ multipleOf: 2
+ description:
+ This sets the alignment of the entry size in bytes. It must be a power
+ of 2.
+
+ For example, to ensure that the size of an entry is a multiple of 64
+ bytes, set this to 64. While this does not affect the contents of the
+ entry within binman itself (the padding is performed only when its
+ parent section is assembled), the end result is that the entry ends
+ with the padding bytes, so may grow. If ‘align-size’ is not provided,
+ no alignment is performed.
+
+ align-end:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 2
+ maximum: 0x80000000
+ multipleOf: 2
+ description:
+ This sets the alignment (in bytes) of the end of an entry with respect
+ to the containing section. It must be a power of 2.
+
+ Some entries require that they end on an alignment boundary,
+ regardless of where they start. This does not move the start of the
+ entry, so the contents of the entry will still start at the beginning.
+ But there may be padding at the end. While this does not affect the
+ contents of the entry within binman itself (the padding is performed
+ only when its parent section is assembled), the end result is that the
+ entry ends with the padding bytes, so may grow. If ‘align-end’ is not
+ provided, no alignment is performed.
+
if:
not:
required: [ reg ]
--
2.34.1
^ permalink raw reply related
* [PATCH 4/4] arm64: dts: qcom: sc8180x: add dp_p1 register blocks to DP nodes
From: Dmitry Baryshkov @ 2024-03-26 20:02 UTC (permalink / raw)
To: Rob Clark, Abhinav Kumar, Sean Paul, Marijn Suijten, David Airlie,
Daniel Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Vinod Koul
Cc: linux-arm-msm, dri-devel, freedreno, devicetree, Dmitry Baryshkov
In-Reply-To: <20240326-fd-fix-schema-v1-0-4475d6d6d633@linaro.org>
DisplayPort nodes must declare the dp_p1 register space in addition to
dp_p0. Add corresponding resource to DisplayPort DT nodes.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
arch/arm64/boot/dts/qcom/sc8180x.dtsi | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc8180x.dtsi b/arch/arm64/boot/dts/qcom/sc8180x.dtsi
index 6d74867d3b61..019104bd70fb 100644
--- a/arch/arm64/boot/dts/qcom/sc8180x.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc8180x.dtsi
@@ -3029,7 +3029,8 @@ mdss_dp0: displayport-controller@ae90000 {
reg = <0 0xae90000 0 0x200>,
<0 0xae90200 0 0x200>,
<0 0xae90400 0 0x600>,
- <0 0xae90a00 0 0x400>;
+ <0 0xae90a00 0 0x400>,
+ <0 0xae91000 0 0x400>;
interrupt-parent = <&mdss>;
interrupts = <12>;
clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
@@ -3105,7 +3106,8 @@ mdss_dp1: displayport-controller@ae98000 {
reg = <0 0xae98000 0 0x200>,
<0 0xae98200 0 0x200>,
<0 0xae98400 0 0x600>,
- <0 0xae98a00 0 0x400>;
+ <0 0xae98a00 0 0x400>,
+ <0 0xae99000 0 0x400>;
interrupt-parent = <&mdss>;
interrupts = <13>;
clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
--
2.39.2
^ permalink raw reply related
* [PATCH 3/4] arm64: dts: qcom: sc8180x: Drop flags for mdss irqs
From: Dmitry Baryshkov @ 2024-03-26 20:02 UTC (permalink / raw)
To: Rob Clark, Abhinav Kumar, Sean Paul, Marijn Suijten, David Airlie,
Daniel Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Vinod Koul
Cc: linux-arm-msm, dri-devel, freedreno, devicetree, Dmitry Baryshkov
In-Reply-To: <20240326-fd-fix-schema-v1-0-4475d6d6d633@linaro.org>
The number of interrupt cells for the mdss interrupt controller is 1,
meaning there should only be one cell for the interrupt number, not two.
Drop the second cell containing (unused) irq flags.
Fixes: 494dec9b6f54 ("arm64: dts: qcom: sc8180x: Add display and gpu nodes")
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
arch/arm64/boot/dts/qcom/sc8180x.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc8180x.dtsi b/arch/arm64/boot/dts/qcom/sc8180x.dtsi
index 99462b42cfc5..6d74867d3b61 100644
--- a/arch/arm64/boot/dts/qcom/sc8180x.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc8180x.dtsi
@@ -2804,7 +2804,7 @@ mdss_mdp: mdp@ae01000 {
power-domains = <&rpmhpd SC8180X_MMCX>;
interrupt-parent = <&mdss>;
- interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <0>;
ports {
#address-cells = <1>;
@@ -2877,7 +2877,7 @@ mdss_dsi0: dsi@ae94000 {
reg-names = "dsi_ctrl";
interrupt-parent = <&mdss>;
- interrupts = <4 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <4>;
clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK>,
<&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>,
@@ -2963,7 +2963,7 @@ mdss_dsi1: dsi@ae96000 {
reg-names = "dsi_ctrl";
interrupt-parent = <&mdss>;
- interrupts = <5 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <5>;
clocks = <&dispcc DISP_CC_MDSS_BYTE1_CLK>,
<&dispcc DISP_CC_MDSS_BYTE1_INTF_CLK>,
--
2.39.2
^ permalink raw reply related
* [PATCH 2/4] arm64: dts: qcom: sc8180x: drop legacy property #stream-id-cells
From: Dmitry Baryshkov @ 2024-03-26 20:02 UTC (permalink / raw)
To: Rob Clark, Abhinav Kumar, Sean Paul, Marijn Suijten, David Airlie,
Daniel Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Vinod Koul
Cc: linux-arm-msm, dri-devel, freedreno, devicetree, Dmitry Baryshkov
In-Reply-To: <20240326-fd-fix-schema-v1-0-4475d6d6d633@linaro.org>
The property #stream-id-cells is legacy, it is not documented as valid
for the GPU. Drop it now.
Fixes: 494dec9b6f54 ("arm64: dts: qcom: sc8180x: Add display and gpu nodes")
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
arch/arm64/boot/dts/qcom/sc8180x.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sc8180x.dtsi b/arch/arm64/boot/dts/qcom/sc8180x.dtsi
index 32afc78d5b76..99462b42cfc5 100644
--- a/arch/arm64/boot/dts/qcom/sc8180x.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc8180x.dtsi
@@ -2225,7 +2225,6 @@ tcsr_mutex: hwlock@1f40000 {
gpu: gpu@2c00000 {
compatible = "qcom,adreno-680.1", "qcom,adreno";
- #stream-id-cells = <16>;
reg = <0 0x02c00000 0 0x40000>;
reg-names = "kgsl_3d0_reg_memory";
--
2.39.2
^ permalink raw reply related
* [PATCH 1/4] dt-bindings: display/msm: sm8150-mdss: add DP node
From: Dmitry Baryshkov @ 2024-03-26 20:02 UTC (permalink / raw)
To: Rob Clark, Abhinav Kumar, Sean Paul, Marijn Suijten, David Airlie,
Daniel Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Vinod Koul
Cc: linux-arm-msm, dri-devel, freedreno, devicetree, Dmitry Baryshkov
In-Reply-To: <20240326-fd-fix-schema-v1-0-4475d6d6d633@linaro.org>
As Qualcomm SM8150 got support for the DisplayPort, add displayport@
node as a valid child to the MDSS node.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
.../devicetree/bindings/display/msm/qcom,sm8150-mdss.yaml | 10 ++++++++++
1 file changed, 10 insertions(+)
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
+
"^dsi@[0-9a-f]+$":
type: object
additionalProperties: true
--
2.39.2
^ permalink raw reply related
* [PATCH 0/4] arm64: dts: fix several display-related schema warnings
From: Dmitry Baryshkov @ 2024-03-26 20:02 UTC (permalink / raw)
To: Rob Clark, Abhinav Kumar, Sean Paul, Marijn Suijten, David Airlie,
Daniel Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Vinod Koul
Cc: linux-arm-msm, dri-devel, freedreno, devicetree, Dmitry Baryshkov
Fix several warnings produced by the display nodes.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
Dmitry Baryshkov (4):
dt-bindings: display/msm: sm8150-mdss: add DP node
arm64: dts: qcom: sc8180x: drop legacy property #stream-id-cells
arm64: dts: qcom: sc8180x: Drop flags for mdss irqs
arm64: dts: qcom: sc8180x: add dp_p1 register blocks to DP nodes
.../devicetree/bindings/display/msm/qcom,sm8150-mdss.yaml | 10 ++++++++++
arch/arm64/boot/dts/qcom/sc8180x.dtsi | 13 +++++++------
2 files changed, 17 insertions(+), 6 deletions(-)
---
base-commit: 13ee4a7161b6fd938aef6688ff43b163f6d83e37
change-id: 20240326-fd-fix-schema-b91f94a95135
Best regards,
--
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
^ permalink raw reply
* [PATCH v2 3/3] ARM: dts: bcm283x: Drop unneeded properties in the bcm2835-firmware node
From: Laurent Pinchart @ 2024-03-26 19:58 UTC (permalink / raw)
To: devicetree, linux-rpi-kernel, linux-arm-kernel
Cc: Dave Stevenson, Naushir Patuck,
Broadcom internal kernel review list, Conor Dooley,
Florian Fainelli, Krzysztof Kozlowski, Nicolas Saenz Julienne,
Ray Jui, Rob Herring, Scott Branden, Stefan Wahren
In-Reply-To: <20240326195807.15163-1-laurent.pinchart@ideasonboard.com>
The firmware node contains a "dma-ranges" property to enable usage of
the DMA mapping API with its child devices, along with "#address-cells"
and "#size-cells" properties to support the dma-ranges. This was needed
due to usage of the incorrect device to perform the DMA mapping in
drivers. Now that this has been fixed, drop the properties.
This effectively reverts commits be08d278eb09 ("ARM: dts: bcm283x: Add
cells encoding format to firmware bus") and 55c7c0621078 ("ARM: dts:
bcm283x: Fix vc4's firmware bus DMA limitations").
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
arch/arm/boot/dts/broadcom/bcm2835-rpi.dtsi | 4 ----
1 file changed, 4 deletions(-)
diff --git a/arch/arm/boot/dts/broadcom/bcm2835-rpi.dtsi b/arch/arm/boot/dts/broadcom/bcm2835-rpi.dtsi
index f0acc9390f31..761a9da97bd0 100644
--- a/arch/arm/boot/dts/broadcom/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/broadcom/bcm2835-rpi.dtsi
@@ -4,11 +4,7 @@ / {
soc {
firmware: firmware {
compatible = "raspberrypi,bcm2835-firmware", "simple-mfd";
- #address-cells = <1>;
- #size-cells = <1>;
-
mboxes = <&mailbox>;
- dma-ranges;
};
power: power {
--
Regards,
Laurent Pinchart
^ permalink raw reply related
* [PATCH v2 2/3] firmware: raspberrypi: Use correct device for DMA mappings
From: Laurent Pinchart @ 2024-03-26 19:58 UTC (permalink / raw)
To: devicetree, linux-rpi-kernel, linux-arm-kernel
Cc: Dave Stevenson, Naushir Patuck,
Broadcom internal kernel review list, Conor Dooley,
Florian Fainelli, Krzysztof Kozlowski, Nicolas Saenz Julienne,
Ray Jui, Rob Herring, Scott Branden, Stefan Wahren
In-Reply-To: <20240326195807.15163-1-laurent.pinchart@ideasonboard.com>
The buffer used to transfer data over the mailbox interface is mapped
using the client's device. This is incorrect, as the device performing
the DMA transfer is the mailbox itself. Fix it by using the mailbox
controller device instead.
This requires including the mailbox_controller.h header to dereference
the mbox_chan and mbox_controller structures. The header is not meant to
be included by clients. This could be fixed by extending the client API
with a function to access the controller's device.
Fixes: 4e3d60656a72 ("ARM: bcm2835: Add the Raspberry Pi firmware driver")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
drivers/firmware/raspberrypi.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
index 322aada20f74..ac34876a97f8 100644
--- a/drivers/firmware/raspberrypi.c
+++ b/drivers/firmware/raspberrypi.c
@@ -9,6 +9,7 @@
#include <linux/dma-mapping.h>
#include <linux/kref.h>
#include <linux/mailbox_client.h>
+#include <linux/mailbox_controller.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_platform.h>
@@ -97,8 +98,8 @@ int rpi_firmware_property_list(struct rpi_firmware *fw,
if (size & 3)
return -EINVAL;
- buf = dma_alloc_coherent(fw->cl.dev, PAGE_ALIGN(size), &bus_addr,
- GFP_ATOMIC);
+ buf = dma_alloc_coherent(fw->chan->mbox->dev, PAGE_ALIGN(size),
+ &bus_addr, GFP_ATOMIC);
if (!buf)
return -ENOMEM;
@@ -126,7 +127,7 @@ int rpi_firmware_property_list(struct rpi_firmware *fw,
ret = -EINVAL;
}
- dma_free_coherent(fw->cl.dev, PAGE_ALIGN(size), buf, bus_addr);
+ dma_free_coherent(fw->chan->mbox->dev, PAGE_ALIGN(size), buf, bus_addr);
return ret;
}
--
Regards,
Laurent Pinchart
^ permalink raw reply related
* [PATCH v2 1/3] dt-bindings: arm: bcm: raspberrypi,bcm2835-firmware: Add gpio child node
From: Laurent Pinchart @ 2024-03-26 19:58 UTC (permalink / raw)
To: devicetree, linux-rpi-kernel, linux-arm-kernel
Cc: Dave Stevenson, Naushir Patuck, Bartosz Golaszewski,
Broadcom internal kernel review list, Conor Dooley,
Florian Fainelli, Krzysztof Kozlowski, Linus Walleij, Ray Jui,
Rob Herring, Scott Branden, Stefan Wahren
In-Reply-To: <20240326195807.15163-1-laurent.pinchart@ideasonboard.com>
Unlike the other child nodes of the raspberrypi,bcm2835-firmware device,
the gpio child is documented in a legacy text-based binding in
gpio/raspberrypi,firmware-gpio.txt. This causes DT validation failures:
arch/arm64/boot/dts/broadcom/bcm2711-rpi-4-b.dtb: 'gpio' does not match any of the regexes: 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/arm/bcm/raspberrypi,bcm2835-firmware.yaml#
Convert the binding to YAML and move it to
raspberrypi,bcm2835-firmware.yaml.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
Changes since v1:
- Add minItems for gpio-line-names
---
.../arm/bcm/raspberrypi,bcm2835-firmware.yaml | 30 +++++++++++++++++++
.../gpio/raspberrypi,firmware-gpio.txt | 30 -------------------
2 files changed, 30 insertions(+), 30 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/gpio/raspberrypi,firmware-gpio.txt
diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
index 39e3c248f5b7..1f84407a73e4 100644
--- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
+++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
@@ -46,6 +46,30 @@ properties:
- compatible
- "#clock-cells"
+ gpio:
+ type: object
+ additionalProperties: false
+
+ properties:
+ compatible:
+ const: raspberrypi,firmware-gpio
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+ description:
+ The first cell is the pin number, and the second cell is used to
+ specify the gpio polarity (GPIO_ACTIVE_HIGH or GPIO_ACTIVE_LOW).
+
+ gpio-line-names:
+ minItems: 8
+
+ required:
+ - compatible
+ - gpio-controller
+ - "#gpio-cells"
+
reset:
type: object
additionalProperties: false
@@ -96,6 +120,12 @@ examples:
#clock-cells = <1>;
};
+ expgpio: gpio {
+ compatible = "raspberrypi,firmware-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
reset: reset {
compatible = "raspberrypi,firmware-reset";
#reset-cells = <1>;
diff --git a/Documentation/devicetree/bindings/gpio/raspberrypi,firmware-gpio.txt b/Documentation/devicetree/bindings/gpio/raspberrypi,firmware-gpio.txt
deleted file mode 100644
index ce97265e23ba..000000000000
--- a/Documentation/devicetree/bindings/gpio/raspberrypi,firmware-gpio.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-Raspberry Pi GPIO expander
-
-The Raspberry Pi 3 GPIO expander is controlled by the VC4 firmware. The
-firmware exposes a mailbox interface that allows the ARM core to control the
-GPIO lines on the expander.
-
-The Raspberry Pi GPIO expander node must be a child node of the Raspberry Pi
-firmware node.
-
-Required properties:
-
-- compatible : Should be "raspberrypi,firmware-gpio"
-- gpio-controller : Marks the device node as a gpio controller
-- #gpio-cells : Should be two. The first cell is the pin number, and
- the second cell is used to specify the gpio polarity:
- 0 = active high
- 1 = active low
-
-Example:
-
-firmware: firmware-rpi {
- compatible = "raspberrypi,bcm2835-firmware";
- mboxes = <&mailbox>;
-
- expgpio: gpio {
- compatible = "raspberrypi,firmware-gpio";
- gpio-controller;
- #gpio-cells = <2>;
- };
-};
--
Regards,
Laurent Pinchart
^ permalink raw reply related
* [PATCH v2 0/3] dt-bindings: arm: bcm: raspberrypi,bcm2835-firmware: Drive-by fixes
From: Laurent Pinchart @ 2024-03-26 19:58 UTC (permalink / raw)
To: devicetree, linux-rpi-kernel, linux-arm-kernel
Cc: Dave Stevenson, Naushir Patuck, Bartosz Golaszewski,
Broadcom internal kernel review list, Conor Dooley,
Florian Fainelli, Krzysztof Kozlowski, Linus Walleij,
Nicolas Saenz Julienne, Ray Jui, Rob Herring, Scott Branden,
Stefan Wahren
Hello,
This small series includes a few drive-by fixes for DT validation
errors.
The first patch has been posted previously in v1 ([1], and now addresses
a small review comment. I think it's good to go.
The next two patches address the same issue as "[PATCH 1/2] dt-bindings:
arm: bcm: raspberrypi,bcm2835-firmware: Add missing properties" ([2]),
but this time with a (hopefully) correct approach. Patch 2/3 starts by
fixing the raspberrypi-bcm2835-firmware driver, removing the need for DT
properties that are specified in bcm2835-rpi.dtsi but not documented in
the corresponding bindings. Patch 3/3 can then drop those properties,
getting rid of the warnings.
[1] https://lore.kernel.org/linux-arm-kernel/20240326004902.17054-3-laurent.pinchart@ideasonboard.com/
[2] https://lore.kernel.org/linux-arm-kernel/20240326004902.17054-2-laurent.pinchart@ideasonboard.com/
Laurent Pinchart (3):
dt-bindings: arm: bcm: raspberrypi,bcm2835-firmware: Add gpio child
node
firmware: raspberrypi: Use correct device for DMA mappings
ARM: dts: bcm283x: Drop unneeded properties in the bcm2835-firmware
node
.../arm/bcm/raspberrypi,bcm2835-firmware.yaml | 30 +++++++++++++++++++
.../gpio/raspberrypi,firmware-gpio.txt | 30 -------------------
arch/arm/boot/dts/broadcom/bcm2835-rpi.dtsi | 4 ---
drivers/firmware/raspberrypi.c | 7 +++--
4 files changed, 34 insertions(+), 37 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/gpio/raspberrypi,firmware-gpio.txt
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] arm64: dts: rockchip: quartzpro64: Enable the GPU
From: Dragan Simic @ 2024-03-26 19:57 UTC (permalink / raw)
To: Sebastian Reichel
Cc: linux-rockchip, heiko, linux-arm-kernel, devicetree, robh+dt,
krzysztof.kozlowski+dt, conor+dt, boris.brezillon, linux-kernel,
kernel
In-Reply-To: <jbyqey5y5ngr7mkrrmdxrwyw5ogd7rq56af6mrmhsckboanvyp@tcaav2tridos>
Hello Sebastian,
On 2024-03-26 20:54, Sebastian Reichel wrote:
> On Mon, Mar 25, 2024 at 05:19:04PM +0100, Dragan Simic wrote:
>> Following the approach used to enable the Mali GPU on the rk3588-evb1,
>> [1]
>> do the same for the Pine64 QuartzPro64, which uses nearly identical
>> hardware
>> design as the RK3588 EVB1.
>>
>> The slight disadvantage is that the regulator coupling logic requires
>> the
>> regulators to be always on, which is also noted in the comments. This
>> is
>> obviously something to be improved at some point in the future, but
>> should
>> be fine for now, especially because the QuartzPro64 isn't a
>> battery-powered
>> board, so low power consumption isn't paramount.
>>
>> [1]
>> https://lore.kernel.org/linux-rockchip/20240325153850.189128-5-sebastian.reichel@collabora.com/
>>
>> Signed-off-by: Dragan Simic <dsimic@manjaro.org>
>> ---
>
> FWIW
>
> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Great, thanks for your review!
>> .../arm64/boot/dts/rockchip/rk3588-quartzpro64.dts | 14
>> ++++++++++++++
>> 1 file changed, 14 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dts
>> b/arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dts
>> index 67414d72e2b6..68d432c61ea5 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dts
>> +++ b/arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dts
>> @@ -285,6 +285,12 @@ &gmac0_rgmii_clk
>> status = "okay";
>> };
>>
>> +&gpu {
>> + mali-supply = <&vdd_gpu_s0>;
>> + sram-supply = <&vdd_gpu_mem_s0>;
>> + status = "okay";
>> +};
>> +
>> &i2c2 {
>> status = "okay";
>>
>> @@ -491,11 +497,15 @@ rk806_dvs3_null: dvs3-null-pins {
>> regulators {
>> vdd_gpu_s0: dcdc-reg1 {
>> regulator-name = "vdd_gpu_s0";
>> + /* regulator coupling requires always-on */
>> + regulator-always-on;
>> regulator-boot-on;
>> regulator-enable-ramp-delay = <400>;
>> regulator-min-microvolt = <550000>;
>> regulator-max-microvolt = <950000>;
>> regulator-ramp-delay = <12500>;
>> + regulator-coupled-with = <&vdd_gpu_mem_s0>;
>> + regulator-coupled-max-spread = <10000>;
>>
>> regulator-state-mem {
>> regulator-off-in-suspend;
>> @@ -545,11 +555,15 @@ regulator-state-mem {
>>
>> vdd_gpu_mem_s0: dcdc-reg5 {
>> regulator-name = "vdd_gpu_mem_s0";
>> + /* regulator coupling requires always-on */
>> + regulator-always-on;
>> regulator-boot-on;
>> regulator-enable-ramp-delay = <400>;
>> regulator-min-microvolt = <675000>;
>> regulator-max-microvolt = <950000>;
>> regulator-ramp-delay = <12500>;
>> + regulator-coupled-with = <&vdd_gpu_s0>;
>> + regulator-coupled-max-spread = <10000>;
>>
>> regulator-state-mem {
>> regulator-off-in-suspend;
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [PATCH RESEND v6 0/5] spmi: pmic-arb: Add support for multiple buses
From: Abel Vesa @ 2024-03-26 19:57 UTC (permalink / raw)
To: Rob Herring
Cc: Stephen Boyd, Matthias Brugger, Bjorn Andersson, Konrad Dybcio,
Dmitry Baryshkov, Neil Armstrong, AngeloGioacchino Del Regno,
Krzysztof Kozlowski, Conor Dooley, Srini Kandagatla, Johan Hovold,
linux-kernel, linux-arm-kernel, linux-arm-msm, linux-mediatek,
devicetree
In-Reply-To: <20240326193203.GA3252922-robh@kernel.org>
On 24-03-26 14:32:03, Rob Herring wrote:
> On Tue, Mar 26, 2024 at 06:28:15PM +0200, Abel Vesa wrote:
> > This RFC prepares for and adds support for 2 buses, which is supported
> > in HW starting with version 7. Until now, none of the currently
> > supported platforms in upstream have used the second bus. The X1E80100
> > platform, on the other hand, needs the second bus for the USB2.0 to work
> > as there are 3 SMB2360 PMICs which provide eUSB2 repeaters and they are
> > all found on the second bus.
> >
> > Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
> > ---
> > Changes in v6:
> > - Changed the compatible to platform specific (X1E80100) along with the
> > schema. Fixed the spmi buses unit addresses and added the empty ranges
> > property. Added missing properties to the spmi buses and the
> > "unevaluatedProperties: false".
> > - Deprecated the "qcom,bus-id" in the legacy schema.
> > - Changed the driver to check for legacy compatible first
> > - Link to v5: https://lore.kernel.org/r/20240221-spmi-multi-master-support-v5-0-3255ca413a0b@linaro.org
>
> Where are Krzysztof's Reviewed-by tags?
Urgh, did "b4 send --resend" which only sent the v5 as it was before the
Reviewed-by tags have been picked up.
My bad.
I'll send a v6 with the tags appended.
>
> Rob
^ permalink raw reply
* Re: [PATCH 1/3] phy: rockchip: emmc: Enable pulldown for strobe line
From: Dragan Simic @ 2024-03-26 19:55 UTC (permalink / raw)
To: Conor Dooley
Cc: dev, Vinod Koul, Kishon Vijay Abraham I, Heiko Stuebner,
Chris Ruehl, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Christopher Obbard, Alban Browaeys, Doug Anderson, Brian Norris,
Jensen Huang, linux-phy, linux-arm-kernel, linux-rockchip,
linux-kernel, devicetree
In-Reply-To: <20240326-tactical-onlooker-3df8d2352dc2@spud>
Hello Conor and Folker,
On 2024-03-26 20:46, Conor Dooley wrote:
> On Tue, Mar 26, 2024 at 07:54:35PM +0100, Folker Schwesinger via B4
> Relay wrote:
>> From: Folker Schwesinger <dev@folker-schwesinger.de>
>>
>> Restore the behavior of the Rockchip kernel that undconditionally
>> enables the internal strobe pulldown.
>
> What do you mean "restore the behaviour of the rockchip kernel"? Did
> mainline behave the same as the rockchip kernel previously? If not,
> using "restore" here is misleading. "Unconditionally" is also
> incorrect,
> because you have a property that disables it.
>
>> As the DT property rockchip,enable-strobe-pulldown is obsolete now,
>> replace it with a property to disable the internal pulldown.
>>
>> This fixes I/O errors observed on various Rock Pi 4 and NanoPi4 series
>> boards with some eMMC modules. Other boards may also be affected.
>>
>> An example of these errors is as follows:
>>
>> [ 290.060817] mmc1: running CQE recovery
>> [ 290.061337] blk_update_request: I/O error, dev mmcblk1, sector
>> 1411072 op 0x1:(WRITE) flags 0x800 phys_seg 36 prio class 0
>> [ 290.061370] EXT4-fs warning (device mmcblk1p1): ext4_end_bio:348:
>> I/O error 10 writing to inode 29547 starting block 176466)
>> [ 290.061484] Buffer I/O error on device mmcblk1p1, logical block
>> 172288
>>
>> Fixes: 8b5c2b45b8f0 ("phy: rockchip: set pulldown for strobe line in
>> dts")
>> Signed-off-by: Folker Schwesinger <dev@folker-schwesinger.de>
>> ---
>> drivers/phy/rockchip/phy-rockchip-emmc.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/phy/rockchip/phy-rockchip-emmc.c
>> b/drivers/phy/rockchip/phy-rockchip-emmc.c
>> index 20023f6eb994..6e637f3e1b19 100644
>> --- a/drivers/phy/rockchip/phy-rockchip-emmc.c
>> +++ b/drivers/phy/rockchip/phy-rockchip-emmc.c
>> @@ -376,14 +376,14 @@ static int rockchip_emmc_phy_probe(struct
>> platform_device *pdev)
>> rk_phy->reg_offset = reg_offset;
>> rk_phy->reg_base = grf;
>> rk_phy->drive_impedance = PHYCTRL_DR_50OHM;
>> - rk_phy->enable_strobe_pulldown = PHYCTRL_REN_STRB_DISABLE;
>> + rk_phy->enable_strobe_pulldown = PHYCTRL_REN_STRB_ENABLE;
>> rk_phy->output_tapdelay_select = PHYCTRL_OTAPDLYSEL_DEFAULT;
>>
>> if (!of_property_read_u32(dev->of_node, "drive-impedance-ohm",
>> &val))
>> rk_phy->drive_impedance = convert_drive_impedance_ohm(pdev, val);
>>
>> - if (of_property_read_bool(dev->of_node,
>> "rockchip,enable-strobe-pulldown"))
>> - rk_phy->enable_strobe_pulldown = PHYCTRL_REN_STRB_ENABLE;
>> + if (of_property_read_bool(dev->of_node,
>> "rockchip,disable-strobe-pulldown"))
>> + rk_phy->enable_strobe_pulldown = PHYCTRL_REN_STRB_DISABLE;
>
> Unfortunately you cannot do this.
> Previously no property at all meant disabled and a property was
> required
> to enable it. With this change the absence of a property means that it
> will be enabled.
> An old devicetree is that wanted this to be disabled would have no
> property and will now end up with it enabled. This is an ABI break and
> is
> clearly not backwards compatible, that's a NAK unless it is
> demonstrable
> that noone actually wants to disable it at all.
Moreover, as I already explained some time ago, [1] some boards and
devices are unfortunately miswired, and we don't want to enable the
DATA STROBE pull-down on such boards.
[1]
https://lore.kernel.org/linux-rockchip/ca5b7cad01f645c7c559ab26a8db8085@manjaro.org/#t
> If this patch fixes a problem on a board that you have, I would suggest
> that you add the property to enable it, as the binding tells you to.
>
> Thanks,
> Conor.
>
>> if (!of_property_read_u32(dev->of_node,
>> "rockchip,output-tapdelay-select", &val)) {
>> if (val <= PHYCTRL_OTAPDLYSEL_MAXVALUE)
>>
>> --
>> 2.44.0
>>
>>
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [PATCH] arm64: dts: rockchip: quartzpro64: Enable the GPU
From: Sebastian Reichel @ 2024-03-26 19:54 UTC (permalink / raw)
To: Dragan Simic
Cc: linux-rockchip, heiko, linux-arm-kernel, devicetree, robh+dt,
krzysztof.kozlowski+dt, conor+dt, boris.brezillon, linux-kernel,
kernel
In-Reply-To: <0f3759ee390f245dac447bbee038445ddfecbec0.1711383286.git.dsimic@manjaro.org>
[-- Attachment #1: Type: text/plain, Size: 2699 bytes --]
Hi,
On Mon, Mar 25, 2024 at 05:19:04PM +0100, Dragan Simic wrote:
> Following the approach used to enable the Mali GPU on the rk3588-evb1, [1]
> do the same for the Pine64 QuartzPro64, which uses nearly identical hardware
> design as the RK3588 EVB1.
>
> The slight disadvantage is that the regulator coupling logic requires the
> regulators to be always on, which is also noted in the comments. This is
> obviously something to be improved at some point in the future, but should
> be fine for now, especially because the QuartzPro64 isn't a battery-powered
> board, so low power consumption isn't paramount.
>
> [1] https://lore.kernel.org/linux-rockchip/20240325153850.189128-5-sebastian.reichel@collabora.com/
>
> Signed-off-by: Dragan Simic <dsimic@manjaro.org>
> ---
FWIW
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-- Sebastian
> .../arm64/boot/dts/rockchip/rk3588-quartzpro64.dts | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dts b/arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dts
> index 67414d72e2b6..68d432c61ea5 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dts
> @@ -285,6 +285,12 @@ &gmac0_rgmii_clk
> status = "okay";
> };
>
> +&gpu {
> + mali-supply = <&vdd_gpu_s0>;
> + sram-supply = <&vdd_gpu_mem_s0>;
> + status = "okay";
> +};
> +
> &i2c2 {
> status = "okay";
>
> @@ -491,11 +497,15 @@ rk806_dvs3_null: dvs3-null-pins {
> regulators {
> vdd_gpu_s0: dcdc-reg1 {
> regulator-name = "vdd_gpu_s0";
> + /* regulator coupling requires always-on */
> + regulator-always-on;
> regulator-boot-on;
> regulator-enable-ramp-delay = <400>;
> regulator-min-microvolt = <550000>;
> regulator-max-microvolt = <950000>;
> regulator-ramp-delay = <12500>;
> + regulator-coupled-with = <&vdd_gpu_mem_s0>;
> + regulator-coupled-max-spread = <10000>;
>
> regulator-state-mem {
> regulator-off-in-suspend;
> @@ -545,11 +555,15 @@ regulator-state-mem {
>
> vdd_gpu_mem_s0: dcdc-reg5 {
> regulator-name = "vdd_gpu_mem_s0";
> + /* regulator coupling requires always-on */
> + regulator-always-on;
> regulator-boot-on;
> regulator-enable-ramp-delay = <400>;
> regulator-min-microvolt = <675000>;
> regulator-max-microvolt = <950000>;
> regulator-ramp-delay = <12500>;
> + regulator-coupled-with = <&vdd_gpu_s0>;
> + regulator-coupled-max-spread = <10000>;
>
> regulator-state-mem {
> regulator-off-in-suspend;
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] phy: rockchip: emmc: Enable pulldown for strobe line
From: Conor Dooley @ 2024-03-26 19:46 UTC (permalink / raw)
To: dev
Cc: Vinod Koul, Kishon Vijay Abraham I, Heiko Stuebner, Chris Ruehl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Christopher Obbard, Alban Browaeys, Doug Anderson, Brian Norris,
Jensen Huang, linux-phy, linux-arm-kernel, linux-rockchip,
linux-kernel, devicetree
In-Reply-To: <20240326-rk-default-enable-strobe-pulldown-v1-1-f410c71605c0@folker-schwesinger.de>
[-- Attachment #1: Type: text/plain, Size: 3387 bytes --]
On Tue, Mar 26, 2024 at 07:54:35PM +0100, Folker Schwesinger via B4 Relay wrote:
> From: Folker Schwesinger <dev@folker-schwesinger.de>
>
> Restore the behavior of the Rockchip kernel that undconditionally
> enables the internal strobe pulldown.
What do you mean "restore the behaviour of the rockchip kernel"? Did
mainline behave the same as the rockchip kernel previously? If not,
using "restore" here is misleading. "Unconditionally" is also incorrect,
because you have a property that disables it.
> As the DT property rockchip,enable-strobe-pulldown is obsolete now,
> replace it with a property to disable the internal pulldown.
>
> This fixes I/O errors observed on various Rock Pi 4 and NanoPi4 series
> boards with some eMMC modules. Other boards may also be affected.
>
> An example of these errors is as follows:
>
> [ 290.060817] mmc1: running CQE recovery
> [ 290.061337] blk_update_request: I/O error, dev mmcblk1, sector 1411072 op 0x1:(WRITE) flags 0x800 phys_seg 36 prio class 0
> [ 290.061370] EXT4-fs warning (device mmcblk1p1): ext4_end_bio:348: I/O error 10 writing to inode 29547 starting block 176466)
> [ 290.061484] Buffer I/O error on device mmcblk1p1, logical block 172288
>
> Fixes: 8b5c2b45b8f0 ("phy: rockchip: set pulldown for strobe line in dts")
> Signed-off-by: Folker Schwesinger <dev@folker-schwesinger.de>
> ---
> drivers/phy/rockchip/phy-rockchip-emmc.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/phy/rockchip/phy-rockchip-emmc.c b/drivers/phy/rockchip/phy-rockchip-emmc.c
> index 20023f6eb994..6e637f3e1b19 100644
> --- a/drivers/phy/rockchip/phy-rockchip-emmc.c
> +++ b/drivers/phy/rockchip/phy-rockchip-emmc.c
> @@ -376,14 +376,14 @@ static int rockchip_emmc_phy_probe(struct platform_device *pdev)
> rk_phy->reg_offset = reg_offset;
> rk_phy->reg_base = grf;
> rk_phy->drive_impedance = PHYCTRL_DR_50OHM;
> - rk_phy->enable_strobe_pulldown = PHYCTRL_REN_STRB_DISABLE;
> + rk_phy->enable_strobe_pulldown = PHYCTRL_REN_STRB_ENABLE;
> rk_phy->output_tapdelay_select = PHYCTRL_OTAPDLYSEL_DEFAULT;
>
> if (!of_property_read_u32(dev->of_node, "drive-impedance-ohm", &val))
> rk_phy->drive_impedance = convert_drive_impedance_ohm(pdev, val);
>
> - if (of_property_read_bool(dev->of_node, "rockchip,enable-strobe-pulldown"))
> - rk_phy->enable_strobe_pulldown = PHYCTRL_REN_STRB_ENABLE;
> + if (of_property_read_bool(dev->of_node, "rockchip,disable-strobe-pulldown"))
> + rk_phy->enable_strobe_pulldown = PHYCTRL_REN_STRB_DISABLE;
Unfortunately you cannot do this.
Previously no property at all meant disabled and a property was required
to enable it. With this change the absence of a property means that it
will be enabled.
An old devicetree is that wanted this to be disabled would have no
property and will now end up with it enabled. This is an ABI break and is
clearly not backwards compatible, that's a NAK unless it is demonstrable
that noone actually wants to disable it at all.
If this patch fixes a problem on a board that you have, I would suggest
that you add the property to enable it, as the binding tells you to.
Thanks,
Conor.
> if (!of_property_read_u32(dev->of_node, "rockchip,output-tapdelay-select", &val)) {
> if (val <= PHYCTRL_OTAPDLYSEL_MAXVALUE)
>
> --
> 2.44.0
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] devicetree: phy: rockchip-emmc: Document changed strobe-pulldown property
From: Conor Dooley @ 2024-03-26 19:34 UTC (permalink / raw)
To: dev
Cc: Vinod Koul, Kishon Vijay Abraham I, Heiko Stuebner, Chris Ruehl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Christopher Obbard, Alban Browaeys, Doug Anderson, Brian Norris,
Jensen Huang, linux-phy, linux-arm-kernel, linux-rockchip,
linux-kernel, devicetree
In-Reply-To: <20240326-rk-default-enable-strobe-pulldown-v1-2-f410c71605c0@folker-schwesinger.de>
[-- Attachment #1: Type: text/plain, Size: 2010 bytes --]
On Tue, Mar 26, 2024 at 07:54:36PM +0100, Folker Schwesinger via B4 Relay wrote:
> From: Folker Schwesinger <dev@folker-schwesinger.de>
The prefix is "dt-bindings" not "devicetree" FYI.
>
> Document the changes regarding the optional strobe-pulldown property.
> These changes are necessary as the default behavior of the driver was
> restored to the Rockchip kernel behavior of enabling the internal
> pulldown by default.
I don't think this is a valid justification, but it'll be easier for me
to explain this on the driver patch.
Thanks,
Conor.
>
> Fixes: f34e43f12382 ("devicetree: phy: rockchip-emmc: pulldown property")
> Signed-off-by: Folker Schwesinger <dev@folker-schwesinger.de>
> ---
> Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt b/Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt
> index 57d28c0d5696..10c05437f7ab 100644
> --- a/Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt
> @@ -16,8 +16,8 @@ Optional properties:
> - drive-impedance-ohm: Specifies the drive impedance in Ohm.
> Possible values are 33, 40, 50, 66 and 100.
> If not set, the default value of 50 will be applied.
> - - rockchip,enable-strobe-pulldown: Enable internal pull-down for the strobe
> - line. If not set, pull-down is not used.
> + - rockchip,disable-strobe-pulldown: Disable internal pull-down for the strobe
> + line. If not set, pull-down is used.
> - rockchip,output-tapdelay-select: Specifies the phyctrl_otapdlysec register.
> If not set, the register defaults to 0x4.
> Maximum value 0xf.
>
> --
> 2.44.0
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 0/4] arm64: dts: rockchip: add wolfvision pf5 mainboard
From: Heiko Stübner @ 2024-03-26 19:33 UTC (permalink / raw)
To: Michael Riesch, Rob Herring
Cc: linux-kernel, linux-arm-kernel, linux-rockchip,
Krzysztof Kozlowski, devicetree, Conor Dooley
In-Reply-To: <171148006579.3222626.4177463381080253015.robh@kernel.org>
Am Dienstag, 26. März 2024, 20:11:58 CET schrieb Rob Herring:
>
> On Mon, 25 Mar 2024 15:22:30 +0100, Michael Riesch wrote:
> > Habidere,
> >
> > This series adds the device tree for the WolfVision PF5 mainboard, which
> > serves as base for recent WolfVision products. It features the Rockchip
> > RK3568 and can be extended with several different extension boards.
> >
> > The WolfVision PF5 IO Expander is one example of such an extension board.
> > The corresponding device tree overlay is also included in this series.
> >
> > May this be the beginning of a beautiful friendship :-)
> >
> > Looking forward to your comments!
> >
> > Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net>
> > ---
> > Michael Riesch (4):
> > dt-bindings: add wolfvision vendor prefix
> > dt-bindings: arm: rockchip: add wolfvision pf5 mainboard
> > arm64: dts: rockchip: add wolfvision pf5 mainboard
> > arm64: dts: rockchip: add wolfvision pf5 io expander board
> >
> > .../devicetree/bindings/arm/rockchip.yaml | 5 +
> > .../devicetree/bindings/vendor-prefixes.yaml | 2 +
> > arch/arm64/boot/dts/rockchip/Makefile | 2 +
> > .../rk3568-wolfvision-pf5-io-expander.dtso | 137 ++++++
> > .../boot/dts/rockchip/rk3568-wolfvision-pf5.dts | 528 +++++++++++++++++++++
> > 5 files changed, 674 insertions(+)
> > ---
> > base-commit: 4cece764965020c22cff7665b18a012006359095
> > change-id: 20240325-feature-wolfvision-pf5-5c1924c0389c
> >
> > Best regards,
> > --
> > Michael Riesch <michael.riesch@wolfvision.net>
> >
> >
> >
>
>
> My bot found new DTB warnings on the .dts files added or changed in this
> series.
>
> Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
> are fixed by another series. Ultimately, it is up to the platform
> maintainer whether these warnings are acceptable or not. No need to reply
> unless the platform maintainer has comments.
>
> If you already ran DT checks and didn't see these error(s), then
> make sure dt-schema is up to date:
>
> pip3 install dtschema --upgrade
>
>
> New warnings running 'make CHECK_DTBS=y rockchip/rk3568-wolfvision-pf5.dtb' for 20240325-feature-wolfvision-pf5-v1-0-5725445f792a@wolfvision.net:
>
> arch/arm64/boot/dts/rockchip/rk3568-wolfvision-pf5.dtb: hdmi@fe0a0000: Unevaluated properties are not allowed ('#sound-dai-cells' was unexpected)
> from schema $id: http://devicetree.org/schemas/display/rockchip/rockchip,dw-hdmi.yaml#
just for the record, this is not the fault of the Wolfvision board,
but caused by an undocumented property in the core hdmi node.
I've prepared a fix for the binding in [0], but as Krzysztof noted,
this patch needs a v2 with a change.
Heiko
[0] https://lore.kernel.org/dri-devel/20240326172801.1163200-1-heiko@sntech.de/
^ permalink raw reply
* Re: [PATCH v4 4/4] remoteproc: stm32: Add support of an OP-TEE TA to load the firmware
From: Arnaud POULIQUEN @ 2024-03-26 19:31 UTC (permalink / raw)
To: Mathieu Poirier
Cc: Bjorn Andersson, Jens Wiklander, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-stm32, linux-arm-kernel, linux-remoteproc,
linux-kernel, op-tee, devicetree
In-Reply-To: <ZgGrnkcebcIQQic6@p14s>
On 3/25/24 17:51, Mathieu Poirier wrote:
> On Fri, Mar 08, 2024 at 03:47:08PM +0100, Arnaud Pouliquen wrote:
>> The new TEE remoteproc device is used to manage remote firmware in a
>> secure, trusted context. The 'st,stm32mp1-m4-tee' compatibility is
>> introduced to delegate the loading of the firmware to the trusted
>> execution context. In such cases, the firmware should be signed and
>> adhere to the image format defined by the TEE.
>>
>> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
>> ---
>> Updates from V3:
>> - remove support of the attach use case. Will be addressed in a separate
>> thread,
>> - add st_rproc_tee_ops::parse_fw ops,
>> - inverse call of devm_rproc_alloc()and tee_rproc_register() to manage cross
>> reference between the rproc struct and the tee_rproc struct in tee_rproc.c.
>> ---
>> drivers/remoteproc/stm32_rproc.c | 60 +++++++++++++++++++++++++++++---
>> 1 file changed, 56 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/remoteproc/stm32_rproc.c b/drivers/remoteproc/stm32_rproc.c
>> index 8cd838df4e92..13df33c78aa2 100644
>> --- a/drivers/remoteproc/stm32_rproc.c
>> +++ b/drivers/remoteproc/stm32_rproc.c
>> @@ -20,6 +20,7 @@
>> #include <linux/remoteproc.h>
>> #include <linux/reset.h>
>> #include <linux/slab.h>
>> +#include <linux/tee_remoteproc.h>
>> #include <linux/workqueue.h>
>>
>> #include "remoteproc_internal.h"
>> @@ -49,6 +50,9 @@
>> #define M4_STATE_STANDBY 4
>> #define M4_STATE_CRASH 5
>>
>> +/* Remote processor unique identifier aligned with the Trusted Execution Environment definitions */
>
> Why is this the case? At least from the kernel side it is possible to call
> tee_rproc_register() with any kind of value, why is there a need to be any
> kind of alignment with the TEE?
The use of the proc_id is to identify a processor in case of multi co-processors.
For instance we can have a system with A DSP and a modem. We would use the same
TEE service, but
the TEE driver will probably be different, same for the signature key.
In such case the proc ID allows to identify the the processor you want to address.
>
>> +#define STM32_MP1_M4_PROC_ID 0
>> +
>> struct stm32_syscon {
>> struct regmap *map;
>> u32 reg;
>> @@ -257,6 +261,19 @@ static int stm32_rproc_release(struct rproc *rproc)
>> return 0;
>> }
>>
>> +static int stm32_rproc_tee_stop(struct rproc *rproc)
>> +{
>> + int err;
>> +
>> + stm32_rproc_request_shutdown(rproc);
>> +
>> + err = tee_rproc_stop(rproc);
>> + if (err)
>> + return err;
>> +
>> + return stm32_rproc_release(rproc);
>> +}
>> +
>> static int stm32_rproc_prepare(struct rproc *rproc)
>> {
>> struct device *dev = rproc->dev.parent;
>> @@ -693,8 +710,19 @@ static const struct rproc_ops st_rproc_ops = {
>> .get_boot_addr = rproc_elf_get_boot_addr,
>> };
>>
>> +static const struct rproc_ops st_rproc_tee_ops = {
>> + .prepare = stm32_rproc_prepare,
>> + .start = tee_rproc_start,
>> + .stop = stm32_rproc_tee_stop,
>> + .kick = stm32_rproc_kick,
>> + .load = tee_rproc_load_fw,
>> + .parse_fw = tee_rproc_parse_fw,
>> + .find_loaded_rsc_table = tee_rproc_find_loaded_rsc_table,
>> +};
>> +
>> static const struct of_device_id stm32_rproc_match[] = {
>> - { .compatible = "st,stm32mp1-m4" },
>> + {.compatible = "st,stm32mp1-m4",},
>> + {.compatible = "st,stm32mp1-m4-tee",},
>> {},
>> };
>> MODULE_DEVICE_TABLE(of, stm32_rproc_match);
>> @@ -853,6 +881,7 @@ static int stm32_rproc_probe(struct platform_device *pdev)
>> struct device *dev = &pdev->dev;
>> struct stm32_rproc *ddata;
>> struct device_node *np = dev->of_node;
>> + struct tee_rproc *trproc = NULL;
>> struct rproc *rproc;
>> unsigned int state;
>> int ret;
>> @@ -861,9 +890,26 @@ static int stm32_rproc_probe(struct platform_device *pdev)
>> if (ret)
>> return ret;
>>
>> - rproc = devm_rproc_alloc(dev, np->name, &st_rproc_ops, NULL, sizeof(*ddata));
>> - if (!rproc)
>> - return -ENOMEM;
>> + if (of_device_is_compatible(np, "st,stm32mp1-m4-tee")) {
>> + /*
>> + * Delegate the firmware management to the secure context.
>> + * The firmware loaded has to be signed.
>> + */
>> + rproc = devm_rproc_alloc(dev, np->name, &st_rproc_tee_ops, NULL, sizeof(*ddata));
>> + if (!rproc)
>> + return -ENOMEM;
>> +
>> + trproc = tee_rproc_register(dev, rproc, STM32_MP1_M4_PROC_ID);
>> + if (IS_ERR(trproc)) {
>> + dev_err_probe(dev, PTR_ERR(trproc),
>> + "signed firmware not supported by TEE\n");
>> + return PTR_ERR(trproc);
>> + }
>> + } else {
>> + rproc = devm_rproc_alloc(dev, np->name, &st_rproc_ops, NULL, sizeof(*ddata));
>> + if (!rproc)
>> + return -ENOMEM;
>> + }
>>
>> ddata = rproc->priv;
>>
>> @@ -915,6 +961,9 @@ static int stm32_rproc_probe(struct platform_device *pdev)
>> dev_pm_clear_wake_irq(dev);
>> device_init_wakeup(dev, false);
>> }
>> + if (trproc)
>
> if (rproc->tee_interface)
>
>
> I am done reviewing this set.
Thank for your review!
Arnaud
>
> Thanks,
> Mathieu
>
>> + tee_rproc_unregister(trproc);
>> +
>> return ret;
>> }
>>
>> @@ -935,6 +984,9 @@ static void stm32_rproc_remove(struct platform_device *pdev)
>> dev_pm_clear_wake_irq(dev);
>> device_init_wakeup(dev, false);
>> }
>> + if (rproc->tee_interface)
>> + tee_rproc_unregister(rproc->tee_interface);
>> +
>> }
>>
>> static int stm32_rproc_suspend(struct device *dev)
>> --
>> 2.25.1
>>
^ permalink raw reply
* Re: [PATCH RESEND v6 0/5] spmi: pmic-arb: Add support for multiple buses
From: Rob Herring @ 2024-03-26 19:32 UTC (permalink / raw)
To: Abel Vesa
Cc: Stephen Boyd, Matthias Brugger, Bjorn Andersson, Konrad Dybcio,
Dmitry Baryshkov, Neil Armstrong, AngeloGioacchino Del Regno,
Krzysztof Kozlowski, Conor Dooley, Srini Kandagatla, Johan Hovold,
linux-kernel, linux-arm-kernel, linux-arm-msm, linux-mediatek,
devicetree
In-Reply-To: <20240326-spmi-multi-master-support-v6-0-1c87d8306c5b@linaro.org>
On Tue, Mar 26, 2024 at 06:28:15PM +0200, Abel Vesa wrote:
> This RFC prepares for and adds support for 2 buses, which is supported
> in HW starting with version 7. Until now, none of the currently
> supported platforms in upstream have used the second bus. The X1E80100
> platform, on the other hand, needs the second bus for the USB2.0 to work
> as there are 3 SMB2360 PMICs which provide eUSB2 repeaters and they are
> all found on the second bus.
>
> Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
> ---
> Changes in v6:
> - Changed the compatible to platform specific (X1E80100) along with the
> schema. Fixed the spmi buses unit addresses and added the empty ranges
> property. Added missing properties to the spmi buses and the
> "unevaluatedProperties: false".
> - Deprecated the "qcom,bus-id" in the legacy schema.
> - Changed the driver to check for legacy compatible first
> - Link to v5: https://lore.kernel.org/r/20240221-spmi-multi-master-support-v5-0-3255ca413a0b@linaro.org
Where are Krzysztof's Reviewed-by tags?
Rob
^ permalink raw reply
* Re: [PATCH] dt-bindings: display: rockchip: add missing #sound-dai-cells to dw-hdmi
From: Heiko Stübner @ 2024-03-26 19:29 UTC (permalink / raw)
To: hjc, andy.yan, robh, krzysztof.kozlowski+dt, conor+dt,
Krzysztof Kozlowski
Cc: dri-devel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <5fb55234-4afd-4e6a-9763-4d2e344e0ce6@linaro.org>
Am Dienstag, 26. März 2024, 18:50:37 CET schrieb Krzysztof Kozlowski:
> On 26/03/2024 18:50, Krzysztof Kozlowski wrote:
> > On 26/03/2024 18:28, Heiko Stuebner wrote:
> >> The #sound-dai-cells DT property is required to describe link between
> >> the HDMI IP block and the SoC's audio subsystem.
> >>
> >> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> >> ---
> >> .../devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> >> index af638b6c0d21..3768df80ca7a 100644
> >> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> >> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> >> @@ -124,6 +124,9 @@ properties:
> >> description:
> >> phandle to the GRF to mux vopl/vopb.
> >>
> >> + "#sound-dai-cells":
> >> + const: 0
> >> +
> >
> > Then you miss $ref in allOf to /schemas/sound/dai-common.yaml
>
> I meant, except your change you should add also above $ref.
sorry about that, will fix that.
Thanks for the pointer
Heiko
^ permalink raw reply
* Re: [PATCH v3 net-next 1/2] dt-bindings: net: airoha,en8811h: Add en8811h
From: Rob Herring @ 2024-03-26 19:29 UTC (permalink / raw)
To: Eric Woudstra
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Krzysztof Kozlowski, Conor Dooley, Andrew Lunn, Heiner Kallweit,
Russell King, Matthias Brugger, AngeloGioacchino Del Regno,
Frank Wunderlich, Daniel Golle, Lucien Jheng, Zhi-Jun You, netdev,
devicetree
In-Reply-To: <20240326162305.303598-2-ericwouds@gmail.com>
On Tue, Mar 26, 2024 at 05:23:04PM +0100, Eric Woudstra wrote:
> Add the Airoha EN8811H 2.5 Gigabit PHY.
>
> The en8811h phy can be set with serdes polarity reversed on rx and/or tx.
>
> Signed-off-by: Eric Woudstra <ericwouds@gmail.com>
Did you change something or forget to add Krzysztof's Reviewed-by?
> ---
> .../bindings/net/airoha,en8811h.yaml | 56 +++++++++++++++++++
> 1 file changed, 56 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/airoha,en8811h.yaml
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox