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 11:37:11 -0600 [thread overview]
Message-ID: <4891F847.7030100@shaw.ca> (raw)
In-Reply-To: <1217509868.2156.18.camel@atlas>
V.Radhakrishnan wrote:
> Hi Robert,
>
> Thanks for the reply. I was thinking that the MMIO and reserve memory
> will be below 4 GB was only applicable for 32-bit environments, since I
> don't have much experience in 64-bit.
>
> However, I had an IDENTICAL problem over 2 years ago. I had used
> posix_memalign() in user space to allocate pages aligned to 4096 byte
> pages, allocated several additional memaligned pages in user space, used
> mlock() to lock all these pages, gathered the user space addresses into
> the original pages as arrays of structures, passed this array into the
> kernel using an ioctl() call, used get_user_pages() to extract the
> struct page pointers, performed a kmap() to get the kernel virtual
> addresses and then extracted the physical addresses and 'sent' this to
> the chip to perform DMA.
>
> This situation is almost identical to what has been reported and hence
> my interest.
>
> However, I had a PCI access problem. The DMA was just NOT happening on
> any machine which had highmem, i.e over 896 MB.
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.
>
> I "solved" the problem since I didn't have much time to do R&D, by
> booting with kernel command line option of mem=512M and the DMA went
> thru successfully.
>
> This was the linux-2.6.15 kernel then. Since the project was basically
> to test the DMA capability of the device, the actual address to where it
> was DMA-ed didn't matter, and I got paid for my work. However, this
> matter was always at the back of my head.
>
> What could have been the problem with the x86 32-bit PCI ?
>
> Thanks and regards
>
> V. Radhakrishnan
> www.atr-labs.com
>
> On Wed, 2008-07-30 at 13:21 -0600, Robert Hancock wrote:
>> V.Radhakrishnan wrote:
>>>>> am testing this in an X86_64 architecture machine with 4 GB of RAM. I
>>>>> am able to successfully dma data into any memory (dma) address >
>>>>> 0x0000_0001_0000_0000.
>>> How can you DMA "successfully" into this address which is > 4 GB when
>>> you have only 4 GB RAM ? Or am I missing something ?
>> The MMIO and other reserved memory space at the top of the 32-bit memory
>> space will cause the top part of memory to be relocated above 4GB.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>
>
next prev parent reply other threads:[~2008-07-31 17:37 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 [this message]
2008-07-31 18:47 ` V.Radhakrishnan
2008-07-31 18:52 ` Robert Hancock
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=4891F847.7030100@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.