Re: SPI redux ... driver model support

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

> With my subsystem that would look like:
>
> static const struct spi_cs_table
> platform_spi1_cs_table[] = {
>  {
>   .name  = "touchscreen",
>   .cs_no  = 1,
>   .platform_data = NULL,
>   .flags  = SPI_CS_IDLE_HIGH,
>   .cs_data = 0,
>  },
>  {
>   .name  = "flash",
>   .cs_no  = 3,
>   .platform_data = NULL,
>   .flags  = SPI_CS_IDLE_HIGH,
>   .cs_data = 0,
>  },
> };

The problem scenario was that only one configuration
is valid at a time ... it would have been clearer if
both the add-on boards used CS1, so that device would
be either ads7864 _or_ at25640a, but not both.



> As far as I can see most SPI devices have fixed
> wirering to an adapter as SPI is not really a hotplug
> bus.

That wiring can be through an expansion connector though, which
is what I meant when I wrote that it's "vaguely hotplug-ish".
Example, the mainboard could have some SPI devices hard-wired,
on CS0 and CS2, while each different plugin board might add very
different devices on CS1 and/or CS3.

In any case, you were the one who also wanted to ship sample USB
peripherals that acted as adapters to various SPI chips... so that
bus adapters would really need to hotplug! :)


> The subsystem does allow you to add extra devices that
> aren't in the cs table if you want by calling
> spi_device_register in which case you have to setup
> the spi_device with the correct information.

Right, but as I had explained, the scenario is that the
SPI devices are on some easily-swapped add-on card.
That's a common physical arrangement for small embeddable
boards, because it takes so few wires per device.

Swapping those SPI connectors shouldn't involve changing
the declaration of the controller on the mainboard ...


> > One reason I posted this driver-model-only patch was
> > to highlight how
> > minimal an SPI core can be if it reuses the driver
> > model core.  I'm
> > not a fan of much "mid-layer" infrastructure in
> > driver stacks.
> > 
>
> This is what my SPI core tries to do. I would like to
> make at 'as small as possible and no smaller'

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.  :)

- 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/