2009-03-26 15:28:32     SPORT Latency test on BF527

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

2009-03-26 15:28:32     SPORT Latency test on BF527

Giuseppe Olivadoti (UNITED STATES)

Message: 71629   

 

When testing the latency between two bursts of data out from the SPORT I see about 500 uSec of latency from when a SPORT transmission is finished until the time when the next burst begins.

 

 

 

The test software performs following functions:

 

1.      Transfer via SPORT interface 8 bytes package using DMA.

 

2.      When transfer is done set programmable flag.

 

3.      Reset programmable flag.

 

4.      Repeat 1-3

 

5.      Sleep for 1 sec

 

6.      Loop back to 1

 

 

 

The BF527 EZKit runs Kernel snapshot revision 7780 from 02/20/2009 and CPU clocks were set to provide the following frequencies:

 

·         Core CLK 400 MHz

 

·         System CLK 100 MHz

 

 

 

See attached scope plots for more detail.

 

 

 

The delay between when the actual transfer is done and when CPU is ready to transfer next package may not only be interrupt latency, but also SPORT driver / Kernel latency. A similar experiment using the SPI as opposed to the SPORT yields latency in the order of 50 uSec, as opposed to the 500 uSec on the SPORT.

 

 

 

I wonder if someone can point out why this behaves like this, and if I can modify my test to improve the latency.

 

 

 

Attached is the simple user space application that shows the issue, it is written so you could trigger a scope on the GPIO's.

 

 

 

 

 

SPORT plot1.bmp

SPORT plot2.bmp

SPORT_527Kit_main.cpp

QuoteReplyEditDelete

 

 

2009-03-26 15:56:03     Re: SPORT Latency test on BF527

Robin Getz (UNITED STATES)

Message: 71632   

 

Giuseppe:

 

I'm not sure what you are doing wrong,

 

We did some benchmarks, using a function generator hooked up to a GPIO IRQ.In the ISR I wiggle a second TEST GPIO high for 1 us.

 

We measured the delay between GPIO IRQ asserted and TEST IRQ asserted.

 

The typical interrupt latency of a system in idle is approx 2.7us (min 2.6us, max 5.2us)

 

Under high process and IO load (Ethernet ping flood, and full UART activity)

 

The average interrupt latency is approx 6 us. (min 2.6us, max 35us)

 

root:/> version

kernel:    Linux release 2.6.28.7-ADI-2009R1-pre-svn6218, build #1439 Wed Mar 25 13:35:15 CET 2009

toolchain: bfin-uclinux-gcc release gcc version 4.1.2 (ADI svn)

user-dist: release svn-7922, build #2888 Wed Mar 25 13:34:32 CET 2009

root:/> cat /proc/cpuinfo

processor       : 0

vendor_id       : Analog Devices

cpu family      : 0x27c8

model name      : ADSP-BF537 500(MHz CCLK) 125(MHz SCLK) (mpu off)

stepping        : 3

cpu MHz         : 500.000/125.000

bogomips        : 997.37

Calibration     : 498688000 loops

cache size      : 16 KB(L1 icache) 32 KB(L1 dcache-wb) 0 KB(L2 cache)

dbank-A/B       : cache/cache

icache setup    : 4 Sub-banks/4 Ways, 32 Lines/Way

dcache setup    : 2 Super-banks/4 Sub-banks/2 Ways, 64 Lines/Way

board name      : ADI BF537-STAMP

board memory    : 65536 kB (0x00000000 -> 0x04000000)

kernel memory   : 57336 kB (0x00001000 -> 0x037ff000)

QuoteReplyEditDelete

 

 

2009-03-26 16:00:44     SPORT Latency test on BF527

Michael Hennerich (GERMANY)

Message: 71633    Hi Giuseppe,

 

In Linux - device drivers typically life in kernel (supervisor) space and not in user space apps.

So if you invoke a system call write(sport_fd, ...) and then do write(gpio_fd, ...) you have several times the system call overhead in linux.

 

Interrupt latency on Blackfin Linux is somewhere between 1.6us and 30us on average apprx 2.6us and for a very busy system around 6us.

 

In case you move your code into the kernel you see the next burst start typ. 2.6us after the DMA DONE Int of pervious transfer triggered.

 

The SPI driver does busy waiting IO, so it's much more likely that the system call returns to the invoking process.

 

-Michael

 

QuoteReplyEditDelete

 

 

2009-03-30 11:22:30     Re: SPORT Latency test on BF527

Giuseppe Olivadoti (UNITED STATES)

Message: 71783   

 

Thanks,

 

Looking deeper into the issue it turns out that the SPORT TX IRQ handler code has a 500 uSec delay. I assume this is to allow the SPORT TX buffer to drain after the DMA is done. Any advice on how much this could safely be shortened by? This would account for almost all of the latency differences between the GPIO tests you have run and the SPORT test listed above.

static irqreturn_t dma_tx_irq_handler(int irq, void *dev_id)

 

{

 

      struct sport_dev *dev = dev_id;

 

      unsigned int status;

 

 

 

      pr_debug("%s enter\n", __func__);

 

      status = get_dma_curr_irqstat(dev->dma_tx_chan);

 

      while (status & DMA_RUN) {

 

            status = get_dma_curr_irqstat(dev->dma_tx_chan);

 

            pr_debug("status:0x%04x\n", status);

 

      }

 

      status = dev->regs->stat;

 

      while (!(status & TXHRE)) {

 

            pr_debug("%s status:%x\n", __func__, status);

 

            udelay(1);

 

            status = *(volatile unsigned short *)&dev->regs->stat;

 

      }

 

      /* Wait for the last byte sent out */

 

      udelay(500);                       //??? Why do we need this delay

 

      pr_debug("%s status:%x\n", __func__, status);

 

 

 

      dev->regs->tcr1 &= ~TSPEN;

 

      SSYNC();

 

      disable_dma(dev->dma_tx_chan);

 

 

 

      dev->wait_con = 1;

 

      wake_up(&dev->waitq);

 

 

 

      /* Clear the interrupt status */

 

      clear_dma_irqstat(dev->dma_tx_chan);

 

 

 

      return IRQ_HANDLED;

 

}

 

 

QuoteReplyEditDelete

 

 

2009-03-30 16:25:19     Re: SPORT Latency test on BF527

Robin Getz (UNITED STATES)

Message: 71792   

 

Giuseppe:

 

All those udelays look like they are *bad*, and are working around the issue of there is no tc_drain type functionality on the SPORT. You know when it goes in the buffer, but not when it comes out the wire. Is there an equivilent in the SPORT that we missed?

 

Since those were added 2006 (by someone who is no longer here), I'm not sure we are going to find out where 500 came from.

 

-Robin

QuoteReplyEditDelete

 

 

2009-03-30 18:14:58     Re: SPORT Latency test on BF527

Mike Frysinger (UNITED STATES)

Message: 71800   

 

if that's true, it's going to make implementing tcdrain() on a SPORT/UART messy as we will have to overestimate the character time and sleep for that long ...

QuoteReplyEditDelete

 

 

2009-03-30 23:06:12     Re: SPORT Latency test on BF527

Sonic Zhang (CHINA)

Message: 71804   

 

The sport clock in the common sport driver can be always enabled when the device is opened. Then the delay in each write operation can be discarded.

 

 

QuoteReplyEditDelete

 

 

2009-03-31 06:56:24     Re: SPORT Latency test on BF527

Cliff Cai (CHINA)

Message: 71869   

 

500us seems too long.when tx hold register is empty,we just need  to wait around 33 clock  to ensure that the last bit has been shifted out.

 

Cliff

Outcomes