On 2019-09-17 7:32 PM, Stephen Boyd wrote: > Quoting Leonard Crestez (2019-09-16 16:03:53) >> On 2019-09-16 11:33 PM, Stephen Boyd wrote: >>> Quoting Leonard Crestez (2019-08-20 08:45:06) >>>> Dram frequency changes required modifying these clocks outside the >>>> control of clk framework. Mark them as CLK_GET_RATE_NOCACHE so that >>>> rates are always read back from registers. >>> >>> Why can't we control the clks from the clk framework? Please add that >>> information in the commit text here. >> >> OK, I will update commit message and comments >> >> These clocks are only modified for DRAM frequency switches during which >> DRAM is briefly inaccessible. The switch is performed with a SMC call to >> by TF-A which runs from a SRAM area. Upon returning to linux several >> clocks bits are modified and we need to update them. >> >> For rate bits an easy solution is to just mark with >> CLK_GET_RATE_NOCACHE, muxes are handled explicitly. > > Is there any reason to expose or control these clks from Linux then? It > might be easier to just make any children clks of the DRAM frequency clk > "root" clks and then ignore any frequency that they might have. > Similarly, because the SMC call is used to change the frequency, it may > be simpler to handle that completely outside of the clk framework (it > may already be this way in this patch series but I haven't read > everything here). The dram alt/apb clocks are real imx8m composite clocks with the same HW implementation as used for peripherals. They also have mux parents which are under the control of the clock framework so the freq switching code takes care to properly enable the new parents before calling SMC. See imx_ddrc_set_freq: https://patchwork.kernel.org/patch/11104145/ Removing dram alt/apb clocks from the tree would still require keeping possible parents enabled somehow. It wouldn't be simpler but a lot uglier. -- Regards, Leonard
