Add the compatible strings for the display controller found in the
UMS9230 SoC and bindings for a gate clock. Add IOMMU-related bindings
to the display-subsystem node.
Signed-off-by: Otto Pflüger <otto.pflueger@abscue.de>
---
.../bindings/display/sprd/sprd,display-subsystem.yaml | 11 +++++++++++
.../bindings/display/sprd/sprd,sharkl3-dpu.yaml | 18 +++++++++++++-----
.../bindings/display/sprd/sprd,sharkl3-dsi-host.yaml | 11 ++++++++---
3 files changed, 32 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml b/Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml
index b3d5e1b96fae2f24ff2afb26c9c3ce0212856be4..d02f79c602f515533f60a993539ed7cd82ce22ec 100644
--- a/Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml
+++ b/Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml
@@ -43,6 +43,17 @@ properties:
compatible:
const: sprd,display-subsystem
+ iommus:
+ maxItems: 1
+
+ memory-region:
+ maxItems: 1
+ description:
+ A phandle to the framebuffer region configured by the bootloader. This
+ can be used together with an iommu-addresses property on the reserved
+ memory region to create an initial passthrough mapping for the boot
+ splash framebuffer.
+
ports:
$ref: /schemas/types.yaml#/definitions/phandle-array
items:
diff --git a/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml
index 4ebea60b8c5ba5f177854e3a8d89e93e7304e18b..6fedb6e508b247eb71da17ced589b8ed09085592 100644
--- a/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml
+++ b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml
@@ -16,7 +16,12 @@ description: |
properties:
compatible:
- const: sprd,sharkl3-dpu
+ oneOf:
+ - items:
+ - enum:
+ - sprd,ums9230-dpu
+ - const: sprd,sharkl3-dpu
+ - const: sprd,sharkl3-dpu
reg:
maxItems: 1
@@ -25,12 +30,15 @@ properties:
maxItems: 1
clocks:
- minItems: 2
+ minItems: 1
clock-names:
- items:
- - const: clk_src_128m
- - const: clk_src_384m
+ oneOf:
+ - items:
+ - const: clk_src_128m
+ - const: clk_src_384m
+ - items:
+ - const: enable
power-domains:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml
index bc5594d18643010b91376c92a8f235a522d7dc3d..8438d2da0a4277db03e30b13cb270684c0c360cb 100644
--- a/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml
+++ b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml
@@ -11,7 +11,9 @@ maintainers:
properties:
compatible:
- const: sprd,sharkl3-dsi-host
+ enum:
+ - sprd,sharkl3-dsi-host
+ - sprd,ums9230-dsi-host
reg:
maxItems: 1
@@ -23,8 +25,11 @@ properties:
minItems: 1
clock-names:
- items:
- - const: clk_src_96m
+ oneOf:
+ - items:
+ - const: clk_src_96m
+ - items:
+ - const: enable
power-domains:
maxItems: 1
--
2.50.0
On 19/07/2025 14:09, Otto Pflüger wrote: > diff --git a/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml > index 4ebea60b8c5ba5f177854e3a8d89e93e7304e18b..6fedb6e508b247eb71da17ced589b8ed09085592 100644 > --- a/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml > +++ b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml > @@ -16,7 +16,12 @@ description: | > > properties: > compatible: > - const: sprd,sharkl3-dpu > + oneOf: > + - items: > + - enum: > + - sprd,ums9230-dpu > + - const: sprd,sharkl3-dpu > + - const: sprd,sharkl3-dpu > > reg: > maxItems: 1 > @@ -25,12 +30,15 @@ properties: > maxItems: 1 > > clocks: > - minItems: 2 > + minItems: 1 This is wrong. You miss maxItems. I will fix existing bindings. > > clock-names: > - items: > - - const: clk_src_128m > - - const: clk_src_384m > + oneOf: > + - items: > + - const: clk_src_128m > + - const: clk_src_384m > + - items: > + - const: enable > > power-domains: > maxItems: 1 > diff --git a/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml > index bc5594d18643010b91376c92a8f235a522d7dc3d..8438d2da0a4277db03e30b13cb270684c0c360cb 100644 > --- a/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml > +++ b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml > @@ -11,7 +11,9 @@ maintainers: > > properties: > compatible: > - const: sprd,sharkl3-dsi-host > + enum: > + - sprd,sharkl3-dsi-host > + - sprd,ums9230-dsi-host > > reg: > maxItems: 1 > @@ -23,8 +25,11 @@ properties: > minItems: 1 > > clock-names: > - items: > - - const: clk_src_96m > + oneOf: > + - items: > + - const: clk_src_96m > + - items: > + - const: enable Why this is completely different clock? How same class device could have completely different clock INPUT? > > power-domains: > maxItems: 1 > Best regards, Krzysztof
On Sun, Jul 20, 2025 at 02:26:19PM +0200, Krzysztof Kozlowski wrote: > On 19/07/2025 14:09, Otto Pflüger wrote: > > diff --git a/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml > > index 4ebea60b8c5ba5f177854e3a8d89e93e7304e18b..6fedb6e508b247eb71da17ced589b8ed09085592 100644 > > --- a/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml > > +++ b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml > > @@ -16,7 +16,12 @@ description: | > > > > properties: > > compatible: > > - const: sprd,sharkl3-dpu > > + oneOf: > > + - items: > > + - enum: > > + - sprd,ums9230-dpu > > + - const: sprd,sharkl3-dpu > > + - const: sprd,sharkl3-dpu > > > > reg: > > maxItems: 1 > > @@ -25,12 +30,15 @@ properties: > > maxItems: 1 > > > > clocks: > > - minItems: 2 > > + minItems: 1 > > This is wrong. You miss maxItems. I will fix existing bindings. Will fix this, thanks. > > > > > clock-names: > > - items: > > - - const: clk_src_128m > > - - const: clk_src_384m > > + oneOf: > > + - items: > > + - const: clk_src_128m > > + - const: clk_src_384m > > + - items: > > + - const: enable > > > > power-domains: > > maxItems: 1 > > diff --git a/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml > > index bc5594d18643010b91376c92a8f235a522d7dc3d..8438d2da0a4277db03e30b13cb270684c0c360cb 100644 > > --- a/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml > > +++ b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml > > @@ -11,7 +11,9 @@ maintainers: > > > > properties: > > compatible: > > - const: sprd,sharkl3-dsi-host > > + enum: > > + - sprd,sharkl3-dsi-host > > + - sprd,ums9230-dsi-host > > > > reg: > > maxItems: 1 > > @@ -23,8 +25,11 @@ properties: > > minItems: 1 > > > > clock-names: > > - items: > > - - const: clk_src_96m > > + oneOf: > > + - items: > > + - const: clk_src_96m > > + - items: > > + - const: enable > > Why this is completely different clock? How same class device could have > completely different clock INPUT? The clocks should be the same on sharkl3 (sc9863a) and ums9230, but the existing bindings don't really make sense here or are incomplete. AFAIK there is no SoC in which this display controller is directly connected to the PLL as shown in the example. The DSI controller is connected to a clock gate. The DPU actually does have two clocks, both of which are clock muxes that allow selecting different frequencies and one of which is behind a clock gate. I can add the second clock for the DPU if needed. Since nothing seems to be using these bindings at the moment, would it be okay to drop the old clock names that refer to specific frequencies? > > > > > power-domains: > > maxItems: 1 > > > > > Best regards, > Krzysztof
On 20/07/2025 15:55, Otto Pflüger wrote: >>> >>> clock-names: >>> - items: >>> - - const: clk_src_96m >>> + oneOf: >>> + - items: >>> + - const: clk_src_96m >>> + - items: >>> + - const: enable >> >> Why this is completely different clock? How same class device could have >> completely different clock INPUT? > > The clocks should be the same on sharkl3 (sc9863a) and ums9230, but > the existing bindings don't really make sense here or are incomplete. > AFAIK there is no SoC in which this display controller is directly > connected to the PLL as shown in the example. The DSI controller is This is not the PLL. Gate either. You are looking from wrong side - how clock is generated. You describe here CLOCK INPUT. > connected to a clock gate. The DPU actually does have two clocks, both > of which are clock muxes that allow selecting different frequencies and > one of which is behind a clock gate. I can add the second clock for the > DPU if needed. > > Since nothing seems to be using these bindings at the moment, would it > be okay to drop the old clock names that refer to specific frequencies? It is still completely irrelevant whether these are muxes. Dropping existing properties is ABI change, but anyway first figure out what is here really. Best regards, Krzysztof
On Sun, Jul 20, 2025 at 05:38:02PM +0200, Krzysztof Kozlowski wrote: > > > > The clocks should be the same on sharkl3 (sc9863a) and ums9230, but > > the existing bindings don't really make sense here or are incomplete. > > AFAIK there is no SoC in which this display controller is directly > > connected to the PLL as shown in the example. The DSI controller is > > This is not the PLL. Gate either. You are looking from wrong side - how > clock is generated. > > You describe here CLOCK INPUT. > > > connected to a clock gate. The DPU actually does have two clocks, both > > of which are clock muxes that allow selecting different frequencies and > > one of which is behind a clock gate. I can add the second clock for the > > DPU if needed. > > > > Since nothing seems to be using these bindings at the moment, would it > > be okay to drop the old clock names that refer to specific frequencies? > > It is still completely irrelevant whether these are muxes. Dropping > existing properties is ABI change, but anyway first figure out what is > here really. I was trying to point out that the existing clock names are incorrect because they refer to a specific source that is not necessarily used for these clocks, instead of giving a name for the clock input. For the DPU, would "core" and "dpi" be more appropriate as clock names? DPI refers to the interface used internally between the DPU and the DSI controller. For the DSI controller, it seems that the clock is actually an APB bus clock needed for accessing the control registers. Again, it is not required to be connected to a 96MHz clock source as the name used in the binding suggests. Would something like "apb_clk" or "pclk" be more descriptive?
On Sun, Jul 20, 2025 at 07:35:24PM +0200, Otto Pflüger wrote: > On Sun, Jul 20, 2025 at 05:38:02PM +0200, Krzysztof Kozlowski wrote: > > > > > > The clocks should be the same on sharkl3 (sc9863a) and ums9230, but > > > the existing bindings don't really make sense here or are incomplete. > > > AFAIK there is no SoC in which this display controller is directly > > > connected to the PLL as shown in the example. The DSI controller is > > > > This is not the PLL. Gate either. You are looking from wrong side - how > > clock is generated. > > > > You describe here CLOCK INPUT. > > > > > connected to a clock gate. The DPU actually does have two clocks, both > > > of which are clock muxes that allow selecting different frequencies and > > > one of which is behind a clock gate. I can add the second clock for the > > > DPU if needed. > > > > > > Since nothing seems to be using these bindings at the moment, would it > > > be okay to drop the old clock names that refer to specific frequencies? > > > > It is still completely irrelevant whether these are muxes. Dropping > > existing properties is ABI change, but anyway first figure out what is > > here really. > > I was trying to point out that the existing clock names are incorrect > because they refer to a specific source that is not necessarily used > for these clocks, instead of giving a name for the clock input. OK, if the old name refers to the same clock input as in your new device, you can deprecate old case in the binding. > > For the DPU, would "core" and "dpi" be more appropriate as clock names? > DPI refers to the interface used internally between the DPU and the DSI > controller. Sounds fine. > > For the DSI controller, it seems that the clock is actually an APB bus > clock needed for accessing the control registers. Again, it is not > required to be connected to a 96MHz clock source as the name used in the > binding suggests. Would something like "apb_clk" or "pclk" be more > descriptive? Yeah, both are correct. I think pclk is preferred. Best regards, Krzysztof
On Sat, 19 Jul 2025 14:09:37 +0200, Otto Pflüger wrote: > Add the compatible strings for the display controller found in the > UMS9230 SoC and bindings for a gate clock. Add IOMMU-related bindings > to the display-subsystem node. > > Signed-off-by: Otto Pflüger <otto.pflueger@abscue.de> > --- > .../bindings/display/sprd/sprd,display-subsystem.yaml | 11 +++++++++++ > .../bindings/display/sprd/sprd,sharkl3-dpu.yaml | 18 +++++++++++++----- > .../bindings/display/sprd/sprd,sharkl3-dsi-host.yaml | 11 ++++++++--- > 3 files changed, 32 insertions(+), 8 deletions(-) > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: ./Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml:38:9: [warning] wrong indentation: expected 10 but found 8 (indentation) ./Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml:41:9: [warning] wrong indentation: expected 10 but found 8 (indentation) dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.example.dtb: dpu@63000000 (sprd,sharkl3-dpu): clocks: [[4294967295, 21], [4294967295, 13]] is too long from schema $id: http://devicetree.org/schemas/display/sprd/sprd,sharkl3-dpu.yaml# doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20250719-ums9230-drm-v1-1-e4344a05eb3d@abscue.de The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
© 2016 - 2025 Red Hat, Inc.