Date: Thu, 11 Apr 2013 01:07:38 +0300 From: Aleksandr Rybalko <ray@freebsd.org> To: Ian Lepore <ian@FreeBSD.org> Cc: Dmytro <dioptimizer@gmail.com>, Aleksandr Rybalko <ray@FreeBSD.org>, freebsd-mips@FreeBSD.org 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: <CAK1zEjs=hC%2BpAYBgGq4t7%2BA_JPLaH6rhvEjD%2B1RNk1Ziu8E-4g@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> <1365609642.41399.237.camel@revolution.hippie.lan> <CAJ-Vmo=%2BtuHC4WA_5xPtjdJMGMn-_g6p5Nn7YjoPcuqb0s9AKg@mail.gmail.com> <1365619856.41399.242.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
sorry guys, I'm too late for main flame :)
On Wed, 10 Apr 2013 12:50:56 -0600
Ian Lepore <ian@FreeBSD.org> wrote:
> On Wed, 2013-04-10 at 10:21 -0700, Adrian Chadd wrote:
> > On 10 April 2013 09:00, Ian Lepore <ian@freebsd.org> 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 <ray@freebsd.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130411010738.9a775853.ray>