[PATCH 4/4] drm/amdgpu: add timeline support in amdgpu CS

Signed-off-by: Chunming Zhou --- drivers/gpu/drm/amd/amdgpu/amdgpu.h| 8 +- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 111 +++-- include/uapi/drm/amdgpu_drm.h | 9 ++ 3 files changed, 100 insertions(+), 28 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/a

[PATCH 3/4] drm: add timeline syncobj payload query ioctl

user mode can query timeline payload. Signed-off-by: Chunming Zhou --- drivers/gpu/drm/drm_internal.h | 2 ++ drivers/gpu/drm/drm_ioctl.c| 2 ++ drivers/gpu/drm/drm_syncobj.c | 53 ++ include/uapi/drm/drm.h | 11 +++ 4 files changed, 68 insertio

[PATCH 1/4] [RFC]drm: add syncobj timeline support v6

This patch is for VK_KHR_timeline_semaphore extension, semaphore is called syncobj in kernel side: This extension introduces a new type of syncobj that has an integer payload identifying a point in a timeline. Such timeline syncobjs support the following operations: * CPU query - A host operati

[PATCH 2/4] drm: add support of syncobj timeline point wait v2

points array is one-to-one match with syncobjs array. v2: add seperate ioctl for timeline point wait, otherwise break uapi. Signed-off-by: Chunming Zhou --- drivers/gpu/drm/drm_internal.h | 2 + drivers/gpu/drm/drm_ioctl.c| 2 + drivers/gpu/drm/drm_syncobj.c | 99 +

Re: [PATCH] [RFC]drm: add syncobj timeline support v5

On 2018年09月18日 16:32, Christian König wrote: +    for (i = 0; i < args->count_handles; i++) { +    if (syncobjs[i]->type == DRM_SYNCOBJ_TYPE_TIMELINE) { +    DRM_ERROR("timeline syncobj cannot reset!\n"); Why not? I mean that should still work or do I miss anything? timeline semap

[PATCH 5/6] drm/i915: Fix intel_dp_mst_best_encoder()

Currently, i915 appears to rely on blocking modesets on no-longer-present MSTB ports by simply returning NULL for ->best_encoder(), which in turn causes any new atomic commits that don't disable the CRTC to fail. This is wrong however, since we still want to allow userspace to disable CRTCs on no-l

[PATCH 6/6] drm/amdgpu/dm/mst: Use drm_dp_mst_connector_atomic_check()

Hook this into amdgpu's atomic check for their connectors so they never get modesets on no-longer-present MST connectors. We'll also expand on this later once we add DP MST fallback retraining support. As well, turns out that the only atomic DRM driver without the ->best_encoder() bug is amdgpu. C

[PATCH 4/6] drm/i915: Skip vcpi allocation for MSTB ports that are gone

Since we need to be able to allow DPMS on->off prop changes after an MST port has disappeared from the system, we need to be able to make sure we can compute a config for the resulting atomic commit. Currently this is impossible when the port has disappeared, since the VCPI slot searching we try to

[PATCH 1/6] drm/dp_mst: Introduce drm_dp_mst_connector_atomic_check()

Currently the way that we prevent userspace from performing new modesets on MST connectors that have just been destroyed is rather broken. There's nothing in the actual DRM DP MST topology helpers that checks whether or not a connector still exists, instead each DRM driver does this on it's own, us

[PATCH 3/6] drm/i915: Leave intel_conn->mst_port set, use mst_port_gone instead

Currently we set intel_connector->mst_port to NULL to signify that the MST port has been removed from the system so that we can prevent further action on the port such as connector probes, mode probing, etc. However, we're going to need access to intel_connector->mst_port in order to fixup ->best_e

[PATCH 0/6] Fix legacy DPMS changes with MST

There's two major things this patchset does: - Add drm_dp_mst_connector_atomic_check() so drivers don't need to use ->best_encoder() to prevent modesets on zombie MST connectors. We'll use this later for implementing MST fallback retraining as well. - Fix DPMS on->off changes failing with l

[PATCH 2/6] drm/nouveau: Unbreak nv50_mstc->best_encoder()

As mentioned in the previous commit, we currently prevent new modesets on recently-removed MST connectors by returning no encoder from our ->best_encoder() callback once the MST port has disappeared. This is wrong however, because it prevents legacy modesetting users from being able to disable CRTC

Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg

On Tue, Sep 18, 2018 at 10:51:08AM -0700, Darren Hart wrote: > On Fri, Sep 14, 2018 at 09:57:48PM +0100, Al Viro wrote: > > On Fri, Sep 14, 2018 at 01:35:06PM -0700, Darren Hart wrote: > > > > > Acked-by: Darren Hart (VMware) > > > > > > As for a longer term solution, would it be possible to in

Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg

On Fri, Sep 14, 2018 at 09:57:48PM +0100, Al Viro wrote: > On Fri, Sep 14, 2018 at 01:35:06PM -0700, Darren Hart wrote: > > > Acked-by: Darren Hart (VMware) > > > > As for a longer term solution, would it be possible to init fops in such > > a way that the compat_ioctl call defaults to generic_

[PATCH] headers: Sync with drm-next

Generated using make headers_install from the drm-next tree - git://anongit.freedesktop.org/drm/drm branch - drm-next commit - 2dc7bad71cd310dc94d1c9907909324dd2b0618f The changes were as follows :- core: (drm.h, drm_fourcc.h, drm_mode.h) - Added client capabilities for ASPECT_RATIO and WRI

[PATCH 11/11] drm/amd/display: fix gamma not being applied

From: SivapiriyanKumarasamy [WHY] Previously night light forced a full update by applying a transfer function update regardless of if it was changed. This logic was removed, Now gamma surface updates are only applied when there is also a plane info update, this does not work in cases such as us

[PATCH 10/11] drm/amd/display: Remove mst_hotplug_work

From: Leo Li [Why] The work struct's schedule call was removed a while ago, making this useless. [How] Remove it. Change-Id: I22139bcba4275ff679b2e054847e6241f660c8fc Signed-off-by: Leo Li Reviewed-by: David Francis Acked-by: Bhawanpreet Lakha --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgp

[PATCH 09/11] drm/amd/display: Guard against null stream dereference in do flip

From: Nicholas Kazlauskas [Why] During suspend under some hardware configurations can result in a series of atomic commits with a NULL stream status - which causes a NULL pointer dereference. This should be guarded. [How] Exit early from the function - if we can't access the stream then there

[PATCH 08/11] drm/amd/display: Stereo 3D support in VSC

From: Eric Bernstein [Why] Need to add strere 3D information in VSC [How] Update mod_build_vsc_infopacket with stereo info Change-Id: Ie99f9f3259e10dcf37a92192cd08e2a65299cf9d Signed-off-by: Eric Bernstein Reviewed-by: Charlene Liu Acked-by: Bhawanpreet Lakha --- .../amd/display/modules/inf

[PATCH 07/11] drm/amd/display: dc 3.1.67

From: Tony Cheng Change-Id: Ib8a760749e950259214db6bd11167768058e5975 Signed-off-by: Tony Cheng Reviewed-by: Steven Chiu Acked-by: Bhawanpreet Lakha --- drivers/gpu/drm/amd/display/dc/dc.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dc.h

[PATCH 06/11] drm/amd/display: program v_update and v_ready with proper field

From: Su Sung Chung [WHY] There are two different variables used to calculate v_update and v_ready, one for validation and the other for performance parameter calculation. Before the variable for validation was used which caused underflow on 1080edp with vsr enabled [HOW] program v_update and v_

[PATCH 05/11] drm/amd/display: Add color bit info to freesync infoframe

From: SivapiriyanKumarasamy Parse the native color bit and send it to freesync module for future use Change-Id: I75e35194dd1aca45349b6274f85e9cd7472c2363 Signed-off-by: SivapiriyanKumarasamy Reviewed-by: Anthony Koo Acked-by: Bhawanpreet Lakha --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu

[PATCH 04/11] drm/amd/display: add pp_smu NULL pointer check

From: Charlene Liu add pp_smu NULL ptr check Change-Id: Ib810078b1f4ea29d48e197539f3c24bfe7085b75 Signed-off-by: Charlene Liu Reviewed-by: Dmytro Laktyushkin Acked-by: Bhawanpreet Lakha --- drivers/gpu/drm/amd/display/dc/core/dc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -

[PATCH 02/11] drm/amd/display: Refactor FPGA-specific link setup

From: Nikola Cornij FPGA doesn't program backend, so we don't need certain link settings (audio stream for example). Change-Id: I12ebdbefb23a0c53a6c7edc749a5e47fbdbf68a6 Signed-off-by: Nikola Cornij Reviewed-by: Tony Cheng Acked-by: Bhawanpreet Lakha --- drivers/gpu/drm/amd/display/dc/core/d

[PATCH 03/11] drm/amd/display: use proper pipe_ctx index

From: Samson Tam Use link->link_index as index to pipe_ctx[] to get proper link information instead of using index 0 to avoid potential miss matches. Change-Id: If3f8c5f1e02396949d0a0a0d2e14400ecd52af87 Signed-off-by: Samson Tam Reviewed-by: Anthony Koo Acked-by: Bhawanpreet Lakha --- driver

[PATCH 01/11] drm/amdgpu: move reserving GDS/GWS/OA into common code

From: Christian König We don't need that in the per ASIC code. Signed-off-by: Christian König Reviewed-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 18 ++ drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 19 --- drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c

[PATCH 00/11] DC Patches Sep 18, 2018

*Summary of Changes *Add Stereo 3D support in VSC *Add Null pointers in flip and pp_smu *Fix gamma not being applied Charlene Liu (1): drm/amd/display: add pp_smu NULL pointer check Christian König (1): drm/amdgpu: move reserving GDS/GWS/OA into common code Eric Bernstein (1): drm/amd/d

Re: Regression on gfx8 with ring init

Tom, can you try if the following makes it working again? diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c index b6160de70d12..d65f5ba92fc5 100644 --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c @@ -937,6 +937,10

Re: Regression on gfx8 with ring init

CRTC and GFX interrupts seem to be working perfectly fine. The problem here looks like only EOP interrupts from the Compute queue are not correctly handled. Most likely a bug somewhere in gfx_v8_0_eop_irq(). Christian. Am 18.09.2018 um 16:36 schrieb Deucher, Alexander: FWIW, a number of co

Re: Regression on gfx8 with ring init

On 2018-09-18 10:31 a.m., Christian König wrote: Well looks like interrupt processing is working perfectly fine. But looking at the error message once more I see that this actually affects ring number 9 and not the GFX ring. Can you fix amdgpu_ib_ring_tests() to print ring->name instead of th

Re: Regression on gfx8 with ring init

FWIW, a number of consumer Raven boards have bad IVRS tables (windows doesn't use interrupt remapping so they are sometimes wrong and probably not validated. There are a number of workaround to manually override the IVRS tables to make interrupts work. I think specifying pci=noacpi is also a p

Re: Regression on gfx8 with ring init

Well looks like interrupt processing is working perfectly fine. But looking at the error message once more I see that this actually affects ring number 9 and not the GFX ring. Can you fix amdgpu_ib_ring_tests() to print ring->name instead of the number? That must be some of the compute ring

Re: [PATCH 1/2] drm/amd/pp: Honour DC's clock limits on Rv

Series is: Reviewed-by: Alex Deucher From: amd-gfx on behalf of Rex Zhu Sent: Tuesday, September 18, 2018 9:11:13 AM To: amd-gfx@lists.freedesktop.org Cc: Zhu, Rex Subject: [PATCH 1/2] drm/amd/pp: Honour DC's clock limits on Rv Honour display's request for mi

Re: [PATCH 1/2] drm/amdgpu: add vega20 sriov capability detection

Series is: Reviewed-by: Alex Deucher From: amd-gfx on behalf of Xiangliang Yu Sent: Tuesday, September 18, 2018 5:56:03 AM To: amd-gfx@lists.freedesktop.org Cc: Yu, Xiangliang; Min, Frank Subject: [PATCH 1/2] drm/amdgpu: add vega20 sriov capability detection

Re: Regression on gfx8 with ring init

On 2018-09-18 10:13 a.m., Christian König wrote: Mhm, there is no more failed IB-test in there isn't it? oh sorry I thought you wanted to test HEAD~ ... Attached is a log from the tip of drm-next Tom Christian. Am 18.09.2018 um 16:09 schrieb Tom St Denis: Disabling IOMMU in the BIOS res

Re: Regression on gfx8 with ring init

Mhm, there is no more failed IB-test in there isn't it? Christian. Am 18.09.2018 um 16:09 schrieb Tom St Denis: Disabling IOMMU in the BIOS resulted in a correct boot up... Here's the log. Tom On 2018-09-18 9:58 a.m., Tom St Denis wrote: Odd I couldn't even boot my system with the dGPU as pr

Re: Regression on gfx8 with ring init

Disabling IOMMU in the BIOS resulted in a correct boot up... Here's the log. Tom On 2018-09-18 9:58 a.m., Tom St Denis wrote: Odd I couldn't even boot my system with the dGPU as primary after rebuilding the kernel.  It got hung up in the IOMMU driver (loads of AMD-Vi IOMMU errors) which I was

Re: Regression on gfx8 with ring init

Odd I couldn't even boot my system with the dGPU as primary after rebuilding the kernel. It got hung up in the IOMMU driver (loads of AMD-Vi IOMMU errors) which I wasn't able to capture because it panic'ed before loading the network stack. Bizarre. I'll keep trying. Tom On 2018-09-18 9:35

Re: Regression on gfx8 with ring init

Am 18.09.2018 um 15:32 schrieb Tom St Denis: On 2018-09-18 9:30 a.m., Christian König wrote: Great, not sure if that is a good or a bad news. Anyway going to revert the change for now. Does anybody volunteer to figure out why interrupts sometimes doesn't work correctly on Raven? What does "d

Re: Regression on gfx8 with ring init

On 2018-09-18 9:30 a.m., Christian König wrote: Great, not sure if that is a good or a bad news. Anyway going to revert the change for now. Does anybody volunteer to figure out why interrupts sometimes doesn't work correctly on Raven? What does "doesn't work correctly?" My workstation is a R

Re: Regression on gfx8 with ring init

Great, not sure if that is a good or a bad news. Anyway going to revert the change for now. Does anybody volunteer to figure out why interrupts sometimes doesn't work correctly on Raven? Christian. Am 18.09.2018 um 15:27 schrieb Tom St Denis: This commit: [root@raven linux]# git bisect good

Regression on gfx8 with ring init

This commit: [root@raven linux]# git bisect good 9b0df0937a852d299fbe42a5939c9a8a4cc83c55 is the first bad commit commit 9b0df0937a852d299fbe42a5939c9a8a4cc83c55 Author: Christian König Date: Tue Sep 18 10:38:09 2018 +0200 drm/amdgpu: remove fence fallback DC doesn't seem to have a f

[PATCH 1/2] drm/amd/pp: Honour DC's clock limits on Rv

Honour display's request for min engine clock/memory clock. Signed-off-by: Rex Zhu --- drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c | 25 +++ 1 file changed, 17 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c b/drivers/gpu/d

[PATCH 2/2] drm/amd/pp: Return error immediately if load firmware failed

this can avoid hard hang and be useful for debug. Signed-off-by: Rex Zhu --- drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c b/drivers/gpu/drm/amd/powerplay/smumg

[PATCH 2/2] drm/amdgpu: Exclude MM engines for vega20 virtual device

From: Frank Min Temporary disable UVD/VCE block if is virtual device Signed-off-by: Frank Min Signed-off-by: Xiangliang Yu --- drivers/gpu/drm/amd/amdgpu/soc15.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/soc15.c b/drivers/gpu/drm/amd

[PATCH 1/2] drm/amdgpu: add vega20 sriov capability detection

From: Frank Min Add sriov capability detection for vega20, then can check if device is virtual device. Signed-off-by: Frank Min Signed-off-by: Xiangliang Yu --- drivers/gpu/drm/amd/amdgpu/nbio_v7_4.c | 15 +-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/drivers/

RE: [PATCH] drm/amdgpu: don't try to unreserve NULL pointer

Thanks. So we still need to check the bo valid before use for the case that if we don't know the size when allocate. Best Regards Rex > -Original Message- > From: Koenig, Christian > Sent: Tuesday, September 18, 2018 5:34 PM > To: Zhu, Rex ; amd-gfx@lists.freedesktop.org > Subject: Re:

Re: [PATCH] drm/amdgpu: don't try to unreserve NULL pointer

Am 18.09.2018 um 11:27 schrieb Zhu, Rex: -Original Message- From: Koenig, Christian Sent: Tuesday, September 18, 2018 4:41 PM To: Zhu, Rex ; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu: don't try to unreserve NULL pointer Am 18.09.2018 um 10:16 schrieb Zhu, Rex:

RE: [PATCH] drm/amdgpu: don't try to unreserve NULL pointer

> -Original Message- > From: Koenig, Christian > Sent: Tuesday, September 18, 2018 4:41 PM > To: Zhu, Rex ; amd-gfx@lists.freedesktop.org > Subject: Re: [PATCH] drm/amdgpu: don't try to unreserve NULL pointer > > Am 18.09.2018 um 10:16 schrieb Zhu, Rex: > > > >> -Original Message

RE: [PATCH] drm/amdgpu: remove fence fallback

> -Original Message- > From: amd-gfx On Behalf Of > Christian K?nig > Sent: Tuesday, September 18, 2018 4:43 PM > To: amd-gfx@lists.freedesktop.org > Subject: [PATCH] drm/amdgpu: remove fence fallback > > DC doesn't seem to have a fallback path either. > > So when interrupts doesn't wo

[PATCH] drm/amdgpu: remove fence fallback

DC doesn't seem to have a fallback path either. So when interrupts doesn't work any more we are pretty much busted no matter what. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 - drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 56 ---

Re: [PATCH] drm/amdgpu: don't try to unreserve NULL pointer

Am 18.09.2018 um 10:16 schrieb Zhu, Rex: -Original Message- From: Christian König Sent: Tuesday, September 18, 2018 3:14 PM To: Zhu, Rex ; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu: don't try to unreserve NULL pointer Am 18.09.2018 um 08:16 schrieb Zhu, Rex: -

Re: [PATCH 5/5] drm/amdgpu: fix shadow BO restoring

On Mon, Sep 17, 2018 at 07:42:38PM +0800, Christian König wrote: > Am 17.09.2018 um 11:10 schrieb Huang Rui: > > On Fri, Sep 14, 2018 at 03:42:57PM +0200, Christian König wrote: > >> Don't grab the reservation lock any more and simplify the handling quite > >> a bit. > >> > >> Signed-off-by: Christ

Re: [PATCH] [RFC]drm: add syncobj timeline support v5

Am 17.09.2018 um 11:33 schrieb zhoucm1: [SNIP]   +static struct dma_fence * +drm_syncobj_point_get(struct drm_syncobj *syncobj, u64 point, u64 flags) +{ +    struct dma_fence *fence; +    int ret = 0; + +    if (flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT) { +    ret = wait_event_timeou

RE: [PATCH] drm/amdgpu: don't try to unreserve NULL pointer

> -Original Message- > From: Christian König > Sent: Tuesday, September 18, 2018 3:14 PM > To: Zhu, Rex ; amd-gfx@lists.freedesktop.org > Subject: Re: [PATCH] drm/amdgpu: don't try to unreserve NULL pointer > > Am 18.09.2018 um 08:16 schrieb Zhu, Rex: > > > >> -Original Message-

Re: [PATCH] drm/amdgpu: don't try to unreserve NULL pointer

Am 17.09.2018 um 20:41 schrieb James Zhu: On 2018-09-17 02:07 PM, Christian König wrote: Don't try to unreserve a BO we doesn't allocated. Fixes: 07012fdd497e drm/amdgpu: don't allocate zero sized kernel BOs Signed-off-by: Christian König ---   drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 3

Re: [PATCH] drm/amdgpu: don't try to unreserve NULL pointer

Am 18.09.2018 um 08:16 schrieb Zhu, Rex: -Original Message- From: amd-gfx On Behalf Of Christian König Sent: Tuesday, September 18, 2018 2:07 AM To: amd-gfx@lists.freedesktop.org Subject: [PATCH] drm/amdgpu: don't try to unreserve NULL pointer Don't try to unreserve a BO we doesn't al