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

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

 




On 12/13/2023 11:49 PM, Krzysztof Kozlowski wrote:
On 14/12/2023 07:17, Manivannan Sadhasivam wrote:
On Tue, Dec 12, 2023 at 11:06:42AM -0800, Nikunj Kela wrote:
+ Linaro team

On 12/12/2023 11:01 AM, Krzysztof Kozlowski wrote:
On 12/12/2023 18:45, Nikunj Kela wrote:
We are abstracting some resources(ex. clocks) under new firmware on an
existing platform therefore need to make changes in certain drivers to
work with that firmware. We need to make a distinction between two
different variants of the FW. In one case, some resources will be
abstracted while in other case, they won't be abstracted. My query is -
"should we define a new compatible string for the variant with
abstracted resources(in FW) or we should add a new DT property keeping
the compatible same?"
Hi,

Usually change in the interface or behavior warrants new compatible.
Property would be suitable if the same device, e.g. same SoC component
with same FW, was configured differently on different boards.

Here, the hardware is going to be the same, but the resources (clocks,
regulators, etc...) will be controlled by the firmware instead of OS.
Yeah, that's the problem with generic questions, instead of specific...
"Talk is cheap."

OK, so the hardware is exactly the same? Does FW bring any
incompatibilities in the interface or is it just about the clocks? I
guess I should not have included "with same FW" in my last statement.
It's true, but way too narrow. Therefore let me rephrase it:

HW is exactly the same. Let me give more insight on the setup. We have been using the HW in virtual environment but now the ownership of certain resources (e.g. clock controller etc.) is handed over to a different VM(non Linux VM). Earlier the ownership of the resources was local to the same VM(Linux VM) via passthrough mode so it could directly access them however now Linux VM talks to non-Linux VM for its operations for resources that it doesn't own anymore via some interface(shared memory/doorbell).  So shall we use property like 'qcom, controlled-remotely' or do we need a new compatible for such setup?

"Property would be suitable if the same device, e.g. same SoC component
with same interface towards OS, was configured differently on different
boards."

Should we still use a different compatible? For the similar usecase, we already
have properties like 'qcom,controlled-remotely' to let the OS know that it
should not configure the hardware and just consume it.
Yeah, also similar qcom,gsi-loader.

Best regards,
Krzysztof





[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