From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wj0-x22c.google.com ([2a00:1450:400c:c01::22c]) by bombadil.infradead.org with esmtps (Exim 4.85_2 #1 (Red Hat Linux)) id 1cAKRM-0004hB-9p for linux-mtd@lists.infradead.org; Fri, 25 Nov 2016 17:37:38 +0000 Received: by mail-wj0-x22c.google.com with SMTP id mp19so64602484wjc.1 for ; Fri, 25 Nov 2016 09:37:14 -0800 (PST) Subject: Re: SPI NAND support in drivers/mtd/spi-nor/spi-nor.c To: Cyrille Pitchen , Boris Brezillon , Brian Norris References: <20161108020115.GA116407@google.com> <20161108090757.204ef112@bbrezillon> Cc: "hramrach@gmail.com" , Richard Weinberger , Peter Pan , linux-mtd@lists.infradead.org, Yao Yuan , "dwmw2@infradead.org" , Ezequiel Garcia From: Marek Vasut Message-ID: <0810b4e9-96fc-ae5d-590b-1449b646defb@gmail.com> Date: Fri, 25 Nov 2016 18:11:41 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 11/08/2016 11:52 AM, Cyrille Pitchen wrote: > Hi all, > > Le 08/11/2016 à 09:07, Boris Brezillon a écrit : >> +Peter >> >> On Mon, 7 Nov 2016 18:01:15 -0800 >> Brian Norris wrote: >> >>> + others >>> >>> On Mon, Nov 07, 2016 at 09:53:34AM +0000, Yao Yuan wrote: >>>> Hi All, >>> >>> Hi Yao, >>> >>> I'm not that interested in handling private requests, and this is >>> generally informative, so I've added the linux-mtd list, as well as the >>> other maintainers. >>> >>> Also, when you're ready to send patches, make sure you use plain text >>> instead of HTML email. >>> >>>> I’m trying to add the QSPI NAND support in MTD. >> >> Yao, can you sync with Peter who is currently working on a SPI NAND >> framework (which would sit in drivers/mtd/nand/spi/). >> >>>> >>>> But I have reached a junction, could you please take some minutes and >>>> give me some suggestions? >>>> >>>> >>>> You know, we have the QSPI NOR support in >>>> drivers/mtd/spi-nor/spi-nor.c, >>>> >>>> And the QSPI NAND is very similar with QSPI NOR, but the Read, write >>>> and erase is different with SPI-NOR. >>> >>> How similar is the controller hardware? Does your IP support standard >>> SPI protocol, or is it specialized for accelerating SPI NAND (e.g., >>> memory-mapped, DMA, etc.)? Does it support SPI NOR? >>> >>>> So I have two ways to add QSPI-NAND: >>> >>> I'll leave your options intact below, but I don't think either of them >>> are that good. SPI NOR and SPI NAND are different enough, I doubt that >>> we'll get much benefit from using the same framework, unless you happen >>> to have IP that's designed for both NOR and NAND, yet doesn't quite do >>> traditional SPI. >>> >>> Particularly, NAND flash has a lot of issues that NOR flash generally >>> does not, around bad block management and wear leveling. Also, there may >>> be something to share around identification/ONFI? (Not sure how similar >>> the implementations are there.) There's been some prior discussion about >>> it, and maybe one of the CC'd people can direct you toward the latest >>> opinions, or else you can search the archives youreself ("SPI NAND" >>> should turn up several results). >>> >>> So the main issues would probably be around abstracting out the >>> bad-block-related and chip identification code so you can share code >>> with existing (parallel) NAND support. At least, that's what I think >>> based on the last time I looked at things, and I think some of the other >>> active maintainers had ideas along the same lines. >> >> I'm not sure identification of raw and SPI NAND is working the same >> way, but that's true for the BBT. And, as Brian said, you don't interact >> with NANDs the same way you do with NORs, so it should IMO stay in >> different frameworks. >> > > I agree with Brian and Boris about separating NORs and NANDs in different > frameworks. I know this is just a detail but for instance, the current > spi-nor framework starts sending the JEDEC Read ID command 9Fh to probe > the memory. At this point, you don't know yet what memory is connected to > the SPI controller. Hence you don't even know wether it is a NAND or a NOR. > Then if I take the Macronix MX35LFxGE4AB QSPI NAND as an example, its > datasheet claims that the JEDEC Read ID command (9Fh) requires 8 dummy > clock cycles after the op code and before reading the actual memory ID. > Those dummy cycles don't exist with SPI NOR memories. > So spi_nor_scan() cannot be used probe (Q)SPI NAND memories. > > Also, the read operation can be performed with a single (Fast) Read > command with (Q)SPI NOR memories whereas it has to be done in two steps > for QSPI NAND memories: > 1 - Page Read (13h): to transfer data from array to cache > 2 - Random Data Read (03h or 0Bh): to read data from the cache and > transfer them on the SPI bus. > > So read operations are quite different as well between NORs and NANDs. > I didn't have a look at the Page Program operation but I expect > strong differences as well. > > I think there are too many differences to handle both kind of memories > with a single framework. Can a QSPI controller handle both SPI NOR and SPI NAND ? That is the question here. If so, we'd have the same driver for both, but different layer on top of it (handling either NOR or NAND commands). I think the different command sets are a detail which can be handled just fine and it should be a detail handled in separate SPI NOR and SPI NAND layers. Just my 5 cents ... -- Best regards, Marek Vasut