DT Query on "New Compatible vs New Property"

DT Query on "New Compatible vs New Property"

[Nikunj Kela]

Dear DT maintainers,

Hope you are doing great. I have a query on DT policy.

We are abstracting some resources(ex. clocks) under new firmware on an 
existing platform therefore need to make changes in certain drivers to 
work with that firmware. We need to make a distinction between two 
different variants of the FW. In one case, some resources will be 
abstracted while in other case, they won't be abstracted. My query is - 
"should we define a new compatible string for the variant with 
abstracted resources(in FW) or we should add a new DT property keeping 
the compatible same?"

Thank you in advance.

Regards,

Nikunj

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

[Krzysztof Kozlowski]

On 12/12/2023 18:45, Nikunj Kela wrote:
> We are abstracting some resources(ex. clocks) under new firmware on an 
> existing platform therefore need to make changes in certain drivers to 
> work with that firmware. We need to make a distinction between two 
> different variants of the FW. In one case, some resources will be 
> abstracted while in other case, they won't be abstracted. My query is - 
> "should we define a new compatible string for the variant with 
> abstracted resources(in FW) or we should add a new DT property keeping 
> the compatible same?"

Hi,

Usually change in the interface or behavior warrants new compatible.
Property would be suitable if the same device, e.g. same SoC component
with same FW, was configured differently on different boards.

Best regards,
Krzysztof

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

[Nikunj Kela]

+ Linaro team

On 12/12/2023 11:01 AM, Krzysztof Kozlowski wrote:
> On 12/12/2023 18:45, Nikunj Kela wrote:
>> We are abstracting some resources(ex. clocks) under new firmware on an
>> existing platform therefore need to make changes in certain drivers to
>> work with that firmware. We need to make a distinction between two
>> different variants of the FW. In one case, some resources will be
>> abstracted while in other case, they won't be abstracted. My query is -
>> "should we define a new compatible string for the variant with
>> abstracted resources(in FW) or we should add a new DT property keeping
>> the compatible same?"
> Hi,
>
> Usually change in the interface or behavior warrants new compatible.
> Property would be suitable if the same device, e.g. same SoC component
> with same FW, was configured differently on different boards.
>
> Best regards,
> Krzysztof

Thank you for your prompt response! Will use different compatible as 
advised.

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

[Manivannan Sadhasivam]

On Tue, Dec 12, 2023 at 11:06:42AM -0800, Nikunj Kela wrote:
> + Linaro team
> 
> On 12/12/2023 11:01 AM, Krzysztof Kozlowski wrote:
> > On 12/12/2023 18:45, Nikunj Kela wrote:
> > > We are abstracting some resources(ex. clocks) under new firmware on an
> > > existing platform therefore need to make changes in certain drivers to
> > > work with that firmware. We need to make a distinction between two
> > > different variants of the FW. In one case, some resources will be
> > > abstracted while in other case, they won't be abstracted. My query is -
> > > "should we define a new compatible string for the variant with
> > > abstracted resources(in FW) or we should add a new DT property keeping
> > > the compatible same?"
> > Hi,
> > 
> > Usually change in the interface or behavior warrants new compatible.
> > Property would be suitable if the same device, e.g. same SoC component
> > with same FW, was configured differently on different boards.
> > 

Here, the hardware is going to be the same, but the resources (clocks,
regulators, etc...) will be controlled by the firmware instead of OS.

Should we still use a different compatible? For the similar usecase, we already
have properties like 'qcom,controlled-remotely' to let the OS know that it
should not configure the hardware and just consume it.

To me both usecases sounds similar.

- Mani

> > Best regards,
> > Krzysztof
> 
> Thank you for your prompt response! Will use different compatible as
> advised.
> 

-- 
மணிவண்ணன் சதாசிவம்

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

[Krzysztof Kozlowski]

On 14/12/2023 07:17, Manivannan Sadhasivam wrote:
> On Tue, Dec 12, 2023 at 11:06:42AM -0800, Nikunj Kela wrote:
>> + Linaro team
>>
>> On 12/12/2023 11:01 AM, Krzysztof Kozlowski wrote:
>>> On 12/12/2023 18:45, Nikunj Kela wrote:
>>>> We are abstracting some resources(ex. clocks) under new firmware on an
>>>> existing platform therefore need to make changes in certain drivers to
>>>> work with that firmware. We need to make a distinction between two
>>>> different variants of the FW. In one case, some resources will be
>>>> abstracted while in other case, they won't be abstracted. My query is -
>>>> "should we define a new compatible string for the variant with
>>>> abstracted resources(in FW) or we should add a new DT property keeping
>>>> the compatible same?"
>>> Hi,
>>>
>>> Usually change in the interface or behavior warrants new compatible.
>>> Property would be suitable if the same device, e.g. same SoC component
>>> with same FW, was configured differently on different boards.
>>>
> 
> Here, the hardware is going to be the same, but the resources (clocks,
> regulators, etc...) will be controlled by the firmware instead of OS.

Yeah, that's the problem with generic questions, instead of specific...
"Talk is cheap."

OK, so the hardware is exactly the same? Does FW bring any
incompatibilities in the interface or is it just about the clocks? I
guess I should not have included "with same FW" in my last statement.
It's true, but way too narrow. Therefore let me rephrase it:

"Property would be suitable if the same device, e.g. same SoC component
with same interface towards OS, was configured differently on different
boards."

> 
> Should we still use a different compatible? For the similar usecase, we already
> have properties like 'qcom,controlled-remotely' to let the OS know that it
> should not configure the hardware and just consume it.

Yeah, also similar qcom,gsi-loader.

Best regards,
Krzysztof

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

[Nikunj Kela]

On 12/13/2023 11:49 PM, Krzysztof Kozlowski wrote:
> On 14/12/2023 07:17, Manivannan Sadhasivam wrote:
>> On Tue, Dec 12, 2023 at 11:06:42AM -0800, Nikunj Kela wrote:
>>> + Linaro team
>>>
>>> On 12/12/2023 11:01 AM, Krzysztof Kozlowski wrote:
>>>> On 12/12/2023 18:45, Nikunj Kela wrote:
>>>>> We are abstracting some resources(ex. clocks) under new firmware on an
>>>>> existing platform therefore need to make changes in certain drivers to
>>>>> work with that firmware. We need to make a distinction between two
>>>>> different variants of the FW. In one case, some resources will be
>>>>> abstracted while in other case, they won't be abstracted. My query is -
>>>>> "should we define a new compatible string for the variant with
>>>>> abstracted resources(in FW) or we should add a new DT property keeping
>>>>> the compatible same?"
>>>> Hi,
>>>>
>>>> Usually change in the interface or behavior warrants new compatible.
>>>> Property would be suitable if the same device, e.g. same SoC component
>>>> with same FW, was configured differently on different boards.
>>>>
>> Here, the hardware is going to be the same, but the resources (clocks,
>> regulators, etc...) will be controlled by the firmware instead of OS.
> Yeah, that's the problem with generic questions, instead of specific...
> "Talk is cheap."
>
> OK, so the hardware is exactly the same? Does FW bring any
> incompatibilities in the interface or is it just about the clocks? I
> guess I should not have included "with same FW" in my last statement.
> It's true, but way too narrow. Therefore let me rephrase it:

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?

> "Property would be suitable if the same device, e.g. same SoC component
> with same interface towards OS, was configured differently on different
> boards."
>
>> Should we still use a different compatible? For the similar usecase, we already
>> have properties like 'qcom,controlled-remotely' to let the OS know that it
>> should not configure the hardware and just consume it.
> Yeah, also similar qcom,gsi-loader.
>
> Best regards,
> Krzysztof
>

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

[Manivannan Sadhasivam]

On Thu, Dec 14, 2023 at 07:18:25AM -0800, Nikunj Kela wrote:
> 
> On 12/13/2023 11:49 PM, Krzysztof Kozlowski wrote:
> > On 14/12/2023 07:17, Manivannan Sadhasivam wrote:
> > > On Tue, Dec 12, 2023 at 11:06:42AM -0800, Nikunj Kela wrote:
> > > > + Linaro team
> > > > 
> > > > On 12/12/2023 11:01 AM, Krzysztof Kozlowski wrote:
> > > > > On 12/12/2023 18:45, Nikunj Kela wrote:
> > > > > > We are abstracting some resources(ex. clocks) under new firmware on an
> > > > > > existing platform therefore need to make changes in certain drivers to
> > > > > > work with that firmware. We need to make a distinction between two
> > > > > > different variants of the FW. In one case, some resources will be
> > > > > > abstracted while in other case, they won't be abstracted. My query is -
> > > > > > "should we define a new compatible string for the variant with
> > > > > > abstracted resources(in FW) or we should add a new DT property keeping
> > > > > > the compatible same?"
> > > > > Hi,
> > > > > 
> > > > > Usually change in the interface or behavior warrants new compatible.
> > > > > Property would be suitable if the same device, e.g. same SoC component
> > > > > with same FW, was configured differently on different boards.
> > > > > 
> > > Here, the hardware is going to be the same, but the resources (clocks,
> > > regulators, etc...) will be controlled by the firmware instead of OS.
> > Yeah, that's the problem with generic questions, instead of specific...
> > "Talk is cheap."
> > 
> > OK, so the hardware is exactly the same? Does FW bring any
> > incompatibilities in the interface or is it just about the clocks? I
> > guess I should not have included "with same FW" in my last statement.
> > It's true, but way too narrow. Therefore let me rephrase it:
> 
> 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?
> 

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.

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.

- Mani

> > "Property would be suitable if the same device, e.g. same SoC component
> > with same interface towards OS, was configured differently on different
> > boards."
> > 
> > > Should we still use a different compatible? For the similar usecase, we already
> > > have properties like 'qcom,controlled-remotely' to let the OS know that it
> > > should not configure the hardware and just consume it.
> > Yeah, also similar qcom,gsi-loader.
> > 
> > Best regards,
> > Krzysztof
> > 

-- 
மணிவண்ணன் சதாசிவம்

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

[Krzysztof Kozlowski]

On 23/01/2024 17:12, Manivannan Sadhasivam wrote:
> On Thu, Dec 14, 2023 at 07:18:25AM -0800, Nikunj Kela wrote:
>>
>> On 12/13/2023 11:49 PM, Krzysztof Kozlowski wrote:
>>> On 14/12/2023 07:17, Manivannan Sadhasivam wrote:
>>>> On Tue, Dec 12, 2023 at 11:06:42AM -0800, Nikunj Kela wrote:
>>>>> + Linaro team
>>>>>
>>>>> On 12/12/2023 11:01 AM, Krzysztof Kozlowski wrote:
>>>>>> On 12/12/2023 18:45, Nikunj Kela wrote:
>>>>>>> We are abstracting some resources(ex. clocks) under new firmware on an
>>>>>>> existing platform therefore need to make changes in certain drivers to
>>>>>>> work with that firmware. We need to make a distinction between two
>>>>>>> different variants of the FW. In one case, some resources will be
>>>>>>> abstracted while in other case, they won't be abstracted. My query is -
>>>>>>> "should we define a new compatible string for the variant with
>>>>>>> abstracted resources(in FW) or we should add a new DT property keeping
>>>>>>> the compatible same?"
>>>>>> Hi,
>>>>>>
>>>>>> Usually change in the interface or behavior warrants new compatible.
>>>>>> Property would be suitable if the same device, e.g. same SoC component
>>>>>> with same FW, was configured differently on different boards.
>>>>>>
>>>> Here, the hardware is going to be the same, but the resources (clocks,
>>>> regulators, etc...) will be controlled by the firmware instead of OS.
>>> Yeah, that's the problem with generic questions, instead of specific...
>>> "Talk is cheap."
>>>
>>> OK, so the hardware is exactly the same? Does FW bring any
>>> incompatibilities in the interface or is it just about the clocks? I
>>> guess I should not have included "with same FW" in my last statement.
>>> It's true, but way too narrow. Therefore let me rephrase it:
>>
>> 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?
>>
> 
> 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.
> 
> 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.

What devices do we talk about? Are they released? For which other
devices you want to use it? I can give you one specific answer but then
it will be taken to other contexts and used for the cases it must not be
used...

Best regards,
Krzysztof

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

[Manivannan Sadhasivam]

On Wed, Jan 24, 2024 at 09:02:16AM +0100, Krzysztof Kozlowski wrote:
> On 23/01/2024 17:12, Manivannan Sadhasivam wrote:
> > On Thu, Dec 14, 2023 at 07:18:25AM -0800, Nikunj Kela wrote:
> >>
> >> On 12/13/2023 11:49 PM, Krzysztof Kozlowski wrote:
> >>> On 14/12/2023 07:17, Manivannan Sadhasivam wrote:
> >>>> On Tue, Dec 12, 2023 at 11:06:42AM -0800, Nikunj Kela wrote:
> >>>>> + Linaro team
> >>>>>
> >>>>> On 12/12/2023 11:01 AM, Krzysztof Kozlowski wrote:
> >>>>>> On 12/12/2023 18:45, Nikunj Kela wrote:
> >>>>>>> We are abstracting some resources(ex. clocks) under new firmware on an
> >>>>>>> existing platform therefore need to make changes in certain drivers to
> >>>>>>> work with that firmware. We need to make a distinction between two
> >>>>>>> different variants of the FW. In one case, some resources will be
> >>>>>>> abstracted while in other case, they won't be abstracted. My query is -
> >>>>>>> "should we define a new compatible string for the variant with
> >>>>>>> abstracted resources(in FW) or we should add a new DT property keeping
> >>>>>>> the compatible same?"
> >>>>>> Hi,
> >>>>>>
> >>>>>> Usually change in the interface or behavior warrants new compatible.
> >>>>>> Property would be suitable if the same device, e.g. same SoC component
> >>>>>> with same FW, was configured differently on different boards.
> >>>>>>
> >>>> Here, the hardware is going to be the same, but the resources (clocks,
> >>>> regulators, etc...) will be controlled by the firmware instead of OS.
> >>> Yeah, that's the problem with generic questions, instead of specific...
> >>> "Talk is cheap."
> >>>
> >>> OK, so the hardware is exactly the same? Does FW bring any
> >>> incompatibilities in the interface or is it just about the clocks? I
> >>> guess I should not have included "with same FW" in my last statement.
> >>> It's true, but way too narrow. Therefore let me rephrase it:
> >>
> >> 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?
> >>
> > 
> > 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.
> > 
> > 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.
> 
> What devices do we talk about? Are they released? For which other
> devices you want to use it?

If you are referring to "peripherals" as "devices", then this new interface is
going to be applicable to most of the peripherals in the SoC like PCIe, UFS, USB
etc...

- Mani

-- 
மணிவண்ணன் சதாசிவம்

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

[Krzysztof Kozlowski]

On 24/01/2024 09:39, Manivannan Sadhasivam wrote:
> On Wed, Jan 24, 2024 at 09:02:16AM +0100, Krzysztof Kozlowski wrote:
>> On 23/01/2024 17:12, Manivannan Sadhasivam wrote:
>>> On Thu, Dec 14, 2023 at 07:18:25AM -0800, Nikunj Kela wrote:
>>>>
>>>> On 12/13/2023 11:49 PM, Krzysztof Kozlowski wrote:
>>>>> On 14/12/2023 07:17, Manivannan Sadhasivam wrote:
>>>>>> On Tue, Dec 12, 2023 at 11:06:42AM -0800, Nikunj Kela wrote:
>>>>>>> + Linaro team
>>>>>>>
>>>>>>> On 12/12/2023 11:01 AM, Krzysztof Kozlowski wrote:
>>>>>>>> On 12/12/2023 18:45, Nikunj Kela wrote:
>>>>>>>>> We are abstracting some resources(ex. clocks) under new firmware on an
>>>>>>>>> existing platform therefore need to make changes in certain drivers to
>>>>>>>>> work with that firmware. We need to make a distinction between two
>>>>>>>>> different variants of the FW. In one case, some resources will be
>>>>>>>>> abstracted while in other case, they won't be abstracted. My query is -
>>>>>>>>> "should we define a new compatible string for the variant with
>>>>>>>>> abstracted resources(in FW) or we should add a new DT property keeping
>>>>>>>>> the compatible same?"
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Usually change in the interface or behavior warrants new compatible.
>>>>>>>> Property would be suitable if the same device, e.g. same SoC component
>>>>>>>> with same FW, was configured differently on different boards.
>>>>>>>>
>>>>>> Here, the hardware is going to be the same, but the resources (clocks,
>>>>>> regulators, etc...) will be controlled by the firmware instead of OS.
>>>>> Yeah, that's the problem with generic questions, instead of specific...
>>>>> "Talk is cheap."
>>>>>
>>>>> OK, so the hardware is exactly the same? Does FW bring any
>>>>> incompatibilities in the interface or is it just about the clocks? I
>>>>> guess I should not have included "with same FW" in my last statement.
>>>>> It's true, but way too narrow. Therefore let me rephrase it:
>>>>
>>>> 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?
>>>>
>>>
>>> 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.
>>>
>>> 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.
>>
>> What devices do we talk about? Are they released? For which other
>> devices you want to use it?
> 
> If you are referring to "peripherals" as "devices", then this new interface is
> going to be applicable to most of the peripherals in the SoC like PCIe, UFS, USB
> etc...
> 

And what about SoCs and final products?

Best regards,
Krzysztof

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

[Manivannan Sadhasivam]

On Wed, Jan 24, 2024 at 09:45:05AM +0100, Krzysztof Kozlowski wrote:
> On 24/01/2024 09:39, Manivannan Sadhasivam wrote:
> > On Wed, Jan 24, 2024 at 09:02:16AM +0100, Krzysztof Kozlowski wrote:
> >> On 23/01/2024 17:12, Manivannan Sadhasivam wrote:
> >>> On Thu, Dec 14, 2023 at 07:18:25AM -0800, Nikunj Kela wrote:
> >>>>
> >>>> On 12/13/2023 11:49 PM, Krzysztof Kozlowski wrote:
> >>>>> On 14/12/2023 07:17, Manivannan Sadhasivam wrote:
> >>>>>> On Tue, Dec 12, 2023 at 11:06:42AM -0800, Nikunj Kela wrote:
> >>>>>>> + Linaro team
> >>>>>>>
> >>>>>>> On 12/12/2023 11:01 AM, Krzysztof Kozlowski wrote:
> >>>>>>>> On 12/12/2023 18:45, Nikunj Kela wrote:
> >>>>>>>>> We are abstracting some resources(ex. clocks) under new firmware on an
> >>>>>>>>> existing platform therefore need to make changes in certain drivers to
> >>>>>>>>> work with that firmware. We need to make a distinction between two
> >>>>>>>>> different variants of the FW. In one case, some resources will be
> >>>>>>>>> abstracted while in other case, they won't be abstracted. My query is -
> >>>>>>>>> "should we define a new compatible string for the variant with
> >>>>>>>>> abstracted resources(in FW) or we should add a new DT property keeping
> >>>>>>>>> the compatible same?"
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> Usually change in the interface or behavior warrants new compatible.
> >>>>>>>> Property would be suitable if the same device, e.g. same SoC component
> >>>>>>>> with same FW, was configured differently on different boards.
> >>>>>>>>
> >>>>>> Here, the hardware is going to be the same, but the resources (clocks,
> >>>>>> regulators, etc...) will be controlled by the firmware instead of OS.
> >>>>> Yeah, that's the problem with generic questions, instead of specific...
> >>>>> "Talk is cheap."
> >>>>>
> >>>>> OK, so the hardware is exactly the same? Does FW bring any
> >>>>> incompatibilities in the interface or is it just about the clocks? I
> >>>>> guess I should not have included "with same FW" in my last statement.
> >>>>> It's true, but way too narrow. Therefore let me rephrase it:
> >>>>
> >>>> 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?
> >>>>
> >>>
> >>> 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.
> >>>
> >>> 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.
> >>
> >> What devices do we talk about? Are they released? For which other
> >> devices you want to use it?
> > 
> > If you are referring to "peripherals" as "devices", then this new interface is
> > going to be applicable to most of the peripherals in the SoC like PCIe, UFS, USB
> > etc...
> > 
> 
> And what about SoCs and final products?
> 

Sorry, I don't understand what you mean. This interface is still under
development and going to be available in future SoCs. At that time, we need
changes to the drivers to adapt to this interface.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

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

[Krzysztof Kozlowski]

On 24/01/2024 09:53, Manivannan Sadhasivam wrote:
> On Wed, Jan 24, 2024 at 09:45:05AM +0100, Krzysztof Kozlowski wrote:
>> On 24/01/2024 09:39, Manivannan Sadhasivam wrote:
>>> On Wed, Jan 24, 2024 at 09:02:16AM +0100, Krzysztof Kozlowski wrote:
>>>> On 23/01/2024 17:12, Manivannan Sadhasivam wrote:
>>>>> On Thu, Dec 14, 2023 at 07:18:25AM -0800, Nikunj Kela wrote:
>>>>>>
>>>>>> On 12/13/2023 11:49 PM, Krzysztof Kozlowski wrote:
>>>>>>> On 14/12/2023 07:17, Manivannan Sadhasivam wrote:
>>>>>>>> On Tue, Dec 12, 2023 at 11:06:42AM -0800, Nikunj Kela wrote:
>>>>>>>>> + Linaro team
>>>>>>>>>
>>>>>>>>> On 12/12/2023 11:01 AM, Krzysztof Kozlowski wrote:
>>>>>>>>>> On 12/12/2023 18:45, Nikunj Kela wrote:
>>>>>>>>>>> We are abstracting some resources(ex. clocks) under new firmware on an
>>>>>>>>>>> existing platform therefore need to make changes in certain drivers to
>>>>>>>>>>> work with that firmware. We need to make a distinction between two
>>>>>>>>>>> different variants of the FW. In one case, some resources will be
>>>>>>>>>>> abstracted while in other case, they won't be abstracted. My query is -
>>>>>>>>>>> "should we define a new compatible string for the variant with
>>>>>>>>>>> abstracted resources(in FW) or we should add a new DT property keeping
>>>>>>>>>>> the compatible same?"
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Usually change in the interface or behavior warrants new compatible.
>>>>>>>>>> Property would be suitable if the same device, e.g. same SoC component
>>>>>>>>>> with same FW, was configured differently on different boards.
>>>>>>>>>>
>>>>>>>> Here, the hardware is going to be the same, but the resources (clocks,
>>>>>>>> regulators, etc...) will be controlled by the firmware instead of OS.
>>>>>>> Yeah, that's the problem with generic questions, instead of specific...
>>>>>>> "Talk is cheap."
>>>>>>>
>>>>>>> OK, so the hardware is exactly the same? Does FW bring any
>>>>>>> incompatibilities in the interface or is it just about the clocks? I
>>>>>>> guess I should not have included "with same FW" in my last statement.
>>>>>>> It's true, but way too narrow. Therefore let me rephrase it:
>>>>>>
>>>>>> 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?
>>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>> 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.
>>>>
>>>> What devices do we talk about? Are they released? For which other
>>>> devices you want to use it?
>>>
>>> If you are referring to "peripherals" as "devices", then this new interface is
>>> going to be applicable to most of the peripherals in the SoC like PCIe, UFS, USB
>>> etc...
>>>
>>
>> And what about SoCs and final products?
>>
> 
> Sorry, I don't understand what you mean. This interface is still under
> development and going to be available in future SoCs. At that time, we need
> changes to the drivers to adapt to this interface.

Hm, confused... The message was saying: the same hardware. Same hardware
means for example Qualcomm SM8550 SoC.

OK, I think we are way past possible theoretical discussions. Please
send patches and we will discuss it from there.


Best regards,
Krzysztof

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

[Manivannan Sadhasivam]

On Wed, Jan 24, 2024 at 10:01:05AM +0100, Krzysztof Kozlowski wrote:
> On 24/01/2024 09:53, Manivannan Sadhasivam wrote:
> > On Wed, Jan 24, 2024 at 09:45:05AM +0100, Krzysztof Kozlowski wrote:
> >> On 24/01/2024 09:39, Manivannan Sadhasivam wrote:
> >>> On Wed, Jan 24, 2024 at 09:02:16AM +0100, Krzysztof Kozlowski wrote:
> >>>> On 23/01/2024 17:12, Manivannan Sadhasivam wrote:
> >>>>> On Thu, Dec 14, 2023 at 07:18:25AM -0800, Nikunj Kela wrote:
> >>>>>>
> >>>>>> On 12/13/2023 11:49 PM, Krzysztof Kozlowski wrote:
> >>>>>>> On 14/12/2023 07:17, Manivannan Sadhasivam wrote:
> >>>>>>>> On Tue, Dec 12, 2023 at 11:06:42AM -0800, Nikunj Kela wrote:
> >>>>>>>>> + Linaro team
> >>>>>>>>>
> >>>>>>>>> On 12/12/2023 11:01 AM, Krzysztof Kozlowski wrote:
> >>>>>>>>>> On 12/12/2023 18:45, Nikunj Kela wrote:
> >>>>>>>>>>> We are abstracting some resources(ex. clocks) under new firmware on an
> >>>>>>>>>>> existing platform therefore need to make changes in certain drivers to
> >>>>>>>>>>> work with that firmware. We need to make a distinction between two
> >>>>>>>>>>> different variants of the FW. In one case, some resources will be
> >>>>>>>>>>> abstracted while in other case, they won't be abstracted. My query is -
> >>>>>>>>>>> "should we define a new compatible string for the variant with
> >>>>>>>>>>> abstracted resources(in FW) or we should add a new DT property keeping
> >>>>>>>>>>> the compatible same?"
> >>>>>>>>>> Hi,
> >>>>>>>>>>
> >>>>>>>>>> Usually change in the interface or behavior warrants new compatible.
> >>>>>>>>>> Property would be suitable if the same device, e.g. same SoC component
> >>>>>>>>>> with same FW, was configured differently on different boards.
> >>>>>>>>>>
> >>>>>>>> Here, the hardware is going to be the same, but the resources (clocks,
> >>>>>>>> regulators, etc...) will be controlled by the firmware instead of OS.
> >>>>>>> Yeah, that's the problem with generic questions, instead of specific...
> >>>>>>> "Talk is cheap."
> >>>>>>>
> >>>>>>> OK, so the hardware is exactly the same? Does FW bring any
> >>>>>>> incompatibilities in the interface or is it just about the clocks? I
> >>>>>>> guess I should not have included "with same FW" in my last statement.
> >>>>>>> It's true, but way too narrow. Therefore let me rephrase it:
> >>>>>>
> >>>>>> 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?
> >>>>>>
> >>>>>
> >>>>> 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.
> >>>>>
> >>>>> 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.
> >>>>
> >>>> What devices do we talk about? Are they released? For which other
> >>>> devices you want to use it?
> >>>
> >>> If you are referring to "peripherals" as "devices", then this new interface is
> >>> going to be applicable to most of the peripherals in the SoC like PCIe, UFS, USB
> >>> etc...
> >>>
> >>
> >> And what about SoCs and final products?
> >>
> > 
> > Sorry, I don't understand what you mean. This interface is still under
> > development and going to be available in future SoCs. At that time, we need
> > changes to the drivers to adapt to this interface.
> 
> Hm, confused... The message was saying: the same hardware. Same hardware
> means for example Qualcomm SM8550 SoC.
> 

Same hardware means all the peripherals are same as of previous gen SoCs apart
from usual improvements. Maybe I confused you by saying that this interface is
only applicable for newer SoCs, that is not accurate.

So for instance, even if you take SM8550, Qcom can use this interface (VM) and
ship it to a customer. The VM is just part of the bootloader package. So if the
VM is shipped with an SoC, then Linux should not try to handle resources for the
peripherals and instead request VM to do so using the SCMI interface. Much like
how ACPI behaves in the x86 world. But how the OS should be made aware of the
presence of VM is the question here. Qcom likes to convey that information using
DT.

> OK, I think we are way past possible theoretical discussions. Please
> send patches and we will discuss it from there.
>

Well, this decision (whether to use a different compatible or a property)
impacts all the peripheral teams inside Qcom as the driver update heavily
depends on this decision. So let's try to conclude the decision here itself.
If something is not clear, please say as you said above. I'll try my best to
clarify.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

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

[Krzysztof Kozlowski]

On 24/01/2024 10:27, Manivannan Sadhasivam wrote:
> On Wed, Jan 24, 2024 at 10:01:05AM +0100, Krzysztof Kozlowski wrote:
>> On 24/01/2024 09:53, Manivannan Sadhasivam wrote:
>>> On Wed, Jan 24, 2024 at 09:45:05AM +0100, Krzysztof Kozlowski wrote:
>>>> On 24/01/2024 09:39, Manivannan Sadhasivam wrote:
>>>>> On Wed, Jan 24, 2024 at 09:02:16AM +0100, Krzysztof Kozlowski wrote:
>>>>>> On 23/01/2024 17:12, Manivannan Sadhasivam wrote:
>>>>>>> On Thu, Dec 14, 2023 at 07:18:25AM -0800, Nikunj Kela wrote:
>>>>>>>>
>>>>>>>> On 12/13/2023 11:49 PM, Krzysztof Kozlowski wrote:
>>>>>>>>> On 14/12/2023 07:17, Manivannan Sadhasivam wrote:
>>>>>>>>>> On Tue, Dec 12, 2023 at 11:06:42AM -0800, Nikunj Kela wrote:
>>>>>>>>>>> + Linaro team
>>>>>>>>>>>
>>>>>>>>>>> On 12/12/2023 11:01 AM, Krzysztof Kozlowski wrote:
>>>>>>>>>>>> On 12/12/2023 18:45, Nikunj Kela wrote:
>>>>>>>>>>>>> We are abstracting some resources(ex. clocks) under new firmware on an
>>>>>>>>>>>>> existing platform therefore need to make changes in certain drivers to
>>>>>>>>>>>>> work with that firmware. We need to make a distinction between two
>>>>>>>>>>>>> different variants of the FW. In one case, some resources will be
>>>>>>>>>>>>> abstracted while in other case, they won't be abstracted. My query is -
>>>>>>>>>>>>> "should we define a new compatible string for the variant with
>>>>>>>>>>>>> abstracted resources(in FW) or we should add a new DT property keeping
>>>>>>>>>>>>> the compatible same?"
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> Usually change in the interface or behavior warrants new compatible.
>>>>>>>>>>>> Property would be suitable if the same device, e.g. same SoC component
>>>>>>>>>>>> with same FW, was configured differently on different boards.
>>>>>>>>>>>>
>>>>>>>>>> Here, the hardware is going to be the same, but the resources (clocks,
>>>>>>>>>> regulators, etc...) will be controlled by the firmware instead of OS.
>>>>>>>>> Yeah, that's the problem with generic questions, instead of specific...
>>>>>>>>> "Talk is cheap."
>>>>>>>>>
>>>>>>>>> OK, so the hardware is exactly the same? Does FW bring any
>>>>>>>>> incompatibilities in the interface or is it just about the clocks? I
>>>>>>>>> guess I should not have included "with same FW" in my last statement.
>>>>>>>>> It's true, but way too narrow. Therefore let me rephrase it:
>>>>>>>>
>>>>>>>> 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?
>>>>>>>>
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> 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.
>>>>>>
>>>>>> What devices do we talk about? Are they released? For which other
>>>>>> devices you want to use it?
>>>>>
>>>>> If you are referring to "peripherals" as "devices", then this new interface is
>>>>> going to be applicable to most of the peripherals in the SoC like PCIe, UFS, USB
>>>>> etc...
>>>>>
>>>>
>>>> And what about SoCs and final products?
>>>>
>>>
>>> Sorry, I don't understand what you mean. This interface is still under
>>> development and going to be available in future SoCs. At that time, we need
>>> changes to the drivers to adapt to this interface.
>>
>> Hm, confused... The message was saying: the same hardware. Same hardware
>> means for example Qualcomm SM8550 SoC.
>>
> 
> Same hardware means all the peripherals are same as of previous gen SoCs apart
> from usual improvements. Maybe I confused you by saying that this interface is
> only applicable for newer SoCs, that is not accurate.
> 
> So for instance, even if you take SM8550, Qcom can use this interface (VM) and
> ship it to a customer. The VM is just part of the bootloader package. So if the
> VM is shipped with an SoC, then Linux should not try to handle resources for the
> peripherals and instead request VM to do so using the SCMI interface. Much like
> how ACPI behaves in the x86 world. But how the OS should be made aware of the
> presence of VM is the question here. Qcom likes to convey that information using
> DT.

So this is not an existing SoC? Then why do you need to change the
meaning of compatible? You have new compatible.

> 
>> OK, I think we are way past possible theoretical discussions. Please
>> send patches and we will discuss it from there.
>>
> 
> Well, this decision (whether to use a different compatible or a property)
> impacts all the peripheral teams inside Qcom as the driver update heavily
> depends on this decision. So let's try to conclude the decision here itself.
> If something is not clear, please say as you said above. I'll try my best to
> clarify.

Then again - list exact existing SoCs which will be affected. If this is
for future SoCs, then why we are even discussing this? Everything
started - first sentence! - with:
"existing platform"

Sorry guys, I am getting more and more confused.

Best regards,
Krzysztof

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

[Sudeep Holla]

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

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

[Manivannan Sadhasivam]

On Wed, Jan 24, 2024 at 10:40:53AM +0100, Krzysztof Kozlowski wrote:
> On 24/01/2024 10:27, Manivannan Sadhasivam wrote:
> > On Wed, Jan 24, 2024 at 10:01:05AM +0100, Krzysztof Kozlowski wrote:
> >> On 24/01/2024 09:53, Manivannan Sadhasivam wrote:
> >>> On Wed, Jan 24, 2024 at 09:45:05AM +0100, Krzysztof Kozlowski wrote:
> >>>> On 24/01/2024 09:39, Manivannan Sadhasivam wrote:
> >>>>> On Wed, Jan 24, 2024 at 09:02:16AM +0100, Krzysztof Kozlowski wrote:
> >>>>>> On 23/01/2024 17:12, Manivannan Sadhasivam wrote:
> >>>>>>> On Thu, Dec 14, 2023 at 07:18:25AM -0800, Nikunj Kela wrote:
> >>>>>>>>
> >>>>>>>> On 12/13/2023 11:49 PM, Krzysztof Kozlowski wrote:
> >>>>>>>>> On 14/12/2023 07:17, Manivannan Sadhasivam wrote:
> >>>>>>>>>> On Tue, Dec 12, 2023 at 11:06:42AM -0800, Nikunj Kela wrote:
> >>>>>>>>>>> + Linaro team
> >>>>>>>>>>>
> >>>>>>>>>>> On 12/12/2023 11:01 AM, Krzysztof Kozlowski wrote:
> >>>>>>>>>>>> On 12/12/2023 18:45, Nikunj Kela wrote:
> >>>>>>>>>>>>> We are abstracting some resources(ex. clocks) under new firmware on an
> >>>>>>>>>>>>> existing platform therefore need to make changes in certain drivers to
> >>>>>>>>>>>>> work with that firmware. We need to make a distinction between two
> >>>>>>>>>>>>> different variants of the FW. In one case, some resources will be
> >>>>>>>>>>>>> abstracted while in other case, they won't be abstracted. My query is -
> >>>>>>>>>>>>> "should we define a new compatible string for the variant with
> >>>>>>>>>>>>> abstracted resources(in FW) or we should add a new DT property keeping
> >>>>>>>>>>>>> the compatible same?"
> >>>>>>>>>>>> Hi,
> >>>>>>>>>>>>
> >>>>>>>>>>>> Usually change in the interface or behavior warrants new compatible.
> >>>>>>>>>>>> Property would be suitable if the same device, e.g. same SoC component
> >>>>>>>>>>>> with same FW, was configured differently on different boards.
> >>>>>>>>>>>>
> >>>>>>>>>> Here, the hardware is going to be the same, but the resources (clocks,
> >>>>>>>>>> regulators, etc...) will be controlled by the firmware instead of OS.
> >>>>>>>>> Yeah, that's the problem with generic questions, instead of specific...
> >>>>>>>>> "Talk is cheap."
> >>>>>>>>>
> >>>>>>>>> OK, so the hardware is exactly the same? Does FW bring any
> >>>>>>>>> incompatibilities in the interface or is it just about the clocks? I
> >>>>>>>>> guess I should not have included "with same FW" in my last statement.
> >>>>>>>>> It's true, but way too narrow. Therefore let me rephrase it:
> >>>>>>>>
> >>>>>>>> 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?
> >>>>>>>>
> >>>>>>>
> >>>>>>> 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.
> >>>>>>>
> >>>>>>> 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.
> >>>>>>
> >>>>>> What devices do we talk about? Are they released? For which other
> >>>>>> devices you want to use it?
> >>>>>
> >>>>> If you are referring to "peripherals" as "devices", then this new interface is
> >>>>> going to be applicable to most of the peripherals in the SoC like PCIe, UFS, USB
> >>>>> etc...
> >>>>>
> >>>>
> >>>> And what about SoCs and final products?
> >>>>
> >>>
> >>> Sorry, I don't understand what you mean. This interface is still under
> >>> development and going to be available in future SoCs. At that time, we need
> >>> changes to the drivers to adapt to this interface.
> >>
> >> Hm, confused... The message was saying: the same hardware. Same hardware
> >> means for example Qualcomm SM8550 SoC.
> >>
> > 
> > Same hardware means all the peripherals are same as of previous gen SoCs apart
> > from usual improvements. Maybe I confused you by saying that this interface is
> > only applicable for newer SoCs, that is not accurate.
> > 
> > So for instance, even if you take SM8550, Qcom can use this interface (VM) and
> > ship it to a customer. The VM is just part of the bootloader package. So if the
> > VM is shipped with an SoC, then Linux should not try to handle resources for the
> > peripherals and instead request VM to do so using the SCMI interface. Much like
> > how ACPI behaves in the x86 world. But how the OS should be made aware of the
> > presence of VM is the question here. Qcom likes to convey that information using
> > DT.
> 
> So this is not an existing SoC? Then why do you need to change the
> meaning of compatible? You have new compatible.
> 

Let me put it this way: Qcom wants to use a VM to control the clocks, regulator,
PHY for the controllers in the SoC that is already out there in the market.
They will just change the bootloader to include the VM and the VM will take
control of the resources. All the resources will be specified in the DT as it is
for the affected controllers.

Right now, the device drivers in the OS are controlling the above mentioned
resources. Can Qcom use DT to convey this information to the OS? So that the
device drivers in the OS can use SCMI interface to manage the resources with the
help of VM. Otherwise, if OS tries to control the resources as usual, it may
result in some access violation.

- Mani

> > 
> >> OK, I think we are way past possible theoretical discussions. Please
> >> send patches and we will discuss it from there.
> >>
> > 
> > Well, this decision (whether to use a different compatible or a property)
> > impacts all the peripheral teams inside Qcom as the driver update heavily
> > depends on this decision. So let's try to conclude the decision here itself.
> > If something is not clear, please say as you said above. I'll try my best to
> > clarify.
> 
> Then again - list exact existing SoCs which will be affected. If this is
> for future SoCs, then why we are even discussing this? Everything
> started - first sentence! - with:
> "existing platform"
> 
> Sorry guys, I am getting more and more confused.
> 
> Best regards,
> Krzysztof
> 

-- 
மணிவண்ணன் சதாசிவம்

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

[Manivannan Sadhasivam]

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

-- 
மணிவண்ணன் சதாசிவம்

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

[Sudeep Holla]

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

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

[Nikunj Kela]

On 1/24/2024 3:02 AM, Sudeep Holla wrote:
> 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.

Hi Sudeep,

We are not using clock protocol to deal with clocks individually. We are 
trying to define different perf domains for peripherals where we are 
grouping clocks/regulators/interconnect bandwidth into these perf 
domains and use OPP levels via SCMI perf protocol. This is done so as to 
avoid individual scmi calls for these resources hence avoiding any race 
conditions and minimizing the traffic between SCMI client and server to 
get better KPIs. This is being planned for sa8775p platform and any 
subsequent platforms will use the same approach. The idea of using perf 
protocol for peripherals is new and I Qualcomm is first one trying to 
use that. Therefore existing peripheral drivers will require a way to 
distinguish between the two different configurations. Hope this provides 
little more context and insight.

Thanks

>
> --
> Regards,
> Sudeep

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

[Sudeep Holla]

On Wed, Jan 24, 2024 at 04:27:55AM -0800, Nikunj Kela wrote:
> 
> On 1/24/2024 3:02 AM, Sudeep Holla wrote:
> > 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.
> 
> Hi Sudeep,
> 
> We are not using clock protocol to deal with clocks individually. We are
> trying to define different perf domains for peripherals where we are
> grouping clocks/regulators/interconnect bandwidth into these perf domains
> and use OPP levels via SCMI perf protocol.

That clarifies on what you are trying to achieve.

> This is done so as to avoid individual scmi calls for these resources
> hence avoiding any race conditions and minimizing the traffic between SCMI
> client and server to get better KPIs.

Fair enough, why can't you just use genpd perf APIs to achieve that ?

> This is being planned for sa8775p platform and any subsequent platforms will
> use the same approach. The idea of using perf protocol for peripherals is
> new and Qualcomm is first one trying to use that.

Sure.

> Therefore existing peripheral drivers will require a way to distinguish between the
> two different configurations. Hope this provides little more context and
> insight.
>

While I agree this is new, use custom APIs to control standard resources
is simply *VERY VERY BAD IDEA* IMO. You may be fine to have these custom
API calls in qcom specific drivers. But what if this is needed in some
generic IP driver. Just not scalable and why should the maintainer of
such driver accept you custom API.

So I would suggest to work towards using std framework APIs or create one
if you can justify the need for it. Please stop creating custom APIs for
using SCMI. It defeats the whole standardisation it is meant to provide.

-- 
Regards,
Sudeep

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

[Nikunj Kela]

On 1/24/2024 4:48 AM, Sudeep Holla wrote:
> On Wed, Jan 24, 2024 at 04:27:55AM -0800, Nikunj Kela wrote:
>> On 1/24/2024 3:02 AM, Sudeep Holla wrote:
>>> 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.
>> Hi Sudeep,
>>
>> We are not using clock protocol to deal with clocks individually. We are
>> trying to define different perf domains for peripherals where we are
>> grouping clocks/regulators/interconnect bandwidth into these perf domains
>> and use OPP levels via SCMI perf protocol.
> That clarifies on what you are trying to achieve.
>
>> This is done so as to avoid individual scmi calls for these resources
>> hence avoiding any race conditions and minimizing the traffic between SCMI
>> client and server to get better KPIs.
> Fair enough, why can't you just use genpd perf APIs to achieve that ?

OPP is built on top of genpd perf only and was recommended by Ulf(PM 
maintainer from Linaro) hence we decided to use OPP APIs instead of 
directly genpd perf API.


>
>> This is being planned for sa8775p platform and any subsequent platforms will
>> use the same approach. The idea of using perf protocol for peripherals is
>> new and Qualcomm is first one trying to use that.
> Sure.
>
>> Therefore existing peripheral drivers will require a way to distinguish between the
>> two different configurations. Hope this provides little more context and
>> insight.
>>
> While I agree this is new, use custom APIs to control standard resources
> is simply *VERY VERY BAD IDEA* IMO. You may be fine to have these custom
> API calls in qcom specific drivers. But what if this is needed in some
> generic IP driver. Just not scalable and why should the maintainer of
> such driver accept you custom API.

Apologies if it wasn't clear but we are not using custom APIs. We are 
using standard OPP APIs to set to opp level of the perf domain. 
Example-dev_pm_opp_set_opp(). As mentioned above, we are following PM 
framework maintainers recommendation to use OPP.


>
> So I would suggest to work towards using std framework APIs or create one
> if you can justify the need for it. Please stop creating custom APIs for
> using SCMI. It defeats the whole standardisation it is meant to provide.

Not sure I understand what you refer to as custom APIs here. The OPP 
APIs are not custom APIs. They are from OPP framework built on top of 
genpd perf. [1] and [2] patch series might provide you more insight into 
the work that Ulf did to support SCMI perf with OPP framework.

[1]: 
https://lore.kernel.org/all/20230919121605.7304-1-ulf.hansson@linaro.org/

[2]:https://lore.kernel.org/all/20230925131715.138411-1-ulf.hansson@linaro.org/

>

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

[Vincent Guittot]

On Wed, 24 Jan 2024 at 14:17, Nikunj Kela <quic_nkela@quicinc.com> wrote:
>
>
> On 1/24/2024 4:48 AM, Sudeep Holla wrote:
> > On Wed, Jan 24, 2024 at 04:27:55AM -0800, Nikunj Kela wrote:
> >> On 1/24/2024 3:02 AM, Sudeep Holla wrote:
> >>> 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.
> >> Hi Sudeep,
> >>
> >> We are not using clock protocol to deal with clocks individually. We are
> >> trying to define different perf domains for peripherals where we are
> >> grouping clocks/regulators/interconnect bandwidth into these perf domains
> >> and use OPP levels via SCMI perf protocol.
> > That clarifies on what you are trying to achieve.
> >
> >> This is done so as to avoid individual scmi calls for these resources
> >> hence avoiding any race conditions and minimizing the traffic between SCMI
> >> client and server to get better KPIs.
> > Fair enough, why can't you just use genpd perf APIs to achieve that ?
>
> OPP is built on top of genpd perf only and was recommended by Ulf(PM
> maintainer from Linaro) hence we decided to use OPP APIs instead of
> directly genpd perf API.
>
>
> >
> >> This is being planned for sa8775p platform and any subsequent platforms will
> >> use the same approach. The idea of using perf protocol for peripherals is
> >> new and Qualcomm is first one trying to use that.
> > Sure.
> >
> >> Therefore existing peripheral drivers will require a way to distinguish between the
> >> two different configurations. Hope this provides little more context and
> >> insight.
> >>
> > While I agree this is new, use custom APIs to control standard resources
> > is simply *VERY VERY BAD IDEA* IMO. You may be fine to have these custom
> > API calls in qcom specific drivers. But what if this is needed in some
> > generic IP driver. Just not scalable and why should the maintainer of
> > such driver accept you custom API.
>
> Apologies if it wasn't clear but we are not using custom APIs. We are
> using standard OPP APIs to set to opp level of the perf domain.
> Example-dev_pm_opp_set_opp(). As mentioned above, we are following PM
> framework maintainers recommendation to use OPP.
>
>
> >
> > So I would suggest to work towards using std framework APIs or create one
> > if you can justify the need for it. Please stop creating custom APIs for
> > using SCMI. It defeats the whole standardisation it is meant to provide.
>
> Not sure I understand what you refer to as custom APIs here. The OPP
> APIs are not custom APIs. They are from OPP framework built on top of
> genpd perf. [1] and [2] patch series might provide you more insight into
> the work that Ulf did to support SCMI perf with OPP framework.

I think that you are speaking about the same thing. They plan to use
SCMI power domain for idle states and SCMI performance domain for
setting a performance mode. Then, the OPP library is used on top of
perf domain to gather and manipulate the  different perf levels.


>
> [1]:
> https://lore.kernel.org/all/20230919121605.7304-1-ulf.hansson@linaro.org/
>
> [2]:https://lore.kernel.org/all/20230925131715.138411-1-ulf.hansson@linaro.org/
>
> >

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

[Sudeep Holla]

On Wed, Jan 24, 2024 at 05:17:09AM -0800, Nikunj Kela wrote:
> 
> On 1/24/2024 4:48 AM, Sudeep Holla wrote:
> > On Wed, Jan 24, 2024 at 04:27:55AM -0800, Nikunj Kela wrote:
> > > On 1/24/2024 3:02 AM, Sudeep Holla wrote:
> > > > 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.
> > > Hi Sudeep,
> > > 
> > > We are not using clock protocol to deal with clocks individually. We are
> > > trying to define different perf domains for peripherals where we are
> > > grouping clocks/regulators/interconnect bandwidth into these perf domains
> > > and use OPP levels via SCMI perf protocol.
> > That clarifies on what you are trying to achieve.
> > 
> > > This is done so as to avoid individual scmi calls for these resources
> > > hence avoiding any race conditions and minimizing the traffic between SCMI
> > > client and server to get better KPIs.
> > Fair enough, why can't you just use genpd perf APIs to achieve that ?
> 
> OPP is built on top of genpd perf only and was recommended by Ulf(PM
> maintainer from Linaro) hence we decided to use OPP APIs instead of directly
> genpd perf API.
> 
> 
> > 
> > > This is being planned for sa8775p platform and any subsequent platforms will
> > > use the same approach. The idea of using perf protocol for peripherals is
> > > new and Qualcomm is first one trying to use that.
> > Sure.
> > 
> > > Therefore existing peripheral drivers will require a way to distinguish between the
> > > two different configurations. Hope this provides little more context and
> > > insight.
> > > 
> > While I agree this is new, use custom APIs to control standard resources
> > is simply *VERY VERY BAD IDEA* IMO. You may be fine to have these custom
> > API calls in qcom specific drivers. But what if this is needed in some
> > generic IP driver. Just not scalable and why should the maintainer of
> > such driver accept you custom API.
> 
> Apologies if it wasn't clear but we are not using custom APIs. We are using
> standard OPP APIs to set to opp level of the perf domain.
> Example-dev_pm_opp_set_opp(). As mentioned above, we are following PM
> framework maintainers recommendation to use OPP.
>

Right, this is std API, but the way it was explained before seemed like a
custom API that builds and sends SCMI command and hence the objection.

I assume dev_pm_opp_set_opp() uses the attached genpd perf domain to make
the request, so it is fine.

> > 
> > So I would suggest to work towards using std framework APIs or create one
> > if you can justify the need for it. Please stop creating custom APIs for
> > using SCMI. It defeats the whole standardisation it is meant to provide.
> 
> Not sure I understand what you refer to as custom APIs here. The OPP APIs
> are not custom APIs. They are from OPP framework built on top of genpd perf.
> [1] and [2] patch series might provide you more insight into the work that
> Ulf did to support SCMI perf with OPP framework.
> 

As mentioned above, agreed. It was not clear before and it was explained as
if you are using custom methods.

Anyways, why do you need know what is the backend provider if you just
use this dev_pm_opp_set_opp() unconditionally. That part is still not clear.
Things like this should be handled without any explicit DT changes IMO, but
happy to hear if I am missing something.

-- 
Regards,
Sudeep

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

[Sudeep Holla]

On Wed, Jan 24, 2024 at 02:38:54PM +0100, Vincent Guittot wrote:
> On Wed, 24 Jan 2024 at 14:17, Nikunj Kela <quic_nkela@quicinc.com> wrote:
> >
> >
> > On 1/24/2024 4:48 AM, Sudeep Holla wrote:
> > > On Wed, Jan 24, 2024 at 04:27:55AM -0800, Nikunj Kela wrote:
> > >> On 1/24/2024 3:02 AM, Sudeep Holla wrote:
> > >>> 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.
> > >> Hi Sudeep,
> > >>
> > >> We are not using clock protocol to deal with clocks individually. We are
> > >> trying to define different perf domains for peripherals where we are
> > >> grouping clocks/regulators/interconnect bandwidth into these perf domains
> > >> and use OPP levels via SCMI perf protocol.
> > > That clarifies on what you are trying to achieve.
> > >
> > >> This is done so as to avoid individual scmi calls for these resources
> > >> hence avoiding any race conditions and minimizing the traffic between SCMI
> > >> client and server to get better KPIs.
> > > Fair enough, why can't you just use genpd perf APIs to achieve that ?
> >
> > OPP is built on top of genpd perf only and was recommended by Ulf(PM
> > maintainer from Linaro) hence we decided to use OPP APIs instead of
> > directly genpd perf API.
> >
> >
> > >
> > >> This is being planned for sa8775p platform and any subsequent platforms will
> > >> use the same approach. The idea of using perf protocol for peripherals is
> > >> new and Qualcomm is first one trying to use that.
> > > Sure.
> > >
> > >> Therefore existing peripheral drivers will require a way to distinguish between the
> > >> two different configurations. Hope this provides little more context and
> > >> insight.
> > >>
> > > While I agree this is new, use custom APIs to control standard resources
> > > is simply *VERY VERY BAD IDEA* IMO. You may be fine to have these custom
> > > API calls in qcom specific drivers. But what if this is needed in some
> > > generic IP driver. Just not scalable and why should the maintainer of
> > > such driver accept you custom API.
> >
> > Apologies if it wasn't clear but we are not using custom APIs. We are
> > using standard OPP APIs to set to opp level of the perf domain.
> > Example-dev_pm_opp_set_opp(). As mentioned above, we are following PM
> > framework maintainers recommendation to use OPP.
> >
> >
> > >
> > > So I would suggest to work towards using std framework APIs or create one
> > > if you can justify the need for it. Please stop creating custom APIs for
> > > using SCMI. It defeats the whole standardisation it is meant to provide.
> >
> > Not sure I understand what you refer to as custom APIs here. The OPP
> > APIs are not custom APIs. They are from OPP framework built on top of
> > genpd perf. [1] and [2] patch series might provide you more insight into
> > the work that Ulf did to support SCMI perf with OPP framework.
> 
> I think that you are speaking about the same thing. They plan to use
> SCMI power domain for idle states and SCMI performance domain for
> setting a performance mode. Then, the OPP library is used on top of
> perf domain to gather and manipulate the  different perf levels.
> 

Indeed, I just realise that after Nikunj's last email. Earlier to that,
it was not so clear and it sounded like some custom way. Anyways I am still
not convinced if this is something drivers need to handle with explicit
DT support for this distinction in particular.

-- 
Regards,
Sudeep

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

[Nikunj Kela]

On 1/24/2024 6:04 AM, Sudeep Holla wrote:
> On Wed, Jan 24, 2024 at 02:38:54PM +0100, Vincent Guittot wrote:
>> On Wed, 24 Jan 2024 at 14:17, Nikunj Kela <quic_nkela@quicinc.com> wrote:
>>>
>>> On 1/24/2024 4:48 AM, Sudeep Holla wrote:
>>>> On Wed, Jan 24, 2024 at 04:27:55AM -0800, Nikunj Kela wrote:
>>>>> On 1/24/2024 3:02 AM, Sudeep Holla wrote:
>>>>>> 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.
>>>>> Hi Sudeep,
>>>>>
>>>>> We are not using clock protocol to deal with clocks individually. We are
>>>>> trying to define different perf domains for peripherals where we are
>>>>> grouping clocks/regulators/interconnect bandwidth into these perf domains
>>>>> and use OPP levels via SCMI perf protocol.
>>>> That clarifies on what you are trying to achieve.
>>>>
>>>>> This is done so as to avoid individual scmi calls for these resources
>>>>> hence avoiding any race conditions and minimizing the traffic between SCMI
>>>>> client and server to get better KPIs.
>>>> Fair enough, why can't you just use genpd perf APIs to achieve that ?
>>> OPP is built on top of genpd perf only and was recommended by Ulf(PM
>>> maintainer from Linaro) hence we decided to use OPP APIs instead of
>>> directly genpd perf API.
>>>
>>>
>>>>> This is being planned for sa8775p platform and any subsequent platforms will
>>>>> use the same approach. The idea of using perf protocol for peripherals is
>>>>> new and Qualcomm is first one trying to use that.
>>>> Sure.
>>>>
>>>>> Therefore existing peripheral drivers will require a way to distinguish between the
>>>>> two different configurations. Hope this provides little more context and
>>>>> insight.
>>>>>
>>>> While I agree this is new, use custom APIs to control standard resources
>>>> is simply *VERY VERY BAD IDEA* IMO. You may be fine to have these custom
>>>> API calls in qcom specific drivers. But what if this is needed in some
>>>> generic IP driver. Just not scalable and why should the maintainer of
>>>> such driver accept you custom API.
>>> Apologies if it wasn't clear but we are not using custom APIs. We are
>>> using standard OPP APIs to set to opp level of the perf domain.
>>> Example-dev_pm_opp_set_opp(). As mentioned above, we are following PM
>>> framework maintainers recommendation to use OPP.
>>>
>>>
>>>> So I would suggest to work towards using std framework APIs or create one
>>>> if you can justify the need for it. Please stop creating custom APIs for
>>>> using SCMI. It defeats the whole standardisation it is meant to provide.
>>> Not sure I understand what you refer to as custom APIs here. The OPP
>>> APIs are not custom APIs. They are from OPP framework built on top of
>>> genpd perf. [1] and [2] patch series might provide you more insight into
>>> the work that Ulf did to support SCMI perf with OPP framework.
>> I think that you are speaking about the same thing. They plan to use
>> SCMI power domain for idle states and SCMI performance domain for
>> setting a performance mode. Then, the OPP library is used on top of
>> perf domain to gather and manipulate the  different perf levels.
>>
> Indeed, I just realise that after Nikunj's last email. Earlier to that,
> it was not so clear and it sounded like some custom way. Anyways I am still
> not convinced if this is something drivers need to handle with explicit
> DT support for this distinction in particular.

Let me try another shot to convince you :) Currently, driver is dealing 
with clocks and regulators using individual framework APIs(e.g. 
set_clk_rate, regulator_set_voltage etc.). With defining perf to group 
them in OPP APIs, we need to now use set_opp. Therefore the driver needs 
to change to use OPP framework APIs instead of clocks/regulator APIs 
hence this query on how to distinguish the two configuration even though 
the hardware is same.

>

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

[Sudeep Holla]

On Wed, Jan 24, 2024 at 06:28:33AM -0800, Nikunj Kela wrote:
> 
> Let me try another shot to convince you :) Currently, driver is dealing with
> clocks and regulators using individual framework APIs(e.g. set_clk_rate,
> regulator_set_voltage etc.). With defining perf to group them in OPP APIs,
> we need to now use set_opp. Therefore the driver needs to change to use OPP
> framework APIs instead of clocks/regulator APIs hence this query on how to
> distinguish the two configuration even though the hardware is same.
>

One option is to make dev_pm_opp_set_opp() work for both. IIUC, opp layer
can deal with clocks and regulators. A quick look at dev_pm_opp_set_opp()
seem to suggest that.

Another option is to try both one after another. Here I am assuming that
clk_get() will fail and return error. One could check if it has pm_domain
with "perf" support and use opp APIs.

I don't think we need DT changes to achieve what you have explained so far.
At least not at a level of per device node compatible or extra property.

--
Regards,
Sudeep

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

[Nikunj Kela]

On 1/24/2024 9:24 AM, Sudeep Holla wrote:
> On Wed, Jan 24, 2024 at 06:28:33AM -0800, Nikunj Kela wrote:
>> Let me try another shot to convince you :) Currently, driver is dealing with
>> clocks and regulators using individual framework APIs(e.g. set_clk_rate,
>> regulator_set_voltage etc.). With defining perf to group them in OPP APIs,
>> we need to now use set_opp. Therefore the driver needs to change to use OPP
>> framework APIs instead of clocks/regulator APIs hence this query on how to
>> distinguish the two configuration even though the hardware is same.
>>
> One option is to make dev_pm_opp_set_opp() work for both. IIUC, opp layer
> can deal with clocks and regulators. A quick look at dev_pm_opp_set_opp()
> seem to suggest that.
I did explore that and there are some complications due to the 
abstraction we are trying to achieve.
>
> Another option is to try both one after another. Here I am assuming that
> clk_get() will fail and return error. One could check if it has pm_domain
> with "perf" support and use opp APIs.
This sounds promising so I would like to explore this further. IIUC, you 
are suggesting that we check if genpd->set_performance_state() is 
implemented when the clock APIs fail?
> I don't think we need DT changes to achieve what you have explained so far.
> At least not at a level of per device node compatible or extra property.
>
> --
> Regards,
> Sudeep

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

[Nikunj Kela]

On 1/24/2024 9:33 AM, Nikunj Kela wrote:
>
> On 1/24/2024 9:24 AM, Sudeep Holla wrote:
>> On Wed, Jan 24, 2024 at 06:28:33AM -0800, Nikunj Kela wrote:
>>> Let me try another shot to convince you :) Currently, driver is 
>>> dealing with
>>> clocks and regulators using individual framework APIs(e.g. 
>>> set_clk_rate,
>>> regulator_set_voltage etc.). With defining perf to group them in OPP 
>>> APIs,
>>> we need to now use set_opp. Therefore the driver needs to change to 
>>> use OPP
>>> framework APIs instead of clocks/regulator APIs hence this query on 
>>> how to
>>> distinguish the two configuration even though the hardware is same.
>>>
>> One option is to make dev_pm_opp_set_opp() work for both. IIUC, opp 
>> layer
>> can deal with clocks and regulators. A quick look at 
>> dev_pm_opp_set_opp()
>> seem to suggest that.
> I did explore that and there are some complications due to the 
> abstraction we are trying to achieve.
>>
>> Another option is to try both one after another. Here I am assuming that
>> clk_get() will fail and return error. One could check if it has 
>> pm_domain
>> with "perf" support and use opp APIs.
> This sounds promising so I would like to explore this further. IIUC, 
> you are suggesting that we check if genpd->set_performance_state() is 
> implemented when the clock APIs fail?
>> I don't think we need DT changes to achieve what you have explained 
>> so far.
>> At least not at a level of per device node compatible or extra property.
>>
Hi Sudeep,

I would like to conclude on this thread. I was discussing this with Ulf. 
He thinks that using the domain names to identify if platform is 
abstracting clocks etc. are not scalable and sufficient. Instead he 
thinks that the change in the interface to OS(and FW) is a good 
candidate for a new compatible(even though HW is same).  Even for SCMI, 
we do change phandle in DT to SCMI protocol phandle so that is like a 
different platform altogether. Could you please let me know if you still 
think that using a different compatible in this case is not warranted.

Thanks

>> -- 
>> Regards,
>> Sudeep

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

[Ulf Hansson]

On Mon, 26 Feb 2024 at 15:24, Nikunj Kela <quic_nkela@quicinc.com> wrote:
>
> On 1/24/2024 9:33 AM, Nikunj Kela wrote:
> >
> > On 1/24/2024 9:24 AM, Sudeep Holla wrote:
> >> On Wed, Jan 24, 2024 at 06:28:33AM -0800, Nikunj Kela wrote:
> >>> Let me try another shot to convince you :) Currently, driver is
> >>> dealing with
> >>> clocks and regulators using individual framework APIs(e.g.
> >>> set_clk_rate,
> >>> regulator_set_voltage etc.). With defining perf to group them in OPP
> >>> APIs,
> >>> we need to now use set_opp. Therefore the driver needs to change to
> >>> use OPP
> >>> framework APIs instead of clocks/regulator APIs hence this query on
> >>> how to
> >>> distinguish the two configuration even though the hardware is same.
> >>>
> >> One option is to make dev_pm_opp_set_opp() work for both. IIUC, opp
> >> layer
> >> can deal with clocks and regulators. A quick look at
> >> dev_pm_opp_set_opp()
> >> seem to suggest that.
> > I did explore that and there are some complications due to the
> > abstraction we are trying to achieve.
> >>
> >> Another option is to try both one after another. Here I am assuming that
> >> clk_get() will fail and return error. One could check if it has
> >> pm_domain
> >> with "perf" support and use opp APIs.
> > This sounds promising so I would like to explore this further. IIUC,
> > you are suggesting that we check if genpd->set_performance_state() is
> > implemented when the clock APIs fail?
> >> I don't think we need DT changes to achieve what you have explained
> >> so far.
> >> At least not at a level of per device node compatible or extra property.
> >>
> Hi Sudeep,
>
> I would like to conclude on this thread. I was discussing this with Ulf.
> He thinks that using the domain names to identify if platform is
> abstracting clocks etc. are not scalable and sufficient. Instead he
> thinks that the change in the interface to OS(and FW) is a good
> candidate for a new compatible(even though HW is same).  Even for SCMI,
> we do change phandle in DT to SCMI protocol phandle so that is like a
> different platform altogether. Could you please let me know if you still
> think that using a different compatible in this case is not warranted.

My apologies for joining this discussion at this late state. Yet, I
just wanted to confirm what Nikunj said above.

In the end we are indeed talking about adding a new platform, as
changing the FW interface from a QCOM proprietary one into SCMI,
simply requires updates to a DTS file(s) that is platform specific.

That said, it also seems reasonable to me to use a compatible string,
to allow us to describe the update of HW for various affected devices.

Probably the best next step is to post a patch series showing how this
would really look like, as it would help us to understand more, I
think.

Kind regards
Uffe

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

[Sudeep Holla]

On Wed, Feb 28, 2024 at 02:27:30PM +0100, Ulf Hansson wrote:
> On Mon, 26 Feb 2024 at 15:24, Nikunj Kela <quic_nkela@quicinc.com> wrote:
> >
> > Hi Sudeep,
> >
> > I would like to conclude on this thread. I was discussing this with Ulf.
> > He thinks that using the domain names to identify if platform is
> > abstracting clocks etc. are not scalable and sufficient. Instead he
> > thinks that the change in the interface to OS(and FW) is a good
> > candidate for a new compatible(even though HW is same).  Even for SCMI,
> > we do change phandle in DT to SCMI protocol phandle so that is like a
> > different platform altogether. Could you please let me know if you still
> > think that using a different compatible in this case is not warranted.
>
> My apologies for joining this discussion at this late state. Yet, I
> just wanted to confirm what Nikunj said above.
>
> In the end we are indeed talking about adding a new platform, as
> changing the FW interface from a QCOM proprietary one into SCMI,
> simply requires updates to a DTS file(s) that is platform specific.
>

The way I read this sounds like all this are platform specific and need
new compatible.

> That said, it also seems reasonable to me to use a compatible string,
> to allow us to describe the update of HW for various affected devices.
>

While I agree with the above statement, it depends on what you refer as
update of HW above. It is all Qcom specific and there is so much turn
between SoCs that this shouldn't matter but I would like to take example
and describe what I initially mentioned/argued against.

Lets us assume 2 SoCs: A and B. A is old and didn't use SCMI while B is
new and migrated to use SCMI. Now let us assume both A and B SoCs have
exact same version/revision of an IP: X. Now just because B uses SCMI,
should X have one compatible to be used in A and another in B. That
doesn't sound right IMO.

If X on A has to manage clocks and voltage separately while the same X
on B uses SCMI to manage them together as performance domain, then the
presence(or absence) of those properties must indicate the difference and
not a change in compaible for the IP X. But it is upto Qcom platform
maintainer, IP driver maintainer and DT maintainers to decide, I will
leave that them. I just wanted to express my opinion on the matter.

> Probably the best next step is to post a patch series showing how this
> would really look like, as it would help us to understand more, I
> think.
>

Agreed.

--
Regards,
Sudeep

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

[Krzysztof Kozlowski]

On 28/02/2024 15:02, Sudeep Holla wrote:
> On Wed, Feb 28, 2024 at 02:27:30PM +0100, Ulf Hansson wrote:
>> On Mon, 26 Feb 2024 at 15:24, Nikunj Kela <quic_nkela@quicinc.com> wrote:
>>>
>>> Hi Sudeep,
>>>
>>> I would like to conclude on this thread. I was discussing this with Ulf.
>>> He thinks that using the domain names to identify if platform is
>>> abstracting clocks etc. are not scalable and sufficient. Instead he
>>> thinks that the change in the interface to OS(and FW) is a good
>>> candidate for a new compatible(even though HW is same).  Even for SCMI,
>>> we do change phandle in DT to SCMI protocol phandle so that is like a
>>> different platform altogether. Could you please let me know if you still
>>> think that using a different compatible in this case is not warranted.
>>
>> My apologies for joining this discussion at this late state. Yet, I
>> just wanted to confirm what Nikunj said above.
>>
>> In the end we are indeed talking about adding a new platform, as
>> changing the FW interface from a QCOM proprietary one into SCMI,
>> simply requires updates to a DTS file(s) that is platform specific.
>>
> 
> The way I read this sounds like all this are platform specific and need
> new compatible.
> 
>> That said, it also seems reasonable to me to use a compatible string,
>> to allow us to describe the update of HW for various affected devices.
>>
> 
> While I agree with the above statement, it depends on what you refer as
> update of HW above. It is all Qcom specific and there is so much turn
> between SoCs that this shouldn't matter but I would like to take example
> and describe what I initially mentioned/argued against.
> 
> Lets us assume 2 SoCs: A and B. A is old and didn't use SCMI while B is
> new and migrated to use SCMI. Now let us assume both A and B SoCs have
> exact same version/revision of an IP: X. Now just because B uses SCMI,
> should X have one compatible to be used in A and another in B. That
> doesn't sound right IMO.

That's trivial to answer, because these are different SoCs. Compatibles
are SoC specific and every SoC-IP-block needs its compatible. Rob was
repeating this many times that versioned compatibles are discouraged.

> 
> If X on A has to manage clocks and voltage separately while the same X
> on B uses SCMI to manage them together as performance domain, then the
> presence(or absence) of those properties must indicate the difference and
> not a change in compaible for the IP X. But it is upto Qcom platform
> maintainer, IP driver maintainer and DT maintainers to decide, I will
> leave that them. I just wanted to express my opinion on the matter.




Best regards,
Krzysztof

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

[Sudeep Holla]

On Wed, Feb 28, 2024 at 03:20:44PM +0100, Krzysztof Kozlowski wrote:
> On 28/02/2024 15:02, Sudeep Holla wrote:
> > On Wed, Feb 28, 2024 at 02:27:30PM +0100, Ulf Hansson wrote:
> >> On Mon, 26 Feb 2024 at 15:24, Nikunj Kela <quic_nkela@quicinc.com> wrote:
> >>>
> >>> Hi Sudeep,
> >>>
> >>> I would like to conclude on this thread. I was discussing this with Ulf.
> >>> He thinks that using the domain names to identify if platform is
> >>> abstracting clocks etc. are not scalable and sufficient. Instead he
> >>> thinks that the change in the interface to OS(and FW) is a good
> >>> candidate for a new compatible(even though HW is same).  Even for SCMI,
> >>> we do change phandle in DT to SCMI protocol phandle so that is like a
> >>> different platform altogether. Could you please let me know if you still
> >>> think that using a different compatible in this case is not warranted.
> >>
> >> My apologies for joining this discussion at this late state. Yet, I
> >> just wanted to confirm what Nikunj said above.
> >>
> >> In the end we are indeed talking about adding a new platform, as
> >> changing the FW interface from a QCOM proprietary one into SCMI,
> >> simply requires updates to a DTS file(s) that is platform specific.
> >>
> > 
> > The way I read this sounds like all this are platform specific and need
> > new compatible.
> > 
> >> That said, it also seems reasonable to me to use a compatible string,
> >> to allow us to describe the update of HW for various affected devices.
> >>
> > 
> > While I agree with the above statement, it depends on what you refer as
> > update of HW above. It is all Qcom specific and there is so much turn
> > between SoCs that this shouldn't matter but I would like to take example
> > and describe what I initially mentioned/argued against.
> > 
> > Lets us assume 2 SoCs: A and B. A is old and didn't use SCMI while B is
> > new and migrated to use SCMI. Now let us assume both A and B SoCs have
> > exact same version/revision of an IP: X. Now just because B uses SCMI,
> > should X have one compatible to be used in A and another in B. That
> > doesn't sound right IMO.
> 
> That's trivial to answer, because these are different SoCs. Compatibles
> are SoC specific and every SoC-IP-block needs its compatible. Rob was
> repeating this many times that versioned compatibles are discouraged.

OK I may have confused or derailed the discussion with the mention of
"exact same version/revision" of X. This is not related versioned compatibles.
Let me try to explain it with some real example. If you look at all the
users of "arm,coresight-tpiu", they all have same compatible on all the
platforms irrespective of the clock/reset/voltage/power domain providers
on these platforms.

E.g. on juno it is based on SCMI while on qcom-msm8974/apq8064 or
hi3660/hi6220 it is platform specific clock/power domain providers.
However all these platform have the same compatible "arm,coresight-tpiu".
That was the point I was trying to make and not related to versioned
compatible for different versions on an IP.


-- 
Regards,
Sudeep

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

[Ulf Hansson]

On Wed, 28 Feb 2024 at 17:09, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> On Wed, Feb 28, 2024 at 03:20:44PM +0100, Krzysztof Kozlowski wrote:
> > On 28/02/2024 15:02, Sudeep Holla wrote:
> > > On Wed, Feb 28, 2024 at 02:27:30PM +0100, Ulf Hansson wrote:
> > >> On Mon, 26 Feb 2024 at 15:24, Nikunj Kela <quic_nkela@quicinc.com> wrote:
> > >>>
> > >>> Hi Sudeep,
> > >>>
> > >>> I would like to conclude on this thread. I was discussing this with Ulf.
> > >>> He thinks that using the domain names to identify if platform is
> > >>> abstracting clocks etc. are not scalable and sufficient. Instead he
> > >>> thinks that the change in the interface to OS(and FW) is a good
> > >>> candidate for a new compatible(even though HW is same).  Even for SCMI,
> > >>> we do change phandle in DT to SCMI protocol phandle so that is like a
> > >>> different platform altogether. Could you please let me know if you still
> > >>> think that using a different compatible in this case is not warranted.
> > >>
> > >> My apologies for joining this discussion at this late state. Yet, I
> > >> just wanted to confirm what Nikunj said above.
> > >>
> > >> In the end we are indeed talking about adding a new platform, as
> > >> changing the FW interface from a QCOM proprietary one into SCMI,
> > >> simply requires updates to a DTS file(s) that is platform specific.
> > >>
> > >
> > > The way I read this sounds like all this are platform specific and need
> > > new compatible.
> > >
> > >> That said, it also seems reasonable to me to use a compatible string,
> > >> to allow us to describe the update of HW for various affected devices.
> > >>
> > >
> > > While I agree with the above statement, it depends on what you refer as
> > > update of HW above. It is all Qcom specific and there is so much turn
> > > between SoCs that this shouldn't matter but I would like to take example
> > > and describe what I initially mentioned/argued against.
> > >
> > > Lets us assume 2 SoCs: A and B. A is old and didn't use SCMI while B is
> > > new and migrated to use SCMI. Now let us assume both A and B SoCs have
> > > exact same version/revision of an IP: X. Now just because B uses SCMI,
> > > should X have one compatible to be used in A and another in B. That
> > > doesn't sound right IMO.
> >
> > That's trivial to answer, because these are different SoCs. Compatibles
> > are SoC specific and every SoC-IP-block needs its compatible. Rob was
> > repeating this many times that versioned compatibles are discouraged.
>
> OK I may have confused or derailed the discussion with the mention of
> "exact same version/revision" of X. This is not related versioned compatibles.
> Let me try to explain it with some real example. If you look at all the
> users of "arm,coresight-tpiu", they all have same compatible on all the
> platforms irrespective of the clock/reset/voltage/power domain providers
> on these platforms.
>
> E.g. on juno it is based on SCMI while on qcom-msm8974/apq8064 or
> hi3660/hi6220 it is platform specific clock/power domain providers.
> However all these platform have the same compatible "arm,coresight-tpiu".
> That was the point I was trying to make and not related to versioned
> compatible for different versions on an IP.

That's perfectly fine, if that is sufficient. It would also be
perfectly fine to extend it with a platform/soc specific compatible,
when needed.

An example could be:
compatible = "qcom,sm8450-coresight-tpiu", "arm,coresight-tpiu";

Krzysztof, please correct me if I am wrong.

Kind regards
Uffe

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

[Srinivas Kandagatla]

On 28/02/2024 16:22, Ulf Hansson wrote:
> On Wed, 28 Feb 2024 at 17:09, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>
>> On Wed, Feb 28, 2024 at 03:20:44PM +0100, Krzysztof Kozlowski wrote:
>>> On 28/02/2024 15:02, Sudeep Holla wrote:
>>>> On Wed, Feb 28, 2024 at 02:27:30PM +0100, Ulf Hansson wrote:
>>>>> On Mon, 26 Feb 2024 at 15:24, Nikunj Kela <quic_nkela@quicinc.com> wrote:
>>>>>>
>>>>>> Hi Sudeep,
>>>>>>
>>>>>> I would like to conclude on this thread. I was discussing this with Ulf.
>>>>>> He thinks that using the domain names to identify if platform is
>>>>>> abstracting clocks etc. are not scalable and sufficient. Instead he
>>>>>> thinks that the change in the interface to OS(and FW) is a good
>>>>>> candidate for a new compatible(even though HW is same).  Even for SCMI,
>>>>>> we do change phandle in DT to SCMI protocol phandle so that is like a
>>>>>> different platform altogether. Could you please let me know if you still
>>>>>> think that using a different compatible in this case is not warranted.
>>>>>
>>>>> My apologies for joining this discussion at this late state. Yet, I
>>>>> just wanted to confirm what Nikunj said above.
>>>>>
>>>>> In the end we are indeed talking about adding a new platform, as
>>>>> changing the FW interface from a QCOM proprietary one into SCMI,
>>>>> simply requires updates to a DTS file(s) that is platform specific.
>>>>>
>>>>
>>>> The way I read this sounds like all this are platform specific and need
>>>> new compatible.
>>>>
>>>>> That said, it also seems reasonable to me to use a compatible string,
>>>>> to allow us to describe the update of HW for various affected devices.
>>>>>
>>>>
>>>> While I agree with the above statement, it depends on what you refer as
>>>> update of HW above. It is all Qcom specific and there is so much turn
>>>> between SoCs that this shouldn't matter but I would like to take example
>>>> and describe what I initially mentioned/argued against.
>>>>
>>>> Lets us assume 2 SoCs: A and B. A is old and didn't use SCMI while B is
>>>> new and migrated to use SCMI. Now let us assume both A and B SoCs have
>>>> exact same version/revision of an IP: X. Now just because B uses SCMI,
>>>> should X have one compatible to be used in A and another in B. That
>>>> doesn't sound right IMO.
>>>
>>> That's trivial to answer, because these are different SoCs. Compatibles
>>> are SoC specific and every SoC-IP-block needs its compatible. Rob was
>>> repeating this many times that versioned compatibles are discouraged.
>>
>> OK I may have confused or derailed the discussion with the mention of
>> "exact same version/revision" of X. This is not related versioned compatibles.
>> Let me try to explain it with some real example. If you look at all the
>> users of "arm,coresight-tpiu", they all have same compatible on all the
>> platforms irrespective of the clock/reset/voltage/power domain providers
>> on these platforms.
>>
>> E.g. on juno it is based on SCMI while on qcom-msm8974/apq8064 or
>> hi3660/hi6220 it is platform specific clock/power domain providers.
>> However all these platform have the same compatible "arm,coresight-tpiu".
>> That was the point I was trying to make and not related to versioned
>> compatible for different versions on an IP.
> 
> That's perfectly fine, if that is sufficient. It would also be
> perfectly fine to extend it with a platform/soc specific compatible,
> when needed.
> 
> An example could be:
> compatible = "qcom,sm8450-coresight-tpiu", "arm,coresight-tpiu";

The issue is not the same as the above example.

We already have a soc specific compatible in this case
ex: "qcom,sc8280xp-ufshc"

making another compatible like "qcom,sc8280xp-ufshc-scmi" or 
"qcom,sc8280xp-ufshc-xyz" based on how some of the resources (clks, 
regulators) are provided in bindings does not really make sense.

Fact is that we are representing the same IP block.

AFAIU, we should go with same compatible irrespective of how the 
resourcing needs are satisfied.

thanks,
Srini

> 
> Krzysztof, please correct me if I am wrong.
> 
> Kind regards
> Uffe

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

[Ulf Hansson]

On Wed, 28 Feb 2024 at 18:11, Srinivas Kandagatla
<srinivas.kandagatla@linaro.org> wrote:
>
>
>
> On 28/02/2024 16:22, Ulf Hansson wrote:
> > On Wed, 28 Feb 2024 at 17:09, Sudeep Holla <sudeep.holla@arm.com> wrote:
> >>
> >> On Wed, Feb 28, 2024 at 03:20:44PM +0100, Krzysztof Kozlowski wrote:
> >>> On 28/02/2024 15:02, Sudeep Holla wrote:
> >>>> On Wed, Feb 28, 2024 at 02:27:30PM +0100, Ulf Hansson wrote:
> >>>>> On Mon, 26 Feb 2024 at 15:24, Nikunj Kela <quic_nkela@quicinc.com> wrote:
> >>>>>>
> >>>>>> Hi Sudeep,
> >>>>>>
> >>>>>> I would like to conclude on this thread. I was discussing this with Ulf.
> >>>>>> He thinks that using the domain names to identify if platform is
> >>>>>> abstracting clocks etc. are not scalable and sufficient. Instead he
> >>>>>> thinks that the change in the interface to OS(and FW) is a good
> >>>>>> candidate for a new compatible(even though HW is same).  Even for SCMI,
> >>>>>> we do change phandle in DT to SCMI protocol phandle so that is like a
> >>>>>> different platform altogether. Could you please let me know if you still
> >>>>>> think that using a different compatible in this case is not warranted.
> >>>>>
> >>>>> My apologies for joining this discussion at this late state. Yet, I
> >>>>> just wanted to confirm what Nikunj said above.
> >>>>>
> >>>>> In the end we are indeed talking about adding a new platform, as
> >>>>> changing the FW interface from a QCOM proprietary one into SCMI,
> >>>>> simply requires updates to a DTS file(s) that is platform specific.
> >>>>>
> >>>>
> >>>> The way I read this sounds like all this are platform specific and need
> >>>> new compatible.
> >>>>
> >>>>> That said, it also seems reasonable to me to use a compatible string,
> >>>>> to allow us to describe the update of HW for various affected devices.
> >>>>>
> >>>>
> >>>> While I agree with the above statement, it depends on what you refer as
> >>>> update of HW above. It is all Qcom specific and there is so much turn
> >>>> between SoCs that this shouldn't matter but I would like to take example
> >>>> and describe what I initially mentioned/argued against.
> >>>>
> >>>> Lets us assume 2 SoCs: A and B. A is old and didn't use SCMI while B is
> >>>> new and migrated to use SCMI. Now let us assume both A and B SoCs have
> >>>> exact same version/revision of an IP: X. Now just because B uses SCMI,
> >>>> should X have one compatible to be used in A and another in B. That
> >>>> doesn't sound right IMO.
> >>>
> >>> That's trivial to answer, because these are different SoCs. Compatibles
> >>> are SoC specific and every SoC-IP-block needs its compatible. Rob was
> >>> repeating this many times that versioned compatibles are discouraged.
> >>
> >> OK I may have confused or derailed the discussion with the mention of
> >> "exact same version/revision" of X. This is not related versioned compatibles.
> >> Let me try to explain it with some real example. If you look at all the
> >> users of "arm,coresight-tpiu", they all have same compatible on all the
> >> platforms irrespective of the clock/reset/voltage/power domain providers
> >> on these platforms.
> >>
> >> E.g. on juno it is based on SCMI while on qcom-msm8974/apq8064 or
> >> hi3660/hi6220 it is platform specific clock/power domain providers.
> >> However all these platform have the same compatible "arm,coresight-tpiu".
> >> That was the point I was trying to make and not related to versioned
> >> compatible for different versions on an IP.
> >
> > That's perfectly fine, if that is sufficient. It would also be
> > perfectly fine to extend it with a platform/soc specific compatible,
> > when needed.
> >
> > An example could be:
> > compatible = "qcom,sm8450-coresight-tpiu", "arm,coresight-tpiu";
>
> The issue is not the same as the above example.
>
> We already have a soc specific compatible in this case
> ex: "qcom,sc8280xp-ufshc"
>
> making another compatible like "qcom,sc8280xp-ufshc-scmi" or
> "qcom,sc8280xp-ufshc-xyz" based on how some of the resources (clks,
> regulators) are provided in bindings does not really make sense.
>
> Fact is that we are representing the same IP block.
>
> AFAIU, we should go with same compatible irrespective of how the
> resourcing needs are satisfied.

I get your point. Nevertheless, we need to create a new platform (new
DTS file), as we are changing the FW interface to SCMI. That means the
toplevel compatible for the platform will be a new one
(Documentation/devicetree/bindings/arm/qcom.yaml).

I am not sure if it's correct/allowed to use that new platform-part as
an extension for the compatible for the IP blocks too? I thought it
was okay, but if not, drivers could match on the platform's compatible
too (not sure we want that though).

Kind regards
Uffe

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

[Sudeep Holla]

On Fri, Mar 01, 2024 at 12:53:25PM +0100, Ulf Hansson wrote:
> On Wed, 28 Feb 2024 at 18:11, Srinivas Kandagatla
> <srinivas.kandagatla@linaro.org> wrote:
> >
> >
> >
> > On 28/02/2024 16:22, Ulf Hansson wrote:
> > > On Wed, 28 Feb 2024 at 17:09, Sudeep Holla <sudeep.holla@arm.com> wrote:
> > >>
> > >> On Wed, Feb 28, 2024 at 03:20:44PM +0100, Krzysztof Kozlowski wrote:
> > >>> On 28/02/2024 15:02, Sudeep Holla wrote:
> > >>>> On Wed, Feb 28, 2024 at 02:27:30PM +0100, Ulf Hansson wrote:
> > >>>>> On Mon, 26 Feb 2024 at 15:24, Nikunj Kela <quic_nkela@quicinc.com> wrote:
> > >>>>>>
> > >>>>>> Hi Sudeep,
> > >>>>>>
> > >>>>>> I would like to conclude on this thread. I was discussing this with Ulf.
> > >>>>>> He thinks that using the domain names to identify if platform is
> > >>>>>> abstracting clocks etc. are not scalable and sufficient. Instead he
> > >>>>>> thinks that the change in the interface to OS(and FW) is a good
> > >>>>>> candidate for a new compatible(even though HW is same).  Even for SCMI,
> > >>>>>> we do change phandle in DT to SCMI protocol phandle so that is like a
> > >>>>>> different platform altogether. Could you please let me know if you still
> > >>>>>> think that using a different compatible in this case is not warranted.
> > >>>>>
> > >>>>> My apologies for joining this discussion at this late state. Yet, I
> > >>>>> just wanted to confirm what Nikunj said above.
> > >>>>>
> > >>>>> In the end we are indeed talking about adding a new platform, as
> > >>>>> changing the FW interface from a QCOM proprietary one into SCMI,
> > >>>>> simply requires updates to a DTS file(s) that is platform specific.
> > >>>>>
> > >>>>
> > >>>> The way I read this sounds like all this are platform specific and need
> > >>>> new compatible.
> > >>>>
> > >>>>> That said, it also seems reasonable to me to use a compatible string,
> > >>>>> to allow us to describe the update of HW for various affected devices.
> > >>>>>
> > >>>>
> > >>>> While I agree with the above statement, it depends on what you refer as
> > >>>> update of HW above. It is all Qcom specific and there is so much turn
> > >>>> between SoCs that this shouldn't matter but I would like to take example
> > >>>> and describe what I initially mentioned/argued against.
> > >>>>
> > >>>> Lets us assume 2 SoCs: A and B. A is old and didn't use SCMI while B is
> > >>>> new and migrated to use SCMI. Now let us assume both A and B SoCs have
> > >>>> exact same version/revision of an IP: X. Now just because B uses SCMI,
> > >>>> should X have one compatible to be used in A and another in B. That
> > >>>> doesn't sound right IMO.
> > >>>
> > >>> That's trivial to answer, because these are different SoCs. Compatibles
> > >>> are SoC specific and every SoC-IP-block needs its compatible. Rob was
> > >>> repeating this many times that versioned compatibles are discouraged.
> > >>
> > >> OK I may have confused or derailed the discussion with the mention of
> > >> "exact same version/revision" of X. This is not related versioned compatibles.
> > >> Let me try to explain it with some real example. If you look at all the
> > >> users of "arm,coresight-tpiu", they all have same compatible on all the
> > >> platforms irrespective of the clock/reset/voltage/power domain providers
> > >> on these platforms.
> > >>
> > >> E.g. on juno it is based on SCMI while on qcom-msm8974/apq8064 or
> > >> hi3660/hi6220 it is platform specific clock/power domain providers.
> > >> However all these platform have the same compatible "arm,coresight-tpiu".
> > >> That was the point I was trying to make and not related to versioned
> > >> compatible for different versions on an IP.
> > >
> > > That's perfectly fine, if that is sufficient. It would also be
> > > perfectly fine to extend it with a platform/soc specific compatible,
> > > when needed.
> > >
> > > An example could be:
> > > compatible = "qcom,sm8450-coresight-tpiu", "arm,coresight-tpiu";
> >
> > The issue is not the same as the above example.
> >
> > We already have a soc specific compatible in this case
> > ex: "qcom,sc8280xp-ufshc"
> >
> > making another compatible like "qcom,sc8280xp-ufshc-scmi" or
> > "qcom,sc8280xp-ufshc-xyz" based on how some of the resources (clks,
> > regulators) are provided in bindings does not really make sense.
> >
> > Fact is that we are representing the same IP block.
> >
> > AFAIU, we should go with same compatible irrespective of how the
> > resourcing needs are satisfied.
> 
> I get your point. Nevertheless, we need to create a new platform (new
> DTS file), as we are changing the FW interface to SCMI. That means the
> toplevel compatible for the platform will be a new one
> (Documentation/devicetree/bindings/arm/qcom.yaml).
>

While I don't understand the details of the above mentioned platform,
it should be a blanket rule that the toplevel compatible for the platform
has to be new.

Check
arch/arm64/boot/dts/arm/juno.dts
arch/arm64/boot/dts/arm/juno-scmi.dtsi
arch/arm64/boot/dts/arm/juno-scmi.dts

One is with old firmware interface and -scmi is with SCMI. No new top
level compatible change is needed. I understand it was switch from one
interface to the another and not like Qcom platforms which is moving
from in-kernel solution to firmware solution. But the general rule applies
here as well unless there are specific reasons for needing that exception.
I am not against it or ruling that out, just curious to understand them.

--
Regards,
Sudeep

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

[Nikunj Kela]

+Trilok

On 3/4/2024 3:01 AM, Sudeep Holla wrote:
> On Fri, Mar 01, 2024 at 12:53:25PM +0100, Ulf Hansson wrote:
>> On Wed, 28 Feb 2024 at 18:11, Srinivas Kandagatla
>> <srinivas.kandagatla@linaro.org> wrote:
>>>
>>>
>>> On 28/02/2024 16:22, Ulf Hansson wrote:
>>>> On Wed, 28 Feb 2024 at 17:09, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>>> On Wed, Feb 28, 2024 at 03:20:44PM +0100, Krzysztof Kozlowski wrote:
>>>>>> On 28/02/2024 15:02, Sudeep Holla wrote:
>>>>>>> On Wed, Feb 28, 2024 at 02:27:30PM +0100, Ulf Hansson wrote:
>>>>>>>> On Mon, 26 Feb 2024 at 15:24, Nikunj Kela <quic_nkela@quicinc.com> wrote:
>>>>>>>>> Hi Sudeep,
>>>>>>>>>
>>>>>>>>> I would like to conclude on this thread. I was discussing this with Ulf.
>>>>>>>>> He thinks that using the domain names to identify if platform is
>>>>>>>>> abstracting clocks etc. are not scalable and sufficient. Instead he
>>>>>>>>> thinks that the change in the interface to OS(and FW) is a good
>>>>>>>>> candidate for a new compatible(even though HW is same).  Even for SCMI,
>>>>>>>>> we do change phandle in DT to SCMI protocol phandle so that is like a
>>>>>>>>> different platform altogether. Could you please let me know if you still
>>>>>>>>> think that using a different compatible in this case is not warranted.
>>>>>>>> My apologies for joining this discussion at this late state. Yet, I
>>>>>>>> just wanted to confirm what Nikunj said above.
>>>>>>>>
>>>>>>>> In the end we are indeed talking about adding a new platform, as
>>>>>>>> changing the FW interface from a QCOM proprietary one into SCMI,
>>>>>>>> simply requires updates to a DTS file(s) that is platform specific.
>>>>>>>>
>>>>>>> The way I read this sounds like all this are platform specific and need
>>>>>>> new compatible.
>>>>>>>
>>>>>>>> That said, it also seems reasonable to me to use a compatible string,
>>>>>>>> to allow us to describe the update of HW for various affected devices.
>>>>>>>>
>>>>>>> While I agree with the above statement, it depends on what you refer as
>>>>>>> update of HW above. It is all Qcom specific and there is so much turn
>>>>>>> between SoCs that this shouldn't matter but I would like to take example
>>>>>>> and describe what I initially mentioned/argued against.
>>>>>>>
>>>>>>> Lets us assume 2 SoCs: A and B. A is old and didn't use SCMI while B is
>>>>>>> new and migrated to use SCMI. Now let us assume both A and B SoCs have
>>>>>>> exact same version/revision of an IP: X. Now just because B uses SCMI,
>>>>>>> should X have one compatible to be used in A and another in B. That
>>>>>>> doesn't sound right IMO.
>>>>>> That's trivial to answer, because these are different SoCs. Compatibles
>>>>>> are SoC specific and every SoC-IP-block needs its compatible. Rob was
>>>>>> repeating this many times that versioned compatibles are discouraged.
>>>>> OK I may have confused or derailed the discussion with the mention of
>>>>> "exact same version/revision" of X. This is not related versioned compatibles.
>>>>> Let me try to explain it with some real example. If you look at all the
>>>>> users of "arm,coresight-tpiu", they all have same compatible on all the
>>>>> platforms irrespective of the clock/reset/voltage/power domain providers
>>>>> on these platforms.
>>>>>
>>>>> E.g. on juno it is based on SCMI while on qcom-msm8974/apq8064 or
>>>>> hi3660/hi6220 it is platform specific clock/power domain providers.
>>>>> However all these platform have the same compatible "arm,coresight-tpiu".
>>>>> That was the point I was trying to make and not related to versioned
>>>>> compatible for different versions on an IP.
>>>> That's perfectly fine, if that is sufficient. It would also be
>>>> perfectly fine to extend it with a platform/soc specific compatible,
>>>> when needed.
>>>>
>>>> An example could be:
>>>> compatible = "qcom,sm8450-coresight-tpiu", "arm,coresight-tpiu";
>>> The issue is not the same as the above example.
>>>
>>> We already have a soc specific compatible in this case
>>> ex: "qcom,sc8280xp-ufshc"
>>>
>>> making another compatible like "qcom,sc8280xp-ufshc-scmi" or
>>> "qcom,sc8280xp-ufshc-xyz" based on how some of the resources (clks,
>>> regulators) are provided in bindings does not really make sense.
>>>
>>> Fact is that we are representing the same IP block.
>>>
>>> AFAIU, we should go with same compatible irrespective of how the
>>> resourcing needs are satisfied.
>> I get your point. Nevertheless, we need to create a new platform (new
>> DTS file), as we are changing the FW interface to SCMI. That means the
>> toplevel compatible for the platform will be a new one
>> (Documentation/devicetree/bindings/arm/qcom.yaml).
>>
> While I don't understand the details of the above mentioned platform,
> it should be a blanket rule that the toplevel compatible for the platform
> has to be new.
>
> Check
> arch/arm64/boot/dts/arm/juno.dts
> arch/arm64/boot/dts/arm/juno-scmi.dtsi
> arch/arm64/boot/dts/arm/juno-scmi.dts
>
> One is with old firmware interface and -scmi is with SCMI. No new top
> level compatible change is needed. I understand it was switch from one
> interface to the another and not like Qcom platforms which is moving
> from in-kernel solution to firmware solution. But the general rule applies
> here as well unless there are specific reasons for needing that exception.
> I am not against it or ruling that out, just curious to understand them.
>
> --
> Regards,
> Sudeep

Hi All,

Thank you all for all your inputs on this. I discussed this with Srini 
and he suggested that we could use a new optional DT property like 
"qcom, fw-managed" to ascertain if we are running on firmware managed 
variant. Thus each device node in the dts can add this. I did ask him 
if, instead of putting it to each device node, we can use it at the 
board level however he thinks that it would not be easy to update yaml 
documentation on DT nodes with board level property. So if everyone here 
agrees with this approach, I would like to close this thread.

Thank you!

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

[Trilok Soni]

On 3/12/2024 9:52 AM, Nikunj Kela wrote:
>> One is with old firmware interface and -scmi is with SCMI. No new top
>> level compatible change is needed. I understand it was switch from one
>> interface to the another and not like Qcom platforms which is moving
>> from in-kernel solution to firmware solution. But the general rule applies
>> here as well unless there are specific reasons for needing that exception.
>> I am not against it or ruling that out, just curious to understand them.
>>
>> -- 
>> Regards,
>> Sudeep
> 
> Hi All,
> 
> Thank you all for all your inputs on this. I discussed this with Srini and he suggested that we could use a new optional DT property like "qcom, fw-managed" to ascertain if we are running on firmware managed variant. Thus each device node in the dts can add this. I did ask him if, instead of putting it to each device node, we can use it at the board level however he thinks that it would not be easy to update yaml documentation on DT nodes with board level property. So if everyone here agrees with this approach, I would like to close this thread.
> 
> Thank you!

Is "fw-managed" name restricted to SCMI based approaches? Why it needs to be per
driver device-tree node? What happens when I attach the same SOC-IP
along w/ the RISC-V Application core and use the RPMI? 

Should not have fw-managed defined at the devicetree spec? This is not a
ARM specific problem since the drivers which are going to use this flag/property
are generic shouldn't care about SCMI/RPMI. 

Basically, I would prefer better than "qcom, fw-managed" since this is not
a qcom specific problem.

-- 
---Trilok Soni

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

[Nikunj Kela]

On 3/12/2024 9:58 AM, Trilok Soni wrote:
> On 3/12/2024 9:52 AM, Nikunj Kela wrote:
>>> One is with old firmware interface and -scmi is with SCMI. No new top
>>> level compatible change is needed. I understand it was switch from one
>>> interface to the another and not like Qcom platforms which is moving
>>> from in-kernel solution to firmware solution. But the general rule applies
>>> here as well unless there are specific reasons for needing that exception.
>>> I am not against it or ruling that out, just curious to understand them.
>>>
>>> -- 
>>> Regards,
>>> Sudeep
>> Hi All,
>>
>> Thank you all for all your inputs on this. I discussed this with Srini and he suggested that we could use a new optional DT property like "qcom, fw-managed" to ascertain if we are running on firmware managed variant. Thus each device node in the dts can add this. I did ask him if, instead of putting it to each device node, we can use it at the board level however he thinks that it would not be easy to update yaml documentation on DT nodes with board level property. So if everyone here agrees with this approach, I would like to close this thread.
>>
>> Thank you!
> Is "fw-managed" name restricted to SCMI based approaches? Why it needs to be per
> driver device-tree node? What happens when I attach the same SOC-IP
> along w/ the RISC-V Application core and use the RPMI?
In theory, fw-managed is not restricted to SCMI based approach however 
currently, we are using it with SCMI based approach only.
>
> Should not have fw-managed defined at the devicetree spec? This is not a
> ARM specific problem since the drivers which are going to use this flag/property
> are generic shouldn't care about SCMI/RPMI.
This requires more discussion I guess, I am not opposed to it.
>
> Basically, I would prefer better than "qcom, fw-managed" since this is not
> a qcom specific problem.
Sure, we can remove qcom if you think that's a better name.

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

[Srinivas Kandagatla]

On 12/03/2024 16:58, Trilok Soni wrote:
> On 3/12/2024 9:52 AM, Nikunj Kela wrote:
>>> One is with old firmware interface and -scmi is with SCMI. No new top
>>> level compatible change is needed. I understand it was switch from one
>>> interface to the another and not like Qcom platforms which is moving
>>> from in-kernel solution to firmware solution. But the general rule applies
>>> here as well unless there are specific reasons for needing that exception.
>>> I am not against it or ruling that out, just curious to understand them.
>>>
>>> -- 
>>> Regards,
>>> Sudeep
>>
>> Hi All,
>>
>> Thank you all for all your inputs on this. I discussed this with Srini and he suggested that we could use a new optional DT property like "qcom, fw-managed" to ascertain if we are running on firmware managed variant. Thus each device node in the dts can add this. I did ask him if, instead of putting it to each device node, we can use it at the board level however he thinks that it would not be easy to update yaml documentation on DT nodes with board level property. So if everyone here agrees with this approach, I would like to close this thread.
>>
>> Thank you!
> 
> Is "fw-managed" name restricted to SCMI based approaches? Why it needs to be per
> driver device-tree node? 

This makes it much more explicit in device bindings on the resource 
dependencies.

What happens when I attach the same SOC-IP
> along w/ the RISC-V Application core and use the RPMI?
> 
> Should not have fw-managed defined at the devicetree spec? This is not a
> ARM specific problem since the drivers which are going to use this flag/property
> are generic shouldn't care about SCMI/RPMI.
> 

> Basically, I would prefer better than "qcom, fw-managed" since this is not
> a qcom specific problem.


We already have something like this in mainline where the BAM DMA 
controller is remotely powered.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml?h=v6.8


--srini

> 

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

[Trilok Soni]

On 3/12/2024 10:21 AM, Srinivas Kandagatla wrote:
> 
>> Basically, I would prefer better than "qcom, fw-managed" since this is not
>> a qcom specific problem.
> 
> 
> We already have something like this in mainline where the BAM DMA controller is remotely powered.
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml?h=v6.8
> 

As you can see it is already fragmented. Why we need to create one more approach
which is not scalable and specific to SOC vendor? 

SCMI or RPMI based firmware is not a QC specific. I also have allergic reaction
when I see drivers modified w/ if (fw_managed) {..} but that is a discussion
for some other day. 


-- 
---Trilok Soni

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

[Ulf Hansson]

On Tue, 12 Mar 2024 at 18:25, Trilok Soni <quic_tsoni@quicinc.com> wrote:
>
> On 3/12/2024 10:21 AM, Srinivas Kandagatla wrote:
> >
> >> Basically, I would prefer better than "qcom, fw-managed" since this is not
> >> a qcom specific problem.
> >
> >
> > We already have something like this in mainline where the BAM DMA controller is remotely powered.
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml?h=v6.8
> >
>
> As you can see it is already fragmented. Why we need to create one more approach
> which is not scalable and specific to SOC vendor?
>
> SCMI or RPMI based firmware is not a QC specific. I also have allergic reaction
> when I see drivers modified w/ if (fw_managed) {..} but that is a discussion
> for some other day.
>
>

For the record, I fully agree with Trilok here.

More importantly, why is the other suggested approach(es) a problem? I
don't get it.

Kind regards
Uffe

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

[Nikunj Kela]

On 3/13/2024 2:19 AM, Ulf Hansson wrote:
> On Tue, 12 Mar 2024 at 18:25, Trilok Soni <quic_tsoni@quicinc.com> wrote:
>> On 3/12/2024 10:21 AM, Srinivas Kandagatla wrote:
>>>> Basically, I would prefer better than "qcom, fw-managed" since this is not
>>>> a qcom specific problem.
>>>
>>> We already have something like this in mainline where the BAM DMA controller is remotely powered.
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml?h=v6.8
>>>
>> As you can see it is already fragmented. Why we need to create one more approach
>> which is not scalable and specific to SOC vendor?
>>
>> SCMI or RPMI based firmware is not a QC specific. I also have allergic reaction
>> when I see drivers modified w/ if (fw_managed) {..} but that is a discussion
>> for some other day.
>>
>>
> For the record, I fully agree with Trilok here.
>
> More importantly, why is the other suggested approach(es) a problem? I
> don't get it.

Hi Ulf,

Srini mentioned that the option of "every driver checking for board 
level compatible/board-id" was once tried before and was rejected in 
upstream. So I didn't want to embark upon something that was already 
rejected once. Srini can provide pointers on that.

>
> Kind regards
> Uffe

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

[Sudeep Holla]

On Tue, Mar 12, 2024 at 09:52:56AM -0700, Nikunj Kela wrote:
> +Trilok
>
> On 3/4/2024 3:01 AM, Sudeep Holla wrote:
> > arch/arm64/boot/dts/arm/juno-scmi.dts
> >
> > One is with old firmware interface and -scmi is with SCMI. No new top
> > level compatible change is needed. I understand it was switch from one
> > interface to the another and not like Qcom platforms which is moving
> > from in-kernel solution to firmware solution. But the general rule applies
> > here as well unless there are specific reasons for needing that exception.
> > I am not against it or ruling that out, just curious to understand them.
>
> Thank you all for all your inputs on this. I discussed this with Srini and
> he suggested that we could use a new optional DT property like "qcom,
> fw-managed" to ascertain if we are running on firmware managed variant. Thus
> each device node in the dts can add this. I did ask him if, instead of
> putting it to each device node, we can use it at the board level however he
> thinks that it would not be easy to update yaml documentation on DT nodes
> with board level property. So if everyone here agrees with this approach, I
> would like to close this thread.

The counter argument from me for that is simple. If you are OK to manage with
one board level compatible/property(doesn't matter for this discussion), then
why can't that be the compatible of the firmware itself(SCMI and RPMI both
must have their own compatible already). The main point is why do you need
any extra information when they are already present. My comment is just for
this one board level compatible/property.

--
Regards,
Sudeep

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

[Srinivas Kandagatla]

On 13/03/2024 09:19, Ulf Hansson wrote:
> On Tue, 12 Mar 2024 at 18:25, Trilok Soni <quic_tsoni@quicinc.com> wrote:
>>
>> On 3/12/2024 10:21 AM, Srinivas Kandagatla wrote:
>>>
>>>> Basically, I would prefer better than "qcom, fw-managed" since this is not
>>>> a qcom specific problem.
>>>
>>>
>>> We already have something like this in mainline where the BAM DMA controller is remotely powered.
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml?h=v6.8
>>>
>>
>> As you can see it is already fragmented. Why we need to create one more approach
>> which is not scalable and specific to SOC vendor?
>>
>> SCMI or RPMI based firmware is not a QC specific. I also have allergic reaction
>> when I see drivers modified w/ if (fw_managed) {..} but that is a discussion
>> for some other day.
>>
>>
> 
> For the record, I fully agree with Trilok here.
> 
> More importantly, why is the other suggested approach(es) a problem? I
> don't get it.

Are we going to do this with each driver on every new board that will be 
added?



thanks,
Srini
> 

> Kind regards
> Uffe

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

[Srinivas Kandagatla]

On 12/03/2024 17:25, Trilok Soni wrote:
> On 3/12/2024 10:21 AM, Srinivas Kandagatla wrote:
>>
>>> Basically, I would prefer better than "qcom, fw-managed" since this is not
>>> a qcom specific problem.
>>
>>
>> We already have something like this in mainline where the BAM DMA controller is remotely powered.
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml?h=v6.8
>>
> 
> As you can see it is already fragmented. Why we need to create one more approach
> which is not scalable and specific to SOC vendor?

The whole issue around this new checks is that the driver/binding is not 
designed to expect same set of resources from different TYPES of providers.
If the driver was designed to support opp's and power domains and make 
the resources handle in a unified way then some/all of these changes 
will naturally fit in.


> 
> SCMI or RPMI based firmware is not a QC specific. I also have allergic reaction

I agree this are not QC specific, am fine with generic dt-binding like 
firmware-managed-resources or something on those lines if DT-maintainers 
are happy with.

What is your suggestion?


> when I see drivers modified w/ if (fw_managed) {..} but that is a discussion

I don't think we have a choice here, either we do this check at 
compatible level or dt-property level or resource level in every drivers.

--srini

> for some other day.
> 
> 

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

[Srinivas Kandagatla]

On 13/03/2024 11:04, Sudeep Holla wrote:
> On Tue, Mar 12, 2024 at 09:52:56AM -0700, Nikunj Kela wrote:
>> +Trilok
>>
>> On 3/4/2024 3:01 AM, Sudeep Holla wrote:
>>> arch/arm64/boot/dts/arm/juno-scmi.dts
>>>
>>> One is with old firmware interface and -scmi is with SCMI. No new top
>>> level compatible change is needed. I understand it was switch from one
>>> interface to the another and not like Qcom platforms which is moving
>>> from in-kernel solution to firmware solution. But the general rule applies
>>> here as well unless there are specific reasons for needing that exception.
>>> I am not against it or ruling that out, just curious to understand them.
>>
>> Thank you all for all your inputs on this. I discussed this with Srini and
>> he suggested that we could use a new optional DT property like "qcom,
>> fw-managed" to ascertain if we are running on firmware managed variant. Thus
>> each device node in the dts can add this. I did ask him if, instead of
>> putting it to each device node, we can use it at the board level however he
>> thinks that it would not be easy to update yaml documentation on DT nodes
>> with board level property. So if everyone here agrees with this approach, I
>> would like to close this thread.
> 
> The counter argument from me for that is simple. If you are OK to manage with
> one board level compatible/property(doesn't matter for this discussion), then
> why can't that be the compatible of the firmware itself(SCMI and RPMI both
> must have their own compatible already). The main point is why do you need
> any extra information when they are already present. My comment is just for
> this one board level compatible/property.

Board specific compatible might not scale, as this will bring in changes 
to every driver and bindings with new board addition.

BoardLevel property, how are we going to reflect this each device DT 
bindings?

Is this new property going to be part of scmi/rpmi firmware node?


--srini



> 
> --
> Regards,
> Sudeep

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

[Trilok Soni]

On 3/13/2024 4:49 AM, Srinivas Kandagatla wrote:
> 
> On 12/03/2024 17:25, Trilok Soni wrote:
>> On 3/12/2024 10:21 AM, Srinivas Kandagatla wrote:
>>>
>>>> Basically, I would prefer better than "qcom, fw-managed" since this is not
>>>> a qcom specific problem.
>>>
>>>
>>> We already have something like this in mainline where the BAM DMA controller is remotely powered.
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml?h=v6.8
>>>
>>
>> As you can see it is already fragmented. Why we need to create one more approach
>> which is not scalable and specific to SOC vendor?
> 
> The whole issue around this new checks is that the driver/binding is not designed to expect same set of resources from different TYPES of providers.
> If the driver was designed to support opp's and power domains and make the resources handle in a unified way then some/all of these changes will naturally fit in.
> 
> 
>>
>> SCMI or RPMI based firmware is not a QC specific. I also have allergic reaction
> 
> I agree this are not QC specific, am fine with generic dt-binding like firmware-managed-resources or something on those lines if DT-maintainers are happy with.
> 
> What is your suggestion?

Yes, DT-spec will be a good start.

> 
> 
>> when I see drivers modified w/ if (fw_managed) {..} but that is a discussion
> 
> I don't think we have a choice here, either we do this check at compatible level or dt-property level or resource level in every drivers.

I don't understand yet why we don't have any other choices but do the conditional checks? Maybe explaining
with the example will help? Start w/ clocks?


-- 
---Trilok Soni

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

[Sudeep Holla]

On Wed, Mar 13, 2024 at 01:04:15PM +0000, Srinivas Kandagatla wrote:
> 
> 
> On 13/03/2024 11:04, Sudeep Holla wrote:
> > On Tue, Mar 12, 2024 at 09:52:56AM -0700, Nikunj Kela wrote:
> > > +Trilok
> > > 
> > > On 3/4/2024 3:01 AM, Sudeep Holla wrote:
> > > > arch/arm64/boot/dts/arm/juno-scmi.dts
> > > > 
> > > > One is with old firmware interface and -scmi is with SCMI. No new top
> > > > level compatible change is needed. I understand it was switch from one
> > > > interface to the another and not like Qcom platforms which is moving
> > > > from in-kernel solution to firmware solution. But the general rule applies
> > > > here as well unless there are specific reasons for needing that exception.
> > > > I am not against it or ruling that out, just curious to understand them.
> > > 
> > > Thank you all for all your inputs on this. I discussed this with Srini and
> > > he suggested that we could use a new optional DT property like "qcom,
> > > fw-managed" to ascertain if we are running on firmware managed variant. Thus
> > > each device node in the dts can add this. I did ask him if, instead of
> > > putting it to each device node, we can use it at the board level however he
> > > thinks that it would not be easy to update yaml documentation on DT nodes
> > > with board level property. So if everyone here agrees with this approach, I
> > > would like to close this thread.
> > 
> > The counter argument from me for that is simple. If you are OK to manage with
> > one board level compatible/property(doesn't matter for this discussion), then
> > why can't that be the compatible of the firmware itself(SCMI and RPMI both
> > must have their own compatible already). The main point is why do you need
> > any extra information when they are already present. My comment is just for
> > this one board level compatible/property.
> 
> Board specific compatible might not scale, as this will bring in changes to
> every driver and bindings with new board addition.
> 
> BoardLevel property, how are we going to reflect this each device DT
> bindings?
> 
> Is this new property going to be part of scmi/rpmi firmware node?
> 

Nope, the point was will the presence of (available) scmi/rpmi device
node suffice if we are thinking of single board level property or
compatible. I was not mixing the discussion of whether adding such
a property to each needed device node in this discussion to keep it
simple. I have already expressed my opinion on that.

I am sure qcom will go and do what they want which may work fine for
qcom specific drivers but it will not work for a generic IP driver
used by many vendors. Not sure if Qcom SoCs are just bundle of Qcom
specific IPs or they do have some generic non-Qcom IPs. Lets us take
SMMU as example. If the SCMI/RPMI controls the power to it, would you
go and add this new compatible in the generic SMMU bindings and add
support in the driver for that ? That is big NO as the driver would
just need to use std framework interface(doesn't matter Runtime PM/Clock/
Reset/genpd/PM OPP). That means they don't need any specific bindings
to inform SMMU driver that the power is f/w managed.

Hope I have conveyed my point better with example this time.

--
Regards,
Sudeep

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

[Nikunj Kela]

On 3/14/2024 3:55 AM, Sudeep Holla wrote:
> On Wed, Mar 13, 2024 at 01:04:15PM +0000, Srinivas Kandagatla wrote:
>>
>> On 13/03/2024 11:04, Sudeep Holla wrote:
>>> On Tue, Mar 12, 2024 at 09:52:56AM -0700, Nikunj Kela wrote:
>>>> +Trilok
>>>>
>>>> On 3/4/2024 3:01 AM, Sudeep Holla wrote:
>>>>> arch/arm64/boot/dts/arm/juno-scmi.dts
>>>>>
>>>>> One is with old firmware interface and -scmi is with SCMI. No new top
>>>>> level compatible change is needed. I understand it was switch from one
>>>>> interface to the another and not like Qcom platforms which is moving
>>>>> from in-kernel solution to firmware solution. But the general rule applies
>>>>> here as well unless there are specific reasons for needing that exception.
>>>>> I am not against it or ruling that out, just curious to understand them.
>>>> Thank you all for all your inputs on this. I discussed this with Srini and
>>>> he suggested that we could use a new optional DT property like "qcom,
>>>> fw-managed" to ascertain if we are running on firmware managed variant. Thus
>>>> each device node in the dts can add this. I did ask him if, instead of
>>>> putting it to each device node, we can use it at the board level however he
>>>> thinks that it would not be easy to update yaml documentation on DT nodes
>>>> with board level property. So if everyone here agrees with this approach, I
>>>> would like to close this thread.
>>> The counter argument from me for that is simple. If you are OK to manage with
>>> one board level compatible/property(doesn't matter for this discussion), then
>>> why can't that be the compatible of the firmware itself(SCMI and RPMI both
>>> must have their own compatible already). The main point is why do you need
>>> any extra information when they are already present. My comment is just for
>>> this one board level compatible/property.
>> Board specific compatible might not scale, as this will bring in changes to
>> every driver and bindings with new board addition.
>>
>> BoardLevel property, how are we going to reflect this each device DT
>> bindings?
>>
>> Is this new property going to be part of scmi/rpmi firmware node?
>>
> Nope, the point was will the presence of (available) scmi/rpmi device
> node suffice if we are thinking of single board level property or
> compatible. I was not mixing the discussion of whether adding such
> a property to each needed device node in this discussion to keep it
> simple. I have already expressed my opinion on that.
>
> I am sure qcom will go and do what they want which may work fine for
> qcom specific drivers but it will not work for a generic IP driver
> used by many vendors. Not sure if Qcom SoCs are just bundle of Qcom
> specific IPs or they do have some generic non-Qcom IPs. Lets us take
> SMMU as example. If the SCMI/RPMI controls the power to it, would you
> go and add this new compatible in the generic SMMU bindings and add
> support in the driver for that ? That is big NO as the driver would
> just need to use std framework interface(doesn't matter Runtime PM/Clock/
> Reset/genpd/PM OPP). That means they don't need any specific bindings
> to inform SMMU driver that the power is f/w managed.
For SMMU, we dont need to make any changes in the existing driver. 
Simple power-domain over SCMI will suffice since we don't need to do 
clock scaling etc. for SMMU. We will use this new property in Qualcomm 
emac, UFS, USB, QUPs(i2c,spi,uart) drivers.
>
> Hope I have conveyed my point better with example this time.
>
> --
> Regards,
> Sudeep

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

[Sudeep Holla]

On Thu, Mar 14, 2024 at 05:35:23AM -0700, Nikunj Kela wrote:
> 
> On 3/14/2024 3:55 AM, Sudeep Holla wrote:
> > > 
> > Nope, the point was will the presence of (available) scmi/rpmi device
> > node suffice if we are thinking of single board level property or
> > compatible. I was not mixing the discussion of whether adding such
> > a property to each needed device node in this discussion to keep it
> > simple. I have already expressed my opinion on that.
> > 
> > I am sure qcom will go and do what they want which may work fine for
> > qcom specific drivers but it will not work for a generic IP driver
> > used by many vendors. Not sure if Qcom SoCs are just bundle of Qcom
> > specific IPs or they do have some generic non-Qcom IPs. Lets us take
> > SMMU as example. If the SCMI/RPMI controls the power to it, would you
> > go and add this new compatible in the generic SMMU bindings and add
> > support in the driver for that ? That is big NO as the driver would
> > just need to use std framework interface(doesn't matter Runtime PM/Clock/
> > Reset/genpd/PM OPP). That means they don't need any specific bindings
> > to inform SMMU driver that the power is f/w managed.
>
> For SMMU, we dont need to make any changes in the existing driver. Simple
> power-domain over SCMI will suffice since we don't need to do clock scaling
> etc. for SMMU. We will use this new property in Qualcomm emac, UFS, USB,
> QUPs(i2c,spi,uart) drivers.

Sure, as I mentioned in the beginning itself, it is all in the Qcom
specific drivers, well you can hack it in any ugly way you want to get
things working even in the upstream.

But just stop and think for a moment how would you solve this problem
if you had few Synopsys Designware IPs instead of all those Qcom specific
IPs. Will your suggested solution work or if it works will that even scale ?

As I said I will shut up and you can do whatever in your drivers, but I
just don't want this to set bad example for other vendors who may not have
all their own IPs and may use some generic ones which means they will now
follow your solution and go and change those drivers now.

The main point I am trying to make is the provide blocks/nodes should
have the information that it is firmware managed. The consumer nodes
have no business to know that information.

I will leave it to you now as I can't stop what you define as Qcom specific
and what changes you can make in those Qcom specific drivers.

--
Regards,
Sudeep

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

[Trilok Soni]

On 3/14/2024 11:38 AM, Sudeep Holla wrote:
> On Thu, Mar 14, 2024 at 05:35:23AM -0700, Nikunj Kela wrote:
>>
>> On 3/14/2024 3:55 AM, Sudeep Holla wrote:
>>>>
>>> Nope, the point was will the presence of (available) scmi/rpmi device
>>> node suffice if we are thinking of single board level property or
>>> compatible. I was not mixing the discussion of whether adding such
>>> a property to each needed device node in this discussion to keep it
>>> simple. I have already expressed my opinion on that.
>>>
>>> I am sure qcom will go and do what they want which may work fine for
>>> qcom specific drivers but it will not work for a generic IP driver
>>> used by many vendors. Not sure if Qcom SoCs are just bundle of Qcom
>>> specific IPs or they do have some generic non-Qcom IPs. Lets us take
>>> SMMU as example. If the SCMI/RPMI controls the power to it, would you
>>> go and add this new compatible in the generic SMMU bindings and add
>>> support in the driver for that ? That is big NO as the driver would
>>> just need to use std framework interface(doesn't matter Runtime PM/Clock/
>>> Reset/genpd/PM OPP). That means they don't need any specific bindings
>>> to inform SMMU driver that the power is f/w managed.
>>
>> For SMMU, we dont need to make any changes in the existing driver. Simple
>> power-domain over SCMI will suffice since we don't need to do clock scaling
>> etc. for SMMU. We will use this new property in Qualcomm emac, UFS, USB,
>> QUPs(i2c,spi,uart) drivers.
> 
> Sure, as I mentioned in the beginning itself, it is all in the Qcom
> specific drivers, well you can hack it in any ugly way you want to get
> things working even in the upstream.
> 
> But just stop and think for a moment how would you solve this problem
> if you had few Synopsys Designware IPs instead of all those Qcom specific
> IPs. Will your suggested solution work or if it works will that even scale ?
> 
> As I said I will shut up and you can do whatever in your drivers, but I
> just don't want this to set bad example for other vendors who may not have
> all their own IPs and may use some generic ones which means they will now
> follow your solution and go and change those drivers now.
> 
> The main point I am trying to make is the provide blocks/nodes should
> have the information that it is firmware managed. The consumer nodes
> have no business to know that information.
> 
> I will leave it to you now as I can't stop what you define as Qcom specific
> and what changes you can make in those Qcom specific drivers.

I agree with what Sudeep has brought up for the SMMU and USB is another example
where we can have 3rd party phy / Synopsys IPs on the QC devices.

From the QCOM side my concern is that I don't want to have QC specific hacks,
because today's on-SOC IP can be tomorrow's discrete IP attached over
PCIe or USB. Think of NPU or Video IP attached to third party
Application processor (though it may not exist today but we never know).


-- 
---Trilok Soni

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

[Srinivas Kandagatla]

On 16/03/2024 19:30, Trilok Soni wrote:
> On 3/14/2024 11:38 AM, Sudeep Holla wrote:
>> On Thu, Mar 14, 2024 at 05:35:23AM -0700, Nikunj Kela wrote:
>>>
>>> On 3/14/2024 3:55 AM, Sudeep Holla wrote:
>>>>>
>>>> Nope, the point was will the presence of (available) scmi/rpmi device
>>>> node suffice if we are thinking of single board level property or
>>>> compatible. I was not mixing the discussion of whether adding such
>>>> a property to each needed device node in this discussion to keep it
>>>> simple. I have already expressed my opinion on that.
>>>>
>>>> I am sure qcom will go and do what they want which may work fine for
>>>> qcom specific drivers but it will not work for a generic IP driver
>>>> used by many vendors. Not sure if Qcom SoCs are just bundle of Qcom
>>>> specific IPs or they do have some generic non-Qcom IPs. Lets us take
>>>> SMMU as example. If the SCMI/RPMI controls the power to it, would you
>>>> go and add this new compatible in the generic SMMU bindings and add
>>>> support in the driver for that ? That is big NO as the driver would
>>>> just need to use std framework interface(doesn't matter Runtime PM/Clock/
>>>> Reset/genpd/PM OPP). That means they don't need any specific bindings
>>>> to inform SMMU driver that the power is f/w managed.
>>>
>>> For SMMU, we dont need to make any changes in the existing driver. Simple
>>> power-domain over SCMI will suffice since we don't need to do clock scaling
>>> etc. for SMMU. We will use this new property in Qualcomm emac, UFS, USB,
>>> QUPs(i2c,spi,uart) drivers.
>>
>> Sure, as I mentioned in the beginning itself, it is all in the Qcom
>> specific drivers, well you can hack it in any ugly way you want to get
>> things working even in the upstream.
>>
>> But just stop and think for a moment how would you solve this problem
>> if you had few Synopsys Designware IPs instead of all those Qcom specific
>> IPs. Will your suggested solution work or if it works will that even scale ?
>>
>> As I said I will shut up and you can do whatever in your drivers, but I
>> just don't want this to set bad example for other vendors who may not have
>> all their own IPs and may use some generic ones which means they will now
>> follow your solution and go and change those drivers now.
>>
>> The main point I am trying to make is the provide blocks/nodes should
>> have the information that it is firmware managed. The consumer nodes
>> have no business to know that information.
>>
>> I will leave it to you now as I can't stop what you define as Qcom specific
>> and what changes you can make in those Qcom specific drivers.
> 
> I agree with what Sudeep has brought up for the SMMU and USB is another example
> where we can have 3rd party phy / Synopsys IPs on the QC devices.

This needs more discussion before we even consider adding scmi perf to 
these drivers.

Big question here is implementation details of the Device SCMI perf

With new SCMI Perf changes all the driver resources handling are moved 
to perf or power domains.

But is this abstraction correct?

Any standards followed Or Is any of this documented?

AFAIU, The whole resources moving to SCMI perf are done in pretty adhoc 
way.(ex: making regulators as power domains, and clks as perf domains.. 
and in some cases clks are power domains, ...)

How can we make sure that other vendors also abstract device resources 
exactly like what Qualcomm SCMI Server?

What I feel so far is that all of the resources are moved to scmi perf 
in a very Qualcomm implementation way.

I have no objections to having a generic property or way to determine 
this more generically. As long as this is explicitly documented as part 
of Device tree binding for all the devices and done correctly.

thanks,
Srini

> 
>  From the QCOM side my concern is that I don't want to have QC specific hacks,
> because today's on-SOC IP can be tomorrow's discrete IP attached over
> PCIe or USB. Think of NPU or Video IP attached to third party
> Application processor (though it may not exist today but we never know).
> 
> 

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

[Sudeep Holla]

On Tue, Mar 19, 2024 at 10:17:32AM +0000, Srinivas Kandagatla wrote:
>
> On 16/03/2024 19:30, Trilok Soni wrote:
> > On 3/14/2024 11:38 AM, Sudeep Holla wrote:
> > > On Thu, Mar 14, 2024 at 05:35:23AM -0700, Nikunj Kela wrote:
> > > >
> > > > On 3/14/2024 3:55 AM, Sudeep Holla wrote:
> > > > > >
> > > > > Nope, the point was will the presence of (available) scmi/rpmi device
> > > > > node suffice if we are thinking of single board level property or
> > > > > compatible. I was not mixing the discussion of whether adding such
> > > > > a property to each needed device node in this discussion to keep it
> > > > > simple. I have already expressed my opinion on that.
> > > > >
> > > > > I am sure qcom will go and do what they want which may work fine for
> > > > > qcom specific drivers but it will not work for a generic IP driver
> > > > > used by many vendors. Not sure if Qcom SoCs are just bundle of Qcom
> > > > > specific IPs or they do have some generic non-Qcom IPs. Lets us take
> > > > > SMMU as example. If the SCMI/RPMI controls the power to it, would you
> > > > > go and add this new compatible in the generic SMMU bindings and add
> > > > > support in the driver for that ? That is big NO as the driver would
> > > > > just need to use std framework interface(doesn't matter Runtime PM/Clock/
> > > > > Reset/genpd/PM OPP). That means they don't need any specific bindings
> > > > > to inform SMMU driver that the power is f/w managed.
> > > >
> > > > For SMMU, we dont need to make any changes in the existing driver. Simple
> > > > power-domain over SCMI will suffice since we don't need to do clock scaling
> > > > etc. for SMMU. We will use this new property in Qualcomm emac, UFS, USB,
> > > > QUPs(i2c,spi,uart) drivers.
> > >
> > > Sure, as I mentioned in the beginning itself, it is all in the Qcom
> > > specific drivers, well you can hack it in any ugly way you want to get
> > > things working even in the upstream.
> > >
> > > But just stop and think for a moment how would you solve this problem
> > > if you had few Synopsys Designware IPs instead of all those Qcom specific
> > > IPs. Will your suggested solution work or if it works will that even scale ?
> > >
> > > As I said I will shut up and you can do whatever in your drivers, but I
> > > just don't want this to set bad example for other vendors who may not have
> > > all their own IPs and may use some generic ones which means they will now
> > > follow your solution and go and change those drivers now.
> > >
> > > The main point I am trying to make is the provide blocks/nodes should
> > > have the information that it is firmware managed. The consumer nodes
> > > have no business to know that information.
> > >
> > > I will leave it to you now as I can't stop what you define as Qcom specific
> > > and what changes you can make in those Qcom specific drivers.
> >
> > I agree with what Sudeep has brought up for the SMMU and USB is another example
> > where we can have 3rd party phy / Synopsys IPs on the QC devices.
>
> This needs more discussion before we even consider adding scmi perf to these
> drivers.

Agreed.


> Big question here is implementation details of the Device SCMI perf
>
> With new SCMI Perf changes all the driver resources handling are moved to
> perf or power domains.
>

Correct and matches my understanding.

> But is this abstraction correct?
>

Don't know, patches were on the list. But I agree only interested parties
reviewed it back then and now more are interested in it and their views
may differ. Open to hear them all.

> Any standards followed Or Is any of this documented?
>

Not sure what you are looking for as answer here TBH.

> AFAIU, The whole resources moving to SCMI perf are done in pretty adhoc
> way.(ex: making regulators as power domains, and clks as perf domains.. and
> in some cases clks are power domains, ...)
>

Hmm, do we have examples for there ? Because I am interested to know more.
1. Regulators as power domains
	IMO this may have happened before the dedicated regulator protocol
	was added to the SCMI specification.
2. Clocks as perf domains
	Not sure if this ever happened, though I admit clocks property
	were used to refer SCMI perf domains in the DT but they(perf/OPP
	domains) were never integrated into clock framework.
3. Clocks as power domains
	Again this hasn't happened in DT or Linux SCMI implementation
	side. I can't speak about firmware implementation side but
	not conforming to the spec may make it hard to work well with
	generic drivers. Conformance tests must catch them ideally but
	writing the conformance tests and running them on the real
	hardware are 2 things that probably not happening at all(not
	even to some extent).

> How can we make sure that other vendors also abstract device resources
> exactly like what Qualcomm SCMI Server?
>

We can't. That is the advantage of platform specific firmware
implementation. But that said, the firmware should be conformant to the
specification. They can't go wild and implement things in a way that
makes it incompatible or non-conformant to the specification. In which
case the standard upstream SCMI drivers can't simply support that platform.

> What I feel so far is that all of the resources are moved to scmi perf in a
> very Qualcomm implementation way.
>

It depends on what exactly this "very Qualcomm implementation way" mean
when we break down to individual details. Sorry there is no other way
to answer or address this. Anything you see as Qcom specific can be
either put into conformant or non-conformant bucket with respect to the
SCMI specification.

> I have no objections to having a generic property or way to determine this
> more generically. As long as this is explicitly documented as part of Device
> tree binding for all the devices and done correctly.
>

OTH, my argument so far is that the presence of SCMI node indicates some
or more SCMI features are available on this platform. The SCMI node itself
then will have the resource provider nodes(like clock, power, perf, reset,
regulator,...etc). If the individual device nodes are consumers of those
resources, they will be pointing to those instead of non-SCMI clock, reset,
...etc resource providers. So ideally we don't need anything more in the
DT.

--
Regards,
Sudeep

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

[Srinivas Kandagatla]

On 19/03/2024 12:00, Sudeep Holla wrote:
> On Tue, Mar 19, 2024 at 10:17:32AM +0000, Srinivas Kandagatla wrote:
>>
>> On 16/03/2024 19:30, Trilok Soni wrote:
>>> On 3/14/2024 11:38 AM, Sudeep Holla wrote:
>>>> On Thu, Mar 14, 2024 at 05:35:23AM -0700, Nikunj Kela wrote:
>>>>>
>>>>> On 3/14/2024 3:55 AM, Sudeep Holla wrote:
>>>>>>>
>>>>>> Nope, the point was will the presence of (available) scmi/rpmi device
>>>>>> node suffice if we are thinking of single board level property or
>>>>>> compatible. I was not mixing the discussion of whether adding such
>>>>>> a property to each needed device node in this discussion to keep it
>>>>>> simple. I have already expressed my opinion on that.
>>>>>>
>>>>>> I am sure qcom will go and do what they want which may work fine for
>>>>>> qcom specific drivers but it will not work for a generic IP driver
>>>>>> used by many vendors. Not sure if Qcom SoCs are just bundle of Qcom
>>>>>> specific IPs or they do have some generic non-Qcom IPs. Lets us take
>>>>>> SMMU as example. If the SCMI/RPMI controls the power to it, would you
>>>>>> go and add this new compatible in the generic SMMU bindings and add
>>>>>> support in the driver for that ? That is big NO as the driver would
>>>>>> just need to use std framework interface(doesn't matter Runtime PM/Clock/
>>>>>> Reset/genpd/PM OPP). That means they don't need any specific bindings
>>>>>> to inform SMMU driver that the power is f/w managed.
>>>>>
>>>>> For SMMU, we dont need to make any changes in the existing driver. Simple
>>>>> power-domain over SCMI will suffice since we don't need to do clock scaling
>>>>> etc. for SMMU. We will use this new property in Qualcomm emac, UFS, USB,
>>>>> QUPs(i2c,spi,uart) drivers.
>>>>
>>>> Sure, as I mentioned in the beginning itself, it is all in the Qcom
>>>> specific drivers, well you can hack it in any ugly way you want to get
>>>> things working even in the upstream.
>>>>
>>>> But just stop and think for a moment how would you solve this problem
>>>> if you had few Synopsys Designware IPs instead of all those Qcom specific
>>>> IPs. Will your suggested solution work or if it works will that even scale ?
>>>>
>>>> As I said I will shut up and you can do whatever in your drivers, but I
>>>> just don't want this to set bad example for other vendors who may not have
>>>> all their own IPs and may use some generic ones which means they will now
>>>> follow your solution and go and change those drivers now.
>>>>
>>>> The main point I am trying to make is the provide blocks/nodes should
>>>> have the information that it is firmware managed. The consumer nodes
>>>> have no business to know that information.
>>>>
>>>> I will leave it to you now as I can't stop what you define as Qcom specific
>>>> and what changes you can make in those Qcom specific drivers.
>>>
>>> I agree with what Sudeep has brought up for the SMMU and USB is another example
>>> where we can have 3rd party phy / Synopsys IPs on the QC devices.
>>
>> This needs more discussion before we even consider adding scmi perf to these
>> drivers.
> 
> Agreed.
> 
> 
>> Big question here is implementation details of the Device SCMI perf
>>
>> With new SCMI Perf changes all the driver resources handling are moved to
>> perf or power domains.
>>
> 
> Correct and matches my understanding.
> 
>> But is this abstraction correct?
>>
> 
> Don't know, patches were on the list. But I agree only interested parties
> reviewed it back then and now more are interested in it and their views
> may differ. Open to hear them all.
> 
>> Any standards followed Or Is any of this documented?
>>
> 
> Not sure what you are looking for as answer here TBH.
> 
>> AFAIU, The whole resources moving to SCMI perf are done in pretty adhoc
>> way.(ex: making regulators as power domains, and clks as perf domains.. and
>> in some cases clks are power domains, ...)
>>
> 
> Hmm, do we have examples for there ? Because I am interested to know more.

here is a patch series that does conversion.

https://lore.kernel.org/lkml/1a47c20a-abda-4493-a8f0-ff7b4e144d9c@quicinc.com/T/

> 1. Regulators as power domains
> 	IMO this may have happened before the dedicated regulator protocol
> 	was added to the SCMI specification.
> 2. Clocks as perf domains
> 	Not sure if this ever happened, though I admit clocks property
> 	were used to refer SCMI perf domains in the DT but they(perf/OPP
> 	domains) were never integrated into clock framework.
> 3. Clocks as power domains
> 	Again this hasn't happened in DT or Linux SCMI implementation
> 	side. I can't speak about firmware implementation side but
> 	not conforming to the spec may make it hard to work well with
> 	generic drivers. Conformance tests must catch them ideally but
> 	writing the conformance tests and running them on the real
> 	hardware are 2 things that probably not happening at all(not
> 	even to some extent).
> 
>> How can we make sure that other vendors also abstract device resources
>> exactly like what Qualcomm SCMI Server?
>>
> 
> We can't. That is the advantage of platform specific firmware
> implementation. But that said, the firmware should be conformant to the
> specification. They can't go wild and implement things in a way that
> makes it incompatible or non-conformant to the specification. In which
> case the standard upstream SCMI drivers can't simply support that platform.
> 
>> What I feel so far is that all of the resources are moved to scmi perf in a
>> very Qualcomm implementation way.
>>
> 
> It depends on what exactly this "very Qualcomm implementation way" mean
> when we break down to individual details. Sorry there is no other way
> to answer or address this. Anything you see as Qcom specific can be
> either put into conformant or non-conformant bucket with respect to the
> SCMI specification.
> 
>> I have no objections to having a generic property or way to determine this
>> more generically. As long as this is explicitly documented as part of Device
>> tree binding for all the devices and done correctly.
>>
> 
> OTH, my argument so far is that the presence of SCMI node indicates some
> or more SCMI features are available on this platform. The SCMI node itself
> then will have the resource provider nodes(like clock, power, perf, reset,
> regulator,...etc). If the individual device nodes are consumers of those
> resources, they will be pointing to those instead of non-SCMI clock, reset,
> ...etc resource providers. So ideally we don't need anything more in the
> DT.

The situation that you described is perfect case of SCMI.

With SCMI perf device support case,  combination of these clks, 
regulators and reset are moved under the perf domain. Its no more the 
same type of resource provider. So the DT bindings will change drastically.

so the existing driver that was expecting clk/regulators/resets now has 
to deal with perf domain.

--srini



> 
> --
> Regards,
> Sudeep

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

[Sudeep Holla]

On Tue, Mar 19, 2024 at 02:40:32PM +0000, Srinivas Kandagatla wrote:
> 
> On 19/03/2024 12:00, Sudeep Holla wrote:
> >
> > OTH, my argument so far is that the presence of SCMI node indicates some
> > or more SCMI features are available on this platform. The SCMI node itself
> > then will have the resource provider nodes(like clock, power, perf, reset,
> > regulator,...etc). If the individual device nodes are consumers of those
> > resources, they will be pointing to those instead of non-SCMI clock, reset,
> > ...etc resource providers. So ideally we don't need anything more in the
> > DT.
> 
> The situation that you described is perfect case of SCMI.
> 
> With SCMI perf device support case,  combination of these clks, regulators
> and reset are moved under the perf domain. Its no more the same type of
> resource provider. So the DT bindings will change drastically.
>

Not sure what you refer as "drastic". Ulf added binding to represent
both power and performance domains extending the current binding used
for power domains and used by genpd framework.

The whole idea with abstraction i.e. clks, regulators, reset all moved
into the firmware under one perf domains means you need less information
in the device tree. So this whole discussion about adding more info to
deal with it sounds moot to me and hence all my arguments.

I am not debating on the implementation just to be clear. I accept changes
might be needed there. The $subject is all about DT bindings and what need
to be changes and for me nothing, just use existing bindings and if there
are issues there, let us discuss it with specifics.

> so the existing driver that was expecting clk/regulators/resets now has to
> deal with perf domain.
>

Agreed.

--
Regards,
Sudeep

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

[Srinivas Kandagatla]

On 19/03/2024 15:17, Sudeep Holla wrote:
> I am not debating on the implementation just to be clear. I accept changes
> might be needed there. The $subject is all about DT bindings and what need
> to be changes and for me nothing, just use existing bindings and if there
> are issues there, let us discuss it with specifics.
> 
How can changes to dt bindings be nothing? All the resources 
clk/regulators/resets will become optional and a new power or perf 
domain will become required for each device with firmwares that support 
SCMI Perf.


--srini
>> so the existing driver that was expecting clk/regulators/resets now has to
>> deal with perf domain.

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

[Sudeep Holla]

On Tue, Mar 19, 2024 at 03:41:40PM +0000, Srinivas Kandagatla wrote:
> 
> On 19/03/2024 15:17, Sudeep Holla wrote:
> > I am not debating on the implementation just to be clear. I accept changes
> > might be needed there. The $subject is all about DT bindings and what need
> > to be changes and for me nothing, just use existing bindings and if there
> > are issues there, let us discuss it with specifics.
> > 
> How can changes to dt bindings be nothing? All the resources
> clk/regulators/resets will become optional and a new power or perf domain
> will become required for each device with firmwares that support SCMI Perf.
>

Correct, sorry to miss the point that few properties are now optional from
mandatory before. Very good point. I was so caught up with the addition of
the new "firmware controlled blah blah" property/compatible that I missed
to observe mandatory->optional as a change. Thanks for correcting me.

--
Regards,
Sudeep

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

[Nikunj Kela]

On 3/13/2024 3:40 PM, Trilok Soni wrote:
> On 3/13/2024 4:49 AM, Srinivas Kandagatla wrote:
>> On 12/03/2024 17:25, Trilok Soni wrote:
>>> On 3/12/2024 10:21 AM, Srinivas Kandagatla wrote:
>>>>> Basically, I would prefer better than "qcom, fw-managed" since this is not
>>>>> a qcom specific problem.
>>>>
>>>> We already have something like this in mainline where the BAM DMA controller is remotely powered.
>>>>
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml?h=v6.8
>>>>
>>> As you can see it is already fragmented. Why we need to create one more approach
>>> which is not scalable and specific to SOC vendor?
>> The whole issue around this new checks is that the driver/binding is not designed to expect same set of resources from different TYPES of providers.
>> If the driver was designed to support opp's and power domains and make the resources handle in a unified way then some/all of these changes will naturally fit in.
>>
>>
>>> SCMI or RPMI based firmware is not a QC specific. I also have allergic reaction
>> I agree this are not QC specific, am fine with generic dt-binding like firmware-managed-resources or something on those lines if DT-maintainers are happy with.
>>
>> What is your suggestion?
> Yes, DT-spec will be a good start.
>
>>
>>> when I see drivers modified w/ if (fw_managed) {..} but that is a discussion
>> I don't think we have a choice here, either we do this check at compatible level or dt-property level or resource level in every drivers.
> I don't understand yet why we don't have any other choices but do the conditional checks? Maybe explaining
> with the example will help? Start w/ clocks?

We are not using SCMI in traditional way in that, we are not dealing 
with individual resources(clocks, regulators, phy, gpio, interconnect 
etc.). We are defining logical/modelled domains(power and performance). 
We need to think in terms of device states. For example, emac device 
might have two states like this:

Clock C1 running at frequency F1 + Regulators R running at voltage V1 + 
Interconnect I running at B1 bandwidth --> Lets call it a level-1 (for 
the performance domain)

Clock C1 running at frquuency F2 + Regulators R running at voltage V1 + 
Interconnect I running at B1 bandwidth --> Lets call it a level-2

Now if the emac driver needs to set the device performance state to 
Level-1, it will call the OPP APIs to set the device performance state 
to Level-1.

Similarly, emac may also define power domains like this:

Power_on --> enable ‘n’ clocks + enable ‘m’ regulators + set ICB 
bandwidth to default ‘b’ + setting some GPIO pin + Enabling n` phy 
clocks + enabling m` phy regulators + follow phy_init sequence and 
caliberation

Power_off --> does just the opposite.

So now you can see dealing with individual clocks etc. would not be 
always possible in our scenario. Therefore, we need to use ‘qcom, 
firmware-managed-resources’ property to figure out if we are abstracting 
resources or not.
>

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

[Nikunj Kela]

On 3/19/2024 9:13 AM, Sudeep Holla wrote:
> On Tue, Mar 19, 2024 at 03:41:40PM +0000, Srinivas Kandagatla wrote:
>> On 19/03/2024 15:17, Sudeep Holla wrote:
>>> I am not debating on the implementation just to be clear. I accept changes
>>> might be needed there. The $subject is all about DT bindings and what need
>>> to be changes and for me nothing, just use existing bindings and if there
>>> are issues there, let us discuss it with specifics.
>>>
>> How can changes to dt bindings be nothing? All the resources
>> clk/regulators/resets will become optional and a new power or perf domain
>> will become required for each device with firmwares that support SCMI Perf.
>>
> Correct, sorry to miss the point that few properties are now optional from
> mandatory before. Very good point. I was so caught up with the addition of
> the new "firmware controlled blah blah" property/compatible that I missed
> to observe mandatory->optional as a change. Thanks for correcting me.
>
> --
> Regards,
> Sudeep
If there are no more questions on this and everyone is on the same page, 
I would like to conclude this thread in favor of using a new DT property 
'qcom,firmware-managed-resources'.

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

[Krzysztof Kozlowski]

On 10/04/2024 18:55, Nikunj Kela wrote:
> If there are no more questions on this and everyone is on the same page, 
> I would like to conclude this thread in favor of using a new DT property 
> 'qcom,firmware-managed-resources'.

Just to recap my earlier statement, because I am not sure if I got the
answer (if answer was provided, then I don't forgot... sorry):

This is a new hardware, so you have a new compatible, therefore any
additional property is not needed.

In other cases, just use existing properties, don't bring a third one. :/

Best regards,
Krzysztof

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

[Nikunj Kela]

On 4/10/2024 10:13 AM, Krzysztof Kozlowski wrote:
> On 10/04/2024 18:55, Nikunj Kela wrote:
>> If there are no more questions on this and everyone is on the same page,
>> I would like to conclude this thread in favor of using a new DT property
>> 'qcom,firmware-managed-resources'.
> Just to recap my earlier statement, because I am not sure if I got the
> answer (if answer was provided, then I don't forgot... sorry):
>
> This is a new hardware, so you have a new compatible, therefore any
> additional property is not needed.
This is not a new HW, this is the same HW with different FW and 
interface to FW is different too. As you can see earlier discussion on 
this thread, new compatible was ruled out since it is the same HW IP.
>
> In other cases, just use existing properties, don't bring a third one. :/
Not sure which existing property you are referring to. There is no 
property to the best of my knowledge to deal with our scenario. Are you 
suggesting we reuse "qcom,controlled-remotely" property that is used in 
Qualcomm BAM DMA Controller for our case too?
>
> Best regards,
> Krzysztof
>

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

[Sudeep Holla]

On Wed, Apr 10, 2024 at 09:55:24AM -0700, Nikunj Kela wrote:
> 
> On 3/19/2024 9:13 AM, Sudeep Holla wrote:
> > On Tue, Mar 19, 2024 at 03:41:40PM +0000, Srinivas Kandagatla wrote:
> > > On 19/03/2024 15:17, Sudeep Holla wrote:
> > > > I am not debating on the implementation just to be clear. I accept changes
> > > > might be needed there. The $subject is all about DT bindings and what need
> > > > to be changes and for me nothing, just use existing bindings and if there
> > > > are issues there, let us discuss it with specifics.
> > > > 
> > > How can changes to dt bindings be nothing? All the resources
> > > clk/regulators/resets will become optional and a new power or perf domain
> > > will become required for each device with firmwares that support SCMI Perf.
> > > 
> > Correct, sorry to miss the point that few properties are now optional from
> > mandatory before. Very good point. I was so caught up with the addition of
> > the new "firmware controlled blah blah" property/compatible that I missed
> > to observe mandatory->optional as a change. Thanks for correcting me.
> > 
> If there are no more questions on this and everyone is on the same page, I
> would like to conclude this thread in favor of using a new DT property
> 'qcom,firmware-managed-resources'.
>

This is exactly opposite to what I have advocated so far in this thread.
Not sure how you drew to this conclusion. Check [1] and [2] for example.
The point was not to have qcom specific compatibles or properties as it
doesn't scale well. Please chime into those if you have argument and how
you came to this conclusion.

--
Regards,
Sudeep

[1] https://lore.kernel.org/all/ZfMZ9ATxuvONcGpz@bogus
[2] https://lore.kernel.org/all/0411f99d-231a-af4b-d681-7f7748361aa3@quicinc.com

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

[Sudeep Holla]

On Wed, Apr 10, 2024 at 09:53:36AM -0700, Nikunj Kela wrote:

[...]

> So now you can see dealing with individual clocks etc. would not be always
> possible in our scenario. Therefore, we need to use ‘qcom,
> firmware-managed-resources’ property to figure out if we are abstracting
> resources or not.
> > 

No

-- 
Regards,
Sudeep

P.S.: skipping all the details as it's already in the thread

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

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 904 bytes --]

On Wed, Apr 10, 2024 at 10:24:02AM -0700, Nikunj Kela wrote:
> 
> On 4/10/2024 10:13 AM, Krzysztof Kozlowski wrote:
> > On 10/04/2024 18:55, Nikunj Kela wrote:
> > > If there are no more questions on this and everyone is on the same page,
> > > I would like to conclude this thread in favor of using a new DT property
> > > 'qcom,firmware-managed-resources'.
> > Just to recap my earlier statement, because I am not sure if I got the
> > answer (if answer was provided, then I don't forgot... sorry):
> > 
> > This is a new hardware, so you have a new compatible, therefore any
> > additional property is not needed.
> This is not a new HW, this is the same HW with different FW and interface to
> FW is different too. As you can see earlier discussion on this thread, new
> compatible was ruled out since it is the same HW IP.

Can you link me to the post that ruled it out please?



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Nikunj Kela]

On 4/11/2024 8:44 AM, Conor Dooley wrote:
> On Wed, Apr 10, 2024 at 10:24:02AM -0700, Nikunj Kela wrote:
>> On 4/10/2024 10:13 AM, Krzysztof Kozlowski wrote:
>>> On 10/04/2024 18:55, Nikunj Kela wrote:
>>>> If there are no more questions on this and everyone is on the same page,
>>>> I would like to conclude this thread in favor of using a new DT property
>>>> 'qcom,firmware-managed-resources'.
>>> Just to recap my earlier statement, because I am not sure if I got the
>>> answer (if answer was provided, then I don't forgot... sorry):
>>>
>>> This is a new hardware, so you have a new compatible, therefore any
>>> additional property is not needed.
>> This is not a new HW, this is the same HW with different FW and interface to
>> FW is different too. As you can see earlier discussion on this thread, new
>> compatible was ruled out since it is the same HW IP.
> Can you link me to the post that ruled it out please?

Hi, There was difference of opinion. While Ulf was in favor of new 
compatible however Srini was against it since it is the same HW IP. 
Please check the link [1] in the same thread and subsequent discussion 
on the same.  To resolve this difference, Qualcomm and Linaro had a 
discussion and it was decided to go with vendor specific DT property.

[1]: 
https://lore.kernel.org/all/CAPDyKFrL2QcB-YbE25smGgJjf3iBEsSSB4ui3V98zJKghNNhKA@mail.gmail.com/

>
>

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

[Nikunj Kela]

On 4/11/2024 2:23 AM, Sudeep Holla wrote:
> On Wed, Apr 10, 2024 at 09:55:24AM -0700, Nikunj Kela wrote:
>> On 3/19/2024 9:13 AM, Sudeep Holla wrote:
>>> On Tue, Mar 19, 2024 at 03:41:40PM +0000, Srinivas Kandagatla wrote:
>>>> On 19/03/2024 15:17, Sudeep Holla wrote:
>>>>> I am not debating on the implementation just to be clear. I accept changes
>>>>> might be needed there. The $subject is all about DT bindings and what need
>>>>> to be changes and for me nothing, just use existing bindings and if there
>>>>> are issues there, let us discuss it with specifics.
>>>>>
>>>> How can changes to dt bindings be nothing? All the resources
>>>> clk/regulators/resets will become optional and a new power or perf domain
>>>> will become required for each device with firmwares that support SCMI Perf.
>>>>
>>> Correct, sorry to miss the point that few properties are now optional from
>>> mandatory before. Very good point. I was so caught up with the addition of
>>> the new "firmware controlled blah blah" property/compatible that I missed
>>> to observe mandatory->optional as a change. Thanks for correcting me.
>>>
>> If there are no more questions on this and everyone is on the same page, I
>> would like to conclude this thread in favor of using a new DT property
>> 'qcom,firmware-managed-resources'.
>>
> This is exactly opposite to what I have advocated so far in this thread.
> Not sure how you drew to this conclusion. Check [1] and [2] for example.
> The point was not to have qcom specific compatibles or properties as it
> doesn't scale well. Please chime into those if you have argument and how
> you came to this conclusion.
>
> --
> Regards,
> Sudeep
>
> [1] https://lore.kernel.org/all/ZfMZ9ATxuvONcGpz@bogus
> [2] https://lore.kernel.org/all/0411f99d-231a-af4b-d681-7f7748361aa3@quicinc.com
Hi Sudeep, we had a discussion with Linaro team on this and people 
suggested that this should be a vendor specific property since different 
vendors might abstract differently. Moreover, our changes are only in 
Qualcomm drivers so it made sense to use vendor specific property. That 
being said, if you are suggesting that we remove Qcom from it, I can 
again discuss this. I will let Srini and other pitch in here if they 
want to add more to it.

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

[Krzysztof Kozlowski]

On 11/04/2024 17:55, Nikunj Kela wrote:
> 
> On 4/11/2024 8:44 AM, Conor Dooley wrote:
>> On Wed, Apr 10, 2024 at 10:24:02AM -0700, Nikunj Kela wrote:
>>> On 4/10/2024 10:13 AM, Krzysztof Kozlowski wrote:
>>>> On 10/04/2024 18:55, Nikunj Kela wrote:
>>>>> If there are no more questions on this and everyone is on the same page,
>>>>> I would like to conclude this thread in favor of using a new DT property
>>>>> 'qcom,firmware-managed-resources'.
>>>> Just to recap my earlier statement, because I am not sure if I got the
>>>> answer (if answer was provided, then I don't forgot... sorry):
>>>>
>>>> This is a new hardware, so you have a new compatible, therefore any
>>>> additional property is not needed.
>>> This is not a new HW, this is the same HW with different FW and interface to
>>> FW is different too. As you can see earlier discussion on this thread, new
>>> compatible was ruled out since it is the same HW IP.
>> Can you link me to the post that ruled it out please?
> 
> Hi, There was difference of opinion. While Ulf was in favor of new 
> compatible however Srini was against it since it is the same HW IP. 
> Please check the link [1] in the same thread and subsequent discussion 
> on the same.  To resolve this difference, Qualcomm and Linaro had a 
> discussion and it was decided to go with vendor specific DT property.
> 
> [1]: 
> https://lore.kernel.org/all/CAPDyKFrL2QcB-YbE25smGgJjf3iBEsSSB4ui3V98zJKghNNhKA@mail.gmail.com/

Just to clarify: Ulf agreed on compatible way for proof of concept and
asked to send a code so everyone can understand better what you are
making. I don't recall any Linaro policy or answer.

After above email, other people proposed other solutions and disagreed
with that statement, so no, you do not have a consensus.

Trying to present this as a consensus if way exaggerated.

You have no conclusion, because talk is cheap and this thread is way too
big. It's also way to vague, like we had to poke you for several emails
to get hardware description. I still don't recall it, but TBH, I am not
going to look at 50 email thread for one email.

Therefore, feel free to propose something, but if you call it "that was
the consensus from community" then please already add there my
Nacked-by, because there was no consensus.

In your proposal finally describe your hardware, firmware and problem
which you are solving (because no one will be going back to this thread).

Best regards,
Krzysztof

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

[Sudeep Holla]

On Thu, Apr 11, 2024 at 08:59:53AM -0700, Nikunj Kela wrote:
> 
> On 4/11/2024 2:23 AM, Sudeep Holla wrote:
> > On Wed, Apr 10, 2024 at 09:55:24AM -0700, Nikunj Kela wrote:
> > > On 3/19/2024 9:13 AM, Sudeep Holla wrote:
> > > > On Tue, Mar 19, 2024 at 03:41:40PM +0000, Srinivas Kandagatla wrote:
> > > > > On 19/03/2024 15:17, Sudeep Holla wrote:
> > > > > > I am not debating on the implementation just to be clear. I accept changes
> > > > > > might be needed there. The $subject is all about DT bindings and what need
> > > > > > to be changes and for me nothing, just use existing bindings and if there
> > > > > > are issues there, let us discuss it with specifics.
> > > > > > 
> > > > > How can changes to dt bindings be nothing? All the resources
> > > > > clk/regulators/resets will become optional and a new power or perf domain
> > > > > will become required for each device with firmwares that support SCMI Perf.
> > > > > 
> > > > Correct, sorry to miss the point that few properties are now optional from
> > > > mandatory before. Very good point. I was so caught up with the addition of
> > > > the new "firmware controlled blah blah" property/compatible that I missed
> > > > to observe mandatory->optional as a change. Thanks for correcting me.
> > > > 
> > > If there are no more questions on this and everyone is on the same page, I
> > > would like to conclude this thread in favor of using a new DT property
> > > 'qcom,firmware-managed-resources'.
> > > 
> > This is exactly opposite to what I have advocated so far in this thread.
> > Not sure how you drew to this conclusion. Check [1] and [2] for example.
> > The point was not to have qcom specific compatibles or properties as it
> > doesn't scale well. Please chime into those if you have argument and how
> > you came to this conclusion.
> > 
> > --
> > Regards,
> > Sudeep
> > 
> > [1] https://lore.kernel.org/all/ZfMZ9ATxuvONcGpz@bogus
> > [2] https://lore.kernel.org/all/0411f99d-231a-af4b-d681-7f7748361aa3@quicinc.com
> Hi Sudeep, we had a discussion with Linaro team on this and people suggested
> that this should be a vendor specific property since different vendors might
> abstract differently.

Unless you point to some public discussion or meeting notes it is hard to
understand what was discussed and how this conclusion was drawn, definitely
not evident from the thread. Any pointers to the meeting notes ? If it was
private, just assume it didn't happen when responding on public ML threads
like these. Otherwise it adds more confusion and won't be much of a help IMO.

> Moreover, our changes are only in Qualcomm drivers so
> it made sense to use vendor specific property. That being said, if you are
> suggesting that we remove Qcom from it, I can again discuss this. I will let
> Srini and other pitch in here if they want to add more to it.

Sorry, there are lots of points made on this thread which you have not
read(missed) or not yet responded. So I suggest you to go through the thread
and then either respond or better start a new thread summarising what is
addressed so far what is not addressed, if you have responses to those
questions.

Since this has become a huge thread now, it may make it hard for people
to follow, annoy few others 😉. So I suggest to start a new thread capturing
highlights of the discussion so far.

For me, you seem to have missed how you address this on a generic USB or
some other non-Qcom IP is the main question I have repeatedly asked and
haven't received any comments on that topic. Trilok suggested that case
needs to be considered even on Qcom SoC which makes you argument that I
will first address Qcom IPs only just weak.

So at this point, I have to conclude you are not interested in addressing
that if you continue in that direction and accept that you will go ahead
with Qcom specific solution anyways. If so, I may have to skip getting
involved in these discussions in the future as I believe it may be just
waste of my time. Sorry if that's harsh, nothing personal.

--
Regards,
Sudeep

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

[Sudeep Holla]

On Thu, Apr 11, 2024 at 09:29:17PM +0200, Krzysztof Kozlowski wrote:
>
> Just to clarify: Ulf agreed on compatible way for proof of concept and
> asked to send a code so everyone can understand better what you are
> making. I don't recall any Linaro policy or answer.
>
> After above email, other people proposed other solutions and disagreed
> with that statement, so no, you do not have a consensus.
>
> Trying to present this as a consensus if way exaggerated.
>
> You have no conclusion, because talk is cheap and this thread is way too
> big. It's also way to vague, like we had to poke you for several emails
> to get hardware description. I still don't recall it, but TBH, I am not
> going to look at 50 email thread for one email.
>
> Therefore, feel free to propose something, but if you call it "that was
> the consensus from community" then please already add there my
> Nacked-by, because there was no consensus.
>
> In your proposal finally describe your hardware, firmware and problem
> which you are solving (because no one will be going back to this thread).
>

I can't agree more, well summarised.

Nikunj,

Sorry I read this email after I responded to you, so please ignore my
suggestion on starting a fresh thread, follow Krzysztof's suggestion
instead. But all other points in my email still stands.

--
Regards,
Sudeep