2009-07-07 15:44:02     Sharing the SPI bus

Document created by Aaronwu Employee on Aug 16, 2013
Version 1Show Document
  • View in full screen mode

2009-07-07 15:44:02     Sharing the SPI bus

Thomas Kurmann (SWITZERLAND)

Message: 76898    Is it safe to share the SPI bus for reading data streams from a AD converter (DMA read) with a SD Card? The AD converter will send data 5 - 10 times per second (about 72 kbit / s - 144 kbit/s). From earlier releases I remember reading that there was a problem using the mmc together with other peripherals, has this been fixed? Also can the SPORT be used as a usual SPI interface? Somehow I don't like the idea that the mmc is writing and the AD wants to send data on the same port. Thanks a lot for your help Tom




2009-07-07 21:17:23     Re: Sharing the SPI bus


Message: 76902   




The blackfin spi driver has two APIs for concurrent spi bus access - spi_lock_bus() and spi_unlock_bus(). This can be used to prevent a transaction (e.g a sequence of SD/MMC commands) from being interrupted by spi messages from other devices. You may have a try.


There is also a sport-spi driver: drivers/spi/bfin_sport_spi.c.






2009-07-08 01:41:37     Re: Sharing the SPI bus

Mike Frysinger (UNITED STATES)

Message: 76904   


it will be a problem with 2008R1.5 and older but should be resolved in 2009R1+ due to the changes Yi mentioned




2009-07-08 07:00:36     Re: Sharing the SPI bus

Thomas Kurmann (SWITZERLAND)

Message: 76926    > Ok, thanks a lot. As far as I remember from a previous project, the sd card always takes 512 bytes of data at once. So if the blackfin is writing to the disk, and an interrupt from the AD comes, the driver from the AD then locks the spi bus, the sd driver will finish writing the 512 bytes and then process the commands requested by the ad driver? If so, that would be great


> thanks for the help,

> tom




2009-07-08 14:52:06     Re: Sharing the SPI bus

Mike Frysinger (UNITED STATES)

Message: 76933   


well, that would never be an issue regardless.  the SPI framework always provides atomicity on a per-message basis.  the problem with SPI/MMC is that it needs to do a message, review the result, and then do another message based on that result.  that is the SPI locking Yi referred to.




2009-07-17 18:37:04     Re: Sharing the SPI bus

Thomas Kurmann (SWITZERLAND)

Message: 77585   


Ok, thanks for the info.


Now I have another question (were finishing the hardware design shortly). Were intending on using a couple of SPI MAX3100 UART chips on the SPORT (SPI emulated) bus. While reading through a couple of board configs I noticed that:


static struct bfin5xx_spi_master bfin_sport_spi0_info = {

    .num_chipselect = 1, /* master only supports one device */

    .enable_dma = 0,  /* master don't support DMA */





.num_chipselect = 1. If I look at the hardware connection posted in another thread its clear that only one dedicated cs is possible


SPORT-SPI function PINS:




TFS1 + RFS1 -> SD DAT3 (#CS)


DR1PRI -> SD DAT0(As SPI MISO function)


DT1PRI -> SD CMD (As SPI MOSI function)


Can the gpio CS also be used for this driver such as with the normal SPI? Out of curiosity have any latency / speed tests been done on the SPORT/SPI emulation? For us it doesnt really matter since the maximum baud on the UARTs will be 115k (for analog modems and gprs) so i dont see a large problem here.


Thanks for your support






2009-07-18 00:03:51     Re: Sharing the SPI bus

Mike Frysinger (UNITED STATES)

Message: 77594   


the driver in 2009R1 should be using GPIO's for CS ...


static void bfin_sport_spi_cs_active(struct driver_data *drv_data, struct chip_data *chip)


    gpio_direction_output(chip->cs_gpio, 0);





2009-07-18 09:38:31     Re: Sharing the SPI bus


Message: 77607   




If you just want more UARTS - have a look at:




You can get a UART, with the simple addition of an ADM3202 (which is going to be cheaper).