2.6.21-rc1 merge status

Hi,

I'd like to give you an update about some 2.6.21-rc1 merge news from the last few days I'm aware of. There are some good news, but unfortunately some bad news as well.

1) Looks like hrtimers and generic clockevents are merged into mainline, so (main?) parts from the -rt patches . Now Kevin will send a patchset to enable a handful of ARM platforms, including OMAP1 [1]. Thanks to Kevin and everybody helping with this!

2) Merging our OMAP patches via Russells patch system to mainline failed [2]. There was some background discussion between Tony, Russell and Andrew how to merge our patches in last week. Tony sent some updated patches based on Russells comments, but it was too much for Russell for a proper review. Russell mentioned ~17klines of changes.

Now, we have to find a proper way how to get our (at the moment) large changes merged upstream. Looks like getting everything merged in the usual two week merge window isn't possible. First we should remove our patchset from Russells incoming queue and then discuss how to go on.

3) I saw that some I2C stuff was merged, but don't know the exact status. After [3] Dave sent a lot of patches to I2C list and there was a lot of discussion. I lost the track there while some discussion like "apply patch 6a and use this patch and use that patch ..." ;)

Dave: Can you give us an update about I2C status in 2.6.21-rc1, what went in and what not? What's about the idea of "embedded I2C stack"? Many thanks!

Opinions and stuff I missed are welcome.

Cheers

Dirk

P.S.: I couldn't find a working archive of arm-linux-kernel. The stuff I can find on

http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/

is always broken after some mails of each month. Therefore I can give no links here and cite the essential parts of the mails from that list here, in case you are not subscribed there. Sorry.

[1]

Date: Fri, 16 Feb 2007 17:54:53 -0800
From: Kevin Hilman <[email protected]>
To: linux-arm-kernel <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Subject: [RFC] generic clockevents, timer_tick() and LEDs

With the recent arrival (as of today) of hrtimers and generic clockevents into mainline, I'm about to submit a set of patches to enable a handful of ARM platforms (ixp4xx, versatile and OMAP1.)

However, I would appreciate any feedback on how to handle the existing timer_tick() function in arch/arm/kernel/time.c. The new clockevent layer now does everything that timer_tick() does, except do_leds().

The way this is handled in the current -rt patch (see patch below) is that ifdef'd arch_tick_leds() call is added to the arch-independent do_timer() function. This then removes the need for the timer ISR to call timer_tick() at all.

Another option would be to remove all the calls handled by clockevents with an #ifdef CONFIG_GENERIC_CLOCKEVENTS inside timer_tick() and leave the timer_tick() call in each ISR.

I prefer the first option and the eventual removal of timer_tick(). Any other thoughts?

Also note that the new dynticks support has been added to mainline, which obsoletes the existing stuff done by NO_IDLE_HZ. From what I can tell, this is currently only used on PXA, sa1100 and OMAP1.
In my
patchset, I plan to make NO_IDLE_HZ 'depends on !GENERIC_CLOCKEVENTS' as platforms moving to clockevents should use the new dynticks (a.k.a. NO_HZ) instead.

I'll have a first go at my patchset ready for comments early next week.
For the curious, most of this is already in the current
-rt patchset.

Kevin

Index: linux-2.6/arch/arm/kernel/time.c
===================================================================
@@ -234,6 +234,13 @@ static inline void do_leds(void)
 #define	do_leds()
 #endif
 
+void arch_tick_leds(void)
+{
+#ifdef CONFIG_LEDS_TIMER
+	do_leds();
+#endif
+}
+
 #ifndef CONFIG_GENERIC_TIME
 void do_gettimeofday(struct timeval *tv)
 {

Index: linux-2.6/kernel/timer.c
===================================================================
@@ -1289,6 +1289,9 @@ void do_timer(unsigned long ticks)
 {
 	jiffies_64 += ticks;
 	update_times(ticks);
+#ifdef CONFIG_LEDS_TIMER
+ 	arch_tick_leds();
+#endif
 }
 
 #ifdef __ARCH_WANT_SYS_ALARM

[2]

Date: Sat, 17 Feb 2007 20:40:59 +0000
From: Russell King - ARM Linux <[email protected]>
To: [email protected]
Subject: Re: Last Chance before 2.6.21-rc1

Right, that's it for -rc1.

Unfortunately, this time around, there's been a number of issues:

1. OMAP stuff has not been merged again; there's just too much of it and not enough time to review it.

2. NetSilicon 93xx got dumped at the last minute due to merging errors which I didn't have time to resolve.

3. IOP changes got dumped because git refused to merge, spewing out an error I didn't understand.

4. Some patches accidentally got dropped during my manipulation of my git tree, and only realised _after_ the final pull
request has been
sent to Linus.

So, if your patch says it was applied, but doesn't appear once my tree has been merged, take that as being _not_ applied, and resend at the appropriate time.

It's been a nightmare this time around due to the number and size of the changes, coupled with the inability to do regular merges with Linus anymore, most notable the lack of pull half-way through this merge window.

[3]
http://linux.omap.com/pipermail/linux-omap-open-source/2006-November/008421.html

If you recall, the patches I did in November were eventually split into "Phase I" and "Phase II".

- One of the "Phase I" patches is in RC1 ... adding new methods for I2C drivers to suspend()/resume()/shutdown(). Ditto several semi-related patches making I2C adapter drivers link up to their adapter hardware device. All are what I'd call minor updates, most of which barely missed the 2.6.20 merge window.

- The other "Phase I" issues are still pending, fixed I think in in recent MM patch sets but expected to stay there unti 2.6.22 merge window opens. The strategy to remove i2c_adapter_driver mistake has done a 180-degree turn because of this new "remove class_device" jihad (which you can NOT read about in the feature removal schedule) ... much wasted time, without which I think all that phase I stuff would have been in 2.6.21 (sigh).

- Accordingly I see no way the "Phase II" stuff (most interesting for OMAP, because it means the I2C stack can behave with adapters that can't support SMBUS_QUICK) to merge before 2.6.22 starts.

I recently refreshed the core "Phase II" patches, and Jean hopes to re-review those phase II patches this week. With any luck that means they will then enter his patch queue (for 2.6.22).

And then it'd be worth refreshing the patches which _use_ those new APIs ... e.g. the OSK patches I sent at some point.

I don't see a rewrite of I2C coming any time soon, or teaching it how to do async messaging. But the "Phase II" stuff should help resolve the main technical issues I recall motivating folk to think about wanting a whole new "embedded" I2C stack: the requirement for SMBUS_QUICK, the inability to pass board-specific platform_data to drivers, the odd belief that I2C chips don't need to issue IRQs.

- Dave

Hi,

Yes, it's a big pile of patches :)

Yeah, Andrew Morton suggested that we post the linux-omap patch series to appropriate mailing lists for larger review. I will post the patch series to LKML few weeks before 2.6.22 opens for review, and will also notify the linux-arm-kernel list asking for people to comment on it.

There are some patches that can be already sent as fixes against 2.6.21-rxX, so that will cut down the size of the patch series a bit.

As we're trying to have all the core omap code in sync with mainline kernel, I'd like to start using branches in our linux-omap tree to make things easier.

Here's what I see working pretty nicely with branches in linux-omap tree:

Linus' mainline tree
\
omap-fixes (Fixes for 2.6.21-rcX)
\
omap-upstream (Queue for when 2.6.22 opens)
\
omap-drivers (Patches to send to driver lists)
\
linux-omap (Non mergeable hacks)

So to checkout the current linux-omap tree, you would just use "git-checkout linux-omap" instead of checking out the master branch as we currently do.

This way we can easily rebase the branches against the mainline tree using git-rebase command. Please also note that we can add other temporary branches between the branches above if necessary.

I'll try to set this up this week to try it out, and then we can change over to it next week assuming there are no problems.

Regards,

Tony