Hi, On 09/02/19 10:59 PM, Jagan Teki wrote: > On Mon, Jan 7, 2019 at 2:24 PM Ye Li <ye...@nxp.com> wrote: >> >> From: Han Xu <han...@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...@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? -- Regards Vignesh _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot