public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Paul Fulghum <paulkf@microgate.com>
To: "Burkhard Schölpen" <bschoelpen@web.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: PCI DMA Interrupt latency
Date: Tue, 10 Jan 2006 09:31:28 -0600	[thread overview]
Message-ID: <43C3D350.6070003@microgate.com> (raw)
In-Reply-To: <419982528@web.de>

Burkhard Schölpen wrote:
> The issue seems to be something like interrupt 
> latency in hardware. Measuring some signals with an 
> oscilloscope shows, that the delay from generating the 
> interrupt, which signals a finished transfer, to the time 
> when the interrupt register on the card is reset (i.e. the 
> beginning of the ISR) sometimes increases to more 
> than 500 microseconds, which is dimensions too high. 
> 
> ... Another consideration is, that 
> another driver could lock all interrupts for too long (but for 
> 500 us??).  

I also have implemented bus master devices based
on the Spartan 2 + Xilinx PCI core and wrote the
associated Linux driver.

My observations of interrupt latency using
a similar setup to what you describe showed
50usec is common but rare events on
the order of milliseconds are possible.
You are probably correct that the
problem as a poorly behaved driver.

If you have complete control over every system
your device is installed in, you can
find and eliminate any device that
causes high interrupt latency.

If you don't have that control, your hardware
needs to tolerate interrupt latency of
that magnitude.

You describe an implementation with a single
DMA buffer. You could switch to multiple
buffers (ring structure or 2 alternating buffers)
with an interrupt triggered after each
buffer is exhausted (I use a ring of buffers).
The remaining buffers allow the transfer to
continue while waiting for ISR execution.

Or, more crudely, trigger the interrupt when
the single buffer reaches some low water mark
and poll in the ISR for actual completion.

-- 
Paul Fulghum
Microgate Systems, Ltd.

  reply	other threads:[~2006-01-10 15:31 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-10 13:18 PCI DMA Interrupt latency Burkhard Schölpen
2006-01-10 15:31 ` Paul Fulghum [this message]
     [not found] <5trA6-6MD-39@gated-at.bofh.it>
2006-01-10 23:59 ` Robert Hancock
2006-01-11  0:10   ` Lee Revell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43C3D350.6070003@microgate.com \
    --to=paulkf@microgate.com \
    --cc=bschoelpen@web.de \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox