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:
> > >
> > > > > I'm not saying th
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 M
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:
> >
> > Ther
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 chunks that we'll need, since the DMA API allocator uses
> the system pool it wi
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 devices: A CPU, a decoder and a video output device. All 3
> devices need to
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:
> >
> > > > I'm not saying that it's reasonable to pass (or even allocate) a 1MB
> > > > buffer via the DMA AP
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 given a bunch of large chunks of memory, is there any
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 that all mappings that map a given ph
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 Jul 10 08:58, Russell King - ARM Linux wr
> *
>> > This is difficult to achieve without remapping kernel memory using L2
>> > page tables, so we can unmap pages on 4K page granularity. That's
>> > going to increase TLB overhead and result in lower system performance
>
nel.org; FUJITA
> > > Tomonori; linux...@kvack.org; a...@firstfloor.org; Zach Pfeffer;
> Michael
> > > Bohan; Tim HRM; linux-omap@vger.kernel.org; linux-arm-
> > > ker...@lists.infra
l
> > Bohan; Tim HRM; linux-omap@vger.kernel.org; linux-arm-
> > ker...@lists.infradead.org; ebied...@xmission.com
> > Subject: Re: [RFC 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device
> > memory management
***
on.com
> Subject: Re: [RFC 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device
> memory management
>
> On Tue, Jul 20, 2010 at 03:02:34PM -0700, step...@codeaurora.org wrote:
> > Russell-
> >
> > If a driver wants to allow a device to access memory (and cache
> What is the problem about mapping a 1MB buffer with the DMA API?
>
> Possibly, an IOMMU can't find space for 1MB but it's not the problem of
the DMA API.
As you have pointed out, one of the issues is that allocation can fail.
While technically VCMM allocations can fail as well, these allocations
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 given a bunch of large chunks of memory, is there any API that can
> manage them (asked this on the other thread as well)?
What is
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 Jul 10 08:58, Russell King - ARM Linux wrote:
>> >> On Thu, Jul 15, 2010 at 08:48:36PM -0400, Tim HRM wrote:
>> >> > I
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 Tue, Jul 20, 2010 at 03:02:34PM -0700, step...@codeaurora.org wrote:
> Russell-
>
> If a driver wants to allow a device to access memory (and cache coherency
> is off/not present for device addesses), the driver needs to remap that
> memory as non-cacheable.
If that memory is not part of the k
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 the
> > > current API
Russell-
If a driver wants to allow a device to access memory (and cache coherency
is off/not present for device addesses), the driver needs to remap that
memory as non-cacheable. Suppose there exists a chunk of
physically-contiguous memory (say, memory reserved for device use) that
happened to be
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 acce
On Tue, Jul 20, 2010 at 01:45:17PM -0700, Zach Pfeffer wrote:
> As you mention in your patch the things that can't conflict are memory
> type (strongly- ordered/device/normal), cache policy
> (cacheable/non-cacheable, copy- back/write-through), and coherency
> realm (non-shareable/inner- shareable/
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 Mon, 19 Jul 2010 09:22:13 +0100
Russell King - ARM Linux wrote:
> > If I want to share the buffer with another device I have to
> > make a copy of the entire thing then fix up the virtual mappings for
> > the other device I'm sharing with.
>
> This is something the DMA API doesn't do - probab
On Mon, Jul 19, 2010 at 10:55:15AM -0700, Michael Bohan wrote:
>
> On 7/16/2010 12:58 AM, Russell King - ARM Linux wrote:
>
>> As the patch has been out for RFC since early April on the linux-arm-kernel
>> mailing list (Subject: [RFC] Prohibit ioremap() on kernel managed RAM),
>> and no comments ha
On 7/16/2010 12:58 AM, Russell King - ARM Linux wrote:
As the patch has been out for RFC since early April on the linux-arm-kernel
mailing list (Subject: [RFC] Prohibit ioremap() on kernel managed RAM),
and no comments have come back from Qualcomm folk.
Would it be unreasonable to allow a map
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 conduct
>> > IO through regions of normal RAM, largely accomplish
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 the
> > current API can handle?
>
> The current API can't really handle it because the DMA API doesn
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 that all mappings that map a given physical buffer:
>> > IOMMU mappings, CPU mappings and one-to-one device mappin
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 u
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 conduct
> > IO through regions of normal RAM, largely accomplished through
> > ioremap() calls.
> >
> > Without more publi
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.
>
> Without more public domain documentation of the MSM chips and AMSS
> interfaces I
On Thu, Jul 15, 2010 at 4:55 AM, 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 the sa
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 the same (or compatible) attributes. At this point
> the only attribute that
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-API contained functions to allocate virtua
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
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-API contained functions to allocate virtual space separate
>> > from physical space and reworked how chained buffers fu
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 wrote:
> > >
> > > > > You mean that you
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 probab
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 wrote:
> >
> > > > You mean that you want to specify this alignment attribute every time
> > > > you create an IOMMU
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 work - but then things start to look like the VCM API
> which does graph based
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_boundary_mask
> > > every time you
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_boundary_mask
> > every time you create an IOMMU mapping. It's odd but it should work.
>
> Kinda. I want to f
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 problem I'm trying to solve boils down to this: map a set
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 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
> >> a
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 buffers in a particular way: use 1 MB
>> co
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 buffers in a particular way: use 1 MB
> contiguous physical memory, then 64
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'r
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 talking about
the DMA engine subsystem
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 refactored
>> into platform independen
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 refactored
> into platform independent code.
>
> Comments, suggestions
51 matches
Mail list logo
