| Message ID | 20200829172532.29358-3-krzk@kernel.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/4] dt-bindings: display: samsung, amoled-mipi-dsi: Do not require enable-gpios on samsung, s6e63j0x03 | expand |
Hi Krzysztof, On 29.08.2020 19:25, Krzysztof Kozlowski wrote: > Commit 52005dece527 ("ARM: dts: Add assigned clock parents to CMU node > for exynos3250") added assigned clocks under Clock Management Unit to > fix hangs when accessing ISP registers. > > This is not the place for it as CMU does not have a required "clocks" > property: > > arch/arm/boot/dts/exynos3250-artik5-eval.dt.yaml: clock-controller@10030000: 'clocks' is a dependency of 'assigned-clocks' > > Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> > > --- > > Not tested and I wonder whether actually correct. For example, what will > happen if devfreq (exynos-bus) is not built in? > > Could someone verify it? Sorry, but this patch is not correct. Those clocks has noting with bus-freq. The assigned clocks property should stay where it is. Maybe one need to fix the schemas for dts verification. Those clocks has to be set (and so generic clock framework does) according to the assigned clocks properties once the clock controller is instantiated. The only alternative would be to add exynos-subcmu variant to properly link CMU with the ISP power domain, but assuming that there is no Exynos 3250 ISP driver in mainline (and probably never will be), it is safe to keep those clocks sourced from 24MHz crystal. > --- > arch/arm/boot/dts/exynos3250.dtsi | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/arch/arm/boot/dts/exynos3250.dtsi b/arch/arm/boot/dts/exynos3250.dtsi > index c67c70e46794..6d467022d929 100644 > --- a/arch/arm/boot/dts/exynos3250.dtsi > +++ b/arch/arm/boot/dts/exynos3250.dtsi > @@ -214,10 +214,6 @@ > compatible = "samsung,exynos3250-cmu"; > reg = <0x10030000 0x20000>; > #clock-cells = <1>; > - assigned-clocks = <&cmu CLK_MOUT_ACLK_400_MCUISP_SUB>, > - <&cmu CLK_MOUT_ACLK_266_SUB>; > - assigned-clock-parents = <&cmu CLK_FIN_PLL>, > - <&cmu CLK_FIN_PLL>; > }; > > cmu_dmc: clock-controller@105c0000 { > @@ -835,6 +831,8 @@ > compatible = "samsung,exynos-bus"; > clocks = <&cmu CLK_DIV_ACLK_400_MCUISP>; > clock-names = "bus"; > + assigned-clocks = <&cmu CLK_MOUT_ACLK_400_MCUISP_SUB>; > + assigned-clock-parents = <&cmu CLK_FIN_PLL>; > operating-points-v2 = <&bus_mcuisp_opp_table>; > status = "disabled"; > }; > @@ -843,6 +841,8 @@ > compatible = "samsung,exynos-bus"; > clocks = <&cmu CLK_DIV_ACLK_266>; > clock-names = "bus"; > + assigned-clocks = <&cmu CLK_MOUT_ACLK_266_SUB>; > + assigned-clock-parents = <&cmu CLK_FIN_PLL>; > operating-points-v2 = <&bus_isp_opp_table>; > status = "disabled"; > }; Best regards
On Mon, Aug 31, 2020 at 10:11:02AM +0200, Marek Szyprowski wrote: > Hi Krzysztof, > > On 29.08.2020 19:25, Krzysztof Kozlowski wrote: > > Commit 52005dece527 ("ARM: dts: Add assigned clock parents to CMU node > > for exynos3250") added assigned clocks under Clock Management Unit to > > fix hangs when accessing ISP registers. > > > > This is not the place for it as CMU does not have a required "clocks" > > property: > > > > arch/arm/boot/dts/exynos3250-artik5-eval.dt.yaml: clock-controller@10030000: 'clocks' is a dependency of 'assigned-clocks' > > > > Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> > > > > --- > > > > Not tested and I wonder whether actually correct. For example, what will > > happen if devfreq (exynos-bus) is not built in? > > > > Could someone verify it? > > Sorry, but this patch is not correct. Those clocks has noting with > bus-freq. The assigned clocks property should stay where it is. Maybe > one need to fix the schemas for dts verification. Those clocks has to be > set (and so generic clock framework does) according to the assigned > clocks properties once the clock controller is instantiated. > > The only alternative would be to add exynos-subcmu variant to properly > link CMU with the ISP power domain, but assuming that there is no Exynos > 3250 ISP driver in mainline (and probably never will be), it is safe to > keep those clocks sourced from 24MHz crystal. Thanks for the clarification. Another solution to silence the warning could be to add a "clocks" property for FIN_PLL, although the driver actually does not take it. This is the only remaining dtschema check warning on Exynos3250 so it would be nice to at least silence it. My goal is to have all them schema-correct, or as close as possible (for Exynos4 the camera node is a trouble). Best regards, Krzysztof
Hi Krzysztof, On 31.08.2020 10:19, Krzysztof Kozlowski wrote: > On Mon, Aug 31, 2020 at 10:11:02AM +0200, Marek Szyprowski wrote: >> On 29.08.2020 19:25, Krzysztof Kozlowski wrote: >>> Commit 52005dece527 ("ARM: dts: Add assigned clock parents to CMU node >>> for exynos3250") added assigned clocks under Clock Management Unit to >>> fix hangs when accessing ISP registers. >>> >>> This is not the place for it as CMU does not have a required "clocks" >>> property: >>> >>> arch/arm/boot/dts/exynos3250-artik5-eval.dt.yaml: clock-controller@10030000: 'clocks' is a dependency of 'assigned-clocks' >>> >>> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> >>> >>> --- >>> >>> Not tested and I wonder whether actually correct. For example, what will >>> happen if devfreq (exynos-bus) is not built in? >>> >>> Could someone verify it? >> Sorry, but this patch is not correct. Those clocks has noting with >> bus-freq. The assigned clocks property should stay where it is. Maybe >> one need to fix the schemas for dts verification. Those clocks has to be >> set (and so generic clock framework does) according to the assigned >> clocks properties once the clock controller is instantiated. >> >> The only alternative would be to add exynos-subcmu variant to properly >> link CMU with the ISP power domain, but assuming that there is no Exynos >> 3250 ISP driver in mainline (and probably never will be), it is safe to >> keep those clocks sourced from 24MHz crystal. > Thanks for the clarification. Another solution to silence the warning > could be to add a "clocks" property for FIN_PLL, although the driver > actually does not take it. Okay, that would be fine. It would make dts match better the hardware and this would even help generic clock framework to always instantiate CMU after the oscilator fixed-clock (there have been some hacks there at some point for that...) Best regards
On Mon, Aug 31, 2020 at 10:19:06AM +0200, Krzysztof Kozlowski wrote: > On Mon, Aug 31, 2020 at 10:11:02AM +0200, Marek Szyprowski wrote: > > Hi Krzysztof, > > > > On 29.08.2020 19:25, Krzysztof Kozlowski wrote: > > > Commit 52005dece527 ("ARM: dts: Add assigned clock parents to CMU node > > > for exynos3250") added assigned clocks under Clock Management Unit to > > > fix hangs when accessing ISP registers. > > > > > > This is not the place for it as CMU does not have a required "clocks" > > > property: > > > > > > arch/arm/boot/dts/exynos3250-artik5-eval.dt.yaml: clock-controller@10030000: 'clocks' is a dependency of 'assigned-clocks' > > > > > > Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> > > > > > > --- > > > > > > Not tested and I wonder whether actually correct. For example, what will > > > happen if devfreq (exynos-bus) is not built in? > > > > > > Could someone verify it? > > > > Sorry, but this patch is not correct. Those clocks has noting with > > bus-freq. The assigned clocks property should stay where it is. Maybe > > one need to fix the schemas for dts verification. Those clocks has to be > > set (and so generic clock framework does) according to the assigned > > clocks properties once the clock controller is instantiated. > > > > The only alternative would be to add exynos-subcmu variant to properly > > link CMU with the ISP power domain, but assuming that there is no Exynos > > 3250 ISP driver in mainline (and probably never will be), it is safe to > > keep those clocks sourced from 24MHz crystal. > > Thanks for the clarification. Another solution to silence the warning > could be to add a "clocks" property for FIN_PLL, although the driver > actually does not take it. > > This is the only remaining dtschema check warning on Exynos3250 so it > would be nice to at least silence it. My goal is to have all them > schema-correct, or as close as possible (for Exynos4 the camera node is > a trouble). BTW, if you have some time, it would be awesome if you could test all the series (on Exynos3250 obviously with this patch reverted): https://github.com/krzk/linux/tree/for-next/dts-exynos-schema-cleanups The Exynos5 cleanup is ongoing, so there will be more patches. But Exynos3 and Exynos4 I finished. Best regards, Krzysztof
diff --git a/arch/arm/boot/dts/exynos3250.dtsi b/arch/arm/boot/dts/exynos3250.dtsi index c67c70e46794..6d467022d929 100644 --- a/arch/arm/boot/dts/exynos3250.dtsi +++ b/arch/arm/boot/dts/exynos3250.dtsi @@ -214,10 +214,6 @@ compatible = "samsung,exynos3250-cmu"; reg = <0x10030000 0x20000>; #clock-cells = <1>; - assigned-clocks = <&cmu CLK_MOUT_ACLK_400_MCUISP_SUB>, - <&cmu CLK_MOUT_ACLK_266_SUB>; - assigned-clock-parents = <&cmu CLK_FIN_PLL>, - <&cmu CLK_FIN_PLL>; }; cmu_dmc: clock-controller@105c0000 { @@ -835,6 +831,8 @@ compatible = "samsung,exynos-bus"; clocks = <&cmu CLK_DIV_ACLK_400_MCUISP>; clock-names = "bus"; + assigned-clocks = <&cmu CLK_MOUT_ACLK_400_MCUISP_SUB>; + assigned-clock-parents = <&cmu CLK_FIN_PLL>; operating-points-v2 = <&bus_mcuisp_opp_table>; status = "disabled"; }; @@ -843,6 +841,8 @@ compatible = "samsung,exynos-bus"; clocks = <&cmu CLK_DIV_ACLK_266>; clock-names = "bus"; + assigned-clocks = <&cmu CLK_MOUT_ACLK_266_SUB>; + assigned-clock-parents = <&cmu CLK_FIN_PLL>; operating-points-v2 = <&bus_isp_opp_table>; status = "disabled"; };
Commit 52005dece527 ("ARM: dts: Add assigned clock parents to CMU node for exynos3250") added assigned clocks under Clock Management Unit to fix hangs when accessing ISP registers. This is not the place for it as CMU does not have a required "clocks" property: arch/arm/boot/dts/exynos3250-artik5-eval.dt.yaml: clock-controller@10030000: 'clocks' is a dependency of 'assigned-clocks' Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> --- Not tested and I wonder whether actually correct. For example, what will happen if devfreq (exynos-bus) is not built in? Could someone verify it? --- arch/arm/boot/dts/exynos3250.dtsi | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)