Re: SPI redux ... driver model support

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

> Date: Wed, 7 Sep 2005 19:38:43 +0100 (BST)
> From: Mark Underwood <basicmark@yahoo.com>
> ...
>
> I see several posabiltiys of how SPI devices could be
> connected to an adapter.

Certainly, and all are addressed cleanly by the kind of
configuration scheme I showed.


> 1) All SPI devices are hardwired to the adapter. I
> think this would be the most common.

For custom hardware, not designed for expansion, yes.  Zaurus Corgi
models, for example, keep three SPI devices busy.

But in that category I'd also include custom hardware that happens to
be packaged by connecting boards, which is also the territory of #2 or
#3 below.  "Hard wired" can include connectors that are removable by
breaking the warranty.  :)


> 2) Some SPI devices are hardwired and some are
> removable.

Development/Evaluation boards -- the reference implementations in most
environments, not just Linux -- seem to all but universally choose this
option (or, more rarely, #3).  There might be some domain-specific chips
hardwired (touchscreen or CAN controller, ADC/DAC, etc), but expansion
connectors WILL expose SPI.

That makes sense; one goal is to support system prototyping, and it's
hard to do that if for any reason one of the major hardware connectivity
options is hard to get at!


> 3) All SPI devices are removable.

This is common for the sort of single board computers that get sold
to run Linux (or whatever) as part of semicustom hardware:  maybe not
much more than a few square inches packed with an SOC CPU, FLASH, RAM,
and expansion connectors providing access to a few dozen SOC peripherals.
(There might be 250 or so SOC pins, with expansion connectors providing
access to some big portion of those pins ... including some for SPI.)

It'd be nice to be able to support those SBCs with a core Linux port,
and then just layer support for addon boards on top of that without
needing to touch a line of arch code.  And convenient for folk who
are adding value through those addons.  :)



> 	 When you plug a card in you use
> spi_device_register to add that device to the system
> and when you remove the card you call
> spi_device_unregister. You can then do the same for a
> different card and at no time have you changed the
> declaration of the controller.

That implies whoever is registering is actually going and creating the
SPI devices ... and doing it AFTER the controller driver is registered.
I actually have issues with each of those implications.

However, I was also aiming to support the model where the controller
drivers are modular, and the "add driver" and "declare hardware" steps
can go in any order.  That way things can work "just like other busses"
when you load the controller drivers ... and the approach is like the
familiar "boot firmware gives hardware description tables to the OS"
approach used by lots of _other_ hardware that probes poorly.  (Except
that Linux is likely taking over lots of that "boot firmware" role.)


> > I'll post a refresh of my patch that seems to me to be
> > a much better match for those goals.  The refresh includes
> > some tweaks based on what you sent, but it's still just
> > one KByte of overhead in the target ROM.  :)

Grr.  I added sysfs attributes and an I/O utility function,
and now it's a bit bigger than 1KByte.  Especially with
debugging enabled, it's nearer 1.5KB.  The curse of actually
trying to hook up to hardware and its quirks.  :(


> OK. I will post an updated version of my SPI subsystem
> within the next few days with the transfer stuff added
> and maybe the interrupt and GPO abstraction as well.

OK.


> I haven't seen any replies to my SPI patch :( did you
> reply to it?

No, I was going to sent it when I sent that refresh; it's helped
focus my thoughts a bit.  :)

Several of the comments (like "get rid of algorithm layer!") you'll have
heard before in response to the RFC from MontaVista.  It seems both
approaches are still trying to make SPI seem like I2C, and not taking
the opportunity to _fix_ very much of the I2C oddness.

- Dave

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