| Message ID | 20241130-fix-board-clocks-v2-20-b9a35858657e@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | arm64: dts: qcom: move board clocks to SoC DTSI files | expand |
On 30/11/2024 02:44, Dmitry Baryshkov wrote: > IPQ5018 is one of the platforms where board-level clocks (XO, sleep) > definitions are split between the SoC dtsi file and the board file. > This is not optimal, as the clocks are a part of the SoC + PMICs design. > Frequencies are common for the whole set of devices using the same SoC. > Remove the split and move frequencies to the SoC DTSI file. > > Suggested-by: Bjorn Andersson <andersson@kernel.org> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> This contradicts DTS coding style and all my existing review. Obviously that's a NAK from me. If you want to merge this patch, please kindly carry my formal objection for this and all following "move board clocks" patches: Nacked-by: Krzysztof Kozlowski <krzk@kernel.org> (I'll respond in next patches as well, just for formality/b4) Best regards, Krzysztof
On 30/11/2024 10:57, Dmitry Baryshkov wrote: > On Sat, Nov 30, 2024 at 10:29:38AM +0100, Krzysztof Kozlowski wrote: >> On 30/11/2024 02:44, Dmitry Baryshkov wrote: >>> IPQ5018 is one of the platforms where board-level clocks (XO, sleep) >>> definitions are split between the SoC dtsi file and the board file. >>> This is not optimal, as the clocks are a part of the SoC + PMICs design. >>> Frequencies are common for the whole set of devices using the same SoC. >>> Remove the split and move frequencies to the SoC DTSI file. >>> >>> Suggested-by: Bjorn Andersson <andersson@kernel.org> >>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> >> >> This contradicts DTS coding style and all my existing review. Obviously >> that's a NAK from me. If you want to merge this patch, please kindly >> carry my formal objection for this and all following "move board clocks" >> patches: >> >> Nacked-by: Krzysztof Kozlowski <krzk@kernel.org> > > I'd kindly ask Bjorn to chime in as a platform maintainer. To change my NAK? NAK is still a NAK. We discussed it many, many times already. We have coding style for this explicitly mentioning this case. Could not be more specific... plus all my reviews for Qualcomm, NXP, TI, ST and other platforms. I would be quite unpredictable or unfair if I gave here some sort of exception while expecting different code from other platforms. Please carry my NAK. Best regards, Krzysztof
On Sat, Nov 30, 2024 at 11:00:32AM +0100, Krzysztof Kozlowski wrote: > On 30/11/2024 10:57, Dmitry Baryshkov wrote: > > On Sat, Nov 30, 2024 at 10:29:38AM +0100, Krzysztof Kozlowski wrote: > >> On 30/11/2024 02:44, Dmitry Baryshkov wrote: > >>> IPQ5018 is one of the platforms where board-level clocks (XO, sleep) > >>> definitions are split between the SoC dtsi file and the board file. > >>> This is not optimal, as the clocks are a part of the SoC + PMICs design. > >>> Frequencies are common for the whole set of devices using the same SoC. > >>> Remove the split and move frequencies to the SoC DTSI file. > >>> > >>> Suggested-by: Bjorn Andersson <andersson@kernel.org> > >>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > >> > >> This contradicts DTS coding style and all my existing review. Obviously > >> that's a NAK from me. If you want to merge this patch, please kindly > >> carry my formal objection for this and all following "move board clocks" > >> patches: > >> > >> Nacked-by: Krzysztof Kozlowski <krzk@kernel.org> > > > > I'd kindly ask Bjorn to chime in as a platform maintainer. > > > To change my NAK? NAK is still a NAK. We discussed it many, many times > already. We have coding style for this explicitly mentioning this case. > Could not be more specific... plus all my reviews for Qualcomm, NXP, TI, > ST and other platforms. I would be quite unpredictable or unfair if I > gave here some sort of exception while expecting different code from > other platforms. > > Please carry my NAK. Of course. I didn't mean to drop your tag or your objection. BTW, would it be possible for you to clarify the policy on external references? I mean, is it fine for DTSI to reference a label which is not defined within that file or within one of the files that it includes?
On Sat, Nov 30, 2024 at 11:43:34AM +0100, Krzysztof Kozlowski wrote: > On 30/11/2024 11:26, Dmitry Baryshkov wrote: > > On Sat, Nov 30, 2024 at 11:00:32AM +0100, Krzysztof Kozlowski wrote: > >> On 30/11/2024 10:57, Dmitry Baryshkov wrote: > >>> On Sat, Nov 30, 2024 at 10:29:38AM +0100, Krzysztof Kozlowski wrote: > >>>> On 30/11/2024 02:44, Dmitry Baryshkov wrote: > >>>>> IPQ5018 is one of the platforms where board-level clocks (XO, sleep) > >>>>> definitions are split between the SoC dtsi file and the board file. > >>>>> This is not optimal, as the clocks are a part of the SoC + PMICs design. > >>>>> Frequencies are common for the whole set of devices using the same SoC. > >>>>> Remove the split and move frequencies to the SoC DTSI file. > >>>>> > >>>>> Suggested-by: Bjorn Andersson <andersson@kernel.org> > >>>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > >>>> > >>>> This contradicts DTS coding style and all my existing review. Obviously > >>>> that's a NAK from me. If you want to merge this patch, please kindly > >>>> carry my formal objection for this and all following "move board clocks" > >>>> patches: > >>>> > >>>> Nacked-by: Krzysztof Kozlowski <krzk@kernel.org> > >>> > >>> I'd kindly ask Bjorn to chime in as a platform maintainer. > >> > >> > >> To change my NAK? NAK is still a NAK. We discussed it many, many times > >> already. We have coding style for this explicitly mentioning this case. > >> Could not be more specific... plus all my reviews for Qualcomm, NXP, TI, > >> ST and other platforms. I would be quite unpredictable or unfair if I > >> gave here some sort of exception while expecting different code from > >> other platforms. > >> > >> Please carry my NAK. > > > > Of course. I didn't mean to drop your tag or your objection. > > > > BTW, would it be possible for you to clarify the policy on external > > references? I mean, is it fine for DTSI to reference a label which is > > not defined within that file or within one of the files that it includes? > > > It is fine, you have plenty of such examples of shared components like > some audio blocks or PMICs. > > All Qualcomm PMICs DTSI (e.g. arch/arm64/boot/dts/qcom/pmi632.dtsi ) > reference them. Chromebooks are even "worse" here: > arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi > Nothing gets included there but hundred of phandles! > > Are you planning to "fix" these as well? No. > > These are just Qualcomm, but same cases are everywhere else. > > But *that's not even important* because I do not suggest to move clocks > to DTSI. I suggest - and was almost always suggesting as best compromise > - to follow DTS coding style by doing opposite of what this patch is > doing. That's why I NAKed this and following patches, except last two > which are different. If you remmember my first attempt was implemented other way around. But I think it still better to have both frequencies in the SoC dtsi, it points out that it is tightly coupled with the RPM CC (and can not be easily changed), it saves us from 32 kHz / 32.768 kHz / 32.764 kHz typos, etc.
On 30.11.2024 11:43 AM, Krzysztof Kozlowski wrote: > On 30/11/2024 11:26, Dmitry Baryshkov wrote: >> On Sat, Nov 30, 2024 at 11:00:32AM +0100, Krzysztof Kozlowski wrote: >>> On 30/11/2024 10:57, Dmitry Baryshkov wrote: >>>> On Sat, Nov 30, 2024 at 10:29:38AM +0100, Krzysztof Kozlowski wrote: >>>>> On 30/11/2024 02:44, Dmitry Baryshkov wrote: >>>>>> IPQ5018 is one of the platforms where board-level clocks (XO, sleep) >>>>>> definitions are split between the SoC dtsi file and the board file. >>>>>> This is not optimal, as the clocks are a part of the SoC + PMICs design. >>>>>> Frequencies are common for the whole set of devices using the same SoC. >>>>>> Remove the split and move frequencies to the SoC DTSI file. >>>>>> >>>>>> Suggested-by: Bjorn Andersson <andersson@kernel.org> >>>>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> >>>>> >>>>> This contradicts DTS coding style and all my existing review. Obviously >>>>> that's a NAK from me. If you want to merge this patch, please kindly >>>>> carry my formal objection for this and all following "move board clocks" >>>>> patches: >>>>> >>>>> Nacked-by: Krzysztof Kozlowski <krzk@kernel.org> >>>> >>>> I'd kindly ask Bjorn to chime in as a platform maintainer. >>> >>> >>> To change my NAK? NAK is still a NAK. We discussed it many, many times >>> already. We have coding style for this explicitly mentioning this case. >>> Could not be more specific... plus all my reviews for Qualcomm, NXP, TI, >>> ST and other platforms. I would be quite unpredictable or unfair if I >>> gave here some sort of exception while expecting different code from >>> other platforms. >>> >>> Please carry my NAK. >> >> Of course. I didn't mean to drop your tag or your objection. >> >> BTW, would it be possible for you to clarify the policy on external >> references? I mean, is it fine for DTSI to reference a label which is >> not defined within that file or within one of the files that it includes? > > > It is fine, you have plenty of such examples of shared components like > some audio blocks or PMICs. > > All Qualcomm PMICs DTSI (e.g. arch/arm64/boot/dts/qcom/pmi632.dtsi ) > reference them. Chromebooks are even "worse" here: > arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi > Nothing gets included there but hundred of phandles! > > Are you planning to "fix" these as well? > > These are just Qualcomm, but same cases are everywhere else. > > But *that's not even important* because I do not suggest to move clocks > to DTSI. I suggest - and was almost always suggesting as best compromise > - to follow DTS coding style by doing opposite of what this patch is > doing. That's why I NAKed this and following patches, except last two > which are different. Many of these components are simply not "fully on board" or "fully on SoC" on Qualcomm platforms, and probably others too. A number of components are tightly coupled and there are lots of circular dependencies, or in-between cases (like RPM(h)cc which abstract clocks specific to a SoC+PMIC combo). Some are effectively represented multiple times. There's also a lot of internal routing which can't be well-represented in DT without adding thousands of lines that Linux would register as virtual clocks that do absolutely nothing. There's also clocks that are not even visible from software POV that are physically connected. And as the final point, any given platform requires a fixed frequency crystal is present and will (to my understanding) not function otherwise. Hence, I think this is really form over function that gets in the way.. Konrad
diff --git a/arch/arm64/boot/dts/qcom/ipq5018-rdp432-c2.dts b/arch/arm64/boot/dts/qcom/ipq5018-rdp432-c2.dts index 8460b538eb6a3e2d6b971bd9637309809e0c0f0c..9bb87b7fd25777d4ba13bd2bb36024b8035d8afd 100644 --- a/arch/arm64/boot/dts/qcom/ipq5018-rdp432-c2.dts +++ b/arch/arm64/boot/dts/qcom/ipq5018-rdp432-c2.dts @@ -38,10 +38,6 @@ &sdhc_1 { status = "okay"; }; -&sleep_clk { - clock-frequency = <32000>; -}; - &tlmm { sdc_default_state: sdc-default-state { clk-pins { @@ -78,7 +74,3 @@ &usb_dwc { &usbphy0 { status = "okay"; }; - -&xo_board_clk { - clock-frequency = <24000000>; -}; diff --git a/arch/arm64/boot/dts/qcom/ipq5018-tplink-archer-ax55-v1.dts b/arch/arm64/boot/dts/qcom/ipq5018-tplink-archer-ax55-v1.dts index 5bb021cb29cd39cb95035bfac1bdbc976439838b..af281c285447f9845f542cc9d976fcdc7f1cf766 100644 --- a/arch/arm64/boot/dts/qcom/ipq5018-tplink-archer-ax55-v1.dts +++ b/arch/arm64/boot/dts/qcom/ipq5018-tplink-archer-ax55-v1.dts @@ -95,10 +95,6 @@ &blsp1_uart1 { status = "okay"; }; -&sleep_clk { - clock-frequency = <32000>; -}; - &tlmm { button_pins: button-pins-state { pins = "gpio25", "gpio31"; @@ -122,7 +118,3 @@ uart_pins: uart-pins-state { bias-disable; }; }; - -&xo_board_clk { - clock-frequency = <24000000>; -}; diff --git a/arch/arm64/boot/dts/qcom/ipq5018.dtsi b/arch/arm64/boot/dts/qcom/ipq5018.dtsi index 8914f2ef0bc47fda243b19174f77ce73fc10757d..fe617e9a086e6541854e03bd1f0a6519079befed 100644 --- a/arch/arm64/boot/dts/qcom/ipq5018.dtsi +++ b/arch/arm64/boot/dts/qcom/ipq5018.dtsi @@ -19,11 +19,13 @@ clocks { sleep_clk: sleep-clk { compatible = "fixed-clock"; #clock-cells = <0>; + clock-frequency = <32000>; }; xo_board_clk: xo-board-clk { compatible = "fixed-clock"; #clock-cells = <0>; + clock-frequency = <24000000>; }; };
IPQ5018 is one of the platforms where board-level clocks (XO, sleep) definitions are split between the SoC dtsi file and the board file. This is not optimal, as the clocks are a part of the SoC + PMICs design. Frequencies are common for the whole set of devices using the same SoC. Remove the split and move frequencies to the SoC DTSI file. Suggested-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> --- arch/arm64/boot/dts/qcom/ipq5018-rdp432-c2.dts | 8 -------- arch/arm64/boot/dts/qcom/ipq5018-tplink-archer-ax55-v1.dts | 8 -------- arch/arm64/boot/dts/qcom/ipq5018.dtsi | 2 ++ 3 files changed, 2 insertions(+), 16 deletions(-)