linux-kernel - RE: RE: RE: [PATCH v2 1/2] clk: divider: prepare for minimum divider

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]

Date:	Mon, 28 Jan 2013 09:18:08 +0000
From:	"Mohammed, Afzal" <afzal@...com>
To:	Mike Turquette <mturquette@...aro.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC:	Stephen Boyd <sboyd@...eaurora.org>
Subject: RE: RE: RE: [PATCH v2 1/2] clk: divider: prepare for minimum divider

Hi Mike,

On Sat, Jan 26, 2013 at 04:05:24, Mike Turquette wrote:

> Thank you for the information.  In short, the way you program your clock
> depend on the configuration of your lcdc device.
> 
> As such I am not sure the basic divider is the right choice for you.
> You might be better off creating a clock for your IP which takes into
> account these details.  Luckily it is possible to inherit from the basic
> clock types and create a new type.
> 
> An example of this is the MXS divider.  It uses the basic divider as a
> "parent class" and adds a busy bit.  This is a better approach than
> putting every feature into the basic divider type.  You can see how it
> was done in drivers/clk/mxs/clk-div.c
> 
> Let me know what you think.

Yes, a derived divider is better.

As mentioned in other thread, the modeling of clock nodes (derived plus
gates) would bring in considerable (relative to complete driver) code, the
advantage being higher pixel clock resolution. Current use cases work
as per existing divider setting in driver. Hence now it seems a better
decision now is to proceed with logic as in v2 (not using clock nodes).
And later depending on the use case requirement, clock tree modeling can
be implemented.

Thanks for your input.

Regards
Afzal