From: Greg KH <gregkh-l3A5Bk7waGM@public.gmane.org>
To: Edward Estabrook
<edward.estabrook.lkml-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
hjk-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org,
edward.estabrook-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
edward_estabrook-+2HdxjxtzLdBDgjK7y7TUQ@public.gmane.org
Subject: Re: [PATCH 1/1] Userspace I/O (UIO): Add support for userspace DMA (corrected)
Date: Wed, 3 Dec 2008 20:17:39 -0800 [thread overview]
Message-ID: <20081204041739.GA16329@suse.de> (raw)
In-Reply-To: <208aa0f00812031751n27a75d21h8747054651639463-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, Dec 03, 2008 at 05:51:30PM -0800, Edward Estabrook wrote:
> From: Edward Estabrook <Edward_Estabrook-+2HdxjxtzLdBDgjK7y7TUQ@public.gmane.org>
>
> Here is a patch that adds the ability to dynamically allocate and use
> coherent DMA
> from userspace by extending the Userspace IO driver. This patch applies against
> 2.6.28-rc6.
>
> The gist of this implementation is to overload uio's mmap
> functionality to allocate
> and map a new DMA region on demand. The bus-specific DMA address as returned by
> dma_alloc_coherent is made available to userspace in the 1st long word
> of the newly
> created region (as well as through the conventional 'addr' file in sysfs).
>
> The kernel-api change is that passing an offset value of 0xFFFFF000UL
> to the a uio
> device's mmap operation will dynamically allocate a DMA region. This
> cannot change/
> break existing behavior as the previous UIO code only allowed a maximum of 5
> mappings.
Odd formatting of your paragraphs :(
Anyway, what about 64bit processors? What happens if they try to use a
valid address in this range?
Is this value always an "invalid" value for all arches that Linux runs
on?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@suse.de>
To: Edward Estabrook <edward.estabrook.lkml@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
hjk@linutronix.de, edward.estabrook@gmail.com,
edward_estabrook@agilent.com
Subject: Re: [PATCH 1/1] Userspace I/O (UIO): Add support for userspace DMA (corrected)
Date: Wed, 3 Dec 2008 20:17:39 -0800 [thread overview]
Message-ID: <20081204041739.GA16329@suse.de> (raw)
In-Reply-To: <208aa0f00812031751n27a75d21h8747054651639463@mail.gmail.com>
On Wed, Dec 03, 2008 at 05:51:30PM -0800, Edward Estabrook wrote:
> From: Edward Estabrook <Edward_Estabrook@agilent.com>
>
> Here is a patch that adds the ability to dynamically allocate and use
> coherent DMA
> from userspace by extending the Userspace IO driver. This patch applies against
> 2.6.28-rc6.
>
> The gist of this implementation is to overload uio's mmap
> functionality to allocate
> and map a new DMA region on demand. The bus-specific DMA address as returned by
> dma_alloc_coherent is made available to userspace in the 1st long word
> of the newly
> created region (as well as through the conventional 'addr' file in sysfs).
>
> The kernel-api change is that passing an offset value of 0xFFFFF000UL
> to the a uio
> device's mmap operation will dynamically allocate a DMA region. This
> cannot change/
> break existing behavior as the previous UIO code only allowed a maximum of 5
> mappings.
Odd formatting of your paragraphs :(
Anyway, what about 64bit processors? What happens if they try to use a
valid address in this range?
Is this value always an "invalid" value for all arches that Linux runs
on?
thanks,
greg k-h
next prev parent reply other threads:[~2008-12-04 4:17 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-04 1:51 [PATCH 1/1] Userspace I/O (UIO): Add support for userspace DMA (corrected) Edward Estabrook
2008-12-04 1:51 ` Edward Estabrook
[not found] ` <208aa0f00812031751n27a75d21h8747054651639463-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-12-04 4:17 ` Greg KH [this message]
2008-12-04 4:17 ` Greg KH
[not found] ` <20081204041739.GA16329-l3A5Bk7waGM@public.gmane.org>
2008-12-04 5:34 ` Edward Estabrook
2008-12-04 5:34 ` Edward Estabrook
2008-12-04 19:40 ` Hans J. Koch
2008-12-04 19:40 ` Hans J. Koch
2008-12-06 0:16 ` Edward Estabrook
2008-12-06 0:16 ` Edward Estabrook
2008-12-11 0:33 ` Hans J. Koch
2008-12-11 0:33 ` Hans J. Koch
2008-12-25 12:30 ` Joerg Roedel
[not found] ` <20081225123004.GA13640-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2008-12-25 15:20 ` Hans J. Koch
2008-12-25 15:20 ` Hans J. Koch
2008-12-27 0:49 ` Andreas Bombe
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=20081204041739.GA16329@suse.de \
--to=gregkh-l3a5bk7wagm@public.gmane.org \
--cc=edward.estabrook-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=edward.estabrook.lkml-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=edward_estabrook-+2HdxjxtzLdBDgjK7y7TUQ@public.gmane.org \
--cc=hjk-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org \
--cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.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 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.