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, [email protected]. 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(-)
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...
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
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.
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.
* Russell King - ARM Linux <[email protected]> [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
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 [email protected] please. Those being D6, E2 and F2.
* Russell King - ARM Linux <[email protected]> [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 [email protected] please. Those being D6, E2 and F2.
I'll bounce them to you.
Regards,
Tony
* Tony Lindgren <[email protected]> [090129 08:42]:
> * Russell King - ARM Linux <[email protected]> [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 [email protected] 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jan 29, 2009 at 08:53:35AM -0800, Tony Lindgren wrote:
> * Tony Lindgren <[email protected]> [090129 08:42]:
> > * Russell King - ARM Linux <[email protected]> [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.