On Tuesday, September 22, 2015 12:46:54 PM Viresh Kumar wrote: > On 19-09-15, 23:29, Scott Wood wrote: > > Get the CPU clock's potential parent clocks from the clock interface > > itself, rather than manually parsing the clocks property to find a > > phandle, looking at the clock-names property of that, and assuming that > > those are valid parent clocks for the cpu clock. > > > > This is necessary now that the clocks are generated based on the clock > > driver's knowledge of the chip rather than a fragile device-tree > > description of the mux options. > > > > We can now rely on the clock driver to ensure that the mux only exposes > > options that are valid. The cpufreq driver was currently being overly > > conservative in some cases -- for example, the "min_cpufreq = > > get_bus_freq()" restriction only applies to chips with erratum > > A-004510, and whether the freq_mask used on p5020 is needed depends on > > the actual frequencies of the PLLs (FWIW, p5040 has a similar > > limitation but its .freq_mask was zero) -- and the frequency mask > > mechanism made assumptions about particular parent clock indices that > > are no longer valid. > > > > Signed-off-by: Scott Wood <scottw...@freescale.com> > > --- > > v3: was patch 1/5 and patch 4/5, plus blacklist e6500 and changes > > to clk api usage > > > > drivers/cpufreq/qoriq-cpufreq.c | 137 > > ++++++++++++---------------------------- > > 1 file changed, 40 insertions(+), 97 deletions(-) > > Acked-by: Viresh Kumar <viresh.ku...@linaro.org>
I'm wondering who's supposed to be merging this set? Rafael _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev