From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>,
Geert Uytterhoeven <geert+renesas@glider.be>,
Magnus Damm <magnus.damm@gmail.com>,
linux-media@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] media: dt-bindings: renesas,fcp: add top-level constraints
Date: Sun, 18 Aug 2024 20:51:53 +0200 [thread overview]
Message-ID: <30aeabc2-1a6e-440e-bf1d-c58b96976041@linaro.org> (raw)
In-Reply-To: <20240818175020.GE29465@pendragon.ideasonboard.com>
On 18/08/2024 19:50, Laurent Pinchart wrote:
> On Sun, Aug 18, 2024 at 07:45:55PM +0200, Krzysztof Kozlowski wrote:
>> On 18/08/2024 19:37, Laurent Pinchart wrote:
>>> On Sun, Aug 18, 2024 at 07:29:36PM +0200, Krzysztof Kozlowski wrote:
>>>> Properties with variable number of items per each device are expected to
>>>> have widest constraints in top-level "properties:" block and further
>>>> customized (narrowed) in "if:then:". Add missing top-level constraints
>>>> for clocks and clock-names.
>>>
>>> In this specific case I think it's fine, but generally speaking, how do
>>> you handle that rule when different variants have completely different
>>> clocks, not just lack some of the clocks ?
>>
>> I don't understand the problem. We handle it as usual, as in all
>> bindings. Here there is no such case, thus names go to the top.
>
> That answers the question, the clock names would still be
> variant-specific in that case.
>
> While the change here won't cause validation failures, I think it's
> confusing to define the clock names at the top level, knowing they don't
> apply to some of the variants, if we don't also define the description
> there. I'd move either both or neither.
First, they apply to ALL variants using clock-names.
Second, we want such lists, like clocks/resets/interrupts, to share as
much as possible between variants, e.g. keep the same order. Having
clock-names listed at top-level encourages this and prevents people from
adding new binding with:
"vclk", "aclk", "pclk",
"new_clock_but_i_want_to_mess_order_of_everything_because_i_can"
>
>>>>
>>>> - clock-names: true
>>>> + clock-names:
>>>> + items:
>>>> + - const: aclk
>>>> + - const: pclk
>>>> + - const: vclk
>>>>
>>>> iommus:
>>>> maxItems: 1
>>>> @@ -71,11 +77,6 @@ allOf:
>>>> - description: Main clock
>>>> - description: Register access clock
>>>> - description: Video clock
>>>> - clock-names:
>>>> - items:
>>>> - - const: aclk
>>>> - - const: pclk
>>>> - - const: vclk
>>>
>>> Any specific reason to move the clock names but not the descriptions ?
>>> The assymetry bothers me.
>>
>> The other variant does not have description of the first clock, so
>> moving it would be incorrect. Moving names is correct, because other
>> variant does not have clock-names at all.
>
> I don't think it's incorrect, when the FCP has a single clock, it's the
> main clock.
Could be main clock, could be something else for me - I did not
investigate enough. If it is main clock, I will move the description as
well.
Best regards,
Krzysztof
next prev parent reply other threads:[~2024-08-18 18:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-18 17:29 [PATCH 1/2] media: dt-bindings: renesas,fcp: add top-level constraints Krzysztof Kozlowski
2024-08-18 17:29 ` [PATCH 2/2] media: dt-bindings: renesas,vsp1: " Krzysztof Kozlowski
2024-08-18 17:39 ` Laurent Pinchart
2024-08-19 17:14 ` Conor Dooley
2024-08-18 17:37 ` [PATCH 1/2] media: dt-bindings: renesas,fcp: " Laurent Pinchart
2024-08-18 17:45 ` Krzysztof Kozlowski
2024-08-18 17:50 ` Laurent Pinchart
2024-08-18 18:51 ` Krzysztof Kozlowski [this message]
2024-08-19 17:14 ` Conor Dooley
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=30aeabc2-1a6e-440e-bf1d-c58b96976041@linaro.org \
--to=krzysztof.kozlowski@linaro.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=geert+renesas@glider.be \
--cc=kieran.bingham+renesas@ideasonboard.com \
--cc=krzk+dt@kernel.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=mchehab@kernel.org \
--cc=robh@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox