[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110210131308.GB1742@n2100.arm.linux.org.uk>
Date: Thu, 10 Feb 2011 13:13:08 +0000
From: Russell King - ARM Linux <linux@....linux.org.uk>
To: Richard Zhao <linuxzsc@...il.com>
Cc: Uwe Kleine-König
<u.kleine-koenig@...gutronix.de>,
Richard Zhao <richard.zhao@...escale.com>,
Nicolas Pitre <nicolas.pitre@...aro.org>,
Lorenzo Pieralisi <Lorenzo.Pieralisi@....com>,
Vincent Guittot <vincent.guittot@...aro.org>,
linux-sh@...r.kernel.org,
Ben Herrenschmidt <benh@...nel.crashing.org>,
Sascha Hauer <s.hauer@...gutronix.de>,
Paul Mundt <lethal@...ux-sh.org>, linux-kernel@...r.kernel.org,
Ryan Mallon <ryan@...ewatersys.com>,
Dima Zavin <dmitriyz@...gle.com>,
Saravana Kannan <skannan@...eaurora.org>,
Ben Dooks <ben-linux@...ff.org>,
Jeremy Kerr <jeremy.kerr@...onical.com>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC,PATCH 1/3] Add a common struct clk
On Thu, Feb 10, 2011 at 09:08:00PM +0800, Richard Zhao wrote:
> Why? what restriction will it cause to add parent in clk?
> Two benifits at least I can see:
> 1. null ops handle, as I said above.
> 2. export clock tree to user level for debug. It's very helpfull.
Don't be tempted to expand what's done at the generic level. Platforms
may need special handling at the current clock level before the parent
clock level is considered. Also platforms may not have parents so it
becomes mere bloat.
The more complicated the generic level becomes, the more platforms won't
covert to it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists