Re: [PATCH 03/12] mtd: nand: omap: Move IRQ handling from GPMC to NAND driver
flat view
From: Roger Quadros <hidden>
Date: 2015-07-13 13:12:51
Also in:
linux-omap, lkml
On 13/07/15 16:03, nick wrote:
On 2015-07-13 09:01 AM, Tony Lindgren wrote:quoted
* nick [off-list ref] [150713 05:54]:quoted
On 2015-07-13 08:40 AM, Tony Lindgren wrote:quoted
* Roger Quadros [off-list ref] [150713 03:07]:quoted
What is the best map we should use for irqchip? Some Socs have 4 WAIT pins, some have 3 and some have 2. Should we start with 0,1,2, for the wait pins and use the next available free one for the NAND?Maybe we can just use the bits defined for each SoC in the GPMC_IRQSTATUS register for the mapping? Regards,Is that a good idea as to my knowledge of OMAP platforms that register is hardware dependent and therefore that may be an issue unless your idea is to create device tables like the way they do in the nand subsystems to support various vendor's nand flash expect here for the pins on OMAP SOCs.Do you mean mapping irqs based on the GPMC_IRQSTATUS register bits? If so, that's pretty much how all the GPIO drivers handle them. We can have a SoC specific irqmask of the valid bits passed from the dts files, and if necessary we can also add custom SoC specific IRQ handlers to the GPMC driver if needed. The idea is that the NAND driver can just request the irq from the GPMC driver and do whatever it wants with the interrupt. Regards, TonyTony, That is what I was hoping the code was doing. So what appears to be the problem with the patches related to irq requesting from the GPMC driver. Cheers, Nick
The problem with this patch is that it expects GPMC_IRQ registers to be accessible by the NAND driver and looses the 2 to 4 pins of WAIT pin edge detection interrupt capability if it is needed for generic use. (not NAND/GPMC memory specific) cheers, -roger