Date: Wed, 10 Apr 2013 08:45:47 -0600 From: Ian Lepore <ian@FreeBSD.org> To: Adrian Chadd <adrian@FreeBSD.org> Cc: Aleksandr Rybalko <ray@FreeBSD.org>, Dmytro <dioptimizer@gmail.com>, freebsd-mips@FreeBSD.org Subject: Re: [PATCH] MMC/SD SPI-mode driver Message-ID: <1365605147.41399.227.camel@revolution.hippie.lan> In-Reply-To: <CAJ-Vmo=irADrYgM1Aw=fHbnO%2Bgf7kHy_xHeSY9mzTSifo34frg@mail.gmail.com> References: <CAK1zEjs=hC%2BpAYBgGq4t7%2BA_JPLaH6rhvEjD%2B1RNk1Ziu8E-4g@mail.gmail.com> <CAD44qMWpz-sjNKwRH6K=xicFXYutfk7R%2BN%2B%2Bo7cbgTg7rcQbkA@mail.gmail.com> <CAK1zEjuVZU4A59q5GxLcKTnFF9mcrbVmJ=w268uSJ=3sxVf1PA@mail.gmail.com> <CAD44qMURrssyXUz-%2Btd226chPA_MbKJ29ZApozbT2cEYbQwSqw@mail.gmail.com> <CAJ-Vmo=nQMuuJAW786egjuXCf0LGOd9g%2BCEEKdOJjPLRQFpKUg@mail.gmail.com> <20130407011307.9a9a9d64.ray@freebsd.org> <CAJ-Vmo=aeLCmBYpn9YMsGjq%2B9aF_Es-rByJ3RSnYkJYUECtLuQ@mail.gmail.com> <20130407022428.86a66c6a.ray@freebsd.org> <CAJ-VmokXseALmvvA9wsgZEBKSP0AGA988592TbsRb%2B4F0-UEcw@mail.gmail.com> <20130408153334.9cc11688aedbf32dcbf83a7b@freebsd.org> <CAJ-Vmo=irADrYgM1Aw=fHbnO%2Bgf7kHy_xHeSY9mzTSifo34frg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2013-04-08 at 11:32 -0700, Adrian Chadd wrote: > On 8 April 2013 05:33, Aleksandr Rybalko <ray@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1365605147.41399.227.camel>