Re: [PATCH] drm/amd/amdgpu: vcn10 Add callback for emit_reg_write_reg_wait

Reviewed-by: Andrey Grodzovsky Andrey On 05/01/2018 10:18 AM, Tom St Denis wrote: The callback .emit_reg_write_reg_wait was missing for vcn decode which resulted in a kernel oops. Signed-off-by: Tom St Denis ---

Re: [PATCH] drm/amd/display: remove need of modeset flag for overlay planes

On Fri, Apr 27, 2018 at 3:27 AM Shirish S wrote: > This patch is in continuation to the > "843e3c7 drm/amd/display: defer modeset check in dm_update_planes_state" > where we started to eliminate the dependency on > DRM_MODE_ATOMIC_ALLOW_MODESET to be set by the user space, >

Re: New SPDX-License-Identifier requirement

I believe it should be : SPDX-License-Identifier: GPL-2.0 OR MIT But John probably knows best about this Oded On Tue, May 1, 2018 at 11:14 PM, Felix Kuehling wrote: > Hi, > > I'm getting a checkpatch warning with the latest amdkfd-next branch > (4.17-rc2) when adding a

New SPDX-License-Identifier requirement

Hi, I'm getting a checkpatch warning with the latest amdkfd-next branch (4.17-rc2) when adding a new file: WARNING: Missing or malformed SPDX-License-Identifier tag in line 1 #34: FILE: drivers/gpu/drm/amd/amdkfd/cwsr_trap_handler.h:1: I've read Documentation/process/license-rules.rst but I'm

[PATCH 01/12] drm/amdkfd: Dump HQD of HIQ

From: Oak Zeng Signed-off-by: Oak Zeng Reviewed-by: Felix Kuehling Signed-off-by: Felix Kuehling --- drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 12 1 file changed, 12 insertions(+)

[PATCH 06/12] drm/amdkfd: Separate trap handler assembly code and its hex values

From: Yong Zhao Since the assembly code is inside "#if 0", it is ineffective. Despite that, during debugging, we need to change the assembly code, extract it into a separate file and compile the new file into hex values using sp3. That process also requires us to remove "#if

[PATCH 04/12] drm/amdkfd: use %px to print user space address instead of %p

From: Philip Yang Signed-off-by: Philip Yang Reviewed-by: Felix Kuehling Signed-off-by: Felix Kuehling --- drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 2 +- drivers/gpu/drm/amd/amdkfd/kfd_queue.c | 8

[PATCH 08/12] drm/amdkfd: Fix signal handling performance again

It turns out that idr_for_each_entry is really slow compared to just iterating over the slots. Based on measurements the difference is estimated to be about a factor 64. That means using idr_for_each_entry is only worth it with very few allocated events. Signed-off-by: Felix Kuehling

[PATCH 05/12] drm/amdkfd: Remove redundant include of amd-iommu.h

Signed-off-by: Felix Kuehling --- drivers/gpu/drm/amd/amdkfd/kfd_device.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c b/drivers/gpu/drm/amd/amdkfd/kfd_device.c index fb4a72d..17de4ac 100644 ---

[PATCH 03/12] drm/amdkfd: Use volatile MTYPE in default/alternate apertures

From: Jay Cornwall MTYPE_NC_NV (0) marks scalar/vector L1 cache lines as non-volatile. Cache lines loaded through these apertures are intended to be invalidated before (and sometimes during) a dispatch. The non-volatile qualifier prevents these cache lines from being

[PATCH 00/12] Assorted KFD fixes

These are some random patches I noticed when comparing amdkfd-next against amd-kfd-staging. Ben Goz (1): drm/amdkfd: Locking PM mutex while allocating IB buffer Felix Kuehling (4): drm/amdkfd: Remove redundant include of amd-iommu.h drm/amdkfd: Fix signal handling performance again

[PATCH 11/12] drm/amdkfd: Remove queue node when destroy queue failed

From: Shaoyun Liu HWS may hang in the middle of destroy queue, remove the queue from the process queue list so it won't be freed again in the future Signed-off-by: Shaoyun Liu Reviewed-by: Felix Kuehling Signed-off-by: Felix

[PATCH 10/12] drm/amdkfd: Locking PM mutex while allocating IB buffer

From: Ben Goz Signed-off-by: Ben Goz Reviewed-by: Felix Kuehling Signed-off-by: Felix Kuehling --- drivers/gpu/drm/amd/amdkfd/kfd_packet_manager.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-)

[PATCH 12/12] drm/amdkfd: Add sanity checks in IRQ handlers

Only accept interrupts from KFD VMIDs. Just checking for a PASID may not be enough because amdgpu started using PASIDs to map VM faults to processes. Warn if an IRQ doesn't have a valid PASID (indicating a firmware bug). Suggested-by: Shaoyun Liu Suggested-by: Oak Zeng

[PATCH 07/12] drm/amdkfd: Fix CP soft hang on APUs

From: Yong Zhao The problem happens on Raven and Carrizo. The context save handler should not clear the high bits of PC_HI before extracting the bits of IB_STS. The bug is not relevant to VEGA10 until we enable demand paging. Signed-off-by: Jay Cornwall

[PATCH 02/12] drm/amdkfd: Reduce priority of context-saving waves before spin-wait

From: Jay Cornwall Synchronization between context-saving wavefronts is achieved by sending a SAVEWAVE message to the SPI and then spin-waiting for a response. These spin-waiting wavefronts may inhibit the progress of other wavefronts in the context save handler, leading to

[PATCH 09/12] drm/amdkfd: Remove initialization of cp_hqd_ib_control on CIK

The initialization is not necessary. amd-kfd-staging and ROCm releases have worked without it for two years. Signed-off-by: Felix Kuehling --- drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c | 4 1 file changed, 4 deletions(-) diff --git

Re: vcn regression on raven1

Hi Jerry, It's well past EOD for me I'll pick this up in the morning. I'm fairly certain I wrote my patch against the tip of amd-staging-drm-next as of my pull this morning though. If it's in there and I missed it somehow I apologize otherwise it'd be nice to make sure it's in there. Based

Re: [PATCH] drm/amd/display: remove need of modeset flag for overlay planes

On 5/2/2018 12:53 AM, Stéphane Marchesin wrote: On Fri, Apr 27, 2018 at 3:27 AM Shirish S wrote: This patch is in continuation to the "843e3c7 drm/amd/display: defer modeset check in dm_update_planes_state" where we started to eliminate the dependency on

Re: vcn regression on raven1

On 05/01/2018 09:34 PM, Tom St Denis wrote: Hi all, I've noticed that on the tip of drm-next vcn playback of video is broken (see dmesg below). I've bisected it to this commit It may be fixed here as a common issue. * https://patchwork.freedesktop.org/patch/218909/ Jerry [root@raven

Re: vcn regression on raven1

I pull from gerrit. I'm just pointing out that it's not on drm-next upstream either. It may have been missed in a rebase or something. Tom From: Zhang, Jerry Sent: Tuesday, May 1, 2018 21:07 To: StDenis, Tom; Deucher, Alexander Cc: Koenig, Christian;

[PATCH] drm/amd/display: remove need of modeset flag for overlay planes (V2)

This patch is in continuation to the "843e3c7 drm/amd/display: defer modeset check in dm_update_planes_state" where we started to eliminate the dependency on DRM_MODE_ATOMIC_ALLOW_MODESET to be set by the user space, which as such is not mandatory. After deferring, this patch eliminates the

答复: Tracking: radeon 0000:00:10.0: ring 0 stalled for more than 10240msec

Hi , If you are sure that the HW worked fine before. I think you should: 1. Be sure that HW works fine now. 2. recall the driver to the point at where it works well, and then replace them one by one to confirm component which causes the issue. 3. try to update the last VBIOS to adapt new

Re: vcn regression on raven1

Hi Jerry, So far as I know this wasn't included on the tip of drm-next. I hit this this morning in my semi-regular pull/build/test cycle. Was this missed in a recent rebase? Tom From: Zhang, Jerry Sent: Tuesday, May 1, 2018 20:43 To: StDenis, Tom;

Re: vcn regression on raven1

Hi Tom, Sound you get the code from freedesktop rather than the internal drm-next. Unfortunately freedesktop looks delay to sync the code from internal drm-next. That's the gap it happened as issue in the test. Hi Alex, Is that a issue for code syncing between freedesktop and internal

Re: vcn regression on raven1

Hi Jerry, Like I said it's (now well) past EOD (meaning my workstation is powered off) so I'll have to check tomorrow. But I do pull from gerrit daily and build from that. I'll take a look in the morning. Cheers, Tom From: Zhang, Jerry Sent: Tuesday,

Re: vcn regression on raven1

Hi Tom, It was landed in the latest drm-next, like * 964933a 2018-04-27 10:26:09 +0800 drm/amdgpu/uvd7: add emit_reg_write_reg_wait ring callback Did you test with that included? Please try to get the latest drm-next, if not. They look the same issue from the log. Jerry On 05/02/2018

Re: vcn regression on raven1

Hi Tom, Do you mean you cannot find the patch from gerrit/amd-staging-dkms-next either? I do find it. the tip of gerrit/amd-staging-drm-next is * bb54e82 2018-04-30 12:17:07 -0400 drm/amdgpu: Switch to interruptable wait to recover from ring hang. while the tip of freedesktop is *

Re: vcn regression on raven1

Hi Tom, Ha, got your meaning. Please check it with the latest drm-next from gerrit tomorrow. Jerry On 05/02/2018 09:41 AM, StDenis, Tom wrote: Hi Jerry, Like I said it's (now well) past EOD (meaning my workstation is powered off) so I'll have to check tomorrow. But I do pull from gerrit

vcn regression on raven1

Hi all, I've noticed that on the tip of drm-next vcn playback of video is broken (see dmesg below). I've bisected it to this commit [root@raven linux]# git bisect good 701372349fd55b5396b335580e979ac4dde3dd02 is the first bad commit commit 701372349fd55b5396b335580e979ac4dde3dd02 Author:

[PATCH] drm/amd/amdgpu: vcn10 Add callback for emit_reg_write_reg_wait

The callback .emit_reg_write_reg_wait was missing for vcn decode which resulted in a kernel oops. Signed-off-by: Tom St Denis --- drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c

Re: [PATCH libdrm] amdgpu: Deinitialize vamgr_high{,_32}

On 2018-04-27 04:44 PM, Michel Dänzer wrote: > From: Michel Dänzer > > Fixes memory leaks. > > Signed-off-by: Michel Dänzer > --- > amdgpu/amdgpu_device.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/amdgpu/amdgpu_device.c

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

On 04/30, Andrey Grodzovsky wrote: > > What about changing PF_SIGNALED to  PF_EXITING in > drm_sched_entity_do_release > > -   if ((current->flags & PF_SIGNALED) && current->exit_code == SIGKILL) > +  if ((current->flags & PF_EXITING) && current->exit_code == SIGKILL) let me repeat,

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

On 04/30, Christian König wrote: > > Well when the process is killed we don't care about correctness any more, we > just want to get rid of it as quickly as possible (OOM situation etc...). OK, > But it is perfectly possible that a process submits some render commands and > then calls exit() or

Re: [PATCH v3 1/3] drm/prime: Iterate SG DMA addresses separately

On 4/30/2018 9:54 AM, Robin Murphy wrote: > For dma_map_sg(), DMA API implementations are free to merge consecutive > segments into a single DMA mapping if conditions are suitable, thus the > resulting DMA addresses which drm_prime_sg_to_page_addr_arrays() > iterates over may be packed into fewer

Re: [PATCH v2 2/3] drm/amdgpu: Allow dma_map_sg() coalescing

On 27/04/18 20:42, Sinan Kaya wrote: On 4/27/2018 11:54 AM, Robin Murphy wrote: ubuntu@ubuntu:~/amdgpu$_./vectoradd_hip.exe [  834.002206] create_process:620 [  837.413021] Unable to handle kernel NULL pointer dereference at virtual address 0018 £5 says that's sg_dma_len(NULL), which

[PATCH v3 2/3] drm/amdgpu: Allow dma_map_sg() coalescing

The amdgpu driver doesn't appear to directly use the scatterlist mapped by amdgpu_ttm_tt_pin_userptr(), it merely hands it off to drm_prime_sg_to_page_addr_arrays() to generate the dma_address array which it actually cares about. Now that the latter can cope with dma_map_sg() coalescing

[PATCH v3 1/3] drm/prime: Iterate SG DMA addresses separately

For dma_map_sg(), DMA API implementations are free to merge consecutive segments into a single DMA mapping if conditions are suitable, thus the resulting DMA addresses which drm_prime_sg_to_page_addr_arrays() iterates over may be packed into fewer entries than sgt->nents implies. The current

[REGRESSION] drm/amd/dc: Add dc display driver (v2)

Hi Harry, A kernel bug report was opened against Ubuntu [0].  After a kernel bisect, it was found the following commit introduced the bug: commit 4562236b3bc0a28aeb6ee93b2d8a849a4c4e1c7c Author: Harry Wentland Date:   Tue Sep 12 15:58:20 2017 -0400     drm/amd/dc: Add

[PATCH v3 3/3] drm/radeon: Allow dma_map_sg() coalescing

Much like amdgpu, the radeon driver doesn't appear to directly use the scatterlist mapped by radeon_ttm_tt_pin_userptr(), it merely hands it off to drm_prime_sg_to_page_addr_arrays() to generate the dma_address array which it actually cares about. Now that the latter can cope with dma_map_sg()

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

Christian König writes: > Hi Eric, > > sorry for the late response, was on vacation last week. > > Am 26.04.2018 um 02:01 schrieb Eric W. Biederman: >> Andrey Grodzovsky writes: >> >>> On 04/25/2018 01:17 PM, Oleg Nesterov wrote:

Re: [PATCH libdrm] amdgpu: Deinitialize vamgr_high{,_32}

Reviewed-by: Andrey Grodzovsky Andrey On 05/01/2018 04:03 AM, Michel Dänzer wrote: On 2018-04-27 04:44 PM, Michel Dänzer wrote: From: Michel Dänzer Fixes memory leaks. Signed-off-by: Michel Dänzer ---

Re: [PATCH v2 1/2] drm/ttm: Only allocate huge pages with new flag TTM_PAGE_FLAG_TRANSHUGE

On 2018-05-01 01:15 AM, Dave Airlie wrote: >> >> >> Yes, I fixed the original false positive messages myself with the swiotlb >> maintainer and I was CCed in fixing the recent fallout from Chris changes as >> well. > > So do we have a good summary of where this at now? > > I'm getting reports on