Re: [PATCH 0/5] Clocklib: generic clocks framework

[Dmitry <dbaryshkov@gmail.com>]

Hi,

2008/4/26 Russell King <rmk+lkml@arm.linux.org.uk>:
> On Fri, Apr 25, 2008 at 10:51:51PM +0200, Pavel Machek wrote:
>  > Hi!
>  >
>  > > > WTF? There are currently around 10 copies of clock code in the tree,
>  > > > every one slightly different. If this can help us get rid of all that
>  > > > crap, that's a GOOD THING, normative or not.
>  > >
>  > > At the expense of people going off and inventing their own APIs because
>  > > they find that the "normatived" clock API doesn't do what they need to?
>  >
>  > Just now, everyone just cuts&copies clock.c. I do not think "new"
>  > situation can worse than that.
>
>  That's certainly not what I've seen going on.  Each implementation is
>  customised to the needs of the SoC it's running on - OMAP has a complex
>  implementation, whereas simpler SoCs have a more simple implementation.
>
>  That's an entirely reasonable state of affairs - those who need complexity
>  are able to have it, whereas those who don't need complexity don't have
>  to be lumbered with it.
>
>  It's a long way from a "cut and copy" situation you're trying to suggest
>  it is.  Certainly on ARM, your viewpoint does not hold.

Actually it is "cut and copy". I once have examined all arm clock subsystems
and converted most of them (excluding OMAP, at91, maybe some others)
to the clocklib. There is more code duplication
that one would think. E.g. DaVinci clock.h contains a few flags
definitions, that
are totally unused by the code (most probably direct c&p from omap code).

I don't understand why do you give such strong oppression to these patches.
Simple systems (like sa1100) will be reduced just to few lines of code.
Mediocre (like pxa) will be again highly reduced in terms of size,
maintainability, etc.
And highly comliex (like omap) do already provide some type of framework
like clocklib.

-- 
With best wishes
Dmitry