On Tue, Jan 23, 2024 at 09:42:31PM +0530, Manivannan Sadhasivam wrote: > On Thu, Dec 14, 2023 at 07:18:25AM -0800, Nikunj Kela wrote: > > > > 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? > > I did see the mention of SCMI somewhere in the thread, hence the interest. What specific resources are we talking here: clocks, reset, power domains, regulators ? If so I don't understand the need for any new compatible "qcom, controlled-remotely' or any change in the driver. The DT has standard bindings for these and drivers would be requesting these resources using std framework apis. If it is a clock controller in the host Linux VM or if it is SCMI controlled clock in a non Linux VM must not matter for the individual drivers right ? Sorry if I am missing something obvious here ? > > 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. > I don't understand why you need to change the UFS controller driver to switch to SCMI driver resource model from self/host Linux driven model. > 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. > I would say the DT should be set accordingly before the Linux boots to point all the resources to SCMI instead of self hosted various controller/provider nodes in the DT. I don't understand why the compatible for a device need to change if the OS resource handling model changes. The resource nodes just points to a different provider node instead. -- Regards, Sudeep
