OMAP clock fast-forward: an introduction to six series

OMAP clock fast-forward: an introduction to six series

[Paul Walmsley]

Hello,

This set of six patch series brings mainline Linux up-to-date with the 
current state of the clock framework in the linux-omap tree.  The patches 
have received extensive testing by OMAP users on the linux-omap mailing 
list, linux-omap@vger.kernel.org.  Current-generation OMAP dev boards 
include the BeagleBoard <http://www.beagleboard.org/> and the Gumstix 
Overo <http://www.gumstix.com/>.

The oldest of the source patches dates back to June 2008.  It's not clear 
to me why the upstream merge process for these patches has been so 
difficult.  I hope that, going forward, upstream merges for OMAP patches 
can keep up with the pace of development on linux-omap, so this type of 
massive merge is unnecessary.

Per rmk's preferences, some patches have been 'compressed.' That is, some 
fix patches have been rolled into a single patch with the original.  To 
ease cross-referencing with the linux-omap git tree, original commit IDs 
have been inserted into the patch messages.  Also, what would have been an 
extremely long series has been split into six smaller, cumulative, roughly 
thematic patch series.  If requested, I would be pleased to simply send 
one large series of the original, uncompressed patches.  Thanks to the git 
and stgit authors and contributors: without those tools, this process 
would have been nearly impossible.

Each series has been compile-tested for 5912 OSK (OMAP1), H4 and 2430SDP 
(OMAP2), and BeagleBoard (OMAP3), and boot-tested on 2430SDP and Beagle.
After the sixth series, the diff with the linux-omap tree for the files 
listed below is minimal.


regards,

- Paul


manifest:

[PATCH A 00/10] OMAP clock, A of F: preliminaries
[PATCH B 00/10] OMAP clock, B of F: clockdomain, powerdomain updates
[PATCH C 00/13] OMAP clock, C of F: DPLL updates
[PATCH D 00/11] OMAP clock, D of F: clock code cleanup
[PATCH E 00/14] OMAP clock, E of F: SDRAM fixes, clock optimization
[PATCH F 00/12] OMAP clock, F of F: more clock cleanup

diffstat (post-compression; pre-compression stats are larger):

 arch/arm/mach-omap1/clock.c                   |  168 -                              
 arch/arm/mach-omap1/clock.h                   |  136 -                              
 arch/arm/mach-omap2/Makefile                  |    8                                
 arch/arm/mach-omap2/board-2430sdp.c           |    2                                
 arch/arm/mach-omap2/board-apollon.c           |    2                                
 arch/arm/mach-omap2/board-generic.c           |    2
 arch/arm/mach-omap2/board-h4.c                |    2
 arch/arm/mach-omap2/board-ldp.c               |    2
 arch/arm/mach-omap2/board-omap3beagle.c       |    2
 arch/arm/mach-omap2/clock.c                   |  786 ++++----
 arch/arm/mach-omap2/clock.h                   |   30
 arch/arm/mach-omap2/clock24xx.c               |  409 ++--
 arch/arm/mach-omap2/clock24xx.h               | 1395 ++++++++------
 arch/arm/mach-omap2/clock34xx.c               |  399 +++-
 arch/arm/mach-omap2/clock34xx.h               | 2509 ++++++++++++++------------
 arch/arm/mach-omap2/clockdomain.c             |   66
 arch/arm/mach-omap2/clockdomains.h            |  132 -
 arch/arm/mach-omap2/cm-regbits-24xx.h         |   81
 arch/arm/mach-omap2/cm-regbits-34xx.h         |  121 -
 arch/arm/mach-omap2/cm.h                      |   20
 arch/arm/mach-omap2/io.c                      |   10
 arch/arm/mach-omap2/mcbsp.c                   |    5
 arch/arm/mach-omap2/memory.c                  |   14
 arch/arm/mach-omap2/memory.h                  |   43
 arch/arm/mach-omap2/pm.c                      |    2
 arch/arm/mach-omap2/powerdomains.h            |    8
 arch/arm/mach-omap2/powerdomains34xx.h        |   63
 arch/arm/mach-omap2/prcm-common.h             |  198 +-
 arch/arm/mach-omap2/prm-regbits-34xx.h        |    9
 arch/arm/mach-omap2/prm.h                     |  166 -
 arch/arm/mach-omap2/sdrc.c                    |   95
 arch/arm/mach-omap2/sdrc2xxx.c                |   83
 arch/arm/mach-omap2/sram242x.S                |    5
 arch/arm/mach-omap2/sram243x.S                |    5
 arch/arm/plat-omap/clock.c                    |  366 ++-
 arch/arm/plat-omap/common.c                   |    4
 arch/arm/plat-omap/cpu-omap.c                 |   57
 arch/arm/plat-omap/include/mach/clock.h       |  178 -
 arch/arm/plat-omap/include/mach/clockdomain.h |   24
 arch/arm/plat-omap/include/mach/common.h      |    7
 arch/arm/plat-omap/include/mach/gpmc.h        |    2
 arch/arm/plat-omap/include/mach/io.h          |    4
 arch/arm/plat-omap/include/mach/powerdomain.h |    5
 arch/arm/plat-omap/include/mach/prcm.h        |    5
 arch/arm/plat-omap/include/mach/sdrc.h        |   82
 arch/arm/plat-omap/include/mach/system.h      |    4
 46 files changed, 4641 insertions(+), 3075 deletions(-)

Re: OMAP clock fast-forward: an introduction to six series

[Russell King - ARM Linux]

On Wed, Jan 28, 2009 at 01:22:22PM -0700, Paul Walmsley wrote:
> Per rmk's preferences, some patches have been 'compressed.' That is, some 
> fix patches have been rolled into a single patch with the original.  To 
> ease cross-referencing with the linux-omap git tree, original commit IDs 
> have been inserted into the patch messages.  Also, what would have been an 
> extremely long series has been split into six smaller, cumulative, roughly 
> thematic patch series.  If requested, I would be pleased to simply send 
> one large series of the original, uncompressed patches.  Thanks to the git 
> and stgit authors and contributors: without those tools, this process 
> would have been nearly impossible.

Since this patch series was only really meant for me to do some follow-on
work on it (to merge it into my tree) is it really necessary to submit
this 70 patch series via slow email via several mailing lists?

At the rate they're coming through I might have the entire set by
midnight...

Re: OMAP clock fast-forward: an introduction to six series

[Paul Walmsley]

Hello Russell,

On Wed, 28 Jan 2009, Russell King - ARM Linux wrote:

> On Wed, Jan 28, 2009 at 01:22:22PM -0700, Paul Walmsley wrote:
> > Per rmk's preferences, some patches have been 'compressed.' That is, some 
> > fix patches have been rolled into a single patch with the original.  To 
> > ease cross-referencing with the linux-omap git tree, original commit IDs 
> > have been inserted into the patch messages.  Also, what would have been an 
> > extremely long series has been split into six smaller, cumulative, roughly 
> > thematic patch series.  If requested, I would be pleased to simply send 
> > one large series of the original, uncompressed patches.  Thanks to the git 
> > and stgit authors and contributors: without those tools, this process 
> > would have been nearly impossible.
> 
> Since this patch series was only really meant for me to do some follow-on
> work on it (to merge it into my tree) is it really necessary to submit
> this 70 patch series via slow email via several mailing lists?

I posted the patches for final review and upstream merging.

Not sure what the follow-on work is that you mention.  But if it's 
additional development work, such as modifying the linux-omap clock code 
to use your recent clkdev code, that should really be discussed 
separately, and patches posted for comment to linux-omap, so the OMAP 
community has a chance to test it first.  People on that list seem to be 
pretty reasonable...

regards,

- Paul

Re: OMAP clock fast-forward: an introduction to six series

[Russell King - ARM Linux]

On Thu, Jan 29, 2009 at 12:05:13AM -0700, Paul Walmsley wrote:
> Hello Russell,
> 
> On Wed, 28 Jan 2009, Russell King - ARM Linux wrote:
> 
> > On Wed, Jan 28, 2009 at 01:22:22PM -0700, Paul Walmsley wrote:
> > > Per rmk's preferences, some patches have been 'compressed.' That is, some 
> > > fix patches have been rolled into a single patch with the original.  To 
> > > ease cross-referencing with the linux-omap git tree, original commit IDs 
> > > have been inserted into the patch messages.  Also, what would have been an 
> > > extremely long series has been split into six smaller, cumulative, roughly 
> > > thematic patch series.  If requested, I would be pleased to simply send 
> > > one large series of the original, uncompressed patches.  Thanks to the git 
> > > and stgit authors and contributors: without those tools, this process 
> > > would have been nearly impossible.
> > 
> > Since this patch series was only really meant for me to do some follow-on
> > work on it (to merge it into my tree) is it really necessary to submit
> > this 70 patch series via slow email via several mailing lists?
> 
> I posted the patches for final review and upstream merging.
> 
> Not sure what the follow-on work is that you mention.  But if it's 
> additional development work, such as modifying the linux-omap clock code 
> to use your recent clkdev code, that should really be discussed 
> separately, and patches posted for comment to linux-omap, so the OMAP 
> community has a chance to test it first.  People on that list seem to be 
> pretty reasonable...

If that's what you thought I was offering, forget it.  I wasn't.

Re: OMAP clock fast-forward: an introduction to six series

[Russell King - ARM Linux]

On Thu, Jan 29, 2009 at 08:11:17AM +0000, Russell King - ARM Linux wrote:
> On Thu, Jan 29, 2009 at 12:05:13AM -0700, Paul Walmsley wrote:
> > Hello Russell,
> > 
> > On Wed, 28 Jan 2009, Russell King - ARM Linux wrote:
> > 
> > > On Wed, Jan 28, 2009 at 01:22:22PM -0700, Paul Walmsley wrote:
> > > > Per rmk's preferences, some patches have been 'compressed.' That is, some 
> > > > fix patches have been rolled into a single patch with the original.  To 
> > > > ease cross-referencing with the linux-omap git tree, original commit IDs 
> > > > have been inserted into the patch messages.  Also, what would have been an 
> > > > extremely long series has been split into six smaller, cumulative, roughly 
> > > > thematic patch series.  If requested, I would be pleased to simply send 
> > > > one large series of the original, uncompressed patches.  Thanks to the git 
> > > > and stgit authors and contributors: without those tools, this process 
> > > > would have been nearly impossible.
> > > 
> > > Since this patch series was only really meant for me to do some follow-on
> > > work on it (to merge it into my tree) is it really necessary to submit
> > > this 70 patch series via slow email via several mailing lists?
> > 
> > I posted the patches for final review and upstream merging.
> > 
> > Not sure what the follow-on work is that you mention.  But if it's 
> > additional development work, such as modifying the linux-omap clock code 
> > to use your recent clkdev code, that should really be discussed 
> > separately, and patches posted for comment to linux-omap, so the OMAP 
> > community has a chance to test it first.  People on that list seem to be 
> > pretty reasonable...
> 
> If that's what you thought I was offering, forget it.  I wasn't.

I'll expand on that.  When clockdomain and powerdomain support was added
to the mainline kernel about six months ago, I specifically asked the
question "Is this everything for this new code" and got told "yes".

I wanted to ensure that the new code I was merging was 100% up to date
with mainline so we wouldn't have a constant drip of old patches to it.

A few weeks later I pulled the omapzoom tree, which contains tony's tree
and diffed the new code, finding some unmerged patches which I added
_before_ that stuff went to Linus.

Since then, I've asked Tony whether the clock code was 100% up to date and
if not send me the patches.  No patches ever came forward.

So, with my work on OMAP first to sort out some of the utter crappyness
in there (which Tony had accepted.)  Tony whinged about it clashing with
your work, but still no clock patches from you or Tony were forthcoming.

Subsequent to that acceptance, and as a result of me getting utterly
pissed off with waiting for something to happen, I converted OMAP over
to use clkdev (so that OMAP can stop abusing the API and being used
as a reason why new implementations should continue this abuse.)

Again, Tony whinged about the big merge problem that this was creating.
So I made an offer to manipulate _your_ changes to apply with my changes.

That's the offer.  The offer is not to merge your code and then think
about what to do with mine possibly in a year or two's time.  OMAP
_is_ going to use the API correctly as soon as possible, no iffs or buts.

Not taking the offer means that you and Tony have to deal with the merging
issues.  Accepting the offer means I do that work for you and publish the
results back to you for your comment.

Your call.

Re: OMAP clock fast-forward: an introduction to six series

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [090129 00:31]:
> On Thu, Jan 29, 2009 at 08:11:17AM +0000, Russell King - ARM Linux wrote:
> > On Thu, Jan 29, 2009 at 12:05:13AM -0700, Paul Walmsley wrote:
> > > Hello Russell,
> > > 
> > > On Wed, 28 Jan 2009, Russell King - ARM Linux wrote:
> > > 
> > > > On Wed, Jan 28, 2009 at 01:22:22PM -0700, Paul Walmsley wrote:
> > > > > Per rmk's preferences, some patches have been 'compressed.' That is, some 
> > > > > fix patches have been rolled into a single patch with the original.  To 
> > > > > ease cross-referencing with the linux-omap git tree, original commit IDs 
> > > > > have been inserted into the patch messages.  Also, what would have been an 
> > > > > extremely long series has been split into six smaller, cumulative, roughly 
> > > > > thematic patch series.  If requested, I would be pleased to simply send 
> > > > > one large series of the original, uncompressed patches.  Thanks to the git 
> > > > > and stgit authors and contributors: without those tools, this process 
> > > > > would have been nearly impossible.
> > > > 
> > > > Since this patch series was only really meant for me to do some follow-on
> > > > work on it (to merge it into my tree) is it really necessary to submit
> > > > this 70 patch series via slow email via several mailing lists?
> > > 
> > > I posted the patches for final review and upstream merging.
> > > 
> > > Not sure what the follow-on work is that you mention.  But if it's 
> > > additional development work, such as modifying the linux-omap clock code 
> > > to use your recent clkdev code, that should really be discussed 
> > > separately, and patches posted for comment to linux-omap, so the OMAP 
> > > community has a chance to test it first.  People on that list seem to be 
> > > pretty reasonable...
> > 
> > If that's what you thought I was offering, forget it.  I wasn't.
> 
> I'll expand on that.  When clockdomain and powerdomain support was added
> to the mainline kernel about six months ago, I specifically asked the
> question "Is this everything for this new code" and got told "yes".
> 
> I wanted to ensure that the new code I was merging was 100% up to date
> with mainline so we wouldn't have a constant drip of old patches to it.
> 
> A few weeks later I pulled the omapzoom tree, which contains tony's tree
> and diffed the new code, finding some unmerged patches which I added
> _before_ that stuff went to Linus.
> 
> Since then, I've asked Tony whether the clock code was 100% up to date and
> if not send me the patches.  No patches ever came forward.
> 
> So, with my work on OMAP first to sort out some of the utter crappyness
> in there (which Tony had accepted.)  Tony whinged about it clashing with
> your work, but still no clock patches from you or Tony were forthcoming.
> 
> Subsequent to that acceptance, and as a result of me getting utterly
> pissed off with waiting for something to happen, I converted OMAP over
> to use clkdev (so that OMAP can stop abusing the API and being used
> as a reason why new implementations should continue this abuse.)
> 
> Again, Tony whinged about the big merge problem that this was creating.
> So I made an offer to manipulate _your_ changes to apply with my changes.
> 
> That's the offer.  The offer is not to merge your code and then think
> about what to do with mine possibly in a year or two's time.  OMAP
> _is_ going to use the API correctly as soon as possible, no iffs or buts.
> 
> Not taking the offer means that you and Tony have to deal with the merging
> issues.  Accepting the offer means I do that work for you and publish the
> results back to you for your comment.
> 
> Your call.

To me it does not matter which way the stuff gets merged. We just need
to get it all merged.

If you guys can't get it merged and sorted out then it will all fall
down on me. And then I have to use tools no smaller than a sledgehammer
to merge it all, so the outcome won't be pretty!

Tony

Re: OMAP clock fast-forward: an introduction to six series

[Russell King - ARM Linux]

On Thu, Jan 29, 2009 at 08:25:58AM -0800, Tony Lindgren wrote:
> To me it does not matter which way the stuff gets merged. We just need
> to get it all merged.
> 
> If you guys can't get it merged and sorted out then it will all fall
> down on me. And then I have to use tools no smaller than a sledgehammer
> to merge it all, so the outcome won't be pretty!

Well, I've continued with my approach.  28 patches are currently merged
onto a follow-on branch (scattered throughout the series but in order)
and the result builds for my OMAP1, OMAP2 and OMAP3 test builds.

Patches which I've provided non-trivial comments on by and large haven't
been merged.  Once I've worked through the set, I'll provide a final list
of those outstanding so nothing should be lost.

I would appreciate someone _bouncing_ (not forwarding) the patches I'm
missing to linux@arm.linux.org.uk please.  Those being D6, E2 and F2.

Re: OMAP clock fast-forward: an introduction to six series

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [090129 08:35]:
> On Thu, Jan 29, 2009 at 08:25:58AM -0800, Tony Lindgren wrote:
> > To me it does not matter which way the stuff gets merged. We just need
> > to get it all merged.
> > 
> > If you guys can't get it merged and sorted out then it will all fall
> > down on me. And then I have to use tools no smaller than a sledgehammer
> > to merge it all, so the outcome won't be pretty!
> 
> Well, I've continued with my approach.  28 patches are currently merged
> onto a follow-on branch (scattered throughout the series but in order)
> and the result builds for my OMAP1, OMAP2 and OMAP3 test builds.

OK, only 32 more patches to go :)

> Patches which I've provided non-trivial comments on by and large haven't
> been merged.  Once I've worked through the set, I'll provide a final list
> of those outstanding so nothing should be lost.
> 
> I would appreciate someone _bouncing_ (not forwarding) the patches I'm
> missing to linux@arm.linux.org.uk please.  Those being D6, E2 and F2.

I'll bounce them to you.

Regards,

Tony

Re: OMAP clock fast-forward: an introduction to six series

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [090129 08:42]:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [090129 08:35]:
> > On Thu, Jan 29, 2009 at 08:25:58AM -0800, Tony Lindgren wrote:
> > > To me it does not matter which way the stuff gets merged. We just need
> > > to get it all merged.
> > > 
> > > If you guys can't get it merged and sorted out then it will all fall
> > > down on me. And then I have to use tools no smaller than a sledgehammer
> > > to merge it all, so the outcome won't be pretty!
> > 
> > Well, I've continued with my approach.  28 patches are currently merged
> > onto a follow-on branch (scattered throughout the series but in order)
> > and the result builds for my OMAP1, OMAP2 and OMAP3 test builds.
> 
> OK, only 32 more patches to go :)

I mean 42!

> > Patches which I've provided non-trivial comments on by and large haven't
> > been merged.  Once I've worked through the set, I'll provide a final list
> > of those outstanding so nothing should be lost.
> > 
> > I would appreciate someone _bouncing_ (not forwarding) the patches I'm
> > missing to linux@arm.linux.org.uk please.  Those being D6, E2 and F2.
> 
> I'll bounce them to you.
> 
> Regards,
> 
> Tony
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP clock fast-forward: an introduction to six series

[Russell King - ARM Linux]

On Thu, Jan 29, 2009 at 08:53:35AM -0800, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [090129 08:42]:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [090129 08:35]:
> > > On Thu, Jan 29, 2009 at 08:25:58AM -0800, Tony Lindgren wrote:
> > > > To me it does not matter which way the stuff gets merged. We just need
> > > > to get it all merged.
> > > > 
> > > > If you guys can't get it merged and sorted out then it will all fall
> > > > down on me. And then I have to use tools no smaller than a sledgehammer
> > > > to merge it all, so the outcome won't be pretty!
> > > 
> > > Well, I've continued with my approach.  28 patches are currently merged
> > > onto a follow-on branch (scattered throughout the series but in order)
> > > and the result builds for my OMAP1, OMAP2 and OMAP3 test builds.
> > 
> > OK, only 32 more patches to go :)
> 
> I mean 42!

You were closer first time around - there's 9 patches I'm not going to merge
as they currently stand, which I've provided comments on.