From: "Burkhard Schölpen" <bschoelpen@web.de>
To: linux-kernel@vger.kernel.org
Subject: PCI DMA burst delay
Date: Thu, 29 Dec 2005 15:43:36 +0100 [thread overview]
Message-ID: <395333712@web.de> (raw)
Hello,
I'm working on a linux driver for a custom pci card (containing a Xilinx FPGA) which is bus master capable and has to transfer large amounts of data with high bandwidth. I finally succeeded in mmaping the dma buffer residing in ram to user space to avoid unnecessary copying. So actually it seems to work quite well, but sometimes I get some trouble (which seems to occur randomly) concerning dma transfers from ram to the device. When this problem occurs, it leads to the fact, that data arrives too late at the input fifo on the pci card (16kBit).
Looking at some signals with an oscilloscope shows the following behaviour:
1. After preparing the dma buffer in ram and telling the pci card that the dma transfer should begin, the first dma burst is transmitted in a normal way.
2. After the first burst, the pci bus grant signal is disabled, so the access to the bus seems to be denied.
3. About 400 nanoseconds later, the pci device tries to initiate the next burst, but does not succeed (pci bus access is not granted)
=> this process is repeated 3 times
4. In most cases the next burst starts here after the third trial (and all other following bursts are following well). But in the (rarely) faulty case, the 2nd burst only starts after another delay of about 600ns, which is too late, because meanwhile I get a buffer underrun in the FPGA. After some delayed bursts the transfer continues normally.
Does anybody have an idea, why the dma bursts could be delayed, although I deactivated all other pci devices that could disturb the transfers? Maybe it is a quite simple issue, because I'm not yet very experienced with dma stuff. Could it be a problem with my driver implementation, because if the problem occurs, it is always after the first burst? The dma buffer in ram I allocated with pci_alloc_consistent() as described in Rubini's book and the DMA-mapping.txt documentation file.
Here is some information about my environment:
- Gigabyte GA-8I945GMF mainboard with Pentium D processor
- custom pci board with Xilinx FPGA Spartan 2 (XC2S150-6) with PCI 32 LogiCore
- Debian Linux with 2.6.13.4 SMP kernel
Another thing I should mention is that I tried to configure the length of the dma bursts with the pci core, but that didn't work. The oscilloscope showed, that the actual burst length never was higher than 512 Bits and I think this is much too less to be efficient!
Any hint would be very appreciated.
Kind regards,
Burkhard Schölpen
__________________________________________________________________________
Erweitern Sie FreeMail zu einem noch leistungsstarkeren E-Mail-Postfach!
Mehr Infos unter http://freemail.web.de/home/landingpad/?mc=021131
next reply other threads:[~2005-12-29 14:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-29 14:43 Burkhard Schölpen [this message]
2005-12-29 15:23 ` PCI DMA burst delay Paul Fulghum
-- strict thread matches above, loose matches on Subject: below --
2005-12-29 16:03 Burkhard Schölpen
2005-12-29 16:55 ` Paul Fulghum
[not found] <5p7gt-3lu-5@gated-at.bofh.it>
2005-12-29 18:40 ` Robert Hancock
2005-12-30 13:23 Burkhard Schölpen
2005-12-30 18:45 ` Robert Hancock
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=395333712@web.de \
--to=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