[U-Boot] [PATCH v2 17/18] spi: mtk_qspi: add qspi driver for MT7629 SoC

Jagan Teki jagan at amarulasolutions.com
Thu Nov 22 06:21:03 UTC 2018


On Wed, Nov 21, 2018 at 5:16 PM Guochun Mao <guochun.mao at mediatek.com> wrote:
>
> Hi Jagan,
>
> On Wed, 2018-11-21 at 15:08 +0530, Jagan Teki wrote:
>
> > > > > +static int mtk_qspi_tx_rx(struct mtk_qspi_priv *priv)
> > > > > +{
> > > > > +       int len = 1 + priv->txlen + priv->rxlen;
> > > > > +       int i, ret, idx;
> > > > > +
> > > > > +       if (len > MTK_QSPI_MAX_SHIFT)
> > > > > +               return -ERR_INVAL;
> > > > > +
> > > > > +       writeb(len * 8, &priv->regs->cnt);
> > > > > +
> > > > > +       /* start at PRGDATA5, go down to PRGDATA0 */
> > > > > +       idx = MTK_QSPI_MAX_RX_TX_SHIFT - 1;
> > > > > +
> > > > > +       /* opcode */
> > > > > +       writeb(priv->op, &priv->regs->prgdata[idx]);
> > > > > +       idx--;
> > > > > +
> > > > > +       /* program TX data */
> > > > > +       for (i = 0; i < priv->txlen; i++, idx--)
> > > > > +               writeb(priv->tx[i], &priv->regs->prgdata[idx]);
> > > > > +
> > > > > +       /* clear out rest of TX registers */
> > > > > +       while (idx >= 0) {
> > > > > +               writeb(0, &priv->regs->prgdata[idx]);
> > > > > +               idx--;
> > > > > +       }
> > > > > +
> > > > > +       ret = mtk_qspi_execute_cmd(priv, MTK_QSPI_PRG_CMD);
> > > >
> > > > What does this execute do?
> > > It send command to flash, and latch data if need.
> > >
> > > > does it intiate the controller register
> > > > based flash command or so?
> > > No, it doesn't.
> > >
> > > >
> > > > Do you have Linux driver on the controller?
> > > Yes, it's drivers/mtd/spi-nor/mtk-quadspi.c
> >
> > This sounds more specific to flash controller rather than spi driver.
> > Can you try to write driver in mtd side itself, like Linux spi-nor.
> > use UCLASS_SPI_FLASH
>
> Sorry, I'm a little confused.
> There are many files(***qspi.c) those that used for accessing spi flash
> under folder drivers/spi/.
> However, there's no specific flash controller driver implemented under
> drives/mtd, only common spi_flash framework. It's different with kernel.
> It seems that we only need implement the spi control logic of
> spi-flash-controller(this part not based on flash, it only do
> data-xfer), and spi_flash framework will work well base on it.
> Isn't that the purpose of this architecture?

Understand your point, to be precise the driver may a fall in trouble
after sometime, if there is an additional flash specific features will
attach in future. ie reason few of flash controllers in drivers/spi
were unable to move further to add their features. and ie also reason
for your driver in Linux which resides in spi-nor.

You can directly write UCLASS_SPI_FLASH like sf_dataflash, I can help
if any issues with probing setup etc.


More information about the U-Boot mailing list