Hi Tony, Artem, This series creates a fictitious GPMC interrupt chip and provide the clients with interrupts that could be handled using standard APIs. This helps in removing the requirement of driver of peripheral connected to GPMC having the knowledge about GPMC. The only user is OMAP NAND driver, it has also been modified to use interrupts provided by imaginary GPMC chip. This series has a dependency on [2], while [2] has a trivial dependency on [1]. With this series plus [1,2], GPMC driver conversion which is going to happen shortly will not create noticable effect outside of arch/arm/*omap*/. If this series along with [1,2] can be taken in for 3.5, ripples felt by MTD drivers upon GPMC driver conversion would be minimal. Regards Afzal [1] http://www.mail-archive.com/linux-omap@xxxxxxxxxxxxxxx/msg68581.html [2] http://www.mail-archive.com/linux-omap@xxxxxxxxxxxxxxx/msg68652.html Afzal Mohammed (3): ARM: OMAP2+: gpmc: Modify interrupt handling ARM: OMAP2+: gpmc-nand: Modify Interrupt handling mtd: nand: omap2: use gpmc provided irqs arch/arm/mach-omap2/gpmc-nand.c | 28 +++++-- arch/arm/mach-omap2/gpmc.c | 137 ++++++++++++++++++++++++++++---- arch/arm/plat-omap/include/plat/gpmc.h | 1 + drivers/mtd/nand/omap2.c | 70 +++++++++------- 4 files changed, 185 insertions(+), 51 deletions(-) -- 1.7.10 -- 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