[U-Boot] [PATCH v2 06/13] spi: add common fdt SPI driver interface

[Simon Glass]

Hi Stephen,

On Tue, Mar 19, 2013 at 11:24 AM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 03/16/2013 10:58 PM, Allen Martin wrote:
>> Add a common interface to fdt based SPI drivers.  Each driver is
>> represented by a table entry in fdt_spi_drivers[].  If there are
>> multiple SPI drivers in the table, the first driver to return success
>> from spi_init() will be registered as the SPI driver.
>
>> diff --git a/drivers/spi/fdt_spi.c b/drivers/spi/fdt_spi.c
>
>> +static struct fdt_spi_driver fdt_spi_drivers[] = {
>> +#ifdef CONFIG_TEGRA20_SFLASH
>> +     {
>> +             .compat         = COMPAT_NVIDIA_TEGRA20_SFLASH,
>> +             .max_ctrls      = 1,
>> +             .init           = tegra20_spi_init,
>> +             .claim_bus      = tegra20_spi_claim_bus,
>> +             .cs_is_valid    = tegra20_spi_cs_is_valid,
>> +             .setup_slave    = tegra20_spi_setup_slave,
>> +             .free_slave     = tegra20_spi_free_slave,
>> +             .cs_activate    = tegra20_spi_cs_activate,
>> +             .cs_deactivate  = tegra20_spi_cs_deactivate,
>> +             .xfer           = tegra20_spi_xfer,
>> +     },
>> +#endif
>> +#ifdef CONFIG_TEGRA20_SLINK
>> +     {
>> +             .compat         = COMPAT_NVIDIA_TEGRA20_SLINK,
>> +             .max_ctrls      = CONFIG_TEGRA_SLINK_CTRLS,
>> +             .init           = tegra30_spi_init,
>> +             .claim_bus      = tegra30_spi_claim_bus,
>> +             .cs_is_valid    = tegra30_spi_cs_is_valid,
>> +             .setup_slave    = tegra30_spi_setup_slave,
>> +             .free_slave     = tegra30_spi_free_slave,
>> +             .cs_activate    = tegra30_spi_cs_activate,
>> +             .cs_deactivate  = tegra30_spi_cs_deactivate,
>> +             .xfer           = tegra30_spi_xfer,
>> +     },
>> +#endif
>> +};
>
> In the future, it would be nice if we could build up that table
> automatically, with each driver providing its own struct inside the
> driver file, and using e.g. linker scripts to piece together the structs
> into one large table. That would avoid the need to list each one here,
> and to prototype all those functions in a header file.
>
> It'd also be nice to allow multiple driver to be active at once.
>
> Still, that's certainly all something that's quite suitable for
> follow-on patches later; not something that needs to be addressed in
> this series.

Agreed. This fits more with the driver model work, where the above
structure could be used as the SPI subsystem interface perhaps.

Regards,
Simon