Date: Wed, 10 Apr 2013 10:00:42 -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: <1365609642.41399.237.camel@revolution.hippie.lan> In-Reply-To: <CAJ-Vmon3v1CV08u7dqn1w=Jwih2eCfjtJdmB_OjZU3cSzx-baA@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> <1365605147.41399.227.camel@revolution.hippie.lan> <CAJ-Vmon3v1CV08u7dqn1w=Jwih2eCfjtJdmB_OjZU3cSzx-baA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2013-04-10 at 08:42 -0700, Adrian Chadd wrote: > On 10 April 2013 07:45, Ian Lepore <ian@freebsd.org> wrote: > > > 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? > > Because its for a data region SPI read command, not a generic SPI command.. ? > 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). The patch referenced earlier in this thread changes the dev/flash/mx25l driver to make a special new spibus call. The default implementation of that call is to return failure, and only one mips platform will implement that call. But the mx25l is not a mips-specific part, what happens when I want to read from the mx25l that's in my DreamPlug box? It seems to me that the only layer at which the right decision can be made is where the low-level hardware driver can say "hey, this is a read on the chip select that's hard-wired to the spi flash part that I can do mapped reads on." Upper layers don't need to know anything about the underlying hardware or make any special calls. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1365609642.41399.237.camel>