On Wed, Jul 21, 2010 at 08:50:26PM -0700, Zach Pfeffer wrote:
On Wed, Jul 14, 2010 at 10:59:43AM +0900, FUJITA Tomonori wrote:
On Tue, 13 Jul 2010 10:02:23 +0100
Zach Pfeffer said this new VCM infrastructure can be useful for
video4linux. However, I don't think we need 3,000-lines
On Thu, Jul 22, 2010 at 08:51:51AM +0100, Russell King - ARM Linux wrote:
On Wed, Jul 21, 2010 at 08:50:26PM -0700, Zach Pfeffer wrote:
On Wed, Jul 14, 2010 at 10:59:43AM +0900, FUJITA Tomonori wrote:
On Tue, 13 Jul 2010 10:02:23 +0100
Zach Pfeffer said this new VCM infrastructure can
On Thu, Jul 22, 2010 at 01:47:36PM +0900, FUJITA Tomonori wrote:
On Wed, 21 Jul 2010 20:50:26 -0700
Zach Pfeffer zpfef...@codeaurora.org wrote:
On Wed, Jul 14, 2010 at 10:59:43AM +0900, FUJITA Tomonori wrote:
On Tue, 13 Jul 2010 10:02:23 +0100
Zach Pfeffer said this new VCM
On Wed, Jul 14, 2010 at 10:59:43AM +0900, FUJITA Tomonori wrote:
On Tue, 13 Jul 2010 10:02:23 +0100
Zach Pfeffer said this new VCM infrastructure can be useful for
video4linux. However, I don't think we need 3,000-lines another
abstraction layer to solve video4linux's issue nicely.
Its only
On Wed, 21 Jul 2010 20:50:26 -0700
Zach Pfeffer zpfef...@codeaurora.org wrote:
On Wed, Jul 14, 2010 at 10:59:43AM +0900, FUJITA Tomonori wrote:
On Tue, 13 Jul 2010 10:02:23 +0100
Zach Pfeffer said this new VCM infrastructure can be useful for
video4linux. However, I don't think we need
On Mon, Jul 12, 2010 at 10:21:05PM -0700, Zach Pfeffer wrote:
Joerg Roedel wrote:
The DMA-API already does this with the help of IOMMUs if they are
present. What is the benefit of your approach over that?
The grist to the DMA-API mill is the opaque scatterlist. Each
scatterlist element
On Wed, Jul 14, 2010 at 09:34:03PM +0200, Joerg Roedel wrote:
On Mon, Jul 12, 2010 at 10:21:05PM -0700, Zach Pfeffer wrote:
Joerg Roedel wrote:
The DMA-API already does this with the help of IOMMUs if they are
present. What is the benefit of your approach over that?
The grist to
On Mon, 12 Jul 2010 22:46:59 -0700
Zach Pfeffer zpfef...@codeaurora.org wrote:
Joerg Roedel wrote:
On Fri, Jul 02, 2010 at 12:33:51AM -0700, Zach Pfeffer wrote:
Daniel Walker wrote:
So if we include this code which map implementations could you
collapse into this implementations ?
Why video4linux can't use the DMA API? Doing DMA with vmalloc'ed
buffers is a thing that we should avoid (there are some exceptions
like xfs though).
Vmalloc is about the only API for creating virtually linear memory areas.
The video stuff really needs that to avoid lots of horrible special
On Tue, 13 Jul 2010 09:20:12 +0100
Alan Cox a...@lxorguk.ukuu.org.uk wrote:
Why video4linux can't use the DMA API? Doing DMA with vmalloc'ed
buffers is a thing that we should avoid (there are some exceptions
like xfs though).
Vmalloc is about the only API for creating virtually linear
On Tue, 13 Jul 2010 17:30:43 +0900
FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp wrote:
On Tue, 13 Jul 2010 09:20:12 +0100
Alan Cox a...@lxorguk.ukuu.org.uk wrote:
Why video4linux can't use the DMA API? Doing DMA with vmalloc'ed
buffers is a thing that we should avoid (there are some
On Tue, 13 Jul 2010 09:42:44 +0100
Alan Cox a...@lxorguk.ukuu.org.uk wrote:
On Tue, 13 Jul 2010 17:30:43 +0900
FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp wrote:
On Tue, 13 Jul 2010 09:20:12 +0100
Alan Cox a...@lxorguk.ukuu.org.uk wrote:
Why video4linux can't use the DMA API?
On Tue, Jul 13, 2010 at 05:45:39PM +0900, FUJITA Tomonori wrote:
Drivers can tell the USB layer that these are vmapped buffers? Adding
something to struct urb? I might be totally wrong since I don't know
anything about the USB layer.
With non-DMA coherent aliasing caches, you need to know
On Tue, Jul 13, 2010 at 02:59:08PM +0900, FUJITA Tomonori wrote:
On Mon, 12 Jul 2010 22:46:59 -0700
Zach Pfeffer zpfef...@codeaurora.org wrote:
Joerg Roedel wrote:
On Fri, Jul 02, 2010 at 12:33:51AM -0700, Zach Pfeffer wrote:
Daniel Walker wrote:
So if we include this code which
On Tue, 13 Jul 2010 10:02:23 +0100
Russell King - ARM Linux li...@arm.linux.org.uk wrote:
On Tue, Jul 13, 2010 at 05:45:39PM +0900, FUJITA Tomonori wrote:
Drivers can tell the USB layer that these are vmapped buffers? Adding
something to struct urb? I might be totally wrong since I don't
Joerg Roedel wrote:
On Fri, Jul 02, 2010 at 12:09:02AM -0700, Zach Pfeffer wrote:
Hari Kanigeri wrote:
He demonstrated the usage of his code in one of the emails he sent out
initially. Did you go over that, and what (or how many) step would you
use with the current code to do the same thing?
Joerg Roedel wrote:
On Thu, Jul 01, 2010 at 03:00:17PM -0700, Zach Pfeffer wrote:
Additionally, the current IOMMU interface does not allow users to
associate one page table with multiple IOMMUs [...]
Thats not true. Multiple IOMMUs are completly handled by the IOMMU
drivers. In the case of
Joerg Roedel wrote:
On Fri, Jul 02, 2010 at 12:33:51AM -0700, Zach Pfeffer wrote:
Daniel Walker wrote:
So if we include this code which map implementations could you
collapse into this implementations ? Generally , what currently existing
code can VCMM help to eliminate?
In theory, it can
Joerg Roedel wrote:
On Thu, Jul 01, 2010 at 11:17:34PM -0700, Zach Pfeffer wrote:
Andi Kleen wrote:
Hmm? dma_map_* does not change any CPU mappings. It only sets up
DMA mapping(s).
Sure, but I was saying that iommu_map() doesn't just set up the IOMMU
mappings, its sets up both the iommu
On Fri, Jul 02, 2010 at 12:09:02AM -0700, Zach Pfeffer wrote:
Hari Kanigeri wrote:
He demonstrated the usage of his code in one of the emails he sent out
initially. Did you go over that, and what (or how many) step would you
use with the current code to do the same thing?
-- So is this
On Thu, Jul 01, 2010 at 03:00:17PM -0700, Zach Pfeffer wrote:
Additionally, the current IOMMU interface does not allow users to
associate one page table with multiple IOMMUs [...]
Thats not true. Multiple IOMMUs are completly handled by the IOMMU
drivers. In the case of the IOMMU-API backend
On Fri, Jul 02, 2010 at 12:33:51AM -0700, Zach Pfeffer wrote:
Daniel Walker wrote:
So if we include this code which map implementations could you
collapse into this implementations ? Generally , what currently existing
code can VCMM help to eliminate?
In theory, it can eliminate all
On Thu, Jul 01, 2010 at 11:17:34PM -0700, Zach Pfeffer wrote:
Andi Kleen wrote:
Hmm? dma_map_* does not change any CPU mappings. It only sets up
DMA mapping(s).
Sure, but I was saying that iommu_map() doesn't just set up the IOMMU
mappings, its sets up both the iommu and kernel buffer
Andi Kleen wrote:
The standard Linux approach to such a problem is to write
a library that drivers can use for common functionality, not put a middle
layer inbetween. Libraries are much more flexible than layers.
I've been thinking about this statement. Its very true. I use the
genalloc lib
Andi Kleen wrote:
The VCMM provides a more abstract, global view with finer-grained
control of each mapping a user wants to create. For instance, the
semantics of iommu_map preclude its use in setting up just the IOMMU
side of a mapping. With a one-sided map, two IOMMU devices can be
Hmm?
Hari Kanigeri wrote:
He demonstrated the usage of his code in one of the emails he sent out
initially. Did you go over that, and what (or how many) step would you
use with the current code to do the same thing?
-- So is this patch set adding layers and abstractions to help the User ?
If
Hari Kanigeri wrote:
The VCMM takes the long view. Its designed for a future in which the
number of IOMMUs will go up and the ways in which these IOMMUs are
composed will vary from system to system, and may vary at
runtime. Already, there are ~20 different IOMMU map implementations in
the
Daniel Walker wrote:
On Thu, 2010-07-01 at 15:00 -0700, Zach Pfeffer wrote:
Additionally, the current IOMMU interface does not allow users to
associate one page table with multiple IOMMUs unless the user explicitly
wrote a muxed device underneith the IOMMU interface. This also could be
On Thu, Jul 01, 2010 at 11:17:34PM -0700, Zach Pfeffer wrote:
Andi Kleen wrote:
The VCMM provides a more abstract, global view with finer-grained
control of each mapping a user wants to create. For instance, the
semantics of iommu_map preclude its use in setting up just the IOMMU
side of
Andi Kleen wrote:
On Thu, Jul 01, 2010 at 11:17:34PM -0700, Zach Pfeffer wrote:
Andi Kleen wrote:
The VCMM provides a more abstract, global view with finer-grained
control of each mapping a user wants to create. For instance, the
semantics of iommu_map preclude its use in setting up just the
On Tue, 29 Jun 2010 22:55:50 -0700 Zach Pfeffer wrote:
arch/arm/mm/vcm.c | 1901
+
include/linux/vcm.h | 701 +
include/linux/vcm_types.h | 318
3 files changed, 2920 insertions(+), 0 deletions(-)
create
What license (name/type) is this?
IANAL, but AFAIK standard wisdom is that disclaimer in the documentation
and/or other materials provided is generally not acceptable for Linux
because it's an excessive burden for all distributors.
Also for me it's still quite unclear why we would want this
On Thu, 2010-07-01 at 20:02 +0200, Andi Kleen wrote:
What license (name/type) is this?
IANAL, but AFAIK standard wisdom is that disclaimer in the documentation
and/or other materials provided is generally not acceptable for Linux
because it's an excessive burden for all distributors.
It's
On Thu, Jul 01, 2010 at 12:28:23PM -0700, Daniel Walker wrote:
On Thu, 2010-07-01 at 20:02 +0200, Andi Kleen wrote:
What license (name/type) is this?
IANAL, but AFAIK standard wisdom is that disclaimer in the documentation
and/or other materials provided is generally not acceptable for
On Thu, 2010-07-01 at 21:38 +0200, Andi Kleen wrote:
Also for me it's still quite unclear why we would want this code at all...
It doesn't seem to do anything you couldn't do with the existing
interfaces.
I don't know all that much about what Zach's done here, but from what
Randy,
On Thu, 1 Jul 2010, Randy Dunlap wrote:
+ * @start_addr The starting address of the VCM region.
+ * @lenThe len of the VCM region. This must be at least
+ * vcm_min() bytes.
and missing lots of struct members here.
If some of them are private, you can use:
On 07/01/10 13:59, Paul Walmsley wrote:
Randy,
On Thu, 1 Jul 2010, Randy Dunlap wrote:
+ * @start_addr The starting address of the VCM region.
+ * @lenThe len of the VCM region. This must be at least
+ * vcm_min() bytes.
and missing lots of struct members here.
If some
Andi Kleen wrote:
Also for me it's still quite unclear why we would want this code at all...
It doesn't seem to do anything you couldn't do with the existing interfaces.
I don't know all that much about what Zach's done here, but from what
he's said so far it looks like this help to manage
On Thu, 2010-07-01 at 15:00 -0700, Zach Pfeffer wrote:
Additionally, the current IOMMU interface does not allow users to
associate one page table with multiple IOMMUs unless the user explicitly
wrote a muxed device underneith the IOMMU interface. This also could be
done, but would have to be
He demonstrated the usage of his code in one of the emails he sent out
initially. Did you go over that, and what (or how many) step would you
use with the current code to do the same thing?
-- So is this patch set adding layers and abstractions to help the User ?
If the idea is to share some
The VCMM takes the long view. Its designed for a future in which the
number of IOMMUs will go up and the ways in which these IOMMUs are
composed will vary from system to system, and may vary at
runtime. Already, there are ~20 different IOMMU map implementations in
the kernel. Had the Linux
The VCMM provides a more abstract, global view with finer-grained
control of each mapping a user wants to create. For instance, the
symantics of iommu_map preclude its use in setting up just the IOMMU
side of a mapping. With a one-sided map, two IOMMU devices can be
Hmm? dma_map_* does not
42 matches
Mail list logo
