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

[Simon Glass]

Hi Jagan,

On 24 September 2014 08:31, Jagan Teki <jagannadh.teki at gmail.com> wrote:

> On 24 September 2014 19:17, Simon Glass <sjg at chromium.org> wrote:
> > 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.
>
> In fact I couldn't like vast change on chip select logic yet, it's
> better to have the dm-spi
> will compatible with the current implementation. But anyway we need to
> discuss more on this.
>

I believe it is mostly compatible in the way it works now. It automatically
creates a 'generic' device for the chip select. The only thing I'm aware of
now is that there is no way to determine the valid chip selects. This is a
board-specific thing. The only sensible approach is probably to use device
tree or platform data. We can't call a function.

Regards,
Simon