Re: [PATCH] drm/amdkfd: Make queue mapping interfaces more consistent

On Wed, Oct 18, 2017 at 5:55 AM, Felix Kuehling wrote: > Pass unmap filter parameters directly to execute_queues_cpsch, same > as unmap_queues_cpsch. > > Signed-off-by: Felix Kuehling > --- > .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 32

Re: [PATCH 1/3] drm/amdgpu: always consider virualised device for checking post

Hi all, Could someone review this patch? — Sincerely Yours, Pixel On 17/10/2017, 4:06 PM, "amd-gfx on behalf of Ding, Pixel" wrote: >you can see the difference of function amdgpu_need_post. Generally speaking,

Re: [PATCH] drm/amdgpu/psp: prevent page fault by checking write_frame address(v2) -v2: update the ring_buffer_end address

On Mon, Oct 16, 2017 at 11:26 PM, Evan Quan wrote: > Change-Id: If3b79428b32ffab57b4e75f9c20c2b2d7e600223 > Signed-off-by: Evan Quan Please include a better commit message. Something like: Prevent a a possible buffer overflow when updating the ring buffer

Applied "drm/amdgpu Moving amdgpu asic types to a separate file" to the asoc tree

The patch drm/amdgpu Moving amdgpu asic types to a separate file has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and

Applied "ASoC: AMD: Audio buffer related changes for Stoney" to the asoc tree

The patch ASoC: AMD: Audio buffer related changes for Stoney has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and

Applied "ASoC: AMD: disabling memory gating in stoney platform" to the asoc tree

The patch ASoC: AMD: disabling memory gating in stoney platform has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and

Applied "ASoC: AMD: Add machine driver for cz rt5650" to the asoc tree

The patch ASoC: AMD: Add machine driver for cz rt5650 has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to

Applied "ASoC: AMD: DMA driver changes for Stoney Platform" to the asoc tree

The patch ASoC: AMD: DMA driver changes for Stoney Platform has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent

Re: [PATCH 1/3] drm/amdgpu: always consider virualised device for checking post

yeah, RB-by: Monk Liu From: Ding, Pixel Sent: Tuesday, October 17, 2017 4:06 PM To: Liu, Monk; amd-gfx@lists.freedesktop.org; Koenig, Christian Cc: Li, Bingley; Sun, Gary Subject: Re: [PATCH 1/3] drm/amdgpu: always consider virualised device

[PATCH 3/3] drm/amdgpu: busywait KIQ register accessing v3

From: pding Register accessing is performed when IRQ is disabled. Never sleep in this function. Known issue: dead sleep in many use cases of index/data registers. v2: wrap polling fence functions. don't trigger IRQ for polling in case of wrongly fence signal. v3: handle

Re: [PATCH] drm/amd/display: Trigger bug when allocation fails.

On 2017-10-17 06:05 PM, Andrey Grodzovsky wrote: > > > On 10/17/2017 05:11 PM, Tom St Denis wrote: >> I'm ok with not pushing my commit and simply adding an else branch that sets >> the pointer to NULL. >> >> (maybe put a WARN_ON to give context?) > > Seems reasonable to me. > Harry ? >

Re: Various cleanups for amdgpu_dm

On 2017-10-17 05:43 PM, Tom St Denis wrote: > On 17/10/17 04:30 PM, Harry Wentland wrote: >> Thanks for these cleanups. >> >> Some of these could possibly squashed but then, I generally >> prefer smaller changes than one big lump. >> >> Reviewed-by: Harry Wentland > > Hi

Re: Various cleanups for amdgpu_dm

On 17/10/17 04:30 PM, Harry Wentland wrote: Thanks for these cleanups. Some of these could possibly squashed but then, I generally prefer smaller changes than one big lump. Reviewed-by: Harry Wentland Hi Harry, You're welcome. Normally I too agree that squashing is

Re: [PATCH] drm/amd/display: Trigger bug when allocation fails.

I'm ok with not pushing my commit and simply adding an else branch that sets the pointer to NULL. (maybe put a WARN_ON to give context?) Tom On 17/10/17 04:42 PM, Andrey Grodzovsky wrote: On 10/17/2017 04:12 PM, Nicolai Hähnle wrote: On 17.10.2017 19:45, Tom St Denis wrote: If the

Re: [PATCH] drm/amd/display: Trigger bug when allocation fails.

On 10/17/2017 04:12 PM, Nicolai Hähnle wrote: On 17.10.2017 19:45, Tom St Denis wrote: If the allocation fails in amdgpu_dm_connector_funcs_reset() the API cannot continue so trigger a BUG_ON. That seems questionable to be honest. The drm_atomic_helper version of this function ends up

Re: [PATCH] drm/amd/display: Trigger bug when allocation fails.

On 2017-10-17 04:12 PM, Nicolai Hähnle wrote: > On 17.10.2017 19:45, Tom St Denis wrote: >> If the allocation fails in amdgpu_dm_connector_funcs_reset() the >> API cannot continue so trigger a BUG_ON. > > That seems questionable to be honest. The drm_atomic_helper version of this > function ends

Re: Various cleanups for amdgpu_dm

Thanks for these cleanups. Some of these could possibly squashed but then, I generally prefer smaller changes than one big lump. Reviewed-by: Harry Wentland Harry On 2017-10-17 12:18 PM, Tom St Denis wrote: > Various cleanups to indentation/braces as well as a couple

Re: [PATCH] drm/amd/display: Trigger bug when allocation fails.

On 17.10.2017 19:45, Tom St Denis wrote: If the allocation fails in amdgpu_dm_connector_funcs_reset() the API cannot continue so trigger a BUG_ON. That seems questionable to be honest. The drm_atomic_helper version of this function ends up setting connector->state = NULL; in this case.

Re: possible use-after-free in amdgpu_dm

On 10/17/2017 03:43 PM, Harry Wentland wrote: On 2017-10-17 02:15 PM, Christian König wrote: Am 17.10.2017 um 19:58 schrieb Felix Kuehling: On 2017-10-17 01:25 PM, Tom St Denis wrote: On 17/10/17 01:23 PM, Tom St Denis wrote: On 17/10/17 01:18 PM, Christian König wrote: Am 17.10.2017 um

[PATCH] drm/amdgpu: fix a possible NULL dereference when attempting reset

[drm:gfx_v8_0_priv_reg_irq] *ERROR* Illegal register access in command stream [drm] IP block:gmc_v8_0 is hung! [drm] IP block:gfx_v8_0 is hung! BUG: unable to handle kernel NULL pointer dereference at 00d8 IP: amd_sched_hw_job_reset+0x3c/0x9a PGD 3aedd8067 P4D 3aedd8067 PUD 3aedd9067

Re: [PATCH] drm/amd/display: Trigger bug when allocation fails.

Reviewed-by: Andrey Grodzovsky On 10/17/2017 01:45 PM, Tom St Denis wrote: If the allocation fails in amdgpu_dm_connector_funcs_reset() the API cannot continue so trigger a BUG_ON. Signed-off-by: Tom St Denis ---

Re: possible use-after-free in amdgpu_dm

On 10/17/2017 01:58 PM, Felix Kuehling wrote: On 2017-10-17 01:25 PM, Tom St Denis wrote: On 17/10/17 01:23 PM, Tom St Denis wrote: On 17/10/17 01:18 PM, Christian König wrote: Am 17.10.2017 um 16:10 schrieb Tom St Denis: In this block of code: void amdgpu_dm_connector_funcs_reset(struct

Re: possible use-after-free in amdgpu_dm

Am 17.10.2017 um 19:58 schrieb Felix Kuehling: On 2017-10-17 01:25 PM, Tom St Denis wrote: On 17/10/17 01:23 PM, Tom St Denis wrote: On 17/10/17 01:18 PM, Christian König wrote: Am 17.10.2017 um 16:10 schrieb Tom St Denis: In this block of code: void amdgpu_dm_connector_funcs_reset(struct

Re: possible use-after-free in amdgpu_dm

On 2017-10-17 01:25 PM, Tom St Denis wrote: > On 17/10/17 01:23 PM, Tom St Denis wrote: >> On 17/10/17 01:18 PM, Christian König wrote: >>> Am 17.10.2017 um 16:10 schrieb Tom St Denis: In this block of code: void amdgpu_dm_connector_funcs_reset(struct drm_connector *connector)

[PATCH] drm/amd/display: Trigger bug when allocation fails.

If the allocation fails in amdgpu_dm_connector_funcs_reset() the API cannot continue so trigger a BUG_ON. Signed-off-by: Tom St Denis --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 + 1 file changed, 1 insertion(+) diff --git

Re: possible use-after-free in amdgpu_dm

On 10/17/2017 01:36 PM, Tom St Denis wrote: On 17/10/17 01:34 PM, Andrey Grodzovsky wrote: On 10/17/2017 01:25 PM, Tom St Denis wrote: On 17/10/17 01:23 PM, Tom St Denis wrote: On 17/10/17 01:18 PM, Christian König wrote: Am 17.10.2017 um 16:10 schrieb Tom St Denis: In this block of

Re: possible use-after-free in amdgpu_dm

On 17/10/17 01:34 PM, Andrey Grodzovsky wrote: On 10/17/2017 01:25 PM, Tom St Denis wrote: On 17/10/17 01:23 PM, Tom St Denis wrote: On 17/10/17 01:18 PM, Christian König wrote: Am 17.10.2017 um 16:10 schrieb Tom St Denis: In this block of code: void amdgpu_dm_connector_funcs_reset(struct

Re: possible use-after-free in amdgpu_dm

On 10/17/2017 01:25 PM, Tom St Denis wrote: On 17/10/17 01:23 PM, Tom St Denis wrote: On 17/10/17 01:18 PM, Christian König wrote: Am 17.10.2017 um 16:10 schrieb Tom St Denis: In this block of code: void amdgpu_dm_connector_funcs_reset(struct drm_connector *connector) { struct

Re: [PATCH 4/9] drm/amdkfd: Avoid submitting an unnecessary packet to HWS

I'll send you a patch by Friday. Regards,   Felix On 2017-10-17 03:04 AM, Oded Gabbay wrote: > Hi Felix, Yong. > I would like to send a pull request to Dave for kernel 4.15 with all > the patches you sent in the last 3 weeks, but I'm blocked by the fix I > asked for this patch. > Do you think

Re: possible use-after-free in amdgpu_dm

On 17/10/17 01:23 PM, Tom St Denis wrote: On 17/10/17 01:18 PM, Christian König wrote: Am 17.10.2017 um 16:10 schrieb Tom St Denis: In this block of code: void amdgpu_dm_connector_funcs_reset(struct drm_connector *connector) {     struct dm_connector_state *state =    

Re: possible use-after-free in amdgpu_dm

On 17/10/17 01:18 PM, Christian König wrote: Am 17.10.2017 um 16:10 schrieb Tom St Denis: In this block of code: void amdgpu_dm_connector_funcs_reset(struct drm_connector *connector) {     struct dm_connector_state *state =     to_dm_connector_state(connector->state);     kfree(state);   

Various cleanups for amdgpu_dm

Various cleanups to indentation/braces as well as a couple of simplifications. Mostly NFC but there are a couple of patches with trivial functional changes (#6, #8) ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org

[PATCH 09/13] drm/amd/display: Fix indentation in create_eml_sink()

Signed-off-by: Tom St Denis --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index

[PATCH 12/13] drm/amd/display: Remove needless cast in amdgpu_dm_connector_init()

The cast of dc_link is redundant. Signed-off-by: Tom St Denis --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c

[PATCH 10/13] drm/amd/display: Tidy up dm_drm_plane_reset()

Move WARN_ON higher up and in doing so fix brace style. Signed-off-by: Tom St Denis --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c

[PATCH 13/13] drm/amd/display: Fix brace style

Signed-off-by: Tom St Denis --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c | 15 ++- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c

[PATCH 05/13] drm/amd/display: Fix brace style in dm_handle_hpd_rx_irq()

Signed-off-by: Tom St Denis --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index

[PATCH 02/13] drm/amd/display: Fix indentation in dm_suspend()

Signed-off-by: Tom St Denis --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index

[PATCH 01/13] drm/amd/display: Simplify dm_late_init()

Signed-off-by: Tom St Denis --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index

Re: Upstream repo for libhsakmt

If I remember correctly, it should be John B. Regards, Andres On 2017-10-17 11:42 AM, Felix Kuehling wrote: I didn't even know about the freedesktop repository. Do you know who has commit access to that? Regards,   Felix On 2017-10-16 10:44 PM, Tom Stellard wrote: Hi Felix, What do you

Re: Upstream repo for libhsakmt

I didn't even know about the freedesktop repository. Do you know who has commit access to that? Regards,   Felix On 2017-10-16 10:44 PM, Tom Stellard wrote: > Hi Felix, > > What do you think about merging your fxkamd/drm-next-wip into the > master branch of the hsakmt repository of

Re: amdgpu: DRI3 with EGL?

On 17/10/17 04:52 PM, Kai Wasserbäch wrote: > Dear Michel, > Michel Dänzer wrote on 17.10.2017 11:20: >> On 16/10/17 06:21 PM, Kai Wasserbäch wrote: >>> Michel Dänzer wrote on 16.10.2017 18:05: On 16/10/17 05:53 PM, Kai Wasserbäch wrote: > [...] > > But when I look at my

Re: [amd-staging-drm-next] compilation error with latest commit #1b006d838f78

On 17/10/17 04:53 PM, Harry Wentland wrote: > On 2017-10-17 10:47 AM, Michel Dänzer wrote: >> On 13/10/17 09:22 PM, Harry Wentland wrote: >>> On 2017-10-12 08:22 PM, Dieter Nützel wrote: next (regression) compilation error:

Re: [amd-staging-drm-next] compilation error with latest commit #1b006d838f78

On 2017-10-17 10:47 AM, Michel Dänzer wrote: > On 13/10/17 09:22 PM, Harry Wentland wrote: >> On 2017-10-12 08:22 PM, Dieter Nützel wrote: >>> Hello, >>> >>> next (regression) compilation error: >>> >>> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c: In function >>>

Re: amdgpu: DRI3 with EGL?

Dear Michel, Michel Dänzer wrote on 17.10.2017 11:20: > On 16/10/17 06:21 PM, Kai Wasserbäch wrote: >> Michel Dänzer wrote on 16.10.2017 18:05: >>> On 16/10/17 05:53 PM, Kai Wasserbäch wrote: [...] But when I look at my Xorg.0.log or the output of eglinfo, I see the following

Re: [amd-staging-drm-next] compilation error with latest commit #1b006d838f78

On 13/10/17 09:22 PM, Harry Wentland wrote: > On 2017-10-12 08:22 PM, Dieter Nützel wrote: >> Hello, >> >> next (regression) compilation error: >> >> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c: In function >> ‘resource_map_pool_resources’: >>

possible use-after-free in amdgpu_dm

In this block of code: void amdgpu_dm_connector_funcs_reset(struct drm_connector *connector) { struct dm_connector_state *state = to_dm_connector_state(connector->state); kfree(state); state = kzalloc(sizeof(*state), GFP_KERNEL); The value of state is

Re: drm/amdgpu: LVDS-1 output only turns on with sleep 1s workaround

Peter Stuge wrote: > Can I help find the cause of my problem and make the internal panel turn > on without my workaround? What information would be needed, and should I > send here or use bugzilla? Anyone? Redirecting me to bugzilla is fine, if that's my best bet. Thanks! //Peter

Re: [PATCH 3/3] drm/amdgpu: busywait KIQ register accessing v2

Thanks. In logically, it can’t handle the extreme case that the seq almost catches up with wait_seq in wrap round where we can’t use this trick, however I understand it can’t happen in reality. I will test and modify. — Sincerely Yours, Pixel On 17/10/2017, 4:59 PM, "Koenig, Christian"

Re: amdgpu: DRI3 with EGL?

On 16/10/17 06:21 PM, Kai Wasserbäch wrote: > Michel Dänzer wrote on 16.10.2017 18:05: >> On 16/10/17 05:53 PM, Kai Wasserbäch wrote: >>> >>> Hey, >>> I'm not sure whether this is a bug or if I'm just missing something. I've >>> got >>> the following stack (Debian testing as a base): >>> GPU:

Re: regression with d6c650c0a8f6f671e49553725e1db541376d95f2

Am 17.10.2017 um 10:57 schrieb Nicolai Hähnle: On 13.10.2017 10:46, Liu, Monk wrote: Just revert Nicolai’s patch,if other routine want to reference s_fence, it should get the finished fence in the first place/time, For gpu_reset routine, it refers to s_fence only on those unfinished job in

Re: [PATCH 3/3] drm/amdgpu: busywait KIQ register accessing v2

Am 17.10.2017 um 10:38 schrieb Ding, Pixel: [SNIP] + if (seq >= wait_seq && wait_seq >= last_seq) + break; + if (seq <= last_seq && + (wait_seq <= seq || wait_seq >= last_seq)) + break; Why not just

Re: regression with d6c650c0a8f6f671e49553725e1db541376d95f2

On 13.10.2017 10:46, Liu, Monk wrote: Just revert Nicolai’s patch,if other routine want to reference s_fence, it should get the finished fence in the first place/time, For gpu_reset routine, it refers to s_fence only on those unfinished job in sched_hw_job_reset, so totally safe to refer to

Re: [PATCH 2/2] drm/amdgpu: allow GTT overcommit during bind

On 2017年10月17日 16:34, Chunming Zhou wrote: On 2017年10月17日 16:27, Christian König wrote: Am 17.10.2017 um 10:15 schrieb Chunming Zhou: On 2017年10月17日 15:46, Christian König wrote: Am 17.10.2017 um 06:11 schrieb Chunming Zhou: On 2017年10月16日 19:40, Christian König wrote: Am 16.10.2017

Re: [PATCH 3/3] drm/amdgpu: busywait KIQ register accessing v2

On 17/10/2017, 4:20 PM, "Koenig, Christian" wrote: >Am 17.10.2017 um 08:37 schrieb Pixel Ding: >> From: pding >> >> Register accessing is performed when IRQ is disabled. Never sleep in >> this function. >> >> Known issue: dead sleep in many use

Re: [PATCH 2/2] drm/amdgpu: allow GTT overcommit during bind

On 2017年10月17日 16:27, Christian König wrote: Am 17.10.2017 um 10:15 schrieb Chunming Zhou: On 2017年10月17日 15:46, Christian König wrote: Am 17.10.2017 um 06:11 schrieb Chunming Zhou: On 2017年10月16日 19:40, Christian König wrote: Am 16.10.2017 um 11:42 schrieb Chunming Zhou: On

RE: [PATCH 2/2] drm/amdgpu: allow GTT overcommit during bind

Patch is Tested-by: Rex Zhu Best Regards Rex -Original Message- From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Christian König Sent: Tuesday, October 17, 2017 4:28 PM To: Zhou, David(ChunMing); amd-gfx@lists.freedesktop.org Subject: Re:

Re: [PATCH 2/2] drm/amdgpu: allow GTT overcommit during bind

Am 17.10.2017 um 10:15 schrieb Chunming Zhou: On 2017年10月17日 15:46, Christian König wrote: Am 17.10.2017 um 06:11 schrieb Chunming Zhou: On 2017年10月16日 19:40, Christian König wrote: Am 16.10.2017 um 11:42 schrieb Chunming Zhou: On 2017年10月16日 17:26, Christian König wrote: From:

Re: [PATCH 3/3] drm/amdgpu: busywait KIQ register accessing v2

Am 17.10.2017 um 08:37 schrieb Pixel Ding: From: pding Register accessing is performed when IRQ is disabled. Never sleep in this function. Known issue: dead sleep in many use cases of index/data registers. v2: wrap polling fence functions. don't trigger IRQ for polling in

Re: [PATCH 2/2] drm/amdgpu: allow GTT overcommit during bind

On 2017年10月17日 15:46, Christian König wrote: Am 17.10.2017 um 06:11 schrieb Chunming Zhou: On 2017年10月16日 19:40, Christian König wrote: Am 16.10.2017 um 11:42 schrieb Chunming Zhou: On 2017年10月16日 17:26, Christian König wrote: From: Christian König While

Re: [PATCH 1/3] drm/amdgpu: always consider virualised device for checking post

you can see the difference of function amdgpu_need_post. Generally speaking, there were 2 functions to check VBIOS posting, one considers VF and passthru while the other doesn’t. In fact we should always consider VF and PT for checking, right? For example, this checking here believe VF needs a

RE: [PATCH 1/3] drm/amdgpu: always consider virualised device for checking post

From the patch itself I still couldn't tell the difference -Original Message- From: Ding, Pixel Sent: 2017年10月17日 15:54 To: Liu, Monk ; amd-gfx@lists.freedesktop.org; Koenig, Christian Cc: Li, Bingley ; Sun, Gary

RE: [PATCH 2/3] drm/amdgpu: report more amdgpu_fence_info v2

Okay leave it, we may need OS preemption in future so it still can be used for that purpose Reviewed-by: Monk Liu -Original Message- From: Ding, Pixel Sent: 2017年10月17日 15:56 To: Liu, Monk ; amd-gfx@lists.freedesktop.org; Koenig, Christian

Re: [PATCH 2/3] drm/amdgpu: report more amdgpu_fence_info v2

Why? The fence WB is always 8 DW. — Sincerely Yours, Pixel On 17/10/2017, 3:49 PM, "Liu, Monk" wrote: >Please use if (amdgpu_sriov_vf()) >To protect your added part > >-Original Message- >From: Pixel Ding [mailto:pixel.d...@amd.com] >Sent: 2017年10月17日 14:38

Re: [PATCH 1/3] drm/amdgpu: always consider virualised device for checking post

It fixes a issue hidden in: 95 static bool igp_read_bios_from_vram(struct amdgpu_device *adev) 96 { 97 uint8_t __iomem *bios; 98 resource_size_t vram_base; 99 resource_size_t size = 256 * 1024; /* ??? */ 100 101 if (!(adev->flags & AMD_IS_APU)) 102 if

RE: [PATCH 2/3] drm/amdgpu: report more amdgpu_fence_info v2

Please use if (amdgpu_sriov_vf()) To protect your added part -Original Message- From: Pixel Ding [mailto:pixel.d...@amd.com] Sent: 2017年10月17日 14:38 To: amd-gfx@lists.freedesktop.org; Liu, Monk ; Koenig, Christian Cc: Li, Bingley

RE: [PATCH 1/3] drm/amdgpu: always consider virualised device for checking post

I don't understand how this patch works??? Looks like just rename vpost_needed to check_post -Original Message- From: Pixel Ding [mailto:pixel.d...@amd.com] Sent: 2017年10月17日 14:38 To: amd-gfx@lists.freedesktop.org; Liu, Monk ; Koenig, Christian

Re: [PATCH 2/2] drm/amdgpu: allow GTT overcommit during bind

Am 17.10.2017 um 06:11 schrieb Chunming Zhou: On 2017年10月16日 19:40, Christian König wrote: Am 16.10.2017 um 11:42 schrieb Chunming Zhou: On 2017年10月16日 17:26, Christian König wrote: From: Christian König While binding BOs to GART we need to allow a bit

Re: [PATCH 4/9] drm/amdkfd: Avoid submitting an unnecessary packet to HWS

On Sun, Oct 8, 2017 at 3:13 PM, Oded Gabbay wrote: > On Wed, Sep 27, 2017 at 7:09 AM, Felix Kuehling > wrote: >> From: Yong Zhao >> >> Signed-off-by: Yong Zhao >> Signed-off-by: Felix Kuehling

Re: [PATCH 2/3] drm/amdgpu: report more amdgpu_fence_info v2

Am 17.10.2017 um 08:37 schrieb Pixel Ding: From: pding Only for GFX ring. This can help checking MCBP feature. v2: report more fence offs. The fence at the end of the frame will indicate the completion status. If the frame completed normally, the fence is written to the

[PATCH 2/3] drm/amdgpu: report more amdgpu_fence_info v2

From: pding Only for GFX ring. This can help checking MCBP feature. v2: report more fence offs. The fence at the end of the frame will indicate the completion status. If the frame completed normally, the fence is written to the address given in the EVENT_WRITE_EOP packet.

[PATCH 3/3] drm/amdgpu: busywait KIQ register accessing v2

From: pding Register accessing is performed when IRQ is disabled. Never sleep in this function. Known issue: dead sleep in many use cases of index/data registers. v2: wrap polling fence functions. don't trigger IRQ for polling in case of wrongly fence signal.

[PATCH 1/3] drm/amdgpu: always consider virualised device for checking post

From: pding The post checking on scratch registers isn't reliable for virtual function. Signed-off-by: pding --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git

Make staging driver stable for SRIOV VF (1 v2)

This is the first patch series to make latest staging driver stable for SRIOV VF on both Tonga and Vega. Patches are merged from SRIOV branches or reimplemented, including bug fixes and small features requested by SRIOV users. v2: "drm/amdgpu: workaround for VM fault caused by SDMA" is dropped.

[PATCH 3/3] drm/amdgpu: busywait KIQ register accessing v2

From: pding Register accessing is performed when IRQ is disabled. Never sleep in this function. Known issue: dead sleep in many use cases of index/data registers. v2: wrap polling fence functions. don't trigger IRQ for polling in case of wrongly fence signal.

[PATCH 1/3] drm/amdgpu: workaround for VM fault caused by SDMA set_wptr

From: pding The polling memory was standalone in VRAM before, so the HDP flush introduced latency that hides a VM fault issue. Now polling memory leverages the WB in system memory and HDP flush is not required, the VM fault at same page happens. Add delay back to workaround

Make staging driver stable for SRIOV VF (1 v2)

This is the first patch series to make latest staging driver stable for SRIOV VF on both Tonga and Vega. Patches are merged from SRIOV branches or reimplemented, including bug fixes and small features requested by SRIOV users. v2: "drm/amdgpu: workaround for VM fault caused by SDMA" is dropped.

[PATCH 2/3] drm/amdgpu: report more amdgpu_fence_info v2

From: pding Only for GFX ring. This can help checking MCBP feature. v2: report more fence offs. The fence at the end of the frame will indicate the completion status. If the frame completed normally, the fence is written to the address given in the EVENT_WRITE_EOP packet.