On Thu, Mar 15, 2012 at 8:43 AM, DebBarma, Tarun Kanti <tarun.ka...@ti.com> wrote: > On Thu, Mar 15, 2012 at 3:35 AM, Kevin Hilman <khil...@ti.com> wrote: >> Tarun, >> >> Can you investigate an abort during boot on 3630/Zoom3? >> >> Both Tony and I are seeing the abort below on 3630/Zoom3. I'm using >> arm-soc/for-next and Tony is using linux-next, but we see the same abort. > The crash looks very similar to what we fixed yesterday. The problem was > basically due to usage of OMAP_GPIO_IRQ macro instead of gpio_to_irq() > which came as part of Benoit's dynamic irq allocation change. The fix is to > replace those macros in the board files. > (The same problem is seen on OMAP3430 SDP as well.) > Anyways, I will confirm. > >> >> Adding in your latest fixes series doesn't make the problem go away, but >> backing out the GPIO runtime PM series does make the problem go away. > Because of dynamic irq allocation we end up into wrong GPIO Bank unless > we use the new gpio_to_irq(). As a result _set_gpio_triggering() tries > to operate > on a GPIO Bank whose clock was not turned on using omap_gpio_request(). > Probably, that is why we do not see the problem when the runtime PM series > is removed because in this case all the GPIO banks are turned on. > To be clear, the issue which we saw was wiith Grant's tree which has GPIO sparce IRQ conversion. So if the issue is seen with linux for-next, it must be the same issue.
There are many board files which are still using static OMAP_GPIO_IRQ macro to retrieve the IRQ number which won't work anymore after the gpio sparce irq conversion series. We will post a patch against Grant's tree to fix those board files. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
