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?
thanks!