From: Robert Hancock <hancockr@shaw.ca>
To: "V.Radhakrishnan" <rk@atr-labs.com>
Cc: Sanka Piyaratna <cesanka@yahoo.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
linux-kernel@vger.kernel.org
Subject: Re: PCIe device driver question
Date: Thu, 31 Jul 2008 12:52:48 -0600 [thread overview]
Message-ID: <48920A00.1060902@shaw.ca> (raw)
In-Reply-To: <1217530046.7668.29.camel@atlas>
V.Radhakrishnan wrote:
>> My guess there was a bug in your DMA mapping code. I don't think kmap is
>> what is normally used for this. I think with get_user_pages one usually
>> takes the returned page pointers to create an SG list and uses
>> dma_map_sg to create a DMA mapping for them.
>
> Looking at the actual code, I see that I had used kmap() only to obtain
> kernel virtual addresses for the array of struct pages obtained from
> user space by using get_user_pages.
>
> Subsequently, I had used dma_map_single() and dma_unmap_single() calls
> for single buffer calls.
I'm suspicious about this usage, I don't know if that will actually
work. There is a dma_map_page call which is meant for doing a DMA
mapping on a struct page which should likely be used instead.
>
> The code didn't have bugs IMHO since it was used for extensive stress
> testing the initial FPGA prototype as well as the final ASIC chip ,
> sometimes running for over 4 days non-stop without breaking.
>
> However, using Test Access Points on the board and using a Logic
> Analyzer showed that DMA was NOT taking place when RAM > 896 MB was
> used. The hardware gurus said that PCI bus cycles just didn't seem to be
> taking place when RAM > 896 MB was used as the source OR destination
> address.
Are you sure the address being passed to the device was correct in this
case? There should be nothing magical about 896MB from a hardware point
of view, and the kernel in general cannot stop you from DMAing anywhere
you like.
>
> Perhaps this was a problem in the earlier kernel(s) and has since been
> rectified ? ( I was using 2.6.15 then ... )
>
> I am just curious since Sanka Piyaratna reported a 'similar' kind of
> situation.
>
> Regards
>
> V. Radhakrishnan
next prev parent reply other threads:[~2008-07-31 18:53 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <fa.PmBLCqOb4Xo53y3W9hAdnsU50Og@ifi.uio.no>
[not found] ` <fa.42mxuHHJP7XQmYeyxNoEC/NFUHA@ifi.uio.no>
2008-07-30 19:21 ` PCIe device driver question Robert Hancock
2008-07-31 13:11 ` V.Radhakrishnan
2008-07-31 17:37 ` Robert Hancock
2008-07-31 18:47 ` V.Radhakrishnan
2008-07-31 18:52 ` Robert Hancock [this message]
2008-07-31 20:47 ` V.Radhakrishnan
2008-07-31 9:58 Sanka Piyaratna
-- strict thread matches above, loose matches on Subject: below --
2008-07-30 22:55 Sanka Piyaratna
2008-07-31 8:44 ` Robert Hancock
[not found] <fa.+kKL98uFtvbcX3ymh2HlJuUDVwY@ifi.uio.no>
2008-07-30 19:24 ` Robert Hancock
2008-07-30 16:09 Sanka Piyaratna
2008-07-30 16:51 ` V.Radhakrishnan
2008-07-30 16:55 ` Alan Cox
2008-07-30 16:00 Sanka Piyaratna
2008-07-30 15:47 ` Alan Cox
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=48920A00.1060902@shaw.ca \
--to=hancockr@shaw.ca \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=cesanka@yahoo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rk@atr-labs.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.