[v2,00/13] mailbox/arm64/ qcom: rework compatibles for fallback

  Hi,

Changes since v1
================
1. Rebase
2. Make msm8994 fallback for several variants, not msm8953, because the latter
   actually might take some clocks.
3. Two new patches for SDX55.
4. Minor corrections in bindings style.
v1: https://lore.kernel.org/all/20230202161856.385825-1-krzysztof.kozlowski@linaro.org/

Description
===========

If entire approach is accepted (and correct), there are no dependencies and
patches can be picked independently.  Although the best in the same cycle, so
there will be no new `dtbs_check` warnings.

Best regards,
Krzysztof

Krzysztof Kozlowski (13):
  dt-bindings: mailbox: qcom,apcs-kpss-global: correct SDX55 clocks
  dt-bindings: mailbox: qcom,apcs-kpss-global: fix SDX55 'if' match
  dt-bindings: mailbox: qcom,apcs-kpss-global: use fallbacks
  mailbox: qcom-apcs-ipc: do not grow the of_device_id
  arm64: dts: qcom: ipq8074: add compatible fallback to mailbox
  arm64: dts: qcom: msm8976: add compatible fallback to mailbox
  arm64: dts: qcom: msm8998: add compatible fallback to mailbox
  arm64: dts: qcom: sdm630: add compatible fallback to mailbox
  arm64: dts: qcom: sm6115: add compatible fallback to mailbox
  arm64: dts: qcom: sm6125: add compatible fallback to mailbox
  arm64: dts: qcom: qcs404: add compatible fallback to mailbox
  arm64: dts: qcom: sc7180: add compatible fallback to mailbox
  arm64: dts: qcom: sm8150: add compatible fallback to mailbox

 .../mailbox/qcom,apcs-kpss-global.yaml        | 67 ++++++++++---------
 arch/arm64/boot/dts/qcom/ipq8074.dtsi         |  3 +-
 arch/arm64/boot/dts/qcom/msm8976.dtsi         |  3 +-
 arch/arm64/boot/dts/qcom/msm8998.dtsi         |  3 +-
 arch/arm64/boot/dts/qcom/qcs404.dtsi          |  3 +-
 arch/arm64/boot/dts/qcom/sc7180.dtsi          |  3 +-
 arch/arm64/boot/dts/qcom/sdm630.dtsi          |  3 +-
 arch/arm64/boot/dts/qcom/sm6115.dtsi          |  3 +-
 arch/arm64/boot/dts/qcom/sm6125.dtsi          |  3 +-
 arch/arm64/boot/dts/qcom/sm8150.dtsi          |  3 +-
 drivers/mailbox/qcom-apcs-ipc-mailbox.c       | 11 +--
 11 files changed, 60 insertions(+), 45 deletions(-)
  

On 14/03/2023 10:09, Krzysztof Kozlowski wrote:
> Hi,
> 
> Changes since v1
> ================
> 1. Rebase
> 2. Make msm8994 fallback for several variants, not msm8953, because the latter
>     actually might take some clocks.

Although the approach looks correct, I think that in some cases it tries 
to mark devices compatible judging from the current driver, not from the 
hardware itself.

For the reference, on msm8994 the apcs is a clock controller for the l2 
clocks (which we do not support yet). If I'm not mistaken, on msm8976 
the apcs region contains a mux for the cluster1 clocks. On sdm630/660 
the apcs region also seems to be involved in CPU clocks scaling.

On the other hand, the sc7180/sm8150 part seems logical.

> 3. Two new patches for SDX55.
> 4. Minor corrections in bindings style.
> v1: https://lore.kernel.org/all/20230202161856.385825-1-krzysztof.kozlowski@linaro.org/
> 
> Description
> ===========
> 
> If entire approach is accepted (and correct), there are no dependencies and
> patches can be picked independently.  Although the best in the same cycle, so
> there will be no new `dtbs_check` warnings.
> 
> Best regards,
> Krzysztof
> 
> Krzysztof Kozlowski (13):
>    dt-bindings: mailbox: qcom,apcs-kpss-global: correct SDX55 clocks
>    dt-bindings: mailbox: qcom,apcs-kpss-global: fix SDX55 'if' match
>    dt-bindings: mailbox: qcom,apcs-kpss-global: use fallbacks
>    mailbox: qcom-apcs-ipc: do not grow the of_device_id
>    arm64: dts: qcom: ipq8074: add compatible fallback to mailbox
>    arm64: dts: qcom: msm8976: add compatible fallback to mailbox
>    arm64: dts: qcom: msm8998: add compatible fallback to mailbox
>    arm64: dts: qcom: sdm630: add compatible fallback to mailbox
>    arm64: dts: qcom: sm6115: add compatible fallback to mailbox
>    arm64: dts: qcom: sm6125: add compatible fallback to mailbox
>    arm64: dts: qcom: qcs404: add compatible fallback to mailbox
>    arm64: dts: qcom: sc7180: add compatible fallback to mailbox
>    arm64: dts: qcom: sm8150: add compatible fallback to mailbox
> 
>   .../mailbox/qcom,apcs-kpss-global.yaml        | 67 ++++++++++---------
>   arch/arm64/boot/dts/qcom/ipq8074.dtsi         |  3 +-
>   arch/arm64/boot/dts/qcom/msm8976.dtsi         |  3 +-
>   arch/arm64/boot/dts/qcom/msm8998.dtsi         |  3 +-
>   arch/arm64/boot/dts/qcom/qcs404.dtsi          |  3 +-
>   arch/arm64/boot/dts/qcom/sc7180.dtsi          |  3 +-
>   arch/arm64/boot/dts/qcom/sdm630.dtsi          |  3 +-
>   arch/arm64/boot/dts/qcom/sm6115.dtsi          |  3 +-
>   arch/arm64/boot/dts/qcom/sm6125.dtsi          |  3 +-
>   arch/arm64/boot/dts/qcom/sm8150.dtsi          |  3 +-
>   drivers/mailbox/qcom-apcs-ipc-mailbox.c       | 11 +--
>   11 files changed, 60 insertions(+), 45 deletions(-)
>
  

On 14/03/2023 13:16, Dmitry Baryshkov wrote:
> On 14/03/2023 10:09, Krzysztof Kozlowski wrote:
>> Hi,
>>
>> Changes since v1
>> ================
>> 1. Rebase
>> 2. Make msm8994 fallback for several variants, not msm8953, because the latter
>>     actually might take some clocks.
> 
> Although the approach looks correct, I think that in some cases it tries 
> to mark devices compatible judging from the current driver, not from the 
> hardware itself.

Which is what compatibility is about...

> 
> For the reference, on msm8994 the apcs is a clock controller for the l2 
> clocks (which we do not support yet). If I'm not mistaken, on msm8976 
> the apcs region contains a mux for the cluster1 clocks. On sdm630/660 
> the apcs region also seems to be involved in CPU clocks scaling.

The question is this means they are incompatible?

> 
> On the other hand, the sc7180/sm8150 part seems logical.
> 


Best regards,
Krzysztof
  

On 16/03/2023 07:52, Krzysztof Kozlowski wrote:
> On 14/03/2023 13:16, Dmitry Baryshkov wrote:
>> On 14/03/2023 10:09, Krzysztof Kozlowski wrote:
>>> Hi,
>>>
>>> Changes since v1
>>> ================
>>> 1. Rebase
>>> 2. Make msm8994 fallback for several variants, not msm8953, because the latter
>>>     actually might take some clocks.
>>
>> Although the approach looks correct, I think that in some cases it tries 
>> to mark devices compatible judging from the current driver, not from the 
>> hardware itself.
> 
> Which is what compatibility is about...
> 
>>
>> For the reference, on msm8994 the apcs is a clock controller for the l2 
>> clocks (which we do not support yet). If I'm not mistaken, on msm8976 
>> the apcs region contains a mux for the cluster1 clocks. On sdm630/660 
>> the apcs region also seems to be involved in CPU clocks scaling.
> 
> The question is this means they are incompatible?

Since there are no more comments I assume they are actually compatible
in the terms of SW interface.

Best regards,
Krzysztof
  

On Wed, 22 Mar 2023 at 19:37, Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 16/03/2023 07:52, Krzysztof Kozlowski wrote:
> > On 14/03/2023 13:16, Dmitry Baryshkov wrote:
> >> On 14/03/2023 10:09, Krzysztof Kozlowski wrote:
> >>> Hi,
> >>>
> >>> Changes since v1
> >>> ================
> >>> 1. Rebase
> >>> 2. Make msm8994 fallback for several variants, not msm8953, because the latter
> >>>     actually might take some clocks.
> >>
> >> Although the approach looks correct, I think that in some cases it tries
> >> to mark devices compatible judging from the current driver, not from the
> >> hardware itself.
> >
> > Which is what compatibility is about...

Well, I was trying to say that once we update the driver, the devices
will not be compatible. But probably our definitions of being
compatible differ.

> >
> >>
> >> For the reference, on msm8994 the apcs is a clock controller for the l2
> >> clocks (which we do not support yet). If I'm not mistaken, on msm8976
> >> the apcs region contains a mux for the cluster1 clocks. On sdm630/660
> >> the apcs region also seems to be involved in CPU clocks scaling.
> >
> > The question is this means they are incompatible?
>
> Since there are no more comments I assume they are actually compatible
> in the terms of SW interface.
  

On 22/03/2023 23:28, Dmitry Baryshkov wrote:
> On Wed, 22 Mar 2023 at 19:37, Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>>
>> On 16/03/2023 07:52, Krzysztof Kozlowski wrote:
>>> On 14/03/2023 13:16, Dmitry Baryshkov wrote:
>>>> On 14/03/2023 10:09, Krzysztof Kozlowski wrote:
>>>>> Hi,
>>>>>
>>>>> Changes since v1
>>>>> ================
>>>>> 1. Rebase
>>>>> 2. Make msm8994 fallback for several variants, not msm8953, because the latter
>>>>>     actually might take some clocks.
>>>>
>>>> Although the approach looks correct, I think that in some cases it tries
>>>> to mark devices compatible judging from the current driver, not from the
>>>> hardware itself.
>>>
>>> Which is what compatibility is about...
> 
> Well, I was trying to say that once we update the driver, the devices
> will not be compatible. But probably our definitions of being
> compatible differ.

What do you want to update in the driver? What's going to happen with
it? What is missing?

Best regards,
Krzysztof
  

On Thu, 23 Mar 2023 at 08:33, Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 22/03/2023 23:28, Dmitry Baryshkov wrote:
> > On Wed, 22 Mar 2023 at 19:37, Krzysztof Kozlowski
> > <krzysztof.kozlowski@linaro.org> wrote:
> >>
> >> On 16/03/2023 07:52, Krzysztof Kozlowski wrote:
> >>> On 14/03/2023 13:16, Dmitry Baryshkov wrote:
> >>>> On 14/03/2023 10:09, Krzysztof Kozlowski wrote:
> >>>>> Hi,
> >>>>>
> >>>>> Changes since v1
> >>>>> ================
> >>>>> 1. Rebase
> >>>>> 2. Make msm8994 fallback for several variants, not msm8953, because the latter
> >>>>>     actually might take some clocks.
> >>>>
> >>>> Although the approach looks correct, I think that in some cases it tries
> >>>> to mark devices compatible judging from the current driver, not from the
> >>>> hardware itself.
> >>>
> >>> Which is what compatibility is about...
> >
> > Well, I was trying to say that once we update the driver, the devices
> > will not be compatible. But probably our definitions of being
> > compatible differ.
>
> What do you want to update in the driver? What's going to happen with
> it? What is missing?

Some of these platforms do not have CPUfreq support, which will most
likely require programming of cluster and L2/L3 clocks being part of
this region.

For the reference, I think that sc7180/sm8150/other new platforms are
proper examples of 'compatible' devices, so the patchset itself has a
correct/good idea beneath. It's just that additional research might be
required for the older platforms.


--
With best wishes
Dmitry
  

On 23/03/2023 10:44, Dmitry Baryshkov wrote:
> On Thu, 23 Mar 2023 at 08:33, Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>>
>> On 22/03/2023 23:28, Dmitry Baryshkov wrote:
>>> On Wed, 22 Mar 2023 at 19:37, Krzysztof Kozlowski
>>> <krzysztof.kozlowski@linaro.org> wrote:
>>>>
>>>> On 16/03/2023 07:52, Krzysztof Kozlowski wrote:
>>>>> On 14/03/2023 13:16, Dmitry Baryshkov wrote:
>>>>>> On 14/03/2023 10:09, Krzysztof Kozlowski wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Changes since v1
>>>>>>> ================
>>>>>>> 1. Rebase
>>>>>>> 2. Make msm8994 fallback for several variants, not msm8953, because the latter
>>>>>>>     actually might take some clocks.
>>>>>>
>>>>>> Although the approach looks correct, I think that in some cases it tries
>>>>>> to mark devices compatible judging from the current driver, not from the
>>>>>> hardware itself.
>>>>>
>>>>> Which is what compatibility is about...
>>>
>>> Well, I was trying to say that once we update the driver, the devices
>>> will not be compatible. But probably our definitions of being
>>> compatible differ.
>>
>> What do you want to update in the driver? What's going to happen with
>> it? What is missing?
> 
> Some of these platforms do not have CPUfreq support, which will most
> likely require programming of cluster and L2/L3 clocks being part of
> this region.
> 
> For the reference, I think that sc7180/sm8150/other new platforms are
> proper examples of 'compatible' devices, so the patchset itself has a
> correct/good idea beneath. It's just that additional research might be
> required for the older platforms.

I'll split the series so the sc7180/so on bits can go in and we'll
figure out compatibility for the rest later...

Best regards,
Krzysztof