[U-Boot] [PATCH v2] fsl_qspi: Improve QSPI driver to incorporate 4 byte commands

[Jagan Teki]

Hi Frieder,

On Wed, May 29, 2019 at 6:14 PM Schrempf Frieder
<frieder.schrempf at kontron.de> wrote:
>
> Hi Jagan,
>
> On 29.05.19 13:06, Jagan Teki wrote:
> > On Fri, Apr 26, 2019 at 6:12 PM Rajat Srivastava
> > <rajat.srivastava at nxp.com> wrote:
> >>
> >> Previously, the SPI framework supported only 3-byte opcodes
> >> but the FSL QSPI controller used to deal with flashes that
> >> work with 4-byte opcodes. As a workaround to resolve this,
> >> for every 3-byte opcodes sent by framework FSL QSPI driver
> >> used to explicitly send corresponding 4-byte opcodes.
> >>
> >> Now the framework has been updated to send 4-byte opcodes
> >> and FSL QSPI driver needs correction. This change will be
> >> applicable for the following defconfig where we disable
> >> CONFIG_FLASH_BAR:
> >> LS1088A, LS1046A, LS1043A, LS1012A, LS2088A defconfigs
> >>
> >> Signed-off-by: Ashish Kumar <ashish.kumar at nxp.com>
> >> Signed-off-by: Rajat Srivastava <rajat.srivastava at nxp.com>
> >> ---
> >> Changes in v2:
> >>   - Update commit message
> >>   - Reduce patchset to one patch
> >>   - This patch is no more applicable:
> >>     https://patchwork.ozlabs.org/patch/1090122/
> >>
> >>   drivers/spi/fsl_qspi.c | 45 +++++++++++++++++++++++++++++-------------
> >>   1 file changed, 31 insertions(+), 14 deletions(-)
> >>
> >> diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c
> >> index 1598c4f698..217005f525 100644
> >> --- a/drivers/spi/fsl_qspi.c
> >> +++ b/drivers/spi/fsl_qspi.c
> >> @@ -26,7 +26,8 @@ DECLARE_GLOBAL_DATA_PTR;
> >>   #define TX_BUFFER_SIZE         0x40
> >>   #endif
> >>
> >> -#define OFFSET_BITS_MASK       GENMASK(23, 0)
> >> +#define OFFSET_BITS_MASK       GENMASK(27, 0)
> >> +#define OFFSET_BITS_MASK_24    GENMASK(23, 0)
> >>
> >>   #define FLASH_STATUS_WEL       0x02
> >>
> >> @@ -754,7 +755,8 @@ static void qspi_op_erase(struct fsl_qspi_priv *priv)
> >>          while (qspi_read32(priv->flags, &regs->sr) & QSPI_SR_BUSY_MASK)
> >>                  ;
> >>
> >> -       if (priv->cur_seqid == QSPI_CMD_SE) {
> >> +       if ((priv->cur_seqid == QSPI_CMD_SE_4B) ||
> >> +           (priv->cur_seqid == QSPI_CMD_SE)) {
> >>                  qspi_write32(priv->flags, &regs->ipcr,
> >>                               (SEQID_SE << QSPI_IPCR_SEQID_SHIFT) | 0);
> >>          } else if (priv->cur_seqid == QSPI_CMD_BE_4K) {
> >> @@ -775,31 +777,44 @@ int qspi_xfer(struct fsl_qspi_priv *priv, unsigned int bitlen,
> >>          u32 txbuf;
> >>
> >>          WATCHDOG_RESET();
> >> -
> >>          if (dout) {
> >>                  if (flags & SPI_XFER_BEGIN) {
> >>                          priv->cur_seqid = *(u8 *)dout;
> >> -                       memcpy(&txbuf, dout, 4);
> >> +                       if (FSL_QSPI_FLASH_SIZE  > SZ_16M && bytes > 4)
> >> +                               memcpy(&txbuf, dout + 1, 4);
> >> +                       else
> >> +                               memcpy(&txbuf, dout, 4);
> >>                  }
> >>
> >>                  if (flags == SPI_XFER_END) {
> >>                          priv->sf_addr = wr_sfaddr;
> >> -                       qspi_op_write(priv, (u8 *)dout, bytes);
> >> -                       return 0;
> >> +                       if (priv->cur_seqid == QSPI_CMD_PP ||
> >> +                           priv->cur_seqid == QSPI_CMD_PP_4B ||
> >> +                           priv->cur_seqid == QSPI_CMD_WRAR) {
> >> +                               qspi_op_write(priv, (u8 *)dout, bytes);
> >> +                               return 0;
> >> +                       }
> >>                  }
> >>
> >> -               if (priv->cur_seqid == QSPI_CMD_FAST_READ ||
> >> -                   priv->cur_seqid == QSPI_CMD_RDAR) {
> >> +               if ((priv->cur_seqid == QSPI_CMD_FAST_READ) ||
> >> +                   (priv->cur_seqid == QSPI_CMD_FAST_READ_4B)) {
> >>                          priv->sf_addr = swab32(txbuf) & OFFSET_BITS_MASK;
> >> +               } else if (priv->cur_seqid == QSPI_CMD_RDAR) {
> >
> > I wonder why we still have flash specific stuff handling, we have
> > spi-mem like Linux. can't we handle these via spi-mem?
>
> Sure we can. I started working on porting the Linux driver to U-Boot
> some weeks ago, but didn't have time to continue with this recently.
>
> See this branch for the current state:
> https://github.com/fschrempf/u-boot/commits/fsl_qspi_spimem_port.

Look promising, I think it would be better have this conversion
instead of concentrating code which were moved/remove later and indeed
we have enough time for next MW.

Jagan.