On Thu, 7 May 2020 15:47:08 +0200 Lubomir Rintel <lkundrak@xxxxx> wrote: > On Wed, May 06, 2020 at 11:35:52PM +0200, Boris Brezillon wrote: > > On Wed, 6 May 2020 22:36:35 +0200 > > Lubomir Rintel <lkundrak@xxxxx> wrote: > > > > > > We really should mask IRQs (AKA disable IRQs in my naming convention > > > > :-)) here, unless we want to switch to interrupt-based waits (which > > > > would be a good thing when we have DMA or WAIT_RDY involved). Having an > > > > interrupt handler in the current implementation doesn't make any sense > > > > (that's assuming the IRQ_STATUS bits are updated even if the interrupts > > > > are disabled, which am not sure is a valid assumption in this case). > > > > > > I have no idea why the interrupt handler is there. Perhaps some > > > interrupts can't be masked and need an ack or something. > > > > Can you try to set NAND_IRQ_MASK to 0x0 and see if that still works. > > Can you also check the number of NAND interrupts when set to 0x0? It's > > hard to tell exactly what caused the interrupt handler to be called > > since this is a shared interrupt. > > When it's set to 0, I get an interrupt with CAFE_NAND_IRQ=0x40000000 > (CAFE_NAND_IRQ_FLASH_RDY) right off the bat. That doesn't happen with > a mask of 0xffffffff. > > When changing the handler to always ack CAFE_NAND_IRQ_FLASH_RDY I've > also seen CAFE_NAND_IRQ=0x80000000 (CAFE_NAND_IRQ_CMD_DONE) suggesting > that other interrupts aren't masked either. > > It seems to be that ones indeed mask interrupts but just can't be > masked (CAFE_NAND_IRQ_CMD_DONE or CAFE_NAND_IRQ_DMA_DONE), perhaps > due to hardware bugs. > I pushed a new version with some interrupt-related changes [1]. [1]https://github.com/bbrezillon/linux/commits/nand/cafe-nand-exec-op-debug ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/