On Wed, Jan 24, 2024 at 10:23:40AM +0000, Sudeep Holla wrote: > 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 ? The design that Qcom is coming up is, all the hardware (peripheral controllers, clocks, regulators) stay as it is, but the control to those resources will be handled by the VM instead of the device driver in OS. The idea is similar (but not same) to ACPI, but here they want to use SCMI commands to let the device driver request VM to control the resources on its behalf. > > > > > 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. > If the VM is taking control of the resources, then device drivers cannot control them. I think it may result in access violation. This design (VM + SCMI) is floated by Qcom to offload the resource management from OS. One can say that ACPI will solve the issue, but... > > 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. > The problem is, the resource provider is not changing. For instance, currently GCC is supplying clocks to all peripherals in an SoC. In this design also, GCC will supply clocks, but driver cannot use standard clock API to enable the clock, but instead it needs to use an SCMI command to let VM enable the clock on its behalf. As per Qcom, this will abstract the resource handling from OS. Like, instead of the driver explicitly enabling all resources, it can ask the VM to do it on its behalf. During suspend/resume also, VM will manage the resources. Hope this clarifies the design. - Mani -- மணிவண்ணன் சதாசிவம்
