From owner-freebsd-mips@FreeBSD.ORG Wed Apr 10 14:45:56 2013 Return-Path: Delivered-To: freebsd-mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B8D0A48C; Wed, 10 Apr 2013 14:45:56 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by mx1.freebsd.org (Postfix) with ESMTP id 9203B2A8; Wed, 10 Apr 2013 14:45:56 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UPwHW-0005Ar-CA; Wed, 10 Apr 2013 14:45:50 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r3AEjlD9029814; Wed, 10 Apr 2013 08:45:47 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX193Uz15yCbNoOBmo/pJouBf Subject: Re: [PATCH] MMC/SD SPI-mode driver From: Ian Lepore To: Adrian Chadd In-Reply-To: References: <20130407011307.9a9a9d64.ray@freebsd.org> <20130407022428.86a66c6a.ray@freebsd.org> <20130408153334.9cc11688aedbf32dcbf83a7b@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Wed, 10 Apr 2013 08:45:47 -0600 Message-ID: <1365605147.41399.227.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Aleksandr Rybalko , Dmytro , 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 14:45:56 -0000 On Mon, 2013-04-08 at 11:32 -0700, Adrian Chadd wrote: > On 8 April 2013 05:33, Aleksandr Rybalko wrote: > > >> That way both can occur independently. > > > > Agree, but you forget to say about lock/unlock :) > > Yup, locking is implied. :-) > > I don't have any problem with extending the bus with this particular > method hack to allow the driver to implement an alternate read method. > > Anyone else? > > I'm happy to review a patch against -HEAD that does this: > > * add that new method, same as zrouter > * add the code to the flash driver, same as zrouter > * add spi locking in ar71xx_spi to ensure that entire transfers are > done inside a lock; > * for that copy read method, have it lock the device, put it back into > mapped mode, do the copy, put it into SPI mode, unlock the device. > > I think that should make it kick ass. > > Any takers? :) Why does this need a new method? Couldn't this be handled as a platform-specific optimized implementation of a regular transfer, after Aleksandr's pending changes that make simultaneous bi-directional transfers optional? -- Ian