On Thu, 2011-02-17 at 08:49 -0600, Paul Walmsley wrote: > On Wed, 16 Feb 2011, Raghuveer Murthy wrote: > <snip> > > > > DPLL_PER post divider output for DSS core functional clock can be changed in > > OMAP3xxx and OMAP4430, based on the requested pixel clock for a given display > > resolution. > > > > Additionally, the number of dividers available for DPLL_PER post dividors for > > DSS has increased from 16 to 32, from OMAP3630 onwards. > > > > Both these are added as dss_features. > > > > Given the above comments from Tomi, can the same be included as part of the > > clock framework? > > Have you considered just calling clk_round_rate() on the DPLL_PER's output > divider and seeing if you can get a rate that you're happy with? Hmm, yes, perhaps that would be possible. Currently we iterate suitable clocks by going through all fck dividers, then lck dividers and then pck dividers, and checking if one of the resulting pixel clocks is close to the required one. But we could start with the required pck, and go "up" from there with pck dividers, lck dividers, and in the end using clk_round_rate() to see if the set of dividers is possible. And we know the maximum allowed fck rate, so we can use that as a ceiling and forget any divider sets that lead to too high clocks. This will probably need a bit more iterations, though, as we may be trying multiple divider sets leading to the same fck rate, because the code doesn't have any idea what the possible rates are. I trust clk_round_rate() is quite simple function (ie. fast)? Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
