Re: [RFC] SPI core

[David Brownell <david-b@pacbell.net>]

Yeah, I've been wondering why there's not an SPI core too.

Couldn't this code look a lot more like standard driver model
code?  Sure, probing and init should work a bit differently
(probably driven mostly by static "this board has this chip
at this chipselect" declarations, like platform_device) but
I never got the impression the I2C model was expected to grow
into new subsystems ...

How does this compare to the AT91 SPI and spidev interfaces?
(I'm picking on those only because I know they exist and seemed
to work nicely when I tested them a while back.  And they're
a rather direct analogue of this "core" patch.)


Quoth NZG <ngustavson at emacinc.com>
> SPI is serial-peripheral interface. A very common 3 wire bus in embedded 
> systems, especially m68k arch's. That fact that it's not there already is 
> actually a little weird IMHO.

Also on ARM ... PXA, OMAP, AT91, and others support it.

MMC cards can be accessed using SPI, as can serial flash chips
including notably DataFlash (over which JFFS2 works, though not
yet in the kernel.org MMC code).

It'd make sense to me to have for example the DataFlash driver
(in the AT91 patches) work using such a standard API.  Likewise
to have a few basic chip drivers working in the framework before
it's merged.

What other drivers do you see getting added "soon" to this
framework?  That is, SPI drivers that's currently in use in 2.6
and so should arguably switch to shared infrastructure to
help get more review and code reuse.

- Dave