On 6/26/25 13:48, Bryan O'Donoghue wrote:
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-0795643fc...@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.
The problem with private communications is that it produces
sacral knowledge.
8939 should be like 8916 because these are devices of a similar class.
What's about MSM8953 then?
Please see commit c830aff08d51 ("media: dt-bindings: Add qcom,msm8953-camss").
x1e has a particular order if a new device x1e+1 comes along with a new
register then
I think I personally haven't understood what was meant by "devices of a
class" but its clearer now.
And I still didn't get it, how to read this "devices of a class"?
In particular why is MSM8939 a device of MSM8916 class and MSM8953 is
not?
For sake of simplicity I list only accepted CAMSS dt bindings:
qcom,msm8916-camss.yaml
qcom,msm8953-camss.yaml
qcom,msm8996-camss.yaml
qcom,sc7280-camss.yaml
qcom,sc8280xp-camss.yaml
qcom,sdm660-camss.yaml
qcom,sdm670-camss.yaml
qcom,sdm845-camss.yaml
qcom,sm8250-camss.yaml
qcom,sm8550-camss.yaml
qcom,x1e80100-camss.yaml
I kindly ask to select a number of class defining IPs from the list,
so that all next ones will derive from those only, and not from
"another class". It's a task for a DT maintainer I presume.
Before completing this and getting a common understanding all next
work to provide CAMSS suppor for new platforms is not directed by
any policy, because the policy "do as it's been done before" is
applied inconsistently.
--
Best wishes,
Vladimir
