Re: upstream merge schedule

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* David Brownell <david-b@xxxxxxxxxxx> [080122 18:16]:
> On Tuesday 22 January 2008, Tony Lindgren wrote:
> > Yeah, I agree, changing into gpiolib is a good idea. We should also
> > split gpio.c into mach-omap1 and mach-omap2 parts.
> 
> Splitting omap1 and omap2/3 gpio would be a good cleanup, yes.  :)
> 
> I'll try to make time to refresh my omap gpiolib patch against
> the latest gpiolib framework code (it may not even be needed).
> But it'd be good if someone else would do that split.

Well I can split it up, it's been bugging me for a while now.
So let's first apply Kevin's fixes, then the gpiolib, then
split it up. If gpiolib merge takes longer, we can split it
up first, then apply gpiolib patches.

> There's various platform stuff to roll in.  The pcf857x code
> worked OK last I tried; various devboards should learn to use
> it.  The tps65010 patch should be easy to refresh, as should
> the debug board (H2/H3/H4/P2/...) FPGA support.  That'd take
> a big bite out of all that ...

OK

> I don't know of any holdups to keep the GPIOLIB framework out
> of 2.6.25-early; it's in current MM.  So a 2.6.25-rc1-omap1
> should have at least the core of all that work.

Cool.

Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux