All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH V1] mtd: mtk-nor: set controller to 4B mode with large capacity flash
@ 2017-03-30  8:23 ` Guochun Mao
  0 siblings, 0 replies; 18+ messages in thread
From: Guochun Mao @ 2017-03-30  8:23 UTC (permalink / raw)
  To: Boris Brezillon, Marek Vasut
  Cc: David Woodhouse, Richard Weinberger, Cyrille Pitchen,
	Rob Herring, Mark Rutland, Matthias Brugger, Russell King,
	linux-mtd, devicetree, linux-arm-kernel, linux-mediatek,
	linux-kernel

Guochun Mao (1):
  mtd: mtk-nor: set controller to 4B mode with large capacity flash

 drivers/mtd/spi-nor/mtk-quadspi.c | 7 +++++++
 1 file changed, 7 insertions(+)

-- 
1.9.1 

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [PATCH V1] mtd: mtk-nor: set controller to 4B mode with large capacity flash
@ 2017-03-30  8:23 ` Guochun Mao
  0 siblings, 0 replies; 18+ messages in thread
From: Guochun Mao @ 2017-03-30  8:23 UTC (permalink / raw)
  To: Boris Brezillon, Marek Vasut
  Cc: Mark Rutland, devicetree, Richard Weinberger, Russell King,
	linux-kernel, Rob Herring, linux-mtd, Matthias Brugger,
	linux-mediatek, Cyrille Pitchen, David Woodhouse,
	linux-arm-kernel

Guochun Mao (1):
  mtd: mtk-nor: set controller to 4B mode with large capacity flash

 drivers/mtd/spi-nor/mtk-quadspi.c | 7 +++++++
 1 file changed, 7 insertions(+)

-- 
1.9.1 

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [PATCH V1] mtd: mtk-nor: set controller to 4B mode with large capacity flash
@ 2017-03-30  8:23 ` Guochun Mao
  0 siblings, 0 replies; 18+ messages in thread
From: Guochun Mao @ 2017-03-30  8:23 UTC (permalink / raw)
  To: linux-arm-kernel

Guochun Mao (1):
  mtd: mtk-nor: set controller to 4B mode with large capacity flash

 drivers/mtd/spi-nor/mtk-quadspi.c | 7 +++++++
 1 file changed, 7 insertions(+)

-- 
1.9.1 

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [PATCH V1 1/1] mtd: mtk-nor: set controller to 4B mode with large capacity flash
  2017-03-30  8:23 ` Guochun Mao
  (?)
@ 2017-03-30  8:23   ` Guochun Mao
  -1 siblings, 0 replies; 18+ messages in thread
From: Guochun Mao @ 2017-03-30  8:23 UTC (permalink / raw)
  To: Boris Brezillon, Marek Vasut
  Cc: David Woodhouse, Richard Weinberger, Cyrille Pitchen,
	Rob Herring, Mark Rutland, Matthias Brugger, Russell King,
	linux-mtd, devicetree, linux-arm-kernel, linux-mediatek,
	linux-kernel, Guochun Mao

when nor's size larger than 16MByte, nor and controller should
enter 4Byte mode simultaneously.

Signed-off-by: Guochun Mao <guochun.mao@mediatek.com>
---
 drivers/mtd/spi-nor/mtk-quadspi.c |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c b/drivers/mtd/spi-nor/mtk-quadspi.c
index e661877..05cd8a8 100644
--- a/drivers/mtd/spi-nor/mtk-quadspi.c
+++ b/drivers/mtd/spi-nor/mtk-quadspi.c
@@ -369,6 +369,13 @@ static int mt8173_nor_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf,
 		/* We only handle 1 byte */
 		ret = mt8173_nor_wr_sr(mt8173_nor, *buf);
 		break;
+	case SPINOR_OP_EN4B:
+		/* Set nor controller to 4-byte address mode,
+		 * and simultaneously set nor flash.
+		 * This case should cooperate with default operation.
+		 */
+		writeb(readb(mt8173_nor->base + MTK_NOR_DUAL_REG) | 0x10,
+				mt8173_nor->base + MTK_NOR_DUAL_REG);
 	default:
 		ret = mt8173_nor_do_tx_rx(mt8173_nor, opcode, buf, len, NULL, 0);
 		if (ret)
-- 
1.7.9.5

^ permalink raw reply related	[flat|nested] 18+ messages in thread

* [PATCH V1 1/1] mtd: mtk-nor: set controller to 4B mode with large capacity flash
@ 2017-03-30  8:23   ` Guochun Mao
  0 siblings, 0 replies; 18+ messages in thread
From: Guochun Mao @ 2017-03-30  8:23 UTC (permalink / raw)
  To: Boris Brezillon, Marek Vasut
  Cc: Mark Rutland, devicetree, Guochun Mao, Richard Weinberger,
	Russell King, linux-kernel, Rob Herring, linux-mtd,
	Matthias Brugger, linux-mediatek, Cyrille Pitchen,
	David Woodhouse, linux-arm-kernel

when nor's size larger than 16MByte, nor and controller should
enter 4Byte mode simultaneously.

Signed-off-by: Guochun Mao <guochun.mao@mediatek.com>
---
 drivers/mtd/spi-nor/mtk-quadspi.c |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c b/drivers/mtd/spi-nor/mtk-quadspi.c
index e661877..05cd8a8 100644
--- a/drivers/mtd/spi-nor/mtk-quadspi.c
+++ b/drivers/mtd/spi-nor/mtk-quadspi.c
@@ -369,6 +369,13 @@ static int mt8173_nor_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf,
 		/* We only handle 1 byte */
 		ret = mt8173_nor_wr_sr(mt8173_nor, *buf);
 		break;
+	case SPINOR_OP_EN4B:
+		/* Set nor controller to 4-byte address mode,
+		 * and simultaneously set nor flash.
+		 * This case should cooperate with default operation.
+		 */
+		writeb(readb(mt8173_nor->base + MTK_NOR_DUAL_REG) | 0x10,
+				mt8173_nor->base + MTK_NOR_DUAL_REG);
 	default:
 		ret = mt8173_nor_do_tx_rx(mt8173_nor, opcode, buf, len, NULL, 0);
 		if (ret)
-- 
1.7.9.5

^ permalink raw reply related	[flat|nested] 18+ messages in thread

* [PATCH V1 1/1] mtd: mtk-nor: set controller to 4B mode with large capacity flash
@ 2017-03-30  8:23   ` Guochun Mao
  0 siblings, 0 replies; 18+ messages in thread
From: Guochun Mao @ 2017-03-30  8:23 UTC (permalink / raw)
  To: linux-arm-kernel

when nor's size larger than 16MByte, nor and controller should
enter 4Byte mode simultaneously.

Signed-off-by: Guochun Mao <guochun.mao@mediatek.com>
---
 drivers/mtd/spi-nor/mtk-quadspi.c |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c b/drivers/mtd/spi-nor/mtk-quadspi.c
index e661877..05cd8a8 100644
--- a/drivers/mtd/spi-nor/mtk-quadspi.c
+++ b/drivers/mtd/spi-nor/mtk-quadspi.c
@@ -369,6 +369,13 @@ static int mt8173_nor_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf,
 		/* We only handle 1 byte */
 		ret = mt8173_nor_wr_sr(mt8173_nor, *buf);
 		break;
+	case SPINOR_OP_EN4B:
+		/* Set nor controller to 4-byte address mode,
+		 * and simultaneously set nor flash.
+		 * This case should cooperate with default operation.
+		 */
+		writeb(readb(mt8173_nor->base + MTK_NOR_DUAL_REG) | 0x10,
+				mt8173_nor->base + MTK_NOR_DUAL_REG);
 	default:
 		ret = mt8173_nor_do_tx_rx(mt8173_nor, opcode, buf, len, NULL, 0);
 		if (ret)
-- 
1.7.9.5

^ permalink raw reply related	[flat|nested] 18+ messages in thread

* Re: [PATCH V1 1/1] mtd: mtk-nor: set controller to 4B mode with large capacity flash
  2017-03-30  8:23   ` Guochun Mao
@ 2017-03-30 10:00     ` Marek Vasut
  -1 siblings, 0 replies; 18+ messages in thread
From: Marek Vasut @ 2017-03-30 10:00 UTC (permalink / raw)
  To: Guochun Mao, Boris Brezillon
  Cc: David Woodhouse, Richard Weinberger, Cyrille Pitchen,
	Rob Herring, Mark Rutland, Matthias Brugger, Russell King,
	linux-mtd, devicetree, linux-arm-kernel, linux-mediatek,
	linux-kernel

On 03/30/2017 10:23 AM, Guochun Mao wrote:
> when nor's size larger than 16MByte, nor and controller should
> enter 4Byte mode simultaneously.
> 
> Signed-off-by: Guochun Mao <guochun.mao@mediatek.com>
> ---
>  drivers/mtd/spi-nor/mtk-quadspi.c |    7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c b/drivers/mtd/spi-nor/mtk-quadspi.c
> index e661877..05cd8a8 100644
> --- a/drivers/mtd/spi-nor/mtk-quadspi.c
> +++ b/drivers/mtd/spi-nor/mtk-quadspi.c
> @@ -369,6 +369,13 @@ static int mt8173_nor_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf,
>  		/* We only handle 1 byte */
>  		ret = mt8173_nor_wr_sr(mt8173_nor, *buf);
>  		break;
> +	case SPINOR_OP_EN4B:
> +		/* Set nor controller to 4-byte address mode,
> +		 * and simultaneously set nor flash.
> +		 * This case should cooperate with default operation.
> +		 */
> +		writeb(readb(mt8173_nor->base + MTK_NOR_DUAL_REG) | 0x10,
> +				mt8173_nor->base + MTK_NOR_DUAL_REG);

And what happens on READ then ? Who clears that bit when protocol
changes ? You probably want something like cqspi_set_protocol()
instead, which is invoked from {read,write}{,_reg}() and erase().

>  	default:
>  		ret = mt8173_nor_do_tx_rx(mt8173_nor, opcode, buf, len, NULL, 0);
>  		if (ret)
> 


-- 
Best regards,
Marek Vasut

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [PATCH V1 1/1] mtd: mtk-nor: set controller to 4B mode with large capacity flash
@ 2017-03-30 10:00     ` Marek Vasut
  0 siblings, 0 replies; 18+ messages in thread
From: Marek Vasut @ 2017-03-30 10:00 UTC (permalink / raw)
  To: linux-arm-kernel

On 03/30/2017 10:23 AM, Guochun Mao wrote:
> when nor's size larger than 16MByte, nor and controller should
> enter 4Byte mode simultaneously.
> 
> Signed-off-by: Guochun Mao <guochun.mao@mediatek.com>
> ---
>  drivers/mtd/spi-nor/mtk-quadspi.c |    7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c b/drivers/mtd/spi-nor/mtk-quadspi.c
> index e661877..05cd8a8 100644
> --- a/drivers/mtd/spi-nor/mtk-quadspi.c
> +++ b/drivers/mtd/spi-nor/mtk-quadspi.c
> @@ -369,6 +369,13 @@ static int mt8173_nor_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf,
>  		/* We only handle 1 byte */
>  		ret = mt8173_nor_wr_sr(mt8173_nor, *buf);
>  		break;
> +	case SPINOR_OP_EN4B:
> +		/* Set nor controller to 4-byte address mode,
> +		 * and simultaneously set nor flash.
> +		 * This case should cooperate with default operation.
> +		 */
> +		writeb(readb(mt8173_nor->base + MTK_NOR_DUAL_REG) | 0x10,
> +				mt8173_nor->base + MTK_NOR_DUAL_REG);

And what happens on READ then ? Who clears that bit when protocol
changes ? You probably want something like cqspi_set_protocol()
instead, which is invoked from {read,write}{,_reg}() and erase().

>  	default:
>  		ret = mt8173_nor_do_tx_rx(mt8173_nor, opcode, buf, len, NULL, 0);
>  		if (ret)
> 


-- 
Best regards,
Marek Vasut

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH V1 1/1] mtd: mtk-nor: set controller to 4B mode with large capacity flash
  2017-03-30  8:23   ` Guochun Mao
@ 2017-03-30 17:40     ` Cyrille Pitchen
  -1 siblings, 0 replies; 18+ messages in thread
From: Cyrille Pitchen @ 2017-03-30 17:40 UTC (permalink / raw)
  To: Guochun Mao, Boris Brezillon, Marek Vasut
  Cc: Mark Rutland, devicetree, Richard Weinberger, Russell King,
	linux-kernel, Rob Herring, linux-mtd, Matthias Brugger,
	linux-mediatek, Cyrille Pitchen, David Woodhouse,
	linux-arm-kernel

Hi Guochun,

Le 30/03/2017 à 10:23, Guochun Mao a écrit :
> when nor's size larger than 16MByte, nor and controller should
> enter 4Byte mode simultaneously.
> 
> Signed-off-by: Guochun Mao <guochun.mao@mediatek.com>
> ---
>  drivers/mtd/spi-nor/mtk-quadspi.c |    7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c b/drivers/mtd/spi-nor/mtk-quadspi.c
> index e661877..05cd8a8 100644
> --- a/drivers/mtd/spi-nor/mtk-quadspi.c
> +++ b/drivers/mtd/spi-nor/mtk-quadspi.c
> @@ -369,6 +369,13 @@ static int mt8173_nor_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf,
>  		/* We only handle 1 byte */
>  		ret = mt8173_nor_wr_sr(mt8173_nor, *buf);
>  		break;
> +	case SPINOR_OP_EN4B:
> +		/* Set nor controller to 4-byte address mode,
> +		 * and simultaneously set nor flash.
> +		 * This case should cooperate with default operation.
> +		 */
> +		writeb(readb(mt8173_nor->base + MTK_NOR_DUAL_REG) | 0x10,
> +				mt8173_nor->base + MTK_NOR_DUAL_REG);

This is not good: you should check in both mt8173_nor_read() and
mt8173_nor_write() whether nor->addr_width is either 3 or 4.

from include/linux/mtd/spi-nor.h:
 * @addr_width:		number of address bytes

Besides SPI commands using an op code from 4-byte address instruction
set always carry a 4-byte address. They can be used directly, without
sending the SPINOR_OP_EN4B before. So you cannot assume that addresses
will be 4-byte long only if your SPI controller driver has seen a
SPINOR_OP_EN4B command before. This assumption is wrong.

SPI controller driver should never check SPINOR_OP_* op codes like this.

Then, testing SPINOR_OP_RDSR from mt8173_nor_read_reg() or
SPINOR_OP_WRSR from mt8173_nor_write_reg() is not a good practice too:
op codes may change depending on the memory manufacturer. So testing op
code values like you do can work with some memories but maybe not all.

Finally, don't use 0x10, please define a macro instead.

Best regards,

Cyrille

>  	default:
>  		ret = mt8173_nor_do_tx_rx(mt8173_nor, opcode, buf, len, NULL, 0);
>  		if (ret)
> 

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [PATCH V1 1/1] mtd: mtk-nor: set controller to 4B mode with large capacity flash
@ 2017-03-30 17:40     ` Cyrille Pitchen
  0 siblings, 0 replies; 18+ messages in thread
From: Cyrille Pitchen @ 2017-03-30 17:40 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Guochun,

Le 30/03/2017 ? 10:23, Guochun Mao a ?crit :
> when nor's size larger than 16MByte, nor and controller should
> enter 4Byte mode simultaneously.
> 
> Signed-off-by: Guochun Mao <guochun.mao@mediatek.com>
> ---
>  drivers/mtd/spi-nor/mtk-quadspi.c |    7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c b/drivers/mtd/spi-nor/mtk-quadspi.c
> index e661877..05cd8a8 100644
> --- a/drivers/mtd/spi-nor/mtk-quadspi.c
> +++ b/drivers/mtd/spi-nor/mtk-quadspi.c
> @@ -369,6 +369,13 @@ static int mt8173_nor_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf,
>  		/* We only handle 1 byte */
>  		ret = mt8173_nor_wr_sr(mt8173_nor, *buf);
>  		break;
> +	case SPINOR_OP_EN4B:
> +		/* Set nor controller to 4-byte address mode,
> +		 * and simultaneously set nor flash.
> +		 * This case should cooperate with default operation.
> +		 */
> +		writeb(readb(mt8173_nor->base + MTK_NOR_DUAL_REG) | 0x10,
> +				mt8173_nor->base + MTK_NOR_DUAL_REG);

This is not good: you should check in both mt8173_nor_read() and
mt8173_nor_write() whether nor->addr_width is either 3 or 4.

from include/linux/mtd/spi-nor.h:
 * @addr_width:		number of address bytes

Besides SPI commands using an op code from 4-byte address instruction
set always carry a 4-byte address. They can be used directly, without
sending the SPINOR_OP_EN4B before. So you cannot assume that addresses
will be 4-byte long only if your SPI controller driver has seen a
SPINOR_OP_EN4B command before. This assumption is wrong.

SPI controller driver should never check SPINOR_OP_* op codes like this.

Then, testing SPINOR_OP_RDSR from mt8173_nor_read_reg() or
SPINOR_OP_WRSR from mt8173_nor_write_reg() is not a good practice too:
op codes may change depending on the memory manufacturer. So testing op
code values like you do can work with some memories but maybe not all.

Finally, don't use 0x10, please define a macro instead.

Best regards,

Cyrille

>  	default:
>  		ret = mt8173_nor_do_tx_rx(mt8173_nor, opcode, buf, len, NULL, 0);
>  		if (ret)
> 

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH V1 1/1] mtd: mtk-nor: set controller to 4B mode with large capacity flash
@ 2017-03-31  2:26       ` Guochun Mao
  0 siblings, 0 replies; 18+ messages in thread
From: Guochun Mao @ 2017-03-31  2:26 UTC (permalink / raw)
  To: Cyrille Pitchen, Marek Vasut
  Cc: Boris Brezillon, Mark Rutland, devicetree, Richard Weinberger,
	Russell King, linux-kernel, Rob Herring, linux-mtd,
	Matthias Brugger, linux-mediatek, Cyrille Pitchen,
	David Woodhouse, linux-arm-kernel

Hi Cyrille, Marek,

Thanks for your suggestions.

On Thu, 2017-03-30 at 19:40 +0200, Cyrille Pitchen wrote:
> Hi Guochun,
> 
> Le 30/03/2017 à 10:23, Guochun Mao a écrit :
> > when nor's size larger than 16MByte, nor and controller should
> > enter 4Byte mode simultaneously.
> > 
> > Signed-off-by: Guochun Mao <guochun.mao@mediatek.com>
> > ---
> >  drivers/mtd/spi-nor/mtk-quadspi.c |    7 +++++++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c b/drivers/mtd/spi-nor/mtk-quadspi.c
> > index e661877..05cd8a8 100644
> > --- a/drivers/mtd/spi-nor/mtk-quadspi.c
> > +++ b/drivers/mtd/spi-nor/mtk-quadspi.c
> > @@ -369,6 +369,13 @@ static int mt8173_nor_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf,
> >  		/* We only handle 1 byte */
> >  		ret = mt8173_nor_wr_sr(mt8173_nor, *buf);
> >  		break;
> > +	case SPINOR_OP_EN4B:
> > +		/* Set nor controller to 4-byte address mode,
> > +		 * and simultaneously set nor flash.
> > +		 * This case should cooperate with default operation.
> > +		 */
> > +		writeb(readb(mt8173_nor->base + MTK_NOR_DUAL_REG) | 0x10,
> > +				mt8173_nor->base + MTK_NOR_DUAL_REG);
> 
> This is not good: you should check in both mt8173_nor_read() and
> mt8173_nor_write() whether nor->addr_width is either 3 or 4.
> 
> from include/linux/mtd/spi-nor.h:
>  * @addr_width:		number of address bytes
> 
> Besides SPI commands using an op code from 4-byte address instruction
> set always carry a 4-byte address. They can be used directly, without
> sending the SPINOR_OP_EN4B before. So you cannot assume that addresses
> will be 4-byte long only if your SPI controller driver has seen a
> SPINOR_OP_EN4B command before. This assumption is wrong.
Nor->addr_width is assigned in spi_nor_scan in spi-nor.c, and it's not
modified in later process.
Does it means that we will not switch nor between 3Byte address and
4Byte?
So, is it better to check nor->addr_width when do nor initialization?

> 
> SPI controller driver should never check SPINOR_OP_* op codes like this.
I agree that SPI controller driver should not check SPINOR_OP_* op codes
like what I do.
I will correct it next version.

Best Regards,
Guochun
> 
> Then, testing SPINOR_OP_RDSR from mt8173_nor_read_reg() or
> SPINOR_OP_WRSR from mt8173_nor_write_reg() is not a good practice too:
> op codes may change depending on the memory manufacturer. So testing op
> code values like you do can work with some memories but maybe not all.
> 
> Finally, don't use 0x10, please define a macro instead.
> 
> Best regards,
> 
> Cyrille
> 
> >  	default:
> >  		ret = mt8173_nor_do_tx_rx(mt8173_nor, opcode, buf, len, NULL, 0);
> >  		if (ret)
> > 
> 

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH V1 1/1] mtd: mtk-nor: set controller to 4B mode with large capacity flash
@ 2017-03-31  2:26       ` Guochun Mao
  0 siblings, 0 replies; 18+ messages in thread
From: Guochun Mao @ 2017-03-31  2:26 UTC (permalink / raw)
  To: Cyrille Pitchen, Marek Vasut
  Cc: Boris Brezillon, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
	Richard Weinberger, Russell King,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
	linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Matthias Brugger,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Cyrille Pitchen,
	David Woodhouse,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r

Hi Cyrille, Marek,

Thanks for your suggestions.

On Thu, 2017-03-30 at 19:40 +0200, Cyrille Pitchen wrote:
> Hi Guochun,
> 
> Le 30/03/2017 à 10:23, Guochun Mao a écrit :
> > when nor's size larger than 16MByte, nor and controller should
> > enter 4Byte mode simultaneously.
> > 
> > Signed-off-by: Guochun Mao <guochun.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> > ---
> >  drivers/mtd/spi-nor/mtk-quadspi.c |    7 +++++++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c b/drivers/mtd/spi-nor/mtk-quadspi.c
> > index e661877..05cd8a8 100644
> > --- a/drivers/mtd/spi-nor/mtk-quadspi.c
> > +++ b/drivers/mtd/spi-nor/mtk-quadspi.c
> > @@ -369,6 +369,13 @@ static int mt8173_nor_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf,
> >  		/* We only handle 1 byte */
> >  		ret = mt8173_nor_wr_sr(mt8173_nor, *buf);
> >  		break;
> > +	case SPINOR_OP_EN4B:
> > +		/* Set nor controller to 4-byte address mode,
> > +		 * and simultaneously set nor flash.
> > +		 * This case should cooperate with default operation.
> > +		 */
> > +		writeb(readb(mt8173_nor->base + MTK_NOR_DUAL_REG) | 0x10,
> > +				mt8173_nor->base + MTK_NOR_DUAL_REG);
> 
> This is not good: you should check in both mt8173_nor_read() and
> mt8173_nor_write() whether nor->addr_width is either 3 or 4.
> 
> from include/linux/mtd/spi-nor.h:
>  * @addr_width:		number of address bytes
> 
> Besides SPI commands using an op code from 4-byte address instruction
> set always carry a 4-byte address. They can be used directly, without
> sending the SPINOR_OP_EN4B before. So you cannot assume that addresses
> will be 4-byte long only if your SPI controller driver has seen a
> SPINOR_OP_EN4B command before. This assumption is wrong.
Nor->addr_width is assigned in spi_nor_scan in spi-nor.c, and it's not
modified in later process.
Does it means that we will not switch nor between 3Byte address and
4Byte?
So, is it better to check nor->addr_width when do nor initialization?

> 
> SPI controller driver should never check SPINOR_OP_* op codes like this.
I agree that SPI controller driver should not check SPINOR_OP_* op codes
like what I do.
I will correct it next version.

Best Regards,
Guochun
> 
> Then, testing SPINOR_OP_RDSR from mt8173_nor_read_reg() or
> SPINOR_OP_WRSR from mt8173_nor_write_reg() is not a good practice too:
> op codes may change depending on the memory manufacturer. So testing op
> code values like you do can work with some memories but maybe not all.
> 
> Finally, don't use 0x10, please define a macro instead.
> 
> Best regards,
> 
> Cyrille
> 
> >  	default:
> >  		ret = mt8173_nor_do_tx_rx(mt8173_nor, opcode, buf, len, NULL, 0);
> >  		if (ret)
> > 
> 


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [PATCH V1 1/1] mtd: mtk-nor: set controller to 4B mode with large capacity flash
@ 2017-03-31  2:26       ` Guochun Mao
  0 siblings, 0 replies; 18+ messages in thread
From: Guochun Mao @ 2017-03-31  2:26 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Cyrille, Marek,

Thanks for your suggestions.

On Thu, 2017-03-30 at 19:40 +0200, Cyrille Pitchen wrote:
> Hi Guochun,
> 
> Le 30/03/2017 ? 10:23, Guochun Mao a ?crit :
> > when nor's size larger than 16MByte, nor and controller should
> > enter 4Byte mode simultaneously.
> > 
> > Signed-off-by: Guochun Mao <guochun.mao@mediatek.com>
> > ---
> >  drivers/mtd/spi-nor/mtk-quadspi.c |    7 +++++++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c b/drivers/mtd/spi-nor/mtk-quadspi.c
> > index e661877..05cd8a8 100644
> > --- a/drivers/mtd/spi-nor/mtk-quadspi.c
> > +++ b/drivers/mtd/spi-nor/mtk-quadspi.c
> > @@ -369,6 +369,13 @@ static int mt8173_nor_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf,
> >  		/* We only handle 1 byte */
> >  		ret = mt8173_nor_wr_sr(mt8173_nor, *buf);
> >  		break;
> > +	case SPINOR_OP_EN4B:
> > +		/* Set nor controller to 4-byte address mode,
> > +		 * and simultaneously set nor flash.
> > +		 * This case should cooperate with default operation.
> > +		 */
> > +		writeb(readb(mt8173_nor->base + MTK_NOR_DUAL_REG) | 0x10,
> > +				mt8173_nor->base + MTK_NOR_DUAL_REG);
> 
> This is not good: you should check in both mt8173_nor_read() and
> mt8173_nor_write() whether nor->addr_width is either 3 or 4.
> 
> from include/linux/mtd/spi-nor.h:
>  * @addr_width:		number of address bytes
> 
> Besides SPI commands using an op code from 4-byte address instruction
> set always carry a 4-byte address. They can be used directly, without
> sending the SPINOR_OP_EN4B before. So you cannot assume that addresses
> will be 4-byte long only if your SPI controller driver has seen a
> SPINOR_OP_EN4B command before. This assumption is wrong.
Nor->addr_width is assigned in spi_nor_scan in spi-nor.c, and it's not
modified in later process.
Does it means that we will not switch nor between 3Byte address and
4Byte?
So, is it better to check nor->addr_width when do nor initialization?

> 
> SPI controller driver should never check SPINOR_OP_* op codes like this.
I agree that SPI controller driver should not check SPINOR_OP_* op codes
like what I do.
I will correct it next version.

Best Regards,
Guochun
> 
> Then, testing SPINOR_OP_RDSR from mt8173_nor_read_reg() or
> SPINOR_OP_WRSR from mt8173_nor_write_reg() is not a good practice too:
> op codes may change depending on the memory manufacturer. So testing op
> code values like you do can work with some memories but maybe not all.
> 
> Finally, don't use 0x10, please define a macro instead.
> 
> Best regards,
> 
> Cyrille
> 
> >  	default:
> >  		ret = mt8173_nor_do_tx_rx(mt8173_nor, opcode, buf, len, NULL, 0);
> >  		if (ret)
> > 
> 

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH V1 1/1] mtd: mtk-nor: set controller to 4B mode with large capacity flash
  2017-03-31  2:26       ` Guochun Mao
@ 2017-03-31  8:56         ` Cyrille Pitchen
  -1 siblings, 0 replies; 18+ messages in thread
From: Cyrille Pitchen @ 2017-03-31  8:56 UTC (permalink / raw)
  To: Guochun Mao, Marek Vasut
  Cc: Boris Brezillon, Mark Rutland, devicetree, Richard Weinberger,
	Russell King, linux-kernel, Rob Herring, linux-mtd,
	Matthias Brugger, linux-mediatek, Cyrille Pitchen,
	David Woodhouse, linux-arm-kernel

Le 31/03/2017 à 04:26, Guochun Mao a écrit :
> Hi Cyrille, Marek,
> 
> Thanks for your suggestions.
> 
> On Thu, 2017-03-30 at 19:40 +0200, Cyrille Pitchen wrote:
>> Hi Guochun,
>>
>> Le 30/03/2017 à 10:23, Guochun Mao a écrit :
>>> when nor's size larger than 16MByte, nor and controller should
>>> enter 4Byte mode simultaneously.
>>>
>>> Signed-off-by: Guochun Mao <guochun.mao@mediatek.com>
>>> ---
>>>  drivers/mtd/spi-nor/mtk-quadspi.c |    7 +++++++
>>>  1 file changed, 7 insertions(+)
>>>
>>> diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c b/drivers/mtd/spi-nor/mtk-quadspi.c
>>> index e661877..05cd8a8 100644
>>> --- a/drivers/mtd/spi-nor/mtk-quadspi.c
>>> +++ b/drivers/mtd/spi-nor/mtk-quadspi.c
>>> @@ -369,6 +369,13 @@ static int mt8173_nor_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf,
>>>  		/* We only handle 1 byte */
>>>  		ret = mt8173_nor_wr_sr(mt8173_nor, *buf);
>>>  		break;
>>> +	case SPINOR_OP_EN4B:
>>> +		/* Set nor controller to 4-byte address mode,
>>> +		 * and simultaneously set nor flash.
>>> +		 * This case should cooperate with default operation.
>>> +		 */
>>> +		writeb(readb(mt8173_nor->base + MTK_NOR_DUAL_REG) | 0x10,
>>> +				mt8173_nor->base + MTK_NOR_DUAL_REG);
>>
>> This is not good: you should check in both mt8173_nor_read() and
>> mt8173_nor_write() whether nor->addr_width is either 3 or 4.
>>
>> from include/linux/mtd/spi-nor.h:
>>  * @addr_width:		number of address bytes
>>
>> Besides SPI commands using an op code from 4-byte address instruction
>> set always carry a 4-byte address. They can be used directly, without
>> sending the SPINOR_OP_EN4B before. So you cannot assume that addresses
>> will be 4-byte long only if your SPI controller driver has seen a
>> SPINOR_OP_EN4B command before. This assumption is wrong.
> Nor->addr_width is assigned in spi_nor_scan in spi-nor.c, and it's not
> modified in later process.
> Does it means that we will not switch nor between 3Byte address and
> 4Byte?
> So, is it better to check nor->addr_width when do nor initialization?
>

Currently yes, nor->addr_width, nor->read_opcode, nor->read_dummy, and
nor->program_opcode are set once for all in spi_nor_scan().

However, nor->read() is likely to be called soon from spi_nor_scan()
with values of nor->addr_width, nor->read_opcode and nor->read_dummy
different from those selected when exiting spi_nor_scan().

So nor->read() / mt8173_nor_read should check nor->addr_width,
nor->read_opcode and nor->read_dummy at each call.

More precisely, I plan to use nor->read() from spi_nor_scan() to read
SFDP (Serial Flash Discoverable Parameters) data.

Whatever op code, numbers of address bytes and dummy cycles used for
(Fast) Read commands, the Read SFDP command uses fixed settings
standardized for all manufacturers and all memory parts:
- op code: 5Ah
- number of bytes for the address: 3 (even for memory > 128Mbits)
- number of dummy clock cycles: 8 clocks

https://patchwork.ozlabs.org/patch/742380/

Please have a look at the spi_nor_read_sfdp().

spi_nor_read_sfdp() is likely to be called from and only from
spi_nor_scan().

Best regards,

Cyrille

>>
>> SPI controller driver should never check SPINOR_OP_* op codes like this.
> I agree that SPI controller driver should not check SPINOR_OP_* op codes
> like what I do.
> I will correct it next version.
> 
> Best Regards,
> Guochun
>>
>> Then, testing SPINOR_OP_RDSR from mt8173_nor_read_reg() or
>> SPINOR_OP_WRSR from mt8173_nor_write_reg() is not a good practice too:
>> op codes may change depending on the memory manufacturer. So testing op
>> code values like you do can work with some memories but maybe not all.
>>
>> Finally, don't use 0x10, please define a macro instead.
>>
>> Best regards,
>>
>> Cyrille
>>
>>>  	default:
>>>  		ret = mt8173_nor_do_tx_rx(mt8173_nor, opcode, buf, len, NULL, 0);
>>>  		if (ret)
>>>
>>
> 
> 
> 

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [PATCH V1 1/1] mtd: mtk-nor: set controller to 4B mode with large capacity flash
@ 2017-03-31  8:56         ` Cyrille Pitchen
  0 siblings, 0 replies; 18+ messages in thread
From: Cyrille Pitchen @ 2017-03-31  8:56 UTC (permalink / raw)
  To: linux-arm-kernel

Le 31/03/2017 ? 04:26, Guochun Mao a ?crit :
> Hi Cyrille, Marek,
> 
> Thanks for your suggestions.
> 
> On Thu, 2017-03-30 at 19:40 +0200, Cyrille Pitchen wrote:
>> Hi Guochun,
>>
>> Le 30/03/2017 ? 10:23, Guochun Mao a ?crit :
>>> when nor's size larger than 16MByte, nor and controller should
>>> enter 4Byte mode simultaneously.
>>>
>>> Signed-off-by: Guochun Mao <guochun.mao@mediatek.com>
>>> ---
>>>  drivers/mtd/spi-nor/mtk-quadspi.c |    7 +++++++
>>>  1 file changed, 7 insertions(+)
>>>
>>> diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c b/drivers/mtd/spi-nor/mtk-quadspi.c
>>> index e661877..05cd8a8 100644
>>> --- a/drivers/mtd/spi-nor/mtk-quadspi.c
>>> +++ b/drivers/mtd/spi-nor/mtk-quadspi.c
>>> @@ -369,6 +369,13 @@ static int mt8173_nor_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf,
>>>  		/* We only handle 1 byte */
>>>  		ret = mt8173_nor_wr_sr(mt8173_nor, *buf);
>>>  		break;
>>> +	case SPINOR_OP_EN4B:
>>> +		/* Set nor controller to 4-byte address mode,
>>> +		 * and simultaneously set nor flash.
>>> +		 * This case should cooperate with default operation.
>>> +		 */
>>> +		writeb(readb(mt8173_nor->base + MTK_NOR_DUAL_REG) | 0x10,
>>> +				mt8173_nor->base + MTK_NOR_DUAL_REG);
>>
>> This is not good: you should check in both mt8173_nor_read() and
>> mt8173_nor_write() whether nor->addr_width is either 3 or 4.
>>
>> from include/linux/mtd/spi-nor.h:
>>  * @addr_width:		number of address bytes
>>
>> Besides SPI commands using an op code from 4-byte address instruction
>> set always carry a 4-byte address. They can be used directly, without
>> sending the SPINOR_OP_EN4B before. So you cannot assume that addresses
>> will be 4-byte long only if your SPI controller driver has seen a
>> SPINOR_OP_EN4B command before. This assumption is wrong.
> Nor->addr_width is assigned in spi_nor_scan in spi-nor.c, and it's not
> modified in later process.
> Does it means that we will not switch nor between 3Byte address and
> 4Byte?
> So, is it better to check nor->addr_width when do nor initialization?
>

Currently yes, nor->addr_width, nor->read_opcode, nor->read_dummy, and
nor->program_opcode are set once for all in spi_nor_scan().

However, nor->read() is likely to be called soon from spi_nor_scan()
with values of nor->addr_width, nor->read_opcode and nor->read_dummy
different from those selected when exiting spi_nor_scan().

So nor->read() / mt8173_nor_read should check nor->addr_width,
nor->read_opcode and nor->read_dummy at each call.

More precisely, I plan to use nor->read() from spi_nor_scan() to read
SFDP (Serial Flash Discoverable Parameters) data.

Whatever op code, numbers of address bytes and dummy cycles used for
(Fast) Read commands, the Read SFDP command uses fixed settings
standardized for all manufacturers and all memory parts:
- op code: 5Ah
- number of bytes for the address: 3 (even for memory > 128Mbits)
- number of dummy clock cycles: 8 clocks

https://patchwork.ozlabs.org/patch/742380/

Please have a look at the spi_nor_read_sfdp().

spi_nor_read_sfdp() is likely to be called from and only from
spi_nor_scan().

Best regards,

Cyrille

>>
>> SPI controller driver should never check SPINOR_OP_* op codes like this.
> I agree that SPI controller driver should not check SPINOR_OP_* op codes
> like what I do.
> I will correct it next version.
> 
> Best Regards,
> Guochun
>>
>> Then, testing SPINOR_OP_RDSR from mt8173_nor_read_reg() or
>> SPINOR_OP_WRSR from mt8173_nor_write_reg() is not a good practice too:
>> op codes may change depending on the memory manufacturer. So testing op
>> code values like you do can work with some memories but maybe not all.
>>
>> Finally, don't use 0x10, please define a macro instead.
>>
>> Best regards,
>>
>> Cyrille
>>
>>>  	default:
>>>  		ret = mt8173_nor_do_tx_rx(mt8173_nor, opcode, buf, len, NULL, 0);
>>>  		if (ret)
>>>
>>
> 
> 
> 

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH V1 1/1] mtd: mtk-nor: set controller to 4B mode with large capacity flash
@ 2017-04-05  3:34           ` Guochun Mao
  0 siblings, 0 replies; 18+ messages in thread
From: Guochun Mao @ 2017-04-05  3:34 UTC (permalink / raw)
  To: Cyrille Pitchen
  Cc: Marek Vasut, Boris Brezillon, Mark Rutland, devicetree,
	Richard Weinberger, Russell King, linux-kernel, Rob Herring,
	linux-mtd, Matthias Brugger, linux-mediatek, Cyrille Pitchen,
	David Woodhouse, linux-arm-kernel

Hi Cyrille,

Thank you for so detailed explanation.
I'll check nor->addr_width in both mt8173_nor_read() and
mt8173_nor_write().

Best regards,
Guochun

On Fri, 2017-03-31 at 10:56 +0200, Cyrille Pitchen wrote:
> Le 31/03/2017 à 04:26, Guochun Mao a écrit :
> > Hi Cyrille, Marek,
> > 
> > Thanks for your suggestions.
> > 
> > On Thu, 2017-03-30 at 19:40 +0200, Cyrille Pitchen wrote:
> >> Hi Guochun,
> >>
> >> Le 30/03/2017 à 10:23, Guochun Mao a écrit :
> >>> when nor's size larger than 16MByte, nor and controller should
> >>> enter 4Byte mode simultaneously.
> >>>
> >>> Signed-off-by: Guochun Mao <guochun.mao@mediatek.com>
> >>> ---
> >>>  drivers/mtd/spi-nor/mtk-quadspi.c |    7 +++++++
> >>>  1 file changed, 7 insertions(+)
> >>>
> >>> diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c b/drivers/mtd/spi-nor/mtk-quadspi.c
> >>> index e661877..05cd8a8 100644
> >>> --- a/drivers/mtd/spi-nor/mtk-quadspi.c
> >>> +++ b/drivers/mtd/spi-nor/mtk-quadspi.c
> >>> @@ -369,6 +369,13 @@ static int mt8173_nor_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf,
> >>>  		/* We only handle 1 byte */
> >>>  		ret = mt8173_nor_wr_sr(mt8173_nor, *buf);
> >>>  		break;
> >>> +	case SPINOR_OP_EN4B:
> >>> +		/* Set nor controller to 4-byte address mode,
> >>> +		 * and simultaneously set nor flash.
> >>> +		 * This case should cooperate with default operation.
> >>> +		 */
> >>> +		writeb(readb(mt8173_nor->base + MTK_NOR_DUAL_REG) | 0x10,
> >>> +				mt8173_nor->base + MTK_NOR_DUAL_REG);
> >>
> >> This is not good: you should check in both mt8173_nor_read() and
> >> mt8173_nor_write() whether nor->addr_width is either 3 or 4.
> >>
> >> from include/linux/mtd/spi-nor.h:
> >>  * @addr_width:		number of address bytes
> >>
> >> Besides SPI commands using an op code from 4-byte address instruction
> >> set always carry a 4-byte address. They can be used directly, without
> >> sending the SPINOR_OP_EN4B before. So you cannot assume that addresses
> >> will be 4-byte long only if your SPI controller driver has seen a
> >> SPINOR_OP_EN4B command before. This assumption is wrong.
> > Nor->addr_width is assigned in spi_nor_scan in spi-nor.c, and it's not
> > modified in later process.
> > Does it means that we will not switch nor between 3Byte address and
> > 4Byte?
> > So, is it better to check nor->addr_width when do nor initialization?
> >
> 
> Currently yes, nor->addr_width, nor->read_opcode, nor->read_dummy, and
> nor->program_opcode are set once for all in spi_nor_scan().
> 
> However, nor->read() is likely to be called soon from spi_nor_scan()
> with values of nor->addr_width, nor->read_opcode and nor->read_dummy
> different from those selected when exiting spi_nor_scan().
> 
> So nor->read() / mt8173_nor_read should check nor->addr_width,
> nor->read_opcode and nor->read_dummy at each call.
> 
> More precisely, I plan to use nor->read() from spi_nor_scan() to read
> SFDP (Serial Flash Discoverable Parameters) data.
> 
> Whatever op code, numbers of address bytes and dummy cycles used for
> (Fast) Read commands, the Read SFDP command uses fixed settings
> standardized for all manufacturers and all memory parts:
> - op code: 5Ah
> - number of bytes for the address: 3 (even for memory > 128Mbits)
> - number of dummy clock cycles: 8 clocks
> 
> https://patchwork.ozlabs.org/patch/742380/
> 
> Please have a look at the spi_nor_read_sfdp().
> 
> spi_nor_read_sfdp() is likely to be called from and only from
> spi_nor_scan().
> 
> Best regards,
> 
> Cyrille
> 
> >>
> >> SPI controller driver should never check SPINOR_OP_* op codes like this.
> > I agree that SPI controller driver should not check SPINOR_OP_* op codes
> > like what I do.
> > I will correct it next version.
> > 
> > Best Regards,
> > Guochun
> >>
> >> Then, testing SPINOR_OP_RDSR from mt8173_nor_read_reg() or
> >> SPINOR_OP_WRSR from mt8173_nor_write_reg() is not a good practice too:
> >> op codes may change depending on the memory manufacturer. So testing op
> >> code values like you do can work with some memories but maybe not all.
> >>
> >> Finally, don't use 0x10, please define a macro instead.
> >>
> >> Best regards,
> >>
> >> Cyrille
> >>
> >>>  	default:
> >>>  		ret = mt8173_nor_do_tx_rx(mt8173_nor, opcode, buf, len, NULL, 0);
> >>>  		if (ret)
> >>>
> >>
> > 
> > 
> > 
> 

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH V1 1/1] mtd: mtk-nor: set controller to 4B mode with large capacity flash
@ 2017-04-05  3:34           ` Guochun Mao
  0 siblings, 0 replies; 18+ messages in thread
From: Guochun Mao @ 2017-04-05  3:34 UTC (permalink / raw)
  To: Cyrille Pitchen
  Cc: Marek Vasut, Boris Brezillon, Mark Rutland,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Richard Weinberger,
	Russell King, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
	linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Matthias Brugger,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Cyrille Pitchen,
	David Woodhouse,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r

Hi Cyrille,

Thank you for so detailed explanation.
I'll check nor->addr_width in both mt8173_nor_read() and
mt8173_nor_write().

Best regards,
Guochun

On Fri, 2017-03-31 at 10:56 +0200, Cyrille Pitchen wrote:
> Le 31/03/2017 à 04:26, Guochun Mao a écrit :
> > Hi Cyrille, Marek,
> > 
> > Thanks for your suggestions.
> > 
> > On Thu, 2017-03-30 at 19:40 +0200, Cyrille Pitchen wrote:
> >> Hi Guochun,
> >>
> >> Le 30/03/2017 à 10:23, Guochun Mao a écrit :
> >>> when nor's size larger than 16MByte, nor and controller should
> >>> enter 4Byte mode simultaneously.
> >>>
> >>> Signed-off-by: Guochun Mao <guochun.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> >>> ---
> >>>  drivers/mtd/spi-nor/mtk-quadspi.c |    7 +++++++
> >>>  1 file changed, 7 insertions(+)
> >>>
> >>> diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c b/drivers/mtd/spi-nor/mtk-quadspi.c
> >>> index e661877..05cd8a8 100644
> >>> --- a/drivers/mtd/spi-nor/mtk-quadspi.c
> >>> +++ b/drivers/mtd/spi-nor/mtk-quadspi.c
> >>> @@ -369,6 +369,13 @@ static int mt8173_nor_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf,
> >>>  		/* We only handle 1 byte */
> >>>  		ret = mt8173_nor_wr_sr(mt8173_nor, *buf);
> >>>  		break;
> >>> +	case SPINOR_OP_EN4B:
> >>> +		/* Set nor controller to 4-byte address mode,
> >>> +		 * and simultaneously set nor flash.
> >>> +		 * This case should cooperate with default operation.
> >>> +		 */
> >>> +		writeb(readb(mt8173_nor->base + MTK_NOR_DUAL_REG) | 0x10,
> >>> +				mt8173_nor->base + MTK_NOR_DUAL_REG);
> >>
> >> This is not good: you should check in both mt8173_nor_read() and
> >> mt8173_nor_write() whether nor->addr_width is either 3 or 4.
> >>
> >> from include/linux/mtd/spi-nor.h:
> >>  * @addr_width:		number of address bytes
> >>
> >> Besides SPI commands using an op code from 4-byte address instruction
> >> set always carry a 4-byte address. They can be used directly, without
> >> sending the SPINOR_OP_EN4B before. So you cannot assume that addresses
> >> will be 4-byte long only if your SPI controller driver has seen a
> >> SPINOR_OP_EN4B command before. This assumption is wrong.
> > Nor->addr_width is assigned in spi_nor_scan in spi-nor.c, and it's not
> > modified in later process.
> > Does it means that we will not switch nor between 3Byte address and
> > 4Byte?
> > So, is it better to check nor->addr_width when do nor initialization?
> >
> 
> Currently yes, nor->addr_width, nor->read_opcode, nor->read_dummy, and
> nor->program_opcode are set once for all in spi_nor_scan().
> 
> However, nor->read() is likely to be called soon from spi_nor_scan()
> with values of nor->addr_width, nor->read_opcode and nor->read_dummy
> different from those selected when exiting spi_nor_scan().
> 
> So nor->read() / mt8173_nor_read should check nor->addr_width,
> nor->read_opcode and nor->read_dummy at each call.
> 
> More precisely, I plan to use nor->read() from spi_nor_scan() to read
> SFDP (Serial Flash Discoverable Parameters) data.
> 
> Whatever op code, numbers of address bytes and dummy cycles used for
> (Fast) Read commands, the Read SFDP command uses fixed settings
> standardized for all manufacturers and all memory parts:
> - op code: 5Ah
> - number of bytes for the address: 3 (even for memory > 128Mbits)
> - number of dummy clock cycles: 8 clocks
> 
> https://patchwork.ozlabs.org/patch/742380/
> 
> Please have a look at the spi_nor_read_sfdp().
> 
> spi_nor_read_sfdp() is likely to be called from and only from
> spi_nor_scan().
> 
> Best regards,
> 
> Cyrille
> 
> >>
> >> SPI controller driver should never check SPINOR_OP_* op codes like this.
> > I agree that SPI controller driver should not check SPINOR_OP_* op codes
> > like what I do.
> > I will correct it next version.
> > 
> > Best Regards,
> > Guochun
> >>
> >> Then, testing SPINOR_OP_RDSR from mt8173_nor_read_reg() or
> >> SPINOR_OP_WRSR from mt8173_nor_write_reg() is not a good practice too:
> >> op codes may change depending on the memory manufacturer. So testing op
> >> code values like you do can work with some memories but maybe not all.
> >>
> >> Finally, don't use 0x10, please define a macro instead.
> >>
> >> Best regards,
> >>
> >> Cyrille
> >>
> >>>  	default:
> >>>  		ret = mt8173_nor_do_tx_rx(mt8173_nor, opcode, buf, len, NULL, 0);
> >>>  		if (ret)
> >>>
> >>
> > 
> > 
> > 
> 


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [PATCH V1 1/1] mtd: mtk-nor: set controller to 4B mode with large capacity flash
@ 2017-04-05  3:34           ` Guochun Mao
  0 siblings, 0 replies; 18+ messages in thread
From: Guochun Mao @ 2017-04-05  3:34 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Cyrille,

Thank you for so detailed explanation.
I'll check nor->addr_width in both mt8173_nor_read() and
mt8173_nor_write().

Best regards,
Guochun

On Fri, 2017-03-31 at 10:56 +0200, Cyrille Pitchen wrote:
> Le 31/03/2017 ? 04:26, Guochun Mao a ?crit :
> > Hi Cyrille, Marek,
> > 
> > Thanks for your suggestions.
> > 
> > On Thu, 2017-03-30 at 19:40 +0200, Cyrille Pitchen wrote:
> >> Hi Guochun,
> >>
> >> Le 30/03/2017 ? 10:23, Guochun Mao a ?crit :
> >>> when nor's size larger than 16MByte, nor and controller should
> >>> enter 4Byte mode simultaneously.
> >>>
> >>> Signed-off-by: Guochun Mao <guochun.mao@mediatek.com>
> >>> ---
> >>>  drivers/mtd/spi-nor/mtk-quadspi.c |    7 +++++++
> >>>  1 file changed, 7 insertions(+)
> >>>
> >>> diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c b/drivers/mtd/spi-nor/mtk-quadspi.c
> >>> index e661877..05cd8a8 100644
> >>> --- a/drivers/mtd/spi-nor/mtk-quadspi.c
> >>> +++ b/drivers/mtd/spi-nor/mtk-quadspi.c
> >>> @@ -369,6 +369,13 @@ static int mt8173_nor_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf,
> >>>  		/* We only handle 1 byte */
> >>>  		ret = mt8173_nor_wr_sr(mt8173_nor, *buf);
> >>>  		break;
> >>> +	case SPINOR_OP_EN4B:
> >>> +		/* Set nor controller to 4-byte address mode,
> >>> +		 * and simultaneously set nor flash.
> >>> +		 * This case should cooperate with default operation.
> >>> +		 */
> >>> +		writeb(readb(mt8173_nor->base + MTK_NOR_DUAL_REG) | 0x10,
> >>> +				mt8173_nor->base + MTK_NOR_DUAL_REG);
> >>
> >> This is not good: you should check in both mt8173_nor_read() and
> >> mt8173_nor_write() whether nor->addr_width is either 3 or 4.
> >>
> >> from include/linux/mtd/spi-nor.h:
> >>  * @addr_width:		number of address bytes
> >>
> >> Besides SPI commands using an op code from 4-byte address instruction
> >> set always carry a 4-byte address. They can be used directly, without
> >> sending the SPINOR_OP_EN4B before. So you cannot assume that addresses
> >> will be 4-byte long only if your SPI controller driver has seen a
> >> SPINOR_OP_EN4B command before. This assumption is wrong.
> > Nor->addr_width is assigned in spi_nor_scan in spi-nor.c, and it's not
> > modified in later process.
> > Does it means that we will not switch nor between 3Byte address and
> > 4Byte?
> > So, is it better to check nor->addr_width when do nor initialization?
> >
> 
> Currently yes, nor->addr_width, nor->read_opcode, nor->read_dummy, and
> nor->program_opcode are set once for all in spi_nor_scan().
> 
> However, nor->read() is likely to be called soon from spi_nor_scan()
> with values of nor->addr_width, nor->read_opcode and nor->read_dummy
> different from those selected when exiting spi_nor_scan().
> 
> So nor->read() / mt8173_nor_read should check nor->addr_width,
> nor->read_opcode and nor->read_dummy at each call.
> 
> More precisely, I plan to use nor->read() from spi_nor_scan() to read
> SFDP (Serial Flash Discoverable Parameters) data.
> 
> Whatever op code, numbers of address bytes and dummy cycles used for
> (Fast) Read commands, the Read SFDP command uses fixed settings
> standardized for all manufacturers and all memory parts:
> - op code: 5Ah
> - number of bytes for the address: 3 (even for memory > 128Mbits)
> - number of dummy clock cycles: 8 clocks
> 
> https://patchwork.ozlabs.org/patch/742380/
> 
> Please have a look at the spi_nor_read_sfdp().
> 
> spi_nor_read_sfdp() is likely to be called from and only from
> spi_nor_scan().
> 
> Best regards,
> 
> Cyrille
> 
> >>
> >> SPI controller driver should never check SPINOR_OP_* op codes like this.
> > I agree that SPI controller driver should not check SPINOR_OP_* op codes
> > like what I do.
> > I will correct it next version.
> > 
> > Best Regards,
> > Guochun
> >>
> >> Then, testing SPINOR_OP_RDSR from mt8173_nor_read_reg() or
> >> SPINOR_OP_WRSR from mt8173_nor_write_reg() is not a good practice too:
> >> op codes may change depending on the memory manufacturer. So testing op
> >> code values like you do can work with some memories but maybe not all.
> >>
> >> Finally, don't use 0x10, please define a macro instead.
> >>
> >> Best regards,
> >>
> >> Cyrille
> >>
> >>>  	default:
> >>>  		ret = mt8173_nor_do_tx_rx(mt8173_nor, opcode, buf, len, NULL, 0);
> >>>  		if (ret)
> >>>
> >>
> > 
> > 
> > 
> 

^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2017-04-05  3:34 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-30  8:23 [PATCH V1] mtd: mtk-nor: set controller to 4B mode with large capacity flash Guochun Mao
2017-03-30  8:23 ` Guochun Mao
2017-03-30  8:23 ` Guochun Mao
2017-03-30  8:23 ` [PATCH V1 1/1] " Guochun Mao
2017-03-30  8:23   ` Guochun Mao
2017-03-30  8:23   ` Guochun Mao
2017-03-30 10:00   ` Marek Vasut
2017-03-30 10:00     ` Marek Vasut
2017-03-30 17:40   ` Cyrille Pitchen
2017-03-30 17:40     ` Cyrille Pitchen
2017-03-31  2:26     ` Guochun Mao
2017-03-31  2:26       ` Guochun Mao
2017-03-31  2:26       ` Guochun Mao
2017-03-31  8:56       ` Cyrille Pitchen
2017-03-31  8:56         ` Cyrille Pitchen
2017-04-05  3:34         ` Guochun Mao
2017-04-05  3:34           ` Guochun Mao
2017-04-05  3:34           ` Guochun Mao

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.