Hi Jagan, On 24 September 2014 08:31, Jagan Teki <jagannadh.t...@gmail.com> wrote:
> On 24 September 2014 19:17, Simon Glass <s...@chromium.org> wrote: > > Hi Jagan, > > > > On 15 September 2014 06:33, 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, 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
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
