Re: [PATCH] drm/amd/display: Set default brightness according to ACPI
On 2024-06-07 09:49, Alex Deucher wrote:
On Fri, Jun 7, 2024 at 3:22 AM Mario Limonciello
wrote:
Currently, amdgpu will always set up the brightness at 100% when it
loads. However this is jarring when the BIOS has it previously
programmed to a much lower value.
The ACPI ATIF method includes two members for "ac_level" and "dc_level".
These represent the default values that should be used if the system is
brought up in AC and DC respectively.
Use these values to set up the default brightness when the backlight
device is registered.
Signed-off-by: Mario Limonciello
Acked-by: Alex Deucher
Reviewed-by: Leo Li
---
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 4
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 12 +++-
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 8
3 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
index 7099ff9cf8c5..f85ace0384d2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
@@ -383,6 +383,8 @@ static int amdgpu_atif_query_backlight_caps(struct
amdgpu_atif *atif)
characteristics.min_input_signal;
atif->backlight_caps.max_input_signal =
characteristics.max_input_signal;
+ atif->backlight_caps.ac_level = characteristics.ac_level;
+ atif->backlight_caps.dc_level = characteristics.dc_level;
out:
kfree(info);
return err;
@@ -1268,6 +1270,8 @@ void amdgpu_acpi_get_backlight_caps(struct
amdgpu_dm_backlight_caps *caps)
caps->caps_valid = atif->backlight_caps.caps_valid;
caps->min_input_signal = atif->backlight_caps.min_input_signal;
caps->max_input_signal = atif->backlight_caps.max_input_signal;
+ caps->ac_level = atif->backlight_caps.ac_level;
+ caps->dc_level = atif->backlight_caps.dc_level;
}
/**
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 5fd7210b2479..71aa0c518951 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -77,6 +77,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -4321,6 +4322,7 @@ amdgpu_dm_register_backlight_device(struct
amdgpu_dm_connector *aconnector)
struct drm_device *drm = aconnector->base.dev;
struct amdgpu_display_manager *dm = _to_adev(drm)->dm;
struct backlight_properties props = { 0 };
+ struct amdgpu_dm_backlight_caps caps = { 0 };
char bl_name[16];
if (aconnector->bl_idx == -1)
@@ -4333,8 +4335,16 @@ amdgpu_dm_register_backlight_device(struct
amdgpu_dm_connector *aconnector)
return;
}
+ amdgpu_acpi_get_backlight_caps();
+ if (caps.caps_valid) {
+ if (power_supply_is_system_supplied() > 0)
+ props.brightness = caps.ac_level;
+ else
+ props.brightness = caps.dc_level;
+ } else
+ props.brightness = AMDGPU_MAX_BL_LEVEL;
+
props.max_brightness = AMDGPU_MAX_BL_LEVEL;
- props.brightness = AMDGPU_MAX_BL_LEVEL;
props.type = BACKLIGHT_RAW;
snprintf(bl_name, sizeof(bl_name), "amdgpu_bl%d",
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index b246e82f5b0d..df72cb71e95a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -173,6 +173,14 @@ struct amdgpu_dm_backlight_caps {
* @aux_support: Describes if the display supports AUX backlight.
*/
bool aux_support;
+ /**
+* @ac_level: the default brightness if booted on AC
+*/
+ u8 ac_level;
+ /**
+* @dc_level: the default brightness if booted on DC
+*/
+ u8 dc_level;
};
/**
--
2.43.0
Re: [PATCH v2 1/2] drm: Introduce 'power saving policy' drm property
On 2024-05-22 18:05, Mario Limonciello wrote:
The `power saving policy` DRM property is an optional property that
can be added to a connector by a driver.
This property is for compositors to indicate intent of policy of
whether a driver can use power saving features that may compromise
the experience intended by the compositor.
Signed-off-by: Mario Limonciello
Acked-by: Leo Li
Thanks!
---
drivers/gpu/drm/drm_connector.c | 46 +
include/drm/drm_connector.h | 2 ++
include/drm/drm_mode_config.h | 5
include/uapi/drm/drm_mode.h | 7 +
4 files changed, 60 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 4d2df7f64dc5..088a5874c7a4 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -961,6 +961,11 @@ static const struct drm_prop_enum_list
drm_scaling_mode_enum_list[] = {
{ DRM_MODE_SCALE_ASPECT, "Full aspect" },
};
+static const struct drm_prop_enum_list drm_power_saving_policy_enum_list[] = {
+ { __builtin_ffs(DRM_MODE_REQUIRE_COLOR_ACCURACY) - 1, "Require color
accuracy" },
+ { __builtin_ffs(DRM_MODE_REQUIRE_LOW_LATENCY) - 1, "Require low
latency" },
+};
+
static const struct drm_prop_enum_list drm_aspect_ratio_enum_list[] = {
{ DRM_MODE_PICTURE_ASPECT_NONE, "Automatic" },
{ DRM_MODE_PICTURE_ASPECT_4_3, "4:3" },
@@ -1499,6 +1504,16 @@ static const u32 dp_colorspaces =
*
*Drivers can set up these properties by calling
*drm_mode_create_tv_margin_properties().
+ * power saving policy:
+ * This property is used to set the power saving policy for the connector.
+ * This property is populated with a bitmask of optional requirements set
+ * by the drm master for the drm driver to respect:
+ * - "Require color accuracy": Disable power saving features that will
+ * affect color fidelity.
+ * For example: Hardware assisted backlight modulation.
+ * - "Require low latency": Disable power saving features that will
+ * affect latency.
+ * For example: Panel self refresh (PSR)
*/
int drm_connector_create_standard_properties(struct drm_device *dev)
@@ -1963,6 +1978,37 @@ int drm_mode_create_scaling_mode_property(struct
drm_device *dev)
}
EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
+/**
+ * drm_mode_create_power_saving_policy_property - create power saving policy
property
+ * @dev: DRM device
+ * @supported_policies: bitmask of supported power saving policies
+ *
+ * Called by a driver the first time it's needed, must be attached to desired
+ * connectors.
+ *
+ * Returns: %0
+ */
+int drm_mode_create_power_saving_policy_property(struct drm_device *dev,
+uint64_t supported_policies)
+{
+ struct drm_property *power_saving;
+
+ if (dev->mode_config.power_saving_policy)
+ return 0;
+ WARN_ON((supported_policies & DRM_MODE_POWER_SAVING_POLICY_ALL) == 0);
+
+ power_saving =
+ drm_property_create_bitmask(dev, 0, "power saving policy",
+ drm_power_saving_policy_enum_list,
+
ARRAY_SIZE(drm_power_saving_policy_enum_list),
+ supported_policies);
+
+ dev->mode_config.power_saving_policy = power_saving;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_mode_create_power_saving_policy_property);
+
/**
* DOC: Variable refresh properties
*
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index fe88d7fc6b8f..b0ec2ec48de7 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -2025,6 +2025,8 @@ int drm_mode_create_dp_colorspace_property(struct
drm_connector *connector,
u32 supported_colorspaces);
int drm_mode_create_content_type_property(struct drm_device *dev);
int drm_mode_create_suggested_offset_properties(struct drm_device *dev);
+int drm_mode_create_power_saving_policy_property(struct drm_device *dev,
+uint64_t supported_policies);
int drm_connector_set_path_property(struct drm_connector *connector,
const char *path);
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 973119a9176b..32077e701e2f 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -954,6 +954,11 @@ struct drm_mode_config {
*/
struct drm_atomic_state *suspend_state;
+ /**
+* @power_saving_policy: bitmask for power saving policy requests.
+*/
+ struct drm_property *power_saving_policy;
+
const struct drm_mode_config_helper_funcs *helper_private;
};
diff --git a/include/
Re: [PATCH v2 2/2] drm/amd: Add power_saving_policy drm property to eDP connectors
NNECTOR_eDP &&
+ (dc_is_dmcu_initialized(adev->dm.dc) ||
+adev->dm.dc->ctx->dmub_srv)) {
+ drm_object_attach_property(>base.base,
+ dm->ddev->mode_config.power_saving_policy, 0);
+ }
+
if (connector_type == DRM_MODE_CONNECTOR_HDMIA) {
/* Content Type is currently only implemented for HDMI. */
drm_connector_attach_content_type_property(>base);
@@ -9344,6 +9374,11 @@ static void amdgpu_dm_atomic_commit_tail(struct
drm_atomic_state *state)
stream_update.hdr_static_metadata = _packet;
}
+ if (dm_old_con_state->psr_forbidden && !dm_new_con_state->psr_forbidden)
+ amdgpu_dm_psr_disable(dm_new_crtc_state->stream);
+ else if (!dm_old_con_state->psr_forbidden &&
dm_new_con_state->psr_forbidden)
+ amdgpu_dm_psr_enable(dm_new_crtc_state->stream);
+
Thanks for the patch!
Unfortunately, enabling/disabling PSR today isn't as straightforward as a call
to amdgpu_dm_psr_enable/disable. The conditions for enabling PSR is quite
convoluted and need some untangling...
For now, I think the easiest way to pipe this property through is to hijack the
`amdgpu_dm_connector->disallow_edp_enter_psr` flag. IIRC, it is currently hooked
up to a debugfs that force disables PSR for testing purposes. Eventually, we can
probably deprecate the debugfs and use this property instead.
We could change the above 'if/else if' to something like the following:
```
struct amdgpu_dm_connector *aconnector = to_amdgpu_dm_connector(connector);
aconnector->disallow_edp_enter_psr = dm_new_con_state->psr_forbidden
/* immediately disable PSR if disallowed */
if (aconnector->disallow_edp_enter_psr) {
mutex_lock(>dc_lock);
amdgpu_dm_psr_disable(dm_new_crtc_state->stream);
mutex_unlock(>dc_lock);
}
```
The moment disallow_edp_enter_psr flips to 0, the next fast update should
re-enable PSR. There isn't any guarantee of an immediate re-enable, but I think
that should be fine.
status = dc_stream_get_status(dm_new_crtc_state->stream);
if (WARN_ON(!status))
@@ -10019,6 +10054,12 @@ static int dm_update_crtc_state(struct
amdgpu_display_manager *dm,
update_stream_scaling_settings(
_crtc_state->mode, dm_new_conn_state,
dm_new_crtc_state->stream);
+
+ if (dm_old_conn_state->psr_forbidden &&
!dm_new_conn_state->psr_forbidden)
+ amdgpu_dm_psr_disable(dm_new_crtc_state->stream);
+ else if (!dm_old_conn_state->psr_forbidden &&
dm_new_conn_state->psr_forbidden)
+ amdgpu_dm_psr_enable(dm_new_crtc_state->stream);
+
dm_update_crtc_state() can be called as part of atomic check, so we should not
do any hw programming here.
There aren't any reasons I can think of to reject allow/disallowing PSR either,
so this part shouldn't be necessary and can be dropped.
Thanks,
Leo
/* ABM settings */
dm_new_crtc_state->abm_level = dm_new_conn_state->abm_level;
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index 09519b7abf67..b246e82f5b0d 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -873,6 +873,8 @@ struct dm_connector_state {
bool underscan_enable;
bool freesync_capable;
bool update_hdcp;
+ bool abm_forbidden;
+ bool psr_forbidden;
uint8_t abm_level;
int vcpi_slots;
uint64_t pbn;
RE: [PATCH] drm/amdgpu: drop some kernel messages in VCN code
[AMD Official Use Only - AMD Internal Distribution Only]
Acked-by: Leo Liu
> -Original Message-
> From: Wu, David
> Sent: Thursday, May 30, 2024 10:59 AM
> To: amd-gfx@lists.freedesktop.org; Koenig, Christian
>
> Cc: Deucher, Alexander ; Liu, Leo
> ; Jiang, Sonny ; Dong, Ruijing
>
> Subject: [PATCH] drm/amdgpu: drop some kernel messages in VCN code
>
> Similar to commit 15681da214b where some kernel log messages are dropped.
> With this commit, more log messages in older version of VCN/JPEG code are
> dropped.
>
> Signed-off-by: David (Ming Qiang) Wu
> ---
> drivers/gpu/drm/amd/amdgpu/jpeg_v1_0.c | 1 -
> drivers/gpu/drm/amd/amdgpu/jpeg_v2_0.c | 8 +---
> drivers/gpu/drm/amd/amdgpu/jpeg_v2_5.c | 3 ---
> drivers/gpu/drm/amd/amdgpu/jpeg_v3_0.c | 10 +-
> drivers/gpu/drm/amd/amdgpu/jpeg_v4_0.c | 3 ---
> drivers/gpu/drm/amd/amdgpu/jpeg_v4_0_3.c | 2 --
> drivers/gpu/drm/amd/amdgpu/jpeg_v4_0_5.c | 5 -
> drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c| 14 ++
> drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c| 14 +++---
> drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c| 11 ++-
> drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c| 16 +++-
> drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c| 14 ++
> drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.c | 10 ++
> drivers/gpu/drm/amd/amdgpu/vcn_v4_0_5.c | 10 +-
> 14 files changed, 17 insertions(+), 104 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/jpeg_v1_0.c
> b/drivers/gpu/drm/amd/amdgpu/jpeg_v1_0.c
> index 77595e9622da..71f43a5c7f72 100644
> --- a/drivers/gpu/drm/amd/amdgpu/jpeg_v1_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/jpeg_v1_0.c
> @@ -581,7 +581,6 @@ static const struct amdgpu_ring_funcs
> jpeg_v1_0_decode_ring_vm_funcs = { static void
> jpeg_v1_0_set_dec_ring_funcs(struct amdgpu_device *adev) {
> adev->jpeg.inst->ring_dec->funcs =
> _v1_0_decode_ring_vm_funcs;
> - DRM_INFO("JPEG decode is enabled in VM mode\n");
> }
>
> static const struct amdgpu_irq_src_funcs jpeg_v1_0_irq_funcs = { diff --git
> a/drivers/gpu/drm/amd/amdgpu/jpeg_v2_0.c
> b/drivers/gpu/drm/amd/amdgpu/jpeg_v2_0.c
> index ef3e42f6b841..99adf3625657 100644
> --- a/drivers/gpu/drm/amd/amdgpu/jpeg_v2_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/jpeg_v2_0.c
> @@ -131,16 +131,11 @@ static int jpeg_v2_0_hw_init(void *handle) {
> struct amdgpu_device *adev = (struct amdgpu_device *)handle;
> struct amdgpu_ring *ring = adev->jpeg.inst->ring_dec;
> - int r;
>
> adev->nbio.funcs->vcn_doorbell_range(adev, ring->use_doorbell,
> (adev->doorbell_index.vcn.vcn_ring0_1 << 1), 0);
>
> - r = amdgpu_ring_test_helper(ring);
> - if (!r)
> - DRM_INFO("JPEG decode initialized successfully.\n");
> -
> - return r;
> + return amdgpu_ring_test_helper(ring);
> }
>
> /**
> @@ -795,7 +790,6 @@ static const struct amdgpu_ring_funcs
> jpeg_v2_0_dec_ring_vm_funcs = { static void
> jpeg_v2_0_set_dec_ring_funcs(struct amdgpu_device *adev) {
> adev->jpeg.inst->ring_dec->funcs = _v2_0_dec_ring_vm_funcs;
> - DRM_INFO("JPEG decode is enabled in VM mode\n");
> }
>
> static const struct amdgpu_irq_src_funcs jpeg_v2_0_irq_funcs = { diff --git
> a/drivers/gpu/drm/amd/amdgpu/jpeg_v2_5.c
> b/drivers/gpu/drm/amd/amdgpu/jpeg_v2_5.c
> index afeaf3c64e27..d8ef95c847c2 100644
> --- a/drivers/gpu/drm/amd/amdgpu/jpeg_v2_5.c
> +++ b/drivers/gpu/drm/amd/amdgpu/jpeg_v2_5.c
> @@ -196,8 +196,6 @@ static int jpeg_v2_5_hw_init(void *handle)
> return r;
> }
>
> - DRM_INFO("JPEG decode initialized successfully.\n");
> -
> return 0;
> }
>
> @@ -728,7 +726,6 @@ static void jpeg_v2_5_set_dec_ring_funcs(struct
> amdgpu_device *adev)
> else /* CHIP_ALDEBARAN */
> adev->jpeg.inst[i].ring_dec->funcs =
> _v2_6_dec_ring_vm_funcs;
> adev->jpeg.inst[i].ring_dec->me = i;
> - DRM_INFO("JPEG(%d) JPEG decode is enabled in VM mode\n",
> i);
> }
> }
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/jpeg_v3_0.c
> b/drivers/gpu/drm/amd/amdgpu/jpeg_v3_0.c
> index 1c7cf4800bf7..31cfa3ce6528 100644
> --- a/drivers/gpu/drm/amd/amdgpu/jpeg_v3_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/jpeg_v3_0.c
> @@ -146,18 +146,11 @@ static int jpeg_v3_0_hw_init(void *handle) {
> struct amdgpu_device *adev = (struct amdgpu_device *)handle;
> struct amdgpu_ring *ring = adev->jpeg.inst->ring_dec;
> - int r;
>
> adev->nbio.funcs->vcn_doorbell_range(adev, rin
Re: [PATCH 0/2] Add support for Panel Power Savings property
On 2024-05-21 13:32, Mario Limonciello wrote: On 5/21/2024 12:27, Leo Li wrote: On 2024-05-21 12:21, Mario Limonciello wrote: On 5/21/2024 11:14, Xaver Hugl wrote: Am Di., 21. Mai 2024 um 16:00 Uhr schrieb Mario Limonciello : On 5/21/2024 08:43, Simon Ser wrote: This makes sense to me in general. I like the fact that it's simple and vendor-neutral. Do we want to hardcode "panel" in the name? Are we sure that this will ever only apply to panels? Do we want to use a name which reflects the intent, rather than the mechanism? In other words, something like "color fidelity" = "preferred" maybe? (I don't know, just throwing ideas around.) In that vein, how about: "power saving policy" --> "power saving" --> "color fidelity" It's not just about colors though, is it? The compositor might want to disable it to increase the backlight brightness in bright environments, so "color fidelity" doesn't really sound right Either of these better? "power saving policy" --> "power saving" --> "accuracy" "power saving policy" --> "allowed" --> "forbidden" Or any other idea? Another consideration in addition to accuracy is latency. I suppose a compositor may want to disable features such as PSR for use-cases requiring low latency. Touch and stylus input are some examples. I wonder if flags would work better than enums? A compositor can set something like `REQUIRE_ACCURACY & REQUIRE_LOW_LATENCY`, for example. I thought we had said the PSR latency issue discussed at the hackfest was likely just a bug and that nominally it won't matter? Ah, either my memory failed, or I failed to clarify. Let me fix that below. If it really will matter enough then yeah I think you're right that flags would be better. More drivers would probably want to opt into the property for the purpose of turning off PSR/PSR2/panel replay as well then. Latency technically shouldn't be a problem for Panel Replay, but is a problem for PSR/PSR2 due to their design. At least it is a problem for amdgpu, not sure about other drivers. FWIU, in short, when a panel (DPRX) goes into self-refresh, it's clock can drift from the gpu (DPTX). Since there's no resync mechanism in PSR/PSR2, it is possible for the panel to lag behind by 1-frame-time(ms) for a noticeable period of time. Panel replay has a resync mechanism, so it theoretically can resync within 1 frame. Since, fwict, replay panels are still rare, I think it'll be nice for compositors that care about latency to have the option to temporarily disable PSR/PSR2. - Leo - Leo Would be nice to add documentation for the property in the "standard connector properties" section. Ack.
Re: [PATCH 0/2] Add support for Panel Power Savings property
On 2024-05-21 12:21, Mario Limonciello wrote: On 5/21/2024 11:14, Xaver Hugl wrote: Am Di., 21. Mai 2024 um 16:00 Uhr schrieb Mario Limonciello : On 5/21/2024 08:43, Simon Ser wrote: This makes sense to me in general. I like the fact that it's simple and vendor-neutral. Do we want to hardcode "panel" in the name? Are we sure that this will ever only apply to panels? Do we want to use a name which reflects the intent, rather than the mechanism? In other words, something like "color fidelity" = "preferred" maybe? (I don't know, just throwing ideas around.) In that vein, how about: "power saving policy" --> "power saving" --> "color fidelity" It's not just about colors though, is it? The compositor might want to disable it to increase the backlight brightness in bright environments, so "color fidelity" doesn't really sound right Either of these better? "power saving policy" --> "power saving" --> "accuracy" "power saving policy" --> "allowed" --> "forbidden" Or any other idea? Another consideration in addition to accuracy is latency. I suppose a compositor may want to disable features such as PSR for use-cases requiring low latency. Touch and stylus input are some examples. I wonder if flags would work better than enums? A compositor can set something like `REQUIRE_ACCURACY & REQUIRE_LOW_LATENCY`, for example. - Leo Would be nice to add documentation for the property in the "standard connector properties" section. Ack.
RE: [PATCH] drm/amd/amdgpu: update jpeg 5 capability
[AMD Official Use Only - AMD Internal Distribution Only]
Reviewed-by: Leo Liu
> -Original Message-
> From: Wu, David
> Sent: Thursday, May 9, 2024 5:37 PM
> To: amd-gfx@lists.freedesktop.org; Deucher, Alexander
>
> Cc: Koenig, Christian ; Liu, Leo
> ; Jiang, Sonny
> Subject: [PATCH] drm/amd/amdgpu: update jpeg 5 capability
>
> Based on the documentation the maximum resolustion should be 16384x16384.
>
> Signed-off-by: David (Ming Qiang) Wu
> ---
> drivers/gpu/drm/amd/amdgpu/soc24.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/soc24.c
> b/drivers/gpu/drm/amd/amdgpu/soc24.c
> index 12900488dd61..285d6af10f62 100644
> --- a/drivers/gpu/drm/amd/amdgpu/soc24.c
> +++ b/drivers/gpu/drm/amd/amdgpu/soc24.c
> @@ -61,7 +61,7 @@ static const struct amdgpu_video_codecs
> vcn_5_0_0_video_codecs_encode_vcn0 = { static const struct
> amdgpu_video_codec_info vcn_5_0_0_video_codecs_decode_array_vcn0[] = {
>
> {codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_MPEG4_
> AVC, 4096, 2160, 52)},
> {codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_HEVC,
> 8192, 4320, 183)},
> - {codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_JPEG,
> 4096, 4096, 0)},
> + {codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_JPEG,
> 16384, 16384,
> +0)},
> {codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_VP9,
> 8192, 4352, 0)},
> {codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_AV1,
> 8192, 4352, 0)}, };
> --
> 2.34.1
RE: [PATCH] drm/amdgpu/vcn: set VCN5 power gating state to GATE on suspend
[AMD Official Use Only - General]
Reviewed-by: Leo Liu
> -Original Message-
> From: Wu, David
> Sent: Thursday, May 9, 2024 3:59 PM
> To: amd-gfx@lists.freedesktop.org; Koenig, Christian
>
> Cc: Deucher, Alexander ; Liu, Leo
> ; Jiang, Sonny
> Subject: [PATCH] drm/amdgpu/vcn: set VCN5 power gating state to GATE on
> suspend
>
> On suspend, we need to set power gating state to GATE when
> VCN5 is busy, otherwise we will get following error on resume:
>
> [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring vcn_unified_0 test
> failed (-110)
> [drm:amdgpu_device_ip_resume_phase2 [amdgpu]] *ERROR* resume of IP
> block failed -110
> amdgpu: amdgpu_device_ip_resume failed (-110).
> PM: dpm_run_callback(): pci_pm_resume+0x0/0x100 returns -110
> PM: failed to resume async: error -110
>
> Signed-off-by: David (Ming Qiang) Wu
> ---
> drivers/gpu/drm/amd/amdgpu/vcn_v5_0_0.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v5_0_0.c
> b/drivers/gpu/drm/amd/amdgpu/vcn_v5_0_0.c
> index 9b87d6a49b39..36d4ca645c56 100644
> --- a/drivers/gpu/drm/amd/amdgpu/vcn_v5_0_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/vcn_v5_0_0.c
> @@ -229,6 +229,13 @@ static int vcn_v5_0_0_hw_fini(void *handle)
> for (i = 0; i < adev->vcn.num_vcn_inst; ++i) {
> if (adev->vcn.harvest_config & (1 << i))
> continue;
> + if (!amdgpu_sriov_vf(adev)) {
> + if ((adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG)
> ||
> + (adev->vcn.cur_state !=
> AMD_PG_STATE_GATE &&
> + RREG32_SOC15(VCN, i, regUVD_STATUS))) {
> + vcn_v5_0_0_set_powergating_state(adev,
> AMD_PG_STATE_GATE);
> + }
> + }
> }
>
> return 0;
> --
> 2.34.1
RE: [PATCH v3] drm/amdgpu: IB test encode test package change for VCN5
[AMD Official Use Only - General] Reviewed-by: Leo Liu > -Original Message- > From: amd-gfx On Behalf Of Sonny > Jiang > Sent: Thursday, April 25, 2024 4:11 PM > To: amd-gfx@lists.freedesktop.org > Cc: Jiang, Sonny ; Jiang, Sonny > > Subject: [PATCH v3] drm/amdgpu: IB test encode test package change for VCN5 > > From: Sonny Jiang > > VCN5 session info package interface changed > > Signed-off-by: Sonny Jiang > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c > index 677eb141554e..b89605b400c0 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c > @@ -885,7 +885,7 @@ static int amdgpu_vcn_enc_get_create_msg(struct > amdgpu_ring *ring, uint32_t hand > ib->ptr[ib->length_dw++] = handle; > ib->ptr[ib->length_dw++] = upper_32_bits(addr); > ib->ptr[ib->length_dw++] = addr; > - ib->ptr[ib->length_dw++] = 0x000b; > + ib->ptr[ib->length_dw++] = 0x; > > ib->ptr[ib->length_dw++] = 0x0014; > ib->ptr[ib->length_dw++] = 0x0002; /* task info */ @@ -952,7 > +952,7 @@ static int amdgpu_vcn_enc_get_destroy_msg(struct amdgpu_ring > *ring, uint32_t han > ib->ptr[ib->length_dw++] = handle; > ib->ptr[ib->length_dw++] = upper_32_bits(addr); > ib->ptr[ib->length_dw++] = addr; > - ib->ptr[ib->length_dw++] = 0x000b; > + ib->ptr[ib->length_dw++] = 0x; > > ib->ptr[ib->length_dw++] = 0x0014; > ib->ptr[ib->length_dw++] = 0x0002; > -- > 2.43.2
Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible
On 2024-04-16 10:10, Harry Wentland wrote: On 2024-04-16 04:01, Pekka Paalanen wrote: On Mon, 15 Apr 2024 18:33:39 -0400 Leo Li wrote: On 2024-04-15 04:19, Pekka Paalanen wrote: On Fri, 12 Apr 2024 16:14:28 -0400 Leo Li wrote: On 2024-04-12 11:31, Alex Deucher wrote: On Fri, Apr 12, 2024 at 11:08 AM Pekka Paalanen wrote: On Fri, 12 Apr 2024 10:28:52 -0400 Leo Li wrote: On 2024-04-12 04:03, Pekka Paalanen wrote: On Thu, 11 Apr 2024 16:33:57 -0400 Leo Li wrote: ... That begs the question of what can be nailed down and what can left to independent implementation. I guess things like which plane should be enabled first (PRIMARY), and how zpos should be interpreted (overlay, underlay, mixed) can be defined. How to handle atomic test failures could be as well. What room is there for the interpretation of zpos values? I thought they are unambiguous already: only the relative numerical order matters, and that uniquely defines the KMS plane ordering. The zpos value of the PRIMARY plane relative to OVERLAYS, for example, as a way for vendors to communicate overlay, underlay, or mixed-arrangement support. I don't think allowing OVERLAYs to be placed under the PRIMARY is currently documented as a way to support underlay. I always thought it's obvious that the zpos numbers dictate the plane order without any other rules. After all, we have the universal planes concept, where the plane type is only informational to aid heuristics rather than defining anything. Only if the zpos property does not exist, the plane types would come into play. Of course, if there actually exists userspace that fails if zpos allows an overlay type plane to be placed below primary, or fails if primary zpos is not zero, then DRM needs a new client cap. Right, it wasn't immediately clear to me that the API allowed placement of things beneath the PRIMARY. But reading the docs for drm_plane_create_zpos*, there's nothing that forbids it. libliftoff for example, assumes that the PRIMARY has the lowest zpos. So underlay arrangements will use an OVERLAY for the scanout plane, and the PRIMARY for the underlay view. That's totally ok. It works, right? Plane type does not matter if the KMS driver accepts the configuration. What is a "scanout plane"? Aren't all KMS planes by definition scanout planes? Pardon my terminology, I thought the scanout plane was where weston rendered non-offloadable surfaces to. I guess it's more correct to call it the "render plane". On weston, it seems to be always assigned to the PRIMARY. The assignment restriction is just technical design debt. It is limiting. There is no other good reason for it, than when lighting up a CRTC for the first time, Weston should do it with the renderer FB only, on the plane that is most likely to succeed i.e. PRIMARY. After the CRTC is lit, there should be no built-in limitations in what can go where. The reason for this is that if a CRTC can be activated, it must always be able to show the renderer FB without incurring a modeset. This is important for ensuring that the fallback compositing (renderer) is always possible. So we start with that configuration, and everything else is optional bonus. Genuinely curious - What exactly is limiting with keeping the renderer FB on PRIMARY? IOW, what is the additional benefit of placing the renderer FB on something other than PRIMARY? The limitations come from a combination of hardware limitations. Perhaps zpos is not mutable, or maybe other planes cannot arbitrarily move between above and below the primary. This reduces the number of possible configurations, which might cause off-loading to fail. I think older hardware has more of these arbitrary restrictions. I see. I was thinking that drivers can do under-the-hood stuff to present a mutable zpos to clients, even if their hardware planes cannot be arbitrarily rearranged, by mapping the PRIMARY to a different hardware plane. But not all planes have the same function, so this sounds more complicated than helpful. For libliftoff, using OVERLAYs as the render plane and PRIMARY as the underlay plane would work. But I think keeping the render plane on PRIMARY (a la weston) makes underlay arrangements easier to allocate, and would be nice to incorporate into a shared algorithm. If zpos exists, I don't think such limitation is a good idea. It will just limit the possible configurations for no reason. With zpos, the KMS plane type should be irrelevant for their z-ordering. Underlay vs. overlay completely loses its meaning at the KMS level. Right, the plane types loose their meanings. But at least with the way libliftoff builds the plane arrangement, where we first allocate the renderer fb matters. libliftoff incrementally builds the atomic state by adding a single plane to the atomic state, then testing it. It essentially does a depth-first-search of all possible arrangements, pruning the search
RE: [PATCH 1/2] drm/amdgpu: IB size alignment on VCN5
[AMD Official Use Only - General] > -Original Message- > From: amd-gfx On Behalf Of > Sonny Jiang > Sent: Monday, April 15, 2024 5:25 PM > To: amd-gfx@lists.freedesktop.org > Cc: Jiang, Sonny ; Jiang, Sonny > > Subject: [PATCH 1/2] drm/amdgpu: IB size alignment on VCN5 > > From: Sonny Jiang > > VCN5 IB size alignment adjusted. > > Signed-off-by: Sonny Jiang > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 6 +++--- > 2 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c > index 5d1b084eb631..94ae14e0989c 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c > @@ -509,7 +509,7 @@ static int amdgpu_hw_ip_info(struct amdgpu_device > *adev, > ++num_rings; > } > ib_start_alignment = 256; > - ib_size_alignment = 4; > + ib_size_alignment = 64; We don't want these impact on previous HW if that is really required. Regards, Leo > break; > case AMDGPU_HW_IP_VCN_JPEG: > type = (amdgpu_device_ip_get_ip_block(adev, > AMD_IP_BLOCK_TYPE_JPEG)) ? > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c > index bb85772b1374..7d176046498f 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c > @@ -731,7 +731,7 @@ static int amdgpu_vcn_dec_sw_send_msg(struct > amdgpu_ring *ring, > int i, r; > > if (sq) > - ib_size_dw += 8; > + ib_size_dw += 16; > > r = amdgpu_job_alloc_with_ib(ring->adev, NULL, NULL, >ib_size_dw * 4, > AMDGPU_IB_POOL_DIRECT, @@ -861,7 +861,7 @@ static int > amdgpu_vcn_enc_get_create_msg(struct amdgpu_ring *ring, uint32_t hand > int i, r; > > if (sq) > - ib_size_dw += 8; > + ib_size_dw += 16; > > r = amdgpu_job_alloc_with_ib(ring->adev, NULL, NULL, >ib_size_dw * 4, > AMDGPU_IB_POOL_DIRECT, @@ -928,7 +928,7 @@ static int > amdgpu_vcn_enc_get_destroy_msg(struct amdgpu_ring *ring, uint32_t han > int i, r; > > if (sq) > - ib_size_dw += 8; > + ib_size_dw += 16; > > r = amdgpu_job_alloc_with_ib(ring->adev, NULL, NULL, >ib_size_dw * 4, > AMDGPU_IB_POOL_DIRECT, > -- > 2.43.2
Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible
On 2024-04-15 04:19, Pekka Paalanen wrote: On Fri, 12 Apr 2024 16:14:28 -0400 Leo Li wrote: On 2024-04-12 11:31, Alex Deucher wrote: On Fri, Apr 12, 2024 at 11:08 AM Pekka Paalanen wrote: On Fri, 12 Apr 2024 10:28:52 -0400 Leo Li wrote: On 2024-04-12 04:03, Pekka Paalanen wrote: On Thu, 11 Apr 2024 16:33:57 -0400 Leo Li wrote: ... That begs the question of what can be nailed down and what can left to independent implementation. I guess things like which plane should be enabled first (PRIMARY), and how zpos should be interpreted (overlay, underlay, mixed) can be defined. How to handle atomic test failures could be as well. What room is there for the interpretation of zpos values? I thought they are unambiguous already: only the relative numerical order matters, and that uniquely defines the KMS plane ordering. The zpos value of the PRIMARY plane relative to OVERLAYS, for example, as a way for vendors to communicate overlay, underlay, or mixed-arrangement support. I don't think allowing OVERLAYs to be placed under the PRIMARY is currently documented as a way to support underlay. I always thought it's obvious that the zpos numbers dictate the plane order without any other rules. After all, we have the universal planes concept, where the plane type is only informational to aid heuristics rather than defining anything. Only if the zpos property does not exist, the plane types would come into play. Of course, if there actually exists userspace that fails if zpos allows an overlay type plane to be placed below primary, or fails if primary zpos is not zero, then DRM needs a new client cap. Right, it wasn't immediately clear to me that the API allowed placement of things beneath the PRIMARY. But reading the docs for drm_plane_create_zpos*, there's nothing that forbids it. libliftoff for example, assumes that the PRIMARY has the lowest zpos. So underlay arrangements will use an OVERLAY for the scanout plane, and the PRIMARY for the underlay view. That's totally ok. It works, right? Plane type does not matter if the KMS driver accepts the configuration. What is a "scanout plane"? Aren't all KMS planes by definition scanout planes? Pardon my terminology, I thought the scanout plane was where weston rendered non-offloadable surfaces to. I guess it's more correct to call it the "render plane". On weston, it seems to be always assigned to the PRIMARY. The assignment restriction is just technical design debt. It is limiting. There is no other good reason for it, than when lighting up a CRTC for the first time, Weston should do it with the renderer FB only, on the plane that is most likely to succeed i.e. PRIMARY. After the CRTC is lit, there should be no built-in limitations in what can go where. The reason for this is that if a CRTC can be activated, it must always be able to show the renderer FB without incurring a modeset. This is important for ensuring that the fallback compositing (renderer) is always possible. So we start with that configuration, and everything else is optional bonus. Genuinely curious - What exactly is limiting with keeping the renderer FB on PRIMARY? IOW, what is the additional benefit of placing the renderer FB on something other than PRIMARY? For libliftoff, using OVERLAYs as the render plane and PRIMARY as the underlay plane would work. But I think keeping the render plane on PRIMARY (a la weston) makes underlay arrangements easier to allocate, and would be nice to incorporate into a shared algorithm. If zpos exists, I don't think such limitation is a good idea. It will just limit the possible configurations for no reason. With zpos, the KMS plane type should be irrelevant for their z-ordering. Underlay vs. overlay completely loses its meaning at the KMS level. Right, the plane types loose their meanings. But at least with the way libliftoff builds the plane arrangement, where we first allocate the renderer fb matters. libliftoff incrementally builds the atomic state by adding a single plane to the atomic state, then testing it. It essentially does a depth-first-search of all possible arrangements, pruning the search on atomic test fail. The state that offloads the most number of FBs will be the arrangement used. Of course, it's unlikely that the entire DFS tree will traversed in time for a frame. So the key is to search the most probable and high-benefit branches first, while minimizing the # of atomic tests needed, before a hard-coded deadline is hit. Following this algorithm, the PRIMARY needs to be enabled first, followed by all the secondary planes. After a plane is enabled, it's not preferred to change it's assigned FB, since that can cause the state to be rejected (in actuality, not just the FB, but also any color and transformation stuffs associated with the surface). It is preferable to build on the state by enabling another fb->plane. This is where changing a plane's zpos to be
Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible
On 2024-04-12 11:31, Alex Deucher wrote: On Fri, Apr 12, 2024 at 11:08 AM Pekka Paalanen wrote: On Fri, 12 Apr 2024 10:28:52 -0400 Leo Li wrote: On 2024-04-12 04:03, Pekka Paalanen wrote: On Thu, 11 Apr 2024 16:33:57 -0400 Leo Li wrote: ... That begs the question of what can be nailed down and what can left to independent implementation. I guess things like which plane should be enabled first (PRIMARY), and how zpos should be interpreted (overlay, underlay, mixed) can be defined. How to handle atomic test failures could be as well. What room is there for the interpretation of zpos values? I thought they are unambiguous already: only the relative numerical order matters, and that uniquely defines the KMS plane ordering. The zpos value of the PRIMARY plane relative to OVERLAYS, for example, as a way for vendors to communicate overlay, underlay, or mixed-arrangement support. I don't think allowing OVERLAYs to be placed under the PRIMARY is currently documented as a way to support underlay. I always thought it's obvious that the zpos numbers dictate the plane order without any other rules. After all, we have the universal planes concept, where the plane type is only informational to aid heuristics rather than defining anything. Only if the zpos property does not exist, the plane types would come into play. Of course, if there actually exists userspace that fails if zpos allows an overlay type plane to be placed below primary, or fails if primary zpos is not zero, then DRM needs a new client cap. Right, it wasn't immediately clear to me that the API allowed placement of things beneath the PRIMARY. But reading the docs for drm_plane_create_zpos*, there's nothing that forbids it. libliftoff for example, assumes that the PRIMARY has the lowest zpos. So underlay arrangements will use an OVERLAY for the scanout plane, and the PRIMARY for the underlay view. That's totally ok. It works, right? Plane type does not matter if the KMS driver accepts the configuration. What is a "scanout plane"? Aren't all KMS planes by definition scanout planes? Pardon my terminology, I thought the scanout plane was where weston rendered non-offloadable surfaces to. I guess it's more correct to call it the "render plane". On weston, it seems to be always assigned to the PRIMARY. For libliftoff, using OVERLAYs as the render plane and PRIMARY as the underlay plane would work. But I think keeping the render plane on PRIMARY (a la weston) makes underlay arrangements easier to allocate, and would be nice to incorporate into a shared algorithm. In an underlay arrangement, pushing down an OVERLAY's zpos below the PRIMARY's zpos is simpler than swapping their surfaces. If such an arrangement fails atomic_test, we won't have to worry about swapping the surfaces back. Of course, it's not that we can't keep track of that in the algorithm, but I think it does make things easier. It may help with reducing the amount of atomic tests. Assuming that the same DRM plane provides the same format/color management/transformation support regardless of it's zpos, we should be able to reasonably expect that changing it's z-ordering will not cause atomic_test failures (or at least, expect less causes for failure). In other words, swapping the render plane from the PRIMARY to an OVERLAY might have more causes for an atomic_test fail, versus changing their z-ordering. The driver might have to do more things under-the-hood to provide this consistent behavior, but I think that's the right place for it. After all, drivers should know more about their hardware's behavior. The assumption that the PRIMARY has the lowest zpos isn't always true. I was made aware that the imx8mq platform places all of their OVERLAYS beneath the PRIMARY. Granted, the KMS code for enabling OVERLAYS is not upstream yet, but it is available from this thread: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1258#note_2319898 . I guess this is more of a bad assumption that should be fixed in libliftoff. IOW, if the KMS client understands zpos and can do a proper KMS configuration search, and all planes have zpos property, then there is no need to look at the plane type at all. That is the goal of the universal planes feature. The optimal configuration with DCN hardware is using underlays. E.g., the desktop plane would be at the top and would have holes cut out of it for videos or windows that want their own plane. If you do it the other way around, there are lots of limitations. Alex Right, patch 1/2 tries to work around one of these limitations (cursor-on-yuv). Others have mentioned we can do the same for scaling. Thanks, Leo Thanks, pq
Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible
On 2024-04-12 04:03, Pekka Paalanen wrote: On Thu, 11 Apr 2024 16:33:57 -0400 Leo Li wrote: On 2024-04-04 10:22, Marius Vlad wrote: On Thu, Apr 04, 2024 at 09:59:03AM -0400, Harry Wentland wrote: Hi all, On 2024-04-04 06:24, Pekka Paalanen wrote: On Wed, 3 Apr 2024 17:32:46 -0400 Leo Li wrote: On 2024-03-28 10:33, Pekka Paalanen wrote: On Fri, 15 Mar 2024 13:09:56 -0400 wrote: From: Leo Li These patches aim to make the amdgpgu KMS driver play nicer with compositors when building multi-plane scanout configurations. They do so by: 1. Making cursor behavior more sensible. 2. Allowing placement of DRM OVERLAY planes underneath the PRIMARY plane for 'underlay' configurations (perhaps more of a RFC, see below). Please see the commit messages for details. For #2, the simplest way to accomplish this was to increase the value of the immutable zpos property for the PRIMARY plane. This allowed OVERLAY planes with a mutable zpos range of (0-254) to be positioned underneath the PRIMARY for an underlay scanout configuration. Technically speaking, DCN hardware does not have a concept of primary or overlay planes - there are simply 4 general purpose hardware pipes that can be maped in any configuration. So the immutable zpos restriction on the PRIMARY plane is kind of arbitrary; it can have a mutable range of (0-254) just like the OVERLAYs. The distinction between PRIMARY and OVERLAY planes is also somewhat arbitrary. We can interpret PRIMARY as the first plane that should be enabled on a CRTC, but beyond that, it doesn't mean much for amdgpu. Therefore, I'm curious about how compositors devs understand KMS planes and their zpos properties, and how we would like to use them. It isn't clear to me how compositors wish to interpret and use the DRM zpos property, or differentiate between OVERLAY and PRIMARY planes, when it comes to setting up multi-plane scanout. You already quoted me on the Weston link, so I don't think I have anything to add. Sounds fine to me, and we don't have a standard plane arrangement algorithm that the kernel could optimize zpos ranges against, yet. Ultimately, what I'd like to answer is "What can we do on the KMS driver and DRM plane API side, that can make building multi-plane scanout configurations easier for compositors?" I'm hoping we can converge on something, whether that be updating the existing documentation to better define the usage, or update the API to provide support for something that is lacking. I think there probably should be a standardised plane arrangement algorithm in userspace, because the search space suffers from permutational explosion. Either there needs to be very few planes (max 4 or 5 at-all-possible per CRTC, including shareable ones) for an exhaustive search to be feasible, or all planes should be more or less equal in capabilities and userspace employs some simplified or heuristic search. If the search algorithm is fixed, then drivers could optimize zpos ranges to have the algorithm find a solution faster. My worry is that userspace already has heuristic search algorithms that may start failing if drivers later change their zpos ranges to be more optimal for another algorithm. OTOH, as long as exhaustive search is feasible, then it does not matter how DRM drivers set up the zpos ranges. In any case, the zpos ranges should try to allow all possible plane arrangements while minimizing the number of arrangements that won't work. The absolute values of zpos are pretty much irrelevant, so I think setting one plane to have an immutable zpos is a good idea, even if it's not necessary by the driver. That is one less moving part, and only the relative ordering between the planes matters. Thanks, pq Right, thanks for your thoughts! I agree that there should be a common plane arrangement algorithm. I think libliftoff is the most obvious candidate here. It only handles overlay arrangements currently, but mixed-mode arrangements is something I've been trying to look at. Taking the driver's reported zpos into account could narrow down the search space for mixed arrangements. We could tell whether underlay, or overlay, or both, is supported by looking at the allowed zpos ranges. I also wonder if it'll make underlay assignments easier. libliftoff has an assumption that the PRIMARY plane has the lowest zpos (which now I realize, is not always true). Therefore, the underlay buffer has to be placed on the PRIMARY, with the render buffer on a higher OVERLAY. Swapping buffers between planes when testing mixed-arrangements is kind of awkward, and simply setting the OVERLAY's zpos to be lower or higher than the PRIMARY's sounds simpler. Currently only gamescope makes use of libliftoff, but I'm curious if patches hooking it up to Weston would be welcomed? If there are other ways to have a common arrangement algorithm, I'd be happy to hear that as well. A natural thing would be to document such an algorithm wi
Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible
On 2024-04-04 10:22, Marius Vlad wrote: On Thu, Apr 04, 2024 at 09:59:03AM -0400, Harry Wentland wrote: Hi all, On 2024-04-04 06:24, Pekka Paalanen wrote: On Wed, 3 Apr 2024 17:32:46 -0400 Leo Li wrote: On 2024-03-28 10:33, Pekka Paalanen wrote: On Fri, 15 Mar 2024 13:09:56 -0400 wrote: From: Leo Li These patches aim to make the amdgpgu KMS driver play nicer with compositors when building multi-plane scanout configurations. They do so by: 1. Making cursor behavior more sensible. 2. Allowing placement of DRM OVERLAY planes underneath the PRIMARY plane for 'underlay' configurations (perhaps more of a RFC, see below). Please see the commit messages for details. For #2, the simplest way to accomplish this was to increase the value of the immutable zpos property for the PRIMARY plane. This allowed OVERLAY planes with a mutable zpos range of (0-254) to be positioned underneath the PRIMARY for an underlay scanout configuration. Technically speaking, DCN hardware does not have a concept of primary or overlay planes - there are simply 4 general purpose hardware pipes that can be maped in any configuration. So the immutable zpos restriction on the PRIMARY plane is kind of arbitrary; it can have a mutable range of (0-254) just like the OVERLAYs. The distinction between PRIMARY and OVERLAY planes is also somewhat arbitrary. We can interpret PRIMARY as the first plane that should be enabled on a CRTC, but beyond that, it doesn't mean much for amdgpu. Therefore, I'm curious about how compositors devs understand KMS planes and their zpos properties, and how we would like to use them. It isn't clear to me how compositors wish to interpret and use the DRM zpos property, or differentiate between OVERLAY and PRIMARY planes, when it comes to setting up multi-plane scanout. You already quoted me on the Weston link, so I don't think I have anything to add. Sounds fine to me, and we don't have a standard plane arrangement algorithm that the kernel could optimize zpos ranges against, yet. Ultimately, what I'd like to answer is "What can we do on the KMS driver and DRM plane API side, that can make building multi-plane scanout configurations easier for compositors?" I'm hoping we can converge on something, whether that be updating the existing documentation to better define the usage, or update the API to provide support for something that is lacking. I think there probably should be a standardised plane arrangement algorithm in userspace, because the search space suffers from permutational explosion. Either there needs to be very few planes (max 4 or 5 at-all-possible per CRTC, including shareable ones) for an exhaustive search to be feasible, or all planes should be more or less equal in capabilities and userspace employs some simplified or heuristic search. If the search algorithm is fixed, then drivers could optimize zpos ranges to have the algorithm find a solution faster. My worry is that userspace already has heuristic search algorithms that may start failing if drivers later change their zpos ranges to be more optimal for another algorithm. OTOH, as long as exhaustive search is feasible, then it does not matter how DRM drivers set up the zpos ranges. In any case, the zpos ranges should try to allow all possible plane arrangements while minimizing the number of arrangements that won't work. The absolute values of zpos are pretty much irrelevant, so I think setting one plane to have an immutable zpos is a good idea, even if it's not necessary by the driver. That is one less moving part, and only the relative ordering between the planes matters. Thanks, pq Right, thanks for your thoughts! I agree that there should be a common plane arrangement algorithm. I think libliftoff is the most obvious candidate here. It only handles overlay arrangements currently, but mixed-mode arrangements is something I've been trying to look at. Taking the driver's reported zpos into account could narrow down the search space for mixed arrangements. We could tell whether underlay, or overlay, or both, is supported by looking at the allowed zpos ranges. I also wonder if it'll make underlay assignments easier. libliftoff has an assumption that the PRIMARY plane has the lowest zpos (which now I realize, is not always true). Therefore, the underlay buffer has to be placed on the PRIMARY, with the render buffer on a higher OVERLAY. Swapping buffers between planes when testing mixed-arrangements is kind of awkward, and simply setting the OVERLAY's zpos to be lower or higher than the PRIMARY's sounds simpler. Currently only gamescope makes use of libliftoff, but I'm curious if patches hooking it up to Weston would be welcomed? If there are other ways to have a common arrangement algorithm, I'd be happy to hear that as well. A natural thing would be to document such an algorithm with the KMS UAPI. I don't know libliftoff well enough to say how welcome it would be in Weston. I have no f
Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible
On 2024-03-28 10:33, Pekka Paalanen wrote: On Fri, 15 Mar 2024 13:09:56 -0400 wrote: From: Leo Li These patches aim to make the amdgpgu KMS driver play nicer with compositors when building multi-plane scanout configurations. They do so by: 1. Making cursor behavior more sensible. 2. Allowing placement of DRM OVERLAY planes underneath the PRIMARY plane for 'underlay' configurations (perhaps more of a RFC, see below). Please see the commit messages for details. For #2, the simplest way to accomplish this was to increase the value of the immutable zpos property for the PRIMARY plane. This allowed OVERLAY planes with a mutable zpos range of (0-254) to be positioned underneath the PRIMARY for an underlay scanout configuration. Technically speaking, DCN hardware does not have a concept of primary or overlay planes - there are simply 4 general purpose hardware pipes that can be maped in any configuration. So the immutable zpos restriction on the PRIMARY plane is kind of arbitrary; it can have a mutable range of (0-254) just like the OVERLAYs. The distinction between PRIMARY and OVERLAY planes is also somewhat arbitrary. We can interpret PRIMARY as the first plane that should be enabled on a CRTC, but beyond that, it doesn't mean much for amdgpu. Therefore, I'm curious about how compositors devs understand KMS planes and their zpos properties, and how we would like to use them. It isn't clear to me how compositors wish to interpret and use the DRM zpos property, or differentiate between OVERLAY and PRIMARY planes, when it comes to setting up multi-plane scanout. You already quoted me on the Weston link, so I don't think I have anything to add. Sounds fine to me, and we don't have a standard plane arrangement algorithm that the kernel could optimize zpos ranges against, yet. Ultimately, what I'd like to answer is "What can we do on the KMS driver and DRM plane API side, that can make building multi-plane scanout configurations easier for compositors?" I'm hoping we can converge on something, whether that be updating the existing documentation to better define the usage, or update the API to provide support for something that is lacking. I think there probably should be a standardised plane arrangement algorithm in userspace, because the search space suffers from permutational explosion. Either there needs to be very few planes (max 4 or 5 at-all-possible per CRTC, including shareable ones) for an exhaustive search to be feasible, or all planes should be more or less equal in capabilities and userspace employs some simplified or heuristic search. If the search algorithm is fixed, then drivers could optimize zpos ranges to have the algorithm find a solution faster. My worry is that userspace already has heuristic search algorithms that may start failing if drivers later change their zpos ranges to be more optimal for another algorithm. OTOH, as long as exhaustive search is feasible, then it does not matter how DRM drivers set up the zpos ranges. In any case, the zpos ranges should try to allow all possible plane arrangements while minimizing the number of arrangements that won't work. The absolute values of zpos are pretty much irrelevant, so I think setting one plane to have an immutable zpos is a good idea, even if it's not necessary by the driver. That is one less moving part, and only the relative ordering between the planes matters. Thanks, pq Right, thanks for your thoughts! I agree that there should be a common plane arrangement algorithm. I think libliftoff is the most obvious candidate here. It only handles overlay arrangements currently, but mixed-mode arrangements is something I've been trying to look at. Taking the driver's reported zpos into account could narrow down the search space for mixed arrangements. We could tell whether underlay, or overlay, or both, is supported by looking at the allowed zpos ranges. I also wonder if it'll make underlay assignments easier. libliftoff has an assumption that the PRIMARY plane has the lowest zpos (which now I realize, is not always true). Therefore, the underlay buffer has to be placed on the PRIMARY, with the render buffer on a higher OVERLAY. Swapping buffers between planes when testing mixed-arrangements is kind of awkward, and simply setting the OVERLAY's zpos to be lower or higher than the PRIMARY's sounds simpler. Currently only gamescope makes use of libliftoff, but I'm curious if patches hooking it up to Weston would be welcomed? If there are other ways to have a common arrangement algorithm, I'd be happy to hear that as well. Note that libliftoff's algorithm is more complex than weston, since it searches harder, and suffers from that permutational explosion. But it solves that by trying high benefit arrangements first (offloading surfaces that update frequently), and bailing out once the search reaches a hard-coded deadline. Since it's currently overlay-only, the goal could be to "simply" have no
Re: [PATCH 1/2] drm/amd/display: Introduce overlay cursor mode
On 2024-03-28 11:52, Harry Wentland wrote:
On 2024-03-28 11:48, Robert Mader wrote:
Hi,
On 15.03.24 18:09, sunpeng...@amd.com wrote:
From: Leo Li
[Why]
DCN is the display hardware for amdgpu. DRM planes are backed by DCN
hardware pipes, which carry pixel data from one end (memory), to the
other (output encoder).
Each DCN pipe has the ability to blend in a cursor early on in the
pipeline. In other words, there are no dedicated cursor planes in DCN,
which makes cursor behavior somewhat unintuitive for compositors.
For example, if the cursor is in RGB format, but the top-most DRM plane
is in YUV format, DCN will not be able to blend them. Because of this,
amdgpu_dm rejects all configurations where a cursor needs to be enabled
on top of a YUV formatted plane.
From a compositor's perspective, when computing an allocation for
hardware plane offloading, this cursor-on-yuv configuration result in an
atomic test failure. Since the failure reason is not obvious at all,
compositors will likely fall back to full rendering, which is not ideal.
Instead, amdgpu_dm can try to accommodate the cursor-on-yuv
configuration by opportunistically reserving a separate DCN pipe just
for the cursor. We can refer to this as "overlay cursor mode". It is
contrasted with "native cursor mode", where the native DCN per-pipe
cursor is used.
[How]
On each crtc, compute whether the cursor plane should be enabled in
overlay mode (which currently, is iff the immediate plane below has a
YUV format). If it is, mark the CRTC as requesting overlay cursor mode.
iff -> if
IIRC another case where this would be needed is when the scale of the plane
below doesn't match the cursor scale. This is especially common for videos and
thus implicitly covered by the YUV check in most cases, but should probably be
made explicit. Michel Dänzer might be able to comment here.
Another possible case that could be covered here is when some area is not
covered by any plane and just shows a black background. This happens e.g. if a
compositor puts a YUV surface on the primary plane that has a different
width/high ratio than the display. The compositor can add black bars by just
leaving the area uncovered and thus require only a single hardware plane for
video playback ("Unless explicitly specified (..), the active area of a CRTC
will be black by default."
https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#plane-abstraction). If
the cursor is visible over this black bars, AMD currently refuses the commit
IIUC (see also Michel Dänzers comment at
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3177#note_1924544)
Thanks for mentioning both of these scenarios. I agree it would be
good if we can expand the use of the overlay cursor to these cases.
Harry
Thanks,
Robert Mader
All good points, thanks for the feedback. I'll take a peek at the scaling + no
underlying plane case and send a v2 when I get around to it.
Leo
During DC validation, attempt to enable a separate DCN pipe for the
cursor if it's in overlay mode. If that fails, or if no overlay mode is
requested, then fallback to native mode.
Signed-off-by: Leo Li
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 309 +++---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 7 +
.../amd/display/amdgpu_dm/amdgpu_dm_crtc.c | 1 +
.../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 13 +-
4 files changed, 288 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 21a61454c878..09ab330aed17 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -8359,8 +8359,19 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
* Disable the cursor first if we're disabling all the planes.
* It'll remain on the screen after the planes are re-enabled
* if we don't.
+ *
+ * If the cursor is transitioning from native to overlay mode, the
+ * native cursor needs to be disabled first.
*/
- if (acrtc_state->active_planes == 0)
+ if (acrtc_state->cursor_mode == DM_CURSOR_OVERLAY_MODE &&
+ dm_old_crtc_state->cursor_mode == DM_CURSOR_NATIVE_MODE) {
+ struct dc_cursor_position cursor_position = {0};
+ dc_stream_set_cursor_position(acrtc_state->stream,
+ _position);
+ }
+
+ if (acrtc_state->active_planes == 0 &&
+ dm_old_crtc_state->cursor_mode == DM_CURSOR_NATIVE_MODE)
amdgpu_dm_commit_cursors(state);
/* update planes when needed */
@@ -8374,7 +8385,8 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
struct dm_plane_state *dm_new_plane_state =
to_dm_plane_state(new_plane_state);
/* Cursor plane is handled after stream updates */
- i
RE: [PATCH v2 3/3] drm/amdgpu/jpeg: support for sriov cpx mode
[AMD Official Use Only - General]
Reviewed-by: Leo Liu
> -Original Message-
> From: Dhume, Samir
> Sent: Friday, March 15, 2024 3:51 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Dhume, Samir ; Lazar, Lijo
> ; Wan, Gavin ; Liu, Leo
> ; Deucher, Alexander
> Subject: [PATCH v2 3/3] drm/amdgpu/jpeg: support for sriov cpx mode
>
> In SRIOV CPX mode, each VF has 4 jpeg engines. The even- numbered VFs point
> to JPEG0 block of the AID and the odd- numbered VFs point to the JPEG1 block.
>
> Even-numbered VFs Odd numbered VFs
>
> VCN doorbell 0 VCN Decode ring VCN Decode ring
> VCN doorbell 1-3 Reserved Reserved
> VCN doorbell 4JPEG0-0 ring
> VCN doorbell 5JPEG0-1 ring
> VCN doorbell 6JPEG0-2 ring
> VCN doorbell 7JPEG0-3 ring
> VCN doorbell 8JPEG1-0 ring
> VCN doorbell 9JPEG1-1 ring
> VCN doorbell 10 JPEG1-2 ring
> VCN doorbell 11 JPEG1-3 ring
>
> Changes involve
> 1. sriov cpx mode - 4 rings
> 2. sriov cpx mode for odd numbered VFs - register correct src-ids (starting
> with
> JPEG4). Map src-id to correct instance in interrupt- handler.
>
> v2:
> 1. removed mmio access from interrupt handler. Use xcc_mask to detect cpx
> mode.
> 2. remove unneccessary sriov variables
>
> Signed-off-by: Samir Dhume
> ---
> drivers/gpu/drm/amd/amdgpu/jpeg_v4_0_3.c | 60 +-
> --
> 1 file changed, 53 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/jpeg_v4_0_3.c
> b/drivers/gpu/drm/amd/amdgpu/jpeg_v4_0_3.c
> index 32caeb37cef9..d95ca797412c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/jpeg_v4_0_3.c
> +++ b/drivers/gpu/drm/amd/amdgpu/jpeg_v4_0_3.c
> @@ -68,6 +68,11 @@ static int jpeg_v4_0_3_early_init(void *handle)
>
> adev->jpeg.num_jpeg_rings = AMDGPU_MAX_JPEG_RINGS;
>
> + /* check for sriov cpx mode */
> + if (amdgpu_sriov_vf(adev))
> + if (adev->gfx.xcc_mask == 0x1)
> + adev->jpeg.num_jpeg_rings = 4;
> +
> jpeg_v4_0_3_set_dec_ring_funcs(adev);
> jpeg_v4_0_3_set_irq_funcs(adev);
> jpeg_v4_0_3_set_ras_funcs(adev);
> @@ -87,11 +92,25 @@ static int jpeg_v4_0_3_sw_init(void *handle)
> struct amdgpu_device *adev = (struct amdgpu_device *)handle;
> struct amdgpu_ring *ring;
> int i, j, r, jpeg_inst;
> + bool sriov_cpx_odd = false;
> +
> + /* check for sriov cpx mode odd/even numbered vfs */
> + if (amdgpu_sriov_vf(adev)) {
> + if (adev->gfx.xcc_mask == 0x1) {
> + if (adev->gfx.funcs->get_xcc_id(adev, 0) & 0x1)
> + sriov_cpx_odd = true;
> + }
> + }
>
> for (j = 0; j < adev->jpeg.num_jpeg_rings; ++j) {
> /* JPEG TRAP */
> - r = amdgpu_irq_add_id(adev, SOC15_IH_CLIENTID_VCN,
> + if (!sriov_cpx_odd)
> + r = amdgpu_irq_add_id(adev,
> SOC15_IH_CLIENTID_VCN,
> amdgpu_ih_srcid_jpeg[j], >jpeg.inst-
> >irq);
> + else
> + r = amdgpu_irq_add_id(adev,
> SOC15_IH_CLIENTID_VCN,
> + amdgpu_ih_srcid_jpeg[j+4], >jpeg.inst-
> >irq);
> +
> if (r)
> return r;
> }
> @@ -116,10 +135,14 @@ static int jpeg_v4_0_3_sw_init(void *handle)
> (adev-
> >doorbell_index.vcn.vcn_ring0_1 << 1) +
> 1 + j + 9 * jpeg_inst;
> } else {
> - if (j < 4)
> + if ((j < 4) && (!sriov_cpx_odd))
> ring->doorbell_index =
> (adev-
> >doorbell_index.vcn.vcn_ring0_1 << 1) +
> 4 + j + 32 * jpeg_inst;
> + else if (sriov_cpx_odd)
> + ring->doorbell_index =
> + (adev-
> >doorbell_index.vcn.vcn_ring0_1 << 1) +
> + 12 + j + 32 * jpeg_inst;
> else
> ring->doorbell_index =
> (adev-
> >doorbell_index.vcn.vcn_ring0_1 << 1) + @@ -186,6 +209,7 @@ static int
> jpeg_v4_0_3_start_sriov(struct amdgpu_device *a
RE: [PATCH 3/3] drm/amdgpu/jpeg: support for sriov cpx mode
[AMD Official Use Only - General]
> -Original Message-
> From: Dhume, Samir
> Sent: Monday, March 4, 2024 10:20 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Dhume, Samir ; Lazar, Lijo
> ; Wan, Gavin ; Liu, Leo
> ; Deucher, Alexander
> Subject: [PATCH 3/3] drm/amdgpu/jpeg: support for sriov cpx mode
>
> Signed-off-by: Samir Dhume
> ---
> drivers/gpu/drm/amd/amdgpu/jpeg_v4_0_3.c | 80 +-
> --
> 1 file changed, 73 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/jpeg_v4_0_3.c
> b/drivers/gpu/drm/amd/amdgpu/jpeg_v4_0_3.c
> index 32caeb37cef9..4bf087f8ca2b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/jpeg_v4_0_3.c
> +++ b/drivers/gpu/drm/amd/amdgpu/jpeg_v4_0_3.c
> @@ -65,9 +65,15 @@ static int amdgpu_ih_srcid_jpeg[] = { static int
> jpeg_v4_0_3_early_init(void *handle) {
> struct amdgpu_device *adev = (struct amdgpu_device *)handle;
> + struct amdgpu_xcp_mgr *xcp_mgr = adev->xcp_mgr;
In general, to make the path clear, can we define and use the SRIOV specific
variables and function within "amdgpu_sriov_vf()" ?
Regards,
Leo
>
> adev->jpeg.num_jpeg_rings = AMDGPU_MAX_JPEG_RINGS;
>
> + if (amdgpu_sriov_vf(adev))
> + if (adev->xcp_mgr->funcs->query_partition_mode(xcp_mgr) ==
> + AMDGPU_CPX_PARTITION_MODE)
> + adev->jpeg.num_jpeg_rings = 4;
> +
> jpeg_v4_0_3_set_dec_ring_funcs(adev);
> jpeg_v4_0_3_set_irq_funcs(adev);
> jpeg_v4_0_3_set_ras_funcs(adev);
> @@ -88,10 +94,28 @@ static int jpeg_v4_0_3_sw_init(void *handle)
> struct amdgpu_ring *ring;
> int i, j, r, jpeg_inst;
>
> + bool sriov_cpx_odd = false;
> + struct amdgpu_xcp_mgr *xcp_mgr = adev->xcp_mgr;
> + int mode;
> +
> + if (amdgpu_sriov_vf(adev)) {
> + mode = xcp_mgr->funcs->query_partition_mode(xcp_mgr);
> +
> + if (mode == AMDGPU_CPX_PARTITION_MODE) {
> + if (adev->gfx.funcs->get_xcc_id(adev, 0) & 0x1)
> + sriov_cpx_odd = true;
> + }
> + }
> +
> for (j = 0; j < adev->jpeg.num_jpeg_rings; ++j) {
> /* JPEG TRAP */
> - r = amdgpu_irq_add_id(adev, SOC15_IH_CLIENTID_VCN,
> + if (!sriov_cpx_odd)
> + r = amdgpu_irq_add_id(adev,
> SOC15_IH_CLIENTID_VCN,
> amdgpu_ih_srcid_jpeg[j], >jpeg.inst-
> >irq);
> + else
> + r = amdgpu_irq_add_id(adev,
> SOC15_IH_CLIENTID_VCN,
> + amdgpu_ih_srcid_jpeg[j+4], >jpeg.inst-
> >irq);
> +
> if (r)
> return r;
> }
> @@ -116,10 +140,15 @@ static int jpeg_v4_0_3_sw_init(void *handle)
> (adev-
> >doorbell_index.vcn.vcn_ring0_1 << 1) +
> 1 + j + 9 * jpeg_inst;
> } else {
> - if (j < 4)
> + if ((j < 4) && (!sriov_cpx_odd))
> ring->doorbell_index =
> (adev-
> >doorbell_index.vcn.vcn_ring0_1 << 1) +
> 4 + j + 32 * jpeg_inst;
> + else if (sriov_cpx_odd)
> + ring->doorbell_index =
> + (adev-
> >doorbell_index.vcn.vcn_ring0_1 << 1) +
> + 12 + j + 32 * jpeg_inst;
> +
> else
> ring->doorbell_index =
> (adev-
> >doorbell_index.vcn.vcn_ring0_1 << 1) + @@ -186,6 +215,9 @@ static int
> jpeg_v4_0_3_start_sriov(struct amdgpu_device *adev)
> uint32_t size, size_dw, item_offset;
> uint32_t init_status;
> int i, j, jpeg_inst;
> + struct amdgpu_xcp_mgr *xcp_mgr = adev->xcp_mgr;
> + int mode;
> + bool cpx_odd = false;
>
> struct mmsch_v4_0_cmd_direct_write
> direct_wt = { {0} };
> @@ -197,6 +229,13 @@ static int jpeg_v4_0_3_start_sriov(struct
> amdgpu_device *adev)
> end.cmd_header.command_type =
> MMSCH_COMMAND__END;
>
> + mode = xcp_mgr->funcs->query_partition_mode(xcp_mgr);
> +
> + if (mode == AMDGPU_CPX_PARTITION_MODE) {
> + if (adev->gfx.funcs->get_xcc_id(adev, 0) & 0x1)
> +
RE: [PATCH 4/4] drm/amdgpu: add vcn 4.0.6 discovery support
[AMD Official Use Only - General] The series of 4 patches are: Reviewed-by: Leo Liu > -Original Message- > From: amd-gfx On Behalf Of Alex > Deucher > Sent: Wednesday, February 21, 2024 12:00 PM > To: amd-gfx@lists.freedesktop.org > Cc: Zhang, Yifan ; Deucher, Alexander > > Subject: [PATCH 4/4] drm/amdgpu: add vcn 4.0.6 discovery support > > From: Yifan Zhang > > This patch is to add vcn 4.0.6 support > > Signed-off-by: Yifan Zhang > Signed-off-by: Alex Deucher > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c > index 704b7820c47c..6e4d26753aac 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c > @@ -2140,6 +2140,7 @@ static int > amdgpu_discovery_set_mm_ip_blocks(struct amdgpu_device *adev) > amdgpu_device_ip_block_add(adev, > _v4_0_3_ip_block); > break; > case IP_VERSION(4, 0, 5): > + case IP_VERSION(4, 0, 6): > amdgpu_device_ip_block_add(adev, > _v4_0_5_ip_block); > amdgpu_device_ip_block_add(adev, > _v4_0_5_ip_block); > break; > -- > 2.43.2
RE: [PATCH] drm/amd/amdgpu: Clean up VCN fw_shared and set flag bits during hw_init
[AMD Official Use Only - General]
> -Original Message-
> From: amd-gfx On Behalf Of
> Bokun Zhang
> Sent: Tuesday, November 28, 2023 4:25 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Zhang, Bokun
> Subject: [PATCH] drm/amd/amdgpu: Clean up VCN fw_shared and set flag
> bits during hw_init
>
> - After whole GPU reset, the VCN fw_shared data is cleaned up.
> This seems like a new behavior and it is considered safer since
> we do not want to keep the residual data
>
> - However, the existing driver code still assumes the residual data.
> For example, in sw_init, we will set the UNIFIED_QUEUE flag bit.
> This flag bit is never set anywhere else.
>
> Then if a WGR happens, sw_init will not be called and therefore,
> we will lose this bit and it leads to a crash in VCN FW.
>
> - A proper fix is that we explicitly set the flag bit in hw_init
> every time and the data is repopulated after a WGR instead of
> assuming the data can survive the WGR.
>
I think this is part of sw_init, along with loading fw. Should not be in the
hw_init. I think you probably can try to save it to a saved_bo when suspend,
and copy back when resume, same way as for FW.
Regards,
Leo
> Signed-off-by: Bokun Zhang
> Change-Id: I783ff826f12e12eaf48d046ff9f1cef65558c7b9
> ---
> drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c | 45 +--
> 1 file changed, 28 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
> b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
> index bf07aa200030..0cf3e639c480 100644
> --- a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
> @@ -111,6 +111,7 @@ static int vcn_v4_0_sw_init(void *handle) {
> struct amdgpu_ring *ring;
> struct amdgpu_device *adev = (struct amdgpu_device *)handle;
> + volatile struct amdgpu_vcn4_fw_shared *fw_shared;
> int i, r;
>
> r = amdgpu_vcn_sw_init(adev);
> @@ -124,11 +125,12 @@ static int vcn_v4_0_sw_init(void *handle)
> return r;
>
> for (i = 0; i < adev->vcn.num_vcn_inst; i++) {
> - volatile struct amdgpu_vcn4_fw_shared *fw_shared;
> -
> if (adev->vcn.harvest_config & (1 << i))
> continue;
>
> + fw_shared = adev->vcn.inst[i].fw_shared.cpu_addr;
> + memset(fw_shared, 0, sizeof(struct
> amdgpu_vcn4_fw_shared));
> +
> /* Init instance 0 sched_score to 1, so it's scheduled after
> other instances */
> if (i == 0)
> atomic_set(>vcn.inst[i].sched_score, 1); @@ -
> 161,21 +163,6 @@ static int vcn_v4_0_sw_init(void *handle)
> if (r)
> return r;
>
> - fw_shared = adev->vcn.inst[i].fw_shared.cpu_addr;
> - fw_shared->present_flag_0 =
> cpu_to_le32(AMDGPU_FW_SHARED_FLAG_0_UNIFIED_QUEUE);
> - fw_shared->sq.is_enabled = 1;
> -
> - fw_shared->present_flag_0 |=
> cpu_to_le32(AMDGPU_VCN_SMU_DPM_INTERFACE_FLAG);
> - fw_shared->smu_dpm_interface.smu_interface_type = (adev-
> >flags & AMD_IS_APU) ?
> - AMDGPU_VCN_SMU_DPM_INTERFACE_APU :
> AMDGPU_VCN_SMU_DPM_INTERFACE_DGPU;
> -
> - if (amdgpu_ip_version(adev, VCN_HWIP, 0) ==
> - IP_VERSION(4, 0, 2)) {
> - fw_shared->present_flag_0 |=
> AMDGPU_FW_SHARED_FLAG_0_DRM_KEY_INJECT;
> - fw_shared->drm_key_wa.method =
> -
> AMDGPU_DRM_KEY_INJECT_WORKAROUND_VCNFW_ASD_HANDSH
> AKING;
> - }
> -
> if (amdgpu_vcnfw_log)
> amdgpu_vcn_fwlog_init(>vcn.inst[i]);
> }
> @@ -245,9 +232,33 @@ static int vcn_v4_0_sw_fini(void *handle) static int
> vcn_v4_0_hw_init(void *handle) {
> struct amdgpu_device *adev = (struct amdgpu_device *)handle;
> + volatile struct amdgpu_vcn4_fw_shared *fw_shared;
> struct amdgpu_ring *ring;
> int i, r;
>
> + for (i = 0; i < adev->vcn.num_vcn_inst; i++) {
> + if (adev->vcn.harvest_config & (1 << i))
> + continue;
> +
> + fw_shared = adev->vcn.inst[i].fw_shared.cpu_addr;
> + fw_shared->present_flag_0 |=
> cpu_to_le32(AMDGPU_FW_SHARED_FLAG_0_UNIFIED_QUEUE);
> + fw_shared->sq.is_enabled = 1;
> +
> + fw_shared->present_flag_0 |=
> cpu_to_le32(AMDGPU_VCN_SMU_DPM_INTERFACE_FLAG);
> + fw_shared->smu_dpm_interface.smu_interface_type = (adev-
> >flags & AMD_IS_APU) ?
&g
Re: [PATCH v4 4/4] drm/amd/amdgpu/vcn: Add RB decouple feature under SRIOV - P4
The set looks good to me. The series is:
Reviewed-by: Leo Liu
On 2023-10-16 12:54, Bokun Zhang wrote:
- In VCN 4 SRIOV code path, add code to enable RB decouple feature
Signed-off-by: Bokun Zhang
---
drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c | 71 +--
1 file changed, 55 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
index 88e17f5e20b2..bf07aa200030 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
@@ -176,9 +176,6 @@ static int vcn_v4_0_sw_init(void *handle)
AMDGPU_DRM_KEY_INJECT_WORKAROUND_VCNFW_ASD_HANDSHAKING;
}
- if (amdgpu_sriov_vf(adev))
- fw_shared->present_flag_0 |=
cpu_to_le32(AMDGPU_VCN_VF_RB_SETUP_FLAG);
-
if (amdgpu_vcnfw_log)
amdgpu_vcn_fwlog_init(>vcn.inst[i]);
}
@@ -1209,6 +1206,24 @@ static int vcn_v4_0_start(struct amdgpu_device *adev)
return 0;
}
+static int vcn_v4_0_init_ring_metadata(struct amdgpu_device *adev, uint32_t vcn_inst, struct amdgpu_ring *ring_enc)
+{
+ struct amdgpu_vcn_rb_metadata *rb_metadata = NULL;
+ uint8_t *rb_ptr = (uint8_t *)ring_enc->ring;
+
+ rb_ptr += ring_enc->ring_size;
+ rb_metadata = (struct amdgpu_vcn_rb_metadata *)rb_ptr;
+
+ memset(rb_metadata, 0, sizeof(struct amdgpu_vcn_rb_metadata));
+ rb_metadata->size = sizeof(struct amdgpu_vcn_rb_metadata);
+ rb_metadata->present_flag_0 |= cpu_to_le32(AMDGPU_VCN_VF_RB_SETUP_FLAG);
+ rb_metadata->present_flag_0 |=
cpu_to_le32(AMDGPU_VCN_VF_RB_DECOUPLE_FLAG);
+ rb_metadata->version = 1;
+ rb_metadata->ring_id = vcn_inst & 0xFF;
+
+ return 0;
+}
+
static int vcn_v4_0_start_sriov(struct amdgpu_device *adev)
{
int i;
@@ -1334,11 +1349,30 @@ static int vcn_v4_0_start_sriov(struct amdgpu_device
*adev)
rb_enc_addr = ring_enc->gpu_addr;
rb_setup->is_rb_enabled_flags |= RB_ENABLED;
- rb_setup->rb_addr_lo = lower_32_bits(rb_enc_addr);
- rb_setup->rb_addr_hi = upper_32_bits(rb_enc_addr);
- rb_setup->rb_size = ring_enc->ring_size / 4;
fw_shared->present_flag_0 |=
cpu_to_le32(AMDGPU_VCN_VF_RB_SETUP_FLAG);
+ if (amdgpu_sriov_is_vcn_rb_decouple(adev)) {
+ vcn_v4_0_init_ring_metadata(adev, i, ring_enc);
+
+ memset((void *)_setup->rb_info, 0, sizeof(struct
amdgpu_vcn_rb_setup_info) * MAX_NUM_VCN_RB_SETUP);
+ if (!(adev->vcn.harvest_config & (1 << 0))) {
+ rb_setup->rb_info[0].rb_addr_lo =
lower_32_bits(adev->vcn.inst[0].ring_enc[0].gpu_addr);
+ rb_setup->rb_info[0].rb_addr_hi =
upper_32_bits(adev->vcn.inst[0].ring_enc[0].gpu_addr);
+ rb_setup->rb_info[0].rb_size =
adev->vcn.inst[0].ring_enc[0].ring_size / 4;
+ }
+ if (!(adev->vcn.harvest_config & (1 << 1))) {
+ rb_setup->rb_info[2].rb_addr_lo =
lower_32_bits(adev->vcn.inst[1].ring_enc[0].gpu_addr);
+ rb_setup->rb_info[2].rb_addr_hi =
upper_32_bits(adev->vcn.inst[1].ring_enc[0].gpu_addr);
+ rb_setup->rb_info[2].rb_size =
adev->vcn.inst[1].ring_enc[0].ring_size / 4;
+ }
+ fw_shared->decouple.is_enabled = 1;
+ fw_shared->present_flag_0 |=
cpu_to_le32(AMDGPU_VCN_VF_RB_DECOUPLE_FLAG);
+ } else {
+ rb_setup->rb_addr_lo = lower_32_bits(rb_enc_addr);
+ rb_setup->rb_addr_hi = upper_32_bits(rb_enc_addr);
+ rb_setup->rb_size = ring_enc->ring_size / 4;
+ }
+
MMSCH_V4_0_INSERT_DIRECT_WT(SOC15_REG_OFFSET(VCN, i,
regUVD_LMI_VCPU_NC0_64BIT_BAR_LOW),
lower_32_bits(adev->vcn.inst[i].fw_shared.gpu_addr));
@@ -1810,6 +1844,7 @@ static struct amdgpu_ring_funcs
vcn_v4_0_unified_ring_vm_funcs = {
.type = AMDGPU_RING_TYPE_VCN_ENC,
.align_mask = 0x3f,
.nop = VCN_ENC_CMD_NO_OP,
+ .extra_dw = sizeof(struct amdgpu_vcn_rb_metadata),
.get_rptr = vcn_v4_0_unified_ring_get_rptr,
.get_wptr = vcn_v4_0_unified_ring_get_wptr,
.set_wptr = vcn_v4_0_unified_ring_set_wptr,
@@ -2023,16 +2058,20 @@ static int vcn_v4_0_process_interrupt(struct
amdgpu_device *adev, struct amdgpu_
{
uint32_t ip_instance;
- switch (entry->client_id) {
- case SOC15_IH_CLIENTID_VCN:
- ip_instance = 0;
- break;
- case SOC15_IH_CLIENTI
RE: [PATCH v3] drm/amd/amdgpu/vcn: Add RB decouple feature under SRIOV
[AMD Official Use Only - General]
> -Original Message-
> From: amd-gfx On Behalf Of
> Bokun Zhang
> Sent: Friday, October 13, 2023 1:43 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Zhang, Bokun
> Subject: [PATCH v3] drm/amd/amdgpu/vcn: Add RB decouple feature under
> SRIOV
>
> - Add code to enable RB decouple feature.
> This feature is controlled by SRIOV host.
> Once enabled, it allows VCN0's job to be remapped to
> VCN1 at hardware level and improves VCN availability
>
Since this is feature is only used by SRIOV, we need to make sure the changes
not affect BM path. Also please split the patch into multiple patches.
> Signed-off-by: Bokun Zhang
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 3 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h | 52 +--
> drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h| 4 ++
> drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h | 5 +-
> drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c | 71 -
> 5 files changed, 110 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> index f4963330c772..7e8c2dbb34fb 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> @@ -204,6 +204,9 @@ int amdgpu_vcn_sw_init(struct amdgpu_device
> *adev)
> adev->vcn.inst[i].fw_shared.gpu_addr = adev-
> >vcn.inst[i].gpu_addr +
> bo_size - fw_shared_size;
>
> + /* clean up fw share */
> + memset(adev->vcn.inst[i].fw_shared.cpu_addr, 0,
> fw_shared_size);
> +
>
This should be redundant, since it should be got cleared when allocation.
adev->vcn.inst[i].fw_shared.mem_size = fw_shared_size;
>
> if (amdgpu_vcnfw_log) {
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
> index 0815c5a97564..6935ab74f481 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
> @@ -169,6 +169,9 @@
> #define AMDGPU_VCN_SMU_VERSION_INFO_FLAG (1 << 11) #define
> AMDGPU_VCN_SMU_DPM_INTERFACE_FLAG (1 << 11) #define
> AMDGPU_VCN_VF_RB_SETUP_FLAG (1 << 14)
> +#define AMDGPU_VCN_VF_RB_DECOUPLE_FLAG (1 << 15)
> +
> +#define MAX_NUM_VCN_RB_SETUP 4
>
> #define AMDGPU_VCN_IB_FLAG_DECODE_BUFFER 0x0001
> #define AMDGPU_VCN_CMD_FLAG_MSG_BUFFER 0x0001
> @@ -335,22 +338,46 @@ struct amdgpu_fw_shared {
> struct amdgpu_fw_shared_smu_interface_info smu_interface_info; };
>
> +struct amdgpu_vcn_rb_setup_info
> +{
> +uint32_t rb_addr_lo;
> +uint32_t rb_addr_hi;
> +uint32_t rb_size;
> +};
> +
> struct amdgpu_fw_shared_rb_setup {
> uint32_t is_rb_enabled_flags;
> - uint32_t rb_addr_lo;
> - uint32_t rb_addr_hi;
> - uint32_t rb_size;
> - uint32_t rb4_addr_lo;
> - uint32_t rb4_addr_hi;
> - uint32_t rb4_size;
> - uint32_t reserved[6];
> +
> + union {
> + // 12 DWords
This can be removed.
> + struct {
> + uint32_t rb_addr_lo;
> + uint32_t rb_addr_hi;
> + uint32_t rb_size;
> + uint32_t rb4_addr_lo;
> + uint32_t rb4_addr_hi;
> + uint32_t rb4_size;
> + uint32_t reserved[6];
> + };
> +
> + // 12 DWords
Same here.
Regards,
Leo
> + struct {
> + struct amdgpu_vcn_rb_setup_info
> rb_info[MAX_NUM_VCN_RB_SETUP];
> + };
> + };
> };
>
> +
> struct amdgpu_fw_shared_drm_key_wa {
> uint8_t method;
> uint8_t reserved[3];
> };
>
> +struct amdgpu_fw_shared_queue_decouple {
> +uint8_t is_enabled;
> +uint8_t reserved[7];
> +};
> +
> struct amdgpu_vcn4_fw_shared {
> uint32_t present_flag_0;
> uint8_t pad[12];
> @@ -361,6 +388,8 @@ struct amdgpu_vcn4_fw_shared {
> struct amdgpu_fw_shared_rb_setup rb_setup;
> struct amdgpu_fw_shared_smu_interface_info smu_dpm_interface;
> struct amdgpu_fw_shared_drm_key_wa drm_key_wa;
> + uint8_t pad3[9];
> + struct amdgpu_fw_shared_queue_decouple decouple;
> };
>
> struct amdgpu_vcn_fwlog {
> @@ -378,6 +407,15 @@ struct amdgpu_vcn_decode_buffer {
> uint32_t pad[30];
> };
>
> +struct amdgpu_vcn_rb_metadata {
> + uint32_t size;
> + uint32_t present_flag_0;
> +
> + uint8_t version;
> + uint8_t ring_id;
> + uint8_t pad[26];
> +};
Re: [PATCH v2] Revert "drm/amd/display: Enable Replay for static screen use cases"
On 2023-10-03 11:23, Lakha, Bhawanpreet wrote:
[AMD Official Use Only - General]
Why not just set replay_feature_enabled = true; to false?
Would that be the right fix? If so, we can send out a patch
with that instead.
- Leo
*From:* Li, Sun peng (Leo)
*Sent:* October 3, 2023 11:20 AM
*To:* Lakha, Bhawanpreet ; LIPSKI, IVAN
; amd-gfx@lists.freedesktop.org
*Cc:* Siqueira, Rodrigo ; Mahfooz, Hamza
; Wentland, Harry ;
Deucher, Alexander ; Chung, ChiaHsuan (Tom)
*Subject:* Re: [PATCH v2] Revert "drm/amd/display: Enable Replay for
static screen use cases"
On 2023-10-03 11:13, Lakha, Bhawanpreet wrote:
[AMD Official Use Only - General]
Any reason for reverting this instead of looking into
"amdgpu_dm_setup_replay()" and "replay_feature_enabled" to see why reply
is being enabled?
It causes a regression in amd_psr. Unless there's a quick fix, we should
revert for now. It sounds like this can break existing support for
PSR/PSR SU.
Acked-by: Leo Li
- Leo
Bhawan
*From:* LIPSKI, IVAN
*Sent:* October 2, 2023 1:47 PM
*To:* amd-gfx@lists.freedesktop.org
*Cc:* Siqueira, Rodrigo ; Mahfooz, Hamza
; Wentland, Harry ;
Lakha, Bhawanpreet ; Deucher, Alexander
; Li, Sun peng (Leo) ;
Chung, ChiaHsuan (Tom) ; LIPSKI, IVAN
; LIPSKI, IVAN
*Subject:* [PATCH v2] Revert "drm/amd/display: Enable Replay for static
screen use cases"
From: Ivan Lipski
This reverts commit a92da5bc33ea99a861f6c422192af6072c145d2d.
V2: Reword commit message
[WHY]
This commit caused regression in which eDP's with PSR support,
but no Replay support (Sink support <= 0x03), failed enabling PSR
and all IGT amd_psr tests.
[HOW]
Reverted the patch.
Signed-off-by: Ivan Lipski
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 23 ---
.../amd/display/amdgpu_dm/amdgpu_dm_crtc.c | 9 +---
drivers/gpu/drm/amd/include/amd_shared.h | 2 --
3 files changed, 1 insertion(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 32156609fbcf..f69b2e9ecd98 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -66,7 +66,6 @@
#include "amdgpu_dm_debugfs.h"
#endif
#include "amdgpu_dm_psr.h"
-#include "amdgpu_dm_replay.h"
#include "ivsrcid/ivsrcid_vislands30.h"
@@ -4423,7 +4422,6 @@ static int amdgpu_dm_initialize_drm_device(struct
amdgpu_device *adev)
enum dc_connection_type new_connection_type = dc_connection_none;
const struct dc_plane_cap *plane;
bool psr_feature_enabled = false;
- bool replay_feature_enabled = false;
int max_overlay = dm->dc->caps.max_slave_planes;
dm->display_indexes_num = dm->dc->caps.max_streams;
@@ -4535,21 +4533,6 @@ static int amdgpu_dm_initialize_drm_device(struct
amdgpu_device *adev)
}
}
- if (!(amdgpu_dc_debug_mask & DC_DISABLE_REPLAY)) {
- switch (amdgpu_ip_version(adev, DCE_HWIP, 0)) {
- case IP_VERSION(3, 1, 4):
- case IP_VERSION(3, 1, 5):
- case IP_VERSION(3, 1, 6):
- case IP_VERSION(3, 2, 0):
- case IP_VERSION(3, 2, 1):
- case IP_VERSION(3, 5, 0):
- replay_feature_enabled = true;
- break;
- default:
- replay_feature_enabled = amdgpu_dc_feature_mask
& DC_REPLAY_MASK;
- break;
- }
- }
/* loops over all connectors on the board */
for (i = 0; i < link_cnt; i++) {
struct dc_link *link = NULL;
@@ -4618,12 +4601,6 @@ static int amdgpu_dm_initialize_drm_device(struct
amdgpu_device *adev)
amdgpu_dm_update_connector_after_detect(aconnector);
setup_backlight_device(dm, aconnector);
- /*
- * Disable psr if replay can be enabled
- */
- if (replay_feature_enabled &&
amdgpu_dm_setup_replay(link, aconnector))
- psr_feature_enabled = false;
-
if (psr_feature_enabled)
amdgpu_dm_set_psr_caps(link);
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
index fb51ec4f8d31..440fc0869a34 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
@@
Re: [PATCH v2] Revert "drm/amd/display: Enable Replay for static screen use cases"
On 2023-10-03 11:13, Lakha, Bhawanpreet wrote:
[AMD Official Use Only - General]
Any reason for reverting this instead of looking into
"amdgpu_dm_setup_replay()" and "replay_feature_enabled" to see why reply
is being enabled?
It causes a regression in amd_psr. Unless there's a quick fix, we should
revert for now. It sounds like this can break existing support for
PSR/PSR SU.
Acked-by: Leo Li
- Leo
Bhawan
*From:* LIPSKI, IVAN
*Sent:* October 2, 2023 1:47 PM
*To:* amd-gfx@lists.freedesktop.org
*Cc:* Siqueira, Rodrigo ; Mahfooz, Hamza
; Wentland, Harry ;
Lakha, Bhawanpreet ; Deucher, Alexander
; Li, Sun peng (Leo) ;
Chung, ChiaHsuan (Tom) ; LIPSKI, IVAN
; LIPSKI, IVAN
*Subject:* [PATCH v2] Revert "drm/amd/display: Enable Replay for static
screen use cases"
From: Ivan Lipski
This reverts commit a92da5bc33ea99a861f6c422192af6072c145d2d.
V2: Reword commit message
[WHY]
This commit caused regression in which eDP's with PSR support,
but no Replay support (Sink support <= 0x03), failed enabling PSR
and all IGT amd_psr tests.
[HOW]
Reverted the patch.
Signed-off-by: Ivan Lipski
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 23 ---
.../amd/display/amdgpu_dm/amdgpu_dm_crtc.c | 9 +---
drivers/gpu/drm/amd/include/amd_shared.h | 2 --
3 files changed, 1 insertion(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 32156609fbcf..f69b2e9ecd98 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -66,7 +66,6 @@
#include "amdgpu_dm_debugfs.h"
#endif
#include "amdgpu_dm_psr.h"
-#include "amdgpu_dm_replay.h"
#include "ivsrcid/ivsrcid_vislands30.h"
@@ -4423,7 +4422,6 @@ static int amdgpu_dm_initialize_drm_device(struct
amdgpu_device *adev)
enum dc_connection_type new_connection_type = dc_connection_none;
const struct dc_plane_cap *plane;
bool psr_feature_enabled = false;
- bool replay_feature_enabled = false;
int max_overlay = dm->dc->caps.max_slave_planes;
dm->display_indexes_num = dm->dc->caps.max_streams;
@@ -4535,21 +4533,6 @@ static int amdgpu_dm_initialize_drm_device(struct
amdgpu_device *adev)
}
}
- if (!(amdgpu_dc_debug_mask & DC_DISABLE_REPLAY)) {
- switch (amdgpu_ip_version(adev, DCE_HWIP, 0)) {
- case IP_VERSION(3, 1, 4):
- case IP_VERSION(3, 1, 5):
- case IP_VERSION(3, 1, 6):
- case IP_VERSION(3, 2, 0):
- case IP_VERSION(3, 2, 1):
- case IP_VERSION(3, 5, 0):
- replay_feature_enabled = true;
- break;
- default:
- replay_feature_enabled = amdgpu_dc_feature_mask
& DC_REPLAY_MASK;
- break;
- }
- }
/* loops over all connectors on the board */
for (i = 0; i < link_cnt; i++) {
struct dc_link *link = NULL;
@@ -4618,12 +4601,6 @@ static int amdgpu_dm_initialize_drm_device(struct
amdgpu_device *adev)
amdgpu_dm_update_connector_after_detect(aconnector);
setup_backlight_device(dm, aconnector);
- /*
- * Disable psr if replay can be enabled
- */
- if (replay_feature_enabled &&
amdgpu_dm_setup_replay(link, aconnector))
- psr_feature_enabled = false;
-
if (psr_feature_enabled)
amdgpu_dm_set_psr_caps(link);
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
index fb51ec4f8d31..440fc0869a34 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
@@ -29,7 +29,6 @@
#include "dc.h"
#include "amdgpu.h"
#include "amdgpu_dm_psr.h"
-#include "amdgpu_dm_replay.h"
#include "amdgpu_dm_crtc.h"
#include "amdgpu_dm_plane.h"
#include "amdgpu_dm_trace.h"
@@ -124,12 +123,7 @@ static void vblank_control_worker(struct
work_struct *work)
* fill_dc_dirty_rects().
*/
if (vblank_work->stream && vblank_work->stream->link) {
- /*
- * Prioritize replay, instead of psr
- */
- if
(vblank_work->stream->link->re
RE: [PATCH] drm/amdgpu: not to save bo in the case of RAS err_event_athub
[AMD Official Use Only - General]
Acked-by: Leo Liu
-Original Message-
From: Wu, David
Sent: Thursday, September 21, 2023 3:18 PM
To: amd-gfx@lists.freedesktop.org
Cc: Koenig, Christian ; Deucher, Alexander
; Liu, Leo
Subject: [PATCH] drm/amdgpu: not to save bo in the case of RAS err_event_athub
err_event_athub will corrupt VCPU buffer and not good to be restored in
amdgpu_vcn_resume() and in this case the VCPU buffer needs to be cleared for
VCN firmware to work properly.
Signed-off-by: David (Ming Qiang) Wu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
index c93f3a4c0e31..f4963330c772 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
@@ -294,8 +294,15 @@ int amdgpu_vcn_suspend(struct amdgpu_device *adev)
void *ptr;
int i, idx;
+ bool in_ras_intr = amdgpu_ras_intr_triggered();
+
cancel_delayed_work_sync(>vcn.idle_work);
+ /* err_event_athub will corrupt VCPU buffer, so we need to
+* restore fw data and clear buffer in amdgpu_vcn_resume() */
+ if (in_ras_intr)
+ return 0;
+
for (i = 0; i < adev->vcn.num_vcn_inst; ++i) {
if (adev->vcn.harvest_config & (1 << i))
continue;
--
2.34.1
RE: [PATCH] drm/amdgpu: update IP count INFO query
[AMD Official Use Only - General]
Reviewed-by: Leo Liu
-Original Message-
From: Sundararaju, Sathishkumar
Sent: Thursday, September 14, 2023 12:01 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Koenig, Christian
; Liu, Leo ; Sundararaju,
Sathishkumar
Subject: [PATCH] drm/amdgpu: update IP count INFO query
update the query to return the number of functional instances where there is
more than an instance of the requested type and for others continue to return
one.
Signed-off-by: Sathishkumar S
---
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 90 +
1 file changed, 61 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index 3a48bec10aea..9521fa7a1bf9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -200,6 +200,44 @@ int amdgpu_driver_load_kms(struct amdgpu_device *adev,
unsigned long flags)
return r;
}
+static enum amd_ip_block_type amdgpu_ip_get_block_type(
+ struct amdgpu_device *adev, uint32_t ip) {
+ enum amd_ip_block_type type;
+
+ switch (ip) {
+ case AMDGPU_HW_IP_GFX:
+ type = AMD_IP_BLOCK_TYPE_GFX;
+ break;
+ case AMDGPU_HW_IP_COMPUTE:
+ type = AMD_IP_BLOCK_TYPE_GFX;
+ break;
+ case AMDGPU_HW_IP_DMA:
+ type = AMD_IP_BLOCK_TYPE_SDMA;
+ break;
+ case AMDGPU_HW_IP_UVD:
+ case AMDGPU_HW_IP_UVD_ENC:
+ type = AMD_IP_BLOCK_TYPE_UVD;
+ break;
+ case AMDGPU_HW_IP_VCE:
+ type = AMD_IP_BLOCK_TYPE_VCE;
+ break;
+ case AMDGPU_HW_IP_VCN_DEC:
+ case AMDGPU_HW_IP_VCN_ENC:
+ type = AMD_IP_BLOCK_TYPE_VCN;
+ break;
+ case AMDGPU_HW_IP_VCN_JPEG:
+ type = (amdgpu_device_ip_get_ip_block(adev,
AMD_IP_BLOCK_TYPE_JPEG)) ?
+ AMD_IP_BLOCK_TYPE_JPEG :
AMD_IP_BLOCK_TYPE_VCN;
+ break;
+ default:
+ type = AMD_IP_BLOCK_TYPE_NUM;
+ break;
+ }
+
+ return type;
+}
+
static int amdgpu_firmware_info(struct drm_amdgpu_info_firmware *fw_info,
struct drm_amdgpu_query_fw *query_fw,
struct amdgpu_device *adev)
@@ -592,45 +630,39 @@ int amdgpu_info_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
}
case AMDGPU_INFO_HW_IP_COUNT: {
enum amd_ip_block_type type;
+ struct amdgpu_ip_block *ip_block = NULL;
uint32_t count = 0;
- switch (info->query_hw_ip.type) {
- case AMDGPU_HW_IP_GFX:
- type = AMD_IP_BLOCK_TYPE_GFX;
- break;
- case AMDGPU_HW_IP_COMPUTE:
- type = AMD_IP_BLOCK_TYPE_GFX;
- break;
- case AMDGPU_HW_IP_DMA:
- type = AMD_IP_BLOCK_TYPE_SDMA;
- break;
- case AMDGPU_HW_IP_UVD:
- type = AMD_IP_BLOCK_TYPE_UVD;
+ type = amdgpu_ip_get_block_type(adev, info->query_hw_ip.type);
+ ip_block = amdgpu_device_ip_get_ip_block(adev, type);
+ if (!ip_block || !ip_block->status.valid)
+ return -EINVAL;
+
+ switch (type) {
+ case AMD_IP_BLOCK_TYPE_GFX:
+ case AMD_IP_BLOCK_TYPE_VCE:
+ count = 1;
break;
- case AMDGPU_HW_IP_VCE:
- type = AMD_IP_BLOCK_TYPE_VCE;
+ case AMD_IP_BLOCK_TYPE_SDMA:
+ count = adev->sdma.num_instances;
break;
- case AMDGPU_HW_IP_UVD_ENC:
- type = AMD_IP_BLOCK_TYPE_UVD;
+ case AMD_IP_BLOCK_TYPE_JPEG:
+ count = adev->jpeg.num_jpeg_inst;
break;
- case AMDGPU_HW_IP_VCN_DEC:
- case AMDGPU_HW_IP_VCN_ENC:
- type = AMD_IP_BLOCK_TYPE_VCN;
+ case AMD_IP_BLOCK_TYPE_VCN:
+ count = adev->vcn.num_vcn_inst;
break;
- case AMDGPU_HW_IP_VCN_JPEG:
- type = (amdgpu_device_ip_get_ip_block(adev,
AMD_IP_BLOCK_TYPE_JPEG)) ?
- AMD_IP_BLOCK_TYPE_JPEG : AMD_IP_BLOCK_TYPE_VCN;
+ case AMD_IP_BLOCK_TYPE_UVD:
+ count = adev->uvd.num_uvd_inst;
break;
+ /* For all other IP block types not listed in the switch
statement
+* the ip status is valid here and the instance count is one.
+*/
default:
-
Re: [PATCH 6/7] Revert "drm/amd/display: Implement zpos property"
On 2023-08-18 04:25, Melissa Wen wrote:
On 07/26, Aurabindo Pillai wrote:
This reverts commit 6c8ff1683d30024c8cff137d30b740a405cc084e.
This patch causes IGT test case 'kms_atomic@plane-immutable-zpos' to
fail on AMDGPU hardware.
Cc: Joshua Ashton
Signed-off-by: Nicholas Choi
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
index 2198df96ed6f..8eeca160d434 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
@@ -1468,15 +1468,6 @@ int amdgpu_dm_plane_init(struct amdgpu_display_manager
*dm,
drm_plane_create_blend_mode_property(plane, blend_caps);
}
- if (plane->type == DRM_PLANE_TYPE_PRIMARY) {
- drm_plane_create_zpos_immutable_property(plane, 0);
- } else if (plane->type == DRM_PLANE_TYPE_OVERLAY) {
- unsigned int zpos = 1 + drm_plane_index(plane);
- drm_plane_create_zpos_property(plane, zpos, 1, 254);
- } else if (plane->type == DRM_PLANE_TYPE_CURSOR) {
- drm_plane_create_zpos_immutable_property(plane, 255);
- }
Hi Jay and Nicholas,
I'm examining this regression and, looking at the test code, I consider
this failure is caused by an incorrect assumption in the IGT test in
which any zpos values must be in the normalized range of 0 and N planes
per CRTC.
for (int k = 0; k < n_planes; k++) {
int zpos;
igt_plane_t *temp;
temp = >pipes[pipe->pipe].planes[k];
if (!igt_plane_has_prop(temp, IGT_PLANE_ZPOS))
continue;
zpos = igt_plane_get_prop(temp, IGT_PLANE_ZPOS);
igt_assert_lt(zpos, n_planes); // test case fails here
plane_ptr[zpos] = temp;
}
I didn't find anything in the DRM documentation that imposes this
behavior. Also, the plane composition in the test is working correctly
with this patch and without this likely-misleading assert. In addition,
enabling zpos property increases the coverage of
`kms_atomic@plane-immutable-zpos` test (previously this part of the test
was just bypassed), so it's not a regression per se. Therefore, I'm
inclined to send a fix to IGT, instead of implementing a behavior that
fit the test but may not fit well AMD display machinery.
But first I wonder if you guys find any other test or visual check that
fail with this feature?
I checked other IGT KMS plane tests and AMD MPO tests (in `amd_plane`)
and results are preserved. If there are no other issues besides IGT
plane-immutable-zpos, I'll proceed with sending the change to IGT.
Thanks,
Melissa
Hi Melissa,
Thanks for taking a look at the IGT test. Looks like the IGT failures
are the only concerns, and I agree that it doesn't make sense to require
zpos to be normalized between 0 and number of planes.
Thanks,
Leo
-
if (plane->type == DRM_PLANE_TYPE_PRIMARY &&
plane_cap &&
(plane_cap->pixel_format_support.nv12 ||
--
2.41.0
Re: [PATCH v4 1/7] drm/amdgpu/vcn: Add MMSCH v4_0_3 support for sriov
The series is:
Acked-by: Leo Liu .
On 2023-08-08 12:26, Samir Dhume wrote:
The structures are the same as v4_0 except for the
init header
Signed-off-by: Samir Dhume
---
drivers/gpu/drm/amd/amdgpu/mmsch_v4_0_3.h | 37 +++
1 file changed, 37 insertions(+)
create mode 100644 drivers/gpu/drm/amd/amdgpu/mmsch_v4_0_3.h
diff --git a/drivers/gpu/drm/amd/amdgpu/mmsch_v4_0_3.h
b/drivers/gpu/drm/amd/amdgpu/mmsch_v4_0_3.h
new file mode 100644
index ..db7eb5260295
--- /dev/null
+++ b/drivers/gpu/drm/amd/amdgpu/mmsch_v4_0_3.h
@@ -0,0 +1,37 @@
+/*
+ * Copyright 2023 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ */
+
+#ifndef __MMSCH_V4_0_3_H__
+#define __MMSCH_V4_0_3_H__
+
+#include "amdgpu_vcn.h"
+#include "mmsch_v4_0.h"
+
+struct mmsch_v4_0_3_init_header {
+ uint32_t version;
+ uint32_t total_size;
+ struct mmsch_v4_0_table_info vcn0;
+ struct mmsch_v4_0_table_info mjpegdec0[4];
+ struct mmsch_v4_0_table_info mjpegdec1[4];
+};
+#endif
Re: [PATCH v3 3/7] drm/amdgpu/vcn: sriov support for vcn_v4_0_3
On 2023-07-28 15:15, Samir Dhume wrote:
initialization table handshake with mmsch
Signed-off-by: Samir Dhume
---
drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.c | 257 +---
1 file changed, 233 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.c
index 411c1d802823..b978265b2d77 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.c
@@ -31,6 +31,7 @@
#include "soc15d.h"
#include "soc15_hw_ip.h"
#include "vcn_v2_0.h"
+#include "mmsch_v4_0_3.h"
#include "vcn/vcn_4_0_3_offset.h"
#include "vcn/vcn_4_0_3_sh_mask.h"
@@ -44,6 +45,7 @@
#define VCN_VID_SOC_ADDRESS_2_0 0x1fb00
#define VCN1_VID_SOC_ADDRESS_3_0 0x48300
+static int vcn_v4_0_3_start_sriov(struct amdgpu_device *adev);
static void vcn_v4_0_3_set_unified_ring_funcs(struct amdgpu_device *adev);
static void vcn_v4_0_3_set_irq_funcs(struct amdgpu_device *adev);
static int vcn_v4_0_3_set_powergating_state(void *handle,
@@ -130,6 +132,10 @@ static int vcn_v4_0_3_sw_init(void *handle)
amdgpu_vcn_fwlog_init(>vcn.inst[i]);
}
+ r = amdgpu_virt_alloc_mm_table(adev);
Since this function is not for bare-metal, please move amdgpu_sriov_vf()
check from inside of the function to here, to avoid confusion.
+ if (r)
+ return r;
+
if (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG)
adev->vcn.pause_dpg_mode = vcn_v4_0_3_pause_dpg_mode;
@@ -167,6 +173,8 @@ static int vcn_v4_0_3_sw_fini(void *handle)
drm_dev_exit(idx);
}
+ amdgpu_virt_free_mm_table(adev);
Same as above.
Regards,
Leo
+
r = amdgpu_vcn_suspend(adev);
if (r)
return r;
@@ -189,33 +197,47 @@ static int vcn_v4_0_3_hw_init(void *handle)
struct amdgpu_ring *ring;
int i, r, vcn_inst;
- for (i = 0; i < adev->vcn.num_vcn_inst; ++i) {
- vcn_inst = GET_INST(VCN, i);
- ring = >vcn.inst[i].ring_enc[0];
+ if (amdgpu_sriov_vf(adev)) {
+ r = vcn_v4_0_3_start_sriov(adev);
+ if (r)
+ goto done;
- if (ring->use_doorbell) {
- adev->nbio.funcs->vcn_doorbell_range(
- adev, ring->use_doorbell,
- (adev->doorbell_index.vcn.vcn_ring0_1 << 1) +
- 9 * vcn_inst,
- adev->vcn.inst[i].aid_id);
-
- WREG32_SOC15(
- VCN, GET_INST(VCN, ring->me),
- regVCN_RB1_DB_CTRL,
- ring->doorbell_index
- <<
VCN_RB1_DB_CTRL__OFFSET__SHIFT |
- VCN_RB1_DB_CTRL__EN_MASK);
-
- /* Read DB_CTRL to flush the write DB_CTRL command. */
- RREG32_SOC15(
- VCN, GET_INST(VCN, ring->me),
- regVCN_RB1_DB_CTRL);
+ for (i = 0; i < adev->vcn.num_vcn_inst; ++i) {
+ ring = >vcn.inst[i].ring_enc[0];
+ ring->wptr = 0;
+ ring->wptr_old = 0;
+ vcn_v4_0_3_unified_ring_set_wptr(ring);
+ ring->sched.ready = true;
}
+ } else {
+ for (i = 0; i < adev->vcn.num_vcn_inst; ++i) {
+ vcn_inst = GET_INST(VCN, i);
+ ring = >vcn.inst[i].ring_enc[0];
+
+ if (ring->use_doorbell) {
+ adev->nbio.funcs->vcn_doorbell_range(
+ adev, ring->use_doorbell,
+ (adev->doorbell_index.vcn.vcn_ring0_1
<< 1) +
+ 9 * vcn_inst,
+ adev->vcn.inst[i].aid_id);
+
+ WREG32_SOC15(
+ VCN, GET_INST(VCN, ring->me),
+ regVCN_RB1_DB_CTRL,
+ ring->doorbell_index
+ <<
VCN_RB1_DB_CTRL__OFFSET__SHIFT |
+ VCN_RB1_DB_CTRL__EN_MASK);
+
+ /* Read DB_CTRL to flush the write DB_CTRL
command. */
+ RREG32_SOC15(
+ VCN, GET_INST(VCN, ring->me),
+ regVCN_RB1_DB_CTRL);
+ }
Re: [PATCH] drm/amdgpu: Enabling FW workaround through shared memory for VCN4_0_2
Reviewed-by: Leo Liu
On 2023-07-17 23:20, sguttula wrote:
This patch will enable VCN FW workaround using
DRM KEY INJECT WORKAROUND method,
which is helping in fixing the secure playback.
Signed-off-by: sguttula
---
Changes in v2:
-updated commit message as per veera's feedback
Changes in v3:
-updated commit message as enabling for 402
-updated the logic as per leo, feedback
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h | 9 +
drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c | 6 ++
2 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
index 1f1d7dc94f90..a3eed90b6af0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
@@ -161,6 +161,7 @@
} while (0)
#define AMDGPU_FW_SHARED_FLAG_0_UNIFIED_QUEUE (1 << 2)
+#define AMDGPU_FW_SHARED_FLAG_0_DRM_KEY_INJECT (1 << 4)
#define AMDGPU_VCN_FW_SHARED_FLAG_0_RB(1 << 6)
#define AMDGPU_VCN_MULTI_QUEUE_FLAG (1 << 8)
#define AMDGPU_VCN_SW_RING_FLAG (1 << 9)
@@ -180,6 +181,8 @@
#define AMDGPU_VCN_SMU_DPM_INTERFACE_DGPU (0)
#define AMDGPU_VCN_SMU_DPM_INTERFACE_APU (1)
+#define AMDGPU_DRM_KEY_INJECT_WORKAROUND_VCNFW_ASD_HANDSHAKING 2
+
enum fw_queue_mode {
FW_QUEUE_RING_RESET = 1,
FW_QUEUE_DPG_HOLD_OFF = 2,
@@ -343,6 +346,11 @@ struct amdgpu_fw_shared_rb_setup {
uint32_t reserved[6];
};
+struct amdgpu_fw_shared_drm_key_wa {
+ uint8_t method;
+ uint8_t reserved[3];
+};
+
struct amdgpu_vcn4_fw_shared {
uint32_t present_flag_0;
uint8_t pad[12];
@@ -352,6 +360,7 @@ struct amdgpu_vcn4_fw_shared {
uint8_t pad2[20];
struct amdgpu_fw_shared_rb_setup rb_setup;
struct amdgpu_fw_shared_smu_interface_info smu_dpm_interface;
+ struct amdgpu_fw_shared_drm_key_wa drm_key_wa;
};
struct amdgpu_vcn_fwlog {
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
index e8c02ae10163..16ee73cfc3a8 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
@@ -169,6 +169,12 @@ static int vcn_v4_0_sw_init(void *handle)
fw_shared->smu_dpm_interface.smu_interface_type = (adev->flags
& AMD_IS_APU) ?
AMDGPU_VCN_SMU_DPM_INTERFACE_APU :
AMDGPU_VCN_SMU_DPM_INTERFACE_DGPU;
+ if (adev->ip_versions[VCN_HWIP][0] == IP_VERSION(4, 0, 2)) {
+ fw_shared->present_flag_0 |=
AMDGPU_FW_SHARED_FLAG_0_DRM_KEY_INJECT;
+ fw_shared->drm_key_wa.method =
+
AMDGPU_DRM_KEY_INJECT_WORKAROUND_VCNFW_ASD_HANDSHAKING;
+ }
+
if (amdgpu_sriov_vf(adev))
fw_shared->present_flag_0 |=
cpu_to_le32(AMDGPU_VCN_VF_RB_SETUP_FLAG);
Re: [PATCH] drm/amdgpu: allow secure submission on VCN4 ring
Reviewed-by: Leo Liu
On 2023-07-17 13:27, sguttula wrote:
This patch will enable secure decode playback on VCN4_0_2
Signed-off-by: sguttula
---
Changes in v2:
-updated commit message only enabling for VCN402
-updated the logic as per Leo's feedback
---
drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
index e8c02ae10163..d2d89bb711b0 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
@@ -1801,7 +1801,7 @@ static int vcn_v4_0_ring_patch_cs_in_place(struct
amdgpu_cs_parser *p,
return 0;
}
-static const struct amdgpu_ring_funcs vcn_v4_0_unified_ring_vm_funcs = {
+static struct amdgpu_ring_funcs vcn_v4_0_unified_ring_vm_funcs = {
.type = AMDGPU_RING_TYPE_VCN_ENC,
.align_mask = 0x3f,
.nop = VCN_ENC_CMD_NO_OP,
@@ -1846,7 +1846,11 @@ static void vcn_v4_0_set_unified_ring_funcs(struct
amdgpu_device *adev)
if (adev->vcn.harvest_config & (1 << i))
continue;
- adev->vcn.inst[i].ring_enc[0].funcs = _v4_0_unified_ring_vm_funcs;
+ if (adev->ip_versions[VCN_HWIP][0] == IP_VERSION(4, 0, 2))
+
vcn_v4_0_unified_ring_vm_funcs.secure_submission_supported = true;
+
+ adev->vcn.inst[i].ring_enc[0].funcs =
+ (const struct amdgpu_ring_funcs
*)_v4_0_unified_ring_vm_funcs;
adev->vcn.inst[i].ring_enc[0].me = i;
DRM_INFO("VCN(%d) encode/decode are enabled in VM mode\n", i);
Re: [PATCH 1/2] drm/amdgpu: allow secure submission on VCN4 ring
Since the changes will affect multiple ASICs, if you only tested with
VCN4_0_4, please just apply the set to that HW.
Regards,
Leo
On 2023-07-16 23:15, Guttula, Suresh wrote:
Hi Leo,
There are two issues here.
This change fixing the Crash while secure playback and we see below error:
2023-07-14T15:51:24.837592Z ERR kernel: [ 129.255823] amdgpu :c2:00.0: amdgpu:
secure submissions not supported on ring
2023-07-14T15:51:24.837601Z ERR kernel: [ 129.255827] [drm:amdgpu_job_run]
*ERROR* Error scheduling IBs (-22)
2023-07-14T15:51:24.837603Z INFO kernel: [ 129.255834] [drm] Skip scheduling
IBs!
The second one : https://patchwork.freedesktop.org/patch/547587/
Fixing the garbage/corruption.
With both patches playback working fine.
Thanks,
Suresh G
-Original Message-
From: Liu, Leo
Sent: Friday, July 14, 2023 7:08 PM
To: Guttula, Suresh ; Deucher, Alexander
; Koenig, Christian
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/2] drm/amdgpu: allow secure submission on VCN4 ring
On 2023-07-14 05:44, sguttula wrote:
This patch will enable secure decode playback on VCN4
Signed-off-by: sguttula
---
drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
index e8c02ae10163..d199f87febd1 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
@@ -1804,6 +1804,7 @@ static int vcn_v4_0_ring_patch_cs_in_place(struct
amdgpu_cs_parser *p,
static const struct amdgpu_ring_funcs vcn_v4_0_unified_ring_vm_funcs = {
.type = AMDGPU_RING_TYPE_VCN_ENC,
.align_mask = 0x3f,
+ .secure_submission_supported = true,
We should set it to true with VCN4_0_4 only for now, and check either this
boolean or VCN4_0_4 with your implementation from patch 2
Regards,
Leo
.nop = VCN_ENC_CMD_NO_OP,
.get_rptr = vcn_v4_0_unified_ring_get_rptr,
.get_wptr = vcn_v4_0_unified_ring_get_wptr,
Re: [PATCH 1/2] drm/amdgpu: allow secure submission on VCN4 ring
On 2023-07-14 05:44, sguttula wrote:
This patch will enable secure decode playback on VCN4
Signed-off-by: sguttula
---
drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
index e8c02ae10163..d199f87febd1 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
@@ -1804,6 +1804,7 @@ static int vcn_v4_0_ring_patch_cs_in_place(struct
amdgpu_cs_parser *p,
static const struct amdgpu_ring_funcs vcn_v4_0_unified_ring_vm_funcs = {
.type = AMDGPU_RING_TYPE_VCN_ENC,
.align_mask = 0x3f,
+ .secure_submission_supported = true,
We should set it to true with VCN4_0_4 only for now, and check either
this boolean or VCN4_0_4 with your implementation from patch 2
Regards,
Leo
.nop = VCN_ENC_CMD_NO_OP,
.get_rptr = vcn_v4_0_unified_ring_get_rptr,
.get_wptr = vcn_v4_0_unified_ring_get_wptr,
Re: [PATCH v3 2/2] drm/amdgpu: update kernel vcn ring test
On 2023-07-10 16:19, Liu, Leo wrote:
[AMD Official Use Only - General]
[AMD Official Use Only - General]
-Original Message-
From: Jamadar, Saleemkhan
Sent: Monday, July 10, 2023 12:54 PM
To: Jamadar, Saleemkhan ; amd-gfx@lists.freedesktop.org; Liu, Leo
; Gopalakrishnan, Veerabadhran (Veera)
; Sundararaju, Sathishkumar
Cc: Koenig, Christian ; Rao, Srinath
Subject: [PATCH v3 2/2] drm/amdgpu: update kernel vcn ring test
add session context buffer to decoder ring test fro vcn v1 to v3.
v3 - correct the cmd for sesssion ctx buf
v2 - add the buffer into IB (Leo liu)
Signed-off-by: Saleemkhan Jamadar
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
index 76e9a2418286..4ee5f933e420 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
@@ -521,6 +521,7 @@ static int amdgpu_vcn_dec_send_msg(struct amdgpu_ring *ring,
struct dma_fence **fence)
{
u64 addr = AMDGPU_GPU_PAGE_ALIGN(ib_msg->gpu_addr);
+ uint64_t session_ctx_buf_gaddr = AMDGPU_GPU_PAGE_ALIGN(ib_msg->gpu_addr
+ 8192);
struct amdgpu_device *adev = ring->adev;
struct dma_fence *f = NULL;
struct amdgpu_job *job;
@@ -546,6 +547,19 @@ static int amdgpu_vcn_dec_send_msg(struct amdgpu_ring
*ring,
}
ib->length_dw = 16;
This line above can be removed. With that the patch is:
Reviewed-by: Leo Liu
I think we should rework the lines above of this line for msg buffer,
put the session ctx buffer right behind it, and no need fill the nop
command in between, so make the code cleaner.
Regards,
Leo
+ ib->ptr[ib->length_dw++] = PACKET0(adev->vcn.internal.data0, 0);
+ ib->ptr[ib->length_dw++] = lower_32_bits(session_ctx_buf_gaddr);
+ ib->ptr[ib->length_dw++] = PACKET0(adev->vcn.internal.data1, 0);
+ ib->ptr[ib->length_dw++] = upper_32_bits(session_ctx_buf_gaddr);
+ /* session ctx buffer cmd */
+ ib->ptr[ib->length_dw++] = PACKET0(adev->vcn.internal.cmd, 0xa);
+ ib->ptr[ib->length_dw++] = 0;
+ for (i = ib->length_dw; i < 32; i += 2) {
+ ib->ptr[i] = PACKET0(adev->vcn.internal.nop, 0);
+ ib->ptr[i+1] = 0;
+ }
+ ib->length_dw = 32;
+
r = amdgpu_job_submit_direct(job, ring, );
if (r)
goto err_free;
--
2.25.1
RE: [PATCH v3 2/2] drm/amdgpu: update kernel vcn ring test
[AMD Official Use Only - General]
-Original Message-
From: Jamadar, Saleemkhan
Sent: Monday, July 10, 2023 12:54 PM
To: Jamadar, Saleemkhan ;
amd-gfx@lists.freedesktop.org; Liu, Leo ; Gopalakrishnan,
Veerabadhran (Veera) ; Sundararaju,
Sathishkumar
Cc: Koenig, Christian ; Rao, Srinath
Subject: [PATCH v3 2/2] drm/amdgpu: update kernel vcn ring test
add session context buffer to decoder ring test fro vcn v1 to v3.
v3 - correct the cmd for sesssion ctx buf
v2 - add the buffer into IB (Leo liu)
Signed-off-by: Saleemkhan Jamadar
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
index 76e9a2418286..4ee5f933e420 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
@@ -521,6 +521,7 @@ static int amdgpu_vcn_dec_send_msg(struct amdgpu_ring *ring,
struct dma_fence **fence)
{
u64 addr = AMDGPU_GPU_PAGE_ALIGN(ib_msg->gpu_addr);
+ uint64_t session_ctx_buf_gaddr = AMDGPU_GPU_PAGE_ALIGN(ib_msg->gpu_addr
+ 8192);
struct amdgpu_device *adev = ring->adev;
struct dma_fence *f = NULL;
struct amdgpu_job *job;
@@ -546,6 +547,19 @@ static int amdgpu_vcn_dec_send_msg(struct amdgpu_ring
*ring,
}
ib->length_dw = 16;
This line above can be removed. With that the patch is:
Reviewed-by: Leo Liu
+ ib->ptr[ib->length_dw++] = PACKET0(adev->vcn.internal.data0, 0);
+ ib->ptr[ib->length_dw++] = lower_32_bits(session_ctx_buf_gaddr);
+ ib->ptr[ib->length_dw++] = PACKET0(adev->vcn.internal.data1, 0);
+ ib->ptr[ib->length_dw++] = upper_32_bits(session_ctx_buf_gaddr);
+ /* session ctx buffer cmd */
+ ib->ptr[ib->length_dw++] = PACKET0(adev->vcn.internal.cmd, 0xa);
+ ib->ptr[ib->length_dw++] = 0;
+ for (i = ib->length_dw; i < 32; i += 2) {
+ ib->ptr[i] = PACKET0(adev->vcn.internal.nop, 0);
+ ib->ptr[i+1] = 0;
+ }
+ ib->length_dw = 32;
+
r = amdgpu_job_submit_direct(job, ring, );
if (r)
goto err_free;
--
2.25.1
RE: [PATCH v2 2/2] drm/amdgpu: update kernel vcn ring test
[AMD Official Use Only - General]
-Original Message-
From: Jamadar, Saleemkhan
Sent: Monday, July 10, 2023 4:24 AM
To: Jamadar, Saleemkhan ;
amd-gfx@lists.freedesktop.org; Liu, Leo ; Gopalakrishnan,
Veerabadhran (Veera) ; Sundararaju,
Sathishkumar
Cc: Koenig, Christian ; Rao, Srinath
Subject: [PATCH v2 2/2] drm/amdgpu: update kernel vcn ring test
add session context buffer to decoder ring test for vcn v1 to v3.
v2 - add the buffer into IB (Leo liu)
Signed-off-by: Saleemkhan Jamadar
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
index 76e9a2418286..4c44d76f69de 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
@@ -521,6 +521,7 @@ static int amdgpu_vcn_dec_send_msg(struct amdgpu_ring *ring,
struct dma_fence **fence)
{
u64 addr = AMDGPU_GPU_PAGE_ALIGN(ib_msg->gpu_addr);
+ uint64_t session_ctx_buf_gaddr = AMDGPU_GPU_PAGE_ALIGN(ib_msg->gpu_addr
+ 8192);
struct amdgpu_device *adev = ring->adev;
struct dma_fence *f = NULL;
struct amdgpu_job *job;
@@ -546,6 +547,17 @@ static int amdgpu_vcn_dec_send_msg(struct amdgpu_ring
*ring,
}
ib->length_dw = 16;
+ ib->ptr[ib->length_dw++] = PACKET0(adev->vcn.internal.data0, 0);
+ ib->ptr[ib->length_dw++] = lower_32_bits(session_ctx_buf_gaddr);
+ ib->ptr[ib->length_dw++] = PACKET0(adev->vcn.internal.data1, 0);
+ ib->ptr[ib->length_dw++] = upper_32_bits(session_ctx_buf_gaddr);
+ ib->ptr[ib->length_dw++] = PACKET0(adev->vcn.internal.cmd, 0);
+ ib->ptr[ib->length_dw++] = 0;
This is not right. Again please check with Mesa.
+ for (i = ib->length_dw; i < 32; i += 2) {
+ ib->ptr[i] = PACKET0(adev->vcn.internal.nop, 0);
+ ib->ptr[i+1] = 0;
+ }
+
Do we need update the ib length?
Regards,
Leo
r = amdgpu_job_submit_direct(job, ring, );
if (r)
goto err_free;
--
2.25.1
Re: [PATCH 2/2] drm/amdgpu: use psp_execute_load_ip_fw_cmd_buf instead
It looks good to me. The series is:
Reviewed-by: Leo Liu
On 2023-06-27 00:48, Lang Yu wrote:
Replace the old ones with psp_execute_load_ip_fw_cmd_buf.
Signed-off-by: Lang Yu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 31 -
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h | 2 --
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 9 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h | 2 ++
drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c | 4 +---
drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c | 4 +---
drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c | 4 +---
drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c | 4 +---
drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.c | 4 +---
9 files changed, 20 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index a1cb541f315f..b61963112118 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -2474,21 +2474,11 @@ int psp_execute_load_ip_fw_cmd_buf(struct amdgpu_device
*adev,
return ret;
}
-static int psp_execute_non_psp_fw_load(struct psp_context *psp,
- struct amdgpu_firmware_info *ucode)
+static inline
+int psp_execute_non_psp_fw_load(struct psp_context *psp,
+ struct amdgpu_firmware_info *ucode)
{
- int ret = 0;
- struct psp_gfx_cmd_resp *cmd = acquire_psp_cmd_buf(psp);
-
- ret = psp_prep_load_ip_fw_cmd_buf(ucode, cmd);
- if (!ret) {
- ret = psp_cmd_submit_buf(psp, ucode, cmd,
-psp->fence_buf_mc_addr);
- }
-
- release_psp_cmd_buf(psp);
-
- return ret;
+ return psp_execute_load_ip_fw_cmd_buf(psp->adev, ucode, 0, 0, 0);
}
static int psp_load_smu_fw(struct psp_context *psp)
@@ -2946,19 +2936,6 @@ int psp_rlc_autoload_start(struct psp_context *psp)
return ret;
}
-int psp_update_vcn_sram(struct amdgpu_device *adev, int inst_idx,
- uint64_t cmd_gpu_addr, int cmd_size)
-{
- struct amdgpu_firmware_info ucode = {0};
-
- ucode.ucode_id = inst_idx ? AMDGPU_UCODE_ID_VCN1_RAM :
- AMDGPU_UCODE_ID_VCN0_RAM;
- ucode.mc_addr = cmd_gpu_addr;
- ucode.ucode_size = cmd_size;
-
- return psp_execute_non_psp_fw_load(>psp, );
-}
-
int psp_ring_cmd_submit(struct psp_context *psp,
uint64_t cmd_buf_mc_addr,
uint64_t fence_mc_addr,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h
index bd324fed6237..e49984a9d570 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h
@@ -459,8 +459,6 @@ extern int psp_wait_for_spirom_update(struct psp_context
*psp, uint32_t reg_inde
uint32_t field_val, uint32_t mask, uint32_t
msec_timeout);
int psp_gpu_reset(struct amdgpu_device *adev);
-int psp_update_vcn_sram(struct amdgpu_device *adev, int inst_idx,
- uint64_t cmd_gpu_addr, int cmd_size);
int psp_execute_load_ip_fw_cmd_buf(struct amdgpu_device *adev,
struct amdgpu_firmware_info *ucode,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
index d37ebd4402ef..1805cd042d34 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
@@ -1257,3 +1257,12 @@ int amdgpu_vcn_ras_sw_init(struct amdgpu_device *adev)
return 0;
}
+
+int amdgpu_vcn_psp_update_sram(struct amdgpu_device *adev, int inst_idx)
+{
+ return psp_execute_load_ip_fw_cmd_buf(adev, NULL,
+ inst_idx ? AMDGPU_UCODE_ID_VCN1_RAM : AMDGPU_UCODE_ID_VCN0_RAM,
+ adev->vcn.inst[inst_idx].dpg_sram_gpu_addr,
+
(uint32_t)((uintptr_t)adev->vcn.inst[inst_idx].dpg_sram_curr_addr -
+
(uintptr_t)adev->vcn.inst[inst_idx].dpg_sram_cpu_addr));
+}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
index 92d5534df5f4..3ac5ad91ed08 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
@@ -414,4 +414,6 @@ int amdgpu_vcn_ras_late_init(struct amdgpu_device *adev,
struct ras_common_if *ras_block);
int amdgpu_vcn_ras_sw_init(struct amdgpu_device *adev);
+int amdgpu_vcn_psp_update_sram(struct amdgpu_device *adev, int inst_idx);
+
#endif
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c
index c975aed2f6c7..74cd1522067c 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c
@@ -881,9 +881,7 @@ static int vcn_v2_0_start_dpg_mode(struct amdgpu_device
*adev, bool indirect)
UVD_MASTINT_EN__VCPU_EN_MASK, 0, indirect);
if (indirect)
- psp_update_vcn_sram(adev,
Re: [PATCH] drm/amdgpu: Clear VCN cache when hw_init
What Christian says is correct, esp. during the playback or encode, when suspend/resume happens, it will save the FW context, and after resume, it will continue the job to where it left during the suspend. Will this apply to SRIOV case? Since the changes only within the SRIOV code, please make sure that also please specify the SRIOV from your patch subject and commit message. Regards, Leo On 2023-06-30 07:38, Christian König wrote: Am 20.06.23 um 15:29 schrieb Horace Chen: [Why] VCN will use some framebuffer space as its cache. It needs to be reset when reset happens, such as FLR. Otherwise some error may be kept after the reset. Well this doesn't make sense at all. The full content of adev->vcn.inst[i].cpu_addr is saved and restored during suspend/resume and IIRC GPU resets as well. See functions amdgpu_vcn_suspend() and amdgpu_vcn_resume(). Please let Leo's team take a look at this and review the change before it is committed. Regards, Christian. Signed-off-by: Horace Chen --- drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c index b48bb5212488..2db73a964031 100644 --- a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c +++ b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c @@ -1292,6 +1292,7 @@ static int vcn_v4_0_start_sriov(struct amdgpu_device *adev) cache_size); cache_addr = adev->vcn.inst[i].gpu_addr + offset; + memset(adev->vcn.inst[i].cpu_addr + offset, 0, AMDGPU_VCN_STACK_SIZE); MMSCH_V4_0_INSERT_DIRECT_WT(SOC15_REG_OFFSET(VCN, i, regUVD_LMI_VCPU_CACHE1_64BIT_BAR_LOW), lower_32_bits(cache_addr)); @@ -1307,6 +1308,8 @@ static int vcn_v4_0_start_sriov(struct amdgpu_device *adev) cache_addr = adev->vcn.inst[i].gpu_addr + offset + AMDGPU_VCN_STACK_SIZE; + memset(adev->vcn.inst[i].cpu_addr + offset + AMDGPU_VCN_STACK_SIZE, 0, + AMDGPU_VCN_STACK_SIZE); MMSCH_V4_0_INSERT_DIRECT_WT(SOC15_REG_OFFSET(VCN, i, regUVD_LMI_VCPU_CACHE2_64BIT_BAR_LOW), lower_32_bits(cache_addr));
Re: [PATCH v2 3/4] drm/amd/display: Set minimum requirement for using PSR-SU on Phoenix
On 6/23/23 11:05, Mario Limonciello wrote:
The same parade TCON issue can potentially happen on Phoenix, and the same
PSR resilience changes have been ported into the DMUB firmware.
Don't allow running PSR-SU unless on the newer firmware.
Cc: Sean Wang
Cc: Marc Rossi
Cc: Hamza Mahfooz
Cc: Tsung-hua (Ryan) Lin
Signed-off-by: Mario Limonciello
Reviewed-by: Leo Li
---
v1->v2:
* Fix a s/dcn31/dcn314/ mixup
---
drivers/gpu/drm/amd/display/dmub/src/dmub_dcn314.c | 5 +
drivers/gpu/drm/amd/display/dmub/src/dmub_dcn314.h | 2 ++
drivers/gpu/drm/amd/display/dmub/src/dmub_srv.c| 1 +
3 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn314.c
b/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn314.c
index 48a06dbd9be7..f161aeb7e7c4 100644
--- a/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn314.c
+++ b/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn314.c
@@ -60,3 +60,8 @@ const struct dmub_srv_dcn31_regs dmub_srv_dcn314_regs = {
{ DMUB_DCN31_FIELDS() },
#undef DMUB_SF
};
+
+bool dmub_dcn314_is_psrsu_supported(struct dmub_srv *dmub)
+{
+ return dmub->fw_version >= DMUB_FW_VERSION(8, 0, 16);
+}
diff --git a/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn314.h
b/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn314.h
index 674267a2940e..f213bd82c911 100644
--- a/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn314.h
+++ b/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn314.h
@@ -30,4 +30,6 @@
extern const struct dmub_srv_dcn31_regs dmub_srv_dcn314_regs;
+bool dmub_dcn314_is_psrsu_supported(struct dmub_srv *dmub);
+
#endif /* _DMUB_DCN314_H_ */
diff --git a/drivers/gpu/drm/amd/display/dmub/src/dmub_srv.c
b/drivers/gpu/drm/amd/display/dmub/src/dmub_srv.c
index 7a31e3e27bab..bdaf43892f47 100644
--- a/drivers/gpu/drm/amd/display/dmub/src/dmub_srv.c
+++ b/drivers/gpu/drm/amd/display/dmub/src/dmub_srv.c
@@ -228,6 +228,7 @@ static bool dmub_srv_hw_setup(struct dmub_srv *dmub, enum
dmub_asic asic)
case DMUB_ASIC_DCN316:
if (asic == DMUB_ASIC_DCN314) {
dmub->regs_dcn31 = _srv_dcn314_regs;
+ funcs->is_psrsu_supported =
dmub_dcn314_is_psrsu_supported;
} else if (asic == DMUB_ASIC_DCN315) {
dmub->regs_dcn31 = _srv_dcn315_regs;
} else if (asic == DMUB_ASIC_DCN316) {
Re: [PATCH v2 2/4] drm/amd/display: Set minimum requirement for using PSR-SU on Rembrandt
On 6/23/23 11:05, Mario Limonciello wrote:
A number of parade TCONs are causing system hangs when utilized with
older DMUB firmware and PSR-SU. Some changes have been introduced into
DMUB firmware to add resilience against these failures.
Don't allow running PSR-SU unless on the newer firmware.
Cc: Sean Wang
Cc: Marc Rossi
Cc: Hamza Mahfooz
Cc: Tsung-hua (Ryan) Lin
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2443
Signed-off-by: Mario Limonciello
Reviewed-by: Leo Li
---
v1->v2:
* Fix a s/dcn314/dcn31/ mixup
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c | 3 ++-
drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c | 7 +++
drivers/gpu/drm/amd/display/dc/dc_dmub_srv.h | 1 +
drivers/gpu/drm/amd/display/dmub/dmub_srv.h | 2 ++
drivers/gpu/drm/amd/display/dmub/src/dmub_dcn31.c | 5 +
drivers/gpu/drm/amd/display/dmub/src/dmub_dcn31.h | 2 ++
drivers/gpu/drm/amd/display/dmub/src/dmub_srv.c | 10 ++
7 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
index d647f68fd563..4f61d4f257cd 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
@@ -24,6 +24,7 @@
*/
#include "amdgpu_dm_psr.h"
+#include "dc_dmub_srv.h"
#include "dc.h"
#include "dm_helpers.h"
#include "amdgpu_dm.h"
@@ -50,7 +51,7 @@ static bool link_supports_psrsu(struct dc_link *link)
!link->dpcd_caps.psr_info.psr2_su_y_granularity_cap)
return false;
- return true;
+ return dc_dmub_check_min_version(dc->ctx->dmub_srv->dmub);
}
/*
diff --git a/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
b/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
index c52c40b16387..c753c6f30dd7 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
+++ b/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
@@ -1011,3 +1011,10 @@ void dc_send_update_cursor_info_to_dmu(
dm_execute_dmub_cmd_list(pCtx->stream->ctx, 2, cmd,
DM_DMUB_WAIT_TYPE_WAIT);
}
}
+
+bool dc_dmub_check_min_version(struct dmub_srv *srv)
+{
+ if (!srv->hw_funcs.is_psrsu_supported)
+ return true;
+ return srv->hw_funcs.is_psrsu_supported(srv);
+}
diff --git a/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.h
b/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.h
index a5196a9292b3..099f94b6107c 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.h
+++ b/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.h
@@ -86,4 +86,5 @@ void dc_dmub_setup_subvp_dmub_command(struct dc *dc, struct
dc_state *context, b
void dc_dmub_srv_log_diagnostic_data(struct dc_dmub_srv *dc_dmub_srv);
void dc_send_update_cursor_info_to_dmu(struct pipe_ctx *pCtx, uint8_t pipe_idx);
+bool dc_dmub_check_min_version(struct dmub_srv *srv);
#endif /* _DMUB_DC_SRV_H_ */
diff --git a/drivers/gpu/drm/amd/display/dmub/dmub_srv.h
b/drivers/gpu/drm/amd/display/dmub/dmub_srv.h
index 2a66a305679a..4585e0419da6 100644
--- a/drivers/gpu/drm/amd/display/dmub/dmub_srv.h
+++ b/drivers/gpu/drm/amd/display/dmub/dmub_srv.h
@@ -367,6 +367,8 @@ struct dmub_srv_hw_funcs {
bool (*is_supported)(struct dmub_srv *dmub);
+ bool (*is_psrsu_supported)(struct dmub_srv *dmub);
+
bool (*is_hw_init)(struct dmub_srv *dmub);
void (*enable_dmub_boot_options)(struct dmub_srv *dmub,
diff --git a/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn31.c
b/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn31.c
index ebf7aeec4029..c8445d474107 100644
--- a/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn31.c
+++ b/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn31.c
@@ -302,6 +302,11 @@ bool dmub_dcn31_is_supported(struct dmub_srv *dmub)
return supported;
}
+bool dmub_dcn31_is_psrsu_supported(struct dmub_srv *dmub)
+{
+ return dmub->fw_version >= DMUB_FW_VERSION(4, 0, 58);
+}
+
void dmub_dcn31_set_gpint(struct dmub_srv *dmub,
union dmub_gpint_data_register reg)
{
diff --git a/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn31.h
b/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn31.h
index 7d5c10ee539b..89c5a948b67d 100644
--- a/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn31.h
+++ b/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn31.h
@@ -221,6 +221,8 @@ bool dmub_dcn31_is_hw_init(struct dmub_srv *dmub);
bool dmub_dcn31_is_supported(struct dmub_srv *dmub);
+bool dmub_dcn31_is_psrsu_supported(struct dmub_srv *dmub);
+
void dmub_dcn31_set_gpint(struct dmub_srv *dmub,
union dmub_gpint_data_register reg);
diff --git a/drivers/gpu/drm/amd/display/dmub/src/dmub_srv.c b/drivers/gpu/drm/amd/display/dmub/src/dmub_srv.c
index 9e9a6a44a7ac..7a31e3e27bab 100644
--- a/drivers/gpu/drm/amd/display/dmub/src/dmub_srv.c
+++
Re: [PATCH 4/4] Revert "drm/amd: Disable PSR-SU on Parade 0803 TCON"
On 6/22/23 14:25, Mario Limonciello wrote: This reverts commit 33eec907ce0eb50a56dca621aa7310f7fa904b93. This is no longer necessary when using newer DMUB F/W. Cc: Sean Wang Cc: Marc Rossi Cc: Hamza Mahfooz Cc: Tsung-hua (Ryan) Lin Signed-off-by: Mario Limonciello Reviewed-by: Leo Li --- drivers/gpu/drm/amd/display/modules/power/power_helpers.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/modules/power/power_helpers.c b/drivers/gpu/drm/amd/display/modules/power/power_helpers.c index b9e78451a3d5..30349881a283 100644 --- a/drivers/gpu/drm/amd/display/modules/power/power_helpers.c +++ b/drivers/gpu/drm/amd/display/modules/power/power_helpers.c @@ -839,8 +839,6 @@ bool is_psr_su_specific_panel(struct dc_link *link) ((dpcd_caps->sink_dev_id_str[1] == 0x08 && dpcd_caps->sink_dev_id_str[0] == 0x08) || (dpcd_caps->sink_dev_id_str[1] == 0x08 && dpcd_caps->sink_dev_id_str[0] == 0x07))) isPSRSUSupported = false; - else if (dpcd_caps->sink_dev_id_str[1] == 0x08 && dpcd_caps->sink_dev_id_str[0] == 0x03) - isPSRSUSupported = false; else if (dpcd_caps->psr_info.force_psrsu_cap == 0x1) isPSRSUSupported = true; }
Re: [PATCH 1/4] drm/amd/display: Correct `DMUB_FW_VERSION` macro
On 6/22/23 14:25, Mario Limonciello wrote:
The `DMUB_FW_VERSION` macro has a mistake in that the revision field
is off by one byte. The last byte is typically used for other purposes
and not a revision.
Cc: Sean Wang
Cc: Marc Rossi
Cc: Hamza Mahfooz
Cc: Tsung-hua (Ryan) Lin
Signed-off-by: Mario Limonciello
Reviewed-by: Leo Li
---
drivers/gpu/drm/amd/display/dmub/dmub_srv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dmub/dmub_srv.h
b/drivers/gpu/drm/amd/display/dmub/dmub_srv.h
index 7c9a2b34bd05..2a66a305679a 100644
--- a/drivers/gpu/drm/amd/display/dmub/dmub_srv.h
+++ b/drivers/gpu/drm/amd/display/dmub/dmub_srv.h
@@ -492,7 +492,7 @@ struct dmub_notification {
* of a firmware to know if feature or functionality is supported or present.
*/
#define DMUB_FW_VERSION(major, minor, revision) \
- major) & 0xFF) << 24) | (((minor) & 0xFF) << 16) | ((revision) &
0x))
+ major) & 0xFF) << 24) | (((minor) & 0xFF) << 16) | (((revision) & 0xFF)
<< 8))
/**
* dmub_srv_create() - creates the DMUB service.
Re: [PATCH 2/4] drm/amd/display: Set minimum requirement for using PSR-SU on Rembrandt
bool dmub_srv_hw_setup(struct dmub_srv *dmub, enum
dmub_asic asic)
case DMUB_ASIC_DCN314:
case DMUB_ASIC_DCN315:
case DMUB_ASIC_DCN316:
- if (asic == DMUB_ASIC_DCN314)
+ if (asic == DMUB_ASIC_DCN314) {
dmub->regs_dcn31 = _srv_dcn314_regs;
- else if (asic == DMUB_ASIC_DCN315)
+ funcs->is_psrsu_supported =
dmub_dcn314_is_psrsu_supported;
+ } else if (asic == DMUB_ASIC_DCN315) {
dmub->regs_dcn31 = _srv_dcn315_regs;
- else if (asic == DMUB_ASIC_DCN316)
+ } else if (asic == DMUB_ASIC_DCN316) {
dmub->regs_dcn31 = _srv_dcn316_regs;
- else
+ } else {
dmub->regs_dcn31 = _srv_dcn31_regs;
+ }
Should these hunks be rolled into 3/4? dmub_dcn314_is_psrsu_supported is
defined there.
Thanks,
Leo
funcs->reset = dmub_dcn31_reset;
funcs->reset_release = dmub_dcn31_reset_release;
funcs->backdoor_load = dmub_dcn31_backdoor_load;
Re: [PATCH] drm/amdgpu/vcn: Need to unpause dpg before stop dpg
Reviewed-by: Leo Liu
On 2023-06-20 21:29, Emily Deng wrote:
Need to unpause dpg first, or it will hit follow error during stop dpg:
"[drm] Register(1) [regUVD_POWER_STATUS] failed to reach value 0x0001 !=
0xn"
Signed-off-by: Emily Deng
---
drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
index b48bb5212488..259795098173 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
@@ -1424,8 +1424,10 @@ static int vcn_v4_0_start_sriov(struct amdgpu_device
*adev)
*/
static void vcn_v4_0_stop_dpg_mode(struct amdgpu_device *adev, int inst_idx)
{
+ struct dpg_pause_state state = {.fw_based = VCN_DPG_STATE__UNPAUSE};
uint32_t tmp;
+ vcn_v4_0_pause_dpg_mode(adev, inst_idx, );
/* Wait for power status to be 1 */
SOC15_WAIT_ON_RREG(VCN, inst_idx, regUVD_POWER_STATUS, 1,
UVD_POWER_STATUS__UVD_POWER_STATUS_MASK);
Re: [PATCH] drm/amd/display: perform a bounds check before filling dirty rectangles
On 6/21/23 17:57, Hamza Mahfooz wrote:
Currently, it is possible for us to access memory that we shouldn't.
Since, we acquire (possibly dangling) pointers to dirty rectangles
before doing a bounds check to make sure we can actually accommodate the
number of dirty rectangles userspace has requested to fill. This issue
is especially evident if a compositor requests both MPO and damage clips
at the same time, in which case I have observed a soft-hang. So, to
avoid this issue, perform the bounds check before filling a single dirty
rectangle and WARN() about it, if it is ever attempted in
fill_dc_dirty_rect().
Cc: sta...@vger.kernel.org # 6.1+
Fixes: 30ebe41582d1 ("drm/amd/display: add FB_DAMAGE_CLIPS support")
Signed-off-by: Hamza Mahfooz
Reviewed-by: Leo Li
Thanks!
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 64b8dcf8dbda..66bb03d503ea 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5065,11 +5065,7 @@ static inline void fill_dc_dirty_rect(struct drm_plane
*plane,
s32 y, s32 width, s32 height,
int *i, bool ffu)
{
- if (*i > DC_MAX_DIRTY_RECTS)
- return;
-
- if (*i == DC_MAX_DIRTY_RECTS)
- goto out;
+ WARN_ON(*i >= DC_MAX_DIRTY_RECTS);
dirty_rect->x = x;
dirty_rect->y = y;
@@ -5085,7 +5081,6 @@ static inline void fill_dc_dirty_rect(struct drm_plane
*plane,
"[PLANE:%d] PSR SU dirty rect at (%d, %d) size (%d,
%d)",
plane->base.id, x, y, width, height);
-out:
(*i)++;
}
@@ -5172,6 +5167,9 @@ static void fill_dc_dirty_rects(struct drm_plane *plane,
*dirty_regions_changed = bb_changed;
+ if ((num_clips + (bb_changed ? 2 : 0)) > DC_MAX_DIRTY_RECTS)
+ goto ffu;
+
if (bb_changed) {
fill_dc_dirty_rect(new_plane_state->plane, _rects[i],
new_plane_state->crtc_x,
@@ -5201,9 +5199,6 @@ static void fill_dc_dirty_rects(struct drm_plane *plane,
new_plane_state->crtc_h, , false);
}
- if (i > DC_MAX_DIRTY_RECTS)
- goto ffu;
-
flip_addrs->dirty_rect_count = i;
return;
RE: [PATCH] drm/amdgpu/vcn: Need to pause dpg before stop dpg
[AMD Official Use Only - General]
Hi Emily,
Do you want to pause or un-pause dpg mode based on and change and commit
message?
With bare metal, before calling the stop, the state of dpg should be un-paused
within the call the of amdgpu_vcn_idle_work_handler, is it not the case for
SRIOV?
Regards,
Leo
-Original Message-
From: amd-gfx On Behalf Of Emily Deng
Sent: Monday, June 19, 2023 6:24 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deng, Emily
Subject: [PATCH] drm/amdgpu/vcn: Need to pause dpg before stop dpg
Need to pause dpg first, or it will hit follow error during stop dpg:
"[drm] Register(1) [regUVD_POWER_STATUS] failed to reach value 0x0001 !=
0xn"
Signed-off-by: Emily Deng
---
drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
index b48bb5212488..259795098173 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
@@ -1424,8 +1424,10 @@ static int vcn_v4_0_start_sriov(struct amdgpu_device
*adev)
*/
static void vcn_v4_0_stop_dpg_mode(struct amdgpu_device *adev, int inst_idx) {
+ struct dpg_pause_state state = {.fw_based = VCN_DPG_STATE__UNPAUSE};
uint32_t tmp;
+ vcn_v4_0_pause_dpg_mode(adev, inst_idx, );
/* Wait for power status to be 1 */
SOC15_WAIT_ON_RREG(VCN, inst_idx, regUVD_POWER_STATUS, 1,
UVD_POWER_STATUS__UVD_POWER_STATUS_MASK);
--
2.36.1
Re: [PATCH] drm/amdgpu: vcn_4_0 set instance 0 init sched score to 1
[Public] Reviewed-by: Leo Liu From: amd-gfx on behalf of Sonny Jiang Sent: June 8, 2023 10:54 AM To: amd-gfx@lists.freedesktop.org Cc: Jiang, Sonny Subject: [PATCH] drm/amdgpu: vcn_4_0 set instance 0 init sched score to 1 From: Sonny Jiang Only vcn0 can process AV1 codecx. In order to use both vcn0 and vcn1 in h264/265 transcode to AV1 cases, set vcn0 sched score to 1 at initialization time. Signed-off-by: Sonny Jiang --- drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c index 8d371faaa2b3..b48bb5212488 100644 --- a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c +++ b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c @@ -129,7 +129,11 @@ static int vcn_v4_0_sw_init(void *handle) if (adev->vcn.harvest_config & (1 << i)) continue; - atomic_set(>vcn.inst[i].sched_score, 0); + /* Init instance 0 sched_score to 1, so it's scheduled after other instances */ + if (i == 0) + atomic_set(>vcn.inst[i].sched_score, 1); + else + atomic_set(>vcn.inst[i].sched_score, 0); /* VCN UNIFIED TRAP */ r = amdgpu_irq_add_id(adev, amdgpu_ih_clientid_vcns[i], -- 2.34.1
Re: [regression][6.0] After commit b261509952bc19d1012cf732f853659be6ebc61e I see WARNING message at drivers/gpu/drm/drm_modeset_lock.c:276 drm_modeset_drop_locks+0x63/0x70
Hi Mikhail, seems like your report flew past me, thanks for the ping. This might be a simple issue of not backing off when deadlock was hit. drm_atomic_normalize_zpos() can return an error code, and I ignored it (oops!) Can you give this patch a try? https://gitlab.freedesktop.org/-/snippets/7414 - Leo On 2/9/23 04:27, Mikhail Gavrilov wrote: Harry, please don't ignore me. This issue still happens in 6.1 and 6.2 Leo you are the author of the problematic commit please don't stand aside. Really nobody is interested in clean logs without warnings and errors? I am 100% sure that reverting commit b261509952bc19d1012cf732f853659be6ebc61e will stop these warnings. I also attached fresh logs from 6.2.0-0.rc6. 6.2-rc7 I started to build without commit b261509952bc19d1012cf732f853659be6ebc61e to avoid these warnings. On Thu, Oct 13, 2022 at 6:36 PM Mikhail Gavrilov Hi! I bisected an issue of the 6.0 kernel which started happening after 6.0-rc7 on all my machines. Backtrace of this issue looks like as: [ 2807.339439] [ cut here ] [ 2807.339445] WARNING: CPU: 11 PID: 2061 at drivers/gpu/drm/drm_modeset_lock.c:276 drm_modeset_drop_locks+0x63/0x70 [ 2807.339453] Modules linked in: tls uinput rfcomm snd_seq_dummy snd_hrtimer nft_objref nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables nfnetlink qrtr bnep intel_rapl_msr intel_rapl_common snd_sof_amd_renoir snd_sof_amd_acp snd_sof_pci snd_hda_codec_realtek sunrpc snd_sof snd_hda_codec_hdmi snd_hda_codec_generic snd_sof_utils snd_hda_intel snd_intel_dspcfg mt7921e snd_intel_sdw_acpi binfmt_misc snd_soc_core mt7921_common snd_hda_codec snd_compress vfat ac97_bus edac_mce_amd mt76_connac_lib snd_pcm_dmaengine fat snd_hda_core snd_rpl_pci_acp6x snd_pci_acp6x mt76 btusb snd_hwdep kvm_amd btrtl snd_seq btbcm mac80211 snd_seq_device kvm btintel btmtk libarc4 snd_pcm snd_pci_acp5x bluetooth snd_timer snd_rn_pci_acp3x irqbypass snd_acp_config snd_soc_acpi cfg80211 rapl snd joydev pcspkr asus_nb_wmi wmi_bmof [ 2807.339519] snd_pci_acp3x soundcore i2c_piix4 k10temp amd_pmc asus_wireless zram amdgpu drm_ttm_helper ttm hid_asus asus_wmi crct10dif_pclmul iommu_v2 crc32_pclmul ledtrig_audio crc32c_intel gpu_sched sparse_keymap platform_profile hid_multitouch polyval_clmulni nvme ucsi_acpi drm_buddy polyval_generic drm_display_helper ghash_clmulni_intel serio_raw nvme_core ccp typec_ucsi rfkill sp5100_tco r8169 cec nvme_common typec wmi video i2c_hid_acpi i2c_hid ip6_tables ip_tables fuse [ 2807.339540] Unloaded tainted modules: acpi_cpufreq():1 acpi_cpufreq():1 acpi_cpufreq():1 acpi_cpufreq():1 acpi_cpufreq():1 acpi_cpufreq():1 acpi_cpufreq():1 acpi_cpufreq():1 acpi_cpufreq():1 amd64_edac():1 acpi_cpufreq():1 acpi_cpufreq():1 amd64_edac():1 amd64_edac():1 acpi_cpufreq():1 pcc_cpufreq():1 fjes():1 amd64_edac():1 acpi_cpufreq():1 amd64_edac():1 acpi_cpufreq():1 fjes():1 pcc_cpufreq():1 amd64_edac():1 acpi_cpufreq():1 fjes():1 amd64_edac():1 acpi_cpufreq():1 pcc_cpufreq():1 amd64_edac():1 fjes():1 acpi_cpufreq():1 acpi_cpufreq():1 pcc_cpufreq():1 amd64_edac():1 fjes():1 acpi_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 acpi_cpufreq():1 fjes():1 amd64_edac():1 pcc_cpufreq():1 pcc_cpufreq():1 amd64_edac():1 acpi_cpufreq():1 fjes():1 pcc_cpufreq():1 amd64_edac():1 acpi_cpufreq():1 acpi_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 fjes():1 acpi_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 acpi_cpufreq():1 fjes():1 pcc_cpufreq():1 acpi_cpufreq():1 pcc_cpufreq():1 fjes():1 [ 2807.339579] acpi_cpufreq():1 fjes():1 pcc_cpufreq():1 acpi_cpufreq():1 pcc_cpufreq():1 acpi_cpufreq():1 fjes():1 acpi_cpufreq():1 pcc_cpufreq():1 fjes():1 pcc_cpufreq():1 acpi_cpufreq():1 fjes():1 acpi_cpufreq():1 fjes():1 fjes():1 fjes():1 fjes():1 fjes():1 fjes():1 fjes():1 fjes():1 fjes():1 fjes():1 fjes():1 fjes():1 fjes():1 fjes():1 [ 2807.339596] CPU: 11 PID: 2061 Comm: gnome-shell Tainted: GW L 6.0.0-rc4-07-cb0eca01ad9756e853efec3301203c2b5b45aa9f+ #16 [ 2807.339598] Hardware name: ASUSTeK COMPUTER INC. ROG Strix G513QY_G513QY/G513QY, BIOS G513QY.318 03/29/2022 [ 2807.339600] RIP: 0010:drm_modeset_drop_locks+0x63/0x70 [ 2807.339602] Code: 42 08 48 89 10 48 89 1b 48 8d bb 50 ff ff ff 48 89 5b 08 e8 3f 41 55 00 48 8b 45 78 49 39 c4 75 c6 5b 5d 41 5c c3 cc cc cc cc <0f> 0b eb ac 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 55 41 54 [ 2807.339604] RSP: 0018:b6ad46e07b80 EFLAGS: 00010282 [ 2807.339606] RAX: 0001 RBX: RCX: 0002 [ 2807.339607] RDX: 0001 RSI: a6a118b1 RDI: b6ad46e07c00 [ 2807.339608] RBP: b6ad46e07c00 R08: R09: [ 2807.339609] R10: R11: 0001 R12: [ 2807.339610] R13: 9801ca24bb00 R14: 9801ca24bb
Re: [PATCH v2 10/21] drm/amd/display: Signal mode_changed if colorspace changed
On 1/13/23 11:24, Harry Wentland wrote:
We need to signal mode_changed to make sure we update the output
colorspace.
v2: No need to call drm_hdmi_avi_infoframe_colorimetry as DC does its
own infoframe packing.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: dri-de...@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-by: Leo Li
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index c311135f1e6f..f74462c282a6 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6492,6 +6492,14 @@ amdgpu_dm_connector_atomic_check(struct drm_connector
*conn,
if (!crtc)
return 0;
+ if (new_con_state->colorspace != old_con_state->colorspace) {
+ new_crtc_state = drm_atomic_get_crtc_state(state, crtc);
+ if (IS_ERR(new_crtc_state))
+ return PTR_ERR(new_crtc_state);
+
+ new_crtc_state->mode_changed = true;
+ }
+
if (!drm_connector_atomic_hdr_metadata_equal(old_con_state,
new_con_state)) {
struct dc_info_packet hdr_infopacket;
@@ -6514,7 +6522,7 @@ amdgpu_dm_connector_atomic_check(struct drm_connector *conn,
* set is permissible, however. So only force a
* modeset if we're entering or exiting HDR.
*/
- new_crtc_state->mode_changed =
+ new_crtc_state->mode_changed = new_crtc_state->mode_changed ||
!old_con_state->hdr_output_metadata ||
!new_con_state->hdr_output_metadata;
}
Re: [PATCH v2 17/21] drm/amd/display: Format input and output CSC matrix
On 1/13/23 11:24, Harry Wentland wrote:
Format the input and output CSC matrix so they
look like 3x4 matrixes. This will make parsing them
much easier and allows us to quickly spot potential
mistakes.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton
Cc: dri-de...@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-by: Leo Li
---
.../drm/amd/display/dc/core/dc_hw_sequencer.c | 38 -
drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h | 54 +++
2 files changed, 56 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_hw_sequencer.c
b/drivers/gpu/drm/amd/display/dc/core/dc_hw_sequencer.c
index 471078fc3900..a70f045fc5c1 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_hw_sequencer.c
@@ -73,28 +73,38 @@ struct out_csc_color_matrix_type {
static const struct out_csc_color_matrix_type output_csc_matrix[] = {
{ COLOR_SPACE_RGB_TYPE,
- { 0x2000, 0, 0, 0, 0, 0x2000, 0, 0, 0, 0, 0x2000, 0} },
+ { 0x2000, 0, 0, 0,
+ 0, 0x2000, 0, 0,
+ 0, 0, 0x2000, 0} },
{ COLOR_SPACE_RGB_LIMITED_TYPE,
- { 0x1B67, 0, 0, 0x201, 0, 0x1B67, 0, 0x201, 0, 0, 0x1B67,
0x201} },
+ { 0x1B67, 0, 0, 0x201,
+ 0, 0x1B67, 0, 0x201,
+ 0, 0, 0x1B67, 0x201} },
{ COLOR_SPACE_YCBCR601_TYPE,
- { 0xE04, 0xF444, 0xFDB9, 0x1004, 0x831, 0x1016, 0x320, 0x201,
0xFB45,
- 0xF6B7, 0xE04, 0x1004} },
+ { 0xE04, 0xF444, 0xFDB9, 0x1004,
+ 0x831, 0x1016, 0x320, 0x201,
+ 0xFB45, 0xF6B7, 0xE04, 0x1004} },
{ COLOR_SPACE_YCBCR709_TYPE,
- { 0xE04, 0xF345, 0xFEB7, 0x1004, 0x5D3, 0x1399, 0x1FA,
- 0x201, 0xFCCA, 0xF533, 0xE04, 0x1004} },
+ { 0xE04, 0xF345, 0xFEB7, 0x1004,
+ 0x5D3, 0x1399, 0x1FA, 0x201,
+ 0xFCCA, 0xF533, 0xE04, 0x1004} },
/* TODO: correct values below */
{ COLOR_SPACE_YCBCR601_LIMITED_TYPE,
- { 0xE00, 0xF447, 0xFDB9, 0x1000, 0x991,
- 0x12C9, 0x3A6, 0x200, 0xFB47, 0xF6B9, 0xE00,
0x1000} },
+ { 0xE00, 0xF447, 0xFDB9, 0x1000,
+ 0x991, 0x12C9, 0x3A6, 0x200,
+ 0xFB47, 0xF6B9, 0xE00, 0x1000} },
{ COLOR_SPACE_YCBCR709_LIMITED_TYPE,
- { 0xE00, 0xF349, 0xFEB7, 0x1000, 0x6CE, 0x16E3,
- 0x24F, 0x200, 0xFCCB, 0xF535, 0xE00, 0x1000} },
+ { 0xE00, 0xF349, 0xFEB7, 0x1000,
+ 0x6CE, 0x16E3, 0x24F, 0x200,
+ 0xFCCB, 0xF535, 0xE00, 0x1000} },
{ COLOR_SPACE_YCBCR2020_TYPE,
- { 0x1000, 0xF149, 0xFEB7, 0x, 0x0868, 0x15B2,
- 0x01E6, 0x, 0xFB88, 0xF478, 0x1000, 0x}
},
+ { 0x1000, 0xF149, 0xFEB7, 0x,
+ 0x0868, 0x15B2, 0x01E6, 0x,
+ 0xFB88, 0xF478, 0x1000, 0x} },
{ COLOR_SPACE_YCBCR709_BLACK_TYPE,
- { 0x, 0x, 0x, 0x1000, 0x, 0x,
- 0x, 0x0200, 0x, 0x, 0x, 0x1000}
},
+ { 0x, 0x, 0x, 0x1000,
+ 0x, 0x, 0x, 0x0200,
+ 0x, 0x, 0x, 0x1000} },
};
static bool is_rgb_type(
diff --git a/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
b/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
index 131fcfa28bca..f4aa76e02518 100644
--- a/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
+++ b/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
@@ -70,28 +70,38 @@ struct dpp_input_csc_matrix {
};
static const struct dpp_input_csc_matrix __maybe_unused dpp_input_csc_matrix[] = {
- {COLOR_SPACE_SRGB,
- {0x2000, 0, 0, 0, 0, 0x2000, 0, 0, 0, 0, 0x2000, 0} },
- {COLOR_SPACE_SRGB_LIMITED,
- {0x2000, 0, 0, 0, 0, 0x2000, 0, 0, 0, 0, 0x2000, 0} },
- {COLOR_SPACE_YCBCR601,
- {0x2cdd, 0x2000, 0, 0xe991, 0xe926, 0x2000, 0xf4fd, 0x10ef,
- 0, 0x2000, 0x38b4, 0xe3a6} },
- {COLOR_SPACE_YCBCR601_LIMITED,
- {0x3353, 0x2568, 0, 0xe400, 0xe5dc, 0x2568, 0xf367, 0x1108,
- 0, 0x2568, 0x40de, 0xdd3a} },
- {COLOR_SPACE_YCBCR709,
- {0x3265, 0x2000, 0, 0xe6ce, 0xf105, 0x2000, 0xfa01, 0xa7d, 0,
- 0x2000, 0x3b61, 0xe24f} },
- {COLOR_SPACE_YCBCR709_LIMITED,
- {0x39a6, 0x2568, 0, 0xe0d6, 0xeedd, 0x2568, 0xf925, 0x9a8, 0,
- 0x2568, 0x43ee
RE: [PATCH 1/4] drm/amdgpu/nv: don't expose AV1 if VCN0 is harvested
[AMD Official Use Only - General]
The series are:
Reviewed-by: Leo Liu
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: January 17, 2023 3:00 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH 1/4] drm/amdgpu/nv: don't expose AV1 if VCN0 is harvested
Only VCN0 supports AV1.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/nv.c | 101 +---
1 file changed, 81 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c b/drivers/gpu/drm/amd/amdgpu/nv.c
index 6853b93ac82e..d972025f0d20 100644
--- a/drivers/gpu/drm/amd/amdgpu/nv.c
+++ b/drivers/gpu/drm/amd/amdgpu/nv.c
@@ -98,7 +98,7 @@ static const struct amdgpu_video_codecs
nv_video_codecs_decode = };
/* Sienna Cichlid */
-static const struct amdgpu_video_codec_info sc_video_codecs_decode_array[] =
+static const struct amdgpu_video_codec_info
+sc_video_codecs_decode_array_vcn0[] =
{
{codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_MPEG2, 4096, 4096,
3)},
{codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_MPEG4, 4096, 4096,
5)}, @@ -110,10 +110,27 @@ static const struct amdgpu_video_codec_info
sc_video_codecs_decode_array[] =
{codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_AV1, 8192, 4352,
0)}, };
-static const struct amdgpu_video_codecs sc_video_codecs_decode =
+static const struct amdgpu_video_codec_info
+sc_video_codecs_decode_array_vcn1[] =
{
- .codec_count = ARRAY_SIZE(sc_video_codecs_decode_array),
- .codec_array = sc_video_codecs_decode_array,
+ {codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_MPEG2, 4096, 4096,
3)},
+ {codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_MPEG4, 4096, 4096,
5)},
+ {codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_MPEG4_AVC, 4096,
4096, 52)},
+ {codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_VC1, 4096, 4096, 4)},
+ {codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_HEVC, 8192, 4352,
186)},
+ {codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_JPEG, 4096, 4096,
0)},
+ {codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_VP9, 8192, 4352,
+0)}, };
+
+static const struct amdgpu_video_codecs sc_video_codecs_decode_vcn0 = {
+ .codec_count = ARRAY_SIZE(sc_video_codecs_decode_array_vcn0),
+ .codec_array = sc_video_codecs_decode_array_vcn0,
+};
+
+static const struct amdgpu_video_codecs sc_video_codecs_decode_vcn1 = {
+ .codec_count = ARRAY_SIZE(sc_video_codecs_decode_array_vcn1),
+ .codec_array = sc_video_codecs_decode_array_vcn1,
};
/* SRIOV Sienna Cichlid, not const since data is controlled by host */ @@
-123,7 +140,7 @@ static struct amdgpu_video_codec_info
sriov_sc_video_codecs_encode_array[] =
{codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_HEVC, 4096, 2304,
0)}, };
-static struct amdgpu_video_codec_info sriov_sc_video_codecs_decode_array[] =
+static struct amdgpu_video_codec_info
+sriov_sc_video_codecs_decode_array_vcn0[] =
{
{codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_MPEG2, 4096, 4096,
3)},
{codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_MPEG4, 4096, 4096,
5)}, @@ -135,16 +152,33 @@ static struct amdgpu_video_codec_info
sriov_sc_video_codecs_decode_array[] =
{codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_AV1, 8192, 4352,
0)}, };
+static struct amdgpu_video_codec_info
+sriov_sc_video_codecs_decode_array_vcn1[] = {
+ {codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_MPEG2, 4096, 4096,
3)},
+ {codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_MPEG4, 4096, 4096,
5)},
+ {codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_MPEG4_AVC, 4096,
4096, 52)},
+ {codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_VC1, 4096, 4096, 4)},
+ {codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_HEVC, 8192, 4352,
186)},
+ {codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_JPEG, 4096, 4096,
0)},
+ {codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_VP9, 8192, 4352,
+0)}, };
+
static struct amdgpu_video_codecs sriov_sc_video_codecs_encode = {
.codec_count = ARRAY_SIZE(sriov_sc_video_codecs_encode_array),
.codec_array = sriov_sc_video_codecs_encode_array,
};
-static struct amdgpu_video_codecs sriov_sc_video_codecs_decode =
+static struct amdgpu_video_codecs sriov_sc_video_codecs_decode_vcn0 =
{
- .codec_count = ARRAY_SIZE(sriov_sc_video_codecs_decode_array),
- .codec_array = sriov_sc_video_codecs_decode_array,
+ .codec_count = ARRAY_SIZE(sriov_sc_video_codecs_decode_array_vcn0),
+ .codec_array = sriov_sc_video_codecs_decode_array_vcn0,
+};
+
+static struct amdgpu_video_codecs sriov_sc_video_codecs_decode_vcn1 = {
+ .codec_count = ARRAY_SIZE(sriov_sc_video_codecs_decode_array_vcn1),
+ .codec_array = sriov_sc_video_codecs_decode_array_vcn1,
};
/* Beige Goby*/
@@ -181,20 +215,37 @@ static const struct amdgpu_video_codecs
yc_video_codecs_decode
Re: [PATCH 3/3] drm/amdgpu/vcn: Add parameter to force (en/dis)abling indirect SRAM mode
Secure part requires PSP load VCN boot sequence which is with indirect sram mode. Regards, Leo From: Alex Deucher Sent: January 16, 2023 4:50 PM To: Guilherme G. Piccoli Cc: amd-gfx@lists.freedesktop.org ; Jiang, Sonny ; ker...@gpiccoli.net ; Pan, Xinhui ; dri-de...@lists.freedesktop.org ; Lazar, Lijo ; Limonciello, Mario ; kernel-...@igalia.com ; Deucher, Alexander ; Zhu, James ; Liu, Leo ; Koenig, Christian Subject: Re: [PATCH 3/3] drm/amdgpu/vcn: Add parameter to force (en/dis)abling indirect SRAM mode On Mon, Jan 16, 2023 at 4:21 PM Guilherme G. Piccoli wrote: > > Currently the FW loading path perform some checks based on IP model > and in case it is advertised as supported, the VCN indirect SRAM > mode is used. > > Happens that in case there's any issue on FW and this mode ends-up > not being properly supported, the driver probe fails [0]. Debugging > this requires driver rebuilding, so to allow fast debug and experiments, > add a parameter to force setting indirect SRAM mode to true/false from > the kernel command-line; parameter default is -1, which doesn't change > the current driver's behavior. Probably a question for Leo or James, but I was under the impression non-indirect mode didn't work on production silicon for most chips, but maybe I'm mis-remembering that. Alex > > [0] Example of this issue, observed on Steam Deck: > > [drm] kiq ring mec 2 pipe 1 q 0 > [drm] failed to load ucode VCN0_RAM(0x3A) > [drm] psp gfx command LOAD_IP_FW(0x6) failed and response status is > (0x) > amdgpu :04:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring > vcn_dec_0 test failed (-110) > [drm:amdgpu_device_init.cold [amdgpu]] *ERROR* hw_init of IP block > failed -110 > amdgpu :04:00.0: amdgpu: amdgpu_device_ip_init failed > amdgpu :04:00.0: amdgpu: Fatal error during GPU init > > Cc: James Zhu > Cc: Lazar Lijo > Cc: Leo Liu > Cc: Mario Limonciello > Cc: Sonny Jiang > Signed-off-by: Guilherme G. Piccoli > --- > > > This work is based on agd5f/amd-staging-drm-next branch. > Thanks in advance for reviews/comments! > Cheers, > > Guilherme > > > drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 + > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 9 + > drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 3 +++ > 3 files changed, 13 insertions(+) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h > b/drivers/gpu/drm/amd/amdgpu/amdgpu.h > index 872450a3a164..5d3c92c94f18 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h > @@ -215,6 +215,7 @@ extern int amdgpu_noretry; > extern int amdgpu_force_asic_type; > extern int amdgpu_smartshift_bias; > extern int amdgpu_use_xgmi_p2p; > +extern int amdgpu_indirect_sram; > #ifdef CONFIG_HSA_AMD > extern int sched_policy; > extern bool debug_evictions; > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > index 06aba201d4db..c7182c0bc841 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > @@ -187,6 +187,7 @@ int amdgpu_num_kcq = -1; > int amdgpu_smartshift_bias; > int amdgpu_use_xgmi_p2p = 1; > int amdgpu_vcnfw_log; > +int amdgpu_indirect_sram = -1; > > static void amdgpu_drv_delayed_reset_work_handler(struct work_struct *work); > > @@ -941,6 +942,14 @@ MODULE_PARM_DESC(smu_pptable_id, > "specify pptable id to be used (-1 = auto(default) value, 0 = use > pptable from vbios, > 0 = soft pptable id)"); > module_param_named(smu_pptable_id, amdgpu_smu_pptable_id, int, 0444); > > +/** > + * DOC: indirect_sram (int) > + * Allow users to force using (or not) the VCN indirect SRAM mode in the fw > load > + * code. Default is -1, meaning auto (aka, don't mess with driver's > behavior). > + */ > +MODULE_PARM_DESC(indirect_sram, "Force VCN indirect SRAM (-1 = auto > (default), 0 = disabled, 1 = enabled)"); > +module_param_named(indirect_sram, amdgpu_indirect_sram, int, 0444); > + > /* These devices are not supported by amdgpu. > * They are supported by the mach64, r128, radeon drivers > */ > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c > index 1f880e162d9d..a2290087e01c 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c > @@ -137,6 +137,9 @@ int amdgpu_vcn_sw_init(struct amdgpu_device *adev) > return -EINVAL; > } > > + if (amdgpu_indirect_sram >= 0) > + adev->vcn.indirect_sram = (bool)amdgpu_indirect_sram; > + > hdr = (const struct common_firmware_header *)adev->vcn.fw->data; > adev->vcn.fw_version = le32_to_cpu(hdr->ucode_version); > > -- > 2.39.0 >
[PATCH] drm/amdgpu: Use the sched from entity for amdgpu_cs trace
The problem is that base sched hasn't been assigned yet at this moment, causing
something like "ring=0"
all the time from trace.
mpv:cs0-3473[002] . 129.047431: amdgpu_cs:
bo_list=92ffb3070400, ring=0, dw=48, fences=0
mpv:cs0-3473[002] . 129.089125: amdgpu_cs:
bo_list=92ffba4b7000, ring=0, dw=48, fences=0
mpv:cs0-3473[002] . 129.130987: amdgpu_cs:
bo_list=92ff84831c00, ring=0, dw=48, fences=0
mpv:cs0-3473[002] . 129.172478: amdgpu_cs:
bo_list=92ffa4b84c00, ring=0, dw=48, fences=0
mpv:cs0-3473[003] . 129.214000: amdgpu_cs:
bo_list=92ffb405b400, ring=0, dw=48, fences=0
mpv:cs0-3473[003] . 129.255763: amdgpu_cs:
bo_list=92ffba4b7000, ring=0, dw=48, fences=0
mpv:cs0-3473[003] . 129.297316: amdgpu_cs:
bo_list=92ffa4b84c00, ring=0, dw=48, fences=0
mpv:cs0-3473[003] . 129.338978: amdgpu_cs:
bo_list=92ff84831c00, ring=0, dw=48, fences=0
mpv:cs0-3473[003] . 129.380685: amdgpu_cs:
bo_list=92ffba4b7000, ring=0, dw=48, fences=0
mpv:cs0-3473[003] . 129.421993: amdgpu_cs:
bo_list=92ffdb4c3400, ring=0, dw=48, fences=0
Fixes: 4624459c84d7 ("drm/amdgpu: add gang submit frontend v6")
Signed-off-by: Leo Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
index 5e6ddc7e101c..6cd6ea765d37 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
@@ -153,10 +153,10 @@ TRACE_EVENT(amdgpu_cs,
TP_fast_assign(
__entry->bo_list = p->bo_list;
- __entry->ring = to_amdgpu_ring(job->base.sched)->idx;
+ __entry->ring =
to_amdgpu_ring(job->base.entity->rq->sched)->idx;
__entry->dw = ib->length_dw;
__entry->fences = amdgpu_fence_count_emitted(
- to_amdgpu_ring(job->base.sched));
+ to_amdgpu_ring(job->base.entity->rq->sched));
),
TP_printk("bo_list=%p, ring=%u, dw=%u, fences=%u",
__entry->bo_list, __entry->ring, __entry->dw,
--
2.25.1
RE: [PATCH] drm/amdgpu/vcn4: add missing encoder cap
[AMD Official Use Only - General]
Reviewed-by: Leo Liu
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: January 10, 2023 5:48 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH] drm/amdgpu/vcn4: add missing encoder cap
VCN4.x supports AV1 encode.
Fixes: 9ac0edaa0f8323 ("drm/amdgpu: add vcn_4_0_0 video codec query")
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/soc21.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/soc21.c
b/drivers/gpu/drm/amd/amdgpu/soc21.c
index 5562670b7b52..bea6b499568a 100644
--- a/drivers/gpu/drm/amd/amdgpu/soc21.c
+++ b/drivers/gpu/drm/amd/amdgpu/soc21.c
@@ -52,6 +52,7 @@ static const struct amdgpu_video_codec_info
vcn_4_0_0_video_codecs_encode_array[
{
{codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_MPEG4_AVC, 4096,
2304, 0)},
{codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_HEVC, 4096, 2304,
0)},
+ {codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_AV1, 8192, 4352, 0)},
};
static const struct amdgpu_video_codecs vcn_4_0_0_video_codecs_encode =
--
2.39.0
Re: [PATCH v2] drm/amd/display: fix PSR-SU/DSC interoperability support
On 1/5/23 15:07, Hamza Mahfooz wrote:
On 1/5/23 13:29, Harry Wentland wrote:
On 1/5/23 12:38, Hamza Mahfooz wrote:
Currently, there are issues with enabling PSR-SU + DSC. This stems from
the fact that DSC imposes a slice height on transmitted video data and
we are not conforming to that slice height in PSR-SU regions. So, pass
slice_height into su_y_granularity to feed the DSC slice height into
PSR-SU code.
Signed-off-by: Hamza Mahfooz
---
v2: move code to modules/power.
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c | 3 ++
.../amd/display/modules/power/power_helpers.c | 35 +++
.../amd/display/modules/power/power_helpers.h | 3 ++
3 files changed, 41 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
index 26291db0a3cf..872d06fe1436 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
@@ -122,6 +122,9 @@ bool amdgpu_dm_link_setup_psr(struct
dc_stream_state *stream)
psr_config.allow_multi_disp_optimizations =
(amdgpu_dc_feature_mask & DC_PSR_ALLOW_MULTI_DISP_OPT);
+ if (!psr_su_set_y_granularity(dc, link, stream, _config))
+ return false;
+
ret = dc_link_setup_psr(link, stream, _config,
_context);
}
diff --git
a/drivers/gpu/drm/amd/display/modules/power/power_helpers.c
b/drivers/gpu/drm/amd/display/modules/power/power_helpers.c
index 9b5d9b2c9a6a..4d27ad9f7370 100644
--- a/drivers/gpu/drm/amd/display/modules/power/power_helpers.c
+++ b/drivers/gpu/drm/amd/display/modules/power/power_helpers.c
@@ -916,3 +916,38 @@ bool mod_power_only_edp(const struct dc_state
*context, const struct dc_stream_s
{
return context && context->stream_count == 1 &&
dc_is_embedded_signal(stream->signal);
}
+
+bool psr_su_set_y_granularity(struct dc *dc, struct dc_link *link,
+ struct dc_stream_state *stream,
+ struct psr_config *config)
+{
+ uint16_t pic_height;
+ uint8_t slice_height;
+
+ if (!dc->caps.edp_dsc_support ||
+ link->panel_config.dsc.disable_dsc_edp ||
+
!link->dpcd_caps.dsc_caps.dsc_basic_caps.fields.dsc_support.DSC_SUPPORT ||
+ !stream->timing.dsc_cfg.num_slices_v)
I'm not sure this condition is correct. We can have DSC but not eDP DSC
support.
AFAIK PSR-SU displays use eDP exclusively, so we shouldn't have to worry
about this case.
Right, the dc_link here should only be eDP. I suppose that isn't quite
clear.
Maybe add this as part of the condition?
if (!(link->connector_signal & SIGNAL_TYPE_EDP))
return true;
Thanks,
Leo
+ return true;
+
+ pic_height = stream->timing.v_addressable +
+ stream->timing.v_border_top + stream->timing.v_border_bottom;
+ slice_height = pic_height / stream->timing.dsc_cfg.num_slices_v;
+
+ if (slice_height) {
+ if (config->su_y_granularity &&
+ (slice_height % config->su_y_granularity)) {
+ WARN(1,
We don't use WARN in display/dc or display/modules. DC_LOG_WARNING
might be better, or log it in the caller.
Harry
+ "%s: dsc: %d, slice_height: %d, num_slices_v: %d\n",
+ __func__,
+ stream->sink->dsc_caps.dsc_dec_caps.is_dsc_supported,
+ slice_height,
+ stream->timing.dsc_cfg.num_slices_v);
+ return false;
+ }
+
+ config->su_y_granularity = slice_height;
+ }
+
+ return true;
+}
diff --git
a/drivers/gpu/drm/amd/display/modules/power/power_helpers.h
b/drivers/gpu/drm/amd/display/modules/power/power_helpers.h
index 316452e9dbc9..bb16b37b83da 100644
--- a/drivers/gpu/drm/amd/display/modules/power/power_helpers.h
+++ b/drivers/gpu/drm/amd/display/modules/power/power_helpers.h
@@ -59,4 +59,7 @@ void mod_power_calc_psr_configs(struct psr_config
*psr_config,
const struct dc_stream_state *stream);
bool mod_power_only_edp(const struct dc_state *context,
const struct dc_stream_state *stream);
+bool psr_su_set_y_granularity(struct dc *dc, struct dc_link *link,
+ struct dc_stream_state *stream,
+ struct psr_config *config);
#endif /* MODULES_POWER_POWER_HELPERS_H_ */
Re: [bug][vaapi][h264] The commit 7cbe08a930a132d84b4cf79953b00b074ec7a2a7 on certain video files leads to problems with VAAPI hardware decoding.
Please try the latest AMDGPU driver: https://gitlab.freedesktop.org/agd5f/linux/-/commits/amd-staging-drm-next/ On 2022-12-07 15:54, Alex Deucher wrote: + Leo, Thong On Wed, Dec 7, 2022 at 3:43 PM Mikhail Gavrilov wrote: On Wed, Dec 7, 2022 at 7:58 PM Alex Deucher wrote: What GPU do you have and what entries do you have in sys/class/drm/card0/device/ip_discovery/die/0/UVD for the device? I bisected the issue on the Radeon 6800M. Parent commit for 7cbe08a930a132d84b4cf79953b00b074ec7a2a7 is 46dd2965bdd1c5a4f6499c73ff32e636fa8f9769. For both commits ip_discovery is absent. # ls /sys/class/drm/card0/device/ | grep ip # ls /sys/class/drm/card1/device/ | grep ip But from verbose info I see that player for 7cbe08a930a132d84b4cf79953b00b074ec7a2a7 use acceleration: $ vlc -v Downloads/test_sample_480_2.mp4 VLC media player 3.0.18 Vetinari (revision ) [561f72097520] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface. [7fa224001190] mp4 demux warning: elst box found [7fa224001190] mp4 demux warning: STTS table of 1 entries [7fa224001190] mp4 demux warning: CTTS table of 78 entries [7fa224001190] mp4 demux warning: elst box found [7fa224001190] mp4 demux warning: STTS table of 1 entries [7fa224001190] mp4 demux warning: elst old=0 new=1 [7fa224d19010] faad decoder warning: decoded zero sample [7fa224001190] mp4 demux warning: elst old=0 new=1 [7fa214007030] gl gl: Initialized libplacebo v4.208.0 (API v208) libva info: VA-API version 1.16.0 libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null) [7fa214007030] glconv_vaapi_x11 gl error: vaInitialize: unknown libva error libva info: VA-API version 1.16.0 libva info: Trying to open /usr/lib64/dri/radeonsi_drv_video.so libva info: Found init function __vaDriverInit_1_16 libva info: va_openDriver() returns 0 [7fa224c0b3a0] avcodec decoder: Using Mesa Gallium driver 23.0.0-devel for AMD Radeon RX 6800M (navi22, LLVM 15.0.4, DRM 3.42, 5.14.0-rc4-14-7cbe08a930a132d84b4cf79953b00b074ec7a2a7+) for hardware decoding [h264 @ 0x7fa224c3fa40] Using deprecated struct vaapi_context in decode. [561f72174de0] pulse audio output warning: starting late (-9724 us) And for 46dd2965bdd1c5a4f6499c73ff32e636fa8f9769 commit did not use acceleration: $ vlc -v Downloads/test_sample_480_2.mp4 VLC media player 3.0.18 Vetinari (revision ) [55f61ad35520] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface. [7fc7e8001190] mp4 demux warning: elst box found [7fc7e8001190] mp4 demux warning: STTS table of 1 entries [7fc7e8001190] mp4 demux warning: CTTS table of 78 entries [7fc7e8001190] mp4 demux warning: elst box found [7fc7e8001190] mp4 demux warning: STTS table of 1 entries [7fc7e8001190] mp4 demux warning: elst old=0 new=1 [7fc7e8d19010] faad decoder warning: decoded zero sample [7fc7e8001190] mp4 demux warning: elst old=0 new=1 [7fc7d8007030] gl gl: Initialized libplacebo v4.208.0 (API v208) libva info: VA-API version 1.16.0 libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null) [7fc7d8007030] glconv_vaapi_x11 gl error: vaInitialize: unknown libva error libva info: VA-API version 1.16.0 libva info: Trying to open /usr/lib64/dri/radeonsi_drv_video.so libva info: Found init function __vaDriverInit_1_16 libva info: va_openDriver() returns 0 [7fc7d40b3260] vaapi generic error: profile(7) is not supported [7fc7d8a089c0] gl gl: Initialized libplacebo v4.208.0 (API v208) Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory [7fc7d89e4f80] gl gl: Initialized libplacebo v4.208.0 (API v208) [55f61ae12de0] pulse audio output warning: starting late (-13537 us) So my bisect didn't make sense :( Anyway can you reproduce the issue with the attached sample file and vlc on fresh kernel (6.1-rc8)? Thanks! -- Best Regards, Mike Gavrilov.
Re: [PATCH v2] drm/amd/display: add FB_DAMAGE_CLIPS support
On 11/18/22 16:51, Hamza Mahfooz wrote:
Currently, userspace doesn't have a way to communicate selective updates
to displays. So, enable support for FB_DAMAGE_CLIPS for DCN ASICs newer
than DCN301, convert DRM damage clips to dc dirty rectangles and fill
them into dirty_rects in fill_dc_dirty_rects().
Signed-off-by: Hamza Mahfooz
Thanks for the patch, it LGTM.
Reviewed-by: Leo Li
It would be good to add an IGT case to cover combinations of MPO &
damage clip commits. Perhaps something that covers the usecase of moving
a MPO video, while desktop UI updates. We'd expect the SU region to
cover both the MPO plane + UI damage clips, or fallback to FFU.
Thanks,
Leo
---
v2: fallback to FFU if we run into too many dirty rectangles, consider
dirty rectangles in non MPO case and always add a dirty rectangle
for the new plane if there are bb changes in the MPO case.
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 130 +++---
.../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 4 +
2 files changed, 88 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 4eb8201a2608..7af94a2c6237 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4842,6 +4842,35 @@ static int fill_dc_plane_attributes(struct amdgpu_device
*adev,
return 0;
}
+static inline void fill_dc_dirty_rect(struct drm_plane *plane,
+ struct rect *dirty_rect, int32_t x,
+ int32_t y, int32_t width, int32_t height,
+ int *i, bool ffu)
+{
+ if (*i > DC_MAX_DIRTY_RECTS)
+ return;
+
+ if (*i == DC_MAX_DIRTY_RECTS)
+ goto out;
+
+ dirty_rect->x = x;
+ dirty_rect->y = y;
+ dirty_rect->width = width;
+ dirty_rect->height = height;
+
+ if (ffu)
+ drm_dbg(plane->dev,
+ "[PLANE:%d] PSR FFU dirty rect size (%d, %d)\n",
+ plane->base.id, width, height);
+ else
+ drm_dbg(plane->dev,
+ "[PLANE:%d] PSR SU dirty rect at (%d, %d) size (%d,
%d)",
+ plane->base.id, x, y, width, height);
+
+out:
+ (*i)++;
+}
+
/**
* fill_dc_dirty_rects() - Fill DC dirty regions for PSR selective updates
*
@@ -4862,10 +4891,6 @@ static int fill_dc_plane_attributes(struct amdgpu_device
*adev,
* addition, certain use cases - such as cursor and multi-plane overlay (MPO)
-
* implicitly provide damage clips without any client support via the plane
* bounds.
- *
- * Today, amdgpu_dm only supports the MPO and cursor usecase.
- *
- * TODO: Also enable for FB_DAMAGE_CLIPS
*/
static void fill_dc_dirty_rects(struct drm_plane *plane,
struct drm_plane_state *old_plane_state,
@@ -4876,12 +4901,11 @@ static void fill_dc_dirty_rects(struct drm_plane *plane,
struct dm_crtc_state *dm_crtc_state = to_dm_crtc_state(crtc_state);
struct rect *dirty_rects = flip_addrs->dirty_rects;
uint32_t num_clips;
+ struct drm_mode_rect *clips;
bool bb_changed;
bool fb_changed;
uint32_t i = 0;
- flip_addrs->dirty_rect_count = 0;
-
/*
* Cursor plane has it's own dirty rect update interface. See
* dcn10_dmub_update_cursor_data and dmub_cmd_update_cursor_info_data
@@ -4889,20 +4913,20 @@ static void fill_dc_dirty_rects(struct drm_plane *plane,
if (plane->type == DRM_PLANE_TYPE_CURSOR)
return;
- /*
-* Today, we only consider MPO use-case for PSR SU. If MPO not
-* requested, and there is a plane update, do FFU.
-*/
+ num_clips = drm_plane_get_damage_clips_count(new_plane_state);
+ clips = drm_plane_get_damage_clips(new_plane_state);
+
if (!dm_crtc_state->mpo_requested) {
- dirty_rects[0].x = 0;
- dirty_rects[0].y = 0;
- dirty_rects[0].width = dm_crtc_state->base.mode.crtc_hdisplay;
- dirty_rects[0].height = dm_crtc_state->base.mode.crtc_vdisplay;
- flip_addrs->dirty_rect_count = 1;
- DRM_DEBUG_DRIVER("[PLANE:%d] PSR FFU dirty rect size (%d,
%d)\n",
-new_plane_state->plane->base.id,
-dm_crtc_state->base.mode.crtc_hdisplay,
-dm_crtc_state->base.mode.crtc_vdisplay);
+ if (!num_clips || num_clips > DC_MAX_DIRTY_RECTS)
+ goto ffu;
+
+ for (; flip_addrs->dirty_rect_count < num_clips; clips++)
+ fill_dc_dirty_rect(new_plane_state->plane,
+
[PATCH] drm/amdgpu: enable Vangogh VCN indirect sram mode
So that uses PSP to initialize HW. Fixes: 0c2c02b6 (drm/amdgpu/vcn: add firmware support for dimgrey_cavefish) Signed-off-by: Leo Liu --- drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c index c448c1bdf84d..72fa14ff862f 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c @@ -156,6 +156,9 @@ int amdgpu_vcn_sw_init(struct amdgpu_device *adev) break; case IP_VERSION(3, 0, 2): fw_name = FIRMWARE_VANGOGH; + if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) && + (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG)) + adev->vcn.indirect_sram = true; break; case IP_VERSION(3, 0, 16): fw_name = FIRMWARE_DIMGREY_CAVEFISH; -- 2.25.1
Re: [PATCH] drm/amd/display: add FB_DAMAGE_CLIPS support
On 11/15/22 15:24, Hamza Mahfooz wrote:
Currently, userspace doesn't have a way to communicate selective updates
to displays. So, enable support for FB_DAMAGE_CLIPS for DCN ASICs newer
than DCN301, convert DRM damage clips to dc dirty rectangles and fill
them into dirty_rects in fill_dc_dirty_rects().
Signed-off-by: Hamza Mahfooz
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 91 +++
.../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 4 +
2 files changed, 58 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 185d09c760ba..18b710ba802d 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4842,6 +4842,31 @@ static int fill_dc_plane_attributes(struct amdgpu_device
*adev,
return 0;
}
+static inline void fill_dc_dirty_rect(struct drm_plane *plane,
+ struct rect *dirty_rect, int32_t x,
+ int32_t y, int32_t width, int32_t height,
+ int *i, bool ffu)
+{
+ WARN_ON(*i >= DC_MAX_DIRTY_RECTS);
Hi Hamza,
Since dc_flip_addrs->dirty_rects has a fixed length of
DC_MAX_DIRTY_RECTS per pipe (a restriction by DMUB FW), I think it makes
more sense to fallback to a full-frame-update (FFU) if num_clips >
DC_MAX_DIRTY_RECTS. An alternative would be to reject the atomic commit,
but that sounds heavy handed.
+
+ dirty_rect->x = x;
+ dirty_rect->y = y;
+ dirty_rect->width = width;
+ dirty_rect->height = height;
+
+ if (ffu)
+ drm_dbg(plane->dev,
+ "[PLANE:%d] PSR FFU dirty rect size (%d, %d)\n",
+ plane->base.id, width, height);
+ else
+ drm_dbg(plane->dev,
+ "[PLANE:%d] PSR SU dirty rect at (%d, %d) size (%d,
%d)",
+ plane->base.id, x, y, width, height);
+
+ (*i)++;
+}
+
+
/**
* fill_dc_dirty_rects() - Fill DC dirty regions for PSR selective updates
*
@@ -4862,10 +4887,6 @@ static int fill_dc_plane_attributes(struct amdgpu_device
*adev,
* addition, certain use cases - such as cursor and multi-plane overlay (MPO)
-
* implicitly provide damage clips without any client support via the plane
* bounds.
- *
- * Today, amdgpu_dm only supports the MPO and cursor usecase.
- *
- * TODO: Also enable for FB_DAMAGE_CLIPS
*/
static void fill_dc_dirty_rects(struct drm_plane *plane,
struct drm_plane_state *old_plane_state,
@@ -4876,12 +4897,11 @@ static void fill_dc_dirty_rects(struct drm_plane *plane,
struct dm_crtc_state *dm_crtc_state = to_dm_crtc_state(crtc_state);
struct rect *dirty_rects = flip_addrs->dirty_rects;
uint32_t num_clips;
+ struct drm_mode_rect *clips;
bool bb_changed;
bool fb_changed;
uint32_t i = 0;
- flip_addrs->dirty_rect_count = 0;
-
/*
* Cursor plane has it's own dirty rect update interface. See
* dcn10_dmub_update_cursor_data and dmub_cmd_update_cursor_info_data
@@ -4894,15 +4914,11 @@ static void fill_dc_dirty_rects(struct drm_plane *plane,
* requested, and there is a plane update, do FFU.
*/
if (!dm_crtc_state->mpo_requested) {
- dirty_rects[0].x = 0;
- dirty_rects[0].y = 0;
- dirty_rects[0].width = dm_crtc_state->base.mode.crtc_hdisplay;
- dirty_rects[0].height = dm_crtc_state->base.mode.crtc_vdisplay;
- flip_addrs->dirty_rect_count = 1;
- DRM_DEBUG_DRIVER("[PLANE:%d] PSR FFU dirty rect size (%d,
%d)\n",
-new_plane_state->plane->base.id,
-dm_crtc_state->base.mode.crtc_hdisplay,
-dm_crtc_state->base.mode.crtc_vdisplay);
+ fill_dc_dirty_rect(new_plane_state->plane, _rects[0], 0,
+ 0, dm_crtc_state->base.mode.crtc_hdisplay,
+ dm_crtc_state->base.mode.crtc_vdisplay, ,
+ true);
+ flip_addrs->dirty_rect_count = i;
return;
}
Previously, we always do FFU on plane updates if no MPO has been
requested. Now, since we want to look at user-provided DRM damage clips,
this bit needs a bit of a rework.
In short, if there are valid clips for this plane
(drm_plane_get_damage_clips_count() > 0), they should be added to
dc_dirty_rects. Otherwise, fallback to old FFU logic.
With MPO, the damage clips are more interesting, since the entire
plane's bounding box can be moved. I wonder if that is reflected in
DRM's damage clips. Do you know
Re: [PATCH v2] drm/amd/display: only fill dirty rectangles when PSR is enabled
On 11/9/22 13:20, Hamza Mahfooz wrote: Currently, we are calling fill_dc_dirty_rects() even if PSR isn't supported by the relevant link in amdgpu_dm_commit_planes(), this is undesirable especially because when drm.debug is enabled we are printing messages in fill_dc_dirty_rects() that are only useful for debugging PSR (and confusing otherwise). So, we can instead limit the filling of dirty rectangles to only when PSR is enabled. Signed-off-by: Hamza Mahfooz Reviewed-by: Leo Li Thanks --- v2: give a more concrete reason. --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 66eb16fbe09f..956a6e494709 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -7697,9 +7697,10 @@ static void amdgpu_dm_commit_planes(struct drm_atomic_state *state, bundle->surface_updates[planes_count].plane_info = >plane_infos[planes_count]; - fill_dc_dirty_rects(plane, old_plane_state, new_plane_state, - new_crtc_state, - >flip_addrs[planes_count]); + if (acrtc_state->stream->link->psr_settings.psr_feature_enabled) + fill_dc_dirty_rects(plane, old_plane_state, + new_plane_state, new_crtc_state, + >flip_addrs[planes_count]); /* * Only allow immediate flips for fast updates that don't
Re: [PATCH] drm/amd/display: explicitly disable psr_feature_enable appropriately
On 2022-10-07 00:28, Shirish S wrote:
[Why]
If psr_feature_enable is set to true by default, it continues to be enabled
for non capable links.
[How]
explicitly disable the feature on links that are not capable of the same.
Signed-off-by: Shirish S
Reviewed-by: Leo Li
Thanks!
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
index 8ca10ab3dfc1..26291db0a3cf 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
@@ -60,11 +60,15 @@ static bool link_supports_psrsu(struct dc_link *link)
*/
void amdgpu_dm_set_psr_caps(struct dc_link *link)
{
- if (!(link->connector_signal & SIGNAL_TYPE_EDP))
+ if (!(link->connector_signal & SIGNAL_TYPE_EDP)) {
+ link->psr_settings.psr_feature_enabled = false;
return;
+ }
- if (link->type == dc_connection_none)
+ if (link->type == dc_connection_none) {
+ link->psr_settings.psr_feature_enabled = false;
return;
+ }
if (link->dpcd_caps.psr_info.psr_version == 0) {
link->psr_settings.psr_version = DC_PSR_VERSION_UNSUPPORTED;
Re: [PATCH] drm/amd/display: disable psr whenever applicable
On 2022-10-06 03:46, S, Shirish wrote:
On 10/6/2022 4:33 AM, Leo Li wrote:
On 2022-10-03 11:26, S, Shirish wrote:
Ping!
Regards,
Shirish S
On 9/30/2022 7:17 PM, S, Shirish wrote:
On 9/30/2022 6:59 PM, Harry Wentland wrote:
+Leo
On 9/30/22 06:27, Shirish S wrote:
[Why]
psr feature continues to be enabled for non capable links.
Do you have more info on what issues you're seeing with this?
Code wise without this change we end up setting
"vblank_disable_immediate" parameter to false for the failing links
also.
Issue wise there is a remote chance of this leading to eDP/connected
monitor not lighting up.
I'm surprised psr_settings.psr_feature_enabled can be 'true' before
amdgpu_dm_set_psr_caps() runs. it should default to 'false', and it's
set early on during amdgpu_dm_initialize_drm_device() before any other
psr-related code runs.
In other words, I don't expect psr_settings.psr_feature_enabled to be
'true' on early return of dm_set_psr_caps().
What are the sequence of events that causes an issue for you?
psr_feature_enabled is set to true by default in
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c#L4264 for DCN 3.0 onwards
(Also, in ChromeOS wherein KMS driver is statically built in kernel, we
set PSR feature as enabled as command-line argument via
amdgpu_dc_feature_mask.)
Hence, the variable is set to true while entering amdgpu_dm_set_psr_caps().
Hmm, that is a local variable in the function, not the same as
link->psr_settings.psr_feature_enabled. Unless I'm missing something, it
looks like link->psr_settings.psr_feature_enabled is never set to true.
More below,
[How]
disable the feature on links that are not capable of the same.
Signed-off-by: Shirish S
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c | 10
--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
index 8ca10ab3dfc1..f73af028f312 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
@@ -60,11 +60,17 @@ static bool link_supports_psrsu(struct dc_link
*link)
*/
void amdgpu_dm_set_psr_caps(struct dc_link *link)
{
- if (!(link->connector_signal & SIGNAL_TYPE_EDP))
+ if (!(link->connector_signal & SIGNAL_TYPE_EDP)) {
+ DRM_ERROR("Disabling PSR as connector is not eDP\n")
I don't think we should log an error here.
My objective of logging an error was to inform user/developer that
this boot PSR enablement had issues.
It's not really an issue, PSR simply cannot be enabled on non-eDP or
disconnected links.
Agree, the idea here is to avoid decisions being taken presuming
psr_feature_enabled being set on such links, like disabling
vblank_disable_immediate
<https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c#L4330>etc.,
Regards,
Shirish S
However, it is concerning if we enter this function
with psr_feature_enabled == true.
Thanks,
Leo
Am fine with moving it to INFO or remove it, if you insist.
Thanks for your comments.
Regards,
Shirish S
+ link->psr_settings.psr_feature_enabled = false;
Never the less, explicitly setting to false rather than leaving it as
default sounds like a good idea to me.
But I don't see how this fixes an issue.
If this is a readability fix, I suggest changing commit title and
description to reflect that.
Thanks,
Leo
return;
+ }
- if (link->type == dc_connection_none)
+ if (link->type == dc_connection_none) {
+ DRM_ERROR("Disabling PSR as eDP connection type is
invalid\n")
Same here, this doesn't warrant an error log.
Harry
+ link->psr_settings.psr_feature_enabled = false;
return;
+ }
if (link->dpcd_caps.psr_info.psr_version == 0) {
link->psr_settings.psr_version =
DC_PSR_VERSION_UNSUPPORTED;
Re: [PATCH] drm/amd/display: disable psr whenever applicable
On 2022-10-03 11:26, S, Shirish wrote:
Ping!
Regards,
Shirish S
On 9/30/2022 7:17 PM, S, Shirish wrote:
On 9/30/2022 6:59 PM, Harry Wentland wrote:
+Leo
On 9/30/22 06:27, Shirish S wrote:
[Why]
psr feature continues to be enabled for non capable links.
Do you have more info on what issues you're seeing with this?
Code wise without this change we end up setting
"vblank_disable_immediate" parameter to false for the failing links also.
Issue wise there is a remote chance of this leading to eDP/connected
monitor not lighting up.
I'm surprised psr_settings.psr_feature_enabled can be 'true' before
amdgpu_dm_set_psr_caps() runs. it should default to 'false', and it's
set early on during amdgpu_dm_initialize_drm_device() before any other
psr-related code runs.
In other words, I don't expect psr_settings.psr_feature_enabled to be
'true' on early return of dm_set_psr_caps().
What are the sequence of events that causes an issue for you?
[How]
disable the feature on links that are not capable of the same.
Signed-off-by: Shirish S
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
index 8ca10ab3dfc1..f73af028f312 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
@@ -60,11 +60,17 @@ static bool link_supports_psrsu(struct dc_link *link)
*/
void amdgpu_dm_set_psr_caps(struct dc_link *link)
{
- if (!(link->connector_signal & SIGNAL_TYPE_EDP))
+ if (!(link->connector_signal & SIGNAL_TYPE_EDP)) {
+ DRM_ERROR("Disabling PSR as connector is not eDP\n")
I don't think we should log an error here.
My objective of logging an error was to inform user/developer that
this boot PSR enablement had issues.
It's not really an issue, PSR simply cannot be enabled on non-eDP or
disconnected links. However, it is concerning if we enter this function
with psr_feature_enabled == true.
Thanks,
Leo
Am fine with moving it to INFO or remove it, if you insist.
Thanks for your comments.
Regards,
Shirish S
+ link->psr_settings.psr_feature_enabled = false;
return;
+ }
- if (link->type == dc_connection_none)
+ if (link->type == dc_connection_none) {
+ DRM_ERROR("Disabling PSR as eDP connection type is invalid\n")
Same here, this doesn't warrant an error log.
Harry
+ link->psr_settings.psr_feature_enabled = false;
return;
+ }
if (link->dpcd_caps.psr_info.psr_version == 0) {
link->psr_settings.psr_version = DC_PSR_VERSION_UNSUPPORTED;
Re: [PATCH] drm/amdgpu: Fix mc_umc_status used uninitialized warning
On 2022-09-28 10:53, Hamza Mahfooz wrote:
On 2022-09-28 10:49, sunpeng...@amd.com wrote:
From: Leo Li
On ChromeOS clang build, the following warning is seen:
/mnt/host/source/src/third_party/kernel/v5.15/drivers/gpu/drm/amd/amdgpu/umc_v6_7.c:463:6:
error: variable 'mc_umc_status' is used uninitialized whenever 'if' condition
is false [-Werror,-Wsometimes-uninitialized]
if (mca_addr == UMC_INVALID_ADDR) {
^~~~
/mnt/host/source/src/third_party/kernel/v5.15/drivers/gpu/drm/amd/amdgpu/umc_v6_7.c:485:21:
note: uninitialized use occurs here
if ((REG_GET_FIELD(mc_umc_status,
MCA_UMC_UMC0_MCUMC_STATUST0, Val) == 1 &&
^
/mnt/host/source/src/third_party/kernel/v5.15/drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu.h:1208:5:
note: expanded from macro 'REG_GET_FIELD'
(((value) & REG_FIELD_MASK(reg, field)) >>
REG_FIELD_SHIFT(reg, field))
^
/mnt/host/source/src/third_party/kernel/v5.15/drivers/gpu/drm/amd/amdgpu/umc_v6_7.c:463:2:
note: remove the 'if' if its condition is always true
if (mca_addr == UMC_INVALID_ADDR) {
^~
/mnt/host/source/src/third_party/kernel/v5.15/drivers/gpu/drm/amd/amdgpu/umc_v6_7.c:460:24:
note: initialize the variable 'mc_umc_status' to silence this warning
uint64_t mc_umc_status, mc_umc_addrt0;
^
= 0
1 error generated.
make[5]: ***
[/mnt/host/source/src/third_party/kernel/v5.15/scripts/Makefile.build:289: drivers/gpu/drm/amd/amdgpu/umc_v6_7.o] Error 1
Fix by initializing mc_umc_status = 0.
Fixes: d8e19e32945e ("drm/amdgpu: support to convert dedicated umc mca
address")
Signed-off-by: Leo Li
Reviewed-by: Hamza Mahfooz
Thanks! Will merge shortly.
Leo
Re: [PATCH] drm/amd/display: Prevent OTG shutdown during PSR SU
On 2022-09-28 09:52, Harry Wentland wrote:
On 2022-09-27 19:13, sunpeng...@amd.com wrote:
From: Leo Li
[Why]
Enabling Z10 optimizations allows DMUB to disable the OTG during PSR
link-off. This theoretically saves power by putting more of the display
hardware to sleep. However, we observe that with PSR SU, it causes
visual artifacts, higher power usage, and potential system hang.
This is partly due to an odd behavior with the VStartup interrupt used
to signal DRM vblank events. If the OTG is toggled on/off during a PSR
link on/off cycle, the vstartup interrupt fires twice in quick
succession. This generates incorrectly timed vblank events.
Additionally, it can cause cursor updates to generate visual artifacts.
Note that this is not observed with PSR1 since PSR is fully disabled
when there are vblank event requestors. Cursor updates are also
artifact-free, likely because there are no selectively-updated (SU)
frames that can generate artifacts.
[How]
A potential solution is to disable z10 idle optimizations only when fast
updates (flips & cursor updates) are committed. A mechanism to do so
would require some thoughtful design. Let's just disable idle
optimizations for PSR2 for now.
Great writeup. Wish every bugfix came with details like this.
Fixes: 7cc191ee7621 ("drm/amd/display: Implement MPO PSR SU")
Signed-off-by: Leo Li
With Thorsten's comments addressed this is
Reviewed-by: Harry Wentland
Harry
Thanks all for the bug report, comments, and review. Will send out v2
and merge shortly.
Leo
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
index c8da18e45b0e..8ca10ab3dfc1 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
@@ -170,7 +170,13 @@ bool amdgpu_dm_psr_enable(struct dc_stream_state *stream)
, 1,
);
- power_opt |= psr_power_opt_z10_static_screen;
+ /*
+* Only enable static-screen optimizations for PSR1. For PSR SU, this
+* causes vstartup interrupt issues, used by amdgpu_dm to send vblank
+* events.
+*/
+ if (link->psr_settings.psr_version < DC_PSR_VERSION_SU_1)
+ power_opt |= psr_power_opt_z10_static_screen;
return dc_link_set_psr_allow_active(link, _enable, false, false, _opt);
}
Re: [REGRESSION] Graphical issues on Lenovo Yoga 7 14ARB7 laptop since v6.0-rc1 (bisected)
Hi August, I've sent a fix here: https://patchwork.freedesktop.org/patch/504993/ It's not the most ideal fix, but it should address the regression. Let me know it works for you. Thanks! Leo On 2022-09-27 10:22, August Wikerfors wrote: Hi Leo, On 2022-09-27 00:29, Leo Li wrote: Hi August, thanks for the log. It seems the eDP panel does not fully satisfy the amdgpu requirements for enabling PSR SU, but we're enabling it anyways. I suspect it may be due to the "DP_FORCE_PSRSU_CAPABILITY" bit being set in it's DPCD registers, I'm checking with some devs to see if that is expected. In the meantime, can you give these two hacks a spin? Let me know if this helps with the glitches and system hangs: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2F-%2Fsnippets%2F7076data=05%7C01%7Csunpeng.li%40amd.com%7Ca5864225840b4bbbd04c08daa093bb26%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637998853607058272%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=cNAK%2FMhWCGwXySpITTTvKtzXQ7WCEQL4DYSrPKzWSkY%3Dreserved=0 Yes, the issues do not happen with those patches applied. Also the dmesg, in particular this line: [drm] PSR support 1, DC PSR ver 1, sink PSR ver 3 DPCD caps 0x70su_y_granularity 4 force_psrsu_cap **X** Here is that line: [ 12.085196] [drm] PSR support 1, DC PSR ver 1, sink PSR ver 3 DPCD caps 0x7b su_y_granularity 4 force_psrsu_cap 1 Regards, August Wikerfors
Re: [REGRESSION] Graphical issues on Lenovo Yoga 7 14ARB7 laptop since v6.0-rc1 (bisected)
Hi August, thanks for the log. It seems the eDP panel does not fully satisfy the amdgpu requirements for enabling PSR SU, but we're enabling it anyways. I suspect it may be due to the "DP_FORCE_PSRSU_CAPABILITY" bit being set in it's DPCD registers, I'm checking with some devs to see if that is expected. In the meantime, can you give these two hacks a spin? Let me know if this helps with the glitches and system hangs: https://gitlab.freedesktop.org/-/snippets/7076 Also the dmesg, in particular this line: [drm] PSR support 1, DC PSR ver 1, sink PSR ver 3 DPCD caps 0x70su_y_granularity 4 force_psrsu_cap **X** Thanks, Leo On 2022-09-23 16:26, August Wikerfors wrote: Hi Leo, On 2022-09-23 20:41, Leo Li wrote: Hi August, Can you provide a dmesg log with drm.debug=0x16 enabled in kernel cmdline? Log is available here: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffiles.augustwikerfors.se%2Fdmesg.2022-09-23.txtdata=05%7C01%7Csunpeng.li%40amd.com%7C261d31a0ac6844e40b2208da9da1ee82%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637995616061782958%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=6LAMah8N%2FdEG6gl6u9HGcajwozrS7fwp%2FJDLZMKpcGU%3Dreserved=0 This is what I did during that log: 1. Boot the system 2. Type into the password field in SDDM (this is when the problem occurs) 3. Switch to a TTY to save the log (the problem doesn't happen there) Regards, August Wikerfors
Re: [REGRESSION] Graphical issues on Lenovo Yoga 7 14ARB7 laptop since v6.0-rc1 (bisected)
Hi August, Can you provide a dmesg log with drm.debug=0x16 enabled in kernel cmdline? I wasn't aware that there are currently psr su edp panel + rembrandt apu systems out in the wild. In any case, psrsu + rmb should be working, and there might something specific to your configuration that's hitting a corner case. The dmesg will shed some light. Thanks Leo On 2022-09-22 14:13, August Wikerfors wrote: Hi Alex, On 2022-09-22 15:59, Alex Deucher wrote: On Thu, Sep 22, 2022 at 8:54 AM Thorsten Leemhuis wrote: Hi, this is your Linux kernel regression tracker. Top-posting for once, to make this easily accessible to everyone. @amdgpu developers, what up here? August afaics didn't even get a single reply for his report that even identifies the change that's causing the problem. We're already late in the development cycle, so it would be good if someone could take a closer look into this before it's too late for 6.0. Been a busy week. Haven't had a chance to look into this yet. Does the issue still happen with this patch: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Fcommit%2F%3Fid%3D66f99628eb24409cb8feb5061f78283c8b65f820data=05%7C01%7Csunpeng.li%40amd.com%7Cb3457b7e83df4b2c7d4308da9cc63280%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63799467232021%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=a0EMjX6L13FaQU0mqxp5vO9vRe0BEDBDJ5emOdCj8gY%3Dreserved=0 Yes, the issue still happens with that patch, and also with the current git master (dc164f4fb00a0abebdfff132f8bc7291a28f5401). Regards, August Wikerfors
Re: [PATCH] drm/amdgpu/vcn: update vcn4 fw shared data structure
Reviewed-by: Leo Liu
On 2022-09-22 15:30, Ruijing Dong wrote:
update VF_RB_SETUP_FLAG, add SMU_DPM_INTERFACE_FLAG,
and corresponding change in VCN4.
Signed-off-by: Ruijing Dong
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h | 8 +++-
drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c | 4
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
index 80b7a6cfd026..253ea6b159df 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
@@ -161,7 +161,8 @@
#define AMDGPU_VCN_SW_RING_FLAG (1 << 9)
#define AMDGPU_VCN_FW_LOGGING_FLAG(1 << 10)
#define AMDGPU_VCN_SMU_VERSION_INFO_FLAG (1 << 11)
-#define AMDGPU_VCN_VF_RB_SETUP_FLAG (1 << 12)
+#define AMDGPU_VCN_SMU_DPM_INTERFACE_FLAG (1 << 11)
+#define AMDGPU_VCN_VF_RB_SETUP_FLAG (1 << 14)
#define AMDGPU_VCN_IB_FLAG_DECODE_BUFFER 0x0001
#define AMDGPU_VCN_CMD_FLAG_MSG_BUFFER0x0001
@@ -171,6 +172,9 @@
#define VCN_CODEC_DISABLE_MASK_HEVC (1 << 2)
#define VCN_CODEC_DISABLE_MASK_H264 (1 << 3)
+#define AMDGPU_VCN_SMU_DPM_INTERFACE_DGPU (0)
+#define AMDGPU_VCN_SMU_DPM_INTERFACE_APU (1)
+
enum fw_queue_mode {
FW_QUEUE_RING_RESET = 1,
FW_QUEUE_DPG_HOLD_OFF = 2,
@@ -335,7 +339,9 @@ struct amdgpu_vcn4_fw_shared {
struct amdgpu_fw_shared_unified_queue_struct sq;
uint8_t pad1[8];
struct amdgpu_fw_shared_fw_logging fw_log;
+ uint8_t pad2[20];
struct amdgpu_fw_shared_rb_setup rb_setup;
+ struct amdgpu_fw_shared_smu_interface_info smu_dpm_interface;
};
struct amdgpu_vcn_fwlog {
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
index b6f73b87c47e..897a5ce9c9da 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
@@ -150,6 +150,10 @@ static int vcn_v4_0_sw_init(void *handle)
fw_shared->present_flag_0 =
cpu_to_le32(AMDGPU_FW_SHARED_FLAG_0_UNIFIED_QUEUE);
fw_shared->sq.is_enabled = 1;
+ fw_shared->present_flag_0 |= cpu_to_le32(AMDGPU_VCN_SMU_DPM_INTERFACE_FLAG);
+ fw_shared->smu_dpm_interface.smu_interface_type = (adev->flags
& AMD_IS_APU) ?
+ AMDGPU_VCN_SMU_DPM_INTERFACE_APU :
AMDGPU_VCN_SMU_DPM_INTERFACE_DGPU;
+
if (amdgpu_sriov_vf(adev))
fw_shared->present_flag_0 |=
cpu_to_le32(AMDGPU_VCN_VF_RB_SETUP_FLAG);
Re: [PATCH v4] drm/amdgpu: add HW_IP_VCN_UNIFIED type
On 2022-07-18 02:57, Christian König wrote:
Am 15.07.22 um 22:04 schrieb Ruijing Dong:
From VCN4, AMDGPU_HW_IP_VCN_UNIFIED is used to support
both encoding and decoding jobs, it re-uses the same
queue number of AMDGPU_HW_IP_VCN_ENC.
link:
https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/245/commits
Signed-off-by: Ruijing Dong
---
include/uapi/drm/amdgpu_drm.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/uapi/drm/amdgpu_drm.h
b/include/uapi/drm/amdgpu_drm.h
index 18d3246d636e..e268cd3cdb12 100644
--- a/include/uapi/drm/amdgpu_drm.h
+++ b/include/uapi/drm/amdgpu_drm.h
@@ -560,6 +560,12 @@ struct drm_amdgpu_gem_va {
#define AMDGPU_HW_IP_UVD_ENC 5
#define AMDGPU_HW_IP_VCN_DEC 6
#define AMDGPU_HW_IP_VCN_ENC 7
+/**
Please don't use "/**" here, that is badly formated for a kerneldoc
comment.
+ * From VCN4, AMDGPU_HW_IP_VCN_UNIFIED is used to support
+ * both encoding and decoding jobs, it re-uses the same
+ * queue number of AMDGPU_HW_IP_VCN_ENC.
+ */
+#define AMDGPU_HW_IP_VCN_UNIFIED AMDGPU_HW_IP_VCN_ENC
I'm still in doubt that adding another define with the same value as
AMDGPU_HW_IP_VCN_ENC is a good idea.
Hi Christian,
From VCN4, there is no VCN dec and enc ring type any more, the
decode/encode will go through the unified queue, so using
AMDGPU_HW_IP_VCN_ENC is no longer accurate . Keeping
AMDGPU_HW_IP_VCN_ENC type is for legacy HW, and the new
AMDGPU_HW_IP_VCN_UNIFIED just happen to use the same HW ring as legacy
encode ring, so reuse the value, and that is the whole idea.
Thanks,
Leo
Instead we should just add the comment to AMDGPU_HW_IP_VCN_ENC.
Regards,
Christian.
#define AMDGPU_HW_IP_VCN_JPEG 8
#define AMDGPU_HW_IP_NUM 9
RE: [PATCH v4] drm/amdgpu: add HW_IP_VCN_UNIFIED type
[AMD Official Use Only - General]
Reviewed-by: Leo Liu
-Original Message-
From: Dong, Ruijing
Sent: July 15, 2022 4:04 PM
To: Koenig, Christian ; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Liu, Leo ;
Dong, Ruijing
Subject: [PATCH v4] drm/amdgpu: add HW_IP_VCN_UNIFIED type
>From VCN4, AMDGPU_HW_IP_VCN_UNIFIED is used to support both encoding and
>decoding jobs, it re-uses the same queue number of AMDGPU_HW_IP_VCN_ENC.
link: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/245/commits
Signed-off-by: Ruijing Dong
---
include/uapi/drm/amdgpu_drm.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h
index 18d3246d636e..e268cd3cdb12 100644
--- a/include/uapi/drm/amdgpu_drm.h
+++ b/include/uapi/drm/amdgpu_drm.h
@@ -560,6 +560,12 @@ struct drm_amdgpu_gem_va {
#define AMDGPU_HW_IP_UVD_ENC 5
#define AMDGPU_HW_IP_VCN_DEC 6
#define AMDGPU_HW_IP_VCN_ENC 7
+/**
+ * From VCN4, AMDGPU_HW_IP_VCN_UNIFIED is used to support
+ * both encoding and decoding jobs, it re-uses the same
+ * queue number of AMDGPU_HW_IP_VCN_ENC.
+ */
+#define AMDGPU_HW_IP_VCN_UNIFIED AMDGPU_HW_IP_VCN_ENC
#define AMDGPU_HW_IP_VCN_JPEG 8
#define AMDGPU_HW_IP_NUM 9
--
2.25.1
RE: [PATCH v3] drm/amdgpu: add comments to HW_IP_VCN_ENC
[AMD Official Use Only - General]
Reviewed-by: Leo Liu
-Original Message-
From: Dong, Ruijing
Sent: July 15, 2022 12:09 PM
To: Koenig, Christian ; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Liu, Leo ;
Dong, Ruijing
Subject: [PATCH v3] drm/amdgpu: add comments to HW_IP_VCN_ENC
>From VCN4, HW_IP_VCN_ENC will be used as unified queue, and support both
>encoding and decoding jobs, HW_IP_VCN_DEC is retired from VCN4.
link: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/245/commits
Signed-off-by: Ruijing Dong
---
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 18d3246d636e..29e4a1ece2ce 100644
--- a/include/uapi/drm/amdgpu_drm.h
+++ b/include/uapi/drm/amdgpu_drm.h
@@ -559,7 +559,14 @@ struct drm_amdgpu_gem_va {
#define AMDGPU_HW_IP_VCE 4
#define AMDGPU_HW_IP_UVD_ENC 5
#define AMDGPU_HW_IP_VCN_DEC 6
+
+/**
+ * From VCN4, AMDGPU_HW_IP_VCN_ENC will be used as unified queue
+ * and support both encoding and decoding jobs, AMDGPU_HW_IP_VCN_DEC
+ * is retired from VCN4.
+ */
#define AMDGPU_HW_IP_VCN_ENC 7
+
#define AMDGPU_HW_IP_VCN_JPEG 8
#define AMDGPU_HW_IP_NUM 9
--
2.25.1
Re: [PATCH v2] drm/amdgpu: Check BO's requested pinning domains against its preferred_domains
On 2022-07-12 13:00, Alex Deucher wrote:
On Tue, Jul 12, 2022 at 12:28 PM wrote:
From: Leo Li
When pinning a buffer, we should check to see if there are any
additional restrictions imposed by bo->preferred_domains. This will
prevent the BO from being moved to an invalid domain when pinning.
For example, this can happen if the user requests to create a BO in GTT
domain for display scanout. amdgpu_dm will allow pinning to either VRAM
or GTT domains, since DCN can scanout from either or. However, in
amdgpu_bo_pin_restricted(), pinning to VRAM is preferred if there is
adequate carveout. This can lead to pinning to VRAM despite the user
requesting GTT placement for the BO.
v2: Allow the kernel to override the domain, which can happen when
exporting a BO to a V4L camera (for example).
Signed-off-by: Leo Li
Reviewed-by: Alex Deucher
Pushed, thanks!
- Leo
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 8a7b0f6162da..bbd3b8b14cfb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -883,6 +883,10 @@ int amdgpu_bo_pin_restricted(struct amdgpu_bo *bo, u32
domain,
if (WARN_ON_ONCE(min_offset > max_offset))
return -EINVAL;
+ /* Check domain to be pinned to against preferred domains */
+ if (bo->preferred_domains & domain)
+ domain = bo->preferred_domains & domain;
+
/* A shared bo cannot be migrated to VRAM */
if (bo->tbo.base.import_attach) {
if (domain & AMDGPU_GEM_DOMAIN_GTT)
--
2.37.0
Re: [PATCH] drm/amd/display: Re-org and cleanup the redundant code
On 2022-06-26 06:15, Chandan Vurdigere Nataraj wrote:
[Why]
Redundant if-else cases for repeater and non-repeater checks
[How]
Without changing the core logic, rearranged the code by removing
redundant checks
Signed-off-by: Chandan Vurdigere Nataraj
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
index 4027f439a5a4..e3254ac05191 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
@@ -907,25 +907,17 @@ enum dc_status dp_get_lane_status_and_lane_adjust(
ln_align->raw = dpcd_buf[2];
if (is_repeater(link, offset)) {
+
With this extra newline dropped,
Reviewed-by: Leo Li
Thanks!
DC_LOG_HW_LINK_TRAINING("%s:\n LTTPR Repeater ID: %d\n"
" 0x%X Lane01Status = %x\n 0x%X Lane23Status = %x\n
",
__func__,
offset,
lane01_status_address, dpcd_buf[0],
lane01_status_address + 1, dpcd_buf[1]);
- } else {
- DC_LOG_HW_LINK_TRAINING("%s:\n 0x%X Lane01Status = %x\n 0x%X
Lane23Status = %x\n ",
- __func__,
- lane01_status_address, dpcd_buf[0],
- lane01_status_address + 1, dpcd_buf[1]);
- }
- lane01_adjust_address = DP_ADJUST_REQUEST_LANE0_1;
- if (is_repeater(link, offset))
lane01_adjust_address = DP_ADJUST_REQUEST_LANE0_1_PHY_REPEATER1
+
((DP_REPEATER_CONFIGURATION_AND_STATUS_SIZE) *
(offset - 1));
- if (is_repeater(link, offset)) {
DC_LOG_HW_LINK_TRAINING("%s:\n LTTPR Repeater ID: %d\n"
" 0x%X Lane01AdjustRequest = %x\n 0x%X
Lane23AdjustRequest = %x\n",
__func__,
@@ -935,6 +927,14 @@ enum dc_status dp_get_lane_status_and_lane_adjust(
lane01_adjust_address + 1,
dpcd_buf[lane_adjust_offset + 1]);
} else {
+
+ DC_LOG_HW_LINK_TRAINING("%s:\n 0x%X Lane01Status = %x\n 0x%X
Lane23Status = %x\n ",
+ __func__,
+ lane01_status_address, dpcd_buf[0],
+ lane01_status_address + 1, dpcd_buf[1]);
+
+ lane01_adjust_address = DP_ADJUST_REQUEST_LANE0_1;
+
DC_LOG_HW_LINK_TRAINING("%s:\n 0x%X Lane01AdjustRequest = %x\n 0x%X
Lane23AdjustRequest = %x\n",
__func__,
lane01_adjust_address,
Re: [PATCH] drm/amd/display : Log DP link training failure reason
On 2022-06-23 12:48, Alex Deucher wrote:
> On Thu, Jun 23, 2022 at 3:33 AM Chandan Vurdigere Nataraj
> wrote:
>>
>> [Why]
>> Existing logs doesn't print DP LT failure reason
>>
>> [How]
>> Update the existing log with DP LT failure reason
>>
>> Signed-off-by: Chandan Vurdigere Nataraj
>
> Acked-by: Alex Deucher
Reviewed-by: Leo Li
>
>>
>> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
>> b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
>> index 4027f439a5a4..c8355acd3672 100644
>> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
>> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
>> @@ -2786,9 +2786,9 @@ bool perform_link_training_with_retries(
>> break;
>> }
>>
>> - DC_LOG_WARNING("%s: Link(%d) training attempt %u of %d
>> failed @ rate(%d) x lane(%d)\n",
>> + DC_LOG_WARNING("%s: Link(%d) training attempt %u of %d
>> failed @ rate(%d) x lane(%d) : fail reason:(%d)\n",
>> __func__, link->link_index, (unsigned int)j + 1,
>> attempts, cur_link_settings.link_rate,
>> - cur_link_settings.lane_count);
>> + cur_link_settings.lane_count, status);
>>
>> dp_disable_link_phy(link, _ctx->link_res, signal);
>>
>> --
>> 2.25.1
>>
Re: [PATCH] drm/amd/display: Fix indentation in dcn32_get_vco_frequency_from_reg()
On 2022-06-23 11:30, Nathan Chancellor wrote:
> Clang warns:
>
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn32/dcn32_clk_mgr.c:549:4:
> warning: misleading indentation; statement is not part of the previous 'else'
> [-Wmisleading-indentation]
> pll_req = dc_fixpt_from_int(pll_req_reg &
> clk_mgr->clk_mgr_mask->FbMult_int);
> ^
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn32/dcn32_clk_mgr.c:542:3:
> note: previous statement is here
> else
> ^
> 1 warning generated.
>
> Indent this statement to the left, as it was clearly intended to be
> called unconditionally, which will fix the warning.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/1655
> Fixes: 3e838f7ccf64 ("drm/amd/display: Get VCO frequency from registers")
> Signed-off-by: Nathan Chancellor
Just hit this myself, thanks for the fix!
Reviewed-by: Leo Li
> ---
> drivers/gpu/drm/amd/display/dc/clk_mgr/dcn32/dcn32_clk_mgr.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn32/dcn32_clk_mgr.c
> b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn32/dcn32_clk_mgr.c
> index 113f93b3d3b2..4e8059f20007 100644
> --- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn32/dcn32_clk_mgr.c
> +++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn32/dcn32_clk_mgr.c
> @@ -546,7 +546,7 @@ static uint32_t dcn32_get_vco_frequency_from_reg(struct
> clk_mgr_internal *clk_mg
>* this works because the int part is on the right edge of the
> register
>* and the frac part is on the left edge
>*/
> - pll_req = dc_fixpt_from_int(pll_req_reg &
> clk_mgr->clk_mgr_mask->FbMult_int);
> + pll_req = dc_fixpt_from_int(pll_req_reg &
> clk_mgr->clk_mgr_mask->FbMult_int);
> pll_req.value |= pll_req_reg &
> clk_mgr->clk_mgr_mask->FbMult_frac;
>
> /* multiply by REFCLK period */
>
> base-commit: fdf249c70a36e2daa7ddf1252cf3b71faed87abc
Re: [PATCH 2/2] drm/amdgpu/vcn: support unified queue only in vcn4
The series are:
Acked-by: Leo Liu
On 2022-06-07 14:36, Ruijing Dong wrote:
- remove multiple queue support.
- add unified queue related functions.
Signed-off-by: Ruijing Dong
---
drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c | 563 +++---
1 file changed, 140 insertions(+), 423 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
index 9119e966..d6f134ef9633 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
@@ -29,7 +29,6 @@
#include "soc15d.h"
#include "soc15_hw_ip.h"
#include "vcn_v2_0.h"
-#include "vcn_sw_ring.h"
#include "vcn/vcn_4_0_0_offset.h"
#include "vcn/vcn_4_0_0_sh_mask.h"
@@ -45,15 +44,12 @@
#define VCN_VID_SOC_ADDRESS_2_0
0x1fb00
#define VCN1_VID_SOC_ADDRESS_3_0
0x48300
-bool unifiedQ_enabled = false;
-
static int amdgpu_ih_clientid_vcns[] = {
SOC15_IH_CLIENTID_VCN,
SOC15_IH_CLIENTID_VCN1
};
-static void vcn_v4_0_set_dec_ring_funcs(struct amdgpu_device *adev);
-static void vcn_v4_0_set_enc_ring_funcs(struct amdgpu_device *adev);
+static void vcn_v4_0_set_unified_ring_funcs(struct amdgpu_device *adev);
static void vcn_v4_0_set_irq_funcs(struct amdgpu_device *adev);
static int vcn_v4_0_set_powergating_state(void *handle,
enum amd_powergating_state state);
@@ -71,36 +67,15 @@ static int vcn_v4_0_early_init(void *handle)
{
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
- if (unifiedQ_enabled) {
- adev->vcn.num_vcn_inst = 1;
- adev->vcn.num_enc_rings = 1;
- } else {
- adev->vcn.num_enc_rings = 2;
- }
-
- if (!unifiedQ_enabled)
- vcn_v4_0_set_dec_ring_funcs(adev);
+ /* re-use enc ring as unified ring */
+ adev->vcn.num_enc_rings = 1;
- vcn_v4_0_set_enc_ring_funcs(adev);
+ vcn_v4_0_set_unified_ring_funcs(adev);
vcn_v4_0_set_irq_funcs(adev);
return 0;
}
-static void amdgpu_vcn_setup_unified_queue_ucode(struct amdgpu_device *adev)
-{
- if (adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) {
- const struct common_firmware_header *hdr;
-
- hdr = (const struct common_firmware_header *)adev->vcn.fw->data;
- adev->firmware.ucode[AMDGPU_UCODE_ID_VCN].ucode_id =
AMDGPU_UCODE_ID_VCN;
- adev->firmware.ucode[AMDGPU_UCODE_ID_VCN].fw = adev->vcn.fw;
- adev->firmware.fw_size +=
- ALIGN(le32_to_cpu(hdr->ucode_size_bytes), PAGE_SIZE);
- DRM_INFO("PSP loading VCN firmware\n");
- }
-}
-
/**
* vcn_v4_0_sw_init - sw init for VCN block
*
@@ -111,17 +86,14 @@ static void amdgpu_vcn_setup_unified_queue_ucode(struct
amdgpu_device *adev)
static int vcn_v4_0_sw_init(void *handle)
{
struct amdgpu_ring *ring;
- int i, j, r;
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
+ int i, r;
r = amdgpu_vcn_sw_init(adev);
if (r)
return r;
- if (unifiedQ_enabled)
- amdgpu_vcn_setup_unified_queue_ucode(adev);
- else
- amdgpu_vcn_setup_ucode(adev);
+ amdgpu_vcn_setup_ucode(adev);
r = amdgpu_vcn_resume(adev);
if (r)
@@ -129,81 +101,40 @@ static int vcn_v4_0_sw_init(void *handle)
for (i = 0; i < adev->vcn.num_vcn_inst; i++) {
volatile struct amdgpu_vcn4_fw_shared *fw_shared;
+
if (adev->vcn.harvest_config & (1 << i))
continue;
- /* VCN DEC TRAP */
+
+ atomic_set(>vcn.inst[i].sched_score, 0);
+
+ /* VCN UNIFIED TRAP */
r = amdgpu_irq_add_id(adev, amdgpu_ih_clientid_vcns[i],
- VCN_4_0__SRCID__UVD_TRAP,
>vcn.inst[i].irq);
+ VCN_4_0__SRCID__UVD_ENC_GENERAL_PURPOSE,
>vcn.inst[i].irq);
if (r)
return r;
- atomic_set(>vcn.inst[i].sched_score, 0);
- if (!unifiedQ_enabled) {
- ring = >vcn.inst[i].ring_dec;
- ring->use_doorbell = true;
-
- /* VCN4 doorbell layout
-* 1: VCN_JPEG_DB_CTRL UVD_JRBC_RB_WPTR; (jpeg)
-* 2: VCN_RB1_DB_CTRL UVD_RB_WPTR; (decode/encode for
unified queue)
-* 3: VCN_RB2_DB_CTRL UVD_RB_WPTR2; (encode only for
swqueue)
-* 4: VCN_RB3_DB_CTRL UVD_RB_WPTR3; (Reserved)
-* 5: VCN_RB4_DB_CTRL UVD_RB_WPTR4; (decode only for
swqueue)
-*/
-
-
Re: [PATCH] drm/amd/display: Use pre-allocated temp struct for bounding box update
On 2022-06-08 13:25, Pillai, Aurabindo wrote:
> [AMD Official Use Only - General]
>
>
> Isnt it cleaner to revert the original patch which removed the temporary
> variable and then instead allocate the clock_limits array on heap, and later
> freed at the end of the function?
>
> --
I don't quite recall the details, but in FPU context, we should not malloc
since it can fault/sleep. More info here:
https://yarchive.net/comp/linux/kernel_fp.html
- Leo
>
> Regards,
> Jay
> ------
> *From:* Li, Sun peng (Leo)
> *Sent:* Wednesday, June 8, 2022 12:48 PM
> *To:* amd-gfx@lists.freedesktop.org
> *Cc:* Wentland, Harry ; Pillai, Aurabindo
> ; Siqueira, Rodrigo ; Li,
> Sun peng (Leo)
> *Subject:* [PATCH] drm/amd/display: Use pre-allocated temp struct for
> bounding box update
>
> From: Leo Li
>
> [Why]
>
> There is a theoretical problem in prior patches for reducing the stack
> size of *update_bw_bounding_box() functions.
>
> By modifying the soc.clock_limits[n] struct directly, this can cause
> unintended behavior as the for loop attempts to swap rows in
> clock_limits[n]. A temporary struct is still required to make sure we
> stay functinoally equivalent.
>
> [How]
>
> Add a temporary clock_limits table to the SOC struct, and use it when
> swapping rows.
>
> Signed-off-by: Leo Li
> ---
> .../drm/amd/display/dc/dml/dcn20/dcn20_fpu.c | 33 +-
> .../amd/display/dc/dml/dcn301/dcn301_fpu.c | 36 ++-
> .../drm/amd/display/dc/dml/dcn31/dcn31_fpu.c | 64 +++
> .../amd/display/dc/dml/display_mode_structs.h | 5 ++
> 4 files changed, 82 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c
> b/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c
> index c2fec0d85da4..e247b2270b1d 100644
> --- a/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c
> +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c
> @@ -2015,9 +2015,8 @@ void dcn21_update_bw_bounding_box(struct dc *dc, struct
> clk_bw_params *bw_params
>
> ASSERT(clk_table->num_entries);
> /* Copy dcn2_1_soc.clock_limits to clock_limits to avoid copying
> over null states later */
> - for (i = 0; i < dcn2_1_soc.num_states + 1; i++) {
> - dcn2_1_soc.clock_limits[i] = dcn2_1_soc.clock_limits[i];
> - }
> + memcpy(_1_soc._clock_tmp, _1_soc.clock_limits,
> + sizeof(dcn2_1_soc.clock_limits));
>
> for (i = 0; i < clk_table->num_entries; i++) {
> /* loop backwards*/
> @@ -2032,22 +2031,26 @@ void dcn21_update_bw_bounding_box(struct dc *dc,
> struct clk_bw_params *bw_params
> if (i == 1)
> k++;
>
> - dcn2_1_soc.clock_limits[k].state = k;
> - dcn2_1_soc.clock_limits[k].dcfclk_mhz =
> clk_table->entries[i].dcfclk_mhz;
> - dcn2_1_soc.clock_limits[k].fabricclk_mhz =
> clk_table->entries[i].fclk_mhz;
> - dcn2_1_soc.clock_limits[k].socclk_mhz =
> clk_table->entries[i].socclk_mhz;
> - dcn2_1_soc.clock_limits[k].dram_speed_mts =
> clk_table->entries[i].memclk_mhz * 2;
> + dcn2_1_soc._clock_tmp[k].state = k;
> + dcn2_1_soc._clock_tmp[k].dcfclk_mhz =
> clk_table->entries[i].dcfclk_mhz;
> + dcn2_1_soc._clock_tmp[k].fabricclk_mhz =
> clk_table->entries[i].fclk_mhz;
> + dcn2_1_soc._clock_tmp[k].socclk_mhz =
> clk_table->entries[i].socclk_mhz;
> + dcn2_1_soc._clock_tmp[k].dram_speed_mts =
> clk_table->entries[i].memclk_mhz * 2;
>
> - dcn2_1_soc.clock_limits[k].dispclk_mhz =
Re: [PATCH] drm/amdgpu/display: Remove unnecessary typecasts and fix build issues
On 2022-06-07 13:58, Aurabindo Pillai wrote:
>
>
> On 2022-06-07 11:34, Leo wrote:
>>
>>
>> On 2022-06-07 05:40, Chandan Vurdigere Nataraj wrote:
>>> [Why]
>>> Getting below errors:
>>> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_32.c:1414:5:
>>> error: implicit conversion from enumeration type 'enum
>>> scan_direction_class' to different enumeration type 'enum
>>> dm_rotation_angle' [-Werror,-Wenum-conversion]
>>> mode_lib->vba.SourceScan[k],
>>> ^~~
>>> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_32.c:1744:22:
>>> error: implicit conversion from enumeration type 'enum
>>> scan_direction_class' to different enumeration type 'enum
>>> dm_rotation_angle' [-Werror,-Wenum-conversion]
>>> && (!(!IsVertical(mode_lib->vba.SourceScan[k])) ||
>>> mode_lib->vba.DCCEnable[k] == true)) {
>>> ~~ ^~~
>>> 2 errors generated.
>>>
>>> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_util_32.c:5484:18:
>>> error: implicit conversion from enumeration type 'RequestType' to
>>> different enumeration type 'enum RequestType' [-Werror,-Wenum-conversion]
>>> RequestLuma = REQ_256Bytes;
>>> ~ ^~~~
>>> 18 errors of similar kind
>>>
>>> [How]
>>> 1. Add typecast at relevant places
>>> 2. Move the enum RequestType definition ahead of declarations
>>>
>>> Signed-off-by: Chandan Vurdigere Nataraj
>>>
>>> diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_32.c
>>> b/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_32.c
>>> index b77a1ae792d1..5828e60f291d 100644
>>> --- a/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_32.c
>>> +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_32.c
>>> @@ -1411,7 +1411,7 @@ static void
>>> DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerforman
>>> v->BytePerPixelC[k],
>>> v->BytePerPixelDETY[k],
>>> v->BytePerPixelDETC[k],
>>> - mode_lib->vba.SourceScan[k],
>>> + (enum dm_rotation_angle) mode_lib->vba.SourceScan[k],
>>
>> Hi Jay,
>>
>> This seems fishy, dm_rotation_angle and scan_dirrection_class are very
>> different enums.
>> Comparing dml32_CalculateDCCConfiguration() with
>> CalculateDCCConfiguration(), it seems dm_rotation_angle is new for DCN32. Is
>> passing vba.SourceScan correct here?
>
> I agree. It should be typecast to scan_direction_class
>From the build error, it looks like dml32_CalculateDCCConfiguration() wants
>type `enum dm_rotation_amgle`, but vba.SourceScan[n] is of type `enum
>scan_direction_class`. The error is complaining that we're implicitly casting
>from scan_direction_class to dm_rotation_angle. In otherwords, this was an
>issue prior to Chandan's fix.
I think we'll need to address this separately, but for now this fixes a build
on chromeos with clang 14 that I've been able to reproduce. Elevating my ack to:
Reviewed-by: Leo Li
Thanks!
Leo
>>
>> One more comment below.
>>
>>> /* Output */
>>> >DCCYMaxUncompressedBlock[k],
>>> >DCCCMaxUncompressedBlock[k],
>>> @@ -1741,7 +1741,8 @@ void
>>> dml32_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_l
>>> mode_lib->vba.SourceFormatPixelAndScanSupport = true;
>>> for (k = 0; k <= mode_lib->vba.NumberOfActiveSurfaces - 1; k++) {
>>> if (mode_lib->vba.SurfaceTiling[k] == dm_sw_linear
>>> - && (!(!IsVertical(mode_lib->vba.SourceScan[k])) ||
>>> mode_lib->vba.DCCEnable[k] == true)) {
>>> + && (!(!IsVertical((enum dm_rotation_angle)
>>> mode_lib->vba.SourceScan[k]))
>>> + || mode_lib->vba.DCCEnable[k] == true)) {
>>> mode_lib->vba.SourceFormatPixelAndScanSupport = false;
>>> }
>>> }
>>> diff --git
>>> a/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_util_32.c
>>> b/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_util_32.c
>&g
Re: [PATCH] drm/amdgpu/display: Remove unnecessary typecasts and fix build issues
On 2022-06-07 05:40, Chandan Vurdigere Nataraj wrote:
> [Why]
> Getting below errors:
> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_32.c:1414:5:
> error: implicit conversion from enumeration type 'enum scan_direction_class'
> to different enumeration type 'enum dm_rotation_angle'
> [-Werror,-Wenum-conversion]
> mode_lib->vba.SourceScan[k],
> ^~~
> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_32.c:1744:22:
> error: implicit conversion from enumeration type 'enum scan_direction_class'
> to different enumeration type 'enum dm_rotation_angle'
> [-Werror,-Wenum-conversion]
> && (!(!IsVertical(mode_lib->vba.SourceScan[k])) ||
> mode_lib->vba.DCCEnable[k] == true)) {
>~~ ^~~
> 2 errors generated.
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_util_32.c:5484:18:
> error: implicit conversion from enumeration type 'RequestType' to different
> enumeration type 'enum RequestType' [-Werror,-Wenum-conversion]
> RequestLuma = REQ_256Bytes;
> ~ ^~~~
> 18 errors of similar kind
>
> [How]
> 1. Add typecast at relevant places
> 2. Move the enum RequestType definition ahead of declarations
>
> Signed-off-by: Chandan Vurdigere Nataraj
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_32.c
> b/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_32.c
> index b77a1ae792d1..5828e60f291d 100644
> --- a/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_32.c
> +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_32.c
> @@ -1411,7 +1411,7 @@ static void
> DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerforman
> v->BytePerPixelC[k],
> v->BytePerPixelDETY[k],
> v->BytePerPixelDETC[k],
> - mode_lib->vba.SourceScan[k],
> + (enum dm_rotation_angle)
> mode_lib->vba.SourceScan[k],
Hi Jay,
This seems fishy, dm_rotation_angle and scan_dirrection_class are very
different enums.
Comparing dml32_CalculateDCCConfiguration() with CalculateDCCConfiguration(),
it seems dm_rotation_angle is new for DCN32. Is passing vba.SourceScan correct
here?
One more comment below.
> /* Output */
> >DCCYMaxUncompressedBlock[k],
> >DCCCMaxUncompressedBlock[k],
> @@ -1741,7 +1741,8 @@ void dml32_ModeSupportAndSystemConfigurationFull(struct
> display_mode_lib *mode_l
> mode_lib->vba.SourceFormatPixelAndScanSupport = true;
> for (k = 0; k <= mode_lib->vba.NumberOfActiveSurfaces - 1; k++) {
> if (mode_lib->vba.SurfaceTiling[k] == dm_sw_linear
> - && (!(!IsVertical(mode_lib->vba.SourceScan[k])) ||
> mode_lib->vba.DCCEnable[k] == true)) {
> + && (!(!IsVertical((enum dm_rotation_angle)
> mode_lib->vba.SourceScan[k]))
> + || mode_lib->vba.DCCEnable[k] == true)) {
> mode_lib->vba.SourceFormatPixelAndScanSupport = false;
> }
> }
> diff --git
> a/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_util_32.c
> b/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_util_32.c
> index 6509a84eeb64..07f3a85f8edf 100644
> --- a/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_util_32.c
> +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_util_32.c
> @@ -5314,9 +5314,15 @@ void dml32_CalculateDCCConfiguration(
> unsigned int*IndependentBlockLuma,
> unsigned int*IndependentBlockChroma)
> {
> + typedef enum {
> + REQ_256Bytes,
> + REQ_128BytesNonContiguous,
> + REQ_128BytesContiguous,
> + REQ_NA
> + } RequestType;
>
> - enum RequestType RequestLuma;
> - enum RequestType RequestChroma;
> + RequestType RequestLuma;
> + RequestType RequestChroma;
This might need a wider cleanup, enum RequestType is defined in
display_mode_enums.h and is already included in all the display_mode_vba*.c
files I've come across. Unless I'm missing something, we shouldn't need to
redefine RequestType.
That said, there doesn't seem to be any functional change, and it fixes a build
error. So
Acked-by: Leo Li
Thanks,
Leo
>
Re: [PATCH] drm/amdgpu/display: Fix compilation issues
On 2022-06-07 10:00, Alex Deucher wrote:
> On Tue, Jun 7, 2022 at 4:27 AM Chandan Vurdigere Nataraj
> wrote:
>>
>> [Why]
>> Getting below build errors:
>> drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:1419:3: error:
>> unannotated fall-through between switch labels
>> [-Werror,-Wimplicit-fallthrough]
>> default:
>> ^
>> drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:1535:2: error:
>> unannotated fall-through between switch labels
>> [-Werror,-Wimplicit-fallthrough]
>> default:
>> ^
>>
>> drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:3276:20: error:
>> variable 'v1_5' is uninitialized when used here [-Werror,-Wuninitialized]
>> for (i = 0; i < v1_5->number_of_path; ++i)
>> ^~~~
>>
>> [How]
>> Fix compilation issues
>>
>> Signed-off-by: Chandan Vurdigere Nataraj
>
> Acked-by: Alex Deucher
Reviewed-by: Leo Li
Thanks for the fix!
>
>>
>> diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
>> b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
>> index 3540b46765fb..25791ed0559d 100644
>> --- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
>> +++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
>> @@ -1415,7 +1415,7 @@ static enum bp_result bios_parser_get_lttpr_caps(
>> case 5:
>> result = get_disp_caps_v4_5(bp, dce_caps);
>> *dce_caps = !!(*dce_caps &
>> DCE_INFO_CAPS_LTTPR_SUPPORT_ENABLE);
>> -
>> + break;
>> default:
>> break;
>> }
>> @@ -1532,6 +1532,7 @@ static enum bp_result
>> bios_parser_get_embedded_panel_info(
>> default:
>> break;
>> }
>> + break;
>> default:
>> break;
>> }
>> @@ -3251,7 +3252,7 @@ static enum bp_result get_bracket_layout_record(
>> static enum bp_result result;
>> struct object_info_table *tbl;
>> struct display_object_info_table_v1_4 *v1_4;
>> -struct display_object_info_table_v1_5 *v1_5;
>> + struct display_object_info_table_v1_5 *v1_5;
>>
>> if (slot_layout_info == NULL) {
>> DC_LOG_DETECTION_EDID_PARSER("Invalid slot_layout_info\n");
>> @@ -3259,6 +3260,7 @@ static enum bp_result get_bracket_layout_record(
>> }
>> tbl = >object_info_tbl;
>> v1_4 = tbl->v1_4;
>> + v1_5 = tbl->v1_5;
>>
>> result = BP_RESULT_NORECORD;
>> switch (bp->object_info_tbl.revision.minor) {
>> --
>> 2.25.1
>>
Re: [PATCH 3/4] drm/amd/display: pass panel instance in dirty rect message
On 2022-06-02 16:48, Harry Wentland wrote: > > > On 2022-06-02 14:03, sunpeng...@amd.com wrote: >> From: David Zhang >> >> [why] >> DMUB FW uses OTG instance to get eDP panel instance. But in case >> of MPO multiple pipe indexes are passed to updated the same panel. >> The other OTG instance passed would be ignored causing in DMUB not >> acknowledging the messages. >> >> [how] >> Add panel instance to dirty rectangle data and cursor update data >> structures and pass to DMUB. >> > > I'm not entirely following why passing the panel_inst solves the problem > that is described. Oops, it looks like the commit message is misleading. "panel_inst" already exists in the dmub_cmd structures. It defaults to 0 today due to the memset, which works with single eDP scenarios. What this change is really doing is identifying the panel instance to run PSR commands on, instead of assuming that the eDP we want is always instance 0. Will reword the message. Thanks, Leo > >> Signed-off-by: Mikita Lipski > > This says the author is David but it has only Mikita's sign-off. > We need David's sign-off as well. > > Harry > >> Acked-by: Leo Li >> --- >> drivers/gpu/drm/amd/display/dc/core/dc.c | 5 + >> 1 file changed, 5 insertions(+) >> >> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c >> b/drivers/gpu/drm/amd/display/dc/core/dc.c >> index d4173be11903..31d83297bcb5 100644 >> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c >> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c >> @@ -2837,10 +2837,14 @@ void dc_dmub_update_dirty_rect(struct dc *dc, >> struct dc_context *dc_ctx = dc->ctx; >> struct dmub_cmd_update_dirty_rect_data *update_dirty_rect; >> unsigned int i, j; >> +unsigned int panel_inst = 0; >> >> if (stream->link->psr_settings.psr_version != DC_PSR_VERSION_SU_1) >> return; >> >> +if (!dc_get_edp_link_panel_inst(dc, stream->link, _inst)) >> +return; >> + >> memset(, 0x0, sizeof(cmd)); >> cmd.update_dirty_rect.header.type = DMUB_CMD__UPDATE_DIRTY_RECT; >> cmd.update_dirty_rect.header.sub_type = 0; >> @@ -2869,6 +2873,7 @@ void dc_dmub_update_dirty_rect(struct dc *dc, >> if (pipe_ctx->plane_state != plane_state) >> continue; >> >> +update_dirty_rect->panel_inst = panel_inst; >> update_dirty_rect->pipe_idx = j; >> dc_dmub_srv_cmd_queue(dc_ctx->dmub_srv, ); >> dc_dmub_srv_cmd_execute(dc_ctx->dmub_srv); >
RE: [PATCH] drm/amdgpu: update VCN codec support for Yellow Carp
[AMD Official Use Only - General]
Reviewed-by: Leo Liu
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: May 26, 2022 4:39 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH] drm/amdgpu: update VCN codec support for Yellow Carp
Supports AV1. Mesa already has support for this and doesn't rely on the kernel
caps for yellow carp, so this was already working from an application
perspective.
Bug:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fdrm%2Famd%2F-%2Fissues%2F2002data=05%7C01%7Cleo.liu%40amd.com%7C097e1931973e4c1b9fc308da3f57ccc5%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637891943577189959%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=uW264nO7bt01lNcMxyFI0NUGQT5eb3Z2yFuX2pdnvT0%3Dreserved=0
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/nv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c b/drivers/gpu/drm/amd/amdgpu/nv.c
index d016e3c3e221..b3fba8dea63c 100644
--- a/drivers/gpu/drm/amd/amdgpu/nv.c
+++ b/drivers/gpu/drm/amd/amdgpu/nv.c
@@ -170,6 +170,7 @@ static const struct amdgpu_video_codec_info
yc_video_codecs_decode_array[] = {
{codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_HEVC, 8192, 4352,
186)},
{codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_VP9, 8192, 4352, 0)},
{codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_JPEG, 4096, 4096,
0)},
+ {codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_AV1, 8192, 4352,
+0)},
};
static const struct amdgpu_video_codecs yc_video_codecs_decode = {
--
2.35.3
Re: [PATCH v2 00/19] DC/DM changes needed for amdgpu PSR-SU
On 2022-05-12 13:39, Daniel Vetter wrote: On Thu, 12 May 2022 at 19:22, Zhang, Dingchen (David) wrote: [AMD Official Use Only - General] Hi Daniel Thanks for your comments and explanations. I replied in-line and look forward to more discussion. regards David From: Daniel Vetter Sent: Thursday, May 12, 2022 7:22 AM To: Alex Deucher Cc: Zhang, Dingchen (David) ; amd-gfx list ; Wang, Chao-kai (Stylon) ; Li, Sun peng (Leo) ; Wentland, Harry ; Zhuo, Qingqing (Lillian) ; Siqueira, Rodrigo ; Li, Roman ; Chiu, Solomon ; Zuo, Jerry ; Pillai, Aurabindo ; Lin, Wayne ; Lakha, Bhawanpreet ; Gutierrez, Agustin ; Kotarac, Pavle Subject: Re: [PATCH v2 00/19] DC/DM changes needed for amdgpu PSR-SU On Wed, 11 May 2022 at 17:35, Alex Deucher wrote: On Tue, May 10, 2022 at 4:45 PM David Zhang wrote: changes in v2: --- - set vsc_packet_rev2 for PSR1 which is safer - add exposure of AMD specific DPCD regs for PSR-SU-RC (rate-control) - add DC/DM change related to amdgpu PSR-SU-RC David Zhang (18): drm/amd/display: align dmub cmd header to latest dmub FW to support PSR-SU drm/amd/display: feed PSR-SU as psr version to dmub FW drm/amd/display: combine dirty rectangles in DMUB FW drm/amd/display: update GSP1 generic info packet for PSRSU drm/amd/display: revise Start/End SDP data drm/amd/display: program PSR2 DPCD Configuration drm/amd/display: Passing Y-granularity to dmub fw drm/amd/display: Set default value of line_capture_indication drm/amd/display: add vline time in micro sec to PSR context drm/amd/display: fix system hang when PSR exits drm/amd/display: Set PSR level to enable ALPM by default drm/amd/display: use HW lock mgr for PSR-SU drm/amd/display: PSRSU+DSC WA for specific TCON drm/amd/display: add shared helpers to update psr config fields to power module drm/amd/display: calculate psr config settings in runtime in DM drm/amd/display: update cursor position to DMUB FW drm/amd/display: expose AMD source specific DPCD for FreeSync PSR support drm/amd/display: PSR-SU rate control support in DC Leo Li (1): drm/amd/display: Implement MPO PSR SU A couple of suggestions from Daniel on IRC: 1. Might be good to extract the "calculate total crtc damage" code from i915 in intel_psr2_sel_fetch_update, stuff that into damage helpers and reuse for i915 and amdgpu To expand a bit on this. There is currently a helper for total damage, but it's at the fb/plane level for drivers which need to upload buffers (usb/spi or virtual) drm_atomic_helper_damage_merged(). That one probably needs to be renamed to signify it's about the plane, and then we need a new drm_atomic_helper_crtc_damage_merged() which (extract from i915 code ideally) which computes total crtc damage for stuff like psr2/su or the command mode dsi panels (unfortunately none of the drivers for android for these panels have been upstreamed yet). <<< Checked the DRM comment for the helper `drm_atomic_helper_damage_merged()` and quoted below: * Drivers might want to use the helper functions drm_atomic_helper_damage_iter_init() and drm_atomic_helper_damage_iter_next() or drm_atomic_helper_damage_merged() if the driver can only handle a single damage region at most. * Currently for amdgpu, the multiple damage clips combination (merging) is handled in DMUB firmware. And the DRM comment shows that the usage of "damage_merged()" helper is for the driver which can only handle single damage region at most. Since AMDGPU is capable of handling multiple damaged clip (in DMUB FW), can I understand that the group of helpers of `damage_merged()` in DRM is not mandatory but optional? Ah I didn't see from a quick read that this was possible. How does this work when the plane is enabled/disabled or resized or moved? -Daniel Hi Daniel, When a plane is disabled, enabled, and/or resized(*), PSR is temporarily disabled. The mechanism to do so isn't in this patchset, but was added when PSR1 was first introduced to amdgpu_dm. In short, amdgpu_dm will disable PSR whenever DC requires a full update to program an atomic state (needs bandwidth recalculations and/or shuffling hw resources). For DC, enabling, disabling, and changing the scaling of a plane are considered full updates. When the plane is moved, both the old and new plane bounds are given to FW as dirty rectangles. (*)Resize should fall under the same bucket, though DC would consider that as a full update. I think disabling PSR would take precedence... will give this another spin to check. Thanks, Leo I also think that the split between dc and kms is a bit funny, I'd put only the resulting damage rect into dc_pipe and do the computation of that in the drm/kms linux code outside of dc functions (or in the glue code for dc), since I'm assuming on windows it's completely different approach in how you compute damage. Especially once we have the crt
Re: [PATCH V3] drm/amdgpu/vcn3: send smu interface type
Reviewed-by: Leo Liu
On 2022-03-30 20:59, boyuan.zh...@amd.com wrote:
From: Boyuan Zhang
For VCN FW to detect ASIC type, in order to use different mailbox registers.
V2: simplify codes and fix format issue.
V3: re-order if/else condition from the smallest version.
Signed-off-by: Boyuan Zhang
Acked-by Huang Rui
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h | 7 +++
drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c | 5 +
2 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
index e2fde88aaf5e..f06fb7f882e2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
@@ -159,6 +159,7 @@
#define AMDGPU_VCN_MULTI_QUEUE_FLAG (1 << 8)
#define AMDGPU_VCN_SW_RING_FLAG (1 << 9)
#define AMDGPU_VCN_FW_LOGGING_FLAG(1 << 10)
+#define AMDGPU_VCN_SMU_VERSION_INFO_FLAG (1 << 11)
#define AMDGPU_VCN_IB_FLAG_DECODE_BUFFER 0x0001
#define AMDGPU_VCN_CMD_FLAG_MSG_BUFFER0x0001
@@ -279,6 +280,11 @@ struct amdgpu_fw_shared_fw_logging {
uint32_t size;
};
+struct amdgpu_fw_shared_smu_interface_info {
+ uint8_t smu_interface_type;
+ uint8_t padding[3];
+};
+
struct amdgpu_fw_shared {
uint32_t present_flag_0;
uint8_t pad[44];
@@ -287,6 +293,7 @@ struct amdgpu_fw_shared {
struct amdgpu_fw_shared_multi_queue multi_queue;
struct amdgpu_fw_shared_sw_ring sw_ring;
struct amdgpu_fw_shared_fw_logging fw_log;
+ struct amdgpu_fw_shared_smu_interface_info smu_interface_info;
};
struct amdgpu_vcn_fwlog {
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
index 0d590183328f..508b3d8464f2 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
@@ -219,6 +219,11 @@ static int vcn_v3_0_sw_init(void *handle)
cpu_to_le32(AMDGPU_VCN_MULTI_QUEUE_FLAG) |
cpu_to_le32(AMDGPU_VCN_FW_SHARED_FLAG_0_RB);
fw_shared->sw_ring.is_enabled =
cpu_to_le32(DEC_SW_RING_ENABLED);
+ fw_shared->present_flag_0 |= AMDGPU_VCN_SMU_VERSION_INFO_FLAG;
+ if (adev->ip_versions[UVD_HWIP][0] == IP_VERSION(3, 1, 1))
+ fw_shared->smu_interface_info.smu_interface_type = 1;
+ else if (adev->ip_versions[UVD_HWIP][0] == IP_VERSION(3, 1, 2))
+ fw_shared->smu_interface_info.smu_interface_type = 2;
if (amdgpu_vcnfw_log)
amdgpu_vcn_fwlog_init(>vcn.inst[i]);
Re: [PATCH v2] drm/amdgpu: add workarounds for Raven VCN TMZ issue
No need for encode. Encrypting uses TEE/TA to convert clear bitstream to
encrypted bitstream, and has nothing to do with VCN encode and tmz.
Regards,
Leo
On 2022-03-10 04:53, Christian König wrote:
Leo you didn't answered the question if we need TMZ for encode as well.
Regards,
Christian.
Am 10.03.22 um 09:45 schrieb Lang Yu:
Ping.
On 03/08/ , Leo Liu wrote:
On 2022-03-08 11:18, Leo Liu wrote:
On 2022-03-08 04:16, Christian König wrote:
Am 08.03.22 um 09:06 schrieb Lang Yu:
On 03/08/ , Christian König wrote:
Am 08.03.22 um 08:33 schrieb Lang Yu:
On 03/08/ , Christian König wrote:
Am 08.03.22 um 04:39 schrieb Lang Yu:
It is a hardware issue that VCN can't handle a GTT
backing stored TMZ buffer on Raven.
Move such a TMZ buffer to VRAM domain before command
submission.
v2:
- Use patch_cs_in_place callback.
Suggested-by: Christian König
Signed-off-by: Lang Yu
---
drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c | 68
+++
1 file changed, 68 insertions(+)
diff --git
a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
index 7bbb9ba6b80b..810932abd3af 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
@@ -24,6 +24,7 @@
#include
#include "amdgpu.h"
+#include "amdgpu_cs.h"
#include "amdgpu_vcn.h"
#include "amdgpu_pm.h"
#include "soc15.h"
@@ -1905,6 +1906,72 @@ static const struct
amd_ip_funcs vcn_v1_0_ip_funcs = {
.set_powergating_state =
vcn_v1_0_set_powergating_state,
};
+/**
+ * It is a hardware issue that Raven VCN can't
handle a GTT TMZ buffer.
+ * Move such a GTT TMZ buffer to VRAM domain
before command submission.
+ */
+static int vcn_v1_0_validate_bo(struct amdgpu_cs_parser
*parser,
+ struct amdgpu_job *job,
+ uint64_t addr)
+{
+ struct ttm_operation_ctx ctx = { false, false };
+ struct amdgpu_fpriv *fpriv = parser->filp->driver_priv;
+ struct amdgpu_vm *vm = >vm;
+ struct amdgpu_bo_va_mapping *mapping;
+ struct amdgpu_bo *bo;
+ int r;
+
+ addr &= AMDGPU_GMC_HOLE_MASK;
+ if (addr & 0x7) {
+ DRM_ERROR("VCN messages must be 8 byte aligned!\n");
+ return -EINVAL;
+ }
+
+ mapping = amdgpu_vm_bo_lookup_mapping(vm,
addr/AMDGPU_GPU_PAGE_SIZE);
+ if (!mapping || !mapping->bo_va ||
!mapping->bo_va->base.bo)
+ return -EINVAL;
+
+ bo = mapping->bo_va->base.bo;
+ if (!(bo->flags & AMDGPU_GEM_CREATE_ENCRYPTED))
+ return 0;
+
+ amdgpu_bo_placement_from_domain(bo,
AMDGPU_GEM_DOMAIN_VRAM);
+ r = ttm_bo_validate(>tbo, >placement, );
+ if (r) {
+ DRM_ERROR("Failed validating the VCN
message BO (%d)!\n", r);
+ return r;
+ }
Well, exactly that won't work.
The message structure isn't TMZ protected because
otherwise the driver won't
be able to stitch it together.
What is TMZ protected are the surfaces the message
structure is pointing to.
So what you would need to do is to completely parse
the structure and then
move on the relevant buffers into VRAM.
Leo or James, can you help with that?
From my observations, when decoding secure contents, register
GPCOM_VCPU_DATA0 and GPCOM_VCPU_DATA1 are set to a TMZ
buffer address.
And this way works when allocating TMZ buffers in GTT domain.
As far as I remember that's only the case for the decoding,
encoding works
by putting the addresses into the message buffer.
But could be that decoding is sufficient, Leo and James need
to comment on
this.
It seems that only decode needs TMZ buffers. Only observe
si_vid_create_tmz_buffer()
was called in rvcn_dec_message_decode() in
src/gallium/drivers/radeon/radeon_vcn_dec.c.
Mhm, good point. Let's wait for Leo and James to wake up, when we
don't need encode support than that would makes things much easier.
For secure playback, the buffer required in TMZ are dpb, dt and
ctx, for
the rest esp. those for CPU access don't need that E.g. msg buffer,
and
bitstream buffer.
From radeon_vcn_dec.c, you can see the buffer for dpb and ctx, and dt
buffer frontend/va/surface is set to PIPE_BIND_PROTECTED.
Regards,
Leo
For VCN1, due to performance reason, the msg and fb buffer was
allocated
into VRAM instead of GTT(for other HW), but those are not TMZ in
order to
have CPU access.
Regards,
Leo
Regards,
Christian.
Regards,
Lang
Regards,
Christian.
Regards,
Lang
Regards,
Christian.
+
+ return r;
+}
+
+static int
vcn_v1_0_ring_patch_cs_in_place(struct
amdgpu_cs_parser *p,
+ struct amdgpu_job *job,
+ struct amdgpu_ib *ib)
+{
+ uint32_t msg_lo = 0, msg_hi = 0;
+ int i, r;
+
+ for (i = 0; i < ib->length_dw; i += 2) {
+ uint32_t reg = amdgpu_ib_get_value(ib, i);
+ uint32_t val = amdgpu_ib_get_value(ib, i + 1);
+
+ if (reg == PACKET0(p->
Re: [PATCH v2] drm/amdgpu: add workarounds for Raven VCN TMZ issue
On 2022-03-08 11:18, Leo Liu wrote:
On 2022-03-08 04:16, Christian König wrote:
Am 08.03.22 um 09:06 schrieb Lang Yu:
On 03/08/ , Christian König wrote:
Am 08.03.22 um 08:33 schrieb Lang Yu:
On 03/08/ , Christian König wrote:
Am 08.03.22 um 04:39 schrieb Lang Yu:
It is a hardware issue that VCN can't handle a GTT
backing stored TMZ buffer on Raven.
Move such a TMZ buffer to VRAM domain before command
submission.
v2:
- Use patch_cs_in_place callback.
Suggested-by: Christian König
Signed-off-by: Lang Yu
---
drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c | 68
+++
1 file changed, 68 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
index 7bbb9ba6b80b..810932abd3af 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
@@ -24,6 +24,7 @@
#include
#include "amdgpu.h"
+#include "amdgpu_cs.h"
#include "amdgpu_vcn.h"
#include "amdgpu_pm.h"
#include "soc15.h"
@@ -1905,6 +1906,72 @@ static const struct amd_ip_funcs
vcn_v1_0_ip_funcs = {
.set_powergating_state = vcn_v1_0_set_powergating_state,
};
+/**
+ * It is a hardware issue that Raven VCN can't handle a GTT TMZ
buffer.
+ * Move such a GTT TMZ buffer to VRAM domain before command
submission.
+ */
+static int vcn_v1_0_validate_bo(struct amdgpu_cs_parser *parser,
+ struct amdgpu_job *job,
+ uint64_t addr)
+{
+ struct ttm_operation_ctx ctx = { false, false };
+ struct amdgpu_fpriv *fpriv = parser->filp->driver_priv;
+ struct amdgpu_vm *vm = >vm;
+ struct amdgpu_bo_va_mapping *mapping;
+ struct amdgpu_bo *bo;
+ int r;
+
+ addr &= AMDGPU_GMC_HOLE_MASK;
+ if (addr & 0x7) {
+ DRM_ERROR("VCN messages must be 8 byte aligned!\n");
+ return -EINVAL;
+ }
+
+ mapping = amdgpu_vm_bo_lookup_mapping(vm,
addr/AMDGPU_GPU_PAGE_SIZE);
+ if (!mapping || !mapping->bo_va || !mapping->bo_va->base.bo)
+ return -EINVAL;
+
+ bo = mapping->bo_va->base.bo;
+ if (!(bo->flags & AMDGPU_GEM_CREATE_ENCRYPTED))
+ return 0;
+
+ amdgpu_bo_placement_from_domain(bo, AMDGPU_GEM_DOMAIN_VRAM);
+ r = ttm_bo_validate(>tbo, >placement, );
+ if (r) {
+ DRM_ERROR("Failed validating the VCN message BO
(%d)!\n", r);
+ return r;
+ }
Well, exactly that won't work.
The message structure isn't TMZ protected because otherwise the
driver won't
be able to stitch it together.
What is TMZ protected are the surfaces the message structure is
pointing to.
So what you would need to do is to completely parse the structure
and then
move on the relevant buffers into VRAM.
Leo or James, can you help with that?
From my observations, when decoding secure contents, register
GPCOM_VCPU_DATA0 and GPCOM_VCPU_DATA1 are set to a TMZ buffer
address.
And this way works when allocating TMZ buffers in GTT domain.
As far as I remember that's only the case for the decoding,
encoding works
by putting the addresses into the message buffer.
But could be that decoding is sufficient, Leo and James need to
comment on
this.
It seems that only decode needs TMZ buffers. Only observe
si_vid_create_tmz_buffer()
was called in rvcn_dec_message_decode() in
src/gallium/drivers/radeon/radeon_vcn_dec.c.
Mhm, good point. Let's wait for Leo and James to wake up, when we
don't need encode support than that would makes things much easier.
For secure playback, the buffer required in TMZ are dpb, dt and ctx,
for the rest esp. those for CPU access don't need that E.g. msg
buffer, and bitstream buffer.
From radeon_vcn_dec.c, you can see the buffer for dpb and ctx, and dt
buffer frontend/va/surface is set to PIPE_BIND_PROTECTED.
Regards,
Leo
For VCN1, due to performance reason, the msg and fb buffer was allocated
into VRAM instead of GTT(for other HW), but those are not TMZ in order
to have CPU access.
Regards,
Leo
Regards,
Christian.
Regards,
Lang
Regards,
Christian.
Regards,
Lang
Regards,
Christian.
+
+ return r;
+}
+
+static int vcn_v1_0_ring_patch_cs_in_place(struct
amdgpu_cs_parser *p,
+ struct amdgpu_job *job,
+ struct amdgpu_ib *ib)
+{
+ uint32_t msg_lo = 0, msg_hi = 0;
+ int i, r;
+
+ for (i = 0; i < ib->length_dw; i += 2) {
+ uint32_t reg = amdgpu_ib_get_value(ib, i);
+ uint32_t val = amdgpu_ib_get_value(ib, i + 1);
+
+ if (reg == PACKET0(p->adev->vcn.internal.data0, 0)) {
+ msg_lo = val;
+ } else if (reg == PACKET0(p->adev->vcn.internal.data1,
0)) {
+ msg_hi = val;
+ } else if (reg == PACKET0(p->adev->vcn.internal.cmd, 0)) {
+ r = vcn_v1_0_validate_bo(p, job,
+ ((u64)msg_hi) << 32 | msg_lo);
+
Re: [PATCH v2] drm/amdgpu: add workarounds for Raven VCN TMZ issue
On 2022-03-08 04:16, Christian König wrote:
Am 08.03.22 um 09:06 schrieb Lang Yu:
On 03/08/ , Christian König wrote:
Am 08.03.22 um 08:33 schrieb Lang Yu:
On 03/08/ , Christian König wrote:
Am 08.03.22 um 04:39 schrieb Lang Yu:
It is a hardware issue that VCN can't handle a GTT
backing stored TMZ buffer on Raven.
Move such a TMZ buffer to VRAM domain before command
submission.
v2:
- Use patch_cs_in_place callback.
Suggested-by: Christian König
Signed-off-by: Lang Yu
---
drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c | 68
+++
1 file changed, 68 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
index 7bbb9ba6b80b..810932abd3af 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
@@ -24,6 +24,7 @@
#include
#include "amdgpu.h"
+#include "amdgpu_cs.h"
#include "amdgpu_vcn.h"
#include "amdgpu_pm.h"
#include "soc15.h"
@@ -1905,6 +1906,72 @@ static const struct amd_ip_funcs
vcn_v1_0_ip_funcs = {
.set_powergating_state = vcn_v1_0_set_powergating_state,
};
+/**
+ * It is a hardware issue that Raven VCN can't handle a GTT TMZ
buffer.
+ * Move such a GTT TMZ buffer to VRAM domain before command
submission.
+ */
+static int vcn_v1_0_validate_bo(struct amdgpu_cs_parser *parser,
+ struct amdgpu_job *job,
+ uint64_t addr)
+{
+ struct ttm_operation_ctx ctx = { false, false };
+ struct amdgpu_fpriv *fpriv = parser->filp->driver_priv;
+ struct amdgpu_vm *vm = >vm;
+ struct amdgpu_bo_va_mapping *mapping;
+ struct amdgpu_bo *bo;
+ int r;
+
+ addr &= AMDGPU_GMC_HOLE_MASK;
+ if (addr & 0x7) {
+ DRM_ERROR("VCN messages must be 8 byte aligned!\n");
+ return -EINVAL;
+ }
+
+ mapping = amdgpu_vm_bo_lookup_mapping(vm,
addr/AMDGPU_GPU_PAGE_SIZE);
+ if (!mapping || !mapping->bo_va || !mapping->bo_va->base.bo)
+ return -EINVAL;
+
+ bo = mapping->bo_va->base.bo;
+ if (!(bo->flags & AMDGPU_GEM_CREATE_ENCRYPTED))
+ return 0;
+
+ amdgpu_bo_placement_from_domain(bo, AMDGPU_GEM_DOMAIN_VRAM);
+ r = ttm_bo_validate(>tbo, >placement, );
+ if (r) {
+ DRM_ERROR("Failed validating the VCN message BO
(%d)!\n", r);
+ return r;
+ }
Well, exactly that won't work.
The message structure isn't TMZ protected because otherwise the
driver won't
be able to stitch it together.
What is TMZ protected are the surfaces the message structure is
pointing to.
So what you would need to do is to completely parse the structure
and then
move on the relevant buffers into VRAM.
Leo or James, can you help with that?
From my observations, when decoding secure contents, register
GPCOM_VCPU_DATA0 and GPCOM_VCPU_DATA1 are set to a TMZ buffer address.
And this way works when allocating TMZ buffers in GTT domain.
As far as I remember that's only the case for the decoding, encoding
works
by putting the addresses into the message buffer.
But could be that decoding is sufficient, Leo and James need to
comment on
this.
It seems that only decode needs TMZ buffers. Only observe
si_vid_create_tmz_buffer()
was called in rvcn_dec_message_decode() in
src/gallium/drivers/radeon/radeon_vcn_dec.c.
Mhm, good point. Let's wait for Leo and James to wake up, when we
don't need encode support than that would makes things much easier.
For secure playback, the buffer required in TMZ are dpb, dt and ctx, for
the rest esp. those for CPU access don't need that E.g. msg buffer, and
bitstream buffer.
From radeon_vcn_dec.c, you can see the buffer for dpb and ctx, and dt
buffer frontend/va/surface is set to PIPE_BIND_PROTECTED.
Regards,
Leo
Regards,
Christian.
Regards,
Lang
Regards,
Christian.
Regards,
Lang
Regards,
Christian.
+
+ return r;
+}
+
+static int vcn_v1_0_ring_patch_cs_in_place(struct
amdgpu_cs_parser *p,
+ struct amdgpu_job *job,
+ struct amdgpu_ib *ib)
+{
+ uint32_t msg_lo = 0, msg_hi = 0;
+ int i, r;
+
+ for (i = 0; i < ib->length_dw; i += 2) {
+ uint32_t reg = amdgpu_ib_get_value(ib, i);
+ uint32_t val = amdgpu_ib_get_value(ib, i + 1);
+
+ if (reg == PACKET0(p->adev->vcn.internal.data0, 0)) {
+ msg_lo = val;
+ } else if (reg == PACKET0(p->adev->vcn.internal.data1,
0)) {
+ msg_hi = val;
+ } else if (reg == PACKET0(p->adev->vcn.internal.cmd, 0)) {
+ r = vcn_v1_0_validate_bo(p, job,
+ ((u64)msg_hi) << 32 | msg_lo);
+ if (r)
+ return r;
+ }
+ }
+
+ return 0;
+}
+
+
static const struct amdgpu_ring_funcs
vcn_v1_0_dec_ring_vm_funcs = {
.type = AMDGPU_RING_TYPE_VCN_DEC,
.align_mask =
RE: [PATCH 1/2] drm/amdgpu/vcn: Update fw shared data structure
[AMD Official Use Only]
The series are:
Reviewed-by: Leo Liu
-Original Message-
From: Dong, Ruijing
Sent: March 2, 2022 4:25 PM
To: amd-gfx@lists.freedesktop.org
Cc: Liu, Leo ; Deucher, Alexander
Subject: [PATCH 1/2] drm/amdgpu/vcn: Update fw shared data structure
Add fw log in fw shared data structure.
Signed-off-by: Ruijing Dong
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 14 -
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h | 26 +++--
drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c | 18 -
drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c | 18 -
drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c | 20 +--
5 files changed, 61 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
index 5e0dbf54d561..6f3f55e39ab1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
@@ -79,6 +79,7 @@ int amdgpu_vcn_sw_init(struct amdgpu_device *adev)
const char *fw_name;
const struct common_firmware_header *hdr;
unsigned char fw_check;
+ unsigned int fw_shared_size;
int i, r;
INIT_DELAYED_WORK(>vcn.idle_work, amdgpu_vcn_idle_work_handler);
@@ -226,7 +227,8 @@ int amdgpu_vcn_sw_init(struct amdgpu_device *adev)
bo_size = AMDGPU_VCN_STACK_SIZE + AMDGPU_VCN_CONTEXT_SIZE;
if (adev->firmware.load_type != AMDGPU_FW_LOAD_PSP)
bo_size +=
AMDGPU_GPU_PAGE_ALIGN(le32_to_cpu(hdr->ucode_size_bytes) + 8);
- bo_size += AMDGPU_GPU_PAGE_ALIGN(sizeof(struct amdgpu_fw_shared));
+ fw_shared_size = AMDGPU_GPU_PAGE_ALIGN(sizeof(struct amdgpu_fw_shared));
+ bo_size += fw_shared_size;
for (i = 0; i < adev->vcn.num_vcn_inst; i++) {
if (adev->vcn.harvest_config & (1 << i)) @@ -240,10 +242,12 @@
int amdgpu_vcn_sw_init(struct amdgpu_device *adev)
return r;
}
- adev->vcn.inst[i].fw_shared_cpu_addr =
adev->vcn.inst[i].cpu_addr +
- bo_size - AMDGPU_GPU_PAGE_ALIGN(sizeof(struct
amdgpu_fw_shared));
- adev->vcn.inst[i].fw_shared_gpu_addr =
adev->vcn.inst[i].gpu_addr +
- bo_size - AMDGPU_GPU_PAGE_ALIGN(sizeof(struct
amdgpu_fw_shared));
+ adev->vcn.inst[i].fw_shared.cpu_addr =
adev->vcn.inst[i].cpu_addr +
+ bo_size - fw_shared_size;
+ adev->vcn.inst[i].fw_shared.gpu_addr =
adev->vcn.inst[i].gpu_addr +
+ bo_size - fw_shared_size;
+
+ adev->vcn.inst[i].fw_shared.mem_size = fw_shared_size;
if (adev->vcn.indirect_sram) {
r = amdgpu_bo_create_kernel(adev, 64 * 2 * 4,
PAGE_SIZE, diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
index 5d3728b027d3..f6569a7d6fdb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
@@ -205,6 +205,13 @@ struct amdgpu_vcn_reg{
unsignedscratch9;
};
+struct amdgpu_vcn_fw_shared {
+ void*cpu_addr;
+ uint64_tgpu_addr;
+ uint32_tmem_size;
+ uint32_tlog_offset;
+};
+
struct amdgpu_vcn_inst {
struct amdgpu_bo*vcpu_bo;
void*cpu_addr;
@@ -221,8 +228,7 @@ struct amdgpu_vcn_inst {
uint64_tdpg_sram_gpu_addr;
uint32_t*dpg_sram_curr_addr;
atomic_tdpg_enc_submission_cnt;
- void*fw_shared_cpu_addr;
- uint64_tfw_shared_gpu_addr;
+ struct amdgpu_vcn_fw_shared fw_shared;
};
struct amdgpu_vcn {
@@ -265,6 +271,13 @@ struct amdgpu_fw_shared_sw_ring {
uint8_t padding[3];
};
+struct amdgpu_fw_shared_fw_logging {
+ uint8_t is_enabled;
+ uint32_t addr_lo;
+ uint32_t addr_hi;
+ uint32_t size;
+};
+
struct amdgpu_fw_shared {
uint32_t present_flag_0;
uint8_t pad[44];
@@ -272,6 +285,15 @@ struct amdgpu_fw_shared {
uint8_t pad1[1];
struct amdgpu_fw_shared_multi_queue multi_queue;
struct amdgpu_fw_shared_sw_ring sw_ring;
+ struct amdgpu_fw_shared_fw_logging fw_log; };
+
+struct amdgpu_vcn_fwlog {
+ uint32_t rptr;
+ uint32_t wptr;
+ uint32_t buffer_size;
+ uint32_t header_size;
+ uint8_t wrapped;
};
struct amdgpu_vcn_decode_buffer {
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c
index 313fc1b53999..36ec877a2a55 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c
@@ -172,7 +172,7 @@ static int vcn_v2_0_sw_init(void *handle)
if (r)
return r;
- fw_shared = adev->vcn
Re: [PATCH 6/6] drm/amdgpu/discovery: Add sw DM function for 3.1.6 DCE
On 2022-02-15 16:44, Alex Deucher wrote: From: Prike Liang Add 3.1.6 DCE IP and assign relevant sw DM function for the new DCE. Signed-off-by: Prike Liang Reviewed-by: Alex Deucher Reviewed-by: Leo Li Thanks! Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c index babc0ab3208e..8fa3cf8dad48 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c @@ -1366,6 +1366,7 @@ static int amdgpu_discovery_set_display_ip_blocks(struct amdgpu_device *adev) case IP_VERSION(3, 0, 1): case IP_VERSION(3, 1, 2): case IP_VERSION(3, 1, 3): + case IP_VERSION(3, 1, 6): amdgpu_device_ip_block_add(adev, _ip_block); break; default:
Re: [PATCH 5/6] drm/amd/display: Add DCN316 resource and SMU clock manager
On 2022-02-15 16:44, Alex Deucher wrote: diff --git a/drivers/gpu/drm/amd/display/dc/gpio/Makefile b/drivers/gpu/drm/amd/display/dc/gpio/Makefile index c5ddade8b187..a1bf2128feba 100644 --- a/drivers/gpu/drm/amd/display/dc/gpio/Makefile +++ b/drivers/gpu/drm/amd/display/dc/gpio/Makefile @@ -106,6 +106,7 @@ GPIO_DCN30 = hw_translate_dcn30.o hw_factory_dcn30.o AMD_DAL_GPIO_DCN30 = $(addprefix $(AMDDALPATH)/dc/gpio/dcn30/,$(GPIO_DCN30)) AMD_DISPLAY_FILES += $(AMD_DAL_GPIO_DCN30) + Looks like we can drop this newline. Otherwise, Reviewed-by: Leo Li endif ### # Diagnostics on FPGA -- 2.34.1
Re: [PATCH 3/6] drm/amd/display: configure dc hw resource for DCN 3.1.6
On 2022-02-15 16:44, Alex Deucher wrote:
From: Prike Liang
- set DC version
- add construct/destroy dc clock management function
- register dcn interrupt handler
Signed-off-by: Prike Liang
Acked-by: Leo Li
Reviewed-by: Leo Li
Thanks.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 +-
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_hdcp.c | 3 ++-
.../amd/display/dc/bios/command_table_helper2.c| 1 +
drivers/gpu/drm/amd/display/dc/clk_mgr/clk_mgr.c | 4 +++-
drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 4
drivers/gpu/drm/amd/display/dc/gpio/hw_factory.c | 1 +
drivers/gpu/drm/amd/display/dc/gpio/hw_translate.c | 1 +
drivers/gpu/drm/amd/display/include/dal_asic_id.h | 6 +-
drivers/gpu/drm/amd/display/include/dal_types.h| 1 +
9 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 10ca3fc6d91e..a4254357bf5f 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -114,6 +114,8 @@ MODULE_FIRMWARE(FIRMWARE_DIMGREY_CAVEFISH_DMUB);
MODULE_FIRMWARE(FIRMWARE_BEIGE_GOBY_DMUB);
#define FIRMWARE_YELLOW_CARP_DMUB "amdgpu/yellow_carp_dmcub.bin"
MODULE_FIRMWARE(FIRMWARE_YELLOW_CARP_DMUB);
+#define FIRMWARE_DCN316_DMUB "amdgpu/dcn_3_1_6_dmcub.bin"
+MODULE_FIRMWARE(FIRMWARE_DCN316_DMUB);
#define FIRMWARE_RAVEN_DMCU "amdgpu/raven_dmcu.bin"
MODULE_FIRMWARE(FIRMWARE_RAVEN_DMCU);
@@ -1801,6 +1803,7 @@ static int load_dmcu_fw(struct amdgpu_device *adev)
case IP_VERSION(3, 0, 1):
case IP_VERSION(3, 1, 2):
case IP_VERSION(3, 1, 3):
+ case IP_VERSION(3, 1, 6):
return 0;
default:
break;
@@ -1916,6 +1919,10 @@ static int dm_dmub_sw_init(struct amdgpu_device *adev)
dmub_asic = (adev->external_rev_id == YELLOW_CARP_B0) ?
DMUB_ASIC_DCN31B : DMUB_ASIC_DCN31;
fw_name_dmub = FIRMWARE_YELLOW_CARP_DMUB;
break;
+ case IP_VERSION(3, 1, 6):
+ dmub_asic = DMUB_ASIC_DCN31B;
+ fw_name_dmub = FIRMWARE_DCN316_DMUB;
+ break;
default:
/* ASIC doesn't support DMUB. */
@@ -4224,6 +4231,7 @@ static int amdgpu_dm_initialize_drm_device(struct
amdgpu_device *adev)
case IP_VERSION(3, 0, 0):
case IP_VERSION(3, 1, 2):
case IP_VERSION(3, 1, 3):
+ case IP_VERSION(3, 1, 6):
case IP_VERSION(2, 1, 0):
if (register_outbox_irq_handlers(dm->adev)) {
DRM_ERROR("DM: Failed to initialize IRQ\n");
@@ -4240,6 +4248,7 @@ static int amdgpu_dm_initialize_drm_device(struct
amdgpu_device *adev)
switch (adev->ip_versions[DCE_HWIP][0]) {
case IP_VERSION(3, 1, 2):
case IP_VERSION(3, 1, 3):
+ case IP_VERSION(3, 1, 6):
psr_feature_enabled = true;
break;
default:
@@ -4356,6 +4365,7 @@ static int amdgpu_dm_initialize_drm_device(struct
amdgpu_device *adev)
case IP_VERSION(3, 0, 1):
case IP_VERSION(3, 1, 2):
case IP_VERSION(3, 1, 3):
+ case IP_VERSION(3, 1, 6):
if (dcn10_register_irq_handlers(dm->adev)) {
DRM_ERROR("DM: Failed to initialize IRQ\n");
goto fail;
@@ -4541,6 +4551,7 @@ static int dm_early_init(void *handle)
case IP_VERSION(2, 1, 0):
case IP_VERSION(3, 1, 2):
case IP_VERSION(3, 1, 3):
+ case IP_VERSION(3, 1, 6):
adev->mode_info.num_crtc = 4;
adev->mode_info.num_hpd = 4;
adev->mode_info.num_dig = 4;
@@ -5213,6 +5224,7 @@ get_plane_modifiers(const struct amdgpu_device *adev,
unsigned int plane_type, u
case AMDGPU_FAMILY_NV:
case AMDGPU_FAMILY_VGH:
case AMDGPU_FAMILY_YC:
+ case AMDGPU_FAMILY_GC_10_3_7:
if (adev->ip_versions[GC_HWIP][0] >= IP_VERSION(10, 3, 0))
add_gfx10_3_modifiers(adev, mods, , );
else
@@ -6179,7 +6191,7 @@ static void apply_dsc_policy_for_stream(struct
amdgpu_dm_connector *aconnector,
if (stream->link && stream->link->local_sink)
max_dsc_target_bpp_limit_override =
stream->link->local_sink->edid_caps.panel_patch.max_dsc_target_bpp_limit;
-
+
/* Set DSC policy according to dsc_clock_en */
dc_dsc_policy_set_enable_dsc_when_not_needed(
aconnector->d
Re: [PATCH] drm/radeon: fix UVD suspend error
On 2022-01-17 2:47 a.m., Qiang Ma wrote:
I met a bug recently and the kernel log:
[ 330.171875] radeon :03:00.0: couldn't schedule ib
[ 330.175781] [drm:radeon_uvd_suspend [radeon]] *ERROR* Error destroying UVD
(-22)!
In radeon drivers, using UVD suspend is as follows:
if (rdev->has_uvd) {
uvd_v1_0_fini(rdev);
radeon_uvd_suspend(rdev);
}
In radeon_ib_schedule function, we check the 'ring->ready' state,
but in uvd_v1_0_fini funciton, we've cleared the ready state.
So, just modify the suspend code flow to fix error.
It seems reasonable to me. The suspend sends the destroy message if
there is still incomplete job, so it should be before the fini which
stops the hardware.
The series are:
Reviewed-by: Leo Liu
Signed-off-by: Qiang Ma
---
drivers/gpu/drm/radeon/cik.c | 2 +-
drivers/gpu/drm/radeon/evergreen.c | 2 +-
drivers/gpu/drm/radeon/ni.c| 2 +-
drivers/gpu/drm/radeon/r600.c | 2 +-
drivers/gpu/drm/radeon/rv770.c | 2 +-
drivers/gpu/drm/radeon/si.c| 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 81b4de7be9f2..5819737c21c6 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -8517,8 +8517,8 @@ int cik_suspend(struct radeon_device *rdev)
cik_cp_enable(rdev, false);
cik_sdma_enable(rdev, false);
if (rdev->has_uvd) {
- uvd_v1_0_fini(rdev);
radeon_uvd_suspend(rdev);
+ uvd_v1_0_fini(rdev);
}
if (rdev->has_vce)
radeon_vce_suspend(rdev);
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index eeb590d2dec2..455f8036aa54 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -5156,8 +5156,8 @@ int evergreen_suspend(struct radeon_device *rdev)
radeon_pm_suspend(rdev);
radeon_audio_fini(rdev);
if (rdev->has_uvd) {
- uvd_v1_0_fini(rdev);
radeon_uvd_suspend(rdev);
+ uvd_v1_0_fini(rdev);
}
r700_cp_stop(rdev);
r600_dma_stop(rdev);
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 4a364ca7a1be..927e5f42e97d 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -2323,8 +2323,8 @@ int cayman_suspend(struct radeon_device *rdev)
cayman_cp_enable(rdev, false);
cayman_dma_stop(rdev);
if (rdev->has_uvd) {
- uvd_v1_0_fini(rdev);
radeon_uvd_suspend(rdev);
+ uvd_v1_0_fini(rdev);
}
evergreen_irq_suspend(rdev);
radeon_wb_disable(rdev);
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index ca3fcae2adb5..dd78fc499402 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -3232,8 +3232,8 @@ int r600_suspend(struct radeon_device *rdev)
radeon_audio_fini(rdev);
r600_cp_stop(rdev);
if (rdev->has_uvd) {
- uvd_v1_0_fini(rdev);
radeon_uvd_suspend(rdev);
+ uvd_v1_0_fini(rdev);
}
r600_irq_suspend(rdev);
radeon_wb_disable(rdev);
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index e592e57be1bb..38796af4fadd 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -1894,8 +1894,8 @@ int rv770_suspend(struct radeon_device *rdev)
radeon_pm_suspend(rdev);
radeon_audio_fini(rdev);
if (rdev->has_uvd) {
- uvd_v1_0_fini(rdev);
radeon_uvd_suspend(rdev);
+ uvd_v1_0_fini(rdev);
}
r700_cp_stop(rdev);
r600_dma_stop(rdev);
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index 013e44ed0f39..8d5e4b25609d 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -6800,8 +6800,8 @@ int si_suspend(struct radeon_device *rdev)
si_cp_enable(rdev, false);
cayman_dma_stop(rdev);
if (rdev->has_uvd) {
- uvd_v1_0_fini(rdev);
radeon_uvd_suspend(rdev);
+ uvd_v1_0_fini(rdev);
}
if (rdev->has_vce)
radeon_vce_suspend(rdev);
RE: [PATCH] drm/amd/display: Drop config guard for DC_LOG_DP2
[AMD Official Use Only]
Agree.
Patch applied. Thanks for your review
-Leo
-Original Message-
From: Alex Deucher
Sent: Thursday, November 18, 2021 12:02 PM
To: Ma, Leo
Cc: Kazlauskas, Nicholas ; amd-gfx list
; Deucher, Alexander
; Choi, Nicholas ; Wentland,
Harry
Subject: Re: [PATCH] drm/amd/display: Drop config guard for DC_LOG_DP2
On Thu, Nov 18, 2021 at 11:53 AM Leo (Hanghong) Ma wrote:
>
> [Why & How]
> It doesn't make sense to guard DC_LOG_DP2 by CONFIG_DRM_AMD_DCN, and
> this also caused build failure for allmodconfig; So drop the guard to
> fix the compile failure;
>
> Signed-off-by: Leo (Hanghong) Ma
Reviewed-by: Alex Deucher
At some point we may want to rework what the DC_LOG stuff maps too (e.g., use
dev_debug or the newer drm interfaces).
Alex
> ---
> drivers/gpu/drm/amd/display/include/logger_types.h | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/include/logger_types.h
> b/drivers/gpu/drm/amd/display/include/logger_types.h
> index 370fad883e33..f093b49c5e6e 100644
> --- a/drivers/gpu/drm/amd/display/include/logger_types.h
> +++ b/drivers/gpu/drm/amd/display/include/logger_types.h
> @@ -72,9 +72,7 @@
> #define DC_LOG_DSC(...) DRM_DEBUG_KMS(__VA_ARGS__) #define
> DC_LOG_SMU(...) pr_debug("[SMU_MSG]:"__VA_ARGS__) #define
> DC_LOG_DWB(...) DRM_DEBUG_KMS(__VA_ARGS__) -#if
> defined(CONFIG_DRM_AMD_DC_DCN) #define DC_LOG_DP2(...)
> DRM_DEBUG_KMS(__VA_ARGS__) -#endif
>
> struct dal_logger;
>
> @@ -126,9 +124,7 @@ enum dc_log_type {
> LOG_MAX_HW_POINTS,
> LOG_ALL_TF_CHANNELS,
> LOG_SAMPLE_1DLUT,
> -#if defined(CONFIG_DRM_AMD_DC_DCN)
> LOG_DP2,
> -#endif
> LOG_SECTION_TOTAL_COUNT
> };
>
> --
> 2.17.1
>
[PATCH] drm/amd/display: Drop config guard for DC_LOG_DP2
[Why & How]
It doesn't make sense to guard DC_LOG_DP2 by CONFIG_DRM_AMD_DCN, and
this also caused build failure for allmodconfig; So drop the guard
to fix the compile failure;
Signed-off-by: Leo (Hanghong) Ma
---
drivers/gpu/drm/amd/display/include/logger_types.h | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/include/logger_types.h
b/drivers/gpu/drm/amd/display/include/logger_types.h
index 370fad883e33..f093b49c5e6e 100644
--- a/drivers/gpu/drm/amd/display/include/logger_types.h
+++ b/drivers/gpu/drm/amd/display/include/logger_types.h
@@ -72,9 +72,7 @@
#define DC_LOG_DSC(...) DRM_DEBUG_KMS(__VA_ARGS__)
#define DC_LOG_SMU(...) pr_debug("[SMU_MSG]:"__VA_ARGS__)
#define DC_LOG_DWB(...) DRM_DEBUG_KMS(__VA_ARGS__)
-#if defined(CONFIG_DRM_AMD_DC_DCN)
#define DC_LOG_DP2(...) DRM_DEBUG_KMS(__VA_ARGS__)
-#endif
struct dal_logger;
@@ -126,9 +124,7 @@ enum dc_log_type {
LOG_MAX_HW_POINTS,
LOG_ALL_TF_CHANNELS,
LOG_SAMPLE_1DLUT,
-#if defined(CONFIG_DRM_AMD_DC_DCN)
LOG_DP2,
-#endif
LOG_SECTION_TOTAL_COUNT
};
--
2.17.1
[PATCH] drm/amd/display: Reduce dmesg error to a debug print
[Why & How]
Dmesg errors are found on dcn3.1 during reset test, but it's not
a really failure. So reduce it to a debug print.
Signed-off-by: Leo (Hanghong) Ma
---
drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
index cb7bf9148904..c7785e29b1c0 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
@@ -4454,7 +4454,7 @@ bool dp_retrieve_lttpr_cap(struct dc_link *link)
lttpr_dpcd_data,
sizeof(lttpr_dpcd_data));
if (status != DC_OK) {
- dm_error("%s: Read LTTPR caps data failed.\n",
__func__);
+ DC_LOG_DP2("%s: Read LTTPR caps data failed.\n",
__func__);
return false;
}
--
2.17.1
Re: [PATCH 4/4] drm/amdgpu/vcn3.0: remove intermediate variable
The series are:
Reviewed-by: Leo Liu
On 2021-10-19 4:10 p.m., Alex Deucher wrote:
No need to use the id variable, just use the constant
plus instance offset directly.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
index 57b62fb04750..da11ceba0698 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
@@ -60,11 +60,6 @@ static int amdgpu_ih_clientid_vcns[] = {
SOC15_IH_CLIENTID_VCN1
};
-static int amdgpu_ucode_id_vcns[] = {
- AMDGPU_UCODE_ID_VCN,
- AMDGPU_UCODE_ID_VCN1
-};
-
static int vcn_v3_0_start_sriov(struct amdgpu_device *adev);
static void vcn_v3_0_set_dec_ring_funcs(struct amdgpu_device *adev);
static void vcn_v3_0_set_enc_ring_funcs(struct amdgpu_device *adev);
@@ -1278,7 +1273,6 @@ static int vcn_v3_0_start_sriov(struct amdgpu_device
*adev)
uint32_t param, resp, expected;
uint32_t offset, cache_size;
uint32_t tmp, timeout;
- uint32_t id;
struct amdgpu_mm_table *table = >virt.mm_table;
uint32_t *table_loc;
@@ -1322,13 +1316,12 @@ static int vcn_v3_0_start_sriov(struct amdgpu_device
*adev)
cache_size = AMDGPU_GPU_PAGE_ALIGN(adev->vcn.fw->size + 4);
if (adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) {
- id = amdgpu_ucode_id_vcns[i];
MMSCH_V3_0_INSERT_DIRECT_WT(SOC15_REG_OFFSET(VCN, i,
mmUVD_LMI_VCPU_CACHE_64BIT_BAR_LOW),
- adev->firmware.ucode[id].tmr_mc_addr_lo);
+ adev->firmware.ucode[AMDGPU_UCODE_ID_VCN +
i].tmr_mc_addr_lo);
MMSCH_V3_0_INSERT_DIRECT_WT(SOC15_REG_OFFSET(VCN, i,
mmUVD_LMI_VCPU_CACHE_64BIT_BAR_HIGH),
- adev->firmware.ucode[id].tmr_mc_addr_hi);
+ adev->firmware.ucode[AMDGPU_UCODE_ID_VCN +
i].tmr_mc_addr_hi);
offset = 0;
MMSCH_V3_0_INSERT_DIRECT_WT(SOC15_REG_OFFSET(VCN, i,
mmUVD_VCPU_CACHE_OFFSET0),
Re: [PATCH 1/2] drm/amdgpu/jpeg2: move jpeg2 shared macro to header file
The series are: Reviewed-by: Leo Liu On 2021-09-29 3:57 p.m., James Zhu wrote: Move jpeg2 shared macro to header file Signed-off-by: James Zhu --- drivers/gpu/drm/amd/amdgpu/jpeg_v2_0.c | 20 drivers/gpu/drm/amd/amdgpu/jpeg_v2_0.h | 20 2 files changed, 20 insertions(+), 20 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/jpeg_v2_0.c b/drivers/gpu/drm/amd/amdgpu/jpeg_v2_0.c index 85967a5..299de1d 100644 --- a/drivers/gpu/drm/amd/amdgpu/jpeg_v2_0.c +++ b/drivers/gpu/drm/amd/amdgpu/jpeg_v2_0.c @@ -32,26 +32,6 @@ #include "vcn/vcn_2_0_0_sh_mask.h" #include "ivsrcid/vcn/irqsrcs_vcn_2_0.h" -#define mmUVD_JRBC_EXTERNAL_REG_INTERNAL_OFFSET0x1bfff -#define mmUVD_JPEG_GPCOM_CMD_INTERNAL_OFFSET 0x4029 -#define mmUVD_JPEG_GPCOM_DATA0_INTERNAL_OFFSET 0x402a -#define mmUVD_JPEG_GPCOM_DATA1_INTERNAL_OFFSET 0x402b -#define mmUVD_LMI_JRBC_RB_MEM_WR_64BIT_BAR_LOW_INTERNAL_OFFSET 0x40ea -#define mmUVD_LMI_JRBC_RB_MEM_WR_64BIT_BAR_HIGH_INTERNAL_OFFSET 0x40eb -#define mmUVD_LMI_JRBC_IB_VMID_INTERNAL_OFFSET 0x40cf -#define mmUVD_LMI_JPEG_VMID_INTERNAL_OFFSET0x40d1 -#define mmUVD_LMI_JRBC_IB_64BIT_BAR_LOW_INTERNAL_OFFSET 0x40e8 -#define mmUVD_LMI_JRBC_IB_64BIT_BAR_HIGH_INTERNAL_OFFSET 0x40e9 -#define mmUVD_JRBC_IB_SIZE_INTERNAL_OFFSET 0x4082 -#define mmUVD_LMI_JRBC_RB_MEM_RD_64BIT_BAR_LOW_INTERNAL_OFFSET 0x40ec -#define mmUVD_LMI_JRBC_RB_MEM_RD_64BIT_BAR_HIGH_INTERNAL_OFFSET 0x40ed -#define mmUVD_JRBC_RB_COND_RD_TIMER_INTERNAL_OFFSET0x4085 -#define mmUVD_JRBC_RB_REF_DATA_INTERNAL_OFFSET 0x4084 -#define mmUVD_JRBC_STATUS_INTERNAL_OFFSET 0x4089 -#define mmUVD_JPEG_PITCH_INTERNAL_OFFSET 0x401f - -#define JRBC_DEC_EXTERNAL_REG_WRITE_ADDR 0x18000 - static void jpeg_v2_0_set_dec_ring_funcs(struct amdgpu_device *adev); static void jpeg_v2_0_set_irq_funcs(struct amdgpu_device *adev); static int jpeg_v2_0_set_powergating_state(void *handle, diff --git a/drivers/gpu/drm/amd/amdgpu/jpeg_v2_0.h b/drivers/gpu/drm/amd/amdgpu/jpeg_v2_0.h index 15a344e..1a03baa 100644 --- a/drivers/gpu/drm/amd/amdgpu/jpeg_v2_0.h +++ b/drivers/gpu/drm/amd/amdgpu/jpeg_v2_0.h @@ -24,6 +24,26 @@ #ifndef __JPEG_V2_0_H__ #define __JPEG_V2_0_H__ +#define mmUVD_JRBC_EXTERNAL_REG_INTERNAL_OFFSET0x1bfff +#define mmUVD_JPEG_GPCOM_CMD_INTERNAL_OFFSET 0x4029 +#define mmUVD_JPEG_GPCOM_DATA0_INTERNAL_OFFSET 0x402a +#define mmUVD_JPEG_GPCOM_DATA1_INTERNAL_OFFSET 0x402b +#define mmUVD_LMI_JRBC_RB_MEM_WR_64BIT_BAR_LOW_INTERNAL_OFFSET 0x40ea +#define mmUVD_LMI_JRBC_RB_MEM_WR_64BIT_BAR_HIGH_INTERNAL_OFFSET 0x40eb +#define mmUVD_LMI_JRBC_IB_VMID_INTERNAL_OFFSET 0x40cf +#define mmUVD_LMI_JPEG_VMID_INTERNAL_OFFSET0x40d1 +#define mmUVD_LMI_JRBC_IB_64BIT_BAR_LOW_INTERNAL_OFFSET 0x40e8 +#define mmUVD_LMI_JRBC_IB_64BIT_BAR_HIGH_INTERNAL_OFFSET 0x40e9 +#define mmUVD_JRBC_IB_SIZE_INTERNAL_OFFSET 0x4082 +#define mmUVD_LMI_JRBC_RB_MEM_RD_64BIT_BAR_LOW_INTERNAL_OFFSET 0x40ec +#define mmUVD_LMI_JRBC_RB_MEM_RD_64BIT_BAR_HIGH_INTERNAL_OFFSET 0x40ed +#define mmUVD_JRBC_RB_COND_RD_TIMER_INTERNAL_OFFSET0x4085 +#define mmUVD_JRBC_RB_REF_DATA_INTERNAL_OFFSET 0x4084 +#define mmUVD_JRBC_STATUS_INTERNAL_OFFSET 0x4089 +#define mmUVD_JPEG_PITCH_INTERNAL_OFFSET 0x401f + +#define JRBC_DEC_EXTERNAL_REG_WRITE_ADDR 0x18000 + void jpeg_v2_0_dec_ring_insert_start(struct amdgpu_ring *ring); void jpeg_v2_0_dec_ring_insert_end(struct amdgpu_ring *ring); void jpeg_v2_0_dec_ring_emit_fence(struct amdgpu_ring *ring, u64 addr, u64 seq,
Re: [PATCH] drm/amd/display: Reduce stack size for dml21_ModeSupportAndSystemConfigurationFull
On 2021-09-14 17:05, Harry Wentland wrote:
[Why & How]
With Werror enabled in the kernel we were failing the clang build since
dml21_ModeSupportAndSystemConfigurationFull's stack frame is 1064 when
building with clang, and exceeding the default 1024 stack frame limit.
The culprit seems to be the Pipe struct, so pull the relevant block
out into its own sub-function.
Signed-off-by: Harry Wentland
Fixes: 3fe617ccafd6 ("Enable '-Werror' by default for all kernel builds")
Cc: Nick Desaulniers
Cc: Linus Torvalds
Cc:amd-gfx@lists.freedesktop.org
Cc: Linux Kernel Mailing List
Cc: Arnd Bergmann
Cc: Leo Li
Cc: Alex Deucher
Cc: Christian König
Cc: Xinhui Pan
Cc: Nathan Chancellor
Cc: Guenter Roeck
Cc:l...@lists.linux.dev
---
Reviewed-by: Leo Li
