Hi,
On 10 October 2014 07:51, Jagan Teki jagannadh.teki@gmail.com wrote:
On 10 October 2014 19:05, Simon Glass sjg@chromium.org wrote:
Hi Jagan,
On 10 October 2014 07:30, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Simon,
On 10 October 2014 07:36, Simon Glass sjg@chromium.org wrote:
Hi Jagan,
On 9 October 2014 04:33, Jagan Teki jagannadh.teki@gmail.com wrote:
On 9 October 2014 02:03, Simon Glass sjg@chromium.org wrote:
Hi,
On 29 September 2014 13:34, Simon Glass sjg@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?
Actually I'd like to bring this through the dm tree as I have a lot of dependent series that need to go that way. What is your timeline for further review of v3? I'm planning to push this to dm/next soon.
OK, I will give my first level comments by tomorrow (IST) May be this will prolong least by next week end, if something need to change.
OK I'll take a look at your comments when I get them.
I suggest adding the qspi stuff to sandbox. Then it will be easier to test with driver model. What do you think?
Will comment again on this.
OK.
Regards, Simon