[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d1b0b5c1-a031-4429-bb4b-ad8bc914c971@linaro.org>
Date: Thu, 26 Jun 2025 11:48:12 +0100
From: Bryan O'Donoghue <bryan.odonoghue@...aro.org>
To: Krzysztof Kozlowski <krzk@...nel.org>, vincent.knecht@...loo.org,
Robert Foss <rfoss@...nel.org>, Todor Tomov <todor.too@...il.com>,
Mauro Carvalho Chehab <mchehab@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
<conor+dt@...nel.org>, Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konradybcio@...nel.org>
Cc: linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
André Apitzsch <git@...tzsch.eu>,
phone-devel@...r.kernel.org, ~postmarketos/upstreaming@...ts.sr.ht,
Vladimir Zapolskiy <vladimir.zapolskiy@...aro.org>,
Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Subject: Re: [PATCH v5 3/4] media: dt-bindings: Add qcom,msm8939-camss
On 26/06/2025 11:28, Krzysztof Kozlowski wrote:
> On 26/06/2025 12:19, Bryan O'Donoghue wrote:
>> On 26/06/2025 11:00, Krzysztof Kozlowski wrote:
>>>> + reg-names:
>>>> + items:
>>>> + - const: csi_clk_mux
>>> No, I already provided arguments in two lengthy discussions - this is
>>> not sorted by name.
>>>
>>> Keep the same order as in previous device, so msm8916 for example. Or
>>> any other, but listen to some requests to sort it by some arbitrary rule
>>> which was never communicated by DT maintainers.
>>
>> I don't think if you look through the history that you can find a
>> consistent rule that was used to arrange the registers.
>>
>> So we are trying to have a consistent way of doing that. Thats why the
>> last number of additions have been sort by name, because it seemed to be
>> the most consistent.
>
>
> Why are we discussing it again? You asked me the same here:
> https://lore.kernel.org/all/8f11c99b-f3ca-4501-aec4-0795643fc3a9@kernel.org/
>
> and I already said - not sorting by name. You take the same order as
> previous.
>
> If you ever want to sort by name, answer to yourself:
> NO. Take the same order as other existing device.
>
> If you ever want to sort by value, answer to yourself:
> NO.
>
> You both came with some new, invented rules of sorting, applied it, and
> now you claim that "existing devices were sorted like that". What? NO!
>
> Best regards,
> Krzysztof
OK.
Discussed this on Slack with Krzysztof.
8939 should be like 8916 because these are devices of a similar class.
x1e has a particular order if a new device x1e+1 comes along with a new
register then
reg-names:
23 items:
24 - const: csid0
25 - const: csid1
26 - const: csid2
27 - const: csid_lite0
28 - const: csid_lite1
29 - const: csid_wrapper
30 - const: csiphy0
31 - const: csiphy1
32 - const: csiphy2
33 - const: csiphy4
34 - const: csitpg0
35 - const: csitpg1
36 - const: csitpg2
37 - const: vfe0
38 - const: vfe1
39 - const: vfe_lite0
40 - const: vfe_lite1
reg-names:
23 items:
24 - const: csid0
25 - const: csid1
26 - const: csid2
27 - const: csid_lite0
28 - const: csid_lite1
29 - const: csid_wrapper
30 - const: csiphy0
31 - const: csiphy1
32 - const: csiphy2
33 - const: csiphy4
34 - const: csitpg0
35 - const: csitpg1
36 - const: csitpg2
37 - const: vfe0
38 - const: vfe1
39 - const: vfe_lite0
40 - const: vfe_lite1
- NEW ENTRY GOES HERE csid3
A new SoC with a significantly different architecture could have
different ordering of regs.
The main block should go first which means the above should look like:
reg-names:
23 items:
24 - const: csid_wrapper
25 - const: csid0
26 - const: csid1
27 - const: csid2
28 - const: csid_lite0
29 - const: csid_lite1
30 - const: csiphy0
31 - const: csiphy1
32 - const: csiphy2
33 - const: csiphy4
34 - const: csitpg0
35 - const: csitpg1
36 - const: csitpg2
37 - const: vfe0
38 - const: vfe1
39 - const: vfe_lite0
40 - const: vfe_lite1
I think I personally haven't understood what was meant by "devices of a
class" but its clearer now.
Appreciate the explanation.
---
bod
Powered by blists - more mailing lists