Re: [PATCH v2 3/3] dt-bindings: display: vop2: Add VP clock resets
On Wed, May 22, 2024 at 02:57:50PM -0400, Detlev Casanova wrote: > Add the documentation for VOP2 video ports reset clocks. > One reset can be set per video port. Reviewed-by: Conor Dooley Cheers, Conor. signature.asc Description: PGP signature
Re: [PATCH 3/3] dt-bindings: display: vop2: Add VP clock resets
On Wed, May 22, 2024 at 11:31:36AM -0400, Detlev Casanova wrote: > On Tuesday, May 21, 2024 2:31:51 P.M. EDT Conor Dooley wrote: > > On Tue, May 21, 2024 at 01:15:46PM -0400, Detlev Casanova wrote: > > > On Wednesday, May 15, 2024 12:33:22 P.M. EDT Heiko Stübner wrote: > > > > Am Mittwoch, 15. Mai 2024, 18:19:29 CEST schrieb Conor Dooley: > > > > > On Tue, May 14, 2024 at 11:19:47AM -0400, Detlev Casanova wrote: > > > > > > Add the documentation for VOP2 video ports reset clocks. > > > > > > One reset can be set per video port. > > > > > > > > > > > > Signed-off-by: Detlev Casanova > > > > > > > > > > Are these resets valid for all VOPs or just the one on 3588? > > > > > > > > Not in that form. > > > > I.e. rk3588 has 4 video-ports (0-3), while rk3568 has 3 (0-2). > > > > > > > > So the binding should take into account that rk3568 also has the > > > > SRST_VOP0 ... SRST_VOP2. > > > > > > That is what is set in the example and the reason why I set minItems to 3 > > > in the main bindings. > > > Then, the rk3588 specific part sets it to 4. > > > > > > Isn't that enough ? > > > > Not quite - you need to restrict maxItems to 3 for the other devices if > > the clocks are not valid. What you've got says that 4 clocks are > > possible but not needed on !rk3588. > > > I don't understand what "properties: resets: minItems: 3" means then. I > thought it means that all devices should have at least 3 resets. Then the > allOf below specifies the special case of rk3588 which has a minimum of 4 > resets. The change you made to the bindings allows someone to define either 3 (because of minItems 3) or 4 (because there are 4 items in the list) resets for the rk3568. > Do I need to add > resets: > minItems: 3 > reset-names: > minItems: 3 > in the "else:" ? No, you need to add maxItems: 3 to the else. > So in that case, I can remove "properties: resets: minItems: 3" above ? > > Also, what do you mean "If the clocks are not valid" ? s/clocks/resets/ ;) signature.asc Description: PGP signature
Re: [PATCH 3/3] dt-bindings: display: vop2: Add VP clock resets
On Tue, May 21, 2024 at 01:15:46PM -0400, Detlev Casanova wrote: > On Wednesday, May 15, 2024 12:33:22 P.M. EDT Heiko Stübner wrote: > > Am Mittwoch, 15. Mai 2024, 18:19:29 CEST schrieb Conor Dooley: > > > On Tue, May 14, 2024 at 11:19:47AM -0400, Detlev Casanova wrote: > > > > Add the documentation for VOP2 video ports reset clocks. > > > > One reset can be set per video port. > > > > > > > > Signed-off-by: Detlev Casanova > > > > > > Are these resets valid for all VOPs or just the one on 3588? > > > > Not in that form. > > I.e. rk3588 has 4 video-ports (0-3), while rk3568 has 3 (0-2). > > > > So the binding should take into account that rk3568 also has the > > SRST_VOP0 ... SRST_VOP2. > > That is what is set in the example and the reason why I set minItems to 3 in > the main bindings. > Then, the rk3588 specific part sets it to 4. > > Isn't that enough ? Not quite - you need to restrict maxItems to 3 for the other devices if the clocks are not valid. What you've got says that 4 clocks are possible but not needed on !rk3588. Cheers, Conor. signature.asc Description: PGP signature
Re: [PATCH v2] dt-bindings: display: synopsys,dw-hdmi: Document ddc-i2c-bus in core
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. Acked-by: Conor Dooley Cheers, Conor. signature.asc Description: PGP signature
Re: [PATCH 3/3] dt-bindings: display: vop2: Add VP clock resets
On Tue, May 14, 2024 at 11:19:47AM -0400, Detlev Casanova wrote:
> Add the documentation for VOP2 video ports reset clocks.
> One reset can be set per video port.
>
> Signed-off-by: Detlev Casanova
Are these resets valid for all VOPs or just the one on 3588?
> ---
> .../display/rockchip/rockchip-vop2.yaml | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
> b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
> index 2531726af306b..941fd059498d4 100644
> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
> @@ -65,6 +65,22 @@ properties:
>- const: dclk_vp3
>- const: pclk_vop
>
> + resets:
> +minItems: 3
> +items:
> + - description: Pixel clock reset for video port 0.
> + - description: Pixel clock reset for video port 1.
> + - description: Pixel clock reset for video port 2.
> + - description: Pixel clock reset for video port 3.
> +
> + reset-names:
> +minItems: 3
> +items:
> + - const: dclk_vp0
> + - const: dclk_vp1
> + - const: dclk_vp2
> + - const: dclk_vp3
> +
>rockchip,grf:
> $ref: /schemas/types.yaml#/definitions/phandle
> description:
> @@ -128,6 +144,11 @@ allOf:
> clock-names:
>minItems: 7
>
> +resets:
> + minItems: 4
> +reset-names:
> + minItems: 4
> +
> ports:
>required:
> - port@0
> @@ -183,6 +204,12 @@ examples:
>"dclk_vp0",
>"dclk_vp1",
>"dclk_vp2";
> +resets = < SRST_VOP0>,
> + < SRST_VOP1>,
> + < SRST_VOP2>;
> +reset-names = "dclk_vp0",
> + "dclk_vp1",
> + "dclk_vp2";
> power-domains = < RK3568_PD_VO>;
> iommus = <_mmu>;
> vop_out: ports {
> --
> 2.43.2
>
signature.asc
Description: PGP signature
Re: [PATCH v2 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
On Mon, May 13, 2024 at 03:44:00PM +0200, AngeloGioacchino Del Regno wrote: > Il 13/05/24 08:15, CK Hu (胡俊光) ha scritto: > > On Fri, 2024-05-10 at 12:14 +0200, AngeloGioacchino Del Regno wrote: > > > Il 10/05/24 11:34, CK Hu (胡俊光) ha scritto: > > > > On Thu, 2024-05-09 at 11:27 +0200, AngeloGioacchino Del Regno > > > > wrote: > > > > > Il 09/05/24 07:42, CK Hu (胡俊光) ha scritto: > > > > > > On Wed, 2024-05-08 at 15:03 +0200, AngeloGioacchino Del Regno > > > > > > wrote: > > > > > > > Il 08/05/24 09:19, CK Hu (胡俊光) ha scritto: > > > > > > > > On Tue, 2024-05-07 at 16:07 +0200, AngeloGioacchino Del > > > > > > > > Regno > > > > > > > > wrote: > > > > > > > > > Il 07/05/24 08:59, CK Hu (胡俊光) ha scritto: > > > > > > > > > > On Thu, 2024-05-02 at 10:50 +0200, AngeloGioacchino Del > > > > > > > > > > Regno > > > > > > > > > > wrote: > > > > > > > > > > > Il 25/04/24 04:23, CK Hu (胡俊光) ha scritto: > > > > > > > > > > > > Hi, Angelo: > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 2024-04-09 at 14:02 +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 < > > > > > > > > > > > > > angelogioacchino.delre...@collabora.com> One of you guys, probably 胡俊光, has a mail client that is completely mangling these quotes. Can you try to fix that please? It makes reading the thread unfun :/ signature.asc Description: PGP signature
Re: [PATCH 1/3] dt-bindings: display: samsung,ams495qa01: add missing SPI properties ref
On Thu, May 09, 2024 at 11:42:51AM +0200, Krzysztof Kozlowski wrote:
> Samsung AMS495QA01 panel is a SPI device, so it should reference
> spi-peripheral-props.yaml schema to allow and validate the SPI device
> properties.
>
> Fixes: 92be07c65b22 ("dt-bindings: display: panel: Add Samsung AMS495QA01")
> Signed-off-by: Krzysztof Kozlowski
Acked-by: Conor Dooley
Cheers,
Conor.
signature.asc
Description: PGP signature
Re: [PATCH 2/3] dt-bindings: display: panel: constrain 'reg' in SPI panels
On Thu, May 09, 2024 at 11:42:52AM +0200, Krzysztof Kozlowski wrote: > SPI-attached devices could have more than one chip-select, thus their > bindings are supposed to constrain the 'reg' property to match hardware. > Add missing 'reg' constrain for SPI-attached display panels. > > Signed-off-by: Krzysztof Kozlowski Acked-by: Conor Dooley Cheers, Conor. signature.asc Description: PGP signature
Re: [PATCH 3/3] dt-bindings: display: panel: constrain 'reg' in DSI panels
On Thu, May 09, 2024 at 11:42:53AM +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). > > Signed-off-by: Krzysztof Kozlowski Acked-by: Conor Dooley Thanks, Conor. signature.asc Description: PGP signature
Re: [PATCH v5 1/7] dt-bindings: display: panel: Add himax hx83102 panel bindings
On Thu, May 09, 2024 at 09:52:01AM +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 Reviewed-by: Conor Dooley Cheers, Conor. signature.asc Description: PGP signature
Re: [PATCH 1/7] dt-bindings: display: rockchip, dw-mipi-dsi: Document RK3128 DSI
On Mon, May 06, 2024 at 09:43:36PM +0200, Alex Bee wrote: > Document the MIPI DSI controller for Rockchip RK3128. The integration is > similar to PX30 so it's bindings-constraints can be re-used. > > Signed-off-by: Alex Bee Acked-by: Conor Dooley Cheers, Conor. signature.asc Description: PGP signature
Re: [PATCH 2/7] dt-bindings: clock: rk3128: Add PCLK_MIPIPHY
On Mon, May 06, 2024 at 09:43:37PM +0200, Alex Bee wrote: > The DPHY's APB clock is required to be exposed in order to be able to > enable it and access the phy's registers. > > Signed-off-by: Alex Bee Acked-by: Conor Dooley signature.asc Description: PGP signature
Re: [PATCH v4 1/7] dt-bindings: display: panel: Add himax hx83102 panel bindings
On Tue, May 07, 2024 at 09:52:28PM +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 Other than the issue Rob's bot reported, this looks fine to me. Thanks for the updates - but please test your bindings! Conor. signature.asc Description: PGP signature
Re: [PATCH v4 6/7] dt-bindings: display: panel: Add compatible for IVO t109nw41
On Tue, May 07, 2024 at 09:52:33PM +0800, Cong Yang wrote: > The IVO t109nw41 is a 11.0" WUXGA TFT LCD panel with himax-hx83102 > controller. Hence, we add a new compatible with panel specific config. > > Signed-off-by: Cong Yang Acked-by: Conor Dooley Cheers, Conor. > --- > Chage since V4: > > - No change. > > V3: > https://lore.kernel.org/all/20240424023010.2099949-7-yangco...@huaqin.corp-partner.google.com > > Chage since V3: > > - Update commit message. > > V2: > https://lore.kernel.org/all/20240422090310.3311429-7-yangco...@huaqin.corp-partner.google.com/ > > --- > .../devicetree/bindings/display/panel/himax,hx83102.yaml| 2 ++ > 1 file changed, 2 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml > b/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml > index 53a6ace75ada..f65b47cad0d4 100644 > --- a/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml > +++ b/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml > @@ -18,6 +18,8 @@ properties: >- enum: ># Boe nv110wum-l60 11.0" WUXGA TFT LCD panel >- boe,nv110wum-l60 > + # IVO t109nw41 11.0" WUXGA TFT LCD panel > + - ivo,t109nw41 ># STARRY himax83102-j02 10.51" WUXGA TFT LCD panel >- starry,himax83102-j02 >- const: himax,hx83102 > -- > 2.25.1 > signature.asc Description: PGP signature
Re: [PATCH v4 4/7] dt-bindings: display: panel: Add compatible for BOE nv110wum-l60
On Tue, May 07, 2024 at 09:52:31PM +0800, Cong Yang wrote: > The BOE nv110wum-l60 is a 11.0" WUXGA TFT LCD panel with himax-hx83102 > controller. Hence, we add a new compatible with panel specific config. > > Signed-off-by: Cong Yang Acked-by: Conor Dooley Cheers, Conor. > --- > Chage since V4: > > - No change. > > V3: > https://lore.kernel.org/all/20240424023010.2099949-5-yangco...@huaqin.corp-partner.google.com > > Chage since V3: > > - Update commit message. > > V2: > https://lore.kernel.org/all/20240422090310.3311429-5-yangco...@huaqin.corp-partner.google.com > > --- > .../devicetree/bindings/display/panel/himax,hx83102.yaml| 2 ++ > 1 file changed, 2 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml > b/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml > index 7cd720eb4981..53a6ace75ada 100644 > --- a/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml > +++ b/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml > @@ -16,6 +16,8 @@ properties: >compatible: > items: >- enum: > + # Boe nv110wum-l60 11.0" WUXGA TFT LCD panel > + - boe,nv110wum-l60 ># STARRY himax83102-j02 10.51" WUXGA TFT LCD panel >- starry,himax83102-j02 >- const: himax,hx83102 > -- > 2.25.1 > signature.asc Description: PGP signature
Re: [PATCH 1/2] dt-bindings: drm/bridge: anx7625: Add a perporty to change TDM setting
On Fri, May 03, 2024 at 02:58:16PM +0800, Hsin-Te Yuan wrote: > On Thu, May 2, 2024 at 10:47 PM Conor Dooley wrote: > > > > On Thu, May 02, 2024 at 09:03:31AM +, Hsin-Te Yuan wrote: > > > Add a perporty to indicate whether anx7625 should shift the first audio > > > data bit. The default TDM setting is to shift the first audio data bit. > > > > > > Signed-off-by: Hsin-Te Yuan > > > --- > > > .../devicetree/bindings/display/bridge/analogix,anx7625.yaml | > > > 4 > > > 1 file changed, 4 insertions(+) > > > > > > diff --git > > > a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml > > > b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml > > > index a1ed1004651b9..915d5d54a2160 100644 > > > --- > > > a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml > > > +++ > > > b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml > > > @@ -82,6 +82,10 @@ properties: > > > type: boolean > > > description: let the driver enable audio HDMI codec function or not. > > > > > > + no-shift-audio-data: > > > +type: boolean > > > +description: Disable the first audio data bit shift in the TDM > > > settings. > > > > This just looks like software policy, since there's no mention in the > > commit message or description as to what property of the hardware causes > > this to be required. Can you please explain why this property is needed? > > > > You're also missing a vendor prefix. > > Sorry, I found this feature in the datasheet originally, but after > deeper investigation, it seems that this feature should be used to > support i2s dsp mode b instead of being used this way. Note that the > difference between i2s dsp mode a and b is whether or not to shift the > audio data by 1 clock cycle. Are you trying to say that this patch is not needed? I'm not really sure. signature.asc Description: PGP signature
Re: [PATCH 1/2] dt-bindings: drm/bridge: anx7625: Add a perporty to change TDM setting
On Thu, May 02, 2024 at 09:03:31AM +, Hsin-Te Yuan wrote: > Add a perporty to indicate whether anx7625 should shift the first audio > data bit. The default TDM setting is to shift the first audio data bit. > > Signed-off-by: Hsin-Te Yuan > --- > .../devicetree/bindings/display/bridge/analogix,anx7625.yaml | 4 > > 1 file changed, 4 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml > b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml > index a1ed1004651b9..915d5d54a2160 100644 > --- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml > +++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml > @@ -82,6 +82,10 @@ properties: > type: boolean > description: let the driver enable audio HDMI codec function or not. > > + no-shift-audio-data: > +type: boolean > +description: Disable the first audio data bit shift in the TDM settings. This just looks like software policy, since there's no mention in the commit message or description as to what property of the hardware causes this to be required. Can you please explain why this property is needed? You're also missing a vendor prefix. Thanks, Conor. > + >aux-bus: > $ref: /schemas/display/dp-aux-bus.yaml# > > > -- > 2.45.0.rc1.225.g2a3ae87e7f-goog > signature.asc Description: PGP signature
Re: [PATCH v3 1/7] dt-bindings: display: panel: Add himax hx83102 panel bindings
On Thu, Apr 25, 2024 at 02:03:24PM +0800, cong yang wrote: > Conor Dooley 于2024年4月25日周四 00:55写道： > > On Wed, Apr 24, 2024 at 10:30:04AM +0800, Cong Yang wrote: > > > +++ b/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml > > > > Filename matching a compatible please. What you've done here makes it > > seem like there's a fallback compatible missing, given this looks like > > the LCD panel controller and the starry compatible below is an LCD panel. > > So change the filename to starry,himax83102-j02.yaml? IDK chief, are you missing a fallback or not? > > > > > > @@ -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 Because the title here makes it seem like there should be. > > > +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 > > > > I'm not sure why this was given a description when port or rotation > > was not. > > So change it to backlight: true ? Sure? It is just a repeat of something already described in panel-common. signature.asc Description: PGP signature
Re: [PATCH v3 1/7] dt-bindings: display: panel: Add himax hx83102 panel bindings
On Wed, Apr 24, 2024 at 10:30:04AM +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.
It'd be good to note in the commit message that the 3v3 supply is not
present on these panels, given it was present in the other binding and
not here.
> [1]:
> https://lore.kernel.org/all/CACRpkdbzYZAS0=zbqjuc4cb2wj4s1h6n6asazqvdmv95r3z...@mail.gmail.com
>
> Signed-off-by: Cong Yang
> ---
> 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
>
> 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
Filename matching a compatible please. What you've done here makes it
seem like there's a fallback compatible missing, given this looks like
the LCD panel controller and the starry compatible below is an LCD panel.
> @@ -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
I'm not sure why this was given a description when port or rotation
was not.
Otherwise, this looks fine to me.
Cheers,
Conor.
> +
> + port: true
> + rotation: true
> +
> +required:
> + - compatible
> + - reg
> + - enable-gpios
> + - pp1800-supply
> + - avdd-supply
> + - avee-supply
> +
> +additionalProperties: false
> +
> +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
>
signature.asc
Description: PGP signature
Re: [PATCH v4 0/7] Managing live video input format for ZynqMP DPSUB
On Tue, Apr 16, 2024 at 01:31:35PM -0700, Anatoliy Klymenko wrote: > Implement live video input format setting for ZynqMP DPSUB. > To: Conor Dooley If there's nothing dt related here anymore, you can drop me :) signature.asc Description: PGP signature
Re: [PATCH v2] ARM: dts: bcm2835: Enable 3D rendering through V3D
On Tue, Apr 16, 2024 at 07:13:51AM -0300, Maíra Canal wrote: > On 4/16/24 02:30, Stefan Wahren wrote: > > Hi Maíra, > > > > Am 16.04.24 um 03:02 schrieb Maíra Canal: > > > On 4/15/24 13:54, Andre Przywara wrote: > > > > On Mon, 15 Apr 2024 13:00:39 -0300 > > > > Maíra Canal wrote: > > > > > > > > Hi, > > > > > > > > > RPi 0-3 is packed with a GPU that provides 3D rendering capabilities > > > > > to > > > > > the RPi. Currently, the downstream kernel uses an overlay to enable > > > > > the > > > > > GPU and use GPU hardware acceleration. When deploying a mainline > > > > > kernel > > > > > to the RPi 0-3, we end up without any GPU hardware acceleration > > > > > (essentially, we can't use the OpenGL driver). > > > > > > > > > > Therefore, enable the V3D core for the RPi 0-3 in the mainline kernel. > > > > > > > > So I think Krzysztof's initial comment still stands: What does that > > > > patch > > > > actually change? If I build those DTBs as of now, none of them has a > > > > status property in the v3d node. Which means it's enabled: > > > > https://github.com/devicetree-org/devicetree-specification/blob/main/source/chapter2-devicetree-basics.rst#status > > > > > > > > So adding an explicit 'status = "okay";' doesn't make a difference. > > > > > > > > What do I miss here? > > > > > > As mentioned by Stefan in the last version, in Raspberry Pi OS, there is > > > a systemd script which is trying to check for the V3D driver (/usr/lib > > > /systemd/scripts/gldriver_test.sh). Within the first check, "raspi- > > > config nonint is_kms" is called, which always seems to fail. What > > > "raspi-config" does is check if > > > /proc/device-tree/soc/v3d@7ec0/status is equal to "okay". As > > > /proc/device-tree/soc/v3d@7ec0/status doesn't exists, it returns > > > false. > > yes, but i also mention that the V3D driver starts without this patch. > > The commit message of this patch suggests this is a DT issue, which is not. > > > > I hadn't the time to update my SD card to Bookworm yet. Does the issue > > still exists with this version? > > I'm using a 32-bit kernel and the recommended OS for 32-bit is Bullseye. > But I checked the Bookworm code and indeed, Bookworm doesn't check > the device tree [1]. > > I'm thinking about sending a patch to the Bullseye branch to fix this > issue. I think you should, sounds like they're making invalid assumptions about the status property. signature.asc Description: PGP signature
Re: [PATCH v2 1/2] dt-bindings: display: panel: Add Raydium RM69380
On Mon, Apr 15, 2024 at 06:10:41PM +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(+)
>
> 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
> +
> +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
Where is reg defined? I briefly checked the two panel-common bindings
and didn't see it.
Cheers,
Conor.
> +
> +required:
> + - compatible
> + - reg
> + - avdd-supply
> + - vddio-supply
> + - reset-gpios
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +
> +dsi {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +panel@0 {
> +compatible = "lenovo,j716f-edo-rm69380", "raydium,rm69380";
> +reg = <0>;
> +
> +avdd-supply = <_avdd_regulator>;
> +vddio-supply = <_l14a>;
> +reset-gpios = < 75 GPIO_ACTIVE_LOW>;
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +reg = <0>;
> +panel_in_0: endpoint {
> +remote-endpoint = <_dsi0_out>;
> +};
> +};
> +
> +port@1 {
> +reg = <1>;
> +panel_in_1: endpoint {
> +remote-endpoint = <_dsi1_out>;
> +};
> +};
> +};
> +};
> +};
> +
> +...
>
> --
> 2.44.0
>
signature.asc
Description: PGP signature
Re: [PATCH v1 1/3] dt-bindings: display: add #sound-dai-cells property to rockchip dw hdmi
On Sat, Apr 13, 2024 at 05:38:05PM +0200, Johan Jonker wrote: > The Rockchip DWC HDMI TX Encoder can take one I2S input and transmit it > over the HDMI output. Add #sound-dai-cells (= 0) to the binding for it. > > Signed-off-by: Johan Jonker Please send cover letters for multi-patch series, for all 3: Acked-by: Conor Dooley Chees, Conor. signature.asc Description: PGP signature
Re: [PATCH 2/2] dt-bindings: display: bridge: lt8912b: document 'lontium,pn-swap' property
On Wed, Apr 03, 2024 at 09:16:31AM +0300, Alexandru Ardelean wrote: > > > > > +type: boolean > > > > The type here should be flag. > > ack; i'll change the type I prob shoulda said, its "$ref: /schemas/types.yaml#/definitions/flag" instead of "type: boolean". signature.asc Description: PGP signature
Re: [PATCH 2/2] dt-bindings: display: bridge: lt8912b: document 'lontium,pn-swap' property
On Tue, Apr 02, 2024 at 01:59:25PM +0300, Alexandru Ardelean wrote: > On some HW designs, it's easier for the layout if the P/N pins are swapped. > The driver currently has a DT property to do that. "currently", because 1/2 adds it. bindings patches should precede the driver patches in the series, so please swap the patches and remove this portion of the description. > > This change documents the 'lontium,pn-swap' property. > > Signed-off-by: Alexandru Ardelean > --- > .../devicetree/bindings/display/bridge/lontium,lt8912b.yaml | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml > b/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml > index 2cef252157985..3a804926b288a 100644 > --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml > +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml > @@ -24,6 +24,12 @@ properties: > maxItems: 1 > description: GPIO connected to active high RESET pin. > > + lontium,pn-swap: > +description: Swap the polarities of the P/N pins in software. > + On some HW designs, the layout is simplified if the P/N pins > + are inverted. Please explain what configuration of a board would cause these to be swapped, rather than why someone might want to configure the board this way. I've got no idea what this hardware is actually doing, so this is being pulled out of a hat, but I'd expect something like "Some boards swap the polarity of the P/N pins, use this property to indicate this to software". > +type: boolean The type here should be flag. Cheers, Conor. > + >ports: > $ref: /schemas/graph.yaml#/properties/ports > > -- > 2.44.0 > signature.asc Description: PGP signature
Re: [PATCH v3 8/9] dt-bindings: xlnx: Add VTC and TPG bindings
On Fri, Mar 29, 2024 at 12:38:33AM +, Klymenko, Anatoliy wrote: > Thank you for the feedback. > > From: Krzysztof Kozlowski > > Subject: Re: [PATCH v3 8/9] dt-bindings: xlnx: Add VTC and TPG bindings > > On 22/03/2024 20:12, Klymenko, Anatoliy wrote: > > >> From: Krzysztof Kozlowski > > >> On 21/03/2024 21:43, Anatoliy Klymenko wrote: > > >>> diff --git a/include/dt-bindings/media/media-bus-format.h > > >>> b/include/dt- > > >> bindings/media/media-bus-format.h > > >>> new file mode 100644 > > >>> index ..60fc6e11dabc > > >>> --- /dev/null > > >>> +++ b/include/dt-bindings/media/media-bus-format.h > > >>> @@ -0,0 +1,177 @@ > > >>> +/* SPDX-License-Identifier: (GPL-2.0-only OR MIT) */ > > >>> +/* > > >>> + * Media Bus API header > > >>> + * > > >>> + * Copyright (C) 2009, Guennadi Liakhovetski > > >>> + > > >>> + * > > >>> + * This program is free software; you can redistribute it and/or > > >>> +modify > > >>> + * it under the terms of the GNU General Public License version 2 > > >>> +as > > >>> + * published by the Free Software Foundation. > > >> > > >> That's not true. Your SPDX tells something entirely different. > > >> > > > > > > Thank you - I'll see how to fix it. > > > > > >> Anyway, you did not explain why you need to copy anything anywhere. > > >> > > >> Specifically, random hex values *are not bindings*. > > >> > > > > > > The same media bus format values are being used by the reference > > > driver in patch #9. And, as far as I know, we cannot use headers from > > > Linux API headers directly (at least I > > > > I don't understand what does it mean. You can use in your driver whatever > > headers you wish, I don't care about them. > > > > > > noticed the same pattern in ../dt-bindings/sdtv-standarts.h for instance). > > What would be the best approach to reusing the same defines on DT and > > driver sides from your point of view? Symlink maybe? > > > > > > > Wrap your messages to match mailing list discussion style. There are no > > defines used in DT. If there are, show me them in *THIS* or other > > *upstreamed* (being upstreamed) patchset. > > > > Sorry, I didn't explain properly what I'm trying to achieve. I need to > create a DT node property that represents video signal format, one of > MEDIA_BUS_FMT_* from include/uapi/linux/media-bus-format.h. It would be > nice to reuse the same symbolic values in the device tree. What is the > best approach here? Should I create a separate header in > include/dt-bindings with the same or similar (to avoid multiple > definition errors) defines, or is it better to create a symlink to > media-bus-format.h like include/dt-bindings/linux-event-codes.h? Isn't there already a property for this, described in Documentation/devicetree/bindings/media/xilinx/video.txt ? signature.asc Description: PGP signature
Re: [PATCH 1/4] dt-bindings: display: simple: Document support for Innolux G121XCE-L01
On Thu, Mar 28, 2024 at 11:27:35AM +0100, Marek Vasut wrote: > Document support for Innolux CheMei 12" G121XCE-L01 XGA LVDS display. > > G121XCE-L01 is a Color Active Matrix Liquid Crystal Display composed of > a TFT LCD panel, a driver circuit, and LED backlight system. The screen > format is intended to support the 4:3, 1024(H) x 768(V) screen and either > 262k/16.7M colors (RGB 6-bits or 8-bits) with LED backlight driver circuit. > All input signals are LVDS interface compatible. > > Documentation [1] and [2] indicate that G121X1-L03 and G121XCE-L01 are > effectively identical panels, use the former as RGB 6-bits variant and > document the later as RGB 8-bits variant. > > [1] > https://www.distec.de/fileadmin/pdf/produkte/TFT-Displays/Innolux/G121X1-L03_Datasheet.pdf > [2] > https://www.distec.de/fileadmin/pdf/produkte/TFT-Displays/Innolux/G121XCE-L01_Datasheet.pdf > > Signed-off-by: Marek Vasut > --- > Cc: Conor Dooley Acked-by: Conor Dooley Thanks, Conor. > Cc: Daniel Vetter > Cc: David Airlie > Cc: Jessica Zhang > Cc: Krzysztof Kozlowski > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Neil Armstrong > Cc: Rob Herring > Cc: Sam Ravnborg > Cc: Thierry Reding > Cc: Thomas Zimmermann > Cc: devicet...@vger.kernel.org > Cc: dri-devel@lists.freedesktop.org > --- > .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > index e0f6aa9a025c4..931d98836e121 100644 > --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > @@ -190,6 +190,8 @@ properties: >- innolux,g121i1-l01 > # Innolux Corporation 12.1" G121X1-L03 XGA (1024x768) TFT LCD panel >- innolux,g121x1-l03 > +# Innolux Corporation 12.1" G121XCE-L01 XGA (1024x768) TFT LCD panel > + - innolux,g121xce-l01 > # Innolux Corporation 11.6" WXGA (1366x768) TFT LCD panel >- innolux,n116bca-ea1 > # Innolux Corporation 11.6" WXGA (1366x768) TFT LCD panel > -- > 2.43.0 > signature.asc Description: PGP signature
Re: [PATCH 4/5] dt-bindings: arm: rockchip: Add GameForce Chi
On Mon, Mar 25, 2024 at 08:49:58AM -0500, Chris Morgan wrote: > From: Chris Morgan > > The GameForce Chi is a handheld gaming device from GameForce powered > by the Rockchip RK3326 SoC. > > Signed-off-by: Chris Morgan Acked-by: Conor Dooley signature.asc Description: PGP signature
Re: [PATCH v3 8/9] dt-bindings: xlnx: Add VTC and TPG bindings
On Sat, Mar 23, 2024 at 11:22:22AM +0100, Krzysztof Kozlowski wrote: > On 22/03/2024 19:05, Conor Dooley wrote: > > On Fri, Mar 22, 2024 at 06:59:18AM +0100, Krzysztof Kozlowski wrote: > >> On 21/03/2024 21:43, Anatoliy Klymenko wrote: > >>> diff --git a/include/dt-bindings/media/media-bus-format.h > >>> b/include/dt-bindings/media/media-bus-format.h > >>> new file mode 100644 > >>> index ..60fc6e11dabc > >>> --- /dev/null > >>> +++ b/include/dt-bindings/media/media-bus-format.h > >>> @@ -0,0 +1,177 @@ > >>> +/* SPDX-License-Identifier: (GPL-2.0-only OR MIT) */ > >>> +/* > >>> + * Media Bus API header > >>> + * > >>> + * Copyright (C) 2009, Guennadi Liakhovetski > >>> + * > >>> + * This program is free software; you can redistribute it and/or modify > >>> + * it under the terms of the GNU General Public License version 2 as > >>> + * published by the Free Software Foundation. > >> > >> That's not true. Your SPDX tells something entirely different. > >> > >> Anyway, you did not explain why you need to copy anything anywhere. > > > > I assume by "copy anything anywhere" you mean "why did you copy a linux > > uapi header into the bindings? > > Yes, I trimmed context too much. > > The reasoning of copying some UAPI and claiming it is a binding was: > "Copy media-bus-formats.h into dt-bindings/media to suplement TPG DT node." > so as seen *there is no reason*. > > Commit msg should explain why we are doing things. Oh for sure. I was just wondering if you were complaining about the UAPI header or if that comment was about the copyright notice. If it had been the latter I was gonna point out the former :) signature.asc Description: PGP signature
Re: [PATCH v3 8/9] dt-bindings: xlnx: Add VTC and TPG bindings
On Fri, Mar 22, 2024 at 06:59:18AM +0100, Krzysztof Kozlowski wrote: > On 21/03/2024 21:43, Anatoliy Klymenko wrote: > > diff --git a/include/dt-bindings/media/media-bus-format.h > > b/include/dt-bindings/media/media-bus-format.h > > new file mode 100644 > > index ..60fc6e11dabc > > --- /dev/null > > +++ b/include/dt-bindings/media/media-bus-format.h > > @@ -0,0 +1,177 @@ > > +/* SPDX-License-Identifier: (GPL-2.0-only OR MIT) */ > > +/* > > + * Media Bus API header > > + * > > + * Copyright (C) 2009, Guennadi Liakhovetski > > + * > > + * This program is free software; you can redistribute it and/or modify > > + * it under the terms of the GNU General Public License version 2 as > > + * published by the Free Software Foundation. > > That's not true. Your SPDX tells something entirely different. > > Anyway, you did not explain why you need to copy anything anywhere. I assume by "copy anything anywhere" you mean "why did you copy a linux uapi header into the bindings? > Specifically, random hex values *are not bindings*. > > Best regards, > Krzysztof > signature.asc Description: PGP signature
Re: [PATCH v2] dt-bindings: display: samsung,exynos5-dp: convert to DT Schema
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 ? Otherwise, Reviewed-by: Conor Dooley Thanks, Conor. signature.asc Description: PGP signature
Re: [PATCH v2 0/3] panel-simple: add support for Crystal Clear CMT430B19N00
On Tue, Mar 05, 2024 at 10:48:56AM +0100, Jérémie Dautheribes wrote: > Hi Conor, > > On 04/03/2024 20:29, 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. > > > Oops you are right, I'm sorry. Should I send a v3 containing these acks? I was going to just provide them here, I just wanted to make sure you didn't intentionally drop them first. But in the interim you got some from Krzysztof, making some from me redundant anyway :) I wouldn't bother adding the forgotten acks or resending, I don't care about my ack count :) signature.asc Description: PGP signature
Re: [PATCH v2 0/3] panel-simple: add support for Crystal Clear CMT430B19N00
On Mon, Mar 04, 2024 at 03:24:51PM -0600, Rob Herring wrote: > On Mon, Mar 04, 2024 at 07:29:04PM +0000, 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 > This is the other nice thing that b4 does, pick up "non review" trailers too. > 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 > signature.asc Description: PGP signature
Re: [PATCH v2 0/3] panel-simple: add support for Crystal Clear CMT430B19N00
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. signature.asc Description: PGP signature
Re: [PATCH 1/3] dt-bindings: Add Crystal Clear Technology vendor prefix
On Thu, Feb 29, 2024 at 09:54:59AM +0100, Neil Armstrong wrote: > Hi Jérémie, > > On 23/02/2024 19:22, Conor Dooley wrote: > > On Fri, Feb 23, 2024 at 02:45:15PM +0100, Jérémie Dautheribes wrote: > > > Update Documentation/devicetree/bindings/vendor-prefixes.yaml to > > > include "cct" as a vendor prefix for "Crystal Clear Technology". CCT is > > > the vendor of the CMT430B19N00 TFT-LCD panel. > > > > > > > Acked-by: Conor Dooley > > > > And add a > > Link: http://www.cct.com.my/ > > as that actually explains why "cct" is the right choice. > > Can you send a v2 with this change ? Does your workflow not allow you to pick up Link: tags while applying patches? signature.asc Description: PGP signature
Re: [PATCH v2 0/9] Add Chameleon v3 video support
Hey, On Wed, Feb 21, 2024 at 04:02:06PM +, Paweł Anikiel wrote: > media: dt-bindings: Add Chameleon v3 framebuffer > media: dt-bindings: Add Intel Displayport RX IP I'm happy with both of these patches, but I would like others to look, so I'll hold off leaving R-b tags until someone else has at least looked. Cheers, Conor. signature.asc Description: PGP signature
Re: [PATCH 2/3] dt-bindings: display: simple: add support for Crystal Clear CMT430B19N00
On Fri, Feb 23, 2024 at 02:45:16PM +0100, Jérémie Dautheribes wrote: > Add Crystal Clear Technology CMT430B19N00 4.3" 480x272 TFT-LCD panel > compatible string. > > Signed-off-by: Jérémie Dautheribes Acked-by: Conor Dooley Cheers, Conor. > --- > .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > index a95445f40870..c575f7c4b745 100644 > --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > @@ -91,6 +91,8 @@ properties: >- boe,nv133fhm-n62 > # BOE NV140FHM-N49 14.0" FHD a-Si FT panel >- boe,nv140fhmn49 > +# Crystal Clear Technology CMT430B19N00 4.3" 480x272 TFT-LCD panel > + - cct,cmt430b19n00 > # CDTech(H.K.) Electronics Limited 4.3" 480x272 color TFT-LCD panel >- cdtech,s043wq26h-ct7 > # CDTech(H.K.) Electronics Limited 7" WSVGA (1024x600) TFT LCD Panel > -- > 2.34.1 > signature.asc Description: PGP signature
Re: [PATCH 1/3] dt-bindings: Add Crystal Clear Technology vendor prefix
On Fri, Feb 23, 2024 at 02:45:15PM +0100, Jérémie Dautheribes wrote: > Update Documentation/devicetree/bindings/vendor-prefixes.yaml to > include "cct" as a vendor prefix for "Crystal Clear Technology". CCT is > the vendor of the CMT430B19N00 TFT-LCD panel. > Acked-by: Conor Dooley And add a Link: http://www.cct.com.my/ as that actually explains why "cct" is the right choice. Cheers, Conor. > Signed-off-by: Jérémie Dautheribes > --- > 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 fef2e12b504e..96e47742e250 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml > +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml > @@ -248,6 +248,8 @@ patternProperties: > description: Catalyst Semiconductor, Inc. >"^cavium,.*": > description: Cavium, Inc. > + "^cct,.*": > +description: Crystal Clear Technology Sdn. Bhd. >"^cdns,.*": > description: Cadence Design Systems Inc. >"^cdtech,.*": > -- > 2.34.1 > signature.asc Description: PGP signature
Re: [PATCH 7/9] media: dt-bindings: Add Chameleon v3 framebuffer
On Mon, Feb 12, 2024 at 01:13:21PM +, Paweł Anikiel wrote:
> The Chameleon v3 uses the framebuffer IP core to take the video signal
> from different sources and directly write frames into memory.
>
> Signed-off-by: Paweł Anikiel
> ---
> .../bindings/media/google,chv3-fb.yaml| 77 +++
> 1 file changed, 77 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/media/google,chv3-fb.yaml
>
> diff --git a/Documentation/devicetree/bindings/media/google,chv3-fb.yaml
> b/Documentation/devicetree/bindings/media/google,chv3-fb.yaml
> new file mode 100644
> index ..ba6643cc7232
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/google,chv3-fb.yaml
> @@ -0,0 +1,77 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/google,chv3-fb.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Google Chameleon v3 video framebuffer
> +
> +maintainers:
> + - Paweł Anikiel
> +
> +properties:
> + compatible:
> +const: google,chv3-fb
> +
> + reg:
> +items:
> + - description: core registers
> + - description: irq registers
> +
> + interrupts:
> +maxItems: 1
> +
> + google,legacy-format:
> +type: boolean
> +description: The incoming video stream is in 32-bit padded mode.
> +
> + google,no-endpoint:
> +type: boolean
> +description:
> + The framebuffer isn't connected to a controllable endpoint.
> + The video interface still works, but EDID control is unavailable
> + and DV timing information only reports the active video width/height.
Why does this need a dedicated property? Is it not sufficient to check
that there are no endpoints in the devicetree?
Cheers,
Conor.
> +
> + port:
> +$ref: /schemas/graph.yaml#/properties/port
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> +
> +allOf:
> + - if:
> + not:
> +required:
> + - google,no-endpoint
> +then:
> + required:
> +- port
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +video@c0060500 {
> +compatible = "google,chv3-fb";
> +reg = <0xc0060500 0x100>,
> + <0xc0060f20 0x10>;
> +interrupts = ;
> +google,legacy-format;
> +google,no-endpoint;
> +};
> +
> + - |
> +video@c0060600 {
> +compatible = "google,chv3-fb";
> +reg = <0xc0060600 0x100>,
> + <0xc0060f30 0x10>;
> +interrupts = ;
> +
> +port {
> +fb_mst0_0: endpoint {
> +remote-endpoint = <_mst_0>;
> +};
> +};
> +};
> --
> 2.43.0.687.g38aa6559b0-goog
>
signature.asc
Description: PGP signature
Re: [PATCH 8/9] media: dt-bindings: Add Intel Displayport RX IP
Yo,
On Mon, Feb 12, 2024 at 01:13:22PM +, Paweł Anikiel wrote:
> 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 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 | 125 ++
> 1 file changed, 125 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 ..3ed37e0a4a94
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/intel,dprx.yaml
> @@ -0,0 +1,125 @@
> +# 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
> +
> +properties:
> + compatible:
> +const: intel,dprx
Please version this compatible, given that is it for an FPGA IP.
I could not find an example of another intel IP that had versioning, but
there's plenty of xilinx stuff you can get inspiration from.
> + reg:
> +items:
> + - description: core registers
> + - description: irq registers
> +
> + interrupts:
> +maxItems: 1
> +
> + intel,has-mst:
Mostly this looks fine, but this property drew my eye.
Firstly, I'd probably call this "intel,multi-stream-support" rather than
"intel,has-mst".
> +type: boolean
> +description: The device supports Multi-Stream Transport
Secondly, there are many many configuration parameters for this IP,
but you have chosen to document just one.
Are all other configuration parameters currently in their default
states or ignored by the driver? If not, please at least document all
configuration settings that you rely on - for example the max stream
count or audio packet encoding.
> +
> + port:
> +$ref: /schemas/graph.yaml#/properties/port
> +description: SST main link
> +
> + ports:
> +$ref: /schemas/graph.yaml#/properties/ports
> +
> +properties:
> + port@0:
> +$ref: /schemas/graph.yaml#/properties/port
> +description: MST virtual channel 0 or SST main link
> +
> + port@1:
> +$ref: /schemas/graph.yaml#/properties/port
> +description: MST virtual channel 1
> +
> + port@2:
> +$ref: /schemas/graph.yaml#/properties/port
> +description: MST virtual channel 2
> +
> + port@3:
> +$ref: /schemas/graph.yaml#/properties/port
> +description: MST virtual channel 3
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> +
> +allOf:
> + - if:
> + required:
> +- intel,has-mst
> +then:
> + required:
> +- ports
> +else:
> + required:
> +- port
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +dprx@c0062000 {
"dprx" isn't a class of device, please try to use a generic node name
here.
Thanks,
Conor.
> +compatible = "intel,dprx";
> +reg = <0xc0062000 0x800>,
> + <0xc0060f80 0x10>;
> +interrupts = ;
> +intel,has-mst;
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +reg = <0>;
> +dprx_mst_0: endpoint {
> +remote-endpoint = <_mst0_0>;
> +};
> +};
> +
> +port@1 {
> +reg = <1>;
> +dprx_mst_1: endpoint {
> +remote-endpoint = <_mst1_0>;
> +};
> +};
> +
> +port@2 {
> +reg = <2>;
> +dprx_mst_2: endpoint {
> +remote-endpoint = <_mst2_0>;
> +};
> +};
> +
> +port@3 {
> +reg = <3>;
> +dprx_mst_3: endpoint {
> +remote-endpoint = <_mst3_0>;
> +};
> +};
> +};
> +};
> +
> + - |
> +dprx@c0064000 {
> +compatible = "intel,dprx";
> +reg = <0xc0064000 0x800>,
> + <0xc0060fe0 0x10>;
> +interrupts = ;
> +
> +port {
> +dprx_sst_0: endpoint {
> +remote-endpoint = <_sst_0>;
> +};
> +};
> +};
> --
> 2.43.0.687.g38aa6559b0-goog
>
signature.asc
Description: PGP signature
Re: [PATCH 1/2] dt-bindings: vendor-prefixes: add prefix for admatec GmbH
On Thu, Feb 15, 2024 at 10:04:41AM +0100, Heiko Stuebner wrote: > From: Heiko Stuebner > > admatec GmbH is a german supplier for industrial displays. > > Signed-off-by: Heiko Stuebner There's a fair few Admatec's it seems, so a link would be good: Link: https://www.admatec.de/ Acked-by: Conor Dooley Cheers, Conor. > --- > 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 1a0dc04f1db47..fef2e12b504ee 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml > +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml > @@ -61,6 +61,8 @@ patternProperties: > description: Analog Devices, Inc. >"^adieng,.*": > description: ADI Engineering, Inc. > + "^admatec,.*": > +description: admatec GmbH >"^advantech,.*": > description: Advantech Corporation >"^aeroflexgaisler,.*": > -- > 2.39.2 > signature.asc Description: PGP signature
Re: [PATCH 2/2] dt-bindings: display: panel-lvds: Add compatible for admatec 9904370 panel
On Thu, Feb 15, 2024 at 10:04:42AM +0100, Heiko Stuebner wrote: > From: Heiko Stuebner > > The 9904379 is a 10.1" 1024x600 LVDS display using the standard > lvds properties. > > Signed-off-by: Heiko Stuebner Acked-by: Conor Dooley Cheers, Conor. > --- > Documentation/devicetree/bindings/display/panel/panel-lvds.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml > b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml > index 3fb24393529cd..155d8ffa8f6ef 100644 > --- a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml > +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml > @@ -39,6 +39,8 @@ properties: >compatible: > items: >- enum: > + # Admatec 9904379 10.1" 1024x600 LVDS panel > + - admatec,9904379 >- auo,b101ew05 ># Chunghwa Picture Tubes Ltd. 7" WXGA (800x1280) TFT LCD LVDS panel >- chunghwa,claa070wp03xg > -- > 2.39.2 > signature.asc Description: PGP signature
Re: [PATCH 2/3] dt-bindings: display: ltk500hd1829: add variant compatible for ltk101b4029w
On Thu, Feb 15, 2024 at 10:05:14AM +0100, Heiko Stuebner wrote: > From: Heiko Stuebner > > Add the compatible for the ltk101b4029w panel, that is really similar > to the ltk500hd1829. Please mention what makes the devices incompatible. "really similar" is vague and could be used for a device that was only cosmetically different. With that, Acked-by: Conor Dooley Cheers, Conor. > > Signed-off-by: Heiko Stuebner > --- > .../bindings/display/panel/leadtek,ltk500hd1829.yaml | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git > a/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml > b/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml > index c5944b4d636c5..d589f16772145 100644 > --- > a/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml > +++ > b/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml > @@ -14,7 +14,9 @@ allOf: > > properties: >compatible: > -const: leadtek,ltk500hd1829 > +enum: > + - leadtek,ltk101b4029w > + - leadtek,ltk500hd1829 >reg: true >backlight: true >reset-gpios: true > -- > 2.39.2 > signature.asc Description: PGP signature
Re: [PATCH v2 1/6] dt-bindings: display/msm/gmu: Document Adreno 750 GMU
On Thu, Feb 15, 2024 at 10:20:23AM +0100, Neil Armstrong wrote: > Document the Adreno 750 GMU found on the SM8650 platform. > > Reviewed-by: Konrad Dybcio > Signed-off-by: Neil Armstrong Acked-by: Conor Dooley Cheers, Conor. > --- > Documentation/devicetree/bindings/display/msm/gmu.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/display/msm/gmu.yaml > b/Documentation/devicetree/bindings/display/msm/gmu.yaml > index 4e1c25b42908..b3837368a260 100644 > --- a/Documentation/devicetree/bindings/display/msm/gmu.yaml > +++ b/Documentation/devicetree/bindings/display/msm/gmu.yaml > @@ -224,6 +224,7 @@ allOf: > enum: >- qcom,adreno-gmu-730.1 >- qcom,adreno-gmu-740.1 > + - qcom,adreno-gmu-750.1 > then: >properties: > reg: > > -- > 2.34.1 > signature.asc Description: PGP signature
Re: [PATCH v3 1/4] dt-bindings: display: bridge: add sam9x75-lvds compatible
$subject: dt-bindings: display: bridge: add sam9x75-lvds compatible If there's a respin for some reason, please update the subject to match what the commit is actually doing (adding a whole binding). Cheers, Conor. signature.asc Description: PGP signature
Re: [PATCH v3 1/2] dt-bindings: display: bridge: cdns: Add display bridge support for dsi on StarFive JH7110 SoC
On Tue, Feb 06, 2024 at 02:57:08PM +0800, Shengyang Chen wrote: > From: Keith Zhao > > Add compatible to support dsi bridge on StarFive JH7110 SoC > > Signed-off-by: Keith Zhao > Signed-off-by: Shengyang Chen Reviewed-by: Conor Dooley Cheers, Conor. signature.asc Description: PGP signature
Re: [PATCH v4 1/3] dt-bindings: display: add STM32 LVDS device
On Tue, Feb 06, 2024 at 12:33:16PM +0100, Raphael Gallais-Pou wrote: > Add "st,stm32mp25-lvds" compatible. > > Signed-off-by: Raphael Gallais-Pou Reviewed-by: Conor Dooley Thanks, Conor. signature.asc Description: PGP signature
Re: [PATCH v2 1/6] dt-bindings: display: rockchip: rockchip, dw-hdmi: remove port property
On Wed, Jan 31, 2024 at 10:14:29PM +0100, Johan Jonker wrote:
> The hdmi-connector nodes are now functional and the new way to model
> hdmi ports nodes with both in and output port subnodes. Unfortunately
> with the conversion to YAML the old method with only an input port node
> was used. Later the new method was also added to the binding.
> A binding must be unambiguously, so remove the old port property
> entirely and make port@0 and port@1 a requirement as all
> upstream dts files are updated as well and because checking
> deprecated stuff is a bit pointless.
> Update the example to avoid use of the removed property.
>
> Signed-off-by: Johan Jonker
Acked-by: Conor Dooley
Thanks,
Conor.
> ---
>
> Changed V2:
> rename title from deprecate to remove
> reword
> ---
> .../display/rockchip/rockchip,dw-hdmi.yaml| 24 +++
> 1 file changed, 20 insertions(+), 4 deletions(-)
>
> diff --git
> a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> index 7e59dee15a5f..391c2a7e79de 100644
> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> @@ -97,8 +97,8 @@ properties:
>ports:
> $ref: /schemas/graph.yaml#/properties/ports
>
> -patternProperties:
> - "^port(@0)?$":
> +properties:
> + port@0:
> $ref: /schemas/graph.yaml#/properties/port
> description: Input of the DWC HDMI TX
> properties:
> @@ -108,11 +108,14 @@ properties:
> description: Connection to the VOPB
>endpoint@1:
> description: Connection to the VOPL
> -properties:
>port@1:
> $ref: /schemas/graph.yaml#/properties/port
> description: Output of the DWC HDMI TX
>
> +required:
> + - port@0
> + - port@1
> +
>rockchip,grf:
> $ref: /schemas/types.yaml#/definitions/phandle
> description:
> @@ -147,7 +150,11 @@ examples:
> clock-names = "iahb", "isfr";
>
> ports {
> -port {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +reg = <0>;
> #address-cells = <1>;
> #size-cells = <0>;
>
> @@ -155,11 +162,20 @@ examples:
> reg = <0>;
> remote-endpoint = <_out_hdmi>;
> };
> +
> hdmi_in_vopl: endpoint@1 {
> reg = <1>;
> remote-endpoint = <_out_hdmi>;
> };
> };
> +
> +port@1 {
> +reg = <1>;
> +
> +hdmi_out_con: endpoint {
> +remote-endpoint = <_con_in>;
> +};
> +};
> };
> };
>
> --
> 2.39.2
>
signature.asc
Description: PGP signature
Re: [linux][PATCH v5 2/3] dt-bindings: atmel,hlcdc: convert pwm bindings to json-schema
On Wed, Jan 31, 2024 at 09:05:22AM +0530, Dharma Balasubiramani wrote:
> Convert device tree bindings for Atmel's HLCDC PWM controller to YAML
> format.
>
> Signed-off-by: Dharma Balasubiramani
> Reviewed-by: Conor Dooley
Same comment about the examples here FWIW.
> +examples:
> + - |
> +pwm {
> + compatible = "atmel,hlcdc-pwm";
> + pinctrl-names = "default";
> + pinctrl-0 = <_lcd_pwm>;
> + #pwm-cells = <3>;
> +};
signature.asc
Description: PGP signature
Re: [linux][PATCH v5 1/3] dt-bindings: display: convert Atmel's HLCDC to DT schema
On Wed, Jan 31, 2024 at 09:05:21AM +0530, Dharma Balasubiramani wrote:
> Convert the existing DT binding to DT schema of the Atmel's HLCDC display
> controller.
I feel like I recall a request to only have a complete example in the
mfd binding but nowhere else.
Otherwise,
Reviewed-by: Conor Dooley
Cheers,
Conor.
> +examples:
> + - |
> +display-controller {
> + compatible = "atmel,hlcdc-display-controller";
> + pinctrl-names = "default";
> + pinctrl-0 = <_lcd_base _lcd_rgb565>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +reg = <0>;
> +
> +hlcdc_panel_output: endpoint@0 {
> + reg = <0>;
> + bus-width = <16>;
> + remote-endpoint = <_input>;
> +};
> + };
> +};
signature.asc
Description: PGP signature
Re: [linux][PATCH v5 3/3] dt-bindings: mfd: atmel,hlcdc: Convert to DT schema format
On Wed, Jan 31, 2024 at 09:05:23AM +0530, Dharma Balasubiramani wrote: > Convert the atmel,hlcdc binding to DT schema format. > > Align clocks and clock-names properties to clearly indicate that the LCD > controller expects lvds_pll_clk when interfaced with the lvds display. This > alignment with the specific hardware requirements ensures accurate device tree > configuration for systems utilizing the HLCDC IP. > > Signed-off-by: Dharma Balasubiramani Reviewed-by: Conor Dooley Thanks, Conor. signature.asc Description: PGP signature
Re: [drm-drm-misc:drm-misc-next v2] dt-bindings: nt35510: document 'port' property
On Wed, Jan 31, 2024 at 10:28:44AM +0100, Dario Binacchi wrote: > Allow 'port' property (coming from panel-common.yaml) to be used in DTS: > > st/stm32f769-disco-mb1166-reva09.dtb: panel@0: 'port' does not match any of > the regexes: 'pinctrl-[0-9]+' > > Signed-off-by: Dario Binacchi > Cc: Alexandre Torgue Acked-by: Conor Dooley > > --- > > Changes in v2: > - Rework the patch to drop errors found by command > 'make DT_CHECKER_FLAGS=-m dt_binding_check'. > > .../devicetree/bindings/display/panel/novatek,nt35510.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git > a/Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml > b/Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml > index a4afaff483b7..91921f4b0e5f 100644 > --- a/Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml > +++ b/Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml > @@ -31,6 +31,7 @@ properties: >vddi-supply: > description: regulator that supplies the vddi voltage >backlight: true > + port: true > > required: >- compatible > -- > 2.43.0 > signature.asc Description: PGP signature
Re: [PATCH v1 1/6] dt-bindings: display: rockchip: rockchip, dw-hdmi: deprecate port property
On Tue, Jan 30, 2024 at 03:55:43PM +0100, Johan Jonker wrote:
> The hdmi-connector nodes are now functional and the new way to model
> hdmi nodes with, so deprecate the port property and
This doesn't really explain what makes having hdmi-connector nodes
replace the usecase for "port".
> make port@0 and
> port@1 a requirement.
Why?
> Also update example.
"Also do x" is a red flag when it comes to commit messages, as it
immediately makes me think that this should be more than one commit.
I'd probably write this as "Update the example to avoid use of the
deprecated property" or something to avoid bad gut reactions.
That's not worth resending for though obviously...
>
> Signed-off-by: Johan Jonker
> ---
> .../display/rockchip/rockchip,dw-hdmi.yaml| 27 ---
> 1 file changed, 23 insertions(+), 4 deletions(-)
>
> diff --git
> a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> index 7e59dee15a5f..cd0a42f35f24 100644
> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> @@ -97,8 +97,11 @@ properties:
>ports:
> $ref: /schemas/graph.yaml#/properties/ports
>
> -patternProperties:
> - "^port(@0)?$":
> +properties:
> + port:
> +$ref: /schemas/graph.yaml#/properties/port
> +deprecated: true
This change makes the deprecated property's description incomplete,
since it doesn't cover the endpoints any more. It also doesn't make
port@0 and port mutually exclusive.
I think I'd just be inclined to delete the "port" bit entirely from the
binding if you're not gonna preserve the description of what that
property was meant to be. Otherwise, I'd be doing something like:
@@ -112,6 +112,8 @@ properties:
endpoint@1:
description: Connection to the VOPL
properties:
+ port:
+deprecated: true
port@1:
$ref: /schemas/graph.yaml#/properties/port
description: Output of the DWC HDMI TX
So that the description of the deprecated property is maintained.
Cheers,
Conor.
> + port@0:
> $ref: /schemas/graph.yaml#/properties/port
> description: Input of the DWC HDMI TX
> properties:
> @@ -108,11 +111,14 @@ properties:
> description: Connection to the VOPB
>endpoint@1:
> description: Connection to the VOPL
> -properties:
>port@1:
> $ref: /schemas/graph.yaml#/properties/port
> description: Output of the DWC HDMI TX
>
> +required:
> + - port@0
> + - port@1
> +
>rockchip,grf:
> $ref: /schemas/types.yaml#/definitions/phandle
> description:
> @@ -147,7 +153,11 @@ examples:
> clock-names = "iahb", "isfr";
>
> ports {
> -port {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +reg = <0>;
> #address-cells = <1>;
> #size-cells = <0>;
>
> @@ -155,11 +165,20 @@ examples:
> reg = <0>;
> remote-endpoint = <_out_hdmi>;
> };
> +
> hdmi_in_vopl: endpoint@1 {
> reg = <1>;
> remote-endpoint = <_out_hdmi>;
> };
> };
> +
> +port@1 {
> +reg = <1>;
> +
> +hdmi_out_con: endpoint {
> +remote-endpoint = <_con_in>;
> +};
> +};
> };
> };
>
> --
> 2.39.2
>
signature.asc
Description: PGP signature
Re: [PATCH v1 2/6] dt-bindings: display: rockchip,dw-hdmi: add power-domains property
On Tue, Jan 30, 2024 at 03:57:23PM +0100, Johan Jonker wrote:
> Most Rockchip hdmi nodes are part of a power domain.
> Add a power-domains property.
Acked-by: Conor Dooley
> Fix example.
Just a note, in the future please explain why simply reordering the
properties constitutes "fixing" the example. I figure your intention is
to align with the (new) documentation about property ordering.
Thanks,
Conor.
>
> Signed-off-by: Johan Jonker
> ---
> .../bindings/display/rockchip/rockchip,dw-hdmi.yaml | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git
> a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> index cd0a42f35f24..6f421740b613 100644
> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> @@ -94,6 +94,9 @@ properties:
>- const: default
>- const: unwedge
>
> + power-domains:
> +maxItems: 1
> +
>ports:
> $ref: /schemas/graph.yaml#/properties/ports
>
> @@ -141,16 +144,18 @@ examples:
> #include
> #include
> #include
> +#include
>
> hdmi: hdmi@ff98 {
> compatible = "rockchip,rk3288-dw-hdmi";
> reg = <0xff98 0x2>;
> -reg-io-width = <4>;
> -ddc-i2c-bus = <>;
> -rockchip,grf = <>;
> interrupts = ;
> clocks = < PCLK_HDMI_CTRL>, < SCLK_HDMI_HDCP>;
> clock-names = "iahb", "isfr";
> +ddc-i2c-bus = <>;
> +power-domains = < RK3288_PD_VIO>;
> +reg-io-width = <4>;
> +rockchip,grf = <>;
>
> ports {
> #address-cells = <1>;
> --
> 2.39.2
>
>
signature.asc
Description: PGP signature
Re: [PATCH v4 0/3] Convert Microchip's HLCDC Text based DT bindings to JSON schema
On Tue, Jan 30, 2024 at 06:42:04AM +, dharm...@microchip.com wrote: > Hi Conor, > > On 24/01/24 10:10 pm, Conor Dooley wrote: > > On Wed, Jan 24, 2024 at 03:30:16PM +0530, Dharma Balasubiramani wrote: > >> Converted the text bindings to YAML and validated them individually using > >> following commands > >> > >> $ make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/ > >> $ make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/ > >> > >> changelogs are available in respective patches. > >> > >> As Sam suggested I'm sending the PWM binding as it is in this patch > >> series, clean up patch > >> will be sent as separate patch. > > Please give discussion on the previous version some time to complete > > before sending a new one. I've still got questions about the clocks > > there. > > Could you please give a green signal to proceed with the v5 patch series > with the following changes only in PATCH 3/3? Didn't we just decide on what to do on the v3 thread yesterday? Go with that. > + clocks: > +minItems: 3 > + > + clock-names: > +items: > + - const: periph_clk > + - const: sys_clk > + - const: slow_clk > + - const: lvds_pll_clk > > > > > Thanks, > > Conor. > > -- > With Best Regards, > Dharma B. > signature.asc Description: PGP signature
Re: [PATCH v3 3/3] dt-bindings: mfd: atmel,hlcdc: Convert to DT schema format
On Mon, Jan 29, 2024 at 03:41:22AM +, dharm...@microchip.com wrote: > I will proceed with updating the clock names to include "lvds pll" and > adjusting the clocks minitems to 3. Does this seem appropriate to you? > > Please let me know if there are any additional considerations or > specific aspects that require attention. That seems okay, thanks. signature.asc Description: PGP signature
Re: [PATCH RFC for upstream 1/4] dt-bindings: display: panel-simple: add ETML1010G3DRA
Hey, On Fri, Jan 26, 2024 at 09:57:23AM +0100, Yannic Moog wrote: > Add Emerging Display Technology Corp. etml1010g3dra 10.1" LCD-TFT LVDS > panel compatible string. > > Signed-off-by: Yannic Moog > [PATCH RFC for upstream 1/4] The "for upstream" here is not really relevant, what else would the patch be for? Acked-by: Conor Dooley Thanks, Conor. > --- > Documentation/devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > index 11422af3477e..b6bbdb3dd2b2 100644 > --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > @@ -139,6 +139,8 @@ properties: >- edt,etm0700g0edh6 > # Emerging Display Technology Corp. LVDS WSVGA TFT Display with > capacitive touch >- edt,etml0700y5dha > +# Emerging Display Technology Corp. 10.1" LVDS WXGA TFT Display with > capacitive touch > + - edt,etml1010g3dra > # Emerging Display Technology Corp. 5.7" VGA TFT LCD panel with > # capacitive touch >- edt,etmv570g2dhu > > -- > 2.34.1 > signature.asc Description: PGP signature
Re: [PATCH v3 3/3] dt-bindings: mfd: atmel,hlcdc: Convert to DT schema format
On Fri, Jan 26, 2024 at 02:22:42PM +, dharm...@microchip.com wrote: > On 25/01/24 1:57 pm, Conor Dooley - M52691 wrote: > > > >>> If the lvds pll is an input to the hlcdc, you need to add it here. > >>> From your description earlier it does sound like it is an input to > >>> the hlcdc, but now you are claiming that it is not. > >> > >> The LVDS PLL serves as an input to both the LCDC and LVDSC > > > > Then it should be an input to both the LCDC and LVDSC in the devicetree. > > For the LVDSC to operate, the presence of the LVDS PLL is crucial. However, > in the case of the LCDC, LVDS PLL is not essential for its operation unless > LVDS interface is used and when it is used lvds driver will take care of > preparing and enabling the LVDS PLL. Please fix your line wrapping, not sure what's going on here, but these lines are super long. > Consequently, it seems that there might not be any significant actions we can > take within the LCD driver regarding the LVDS PLL. You should be getting a reference to the clock and calling enable on it etc, even if the LVDSC is also doing so. That will allow the clock framework to correctly track users. > If there are no intentions to utilize it within the driver, is it necessary > to explicitly designate it as an input in the device tree? The binding describes the hardware, so yes it should be there. What the driver implementation does with the clock is not relevant. That said, I think the driver should actually be using it, as I wrote above. > > If yes, I will update the bindings with optional LVDS PLL clock. > > clock-names: > items: > - const: periph_clk > - const: sys_clk > - const: slow_clk > - const: lvds_pll # Optional clock This looks correct, but the comment is not needed. Setting minItems: 3 does this for you. > >> with the > >> LVDS_PLL multiplied by 7 for the Pixel clock to the LVDS PHY, and > > > > Are you sure? The diagram doesn't show a multiplier, the 7x comment > > there seems to be showing relations? > > Sorry, > LVDS PLL = (PCK * 7) goes to LVDSC PHY > PCK = (LVDS PLL / 7) goes to LCDC I'll take your word for it :) > >> LVDS_PLL divided by 7 for the Pixel clock to the LCDC. > > > >> I am inclined to believe that appropriately configuring and enabling it > >> in the LVDS driver would be the appropriate course of action. > > > > We're talking about bindings here, not drivers, but I would imagine that > > if two peripherals are using the same clock then both of them should be > > getting a reference to and enabling that clock so that the clock > > framework can correctly track the users. > > > >>> I don't know your hardware, so I have no idea which of the two is > >>> correct, but it sounds like the former. Without digging into how this > >>> works my assumption about the hardware here looks like is that the lvds > >>> controller is a clock provider, > >> > >> It's a PLL clock from PMC. > >> > >>> and that the lvds controller's clock is > >>> an optional input for the hlcdc. > >> > >> Again it's a PLL clock from PMC. > >> > >> Please refer Section 39.3 > >> https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ProductDocuments/DataSheets/SAM9X7-Series-Data-Sheet-DS60001813.pdf > > > > It is not the same exact clock as you pointed out above though, so the > > by 7 divider should be modelled. > > Modelled in mfd binding? If possible, could you please provide an example for > better clarity? Thank you. Whatever node corresponds to the register range controlling this PLL should be a "clock-controller" (like any other clock provider does). Your PMC should have this property. I don't know if the correct location is the mfd node or somewhere else, you'll have to check your docs. Thanks, Conor. signature.asc Description: PGP signature
Re: [PATCH v3 3/3] dt-bindings: mfd: atmel,hlcdc: Convert to DT schema format
> > If the lvds pll is an input to the hlcdc, you need to add it here.
> > From your description earlier it does sound like it is an input to
> > the hlcdc, but now you are claiming that it is not.
>
> The LVDS PLL serves as an input to both the LCDC and LVDSC
Then it should be an input to both the LCDC and LVDSC in the devicetree.
> with the
> LVDS_PLL multiplied by 7 for the Pixel clock to the LVDS PHY, and
Are you sure? The diagram doesn't show a multiplier, the 7x comment
there seems to be showing relations?
> LVDS_PLL divided by 7 for the Pixel clock to the LCDC.
> I am inclined to believe that appropriately configuring and enabling it
> in the LVDS driver would be the appropriate course of action.
We're talking about bindings here, not drivers, but I would imagine that
if two peripherals are using the same clock then both of them should be
getting a reference to and enabling that clock so that the clock
framework can correctly track the users.
> > I don't know your hardware, so I have no idea which of the two is
> > correct, but it sounds like the former. Without digging into how this
> > works my assumption about the hardware here looks like is that the lvds
> > controller is a clock provider,
>
> It's a PLL clock from PMC.
>
> > and that the lvds controller's clock is
> > an optional input for the hlcdc.
>
> Again it's a PLL clock from PMC.
>
> Please refer Section 39.3
> https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ProductDocuments/DataSheets/SAM9X7-Series-Data-Sheet-DS60001813.pdf
It is not the same exact clock as you pointed out above though, so the
by 7 divider should be modelled.
> > Can you please explain what provides the lvds pll clock and show an
> > example of how you think the devictree would look with "the lvds pll in
> > the lvds dt node"?
>
> Sure, Please see the below example
>
> The typical lvds node will look like
>
> lvds_controller: lvds-controller@f806 {
> compatible = "microchip,sam9x7-lvds";
> reg = <0xf806 0x100>;
> interrupts = <56 IRQ_TYPE_LEVEL_HIGH 0>;
> clocks = < PMC_TYPE_PERIPHERAL 56>, <
> PMC_TYPE_CORE PMC_LVDSPLL>;
> clock-names = "pclk", "lvds_pll_clk";
> status = "disabled";
> };
In isolation, this looks fine.
Cheers,
Conor.
signature.asc
Description: PGP signature
Re: [PATCH v4 0/3] Convert Microchip's HLCDC Text based DT bindings to JSON schema
On Wed, Jan 24, 2024 at 03:30:16PM +0530, Dharma Balasubiramani wrote: > Converted the text bindings to YAML and validated them individually using > following commands > > $ make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/ > $ make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/ > > changelogs are available in respective patches. > > As Sam suggested I'm sending the PWM binding as it is in this patch series, > clean up patch > will be sent as separate patch. Please give discussion on the previous version some time to complete before sending a new one. I've still got questions about the clocks there. Thanks, Conor. signature.asc Description: PGP signature
Re: [PATCH v3 3/3] dt-bindings: mfd: atmel,hlcdc: Convert to DT schema format
On Wed, Jan 24, 2024 at 05:18:26AM +, dharm...@microchip.com wrote: > Hi Conor & All, > > On 22/01/24 2:46 pm, Conor Dooley wrote: > > On Mon, Jan 22, 2024 at 03:38:41AM +,dharm...@microchip.com wrote: > >> Hi Conor, > >> On 19/01/24 5:33 pm, Conor Dooley - M52691 wrote: > >>> On Fri, Jan 19, 2024 at 03:32:49AM +,dharm...@microchip.com wrote: > >>>> On 18/01/24 9:10 pm, Conor Dooley wrote: > >>>>> On Thu, Jan 18, 2024 at 02:56:12PM +0530, Dharma Balasubiramani wrote: > >>>>>> Convert the atmel,hlcdc binding to DT schema format. > >>>>>> > >>>>>> Adjust the clock-names property to clarify that the LCD controller > >>>>>> expects > >>>>>> one of these clocks (either sys_clk or lvds_pll_clk to be present but > >>>>>> not > >>>>>> both) along with the slow_clk and periph_clk. This alignment with the > >>>>>> actual > >>>>>> hardware requirements will enable accurate device tree configuration > >>>>>> for > >>>>>> systems using the HLCDC IP. > >>>>>> > >>>>>> Signed-off-by: Dharma Balasubiramani > >>>>>> --- > >>>>>> changelog > >>>>>> v2 -> v3 > >>>>>> - Rename hlcdc-display-controller and hlcdc-pwm to generic names. > >>>>>> - Modify the description by removing the unwanted comments and '|'. > >>>>>> - Modify clock-names simpler. > >>>>>> v1 -> v2 > >>>>>> - Remove the explicit copyrights. > >>>>>> - Modify title (not include words like binding/driver). > >>>>>> - Modify description actually describing the hardware and not the > >>>>>> driver. > >>>>>> - Add details of lvds_pll addition in commit message. > >>>>>> - Ref endpoint and not endpoint-base. > >>>>>> - Fix coding style. > >>>>>> ... > >>>>>> .../devicetree/bindings/mfd/atmel,hlcdc.yaml | 97 > >>>>>> +++ > >>>>>> .../devicetree/bindings/mfd/atmel-hlcdc.txt | 56 --- > >>>>>> 2 files changed, 97 insertions(+), 56 deletions(-) > >>>>>> create mode 100644 > >>>>>> Documentation/devicetree/bindings/mfd/atmel,hlcdc.yaml > >>>>>> delete mode 100644 > >>>>>> Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt > >>>>>> > >>>>>> diff --git a/Documentation/devicetree/bindings/mfd/atmel,hlcdc.yaml > >>>>>> b/Documentation/devicetree/bindings/mfd/atmel,hlcdc.yaml > >>>>>> new file mode 100644 > >>>>>> index ..eccc998ac42c > >>>>>> --- /dev/null > >>>>>> +++ b/Documentation/devicetree/bindings/mfd/atmel,hlcdc.yaml > >>>>>> @@ -0,0 +1,97 @@ > >>>>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > >>>>>> +%YAML 1.2 > >>>>>> +--- > >>>>>> +$id:http://devicetree.org/schemas/mfd/atmel,hlcdc.yaml# > >>>>>> +$schema:http://devicetree.org/meta-schemas/core.yaml# > >>>>>> + > >>>>>> +title: Atmel's HLCD Controller > >>>>>> + > >>>>>> +maintainers: > >>>>>> + - Nicolas Ferre > >>>>>> + - Alexandre Belloni > >>>>>> + - Claudiu Beznea > >>>>>> + > >>>>>> +description: > >>>>>> + The Atmel HLCDC (HLCD Controller) IP available on Atmel SoCs > >>>>>> exposes two > >>>>>> + subdevices, a PWM chip and a Display Controller. > >>>>>> + > >>>>>> +properties: > >>>>>> + compatible: > >>>>>> +enum: > >>>>>> + - atmel,at91sam9n12-hlcdc > >>>>>> + - atmel,at91sam9x5-hlcdc > >>>>>> + - atmel,sama5d2-hlcdc > >>>>>> + - atmel,sama5d3-hlcdc > >>>>>> + - atmel,sama5d4-hlcdc > >>>>>> + - microchip,sam9x60-hlcdc > >>>>>> + - microchip,sam9x75-xlcdc > >>>>>> +
Re: [PATCH v3 1/3] dt-bindings: mailbox: Add mediatek,gce-props.yaml
On Mon, Jan 22, 2024 at 11:38:15AM +0100, AngeloGioacchino Del Regno wrote: > Il 19/01/24 17:44, Conor Dooley ha scritto: > > Rob, > > > > On Fri, Jan 19, 2024 at 02:32:22PM +0800, Jason-JH.Lin wrote: > > > Add mediatek,gce-props.yaml for common GCE properties that is used for > > > both mailbox providers and consumers. We place the common property > > > "mediatek,gce-events" in this binding currently. > > > > > > The property "mediatek,gce-events" is used for GCE event ID corresponding > > > to a hardware event signal sent by the hardware or a sofware driver. > > > If the mailbox providers or consumers want to manipulate the value of > > > the event ID, they need to know the specific event ID. > > > > > > Signed-off-by: Jason-JH.Lin > > > --- > > > .../bindings/mailbox/mediatek,gce-props.yaml | 52 +++ > > > > Is bindings/mailbox the correct directory to put this in? > > > > Well, the GCE is a mailbox :-) > > ...but I get why you're asking... and I don't think that this should go to > arm/mediatek/ as it's really just only referring to extra properties for kind > of > "special" mailbox client events... gce is a mailbox, but this isn't a binding for the mailbox itself, hence me wondering. I haven't been able to think of something better though, so Reviewed-by: Conor Dooley Cheers, Conor. signature.asc Description: PGP signature
Re: [PATCH 1/3] dt-bindings: display: bridge: add sam9x7-lvds compatible
On Mon, Jan 22, 2024 at 04:51:16PM +0100, Krzysztof Kozlowski wrote: > On 22/01/2024 09:29, Dharma Balasubiramani wrote: > > Add the 'sam9x7-lvds' compatible binding, which describes the > > Low Voltage Differential Signaling (LVDS) Controller found on Microchip's > > sam9x7 series System-on-Chip (SoC) devices. This binding will be used to > > define the properties and configuration for the LVDS Controller in DT. > > > > Signed-off-by: Dharma Balasubiramani > > --- > > .../display/bridge/microchip,sam9x7-lvds.yaml | 59 +++ > > 1 file changed, 59 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/bridge/microchip,sam9x7-lvds.yaml > > > > diff --git > > a/Documentation/devicetree/bindings/display/bridge/microchip,sam9x7-lvds.yaml > > > > b/Documentation/devicetree/bindings/display/bridge/microchip,sam9x7-lvds.yaml > > new file mode 100644 > > index ..8c2c5b858c85 > > --- /dev/null > > +++ > > b/Documentation/devicetree/bindings/display/bridge/microchip,sam9x7-lvds.yaml > > @@ -0,0 +1,59 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: > > http://devicetree.org/schemas/display/bridge/microchip,sam9x7-lvds.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Microchip SAM9X7 LVDS Controller > > What is the "X"? > > > + > > +maintainers: > > + - Dharma Balasubiramani > > + > > +description: | > > Do not need '|' unless you need to preserve formatting. > > > + The Low Voltage Differential Signaling Controller (LVDSC) manages data > > + format conversion from the LCD Controller internal DPI bus to OpenLDI > > + LVDS output signals. LVDSC functions include bit mapping, balanced mode > > + management, and serializer. > > + > > +properties: > > + compatible: > > +const: microchip,sam9x7-lvds > > What is "x"? Wildcard? Then no, don't use it and instead use proper SoC > version number. These SoCs actually do have an x in their name. However, and I do always get confused here, the sam9x7 is a series of SoCs (the cover letter does say this) rather than a specific device. I think the series current consists of a sam9x70 sam9x72 and a sam9x75. The devices are largely similar, but I am not sure if the sam9x70 supports LVDS at all. Having a compatible for the series does not seem correct to me. Cheers, Conor. signature.asc Description: PGP signature
Re: [PATCH v3 3/3] dt-bindings: mfd: atmel,hlcdc: Convert to DT schema format
On Mon, Jan 22, 2024 at 03:38:41AM +, dharm...@microchip.com wrote: > Hi Conor, > On 19/01/24 5:33 pm, Conor Dooley - M52691 wrote: > > On Fri, Jan 19, 2024 at 03:32:49AM +, dharm...@microchip.com wrote: > >> On 18/01/24 9:10 pm, Conor Dooley wrote: > >>> On Thu, Jan 18, 2024 at 02:56:12PM +0530, Dharma Balasubiramani wrote: > >>>> Convert the atmel,hlcdc binding to DT schema format. > >>>> > >>>> Adjust the clock-names property to clarify that the LCD controller > >>>> expects > >>>> one of these clocks (either sys_clk or lvds_pll_clk to be present but not > >>>> both) along with the slow_clk and periph_clk. This alignment with the > >>>> actual > >>>> hardware requirements will enable accurate device tree configuration for > >>>> systems using the HLCDC IP. > >>>> > >>>> Signed-off-by: Dharma Balasubiramani > >>>> --- > >>>> changelog > >>>> v2 -> v3 > >>>> - Rename hlcdc-display-controller and hlcdc-pwm to generic names. > >>>> - Modify the description by removing the unwanted comments and '|'. > >>>> - Modify clock-names simpler. > >>>> v1 -> v2 > >>>> - Remove the explicit copyrights. > >>>> - Modify title (not include words like binding/driver). > >>>> - Modify description actually describing the hardware and not the driver. > >>>> - Add details of lvds_pll addition in commit message. > >>>> - Ref endpoint and not endpoint-base. > >>>> - Fix coding style. > >>>> ... > >>>>.../devicetree/bindings/mfd/atmel,hlcdc.yaml | 97 +++ > >>>>.../devicetree/bindings/mfd/atmel-hlcdc.txt | 56 --- > >>>>2 files changed, 97 insertions(+), 56 deletions(-) > >>>>create mode 100644 > >>>> Documentation/devicetree/bindings/mfd/atmel,hlcdc.yaml > >>>>delete mode 100644 > >>>> Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt > >>>> > >>>> diff --git a/Documentation/devicetree/bindings/mfd/atmel,hlcdc.yaml > >>>> b/Documentation/devicetree/bindings/mfd/atmel,hlcdc.yaml > >>>> new file mode 100644 > >>>> index ..eccc998ac42c > >>>> --- /dev/null > >>>> +++ b/Documentation/devicetree/bindings/mfd/atmel,hlcdc.yaml > >>>> @@ -0,0 +1,97 @@ > >>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > >>>> +%YAML 1.2 > >>>> +--- > >>>> +$id:http://devicetree.org/schemas/mfd/atmel,hlcdc.yaml# > >>>> +$schema:http://devicetree.org/meta-schemas/core.yaml# > >>>> + > >>>> +title: Atmel's HLCD Controller > >>>> + > >>>> +maintainers: > >>>> + - Nicolas Ferre > >>>> + - Alexandre Belloni > >>>> + - Claudiu Beznea > >>>> + > >>>> +description: > >>>> + The Atmel HLCDC (HLCD Controller) IP available on Atmel SoCs exposes > >>>> two > >>>> + subdevices, a PWM chip and a Display Controller. > >>>> + > >>>> +properties: > >>>> + compatible: > >>>> +enum: > >>>> + - atmel,at91sam9n12-hlcdc > >>>> + - atmel,at91sam9x5-hlcdc > >>>> + - atmel,sama5d2-hlcdc > >>>> + - atmel,sama5d3-hlcdc > >>>> + - atmel,sama5d4-hlcdc > >>>> + - microchip,sam9x60-hlcdc > >>>> + - microchip,sam9x75-xlcdc > >>>> + > >>>> + reg: > >>>> +maxItems: 1 > >>>> + > >>>> + interrupts: > >>>> +maxItems: 1 > >>>> + > >>>> + clocks: > >>>> +maxItems: 3 > >>> Hmm, one thing I probably should have said on the previous version, but > >>> I missed somehow: It would be good to add an items list to the clocks > >>> property here to explain what the 3 clocks are/are used for - especially > >>> since there is additional complexity being added here to use either the > >>> sys or lvds clocks. > >> May I inquire if this approach is likely to be effective? > >> > >> clocks: > >> items: > >> - description: peripheral clock > >> - descri
Re: [PATCH v3 3/3] dt-bindings: soc: mediatek: Change mediatek,gce-events to refernece
On Fri, Jan 19, 2024 at 02:32:24PM +0800, Jason-JH.Lin wrote: > Change mediatek,gce-events property to reference mediatek,gce-props.yaml > instead of defining itself. > > Signed-off-by: Jason-JH.Lin Reviewed-by: Conor Dooley Cheers, Conor. signature.asc Description: PGP signature
Re: [PATCH v3 2/3] dt-bindings: media: mediatek: mdp: Change mediatek,gce-events to reference
On Fri, Jan 19, 2024 at 02:32:23PM +0800, Jason-JH.Lin wrote: > Change mediatek,gce-events property to reference mediatek,gce-props.yaml > instead of defining itself. > > Signed-off-by: Jason-JH.Lin Reviewed-by: Conor Dooley Cheers, Conor. signature.asc Description: PGP signature
Re: [PATCH v3 1/3] dt-bindings: mailbox: Add mediatek,gce-props.yaml
Rob, On Fri, Jan 19, 2024 at 02:32:22PM +0800, Jason-JH.Lin wrote: > Add mediatek,gce-props.yaml for common GCE properties that is used for > both mailbox providers and consumers. We place the common property > "mediatek,gce-events" in this binding currently. > > The property "mediatek,gce-events" is used for GCE event ID corresponding > to a hardware event signal sent by the hardware or a sofware driver. > If the mailbox providers or consumers want to manipulate the value of > the event ID, they need to know the specific event ID. > > Signed-off-by: Jason-JH.Lin > --- > .../bindings/mailbox/mediatek,gce-props.yaml | 52 +++ Is bindings/mailbox the correct directory to put this in? > 1 file changed, 52 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/mailbox/mediatek,gce-props.yaml > > diff --git > a/Documentation/devicetree/bindings/mailbox/mediatek,gce-props.yaml > b/Documentation/devicetree/bindings/mailbox/mediatek,gce-props.yaml > new file mode 100644 > index ..68b519ff089f > --- /dev/null > +++ b/Documentation/devicetree/bindings/mailbox/mediatek,gce-props.yaml > @@ -0,0 +1,52 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/mailbox/mediatek,gce-props.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: MediaTek Global Command Engine Common Propertes > + > +maintainers: > + - Houlong Wei > + > +description: > + The Global Command Engine (GCE) is an instruction based, multi-threaded, > + single-core command dispatcher for MediaTek hardware. The Command Queue > + (CMDQ) mailbox driver is a driver for GCE, implemented using the Linux > + mailbox framework. It is used to receive messages from mailbox consumers > + and configure GCE to execute the specified instruction set in the message. > + We use mediatek,gce-mailbox.yaml to define the properties for CMDQ mailbox > + driver. A device driver that uses the CMDQ driver to configure its hardware > + registers is a mailbox consumer. The mailbox consumer can request a mailbox > + channel corresponding to a GCE hardware thread to send a message, > specifying > + that the GCE thread to configure its hardware. The mailbox provider can > also > + reserved a mailbox channel to configure GCE hardware register by the > spcific > + GCE thread. This binding defines the common GCE properties for both mailbox > + provider and consumers. > + > +properties: > + mediatek,gce-events: > +description: > + GCE has an event table in SRAM, consisting of 1024 event IDs (0~1023). > + Each event ID has a boolean event value with the default value 0. > + The property mediatek,gce-events is used to obtain the event IDs. > + Some gce-events are hardware-bound and cannot be changed by software. > + For instance, in MT8195, when VDO0_MUTEX is stream done, VDO_MUTEX will > + send an event signal to GCE, setting the value of event ID 597 to 1. > + Similarly, in MT8188, the value of event ID 574 will be set to 1 when > + VOD0_MUTEX is stream done. > + On the other hand, some gce-events are not hardware-bound and can be > + changed by software. For example, in MT8188, we can set the value of > + event ID 855, which is not bound to any hardware, to 1 when the driver > + in the secure world completes a task. However, in MT8195, event ID 855 > + is already bound to VDEC_LAT1, so we need to select another event ID to > + achieve the same purpose. This event ID can be any ID that is not bound > + to any hardware and is not yet used in any software driver. > + To determine if the event ID is bound to the hardware or used by a > + software driver, refer to the GCE header > + include/dt-bindings/gce/-gce.h of each chip. > +$ref: /schemas/types.yaml#/definitions/uint32-array > +minItems: 1 > +maxItems: 1024 > + > +additionalProperties: true > -- > 2.18.0 > signature.asc Description: PGP signature
Re: [PATCH v3 3/3] dt-bindings: mfd: atmel,hlcdc: Convert to DT schema format
On Fri, Jan 19, 2024 at 03:32:49AM +, dharm...@microchip.com wrote: > On 18/01/24 9:10 pm, Conor Dooley wrote: > > On Thu, Jan 18, 2024 at 02:56:12PM +0530, Dharma Balasubiramani wrote: > >> Convert the atmel,hlcdc binding to DT schema format. > >> > >> Adjust the clock-names property to clarify that the LCD controller expects > >> one of these clocks (either sys_clk or lvds_pll_clk to be present but not > >> both) along with the slow_clk and periph_clk. This alignment with the > >> actual > >> hardware requirements will enable accurate device tree configuration for > >> systems using the HLCDC IP. > >> > >> Signed-off-by: Dharma Balasubiramani > >> --- > >> changelog > >> v2 -> v3 > >> - Rename hlcdc-display-controller and hlcdc-pwm to generic names. > >> - Modify the description by removing the unwanted comments and '|'. > >> - Modify clock-names simpler. > >> v1 -> v2 > >> - Remove the explicit copyrights. > >> - Modify title (not include words like binding/driver). > >> - Modify description actually describing the hardware and not the driver. > >> - Add details of lvds_pll addition in commit message. > >> - Ref endpoint and not endpoint-base. > >> - Fix coding style. > >> ... > >> .../devicetree/bindings/mfd/atmel,hlcdc.yaml | 97 +++ > >> .../devicetree/bindings/mfd/atmel-hlcdc.txt | 56 --- > >> 2 files changed, 97 insertions(+), 56 deletions(-) > >> create mode 100644 Documentation/devicetree/bindings/mfd/atmel,hlcdc.yaml > >> delete mode 100644 Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt > >> > >> diff --git a/Documentation/devicetree/bindings/mfd/atmel,hlcdc.yaml > >> b/Documentation/devicetree/bindings/mfd/atmel,hlcdc.yaml > >> new file mode 100644 > >> index ..eccc998ac42c > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/mfd/atmel,hlcdc.yaml > >> @@ -0,0 +1,97 @@ > >> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > >> +%YAML 1.2 > >> +--- > >> +$id:http://devicetree.org/schemas/mfd/atmel,hlcdc.yaml# > >> +$schema:http://devicetree.org/meta-schemas/core.yaml# > >> + > >> +title: Atmel's HLCD Controller > >> + > >> +maintainers: > >> + - Nicolas Ferre > >> + - Alexandre Belloni > >> + - Claudiu Beznea > >> + > >> +description: > >> + The Atmel HLCDC (HLCD Controller) IP available on Atmel SoCs exposes two > >> + subdevices, a PWM chip and a Display Controller. > >> + > >> +properties: > >> + compatible: > >> +enum: > >> + - atmel,at91sam9n12-hlcdc > >> + - atmel,at91sam9x5-hlcdc > >> + - atmel,sama5d2-hlcdc > >> + - atmel,sama5d3-hlcdc > >> + - atmel,sama5d4-hlcdc > >> + - microchip,sam9x60-hlcdc > >> + - microchip,sam9x75-xlcdc > >> + > >> + reg: > >> +maxItems: 1 > >> + > >> + interrupts: > >> +maxItems: 1 > >> + > >> + clocks: > >> +maxItems: 3 > > Hmm, one thing I probably should have said on the previous version, but > > I missed somehow: It would be good to add an items list to the clocks > > property here to explain what the 3 clocks are/are used for - especially > > since there is additional complexity being added here to use either the > > sys or lvds clocks. > May I inquire if this approach is likely to be effective? > >clocks: > items: >- description: peripheral clock >- description: generic clock or lvds pll clock >Once the LVDS PLL is enabled, the pixel clock is used as the >clock for LCDC, so its GCLK is no longer needed. >- description: slow clock > maxItems: 3 Hmm that sounds very suspect to me. "Once the lvdspll is enabled the generic clock is no longer needed" sounds like both clocks can be provided to the IP on different pins and their provision is not mutually exclusive, just that the IP will only actually use one at a time. If that is the case, then this patch is nott correct and the binding should allow for 4 clocks, with both the generic clock and the lvds pll being present in the DT at the same time. I vaguely recall internal discussion about this problem some time back but the details all escape me. Thanks, Conor. signature.asc Description: PGP signature
Re: [PATCH v3 3/3] dt-bindings: mfd: atmel,hlcdc: Convert to DT schema format
On Thu, Jan 18, 2024 at 02:56:12PM +0530, Dharma Balasubiramani wrote: > Convert the atmel,hlcdc binding to DT schema format. > > Adjust the clock-names property to clarify that the LCD controller expects > one of these clocks (either sys_clk or lvds_pll_clk to be present but not > both) along with the slow_clk and periph_clk. This alignment with the actual > hardware requirements will enable accurate device tree configuration for > systems using the HLCDC IP. > > Signed-off-by: Dharma Balasubiramani > --- > changelog > v2 -> v3 > - Rename hlcdc-display-controller and hlcdc-pwm to generic names. > - Modify the description by removing the unwanted comments and '|'. > - Modify clock-names simpler. > v1 -> v2 > - Remove the explicit copyrights. > - Modify title (not include words like binding/driver). > - Modify description actually describing the hardware and not the driver. > - Add details of lvds_pll addition in commit message. > - Ref endpoint and not endpoint-base. > - Fix coding style. > ... > .../devicetree/bindings/mfd/atmel,hlcdc.yaml | 97 +++ > .../devicetree/bindings/mfd/atmel-hlcdc.txt | 56 --- > 2 files changed, 97 insertions(+), 56 deletions(-) > create mode 100644 Documentation/devicetree/bindings/mfd/atmel,hlcdc.yaml > delete mode 100644 Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt > > diff --git a/Documentation/devicetree/bindings/mfd/atmel,hlcdc.yaml > b/Documentation/devicetree/bindings/mfd/atmel,hlcdc.yaml > new file mode 100644 > index ..eccc998ac42c > --- /dev/null > +++ b/Documentation/devicetree/bindings/mfd/atmel,hlcdc.yaml > @@ -0,0 +1,97 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/mfd/atmel,hlcdc.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Atmel's HLCD Controller > + > +maintainers: > + - Nicolas Ferre > + - Alexandre Belloni > + - Claudiu Beznea > + > +description: > + The Atmel HLCDC (HLCD Controller) IP available on Atmel SoCs exposes two > + subdevices, a PWM chip and a Display Controller. > + > +properties: > + compatible: > +enum: > + - atmel,at91sam9n12-hlcdc > + - atmel,at91sam9x5-hlcdc > + - atmel,sama5d2-hlcdc > + - atmel,sama5d3-hlcdc > + - atmel,sama5d4-hlcdc > + - microchip,sam9x60-hlcdc > + - microchip,sam9x75-xlcdc > + > + reg: > +maxItems: 1 > + > + interrupts: > +maxItems: 1 > + > + clocks: > +maxItems: 3 Hmm, one thing I probably should have said on the previous version, but I missed somehow: It would be good to add an items list to the clocks property here to explain what the 3 clocks are/are used for - especially since there is additional complexity being added here to use either the sys or lvds clocks. Thanks, Conor. > + > + clock-names: > +items: > + - const: periph_clk > + - enum: [sys_clk, lvds_pll_clk] > + - const: slow_clk signature.asc Description: PGP signature
Re: [PATCH v3 1/3] dt-bindings: display: convert Atmel's HLCDC to DT schema
On Thu, Jan 18, 2024 at 02:56:10PM +0530, Dharma Balasubiramani wrote: > Convert the existing DT binding to DT schema of the Atmel's HLCDC display > controller. > > Signed-off-by: Dharma Balasubiramani > --- > changelog > v2 -> v3 > - Remove '|' in description, as there is no formatting to preserve. > - Ref video-interfaces as endpoint. > - Remove ref and description for bus-width. > - Add new line before the child node in example. > - Remove 'example 2', as it is not required for just one additional property. Rob's comment on the previous version was: | Just 1 extra property doesn't justify 2 examples. | | In any case, drop the partial examples and just have 1 complete example | in the MFD binding schema. signature.asc Description: PGP signature
Re: [PATCH v2 2/3] dt-bindings: atmel, hlcdc: convert pwm bindings to json-schema
On Wed, Jan 17, 2024 at 02:43:00AM +, dharm...@microchip.com wrote: > On 17/01/24 1:40 am, Alexandre Belloni wrote: > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > > content is safe > > > > On 16/01/2024 18:03:19+, Conor Dooley wrote: > >> On Tue, Jan 16, 2024 at 05:07:59PM +0530, Dharma Balasubiramani wrote: > >>> Convert device tree bindings for Atmel's HLCDC PWM controller to YAML > >>> format. > >>> > >>> Signed-off-by: Dharma Balasubiramani > >>> --- > >>> changelog > >>> v1 -> v2 > >>> - Remove the explicit copyrights. > >>> - Modify title (not include words like binding/driver). > >>> - Modify description actually describing the hardware and not the driver. > >>> - Remove pinctrl properties which aren't required. > >>> - Drop parent node and it's other sub-device node which are not related > >>> here. > >>> --- > >>> .../bindings/pwm/atmel,hlcdc-pwm.yaml | 47 +++ > >>> .../bindings/pwm/atmel-hlcdc-pwm.txt | 29 > >>> 2 files changed, 47 insertions(+), 29 deletions(-) > >>> create mode 100644 > >>> Documentation/devicetree/bindings/pwm/atmel,hlcdc-pwm.yaml > >>> delete mode 100644 > >>> Documentation/devicetree/bindings/pwm/atmel-hlcdc-pwm.txt > >>> > >>> diff --git a/Documentation/devicetree/bindings/pwm/atmel,hlcdc-pwm.yaml > >>> b/Documentation/devicetree/bindings/pwm/atmel,hlcdc-pwm.yaml > >>> new file mode 100644 > >>> index ..751122309fa9 > >>> --- /dev/null > >>> +++ b/Documentation/devicetree/bindings/pwm/atmel,hlcdc-pwm.yaml > >>> @@ -0,0 +1,47 @@ > >>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > >> > >> The original file has no license, but was originally written by a > >> free-electrons employee, so the relicensing here is fine. > >> > > > > I confirm relicensing is fine, even assigning the copyright to > > Microchip (note that Bootlin is legally the same entity as > > free-electrons) > Thanks Conor and Alexandre. > I will add the copyrights back in v3. Just to note, in case you misunderstood my original comment here: What I said had nothing to do with adding a Microchip copyright assignment to the file, but rather about the fact that your patch relicenses the binding from GPL v2 to GPL v2 OR BSD 2 Clause. signature.asc Description: PGP signature
Re: [PATCH v2 3/3] dt-bindings: mfd: atmel,hlcdc: Convert to DT schema format
On Tue, Jan 16, 2024 at 05:08:00PM +0530, Dharma Balasubiramani wrote:
> Convert the atmel,hlcdc binding to DT schema format.
>
> Adjust the clock-names property to clarify that the LCD controller expects
> one of these clocks (either sys_clk or lvds_pll_clk to be present but not
> both) along with the slow_clk and periph_clk. This alignment with the actual
> hardware requirements will enable accurate device tree configuration for
> systems using the HLCDC IP.
>
> Signed-off-by: Dharma Balasubiramani
> ---
> changelog
> v1 -> v2
> - Remove the explicit copyrights.
> - Modify title (not include words like binding/driver).
> - Modify description actually describing the hardware and not the driver.
> - Add details of lvds_pll addition in commit message.
> - Ref endpoint and not endpoint-base.
> - Fix coding style.
>
> Note: Renaming hlcdc-display-controller, hlcdc-pwm to generic names throws
> errors from the existing DTS files.
I don't think that is important. If there is no code that depends on the
node names (and there is not in the mainline kernel, not sure about
anywhere else) the binding and the devicetree could easily adopt generic
node names.
> ...
> /home/dharma/Mainline/linux/arch/arm/boot/dts/microchip/at91sam9n12ek.dtb:
> hlcdc@f8038000: 'hlcdc-display-controller' does not match any of the
> regexes: 'pinctrl-[0-9]+'
> ---
> .../devicetree/bindings/mfd/atmel,hlcdc.yaml | 105 ++
> .../devicetree/bindings/mfd/atmel-hlcdc.txt | 56 --
> 2 files changed, 105 insertions(+), 56 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mfd/atmel,hlcdc.yaml
> delete mode 100644 Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/atmel,hlcdc.yaml
> b/Documentation/devicetree/bindings/mfd/atmel,hlcdc.yaml
> new file mode 100644
> index ..f624b60b76fb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/atmel,hlcdc.yaml
> @@ -0,0 +1,105 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mfd/atmel,hlcdc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Atmel's HLCD Controller
> +
> +maintainers:
> + - Nicolas Ferre
> + - Alexandre Belloni
> + - Claudiu Beznea
> +
> +description: |
> + The Atmel HLCDC (HLCD Controller) IP available on Atmel SoCs exposes two
> + subdevices
> +# a PWM chip:
> +# a Display Controller:
The formatting here is a bit odd. I'd truncate this to
"subdevices: a PWM chip and a display controller." & drop the |.
> +properties:
> + compatible:
> +enum:
> + - atmel,at91sam9n12-hlcdc
> + - atmel,at91sam9x5-hlcdc
> + - atmel,sama5d2-hlcdc
> + - atmel,sama5d3-hlcdc
> + - atmel,sama5d4-hlcdc
> + - microchip,sam9x60-hlcdc
> + - microchip,sam9x75-xlcdc
> +
> + reg:
> +maxItems: 1
> +
> + interrupts:
> +maxItems: 1
> +
> + clocks:
> +maxItems: 3
> +
> + clock-names:
> +anyOf:
> + - items:
> + - enum:
> + - sys_clk
> + - lvds_pll_clk
> + - contains:
> + const: periph_clk
> + - contains:
> + const: slow_clk
> +maxItems: 3
Why not just:
clock-names:
items:
- const: periph_clk
- enum: [sys_clk, lvds_pll_clk]
- const: slow_clk
Cheers,
Conor.
> +
> + hlcdc-display-controller:
> +$ref: /schemas/display/atmel/atmel,hlcdc-display-controller.yaml
> +
> + hlcdc-pwm:
> +$ref: /schemas/pwm/atmel,hlcdc-pwm.yaml
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - clock-names
> + - interrupts
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +#include
> +#include
> +
> +lcd_controller: lcd-controller@f003 {
> + compatible = "atmel,sama5d3-hlcdc";
> + reg = <0xf003 0x2000>;
> + clocks = <_clk>, <>, <>;
> + clock-names = "periph_clk", "sys_clk", "slow_clk";
> + interrupts = <36 IRQ_TYPE_LEVEL_HIGH 0>;
> +
> + hlcdc-display-controller {
> +compatible = "atmel,hlcdc-display-controller";
> +pinctrl-names = "default";
> +pinctrl-0 = <_lcd_base _lcd_rgb888>;
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> +
> + hlcdc_panel_output: endpoint@0 {
> +reg = <0>;
> +remote-endpoint = <_input>;
> + };
> +};
> + };
> +
> + hlcdc-pwm {
> +compatible = "atmel,hlcdc-pwm";
> +pinctrl-names = "default";
> +pinctrl-0 = <_lcd_pwm>;
> +#pwm-cells = <3>;
> + };
> +};
> diff --git a/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt
> b/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt
> deleted file mode 100644
> index 7de696eefaed..
> ---
Re: [PATCH v2 2/3] dt-bindings: atmel, hlcdc: convert pwm bindings to json-schema
On Tue, Jan 16, 2024 at 05:07:59PM +0530, Dharma Balasubiramani wrote:
> Convert device tree bindings for Atmel's HLCDC PWM controller to YAML
> format.
>
> Signed-off-by: Dharma Balasubiramani
> ---
> changelog
> v1 -> v2
> - Remove the explicit copyrights.
> - Modify title (not include words like binding/driver).
> - Modify description actually describing the hardware and not the driver.
> - Remove pinctrl properties which aren't required.
> - Drop parent node and it's other sub-device node which are not related here.
> ---
> .../bindings/pwm/atmel,hlcdc-pwm.yaml | 47 +++
> .../bindings/pwm/atmel-hlcdc-pwm.txt | 29
> 2 files changed, 47 insertions(+), 29 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/pwm/atmel,hlcdc-pwm.yaml
> delete mode 100644 Documentation/devicetree/bindings/pwm/atmel-hlcdc-pwm.txt
>
> diff --git a/Documentation/devicetree/bindings/pwm/atmel,hlcdc-pwm.yaml
> b/Documentation/devicetree/bindings/pwm/atmel,hlcdc-pwm.yaml
> new file mode 100644
> index ..751122309fa9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/atmel,hlcdc-pwm.yaml
> @@ -0,0 +1,47 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
The original file has no license, but was originally written by a
free-electrons employee, so the relicensing here is fine.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pwm/atmel,hlcdc-pwm.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Atmel's HLCDC's PWM controller
> +
> +maintainers:
> + - Nicolas Ferre
> + - Alexandre Belloni
> + - Claudiu Beznea
> +
> +description: |
Again, the | is not needed here.
> + The LCDC integrates a Pulse Width Modulation (PWM) Controller. This block
> + generates the LCD contrast control signal (LCD_PWM) that controls the
> + display's contrast by software. LCDC_PWM is an 8-bit PWM signal that can be
> + converted to an analog voltage with a simple passive filter. LCD display
> + panels have different backlight specifications in terms of minimum/maximum
> + values for PWM frequency. If the LCDC PWM frequency range does not match
> the
> + LCD display panel, it is possible to use the standalone PWM Controller to
> + drive the backlight.
> +
> +properties:
> + compatible:
> +const: atmel,hlcdc-pwm
> +
> + "#pwm-cells":
> +const: 3
> +description: |
> + This PWM chip uses the default 3 cells bindings defined in pwm.yaml in
> + this directory.
I would delete this description tbh.
> +
> +required:
> + - compatible
> + - "#pwm-cells"
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +pwm: pwm {
> + compatible = "atmel,hlcdc-pwm";
> + pinctrl-names = "default";
> + pinctrl-0 = <_lcd_pwm>;
> + #pwm-cells = <3>;
> +};
The label here is not used and can be dropped. Otherwise,
Reviewed-by: Conor Dooley
Cheers,
Conor.
> diff --git a/Documentation/devicetree/bindings/pwm/atmel-hlcdc-pwm.txt
> b/Documentation/devicetree/bindings/pwm/atmel-hlcdc-pwm.txt
> deleted file mode 100644
> index afa501bf7f94..
> --- a/Documentation/devicetree/bindings/pwm/atmel-hlcdc-pwm.txt
> +++ /dev/null
> @@ -1,29 +0,0 @@
> -Device-Tree bindings for Atmel's HLCDC (High-end LCD Controller) PWM driver
> -
> -The Atmel HLCDC PWM is subdevice of the HLCDC MFD device.
> -See ../mfd/atmel-hlcdc.txt for more details.
> -
> -Required properties:
> - - compatible: value should be one of the following:
> - "atmel,hlcdc-pwm"
> - - pinctr-names: the pin control state names. Should contain "default".
> - - pinctrl-0: should contain the pinctrl states described by pinctrl
> - default.
> - - #pwm-cells: should be set to 3. This PWM chip use the default 3 cells
> - bindings defined in pwm.yaml in this directory.
> -
> -Example:
> -
> - hlcdc: hlcdc@f003 {
> - compatible = "atmel,sama5d3-hlcdc";
> - reg = <0xf003 0x2000>;
> - clocks = <_clk>, <>, <>;
> - clock-names = "periph_clk","sys_clk", "slow_clk";
> -
> - hlcdc_pwm: hlcdc-pwm {
> - compatible = "atmel,hlcdc-pwm";
> - pinctrl-names = "default";
> - pinctrl-0 = <_lcd_pwm>;
> - #pwm-cells = <3>;
> - };
> - };
> --
> 2.25.1
>
signature.asc
Description: PGP signature
Re: [PATCH v2 1/3] dt-bindings: display: convert Atmel's HLCDC to DT schema
Yo,
On Tue, Jan 16, 2024 at 05:07:58PM +0530, Dharma Balasubiramani wrote:
> Convert the existing DT binding to DT schema of the Atmel's HLCDC display
> controller.
>
> Signed-off-by: Dharma Balasubiramani
> ---
> changelog
> v1 -> v2
> - Remove the explicit copyrights.
> - Modify filename like compatible.
> - Modify title (drop words like binding/driver).
> - Modify description actually describing the hardware and not the driver.
> - Remove pinctrl properties which aren't required.
> - Ref endpoint and not endpoint-base.
> - Drop redundant info about bus-width description and add ref to
> video-interfaces.
> - Move 'additionalProperties' after 'Required'.
> - Drop parent node and it's other sub-device node which are not related here.
> - Add compatible to example 2 and add comments that bus-width is the diff
> between two examples.
> ---
> .../atmel/atmel,hlcdc-display-controller.yaml | 110 ++
> .../bindings/display/atmel/hlcdc-dc.txt | 75
> 2 files changed, 110 insertions(+), 75 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/display/atmel/atmel,hlcdc-display-controller.yaml
> delete mode 100644
> Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt
>
> diff --git
> a/Documentation/devicetree/bindings/display/atmel/atmel,hlcdc-display-controller.yaml
>
> b/Documentation/devicetree/bindings/display/atmel/atmel,hlcdc-display-controller.yaml
> new file mode 100644
> index ..f022c294cfbc
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/display/atmel/atmel,hlcdc-display-controller.yaml
> @@ -0,0 +1,110 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id:
> http://devicetree.org/schemas/display/atmel/atmel,hlcdc-display-controller.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Atmel's High LCD Controller (HLCDC)
> +
> +maintainers:
> + - Nicolas Ferre
> + - Alexandre Belloni
> + - Claudiu Beznea
> +
> +description: |
This | is not needed as you have no formatting to preserve.
> + 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.
> +
> +properties:
> + compatible:
> +const: atmel,hlcdc-display-controller
> +
> + '#address-cells':
> +const: 1
> +
> + '#size-cells':
> +const: 0
> +
> + port@0:
> +$ref: /schemas/graph.yaml#/$defs/port-base
> +unevaluatedProperties: false
> +description:
> + Output endpoint of the controller, connecting the LCD panel signals.
> +
> +properties:
> + '#address-cells':
> +const: 1
> +
> + '#size-cells':
> +const: 0
> +
> + reg:
> +maxItems: 1
> +
> + endpoint:
> +$ref: /schemas/graph.yaml#/$defs/endpoint
$ref: /schemas/media/video-interfaces.yaml#
to match approximately all other endpoints?
> +unevaluatedProperties: false
> +description:
> + Endpoint connecting the LCD panel signals.
> +
> +properties:
> + bus-width:
> +description: Endpoint bus width.
> +$ref: /schemas/media/video-interfaces.yaml#
and then bus-width's type is already defined for you, no?
> +enum: [ 12, 16, 18, 24 ]
> +
> +required:
> + - '#address-cells'
> + - '#size-cells'
> + - compatible
> + - port@0
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +//Example 1
> +
> +display-controller {
> + compatible = "atmel,hlcdc-display-controller";
> + pinctrl-names = "default";
> + pinctrl-0 = <_lcd_base _lcd_rgb888>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +reg = <0>;
> +
> +hlcdc_panel_output: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <_input>;
> +};
> + };
> +};
> +
> + - |
> +//Example 2 With a video interface override to force rgb565, bus-width=16
> +
> +display-controller {
> + compatible = "atmel,hlcdc-display-controller";
> + pinctrl-names = "default";
> + pinctrl-0 = <_lcd_base _lcd_rgb565>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +reg = <0>;
Should be a newline here before the child node.
Cheers,
Conor.
> +hlcdc_panel_output2: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <_input>;
> + bus-width = <16>;
> +};
> + };
> +};
> diff --git a/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt
> b/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt
> deleted file mode 100644
> index
Re: [PATCH v2 1/2] dt-bindings: display: panel: panel-simple: Add compatible property for waveshare 7inch touchscreen panel
On Tue, Jan 16, 2024 at 09:40:21AM +, Shengyang Chen wrote: > Hi, Conor > > Thanks for comment. > > > -Original Message----- > > From: Conor Dooley > > Sent: 2024年1月10日 0:32 > > To: Shengyang Chen > > Cc: devicet...@vger.kernel.org; dri-devel@lists.freedesktop.org; > > neil.armstr...@linaro.org; quic_jessz...@quicinc.com; s...@ravnborg.org; > > airl...@gmail.com; dan...@ffwll.ch; maarten.lankho...@linux.intel.com; > > mrip...@kernel.org; tzimmerm...@suse.de; robh...@kernel.org; > > krzysztof.kozlowski...@linaro.org; conor...@kernel.org; wahre...@gmx.net; > > dave.steven...@raspberrypi.com; thierry.red...@gmail.com; Changhuang > > Liang ; Keith Zhao > > ; Jack Zhu ; > > linux-ker...@vger.kernel.org > > Subject: Re: [PATCH v2 1/2] dt-bindings: display: panel: panel-simple: Add > > compatible property for waveshare 7inch touchscreen panel > > > > On Tue, Jan 09, 2024 at 03:09:48PM +0800, Shengyang Chen wrote: > > > The waveshare 7" 800x480 panel is a clone of Raspberry Pi 7" 800x480 > > > panel It can be drived by Raspberry Pi panel's process but it needs > > > different timing from Raspberry Pi panel. Add compatible property for it. > > > > > > Signed-off-by: Keith Zhao > > > Signed-off-by: Shengyang Chen > > > --- > > > .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ > > > 1 file changed, 2 insertions(+) > > > > > > diff --git > > > a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > > > b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > > > index 11422af3477e..02f6b1b2ddc9 100644 > > > --- > > > a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > > > +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yam > > > +++ l > > > @@ -335,6 +335,8 @@ properties: > > >- vivax,tpc9150-panel > > > # VXT 800x480 color TFT LCD panel > > >- vxt,vl050-8048nt-c01 > > > +# Waveshare 7" (800x480) touchscreen LCD panel > > > + - waveshare,7inch-touchscreen > > > > Is "7inch-touchscreen" really a specific enough identifier for this device? > > > > Referring to official website[1] and Neil's suggestion, maybe I should change > to > "7inch-touchscreen-dsi-lcd" or "waveshare,7inch-dsi-sku19885" if the next > patch version is needed. The one with the sku certainly seems more specific, if a next version is needed I would use that. Thanks, Conor. signature.asc Description: PGP signature
Re: [PATCH 1/2] dt-bindings: display: ti,am65x-dss: Add support for common1 region
On Tue, Jan 16, 2024 at 02:43:25PM +0530, Devarsh Thakkar wrote: > Hi Conor, > > Thanks for the review. > > On 15/01/24 21:47, Conor Dooley wrote: > > On Mon, Jan 15, 2024 at 06:27:15PM +0530, Devarsh Thakkar wrote: > >> TI keystone display subsystem present in AM65 and other SoCs such as AM62 > > > > Do all 3 SoCs supported by this binding (am625 am62a7 am65x) have this > > common1 register? If not, you should limit it the platforms that do have > > it. > > > > Yes all 3 SoCs supported by binding have common1 register space supported. Okay, thanks. Acked-by: Conor Dooley Cheers, Conor. signature.asc Description: PGP signature
Re: [DO NOT MERGE PATCH 2/2] arm64: dts: ti: Add common1 register space for AM62x and AM65x SoCs
On Tue, Jan 16, 2024 at 02:48:53PM +0530, Devarsh Thakkar wrote: > Hi Conor, > > Thanks for the review. > > On 15/01/24 21:44, Conor Dooley wrote: > > On Mon, Jan 15, 2024 at 06:27:16PM +0530, Devarsh Thakkar wrote: > >> This adds common1 register space for AM62x and AM65x SoC's which are using > >> TI's Keystone display hardware and supporting it as described in > >> Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml. > >> > >> This region is documented in respective Technical Reference Manuals [1]. > >> > >> [1]: > >> AM62x TRM: > >> https://www.ti.com/lit/pdf/spruiv7 (Section 14.8.9.1 DSS Registers) > >> > >> AM65x TRM: > >> https://www.ti.com/lit/pdf/spruid7 (Section 12.6.5 DSS Registers) > >> > >> Signed-off-by: Devarsh Thakkar > >> --- > > > > "[DO NOT MERGE PATCH 2/2]" but no rationale here as to why this cannot > > be merged? What's the problem with it? > > > > No problem as such from my point of view, but this is the process I follow > since maintainer trees for device-tree file and bindings are different. I > generally mark a [DO NOT MERGE] tag for device-tree file patches until binding > patch gets merged so that the device-tree patches don't get applied by mistake > if binding patch has some pending comments. > > Once binding patch gets merged, I re-send the device-tree file patches again > to respective list. I see. Please note this in your patches, under the --- line, in the future to avoid confusion. signature.asc Description: PGP signature
Re: [PATCH 1/2] dt-bindings: display: ti,am65x-dss: Add support for common1 region
On Mon, Jan 15, 2024 at 06:27:15PM +0530, Devarsh Thakkar wrote: > TI keystone display subsystem present in AM65 and other SoCs such as AM62 Do all 3 SoCs supported by this binding (am625 am62a7 am65x) have this common1 register? If not, you should limit it the platforms that do have it. Thanks, Conor. > support two separate register spaces namely "common" and "common1" which > can be used by two separate hosts to program the display controller as > described in respective Technical Reference Manuals [1]. > > The common1 register space has similar set of configuration registers as > supported in common register space except the global configuration > registers which are exclusive to common region. > > This adds binding for "common1" register region too as supported by the > hardware. > > [1]: > AM62x TRM: > https://www.ti.com/lit/pdf/spruiv7 (Section 14.8.9.1 DSS Registers) > > AM65x TRM: > https://www.ti.com/lit/pdf/spruid7 (Section 12.6.5 DSS Registers) > > Signed-off-by: Devarsh Thakkar > --- > .../devicetree/bindings/display/ti/ti,am65x-dss.yaml | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml > b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml > index b6767ef0d24d..55e3e490d0e6 100644 > --- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml > +++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml > @@ -37,6 +37,7 @@ properties: >- description: OVR2 overlay manager for vp2 >- description: VP1 video port 1 >- description: VP2 video port 2 > + - description: common1 DSS register area > >reg-names: > items: > @@ -47,6 +48,7 @@ properties: >- const: ovr2 >- const: vp1 >- const: vp2 > + - const: common1 > >clocks: > items: > @@ -147,9 +149,10 @@ examples: > <0x04a07000 0x1000>, /* ovr1 */ > <0x04a08000 0x1000>, /* ovr2 */ > <0x04a0a000 0x1000>, /* vp1 */ > -<0x04a0b000 0x1000>; /* vp2 */ > +<0x04a0b000 0x1000>, /* vp2 */ > +<0x04a01000 0x1000>; /* common1 */ > reg-names = "common", "vidl1", "vid", > -"ovr1", "ovr2", "vp1", "vp2"; > +"ovr1", "ovr2", "vp1", "vp2", "common1"; > ti,am65x-oldi-io-ctrl = <_oldi_io_ctrl>; > power-domains = <_pds 67 TI_SCI_PD_EXCLUSIVE>; > clocks =<_clks 67 1>, > -- > 2.34.1 > signature.asc Description: PGP signature
Re: [DO NOT MERGE PATCH 2/2] arm64: dts: ti: Add common1 register space for AM62x and AM65x SoCs
On Mon, Jan 15, 2024 at 06:27:16PM +0530, Devarsh Thakkar wrote:
> This adds common1 register space for AM62x and AM65x SoC's which are using
> TI's Keystone display hardware and supporting it as described in
> Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml.
>
> This region is documented in respective Technical Reference Manuals [1].
>
> [1]:
> AM62x TRM:
> https://www.ti.com/lit/pdf/spruiv7 (Section 14.8.9.1 DSS Registers)
>
> AM65x TRM:
> https://www.ti.com/lit/pdf/spruid7 (Section 12.6.5 DSS Registers)
>
> Signed-off-by: Devarsh Thakkar
> ---
"[DO NOT MERGE PATCH 2/2]" but no rationale here as to why this cannot
be merged? What's the problem with it?
Cheers,
Conor.
> arch/arm64/boot/dts/ti/k3-am62-main.dtsi | 5 +++--
> arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 5 +++--
> 2 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
> b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
> index 464b7565d085..298bf8d5de8c 100644
> --- a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
> @@ -779,9 +779,10 @@ dss: dss@3020 {
> <0x00 0x30207000 0x00 0x1000>, /* ovr1 */
> <0x00 0x30208000 0x00 0x1000>, /* ovr2 */
> <0x00 0x3020a000 0x00 0x1000>, /* vp1: Used for OLDI */
> - <0x00 0x3020b000 0x00 0x1000>; /* vp2: Used as DPI Out */
> + <0x00 0x3020b000 0x00 0x1000>, /* vp2: Used as DPI Out */
> + <0x00 0x30201000 0x00 0x1000>; /* common1 */
> reg-names = "common", "vidl1", "vid",
> - "ovr1", "ovr2", "vp1", "vp2";
> + "ovr1", "ovr2", "vp1", "vp2", "common1";
> power-domains = <_pds 186 TI_SCI_PD_EXCLUSIVE>;
> clocks = <_clks 186 6>,
><_vp1_clk>,
> diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> index fcea54465636..5b2d4365b911 100644
> --- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> @@ -1019,9 +1019,10 @@ dss: dss@4a0 {
> <0x0 0x04a07000 0x0 0x1000>, /* ovr1 */
> <0x0 0x04a08000 0x0 0x1000>, /* ovr2 */
> <0x0 0x04a0a000 0x0 0x1000>, /* vp1 */
> - <0x0 0x04a0b000 0x0 0x1000>; /* vp2 */
> + <0x0 0x04a0b000 0x0 0x1000>, /* vp2 */
> + <0x0 0x04a01000 0x0 0x1000>; /* common1 */
> reg-names = "common", "vidl1", "vid",
> - "ovr1", "ovr2", "vp1", "vp2";
> + "ovr1", "ovr2", "vp1", "vp2", "common1";
>
> ti,am65x-oldi-io-ctrl = <_oldi_io_ctrl>;
>
> --
> 2.34.1
>
signature.asc
Description: PGP signature
Re: [DO NOT MERGE v6 26/37] dt-bindings: vendor-prefixes: Add smi
On Wed, Jan 10, 2024 at 12:23:37PM +0100, Geert Uytterhoeven wrote: > Hi Conor, > > On Tue, Jan 9, 2024 at 7:06 PM Conor Dooley wrote: > > On Tue, Jan 09, 2024 at 05:23:23PM +0900, Yoshinori Sato wrote: > > > Add Silicon Mortion Technology Corporation > > Motion > > > > https://www.siliconmotion.com/ > > > > > > Signed-off-by: Yoshinori Sato > > > --- > > > 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 94ed63d9f7de..a338bdd743ab 100644 > > > --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml > > > +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml > > > @@ -1283,6 +1283,8 @@ patternProperties: > > > description: Skyworks Solutions, Inc. > > >"^smartlabs,.*": > > > description: SmartLabs LLC > > > + "^smi,.*": > > > +description: Silicon Motion Technology Corporation > > > > How come "smi" is used for a company with this name? > > Why is it not something like SMTC? There's probably some history here > > that I am unaware of. > > See Documentation/devicetree/bindings/display/sm501fb.txt > The stock ticker is "SIMO", though. > https://www.nasdaq.com/market-activity/stocks/simo If there's an existing user, there's little reason to stand in the way I think. Acked-by: Conor Dooley Cheers, Conor. signature.asc Description: PGP signature
Re: [PATCH 2/3] arch and include: Update LLVM Phabricator links
On Tue, Jan 09, 2024 at 03:16:30PM -0700, Nathan Chancellor wrote: > reviews.llvm.org was LLVM's Phabricator instances for code review. It > has been abandoned in favor of GitHub pull requests. While the majority > of links in the kernel sources still work because of the work Fangrui > has done turning the dynamic Phabricator instance into a static archive, > there are some issues with that work, so preemptively convert all the > links in the kernel sources to point to the commit on GitHub. > > Most of the commits have the corresponding differential review link in > the commit message itself so there should not be any loss of fidelity in > the relevant information. > > Link: https://discourse.llvm.org/t/update-on-github-pull-requests/71540/172 > Signed-off-by: Nathan Chancellor > --- > arch/riscv/Kconfig | 2 +- > arch/riscv/include/asm/ftrace.h | 2 +- Reviewed-by: Conor Dooley Cheers, Conor. signature.asc Description: PGP signature
Re: [DO NOT MERGE v6 27/37] dt-bindings: ata: ata-generic: Add new targets
On Tue, Jan 09, 2024 at 06:07:19PM +, Conor Dooley wrote: > On Tue, Jan 09, 2024 at 05:23:24PM +0900, Yoshinori Sato wrote: > > Added new ata-generic target. > > - iodata,usl-5p-ata > > - renesas,rts7751r2d-ata > > > > Each boards have simple IDE Interface. Use ATA generic driver. > > > > Signed-off-by: Yoshinori Sato > > Acked-by: Conor Dooley That said, a bullet point list in the commit message of what compatibles you added isn't really achieving anything, you can drop that from the commit message if/when you resend the series. > > Cheers, > Conor. > > > --- > > Documentation/devicetree/bindings/ata/ata-generic.yaml | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/ata/ata-generic.yaml > > b/Documentation/devicetree/bindings/ata/ata-generic.yaml > > index 0697927f3d7e..1025b3b351d0 100644 > > --- a/Documentation/devicetree/bindings/ata/ata-generic.yaml > > +++ b/Documentation/devicetree/bindings/ata/ata-generic.yaml > > @@ -18,6 +18,8 @@ properties: > >- enum: > >- arm,vexpress-cf > >- fsl,mpc8349emitx-pata > > + - iodata,usl-5p-ata > > + - renesas,rts7751r2d-ata > >- const: ata-generic > > > >reg: > > -- > > 2.39.2 > > signature.asc Description: PGP signature
Re: [DO NOT MERGE v6 27/37] dt-bindings: ata: ata-generic: Add new targets
On Tue, Jan 09, 2024 at 05:23:24PM +0900, Yoshinori Sato wrote: > Added new ata-generic target. > - iodata,usl-5p-ata > - renesas,rts7751r2d-ata > > Each boards have simple IDE Interface. Use ATA generic driver. > > Signed-off-by: Yoshinori Sato Acked-by: Conor Dooley Cheers, Conor. > --- > Documentation/devicetree/bindings/ata/ata-generic.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/ata/ata-generic.yaml > b/Documentation/devicetree/bindings/ata/ata-generic.yaml > index 0697927f3d7e..1025b3b351d0 100644 > --- a/Documentation/devicetree/bindings/ata/ata-generic.yaml > +++ b/Documentation/devicetree/bindings/ata/ata-generic.yaml > @@ -18,6 +18,8 @@ properties: >- enum: >- arm,vexpress-cf >- fsl,mpc8349emitx-pata > + - iodata,usl-5p-ata > + - renesas,rts7751r2d-ata >- const: ata-generic > >reg: > -- > 2.39.2 > signature.asc Description: PGP signature
Re: [DO NOT MERGE v6 26/37] dt-bindings: vendor-prefixes: Add smi
On Tue, Jan 09, 2024 at 05:23:23PM +0900, Yoshinori Sato wrote: > Add Silicon Mortion Technology Corporation > https://www.siliconmotion.com/ > > Signed-off-by: Yoshinori Sato > --- > 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 94ed63d9f7de..a338bdd743ab 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml > +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml > @@ -1283,6 +1283,8 @@ patternProperties: > description: Skyworks Solutions, Inc. >"^smartlabs,.*": > description: SmartLabs LLC > + "^smi,.*": > +description: Silicon Motion Technology Corporation How come "smi" is used for a company with this name? Why is it not something like SMTC? There's probably some history here that I am unaware of. Cheers, Conor. >"^smsc,.*": > description: Standard Microsystems Corporation >"^snps,.*": > -- > 2.39.2 > signature.asc Description: PGP signature
Re: [DO NOT MERGE v6 25/37] dt-bindings: vendor-prefixes: Add iodata
On Tue, Jan 09, 2024 at 05:23:22PM +0900, Yoshinori Sato wrote: > Add IO DATA DEVICE INC. > https://www.iodata.com/ > > Signed-off-by: Yoshinori Sato I think you are missing an r-b tag here from Geert: https://lore.kernel.org/all/camuhmduvnt1tdtoq4ppqn69cocaeveaxrsol2vq2efbq+hv...@mail.gmail.com/ Acked-by: Conor Dooley Cheers, Conor. > --- > 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 309b94c328c8..94ed63d9f7de 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml > +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml > @@ -671,6 +671,8 @@ patternProperties: > description: Inventec >"^inversepath,.*": > description: Inverse Path > + "^iodata,.*": > +description: IO DATA DEVICE Inc. >"^iom,.*": > description: Iomega Corporation >"^irondevice,.*": > -- > 2.39.2 > signature.asc Description: PGP signature
Re: [DO NOT MERGE v6 24/37] dt-binding: sh: cpus: Add SH CPUs json-schema
Yo,
On Tue, Jan 09, 2024 at 05:23:21PM +0900, Yoshinori Sato wrote:
> Renesas SH series and compatible ISA CPUs.
>
> Signed-off-by: Yoshinori Sato
> ---
> .../devicetree/bindings/sh/cpus.yaml | 74 +++
> 1 file changed, 74 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 ..c04f897d2c2a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sh/cpus.yaml
> @@ -0,0 +1,74 @@
> +# 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: |+
> + The device tree allows to describe the layout of CPUs in a system through
> + the "cpus" node, which in turn contains a number of subnodes (ie "cpu")
> + defining properties for every cpu.
> +
> + Bindings for CPU nodes follow the Devicetree Specification, available from:
> +
> + https://www.devicetree.org/specifications/
You likely copied this description from the arm binding (or from
dt-schema), but I don't think this is anything other than a statement of
the obvious. If there is a description here it should (IMO) talk about
the superh cpus.
> +
> +properties:
> + compatible:
> +anyOf:
> + - items:
> + - enum:
> + - renesas,sh2a
> + - renesas,sh3
> + - renesas,sh4
> + - renesas,sh4a
> + - jcore,j2
> + - const: renesas,sh2
> + - const: renesas,sh2
> +
> + clock-frequency:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: CPU core clock frequency.
What is the point of this? You have a clocks property, can't you obtain
the clock frequency by looking up the provider of that clock?
> +
> + clocks:
> +maxItems: 1
> +
> + clock-names: true
Why do you need clock-names if you only have one clock?
> +
> + reg:
> +maxItems: 1
> +
> + device_type: true
> +
> +required:
> + - compatible
> + - reg
> + - device_type
> +
> +additionalProperties: true
This should be unevaluatedProperties: false
Properties like the icache-size are documented in cpu.yaml and
you can add an reference to that to permit them. The riscv cpus binding
does this if you need to see how that works.
Cheers,
Conor.
> +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
>
signature.asc
Description: PGP signature
Re: [PATCH v2 1/2] dt-bindings: display: panel: panel-simple: Add compatible property for waveshare 7inch touchscreen panel
On Tue, Jan 09, 2024 at 03:09:48PM +0800, Shengyang Chen wrote: > The waveshare 7" 800x480 panel is a clone of Raspberry Pi 7" 800x480 panel > It can be drived by Raspberry Pi panel's process but it needs different > timing from Raspberry Pi panel. Add compatible property for it. > > Signed-off-by: Keith Zhao > Signed-off-by: Shengyang Chen > --- > .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > index 11422af3477e..02f6b1b2ddc9 100644 > --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > @@ -335,6 +335,8 @@ properties: >- vivax,tpc9150-panel > # VXT 800x480 color TFT LCD panel >- vxt,vl050-8048nt-c01 > +# Waveshare 7" (800x480) touchscreen LCD panel > + - waveshare,7inch-touchscreen Is "7inch-touchscreen" really a specific enough identifier for this device? > # Winstar Display Corporation 3.5" QVGA (320x240) TFT LCD panel >- winstar,wf35ltiacd > # Yes Optoelectronics YTC700TLAG-05-201C 7" TFT LCD panel > -- > 2.17.1 > signature.asc Description: PGP signature
Re: [PATCH 1/2] dt-bindings: display: Add SSD133x OLED controllers
On Sun, Dec 17, 2023 at 11:00:07PM +0100, Javier Martinez Canillas wrote: > Conor Dooley writes: > > Hello Conor, > > > On Sun, Dec 17, 2023 at 10:33:24PM +0100, Javier Martinez Canillas wrote: > > [...] > > >> >> +then: > >> >> + properties: > >> >> +width: > >> >> + default: 96 > >> >> +height: > >> >> + default: 64 > >> > > >> > Do you envisage a rake of devices that are going to end up in this > >> > binding? Otherwise, why not unconditionally set the constraints? > >> > > >> > >> Because these are only for the default width and height, there can be > >> panels using the same controller but that have a different resolution. > >> > >> For example, there are panels using the SSD1306 controller that have > >> 128x32 [0], 64x32 [1] or 128x64 [2] resolutions. > > > > This, as you know, does not matter here. > > > > Are you sure? What I tried to say is that the SSD133x are just OLED > controllers and manufacturers use those chips to attach a panel that > has a certain resolution. > > While it makes sense to use all the supported width and height, some > manufacturers chose to have a smaller panel instead (I used SSD1306 > as an example because I knew about these but the same might be true > for let's say SSD1331). > > Or saying another way, are you sure that every manufacturer selling > RGB OLED panels using the SSD1331 chip will use the default resolution > and users won't have to set a custom width and height ? That's not at all what I was saying. I just meant unconditionally set the constraints on the property (in this case the default) since you only have one compatible. Not unconditionally set the height and width. Apologies if if that was unclear. Thanks, Conor. > I have already chosen to make the DT binding as simple as possible to > prevent what happened with the SSD1306 "solomon,page-offset" property > that has a broken default [0] but I think that not allowing to set the > resolution is already too restrictive and would make it unusable for > any panel that doesn't have the default width and height. > > [0]: > https://lists.freedesktop.org/archives/dri-devel/2023-November/431150.html > > >> But answering your question, yes I think that more devices for this > >> SSD133x family are going to be added later. Looking at [3], there is > >> at least SSD1333 that has a different default resolutions (176x176). > > > > That's fair enough though. I'd probably err on the side of introducing > > this complexity when the other users actually show up though. > > > > Agree and the reason why I did not include entries for the SSD1332 and > SSD1333. I was planning to add those only if there were users since it > seems that the SSD1331 is the most popular controller from this family. > > But as explained, even for the SSD1331 it may be needed to set a width > and height that is different than the default of this panel controller. > > -- > Best regards, > > Javier Martinez Canillas > Core Platforms > Red Hat > signature.asc Description: PGP signature
Re: [PATCH v2 1/2] dt-bindings: display: Add SSD133x OLED controllers
On Mon, Dec 18, 2023 at 02:20:35PM +0100, Javier Martinez Canillas wrote: > Add a Device Tree binding schema for the OLED panels based on the > Solomon SSD133x family of controllers. > > Signed-off-by: Javier Martinez Canillas > --- > > Changes in v2: > - Unconditionally set the width and height constraints (Conor Dooley). > - Fix indentation in the DTS examples (Krzysztof Kozlowski). > > .../bindings/display/solomon,ssd133x.yaml | 57 +++ > 1 file changed, 57 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/solomon,ssd133x.yaml > > diff --git a/Documentation/devicetree/bindings/display/solomon,ssd133x.yaml > b/Documentation/devicetree/bindings/display/solomon,ssd133x.yaml > new file mode 100644 > index ..8feee9eef0fd > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/solomon,ssd133x.yaml > @@ -0,0 +1,57 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/solomon,ssd133x.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Solomon SSD133x OLED Display Controllers > + > +maintainers: > + - Javier Martinez Canillas > + > +properties: > + compatible: > +enum: > + - solomon,ssd1331 > + > +required: > + - compatible > + - reg > + > +allOf: > + - $ref: solomon,ssd-common.yaml# > + > + - properties: > + width: > +default: 96 > + height: > +default: 64 diff --git a/Documentation/devicetree/bindings/display/solomon,ssd133x.yaml b/Documentation/devicetree/bindings/display/solomon,ssd133x.yaml index 8feee9eef0fd..ffc939c782eb 100644 --- a/Documentation/devicetree/bindings/display/solomon,ssd133x.yaml +++ b/Documentation/devicetree/bindings/display/solomon,ssd133x.yaml @@ -9,24 +9,24 @@ title: Solomon SSD133x OLED Display Controllers maintainers: - Javier Martinez Canillas +allOf: + - $ref: solomon,ssd-common.yaml# + properties: compatible: enum: - solomon,ssd1331 + width: +default: 96 + + height: +default: 64 + required: - compatible - reg -allOf: - - $ref: solomon,ssd-common.yaml# - - - properties: - width: -default: 96 - height: -default: 64 - unevaluatedProperties: false examples: The properties stuff doesn't need to be in the allOf. Although, I took the opportunity to look at ssd-common.yaml. How do the height/width here differ from the vendor prefixed versions in that file? signature.asc Description: PGP signature
Re: [PATCH 1/2] dt-bindings: display: Add SSD133x OLED controllers
On Sun, Dec 17, 2023 at 10:33:24PM +0100, Javier Martinez Canillas wrote: > Conor Dooley writes: > > Hello Connor, > > > On Sun, Dec 17, 2023 at 11:07:03AM +0100, Javier Martinez Canillas wrote: > > [...] > > >> +properties: > >> + compatible: > >> +enum: > >> + - solomon,ssd1331 > >> + > >> +required: > >> + - compatible > >> + - reg > >> + > >> +allOf: > >> + - $ref: solomon,ssd-common.yaml# > >> + > >> + - if: > >> + properties: > >> +compatible: > >> + contains: > >> +const: solomon,ssd1331 > >> +then: > >> + properties: > >> +width: > >> + default: 96 > >> +height: > >> + default: 64 > > > > Do you envisage a rake of devices that are going to end up in this > > binding? Otherwise, why not unconditionally set the constraints? > > > > Because these are only for the default width and height, there can be > panels using the same controller but that have a different resolution. > > For example, there are panels using the SSD1306 controller that have > 128x32 [0], 64x32 [1] or 128x64 [2] resolutions. This, as you know, does not matter here. > But answering your question, yes I think that more devices for this > SSD133x family are going to be added later. Looking at [3], there is > at least SSD1333 that has a different default resolutions (176x176). That's fair enough though. I'd probably err on the side of introducing this complexity when the other users actually show up though. > > I think that even the SSD135x family could be supported by the same > modsetting pipeline, but I need to get one to figure it out. > > [0]: https://es.aliexpress.com/item/1005003648174074.html > [1]: > https://www.buydisplay.com/white-0-49-inch-oled-display-64x32-iic-i2c-ssd1306-connector-fpc > [2]: https://es.aliexpress.com/item/1005001582340858.html?gatewayAdapt=glo2esp > [3]: https://www.solomon-systech.com/product-search/?technology=oled-display > > > Cheers, > > Conor. > > -- > Best regards, > > Javier Martinez Canillas > Core Platforms > Red Hat > signature.asc Description: PGP signature
Re: [PATCH 1/2] dt-bindings: display: Add SSD133x OLED controllers
On Sun, Dec 17, 2023 at 11:07:03AM +0100, Javier Martinez Canillas wrote: > Add a Device Tree binding schema for the OLED panels based on the > Solomon SSD133x family of controllers. > > Signed-off-by: Javier Martinez Canillas > --- > > .../bindings/display/solomon,ssd133x.yaml | 63 +++ > 1 file changed, 63 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/solomon,ssd133x.yaml > > diff --git a/Documentation/devicetree/bindings/display/solomon,ssd133x.yaml > b/Documentation/devicetree/bindings/display/solomon,ssd133x.yaml > new file mode 100644 > index ..eee8d8c9ca35 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/solomon,ssd133x.yaml > @@ -0,0 +1,63 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/solomon,ssd133x.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Solomon SSD133x OLED Display Controllers > + > +maintainers: > + - Javier Martinez Canillas > + > +properties: > + compatible: > +enum: > + - solomon,ssd1331 > + > +required: > + - compatible > + - reg > + > +allOf: > + - $ref: solomon,ssd-common.yaml# > + > + - if: > + properties: > +compatible: > + contains: > +const: solomon,ssd1331 > +then: > + properties: > +width: > + default: 96 > +height: > + default: 64 Do you envisage a rake of devices that are going to end up in this binding? Otherwise, why not unconditionally set the constraints? Cheers, Conor. signature.asc Description: PGP signature
Re: [PATCH 2/3] dt-bindings: lcdif: Decouple imx8mq from imx6sx
On Mon, Dec 11, 2023 at 05:41:37PM -0300, Fabio Estevam wrote: > From: Fabio Estevam > > On i.MX6SX, the LCDIF has an associated power domain. > > i.MX8MQ does not have an LCDIF power domain, so allow passing only > "fsl,imx8mq-lcdif" as compatible string to fix the following > dt-schema warning: > > imx8mq-evk.dtb: lcd-controller@3032: 'power-domains' is a required > property > from schema $id: http://devicetree.org/schemas/display/fsl,lcdif.yaml# > > Signed-off-by: Fabio Estevam Acked-by: Conor Dooley Cheers, Conor. signature.asc Description: PGP signature
Re: [PATCH v1 1/2] dt-bindings: display: panel: raspberrypi: Add compatible property for waveshare 7inch touchscreen panel
On Thu, Dec 07, 2023 at 11:48:56AM +0800, Shengyang Chen wrote: > Hi, Conor > > thanks for comment > > On 2023/12/6 23:40, Conor Dooley wrote: > > On Wed, Dec 06, 2023 at 05:43:48PM +0800, Shengyang Chen wrote: > >> Hi, Conor > >> > >> On 2023/11/24 20:31, Conor Dooley wrote: > >> > On Fri, Nov 24, 2023 at 06:44:50PM +0800, Shengyang Chen wrote: > >> >> The waveshare 7inch touchscreen panel is a kind of raspberrypi pi > >> >> panel > >> > > >> > Can you be more specific about what "is a kind of rpi panel" means? > >> > Are they using identical chips as controllers or something like that? > >> > > >> > >> Wareshare panel has same i2c slave address and registers address with > >> the original raspberry pi panel. They both use Atmel firmware and they > >> got same reg id. It can be operated by using the driver of raspberry pi > >> driver > >> after some change of the code. So I suppose it may be a kind of raspberry > >> pi panel > >> and discribe it in this way. It's my own judgement. Sorry about that. > >> Maybe just like Dave said, It cloned the behaviour of the raspberri pi > >> panel. > >> I will change the discribtion in next version to not make other confused. > >> > >> By the way, we will try Stefan's method before next version. > >> The method we used in this patch may be abandoned if Stefan's method is > >> verified in our platform. > >> At that time yaml may also be changed to fit new method. > > > > I don't know what Stefan's approach is, but I do not think that a > > bindings patch should be dropped. The waveshare might be a clone, but it > > is a distinct device. If the same driver can control both, then the > > compatible setups that should be permitted are: > > compatible = "raspberrypi,7inch-touchscreen-panel"; > > and > > compatible = "waveshare,7inch-touchscreen-panel", > > "raspberrypi,7inch-touchscreen-panel"; > If we use Stenfan's method, we can reuse the code of panel-simple.c > we may submit our patch to > /Documentation/devicetree/bindings/display/panel/panel-simple.yaml > /drivers/gpu/drm/panel/panel-simple.c > as a new panel porting. That may less confuse. As long as you provide a specific compatible, and not re-use the rpi one, that's fine. It just sounded like you were intending to reuse that here, but from this message it seems like I misunderstood. Thanks, Conor. signature.asc Description: PGP signature
Re: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
On Tue, Dec 05, 2023 at 07:04:05PM +0100, H. Nikolaus Schaller wrote:
> > Am 05.12.2023 um 18:33 schrieb Andrew Davis :
> >
> > On 12/5/23 2:17 AM, H. Nikolaus Schaller wrote:
> >>> + - enum:
> >>> + - ti,omap3430-gpu # Rev 121
> >>> + - ti,omap3630-gpu # Rev 125
> >> Is the "Rev 121" and "Rev 125" a property of the SoC integration
> >> (clock/reset/power
> >> hookup etc.) or of the integrated SGX core?
> >
> > The Rev is a property of the SGX core, not the SoC integration.
>
> Then, it should belong there and not be a comment of the ti,omap*-gpu record.
> In this way it does not seem to be a proper hardware description.
>
> BTW: there are examples where the revision is part of the compatible string,
> even
> if the (Linux) driver makes no use of it:
>
> drivers/net/ethernet/xilinx/xilinx_emaclite.c
AFAICT these Xilinx devices that put the revisions in the compatible are
a different case - they're "soft" IP intended for use in the fabric of
an FPGA, and assigning a device specific compatible there does not make
sense.
In this case it appears that the revision is completely known once you
see "ti,omap3630-gpu", so encoding the extra "121" into the compatible
string is not required.
>
> > But it seems that
> > compatible string is being used to define both (as we see being debated in
> > the other
> > thread on this series).
> >
> >> In my understanding the Revs are different variants of the SGX core (errata
> >> fixes, instruction set, pipeline size etc.). And therefore the current
> >> driver code
> >> has to be configured by some macros to handle such cases.
> >> So the Rev should IMHO be part of the next line:
> >>> + - const: img,powervr-sgx530
> >> + - enum:
> >> + - img,powervr-sgx530-121
> >> + - img,powervr-sgx530-125
> >> We have a similar definition in the openpvrsgx code.
> >> Example: compatible = "ti,omap3-sgx530-121", "img,sgx530-121",
> >> "img,sgx530";
> >> (I don't mind about the powervr- prefix).
> >> This would allow a generic and universal sgx driver (loaded through just
> >> matching
> >> "img,sgx530") to handle the errata and revision specifics at runtime based
> >> on the
> >> compatible entry ("img,sgx530-121") and know about SoC integration
> >> ("ti,omap3-sgx530-121").
The "raw" sgx530 compatible does not seem helpful if the sgx530-121 or
sgx530-125 compatibles are also required to be present for the driver to
actually function. The revision specific compatibles I would not object
to, but everything in here has different revisions anyway - does the
same revision actually appear in multiple devices? If it doesn't then I
don't see any value in the suffixed compatibles either.
> >> And user-space can be made to load the right firmware variant based on
> >> "img,sgx530-121"
> >> I don't know if there is some register which allows to discover the
> >> revision long
> >> before the SGX subsystem is initialized and the firmware is up and running.
> >> What I know is that it is possible to read out the revision after starting
> >> the firmware
> >> but it may just echo the version number of the firmware binary provided
> >> from user-space.
> >
> > We should be able to read out the revision (register EUR_CR_CORE_REVISION),
> > the problem is
> > today the driver is built for a given revision at compile time.
>
> Yes, that is something we had planned to get rid of for a long time by using
> different compatible
> strings and some variant specific struct like many others drivers are doing
> it.
> But it was a to big task so nobody did start with it.
>
> > That is a software issue,
> > not something that we need to encode in DT. While the core ID (SGX5xx) can
> > be also detected
> > (EUR_CR_CORE_ID), the location of that register changes, and so it does
> > need encoded in
> > DT compatible.
>
> Ok, I didn't know about such registers as there is not much public
> information available.
> Fair enough, there are some error reports about in different forums.
>
> On the other hand we then must read out this register in more or less early
> initialization
> stages. Even if we know this information to be static and it could be as
> simple as a list
> of compatible strings in the driver.
>
> > The string "ti,omap3430-gpu" tells us the revision if we cannot detect it
> > (as in the current
> > driver), and the SoC integration is generic anyway (just a reg and
> > interrupt).
>
> It of course tells, but may need a translation table that needs to be
> maintained in a
> different format. Basically the same what the comments show in a non-machine
> readable
> format.
>
> I just wonder why the specific version can or should not become simply part
> of the DTS
> and needs this indirection.
>
> Basically it is a matter of openness for future (driver) development and why
> it needs
> careful decisions.
>
> So in other words: I would prefer to see the comments about versions encoded
Re: [PATCH v1 1/2] dt-bindings: display: panel: raspberrypi: Add compatible property for waveshare 7inch touchscreen panel
On Wed, Dec 06, 2023 at 05:43:48PM +0800, Shengyang Chen wrote: > Hi, Conor > > On 2023/11/24 20:31, Conor Dooley wrote: > > On Fri, Nov 24, 2023 at 06:44:50PM +0800, Shengyang Chen wrote: > >> The waveshare 7inch touchscreen panel is a kind of raspberrypi pi > >> panel > > > > Can you be more specific about what "is a kind of rpi panel" means? > > Are they using identical chips as controllers or something like that? > > > > Wareshare panel has same i2c slave address and registers address with > the original raspberry pi panel. They both use Atmel firmware and they > got same reg id. It can be operated by using the driver of raspberry pi driver > after some change of the code. So I suppose it may be a kind of raspberry pi > panel > and discribe it in this way. It's my own judgement. Sorry about that. > Maybe just like Dave said, It cloned the behaviour of the raspberri pi panel. > I will change the discribtion in next version to not make other confused. > > By the way, we will try Stefan's method before next version. > The method we used in this patch may be abandoned if Stefan's method is > verified in our platform. > At that time yaml may also be changed to fit new method. I don't know what Stefan's approach is, but I do not think that a bindings patch should be dropped. The waveshare might be a clone, but it is a distinct device. If the same driver can control both, then the compatible setups that should be permitted are: compatible = "raspberrypi,7inch-touchscreen-panel"; and compatible = "waveshare,7inch-touchscreen-panel", "raspberrypi,7inch-touchscreen-panel"; Cheers, Conor. > >> and it can be drived by panel-raspberrypi-touchscreen.c. > >> Add compatible property for it. > >> > >> Signed-off-by: Keith Zhao > >> Signed-off-by: Shengyang Chen > >> --- > >> .../bindings/display/panel/raspberrypi,7inch-touchscreen.yaml | 4 +++- > >> 1 file changed, 3 insertions(+), 1 deletion(-) > >> > >> diff --git > >> a/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.yaml > >> > >> b/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.yaml > >> index 22a083f7bc8e..e4e6cb4d4e5b 100644 > >> --- > >> a/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.yaml > >> +++ > >> b/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.yaml > >> @@ -22,7 +22,9 @@ description: |+ > >> > >> properties: > >>compatible: > >> -const: raspberrypi,7inch-touchscreen-panel > >> +enum: > >> + - raspberrypi,7inch-touchscreen-panel > >> + - waveshare,7inch-touchscreen-panel > >> > >>reg: > >> const: 0x45 > >> -- > >> 2.17.1 > >> > > > thanks. > > Best Regards, > Shengyang > signature.asc Description: PGP signature
Re: [PATCH v2] dt-bindings: lcdif: Properly describe the i.MX23 interrupts
On Wed, Dec 06, 2023 at 08:23:37AM -0300, Fabio Estevam wrote: > From: Fabio Estevam > > i.MX23 has two LCDIF interrupts instead of a single one like other > i.MX devices. > > Take this into account for properly describing the i.MX23 LCDIF > interrupts. > > This fixes the following dt-schema warning: > > imx23-olinuxino.dtb: lcdif@8003: interrupts: [[46], [45]] is too long > from schema $id: http://devicetree.org/schemas/display/fsl,lcdif.yaml# > > Signed-off-by: Fabio Estevam > Reviewed-by: Marek Vasut Acked-by: Conor Dooley Thanks, Conor. signature.asc Description: PGP signature
Re: [PATCH v1 1/3] dt-bindings: drm: rockchip: convert inno_hdmi-rockchip.txt to yaml
On Mon, Dec 04, 2023 at 09:47:15PM +0100, Johan Jonker wrote: > On 12/4/23 19:56, Alex Bee wrote: > > Am 04.12.23 um 18:39 schrieb Johan Jonker: > >> diff --git > >> a/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml > >> > >> b/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml > >> new file mode 100644 > >> index ..96889c86849a > >> --- /dev/null > >> +++ > >> b/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml > >> @@ -0,0 +1,103 @@ > >> +# SPDX-License-Identifier: GPL-2.0 > >> +%YAML 1.2 > >> +--- > >> +$id: > >> http://devicetree.org/schemas/display/rockchip/rockchip,inno-hdmi.yaml# > >> +$schema: http://devicetree.org/meta-schemas/core.yaml# > >> + > >> +title: Rockchip Innosilicon HDMI controller > >> + > >> +maintainers: > >> + - Sandy Huang > >> + - Heiko Stuebner > >> + > >> +properties: > >> + compatible: > >> + enum: > >> + - rockchip,rk3036-inno-hdmi > >> + > >> + reg: > >> + maxItems: 1 > >> + > >> + interrupts: > >> + maxItems: 1 > >> + > >> + clocks: > >> + maxItems: 1 > > > The interrupts/clock description exists already in the txt-bindings - so > > how about: > > > > + items: > > + - descrition: > >> + > > It's not common to do so when there's only one clock and nothing special to > mention. > Used this style for most of my conversions. > Further rational might be given by Krzysztof and co. Ye, when there is no ambiguity, having the description is not required. signature.asc Description: PGP signature
Re: [PATCH 1/2] dt-bindings: display: simple: Add boe,bp082wx1-100 8.2" panel
On Sat, Dec 02, 2023 at 10:11:52AM +0200, Tony Lindgren wrote: > This panel is found on Motorola mapphone tablets mz607 to mz609. Acked-by: Conor Dooley Cheers, Conor. > > Signed-off-by: Tony Lindgren > --- > .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > @@ -73,6 +73,8 @@ properties: >- auo,t215hvn01 > # Shanghai AVIC Optoelectronics 7" 1024x600 color TFT-LCD panel >- avic,tm070ddh03 > +# BOE BP082WX1-100 8.2" WXGA (1280x800) LVDS panel > + - boe,bp082wx1-100 > # BOE BP101WX1-100 10.1" WXGA (1280x800) LVDS panel >- boe,bp101wx1-100 > # BOE EV121WXM-N10-1850 12.1" WXGA (1280x800) TFT LCD panel > -- > 2.43.0 signature.asc Description: PGP signature
Re: [PATCH 3/3] drm/amd/display: Support DRM_AMD_DC_FP on RISC-V
On Wed, Nov 29, 2023 at 05:42:24PM -0700, Nathan Chancellor wrote:
> On Thu, Nov 23, 2023 at 02:23:01PM +0000, Conor Dooley wrote:
> > On Tue, Nov 21, 2023 at 07:05:15PM -0800, Samuel Holland wrote:
> > > RISC-V uses kernel_fpu_begin()/kernel_fpu_end() like several other
> > > architectures. Enabling hardware FP requires overriding the ISA string
> > > for the relevant compilation units.
> >
> > Ah yes, bringing the joy of frame-larger-than warnings to RISC-V:
> > ../drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_32.c:58:13:
> > warning: stack frame size (2416) exceeds limit (2048) in
> > 'DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerformanceCalculation'
> > [-Wframe-larger-than]
>
> :(
>
> > Nathan, have you given up on these being sorted out?
>
> Does your configuration have KASAN (I don't think RISC-V supports
> KCSAN)? It is possible that dml/dcn32 needs something similar to commit
> 6740ec97bcdb ("drm/amd/display: Increase frame warning limit with KASAN
> or KCSAN in dml2")?
It's from allmodconfig, so yes, I think so.
signature.asc
Description: PGP signature
Re: [PATCH] dt-bindings: mxsfb: Remove power-domains requirements for i.MX7D
On Mon, Nov 27, 2023 at 04:35:56PM +0100, Roland Hieber wrote:
> From: Philipp Zabel
>
> i.MX7D is documented as compatible with i.MX6SX, but it doesn't have the
> power-domain requirement. Limit the i.MX6SX power-domains requirement to
> i.MX6SX only.
I dont like this commit message tbh, I shouldn't have to go and dig out the
file to be able to understand what you are doing here - it should really be
explained that the imx7d falls back to the imx6sx, as otherwise this looks
like nothing at all to do with with imx7d.
Thanks,
Conor.
>
> Fixes: f62678a77d58 ("dt-bindings: mxsfb: Document i.MX8M/i.MX6SX/i.MX6SL
> power-domains property")
> Signed-off-by: Philipp Zabel
> Signed-off-by: Roland Hieber
> ---
> Documentation/devicetree/bindings/display/fsl,lcdif.yaml | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> index fc11ab5fc465..83532959e51c 100644
> --- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> +++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> @@ -117,13 +117,19 @@ allOf:
>maxItems: 1
> clock-names:
>maxItems: 1
> + - if:
> + properties:
> +compatible:
> + const: fsl,imx6sx-lcdif
> +then:
> + required:
> +- power-domains
>- if:
>properties:
> compatible:
>contains:
> enum:
>- fsl,imx6sl-lcdif
> - - fsl,imx6sx-lcdif
>- fsl,imx8mm-lcdif
>- fsl,imx8mn-lcdif
>- fsl,imx8mp-lcdif
>
> ---
> base-commit: 2cc14f52aeb78ce3f29677c2de1f06c0e91471ab
> change-id: 20231127-b4-dt-bindings-mxsfb-9a0676d08b4c
>
> Best regards,
> --
> Roland Hieber, Pengutronix e.K. | r...@pengutronix.de |
> Steuerwalder Str. 21 | https://www.pengutronix.de/ |
> 31137 Hildesheim, Germany| Phone: +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
>
>
signature.asc
Description: PGP signature
