* Ghorai, Sukumar <s-ghorai@xxxxxx> [100918 11:16]: > > > > This handler should be in gpmc.c as it may be needed for other GPMC > > connected devices on the same system. You can use chained irq handlers > > to allow all the drivers to use the interrupt then. > > [Ghorai] > You mean as this function used the gpmc-irq number in nand file, so handler should move to gpmc.c file? Yes, other GPMC connected drivers may want to use it too for their chip selects. > 1. For that we need to add one io-struct (to keep io buffer status) in gpmc.c; > > 2. Also need help how to sync between gpmc.c/omap_nand_irq() and omap2.c/omap_write_buf_irq_pref(), men how read/write function know that work done in interrupt-context? Or you prefer to move the complete IO function (omap_read/write_buf_irq_pref) to gpmc.c? > > 3. gpmc does not now about the read and write address that's applicable for NAND. So how to pass the IO address from omap2.c to gpmc.c, interrupt handler? Hmm, I don't follow you. You can have the interrupt handler both in gpmc.c and in the nand driver with set_irq_chained_handler() and set_irq_data(). We are doing that already in lots of places, like gpio.c and twl4030-irq.c. > So, please let me know your suggestion again such that I can post this time itself. Otherwise again it will miss from coming release, this was posted/reviewed for last release too. And suggest to void repeating of missing release window again. Yes would be nice to get this patch in, to me it seems that this issue is the only blocker. It should be pretty easy change to make. Regards, 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
