From: Miquel Raynal <miquel.raynal@bootlin.com>
To: "SkyLake Huang" <SkyLake.Huang@mediatek.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
"mmkurbanov@salutedevices.com" <mmkurbanov@salutedevices.com>,
"kernel@sberdevices.ru" <kernel@sberdevices.ru>,
"d-gole@ti.com" <d-gole@ti.com>,
"dev@kicherer.org" <dev@kicherer.org>,
"gch981213@gmail.com" <gch981213@gmail.com>,
"vigneshr@ti.com" <vigneshr@ti.com>,
"richard@nod.at" <richard@nod.at>
Subject: Re: [PATCH v2] mtd: spinand: add support for FORESEE F35SQA002G
Date: Wed, 13 Nov 2024 10:05:17 +0100 [thread overview]
Message-ID: <87h68bsdv6.fsf@bootlin.com> (raw)
In-Reply-To: <12f4d28f3efb7fe319ec919df92145c4ad24da01.camel@mediatek.com> ("SkyLake Huang (黃啟澤)"'s message of "Tue, 12 Nov 2024 11:25:25 +0000")
On 12/11/2024 at 11:25:25 GMT, SkyLake Huang (黃啟澤) <SkyLake.Huang@mediatek.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@mediatek.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
> 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?
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: "SkyLake Huang" <SkyLake.Huang@mediatek.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
"mmkurbanov@salutedevices.com" <mmkurbanov@salutedevices.com>,
"kernel@sberdevices.ru" <kernel@sberdevices.ru>,
"d-gole@ti.com" <d-gole@ti.com>,
"dev@kicherer.org" <dev@kicherer.org>,
"gch981213@gmail.com" <gch981213@gmail.com>,
"vigneshr@ti.com" <vigneshr@ti.com>,
"richard@nod.at" <richard@nod.at>
Subject: Re: [PATCH v2] mtd: spinand: add support for FORESEE F35SQA002G
Date: Wed, 13 Nov 2024 10:05:17 +0100 [thread overview]
Message-ID: <87h68bsdv6.fsf@bootlin.com> (raw)
In-Reply-To: <12f4d28f3efb7fe319ec919df92145c4ad24da01.camel@mediatek.com> ("SkyLake Huang (黃啟澤)"'s message of "Tue, 12 Nov 2024 11:25:25 +0000")
On 12/11/2024 at 11:25:25 GMT, SkyLake Huang (黃啟澤) <SkyLake.Huang@mediatek.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@mediatek.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
> 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?
Thanks,
Miquèl
next prev parent reply other threads:[~2024-11-13 9:09 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-08 16:34 [PATCH net-next v3 0/5] Re-organize MediaTek ethernet phy drivers and propose mtk-phy-lib Sky Huang
2024-11-08 16:34 ` [PATCH net-next v3 1/5] net: phy: mediatek: Re-organize MediaTek ethernet phy drivers Sky Huang
2024-11-08 16:34 ` [PATCH net-next v3 2/5] net: phy: mediatek: Move LED helper functions into mtk phy lib Sky Huang
2024-11-08 16:34 ` [PATCH net-next v3 3/5] net: phy: mediatek: Improve readability of mtk-phy-lib.c's mtk_phy_led_hw_ctrl_set() Sky Huang
2024-11-12 10:08 ` [PATCH v2] mtd: spinand: add support for FORESEE F35SQA002G SkyLake Huang (黃啟澤)
2024-11-12 10:08 ` SkyLake Huang (黃啟澤)
2024-11-12 10:48 ` Miquel Raynal
2024-11-12 10:48 ` Miquel Raynal
2024-11-12 11:25 ` SkyLake Huang (黃啟澤)
2024-11-12 11:25 ` SkyLake Huang (黃啟澤)
2024-11-13 9:05 ` Miquel Raynal [this message]
2024-11-13 9:05 ` Miquel Raynal
2024-11-13 10:10 ` Chuanhong Guo
2024-11-13 10:10 ` Chuanhong Guo
2024-11-18 7:43 ` Miquel Raynal
2024-11-18 7:43 ` Miquel Raynal
2024-11-19 10:29 ` SkyLake Huang (黃啟澤)
2024-11-19 10:29 ` SkyLake Huang (黃啟澤)
2024-11-08 16:34 ` [PATCH net-next v3 4/5] net: phy: mediatek: Integrate read/write page helper functions Sky Huang
2024-11-08 16:34 ` [PATCH net-next v3 5/5] net: phy: mediatek: add MT7530 & MT7531's PHY ID macros Sky Huang
2024-11-13 13:10 ` [PATCH net-next v3 0/5] Re-organize MediaTek ethernet phy drivers and propose mtk-phy-lib patchwork-bot+netdevbpf
-- strict thread matches above, loose matches on Subject: below --
2023-10-02 14:04 [PATCH v2] mtd: spinand: add support for FORESEE F35SQA002G Martin Kurbanov
2023-10-02 14:04 ` Martin Kurbanov
2023-10-16 9:29 ` Miquel Raynal
2023-10-16 9:29 ` Miquel Raynal
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=87h68bsdv6.fsf@bootlin.com \
--to=miquel.raynal@bootlin.com \
--cc=SkyLake.Huang@mediatek.com \
--cc=d-gole@ti.com \
--cc=dev@kicherer.org \
--cc=gch981213@gmail.com \
--cc=kernel@sberdevices.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=mmkurbanov@salutedevices.com \
--cc=richard@nod.at \
--cc=vigneshr@ti.com \
/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 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.