Thread (16 messages) flat view 16 messages, 3 authors, 2013-01-23

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

From: Mohammed, Afzal <hidden>
Date: 2013-01-23 13:00:40
Also in: linux-fbdev, linux-omap, lkml

Hi Mike,

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

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help