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

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

 



On 24/01/2024 10:27, Manivannan Sadhasivam wrote:
> On Wed, Jan 24, 2024 at 10:01:05AM +0100, Krzysztof Kozlowski wrote:
>> On 24/01/2024 09:53, Manivannan Sadhasivam wrote:
>>> On Wed, Jan 24, 2024 at 09:45:05AM +0100, Krzysztof Kozlowski wrote:
>>>> On 24/01/2024 09:39, Manivannan Sadhasivam wrote:
>>>>> On Wed, Jan 24, 2024 at 09:02:16AM +0100, Krzysztof Kozlowski wrote:
>>>>>> On 23/01/2024 17:12, Manivannan Sadhasivam wrote:
>>>>>>> On Thu, Dec 14, 2023 at 07:18:25AM -0800, Nikunj Kela wrote:
>>>>>>>>
>>>>>>>> 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?
>>>>>>>>
>>>>>>>
>>>>>>> Krzysztof, just a ping on this thread.
>>>>>>>
>>>>>>> To summarise, the hardware is exactly same. We can consider the case of UFS. The
>>>>>>> UFS controller is exactly same in this proposed setup but the resources of the
>>>>>>> UFS controller are taken care by the VM. So instead of enabling the resources
>>>>>>> one by one, Linux kernel will just ask the VM to do so using an SCMI command.
>>>>>>>
>>>>>>> Due to this difference, we need to make the changes in the UFS controller
>>>>>>> driver. So we want to know if we can use a different compatible for the UFS
>>>>>>> controller altogether in DT (this will allow Linux kernel to have a separate
>>>>>>> driver and will simplify things) or just use a property like
>>>>>>> "remotely-controlled" to let the driver detect this setup and take action
>>>>>>> accordingly.
>>>>>>
>>>>>> What devices do we talk about? Are they released? For which other
>>>>>> devices you want to use it?
>>>>>
>>>>> If you are referring to "peripherals" as "devices", then this new interface is
>>>>> going to be applicable to most of the peripherals in the SoC like PCIe, UFS, USB
>>>>> etc...
>>>>>
>>>>
>>>> And what about SoCs and final products?
>>>>
>>>
>>> Sorry, I don't understand what you mean. This interface is still under
>>> development and going to be available in future SoCs. At that time, we need
>>> changes to the drivers to adapt to this interface.
>>
>> Hm, confused... The message was saying: the same hardware. Same hardware
>> means for example Qualcomm SM8550 SoC.
>>
> 
> Same hardware means all the peripherals are same as of previous gen SoCs apart
> from usual improvements. Maybe I confused you by saying that this interface is
> only applicable for newer SoCs, that is not accurate.
> 
> So for instance, even if you take SM8550, Qcom can use this interface (VM) and
> ship it to a customer. The VM is just part of the bootloader package. So if the
> VM is shipped with an SoC, then Linux should not try to handle resources for the
> peripherals and instead request VM to do so using the SCMI interface. Much like
> how ACPI behaves in the x86 world. But how the OS should be made aware of the
> presence of VM is the question here. Qcom likes to convey that information using
> DT.

So this is not an existing SoC? Then why do you need to change the
meaning of compatible? You have new compatible.

> 
>> OK, I think we are way past possible theoretical discussions. Please
>> send patches and we will discuss it from there.
>>
> 
> Well, this decision (whether to use a different compatible or a property)
> impacts all the peripheral teams inside Qcom as the driver update heavily
> depends on this decision. So let's try to conclude the decision here itself.
> If something is not clear, please say as you said above. I'll try my best to
> clarify.

Then again - list exact existing SoCs which will be affected. If this is
for future SoCs, then why we are even discussing this? Everything
started - first sentence! - with:
"existing platform"

Sorry guys, I am getting more and more confused.

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