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

[Jagan Teki]

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.

thanks!
-- 
Jagan.