From owner-freebsd-mips@FreeBSD.ORG Wed Apr 10 22:07:53 2013 Return-Path: Delivered-To: freebsd-mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DE82693C; Wed, 10 Apr 2013 22:07:53 +0000 (UTC) (envelope-from ray@freebsd.org) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 92C86DB0; Wed, 10 Apr 2013 22:07:53 +0000 (UTC) Received: from rnote.ddteam.net (146-209-201-46.pool.ukrtel.net [46.201.209.146]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id 15663C496C; Thu, 11 Apr 2013 01:07:46 +0300 (EEST) Date: Thu, 11 Apr 2013 01:07:38 +0300 From: Aleksandr Rybalko To: Ian Lepore Subject: Re: [PATCH] MMC/SD SPI-mode driver Message-Id: <20130411010738.9a775853.ray@freebsd.org> In-Reply-To: <1365619856.41399.242.camel@revolution.hippie.lan> References: <20130407011307.9a9a9d64.ray@freebsd.org> <20130407022428.86a66c6a.ray@freebsd.org> <20130408153334.9cc11688aedbf32dcbf83a7b@freebsd.org> <1365605147.41399.227.camel@revolution.hippie.lan> <1365609642.41399.237.camel@revolution.hippie.lan> <1365619856.41399.242.camel@revolution.hippie.lan> Organization: FreeBSD.ORG X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) X-Operating-System: FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Dmytro , Aleksandr Rybalko , freebsd-mips@FreeBSD.org X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 22:07:53 -0000 Hi, sorry guys, I'm too late for main flame :) On Wed, 10 Apr 2013 12:50:56 -0600 Ian Lepore wrote: > On Wed, 2013-04-10 at 10:21 -0700, Adrian Chadd wrote: > > On 10 April 2013 09:00, Ian Lepore wrote: > > > > > I don't understand how reading is not a generic spi command > > > (presupposing the existance of the proposed changes that allow > > > for a spi read without a concurrent write and vice versa). > > > > No. Reading is an SPI method. But the SPI flash command for reading > > data is different than other SPI commands. > > > > The only thing we should be doing this for is SPI _flash reads_. Not > > SPI reads. Just data area reads from a directly attached flash chip. > > > > It's dirty or inefficient any way we do this. Either we special case > > spibus drivers, or we expose a SPI read / SPI write 'command' that > > knows it's not a generic SPI bus transaction but specifically a > > read-this-flash-data-from-this-offset-and-length transaction. Or > > some other kind of dirty hack. > > > > Maybe something like this could work? > > static int > ar71xx_spi_transfer(device_t dev, device_t child, struct spi_command > *cmd) { > if (cmd->cs == sc->magic_mapped_flash_chipsel && > cmd->tx_cmd == NULL && cmd->tx_data == NULL && > *(uint8_t *)cmd->rx_cmd == SPIFLASH_READ_OPCODE && > /* maybe some other constraints I don't know about */ > /* maybe even check that child is the mx25l driver */) > return do_magic_mapped_read(...); > else > return do_mundane_nonmapped_transfer(...); > } > > -- Ian > Yeah, I like that one. It's well enclose chip specific ability inside chip specific driver. I see only one problem: what we will do if some hypothetical will send command similar to SPI flash command? And theoretical, SPI flash driver allowed to ask next block of data with just empty command (tx_cmd_sz is 0), with CS hold of course. /me will not count that SPI flash can use two command for read (READ + FAST_READ). Do we able to replace one of newbus methods for single driver instance? Thanks. WBW -- Aleksandr Rybalko