All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joerg Roedel <joerg.roedel@amd.com>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: mingo@elte.hu, linux-kernel@vger.kernel.org, andi@firstfloor.org
Subject: Re: [PATCH 3/3] x86: restore old GART alloc_coherent behavior
Date: Wed, 24 Sep 2008 14:57:40 +0200	[thread overview]
Message-ID: <20080924125740.GT24392@amd.com> (raw)
In-Reply-To: <20080924214353U.fujita.tomonori@lab.ntt.co.jp>

On Wed, Sep 24, 2008 at 09:43:59PM +0900, FUJITA Tomonori wrote:
> On Wed, 24 Sep 2008 14:11:27 +0200
> Joerg Roedel <joerg.roedel@amd.com> wrote:
> 
> > On Wed, Sep 24, 2008 at 08:48:37PM +0900, FUJITA Tomonori wrote:
> > > Currently, GART alloc_coherent tries to allocate pages with GFP_DMA32
> > > for a device having dma_masks > 24bit < 32bits. If GART gets an
> > > address that a device can't access to, GART try to map the address to
> > > a virtual I/O address that the device can access to.
> > > 
> > > But Andi pointed out, "The GART is somewhere in the 4GB range so you
> > > cannot use it to map anything < 4GB. Also GART is pretty small."
> > > 
> > > http://lkml.org/lkml/2008/9/12/43
> > > 
> > > That is, it's possible that GART doesn't have virtual I/O address
> > > space that a device can access to. The above behavior doesn't work for
> > > a device having dma_masks > 24bit < 32bits.
> > > 
> > > This patch restores old GART alloc_coherent behavior (before the
> > > alloc_coherent rewrite).
> > 
> > Patchset looks good in principle. But I have a small question, see
> > below.
> > 
> > > 
> > > Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
> > > ---
> > >  arch/x86/kernel/pci-gart_64.c |   43 +++++++++++++++++++---------------------
> > >  1 files changed, 20 insertions(+), 23 deletions(-)
> > > 
> > > diff --git a/arch/x86/kernel/pci-gart_64.c b/arch/x86/kernel/pci-gart_64.c
> > > index 7e08e46..25c94fb 100644
> > > --- a/arch/x86/kernel/pci-gart_64.c
> > > +++ b/arch/x86/kernel/pci-gart_64.c
> > > @@ -487,31 +487,28 @@ static void *
> > >  gart_alloc_coherent(struct device *dev, size_t size, dma_addr_t *dma_addr,
> > >  		    gfp_t flag)
> > >  {
> > > -	void *vaddr;
> > >  	dma_addr_t paddr;
> > >  	unsigned long align_mask;
> > > -	u64 dma_mask = dma_alloc_coherent_mask(dev, flag);
> > > -
> > > -	vaddr = (void *)__get_free_pages(flag | __GFP_ZERO, get_order(size));
> > > -	if (!vaddr)
> > > -		return NULL;
> > > -
> > > -	paddr = virt_to_phys(vaddr);
> > > -	if (is_buffer_dma_capable(dma_mask, paddr, size)) {
> > > -		*dma_addr = paddr;
> > > -		return vaddr;
> > > -	}
> > > -
> > > -	align_mask = (1UL << get_order(size)) - 1;
> > > -
> > > -	*dma_addr = dma_map_area(dev, paddr, size, DMA_BIDIRECTIONAL,
> > > -				 align_mask);
> > > -	flush_gart();
> > > -
> > > -	if (*dma_addr != bad_dma_address)
> > > -		return vaddr;
> > > -
> > > -	free_pages((unsigned long)vaddr, get_order(size));
> > > +	struct page *page;
> > > +
> > > +	if (force_iommu && !(flag & GFP_DMA)) {
> > > +		flag &= ~(__GFP_DMA | __GFP_HIGHMEM | __GFP_DMA32);
> > > +		page = alloc_pages(flag | __GFP_ZERO, get_order(size));
> > > +		if (!page)
> > > +			return NULL;
> > > +
> > > +		align_mask = (1UL << get_order(size)) - 1;
> > > +		paddr = dma_map_area(dev, page_to_phys(page), size,
> > > +				     DMA_BIDIRECTIONAL, align_mask);
> > 
> > Can't we check if a mapping is required before calling dma_map_area?
> > Your recently introduced IOMMU helper functions should make that easy
> > and GART address space is a rare resource. AFAIR this is also the
> > behaviour of the old generic dma_alloc_coherent function.
> 
> I think that the behavior of the old generic dma_alloc_coherent
> function and GART is different.
> 
> The old GART code does virtual mappings only with force_iommu option
> enabled. The old GART code always do virtual mappings with force_iommu
> option enabled (unless GFP_DMA is set).

Hmm true, the old code called map_simple and not map_single so it mapped
always.

> 
> 
> > > +
> > > +		flush_gart();
> > 
> > This should depend on need_flush.
> 
> Theoretically, yes, I think. But this patch restores the old GART code
> behavior.

Ok. The map_simple function of GART did it unconditionally too so this
is the old behavior. But its safe here to flush conditionally. I'll send
a follow-up patch.

Joerg

-- 
           |           AMD Saxony Limited Liability Company & Co. KG
 Operating |         Wilschdorfer Landstr. 101, 01109 Dresden, Germany
 System    |                  Register Court Dresden: HRA 4896
 Research  |              General Partner authorized to represent:
 Center    |             AMD Saxony LLC (Wilmington, Delaware, US)
           | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy


  reply	other threads:[~2008-09-24 12:57 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-24 11:48 [PATCH 0/3] x86: restore old GART alloc_coherent FUJITA Tomonori
2008-09-24 11:48 ` [PATCH 1/3] x86: export pci-nommu's alloc_coherent FUJITA Tomonori
2008-09-24 11:48   ` [PATCH 2/3] revert "x86: make GART to respect device's dma_mask about virtual mappings" FUJITA Tomonori
2008-09-24 11:48     ` [PATCH 3/3] x86: restore old GART alloc_coherent behavior FUJITA Tomonori
2008-09-24 12:11       ` Joerg Roedel
2008-09-24 12:43         ` FUJITA Tomonori
2008-09-24 12:57           ` Joerg Roedel [this message]
2008-09-24 13:06       ` Alan Cox
2008-09-24 22:01       ` Andi Kleen
2008-09-24 12:58 ` [PATCH 0/3] x86: restore old GART alloc_coherent Joerg Roedel
2008-09-25  9:04 ` Ingo Molnar

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=20080924125740.GT24392@amd.com \
    --to=joerg.roedel@amd.com \
    --cc=andi@firstfloor.org \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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.