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 08:34:55AM +0100, Russell King - ARM Linux wrote:
On Wed, Jul 21, 2010 at 09:25:28PM -0700, Zach Pfeffer wrote:
Yes it is a problem, as Russell has brought up, but there's something
I probably haven't communicated well. I'll use the following example:
There are 3
On Thu, Jul 22, 2010 at 08:39:17AM +0100, Russell King - ARM Linux wrote:
On Wed, Jul 21, 2010 at 09:30:34PM -0700, Zach Pfeffer wrote:
This goes to the nub of the issue. We need a lot of 1 MB physically
contiguous chunks. The system is going to fragment and we'll never get
our 12 1 MB
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 Thu, Jul 22, 2010 at 01:43:26PM +0900, FUJITA Tomonori wrote:
On Wed, 21 Jul 2010 21:30:34 -0700
Zach Pfeffer zpfef...@codeaurora.org wrote:
On Wed, Jul 21, 2010 at 10:44:37AM +0900, FUJITA Tomonori wrote:
On Tue, 20 Jul 2010 15:20:01 -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 3,000-lines another
abstraction layer to solve video4linux's issue nicely.
Its only
On Tue, Jul 20, 2010 at 09:44:12PM -0400, Timothy Meade wrote:
On Tue, Jul 20, 2010 at 8:44 PM, Zach Pfeffer zpfef...@codeaurora.org wrote:
On Mon, Jul 19, 2010 at 05:21:35AM -0400, Tim HRM wrote:
On Fri, Jul 16, 2010 at 8:01 PM, Larry Bassel lbas...@codeaurora.org
wrote:
On 16 Jul 10
On Mon, Jul 19, 2010 at 12:44:49AM -0700, Eric W. Biederman wrote:
Zach Pfeffer zpfef...@codeaurora.org writes:
On Thu, Jul 15, 2010 at 09:55:35AM +0100, Russell King - ARM Linux wrote:
On Wed, Jul 14, 2010 at 06:29:58PM -0700, Zach Pfeffer wrote:
The VCM ensures that all mappings
On Wed, Jul 21, 2010 at 10:44:37AM +0900, FUJITA Tomonori wrote:
On Tue, 20 Jul 2010 15:20:01 -0700
Zach Pfeffer zpfef...@codeaurora.org wrote:
I'm not saying that it's reasonable to pass (or even allocate) a 1MB
buffer via the DMA API.
But given a bunch of large chunks of memory
On Tue, Jul 20, 2010 at 09:54:33PM +0100, Russell King - ARM Linux wrote:
On Tue, Jul 20, 2010 at 01:45:17PM -0700, Zach Pfeffer wrote:
You can also conflict in access permissions which can and do conflict
(which are what multiple mappings are all about...some buffer can get
some access
On Mon, Jul 19, 2010 at 05:21:35AM -0400, Tim HRM wrote:
On Fri, Jul 16, 2010 at 8:01 PM, Larry Bassel lbas...@codeaurora.org wrote:
On 16 Jul 10 08:58, Russell King - ARM Linux wrote:
On Thu, Jul 15, 2010 at 08:48:36PM -0400, Tim HRM wrote:
Interesting, since I seem to remember the MSM
On Thu, Jul 15, 2010 at 09:55:35AM +0100, Russell King - ARM Linux wrote:
On Wed, Jul 14, 2010 at 06:29:58PM -0700, Zach Pfeffer wrote:
The VCM ensures that all mappings that map a given physical buffer:
IOMMU mappings, CPU mappings and one-to-one device mappings all map
that buffer using
On Wed, Jul 14, 2010 at 10:59:38AM +0900, FUJITA Tomonori wrote:
On Tue, 13 Jul 2010 05:14:21 -0700
Zach Pfeffer zpfef...@codeaurora.org wrote:
You mean that you want to specify this alignment attribute every time
you create an IOMMU mapping? Then you can set segment_boundary_mask
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
On Wed, Jul 14, 2010 at 11:05:36PM +0100, Russell King - ARM Linux wrote:
On Wed, Jul 14, 2010 at 01:11:49PM -0700, Zach Pfeffer wrote:
If the DMA-API contained functions to allocate virtual space separate
from physical space and reworked how chained buffers functioned it
would probably
On Wed, Jul 14, 2010 at 06:29:58PM -0700, Zach Pfeffer wrote:
On Wed, Jul 14, 2010 at 11:05:36PM +0100, Russell King - ARM Linux wrote:
On Wed, Jul 14, 2010 at 01:11:49PM -0700, Zach Pfeffer wrote:
If the DMA-API contained functions to allocate virtual space separate
from physical space
On Wed, Jul 14, 2010 at 06:47:34PM -0700, Eric W. Biederman wrote:
Zach Pfeffer zpfef...@codeaurora.org writes:
On Wed, Jul 14, 2010 at 11:05:36PM +0100, Russell King - ARM Linux wrote:
On Wed, Jul 14, 2010 at 01:11:49PM -0700, Zach Pfeffer wrote:
If the DMA-API contained functions
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, Jul 13, 2010 at 03:03:25PM +0900, FUJITA Tomonori wrote:
On Mon, 12 Jul 2010 22:57:06 -0700
Zach Pfeffer zpfef...@codeaurora.org wrote:
FUJITA Tomonori wrote:
On Thu, 08 Jul 2010 16:59:52 -0700
Zach Pfeffer zpfef...@codeaurora.org wrote:
The problem I'm trying to solve
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
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
FUJITA Tomonori wrote:
On Thu, 08 Jul 2010 16:59:52 -0700
Zach Pfeffer zpfef...@codeaurora.org wrote:
The problem I'm trying to solve boils down to this: map a set of
contiguous physical buffers to an aligned IOMMU address. I need to
allocate the set of physical buffers in a particular way
Russell King - ARM Linux wrote:
On Wed, Jul 07, 2010 at 03:44:27PM -0700, Zach Pfeffer wrote:
The DMA API handles the allocation and use of DMA channels. It can
configure physical transfer settings, manage scatter-gather lists,
etc.
You're confused about what the DMA API is. You're
and wanted.
Signed-off-by: Zach Pfeffer zpfef...@codeaurora.org
---
Documentation/vcm.txt | 587 +
1 files changed, 587 insertions(+), 0 deletions(-)
create mode 100644 Documentation/vcm.txt
diff --git a/Documentation/vcm.txt b/Documentation/vcm.txt
-by: Zach Pfeffer zpfef...@codeaurora.org
---
arch/arm/mm/vcm_alloc.c | 425 +
include/linux/vcm_alloc.h | 70
2 files changed, 495 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mm/vcm_alloc.c
create mode 100644 include/linux
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
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
and wanted.
Signed-off-by: Zach Pfeffer zpfef...@codeaurora.org
---
Documentation/vcm.txt | 587 +
1 files changed, 587 insertions(+), 0 deletions(-)
create mode 100644 Documentation/vcm.txt
diff --git a/Documentation/vcm.txt b/Documentation/vcm.txt
Thank you for the corrections. I'm correcting them now. Some responses:
Randy Dunlap wrote:
+struct vcm *vcm_create(size_t start_addr, size_t len);
Seems odd to use size_t for start_addr.
I used size_t because I wanted to allow the start_addr the same range
as len. Is there a better type
and wanted.
Signed-off-by: Zach Pfeffer zpfef...@codeaurora.org
---
Documentation/vcm.txt | 587 +
1 files changed, 587 insertions(+), 0 deletions(-)
create mode 100644 Documentation/vcm.txt
diff --git a/Documentation/vcm.txt b/Documentation/vcm.txt
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
and wanted.
Signed-off-by: Zach Pfeffer zpfef...@codeaurora.org
---
Documentation/vcm.txt | 583 +
1 files changed, 583 insertions(+), 0 deletions(-)
create mode 100644 Documentation/vcm.txt
diff --git a/Documentation/vcm.txt b/Documentation/vcm.txt
-by: Zach Pfeffer zpfef...@codeaurora.org
---
arch/arm/mm/vcm_alloc.c | 425 +
include/linux/vcm_alloc.h | 70
2 files changed, 495 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mm/vcm_alloc.c
create mode 100644 include/linux
FUJITA Tomonori wrote:
On Thu, 24 Jun 2010 23:48:50 -0700
Zach Pfeffer zpfef...@codeaurora.org wrote:
Andi Kleen wrote:
Zach Pfeffer zpfef...@codeaurora.org writes:
This patch contains the documentation for and the main header file of
the API, termed the Virtual Contiguous Memory Manager
Andi Kleen wrote:
Zach Pfeffer zpfef...@codeaurora.org writes:
This patch contains the documentation for and the main header file of
the API, termed the Virtual Contiguous Memory Manager. Its use would
allow all of the IOMMU to VM, VM to device and device to IOMMU
interoperation code
and criticisms are welcome and wanted.
Signed-off-by: Zach Pfeffer zpfef...@codeaurora.org
---
Documentation/vcm.txt | 583
include/linux/vcm.h | 1017 +
2 files changed, 1600 insertions(+), 0 deletions(-)
create mode
42 matches
Mail list logo
