Re: [PATCH] drm/amdgpu: add print for iommu translation mode
On 2023-03-17 16:04, Sider, Graham wrote:
[AMD Official Use Only - General]
-Original Message-
From: Russell, Kent
Sent: Friday, March 17, 2023 3:58 PM
To: Mahfooz, Hamza ; Sider, Graham
; amd-gfx@lists.freedesktop.org
Cc: Kuehling, Felix
Subject: RE: [PATCH] drm/amdgpu: add print for iommu translation mode
[AMD Official Use Only - General]
-Original Message-
From: amd-gfx On Behalf Of
Hamza Mahfooz
Sent: Friday, March 17, 2023 3:58 PM
To: Sider, Graham ;
amd-gfx@lists.freedesktop.org
Cc: Kuehling, Felix
Subject: Re: [PATCH] drm/amdgpu: add print for iommu translation mode
On 3/17/23 15:47, Graham Sider wrote:
Add log to display whether RAM is direct vs DMA mapped.
Signed-off-by: Graham Sider
If this information is only useful for debugging purposes, please use
drm_dbg() instead of pr_info().
It's useful for more than just debug I would say. Just a quick way to grep
whether IOMMU is off/pt vs device isolation mode.
I agree. The kernel log otherwise tells you the default IOMMU domain,
but it may not match the domain actually used for the GPU. Without this
message there is no easy way to tell from a kernel log. This will help
with triaging issues from logs provided by external and internal users.
Graham
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 8bba5e6872a1..8797a9523244 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3528,8 +3528,12 @@ static void
amdgpu_device_check_iommu_direct_map(struct amdgpu_device *adev)
struct iommu_domain *domain;
domain = iommu_get_domain_for_dev(adev->dev);
- if (!domain || domain->type == IOMMU_DOMAIN_IDENTITY)
+ if (!domain || domain->type == IOMMU_DOMAIN_IDENTITY) {
+ pr_info("RAM is direct mapped to GPU (not traslated by
Use dev_info. That way you can tell which GPU the message applies to in
a multi-GPU system.
Regards,
Felix
traslated -> translated
Thanks, my keyboard keeps skipping the on the 'n' key lately :( time for a
clean.
Graham
Kent
IOMMU)\n");
adev->ram_is_direct_mapped = true;
+ } else {
+ pr_info("RAM is DMA mapped to GPU (translated by
IOMMU)\n");
+ }
}
static const struct attribute *amdgpu_dev_attributes[] = {
--
Hamza
Re: [PATCH 36/37] drm/amd/display/dc/link/link_detection: Demote a couple of kerneldoc abuses
Applied. Thanks! Alex On Fri, Mar 17, 2023 at 4:24 AM Lee Jones wrote: > > Fixes the following W=1 kernel build warning(s): > > drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_detection.c:877: warning: > Function parameter or member 'link' not described in > 'detect_link_and_local_sink' > drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_detection.c:877: warning: > Function parameter or member 'reason' not described in > 'detect_link_and_local_sink' > drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_detection.c:1232: > warning: Function parameter or member 'link' not described in > 'dc_link_detect_connection_type' > > Cc: Harry Wentland > Cc: Leo Li > Cc: Rodrigo Siqueira > Cc: Alex Deucher > Cc: "Christian König" > Cc: "Pan, Xinhui" > Cc: David Airlie > Cc: Daniel Vetter > Cc: Lee Jones > Cc: Wenjing Liu > Cc: amd-gfx@lists.freedesktop.org > Cc: dri-de...@lists.freedesktop.org > Signed-off-by: Lee Jones > --- > drivers/gpu/drm/amd/display/dc/link/link_detection.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/amd/display/dc/link/link_detection.c > b/drivers/gpu/drm/amd/display/dc/link/link_detection.c > index 9a4cfa777622e..67addedd89563 100644 > --- a/drivers/gpu/drm/amd/display/dc/link/link_detection.c > +++ b/drivers/gpu/drm/amd/display/dc/link/link_detection.c > @@ -832,7 +832,7 @@ static void verify_link_capability(struct dc_link *link, > struct dc_sink *sink, > verify_link_capability_non_destructive(link); > } > > -/** > +/* > * detect_link_and_local_sink() - Detect if a sink is attached to a given > link > * > * link->local_sink is created or destroyed as needed. > @@ -1185,7 +1185,7 @@ static bool detect_link_and_local_sink(struct dc_link > *link, > return true; > } > > -/** > +/* > * link_detect_connection_type() - Determine if there is a sink connected > * > * @type: Returned connection type > -- > 2.40.0.rc1.284.g88254d51c5-goog >
Re: [PATCH 35/37] drm/amd/display/dc/dce60/Makefile: Fix previous attempt to silence known override-init warnings
Applied. Thanks!
On Fri, Mar 17, 2023 at 4:23 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:157:21:
> note: in expansion of macro ‘mmCRTC1_DCFE_MEM_LIGHT_SLEEP_CNTL’
> drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_transform.h:170:9: note: in
> expansion of macro ‘SRI’
> drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:183:17:
> note: in expansion of macro ‘XFM_COMMON_REG_LIST_DCE60’
> drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:188:17:
> note: in expansion of macro ‘transform_regs’
> drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_6_0_d.h:722:43:
> warning: initialized field overwritten [-Woverride-init]
> drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:157:21:
> note: in expansion of macro ‘mmCRTC2_DCFE_MEM_LIGHT_SLEEP_CNTL’
> drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_transform.h:170:9: note: in
> expansion of macro ‘SRI’
> drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:183:17:
> note: in expansion of macro ‘XFM_COMMON_REG_LIST_DCE60’
> drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:189:17:
> note: in expansion of macro ‘transform_regs’
> drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_6_0_d.h:722:43: note:
> (near initialization for ‘xfm_regs[2].DCFE_MEM_LIGHT_SLEEP_CN
>
> [100 lines snipped for brevity]
>
> Fixes: ceb3cf476a441 ("drm/amd/display/dc/dce60/Makefile: Ignore
> -Woverride-init warning")
> Cc: Harry Wentland
> Cc: Leo Li
> Cc: Rodrigo Siqueira
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: "Pan, Xinhui"
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Mauro Rossi
> Cc: amd-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Lee Jones
> ---
> drivers/gpu/drm/amd/display/dc/dce60/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dce60/Makefile
> b/drivers/gpu/drm/amd/display/dc/dce60/Makefile
> index dda596fa1cd76..fee331accc0e7 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce60/Makefile
> +++ b/drivers/gpu/drm/amd/display/dc/dce60/Makefile
> @@ -23,7 +23,7 @@
> # Makefile for the 'controller' sub-component of DAL.
> # It provides the control and status of HW CRTC block.
>
> -CFLAGS_AMDDALPATH)/dc/dce60/dce60_resource.o = $(call cc-disable-warning,
> override-init)
> +CFLAGS_$(AMDDALPATH)/dc/dce60/dce60_resource.o = $(call cc-disable-warning,
> override-init)
>
> DCE60 = dce60_timing_generator.o dce60_hw_sequencer.o \
> dce60_resource.o
> --
> 2.40.0.rc1.284.g88254d51c5-goog
>
Re: [PATCH 33/37] drm/amd/display/dc/link/protocols/link_dp_capability: Demote non-compliant kerneldoc
Applied. Thanks! Alex On Fri, Mar 17, 2023 at 4:23 AM Lee Jones wrote: > > Fixes the following W=1 kernel build warning(s): > > > drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_capability.c:2190: > warning: Function parameter or member 'link' not described in > 'dc_link_is_dp_sink_present' > > Cc: Harry Wentland > Cc: Leo Li > Cc: Rodrigo Siqueira > Cc: Alex Deucher > Cc: "Christian König" > Cc: "Pan, Xinhui" > Cc: David Airlie > Cc: Daniel Vetter > Cc: amd-gfx@lists.freedesktop.org > Cc: dri-de...@lists.freedesktop.org > Signed-off-by: Lee Jones > --- > .../gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > 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 51427f5081642..2a2443535b676 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 > @@ -2177,7 +2177,7 @@ bool dp_verify_link_cap_with_retries( > return success; > } > > -/** > +/* > * Check if there is a native DP or passive DP-HDMI dongle connected > */ > bool dp_is_sink_present(struct dc_link *link) > -- > 2.40.0.rc1.284.g88254d51c5-goog >
Re: [PATCH 32/37] drm/amd/display/dc/link/protocols/link_dp_capability: Remove unused variable and mark another as __maybe_unused
Applied. Thanks!
Alex
On Fri, Mar 17, 2023 at 4:23 AM Lee Jones wrote:
>
> ‘ds_port’ is clearly not used anywhere and ‘result_write_min_hblank’ is
> only utilised when debugging is enabled. The alternative would be to
> allocate the variable under the same clause as the debugging code, but
> that would become very messy, very quickly.
>
> Fixes the following W=1 kernel build warning(s):
>
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_capability.c:
> In function ‘dp_wa_power_up_0010FA’:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_capability.c:280:42:
> warning: variable ‘ds_port’ set but not used [-Wunused-but-set-variable]
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_capability.c:
> In function ‘dpcd_set_source_specific_data’:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_capability.c:1296:32:
> warning: variable ‘result_write_min_hblank’ set but not used
> [-Wunused-but-set-variable]
>
> Cc: Harry Wentland
> Cc: Leo Li
> Cc: Rodrigo Siqueira
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: "Pan, Xinhui"
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Wenjing Liu
> Cc: amd-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Lee Jones
> ---
> .../gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> 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 e9bcb35ae185a..51427f5081642 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
> @@ -1284,7 +1284,7 @@ bool dp_overwrite_extended_receiver_cap(struct dc_link
> *link)
> void dpcd_set_source_specific_data(struct dc_link *link)
> {
> if (!link->dc->vendor_signature.is_valid) {
> - enum dc_status result_write_min_hblank = DC_NOT_SUPPORTED;
> + enum dc_status __maybe_unused result_write_min_hblank =
> DC_NOT_SUPPORTED;
> struct dpcd_amd_signature amd_signature = {0};
> struct dpcd_amd_device_id amd_device_id = {0};
>
> --
> 2.40.0.rc1.284.g88254d51c5-goog
>
Re: [PATCH 30/37] drm/amd/display/dc/link/protocols/link_dp_training: Remove set but unused variable 'result'
Applied. Thanks! On Fri, Mar 17, 2023 at 4:23 AM Lee Jones wrote: > > Fixes the following W=1 kernel build warning(s): > > drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_training.c: > In function ‘perform_link_training_with_retries’: > > drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_training.c:1586:38: > warning: variable ‘result’ set but not used [-Wunused-but-set-variable] > > Cc: Harry Wentland > Cc: Leo Li > Cc: Rodrigo Siqueira > Cc: Alex Deucher > Cc: "Christian König" > Cc: "Pan, Xinhui" > Cc: David Airlie > Cc: Daniel Vetter > Cc: Wenjing Liu > Cc: amd-gfx@lists.freedesktop.org > Cc: dri-de...@lists.freedesktop.org > Signed-off-by: Lee Jones > --- > .../gpu/drm/amd/display/dc/link/protocols/link_dp_training.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_training.c > b/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_training.c > index a9025671ee4a8..10261764a0cea 100644 > --- a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_training.c > +++ b/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_training.c > @@ -1580,8 +1580,7 @@ bool perform_link_training_with_retries( > * Report and continue with eDP panel mode to > * perform eDP link training with right > settings > */ > - bool result; > - result = > cp_psp->funcs.enable_assr(cp_psp->handle, link); > + cp_psp->funcs.enable_assr(cp_psp->handle, > link); > } > } > > -- > 2.40.0.rc1.284.g88254d51c5-goog >
Re: [PATCH 29/37] drm/amd/display/dc/link/link_detection: Remove unused variable 'status'
Applied. Thanks!
On Fri, Mar 17, 2023 at 4:23 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_detection.c: In function
> ‘query_hdcp_capability’:
> drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_detection.c:501:42:
> warning: variable ‘status’ set but not used [-Wunused-but-set-variable]
>
> Cc: Harry Wentland
> Cc: Leo Li
> Cc: Rodrigo Siqueira
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: "Pan, Xinhui"
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Wenjing Liu
> Cc: amd-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Lee Jones
> ---
> drivers/gpu/drm/amd/display/dc/link/link_detection.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/link/link_detection.c
> b/drivers/gpu/drm/amd/display/dc/link/link_detection.c
> index 9177b146a80a8..9a4cfa777622e 100644
> --- a/drivers/gpu/drm/amd/display/dc/link/link_detection.c
> +++ b/drivers/gpu/drm/amd/display/dc/link/link_detection.c
> @@ -498,8 +498,6 @@ static void query_hdcp_capability(enum signal_type
> signal, struct dc_link *link)
> dc_process_hdcp_msg(signal, link, &msg22);
>
> if (signal == SIGNAL_TYPE_DISPLAY_PORT || signal ==
> SIGNAL_TYPE_DISPLAY_PORT_MST) {
> - enum hdcp_message_status status = HDCP_MESSAGE_UNSUPPORTED;
> -
> msg14.data = &link->hdcp_caps.bcaps.raw;
> msg14.length = sizeof(link->hdcp_caps.bcaps.raw);
> msg14.msg_id = HDCP_MESSAGE_ID_READ_BCAPS;
> @@ -507,7 +505,7 @@ static void query_hdcp_capability(enum signal_type
> signal, struct dc_link *link)
> msg14.link = HDCP_LINK_PRIMARY;
> msg14.max_retries = 5;
>
> - status = dc_process_hdcp_msg(signal, link, &msg14);
> + dc_process_hdcp_msg(signal, link, &msg14);
> }
>
> }
> --
> 2.40.0.rc1.284.g88254d51c5-goog
>
Re: [PATCH 28/37] drm/amd/display/dc/core/dc_stat: Convert a couple of doc headers to kerneldoc format
On Fri, Mar 17, 2023 at 4:23 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stat.c:38: warning: Cannot
> understand
> *
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stat.c:76: warning: Cannot
> understand
> *
>
> Cc: Harry Wentland
> Cc: Leo Li
> Cc: Rodrigo Siqueira
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: "Pan, Xinhui"
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Mustapha Ghaddar
> Cc: Nicholas Kazlauskas
> Cc: Jasdeep Dhillon
> Cc: amd-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Lee Jones
> ---
> drivers/gpu/drm/amd/display/dc/core/dc_stat.c | 28 +++
> 1 file changed, 10 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_stat.c
> b/drivers/gpu/drm/amd/display/dc/core/dc_stat.c
> index 6c06587dd88c2..5f6392ae31a66 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_stat.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_stat.c
> @@ -35,19 +35,15 @@
> */
>
> /**
This looks like it follows some other documentation scheme. Would
probably be better to just remove the extra * and make it not kernel
doc. @Wentland, Harry @Siqueira, Rodrigo ?
Alex
> -
> *
> - * Function: dc_stat_get_dmub_notification
> + * dc_stat_get_dmub_notification
> *
> - * @brief
> - * Calls dmub layer to retrieve dmub notification
> + * Calls dmub layer to retrieve dmub notification
> *
> - * @param
> - * [in] dc: dc structure
> - * [in] notify: dmub notification structure
> + * @dc: dc structure
> + * @notify: dmub notification structure
> *
> - * @return
> + * Returns
> * None
> -
> *
> */
> void dc_stat_get_dmub_notification(const struct dc *dc, struct
> dmub_notification *notify)
> {
> @@ -73,19 +69,15 @@ void dc_stat_get_dmub_notification(const struct dc *dc,
> struct dmub_notification
> }
>
> /**
> -
> *
> - * Function: dc_stat_get_dmub_dataout
> + * dc_stat_get_dmub_dataout
> *
> - * @brief
> - * Calls dmub layer to retrieve dmub gpint dataout
> + * Calls dmub layer to retrieve dmub gpint dataout
> *
> - * @param
> - * [in] dc: dc structure
> - * [in] dataout: dmub gpint dataout
> + * @dc: dc structure
> + * @dataout: dmub gpint dataout
> *
> - * @return
> + * Returns
> * None
> -
> *
> */
> void dc_stat_get_dmub_dataout(const struct dc *dc, uint32_t *dataout)
> {
> --
> 2.40.0.rc1.284.g88254d51c5-goog
>
Re: [PATCH 27/37] drm/amd/display/dc/dce/dmub_psr: Demote kerneldoc abuse
Applied. Thanks! On Fri, Mar 17, 2023 at 4:23 AM Lee Jones wrote: > > Fixes the following W=1 kernel build warning(s): > > drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_psr.c:257: warning: This > comment starts with '/**', but isn't a kernel-doc comment. Refer > Documentation/doc-guide/kernel-doc.rst > > Cc: Harry Wentland > Cc: Leo Li > Cc: Rodrigo Siqueira > Cc: Alex Deucher > Cc: "Christian König" > Cc: "Pan, Xinhui" > Cc: David Airlie > Cc: Daniel Vetter > Cc: David Zhang > Cc: amd-gfx@lists.freedesktop.org > Cc: dri-de...@lists.freedesktop.org > Signed-off-by: Lee Jones > --- > drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c > b/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c > index 27b8f3435d86f..9705d8f883825 100644 > --- a/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c > +++ b/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c > @@ -253,7 +253,7 @@ static void dmub_psr_set_level(struct dmub_psr *dmub, > uint16_t psr_level, uint8_ > dc_dmub_srv_wait_idle(dc->dmub_srv); > } > > -/** > +/* > * Set PSR vtotal requirement for FreeSync PSR. > */ > static void dmub_psr_set_sink_vtotal_in_psr_active(struct dmub_psr *dmub, > -- > 2.40.0.rc1.284.g88254d51c5-goog >
Re: [PATCH 26/37] drm/amd/display/amdgpu_dm/amdgpu_dm_helpers: Move SYNAPTICS_DEVICE_ID into CONFIG_DRM_AMD_DC_DCN ifdef
On Fri, Mar 17, 2023 at 4:23 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:48:22:
> warning: ‘SYNAPTICS_DEVICE_ID’ defined but not used [-Wunused-const-variable=]
CONFIG_DRM_AMD_DC_DCN was recently dropped so this patch is no longer relevant.
Alex
>
> Cc: Harry Wentland
> Cc: Leo Li
> Cc: Rodrigo Siqueira
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: "Pan, Xinhui"
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: amd-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Lee Jones
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> index 330ab036c830f..a8904184673f6 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> @@ -44,9 +44,6 @@
> #include "dm_helpers.h"
> #include "ddc_service_types.h"
>
> -/* MST Dock */
> -static const uint8_t SYNAPTICS_DEVICE_ID[] = "SYNA";
> -
> /* dm_helpers_parse_edid_caps
> *
> * Parse edid caps
> @@ -703,6 +700,9 @@ static void apply_synaptics_fifo_reset_wa(struct
> drm_dp_aux *aux)
> DC_LOG_DC("Done apply_synaptics_fifo_reset_wa\n");
> }
>
> +/* MST Dock */
> +static const uint8_t SYNAPTICS_DEVICE_ID[] = "SYNA";
> +
> static uint8_t write_dsc_enable_synaptics_non_virtual_dpcd_mst(
> struct drm_dp_aux *aux,
> const struct dc_stream_state *stream,
> --
> 2.40.0.rc1.284.g88254d51c5-goog
>
Re: [PATCH 20/37] drm/amd/display/amdgpu_dm/amdgpu_dm_helpers: Move defines out to where they are actually used
Applied. Thanks!
Alex
On Fri, Mar 17, 2023 at 4:23 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/../display/include/ddc_service_types.h: At top
> level:
> drivers/gpu/drm/amd/amdgpu/../display/include/ddc_service_types.h:143:22:
> warning: ‘SYNAPTICS_DEVICE_ID’ defined but not used
> [-Wunused-const-variable=]
> drivers/gpu/drm/amd/amdgpu/../display/include/ddc_service_types.h:140:22:
> warning: ‘DP_VGA_LVDS_CONVERTER_ID_3’ defined but not used
> [-Wunused-const-variable=]
> drivers/gpu/drm/amd/amdgpu/../display/include/ddc_service_types.h:138:22:
> warning: ‘DP_VGA_LVDS_CONVERTER_ID_2’ defined but not used
> [-Wunused-const-variable=]
> drivers/gpu/drm/amd/amdgpu/../display/include/ddc_service_types.h:133:22:
> warning: ‘DP_SINK_DEVICE_STR_ID_2’ defined but not used
> [-Wunused-const-variable=]
> drivers/gpu/drm/amd/amdgpu/../display/include/ddc_service_types.h:132:22:
> warning: ‘DP_SINK_DEVICE_STR_ID_1’ defined but not used
> [-Wunused-const-variable=]
>
> [snip 400 similar lines brevity]
>
> Cc: Harry Wentland
> Cc: Leo Li
> Cc: Rodrigo Siqueira
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: "Pan, Xinhui"
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: amd-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Lee Jones
> ---
> .../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 3 +++
> drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c | 3 +++
> .../gpu/drm/amd/display/dc/link/link_detection.c| 2 ++
> .../dc/link/protocols/link_edp_panel_control.c | 5 +
> .../gpu/drm/amd/display/include/ddc_service_types.h | 13 -
> 5 files changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> index 9c1e91c2179eb..330ab036c830f 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> @@ -44,6 +44,9 @@
> #include "dm_helpers.h"
> #include "ddc_service_types.h"
>
> +/* MST Dock */
> +static const uint8_t SYNAPTICS_DEVICE_ID[] = "SYNA";
> +
> /* dm_helpers_parse_edid_caps
> *
> * Parse edid caps
> diff --git a/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c
> b/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c
> index 19440bdf63449..27b8f3435d86f 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c
> @@ -33,6 +33,9 @@
>
> #define MAX_PIPES 6
>
> +static const uint8_t DP_SINK_DEVICE_STR_ID_1[] = {7, 1, 8, 7, 3};
> +static const uint8_t DP_SINK_DEVICE_STR_ID_2[] = {7, 1, 8, 7, 5};
> +
> /*
> * Convert dmcub psr state to dmcu psr state.
> */
> diff --git a/drivers/gpu/drm/amd/display/dc/link/link_detection.c
> b/drivers/gpu/drm/amd/display/dc/link/link_detection.c
> index 8cfeddfb65c89..9177b146a80a8 100644
> --- a/drivers/gpu/drm/amd/display/dc/link/link_detection.c
> +++ b/drivers/gpu/drm/amd/display/dc/link/link_detection.c
> @@ -60,6 +60,8 @@
> */
> #define LINK_TRAINING_MAX_VERIFY_RETRY 2
>
> +static const u8 DP_SINK_BRANCH_DEV_NAME_7580[] = "7580\x80u";
> +
> static const uint8_t dp_hdmi_dongle_signature_str[] = "DP-HDMI ADAPTOR";
>
> static enum ddc_transaction_type get_ddc_transaction_type(enum signal_type
> sink_signal)
> diff --git
> a/drivers/gpu/drm/amd/display/dc/link/protocols/link_edp_panel_control.c
> b/drivers/gpu/drm/amd/display/dc/link/protocols/link_edp_panel_control.c
> index 93a6bbe954bb7..d895046787bc4 100644
> --- a/drivers/gpu/drm/amd/display/dc/link/protocols/link_edp_panel_control.c
> +++ b/drivers/gpu/drm/amd/display/dc/link/protocols/link_edp_panel_control.c
> @@ -37,6 +37,11 @@
> #include "abm.h"
> #define DC_LOGGER_INIT(logger)
>
> +/* Travis */
> +static const uint8_t DP_VGA_LVDS_CONVERTER_ID_2[] = "sivarT";
> +/* Nutmeg */
> +static const uint8_t DP_VGA_LVDS_CONVERTER_ID_3[] = "dnomlA";
> +
> void dp_set_panel_mode(struct dc_link *link, enum dp_panel_mode panel_mode)
> {
> union dpcd_edp_config edp_config_set;
> diff --git a/drivers/gpu/drm/amd/display/include/ddc_service_types.h
> b/drivers/gpu/drm/amd/display/include/ddc_service_types.h
> index 31a12ce79a8e0..f843fc4978552 100644
> --- a/drivers/gpu/drm/amd/display/include/ddc_service_types.h
> +++ b/drivers/gpu/drm/amd/display/include/ddc_service_types.h
> @@ -129,17 +129,4 @@ struct av_sync_data {
> uint8_t aud_del_ins3;/* DPCD 0002Dh */
> };
>
> -static const uint8_t DP_SINK_DEVICE_STR_ID_1[] = {7, 1, 8, 7, 3};
> -static const uint8_t DP_SINK_DEVICE_STR_ID_2[] = {7, 1, 8, 7, 5};
> -
> -static const u8 DP_SINK_BRANCH_DEV_NAME_7580[] = "7580\x80u";
> -
> -/*Travis*/
> -static const uint8_t DP_VGA_LVDS_CONVERTER_ID_2[] = "sivarT";
> -/*Nutmeg*/
> -static const uint8_t DP_VGA_LVDS_CONVERTER_ID_3[] = "dnomlA";
> -
> -/*MST Dock*/
> -static const uint8_t SY
Re: [PATCH 19/37] drm/amd/pm/swsmu/smu11/vangogh_ppt: Provide a couple of missing parameter descriptions
Applied. Thanks! Alex On Fri, Mar 17, 2023 at 4:23 AM Lee Jones wrote: > > Fixes the following W=1 kernel build warning(s): > > drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:2381: warning: > Function parameter or member 'residency' not described in > 'vangogh_get_gfxoff_residency' > drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:2399: warning: > Function parameter or member 'entrycount' not described in > 'vangogh_get_gfxoff_entrycount' > > Cc: Evan Quan > Cc: Alex Deucher > Cc: "Christian König" > Cc: "Pan, Xinhui" > Cc: David Airlie > Cc: Daniel Vetter > Cc: Li Ma > Cc: amd-gfx@lists.freedesktop.org > Cc: dri-de...@lists.freedesktop.org > Signed-off-by: Lee Jones > --- > drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c > b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c > index 4590374251f3b..7433dcaa16e04 100644 > --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c > +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c > @@ -2389,6 +2389,7 @@ static u32 vangogh_set_gfxoff_residency(struct > smu_context *smu, bool start) > * vangogh_get_gfxoff_residency > * > * @smu: amdgpu_device pointer > + * @residency: placeholder for return value > * > * This function will be used to get gfxoff residency. > * > @@ -2407,6 +2408,7 @@ static u32 vangogh_get_gfxoff_residency(struct > smu_context *smu, uint32_t *resid > * vangogh_get_gfxoff_entrycount - get gfxoff entry count > * > * @smu: amdgpu_device pointer > + * @entrycount: placeholder for return value > * > * This function will be used to get gfxoff entry count > * > -- > 2.40.0.rc1.284.g88254d51c5-goog >
Re: [PATCH 18/37] drm/amd/amdgpu/amdgpu_vce: Provide description for amdgpu_vce_validate_bo()'s 'p' param
Applied with minor modification. Thanks! Alex On Fri, Mar 17, 2023 at 4:23 AM Lee Jones wrote: > > Fixes the following W=1 kernel build warning(s): > > drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c:599: warning: Function parameter or > member 'p' not described in 'amdgpu_vce_validate_bo' > > Cc: Alex Deucher > Cc: "Christian König" > Cc: "Pan, Xinhui" > Cc: David Airlie > Cc: Daniel Vetter > Cc: Sumit Semwal > Cc: amd-gfx@lists.freedesktop.org > Cc: dri-de...@lists.freedesktop.org > Cc: linux-me...@vger.kernel.org > Cc: linaro-mm-...@lists.linaro.org > Signed-off-by: Lee Jones > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c > index 2fb61410b1c02..c4d65ade5c00a 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c > @@ -585,6 +585,7 @@ static int amdgpu_vce_get_destroy_msg(struct amdgpu_ring > *ring, uint32_t handle, > /** > * amdgpu_vce_validate_bo - make sure not to cross 4GB boundary > * > + * @p: parser context > * @ib: indirect buffer to use > * @lo: address of lower dword > * @hi: address of higher dword > -- > 2.40.0.rc1.284.g88254d51c5-goog >
Re: [PATCH 17/37] drm/amd/amdgpu/amdgpu_mes: Ensure amdgpu_bo_create_kernel()'s return value is checked
Applied. Thanks!
On Fri, Mar 17, 2023 at 4:23 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c: In function
> ‘amdgpu_mes_ctx_alloc_meta_data’:
> drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c:1099:13: warning: variable ‘r’ set
> but not used [-Wunused-but-set-variable]
>
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: "Pan, Xinhui"
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Sumit Semwal
> Cc: Jack Xiao
> Cc: Hawking Zhang
> Cc: amd-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> Signed-off-by: Lee Jones
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c
> index 82e27bd4f0383..30cd72ca1eefd 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c
> @@ -1104,6 +1104,11 @@ int amdgpu_mes_ctx_alloc_meta_data(struct
> amdgpu_device *adev,
> &ctx_data->meta_data_obj,
> &ctx_data->meta_data_mc_addr,
> &ctx_data->meta_data_ptr);
> + if (r) {
> + dev_warn(adev->dev, "(%d) create CTX bo failed\n", r);
> + return r;
> + }
> +
> if (!ctx_data->meta_data_obj)
> return -ENOMEM;
>
> --
> 2.40.0.rc1.284.g88254d51c5-goog
>
Re: [PATCH 16/37] drm/amd/amdgpu/ih_v6_0: Repair misspelling and provide descriptions for 'ih'
Applied. Thanks! On Fri, Mar 17, 2023 at 4:23 AM Lee Jones wrote: > > Fixes the following W=1 kernel build warning(s): > > drivers/gpu/drm/amd/amdgpu/ih_v6_0.c:392: warning: Function parameter or > member 'ih' not described in 'ih_v6_0_get_wptr' > drivers/gpu/drm/amd/amdgpu/ih_v6_0.c:432: warning: Function parameter or > member 'ih' not described in 'ih_v6_0_irq_rearm' > drivers/gpu/drm/amd/amdgpu/ih_v6_0.c:458: warning: Function parameter or > member 'ih' not described in 'ih_v6_0_set_rptr' > > Cc: Alex Deucher > Cc: "Christian König" > Cc: "Pan, Xinhui" > Cc: David Airlie > Cc: Daniel Vetter > Cc: Hawking Zhang > Cc: amd-gfx@lists.freedesktop.org > Cc: dri-de...@lists.freedesktop.org > Signed-off-by: Lee Jones > --- > drivers/gpu/drm/amd/amdgpu/ih_v6_0.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/ih_v6_0.c > b/drivers/gpu/drm/amd/amdgpu/ih_v6_0.c > index 7cd79a3844b24..b02e1cef78a76 100644 > --- a/drivers/gpu/drm/amd/amdgpu/ih_v6_0.c > +++ b/drivers/gpu/drm/amd/amdgpu/ih_v6_0.c > @@ -119,7 +119,7 @@ force_update_wptr_for_self_int(struct amdgpu_device *adev, > * ih_v6_0_toggle_ring_interrupts - toggle the interrupt ring buffer > * > * @adev: amdgpu_device pointer > - * @ih: amdgpu_ih_ring pointet > + * @ih: amdgpu_ih_ring pointer > * @enable: true - enable the interrupts, false - disable the interrupts > * > * Toggle the interrupt ring buffer (IH_V6_0) > @@ -381,6 +381,7 @@ static void ih_v6_0_irq_disable(struct amdgpu_device > *adev) > * ih_v6_0_get_wptr - get the IH ring buffer wptr > * > * @adev: amdgpu_device pointer > + * @ih: amdgpu_ih_ring pointer > * > * Get the IH ring buffer wptr from either the register > * or the writeback memory buffer. Also check for > @@ -425,6 +426,7 @@ static u32 ih_v6_0_get_wptr(struct amdgpu_device *adev, > * ih_v6_0_irq_rearm - rearm IRQ if lost > * > * @adev: amdgpu_device pointer > + * @ih: amdgpu_ih_ring pointer > * > */ > static void ih_v6_0_irq_rearm(struct amdgpu_device *adev, > @@ -450,6 +452,7 @@ static void ih_v6_0_irq_rearm(struct amdgpu_device *adev, > * ih_v6_0_set_rptr - set the IH ring buffer rptr > * > * @adev: amdgpu_device pointer > + * @ih: amdgpu_ih_ring pointer > * > * Set the IH ring buffer rptr. > */ > -- > 2.40.0.rc1.284.g88254d51c5-goog >
Re: [PATCH 15/37] drm/amd/amdgpu/gmc_v11_0: Provide a few missing param descriptions relating to hubs and flushes
Applied. Thanks! Alex On Fri, Mar 17, 2023 at 4:23 AM Lee Jones wrote: > > Fixes the following W=1 kernel build warning(s): > > drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c:282: warning: Function parameter or > member 'vmhub' not described in 'gmc_v11_0_flush_gpu_tlb' > drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c:282: warning: Function parameter or > member 'flush_type' not described in 'gmc_v11_0_flush_gpu_tlb' > drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c:322: warning: Function parameter or > member 'flush_type' not described in 'gmc_v11_0_flush_gpu_tlb_pasid' > drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c:322: warning: Function parameter or > member 'all_hub' not described in 'gmc_v11_0_flush_gpu_tlb_pasid' > > Cc: Alex Deucher > Cc: "Christian König" > Cc: "Pan, Xinhui" > Cc: David Airlie > Cc: Daniel Vetter > Cc: amd-gfx@lists.freedesktop.org > Cc: dri-de...@lists.freedesktop.org > Signed-off-by: Lee Jones > --- > drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c > b/drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c > index fad199ed15f38..9f4f28192c601 100644 > --- a/drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c > +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c > @@ -274,6 +274,8 @@ static void gmc_v11_0_flush_vm_hub(struct amdgpu_device > *adev, uint32_t vmid, > * > * @adev: amdgpu_device pointer > * @vmid: vm instance to flush > + * @vmhub: which hub to flush > + * @flush_type: the flush type > * > * Flush the TLB for the requested page table. > */ > @@ -313,6 +315,8 @@ static void gmc_v11_0_flush_gpu_tlb(struct amdgpu_device > *adev, uint32_t vmid, > * > * @adev: amdgpu_device pointer > * @pasid: pasid to be flush > + * @flush_type: the flush type > + * @all_hub: flush all hubs > * > * Flush the TLB for the requested pasid. > */ > -- > 2.40.0.rc1.284.g88254d51c5-goog >
Re: [PATCH 14/37] drm/amd/amdgpu/amdgpu_vm_pt: Supply description for amdgpu_vm_pt_free_dfs()'s unlocked param
Applied. Thanks! Alex On Fri, Mar 17, 2023 at 4:23 AM Lee Jones wrote: > > Fixes the following W=1 kernel build warning(s): > > drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c:683: warning: Function parameter > or member 'unlocked' not described in 'amdgpu_vm_pt_free_dfs' > > Cc: Alex Deucher > Cc: "Christian König" > Cc: "Pan, Xinhui" > Cc: David Airlie > Cc: Daniel Vetter > Cc: Sumit Semwal > Cc: amd-gfx@lists.freedesktop.org > Cc: dri-de...@lists.freedesktop.org > Cc: linux-me...@vger.kernel.org > Cc: linaro-mm-...@lists.linaro.org > Signed-off-by: Lee Jones > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c > index 01e42bdd8e4e8..df63dc3bca18c 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c > @@ -673,6 +673,7 @@ void amdgpu_vm_pt_free_work(struct work_struct *work) > * @adev: amdgpu device structure > * @vm: amdgpu vm structure > * @start: optional cursor where to start freeing PDs/PTs > + * @unlocked: vm resv unlock status > * > * Free the page directory or page table level and all sub levels. > */ > -- > 2.40.0.rc1.284.g88254d51c5-goog >
Re: [PATCH 13/37] drm/amd/amdgpu/amdgpu_ucode: Remove unused function ‘amdgpu_ucode_print_imu_hdr’
Applied. Thanks!
On Fri, Mar 17, 2023 at 4:22 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c:129:6: warning: no previous
> prototype for ‘amdgpu_ucode_print_imu_hdr’ [-Wmissing-prototypes]
>
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: "Pan, Xinhui"
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: amd-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Lee Jones
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 13 -
> 1 file changed, 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> index 380b89114341d..a7bffd24ceaf3 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> @@ -126,19 +126,6 @@ void amdgpu_ucode_print_gfx_hdr(const struct
> common_firmware_header *hdr)
> }
> }
>
> -void amdgpu_ucode_print_imu_hdr(const struct common_firmware_header *hdr)
> -{
> - uint16_t version_major = le16_to_cpu(hdr->header_version_major);
> - uint16_t version_minor = le16_to_cpu(hdr->header_version_minor);
> -
> - DRM_DEBUG("IMU\n");
> - amdgpu_ucode_print_common_hdr(hdr);
> -
> - if (version_major != 1) {
> - DRM_ERROR("Unknown GFX ucode version: %u.%u\n",
> version_major, version_minor);
> - }
> -}
> -
> void amdgpu_ucode_print_rlc_hdr(const struct common_firmware_header *hdr)
> {
> uint16_t version_major = le16_to_cpu(hdr->header_version_major);
> --
> 2.40.0.rc1.284.g88254d51c5-goog
>
Re: [PATCH 03/37] drm/amd/amdgpu/amdgpu_device: Provide missing kerneldoc entry for 'reset_context'
Applied. Thanks! On Fri, Mar 17, 2023 at 4:22 AM Lee Jones wrote: > > Fixes the following W=1 kernel build warning(s): > > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:5152: >warning: Function parameter or member 'reset_context' not described in > 'amdgpu_device_gpu_recover' > > Cc: Alex Deucher > Cc: "Christian König" > Cc: "Pan, Xinhui" > Cc: David Airlie > Cc: Daniel Vetter > Cc: Sumit Semwal > Cc: amd-gfx@lists.freedesktop.org > Cc: dri-de...@lists.freedesktop.org > Cc: linux-me...@vger.kernel.org > Cc: linaro-mm-...@lists.linaro.org > Signed-off-by: Lee Jones > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c > index d4519fbd526f2..ef0b2787796da 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c > @@ -5145,6 +5145,7 @@ static inline void > amdgpu_device_stop_pending_resets(struct amdgpu_device *adev) > * > * @adev: amdgpu_device pointer > * @job: which job trigger hang > + * @reset_context: amdgpu reset context pointer > * > * Attempt to reset the GPU if it has hung (all asics). > * Attempt to do soft-reset or full-reset and reinitialize Asic > -- > 2.40.0.rc1.284.g88254d51c5-goog >
Re: [PATCH 01/37] drm/amd/display/dc/dc_hdmi_types: Move string definition to the only file it's used in
Applied. Thanks!
On Fri, Mar 17, 2023 at 4:22 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dc_hdmi_types.h:53:22:
>warning: ‘dp_hdmi_dongle_signature_str’ defined but not used
> [-Wunused-const-variable=]
>
> [snipped 400 similar lines for brevity]
>
> Cc: Harry Wentland
> Cc: Leo Li
> Cc: Rodrigo Siqueira
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: "Pan, Xinhui"
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Wenjing Liu
> Cc: amd-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Lee Jones
> ---
> drivers/gpu/drm/amd/display/dc/dc_hdmi_types.h | 1 -
> drivers/gpu/drm/amd/display/dc/link/link_detection.c | 2 ++
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dc_hdmi_types.h
> b/drivers/gpu/drm/amd/display/dc/dc_hdmi_types.h
> index c364744b4c835..b015e80672ec9 100644
> --- a/drivers/gpu/drm/amd/display/dc/dc_hdmi_types.h
> +++ b/drivers/gpu/drm/amd/display/dc/dc_hdmi_types.h
> @@ -50,7 +50,6 @@ struct dp_hdmi_dongle_signature_data {
>
> /* DP-HDMI dongle slave address for retrieving dongle signature*/
> #define DP_HDMI_DONGLE_ADDRESS 0x40
> -static const uint8_t dp_hdmi_dongle_signature_str[] = "DP-HDMI ADAPTOR";
> #define DP_HDMI_DONGLE_SIGNATURE_EOT 0x04
>
>
> diff --git a/drivers/gpu/drm/amd/display/dc/link/link_detection.c
> b/drivers/gpu/drm/amd/display/dc/link/link_detection.c
> index fee71ebdfc733..8cfeddfb65c89 100644
> --- a/drivers/gpu/drm/amd/display/dc/link/link_detection.c
> +++ b/drivers/gpu/drm/amd/display/dc/link/link_detection.c
> @@ -60,6 +60,8 @@
> */
> #define LINK_TRAINING_MAX_VERIFY_RETRY 2
>
> +static const uint8_t dp_hdmi_dongle_signature_str[] = "DP-HDMI ADAPTOR";
> +
> static enum ddc_transaction_type get_ddc_transaction_type(enum signal_type
> sink_signal)
> {
> enum ddc_transaction_type transaction_type =
> DDC_TRANSACTION_TYPE_NONE;
> --
> 2.40.0.rc1.284.g88254d51c5-goog
>
RE: [PATCH] drm/amdgpu: add print for iommu translation mode
[AMD Official Use Only - General]
> -Original Message-
> From: Russell, Kent
> Sent: Friday, March 17, 2023 3:58 PM
> To: Mahfooz, Hamza ; Sider, Graham
> ; amd-gfx@lists.freedesktop.org
> Cc: Kuehling, Felix
> Subject: RE: [PATCH] drm/amdgpu: add print for iommu translation mode
>
> [AMD Official Use Only - General]
>
>
>
> > -Original Message-
> > From: amd-gfx On Behalf Of
> > Hamza Mahfooz
> > Sent: Friday, March 17, 2023 3:58 PM
> > To: Sider, Graham ;
> > amd-gfx@lists.freedesktop.org
> > Cc: Kuehling, Felix
> > Subject: Re: [PATCH] drm/amdgpu: add print for iommu translation mode
> >
> >
> > On 3/17/23 15:47, Graham Sider wrote:
> > > Add log to display whether RAM is direct vs DMA mapped.
> > >
> > > Signed-off-by: Graham Sider
> >
> > If this information is only useful for debugging purposes, please use
> > drm_dbg() instead of pr_info().
It's useful for more than just debug I would say. Just a quick way to grep
whether IOMMU is off/pt vs device isolation mode.
Graham
> >
> > > ---
> > > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 +-
> > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > index 8bba5e6872a1..8797a9523244 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > @@ -3528,8 +3528,12 @@ static void
> > amdgpu_device_check_iommu_direct_map(struct amdgpu_device *adev)
> > > struct iommu_domain *domain;
> > >
> > > domain = iommu_get_domain_for_dev(adev->dev);
> > > - if (!domain || domain->type == IOMMU_DOMAIN_IDENTITY)
> > > + if (!domain || domain->type == IOMMU_DOMAIN_IDENTITY) {
> > > + pr_info("RAM is direct mapped to GPU (not traslated by
> traslated -> translated
>
Thanks, my keyboard keeps skipping the on the 'n' key lately :( time for a
clean.
Graham
> Kent
> > IOMMU)\n");
> > > adev->ram_is_direct_mapped = true;
> > > + } else {
> > > + pr_info("RAM is DMA mapped to GPU (translated by
> > IOMMU)\n");
> > > + }
> > > }
> > >
> > > static const struct attribute *amdgpu_dev_attributes[] = {
> >
> > --
> > Hamza
RE: [PATCH] drm/amdgpu: add print for iommu translation mode
[AMD Official Use Only - General]
> -Original Message-
> From: amd-gfx On Behalf Of Hamza
> Mahfooz
> Sent: Friday, March 17, 2023 3:58 PM
> To: Sider, Graham ; amd-gfx@lists.freedesktop.org
> Cc: Kuehling, Felix
> Subject: Re: [PATCH] drm/amdgpu: add print for iommu translation mode
>
>
> On 3/17/23 15:47, Graham Sider wrote:
> > Add log to display whether RAM is direct vs DMA mapped.
> >
> > Signed-off-by: Graham Sider
>
> If this information is only useful for debugging purposes, please use
> drm_dbg() instead of pr_info().
>
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > index 8bba5e6872a1..8797a9523244 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > @@ -3528,8 +3528,12 @@ static void
> amdgpu_device_check_iommu_direct_map(struct amdgpu_device *adev)
> > struct iommu_domain *domain;
> >
> > domain = iommu_get_domain_for_dev(adev->dev);
> > - if (!domain || domain->type == IOMMU_DOMAIN_IDENTITY)
> > + if (!domain || domain->type == IOMMU_DOMAIN_IDENTITY) {
> > + pr_info("RAM is direct mapped to GPU (not traslated by
traslated -> translated
Kent
> IOMMU)\n");
> > adev->ram_is_direct_mapped = true;
> > + } else {
> > + pr_info("RAM is DMA mapped to GPU (translated by
> IOMMU)\n");
> > + }
> > }
> >
> > static const struct attribute *amdgpu_dev_attributes[] = {
>
> --
> Hamza
Re: [PATCH] drm/amdgpu: add print for iommu translation mode
On 3/17/23 15:47, Graham Sider wrote:
Add log to display whether RAM is direct vs DMA mapped.
Signed-off-by: Graham Sider
If this information is only useful for debugging purposes, please use
drm_dbg() instead of pr_info().
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 8bba5e6872a1..8797a9523244 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3528,8 +3528,12 @@ static void amdgpu_device_check_iommu_direct_map(struct
amdgpu_device *adev)
struct iommu_domain *domain;
domain = iommu_get_domain_for_dev(adev->dev);
- if (!domain || domain->type == IOMMU_DOMAIN_IDENTITY)
+ if (!domain || domain->type == IOMMU_DOMAIN_IDENTITY) {
+ pr_info("RAM is direct mapped to GPU (not traslated by
IOMMU)\n");
adev->ram_is_direct_mapped = true;
+ } else {
+ pr_info("RAM is DMA mapped to GPU (translated by IOMMU)\n");
+ }
}
static const struct attribute *amdgpu_dev_attributes[] = {
--
Hamza
[PATCH] drm/amdgpu: add print for iommu translation mode
Add log to display whether RAM is direct vs DMA mapped.
Signed-off-by: Graham Sider
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 8bba5e6872a1..8797a9523244 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3528,8 +3528,12 @@ static void amdgpu_device_check_iommu_direct_map(struct
amdgpu_device *adev)
struct iommu_domain *domain;
domain = iommu_get_domain_for_dev(adev->dev);
- if (!domain || domain->type == IOMMU_DOMAIN_IDENTITY)
+ if (!domain || domain->type == IOMMU_DOMAIN_IDENTITY) {
+ pr_info("RAM is direct mapped to GPU (not traslated by
IOMMU)\n");
adev->ram_is_direct_mapped = true;
+ } else {
+ pr_info("RAM is DMA mapped to GPU (translated by IOMMU)\n");
+ }
}
static const struct attribute *amdgpu_dev_attributes[] = {
--
2.25.1
Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI
On Fri, Mar 17, 2023 at 07:47:52PM +0100, Sebastian Wick wrote: > On Fri, Mar 17, 2023 at 7:38 PM Ville Syrjälä > wrote: > > > > On Fri, Mar 17, 2023 at 06:40:53PM +0100, Sebastian Wick wrote: > > > On Fri, Mar 17, 2023 at 5:34 PM Ville Syrjälä > > > wrote: > > > > > > > > On Fri, Mar 17, 2023 at 05:37:51PM +0200, Pekka Paalanen wrote: > > > > > On Fri, 17 Mar 2023 16:14:38 +0200 > > > > > Ville Syrjälä wrote: > > > > > > > > > > > On Fri, Mar 17, 2023 at 03:35:53PM +0200, Pekka Paalanen wrote: > > > > > > > On Fri, 17 Mar 2023 14:50:40 +0200 > > > > > > > Ville Syrjälä wrote: > > > > > > > > > > > > > > > On Fri, Mar 17, 2023 at 10:53:35AM +0200, Pekka Paalanen wrote: > > > > > > > > > On Fri, 17 Mar 2023 01:01:38 +0200 > > > > > > > > > Ville Syrjälä wrote: > > > > > > > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 10:13:54PM +0100, Sebastian Wick > > > > > > > > > > wrote: > > > > > > > > > > > On Thu, Mar 16, 2023 at 1:35 PM Ville Syrjälä > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 01:34:49PM +0200, Pekka > > > > > > > > > > > > Paalanen wrote: > > > > > > > > > > > > > On Thu, 16 Mar 2023 12:47:51 +0200 > > > > > > > > > > > > > Ville Syrjälä wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 12:07:01PM +0200, Pekka > > > > > > > > > > > > > > Paalanen wrote: > > > > > > > > > > > > > > > On Thu, 16 Mar 2023 11:50:27 +0200 > > > > > > > > > > > > > > > Ville Syrjälä > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 01:37:24AM +0100, > > > > > > > > > > > > > > > > Sebastian Wick wrote: > > > > > > > > > > > > > > > > > On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We want compositors to be able to set the > > > > > > > > > > > > > > > > > > output > > > > > > > > > > > > > > > > > > colorspace on DP and HDMI outputs, based on > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > caps reported from the receiver via EDID. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > About that... The documentation says that > > > > > > > > > > > > > > > > > user space has to check the > > > > > > > > > > > > > > > > > EDID for what the sink actually supports. So > > > > > > > > > > > > > > > > > whatever is in > > > > > > > > > > > > > > > > > supported_colorspaces is just what the > > > > > > > > > > > > > > > > > driver/hardware is able to set > > > > > > > > > > > > > > > > > but doesn't actually indicate that the sink > > > > > > > > > > > > > > > > > supports it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So the only way to enable bt2020 is by > > > > > > > > > > > > > > > > > checking if the sink supports > > > > > > > > > > > > > > > > > both RGB and YUV variants because both could > > > > > > > > > > > > > > > > > be used by the driver. > > > > > > > > > > > > > > > > > Not great at all. Something to remember for > > > > > > > > > > > > > > > > > the new property. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hmm. I wonder if that's even legal... Looks > > > > > > > > > > > > > > > > like maybe it > > > > > > > > > > > > > > > > is since I can't immediately spot anything in > > > > > > > > > > > > > > > > CTA-861 to > > > > > > > > > > > > > > > > forbid it :/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Wouldn't the driver do the same EDID check before > > > > > > > > > > > > > > > choosing whether it > > > > > > > > > > > > > > > uses RGB or YCbCr signalling? > > > > > > > > > > > > > > > > > > > > > > > > > > > > I suppose it could. The modeset would then fail, > > > > > > > > > > > > > > which is perhaps > > > > > > > > > > > > > > > > > > > > > > > > > > Could? What are they missing? > > > > > > > > > > > > > > > > > > > > > > > > The fact that the new property that also affects the > > > > > > > > > > > > rgb->ycbcr matrix > > > > > > > > > > > > doesn't even exist? > > > > > > > > > > > > > > > > > > > > > > I think the question was about the current Colorspace > > > > > > > > > > > property. > > > > > > > > > > > > > > > > > > Yes. > > > > > > > > > > > > > > > > > > We need to be able to set ColourPrimaries infoframe field for > > > > > > > > > the sink. > > > > > > > > > Only userspace knows what ColourPrimaries it uses, and the > > > > > > > > > driver has > > > > > > > > > no need to care at all, other than tell the sink what we have. > > > > > > > > > > > > > > > > > > When a driver chooses to use YCbCr, it needs to use the > > > > > > > > > MatrixCoefficients the sink expects. > > > > > > > > > > > > > > > > > > If we send the infoframe to the sink telling the signal uses > > > > > > > > > BT.2020 > > > > > > > > > ColourPrimaries, does that same bit pattern also tell the > > > > > > > > >
Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI
On Fri, Mar 17, 2023 at 7:38 PM Ville Syrjälä wrote: > > On Fri, Mar 17, 2023 at 06:40:53PM +0100, Sebastian Wick wrote: > > On Fri, Mar 17, 2023 at 5:34 PM Ville Syrjälä > > wrote: > > > > > > On Fri, Mar 17, 2023 at 05:37:51PM +0200, Pekka Paalanen wrote: > > > > On Fri, 17 Mar 2023 16:14:38 +0200 > > > > Ville Syrjälä wrote: > > > > > > > > > On Fri, Mar 17, 2023 at 03:35:53PM +0200, Pekka Paalanen wrote: > > > > > > On Fri, 17 Mar 2023 14:50:40 +0200 > > > > > > Ville Syrjälä wrote: > > > > > > > > > > > > > On Fri, Mar 17, 2023 at 10:53:35AM +0200, Pekka Paalanen wrote: > > > > > > > > On Fri, 17 Mar 2023 01:01:38 +0200 > > > > > > > > Ville Syrjälä wrote: > > > > > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 10:13:54PM +0100, Sebastian Wick > > > > > > > > > wrote: > > > > > > > > > > On Thu, Mar 16, 2023 at 1:35 PM Ville Syrjälä > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 01:34:49PM +0200, Pekka Paalanen > > > > > > > > > > > wrote: > > > > > > > > > > > > On Thu, 16 Mar 2023 12:47:51 +0200 > > > > > > > > > > > > Ville Syrjälä wrote: > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 12:07:01PM +0200, Pekka > > > > > > > > > > > > > Paalanen wrote: > > > > > > > > > > > > > > On Thu, 16 Mar 2023 11:50:27 +0200 > > > > > > > > > > > > > > Ville Syrjälä wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 01:37:24AM +0100, > > > > > > > > > > > > > > > Sebastian Wick wrote: > > > > > > > > > > > > > > > > On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We want compositors to be able to set the > > > > > > > > > > > > > > > > > output > > > > > > > > > > > > > > > > > colorspace on DP and HDMI outputs, based on > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > caps reported from the receiver via EDID. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > About that... The documentation says that user > > > > > > > > > > > > > > > > space has to check the > > > > > > > > > > > > > > > > EDID for what the sink actually supports. So > > > > > > > > > > > > > > > > whatever is in > > > > > > > > > > > > > > > > supported_colorspaces is just what the > > > > > > > > > > > > > > > > driver/hardware is able to set > > > > > > > > > > > > > > > > but doesn't actually indicate that the sink > > > > > > > > > > > > > > > > supports it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So the only way to enable bt2020 is by checking > > > > > > > > > > > > > > > > if the sink supports > > > > > > > > > > > > > > > > both RGB and YUV variants because both could be > > > > > > > > > > > > > > > > used by the driver. > > > > > > > > > > > > > > > > Not great at all. Something to remember for the > > > > > > > > > > > > > > > > new property. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hmm. I wonder if that's even legal... Looks like > > > > > > > > > > > > > > > maybe it > > > > > > > > > > > > > > > is since I can't immediately spot anything in > > > > > > > > > > > > > > > CTA-861 to > > > > > > > > > > > > > > > forbid it :/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > Wouldn't the driver do the same EDID check before > > > > > > > > > > > > > > choosing whether it > > > > > > > > > > > > > > uses RGB or YCbCr signalling? > > > > > > > > > > > > > > > > > > > > > > > > > > I suppose it could. The modeset would then fail, > > > > > > > > > > > > > which is perhaps > > > > > > > > > > > > > > > > > > > > > > > > Could? What are they missing? > > > > > > > > > > > > > > > > > > > > > > The fact that the new property that also affects the > > > > > > > > > > > rgb->ycbcr matrix > > > > > > > > > > > doesn't even exist? > > > > > > > > > > > > > > > > > > > > I think the question was about the current Colorspace > > > > > > > > > > property. > > > > > > > > > > > > > > > > Yes. > > > > > > > > > > > > > > > > We need to be able to set ColourPrimaries infoframe field for > > > > > > > > the sink. > > > > > > > > Only userspace knows what ColourPrimaries it uses, and the > > > > > > > > driver has > > > > > > > > no need to care at all, other than tell the sink what we have. > > > > > > > > > > > > > > > > When a driver chooses to use YCbCr, it needs to use the > > > > > > > > MatrixCoefficients the sink expects. > > > > > > > > > > > > > > > > If we send the infoframe to the sink telling the signal uses > > > > > > > > BT.2020 > > > > > > > > ColourPrimaries, does that same bit pattern also tell the sink > > > > > > > > we are > > > > > > > > using the BT.2020 NCL MatrixCoefficients if the driver chooses > > > > > > > > YCbCr? > > > > > > > > > > > > > > > > Do drivers actually use BT.2020 NCL MatrixCoefficients in that > > > > > > > > case? > > > > > > > > > > > > > > No. I think I've repeated thi
Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI
On Fri, Mar 17, 2023 at 06:40:53PM +0100, Sebastian Wick wrote: > On Fri, Mar 17, 2023 at 5:34 PM Ville Syrjälä > wrote: > > > > On Fri, Mar 17, 2023 at 05:37:51PM +0200, Pekka Paalanen wrote: > > > On Fri, 17 Mar 2023 16:14:38 +0200 > > > Ville Syrjälä wrote: > > > > > > > On Fri, Mar 17, 2023 at 03:35:53PM +0200, Pekka Paalanen wrote: > > > > > On Fri, 17 Mar 2023 14:50:40 +0200 > > > > > Ville Syrjälä wrote: > > > > > > > > > > > On Fri, Mar 17, 2023 at 10:53:35AM +0200, Pekka Paalanen wrote: > > > > > > > On Fri, 17 Mar 2023 01:01:38 +0200 > > > > > > > Ville Syrjälä wrote: > > > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 10:13:54PM +0100, Sebastian Wick wrote: > > > > > > > > > On Thu, Mar 16, 2023 at 1:35 PM Ville Syrjälä > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 01:34:49PM +0200, Pekka Paalanen > > > > > > > > > > wrote: > > > > > > > > > > > On Thu, 16 Mar 2023 12:47:51 +0200 > > > > > > > > > > > Ville Syrjälä wrote: > > > > > > > > > > > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 12:07:01PM +0200, Pekka > > > > > > > > > > > > Paalanen wrote: > > > > > > > > > > > > > On Thu, 16 Mar 2023 11:50:27 +0200 > > > > > > > > > > > > > Ville Syrjälä wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 01:37:24AM +0100, Sebastian > > > > > > > > > > > > > > Wick wrote: > > > > > > > > > > > > > > > On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We want compositors to be able to set the output > > > > > > > > > > > > > > > > colorspace on DP and HDMI outputs, based on the > > > > > > > > > > > > > > > > caps reported from the receiver via EDID. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > About that... The documentation says that user > > > > > > > > > > > > > > > space has to check the > > > > > > > > > > > > > > > EDID for what the sink actually supports. So > > > > > > > > > > > > > > > whatever is in > > > > > > > > > > > > > > > supported_colorspaces is just what the > > > > > > > > > > > > > > > driver/hardware is able to set > > > > > > > > > > > > > > > but doesn't actually indicate that the sink > > > > > > > > > > > > > > > supports it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So the only way to enable bt2020 is by checking > > > > > > > > > > > > > > > if the sink supports > > > > > > > > > > > > > > > both RGB and YUV variants because both could be > > > > > > > > > > > > > > > used by the driver. > > > > > > > > > > > > > > > Not great at all. Something to remember for the > > > > > > > > > > > > > > > new property. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hmm. I wonder if that's even legal... Looks like > > > > > > > > > > > > > > maybe it > > > > > > > > > > > > > > is since I can't immediately spot anything in > > > > > > > > > > > > > > CTA-861 to > > > > > > > > > > > > > > forbid it :/ > > > > > > > > > > > > > > > > > > > > > > > > > > Wouldn't the driver do the same EDID check before > > > > > > > > > > > > > choosing whether it > > > > > > > > > > > > > uses RGB or YCbCr signalling? > > > > > > > > > > > > > > > > > > > > > > > > I suppose it could. The modeset would then fail, which > > > > > > > > > > > > is perhaps > > > > > > > > > > > > > > > > > > > > > > Could? What are they missing? > > > > > > > > > > > > > > > > > > > > The fact that the new property that also affects the > > > > > > > > > > rgb->ycbcr matrix > > > > > > > > > > doesn't even exist? > > > > > > > > > > > > > > > > > > I think the question was about the current Colorspace > > > > > > > > > property. > > > > > > > > > > > > > > Yes. > > > > > > > > > > > > > > We need to be able to set ColourPrimaries infoframe field for the > > > > > > > sink. > > > > > > > Only userspace knows what ColourPrimaries it uses, and the driver > > > > > > > has > > > > > > > no need to care at all, other than tell the sink what we have. > > > > > > > > > > > > > > When a driver chooses to use YCbCr, it needs to use the > > > > > > > MatrixCoefficients the sink expects. > > > > > > > > > > > > > > If we send the infoframe to the sink telling the signal uses > > > > > > > BT.2020 > > > > > > > ColourPrimaries, does that same bit pattern also tell the sink we > > > > > > > are > > > > > > > using the BT.2020 NCL MatrixCoefficients if the driver chooses > > > > > > > YCbCr? > > > > > > > > > > > > > > Do drivers actually use BT.2020 NCL MatrixCoefficients in that > > > > > > > case? > > > > > > > > > > > > No. I think I've repeated this same line a thousand times already: > > > > > > The current colorspace property *only* affects the > > > > > > infoframe/msa/sdp, > > > > > > nothing else. > > > > > > > > > > That's the problem. I don't know what that means. > > > > > > > > > > Does it mean that the sink expects BT.2020 NCL MatrixCoefficients to > > > > > have been used?
Re: [Intel-gfx] [BUG 6.3-rc1] Bad lock in ttm_bo_delayed_delete()
On Wed, Mar 15, 2023 at 5:22 PM Steven Rostedt wrote:
>
> I hope that this gets in by -rc3, as I want to start basing my next branch
> on that tag.
My tree should have it now as commit c00133a9e87e ("drm/ttm: drop
extra ttm_bo_put in ttm_bo_cleanup_refs").
Linus
Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI
On Fri, Mar 17, 2023 at 5:34 PM Ville Syrjälä wrote: > > On Fri, Mar 17, 2023 at 05:37:51PM +0200, Pekka Paalanen wrote: > > On Fri, 17 Mar 2023 16:14:38 +0200 > > Ville Syrjälä wrote: > > > > > On Fri, Mar 17, 2023 at 03:35:53PM +0200, Pekka Paalanen wrote: > > > > On Fri, 17 Mar 2023 14:50:40 +0200 > > > > Ville Syrjälä wrote: > > > > > > > > > On Fri, Mar 17, 2023 at 10:53:35AM +0200, Pekka Paalanen wrote: > > > > > > On Fri, 17 Mar 2023 01:01:38 +0200 > > > > > > Ville Syrjälä wrote: > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 10:13:54PM +0100, Sebastian Wick wrote: > > > > > > > > On Thu, Mar 16, 2023 at 1:35 PM Ville Syrjälä > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 01:34:49PM +0200, Pekka Paalanen > > > > > > > > > wrote: > > > > > > > > > > On Thu, 16 Mar 2023 12:47:51 +0200 > > > > > > > > > > Ville Syrjälä wrote: > > > > > > > > > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 12:07:01PM +0200, Pekka Paalanen > > > > > > > > > > > wrote: > > > > > > > > > > > > On Thu, 16 Mar 2023 11:50:27 +0200 > > > > > > > > > > > > Ville Syrjälä wrote: > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 01:37:24AM +0100, Sebastian > > > > > > > > > > > > > Wick wrote: > > > > > > > > > > > > > > On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We want compositors to be able to set the output > > > > > > > > > > > > > > > colorspace on DP and HDMI outputs, based on the > > > > > > > > > > > > > > > caps reported from the receiver via EDID. > > > > > > > > > > > > > > > > > > > > > > > > > > > > About that... The documentation says that user > > > > > > > > > > > > > > space has to check the > > > > > > > > > > > > > > EDID for what the sink actually supports. So > > > > > > > > > > > > > > whatever is in > > > > > > > > > > > > > > supported_colorspaces is just what the > > > > > > > > > > > > > > driver/hardware is able to set > > > > > > > > > > > > > > but doesn't actually indicate that the sink > > > > > > > > > > > > > > supports it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > So the only way to enable bt2020 is by checking if > > > > > > > > > > > > > > the sink supports > > > > > > > > > > > > > > both RGB and YUV variants because both could be > > > > > > > > > > > > > > used by the driver. > > > > > > > > > > > > > > Not great at all. Something to remember for the new > > > > > > > > > > > > > > property. > > > > > > > > > > > > > > > > > > > > > > > > > > Hmm. I wonder if that's even legal... Looks like > > > > > > > > > > > > > maybe it > > > > > > > > > > > > > is since I can't immediately spot anything in CTA-861 > > > > > > > > > > > > > to > > > > > > > > > > > > > forbid it :/ > > > > > > > > > > > > > > > > > > > > > > > > Wouldn't the driver do the same EDID check before > > > > > > > > > > > > choosing whether it > > > > > > > > > > > > uses RGB or YCbCr signalling? > > > > > > > > > > > > > > > > > > > > > > I suppose it could. The modeset would then fail, which is > > > > > > > > > > > perhaps > > > > > > > > > > > > > > > > > > > > Could? What are they missing? > > > > > > > > > > > > > > > > > > The fact that the new property that also affects the > > > > > > > > > rgb->ycbcr matrix > > > > > > > > > doesn't even exist? > > > > > > > > > > > > > > > > I think the question was about the current Colorspace property. > > > > > > > > > > > > Yes. > > > > > > > > > > > > We need to be able to set ColourPrimaries infoframe field for the > > > > > > sink. > > > > > > Only userspace knows what ColourPrimaries it uses, and the driver > > > > > > has > > > > > > no need to care at all, other than tell the sink what we have. > > > > > > > > > > > > When a driver chooses to use YCbCr, it needs to use the > > > > > > MatrixCoefficients the sink expects. > > > > > > > > > > > > If we send the infoframe to the sink telling the signal uses BT.2020 > > > > > > ColourPrimaries, does that same bit pattern also tell the sink we > > > > > > are > > > > > > using the BT.2020 NCL MatrixCoefficients if the driver chooses > > > > > > YCbCr? > > > > > > > > > > > > Do drivers actually use BT.2020 NCL MatrixCoefficients in that case? > > > > > > > > > > No. I think I've repeated this same line a thousand times already: > > > > > The current colorspace property *only* affects the infoframe/msa/sdp, > > > > > nothing else. > > > > > > > > That's the problem. I don't know what that means. > > > > > > > > Does it mean that the sink expects BT.2020 NCL MatrixCoefficients to > > > > have been used? > > > > > > Yes, assuming that is the colorspace property value you picked. > > > > > > > > > > > And the driver will never use BT.2020 NCL MatrixCoefficients in any > > > > circumstances? > > > > > > Correct. > > > > > > > > > > > See the conflict? The sink will be decoding the signal incorrectly, > > > > because we are encodi
[PATCH 10/10] drm/amdgpu: bump driver version number for CP GFX shadow
So UMDs can determine whether the kernel supports this. Mesa MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21986 Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c index 5f02c530e2cc..9caa7b7f52dd 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c @@ -110,9 +110,10 @@ * 3.52.0 - Add AMDGPU_IDS_FLAGS_CONFORMANT_TRUNC_COORD, add device_info fields: *tcp_cache_size, num_sqc_per_wgp, sqc_data_cache_size, sqc_inst_cache_size, *gl1c_cache_size, gl2c_cache_size, mall_size, enabled_rb_pipes_mask_hi + * 3.53.0 - Support for GFX11 CP GFX shadowing */ #define KMS_DRIVER_MAJOR 3 -#define KMS_DRIVER_MINOR 52 +#define KMS_DRIVER_MINOR 53 #define KMS_DRIVER_PATCHLEVEL 0 unsigned int amdgpu_vram_limit = UINT_MAX; -- 2.39.2
[PATCH 09/10] drm/amdgpu: add support for new GFX shadow size query
Use the new callback to fetch the data. Return an error if
not supported. UMDs should use this query to check whether
shadow buffers are supported and if so what size they
should be.
v2: return an error rather than a zerod structure.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 26 +
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index 9e85eedb57d8..8a6764756dcf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -1139,6 +1139,32 @@ int amdgpu_info_ioctl(struct drm_device *dev, void
*data, struct drm_file *filp)
kfree(caps);
return r;
}
+ case AMDGPU_INFO_CP_GFX_SHADOW_SIZE: {
+ struct amdgpu_gfx_shadow_info shadow_info;
+ struct drm_amdgpu_info_cp_gfx_shadow_size drm_shadow_size;
+ int r;
+
+ memset(&shadow_info, 0, sizeof(struct amdgpu_gfx_shadow_info));
+ if (adev->gfx.funcs->get_gfx_shadow_info) {
+ r = amdgpu_gfx_get_gfx_shadow_info(adev, &shadow_info);
+ if (r)
+ return r;
+ drm_shadow_size.shadow_size = shadow_info.shadow_size;
+ drm_shadow_size.shadow_alignment =
shadow_info.shadow_alignment;
+ drm_shadow_size.csa_size = shadow_info.csa_size;
+ drm_shadow_size.csa_alignment =
shadow_info.csa_alignment;
+ drm_shadow_size.gds_size = shadow_info.gds_size;
+ drm_shadow_size.gds_alignment =
shadow_info.gds_alignment;
+ } else {
+ return -ENOTSUPP;
+ }
+ r = copy_to_user(out, &drm_shadow_size,
+min((size_t)size,
+sizeof(struct
drm_amdgpu_info_cp_gfx_shadow_size))) ?
+ -EFAULT : 0;
+ return r;
+
+ }
default:
DRM_DEBUG_KMS("Invalid request %d\n", info->query);
return -EINVAL;
--
2.39.2
[PATCH 08/10] drm/amdgpu: add get_gfx_shadow_info callback for gfx11
XXX: don't apply this until we get the final FW versions
Used to get the size and alignment requirements for
the gfx shadow buffer for preemption.
v2: use FW version check to determine whether to
return a valid size here
return an error if not supported (Alex)
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 27 ++
1 file changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
index 0a507b7939f4..87b3d777e9ac 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
@@ -822,6 +822,32 @@ static void gfx_v11_0_select_me_pipe_q(struct
amdgpu_device *adev,
soc21_grbm_select(adev, me, pipe, q, vm);
}
+/* all sizes are in bytes */
+#define MQD_SHADOW_BASE_SIZE 73728
+#define MQD_SHADOW_BASE_ALIGNMENT 256
+#define MQD_FWWORKAREA_SIZE 484
+#define MQD_FWWORKAREA_ALIGNMENT 256
+
+static int gfx_v11_0_get_gfx_shadow_info(struct amdgpu_device *adev,
+struct amdgpu_gfx_shadow_info
*shadow_info)
+{
+ if (shadow_info) {
+ if (adev->gfx.cp_gfx_shadow) {
+ shadow_info->shadow_size = MQD_SHADOW_BASE_SIZE;
+ shadow_info->shadow_alignment =
MQD_SHADOW_BASE_ALIGNMENT;
+ shadow_info->csa_size = MQD_FWWORKAREA_SIZE;
+ shadow_info->csa_alignment = MQD_FWWORKAREA_ALIGNMENT;
+ shadow_info->gds_size = 0x1000;
+ shadow_info->gds_alignment = 256;
+ return 0;
+ } else {
+ memset(shadow_info, 0, sizeof(struct
amdgpu_gfx_shadow_info));
+ return -ENOTSUPP;
+ }
+ }
+ return -EINVAL;
+}
+
static const struct amdgpu_gfx_funcs gfx_v11_0_gfx_funcs = {
.get_gpu_clock_counter = &gfx_v11_0_get_gpu_clock_counter,
.select_se_sh = &gfx_v11_0_select_se_sh,
@@ -830,6 +856,7 @@ static const struct amdgpu_gfx_funcs gfx_v11_0_gfx_funcs = {
.read_wave_vgprs = &gfx_v11_0_read_wave_vgprs,
.select_me_pipe_q = &gfx_v11_0_select_me_pipe_q,
.update_perfmon_mgcg = &gfx_v11_0_update_perf_clk,
+ .get_gfx_shadow_info = &gfx_v11_0_get_gfx_shadow_info,
};
static int gfx_v11_0_gpu_early_init(struct amdgpu_device *adev)
--
2.39.2
[PATCH 04/10] drm/amdgpu: add gfx11 emit shadow callback
From: Christian König
Add ring callback for gfx to update the CP firmware
with the new shadow information before we process the
IB.
v2: add implementation for new packet (Alex)
v3: add current FW version checks (Alex)
v4: only initialize shadow on first use
Only set IB_VMID when a valid shadow buffer is present
(Alex)
Signed-off-by: Christian König
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 2 ++
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 46 +
drivers/gpu/drm/amd/amdgpu/nvd.h| 5 ++-
3 files changed, 52 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
index de9e7a00bb15..4ad9e225d6e6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
@@ -364,6 +364,8 @@ struct amdgpu_gfx {
struct amdgpu_ring sw_gfx_ring[AMDGPU_MAX_SW_GFX_RINGS];
struct amdgpu_ring_mux muxer;
+
+ boolcp_gfx_shadow; /* for gfx11 */
};
#define amdgpu_gfx_get_gpu_clock_counter(adev)
(adev)->gfx.funcs->get_gpu_clock_counter((adev))
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
index 3bf697a80cf2..166a3f640042 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
@@ -463,6 +463,27 @@ static int gfx_v11_0_init_toc_microcode(struct
amdgpu_device *adev, const char *
return err;
}
+static void gfx_v11_0_check_fw_cp_gfx_shadow(struct amdgpu_device *adev)
+{
+ switch (adev->ip_versions[GC_HWIP][0]) {
+ case IP_VERSION(11, 0, 0):
+ case IP_VERSION(11, 0, 2):
+ case IP_VERSION(11, 0, 3):
+ /* XXX fix me! */
+ if ((adev->gfx.me_fw_version >= 1498) &&
+ (adev->gfx.me_feature_version >= 29) &&
+ (adev->gfx.pfp_fw_version >= 1541) &&
+ (adev->gfx.pfp_feature_version >= 29) &&
+ (adev->gfx.mec_fw_version >= 507) &&
+ (adev->gfx.mec_feature_version >= 29))
+ adev->gfx.cp_gfx_shadow = true;
+ break;
+ default:
+ adev->gfx.cp_gfx_shadow = false;
+ break;
+ }
+}
+
static int gfx_v11_0_init_microcode(struct amdgpu_device *adev)
{
char fw_name[40];
@@ -539,6 +560,7 @@ static int gfx_v11_0_init_microcode(struct amdgpu_device
*adev)
/* only one MEC for gfx 11.0.0. */
adev->gfx.mec2_fw = NULL;
+ gfx_v11_0_check_fw_cp_gfx_shadow(adev);
out:
if (err) {
amdgpu_ucode_release(&adev->gfx.pfp_fw);
@@ -5563,6 +5585,28 @@ static void gfx_v11_0_ring_emit_cntxcntl(struct
amdgpu_ring *ring,
amdgpu_ring_write(ring, 0);
}
+static void gfx_v11_0_ring_emit_gfx_shadow(struct amdgpu_ring *ring,
+ struct amdgpu_job *job)
+{
+ unsigned vmid = AMDGPU_JOB_GET_VMID(job);
+ struct amdgpu_device *adev = ring->adev;
+
+ if (!adev->gfx.cp_gfx_shadow)
+ return;
+
+ amdgpu_ring_write(ring, PACKET3(PACKET3_SET_Q_PREEMPTION_MODE, 7));
+ amdgpu_ring_write(ring, lower_32_bits(job->shadow_va));
+ amdgpu_ring_write(ring, upper_32_bits(job->shadow_va));
+ amdgpu_ring_write(ring, lower_32_bits(job->gds_va));
+ amdgpu_ring_write(ring, upper_32_bits(job->gds_va));
+ amdgpu_ring_write(ring, lower_32_bits(job->csa_va));
+ amdgpu_ring_write(ring, upper_32_bits(job->csa_va));
+ amdgpu_ring_write(ring, job->shadow_va ?
+ PACKET3_SET_Q_PREEMPTION_MODE_IB_VMID(vmid) : 0);
+ amdgpu_ring_write(ring, job->init_shadow ?
+ PACKET3_SET_Q_PREEMPTION_MODE_INIT_SHADOW_MEM : 0);
+}
+
static unsigned gfx_v11_0_ring_emit_init_cond_exec(struct amdgpu_ring *ring)
{
unsigned ret;
@@ -6183,6 +6227,7 @@ static const struct amdgpu_ring_funcs
gfx_v11_0_ring_funcs_gfx = {
.set_wptr = gfx_v11_0_ring_set_wptr_gfx,
.emit_frame_size = /* totally 242 maximum if 16 IBs */
5 + /* COND_EXEC */
+ 9 + /* SET_Q_PREEMPTION_MODE */
7 + /* PIPELINE_SYNC */
SOC15_FLUSH_GPU_TLB_NUM_WREG * 5 +
SOC15_FLUSH_GPU_TLB_NUM_REG_WAIT * 7 +
@@ -6209,6 +6254,7 @@ static const struct amdgpu_ring_funcs
gfx_v11_0_ring_funcs_gfx = {
.insert_nop = amdgpu_ring_insert_nop,
.pad_ib = amdgpu_ring_generic_pad_ib,
.emit_cntxcntl = gfx_v11_0_ring_emit_cntxcntl,
+ .emit_gfx_shadow = gfx_v11_0_ring_emit_gfx_shadow,
.init_cond_exec = gfx_v11_0_ring_emit_init_cond_exec,
.patch_cond_exec = gfx_v11_0_ring_emit_patch_cond_exec,
.preempt_ib = gfx_v11_0_ring_preempt_ib,
diff --git a/drivers/gpu/drm/amd/amdgpu/nvd.h b/drivers/gpu/drm/amd/amdgpu/nvd.h
index fd6b58243b03..631dafb92299 1006
[PATCH 07/10] drm/amdgpu: add gfx shadow callback
To provide IP specific shadow sizes. UMDs will use
this to query the kernel driver for the size of the
shadow buffers.
v2: make callback return an int (Alex)
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
index 4ad9e225d6e6..8826f1efc75f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
@@ -219,6 +219,15 @@ struct amdgpu_gfx_ras {
struct amdgpu_iv_entry *entry);
};
+struct amdgpu_gfx_shadow_info {
+ u32 shadow_size;
+ u32 shadow_alignment;
+ u32 csa_size;
+ u32 csa_alignment;
+ u32 gds_size;
+ u32 gds_alignment;
+};
+
struct amdgpu_gfx_funcs {
/* get the gpu clock counter */
uint64_t (*get_gpu_clock_counter)(struct amdgpu_device *adev);
@@ -236,6 +245,8 @@ struct amdgpu_gfx_funcs {
u32 queue, u32 vmid);
void (*init_spm_golden)(struct amdgpu_device *adev);
void (*update_perfmon_mgcg)(struct amdgpu_device *adev, bool enable);
+ int (*get_gfx_shadow_info)(struct amdgpu_device *adev,
+ struct amdgpu_gfx_shadow_info *shadow_info);
};
struct sq_work {
@@ -372,6 +383,7 @@ struct amdgpu_gfx {
#define amdgpu_gfx_select_se_sh(adev, se, sh, instance)
(adev)->gfx.funcs->select_se_sh((adev), (se), (sh), (instance))
#define amdgpu_gfx_select_me_pipe_q(adev, me, pipe, q, vmid)
(adev)->gfx.funcs->select_me_pipe_q((adev), (me), (pipe), (q), (vmid))
#define amdgpu_gfx_init_spm_golden(adev)
(adev)->gfx.funcs->init_spm_golden((adev))
+#define amdgpu_gfx_get_gfx_shadow_info(adev, si)
(adev)->gfx.funcs->get_gfx_shadow_info((adev), (si))
/**
* amdgpu_gfx_create_bitmask - create a bitmask
--
2.39.2
[PATCH 06/10] drm/amdgpu: don't require a job for cond_exec and shadow
We need to reset the shadow state every time we submit an IB and there needs to be a COND_EXEC packet after the SET_Q_PREEMPTION_MODE packet for it to work properly, so we should emit both of these packets regardless of whether there is a job present or not. Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c index d88964b9407f..cd5b0df44ffb 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c @@ -213,10 +213,10 @@ int amdgpu_ib_schedule(struct amdgpu_ring *ring, unsigned num_ibs, amdgpu_ring_ib_begin(ring); - if (job && ring->funcs->emit_gfx_shadow) + if (ring->funcs->emit_gfx_shadow) amdgpu_ring_emit_gfx_shadow(ring, job); - if (job && ring->funcs->init_cond_exec) + if (ring->funcs->init_cond_exec) patch_offset = amdgpu_ring_init_cond_exec(ring); amdgpu_device_flush_hdp(adev, ring); -- 2.39.2
[PATCH 05/10] drm/amdgpu/gfx11: make job optional in emit_gfx_shadow
We need to emit this packet any time we emit an IB, not
just when we have a job. When no job is present just
send all 0's to reset to the legacy state.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 34 +-
1 file changed, 23 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
index 166a3f640042..0a507b7939f4 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
@@ -5594,17 +5594,29 @@ static void gfx_v11_0_ring_emit_gfx_shadow(struct
amdgpu_ring *ring,
if (!adev->gfx.cp_gfx_shadow)
return;
- amdgpu_ring_write(ring, PACKET3(PACKET3_SET_Q_PREEMPTION_MODE, 7));
- amdgpu_ring_write(ring, lower_32_bits(job->shadow_va));
- amdgpu_ring_write(ring, upper_32_bits(job->shadow_va));
- amdgpu_ring_write(ring, lower_32_bits(job->gds_va));
- amdgpu_ring_write(ring, upper_32_bits(job->gds_va));
- amdgpu_ring_write(ring, lower_32_bits(job->csa_va));
- amdgpu_ring_write(ring, upper_32_bits(job->csa_va));
- amdgpu_ring_write(ring, job->shadow_va ?
- PACKET3_SET_Q_PREEMPTION_MODE_IB_VMID(vmid) : 0);
- amdgpu_ring_write(ring, job->init_shadow ?
- PACKET3_SET_Q_PREEMPTION_MODE_INIT_SHADOW_MEM : 0);
+ if (job) {
+ amdgpu_ring_write(ring, PACKET3(PACKET3_SET_Q_PREEMPTION_MODE,
7));
+ amdgpu_ring_write(ring, lower_32_bits(job->shadow_va));
+ amdgpu_ring_write(ring, upper_32_bits(job->shadow_va));
+ amdgpu_ring_write(ring, lower_32_bits(job->gds_va));
+ amdgpu_ring_write(ring, upper_32_bits(job->gds_va));
+ amdgpu_ring_write(ring, lower_32_bits(job->csa_va));
+ amdgpu_ring_write(ring, upper_32_bits(job->csa_va));
+ amdgpu_ring_write(ring, job->shadow_va ?
+ PACKET3_SET_Q_PREEMPTION_MODE_IB_VMID(vmid) :
0);
+ amdgpu_ring_write(ring, job->init_shadow ?
+ PACKET3_SET_Q_PREEMPTION_MODE_INIT_SHADOW_MEM
: 0);
+ } else {
+ amdgpu_ring_write(ring, PACKET3(PACKET3_SET_Q_PREEMPTION_MODE,
7));
+ amdgpu_ring_write(ring, 0);
+ amdgpu_ring_write(ring, 0);
+ amdgpu_ring_write(ring, 0);
+ amdgpu_ring_write(ring, 0);
+ amdgpu_ring_write(ring, 0);
+ amdgpu_ring_write(ring, 0);
+ amdgpu_ring_write(ring, 0);
+ amdgpu_ring_write(ring, 0);
+ }
}
static unsigned gfx_v11_0_ring_emit_init_cond_exec(struct amdgpu_ring *ring)
--
2.39.2
[PATCH 01/10] drm/amdgpu: add UAPI to query GFX shadow sizes
Add UAPI to query the GFX shadow buffer requirements
for preemption on GFX11. UMDs need to specify the shadow
areas for preemption.
Signed-off-by: Alex Deucher
---
include/uapi/drm/amdgpu_drm.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h
index b6eb90df5d05..cb22bb78c373 100644
--- a/include/uapi/drm/amdgpu_drm.h
+++ b/include/uapi/drm/amdgpu_drm.h
@@ -876,6 +876,7 @@ struct drm_amdgpu_cs_chunk_data {
#define AMDGPU_INFO_VIDEO_CAPS_DECODE 0
/* Subquery id: Encode */
#define AMDGPU_INFO_VIDEO_CAPS_ENCODE 1
+#define AMDGPU_INFO_CP_GFX_SHADOW_SIZE 0x22
#define AMDGPU_INFO_MMR_SE_INDEX_SHIFT 0
#define AMDGPU_INFO_MMR_SE_INDEX_MASK 0xff
@@ -1193,6 +1194,15 @@ struct drm_amdgpu_info_video_caps {
struct drm_amdgpu_info_video_codec_info
codec_info[AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_COUNT];
};
+struct drm_amdgpu_info_cp_gfx_shadow_size {
+ __u32 shadow_size;
+ __u32 shadow_alignment;
+ __u32 csa_size;
+ __u32 csa_alignment;
+ __u32 gds_size;
+ __u32 gds_alignment;
+};
+
/*
* Supported GPU families
*/
--
2.39.2
[PATCH 02/10] drm/amdgpu/UAPI: add new CS chunk for GFX shadow buffers
For GFX11, the UMD needs to allocate some shadow buffers
to be used for preemption. The UMD allocates the buffers
and passes the GPU virtual address to the kernel since the
kernel will program the packet that specified these
addresses as part of its IB submission frame.
Signed-off-by: Alex Deucher
---
include/uapi/drm/amdgpu_drm.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h
index cb22bb78c373..be43d5f96534 100644
--- a/include/uapi/drm/amdgpu_drm.h
+++ b/include/uapi/drm/amdgpu_drm.h
@@ -592,6 +592,7 @@ struct drm_amdgpu_gem_va {
#define AMDGPU_CHUNK_ID_SCHEDULED_DEPENDENCIES 0x07
#define AMDGPU_CHUNK_ID_SYNCOBJ_TIMELINE_WAIT0x08
#define AMDGPU_CHUNK_ID_SYNCOBJ_TIMELINE_SIGNAL 0x09
+#define AMDGPU_CHUNK_ID_CP_GFX_SHADOW 0x0a
struct drm_amdgpu_cs_chunk {
__u32 chunk_id;
@@ -708,6 +709,12 @@ struct drm_amdgpu_cs_chunk_data {
};
};
+struct drm_amdgpu_cs_chunk_cp_gfx_shadow {
+ __u64 shadow_va;
+ __u64 csa_va;
+ __u64 gds_va;
+};
+
/*
* Query h/w info: Flag that this is integrated (a.h.a. fusion) GPU
*
--
2.39.2
[PATCH 03/10] drm/amdgpu: add gfx shadow CS IOCTL support
From: Christian König
Add support for submitting the shadow update packet
when submitting an IB. Needed for MCBP on GFX11.
v2: update API for CSA (Alex)
v3: fix ordering; SET_Q_PREEMPTION_MODE most come before COND_EXEC
Add missing check for AMDGPU_CHUNK_ID_CP_GFX_SHADOW in
amdgpu_cs_pass1()
Only initialize shadow on first use
(Alex)
Signed-off-by: Christian König
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 24
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 4
drivers/gpu/drm/amd/amdgpu/amdgpu_job.h | 6 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 2 ++
5 files changed, 37 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index f6144b378617..9bdda246b09c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -280,6 +280,7 @@ static int amdgpu_cs_pass1(struct amdgpu_cs_parser *p,
case AMDGPU_CHUNK_ID_SCHEDULED_DEPENDENCIES:
case AMDGPU_CHUNK_ID_SYNCOBJ_TIMELINE_WAIT:
case AMDGPU_CHUNK_ID_SYNCOBJ_TIMELINE_SIGNAL:
+ case AMDGPU_CHUNK_ID_CP_GFX_SHADOW:
break;
default:
@@ -587,6 +588,26 @@ static int amdgpu_cs_p2_syncobj_timeline_signal(struct
amdgpu_cs_parser *p,
return 0;
}
+static void amdgpu_cs_p2_shadow(struct amdgpu_cs_parser *p,
+ struct amdgpu_cs_chunk *chunk)
+{
+ struct drm_amdgpu_cs_chunk_cp_gfx_shadow *shadow = chunk->kdata;
+ bool shadow_initialized = false;
+ int i;
+
+ for (i = 0; i < p->gang_size; ++i) {
+ p->jobs[i]->shadow_va = shadow->shadow_va;
+ p->jobs[i]->csa_va = shadow->csa_va;
+ p->jobs[i]->gds_va = shadow->gds_va;
+ if (!p->ctx->shadow_initialized) {
+ p->jobs[i]->init_shadow = true;
+ shadow_initialized = true;
+ }
+ }
+ if (shadow_initialized)
+ p->ctx->shadow_initialized = true;
+}
+
static int amdgpu_cs_pass2(struct amdgpu_cs_parser *p)
{
unsigned int ce_preempt = 0, de_preempt = 0;
@@ -629,6 +650,9 @@ static int amdgpu_cs_pass2(struct amdgpu_cs_parser *p)
if (r)
return r;
break;
+ case AMDGPU_CHUNK_ID_CP_GFX_SHADOW:
+ amdgpu_cs_p2_shadow(p, chunk);
+ break;
}
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.h
index 0fa0e56daf67..909d188c41f2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.h
@@ -57,6 +57,7 @@ struct amdgpu_ctx {
unsigned long ras_counter_ce;
unsigned long ras_counter_ue;
uint32_tstable_pstate;
+ boolshadow_initialized;
};
struct amdgpu_ctx_mgr {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
index b348dbe2..d88964b9407f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
@@ -212,6 +212,10 @@ int amdgpu_ib_schedule(struct amdgpu_ring *ring, unsigned
num_ibs,
}
amdgpu_ring_ib_begin(ring);
+
+ if (job && ring->funcs->emit_gfx_shadow)
+ amdgpu_ring_emit_gfx_shadow(ring, job);
+
if (job && ring->funcs->init_cond_exec)
patch_offset = amdgpu_ring_init_cond_exec(ring);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h
index 9790def34815..b470808fa40e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h
@@ -68,6 +68,12 @@ struct amdgpu_job {
uint64_tuf_addr;
uint64_tuf_sequence;
+ /* virtual addresses for shadow/GDS/CSA */
+ uint64_tshadow_va;
+ uint64_tcsa_va;
+ uint64_tgds_va;
+ boolinit_shadow;
+
/* job_run_counter >= 1 means a resubmit job */
uint32_tjob_run_counter;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
index 3989e755a5b4..8643d4a92c27 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
@@ -212,6 +212,7 @@ struct amdgpu_ring_funcs {
void (*end_use)(struct amdgpu_ring *ring);
void (*emit_switch_buffer) (struct amdgpu_ring *ring);
void (*emit_cntxcntl) (struct amdgpu_ring *ring, uint32_t flags);
+ void (*emit_gfx_shadow)(struct amdgpu_ring *ring, struct amdgpu_job
*job);
[PATCH 00/10] Enable FW assisted shadowing for GFX11
This patch set allows for FW assisted shadowing on supported platforms. A new enough CP FW is required. This feature is required for mid command buffer preemption and proper SR-IOV support. This also simplifies the UMDs by allowing persistent hardware state when the command submission executes. UMDs that use this will have their state retained across command submissions. The mesa MR to implement the user mode side of this is: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21986 Alex Deucher (8): drm/amdgpu: add UAPI to query GFX shadow sizes drm/amdgpu/UAPI: add new CS chunk for GFX shadow buffers drm/amdgpu/gfx11: make job optional in emit_gfx_shadow drm/amdgpu: don't require a job for cond_exec and shadow drm/amdgpu: add gfx shadow callback drm/amdgpu: add get_gfx_shadow_info callback for gfx11 drm/amdgpu: add support for new GFX shadow size query drm/amdgpu: bump driver version number for CP GFX shadow Christian König (2): drm/amdgpu: add gfx shadow CS IOCTL support drm/amdgpu: add gfx11 emit shadow callback drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 24 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 14 drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 6 +- drivers/gpu/drm/amd/amdgpu/amdgpu_job.h | 6 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 26 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 2 + drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 85 drivers/gpu/drm/amd/amdgpu/nvd.h | 5 +- include/uapi/drm/amdgpu_drm.h| 17 + 11 files changed, 186 insertions(+), 3 deletions(-) -- 2.39.2
[pull] amdgpu, amdkfd, radeon, UAPI drm-next-6.4
Hi Dave, Daniel, New stuff for 6.4. The following changes since commit 424b3d7582a2a4a7c45d405225ac70cff97f2e4a: drm/amd/pm: downgrade log level upon SMU IF version mismatch (2023-02-23 17:35:59 -0500) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-next-6.4-2023-03-17 for you to fetch changes up to 7ee938ac006096fe9c3f1075f56b9263587c150f: drm/amdgpu: Don't resume IOMMU after incomplete init (2023-03-15 18:45:27 -0400) amd-drm-next-6.4-2023-03-17: amdgpu: - Misc code cleanups - Documentation fixes - Make kobj structures const - Add thermal throttling adjustments for supported APUs - UMC RAS fixes - Display reset fixes - DCN 3.2 fixes - Freesync fixes - DC code reorg - Generalize dmabuf import to work with KFD - DC DML fixes - SRIOV fixes - UVD code cleanups - IH 4.4.2 updates - HDP 4.4.2 updates - SDMA 4.4.2 updates - PSP 13.0.6 updates - Add capped/uncapped workload handling for supported APUs - DCN 3.1.4 updates - Re-org DC Kconfig - USB4 fixes - Reorg DC plane and stream handling - Register vga_switcheroo for apple-gmux - SMU 13.0.6 updates - Fix error checking in read_mm_registers functions for affected families - VCN 4.0.4 fix - Drop redundant pci_enable_pcie_error_reporting() call - RDNA2 SMU OD suspend/resume fix - Expose additional memory stats via fdinfo - RAS fixes - Misc display fixes - DP MST fixes - IOMMU regression fix for KFD amdkfd: - Make kobj structures const - Support for exporting buffers via dmabuf - Multi-VMA page migration fixes - NBIO fixes - Misc code cleanups - Fix possible double free - Fix possible UAF radeon: - iMac fix UAPI: - KFD dmabuf export support. Required for importing KFD buffers into GEM contexts and for RDMA P2P support. Proposed user mode changes: https://github.com/fxkamd/ROCT-Thunk-Interface/commits/fxkamd/dmabuf Agustin Gutierrez (1): drm/amd/display: Keep PHY active for dp config Alex Deucher (6): drm/amdgpu: fix error checking in amdgpu_read_mm_registers for soc15 drm/amdgpu: fix error checking in amdgpu_read_mm_registers for soc21 drm/amdgpu: fix error checking in amdgpu_read_mm_registers for nv Revert "drm/amdgpu/display: change pipe policy for DCN 2.1" Revert "drm/amd/display: Pass proper parent for DM backlight device registration" drm/amdgpu/nv: fix codec array for SR_IOV Alex Hung (1): drm/amd/display: fix shift-out-of-bounds in CalculateVMAndRowBytes Alvin Lee (5): drm/amd/display: DAL to program DISPCLK WDIVIDER if PMFW doesn't drm/amd/display: When blanking during init loop to find OPP index drm/amd/display: Update to correct min FCLK when construction BB drm/amd/display: Pass tg and hubp inst instead of pipe index for SubVP drm/amd/display: Use DPP inst instead of pipe idx for DPP DTO programming Anthony Koo (1): drm/amd/display: [FW Promotion] Release 0.0.158.0 Aric Cyr (9): drm/amd/display: Reduce CPU busy-waiting for long delays Revert "drm/amd/display: Do not set DRR on pipe commit" Revert "drm/amd/display: Fix FreeSync active bit issue" drm/amd/display: Only wait for blank completion if OTG active drm/amd/display: Do not update DRR while BW optimizations pending drm/amd/display: Promote DAL to 3.2.224 drm/amd/display: 3.2.225 drm/amd/display: 3.2.226 drm/amd/display: 3.2.227 Arthur Grillo (2): drm/amd/display: Remove unused local variables drm/amd/display: Remove unused local variables and function Aurabindo Pillai (1): drm/amd/display: fix clock sequence logic for DCN32 Ayush Gupta (2): drm/amd/display: populate subvp cmd info only for the top pipe drm/amd/display: disconnect MPCC only on OTG change Benjamin Cheng (1): drm/amd/display: Write to correct dirty_rect Bhawanpreet Lakha (1): drm/amd/display: Fix HDCP failing to enable after suspend Bjorn Helgaas (1): drm/amdgpu: Drop redundant pci_enable_pcie_error_reporting() Błażej Szczygieł (1): drm/amd/pm: Fix sienna cichlid incorrect OD volage after resume Candice Li (3): drm/amdgpu: Make umc_v8_10_convert_error_address static and remove unused variable drm/amdgpu: Support umc node harvest config on umc v8_10 drm/amd/pm: Enable ecc_info table support for smu v13_0_10 Chia-I Wu (2): drm/amdkfd: fix a potential double free in pqm_create_queue drm/amdkfd: fix potential kgd_mem UAFs Chris Park (1): drm/amd/display: Simplify register offsets Christian König (2): drm/amdgpu: stop waiting in amdgpu_uvd_send_msg drm/amdgpu: simplify amdgpu_uvd_send_msg Cruise Hung (1): drm/amd/display: Fix DP MST sinks removal issue Daniel Phillips (1): amdkfd: Memory availability can never be negative David Belanger (1): drm/amdkfd: Fixed k
Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI
On Fri, Mar 17, 2023 at 05:37:51PM +0200, Pekka Paalanen wrote: > On Fri, 17 Mar 2023 16:14:38 +0200 > Ville Syrjälä wrote: > > > On Fri, Mar 17, 2023 at 03:35:53PM +0200, Pekka Paalanen wrote: > > > On Fri, 17 Mar 2023 14:50:40 +0200 > > > Ville Syrjälä wrote: > > > > > > > On Fri, Mar 17, 2023 at 10:53:35AM +0200, Pekka Paalanen wrote: > > > > > On Fri, 17 Mar 2023 01:01:38 +0200 > > > > > Ville Syrjälä wrote: > > > > > > > > > > > On Thu, Mar 16, 2023 at 10:13:54PM +0100, Sebastian Wick wrote: > > > > > > > On Thu, Mar 16, 2023 at 1:35 PM Ville Syrjälä > > > > > > > wrote: > > > > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 01:34:49PM +0200, Pekka Paalanen wrote: > > > > > > > > > > > > > > > > > On Thu, 16 Mar 2023 12:47:51 +0200 > > > > > > > > > Ville Syrjälä wrote: > > > > > > > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 12:07:01PM +0200, Pekka Paalanen > > > > > > > > > > wrote: > > > > > > > > > > > On Thu, 16 Mar 2023 11:50:27 +0200 > > > > > > > > > > > Ville Syrjälä wrote: > > > > > > > > > > > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 01:37:24AM +0100, Sebastian > > > > > > > > > > > > Wick wrote: > > > > > > > > > > > > > On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > We want compositors to be able to set the output > > > > > > > > > > > > > > colorspace on DP and HDMI outputs, based on the > > > > > > > > > > > > > > caps reported from the receiver via EDID. > > > > > > > > > > > > > > > > > > > > > > > > > > About that... The documentation says that user space > > > > > > > > > > > > > has to check the > > > > > > > > > > > > > EDID for what the sink actually supports. So whatever > > > > > > > > > > > > > is in > > > > > > > > > > > > > supported_colorspaces is just what the > > > > > > > > > > > > > driver/hardware is able to set > > > > > > > > > > > > > but doesn't actually indicate that the sink supports > > > > > > > > > > > > > it. > > > > > > > > > > > > > > > > > > > > > > > > > > So the only way to enable bt2020 is by checking if > > > > > > > > > > > > > the sink supports > > > > > > > > > > > > > both RGB and YUV variants because both could be used > > > > > > > > > > > > > by the driver. > > > > > > > > > > > > > Not great at all. Something to remember for the new > > > > > > > > > > > > > property. > > > > > > > > > > > > > > > > > > > > > > > > Hmm. I wonder if that's even legal... Looks like maybe > > > > > > > > > > > > it > > > > > > > > > > > > is since I can't immediately spot anything in CTA-861 to > > > > > > > > > > > > forbid it :/ > > > > > > > > > > > > > > > > > > > > > > Wouldn't the driver do the same EDID check before > > > > > > > > > > > choosing whether it > > > > > > > > > > > uses RGB or YCbCr signalling? > > > > > > > > > > > > > > > > > > > > I suppose it could. The modeset would then fail, which is > > > > > > > > > > perhaps > > > > > > > > > > > > > > > > > > Could? What are they missing? > > > > > > > > > > > > > > > > The fact that the new property that also affects the rgb->ycbcr > > > > > > > > matrix > > > > > > > > doesn't even exist? > > > > > > > > > > > > > > I think the question was about the current Colorspace property. > > > > > > > > > > > > > > > > > Yes. > > > > > > > > > > We need to be able to set ColourPrimaries infoframe field for the > > > > > sink. > > > > > Only userspace knows what ColourPrimaries it uses, and the driver has > > > > > no need to care at all, other than tell the sink what we have. > > > > > > > > > > When a driver chooses to use YCbCr, it needs to use the > > > > > MatrixCoefficients the sink expects. > > > > > > > > > > If we send the infoframe to the sink telling the signal uses BT.2020 > > > > > ColourPrimaries, does that same bit pattern also tell the sink we are > > > > > using the BT.2020 NCL MatrixCoefficients if the driver chooses YCbCr? > > > > > > > > > > Do drivers actually use BT.2020 NCL MatrixCoefficients in that case? > > > > > > > > > > > > > No. I think I've repeated this same line a thousand times already: > > > > The current colorspace property *only* affects the infoframe/msa/sdp, > > > > nothing else. > > > > > > That's the problem. I don't know what that means. > > > > > > Does it mean that the sink expects BT.2020 NCL MatrixCoefficients to > > > have been used? > > > > Yes, assuming that is the colorspace property value you picked. > > > > > > > > And the driver will never use BT.2020 NCL MatrixCoefficients in any > > > circumstances? > > > > Correct. > > > > > > > > See the conflict? The sink will be decoding the signal incorrectly, > > > because we are encoding it with the wrong MatrixCoefficients if the > > > driver happens to silently choose YCbCr and userspace wants to send > > > BT2020 ColourPrimaries indicated in the infoframe. >
Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI
On Fri, 17 Mar 2023 16:14:38 +0200 Ville Syrjälä wrote: > On Fri, Mar 17, 2023 at 03:35:53PM +0200, Pekka Paalanen wrote: > > On Fri, 17 Mar 2023 14:50:40 +0200 > > Ville Syrjälä wrote: > > > > > On Fri, Mar 17, 2023 at 10:53:35AM +0200, Pekka Paalanen wrote: > > > > On Fri, 17 Mar 2023 01:01:38 +0200 > > > > Ville Syrjälä wrote: > > > > > > > > > On Thu, Mar 16, 2023 at 10:13:54PM +0100, Sebastian Wick wrote: > > > > > > On Thu, Mar 16, 2023 at 1:35 PM Ville Syrjälä > > > > > > wrote: > > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 01:34:49PM +0200, Pekka Paalanen wrote: > > > > > > > > > > > > > > > On Thu, 16 Mar 2023 12:47:51 +0200 > > > > > > > > Ville Syrjälä wrote: > > > > > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 12:07:01PM +0200, Pekka Paalanen > > > > > > > > > wrote: > > > > > > > > > > On Thu, 16 Mar 2023 11:50:27 +0200 > > > > > > > > > > Ville Syrjälä wrote: > > > > > > > > > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 01:37:24AM +0100, Sebastian Wick > > > > > > > > > > > wrote: > > > > > > > > > > > > On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > We want compositors to be able to set the output > > > > > > > > > > > > > colorspace on DP and HDMI outputs, based on the > > > > > > > > > > > > > caps reported from the receiver via EDID. > > > > > > > > > > > > > > > > > > > > > > > > About that... The documentation says that user space > > > > > > > > > > > > has to check the > > > > > > > > > > > > EDID for what the sink actually supports. So whatever > > > > > > > > > > > > is in > > > > > > > > > > > > supported_colorspaces is just what the driver/hardware > > > > > > > > > > > > is able to set > > > > > > > > > > > > but doesn't actually indicate that the sink supports it. > > > > > > > > > > > > > > > > > > > > > > > > So the only way to enable bt2020 is by checking if the > > > > > > > > > > > > sink supports > > > > > > > > > > > > both RGB and YUV variants because both could be used by > > > > > > > > > > > > the driver. > > > > > > > > > > > > Not great at all. Something to remember for the new > > > > > > > > > > > > property. > > > > > > > > > > > > > > > > > > > > > > Hmm. I wonder if that's even legal... Looks like maybe it > > > > > > > > > > > is since I can't immediately spot anything in CTA-861 to > > > > > > > > > > > forbid it :/ > > > > > > > > > > > > > > > > > > > > Wouldn't the driver do the same EDID check before choosing > > > > > > > > > > whether it > > > > > > > > > > uses RGB or YCbCr signalling? > > > > > > > > > > > > > > > > > > I suppose it could. The modeset would then fail, which is > > > > > > > > > perhaps > > > > > > > > > > > > > > > > Could? What are they missing? > > > > > > > > > > > > > > The fact that the new property that also affects the rgb->ycbcr > > > > > > > matrix > > > > > > > doesn't even exist? > > > > > > > > > > > > I think the question was about the current Colorspace property. > > > > > > > > Yes. > > > > > > > > We need to be able to set ColourPrimaries infoframe field for the sink. > > > > Only userspace knows what ColourPrimaries it uses, and the driver has > > > > no need to care at all, other than tell the sink what we have. > > > > > > > > When a driver chooses to use YCbCr, it needs to use the > > > > MatrixCoefficients the sink expects. > > > > > > > > If we send the infoframe to the sink telling the signal uses BT.2020 > > > > ColourPrimaries, does that same bit pattern also tell the sink we are > > > > using the BT.2020 NCL MatrixCoefficients if the driver chooses YCbCr? > > > > > > > > Do drivers actually use BT.2020 NCL MatrixCoefficients in that case? > > > > > > No. I think I've repeated this same line a thousand times already: > > > The current colorspace property *only* affects the infoframe/msa/sdp, > > > nothing else. > > > > That's the problem. I don't know what that means. > > > > Does it mean that the sink expects BT.2020 NCL MatrixCoefficients to > > have been used? > > Yes, assuming that is the colorspace property value you picked. > > > > > And the driver will never use BT.2020 NCL MatrixCoefficients in any > > circumstances? > > Correct. > > > > > See the conflict? The sink will be decoding the signal incorrectly, > > because we are encoding it with the wrong MatrixCoefficients if the > > driver happens to silently choose YCbCr and userspace wants to send > > BT2020 ColourPrimaries indicated in the infoframe. > > Yes. And hence I thought pretty much everyone already > agreed that a new property is needed. I think I was confused as well with the re-posting of this series, thinking it could be salvageable somehow and tried to understand how. Up to Harry, I think I've left enough annoying questions by now. :-) > To make sure we actually understand what we're implement
[linux-next:master] BUILD REGRESSION 6f08c1de13a9403341c18b66638a05588b2663ce
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 6f08c1de13a9403341c18b66638a05588b2663ce Add linux-next specific files for 20230317 Error/Warning reports: https://lore.kernel.org/oe-kbuild-all/202303081807.lblwkmpx-...@intel.com https://lore.kernel.org/oe-kbuild-all/202303082135.njdx1bij-...@intel.com https://lore.kernel.org/oe-kbuild-all/202303151409.por0sbf7-...@intel.com https://lore.kernel.org/oe-kbuild-all/202303161404.ormfcy09-...@intel.com https://lore.kernel.org/oe-kbuild-all/202303161521.jbgbafjj-...@intel.com https://lore.kernel.org/oe-kbuild-all/202303171300.g6uem0x9-...@intel.com https://lore.kernel.org/oe-kbuild-all/202303171506.af2gnuda-...@intel.com https://lore.kernel.org/oe-kbuild-all/202303171606.xoywr7lj-...@intel.com Error/Warning: (recently discovered and may have been fixed) Warning: Documentation/devicetree/bindings/input/snvs-pwrkey.txt references a file that doesn't exist: Documentation/devicetree/bindings/crypto/fsl-sec4.txt Warning: Documentation/devicetree/bindings/rtc/snvs-rtc.txt references a file that doesn't exist: Documentation/devicetree/bindings/crypto/fsl-sec4.txt Warning: MAINTAINERS references a file that doesn't exist: Documentation/devicetree/bindings/crypto/fsl-sec4.txt drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_validation.c:258:10: warning: no previous prototype for 'link_timing_bandwidth_kbps' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_capability.c:2184: warning: expecting prototype for Check if there is a native DP or passive DP(). Prototype was for dp_is_sink_present() instead drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu13/smu_v13_0_6_ppt.c:309:17: sparse: int drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu13/smu_v13_0_6_ppt.c:309:17: sparse: void drivers/net/wireless/legacy/ray_cs.c:628:17: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation] include/linux/compiler_types.h:338:27: error: expression in static assertion is not an integer include/linux/compiler_types.h:340:27: error: expression in static assertion is not an integer include/linux/container_of.h:20:54: error: invalid use of undefined type 'struct module' include/linux/rculist.h:392:21: error: invalid use of undefined type 'struct module' include/linux/stddef.h:16:33: error: invalid use of undefined type 'struct module' kernel/bpf/../module/internal.h:205:2: error: assigning to 'struct module *' from incompatible type 'void' kernel/bpf/../module/internal.h:205:2: error: incomplete definition of type 'struct module' kernel/bpf/../module/internal.h:205:2: error: offsetof of incomplete type 'typeof (*mod)' (aka 'struct module') kernel/bpf/../module/internal.h:205:2: error: operand of type 'void' where arithmetic or pointer type is required kernel/bpf/../module/internal.h:212:2: error: operand of type 'void' where arithmetic or pointer type is required lib/dynamic_debug.c:947:6: warning: no previous prototype for function '__dynamic_ibdev_dbg' [-Wmissing-prototypes] Unverified Error/Warning (likely false positive, please contact us if interested): crypto/rng.c:206:27: warning: Value stored to 'istat' during its initialization is never read [clang-analyzer-deadcode.DeadStores] drivers/usb/host/xhci-rcar.c:239:34: warning: unused variable 'usb_xhci_of_match' [-Wunused-const-variable] drivers/watchdog/imx2_wdt.c:442:22: sparse: sparse: symbol 'imx_wdt' was not declared. Should it be static? drivers/watchdog/imx2_wdt.c:446:22: sparse: sparse: symbol 'imx_wdt_legacy' was not declared. Should it be static? include/linux/gpio/consumer.h: linux/err.h is included more than once. include/linux/gpio/driver.h: asm/bug.h is included more than once. io_uring/io_uring.c:432 io_prep_async_work() error: we previously assumed 'req->file' could be null (see line 425) io_uring/kbuf.c:221 __io_remove_buffers() warn: variable dereferenced before check 'bl->buf_ring' (see line 219) Error/Warning ids grouped by kconfigs: gcc_recent_errors |-- alpha-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:no-previous-prototype-for-link_timing_bandwidth_kbps | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-protocols-link_dp_capability.c:warning:expecting-prototype-for-Check-if-there-is-a-native-DP-or-passive-DP().-Prototype-was-for-dp_is_sink_present()-inste | `-- drivers-net-wireless-legacy-ray_cs.c:warning:strncpy-specified-bound-equals-destination-size |-- arc-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:no-previous-prototype-for-link_timing_bandwidth_kbps | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-protocols-link_dp_capability.c:warning:expe
Re: [PATCH] drm/amdgpu: Adding CAP firmware initialization
On Thu, Mar 16, 2023 at 4:36 AM Bill Liu wrote: > > Added CAP firmware initialization for PSP v13.0.10 under > psp_init_sriov_microcode > > Signed-off-by: Bill Liu Acked-by: Alex Deucher > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 1 + > drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 2 ++ > 2 files changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c > index 02f948adae72..0b9e99c35a05 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c > @@ -148,6 +148,7 @@ static int psp_init_sriov_microcode(struct psp_context > *psp) > break; > case IP_VERSION(13, 0, 10): > adev->virt.autoload_ucode_id = AMDGPU_UCODE_ID_CP_MES1_DATA; > + ret = psp_init_cap_microcode(psp, ucode_prefix); > break; > default: > return -EINVAL; > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c > index 380b89114341..b59c92037375 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c > @@ -669,6 +669,8 @@ const char *amdgpu_ucode_name(enum AMDGPU_UCODE_ID > ucode_id) > return "VCN1_RAM"; > case AMDGPU_UCODE_ID_DMCUB: > return "DMCUB"; > + case AMDGPU_UCODE_ID_CAP: > + return "CAP"; > default: > return "UNKNOWN UCODE"; > } > -- > 2.34.1 >
Re: [RFC PATCH 1/5] x86/xen: disable swiotlb for xen pvh
On Thu, Mar 16, 2023 at 7:09 PM Stefano Stabellini wrote: > > On Thu, 16 Mar 2023, Juergen Gross wrote: > > On 16.03.23 14:53, Alex Deucher wrote: > > > On Thu, Mar 16, 2023 at 9:48 AM Juergen Gross wrote: > > > > > > > > On 16.03.23 14:45, Alex Deucher wrote: > > > > > On Thu, Mar 16, 2023 at 3:50 AM Jan Beulich wrote: > > > > > > > > > > > > On 16.03.2023 00:25, Stefano Stabellini wrote: > > > > > > > On Wed, 15 Mar 2023, Jan Beulich wrote: > > > > > > > > On 15.03.2023 01:52, Stefano Stabellini wrote: > > > > > > > > > On Mon, 13 Mar 2023, Jan Beulich wrote: > > > > > > > > > > On 12.03.2023 13:01, Huang Rui wrote: > > > > > > > > > > > Xen PVH is the paravirtualized mode and takes advantage of > > > > > > > > > > > hardware > > > > > > > > > > > virtualization support when possible. It will using the > > > > > > > > > > > hardware IOMMU > > > > > > > > > > > support instead of xen-swiotlb, so disable swiotlb if > > > > > > > > > > > current domain is > > > > > > > > > > > Xen PVH. > > > > > > > > > > > > > > > > > > > > But the kernel has no way (yet) to drive the IOMMU, so how > > > > > > > > > > can > > > > > > > > > > it get > > > > > > > > > > away without resorting to swiotlb in certain cases (like I/O > > > > > > > > > > to an > > > > > > > > > > address-restricted device)? > > > > > > > > > > > > > > > > > > I think Ray meant that, thanks to the IOMMU setup by Xen, > > > > > > > > > there > > > > > > > > > is no > > > > > > > > > need for swiotlb-xen in Dom0. Address translations are done by > > > > > > > > > the IOMMU > > > > > > > > > so we can use guest physical addresses instead of machine > > > > > > > > > addresses for > > > > > > > > > DMA. This is a similar case to Dom0 on ARM when the IOMMU is > > > > > > > > > available > > > > > > > > > (see include/xen/arm/swiotlb-xen.h:xen_swiotlb_detect, the > > > > > > > > > corresponding > > > > > > > > > case is XENFEAT_not_direct_mapped). > > > > > > > > > > > > > > > > But how does Xen using an IOMMU help with, as said, > > > > > > > > address-restricted > > > > > > > > devices? They may still need e.g. a 32-bit address to be > > > > > > > > programmed in, > > > > > > > > and if the kernel has memory beyond the 4G boundary not all I/O > > > > > > > > buffers > > > > > > > > may fulfill this requirement. > > > > > > > > > > > > > > In short, it is going to work as long as Linux has guest physical > > > > > > > addresses (not machine addresses, those could be anything) lower > > > > > > > than > > > > > > > 4GB. > > > > > > > > > > > > > > If the address-restricted device does DMA via an IOMMU, then the > > > > > > > device > > > > > > > gets programmed by Linux using its guest physical addresses (not > > > > > > > machine > > > > > > > addresses). > > > > > > > > > > > > > > The 32-bit restriction would be applied by Linux to its choice of > > > > > > > guest > > > > > > > physical address to use to program the device, the same way it > > > > > > > does > > > > > > > on > > > > > > > native. The device would be fine as it always uses Linux-provided > > > > > > > <4GB > > > > > > > addresses. After the IOMMU translation (pagetable setup by Xen), > > > > > > > we > > > > > > > could get any address, including >4GB addresses, and that is > > > > > > > expected to > > > > > > > work. > > > > > > > > > > > > I understand that's the "normal" way of working. But whatever the > > > > > > swiotlb > > > > > > is used for in baremetal Linux, that would similarly require its use > > > > > > in > > > > > > PVH (or HVM) aiui. So unconditionally disabling it in PVH would look > > > > > > to > > > > > > me like an incomplete attempt to disable its use altogether on x86. > > > > > > What > > > > > > difference of PVH vs baremetal am I missing here? > > > > > > > > > > swiotlb is not usable for GPUs even on bare metal. They often have > > > > > hundreds or megs or even gigs of memory mapped on the device at any > > > > > given time. Also, AMD GPUs support 44-48 bit DMA masks (depending on > > > > > the chip family). > > > > > > > > But the swiotlb isn't per device, but system global. > > > > > > Sure, but if the swiotlb is in use, then you can't really use the GPU. > > > So you get to pick one. > > > > The swiotlb is used only for buffers which are not within the DMA mask of a > > device (see dma_direct_map_page()). So an AMD GPU supporting a 44 bit DMA > > mask > > won't use the swiotlb unless you have a buffer above guest physical address > > of > > 16TB (so basically never). > > > > Disabling swiotlb in such a guest would OTOH mean, that a device with only > > 32 bit DMA mask passed through to this guest couldn't work with buffers > > above 4GB. > > > > I don't think this is acceptable. > > From the Xen subsystem in Linux point of view, the only thing we need to > do is to make sure *not* to enable swiotlb_xen (yes "swiotlb_xen", not > the global swiotlb) on PVH because it is not needed anyway. > > I think we should leave the global "swiotlb" setti
Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI
On Fri, Mar 17, 2023 at 03:35:53PM +0200, Pekka Paalanen wrote: > On Fri, 17 Mar 2023 14:50:40 +0200 > Ville Syrjälä wrote: > > > On Fri, Mar 17, 2023 at 10:53:35AM +0200, Pekka Paalanen wrote: > > > On Fri, 17 Mar 2023 01:01:38 +0200 > > > Ville Syrjälä wrote: > > > > > > > On Thu, Mar 16, 2023 at 10:13:54PM +0100, Sebastian Wick wrote: > > > > > On Thu, Mar 16, 2023 at 1:35 PM Ville Syrjälä > > > > > wrote: > > > > > > > > > > > > On Thu, Mar 16, 2023 at 01:34:49PM +0200, Pekka Paalanen wrote: > > > > > > > On Thu, 16 Mar 2023 12:47:51 +0200 > > > > > > > Ville Syrjälä wrote: > > > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 12:07:01PM +0200, Pekka Paalanen wrote: > > > > > > > > > > > > > > > > > On Thu, 16 Mar 2023 11:50:27 +0200 > > > > > > > > > Ville Syrjälä wrote: > > > > > > > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 01:37:24AM +0100, Sebastian Wick > > > > > > > > > > wrote: > > > > > > > > > > > On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > We want compositors to be able to set the output > > > > > > > > > > > > colorspace on DP and HDMI outputs, based on the > > > > > > > > > > > > caps reported from the receiver via EDID. > > > > > > > > > > > > > > > > > > > > > > About that... The documentation says that user space has > > > > > > > > > > > to check the > > > > > > > > > > > EDID for what the sink actually supports. So whatever is > > > > > > > > > > > in > > > > > > > > > > > supported_colorspaces is just what the driver/hardware is > > > > > > > > > > > able to set > > > > > > > > > > > but doesn't actually indicate that the sink supports it. > > > > > > > > > > > > > > > > > > > > > > So the only way to enable bt2020 is by checking if the > > > > > > > > > > > sink supports > > > > > > > > > > > both RGB and YUV variants because both could be used by > > > > > > > > > > > the driver. > > > > > > > > > > > Not great at all. Something to remember for the new > > > > > > > > > > > property. > > > > > > > > > > > > > > > > > > > > Hmm. I wonder if that's even legal... Looks like maybe it > > > > > > > > > > is since I can't immediately spot anything in CTA-861 to > > > > > > > > > > forbid it :/ > > > > > > > > > > > > > > > > > > Wouldn't the driver do the same EDID check before choosing > > > > > > > > > whether it > > > > > > > > > uses RGB or YCbCr signalling? > > > > > > > > > > > > > > > > I suppose it could. The modeset would then fail, which is > > > > > > > > perhaps > > > > > > > > > > > > > > Could? What are they missing? > > > > > > > > > > > > The fact that the new property that also affects the rgb->ycbcr > > > > > > matrix > > > > > > doesn't even exist? > > > > > > > > > > I think the question was about the current Colorspace property. > > > > > > Yes. > > > > > > We need to be able to set ColourPrimaries infoframe field for the sink. > > > Only userspace knows what ColourPrimaries it uses, and the driver has > > > no need to care at all, other than tell the sink what we have. > > > > > > When a driver chooses to use YCbCr, it needs to use the > > > MatrixCoefficients the sink expects. > > > > > > If we send the infoframe to the sink telling the signal uses BT.2020 > > > ColourPrimaries, does that same bit pattern also tell the sink we are > > > using the BT.2020 NCL MatrixCoefficients if the driver chooses YCbCr? > > > > > > Do drivers actually use BT.2020 NCL MatrixCoefficients in that case? > > > > No. I think I've repeated this same line a thousand times already: > > The current colorspace property *only* affects the infoframe/msa/sdp, > > nothing else. > > That's the problem. I don't know what that means. > > Does it mean that the sink expects BT.2020 NCL MatrixCoefficients to > have been used? Yes, assuming that is the colorspace property value you picked. > > And the driver will never use BT.2020 NCL MatrixCoefficients in any > circumstances? Correct. > > See the conflict? The sink will be decoding the signal incorrectly, > because we are encoding it with the wrong MatrixCoefficients if the > driver happens to silently choose YCbCr and userspace wants to send > BT2020 ColourPrimaries indicated in the infoframe. Yes. And hence I thought pretty much everyone already agreed that a new property is needed. To make sure we actually understand what we're implementing I think it should start out very minimal. Eg just three values: - unspecified RGB + BT.601 YCbCr - unspecified RGB + BT.709 YCbCr - BT.2020 RGB + BT.2020 YCbCr NCL And that would control: - basic colorimetry metadata transmitted to the sink - MatrixCoefficients used for the potential RGB->YCbCr conversion Transfer funcs, primaries, etc. would be left out (apart from the potential metadata aspect). > > > > > > > > > If they don't, then YCbCr BT.2020 has never worked, which is another > > > nail in the coffin for "Colorspace
Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI
On 3/17/23 13:35, Pekka Paalanen wrote: On Fri, 17 Mar 2023 14:50:40 +0200 Ville Syrjälä wrote: On Fri, Mar 17, 2023 at 10:53:35AM +0200, Pekka Paalanen wrote: On Fri, 17 Mar 2023 01:01:38 +0200 Ville Syrjälä wrote: On Thu, Mar 16, 2023 at 10:13:54PM +0100, Sebastian Wick wrote: On Thu, Mar 16, 2023 at 1:35 PM Ville Syrjälä wrote: On Thu, Mar 16, 2023 at 01:34:49PM +0200, Pekka Paalanen wrote: On Thu, 16 Mar 2023 12:47:51 +0200 Ville Syrjälä wrote: On Thu, Mar 16, 2023 at 12:07:01PM +0200, Pekka Paalanen wrote: On Thu, 16 Mar 2023 11:50:27 +0200 Ville Syrjälä wrote: On Thu, Mar 16, 2023 at 01:37:24AM +0100, Sebastian Wick wrote: On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland wrote: We want compositors to be able to set the output colorspace on DP and HDMI outputs, based on the caps reported from the receiver via EDID. About that... The documentation says that user space has to check the EDID for what the sink actually supports. So whatever is in supported_colorspaces is just what the driver/hardware is able to set but doesn't actually indicate that the sink supports it. So the only way to enable bt2020 is by checking if the sink supports both RGB and YUV variants because both could be used by the driver. Not great at all. Something to remember for the new property. Hmm. I wonder if that's even legal... Looks like maybe it is since I can't immediately spot anything in CTA-861 to forbid it :/ Wouldn't the driver do the same EDID check before choosing whether it uses RGB or YCbCr signalling? I suppose it could. The modeset would then fail, which is perhaps Could? What are they missing? The fact that the new property that also affects the rgb->ycbcr matrix doesn't even exist? I think the question was about the current Colorspace property. Yes. We need to be able to set ColourPrimaries infoframe field for the sink. Only userspace knows what ColourPrimaries it uses, and the driver has no need to care at all, other than tell the sink what we have. When a driver chooses to use YCbCr, it needs to use the MatrixCoefficients the sink expects. If we send the infoframe to the sink telling the signal uses BT.2020 ColourPrimaries, does that same bit pattern also tell the sink we are using the BT.2020 NCL MatrixCoefficients if the driver chooses YCbCr? Do drivers actually use BT.2020 NCL MatrixCoefficients in that case? No. I think I've repeated this same line a thousand times already: The current colorspace property *only* affects the infoframe/msa/sdp, nothing else. No, sorry, this is completely nonsensical. Even with the current Colorspace property that we want to deprecate, drivers doing an implicit conversion from RGB -> to YCC should respect the colorspace property to pick the right matrix coefficients here. Doing so simply introduces a useless mismatch that is unavoidable from userspace and makes absolutely no sense. Arguing about this is kind of completely useless anyway... as we are deprecating this property... Let's plase let it die. I am not sure why these patches were re-submitted with my RB again after we had the discussion previously about making a new one that's actually going to get tested and have userspace consumers. (FTR, I guess Gamescope *is* a userspace consumer for this broken property right now, but I am completely happy for AMDGPU upstream to never support this and to just move onto the new property and leave this one behind). That's the problem. I don't know what that means. Does it mean that the sink expects BT.2020 NCL MatrixCoefficients to have been used? Yes. And the driver will never use BT.2020 NCL MatrixCoefficients in any circumstances? That is what Ville is describing and what I disagree with, yes. But whether or not Ville or I agree on that is kind of irrelevant as we are going to deprecate the property... right... right? See the conflict? The sink will be decoding the signal incorrectly, because we are encoding it with the wrong MatrixCoefficients if the driver happens to silently choose YCbCr and userspace wants to send BT2020 ColourPrimaries indicated in the infoframe. Yeah. - Joshie 🐸✨ If they don't, then YCbCr BT.2020 has never worked, which is another nail in the coffin for "Colorspace" property. That is the same nail we've been talking about all along I thought. But it still means that RGB BT.2020 may have worked correctly, and then drivers would regress if they started picking YCbCr for any reason where they previously used RGB. The policy has been to use RGB if at all possible. Only falling back to YCbCr 4:2:0 if absolutely necessary (eg. EDID says 4:2:0 must be used, or there's not enough bandwidth for 4:4:4, etc.). If the behaviour suddenly changes then it probably means the driver was doing something illegal before by using RGB 4:4:4. Ok. I mean, drivers are already automatically choosing between RGB and YCbCr signalling based on e.g. available bandwidt
Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI
On Fri, 17 Mar 2023 14:50:40 +0200 Ville Syrjälä wrote: > On Fri, Mar 17, 2023 at 10:53:35AM +0200, Pekka Paalanen wrote: > > On Fri, 17 Mar 2023 01:01:38 +0200 > > Ville Syrjälä wrote: > > > > > On Thu, Mar 16, 2023 at 10:13:54PM +0100, Sebastian Wick wrote: > > > > On Thu, Mar 16, 2023 at 1:35 PM Ville Syrjälä > > > > wrote: > > > > > > > > > > On Thu, Mar 16, 2023 at 01:34:49PM +0200, Pekka Paalanen wrote: > > > > > > On Thu, 16 Mar 2023 12:47:51 +0200 > > > > > > Ville Syrjälä wrote: > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 12:07:01PM +0200, Pekka Paalanen wrote: > > > > > > > > > > > > > > > On Thu, 16 Mar 2023 11:50:27 +0200 > > > > > > > > Ville Syrjälä wrote: > > > > > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 01:37:24AM +0100, Sebastian Wick > > > > > > > > > wrote: > > > > > > > > > > On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > We want compositors to be able to set the output > > > > > > > > > > > colorspace on DP and HDMI outputs, based on the > > > > > > > > > > > caps reported from the receiver via EDID. > > > > > > > > > > > > > > > > > > > > About that... The documentation says that user space has to > > > > > > > > > > check the > > > > > > > > > > EDID for what the sink actually supports. So whatever is in > > > > > > > > > > supported_colorspaces is just what the driver/hardware is > > > > > > > > > > able to set > > > > > > > > > > but doesn't actually indicate that the sink supports it. > > > > > > > > > > > > > > > > > > > > So the only way to enable bt2020 is by checking if the sink > > > > > > > > > > supports > > > > > > > > > > both RGB and YUV variants because both could be used by the > > > > > > > > > > driver. > > > > > > > > > > Not great at all. Something to remember for the new > > > > > > > > > > property. > > > > > > > > > > > > > > > > > > Hmm. I wonder if that's even legal... Looks like maybe it > > > > > > > > > is since I can't immediately spot anything in CTA-861 to > > > > > > > > > forbid it :/ > > > > > > > > > > > > > > > > Wouldn't the driver do the same EDID check before choosing > > > > > > > > whether it > > > > > > > > uses RGB or YCbCr signalling? > > > > > > > > > > > > > > I suppose it could. The modeset would then fail, which is perhaps > > > > > > > > > > > > > > > > > > > Could? What are they missing? > > > > > > > > > > The fact that the new property that also affects the rgb->ycbcr matrix > > > > > doesn't even exist? > > > > > > > > I think the question was about the current Colorspace property. > > > > Yes. > > > > We need to be able to set ColourPrimaries infoframe field for the sink. > > Only userspace knows what ColourPrimaries it uses, and the driver has > > no need to care at all, other than tell the sink what we have. > > > > When a driver chooses to use YCbCr, it needs to use the > > MatrixCoefficients the sink expects. > > > > If we send the infoframe to the sink telling the signal uses BT.2020 > > ColourPrimaries, does that same bit pattern also tell the sink we are > > using the BT.2020 NCL MatrixCoefficients if the driver chooses YCbCr? > > > > Do drivers actually use BT.2020 NCL MatrixCoefficients in that case? > > No. I think I've repeated this same line a thousand times already: > The current colorspace property *only* affects the infoframe/msa/sdp, > nothing else. That's the problem. I don't know what that means. Does it mean that the sink expects BT.2020 NCL MatrixCoefficients to have been used? And the driver will never use BT.2020 NCL MatrixCoefficients in any circumstances? See the conflict? The sink will be decoding the signal incorrectly, because we are encoding it with the wrong MatrixCoefficients if the driver happens to silently choose YCbCr and userspace wants to send BT2020 ColourPrimaries indicated in the infoframe. > > > > > If they don't, then YCbCr BT.2020 has never worked, which is another > > nail in the coffin for "Colorspace" property. > > That is the same nail we've been talking about all along I thought. > > > But it still means that > > RGB BT.2020 may have worked correctly, and then drivers would regress > > if they started picking YCbCr for any reason where they previously used > > RGB. > > The policy has been to use RGB if at all possible. Only falling back > to YCbCr 4:2:0 if absolutely necessary (eg. EDID says 4:2:0 must > be used, or there's not enough bandwidth for 4:4:4, etc.). If the > behaviour suddenly changes then it probably means the driver was > doing something illegal before by using RGB 4:4:4. Ok. > > > > > > > > > > > > I mean, drivers are already automatically choosing between RGB and > > > > > > YCbCr > > > > > > signalling based on e.g. available bandwidth. Surely they already > > > > > > will > > > > > > not attempt to send a signal format to a monitor that does not say > > > > > > it > > > > > > su
Re: [RFC PATCH 1/5] x86/xen: disable swiotlb for xen pvh
On Thu, Mar 16, 2023 at 04:09:44PM -0700, Stefano Stabellini wrote: > On Thu, 16 Mar 2023, Juergen Gross wrote: > > On 16.03.23 14:53, Alex Deucher wrote: > > > On Thu, Mar 16, 2023 at 9:48 AM Juergen Gross wrote: > > > > > > > > On 16.03.23 14:45, Alex Deucher wrote: > > > > > On Thu, Mar 16, 2023 at 3:50 AM Jan Beulich wrote: > > > > > > > > > > > > On 16.03.2023 00:25, Stefano Stabellini wrote: > > > > > > > On Wed, 15 Mar 2023, Jan Beulich wrote: > > > > > > > > On 15.03.2023 01:52, Stefano Stabellini wrote: > > > > > > > > > On Mon, 13 Mar 2023, Jan Beulich wrote: > > > > > > > > > > On 12.03.2023 13:01, Huang Rui wrote: > > > > > > > > > > > Xen PVH is the paravirtualized mode and takes advantage of > > > > > > > > > > > hardware > > > > > > > > > > > virtualization support when possible. It will using the > > > > > > > > > > > hardware IOMMU > > > > > > > > > > > support instead of xen-swiotlb, so disable swiotlb if > > > > > > > > > > > current domain is > > > > > > > > > > > Xen PVH. > > > > > > > > > > > > > > > > > > > > But the kernel has no way (yet) to drive the IOMMU, so how > > > > > > > > > > can > > > > > > > > > > it get > > > > > > > > > > away without resorting to swiotlb in certain cases (like I/O > > > > > > > > > > to an > > > > > > > > > > address-restricted device)? > > > > > > > > > > > > > > > > > > I think Ray meant that, thanks to the IOMMU setup by Xen, > > > > > > > > > there > > > > > > > > > is no > > > > > > > > > need for swiotlb-xen in Dom0. Address translations are done by > > > > > > > > > the IOMMU > > > > > > > > > so we can use guest physical addresses instead of machine > > > > > > > > > addresses for > > > > > > > > > DMA. This is a similar case to Dom0 on ARM when the IOMMU is > > > > > > > > > available > > > > > > > > > (see include/xen/arm/swiotlb-xen.h:xen_swiotlb_detect, the > > > > > > > > > corresponding > > > > > > > > > case is XENFEAT_not_direct_mapped). > > > > > > > > > > > > > > > > But how does Xen using an IOMMU help with, as said, > > > > > > > > address-restricted > > > > > > > > devices? They may still need e.g. a 32-bit address to be > > > > > > > > programmed in, > > > > > > > > and if the kernel has memory beyond the 4G boundary not all I/O > > > > > > > > buffers > > > > > > > > may fulfill this requirement. > > > > > > > > > > > > > > In short, it is going to work as long as Linux has guest physical > > > > > > > addresses (not machine addresses, those could be anything) lower > > > > > > > than > > > > > > > 4GB. > > > > > > > > > > > > > > If the address-restricted device does DMA via an IOMMU, then the > > > > > > > device > > > > > > > gets programmed by Linux using its guest physical addresses (not > > > > > > > machine > > > > > > > addresses). > > > > > > > > > > > > > > The 32-bit restriction would be applied by Linux to its choice of > > > > > > > guest > > > > > > > physical address to use to program the device, the same way it > > > > > > > does > > > > > > > on > > > > > > > native. The device would be fine as it always uses Linux-provided > > > > > > > <4GB > > > > > > > addresses. After the IOMMU translation (pagetable setup by Xen), > > > > > > > we > > > > > > > could get any address, including >4GB addresses, and that is > > > > > > > expected to > > > > > > > work. > > > > > > > > > > > > I understand that's the "normal" way of working. But whatever the > > > > > > swiotlb > > > > > > is used for in baremetal Linux, that would similarly require its use > > > > > > in > > > > > > PVH (or HVM) aiui. So unconditionally disabling it in PVH would look > > > > > > to > > > > > > me like an incomplete attempt to disable its use altogether on x86. > > > > > > What > > > > > > difference of PVH vs baremetal am I missing here? > > > > > > > > > > swiotlb is not usable for GPUs even on bare metal. They often have > > > > > hundreds or megs or even gigs of memory mapped on the device at any > > > > > given time. Also, AMD GPUs support 44-48 bit DMA masks (depending on > > > > > the chip family). > > > > > > > > But the swiotlb isn't per device, but system global. > > > > > > Sure, but if the swiotlb is in use, then you can't really use the GPU. > > > So you get to pick one. > > > > The swiotlb is used only for buffers which are not within the DMA mask of a > > device (see dma_direct_map_page()). So an AMD GPU supporting a 44 bit DMA > > mask > > won't use the swiotlb unless you have a buffer above guest physical address > > of > > 16TB (so basically never). > > > > Disabling swiotlb in such a guest would OTOH mean, that a device with only > > 32 bit DMA mask passed through to this guest couldn't work with buffers > > above 4GB. > > > > I don't think this is acceptable. > > From the Xen subsystem in Linux point of view, the only thing we need to > do is to make sure *not* to enable swiotlb_xen (yes "swiotlb_xen", not > the global swiotlb) on PVH because it is not needed anyway. But this is already the case o
Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI
On Fri, Mar 17, 2023 at 10:53:35AM +0200, Pekka Paalanen wrote: > On Fri, 17 Mar 2023 01:01:38 +0200 > Ville Syrjälä wrote: > > > On Thu, Mar 16, 2023 at 10:13:54PM +0100, Sebastian Wick wrote: > > > On Thu, Mar 16, 2023 at 1:35 PM Ville Syrjälä > > > wrote: > > > > > > > > On Thu, Mar 16, 2023 at 01:34:49PM +0200, Pekka Paalanen wrote: > > > > > On Thu, 16 Mar 2023 12:47:51 +0200 > > > > > Ville Syrjälä wrote: > > > > > > > > > > > On Thu, Mar 16, 2023 at 12:07:01PM +0200, Pekka Paalanen wrote: > > > > > > > On Thu, 16 Mar 2023 11:50:27 +0200 > > > > > > > Ville Syrjälä wrote: > > > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 01:37:24AM +0100, Sebastian Wick wrote: > > > > > > > > > > > > > > > > > On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > We want compositors to be able to set the output > > > > > > > > > > colorspace on DP and HDMI outputs, based on the > > > > > > > > > > caps reported from the receiver via EDID. > > > > > > > > > > > > > > > > > > About that... The documentation says that user space has to > > > > > > > > > check the > > > > > > > > > EDID for what the sink actually supports. So whatever is in > > > > > > > > > supported_colorspaces is just what the driver/hardware is > > > > > > > > > able to set > > > > > > > > > but doesn't actually indicate that the sink supports it. > > > > > > > > > > > > > > > > > > So the only way to enable bt2020 is by checking if the sink > > > > > > > > > supports > > > > > > > > > both RGB and YUV variants because both could be used by the > > > > > > > > > driver. > > > > > > > > > Not great at all. Something to remember for the new property. > > > > > > > > > > > > > > > > > > > > > > > > > Hmm. I wonder if that's even legal... Looks like maybe it > > > > > > > > is since I can't immediately spot anything in CTA-861 to > > > > > > > > forbid it :/ > > > > > > > > > > > > > > Wouldn't the driver do the same EDID check before choosing > > > > > > > whether it > > > > > > > uses RGB or YCbCr signalling? > > > > > > > > > > > > I suppose it could. The modeset would then fail, which is perhaps > > > > > > > > > > Could? What are they missing? > > > > > > > > The fact that the new property that also affects the rgb->ycbcr matrix > > > > doesn't even exist? > > > > > > I think the question was about the current Colorspace property. > > Yes. > > We need to be able to set ColourPrimaries infoframe field for the sink. > Only userspace knows what ColourPrimaries it uses, and the driver has > no need to care at all, other than tell the sink what we have. > > When a driver chooses to use YCbCr, it needs to use the > MatrixCoefficients the sink expects. > > If we send the infoframe to the sink telling the signal uses BT.2020 > ColourPrimaries, does that same bit pattern also tell the sink we are > using the BT.2020 NCL MatrixCoefficients if the driver chooses YCbCr? > > Do drivers actually use BT.2020 NCL MatrixCoefficients in that case? No. I think I've repeated this same line a thousand times already: The current colorspace property *only* affects the infoframe/msa/sdp, nothing else. > > If they don't, then YCbCr BT.2020 has never worked, which is another > nail in the coffin for "Colorspace" property. That is the same nail we've been talking about all along I thought. > But it still means that > RGB BT.2020 may have worked correctly, and then drivers would regress > if they started picking YCbCr for any reason where they previously used > RGB. The policy has been to use RGB if at all possible. Only falling back to YCbCr 4:2:0 if absolutely necessary (eg. EDID says 4:2:0 must be used, or there's not enough bandwidth for 4:4:4, etc.). If the behaviour suddenly changes then it probably means the driver was doing something illegal before by using RGB 4:4:4. > > > > > > > > > > > I mean, drivers are already automatically choosing between RGB and > > > > > YCbCr > > > > > signalling based on e.g. available bandwidth. Surely they already will > > > > > not attempt to send a signal format to a monitor that does not say it > > > > > supports that? > > > > > > That's exactly what they do. The drivers don't check the EDID for the > > > colorimetry the sink supports and the responsibility is punted off to > > > user space. > > I suspect there are two different things: > > - which of RGB, YCbCr 4:4:4, YCbCr 4:2:0 can the sink take > - the supported MatrixCoefficients for each of the YCbCr > > Surely drivers are already checking the former point? Yes. > > I'm not surprised if they are not checking the latter point, but they > do need to, because it is the driver making the choice between RGB and > some YCbCr. This point has been irrelevant since we always select BT.709 and there is no optional feature bit in EDID to check for that. Presumaly it is mandatory for sinks to support both BT.601 and BT.709 whenever they support YCbCr in general. >
RE: [PATCH] drm/amdgpu: Adding CAP firmware initialization
[AMD Official Use Only - General] Reviewed-by: Monk Liu Thanks --- Monk Liu | Cloud GPU & Virtualization Software | AMD --- -Original Message- From: amd-gfx On Behalf Of Bill Liu Sent: 2023年3月16日 16:36 To: amd-gfx@lists.freedesktop.org; Deucher, Alexander ; Zhang, Hawking Cc: Chen, Horace ; Liu, Bill ; Chang, HaiJun Subject: [PATCH] drm/amdgpu: Adding CAP firmware initialization Added CAP firmware initialization for PSP v13.0.10 under psp_init_sriov_microcode Signed-off-by: Bill Liu --- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 2 ++ 2 files changed, 3 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c index 02f948adae72..0b9e99c35a05 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c @@ -148,6 +148,7 @@ static int psp_init_sriov_microcode(struct psp_context *psp) break; case IP_VERSION(13, 0, 10): adev->virt.autoload_ucode_id = AMDGPU_UCODE_ID_CP_MES1_DATA; + ret = psp_init_cap_microcode(psp, ucode_prefix); break; default: return -EINVAL; diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c index 380b89114341..b59c92037375 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c @@ -669,6 +669,8 @@ const char *amdgpu_ucode_name(enum AMDGPU_UCODE_ID ucode_id) return "VCN1_RAM"; case AMDGPU_UCODE_ID_DMCUB: return "DMCUB"; + case AMDGPU_UCODE_ID_CAP: + return "CAP"; default: return "UNKNOWN UCODE"; } -- 2.34.1
Re: [PATCH 00/10] drm/radeon: Convert fbdev to DRM client
Hi Christian Am 17.03.23 um 09:53 schrieb Christian König: Am 16.03.23 um 10:37 schrieb Thomas Zimmermann: Convert radeon's fbdev code to drm_client. Replaces the current ad-hoc integration. The conversion includes a number of cleanups. Only build fbdev support if the config option has been set. I'm torn apart on that. On the one hand it looks like a really nice cleanup on the other hand we don't really want to touch radeon any more. It's a driver in the upstream kernel. You have to expect at least some changes. Alex what do you think? Is that worth the risk of breaking stuff? Moving all fbdev emulation to struct drm_client is required for new in-kernel DRM clients, such as a DRM kernel logger or a boot splash. Best regards Thomas Christian. Thomas Zimmermann (10): drm/radeon: Move radeon_align_pitch() next to dumb-buffer helpers drm/radeon: Improve fbdev object-test helper drm/radeon: Remove struct radeon_fbdev drm/radeon: Remove test for !screen_base in fbdev probing drm/radeon: Move fbdev object helpers before struct fb_ops et al drm/radeon: Fix coding style in fbdev emulation drm/radeon: Move fbdev cleanup code into fb_destroy callback drm/radeon: Correctly clean up failed display probing drm/radeon: Implement client-based fbdev emulation drm/radeon: Only build fbdev if DRM_FBDEV_EMULATION is set drivers/gpu/drm/radeon/Makefile | 3 +- drivers/gpu/drm/radeon/radeon.h | 2 + drivers/gpu/drm/radeon/radeon_display.c | 4 - drivers/gpu/drm/radeon/radeon_drv.c | 3 +- drivers/gpu/drm/radeon/radeon_drv.h | 1 - drivers/gpu/drm/radeon/radeon_fb.c | 400 -- drivers/gpu/drm/radeon/radeon_fbdev.c | 422 drivers/gpu/drm/radeon/radeon_gem.c | 24 ++ drivers/gpu/drm/radeon/radeon_kms.c | 18 - drivers/gpu/drm/radeon/radeon_mode.h | 20 +- 10 files changed, 464 insertions(+), 433 deletions(-) delete mode 100644 drivers/gpu/drm/radeon/radeon_fb.c create mode 100644 drivers/gpu/drm/radeon/radeon_fbdev.c base-commit: ec0708e846b819c8d5b642de42448a87d7526564 -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI
On Fri, 17 Mar 2023 01:01:38 +0200 Ville Syrjälä wrote: > On Thu, Mar 16, 2023 at 10:13:54PM +0100, Sebastian Wick wrote: > > On Thu, Mar 16, 2023 at 1:35 PM Ville Syrjälä > > wrote: > > > > > > On Thu, Mar 16, 2023 at 01:34:49PM +0200, Pekka Paalanen wrote: > > > > On Thu, 16 Mar 2023 12:47:51 +0200 > > > > Ville Syrjälä wrote: > > > > > > > > > On Thu, Mar 16, 2023 at 12:07:01PM +0200, Pekka Paalanen wrote: > > > > > > On Thu, 16 Mar 2023 11:50:27 +0200 > > > > > > Ville Syrjälä wrote: > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 01:37:24AM +0100, Sebastian Wick wrote: > > > > > > > > On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > We want compositors to be able to set the output > > > > > > > > > colorspace on DP and HDMI outputs, based on the > > > > > > > > > caps reported from the receiver via EDID. > > > > > > > > > > > > > > > > About that... The documentation says that user space has to > > > > > > > > check the > > > > > > > > EDID for what the sink actually supports. So whatever is in > > > > > > > > supported_colorspaces is just what the driver/hardware is able > > > > > > > > to set > > > > > > > > but doesn't actually indicate that the sink supports it. > > > > > > > > > > > > > > > > So the only way to enable bt2020 is by checking if the sink > > > > > > > > supports > > > > > > > > both RGB and YUV variants because both could be used by the > > > > > > > > driver. > > > > > > > > Not great at all. Something to remember for the new property. > > > > > > > > > > > > > > Hmm. I wonder if that's even legal... Looks like maybe it > > > > > > > is since I can't immediately spot anything in CTA-861 to > > > > > > > forbid it :/ > > > > > > > > > > > > Wouldn't the driver do the same EDID check before choosing whether > > > > > > it > > > > > > uses RGB or YCbCr signalling? > > > > > > > > > > I suppose it could. The modeset would then fail, which is perhaps > > > > > > > > Could? What are they missing? > > > > > > The fact that the new property that also affects the rgb->ycbcr matrix > > > doesn't even exist? > > > > I think the question was about the current Colorspace property. Yes. We need to be able to set ColourPrimaries infoframe field for the sink. Only userspace knows what ColourPrimaries it uses, and the driver has no need to care at all, other than tell the sink what we have. When a driver chooses to use YCbCr, it needs to use the MatrixCoefficients the sink expects. If we send the infoframe to the sink telling the signal uses BT.2020 ColourPrimaries, does that same bit pattern also tell the sink we are using the BT.2020 NCL MatrixCoefficients if the driver chooses YCbCr? Do drivers actually use BT.2020 NCL MatrixCoefficients in that case? If they don't, then YCbCr BT.2020 has never worked, which is another nail in the coffin for "Colorspace" property. But it still means that RGB BT.2020 may have worked correctly, and then drivers would regress if they started picking YCbCr for any reason where they previously used RGB. > > > > > > > > I mean, drivers are already automatically choosing between RGB and YCbCr > > > > signalling based on e.g. available bandwidth. Surely they already will > > > > not attempt to send a signal format to a monitor that does not say it > > > > supports that? > > > > That's exactly what they do. The drivers don't check the EDID for the > > colorimetry the sink supports and the responsibility is punted off to > > user space. I suspect there are two different things: - which of RGB, YCbCr 4:4:4, YCbCr 4:2:0 can the sink take - the supported MatrixCoefficients for each of the YCbCr Surely drivers are already checking the former point? I'm not surprised if they are not checking the latter point, but they do need to, because it is the driver making the choice between RGB and some YCbCr. > > > > > > We just signal default/bt.709 colorimetry. There is nothing to > > > check for those IIRC. > > > > You do support bt.2020, no? > > Not for rgb->ycbcr conversion. I see there is confusion about what "colorimetry" is. Please, let's use the H.273 terminology to make the difference clear between ColourPrimaries and MatrixCoefficients. Thanks, pq pgpB0WCZg0lPt.pgp Description: OpenPGP digital signature
Re: [PATCH 00/10] drm/radeon: Convert fbdev to DRM client
Am 16.03.23 um 10:37 schrieb Thomas Zimmermann: Convert radeon's fbdev code to drm_client. Replaces the current ad-hoc integration. The conversion includes a number of cleanups. Only build fbdev support if the config option has been set. I'm torn apart on that. On the one hand it looks like a really nice cleanup on the other hand we don't really want to touch radeon any more. Alex what do you think? Is that worth the risk of breaking stuff? Christian. Thomas Zimmermann (10): drm/radeon: Move radeon_align_pitch() next to dumb-buffer helpers drm/radeon: Improve fbdev object-test helper drm/radeon: Remove struct radeon_fbdev drm/radeon: Remove test for !screen_base in fbdev probing drm/radeon: Move fbdev object helpers before struct fb_ops et al drm/radeon: Fix coding style in fbdev emulation drm/radeon: Move fbdev cleanup code into fb_destroy callback drm/radeon: Correctly clean up failed display probing drm/radeon: Implement client-based fbdev emulation drm/radeon: Only build fbdev if DRM_FBDEV_EMULATION is set drivers/gpu/drm/radeon/Makefile | 3 +- drivers/gpu/drm/radeon/radeon.h | 2 + drivers/gpu/drm/radeon/radeon_display.c | 4 - drivers/gpu/drm/radeon/radeon_drv.c | 3 +- drivers/gpu/drm/radeon/radeon_drv.h | 1 - drivers/gpu/drm/radeon/radeon_fb.c | 400 -- drivers/gpu/drm/radeon/radeon_fbdev.c | 422 drivers/gpu/drm/radeon/radeon_gem.c | 24 ++ drivers/gpu/drm/radeon/radeon_kms.c | 18 - drivers/gpu/drm/radeon/radeon_mode.h| 20 +- 10 files changed, 464 insertions(+), 433 deletions(-) delete mode 100644 drivers/gpu/drm/radeon/radeon_fb.c create mode 100644 drivers/gpu/drm/radeon/radeon_fbdev.c base-commit: ec0708e846b819c8d5b642de42448a87d7526564
[PATCH 36/37] drm/amd/display/dc/link/link_detection: Demote a couple of kerneldoc abuses
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_detection.c:877: warning: Function parameter or member 'link' not described in 'detect_link_and_local_sink' drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_detection.c:877: warning: Function parameter or member 'reason' not described in 'detect_link_and_local_sink' drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_detection.c:1232: warning: Function parameter or member 'link' not described in 'dc_link_detect_connection_type' Cc: Harry Wentland Cc: Leo Li Cc: Rodrigo Siqueira Cc: Alex Deucher Cc: "Christian König" Cc: "Pan, Xinhui" Cc: David Airlie Cc: Daniel Vetter Cc: Lee Jones Cc: Wenjing Liu Cc: amd-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/amd/display/dc/link/link_detection.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/link/link_detection.c b/drivers/gpu/drm/amd/display/dc/link/link_detection.c index 9a4cfa777622e..67addedd89563 100644 --- a/drivers/gpu/drm/amd/display/dc/link/link_detection.c +++ b/drivers/gpu/drm/amd/display/dc/link/link_detection.c @@ -832,7 +832,7 @@ static void verify_link_capability(struct dc_link *link, struct dc_sink *sink, verify_link_capability_non_destructive(link); } -/** +/* * detect_link_and_local_sink() - Detect if a sink is attached to a given link * * link->local_sink is created or destroyed as needed. @@ -1185,7 +1185,7 @@ static bool detect_link_and_local_sink(struct dc_link *link, return true; } -/** +/* * link_detect_connection_type() - Determine if there is a sink connected * * @type: Returned connection type -- 2.40.0.rc1.284.g88254d51c5-goog
[PATCH 35/37] drm/amd/display/dc/dce60/Makefile: Fix previous attempt to silence known override-init warnings
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:157:21: note:
in expansion of macro ‘mmCRTC1_DCFE_MEM_LIGHT_SLEEP_CNTL’
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_transform.h:170:9: note: in
expansion of macro ‘SRI’
drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:183:17: note:
in expansion of macro ‘XFM_COMMON_REG_LIST_DCE60’
drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:188:17: note:
in expansion of macro ‘transform_regs’
drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_6_0_d.h:722:43:
warning: initialized field overwritten [-Woverride-init]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:157:21: note:
in expansion of macro ‘mmCRTC2_DCFE_MEM_LIGHT_SLEEP_CNTL’
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_transform.h:170:9: note: in
expansion of macro ‘SRI’
drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:183:17: note:
in expansion of macro ‘XFM_COMMON_REG_LIST_DCE60’
drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:189:17: note:
in expansion of macro ‘transform_regs’
drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_6_0_d.h:722:43: note:
(near initialization for ‘xfm_regs[2].DCFE_MEM_LIGHT_SLEEP_CN
[100 lines snipped for brevity]
Fixes: ceb3cf476a441 ("drm/amd/display/dc/dce60/Makefile: Ignore
-Woverride-init warning")
Cc: Harry Wentland
Cc: Leo Li
Cc: Rodrigo Siqueira
Cc: Alex Deucher
Cc: "Christian König"
Cc: "Pan, Xinhui"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Mauro Rossi
Cc: amd-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/amd/display/dc/dce60/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dce60/Makefile
b/drivers/gpu/drm/amd/display/dc/dce60/Makefile
index dda596fa1cd76..fee331accc0e7 100644
--- a/drivers/gpu/drm/amd/display/dc/dce60/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dce60/Makefile
@@ -23,7 +23,7 @@
# Makefile for the 'controller' sub-component of DAL.
# It provides the control and status of HW CRTC block.
-CFLAGS_AMDDALPATH)/dc/dce60/dce60_resource.o = $(call cc-disable-warning,
override-init)
+CFLAGS_$(AMDDALPATH)/dc/dce60/dce60_resource.o = $(call cc-disable-warning,
override-init)
DCE60 = dce60_timing_generator.o dce60_hw_sequencer.o \
dce60_resource.o
--
2.40.0.rc1.284.g88254d51c5-goog
[PATCH 33/37] drm/amd/display/dc/link/protocols/link_dp_capability: Demote non-compliant kerneldoc
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_capability.c:2190: warning: Function parameter or member 'link' not described in 'dc_link_is_dp_sink_present' Cc: Harry Wentland Cc: Leo Li Cc: Rodrigo Siqueira Cc: Alex Deucher Cc: "Christian König" Cc: "Pan, Xinhui" Cc: David Airlie Cc: Daniel Vetter Cc: amd-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones --- .../gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 51427f5081642..2a2443535b676 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 @@ -2177,7 +2177,7 @@ bool dp_verify_link_cap_with_retries( return success; } -/** +/* * Check if there is a native DP or passive DP-HDMI dongle connected */ bool dp_is_sink_present(struct dc_link *link) -- 2.40.0.rc1.284.g88254d51c5-goog
[PATCH 32/37] drm/amd/display/dc/link/protocols/link_dp_capability: Remove unused variable and mark another as __maybe_unused
‘ds_port’ is clearly not used anywhere and ‘result_write_min_hblank’ is
only utilised when debugging is enabled. The alternative would be to
allocate the variable under the same clause as the debugging code, but
that would become very messy, very quickly.
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_capability.c:
In function ‘dp_wa_power_up_0010FA’:
drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_capability.c:280:42:
warning: variable ‘ds_port’ set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_capability.c:
In function ‘dpcd_set_source_specific_data’:
drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_capability.c:1296:32:
warning: variable ‘result_write_min_hblank’ set but not used
[-Wunused-but-set-variable]
Cc: Harry Wentland
Cc: Leo Li
Cc: Rodrigo Siqueira
Cc: Alex Deucher
Cc: "Christian König"
Cc: "Pan, Xinhui"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Wenjing Liu
Cc: amd-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
.../gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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 e9bcb35ae185a..51427f5081642 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
@@ -1284,7 +1284,7 @@ bool dp_overwrite_extended_receiver_cap(struct dc_link
*link)
void dpcd_set_source_specific_data(struct dc_link *link)
{
if (!link->dc->vendor_signature.is_valid) {
- enum dc_status result_write_min_hblank = DC_NOT_SUPPORTED;
+ enum dc_status __maybe_unused result_write_min_hblank =
DC_NOT_SUPPORTED;
struct dpcd_amd_signature amd_signature = {0};
struct dpcd_amd_device_id amd_device_id = {0};
--
2.40.0.rc1.284.g88254d51c5-goog
[PATCH 29/37] drm/amd/display/dc/link/link_detection: Remove unused variable 'status'
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_detection.c: In function
‘query_hdcp_capability’:
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_detection.c:501:42:
warning: variable ‘status’ set but not used [-Wunused-but-set-variable]
Cc: Harry Wentland
Cc: Leo Li
Cc: Rodrigo Siqueira
Cc: Alex Deucher
Cc: "Christian König"
Cc: "Pan, Xinhui"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Wenjing Liu
Cc: amd-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/amd/display/dc/link/link_detection.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/link/link_detection.c
b/drivers/gpu/drm/amd/display/dc/link/link_detection.c
index 9177b146a80a8..9a4cfa777622e 100644
--- a/drivers/gpu/drm/amd/display/dc/link/link_detection.c
+++ b/drivers/gpu/drm/amd/display/dc/link/link_detection.c
@@ -498,8 +498,6 @@ static void query_hdcp_capability(enum signal_type signal,
struct dc_link *link)
dc_process_hdcp_msg(signal, link, &msg22);
if (signal == SIGNAL_TYPE_DISPLAY_PORT || signal ==
SIGNAL_TYPE_DISPLAY_PORT_MST) {
- enum hdcp_message_status status = HDCP_MESSAGE_UNSUPPORTED;
-
msg14.data = &link->hdcp_caps.bcaps.raw;
msg14.length = sizeof(link->hdcp_caps.bcaps.raw);
msg14.msg_id = HDCP_MESSAGE_ID_READ_BCAPS;
@@ -507,7 +505,7 @@ static void query_hdcp_capability(enum signal_type signal,
struct dc_link *link)
msg14.link = HDCP_LINK_PRIMARY;
msg14.max_retries = 5;
- status = dc_process_hdcp_msg(signal, link, &msg14);
+ dc_process_hdcp_msg(signal, link, &msg14);
}
}
--
2.40.0.rc1.284.g88254d51c5-goog
[PATCH 30/37] drm/amd/display/dc/link/protocols/link_dp_training: Remove set but unused variable 'result'
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_training.c: In function ‘perform_link_training_with_retries’: drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_training.c:1586:38: warning: variable ‘result’ set but not used [-Wunused-but-set-variable] Cc: Harry Wentland Cc: Leo Li Cc: Rodrigo Siqueira Cc: Alex Deucher Cc: "Christian König" Cc: "Pan, Xinhui" Cc: David Airlie Cc: Daniel Vetter Cc: Wenjing Liu Cc: amd-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones --- .../gpu/drm/amd/display/dc/link/protocols/link_dp_training.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_training.c b/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_training.c index a9025671ee4a8..10261764a0cea 100644 --- a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_training.c +++ b/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_training.c @@ -1580,8 +1580,7 @@ bool perform_link_training_with_retries( * Report and continue with eDP panel mode to * perform eDP link training with right settings */ - bool result; - result = cp_psp->funcs.enable_assr(cp_psp->handle, link); + cp_psp->funcs.enable_assr(cp_psp->handle, link); } } -- 2.40.0.rc1.284.g88254d51c5-goog
[PATCH 28/37] drm/amd/display/dc/core/dc_stat: Convert a couple of doc headers to kerneldoc format
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stat.c:38: warning: Cannot
understand
*
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stat.c:76: warning: Cannot
understand
*
Cc: Harry Wentland
Cc: Leo Li
Cc: Rodrigo Siqueira
Cc: Alex Deucher
Cc: "Christian König"
Cc: "Pan, Xinhui"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Mustapha Ghaddar
Cc: Nicholas Kazlauskas
Cc: Jasdeep Dhillon
Cc: amd-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/amd/display/dc/core/dc_stat.c | 28 +++
1 file changed, 10 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_stat.c
b/drivers/gpu/drm/amd/display/dc/core/dc_stat.c
index 6c06587dd88c2..5f6392ae31a66 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_stat.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_stat.c
@@ -35,19 +35,15 @@
*/
/**
- *
- * Function: dc_stat_get_dmub_notification
+ * dc_stat_get_dmub_notification
*
- * @brief
- * Calls dmub layer to retrieve dmub notification
+ * Calls dmub layer to retrieve dmub notification
*
- * @param
- * [in] dc: dc structure
- * [in] notify: dmub notification structure
+ * @dc: dc structure
+ * @notify: dmub notification structure
*
- * @return
+ * Returns
* None
- *
*/
void dc_stat_get_dmub_notification(const struct dc *dc, struct
dmub_notification *notify)
{
@@ -73,19 +69,15 @@ void dc_stat_get_dmub_notification(const struct dc *dc,
struct dmub_notification
}
/**
- *
- * Function: dc_stat_get_dmub_dataout
+ * dc_stat_get_dmub_dataout
*
- * @brief
- * Calls dmub layer to retrieve dmub gpint dataout
+ * Calls dmub layer to retrieve dmub gpint dataout
*
- * @param
- * [in] dc: dc structure
- * [in] dataout: dmub gpint dataout
+ * @dc: dc structure
+ * @dataout: dmub gpint dataout
*
- * @return
+ * Returns
* None
- *
*/
void dc_stat_get_dmub_dataout(const struct dc *dc, uint32_t *dataout)
{
--
2.40.0.rc1.284.g88254d51c5-goog
[PATCH 27/37] drm/amd/display/dc/dce/dmub_psr: Demote kerneldoc abuse
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_psr.c:257: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst Cc: Harry Wentland Cc: Leo Li Cc: Rodrigo Siqueira Cc: Alex Deucher Cc: "Christian König" Cc: "Pan, Xinhui" Cc: David Airlie Cc: Daniel Vetter Cc: David Zhang Cc: amd-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c b/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c index 27b8f3435d86f..9705d8f883825 100644 --- a/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c +++ b/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c @@ -253,7 +253,7 @@ static void dmub_psr_set_level(struct dmub_psr *dmub, uint16_t psr_level, uint8_ dc_dmub_srv_wait_idle(dc->dmub_srv); } -/** +/* * Set PSR vtotal requirement for FreeSync PSR. */ static void dmub_psr_set_sink_vtotal_in_psr_active(struct dmub_psr *dmub, -- 2.40.0.rc1.284.g88254d51c5-goog
[PATCH 26/37] drm/amd/display/amdgpu_dm/amdgpu_dm_helpers: Move SYNAPTICS_DEVICE_ID into CONFIG_DRM_AMD_DC_DCN ifdef
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:48:22:
warning: ‘SYNAPTICS_DEVICE_ID’ defined but not used [-Wunused-const-variable=]
Cc: Harry Wentland
Cc: Leo Li
Cc: Rodrigo Siqueira
Cc: Alex Deucher
Cc: "Christian König"
Cc: "Pan, Xinhui"
Cc: David Airlie
Cc: Daniel Vetter
Cc: amd-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index 330ab036c830f..a8904184673f6 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -44,9 +44,6 @@
#include "dm_helpers.h"
#include "ddc_service_types.h"
-/* MST Dock */
-static const uint8_t SYNAPTICS_DEVICE_ID[] = "SYNA";
-
/* dm_helpers_parse_edid_caps
*
* Parse edid caps
@@ -703,6 +700,9 @@ static void apply_synaptics_fifo_reset_wa(struct drm_dp_aux
*aux)
DC_LOG_DC("Done apply_synaptics_fifo_reset_wa\n");
}
+/* MST Dock */
+static const uint8_t SYNAPTICS_DEVICE_ID[] = "SYNA";
+
static uint8_t write_dsc_enable_synaptics_non_virtual_dpcd_mst(
struct drm_dp_aux *aux,
const struct dc_stream_state *stream,
--
2.40.0.rc1.284.g88254d51c5-goog
[PATCH 19/37] drm/amd/pm/swsmu/smu11/vangogh_ppt: Provide a couple of missing parameter descriptions
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:2381: warning: Function parameter or member 'residency' not described in 'vangogh_get_gfxoff_residency' drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:2399: warning: Function parameter or member 'entrycount' not described in 'vangogh_get_gfxoff_entrycount' Cc: Evan Quan Cc: Alex Deucher Cc: "Christian König" Cc: "Pan, Xinhui" Cc: David Airlie Cc: Daniel Vetter Cc: Li Ma Cc: amd-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c index 4590374251f3b..7433dcaa16e04 100644 --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c @@ -2389,6 +2389,7 @@ static u32 vangogh_set_gfxoff_residency(struct smu_context *smu, bool start) * vangogh_get_gfxoff_residency * * @smu: amdgpu_device pointer + * @residency: placeholder for return value * * This function will be used to get gfxoff residency. * @@ -2407,6 +2408,7 @@ static u32 vangogh_get_gfxoff_residency(struct smu_context *smu, uint32_t *resid * vangogh_get_gfxoff_entrycount - get gfxoff entry count * * @smu: amdgpu_device pointer + * @entrycount: placeholder for return value * * This function will be used to get gfxoff entry count * -- 2.40.0.rc1.284.g88254d51c5-goog
[PATCH 20/37] drm/amd/display/amdgpu_dm/amdgpu_dm_helpers: Move defines out to where they are actually used
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/../display/include/ddc_service_types.h: At top
level:
drivers/gpu/drm/amd/amdgpu/../display/include/ddc_service_types.h:143:22:
warning: ‘SYNAPTICS_DEVICE_ID’ defined but not used
[-Wunused-const-variable=]
drivers/gpu/drm/amd/amdgpu/../display/include/ddc_service_types.h:140:22:
warning: ‘DP_VGA_LVDS_CONVERTER_ID_3’ defined but not used
[-Wunused-const-variable=]
drivers/gpu/drm/amd/amdgpu/../display/include/ddc_service_types.h:138:22:
warning: ‘DP_VGA_LVDS_CONVERTER_ID_2’ defined but not used
[-Wunused-const-variable=]
drivers/gpu/drm/amd/amdgpu/../display/include/ddc_service_types.h:133:22:
warning: ‘DP_SINK_DEVICE_STR_ID_2’ defined but not used
[-Wunused-const-variable=]
drivers/gpu/drm/amd/amdgpu/../display/include/ddc_service_types.h:132:22:
warning: ‘DP_SINK_DEVICE_STR_ID_1’ defined but not used
[-Wunused-const-variable=]
[snip 400 similar lines brevity]
Cc: Harry Wentland
Cc: Leo Li
Cc: Rodrigo Siqueira
Cc: Alex Deucher
Cc: "Christian König"
Cc: "Pan, Xinhui"
Cc: David Airlie
Cc: Daniel Vetter
Cc: amd-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 3 +++
drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c | 3 +++
.../gpu/drm/amd/display/dc/link/link_detection.c| 2 ++
.../dc/link/protocols/link_edp_panel_control.c | 5 +
.../gpu/drm/amd/display/include/ddc_service_types.h | 13 -
5 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index 9c1e91c2179eb..330ab036c830f 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -44,6 +44,9 @@
#include "dm_helpers.h"
#include "ddc_service_types.h"
+/* MST Dock */
+static const uint8_t SYNAPTICS_DEVICE_ID[] = "SYNA";
+
/* dm_helpers_parse_edid_caps
*
* Parse edid caps
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c
b/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c
index 19440bdf63449..27b8f3435d86f 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c
@@ -33,6 +33,9 @@
#define MAX_PIPES 6
+static const uint8_t DP_SINK_DEVICE_STR_ID_1[] = {7, 1, 8, 7, 3};
+static const uint8_t DP_SINK_DEVICE_STR_ID_2[] = {7, 1, 8, 7, 5};
+
/*
* Convert dmcub psr state to dmcu psr state.
*/
diff --git a/drivers/gpu/drm/amd/display/dc/link/link_detection.c
b/drivers/gpu/drm/amd/display/dc/link/link_detection.c
index 8cfeddfb65c89..9177b146a80a8 100644
--- a/drivers/gpu/drm/amd/display/dc/link/link_detection.c
+++ b/drivers/gpu/drm/amd/display/dc/link/link_detection.c
@@ -60,6 +60,8 @@
*/
#define LINK_TRAINING_MAX_VERIFY_RETRY 2
+static const u8 DP_SINK_BRANCH_DEV_NAME_7580[] = "7580\x80u";
+
static const uint8_t dp_hdmi_dongle_signature_str[] = "DP-HDMI ADAPTOR";
static enum ddc_transaction_type get_ddc_transaction_type(enum signal_type
sink_signal)
diff --git
a/drivers/gpu/drm/amd/display/dc/link/protocols/link_edp_panel_control.c
b/drivers/gpu/drm/amd/display/dc/link/protocols/link_edp_panel_control.c
index 93a6bbe954bb7..d895046787bc4 100644
--- a/drivers/gpu/drm/amd/display/dc/link/protocols/link_edp_panel_control.c
+++ b/drivers/gpu/drm/amd/display/dc/link/protocols/link_edp_panel_control.c
@@ -37,6 +37,11 @@
#include "abm.h"
#define DC_LOGGER_INIT(logger)
+/* Travis */
+static const uint8_t DP_VGA_LVDS_CONVERTER_ID_2[] = "sivarT";
+/* Nutmeg */
+static const uint8_t DP_VGA_LVDS_CONVERTER_ID_3[] = "dnomlA";
+
void dp_set_panel_mode(struct dc_link *link, enum dp_panel_mode panel_mode)
{
union dpcd_edp_config edp_config_set;
diff --git a/drivers/gpu/drm/amd/display/include/ddc_service_types.h
b/drivers/gpu/drm/amd/display/include/ddc_service_types.h
index 31a12ce79a8e0..f843fc4978552 100644
--- a/drivers/gpu/drm/amd/display/include/ddc_service_types.h
+++ b/drivers/gpu/drm/amd/display/include/ddc_service_types.h
@@ -129,17 +129,4 @@ struct av_sync_data {
uint8_t aud_del_ins3;/* DPCD 0002Dh */
};
-static const uint8_t DP_SINK_DEVICE_STR_ID_1[] = {7, 1, 8, 7, 3};
-static const uint8_t DP_SINK_DEVICE_STR_ID_2[] = {7, 1, 8, 7, 5};
-
-static const u8 DP_SINK_BRANCH_DEV_NAME_7580[] = "7580\x80u";
-
-/*Travis*/
-static const uint8_t DP_VGA_LVDS_CONVERTER_ID_2[] = "sivarT";
-/*Nutmeg*/
-static const uint8_t DP_VGA_LVDS_CONVERTER_ID_3[] = "dnomlA";
-
-/*MST Dock*/
-static const uint8_t SYNAPTICS_DEVICE_ID[] = "SYNA";
-
#endif /* __DAL_DDC_SERVICE_TYPES_H__ */
--
2.40.0.rc1.284.g88254d51c5-goog
[PATCH 18/37] drm/amd/amdgpu/amdgpu_vce: Provide description for amdgpu_vce_validate_bo()'s 'p' param
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c:599: warning: Function parameter or member 'p' not described in 'amdgpu_vce_validate_bo' Cc: Alex Deucher Cc: "Christian König" Cc: "Pan, Xinhui" Cc: David Airlie Cc: Daniel Vetter Cc: Sumit Semwal Cc: amd-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Signed-off-by: Lee Jones --- drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c index 2fb61410b1c02..c4d65ade5c00a 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c @@ -585,6 +585,7 @@ static int amdgpu_vce_get_destroy_msg(struct amdgpu_ring *ring, uint32_t handle, /** * amdgpu_vce_validate_bo - make sure not to cross 4GB boundary * + * @p: parser context * @ib: indirect buffer to use * @lo: address of lower dword * @hi: address of higher dword -- 2.40.0.rc1.284.g88254d51c5-goog
[PATCH 17/37] drm/amd/amdgpu/amdgpu_mes: Ensure amdgpu_bo_create_kernel()'s return value is checked
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c: In function
‘amdgpu_mes_ctx_alloc_meta_data’:
drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c:1099:13: warning: variable ‘r’ set but
not used [-Wunused-but-set-variable]
Cc: Alex Deucher
Cc: "Christian König"
Cc: "Pan, Xinhui"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: Jack Xiao
Cc: Hawking Zhang
Cc: amd-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c
index 82e27bd4f0383..30cd72ca1eefd 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c
@@ -1104,6 +1104,11 @@ int amdgpu_mes_ctx_alloc_meta_data(struct amdgpu_device
*adev,
&ctx_data->meta_data_obj,
&ctx_data->meta_data_mc_addr,
&ctx_data->meta_data_ptr);
+ if (r) {
+ dev_warn(adev->dev, "(%d) create CTX bo failed\n", r);
+ return r;
+ }
+
if (!ctx_data->meta_data_obj)
return -ENOMEM;
--
2.40.0.rc1.284.g88254d51c5-goog
[PATCH 16/37] drm/amd/amdgpu/ih_v6_0: Repair misspelling and provide descriptions for 'ih'
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/ih_v6_0.c:392: warning: Function parameter or member 'ih' not described in 'ih_v6_0_get_wptr' drivers/gpu/drm/amd/amdgpu/ih_v6_0.c:432: warning: Function parameter or member 'ih' not described in 'ih_v6_0_irq_rearm' drivers/gpu/drm/amd/amdgpu/ih_v6_0.c:458: warning: Function parameter or member 'ih' not described in 'ih_v6_0_set_rptr' Cc: Alex Deucher Cc: "Christian König" Cc: "Pan, Xinhui" Cc: David Airlie Cc: Daniel Vetter Cc: Hawking Zhang Cc: amd-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/amd/amdgpu/ih_v6_0.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/ih_v6_0.c b/drivers/gpu/drm/amd/amdgpu/ih_v6_0.c index 7cd79a3844b24..b02e1cef78a76 100644 --- a/drivers/gpu/drm/amd/amdgpu/ih_v6_0.c +++ b/drivers/gpu/drm/amd/amdgpu/ih_v6_0.c @@ -119,7 +119,7 @@ force_update_wptr_for_self_int(struct amdgpu_device *adev, * ih_v6_0_toggle_ring_interrupts - toggle the interrupt ring buffer * * @adev: amdgpu_device pointer - * @ih: amdgpu_ih_ring pointet + * @ih: amdgpu_ih_ring pointer * @enable: true - enable the interrupts, false - disable the interrupts * * Toggle the interrupt ring buffer (IH_V6_0) @@ -381,6 +381,7 @@ static void ih_v6_0_irq_disable(struct amdgpu_device *adev) * ih_v6_0_get_wptr - get the IH ring buffer wptr * * @adev: amdgpu_device pointer + * @ih: amdgpu_ih_ring pointer * * Get the IH ring buffer wptr from either the register * or the writeback memory buffer. Also check for @@ -425,6 +426,7 @@ static u32 ih_v6_0_get_wptr(struct amdgpu_device *adev, * ih_v6_0_irq_rearm - rearm IRQ if lost * * @adev: amdgpu_device pointer + * @ih: amdgpu_ih_ring pointer * */ static void ih_v6_0_irq_rearm(struct amdgpu_device *adev, @@ -450,6 +452,7 @@ static void ih_v6_0_irq_rearm(struct amdgpu_device *adev, * ih_v6_0_set_rptr - set the IH ring buffer rptr * * @adev: amdgpu_device pointer + * @ih: amdgpu_ih_ring pointer * * Set the IH ring buffer rptr. */ -- 2.40.0.rc1.284.g88254d51c5-goog
[PATCH 14/37] drm/amd/amdgpu/amdgpu_vm_pt: Supply description for amdgpu_vm_pt_free_dfs()'s unlocked param
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c:683: warning: Function parameter or member 'unlocked' not described in 'amdgpu_vm_pt_free_dfs' Cc: Alex Deucher Cc: "Christian König" Cc: "Pan, Xinhui" Cc: David Airlie Cc: Daniel Vetter Cc: Sumit Semwal Cc: amd-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Signed-off-by: Lee Jones --- drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c index 01e42bdd8e4e8..df63dc3bca18c 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c @@ -673,6 +673,7 @@ void amdgpu_vm_pt_free_work(struct work_struct *work) * @adev: amdgpu device structure * @vm: amdgpu vm structure * @start: optional cursor where to start freeing PDs/PTs + * @unlocked: vm resv unlock status * * Free the page directory or page table level and all sub levels. */ -- 2.40.0.rc1.284.g88254d51c5-goog
[PATCH 15/37] drm/amd/amdgpu/gmc_v11_0: Provide a few missing param descriptions relating to hubs and flushes
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c:282: warning: Function parameter or member 'vmhub' not described in 'gmc_v11_0_flush_gpu_tlb' drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c:282: warning: Function parameter or member 'flush_type' not described in 'gmc_v11_0_flush_gpu_tlb' drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c:322: warning: Function parameter or member 'flush_type' not described in 'gmc_v11_0_flush_gpu_tlb_pasid' drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c:322: warning: Function parameter or member 'all_hub' not described in 'gmc_v11_0_flush_gpu_tlb_pasid' Cc: Alex Deucher Cc: "Christian König" Cc: "Pan, Xinhui" Cc: David Airlie Cc: Daniel Vetter Cc: amd-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c b/drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c index fad199ed15f38..9f4f28192c601 100644 --- a/drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c @@ -274,6 +274,8 @@ static void gmc_v11_0_flush_vm_hub(struct amdgpu_device *adev, uint32_t vmid, * * @adev: amdgpu_device pointer * @vmid: vm instance to flush + * @vmhub: which hub to flush + * @flush_type: the flush type * * Flush the TLB for the requested page table. */ @@ -313,6 +315,8 @@ static void gmc_v11_0_flush_gpu_tlb(struct amdgpu_device *adev, uint32_t vmid, * * @adev: amdgpu_device pointer * @pasid: pasid to be flush + * @flush_type: the flush type + * @all_hub: flush all hubs * * Flush the TLB for the requested pasid. */ -- 2.40.0.rc1.284.g88254d51c5-goog
[PATCH 13/37] drm/amd/amdgpu/amdgpu_ucode: Remove unused function ‘amdgpu_ucode_print_imu_hdr’
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c:129:6: warning: no previous
prototype for ‘amdgpu_ucode_print_imu_hdr’ [-Wmissing-prototypes]
Cc: Alex Deucher
Cc: "Christian König"
Cc: "Pan, Xinhui"
Cc: David Airlie
Cc: Daniel Vetter
Cc: amd-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
index 380b89114341d..a7bffd24ceaf3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
@@ -126,19 +126,6 @@ void amdgpu_ucode_print_gfx_hdr(const struct
common_firmware_header *hdr)
}
}
-void amdgpu_ucode_print_imu_hdr(const struct common_firmware_header *hdr)
-{
- uint16_t version_major = le16_to_cpu(hdr->header_version_major);
- uint16_t version_minor = le16_to_cpu(hdr->header_version_minor);
-
- DRM_DEBUG("IMU\n");
- amdgpu_ucode_print_common_hdr(hdr);
-
- if (version_major != 1) {
- DRM_ERROR("Unknown GFX ucode version: %u.%u\n", version_major,
version_minor);
- }
-}
-
void amdgpu_ucode_print_rlc_hdr(const struct common_firmware_header *hdr)
{
uint16_t version_major = le16_to_cpu(hdr->header_version_major);
--
2.40.0.rc1.284.g88254d51c5-goog
[PATCH 03/37] drm/amd/amdgpu/amdgpu_device: Provide missing kerneldoc entry for 'reset_context'
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:5152: warning: Function parameter or member 'reset_context' not described in 'amdgpu_device_gpu_recover' Cc: Alex Deucher Cc: "Christian König" Cc: "Pan, Xinhui" Cc: David Airlie Cc: Daniel Vetter Cc: Sumit Semwal Cc: amd-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Signed-off-by: Lee Jones --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index d4519fbd526f2..ef0b2787796da 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -5145,6 +5145,7 @@ static inline void amdgpu_device_stop_pending_resets(struct amdgpu_device *adev) * * @adev: amdgpu_device pointer * @job: which job trigger hang + * @reset_context: amdgpu reset context pointer * * Attempt to reset the GPU if it has hung (all asics). * Attempt to do soft-reset or full-reset and reinitialize Asic -- 2.40.0.rc1.284.g88254d51c5-goog
[PATCH 01/37] drm/amd/display/dc/dc_hdmi_types: Move string definition to the only file it's used in
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/../display/dc/dc_hdmi_types.h:53:22:
warning: ‘dp_hdmi_dongle_signature_str’ defined but not used
[-Wunused-const-variable=]
[snipped 400 similar lines for brevity]
Cc: Harry Wentland
Cc: Leo Li
Cc: Rodrigo Siqueira
Cc: Alex Deucher
Cc: "Christian König"
Cc: "Pan, Xinhui"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Wenjing Liu
Cc: amd-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/amd/display/dc/dc_hdmi_types.h | 1 -
drivers/gpu/drm/amd/display/dc/link/link_detection.c | 2 ++
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dc_hdmi_types.h
b/drivers/gpu/drm/amd/display/dc/dc_hdmi_types.h
index c364744b4c835..b015e80672ec9 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_hdmi_types.h
+++ b/drivers/gpu/drm/amd/display/dc/dc_hdmi_types.h
@@ -50,7 +50,6 @@ struct dp_hdmi_dongle_signature_data {
/* DP-HDMI dongle slave address for retrieving dongle signature*/
#define DP_HDMI_DONGLE_ADDRESS 0x40
-static const uint8_t dp_hdmi_dongle_signature_str[] = "DP-HDMI ADAPTOR";
#define DP_HDMI_DONGLE_SIGNATURE_EOT 0x04
diff --git a/drivers/gpu/drm/amd/display/dc/link/link_detection.c
b/drivers/gpu/drm/amd/display/dc/link/link_detection.c
index fee71ebdfc733..8cfeddfb65c89 100644
--- a/drivers/gpu/drm/amd/display/dc/link/link_detection.c
+++ b/drivers/gpu/drm/amd/display/dc/link/link_detection.c
@@ -60,6 +60,8 @@
*/
#define LINK_TRAINING_MAX_VERIFY_RETRY 2
+static const uint8_t dp_hdmi_dongle_signature_str[] = "DP-HDMI ADAPTOR";
+
static enum ddc_transaction_type get_ddc_transaction_type(enum signal_type
sink_signal)
{
enum ddc_transaction_type transaction_type = DDC_TRANSACTION_TYPE_NONE;
--
2.40.0.rc1.284.g88254d51c5-goog
