[linux-next:master] BUILD REGRESSION 4aa1da8d99724f6c0b762b58a71cee7c5e2e109b

2023-04-17 Thread kernel test robot
tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 4aa1da8d99724f6c0b762b58a71cee7c5e2e109b  Add linux-next specific 
files for 20230417

Error/Warning reports:

https://lore.kernel.org/oe-kbuild-all/202304102354.q4voxgte-...@intel.com

Error/Warning: (recently discovered and may have been fixed)

drivers/clk/clk-sp7021.c:316:8: warning: result of comparison of constant 
18446744073709551615 with expression of type 'typeof (_Generic((_m), char: 
(unsigned char)0, unsigned char: (unsigned char)0, signed char: (unsigned 
char)0, unsigned short: (unsigned short)0, short: (unsigned short)0, unsigned 
int: (unsigned int)0, int: (unsigned int)0, unsigned long: (unsigned long)0, 
long: (unsigned long)0, unsigned long long: (unsigned long long)0, long long: 
(unsigned long long)0, default: (_m)))' (aka 'unsigned int') is always false 
[-Wtautological-constant-out-of-range-compare]
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_validation.c:351:13: 
warning: variable 'bw_needed' set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_validation.c:352:25: 
warning: variable 'link' set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:62: warning: wrong kernel-doc 
identifier on line:
drivers/gpu/drm/i915/i915_pmu.h:41: warning: This comment starts with '/**', 
but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
drivers/gpu/drm/i915/i915_request.h:176: warning: This comment starts with 
'/**', but isn't a kernel-doc comment. Refer 
Documentation/doc-guide/kernel-doc.rst
drivers/gpu/drm/i915/i915_vma.h:145: warning: expecting prototype for 
i915_vma_offset(). Prototype was for i915_vma_size() instead
drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:298:6: warning: variable 'ret' is 
uninitialized when used here [-Wuninitialized]
nios2-linux-ld: phy-mtk-hdmi-mt8195.c:(.text+0x564): undefined reference to 
`__gesf2'
nios2-linux-ld: phy-mtk-hdmi-mt8195.c:(.text+0x584): undefined reference to 
`__ltsf2'
phy-mtk-hdmi-mt8195.c:(.text+0x550): undefined reference to `__floatunsisf'

Unverified Error/Warning (likely false positive, please contact us if 
interested):

drivers/acpi/property.c:985 acpi_data_prop_read_single() error: potentially 
dereferencing uninitialized 'obj'.
fs/xfs/scrub/refcount.c: xfs_mount.h is included more than once.
fs/xfs/scrub/refcount.c: xfs_trans_resv.h is included more than once.

Error/Warning ids grouped by kconfigs:

gcc_recent_errors
|-- alpha-allyesconfig
|   |-- 
drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
|   `-- 
drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
|-- arc-allyesconfig
|   |-- 
drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
|   `-- 
drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
|-- arm-allmodconfig
|   |-- 
drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
|   `-- 
drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
|-- arm-allyesconfig
|   |-- 
drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
|   `-- 
drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
|-- arm64-allyesconfig
|   |-- 
drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
|   `-- 
drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
|-- i386-allyesconfig
|   |-- 
drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
|   `-- 
drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
|-- i386-randconfig-m021-20230417
|   `-- 
drivers-acpi-property.c-acpi_data_prop_read_single()-error:potentially-dereferencing-uninitialized-obj-.
|-- ia64-allmodconfig
|   |-- 
drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
|   `-- 
drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
|-- ia64-randconfig-r002-20230416
|   |-- 
drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
|   `-- 
drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
|-- loongarch-allmodconfig
|   |-- 
drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
|   `-- 
drivers-gpu-drm-amd-a

[PATCH] drm/amdgpu: Enable doorbell selfring if resize BAR successfully

2023-04-17 Thread Shane Xiao
[Why]
The selfring doorbell aperture will change when we resize
FB BAR successfully during gmc sw init, we should reorder
the sequence of enabling doorbell selfring aperture.

[How]
Move enable_doorbell_selfring_aperture from *_common_hw_init
to *_common_late_init.

This fixes the potential issue that GPU ring its own
doorbell when this device is in translated mode with
iommu is on.

Signed-off-by: Shane Xiao 
Signed-off-by: Aaron Liu 
Tested-by: Xiaomeng Hou 
---
 drivers/gpu/drm/amd/amdgpu/nv.c| 4 +++-
 drivers/gpu/drm/amd/amdgpu/soc15.c | 4 +++-
 drivers/gpu/drm/amd/amdgpu/soc21.c | 4 +++-
 3 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c b/drivers/gpu/drm/amd/amdgpu/nv.c
index 47420b403871..f4c85634a4c8 100644
--- a/drivers/gpu/drm/amd/amdgpu/nv.c
+++ b/drivers/gpu/drm/amd/amdgpu/nv.c
@@ -535,7 +535,8 @@ static void nv_enable_doorbell_aperture(struct 
amdgpu_device *adev,
bool enable)
 {
adev->nbio.funcs->enable_doorbell_aperture(adev, enable);
-   adev->nbio.funcs->enable_doorbell_selfring_aperture(adev, enable);
+   if (!enable)
+   adev->nbio.funcs->enable_doorbell_selfring_aperture(adev, 
false);
 }
 
 const struct amdgpu_ip_block_version nv_common_ip_block =
@@ -999,6 +1000,7 @@ static int nv_common_late_init(void *handle)
}
}
 
+   adev->nbio.funcs->enable_doorbell_selfring_aperture(adev, true);
return 0;
 }
 
diff --git a/drivers/gpu/drm/amd/amdgpu/soc15.c 
b/drivers/gpu/drm/amd/amdgpu/soc15.c
index bc5dd80f10c1..0202de79a389 100644
--- a/drivers/gpu/drm/amd/amdgpu/soc15.c
+++ b/drivers/gpu/drm/amd/amdgpu/soc15.c
@@ -623,7 +623,8 @@ static void soc15_enable_doorbell_aperture(struct 
amdgpu_device *adev,
   bool enable)
 {
adev->nbio.funcs->enable_doorbell_aperture(adev, enable);
-   adev->nbio.funcs->enable_doorbell_selfring_aperture(adev, enable);
+   if (!enable)
+   adev->nbio.funcs->enable_doorbell_selfring_aperture(adev, 
false);
 }
 
 const struct amdgpu_ip_block_version vega10_common_ip_block =
@@ -1125,6 +1126,7 @@ static int soc15_common_late_init(void *handle)
if (amdgpu_sriov_vf(adev))
xgpu_ai_mailbox_get_irq(adev);
 
+   adev->nbio.funcs->enable_doorbell_selfring_aperture(adev, true);
return 0;
 }
 
diff --git a/drivers/gpu/drm/amd/amdgpu/soc21.c 
b/drivers/gpu/drm/amd/amdgpu/soc21.c
index 514bfc705d5a..cd4619085d67 100644
--- a/drivers/gpu/drm/amd/amdgpu/soc21.c
+++ b/drivers/gpu/drm/amd/amdgpu/soc21.c
@@ -454,7 +454,8 @@ static void soc21_enable_doorbell_aperture(struct 
amdgpu_device *adev,
bool enable)
 {
adev->nbio.funcs->enable_doorbell_aperture(adev, enable);
-   adev->nbio.funcs->enable_doorbell_selfring_aperture(adev, enable);
+   if (!enable)
+   adev->nbio.funcs->enable_doorbell_selfring_aperture(adev, 
false);
 }
 
 const struct amdgpu_ip_block_version soc21_common_ip_block =
@@ -764,6 +765,7 @@ static int soc21_common_late_init(void *handle)
amdgpu_irq_get(adev, 
&adev->nbio.ras_err_event_athub_irq, 0);
}
 
+   adev->nbio.funcs->enable_doorbell_selfring_aperture(adev, true);
return 0;
 }
 
-- 
2.25.1



[PATCH] drm/dp_mst: Clear MSG_RDY flag before sending new message

2023-04-17 Thread Wayne Lin
[Why & How]
The sequence for collecting down_reply/up_request from source
perspective should be:

Request_n->repeat (get partial reply of Request_n->clear message ready
flag to ack DPRX that the message is received) till all partial
replies for Request_n are received->new Request_n+1.

While assembling partial reply packets, reading out DPCD DOWN_REP
Sideband MSG buffer + clearing DOWN_REP_MSG_RDY flag should be
wrapped up as a complete operation for reading out a reply packet.
Kicking off a new request before clearing DOWN_REP_MSG_RDY flag might
be risky. e.g. If the reply of the new request has overwritten the
DPRX DOWN_REP Sideband MSG buffer before source writing ack to clear
DOWN_REP_MSG_RDY flag, source then unintentionally flushes the reply
for the new request. Should handle the up request in the same way.

In drm_dp_mst_hpd_irq(), we don't clear MSG_RDY flag before caliing
drm_dp_mst_kick_tx(). Fix that.

Signed-off-by: Wayne Lin 
Cc: sta...@vger.kernel.org
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  2 ++
 drivers/gpu/drm/display/drm_dp_mst_topology.c | 22 +++
 drivers/gpu/drm/i915/display/intel_dp.c   |  3 +++
 drivers/gpu/drm/nouveau/dispnv50/disp.c   |  2 ++
 4 files changed, 29 insertions(+)

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 77277d90b6e2..5313a5656598 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -3166,6 +3166,8 @@ static void dm_handle_mst_sideband_msg(struct 
amdgpu_dm_connector *aconnector)
for (retry = 0; retry < 3; retry++) {
uint8_t wret;
 
+   /* MSG_RDY ack is done in drm*/
+   esi[1] &= ~(DP_DOWN_REP_MSG_RDY | 
DP_UP_REQ_MSG_RDY);
wret = drm_dp_dpcd_write(
&aconnector->dm_dp_aux.aux,
dpcd_addr + 1,
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c 
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 51a46689cda7..02aad713c67c 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -4054,6 +4054,9 @@ int drm_dp_mst_hpd_irq(struct drm_dp_mst_topology_mgr 
*mgr, u8 *esi, bool *handl
 {
int ret = 0;
int sc;
+   const int tosend = 1;
+   int retries = 0;
+   u8 buf = 0;
*handled = false;
sc = DP_GET_SINK_COUNT(esi[0]);
 
@@ -4072,6 +4075,25 @@ int drm_dp_mst_hpd_irq(struct drm_dp_mst_topology_mgr 
*mgr, u8 *esi, bool *handl
*handled = true;
}
 
+   if (*handled) {
+   buf = esi[1] & (DP_DOWN_REP_MSG_RDY | DP_UP_REQ_MSG_RDY);
+   do {
+   ret = drm_dp_dpcd_write(mgr->aux,
+   
DP_DEVICE_SERVICE_IRQ_VECTOR_ESI0,
+   &buf,
+   tosend);
+
+   if (ret == tosend)
+   break;
+
+   retries++;
+   } while (retries < 5);
+
+   if (ret != tosend)
+   drm_dbg_kms(mgr->dev, "failed to write dpcd 0x%x\n",
+   DP_DEVICE_SERVICE_IRQ_VECTOR_ESI0);
+   }
+
drm_dp_mst_kick_tx(mgr);
return ret;
 }
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index bf80f296a8fd..abec3de38b66 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3939,6 +3939,9 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
if (!memchr_inv(ack, 0, sizeof(ack)))
break;
 
+   /* MSG_RDY ack is done in drm*/
+   ack[1] &= ~(DP_DOWN_REP_MSG_RDY | DP_UP_REQ_MSG_RDY);
+
if (!intel_dp_ack_sink_irq_esi(intel_dp, ack))
drm_dbg_kms(&i915->drm, "Failed to ack ESI\n");
}
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index edcb2529b402..e905987104ed 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1336,6 +1336,8 @@ nv50_mstm_service(struct nouveau_drm *drm,
if (!handled)
break;
 
+   /* MSG_RDY ack is done in drm*/
+   esi[1] &= ~(DP_DOWN_REP_MSG_RDY | DP_UP_REQ_MSG_RDY);
rc = drm_dp_dpcd_write(aux, DP_SINK_COUNT_ESI + 1, &esi[1],
   3);
if (rc != 3) {
-- 
2.37.3



[PATCH] [v2] drm/amd/display: fix is_timing_changed() prototype

2023-04-17 Thread Arnd Bergmann
From: Arnd Bergmann 

Three functions in the amdgpu display driver cause -Wmissing-prototype
warnings:

drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1858:6: error: no 
previous prototype for 'is_timing_changed' [-Werror=missing-prototypes]

is_timing_changed() is actually meant to be a global symbol, but needs
a proper name and prototype.

Fixes: 17ce8a6907f7 ("drm/amd/display: Add dsc pre-validation in atomic check")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 5 ++---
 drivers/gpu/drm/amd/display/dc/core/dc_resource.c   | 6 +++---
 drivers/gpu/drm/amd/display/dc/dc.h | 3 +++
 3 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 994ba426ca66..442511061178 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -45,8 +45,7 @@
 #endif
 
 #include "dc/dcn20/dcn20_resource.h"
-bool is_timing_changed(struct dc_stream_state *cur_stream,
-  struct dc_stream_state *new_stream);
+
 #define PEAK_FACTOR_X1000 1006
 
 static ssize_t dm_dp_aux_transfer(struct drm_dp_aux *aux,
@@ -1417,7 +1416,7 @@ int pre_validate_dsc(struct drm_atomic_state *state,
struct dc_stream_state *stream = dm_state->context->streams[i];
 
if (local_dc_state->streams[i] &&
-   is_timing_changed(stream, local_dc_state->streams[i])) {
+   dc_is_timing_changed(stream, local_dc_state->streams[i])) {
DRM_INFO_ONCE("crtc[%d] needs mode_changed\n", i);
} else {
int ind = find_crtc_index_in_state_by_stream(state, 
stream);
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
index 85d54bfb595c..344533623cb9 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
@@ -1855,7 +1855,7 @@ bool dc_add_all_planes_for_stream(
return add_all_planes_for_stream(dc, stream, &set, 1, context);
 }
 
-bool is_timing_changed(struct dc_stream_state *cur_stream,
+bool dc_is_timing_changed(struct dc_stream_state *cur_stream,
   struct dc_stream_state *new_stream)
 {
if (cur_stream == NULL)
@@ -1880,7 +1880,7 @@ static bool are_stream_backends_same(
if (stream_a == NULL || stream_b == NULL)
return false;
 
-   if (is_timing_changed(stream_a, stream_b))
+   if (dc_is_timing_changed(stream_a, stream_b))
return false;
 
if (stream_a->signal != stream_b->signal)
@@ -3505,7 +3505,7 @@ bool pipe_need_reprogram(
if (pipe_ctx_old->stream_res.stream_enc != 
pipe_ctx->stream_res.stream_enc)
return true;
 
-   if (is_timing_changed(pipe_ctx_old->stream, pipe_ctx->stream))
+   if (dc_is_timing_changed(pipe_ctx_old->stream, pipe_ctx->stream))
return true;
 
if (pipe_ctx_old->stream->dpms_off != pipe_ctx->stream->dpms_off)
diff --git a/drivers/gpu/drm/amd/display/dc/dc.h 
b/drivers/gpu/drm/amd/display/dc/dc.h
index 23ee63b98dcd..e7ab6cb3769b 100644
--- a/drivers/gpu/drm/amd/display/dc/dc.h
+++ b/drivers/gpu/drm/amd/display/dc/dc.h
@@ -2225,4 +2225,7 @@ void dc_process_dmub_dpia_hpd_int_enable(const struct dc 
*dc,
 /* Disable acc mode Interfaces */
 void dc_disable_accelerated_mode(struct dc *dc);
 
+bool dc_is_timing_changed(struct dc_stream_state *cur_stream,
+  struct dc_stream_state *new_stream);
+
 #endif /* DC_INTERFACE_H_ */
-- 
2.39.2



Re: [PATCH 1/2] drm/amd/display: mark dccg314_init() static

2023-04-17 Thread Arnd Bergmann
On Mon, Apr 17, 2023, at 23:12, Hamza Mahfooz wrote:
> On 4/17/23 17:05, Arnd Bergmann wrote:
>> From: Arnd Bergmann 
>> 
>> The newly introduced global function is not declared in a header or
>> called from another file, causing a harmless warning with sparse
>> or W=1 builds:
>> 
>> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn314/dcn314_dccg.c:277:6: error: 
>> no previous prototype for 'dccg314_init' [-Werror=missing-prototypes]
>> 
>> Mark it static instead.
>> 
>> Fixes: 6f6869dcf415 ("drm/amd/display: prep work for root clock optimization 
>> enablement for DCN314")
>> Signed-off-by: Arnd Bergmann 
>
> This has already been fixed as of commit 669f4ac40947 ("drm/amd/display:
> set variable dccg314_init storage-class-specifier to static") in
> amd-staging-drm-next.

Ok, thanks. I waited for a rebase on today's linux-next before posting
mine to make sure it's not already fixed, it must have just missed the
cut-off.

  Arnd


Re: [PATCH 2/2] drm/amd/display: fix missing=prototypes warnings

2023-04-17 Thread Hamza Mahfooz

On 4/17/23 17:05, Arnd Bergmann wrote:

From: Arnd Bergmann 

Three functions in the amdgpu display driver cause -Wmissing-prototype
warnings:

drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1858:6: error: no 
previous prototype for 'is_timing_changed' [-Werror=missing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:210:6: 
error: no previous prototype for 'is_synaptics_cascaded_panamera' 
[-Werror=missing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_optc.c:294:6: error: no 
previous prototype for 'optc3_wait_drr_doublebuffer_pending_clear' 
[-Werror=missing-prototypes]

is_timing_changed() is actually meant to be a global symbol, but needs
a proper name and prototype, while the other two can just be made static.

Fixes: 54c7b715b5ef ("drm/amd/display: Add DSC Support for Synaptics Cascaded MST 
Hub")
Fixes: 17ce8a6907f7 ("drm/amd/display: Add dsc pre-validation in atomic check")
Fixes: 8f0d304d21b3 ("drm/amd/display: Do not commit pipe when updating DRR")
Signed-off-by: Arnd Bergmann 


It seems like, only the changes for is_timing_changed() are in this patch.


---
  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 5 ++---
  drivers/gpu/drm/amd/display/dc/core/dc_resource.c   | 6 +++---
  drivers/gpu/drm/amd/display/dc/dc.h | 3 +++
  3 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 994ba426ca66..442511061178 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -45,8 +45,7 @@
  #endif
  
  #include "dc/dcn20/dcn20_resource.h"

-bool is_timing_changed(struct dc_stream_state *cur_stream,
-  struct dc_stream_state *new_stream);
+
  #define PEAK_FACTOR_X1000 1006
  
  static ssize_t dm_dp_aux_transfer(struct drm_dp_aux *aux,

@@ -1417,7 +1416,7 @@ int pre_validate_dsc(struct drm_atomic_state *state,
struct dc_stream_state *stream = dm_state->context->streams[i];
  
  		if (local_dc_state->streams[i] &&

-   is_timing_changed(stream, local_dc_state->streams[i])) {
+   dc_is_timing_changed(stream, local_dc_state->streams[i])) {
DRM_INFO_ONCE("crtc[%d] needs mode_changed\n", i);
} else {
int ind = find_crtc_index_in_state_by_stream(state, 
stream);
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
index 85d54bfb595c..344533623cb9 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
@@ -1855,7 +1855,7 @@ bool dc_add_all_planes_for_stream(
return add_all_planes_for_stream(dc, stream, &set, 1, context);
  }
  
-bool is_timing_changed(struct dc_stream_state *cur_stream,

+bool dc_is_timing_changed(struct dc_stream_state *cur_stream,
   struct dc_stream_state *new_stream)
  {
if (cur_stream == NULL)
@@ -1880,7 +1880,7 @@ static bool are_stream_backends_same(
if (stream_a == NULL || stream_b == NULL)
return false;
  
-	if (is_timing_changed(stream_a, stream_b))

+   if (dc_is_timing_changed(stream_a, stream_b))
return false;
  
  	if (stream_a->signal != stream_b->signal)

@@ -3505,7 +3505,7 @@ bool pipe_need_reprogram(
if (pipe_ctx_old->stream_res.stream_enc != 
pipe_ctx->stream_res.stream_enc)
return true;
  
-	if (is_timing_changed(pipe_ctx_old->stream, pipe_ctx->stream))

+   if (dc_is_timing_changed(pipe_ctx_old->stream, pipe_ctx->stream))
return true;
  
  	if (pipe_ctx_old->stream->dpms_off != pipe_ctx->stream->dpms_off)

diff --git a/drivers/gpu/drm/amd/display/dc/dc.h 
b/drivers/gpu/drm/amd/display/dc/dc.h
index 23ee63b98dcd..e7ab6cb3769b 100644
--- a/drivers/gpu/drm/amd/display/dc/dc.h
+++ b/drivers/gpu/drm/amd/display/dc/dc.h
@@ -2225,4 +2225,7 @@ void dc_process_dmub_dpia_hpd_int_enable(const struct dc 
*dc,
  /* Disable acc mode Interfaces */
  void dc_disable_accelerated_mode(struct dc *dc);
  
+bool dc_is_timing_changed(struct dc_stream_state *cur_stream,

+  struct dc_stream_state *new_stream);
+
  #endif /* DC_INTERFACE_H_ */

--
Hamza



Re: [PATCH 1/2] drm/amd/display: mark dccg314_init() static

2023-04-17 Thread Hamza Mahfooz



On 4/17/23 17:05, Arnd Bergmann wrote:

From: Arnd Bergmann 

The newly introduced global function is not declared in a header or
called from another file, causing a harmless warning with sparse
or W=1 builds:

drivers/gpu/drm/amd/amdgpu/../display/dc/dcn314/dcn314_dccg.c:277:6: error: no 
previous prototype for 'dccg314_init' [-Werror=missing-prototypes]

Mark it static instead.

Fixes: 6f6869dcf415 ("drm/amd/display: prep work for root clock optimization 
enablement for DCN314")
Signed-off-by: Arnd Bergmann 


This has already been fixed as of commit 669f4ac40947 ("drm/amd/display:
set variable dccg314_init storage-class-specifier to static") in
amd-staging-drm-next.


---
  drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c 
b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c
index 6f879265ad9c..de7bfba2c179 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c
@@ -274,7 +274,7 @@ static void dccg314_set_dpstreamclk(
}
  }
  
-void dccg314_init(struct dccg *dccg)

+static void dccg314_init(struct dccg *dccg)
  {
int otg_inst;
  

--
Hamza



[PATCH 2/2] drm/amd/display: fix missing=prototypes warnings

2023-04-17 Thread Arnd Bergmann
From: Arnd Bergmann 

Three functions in the amdgpu display driver cause -Wmissing-prototype
warnings:

drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1858:6: error: no 
previous prototype for 'is_timing_changed' [-Werror=missing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:210:6: 
error: no previous prototype for 'is_synaptics_cascaded_panamera' 
[-Werror=missing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_optc.c:294:6: error: no 
previous prototype for 'optc3_wait_drr_doublebuffer_pending_clear' 
[-Werror=missing-prototypes]

is_timing_changed() is actually meant to be a global symbol, but needs
a proper name and prototype, while the other two can just be made static.

Fixes: 54c7b715b5ef ("drm/amd/display: Add DSC Support for Synaptics Cascaded 
MST Hub")
Fixes: 17ce8a6907f7 ("drm/amd/display: Add dsc pre-validation in atomic check")
Fixes: 8f0d304d21b3 ("drm/amd/display: Do not commit pipe when updating DRR")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 5 ++---
 drivers/gpu/drm/amd/display/dc/core/dc_resource.c   | 6 +++---
 drivers/gpu/drm/amd/display/dc/dc.h | 3 +++
 3 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 994ba426ca66..442511061178 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -45,8 +45,7 @@
 #endif
 
 #include "dc/dcn20/dcn20_resource.h"
-bool is_timing_changed(struct dc_stream_state *cur_stream,
-  struct dc_stream_state *new_stream);
+
 #define PEAK_FACTOR_X1000 1006
 
 static ssize_t dm_dp_aux_transfer(struct drm_dp_aux *aux,
@@ -1417,7 +1416,7 @@ int pre_validate_dsc(struct drm_atomic_state *state,
struct dc_stream_state *stream = dm_state->context->streams[i];
 
if (local_dc_state->streams[i] &&
-   is_timing_changed(stream, local_dc_state->streams[i])) {
+   dc_is_timing_changed(stream, local_dc_state->streams[i])) {
DRM_INFO_ONCE("crtc[%d] needs mode_changed\n", i);
} else {
int ind = find_crtc_index_in_state_by_stream(state, 
stream);
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
index 85d54bfb595c..344533623cb9 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
@@ -1855,7 +1855,7 @@ bool dc_add_all_planes_for_stream(
return add_all_planes_for_stream(dc, stream, &set, 1, context);
 }
 
-bool is_timing_changed(struct dc_stream_state *cur_stream,
+bool dc_is_timing_changed(struct dc_stream_state *cur_stream,
   struct dc_stream_state *new_stream)
 {
if (cur_stream == NULL)
@@ -1880,7 +1880,7 @@ static bool are_stream_backends_same(
if (stream_a == NULL || stream_b == NULL)
return false;
 
-   if (is_timing_changed(stream_a, stream_b))
+   if (dc_is_timing_changed(stream_a, stream_b))
return false;
 
if (stream_a->signal != stream_b->signal)
@@ -3505,7 +3505,7 @@ bool pipe_need_reprogram(
if (pipe_ctx_old->stream_res.stream_enc != 
pipe_ctx->stream_res.stream_enc)
return true;
 
-   if (is_timing_changed(pipe_ctx_old->stream, pipe_ctx->stream))
+   if (dc_is_timing_changed(pipe_ctx_old->stream, pipe_ctx->stream))
return true;
 
if (pipe_ctx_old->stream->dpms_off != pipe_ctx->stream->dpms_off)
diff --git a/drivers/gpu/drm/amd/display/dc/dc.h 
b/drivers/gpu/drm/amd/display/dc/dc.h
index 23ee63b98dcd..e7ab6cb3769b 100644
--- a/drivers/gpu/drm/amd/display/dc/dc.h
+++ b/drivers/gpu/drm/amd/display/dc/dc.h
@@ -2225,4 +2225,7 @@ void dc_process_dmub_dpia_hpd_int_enable(const struct dc 
*dc,
 /* Disable acc mode Interfaces */
 void dc_disable_accelerated_mode(struct dc *dc);
 
+bool dc_is_timing_changed(struct dc_stream_state *cur_stream,
+  struct dc_stream_state *new_stream);
+
 #endif /* DC_INTERFACE_H_ */
-- 
2.39.2



[PATCH 1/2] drm/amd/display: mark dccg314_init() static

2023-04-17 Thread Arnd Bergmann
From: Arnd Bergmann 

The newly introduced global function is not declared in a header or
called from another file, causing a harmless warning with sparse
or W=1 builds:

drivers/gpu/drm/amd/amdgpu/../display/dc/dcn314/dcn314_dccg.c:277:6: error: no 
previous prototype for 'dccg314_init' [-Werror=missing-prototypes]

Mark it static instead.

Fixes: 6f6869dcf415 ("drm/amd/display: prep work for root clock optimization 
enablement for DCN314")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c 
b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c
index 6f879265ad9c..de7bfba2c179 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c
@@ -274,7 +274,7 @@ static void dccg314_set_dpstreamclk(
}
 }
 
-void dccg314_init(struct dccg *dccg)
+static void dccg314_init(struct dccg *dccg)
 {
int otg_inst;
 
-- 
2.39.2



[PATCH] drm/radeon: move prototypes to header

2023-04-17 Thread Arnd Bergmann
From: Arnd Bergmann 

Global functions in radeon_atpx_handler.c are not declared in a header
but instead in each file using them. This risks the types getting out
of sync and causes warnings:

drivers/gpu/drm/radeon/radeon_atpx_handler.c:64:6: error: no previous prototype 
for 'radeon_has_atpx' [-Werror=missing-prototypes]
drivers/gpu/drm/radeon/radeon_atpx_handler.c:68:6: error: no previous prototype 
for 'radeon_has_atpx_dgpu_power_cntl' [-Werror=missing-prototypes]
drivers/gpu/drm/radeon/radeon_atpx_handler.c:72:6: error: no previous prototype 
for 'radeon_is_atpx_hybrid' [-Werror=missing-prototypes]
drivers/gpu/drm/radeon/radeon_atpx_handler.c:76:6: error: no previous prototype 
for 'radeon_atpx_dgpu_req_power_for_displays' [-Werror=missing-prototypes]
drivers/gpu/drm/radeon/radeon_atpx_handler.c:594:6: error: no previous 
prototype for 'radeon_register_atpx_handler' [-Werror=missing-prototypes]
drivers/gpu/drm/radeon/radeon_atpx_handler.c:612:6: error: no previous 
prototype for 'radeon_unregister_atpx_handler' [-Werror=missing-prototypes]

Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/radeon/radeon.h  | 18 ++
 drivers/gpu/drm/radeon/radeon_acpi.c |  6 --
 drivers/gpu/drm/radeon/radeon_atpx_handler.c |  1 +
 drivers/gpu/drm/radeon/radeon_device.c   |  8 
 drivers/gpu/drm/radeon/radeon_drv.c  | 13 -
 drivers/gpu/drm/radeon/radeon_kms.c  |  6 --
 6 files changed, 19 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 8afb03bbce29..74fb4dfc3e5e 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2964,6 +2964,24 @@ void radeon_irq_kms_set_irq_n_enabled(struct 
radeon_device *rdev,
 void radeon_audio_component_init(struct radeon_device *rdev);
 void radeon_audio_component_fini(struct radeon_device *rdev);
 
+/* atpx handler */
+#if defined(CONFIG_VGA_SWITCHEROO)
+bool radeon_has_atpx(void);
+void radeon_register_atpx_handler(void);
+void radeon_unregister_atpx_handler(void);
+bool radeon_has_atpx_dgpu_power_cntl(void);
+bool radeon_is_atpx_hybrid(void);
+bool radeon_atpx_dgpu_req_power_for_displays(void);
+#else
+static inline bool radeon_has_atpx(void) { return false; }
+static inline void radeon_register_atpx_handler(void) {}
+static inline void radeon_unregister_atpx_handler(void) {}
+static inline bool radeon_has_atpx_dgpu_power_cntl(void) { return false; }
+static inline bool radeon_is_atpx_hybrid(void) { return false; }
+static inline bool radeon_atpx_dgpu_req_power_for_displays(void) { return 
false; }
+#endif
+
+
 #include "radeon_object.h"
 
 #endif
diff --git a/drivers/gpu/drm/radeon/radeon_acpi.c 
b/drivers/gpu/drm/radeon/radeon_acpi.c
index 5771d1fcb073..695c673eb9f6 100644
--- a/drivers/gpu/drm/radeon/radeon_acpi.c
+++ b/drivers/gpu/drm/radeon/radeon_acpi.c
@@ -38,12 +38,6 @@
 #include "radeon_acpi.h"
 #include "radeon_pm.h"
 
-#if defined(CONFIG_VGA_SWITCHEROO)
-bool radeon_atpx_dgpu_req_power_for_displays(void);
-#else
-static inline bool radeon_atpx_dgpu_req_power_for_displays(void) { return 
false; }
-#endif
-
 #define ACPI_AC_CLASS   "ac_adapter"
 
 struct atif_verify_interface {
diff --git a/drivers/gpu/drm/radeon/radeon_atpx_handler.c 
b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
index 6f93f54bf651..dfd30558f8e8 100644
--- a/drivers/gpu/drm/radeon/radeon_atpx_handler.c
+++ b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
@@ -12,6 +12,7 @@
 #include 
 
 #include "radeon_acpi.h"
+#include "radeon.h"
 
 struct radeon_atpx_functions {
bool px_params;
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index afbb3a80c0c6..180f8aa971b4 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -113,14 +113,6 @@ static const char radeon_family_name[][16] = {
"LAST",
 };
 
-#if defined(CONFIG_VGA_SWITCHEROO)
-bool radeon_has_atpx_dgpu_power_cntl(void);
-bool radeon_is_atpx_hybrid(void);
-#else
-static inline bool radeon_has_atpx_dgpu_power_cntl(void) { return false; }
-static inline bool radeon_is_atpx_hybrid(void) { return false; }
-#endif
-
 #define RADEON_PX_QUIRK_DISABLE_PX  (1 << 0)
 
 struct radeon_px_quirk {
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index e4374814f0ef..d8d75b347678 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -128,19 +128,6 @@ int radeon_mode_dumb_create(struct drm_file *file_priv,
struct drm_device *dev,
struct drm_mode_create_dumb *args);
 
-/* atpx handler */
-#if defined(CONFIG_VGA_SWITCHEROO)
-void radeon_register_atpx_handler(void);
-void radeon_unregister_atpx_handler(void);
-bool radeon_has_atpx_dgpu_power_cntl(void);
-bool radeon_is_atpx_hybrid(void);
-#else
-static inline void radeon_register_atpx_handler(void) {}
-static 

[PATCH v2] drm/amd/display: fix flickering caused by S/G mode

2023-04-17 Thread Hamza Mahfooz
Currently, on a handful of ASICs. We allow the framebuffer for a given
plane to exist in either VRAM or GTT. However, if the plane's new
framebuffer is in a different memory domain than it's previous
framebuffer, flipping between them can cause the screen to flicker. So,
to fix this, don't perform an immediate flip in the aforementioned case.

Cc: sta...@vger.kernel.org
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2354
Fixes: 81d0bcf99009 ("drm/amdgpu: make display pinning more flexible (v2)")
Signed-off-by: Hamza Mahfooz 
---
v2: make a number of clarifications to the commit message and drop
locking.
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c| 16 ++--
 1 file changed, 14 insertions(+), 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 da3045fdcb6d..fd1b323f0e85 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7897,6 +7897,13 @@ static void amdgpu_dm_commit_cursors(struct 
drm_atomic_state *state)
amdgpu_dm_plane_handle_cursor_update(plane, 
old_plane_state);
 }
 
+static inline uint32_t get_mem_type(struct drm_framebuffer *fb)
+{
+   struct amdgpu_bo *abo = gem_to_amdgpu_bo(fb->obj[0]);
+
+   return abo->tbo.resource ? abo->tbo.resource->mem_type : 0;
+}
+
 static void amdgpu_dm_commit_planes(struct drm_atomic_state *state,
struct dc_state *dc_state,
struct drm_device *dev,
@@ -7916,6 +7923,7 @@ static void amdgpu_dm_commit_planes(struct 
drm_atomic_state *state,
to_dm_crtc_state(drm_atomic_get_old_crtc_state(state, 
pcrtc));
int planes_count = 0, vpos, hpos;
unsigned long flags;
+   uint32_t mem_type;
u32 target_vblank, last_flip_vblank;
bool vrr_active = amdgpu_dm_crtc_vrr_active(acrtc_state);
bool cursor_update = false;
@@ -8035,13 +8043,17 @@ static void amdgpu_dm_commit_planes(struct 
drm_atomic_state *state,
}
}
 
+   mem_type = get_mem_type(old_plane_state->fb);
+
/*
 * Only allow immediate flips for fast updates that don't
-* change FB pitch, DCC state, rotation or mirroing.
+* change memory domain, FB pitch, DCC state, rotation or
+* mirroring.
 */
bundle->flip_addrs[planes_count].flip_immediate =
crtc->state->async_flip &&
-   acrtc_state->update_type == UPDATE_TYPE_FAST;
+   acrtc_state->update_type == UPDATE_TYPE_FAST &&
+   (!mem_type || get_mem_type(fb) == mem_type);
 
timestamp_ns = ktime_get_ns();
bundle->flip_addrs[planes_count].flip_timestamp_in_us = 
div_u64(timestamp_ns, 1000);
-- 
2.40.0



Re: [PATCH v2] radeon: avoid double free in ci_dpm_init()

2023-04-17 Thread Alex Deucher
Thanks.  Applied!

Alex

On Thu, Apr 13, 2023 at 11:12 AM Nikita Zhandarovich
 wrote:
>
> Several calls to ci_dpm_fini() will attempt to free resources that
> either have been freed before or haven't been allocated yet. This
> may lead to undefined or dangerous behaviour.
>
> For instance, if r600_parse_extended_power_table() fails, it might
> call r600_free_extended_power_table() as will ci_dpm_fini() later
> during error handling.
>
> Fix this by only freeing pointers to objects previously allocated.
>
> Found by Linux Verification Center (linuxtesting.org) with static
> analysis tool SVACE.
>
> Fixes: cc8dbbb4f62a ("drm/radeon: add dpm support for CI dGPUs (v2)")
> Cc: sta...@vger.kernel.org
> Co-developed-by: Natalia Petrova 
> Signed-off-by: Nikita Zhandarovich 
> ---
> v2: free only resouces allocated prior, do not remove ci_dpm_fini()
> or other deallocating calls altogether; fix commit message.
> v1: 
> https://lore.kernel.org/all/20230403182808.8699-1-n.zhandarov...@fintech.ru/
>
>  drivers/gpu/drm/radeon/ci_dpm.c | 28 
>  1 file changed, 20 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
> index 8ef25ab305ae..b8f4dac68d85 100644
> --- a/drivers/gpu/drm/radeon/ci_dpm.c
> +++ b/drivers/gpu/drm/radeon/ci_dpm.c
> @@ -5517,6 +5517,7 @@ static int ci_parse_power_table(struct radeon_device 
> *rdev)
> u8 frev, crev;
> u8 *power_state_offset;
> struct ci_ps *ps;
> +   int ret;
>
> if (!atom_parse_data_header(mode_info->atom_context, index, NULL,
>&frev, &crev, &data_offset))
> @@ -5546,11 +5547,15 @@ static int ci_parse_power_table(struct radeon_device 
> *rdev)
> non_clock_array_index = power_state->v2.nonClockInfoIndex;
> non_clock_info = (struct _ATOM_PPLIB_NONCLOCK_INFO *)
> 
> &non_clock_info_array->nonClockInfo[non_clock_array_index];
> -   if (!rdev->pm.power_state[i].clock_info)
> -   return -EINVAL;
> +   if (!rdev->pm.power_state[i].clock_info) {
> +   ret = -EINVAL;
> +   goto err_free_ps;
> +   }
> ps = kzalloc(sizeof(struct ci_ps), GFP_KERNEL);
> -   if (ps == NULL)
> -   return -ENOMEM;
> +   if (ps == NULL) {
> +   ret = -ENOMEM;
> +   goto err_free_ps;
> +   }
> rdev->pm.dpm.ps[i].ps_priv = ps;
> ci_parse_pplib_non_clock_info(rdev, &rdev->pm.dpm.ps[i],
>   non_clock_info,
> @@ -5590,6 +5595,12 @@ static int ci_parse_power_table(struct radeon_device 
> *rdev)
> }
>
> return 0;
> +
> +err_free_ps:
> +   for (i = 0; i < rdev->pm.dpm.num_ps; i++)
> +   kfree(rdev->pm.dpm.ps[i].ps_priv);
> +   kfree(rdev->pm.dpm.ps);
> +   return ret;
>  }
>
>  static int ci_get_vbios_boot_values(struct radeon_device *rdev,
> @@ -5678,25 +5689,26 @@ int ci_dpm_init(struct radeon_device *rdev)
>
> ret = ci_get_vbios_boot_values(rdev, &pi->vbios_boot_state);
> if (ret) {
> -   ci_dpm_fini(rdev);
> +   kfree(rdev->pm.dpm.priv);
> return ret;
> }
>
> ret = r600_get_platform_caps(rdev);
> if (ret) {
> -   ci_dpm_fini(rdev);
> +   kfree(rdev->pm.dpm.priv);
> return ret;
> }
>
> ret = r600_parse_extended_power_table(rdev);
> if (ret) {
> -   ci_dpm_fini(rdev);
> +   kfree(rdev->pm.dpm.priv);
> return ret;
> }
>
> ret = ci_parse_power_table(rdev);
> if (ret) {
> -   ci_dpm_fini(rdev);
> +   kfree(rdev->pm.dpm.priv);
> +   r600_free_extended_power_table(rdev);
> return ret;
> }
>


Re: [PATCH] drm/amd/display: remove unused variable oldest_index

2023-04-17 Thread Alex Deucher
Applied.  Thanks!

On Fri, Apr 14, 2023 at 11:08 AM Tom Rix  wrote:
>
> cpp_check reports
> drivers/gpu/drm/amd/display/modules/freesync/freesync.c:1143:17: style: 
> Variable
>   'oldest_index' is assigned a value that is never used. [unreadVariable]
>oldest_index = 0;
> ^
>
> This variable is not used so remove.
>
> Signed-off-by: Tom Rix 
> ---
>  drivers/gpu/drm/amd/display/modules/freesync/freesync.c | 4 
>  1 file changed, 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c 
> b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
> index 5c41a4751db4..5798c0eafa1f 100644
> --- a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
> +++ b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
> @@ -1137,10 +1137,6 @@ void mod_freesync_handle_preflip(struct mod_freesync 
> *mod_freesync,
>
> if (in_out_vrr->supported &&
> in_out_vrr->state == VRR_STATE_ACTIVE_VARIABLE) {
> -   unsigned int oldest_index = plane->time.index + 1;
> -
> -   if (oldest_index >= DC_PLANE_UPDATE_TIMES_MAX)
> -   oldest_index = 0;
>
> last_render_time_in_us = curr_time_stamp_in_us -
> plane->time.prev_update_time_in_us;
> --
> 2.27.0
>


Re: [PATCH][next] drm/amd/pm: Fix spelling mistake "aquire" -> "acquire"

2023-04-17 Thread Alex Deucher
Applied.  Thanks!

Alex

On Mon, Apr 17, 2023 at 1:42 PM Colin Ian King  wrote:
>
> There is a spelling mistake in the smu_i2c_bus_access prototype. Fix it.
>
> Signed-off-by: Colin Ian King 
> ---
>  drivers/gpu/drm/amd/pm/powerplay/inc/hwmgr.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/powerplay/inc/hwmgr.h 
> b/drivers/gpu/drm/amd/pm/powerplay/inc/hwmgr.h
> index 5ce433e2c16a..f1580a26a850 100644
> --- a/drivers/gpu/drm/amd/pm/powerplay/inc/hwmgr.h
> +++ b/drivers/gpu/drm/amd/pm/powerplay/inc/hwmgr.h
> @@ -359,7 +359,7 @@ struct pp_hwmgr_func {
> int (*set_ppfeature_status)(struct pp_hwmgr *hwmgr, uint64_t 
> ppfeature_masks);
> int (*set_mp1_state)(struct pp_hwmgr *hwmgr, enum pp_mp1_state 
> mp1_state);
> int (*asic_reset)(struct pp_hwmgr *hwmgr, enum SMU_ASIC_RESET_MODE 
> mode);
> -   int (*smu_i2c_bus_access)(struct pp_hwmgr *hwmgr, bool aquire);
> +   int (*smu_i2c_bus_access)(struct pp_hwmgr *hwmgr, bool acquire);
> int (*set_df_cstate)(struct pp_hwmgr *hwmgr, enum pp_df_cstate state);
> int (*set_xgmi_pstate)(struct pp_hwmgr *hwmgr, uint32_t pstate);
> int (*disable_power_features_for_compute_performance)(struct pp_hwmgr 
> *hwmgr,
> --
> 2.30.2
>


[PATCH][next] drm/amd/pm: Fix spelling mistake "aquire" -> "acquire"

2023-04-17 Thread Colin Ian King
There is a spelling mistake in the smu_i2c_bus_access prototype. Fix it.

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/amd/pm/powerplay/inc/hwmgr.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/pm/powerplay/inc/hwmgr.h 
b/drivers/gpu/drm/amd/pm/powerplay/inc/hwmgr.h
index 5ce433e2c16a..f1580a26a850 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/inc/hwmgr.h
+++ b/drivers/gpu/drm/amd/pm/powerplay/inc/hwmgr.h
@@ -359,7 +359,7 @@ struct pp_hwmgr_func {
int (*set_ppfeature_status)(struct pp_hwmgr *hwmgr, uint64_t 
ppfeature_masks);
int (*set_mp1_state)(struct pp_hwmgr *hwmgr, enum pp_mp1_state 
mp1_state);
int (*asic_reset)(struct pp_hwmgr *hwmgr, enum SMU_ASIC_RESET_MODE 
mode);
-   int (*smu_i2c_bus_access)(struct pp_hwmgr *hwmgr, bool aquire);
+   int (*smu_i2c_bus_access)(struct pp_hwmgr *hwmgr, bool acquire);
int (*set_df_cstate)(struct pp_hwmgr *hwmgr, enum pp_df_cstate state);
int (*set_xgmi_pstate)(struct pp_hwmgr *hwmgr, uint32_t pstate);
int (*disable_power_features_for_compute_performance)(struct pp_hwmgr 
*hwmgr,
-- 
2.30.2



Re: [PATCH] drm/amd/display: fix flickering caused by S/G mode

2023-04-17 Thread Alex Deucher
On Mon, Apr 17, 2023 at 1:59 AM Christian König
 wrote:
>
> Am 14.04.23 um 21:33 schrieb Hamza Mahfooz:
> > Currently, we allow the framebuffer for a given plane to move between
> > memory domains, however when that happens it causes the screen to
> > flicker, it is even possible for the framebuffer to change memory
> > domains on every plane update (causing a continuous flicker effect). So,
> > to fix this, don't perform an immediate flip in the aforementioned case.
>
> That sounds strongly like you just forget to wait for the move to finish!

It doesn't exhibit when we allow only gtt or only vram, only when
switches between pools does it flicker.

Alex

>
> What is the order of things done here? E.g. who calls amdgpu_bo_pin()
> and who waits for fences for finish signaling? Is that maybe just in the
> wrong order?
>
> Regards,
> Christian.
>
> >
> > Cc: sta...@vger.kernel.org
> > Fixes: 81d0bcf99009 ("drm/amdgpu: make display pinning more flexible (v2)")
> > Signed-off-by: Hamza Mahfooz 
> > ---
> >   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 41 ++-
> >   1 file changed, 39 insertions(+), 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 da3045fdcb6d..9a4e7408384a 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -7897,6 +7897,34 @@ static void amdgpu_dm_commit_cursors(struct 
> > drm_atomic_state *state)
> >   amdgpu_dm_plane_handle_cursor_update(plane, 
> > old_plane_state);
> >   }
> >
> > +static inline uint32_t get_mem_type(struct amdgpu_device *adev,
> > + struct drm_gem_object *obj,
> > + bool check_domain)
> > +{
> > + struct amdgpu_bo *abo = gem_to_amdgpu_bo(obj);
> > + uint32_t mem_type;
> > +
> > + if (unlikely(amdgpu_bo_reserve(abo, true)))
> > + return 0;
> > +
> > + if (unlikely(dma_resv_reserve_fences(abo->tbo.base.resv, 1)))
> > + goto err;
> > +
> > + if (check_domain &&
> > + amdgpu_display_supported_domains(adev, abo->flags) !=
> > + (AMDGPU_GEM_DOMAIN_VRAM | AMDGPU_GEM_DOMAIN_GTT))
> > + goto err;
> > +
> > + mem_type = abo->tbo.resource->mem_type;
> > + amdgpu_bo_unreserve(abo);
> > +
> > + return mem_type;
> > +
> > +err:
> > + amdgpu_bo_unreserve(abo);
> > + return 0;
> > +}
> > +
> >   static void amdgpu_dm_commit_planes(struct drm_atomic_state *state,
> >   struct dc_state *dc_state,
> >   struct drm_device *dev,
> > @@ -7916,6 +7944,7 @@ static void amdgpu_dm_commit_planes(struct 
> > drm_atomic_state *state,
> >   to_dm_crtc_state(drm_atomic_get_old_crtc_state(state, 
> > pcrtc));
> >   int planes_count = 0, vpos, hpos;
> >   unsigned long flags;
> > + uint32_t mem_type;
> >   u32 target_vblank, last_flip_vblank;
> >   bool vrr_active = amdgpu_dm_crtc_vrr_active(acrtc_state);
> >   bool cursor_update = false;
> > @@ -8035,13 +8064,21 @@ static void amdgpu_dm_commit_planes(struct 
> > drm_atomic_state *state,
> >   }
> >   }
> >
> > + mem_type = get_mem_type(dm->adev, old_plane_state->fb->obj[0],
> > + true);
> > +
> >   /*
> >* Only allow immediate flips for fast updates that don't
> > -  * change FB pitch, DCC state, rotation or mirroing.
> > +  * change memory domain, FB pitch, DCC state, rotation or
> > +  * mirroring.
> >*/
> >   bundle->flip_addrs[planes_count].flip_immediate =
> >   crtc->state->async_flip &&
> > - acrtc_state->update_type == UPDATE_TYPE_FAST;
> > + acrtc_state->update_type == UPDATE_TYPE_FAST &&
> > + (!mem_type || (mem_type && get_mem_type(dm->adev,
> > + fb->obj[0],
> > + false) ==
> > +mem_type));
> >
> >   timestamp_ns = ktime_get_ns();
> >   bundle->flip_addrs[planes_count].flip_timestamp_in_us = 
> > div_u64(timestamp_ns, 1000);
>


Re: [PATCH v3] drm/amd/display: Check & log if receiver supports MST, DSC & FEC.

2023-04-17 Thread Aurabindo Pillai




On 4/17/23 12:57, Srinivasan Shanmugam wrote:

After reading from receiver via DPCD, check & log if it supports MST,
DSC & FEC

Cc: Aurabindo Pillai 
Cc: Fangzhi Zuo 
Signed-off-by: Srinivasan Shanmugam 
---
v2:
  - Added %s: to print the function name.

v3:
  - Used the defined struct instead of the bitwise logic here, like
fec_cap.bits.FEC_CAPABLE. Makes it more readable. (Aurabindo)

  - For DSC, it would be useful to print both basic DSC and passthrough
capability. (Aurabindo)

  .../dc/link/protocols/link_dp_capability.c   | 16 
  1 file changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c 
b/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c
index ba98013fecd0..59adc61156cb 100644
--- a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c
+++ b/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c
@@ -1554,6 +1554,9 @@ static bool retrieve_link_cap(struct dc_link *link)
int i;
struct dp_sink_hw_fw_revision dp_hw_fw_revision;
const uint32_t post_oui_delay = 30; // 30ms
+   bool is_fec_supported = false;
+   bool is_dsc_basic_supported = false;
+   bool is_dsc_passthrough_supported = false;
  
  	memset(dpcd_data, '\0', sizeof(dpcd_data));

memset(&down_strm_port_count,
@@ -1696,6 +1699,7 @@ static bool retrieve_link_cap(struct dc_link *link)
  
  	/* TODO - decouple raw mst capability from policy decision */

link->dpcd_caps.is_mst_capable = read_is_mst_supported(link);
+   DC_LOG_DC("%s: MST_Support: %s\n", __func__, 
str_yes_no(link->dpcd_caps.is_mst_capable));
  
  	get_active_converter_info(ds_port.byte, link);
  
@@ -1803,6 +1807,18 @@ static bool retrieve_link_cap(struct dc_link *link)

DP_DSC_SUPPORT,
link->dpcd_caps.dsc_caps.dsc_basic_caps.raw,

sizeof(link->dpcd_caps.dsc_caps.dsc_basic_caps.raw));
+   if (status == DC_OK) {
+   is_fec_supported = 
link->dpcd_caps.fec_cap.bits.FEC_CAPABLE;
+   is_dsc_basic_supported = 
link->dpcd_caps.dsc_caps.dsc_basic_caps.fields.dsc_support.DSC_SUPPORT;
+   is_dsc_passthrough_supported = 
link->dpcd_caps.dsc_caps.dsc_basic_caps.fields.dsc_support.DSC_PASSTHROUGH_SUPPORT;
+   DC_LOG_DC("%s: FEC_Sink_Support: %s\n", __func__,
+ str_yes_no(is_fec_supported));
+   DC_LOG_DC("%s: DSC_Basic_Sink_Support: %s\n", __func__,
+ str_yes_no(is_dsc_basic_supported));
+   if (link->dpcd_caps.is_mst_capable)
+   DC_LOG_DC("%s: DSC_Passthrough_Sink_Support: 
%s\n", __func__,
+ 
str_yes_no(is_dsc_passthrough_supported));
+   }
if (link->dpcd_caps.dongle_type != DISPLAY_DONGLE_NONE) {
status = core_link_read_dpcd(
link,



Reviewed-by: Aurabindo Pillai 


Re: [PATCH] drm/amd/display: Unconditionally print when DP sink power state fails

2023-04-17 Thread Aurabindo Pillai




On 4/17/23 13:08, Srinivasan Shanmugam wrote:

The previous 'commit 9360c01646d4e ("drm/amd/display: Add logging when
setting DP sink power state fails")', it is better to unconditionally
print "failed to power up sink", because we are returning
DC_ERROR_UNEXPECTED.

Cc: Aurabindo Pillai 
Cc: Fangzhi Zuo 
Signed-off-by: Srinivasan Shanmugam 
---
  .../drm/amd/display/dc/link/protocols/link_dp_capability.c| 4 +---
  1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c 
b/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c
index 59adc61156cb..2914fca7dab3 100644
--- a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c
+++ b/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c
@@ -1043,9 +1043,7 @@ static enum dc_status wake_up_aux_channel(struct dc_link 
*link)
DP_SET_POWER,
&dpcd_power_state,
sizeof(dpcd_power_state));
-   if (status < 0)
-   DC_LOG_DC("%s: Failed to power up sink: %s\n", __func__,
- dpcd_power_state == DP_SET_POWER_D0 ? "D0" : 
"D3");
+   DC_LOG_DC("%s: Failed to power up sink\n", __func__);
return DC_ERROR_UNEXPECTED;
}
  



With the following tag added to the commit message:

Fixes: 9360c01646d4e ("drm/amd/display: Add logging when setting DP sink 
power state fails")


The patch is:

Reviewed-by: Aurabindo Pillai 


[PATCH] drm/amd/display: Unconditionally print when DP sink power state fails

2023-04-17 Thread Srinivasan Shanmugam
The previous 'commit 9360c01646d4e ("drm/amd/display: Add logging when
setting DP sink power state fails")', it is better to unconditionally
print "failed to power up sink", because we are returning
DC_ERROR_UNEXPECTED.

Cc: Aurabindo Pillai 
Cc: Fangzhi Zuo 
Signed-off-by: Srinivasan Shanmugam 
---
 .../drm/amd/display/dc/link/protocols/link_dp_capability.c| 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c 
b/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c
index 59adc61156cb..2914fca7dab3 100644
--- a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c
+++ b/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c
@@ -1043,9 +1043,7 @@ static enum dc_status wake_up_aux_channel(struct dc_link 
*link)
DP_SET_POWER,
&dpcd_power_state,
sizeof(dpcd_power_state));
-   if (status < 0)
-   DC_LOG_DC("%s: Failed to power up sink: %s\n", __func__,
- dpcd_power_state == DP_SET_POWER_D0 ? "D0" : 
"D3");
+   DC_LOG_DC("%s: Failed to power up sink\n", __func__);
return DC_ERROR_UNEXPECTED;
}
 
-- 
2.25.1



Canceled event: XDC 2023 A Corunha Spain @ Tue Oct 17 - Thu Oct 19, 2023 (amd-gfx@lists.freedesktop.org)

2023-04-17 Thread mario . kleiner . de
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:CANCEL
BEGIN:VEVENT
DTSTART;VALUE=DATE:20231017
DTEND;VALUE=DATE:20231020
DTSTAMP:20230417T170848Z
ORGANIZER;CN=mario.kleiner...@gmail.com:mailto:mario.kleiner...@gmail.com
UID:65qeuuc9e0gll25tq5r7e61...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=et
 na...@lists.freedesktop.org;X-NUM-GUESTS=0:mailto:etnaviv@lists.freedesktop
 .org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=xo
 rg-de...@lists.freedesktop.org;X-NUM-GUESTS=0:mailto:xorg-devel@lists.freed
 esktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=am
 d-gfx list;X-NUM-GUESTS=0:mailto:amd-gfx@lists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=in
 tel-gfx;X-NUM-GUESTS=0:mailto:intel-...@lists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=No
 uveau Dev;X-NUM-GUESTS=0:mailto:nouv...@lists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=mario.
 kleiner...@gmail.com;X-NUM-GUESTS=0:mailto:mario.kleiner...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=bo
 a...@foundation.x.org;X-NUM-GUESTS=0:mailto:bo...@foundation.x.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=li
 bre-soc-...@lists.libre-soc.org;X-NUM-GUESTS=0:mailto:libre-soc-dev@lists.l
 ibre-soc.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=ML
  mesa-dev;X-NUM-GUESTS=0:mailto:mesa-...@lists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=me
 mb...@x.org;X-NUM-GUESTS=0:mailto:memb...@x.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=fr
 eedr...@lists.freedesktop.org;X-NUM-GUESTS=0:mailto:freedreno@lists.freedes
 ktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=dr
 oidbit...@gmail.com;X-NUM-GUESTS=0:mailto:droidbit...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=wa
 yland-de...@lists.freedesktop.org;X-NUM-GUESTS=0:mailto:wayland-devel@lists
 .freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=dr
 i-devel;X-NUM-GUESTS=0:mailto:dri-de...@lists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=si
 gles...@igalia.com;X-NUM-GUESTS=0:mailto:sigles...@igalia.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=ev
 e...@lists.x.org;X-NUM-GUESTS=0:mailto:eve...@lists.x.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;X-NUM
 -GUESTS=0:mailto:bibby.hs...@mediatek.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN="G
 arg, Rohan";X-NUM-GUESTS=0:mailto:rohan.g...@intel.com
X-GOOGLE-CONFERENCE:https://meet.google.com/azn-uwfp-pgw
CREATED:20230417T170310Z
DESCRIPTION:Hello!\n \nRegistration & Call for Proposals are now open for X
 DC 2023\, which will\ntake place on October 17-19\, 2023.\n\nhttps://xdc202
 3.x.org\n \nAs usual\, the conference is free of charge and open to the gen
 eral\npublic. If you plan on attending\, please make sure to register as ea
 rly\nas possible!\n \nIn order to register as attendee\, you will therefore
  need to register\nvia the XDC website.\n \nhttps://indico.freedesktop.org/
 event/4/registrations/\n \nIn addition to registration\, the CfP is now ope
 n for talks\, workshops\nand demos at XDC 2023. While ...\n\n-::~:~::~:~:~:
 ~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-\n
 Join with Google Meet: https://meet.google.com/azn-uwfp-pgw\n\nLearn more a
 bout Meet at: https://support.google.com/a/users/answer/9282720\n\nPlease d
 o not edit this section.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20230417T170847Z
LOCATION:
SEQUENCE:1
STATUS:CANCELLED
SUMMARY:XDC 2023 A Corunha Spain
TRANSP:TRANSPARENT
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics


Invitation: XDC 2023 A Corunha Spain @ Tue Oct 17 - Thu Oct 19, 2023 (amd-gfx@lists.freedesktop.org)

2023-04-17 Thread mario . kleiner . de
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART;VALUE=DATE:20231017
DTEND;VALUE=DATE:20231020
DTSTAMP:20230417T170311Z
ORGANIZER;CN=mario.kleiner...@gmail.com:mailto:mario.kleiner...@gmail.com
UID:65qeuuc9e0gll25tq5r7e61...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=etna...@lists.freedesktop.org;X-NUM-GUESTS=0:mailto:etnaviv@lists.f
 reedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=xorg-de...@lists.freedesktop.org;X-NUM-GUESTS=0:mailto:xorg-devel@l
 ists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=amd-gfx list;X-NUM-GUESTS=0:mailto:amd-gfx@lists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=intel-gfx;X-NUM-GUESTS=0:mailto:intel-...@lists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Nouveau Dev;X-NUM-GUESTS=0:mailto:nouv...@lists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=mario.kleiner...@gmail.com;X-NUM-GUESTS=0:mailto:mario.kleiner.de@gmail
 .com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=bo...@foundation.x.org;X-NUM-GUESTS=0:mailto:bo...@foundation.x.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=libre-soc-...@lists.libre-soc.org;X-NUM-GUESTS=0:mailto:libre-soc-d
 e...@lists.libre-soc.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=ML mesa-dev;X-NUM-GUESTS=0:mailto:mesa-...@lists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=memb...@x.org;X-NUM-GUESTS=0:mailto:memb...@x.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=freedr...@lists.freedesktop.org;X-NUM-GUESTS=0:mailto:freedreno@lis
 ts.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=droidbit...@gmail.com;X-NUM-GUESTS=0:mailto:droidbit...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=wayland-de...@lists.freedesktop.org;X-NUM-GUESTS=0:mailto:wayland-d
 e...@lists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=dri-devel;X-NUM-GUESTS=0:mailto:dri-de...@lists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=sigles...@igalia.com;X-NUM-GUESTS=0:mailto:sigles...@igalia.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=eve...@lists.x.org;X-NUM-GUESTS=0:mailto:eve...@lists.x.org
X-GOOGLE-CONFERENCE:https://meet.google.com/azn-uwfp-pgw
X-MICROSOFT-CDO-OWNERAPPTID:-2084153633
CREATED:20230417T170310Z
DESCRIPTION:Hello!\n \nRegistration & Call for Proposals are now open for X
 DC 2023\, which will\ntake place on October 17-19\, 2023.\n\nhttps://xdc202
 3.x.org\n \nAs usual\, the conference is free of charge and open to the gen
 eral\npublic. If you plan on attending\, please make sure to register as ea
 rly\nas possible!\n \nIn order to register as attendee\, you will therefore
  need to register\nvia the XDC website.\n \nhttps://indico.freedesktop.org/
 event/4/registrations/\n \nIn addition to registration\, the CfP is now ope
 n for talks\, workshops\nand demos at XDC 2023. While ...\n\n-::~:~::~:~:~:
 ~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-\n
 Join with Google Meet: https://meet.google.com/azn-uwfp-pgw\n\nLearn more a
 bout Meet at: https://support.google.com/a/users/answer/9282720\n\nPlease d
 o not edit this section.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20230417T170310Z
LOCATION:
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:XDC 2023 A Corunha Spain
TRANSP:TRANSPARENT
BEGIN:VALARM
ACTION:EMAIL
DESCRIPTION:This is an event reminder
SUMMARY:Alarm notification
ATTENDEE:mailto:amd-gfx@lists.freedesktop.org
TRIGGER:-P0DT0H30M0S
END:VALARM
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:This is an event reminder
TRIGGER:-P0DT0H30M0S
END:VALARM
BEGIN:VALARM
ACTION:EMAIL
DESCRIPTION:This is an event reminder
SUMMARY:Alarm notification
ATTENDEE:mailto:amd-gfx@lists.freedesktop.org
TRIGGER:-P0DT7H30M0S
END:VALARM
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics


[PATCH v3] drm/amd/display: Check & log if receiver supports MST, DSC & FEC.

2023-04-17 Thread Srinivasan Shanmugam
After reading from receiver via DPCD, check & log if it supports MST,
DSC & FEC

Cc: Aurabindo Pillai 
Cc: Fangzhi Zuo 
Signed-off-by: Srinivasan Shanmugam 
---
v2:
 - Added %s: to print the function name.

v3:
 - Used the defined struct instead of the bitwise logic here, like 
fec_cap.bits.FEC_CAPABLE. Makes it more readable. (Aurabindo)

 - For DSC, it would be useful to print both basic DSC and passthrough 
capability. (Aurabindo)

 .../dc/link/protocols/link_dp_capability.c   | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c 
b/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c
index ba98013fecd0..59adc61156cb 100644
--- a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c
+++ b/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c
@@ -1554,6 +1554,9 @@ static bool retrieve_link_cap(struct dc_link *link)
int i;
struct dp_sink_hw_fw_revision dp_hw_fw_revision;
const uint32_t post_oui_delay = 30; // 30ms
+   bool is_fec_supported = false;
+   bool is_dsc_basic_supported = false;
+   bool is_dsc_passthrough_supported = false;
 
memset(dpcd_data, '\0', sizeof(dpcd_data));
memset(&down_strm_port_count,
@@ -1696,6 +1699,7 @@ static bool retrieve_link_cap(struct dc_link *link)
 
/* TODO - decouple raw mst capability from policy decision */
link->dpcd_caps.is_mst_capable = read_is_mst_supported(link);
+   DC_LOG_DC("%s: MST_Support: %s\n", __func__, 
str_yes_no(link->dpcd_caps.is_mst_capable));
 
get_active_converter_info(ds_port.byte, link);
 
@@ -1803,6 +1807,18 @@ static bool retrieve_link_cap(struct dc_link *link)
DP_DSC_SUPPORT,
link->dpcd_caps.dsc_caps.dsc_basic_caps.raw,

sizeof(link->dpcd_caps.dsc_caps.dsc_basic_caps.raw));
+   if (status == DC_OK) {
+   is_fec_supported = 
link->dpcd_caps.fec_cap.bits.FEC_CAPABLE;
+   is_dsc_basic_supported = 
link->dpcd_caps.dsc_caps.dsc_basic_caps.fields.dsc_support.DSC_SUPPORT;
+   is_dsc_passthrough_supported = 
link->dpcd_caps.dsc_caps.dsc_basic_caps.fields.dsc_support.DSC_PASSTHROUGH_SUPPORT;
+   DC_LOG_DC("%s: FEC_Sink_Support: %s\n", __func__,
+ str_yes_no(is_fec_supported));
+   DC_LOG_DC("%s: DSC_Basic_Sink_Support: %s\n", __func__,
+ str_yes_no(is_dsc_basic_supported));
+   if (link->dpcd_caps.is_mst_capable)
+   DC_LOG_DC("%s: DSC_Passthrough_Sink_Support: 
%s\n", __func__,
+ 
str_yes_no(is_dsc_passthrough_supported));
+   }
if (link->dpcd_caps.dongle_type != DISPLAY_DONGLE_NONE) {
status = core_link_read_dpcd(
link,
-- 
2.25.1



Re: [Nouveau] XDC 2023: Registration & Call for Proposals now open!

2023-04-17 Thread Luna Jernberg
Signed up will only attend virtually Online however just fyi

On Mon, Apr 17, 2023 at 1:41 PM Samuel Iglesias Gonsálvez
 wrote:
>
> Hello!
>
> Registration & Call for Proposals are now open for XDC 2023, which will
> take place on October 17-19, 2023.
>
> https://xdc2023.x.org
>
> As usual, the conference is free of charge and open to the general
> public. If you plan on attending, please make sure to register as early
> as possible!
>
> In order to register as attendee, you will therefore need to register
> via the XDC website.
>
> https://indico.freedesktop.org/event/4/registrations/
>
> In addition to registration, the CfP is now open for talks, workshops
> and demos at XDC 2023. While any serious proposal will be gratefully
> considered, topics of interest to X.Org and freedesktop.org developers
> are encouraged. The program focus is on new development, ongoing
> challenges and anything else that will spark discussions among
> attendees in the hallway track.
>
> We are open to talks across all layers of the graphics stack, from the
> kernel to desktop environments / graphical applications and about how
> to make things better for the developers who build them. Head to the
> CfP page to learn more:
>
> https://indico.freedesktop.org/event/4/abstracts/
>
> The deadline for submissions is Monday, 17 July 2023 (23:59 CEST)
>
> Check out our Reimbursement Policy to accept speaker expenses:
>
> https://www.x.org/wiki/XorgFoundation/Policies/Reimbursement/
>
> If you have any questions, please send me an email to
> siglesias AT igalia.com, adding on Cc the X.org board (board
> at foundation.x.org).
>
> And please keep in mind, you can follow us on Twitter for all the latest
> updates and to stay connected:
>
> https://twitter.com/XOrgDevConf
>
> Best,
>
> Sam


Re: [PATCH] drm/amd/display: fix flickering caused by S/G mode

2023-04-17 Thread Hamza Mahfooz

On 4/17/23 11:41, Wu, Hersen wrote:

[AMD Official Use Only - General]

Hi,

The change applies to all AMD GPU ASIC.
Please communicate with issue reporter to see if the issue could be reproduced 
older ASIC, like Mendocino, CZN.


From the community reports, it can be reproduced on as far back as the
Ryzen 4800H (which I guess is Renoir).



Thanks!
Hersen


-Original Message-
From: Mahfooz, Hamza 
Sent: Monday, April 17, 2023 11:26 AM
To: Koenig, Christian ; amd-gfx@lists.freedesktop.org
Cc: sta...@vger.kernel.org; Wentland, Harry ; Li, Sun peng (Leo) ; Siqueira, Rodrigo 
; Deucher, Alexander ; Pan, Xinhui ; David Airlie 
; Daniel Vetter ; Pillai, Aurabindo ; Zhuo, Qingqing (Lillian) 
; Hans de Goede ; Wu, Hersen ; Wang, Chao-kai (Stylon) 
; Tuikov, Luben ; dri-de...@lists.freedesktop.org; linux-ker...@vger.kernel.org
Subject: Re: [PATCH] drm/amd/display: fix flickering caused by S/G mode


On 4/17/23 11:03, Christian König wrote:

Am 17.04.23 um 16:51 schrieb Hamza Mahfooz:


On 4/17/23 01:59, Christian König wrote:

Am 14.04.23 um 21:33 schrieb Hamza Mahfooz:

Currently, we allow the framebuffer for a given plane to move
between memory domains, however when that happens it causes the
screen to flicker, it is even possible for the framebuffer to
change memory domains on every plane update (causing a continuous flicker 
effect).
So,
to fix this, don't perform an immediate flip in the aforementioned
case.


That sounds strongly like you just forget to wait for the move to
finish!

What is the order of things done here? E.g. who calls
amdgpu_bo_pin() and who waits for fences for finish signaling? Is
that maybe just in the wrong order?


The pinning logic is in dm_plane_helper_prepare_fb(). Also, it seems
like we wait for the fences in amdgpu_dm_atomic_commit_tail(), using
drm_atomic_helper_wait_for_fences(). The ordering should be fine as
well, since prepare_fb() is always called before atomic_commit_tail().


Ok, then why is there any flickering?

BTW reserving a fence slot is completely unnecessary. That looks like
you copy&pasted the code from somewhere else without checking what it
actually does.


It seemed like it was necessary to read `tbo.resource` since the documentation for 
`struct ttm_buffer_object` makes mention of a "bo::resv::reserved" lock.



Regards,
Christian.





Regards,
Christian.



Cc: sta...@vger.kernel.org
Fixes: 81d0bcf99009 ("drm/amdgpu: make display pinning more
flexible
(v2)")
Signed-off-by: Hamza Mahfooz 
---
   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 41
++-
   1 file changed, 39 insertions(+), 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 da3045fdcb6d..9a4e7408384a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7897,6 +7897,34 @@ static void amdgpu_dm_commit_cursors(struct
drm_atomic_state *state)
   amdgpu_dm_plane_handle_cursor_update(plane,
old_plane_state);
   }
+static inline uint32_t get_mem_type(struct amdgpu_device *adev,
+    struct drm_gem_object *obj,
+    bool check_domain) {
+    struct amdgpu_bo *abo = gem_to_amdgpu_bo(obj);
+    uint32_t mem_type;
+
+    if (unlikely(amdgpu_bo_reserve(abo, true)))
+    return 0;
+
+    if (unlikely(dma_resv_reserve_fences(abo->tbo.base.resv, 1)))
+    goto err;
+
+    if (check_domain &&
+    amdgpu_display_supported_domains(adev, abo->flags) !=
+    (AMDGPU_GEM_DOMAIN_VRAM | AMDGPU_GEM_DOMAIN_GTT))
+    goto err;
+
+    mem_type = abo->tbo.resource->mem_type;
+    amdgpu_bo_unreserve(abo);
+
+    return mem_type;
+
+err:
+    amdgpu_bo_unreserve(abo);
+    return 0;
+}
+
   static void amdgpu_dm_commit_planes(struct drm_atomic_state
*state,
   struct dc_state *dc_state,
   struct drm_device *dev, @@ -7916,6 +7944,7 @@
static void amdgpu_dm_commit_planes(struct drm_atomic_state *state,
to_dm_crtc_state(drm_atomic_get_old_crtc_state(state, pcrtc));
   int planes_count = 0, vpos, hpos;
   unsigned long flags;
+    uint32_t mem_type;
   u32 target_vblank, last_flip_vblank;
   bool vrr_active = amdgpu_dm_crtc_vrr_active(acrtc_state);
   bool cursor_update = false;
@@ -8035,13 +8064,21 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
   }
   }
+    mem_type = get_mem_type(dm->adev,
+old_plane_state->fb->obj[0],
+    true);
+
   /*
    * Only allow immediate flips for fast updates that don't
- * change FB pitch, DCC state, rotation or mirroing.
+ * change memory domain, FB pitch, DCC state, rotation or
+ * mirroring.
    */
   bundle->flip_addrs[planes_count].flip_immediate =
   crtc->state->async_flip &&
-    acrtc_state->update_type == UPDATE_TYPE_FAST;
+    acrtc_stat

Re: [PATCH] drm/amd/display: fix flickering caused by S/G mode

2023-04-17 Thread Christian König

Am 17.04.23 um 17:25 schrieb Hamza Mahfooz:


On 4/17/23 11:03, Christian König wrote:

Am 17.04.23 um 16:51 schrieb Hamza Mahfooz:


On 4/17/23 01:59, Christian König wrote:

Am 14.04.23 um 21:33 schrieb Hamza Mahfooz:

Currently, we allow the framebuffer for a given plane to move between
memory domains, however when that happens it causes the screen to
flicker, it is even possible for the framebuffer to change memory
domains on every plane update (causing a continuous flicker 
effect). So,
to fix this, don't perform an immediate flip in the aforementioned 
case.


That sounds strongly like you just forget to wait for the move to 
finish!


What is the order of things done here? E.g. who calls 
amdgpu_bo_pin() and who waits for fences for finish signaling? Is 
that maybe just in the wrong order?


The pinning logic is in dm_plane_helper_prepare_fb(). Also, it seems
like we wait for the fences in amdgpu_dm_atomic_commit_tail(), using
drm_atomic_helper_wait_for_fences(). The ordering should be fine as
well, since prepare_fb() is always called before atomic_commit_tail().


Ok, then why is there any flickering?

BTW reserving a fence slot is completely unnecessary. That looks like 
you copy&pasted the code from somewhere else without checking what it 
actually does.


It seemed like it was necessary to read `tbo.resource` since the
documentation for `struct ttm_buffer_object` makes mention of a
"bo::resv::reserved" lock.


What? No, that sounds like you completely misunderstood that. I think we 
need to improve the documentation.


As long as the object is pinned for scanout you don't even need to 
reserve it.


Just use something like "abo->tbo.resource ? abo->tbo.resource->mem_type 
: 0" here.


Regards,
Christian.





Regards,
Christian.





Regards,
Christian.



Cc: sta...@vger.kernel.org
Fixes: 81d0bcf99009 ("drm/amdgpu: make display pinning more 
flexible (v2)")

Signed-off-by: Hamza Mahfooz 
---
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 41 
++-

  1 file changed, 39 insertions(+), 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 da3045fdcb6d..9a4e7408384a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7897,6 +7897,34 @@ static void amdgpu_dm_commit_cursors(struct 
drm_atomic_state *state)
  amdgpu_dm_plane_handle_cursor_update(plane, 
old_plane_state);

  }
+static inline uint32_t get_mem_type(struct amdgpu_device *adev,
+    struct drm_gem_object *obj,
+    bool check_domain)
+{
+    struct amdgpu_bo *abo = gem_to_amdgpu_bo(obj);
+    uint32_t mem_type;
+
+    if (unlikely(amdgpu_bo_reserve(abo, true)))
+    return 0;
+
+    if (unlikely(dma_resv_reserve_fences(abo->tbo.base.resv, 1)))
+    goto err;
+
+    if (check_domain &&
+    amdgpu_display_supported_domains(adev, abo->flags) !=
+    (AMDGPU_GEM_DOMAIN_VRAM | AMDGPU_GEM_DOMAIN_GTT))
+    goto err;
+
+    mem_type = abo->tbo.resource->mem_type;
+    amdgpu_bo_unreserve(abo);
+
+    return mem_type;
+
+err:
+    amdgpu_bo_unreserve(abo);
+    return 0;
+}
+
  static void amdgpu_dm_commit_planes(struct drm_atomic_state *state,
  struct dc_state *dc_state,
  struct drm_device *dev,
@@ -7916,6 +7944,7 @@ static void amdgpu_dm_commit_planes(struct 
drm_atomic_state *state,

to_dm_crtc_state(drm_atomic_get_old_crtc_state(state, pcrtc));
  int planes_count = 0, vpos, hpos;
  unsigned long flags;
+    uint32_t mem_type;
  u32 target_vblank, last_flip_vblank;
  bool vrr_active = amdgpu_dm_crtc_vrr_active(acrtc_state);
  bool cursor_update = false;
@@ -8035,13 +8064,21 @@ static void amdgpu_dm_commit_planes(struct 
drm_atomic_state *state,

  }
  }
+    mem_type = get_mem_type(dm->adev, 
old_plane_state->fb->obj[0],

+    true);
+
  /*
   * Only allow immediate flips for fast updates that don't
- * change FB pitch, DCC state, rotation or mirroing.
+ * change memory domain, FB pitch, DCC state, rotation or
+ * mirroring.
   */
bundle->flip_addrs[planes_count].flip_immediate =
  crtc->state->async_flip &&
-    acrtc_state->update_type == UPDATE_TYPE_FAST;
+    acrtc_state->update_type == UPDATE_TYPE_FAST &&
+    (!mem_type || (mem_type && get_mem_type(dm->adev,
+    fb->obj[0],
+    false) ==
+   mem_type));
  timestamp_ns = ktime_get_ns();
bundle->flip_addrs[planes_count].flip_timestamp_in_us = 
div_u64(timestamp_ns, 1000);








Re: [PATCH 62/66] drm/amd/display: Explicitly specify update type per plane info change

2023-04-17 Thread Aurabindo Pillai

Hi,

Please add:

Fixes: aa5fdb1ab5b6 ("drm/amd/display: Explicitly specify update type 
per plane info change")


On 4/14/23 11:53, Qingqing Zhuo wrote:

From: Nicholas Kazlauskas 

[Why]
The bit for flip addr is being set causing the determination for
FAST vs MEDIUM to always return MEDIUM when plane info is provided
as a surface update. This causes extreme stuttering for the typical
atomic update path on Linux.

[How]
Don't use update_flags->raw for determining FAST vs MEDIUM. It's too
fragile to changes like this.

Explicitly specify the update type per update flag instead. It's not
as clever as checking the bits itself but at least it's correct.

Reviewed-by: Rodrigo Siqueira 
Signed-off-by: Nicholas Kazlauskas 
---
  drivers/gpu/drm/amd/display/dc/core/dc.c | 3 ---
  1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 238a13266ad8..e65ba87ee2c5 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -2482,9 +2482,6 @@ static enum surface_update_type det_surface_update(const 
struct dc *dc,
enum surface_update_type overall_type = UPDATE_TYPE_FAST;
union surface_update_flags *update_flags = &u->surface->update_flags;
  
-	if (u->flip_addr)

-   update_flags->bits.addr_update = 1;
-
if (!is_surface_in_context(context, u->surface) || 
u->surface->force_full_update) {
update_flags->raw = 0x;
return UPDATE_TYPE_FULL;


RE: [PATCH] drm/amd/display: fix flickering caused by S/G mode

2023-04-17 Thread Wu, Hersen
[AMD Official Use Only - General]

Hi,

The change applies to all AMD GPU ASIC.
Please communicate with issue reporter to see if the issue could be reproduced 
older ASIC, like Mendocino, CZN.

Thanks!
Hersen


-Original Message-
From: Mahfooz, Hamza  
Sent: Monday, April 17, 2023 11:26 AM
To: Koenig, Christian ; amd-gfx@lists.freedesktop.org
Cc: sta...@vger.kernel.org; Wentland, Harry ; Li, Sun 
peng (Leo) ; Siqueira, Rodrigo ; 
Deucher, Alexander ; Pan, Xinhui 
; David Airlie ; Daniel Vetter 
; Pillai, Aurabindo ; Zhuo, Qingqing 
(Lillian) ; Hans de Goede ; Wu, 
Hersen ; Wang, Chao-kai (Stylon) ; 
Tuikov, Luben ; dri-de...@lists.freedesktop.org; 
linux-ker...@vger.kernel.org
Subject: Re: [PATCH] drm/amd/display: fix flickering caused by S/G mode


On 4/17/23 11:03, Christian König wrote:
> Am 17.04.23 um 16:51 schrieb Hamza Mahfooz:
>>
>> On 4/17/23 01:59, Christian König wrote:
>>> Am 14.04.23 um 21:33 schrieb Hamza Mahfooz:
 Currently, we allow the framebuffer for a given plane to move 
 between memory domains, however when that happens it causes the 
 screen to flicker, it is even possible for the framebuffer to 
 change memory domains on every plane update (causing a continuous flicker 
 effect).
 So,
 to fix this, don't perform an immediate flip in the aforementioned 
 case.
>>>
>>> That sounds strongly like you just forget to wait for the move to 
>>> finish!
>>>
>>> What is the order of things done here? E.g. who calls 
>>> amdgpu_bo_pin() and who waits for fences for finish signaling? Is 
>>> that maybe just in the wrong order?
>>
>> The pinning logic is in dm_plane_helper_prepare_fb(). Also, it seems 
>> like we wait for the fences in amdgpu_dm_atomic_commit_tail(), using 
>> drm_atomic_helper_wait_for_fences(). The ordering should be fine as 
>> well, since prepare_fb() is always called before atomic_commit_tail().
> 
> Ok, then why is there any flickering?
> 
> BTW reserving a fence slot is completely unnecessary. That looks like 
> you copy&pasted the code from somewhere else without checking what it 
> actually does.

It seemed like it was necessary to read `tbo.resource` since the documentation 
for `struct ttm_buffer_object` makes mention of a "bo::resv::reserved" lock.

> 
> Regards,
> Christian.
> 
>>
>>>
>>> Regards,
>>> Christian.
>>>

 Cc: sta...@vger.kernel.org
 Fixes: 81d0bcf99009 ("drm/amdgpu: make display pinning more 
 flexible
 (v2)")
 Signed-off-by: Hamza Mahfooz 
 ---
   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 41
 ++-
   1 file changed, 39 insertions(+), 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 da3045fdcb6d..9a4e7408384a 100644
 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
 +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
 @@ -7897,6 +7897,34 @@ static void amdgpu_dm_commit_cursors(struct 
 drm_atomic_state *state)
   amdgpu_dm_plane_handle_cursor_update(plane,
 old_plane_state);
   }
 +static inline uint32_t get_mem_type(struct amdgpu_device *adev,
 +    struct drm_gem_object *obj,
 +    bool check_domain) {
 +    struct amdgpu_bo *abo = gem_to_amdgpu_bo(obj);
 +    uint32_t mem_type;
 +
 +    if (unlikely(amdgpu_bo_reserve(abo, true)))
 +    return 0;
 +
 +    if (unlikely(dma_resv_reserve_fences(abo->tbo.base.resv, 1)))
 +    goto err;
 +
 +    if (check_domain &&
 +    amdgpu_display_supported_domains(adev, abo->flags) !=
 +    (AMDGPU_GEM_DOMAIN_VRAM | AMDGPU_GEM_DOMAIN_GTT))
 +    goto err;
 +
 +    mem_type = abo->tbo.resource->mem_type;
 +    amdgpu_bo_unreserve(abo);
 +
 +    return mem_type;
 +
 +err:
 +    amdgpu_bo_unreserve(abo);
 +    return 0;
 +}
 +
   static void amdgpu_dm_commit_planes(struct drm_atomic_state 
 *state,
   struct dc_state *dc_state,
   struct drm_device *dev, @@ -7916,6 +7944,7 @@ 
 static void amdgpu_dm_commit_planes(struct drm_atomic_state *state, 
 to_dm_crtc_state(drm_atomic_get_old_crtc_state(state, pcrtc));
   int planes_count = 0, vpos, hpos;
   unsigned long flags;
 +    uint32_t mem_type;
   u32 target_vblank, last_flip_vblank;
   bool vrr_active = amdgpu_dm_crtc_vrr_active(acrtc_state);
   bool cursor_update = false;
 @@ -8035,13 +8064,21 @@ static void amdgpu_dm_commit_planes(struct 
 drm_atomic_state *state,
   }
   }
 +    mem_type = get_mem_type(dm->adev, 
 +old_plane_state->fb->obj[0],
 +    true);
 +
   /*
    * Only allow immediate flips for fast updates that don't
 - * change FB pitch,

Re: [PATCH] drm/amd/display: fix flickering caused by S/G mode

2023-04-17 Thread Hamza Mahfooz



On 4/17/23 11:03, Christian König wrote:

Am 17.04.23 um 16:51 schrieb Hamza Mahfooz:


On 4/17/23 01:59, Christian König wrote:

Am 14.04.23 um 21:33 schrieb Hamza Mahfooz:

Currently, we allow the framebuffer for a given plane to move between
memory domains, however when that happens it causes the screen to
flicker, it is even possible for the framebuffer to change memory
domains on every plane update (causing a continuous flicker effect). 
So,
to fix this, don't perform an immediate flip in the aforementioned 
case.


That sounds strongly like you just forget to wait for the move to 
finish!


What is the order of things done here? E.g. who calls amdgpu_bo_pin() 
and who waits for fences for finish signaling? Is that maybe just in 
the wrong order?


The pinning logic is in dm_plane_helper_prepare_fb(). Also, it seems
like we wait for the fences in amdgpu_dm_atomic_commit_tail(), using
drm_atomic_helper_wait_for_fences(). The ordering should be fine as
well, since prepare_fb() is always called before atomic_commit_tail().


Ok, then why is there any flickering?

BTW reserving a fence slot is completely unnecessary. That looks like 
you copy&pasted the code from somewhere else without checking what it 
actually does.


It seemed like it was necessary to read `tbo.resource` since the
documentation for `struct ttm_buffer_object` makes mention of a
"bo::resv::reserved" lock.



Regards,
Christian.





Regards,
Christian.



Cc: sta...@vger.kernel.org
Fixes: 81d0bcf99009 ("drm/amdgpu: make display pinning more flexible 
(v2)")

Signed-off-by: Hamza Mahfooz 
---
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 41 
++-

  1 file changed, 39 insertions(+), 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 da3045fdcb6d..9a4e7408384a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7897,6 +7897,34 @@ static void amdgpu_dm_commit_cursors(struct 
drm_atomic_state *state)
  amdgpu_dm_plane_handle_cursor_update(plane, 
old_plane_state);

  }
+static inline uint32_t get_mem_type(struct amdgpu_device *adev,
+    struct drm_gem_object *obj,
+    bool check_domain)
+{
+    struct amdgpu_bo *abo = gem_to_amdgpu_bo(obj);
+    uint32_t mem_type;
+
+    if (unlikely(amdgpu_bo_reserve(abo, true)))
+    return 0;
+
+    if (unlikely(dma_resv_reserve_fences(abo->tbo.base.resv, 1)))
+    goto err;
+
+    if (check_domain &&
+    amdgpu_display_supported_domains(adev, abo->flags) !=
+    (AMDGPU_GEM_DOMAIN_VRAM | AMDGPU_GEM_DOMAIN_GTT))
+    goto err;
+
+    mem_type = abo->tbo.resource->mem_type;
+    amdgpu_bo_unreserve(abo);
+
+    return mem_type;
+
+err:
+    amdgpu_bo_unreserve(abo);
+    return 0;
+}
+
  static void amdgpu_dm_commit_planes(struct drm_atomic_state *state,
  struct dc_state *dc_state,
  struct drm_device *dev,
@@ -7916,6 +7944,7 @@ static void amdgpu_dm_commit_planes(struct 
drm_atomic_state *state,

to_dm_crtc_state(drm_atomic_get_old_crtc_state(state, pcrtc));
  int planes_count = 0, vpos, hpos;
  unsigned long flags;
+    uint32_t mem_type;
  u32 target_vblank, last_flip_vblank;
  bool vrr_active = amdgpu_dm_crtc_vrr_active(acrtc_state);
  bool cursor_update = false;
@@ -8035,13 +8064,21 @@ static void amdgpu_dm_commit_planes(struct 
drm_atomic_state *state,

  }
  }
+    mem_type = get_mem_type(dm->adev, old_plane_state->fb->obj[0],
+    true);
+
  /*
   * Only allow immediate flips for fast updates that don't
- * change FB pitch, DCC state, rotation or mirroing.
+ * change memory domain, FB pitch, DCC state, rotation or
+ * mirroring.
   */
  bundle->flip_addrs[planes_count].flip_immediate =
  crtc->state->async_flip &&
-    acrtc_state->update_type == UPDATE_TYPE_FAST;
+    acrtc_state->update_type == UPDATE_TYPE_FAST &&
+    (!mem_type || (mem_type && get_mem_type(dm->adev,
+    fb->obj[0],
+    false) ==
+   mem_type));
  timestamp_ns = ktime_get_ns();
bundle->flip_addrs[planes_count].flip_timestamp_in_us = 
div_u64(timestamp_ns, 1000);





--
Hamza



Re: [PATCH v2] drm/amd/display: Check & log if receiver supports MST, DSC & FEC.

2023-04-17 Thread Aurabindo Pillai




On 4/15/23 14:27, Srinivasan Shanmugam wrote:

After reading from receiver via DPCD, check & log if it supports MST,
DSC & FEC

Cc: Aurabindo Pillai 
Cc: Fangzhi Zuo 
Signed-off-by: Srinivasan Shanmugam 
---

v2:

  - Added %s: to print the function name.

  .../amd/display/dc/link/protocols/link_dp_capability.c   | 9 +
  1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c 
b/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c
index ba98013fecd0..f93fc35a1a50 100644
--- a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c
+++ b/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c
@@ -1554,6 +1554,8 @@ static bool retrieve_link_cap(struct dc_link *link)
int i;
struct dp_sink_hw_fw_revision dp_hw_fw_revision;
const uint32_t post_oui_delay = 30; // 30ms
+   bool is_fec_supported = false;
+   bool is_dsc_supported = false;
  
  	memset(dpcd_data, '\0', sizeof(dpcd_data));

memset(&down_strm_port_count,
@@ -1696,6 +1698,7 @@ static bool retrieve_link_cap(struct dc_link *link)
  
  	/* TODO - decouple raw mst capability from policy decision */

link->dpcd_caps.is_mst_capable = read_is_mst_supported(link);
+   DC_LOG_DC("%s: MST_Support: %s\n", __func__, 
str_yes_no(link->dpcd_caps.is_mst_capable));
  
  	get_active_converter_info(ds_port.byte, link);
  
@@ -1803,6 +1806,12 @@ static bool retrieve_link_cap(struct dc_link *link)

DP_DSC_SUPPORT,
link->dpcd_caps.dsc_caps.dsc_basic_caps.raw,

sizeof(link->dpcd_caps.dsc_caps.dsc_basic_caps.raw));
+   if (status == DC_OK) {
+   is_fec_supported = link->dpcd_caps.fec_cap.raw & 0x1;
+   is_dsc_supported = 
link->dpcd_caps.dsc_caps.dsc_basic_caps.raw[0] & 0x1;


Can we use the defined struct instead of the bitwise logic here, like 
fec_cap.bits.FEC_CAPABLE? Makes it more readable.


For DSC, it would be useful to print both basic DSC and passthrough 
capability.



+   DC_LOG_DC("%s: FEC_Sink_Support: %s\n", __func__, 
str_yes_no(is_fec_supported));
+   DC_LOG_DC("%s: DSC_Sink_Support: %s\n", __func__, 
str_yes_no(is_dsc_supported));
+   }
if (link->dpcd_caps.dongle_type != DISPLAY_DONGLE_NONE) {
status = core_link_read_dpcd(
link,


Re: [PATCH] drm/amd/display: fix flickering caused by S/G mode

2023-04-17 Thread Christian König

Am 17.04.23 um 16:51 schrieb Hamza Mahfooz:


On 4/17/23 01:59, Christian König wrote:

Am 14.04.23 um 21:33 schrieb Hamza Mahfooz:

Currently, we allow the framebuffer for a given plane to move between
memory domains, however when that happens it causes the screen to
flicker, it is even possible for the framebuffer to change memory
domains on every plane update (causing a continuous flicker effect). 
So,
to fix this, don't perform an immediate flip in the aforementioned 
case.


That sounds strongly like you just forget to wait for the move to 
finish!


What is the order of things done here? E.g. who calls amdgpu_bo_pin() 
and who waits for fences for finish signaling? Is that maybe just in 
the wrong order?


The pinning logic is in dm_plane_helper_prepare_fb(). Also, it seems
like we wait for the fences in amdgpu_dm_atomic_commit_tail(), using
drm_atomic_helper_wait_for_fences(). The ordering should be fine as
well, since prepare_fb() is always called before atomic_commit_tail().


Ok, then why is there any flickering?

BTW reserving a fence slot is completely unnecessary. That looks like 
you copy&pasted the code from somewhere else without checking what it 
actually does.


Regards,
Christian.





Regards,
Christian.



Cc: sta...@vger.kernel.org
Fixes: 81d0bcf99009 ("drm/amdgpu: make display pinning more flexible 
(v2)")

Signed-off-by: Hamza Mahfooz 
---
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 41 
++-

  1 file changed, 39 insertions(+), 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 da3045fdcb6d..9a4e7408384a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7897,6 +7897,34 @@ static void amdgpu_dm_commit_cursors(struct 
drm_atomic_state *state)
  amdgpu_dm_plane_handle_cursor_update(plane, 
old_plane_state);

  }
+static inline uint32_t get_mem_type(struct amdgpu_device *adev,
+    struct drm_gem_object *obj,
+    bool check_domain)
+{
+    struct amdgpu_bo *abo = gem_to_amdgpu_bo(obj);
+    uint32_t mem_type;
+
+    if (unlikely(amdgpu_bo_reserve(abo, true)))
+    return 0;
+
+    if (unlikely(dma_resv_reserve_fences(abo->tbo.base.resv, 1)))
+    goto err;
+
+    if (check_domain &&
+    amdgpu_display_supported_domains(adev, abo->flags) !=
+    (AMDGPU_GEM_DOMAIN_VRAM | AMDGPU_GEM_DOMAIN_GTT))
+    goto err;
+
+    mem_type = abo->tbo.resource->mem_type;
+    amdgpu_bo_unreserve(abo);
+
+    return mem_type;
+
+err:
+    amdgpu_bo_unreserve(abo);
+    return 0;
+}
+
  static void amdgpu_dm_commit_planes(struct drm_atomic_state *state,
  struct dc_state *dc_state,
  struct drm_device *dev,
@@ -7916,6 +7944,7 @@ static void amdgpu_dm_commit_planes(struct 
drm_atomic_state *state,

to_dm_crtc_state(drm_atomic_get_old_crtc_state(state, pcrtc));
  int planes_count = 0, vpos, hpos;
  unsigned long flags;
+    uint32_t mem_type;
  u32 target_vblank, last_flip_vblank;
  bool vrr_active = amdgpu_dm_crtc_vrr_active(acrtc_state);
  bool cursor_update = false;
@@ -8035,13 +8064,21 @@ static void amdgpu_dm_commit_planes(struct 
drm_atomic_state *state,

  }
  }
+    mem_type = get_mem_type(dm->adev, old_plane_state->fb->obj[0],
+    true);
+
  /*
   * Only allow immediate flips for fast updates that don't
- * change FB pitch, DCC state, rotation or mirroing.
+ * change memory domain, FB pitch, DCC state, rotation or
+ * mirroring.
   */
  bundle->flip_addrs[planes_count].flip_immediate =
  crtc->state->async_flip &&
-    acrtc_state->update_type == UPDATE_TYPE_FAST;
+    acrtc_state->update_type == UPDATE_TYPE_FAST &&
+    (!mem_type || (mem_type && get_mem_type(dm->adev,
+    fb->obj[0],
+    false) ==
+   mem_type));
  timestamp_ns = ktime_get_ns();
bundle->flip_addrs[planes_count].flip_timestamp_in_us = 
div_u64(timestamp_ns, 1000);






Re: [PATCH] drm/ttm: fix null-ptr-deref in radeon_ttm_tt_populate()

2023-04-17 Thread Nikita Zhandarovich



On 4/17/23 07:42, Christian König wrote:
> 
> 
> Am 17.04.23 um 16:34 schrieb Nikita Zhandarovich:
>> Currently, drm_prime_sg_to_page_addr_arrays() dereferences 'gtt->ttm'
>> without ensuring that 'gtt' (and therefore 'gtt->tmm') is not NULL.
>>
>> Fix this by testing 'gtt' for NULL value before dereferencing.
>>
>> Found by Linux Verification Center (linuxtesting.org) with static
>> analysis tool SVACE.
>>
>> Fixes: 40f5cf996991 ("drm/radeon: add PRIME support (v2)")
>> Signed-off-by: Nikita Zhandarovich 
>> ---
>>   drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
>> b/drivers/gpu/drm/radeon/radeon_ttm.c
>> index 1e8e287e113c..33d01c3bdee4 100644
>> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
>> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
>> @@ -553,7 +553,7 @@ static int radeon_ttm_tt_populate(struct
>> ttm_device *bdev,
>>   return 0;
>>   }
>>   -    if (slave && ttm->sg) {
>> +    if (gtt && slave && ttm->sg) {
> 
> The gtt variable is derived from the ttm variable and so never NULL
> here. The only case when this can be NULL is for AGP and IIRC we don't
> support DMA-buf in this case.
> 
>>   drm_prime_sg_to_dma_addr_array(ttm->sg, gtt->ttm.dma_address,
> 
> Just use ttm->dma_addresses instead of gtt->ttm.dma_address here to make
> your automated checker happy.
> 
> Regards,
> Christian.
> 
>>  ttm->num_pages);
>>   return 0;
> 

Thank you for your reply, you are absolutely right.
Apologies for wasting your time.

Nikita


Re: [PATCH] drm/amd/display: set variable dccg314_init storage-class-specifier to static

2023-04-17 Thread Hamza Mahfooz

On 4/15/23 11:17, Tom Rix wrote:

smatch reports
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn314/dcn314_dccg.c:277:6: warning: 
symbol
   'dccg314_init' was not declared. Should it be static?

This variable is only used in one file so should be static.

Signed-off-by: Tom Rix 


Applied, thanks!


---
  drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c 
b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c
index 6f879265ad9c..de7bfba2c179 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c
@@ -274,7 +274,7 @@ static void dccg314_set_dpstreamclk(
}
  }
  
-void dccg314_init(struct dccg *dccg)

+static void dccg314_init(struct dccg *dccg)
  {
int otg_inst;
  

--
Hamza



Re: [PATCH] drm/amd/display: fix flickering caused by S/G mode

2023-04-17 Thread Hamza Mahfooz



On 4/17/23 01:59, Christian König wrote:

Am 14.04.23 um 21:33 schrieb Hamza Mahfooz:

Currently, we allow the framebuffer for a given plane to move between
memory domains, however when that happens it causes the screen to
flicker, it is even possible for the framebuffer to change memory
domains on every plane update (causing a continuous flicker effect). So,
to fix this, don't perform an immediate flip in the aforementioned case.


That sounds strongly like you just forget to wait for the move to finish!

What is the order of things done here? E.g. who calls amdgpu_bo_pin() 
and who waits for fences for finish signaling? Is that maybe just in the 
wrong order?


The pinning logic is in dm_plane_helper_prepare_fb(). Also, it seems
like we wait for the fences in amdgpu_dm_atomic_commit_tail(), using
drm_atomic_helper_wait_for_fences(). The ordering should be fine as
well, since prepare_fb() is always called before atomic_commit_tail().



Regards,
Christian.



Cc: sta...@vger.kernel.org
Fixes: 81d0bcf99009 ("drm/amdgpu: make display pinning more flexible 
(v2)")

Signed-off-by: Hamza Mahfooz 
---
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 41 ++-
  1 file changed, 39 insertions(+), 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 da3045fdcb6d..9a4e7408384a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7897,6 +7897,34 @@ static void amdgpu_dm_commit_cursors(struct 
drm_atomic_state *state)
  amdgpu_dm_plane_handle_cursor_update(plane, 
old_plane_state);

  }
+static inline uint32_t get_mem_type(struct amdgpu_device *adev,
+    struct drm_gem_object *obj,
+    bool check_domain)
+{
+    struct amdgpu_bo *abo = gem_to_amdgpu_bo(obj);
+    uint32_t mem_type;
+
+    if (unlikely(amdgpu_bo_reserve(abo, true)))
+    return 0;
+
+    if (unlikely(dma_resv_reserve_fences(abo->tbo.base.resv, 1)))
+    goto err;
+
+    if (check_domain &&
+    amdgpu_display_supported_domains(adev, abo->flags) !=
+    (AMDGPU_GEM_DOMAIN_VRAM | AMDGPU_GEM_DOMAIN_GTT))
+    goto err;
+
+    mem_type = abo->tbo.resource->mem_type;
+    amdgpu_bo_unreserve(abo);
+
+    return mem_type;
+
+err:
+    amdgpu_bo_unreserve(abo);
+    return 0;
+}
+
  static void amdgpu_dm_commit_planes(struct drm_atomic_state *state,
  struct dc_state *dc_state,
  struct drm_device *dev,
@@ -7916,6 +7944,7 @@ static void amdgpu_dm_commit_planes(struct 
drm_atomic_state *state,
  to_dm_crtc_state(drm_atomic_get_old_crtc_state(state, 
pcrtc));

  int planes_count = 0, vpos, hpos;
  unsigned long flags;
+    uint32_t mem_type;
  u32 target_vblank, last_flip_vblank;
  bool vrr_active = amdgpu_dm_crtc_vrr_active(acrtc_state);
  bool cursor_update = false;
@@ -8035,13 +8064,21 @@ static void amdgpu_dm_commit_planes(struct 
drm_atomic_state *state,

  }
  }
+    mem_type = get_mem_type(dm->adev, old_plane_state->fb->obj[0],
+    true);
+
  /*
   * Only allow immediate flips for fast updates that don't
- * change FB pitch, DCC state, rotation or mirroing.
+ * change memory domain, FB pitch, DCC state, rotation or
+ * mirroring.
   */
  bundle->flip_addrs[planes_count].flip_immediate =
  crtc->state->async_flip &&
-    acrtc_state->update_type == UPDATE_TYPE_FAST;
+    acrtc_state->update_type == UPDATE_TYPE_FAST &&
+    (!mem_type || (mem_type && get_mem_type(dm->adev,
+    fb->obj[0],
+    false) ==
+   mem_type));
  timestamp_ns = ktime_get_ns();
  bundle->flip_addrs[planes_count].flip_timestamp_in_us = 
div_u64(timestamp_ns, 1000);



--
Hamza



[PATCH] drm/ttm: fix null-ptr-deref in radeon_ttm_tt_populate()

2023-04-17 Thread Nikita Zhandarovich
Currently, drm_prime_sg_to_page_addr_arrays() dereferences 'gtt->ttm'
without ensuring that 'gtt' (and therefore 'gtt->tmm') is not NULL.

Fix this by testing 'gtt' for NULL value before dereferencing.

Found by Linux Verification Center (linuxtesting.org) with static
analysis tool SVACE.

Fixes: 40f5cf996991 ("drm/radeon: add PRIME support (v2)")
Signed-off-by: Nikita Zhandarovich 
---
 drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 1e8e287e113c..33d01c3bdee4 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -553,7 +553,7 @@ static int radeon_ttm_tt_populate(struct ttm_device *bdev,
return 0;
}
 
-   if (slave && ttm->sg) {
+   if (gtt && slave && ttm->sg) {
drm_prime_sg_to_dma_addr_array(ttm->sg, gtt->ttm.dma_address,
   ttm->num_pages);
return 0;
-- 
2.25.1



Re: [PATCH] drm/ttm: fix null-ptr-deref in radeon_ttm_tt_populate()

2023-04-17 Thread Christian König




Am 17.04.23 um 16:34 schrieb Nikita Zhandarovich:

Currently, drm_prime_sg_to_page_addr_arrays() dereferences 'gtt->ttm'
without ensuring that 'gtt' (and therefore 'gtt->tmm') is not NULL.

Fix this by testing 'gtt' for NULL value before dereferencing.

Found by Linux Verification Center (linuxtesting.org) with static
analysis tool SVACE.

Fixes: 40f5cf996991 ("drm/radeon: add PRIME support (v2)")
Signed-off-by: Nikita Zhandarovich 
---
  drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 1e8e287e113c..33d01c3bdee4 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -553,7 +553,7 @@ static int radeon_ttm_tt_populate(struct ttm_device *bdev,
return 0;
}
  
-	if (slave && ttm->sg) {

+   if (gtt && slave && ttm->sg) {


The gtt variable is derived from the ttm variable and so never NULL 
here. The only case when this can be NULL is for AGP and IIRC we don't 
support DMA-buf in this case.



drm_prime_sg_to_dma_addr_array(ttm->sg, gtt->ttm.dma_address,


Just use ttm->dma_addresses instead of gtt->ttm.dma_address here to make 
your automated checker happy.


Regards,
Christian.


   ttm->num_pages);
return 0;




RE: [PATCH 00/66] DC Patches Apr 17th, 2023

2023-04-17 Thread Wheeler, Daniel
[Public]

Hi all,
 
This week this patchset was tested on the following systems:
 
Lenovo Thinkpad T14s Gen2, with AMD Ryzen 5 5650U 
Lenovo Thinkpad T13s Gen4 with AMD Ryzen 5 6600U
Reference AMD RX6800
 
These systems were tested on the following display types: 
eDP, (1080p 60hz [5650U]) (1920x1200 60hz [6600U]) (2560x1600 120hz[6600U])
VGA and DVI (1680x1050 60HZ [DP to VGA/DVI, USB-C to DVI/VGA])
DP/HDMI/USB-C (1440p 170hz, 4k 60hz, 4k 144hz [Includes USB-C to DP/HDMI 
adapters])
 
MST tested with Startech MST14DP123DP and 2x 4k 60Hz displays
DSC tested with Cable Matters 101075 (DP to 3x DP), and 201375 (USB-C to 3x DP) 
with 3x 4k60 displays
HP Hook G2 with 1 and 2 4k60 Displays
 
The testing is a mix of automated and manual tests. Manual testing includes 
(but is not limited to):
Changing display configurations and settings
Benchmark testing
Feature testing (Freesync, etc.)
 
Automated testing includes (but is not limited to):
Script testing (scripts to automate some of the manual checks)
IGT testing
 
The patchset consists of the amd-staging-drm-next branch (Head commit - 
c940e09ec9ad drm/amd/display: 3.2.230) with new patches added on top of it. 
This branch is used for both Ubuntu and Chrome OS testing (ChromeOS on a 
bi-weekly basis).
 
 
Tested on Ubuntu 22.04.1 and Chrome OS
 
Tested-by: Daniel Wheeler 
 
 
Thank you,
 
Dan Wheeler
Sr. Technologist | AMD
SW Display
--
1 Commerce Valley Dr E, Thornhill, ON L3T 7X6
amd.com

-Original Message-
From: Zhuo, Qingqing (Lillian)  
Sent: April 14, 2023 11:52 AM
To: amd-gfx@lists.freedesktop.org
Cc: Wentland, Harry ; Li, Sun peng (Leo) 
; Lakha, Bhawanpreet ; Siqueira, 
Rodrigo ; Pillai, Aurabindo 
; Zhuo, Qingqing (Lillian) ; 
Li, Roman ; Lin, Wayne ; Wang, Chao-kai 
(Stylon) ; Chiu, Solomon ; Kotarac, 
Pavle ; Gutierrez, Agustin ; 
Wheeler, Daniel 
Subject: [PATCH 00/66] DC Patches Apr 17th, 2023

This DC patchset brings improvements in multiple areas. In summary, we 
highlight:
- FW Release 0.0.162.0
- Enable FPO+Vactivate
- Support for VESA SCR on OLED
- Refactor DMUB commands
- Fixes in secure display, modeset, memleak and more
- Picked up missed patches in history

Cc: Daniel Wheeler 

Alan Liu (1):
  drm/amd/display: Fix in disabling secure display

Alex Hung (2):
  drm/amd/display: allow edp updates for virtual signal
  drm/amd/display: fix a divided-by-zero error

Alvin Lee (5):
  drm/amd/display: Only consider DISPCLK when using optimized boot path
  drm/amd/display: Reduce SubVP + DRR stretch margin
  drm/amd/display: Set watermarks set D equal to A
  drm/amd/display: Enable FPO + Vactive
  drm/amd/display: Update DTBCLK for DCN32

Anthony Koo (1):
  drm/amd/display: [FW Promotion] Release 0.0.162.0

Aric Cyr (1):
  drm/amd/display: 3.2.231

Aurabindo Pillai (13):
  drm/amd/display: Fix hang when skipping modeset
  drm/amd/display: remove incorrect early return
  drm/amd/display: Fixes for dcn32_clk_mgr implementation
  drm/amd/display: Do not clear GPINT register when releasing DMUB from
reset
  drm/amd/display: Update bounding box values for DCN321
  drm/amd/display: add support for low bpc
  drm/amd/display: Set DRAM clock if retraining is required
  drm/amd/display: Add check for PState change in DCN32
  drm/amd/display: Remove DET check from DCN32
  drm/amd/display: Add extra check for 444 16 format
  drm/amd/display: Add FAMS capability to DCN31
  drm/amd/display: Add FAMS related definitions and documenation for
enum fields
  drm/amd/display: remove some unused variables

Cruise Hung (1):
  drm/amd/display: Reset OUTBOX0 r/w pointer on DMUB reset

Daniel Miess (1):
  drm/amd/display: limit timing for single dimm memory

Dmytro Laktyushkin (4):
  drm/amd/display: update max streams per surface
  drm/amd/display: add extra dc odm debug options
  drm/amd/display: set dcn315 lb bpp to 48
  drm/amd/display: Limit nv21 dst_y

Eric Yang (1):
  drm/amd/display: add mechanism to skip DCN init

Hersen Wu (2):
  drm/amd/display: fix memleak in aconnector->timing_requested
  drm/amd/display: fix access hdcp_workqueue assert

Igor Kravchenko (1):
  drm/amd/display: Set min_width and min_height capability for DCN30

Iswara Nagulendran (1):
  drm/amd/display: Adding support for VESA SCR

Jasdeep Dhillon (1):
  drm/amd/display: Isolate remaining FPU code in DCN32

Jingwen Zhu (1):
  drm/amd/display: Improvement for handling edp link training fails

Josip Pavic (3):
  drm/amd/display: copy dmub caps to dc on dcn31
  drm/amd/display: refactor dmub commands into single function
  drm/amd/display: drain dmub inbox if queue is full

Krunoslav Kovac (1):
  drm/amd/display: 3-plane MPO enablement for DCN321

Leon Huang (2):
  drm/amd/display: Refactor ABM feature
  drm/amd/display: Fix ABM pipe/backlight issues when change backlight

Meenakshikumar Somasundaram (1):
  drm/amd/display: Adjust dmub outbox notification enable

Michael

Re: XDC 2023: Registration & Call for Proposals now open!

2023-04-17 Thread Samuel Iglesias Gonsálvez


On 4/17/23 13:41, Samuel Iglesias Gonsálvez wrote:


Hello!

Registration & Call for Proposals are now open for XDC 2023, which will
take place on October 17-19, 2023.


Forgot to mention, it will be in A Coruña, Spain :)


https://xdc2023.x.org

As usual, the conference is free of charge and open to the general
public. If you plan on attending, please make sure to register as early
as possible!

In order to register as attendee, you will therefore need to register
via the XDC website.

https://indico.freedesktop.org/event/4/registrations/

In addition to registration, the CfP is now open for talks, workshops
and demos at XDC 2023. While any serious proposal will be gratefully
considered, topics of interest to X.Org and freedesktop.org developers
are encouraged. The program focus is on new development, ongoing
challenges and anything else that will spark discussions among
attendees in the hallway track.

We are open to talks across all layers of the graphics stack, from the
kernel to desktop environments / graphical applications and about how
to make things better for the developers who build them. Head to the
CfP page to learn more:

https://indico.freedesktop.org/event/4/abstracts/

The deadline for submissions is Monday, 17 July 2023 (23:59 CEST)

Check out our Reimbursement Policy to accept speaker expenses:

https://www.x.org/wiki/XorgFoundation/Policies/Reimbursement/

If you have any questions, please send me an email to
siglesias AT igalia.com, adding on Cc the X.org board (board
at foundation.x.org).

And please keep in mind, you can follow us on Twitter for all the latest
updates and to stay connected:

https://twitter.com/XOrgDevConf

Best,

Sam



OpenPGP_0x7FF4BA32F17DC343.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


XDC 2023: Registration & Call for Proposals now open!

2023-04-17 Thread Samuel Iglesias Gonsálvez

Hello!

Registration & Call for Proposals are now open for XDC 2023, which will
take place on October 17-19, 2023.

https://xdc2023.x.org

As usual, the conference is free of charge and open to the general
public. If you plan on attending, please make sure to register as early
as possible!

In order to register as attendee, you will therefore need to register
via the XDC website.

https://indico.freedesktop.org/event/4/registrations/

In addition to registration, the CfP is now open for talks, workshops
and demos at XDC 2023. While any serious proposal will be gratefully
considered, topics of interest to X.Org and freedesktop.org developers
are encouraged. The program focus is on new development, ongoing
challenges and anything else that will spark discussions among
attendees in the hallway track.

We are open to talks across all layers of the graphics stack, from the
kernel to desktop environments / graphical applications and about how
to make things better for the developers who build them. Head to the
CfP page to learn more:

https://indico.freedesktop.org/event/4/abstracts/

The deadline for submissions is Monday, 17 July 2023 (23:59 CEST)

Check out our Reimbursement Policy to accept speaker expenses:

https://www.x.org/wiki/XorgFoundation/Policies/Reimbursement/

If you have any questions, please send me an email to
siglesias AT igalia.com, adding on Cc the X.org board (board
at foundation.x.org).

And please keep in mind, you can follow us on Twitter for all the latest
updates and to stay connected:

https://twitter.com/XOrgDevConf

Best,

Sam



OpenPGP_0x7FF4BA32F17DC343.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH 1/7] mm/gup: remove unused vmas parameter from get_user_pages()

2023-04-17 Thread Jason Gunthorpe
On Sat, Apr 15, 2023 at 12:27:13AM +0100, Lorenzo Stoakes wrote:
> No invocation of get_user_pages() uses the vmas parameter, so remove
> it.
> 
> The GUP API is confusing and caveated. Recent changes have done much to
> improve that, however there is more we can do. Exporting vmas is a prime
> target as the caller has to be extremely careful to preclude their use
> after the mmap_lock has expired or otherwise be left with dangling
> pointers.
> 
> Removing the vmas parameter focuses the GUP functions upon their primary
> purpose - pinning (and outputting) pages as well as performing the actions
> implied by the input flags.
> 
> This is part of a patch series aiming to remove the vmas parameter
> altogether.
> 
> Signed-off-by: Lorenzo Stoakes 
> Suggested-by: Matthew Wilcox (Oracle) 
> ---
>  arch/x86/kernel/cpu/sgx/ioctl.c | 2 +-
>  drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
>  drivers/misc/sgi-gru/grufault.c | 2 +-
>  include/linux/mm.h  | 3 +--
>  mm/gup.c| 9 +++--
>  mm/gup_test.c   | 5 ++---
>  virt/kvm/kvm_main.c | 4 ++--
>  7 files changed, 11 insertions(+), 16 deletions(-)

Reviewed-by: Jason Gunthorpe 

Jason


Re: [PATCH v3 1/7] mm/gup: remove unused vmas parameter from get_user_pages()

2023-04-17 Thread David Hildenbrand

On 15.04.23 14:09, Lorenzo Stoakes wrote:

No invocation of get_user_pages() uses the vmas parameter, so remove
it.

The GUP API is confusing and caveated. Recent changes have done much to
improve that, however there is more we can do. Exporting vmas is a prime
target as the caller has to be extremely careful to preclude their use
after the mmap_lock has expired or otherwise be left with dangling
pointers.

Removing the vmas parameter focuses the GUP functions upon their primary
purpose - pinning (and outputting) pages as well as performing the actions
implied by the input flags.

This is part of a patch series aiming to remove the vmas parameter
altogether.

Signed-off-by: Lorenzo Stoakes 
Suggested-by: Matthew Wilcox (Oracle) 
Acked-by: Greg Kroah-Hartman 
---


Acked-by: David Hildenbrand 

--
Thanks,

David / dhildenb



Re: 2023 X.Org Foundation Membership deadline for voting in the election

2023-04-17 Thread Laurent Pinchart
Hi Ricardo,

On Mon, Mar 13, 2023 at 04:22:54PM +0100, Ricardo Garcia wrote:
> This is a reminder that the deadline for new memberships and renewals
> finishes in a couple of weeks. Original email follows.
> 
> Thanks for your attention.

I don't know if I'm the only one affected by this issue, but I've just
received today two months of e-mails from x.org, including all the
reminders aboud membership renewal and election nomination period. This
isn't the first time this happens, and the last time I was told there
was no automated process to quick the mail queues when errors happen,
making mails pile up forever on x.org's side until someone handles it
manually. This is something you really want to automate, or at least
monitored.

> On Wed, 2023-02-15 at 16:58 +0100, Ricardo Garcia wrote:
> > The 2023 X.Org Foundation elections are rapidly approaching. We will be
> > forwarding the election schedule and nominating process to the
> > membership shortly.
> > 
> > Please note that only current members can vote in the upcoming election,
> > and that the deadline for new memberships or renewals to vote in the
> > upcoming election is 26 March 2023 at 23:59 UTC.
> > 
> > If you are interested in joining the X.Org Foundation or in renewing
> > your membership, please visit the membership system site at:
> > https://members.x.org/
> > 
> > Ricardo Garcia, on behalf of the X.Org elections committee

-- 
Regards,

Laurent Pinchart


Re: [PATCH] drm/amdgpu: release gpu full access after "amdgpu_device_ip_late_init"

2023-04-17 Thread JingWen Chen
Reviewed-by: jingwen.ch...@amd.com

On 4/14/23 4:41 PM, Chong Li wrote:
> [WHY]
>  Function "amdgpu_irq_update()" called by "amdgpu_device_ip_late_init()" is 
> an atomic context.
>  We shouldn't access registers through KIQ since "msleep()" may be called in 
> "amdgpu_kiq_rreg()".
>
> [HOW]
>  Move function "amdgpu_virt_release_full_gpu()" after function 
> "amdgpu_device_ip_late_init()",
>  to ensure that registers be accessed through RLCG instead of KIQ.
>
> Call Trace:
>   
>   show_stack+0x52/0x69
>   dump_stack_lvl+0x49/0x6d
>   dump_stack+0x10/0x18
>   __schedule_bug.cold+0x4f/0x6b
>   __schedule+0x473/0x5d0
>   ? __wake_up_klogd.part.0+0x40/0x70
>   ? vprintk_emit+0xbe/0x1f0
>   schedule+0x68/0x110
>   schedule_timeout+0x87/0x160
>   ? timer_migration_handler+0xa0/0xa0
>   msleep+0x2d/0x50
>   amdgpu_kiq_rreg+0x18d/0x1f0 [amdgpu]
>   amdgpu_device_rreg.part.0+0x59/0xd0 [amdgpu]
>   amdgpu_device_rreg+0x3a/0x50 [amdgpu]
>   amdgpu_sriov_rreg+0x3c/0xb0 [amdgpu]
>   gfx_v10_0_set_gfx_eop_interrupt_state.constprop.0+0x16c/0x190 [amdgpu]
>   gfx_v10_0_set_eop_interrupt_state+0xa5/0xb0 [amdgpu]
>   amdgpu_irq_update+0x53/0x80 [amdgpu]
>   amdgpu_irq_get+0x7c/0xb0 [amdgpu]
>   amdgpu_fence_driver_hw_init+0x58/0x90 [amdgpu]
>   amdgpu_device_init.cold+0x16b7/0x2022 [amdgpu]
>
> Signed-off-by: Chong Li 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 32 --
>  1 file changed, 17 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 051b9e231cf4..ee21a99ab4d4 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -2538,8 +2538,6 @@ static int amdgpu_device_ip_init(struct amdgpu_device 
> *adev)
>   amdgpu_fru_get_product_info(adev);
>  
>  init_failed:
> - if (amdgpu_sriov_vf(adev))
> - amdgpu_virt_release_full_gpu(adev, true);
>  
>   return r;
>  }
> @@ -3856,18 +3854,6 @@ int amdgpu_device_init(struct amdgpu_device *adev,
>  
>   r = amdgpu_device_ip_init(adev);
>   if (r) {
> - /* failed in exclusive mode due to timeout */
> - if (amdgpu_sriov_vf(adev) &&
> - !amdgpu_sriov_runtime(adev) &&
> - amdgpu_virt_mmio_blocked(adev) &&
> - !amdgpu_virt_wait_reset(adev)) {
> - dev_err(adev->dev, "VF exclusive mode timeout\n");
> - /* Don't send request since VF is inactive. */
> - adev->virt.caps &= ~AMDGPU_SRIOV_CAPS_RUNTIME;
> - adev->virt.ops = NULL;
> - r = -EAGAIN;
> - goto release_ras_con;
> - }
>   dev_err(adev->dev, "amdgpu_device_ip_init failed\n");
>   amdgpu_vf_error_put(adev, AMDGIM_ERROR_VF_AMDGPU_INIT_FAIL, 0, 
> 0);
>   goto release_ras_con;
> @@ -3936,8 +3922,10 @@ int amdgpu_device_init(struct amdgpu_device *adev,
>  msecs_to_jiffies(AMDGPU_RESUME_MS));
>   }
>  
> - if (amdgpu_sriov_vf(adev))
> + if (amdgpu_sriov_vf(adev)) {
> + amdgpu_virt_release_full_gpu(adev, true);
>   flush_delayed_work(&adev->delayed_init_work);
> + }
>  
>   r = sysfs_create_files(&adev->dev->kobj, amdgpu_dev_attributes);
>   if (r)
> @@ -3977,6 +3965,20 @@ int amdgpu_device_init(struct amdgpu_device *adev,
>   return 0;
>  
>  release_ras_con:
> + if (amdgpu_sriov_vf(adev))
> + amdgpu_virt_release_full_gpu(adev, true);
> +
> + /* failed in exclusive mode due to timeout */
> + if (amdgpu_sriov_vf(adev) &&
> + !amdgpu_sriov_runtime(adev) &&
> + amdgpu_virt_mmio_blocked(adev) &&
> + !amdgpu_virt_wait_reset(adev)) {
> + dev_err(adev->dev, "VF exclusive mode timeout\n");
> + /* Don't send request since VF is inactive. */
> + adev->virt.caps &= ~AMDGPU_SRIOV_CAPS_RUNTIME;
> + adev->virt.ops = NULL;
> + r = -EAGAIN;
> + }
>   amdgpu_release_ras_context(adev);
>  
>  failed:


[PATCH v3 1/7] mm/gup: remove unused vmas parameter from get_user_pages()

2023-04-17 Thread Lorenzo Stoakes
No invocation of get_user_pages() uses the vmas parameter, so remove
it.

The GUP API is confusing and caveated. Recent changes have done much to
improve that, however there is more we can do. Exporting vmas is a prime
target as the caller has to be extremely careful to preclude their use
after the mmap_lock has expired or otherwise be left with dangling
pointers.

Removing the vmas parameter focuses the GUP functions upon their primary
purpose - pinning (and outputting) pages as well as performing the actions
implied by the input flags.

This is part of a patch series aiming to remove the vmas parameter
altogether.

Signed-off-by: Lorenzo Stoakes 
Suggested-by: Matthew Wilcox (Oracle) 
Acked-by: Greg Kroah-Hartman 
---
 arch/x86/kernel/cpu/sgx/ioctl.c | 2 +-
 drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
 drivers/misc/sgi-gru/grufault.c | 2 +-
 include/linux/mm.h  | 3 +--
 mm/gup.c| 9 +++--
 mm/gup_test.c   | 5 ++---
 virt/kvm/kvm_main.c | 2 +-
 7 files changed, 10 insertions(+), 15 deletions(-)

diff --git a/arch/x86/kernel/cpu/sgx/ioctl.c b/arch/x86/kernel/cpu/sgx/ioctl.c
index 21ca0a831b70..5d390df21440 100644
--- a/arch/x86/kernel/cpu/sgx/ioctl.c
+++ b/arch/x86/kernel/cpu/sgx/ioctl.c
@@ -214,7 +214,7 @@ static int __sgx_encl_add_page(struct sgx_encl *encl,
if (!(vma->vm_flags & VM_MAYEXEC))
return -EACCES;
 
-   ret = get_user_pages(src, 1, 0, &src_page, NULL);
+   ret = get_user_pages(src, 1, 0, &src_page);
if (ret < 1)
return -EFAULT;
 
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 1e8e287e113c..0597540f0dde 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -362,7 +362,7 @@ static int radeon_ttm_tt_pin_userptr(struct ttm_device 
*bdev, struct ttm_tt *ttm
struct page **pages = ttm->pages + pinned;
 
r = get_user_pages(userptr, num_pages, write ? FOLL_WRITE : 0,
-  pages, NULL);
+  pages);
if (r < 0)
goto release_pages;
 
diff --git a/drivers/misc/sgi-gru/grufault.c b/drivers/misc/sgi-gru/grufault.c
index b836936e9747..378cf02a2aa1 100644
--- a/drivers/misc/sgi-gru/grufault.c
+++ b/drivers/misc/sgi-gru/grufault.c
@@ -185,7 +185,7 @@ static int non_atomic_pte_lookup(struct vm_area_struct *vma,
 #else
*pageshift = PAGE_SHIFT;
 #endif
-   if (get_user_pages(vaddr, 1, write ? FOLL_WRITE : 0, &page, NULL) <= 0)
+   if (get_user_pages(vaddr, 1, write ? FOLL_WRITE : 0, &page) <= 0)
return -EFAULT;
*paddr = page_to_phys(page);
put_page(page);
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 37554b08bb28..b14cc4972d0b 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2380,8 +2380,7 @@ long pin_user_pages_remote(struct mm_struct *mm,
   unsigned int gup_flags, struct page **pages,
   struct vm_area_struct **vmas, int *locked);
 long get_user_pages(unsigned long start, unsigned long nr_pages,
-   unsigned int gup_flags, struct page **pages,
-   struct vm_area_struct **vmas);
+   unsigned int gup_flags, struct page **pages);
 long pin_user_pages(unsigned long start, unsigned long nr_pages,
unsigned int gup_flags, struct page **pages,
struct vm_area_struct **vmas);
diff --git a/mm/gup.c b/mm/gup.c
index 1f72a717232b..7e454d6b157e 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -2251,8 +2251,6 @@ long get_user_pages_remote(struct mm_struct *mm,
  * @pages:  array that receives pointers to the pages pinned.
  *  Should be at least nr_pages long. Or NULL, if caller
  *  only intends to ensure the pages are faulted in.
- * @vmas:   array of pointers to vmas corresponding to each page.
- *  Or NULL if the caller does not require them.
  *
  * This is the same as get_user_pages_remote(), just with a less-flexible
  * calling convention where we assume that the mm being operated on belongs to
@@ -2260,16 +2258,15 @@ long get_user_pages_remote(struct mm_struct *mm,
  * obviously don't pass FOLL_REMOTE in here.
  */
 long get_user_pages(unsigned long start, unsigned long nr_pages,
-   unsigned int gup_flags, struct page **pages,
-   struct vm_area_struct **vmas)
+   unsigned int gup_flags, struct page **pages)
 {
int locked = 1;
 
-   if (!is_valid_gup_args(pages, vmas, NULL, &gup_flags, FOLL_TOUCH))
+   if (!is_valid_gup_args(pages, NULL, NULL, &gup_flags, FOLL_TOUCH))
return -EINVAL;
 
return __get_user_pages_locked(current->mm, start, nr_pages, pages,
-  vmas, &locked, gup_flags);
+  

[PATCH 1/7] mm/gup: remove unused vmas parameter from get_user_pages()

2023-04-17 Thread Lorenzo Stoakes
No invocation of get_user_pages() uses the vmas parameter, so remove
it.

The GUP API is confusing and caveated. Recent changes have done much to
improve that, however there is more we can do. Exporting vmas is a prime
target as the caller has to be extremely careful to preclude their use
after the mmap_lock has expired or otherwise be left with dangling
pointers.

Removing the vmas parameter focuses the GUP functions upon their primary
purpose - pinning (and outputting) pages as well as performing the actions
implied by the input flags.

This is part of a patch series aiming to remove the vmas parameter
altogether.

Signed-off-by: Lorenzo Stoakes 
Suggested-by: Matthew Wilcox (Oracle) 
---
 arch/x86/kernel/cpu/sgx/ioctl.c | 2 +-
 drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
 drivers/misc/sgi-gru/grufault.c | 2 +-
 include/linux/mm.h  | 3 +--
 mm/gup.c| 9 +++--
 mm/gup_test.c   | 5 ++---
 virt/kvm/kvm_main.c | 4 ++--
 7 files changed, 11 insertions(+), 16 deletions(-)

diff --git a/arch/x86/kernel/cpu/sgx/ioctl.c b/arch/x86/kernel/cpu/sgx/ioctl.c
index 21ca0a831b70..5d390df21440 100644
--- a/arch/x86/kernel/cpu/sgx/ioctl.c
+++ b/arch/x86/kernel/cpu/sgx/ioctl.c
@@ -214,7 +214,7 @@ static int __sgx_encl_add_page(struct sgx_encl *encl,
if (!(vma->vm_flags & VM_MAYEXEC))
return -EACCES;
 
-   ret = get_user_pages(src, 1, 0, &src_page, NULL);
+   ret = get_user_pages(src, 1, 0, &src_page);
if (ret < 1)
return -EFAULT;
 
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 1e8e287e113c..0597540f0dde 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -362,7 +362,7 @@ static int radeon_ttm_tt_pin_userptr(struct ttm_device 
*bdev, struct ttm_tt *ttm
struct page **pages = ttm->pages + pinned;
 
r = get_user_pages(userptr, num_pages, write ? FOLL_WRITE : 0,
-  pages, NULL);
+  pages);
if (r < 0)
goto release_pages;
 
diff --git a/drivers/misc/sgi-gru/grufault.c b/drivers/misc/sgi-gru/grufault.c
index b836936e9747..378cf02a2aa1 100644
--- a/drivers/misc/sgi-gru/grufault.c
+++ b/drivers/misc/sgi-gru/grufault.c
@@ -185,7 +185,7 @@ static int non_atomic_pte_lookup(struct vm_area_struct *vma,
 #else
*pageshift = PAGE_SHIFT;
 #endif
-   if (get_user_pages(vaddr, 1, write ? FOLL_WRITE : 0, &page, NULL) <= 0)
+   if (get_user_pages(vaddr, 1, write ? FOLL_WRITE : 0, &page) <= 0)
return -EFAULT;
*paddr = page_to_phys(page);
put_page(page);
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 5d5ba1556ae9..faeed36c2d04 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2380,8 +2380,7 @@ long pin_user_pages_remote(struct mm_struct *mm,
   unsigned int gup_flags, struct page **pages,
   struct vm_area_struct **vmas, int *locked);
 long get_user_pages(unsigned long start, unsigned long nr_pages,
-   unsigned int gup_flags, struct page **pages,
-   struct vm_area_struct **vmas);
+   unsigned int gup_flags, struct page **pages);
 long pin_user_pages(unsigned long start, unsigned long nr_pages,
unsigned int gup_flags, struct page **pages,
struct vm_area_struct **vmas);
diff --git a/mm/gup.c b/mm/gup.c
index 1f72a717232b..7e454d6b157e 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -2251,8 +2251,6 @@ long get_user_pages_remote(struct mm_struct *mm,
  * @pages:  array that receives pointers to the pages pinned.
  *  Should be at least nr_pages long. Or NULL, if caller
  *  only intends to ensure the pages are faulted in.
- * @vmas:   array of pointers to vmas corresponding to each page.
- *  Or NULL if the caller does not require them.
  *
  * This is the same as get_user_pages_remote(), just with a less-flexible
  * calling convention where we assume that the mm being operated on belongs to
@@ -2260,16 +2258,15 @@ long get_user_pages_remote(struct mm_struct *mm,
  * obviously don't pass FOLL_REMOTE in here.
  */
 long get_user_pages(unsigned long start, unsigned long nr_pages,
-   unsigned int gup_flags, struct page **pages,
-   struct vm_area_struct **vmas)
+   unsigned int gup_flags, struct page **pages)
 {
int locked = 1;
 
-   if (!is_valid_gup_args(pages, vmas, NULL, &gup_flags, FOLL_TOUCH))
+   if (!is_valid_gup_args(pages, NULL, NULL, &gup_flags, FOLL_TOUCH))
return -EINVAL;
 
return __get_user_pages_locked(current->mm, start, nr_pages, pages,
-  vmas, &locked, gup_flags);
+  

[PATCH v2 1/7] mm/gup: remove unused vmas parameter from get_user_pages()

2023-04-17 Thread Lorenzo Stoakes
No invocation of get_user_pages() uses the vmas parameter, so remove
it.

The GUP API is confusing and caveated. Recent changes have done much to
improve that, however there is more we can do. Exporting vmas is a prime
target as the caller has to be extremely careful to preclude their use
after the mmap_lock has expired or otherwise be left with dangling
pointers.

Removing the vmas parameter focuses the GUP functions upon their primary
purpose - pinning (and outputting) pages as well as performing the actions
implied by the input flags.

This is part of a patch series aiming to remove the vmas parameter
altogether.

Signed-off-by: Lorenzo Stoakes 
Suggested-by: Matthew Wilcox (Oracle) 
Acked-by: Greg Kroah-Hartman 
---
 arch/x86/kernel/cpu/sgx/ioctl.c | 2 +-
 drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
 drivers/misc/sgi-gru/grufault.c | 2 +-
 include/linux/mm.h  | 3 +--
 mm/gup.c| 9 +++--
 mm/gup_test.c   | 5 ++---
 virt/kvm/kvm_main.c | 2 +-
 7 files changed, 10 insertions(+), 15 deletions(-)

diff --git a/arch/x86/kernel/cpu/sgx/ioctl.c b/arch/x86/kernel/cpu/sgx/ioctl.c
index 21ca0a831b70..5d390df21440 100644
--- a/arch/x86/kernel/cpu/sgx/ioctl.c
+++ b/arch/x86/kernel/cpu/sgx/ioctl.c
@@ -214,7 +214,7 @@ static int __sgx_encl_add_page(struct sgx_encl *encl,
if (!(vma->vm_flags & VM_MAYEXEC))
return -EACCES;
 
-   ret = get_user_pages(src, 1, 0, &src_page, NULL);
+   ret = get_user_pages(src, 1, 0, &src_page);
if (ret < 1)
return -EFAULT;
 
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 1e8e287e113c..0597540f0dde 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -362,7 +362,7 @@ static int radeon_ttm_tt_pin_userptr(struct ttm_device 
*bdev, struct ttm_tt *ttm
struct page **pages = ttm->pages + pinned;
 
r = get_user_pages(userptr, num_pages, write ? FOLL_WRITE : 0,
-  pages, NULL);
+  pages);
if (r < 0)
goto release_pages;
 
diff --git a/drivers/misc/sgi-gru/grufault.c b/drivers/misc/sgi-gru/grufault.c
index b836936e9747..378cf02a2aa1 100644
--- a/drivers/misc/sgi-gru/grufault.c
+++ b/drivers/misc/sgi-gru/grufault.c
@@ -185,7 +185,7 @@ static int non_atomic_pte_lookup(struct vm_area_struct *vma,
 #else
*pageshift = PAGE_SHIFT;
 #endif
-   if (get_user_pages(vaddr, 1, write ? FOLL_WRITE : 0, &page, NULL) <= 0)
+   if (get_user_pages(vaddr, 1, write ? FOLL_WRITE : 0, &page) <= 0)
return -EFAULT;
*paddr = page_to_phys(page);
put_page(page);
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 37554b08bb28..b14cc4972d0b 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2380,8 +2380,7 @@ long pin_user_pages_remote(struct mm_struct *mm,
   unsigned int gup_flags, struct page **pages,
   struct vm_area_struct **vmas, int *locked);
 long get_user_pages(unsigned long start, unsigned long nr_pages,
-   unsigned int gup_flags, struct page **pages,
-   struct vm_area_struct **vmas);
+   unsigned int gup_flags, struct page **pages);
 long pin_user_pages(unsigned long start, unsigned long nr_pages,
unsigned int gup_flags, struct page **pages,
struct vm_area_struct **vmas);
diff --git a/mm/gup.c b/mm/gup.c
index 1f72a717232b..7e454d6b157e 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -2251,8 +2251,6 @@ long get_user_pages_remote(struct mm_struct *mm,
  * @pages:  array that receives pointers to the pages pinned.
  *  Should be at least nr_pages long. Or NULL, if caller
  *  only intends to ensure the pages are faulted in.
- * @vmas:   array of pointers to vmas corresponding to each page.
- *  Or NULL if the caller does not require them.
  *
  * This is the same as get_user_pages_remote(), just with a less-flexible
  * calling convention where we assume that the mm being operated on belongs to
@@ -2260,16 +2258,15 @@ long get_user_pages_remote(struct mm_struct *mm,
  * obviously don't pass FOLL_REMOTE in here.
  */
 long get_user_pages(unsigned long start, unsigned long nr_pages,
-   unsigned int gup_flags, struct page **pages,
-   struct vm_area_struct **vmas)
+   unsigned int gup_flags, struct page **pages)
 {
int locked = 1;
 
-   if (!is_valid_gup_args(pages, vmas, NULL, &gup_flags, FOLL_TOUCH))
+   if (!is_valid_gup_args(pages, NULL, NULL, &gup_flags, FOLL_TOUCH))
return -EINVAL;
 
return __get_user_pages_locked(current->mm, start, nr_pages, pages,
-  vmas, &locked, gup_flags);
+  

[PATCH] drm/amd/display: set variable dccg314_init storage-class-specifier to static

2023-04-17 Thread Tom Rix
smatch reports
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn314/dcn314_dccg.c:277:6: warning: 
symbol
  'dccg314_init' was not declared. Should it be static?

This variable is only used in one file so should be static.

Signed-off-by: Tom Rix 
---
 drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c 
b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c
index 6f879265ad9c..de7bfba2c179 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c
@@ -274,7 +274,7 @@ static void dccg314_set_dpstreamclk(
}
 }
 
-void dccg314_init(struct dccg *dccg)
+static void dccg314_init(struct dccg *dccg)
 {
int otg_inst;
 
-- 
2.27.0



Re: [PATCH 1/7] mm/gup: remove unused vmas parameter from get_user_pages()

2023-04-17 Thread Greg Kroah-Hartman
On Sat, Apr 15, 2023 at 12:27:13AM +0100, Lorenzo Stoakes wrote:
> No invocation of get_user_pages() uses the vmas parameter, so remove
> it.
> 
> The GUP API is confusing and caveated. Recent changes have done much to
> improve that, however there is more we can do. Exporting vmas is a prime
> target as the caller has to be extremely careful to preclude their use
> after the mmap_lock has expired or otherwise be left with dangling
> pointers.
> 
> Removing the vmas parameter focuses the GUP functions upon their primary
> purpose - pinning (and outputting) pages as well as performing the actions
> implied by the input flags.
> 
> This is part of a patch series aiming to remove the vmas parameter
> altogether.
> 
> Signed-off-by: Lorenzo Stoakes 
> Suggested-by: Matthew Wilcox (Oracle) 

Acked-by: Greg Kroah-Hartman 


Re: [PATCH] drm/amdgpu: Fix desktop freezed after gpu-reset

2023-04-17 Thread Christian König

Am 14.04.23 um 18:22 schrieb Alan Liu:

[Why]
After gpu-reset, sometimes the driver would fail to enable vblank irq,
causing flip_done timed out and the desktop freezed.

During gpu-reset, we will disable and enable vblank irq in dm_suspend()
and dm_resume(). Later on in amdgpu_irq_gpu_reset_resume_helper(), we
will check irqs' refcount and decide to enable or disable the irqs
again.

However, we have 2 sets of API for controling vblank irq, one is
dm_vblank_get/put() and another is amdgpu_irq_get/put(). Each API has
its own refcount and flag to store the state of vblank irq, and they
are not synchronized.

In drm we use the first API to control vblank irq but in
amdgpu_irq_gpu_reset_resume_helper() we use the second set of API.

The failure happens when vblank irq was enabled by dm_vblank_get()
before gpu-reset, we have vblank->enabled true. However, during
gpu-reset, in amdgpu_irq_gpu_reset_resume_helper(), vblank irq's state
checked from amdgpu_irq_update() is DISABLED. So finally it will disable
vblank irq again. After gpu-reset, if there is a cursor plane commit,
the driver will try to enable vblank irq by calling drm_vblank_enable(),
but the vblank->enabled is still true, so it fails to turn on vblank
irq and causes flip_done can't be completed in vblank irq handler and
desktop become freezed.

[How]
Combining the 2 vblank control APIs by letting drm's API finally calls
amdgpu_irq's API, so the irq's refcount and state of both APIs can be
synchronized. Also add a check to prevent refcount from being less then
0 in amdgpu_irq_put().

v2:
- Add warning in amdgpu_irq_enable() if the irq is already disabled.
- Call dc_interrupt_set() in dm_set_vblank() to avoid refcount change
   if it is in gpu-reset.

Signed-off-by: Alan Liu 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c |  3 +++
  .../drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c  | 17 ++---
  2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
index a6aef488a822..c8413470e057 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
@@ -597,6 +597,9 @@ int amdgpu_irq_put(struct amdgpu_device *adev, struct 
amdgpu_irq_src *src,
if (!src->enabled_types || !src->funcs->set)
return -EINVAL;
  
+	if (WARN_ON(!amdgpu_irq_enabled(adev, src, type)))

+   return -EINVAL;
+
if (atomic_dec_and_test(&src->enabled_types[type]))
return amdgpu_irq_update(adev, src, type);
  
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c

index 1d924dc51a3e..514fefef109d 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
@@ -169,10 +169,21 @@ static inline int dm_set_vblank(struct drm_crtc *crtc, 
bool enable)
if (rc)
return rc;
  
-	irq_source = IRQ_TYPE_VBLANK + acrtc->otg_inst;

+   if (amdgpu_in_reset(adev)) {
+   irq_source = IRQ_TYPE_VBLANK + acrtc->otg_inst;
+   /* During gpu-reset we'll disable and then enable vblank irq,
+* so don't use amdgpu_irq_get/put() to avoid refcount change.
+*/
+   if (!dc_interrupt_set(adev->dm.dc, irq_source, enable))
+   rc = -EBUSY;
+   } else {
+   rc = (enable)
+   ? amdgpu_irq_get(adev, &adev->crtc_irq, acrtc->crtc_id)
+   : amdgpu_irq_put(adev, &adev->crtc_irq, acrtc->crtc_id);
+   }


It would be cleaner if we could do this on a higher level, e.g. in the 
GPU reset code.


But for now that should do it and I think this could even be back-ported 
to stable.


Regards,
Christian.

  
-	if (!dc_interrupt_set(adev->dm.dc, irq_source, enable))

-   return -EBUSY;
+   if (rc)
+   return rc;
  
  skip:

if (amdgpu_in_reset(adev))