As a mechanism to detect whether SWIOTLB is enabled or not.
And as such, we might as well wrap it within an 'swiotlb_enabled()'
function that will call the swiotlb_nr_tlb.
We also fix the spelling - it was swioltb instead of
swiotlb.
CC: FUJITA Tomonori
Signed-off-by: Konrad Rzes
On Thu, Aug 25, 2011 at 05:28:09PM +0200, Michel Dänzer wrote:
> On Mit, 2011-08-24 at 13:16 -0400, Konrad Rzeszutek Wilk wrote:
> >
> > My PowerPC has issues with booting a virgin 3.0 kernel (something about
> > "ELF image not correct") so I don't have
> > + entry->vaddr = dma_alloc_writecombine(dev->dev, entry->size,
> > + (dma_addr_t *)&entry->paddr, GFP_KERNEL);
> > + if (!entry->paddr) {
> > + DRM_ERROR("failed to allocate buffer.\n");
> > + return -ENOMEM;
> > + }
> > +
> >
t use pci_dma_mapping_error as that is IOMMU
specific (some check for a specific physical address, some
for ranges, some just do a check against zero).
Also update the comments in the header about the true state
of that parameter.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/no
Since v1: [http://lwn.net/Articles/456246/]
- Ran it through the gauntlet of SubmitChecklist and fixed issues
- Made radeon/nouveau driver set coherent_dma (which is required for dmapool)
[.. and this is what I said in v1 post]:
Way back in January this patchset:
http://lists.freedesktop.org/ar
ode).
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_memory.c |3 ++
drivers/gpu/drm/ttm/ttm_page_alloc.c | 58
include/drm/ttm/ttm_page_alloc.h | 60 ++
3 files changed, 113 insertions(+), 8 deleti
We want to pass in the 'struct device' to the TTM layer so that
the TTM DMA pool code (if enabled) can use it. The DMA API code
needs the 'struct device' to do the DMA API operations.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/nouveau/nouveau_mem.c |3
As a mechanism to detect whether SWIOTLB is enabled or not.
And as such, we might as well wrap it within an 'swiotlb_enabled()'
function that will call the swiotlb_nr_tlb.
We also fix the spelling - it was swioltb instead of
swiotlb.
CC: FUJITA Tomonori
Signed-off-by: Konrad Rzes
The TTM DMA only gets turned on when the SWIOTLB is enabled - but
we might also want to turn it off when SWIOTLB is on to
use the non-DMA TTM pool code.
In the future this parameter can be removed.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |4
All the storage devices that use the dmapool set the coherent DMA
mask so they can properly use the dmapool. Since the TTM DMA pool
code is based on that and dma_alloc_coherent checks the
'coherent_dma_mask' and not 'dma_mask' we want to set it.
Signed-off-by: Konrad Rzeszute
On Wed, Aug 31, 2011 at 09:33:29AM +0300, Pekka Paalanen wrote:
> On Tue, 30 Aug 2011 22:41:46 -0400
> Konrad Rzeszutek Wilk wrote:
>
> > . instead of checking against the DMA_ERROR_CODE value which is
> > per-platform specific. The zero value is a known invalid value
> &
On Wed, Aug 31, 2011 at 09:42:51AM +0200, Thomas Hellstrom wrote:
> Signed-off-by: Thomas Hellstrom
> Reviewed-by: José Fonseca
> ---
> drivers/gpu/drm/vmwgfx/svga_reg.h | 96
> ++-
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |4 ++
> 2 files changed, 99 insert
On Wed, Aug 31, 2011 at 09:42:55AM +0200, Thomas Hellstrom wrote:
> Guest Memory Regions 2 is a way to bind pages to the GPU, but using
> the FIFO instead of an io-submitted descriptor chain.
>
> Signed-off-by: Thomas Hellstrom
> Reviewed-by: Jakob Bornecantz
> ---
> drivers/gpu/drm/vmwgfx/vmwg
ode).
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_memory.c |3 ++
drivers/gpu/drm/ttm/ttm_page_alloc.c | 58
include/drm/ttm/ttm_page_alloc.h | 60 ++
3 files changed, 113 insertions(+), 8 deleti
Since v1.7: [https://lkml.org/lkml/2011/8/30/460]
- Fixed checking the DMA address in radeon/nouveau code.
Since v1: [http://lwn.net/Articles/456246/]
- Ran it through the gauntlet of SubmitChecklist and fixed issues
- Made radeon/nouveau driver set coherent_dma (which is required for dmapool)
We want to pass in the 'struct device' to the TTM layer so that
the TTM DMA pool code (if enabled) can use it. The DMA API code
needs the 'struct device' to do the DMA API operations.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/nouveau/nouveau_mem.c |3
All the storage devices that use the dmapool set the coherent DMA
mask so they can properly use the dmapool. Since the TTM DMA pool
code is based on that and dma_alloc_coherent checks the
'coherent_dma_mask' and not 'dma_mask' we want to set it.
Signed-off-by: Konrad Rzeszute
The TTM DMA only gets turned on when the SWIOTLB is enabled - but
we might also want to turn it off when SWIOTLB is on to
use the non-DMA TTM pool code.
In the future this parameter can be removed.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |4
As a mechanism to detect whether SWIOTLB is enabled or not.
And as such, we might as well wrap it within an 'swiotlb_enabled()'
function that will call the swiotlb_nr_tlb.
We also fix the spelling - it was swioltb instead of
swiotlb.
CC: FUJITA Tomonori
Signed-off-by: Konrad Rzes
t use pci_dma_mapping_error as that is IOMMU
specific (some check for a specific physical address, some
for ranges, some just do a check against zero).
Also update the comments in the header about the true state
of that parameter.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/no
On Thu, Sep 15, 2011 at 08:21:00PM +0200, Michel Dänzer wrote:
> From: Michel Dänzer
>
> This was only the case if the GPU reset was triggered from the CS ioctl,
> otherwise other processes could happily enter the CS ioctl and wreak havoc
> during the GPU reset.
>
> This is a little complicated
On Fri, Sep 16, 2011 at 10:40:23AM +0200, Michel Dänzer wrote:
> On Fre, 2011-09-16 at 04:31 -0400, Konrad Rzeszutek Wilk wrote:
> > On Thu, Sep 15, 2011 at 08:21:00PM +0200, Michel Dänzer wrote:
> > > From: Michel Dänzer
> > >
> > > This was only the case
On Sat, Sep 17, 2011 at 04:05:58AM +0900, FUJITA Tomonori wrote:
> On Tue, 13 Sep 2011 10:12:47 -0400
> Konrad Rzeszutek Wilk wrote:
>
> > As a mechanism to detect whether SWIOTLB is enabled or not.
> > And as such, we might as well wrap it within an 'swiotlb_enabled
> > > > > + DRM_ERROR("desired size is bigger then real
> size.\n");
> > > >
> > > > So .. you can't continue by just using the real size instead?
> > > >
> > >
> > > I am afraid I don't understand what you mean but I think that condition
> > is
> > > fine. size is a vm area to user-des
onfig
(ecb4aed78dcf09e48c8c34c8c2fa7f5c69344be6) but this one is lacking.
Acked-by: Konrad Rzeszutek Wilk
- Forwarded message from Bruce Edge -
Date: Sun, 7 Nov 2010 17:56:38 -0800
From: Bruce Edge
To: xen-de...@lists.xensource.com,
Konrad Rzeszutek Wilk
Subject: PATCH: pvops 2.6.36 patch for unde
On Mon, Nov 08, 2010 at 10:51:10AM -0500, Konrad Rzeszutek Wilk wrote:
> Hey guys,
>
> This failure also occurs on v2.6.37-rc1 (the branch Bruce is
> referring has been merged in Linus's tree). This compile
> failure can be demonstrated if one does not
> select VIDEO_OUT
> > The errors
> >
> > [3.778476] [drm:r100_ring_test] *ERROR* radeon: ring test failed
> > (sracth(0x15E4)=0xCAFEDEAD)
> > [3.781010] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).
> > [3.782542] radeon :00:04.0: failled initializing CP (-22).
> > [3.784006] radeon
We only use the "if (pool == NULL)" path for right now.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 26 +++---
1 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/g
This is right now limited to only non-pool constructs.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc.c |9 ++---
drivers/gpu/drm/ttm/ttm_tt.c | 10 --
include/drm/ttm/ttm_bo_driver.h |2 ++
include/drm/ttm/ttm_page_alloc.h
_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.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/radeon/radeon.h |4 ++-
drivers/gpu/drm/radeon/radeon_gar
hys do not give use the DMA (bus) address).
Since we are using the DMA API on those pages, we should pass in the
DMA address to this function so it can save it in its proper fields
(later patches use it).
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/nouveau/nouveau_sgdma.c |3 ++
uct device' or 'struct pci_device'
but figured it would make first sense to get your guys input before heading
that route.
This patch-set is also available at:
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
devel/ttm.pci-api.v3
Konrad Rzeszutek Wilk (5):
ttm
_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.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/nouveau/nouveau_sgdma.c | 28 +---
1 files c
On Fri, Jan 07, 2011 at 05:47:59PM +, Prasad Joshi wrote:
> 2011/1/7 Konrad Rzeszutek Wilk :
> >> > The errors
> >> >
> >> > [ 3.778476] [drm:r100_ring_test] *ERROR* radeon: ring test failed
> >> > (sracth(0x15E4)=0xCAFEDEAD)
> >>
On Mon, Jan 10, 2011 at 03:25:55PM +0100, Thomas Hellstrom wrote:
> Konrad,
>
> Before looking further into the patch series, I need to make sure
> I've completely understood the problem and why you've chosen this
> solution: Please see inline.
Of course.
.. snip ..
> >The problem above can be e
. snip ..
> >>2) What about accounting? In a *non-Xen* environment, will the
> >>number of coherent pages be less than the number of DMA32 pages, or
> >>will dma_alloc_coherent just translate into a alloc_page(GFP_DMA32)?
> >The code in the IOMMUs end up calling __get_free_pages, which ends up
> >i
> Tried your patches on Guest machine, it did not help. I am attaching
> the messages from guest machine.
Ok, then the issue is not with the guest but the IOMMU.
>
> > well, what is the DMA code that gets turned on when you run your guest?
>
> Looking into the qemu-kvm code to find more informat
> AMD chipset.
They don't seem to have have any errata's for this GFX business.
But they do have a passthrough mode - hopefull that is not what you have
passed in?
> > Since you mentioned that you were able to passthrough other PCI devices
> > that means the IOMMU is working. This narrows it down
. snip ..
> >>>I think the error path would be the same in both cases?
> >>Not really. The really dangerous situation is if TTM is allowed to
> >>exhaust all GFP_KERNEL memory. Then any application or kernel task
> >Ok, since GFP_KERNEL does not contain the GFP_DMA32 flag then
> >this should be OK?
> >> Another thing that I was thinking of is what happens if you have a
> >> huge gart and allocate a lot of coherent memory. Could that
> >> potentially exhaust IOMMU resources?
> >
> >
> >
> > So the GART is in the PCI space in one of the BARs of the device right?
> > (We are talking about the d
> > What motherboard is this?
>
> ASUS M4A89TD Pro/USB3, it is mentioned on the link
> http://wiki.xensource.com/xenwiki/VTdHowTo
I am not sure how the implementation of the IOMMU
in the Xen hypervisor is different from the Linux implementation.
Usually it is lock-step, but it might be different.
On Tue, Jan 11, 2011 at 01:12:57PM -0500, Alex Deucher wrote:
> On Tue, Jan 11, 2011 at 11:59 AM, Konrad Rzeszutek Wilk
> wrote:
> >> >> Another thing that I was thinking of is what happens if you have a
> >> >> huge gart and allocate a lot of coherent me
On Wed, Jan 12, 2011 at 10:12:14AM +0100, Thomas Hellstrom wrote:
> Hi, Konrad.
>
> This discussion has become a bit lenghty. I'll filter out the
> sorted-out stuff, which leaves me with two remaining issues:
>
>
> On 01/11/2011 04:55 PM, Konrad Rzeszutek Wilk wrot
On Wed, Jan 12, 2011 at 10:19:39AM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 12, 2011 at 10:12:14AM +0100, Thomas Hellstrom wrote:
> > Hi, Konrad.
> >
> > This discussion has become a bit lenghty. I'll filter out the
> > sorted-out stuff, which lea
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
> whe
On Fri, Jan 07, 2011 at 12:11:44PM -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
> whe
On Thu, Jan 27, 2011 at 10:28:45AM +0100, Thomas Hellstrom wrote:
> Konrad, Dave
>
> Given our previous discussion on the list, I believe these patches
> shouldn't introduce any regressions in the non-Xen case, however we
> should probably be prepared to back them out quickly if that turns
> out t
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
> 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
>
> Code looks good but GART stuff can be picky, i will try to do a full
> scale testing in next couple week.
ping?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
x27;t see this anymore.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/radeon/radeon_gart.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index 6501611..dc04c7b 100644
--- a/driver
I found this when I was doing a bit of testing of my TTM patches. The issue is
that during unload/unbind:
echo :01:05.0 > /sys/bus/pci/drivers/radeon/unbind
the radeon driver would unload, but if compiled with the CONFIG_DMA_API_DEBUG=y
it would throw out this warning:
[ 22.113420] drm: un
On Thu, Feb 24, 2011 at 03:25:43AM -0500, Alex Deucher wrote:
> On Wed, Feb 23, 2011 at 3:48 PM, Konrad Rzeszutek Wilk
> wrote:
> > git commit 82568565683b4991964a5fc89a9ca0c7122818e8 adds a dummy page
> > so that if something goes wrong it will at least fetch/write data
using the DMA
API."
and moves the mechanism of passing in 'struct device' to the TTM API.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/nouveau/nouveau_mem.c |4 ++--
drivers/gpu/drm/radeon/radeon_ttm.c |4 ++--
drivers/gpu/drm/ttm/ttm_bo.c |4 +
e struct ttm_bo_device and use that. However,
when 'ttm_tt_destroy' is called it sets ttm->be (which contains
the 'struct ttm_bo_device') to NULL so we cannot use it. Hence
we copy the 'struct device' pointer to the 'struct ttm_tm' and keep
it there.
[v2: A
would fallback to that?). Ended up calling 'unbind' on the
/sys/pci/.../$BDF/driver/[radeon,nouveau] to trigger the de-allocation path.
Thomas,
What is the best way to test vmw-gfx*? Does the Workstation (5?) support
this particular frontend?
Konrad Rzeszutek Wilk (2):
ttm: Incl
ages and copy all
> the data.
Makes sense.
>
> /Thomas
>
>
> On 03/08/2011 04:39 PM, Konrad Rzeszutek Wilk wrote:
> >These two patches are not strictly required but they do a bit of
> >cleanup and also fix a false reporting issue when the kernel is compiled
&g
On Mon, Mar 21, 2011 at 02:11:07PM +0100, Michel Dänzer wrote:
> On Fre, 2011-01-07 at 12:11 -0500, Konrad Rzeszutek Wilk wrote:
> >
> > 1) The 'NULL' when doing dma_alloc_coherent is unsightly. I was toying
> > with modifying the TTM API to pass in 'struct de
On Tue, Mar 08, 2011 at 09:52:54PM +0100, Thomas Hellstrom wrote:
> Hi, Konrad,
>
> Is passing a struct device to the DMA api really *strictly* necessary?
Soo.. it seems it is on PowerPC, which I sadly didn't check for, does require
this.
>
> I'd like to avoid that at all cost, since we don't wa
On Tue, Mar 22, 2011 at 02:13:19PM +0100, Michel Dänzer wrote:
> On Mon, 2011-03-21 at 19:18 -0400, Konrad Rzeszutek Wilk wrote:
> > On Mon, Mar 21, 2011 at 02:11:07PM +0100, Michel Dänzer wrote:
> > > On Fre, 2011-01-07 at 12:11 -0500, Konrad Rzeszutek Wilk wrote:
> > &
> >I was thinking about this a bit after I found that the PowerPC requires
> >the 'struct dev'. But I got a question first, what do you with pages
> >that were allocated to a device that can do 64-bit DMA and then
> >move it to a device than can 32-bit DMA? Obviously the 32-bit card would
> >set th
On Wed, Mar 23, 2011 at 02:17:18PM +0100, Thomas Hellstrom wrote:
> On 03/23/2011 01:51 PM, Konrad Rzeszutek Wilk wrote:
> >>>I was thinking about this a bit after I found that the PowerPC requires
> >>>the 'struct dev'. But I got a question first, what do yo
On Thu, Mar 24, 2011 at 08:52:20AM +0100, Thomas Hellstrom wrote:
> On 03/23/2011 03:52 PM, Konrad Rzeszutek Wilk wrote:
> >On Wed, Mar 23, 2011 at 02:17:18PM +0100, Thomas Hellstrom wrote:
> >>On 03/23/2011 01:51 PM, Konrad Rzeszutek Wilk wrote:
> >>>>>I w
> > When a page in the TTM pool is being moved back and forth and also changes
> > the caching model, what happens on the free part? Is the original caching
> > state put back on it? Say I allocated a DMA32 page (GFP_DMA32), and move it
> > to another pool for another radeon device. I also do some
On Sun, Jun 27, 2010 at 12:58:07AM -0400, Matt Turner wrote:
> On Sun, Jun 27, 2010 at 12:20 AM, FUJITA Tomonori
> wrote:
> > On Thu, 24 Jun 2010 10:53:52 -0400
> > Matt Turner wrote:
> >
> >> > Seems that the IOMMU can't find 128 pages. It's likely due to:
> >> >
> >> > - out of the IOMMU space
On Tue, Nov 22, 2011 at 08:54:12AM -0500, Konrad Rzeszutek Wilk wrote:
> > Subject: Regression in 3.1 causes Xen to use wrong idle routine
> > Submitter : Stefan Bader
> > Date : 2011-10-26 10:24
> > Message-ID : 4EA7DFD1.9060608 at canonical.com
> > Re
ch is trapped in the hypervisor,
and then follow it up with a yield hypercall. Meaning we end up
going to hypervisor twice instead of just once.
Lets make pm_idle be default_idle to take care of that.
Reported-by: Stefan Bader
Signed-off-by: Konrad Rzeszutek Wilk
---
arch/x86/include/asm/sys
On Tue, Nov 29, 2011 at 07:34:28PM +0100, Borislav Petkov wrote:
> On Tue, Nov 29, 2011 at 01:04:14PM -0500, Konrad Rzeszutek Wilk wrote:
> > This patch:
> >
> > commit d91ee5863b71e8c90eaf6035bff3078a85e2e7b5
> > Author: Len Brown
> > Date: Fri Apr 1 18:28:3
On Tue, Nov 29, 2011 at 07:34:28PM +0100, Borislav Petkov wrote:
> On Tue, Nov 29, 2011 at 01:04:14PM -0500, Konrad Rzeszutek Wilk wrote:
> > This patch:
Borislav,
Thanks for your review comments. How does this patch look? I believe
I touched upon all of the things you mentioned.
avior before v3.0 was that pm_idle was set
to default_idle irregardless of select_idle_routine/idle_setup.
We want to do that, but only for one specific case: Xen.
This patch does that.
Fixes RH BZ #739499 and Ubuntu #881076
Reported-by: Stefan Bader
Signed-off-by: Konrad Rzeszutek Wilk
---
arc
ends on DRM_SAMSUNG
> + help
> + Choose this option if you want to use Samsung FIMD for DRM.
> + If M is selected, the module will be called samsung_drm_fimd
.. which is just nitpicking and optional so. I took a look at the code and
you can stick 'Reviewed-by: Konrad Rzeszutek Wilk '
if you want to.
On Mon, Oct 03, 2011 at 06:35:42PM +0200, Thomas Hellstrom wrote:
> On 09/30/2011 04:09 PM, Konrad Rzeszutek Wilk wrote:
> >On Fri, Sep 30, 2011 at 08:59:52AM +0200, Thomas Hellstrom wrote:
> >>Konrad,
> >>
> >>I'm really sorry for taking so long to re
On Fri, Sep 30, 2011 at 06:43:16PM +0900, Inki Dae wrote:
> I am sorry for missed title.
Hey Dave,
I took a look at the driver with memory/DMA in mind and it looks
good to me.
>
>
>
> From: Inki Dae [mailto:inki.dae at samsung.com]
> Sent: Friday, September 30, 2011 6:39 PM
> To: 'airlied at
On Mon, Oct 03, 2011 at 03:12:17AM +0200, Jakob Bornecrantz wrote:
> On Thu, Sep 29, 2011 at 11:50 PM, Konrad Rzeszutek Wilk
> wrote:
> > On Wed, Sep 28, 2011 at 04:10:06PM +0200, Thomas Hellstrom wrote:
> >> From: Jakob Bornecrantz
> >>
> >> Mor
On Mon, Oct 03, 2011 at 03:18:32AM +0200, Jakob Bornecrantz wrote:
> On Thu, Sep 29, 2011 at 11:42 PM, Konrad Rzeszutek Wilk
> wrote:
> > On Wed, Sep 28, 2011 at 04:10:01PM +0200, Thomas Hellstrom wrote:
> >> From: Jakob Bornecrantz
> >>
> >> Signed-off-
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/nouveau/nouveau_debugfs.c |1 +
drivers/gpu/drm/nouveau/nouveau_sgdma.c |5 +
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
b/drivers/gpu/drm/nouveau/nouveau_debug
__ttm_put_pages,
which later on we will remove (by moving the __ttm_put_pages).
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 29 +++--
drivers/gpu/drm/ttm/ttm_tt.c |6 ++
include/drm/ttm/ttm_page_alloc.h | 16 +
The TTM DMA only gets turned on when the SWIOTLB is enabled - but
we might also want to turn it off when SWIOTLB is on to
use the non-DMA TTM pool code.
In the future this parameter can be removed.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_memory.c |7
t use pci_dma_mapping_error as that is IOMMU
specific (some check for a specific physical address, some
for ranges, some just do a check against zero).
Also update the comments in the header about the true state
of that parameter.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/no
troying them).
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_tt.c | 15 +++
1 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 76c982f..31ae359 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b
All the storage devices that use the dmapool set the coherent DMA
mask so they can properly use the dmapool. Since the TTM DMA pool
code is based on that and dma_alloc_coherent checks the
'coherent_dma_mask' and not 'dma_mask' we want to set it.
Signed-off-by: Konrad Rzeszute
The two overrides will be choosen by the backends whether they
want to use a different TTM page pool than the default.
If the backend does not choose a new override, the default one
will be used.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 10
ey work.
Michel (thanks!) took a spin of the patches on his PowerPC and they did not
cause any regressions (wheew).
The patches are also located in a git tree:
git://oss.oracle.com/git/kwilk/xen.git devel/ttm.dma_pool.v2.1
Konrad Rzeszutek Wilk (11):
swiotlb: Expose swiotlb_nr_tlb
D?nzer
[v1: Using swiotlb_nr_tbl instead of swiotlb_enabled]
[v2: Major overhaul - added 'inuse_list' to seperate used from inuse and reorder
the order of lists to get better performance.]
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/Makefile |3 +
driv
which was used in the "ttm: Wrap ttm_[put|get]_pages and
extract GFP_* and caching states from 'struct ttm_tt" patch.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 83 -
1 files changed, 40 insertions(+), 43 del
: Alex Deucher
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/radeon/radeon_ttm.c | 19 +++
1 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 60125dd..2e7419f 100644
--- a/drivers
As a mechanism to detect whether SWIOTLB is enabled or not.
We also fix the spelling - it was swioltb instead of
swiotlb.
CC: FUJITA Tomonori
[v1: Ripped out swiotlb_enabled]
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/xen/swiotlb-xen.c |2 +-
include/linux/swiotlb.h |2 +-
lib
On Wed, Oct 19, 2011 at 06:19:21PM -0400, Konrad Rzeszutek Wilk wrote:
Hmm, seems a part of this got eaten by the Internet monsters.
Since v2.0: [not posted]
- Redid the registration/override to be tightly integrated with the
'struct ttm_backend_func' per Thomas's suggest
On Sat, Oct 22, 2011 at 11:40:54AM +0200, Thomas Hellstrom wrote:
> Konrad,
>
> I was hoping that we could get rid of the dma_address shuffling into
> core TTM,
> like I mentioned in the review. From what I can tell it's now only
> used in the backend and
> core ttm doesn't care about it.
>
> Is
> >For that there are couple of architectural issues I am not sure how to solve.
> >
> >There has to be some form of TTM<->[Radeon|Nouveau] lookup mechanism
> >to say: "here is a 'struct page *', give me the bus address". Currently
> >this is solved by keeping an array of DMA addresses along with t
On Sat, Oct 22, 2011 at 10:29:33AM +0200, Thomas Hellstrom wrote:
> From: Jakob Bornecrantz
>
> Signed-off-by: Jakob Bornecrantz
> Signed-off-by: Thomas Hellstrom
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 10 +-
> 1 files changed, 9 insertions(+), 1 deletions(-)
>
> diff --git a
On Mon, Oct 24, 2011 at 03:01:23PM -0700, Jakob Bornecrantz wrote:
>
> - Original Message -
> > On Sat, Oct 22, 2011 at 10:29:33AM +0200, Thomas Hellstrom wrote:
> > > From: Jakob Bornecrantz
> > >
> > > Signed-off-by: Jakob Bornecrantz
> > > Signed-off-by: Thomas Hellstrom
> > > ---
>
On Wed, Aug 31, 2011 at 09:42:51AM +0200, Thomas Hellstrom wrote:
> Signed-off-by: Thomas Hellstrom
> Reviewed-by: Jos? Fonseca
> ---
> drivers/gpu/drm/vmwgfx/svga_reg.h | 96
> ++-
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |4 ++
> 2 files changed, 99 insert
On Wed, Aug 31, 2011 at 09:42:55AM +0200, Thomas Hellstrom wrote:
> Guest Memory Regions 2 is a way to bind pages to the GPU, but using
> the FIFO instead of an io-submitted descriptor chain.
>
> Signed-off-by: Thomas Hellstrom
> Reviewed-by: Jakob Bornecantz
> ---
> drivers/gpu/drm/vmwgfx/vmwg
ode).
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_memory.c |3 ++
drivers/gpu/drm/ttm/ttm_page_alloc.c | 58
include/drm/ttm/ttm_page_alloc.h | 60 ++
3 files changed, 113 insertions(+), 8 deleti
Since v1.7: [https://lkml.org/lkml/2011/8/30/460]
- Fixed checking the DMA address in radeon/nouveau code.
Since v1: [http://lwn.net/Articles/456246/]
- Ran it through the gauntlet of SubmitChecklist and fixed issues
- Made radeon/nouveau driver set coherent_dma (which is required for dmapool)
We want to pass in the 'struct device' to the TTM layer so that
the TTM DMA pool code (if enabled) can use it. The DMA API code
needs the 'struct device' to do the DMA API operations.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/nouveau/nouveau_mem.c |3
All the storage devices that use the dmapool set the coherent DMA
mask so they can properly use the dmapool. Since the TTM DMA pool
code is based on that and dma_alloc_coherent checks the
'coherent_dma_mask' and not 'dma_mask' we want to set it.
Signed-off-by: Konrad Rzeszute
The TTM DMA only gets turned on when the SWIOTLB is enabled - but
we might also want to turn it off when SWIOTLB is on to
use the non-DMA TTM pool code.
In the future this parameter can be removed.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |4
; then there are the DMA32 variants which are:
write-combined dma32, uncached dma32, and cached dma32.
Currently this code only gets activated when any variant of the SWIOTLB IOMMU
code is running (Intel without VT-d, AMD without GART, IBM Calgary and Xen PV
with PCI devices).
Signed-off-by:
As a mechanism to detect whether SWIOTLB is enabled or not.
And as such, we might as well wrap it within an 'swiotlb_enabled()'
function that will call the swiotlb_nr_tlb.
We also fix the spelling - it was swioltb instead of
swiotlb.
CC: FUJITA Tomonori
Signed-off-by: Konrad Rzes
201 - 300 of 505 matches
Mail list logo
