Section 15.4.4.13.2 of the OMAP4 TRM (NAND Device-Ready Pin) indicates that software can poll the WAIT0STATUS bit of the GPMC_STATUS register can be used to monitor the readiness of the NAND device. That is, the state of the NAND's ready line connected to the GPMC_WAIT0.
However, this isn't what the Linux driver does. Instead, it uses the WAIT0EDGEDETECTION bit in the GPMC_IRQSTATUS register (omap_dev_read()). The problem is that that bit changes a long time after the GPMC_WAIT0 signal changes. It takes longer for the WAIT0EDGEDETECTION bit to change than it does to transfer an entire 2048 byte page of data from the NAND chip. So this has a large impact on NAND performance.
I've modified the Linux driver to use WAIT0STATUS instead of WAIT0EDGEDETECTION. Although faster, it leads to occasional read errors. It seems that something (the GPMC engine?) isn't ready even after the NAND chip has indicated that it is ready.
I don't see any reference to this in the OMAP4 errata. Also, there's nothing in the git history for the Linux driver (it's been coded this way since the beginning).
Is there any background on a problem related to the WAIT0STATUS bit, what the Linux driver might be working around instead of using it?
Alternatively, is there a way to get WAIT0EDGEDETECTION to reflect the ready line status faster?
Regards,
Steve
