.../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(-)
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(-) -- 2.34.1
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(-) > -- With best wishes Dmitry
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. -- With best wishes Dmitry
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
© 2016 - 2026 Red Hat, Inc.