[U-Boot-Users] [RFC/PATCH 2/6] SPI API improvements

[Ben Warren <bwarren@qstreams.com>]

Hi Haavard,

Haavard Skinnemoen wrote:
> From: Haavard Skinnemoen <hskinnemoen@atmel.com>
>
> This patch gets rid of the spi_chipsel table and adds a handful of new
> functions that makes the SPI layer cleaner and more flexible.
>
> Instead of the spi_chipsel table, each board that wants to use SPI
> gets to implement three hooks:
>   * spi_cs_activate(): Activates the chipselect for a given slave
>   * spi_cs_deactivate(): Deactivates the chipselect for a given slave
>   * spi_cs_is_valid(): Determines if the given bus/chipselect
>     combination can be activated.
>
> Not all drivers may need those extra functions however. If that's the
> case, the board code may just leave them out (assuming they know what
> the driver needs) or rely on the linker to strip them out (assuming
> --gc-sections is being used.)
>
> To set up communication parameters for a given slave, the driver needs
> to call spi_setup_slave(). This returns a pointer to an opaque
> spi_slave struct which must be passed as a parameter to subsequent SPI
> calls. This struct can be freed by calling spi_free_slave(), but most
> driver probably don't want to do this.
>
> Before starting one or more SPI transfers, the driver must call
> spi_claim_bus() to gain exclusive access to the SPI bus and initialize
> the hardware. When all transfers are done, the driver must call
> spi_release_bus() to make the bus available to others, and possibly
> shut down the SPI controller hardware.
>
> spi_xfer() behaves mostly the same as before, but it now takes a
> spi_slave parameter instead of a spi_chipsel function pointer. It also
> got a new parameter, flags, which is used to specify chip select
> behaviour. This may be extended with other flags in the future.
>
> This patch has been build-tested on all powerpc and arm boards
> involved. I have not tested NIOS since I don't have a toolchain for it
> installed, so I expect some breakage there even though I've tried
> fixing up everything I could find by visual inspection.
>
> I have run-time tested this on AVR32 ATNGW100 using the atmel_spi and
> DataFlash drivers posted as a follow-up. I'd like some help testing
> other boards that use the existing SPI API.
>
> But most of all, I'd like some comments on the new API. Is this stuff
> usable for everyone? If not, why?
>
> Changed in v4:
>   - Build fixes for various boards, drivers and commands
>   - Provide common struct spi_slave definition that can be extended by
>     drivers
>   - Pass a struct spi_slave * to spi_cs_activate and spi_cs_deactivate
>   - Make default bus and mode build-time configurable
>   - Override default SPI bus ID and mode on mx32ads and imx31_litekit.
>
> Changed in v3:
>   - Add opaque struct spi_slave for controller-specific data associated
>     with a slave.
>   - Add spi_claim_bus() and spi_release_bus()
>   - Add spi_free_slave()
>   - spi_setup() is now called spi_setup_slave() and returns a
>     struct spi_slave
>   - soft_spi now supports four SPI modes (CPOL|CPHA)
>   - Add bus parameter to spi_setup_slave()
>   - Convert the new i.MX32 SPI driver
>   - Convert the new MC13783 RTC driver
>
> Changed in v2:
>   - Convert the mpc8xxx_spi driver and the mpc8349emds board to the
>     new API.
>
> Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com>
> ---
Tested on MPC8349EMDS, works great!  Nice work.  Sorry for taking so 
long.  I finally have my gear all set up again.

Acked-by: Ben Warren <biggerbadderben@gmail.com>

regards,
Ben