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.
