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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <C8443D0743D26F4388EA172BF4E2A7A93EA9123E@DBDE01.ent.ti.com>
Date:	Wed, 23 Jan 2013 13:00:20 +0000
From:	"Mohammed, Afzal" <afzal@...com>
To:	"Nori, Sekhar" <nsekhar@...com>,
	Mike Turquette <mturquette@...aro.org>
CC:	Florian Tobias Schandinat <FlorianSchandinat@....de>,
	"Valkeinen, Tomi" <tomi.valkeinen@...com>,
	Grant Likely <grant.likely@...retlab.ca>,
	Rob Herring <rob.herring@...xeda.com>,
	Rob Landley <rob@...dley.net>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	"linux-fbdev@...r.kernel.org" <linux-fbdev@...r.kernel.org>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v2 12/12] video: da8xx-fb: set upstream clock rate (if
 reqd)

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