Re: [PATCH 08/10] dt-bindings: vendor-prefixes: Add AYN Technologies
On Wed, Apr 24, 2024 at 11:29:13PM +0800, Xilin Wu wrote: > Add an entry for AYN Technologies (https://www.ayntec.com/) > > Signed-off-by: Xilin Wu > --- > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml > b/Documentation/devicetree/bindings/vendor-prefixes.yaml > index e4aeeb5fe4d1..c2365b0f4184 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml > +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml > @@ -194,6 +194,8 @@ patternProperties: > description: Axentia Technologies AB >"^axis,.*": > description: Axis Communications AB > + "^ayn,.*": It is somewhat preferred to use the domain name (ayntec). > +description: AYN Technologies Co., Ltd. >"^azoteq,.*": > description: Azoteq (Pty) Ltd >"^azw,.*": > > -- > 2.44.0 >
Re: [PATCH 03/10] dt-bindings: display: panel: Add Synaptics TD4328
On Wed, Apr 24, 2024 at 11:29:08PM +0800, Xilin Wu wrote:
> Synaptics TD4328 is a display driver IC used to drive LCD DSI panels.
>
> Signed-off-by: Xilin Wu
> ---
> .../bindings/display/panel/synaptics,td4328.yaml | 69
> ++
> 1 file changed, 69 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/synaptics,td4328.yaml
> b/Documentation/devicetree/bindings/display/panel/synaptics,td4328.yaml
> new file mode 100644
> index ..216f2fb22b88
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/synaptics,td4328.yaml
> @@ -0,0 +1,69 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/synaptics,td4328.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Synaptics TD4328-based DSI display panels
> +
> +maintainers:
> + - Xilin Wu
> +
> +description:
> + The Synaptics TD4328 is a generic DSI Panel IC used to control
> + LCD panels.
> +
> +allOf:
> + - $ref: panel-common.yaml#
> +
> +properties:
> + compatible:
> +contains:
> + const: syna,td4328
You need a compatible specific to a panel. This can be a fallback
though.
> +
> + vdd-supply:
> +description: Digital voltage rail
> +
> + vddio-supply:
> +description: Digital I/O voltage rail
> +
> + reg: true
> + port: true
> +
> +required:
> + - compatible
> + - reg
> + - reset-gpios
> + - vdd-supply
> + - vddio-supply
> + - port
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> +#include
> +
> +dsi {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +panel@0 {
> +compatible = "syna,td4328";
> +reg = <0>;
> +
> +backlight = <>;
> +reset-gpios = < 133 GPIO_ACTIVE_LOW>;
> +
> +vdd-supply = <_lcm_2p8>;
> +vddio-supply = <_l12b_1p8>;
> +
> +port {
> +panel_in_0: endpoint {
> +remote-endpoint = <_out>;
> +};
> +};
> +};
> +};
> +
> +...
>
> --
> 2.44.0
>
Re: [PATCH v2 4/7] dt-bindings: display: panel: Add compatible for BOE nv110wum-l60
On Mon, Apr 22, 2024 at 05:03:07PM +0800, Cong Yang wrote: > The BOE nv110wum-l60 is a 11.0" WUXGA TFT LCD panel, which fits in nicely > with the existing himax-hx83102 driver. >From a h/w perspective, the reason to share the binding is the same underlying controller, himax hx83102, is used, not that it is the same driver. Rob
Re: [PATCH v2 1/7] dt-bindings: display: panel: Add himax hx83102 panel bindings
On Mon, Apr 22, 2024 at 05:03:04PM +0800, Cong Yang wrote:
> In V1, discussed with Doug and Linus [1], we need break out as separate
> driver for the himax83102-j02 controller. So add new documentation for
> "starry,himax83102-j02" panel.
>
> [1]:
> https://lore.kernel.org/all/CACRpkdbzYZAS0=zbqjuc4cb2wj4s1h6n6asazqvdmv95r3z...@mail.gmail.com
Please summarize this in the commit message rather than referring to a
link to understand "why" you doing this.
>
> Signed-off-by: Cong Yang
> ---
> .../display/panel/boe,tv101wum-nl6.yaml | 2 -
> .../bindings/display/panel/himax,hx83102.yaml | 73 +++
> 2 files changed, 73 insertions(+), 2 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
> b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
> index 906ef62709b8..53fb35f5c9de 100644
> --- a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
> @@ -32,8 +32,6 @@ properties:
>- innolux,hj110iz-01a
> # STARRY 2081101QFH032011-53G 10.1" WUXGA TFT LCD panel
>- starry,2081101qfh032011-53g
> -# STARRY himax83102-j02 10.51" WUXGA TFT LCD panel
> - - starry,himax83102-j02
> # STARRY ili9882t 10.51" WUXGA TFT LCD panel
>- starry,ili9882t
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml
> b/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml
> new file mode 100644
> index ..2e0cd6998ba8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml
> @@ -0,0 +1,73 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/himax,hx83102.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Himax HX83102 MIPI-DSI LCD panel controller
> +
> +maintainers:
> + - Cong Yang
> +
> +allOf:
> + - $ref: panel-common.yaml#
> +
> +properties:
> + compatible:
> +enum:
> +# STARRY himax83102-j02 10.51" WUXGA TFT LCD panel
> + - starry,himax83102-j02
> +
> + reg:
> +description: the virtual channel number of a DSI peripheral
> +
> + enable-gpios:
> +description: a GPIO spec for the enable pin
> +
> + pp1800-supply:
> +description: core voltage supply
> +
> + avdd-supply:
> +description: phandle of the regulator that provides positive voltage
> +
> + avee-supply:
> +description: phandle of the regulator that provides negative voltage
> +
> + backlight:
> +description: phandle of the backlight device attached to the panel
> +
> + port: true
> + rotation: true
> +
> +required:
> + - compatible
> + - reg
> + - enable-gpios
> + - pp1800-supply
> + - avdd-supply
> + - avee-supply
> +
> +additionalProperties: false
Perhaps 'unevaluatedProperties' instead. Don't you want to support
standard properties such as width-mm/height-mm?
> +
> +examples:
> + - |
> +dsi {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +panel@0 {
> +compatible = "starry,himax83102-j02";
> +reg = <0>;
> +enable-gpios = < 45 0>;
> +avdd-supply = <_lcd>;
> +avee-supply = <_lcd>;
> +pp1800-supply = <_lcd>;
> +backlight = <_lcd0>;
> +port {
> +panel_in: endpoint {
> +remote-endpoint = <_out>;
> +};
> +};
> +};
> +};
> +
> +...
> --
> 2.25.1
>
Re: [PATCH v3 07/17] dt-bindings: display: mediatek: dpi: add compatible for MT8365
On Thu, 18 Apr 2024 16:16:55 +0200, Alexandre Mergnat wrote: > Add dt-binding documentation of dpi for MediaTek MT8365 SoC. > > Signed-off-by: Alexandre Mergnat > --- > Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml | 4 > 1 file changed, 4 insertions(+) > Acked-by: Rob Herring (Arm)
Re: [PATCH] i2c: mux: Remove class argument from i2c_mux_add_adapter()
On Thu, Apr 18, 2024 at 10:55:39PM +0200, Heiner Kallweit wrote:
> 99a741aa7a2d ("i2c: mux: gpio: remove support for class-based device
> instantiation") removed the last call to i2c_mux_add_adapter() with a
> non-null class argument. Therefore the class argument can be removed.
>
> Note: Class-based device instantiation is a legacy mechanism which
> shouldn't be used in new code, so we can rule out that this argument
> may be needed again in the future.
>
> Signed-off-by: Heiner Kallweit
> ---
> drivers/gpu/drm/bridge/sii902x.c | 2 +-
> drivers/i2c/i2c-mux.c | 24 +-
> drivers/i2c/muxes/i2c-arb-gpio-challenge.c | 2 +-
> drivers/i2c/muxes/i2c-mux-gpio.c | 2 +-
> drivers/i2c/muxes/i2c-mux-gpmux.c | 2 +-
> drivers/i2c/muxes/i2c-mux-ltc4306.c| 2 +-
> drivers/i2c/muxes/i2c-mux-mlxcpld.c| 2 +-
> drivers/i2c/muxes/i2c-mux-pca9541.c| 2 +-
> drivers/i2c/muxes/i2c-mux-pca954x.c| 2 +-
> drivers/i2c/muxes/i2c-mux-pinctrl.c| 2 +-
> drivers/i2c/muxes/i2c-mux-reg.c| 2 +-
> drivers/iio/gyro/mpu3050-i2c.c | 2 +-
> drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c | 2 +-
> drivers/media/dvb-frontends/af9013.c | 2 +-
> drivers/media/dvb-frontends/lgdt3306a.c| 2 +-
> drivers/media/dvb-frontends/m88ds3103.c| 2 +-
> drivers/media/dvb-frontends/rtl2830.c | 2 +-
> drivers/media/dvb-frontends/rtl2832.c | 2 +-
> drivers/media/dvb-frontends/si2168.c | 2 +-
> drivers/media/i2c/max9286.c| 2 +-
> drivers/media/usb/cx231xx/cx231xx-i2c.c| 5 +
> drivers/of/unittest.c | 2 +-
Acked-by: Rob Herring (Arm)
> include/linux/i2c-mux.h| 3 +--
> 23 files changed, 23 insertions(+), 49 deletions(-)
Re: [PATCH v1 1/2] dt-bindings: input: i2c-hid: Introduce Ilitek ili2900
On Thu, 18 Apr 2024 20:48:14 +0800, lvzhaoxiong wrote: > The ili2900 touch screen chip same as ilitek ili9882t controller > has a reset gpio. > > Signed-off-by: lvzhaoxiong > --- > Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml | 1 + > 1 file changed, 1 insertion(+) > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: ./Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml:22:5: [error] duplication of key "const" in mapping (key-duplicates) dtschema/dtc warnings/errors: make[2]: *** Deleting file 'Documentation/devicetree/bindings/input/ilitek,ili9882t.example.dts' Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml:22:5: found duplicate key "const" with value "ilitek,ili2900" (original value: "ilitek,ili9882t") make[2]: *** [Documentation/devicetree/bindings/Makefile:26: Documentation/devicetree/bindings/input/ilitek,ili9882t.example.dts] Error 1 make[2]: *** Waiting for unfinished jobs ./Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml:22:5: found duplicate key "const" with value "ilitek,ili2900" (original value: "ilitek,ili9882t") /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml: ignoring, error parsing file make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1430: dt_binding_check] Error 2 make: *** [Makefile:240: __sub-make] Error 2 doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240418124815.31897-2-lvzhaoxi...@huaqin.corp-partner.google.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH v4 1/2] dt-bindings: display: panel: Add Raydium RM69380
On Wed, 17 Apr 2024 18:29:33 +0200, David Wronek wrote:
> Raydium RM69380 is a display driver IC used to drive OLED DSI panels.
> Add a dt-binding for it.
>
> Signed-off-by: David Wronek
> ---
> Note:
> Depends on commit 48a516363e29 ("dt-bindings: display: panel: add common
> dual-link schema")
> ---
> .../bindings/display/panel/raydium,rm69380.yaml| 89
> ++
> 1 file changed, 89 insertions(+)
>
Reviewed-by: Rob Herring (Arm)
Re: [PATCH v2 12/18] dt-bindings: pwm: mediatek,pwm-disp: add compatible for mt8365 SoC
On Tue, 16 Apr 2024 17:53:13 +0200, Alexandre Mergnat wrote: > Add a compatible string for MediaTek Genio 350 MT8365's display PWM > block: this is the same as MT8183. > > Reviewed-by: AngeloGioacchino Del Regno > > Acked-by: Uwe Kleine-König > Signed-off-by: Alexandre Mergnat > --- > Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring (Arm)
Re: [PATCH v2 10/18] dt-bindings: display: mediatek: rdma: add compatible for MT8365 SoC
On Tue, 16 Apr 2024 17:53:11 +0200, Alexandre Mergnat wrote: > Document the display Data Path Read DMA on MT8365, which is compatible > with that of the MT8183. > > Signed-off-by: Alexandre Mergnat > --- > Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring (Arm)
Re: [PATCH v2 09/18] dt-bindings: display: mediatek: ovl: add compatible for MT8365 SoC
On Tue, 16 Apr 2024 17:53:10 +0200, Alexandre Mergnat wrote: > Document the display Overlay on MT8365, which is compatible > with that of the MT8192. > > Signed-off-by: Alexandre Mergnat > --- > Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring (Arm)
Re: [PATCH v2 08/18] dt-bindings: display: mediatek: gamma: add compatible for MT8365 SoC
On Tue, 16 Apr 2024 17:53:09 +0200, Alexandre Mergnat wrote: > Document the display Gamma on MT8365, which is compatible > with that of the MT8183. > > Signed-off-by: Alexandre Mergnat > --- > Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring (Arm)
Re: [PATCH v2 06/18] dt-bindings: display: mediatek: dpi: add power-domains property
On Tue, 16 Apr 2024 17:53:07 +0200, amerg...@baylibre.com wrote: > From: Fabien Parent > > DPI is part of the display / multimedia block in MediaTek SoCs, and > always have a power-domain (at least in the upstream device-trees). > Add the power-domains property to the binding documentation. > > Signed-off-by: Fabien Parent > Signed-off-by: Alexandre Mergnat > --- > Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml | 5 > + > 1 file changed, 5 insertions(+) > Acked-by: Rob Herring (Arm)
Re: [PATCH v2 05/18] dt-bindings: display: mediatek: dsi: add compatible for MT8365 SoC
On Tue, 16 Apr 2024 17:53:06 +0200, Alexandre Mergnat wrote: > Document the Display Serial Interface on MT8365, which is compatible > with that of the MT8183. > > Signed-off-by: Alexandre Mergnat > --- > Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring (Arm)
Re: [PATCH v2 04/18] dt-bindings: display: mediatek: dither: add compatible for MT8365 SoC
On Tue, 16 Apr 2024 17:53:05 +0200, Alexandre Mergnat wrote: > Document the display Dither on MT8365, which is compatible > with that of the MT8183. > > Signed-off-by: Alexandre Mergnat > --- > Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring (Arm)
Re: [PATCH v2 03/18] dt-bindings: display: mediatek: color: add compatible for MT8365 SoC
On Tue, 16 Apr 2024 17:53:04 +0200, Alexandre Mergnat wrote: > Document the display Color on MT8365, which is compatible > with that of the MT8173. > > Signed-off-by: Alexandre Mergnat > --- > Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring (Arm)
Re: [PATCH v2 01/18] dt-bindings: display: mediatek: aal: add compatible for MT8365 SoC
On Tue, 16 Apr 2024 17:53:02 +0200, Alexandre Mergnat wrote: > Document the display Adaptive Ambient Light on MT8365, which is compatible > with that of the MT8183. > > Signed-off-by: Alexandre Mergnat > --- > Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring (Arm)
Re: [PATCH v2 02/18] dt-bindings: display: mediatek: ccorr: add compatible for MT8365 SoC
On Tue, 16 Apr 2024 17:53:03 +0200, Alexandre Mergnat wrote: > Document the display Color Correction on MT8365, which is compatible > with that of the MT8183. > > Signed-off-by: Alexandre Mergnat > --- > Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml | 3 > +++ > 1 file changed, 3 insertions(+) > Acked-by: Rob Herring (Arm)
Re: [PATCH v4 1/2] dt-bindings: display: panel: Add Raydium RM69380
On Wed, 17 Apr 2024 18:29:33 +0200, David Wronek wrote:
> Raydium RM69380 is a display driver IC used to drive OLED DSI panels.
> Add a dt-binding for it.
>
> Signed-off-by: David Wronek
> ---
> Note:
> Depends on commit 48a516363e29 ("dt-bindings: display: panel: add common
> dual-link schema")
> ---
> .../bindings/display/panel/raydium,rm69380.yaml| 89
> ++
> 1 file changed, 89 insertions(+)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml:
Error in referenced schema matching $id:
http://devicetree.org/schemas/display/panel/panel-common-dual.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/raydium,rm69380.example.dtb:
panel@0: False schema does not allow {'compatible':
['lenovo,j716f-edo-rm69380', 'raydium,rm69380'], 'reg': [[0]], 'avdd-supply':
[[4294967295]], 'vddio-supply': [[4294967295]], 'reset-gpios': [[4294967295,
75, 1]], 'ports': {'#address-cells': [[1]], '#size-cells': [[0]], 'port@0':
{'reg': [[0]], 'endpoint': {'remote-endpoint': [[4294967295]]}}, 'port@1':
{'reg': [[1]], 'endpoint': {'remote-endpoint': [[4294967295]]}}}, '$nodename':
['panel@0']}
from schema $id:
http://devicetree.org/schemas/display/panel/raydium,rm69380.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/raydium,rm69380.example.dtb:
panel@0: Unevaluated properties are not allowed ('ports' was unexpected)
from schema $id:
http://devicetree.org/schemas/display/panel/raydium,rm69380.yaml#
doc reference errors (make refcheckdocs):
See
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240417-raydium-rm69380-driver-v4-1-e9c2337d0...@mainlining.org
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH v3 1/2] dt-bindings: display: panel: Add Raydium RM69380
On Tue, Apr 16, 2024 at 08:30:48PM +0200, David Wronek wrote:
> Raydium RM69380 is a display driver IC used to drive OLED DSI panels.
> Add a dt-binding for it.
>
> Signed-off-by: David Wronek
> ---
> Note:
> Depends on commit 48a516363e29 ("dt-bindings: display: panel: add common
> dual-link schema")
> ---
> .../bindings/display/panel/raydium,rm69380.yaml| 91
> ++
> 1 file changed, 91 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml
> b/Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml
> new file mode 100644
> index ..0ac7d033cbe0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml
> @@ -0,0 +1,91 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/raydium,rm69380.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Raydium RM6380-based DSI display panels
RM69380-based
> +
> +maintainers:
> + - David Wronek
> +
> +description:
> + The Raydium RM69380 is a generic DSI panel IC used to control
> + OLED panels.
> +
> +allOf:
> + - $ref: panel-common-dual.yaml#
> +
> +properties:
> + compatible:
> +items:
> + - enum:
> + - lenovo,j716f-edo-rm69380
> + - const: raydium,rm69380
> +description: This indicates the panel manufacturer of the panel
> + that is in turn using the RM69380 panel driver. The compatible
> + string determines how the RM69380 panel driver shall be configured
> + to work with the indicated panel. The raydium,rm69380 compatible shall
> + always be provided as a fallback.
> +
> + avdd-supply:
> +description: Analog voltage rail
> +
> + vddio-supply:
> +description: I/O voltage rail
> +
> + reset-gpios:
> +maxItems: 1
> +description: phandle of gpio for reset line - This should be active low
> +
> + ports: true
> + reg: true
Drop these and change 'addtionalProperties' to 'unevaluatedProperties'.
Other properties in panel-common.yaml should be allowed. width-mm and
height-mm for example.
> +
> +required:
> + - compatible
> + - reg
> + - avdd-supply
> + - vddio-supply
> + - reset-gpios
> + - ports
Already required in panel-common-dual.yaml.
Rob
Re: [PATCH v3 1/2] dt-bindings: display: panel: Add Raydium RM69380
On Tue, 16 Apr 2024 20:30:48 +0200, David Wronek wrote:
> Raydium RM69380 is a display driver IC used to drive OLED DSI panels.
> Add a dt-binding for it.
>
> Signed-off-by: David Wronek
> ---
> Note:
> Depends on commit 48a516363e29 ("dt-bindings: display: panel: add common
> dual-link schema")
> ---
> .../bindings/display/panel/raydium,rm69380.yaml| 91
> ++
> 1 file changed, 91 insertions(+)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml:
Error in referenced schema matching $id:
http://devicetree.org/schemas/display/panel/panel-common-dual.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/raydium,rm69380.example.dtb:
panel@0: False schema does not allow {'compatible':
['lenovo,j716f-edo-rm69380', 'raydium,rm69380'], 'reg': [[0]], 'avdd-supply':
[[4294967295]], 'vddio-supply': [[4294967295]], 'reset-gpios': [[4294967295,
75, 1]], 'ports': {'#address-cells': [[1]], '#size-cells': [[0]], 'port@0':
{'reg': [[0]], 'endpoint': {'remote-endpoint': [[4294967295]]}}, 'port@1':
{'reg': [[1]], 'endpoint': {'remote-endpoint': [[4294967295]]}}}, '$nodename':
['panel@0']}
from schema $id:
http://devicetree.org/schemas/display/panel/raydium,rm69380.yaml#
doc reference errors (make refcheckdocs):
See
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240416-raydium-rm69380-driver-v3-1-21600ac4c...@mainlining.org
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH v2 1/2] dt-bindings: display: panel: Add Raydium RM69380
On Mon, 15 Apr 2024 18:10:41 +0200, David Wronek wrote:
> Raydium RM69380 is a display driver IC used to drive OLED DSI panels.
> Add a dt-binding for it.
>
> Signed-off-by: David Wronek
> ---
> .../bindings/display/panel/raydium,rm69380.yaml| 91
> ++
> 1 file changed, 91 insertions(+)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml:
Error in referenced schema matching $id:
http://devicetree.org/schemas/display/panel/panel-common-dual.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/raydium,rm69380.example.dtb:
panel@0: False schema does not allow {'compatible':
['lenovo,j716f-edo-rm69380', 'raydium,rm69380'], 'reg': [[0]], 'avdd-supply':
[[4294967295]], 'vddio-supply': [[4294967295]], 'reset-gpios': [[4294967295,
75, 1]], 'ports': {'#address-cells': [[1]], '#size-cells': [[0]], 'port@0':
{'reg': [[0]], 'endpoint': {'remote-endpoint': [[4294967295]]}}, 'port@1':
{'reg': [[1]], 'endpoint': {'remote-endpoint': [[4294967295]]}}}, '$nodename':
['panel@0']}
from schema $id:
http://devicetree.org/schemas/display/panel/raydium,rm69380.yaml#
doc reference errors (make refcheckdocs):
See
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240415-raydium-rm69380-driver-v2-1-524216461...@mainlining.org
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH 1/2] dt-bindings: display: panel: Add Raydium RM69380
On Sun, 14 Apr 2024 17:22:30 +0200, David Wronek wrote:
> Raydium RM69380 is a display driver IC used to drive OLED DSI panels.
> Add a dt-binding for it.
>
> Signed-off-by: David Wronek
> ---
> .../bindings/display/panel/raydium,rm69380.yaml| 94
> ++
> 1 file changed, 94 insertions(+)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml:
Error in referenced schema matching $id:
http://devicetree.org/schemas/display/panel/panel-common-dual.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/raydium,rm69380.example.dtb:
panel@0: False schema does not allow {'compatible':
['lenovo,j716f-edo-rm69380', 'raydium,rm69380'], 'reg': [[0]], 'avdd-supply':
[[4294967295]], 'vddio-supply': [[4294967295]], 'reset-gpios': [[4294967295,
75, 1]], 'ports': {'#address-cells': [[1]], '#size-cells': [[0]], 'port@0':
{'reg': [[0]], 'endpoint': {'remote-endpoint': [[4294967295]]}}, 'port@1':
{'reg': [[1]], 'endpoint': {'remote-endpoint': [[4294967295]]}}}, '$nodename':
['panel@0']}
from schema $id:
http://devicetree.org/schemas/display/panel/raydium,rm69380.yaml#
doc reference errors (make refcheckdocs):
See
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240414-raydium-rm69380-driver-v1-1-5e86ba249...@mainlining.org
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH v2 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
On Tue, Apr 09, 2024 at 02:02:10PM +0200, AngeloGioacchino Del Regno wrote: > Document OF graph on MMSYS/VDOSYS: this supports up to three DDP paths > per HW instance (so potentially up to six displays for multi-vdo SoCs). > > The MMSYS or VDOSYS is always the first component in the DDP pipeline, > so it only supports an output port with multiple endpoints - where each > endpoint defines the starting point for one of the (currently three) > possible hardware paths. > > Signed-off-by: AngeloGioacchino Del Regno > > --- > .../bindings/arm/mediatek/mediatek,mmsys.yaml | 23 +++ > 1 file changed, 23 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml > b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml > index b3c6888c1457..4e9acd966aa5 100644 > --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml > +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml > @@ -93,6 +93,29 @@ properties: >'#reset-cells': > const: 1 > > + port: > +$ref: /schemas/graph.yaml#/properties/port > +description: > + Output port node. This port connects the MMSYS/VDOSYS output to > + the first component of one display pipeline, for example one of > + the available OVL or RDMA blocks. > + Some MediaTek SoCs support up to three display outputs per MMSYS. I'm have a hard time understanding this, but is it 3 outputs simultaneously or connect mmsys to 1 of 3. Generally it's multiple ports for the former and endpoints for the latter. > +properties: > + endpoint@0: > +$ref: /schemas/graph.yaml#/properties/endpoint > +description: Output to the primary display pipeline > + > + endpoint@1: > +$ref: /schemas/graph.yaml#/properties/endpoint > +description: Output to the secondary display pipeline > + > + endpoint@2: > +$ref: /schemas/graph.yaml#/properties/endpoint > +description: Output to the tertiary display pipeline > + > +required: > + - endpoint@0 > + > required: >- compatible >- reg > -- > 2.44.0 >
Re: [PATCH v2 1/3] dt-bindings: display: mediatek: Add OF graph support for board path
On Tue, Apr 09, 2024 at 02:02:09PM +0200, AngeloGioacchino Del Regno wrote:
> The display IPs in MediaTek SoCs support being interconnected with
> different instances of DDP IPs (for example, merge0 or merge1) and/or
> with different DDP IPs (for example, rdma can be connected with either
> color, dpi, dsi, merge, etc), forming a full Display Data Path that
> ends with an actual display.
>
> The final display pipeline is effectively board specific, as it does
> depend on the display that is attached to it, and eventually on the
> sensors supported by the board (for example, Adaptive Ambient Light
> would need an Ambient Light Sensor, otherwise it's pointless!), other
> than the output type.
>
> Add support for OF graphs to most of the MediaTek DDP (display) bindings
> to add flexibility to build custom hardware paths, hence enabling board
> specific configuration of the display pipeline and allowing to finally
> migrate away from using hardcoded paths.
>
> Signed-off-by: AngeloGioacchino Del Regno
>
> ---
> .../display/mediatek/mediatek,aal.yaml| 40 +++
> .../display/mediatek/mediatek,ccorr.yaml | 21 ++
> .../display/mediatek/mediatek,color.yaml | 22 ++
> .../display/mediatek/mediatek,dither.yaml | 22 ++
> .../display/mediatek/mediatek,dpi.yaml| 25 +++-
> .../display/mediatek/mediatek,dsc.yaml| 24 +++
> .../display/mediatek/mediatek,dsi.yaml| 27 -
> .../display/mediatek/mediatek,ethdr.yaml | 22 ++
> .../display/mediatek/mediatek,gamma.yaml | 19 +
> .../display/mediatek/mediatek,merge.yaml | 23 +++
> .../display/mediatek/mediatek,od.yaml | 22 ++
> .../display/mediatek/mediatek,ovl-2l.yaml | 22 ++
> .../display/mediatek/mediatek,ovl.yaml| 22 ++
> .../display/mediatek/mediatek,postmask.yaml | 21 ++
> .../display/mediatek/mediatek,rdma.yaml | 22 ++
> .../display/mediatek/mediatek,ufoe.yaml | 21 ++
> 16 files changed, 372 insertions(+), 3 deletions(-)
>
> diff --git
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
> index b4c28e96dd55..623cf7e37fe3 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
> @@ -61,6 +61,27 @@ properties:
> $ref: /schemas/types.yaml#/definitions/phandle-array
> maxItems: 1
>
> + ports:
> +$ref: /schemas/graph.yaml#/properties/ports
> +description:
> + Input and output ports can have multiple endpoints, each of those
> + connects to either the primary, secondary, etc, display pipeline.
> +
> +properties:
> + port@0:
> +$ref: /schemas/graph.yaml#/properties/port
> +description: AAL input port
> +
> + port@1:
> +$ref: /schemas/graph.yaml#/properties/port
> +description:
> + AAL output to the next component's input, for example could be one
> + of many gamma, overdrive or other blocks.
> +
> +required:
> + - port@0
> + - port@1
> +
> required:
>- compatible
>- reg
> @@ -88,5 +109,24 @@ examples:
> power-domains = < MT8173_POWER_DOMAIN_MM>;
> clocks = < CLK_MM_DISP_AAL>;
> mediatek,gce-client-reg = < SUBSYS_1401 0x5000 0x1000>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + aal0_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + aal0_out: endpoint {
> + remote-endpoint = <_in>;
> + };
> + };
> + };
> };
> };
> diff --git
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
> index 8c2a737237f2..71ea277a5d8e 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
> @@ -54,6 +54,27 @@ properties:
> $ref: /schemas/types.yaml#/definitions/phandle-array
> maxItems: 1
>
> + ports:
> +$ref: /schemas/graph.yaml#/properties/ports
> +description:
> + Input and output ports can have multiple endpoints, each of those
> + connects to either the primary, secondary, etc, display pipeline.
> +
> +properties:
> + port@0:
> +$ref: /schemas/graph.yaml#/properties/port
> +description: CCORR input port
> +
> + port@1:
> +$ref: /schemas/graph.yaml#/properties/port
>
Re: [PATCH 1/2] dt-bindings: panel-simple-dsi: add New Khadas TS050 panel bindings
On Wed, Apr 10, 2024 at 08:22:25AM +0400, Christian Hewitt wrote: > > On 9 Apr 2024, at 12:26 PM, Jacobe Zang wrote: > > > > This add the bindings for the New Khadas TS050 1080x1920 5" LCD DSI panel > > designed to work with the Khadas VIM3 and VIM3L Single Board Computers. > > > > Signed-off-by: Jacobe Zang > > --- > > .../devicetree/bindings/display/panel/panel-simple-dsi.yaml | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git > > a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml > > b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml > > index f9160d7bac3ca..e194309f31b72 100644 > > --- a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml > > +++ b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml > > @@ -36,6 +36,8 @@ properties: > > - jdi,fhd-r63452 > > # Khadas TS050 5" 1080x1920 LCD panel > > - khadas,ts050 > > +# Khadas NEW TS050 5" 1080x1920 LCD panel > > + - khadas,newts050 > > Products are only new until they are old. At some future point there will > inevitably be a third iteration requiring a ‘new new’ name. IMHO it would > be better to use something like khadas,ts050v2. I only see patch 1, so the threading is messed up... In any case, The commit message should say something about how they are different? Is the new one not compatible with the old? That's what this change tells me. Otherwise, it should have a fallback. Rob
Re: [RESEND v7 28/37] dt-bindings: soc: renesas: sh: Add SH7751 based target
On Thu, 04 Apr 2024 14:14:39 +0900, Yoshinori Sato wrote: > Signed-off-by: Yoshinori Sato > --- > .../devicetree/bindings/soc/renesas/sh.yaml | 27 +++ > 1 file changed, 27 insertions(+) > create mode 100644 Documentation/devicetree/bindings/soc/renesas/sh.yaml > Reviewed-by: Rob Herring
Re: [RESEND v7 25/37] dt-binding: sh: cpus: Add SH CPUs json-schema
On Thu, Apr 04, 2024 at 02:14:36PM +0900, Yoshinori Sato wrote:
> Renesas SH series and compatible ISA CPUs.
>
> Signed-off-by: Yoshinori Sato
> ---
> .../devicetree/bindings/sh/cpus.yaml | 63 +++
> 1 file changed, 63 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sh/cpus.yaml
>
> diff --git a/Documentation/devicetree/bindings/sh/cpus.yaml
> b/Documentation/devicetree/bindings/sh/cpus.yaml
> new file mode 100644
> index ..9e5640793d76
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sh/cpus.yaml
> @@ -0,0 +1,63 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sh/cpus.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Renesas SuperH CPUs
> +
> +maintainers:
> + - Yoshinori Sato
> +
> +description: |+
> + Definition of CPU core with Renesas SuperH and compatible instruction set.
> +
> +properties:
> + compatible:
> +anyOf:
oneOf
> + - items:
> + - enum:
> + - renesas,sh2a
> + - renesas,sh3
> + - renesas,sh4
> + - renesas,sh4a
> + - jcore,j2
> + - const: renesas,sh2
> + - const: renesas,sh2
> +
> + clocks:
> +maxItems: 1
> +
> + reg:
> +maxItems: 1
> +
> + device_type:
> +const: cpu
> +
> +required:
> + - compatible
> + - reg
> + - device_type
> +
> +additionalProperties: true
This is a problem with the other cpu bindings, but should not be copied
here. Add a $ref to schemas/cpu.yaml and make this
'unevaluatedProperties: false'.
> +
> +examples:
> + - |
> +#include
> +cpus {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +cpu: cpu@0 {
> +compatible = "renesas,sh4", "renesas,sh2";
> +device_type = "cpu";
> +reg = <0>;
> +clocks = < SH7750_CPG_ICK>;
> +clock-names = "ick";
> +icache-size = <16384>;
> +icache-line-size = <32>;
> +dcache-size = <32768>;
> +dcache-line-size = <32>;
> +};
> +};
> +...
> --
> 2.39.2
>
Re: [RESEND v7 22/37] dt-bindings: display: smi,sm501: SMI SM501 binding json-schema
On Thu, Apr 04, 2024 at 02:14:33PM +0900, Yoshinori Sato wrote: > Signed-off-by: Yoshinori Sato > --- > .../bindings/display/smi,sm501.yaml | 398 ++ > 1 file changed, 398 insertions(+) > create mode 100644 Documentation/devicetree/bindings/display/smi,sm501.yaml > > diff --git a/Documentation/devicetree/bindings/display/smi,sm501.yaml > b/Documentation/devicetree/bindings/display/smi,sm501.yaml > new file mode 100644 > index ..06c6af4fa4a9 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/smi,sm501.yaml > @@ -0,0 +1,398 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/smi,sm501.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Silicon Motion SM501 Mobile Multimedia Companion Chip > + > +maintainers: > + - Yoshinori Sato > + > +description: | Don't need '|' > + These DT bindings describe the SM501. Drop "These DT bindings describe" and just describe what the h/w is. > + > +properties: > + compatible: > +const: > + smi,sm501 > + > + reg: > +maxItems: 2 > +description: | > + First entry: System Configuration register > + Second entry: IO space (Display Controller register) items: - description: System Configuration register - description: IO space (Display Controller register) Is it just 1 register in each or should be "registers"? > + > + interrupts: > +description: SM501 interrupt to the cpu should be described here. > + > + mode: > +$ref: /schemas/types.yaml#/definitions/string > +description: select a video mode > + > + edid: > +description: | Don't need '|'. > + verbatim EDID data block describing attached display. s/verbatim/Verbatim/ > + Data from the detailed timing descriptor will be used to > + program the display controller. > + > + little-endian: > +$ref: /schemas/types.yaml#/definitions/flag > +description: available on big endian systems, to set different foreign > endian. > + big-endian: > +$ref: /schemas/types.yaml#/definitions/flag > +description: available on little endian systems, to set different > foreign endian. > + > + swap-fb-endian: All these custom properties need vendor prefix. But really, why are so many custom properties needed? Other display controllers don't need so many, why does this one? Do you actually have users of all of them. > +$ref: /schemas/types.yaml#/definitions/flag > +description: swap framebuffer byteorder. > + > + route-crt-panel: > +$ref: /schemas/types.yaml#/definitions/flag > +description: Panel output merge to CRT. > + > + crt: > +type: object > +description: CRT output control > +properties: > + edid: Huh? You already defined edid elsewhere. > +$ref: /schemas/types.yaml#/definitions/uint8-array > +description: | > + verbatim EDID data block describing attached display. > + Data from the detailed timing descriptor will be used to > + program the display controller. > + > + smi,flags: > +$ref: /schemas/types.yaml#/definitions/string-array > +description: Display control flags. > +items: > + anyOf: > +- const: use-init-done > +- const: disable-at-exit > +- const: use-hwcursor > +- const: use-hwaccel > +- const: panel-no-fpen > +- const: panel-no-vbiasen > +- const: panel-inv-fpen > +- const: panel-inv-vbiasen > +maxItems: 8 > + > + bpp: > +$ref: /schemas/types.yaml#/definitions/uint32 > +description: Color depth > + > + panel: Isn't this just the same as 'crt'? > +type: object > +description: Panel output control > +properties: > + edid: > +$ref: /schemas/types.yaml#/definitions/uint8-array > +description: | > + verbatim EDID data block describing attached display. > + Data from the detailed timing descriptor will be used to > + program the display controller. > + > + smi,flags: > +$ref: /schemas/types.yaml#/definitions/string-array > +description: Display control flags. > +items: > + anyOf: > +- const: use-init-done > +- const: disable-at-exit > +- const: use-hwcursor > +- const: use-hwaccel > +- const: panel-no-fpen > +- const: panel-no-vbiasen > +- const: panel-inv-fpen > +- const: panel-inv-vbiasen > +maxItems: 8 > + > + bpp: > +$ref: /schemas/types.yaml#/definitions/uint32 > +description: Color depth > + > + smi,devices: > +$ref: /schemas/types.yaml#/definitions/string-array > +description: Select SM501 device functions. > +items: > + anyOf: > +- const: usb-host > +- const: usb-slave > +
Re: [RESEND v7 17/37] dt-bindings: interrupt-controller: renesas,sh7751-intc: Add json-schema
On Thu, 04 Apr 2024 14:14:28 +0900, Yoshinori Sato wrote: > Renesas SH7751 INTC json-schema. > > Signed-off-by: Yoshinori Sato > --- > .../renesas,sh7751-intc.yaml | 53 +++ > 1 file changed, 53 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/interrupt-controller/renesas,sh7751-intc.yaml > Reviewed-by: Rob Herring
Re: [RESEND v7 13/37] dt-bindings: clock: sh7750-cpg: Add renesas,sh7750-cpg header.
On Thu, Apr 04, 2024 at 02:14:24PM +0900, Yoshinori Sato wrote:
> SH7750 CPG Clock output define.
This and the subject don't match what the patch does.
>
> Signed-off-by: Yoshinori Sato
> ---
> .../bindings/clock/renesas,sh7750-cpg.yaml| 105 ++
> include/dt-bindings/clock/sh7750-cpg.h| 26 +
> 2 files changed, 131 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/clock/renesas,sh7750-cpg.yaml
> create mode 100644 include/dt-bindings/clock/sh7750-cpg.h
>
> diff --git a/Documentation/devicetree/bindings/clock/renesas,sh7750-cpg.yaml
> b/Documentation/devicetree/bindings/clock/renesas,sh7750-cpg.yaml
> new file mode 100644
> index ..04c10b0834ee
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/renesas,sh7750-cpg.yaml
> @@ -0,0 +1,105 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/renesas,sh7750-cpg.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Renesas SH7750/7751 Clock Pulse Generator (CPG)
> +
> +maintainers:
> + - Yoshinori Sato
> +
> +description:
> + The Clock Pulse Generator (CPG) generates core clocks for the SoC. It
> + includes PLLs, and variable ratio dividers.
> +
> + The CPG may also provide a Clock Domain for SoC devices, in combination
> with
> + the CPG Module Stop (MSTP) Clocks.
> +
> +properties:
> + compatible:
> +enum:
> + - renesas,sh7750-cpg # SH7750
> + - renesas,sh7750s-cpg# SH775S
> + - renesas,sh7750r-cpg# SH7750R
> + - renesas,sh7751-cpg # SH7751
> + - renesas,sh7751r-cpg# SH7751R
> +
> + reg: true
> +
> + reg-names: true
> +
> + clocks:
> +maxItems: 1
> +
> + clock-names:
> +const: extal
> +
> + '#clock-cells':
> +const: 1
> +
> + renesas,mode:
> +description: Board-specific settings of the MD[0-2] pins on SoC
> +$ref: /schemas/types.yaml#/definitions/uint32
> +minimum: 0
> +maximum: 6
> +
> + '#power-domain-cells':
> +const: 0
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - clocks
> + - clock-names
> + - '#clock-cells'
> +
> +allOf:
> + - if:
> + properties:
> +compatible:
> + contains:
> +enum:
> + - renesas,sh7750-cpg
> + - renesas,sh7750s-cpg
> +then:
> + properties:
> +reg:
> + maxItems: 1
> +reg-names:
> + items:
> +- const: FRQCR
> +
> + - if:
> + properties:
> +compatible:
> + contains:
> +enum:
> + - renesas,sh7750r-cpg
> + - renesas,sh7751-cpg
> + - renesas,sh7751r-cpg
> +then:
> + properties:
> +reg:
> + maxItems: 2
minItems: 2 (instead)
> +reg-names:
> + items:
> +- const: FRQCR
> +- const: CLKSTP00
Move this to the top-level and add 'minItems: 1'. Then above you just
need 'maxItems: 1' and here 'minItems: 2'.
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +cpg: clock-controller@ffc0 {
> +#clock-cells = <1>;
> +#power-domain-cells = <0>;
> +compatible = "renesas,sh7751r-cpg";
> +clocks = <>;
> +clock-names = "extal";
> +reg = <0xffc0 20>, <0xfe0a 16>;
> +reg-names = "FRQCR", "CLKSTP00";
> +renesas,mode = <0>;
> +};
> diff --git a/include/dt-bindings/clock/sh7750-cpg.h
> b/include/dt-bindings/clock/sh7750-cpg.h
> new file mode 100644
> index ..ec267be91adf
> --- /dev/null
> +++ b/include/dt-bindings/clock/sh7750-cpg.h
> @@ -0,0 +1,26 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> + *
> + * Copyright 2023 Yoshinori Sato
> + */
> +
> +#ifndef __DT_BINDINGS_CLOCK_SH7750_H__
> +#define __DT_BINDINGS_CLOCK_SH7750_H__
> +
> +#define SH7750_CPG_PLLOUT0
> +
> +#define SH7750_CPG_PCK 1
> +#define SH7750_CPG_BCK 2
> +#define SH7750_CPG_ICK 3
> +
> +#define SH7750_MSTP_SCI 4
> +#define SH7750_MSTP_RTC 5
> +#define SH7750_MSTP_TMU012 6
> +#define SH7750_MSTP_SCIF 7
> +#define SH7750_MSTP_DMAC 8
> +#define SH7750_MSTP_UBC 9
> +#define SH7750_MSTP_SQ 10
> +#define SH7750_CSTP_INTC 11
> +#define SH7750_CSTP_TMU3412
> +#define SH7750_CSTP_PCIC 13
> +
> +#endif
> --
> 2.39.2
>
Re: [RESEND v7 12/37] dt-bindings: pci: pci-sh7751: Add SH7751 PCI
On Thu, Apr 04, 2024 at 02:14:23PM +0900, Yoshinori Sato wrote:
> Renesas SH7751 PCI Controller json-schema.
>
> Signed-off-by: Yoshinori Sato
> ---
> .../bindings/pci/renesas,sh7751-pci.yaml | 89 +++
> 1 file changed, 89 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/pci/renesas,sh7751-pci.yaml
>
> diff --git a/Documentation/devicetree/bindings/pci/renesas,sh7751-pci.yaml
> b/Documentation/devicetree/bindings/pci/renesas,sh7751-pci.yaml
> new file mode 100644
> index ..115c2bb67339
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/renesas,sh7751-pci.yaml
> @@ -0,0 +1,89 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pci/renesas,sh7751-pci.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Renesas SH7751 PCI Host controller
> +
> +maintainers:
> + - Yoshinori Sato
> +
> +allOf:
> + - $ref: /schemas/pci/pci-bus.yaml#
> +
> +properties:
> + compatible:
> +const: renesas,sh7751-pci
> +
> + reg:
> +minItems: 2
> +maxItems: 2
> +
> + reg-names:
> +items:
> + - const: PCI Controller
> + - const: Bus State Controller
> +
> + "#interrupt-cells":
> +const: 1
> +
> + "#address-cells":
> +const: 3
> +
> + "#size-cells":
> +const: 2
> +
> + ranges: true
> +
> + dma-ranges: true
All 5 of these are defined in pci-bus-common.yaml, so you can drop them.
> +
> + interrupt-controller: true
> +
> + renesas,bus-arbit-round-robin:
> +$ref: /schemas/types.yaml#/definitions/flag
> +description: |
Don't need '|'.
> + Set DMA bus arbitration to round robin.
> +
> +required:
> + - compatible
> + - reg
> + - "#interrupt-cells"
> + - "#address-cells"
> + - "#size-cells"
> + - ranges
These 3 are already required, so drop.
> + - interrupt-map
> + - interrupt-map-mask
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> +#include
> +pci@fe20 {
> +compatible = "renesas,sh7751-pci";
> +#address-cells = <3>;
> +#size-cells = <2>;
> +#interrupt-cells = <1>;
> +interrupt-controller;
> +device_type = "pci";
> +bus-range = <0 0>;
> +ranges = <0x0200 0 0xfd00 0xfd00 0 0x0100>,
> + <0x0100 0 0x 0xfe24 0 0x0004>;
> +dma-ranges = <0x0200 0 0xc00 0x0c00 0 0x0400>;
> +reg = <0xfe20 0x0400>,
> + <0xff80 0x0100>;
> +interrupt-map = <0x 0 0 1 5 IRQ_TYPE_LEVEL_LOW>,
> +<0x 0 0 2 6 IRQ_TYPE_LEVEL_LOW>,
> +<0x 0 0 3 7 IRQ_TYPE_LEVEL_LOW>,
> +<0x 0 0 4 8 IRQ_TYPE_LEVEL_LOW>,
> +<0x0800 0 0 1 6 IRQ_TYPE_LEVEL_LOW>,
> +<0x0800 0 0 2 7 IRQ_TYPE_LEVEL_LOW>,
> +<0x0800 0 0 3 8 IRQ_TYPE_LEVEL_LOW>,
> +<0x0800 0 0 4 5 IRQ_TYPE_LEVEL_LOW>,
> +<0x1000 0 0 1 7 IRQ_TYPE_LEVEL_LOW>,
> +<0x1000 0 0 2 8 IRQ_TYPE_LEVEL_LOW>,
> +<0x1000 0 0 3 5 IRQ_TYPE_LEVEL_LOW>,
> +<0x1000 0 0 4 6 IRQ_TYPE_LEVEL_LOW>;
> +interrupt-map-mask = <0x1800 0 0 7>;
> +};
> --
> 2.39.2
>
Re: [RESEND v7 09/37] dt-binding: Add compatible SH7750 SoC
On Thu, 04 Apr 2024 14:14:20 +0900, Yoshinori Sato wrote: > Signed-off-by: Yoshinori Sato > --- > Documentation/devicetree/bindings/timer/renesas,tmu.yaml | 2 ++ > 1 file changed, 2 insertions(+) > Acked-by: Rob Herring
Re: [PATCH v2 04/18] ASoC: dt-bindings: mt6357: Add audio codec document
On Tue, 09 Apr 2024 12:13:25 +0200, Alexandre Mergnat wrote: > Add MT8365 audio codec bindings to set required > and optional voltage properties between the codec and the board. > The properties are: > - phandle of the requiered power supply. > - Setup of microphone bias voltage. > - Setup of the speaker pin pull-down. > > Signed-off-by: Alexandre Mergnat > --- > .../devicetree/bindings/sound/mt6357.yaml | 54 > ++ > 1 file changed, 54 insertions(+) > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/sound/mt6357.yaml: properties:vaud28-supply: '$ref' is not one of ['description', 'deprecated'] from schema $id: http://devicetree.org/meta-schemas/core.yaml# doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240226-audio-i350-v2-4-3043d483d...@baylibre.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH v2 03/18] dt-bindings: mfd: mediatek: Add codec property for MT6357 PMIC
On Tue, 09 Apr 2024 12:13:24 +0200, Alexandre Mergnat wrote: > Add the audio codec sub-device. This sub-device is used to set required > and optional voltage properties between the codec and the board. > > Signed-off-by: Alexandre Mergnat > --- > Documentation/devicetree/bindings/mfd/mediatek,mt6357.yaml | 5 + > 1 file changed, 5 insertions(+) > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mfd/mediatek,mt6357.yaml: Error in referenced schema matching $id: http://devicetree.org/schemas/sound/mt6357.yaml doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240226-audio-i350-v2-3-3043d483d...@baylibre.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: [RESEND v7 06/37] sh: kernel/setup Update DT support.
On Thu, Apr 4, 2024 at 12:15 AM Yoshinori Sato wrote: > > Fix extrnal fdt initialize and bootargs. What is the problem you are trying to solve? And a typo. > > Signed-off-by: Yoshinori Sato > --- > arch/sh/Kconfig | 23 +++ > arch/sh/include/asm/setup.h | 1 + > arch/sh/kernel/setup.c | 36 +++- > 3 files changed, 35 insertions(+), 25 deletions(-) > > diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig > index 6711cde0d973..242cf30e704d 100644 > --- a/arch/sh/Kconfig > +++ b/arch/sh/Kconfig > @@ -708,17 +708,22 @@ config ROMIMAGE_MMCIF > first part of the romImage which in turn loads the rest the kernel > image to RAM using the MMCIF hardware block. > > +config CMDLINE > + string "Kernel command line arguments string" > + default "console=ttySC1,115200" > + > choice > prompt "Kernel command line" > - optional > - default CMDLINE_OVERWRITE > - depends on !OF || USE_BUILTIN_DTB > + default CMDLINE_BOOTLOADER > + > +config CMDLINE_BOOTLOADER > + bool "Use bootloader kernel arguments" This should be the preferred, normal, default way. So why is it a user visible option? > help > - Setting this option allows the kernel command line arguments > - to be set. > + Uses the command-line options passed by the boot loader. > + If boot loader dosen't provide kernel argments, Use built-in > argments. typos bootloader in some spots, "boot loader" in others. Go with the former. > > config CMDLINE_OVERWRITE > - bool "Overwrite bootloader kernel arguments" > + bool "Overwrite built-in kernel arguments" The original made more sense to me. The default should be to use bootloader args. Any built-in kernel command line should be prepend, append (extend), or overwrite/replace. Rob
Re: [PATCH v1 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
On Thu, 04 Apr 2024 10:16:34 +0200, AngeloGioacchino Del Regno wrote:
> Document OF graph on MMSYS/VDOSYS: this supports up to three DDP paths
> per HW instance (so potentially up to six displays for multi-vdo SoCs).
>
> The MMSYS or VDOSYS is always the first component in the DDP pipeline,
> so it only supports an output port with multiple endpoints - where each
> endpoint defines the starting point for one of the (currently three)
> possible hardware paths.
>
> Signed-off-by: AngeloGioacchino Del Regno
>
> ---
> .../bindings/arm/mediatek/mediatek,mmsys.yaml | 23 +++
> 1 file changed, 23 insertions(+)
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml:
properties:port:properties:required: ['endpoint@0'] is not of type 'object',
'boolean'
from schema $id: http://json-schema.org/draft-07/schema#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml:
properties:port:properties: 'required' should not be valid under {'$ref':
'#/definitions/json-schema-prop-names'}
hint: A json-schema keyword was found instead of a DT property name.
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml:
properties:port:properties:required: ['endpoint@0'] is not of type 'object',
'boolean'
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml:
ignoring, error in schema: properties: port: properties: required
Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.example.dtb:
/example-0/syscon@1400: failed to match any schema with compatible:
['mediatek,mt8173-mmsys', 'syscon']
doc reference errors (make refcheckdocs):
See
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240404081635.91412-3-angelogioacchino.delre...@collabora.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
Re: [RESEND v7 19/37] dt-bindings: interrupt-controller: renesas,sh7751-irl-ext: Add json-schema
On Thu, 04 Apr 2024 14:14:30 +0900, Yoshinori Sato wrote: > Renesas SH7751 external interrupt encoder json-schema. > > Signed-off-by: Yoshinori Sato > --- > .../renesas,sh7751-irl-ext.yaml | 57 +++ > 1 file changed, 57 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/interrupt-controller/renesas,sh7751-irl-ext.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/interrupt-controller/renesas,sh7751-irl-ext.example.dtb: interrupt-controller@a400: #interrupt-cells:0:0: 2 was expected from schema $id: http://devicetree.org/schemas/interrupt-controller/renesas,sh7751-irl-ext.yaml# doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/8d8dec2d75890f3a14632c9606c332fb11d89a95.1712207606.git.ys...@users.sourceforge.jp The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH v12 0/7] drm/meson: add support for MIPI DSI Display
On Wed, 03 Apr 2024 09:46:31 +0200, Neil Armstrong wrote: > The Amlogic G12A, G12B & SM1 SoCs embeds a Synopsys DW-MIPI-DSI transceiver > (ver 1.21a), > with a custom glue managing the IP resets, clock and data input similar to > the DW-HDMI > glue on the same Amlogic SoCs. > > This is a follow-up of v5 now the DRM patches are applied, the clk & DT > changes > remains for a full DSI support on G12A & SM1 platforms. > > The DW-MIPI-DSI transceiver + D-PHY are clocked by the GP0 PLL, and the ENCL > encoder + VIU > pixel reader by the VCLK2 clock using the HDMI PLL. > > The DW-MIPI-DSI transceiver gets this pixel stream as input clocked with the > VCLK2 clock. > > An optional "MEAS" clock can be enabled to measure the delay between each > vsync feeding the > DW-MIPI-DSI transceiver. > > The clock setup has been redesigned to use CCF, a common PLL (GP0) and the > VCLK2 clock > path for DSI in preparation of full CCF support and possibly dual display > with HDMI. > > The change from v5 is that now we use a "VCLK" driver instead of notifier and > rely > on CLK_SET_RATE_GATE to ensure the VCLK gate operation are called. > > Signed-off-by: Neil Armstrong > --- > Changes in v12: > - fix parameters alignment in patch 2 > - update g12a_mipi_dsi_pxclk_div_table comment with jerome's suggestions > - fix dtbs overlay build, fix missed v11... thx khadas for reporting it > off-list & testing > - Link to v11: > https://lore.kernel.org/r/20240325-amlogic-v6-4-upstream-dsi-ccf-vim3-v11-0-04f55de44...@linaro.org > > Changes in v11: > - Rebased on v6.9-rc1 > - Fixed overlay handling/creation > - Link to v10: > https://lore.kernel.org/r/20240205-amlogic-v6-4-upstream-dsi-ccf-vim3-v10-0-dc06073d5...@linaro.org > > Changes in v10: > - Rename regmap_vclk to meson_clk and add _gate for the gate > - Move COMMON_CLK_MESON_VCLK to following patch > - Remove CLK_SET_RATE_PARENT from g12a_vclk2_sel, keep it only on > mipi_dsi_pxclk_sel > - Add more info on commit message to specify how clock setup is designed > - Remove forgotten CLK_IGNORE_UNUSED on g12a_vclk2_input > - Remove useless CLK_SET_RATE_PARENT on g12a_vclk2_div to stop propagatting > rate _after_ vclk2_div > - Remove invalid CLK_SET_RATE_GATE on g12a_vclk2 since it's not a divider... > - Drop already applied patches > - move Khadas TS050 changes as an overlay > - Link to v9: > https://lore.kernel.org/r/20231124-amlogic-v6-4-upstream-dsi-ccf-vim3-v9-0-95256ed13...@linaro.org > > Changes in v9: > - Colledte reviewed-bys > - Fixed patches 2 & 4, commit messages and bindings format > - Link to v8: > https://lore.kernel.org/r/20231109-amlogic-v6-4-upstream-dsi-ccf-vim3-v8-0-81e4aeeda...@linaro.org > > Changes in v8: > - Switch vclk clk driver to parm as requested by Jerome > - Added bindings fixes to amlogic,meson-axg-mipi-pcie-analog & > amlogic,g12a-mipi-dphy-analog > - Fixed DT errors in vim3 example and MNT Reform DT > - Rebased on next-20231107, successfully tested on VIM3L > - Link to v7: > https://lore.kernel.org/r/20230803-amlogic-v6-4-upstream-dsi-ccf-vim3-v7-0-762219fc5...@linaro.org > > Changes in v7: > - Added review tags > - Fixed patch 5 thanks to George > - Link to v6: > https://lore.kernel.org/r/20230512-amlogic-v6-4-upstream-dsi-ccf-vim3-v6-0-fd2ac9845...@linaro.org > > Changes in v6: > - dropped applied DRM patches > - dropped clk private prefix patches > - rebased on top of > 20230607-topic-amlogic-upstream-clkid-public-migration-v2-0-38172d17c...@linaro.org > - re-ordered/cleaned ENCL patches to match clkid public migration > - Added new "vclk" driver > - uses vclk driver instead of notifier > - cleaned VCLK2 clk flags > - add px_clk gating from DSI driver > - Link to v5: > https://lore.kernel.org/r/20230512-amlogic-v6-4-upstream-dsi-ccf-vim3-v5-0-56eb7a4d5...@linaro.org > > Changes in v5: > - Aded PRIV all the G12 internal clk IDS to simplify public exposing > - Fixed the DSI bindings > - Fixed the DSI HSYNC/VSYNC polarity handling > - Fixed the DSI clock setup > - Fixed the DSI phy timings > - Dropped components for DSI, only keeping it for HDMI > - Added MNT Reform 2 CM4 DT > - Dropped already applied PHY fix > - Link to v4: > https://lore.kernel.org/r/20230512-amlogic-v6-4-upstream-dsi-ccf-vim3-v4-0-2592c29ea...@linaro.org > > Changes from v3 at [3]: > - switched all clk setup via CCF > - using single PLL for DSI controller & ENCL encoder > - added ENCL clocks to CCF > - make the VCLK2 clocks configuration by CCF > - fixed probe/bind of DSI controller to work with panels & bridges > - added bit_clk to controller to it can setup the BIT clock aswell > - added fix for components unbind > - added fix for analog phy setup value > - added TS050 timings fix > - dropped previous clk control patch > > Changes from v2 at [2]: > - Fixed patch 3 > - Added reviews from Jagan > - Rebased on v5.19-rc1 > > Changes from v1 at [1]: > - fixed DSI host bindings > - add reviewed-by tags for bindings > - moved magic values to defines
Re: [PATCH v5 1/2] dt-bindings: backlight: Add Texas Instruments LM3509
On Sat, Mar 30, 2024 at 03:59:24PM +0100, Patrick Gansterer wrote: > Add Device Tree bindings for Texas Instruments LM3509 - a > High Efficiency Boost for White LED's and/or OLED Displays > > Signed-off-by: Patrick Gansterer > Reviewed-by: Krzysztof Kozlowski > Reviewed-by: Daniel Thompson > --- > .../bindings/leds/backlight/ti,lm3509.yaml| 139 ++ > 1 file changed, 139 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/leds/backlight/ti,lm3509.yaml > > diff --git a/Documentation/devicetree/bindings/leds/backlight/ti,lm3509.yaml > b/Documentation/devicetree/bindings/leds/backlight/ti,lm3509.yaml > new file mode 100644 > index ..b67f67648852 > --- /dev/null > +++ b/Documentation/devicetree/bindings/leds/backlight/ti,lm3509.yaml > @@ -0,0 +1,139 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/leds/backlight/ti,lm3509.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: TI LM3509 High Efficiency Boost for White LED's and/or OLED Displays > + > +maintainers: > + - Patrick Gansterer > + > +description: > + The LM3509 current mode boost converter offers two separate outputs. > + https://www.ti.com/product/LM3509 > + > +properties: > + compatible: > +const: ti,lm3509 > + > + reg: > +maxItems: 1 > + > + "#address-cells": > +const: 1 > + > + "#size-cells": > +const: 0 > + > + reset-gpios: > +maxItems: 1 > + > + ti,brightness-rate-of-change-us: > +description: Brightness Rate of Change in microseconds. > +enum: [51, 13000, 26000, 52000] > + > + ti,oled-mode: > +description: Enable OLED mode. > +type: boolean > + > +patternProperties: > + "^led@[01]$": > +type: object > +description: Properties for a string of connected LEDs. > + > +allOf: You don't need allOf here. > + - $ref: common.yaml# > + > +properties: > + reg: > +description: > + The control register that is used to program the two current sinks. > + The LM3509 has two registers (BMAIN and BSUB) and are represented > + as 0 or 1 in this property. The two current sinks can be controlled > + independently with both registers, or register BMAIN can be > + configured to control both sinks with the led-sources property. > +minimum: 0 > +maximum: 1 > + > + label: true > + > + led-sources: > +allOf: Or here. > + - minItems: 1 > +maxItems: 2 > +items: > + minimum: 0 > + maximum: 1
Re: [PATCH 2/3] dt-bindings: display: msm: sm6350-mdss: document DP controller subnode
On Thu, Mar 28, 2024 at 10:42:45AM +0100, Luca Weiss wrote: > Document the displayport controller subnode of the SM6350 MDSS. > > Signed-off-by: Luca Weiss > --- > .../devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml | 10 > ++ > 1 file changed, 10 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml > b/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml > index c9ba1fae8042..d91b8eca6aba 100644 > --- a/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml > +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml > @@ -53,6 +53,16 @@ patternProperties: >compatible: > const: qcom,sm6350-dpu > > + "^displayport-controller@[0-9a-f]+$": > +type: object > +additionalProperties: true > + > +properties: > + compatible: > +items: > + - const: qcom,sm6350-dp > + - const: qcom,sm8350-dp Just use 'contains' here with qcom,sm6350-dp. The full schema will check the order. Rob
Re: [PATCH 1/3] dt-bindings: display: msm: dp-controller: document SM8250 compatible
On Thu, 28 Mar 2024 10:42:44 +0100, Luca Weiss wrote: > Add the compatible string for the DisplayPort controller on SM6350 which > is compatible with the one on SM8350. > > Signed-off-by: Luca Weiss > --- > Documentation/devicetree/bindings/display/msm/dp-controller.yaml | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring
Re: [PATCH v2] dt-bindings: display: bridge: it6505: Add #sound-dai-cells
On Wed, 27 Mar 2024 16:52:48 +0800, Chen-Yu Tsai wrote: > The ITE IT6505 display bridge can take one I2S input and transmit it > over the DisplayPort link. > > Add #sound-dai-cells (= 0) to the binding for it. > > Signed-off-by: Chen-Yu Tsai > --- > Changes since v1 [1]: > - Reference /schemas/sound/dai-common.yaml > - Change "additionalProperties: false" to "unevaluatedProperties: false" > > The driver side changes [2] are still being worked on. > > [1] > https://lore.kernel.org/dri-devel/20240126073511.2708574-1-we...@chromium.org/ > [2] > https://lore.kernel.org/linux-arm-kernel/20230730180803.22570-4-jiaxin...@mediatek.com/ > --- > .../devicetree/bindings/display/bridge/ite,it6505.yaml| 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > Reviewed-by: Rob Herring
Re: [PATCH 1/4] dt-bindings: display: bridge: add the Hot-plug MIPI DSI connector
On Tue, Mar 26, 2024 at 05:28:11PM +0100, Luca Ceresoli wrote: > Add bindings for a physical, hot-pluggable connector allowing the far end > of a MIPI DSI bus to be connected and disconnected at runtime. > > Signed-off-by: Luca Ceresoli > --- > .../bridge/hotplug-video-connector-dsi.yaml| 87 > ++ > MAINTAINERS| 5 ++ > 2 files changed, 92 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/bridge/hotplug-video-connector-dsi.yaml > > b/Documentation/devicetree/bindings/display/bridge/hotplug-video-connector-dsi.yaml > new file mode 100644 > index ..05beb8aa9ab4 > --- /dev/null > +++ > b/Documentation/devicetree/bindings/display/bridge/hotplug-video-connector-dsi.yaml > @@ -0,0 +1,87 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: > http://devicetree.org/schemas/display/bridge/hotplug-video-connector-dsi.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Hot-pluggable connector on a MIPI DSI bus > + > +maintainers: > + - Luca Ceresoli > + > +description: > + A bridge representing a physical, hot-pluggable connector on a MIPI DSI > + video bus. The connector splits the video pipeline in a fixed part and a > + removable part. > + > + The fixed part of the video pipeline includes all components up to the > + display controller and 0 or more bridges. The removable part includes one > + or more bridges and any other components up to the panel. > + > + The removable part of the pipeline can be physically disconnected at any > + moment, making all of its components not usable anymore. The same or a > + different removable part of the pipeline can be reconnected later on. > + > + Note that the hotplug-video-connector does not describe video busses > + having native hotplug capabilities in the hardware, such as HDMI. > + > +properties: > + compatible: > +const: hotplug-video-connector-dsi Got a spec for this connector? How do I know if I have one or not? The problem here is what else is on this connector? GPIO controls, power rails, etc.? If this is some kind of standard connector, then we need to be able to remap everything on the connector not just DSI signals. And for that, it's not just DSI signals, so I'd say we would need some sort of generic graph remapping that the core graph code handles transparently. If it is not standard, then you don't need any remapping and can just use an overlay that connects the ports directly. Rob
Re: [PATCH 2/5] dt-bindings: display: Add GameForce Chi Panel
On Mon, 25 Mar 2024 08:49:56 -0500, Chris Morgan wrote: > From: Chris Morgan > > The GameForce Chi panel is a panel specific to the GameForce Chi > handheld device that measures 3.5" diagonally with a resolution of > 640x480. > > Signed-off-by: Chris Morgan > --- > .../devicetree/bindings/display/panel/rocktech,jh057n00900.yaml | 2 ++ > 1 file changed, 2 insertions(+) > Acked-by: Rob Herring
Re: [PATCH 1/5] dt-bindings: vendor-prefix: Add prefix for GameForce
On Mon, 25 Mar 2024 08:49:55 -0500, Chris Morgan wrote: > From: Chris Morgan > > GameForce is a company that produces handheld game consoles. > > https://gameforce.fun/ > > Signed-off-by: Chris Morgan > --- > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ > 1 file changed, 2 insertions(+) > Acked-by: Rob Herring
Re: [PATCH v4] dt-bindings: display: atmel,lcdc: convert to dtschema
On Mon, 18 Mar 2024 11:10:13 +0530, Dharma Balasubiramani wrote: > Convert the atmel,lcdc bindings to DT schema. > Changes during conversion: add missing clocks and clock-names properties. > > Signed-off-by: Dharma Balasubiramani > --- > This patch converts the existing lcdc display text binding to JSON schema. > The binding is split into two namely > lcdc.yaml > - Holds the frame buffer properties > lcdc-display.yaml > - Holds the display panel properties which is a phandle to the display > property in lcdc fb node. > > These bindings are tested using the following command. > 'make DT_CHECKER_FLAGS=-m dt_binding_check' > --- > Changes in v4: > - Add maximum for atmel,guard-time property. > - Add constraints for bits-per-pixel property. > - Update the atmel,lcd-wiring-mode property's ref to point single string > rather than an array. > - Add constraints for atmel,lcd-wiring-mode property. > - Add maxItems to the atmel,power-control-gpio property. > - Link to v3: > https://lore.kernel.org/r/20240304-lcdc-fb-v3-1-8b616fbb0...@microchip.com > > Changes in v3: > - Remove the generic property "bits-per-pixel" > - Link to v2: > https://lore.kernel.org/r/20240304-lcdc-fb-v2-1-a14b463c1...@microchip.com > > Changes in v2: > - Run checkpatch and remove whitespace errors. > - Add the standard interrupt flags. > - Split the binding into two, namely lcdc.yaml and lcdc-display.yaml. > - Link to v1: > https://lore.kernel.org/r/20240223-lcdc-fb-v1-1-4c64cb627...@microchip.com > --- > .../bindings/display/atmel,lcdc-display.yaml | 103 > + > .../devicetree/bindings/display/atmel,lcdc.txt | 87 - > .../devicetree/bindings/display/atmel,lcdc.yaml| 70 ++ > 3 files changed, 173 insertions(+), 87 deletions(-) > Applied, thanks!
Re: [PATCH v2] dt-bindings: display: samsung,exynos5-dp: convert to DT Schema
On Wed, 13 Mar 2024 19:28:55 +0100, Krzysztof Kozlowski wrote: > Convert Samsung Exynos5250/5420 SoC Display Port Controller bindings to > DT schema with a change: add power-domains, already used in DTS. > > This Display Port controller is actually variant of Analogix Display > Port bridge, however new DT Schema does not reference analogix,dp.yaml, > because of incompatibilities in the driver. The analogix,dp.yaml > expects two ports, input and output, but Linux Exynos DP DRM driver and > DTS use only one port: output. > > Signed-off-by: Krzysztof Kozlowski > > --- > > Changes in v2: > 1. Document deprecated samsung,hpd-gpios > --- > .../bindings/display/exynos/exynos_dp.txt | 112 > .../display/samsung/samsung,exynos5-dp.yaml | 163 ++ > 2 files changed, 163 insertions(+), 112 deletions(-) > delete mode 100644 > Documentation/devicetree/bindings/display/exynos/exynos_dp.txt > create mode 100644 > Documentation/devicetree/bindings/display/samsung/samsung,exynos5-dp.yaml > Applied, thanks!
Re: [RESEND PATCH] dt-bindings: display: sony,td4353-jdi: allow width-mm and height-mm
On Mon, 25 Mar 2024 11:32:27 +0100, Krzysztof Kozlowski wrote: > Allow width and height properties from panel-common.yaml, already used > on some boards: > > sdm845-sony-xperia-tama-apollo.dtb: panel@0: 'height-mm', 'width-mm' do not > match any of the regexes: 'pinctrl-[0-9]+' > > Acked-by: Conor Dooley > Signed-off-by: Krzysztof Kozlowski > --- > > Rob, could you pick up this one? Was on the list for almost a year. > > > .../devicetree/bindings/display/panel/sony,td4353-jdi.yaml | 2 ++ > 1 file changed, 2 insertions(+) > Applied, thanks!
Re: [PATCH v11 0/7] drm/meson: add support for MIPI DSI Display
On Mon, 25 Mar 2024 12:09:46 +0100, Neil Armstrong wrote: > The Amlogic G12A, G12B & SM1 SoCs embeds a Synopsys DW-MIPI-DSI transceiver > (ver 1.21a), > with a custom glue managing the IP resets, clock and data input similar to > the DW-HDMI > glue on the same Amlogic SoCs. > > This is a follow-up of v5 now the DRM patches are applied, the clk & DT > changes > remains for a full DSI support on G12A & SM1 platforms. > > The DW-MIPI-DSI transceiver + D-PHY are clocked by the GP0 PLL, and the ENCL > encoder + VIU > pixel reader by the VCLK2 clock using the HDMI PLL. > > The DW-MIPI-DSI transceiver gets this pixel stream as input clocked with the > VCLK2 clock. > > An optional "MEAS" clock can be enabled to measure the delay between each > vsync feeding the > DW-MIPI-DSI transceiver. > > The clock setup has been redesigned to use CCF, a common PLL (GP0) and the > VCLK2 clock > path for DSI in preparation of full CCF support and possibly dual display > with HDMI. > > The change from v5 is that now we use a "VCLK" driver instead of notifier and > rely > on CLK_SET_RATE_GATE to ensure the VCLK gate operation are called. > > Signed-off-by: Neil Armstrong > --- > Changes in v11: > - Rebased on v6.9-rc1 > - Fixed overlay handling/creation > - Link to v10: > https://lore.kernel.org/r/20240205-amlogic-v6-4-upstream-dsi-ccf-vim3-v10-0-dc06073d5...@linaro.org > > Changes in v10: > - Rename regmap_vclk to meson_clk and add _gate for the gate > - Move COMMON_CLK_MESON_VCLK to following patch > - Remove CLK_SET_RATE_PARENT from g12a_vclk2_sel, keep it only on > mipi_dsi_pxclk_sel > - Add more info on commit message to specify how clock setup is designed > - Remove forgotten CLK_IGNORE_UNUSED on g12a_vclk2_input > - Remove useless CLK_SET_RATE_PARENT on g12a_vclk2_div to stop propagatting > rate _after_ vclk2_div > - Remove invalid CLK_SET_RATE_GATE on g12a_vclk2 since it's not a divider... > - Drop already applied patches > - move Khadas TS050 changes as an overlay > - Link to v9: > https://lore.kernel.org/r/20231124-amlogic-v6-4-upstream-dsi-ccf-vim3-v9-0-95256ed13...@linaro.org > > Changes in v9: > - Colledte reviewed-bys > - Fixed patches 2 & 4, commit messages and bindings format > - Link to v8: > https://lore.kernel.org/r/20231109-amlogic-v6-4-upstream-dsi-ccf-vim3-v8-0-81e4aeeda...@linaro.org > > Changes in v8: > - Switch vclk clk driver to parm as requested by Jerome > - Added bindings fixes to amlogic,meson-axg-mipi-pcie-analog & > amlogic,g12a-mipi-dphy-analog > - Fixed DT errors in vim3 example and MNT Reform DT > - Rebased on next-20231107, successfully tested on VIM3L > - Link to v7: > https://lore.kernel.org/r/20230803-amlogic-v6-4-upstream-dsi-ccf-vim3-v7-0-762219fc5...@linaro.org > > Changes in v7: > - Added review tags > - Fixed patch 5 thanks to George > - Link to v6: > https://lore.kernel.org/r/20230512-amlogic-v6-4-upstream-dsi-ccf-vim3-v6-0-fd2ac9845...@linaro.org > > Changes in v6: > - dropped applied DRM patches > - dropped clk private prefix patches > - rebased on top of > 20230607-topic-amlogic-upstream-clkid-public-migration-v2-0-38172d17c...@linaro.org > - re-ordered/cleaned ENCL patches to match clkid public migration > - Added new "vclk" driver > - uses vclk driver instead of notifier > - cleaned VCLK2 clk flags > - add px_clk gating from DSI driver > - Link to v5: > https://lore.kernel.org/r/20230512-amlogic-v6-4-upstream-dsi-ccf-vim3-v5-0-56eb7a4d5...@linaro.org > > Changes in v5: > - Aded PRIV all the G12 internal clk IDS to simplify public exposing > - Fixed the DSI bindings > - Fixed the DSI HSYNC/VSYNC polarity handling > - Fixed the DSI clock setup > - Fixed the DSI phy timings > - Dropped components for DSI, only keeping it for HDMI > - Added MNT Reform 2 CM4 DT > - Dropped already applied PHY fix > - Link to v4: > https://lore.kernel.org/r/20230512-amlogic-v6-4-upstream-dsi-ccf-vim3-v4-0-2592c29ea...@linaro.org > > Changes from v3 at [3]: > - switched all clk setup via CCF > - using single PLL for DSI controller & ENCL encoder > - added ENCL clocks to CCF > - make the VCLK2 clocks configuration by CCF > - fixed probe/bind of DSI controller to work with panels & bridges > - added bit_clk to controller to it can setup the BIT clock aswell > - added fix for components unbind > - added fix for analog phy setup value > - added TS050 timings fix > - dropped previous clk control patch > > Changes from v2 at [2]: > - Fixed patch 3 > - Added reviews from Jagan > - Rebased on v5.19-rc1 > > Changes from v1 at [1]: > - fixed DSI host bindings > - add reviewed-by tags for bindings > - moved magic values to defines thanks to Martin's searches > - added proper prefixes to defines > - moved phy_configure to phy_init() dw-mipi-dsi callback > - moved phy_on to a new phy_power_on() dw-mipi-dsi callback > - correctly return phy_init/configure errors to callback returns > > [1] https://lore.kernel.org/r/20200907081825.1654-1-narmstr...@baylibre.com > [2]
Re: [PATCH v3 8/9] dt-bindings: xlnx: Add VTC and TPG bindings
On Thu, 21 Mar 2024 13:43:46 -0700, Anatoliy Klymenko wrote: > DO NOT MERGE. REFERENCE ONLY. > > Add binding for AMD/Xilinx Video Timing Controller and Test Pattern > Generator. > > Copy media-bus-formats.h into dt-bindings/media to suplement TPG DT node. > > Signed-off-by: Anatoliy Klymenko > --- > .../bindings/display/xlnx/xlnx,v-tpg.yaml | 87 ++ > .../devicetree/bindings/display/xlnx/xlnx,vtc.yaml | 65 > include/dt-bindings/media/media-bus-format.h | 177 > + > 3 files changed, 329 insertions(+) > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: ./Documentation/devicetree/bindings/display/xlnx/xlnx,v-tpg.yaml:35:4: [warning] wrong indentation: expected 4 but found 3 (indentation) ./Documentation/devicetree/bindings/display/xlnx/xlnx,v-tpg.yaml:45:8: [warning] wrong indentation: expected 8 but found 7 (indentation) ./Documentation/devicetree/bindings/display/xlnx/xlnx,v-tpg.yaml:49:8: [warning] wrong indentation: expected 8 but found 7 (indentation) dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/xlnx/xlnx,v-tpg.yaml: bus-format: missing type definition /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/xlnx/xlnx,v-tpg.yaml: xlnx,bridge: missing type definition /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/xlnx/xlnx,vtc.yaml: xlnx,pixels-per-clock: missing type definition doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240321-dp-live-fmt-v3-8-d5090d796...@amd.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH v2] dt-bindings: display: samsung,exynos5-dp: convert to DT Schema
On Thu, Mar 21, 2024 at 08:37:15AM +0100, Krzysztof Kozlowski wrote: > On 20/03/2024 18:04, Conor Dooley wrote: > > On Wed, Mar 13, 2024 at 07:28:55PM +0100, Krzysztof Kozlowski wrote: > > > >> + clock-names: > >> +items: > >> + - const: dp > > > >> + phy-names: > >> +items: > >> + - const: dp > > > > The items lists here are redundant when you only have a single item, no? > > Isnt it just > > phy-names: > > const: dp > > Somehow the convention for properties was to define the list. Unlike for > compatible where we use shorter syntax like you propose. Shall we change > the approach and use shorter syntax in general? I guess the difference is -names is usually more than 1 whereas compatible is frequently only 1. Either way is fine I think. Rob
Re: [PATCH v2 2/4] dt-bindings: display/xlnx/zynqmp-dpsub: Add audio DMAs
On Tue, Mar 19, 2024 at 10:22:37AM +0200, Tomi Valkeinen wrote: > The DP subsystem for ZynqMP support audio via two channels, and the DP > DMA has dma-engines for those channels. For some reason the DT binding > has not specified those channels, even if the picture included in > xlnx,zynqmp-dpsub.yaml shows "2 x aud" DMAs. New required entries is an ABI change. This message kind of indicates it was a mistake, but should be a lot more explicit. Are things broken without the entries? Need 'Fixes'? > > Add the two audio DMAs to the binding. > > Signed-off-by: Tomi Valkeinen > --- > .../devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml| 10 > -- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff --git > a/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml > b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml > index 554f9d5809d4..6b754d4f260e 100644 > --- a/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml > +++ b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml > @@ -100,12 +100,16 @@ properties: >- description: Video layer, plane 1 (U/V or U) >- description: Video layer, plane 2 (V) >- description: Graphics layer > + - description: Audio channel 0 > + - description: Audio channel 1 >dma-names: > items: >- const: vid0 >- const: vid1 >- const: vid2 >- const: gfx0 > + - const: aud0 > + - const: aud1 > >phys: > description: PHYs for the DP data lanes > @@ -194,11 +198,13 @@ examples: > power-domains = <_dp>; > resets = < ZYNQMP_RESET_DP>; > > -dma-names = "vid0", "vid1", "vid2", "gfx0"; > +dma-names = "vid0", "vid1", "vid2", "gfx0", "aud0", "aud1"; > dmas = <_dpdma 0>, > <_dpdma 1>, > <_dpdma 2>, > - <_dpdma 3>; > + <_dpdma 3>, > + <_dpdma 4>, > + <_dpdma 5>; > > phys = < 1 PHY_TYPE_DP 0 3>, > < 0 PHY_TYPE_DP 1 3>; > > -- > 2.34.1 >
Re: [PATCH 1/2] dt-bindings: ili9881c: Add Startek KD050HDFIA020-C020A support
On Sun, 17 Mar 2024 17:57:45 +0200, Laurent Pinchart wrote: > Document the compatible value for Startek KD050HDFIA020-C020A panels. > > Signed-off-by: Laurent Pinchart > --- > .../devicetree/bindings/display/panel/ilitek,ili9881c.yaml | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring
Re: [PATCH v2 7/8] dt-bindings: xlnx: Add VTC and TPG bindings
On Tue, 12 Mar 2024 17:55:04 -0700, Anatoliy Klymenko wrote: > DO NOT MERGE. REFERENCE ONLY. > > Add binding for AMD/Xilinx Video Timing Controller and Test Pattern > Generator. > > Copy media-bus-formats.h into dt-bindings/media to suplement TPG DT node. > > Signed-off-by: Anatoliy Klymenko > --- > .../bindings/display/xlnx/xlnx,v-tpg.yaml | 87 ++ > .../devicetree/bindings/display/xlnx/xlnx,vtc.yaml | 65 > include/dt-bindings/media/media-bus-format.h | 177 > + > 3 files changed, 329 insertions(+) > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: ./Documentation/devicetree/bindings/display/xlnx/xlnx,v-tpg.yaml:35:4: [warning] wrong indentation: expected 4 but found 3 (indentation) ./Documentation/devicetree/bindings/display/xlnx/xlnx,v-tpg.yaml:45:8: [warning] wrong indentation: expected 8 but found 7 (indentation) ./Documentation/devicetree/bindings/display/xlnx/xlnx,v-tpg.yaml:49:8: [warning] wrong indentation: expected 8 but found 7 (indentation) dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/xlnx/xlnx,vtc.yaml: xlnx,pixels-per-clock: missing type definition /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/xlnx/xlnx,v-tpg.yaml: bus-format: missing type definition /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/xlnx/xlnx,v-tpg.yaml: xlnx,bridge: missing type definition doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240312-dp-live-fmt-v2-7-a9c35dc5c...@amd.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH 2/4] dt-bindings: display/xlnx/zynqmp-dpsub: Add audio DMAs
On Tue, 12 Mar 2024 11:41:03 +0200, Tomi Valkeinen wrote: > The DP subsystem for ZynqMP support audio via two channels, and the DP > DMA has dma-engines for those channels. For some reason the DT binding > has not specified those channels, even if the picture included in > xlnx,zynqmp-dpsub.yaml shows "2 x aud" DMAs. > > Add the two audio DMAs to the binding. > > Signed-off-by: Tomi Valkeinen > --- > .../devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml| 10 > -- > 1 file changed, 8 insertions(+), 2 deletions(-) > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: Error: Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.example.dts:54.26-27 syntax error FATAL ERROR: Unable to parse input tree make[2]: *** [scripts/Makefile.lib:419: Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.example.dtb] Error 1 make[2]: *** Waiting for unfinished jobs make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1428: dt_binding_check] Error 2 make: *** [Makefile:240: __sub-make] Error 2 doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240312-xilinx-dp-audio-v1-2-696c79fac...@ideasonboard.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH 02/12] dt-bindings: display: imx/ldb: drop ddc-i2c-bus property
On Mon, 11 Mar 2024 13:20:10 +0200, Dmitry Baryshkov wrote: > The in-kernel DT files do not use ddc-i2c-bus property with the iMX LVDS > Display Bridge. If in future a need arises to support such usecase, the > panel-simple should be used, which is able to handle the DDC bus. > > Signed-off-by: Dmitry Baryshkov > --- > Documentation/devicetree/bindings/display/imx/ldb.txt | 1 - > 1 file changed, 1 deletion(-) > Acked-by: Rob Herring
Re: [PATCH 01/12] dt-bindings: display: fsl-imx-drm: drop edid property support
On Mon, 11 Mar 2024 13:20:09 +0200, Dmitry Baryshkov wrote: > None of the in-kernel DT files ever used edid override with the > fsl-imx-drm driver. In case the EDID needs to be specified manually, DRM > core allows one to either override it via the debugfs or to load it via > request_firmware by using DRM_LOAD_EDID_FIRMWARE. In all other cases > EDID and/or modes are to be provided as a part of the panel driver. > > Drop the edid property from the fsl-imx-drm bindings. > > Signed-off-by: Dmitry Baryshkov > --- > Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt | 2 -- > 1 file changed, 2 deletions(-) > Acked-by: Rob Herring
Re: [PATCH v3] dt-bindings: display: atmel,lcdc: convert to dtschema
On Mon, Mar 04, 2024 at 08:00:03PM +0530, Dharma Balasubiramani wrote:
> Convert the atmel,lcdc bindings to DT schema.
> Changes during conversion: add missing clocks and clock-names properties.
>
> Signed-off-by: Dharma Balasubiramani
> ---
> This patch converts the existing lcdc display text binding to JSON schema.
> The binding is split into two namely
> lcdc.yaml
> - Holds the frame buffer properties
> lcdc-display.yaml
> - Holds the display panel properties which is a phandle to the display
> property in lcdc fb node.
>
> These bindings are tested using the following command.
> 'make DT_CHECKER_FLAGS=-m dt_binding_check'
> ---
> Changes in v3:
> - Remove the generic property "bits-per-pixel"
> - Link to v2:
> https://lore.kernel.org/r/20240304-lcdc-fb-v2-1-a14b463c1...@microchip.com
>
> Changes in v2:
> - Run checkpatch and remove whitespace errors.
> - Add the standard interrupt flags.
> - Split the binding into two, namely lcdc.yaml and lcdc-display.yaml.
> - Link to v1:
> https://lore.kernel.org/r/20240223-lcdc-fb-v1-1-4c64cb627...@microchip.com
> ---
> .../bindings/display/atmel,lcdc-display.yaml | 97
> ++
> .../devicetree/bindings/display/atmel,lcdc.txt | 87 ---
> .../devicetree/bindings/display/atmel,lcdc.yaml| 70
> 3 files changed, 167 insertions(+), 87 deletions(-)
>
> diff --git
> a/Documentation/devicetree/bindings/display/atmel,lcdc-display.yaml
> b/Documentation/devicetree/bindings/display/atmel,lcdc-display.yaml
> new file mode 100644
> index ..5e0b706d695d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/atmel,lcdc-display.yaml
> @@ -0,0 +1,97 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/atmel,lcdc-display.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Microchip's LCDC Display
> +
> +maintainers:
> + - Nicolas Ferre
> + - Dharma Balasubiramani
> +
> +description:
> + The LCD Controller (LCDC) consists of logic for transferring LCD image data
> + from an external display buffer to a TFT LCD panel. The LCDC has one
> display
> + input buffer per layer that fetches pixels through the single bus host
> + interface and a look-up table to allow palletized display configurations.
> The
> + LCDC is programmable on a per layer basis, and supports different LCD
> + resolutions, window sizes, image formats and pixel depths.
> +
> +# We need a select here since this schema is applicable only for nodes with
> the
> +# following properties
> +
> +select:
> + anyOf:
> +- required: [ 'atmel,dmacon' ]
> +- required: [ 'atmel,lcdcon2' ]
> +- required: [ 'atmel,guard-time' ]
> +
> +properties:
> + atmel,dmacon:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: dma controller configuration
> +
> + atmel,lcdcon2:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: lcd controller configuration
> +
> + atmel,guard-time:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: lcd guard time (Delay in frame periods)
Is there a maximum?
> +
> + bits-per-pixel:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: lcd panel bit-depth.
Constraints?
> +
> + atmel,lcdcon-backlight:
> +$ref: /schemas/types.yaml#/definitions/flag
> +description: enable backlight
> +
> + atmel,lcdcon-backlight-inverted:
> +$ref: /schemas/types.yaml#/definitions/flag
> +description: invert backlight PWM polarity
> +
> + atmel,lcd-wiring-mode:
> +$ref: /schemas/types.yaml#/definitions/non-unique-string-array
Isn't this just a single string rather than an array?
> +description: lcd wiring mode "RGB" or "BRG"
enum:
- RGB
- BRG
No BGR?
But wait, the example shows the value is '1'. That should fail testing.
It didn't, but I've now fixed that.
> +
> + atmel,power-control-gpio:
> +description: gpio to power on or off the LCD (as many as needed)
maxItems: 1
> +
> + display-timings:
> +$ref: panel/display-timings.yaml#
> +
> +required:
> + - atmel,dmacon
> + - atmel,lcdcon2
> + - atmel,guard-time
> + - bits-per-pixel
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +display: panel {
> + bits-per-pixel = <32>;
> + atmel,lcdcon-backlight;
> + atmel,dmacon = <0x1>;
> + atmel,lcdcon2 = <0x80008002>;
> + atmel,guard-time = <9>;
> + atmel,lcd-wiring-mode = <1>;
> +
> + display-timings {
> +native-mode = <>;
> +timing0: timing0 {
> + clock-frequency = <900>;
> + hactive = <480>;
> + vactive = <272>;
> + hback-porch = <1>;
> + hfront-porch = <1>;
> + vback-porch = <40>;
> + vfront-porch = <1>;
> + hsync-len = <45>;
> + vsync-len = <1>;
> +};
> + };
> +};
Re: [PATCH v2 0/3] panel-simple: add support for Crystal Clear CMT430B19N00
On Mon, Mar 04, 2024 at 07:29:04PM +, Conor Dooley wrote: > On Mon, Mar 04, 2024 at 05:04:51PM +0100, Jérémie Dautheribes wrote: > > Hello everyone, > > > > This patch series add support for the Crystal Clear Technology > > CMT430B19N00 4.3" 480x272 TFT-LCD panel. > > It also adds Crystal Clear Technology to vendor-prefixes.yaml. > > > > Please note that unfortunately there is no public datasheet available > > for this panel. > > > > Changes in v2: > > - add link to the Crystal Clear Technology website in commit message, as > > suggested by Conor Dooley and Neil Armstrong. > > You forgot however to add the acks that I gave you for the two > dt-binding patches. I was wondering why my scripts said this was already reviewed with that missing. Turns out b4 will now check prior versions and add the tags as long as the patch-id matches. Neat, but the submitter really has to grasp how that all works (knowing if the patch-id changed) as well as the maintainer has to use b4, so we can't really rely on it. Here's b4 debug log: new message: 20240223-subtotal-aground-268d135adeff@spud Running git --no-pager patch-id --stable found matching patch-id for Re: [PATCH 2/3] dt-bindings: display: simple: add support for Crystal Clear CMT430B19N00 new message: 20240229-woven-lively-1d90687b2d03@spud skipping reply without trailers: 20240229-woven-lively-1d90687b2d03@spud new message: 20240223134517.728568-2-jeremie.dautheri...@bootlin.com skipping non-reply: 20240223134517.728568-2-jeremie.dautheri...@bootlin.com Analyzing follow-up: Re: [PATCH v2 0/3] panel-simple: add support for Crystal Clear CMT430B19N00 (co...@kernel.org) no trailers found, skipping Analyzing follow-up: Re: [PATCH v2 3/3] drm/panel: simple: add CMT430B19N00 LCD panel support (mrip...@kernel.org) no trailers found, skipping adding "Acked-by: Conor Dooley " from trailer_map to: [PATCH v2 1/3] dt-bindings: Add Crystal C lear Technology vendor prefix adding "Link: http://www.cct.com.my/; from trailer_map to: [PATCH v2 1/3] dt-bindings: Add Crystal Clear Technology vendor prefix adding "Acked-by: Conor Dooley " from trailer_map to: [PATCH v2 2/3] dt-bindings: display: simp le: add support for Crystal Clear CMT430B19N00 adding "Reviewed-by: Neil Armstrong " from trailer_map to: [PATCH v2 3/3] drm/panel: simple: add CMT430B19N00 LCD panel support adding "Reviewed-by: Jessica Zhang " from trailer_map to: [PATCH v2 3/3] drm/panel: simple: add CMT430B19N00 LCD panel support
Re: [PATCH v2] dt-bindings: display: atmel,lcdc: convert to dtschema
On Mon, 04 Mar 2024 11:06:39 +0530, Dharma Balasubiramani wrote: > Convert the atmel,lcdc bindings to DT schema. > Changes during conversion: add missing clocks and clock-names properties. > > Signed-off-by: Dharma Balasubiramani > --- > This patch converts the existing lcdc display text binding to JSON schema. > The binding is split into two namely > lcdc.yaml > - Holds the frame buffer properties > lcdc-display.yaml > - Holds the display panel properties which is a phandle to the display > property in lcdc fb node. > > These bindings are tested against the existing at91 dts files using > dtbs_check. > --- > Changes in v2: > - Run checkpatch and remove whitespace errors. > - Add the standard interrupt flags. > - Split the binding into two, namely lcdc.yaml and lcdc-display.yaml. > - Link to v1: > https://lore.kernel.org/r/20240223-lcdc-fb-v1-1-4c64cb627...@microchip.com > --- > .../bindings/display/atmel,lcdc-display.yaml | 98 > ++ > .../devicetree/bindings/display/atmel,lcdc.txt | 87 --- > .../devicetree/bindings/display/atmel,lcdc.yaml| 70 > 3 files changed, 168 insertions(+), 87 deletions(-) > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/imx/fsl,imx-lcdc.example.dtb: display0: 'atmel,dmacon' is a required property from schema $id: http://devicetree.org/schemas/display/atmel,lcdc-display.yaml# /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/imx/fsl,imx-lcdc.example.dtb: display0: 'atmel,lcdcon2' is a required property from schema $id: http://devicetree.org/schemas/display/atmel,lcdc-display.yaml# /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/imx/fsl,imx-lcdc.example.dtb: display0: 'atmel,guard-time' is a required property from schema $id: http://devicetree.org/schemas/display/atmel,lcdc-display.yaml# /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/imx/fsl,imx-lcdc.example.dtb: display0: 'fsl,pcr', 'model' do not match any of the regexes: 'pinctrl-[0-9]+' from schema $id: http://devicetree.org/schemas/display/atmel,lcdc-display.yaml# doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240304-lcdc-fb-v2-1-a14b463c1...@microchip.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH] dt-bindings: display: atmel,lcdc: convert to dtschema
On Thu, Feb 29, 2024 at 06:25:56AM +, dharm...@microchip.com wrote: > On 28/02/24 3:53 pm, Krzysztof Kozlowski wrote: > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > > content is safe > > > > On 28/02/2024 11:18, dharm...@microchip.com wrote: > >> On 28/02/24 12:43 pm, Krzysztof Kozlowski wrote: > >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know > >>> the content is safe > >>> > >>> On 28/02/2024 07:59, dharm...@microchip.com wrote: > > > > > I don't know what's this exactly, but if embedded display then maybe > > could be part of this device node. If some other display, then maybe you > > need another schema, with compatible? But first I would check how others > > are doing this. > > Okay, then I think the driver also needs to be modified, currently the > driver parses the phandle and looks for these properties. Also the > corresponding dts files. > >>> > >>> Driver does not have to be modified in my proposal. You would still have > >>> phandle. > >> > >> If I understand correctly, I could define the dt bindings as below > >> > >> display: > >> $ref: /schemas/types.yaml#/definitions/phandle > >> description: A phandle pointing to the display node. > >> > >> panel: > >> $ref: panel/panel-common.yaml# > >> properties: > >> > > > > So these are standard panel bindings? Then the node should live outside > > of lcdc. If current driver needs to poke inside panel and panel could be > > anything, then probably you need peripheral-props-like approach. :/ > > Thank you so much, so can I use something like this > >display: > $ref: /schemas/types.yaml#/definitions/phandle > description: A phandle pointing to the display node. > > patternProperties: >"^panel": Just 'panel' and not a pattern. However, that's not what the original binding had. It was a separate node. If you want to preserve that, then you'll need a separate schema file and a special 'select'. Something like: select: anyOf: - required: [ atmel,dmacon ] - required: [ atmel,lcdcon2 ] - required: [ atmel,guard-time ] Up to you and at91 maintainers if you want to have to update your dts files or not. Rob
Re: [PATCH v2 1/3] dt-bindings: display: msm: dp-controller: document X1E80100 compatible
On Tue, Feb 27, 2024 at 04:45:25PM +0100, Krzysztof Kozlowski wrote: > On 22/02/2024 16:55, Abel Vesa wrote: > > Add the X1E80100 to the list of compatibles and document the is-edp > > flag. The controllers are expected to operate in DP mode by default, > > and this flag can be used to select eDP mode. > > > > Signed-off-by: Abel Vesa > > --- > > Documentation/devicetree/bindings/display/msm/dp-controller.yaml | 6 ++ > > 1 file changed, 6 insertions(+) > > > > diff --git > > a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml > > b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml > > index ae53cbfb2193..ed11852e403d 100644 > > --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml > > +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml > > @@ -27,6 +27,7 @@ properties: > >- qcom,sdm845-dp > >- qcom,sm8350-dp > >- qcom,sm8650-dp > > + - qcom,x1e80100-dp > >- items: > >- enum: > >- qcom,sm8150-dp > > @@ -73,6 +74,11 @@ properties: > >- description: phy 0 parent > >- description: phy 1 parent > > > > + is-edp: > > +$ref: /schemas/types.yaml#/definitions/flag > > +description: > > + Tells the controller to switch to eDP mode > > > DP controller cannot be edp, so property "is-edp" is confusing. Probably > you want to choose some phy mode, so you should rather use "phy-mode" > property. I am sure we've been here... phy-mode belongs in the phy node though. Not that you couldn't look in the phy node and see, but everyone likes all the properties they need nicely packaged up in their driver's node. > Anyway, if you define completely new property without vendor prefix, > that's a generic property, so you need to put it in some common schema > for all Display Controllers, not only Qualcomm. I'm trying to unsee what the driver is doing... Hard-coding the connector type and some instance indices. U! I'm sure I'm to blame for rejecting those in DT. I've suggested connector nodes in the past. More generally, whatever is attached at the other end (as it could be a bridge rather than a connector) knows what mode is needed. It's simple negotiation. Each end presents what they support. You take the union of the list(s) and get the mode. If there's more than one, then the kernel or user gets to choose. Qualcomm is not the only one with this problem. Solve it for everyone... Rob
Re: [PATCH v2 1/3] dt-bindings: display: msm: dp-controller: document X1E80100 compatible
On Sun, Feb 25, 2024 at 12:34:34AM +0200, Dmitry Baryshkov wrote: > On Thu, 22 Feb 2024 at 17:55, Abel Vesa wrote: > > > > Add the X1E80100 to the list of compatibles and document the is-edp > > flag. The controllers are expected to operate in DP mode by default, > > and this flag can be used to select eDP mode. > > > > Signed-off-by: Abel Vesa > > Rob, Krzysztof, Connor, gracious ping for the review. It would be > really nice to merge this patchset during the next cycle. It also > unbreaks several other patches. The only thing that speeds up my review is reviewing whatever is ahead of this patch in the queue[1]. Rob [1] https://patchwork.ozlabs.org/project/devicetree-bindings/list/
Re: [PATCH v2 8/9] media: dt-bindings: Add Intel Displayport RX IP
On Thu, Feb 29, 2024 at 11:25:41AM +0100, Paweł Anikiel wrote: > On Wed, Feb 28, 2024 at 7:10 PM Rob Herring wrote: > > > > On Wed, Feb 28, 2024 at 02:09:33PM +0100, Paweł Anikiel wrote: > > > On Wed, Feb 28, 2024 at 1:18 PM Krzysztof Kozlowski > > > wrote: > > > > > > > > On 28/02/2024 12:05, Paweł Anikiel wrote: > > > > > On Tue, Feb 27, 2024 at 3:29 PM Rob Herring wrote: > > > > >> > > > > >> On Mon, Feb 26, 2024 at 11:59:42AM +0100, Paweł Anikiel wrote: > > > > >>> On Mon, Feb 26, 2024 at 10:13 AM Krzysztof Kozlowski > > > > >>> wrote: > > > > >>>> > > > > >>>> On 21/02/2024 17:02, 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 | 160 > > > > >>>>> ++ > > > > >>>>> 1 file changed, 160 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 ..31025f2d5dcd > > > > >>>>> --- /dev/null > > > > >>>>> +++ b/Documentation/devicetree/bindings/media/intel,dprx.yaml > > > > >>>>> @@ -0,0 +1,160 @@ > > > > >>>>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > > > > >>>>> +%YAML 1.2 > > > > >>>>> +--- > > > > >>>>> +$id: http://devicetree.org/schemas/media/intel,dprx.yaml# > > > > >>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > >>>>> + > > > > >>>>> +title: Intel DisplayPort RX IP > > > > >>>>> + > > > > >>>>> +maintainers: > > > > >>>>> + - Paweł Anikiel > > > > >>>>> + > > > > >>>>> +description: | > > > > >>>>> + The Intel Displayport RX IP is a part of the DisplayPort Intel > > > > >>>>> FPGA IP > > > > >>>>> + Core. It implements a DisplayPort 1.4 receiver capable of HBR3 > > > > >>>>> video > > > > >>>>> + capture and Multi-Stream Transport. > > > > >>>>> + > > > > >>>>> + The IP features a large number of configuration parameters, > > > > >>>>> found at: > > > > >>>>> + > > > > >>>>> https://www.intel.com/content/www/us/en/docs/programmable/683273/23-3-20-0-1/sink-parameters.html > > > > >>>>> + > > > > >>>>> + The following parameters have to be enabled: > > > > >>>>> +- Support DisplayPort sink > > > > >>>>> +- Enable GPU control > > > > >>>>> + The following parameters' values have to be set in the > > > > >>>>> devicetree: > > > > >>>>> +- RX maximum link rate > > > > >>>>> +- Maximum lane count > > > > >>>>> +- Support MST > > > > >>>>> +- Max stream count (only if Support MST is enabled) > > > > >>>>> + > > > > >>>>> +properties: > > > > >&g
Re: [PATCH v2 8/9] media: dt-bindings: Add Intel Displayport RX IP
On Wed, Feb 28, 2024 at 02:09:33PM +0100, Paweł Anikiel wrote: > On Wed, Feb 28, 2024 at 1:18 PM Krzysztof Kozlowski > wrote: > > > > On 28/02/2024 12:05, Paweł Anikiel wrote: > > > On Tue, Feb 27, 2024 at 3:29 PM Rob Herring wrote: > > >> > > >> On Mon, Feb 26, 2024 at 11:59:42AM +0100, Paweł Anikiel wrote: > > >>> On Mon, Feb 26, 2024 at 10:13 AM Krzysztof Kozlowski > > >>> wrote: > > >>>> > > >>>> On 21/02/2024 17:02, 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 | 160 > > >>>>> ++ > > >>>>> 1 file changed, 160 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 ..31025f2d5dcd > > >>>>> --- /dev/null > > >>>>> +++ b/Documentation/devicetree/bindings/media/intel,dprx.yaml > > >>>>> @@ -0,0 +1,160 @@ > > >>>>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > > >>>>> +%YAML 1.2 > > >>>>> +--- > > >>>>> +$id: http://devicetree.org/schemas/media/intel,dprx.yaml# > > >>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# > > >>>>> + > > >>>>> +title: Intel DisplayPort RX IP > > >>>>> + > > >>>>> +maintainers: > > >>>>> + - Paweł Anikiel > > >>>>> + > > >>>>> +description: | > > >>>>> + The Intel Displayport RX IP is a part of the DisplayPort Intel > > >>>>> FPGA IP > > >>>>> + Core. It implements a DisplayPort 1.4 receiver capable of HBR3 > > >>>>> video > > >>>>> + capture and Multi-Stream Transport. > > >>>>> + > > >>>>> + The IP features a large number of configuration parameters, found > > >>>>> at: > > >>>>> + > > >>>>> https://www.intel.com/content/www/us/en/docs/programmable/683273/23-3-20-0-1/sink-parameters.html > > >>>>> + > > >>>>> + The following parameters have to be enabled: > > >>>>> +- Support DisplayPort sink > > >>>>> +- Enable GPU control > > >>>>> + The following parameters' values have to be set in the devicetree: > > >>>>> +- RX maximum link rate > > >>>>> +- Maximum lane count > > >>>>> +- Support MST > > >>>>> +- Max stream count (only if Support MST is enabled) > > >>>>> + > > >>>>> +properties: > > >>>>> + compatible: > > >>>>> +const: intel,dprx-20.0.1 > > >>>>> + > > >>>>> + reg: > > >>>>> +maxItems: 1 > > >>>>> + > > >>>>> + interrupts: > > >>>>> +maxItems: 1 > > >>>>> + > > >>>>> + intel,max-link-rate: > > >>>>> +$ref: /schemas/types.yaml#/definitions/uint32 > > >>>>> +description: Max link rate configuration parameter > > >>>> > > >>>> Please do not duplicate property name in description. It's useless. > > >>>> Instead explain what is this responsible for. > > >>>> > > >>>> Why max-link-rate would differ for the same dprx-20.0.1? And why > > >>>> standard properties cannot be used? > > >>>> >
Re: [PATCH v2 8/9] media: dt-bindings: Add Intel Displayport RX IP
On Mon, Feb 26, 2024 at 11:59:42AM +0100, Paweł Anikiel wrote: > On Mon, Feb 26, 2024 at 10:13 AM Krzysztof Kozlowski > wrote: > > > > On 21/02/2024 17:02, 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 | 160 ++ > > > 1 file changed, 160 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 ..31025f2d5dcd > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/media/intel,dprx.yaml > > > @@ -0,0 +1,160 @@ > > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/media/intel,dprx.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: Intel DisplayPort RX IP > > > + > > > +maintainers: > > > + - Paweł Anikiel > > > + > > > +description: | > > > + The Intel Displayport RX IP is a part of the DisplayPort Intel FPGA IP > > > + Core. It implements a DisplayPort 1.4 receiver capable of HBR3 video > > > + capture and Multi-Stream Transport. > > > + > > > + The IP features a large number of configuration parameters, found at: > > > + > > > https://www.intel.com/content/www/us/en/docs/programmable/683273/23-3-20-0-1/sink-parameters.html > > > + > > > + The following parameters have to be enabled: > > > +- Support DisplayPort sink > > > +- Enable GPU control > > > + The following parameters' values have to be set in the devicetree: > > > +- RX maximum link rate > > > +- Maximum lane count > > > +- Support MST > > > +- Max stream count (only if Support MST is enabled) > > > + > > > +properties: > > > + compatible: > > > +const: intel,dprx-20.0.1 > > > + > > > + reg: > > > +maxItems: 1 > > > + > > > + interrupts: > > > +maxItems: 1 > > > + > > > + intel,max-link-rate: > > > +$ref: /schemas/types.yaml#/definitions/uint32 > > > +description: Max link rate configuration parameter > > > > Please do not duplicate property name in description. It's useless. > > Instead explain what is this responsible for. > > > > Why max-link-rate would differ for the same dprx-20.0.1? And why > > standard properties cannot be used? > > > > Same for all questions below. > > These four properties are the IP configuration parameters mentioned in > the device description. When generating the IP core you can set these > parameters, which could make them differ for the same dprx-20.0.1. > They are documented in the user guide, for which I also put a link in > the description. Is that enough? Or should I also document these > parameters here? Use the standard properties: link-frequencies and data-lanes. Those go under the port(s) because they are inheritly per logical link. Rob
Re: [PATCH v2 8/9] media: dt-bindings: Add Intel Displayport RX IP
On Tue, Feb 27, 2024 at 02:11:27PM +0100, Paweł Anikiel wrote: > On Mon, Feb 26, 2024 at 6:29 PM Krzysztof Kozlowski > wrote: > > > > On 26/02/2024 13:43, Paweł Anikiel wrote: > > > + intel,max-stream-count: > > > +$ref: /schemas/types.yaml#/definitions/uint32 > > > +description: Max stream count configuration parameter > > > + > > > + port: > > > +$ref: /schemas/graph.yaml#/properties/port > > > +description: SST main link > > > > I don't understand why you have both port and ports. Shouldn't this be > > under ports? > > >>> > > >>> I put both so that you can use the shorter port property when the > > >>> device only has one port (i.e. no MST support). It would work fine > > >>> without it. If you think that's unnecessary, I can remove it (and use > > >>> the ports property even if there is only one). > > >> > > >> No, it is fine, but then you need allOf: which will restrict to only one > > >> of them: either port or ports. > > > > > > There already is an allOf below that says that ports is required for > > > MST support and port is required otherwise. Isn't this enough? > > > > Add both port and ports and see if it is enough. > > Ok, I see. I tried and this seems to work: > > oneOf: > - required: > - port > - required: > - ports > > And that would make the if/else with port and ports below not needed. > What do you think? Just always use 'ports' rather than complicate things. Rob
Re: [PATCH 1/8] dt-bindings: arm-smmu: Add QCM2290 GPU SMMU
On Mon, 19 Feb 2024 14:35:46 +0100, Konrad Dybcio wrote: > The GPU SMMU on QCM2290 nicely fits into the description we already have > for SM61[12]5. Add it. > > Signed-off-by: Konrad Dybcio > --- > Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > Acked-by: Rob Herring
Re: [PATCH v2 4/4] dt-bindings: display: simple: hardware can use several properties
On Sat, Feb 17, 2024 at 12:02:58PM +0100, Raphael Gallais-Pou wrote: > Setting a panel-timing in the device-tree overwrite the one specified in > the driver and set it as preferred. In that case 'height-mm', > 'width-mm' and 'panel-timing' are properties that can be use for simple > panels, according to panel-common.yaml > > Fixes following warnings: > arch/arm/boot/dts/st/stm32mp135f-dk.dtb: panel-rgb: 'height-mm', > 'panel-timing', 'width-mm' do not match any of the regexes: 'pinctrl-[0-9]+' > from schema $id: > http://devicetree.org/schemas/display/panel/panel-simple.yaml# > > Signed-off-by: Raphael Gallais-Pou > --- > Documentation/devicetree/bindings/display/panel/panel-simple.yaml | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > index 634a10c6f2dd..c02cbbc7a100 100644 > --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > @@ -352,6 +352,9 @@ properties: >no-hpd: true >hpd-gpios: true >data-mapping: true > + height-mm: true > + width-mm: true > + panel-timing: true Instead, just change 'additionalProperties' to 'unevaluateProperties' and drop all these 'prop: true' lines. Pretty much anything from panel-common.yaml should be allowed. Rob
Re: (subset) [linux][PATCH v6 3/3] dt-bindings: mfd: atmel,hlcdc: Convert to DT schema format
On Tue, Feb 20, 2024 at 08:30:38AM +, dharm...@microchip.com wrote: > Hi Lee, > > On 20/02/24 1:50 pm, Lee Jones wrote: > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > > content is safe > > > > On Tue, 20 Feb 2024, dharm...@microchip.com wrote: > > > >> Hi Krzysztof, > >> > >> On 12/02/24 3:53 pm, Krzysztof Kozlowski wrote: > >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know > >>> the content is safe > >>> > >>> On 08/02/2024 11:43, Lee Jones wrote: > On Fri, 02 Feb 2024 05:47:33 +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. > > > > [...] > > Applied, thanks! > > [3/3] dt-bindings: mfd: atmel,hlcdc: Convert to DT schema format > commit: cb946db1335b599ece363d33966bf653ed0fa58a > > >>> > >>> Next is still failing. > >>> > >>> Dharma, > >>> You must explain and clearly mark dependencies between patches. > >> > >> I sincerely apologize for any confusion caused by the oversight. I have > >> organized the patches according to their dependencies in the patch > >> series, but unfortunately, I neglected to explicitly mention these > >> dependencies. I understand the importance of clear communication in our > >> collaborative efforts. Please feel free to provide guidance on how I can > >> assist you further in resolving this matter. > > > > If this continues to be an issue, I can just remove the commit. > > There won't be any issue if both pwm and display binding goes before the > mfd binding. > > Could you please pick the display binding as well? As this is still not resolved, I've applied the display binding. Not ideal, but should fix next. Rob
Re: [PATCH 2/8] dt-bindings: clock: Add Qcom QCM2290 GPUCC
On Mon, 19 Feb 2024 14:35:47 +0100, Konrad Dybcio wrote:
> Add device tree bindings for graphics clock controller for Qualcomm
> Technology Inc's QCM2290 SoCs.
>
> Signed-off-by: Konrad Dybcio
> ---
> .../bindings/clock/qcom,qcm2290-gpucc.yaml | 76
> ++
> include/dt-bindings/clock/qcom,qcm2290-gpucc.h | 32 +
> 2 files changed, 108 insertions(+)
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/clock/qcom,qcm2290-gpucc.yaml:
properties:compatible: [{'const': 'qcom,qcm2290-gpucc'}] is not of type
'object', 'boolean'
from schema $id: http://json-schema.org/draft-07/schema#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/clock/qcom,qcm2290-gpucc.yaml:
properties:compatible: [{'const': 'qcom,qcm2290-gpucc'}] is not of type
'object', 'boolean'
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/clock/qcom,qcm2290-gpucc.yaml:
ignoring, error in schema: properties: compatible
Documentation/devicetree/bindings/clock/qcom,qcm2290-gpucc.example.dtb:
/example-0/soc/clock-controller@599: failed to match any schema with
compatible: ['qcom,qcm2290-gpucc']
doc reference errors (make refcheckdocs):
See
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240219-topic-rb1_gpu-v1-2-d260fa854...@linaro.org
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH v3 2/4] dt-bindings: display/msm: Document MDSS on X1E80100
On Fri, 16 Feb 2024 19:01:06 +0200, Abel Vesa wrote: > Document the MDSS hardware found on the Qualcomm X1E80100 platform. > > Reviewed-by: Krzysztof Kozlowski > Signed-off-by: Abel Vesa > --- > .../bindings/display/msm/qcom,x1e80100-mdss.yaml | 253 > + > 1 file changed, 253 insertions(+) > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: Documentation/devicetree/bindings/display/msm/qcom,x1e80100-mdss.example.dts:24:18: fatal error: dt-bindings/clock/qcom,x1e80100-dispcc.h: No such file or directory 24 | #include | ^~ compilation terminated. make[2]: *** [scripts/Makefile.lib:419: Documentation/devicetree/bindings/display/msm/qcom,x1e80100-mdss.example.dtb] Error 1 make[2]: *** Waiting for unfinished jobs make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1428: dt_binding_check] Error 2 make: *** [Makefile:240: __sub-make] Error 2 doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240216-x1e80100-display-v3-2-28b1c33ac...@linaro.org The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH v2 2/4] dt-bindings: display/msm: Document the DPU for X1E80100
On Wed, Feb 14, 2024 at 11:24:31PM +0200, Abel Vesa wrote: > Document the DPU for Qualcomm X1E80100 platform in the SM8650 schema, as > they are similar. > > Signed-off-by: Abel Vesa > --- > Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git > a/Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml > b/Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml > index a01d15a03317..c4087cc5abbd 100644 > --- a/Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml > +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml > @@ -13,7 +13,9 @@ $ref: /schemas/display/msm/dpu-common.yaml# > > properties: >compatible: > -const: qcom,sm8650-dpu > +enum: > + - qcom,sm8650-dpu > + - qcom,x1e80100-dpu Patch 1 uses this in the example, so this patch needs to come first. > >reg: > items: > > -- > 2.34.1 >
Re: [PATCH v2 1/4] dt-bindings: display/msm: document MDSS on X1E80100
On Wed, Feb 14, 2024 at 11:24:30PM +0200, Abel Vesa wrote:
> Document the MDSS hardware found on the Qualcomm X1E80100 platform.
>
> Reviewed-by: Krzysztof Kozlowski
> Signed-off-by: Abel Vesa
> ---
> .../bindings/display/msm/qcom,x1e80100-mdss.yaml | 252
> +
> 1 file changed, 252 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/display/msm/qcom,x1e80100-mdss.yaml
> b/Documentation/devicetree/bindings/display/msm/qcom,x1e80100-mdss.yaml
> new file mode 100644
> index ..c3e38afab76e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/msm/qcom,x1e80100-mdss.yaml
> @@ -0,0 +1,252 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/msm/qcom,x1e80100-mdss.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm X1E80100 Display MDSS
> +
> +maintainers:
> + - Abel Vesa
> +
> +description:
> + X1E80100 MSM Mobile Display Subsystem(MDSS), which encapsulates sub-blocks
> like
> + DPU display controller, DP interfaces, etc.
> +
> +$ref: /schemas/display/msm/mdss-common.yaml#
> +
> +properties:
> + compatible:
> +const: qcom,x1e80100-mdss
> +
> + clocks:
> +items:
> + - description: Display AHB
> + - description: Display hf AXI
> + - description: Display core
> +
> + iommus:
> +maxItems: 1
> +
> + interconnects:
> +maxItems: 3
> +
> + interconnect-names:
> +maxItems: 3
> +
> +patternProperties:
> + "^display-controller@[0-9a-f]+$":
> +type: object
additionalProperties: true
> +properties:
> + compatible:
> +const: qcom,x1e80100-dpu
> +
> + "^displayport-controller@[0-9a-f]+$":
> +type: object
additionalProperties: true
> +properties:
> + compatible:
> +const: qcom,x1e80100-dp
> +
> + "^phy@[0-9a-f]+$":
> +type: object
additionalProperties: true
> +properties:
> + compatible:
> +const: qcom,x1e80100-dp-phy
> +
> +required:
> + - compatible
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +display-subsystem@ae0 {
> +compatible = "qcom,x1e80100-mdss";
> +reg = <0x0ae0 0x1000>;
> +reg-names = "mdss";
> +
> +interconnects = <_noc MASTER_MDP 0 _noc SLAVE_LLCC 0>,
> +<_virt MASTER_LLCC 0 _virt SLAVE_EBI1 0>,
> +<_noc MASTER_APPSS_PROC 0 _noc
> SLAVE_DISPLAY_CFG 0>;
> +interconnect-names = "mdp0-mem", "mdp1-mem", "cpu-cfg";
> +
> +resets = <_core_bcr>;
> +
> +power-domains = <_gdsc>;
> +
> +clocks = < DISP_CC_MDSS_AHB_CLK>,
> + < GCC_DISP_HF_AXI_CLK>,
> + < DISP_CC_MDSS_MDP_CLK>;
> +clock-names = "bus", "nrt_bus", "core";
> +
> +interrupts = ;
> +interrupt-controller;
> +#interrupt-cells = <1>;
> +
> +iommus = <_smmu 0x1c00 0x2>;
> +
> +#address-cells = <1>;
> +#size-cells = <1>;
> +ranges;
> +
> +display-controller@ae01000 {
> +compatible = "qcom,x1e80100-dpu";
> +reg = <0x0ae01000 0x8f000>,
> + <0x0aeb 0x2008>;
> +reg-names = "mdp", "vbif";
> +
> +clocks = <_axi_clk>,
> + <_ahb_clk>,
> + <_mdp_lut_clk>,
> + <_mdp_clk>,
> + <_mdp_vsync_clk>;
> +clock-names = "nrt_bus",
> + "iface",
> + "lut",
> + "core",
> + "vsync";
> +
> +assigned-clocks = <_mdp_vsync_clk>;
> +assigned-clock-rates = <1920>;
> +
> +operating-points-v2 = <_opp_table>;
> +power-domains = < RPMHPD_MMCX>;
> +
> +interrupt-parent = <>;
> +interrupts = <0>;
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +reg = <0>;
> +dpu_intf1_out: endpoint {
> +remote-endpoint = <_in>;
> +};
> +};
> +
> +port@1 {
> +reg = <1>;
> +dpu_intf2_out: endpoint {
> +remote-endpoint = <_in>;
> +};
> +};
> +};
> +
> +mdp_opp_table: opp-table {
> +compatible = "operating-points-v2";
> +
> +opp-2 {
> +opp-hz = /bits/ 64 <2>;
> +required-opps = <_opp_low_svs>;
> +};
> +
> +opp-32500 {
> +opp-hz = /bits/ 64
Re: [PATCH v2 2/4] dt-bindings: display/msm: Document the DPU for X1E80100
On Wed, 14 Feb 2024 23:24:31 +0200, Abel Vesa wrote: > Document the DPU for Qualcomm X1E80100 platform in the SM8650 schema, as > they are similar. > > Signed-off-by: Abel Vesa > --- > Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240214-x1e80100-display-v2-2-cf05ba887...@linaro.org The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH v2 1/4] dt-bindings: display/msm: document MDSS on X1E80100
On Wed, 14 Feb 2024 23:24:30 +0200, Abel Vesa wrote: > Document the MDSS hardware found on the Qualcomm X1E80100 platform. > > Reviewed-by: Krzysztof Kozlowski > Signed-off-by: Abel Vesa > --- > .../bindings/display/msm/qcom,x1e80100-mdss.yaml | 252 > + > 1 file changed, 252 insertions(+) > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: Documentation/devicetree/bindings/display/msm/qcom,x1e80100-mdss.example.dts:24:18: fatal error: dt-bindings/clock/qcom,x1e80100-dispcc.h: No such file or directory 24 | #include | ^~ compilation terminated. make[2]: *** [scripts/Makefile.lib:419: Documentation/devicetree/bindings/display/msm/qcom,x1e80100-mdss.example.dtb] Error 1 make[2]: *** Waiting for unfinished jobs make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1428: dt_binding_check] Error 2 make: *** [Makefile:240: __sub-make] Error 2 doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240214-x1e80100-display-v2-1-cf05ba887...@linaro.org The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH] dt-bindings: use capital "OR" for multiple licenses in SPDX
On Thu, 08 Feb 2024 11:53:27 +0100, Krzysztof Kozlowski wrote: > Documentation/process/license-rules.rst and checkpatch expect the SPDX > identifier syntax for multiple licenses to use capital "OR". Correct it > to keep consistent format and avoid copy-paste issues. > > Signed-off-by: Krzysztof Kozlowski > --- > .../devicetree/bindings/display/panel/visionox,r66451.yaml | 2 +- > Documentation/devicetree/bindings/usb/cypress,hx3.yaml | 2 +- > include/dt-bindings/power/amlogic,c3-pwrc.h | 2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) > Applied, thanks!
Re: [PATCH 8/9] media: dt-bindings: Add Intel Displayport RX IP
On Mon, 12 Feb 2024 13:13:22 +, 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 > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: Error: Documentation/devicetree/bindings/media/intel,dprx.example.dts:28.27-28 syntax error make[2]: *** [scripts/Makefile.lib:419: Documentation/devicetree/bindings/media/intel,dprx.example.dtb] Error 1 doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240212131323.2162161-9-panik...@google.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH 7/9] media: dt-bindings: Add Chameleon v3 framebuffer
On Mon, 12 Feb 2024 13:13:21 +, 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 > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: Error: Documentation/devicetree/bindings/media/google,chv3-fb.example.dts:28.27-28 syntax error FATAL ERROR: Unable to parse input tree make[2]: *** [scripts/Makefile.lib:419: Documentation/devicetree/bindings/media/google,chv3-fb.example.dtb] Error 1 make[2]: *** Waiting for unfinished jobs make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1428: dt_binding_check] Error 2 make: *** [Makefile:240: __sub-make] Error 2 doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240212131323.2162161-8-panik...@google.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH v3 03/10] dt-bindings: display: bridge: tc358775: Add support for tc358765
On Mon, Feb 12, 2024 at 12:30:12PM +0100, Krzysztof Kozlowski wrote:
> On 12/02/2024 09:17, Tony Lindgren wrote:
> > * Krzysztof Kozlowski [240212 08:06]:
> >> On 11/02/2024 10:51, Tony Lindgren wrote:
> >>> The tc358765 is similar to tc358775. The tc358765 just an earlier version
> >>> of the hardware, and it's pin and register compatible with tc358775 for
> >>> most part.
> >>>
> >>> From the binding point of view the only difference is that the tc358765
> >>> does not have stdby-gpios.
> >>>
> >>> Signed-off-by: Tony Lindgren
> >>> ---
> >>
> >> It does not look like you tested the bindings, at least after quick
> >> look. Please run `make dt_binding_check` (see
> >> Documentation/devicetree/bindings/writing-schema.rst for instructions).
> >> Maybe you need to update your dtschema and yamllint.
> >
> > I did.. But I did not notice that this no longer works:
> >
> > $ make dt_binding_check
> > DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml
> > LINTDocumentation/devicetree/bindings
> > usage: yamllint [-h] [-] [-c CONFIG_FILE | -d CONFIG_DATA] [--list-files]
> > [-f {parsable,standard,colored,github,auto}] [-s] [--no-warnings] [-v]
> > [FILE_OR_DIR ...]
> > yamllint: error: one of the arguments FILE_OR_DIR - is required
> > CHKDT Documentation/devicetree/bindings/processed-schema.json
> > SCHEMA Documentation/devicetree/bindings/processed-schema.json
> >
> > After removing the ">2&1" from the Makefile, there's some more info:
> >
> > yamllint: error: one of the arguments FILE_OR_DIR - is required
> >
> > Where DT_SCHEMA_FILES ends up empty. I guess dt_binding_check needs
> > to be now run with just:
> >
> > $ make dt_binding_check DT_SCHEMA_FILES=toshiba,tc358775.yaml
> >
>
> Yes, since June last year. Rob later brought (in July) backwards
> compatible way, but apparently something changed now in Makefile.
It broke in 6.8-rc1. I have a fix in my tree which I'll send to Linus
this week.
Rob
Re: [PATCH v3 03/10] dt-bindings: display: bridge: tc358775: Add support for tc358765
On Sun, 11 Feb 2024 11:51:08 +0200, Tony Lindgren wrote: > The tc358765 is similar to tc358775. The tc358765 just an earlier version > of the hardware, and it's pin and register compatible with tc358775 for > most part. > > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: ./Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml:87:8: [error] empty value in block mapping (empty-values) dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml: allOf:0:if: None is not of type 'object', 'boolean' from schema $id: http://json-schema.org/draft-07/schema# /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml: allOf:0:then: 'anyOf' conditional failed, one must be fixed: 'stby-gpios' is not one of ['$ref', 'additionalItems', 'additionalProperties', 'allOf', 'anyOf', 'const', 'contains', 'default', 'dependencies', 'dependentRequired', 'dependentSchemas', 'deprecated', 'description', 'else', 'enum', 'exclusiveMaximum', 'exclusiveMinimum', 'items', 'if', 'minItems', 'minimum', 'maxItems', 'maximum', 'multipleOf', 'not', 'oneOf', 'pattern', 'patternProperties', 'properties', 'required', 'then', 'typeSize', 'unevaluatedProperties', 'uniqueItems'] 'type' was expected from schema $id: http://devicetree.org/meta-schemas/keywords.yaml# /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml: ignoring, error in schema: allOf: 0: if Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.example.dtb: /example-0/i2c@78b8000/bridge@f: failed to match any schema with compatible: ['toshiba,tc358775'] Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.example.dtb: /example-1/i2c@78b8000/bridge@f: failed to match any schema with compatible: ['toshiba,tc358775'] doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240211095144.2589-4-t...@atomide.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH v3 05/24] media: i2c: switch to use of_graph_get_next_device_endpoint()
On Sun, Feb 04, 2024 at 11:44:39PM +, Kuninori Morimoto wrote:
>
> Hi Rob
>
> > This is assuming there's just 1 port and 1 endpoint, but let's be
> > specific as the bindings are (first endpoint on port 0):
> >
> > of_graph_get_endpoint_by_regs(client->dev.of_node, 0, -1);
> >
> > Note we could ask for endpoint 0 here, but the bindings generally allow
> > for more than 1.
> >
> > I imagine most of the other cases here are the same.
>
> I will do it on new patch-set
>
> > > - for_each_endpoint_of_node(state->dev->of_node, ep_np) {
> > > + for_each_device_endpoint_of_node(state->dev->of_node, ep_np) {
> >
> > I would skip the rename.
>
> It is needed to avoid confuse, because new function will add
> another endpoint loop.
>
> see
> https://lore.kernel.org/r/20240131100701.754a95ee@booty
I've read the threads already and think you should skip the rename. Just
put 'port' in the name of the new one. That and taking a port number
param should be enough distinction.
Rob
Re: [linux][PATCH v2 1/4] dt-bindings: display: bridge: add sam9x75-lvds compatible
On Mon, 05 Feb 2024 16:36:06 +0530, Dharma Balasubiramani wrote: > Add the 'sam9x75-lvds' compatible binding, which describes the Low Voltage > Differential Signaling (LVDS) Controller found on some 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 > --- > Changelog > v1 -> v2 > - Remove '|' in description, as there is no formatting to preserve. > - Remove 'gclk' from clock-names as there is only one clock(pclk). > - Remove the unused headers and include only used ones. > - Change the compatible name specific to SoC (sam9x75) instead of entire > series. > - Change file name to match the compatible name. > --- > .../bridge/microchip,sam9x75-lvds.yaml| 55 +++ > 1 file changed, 55 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/microchip,sam9x75-lvds.yaml > Reviewed-by: Rob Herring
Re: [PATCH V8 09/12] dt-bindings: display: imx: add binding for i.MX8MP HDMI TX
On Sat, 03 Feb 2024 10:52:49 -0600, Adam Ford wrote: > From: Lucas Stach > > The HDMI TX controller on the i.MX8MP SoC is a Synopsys designware IP > core with a little bit of SoC integration around it. > > Signed-off-by: Lucas Stach > Signed-off-by: Adam Ford > > --- > V3: Change name and location to better idenfity as a bridge and > HDMI 2.0a transmitter > > Fix typos and feedback from Rob and added ports. > --- > .../display/bridge/fsl,imx8mp-hdmi-tx.yaml| 102 ++ > 1 file changed, 102 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml > Reviewed-by: Rob Herring
Re: [PATCH V8 03/12] dt-bindings: soc: imx: add missing clock and power-domains to imx8mp-hdmi-blk-ctrl
On Sat, 03 Feb 2024 10:52:43 -0600, Adam Ford wrote: > Per guidance from the NXP downstream kernel, if the clock is > disabled before HDMI/LCDIF probe, LCDIF will not get pixel > clock from HDMI PHY and throw an error: > > [CRTC:39:crtc-2] vblank wait timed out > WARNING: CPU: 2 PID: 9 at drivers/gpu/drm/drm_atomic_helper.c: > 1634 drm_atomic_helper_wait_for_vblanks.part.0+0x23c/0x260 > > Fix this by adding the fdcc clock to the hdmi_blk_ctrl. This > should be safe, since neither this power domain nor the dependent > HDMI and LCDIF drivers been enabled or added to the SoC device > tree yet. > > According to Sandor Yu from NXP, "the FDCC clock is not for HDMITX > in desgin, but it is part of HDMI domain that needed by HDMITX. > So I think it is reasonable added it to the power domain driver." > > The driver also supports two power domains which are missing from the binding > that also fix an issue with resuming from suspend. > > Signed-off-by: Adam Ford > --- > V2: Update commit message to both show error and give a bit more > background. > Add missing power domains hdcp and hdrv as pointed out by Marek Vasut > --- > .../soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml | 22 ++++++++--- > 1 file changed, 14 insertions(+), 8 deletions(-) > Reviewed-by: Rob Herring
Re: [PATCH] dt-bindings: drm/bridge: ti-sn65dsi86: Fix bouncing @codeaurora address
On Fri, 02 Feb 2024 13:23:29 -0700, Jeffrey Hugo wrote: > The servers for the @codeaurora domain are long retired and any messages > sent there bounce. Sandeep Panda's email address is no longer valid and > should be repleaced. However Sandeep has left the company and has not > been active sice, therefore it looks like this binding is orphaned. > > Doug is listed as the reviewer for this file in MAINTAINERS and has > volunteered to be listed within the file as the binding maintainer. > Therefore replace Sandeep with Doug to make the documentation current. > > Signed-off-by: Jeffrey Hugo > --- > .../devicetree/bindings/display/bridge/ti,sn65dsi86.yaml| 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Acked-by: Rob Herring
Re: [PATCH] dt-bindings: backlight: qcom-wled: Fix bouncing email addresses
On Fri, 02 Feb 2024 11:01:51 -0700, Jeffrey Hugo wrote: > Bjorn is no longer at Linaro. Update his email address to @kernel to > match the .mailmap entry. > > The servers for @codeaurora are long retired and messages sent there > will bounce. Update Kiran's email address to match the .mailmap entry. > > This will help anyone that is looking to reach out about this binding > and is not using .mailmap to pre-process their message. > > Signed-off-by: Jeffrey Hugo > --- > .../devicetree/bindings/leds/backlight/qcom-wled.yaml | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > Acked-by: Rob Herring
Re: [PATCH] dt-bindings: display: msm: sm8650-mdss: Add missing explicit "additionalProperties"
On Sat, Feb 03, 2024 at 03:55:54AM +0100, Dmitry Baryshkov wrote: > On Fri, 2 Feb 2024 at 23:23, Rob Herring wrote: > > > > In order to check schemas for missing additionalProperties or > > unevaluatedProperties, cases allowing extra properties must be explicit. > > > > Signed-off-by: Rob Herring > > Reviewed-by: Dmitry Baryshkov > > Rob, if you need it for some rework, please feel free to pick it into > your tree, otherwise I'll pick it for msm-next in the next few days. msm-next is fine. Rob
[PATCH] dt-bindings: display: msm: sm8650-mdss: Add missing explicit "additionalProperties"
In order to check schemas for missing additionalProperties or unevaluatedProperties, cases allowing extra properties must be explicit. Signed-off-by: Rob Herring --- .../devicetree/bindings/display/msm/qcom,sm8650-mdss.yaml | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8650-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8650-mdss.yaml index bd9dc93d..24cece1e888b 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sm8650-mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8650-mdss.yaml @@ -37,18 +37,21 @@ properties: patternProperties: "^display-controller@[0-9a-f]+$": type: object +additionalProperties: true properties: compatible: const: qcom,sm8650-dpu "^displayport-controller@[0-9a-f]+$": type: object +additionalProperties: true properties: compatible: const: qcom,sm8650-dp "^dsi@[0-9a-f]+$": type: object +additionalProperties: true properties: compatible: items: @@ -57,6 +60,7 @@ patternProperties: "^phy@[0-9a-f]+$": type: object +additionalProperties: true properties: compatible: const: qcom,sm8650-dsi-phy-4nm -- 2.43.0
Re: [PATCH v3 06/24] media: platform: switch to use of_graph_get_next_device_endpoint()
On Wed, Jan 31, 2024 at 05:05:34AM +, Kuninori Morimoto wrote:
> of_graph_get_next_endpoint() is now renamed to
> of_graph_get_next_device_endpoint(). Switch to it.
>
> Signed-off-by: Kuninori Morimoto
> ---
> drivers/media/platform/atmel/atmel-isi.c | 4 ++--
> drivers/media/platform/intel/pxa_camera.c| 2 +-
> drivers/media/platform/microchip/microchip-sama5d2-isc.c | 2 +-
> drivers/media/platform/microchip/microchip-sama7g5-isc.c | 2 +-
> drivers/media/platform/qcom/camss/camss.c| 2 +-
> drivers/media/platform/renesas/renesas-ceu.c | 2 +-
> drivers/media/platform/samsung/exynos4-is/fimc-is.c | 2 +-
> drivers/media/platform/samsung/exynos4-is/mipi-csis.c| 2 +-
> drivers/media/platform/st/stm32/stm32-dcmi.c | 4 ++--
> drivers/media/platform/ti/am437x/am437x-vpfe.c | 2 +-
> drivers/media/platform/ti/davinci/vpif.c | 3 +--
> drivers/media/platform/ti/davinci/vpif_capture.c | 3 +--
> drivers/media/platform/video-mux.c | 2 +-
> drivers/media/platform/xilinx/xilinx-vipp.c | 2 +-
> 14 files changed, 16 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/media/platform/atmel/atmel-isi.c
> b/drivers/media/platform/atmel/atmel-isi.c
> index 4046212d48b4..4317750d05ad 100644
> --- a/drivers/media/platform/atmel/atmel-isi.c
> +++ b/drivers/media/platform/atmel/atmel-isi.c
> @@ -831,7 +831,7 @@ static int atmel_isi_parse_dt(struct atmel_isi *isi,
> isi->pdata.full_mode = 1;
> isi->pdata.frate = ISI_CFG1_FRATE_CAPTURE_ALL;
>
> - np = of_graph_get_next_endpoint(np, NULL);
> + np = of_graph_get_next_device_endpoint(np, NULL);
Same comment on using of_graph_get_endpoint_by_regs().
> if (!np) {
> dev_err(>dev, "Could not find the endpoint\n");
> return -EINVAL;
> @@ -1155,7 +1155,7 @@ static int isi_graph_init(struct atmel_isi *isi)
> struct device_node *ep;
> int ret;
>
> - ep = of_graph_get_next_endpoint(isi->dev->of_node, NULL);
> + ep = of_graph_get_next_device_endpoint(isi->dev->of_node, NULL);
> if (!ep)
> return -EINVAL;
>
> diff --git a/drivers/media/platform/intel/pxa_camera.c
> b/drivers/media/platform/intel/pxa_camera.c
> index 59b89e421dc2..f2175c03502b 100644
> --- a/drivers/media/platform/intel/pxa_camera.c
> +++ b/drivers/media/platform/intel/pxa_camera.c
> @@ -2207,7 +2207,7 @@ static int pxa_camera_pdata_from_dt(struct device *dev,
> pcdev->mclk = mclk_rate;
> }
>
> - np = of_graph_get_next_endpoint(np, NULL);
> + np = of_graph_get_next_device_endpoint(np, NULL);
> if (!np) {
> dev_err(dev, "could not find endpoint\n");
> return -EINVAL;
> diff --git a/drivers/media/platform/microchip/microchip-sama5d2-isc.c
> b/drivers/media/platform/microchip/microchip-sama5d2-isc.c
> index 5ac149cf3647..201049c047b0 100644
> --- a/drivers/media/platform/microchip/microchip-sama5d2-isc.c
> +++ b/drivers/media/platform/microchip/microchip-sama5d2-isc.c
> @@ -363,7 +363,7 @@ static int isc_parse_dt(struct device *dev, struct
> isc_device *isc)
> while (1) {
> struct v4l2_fwnode_endpoint v4l2_epn = { .bus_type = 0 };
>
> - epn = of_graph_get_next_endpoint(np, epn);
> + epn = of_graph_get_next_device_endpoint(np, epn);
Looks like this should use the iterator?
> if (!epn)
> return 0;
>
> diff --git a/drivers/media/platform/microchip/microchip-sama7g5-isc.c
> b/drivers/media/platform/microchip/microchip-sama7g5-isc.c
> index 73445f33d26b..b617a9bcd398 100644
> --- a/drivers/media/platform/microchip/microchip-sama7g5-isc.c
> +++ b/drivers/media/platform/microchip/microchip-sama7g5-isc.c
> @@ -349,7 +349,7 @@ static int xisc_parse_dt(struct device *dev, struct
> isc_device *isc)
> while (1) {
> struct v4l2_fwnode_endpoint v4l2_epn = { .bus_type = 0 };
>
> - epn = of_graph_get_next_endpoint(np, epn);
> + epn = of_graph_get_next_device_endpoint(np, epn);
> if (!epn)
> return 0;
>
> diff --git a/drivers/media/platform/qcom/camss/camss.c
> b/drivers/media/platform/qcom/camss/camss.c
> index 8e78dd8d5961..cbb6f88cfe4a 100644
> --- a/drivers/media/platform/qcom/camss/camss.c
> +++ b/drivers/media/platform/qcom/camss/camss.c
> @@ -1136,7 +1136,7 @@ static int camss_of_parse_ports(struct camss *camss)
> struct device_node *remote = NULL;
> int ret, num_subdevs = 0;
>
> - for_each_endpoint_of_node(dev->of_node, node) {
> + for_each_device_endpoint_of_node(dev->of_node, node) {
> struct camss_async_subdev *csd;
>
> if (!of_device_is_available(node))
> diff --git a/drivers/media/platform/renesas/renesas-ceu.c
> b/drivers/media/platform/renesas/renesas-ceu.c
> index
Re: [PATCH v3 05/24] media: i2c: switch to use of_graph_get_next_device_endpoint()
On Wed, Jan 31, 2024 at 05:05:27AM +, Kuninori Morimoto wrote:
> of_graph_get_next_endpoint() is now renamed to
> of_graph_get_next_device_endpoint(). Switch to it.
>
> Signed-off-by: Kuninori Morimoto
> ---
> drivers/media/i2c/adv7343.c | 2 +-
> drivers/media/i2c/adv748x/adv748x-core.c | 2 +-
> drivers/media/i2c/adv7604.c | 2 +-
> drivers/media/i2c/isl7998x.c | 2 +-
> drivers/media/i2c/max9286.c | 2 +-
> drivers/media/i2c/mt9p031.c | 2 +-
> drivers/media/i2c/mt9v032.c | 2 +-
> drivers/media/i2c/ov2659.c | 2 +-
> drivers/media/i2c/ov5645.c | 2 +-
> drivers/media/i2c/ov5647.c | 2 +-
> drivers/media/i2c/s5c73m3/s5c73m3-core.c | 2 +-
> drivers/media/i2c/s5k5baf.c | 2 +-
> drivers/media/i2c/tc358743.c | 2 +-
> drivers/media/i2c/tda1997x.c | 2 +-
> drivers/media/i2c/tvp514x.c | 2 +-
> drivers/media/i2c/tvp5150.c | 4 ++--
> drivers/media/i2c/tvp7002.c | 2 +-
> 17 files changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/media/i2c/adv7343.c b/drivers/media/i2c/adv7343.c
> index ff21cd4744d3..7e4eb2f8bf0d 100644
> --- a/drivers/media/i2c/adv7343.c
> +++ b/drivers/media/i2c/adv7343.c
> @@ -403,7 +403,7 @@ adv7343_get_pdata(struct i2c_client *client)
> if (!IS_ENABLED(CONFIG_OF) || !client->dev.of_node)
> return client->dev.platform_data;
>
> - np = of_graph_get_next_endpoint(client->dev.of_node, NULL);
> + np = of_graph_get_next_device_endpoint(client->dev.of_node, NULL);
This is assuming there's just 1 port and 1 endpoint, but let's be
specific as the bindings are (first endpoint on port 0):
of_graph_get_endpoint_by_regs(client->dev.of_node, 0, -1);
Note we could ask for endpoint 0 here, but the bindings generally allow
for more than 1.
I imagine most of the other cases here are the same.
> if (!np)
> return NULL;
>
> diff --git a/drivers/media/i2c/adv748x/adv748x-core.c
> b/drivers/media/i2c/adv748x/adv748x-core.c
> index 3eb6d5e8f082..4e9e4cef8954 100644
> --- a/drivers/media/i2c/adv748x/adv748x-core.c
> +++ b/drivers/media/i2c/adv748x/adv748x-core.c
> @@ -657,7 +657,7 @@ static int adv748x_parse_dt(struct adv748x_state *state)
> bool in_found = false;
> int ret;
>
> - for_each_endpoint_of_node(state->dev->of_node, ep_np) {
> + for_each_device_endpoint_of_node(state->dev->of_node, ep_np) {
I would skip the rename.
Rob
Re: [PATCH v2 1/6] dt-bindings: display: rockchip: rockchip, dw-hdmi: remove port property
On Wed, 31 Jan 2024 22:14:29 +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 > --- > > Changed V2: > rename title from deprecate to remove > reword > --- > .../display/rockchip/rockchip,dw-hdmi.yaml| 24 +++ > 1 file changed, 20 insertions(+), 4 deletions(-) > Reviewed-by: Rob Herring
Re: [linux][PATCH v5 0/3] Convert Microchip's HLCDC Text based DT bindings to JSON schema
On Thu, Feb 01, 2024 at 03:38:37AM +, dharm...@microchip.com wrote: > Hi Rob, > > On 31/01/24 9:05 am, Dharma B - I70843 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. > > > > I would want to know if I can have the examples in display and pwm > bindings separately or if I have to delete them from both and have a > single, comprehensive example in mfd binding. I'm a little puzzled about > this. The strong preference is 1 complete example in the MFD binding. That avoids 2 copies of the same thing, issues with incomplete examples, and temporary warnings bisecting the series. Rob
Re: [PATCH v1 1/6] dt-bindings: display: rockchip: rockchip, dw-hdmi: deprecate port property
On Tue, Jan 30, 2024 at 06:18:49PM +, Conor Dooley wrote: > 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? That means the deprecated way will always have warnings which makes documenting the deprecated stuff a bit pointless. Technically, new required properties are ABI break and something I'm working on making the tools check (by comparing 2 versions of schemas). That said, if all the upstream dts files are fixed already, then I don't care too much. > > 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. graph.yaml has a check that effectively does that. Rob
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. Fix example.
>
> 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>;
It makes more sense to keep reg-io-width together with reg.
> -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
>
Re: [PATCH] dt-bindings: display: nxp,tda998x: Fix 'audio-ports' constraints
On Mon, 22 Jan 2024 14:49:58 -0600, Rob Herring wrote: > The constraints for 'audio-ports' don't match the description. There can > be 1 or 2 DAI entries and each entry is exactly 2 values. Also, the > values' sizes are 32-bits, not 8-bits. Move the size constraints to the > outer dimension (number of DAIs) and add constraints on inner array > values. > > Signed-off-by: Rob Herring > --- > .../devicetree/bindings/display/bridge/nxp,tda998x.yaml| 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > Applied, thanks!
Re: [PATCH v4 13/14] dt-bindings: gpu: mali-valhall-csf: Add support for Arm Mali CSF GPUs
On Mon, Jan 22, 2024 at 05:30:44PM +0100, Boris Brezillon wrote:
> From: Liviu Dudau
>
> Arm has introduced a new v10 GPU architecture that replaces the Job Manager
> interface with a new Command Stream Frontend. It adds firmware driven
> command stream queues that can be used by kernel and user space to submit
> jobs to the GPU.
>
> Add the initial schema for the device tree that is based on support for
> RK3588 SoC. The minimum number of clocks is one for the IP, but on Rockchip
> platforms they will tend to expose the semi-independent clocks for better
> power management.
>
> v4:
> - Fix formatting issue
>
> v3:
> - Cleanup commit message to remove redundant text
> - Added opp-table property and re-ordered entries
> - Clarified power-domains and power-domain-names requirements for RK3588.
> - Cleaned up example
>
> Note: power-domains and power-domain-names requirements for other platforms
> are still work in progress, hence the bindings are left incomplete here.
>
> v2:
> - New commit
>
> Signed-off-by: Liviu Dudau
> Cc: Krzysztof Kozlowski
> Cc: Rob Herring
> Cc: Conor Dooley
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Boris Brezillon
> ---
> .../bindings/gpu/arm,mali-valhall-csf.yaml| 147 ++
> 1 file changed, 147 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
>
> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
> b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
> new file mode 100644
> index ..be1f6bacc3f3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
> @@ -0,0 +1,147 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/gpu/arm,mali-valhall-csf.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ARM Mali Valhall GPU
> +
> +maintainers:
> + - Liviu Dudau
> + - Boris Brezillon
> +
> +properties:
> + $nodename:
> +pattern: '^gpu@[a-f0-9]+$'
> +
> + compatible:
> +oneOf:
> + - items:
> + - enum:
> + - rockchip,rk3588-mali
> + - const: arm,mali-valhall-csf # Mali Valhall GPU model/revision
> is fully discoverable
> +
> + reg:
> +maxItems: 1
> +
> + interrupts:
> +items:
> + - description: Job interrupt
> + - description: MMU interrupt
> + - description: GPU interrupt
> +
> + interrupt-names:
> +items:
> + - const: job
> + - const: mmu
> + - const: gpu
> +
> + clocks:
> +minItems: 1
> +maxItems: 3
> +
> + clock-names:
> +minItems: 1
> +items:
> + - const: core
> + - const: coregroup
> + - const: stacks
> +
> + mali-supply: true
> +
> + operating-points-v2: true
> + opp-table:
> +type: object
> +
> + power-domains:
> +minItems: 1
> +maxItems: 5
> +
> + power-domain-names:
> +minItems: 1
> +maxItems: 5
> +
> + sram-supply: true
> +
> + "#cooling-cells":
> +const: 2
> +
> + dynamic-power-coefficient:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description:
> + A u32 value that represents the running time dynamic
> + power coefficient in units of uW/MHz/V^2. The
> + coefficient can either be calculated from power
> + measurements or derived by analysis.
> +
> + The dynamic power consumption of the GPU is
> + proportional to the square of the Voltage (V) and
> + the clock frequency (f). The coefficient is used to
> + calculate the dynamic power as below -
> +
> + Pdyn = dynamic-power-coefficient * V^2 * f
> +
> + where voltage is in V, frequency is in MHz.
> +
> + dma-coherent: true
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - interrupt-names
> + - clocks
> + - mali-supply
> +
> +additionalProperties: false
> +
> +allOf:
> + - if:
> + properties:
> +compatible:
> + contains:
> +const: rockchip,rk3588-mali
> +then:
> + properties:
> +clocks:
> + minItems: 3
> +power-domains:
> + maxItems: 1
> +power-domain-names: false
> +
> +examples:
> + - |
> +#include
> +#include
> +#include
> +#include
> +
> +gpu: gpu@fb00 {
> +compatible = "rockchip,rk3588-mali", "arm,mali-valhall-csf";
> +reg = <0xfb00 0x20>;
>
Re: [PATCH 1/3] dt-bindings: display: bridge: add sam9x7-lvds compatible
On Tue, Jan 23, 2024 at 03:39:13AM +, dharm...@microchip.com wrote: > Hi Conor, > > On 22/01/24 10:07 pm, Conor Dooley wrote: > > 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. > Yes, you are correct. Only sam9x72 and sam9x75 have LVDS support, while > sam9x70 does not. I will revise the compatibility to include both > sam9x72 and sam9x75, as outlined below: > > properties: >compatible: > enum: >- microchip,sam9x72-lvds >- microchip,sam9x75-lvds I would presume these 2 are the same, but the above implies they aren't. I think what you had is fine assuming these are all fundamentally the same part with just packaging or fused off h/w differences. Rob
Re: [drm-drm-misc:drm-misc-next] dt-bindings: nt35510: document 'port' property
On Sat, Jan 27, 2024 at 04:28:08PM +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
>
> ---
>
> .../display/panel/novatek,nt35510.yaml| 34 +++
> 1 file changed, 34 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml
> b/Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml
> index a4afaff483b7..72913719df23 100644
> --- a/Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml
> @@ -31,6 +31,22 @@ properties:
>vddi-supply:
> description: regulator that supplies the vddi voltage
>backlight: true
> + port:
> +$ref: /schemas/graph.yaml#/properties/port
Just 'port: true'
> +
> +if:
> + properties:
> +compatible:
> + contains:
> +enum:
> + - frida,frd400b25025
> +then:
> + required:
> +- port
> +
> +else:
> + properties:
> +port: false
No need for this. 'port' should be allowed for everyone.
>
> required:
>- compatible
> @@ -54,5 +70,23 @@ examples:
> backlight = <_bl>;
> };
> };
> + - |
> +dsi {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +panel@0 {
> +compatible = "frida,frd400b25025", "novatek,nt35510";
> +vddi-supply = <_3v3>;
> +vdd-supply = <_3v3>;
> +reg = <0>; /* dsi virtual channel (0..3) */
> +reset-gpios = < 15 GPIO_ACTIVE_LOW>;
>
> +port {
> +dsi_panel_in: endpoint {
> +remote-endpoint = <_out>;
> +};
> +};
> +};
> +};
> ...
> --
> 2.43.0
>
