Common clock API for i.MX

Common clock API for i.MX

[Matt Sealey]

Hi Arnd/RMK/Sascha,

We're trying to bring up a good batch of drivers here for MX51 and
EfikaMX systems and noticed that the released 3.2 kernel doesn't
include the common clock stuff that all the other platforms seem to be
using. In order to get things tested on a stable kernel before we leap
ahead, especially for Sascha's IPU code and in general platform
independence for any code using the clock API (by that I mean I don't
want to have to hack #include <mach/clock.h> in anything if I can help
it) I kind of need the newbies guide to where the clock code
tree/branch actually lives and more specifically is there a minimal
patchset I should be looking at rather than merging down a development
tree on top of our kernel?

The last discussion I saw on this was April last year, and now things
are moving to mach-imx this is starting to get a little complicated,
there's a lot of disjointed history to walk through. Any advise on
what to do and where to look would be invaluable. Is the patchset from
April (which starts here from the cleanest tree I can find;
http://git.pengutronix.de/?p=imx/linux-2.6.git;a=commit;h=32c99207d4231ae4f807866b29bbfd0415087400)
still valid or is there somewhere better I should be looking?

-- 
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.

Common clock API for i.MX

[Russell King - ARM Linux]

On Tue, Jan 24, 2012 at 07:54:08PM -0600, Matt Sealey wrote:
> Hi Arnd/RMK/Sascha,
> 
> We're trying to bring up a good batch of drivers here for MX51 and
> EfikaMX systems and noticed that the released 3.2 kernel doesn't
> include the common clock stuff that all the other platforms seem to be
> using.

As far as I know, it still isn't ready (if it was, surely it would've
been merged?)

Grepping for clk_prepare() it looks like very few people have converted
over to this - it's just the AMBA stuff, a few bits of OMAP and MXS.
So even if the common clock stuff comes in, almost nothing will be able
to use it:

arch/arm/common/sa1111.c
arch/arm/common/timer-sp.c
arch/arm/mach-omap2/clock2xxx.c
arch/arm/mach-omap2/clock.h
arch/arm/mach-omap2/prcm.c
arch/arm/mach-omap2/clock2430_data.c
arch/arm/mach-omap2/clock2xxx.h
arch/arm/mach-omap2/clock2420_data.c
arch/arm/mach-mxs/clock-mx23.c
arch/arm/mach-mxs/clock.c
arch/arm/mach-mxs/timer.c
arch/arm/mach-mxs/system.c
arch/arm/mach-mxs/clock-mx28.c
arch/arm/mach-mxs/mach-mx28evk.c
arch/arm/kernel/smp_twd.c
drivers/gpio/gpio-pxa.c
drivers/tty/serial/amba-pl011.c
drivers/tty/serial/mxs-auart.c
drivers/tty/serial/amba-pl010.c
drivers/amba/bus.c
drivers/net/ethernet/freescale/fec.c
drivers/net/can/flexcan.c
drivers/video/omap2/dss/dsi.c
drivers/video/amba-clcd.c
drivers/video/mxsfb.c
drivers/staging/tidspbridge/include/dspbridge/clk.h
drivers/staging/tidspbridge/core/dsp-clock.c
drivers/spi/spi-pl022.c
drivers/mmc/host/mmci.c
drivers/mmc/host/mxs-mmc.c
drivers/dma/mxs-dma.c
drivers/mtd/nand/gpmi-nand/gpmi-lib.c

My conclusion, therefore, is that there's very little actual interest
amongst the ARM community to move towards a common clk API.

I'm rather disappointed by that, and have been wondering for some time
why I wasted my time over the clk_prepare() stuff, and wondering why the
hell I bothered putting it in mainline.  I must have been under the
mistaken impression that this is something people wanted.  Obviously not.

There's a good saying here: actions speak louder than words.  The action
here is the lack of patches from platform maintainers.  That definitely
shouts.

As a result of the lack of motivation by others over this, I've lost
interest in it.  Sorry.

Common clock API for i.MX

[Matt Sealey]

On Wed, Jan 25, 2012 at 2:45 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Jan 24, 2012 at 07:54:08PM -0600, Matt Sealey wrote:
>> Hi Arnd/RMK/Sascha,
>>
>> We're trying to bring up a good batch of drivers here for MX51 and
>> EfikaMX systems and noticed that the released 3.2 kernel doesn't
>> include the common clock stuff that all the other platforms seem to be
>> using.
>
> As far as I know, it still isn't ready (if it was, surely it would've
> been merged?)
>
> Grepping for clk_prepare() it looks like very few people have converted
> over to this - it's just the AMBA stuff, a few bits of OMAP and MXS.
> So even if the common clock stuff comes in, almost nothing will be able
> to use it:
>
> arch/arm/common/sa1111.c
> arch/arm/common/timer-sp.c
> arch/arm/mach-omap2/clock2xxx.c
> arch/arm/mach-omap2/clock.h
> arch/arm/mach-omap2/prcm.c
> arch/arm/mach-omap2/clock2430_data.c
> arch/arm/mach-omap2/clock2xxx.h
> arch/arm/mach-omap2/clock2420_data.c
> arch/arm/mach-mxs/clock-mx23.c
> arch/arm/mach-mxs/clock.c
> arch/arm/mach-mxs/timer.c
> arch/arm/mach-mxs/system.c
> arch/arm/mach-mxs/clock-mx28.c
> arch/arm/mach-mxs/mach-mx28evk.c
> arch/arm/kernel/smp_twd.c
> drivers/gpio/gpio-pxa.c
> drivers/tty/serial/amba-pl011.c
> drivers/tty/serial/mxs-auart.c
> drivers/tty/serial/amba-pl010.c
> drivers/amba/bus.c
> drivers/net/ethernet/freescale/fec.c
> drivers/net/can/flexcan.c
> drivers/video/omap2/dss/dsi.c
> drivers/video/amba-clcd.c
> drivers/video/mxsfb.c
> drivers/staging/tidspbridge/include/dspbridge/clk.h
> drivers/staging/tidspbridge/core/dsp-clock.c
> drivers/spi/spi-pl022.c
> drivers/mmc/host/mmci.c
> drivers/mmc/host/mxs-mmc.c
> drivers/dma/mxs-dma.c
> drivers/mtd/nand/gpmi-nand/gpmi-lib.c
>
> My conclusion, therefore, is that there's very little actual interest
> amongst the ARM community to move towards a common clk API.

Maybe it's a chicken-egg thing; nobody wants to work on it until someone else
has done some legwork? :)

> I'm rather disappointed by that, and have been wondering for some time
> why I wasted my time over the clk_prepare() stuff, and wondering why the
> hell I bothered putting it in mainline. ?I must have been under the
> mistaken impression that this is something people wanted. ?Obviously not.

I'm under the impression that it's important, the fact that Jeremy's
initial patch
puts over (~21 different struct clk definitions) is reason enough to make it
work. What I'm curious about now is what made it "not ready"? Especially if
MXS is using it but not the bigger i.MX chips?

I always get a bit nervous, even when writing platform-specific code, when I
have to include something from mach/ that doesn't seem in particular specific
to that machine. If you need an interrupt definition or some registers it's all
well and good, but for the clock API (which is common.. just different
implementations) I have a hard time working out how this driver would even
work in a kernel image that contained support for multiple SoC's - this was
the big goal Canonical/Linaro were working towards wasn't it? If in a driver I
include <mach/clock.h> and the kernel is OMAP+MX51, who knows who's
clock stuff I am including? It just shouldn't be that way... Linus said that
much, for every duplication that stays in there it digs a hole for ARM as one
of the messier trees..

> As a result of the lack of motivation by others over this, I've lost
> interest in it. ?Sorry.

Can I drum up some interest here? Guys, what's going on? Who was
ultimately responsible for the code/concept?

-- 
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.

Common clock API for i.MX

[Russell King - ARM Linux]

On Wed, Jan 25, 2012 at 07:45:15AM -0600, Matt Sealey wrote:
> On Wed, Jan 25, 2012 at 2:45 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Tue, Jan 24, 2012 at 07:54:08PM -0600, Matt Sealey wrote:
> >> Hi Arnd/RMK/Sascha,
> >>
> >> We're trying to bring up a good batch of drivers here for MX51 and
> >> EfikaMX systems and noticed that the released 3.2 kernel doesn't
> >> include the common clock stuff that all the other platforms seem to be
> >> using.
> >
> > As far as I know, it still isn't ready (if it was, surely it would've
> > been merged?)
> >
> > Grepping for clk_prepare() it looks like very few people have converted
> > over to this - it's just the AMBA stuff, a few bits of OMAP and MXS.
> > So even if the common clock stuff comes in, almost nothing will be able
> > to use it:
> >
> > arch/arm/common/sa1111.c
> > arch/arm/common/timer-sp.c
> > arch/arm/mach-omap2/clock2xxx.c
> > arch/arm/mach-omap2/clock.h
> > arch/arm/mach-omap2/prcm.c
> > arch/arm/mach-omap2/clock2430_data.c
> > arch/arm/mach-omap2/clock2xxx.h
> > arch/arm/mach-omap2/clock2420_data.c
> > arch/arm/mach-mxs/clock-mx23.c
> > arch/arm/mach-mxs/clock.c
> > arch/arm/mach-mxs/timer.c
> > arch/arm/mach-mxs/system.c
> > arch/arm/mach-mxs/clock-mx28.c
> > arch/arm/mach-mxs/mach-mx28evk.c
> > arch/arm/kernel/smp_twd.c
> > drivers/gpio/gpio-pxa.c
> > drivers/tty/serial/amba-pl011.c
> > drivers/tty/serial/mxs-auart.c
> > drivers/tty/serial/amba-pl010.c
> > drivers/amba/bus.c
> > drivers/net/ethernet/freescale/fec.c
> > drivers/net/can/flexcan.c
> > drivers/video/omap2/dss/dsi.c
> > drivers/video/amba-clcd.c
> > drivers/video/mxsfb.c
> > drivers/staging/tidspbridge/include/dspbridge/clk.h
> > drivers/staging/tidspbridge/core/dsp-clock.c
> > drivers/spi/spi-pl022.c
> > drivers/mmc/host/mmci.c
> > drivers/mmc/host/mxs-mmc.c
> > drivers/dma/mxs-dma.c
> > drivers/mtd/nand/gpmi-nand/gpmi-lib.c
> >
> > My conclusion, therefore, is that there's very little actual interest
> > amongst the ARM community to move towards a common clk API.
> 
> Maybe it's a chicken-egg thing; nobody wants to work on it until someone else
> has done some legwork? :)

That was the precise problem which clk_prepare() was meant to solve.
Precisely nothing was happening in terms of mainline with all the
discussions going around in circles.

We managed to settle on how to solve the problem where some platforms
want different characteristics from clk_enable(), and nothing happened.
The discussion kept going around in circles.

The whole point of getting clk_prepare() in early was to avoid a big-bang
day where everything had to be converted in one big step when a platform
decides to use the common API.

We know _definitely_ that a common API is going to need clk_prepare(),
which is why I invested time into kicking that off.  Given the lack of
uptake of it, I don't know why I bothered - I don't even know why I
bothered getting involved in the totally useless discussions first time
around.  It's just been a complete and utter waste of my time.

Like many things in the ARM community, trying to motivate people is an
impossibility.  It can be seen time and time again.  Like the restart
changes.

It's times like this I don't know why I bother.  That's why I've been
hacking on the old SA11x0 platforms since Christmas.  At least I don't
have to deal with trying to get concensus between arguing factions
which _never_ makes progress even when there's agreement.  I don't have
to bother with kicking people to get them to update their own hairy code.
With obsolete hardware there _aren't_ any factions to kick together to
agree.

As I said, I've lost interest in the common clk API.  Totally.  Completely.
I really don't care so long as it doesn't create difficulties for me and
the platforms I care about.  That's all I'm going to care about over the
common clk API in future.  Not whether it solves other peoples problems.
Call me selfish, but I think it's one of the times I'm justified to be
given how much work I've tried to put in to that area.

Common clock API for i.MX

[Sylwester Nawrocki]

On 01/25/2012 03:44 PM, Russell King - ARM Linux wrote:
> On Wed, Jan 25, 2012 at 07:45:15AM -0600, Matt Sealey wrote:
>> On Wed, Jan 25, 2012 at 2:45 AM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk>  wrote:
>>> On Tue, Jan 24, 2012 at 07:54:08PM -0600, Matt Sealey wrote:
>>>> Hi Arnd/RMK/Sascha,
>>>>
>>>> We're trying to bring up a good batch of drivers here for MX51 and
>>>> EfikaMX systems and noticed that the released 3.2 kernel doesn't
>>>> include the common clock stuff that all the other platforms seem to be
>>>> using.
>>>
>>> As far as I know, it still isn't ready (if it was, surely it would've
>>> been merged?)
>>>
>>> Grepping for clk_prepare() it looks like very few people have converted
>>> over to this - it's just the AMBA stuff, a few bits of OMAP and MXS.
>>> So even if the common clock stuff comes in, almost nothing will be able
>>> to use it:
>>>
>>> arch/arm/common/sa1111.c
>>> arch/arm/common/timer-sp.c
>>> arch/arm/mach-omap2/clock2xxx.c
>>> arch/arm/mach-omap2/clock.h
>>> arch/arm/mach-omap2/prcm.c
>>> arch/arm/mach-omap2/clock2430_data.c
>>> arch/arm/mach-omap2/clock2xxx.h
>>> arch/arm/mach-omap2/clock2420_data.c
>>> arch/arm/mach-mxs/clock-mx23.c
>>> arch/arm/mach-mxs/clock.c
>>> arch/arm/mach-mxs/timer.c
>>> arch/arm/mach-mxs/system.c
>>> arch/arm/mach-mxs/clock-mx28.c
>>> arch/arm/mach-mxs/mach-mx28evk.c
>>> arch/arm/kernel/smp_twd.c
>>> drivers/gpio/gpio-pxa.c
>>> drivers/tty/serial/amba-pl011.c
>>> drivers/tty/serial/mxs-auart.c
>>> drivers/tty/serial/amba-pl010.c
>>> drivers/amba/bus.c
>>> drivers/net/ethernet/freescale/fec.c
>>> drivers/net/can/flexcan.c
>>> drivers/video/omap2/dss/dsi.c
>>> drivers/video/amba-clcd.c
>>> drivers/video/mxsfb.c
>>> drivers/staging/tidspbridge/include/dspbridge/clk.h
>>> drivers/staging/tidspbridge/core/dsp-clock.c
>>> drivers/spi/spi-pl022.c
>>> drivers/mmc/host/mmci.c
>>> drivers/mmc/host/mxs-mmc.c
>>> drivers/dma/mxs-dma.c
>>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c
>>>
>>> My conclusion, therefore, is that there's very little actual interest
>>> amongst the ARM community to move towards a common clk API.
>>
>> Maybe it's a chicken-egg thing; nobody wants to work on it until someone else
>> has done some legwork? :)
> 
> That was the precise problem which clk_prepare() was meant to solve.
> Precisely nothing was happening in terms of mainline with all the
> discussions going around in circles.

There are some pending V4L API developments depending on common struct clk,
required for sub-device drivers reuse and needed for works on DT support.
Unfortunately none of the media drivers is converted to clk_prepare yet.
This is where clock APIs are used (drivers/media/):

video/atmel-isi.c
video/davinci/dm355_ccdc.c
video/davinci/dm644x_ccdc.c
video/davinci/isif.c
video/davinci/vpbe.c
video/fsl-viu.c
video/mx1_camera.c
video/mx2_camera.c
video/mx3_camera.c
video/omap1_camera.c
video/omap24xxcam.c
video/omap3isp/isp.c
video/omap3isp/ispvideo.c
video/pxa_camera.c
video/s5p-fimc/fimc-core.c
video/s5p-fimc/fimc-mdevice.c
video/s5p-fimc/mipi-csis.c
video/s5p-mfc/s5p_mfc_pm.c
video/s5p-tv/hdmi_drv.c
video/s5p-tv/mixer_drv.c
video/s5p-tv/sdo_drv.c

Seems like people are unaware the clk_prepare support is needed first.
So let's convert these modules now, rather than waiting for the common
struct clk conversion to magically happen. As it is really needed and 
the efforts seem insignificant, at least for drivers/media/.

 
> We managed to settle on how to solve the problem where some platforms
> want different characteristics from clk_enable(), and nothing happened.
> The discussion kept going around in circles.
> 
> The whole point of getting clk_prepare() in early was to avoid a big-bang
> day where everything had to be converted in one big step when a platform
> decides to use the common API.
> 
> We know _definitely_ that a common API is going to need clk_prepare(),
> which is why I invested time into kicking that off.  Given the lack of
> uptake of it, I don't know why I bothered - I don't even know why I
> bothered getting involved in the totally useless discussions first time
> around.  It's just been a complete and utter waste of my time.
> 
> Like many things in the ARM community, trying to motivate people is an
> impossibility.  It can be seen time and time again.  Like the restart
> changes.
> 
> It's times like this I don't know why I bother.  That's why I've been
> hacking on the old SA11x0 platforms since Christmas.  At least I don't
> have to deal with trying to get concensus between arguing factions
> which _never_ makes progress even when there's agreement.  I don't have
> to bother with kicking people to get them to update their own hairy code.
> With obsolete hardware there _aren't_ any factions to kick together to
> agree.
> 
> As I said, I've lost interest in the common clk API.  Totally.  Completely.
> I really don't care so long as it doesn't create difficulties for me and
> the platforms I care about.  That's all I'm going to care about over the
> common clk API in future.  Not whether it solves other peoples problems.
> Call me selfish, but I think it's one of the times I'm justified to be
> given how much work I've tried to put in to that area.

--

Thanks,
Sylwester

Common clock API for i.MX

[Mark Brown]

On Wed, Jan 25, 2012 at 07:45:15AM -0600, Matt Sealey wrote:
> On Wed, Jan 25, 2012 at 2:45 AM, Russell King - ARM Linux

> > My conclusion, therefore, is that there's very little actual interest
> > amongst the ARM community to move towards a common clk API.

> Maybe it's a chicken-egg thing; nobody wants to work on it until someone else
> has done some legwork? :)

I do think that this is a big part of the issue, the patches have been
floating around for ages and it's not clear when they'll manage to make
it in (and hence when it'll be worth moving to use them).

> > As a result of the lack of motivation by others over this, I've lost
> > interest in it. ?Sorry.

> Can I drum up some interest here? Guys, what's going on? Who was
> ultimately responsible for the code/concept?

Mike Turquette has been driving this for the past while.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120125/01b3dd62/attachment.sig>

Common clock API for i.MX

[Nicolas Pitre]

On Wed, 25 Jan 2012, Mark Brown wrote:

> On Wed, Jan 25, 2012 at 07:45:15AM -0600, Matt Sealey wrote:
> > On Wed, Jan 25, 2012 at 2:45 AM, Russell King - ARM Linux
> 
> > > My conclusion, therefore, is that there's very little actual interest
> > > amongst the ARM community to move towards a common clk API.
> 
> > Maybe it's a chicken-egg thing; nobody wants to work on it until someone else
> > has done some legwork? :)
> 
> I do think that this is a big part of the issue, the patches have been
> floating around for ages and it's not clear when they'll manage to make
> it in (and hence when it'll be worth moving to use them).

Maybe because nobody is actively promoting them and pushing them 
forward?  It is not sufficient to just post patches to a mailing list 
and wait.


Nicolas

Common clock API for i.MX

[Mark Brown]

On Wed, Jan 25, 2012 at 10:42:20AM -0500, Nicolas Pitre wrote:
> On Wed, 25 Jan 2012, Mark Brown wrote:

> > I do think that this is a big part of the issue, the patches have been
> > floating around for ages and it's not clear when they'll manage to make
> > it in (and hence when it'll be worth moving to use them).

> Maybe because nobody is actively promoting them and pushing them 
> forward?  It is not sufficient to just post patches to a mailing list 
> and wait.

Yeah, it's a chicken and egg situation - it seems very difficult for
them to get integrated so few people are spending much time on them
which means it's not obvious that there's a pressing need for them :(
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120125/3677c32e/attachment.sig>

Common clock API for i.MX

[Shawn Guo]

On Wed, Jan 25, 2012 at 08:45:33AM +0000, Russell King - ARM Linux wrote:
> Grepping for clk_prepare() it looks like very few people have converted
> over to this - it's just the AMBA stuff, a few bits of OMAP and MXS.

Sascha queued up some of IMX clk_prepare() bits from Richard Zhao on
branch below.

http://git.pengutronix.de/?p=imx/linux-2.6.git;a=shortlog;h=refs/heads/imx-features

Sascha, what's the plan of mainlining them?  I thought you could have
sent them during 3.3 merge window.  But you did not.

-- 
Regards,
Shawn

Common clock API for i.MX

[Sascha Hauer]

On Thu, Jan 26, 2012 at 02:20:05PM +0800, Shawn Guo wrote:
> On Wed, Jan 25, 2012 at 08:45:33AM +0000, Russell King - ARM Linux wrote:
> > Grepping for clk_prepare() it looks like very few people have converted
> > over to this - it's just the AMBA stuff, a few bits of OMAP and MXS.
> 
> Sascha queued up some of IMX clk_prepare() bits from Richard Zhao on
> branch below.
> 
> http://git.pengutronix.de/?p=imx/linux-2.6.git;a=shortlog;h=refs/heads/imx-features
> 
> Sascha, what's the plan of mainlining them?  I thought you could have
> sent them during 3.3 merge window.  But you did not.

Grmpf. Seems I have missed the patches. My bad. I will see if they
still merge and send a pull request tomorrow.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Common clock API for i.MX

[Saravana Kannan]

On 01/25/2012 12:45 AM, Russell King - ARM Linux wrote:
>
> My conclusion, therefore, is that there's very little actual interest
> amongst the ARM community to move towards a common clk API.

MSM is most certainly interested.

> I'm rather disappointed by that, and have been wondering for some time
> why I wasted my time over the clk_prepare() stuff, and wondering why the
> hell I bothered putting it in mainline.  I must have been under the
> mistaken impression that this is something people wanted.  Obviously not.

The time you spent on this certainly wasn't a waste. Once it got into 
the mainline, we already back ported the stubs into our kernel tree. I 
have already laid out a plan to migrate of all MSM drivers to the new 
APIs and it's work in progress. Some drivers devs are already working on it.

Unfortunately, the fact that not all the MSM drivers are already merged 
onto the mailine is a separate issue that I don't have much control 
over. So, the interest for these APIs aren't easily visible to you.

> There's a good saying here: actions speak louder than words.  The action
> here is the lack of patches from platform maintainers.  That definitely
> shouts.

You are welcome to look at our kernel tree for proof of interest. I know 
internal trees aren't of much relevance to you, but you can take that as 
a precursor of what to expect when changes get pushed upstream.

> As a result of the lack of motivation by others over this, I've lost
> interest in it.  Sorry.
Hopefully, this email is of some help in restoring your interest.

Thanks,
Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Common clock API for i.MX

[Shawn Guo]

On Tue, Jan 24, 2012 at 07:54:08PM -0600, Matt Sealey wrote:
> Hi Arnd/RMK/Sascha,
> 
> We're trying to bring up a good batch of drivers here for MX51 and
> EfikaMX systems and noticed that the released 3.2 kernel doesn't
> include the common clock stuff that all the other platforms seem to be
> using. In order to get things tested on a stable kernel before we leap
> ahead, especially for Sascha's IPU code and in general platform
> independence for any code using the clock API (by that I mean I don't
> want to have to hack #include <mach/clock.h> in anything if I can help
> it) I kind of need the newbies guide to where the clock code
> tree/branch actually lives and more specifically is there a minimal
> patchset I should be looking at rather than merging down a development
> tree on top of our kernel?
> 
> The last discussion I saw on this was April last year, and now things
> are moving to mach-imx this is starting to get a little complicated,
> there's a lot of disjointed history to walk through. Any advise on
> what to do and where to look would be invaluable. Is the patchset from
> April (which starts here from the cleanest tree I can find;
> http://git.pengutronix.de/?p=imx/linux-2.6.git;a=commit;h=32c99207d4231ae4f807866b29bbfd0415087400)
> still valid or is there somewhere better I should be looking?
> 
Mike Turquette picked up the work several months ago, and has posted
4 versions since then.  The following branch has the latest version.

http://git.linaro.org/gitweb?p=people/mturquette/linux.git;a=shortlog;h=refs/heads/v3.2-rc5-clkv4

Richard Zhao has been closely tracking the work to have imx5 clock
migrated to it.  And the latest code can be found on the branch below.

http://git.linaro.org/gitweb?p=people/riczhao/linux-2.6.git;a=shortlog;h=refs/heads/v3.2-rc5-clkv4

-- 
Regards,
Shawn