Re: [PATCH/RFC 0/2] simple SPI framework, refresh + ads7864 driver

[David Brownell]

> Date: Wed, 5 Oct 2005 17:24:53 +0100
> From: Russell King <rmk+lkml@xxxxxxxxxxxxxxxx>
>
> On Wed, Oct 05, 2005 at 09:21:17AM -0700, David Brownell wrote:
> > In my investigations of SPI, I don't happen to have come across any
> > SPI slave device that would naturally be handled as a block device.
> > There's lots of flash (and dataflash); that's MTD, not block.
>
> In two words, MMC cards.

With the interesting subcase of DataFlash cards, which are MMC format
but which only talk SPI protocol.  Dataflash would go through MTD.

(Seems to me that DataFlash cards are now "old tech" not being put
into many new systems.  Certainly they're not price-competitive with
MMC/SD ... DigiKey charges $US 28 for an 8 MB card, quantity one,
and that's the local price of a single 256 MB MMC or SD card.  The
story with discrete DataFlash chips seems to be different.)


> They can be used in MMC mode or SPI mode.

Yes, but ... any system with an MMC controller would use them in
MMC mode; then they'd be "MMC devices".  (Except DataFlash...)

The reason to use them in SPI mode is that that the system might
not _have_ an MMC controller, yet it might want inexpensive
removable storage.

(And there's another funky case too.  Most MMC controllers will
handle SPI protocol directly; I'm not sure how full the support
is, maybe it's just enough to talk to MMC cards.  But systems
that want SPI -- say, for sensors -- might do that using their
MMC controllers on one of the chipselects that's not used for
an external card slot.)


>  	 There have been some queries
> about using them in SPI mode, but I don't think anyone's written such
> a driver (yet).

Nor does the MMC stack yet understand that notion... it'd likely
help a bit if there were an SPI framework to build on!

Teaching that stack how to work in SPI mode, or even represent
controllers which only support SPI protocol, would be a lot more
work than just letting SPI drivers optionally provide DMA addresses
as well as the CPU addresses for their buffers.  :)

- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/