public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jerome Glisse <j.glisse@gmail.com>
Cc: linux-kernel@vger.kernel.org, thellstrom@vmware.com,
	thomas@shipmail.org, airlied@redhat.com, jglisse@redhat.com,
	bskeggs@redhat.com, xen-devel@lists.xensource.com
Subject: Re: [PATCH] TTM DMA pool v2.2 or [GIT PULL] (stable/ttm.dma_pool.v2.3) for 3.3
Date: Fri, 4 Nov 2011 14:44:53 -0400	[thread overview]
Message-ID: <20111104184453.GB1616@phenom.dumpdata.com> (raw)
In-Reply-To: <20111104183110.GC2015@homer.localdomain>

> > git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/ttm.dma_pool.v2.3
> > 
> 
> On what hw did you tested ? With and without xen ? Here radeon

On AMD and Intel. And with both Nvidia and Radeon cards.
64-bit cards (I have a patch where I forced the 64-bit card to use
the TTM DMA pool code to test) and 32-bit cards (ATI ES1000)

On baremetal and Xen. Um, Fedora Core 16 as distro.

Oh, and I also tried PPC (Power Mac 4) but could not get it to boot
the 3.1 kernel. Something with the LILO grub loader did not work.

> that doesn't need dma32 doesn't work when forcing swiotlb which
> kind of expected i guess. Should we expose if swiotlb is enabled

You did 'swiotlb=force' ?
> forced so we use dma pool in such case ?

Hm, it shoudl have enabled itself. The swiotlb_nr_tlb would return some
contents and we would.. Oh, you mean you did a 64-bit card _and_
did swiotlb=force. And since the rdev->dma32 was set to zero it
did _not_ use the TTM DMA pool.

Right. I did not do it initially just so that I could limit the scope
in case I messed up something in the code. But the code has the
'no_dma' parameter, so it can easily turn off the DMA TTM code.

So, to answer your question - sure, we can ignore the rdev_dma32 and
just use the the swiotlb_nr_tlb to check.

BTW, thank you for taking a spin with these patches and rebasing them
on top of yours. I am going to start testing them and reviewing the
latest batch you sent on Monday.

  reply	other threads:[~2011-11-04 18:45 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-01 18:47 [PATCH] TTM DMA pool v2.2 or [GIT PULL] (stable/ttm.dma_pool.v2.3) for 3.3 Konrad Rzeszutek Wilk
2011-11-01 18:47 ` [PATCH 01/11] swiotlb: Expose swiotlb_nr_tlb function to modules Konrad Rzeszutek Wilk
2011-11-01 18:47 ` [PATCH 02/11] nouveau/radeon: Set coherent DMA mask Konrad Rzeszutek Wilk
2011-11-01 18:47 ` [PATCH 03/11] ttm/radeon/nouveau: Check the DMA address from TTM against known value Konrad Rzeszutek Wilk
2011-11-01 18:47 ` [PATCH 04/11] ttm: Wrap ttm_[put|get]_pages and extract GFP_* and caching states from 'struct ttm_tt' Konrad Rzeszutek Wilk
2011-11-01 18:47 ` [PATCH 05/11] ttm: Get rid of temporary scaffolding Konrad Rzeszutek Wilk
2011-11-01 18:47 ` [PATCH 06/11] ttm/driver: Expand ttm_backend_func to include two overrides for TTM page pool Konrad Rzeszutek Wilk
2011-11-01 18:47 ` [PATCH 07/11] ttm: Do not set the ttm->be to NULL before calling the TTM page pool to free pages Konrad Rzeszutek Wilk
2011-11-01 18:47 ` [PATCH 08/11] ttm: Provide DMA aware TTM page pool code Konrad Rzeszutek Wilk
2011-11-01 18:47 ` [PATCH 09/11] ttm: Add 'no_dma' parameter to turn the TTM DMA pool off during runtime Konrad Rzeszutek Wilk
2011-11-01 18:47 ` [PATCH 10/11] nouveau/ttm/dma: Enable the TTM DMA pool if device can only do 32-bit DMA Konrad Rzeszutek Wilk
2011-11-01 18:47 ` [PATCH 11/11] radeon/ttm/dma: Enable the TTM DMA pool if the device can only do 32-bit Konrad Rzeszutek Wilk
2011-11-04 18:31 ` [PATCH] TTM DMA pool v2.2 or [GIT PULL] (stable/ttm.dma_pool.v2.3) for 3.3 Jerome Glisse
2011-11-04 18:44   ` Konrad Rzeszutek Wilk [this message]
2011-11-04 19:24     ` Jerome Glisse
2011-11-04 19:41       ` Konrad Rzeszutek Wilk
2011-11-04 20:54         ` Jerome Glisse
2011-11-04 21:08           ` Konrad Rzeszutek Wilk

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=20111104184453.GB1616@phenom.dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=airlied@redhat.com \
    --cc=bskeggs@redhat.com \
    --cc=j.glisse@gmail.com \
    --cc=jglisse@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=thellstrom@vmware.com \
    --cc=thomas@shipmail.org \
    --cc=xen-devel@lists.xensource.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox