linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: guochun.mao@mediatek.com (Guochun Mao)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V1 1/1] mtd: mtk-nor: set controller to 4B mode with large capacity flash
Date: Wed, 5 Apr 2017 11:34:34 +0800	[thread overview]
Message-ID: <1491363274.7262.10.camel@mhfsdcap03> (raw)
In-Reply-To: <873a3dac-7d3a-0723-4c7d-c786d3398278@wedev4u.fr>

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)
> >>>
> >>
> > 
> > 
> > 
> 

      reply	other threads:[~2017-04-05  3:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 ` [PATCH V1 1/1] " Guochun Mao
2017-03-30 10:00   ` Marek Vasut
2017-03-30 17:40   ` Cyrille Pitchen
2017-03-31  2:26     ` Guochun Mao
2017-03-31  8:56       ` Cyrille Pitchen
2017-04-05  3:34         ` Guochun Mao [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1491363274.7262.10.camel@mhfsdcap03 \
    --to=guochun.mao@mediatek.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).