* Trilok Soni <soni.trilok@xxxxxxxxx> [080118 23:44]: > Hi Felipe, > > On Jan 19, 2008 2:34 AM, Felipe Balbi <me@xxxxxxxxxxxxxxx> wrote: > > On Fri, Jan 18, 2008 at 08:41:23AM -0800, Tony Lindgren wrote: > > > * Daniel Walker <dwalker@xxxxxxxxxx> [080117 21:57]: > > > > > > > > When I made the nokia770 patch (just sent) I was wonder when it would be > > > > merged? It seems that omap upstream merges are somewhat slow going, why > > > > is that? > > > > > > Ideally patches should get merged to linux-omap within few days > > > and in more intrusive cases within few weeks. But sometimes patches > > > pile up, and now we have some patches pending mostly because I > > > was travelling for three weeks. I will be applying patches starting > > > today, so hopefully we'll have the pending patches cleared up within > > > next few days. > > > > > > Regarding merging core omap stuff to mainline kernel, we still need > > > to clean up few things to get arch/arm/*omap directories in sync with > > > mainline. After currently pending patches arch/arm/mach-omap1 and > > > plat-omap will be within one or two more main releases away from > > > being in sync, and mach-omap2 will take a bit longer. So hopefully > > > we'll be in sync with mainline for core omap stuff during this year. > > > > > > Regarding merging various drivers upstream, they need to go through > > > various driver mailing lists or LKML. So ideally the person who has > > > done the patch will also send it for merging to the right mailing > > > list. Otherwise the driver patch will most likely just stay in > > > linux-omap tree. > > > > Besides that, i think after omap2 merge we could schedule a driver merge > > task so we get all drivers made in omap tree to upstream (also the > > defconfigs :-). > > I think once gpiolib gets integrated with mainline kernel, then it > would be easy convert > our current gpio expander code to use gpiolib (some of this conversion > patches were posted by David for DaVinci and OMAP) > and the drivers having this depedancies like OMAP IR, USB tranceiver > and other drivers using current gpio_expander_* apis, > can merged easily to upstream. If I remember correctly, OMAP IR driver > went through the upstream review by Samuel, but was > rejected due to this GPIO_EXPA KConfig symbol and api dependency :) Yeah, I agree, changing into gpiolib is a good idea. We should also split gpio.c into mach-omap1 and mach-omap2 parts. 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
