Re: [PATCH v3 2/4] dt-bindings: display/msm: hdmi: add qcom,hdmi-tx-8998
On Thu, 06 Jun 2024 18:07:48 +0200, Marc Gonzalez wrote: > HDMI TX block embedded in the APQ8098. > > Signed-off-by: Marc Gonzalez > --- > .../devicetree/bindings/display/msm/hdmi.yaml | 28 > -- > 1 file changed, 26 insertions(+), 2 deletions(-) > Reviewed-by: Rob Herring (Arm)
Re: [PATCH] dt-bindings: display: panel: constrain 'reg' in DSI panels (part two)
On Wed, 05 Jun 2024 12:56:59 +0200, Krzysztof Kozlowski wrote: > DSI-attached devices could respond to more than one virtual channel > number, thus their bindings are supposed to constrain the 'reg' property > to match hardware. Add missing 'reg' constrain for DSI-attached display > panels, based on DTS sources in Linux kernel (assume all devices take > only one channel number). > > Few bindings missed previous fixup: LG SW43408 and Raydium RM69380. > > Signed-off-by: Krzysztof Kozlowski > > --- > > This should apply on any tree. > --- > .../devicetree/bindings/display/panel/lg,sw43408.yaml| 4 +++- > .../devicetree/bindings/display/panel/raydium,rm69380.yaml | 5 +++-- > 2 files changed, 6 insertions(+), 3 deletions(-) > Applied, thanks!
Re: [PATCH 12/14] dt-bindings: display: rockchip,dw-hdmi: Add compatible for RK3588
On Thu, Jun 6, 2024 at 5:51 AM Cristian Ciocaltea
wrote:
>
> On 6/6/24 2:22 AM, Rob Herring wrote:
> > On Sat, Jun 01, 2024 at 04:12:34PM +0300, Cristian Ciocaltea wrote:
> >> Document the Synopsys DesignWare HDMI 2.1 Quad-Pixel (QP) TX controller
> >> found on Rockchip RK3588 SoC family.
> >>
> >> Since RK3588 uses different clocks than previous Rockchip SoCs and also
> >> requires a couple of reset lines and some additional properties, provide
> >> the required changes in the binding to accommodate all variants.
> >>
> >> Signed-off-by: Cristian Ciocaltea
> >> ---
> >> .../display/rockchip/rockchip,dw-hdmi.yaml | 127
> >> +++--
> >> 1 file changed, 90 insertions(+), 37 deletions(-)
> >>
> >> diff --git
> >> a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> >> b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> >> index 2aac62219ff6..60d6b815227f 100644
> >> ---
> >> a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> >> +++
> >> b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> >> @@ -10,12 +10,10 @@ maintainers:
> >>- Mark Yao
> >>
> >> description: |
> >> - The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
> >> - with a companion PHY IP.
> >> -
> >> -allOf:
> >> - - $ref: ../bridge/synopsys,dw-hdmi.yaml#
> >> - - $ref: /schemas/sound/dai-common.yaml#
> >> + For SoCs up to RK3568, the HDMI transmitter is a Synopsys DesignWare
> >> + HDMI 1.4 TX controller IP with a companion PHY IP.
> >> + The RK3588 SoC integrates the Synopsys DesignWare HDMI 2.1 Quad-Pixel
> >> (QP)
> >> + TX controller IP and a HDMI/eDP TX Combo PHY based on a Samsung IP
> >> block.
> >>
> >> properties:
> >>compatible:
> >> @@ -25,6 +23,7 @@ properties:
> >>- rockchip,rk3328-dw-hdmi
> >>- rockchip,rk3399-dw-hdmi
> >>- rockchip,rk3568-dw-hdmi
> >> + - rockchip,rk3588-dw-hdmi
> >>
> >>reg-io-width:
> >> const: 4
> >> @@ -40,36 +39,6 @@ properties:
> >>A 1.8V supply that powers up the SoC internal circuitry. The pin
> >> name on the
> >>SoC usually is HDMI_TX_AVDD_1V8.
> >>
> >> - clocks:
> >> -minItems: 2
> >> -items:
> >> - - {}
> >> - - {}
> >> - # The next three clocks are all optional, but shall be specified in
> >> this
> >> - # order when present.
> >> - - description: The HDMI CEC controller main clock
> >> - - description: Power for GRF IO
> >> - - description: External clock for some HDMI PHY (old clock name,
> >> deprecated)
> >> - - description: External clock for some HDMI PHY (new name)
> >> -
> >> - clock-names:
> >> -minItems: 2
> >> -items:
> >> - - {}
> >> - - {}
> >> - - enum:
> >> - - cec
> >> - - grf
> >> - - vpll
> >> - - ref
> >> - - enum:
> >> - - grf
> >> - - vpll
> >> - - ref
> >> - - enum:
> >> - - vpll
> >> - - ref
> >> -
> >>ddc-i2c-bus:
> >> $ref: /schemas/types.yaml#/definitions/phandle
> >> description:
> >> @@ -131,13 +100,97 @@ properties:
> >> required:
> >>- compatible
> >>- reg
> >> - - reg-io-width
> >>- clocks
> >>- clock-names
> >>- interrupts
> >>- ports
> >>- rockchip,grf
> >>
> >> +allOf:
> >> + - $ref: /schemas/sound/dai-common.yaml#
> >> + - if:
> >> + properties:
> >> +compatible:
> >> + contains:
> >> +enum:
> >> + - rockchip,rk3588-dw-hdmi
> >> +then:
> >> + properties:
> >> +reg:
> >> + maxItems: 1
> >> +
> >> +clocks:
> >> + minItems: 1
> >> + items:
> >> +- description: APB system interface clock
> >> +# The next clocks are optional, but shall be specified in this
> >> +
Re: [PATCH 12/14] dt-bindings: display: rockchip,dw-hdmi: Add compatible for RK3588
On Sat, Jun 01, 2024 at 04:12:34PM +0300, Cristian Ciocaltea wrote:
> Document the Synopsys DesignWare HDMI 2.1 Quad-Pixel (QP) TX controller
> found on Rockchip RK3588 SoC family.
>
> Since RK3588 uses different clocks than previous Rockchip SoCs and also
> requires a couple of reset lines and some additional properties, provide
> the required changes in the binding to accommodate all variants.
>
> Signed-off-by: Cristian Ciocaltea
> ---
> .../display/rockchip/rockchip,dw-hdmi.yaml | 127
> +++--
> 1 file changed, 90 insertions(+), 37 deletions(-)
>
> diff --git
> a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> index 2aac62219ff6..60d6b815227f 100644
> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> @@ -10,12 +10,10 @@ maintainers:
>- Mark Yao
>
> description: |
> - The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
> - with a companion PHY IP.
> -
> -allOf:
> - - $ref: ../bridge/synopsys,dw-hdmi.yaml#
> - - $ref: /schemas/sound/dai-common.yaml#
> + For SoCs up to RK3568, the HDMI transmitter is a Synopsys DesignWare
> + HDMI 1.4 TX controller IP with a companion PHY IP.
> + The RK3588 SoC integrates the Synopsys DesignWare HDMI 2.1 Quad-Pixel (QP)
> + TX controller IP and a HDMI/eDP TX Combo PHY based on a Samsung IP block.
>
> properties:
>compatible:
> @@ -25,6 +23,7 @@ properties:
>- rockchip,rk3328-dw-hdmi
>- rockchip,rk3399-dw-hdmi
>- rockchip,rk3568-dw-hdmi
> + - rockchip,rk3588-dw-hdmi
>
>reg-io-width:
> const: 4
> @@ -40,36 +39,6 @@ properties:
>A 1.8V supply that powers up the SoC internal circuitry. The pin name
> on the
>SoC usually is HDMI_TX_AVDD_1V8.
>
> - clocks:
> -minItems: 2
> -items:
> - - {}
> - - {}
> - # The next three clocks are all optional, but shall be specified in
> this
> - # order when present.
> - - description: The HDMI CEC controller main clock
> - - description: Power for GRF IO
> - - description: External clock for some HDMI PHY (old clock name,
> deprecated)
> - - description: External clock for some HDMI PHY (new name)
> -
> - clock-names:
> -minItems: 2
> -items:
> - - {}
> - - {}
> - - enum:
> - - cec
> - - grf
> - - vpll
> - - ref
> - - enum:
> - - grf
> - - vpll
> - - ref
> - - enum:
> - - vpll
> - - ref
> -
>ddc-i2c-bus:
> $ref: /schemas/types.yaml#/definitions/phandle
> description:
> @@ -131,13 +100,97 @@ properties:
> required:
>- compatible
>- reg
> - - reg-io-width
>- clocks
>- clock-names
>- interrupts
>- ports
>- rockchip,grf
>
> +allOf:
> + - $ref: /schemas/sound/dai-common.yaml#
> + - if:
> + properties:
> +compatible:
> + contains:
> +enum:
> + - rockchip,rk3588-dw-hdmi
> +then:
> + properties:
> +reg:
> + maxItems: 1
> +
> +clocks:
> + minItems: 1
> + items:
> +- description: APB system interface clock
> +# The next clocks are optional, but shall be specified in this
> +# order when present.
> +- description: TMDS/FRL link clock
> +- description: EARC RX biphase clock
> +- description: Reference clock
> +- description: Audio interface clock
> +- description: Video datapath clock
> +
> +clock-names:
> + minItems: 1
> + items:
> +- const: pclk
> +- enum: [hdp, earc, ref, aud, hclk_vo1]
> +- enum: [earc, ref, aud, hclk_vo1]
> +- enum: [ref, aud, hclk_vo1]
> +- enum: [aud, hclk_vo1]
> +- const: hclk_vo1
> +
> +resets:
> + minItems: 2
> + maxItems: 2
> +
> +reset-names:
> + items:
> +- const: ref
> +- const: hdp
> +
> +interrupts:
> + minItems: 1
> + maxItems: 5
> +
> +rockchip,vo1_grf:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description: Some QP related data is accessed through VO1 GRF regs
> +
> + required:
> +- resets
> +- reset-names
> +- rockchip,vo1_grf
> +
> +else:
> + $ref: ../bridge/synopsys,dw-hdmi.yaml#
This is odd... With this plus the amount of conditional schema, I think
this should be a new schema doc. Doesn't have to have a common
schema. You can let the 2nd user of this IP block do that. Though if you
have the Synopsys spec, then it would be good to use it and be sure the
binding corresponds to it.
Rob
Re: [PATCH] dt-bindings: display: bridge: tc358767: Keep enum sorted
On Fri, 31 May 2024 22:30:18 +0200, Marek Vasut wrote: > Keep the list sorted numerically. No functional change. > > Signed-off-by: Marek Vasut > --- > Cc: Andrzej Hajda > Cc: Conor Dooley > Cc: Daniel Vetter > Cc: David Airlie > Cc: Jernej Skrabec > Cc: Jonas Karlman > Cc: Krzysztof Kozlowski > Cc: Laurent Pinchart > Cc: Lucas Stach > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Neil Armstrong > Cc: Rob Herring > Cc: Robert Foss > Cc: Thomas Zimmermann > Cc: devicet...@vger.kernel.org > Cc: dri-devel@lists.freedesktop.org > Cc: ker...@dh-electronics.com > --- > .../devicetree/bindings/display/bridge/toshiba,tc358767.yaml | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Acked-by: Rob Herring (Arm)
Re: [PATCH 1/2] dt-bindings: display: bridge: tc358867: Document default DP preemphasis
On Tue, Jun 04, 2024 at 11:42:31AM +0200, Alexander Stein wrote: > Hi Marek, > > Am Freitag, 31. Mai 2024, 22:42:03 CEST schrieb Marek Vasut: > > Document default DP port preemphasis configurable via new DT property > > "toshiba,pre-emphasis". This is useful in case the DP link properties > > are known and starting link training from preemphasis setting of 0 dB > > is not useful. The preemphasis can be set separately for both DP lanes > > in range 0=0dB, 1=3.5dB, 2=6dB . > > > > Signed-off-by: Marek Vasut > > --- > > Cc: Andrzej Hajda > > Cc: Conor Dooley > > Cc: Daniel Vetter > > Cc: David Airlie > > Cc: Jernej Skrabec > > Cc: Jonas Karlman > > Cc: Krzysztof Kozlowski > > Cc: Laurent Pinchart > > Cc: Lucas Stach > > Cc: Maarten Lankhorst > > Cc: Maxime Ripard > > Cc: Neil Armstrong > > Cc: Rob Herring > > Cc: Robert Foss > > Cc: Thomas Zimmermann > > Cc: devicet...@vger.kernel.org > > Cc: dri-devel@lists.freedesktop.org > > Cc: ker...@dh-electronics.com > > --- > > .../display/bridge/toshiba,tc358767.yaml | 18 ++ > > 1 file changed, 18 insertions(+) > > > > diff --git > > a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml > > b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml > > index 2ad0cd6dd49e0..dcf56e996ee22 100644 > > --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml > > +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml > > @@ -98,6 +98,24 @@ properties: > > reference to a valid eDP panel input endpoint node. This port > > is > > optional, treated as DP panel if not defined > > > > +properties: > > + endpoint: > > +$ref: /schemas/media/video-interfaces.yaml# > > +unevaluatedProperties: false > > + > > +properties: > > + toshiba,pre-emphasis: > > +description: > > + Display port output Pre-Emphasis settings for both ports. > > Is this a property of the port or the endpoint? What's the difference? Either is the same data path. The preference is custom properties in endpoint node, not port nodes. Rob
Re: [PATCH 1/2] dt-bindings: display: bridge: tc358867: Document default DP preemphasis
On Fri, May 31, 2024 at 10:42:03PM +0200, Marek Vasut wrote: > Document default DP port preemphasis configurable via new DT property > "toshiba,pre-emphasis". This is useful in case the DP link properties > are known and starting link training from preemphasis setting of 0 dB > is not useful. The preemphasis can be set separately for both DP lanes > in range 0=0dB, 1=3.5dB, 2=6dB . > > Signed-off-by: Marek Vasut > --- > Cc: Andrzej Hajda > Cc: Conor Dooley > Cc: Daniel Vetter > Cc: David Airlie > Cc: Jernej Skrabec > Cc: Jonas Karlman > Cc: Krzysztof Kozlowski > Cc: Laurent Pinchart > Cc: Lucas Stach > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Neil Armstrong > Cc: Rob Herring > Cc: Robert Foss > Cc: Thomas Zimmermann > Cc: devicet...@vger.kernel.org > Cc: dri-devel@lists.freedesktop.org > Cc: ker...@dh-electronics.com > --- > .../display/bridge/toshiba,tc358767.yaml | 18 ++ > 1 file changed, 18 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml > b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml > index 2ad0cd6dd49e0..dcf56e996ee22 100644 > --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml > +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml > @@ -98,6 +98,24 @@ properties: > reference to a valid eDP panel input endpoint node. This port is > optional, treated as DP panel if not defined > > +properties: > + endpoint: > +$ref: /schemas/media/video-interfaces.yaml# > +unevaluatedProperties: false > + > +properties: > + toshiba,pre-emphasis: You didn't test adding this property. You will find it isn't allowed. That's because 'properties/port' schema above doesn't allow extra properties (on the port and endpoint). > +description: > + Display port output Pre-Emphasis settings for both ports. Both ports? This schema is for just port 2. > +$ref: /schemas/types.yaml#/definitions/uint32-array > +minItems: 2 > +maxItems: 2 > +items: > + enum: > +- 0 # -6dB de-emphasis > +- 1 # -3.5dB de-emphasis > +- 2 # No de-emphasis > + > oneOf: >- required: >- port@0 > -- > 2.43.0 >
Re: [PATCH v2 1/5] dt-bindings: connector: add GE SUNH hotplug addon connector
On Tue, May 14, 2024 at 06:51:25PM +0200, Luca Ceresoli wrote:
> Hello Rob,
>
> +cc Srinivas and Miquèl for the NVMEM cell discussion below
>
> On Fri, 10 May 2024 11:36:25 -0500
> Rob Herring wrote:
>
> > On Fri, May 10, 2024 at 09:10:37AM +0200, Luca Ceresoli wrote:
> > > Add bindings for the GE SUNH add-on connector. This is a physical,
> > > hot-pluggable connector that allows to attach and detach at runtime an
> > > add-on adding peripherals on non-discoverable busses.
> > >
> > > Signed-off-by: Luca Ceresoli
>
> [...]
>
> > > +++
> > > b/Documentation/devicetree/bindings/connector/ge,sunh-addon-connector.yaml
> > > @@ -0,0 +1,197 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id:
> > > http://devicetree.org/schemas/connector/ge,sunh-addon-connector.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: GE SUNH hotplug add-on connector
> > > +
> > > +maintainers:
> > > + - Luca Ceresoli
> > > +
> > > +description:
> > > + Represent the physical connector present on GE SUNH devices that allows
> > > + to attach and detach at runtime an add-on adding peripherals on
> > > + non-discoverable busses.
> > > +
> > > + This connector has status GPIOs to notify the connection status to the
> > > + CPU and a reset GPIO to allow the CPU to reset all the peripherals on
> > > the
> > > + add-on. It also has a 4-lane MIPI DSI bus.
> > > +
> > > + Add-on removal can happen at any moment under user control and without
> > > + prior notice to the CPU, making all of its components not usable
> > > + anymore. Later on, the same or a different add-on model can be
> > > connected.
> >
> > Is there any documentation for this connector?
> >
> > Is the connector supposed to be generic in that any board with any SoC
> > could have it? If so, the connector needs to be able to remap things so
> > overlays aren't tied to the base dts, but only the connector. If not,
> > then doing that isn't required, but still a good idea IMO.
>
> It is not generic. The connector pinout is very specific to this
> product, and there is no public documentation.
>
> > > +examples:
> > > + # Main DTS describing the "main" board up to the connector
> > > + - |
> > > +/ {
> > > +#include
> > > +
> > > +addon_connector: addon-connector {
> >
> > Just 'connector' for the node name.
>
> OK
>
> > > +compatible = "ge,sunh-addon-connector";
> > > +reset-gpios = < 1 GPIO_ACTIVE_LOW>;
> > > +plugged-gpios = < 2 GPIO_ACTIVE_LOW>;
> > > +powergood-gpios = < 3 GPIO_ACTIVE_HIGH>;
> > > +
> > > +ports {
> > > +#address-cells = <1>;
> > > +#size-cells = <0>;
> > > +
> > > +port@0 {
> > > +reg = <0>;
> > > +
> > > +hotplug_conn_dsi_in: endpoint {
> > > +remote-endpoint = <_bridge_out>;
> > > +};
> > > +};
> > > +
> > > +port@1 {
> > > +reg = <1>;
> > > +
> > > +hotplug_conn_dsi_out: endpoint {
> > > +// remote-endpoint to be added by overlay
> > > +};
> > > +};
> > > +};
> > > +};
> > > +};
> > > +
> > > + # "base" overlay describing the common components on every add-on that
> > > + # are required to read the model ID
> >
> > This is located on the add-on board, right?
>
> Exactly. Each add-on has an EEPROM with the add-on model ID stored
> along with other data.
>
> > Is it really any better to have this as a separate overlay rather than
> > just making it an include? Better to have just 1 overlay per board
> > applied atomically than splitting it up.
>
> (see below)
>
> > > + - |
> > > + {
> >
> > Generally, I think everything on an add-on board should be underneath
> > the connector node. For starters, that makes controlling prob
Re: [DO NOT MERGE v8 21/36] dt-bindings: serial: renesas,scif: Add scif-sh7751.
On Wed, 29 May 2024 17:01:07 +0900, Yoshinori Sato wrote: > Add Renesas SH7751 SCIF. > > Signed-off-by: Yoshinori Sato > Reviewed-by: Geert Uytterhoeven > --- > Documentation/devicetree/bindings/serial/renesas,scif.yaml | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring (Arm)
Re: [DO NOT MERGE v8 19/36] dt-bindings: interrupt-controller: renesas,sh7751-irl-ext: Add json-schema
On Wed, May 29, 2024 at 05:01:05PM +0900, Yoshinori Sato wrote:
> Renesas SH7751 external interrupt encoder json-schema.
>
> Signed-off-by: Yoshinori Sato
> ---
> .../renesas,sh7751-irl-ext.yaml | 57 +++
> 1 file changed, 57 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/interrupt-controller/renesas,sh7751-irl-ext.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/interrupt-controller/renesas,sh7751-irl-ext.yaml
>
> b/Documentation/devicetree/bindings/interrupt-controller/renesas,sh7751-irl-ext.yaml
> new file mode 100644
> index ..ff70d57b86cd
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/interrupt-controller/renesas,sh7751-irl-ext.yaml
> @@ -0,0 +1,57 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id:
> http://devicetree.org/schemas/interrupt-controller/renesas,sh7751-irl-ext.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Renesas SH7751 external interrupt encoder with enable regs.
> +
> +maintainers:
> + - Yoshinori Sato
> +
> +description:
> + This is the generally used external interrupt encoder on SH7751 based
> boards.
> +
> +properties:
> + compatible:
> +items:
> + - const: renesas,sh7751-irl-ext
> +
> + reg: true
Needs to define how many and what they are.
> +
> + interrupt-controller: true
> +
> + '#interrupt-cells':
> +const: 2
> +
> + '#address-cells':
> +const: 0
> +
> + renesas,set-to-disable:
> +$ref: /schemas/types.yaml#/definitions/flag
> +description: Invert enable registers. Setting the bit to 0 enables
> interrupts.
> +
> + renesas,enable-reg:
> +$ref: /schemas/types.yaml#/definitions/uint32-array
> +description: |
Don't need '|'.
> + IRQ enable register bit mapping
This needs a better description and constraints? Number of entries in
the array or values of the entries.
> +
> +required:
> + - compatible
> + - reg
> + - interrupt-controller
> + - '#interrupt-cells'
> + - renesas,enable-reg
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +r2dintc: interrupt-controller@a400 {
> +compatible = "renesas,sh7751-irl-ext";
> +reg = <0xa400 0x02>;
> +interrupt-controller;
> +#address-cells = <0>;
> +#interrupt-cells = <2>;
> +renesas,enable-reg = <12 9 10 3 0 4 1 2 8 5 6 7 15 15 15 11>;
> +};
> --
> 2.39.2
>
Re: [DO NOT MERGE v8 22/36] dt-bindings: display: smi,sm501: SMI SM501 binding json-schema
On Wed, 29 May 2024 17:01:08 +0900, Yoshinori Sato wrote: > Signed-off-by: Yoshinori Sato > --- > .../bindings/display/smi,sm501.yaml | 443 ++ > 1 file changed, 443 insertions(+) > create mode 100644 Documentation/devicetree/bindings/display/smi,sm501.yaml > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/smi,sm501.yaml: crt: Missing additionalProperties/unevaluatedProperties constraint /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/smi,sm501.yaml: panel: Missing additionalProperties/unevaluatedProperties constraint doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/2fb214e148e74fb0acc202543dca8dd8a170a6e6.1716965617.git.ys...@users.sourceforge.jp 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.
Re: [DO NOT MERGE v8 24/36] dt-binding: sh: cpus: Add SH CPUs json-schema
On Wed, 29 May 2024 17:01:10 +0900, Yoshinori Sato wrote: > Renesas SH series and compatible ISA CPUs. > > Signed-off-by: Yoshinori Sato > --- > .../devicetree/bindings/sh/cpus.yaml | 63 +++ > 1 file changed, 63 insertions(+) > create mode 100644 Documentation/devicetree/bindings/sh/cpus.yaml > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/sh/cpus.example.dtb: cpu@0: 'clock-names', 'dcache-line-size', 'dcache-size', 'icache-line-size', 'icache-size' do not match any of the regexes: 'pinctrl-[0-9]+' from schema $id: http://devicetree.org/schemas/sh/cpus.yaml# doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/d54cb668f3f19221fdbf34a70a9123fb3a6b4004.1716965617.git.ys...@users.sourceforge.jp 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.
Re: [PATCH RESEND,v6 2/8] dt-bindings: mailbox: Add property for CMDQ secure driver
On Sun, 26 May 2024 22:44:37 +0800, Jason-JH.Lin wrote:
> 1. Add mboxes property to define a GCE loopping thread as a secure IRQ
> handler.
> The CMDQ secure driver requests a mbox channel and sends a looping
> command to the GCE thread. The looping command will wait for a secure
> packet done event signal from secure world and then jump back to the
> first instuction. Each time it waits for an event, it notifies the
> CMDQ driver to perform the same action as the IRQ handler.
>
> 2. Add gce-events property from gce-props.yaml to define a
> secure packet done signal in secure world.
> There are 1024 events IDs for GCE to use to execute instructions in
> the specific event happened. These events could be signaled by HW or SW
> and their value would be different in different SoC because of HW event
> IDs distribution range from 0 to 1023.
> If we set a static event ID: 855 for mt8188, it might be conflict the
> event ID original set in mt8195.
> So we define an event ID that will be set when GCE runs to the end of
> secure cmdq packet in the secure world.
>
> This can reduce the latency of software communication between normal
> world and secure world. In addition, we can also remove the complex
> logic after the secure packet done in the secure world.
>
> Signed-off-by: Jason-JH.Lin
> Signed-off-by: Hsiao Chien Sung
> ---
> .../devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.example.dtb:
mailbox@10212000: False schema does not allow {'compatible':
['mediatek,mt8173-gce'], 'reg': [[0, 270606336, 0, 4096]], 'interrupts': [[0,
135, 8]], '#mbox-cells': [[2]], 'clocks': [[4294967295, 4]], 'clock-names':
['gce'], '$nodename': ['mailbox@10212000']}
from schema $id:
http://devicetree.org/schemas/mailbox/mediatek,gce-mailbox.yaml#
doc reference errors (make refcheckdocs):
See
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/2024052613.14345-3-jason-jh@mediatek.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH v6 2/8] dt-bindings: mailbox: Add property for CMDQ secure driver
On Sun, 26 May 2024 07:08:04 +0800, Jason-JH.Lin wrote:
> 1. Add mboxes property to define a GCE loopping thread as a secure IRQ
> handler.
> The CMDQ secure driver requests a mbox channel and sends a looping
> command to the GCE thread. The looping command will wait for a secure
> packet done event signal from secure world and then jump back to the
> first instuction. Each time it waits for an event, it notifies the
> CMDQ driver to perform the same action as the IRQ handler.
>
> 2. Add gce-events property from gce-props.yaml to define a
> secure packet done signal in secure world.
> There are 1024 events IDs for GCE to use to execute instructions in
> the specific event happened. These events could be signaled by HW or SW
> and their value would be different in different SoC because of HW event
> IDs distribution range from 0 to 1023.
> If we set a static event ID: 855 for mt8188, it might be conflict the
> event ID original set in mt8195.
> So we define an event ID that will be set when GCE runs to the end of
> secure cmdq packet in the secure world.
>
> This can reduce the latency of software communication between normal
> world and secure world. In addition, we can also remove the complex
> logic after the secure packet done in the secure world.
>
> Signed-off-by: Jason-JH.Lin
> Signed-off-by: Hsiao Chien Sung
> ---
> .../devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.example.dtb:
mailbox@10212000: False schema does not allow {'compatible':
['mediatek,mt8173-gce'], 'reg': [[0, 270606336, 0, 4096]], 'interrupts': [[0,
135, 8]], '#mbox-cells': [[2]], 'clocks': [[4294967295, 4]], 'clock-names':
['gce'], '$nodename': ['mailbox@10212000']}
from schema $id:
http://devicetree.org/schemas/mailbox/mediatek,gce-mailbox.yaml#
doc reference errors (make refcheckdocs):
See
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240525230810.24623-3-jason-jh@mediatek.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH 1/2] dt-bindings: display: panel: Add WL-355608-A8 panel
On Fri, 24 May 2024 22:33:13 +1200, Ryan Walklin wrote: > The WL-355608-A8 is a 3.5" 640x480@60Hz RGB LCD display from an unknown > OEM, used in a number of handheld gaming devices made by Anbernic. > > Add a device tree binding for the panel. > > Signed-off-by: Ryan Walklin > --- > .../bindings/display/panel/wl-355608-a8.yaml | 68 +++ > 1 file changed, 68 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/wl-355608-a8.yaml > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: dtschema/dtc warnings/errors: Documentation/devicetree/bindings/display/panel/wl-355608-a8.example.dtb: /example-0/spi/panel@0: failed to match any schema with compatible: ['wl_355608_a8'] doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240524103506.187277-2-r...@testtoast.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH 1/7] dt-bindings: display/msm/dsi: allow specifying TE source
On Mon, May 20, 2024 at 03:12:43PM +0300, Dmitry Baryshkov wrote: > Command mode panels provide TE signal back to the DSI host to signal > that the frame display has completed and update of the image will not > cause tearing. Usually it is connected to the first GPIO with the > mdp_vsync function, which is the default. In such case the property can > be skipped. > > Signed-off-by: Dmitry Baryshkov > --- > .../bindings/display/msm/dsi-controller-main.yaml| 16 > > 1 file changed, 16 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml > b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml > index 1fa28e976559..c1771c69b247 100644 > --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml > +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml > @@ -162,6 +162,21 @@ properties: > items: >enum: [ 0, 1, 2, 3 ] > > + qcom,te-source: > +$ref: /schemas/types.yaml#/definitions/string > +description: > + Specifies the source of vsync signal from the panel used > for > + tearing elimination. The default is mdp_gpio0. default: mdp_gpio0 With that, Reviewed-by: Rob Herring (Arm)
Re: [RFC PATCH 3/8] rust: drm: Add Device and Driver abstractions
On Mon, May 20, 2024 at 07:20:50PM +0200, Danilo Krummrich wrote:
> From: Asahi Lina
>
> Add abstractions for DRM drivers and devices. These go together in one
> commit since both are fairly tightly coupled types.
>
> A few things have been stubbed out, to be implemented as further bits of
> the DRM subsystem are introduced.
>
> Signed-off-by: Asahi Lina
> Co-developed-by: Danilo Krummrich
> Signed-off-by: Danilo Krummrich
> ---
> rust/bindings/bindings_helper.h | 2 +
> rust/kernel/drm/device.rs | 87 +
> rust/kernel/drm/drv.rs | 318
> rust/kernel/drm/mod.rs | 2 +
> 4 files changed, 409 insertions(+)
> create mode 100644 rust/kernel/drm/device.rs
> create mode 100644 rust/kernel/drm/drv.rs
[...]
> diff --git a/rust/kernel/drm/drv.rs b/rust/kernel/drm/drv.rs
> new file mode 100644
> index ..5dd8f3f8df7c
> --- /dev/null
> +++ b/rust/kernel/drm/drv.rs
> @@ -0,0 +1,318 @@
> +// SPDX-License-Identifier: GPL-2.0 OR MIT
> +
> +//! DRM driver core.
> +//!
> +//! C header:
> [`include/linux/drm/drm_drv.h`](../../../../include/linux/drm/drm_drv.h)
> +
> +use crate::{
> +alloc::flags::*,
> +bindings, device, drm,
> +error::code::*,
> +error::{Error, Result},
> +prelude::*,
> +private::Sealed,
> +str::CStr,
> +types::{ARef, ForeignOwnable},
> +ThisModule,
> +};
> +use core::{
> +marker::{PhantomData, PhantomPinned},
> +pin::Pin,
> +};
> +use macros::vtable;
> +
> +/// Driver use the GEM memory manager. This should be set for all modern
> drivers.
> +pub const FEAT_GEM: u32 = bindings::drm_driver_feature_DRIVER_GEM;
> +/// Driver supports mode setting interfaces (KMS).
> +pub const FEAT_MODESET: u32 = bindings::drm_driver_feature_DRIVER_MODESET;
> +/// Driver supports dedicated render nodes.
> +pub const FEAT_RENDER: u32 = bindings::drm_driver_feature_DRIVER_RENDER;
> +/// Driver supports the full atomic modesetting userspace API.
> +///
> +/// Drivers which only use atomic internally, but do not support the full
> userspace API (e.g. not
> +/// all properties converted to atomic, or multi-plane updates are not
> guaranteed to be tear-free)
> +/// should not set this flag.
> +pub const FEAT_ATOMIC: u32 = bindings::drm_driver_feature_DRIVER_ATOMIC;
> +/// Driver supports DRM sync objects for explicit synchronization of command
> submission.
> +pub const FEAT_SYNCOBJ: u32 = bindings::drm_driver_feature_DRIVER_SYNCOBJ;
> +/// Driver supports the timeline flavor of DRM sync objects for explicit
> synchronization of command
> +/// submission.
> +pub const FEAT_SYNCOBJ_TIMELINE: u32 =
> bindings::drm_driver_feature_DRIVER_SYNCOBJ_TIMELINE;
This is missing an entry for DRIVER_GEM_GPUVA. And some others perhaps.
I suppose some are legacy which won't be needed any time soon if ever.
Not sure if you intend for this to be complete, or you are just adding
what you are using? Only FEAT_GEM is used by nova ATM.
Rob
Re: [PATCH] dt-bindings: display: synopsys, dw-hdmi: Mark ddc-i2c-bus as deprecated
On Tue, 21 May 2024 12:40:47 +0200, Marek Vasut wrote: > The ddc-i2c-bus property should be placed in connector node, > mark the HDMI TX side property as deprecated. > > Signed-off-by: Marek Vasut > --- > Cc: Andrzej Hajda > Cc: Conor Dooley > Cc: Daniel Vetter > Cc: David Airlie > Cc: Fabio Estevam > Cc: Jernej Skrabec > Cc: Jonas Karlman > Cc: Krzysztof Kozlowski > Cc: Laurent Pinchart > Cc: Liu Ying > Cc: Maarten Lankhorst > Cc: Mark Yao > Cc: Maxime Ripard > Cc: Neil Armstrong > Cc: Pengutronix Kernel Team > Cc: Philipp Zabel > Cc: Rob Herring > Cc: Robert Foss > Cc: Sascha Hauer > Cc: Shawn Guo > Cc: Thomas Zimmermann > Cc: devicet...@vger.kernel.org > Cc: dri-devel@lists.freedesktop.org > Cc: i...@lists.linux.dev > Cc: ker...@dh-electronics.com > Cc: linux-arm-ker...@lists.infradead.org > --- > .../devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring (Arm)
Re: [PATCH] dt-bindings: display: Reorganize legacy eDP panel bindings
On Mon, 20 May 2024 15:38:17 -0700, Douglas Anderson wrote: > Back in the day, we used to need to list the exact panel in dts for > eDP panels. This led to all sorts of problems including a large number > of cases where people listed a bogus panel in their device tree > because of the needs of second sourcing (and third sourcing, and > fourth sourcing, ...). Back when we needed to add eDP panels to dts > files we used to list them in "panel-simple.yaml". > > These days we have the new way of doing things as documented in > "panel-edp.yaml". We can just list the compatible "edp-panel", add > some timing info to the source code, and we're good to go. There's not > really good reasons not to use this new method. > > To try to make it obvious that we shouldn't add new compatible strings > for eDP panels, let's move them all out of the old "panel-simple.yaml" > file to their own file: "panel-edp-legacy.yaml". This new file will > have a description that makes it obvious that we shouldn't use it for > new panels. > > While we're doing this: > - We can remove eDP-specific properties from panel-simple.yaml since > there are no more panels there. > - We don't need to copy non-eDP properties to the > "panel-edp-legacy.yaml". > - We'll fork off a separate yaml file for "samsung,atna33xc20.yaml". > This is an eDP panel which isn't _quite_ handled by the generic > "edp-panel" compatible since it's not allowed to have an external > backlight (it has one builtin) and it absolutely requires an > "enable" GPIO. > - We'll un-fork the "sharp,ld-d5116z01b.yaml" and put it in > "panel-edp-legacy.yaml" since there doesn't appear to be any reason > for it to be separate. > > Suggested-by: Dmitry Baryshkov > Signed-off-by: Douglas Anderson > --- > > .../display/panel/panel-edp-legacy.yaml | 127 ++ > .../bindings/display/panel/panel-simple.yaml | 58 > .../display/panel/samsung,atna33xc20.yaml | 95 + > .../display/panel/sharp,ld-d5116z01b.yaml | 30 - > 4 files changed, 222 insertions(+), 88 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/display/panel/panel-edp-legacy.yaml > create mode 100644 > Documentation/devicetree/bindings/display/panel/samsung,atna33xc20.yaml > delete mode 100644 > Documentation/devicetree/bindings/display/panel/sharp,ld-d5116z01b.yaml > Reviewed-by: Rob Herring (Arm)
Re: [PATCH v2 1/5] dt-bindings: display: panel: mipi-dbi-spi: Add a pixel format property
On Sun, 12 May 2024 17:25:38 +0200, Noralf Trønnes wrote: > The MIPI DBI 2.0 specification (2005) lists only two pixel formats for > the Type C Interface (SPI) and that is 3-bits/pixel RGB111 with > 2 options for bit layout. > > For Type A and B (parallel) the following formats are listed: RGB332, > RGB444, RGB565, RGB666 and RGB888 (some have 2 options for the bit layout). > > Many MIPI DBI compatible controllers support all interface types on the > same chip and often the manufacturers have chosen to provide support for > the Type A/B interface pixel formats also on the Type C interface. > > Some chips provide many pixel formats with optional bit layouts over SPI, > but the most common by far are RGB565 and RGB666. So even if the > specification doesn't list these formats for the Type C interface, the > industry has chosen to include them. > > The MIPI DCS specification lists the standard commands that can be sent > over the MIPI DBI interface. The set_address_mode (36h) command has one > bit in the parameter that controls RGB/BGR order: > This bit controls the RGB data latching order transferred from the > peripheral’s frame memory to the display device. > This means that each supported RGB format also has a BGR variant. > > Based on this rationale document the following pixel formats describing > the bit layout going over the wire: > - RGB111 (option 1): x2r1g1b1r1g1b1 (2 pixels per byte) > - BGR111 (option 1): x2b1g1r1b1g1r1 (2 pixels per byte) > - RGB111 (option 2): x1r1g1b1x1r1g1b1 (2 pixels per byte) > - BGR111 (option 2): x1b1g1r1x1b1g1r1 (2 pixels per byte) > - RGB565: r5g6b5 (2 bytes) > - BGR565: b5g6r5 (2 bytes) > - RGB666: r6x2g6x2b6x2 (3 bytes) > - BGR666: b6x2g6x2r6x2 (3 bytes) > (x: don't care) > > v2: > - Use 'default: r5g6b5' (Rob) > > Signed-off-by: Noralf Trønnes > --- > .../bindings/display/panel/panel-mipi-dbi-spi.yaml | 30 > ++ > 1 file changed, 30 insertions(+) > Reviewed-by: Rob Herring (Arm)
Re: [PATCH v2] dt-bindings: display: synopsys,dw-hdmi: Document ddc-i2c-bus in core
On Wed, May 15, 2024 at 04:47:05PM +0300, Laurent Pinchart wrote: > Hi Marek, > > Thank you for the patch. > > On Wed, May 15, 2024 at 08:27:44AM +0200, Marek Vasut wrote: > > The DW HDMI driver core is responsible for parsing the 'ddc-i2c-bus' > > property, > > move the property description into the DW HDMI common DT schema too, so this > > property can be used on all devices integrating the DW HDMI core. > > De-duplicating documentation is good :-) Generally, yes. > I see no reason why this property should be disallowed on any of the > platforms that integrate a DW HDMI (unless that platform has no other > I2C controller, but I think we can ignore that in the bindings). The main reason is Because this property should be in a connector node as the I2C bus is connected to the connector not the HDMI block. I would suggest this gets marked 'deprecated'. Can be a separate patch. Rob
Re: [PATCH 3/4] dt-bindings: display: ti,am65x-dss: Add OLDI properties for AM625 DSS
On Sun, May 12, 2024 at 01:00:54AM +0530, Aradhya Bhatia wrote: > The DSS in AM625 SoC has 2 OLDI TXes. Refer the OLDI schema to add the > properties. > > Signed-off-by: Aradhya Bhatia > --- > .../bindings/display/ti/ti,am65x-dss.yaml | 136 +- > 1 file changed, 135 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml > b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml > index 399d68986326..4aa2de59b32b 100644 > --- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml > +++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml > @@ -85,12 +85,30 @@ properties: > > properties: >port@0: > -$ref: /schemas/graph.yaml#/properties/port > +$ref: /schemas/graph.yaml#/$defs/port-base You don't need this change. You aren't adding any extra properties. > description: >For AM65x DSS, the OLDI output port node from video port 1. >For AM625 DSS, the internal DPI output port node from video >port 1. >For AM62A7 DSS, the port is tied off inside the SoC. > +properties: > + endpoint@0: > +$ref: /schemas/graph.yaml#/properties/endpoint > +description: > + For AM625 DSS, VP Connection to OLDI0. > + For AM65X DSS, OLDI output from the SoC. > + > + endpoint@1: > +$ref: /schemas/graph.yaml#/properties/endpoint > +description: > + For AM625 DSS, VP Connection to OLDI1. > + > +anyOf: > + - required: > + - endpoint > + - required: > + - endpoint@0 > + - endpoint@1 > >port@1: > $ref: /schemas/graph.yaml#/properties/port > @@ -112,6 +130,22 @@ properties: >Input memory (from main memory to dispc) bandwidth limit in >bytes per second > > + oldi-txes: > +type: object > +properties: > + "#address-cells": > +const: 1 > + > + "#size-cells": > +const: 0 > + > +patternProperties: > + '^oldi_tx@[0-1]$': > +type: object > +$ref: ti,am625-oldi.yaml# > +unevaluatedProperties: false > +description: OLDI transmitters connected to the DSS VPs Connected to is not part of the DSS. I don't think these nodes belong here as mentioned in the other patch. Rob
Re: [PATCH 2/4] dt-bindings: display: ti: Add schema for AM625 OLDI Transmitter
On Mon, May 13, 2024 at 02:07:44PM +0530, Aradhya Bhatia wrote:
> Hi Laurent,
>
> Thank you for reviewing the patches!
>
> On 13-May-24 01:04, Laurent Pinchart wrote:
> > Hi Aradhya,
> >
> > Thank you for the patch.
> >
> > On Sun, May 12, 2024 at 01:00:53AM +0530, Aradhya Bhatia wrote:
> >> Add devicetree binding schema for AM625 OLDI Transmitters.
> >>
> >> Signed-off-by: Aradhya Bhatia
> >> ---
> >> .../bindings/display/ti/ti,am625-oldi.yaml| 153 ++
> >> MAINTAINERS | 1 +
> >> 2 files changed, 154 insertions(+)
> >> create mode 100644
> >> Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml
> >>
> >> diff --git
> >> a/Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml
> >> b/Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml
> >> new file mode 100644
> >> index ..0a96e600bc0b
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml
> >> @@ -0,0 +1,153 @@
> >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> >> +%YAML 1.2
> >> +---
> >> +$id: http://devicetree.org/schemas/display/ti/ti,am625-oldi.yaml#
> >> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >> +
> >> +title: Texas Instruments AM625 OLDI Transmitter
> >> +
> >> +maintainers:
> >> + - Tomi Valkeinen
> >> + - Aradhya Bhatia
> >> +
> >> +description: |
> >> + The AM625 TI Keystone OpenLDI transmitter (OLDI TX) supports serialized
> >> RGB
> >> + pixel data transmission between host and flat panel display over LVDS
> >> (Low
> >> + Voltage Differential Sampling) interface. The OLDI TX consists of
> >> 7-to-1 data
> >> + serializers, and 4-data and 1-clock LVDS outputs. It supports the LVDS
> >> output
> >> + formats "jeida-18", "jeida-24" and "vesa-18", and can accept 24-bit RGB
> >> or
> >> + padded and un-padded 18-bit RGB bus formats as input.
> >> +
> >> +properties:
> >> + reg:
> >> +maxItems: 1
> >> +
> >> + clocks:
> >> +maxItems: 1
> >> +description: serial clock input for the OLDI transmitters
> >> +
> >> + clock-names:
> >> +const: s_clk
> >> +
> >> + ti,companion-oldi:
> >> +$ref: /schemas/types.yaml#/definitions/phandle
> >> +description:
> >> + phandle to companion OLDI transmitter. This property is mandatory
> >> for the
> >> + primarty OLDI TX if the OLDI TXes are expected to work either in
> >> dual-lvds
> >> + mode or in clone mode. This property should point to the secondary
> >> OLDI
> >> + TX.
> >> +
> >> + ti,secondary-oldi:
> >> +type: boolean
> >> +description: Boolean property to mark an OLDI TX as secondary node.
> >> +
> >> + ti,oldi-io-ctrl:
> >> +$ref: /schemas/types.yaml#/definitions/phandle
> >> +description:
> >> + phandle to syscon device node mapping OLDI IO_CTRL registers found
> >> in the
> >> + control MMR region. This property is needed for OLDI interface to
> >> work.
> >> +
> >> + ports:
> >> +$ref: /schemas/graph.yaml#/properties/ports
> >> +
> >> +properties:
> >> + port@0:
> >> +$ref: /schemas/graph.yaml#/properties/port
> >> +description: Parallel RGB input port
> >> +
> >> + port@1:
> >> +$ref: /schemas/graph.yaml#/properties/port
> >> +description: LVDS output port
> >> +
> >> +required:
> >> + - port@0
> >> + - port@1
> >> +
> >> +allOf:
> >> + - if:
> >> + properties:
> >> +ti,secondary-oldi: true
> >> +then:
> >> + properties:
> >> +ti,companion-oldi: false
> >> +ti,oldi-io-ctrl: false
> >> +clocks: false
> >> +clock-names: false
> >> +
> >> +else:
> >> + required:
> >> +- ti,oldi-io-ctrl
> >> +- clocks
> >> +- clock-names
> >> +
> >> +required:
> >> + - reg
> >> + - ports
> >> +
> >> +additionalProperties: false
> >> +
> >> +examples:
> >> + - |
> >> +#include
> >> +
> >> +oldi_txes {
> >> +#address-cells = <1>;
> >> +#size-cells = <0>;
> >> +oldi: oldi@0 {
> >> +reg = <0>;
> >> +clocks = <_clks 186 0>;
> >> +clock-names = "s_clk";
> >> +ti,oldi-io-ctrl = <_oldi_io_ctrl>;
> >
> > What bus does this device live on ? Couldn't the I/O register space be
> > referenced by the reg property ?.
> >
>
> These registers are a part of the system-controller register space
> (ctrl_mmr0). The whole register set is owned by the main_conf[0]
> devicetree node, with sub-nodes pointing to specific regions. That's why
> I cannot reference these registers directly.
Then what does 'reg' represent? Looks like you just made up an index. If
so, then this should probably be a child of _oldi_io_ctrl instead.
Or it should just be merged into that node.
Rob
Re: [PATCH 1/4] dt-bindings: display: ti,am65x-dss: Minor Cleanup
On Sun, May 12, 2024 at 01:00:52AM +0530, Aradhya Bhatia wrote: > Reduce tab size from 8 spaces to 4 spaces to make the bindings > consistent, and easy to expand. "Re-indent the example" would be more specific than "minor cleanups" in the subject. Otherwise, Acked-by: Rob Herring (Arm) > > Signed-off-by: Aradhya Bhatia > --- > .../bindings/display/ti/ti,am65x-dss.yaml | 54 +-- > 1 file changed, 27 insertions(+), 27 deletions(-)
Re: [PATCH v3 05/10] media: dt-bindings: video-interfaces: Support DisplayPort MST
On Tue, 07 May 2024 15:54:08 +, Paweł Anikiel wrote: > Add a DisplayPort bus type and a multi-stream-support property > indicating whether the interface supports MST. > > Signed-off-by: Paweł Anikiel > --- > .../devicetree/bindings/media/video-interfaces.yaml| 7 +++ > include/dt-bindings/media/video-interfaces.h | 2 ++ > 2 files changed, 9 insertions(+) > Reviewed-by: Rob Herring (Arm)
Re: [PATCH 0/3] dt-bindings: display: panel: constrain 'reg'
On Thu, May 09, 2024 at 11:42:50AM +0200, Krzysztof Kozlowski wrote: > Hi, > > Cleanups for display panel bindings. > > Rob, maybe you could take entire set if it applies? I based it on > linux-next, so letl me know if I need to rebase on your for-next. Applied. These 2 don't exist in my tree: Documentation/devicetree/bindings/display/panel/lg,sw43408.yaml Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml Rob
Re: [PATCH v3 08/10] media: dt-bindings: Add Chameleon v3 video interface
On Tue, 07 May 2024 15:54:11 +, Paweł Anikiel wrote: > Add dt binding for the video interface present on the Google > Chameleon v3. The Chameleon v3 uses the video interface to capture > a single video source from a given HDMI or DP connector and write > the resulting frames to memory. > > Signed-off-by: Paweł Anikiel > --- > .../bindings/media/google,chv3-video.yaml | 64 +++ > 1 file changed, 64 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/media/google,chv3-video.yaml > Reviewed-by: Rob Herring (Arm)
Re: [PATCH v3 09/10] media: dt-bindings: Add Intel Displayport RX IP
On Tue, May 07, 2024 at 03:54:12PM +, Paweł Anikiel wrote:
> Add dt binding for the Intel Displayport receiver FPGA IP.
> It is a part of the DisplayPort Intel FPGA IP Core, and supports
> DisplayPort 1.4, HBR3 video capture and Multi-Stream Transport.
>
> The user guide can be found here:
> https://www.intel.com/programmable/technical-pdfs/683273.pdf
>
> Signed-off-by: Paweł Anikiel
> ---
> .../devicetree/bindings/media/intel,dprx.yaml | 172 ++
> 1 file changed, 172 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/intel,dprx.yaml
>
> diff --git a/Documentation/devicetree/bindings/media/intel,dprx.yaml
> b/Documentation/devicetree/bindings/media/intel,dprx.yaml
> new file mode 100644
> index ..01bed858f746
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/intel,dprx.yaml
> @@ -0,0 +1,172 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/intel,dprx.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Intel DisplayPort RX IP
> +
> +maintainers:
> + - Paweł Anikiel
> +
> +description: |
> + The Intel Displayport RX IP is a part of the DisplayPort Intel FPGA IP
> + Core. It implements a DisplayPort 1.4 receiver capable of HBR3 video
> + capture and Multi-Stream Transport.
> +
> + The IP features a large number of configuration parameters, found at:
> +
> https://www.intel.com/content/www/us/en/docs/programmable/683273/23-3-20-0-1/sink-parameters.html
> +
> + The following parameters have to be enabled:
> +- Support DisplayPort sink
> +- Enable GPU control
> + The following parameters have to be set in the devicetree:
> +- RX maximum link rate (using link-frequencies)
> +- Maximum lane count (using data-lanes)
> +- Support MST (using multi-stream-support)
> +- Max stream count (inferred from the number of ports)
> +
> +properties:
> + compatible:
> +const: intel,dprx-20.0.1
> +
> + reg:
> +maxItems: 1
> +
> + interrupts:
> +maxItems: 1
> +
> + ports:
> +$ref: /schemas/graph.yaml#/properties/ports
> +
> +properties:
> + port@0:
> +$ref: /schemas/graph.yaml#/$defs/port-base
> +description: MST virtual channel 0 or SST main link
> +
> +properties:
> + endpoint:
> +$ref: /schemas/media/video-interfaces.yaml#
> +
> +properties:
> + link-frequencies: true
> +
> + data-lanes:
> +minItems: 1
> +maxItems: 4
> +
> + multi-stream-support: true
> +
> +required:
> + - data-lanes
> + - link-frequencies
> +
> + port@1:
> +$ref: /schemas/graph.yaml#/properties/port
> +description: MST virtual channel 0 or SST main link
How can port@0 also be "MST virtual channel 0 or SST main link"?
> +
> + port@2:
> +$ref: /schemas/graph.yaml#/properties/port
> +description: MST virtual channel 1
> +
> + port@3:
> +$ref: /schemas/graph.yaml#/properties/port
> +description: MST virtual channel 2
> +
> + port@4:
> +$ref: /schemas/graph.yaml#/properties/port
> +description: MST virtual channel 3
> +
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +
> +dp-receiver@c0062000 {
> +compatible = "intel,dprx-20.0.1";
> +reg = <0xc0062000 0x800>;
> +interrupt-parent = <_mst_irq>;
> +interrupts = <0 IRQ_TYPE_EDGE_RISING>;
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +reg = <0>;
> +dprx_mst_in: endpoint {
> +remote-endpoint = <_input_mst_0>;
> +data-lanes = <0 1 2 3>;
> +link-frequencies = /bits/ 64 <162000 27
> + 54 81>;
> +multi-stream-support;
> +};
> +};
> +
> +port@1 {
> +reg = <1>;
> +dprx_mst_0: endpoint {
> +remote-endpoint = <_mst0_0>;
> +};
> +};
> +
> +port@2 {
> +reg = <2>;
> +dprx_mst_1: endpoint {
> +remote-endpoint = <_mst1_0>;
> +};
> +};
> +
> +port@3 {
> +reg = <3>;
> +dprx_mst_2: endpoint {
> +remote-endpoint = <_mst2_0>;
> +};
> +};
> +
> +port@4 {
> +reg = <4>;
> +dprx_mst_3: endpoint {
> +remote-endpoint = <_mst3_0>;
> +};
> +};
> +};
> +};
Re: [PATCH v3 05/10] media: dt-bindings: video-interfaces: Support DisplayPort MST
On Tue, May 07, 2024 at 03:54:08PM +, Paweł Anikiel wrote: > Add a DisplayPort bus type and a multi-stream-support property > indicating whether the interface supports MST. > > Signed-off-by: Paweł Anikiel > --- > .../devicetree/bindings/media/video-interfaces.yaml| 7 +++ > include/dt-bindings/media/video-interfaces.h | 2 ++ > 2 files changed, 9 insertions(+) > > diff --git a/Documentation/devicetree/bindings/media/video-interfaces.yaml > b/Documentation/devicetree/bindings/media/video-interfaces.yaml > index 26e3e7d7c67b..7bf3a2c09a5b 100644 > --- a/Documentation/devicetree/bindings/media/video-interfaces.yaml > +++ b/Documentation/devicetree/bindings/media/video-interfaces.yaml > @@ -94,6 +94,7 @@ properties: >- 5 # Parallel >- 6 # BT.656 >- 7 # DPI > + - 8 # DisplayPort > description: >Data bus type. > > @@ -217,4 +218,10 @@ properties: >Whether the clock signal is used as clock (0) or strobe (1). Used with >CCP2, for instance. > > + multi-stream-support: If MST is a known term for DP, then perhaps "dp-mst-support" for the name. In any case, 'dp' should be in there somewhere. > +type: boolean > +description: > + Support transport of multiple independent streams. Used for > + DisplayPort MST-capable interfaces. Wouldn't this be implied by the devices at each end of the link? The drivers for each device should really list out features supported for the link. The mode used is then the union of those 2 lists with DT properties only used when the union is not definitive. > + > additionalProperties: true > diff --git a/include/dt-bindings/media/video-interfaces.h > b/include/dt-bindings/media/video-interfaces.h > index 68ac4e05e37f..b236806f4482 100644 > --- a/include/dt-bindings/media/video-interfaces.h > +++ b/include/dt-bindings/media/video-interfaces.h > @@ -12,5 +12,7 @@ > #define MEDIA_BUS_TYPE_CSI2_DPHY 4 > #define MEDIA_BUS_TYPE_PARALLEL 5 > #define MEDIA_BUS_TYPE_BT656 6 > +#define MEDIA_BUS_TYPE_DPI 7 > +#define MEDIA_BUS_TYPE_DISPLAYPORT 8 > > #endif /* __DT_BINDINGS_MEDIA_VIDEO_INTERFACES_H__ */ > -- > 2.45.0.rc1.225.g2a3ae87e7f-goog >
Re: [PATCH v2 0/5] Add support for GE SUNH hot-pluggable connector (was: "drm: add support for hot-pluggable bridges")
On Fri, May 10, 2024 at 09:10:36AM +0200, Luca Ceresoli wrote: > Hello, > > this series aims at supporting a Linux device with a connector to > physically add and remove an add-on to/from the main device to augment its > features at runtime, using device tree overlays. > > This is the v2 of "drm: add support for hot-pluggable bridges" [0] which > was however more limited in scope, covering only the DRM aspects. This new > series also takes a different approach to the DRM bridge instantiation. > > [0] > https://lore.kernel.org/all/20240326-hotplug-drm-bridge-v1-0-4b51b5eb7...@bootlin.com/ > > Use case > > > This series targets a professional product (GE SUNH) that is composed of a > "main" part running on battery, with the main SoC and able to work > autonomously with limited features, and an optional "add-on" that enables > more features by adding more hardware peripherals, some of which are on > non-discoverable busses such as I2C and MIPI DSI. > > The add-on can be connected and disconnected at runtime at any moment by > the end user, and add-on features need to be enabled and disabled > automatically at runtime. > > The add-on has status pins that are connected to GPIOs on the main board, > allowing the CPU to detect add-on insertion and removal. It also has a > reset GPIO allowign to reset all peripherals on the add-on at once. > > The features provided by the add-on include a display and a battery charger > to recharge the battery of the main part. The display on the add-on has an > LVDS input but the connector between the base and the add-on has a MIPI DSI > bus, so a DSI-to-LVDS bridge is present on the add-on. > > Different add-on models can be connected to the main part, and for this a > model ID is stored in the add-on itself so the software running on the CPU > on the main part knows which non-discoverable hardware to probe. > > Overall approach > > > Device tree overlays appear as the most natural solution to support the > addition and removal of devices from a running system. > > Several features are missing from the mainline Linux kernel in order to > support this use case: > > 1. runtime (un)loading of device tree overlays is not supported Not true. Device specific applying of overlays has been supported since we merged DT overlay support. What's not supported is a general purpose interface to userspace to change any part of the DT at any point in time. > 2. if enabled, overlay (un)loading exposes several bugs Hence why there is no general purpose interface. > 3. the DRM subsystem assumes video bridges are non-removable Rob
Re: [PATCH v2 1/5] dt-bindings: connector: add GE SUNH hotplug addon connector
On Fri, May 10, 2024 at 09:10:37AM +0200, Luca Ceresoli wrote:
> Add bindings for the GE SUNH add-on connector. This is a physical,
> hot-pluggable connector that allows to attach and detach at runtime an
> add-on adding peripherals on non-discoverable busses.
>
> Signed-off-by: Luca Ceresoli
>
> ---
>
> NOTE: the second and third examples fail 'make dt_binding_check' because
> they are example of DT overlay code -- I'm not aware of a way to
> validate overlay examples as of now
>
> This patch is new in v2.
> ---
> .../connector/ge,sunh-addon-connector.yaml | 197
> +
> MAINTAINERS| 5 +
> 2 files changed, 202 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/connector/ge,sunh-addon-connector.yaml
> b/Documentation/devicetree/bindings/connector/ge,sunh-addon-connector.yaml
> new file mode 100644
> index ..c7ac62e5f2c9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/connector/ge,sunh-addon-connector.yaml
> @@ -0,0 +1,197 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/connector/ge,sunh-addon-connector.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: GE SUNH hotplug add-on connector
> +
> +maintainers:
> + - Luca Ceresoli
> +
> +description:
> + Represent the physical connector present on GE SUNH devices that allows
> + to attach and detach at runtime an add-on adding peripherals on
> + non-discoverable busses.
> +
> + This connector has status GPIOs to notify the connection status to the
> + CPU and a reset GPIO to allow the CPU to reset all the peripherals on the
> + add-on. It also has a 4-lane MIPI DSI bus.
> +
> + Add-on removal can happen at any moment under user control and without
> + prior notice to the CPU, making all of its components not usable
> + anymore. Later on, the same or a different add-on model can be connected.
Is there any documentation for this connector?
Is the connector supposed to be generic in that any board with any SoC
could have it? If so, the connector needs to be able to remap things so
overlays aren't tied to the base dts, but only the connector. If not,
then doing that isn't required, but still a good idea IMO.
> +
> +properties:
> + compatible:
> +const: ge,sunh-addon-connector
> +
> + reset-gpios:
> +description: An output GPIO to reset the peripherals on the add-on.
> +maxItems: 1
> +
> + plugged-gpios:
> +description: An input GPIO that is asserted if and only if an add-on is
> + physically connected.
> +maxItems: 1
> +
> + powergood-gpios:
> +description: An input GPIO that is asserted if and only if power rails
> + on the add-on are stable.
> +maxItems: 1
> +
> + ports:
> +$ref: /schemas/graph.yaml#/properties/ports
> +
> +description: OF graph bindings modeling the MIPI DSI bus across the
> + connector. The connector splits the video pipeline in a fixed part
> + and a removable part.
> +
> + The fixed part of the video pipeline includes all components up to
> + the display controller and 0 or more bridges. The removable part
> + includes any bridges and any other components up to the panel.
> +
> +properties:
> + port@0:
> +$ref: /schemas/graph.yaml#/properties/port
> +description: The MIPI DSI bus line from the CPU to the connector.
> + The remote-endpoint sub-node must point to the last non-removable
> + component of the video pipeline.
> +
> + port@1:
> +$ref: /schemas/graph.yaml#/properties/port
> +
> +description: The MIPI DSI bus line from the connector to the
> + add-on. The remote-endpoint sub-node must point to the first
> + add-on component of the video pipeline. As it describes the
> + hot-pluggable hardware, the endpoint node cannot be filled until
> + an add-on is detected, so this needs to be done by a device tree
> + overlay at runtime.
> +
> +required:
> + - port@0
> + - port@1
> +
> +required:
> + - compatible
> +
> +unevaluatedProperties: false
> +
> +examples:
> + # Main DTS describing the "main" board up to the connector
> + - |
> +/ {
> +#include
> +
> +addon_connector: addon-connector {
Just 'connector' for the node name.
> +compatible = "ge,sunh-addon-connector";
> +reset-gpios = < 1 GPIO_ACTIVE_LOW>;
> +plugged-gpios = < 2 GPIO_ACTIVE_LOW>;
> +powergood-gpios = < 3 GPIO_ACTIVE_HIGH>;
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +reg = <0>;
> +
> +hotplug_conn_dsi_in: endpoint {
> +remote-endpoint = <_bridge_out>;
> +};
> +};
> +
> +
Re: [PATCH v2 1/5] dt-bindings: connector: add GE SUNH hotplug addon connector
On Fri, May 10, 2024 at 5:37 AM Luca Ceresoli wrote: > > Hello Rob, > > On Fri, 10 May 2024 03:41:35 -0500 > "Rob Herring (Arm)" wrote: > > > On Fri, 10 May 2024 09:10:37 +0200, Luca Ceresoli wrote: > > > Add bindings for the GE SUNH add-on connector. This is a physical, > > > hot-pluggable connector that allows to attach and detach at runtime an > > > add-on adding peripherals on non-discoverable busses. > > > > > > Signed-off-by: Luca Ceresoli > > > > > > --- > > > > > > NOTE: the second and third examples fail 'make dt_binding_check' because > > > they are example of DT overlay code -- I'm not aware of a way to > > > validate overlay examples as of now > > As mentioned here... > > > > > > > This patch is new in v2. > > > --- > > > .../connector/ge,sunh-addon-connector.yaml | 197 > > > + > > > MAINTAINERS| 5 + > > > 2 files changed, 202 insertions(+) > > > > > > > My bot found errors running 'make dt_binding_check' on your patch: > > > > yamllint warnings/errors: > > > > dtschema/dtc warnings/errors: > > Error: > > Documentation/devicetree/bindings/connector/ge,sunh-addon-connector.example.dts:49.9-14 > > syntax error > > FATAL ERROR: Unable to parse input tree > > ...this is expected. > > Any hints on how this can be managed in bindings examples would be very > useful. Overlays in examples are not supported. Add actual .dtso files if you want examples of overlays (maybe you did, shrug). Overlays are somewhat orthogonal to bindings. Bindings define the ABI. It only makes sense to validate applied overlays. Now maybe overlays contain complete nodes and we could validate those, but that's a problem for actual overlay files and not something we need to complicate examples with. Rob
Re: [PATCH v2 2/2] Add dp PHY dt-bindings
On Fri, May 10, 2024 at 07:04:15PM +0800, Liankun Yang wrote:
> Add dp PHY dt-bindings.
>
> Changeds in v2:
> - Add dp PHY dt-bindings.
> https://patchwork.kernel.org/project/linux-mediatek/patch/
> 20240403040517.3279-1-liankun.y...@mediatek.com/
>
> Signed-off-by: Liankun Yang
> ---
> .../display/mediatek/mediatek.phy-dp.yaml | 45 +++
> 1 file changed, 45 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/mediatek/mediatek.phy-dp.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/mediatek/mediatek.phy-dp.yaml
> b/Documentation/devicetree/bindings/display/mediatek/mediatek.phy-dp.yaml
git refuses to apply your patch because 'new file mode 100644' is
missing. You must have edited the patch or something.
If it did apply, you'd notice it fails testing.
> index ..476bc329363f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek.phy-dp.yaml
> @@ -0,0 +1,45 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/mediatek/mediatek,phy-dp.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek Display Port Controller
> +
> +maintainers:
> + - Mac shen
> + - Liankun yang
> +
> +description: |
> + Special settings need to be configured by MediaTek DP based on the actual
> + hardware situation. For example, when using a certain brand's docking
> + station for display projection, garbage may appear. Adjusting the specific
> + ssc value can resolve this issue.
> +
> +properties:
> + status: disabled
> +description: |
> + Since the DP driver has already registered the DP PHY device
> + through mtk_dp_register_phy(), so the status is disabled.
What!? Please show me any other binding that has 'status' in it. Go read
up on how to write bindings and what goes in them.
> +
> + dp-ssc-setting:
> +- ssc-delta-hbr
> +description: Specific values are set based on the actual HW situation.
> +
> +required:
> + - status
> + - dp-ssc-setting
> +
> +examples:
> + - |
> +soc {
> +#address-cells = <2>;
> +#size-cells = <2>;
> +
> +phy-dp@1c60 {
> + status = "disabled";
> + dp-ssc-setting {
> +ssc-delta-hbr = <0x01fe>;
> + }
> +};
> +};
> --
> 2.18.0
>
Re: [PATCH v2 1/5] dt-bindings: connector: add GE SUNH hotplug addon connector
On Fri, 10 May 2024 09:10:37 +0200, Luca Ceresoli wrote: > Add bindings for the GE SUNH add-on connector. This is a physical, > hot-pluggable connector that allows to attach and detach at runtime an > add-on adding peripherals on non-discoverable busses. > > Signed-off-by: Luca Ceresoli > > --- > > NOTE: the second and third examples fail 'make dt_binding_check' because > they are example of DT overlay code -- I'm not aware of a way to > validate overlay examples as of now > > This patch is new in v2. > --- > .../connector/ge,sunh-addon-connector.yaml | 197 > + > MAINTAINERS| 5 + > 2 files changed, 202 insertions(+) > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: dtschema/dtc warnings/errors: Error: Documentation/devicetree/bindings/connector/ge,sunh-addon-connector.example.dts:49.9-14 syntax error FATAL ERROR: Unable to parse input tree make[2]: *** [scripts/Makefile.lib:427: Documentation/devicetree/bindings/connector/ge,sunh-addon-connector.example.dtb] Error 1 make[2]: *** Waiting for unfinished jobs make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1430: dt_binding_check] Error 2 make: *** [Makefile:240: __sub-make] Error 2 doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240510-hotplug-drm-bridge-v2-1-ec32f2c66...@bootlin.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH v1 1/2] dt-bindings: input: i2c-hid: Introduce Ilitek ili2900
On Thu, 09 May 2024 14:43:35 +0800, Zhaoxiong Lv wrote: > From: lvzhaoxiong > > The ili2900 touch screen chip same as ilitek ili9882t controller > has a reset gpio. > > Signed-off-by: lvzhaoxiong > --- > Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml | 1 + > 1 file changed, 1 insertion(+) > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: ./Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml:22:5: [error] duplication of key "const" in mapping (key-duplicates) dtschema/dtc warnings/errors: make[2]: *** Deleting file 'Documentation/devicetree/bindings/input/ilitek,ili9882t.example.dts' Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml:22:5: found duplicate key "const" with value "ilitek,ili2900" (original value: "ilitek,ili9882t") make[2]: *** [Documentation/devicetree/bindings/Makefile:26: Documentation/devicetree/bindings/input/ilitek,ili9882t.example.dts] Error 1 make[2]: *** Waiting for unfinished jobs ./Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml:22:5: found duplicate key "const" with value "ilitek,ili2900" (original value: "ilitek,ili9882t") /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml: ignoring, error parsing file make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1430: dt_binding_check] Error 2 make: *** [Makefile:240: __sub-make] Error 2 doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240509064336.9803-1-lvzhaoxi...@huaqin.corp-partner.google.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH 1/5] dt-bindings: display: panel: mipi-dbi-spi: Add a pixel format property
On Tue, May 07, 2024 at 11:57:26AM +0200, Noralf Trønnes wrote: > The MIPI DBI 2.0 specification (2005) lists only two pixel formats for > the Type C Interface (SPI) and that is 3-bits/pixel RGB111 with > 2 options for bit layout. > > For Type A and B (parallel) the following formats are listed: RGB332, > RGB444, RGB565, RGB666 and RGB888 (some have 2 options for the bit layout). > > Many MIPI DBI compatible controllers support all interface types on the > same chip and often the manufacturers have chosen to provide support for > the Type A/B interface pixel formats also on the Type C interface. > > Some chips provide many pixel formats with optional bit layouts over SPI, > but the most common by far are RGB565 and RGB666. So even if the > specification doesn't list these formats for the Type C interface, the > industry has chosen to include them. > > The MIPI DCS specification lists the standard commands that can be sent > over the MIPI DBI interface. The set_address_mode (36h) command has one > bit in the parameter that controls RGB/BGR order: > This bit controls the RGB data latching order transferred from the > peripheral’s frame memory to the display device. > This means that each supported RGB format also has a BGR variant. > > Based on this rationale document the following pixel formats describing > the bit layout going over the wire: > - RGB111 (option 1): x2r1g1b1r1g1b1 (2 pixels per byte) > - BGR111 (option 1): x2b1g1r1b1g1r1 (2 pixels per byte) > - RGB111 (option 2): x1r1g1b1x1r1g1b1 (2 pixels per byte) > - BGR111 (option 2): x1b1g1r1x1b1g1r1 (2 pixels per byte) > - RGB565: r5g6b5 (2 bytes) > - BGR565: b5g6r5 (2 bytes) > - RGB666: r6x2g6x2b6x2 (3 bytes) > - BGR666: b6x2g6x2r6x2 (3 bytes) > (x: don't care) > > Signed-off-by: Noralf Trønnes > --- > .../bindings/display/panel/panel-mipi-dbi-spi.yaml | 31 > ++ > 1 file changed, 31 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml > b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml > index e808215cb39e..dac8f9af100e 100644 > --- a/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml > +++ b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml > @@ -50,6 +50,12 @@ description: | >|Command or data | >|| > > + The standard defines one pixel format for type C: RGB111. The industry > + however has decided to provide the type A/B interface pixel formats also on > + the Type C interface and most common among these are RGB565 and RGB666. > + The MIPI DCS command set_address_mode (36h) has one bit that controls > RGB/BGR > + order. This gives each supported RGB format a BGR variant. > + >The panel resolution is specified using the panel-timing node properties >hactive (width) and vactive (height). The other mandatory panel-timing >properties should be set to zero except clock-frequency which can be > @@ -90,6 +96,29 @@ properties: > >spi-3wire: true > > + format: > +description: > > + Pixel format in bit order as going on the wire: > +* `x2r1g1b1r1g1b1` - RGB111, 2 pixels per byte > +* `x2b1g1r1b1g1r1` - BGR111, 2 pixels per byte > +* `x1r1g1b1x1r1g1b1` - RGB111, 2 pixels per byte > +* `x1b1g1r1x1b1g1r1` - BGR111, 2 pixels per byte > +* `r5g6b5` - RGB565, 2 bytes > +* `b5g6r5` - BGR565, 2 bytes > +* `r6x2g6x2b6x2` - RGB666, 3 bytes > +* `b6x2g6x2r6x2` - BGR666, 3 bytes > + This property is optional for backwards compatibility and `r5g6b5` is > + assumed in its absence. Use schemas, not free form text: default: r5g6b5 > +enum: > + - x2r1g1b1r1g1b1 > + - x2b1g1r1b1g1r1 > + - x1r1g1b1x1r1g1b1 > + - x1b1g1r1x1b1g1r1 > + - r5g6b5 > + - b5g6r5 > + - r6x2g6x2b6x2 > + - b6x2g6x2r6x2 > + > required: >- compatible >- reg > @@ -116,6 +145,8 @@ examples: > reset-gpios = < 25 GPIO_ACTIVE_HIGH>; > write-only; > > +format = "r5g6b5"; > + > backlight = <>; > > width-mm = <35>; > > -- > 2.45.0 >
Re: [PATCH v3 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
On Thu, 02 May 2024 13:56:21 +0200, AngeloGioacchino Del Regno wrote: > Document OF graph on MMSYS/VDOSYS: this supports up to three DDP paths > per HW instance (so potentially up to six displays for multi-vdo SoCs). > > The MMSYS or VDOSYS is always the first component in the DDP pipeline, > so it only supports an output port with multiple endpoints - where each > endpoint defines the starting point for one of the (currently three) > possible hardware paths. > > Signed-off-by: AngeloGioacchino Del Regno > > --- > .../bindings/arm/mediatek/mediatek,mmsys.yaml | 23 +++ > 1 file changed, 23 insertions(+) > Reviewed-by: Rob Herring (Arm)
Re: [PATCH v3 1/3] dt-bindings: display: mediatek: Add OF graph support for board path
On Thu, 02 May 2024 13:56:20 +0200, AngeloGioacchino Del Regno wrote: > The display IPs in MediaTek SoCs support being interconnected with > different instances of DDP IPs (for example, merge0 or merge1) and/or > with different DDP IPs (for example, rdma can be connected with either > color, dpi, dsi, merge, etc), forming a full Display Data Path that > ends with an actual display. > > The final display pipeline is effectively board specific, as it does > depend on the display that is attached to it, and eventually on the > sensors supported by the board (for example, Adaptive Ambient Light > would need an Ambient Light Sensor, otherwise it's pointless!), other > than the output type. > > Add support for OF graphs to most of the MediaTek DDP (display) bindings > to add flexibility to build custom hardware paths, hence enabling board > specific configuration of the display pipeline and allowing to finally > migrate away from using hardcoded paths. > > Signed-off-by: AngeloGioacchino Del Regno > > --- > .../display/mediatek/mediatek,aal.yaml| 40 +++ > .../display/mediatek/mediatek,ccorr.yaml | 21 ++ > .../display/mediatek/mediatek,color.yaml | 22 ++ > .../display/mediatek/mediatek,dither.yaml | 22 ++ > .../display/mediatek/mediatek,dpi.yaml| 25 +++- > .../display/mediatek/mediatek,dsc.yaml| 24 +++ > .../display/mediatek/mediatek,dsi.yaml| 27 - > .../display/mediatek/mediatek,ethdr.yaml | 22 ++ > .../display/mediatek/mediatek,gamma.yaml | 19 + > .../display/mediatek/mediatek,merge.yaml | 23 +++ > .../display/mediatek/mediatek,od.yaml | 22 ++ > .../display/mediatek/mediatek,ovl-2l.yaml | 22 ++ > .../display/mediatek/mediatek,ovl.yaml| 22 ++ > .../display/mediatek/mediatek,postmask.yaml | 21 ++ > .../display/mediatek/mediatek,rdma.yaml | 22 ++ > .../display/mediatek/mediatek,ufoe.yaml | 21 ++ > 16 files changed, 372 insertions(+), 3 deletions(-) > Reviewed-by: Rob Herring (Arm)
Re: [PATCH v4 1/7] dt-bindings: display: panel: Add himax hx83102 panel bindings
On Tue, 07 May 2024 21:52:28 +0800, Cong Yang wrote: > In V1, discussed with Doug and Linus [1], we need break out as separate > driver for the himax83102-j02 controller. Beacuse "starry,himax83102-j02" > and in this series "BOE nv110wum-l60" "IVO t109nw41" panels use same > controller, they have some common CMDS. So add new documentation for > this panels. > > For himax83102-j02 controller, no need 3v3 supply, so remove it. > > [1]: > https://lore.kernel.org/all/CACRpkdbzYZAS0=zbqjuc4cb2wj4s1h6n6asazqvdmv95r3z...@mail.gmail.com > > Signed-off-by: Cong Yang > --- > Chage since V4: > > - Update commit message and add fallback compatible. > > V3: > https://lore.kernel.org/all/20240424023010.2099949-2-yangco...@huaqin.corp-partner.google.com > > Chage since V3: > > - Update commit message. > > V2: > https://lore.kernel.org/all/20240422090310.3311429-2-yangco...@huaqin.corp-partner.google.com > > --- > .../display/panel/boe,tv101wum-nl6.yaml | 2 - > .../bindings/display/panel/himax,hx83102.yaml | 73 +++ > 2 files changed, 73 insertions(+), 2 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/himax,hx83102.example.dtb: panel@0: compatible:0: 'starry,himax83102-j02, himax,hx83102' does not match '^[a-zA-Z0-9][a-zA-Z0-9,+\\-._/]+$' from schema $id: http://devicetree.org/schemas/dt-core.yaml# Documentation/devicetree/bindings/display/panel/himax,hx83102.example.dtb: /example-0/dsi/panel@0: failed to match any schema with compatible: ['starry,himax83102-j02, himax,hx83102'] doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240507135234.1356855-2-yangco...@huaqin.corp-partner.google.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH 08/10] dt-bindings: vendor-prefixes: Add AYN Technologies
On Wed, Apr 24, 2024 at 11:29:13PM +0800, Xilin Wu wrote: > Add an entry for AYN Technologies (https://www.ayntec.com/) > > Signed-off-by: Xilin Wu > --- > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml > b/Documentation/devicetree/bindings/vendor-prefixes.yaml > index e4aeeb5fe4d1..c2365b0f4184 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml > +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml > @@ -194,6 +194,8 @@ patternProperties: > description: Axentia Technologies AB >"^axis,.*": > description: Axis Communications AB > + "^ayn,.*": It is somewhat preferred to use the domain name (ayntec). > +description: AYN Technologies Co., Ltd. >"^azoteq,.*": > description: Azoteq (Pty) Ltd >"^azw,.*": > > -- > 2.44.0 >
Re: [PATCH 03/10] dt-bindings: display: panel: Add Synaptics TD4328
On Wed, Apr 24, 2024 at 11:29:08PM +0800, Xilin Wu wrote:
> Synaptics TD4328 is a display driver IC used to drive LCD DSI panels.
>
> Signed-off-by: Xilin Wu
> ---
> .../bindings/display/panel/synaptics,td4328.yaml | 69
> ++
> 1 file changed, 69 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/synaptics,td4328.yaml
> b/Documentation/devicetree/bindings/display/panel/synaptics,td4328.yaml
> new file mode 100644
> index ..216f2fb22b88
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/synaptics,td4328.yaml
> @@ -0,0 +1,69 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/synaptics,td4328.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Synaptics TD4328-based DSI display panels
> +
> +maintainers:
> + - Xilin Wu
> +
> +description:
> + The Synaptics TD4328 is a generic DSI Panel IC used to control
> + LCD panels.
> +
> +allOf:
> + - $ref: panel-common.yaml#
> +
> +properties:
> + compatible:
> +contains:
> + const: syna,td4328
You need a compatible specific to a panel. This can be a fallback
though.
> +
> + vdd-supply:
> +description: Digital voltage rail
> +
> + vddio-supply:
> +description: Digital I/O voltage rail
> +
> + reg: true
> + port: true
> +
> +required:
> + - compatible
> + - reg
> + - reset-gpios
> + - vdd-supply
> + - vddio-supply
> + - port
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> +#include
> +
> +dsi {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +panel@0 {
> +compatible = "syna,td4328";
> +reg = <0>;
> +
> +backlight = <>;
> +reset-gpios = < 133 GPIO_ACTIVE_LOW>;
> +
> +vdd-supply = <_lcm_2p8>;
> +vddio-supply = <_l12b_1p8>;
> +
> +port {
> +panel_in_0: endpoint {
> +remote-endpoint = <_out>;
> +};
> +};
> +};
> +};
> +
> +...
>
> --
> 2.44.0
>
Re: [PATCH v2 4/7] dt-bindings: display: panel: Add compatible for BOE nv110wum-l60
On Mon, Apr 22, 2024 at 05:03:07PM +0800, Cong Yang wrote: > The BOE nv110wum-l60 is a 11.0" WUXGA TFT LCD panel, which fits in nicely > with the existing himax-hx83102 driver. >From a h/w perspective, the reason to share the binding is the same underlying controller, himax hx83102, is used, not that it is the same driver. Rob
Re: [PATCH v2 1/7] dt-bindings: display: panel: Add himax hx83102 panel bindings
On Mon, Apr 22, 2024 at 05:03:04PM +0800, Cong Yang wrote:
> In V1, discussed with Doug and Linus [1], we need break out as separate
> driver for the himax83102-j02 controller. So add new documentation for
> "starry,himax83102-j02" panel.
>
> [1]:
> https://lore.kernel.org/all/CACRpkdbzYZAS0=zbqjuc4cb2wj4s1h6n6asazqvdmv95r3z...@mail.gmail.com
Please summarize this in the commit message rather than referring to a
link to understand "why" you doing this.
>
> Signed-off-by: Cong Yang
> ---
> .../display/panel/boe,tv101wum-nl6.yaml | 2 -
> .../bindings/display/panel/himax,hx83102.yaml | 73 +++
> 2 files changed, 73 insertions(+), 2 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
> b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
> index 906ef62709b8..53fb35f5c9de 100644
> --- a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
> @@ -32,8 +32,6 @@ properties:
>- innolux,hj110iz-01a
> # STARRY 2081101QFH032011-53G 10.1" WUXGA TFT LCD panel
>- starry,2081101qfh032011-53g
> -# STARRY himax83102-j02 10.51" WUXGA TFT LCD panel
> - - starry,himax83102-j02
> # STARRY ili9882t 10.51" WUXGA TFT LCD panel
>- starry,ili9882t
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml
> b/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml
> new file mode 100644
> index ..2e0cd6998ba8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml
> @@ -0,0 +1,73 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/himax,hx83102.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Himax HX83102 MIPI-DSI LCD panel controller
> +
> +maintainers:
> + - Cong Yang
> +
> +allOf:
> + - $ref: panel-common.yaml#
> +
> +properties:
> + compatible:
> +enum:
> +# STARRY himax83102-j02 10.51" WUXGA TFT LCD panel
> + - starry,himax83102-j02
> +
> + reg:
> +description: the virtual channel number of a DSI peripheral
> +
> + enable-gpios:
> +description: a GPIO spec for the enable pin
> +
> + pp1800-supply:
> +description: core voltage supply
> +
> + avdd-supply:
> +description: phandle of the regulator that provides positive voltage
> +
> + avee-supply:
> +description: phandle of the regulator that provides negative voltage
> +
> + backlight:
> +description: phandle of the backlight device attached to the panel
> +
> + port: true
> + rotation: true
> +
> +required:
> + - compatible
> + - reg
> + - enable-gpios
> + - pp1800-supply
> + - avdd-supply
> + - avee-supply
> +
> +additionalProperties: false
Perhaps 'unevaluatedProperties' instead. Don't you want to support
standard properties such as width-mm/height-mm?
> +
> +examples:
> + - |
> +dsi {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +panel@0 {
> +compatible = "starry,himax83102-j02";
> +reg = <0>;
> +enable-gpios = < 45 0>;
> +avdd-supply = <_lcd>;
> +avee-supply = <_lcd>;
> +pp1800-supply = <_lcd>;
> +backlight = <_lcd0>;
> +port {
> +panel_in: endpoint {
> +remote-endpoint = <_out>;
> +};
> +};
> +};
> +};
> +
> +...
> --
> 2.25.1
>
Re: [PATCH v3 07/17] dt-bindings: display: mediatek: dpi: add compatible for MT8365
On Thu, 18 Apr 2024 16:16:55 +0200, Alexandre Mergnat wrote: > Add dt-binding documentation of dpi for MediaTek MT8365 SoC. > > Signed-off-by: Alexandre Mergnat > --- > Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml | 4 > 1 file changed, 4 insertions(+) > Acked-by: Rob Herring (Arm)
Re: [PATCH] i2c: mux: Remove class argument from i2c_mux_add_adapter()
On Thu, Apr 18, 2024 at 10:55:39PM +0200, Heiner Kallweit wrote:
> 99a741aa7a2d ("i2c: mux: gpio: remove support for class-based device
> instantiation") removed the last call to i2c_mux_add_adapter() with a
> non-null class argument. Therefore the class argument can be removed.
>
> Note: Class-based device instantiation is a legacy mechanism which
> shouldn't be used in new code, so we can rule out that this argument
> may be needed again in the future.
>
> Signed-off-by: Heiner Kallweit
> ---
> drivers/gpu/drm/bridge/sii902x.c | 2 +-
> drivers/i2c/i2c-mux.c | 24 +-
> drivers/i2c/muxes/i2c-arb-gpio-challenge.c | 2 +-
> drivers/i2c/muxes/i2c-mux-gpio.c | 2 +-
> drivers/i2c/muxes/i2c-mux-gpmux.c | 2 +-
> drivers/i2c/muxes/i2c-mux-ltc4306.c| 2 +-
> drivers/i2c/muxes/i2c-mux-mlxcpld.c| 2 +-
> drivers/i2c/muxes/i2c-mux-pca9541.c| 2 +-
> drivers/i2c/muxes/i2c-mux-pca954x.c| 2 +-
> drivers/i2c/muxes/i2c-mux-pinctrl.c| 2 +-
> drivers/i2c/muxes/i2c-mux-reg.c| 2 +-
> drivers/iio/gyro/mpu3050-i2c.c | 2 +-
> drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c | 2 +-
> drivers/media/dvb-frontends/af9013.c | 2 +-
> drivers/media/dvb-frontends/lgdt3306a.c| 2 +-
> drivers/media/dvb-frontends/m88ds3103.c| 2 +-
> drivers/media/dvb-frontends/rtl2830.c | 2 +-
> drivers/media/dvb-frontends/rtl2832.c | 2 +-
> drivers/media/dvb-frontends/si2168.c | 2 +-
> drivers/media/i2c/max9286.c| 2 +-
> drivers/media/usb/cx231xx/cx231xx-i2c.c| 5 +
> drivers/of/unittest.c | 2 +-
Acked-by: Rob Herring (Arm)
> include/linux/i2c-mux.h| 3 +--
> 23 files changed, 23 insertions(+), 49 deletions(-)
Re: [PATCH v1 1/2] dt-bindings: input: i2c-hid: Introduce Ilitek ili2900
On Thu, 18 Apr 2024 20:48:14 +0800, lvzhaoxiong wrote: > The ili2900 touch screen chip same as ilitek ili9882t controller > has a reset gpio. > > Signed-off-by: lvzhaoxiong > --- > Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml | 1 + > 1 file changed, 1 insertion(+) > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: ./Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml:22:5: [error] duplication of key "const" in mapping (key-duplicates) dtschema/dtc warnings/errors: make[2]: *** Deleting file 'Documentation/devicetree/bindings/input/ilitek,ili9882t.example.dts' Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml:22:5: found duplicate key "const" with value "ilitek,ili2900" (original value: "ilitek,ili9882t") make[2]: *** [Documentation/devicetree/bindings/Makefile:26: Documentation/devicetree/bindings/input/ilitek,ili9882t.example.dts] Error 1 make[2]: *** Waiting for unfinished jobs ./Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml:22:5: found duplicate key "const" with value "ilitek,ili2900" (original value: "ilitek,ili9882t") /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml: ignoring, error parsing file make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1430: dt_binding_check] Error 2 make: *** [Makefile:240: __sub-make] Error 2 doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240418124815.31897-2-lvzhaoxi...@huaqin.corp-partner.google.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH v4 1/2] dt-bindings: display: panel: Add Raydium RM69380
On Wed, 17 Apr 2024 18:29:33 +0200, David Wronek wrote:
> Raydium RM69380 is a display driver IC used to drive OLED DSI panels.
> Add a dt-binding for it.
>
> Signed-off-by: David Wronek
> ---
> Note:
> Depends on commit 48a516363e29 ("dt-bindings: display: panel: add common
> dual-link schema")
> ---
> .../bindings/display/panel/raydium,rm69380.yaml| 89
> ++
> 1 file changed, 89 insertions(+)
>
Reviewed-by: Rob Herring (Arm)
Re: [PATCH v2 12/18] dt-bindings: pwm: mediatek,pwm-disp: add compatible for mt8365 SoC
On Tue, 16 Apr 2024 17:53:13 +0200, Alexandre Mergnat wrote: > Add a compatible string for MediaTek Genio 350 MT8365's display PWM > block: this is the same as MT8183. > > Reviewed-by: AngeloGioacchino Del Regno > > Acked-by: Uwe Kleine-König > Signed-off-by: Alexandre Mergnat > --- > Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring (Arm)
Re: [PATCH v2 10/18] dt-bindings: display: mediatek: rdma: add compatible for MT8365 SoC
On Tue, 16 Apr 2024 17:53:11 +0200, Alexandre Mergnat wrote: > Document the display Data Path Read DMA on MT8365, which is compatible > with that of the MT8183. > > Signed-off-by: Alexandre Mergnat > --- > Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring (Arm)
Re: [PATCH v2 09/18] dt-bindings: display: mediatek: ovl: add compatible for MT8365 SoC
On Tue, 16 Apr 2024 17:53:10 +0200, Alexandre Mergnat wrote: > Document the display Overlay on MT8365, which is compatible > with that of the MT8192. > > Signed-off-by: Alexandre Mergnat > --- > Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring (Arm)
Re: [PATCH v2 08/18] dt-bindings: display: mediatek: gamma: add compatible for MT8365 SoC
On Tue, 16 Apr 2024 17:53:09 +0200, Alexandre Mergnat wrote: > Document the display Gamma on MT8365, which is compatible > with that of the MT8183. > > Signed-off-by: Alexandre Mergnat > --- > Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring (Arm)
Re: [PATCH v2 06/18] dt-bindings: display: mediatek: dpi: add power-domains property
On Tue, 16 Apr 2024 17:53:07 +0200, amerg...@baylibre.com wrote: > From: Fabien Parent > > DPI is part of the display / multimedia block in MediaTek SoCs, and > always have a power-domain (at least in the upstream device-trees). > Add the power-domains property to the binding documentation. > > Signed-off-by: Fabien Parent > Signed-off-by: Alexandre Mergnat > --- > Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml | 5 > + > 1 file changed, 5 insertions(+) > Acked-by: Rob Herring (Arm)
Re: [PATCH v2 05/18] dt-bindings: display: mediatek: dsi: add compatible for MT8365 SoC
On Tue, 16 Apr 2024 17:53:06 +0200, Alexandre Mergnat wrote: > Document the Display Serial Interface on MT8365, which is compatible > with that of the MT8183. > > Signed-off-by: Alexandre Mergnat > --- > Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring (Arm)
Re: [PATCH v2 04/18] dt-bindings: display: mediatek: dither: add compatible for MT8365 SoC
On Tue, 16 Apr 2024 17:53:05 +0200, Alexandre Mergnat wrote: > Document the display Dither on MT8365, which is compatible > with that of the MT8183. > > Signed-off-by: Alexandre Mergnat > --- > Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring (Arm)
Re: [PATCH v2 03/18] dt-bindings: display: mediatek: color: add compatible for MT8365 SoC
On Tue, 16 Apr 2024 17:53:04 +0200, Alexandre Mergnat wrote: > Document the display Color on MT8365, which is compatible > with that of the MT8173. > > Signed-off-by: Alexandre Mergnat > --- > Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring (Arm)
Re: [PATCH v2 01/18] dt-bindings: display: mediatek: aal: add compatible for MT8365 SoC
On Tue, 16 Apr 2024 17:53:02 +0200, Alexandre Mergnat wrote: > Document the display Adaptive Ambient Light on MT8365, which is compatible > with that of the MT8183. > > Signed-off-by: Alexandre Mergnat > --- > Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring (Arm)
Re: [PATCH v2 02/18] dt-bindings: display: mediatek: ccorr: add compatible for MT8365 SoC
On Tue, 16 Apr 2024 17:53:03 +0200, Alexandre Mergnat wrote: > Document the display Color Correction on MT8365, which is compatible > with that of the MT8183. > > Signed-off-by: Alexandre Mergnat > --- > Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml | 3 > +++ > 1 file changed, 3 insertions(+) > Acked-by: Rob Herring (Arm)
Re: [PATCH v4 1/2] dt-bindings: display: panel: Add Raydium RM69380
On Wed, 17 Apr 2024 18:29:33 +0200, David Wronek wrote:
> Raydium RM69380 is a display driver IC used to drive OLED DSI panels.
> Add a dt-binding for it.
>
> Signed-off-by: David Wronek
> ---
> Note:
> Depends on commit 48a516363e29 ("dt-bindings: display: panel: add common
> dual-link schema")
> ---
> .../bindings/display/panel/raydium,rm69380.yaml| 89
> ++
> 1 file changed, 89 insertions(+)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml:
Error in referenced schema matching $id:
http://devicetree.org/schemas/display/panel/panel-common-dual.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/raydium,rm69380.example.dtb:
panel@0: False schema does not allow {'compatible':
['lenovo,j716f-edo-rm69380', 'raydium,rm69380'], 'reg': [[0]], 'avdd-supply':
[[4294967295]], 'vddio-supply': [[4294967295]], 'reset-gpios': [[4294967295,
75, 1]], 'ports': {'#address-cells': [[1]], '#size-cells': [[0]], 'port@0':
{'reg': [[0]], 'endpoint': {'remote-endpoint': [[4294967295]]}}, 'port@1':
{'reg': [[1]], 'endpoint': {'remote-endpoint': [[4294967295]]}}}, '$nodename':
['panel@0']}
from schema $id:
http://devicetree.org/schemas/display/panel/raydium,rm69380.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/raydium,rm69380.example.dtb:
panel@0: Unevaluated properties are not allowed ('ports' was unexpected)
from schema $id:
http://devicetree.org/schemas/display/panel/raydium,rm69380.yaml#
doc reference errors (make refcheckdocs):
See
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240417-raydium-rm69380-driver-v4-1-e9c2337d0...@mainlining.org
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.
Re: [PATCH v3 1/2] dt-bindings: display: panel: Add Raydium RM69380
On Tue, Apr 16, 2024 at 08:30:48PM +0200, David Wronek wrote:
> Raydium RM69380 is a display driver IC used to drive OLED DSI panels.
> Add a dt-binding for it.
>
> Signed-off-by: David Wronek
> ---
> Note:
> Depends on commit 48a516363e29 ("dt-bindings: display: panel: add common
> dual-link schema")
> ---
> .../bindings/display/panel/raydium,rm69380.yaml| 91
> ++
> 1 file changed, 91 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml
> b/Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml
> new file mode 100644
> index ..0ac7d033cbe0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml
> @@ -0,0 +1,91 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/raydium,rm69380.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Raydium RM6380-based DSI display panels
RM69380-based
> +
> +maintainers:
> + - David Wronek
> +
> +description:
> + The Raydium RM69380 is a generic DSI panel IC used to control
> + OLED panels.
> +
> +allOf:
> + - $ref: panel-common-dual.yaml#
> +
> +properties:
> + compatible:
> +items:
> + - enum:
> + - lenovo,j716f-edo-rm69380
> + - const: raydium,rm69380
> +description: This indicates the panel manufacturer of the panel
> + that is in turn using the RM69380 panel driver. The compatible
> + string determines how the RM69380 panel driver shall be configured
> + to work with the indicated panel. The raydium,rm69380 compatible shall
> + always be provided as a fallback.
> +
> + avdd-supply:
> +description: Analog voltage rail
> +
> + vddio-supply:
> +description: I/O voltage rail
> +
> + reset-gpios:
> +maxItems: 1
> +description: phandle of gpio for reset line - This should be active low
> +
> + ports: true
> + reg: true
Drop these and change 'addtionalProperties' to 'unevaluatedProperties'.
Other properties in panel-common.yaml should be allowed. width-mm and
height-mm for example.
> +
> +required:
> + - compatible
> + - reg
> + - avdd-supply
> + - vddio-supply
> + - reset-gpios
> + - ports
Already required in panel-common-dual.yaml.
Rob
Re: [PATCH v3 1/2] dt-bindings: display: panel: Add Raydium RM69380
On Tue, 16 Apr 2024 20:30:48 +0200, David Wronek wrote:
> Raydium RM69380 is a display driver IC used to drive OLED DSI panels.
> Add a dt-binding for it.
>
> Signed-off-by: David Wronek
> ---
> Note:
> Depends on commit 48a516363e29 ("dt-bindings: display: panel: add common
> dual-link schema")
> ---
> .../bindings/display/panel/raydium,rm69380.yaml| 91
> ++
> 1 file changed, 91 insertions(+)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml:
Error in referenced schema matching $id:
http://devicetree.org/schemas/display/panel/panel-common-dual.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/raydium,rm69380.example.dtb:
panel@0: False schema does not allow {'compatible':
['lenovo,j716f-edo-rm69380', 'raydium,rm69380'], 'reg': [[0]], 'avdd-supply':
[[4294967295]], 'vddio-supply': [[4294967295]], 'reset-gpios': [[4294967295,
75, 1]], 'ports': {'#address-cells': [[1]], '#size-cells': [[0]], 'port@0':
{'reg': [[0]], 'endpoint': {'remote-endpoint': [[4294967295]]}}, 'port@1':
{'reg': [[1]], 'endpoint': {'remote-endpoint': [[4294967295]]}}}, '$nodename':
['panel@0']}
from schema $id:
http://devicetree.org/schemas/display/panel/raydium,rm69380.yaml#
doc reference errors (make refcheckdocs):
See
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240416-raydium-rm69380-driver-v3-1-21600ac4c...@mainlining.org
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.
Re: [PATCH v2 1/2] dt-bindings: display: panel: Add Raydium RM69380
On Mon, 15 Apr 2024 18:10:41 +0200, David Wronek wrote:
> Raydium RM69380 is a display driver IC used to drive OLED DSI panels.
> Add a dt-binding for it.
>
> Signed-off-by: David Wronek
> ---
> .../bindings/display/panel/raydium,rm69380.yaml| 91
> ++
> 1 file changed, 91 insertions(+)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml:
Error in referenced schema matching $id:
http://devicetree.org/schemas/display/panel/panel-common-dual.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/raydium,rm69380.example.dtb:
panel@0: False schema does not allow {'compatible':
['lenovo,j716f-edo-rm69380', 'raydium,rm69380'], 'reg': [[0]], 'avdd-supply':
[[4294967295]], 'vddio-supply': [[4294967295]], 'reset-gpios': [[4294967295,
75, 1]], 'ports': {'#address-cells': [[1]], '#size-cells': [[0]], 'port@0':
{'reg': [[0]], 'endpoint': {'remote-endpoint': [[4294967295]]}}, 'port@1':
{'reg': [[1]], 'endpoint': {'remote-endpoint': [[4294967295]]}}}, '$nodename':
['panel@0']}
from schema $id:
http://devicetree.org/schemas/display/panel/raydium,rm69380.yaml#
doc reference errors (make refcheckdocs):
See
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240415-raydium-rm69380-driver-v2-1-524216461...@mainlining.org
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.
Re: [PATCH 1/2] dt-bindings: display: panel: Add Raydium RM69380
On Sun, 14 Apr 2024 17:22:30 +0200, David Wronek wrote:
> Raydium RM69380 is a display driver IC used to drive OLED DSI panels.
> Add a dt-binding for it.
>
> Signed-off-by: David Wronek
> ---
> .../bindings/display/panel/raydium,rm69380.yaml| 94
> ++
> 1 file changed, 94 insertions(+)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml:
Error in referenced schema matching $id:
http://devicetree.org/schemas/display/panel/panel-common-dual.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/raydium,rm69380.example.dtb:
panel@0: False schema does not allow {'compatible':
['lenovo,j716f-edo-rm69380', 'raydium,rm69380'], 'reg': [[0]], 'avdd-supply':
[[4294967295]], 'vddio-supply': [[4294967295]], 'reset-gpios': [[4294967295,
75, 1]], 'ports': {'#address-cells': [[1]], '#size-cells': [[0]], 'port@0':
{'reg': [[0]], 'endpoint': {'remote-endpoint': [[4294967295]]}}, 'port@1':
{'reg': [[1]], 'endpoint': {'remote-endpoint': [[4294967295]]}}}, '$nodename':
['panel@0']}
from schema $id:
http://devicetree.org/schemas/display/panel/raydium,rm69380.yaml#
doc reference errors (make refcheckdocs):
See
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240414-raydium-rm69380-driver-v1-1-5e86ba249...@mainlining.org
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.
Re: [PATCH v2 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
On Tue, Apr 09, 2024 at 02:02:10PM +0200, AngeloGioacchino Del Regno wrote: > Document OF graph on MMSYS/VDOSYS: this supports up to three DDP paths > per HW instance (so potentially up to six displays for multi-vdo SoCs). > > The MMSYS or VDOSYS is always the first component in the DDP pipeline, > so it only supports an output port with multiple endpoints - where each > endpoint defines the starting point for one of the (currently three) > possible hardware paths. > > Signed-off-by: AngeloGioacchino Del Regno > > --- > .../bindings/arm/mediatek/mediatek,mmsys.yaml | 23 +++ > 1 file changed, 23 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml > b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml > index b3c6888c1457..4e9acd966aa5 100644 > --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml > +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml > @@ -93,6 +93,29 @@ properties: >'#reset-cells': > const: 1 > > + port: > +$ref: /schemas/graph.yaml#/properties/port > +description: > + Output port node. This port connects the MMSYS/VDOSYS output to > + the first component of one display pipeline, for example one of > + the available OVL or RDMA blocks. > + Some MediaTek SoCs support up to three display outputs per MMSYS. I'm have a hard time understanding this, but is it 3 outputs simultaneously or connect mmsys to 1 of 3. Generally it's multiple ports for the former and endpoints for the latter. > +properties: > + endpoint@0: > +$ref: /schemas/graph.yaml#/properties/endpoint > +description: Output to the primary display pipeline > + > + endpoint@1: > +$ref: /schemas/graph.yaml#/properties/endpoint > +description: Output to the secondary display pipeline > + > + endpoint@2: > +$ref: /schemas/graph.yaml#/properties/endpoint > +description: Output to the tertiary display pipeline > + > +required: > + - endpoint@0 > + > required: >- compatible >- reg > -- > 2.44.0 >
Re: [PATCH v2 1/3] dt-bindings: display: mediatek: Add OF graph support for board path
On Tue, Apr 09, 2024 at 02:02:09PM +0200, AngeloGioacchino Del Regno wrote:
> The display IPs in MediaTek SoCs support being interconnected with
> different instances of DDP IPs (for example, merge0 or merge1) and/or
> with different DDP IPs (for example, rdma can be connected with either
> color, dpi, dsi, merge, etc), forming a full Display Data Path that
> ends with an actual display.
>
> The final display pipeline is effectively board specific, as it does
> depend on the display that is attached to it, and eventually on the
> sensors supported by the board (for example, Adaptive Ambient Light
> would need an Ambient Light Sensor, otherwise it's pointless!), other
> than the output type.
>
> Add support for OF graphs to most of the MediaTek DDP (display) bindings
> to add flexibility to build custom hardware paths, hence enabling board
> specific configuration of the display pipeline and allowing to finally
> migrate away from using hardcoded paths.
>
> Signed-off-by: AngeloGioacchino Del Regno
>
> ---
> .../display/mediatek/mediatek,aal.yaml| 40 +++
> .../display/mediatek/mediatek,ccorr.yaml | 21 ++
> .../display/mediatek/mediatek,color.yaml | 22 ++
> .../display/mediatek/mediatek,dither.yaml | 22 ++
> .../display/mediatek/mediatek,dpi.yaml| 25 +++-
> .../display/mediatek/mediatek,dsc.yaml| 24 +++
> .../display/mediatek/mediatek,dsi.yaml| 27 -
> .../display/mediatek/mediatek,ethdr.yaml | 22 ++
> .../display/mediatek/mediatek,gamma.yaml | 19 +
> .../display/mediatek/mediatek,merge.yaml | 23 +++
> .../display/mediatek/mediatek,od.yaml | 22 ++
> .../display/mediatek/mediatek,ovl-2l.yaml | 22 ++
> .../display/mediatek/mediatek,ovl.yaml| 22 ++
> .../display/mediatek/mediatek,postmask.yaml | 21 ++
> .../display/mediatek/mediatek,rdma.yaml | 22 ++
> .../display/mediatek/mediatek,ufoe.yaml | 21 ++
> 16 files changed, 372 insertions(+), 3 deletions(-)
>
> diff --git
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
> index b4c28e96dd55..623cf7e37fe3 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
> @@ -61,6 +61,27 @@ properties:
> $ref: /schemas/types.yaml#/definitions/phandle-array
> maxItems: 1
>
> + ports:
> +$ref: /schemas/graph.yaml#/properties/ports
> +description:
> + Input and output ports can have multiple endpoints, each of those
> + connects to either the primary, secondary, etc, display pipeline.
> +
> +properties:
> + port@0:
> +$ref: /schemas/graph.yaml#/properties/port
> +description: AAL input port
> +
> + port@1:
> +$ref: /schemas/graph.yaml#/properties/port
> +description:
> + AAL output to the next component's input, for example could be one
> + of many gamma, overdrive or other blocks.
> +
> +required:
> + - port@0
> + - port@1
> +
> required:
>- compatible
>- reg
> @@ -88,5 +109,24 @@ examples:
> power-domains = < MT8173_POWER_DOMAIN_MM>;
> clocks = < CLK_MM_DISP_AAL>;
> mediatek,gce-client-reg = < SUBSYS_1401 0x5000 0x1000>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + aal0_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + aal0_out: endpoint {
> + remote-endpoint = <_in>;
> + };
> + };
> + };
> };
> };
> diff --git
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
> index 8c2a737237f2..71ea277a5d8e 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
> @@ -54,6 +54,27 @@ properties:
> $ref: /schemas/types.yaml#/definitions/phandle-array
> maxItems: 1
>
> + ports:
> +$ref: /schemas/graph.yaml#/properties/ports
> +description:
> + Input and output ports can have multiple endpoints, each of those
> + connects to either the primary, secondary, etc, display pipeline.
> +
> +properties:
> + port@0:
> +$ref: /schemas/graph.yaml#/properties/port
> +description: CCORR input port
> +
> + port@1:
> +$ref: /schemas/graph.yaml#/properties/port
>
Re: [PATCH 1/2] dt-bindings: panel-simple-dsi: add New Khadas TS050 panel bindings
On Wed, Apr 10, 2024 at 08:22:25AM +0400, Christian Hewitt wrote: > > On 9 Apr 2024, at 12:26 PM, Jacobe Zang wrote: > > > > This add the bindings for the New Khadas TS050 1080x1920 5" LCD DSI panel > > designed to work with the Khadas VIM3 and VIM3L Single Board Computers. > > > > Signed-off-by: Jacobe Zang > > --- > > .../devicetree/bindings/display/panel/panel-simple-dsi.yaml | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git > > a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml > > b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml > > index f9160d7bac3ca..e194309f31b72 100644 > > --- a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml > > +++ b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml > > @@ -36,6 +36,8 @@ properties: > > - jdi,fhd-r63452 > > # Khadas TS050 5" 1080x1920 LCD panel > > - khadas,ts050 > > +# Khadas NEW TS050 5" 1080x1920 LCD panel > > + - khadas,newts050 > > Products are only new until they are old. At some future point there will > inevitably be a third iteration requiring a ‘new new’ name. IMHO it would > be better to use something like khadas,ts050v2. I only see patch 1, so the threading is messed up... In any case, The commit message should say something about how they are different? Is the new one not compatible with the old? That's what this change tells me. Otherwise, it should have a fallback. Rob
Re: [RESEND v7 28/37] dt-bindings: soc: renesas: sh: Add SH7751 based target
On Thu, 04 Apr 2024 14:14:39 +0900, Yoshinori Sato wrote: > Signed-off-by: Yoshinori Sato > --- > .../devicetree/bindings/soc/renesas/sh.yaml | 27 +++ > 1 file changed, 27 insertions(+) > create mode 100644 Documentation/devicetree/bindings/soc/renesas/sh.yaml > Reviewed-by: Rob Herring
Re: [RESEND v7 25/37] dt-binding: sh: cpus: Add SH CPUs json-schema
On Thu, Apr 04, 2024 at 02:14:36PM +0900, Yoshinori Sato wrote:
> Renesas SH series and compatible ISA CPUs.
>
> Signed-off-by: Yoshinori Sato
> ---
> .../devicetree/bindings/sh/cpus.yaml | 63 +++
> 1 file changed, 63 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sh/cpus.yaml
>
> diff --git a/Documentation/devicetree/bindings/sh/cpus.yaml
> b/Documentation/devicetree/bindings/sh/cpus.yaml
> new file mode 100644
> index ..9e5640793d76
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sh/cpus.yaml
> @@ -0,0 +1,63 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sh/cpus.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Renesas SuperH CPUs
> +
> +maintainers:
> + - Yoshinori Sato
> +
> +description: |+
> + Definition of CPU core with Renesas SuperH and compatible instruction set.
> +
> +properties:
> + compatible:
> +anyOf:
oneOf
> + - items:
> + - enum:
> + - renesas,sh2a
> + - renesas,sh3
> + - renesas,sh4
> + - renesas,sh4a
> + - jcore,j2
> + - const: renesas,sh2
> + - const: renesas,sh2
> +
> + clocks:
> +maxItems: 1
> +
> + reg:
> +maxItems: 1
> +
> + device_type:
> +const: cpu
> +
> +required:
> + - compatible
> + - reg
> + - device_type
> +
> +additionalProperties: true
This is a problem with the other cpu bindings, but should not be copied
here. Add a $ref to schemas/cpu.yaml and make this
'unevaluatedProperties: false'.
> +
> +examples:
> + - |
> +#include
> +cpus {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +cpu: cpu@0 {
> +compatible = "renesas,sh4", "renesas,sh2";
> +device_type = "cpu";
> +reg = <0>;
> +clocks = < SH7750_CPG_ICK>;
> +clock-names = "ick";
> +icache-size = <16384>;
> +icache-line-size = <32>;
> +dcache-size = <32768>;
> +dcache-line-size = <32>;
> +};
> +};
> +...
> --
> 2.39.2
>
Re: [RESEND v7 22/37] dt-bindings: display: smi,sm501: SMI SM501 binding json-schema
On Thu, Apr 04, 2024 at 02:14:33PM +0900, Yoshinori Sato wrote: > Signed-off-by: Yoshinori Sato > --- > .../bindings/display/smi,sm501.yaml | 398 ++ > 1 file changed, 398 insertions(+) > create mode 100644 Documentation/devicetree/bindings/display/smi,sm501.yaml > > diff --git a/Documentation/devicetree/bindings/display/smi,sm501.yaml > b/Documentation/devicetree/bindings/display/smi,sm501.yaml > new file mode 100644 > index ..06c6af4fa4a9 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/smi,sm501.yaml > @@ -0,0 +1,398 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/smi,sm501.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Silicon Motion SM501 Mobile Multimedia Companion Chip > + > +maintainers: > + - Yoshinori Sato > + > +description: | Don't need '|' > + These DT bindings describe the SM501. Drop "These DT bindings describe" and just describe what the h/w is. > + > +properties: > + compatible: > +const: > + smi,sm501 > + > + reg: > +maxItems: 2 > +description: | > + First entry: System Configuration register > + Second entry: IO space (Display Controller register) items: - description: System Configuration register - description: IO space (Display Controller register) Is it just 1 register in each or should be "registers"? > + > + interrupts: > +description: SM501 interrupt to the cpu should be described here. > + > + mode: > +$ref: /schemas/types.yaml#/definitions/string > +description: select a video mode > + > + edid: > +description: | Don't need '|'. > + verbatim EDID data block describing attached display. s/verbatim/Verbatim/ > + Data from the detailed timing descriptor will be used to > + program the display controller. > + > + little-endian: > +$ref: /schemas/types.yaml#/definitions/flag > +description: available on big endian systems, to set different foreign > endian. > + big-endian: > +$ref: /schemas/types.yaml#/definitions/flag > +description: available on little endian systems, to set different > foreign endian. > + > + swap-fb-endian: All these custom properties need vendor prefix. But really, why are so many custom properties needed? Other display controllers don't need so many, why does this one? Do you actually have users of all of them. > +$ref: /schemas/types.yaml#/definitions/flag > +description: swap framebuffer byteorder. > + > + route-crt-panel: > +$ref: /schemas/types.yaml#/definitions/flag > +description: Panel output merge to CRT. > + > + crt: > +type: object > +description: CRT output control > +properties: > + edid: Huh? You already defined edid elsewhere. > +$ref: /schemas/types.yaml#/definitions/uint8-array > +description: | > + verbatim EDID data block describing attached display. > + Data from the detailed timing descriptor will be used to > + program the display controller. > + > + smi,flags: > +$ref: /schemas/types.yaml#/definitions/string-array > +description: Display control flags. > +items: > + anyOf: > +- const: use-init-done > +- const: disable-at-exit > +- const: use-hwcursor > +- const: use-hwaccel > +- const: panel-no-fpen > +- const: panel-no-vbiasen > +- const: panel-inv-fpen > +- const: panel-inv-vbiasen > +maxItems: 8 > + > + bpp: > +$ref: /schemas/types.yaml#/definitions/uint32 > +description: Color depth > + > + panel: Isn't this just the same as 'crt'? > +type: object > +description: Panel output control > +properties: > + edid: > +$ref: /schemas/types.yaml#/definitions/uint8-array > +description: | > + verbatim EDID data block describing attached display. > + Data from the detailed timing descriptor will be used to > + program the display controller. > + > + smi,flags: > +$ref: /schemas/types.yaml#/definitions/string-array > +description: Display control flags. > +items: > + anyOf: > +- const: use-init-done > +- const: disable-at-exit > +- const: use-hwcursor > +- const: use-hwaccel > +- const: panel-no-fpen > +- const: panel-no-vbiasen > +- const: panel-inv-fpen > +- const: panel-inv-vbiasen > +maxItems: 8 > + > + bpp: > +$ref: /schemas/types.yaml#/definitions/uint32 > +description: Color depth > + > + smi,devices: > +$ref: /schemas/types.yaml#/definitions/string-array > +description: Select SM501 device functions. > +items: > + anyOf: > +- const: usb-host > +- const: usb-slave > +
Re: [RESEND v7 17/37] dt-bindings: interrupt-controller: renesas,sh7751-intc: Add json-schema
On Thu, 04 Apr 2024 14:14:28 +0900, Yoshinori Sato wrote: > Renesas SH7751 INTC json-schema. > > Signed-off-by: Yoshinori Sato > --- > .../renesas,sh7751-intc.yaml | 53 +++ > 1 file changed, 53 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/interrupt-controller/renesas,sh7751-intc.yaml > Reviewed-by: Rob Herring
Re: [RESEND v7 13/37] dt-bindings: clock: sh7750-cpg: Add renesas,sh7750-cpg header.
On Thu, Apr 04, 2024 at 02:14:24PM +0900, Yoshinori Sato wrote:
> SH7750 CPG Clock output define.
This and the subject don't match what the patch does.
>
> Signed-off-by: Yoshinori Sato
> ---
> .../bindings/clock/renesas,sh7750-cpg.yaml| 105 ++
> include/dt-bindings/clock/sh7750-cpg.h| 26 +
> 2 files changed, 131 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/clock/renesas,sh7750-cpg.yaml
> create mode 100644 include/dt-bindings/clock/sh7750-cpg.h
>
> diff --git a/Documentation/devicetree/bindings/clock/renesas,sh7750-cpg.yaml
> b/Documentation/devicetree/bindings/clock/renesas,sh7750-cpg.yaml
> new file mode 100644
> index ..04c10b0834ee
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/renesas,sh7750-cpg.yaml
> @@ -0,0 +1,105 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/renesas,sh7750-cpg.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Renesas SH7750/7751 Clock Pulse Generator (CPG)
> +
> +maintainers:
> + - Yoshinori Sato
> +
> +description:
> + The Clock Pulse Generator (CPG) generates core clocks for the SoC. It
> + includes PLLs, and variable ratio dividers.
> +
> + The CPG may also provide a Clock Domain for SoC devices, in combination
> with
> + the CPG Module Stop (MSTP) Clocks.
> +
> +properties:
> + compatible:
> +enum:
> + - renesas,sh7750-cpg # SH7750
> + - renesas,sh7750s-cpg# SH775S
> + - renesas,sh7750r-cpg# SH7750R
> + - renesas,sh7751-cpg # SH7751
> + - renesas,sh7751r-cpg# SH7751R
> +
> + reg: true
> +
> + reg-names: true
> +
> + clocks:
> +maxItems: 1
> +
> + clock-names:
> +const: extal
> +
> + '#clock-cells':
> +const: 1
> +
> + renesas,mode:
> +description: Board-specific settings of the MD[0-2] pins on SoC
> +$ref: /schemas/types.yaml#/definitions/uint32
> +minimum: 0
> +maximum: 6
> +
> + '#power-domain-cells':
> +const: 0
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - clocks
> + - clock-names
> + - '#clock-cells'
> +
> +allOf:
> + - if:
> + properties:
> +compatible:
> + contains:
> +enum:
> + - renesas,sh7750-cpg
> + - renesas,sh7750s-cpg
> +then:
> + properties:
> +reg:
> + maxItems: 1
> +reg-names:
> + items:
> +- const: FRQCR
> +
> + - if:
> + properties:
> +compatible:
> + contains:
> +enum:
> + - renesas,sh7750r-cpg
> + - renesas,sh7751-cpg
> + - renesas,sh7751r-cpg
> +then:
> + properties:
> +reg:
> + maxItems: 2
minItems: 2 (instead)
> +reg-names:
> + items:
> +- const: FRQCR
> +- const: CLKSTP00
Move this to the top-level and add 'minItems: 1'. Then above you just
need 'maxItems: 1' and here 'minItems: 2'.
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +cpg: clock-controller@ffc0 {
> +#clock-cells = <1>;
> +#power-domain-cells = <0>;
> +compatible = "renesas,sh7751r-cpg";
> +clocks = <>;
> +clock-names = "extal";
> +reg = <0xffc0 20>, <0xfe0a 16>;
> +reg-names = "FRQCR", "CLKSTP00";
> +renesas,mode = <0>;
> +};
> diff --git a/include/dt-bindings/clock/sh7750-cpg.h
> b/include/dt-bindings/clock/sh7750-cpg.h
> new file mode 100644
> index ..ec267be91adf
> --- /dev/null
> +++ b/include/dt-bindings/clock/sh7750-cpg.h
> @@ -0,0 +1,26 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> + *
> + * Copyright 2023 Yoshinori Sato
> + */
> +
> +#ifndef __DT_BINDINGS_CLOCK_SH7750_H__
> +#define __DT_BINDINGS_CLOCK_SH7750_H__
> +
> +#define SH7750_CPG_PLLOUT0
> +
> +#define SH7750_CPG_PCK 1
> +#define SH7750_CPG_BCK 2
> +#define SH7750_CPG_ICK 3
> +
> +#define SH7750_MSTP_SCI 4
> +#define SH7750_MSTP_RTC 5
> +#define SH7750_MSTP_TMU012 6
> +#define SH7750_MSTP_SCIF 7
> +#define SH7750_MSTP_DMAC 8
> +#define SH7750_MSTP_UBC 9
> +#define SH7750_MSTP_SQ 10
> +#define SH7750_CSTP_INTC 11
> +#define SH7750_CSTP_TMU3412
> +#define SH7750_CSTP_PCIC 13
> +
> +#endif
> --
> 2.39.2
>
Re: [RESEND v7 12/37] dt-bindings: pci: pci-sh7751: Add SH7751 PCI
On Thu, Apr 04, 2024 at 02:14:23PM +0900, Yoshinori Sato wrote:
> Renesas SH7751 PCI Controller json-schema.
>
> Signed-off-by: Yoshinori Sato
> ---
> .../bindings/pci/renesas,sh7751-pci.yaml | 89 +++
> 1 file changed, 89 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/pci/renesas,sh7751-pci.yaml
>
> diff --git a/Documentation/devicetree/bindings/pci/renesas,sh7751-pci.yaml
> b/Documentation/devicetree/bindings/pci/renesas,sh7751-pci.yaml
> new file mode 100644
> index ..115c2bb67339
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/renesas,sh7751-pci.yaml
> @@ -0,0 +1,89 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pci/renesas,sh7751-pci.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Renesas SH7751 PCI Host controller
> +
> +maintainers:
> + - Yoshinori Sato
> +
> +allOf:
> + - $ref: /schemas/pci/pci-bus.yaml#
> +
> +properties:
> + compatible:
> +const: renesas,sh7751-pci
> +
> + reg:
> +minItems: 2
> +maxItems: 2
> +
> + reg-names:
> +items:
> + - const: PCI Controller
> + - const: Bus State Controller
> +
> + "#interrupt-cells":
> +const: 1
> +
> + "#address-cells":
> +const: 3
> +
> + "#size-cells":
> +const: 2
> +
> + ranges: true
> +
> + dma-ranges: true
All 5 of these are defined in pci-bus-common.yaml, so you can drop them.
> +
> + interrupt-controller: true
> +
> + renesas,bus-arbit-round-robin:
> +$ref: /schemas/types.yaml#/definitions/flag
> +description: |
Don't need '|'.
> + Set DMA bus arbitration to round robin.
> +
> +required:
> + - compatible
> + - reg
> + - "#interrupt-cells"
> + - "#address-cells"
> + - "#size-cells"
> + - ranges
These 3 are already required, so drop.
> + - interrupt-map
> + - interrupt-map-mask
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> +#include
> +pci@fe20 {
> +compatible = "renesas,sh7751-pci";
> +#address-cells = <3>;
> +#size-cells = <2>;
> +#interrupt-cells = <1>;
> +interrupt-controller;
> +device_type = "pci";
> +bus-range = <0 0>;
> +ranges = <0x0200 0 0xfd00 0xfd00 0 0x0100>,
> + <0x0100 0 0x 0xfe24 0 0x0004>;
> +dma-ranges = <0x0200 0 0xc00 0x0c00 0 0x0400>;
> +reg = <0xfe20 0x0400>,
> + <0xff80 0x0100>;
> +interrupt-map = <0x 0 0 1 5 IRQ_TYPE_LEVEL_LOW>,
> +<0x 0 0 2 6 IRQ_TYPE_LEVEL_LOW>,
> +<0x 0 0 3 7 IRQ_TYPE_LEVEL_LOW>,
> +<0x 0 0 4 8 IRQ_TYPE_LEVEL_LOW>,
> +<0x0800 0 0 1 6 IRQ_TYPE_LEVEL_LOW>,
> +<0x0800 0 0 2 7 IRQ_TYPE_LEVEL_LOW>,
> +<0x0800 0 0 3 8 IRQ_TYPE_LEVEL_LOW>,
> +<0x0800 0 0 4 5 IRQ_TYPE_LEVEL_LOW>,
> +<0x1000 0 0 1 7 IRQ_TYPE_LEVEL_LOW>,
> +<0x1000 0 0 2 8 IRQ_TYPE_LEVEL_LOW>,
> +<0x1000 0 0 3 5 IRQ_TYPE_LEVEL_LOW>,
> +<0x1000 0 0 4 6 IRQ_TYPE_LEVEL_LOW>;
> +interrupt-map-mask = <0x1800 0 0 7>;
> +};
> --
> 2.39.2
>
Re: [RESEND v7 09/37] dt-binding: Add compatible SH7750 SoC
On Thu, 04 Apr 2024 14:14:20 +0900, Yoshinori Sato wrote: > Signed-off-by: Yoshinori Sato > --- > Documentation/devicetree/bindings/timer/renesas,tmu.yaml | 2 ++ > 1 file changed, 2 insertions(+) > Acked-by: Rob Herring
Re: [PATCH v2 04/18] ASoC: dt-bindings: mt6357: Add audio codec document
On Tue, 09 Apr 2024 12:13:25 +0200, Alexandre Mergnat wrote: > Add MT8365 audio codec bindings to set required > and optional voltage properties between the codec and the board. > The properties are: > - phandle of the requiered power supply. > - Setup of microphone bias voltage. > - Setup of the speaker pin pull-down. > > Signed-off-by: Alexandre Mergnat > --- > .../devicetree/bindings/sound/mt6357.yaml | 54 > ++ > 1 file changed, 54 insertions(+) > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/sound/mt6357.yaml: properties:vaud28-supply: '$ref' is not one of ['description', 'deprecated'] from schema $id: http://devicetree.org/meta-schemas/core.yaml# doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240226-audio-i350-v2-4-3043d483d...@baylibre.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH v2 03/18] dt-bindings: mfd: mediatek: Add codec property for MT6357 PMIC
On Tue, 09 Apr 2024 12:13:24 +0200, Alexandre Mergnat wrote: > Add the audio codec sub-device. This sub-device is used to set required > and optional voltage properties between the codec and the board. > > Signed-off-by: Alexandre Mergnat > --- > Documentation/devicetree/bindings/mfd/mediatek,mt6357.yaml | 5 + > 1 file changed, 5 insertions(+) > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mfd/mediatek,mt6357.yaml: Error in referenced schema matching $id: http://devicetree.org/schemas/sound/mt6357.yaml doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240226-audio-i350-v2-3-3043d483d...@baylibre.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: [RESEND v7 06/37] sh: kernel/setup Update DT support.
On Thu, Apr 4, 2024 at 12:15 AM Yoshinori Sato wrote: > > Fix extrnal fdt initialize and bootargs. What is the problem you are trying to solve? And a typo. > > Signed-off-by: Yoshinori Sato > --- > arch/sh/Kconfig | 23 +++ > arch/sh/include/asm/setup.h | 1 + > arch/sh/kernel/setup.c | 36 +++- > 3 files changed, 35 insertions(+), 25 deletions(-) > > diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig > index 6711cde0d973..242cf30e704d 100644 > --- a/arch/sh/Kconfig > +++ b/arch/sh/Kconfig > @@ -708,17 +708,22 @@ config ROMIMAGE_MMCIF > first part of the romImage which in turn loads the rest the kernel > image to RAM using the MMCIF hardware block. > > +config CMDLINE > + string "Kernel command line arguments string" > + default "console=ttySC1,115200" > + > choice > prompt "Kernel command line" > - optional > - default CMDLINE_OVERWRITE > - depends on !OF || USE_BUILTIN_DTB > + default CMDLINE_BOOTLOADER > + > +config CMDLINE_BOOTLOADER > + bool "Use bootloader kernel arguments" This should be the preferred, normal, default way. So why is it a user visible option? > help > - Setting this option allows the kernel command line arguments > - to be set. > + Uses the command-line options passed by the boot loader. > + If boot loader dosen't provide kernel argments, Use built-in > argments. typos bootloader in some spots, "boot loader" in others. Go with the former. > > config CMDLINE_OVERWRITE > - bool "Overwrite bootloader kernel arguments" > + bool "Overwrite built-in kernel arguments" The original made more sense to me. The default should be to use bootloader args. Any built-in kernel command line should be prepend, append (extend), or overwrite/replace. Rob
Re: [PATCH v1 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
On Thu, 04 Apr 2024 10:16:34 +0200, AngeloGioacchino Del Regno wrote:
> Document OF graph on MMSYS/VDOSYS: this supports up to three DDP paths
> per HW instance (so potentially up to six displays for multi-vdo SoCs).
>
> The MMSYS or VDOSYS is always the first component in the DDP pipeline,
> so it only supports an output port with multiple endpoints - where each
> endpoint defines the starting point for one of the (currently three)
> possible hardware paths.
>
> Signed-off-by: AngeloGioacchino Del Regno
>
> ---
> .../bindings/arm/mediatek/mediatek,mmsys.yaml | 23 +++
> 1 file changed, 23 insertions(+)
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml:
properties:port:properties:required: ['endpoint@0'] is not of type 'object',
'boolean'
from schema $id: http://json-schema.org/draft-07/schema#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml:
properties:port:properties: 'required' should not be valid under {'$ref':
'#/definitions/json-schema-prop-names'}
hint: A json-schema keyword was found instead of a DT property name.
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml:
properties:port:properties:required: ['endpoint@0'] is not of type 'object',
'boolean'
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml:
ignoring, error in schema: properties: port: properties: required
Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.example.dtb:
/example-0/syscon@1400: failed to match any schema with compatible:
['mediatek,mt8173-mmsys', 'syscon']
doc reference errors (make refcheckdocs):
See
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240404081635.91412-3-angelogioacchino.delre...@collabora.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
Re: [RESEND v7 19/37] dt-bindings: interrupt-controller: renesas,sh7751-irl-ext: Add json-schema
On Thu, 04 Apr 2024 14:14:30 +0900, Yoshinori Sato wrote: > Renesas SH7751 external interrupt encoder json-schema. > > Signed-off-by: Yoshinori Sato > --- > .../renesas,sh7751-irl-ext.yaml | 57 +++ > 1 file changed, 57 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/interrupt-controller/renesas,sh7751-irl-ext.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/interrupt-controller/renesas,sh7751-irl-ext.example.dtb: interrupt-controller@a400: #interrupt-cells:0:0: 2 was expected from schema $id: http://devicetree.org/schemas/interrupt-controller/renesas,sh7751-irl-ext.yaml# doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/8d8dec2d75890f3a14632c9606c332fb11d89a95.1712207606.git.ys...@users.sourceforge.jp 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.
Re: [PATCH v12 0/7] drm/meson: add support for MIPI DSI Display
On Wed, 03 Apr 2024 09:46:31 +0200, Neil Armstrong wrote: > The Amlogic G12A, G12B & SM1 SoCs embeds a Synopsys DW-MIPI-DSI transceiver > (ver 1.21a), > with a custom glue managing the IP resets, clock and data input similar to > the DW-HDMI > glue on the same Amlogic SoCs. > > This is a follow-up of v5 now the DRM patches are applied, the clk & DT > changes > remains for a full DSI support on G12A & SM1 platforms. > > The DW-MIPI-DSI transceiver + D-PHY are clocked by the GP0 PLL, and the ENCL > encoder + VIU > pixel reader by the VCLK2 clock using the HDMI PLL. > > The DW-MIPI-DSI transceiver gets this pixel stream as input clocked with the > VCLK2 clock. > > An optional "MEAS" clock can be enabled to measure the delay between each > vsync feeding the > DW-MIPI-DSI transceiver. > > The clock setup has been redesigned to use CCF, a common PLL (GP0) and the > VCLK2 clock > path for DSI in preparation of full CCF support and possibly dual display > with HDMI. > > The change from v5 is that now we use a "VCLK" driver instead of notifier and > rely > on CLK_SET_RATE_GATE to ensure the VCLK gate operation are called. > > Signed-off-by: Neil Armstrong > --- > Changes in v12: > - fix parameters alignment in patch 2 > - update g12a_mipi_dsi_pxclk_div_table comment with jerome's suggestions > - fix dtbs overlay build, fix missed v11... thx khadas for reporting it > off-list & testing > - Link to v11: > https://lore.kernel.org/r/20240325-amlogic-v6-4-upstream-dsi-ccf-vim3-v11-0-04f55de44...@linaro.org > > Changes in v11: > - Rebased on v6.9-rc1 > - Fixed overlay handling/creation > - Link to v10: > https://lore.kernel.org/r/20240205-amlogic-v6-4-upstream-dsi-ccf-vim3-v10-0-dc06073d5...@linaro.org > > Changes in v10: > - Rename regmap_vclk to meson_clk and add _gate for the gate > - Move COMMON_CLK_MESON_VCLK to following patch > - Remove CLK_SET_RATE_PARENT from g12a_vclk2_sel, keep it only on > mipi_dsi_pxclk_sel > - Add more info on commit message to specify how clock setup is designed > - Remove forgotten CLK_IGNORE_UNUSED on g12a_vclk2_input > - Remove useless CLK_SET_RATE_PARENT on g12a_vclk2_div to stop propagatting > rate _after_ vclk2_div > - Remove invalid CLK_SET_RATE_GATE on g12a_vclk2 since it's not a divider... > - Drop already applied patches > - move Khadas TS050 changes as an overlay > - Link to v9: > https://lore.kernel.org/r/20231124-amlogic-v6-4-upstream-dsi-ccf-vim3-v9-0-95256ed13...@linaro.org > > Changes in v9: > - Colledte reviewed-bys > - Fixed patches 2 & 4, commit messages and bindings format > - Link to v8: > https://lore.kernel.org/r/20231109-amlogic-v6-4-upstream-dsi-ccf-vim3-v8-0-81e4aeeda...@linaro.org > > Changes in v8: > - Switch vclk clk driver to parm as requested by Jerome > - Added bindings fixes to amlogic,meson-axg-mipi-pcie-analog & > amlogic,g12a-mipi-dphy-analog > - Fixed DT errors in vim3 example and MNT Reform DT > - Rebased on next-20231107, successfully tested on VIM3L > - Link to v7: > https://lore.kernel.org/r/20230803-amlogic-v6-4-upstream-dsi-ccf-vim3-v7-0-762219fc5...@linaro.org > > Changes in v7: > - Added review tags > - Fixed patch 5 thanks to George > - Link to v6: > https://lore.kernel.org/r/20230512-amlogic-v6-4-upstream-dsi-ccf-vim3-v6-0-fd2ac9845...@linaro.org > > Changes in v6: > - dropped applied DRM patches > - dropped clk private prefix patches > - rebased on top of > 20230607-topic-amlogic-upstream-clkid-public-migration-v2-0-38172d17c...@linaro.org > - re-ordered/cleaned ENCL patches to match clkid public migration > - Added new "vclk" driver > - uses vclk driver instead of notifier > - cleaned VCLK2 clk flags > - add px_clk gating from DSI driver > - Link to v5: > https://lore.kernel.org/r/20230512-amlogic-v6-4-upstream-dsi-ccf-vim3-v5-0-56eb7a4d5...@linaro.org > > Changes in v5: > - Aded PRIV all the G12 internal clk IDS to simplify public exposing > - Fixed the DSI bindings > - Fixed the DSI HSYNC/VSYNC polarity handling > - Fixed the DSI clock setup > - Fixed the DSI phy timings > - Dropped components for DSI, only keeping it for HDMI > - Added MNT Reform 2 CM4 DT > - Dropped already applied PHY fix > - Link to v4: > https://lore.kernel.org/r/20230512-amlogic-v6-4-upstream-dsi-ccf-vim3-v4-0-2592c29ea...@linaro.org > > Changes from v3 at [3]: > - switched all clk setup via CCF > - using single PLL for DSI controller & ENCL encoder > - added ENCL clocks to CCF > - make the VCLK2 clocks configuration by CCF > - fixed probe/bind of DSI controller to work with panels & bridges > - added bit_clk to controller to it can setup the BIT clock aswell > - added fix for components unbind > - added fix for analog phy setup value > - added TS050 timings fix > - dropped previous clk control patch > > Changes from v2 at [2]: > - Fixed patch 3 > - Added reviews from Jagan > - Rebased on v5.19-rc1 > > Changes from v1 at [1]: > - fixed DSI host bindings > - add reviewed-by tags for bindings > - moved magic values to defines
Re: [PATCH v5 1/2] dt-bindings: backlight: Add Texas Instruments LM3509
On Sat, Mar 30, 2024 at 03:59:24PM +0100, Patrick Gansterer wrote: > Add Device Tree bindings for Texas Instruments LM3509 - a > High Efficiency Boost for White LED's and/or OLED Displays > > Signed-off-by: Patrick Gansterer > Reviewed-by: Krzysztof Kozlowski > Reviewed-by: Daniel Thompson > --- > .../bindings/leds/backlight/ti,lm3509.yaml| 139 ++ > 1 file changed, 139 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/leds/backlight/ti,lm3509.yaml > > diff --git a/Documentation/devicetree/bindings/leds/backlight/ti,lm3509.yaml > b/Documentation/devicetree/bindings/leds/backlight/ti,lm3509.yaml > new file mode 100644 > index ..b67f67648852 > --- /dev/null > +++ b/Documentation/devicetree/bindings/leds/backlight/ti,lm3509.yaml > @@ -0,0 +1,139 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/leds/backlight/ti,lm3509.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: TI LM3509 High Efficiency Boost for White LED's and/or OLED Displays > + > +maintainers: > + - Patrick Gansterer > + > +description: > + The LM3509 current mode boost converter offers two separate outputs. > + https://www.ti.com/product/LM3509 > + > +properties: > + compatible: > +const: ti,lm3509 > + > + reg: > +maxItems: 1 > + > + "#address-cells": > +const: 1 > + > + "#size-cells": > +const: 0 > + > + reset-gpios: > +maxItems: 1 > + > + ti,brightness-rate-of-change-us: > +description: Brightness Rate of Change in microseconds. > +enum: [51, 13000, 26000, 52000] > + > + ti,oled-mode: > +description: Enable OLED mode. > +type: boolean > + > +patternProperties: > + "^led@[01]$": > +type: object > +description: Properties for a string of connected LEDs. > + > +allOf: You don't need allOf here. > + - $ref: common.yaml# > + > +properties: > + reg: > +description: > + The control register that is used to program the two current sinks. > + The LM3509 has two registers (BMAIN and BSUB) and are represented > + as 0 or 1 in this property. The two current sinks can be controlled > + independently with both registers, or register BMAIN can be > + configured to control both sinks with the led-sources property. > +minimum: 0 > +maximum: 1 > + > + label: true > + > + led-sources: > +allOf: Or here. > + - minItems: 1 > +maxItems: 2 > +items: > + minimum: 0 > + maximum: 1
Re: [PATCH 2/3] dt-bindings: display: msm: sm6350-mdss: document DP controller subnode
On Thu, Mar 28, 2024 at 10:42:45AM +0100, Luca Weiss wrote: > Document the displayport controller subnode of the SM6350 MDSS. > > Signed-off-by: Luca Weiss > --- > .../devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml | 10 > ++ > 1 file changed, 10 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml > b/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml > index c9ba1fae8042..d91b8eca6aba 100644 > --- a/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml > +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml > @@ -53,6 +53,16 @@ patternProperties: >compatible: > const: qcom,sm6350-dpu > > + "^displayport-controller@[0-9a-f]+$": > +type: object > +additionalProperties: true > + > +properties: > + compatible: > +items: > + - const: qcom,sm6350-dp > + - const: qcom,sm8350-dp Just use 'contains' here with qcom,sm6350-dp. The full schema will check the order. Rob
Re: [PATCH 1/3] dt-bindings: display: msm: dp-controller: document SM8250 compatible
On Thu, 28 Mar 2024 10:42:44 +0100, Luca Weiss wrote: > Add the compatible string for the DisplayPort controller on SM6350 which > is compatible with the one on SM8350. > > Signed-off-by: Luca Weiss > --- > Documentation/devicetree/bindings/display/msm/dp-controller.yaml | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring
Re: [PATCH v2] dt-bindings: display: bridge: it6505: Add #sound-dai-cells
On Wed, 27 Mar 2024 16:52:48 +0800, Chen-Yu Tsai wrote: > The ITE IT6505 display bridge can take one I2S input and transmit it > over the DisplayPort link. > > Add #sound-dai-cells (= 0) to the binding for it. > > Signed-off-by: Chen-Yu Tsai > --- > Changes since v1 [1]: > - Reference /schemas/sound/dai-common.yaml > - Change "additionalProperties: false" to "unevaluatedProperties: false" > > The driver side changes [2] are still being worked on. > > [1] > https://lore.kernel.org/dri-devel/20240126073511.2708574-1-we...@chromium.org/ > [2] > https://lore.kernel.org/linux-arm-kernel/20230730180803.22570-4-jiaxin...@mediatek.com/ > --- > .../devicetree/bindings/display/bridge/ite,it6505.yaml| 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > Reviewed-by: Rob Herring
Re: [PATCH 1/4] dt-bindings: display: bridge: add the Hot-plug MIPI DSI connector
On Tue, Mar 26, 2024 at 05:28:11PM +0100, Luca Ceresoli wrote: > Add bindings for a physical, hot-pluggable connector allowing the far end > of a MIPI DSI bus to be connected and disconnected at runtime. > > Signed-off-by: Luca Ceresoli > --- > .../bridge/hotplug-video-connector-dsi.yaml| 87 > ++ > MAINTAINERS| 5 ++ > 2 files changed, 92 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/bridge/hotplug-video-connector-dsi.yaml > > b/Documentation/devicetree/bindings/display/bridge/hotplug-video-connector-dsi.yaml > new file mode 100644 > index ..05beb8aa9ab4 > --- /dev/null > +++ > b/Documentation/devicetree/bindings/display/bridge/hotplug-video-connector-dsi.yaml > @@ -0,0 +1,87 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: > http://devicetree.org/schemas/display/bridge/hotplug-video-connector-dsi.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Hot-pluggable connector on a MIPI DSI bus > + > +maintainers: > + - Luca Ceresoli > + > +description: > + A bridge representing a physical, hot-pluggable connector on a MIPI DSI > + video bus. The connector splits the video pipeline in a fixed part and a > + removable part. > + > + The fixed part of the video pipeline includes all components up to the > + display controller and 0 or more bridges. The removable part includes one > + or more bridges and any other components up to the panel. > + > + The removable part of the pipeline can be physically disconnected at any > + moment, making all of its components not usable anymore. The same or a > + different removable part of the pipeline can be reconnected later on. > + > + Note that the hotplug-video-connector does not describe video busses > + having native hotplug capabilities in the hardware, such as HDMI. > + > +properties: > + compatible: > +const: hotplug-video-connector-dsi Got a spec for this connector? How do I know if I have one or not? The problem here is what else is on this connector? GPIO controls, power rails, etc.? If this is some kind of standard connector, then we need to be able to remap everything on the connector not just DSI signals. And for that, it's not just DSI signals, so I'd say we would need some sort of generic graph remapping that the core graph code handles transparently. If it is not standard, then you don't need any remapping and can just use an overlay that connects the ports directly. Rob
Re: [PATCH 2/5] dt-bindings: display: Add GameForce Chi Panel
On Mon, 25 Mar 2024 08:49:56 -0500, Chris Morgan wrote: > From: Chris Morgan > > The GameForce Chi panel is a panel specific to the GameForce Chi > handheld device that measures 3.5" diagonally with a resolution of > 640x480. > > Signed-off-by: Chris Morgan > --- > .../devicetree/bindings/display/panel/rocktech,jh057n00900.yaml | 2 ++ > 1 file changed, 2 insertions(+) > Acked-by: Rob Herring
Re: [PATCH 1/5] dt-bindings: vendor-prefix: Add prefix for GameForce
On Mon, 25 Mar 2024 08:49:55 -0500, Chris Morgan wrote: > From: Chris Morgan > > GameForce is a company that produces handheld game consoles. > > https://gameforce.fun/ > > Signed-off-by: Chris Morgan > --- > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ > 1 file changed, 2 insertions(+) > Acked-by: Rob Herring
Re: [PATCH v4] dt-bindings: display: atmel,lcdc: convert to dtschema
On Mon, 18 Mar 2024 11:10:13 +0530, Dharma Balasubiramani wrote: > Convert the atmel,lcdc bindings to DT schema. > Changes during conversion: add missing clocks and clock-names properties. > > Signed-off-by: Dharma Balasubiramani > --- > This patch converts the existing lcdc display text binding to JSON schema. > The binding is split into two namely > lcdc.yaml > - Holds the frame buffer properties > lcdc-display.yaml > - Holds the display panel properties which is a phandle to the display > property in lcdc fb node. > > These bindings are tested using the following command. > 'make DT_CHECKER_FLAGS=-m dt_binding_check' > --- > Changes in v4: > - Add maximum for atmel,guard-time property. > - Add constraints for bits-per-pixel property. > - Update the atmel,lcd-wiring-mode property's ref to point single string > rather than an array. > - Add constraints for atmel,lcd-wiring-mode property. > - Add maxItems to the atmel,power-control-gpio property. > - Link to v3: > https://lore.kernel.org/r/20240304-lcdc-fb-v3-1-8b616fbb0...@microchip.com > > Changes in v3: > - Remove the generic property "bits-per-pixel" > - Link to v2: > https://lore.kernel.org/r/20240304-lcdc-fb-v2-1-a14b463c1...@microchip.com > > Changes in v2: > - Run checkpatch and remove whitespace errors. > - Add the standard interrupt flags. > - Split the binding into two, namely lcdc.yaml and lcdc-display.yaml. > - Link to v1: > https://lore.kernel.org/r/20240223-lcdc-fb-v1-1-4c64cb627...@microchip.com > --- > .../bindings/display/atmel,lcdc-display.yaml | 103 > + > .../devicetree/bindings/display/atmel,lcdc.txt | 87 - > .../devicetree/bindings/display/atmel,lcdc.yaml| 70 ++ > 3 files changed, 173 insertions(+), 87 deletions(-) > Applied, thanks!
Re: [PATCH v2] dt-bindings: display: samsung,exynos5-dp: convert to DT Schema
On Wed, 13 Mar 2024 19:28:55 +0100, Krzysztof Kozlowski wrote: > Convert Samsung Exynos5250/5420 SoC Display Port Controller bindings to > DT schema with a change: add power-domains, already used in DTS. > > This Display Port controller is actually variant of Analogix Display > Port bridge, however new DT Schema does not reference analogix,dp.yaml, > because of incompatibilities in the driver. The analogix,dp.yaml > expects two ports, input and output, but Linux Exynos DP DRM driver and > DTS use only one port: output. > > Signed-off-by: Krzysztof Kozlowski > > --- > > Changes in v2: > 1. Document deprecated samsung,hpd-gpios > --- > .../bindings/display/exynos/exynos_dp.txt | 112 > .../display/samsung/samsung,exynos5-dp.yaml | 163 ++ > 2 files changed, 163 insertions(+), 112 deletions(-) > delete mode 100644 > Documentation/devicetree/bindings/display/exynos/exynos_dp.txt > create mode 100644 > Documentation/devicetree/bindings/display/samsung/samsung,exynos5-dp.yaml > Applied, thanks!
Re: [RESEND PATCH] dt-bindings: display: sony,td4353-jdi: allow width-mm and height-mm
On Mon, 25 Mar 2024 11:32:27 +0100, Krzysztof Kozlowski wrote: > Allow width and height properties from panel-common.yaml, already used > on some boards: > > sdm845-sony-xperia-tama-apollo.dtb: panel@0: 'height-mm', 'width-mm' do not > match any of the regexes: 'pinctrl-[0-9]+' > > Acked-by: Conor Dooley > Signed-off-by: Krzysztof Kozlowski > --- > > Rob, could you pick up this one? Was on the list for almost a year. > > > .../devicetree/bindings/display/panel/sony,td4353-jdi.yaml | 2 ++ > 1 file changed, 2 insertions(+) > Applied, thanks!
Re: [PATCH v11 0/7] drm/meson: add support for MIPI DSI Display
On Mon, 25 Mar 2024 12:09:46 +0100, Neil Armstrong wrote: > The Amlogic G12A, G12B & SM1 SoCs embeds a Synopsys DW-MIPI-DSI transceiver > (ver 1.21a), > with a custom glue managing the IP resets, clock and data input similar to > the DW-HDMI > glue on the same Amlogic SoCs. > > This is a follow-up of v5 now the DRM patches are applied, the clk & DT > changes > remains for a full DSI support on G12A & SM1 platforms. > > The DW-MIPI-DSI transceiver + D-PHY are clocked by the GP0 PLL, and the ENCL > encoder + VIU > pixel reader by the VCLK2 clock using the HDMI PLL. > > The DW-MIPI-DSI transceiver gets this pixel stream as input clocked with the > VCLK2 clock. > > An optional "MEAS" clock can be enabled to measure the delay between each > vsync feeding the > DW-MIPI-DSI transceiver. > > The clock setup has been redesigned to use CCF, a common PLL (GP0) and the > VCLK2 clock > path for DSI in preparation of full CCF support and possibly dual display > with HDMI. > > The change from v5 is that now we use a "VCLK" driver instead of notifier and > rely > on CLK_SET_RATE_GATE to ensure the VCLK gate operation are called. > > Signed-off-by: Neil Armstrong > --- > Changes in v11: > - Rebased on v6.9-rc1 > - Fixed overlay handling/creation > - Link to v10: > https://lore.kernel.org/r/20240205-amlogic-v6-4-upstream-dsi-ccf-vim3-v10-0-dc06073d5...@linaro.org > > Changes in v10: > - Rename regmap_vclk to meson_clk and add _gate for the gate > - Move COMMON_CLK_MESON_VCLK to following patch > - Remove CLK_SET_RATE_PARENT from g12a_vclk2_sel, keep it only on > mipi_dsi_pxclk_sel > - Add more info on commit message to specify how clock setup is designed > - Remove forgotten CLK_IGNORE_UNUSED on g12a_vclk2_input > - Remove useless CLK_SET_RATE_PARENT on g12a_vclk2_div to stop propagatting > rate _after_ vclk2_div > - Remove invalid CLK_SET_RATE_GATE on g12a_vclk2 since it's not a divider... > - Drop already applied patches > - move Khadas TS050 changes as an overlay > - Link to v9: > https://lore.kernel.org/r/20231124-amlogic-v6-4-upstream-dsi-ccf-vim3-v9-0-95256ed13...@linaro.org > > Changes in v9: > - Colledte reviewed-bys > - Fixed patches 2 & 4, commit messages and bindings format > - Link to v8: > https://lore.kernel.org/r/20231109-amlogic-v6-4-upstream-dsi-ccf-vim3-v8-0-81e4aeeda...@linaro.org > > Changes in v8: > - Switch vclk clk driver to parm as requested by Jerome > - Added bindings fixes to amlogic,meson-axg-mipi-pcie-analog & > amlogic,g12a-mipi-dphy-analog > - Fixed DT errors in vim3 example and MNT Reform DT > - Rebased on next-20231107, successfully tested on VIM3L > - Link to v7: > https://lore.kernel.org/r/20230803-amlogic-v6-4-upstream-dsi-ccf-vim3-v7-0-762219fc5...@linaro.org > > Changes in v7: > - Added review tags > - Fixed patch 5 thanks to George > - Link to v6: > https://lore.kernel.org/r/20230512-amlogic-v6-4-upstream-dsi-ccf-vim3-v6-0-fd2ac9845...@linaro.org > > Changes in v6: > - dropped applied DRM patches > - dropped clk private prefix patches > - rebased on top of > 20230607-topic-amlogic-upstream-clkid-public-migration-v2-0-38172d17c...@linaro.org > - re-ordered/cleaned ENCL patches to match clkid public migration > - Added new "vclk" driver > - uses vclk driver instead of notifier > - cleaned VCLK2 clk flags > - add px_clk gating from DSI driver > - Link to v5: > https://lore.kernel.org/r/20230512-amlogic-v6-4-upstream-dsi-ccf-vim3-v5-0-56eb7a4d5...@linaro.org > > Changes in v5: > - Aded PRIV all the G12 internal clk IDS to simplify public exposing > - Fixed the DSI bindings > - Fixed the DSI HSYNC/VSYNC polarity handling > - Fixed the DSI clock setup > - Fixed the DSI phy timings > - Dropped components for DSI, only keeping it for HDMI > - Added MNT Reform 2 CM4 DT > - Dropped already applied PHY fix > - Link to v4: > https://lore.kernel.org/r/20230512-amlogic-v6-4-upstream-dsi-ccf-vim3-v4-0-2592c29ea...@linaro.org > > Changes from v3 at [3]: > - switched all clk setup via CCF > - using single PLL for DSI controller & ENCL encoder > - added ENCL clocks to CCF > - make the VCLK2 clocks configuration by CCF > - fixed probe/bind of DSI controller to work with panels & bridges > - added bit_clk to controller to it can setup the BIT clock aswell > - added fix for components unbind > - added fix for analog phy setup value > - added TS050 timings fix > - dropped previous clk control patch > > Changes from v2 at [2]: > - Fixed patch 3 > - Added reviews from Jagan > - Rebased on v5.19-rc1 > > Changes from v1 at [1]: > - fixed DSI host bindings > - add reviewed-by tags for bindings > - moved magic values to defines thanks to Martin's searches > - added proper prefixes to defines > - moved phy_configure to phy_init() dw-mipi-dsi callback > - moved phy_on to a new phy_power_on() dw-mipi-dsi callback > - correctly return phy_init/configure errors to callback returns > > [1] https://lore.kernel.org/r/20200907081825.1654-1-narmstr...@baylibre.com > [2]
Re: [PATCH v3 8/9] dt-bindings: xlnx: Add VTC and TPG bindings
On Thu, 21 Mar 2024 13:43:46 -0700, Anatoliy Klymenko wrote: > DO NOT MERGE. REFERENCE ONLY. > > Add binding for AMD/Xilinx Video Timing Controller and Test Pattern > Generator. > > Copy media-bus-formats.h into dt-bindings/media to suplement TPG DT node. > > Signed-off-by: Anatoliy Klymenko > --- > .../bindings/display/xlnx/xlnx,v-tpg.yaml | 87 ++ > .../devicetree/bindings/display/xlnx/xlnx,vtc.yaml | 65 > include/dt-bindings/media/media-bus-format.h | 177 > + > 3 files changed, 329 insertions(+) > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: ./Documentation/devicetree/bindings/display/xlnx/xlnx,v-tpg.yaml:35:4: [warning] wrong indentation: expected 4 but found 3 (indentation) ./Documentation/devicetree/bindings/display/xlnx/xlnx,v-tpg.yaml:45:8: [warning] wrong indentation: expected 8 but found 7 (indentation) ./Documentation/devicetree/bindings/display/xlnx/xlnx,v-tpg.yaml:49:8: [warning] wrong indentation: expected 8 but found 7 (indentation) dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/xlnx/xlnx,v-tpg.yaml: bus-format: missing type definition /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/xlnx/xlnx,v-tpg.yaml: xlnx,bridge: missing type definition /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/xlnx/xlnx,vtc.yaml: xlnx,pixels-per-clock: missing type definition doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240321-dp-live-fmt-v3-8-d5090d796...@amd.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH v2] dt-bindings: display: samsung,exynos5-dp: convert to DT Schema
On Thu, Mar 21, 2024 at 08:37:15AM +0100, Krzysztof Kozlowski wrote: > On 20/03/2024 18:04, Conor Dooley wrote: > > On Wed, Mar 13, 2024 at 07:28:55PM +0100, Krzysztof Kozlowski wrote: > > > >> + clock-names: > >> +items: > >> + - const: dp > > > >> + phy-names: > >> +items: > >> + - const: dp > > > > The items lists here are redundant when you only have a single item, no? > > Isnt it just > > phy-names: > > const: dp > > Somehow the convention for properties was to define the list. Unlike for > compatible where we use shorter syntax like you propose. Shall we change > the approach and use shorter syntax in general? I guess the difference is -names is usually more than 1 whereas compatible is frequently only 1. Either way is fine I think. Rob
Re: [PATCH v2 2/4] dt-bindings: display/xlnx/zynqmp-dpsub: Add audio DMAs
On Tue, Mar 19, 2024 at 10:22:37AM +0200, Tomi Valkeinen wrote: > The DP subsystem for ZynqMP support audio via two channels, and the DP > DMA has dma-engines for those channels. For some reason the DT binding > has not specified those channels, even if the picture included in > xlnx,zynqmp-dpsub.yaml shows "2 x aud" DMAs. New required entries is an ABI change. This message kind of indicates it was a mistake, but should be a lot more explicit. Are things broken without the entries? Need 'Fixes'? > > Add the two audio DMAs to the binding. > > Signed-off-by: Tomi Valkeinen > --- > .../devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml| 10 > -- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff --git > a/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml > b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml > index 554f9d5809d4..6b754d4f260e 100644 > --- a/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml > +++ b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml > @@ -100,12 +100,16 @@ properties: >- description: Video layer, plane 1 (U/V or U) >- description: Video layer, plane 2 (V) >- description: Graphics layer > + - description: Audio channel 0 > + - description: Audio channel 1 >dma-names: > items: >- const: vid0 >- const: vid1 >- const: vid2 >- const: gfx0 > + - const: aud0 > + - const: aud1 > >phys: > description: PHYs for the DP data lanes > @@ -194,11 +198,13 @@ examples: > power-domains = <_dp>; > resets = < ZYNQMP_RESET_DP>; > > -dma-names = "vid0", "vid1", "vid2", "gfx0"; > +dma-names = "vid0", "vid1", "vid2", "gfx0", "aud0", "aud1"; > dmas = <_dpdma 0>, > <_dpdma 1>, > <_dpdma 2>, > - <_dpdma 3>; > + <_dpdma 3>, > + <_dpdma 4>, > + <_dpdma 5>; > > phys = < 1 PHY_TYPE_DP 0 3>, > < 0 PHY_TYPE_DP 1 3>; > > -- > 2.34.1 >
Re: [PATCH 1/2] dt-bindings: ili9881c: Add Startek KD050HDFIA020-C020A support
On Sun, 17 Mar 2024 17:57:45 +0200, Laurent Pinchart wrote: > Document the compatible value for Startek KD050HDFIA020-C020A panels. > > Signed-off-by: Laurent Pinchart > --- > .../devicetree/bindings/display/panel/ilitek,ili9881c.yaml | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring
Re: [PATCH v2 7/8] dt-bindings: xlnx: Add VTC and TPG bindings
On Tue, 12 Mar 2024 17:55:04 -0700, Anatoliy Klymenko wrote: > DO NOT MERGE. REFERENCE ONLY. > > Add binding for AMD/Xilinx Video Timing Controller and Test Pattern > Generator. > > Copy media-bus-formats.h into dt-bindings/media to suplement TPG DT node. > > Signed-off-by: Anatoliy Klymenko > --- > .../bindings/display/xlnx/xlnx,v-tpg.yaml | 87 ++ > .../devicetree/bindings/display/xlnx/xlnx,vtc.yaml | 65 > include/dt-bindings/media/media-bus-format.h | 177 > + > 3 files changed, 329 insertions(+) > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: ./Documentation/devicetree/bindings/display/xlnx/xlnx,v-tpg.yaml:35:4: [warning] wrong indentation: expected 4 but found 3 (indentation) ./Documentation/devicetree/bindings/display/xlnx/xlnx,v-tpg.yaml:45:8: [warning] wrong indentation: expected 8 but found 7 (indentation) ./Documentation/devicetree/bindings/display/xlnx/xlnx,v-tpg.yaml:49:8: [warning] wrong indentation: expected 8 but found 7 (indentation) dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/xlnx/xlnx,vtc.yaml: xlnx,pixels-per-clock: missing type definition /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/xlnx/xlnx,v-tpg.yaml: bus-format: missing type definition /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/xlnx/xlnx,v-tpg.yaml: xlnx,bridge: missing type definition doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240312-dp-live-fmt-v2-7-a9c35dc5c...@amd.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH 2/4] dt-bindings: display/xlnx/zynqmp-dpsub: Add audio DMAs
On Tue, 12 Mar 2024 11:41:03 +0200, Tomi Valkeinen wrote: > The DP subsystem for ZynqMP support audio via two channels, and the DP > DMA has dma-engines for those channels. For some reason the DT binding > has not specified those channels, even if the picture included in > xlnx,zynqmp-dpsub.yaml shows "2 x aud" DMAs. > > Add the two audio DMAs to the binding. > > Signed-off-by: Tomi Valkeinen > --- > .../devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml| 10 > -- > 1 file changed, 8 insertions(+), 2 deletions(-) > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: Error: Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.example.dts:54.26-27 syntax error FATAL ERROR: Unable to parse input tree make[2]: *** [scripts/Makefile.lib:419: Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.example.dtb] Error 1 make[2]: *** Waiting for unfinished jobs make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1428: dt_binding_check] Error 2 make: *** [Makefile:240: __sub-make] Error 2 doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240312-xilinx-dp-audio-v1-2-696c79fac...@ideasonboard.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH 02/12] dt-bindings: display: imx/ldb: drop ddc-i2c-bus property
On Mon, 11 Mar 2024 13:20:10 +0200, Dmitry Baryshkov wrote: > The in-kernel DT files do not use ddc-i2c-bus property with the iMX LVDS > Display Bridge. If in future a need arises to support such usecase, the > panel-simple should be used, which is able to handle the DDC bus. > > Signed-off-by: Dmitry Baryshkov > --- > Documentation/devicetree/bindings/display/imx/ldb.txt | 1 - > 1 file changed, 1 deletion(-) > Acked-by: Rob Herring
Re: [PATCH 01/12] dt-bindings: display: fsl-imx-drm: drop edid property support
On Mon, 11 Mar 2024 13:20:09 +0200, Dmitry Baryshkov wrote: > None of the in-kernel DT files ever used edid override with the > fsl-imx-drm driver. In case the EDID needs to be specified manually, DRM > core allows one to either override it via the debugfs or to load it via > request_firmware by using DRM_LOAD_EDID_FIRMWARE. In all other cases > EDID and/or modes are to be provided as a part of the panel driver. > > Drop the edid property from the fsl-imx-drm bindings. > > Signed-off-by: Dmitry Baryshkov > --- > Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt | 2 -- > 1 file changed, 2 deletions(-) > Acked-by: Rob Herring
Re: [PATCH v3] dt-bindings: display: atmel,lcdc: convert to dtschema
On Mon, Mar 04, 2024 at 08:00:03PM +0530, Dharma Balasubiramani wrote:
> Convert the atmel,lcdc bindings to DT schema.
> Changes during conversion: add missing clocks and clock-names properties.
>
> Signed-off-by: Dharma Balasubiramani
> ---
> This patch converts the existing lcdc display text binding to JSON schema.
> The binding is split into two namely
> lcdc.yaml
> - Holds the frame buffer properties
> lcdc-display.yaml
> - Holds the display panel properties which is a phandle to the display
> property in lcdc fb node.
>
> These bindings are tested using the following command.
> 'make DT_CHECKER_FLAGS=-m dt_binding_check'
> ---
> Changes in v3:
> - Remove the generic property "bits-per-pixel"
> - Link to v2:
> https://lore.kernel.org/r/20240304-lcdc-fb-v2-1-a14b463c1...@microchip.com
>
> Changes in v2:
> - Run checkpatch and remove whitespace errors.
> - Add the standard interrupt flags.
> - Split the binding into two, namely lcdc.yaml and lcdc-display.yaml.
> - Link to v1:
> https://lore.kernel.org/r/20240223-lcdc-fb-v1-1-4c64cb627...@microchip.com
> ---
> .../bindings/display/atmel,lcdc-display.yaml | 97
> ++
> .../devicetree/bindings/display/atmel,lcdc.txt | 87 ---
> .../devicetree/bindings/display/atmel,lcdc.yaml| 70
> 3 files changed, 167 insertions(+), 87 deletions(-)
>
> diff --git
> a/Documentation/devicetree/bindings/display/atmel,lcdc-display.yaml
> b/Documentation/devicetree/bindings/display/atmel,lcdc-display.yaml
> new file mode 100644
> index ..5e0b706d695d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/atmel,lcdc-display.yaml
> @@ -0,0 +1,97 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/atmel,lcdc-display.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Microchip's LCDC Display
> +
> +maintainers:
> + - Nicolas Ferre
> + - Dharma Balasubiramani
> +
> +description:
> + The LCD Controller (LCDC) consists of logic for transferring LCD image data
> + from an external display buffer to a TFT LCD panel. The LCDC has one
> display
> + input buffer per layer that fetches pixels through the single bus host
> + interface and a look-up table to allow palletized display configurations.
> The
> + LCDC is programmable on a per layer basis, and supports different LCD
> + resolutions, window sizes, image formats and pixel depths.
> +
> +# We need a select here since this schema is applicable only for nodes with
> the
> +# following properties
> +
> +select:
> + anyOf:
> +- required: [ 'atmel,dmacon' ]
> +- required: [ 'atmel,lcdcon2' ]
> +- required: [ 'atmel,guard-time' ]
> +
> +properties:
> + atmel,dmacon:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: dma controller configuration
> +
> + atmel,lcdcon2:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: lcd controller configuration
> +
> + atmel,guard-time:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: lcd guard time (Delay in frame periods)
Is there a maximum?
> +
> + bits-per-pixel:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: lcd panel bit-depth.
Constraints?
> +
> + atmel,lcdcon-backlight:
> +$ref: /schemas/types.yaml#/definitions/flag
> +description: enable backlight
> +
> + atmel,lcdcon-backlight-inverted:
> +$ref: /schemas/types.yaml#/definitions/flag
> +description: invert backlight PWM polarity
> +
> + atmel,lcd-wiring-mode:
> +$ref: /schemas/types.yaml#/definitions/non-unique-string-array
Isn't this just a single string rather than an array?
> +description: lcd wiring mode "RGB" or "BRG"
enum:
- RGB
- BRG
No BGR?
But wait, the example shows the value is '1'. That should fail testing.
It didn't, but I've now fixed that.
> +
> + atmel,power-control-gpio:
> +description: gpio to power on or off the LCD (as many as needed)
maxItems: 1
> +
> + display-timings:
> +$ref: panel/display-timings.yaml#
> +
> +required:
> + - atmel,dmacon
> + - atmel,lcdcon2
> + - atmel,guard-time
> + - bits-per-pixel
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +display: panel {
> + bits-per-pixel = <32>;
> + atmel,lcdcon-backlight;
> + atmel,dmacon = <0x1>;
> + atmel,lcdcon2 = <0x80008002>;
> + atmel,guard-time = <9>;
> + atmel,lcd-wiring-mode = <1>;
> +
> + display-timings {
> +native-mode = <>;
> +timing0: timing0 {
> + clock-frequency = <900>;
> + hactive = <480>;
> + vactive = <272>;
> + hback-porch = <1>;
> + hfront-porch = <1>;
> + vback-porch = <40>;
> + vfront-porch = <1>;
> + hsync-len = <45>;
> + vsync-len = <1>;
> +};
> + };
> +};
Re: [PATCH v2 0/3] panel-simple: add support for Crystal Clear CMT430B19N00
On Mon, Mar 04, 2024 at 07:29:04PM +, Conor Dooley wrote: > On Mon, Mar 04, 2024 at 05:04:51PM +0100, Jérémie Dautheribes wrote: > > Hello everyone, > > > > This patch series add support for the Crystal Clear Technology > > CMT430B19N00 4.3" 480x272 TFT-LCD panel. > > It also adds Crystal Clear Technology to vendor-prefixes.yaml. > > > > Please note that unfortunately there is no public datasheet available > > for this panel. > > > > Changes in v2: > > - add link to the Crystal Clear Technology website in commit message, as > > suggested by Conor Dooley and Neil Armstrong. > > You forgot however to add the acks that I gave you for the two > dt-binding patches. I was wondering why my scripts said this was already reviewed with that missing. Turns out b4 will now check prior versions and add the tags as long as the patch-id matches. Neat, but the submitter really has to grasp how that all works (knowing if the patch-id changed) as well as the maintainer has to use b4, so we can't really rely on it. Here's b4 debug log: new message: 20240223-subtotal-aground-268d135adeff@spud Running git --no-pager patch-id --stable found matching patch-id for Re: [PATCH 2/3] dt-bindings: display: simple: add support for Crystal Clear CMT430B19N00 new message: 20240229-woven-lively-1d90687b2d03@spud skipping reply without trailers: 20240229-woven-lively-1d90687b2d03@spud new message: 20240223134517.728568-2-jeremie.dautheri...@bootlin.com skipping non-reply: 20240223134517.728568-2-jeremie.dautheri...@bootlin.com Analyzing follow-up: Re: [PATCH v2 0/3] panel-simple: add support for Crystal Clear CMT430B19N00 (co...@kernel.org) no trailers found, skipping Analyzing follow-up: Re: [PATCH v2 3/3] drm/panel: simple: add CMT430B19N00 LCD panel support (mrip...@kernel.org) no trailers found, skipping adding "Acked-by: Conor Dooley " from trailer_map to: [PATCH v2 1/3] dt-bindings: Add Crystal C lear Technology vendor prefix adding "Link: http://www.cct.com.my/; from trailer_map to: [PATCH v2 1/3] dt-bindings: Add Crystal Clear Technology vendor prefix adding "Acked-by: Conor Dooley " from trailer_map to: [PATCH v2 2/3] dt-bindings: display: simp le: add support for Crystal Clear CMT430B19N00 adding "Reviewed-by: Neil Armstrong " from trailer_map to: [PATCH v2 3/3] drm/panel: simple: add CMT430B19N00 LCD panel support adding "Reviewed-by: Jessica Zhang " from trailer_map to: [PATCH v2 3/3] drm/panel: simple: add CMT430B19N00 LCD panel support
Re: [PATCH v2] dt-bindings: display: atmel,lcdc: convert to dtschema
On Mon, 04 Mar 2024 11:06:39 +0530, Dharma Balasubiramani wrote: > Convert the atmel,lcdc bindings to DT schema. > Changes during conversion: add missing clocks and clock-names properties. > > Signed-off-by: Dharma Balasubiramani > --- > This patch converts the existing lcdc display text binding to JSON schema. > The binding is split into two namely > lcdc.yaml > - Holds the frame buffer properties > lcdc-display.yaml > - Holds the display panel properties which is a phandle to the display > property in lcdc fb node. > > These bindings are tested against the existing at91 dts files using > dtbs_check. > --- > Changes in v2: > - Run checkpatch and remove whitespace errors. > - Add the standard interrupt flags. > - Split the binding into two, namely lcdc.yaml and lcdc-display.yaml. > - Link to v1: > https://lore.kernel.org/r/20240223-lcdc-fb-v1-1-4c64cb627...@microchip.com > --- > .../bindings/display/atmel,lcdc-display.yaml | 98 > ++ > .../devicetree/bindings/display/atmel,lcdc.txt | 87 --- > .../devicetree/bindings/display/atmel,lcdc.yaml| 70 > 3 files changed, 168 insertions(+), 87 deletions(-) > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/imx/fsl,imx-lcdc.example.dtb: display0: 'atmel,dmacon' is a required property from schema $id: http://devicetree.org/schemas/display/atmel,lcdc-display.yaml# /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/imx/fsl,imx-lcdc.example.dtb: display0: 'atmel,lcdcon2' is a required property from schema $id: http://devicetree.org/schemas/display/atmel,lcdc-display.yaml# /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/imx/fsl,imx-lcdc.example.dtb: display0: 'atmel,guard-time' is a required property from schema $id: http://devicetree.org/schemas/display/atmel,lcdc-display.yaml# /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/imx/fsl,imx-lcdc.example.dtb: display0: 'fsl,pcr', 'model' do not match any of the regexes: 'pinctrl-[0-9]+' from schema $id: http://devicetree.org/schemas/display/atmel,lcdc-display.yaml# doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240304-lcdc-fb-v2-1-a14b463c1...@microchip.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
