Hi Jagan,
On 24 September 2014 08:31, Jagan Teki jagannadh.teki@gmail.com wrote:
On 24 September 2014 19:17, Simon Glass sjg@chromium.org wrote:
Hi Jagan,
On 15 September 2014 06:33, 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, event 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.
As always, driver model patches are available at u-boot-dm.git branch 'working'.
I've decided that the chip select approach is not going to server our purposes for the long term. I'm going to respin this series with a few changes and then send v3. It is currently at u-boot-dm/spi-working.
Also this isn't going to go into dm/master yet, except for some of the
more
minor sandbox changes that you have reviewed. But I would like to get it into dm/next.
In fact I couldn't like vast change on chip select logic yet, it's better to have the dm-spi will compatible with the current implementation. But anyway we need to discuss more on this.
I believe it is mostly compatible in the way it works now. It automatically creates a 'generic' device for the chip select. The only thing I'm aware of now is that there is no way to determine the valid chip selects. This is a board-specific thing. The only sensible approach is probably to use device tree or platform data. We can't call a function.
Regards, Simon