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

[Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>]

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.

OK, I think we are way past possible theoretical discussions. Please
send patches and we will discuss it from there.


Best regards,
Krzysztof