> From: Stephen Boyd [mailto:sboyd@xxxxxxxxxx] > > Quoting Eric Nelson (2019-03-11 13:48:55) > > > On March 11, 2019, 6:35 p.m. UTC, Stephen Boyd wrote: > > > Quoting Eric Nelson (2019-03-11 08:59:56) > > >> + * > > >> + * Renamed to _BROKEN to prevent inadvertent use, > > >> + * but reserved the array slot to maintain DT binary > > >> + * compatibility. > > >> + */ > > >> +#define IMX6QDL_CLK_PLL4_AUDIO_DIV_BROKEN 203 > > > > > > But it breaks the build. I don't get it. Just add a comment > > > indicating it shouldn't be used? That breaks the cross-tree > > > dependency chain and lets clk tree merge the clk driver part and arm-soc > merge the dts part. > > The device tree update also requires the update to clk-imx6q.c for > > proper run-time operation, so I don't see how these two parts can be > > separated. > > > > I thought about leaving the PLL4_AUDIO_DIV clock in place but turning > > it into a dummy (placeholder), but that might lead others down the > > long path I traversed before I found out that my manual was old and > > the clock didn't function. > > I'm not suggesting that it's left as a dummy forever, just until the other trees > can merge their parts of this series and so that these patches can be applied in > order that they're sent. Right now, the kbuild robot fails on this patch series > because this patch intentionally breaks the build. Please don't do that. Send > patch series that are bisectable so that the build doesn't break in the middle. A grep shows there're still many users of it. $ grep -rn IMX6QDL_CLK_PLL4_AUDIO_DIV arch/arm/boot/dts/*.dts* arch/arm/boot/dts/imx6q-cm-fx6.dts:451: <&clks IMX6QDL_CLK_PLL4_AUDIO_DIV>; arch/arm/boot/dts/imx6q-cm-fx6.dts:452: assigned-clock-parents = <&clks IMX6QDL_CLK_PLL4_AUDIO_DIV>; arch/arm/boot/dts/imx6qdl-sabreauto.dtsi:287: assigned-clock-parents = <&clks IMX6QDL_CLK_PLL4_AUDIO_DIV>; arch/arm/boot/dts/imx6qdl-sabreauto.dtsi.orig:127: assigned-clock-parents = <&clks IMX6QDL_CLK_PLL4_AUDIO_DIV>; arch/arm/boot/dts/imx6q-novena.dts:421: <&clks IMX6QDL_CLK_PLL4_AUDIO_DIV>, We probably need to fix those device trees first and then can mark it as BROKEN and remove from the driver support. Copy NXP audio guys to double check if the issue exists on the downstream tree as I saw the similar code there. Shengjiu, Can you help check it? Regards Dong Aisheng
