--- [email protected] wrote:
> Well I like this a bit better, but it's still in
> transition from
> the old I2C style stuff over to a newer driver model
> based one.
> (As other folk have noted, with the "bus" v.
> "adapter" confusion.)
>
> - Can you make the SPI messages work with an async
> API?
> It suffices to have a callback and a "void *"
> for the
> caller's data. Those callbacks should be able
> to start
> the next stage of a device protocol request ...
> e.g. the
> first one issues some command bytes, and its
> completion
> callback starts the data transfer. (It's easy
> to build
> synchronous models over async ones; but not the
> other way.)
>
> (I see Mark Underwood commented that he was
> working with
> one like that.)
Yep. I'm doing some tidying up. The work is still in
development but I'm trying to get some patches ready
so people and compare and contrast :-).
>
> - The basic thing that bothers me is that, like
> original I2C,
> the roles and responsibilities here don't
> correspond in any
> consistent way to the driver model. For new
> code like SPI,
> there's no excuse for that to happen.
>
> - It should probably also not assume Linux can
> only act in
> the "master" role. SPI controllers are simple,
> and often
> can implement slave roles just as well. (This
> is one of
> several technical details that bother me...)
I'm afraid my SPI subsystem doesn't either :-(. But it
hopefully shouldn't be hard to add :-)
>
>
> One thing I've been looking for in your posts about
> SPI is an
> example of how to configure a system using it. Some
> examples
> come quickly to mind (all Linux-based boards):
>
> * System 1 has one SPI bus with two chipselects
> wired.
> CS0 is for a DataFlash chip on the motherboard;
> while
> CS3 is a MMC/SD/SPI socket (cards can be
> added/removed)
> that's primarily used for DataFlash cards.
>
> * System 2 uses SPI to talk to to a multi function
> chip,
> with sensors for battery, temperature, and
> touchscreen
> (and others not used) as well as stereo audio
> over what's
> esentially an I2S channel. Plus an MMC/SD/SPI
> socket,
> not yet used in SPI mode (it'd use the MMC
> controller in
> SPI mode, not yet implemented or required).
>
> * System 3 uses SPI to talk to an AVR based
> microcontroller,
> using application-specific protocols to collect
> sensor
> data and to issue (robotics) commands. (AVR is
> an 8-bit
> microcontroller. In this case its firmware is
> open, but
> clearly not running under Linux. In other
> cases, there's
> no reason both sides can't run Linux.)
>
> Given that those SPI devices can't usefully be
> probed, and that
> things like some CAN drivers will cheerfully bind to
> a DataFlash
> device, how do you see systems like those getting
> configured?
> Lots of board-specific logic in the SPI bus and
> device drivers?
> (I'd hope to avoid that, though it clearly works!)
>
The way my subsystem gets around this is that each
adaptor has a CS table which describes what clients
are on what chip select. This is then used in the core
layer to 'probe' for devices. If a match is found (the
name of a client driver matches a name in the CS
table) then the clients probe function gets called
from which the client could also do some checking
(like I2C) and if it is happy that it is talking to
the device it was written for then it attaches the
cline to the bus.
>
> Anyway, more detailed comments below. I'm afraid I
> jumped
> right to the end of your post, where you had the
> highest level
> overview I could find: the <linux/spi.h> header.
> Next time
> it might be quicker to just review that part. :)
>
> I recently came across a FAQ entry that read "SPI is
> actually a
> lot simpler than for example I2C". True; but I
> don't think it
> looks that way yet in this API!
Hmm, SPI as no protocol like I2C but, to me, that
makes it harder as you can do more things with it. You
also have different clock modes and speeds unlike I2C.
>
> - Dave
>
=== message truncated ===
Hopefully more SPI patches coming soon. You have been
warned :-)
Mark
___________________________________________________________
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |