Quoting Dmitry Osipenko (2017-12-19 12:20:56) > On 19.12.2017 22:56, Michael Turquette wrote: > > Quoting Dmitry Osipenko (2017-12-18 19:59:06) > >> Machine dies if HCLK, SCLK or EMC is disabled, hence mark these clocks > >> as critical. Currently some of drivers do not manage clocks properly, > >> expecting clocks to be 'always enabled', these clocks are MC and PLL_P > >> outputs. Let's mark MC or PLL_P outputs as critical for now and revert > >> this change once drivers would be corrected. > > > > Are the drivers that do not manage their clocks correctly merged > > upstream? If so can we fix those drivers instead of marking clocks as > > critical? > > All the drivers are in upstream for a quite long time already. We should be > able > to correct them, but I haven't tried yet. > > > If not can we annotate the flags below with a comment stating to remove > > the critical clock flag once the consumer driver gets a clue? > I'll try to take a look at how much effort it would take to correct the > drivers > during the next few days and will send v3 with either the comment being added > or > 'always enabled' clocks being dropped from the patch.
Great, thanks for looking into it. Critical clocks are an easy-to-abuse feature and we should really be using the clk.h api as much as possible in place of the critical clocks mechanism. Best regards, Mike
