On Tue, 3 Jun 2025 at 18:50, Christian König wrote:
>
> On 6/3/25 09:52, David Airlie wrote:
> > On Tue, Jun 3, 2025 at 5:47 PM Christian König
> > wrote:
> >>
> >> On 6/2/25 22:40, Dave Airlie wrote:
> >>> From: Dave Airlie
> >>>
> >>> Currently you can't see per-device numa aware pools proper
On 6/3/25 09:52, David Airlie wrote:
> On Tue, Jun 3, 2025 at 5:47 PM Christian König
> wrote:
>>
>> On 6/2/25 22:40, Dave Airlie wrote:
>>> From: Dave Airlie
>>>
>>> Currently you can't see per-device numa aware pools properly.
>>>
>>> Cc: Christian König
>>> Signed-off-by: Dave Airlie
>>
>>
On Tue, Jun 3, 2025 at 5:47 PM Christian König wrote:
>
> On 6/2/25 22:40, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > Currently you can't see per-device numa aware pools properly.
> >
> > Cc: Christian König
> > Signed-off-by: Dave Airlie
>
> Reviewed-by: Christian König
>
> Any follow u
On 6/2/25 22:40, Dave Airlie wrote:
> From: Dave Airlie
>
> Currently you can't see per-device numa aware pools properly.
>
> Cc: Christian König
> Signed-off-by: Dave Airlie
Reviewed-by: Christian König
Any follow up patch to wire this up in amdgpu?
Regards,
Christian.
> ---
> drivers/g
From: Dave Airlie
Currently you can't see per-device numa aware pools properly.
Cc: Christian König
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_pool.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/t
Am 03.03.23 um 11:12 schrieb suijingfeng:
should replace '@' with '*'
Signed-off-by: suijingfeng
I've just reviewed and pushed the patch to drm-misc-next.
Just please use your full (first and last) name for author and
signed-off-by tags in the future.
Thanks,
Christian.
---
include/
should replace '@' with '*'
Signed-off-by: suijingfeng
---
include/drm/ttm/ttm_device.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/ttm/ttm_device.h b/include/drm/ttm/ttm_device.h
index 4f3e81eac6f3..56e82ba2d046 100644
--- a/include/drm/ttm/ttm_device.h
+++
Am 19.03.22 um 08:31 schrieb Xiaomeng Tong:
When list_for_each_entry() completes the iteration over the whole list
without breaking the loop, the iterator value will be a bogus pointer
computed based on the head element.
While it is safe to use the pointer to determine if it was computed
based o
When list_for_each_entry() completes the iteration over the whole list
without breaking the loop, the iterator value will be a bogus pointer
computed based on the head element.
While it is safe to use the pointer to determine if it was computed
based on the head element with &pos->member == head,
Patch looks good to me too.
Reviewed-by: Roland Scheidegger
Seems indeed like we should do some cleanup.
Roland
Am 28.07.20 um 09:37 schrieb Christian König:
> Am 28.07.20 um 05:42 schrieb Dave Airlie:
>> From: Dave Airlie
>>
>> Just drop the argument from this.
>>
>> This does ask the questio
> On Jul 27, 2020, at 11:42 PM, Dave Airlie wrote:
>
> From: Dave Airlie
>
> Just drop the argument from this.
>
> This does ask the question if this is the function vmwgfx
> should be using or should it be doing an evict all like
> the other drivers.
Yea, it really should. This code is real
On Tue, Jul 28, 2020 at 01:42:54PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Just drop the argument from this.
>
> This does ask the question if this is the function vmwgfx
> should be using or should it be doing an evict all like
> the other drivers.
Yeah this looks a bit like ttm_bo_s
Am 28.07.20 um 05:42 schrieb Dave Airlie:
From: Dave Airlie
Just drop the argument from this.
This does ask the question if this is the function vmwgfx
should be using or should it be doing an evict all like
the other drivers.
Signed-off-by: Dave Airlie
Reviewed-by: Christian König
---
From: Dave Airlie
Just drop the argument from this.
This does ask the question if this is the function vmwgfx
should be using or should it be doing an evict all like
the other drivers.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_bo.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv
Quoting Chris Wilson (2019-08-14 19:22:54)
You saw nothing; wrong experimental branch.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
---
drivers/gpu/drm/i915/Makefile | 7 +
drivers/gpu/drm/i915/ttm/Makefile | 5 +
drivers/gpu/drm/i915/ttm/i915_ttm_drv.c | 4 +
drivers/gpu/drm/i915/ttm/i915_ttm_drv.h | 12 ++
drivers/gpu/drm/i915/ttm/i915_ttm_ppgtt.c | 174 ++
drivers/gpu/drm/i
adding a wrapper for pin function as below?
amdgpu_get_pin_bo_timeout()
{
do {
amdgpo_bo_reserve();
r=amdgpu_bo_pin();
if(!r)
break;
amdgpu_bo_unreserve();
timeout--;
} while(timeout>0);
}
Original Message
Subject: Re: [PATCH] ttm: wait mem space if user allow
u_bo_pin();
if(!r)
break;
amdgpu_bo_unreserve();
timeout--;
} while(timeout>0);
}
Original Message
Subject: Re: [PATCH] ttm: wait mem space if user allow while
gpu busy
From: Christian König
To: "Zhou, David(ChunMing)" ,"Koenig, Christian" ,&qu
in ttm has this risk, how about just adding a wrapper for
pin function as below?
amdgpu_get_pin_bo_timeout()
{
do {
amdgpo_bo_reserve();
r=amdgpu_bo_pin();
if(!r)
break;
amdgpu_bo_unreserve();
timeout--;
} while(timeout>0);
}
Original Message
Subject: Re: [PATCH]
ssage --------
Subject: Re: [PATCH] ttm: wait mem space if user allow while gpu busy
From: Christian König
To: "Zhou, David(ChunMing)" ,"Koenig, Christian" ,"Liang, Prike"
,dri-devel@lists.freedesktop.org
CC:
Well that's not so easy of hand.
The basic problem here
erve();
r=amdgpu_bo_pin();
if(!r)
break;
amdgpu_bo_unreserve();
timeout--;
} while(timeout>0);
}
Original Message --------
Subject: Re: [PATCH] ttm: wait mem space if user allow while gpu busy
From: Christian König
To: "Zhou, David(ChunMing)" ,"Koeni
y not trivial, but doable as far as I can see.
>>
>> Have fun :)
>> Christian.
>>
>> Am 23.04.19 um 15:19 schrieb Zhou, David(ChunMing):
>>
>> How about adding more condition ctx->resv inline to address your concern? As
>> well as don't wait from same user, s
fun :)
> Christian.
>
> Am 23.04.19 um 15:19 schrieb Zhou, David(ChunMing):
>
> How about adding more condition ctx->resv inline to address your concern? As
> well as don't wait from same user, shouldn't lead to deadlock.
>
> Otherwise, any other idea?
&g
function as below?
amdgpu_get_pin_bo_timeout()
{
do {
amdgpo_bo_reserve();
r=amdgpu_bo_pin();
if(!r)
break;
amdgpu_bo_unreserve();
timeout--;
} while(timeout>0);
}
Original Message ----
Subject: Re: [PATCH] ttm: wait mem space if user allow while gpu busy
From: Christian K
u_bo_pin();
if(!r)
break;
amdgpu_bo_unreserve();
timeout--;
} while(timeout>0);
}
Original Message ----
Subject: Re: [PATCH] ttm: wait mem space if user allow while gpu busy
From: Christian König
To: "Zhou, David(ChunMing)" ,"Koenig, Christian" ,"L
has this risk, how about just adding a
wrapper for pin function as below?
amdgpu_get_pin_bo_timeout()
{
do {
amdgpo_bo_reserve();
r=amdgpu_bo_pin();
if(!r)
break;
amdgpu_bo_unreserve();
timeout--;
} while(timeout>0);
}
Original Message ----
Subject: Re: [PATCH] ttm: w
timeout--;
} while(timeout>0);
}
Original Message
Subject: Re: [PATCH] ttm: wait mem space if user allow while gpu busy
From: Christian König
To: "Zhou, David(ChunMing)" ,"Koenig, Christian" ,"Liang, Prike"
,dri-devel@lists.freedesktop.org
CC:
We
l Message
Subject: Re: [PATCH] ttm: wait mem space if user allow while gpu busy
From: Christian König
To: "Zhou, David(ChunMing)" ,"Koenig, Christian" ,"Liang, Prike"
,dri-devel@lists.freedesktop.org
CC:
Well that's not so easy of hand.
The basic problem here is t
eb Zhou, David(ChunMing):
How about adding more condition ctx->resv inline to address your
concern? As well as don't wait from same user, shouldn't lead to deadlock.
Otherwise, any other idea?
Original Message
Subject: Re: [PATCH] ttm: wait mem space if user allow
How about adding more condition ctx->resv inline to address your concern? As
well as don't wait from same user, shouldn't lead to deadlock.
Otherwise, any other idea?
Original Message
Subject: Re: [PATCH] ttm: wait mem space if user allow while gpu busy
From: Ch
Sent: Monday, April 22, 2019 6:39 PM
To: dri-devel@lists.freedesktop.org
Cc: Liang, Prike ; Zhou, David(ChunMing)
Subject: [PATCH] ttm: wait mem space if user allow while gpu busy
heavy gpu job could occupy memory long time, which could lead to other user
fail to get memory.
Chan
Acked-by: Prike Liang
Thanks,
Prike
-Original Message-
From: Chunming Zhou
Sent: Monday, April 22, 2019 6:39 PM
To: dri-devel@lists.freedesktop.org
Cc: Liang, Prike ; Zhou, David(ChunMing)
Subject: [PATCH] ttm: wait mem space if user allow while gpu busy
heavy gpu job could occupy
heavy gpu job could occupy memory long time, which could lead to other
user fail to get memory.
Change-Id: I0b322d98cd76e5ac32b00462bbae8008d76c5e11
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/ttm/ttm_bo.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu
On 11.12.2015 14:37, Julia Lawall wrote:
> The ttm_backend_func structures are never modified, so declare them as
> const.
>
> Done with the help of Coccinelle.
>
> Signed-off-by: Julia Lawall
Reviewed-by: Christian König
>
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |2 +-
> driver
The ttm_backend_func structures are never modified, so declare them as
const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |2 +-
drivers/gpu/drm/ast/ast_ttm.c |2 +-
drivers/gpu/drm/bochs/bochs_mm.c|2 +
On Sunday, June 15, 2014 9:11 AM, Martin Kepplinger wrote:
>
> Fix a sparse warning: ttm_bo_reserve()'s last argument is a
> pointer to a struct, so use NULL as nullpointer.
>
> Signed-off-by: Martin Kepplinger
Reviewed-by: Jingoo Han
Best regards,
Jingoo Han
> ---
> this applies to next-201
Fix a sparse warning: ttm_bo_reserve()'s last argument is a
pointer to a struct, so use NULL as nullpointer.
Signed-off-by: Martin Kepplinger
---
this applies to next-20140613. Please ignore if annoyingly irrelevant.
drivers/gpu/drm/ttm/ttm_bo.c | 14 +++---
1 file changed, 7 insertio
if we have a move notify callback, when moving fails, we call move notify
the opposite way around, however this ends up with *mem containing the mm_node
from the bo, which means we double free it. This is a follow on to the previous
fix.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_bo.
When we are using memcpy to move objects around, and we fail to memcpy
due to lack of memory to populate or failure to finish the copy, we don't
want to destroy the mm_node that has been copied into old_copy.
While working on a new kms driver that uses memcpy, if I overallocated bo's
up to the mem
On Wed, Jan 16, 2013 at 1:01 AM, Dave Airlie wrote:
> if we have a move notify callback, when moving fails, we call move notify
> the opposite way around, however this ends up with *mem containing the mm_node
> from the bo, which means we double free it. This is a follow on to the
> previous
> fi
On Tue, Jan 15, 2013 at 11:28 PM, Dave Airlie wrote:
> When we are using memcpy to move objects around, and we fail to memcpy
> due to lack of memory to populate or failure to finish the copy, we don't
> want to destroy the mm_node that has been copied into old_copy.
>
> While working on a new kms
On Wed, Jan 16, 2013 at 1:01 AM, Dave Airlie wrote:
> if we have a move notify callback, when moving fails, we call move notify
> the opposite way around, however this ends up with *mem containing the mm_node
> from the bo, which means we double free it. This is a follow on to the
> previous
> fi
On Tue, Jan 15, 2013 at 11:28 PM, Dave Airlie wrote:
> When we are using memcpy to move objects around, and we fail to memcpy
> due to lack of memory to populate or failure to finish the copy, we don't
> want to destroy the mm_node that has been copied into old_copy.
>
> While working on a new kms
if we have a move notify callback, when moving fails, we call move notify
the opposite way around, however this ends up with *mem containing the mm_node
from the bo, which means we double free it. This is a follow on to the previous
fix.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_bo.
When we are using memcpy to move objects around, and we fail to memcpy
due to lack of memory to populate or failure to finish the copy, we don't
want to destroy the mm_node that has been copied into old_copy.
While working on a new kms driver that uses memcpy, if I overallocated bo's
up to the mem
On Thu, Jan 12, 2012 at 11:50:26AM -0500, Konrad Rzeszutek Wilk wrote:
> . It was useful during development, but now on a production system
> we can get this (if the user forgot to upload the firmware):
>
> [drm] radeon: irq initialized.
> [drm] GART: num cpu pages 131072, num gpu pages 131072
> [
On Thu, Jan 12, 2012 at 11:50:26AM -0500, Konrad Rzeszutek Wilk wrote:
> . It was useful during development, but now on a production system
> we can get this (if the user forgot to upload the firmware):
>
> [drm] radeon: irq initialized.
> [drm] GART: num cpu pages 131072, num gpu pages 131072
> [
. It was useful during development, but now on a production system
we can get this (if the user forgot to upload the firmware):
[drm] radeon: irq initialized.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] radeon: ib pool ready.
[drm] Loading SUMO Microcode
r600_cp: Failed to load fi
. It was useful during development, but now on a production system
we can get this (if the user forgot to upload the firmware):
[drm] radeon: irq initialized.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] radeon: ib pool ready.
[drm] Loading SUMO Microcode
r600_cp: Failed to load fi
---
drivers/gpu/drm/nouveau/nouveau_bo.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 724b41a..326b64a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nou
ttm tt rework modified the way we allocate and populate the
ttm_tt structure, the AGP side was missing some bit to properly
work. Fix those and fix radeon and nouveau AGP support.
Tested on radeon only so far.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 13 +++
On Wed, Oct 19, 2011 at 06:19:21PM -0400, Konrad Rzeszutek Wilk wrote:
> [.. and this is what I said in v1 post]:
>
> Way back in January this patchset:
> http://lists.freedesktop.org/archives/dri-devel/2011-January/006905.html
> was merged in, but pieces of it had to be reverted b/c they did not
On Wed, Oct 19, 2011 at 06:19:21PM -0400, Konrad Rzeszutek Wilk wrote:
> [.. and this is what I said in v1 post]:
>
> Way back in January this patchset:
> http://lists.freedesktop.org/archives/dri-devel/2011-January/006905.html
> was merged in, but pieces of it had to be reverted b/c they did not
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 suggestion.
Since v1.9: [not
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 suggestion.
Since v1.9: [not
[.. and this is what I said in v1 post]:
Way back in January this patchset:
http://lists.freedesktop.org/archives/dri-devel/2011-January/006905.html
was merged in, but pieces of it had to be reverted b/c they did not
work properly under PowerPC, ARM, and when swapping out pages to disk.
After a b
[.. and this is what I said in v1 post]:
Way back in January this patchset:
http://lists.freedesktop.org/archives/dri-devel/2011-January/006905.html
was merged in, but pieces of it had to be reverted b/c they did not
work properly under PowerPC, ARM, and when swapping out pages to disk.
After a b
On 10/03/2011 06:46 PM, Konrad Rzeszutek Wilk wrote:
>
> It does now (I had a spinlock mishap).. which reminds me - how
> do I test these patches with your vmwgfx driver? I've an old version
> of VMWare Workstation 8, would that do?
>
VMware workstation 8 is OK (it's actually the latest versio
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 review this.
>>
> That is OK. We all are busy - and it gave me some time to pretty
> up the code even more.
>
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 review this.
> >That is OK. We all are busy - and
On 10/03/2011 06:46 PM, Konrad Rzeszutek Wilk wrote:
It does now (I had a spinlock mishap).. which reminds me - how
do I test these patches with your vmwgfx driver? I've an old version
of VMWare Workstation 8, would that do?
VMware workstation 8 is OK (it's actually the latest version of
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 review this.
> >That is OK. We all are busy - and
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 review this.
That is OK. We all are busy - and it gave me some time to pretty
up the code even more.
I'd like to
On Fri, Sep 30, 2011 at 08:59:52AM +0200, Thomas Hellstrom wrote:
> Konrad,
>
> I'm really sorry for taking so long to review this.
That is OK. We all are busy - and it gave me some time to pretty
up the code even more.
>
> I'd like to go through a couple of high-level things first before
> rev
Konrad,
I'm really sorry for taking so long to review this.
I'd like to go through a couple of high-level things first before
reviewing the coding itself.
The page_alloc_func structure looks nice, but I'd like to have it per
ttm backend,
we would just need to make sure that the backend is aliv
On Fri, Sep 30, 2011 at 08:59:52AM +0200, Thomas Hellstrom wrote:
> Konrad,
>
> I'm really sorry for taking so long to review this.
That is OK. We all are busy - and it gave me some time to pretty
up the code even more.
>
> I'd like to go through a couple of high-level things first before
> rev
Konrad,
I'm really sorry for taking so long to review this.
I'd like to go through a couple of high-level things first before
reviewing the coding itself.
The page_alloc_func structure looks nice, but I'd like to have it per
ttm backend,
we would just need to make sure that the backend is al
[.. and this is what I said in v1 post]:
Way back in January this patchset:
http://lists.freedesktop.org/archives/dri-devel/2011-January/006905.html
was merged in, but pieces of it had to be reverted b/c they did not
work properly under PowerPC, ARM, and when swapping out pages to disk.
After a b
[.. and this is what I said in v1 post]:
Way back in January this patchset:
http://lists.freedesktop.org/archives/dri-devel/2011-January/006905.html
was merged in, but pieces of it had to be reverted b/c they did not
work properly under PowerPC, ARM, and when swapping out pages to disk.
After a b
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)
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)
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
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
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 that yet covered.
I tested your patches on my PowerBook with a Radeon.
Tested-by: Michel D?nzer
--
Earthling
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 that yet covered.
>
> I tested your patches
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 that yet covered.
>
> I tested your patches
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 that yet covered.
I tested your patches on my PowerBook with a Radeon.
Tested-by: Michel Dänzer
--
Earthling
Way back in January this patchset:
http://lists.freedesktop.org/archives/dri-devel/2011-January/006905.html
was merged in, but pieces of it had to be reverted b/c they did not
work properly under PowerPC, ARM, and when swapping out pages to disk.
After a bit of discussion on the mailing list
http:
Way back in January this patchset:
http://lists.freedesktop.org/archives/dri-devel/2011-January/006905.html
was merged in, but pieces of it had to be reverted b/c they did not
work properly under PowerPC, ARM, and when swapping out pages to disk.
After a bit of discussion on the mailing list
http:
. and some comments to make it easier to understand.
Ackedby: Randy Dunlap
[v2: Added some more updates from Randy Dunlap]
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 16
include/drm/ttm/ttm_bo_api.h |3 ---
include/drm/ttm/ttm_
.instead increment it by the count of pages that we want to
splice into the pool list.
In other words we were incrementing the pool->npages by the wrong
amount. This bug was observed from code inspection.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc.c |2 +-
1
. and some comments to make it easier to understand.
Ackedby: Randy Dunlap
[v2: Added some more updates from Randy Dunlap]
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 16
include/drm/ttm/ttm_bo_api.h |3 ---
include/drm/ttm/ttm_
.instead increment it by the count of pages that we want to
splice into the pool list.
In other words we were incrementing the pool->npages by the wrong
amount. This bug was observed from code inspection.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc.c |2 +-
1
. and some comments to make it easier to understand.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 14 +++---
include/drm/ttm/ttm_bo_api.h |3 ---
include/drm/ttm/ttm_bo_driver.h |6 +++---
include/drm/ttm/ttm_memory.h |
On Tue, 7 Jun 2011 14:35:52 -0400 Konrad Rzeszutek Wilk wrote:
> . and some comments to make it easier to understand.
>
> Signed-off-by: Konrad Rzeszutek Wilk
> ---
> drivers/gpu/drm/ttm/ttm_page_alloc.c | 14 +++---
> include/drm/ttm/ttm_bo_api.h |3 ---
> include/drm/tt
On Tue, 7 Jun 2011 14:35:52 -0400 Konrad Rzeszutek Wilk wrote:
> . and some comments to make it easier to understand.
>
> Signed-off-by: Konrad Rzeszutek Wilk
> ---
> drivers/gpu/drm/ttm/ttm_page_alloc.c | 14 +++---
> include/drm/ttm/ttm_bo_api.h |3 ---
> include/drm/tt
. and some comments to make it easier to understand.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 14 +++---
include/drm/ttm/ttm_bo_api.h |3 ---
include/drm/ttm/ttm_bo_driver.h |6 +++---
include/drm/ttm/ttm_memory.h |
populuated due to the wrong state
Signed-off-by: Austin Yuan
Signed-off-by: Elaine Wang
---
drivers/gpu/drm/ttm/ttm_tt.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index a7bab87..4ea44c2 100644
--- a/driv
88 matches
Mail list logo
