Re: DT Query on "New Compatible vs New Property"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 4/11/2024 2:23 AM, Sudeep Holla wrote:
On Wed, Apr 10, 2024 at 09:55:24AM -0700, Nikunj Kela wrote:
On 3/19/2024 9:13 AM, Sudeep Holla wrote:
On Tue, Mar 19, 2024 at 03:41:40PM +0000, Srinivas Kandagatla wrote:
On 19/03/2024 15:17, Sudeep Holla wrote:
I am not debating on the implementation just to be clear. I accept changes
might be needed there. The $subject is all about DT bindings and what need
to be changes and for me nothing, just use existing bindings and if there
are issues there, let us discuss it with specifics.

How can changes to dt bindings be nothing? All the resources
clk/regulators/resets will become optional and a new power or perf domain
will become required for each device with firmwares that support SCMI Perf.

Correct, sorry to miss the point that few properties are now optional from
mandatory before. Very good point. I was so caught up with the addition of
the new "firmware controlled blah blah" property/compatible that I missed
to observe mandatory->optional as a change. Thanks for correcting me.

If there are no more questions on this and everyone is on the same page, I
would like to conclude this thread in favor of using a new DT property
'qcom,firmware-managed-resources'.

This is exactly opposite to what I have advocated so far in this thread.
Not sure how you drew to this conclusion. Check [1] and [2] for example.
The point was not to have qcom specific compatibles or properties as it
doesn't scale well. Please chime into those if you have argument and how
you came to this conclusion.

--
Regards,
Sudeep

[1] https://lore.kernel.org/all/ZfMZ9ATxuvONcGpz@bogus
[2] https://lore.kernel.org/all/0411f99d-231a-af4b-d681-7f7748361aa3@xxxxxxxxxxx
Hi Sudeep, we had a discussion with Linaro team on this and people suggested that this should be a vendor specific property since different vendors might abstract differently. Moreover, our changes are only in Qualcomm drivers so it made sense to use vendor specific property. That being said, if you are suggesting that we remove Qcom from it, I can again discuss this. I will let Srini and other pitch in here if they want to add more to it.




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux