From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Warren Date: Sun, 25 May 2008 23:57:18 -0700 Subject: [U-Boot-Users] [RFC/PATCH 2/6] SPI API improvements In-Reply-To: <1210929035-7997-2-git-send-email-haavard.skinnemoen@atmel.com> References: <> <1210929035-7997-1-git-send-email-haavard.skinnemoen@atmel.com> <1210929035-7997-2-git-send-email-haavard.skinnemoen@atmel.com> Message-ID: <483A5F4E.6030602@qstreams.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Haavard, Haavard Skinnemoen wrote: > From: Haavard Skinnemoen > > 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 > --- 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 regards, Ben