RE: [PATCH v2 1/4] ARM: OMAP2+: dpll: round rate to closest value
Hi Paul,
On Fri, Jan 25, 2013 at 17:48:22, Mohammed, Afzal wrote:
On Fri, Jan 25, 2013 at 13:48:11, Paul Walmsley wrote:
like MPU CPUFreq. I'd suggest reverting
241d3a8dca239610d3d991bf58d4fe38c2d86fd5 or using a similar approach.
As you prefer reverting the above commit, I will proceed so, hmm.. got
This patch or reverting the above mentioned commit is not required for
lcdc to be usable on am335x, instead please consider for inclusion
patches 3 4 of this series,
ARM: OMAP2+: clock: DEFINE_STRUCT_CLK_FLAGS helper and
ARM: AM33XX: clock: SET_RATE_PARENT in lcd path
Patches 3 4 are required to have a functional frame buffer driver
on am335x, also it may help drm driver for the lcdc ip in am335x to
be a platform independent one.
Regards
Afzal
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: RE: [PATCH v2 1/4] ARM: OMAP2+: dpll: round rate to closest value
Hi Mike, On Sat, Jan 26, 2013 at 03:50:32, Mike Turquette wrote: Is MULT_ROUND_UP doing the right thing for you in the clk_divider code? What is the clock rate requested of the parent PLL? I just want to make sure that we're doing the right thing in the basic divider code. Actually MULT_ROUND_UP made my life difficult earlier, and finally came up with this solution instead of removing it. It was something like 6000 requested of PLL, for i = 1, but for other values, it was something like 6001, 6002 etc. Even if round rate rounds, I thought removing MULT_ROUND_UP would be ok, couldn't spend time to understand fully rational behind it, and as it was in generic code, kept away from doing it. Regards Afzal
RE: [PATCH v2 1/4] ARM: OMAP2+: dpll: round rate to closest value
Hi On Fri, 25 Jan 2013, Mohammed, Afzal wrote: On Fri, Jan 25, 2013 at 13:48:11, Paul Walmsley wrote: On Wed, 23 Jan 2013, Afzal Mohammed wrote: Currently round rate function would return proper rate iff requested rate exactly matches the PLL lockable rate. This causes set_rate to fail if exact rate could not be set. Instead round rate may return closest rate possible (less than the requested). And if any user is badly in need of exact rate, then return value of round rate could be used to decide whether to invoke set rate or not. Modify round rate so that it return closest possible rate. This doesn't look like the right approach to me. For some PLLs, an exact rate is desired. If exact rate is required, there is a way to achieve it as mentioned in the commit message, i.e. by first invoking round rate over reqd. rate and if it doesn't match, bail out w/o invoking set_rate. And it seems requirement of CCF w.r.t to round rate is to return closest possible rate. Hmm. Maybe I need to take a closer look. I'm a little worried that, since __clk_round_rate() can be called from omap3_noncore_dpll_set_rate(), we might wind up with inconsistent behavior. Effectively we'd need to mandate that clk_round_rate() would have to be called first for any DPLL where we'd expect to set an exact rate. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] ARM: OMAP2+: dpll: round rate to closest value
Hi On Wed, 23 Jan 2013, Afzal Mohammed wrote: Currently round rate function would return proper rate iff requested rate exactly matches the PLL lockable rate. This causes set_rate to fail if exact rate could not be set. Instead round rate may return closest rate possible (less than the requested). And if any user is badly in need of exact rate, then return value of round rate could be used to decide whether to invoke set rate or not. Modify round rate so that it return closest possible rate. This doesn't look like the right approach to me. For some PLLs, an exact rate is desired. We removed the rate tolerance code in commit 241d3a8dca239610d3d991bf58d4fe38c2d86fd5, but that was probably premature. We've encountered several situations now where we could really use it, like MPU CPUFreq. I'd suggest reverting 241d3a8dca239610d3d991bf58d4fe38c2d86fd5 or using a similar approach. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 1/4] ARM: OMAP2+: dpll: round rate to closest value
Hi Paul, On Fri, Jan 25, 2013 at 13:48:11, Paul Walmsley wrote: On Wed, 23 Jan 2013, Afzal Mohammed wrote: Currently round rate function would return proper rate iff requested rate exactly matches the PLL lockable rate. This causes set_rate to fail if exact rate could not be set. Instead round rate may return closest rate possible (less than the requested). And if any user is badly in need of exact rate, then return value of round rate could be used to decide whether to invoke set rate or not. Modify round rate so that it return closest possible rate. This doesn't look like the right approach to me. For some PLLs, an exact rate is desired. If exact rate is required, there is a way to achieve it as mentioned in the commit message, i.e. by first invoking round rate over reqd. rate and if it doesn't match, bail out w/o invoking set_rate. And it seems requirement of CCF w.r.t to round rate is to return closest possible rate. We removed the rate tolerance code in commit 241d3a8dca239610d3d991bf58d4fe38c2d86fd5, but that was probably premature. We've encountered several situations now where we could really use it, like MPU CPUFreq. I'd suggest reverting 241d3a8dca239610d3d991bf58d4fe38c2d86fd5 or using a similar approach. As you prefer reverting the above commit, I will proceed so, hmm.. got not so simple merge conflict, wish there was a command, git revert logical .. Regards Afzal
Re: RE: [PATCH v2 1/4] ARM: OMAP2+: dpll: round rate to closest value
Quoting Mohammed, Afzal (2013-01-25 04:18:22) Hi Paul, On Fri, Jan 25, 2013 at 13:48:11, Paul Walmsley wrote: On Wed, 23 Jan 2013, Afzal Mohammed wrote: Currently round rate function would return proper rate iff requested rate exactly matches the PLL lockable rate. This causes set_rate to fail if exact rate could not be set. Instead round rate may return closest rate possible (less than the requested). And if any user is badly in need of exact rate, then return value of round rate could be used to decide whether to invoke set rate or not. Modify round rate so that it return closest possible rate. This doesn't look like the right approach to me. For some PLLs, an exact rate is desired. If exact rate is required, there is a way to achieve it as mentioned in the commit message, i.e. by first invoking round rate over reqd. rate and if it doesn't match, bail out w/o invoking set_rate. And it seems requirement of CCF w.r.t to round rate is to return closest possible rate. Is MULT_ROUND_UP doing the right thing for you in the clk_divider code? What is the clock rate requested of the parent PLL? I just want to make sure that we're doing the right thing in the basic divider code. Thanks, Mike -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
