diff mbox series

[v6,04/19] spi: spi-mem: allow specifying a command's extension

Message ID 20200520163053.24357-5-p.yadav@ti.com (mailing list archive)
State New, archived
Headers show
Series mtd: spi-nor: add xSPI Octal DTR support | expand

Commit Message

Pratyush Yadav May 20, 2020, 4:30 p.m. UTC
In xSPI mode, flashes expect 2-byte opcodes. The second byte is called
the "command extension". There can be 3 types of extensions in xSPI:
repeat, invert, and hex. When the extension type is "repeat", the same
opcode is sent twice. When it is "invert", the second byte is the
inverse of the opcode. When it is "hex" an additional opcode byte based
is sent with the command whose value can be anything.

So, make opcode a 16-bit value and add a 'nbytes', similar to how
multiple address widths are handled.

Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
 include/linux/spi/spi-mem.h | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

Comments

Boris Brezillon May 21, 2020, 6:22 p.m. UTC | #1
On Wed, 20 May 2020 22:00:38 +0530
Pratyush Yadav <p.yadav@ti.com> wrote:

> In xSPI mode, flashes expect 2-byte opcodes. The second byte is called
> the "command extension". There can be 3 types of extensions in xSPI:
> repeat, invert, and hex. When the extension type is "repeat", the same
> opcode is sent twice. When it is "invert", the second byte is the
> inverse of the opcode. When it is "hex" an additional opcode byte based
> is sent with the command whose value can be anything.
> 
> So, make opcode a 16-bit value and add a 'nbytes', similar to how
> multiple address widths are handled.
> 
> Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
> ---
>  include/linux/spi/spi-mem.h | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
> index e3dcb956bf61..731bb64c6ba6 100644
> --- a/include/linux/spi/spi-mem.h
> +++ b/include/linux/spi/spi-mem.h
> @@ -69,6 +69,8 @@ enum spi_mem_data_dir {
>  
>  /**
>   * struct spi_mem_op - describes a SPI memory operation
> + * @cmd.nbytes: number of opcode bytes (only 1 or 2 are valid). The opcode is
> + *		sent MSB-first.
>   * @cmd.buswidth: number of IO lines used to transmit the command
>   * @cmd.opcode: operation opcode
>   * @cmd.dtr: whether the command opcode should be sent in DTR mode or not
> @@ -94,9 +96,10 @@ enum spi_mem_data_dir {
>   */
>  struct spi_mem_op {
>  	struct {
> +		u8 nbytes;
>  		u8 buswidth;
>  		u8 dtr : 1;
> -		u8 opcode;
> +		u16 opcode;
>  	} cmd;
>  
>  	struct {

As mentioned in one of my previous review, you should patch the mxic
driver before extending the opcode field:

--->8---
diff --git a/drivers/spi/spi-mxic.c b/drivers/spi/spi-mxic.c
index 69491f3a515d..c3f4136a7c1d 100644
--- a/drivers/spi/spi-mxic.c
+++ b/drivers/spi/spi-mxic.c
@@ -356,6 +356,7 @@ static int mxic_spi_mem_exec_op(struct spi_mem *mem,
        int nio = 1, i, ret;
        u32 ss_ctrl;
        u8 addr[8];
+       u8 cmd[2];
 
        ret = mxic_spi_set_freq(mxic, mem->spi->max_speed_hz);
        if (ret)
@@ -393,7 +394,10 @@ static int mxic_spi_mem_exec_op(struct spi_mem *mem,
        writel(readl(mxic->regs + HC_CFG) | HC_CFG_MAN_CS_ASSERT,
               mxic->regs + HC_CFG);
 
-       ret = mxic_spi_data_xfer(mxic, &op->cmd.opcode, NULL, 1);
+       for (i = 0; i < op->cmd.nbytes; i++)
+               cmd[i] = op->cmd.opcode >> (8 * (op->cmd.nbytes - i - 1));
+
+       ret = mxic_spi_data_xfer(mxic, cmd, NULL, op->cmd.nbytes);
        if (ret)
                goto out;
Pratyush Yadav May 21, 2020, 7:41 p.m. UTC | #2
On 21/05/20 08:22PM, Boris Brezillon wrote:
> On Wed, 20 May 2020 22:00:38 +0530
> Pratyush Yadav <p.yadav@ti.com> wrote:
> 
> > In xSPI mode, flashes expect 2-byte opcodes. The second byte is called
> > the "command extension". There can be 3 types of extensions in xSPI:
> > repeat, invert, and hex. When the extension type is "repeat", the same
> > opcode is sent twice. When it is "invert", the second byte is the
> > inverse of the opcode. When it is "hex" an additional opcode byte based
> > is sent with the command whose value can be anything.
> > 
> > So, make opcode a 16-bit value and add a 'nbytes', similar to how
> > multiple address widths are handled.
> > 
> > Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
> > ---
> >  include/linux/spi/spi-mem.h | 5 ++++-
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
> > index e3dcb956bf61..731bb64c6ba6 100644
> > --- a/include/linux/spi/spi-mem.h
> > +++ b/include/linux/spi/spi-mem.h
> > @@ -69,6 +69,8 @@ enum spi_mem_data_dir {
> >  
> >  /**
> >   * struct spi_mem_op - describes a SPI memory operation
> > + * @cmd.nbytes: number of opcode bytes (only 1 or 2 are valid). The opcode is
> > + *		sent MSB-first.
> >   * @cmd.buswidth: number of IO lines used to transmit the command
> >   * @cmd.opcode: operation opcode
> >   * @cmd.dtr: whether the command opcode should be sent in DTR mode or not
> > @@ -94,9 +96,10 @@ enum spi_mem_data_dir {
> >   */
> >  struct spi_mem_op {
> >  	struct {
> > +		u8 nbytes;
> >  		u8 buswidth;
> >  		u8 dtr : 1;
> > -		u8 opcode;
> > +		u16 opcode;
> >  	} cmd;
> >  
> >  	struct {
> 
> As mentioned in one of my previous review, you should patch the mxic
> driver before extending the opcode field:

IIUC, this patchset doesn't break original functionality of the driver. 
It will work like before with 1-byte opcodes. So I don't think it is the 
responsibility of this patchset to enhance the driver. It didn't work 
before with 2-byte opcodes, it won't work now. IMO this should be a 
separate, independent change.
 
> --->8---
> diff --git a/drivers/spi/spi-mxic.c b/drivers/spi/spi-mxic.c
> index 69491f3a515d..c3f4136a7c1d 100644
> --- a/drivers/spi/spi-mxic.c
> +++ b/drivers/spi/spi-mxic.c
> @@ -356,6 +356,7 @@ static int mxic_spi_mem_exec_op(struct spi_mem *mem,
>         int nio = 1, i, ret;
>         u32 ss_ctrl;
>         u8 addr[8];
> +       u8 cmd[2];
>  
>         ret = mxic_spi_set_freq(mxic, mem->spi->max_speed_hz);
>         if (ret)
> @@ -393,7 +394,10 @@ static int mxic_spi_mem_exec_op(struct spi_mem *mem,
>         writel(readl(mxic->regs + HC_CFG) | HC_CFG_MAN_CS_ASSERT,
>                mxic->regs + HC_CFG);
>  
> -       ret = mxic_spi_data_xfer(mxic, &op->cmd.opcode, NULL, 1);
> +       for (i = 0; i < op->cmd.nbytes; i++)
> +               cmd[i] = op->cmd.opcode >> (8 * (op->cmd.nbytes - i - 1));
> +
> +       ret = mxic_spi_data_xfer(mxic, cmd, NULL, op->cmd.nbytes);
>         if (ret)
>                 goto out;
>
Pratyush Yadav May 21, 2020, 8:03 p.m. UTC | #3
On 22/05/20 01:11AM, Pratyush Yadav wrote:
> On 21/05/20 08:22PM, Boris Brezillon wrote:
> > On Wed, 20 May 2020 22:00:38 +0530
> > Pratyush Yadav <p.yadav@ti.com> wrote:
> > 
> > > In xSPI mode, flashes expect 2-byte opcodes. The second byte is called
> > > the "command extension". There can be 3 types of extensions in xSPI:
> > > repeat, invert, and hex. When the extension type is "repeat", the same
> > > opcode is sent twice. When it is "invert", the second byte is the
> > > inverse of the opcode. When it is "hex" an additional opcode byte based
> > > is sent with the command whose value can be anything.
> > > 
> > > So, make opcode a 16-bit value and add a 'nbytes', similar to how
> > > multiple address widths are handled.
> > > 
> > > Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
> > > ---
> > >  include/linux/spi/spi-mem.h | 5 ++++-
> > >  1 file changed, 4 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
> > > index e3dcb956bf61..731bb64c6ba6 100644
> > > --- a/include/linux/spi/spi-mem.h
> > > +++ b/include/linux/spi/spi-mem.h
> > > @@ -69,6 +69,8 @@ enum spi_mem_data_dir {
> > >  
> > >  /**
> > >   * struct spi_mem_op - describes a SPI memory operation
> > > + * @cmd.nbytes: number of opcode bytes (only 1 or 2 are valid). The opcode is
> > > + *		sent MSB-first.
> > >   * @cmd.buswidth: number of IO lines used to transmit the command
> > >   * @cmd.opcode: operation opcode
> > >   * @cmd.dtr: whether the command opcode should be sent in DTR mode or not
> > > @@ -94,9 +96,10 @@ enum spi_mem_data_dir {
> > >   */
> > >  struct spi_mem_op {
> > >  	struct {
> > > +		u8 nbytes;
> > >  		u8 buswidth;
> > >  		u8 dtr : 1;
> > > -		u8 opcode;
> > > +		u16 opcode;
> > >  	} cmd;
> > >  
> > >  	struct {
> > 
> > As mentioned in one of my previous review, you should patch the mxic
> > driver before extending the opcode field:
> 
> IIUC, this patchset doesn't break original functionality of the driver. 
> It will work like before with 1-byte opcodes. So I don't think it is the 
> responsibility of this patchset to enhance the driver. It didn't work 
> before with 2-byte opcodes, it won't work now. IMO this should be a 
> separate, independent change.

Scratch that. Big/little endian issue. If you'd drop your Signed-off-by, 
I'll write the commit message and patch it in.
  
> > --->8---
> > diff --git a/drivers/spi/spi-mxic.c b/drivers/spi/spi-mxic.c
> > index 69491f3a515d..c3f4136a7c1d 100644
> > --- a/drivers/spi/spi-mxic.c
> > +++ b/drivers/spi/spi-mxic.c
> > @@ -356,6 +356,7 @@ static int mxic_spi_mem_exec_op(struct spi_mem *mem,
> >         int nio = 1, i, ret;
> >         u32 ss_ctrl;
> >         u8 addr[8];
> > +       u8 cmd[2];
> >  
> >         ret = mxic_spi_set_freq(mxic, mem->spi->max_speed_hz);
> >         if (ret)
> > @@ -393,7 +394,10 @@ static int mxic_spi_mem_exec_op(struct spi_mem *mem,
> >         writel(readl(mxic->regs + HC_CFG) | HC_CFG_MAN_CS_ASSERT,
> >                mxic->regs + HC_CFG);
> >  
> > -       ret = mxic_spi_data_xfer(mxic, &op->cmd.opcode, NULL, 1);
> > +       for (i = 0; i < op->cmd.nbytes; i++)
> > +               cmd[i] = op->cmd.opcode >> (8 * (op->cmd.nbytes - i - 1));
> > +
> > +       ret = mxic_spi_data_xfer(mxic, cmd, NULL, op->cmd.nbytes);
> >         if (ret)
> >                 goto out;
> >
Boris Brezillon May 21, 2020, 8:16 p.m. UTC | #4
On Fri, 22 May 2020 01:33:15 +0530
Pratyush Yadav <p.yadav@ti.com> wrote:

> On 22/05/20 01:11AM, Pratyush Yadav wrote:
> > On 21/05/20 08:22PM, Boris Brezillon wrote:  
> > > On Wed, 20 May 2020 22:00:38 +0530
> > > Pratyush Yadav <p.yadav@ti.com> wrote:
> > >   
> > > > In xSPI mode, flashes expect 2-byte opcodes. The second byte is called
> > > > the "command extension". There can be 3 types of extensions in xSPI:
> > > > repeat, invert, and hex. When the extension type is "repeat", the same
> > > > opcode is sent twice. When it is "invert", the second byte is the
> > > > inverse of the opcode. When it is "hex" an additional opcode byte based
> > > > is sent with the command whose value can be anything.
> > > > 
> > > > So, make opcode a 16-bit value and add a 'nbytes', similar to how
> > > > multiple address widths are handled.
> > > > 
> > > > Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
> > > > ---
> > > >  include/linux/spi/spi-mem.h | 5 ++++-
> > > >  1 file changed, 4 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
> > > > index e3dcb956bf61..731bb64c6ba6 100644
> > > > --- a/include/linux/spi/spi-mem.h
> > > > +++ b/include/linux/spi/spi-mem.h
> > > > @@ -69,6 +69,8 @@ enum spi_mem_data_dir {
> > > >  
> > > >  /**
> > > >   * struct spi_mem_op - describes a SPI memory operation
> > > > + * @cmd.nbytes: number of opcode bytes (only 1 or 2 are valid). The opcode is
> > > > + *		sent MSB-first.
> > > >   * @cmd.buswidth: number of IO lines used to transmit the command
> > > >   * @cmd.opcode: operation opcode
> > > >   * @cmd.dtr: whether the command opcode should be sent in DTR mode or not
> > > > @@ -94,9 +96,10 @@ enum spi_mem_data_dir {
> > > >   */
> > > >  struct spi_mem_op {
> > > >  	struct {
> > > > +		u8 nbytes;
> > > >  		u8 buswidth;
> > > >  		u8 dtr : 1;
> > > > -		u8 opcode;
> > > > +		u16 opcode;
> > > >  	} cmd;
> > > >  
> > > >  	struct {  
> > > 
> > > As mentioned in one of my previous review, you should patch the mxic
> > > driver before extending the opcode field:  
> > 
> > IIUC, this patchset doesn't break original functionality of the driver. 
> > It will work like before with 1-byte opcodes. So I don't think it is the 
> > responsibility of this patchset to enhance the driver. It didn't work 
> > before with 2-byte opcodes, it won't work now. IMO this should be a 
> > separate, independent change.  
> 
> Scratch that. Big/little endian issue. If you'd drop your Signed-off-by, 
> I'll write the commit message and patch it in.

Just add a Suggested-by, that should be fine.

>   
> > > --->8---  
> > > diff --git a/drivers/spi/spi-mxic.c b/drivers/spi/spi-mxic.c
> > > index 69491f3a515d..c3f4136a7c1d 100644
> > > --- a/drivers/spi/spi-mxic.c
> > > +++ b/drivers/spi/spi-mxic.c
> > > @@ -356,6 +356,7 @@ static int mxic_spi_mem_exec_op(struct spi_mem *mem,
> > >         int nio = 1, i, ret;
> > >         u32 ss_ctrl;
> > >         u8 addr[8];
> > > +       u8 cmd[2];
> > >  
> > >         ret = mxic_spi_set_freq(mxic, mem->spi->max_speed_hz);
> > >         if (ret)
> > > @@ -393,7 +394,10 @@ static int mxic_spi_mem_exec_op(struct spi_mem *mem,
> > >         writel(readl(mxic->regs + HC_CFG) | HC_CFG_MAN_CS_ASSERT,
> > >                mxic->regs + HC_CFG);
> > >  
> > > -       ret = mxic_spi_data_xfer(mxic, &op->cmd.opcode, NULL, 1);
> > > +       for (i = 0; i < op->cmd.nbytes; i++)
> > > +               cmd[i] = op->cmd.opcode >> (8 * (op->cmd.nbytes - i - 1));
> > > +
> > > +       ret = mxic_spi_data_xfer(mxic, cmd, NULL, op->cmd.nbytes);
> > >         if (ret)
> > >                 goto out;
> > >    
>
Pratyush Yadav May 22, 2020, 6:23 p.m. UTC | #5
Hi Boris,

On 21/05/20 08:22PM, Boris Brezillon wrote:
> On Wed, 20 May 2020 22:00:38 +0530
> Pratyush Yadav <p.yadav@ti.com> wrote:
> 
> As mentioned in one of my previous review, you should patch the mxic
> driver before extending the opcode field:
> 
> --->8---
> diff --git a/drivers/spi/spi-mxic.c b/drivers/spi/spi-mxic.c
> index 69491f3a515d..c3f4136a7c1d 100644
> --- a/drivers/spi/spi-mxic.c
> +++ b/drivers/spi/spi-mxic.c
> @@ -356,6 +356,7 @@ static int mxic_spi_mem_exec_op(struct spi_mem *mem,
>         int nio = 1, i, ret;
>         u32 ss_ctrl;
>         u8 addr[8];
> +       u8 cmd[2];

Regarding your comment about bisect-ability, how about I change this to:
  
  u8 cmd[sizeof(op->cmd.opcode)];

and put this patch before the change to 2-byte opcodes. This should also 
make it resistent to further changes in opcode size. Does that sound 
like a sane idea?
  
>         ret = mxic_spi_set_freq(mxic, mem->spi->max_speed_hz);
>         if (ret)
> @@ -393,7 +394,10 @@ static int mxic_spi_mem_exec_op(struct spi_mem *mem,
>         writel(readl(mxic->regs + HC_CFG) | HC_CFG_MAN_CS_ASSERT,
>                mxic->regs + HC_CFG);
>  
> -       ret = mxic_spi_data_xfer(mxic, &op->cmd.opcode, NULL, 1);
> +       for (i = 0; i < op->cmd.nbytes; i++)
> +               cmd[i] = op->cmd.opcode >> (8 * (op->cmd.nbytes - i - 1));
> +
> +       ret = mxic_spi_data_xfer(mxic, cmd, NULL, op->cmd.nbytes);
>         if (ret)
>                 goto out;
>
diff mbox series

Patch

diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
index e3dcb956bf61..731bb64c6ba6 100644
--- a/include/linux/spi/spi-mem.h
+++ b/include/linux/spi/spi-mem.h
@@ -69,6 +69,8 @@  enum spi_mem_data_dir {
 
 /**
  * struct spi_mem_op - describes a SPI memory operation
+ * @cmd.nbytes: number of opcode bytes (only 1 or 2 are valid). The opcode is
+ *		sent MSB-first.
  * @cmd.buswidth: number of IO lines used to transmit the command
  * @cmd.opcode: operation opcode
  * @cmd.dtr: whether the command opcode should be sent in DTR mode or not
@@ -94,9 +96,10 @@  enum spi_mem_data_dir {
  */
 struct spi_mem_op {
 	struct {
+		u8 nbytes;
 		u8 buswidth;
 		u8 dtr : 1;
-		u8 opcode;
+		u16 opcode;
 	} cmd;
 
 	struct {