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.
WARNING: multiple messages have this Message-ID (diff)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jerome Glisse <j.glisse@gmail.com>
Cc: thellstrom@vmware.com, xen-devel@lists.xensource.com,
thomas@shipmail.org, linux-kernel@vger.kernel.org,
jglisse@redhat.com, bskeggs@redhat.com, airlied@redhat.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.
next prev parent reply other threads:[~2011-11-04 18:45 UTC|newest]
Thread overview: 20+ 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 18:44 ` Konrad Rzeszutek Wilk
2011-11-04 19:24 ` Jerome Glisse
2011-11-04 19:41 ` Konrad Rzeszutek Wilk
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 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.