[PATCH v2 12/12] video: da8xx-fb: set upstream clock rate (if reqd)

[Mohammed, Afzal]

Hi Mike,

On Wed, Jan 16, 2013 at 10:32:10, Nori, Sekhar wrote:
> On 1/15/2013 9:02 PM, Mike Turquette wrote:
> > Quoting Afzal Mohammed (2013-01-15 05:44:36)

> >> Note:
> >> A better (if allowable) solution may be to represent clock divider in
> >> LCDC IP as a basic divider clock - the one defined in common clock
> >> framework. But for this to happen, all the platform's using this driver
> >> should be using common clock framework (DaVinci is yet to be converted
> >> to use common clock framework). And it has to be determined whether
> >> common clock framework allows this kind of a clock modelling inside a
> >> driver and for this to be part of clock tree. Advantage of doing so
> >> would be better resolution for pixel clock, even though without this
> >> existing use cases are working properly. Or another extreme alternative
> >> would be to replicate clk-divider of common clock framework inside the
> >> driver, but that probably is not preferred and not worth as it would be
> >> duplication and without much advantage to existing users.

> > Modeling the divider inside your IP block as a clock is supported in the
> > common clock framework.  Linking up these sorts of clocks to the clock
> > tree was one of the original design goals of CCF.

> > Regarding DaVinci: converting that platform over to use CCF would be the
> > best approach.

> This is work in progress. There are patches that have been posted. Work
> has been slow on this though due to lack of bandwidth.

> > An alternative would be that you could break
> > single-image boot for AM335x and DaVinci, by having AM335x use CCF and
> > DaVinci use the legacy clock framework.  From the LCDC driver's

> Single image for DaVinci and AM335x is not possible anyway since ARMv5
> and ARMv6+ cannot be supported in a single image.

> > perspective this should not matter and is indeed the purpose of the
> > clk.h api and clkdev interfaces, however looking at this driver I can
> > see there would still be a lot ifdef-ery going on... better to just
> > convert everything over to CCF.

> Waiting for DaVinci CCF to complete will be too long a wait. Probably
> convert to CCF just for AM335x ATM. There would be some ifdef'ry but
> hopefully that need not be inside function bodies. Would have to see the
> implementation, I guess.

v4 posted has the divider in LCDC IP modeled by clock node for CCF, for
non-CCF (DaVinci), existing logic is kept as is with the help of ifdef's
(as DaVinci maintainer mentioned that DaVinci CCF may take some time)

Regards
Afzal