Hi,
On 09/02/19 10:59 PM, Jagan Teki wrote:
On Mon, Jan 7, 2019 at 2:24 PM Ye Li ye.li@nxp.com wrote:
From: Han Xu han.xu@nxp.com
Support to read the flag status in driver to avoid the spi-nor framework wait_for_ready hang issue.
Signed-off-by: Han Xu han.xu@nxp.com
drivers/spi/fsl_qspi.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+)
diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c index 1987a72..ed0e649 100644 --- a/drivers/spi/fsl_qspi.c +++ b/drivers/spi/fsl_qspi.c @@ -47,6 +47,7 @@ DECLARE_GLOBAL_DATA_PTR; #endif #define SEQID_WRAR 13 #define SEQID_RDAR 14 +#define SEQID_RDFSR 15
/* QSPI CMD */ #define QSPI_CMD_PP 0x02 /* Page program (up to 256 bytes) */ @@ -57,6 +58,7 @@ DECLARE_GLOBAL_DATA_PTR; #define QSPI_CMD_CHIP_ERASE 0xc7 /* Erase whole flash chip */ #define QSPI_CMD_SE 0xd8 /* Sector erase (usually 64KiB) */ #define QSPI_CMD_RDID 0x9f /* Read JEDEC ID */ +#define QSPI_CMD_FLAG_SR 0x70 /* Read FLAG STATUS*/
NAK, need to handle this from flash side. better keep working on that front.
U-Boot now supports spi-mem abstraction just like kernel. Could you move fsl_qspi to use spi-mem APIs to get rid of using opcodes directly within the driver?