Hi Jagan, On 11 August 2014 13:55, Simon Glass <[email protected]> wrote: > Hi Jagan, > > On 10 August 2014 03:16, Jagan Teki <[email protected]> wrote: >> On Sun, Aug 10, 2014 at 2:59 AM, Simon Glass <[email protected]> wrote: >>> Hi, >>> >>> On 14 July 2014 18:56, Simon Glass <[email protected]> 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 :-)
I'll send an updated series with your comments address. I'm planning to apply the non-exynos parts of SPI this week. Please let me know if you have any objections. I'd like to allow sufficient test time before the release. Regards, Simon _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
