Message ID | 20120321180536.GK9859@atomide.com |
---|---|
State | New |
Headers | show |
Hi Tony, On Wed, Mar 21, 2012 at 11:05 AM, Tony Lindgren <tony@atomide.com> wrote: > Hi Arnd & Olof, > > Here's a set of fixes that would be nice to get merged during > the merge window before the GPIO changes get merged to avoid > boot issues on many omap boards. > > The changes queued in the GPIO tree require getting rid of > OMAP_GPIO_IRQ and use gpio_to_irq() instead. This is needed for > dynamically allocated GPIO interrupt ranges. Sorry for the slow response on this, we've been focused on getting the main pulls going in. I'm about to start a fixes branch now and looked at this pull request. I replied to one of the original patches in this branch, they need to be fixed before they can go in: http://marc.info/?l=linux-omap&m=133299716528617&w=2 Also, that way we can get a clean branch based on current mainline without merge conflicts. -Olof
* Olof Johansson <olof@lixom.net> [120328 22:04]: > Hi Tony, > > On Wed, Mar 21, 2012 at 11:05 AM, Tony Lindgren <tony@atomide.com> wrote: > > Hi Arnd & Olof, > > > > Here's a set of fixes that would be nice to get merged during > > the merge window before the GPIO changes get merged to avoid > > boot issues on many omap boards. > > > > The changes queued in the GPIO tree require getting rid of > > OMAP_GPIO_IRQ and use gpio_to_irq() instead. This is needed for > > dynamically allocated GPIO interrupt ranges. > > Sorry for the slow response on this, we've been focused on getting the > main pulls going in. I'm about to start a fixes branch now and looked > at this pull request. > > I replied to one of the original patches in this branch, they need to > be fixed before they can go in: > > http://marc.info/?l=linux-omap&m=133299716528617&w=2 Thanks, that's a good catch. > Also, that way we can get a clean branch based on current mainline > without merge conflicts. Yes will do. Regards, Tony