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? I can give you one specific answer but then it will be taken to other contexts and used for the cases it must not be used... Best regards, Krzysztof
