Tony, On 13/07/15 15:40, Tony Lindgren wrote: > * Roger Quadros <rogerq@xxxxxx> [150713 03:07]: >> Tony, >> >> On 13/07/15 10:10, Tony Lindgren wrote: >>> * Roger Quadros <rogerq@xxxxxx> [150710 05:26]: >>>> Since the Interrupt Events are used only by the NAND driver, >>>> there is no point in managing the Interrupt registers >>>> in the GPMC driver and complicating it with irqchip modeling. >>> >>> I don't think it's a good idea to allow external drivers to >>> tinker directly with GPMC registers. How about just set up GPMC >>> as an irqchip for the edge detection interrupts? >>> >>> I think we already have devices with multiple NAND chips. And >>> there's nothing stopping other drivers from using the edge >>> detection interrupts. >> >> OK. The GPMC_IRQ registers manage 2 NAND specific interrupts >> (terminalcount and fifo) and 'n' WAIT pin edge interrupts. >> >> So we can model this as a irqchip with 'n + 2' interrupts. > > OK For the wait pins irqchip is not sufficient and it needs to be gpiochip with irqchip. Waitpin status can be read from GPIO_STATUS register. Just getting the interrupt is not enough and we want to know if the line is high or low. That is how nand->dev_ready works. How about having 2 IRQ domains? One is irqchip with 2 interrupts (terminalcount and fifo) and second is gpiochip + irqchip for the n wait pins. The nand driver can then be modified to use GPIO to get Read/Busy pin status from the wait pin. cheers, -roger > >> We need to take care that if a GPMC chip select needs a >> wait pin then it can't be used as a generic interrupt. >> >> We need to get rid of omap_dev_ready() in nand/omap2.c as >> it accesses the GPMC_STATUS register directly. Plus it is >> hard coded to only monitor wait0 pin. > > OK > >> 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, > > Tony > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
