Re: DT Query on "New Compatible vs New Property"

[Sudeep Holla <sudeep.holla@arm.com>]

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