On Wed, Jan 24, 2024 at 04:15:30PM +0530, Manivannan Sadhasivam wrote: > 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. > This is no different on any platform that using SCMI or any firmware interface for managing the resources. > 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. > Correct, but that doesn't explain on what you are suggesting to change in the drivers. Drivers must modify nothing to switch between the models. > > > > > > > > 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. > Well why are those "raw" resources presented to the Linux. I see no difference between this and presenting the secure resource to the Linux via DT and complaining when it faults accessing them inside the kernel. So still not providing any reasoning to the actual change. > 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... > Yes I am aware of it to some extent. > > > 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. I am completely lost. The SCMI clock(and any other resource provider) register itself to the corresponding framework in the kernel. The consumers of these resource must simply use the std. APIs as usual so it doesn't matter who is the provider of this resource. That is the model in which almost all resource framework work in the kernel. Just switching to SCMI doesn't and must not require any change in the consumer drivers. I am still failing terribly here to understand the motive here. > 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. > Yes just use the standard framework calls to indicate the same to the VM. > Hope this clarifies the design. Not really, still puzzled may be more than before as I don't understand what is going on with the approach as it seem to be deviating from my initial understanding. May be take an example of one driver, present the DT binding and driver changes to make sure there is no misunderstanding from my side. But I am not convinced with the explanation so far. -- Regards, Sudeep
