All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jerome Glisse <j.glisse@gmail.com>
Cc: dri-devel@lists.freedesktop.org, thomas@shipmail.org,
	airlied@linux.ie, linux-kernel@vger.kernel.org,
	Alex Deucher <alexdeucher@gmail.com>,
	Jerome Glisse <jglisse@redhat.com>,
	konrad@darnok.org
Subject: Re: [PATCH 4/5] radeon/ttm/PCIe: Use dma_addr if TTM has set it.
Date: Fri, 28 Jan 2011 10:03:11 -0500	[thread overview]
Message-ID: <20110128150310.GA29440@dumpdata.com> (raw)
In-Reply-To: <AANLkTimKgfKwtWpXBvTGmJbW-2uGhV+7nMahsScUM0pr@mail.gmail.com>

On Fri, Jan 28, 2011 at 09:42:48AM -0500, Jerome Glisse wrote:
> On Thu, Jan 27, 2011 at 4:20 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> > On Fri, Jan 07, 2011 at 12:11:43PM -0500, Konrad Rzeszutek Wilk wrote:
> >> If the TTM layer has used the DMA API to setup pages that are
> >> TTM_PAGE_FLAG_DMA32 (look at patch titled: "ttm: Utilize the dma_addr_t
> >> array for pages that are to in DMA32 pool."), lets use it
> >> when programming the GART in the PCIe type cards.
> >>
> >> This patch skips doing the pci_map_page (and pci_unmap_page) if
> >> there is a DMA addresses passed in for that page. If the dma_address
> >> is zero (or DMA_ERROR_CODE), then we continue on with our old
> >> behaviour.
> >
> > Hey Jerome,
> >
> > I should have CC-ed you earlier but missed that and instead just
> > CC-ed the mailing list. I was wondering what your thoughts are
> > about this patchset? Thomas took a look at the patchset and he is OK
> > but more eyes never hurt.
> >
> > FYI, for clarity I hadn't made the old calls that got moved due
> > to adding of "{" checkpatch.pl compliant. It complains about it being
> > past 80 characters. I can naturally fix that up, but thought
> > that it might detract from the nature of the patch.
> 
> What happen when we don't ask dma32 alloc to ttm ? Will this still
> work in virtualized environnement ?

You mean if we don't pass in the TTM_PAGE_FLAG_DMA32? It will go back
to using the old mechanism - which is to allocate page using
alloc_page(GFP_HIGHUSER). Which should be OK in baremetal or
virtualized environment - and as long as the driver uses the page
for non-DMA type things, or the graphic card is 64-bit capable at which
point it has no trouble reaching it.

> 
> Code looks good but GART stuff can be picky, i will try to do a full
> scale testing in next couple week.

Thank you! Much appreciated. Would it be OK if I pinged you in two weeks
time just in case?

WARNING: multiple messages have this Message-ID (diff)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jerome Glisse <j.glisse@gmail.com>
Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Jerome Glisse <jglisse@redhat.com>,
	konrad@darnok.org
Subject: Re: [PATCH 4/5] radeon/ttm/PCIe: Use dma_addr if TTM has set it.
Date: Fri, 28 Jan 2011 10:03:11 -0500	[thread overview]
Message-ID: <20110128150310.GA29440@dumpdata.com> (raw)
In-Reply-To: <AANLkTimKgfKwtWpXBvTGmJbW-2uGhV+7nMahsScUM0pr@mail.gmail.com>

On Fri, Jan 28, 2011 at 09:42:48AM -0500, Jerome Glisse wrote:
> On Thu, Jan 27, 2011 at 4:20 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> > On Fri, Jan 07, 2011 at 12:11:43PM -0500, Konrad Rzeszutek Wilk wrote:
> >> If the TTM layer has used the DMA API to setup pages that are
> >> TTM_PAGE_FLAG_DMA32 (look at patch titled: "ttm: Utilize the dma_addr_t
> >> array for pages that are to in DMA32 pool."), lets use it
> >> when programming the GART in the PCIe type cards.
> >>
> >> This patch skips doing the pci_map_page (and pci_unmap_page) if
> >> there is a DMA addresses passed in for that page. If the dma_address
> >> is zero (or DMA_ERROR_CODE), then we continue on with our old
> >> behaviour.
> >
> > Hey Jerome,
> >
> > I should have CC-ed you earlier but missed that and instead just
> > CC-ed the mailing list. I was wondering what your thoughts are
> > about this patchset? Thomas took a look at the patchset and he is OK
> > but more eyes never hurt.
> >
> > FYI, for clarity I hadn't made the old calls that got moved due
> > to adding of "{" checkpatch.pl compliant. It complains about it being
> > past 80 characters. I can naturally fix that up, but thought
> > that it might detract from the nature of the patch.
> 
> What happen when we don't ask dma32 alloc to ttm ? Will this still
> work in virtualized environnement ?

You mean if we don't pass in the TTM_PAGE_FLAG_DMA32? It will go back
to using the old mechanism - which is to allocate page using
alloc_page(GFP_HIGHUSER). Which should be OK in baremetal or
virtualized environment - and as long as the driver uses the page
for non-DMA type things, or the graphic card is 64-bit capable at which
point it has no trouble reaching it.

> 
> Code looks good but GART stuff can be picky, i will try to do a full
> scale testing in next couple week.

Thank you! Much appreciated. Would it be OK if I pinged you in two weeks
time just in case?

  reply	other threads:[~2011-01-28 15:04 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-07 17:11 [RFC PATCH v2] Utilize the PCI API in the TTM framework Konrad Rzeszutek Wilk
2011-01-07 17:11 ` [PATCH 1/5] ttm: Introduce a placeholder for DMA (bus) addresses Konrad Rzeszutek Wilk
2011-01-27  9:13   ` Thomas Hellstrom
2011-01-07 17:11 ` [PATCH 2/5] tm: Utilize the dma_addr_t array for pages that are to in DMA32 pool Konrad Rzeszutek Wilk
2011-01-27  9:17   ` Thomas Hellstrom
2011-01-07 17:11 ` [PATCH 3/5] ttm: Expand (*populate) to support an array of DMA addresses Konrad Rzeszutek Wilk
2011-01-27  9:19   ` Thomas Hellstrom
2011-01-27 21:10     ` Konrad Rzeszutek Wilk
2011-01-07 17:11 ` [PATCH 4/5] radeon/ttm/PCIe: Use dma_addr if TTM has set it Konrad Rzeszutek Wilk
2011-01-27 21:20   ` Konrad Rzeszutek Wilk
2011-01-28 14:42     ` Jerome Glisse
2011-01-28 14:42       ` Jerome Glisse
2011-01-28 15:03       ` Konrad Rzeszutek Wilk [this message]
2011-01-28 15:03         ` Konrad Rzeszutek Wilk
2011-02-16 15:54       ` Konrad Rzeszutek Wilk
2011-02-16 15:54         ` Konrad Rzeszutek Wilk
2011-02-16 18:51         ` Jerome Glisse
2011-01-07 17:11 ` [PATCH 5/5] nouveau/ttm/PCIe: " Konrad Rzeszutek Wilk
2011-01-27 21:22   ` Konrad Rzeszutek Wilk
2011-01-07 22:21 ` [RFC PATCH v2] Utilize the PCI API in the TTM framework Ian Campbell
2011-01-08 10:41 ` Thomas Hellstrom
2011-01-10 14:25 ` Thomas Hellstrom
2011-01-10 15:21   ` Konrad Rzeszutek Wilk
2011-01-10 15:58     ` Thomas Hellstrom
2011-01-10 15:58       ` Thomas Hellstrom
2011-01-10 16:45       ` Konrad Rzeszutek Wilk
2011-01-10 20:50         ` Thomas Hellstrom
2011-01-11 15:55           ` Konrad Rzeszutek Wilk
2011-01-11 15:55             ` Konrad Rzeszutek Wilk
2011-01-11 16:21             ` Alex Deucher
2011-01-11 16:21               ` Alex Deucher
2011-01-11 16:59               ` Konrad Rzeszutek Wilk
2011-01-11 16:59                 ` Konrad Rzeszutek Wilk
2011-01-11 18:12                 ` Alex Deucher
2011-01-11 18:28                   ` Konrad Rzeszutek Wilk
2011-01-11 19:28                     ` Alex Deucher
2011-01-12  9:12             ` Thomas Hellstrom
2011-01-12 15:19               ` Konrad Rzeszutek Wilk
2011-01-12 15:19                 ` Konrad Rzeszutek Wilk
2011-01-24 14:49                 ` Konrad Rzeszutek Wilk
2011-01-24 14:49                   ` Konrad Rzeszutek Wilk
2011-01-27  9:28 ` Thomas Hellstrom
2011-01-27 21:13   ` Konrad Rzeszutek Wilk
2011-03-21 13:11 ` Michel Dänzer
2011-03-21 23:18   ` Konrad Rzeszutek Wilk
2011-03-21 23:18     ` Konrad Rzeszutek Wilk
2011-03-22 13:13     ` Michel Dänzer
2011-03-22 13:13       ` Michel Dänzer
2011-03-22 14:54       ` Konrad Rzeszutek Wilk
2011-03-22 15:10         ` Michel Dänzer

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=20110128150310.GA29440@dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=airlied@linux.ie \
    --cc=alexdeucher@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=j.glisse@gmail.com \
    --cc=jglisse@redhat.com \
    --cc=konrad@darnok.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=thomas@shipmail.org \
    /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.