[U-Boot] [PATCH v2 0/30] Introduce driver model support for SPI, SPI flash, cros_ec

Simon Glass sjg at chromium.org
Wed Sep 24 15:47:54 CEST 2014


Hi Jagan,

On 15 September 2014 06:33, Simon Glass <sjg at chromium.org> wrote:

> Up until now driver model has not been used for any type of bus. Buses
> have some unique properties and needs, so we cannot claim that driver
> model can cover all the common cases unless we have converted a bus over
> to driver model.
>
> SPI is a reasonable choice for this next step. It has a fairly simple
> API and not too many dependencies. The main one is SPI flash so we may
> as well convert that also. Since the boards I test with have cros_ec I
> have also included that, for SPI only.
>
> The technique used is make use of driver model's supported data structures
> to hold information currently kept by each subsystem in a private data
> structure. Since 'struct spi_slave' relates to the slave device on the bus
> it is stored in the 'parent' data with each child device of the bus.
> Since 'struct spi_flash' is a standard interface used for each SPI flash
> driver, it is stored in the SPI FLash uclass's private data for each
> device.
>
> New defines are created to enable driver model for each subsystem. These
> are:
>
>    CONFIG_DM_SPI
>    CONFIG_DM_SPI_FLASH
>    CONFIG_DM_CROS_EC
>
> This allows us to move some boards and drivers to driver model, while
> leaving others behind. A 'big bang' conversion of everything to driver
> model, event at a subsystem level, is never going to work.
>
> There is some cost in changing the uclass interface after it is created,
> so if you have limited time, please spend it reviewing the uclass
> interfaces in spi.h and spi_flash.h. These need to be supported by each
> driver, so changing them later may involve changing multiple drivers.
>
> To assist with the conversion of other SPI drivers, a README file is
> added to walk through the process.
>
> As always, driver model patches are available at u-boot-dm.git branch
> 'working'.
>

I've decided that the chip select approach is not going to server our
purposes for the long term. I'm going to respin this series with a few
changes and then send v3. It is currently at u-boot-dm/spi-working.

Also this isn't going to go into dm/master yet, except for some of the more
minor sandbox changes that you have reviewed. But I would like to get it
into dm/next.

Regards,
Simon


More information about the U-Boot mailing list