Hi Christian,
Thanks again for your review.
And for the mask change my understanding is it is to be used for mark different
part of fw (1<<24 is for stack and 2<<24 is for the data).
And more detailed background would need Leo give us.
Best Regards,
Frank
-Original Message-
From: Koenig
to indicate page order for each element in the pool
Change-Id: Ic609925ca5d2a5d4ad49d6becf505388ce3624cf
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 42 ++--
1 file changed, 31 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/ttm
Change-Id: Idf5ccb579d264b343199d8b8344bddeec2c0019f
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 2db551f..fabb082 100644
--- a/d
Change-Id: Ia55b206d95812c5afcfd6cec29f580758d1f50f0
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index fabb082
Change-Id: Id8bd4d1ecff9f3ab14355e2dbd1c59b9fe824e01
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 343db0b..82d40c6 10064
Change-Id: I9fa45af447c3c78d0b7b2b8958081e584c560120
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 82d40c6..53fd8e9 100644
--- a/dr
-Original Message-
From: Koenig, Christian
Sent: Wednesday, November 22, 2017 3:48 PM
To: He, Roger ; amd-gfx@lists.freedesktop.org;
dri-de...@lists.freedesktop.org
Subject: Re: [PATCH 1/4] drm/ttm: add page order in page pool
Am 22.11.2017 um 06:36 schrieb Roger He:
> to indicate page
On 2017-11-21 07:38 PM, Christian König wrote:
> Am 21.11.2017 um 18:29 schrieb Michel Dänzer:
>> From: Michel Dänzer
>>
>> This matches the corresponding UAPI fields. Treating the ring index as
>> signed could result in accessing random unrelated memory if the MSB was
>> set.
>>
>> Fixes: effd924
to indicate page order for each element in the pool
Change-Id: Ic609925ca5d2a5d4ad49d6becf505388ce3624cf
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 38 +---
1 file changed, 27 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/ttm
Change-Id: Idf5ccb579d264b343199d8b8344bddeec2c0019f
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index a02bd65..9b48b93 100644
--- a/d
e.g. shrink reqeust is less than 512, the logic will skip huge pool
Change-Id: Id8bd4d1ecff9f3ab14355e2dbd1c59b9fe824e01
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_
Change-Id: Ia55b206d95812c5afcfd6cec29f580758d1f50f0
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 9b48b93
Change-Id: I9fa45af447c3c78d0b7b2b8958081e584c560120
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index a710d9e..388c5b1 100644
--- a/dr
Am 22.11.2017 um 09:42 schrieb Michel Dänzer:
On 2017-11-21 07:38 PM, Christian König wrote:
Am 21.11.2017 um 18:29 schrieb Michel Dänzer:
From: Michel Dänzer
This matches the corresponding UAPI fields. Treating the ring index as
signed could result in accessing random unrelated memory if the
I would rather completely nuke ttm_pages_put() instead of coming up with
more workarounds here.
Going to provide a cleanup patch to show what I mean, just give me a minute.
Regards,
Christian.
Am 22.11.2017 um 06:36 schrieb Roger He:
Change-Id: Ia55b206d95812c5afcfd6cec29f580758d1f50f0
Signed
Am 22.11.2017 um 10:17 schrieb Roger He:
to indicate page order for each element in the pool
Change-Id: Ic609925ca5d2a5d4ad49d6becf505388ce3624cf
Signed-off-by: Roger He
Reviewed-by: Christian König for this one.
Feel free to commit it preliminary, but I think we still need to work on
the
On 2017-11-22 10:22 AM, Christian König wrote:
> Am 22.11.2017 um 09:42 schrieb Michel Dänzer:
>> On 2017-11-21 07:38 PM, Christian König wrote:
>>> Am 21.11.2017 um 18:29 schrieb Michel Dänzer:
From: Michel Dänzer
This matches the corresponding UAPI fields. Treating the ring index
the patch set looks ok to me, Reviewed-by: Chunming Zhou
On 2017年11月22日 17:17, Roger He wrote:
to indicate page order for each element in the pool
Change-Id: Ic609925ca5d2a5d4ad49d6becf505388ce3624cf
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 38 +++
Hi Christian:
This is old patch, I already send new patches. And it is clean and simple.
Please check that.
Thanks
Roger(Hongbo.He)
-Original Message-
From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com]
Sent: Wednesday, November 22, 2017 5:29 PM
To: He, Roger ; amd-gfx@lis
That completely negates the advantage of setting write back on multiple
pages at once.
In other words this way we wouldn't need the array any more at all and
could remove the whole complicated handling.
I'm pretty close to saying just go ahead with that and even clean up the
whole stuff with
Am 21.11.2017 um 23:26 schrieb Boris Ostrovsky:
On 11/21/2017 08:34 AM, Christian König wrote:
Hi Boris,
attached are two patches.
The first one is a trivial fix for the infinite loop issue, it now
correctly aborts the fixup when it can't find address space for the
root window.
The second is
Hi Christian:
Maybe we can get back the logic for page order 0 in ttm_pages_put.
I mean: handle order 0 with set_pages_array_wb and handle order 9 with
set_pages_wb.
If that, no performance concern.
How about that?
Thanks
Roger(Hongbo.He)
-Original Message-
From: Christian König [mailto
Change-Id: Ia55b206d95812c5afcfd6cec29f580758d1f50f0
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 26 ++
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index
e.g. shrink reqeust is less than 512, the logic will skip huge pool
Change-Id: Id8bd4d1ecff9f3ab14355e2dbd1c59b9fe824e01
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_
Change-Id: Idf5ccb579d264b343199d8b8344bddeec2c0019f
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index a8b2bfa..cdbb731 100644
--- a/d
Quoting Roger He (2017-11-22 11:44:27)
> Change-Id: Idf5ccb579d264b343199d8b8344bddeec2c0019f
> Signed-off-by: Roger He
> ---
> drivers/gpu/drm/ttm/ttm_page_alloc.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
> b/drivers/gpu/drm/ttm
Quoting Roger He (2017-11-22 11:44:29)
> e.g. shrink reqeust is less than 512, the logic will skip huge pool
You should also tell the shrinker that you skipped objects so that it
knows to accumulate the request for the next pass. See
shrinkctl->nr_scanned.
-Chris
__
Am 22.11.2017 um 12:44 schrieb Roger He:
Change-Id: Idf5ccb579d264b343199d8b8344bddeec2c0019f
Signed-off-by: Roger He
Reviewed-by: Christian König for the whole
series.
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu
Am 22.11.2017 um 12:50 schrieb Chris Wilson:
Quoting Roger He (2017-11-22 11:44:27)
Change-Id: Idf5ccb579d264b343199d8b8344bddeec2c0019f
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_p
Am 20.11.2017 um 15:46 schrieb Michel Dänzer:
On 20/11/17 02:20 PM, Christian König wrote:
Am 20.11.2017 um 11:36 schrieb Michel Dänzer:
On 18/11/17 03:31 PM, Christian König wrote:
Am 17.11.2017 um 17:09 schrieb Michel Dänzer:
On 17/11/17 11:28 AM, Christian König wrote:
Ping? Michel, Alex
On 2017 Nov 22, Martin Babutzka wrote:
>Dear AMD Developers,
>At first congratulations for the DC code submission to the 4.15 kernel.
>Unfortunately the major regression which I reported on 29.09., 06.10.,
>02.11. and 05.11. still exists. But this time I got additional
>debugging information maybe
Am 22.11.2017 um 17:24 schrieb Boris Ostrovsky:
On 11/22/2017 05:09 AM, Christian König wrote:
Am 21.11.2017 um 23:26 schrieb Boris Ostrovsky:
On 11/21/2017 08:34 AM, Christian König wrote:
Hi Boris,
attached are two patches.
The first one is a trivial fix for the infinite loop issue, it now
On 2017-11-22 11:47 AM, Colin King wrote:
> From: Colin Ian King
>
> Currently in the case where some of the allocations fail for dce110_tgv,
> dce110_xfmv, dce110_miv or dce110_oppv then the exit return path ends
> up leaking allocated objects. Fix this by kfree'ing them before returning.
> Also
On 2017-11-15 02:52 AM, Andrey Grodzovsky wrote:
> Can you try this patch ? I noticed there is a new API to use to wait for
> flips instead of what we are using now.
I've been testing this patch for a week and haven't seen the dmesg splat
anymore.
Reviewed-and-Tested-by: Michel Dänzer
--
Eart
Thanks for testing, Harry please merge it into dal-dev tree.
Andrey
On 11/22/2017 12:40 PM, Michel Dänzer wrote:
On 2017-11-15 02:52 AM, Andrey Grodzovsky wrote:
Can you try this patch ? I noticed there is a new API to use to wait for
flips instead of what we are using now.
I've been testing
On 2017-11-22 01:01 PM, Andrey Grodzovsky wrote:
> Thanks for testing, Harry please merge it into dal-dev tree.
>
Thanks, Michel and Andrey. Will merge it.
Harry
> Andrey
>
>
> On 11/22/2017 12:40 PM, Michel Dänzer wrote:
>> On 2017-11-15 02:52 AM, Andrey Grodzovsky wrote:
>>> Can you try thi
Ok, now I have more use-after-free report, this time without dc. I
don't know if this is related, but I didn't have runtime errors without
dc for now.
kasan report:
[22697.845475]
==
[22697.845495] BUG: KASAN: use-after-free in amd
On 2017-11-22 02:13 AM, S, Shirish wrote:
> From: Shirish S
>
> While validation fbc, array_mode of the pipe is accessed without checking
> plane_state exists for it.
> Causing to null pointer dereferencing followed by reboot when a crtc
> associated with external display(not
> connected) is pa
Which driver are you using?
I guess your driver is a bit old, the issue should be fixed before.
Regards,
David Zhou
On 2017年11月23日 06:31, Johannes Hirte wrote:
Ok, now I have more use-after-free report, this time without dc. I
don't know if this is related, but I didn't have runtime errors
Hi Leo,
Would you please comments on Christian's questions?
Best Regards,
Frank
-Original Message-
From: Min, Frank
Sent: Wednesday, November 22, 2017 4:04 PM
To: Koenig, Christian ;
amd-gfx@lists.freedesktop.org; Liu, Leo
Subject: RE: [PATCH] drm/amdgpu: correct vce4.0 fw config for S
Hi,
I just want to let you know that I'm still alive and still committed to
porting VCE 1.0 from radeon to amdgpu. However, for many reasons, I've
been pretty much unable to work on the code since my last communication.
That being said, I've created a script based on Piotr Redlewski's work
to gen
From: Shirish S
Currently the atomic check code uses legacy_cursor_update to differnetiate if
the cursor plane is being requested by the user, which is not required as we
shall be updating plane only if modeset is requested/required.
Have tested cursor plane and underlay get updated seamlessl
42 matches
Mail list logo
