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

Simon Glass sjg at chromium.org
Mon Aug 11 21:55:01 CEST 2014


Hi Jagan,

On 10 August 2014 03:16, Jagan Teki <jagannadh.teki at gmail.com> wrote:
> On Sun, Aug 10, 2014 at 2:59 AM, Simon Glass <sjg at chromium.org> wrote:
>> Hi,
>>
>> On 14 July 2014 18:56, 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.
>>>
>>> On the other hand, we change the driver at the same time as the CONFIG
>>> option is enabled. Keeping both version of the driver around involves a
>>> flock of #ifdefs, the benefit of which is not apparent to me, since the
>>> old code is removed anyway.
>>>
>>> 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 help with conversion of SPI drivers to driver model, documentation is
>>> provided which takes the happy camper through the process with an example.
>>>
>>> As always, driver model patches are available at u-boot-dm.git branch
>>> 'working'.
>>>
>>> Note: This series is not fully ready - e.g. some header files are missing
>>> comments. But I wanted to get it out for review early since some SPI work
>>> is ongoing which might depend on it.
>>
>> Are there any comments on this series please? I'd like to apply these
>> to dm/master early next week, excluding the exynos ones.
>
> I will be busy in next full week, give me 2 more weeks.
> Probably I will give my comments on next to next weekend.

I'll see what I can do. It has been out for review for 4 weeks :-)

Regards,
Simon


More information about the U-Boot mailing list