Message-ID: <20110418105442.GB27864@linux-sh.org>
Date:	Mon, 18 Apr 2011 19:54:42 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Nicolas Pitre <nicolas.pitre@...aro.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Jeremy Kerr <jeremy.kerr@...onical.com>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@....com>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	linux-sh@...r.kernel.org, Sascha Hauer <s.hauer@...gutronix.de>,
	lkml <linux-kernel@...r.kernel.org>,
	Dima Zavin <dmitriyz@...gle.com>,
	Saravana Kannan <skannan@...eaurora.org>,
	Ben Dooks <ben-linux@...ff.org>,
	Uwe Kleine-K?nig <u.kleine-koenig@...gutronix.de>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 0/2] Common struct clk implementation, v14

On Thu, Apr 14, 2011 at 04:38:14PM +0100, Russell King - ARM Linux wrote:
> On Thu, Apr 14, 2011 at 09:39:58AM -0400, Nicolas Pitre wrote:
> > However we can and must do better in consolidation work in order to make 
> > the tree more maintainable of course.  _That_ is the real issue and 
> > _that_ is what the ARM tree sucks at.  The fact that this consolidation 
> > work might reduce the size of the ARM code is only a side effect, not 
> > the primary goal.  So let's not get too hung up about LOC but focus on 
> > improving the infrastructure instead.
> 
> Look, this is what is in amongst the 6K lines of new code - these are
> the top two in the diffstat with the highest number of additional lines:
> 
>  arch/arm/mach-ux500/clock-db8500.c                 | 1291 +++++++++++++
>  arch/arm/mach-ux500/prcmu-db8500.c                 | 2018 ++++++++++++++++++++
> 
> These comprise 50% of the 6K of new code.  clock-db8500.c is a mixture
> of code and data declarations for individual clocks - which is essentially
> what Linus picked up with his complaint on under OMAP.  That in itself
> makes me worried.
> 
A common struct clk implementation will at least allow you to whittle
this number down a bit, but it's obviously not possible to attempt to
work with the generic infrastructure prior to it being merged. Given that
there is nothing ARM-specific about the patch series it doesn't much
matter which tree it ultimately gets merged through, so long as it's in
place for people to build on top of for the next merge window.

> Now, the next thing is that Linus hasn't been too happy about driver stuff
> coming via my tree either - it's something which has been the subject of
> concern in private email.  I've _already_ said something about that prior
> to the recent merge window.  So should I take the clk API stuff which
> touches the drivers subtree?  If yes, it needs to be kept entirely separate
> from the rest of the ARM stuff so we don't end up mixing drivers stuff with
> ARM stuff.

ARM has been the defacto owner for the clock bits to date, but between
clkdev and a common struct clk it's certainly possible to move to a clock
tree and treat it the same as any other subsystem. Moving things out of
arch/arm and in to more generic maintenance paths certainly reduces the
chance for abuse -- and also provides a path for driver stuff.

SH and ARM-based SH/R-Mobile CPUs already share a clock framework, which
I've slowly been refactoring in preparation for Jeremy's common struct
clk. With that merged I'll be able to kill off a couple hundred lines
from the existing implementation at least.

If you'd prefer not to be the guinea pig for the clock bits going in to
.40 I'm certainly happy to take them in a topic branch, convert my
platforms on top of that and send the bits off to Linus early in the
merge window.
--
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