From: "Burkhard Schölpen" <bschoelpen@web.de>
To: RobertHancock <hancockr@shaw.ca>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: PCI DMA burst delay
Date: Fri, 30 Dec 2005 14:23:19 +0100 [thread overview]
Message-ID: <397463649@web.de> (raw)
>What kind of PCI transaction is the core using to do the reads? I think
>that Memory Read can cause bursts to be interrupted quickly on some
>chipsets. If you can use Memory Read Line or Memory Read Multiple this
>may increase performance.
>
>You may also need more buffering in the FPGA, otherwise you may be
>vulnerable to underruns if there is contention on the PCI bus. The
>device should be able to handle normal arbitration delays.
Yeah, that was it! I asked the programmer of the FPGA and he told me that he was using the normal Memory Read transaction. After changing that to MRM we get a much higher burst length. Now the buffer underruns really seem to be disappeared, that is great! He also told me that the fifo buffer on the FPGA could not be larger, because the size is somehow limited in the core (it's some special block ram I think...), so we are lucky that the burst length seems to fix our problem.
By the way, there is another question coming up to my mind. The pci card is to be designed for a large size copying machine (i.e. it is something like a framegrabber device which has to write out data to a printer simultaneously) which leads to really high bandwidth. For now I allocate the dma buffer in ram (a ringbuffer) using pci_alloc_consistent(), which unfortunately delimits the size to about 4 MB. However, it would be convenient to be able to allocate a larger dma buffer, because then we would be able to perform some image processing algorithms directly inside this buffer via mmapping it to user space. Is there any way to achieve this quite simple without being forced to use scatter/gather dma (our hardware is not able to do this - at least until now)?
Thank you very much for your help!
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-30 13:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-30 13:23 Burkhard Schölpen [this message]
2005-12-30 18:45 ` PCI DMA burst delay Robert Hancock
[not found] <5p7gt-3lu-5@gated-at.bofh.it>
2005-12-29 18:40 ` Robert Hancock
-- strict thread matches above, loose matches on Subject: below --
2005-12-29 16:03 Burkhard Schölpen
2005-12-29 16:55 ` Paul Fulghum
2005-12-29 14:43 Burkhard Schölpen
2005-12-29 15:23 ` Paul Fulghum
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=397463649@web.de \
--to=bschoelpen@web.de \
--cc=hancockr@shaw.ca \
--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