On Thu, Jul 22, 2010 at 01:43:26PM +0900, FUJITA Tomonori wrote:
> On Wed, 21 Jul 2010 21:30:34 -0700
> Zach Pfeffer 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 wrote
On Thu, Jul 22, 2010 at 01:47:36PM +0900, FUJITA Tomonori wrote:
> On Wed, 21 Jul 2010 20:50:26 -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
> > >
> > > Zac
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 ne
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
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
> > >
> >
On Wed, Jul 21, 2010 at 10:44:37AM +0900, FUJITA Tomonori wrote:
> On Tue, 20 Jul 2010 15:20:01 -0700
> Zach Pfeffer wrote:
>
> > > I'm not saying that it's reasonable to pass (or even allocate) a 1MB
> > > buffer via the DMA API.
> >
> > But
On Mon, Jul 19, 2010 at 12:44:49AM -0700, Eric W. Biederman wrote:
> Zach Pfeffer 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 t
On Tue, Jul 20, 2010 at 09:44:12PM -0400, Timothy Meade wrote:
> On Tue, Jul 20, 2010 at 8:44 PM, Zach Pfeffer 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
> >> wrote:
> >> > On 16
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&
On Mon, Jul 19, 2010 at 05:21:35AM -0400, Tim HRM wrote:
> On Fri, Jul 16, 2010 at 8:01 PM, Larry Bassel 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 devices mostly
On Mon, Jul 19, 2010 at 09:22:13AM +0100, Russell King - ARM Linux wrote:
> On Wed, Jul 14, 2010 at 06:41:48PM -0700, Zach Pfeffer wrote:
> > On Thu, Jul 15, 2010 at 08:07:28AM +0900, FUJITA Tomonori wrote:
> > > Why we we need a new abstraction layer to solve the problem that
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 c
On Fri, Jul 16, 2010 at 08:58:56AM +0100, 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 devices mostly conduct
> > IO through regions of normal RAM, largely accomplished through
> > ioremap() calls.
> >
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
On Wed, Jul 14, 2010 at 06:47:34PM -0700, Eric W. Biederman wrote:
> Zach Pfeffer 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-AP
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 s
On Thu, Jul 15, 2010 at 08:07:28AM +0900, FUJITA Tomonori wrote:
> On Wed, 14 Jul 2010 13:11:49 -0700
> Zach Pfeffer wrote:
>
> > On Wed, Jul 14, 2010 at 10:59:38AM +0900, FUJITA Tomonori wrote:
> > > On Tue, 13 Jul 2010 05:14:21 -0700
> > > Zach Pfeffer wrot
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 function
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 bene
On Wed, Jul 14, 2010 at 10:59:38AM +0900, FUJITA Tomonori wrote:
> On Tue, 13 Jul 2010 05:14:21 -0700
> Zach Pfeffer wrote:
>
> > > You mean that you want to specify this alignment attribute every time
> > > you create an IOMMU mapping? Then you can set segment_boundar
On Tue, Jul 13, 2010 at 03:03:25PM +0900, FUJITA Tomonori wrote:
> On Mon, 12 Jul 2010 22:57:06 -0700
> Zach Pfeffer wrote:
>
> > FUJITA Tomonori wrote:
> > > On Thu, 08 Jul 2010 16:59:52 -0700
> > > Zach Pfeffer wrote:
> > >
> > >> The pro
On Tue, Jul 13, 2010 at 02:59:08PM +0900, FUJITA Tomonori wrote:
> On Mon, 12 Jul 2010 22:46:59 -0700
> Zach Pfeffer wrote:
>
> > Joerg Roedel wrote:
> > > On Fri, Jul 02, 2010 at 12:33:51AM -0700, Zach Pfeffer wrote:
> > >> Daniel Walker wrote:
> > &
FUJITA Tomonori wrote:
> On Thu, 08 Jul 2010 16:59:52 -0700
> Zach Pfeffer 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 buffe
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
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 exis
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 IO
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
>
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 co
Eric W. Biederman wrote:
> Zach Pfeffer writes:
>
>> This patch contains the documentation for 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 to be ref
Signed-off-by: Zach Pfeffer
---
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/vcm_alloc.h
di
wanted.
Signed-off-by: Zach Pfeffer
---
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
new file mode 100644
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
wanted.
Signed-off-by: Zach Pfeffer
---
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
new file mode 100644
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
>>>&g
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
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
>
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 ?
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
>
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
wanted.
Signed-off-by: Zach Pfeffer
---
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
new file mode 100644
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 t
Signed-off-by: Zach Pfeffer
---
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/vcm_alloc.h
di
wanted.
Signed-off-by: Zach Pfeffer
---
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
new file mode 100644
FUJITA Tomonori wrote:
> On Thu, 24 Jun 2010 23:48:50 -0700
> Zach Pfeffer wrote:
>
>> Andi Kleen wrote:
>>> Zach Pfeffer writes:
>>>
>>>> This patch contains the documentation for and the main header file of
>>>> the API, termed the Vi
Andi Kleen wrote:
> Zach Pfeffer 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
>> intero
criticisms are welcome and wanted.
Signed-off-by: Zach Pfeffer
---
Documentation/vcm.txt | 583
include/linux/vcm.h | 1017 +
2 files changed, 1600 insertions(+), 0 deletions(-)
create mode 100644 Documentation
46 matches
Mail list logo
