From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-out.m-online.net ([212.18.0.10]) by bombadil.infradead.org with esmtps (Exim 4.85_2 #1 (Red Hat Linux)) id 1bGBWP-0006A2-QY for linux-mtd@lists.infradead.org; Thu, 23 Jun 2016 20:46:47 +0000 Message-ID: <576C4A9B.8010708@denx.de> Date: Thu, 23 Jun 2016 22:46:19 +0200 From: Marek Vasut MIME-Version: 1.0 To: Michal Suchanek , Cyrille Pitchen CC: Brian Norris , MTD Maling List , Boris Brezillon , nicolas.ferre@atmel.com, Linux Kernel Mailing List Subject: Re: [PATCH 7/9] mtd: m25p80: add support of dual and quad spi protocols to all commands References: <0a3b22ec3bc41c26536f3acc8acfd98f9b3207ed.1466440540.git.cyrille.pitchen@atmel.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 06/23/2016 10:35 PM, Michal Suchanek wrote: > Hello, Hi, > this patch is kind of awesome. > > I have a few practical concerns however. > > On 20 June 2016 at 18:50, Cyrille Pitchen wrote: >> Before this patch, m25p80_read() supported few SPI protocols: >> - regular SPI 1-1-1 >> - SPI Dual Output 1-1-2 >> - SPI Quad Output 1-1-4 >> On the other hand, all other m25p80_*() hooks only supported SPI 1-1-1. > > Under typical use my estimate is that huge majority of data is > transferred in _read() seconded by _write(). > > As I understand it the n-n-n means how many bits you transfer in > parallel when sending command-address-data. > > In _read() the command and data overhead is negligible when you can > read kilobytes at once. So difference between 1-1-4 and 4-4-4 is not > meaningful performance-wise. Are there flash chips that support one > but not the other? That's quite unlikely. > For _write() the benefits are even harder to assess. The page program usually works on 256B pages, so the math is rather easy. > You can > presumably write at n-n-4 or n-n-2 if your controller and flash > supports it transferring the page faster. And then spend possibly > large amount of time waiting for the flash to get ready again. If the > programming time is fixed transferring the page faster may or may not > have benefits. It may at least free the bus for other devices to use. > > The _reg_ stuff is probably negligible altogether, > > Lastly the faster transfers of address bytes seem to be achieved with > increasingly longer command codes given how much the maximum command > length increased. So even in a page write where the address is a few % > of the transfer the benefit of these extra modes is dubious. > > Overall I wonder how much it is worthwhile to complicate the code to > get all these modes in every single function. In my opinion, 1-1-x makes sense as it is supported by most flashes, while n-m-x where n,m>1 does not make sense as it often requires some stateful change to non-volatile register with little gain. > Thanks > > Michal > -- Best regards, Marek Vasut