linux-kernel - RE: RE: RE: [PATCH v4 12/12] video: da8xx-fb: CCF clock divider handling

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: <C8443D0743D26F4388EA172BF4E2A7A93EA943E9@DBDE01.ent.ti.com>
Date:	Mon, 28 Jan 2013 09:17:19 +0000
From:	"Mohammed, Afzal" <afzal@...com>
To:	Mike Turquette <mturquette@...aro.org>,
	"linux-fbdev@...r.kernel.org" <linux-fbdev@...r.kernel.org>,
	"linux-omap@...r.kernel.org" <linux-omap@...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>
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>,
	"paul@...an.com" <paul@...an.com>,
	"Nayak, Rajendra" <rnayak@...com>,
	"Cousson, Benoit" <b-cousson@...com>
Subject: RE: RE: RE: [PATCH v4 12/12] video: da8xx-fb: CCF clock divider
 handling

Hi Mike,

On Sat, Jan 26, 2013 at 04:14:53, Mike Turquette wrote:

> I think Paul W. or someone on the TI side should weigh in on your clkdev
> entries.  My main point is that the actual tree should be modeled and
> clocks shouldn't be globbed together unnecessarily.  As mentioned in the
> other mail thread you might be better off making a divider for your LCDC
> IP block and modeling each node individually.

It seems complexity of driver would increase by creating a new inherited
divider clock and having a total 3-4 clock nodes. The advantage going
with it would be higher configurable resolution for pixel clock.
Current use cases work without higher pixel clock resolution.

And drm driver posted for the same IP is without CCF modeling.

So I will presently not model clock nodes in LCDC IP, later if use cases
badly require, this can be done (and if it happens, hopefully by that
DaVinci would be CCF'ed and it would be more clean to implement it).

Thanks for sharing your ideas.

Regards
Afzal