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 depend
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
DRM_MODE_ATOMIC_ALLOW_MODESET to be s
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 driver.
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 dai
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, M
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
* a1100
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; amd
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 drm-next?
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 on
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 08:4
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; Deuch
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 li
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
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd
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
---
drivers
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
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
+++ b/driv
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 Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
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
Signed-off-by: Yong Zhao
Reviewed-by: F
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(+)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
b/drivers/gpu/drm
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 distinguished from
those load
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(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_packet_manager.c
b/drivers/gpu/drm/amd/a
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
Signed-off-by: Felix Kueh
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 the
synchronization co
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 0" and modify lines s
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
drm/am
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 a/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c
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
---
drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c | 1 +
1 file changed, 1 insertion(+)
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 file:
>
> WARNING: Mis
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 un
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,
> which as such is not
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
b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0
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
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: Alex
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
---
amdgpu/amdgpu_device.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/amdgpu/
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 b/amdgpu/amdgpu_device.c
> index d81efcf8..983b19ab 1006
34 matches
Mail list logo
