From: Earl Chew <earl_chew@agilent.com>
To: "Hans J. Koch" <hjk@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org, gregkh@suse.de,
linux-mm <linux-mm@kvack.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 1/1] Userspace I/O (UIO): Add support for userspace DMA
Date: Tue, 15 Dec 2009 16:20:56 -0800 [thread overview]
Message-ID: <4B2827E8.60602@agilent.com> (raw)
In-Reply-To: <20091215222811.GC2432@local>
Hans J. Koch wrote:
> One example: An A/D converter has an on-chip 32k buffer. It causes an
> interrupt as soon as the buffer is filled up to a certain high-water mark.
> Such cases would easily fit into the current UIO system. The UIO core could
> simply DMA the data to one of the mappings. A new flag for that mapping and
> a few other changes are all it takes. After the DMA transfer is complete, the
> interrupt is passed on to userspace, which would find the buffer already
> filled with the desired data. Just a thought, unfortunately I haven't got
> such hardware to try it.
Hans,
Is this case already covered by the pre-existing UIO_MEM_LOGICAL
option ?
I'm thinking that since the memory is statically defined, it can be
described using one of the existing struct uio_mem mem[] slots in
struct uio_info and marked as UIO_MEM_LOGICAL.
The userspace program can map that into its process space using the
existing mmap() interface.
What am I missing?
> When it comes to dynamically allocated DMA buffers, it might well be possible
> to add a new directory in sysfs besides the "mem" directory, e.g. something
> like /sys/class/uio/uioN/dma-mem/. This would save us the trouble of creating
> a new device. Maybe the example above would better fit in here, too. Who knows.
I looked at the 2.6.32 source at
http://lxr.linux.no/#linux+v2.6.32/drivers/uio/uio.c
and didn't see any reference to /sys/class/uio/uioN/mem . Perhaps
you're referring to something new.
In any case, I think you're describing adding
/sys/class/uio/uioN/dma-mem
as a means to control /dev/uioN . Presumably writing to
/sys/class/uio/uioN/dma-mem would create additional dynamic
DMA buffers.
I can't yet see a way to make this request-response. When requesting
a dynamic buffer I need to indicate the size that I want, and in
return I need to obtain a handle to the buffer (either its mapping
number, address, etc). Once I have that, I can query other
interesting information (eg its bus address).
Earl
WARNING: multiple messages have this Message-ID (diff)
From: Earl Chew <earl_chew@agilent.com>
To: "Hans J. Koch" <hjk@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org, gregkh@suse.de,
linux-mm <linux-mm@kvack.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 1/1] Userspace I/O (UIO): Add support for userspace DMA
Date: Tue, 15 Dec 2009 16:20:56 -0800 [thread overview]
Message-ID: <4B2827E8.60602@agilent.com> (raw)
In-Reply-To: <20091215222811.GC2432@local>
Hans J. Koch wrote:
> One example: An A/D converter has an on-chip 32k buffer. It causes an
> interrupt as soon as the buffer is filled up to a certain high-water mark.
> Such cases would easily fit into the current UIO system. The UIO core could
> simply DMA the data to one of the mappings. A new flag for that mapping and
> a few other changes are all it takes. After the DMA transfer is complete, the
> interrupt is passed on to userspace, which would find the buffer already
> filled with the desired data. Just a thought, unfortunately I haven't got
> such hardware to try it.
Hans,
Is this case already covered by the pre-existing UIO_MEM_LOGICAL
option ?
I'm thinking that since the memory is statically defined, it can be
described using one of the existing struct uio_mem mem[] slots in
struct uio_info and marked as UIO_MEM_LOGICAL.
The userspace program can map that into its process space using the
existing mmap() interface.
What am I missing?
> When it comes to dynamically allocated DMA buffers, it might well be possible
> to add a new directory in sysfs besides the "mem" directory, e.g. something
> like /sys/class/uio/uioN/dma-mem/. This would save us the trouble of creating
> a new device. Maybe the example above would better fit in here, too. Who knows.
I looked at the 2.6.32 source at
http://lxr.linux.no/#linux+v2.6.32/drivers/uio/uio.c
and didn't see any reference to /sys/class/uio/uioN/mem . Perhaps
you're referring to something new.
In any case, I think you're describing adding
/sys/class/uio/uioN/dma-mem
as a means to control /dev/uioN . Presumably writing to
/sys/class/uio/uioN/dma-mem would create additional dynamic
DMA buffers.
I can't yet see a way to make this request-response. When requesting
a dynamic buffer I need to indicate the size that I want, and in
return I need to obtain a handle to the buffer (either its mapping
number, address, etc). Once I have that, I can query other
interesting information (eg its bus address).
Earl
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2009-12-16 0:21 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-03 21:39 [PATCH 1/1] Userspace I/O (UIO): Add support for userspace DMA edward_estabrook
2008-12-03 22:00 ` Leon Woestenberg
2008-12-04 2:44 ` Edward Estabrook
2008-12-04 0:49 ` Greg KH
2008-12-04 0:50 ` Greg KH
2008-12-04 1:49 ` Edward Estabrook
2008-12-04 8:39 ` Peter Zijlstra
2008-12-04 8:39 ` Peter Zijlstra
2008-12-04 10:27 ` Hugh Dickins
2008-12-04 10:27 ` Hugh Dickins
2008-12-23 21:32 ` Max Krasnyansky
2008-12-23 21:32 ` Max Krasnyansky
2008-12-04 18:08 ` Hans J. Koch
2008-12-04 18:08 ` Hans J. Koch
2008-12-05 7:10 ` Peter Zijlstra
2008-12-05 7:10 ` Peter Zijlstra
2008-12-05 9:44 ` Hans J. Koch
2008-12-05 9:44 ` Hans J. Koch
2008-12-06 0:32 ` Edward Estabrook
2008-12-06 0:32 ` Edward Estabrook
2008-12-12 17:25 ` Peter Zijlstra
2008-12-13 0:29 ` Hans J. Koch
2009-12-12 0:02 ` Earl Chew
2009-12-12 0:02 ` Earl Chew
2009-12-14 19:23 ` Hans J. Koch
2009-12-14 19:23 ` Hans J. Koch
2009-12-15 13:34 ` Earl Chew
2009-12-15 13:34 ` Earl Chew
2009-12-15 17:47 ` Earl Chew
2009-12-15 17:47 ` Earl Chew
2009-12-15 21:33 ` Hans J. Koch
2009-12-15 21:33 ` Hans J. Koch
2009-12-15 21:00 ` Hans J. Koch
2009-12-15 21:00 ` Hans J. Koch
2009-12-15 21:47 ` Earl Chew
2009-12-15 21:47 ` Earl Chew
2009-12-15 22:28 ` Hans J. Koch
2009-12-15 22:28 ` Hans J. Koch
2009-12-16 0:20 ` Earl Chew [this message]
2009-12-16 0:20 ` Earl Chew
2009-12-16 1:23 ` Hans J. Koch
2009-12-16 1:23 ` Hans J. Koch
2009-12-16 1:45 ` Earl Chew
2009-12-16 1:45 ` Earl Chew
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=4B2827E8.60602@agilent.com \
--to=earl_chew@agilent.com \
--cc=gregkh@suse.de \
--cc=hjk@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
/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.