Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756046AbbHFSUp (ORCPT ); Thu, 6 Aug 2015 14:20:45 -0400 Received: from mail-wi0-f181.google.com ([209.85.212.181]:33707 "EHLO mail-wi0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754836AbbHFSUn (ORCPT ); Thu, 6 Aug 2015 14:20:43 -0400 MIME-Version: 1.0 In-Reply-To: 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> From: Michal Suchanek Date: Thu, 6 Aug 2015 20:20:02 +0200 Message-ID: Subject: Re: [RFC PATCH 1/5] spi: introduce flag for memory mapped read To: Geert Uytterhoeven Cc: Russell King - ARM Linux , Vignesh R , 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: 3809 Lines: 82 On 6 August 2015 at 18:14, Geert Uytterhoeven wrote: > 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? > Presumably the driver would interpret some random part of the message as address and map the reply in your address space at that address from the flash mmap base. If you happen to overflow the flash memory mmap space the behaviour will probably not be well defined. Thanks Michal -- 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/