RE: [PATCH 2/2] drm/ttm: swap consecutive allocated pooled pages v3

Hold on, only Patch 1 is Reviewed-by: Roger He . For Patch 2: + list_for_each_entry(p, , lru) { + /* Swap the pages if we detect consecutive order */ + if (count > first && pages[count - 1] == p - 1) { +

RE: [PATCH 2/2] drm/ttm: swap consecutive allocated pooled pages v3

Series is: Reviewed-by: Roger He Thanks Roger(Hongbo.He) -Original Message- From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com] Sent: Monday, December 04, 2017 8:46 PM To: dri-de...@lists.freedesktop.org; amd-gfx@lists.freedesktop.org; He, Roger

Re: [PATCH 0/2] Move scheduler out of AMDGPU

On Fri, Dec 1, 2017 at 10:55 AM, Christian König wrote: > Am 01.12.2017 um 16:28 schrieb Lucas Stach: >> >> Hi all, >> >> so this is the first step to make the marvelous AMDGPU scheduler useable >> for other drivers. I have a (mostly) working prototype of Etnaviv using

Re: [PATCH 1/3] st/va: rename vlVaSubpictureImage to vlVaSetSubpictureImage

Sent to the incorrect lists. Please ignores. Thanks. On 12/04/2017 03:50 PM, Leo Liu wrote: Following VA spec Signed-off-by: Leo Liu --- src/gallium/state_trackers/va/context.c| 2 +- src/gallium/state_trackers/va/subpicture.c | 2 +-

[PATCH 2/3] st/va: use designated initialisers for VA driver functions

Signed-off-by: Leo Liu --- src/gallium/state_trackers/va/context.c | 99 - 1 file changed, 49 insertions(+), 50 deletions(-) diff --git a/src/gallium/state_trackers/va/context.c b/src/gallium/state_trackers/va/context.c index

[PATCH 3/3] st/va: Enable vaExportSurfaceHandle()

From: Mark Thompson It will be present from libva 2.1 (VAAPI 1.1.0 or higher). v2: rebase to previous patches(Leo) Signed-off-by: Mark Thompson Signed-off-by: Leo Liu --- src/gallium/state_trackers/va/context.c | 2 +-

[PATCH] drm/amd/display: add mod_freesync_user_enable to dm_connector_state

We don't currently expose variable refresh rate, but add the state to the connector state to make it easier to maintain the support for it from a hw support perspective while we figure out the uapi for drm. Signed-off-by: Alex Deucher ---

[PATCH 1/3] st/va: rename vlVaSubpictureImage to vlVaSetSubpictureImage

Following VA spec Signed-off-by: Leo Liu --- src/gallium/state_trackers/va/context.c| 2 +- src/gallium/state_trackers/va/subpicture.c | 2 +- src/gallium/state_trackers/va/va_private.h | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git

Re: [PATCH] drm: amd: dc: don't use FP math when Kcov is enabled

On 2017-12-04 08:08 AM, Arnd Bergmann wrote: > Building the DCN 1.0 Raven display driver with CONFIG_KCOV_INSTRUMENT_ALL=y > and CONFIG_KCOV_ENABLE_COMPARISONS=y results in warnings about many functions > that do a comparison of floating-point variables: > >

Re: [PATCH libdrm 3/3] amdgpu: Only remember the device's marketing name

On Fri, Dec 1, 2017 at 11:56 AM, Michel Dänzer wrote: > From: Michel Dänzer > > There's no point in keeping around the full table of marketing names, > when amdgpu_get_marketing_name only ever returns the device's marketing > name. > > Signed-off-by:

Re: [PATCH 0/4] Backported amdgpu ttm deadlock fixes for 4.14

On Thu, Nov 30, 2017 at 07:23:02PM -0500, Lyude Paul wrote: > I haven't gone to see where it started, but as of late a good number of > pretty nasty deadlock issues have appeared with the kernel. Easy > reproduction recipe on a laptop with i915/amdgpu prime with lockdep enabled: > > DRI_PRIME=1

[PATCH] drm: amd: dc: don't use FP math when Kcov is enabled

Building the DCN 1.0 Raven display driver with CONFIG_KCOV_INSTRUMENT_ALL=y and CONFIG_KCOV_ENABLE_COMPARISONS=y results in warnings about many functions that do a comparison of floating-point variables: drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.o: In function `dcn_bw_calc_rq_dlg_ttu':

Re: [PATCH 1/2] drm/ttm: swap consecutive allocated cached pages v3

On 2017-12-04 01:46 PM, Christian König wrote: > When we detect consecutive allocation of pages swap them to avoid > accidentally freeing them as huge page. > > v2: use swap > v3: check if it's really the first allocated page > > Signed-off-by: Christian König > --- >

Re: [PATCH] drm/amdkfd: Fix printing pointer cast

Thanks. This change is Reviewed-by: Felix Kuehling On 2017-12-04 06:50 AM, Kent Russell wrote: > Just print a pointer instead of casting > > v2: Remove the 0x prefix, since %p prints that automatically, and remove > it from one other spot as well > > Change-Id:

[PATCH umr] Allow specifying virtual devices now

Now you can specify a device not present in the system for the purposes of using the --lookup command (also -lr and -lb). Handy for decoding register dumps for ASICs you don't have access to. Simply use the --force command with a '.' prefix, e.g. umr -f .vega10 -lb Can be combined with NPI

[PATCH 1/2] drm/ttm: swap consecutive allocated cached pages v3

When we detect consecutive allocation of pages swap them to avoid accidentally freeing them as huge page. v2: use swap v3: check if it's really the first allocated page Signed-off-by: Christian König --- drivers/gpu/drm/ttm/ttm_page_alloc.c | 7 ++- 1 file

[PATCH 2/2] drm/ttm: swap consecutive allocated pooled pages v3

When we detect consecutive allocation of pages swap them to avoid accidentally freeing them as huge page. v2: use swap v3: check if it's really the first allocated page Signed-off-by: Christian König --- drivers/gpu/drm/ttm/ttm_page_alloc.c | 7 ++- 1 file

RE: [PATCH 1/2] drm/ttm: swap consecutive allocated cached pages v2

-Original Message- From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com] Sent: Monday, December 04, 2017 8:13 PM To: dri-de...@lists.freedesktop.org; amd-gfx@lists.freedesktop.org; He, Roger ; ckoenig.leichtzumer...@gmail.com Subject: [PATCH 1/2] drm/ttm:

Re: [PATCH 1/2] drm/ttm: swap consecutive allocated cached pages

Am 04.12.2017 um 12:51 schrieb Michel Dänzer: On 2017-12-04 12:42 PM, Christian König wrote: When we detect consecutive allocation of pages swap them to avoid accidentally freeing them as huge page. Signed-off-by: Christian König ---

[PATCH 1/2] drm/ttm: swap consecutive allocated cached pages v2

When we detect consecutive allocation of pages swap them to avoid accidentally freeing them as huge page. v2: use swap Signed-off-by: Christian König --- drivers/gpu/drm/ttm/ttm_page_alloc.c | 4 1 file changed, 4 insertions(+) diff --git

[PATCH 2/2] drm/ttm: swap consecutive allocated pooled pages v2

When we detect consecutive allocation of pages swap them to avoid accidentally freeing them as huge page. v2: use swap Signed-off-by: Christian König --- drivers/gpu/drm/ttm/ttm_page_alloc.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git

Re: [PATCH 1/2] drm/ttm: swap consecutive allocated cached pages

On 2017-12-04 12:42 PM, Christian König wrote: > When we detect consecutive allocation of pages swap them to avoid > accidentally freeing them as huge page. > > Signed-off-by: Christian König > --- > drivers/gpu/drm/ttm/ttm_page_alloc.c | 8 > 1 file changed,

[PATCH] drm/amdkfd: Fix printing pointer cast

Just print a pointer instead of casting v2: Remove the 0x prefix, since %p prints that automatically, and remove it from one other spot as well Change-Id: I0564230d2985e703d59201832f50358da3b67afc Signed-off-by: Kent Russell --- drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c |

[PATCH 2/2] drm/ttm: swap consecutive allocated pooled pages

When we detect consecutive allocation of pages swap them to avoid accidentally freeing them as huge page. Signed-off-by: Christian König --- drivers/gpu/drm/ttm/ttm_page_alloc.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git

[PATCH 1/2] drm/ttm: swap consecutive allocated cached pages

When we detect consecutive allocation of pages swap them to avoid accidentally freeing them as huge page. Signed-off-by: Christian König --- drivers/gpu/drm/ttm/ttm_page_alloc.c | 8 1 file changed, 8 insertions(+) diff --git

Re: [PATCH 0/2] Move scheduler out of AMDGPU

Hi, Am Samstag, den 02.12.2017, 12:14 + schrieb Liu, Monk: > I'm wondering if GPU reset still work after this home move ... Why wouldn't it continue to work? After all this is just a code move that doesn't change anything about the inner workings of the scheduler. Regards, Lucas > >