Hi Simon, On 10 October 2014 07:36, Simon Glass <s...@chromium.org> wrote: > Hi Jagan, > > On 9 October 2014 04:33, Jagan Teki <jagannadh.t...@gmail.com> wrote: >> On 9 October 2014 02:03, Simon Glass <s...@chromium.org> wrote: >>> Hi, >>> >>> On 29 September 2014 13:34, Simon Glass <s...@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, even 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. >>>> >>>> So far, sandbox, exynos and tegra drivers are converted over. >>>> >>>> As always, driver model patches are available at u-boot-dm.git branch >>>> 'working'. There is a branch for just this series called 'spi-working'. >>> >>> I think this has had enough time out there. So I will push this to >>> dm/next later this week. >> >> Sorry - I need to review a lot wrt v3. >> I do understand that it has been in enough time, but this causes a >> significant changes on >> entire framework, please hold on for a while I need to think with >> respect on qspi stuff with in >> the spi framework. > > Well I'm not sure it supports setting of the flags that are needed for > that. I don't have a platform to test with anyway. > > On the other hand adding that support to driver model could easily be > a separate effort. I don't see a good reason to hold up the core SPI / > SPI flash support.
Partially agreed at this moment, let me think and review the whole stuff. I would place all these stuff on to my master-next, once I'm OK. Any changes based on my strategy wrt qspi stuff - I may change these. But I will push all these later on the 13/10 release. Comments? thanks! -- Jagan. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot