Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755277AbbHFQOF (ORCPT ); Thu, 6 Aug 2015 12:14:05 -0400 Received: from mail-ob0-f176.google.com ([209.85.214.176]:36489 "EHLO mail-ob0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753217AbbHFQOC (ORCPT ); Thu, 6 Aug 2015 12:14:02 -0400 MIME-Version: 1.0 In-Reply-To: <20150806135129.GJ7576@n2100.arm.linux.org.uk> References: <20150804155148.GR20873@sirena.org.uk> <55C0FD98.1090107@ti.com> <20150805115013.GJ20873@sirena.org.uk> <20150805124412.GN20873@sirena.org.uk> <20150806090202.GO20873@sirena.org.uk> <20150806102225.GI7576@n2100.arm.linux.org.uk> <55C35233.2000105@ti.com> <20150806135129.GJ7576@n2100.arm.linux.org.uk> Date: Thu, 6 Aug 2015 18:14:00 +0200 X-Google-Sender-Auth: WPrKUZQmVeNhDaeSsD3etLQFqEU Message-ID: Subject: Re: [RFC PATCH 1/5] spi: introduce flag for memory mapped read From: Geert Uytterhoeven To: Russell King - ARM Linux Cc: Vignesh R , Michal Suchanek , Mark Brown , devicetree , Brian Norris , Tony Lindgren , Linux Kernel Mailing List , linux-spi , Huang Shijie , MTD Maling List , "linux-omap@vger.kernel.org" , David Woodhouse , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3720 Lines: 80 On Thu, Aug 6, 2015 at 3:51 PM, Russell King - ARM Linux wrote: > On Thu, Aug 06, 2015 at 05:55:23PM +0530, Vignesh R wrote: >> On the whole following are my requirements: >> 1. to be able to communicate with non -flash SPI devices via config port >> ( this functionality is supported by current driver, I dont want to >> break it). Or pump any spi_message on to SPI bus directly. >> 2. take advantage of memory mapped port in order to increase read >> throughput( and use dma in future) when the slave is a m25p80 type flash. >> 3. handle m25p80 as well as other slave on multiple chipselects. >> >> I just need to know whether the user that requested the transfer is >> m25p80 driver. If yes, ti-qspi driver can take advantage of memory >> mapped interface, else just use config port to access SPI bus directly. > > The problem with this approach is that it's an abomination. It's adding > a SPI-user specific hack which is detected by a specific driver. That's > really not sane - what happens when we have lots of these kinds of "I'm > an X SPI-user" with drivers detecting that? It's not maintainable in the > long term. > > Yes, your requirements _today_ seem simple and easy, but you're only > thinking about today, not tomorrow when you've moved on and someone else > has to maintain the mess left behind (or delete it from mainline because > they're sick of dealing with a hack.) > >> The spi_message that is received in transfer_one_message() is too >> generic to imply the slave device that is on the other side of the wire. >> IMO, the read command does not imply that the slave is m25p80 flash >> (besides the read opcodes vary across vendors of m25p80 and across modes). > > I can see both sides of the argument. > > Mark is saying: if the SPI driver detects that the message to be transmitted > is a read command followed by the appropriate number of dummy bytes, and > then the data being read _and_ it's using quad-mode access, and the hardware > generates _exactly_ that in hardware using the memory mapped mode, there is > no reason _not_ to use the hardware to achieve that SPI transaction. The > bus activity will be identical to what happens when the SPI controller is > used manually to achieve that bus sequence. > > You're saying: but the documentation says you can't use it for anything > except m25p80. If you look at 24.5.4.1.2, it tells you what the SFI > generates on the bus, which is: > > 1. CS active > 2. Read command byte sent > 3. 1-4 address bytes sent > 4. 0-3 dummy bytes sent > 5. data bytes read from bus > 6. CS inactive > > So, Mark's point is "if we can detect a transaction which fits _that_ > bus activity, there's no reason not to use this acceleration for the > transaction." > > What you're failing to counter with is: we don't have enough information > in the SPI driver to know how many dummy bytes there are between the > address bytes and the data read from the bus. Irrespective of the dummy bytes. What if the spi device is not a FLASH ROM, but some other device, which receives a data packet that accidentally looks like an m25p80 READ command? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/