Message-ID: <9b87c51ec60df455911c0a4752407bb6e4af8569.camel@mediatek.com>
Date: Tue, 19 Nov 2024 10:29:08 +0000
From: SkyLake Huang (黃啟澤)
	<SkyLake.Huang@...iatek.com>
To: "gch981213@...il.com" <gch981213@...il.com>, "miquel.raynal@...tlin.com"
	<miquel.raynal@...tlin.com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
	"mmkurbanov@...utedevices.com" <mmkurbanov@...utedevices.com>,
	"kernel@...rdevices.ru" <kernel@...rdevices.ru>, "d-gole@...com"
	<d-gole@...com>, "dev@...herer.org" <dev@...herer.org>, "vigneshr@...com"
	<vigneshr@...com>, "richard@....at" <richard@....at>
Subject: Re: [PATCH v2] mtd: spinand: add support for FORESEE F35SQA002G

On Wed, 2024-11-13 at 18:10 +0800, Chuanhong Guo wrote:
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> 
> 
> Hello all!
> 
> On Wed, Nov 13, 2024 at 5:05 PM Miquel Raynal <
> miquel.raynal@...tlin.com> wrote:
> > 
> > On 12/11/2024 at 11:25:25 GMT, SkyLake Huang (黃啟澤) <
> > SkyLake.Huang@...iatek.com> wrote:
> > 
> > > On Tue, 2024-11-12 at 11:48 +0100, Miquel Raynal wrote:
> > > > External email : Please do not click links or open attachments
> > > > until
> > > > you have verified the sender or the content.
> > > > 
> > > > 
> > > > Hi Sky,
> > > > 
> > > > On 12/11/2024 at 10:08:31 GMT, SkyLake Huang (黃啟澤) <
> > > > SkyLake.Huang@...iatek.com> wrote:
> > > > 
> > > > > Hi Miquel/Martin,
> > > > > About this driver, including F35SQA001G/F35SQA002G parts, I'm
> > > > > concerned
> > > > > that the driver will always use 32H for update_cache
> > > > > operations,
> > > > > which
> > > > > means it's not compitable with those SPI controller who can't
> > > > > transmit
> > > > > 2048 bytes (most small-density SPI-NAND's page size nowadays)
> > > > > at
> > > > > one
> > > > > time.
> > > > > 
> > > > > The following controller's driver seems that they can't
> > > > > transmit
> > > > > 2048
> > > > > bytes in one transmission:
> > > > > - spi-amd.c: 64 bytes (AMD_SPI_MAX_DATA)
> > > > > - spi-amlogic-spifc-a1.c: 512 bytes (SPIFC_A1_BUFFER_SIZE)
> > > > > - spi-fsl-qspi.c: 1KB
> > > > > - spi-hisi-sfc-v3xx.c: 64*6 bytes
> > > > > - spi-intel.c: 64 bytes (INTEL_SPI_FIFO_SZ)
> > > > > - spi-microchip-core-qspi.c: 256 bytesc (MAX_DATA_CMD_LEN)
> > > > > - spi-nxp-fspi.c: TX:1KB, RX: 512B in FIFO mode
> > > > > - spi-wpcm-fiu.c: 4B
> > > > 
> > > > I believe most of these drivers are still able to send one page
> > > > of
> > > > data
> > > > without toggling the CS (which is what actually matters, I
> > > > believe).
> > > > If
> > > > they were broken, they would be broken with all spi memory
> > > > devices,
> > > > not
> > > > only Foresee's.
> > > > 
> > > 
> > > Hi Miquel,
> > > I think it's not about toggling the CS?
> > > 
> > > If a SPI controller tries to execute write page and it's capable
> > > to
> > > send only 1KB in one transmission, it should transmit data in two
> > > steps: 1st 34H (random program load x4) and 2nd 34H. However,
> > > when
> > > F35SQA002G executes 2nd 34H command, it needs to execute 32H
> > > first, and
> 
> I don't think that's what the datasheet means. I think it needs
> 02h/32h as the first
> command to write page cache, and the subsequent page cache writing
> can
> be done using 84h/34h before the final page program happens.
> Otherwise the
> 84h/34h command is just completely broken and useless.
> If it actually is broken, we do need additional guards in
> spinand_write_cache_op
> to abort when spi_mem_dirmap_write doesn't return exactly nbytes as
> requested.
> 
Confirm with Foresee and yes you're right XD

> > > it will clear data transmitted by 1st 34H in NAND flash's cache.
> > > This
> > > will cause data corruption. Other SPI-NANDs doesn't need to
> > > execute 32H
> > > before 34H.
> > 
> > Is it really what happens? I'd instead expect the spi controller to
> > send:
> > - 34h
> > - 1k data
> > - 1k data
> > ...
> > 
> > Why should we repeat the command while we are in the I/O phase?
> 
> Several SPI-MEM controller don't allow software controlled CS, or for
> some
> other reasons are unable to execute a longer spi-mem op.
> spi_mem_dirmap_write returns the actual request size it's able to
> make,
> and spinand_write_to_cache_op use a while loop to split one
> update_cache
> request into multiple ones.
> 
> This only works using the Random Program Load instruction (84h/34h)
> which preserves the previous written data in the flash data cache.
> All current supported flashes are exclusively using 84h/34h as the
> command
> to write the page cache.
> 
> Load Program Data(02h/32h) will clear the entire page cache. As a
> result, when a request is split as described above, the previous
> written
> data will be cleared, breaking the page cache writing procedure.
> 
> We can change write_to_cache_op to use Load Program Data on the
> first request. If that doesn't finish writing, use Random Program
> Load
> on subsequent data loading.
> --
> Regards,
> Chuanhong Guo

I observe that exec_op() in drivers/spi/spi-mt65xx.c on our platform
will issue the following commands once I limit its capability in
1024Bytes: (try to write 1 page)
- 34H
- addr
- 1020KB (1024KB - 1 byte opcode - 3 bytes addr)
- 34H
- addr
- 1020KB (1024KB - 1 byte opcode - 3 bytes addr)
- 34H
- addr
- 72KB

Is it possible to send 34H, 1K, 1K with current nbytes loop in
spinand_write_to_cache_op()? With which SPI controller?

I submit a patch according to this discussion, anyway.

https://lore.kernel.org/linux-mtd/20241119093949.3014-1-SkyLake.Huang@mediatek.com/

BRs,
Sky

Powered by blists - more mailing lists