All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Nikolaus Schaller" <hns@goldelico.com>
To: Maxime Ripard <maxime@cerno.tech>
Cc: Sam Ravnborg <sam@ravnborg.org>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	Paul Cercueil <paul@crapouillou.net>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Kees Cook <keescook@chromium.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	Andrzej Hajda <a.hajda@samsung.com>,
	Neil Armstrong <narmstrong@baylibre.com>,
	Robert Foss <robert.foss@linaro.org>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	Ezequiel Garcia <ezequiel@collabora.com>,
	Harry Wentland <harry.wentland@amd.com>,
	Hans Verkuil <hverkuil-cisco@xs4all.nl>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>, Paul Boddie <paul@boddie.org.uk>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>,
	linux-mips <linux-mips@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Discussions about the Letux Kernel 
	<letux-kernel@openphoenux.org>, Jonas Karlman <jonas@kwiboo.se>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Rob Herring <robh@kernel.org>
Subject: Re: [PATCH v4 03/10] dt-bindings: display: Add ingenic,jz4780-dw-hdmi DT Schema
Date: Tue, 28 Sep 2021 11:34:22 +0200	[thread overview]
Message-ID: <A17F7F48-5A3E-4F23-8C40-156275F5AEEE@goldelico.com> (raw)
In-Reply-To: <20210928091807.xgqxemjizlobpcxy@gilmour>



> Am 28.09.2021 um 11:18 schrieb Maxime Ripard <maxime@cerno.tech>:
> 
> On Tue, Sep 28, 2021 at 10:59:45AM +0200, H. Nikolaus Schaller wrote:
>>>> +properties:
>>>> +  compatible:
>>>> +    items:
>>>> +      - const: ingenic,jz4780-dw-hdmi
>>> 
>>> This can just be a const, there's no need for the items
>> 
>> Maybe starting with an enum is better if more compatible strings are to be added.
> 
> it's still fairly easy to change if needed, there's no need to confuse
> anyone.
> 
>>> 
>>>> +  reg-io-width:
>>>> +    const: 4
>>> 
>>> If it's fixed, why do you need it in the first place?
>> 
>> There is a fixed default of 1 if not specified.
> 
> My point was more about why do you need to have that property at all?
> Can't you just drop it and assume that the register width is 32 bits if
> it's all you will ever run on?

No, please see bridge/synopsys,dw-hdmi.yaml where it is derived from:

  reg-io-width:
    description:
      Width (in bytes) of the registers specified by the reg property.
    allOf:
      - $ref: /schemas/types.yaml#/definitions/uint32
      - enum: [1, 4]
    default: 1

Other bindings define it explicitly to be 4, e.g.

Documentation//devicetree/bindings/display/intel,keembay-msscam.yaml:  reg-io-width:
Documentation//devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml:  reg-io-width:

Therefore I'd assume that a regmap is not properly set up
if we don't require the DTS to include it with const: 4.

> 
>>>> +  clocks:
>>>> +    maxItems: 2
>>>> +    description: Clock specifiers for isrf and iahb clocks
>>> 
>>> This can be defined as
>>> 
>>> clocks:
>>> items:
>>>   - description: isrf
>>>   - description: iahb
>>> 
>>> A better description about what these clocks are would be nice as well
>> 
>> Generally I see that this all is nowadays not independent of
>> 
>> Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml
>> 
>> where there is already a description.
> 
> Ok, good then
> 
>> On the other hand every SoC specialization runs its own copy. e.g.
>> 
>> Documentation/devicetree/bindings/display/imx/fsl,imx6-hdmi.yaml
>> Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yam
>> 
>>> 
>>>> +  clock-names:
>>>> +    items:
>>>> +      - const: isfr
>>> 
>>> Is it isfr or isrf?
>> 
>> isfr. Seems to be a typo in the description. See
>> bridge/synopsys,dw-hdmi.yaml#
>> 
>> One question to the yaml specialists:
>> 
>> since ../bridge/synopsys,dw-hdmi.yaml# already defines this, do we
>> have to repeat? Or can we reduce to just the changes?
> 
> If you add the ref you mentionned above, you don't have to repeat

Nice. It defines:

  clocks:
    minItems: 2
    maxItems: 5
    items:
      - description: The bus clock for either AHB and APB
      - description: The internal register configuration clock
    additionalItems: true

> yourself indeed. You can just put clock-names: true

Or should we do

  clocks:
    maxItems: 2
    additionalItems: false

> 
>> [I am still not familiar enough with the yaml stuff to understand if
>> it has sort of inheritance like device tree include files, so that you
>> just have to change relevant properties]
> 
> Kind of, but not entirely. schemas are all applied separately, unlike DT
> includes that will just expand to one big DT. In practice, it means that
> your device must validate against all the schemas, not just the sum of
> them.
> 
> For example, if you have a generic schema that has:
> 
> properties:
>  compatible:
>    const: vendor,my-generic-compatible
> 
> 
> and your schema that extends the generic binding, with a ref to the
> generic one that has:
> 
> properties:
>  compatible:
>    items:
>      - const: other-vendor,my-device-compatible
>      - const: vendor,my-generic-compatible
> 
> 
> It will still fail since the generic schema expects only a single
> compatible, whereas your device would have two.

Ok, I see. it is not a simple "overwrite" rule.

> 
>>> 
>>>> +      - const: iahb
>> 
>> would it make sense to add additionalItems: false here?
>> 
>> In the jz4780 case there are just two clocks while other specializations
>> use more and synopsys,dw-hdmi.yaml# defines additionalItems: true.
> 
> If you want to refine the generic one, and it's all the clocks you ever
> expect then there's no need for additionalItems

Ok.

> 
>>> 
>>>> +    description: An I2C interface if the internal DDC I2C driver is not to be used
>>>> +  ports: true
>>> 
>>> If there's a single port, you don't need ports
>> 
>> There can be two ports - one for input from LCDC and one
>> for output (HDMI connector). But explicitly defining an output
>> port is optional to some extent (depending on driver structure).
> 
> This needs to be defined then (and port@0 made mandatory)

Ok. I'll try to make the best out of it for v5 series. Maybe
it is still not perfect by then, but close...

> 
> Maxime

BR and thanks,
Nikolaus


WARNING: multiple messages have this Message-ID (diff)
From: "H. Nikolaus Schaller" <hns@goldelico.com>
To: Maxime Ripard <maxime@cerno.tech>
Cc: Sam Ravnborg <sam@ravnborg.org>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	Paul Cercueil <paul@crapouillou.net>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Kees Cook <keescook@chromium.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	Andrzej Hajda <a.hajda@samsung.com>,
	Neil Armstrong <narmstrong@baylibre.com>,
	Robert Foss <robert.foss@linaro.org>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	Ezequiel Garcia <ezequiel@collabora.com>,
	Harry Wentland <harry.wentland@amd.com>,
	Hans Verkuil <hverkuil-cisco@xs4all.nl>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>, Paul Boddie <paul@boddie.org.uk>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	linux-mips <linux-mips@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Discussions about the Letux Kernel <letux-kernel@openphoenux.org>,
	Jonas Karlman <jonas@kwiboo.se>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Rob Herring <robh@kernel.org>
Subject: Re: [PATCH v4 03/10] dt-bindings: display: Add ingenic, jz4780-dw-hdmi DT Schema
Date: Tue, 28 Sep 2021 11:34:22 +0200	[thread overview]
Message-ID: <A17F7F48-5A3E-4F23-8C40-156275F5AEEE@goldelico.com> (raw)
In-Reply-To: <20210928091807.xgqxemjizlobpcxy@gilmour>



> Am 28.09.2021 um 11:18 schrieb Maxime Ripard <maxime@cerno.tech>:
> 
> On Tue, Sep 28, 2021 at 10:59:45AM +0200, H. Nikolaus Schaller wrote:
>>>> +properties:
>>>> +  compatible:
>>>> +    items:
>>>> +      - const: ingenic,jz4780-dw-hdmi
>>> 
>>> This can just be a const, there's no need for the items
>> 
>> Maybe starting with an enum is better if more compatible strings are to be added.
> 
> it's still fairly easy to change if needed, there's no need to confuse
> anyone.
> 
>>> 
>>>> +  reg-io-width:
>>>> +    const: 4
>>> 
>>> If it's fixed, why do you need it in the first place?
>> 
>> There is a fixed default of 1 if not specified.
> 
> My point was more about why do you need to have that property at all?
> Can't you just drop it and assume that the register width is 32 bits if
> it's all you will ever run on?

No, please see bridge/synopsys,dw-hdmi.yaml where it is derived from:

  reg-io-width:
    description:
      Width (in bytes) of the registers specified by the reg property.
    allOf:
      - $ref: /schemas/types.yaml#/definitions/uint32
      - enum: [1, 4]
    default: 1

Other bindings define it explicitly to be 4, e.g.

Documentation//devicetree/bindings/display/intel,keembay-msscam.yaml:  reg-io-width:
Documentation//devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml:  reg-io-width:

Therefore I'd assume that a regmap is not properly set up
if we don't require the DTS to include it with const: 4.

> 
>>>> +  clocks:
>>>> +    maxItems: 2
>>>> +    description: Clock specifiers for isrf and iahb clocks
>>> 
>>> This can be defined as
>>> 
>>> clocks:
>>> items:
>>>   - description: isrf
>>>   - description: iahb
>>> 
>>> A better description about what these clocks are would be nice as well
>> 
>> Generally I see that this all is nowadays not independent of
>> 
>> Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml
>> 
>> where there is already a description.
> 
> Ok, good then
> 
>> On the other hand every SoC specialization runs its own copy. e.g.
>> 
>> Documentation/devicetree/bindings/display/imx/fsl,imx6-hdmi.yaml
>> Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yam
>> 
>>> 
>>>> +  clock-names:
>>>> +    items:
>>>> +      - const: isfr
>>> 
>>> Is it isfr or isrf?
>> 
>> isfr. Seems to be a typo in the description. See
>> bridge/synopsys,dw-hdmi.yaml#
>> 
>> One question to the yaml specialists:
>> 
>> since ../bridge/synopsys,dw-hdmi.yaml# already defines this, do we
>> have to repeat? Or can we reduce to just the changes?
> 
> If you add the ref you mentionned above, you don't have to repeat

Nice. It defines:

  clocks:
    minItems: 2
    maxItems: 5
    items:
      - description: The bus clock for either AHB and APB
      - description: The internal register configuration clock
    additionalItems: true

> yourself indeed. You can just put clock-names: true

Or should we do

  clocks:
    maxItems: 2
    additionalItems: false

> 
>> [I am still not familiar enough with the yaml stuff to understand if
>> it has sort of inheritance like device tree include files, so that you
>> just have to change relevant properties]
> 
> Kind of, but not entirely. schemas are all applied separately, unlike DT
> includes that will just expand to one big DT. In practice, it means that
> your device must validate against all the schemas, not just the sum of
> them.
> 
> For example, if you have a generic schema that has:
> 
> properties:
>  compatible:
>    const: vendor,my-generic-compatible
> 
> 
> and your schema that extends the generic binding, with a ref to the
> generic one that has:
> 
> properties:
>  compatible:
>    items:
>      - const: other-vendor,my-device-compatible
>      - const: vendor,my-generic-compatible
> 
> 
> It will still fail since the generic schema expects only a single
> compatible, whereas your device would have two.

Ok, I see. it is not a simple "overwrite" rule.

> 
>>> 
>>>> +      - const: iahb
>> 
>> would it make sense to add additionalItems: false here?
>> 
>> In the jz4780 case there are just two clocks while other specializations
>> use more and synopsys,dw-hdmi.yaml# defines additionalItems: true.
> 
> If you want to refine the generic one, and it's all the clocks you ever
> expect then there's no need for additionalItems

Ok.

> 
>>> 
>>>> +    description: An I2C interface if the internal DDC I2C driver is not to be used
>>>> +  ports: true
>>> 
>>> If there's a single port, you don't need ports
>> 
>> There can be two ports - one for input from LCDC and one
>> for output (HDMI connector). But explicitly defining an output
>> port is optional to some extent (depending on driver structure).
> 
> This needs to be defined then (and port@0 made mandatory)

Ok. I'll try to make the best out of it for v5 series. Maybe
it is still not perfect by then, but close...

> 
> Maxime

BR and thanks,
Nikolaus


  reply	other threads:[~2021-09-28  9:34 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-27 16:44 [PATCH v4 00/10] MIPS: JZ4780 and CI20 HDMI H. Nikolaus Schaller
2021-09-27 16:44 ` [PATCH v4 01/10] drm/ingenic: Fix drm_init error path if IPU was registered H. Nikolaus Schaller
2021-09-27 16:44 ` [PATCH v4 02/10] drm/ingenic: Add support for JZ4780 and HDMI output H. Nikolaus Schaller
2021-09-28  9:35   ` Paul Cercueil
2021-09-28 10:21     ` H. Nikolaus Schaller
2021-09-28 12:06       ` H. Nikolaus Schaller
2021-09-29 13:25         ` H. Nikolaus Schaller
2021-09-29 14:30         ` Paul Cercueil
2021-09-29 14:42           ` H. Nikolaus Schaller
2021-09-27 16:44 ` [PATCH v4 03/10] dt-bindings: display: Add ingenic,jz4780-dw-hdmi DT Schema H. Nikolaus Schaller
2021-09-27 16:44   ` [PATCH v4 03/10] dt-bindings: display: Add ingenic, jz4780-dw-hdmi " H. Nikolaus Schaller
2021-09-27 17:07   ` [PATCH v4 03/10] dt-bindings: display: Add ingenic,jz4780-dw-hdmi " maxime
2021-09-27 17:07     ` maxime
2021-09-28  8:59     ` H. Nikolaus Schaller
2021-09-28  8:59       ` [PATCH v4 03/10] dt-bindings: display: Add ingenic, jz4780-dw-hdmi " H. Nikolaus Schaller
2021-09-28  9:18       ` [PATCH v4 03/10] dt-bindings: display: Add ingenic,jz4780-dw-hdmi " Maxime Ripard
2021-09-28  9:18         ` Maxime Ripard
2021-09-28  9:34         ` H. Nikolaus Schaller [this message]
2021-09-28  9:34           ` [PATCH v4 03/10] dt-bindings: display: Add ingenic, jz4780-dw-hdmi " H. Nikolaus Schaller
2021-09-28  2:01   ` [PATCH v4 03/10] dt-bindings: display: Add ingenic,jz4780-dw-hdmi " Rob Herring
2021-09-28  2:01     ` Rob Herring
2021-09-27 16:44 ` [PATCH v4 04/10] drm/bridge: synopsis: Add mode_fixup and bridge timings support H. Nikolaus Schaller
2021-09-27 16:44 ` [PATCH v4 05/10] drm/bridge: synopsis: Fix to properly handle HPD H. Nikolaus Schaller
2021-09-27 17:00   ` Maxime Ripard
2021-09-27 17:00     ` Maxime Ripard
2021-09-27 17:53     ` H. Nikolaus Schaller
2021-09-27 16:44 ` [PATCH v4 06/10] drm/ingenic: Add dw-hdmi driver for jz4780 H. Nikolaus Schaller
2021-09-27 17:08   ` Maxime Ripard
2021-09-27 17:08     ` Maxime Ripard
2021-09-27 17:54     ` H. Nikolaus Schaller
2021-09-28 13:02   ` Neil Armstrong
2021-09-28 13:35     ` H. Nikolaus Schaller
2021-09-28 14:10   ` Paul Cercueil
2021-09-27 16:44 ` [PATCH v4 07/10] MIPS: DTS: jz4780: Account for Synopsys HDMI driver and LCD controllers H. Nikolaus Schaller
2021-09-27 16:44 ` [PATCH v4 08/10] MIPS: DTS: CI20: Add DT nodes for HDMI setup H. Nikolaus Schaller
2021-09-27 16:44 ` [PATCH v4 09/10] MIPS: defconfig: CI20: configure for DRM_DW_HDMI_JZ4780 H. Nikolaus Schaller
2021-09-27 16:44 ` [PATCH v4 10/10] drm/ingenic: add some jz4780 specific features H. Nikolaus Schaller
2021-09-28  9:58   ` Paul Cercueil
2021-09-28 10:06     ` H. Nikolaus Schaller
2021-09-28 11:50       ` H. Nikolaus Schaller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=A17F7F48-5A3E-4F23-8C40-156275F5AEEE@goldelico.com \
    --to=hns@goldelico.com \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=a.hajda@samsung.com \
    --cc=airlied@linux.ie \
    --cc=broonie@kernel.org \
    --cc=daniel@ffwll.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=ebiederm@xmission.com \
    --cc=ezequiel@collabora.com \
    --cc=geert+renesas@glider.be \
    --cc=harry.wentland@amd.com \
    --cc=hverkuil-cisco@xs4all.nl \
    --cc=jernej.skrabec@gmail.com \
    --cc=jonas@kwiboo.se \
    --cc=keescook@chromium.org \
    --cc=letux-kernel@openphoenux.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=maxime@cerno.tech \
    --cc=miquel.raynal@bootlin.com \
    --cc=narmstrong@baylibre.com \
    --cc=paul@boddie.org.uk \
    --cc=paul@crapouillou.net \
    --cc=robert.foss@linaro.org \
    --cc=robh+dt@kernel.org \
    --cc=robh@kernel.org \
    --cc=sam@ravnborg.org \
    --cc=tsbogend@alpha.franken.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.