[PATCH 4/4] drm/amd/display: Move 'struct scaler_data' off stack
From: Arnd Bergmann
The scaler_data structure is implicitly copied onto the stack twice by
being returned from a function. This is usually a bad idea, but it
was not flagged by the compiler until a recent addition that pushed
it over the 1024 byte function stack limit:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/dml2_translation_helper.c: In
function 'populate_dml_plane_cfg_from_plane_state':
drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/dml2_translation_helper.c:1075:1:
error: the frame size of 1032 bytes is larger than 1024 bytes
[-Werror=frame-larger-than=]
Use an explicit kzalloc() and memcpy() instead here to keep it off the
stack.
Fixes: 00c391102abc ("drm/amd/display: Add misc DC changes for DCN401")
Fixes: 7966f319c66d ("drm/amd/display: Introduce DML2")
Signed-off-by: Arnd Bergmann
---
.../display/dc/dml2/dml2_translation_helper.c | 56 ++-
1 file changed, 31 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml2/dml2_translation_helper.c
b/drivers/gpu/drm/amd/display/dc/dml2/dml2_translation_helper.c
index 705985d3f407..c04ebf5434c9 100644
--- a/drivers/gpu/drm/amd/display/dc/dml2/dml2_translation_helper.c
+++ b/drivers/gpu/drm/amd/display/dc/dml2/dml2_translation_helper.c
@@ -927,7 +927,7 @@ static void populate_dml_surface_cfg_from_plane_state(enum
dml_project_id dml2_p
}
}
-static struct scaler_data get_scaler_data_for_plane(const struct
dc_plane_state *in, struct dc_state *context)
+static void get_scaler_data_for_plane(const struct dc_plane_state *in, struct
dc_state *context, struct scaler_data *out)
{
int i;
struct pipe_ctx *temp_pipe = >res_ctx.temp_pipe;
@@ -948,7 +948,7 @@ static struct scaler_data get_scaler_data_for_plane(const
struct dc_plane_state
}
ASSERT(i < MAX_PIPES);
- return temp_pipe->plane_res.scl_data;
+ memcpy(out, _pipe->plane_res.scl_data, sizeof(*out));
}
static void populate_dummy_dml_plane_cfg(struct dml_plane_cfg_st *out,
unsigned int location, const struct dc_stream_state *in)
@@ -1007,27 +1007,31 @@ static void populate_dummy_dml_plane_cfg(struct
dml_plane_cfg_st *out, unsigned
static void populate_dml_plane_cfg_from_plane_state(struct dml_plane_cfg_st
*out, unsigned int location, const struct dc_plane_state *in, struct dc_state
*context)
{
- const struct scaler_data scaler_data = get_scaler_data_for_plane(in,
context);
+ struct scaler_data *scaler_data = kzalloc(sizeof(*scaler_data),
GFP_KERNEL);
+ if (!scaler_data)
+ return;
+
+ get_scaler_data_for_plane(in, context, scaler_data);
out->CursorBPP[location] = dml_cur_32bit;
out->CursorWidth[location] = 256;
out->GPUVMMinPageSizeKBytes[location] = 256;
- out->ViewportWidth[location] = scaler_data.viewport.width;
- out->ViewportHeight[location] = scaler_data.viewport.height;
- out->ViewportWidthChroma[location] = scaler_data.viewport_c.width;
- out->ViewportHeightChroma[location] = scaler_data.viewport_c.height;
- out->ViewportXStart[location] = scaler_data.viewport.x;
- out->ViewportYStart[location] = scaler_data.viewport.y;
- out->ViewportXStartC[location] = scaler_data.viewport_c.x;
- out->ViewportYStartC[location] = scaler_data.viewport_c.y;
+ out->ViewportWidth[location] = scaler_data->viewport.width;
+ out->ViewportHeight[location] = scaler_data->viewport.height;
+ out->ViewportWidthChroma[location] = scaler_data->viewport_c.width;
+ out->ViewportHeightChroma[location] = scaler_data->viewport_c.height;
+ out->ViewportXStart[location] = scaler_data->viewport.x;
+ out->ViewportYStart[location] = scaler_data->viewport.y;
+ out->ViewportXStartC[location] = scaler_data->viewport_c.x;
+ out->ViewportYStartC[location] = scaler_data->viewport_c.y;
out->ViewportStationary[location] = false;
- out->ScalerEnabled[location] = scaler_data.ratios.horz.value !=
dc_fixpt_one.value ||
- scaler_data.ratios.horz_c.value !=
dc_fixpt_one.value ||
- scaler_data.ratios.vert.value !=
dc_fixpt_one.value ||
- scaler_data.ratios.vert_c.value !=
dc_fixpt_one.value;
+ out->ScalerEnabled[location] = scaler_data->ratios.horz.value !=
dc_fixpt_one.value ||
+ scaler_data->ratios.horz_c.value !=
dc_fixpt_one.value ||
+ scaler_data->ratios.vert.value !=
dc_fixpt_one.value ||
+ scaler_data->ratios.vert_c.value !=
dc_fixpt_one.value;
/* Current driver code base uses LBBitPerPixel as 57. There is a
discrepancy
* from the HW/DML teams about this value. Initialize LBBitPerPixel
with the
@@ -1043,25 +1
[PATCH 3/4] drm/amd/display: avoid large on-stack structures
From: Arnd Bergmann
Putting excessively large objects on a function stack causes
a warning about possibly overflowing the 8KiB of kernel stack:
drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn401/dcn401_resource.c: In
function 'dcn401_update_bw_bounding_box':
drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn401/dcn401_resource.c:1599:1:
error: the frame size of 1196 bytes is larger than 1024 bytes
[-Werror=frame-larger-than=]
1599 | }
| ^
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_state.c: In function
'dc_state_create':
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_state.c:221:1: error: the
frame size of 1196 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
221 | }
| ^
Use dynamic allocation instead.
Fixes: e779f4587f61 ("drm/amd/display: Add handling for DC power mode")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/dc/core/dc_state.c | 16 +++-
.../display/dc/resource/dcn401/dcn401_resource.c | 16 +++-
2 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_state.c
b/drivers/gpu/drm/amd/display/dc/core/dc_state.c
index 70928223b642..8ea9391c60b7 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_state.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_state.c
@@ -193,7 +193,11 @@ static void init_state(struct dc *dc, struct dc_state
*state)
struct dc_state *dc_state_create(struct dc *dc, struct dc_state_create_params
*params)
{
#ifdef CONFIG_DRM_AMD_DC_FP
- struct dml2_configuration_options dml2_opt = dc->dml2_options;
+ struct dml2_configuration_options *dml2_opt;
+
+ dml2_opt = kmemdup(>dml2_options, sizeof(*dml2_opt), GFP_KERNEL);
+ if (!dml2_opt)
+ return NULL;
#endif
struct dc_state *state = kvzalloc(sizeof(struct dc_state),
GFP_KERNEL);
@@ -207,12 +211,14 @@ struct dc_state *dc_state_create(struct dc *dc, struct
dc_state_create_params *p
#ifdef CONFIG_DRM_AMD_DC_FP
if (dc->debug.using_dml2) {
- dml2_opt.use_clock_dc_limits = false;
- dml2_create(dc, _opt, >bw_ctx.dml2);
+ dml2_opt->use_clock_dc_limits = false;
+ dml2_create(dc, dml2_opt, >bw_ctx.dml2);
- dml2_opt.use_clock_dc_limits = true;
- dml2_create(dc, _opt, >bw_ctx.dml2_dc_power_source);
+ dml2_opt->use_clock_dc_limits = true;
+ dml2_create(dc, dml2_opt, >bw_ctx.dml2_dc_power_source);
}
+
+ kfree(dml2_opt);
#endif
kref_init(>refcount);
diff --git a/drivers/gpu/drm/amd/display/dc/resource/dcn401/dcn401_resource.c
b/drivers/gpu/drm/amd/display/dc/resource/dcn401/dcn401_resource.c
index 247bac177d1b..8dfb0a3d21cb 100644
--- a/drivers/gpu/drm/amd/display/dc/resource/dcn401/dcn401_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/resource/dcn401/dcn401_resource.c
@@ -1581,21 +1581,27 @@ static struct dc_cap_funcs cap_funcs = {
static void dcn401_update_bw_bounding_box(struct dc *dc, struct clk_bw_params
*bw_params)
{
- struct dml2_configuration_options dml2_opt = dc->dml2_options;
+ struct dml2_configuration_options *dml2_opt;
+
+ dml2_opt = kmemdup(>dml2_options, sizeof(*dml2_opt), GFP_KERNEL);
+ if (!dml2_opt)
+ return;
DC_FP_START();
dcn401_update_bw_bounding_box_fpu(dc, bw_params);
- dml2_opt.use_clock_dc_limits = false;
+ dml2_opt->use_clock_dc_limits = false;
if (dc->debug.using_dml2 && dc->current_state &&
dc->current_state->bw_ctx.dml2)
- dml2_reinit(dc, _opt, >current_state->bw_ctx.dml2);
+ dml2_reinit(dc, dml2_opt, >current_state->bw_ctx.dml2);
- dml2_opt.use_clock_dc_limits = true;
+ dml2_opt->use_clock_dc_limits = true;
if (dc->debug.using_dml2 && dc->current_state &&
dc->current_state->bw_ctx.dml2_dc_power_source)
- dml2_reinit(dc, _opt,
>current_state->bw_ctx.dml2_dc_power_source);
+ dml2_reinit(dc, dml2_opt,
>current_state->bw_ctx.dml2_dc_power_source);
DC_FP_END();
+
+ kfree(dml2_opt);
}
enum dc_status dcn401_patch_unknown_plane_state(struct dc_plane_state
*plane_state)
--
2.39.2
[PATCH 2/4] [RESEND] drm/amd/display: fix graphics_object_id size
From: Arnd Bergmann
The graphics_object_id structure is meant to fit into 32 bits, as it's
passed by value in and out of functions. A recent change increased
the size to 128 bits, so it's now always passed by reference, which
is clearly not intended and ends up producing a compile-time warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_factory.c: In function
'construct_phy':
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_factory.c:743:1: error: the
frame size of 1040 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
Add back the bitfields to revert to the original size, while keeping
the 'enum' type change.
fec85f995a4b ("drm/amd/display: Fix compiler redefinition warnings for certain
configs")
Signed-off-by: Arnd Bergmann
---
Originally sent as
https://lore.kernel.org/all/20240418083421.3956461-2-a...@kernel.org/
---
drivers/gpu/drm/amd/display/include/grph_object_id.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/include/grph_object_id.h
b/drivers/gpu/drm/amd/display/include/grph_object_id.h
index 08ee0350b31f..54e33062b3c0 100644
--- a/drivers/gpu/drm/amd/display/include/grph_object_id.h
+++ b/drivers/gpu/drm/amd/display/include/grph_object_id.h
@@ -226,8 +226,8 @@ enum dp_alt_mode {
struct graphics_object_id {
uint32_t id:8;
- enum object_enum_id enum_id;
- enum object_type type;
+ enum object_enum_id enum_id :4;
+ enum object_type type :4;
uint32_t reserved:16; /* for padding. total size should be u32 */
};
--
2.39.2
[PATCH 1/4] [RESEND] drm/amd/display: dynamically allocate dml2_configuration_options structures
From: Arnd Bergmann
This structure is too large to fit on a stack, as shown by the
newly introduced warnings from a recent code change:
drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn32/dcn32_resource.c: In
function 'dcn32_update_bw_bounding_box':
drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn32/dcn32_resource.c:2019:1:
error: the frame size of 1180 bytes is larger than 1024 bytes
[-Werror=frame-larger-than=]
drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn321/dcn321_resource.c: In
function 'dcn321_update_bw_bounding_box':
drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn321/dcn321_resource.c:1597:1:
error: the frame size of 1180 bytes is larger than 1024 bytes
[-Werror=frame-larger-than=]
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_state.c: In function
'dc_state_create':
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_state.c:219:1: error: the
frame size of 1184 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
Instead of open-coding the assignment of a large structure to a stack
variable, use an explicit kmemdup() in each case to move it off the stack.
Fixes: e779f4587f61 ("drm/amd/display: Add handling for DC power mode")
Signed-off-by: Arnd Bergmann
---
Originally sent as
https://lore.kernel.org/all/20240418083421.3956461-1-a...@kernel.org/
---
.../display/dc/resource/dcn32/dcn32_resource.c | 16 +++-
.../display/dc/resource/dcn321/dcn321_resource.c | 16 +++-
2 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/resource/dcn32/dcn32_resource.c
b/drivers/gpu/drm/amd/display/dc/resource/dcn32/dcn32_resource.c
index 022d320be1d5..0f11d7c8791c 100644
--- a/drivers/gpu/drm/amd/display/dc/resource/dcn32/dcn32_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/resource/dcn32/dcn32_resource.c
@@ -2007,21 +2007,27 @@ void dcn32_calculate_wm_and_dlg(struct dc *dc, struct
dc_state *context,
static void dcn32_update_bw_bounding_box(struct dc *dc, struct clk_bw_params
*bw_params)
{
- struct dml2_configuration_options dml2_opt = dc->dml2_options;
+ struct dml2_configuration_options *dml2_opt;
+
+ dml2_opt = kmemdup(>dml2_options, sizeof(dc->dml2_options),
GFP_KERNEL);
+ if (!dml2_opt)
+ return;
DC_FP_START();
dcn32_update_bw_bounding_box_fpu(dc, bw_params);
- dml2_opt.use_clock_dc_limits = false;
+ dml2_opt->use_clock_dc_limits = false;
if (dc->debug.using_dml2 && dc->current_state &&
dc->current_state->bw_ctx.dml2)
- dml2_reinit(dc, _opt, >current_state->bw_ctx.dml2);
+ dml2_reinit(dc, dml2_opt, >current_state->bw_ctx.dml2);
- dml2_opt.use_clock_dc_limits = true;
+ dml2_opt->use_clock_dc_limits = true;
if (dc->debug.using_dml2 && dc->current_state &&
dc->current_state->bw_ctx.dml2_dc_power_source)
- dml2_reinit(dc, _opt,
>current_state->bw_ctx.dml2_dc_power_source);
+ dml2_reinit(dc, dml2_opt,
>current_state->bw_ctx.dml2_dc_power_source);
DC_FP_END();
+
+ kfree(dml2_opt);
}
static struct resource_funcs dcn32_res_pool_funcs = {
diff --git a/drivers/gpu/drm/amd/display/dc/resource/dcn321/dcn321_resource.c
b/drivers/gpu/drm/amd/display/dc/resource/dcn321/dcn321_resource.c
index e4b360d89b3b..07ca6f58447d 100644
--- a/drivers/gpu/drm/amd/display/dc/resource/dcn321/dcn321_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/resource/dcn321/dcn321_resource.c
@@ -1581,21 +1581,27 @@ static struct dc_cap_funcs cap_funcs = {
static void dcn321_update_bw_bounding_box(struct dc *dc, struct clk_bw_params
*bw_params)
{
- struct dml2_configuration_options dml2_opt = dc->dml2_options;
+ struct dml2_configuration_options *dml2_opt;
+
+ dml2_opt = kmemdup(>dml2_options, sizeof(dc->dml2_options),
GFP_KERNEL);
+ if (!dml2_opt)
+ return;
DC_FP_START();
dcn321_update_bw_bounding_box_fpu(dc, bw_params);
- dml2_opt.use_clock_dc_limits = false;
+ dml2_opt->use_clock_dc_limits = false;
if (dc->debug.using_dml2 && dc->current_state &&
dc->current_state->bw_ctx.dml2)
- dml2_reinit(dc, _opt, >current_state->bw_ctx.dml2);
+ dml2_reinit(dc, dml2_opt, >current_state->bw_ctx.dml2);
- dml2_opt.use_clock_dc_limits = true;
+ dml2_opt->use_clock_dc_limits = true;
if (dc->debug.using_dml2 && dc->current_state &&
dc->current_state->bw_ctx.dml2_dc_power_source)
- dml2_reinit(dc, _opt,
>current_state->bw_ctx.dml2_dc_power_source);
+ dml2_reinit(dc, dml2_opt,
>current_state->bw_ctx.dml2_dc_power_source);
DC_FP_END();
+
+ kfree(dml2_opt);
}
static struct resource_funcs dcn321_res_pool_funcs = {
--
2.39.2
[PATCH] drm/amdkfd: select CONFIG_CRC16
From: Arnd Bergmann
The amdkfd support fails to link when CONFIG_CRC16 is disabled:
aarch64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_topology.o: in function
`kfd_topology_add_device':
kfd_topology.c:(.text+0x3a4c): undefined reference to `crc16'
This is a library module that needs to be selected from every user.
Fixes: 3ed181b8ff43 ("drm/amdkfd: Ensure gpu_id is unique")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/amdkfd/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdkfd/Kconfig
b/drivers/gpu/drm/amd/amdkfd/Kconfig
index d3c3d3ab7225..f82595af34bf 100644
--- a/drivers/gpu/drm/amd/amdkfd/Kconfig
+++ b/drivers/gpu/drm/amd/amdkfd/Kconfig
@@ -6,6 +6,7 @@
config HSA_AMD
bool "HSA kernel driver for AMD GPU devices"
depends on DRM_AMDGPU && (X86_64 || ARM64 || PPC64)
+ select CRC16
select HMM_MIRROR
select MMU_NOTIFIER
select DRM_AMDGPU_USERPTR
--
2.39.2
[PATCH 2/2] drm/amd/display: fix graphics_object_id size
From: Arnd Bergmann
The graphics_object_id structure is meant to fit into 32 bits, as it's
passed by value in and out of functions. A recent change increased
the size to 128 bits, so it's now always passed by reference, which
is clearly not intended and ends up producing a compile-time warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_factory.c: In function
'construct_phy':
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_factory.c:743:1: error: the
frame size of 1040 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
Add back the bitfields to revert to the original size, while keeping
the 'enum' type change.
fec85f995a4b ("drm/amd/display: Fix compiler redefinition warnings for certain
configs")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/include/grph_object_id.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/include/grph_object_id.h
b/drivers/gpu/drm/amd/display/include/grph_object_id.h
index 08ee0350b31f..54e33062b3c0 100644
--- a/drivers/gpu/drm/amd/display/include/grph_object_id.h
+++ b/drivers/gpu/drm/amd/display/include/grph_object_id.h
@@ -226,8 +226,8 @@ enum dp_alt_mode {
struct graphics_object_id {
uint32_t id:8;
- enum object_enum_id enum_id;
- enum object_type type;
+ enum object_enum_id enum_id :4;
+ enum object_type type :4;
uint32_t reserved:16; /* for padding. total size should be u32 */
};
--
2.39.2
[PATCH 1/2] drm/amd/display: dynamically allocate dml2_configuration_options structures
From: Arnd Bergmann
This structure is too large to fit on a stack, as shown by the
newly introduced warnings from a recent code change:
drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn32/dcn32_resource.c: In
function 'dcn32_update_bw_bounding_box':
drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn32/dcn32_resource.c:2019:1:
error: the frame size of 1180 bytes is larger than 1024 bytes
[-Werror=frame-larger-than=]
drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn321/dcn321_resource.c: In
function 'dcn321_update_bw_bounding_box':
drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn321/dcn321_resource.c:1597:1:
error: the frame size of 1180 bytes is larger than 1024 bytes
[-Werror=frame-larger-than=]
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_state.c: In function
'dc_state_create':
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_state.c:219:1: error: the
frame size of 1184 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
Instead of open-coding the assignment of a large structure to a stack
variable, use an explicit kmemdup() in each case to move it off the stack.
Fixes: e779f4587f61 ("drm/amd/display: Add handling for DC power mode")
Signed-off-by: Arnd Bergmann
---
.../display/dc/resource/dcn32/dcn32_resource.c | 16 +++-
.../display/dc/resource/dcn321/dcn321_resource.c | 16 +++-
2 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/resource/dcn32/dcn32_resource.c
b/drivers/gpu/drm/amd/display/dc/resource/dcn32/dcn32_resource.c
index c16e915686fc..b2b95f5abb09 100644
--- a/drivers/gpu/drm/amd/display/dc/resource/dcn32/dcn32_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/resource/dcn32/dcn32_resource.c
@@ -2001,21 +2001,27 @@ void dcn32_calculate_wm_and_dlg(struct dc *dc, struct
dc_state *context,
static void dcn32_update_bw_bounding_box(struct dc *dc, struct clk_bw_params
*bw_params)
{
- struct dml2_configuration_options dml2_opt = dc->dml2_options;
+ struct dml2_configuration_options *dml2_opt;
+
+ dml2_opt = kmemdup(>dml2_options, sizeof(dc->dml2_options),
GFP_KERNEL);
+ if (!dml2_opt)
+ return;
DC_FP_START();
dcn32_update_bw_bounding_box_fpu(dc, bw_params);
- dml2_opt.use_clock_dc_limits = false;
+ dml2_opt->use_clock_dc_limits = false;
if (dc->debug.using_dml2 && dc->current_state &&
dc->current_state->bw_ctx.dml2)
- dml2_reinit(dc, _opt, >current_state->bw_ctx.dml2);
+ dml2_reinit(dc, dml2_opt, >current_state->bw_ctx.dml2);
- dml2_opt.use_clock_dc_limits = true;
+ dml2_opt->use_clock_dc_limits = true;
if (dc->debug.using_dml2 && dc->current_state &&
dc->current_state->bw_ctx.dml2_dc_power_source)
- dml2_reinit(dc, _opt,
>current_state->bw_ctx.dml2_dc_power_source);
+ dml2_reinit(dc, dml2_opt,
>current_state->bw_ctx.dml2_dc_power_source);
DC_FP_END();
+
+ kfree(dml2_opt);
}
static struct resource_funcs dcn32_res_pool_funcs = {
diff --git a/drivers/gpu/drm/amd/display/dc/resource/dcn321/dcn321_resource.c
b/drivers/gpu/drm/amd/display/dc/resource/dcn321/dcn321_resource.c
index 3816678b044f..ea5768f57138 100644
--- a/drivers/gpu/drm/amd/display/dc/resource/dcn321/dcn321_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/resource/dcn321/dcn321_resource.c
@@ -1579,21 +1579,27 @@ static struct dc_cap_funcs cap_funcs = {
static void dcn321_update_bw_bounding_box(struct dc *dc, struct clk_bw_params
*bw_params)
{
- struct dml2_configuration_options dml2_opt = dc->dml2_options;
+ struct dml2_configuration_options *dml2_opt;
+
+ dml2_opt = kmemdup(>dml2_options, sizeof(dc->dml2_options),
GFP_KERNEL);
+ if (!dml2_opt)
+ return;
DC_FP_START();
dcn321_update_bw_bounding_box_fpu(dc, bw_params);
- dml2_opt.use_clock_dc_limits = false;
+ dml2_opt->use_clock_dc_limits = false;
if (dc->debug.using_dml2 && dc->current_state &&
dc->current_state->bw_ctx.dml2)
- dml2_reinit(dc, _opt, >current_state->bw_ctx.dml2);
+ dml2_reinit(dc, dml2_opt, >current_state->bw_ctx.dml2);
- dml2_opt.use_clock_dc_limits = true;
+ dml2_opt->use_clock_dc_limits = true;
if (dc->debug.using_dml2 && dc->current_state &&
dc->current_state->bw_ctx.dml2_dc_power_source)
- dml2_reinit(dc, _opt,
>current_state->bw_ctx.dml2_dc_power_source);
+ dml2_reinit(dc, dml2_opt,
>current_state->bw_ctx.dml2_dc_power_source);
DC_FP_END();
+
+ kfree(dml2_opt);
}
static struct resource_funcs dcn321_res_pool_funcs = {
--
2.39.2
Re: [PATCH v4 13/15] drm/amd/display: Use ARCH_HAS_KERNEL_FPU_SUPPORT
On Thu, Apr 11, 2024, at 09:15, Ard Biesheuvel wrote: > On Thu, 11 Apr 2024 at 03:11, Samuel Holland > wrote: >> On 2024-04-10 8:02 PM, Thiago Jung Bauermann wrote: >> > Samuel Holland writes: >> >> >> The short-term fix would be to drop the `select >> >> ARCH_HAS_KERNEL_FPU_SUPPORT` for >> >> 32-bit arm until we can provide these runtime library functions. >> > >> > Does this mean that patch 2 in this series: >> > >> > [PATCH v4 02/15] ARM: Implement ARCH_HAS_KERNEL_FPU_SUPPORT >> > >> > will be dropped? >> >> No, because later patches in the series (3, 6) depend on the definition of >> CC_FLAGS_FPU from that patch. I will need to send a fixup patch unless I can >> find a GPL-2 compatible implementation of the runtime library functions. >> > > Is there really a point to doing that? Do 32-bit ARM systems even have > enough address space to the map the BARs of the AMD GPUs that need > this support? > > Given that this was not enabled before, I don't think the upshot of > this series should be that we enable support for something on 32-bit > ARM that may cause headaches down the road without any benefit. > > So I'd prefer a fixup patch that opts ARM out of this over adding > support code for 64-bit conversions. I have not found any dts file for a 32-bit platform with support for a 64-bit prefetchable BAR, and there are very few that even have a pcie slot (as opposed on on-board devices) you could plug a card into. That said, I also don't think we should encourage the use of floating-point code in random device drivers. There is really no excuse for the amdgpu driver to use floating point math here, and we should get AMD to fix their driver instead. Arnd
[PATCH 00/12] kbuild: enable some -Wextra warnings by default
From: Arnd Bergmann This is a follow-up on a couple of patch series I sent in the past, enabling -Wextra (aside from stuff that is explicitly disabled), -Wcast-function-pointer-strict and -Wrestrict. I have tested these on 'defconfig' and 'allmodconfig' builds across all architectures, as well as many 'randconfig' builds on x86, arm and arm64. It would be nice to have all the Makefile.extrawarn changes in v6.10, hopefully with the driver fixes going in before that through the respective subsystem trees. Arnd Arnd Bergmann (12): kbuild: make -Woverride-init warnings more consistent [v3] parport: mfc3: avoid empty-body warning kbuild: turn on -Wextra by default kbuild: remove redundant extra warning flags firmware: dmi-id: add a release callback function nouveau: fix function cast warning cxlflash: fix function pointer cast warnings x86: math-emu: fix function cast warnings kbuild: enable -Wcast-function-type-strict unconditionally sata: sx4: fix pdc20621_get_from_dimm() on 64-bit [v4] kallsyms: rework symbol lookup return codes kbuild: turn on -Wrestrict by default arch/x86/math-emu/fpu_etc.c | 9 +++-- arch/x86/math-emu/fpu_trig.c | 6 ++-- arch/x86/math-emu/reg_constant.c | 7 +++- drivers/ata/sata_sx4.c| 6 ++-- drivers/firmware/dmi-id.c | 7 +++- .../gpu/drm/amd/display/dc/dce110/Makefile| 2 +- .../gpu/drm/amd/display/dc/dce112/Makefile| 2 +- .../gpu/drm/amd/display/dc/dce120/Makefile| 2 +- drivers/gpu/drm/amd/display/dc/dce60/Makefile | 2 +- drivers/gpu/drm/amd/display/dc/dce80/Makefile | 2 +- drivers/gpu/drm/i915/Makefile | 6 ++-- .../drm/nouveau/nvkm/subdev/bios/shadowof.c | 7 +++- drivers/gpu/drm/xe/Makefile | 4 +-- drivers/net/ethernet/renesas/sh_eth.c | 2 +- drivers/parport/parport_mfc3.c| 3 +- drivers/pinctrl/aspeed/Makefile | 2 +- drivers/scsi/cxlflash/lunmgt.c| 4 +-- drivers/scsi/cxlflash/main.c | 14 drivers/scsi/cxlflash/superpipe.c | 34 +-- drivers/scsi/cxlflash/superpipe.h | 11 +++--- drivers/scsi/cxlflash/vlun.c | 7 ++-- fs/proc/Makefile | 2 +- include/linux/filter.h| 14 include/linux/ftrace.h| 6 ++-- include/linux/module.h| 14 kernel/bpf/Makefile | 2 +- kernel/bpf/core.c | 7 ++-- kernel/kallsyms.c | 23 +++-- kernel/module/kallsyms.c | 26 +++--- kernel/trace/ftrace.c | 13 +++ mm/Makefile | 3 +- scripts/Makefile.extrawarn| 33 -- 32 files changed, 134 insertions(+), 148 deletions(-) -- 2.39.2 Cc: Bill Metzenthen Cc: Thomas Gleixner Cc: x...@kernel.org Cc: Damien Le Moal Cc: Jean Delvare Cc: Harry Wentland Cc: Jani Nikula Cc: Sergey Shtylyov Cc: Jakub Kicinski Cc: Sudip Mukherjee Cc: Andrew Jeffery Cc: "Manoj N. Kumar" Cc: "Martin K. Petersen" Cc: Alexei Starovoitov Cc: Steven Rostedt Cc: Luis Chamberlain Cc: Andrew Morton Cc: Masahiro Yamada Cc: Nathan Chancellor Cc: Nicolas Schier Cc: Greg Kroah-Hartman Cc: linux-ker...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: amd-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Cc: intel-...@lists.freedesktop.org Cc: nouv...@lists.freedesktop.org Cc: intel...@lists.freedesktop.org Cc: net...@vger.kernel.org Cc: linux-renesas-...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-s...@vger.kernel.org Cc: b...@vger.kernel.org Cc: linux-trace-ker...@vger.kernel.org Cc: linux-modu...@vger.kernel.org Cc: linux...@kvack.org Cc: linux-kbu...@vger.kernel.org Cc: l...@lists.linux.dev
Re: [PATCH 3/3] drm/amd/display: Support DRM_AMD_DC_FP on RISC-V
On Fri, Dec 8, 2023, at 06:04, Samuel Holland wrote:
> On 2023-11-29 6:42 PM, Nathan Chancellor wrote:
>> On Thu, Nov 23, 2023 at 02:23:01PM +, Conor Dooley wrote:
>>> On Tue, Nov 21, 2023 at 07:05:15PM -0800, Samuel Holland wrote:
RISC-V uses kernel_fpu_begin()/kernel_fpu_end() like several other
architectures. Enabling hardware FP requires overriding the ISA string
for the relevant compilation units.
>>>
>>> Ah yes, bringing the joy of frame-larger-than warnings to RISC-V:
>>> ../drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_32.c:58:13:
>>> warning: stack frame size (2416) exceeds limit (2048) in
>>> 'DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerformanceCalculation'
>>> [-Wframe-larger-than]
>>
>> :(
>>
>>> Nathan, have you given up on these being sorted out?
>>
>> Does your configuration have KASAN (I don't think RISC-V supports
>> KCSAN)? It is possible that dml/dcn32 needs something similar to commit
>> 6740ec97bcdb ("drm/amd/display: Increase frame warning limit with KASAN
>> or KCSAN in dml2")?
>>
>> I am not really interested in playing whack-a-mole with these warnings
>> like I have done in the past for the reasons I outlined here:
>>
>> https://lore.kernel.org/20231019205117.GA839902@dev-arch.thelio-3990X/
>
> I also see one of these with clang 17 even with KASAN disabled:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_32.c:37:6:
> warning: stack frame size (2208) exceeds limit (2048) in 'dml32_recalculate'
> [-Wframe-larger-than]
> void dml32_recalculate(struct display_mode_lib *mode_lib)
>
> ^
> 1532/2208 (69.38%) spills, 676/2208 (30.62%) variables
>
> So I'm in favor of just raising the limit for these files for clang, like you
> suggested in the linked thread.
How about just adding a BUG_ON(IS_ENABLED(CONFIG_RISCV))
in that function? That should also avoid the build failure
but give a better indication of where the problem is
if someone actually runs into that function and triggers
a runtime stack overflow.
Arnd
Re: [PATCH 3/3] drm/amd/display: Support DRM_AMD_DC_FP on RISC-V
On Sat, Dec 9, 2023, at 22:29, Samuel Holland wrote: > On 2023-12-09 2:38 PM, Arnd Bergmann wrote: >> On Fri, Dec 8, 2023, at 06:04, Samuel Holland wrote: >>> On 2023-11-29 6:42 PM, Nathan Chancellor wrote: >>>> >>>> https://lore.kernel.org/20231019205117.GA839902@dev-arch.thelio-3990X/ >>> >>> I also see one of these with clang 17 even with KASAN disabled: >>> >>> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_32.c:37:6: >>> warning: stack frame size (2208) exceeds limit (2048) in 'dml32_recalculate' >>> [-Wframe-larger-than] >>> void dml32_recalculate(struct display_mode_lib *mode_lib) >>> >>> ^ >>> 1532/2208 (69.38%) spills, 676/2208 (30.62%) variables >>> >>> So I'm in favor of just raising the limit for these files for clang, like >>> you >>> suggested in the linked thread. >> >> How about just adding a BUG_ON(IS_ENABLED(CONFIG_RISCV)) >> in that function? That should also avoid the build failure >> but give a better indication of where the problem is >> if someone actually runs into that function and triggers >> a runtime stack overflow. > > Won't that break actual users of the driver, trading an unlikely but > theoretically possible stack overflow for a guaranteed crash? The intent of > this > series is that I have one of these GPUs plugged in to a RISC-V board, and I > want > to use it. Ah, I thought you just wanted to get it to compile cleanly so you could use some of the more common cards. If you are trying to run the dcn32 code specifically, then you should definitely fix the stack usage of that function instead. Arnd
[PATCH] drm/amd/display: avoid stringop-overflow warnings for dp_decide_lane_settings()
From: Arnd Bergmann
gcc prints a warning about a possible array overflow for a couple of
callers of dp_decide_lane_settings() after commit 1b56c90018f0 ("Makefile:
Enable -Wstringop-overflow globally"):
drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_training_fixed_vs_pe_retimer.c:
In function 'dp_perform_fixed_vs_pe_training_sequence_legacy':
drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_training_fixed_vs_pe_retimer.c:426:25:
error: 'dp_decide_lane_settings' accessing 4 bytes in a region of size 1
[-Werror=stringop-overflow=]
426 | dp_decide_lane_settings(lt_settings,
dpcd_lane_adjust,
|
^~
427 | lt_settings->hw_lane_settings,
lt_settings->dpcd_lane_settings);
|
~~~
drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_training_fixed_vs_pe_retimer.c:426:25:
note: referencing argument 4 of type 'union dpcd_training_lane[4]'
I'm not entirely sure what caused this, but changing the prototype to expect
a pointer instead of an array avoids the warnings.
Fixes: 7727e7b60f82 ("drm/amd/display: Improve robustness of FIXED_VS link
training at DP1 rates")
Signed-off-by: Arnd Bergmann
---
.../gpu/drm/amd/display/dc/link/protocols/link_dp_training.c| 2 +-
.../gpu/drm/amd/display/dc/link/protocols/link_dp_training.h| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_training.c
b/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_training.c
index 90339c2dfd84..5a0b04518956 100644
--- a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_training.c
+++ b/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_training.c
@@ -807,7 +807,7 @@ void dp_decide_lane_settings(
const struct link_training_settings *lt_settings,
const union lane_adjust ln_adjust[LANE_COUNT_DP_MAX],
struct dc_lane_settings hw_lane_settings[LANE_COUNT_DP_MAX],
- union dpcd_training_lane dpcd_lane_settings[LANE_COUNT_DP_MAX])
+ union dpcd_training_lane *dpcd_lane_settings)
{
uint32_t lane;
diff --git a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_training.h
b/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_training.h
index 7d027bac8255..851bd17317a0 100644
--- a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_training.h
+++ b/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_training.h
@@ -111,7 +111,7 @@ void dp_decide_lane_settings(
const struct link_training_settings *lt_settings,
const union lane_adjust ln_adjust[LANE_COUNT_DP_MAX],
struct dc_lane_settings hw_lane_settings[LANE_COUNT_DP_MAX],
- union dpcd_training_lane dpcd_lane_settings[LANE_COUNT_DP_MAX]);
+ union dpcd_training_lane *dpcd_lane_settings);
enum dc_dp_training_pattern decide_cr_training_pattern(
const struct dc_link_settings *link_settings);
--
2.39.2
Re: [PATCH 2/2] drm/amdkfd: drop struct kfd_cu_info
On Tue, Sep 26, 2023, at 20:47, Deucher, Alexander wrote: >> From: Arnd Bergmann >> Subject: Re: [PATCH 2/2] drm/amdkfd: drop struct kfd_cu_info >> >> On Tue, Sep 26, 2023, at 18:39, Alex Deucher wrote: >> > I think this was an abstraction back from when kfd supported both >> > radeon and amdgpu. Since we just support amdgpu now, there is no more >> > need for this and we can use the amdgpu structures directly. >> > >> > This also avoids having the kfd_cu_info structures on the stack when >> > inlining which can blow up the stack. >> > >> > Cc: Arnd Bergmann >> > Signed-off-by: Alex Deucher >> >> Nice cleanup! >> >> Acked-by: Arnd Bergmann >> >> I guess you could fold patch 1/2 into this as it removes all the added code >> from >> that anyway. > > I left it as a separate patch as I didn't get a chance to see when the > stack warning appeared and figured it might be a good way to mitigate > that on stable kernels if necessary without pulling in the whole > rework, but if not, I can just squash it into the second patch. Makes sense. FWIW, I had never seen the warning before updating to linux-next this week from an older snapshot from last month. My guess is that one of the recent changes made gcc take different inlining decisions so we end up with two copies of the cu_info in the same stack frame, even though the fundamental problem was there already. Arnd
Re: [PATCH 2/2] drm/amdkfd: drop struct kfd_cu_info
On Tue, Sep 26, 2023, at 18:39, Alex Deucher wrote: > I think this was an abstraction back from when > kfd supported both radeon and amdgpu. Since we just > support amdgpu now, there is no more need for this and > we can use the amdgpu structures directly. > > This also avoids having the kfd_cu_info structures on > the stack when inlining which can blow up the stack. > > Cc: Arnd Bergmann > Signed-off-by: Alex Deucher Nice cleanup! Acked-by: Arnd Bergmann I guess you could fold patch 1/2 into this as it removes all the added code from that anyway.
Re: [PATCH 1/2] drm/amdkfd: reduce stack size in kfd_topology_add_device()
On Tue, Sep 26, 2023, at 18:39, Alex Deucher wrote: > kfd_topology.c:2082:1: warning: the frame size of 1440 bytes is larger > than 1024 bytes > > Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2866 > Cc: Arnd Bergmann > Signed-off-by: Alex Deucher Acked-by: Arnd Bergmann
[PATCH] drm/amdkfd: fix build failure without CONFIG_DYNAMIC_DEBUG
From: Arnd Bergmann
When CONFIG_DYNAMIC_DEBUG is disabled altogether, calling
_dynamic_func_call_no_desc() does not work:
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c: In function
'svm_range_set_attr':
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c:52:9: error: implicit
declaration of function '_dynamic_func_call_no_desc'
[-Werror=implicit-function-declaration]
52 | _dynamic_func_call_no_desc("svm_range_dump",
svm_range_debug_dump, svms)
| ^~
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c:3564:9: note: in expansion of
macro 'dynamic_svm_range_dump'
3564 | dynamic_svm_range_dump(svms);
| ^~
Add a compile-time conditional in addition to the runtime check.
Fixes: 8923137dbe4b2 ("drm/amdkfd: avoid svm dump when dynamic debug disabled")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
index 308384dbc502d..44e710821b6d9 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
@@ -23,6 +23,7 @@
#include
#include
+#include
#include
#include
@@ -48,8 +49,13 @@
* page table is updated.
*/
#define AMDGPU_SVM_RANGE_RETRY_FAULT_PENDING (2UL * NSEC_PER_MSEC)
+#if IS_ENABLED(CONFIG_DYNAMIC_DEBUG)
#define dynamic_svm_range_dump(svms) \
_dynamic_func_call_no_desc("svm_range_dump", svm_range_debug_dump, svms)
+#else
+#define dynamic_svm_range_dump(svms) \
+ do { if (0) svm_range_debug_dump(svms); } while (0)
+#endif
/* Giant svm range split into smaller ranges based on this, it is decided using
* minimum of all dGPU/APU 1/32 VRAM size, between 2MB to 1GB and alignment to
--
2.39.2
[PATCH] [v2] drm/amdgpu: avoid integer overflow warning in amdgpu_device_resize_fb_bar()
From: Arnd Bergmann
On 32-bit architectures comparing a resource against a value larger than
U32_MAX can cause a warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1344:18: error: result of comparison
of constant 4294967296 with expression of type 'resource_size_t' (aka 'unsigned
int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
res->start > 0x1ull)
~~ ^ ~~
As gcc does not warn about this in dead code, add an IS_ENABLED() check at
the start of the function. This will always return success but not actually
resize
the BAR on 32-bit architectures without high memory, which is exactly what
we want here, as the driver can fall back to bank switching the VRAM
access.
Fixes: 31b8adab3247e ("drm/amdgpu: require a root bus window above 4GB for BAR
resize")
Signed-off-by: Arnd Bergmann
---
v2: return early instead of shutting up the warning with a cast and
running into a failure
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 7f069e1731fee..fcf5f07c47751 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1325,6 +1325,9 @@ int amdgpu_device_resize_fb_bar(struct amdgpu_device
*adev)
u16 cmd;
int r;
+ if (!IS_ENABLED(CONFIG_PHYS_ADDR_T_64BIT))
+ return 0;
+
/* Bypass for VF */
if (amdgpu_sriov_vf(adev))
return 0;
--
2.39.2
Re: [PATCH] drm/amdgpu: avoid integer overflow warning in amdgpu_device_resize_fb_bar()
On Tue, Jul 4, 2023, at 14:33, Christian König wrote: > Am 04.07.23 um 14:24 schrieb Arnd Bergmann: >> On Tue, Jul 4, 2023, at 08:54, Christian König wrote: >>> Am 03.07.23 um 14:35 schrieb Arnd Bergmann: >> Not sure I understand the specific requirement. Do you mean the entire >> amdgpu driver requires 64-bit BAR addressing, or just the bits that >> resize the BARs? > > Well a bit of both. > > Modern AMD GPUs have 16GiB of local memory (VRAM), making those > accessible to a CPU which can only handle 32bit addresses by resizing > the BAR is impossible to begin with. > > But going a step further even without resizing it is pretty hard to get > that hardware working on such an architecture. I'd still like to understand this part better, as we have a lot of arm64 chips with somewhat flawed PCIe implementations, often with a tiny 64-bit memory space, but otherwise probably capable of using a GPU. What exactly do you expect to happen here? a) Use only part of the VRAM but otherwise work as expected b) Access all of the VRAM, but at a performance cost for bank switching? c) Require kernel changes to make a) or b) work, otherwise fail to load d) have no chance of working even with driver changes >>> It might be cleaner to just not build the whole driver on such systems >>> or at least leave out this function. >> How about this version? This also addresses the build failure, but >> I don't know if this makes any sense: >> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c >> @@ -1325,6 +1325,9 @@ int amdgpu_device_resize_fb_bar(struct amdgpu_device >> *adev) >> u16 cmd; >> int r; >> >> + if (!IS_ENABLED(CONFIG_PHYS_ADDR_T_64BIT)) >> + return 0; >> + > > Yes, if that suppresses the warning as well then that makes perfect > sense to me. Ok, I'll send that as a v2 then. Arnd
Re: [PATCH] drm/amdgpu: avoid integer overflow warning in amdgpu_device_resize_fb_bar()
On Tue, Jul 4, 2023, at 16:51, Christian König wrote: > Am 04.07.23 um 16:31 schrieb Arnd Bergmann: >> On Tue, Jul 4, 2023, at 14:33, Christian König wrote: >>> >>> Modern AMD GPUs have 16GiB of local memory (VRAM), making those >>> accessible to a CPU which can only handle 32bit addresses by resizing >>> the BAR is impossible to begin with. >>> >>> But going a step further even without resizing it is pretty hard to get >>> that hardware working on such an architecture. >> I'd still like to understand this part better, as we have a lot of >> arm64 chips with somewhat flawed PCIe implementations, often with >> a tiny 64-bit memory space, but otherwise probably capable of >> using a GPU. > > Yeah, those are unfortunately very well known to us :( > >> What exactly do you expect to happen here? >> >> a) Use only part of the VRAM but otherwise work as expected >> b) Access all of the VRAM, but at a performance cost for >> bank switching? > > We have tons of x86 systems where we can't resize the BAR (because of > lack of BIOS setup of the root PCIe windows). So bank switching is still > perfectly supported. Ok, good. > After investigating (which sometimes even includes involving engineers > from ARM) we usually find that those boards doesn't even remotely comply > to the PCIe specification, both regarding power as well as functional > things like DMA coherency. Makes sense, the power usage is clearly going to make this impossible on a lot of boards. I would have expected noncoherent DMA to be a solvable problem, since that generally works with all drivers that use the dma-mapping interfaces correctly, but I understand that drivers/gpu/* often does its own thing here, which may make that harder. Arnd
Re: [PATCH] drm/amdgpu: avoid integer overflow warning in amdgpu_device_resize_fb_bar()
On Tue, Jul 4, 2023, at 08:54, Christian König wrote: > Am 03.07.23 um 14:35 schrieb Arnd Bergmann: >> From: Arnd Bergmann >> >> On 32-bit architectures comparing a resource against a value larger than >> U32_MAX can cause a warning: >> >> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1344:18: error: result of >> comparison of constant 4294967296 with expression of type 'resource_size_t' >> (aka 'unsigned int') is always false >> [-Werror,-Wtautological-constant-out-of-range-compare] >> res->start > 0x1ull) >> ~~ ^ ~~ >> >> The compiler is right that this cannot happen in this configuration, which >> is ok, so just add a cast to shut up the warning. > > Well it doesn't make sense to compile that driver on systems with only > 32bit phys_addr_t in the first place. Not sure I understand the specific requirement. Do you mean the entire amdgpu driver requires 64-bit BAR addressing, or just the bits that resize the BARs? > It might be cleaner to just not build the whole driver on such systems > or at least leave out this function. How about this version? This also addresses the build failure, but I don't know if this makes any sense: --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -1325,6 +1325,9 @@ int amdgpu_device_resize_fb_bar(struct amdgpu_device *adev) u16 cmd; int r; + if (!IS_ENABLED(CONFIG_PHYS_ADDR_T_64BIT)) + return 0; + /* Bypass for VF */ if (amdgpu_sriov_vf(adev)) return 0; Arnd
[PATCH] drm/amdgpu: avoid integer overflow warning in amdgpu_device_resize_fb_bar()
From: Arnd Bergmann
On 32-bit architectures comparing a resource against a value larger than
U32_MAX can cause a warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1344:18: error: result of comparison
of constant 4294967296 with expression of type 'resource_size_t' (aka 'unsigned
int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
res->start > 0x1ull)
~~ ^ ~~
The compiler is right that this cannot happen in this configuration, which
is ok, so just add a cast to shut up the warning.
Fixes: 31b8adab3247e ("drm/amdgpu: require a root bus window above 4GB for BAR
resize")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 7f069e1731fee..abd13942aac5d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1341,7 +1341,7 @@ int amdgpu_device_resize_fb_bar(struct amdgpu_device
*adev)
pci_bus_for_each_resource(root, res, i) {
if (res && res->flags & (IORESOURCE_MEM | IORESOURCE_MEM_64) &&
- res->start > 0x1ull)
+ (u64)res->start > 0x1ull)
break;
}
--
2.39.2
[PATCH] drm/amdgpu: fix building without DEBUG_FS
From: Arnd Bergmann
The debugfs file is defined unconditionally, but the registration is hidden
in an #ifdef, which causes a warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_rap.c:110:37: error: unused variable
'amdgpu_rap_debugfs_ops' [-Werror,-Wunused-const-variable]
static const struct file_operations amdgpu_rap_debugfs_ops = {
^
in amdgpu_pm.c, the same thing happens with the clocks[] variable:
drivers/gpu/drm/amd/pm/amdgpu_pm.c:38:34: error: unused variable 'clocks'
[-Werror,-Wunused-const-variable]
static const struct cg_flag_name clocks[] = {
^
Since debugfs_create_file() does nothing when debugfs is disabled, removing
the ifdefs makes the code more readable and also avoids both warnings.
Fixes: a4322e1881bed ("drm/amdgpu: add debugfs interface for RAP test")
Fixes: e098bc9612c2b ("drm/amd/pm: optimize the power related source code
layout")
Reported-by: kernel test robot
Link: https://lore.kernel.org/oe-kbuild-all/202302200339.whql7emr-...@intel.com/
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_rap.c | 2 --
drivers/gpu/drm/amd/pm/amdgpu_pm.c | 6 --
2 files changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_rap.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_rap.c
index 12010c988c8b5..123bcf5c2bb13 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_rap.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_rap.c
@@ -116,7 +116,6 @@ static const struct file_operations amdgpu_rap_debugfs_ops
= {
void amdgpu_rap_debugfs_init(struct amdgpu_device *adev)
{
-#if defined(CONFIG_DEBUG_FS)
struct drm_minor *minor = adev_to_drm(adev)->primary;
if (!adev->psp.rap_context.context.initialized)
@@ -124,5 +123,4 @@ void amdgpu_rap_debugfs_init(struct amdgpu_device *adev)
debugfs_create_file("rap_test", S_IWUSR, minor->debugfs_root,
adev, _rap_debugfs_ops);
-#endif
}
diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
index a57952b93e73f..ec39805b762e6 100644
--- a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
@@ -3565,8 +3565,6 @@ void amdgpu_pm_sysfs_fini(struct amdgpu_device *adev)
/*
* Debugfs info
*/
-#if defined(CONFIG_DEBUG_FS)
-
static void amdgpu_debugfs_prints_cpu_info(struct seq_file *m,
struct amdgpu_device *adev) {
uint16_t *p_val;
@@ -3768,11 +3766,8 @@ static const struct file_operations
amdgpu_debugfs_pm_prv_buffer_fops = {
.llseek = default_llseek,
};
-#endif
-
void amdgpu_debugfs_pm_init(struct amdgpu_device *adev)
{
-#if defined(CONFIG_DEBUG_FS)
struct drm_minor *minor = adev_to_drm(adev)->primary;
struct dentry *root = minor->debugfs_root;
@@ -3789,5 +3784,4 @@ void amdgpu_debugfs_pm_init(struct amdgpu_device *adev)
adev->pm.smu_prv_buffer_size);
amdgpu_dpm_stb_debug_fs_init(adev);
-#endif
}
--
2.39.2
[PATCH] drm/amdkfd: mark som eclear_address_watch() callback static
From: Arnd Bergmann
Some of the newly introduced clear_address_watch callback handlers have
no prototype because they are only used in one file, which causes a W=1
warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c:164:10: error: no previous
prototype for 'kgd_gfx_aldebaran_clear_address_watch'
[-Werror=missing-prototypes]
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v11.c:782:10: error: no previous
prototype for 'kgd_gfx_v11_clear_address_watch' [-Werror=missing-prototypes]
Mark these ones static. If another user comes up in the future, that
can be reverted along with adding the prototype.
Fixes: cfd9715f741a1 ("drm/amdkfd: add debug set and clear address watch points
operation")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v11.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c
index efd6a72aab4eb..bdda8744398fe 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c
@@ -161,7 +161,7 @@ static uint32_t kgd_gfx_aldebaran_set_address_watch(
return watch_address_cntl;
}
-uint32_t kgd_gfx_aldebaran_clear_address_watch(struct amdgpu_device *adev,
+static uint32_t kgd_gfx_aldebaran_clear_address_watch(struct amdgpu_device
*adev,
uint32_t watch_id)
{
return 0;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v11.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v11.c
index 52efa690a3c21..131859ce3e7e9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v11.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v11.c
@@ -779,7 +779,7 @@ static uint32_t kgd_gfx_v11_set_address_watch(struct
amdgpu_device *adev,
return watch_address_cntl;
}
-uint32_t kgd_gfx_v11_clear_address_watch(struct amdgpu_device *adev,
+static uint32_t kgd_gfx_v11_clear_address_watch(struct amdgpu_device *adev,
uint32_t watch_id)
{
return 0;
--
2.39.2
[PATCH] drm/amd/display: avoid calling missing .resync_fifo_dccg_dio()
From: Arnd Bergmann
The .resync_fifo_dccg_dio() callback pointer was added in an #ifdef block,
but is called unconditionally:
drivers/gpu/drm/amd/amdgpu/../display/dc/dce110/dce110_hw_sequencer.c:2292:31:
error: 'struct hwseq_private_funcs' has no member named 'resync_fifo_dccg_dio'
Add the same #ifdef around the caller as well.
Fixes: 6354b0dc3a7a ("drm/amd/display: Trigger DIO FIFO resync on commit
streams")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
b/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
index c6fe2c00aedb..d4cacb8df631 100644
--- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
@@ -2289,8 +2289,10 @@ enum dc_status dce110_apply_ctx_to_hw(
if (DC_OK != status)
return status;
+#ifdef CONFIG_DRM_AMD_DC_FP
if (hws->funcs.resync_fifo_dccg_dio)
hws->funcs.resync_fifo_dccg_dio(hws, dc, context);
+#endif
}
if (dc->fbc_compressor)
--
2.39.2
[PATCH 5/5] drm/amdgpu: fix acpi build warnings
From: Arnd Bergmann
Two newly introduced functions are in the global namespace but have no
prototypes
or callers outside of amdgpu_acpi.c, another function is static but only has
a caller inside of an #ifdef:
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:902:13: error: no previous prototype
for 'amdgpu_acpi_get_node_id' [-Werror=missing-prototypes]
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:928:30: error: no previous prototype
for 'amdgpu_acpi_get_dev' [-Werror=missing-prototypes]
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:860:33: error:
'amdgpu_acpi_get_numa_info' defined but not used [-Werror=unused-function]
Avoid the warnings by marking all of them static and ensuring that the compiler
is
able to see the callsites.
Fixes: c34db97b8217 ("drm/amdgpu: Add API to get numa information of XCC")
Fixes: 1f6f659d06e1 ("drm/amdgpu: Store additional numa node information")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
index 873532c4adbe..1dbcd0e62478 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
@@ -899,13 +899,15 @@ static struct amdgpu_numa_info
*amdgpu_acpi_get_numa_info(uint32_t pxm)
*
* Returns ACPI STATUS OK with Node ID on success or the corresponding failure
reason
*/
-acpi_status amdgpu_acpi_get_node_id(acpi_handle handle,
+static acpi_status amdgpu_acpi_get_node_id(acpi_handle handle,
struct amdgpu_numa_info **numa_info)
{
-#ifdef CONFIG_ACPI_NUMA
u64 pxm;
acpi_status status;
+ if (!IS_ENABLED(CONFIG_ACPI_NUMA))
+ return_ACPI_STATUS(AE_NOT_EXIST);
+
if (!numa_info)
return_ACPI_STATUS(AE_ERROR);
@@ -920,12 +922,9 @@ acpi_status amdgpu_acpi_get_node_id(acpi_handle handle,
return_ACPI_STATUS(AE_ERROR);
return_ACPI_STATUS(AE_OK);
-#else
- return_ACPI_STATUS(AE_NOT_EXIST);
-#endif
}
-struct amdgpu_acpi_dev_info *amdgpu_acpi_get_dev(u16 bdf)
+static struct amdgpu_acpi_dev_info *amdgpu_acpi_get_dev(u16 bdf)
{
struct amdgpu_acpi_dev_info *acpi_dev;
--
2.39.2
[PATCH 4/5] drm/amdgpu: use %pad format string for dma_addr_t
From: Arnd Bergmann
DMA addresses can be shorter than u64, which results in a broken debug output:
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c: In function
'amdgpu_gart_table_ram_alloc':
drivers/gpu/drm/amd/amdgpu/amdgpu.h:41:22: error: format '%llx' expects
argument of type 'long long unsigned int', but argument 4 has type 'dma_addr_t'
{aka 'unsigned int'} [-Werror=format=]
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c:146:9: note: in expansion of macro
'dev_info'
146 | dev_info(adev->dev, "%s dma_addr:%llx\n", __func__, dma_addr);
Use the special %pad format string and pass the DMA address by reference.
Fixes: d020a29b6b58 ("drm/amdgpu: Allocate GART table in RAM for AMD APU")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
index a070adf30c88..73b8cca35bab 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
@@ -143,7 +143,7 @@ int amdgpu_gart_table_ram_alloc(struct amdgpu_device *adev)
return -EFAULT;
}
- dev_info(adev->dev, "%s dma_addr:%llx\n", __func__, dma_addr);
+ dev_info(adev->dev, "%s dma_addr:%pad\n", __func__, _addr);
/* Create SG table */
sg = kmalloc(sizeof(*sg), GFP_KERNEL);
if (!sg) {
--
2.39.2
[PATCH 3/5] drm/amdgpu:mark aqua_vanjaram_reg_init.c function as static
From: Arnd Bergmann
A few newly added global functions have no prototype, which causes warnings:
drivers/gpu/drm/amd/amdgpu/aqua_vanjaram_reg_init.c:169:5: error: no previous
prototype for 'aqua_vanjaram_select_scheds' [-Werror=missing-prototypes]
drivers/gpu/drm/amd/amdgpu/aqua_vanjaram_reg_init.c:310:5: error: no previous
prototype for '__aqua_vanjaram_get_xcc_per_xcp' [-Werror=missing-prototypes]
drivers/gpu/drm/amd/amdgpu/aqua_vanjaram_reg_init.c:337:5: error: no previous
prototype for '__aqua_vanjaram_get_xcp_ip_info' [-Werror=missing-prototypes]
drivers/gpu/drm/amd/amdgpu/aqua_vanjaram_reg_init.c:593:5: error: no previous
prototype for 'aqua_vanjaram_get_xcp_ip_details' [-Werror=missing-prototypes]
There are no callers from other files, so just mark them as 'static'.
Fixes: 5f9f80485953 ("drm/amdgpu: add partition schedule for GC(9, 4, 3)")
Fixes: 27614f589fc0 ("drm/amdgpu: Add SOC partition funcs for GC v9.4.3")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/amdgpu/aqua_vanjaram_reg_init.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/aqua_vanjaram_reg_init.c
b/drivers/gpu/drm/amd/amdgpu/aqua_vanjaram_reg_init.c
index 68d1a0fc5f5d..a595bb958215 100644
--- a/drivers/gpu/drm/amd/amdgpu/aqua_vanjaram_reg_init.c
+++ b/drivers/gpu/drm/amd/amdgpu/aqua_vanjaram_reg_init.c
@@ -166,7 +166,7 @@ static int aqua_vanjaram_update_partition_sched_list(struct
amdgpu_device *adev)
return aqua_vanjaram_xcp_sched_list_update(adev);
}
-int aqua_vanjaram_select_scheds(
+static int aqua_vanjaram_select_scheds(
struct amdgpu_device *adev,
u32 hw_ip,
u32 hw_prio,
@@ -307,7 +307,7 @@ static int aqua_vanjaram_query_partition_mode(struct
amdgpu_xcp_mgr *xcp_mgr)
return mode;
}
-int __aqua_vanjaram_get_xcc_per_xcp(struct amdgpu_xcp_mgr *xcp_mgr, int mode)
+static int __aqua_vanjaram_get_xcc_per_xcp(struct amdgpu_xcp_mgr *xcp_mgr, int
mode)
{
int num_xcc, num_xcc_per_xcp = 0;
@@ -334,7 +334,7 @@ int __aqua_vanjaram_get_xcc_per_xcp(struct amdgpu_xcp_mgr
*xcp_mgr, int mode)
return num_xcc_per_xcp;
}
-int __aqua_vanjaram_get_xcp_ip_info(struct amdgpu_xcp_mgr *xcp_mgr, int xcp_id,
+static int __aqua_vanjaram_get_xcp_ip_info(struct amdgpu_xcp_mgr *xcp_mgr, int
xcp_id,
enum AMDGPU_XCP_IP_BLOCK ip_id,
struct amdgpu_xcp_ip *ip)
{
@@ -590,7 +590,7 @@ static int aqua_vanjaram_get_xcp_mem_id(struct
amdgpu_xcp_mgr *xcp_mgr,
return r;
}
-int aqua_vanjaram_get_xcp_ip_details(struct amdgpu_xcp_mgr *xcp_mgr, int
xcp_id,
+static int aqua_vanjaram_get_xcp_ip_details(struct amdgpu_xcp_mgr *xcp_mgr,
int xcp_id,
enum AMDGPU_XCP_IP_BLOCK ip_id,
struct amdgpu_xcp_ip *ip)
{
--
2.39.2
[PATCH 2/5] drm/amdkfd: mark local functions as static
From: Arnd Bergmann
The file was newly added and causes some -Wmissing-prototype warnings:
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gc_9_4_3.c:57:5: error: no previous
prototype for 'kgd_gfx_v9_4_3_hqd_sdma_load' [-Werror=missing-prototypes]
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gc_9_4_3.c:126:5: error: no previous
prototype for 'kgd_gfx_v9_4_3_hqd_sdma_dump' [-Werror=missing-prototypes]
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gc_9_4_3.c:163:6: error: no previous
prototype for 'kgd_gfx_v9_4_3_hqd_sdma_is_occupied' [-Werror=missing-prototypes]
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gc_9_4_3.c:181:5: error: no previous
prototype for 'kgd_gfx_v9_4_3_hqd_sdma_destroy' [-Werror=missing-prototypes]
Mark these all as 'static' since there are no outside callers.
Fixes: 09a95a85cf3e ("drm/amdkfd: Update SDMA queue management for GFX9.4.3")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gc_9_4_3.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gc_9_4_3.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gc_9_4_3.c
index 81dfbe39fd8e..5b4b7f8b92a5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gc_9_4_3.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gc_9_4_3.c
@@ -54,7 +54,7 @@ static uint32_t get_sdma_rlc_reg_offset(struct amdgpu_device
*adev,
return retval;
}
-int kgd_gfx_v9_4_3_hqd_sdma_load(struct amdgpu_device *adev, void *mqd,
+static int kgd_gfx_v9_4_3_hqd_sdma_load(struct amdgpu_device *adev, void *mqd,
uint32_t __user *wptr, struct mm_struct *mm)
{
struct v9_sdma_mqd *m;
@@ -123,7 +123,7 @@ int kgd_gfx_v9_4_3_hqd_sdma_load(struct amdgpu_device
*adev, void *mqd,
return 0;
}
-int kgd_gfx_v9_4_3_hqd_sdma_dump(struct amdgpu_device *adev,
+static int kgd_gfx_v9_4_3_hqd_sdma_dump(struct amdgpu_device *adev,
uint32_t engine_id, uint32_t queue_id,
uint32_t (**dump)[2], uint32_t *n_regs)
{
@@ -160,7 +160,7 @@ int kgd_gfx_v9_4_3_hqd_sdma_dump(struct amdgpu_device *adev,
return 0;
}
-bool kgd_gfx_v9_4_3_hqd_sdma_is_occupied(struct amdgpu_device *adev, void *mqd)
+static bool kgd_gfx_v9_4_3_hqd_sdma_is_occupied(struct amdgpu_device *adev,
void *mqd)
{
struct v9_sdma_mqd *m;
uint32_t sdma_rlc_reg_offset;
@@ -178,7 +178,7 @@ bool kgd_gfx_v9_4_3_hqd_sdma_is_occupied(struct
amdgpu_device *adev, void *mqd)
return false;
}
-int kgd_gfx_v9_4_3_hqd_sdma_destroy(struct amdgpu_device *adev, void *mqd,
+static int kgd_gfx_v9_4_3_hqd_sdma_destroy(struct amdgpu_device *adev, void
*mqd,
unsigned int utimeout)
{
struct v9_sdma_mqd *m;
--
2.39.2
[PATCH 1/5] drm/amd/pm: mark irq functions as 'static'
From: Arnd Bergmann
Two newly added functions cause a warning because they lack a prototype:
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu13/smu_v13_0_6_ppt.c:1328:5: error:
no previous prototype for 'smu_v13_0_6_set_irq_state'
[-Werror=missing-prototypes]
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu13/smu_v13_0_6_ppt.c:1368:5: error:
no previous prototype for 'smu_v13_0_6_register_irq_handler'
[-Werror=missing-prototypes]
They are only used locally, so just mark them static.
Fixes: 48b5659cf086 ("drm/amd/pm: Add ih for SMU v13.0.6 thermal throttling")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c
index a712b2bf2d25..41b49cc827cd 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c
@@ -1325,7 +1325,7 @@ static int smu_v13_0_6_irq_process(struct amdgpu_device
*adev,
return 0;
}
-int smu_v13_0_6_set_irq_state(struct amdgpu_device *adev,
+static int smu_v13_0_6_set_irq_state(struct amdgpu_device *adev,
struct amdgpu_irq_src *source,
unsigned tyep,
enum amdgpu_interrupt_state state)
@@ -1365,7 +1365,7 @@ static const struct amdgpu_irq_src_funcs
smu_v13_0_6_irq_funcs =
.process = smu_v13_0_6_irq_process,
};
-int smu_v13_0_6_register_irq_handler(struct smu_context *smu)
+static int smu_v13_0_6_register_irq_handler(struct smu_context *smu)
{
struct amdgpu_device *adev = smu->adev;
struct amdgpu_irq_src *irq_src = >irq_source;
--
2.39.2
[PATCH] drm/amd/display: mark amdgpu_dm_connector_funcs_force static
From: Arnd Bergmann
A global function without a header prototype has made it into
linux-next during the merge window:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:6339:6: error: no
previous prototype for 'amdgpu_dm_connector_funcs_force'
[-Werror=missing-prototypes]
Mark the function static instead, as there are no other
callers outside this file.
Fixes: 0ba4a784a145 ("drm/amd/display: implement force function in
amdgpu_dm_connector_funcs")
Reported-by: kernel test robot
Link: https://lore.kernel.org/oe-kbuild-all/202304251640.jclqtim9-...@intel.com/
Signed-off-by: Arnd Bergmann
---
This was previously reported by a bot for the drm-next tree but remains
broken in linux-next-20230428. Sending it out as I needed this fix
for my local builds.
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
1 file changed, 1 insertion(+), 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 3647d21d688f..2bbb2988942d 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6336,7 +6336,7 @@ amdgpu_dm_connector_late_register(struct drm_connector
*connector)
return 0;
}
-void amdgpu_dm_connector_funcs_force(struct drm_connector *connector)
+static void amdgpu_dm_connector_funcs_force(struct drm_connector *connector)
{
struct amdgpu_dm_connector *aconnector =
to_amdgpu_dm_connector(connector);
struct dc_link *dc_link = aconnector->dc_link;
--
2.39.2
[PATCH 3/3] drm/amd/display: remove unused variables in dcn21_set_backlight_level
From: Arnd Bergmann
The only references to these variables were removed, so they now cause
warnings and have to be removed as well:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_hwseq.c:226:20: error:
unused variable 'cmd' [-Werror,-Wunused-variable]
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_hwseq.c:229:11: error:
unused variable 'otg_inst' [-Werror,-Wunused-variable]
Fixes: 6f0ef80a00ad ("drm/amd/display: Fix ABM pipe/backlight issues when
change backlight")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c
b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c
index 55a464a39529..43463d08f21b 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c
@@ -223,10 +223,8 @@ bool dcn21_set_backlight_level(struct pipe_ctx *pipe_ctx,
uint32_t backlight_pwm_u16_16,
uint32_t frame_ramp)
{
- union dmub_rb_cmd cmd;
struct dc_context *dc = pipe_ctx->stream->ctx;
struct abm *abm = pipe_ctx->stream_res.abm;
- uint32_t otg_inst = pipe_ctx->stream_res.tg->inst;
struct panel_cntl *panel_cntl = pipe_ctx->stream->link->panel_cntl;
if (dc->dc->res_pool->dmcu) {
--
2.39.2
[PATCH 2/3] drm/amd/display: dumb_abm_lcd: avoid missing-prototype warnings
From: Arnd Bergmann
The dmub_abm_set_ambient_level() function has no caller and can
just be removed, the other ones have a declaration in the
header file and just need to see the prototype:
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:122:14: error: no
previous prototype for function 'dmub_abm_get_current_backlight'
[-Werror,-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:133:14: error: no
previous prototype for function 'dmub_abm_get_target_backlight'
[-Werror,-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:144:6: error: no
previous prototype for function 'dmub_abm_set_level'
[-Werror,-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:163:6: error: no
previous prototype for function 'dmub_abm_set_ambient_level'
[-Werror,-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:183:6: error: no
previous prototype for function 'dmub_abm_init_config'
[-Werror,-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:213:6: error: no
previous prototype for function 'dmub_abm_set_pause'
[-Werror,-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:231:6: error: no
previous prototype for function 'dmub_abm_set_pipe'
[-Werror,-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:251:6: error: no
previous prototype for function 'dmub_abm_set_backlight_level'
[-Werror,-Wmissing-prototypes]
Fixes: b8fe56375f78 ("drm/amd/display: Refactor ABM feature")
Signed-off-by: Arnd Bergmann
---
.../gpu/drm/amd/display/dc/dce/dmub_abm_lcd.c | 22 +--
1 file changed, 1 insertion(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dmub_abm_lcd.c
b/drivers/gpu/drm/amd/display/dc/dce/dmub_abm_lcd.c
index e152c68edfd1..39da73eba86e 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dmub_abm_lcd.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dmub_abm_lcd.c
@@ -24,6 +24,7 @@
*/
#include "dmub_abm.h"
+#include "dmub_abm_lcd.h"
#include "dce_abm.h"
#include "dc.h"
#include "dc_dmub_srv.h"
@@ -159,27 +160,6 @@ bool dmub_abm_set_level(struct abm *abm, uint32_t level,
uint8_t panel_mask)
return true;
}
-#ifndef TRIM_AMBIENT_GAMMA
-void dmub_abm_set_ambient_level(struct abm *abm, unsigned int ambient_lux,
uint8_t panel_mask)
-{
- union dmub_rb_cmd cmd;
- struct dc_context *dc = abm->ctx;
-
- if (ambient_lux > 0x)
- ambient_lux = 0x;
-
- memset(, 0, sizeof(cmd));
- cmd.abm_set_ambient_level.header.type = DMUB_CMD__ABM;
- cmd.abm_set_ambient_level.header.sub_type =
DMUB_CMD__ABM_SET_AMBIENT_LEVEL;
- cmd.abm_set_ambient_level.abm_set_ambient_level_data.ambient_lux =
ambient_lux;
- cmd.abm_set_ambient_level.abm_set_ambient_level_data.version =
DMUB_CMD_ABM_CONTROL_VERSION_1;
- cmd.abm_set_ambient_level.abm_set_ambient_level_data.panel_mask =
panel_mask;
- cmd.abm_set_ambient_level.header.payload_bytes = sizeof(struct
dmub_cmd_abm_set_ambient_level_data);
-
- dm_execute_dmub_cmd(dc, , DM_DMUB_WAIT_TYPE_WAIT);
-}
-#endif
-
void dmub_abm_init_config(struct abm *abm,
const char *src,
unsigned int bytes,
--
2.39.2
[PATCH 1/3] drm/amdgpu: mark gfx_v9_4_3_disable_gpa_mode() static
From: Arnd Bergmann
This was left global by accident, the corresponding functions for other
hardware types are already static:
drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:1072:6: error: no previous prototype
for function 'gfx_v9_4_3_disable_gpa_mode' [-Werror,-Wmissing-prototypes]
Fixes: 86301129698b ("drm/amdgpu: split gc v9_4_3 functionality from gc v9_0")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c
index baa10ee8ec69..5d3aafba1f8e 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c
@@ -1069,7 +1069,7 @@ static void gfx_v9_4_3_init_pg(struct amdgpu_device
*adev, int xcc_id)
}
}
-void gfx_v9_4_3_disable_gpa_mode(struct amdgpu_device *adev, int xcc_id)
+static void gfx_v9_4_3_disable_gpa_mode(struct amdgpu_device *adev, int xcc_id)
{
uint32_t data;
--
2.39.2
Re: [PATCH 2/2] drm/amd/display: fix missing=prototypes warnings
On Mon, Apr 17, 2023, at 23:17, Hamza Mahfooz wrote:
> On 4/17/23 17:05, Arnd Bergmann wrote:
>> From: Arnd Bergmann
>>
>> Three functions in the amdgpu display driver cause -Wmissing-prototype
>> warnings:
>>
>> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1858:6: error:
>> no previous prototype for 'is_timing_changed' [-Werror=missing-prototypes]
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:210:6:
>> error: no previous prototype for 'is_synaptics_cascaded_panamera'
>> [-Werror=missing-prototypes]
>> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_optc.c:294:6: error: no
>> previous prototype for 'optc3_wait_drr_doublebuffer_pending_clear'
>> [-Werror=missing-prototypes]
>>
>> is_timing_changed() is actually meant to be a global symbol, but needs
>> a proper name and prototype, while the other two can just be made static.
>>
>> Fixes: 54c7b715b5ef ("drm/amd/display: Add DSC Support for Synaptics
>> Cascaded MST Hub")
>> Fixes: 17ce8a6907f7 ("drm/amd/display: Add dsc pre-validation in atomic
>> check")
>> Fixes: 8f0d304d21b3 ("drm/amd/display: Do not commit pipe when updating DRR")
>> Signed-off-by: Arnd Bergmann
>
> It seems like, only the changes for is_timing_changed() are in this patch.
Indeed. I made this patch a few weeks ago, and it looks like the other
two were fixed in the same way that I had in the meantime, so the other
changes got silently dropped during a rebase. I've updated the changelog
text and sent a v2 now.
Arnd
[PATCH] [v2] drm/amd/display: fix is_timing_changed() prototype
From: Arnd Bergmann
Three functions in the amdgpu display driver cause -Wmissing-prototype
warnings:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1858:6: error: no
previous prototype for 'is_timing_changed' [-Werror=missing-prototypes]
is_timing_changed() is actually meant to be a global symbol, but needs
a proper name and prototype.
Fixes: 17ce8a6907f7 ("drm/amd/display: Add dsc pre-validation in atomic check")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 5 ++---
drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 6 +++---
drivers/gpu/drm/amd/display/dc/dc.h | 3 +++
3 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 994ba426ca66..442511061178 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -45,8 +45,7 @@
#endif
#include "dc/dcn20/dcn20_resource.h"
-bool is_timing_changed(struct dc_stream_state *cur_stream,
- struct dc_stream_state *new_stream);
+
#define PEAK_FACTOR_X1000 1006
static ssize_t dm_dp_aux_transfer(struct drm_dp_aux *aux,
@@ -1417,7 +1416,7 @@ int pre_validate_dsc(struct drm_atomic_state *state,
struct dc_stream_state *stream = dm_state->context->streams[i];
if (local_dc_state->streams[i] &&
- is_timing_changed(stream, local_dc_state->streams[i])) {
+ dc_is_timing_changed(stream, local_dc_state->streams[i])) {
DRM_INFO_ONCE("crtc[%d] needs mode_changed\n", i);
} else {
int ind = find_crtc_index_in_state_by_stream(state,
stream);
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
index 85d54bfb595c..344533623cb9 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
@@ -1855,7 +1855,7 @@ bool dc_add_all_planes_for_stream(
return add_all_planes_for_stream(dc, stream, , 1, context);
}
-bool is_timing_changed(struct dc_stream_state *cur_stream,
+bool dc_is_timing_changed(struct dc_stream_state *cur_stream,
struct dc_stream_state *new_stream)
{
if (cur_stream == NULL)
@@ -1880,7 +1880,7 @@ static bool are_stream_backends_same(
if (stream_a == NULL || stream_b == NULL)
return false;
- if (is_timing_changed(stream_a, stream_b))
+ if (dc_is_timing_changed(stream_a, stream_b))
return false;
if (stream_a->signal != stream_b->signal)
@@ -3505,7 +3505,7 @@ bool pipe_need_reprogram(
if (pipe_ctx_old->stream_res.stream_enc !=
pipe_ctx->stream_res.stream_enc)
return true;
- if (is_timing_changed(pipe_ctx_old->stream, pipe_ctx->stream))
+ if (dc_is_timing_changed(pipe_ctx_old->stream, pipe_ctx->stream))
return true;
if (pipe_ctx_old->stream->dpms_off != pipe_ctx->stream->dpms_off)
diff --git a/drivers/gpu/drm/amd/display/dc/dc.h
b/drivers/gpu/drm/amd/display/dc/dc.h
index 23ee63b98dcd..e7ab6cb3769b 100644
--- a/drivers/gpu/drm/amd/display/dc/dc.h
+++ b/drivers/gpu/drm/amd/display/dc/dc.h
@@ -2225,4 +2225,7 @@ void dc_process_dmub_dpia_hpd_int_enable(const struct dc
*dc,
/* Disable acc mode Interfaces */
void dc_disable_accelerated_mode(struct dc *dc);
+bool dc_is_timing_changed(struct dc_stream_state *cur_stream,
+ struct dc_stream_state *new_stream);
+
#endif /* DC_INTERFACE_H_ */
--
2.39.2
Re: [PATCH 1/2] drm/amd/display: mark dccg314_init() static
On Mon, Apr 17, 2023, at 23:12, Hamza Mahfooz wrote:
> On 4/17/23 17:05, Arnd Bergmann wrote:
>> From: Arnd Bergmann
>>
>> The newly introduced global function is not declared in a header or
>> called from another file, causing a harmless warning with sparse
>> or W=1 builds:
>>
>> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn314/dcn314_dccg.c:277:6: error:
>> no previous prototype for 'dccg314_init' [-Werror=missing-prototypes]
>>
>> Mark it static instead.
>>
>> Fixes: 6f6869dcf415 ("drm/amd/display: prep work for root clock optimization
>> enablement for DCN314")
>> Signed-off-by: Arnd Bergmann
>
> This has already been fixed as of commit 669f4ac40947 ("drm/amd/display:
> set variable dccg314_init storage-class-specifier to static") in
> amd-staging-drm-next.
Ok, thanks. I waited for a rebase on today's linux-next before posting
mine to make sure it's not already fixed, it must have just missed the
cut-off.
Arnd
[PATCH 2/2] drm/amd/display: fix missing=prototypes warnings
From: Arnd Bergmann
Three functions in the amdgpu display driver cause -Wmissing-prototype
warnings:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1858:6: error: no
previous prototype for 'is_timing_changed' [-Werror=missing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:210:6:
error: no previous prototype for 'is_synaptics_cascaded_panamera'
[-Werror=missing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_optc.c:294:6: error: no
previous prototype for 'optc3_wait_drr_doublebuffer_pending_clear'
[-Werror=missing-prototypes]
is_timing_changed() is actually meant to be a global symbol, but needs
a proper name and prototype, while the other two can just be made static.
Fixes: 54c7b715b5ef ("drm/amd/display: Add DSC Support for Synaptics Cascaded
MST Hub")
Fixes: 17ce8a6907f7 ("drm/amd/display: Add dsc pre-validation in atomic check")
Fixes: 8f0d304d21b3 ("drm/amd/display: Do not commit pipe when updating DRR")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 5 ++---
drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 6 +++---
drivers/gpu/drm/amd/display/dc/dc.h | 3 +++
3 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 994ba426ca66..442511061178 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -45,8 +45,7 @@
#endif
#include "dc/dcn20/dcn20_resource.h"
-bool is_timing_changed(struct dc_stream_state *cur_stream,
- struct dc_stream_state *new_stream);
+
#define PEAK_FACTOR_X1000 1006
static ssize_t dm_dp_aux_transfer(struct drm_dp_aux *aux,
@@ -1417,7 +1416,7 @@ int pre_validate_dsc(struct drm_atomic_state *state,
struct dc_stream_state *stream = dm_state->context->streams[i];
if (local_dc_state->streams[i] &&
- is_timing_changed(stream, local_dc_state->streams[i])) {
+ dc_is_timing_changed(stream, local_dc_state->streams[i])) {
DRM_INFO_ONCE("crtc[%d] needs mode_changed\n", i);
} else {
int ind = find_crtc_index_in_state_by_stream(state,
stream);
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
index 85d54bfb595c..344533623cb9 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
@@ -1855,7 +1855,7 @@ bool dc_add_all_planes_for_stream(
return add_all_planes_for_stream(dc, stream, , 1, context);
}
-bool is_timing_changed(struct dc_stream_state *cur_stream,
+bool dc_is_timing_changed(struct dc_stream_state *cur_stream,
struct dc_stream_state *new_stream)
{
if (cur_stream == NULL)
@@ -1880,7 +1880,7 @@ static bool are_stream_backends_same(
if (stream_a == NULL || stream_b == NULL)
return false;
- if (is_timing_changed(stream_a, stream_b))
+ if (dc_is_timing_changed(stream_a, stream_b))
return false;
if (stream_a->signal != stream_b->signal)
@@ -3505,7 +3505,7 @@ bool pipe_need_reprogram(
if (pipe_ctx_old->stream_res.stream_enc !=
pipe_ctx->stream_res.stream_enc)
return true;
- if (is_timing_changed(pipe_ctx_old->stream, pipe_ctx->stream))
+ if (dc_is_timing_changed(pipe_ctx_old->stream, pipe_ctx->stream))
return true;
if (pipe_ctx_old->stream->dpms_off != pipe_ctx->stream->dpms_off)
diff --git a/drivers/gpu/drm/amd/display/dc/dc.h
b/drivers/gpu/drm/amd/display/dc/dc.h
index 23ee63b98dcd..e7ab6cb3769b 100644
--- a/drivers/gpu/drm/amd/display/dc/dc.h
+++ b/drivers/gpu/drm/amd/display/dc/dc.h
@@ -2225,4 +2225,7 @@ void dc_process_dmub_dpia_hpd_int_enable(const struct dc
*dc,
/* Disable acc mode Interfaces */
void dc_disable_accelerated_mode(struct dc *dc);
+bool dc_is_timing_changed(struct dc_stream_state *cur_stream,
+ struct dc_stream_state *new_stream);
+
#endif /* DC_INTERFACE_H_ */
--
2.39.2
[PATCH 1/2] drm/amd/display: mark dccg314_init() static
From: Arnd Bergmann
The newly introduced global function is not declared in a header or
called from another file, causing a harmless warning with sparse
or W=1 builds:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn314/dcn314_dccg.c:277:6: error: no
previous prototype for 'dccg314_init' [-Werror=missing-prototypes]
Mark it static instead.
Fixes: 6f6869dcf415 ("drm/amd/display: prep work for root clock optimization
enablement for DCN314")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c
b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c
index 6f879265ad9c..de7bfba2c179 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c
@@ -274,7 +274,7 @@ static void dccg314_set_dpstreamclk(
}
}
-void dccg314_init(struct dccg *dccg)
+static void dccg314_init(struct dccg *dccg)
{
int otg_inst;
--
2.39.2
[PATCH] drm/radeon: move prototypes to header
From: Arnd Bergmann
Global functions in radeon_atpx_handler.c are not declared in a header
but instead in each file using them. This risks the types getting out
of sync and causes warnings:
drivers/gpu/drm/radeon/radeon_atpx_handler.c:64:6: error: no previous prototype
for 'radeon_has_atpx' [-Werror=missing-prototypes]
drivers/gpu/drm/radeon/radeon_atpx_handler.c:68:6: error: no previous prototype
for 'radeon_has_atpx_dgpu_power_cntl' [-Werror=missing-prototypes]
drivers/gpu/drm/radeon/radeon_atpx_handler.c:72:6: error: no previous prototype
for 'radeon_is_atpx_hybrid' [-Werror=missing-prototypes]
drivers/gpu/drm/radeon/radeon_atpx_handler.c:76:6: error: no previous prototype
for 'radeon_atpx_dgpu_req_power_for_displays' [-Werror=missing-prototypes]
drivers/gpu/drm/radeon/radeon_atpx_handler.c:594:6: error: no previous
prototype for 'radeon_register_atpx_handler' [-Werror=missing-prototypes]
drivers/gpu/drm/radeon/radeon_atpx_handler.c:612:6: error: no previous
prototype for 'radeon_unregister_atpx_handler' [-Werror=missing-prototypes]
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/radeon/radeon.h | 18 ++
drivers/gpu/drm/radeon/radeon_acpi.c | 6 --
drivers/gpu/drm/radeon/radeon_atpx_handler.c | 1 +
drivers/gpu/drm/radeon/radeon_device.c | 8
drivers/gpu/drm/radeon/radeon_drv.c | 13 -
drivers/gpu/drm/radeon/radeon_kms.c | 6 --
6 files changed, 19 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 8afb03bbce29..74fb4dfc3e5e 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2964,6 +2964,24 @@ void radeon_irq_kms_set_irq_n_enabled(struct
radeon_device *rdev,
void radeon_audio_component_init(struct radeon_device *rdev);
void radeon_audio_component_fini(struct radeon_device *rdev);
+/* atpx handler */
+#if defined(CONFIG_VGA_SWITCHEROO)
+bool radeon_has_atpx(void);
+void radeon_register_atpx_handler(void);
+void radeon_unregister_atpx_handler(void);
+bool radeon_has_atpx_dgpu_power_cntl(void);
+bool radeon_is_atpx_hybrid(void);
+bool radeon_atpx_dgpu_req_power_for_displays(void);
+#else
+static inline bool radeon_has_atpx(void) { return false; }
+static inline void radeon_register_atpx_handler(void) {}
+static inline void radeon_unregister_atpx_handler(void) {}
+static inline bool radeon_has_atpx_dgpu_power_cntl(void) { return false; }
+static inline bool radeon_is_atpx_hybrid(void) { return false; }
+static inline bool radeon_atpx_dgpu_req_power_for_displays(void) { return
false; }
+#endif
+
+
#include "radeon_object.h"
#endif
diff --git a/drivers/gpu/drm/radeon/radeon_acpi.c
b/drivers/gpu/drm/radeon/radeon_acpi.c
index 5771d1fcb073..695c673eb9f6 100644
--- a/drivers/gpu/drm/radeon/radeon_acpi.c
+++ b/drivers/gpu/drm/radeon/radeon_acpi.c
@@ -38,12 +38,6 @@
#include "radeon_acpi.h"
#include "radeon_pm.h"
-#if defined(CONFIG_VGA_SWITCHEROO)
-bool radeon_atpx_dgpu_req_power_for_displays(void);
-#else
-static inline bool radeon_atpx_dgpu_req_power_for_displays(void) { return
false; }
-#endif
-
#define ACPI_AC_CLASS "ac_adapter"
struct atif_verify_interface {
diff --git a/drivers/gpu/drm/radeon/radeon_atpx_handler.c
b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
index 6f93f54bf651..dfd30558f8e8 100644
--- a/drivers/gpu/drm/radeon/radeon_atpx_handler.c
+++ b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
@@ -12,6 +12,7 @@
#include
#include "radeon_acpi.h"
+#include "radeon.h"
struct radeon_atpx_functions {
bool px_params;
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index afbb3a80c0c6..180f8aa971b4 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -113,14 +113,6 @@ static const char radeon_family_name[][16] = {
"LAST",
};
-#if defined(CONFIG_VGA_SWITCHEROO)
-bool radeon_has_atpx_dgpu_power_cntl(void);
-bool radeon_is_atpx_hybrid(void);
-#else
-static inline bool radeon_has_atpx_dgpu_power_cntl(void) { return false; }
-static inline bool radeon_is_atpx_hybrid(void) { return false; }
-#endif
-
#define RADEON_PX_QUIRK_DISABLE_PX (1 << 0)
struct radeon_px_quirk {
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index e4374814f0ef..d8d75b347678 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -128,19 +128,6 @@ int radeon_mode_dumb_create(struct drm_file *file_priv,
struct drm_device *dev,
struct drm_mode_create_dumb *args);
-/* atpx handler */
-#if defined(CONFIG_VGA_SWITCHEROO)
-void radeon_register_atpx_handler(void);
-void radeon_unregister_atpx_handler(void);
-bool radeon_has_atpx_dgpu_power_cntl(void);
-bool radeon_is_atpx_hybrid(voi
[PATCH] drm/amd/display: fix link_validation build failure
From: Arnd Bergmann
When CONFIG_DRM_AMD_DC_DCN is disabled, the is_frl member
is not defined:
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_validation.c: In function
'dp_active_dongle_validate_timing':
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_validation.c:126:66: error:
'const struct dc_dsc_config' has no member named 'is_frl'
126 | if (timing->flags.DSC &&
!timing->dsc_cfg.is_frl)
| ^
Use the same #ifdef as the other references to this.
Fixes: 5461d1ea ("drm/amd/display: break down dc_link.c")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/dc/link/link_validation.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/link/link_validation.c
b/drivers/gpu/drm/amd/display/dc/link/link_validation.c
index cd821d077d73..8ddebf3bdd46 100644
--- a/drivers/gpu/drm/amd/display/dc/link/link_validation.c
+++ b/drivers/gpu/drm/amd/display/dc/link/link_validation.c
@@ -123,9 +123,11 @@ static bool dp_active_dongle_validate_timing(
if (dongle_caps->dp_hdmi_frl_max_link_bw_in_kbps > 0) { // DP
to HDMI FRL converter
struct dc_crtc_timing outputTiming = *timing;
+#if defined(CONFIG_DRM_AMD_DC_DCN)
if (timing->flags.DSC && !timing->dsc_cfg.is_frl)
/* DP input has DSC, HDMI FRL output doesn't
have DSC, remove DSC from output timing */
outputTiming.flags.DSC = 0;
+#endif
if (dc_bandwidth_in_kbps_from_timing() >
dongle_caps->dp_hdmi_frl_max_link_bw_in_kbps)
return false;
} else { // DP to HDMI TMDS converter
--
2.39.1
[PATCH] [SUBMITTED 20210927] [RESEND^2] drm/amdgpu: fix enum odm_combine_mode mismatch
From: Arnd Bergmann
A conversion from 'bool' to 'enum odm_combine_mode' was incomplete,
and gcc warns about this with many instances of
display/dc/dml/dcn20/display_mode_vba_20.c:3899:44: warning: implicit
conversion from 'enum ' to 'enum
odm_combine_mode' [-Wenum-conversion]
3899 | locals->ODMCombineEnablePerState[i][k] = false;
Change the ones that we get a warning for, using the same numerical
values to leave the behavior unchanged.
Fixes: 5fc11598166d ("drm/amd/display: expand dml structs")
Link: https://lore.kernel.org/all/20201026210039.3884312-3-a...@kernel.org/
Link: https://lore.kernel.org/all/20210927100659.1431744-1-a...@kernel.org/
Signed-off-by: Arnd Bergmann
---
I sent this in 2020 and in 2021, but never got a reply and the warning
is still there.
---
.../amd/display/dc/dml/dcn20/display_mode_vba_20.c | 8
.../amd/display/dc/dml/dcn20/display_mode_vba_20v2.c | 10 +-
.../amd/display/dc/dml/dcn21/display_mode_vba_21.c | 12 ++--
3 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20.c
index f34bc3c8da41..69c41e3e3ba2 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20.c
@@ -3901,14 +3901,14 @@ void dml20_ModeSupportAndSystemConfigurationFull(struct
display_mode_lib *mode_l
mode_lib->vba.PlaneRequiredDISPCLKWithODMCombine = mode_lib->vba.PixelClock[k]
/ 2
* (1 +
mode_lib->vba.DISPCLKDPPCLKDSCCLKDownSpreading / 100.0);
- locals->ODMCombineEnablePerState[i][k] = false;
+ locals->ODMCombineEnablePerState[i][k] =
dm_odm_combine_mode_disabled;
mode_lib->vba.PlaneRequiredDISPCLK =
mode_lib->vba.PlaneRequiredDISPCLKWithoutODMCombine;
if (mode_lib->vba.ODMCapability) {
if
(locals->PlaneRequiredDISPCLKWithoutODMCombine >
mode_lib->vba.MaxDispclkRoundedDownToDFSGranularity) {
-
locals->ODMCombineEnablePerState[i][k] = true;
+
locals->ODMCombineEnablePerState[i][k] = dm_odm_combine_mode_2to1;
mode_lib->vba.PlaneRequiredDISPCLK =
mode_lib->vba.PlaneRequiredDISPCLKWithODMCombine;
} else if (locals->HActive[k] >
DCN20_MAX_420_IMAGE_WIDTH && locals->OutputFormat[k] == dm_420) {
-
locals->ODMCombineEnablePerState[i][k] = true;
+
locals->ODMCombineEnablePerState[i][k] = dm_odm_combine_mode_2to1;
mode_lib->vba.PlaneRequiredDISPCLK =
mode_lib->vba.PlaneRequiredDISPCLKWithODMCombine;
}
}
@@ -3961,7 +3961,7 @@ void dml20_ModeSupportAndSystemConfigurationFull(struct
display_mode_lib *mode_l
locals->RequiredDISPCLK[i][j] = 0.0;
locals->DISPCLK_DPPCLK_Support[i][j] = true;
for (k = 0; k <=
mode_lib->vba.NumberOfActivePlanes - 1; k++) {
- locals->ODMCombineEnablePerState[i][k]
= false;
+ locals->ODMCombineEnablePerState[i][k]
= dm_odm_combine_mode_disabled;
if (locals->SwathWidthYSingleDPP[k] <=
locals->MaximumSwathWidth[k]) {
locals->NoOfDPP[i][j][k] = 1;
locals->RequiredDPPCLK[i][j][k]
= locals->MinDPPCLKUsingSingleDPP[k]
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20v2.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20v2.c
index 366138df0fe2..f475a0ae946c 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20v2.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20v2.c
@@ -4012,17 +4012,17 @@ void
dml20v2_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode
mode_lib->vba.PlaneRequiredDISPCLKWithODMCombine = mode_lib->vba.PixelClock[k]
/ 2
* (1 +
mode_lib->vba.DISPCLKDPPCLKDSCCLKDownSpreading / 100.0);
- locals->ODMCombineEnablePerState[i][k] = false;
+ locals->ODMC
[PATCH] drm/amdgpu/display/mst: fix an unused-variable warning
From: Arnd Bergmann
The newly added code is in an #ifdef, so the variables that
are only used in there cause a warning if CONFIG_DRM_AMD_DC_DCN
is disabled:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function
'amdgpu_dm_atomic_check':
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:9698:43: error:
unused variable 'mst_state' [-Werror=unused-variable]
9698 | struct drm_dp_mst_topology_state *mst_state;
| ^
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:9697:41: error:
unused variable 'mgr' [-Werror=unused-variable]
9697 | struct drm_dp_mst_topology_mgr *mgr;
| ^~~
Fixes: c689e1e362ea ("drm/amdgpu/display/mst: Fix mst_state->pbn_div and slot
count assignments")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index be1232356f9e..c966bb05f6c7 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -9694,8 +9694,10 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
struct drm_connector_state *old_con_state, *new_con_state;
struct drm_crtc *crtc;
struct drm_crtc_state *old_crtc_state, *new_crtc_state;
+#if defined(CONFIG_DRM_AMD_DC_DCN)
struct drm_dp_mst_topology_mgr *mgr;
struct drm_dp_mst_topology_state *mst_state;
+#endif
struct drm_plane *plane;
struct drm_plane_state *old_plane_state, *new_plane_state;
enum dc_status status;
--
2.39.0
[PATCH] drm/amd/display: fix hdmi_encoded_link_bw definition
From: Arnd Bergmann
Some of the data structures are hidden when CONFIG_DRM_AMD_DC_DCN is
disabled, which leads to a link failure:
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_dp_capability.c:234:21:
error: 'union hdmi_encoded_link_bw' declared inside parameter list will not be
visible outside of this definition or declaration [-Werror]
234 | const union hdmi_encoded_link_bw hdmi_encoded_link_bw)
| ^~~~
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_dp_capability.c:234:42:
error: parameter 2 ('hdmi_encoded_link_bw') has incomplete type
234 | const union hdmi_encoded_link_bw hdmi_encoded_link_bw)
| ~^~~~
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_dp_capability.c:232:17:
error: function declaration isn't a prototype [-Werror=strict-prototypes]
232 | static uint32_t intersect_frl_link_bw_support(
| ^
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_dp_capability.c: In function
'get_active_converter_info':
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_dp_capability.c:1126:76:
error: storage size of 'hdmi_encoded_link_bw' isn't known
1126 | union
hdmi_encoded_link_bw hdmi_encoded_link_bw;
|
^~~~
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_dp_capability.c:1130:101:
error: 'struct ' has no member named 'MAX_ENCODED_LINK_BW_SUPPORT'
1130 |
hdmi_color_caps.bits.MAX_ENCODED_LINK_BW_SUPPORT);
There is probably no need to hide the data structure, and removing
the #ifdef makes it build cleanly.
Fixes: d5a43956b73b ("drm/amd/display: move dp capability related logic to
link_dp_capability")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/dc/dc_dp_types.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
b/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
index b7e53b7dc4ed..84da54358922 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
+++ b/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
@@ -361,14 +361,10 @@ enum dpcd_downstream_port_detailed_type {
union dwnstream_port_caps_byte2 {
struct {
uint8_t MAX_BITS_PER_COLOR_COMPONENT:2;
-#if defined(CONFIG_DRM_AMD_DC_DCN)
uint8_t MAX_ENCODED_LINK_BW_SUPPORT:3;
uint8_t SOURCE_CONTROL_MODE_SUPPORT:1;
uint8_t CONCURRENT_LINK_BRING_UP_SEQ_SUPPORT:1;
uint8_t RESERVED:1;
-#else
- uint8_t RESERVED:6;
-#endif
} bits;
uint8_t raw;
};
@@ -406,7 +402,6 @@ union dwnstream_port_caps_byte3_hdmi {
uint8_t raw;
};
-#if defined(CONFIG_DRM_AMD_DC_DCN)
union hdmi_sink_encoded_link_bw_support {
struct {
uint8_t HDMI_SINK_ENCODED_LINK_BW_SUPPORT:3;
@@ -428,7 +423,6 @@ union hdmi_encoded_link_bw {
} bits;
uint8_t raw;
};
-#endif
/*4-byte structure for detailed capabilities of a down-stream port
(DP-to-TMDS converter).*/
--
2.39.0
[PATCH] drm/amd/display: fix dp_retrieve_lttpr_cap() return value
From: Arnd Bergmann
gcc-13 notices a mismatch between the return type of dp_retrieve_lttpr_cap()
and the returned value:
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_dp_capability.c: In function
'dp_retrieve_lttpr_cap':
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_dp_capability.c:1465:24:
error: implicit conversion from 'enum ' to 'enum dc_status'
[-Werror=enum-conversion]
1465 | return false;
|^
Change the value to an actual dc_status code and remove the bogus
initialization that was apparently meant to get returned here.
Fixes: b473bd5fc333 ("drm/amd/display: refine wake up aux in retrieve link
caps")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/dc/link/link_dp_capability.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/link/link_dp_capability.c
b/drivers/gpu/drm/amd/display/dc/link/link_dp_capability.c
index 088f4291bfbf..e72ad1b8330f 100644
--- a/drivers/gpu/drm/amd/display/dc/link/link_dp_capability.c
+++ b/drivers/gpu/drm/amd/display/dc/link/link_dp_capability.c
@@ -1455,14 +1455,14 @@ static bool dpcd_read_sink_ext_caps(struct dc_link
*link)
enum dc_status dp_retrieve_lttpr_cap(struct dc_link *link)
{
uint8_t lttpr_dpcd_data[8];
- enum dc_status status = DC_ERROR_UNEXPECTED;
- bool is_lttpr_present = false;
+ enum dc_status status;
+ bool is_lttpr_present;
/* Logic to determine LTTPR support*/
bool vbios_lttpr_interop = link->dc->caps.vbios_lttpr_aware;
if (!vbios_lttpr_interop ||
!link->dc->caps.extended_aux_timeout_support)
- return false;
+ return DC_ERROR_UNEXPECTED;
/* By reading LTTPR capability, RX assumes that we will enable
* LTTPR extended aux timeout if LTTPR is present.
--
2.39.0
[PATCH] [v2] drm/amd/display: fix dp_retrieve_lttpr_cap return code
From: Arnd Bergmann
The dp_retrieve_lttpr_cap() return type changed from 'bool'
to 'enum dc_status', so now the early 'return' uses the wrong
type:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c: In function
'dp_retrieve_lttpr_cap':
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:5075:24: error:
implicit conversion from 'enum ' to 'enum dc_status'
[-Werror=enum-conversion]
5075 | return false;
|^
Convert it to return 'DC_ERROR_UNEXPECTED', which was apparently set
as a default return code here but never used.
Fixes: b473bd5fc333 ("drm/amd/display: refine wake up aux in retrieve link
caps")
Signed-off-by: Arnd Bergmann
---
v2 changes:
- use DC_ERROR_UNEXPECTED instead of DC_OK
- remove bogus initializers
---
drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
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 9edfcdf3db3b..cf512362b4f1 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
@@ -5088,14 +5088,14 @@ static bool dpcd_read_sink_ext_caps(struct dc_link
*link)
enum dc_status dp_retrieve_lttpr_cap(struct dc_link *link)
{
uint8_t lttpr_dpcd_data[8];
- enum dc_status status = DC_ERROR_UNEXPECTED;
- bool is_lttpr_present = false;
+ enum dc_status status;
+ bool is_lttpr_present;
/* Logic to determine LTTPR support*/
bool vbios_lttpr_interop = link->dc->caps.vbios_lttpr_aware;
if (!vbios_lttpr_interop ||
!link->dc->caps.extended_aux_timeout_support)
- return false;
+ return DC_ERROR_UNEXPECTED;
/* By reading LTTPR capability, RX assumes that we will enable
* LTTPR extended aux timeout if LTTPR is present.
--
2.39.0
Re: [PATCH] drm/amd/display: fix dp_retrieve_lttpr_cap return code
On Thu, Dec 15, 2022, at 18:56, Michel Dänzer wrote:
> On 12/15/22 17:37, Arnd Bergmann wrote:
/amd/display/dc/core/dc_link_dp.c
>> index af9411ee3c74..95dbfa4e996a 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
>> @@ -5095,7 +5095,7 @@ enum dc_status dp_retrieve_lttpr_cap(struct dc_link
>> *link)
>> bool vbios_lttpr_interop = link->dc->caps.vbios_lttpr_aware;
>>
>> if (!vbios_lttpr_interop ||
>> !link->dc->caps.extended_aux_timeout_support)
>> -return false;
>> +return DC_OK;
>
> return status;
>
> seems more appropriate. (Otherwise the status = DC_ERROR_UNEXPECTED
> initialization has no effect)
Ok, makes sense. I'd also remove the unused initialization in that
case though:
enum dc_status dp_retrieve_lttpr_cap(struct dc_link *link)
{
uint8_t lttpr_dpcd_data[8];
- enum dc_status status = DC_ERROR_UNEXPECTED;
- bool is_lttpr_present = false;
+ enum dc_status status;
+ bool is_lttpr_present;
/* Logic to determine LTTPR support*/
bool vbios_lttpr_interop = link->dc->caps.vbios_lttpr_aware;
if (!vbios_lttpr_interop ||
!link->dc->caps.extended_aux_timeout_support)
- return false;
+ return DC_ERROR_UNEXPECTED;
/* By reading LTTPR capability, RX assumes that we will enable
* LTTPR extended aux timeout if LTTPR is present.
I'll send that as a v2 once that passes my build test and nobody
has further suggestions.
Arnd
[PATCH] drm/amd/display: fix duplicate assignments
From: Arnd Bergmann
The .set_odm_combine callback pointer was added twice, causing
a harmless -Wextra warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn314/dcn314_optc.c:258:36: error:
initialized field overwritten [-Werror=override-init]
258 | .set_odm_combine = optc314_set_odm_combine,
|^~~
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn314/dcn314_optc.c:258:36: note:
(near initialization for 'dcn314_tg_funcs.set_odm_combine')
Fixes: 5ade1b951dec ("drm/amd/display: Add OTG/ODM functions")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/dc/dcn314/dcn314_optc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_optc.c
b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_optc.c
index f246aab23050..0086cafb0f7a 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_optc.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_optc.c
@@ -241,7 +241,6 @@ static struct timing_generator_funcs dcn314_tg_funcs = {
.set_dsc_config = optc3_set_dsc_config,
.get_dsc_status = optc2_get_dsc_status,
.set_dwb_source = NULL,
- .set_odm_combine = optc314_set_odm_combine,
.get_optc_source = optc2_get_optc_source,
.set_out_mux = optc3_set_out_mux,
.set_drr_trigger_window = optc3_set_drr_trigger_window,
--
2.35.1
[PATCH] drm/amd/display: fix dp_retrieve_lttpr_cap return code
From: Arnd Bergmann
The dp_retrieve_lttpr_cap() return type changed from 'bool'
to 'enum dc_status', so now the early 'return' uses the wrong
type:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c: In function
'dp_retrieve_lttpr_cap':
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:5075:24: error:
implicit conversion from 'enum ' to 'enum dc_status'
[-Werror=enum-conversion]
5075 | return false;
|^
Convert it to return 'DC_OK', which is the same value as 'false'.
Fixes: b473bd5fc333 ("drm/amd/display: refine wake up aux in retrieve link
caps")
Signed-off-by: Arnd Bergmann
---
No idea if DC_OK is the intended return code, but it leaves the behavior
unchanged and fixes the warning.
---
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 af9411ee3c74..95dbfa4e996a 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
@@ -5095,7 +5095,7 @@ enum dc_status dp_retrieve_lttpr_cap(struct dc_link *link)
bool vbios_lttpr_interop = link->dc->caps.vbios_lttpr_aware;
if (!vbios_lttpr_interop ||
!link->dc->caps.extended_aux_timeout_support)
- return false;
+ return DC_OK;
/* By reading LTTPR capability, RX assumes that we will enable
* LTTPR extended aux timeout if LTTPR is present.
--
2.35.1
[PATCH] drm/amd/pm: avoid large variable on kernel stack
From: Arnd Bergmann
The activity_monitor_external[] array is too big to fit on the
kernel stack, resulting in this warning with clang:
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu13/smu_v13_0_7_ppt.c:1438:12: error:
stack frame size (1040) exceeds limit (1024) in
'smu_v13_0_7_get_power_profile_mode' [-Werror,-Wframe-larger-than]
Use dynamic allocation instead. It should also be possible to
have single element here instead of the array, but this seems
easier.
Fixes: 334682ae8151 ("drm/amd/pm: enable workload type change on smu_v13_0_7")
Signed-off-by: Arnd Bergmann
---
.../drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c | 21 ++-
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
index c270f94a1b86..7eba854e09ec 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
@@ -1439,7 +1439,7 @@ static int smu_v13_0_7_get_power_limit(struct smu_context
*smu,
static int smu_v13_0_7_get_power_profile_mode(struct smu_context *smu, char
*buf)
{
- DpmActivityMonitorCoeffIntExternal_t
activity_monitor_external[PP_SMC_POWER_PROFILE_COUNT];
+ DpmActivityMonitorCoeffIntExternal_t *activity_monitor_external;
uint32_t i, j, size = 0;
int16_t workload_type = 0;
int result = 0;
@@ -1447,6 +1447,12 @@ static int smu_v13_0_7_get_power_profile_mode(struct
smu_context *smu, char *buf
if (!buf)
return -EINVAL;
+ activity_monitor_external = kcalloc(sizeof(activity_monitor_external),
+ PP_SMC_POWER_PROFILE_COUNT,
+ GFP_KERNEL);
+ if (!activity_monitor_external)
+ return -ENOMEM;
+
size += sysfs_emit_at(buf, size, " ");
for (i = 0; i <= PP_SMC_POWER_PROFILE_WINDOW3D; i++)
size += sysfs_emit_at(buf, size, "%-14s%s",
amdgpu_pp_profile_name[i],
@@ -1459,15 +1465,17 @@ static int smu_v13_0_7_get_power_profile_mode(struct
smu_context *smu, char *buf
workload_type = smu_cmn_to_asic_specific_index(smu,
CMN2ASIC_MAPPING_WORKLOAD,
i);
- if (workload_type < 0)
- return -EINVAL;
+ if (workload_type < 0) {
+ result = -EINVAL;
+ goto out;
+ }
result = smu_cmn_update_table(smu,
SMU_TABLE_ACTIVITY_MONITOR_COEFF,
workload_type,
(void
*)(_monitor_external[i]), false);
if (result) {
dev_err(smu->adev->dev, "[%s] Failed to get activity
monitor!", __func__);
- return result;
+ goto out;
}
}
@@ -1495,7 +1503,10 @@ do {
\
PRINT_DPM_MONITOR(Fclk_BoosterFreq);
#undef PRINT_DPM_MONITOR
- return size;
+ result = size;
+out:
+ kfree(activity_monitor_external);
+ return result;
}
static int smu_v13_0_7_set_power_profile_mode(struct smu_context *smu, long
*input, uint32_t size)
--
2.35.1
Re: [PATCH 2/3] drm/amdgpu: Temporarily disable broken Clang builds due to blown stack-frame
On Fri, Nov 25, 2022, at 10:25, Lee Jones wrote: > calculate_bandwidth() is presently broken on all !(X86_64 || SPARC64 || ARM64) > architectures built with Clang (all released versions), whereby the stack > frame gets blown up to well over 5k. This would cause an immediate kernel > panic on most architectures. We'll revert this when the following bug report > has been resolved: https://github.com/llvm/llvm-project/issues/41896. > > Suggested-by: Arnd Bergmann > Signed-off-by: Lee Jones > --- > drivers/gpu/drm/Kconfig | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index 34f5a092c99e7..1fa7b9760adb8 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -265,6 +265,7 @@ source "drivers/gpu/drm/radeon/Kconfig" > > config DRM_AMDGPU > tristate "AMD GPU" > + depends on BROKEN || !CC_IS_CLANG || !(X86_64 || SPARC64 || ARM64) The logic looks fine, this has been broken for so long without anyone paying attention that limiting the broken code to the working architectures is probably the best way to avoid trouble. However, as far as I can tell, the problem doesn't affect the entire driver, only the "new" display engine, so I would probably try to limit this to turning off CONFIG_DRM_AMD_DC for architectures that don't have a fixed clang. Arnd
Re: [PATCH 1/3] drm/amd/display/dc/calcs/dce_calcs: Break-out a stack-heavy chunk of code
On Fri, Nov 25, 2022, at 10:25, Lee Jones wrote: > bw_calcs() presently blows the stack-frame limit by calling functions > inside a argument list which return quite a bit of data to be passed > onto sub-functions. Simply breaking out this hunk reduces the > stack-frame use by 500 Bytes, preventing the following compiler > warning: > > drivers/gpu/drm/amd/amdgpu/../display/dc/dml/calcs/dce_calcs.c:3285:6: > warning: stack frame size (1384) exceeds limit (1024) > in 'bw_calcs' [-Wframe-larger-than] > bool bw_calcs(struct dc_context *ctx, > ^ > 1 warning generated. > > This resolves the issue and takes us one step closer towards a > successful allmodconfig WERROR build. > > Signed-off-by: Lee Jones Is this still needed with the patch to turn off the display engine on most architectures? On which architecture and with which compiler do you still observe the problem? Note that this probably doesn't actually solve the potential stack overflow by itself, since the function that is now split out is still called with the parent stack active. Splitting out multiple smaller bits however would solve it since then the stack frames could overlap. Arnd
Re: [PATCH 3/3] Kconfig.debug: Provide a little extra FRAME_WARN leeway when KASAN is enabled
On Fri, Nov 25, 2022, at 10:25, Lee Jones wrote: > When enabled, KASAN enlarges function's stack-frames. Pushing quite a > few over the current threshold. This can mainly be seen on 32-bit > architectures where the present limit (when !GCC) is a lowly > 1024-Bytes. > > Signed-off-by: Lee Jones Acked-by: Arnd Bergmann If this affects only clang but not gcc, I wonder if we could limit the scope and keep the 1024 byte limit on gcc builds. > --- > lib/Kconfig.debug | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > index c3c0b077ade33..82d475168db95 100644 > --- a/lib/Kconfig.debug > +++ b/lib/Kconfig.debug > @@ -399,6 +399,7 @@ config FRAME_WARN > default 2048 if GCC_PLUGIN_LATENT_ENTROPY This is actually a related bug that we should fix: allmodconfig with gcc turns on GCC_PLUGIN_LATENT_ENTROPY, so the limit ends up being way too high. I think we need to either ensure that allmodconfig turns off the latent entropy plugin, or that the limit gets lowered again to something that is not any higher than the KASAN limit. Arnd
Re: [PATCH v2 1/2] drm/amdgpu: Temporarily disable broken Clang builds due to blown stack-frame
On Fri, Nov 25, 2022, at 13:07, Lee Jones wrote: > calculate_bandwidth() is presently broken on all !(X86_64 || SPARC64 || ARM64) > architectures built with Clang (all released versions), whereby the stack > frame gets blown up to well over 5k. This would cause an immediate kernel > panic on most architectures. We'll revert this when the following bug report > has been resolved: https://github.com/llvm/llvm-project/issues/41896. > > Suggested-by: Arnd Bergmann > Signed-off-by: Lee Jones Acked-by: Arnd Bergmann
Re: [PATCH v2 2/2] Kconfig.debug: Provide a little extra FRAME_WARN leeway when KASAN is enabled
On Fri, Nov 25, 2022, at 14:40, Lee Jones wrote: > On Fri, 25 Nov 2022, Lee Jones wrote: > >> When enabled, KASAN enlarges function's stack-frames. Pushing quite a >> few over the current threshold. This can mainly be seen on 32-bit >> architectures where the present limit (when !GCC) is a lowly >> 1024-Bytes. >> >> Signed-off-by: Lee Jones >> --- >> lib/Kconfig.debug | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug >> index c3c0b077ade33..82d475168db95 100644 >> --- a/lib/Kconfig.debug >> +++ b/lib/Kconfig.debug >> @@ -399,6 +399,7 @@ config FRAME_WARN >> default 2048 if GCC_PLUGIN_LATENT_ENTROPY >> default 2048 if PARISC >> default 1536 if (!64BIT && XTENSA) >> +default 1280 if KASAN && !64BIT >> default 1024 if !64BIT >> default 2048 if 64BIT >> help > > Note this also fixes 61 warnings when > > (GCC && !GCC_PLUGIN_LATENT_ENTROPY) > > ... which as Arnd says should not be enabled by default. We'll > address that issue once this set has been applied. Thanks a lot for checking this! Reviewed-by: Arnd Bergmann
Re: [PATCH v3 1/1] drm/amd/display: add DCN support for ARM64
On Thu, Oct 27, 2022, at 21:52, Ao Zhong wrote: > After moving all FPU code to the DML folder, we can enable DCN support > for the ARM64 platform. Remove the -mgeneral-regs-only CFLAG from the > code in the DML folder that needs to use hardware FPU, and add a control > mechanism for ARM Neon. > > Signed-off-by: Ao Zhong Looks good to me, Acked-by: Arnd Bergmann
Re: [PATCH v2 1/1] drm/amd/display: add DCN support for ARM64
On Thu, Oct 27, 2022, at 16:45, Ao Zhong wrote: > After moving all FPU code to the DML folder, we can enable DCN support > for the ARM64 platform. Remove the -mgeneral-regs-only CFLAG from the > code in the DML folder that needs to use hardware FPU, and add a control > mechanism for ARM Neon. > > Signed-off-by: Ao Zhong > > +ifdef CONFIG_ARM64 > +ifdef CONFIG_DRM_AMD_DC_DCN > +dml_rcflags := -mgeneral-regs-only > +endif > +endif I don't think the CONFIG_DRM_AMD_DC_DCN check is needed here, if the dml_ccflags doesn't have this. > +ifdef CONFIG_ARM64 > +CFLAGS_REMOVE_$(AMDDALPATH)/dc/dml/dcn10/dcn10_fpu.o := $(dml_rcflags) > +CFLAGS_REMOVE_$(AMDDALPATH)/dc/dml/dcn20/dcn20_fpu.o := $(dml_rcflags) > +CFLAGS_REMOVE_$(AMDDALPATH)/dc/dml/dcn314/display_mode_vba_314.o := > $(dml_rcflags) Similarly, this bit should not need a check for CONFIG_ARM64. > +CFLAGS_REMOVE_$(AMDDALPATH)/dc/dml/dcn314/display_rq_dlg_calc_314.o := > $(dml_rcflags) > +CFLAGS_REMOVE_$(AMDDALPATH)/dc/dml/dcn314/dcn314_fpu.o := > $(dml_rcflags) > +CFLAGS_REMOVE_$(AMDDALPATH)/dc/dml/dcn30/dcn30_fpu.o := $(dml_rcflags) > +CFLAGS_REMOVE_$(AMDDALPATH)/dc/dml/dcn32/dcn32_fpu.o := $(dml_rcflags) > +CFLAGS_REMOVE_$(AMDDALPATH)/dc/dml/dcn321/dcn321_fpu.o := > $(dml_rcflags) > +CFLAGS_REMOVE_$(AMDDALPATH)/dc/dml/dcn31/dcn31_fpu.o := $(dml_rcflags) > +CFLAGS_REMOVE_$(AMDDALPATH)/dc/dml/dcn302/dcn302_fpu.o := > $(dml_rcflags) > +CFLAGS_REMOVE_$(AMDDALPATH)/dc/dml/dcn303/dcn303_fpu.o := > $(dml_rcflags) > +CFLAGS_REMOVE_$(AMDDALPATH)/dc/dml/calcs/dcn_calc_math.o := > $(dml_rcflags) > +endif > endif > CFLAGS_$(AMDDALPATH)/dc/dml/dml1_display_rq_dlg_calc.o := > $(dml_ccflags) > CFLAGS_$(AMDDALPATH)/dc/dml/display_rq_dlg_helpers.o := $(dml_ccflags) Having the #endif for the CONFIG_DRM_AMD_DC_DCN list is a bit confusing (this is the preexisting state, not your change).I'd probably drop the CONFIG_DRM_AMD_DC_DCN check for the per-file cflags entirely. Arnd
Re: [PATCH RESEND 1/1] drm/amd/display: add DCN support for ARM64
On Thu, Oct 27, 2022, at 15:38, Ao Zhong wrote: > Am Do., 27. Okt. 2022 um 12:52 Uhr schrieb Arnd Bergmann : > >> Why do you need separate $(dml_rcflags) and $(dml_rcflags_arm64) >> rather than adding -mgeneral-regs-only to $(dml_rcflags) directly? > > I don't know if $(dml_rcflags) has any other use. I'm afraid my patch > will break something. >From the git history, it looks like dml_rcflags was introduced for arm64 support originally and left in place when this support got disabled. Arnd
Re: [PATCH RESEND 1/1] drm/amd/display: add DCN support for ARM64
On Thu, Oct 27, 2022, at 02:25, Ao Zhong wrote: > After moving all FPU code to the DML folder, we can enable DCN support > for the ARM64 platform. Remove the -mgeneral-regs-only CFLAG from the > code in the DML folder that needs to use hardware FPU, and add a control > mechanism for ARM Neon. > > Signed-off-by: Ao Zhong There have been problems with stack frame overflows on this code in the past, how much have you tested this with random configurations to see if we still hit them in corner cases on arm64 that may not show up on x86 or powerpc? I would expect to see a few more of them for every new architecture port. > index d0c6cf61c676..3cdd109189e0 100644 > --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile > +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile > @@ -33,6 +33,12 @@ ifdef CONFIG_PPC64 > dml_ccflags := -mhard-float -maltivec > endif > > +ifdef CONFIG_ARM64 > +ifdef CONFIG_DRM_AMD_DC_DCN > +dml_rcflags_arm64 := -mgeneral-regs-only > +endif > +endif > + > CFLAGS_$(AMDDALPATH)/dc/dml/calcs/dcn_calcs.o := $(dml_ccflags) > CFLAGS_$(AMDDALPATH)/dc/dml/calcs/dcn_calc_auto.o := $(dml_ccflags) > CFLAGS_$(AMDDALPATH)/dc/dml/calcs/dcn_calc_math.o := $(dml_ccflags) > -Wno-tautological-compare > -CFLAGS_REMOVE_$(AMDDALPATH)/dc/dml/display_mode_vba.o := $(dml_rcflags) > +CFLAGS_REMOVE_$(AMDDALPATH)/dc/dml/display_mode_vba.o := > $(dml_rcflags) $(dml_rcflags_arm64) Why do you need separate $(dml_rcflags) and $(dml_rcflags_arm64) rather than adding -mgeneral-regs-only to $(dml_rcflags) directly? Arnd
Re: mainline build failure for x86_64 allmodconfig with clang
On Fri, Aug 5, 2022 at 8:02 PM Nathan Chancellor wrote: > On Fri, Aug 05, 2022 at 06:16:45PM +0200, Arnd Bergmann wrote: > > On Fri, Aug 5, 2022 at 5:32 PM Harry Wentland > > wrote: > > While splitting out sub-functions can help reduce the maximum stack > > usage, it seems that in this case it makes the actual problem worse: > > I see 2168 bytes for the combined > > dml32_ModeSupportAndSystemConfigurationFull(), but marking > > mode_support_configuration() as noinline gives me 1992 bytes > > for the outer function plus 384 bytes for the inner one. So it does > > avoid the warning (barely), but not the problem that the warning tries > > to point out. > > I haven't had a chance to take a look at splitting things up yet, would > you recommend a different approach? Splitting up large functions can help when you have large local variables that are used in different parts of the function, and the split gets the compiler to reuse stack locations. I think in this particular function, the problem isn't actually local variables but either pushing variables on the stack for argument passing, or something that causes the compiler to run out of registers so it has to spill registers to the stack. In either case, one has to actually look at the generated output and then try to rearrange the codes so this does not happen. One thing to try would be to condense a function call like dml32_CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport( >dummy_vars.dml32_CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport, mode_lib->vba.USRRetrainingRequiredFinal, mode_lib->vba.UsesMALLForPStateChange, mode_lib->vba.PrefetchModePerState[mode_lib->vba.VoltageLevel][mode_lib->vba.maxMpcComb], mode_lib->vba.NumberOfActiveSurfaces, mode_lib->vba.MaxLineBufferLines, mode_lib->vba.LineBufferSizeFinal, mode_lib->vba.WritebackInterfaceBufferSize, mode_lib->vba.DCFCLK, mode_lib->vba.ReturnBW, mode_lib->vba.SynchronizeTimingsFinal, mode_lib->vba.SynchronizeDRRDisplaysForUCLKPStateChangeFinal, mode_lib->vba.DRRDisplay, v->dpte_group_bytes, v->meta_row_height, v->meta_row_height_chroma, v->dummy_vars.DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerformanceCalculation.mmSOCParameters, mode_lib->vba.WritebackChunkSize, mode_lib->vba.SOCCLK, v->DCFCLKDeepSleep, mode_lib->vba.DETBufferSizeY, mode_lib->vba.DETBufferSizeC, mode_lib->vba.SwathHeightY, mode_lib->vba.SwathHeightC, mode_lib->vba.LBBitPerPixel, v->SwathWidthY, v->SwathWidthC, mode_lib->vba.HRatio, mode_lib->vba.HRatioChroma, mode_lib->vba.vtaps, mode_lib->vba.VTAPsChroma, mode_lib->vba.VRatio, mode_lib->vba.VRatioChroma, mode_lib->vba.HTotal, mode_lib->vba.VTotal, mode_lib->vba.VActive, mode_lib->vba.PixelClock, mode_lib->vba.BlendingAndTiming, /* more arguments */); into calling conventions that take a pointer to 'mode_lib->vba' and another one to 'v', so these are no longer passed on the stack individually. Arnd
Re: mainline build failure for x86_64 allmodconfig with clang
On Fri, Aug 5, 2022 at 5:32 PM Harry Wentland wrote:
> > I do notice that these files build with a non-configurable
> > -Wframe-large-than value:
> >
> > $ rg frame_warn_flag drivers/gpu/drm/amd/display/dc/dml/Makefile
> > 54:frame_warn_flag := -Wframe-larger-than=2048
>
> Tbh, I was looking at the history and I can't find a good reason this
> was added. It should be safe to drop this. I would much rather use
> the CONFIG_FRAME_WARN value than override it.
>
> AFAIK most builds use 2048 by default anyways.
I'm fairly sure this was done for 32-bit builds, which default to a lower
warning limit of 1024 bytes and would otherwise run into this
problem when 64-bit platforms don't. With the default warning limit,
clang warns even more about an i386 build:
display/dc/dml/dcn20/display_rq_dlg_calc_20.c:1549:6: error: stack
frame size (1324) exceeds limit (1024) in 'dml20_rq_dlg_get_dlg_reg'
display/dc/dml/dcn20/display_rq_dlg_calc_20v2.c:1550:6: error: stack
frame size (1324) exceeds limit (1024) in 'dml20v2_rq_dlg_get_dlg_reg'
display/dc/dml/dcn30/display_rq_dlg_calc_30.c:1742:6: error: stack
frame size (1484) exceeds limit (1024) in 'dml30_rq_dlg_get_dlg_reg'
display/dc/dml/dcn31/display_rq_dlg_calc_31.c:1571:6: error: stack
frame size (1548) exceeds limit (1024) in 'dml31_rq_dlg_get_dlg_reg'
display/dc/dml/dcn21/display_rq_dlg_calc_21.c:1657:6: error: stack
frame size (1388) exceeds limit (1024) in 'dml21_rq_dlg_get_dlg_reg'
display/dc/dml/dcn32/display_rq_dlg_calc_32.c:206:6: error: stack
frame size (1276) exceeds limit (1024) in 'dml32_rq_dlg_get_dlg_reg'
display/dc/dml/dcn31/display_mode_vba_31.c:2049:13: error: stack frame
size (1468) exceeds limit (1024) in
'DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerformanceCalculation'
display/dc/dml/dcn20/display_mode_vba_20v2.c:1145:13: error: stack
frame size (1228) exceeds limit (1024) in
'dml20v2_DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerformanceCalculation'
display/dc/dml/dcn20/display_mode_vba_20.c:1085:13: error: stack frame
size (1340) exceeds limit (1024) in
'dml20_DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerformanceCalculation'
display/dc/dml/dcn31/display_mode_vba_31.c:3908:6: error: stack frame
size (1996) exceeds limit (1024) in
'dml31_ModeSupportAndSystemConfigurationFull'
display/dc/dml/dcn21/display_mode_vba_21.c:1466:13: error: stack frame
size (1308) exceeds limit (1024) in
'DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerformanceCalculation'
display/dc/dml/dcn20/display_mode_vba_20v2.c:3393:6: error: stack
frame size (1356) exceeds limit (1024) in
'dml20v2_ModeSupportAndSystemConfigurationFull'
display/dc/dml/dcn20/display_mode_vba_20.c:3286:6: error: stack frame
size (1468) exceeds limit (1024) in
'dml20_ModeSupportAndSystemConfigurationFull'
display/dc/dml/dcn21/display_mode_vba_21.c:3518:6: error: stack frame
size (1228) exceeds limit (1024) in
'dml21_ModeSupportAndSystemConfigurationFull'
display/dc/dml/dcn30/display_mode_vba_30.c:1906:13: error: stack frame
size (1436) exceeds limit (1024) in
'DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerformanceCalculation'
display/dc/dml/dcn30/display_mode_vba_30.c:3596:6: error: stack frame
size (2092) exceeds limit (1024) in
'dml30_ModeSupportAndSystemConfigurationFull'
> > I do note that commit 1b54a0121dba ("drm/amd/display: Reduce stack size
> > in the mode support function") did have a workaround for GCC. It appears
> > clang will still inline mode_support_configuration(). If I mark it as
> > 'noinline', the warning disappears in that file.
>
> That'd be the best quick fix. I guess if we split out functions to fix
> stack usage we should mark them as 'noinline' in the future to avoid
> agressive compiler optimizations.
While splitting out sub-functions can help reduce the maximum stack
usage, it seems that in this case it makes the actual problem worse:
I see 2168 bytes for the combined
dml32_ModeSupportAndSystemConfigurationFull(), but marking
mode_support_configuration() as noinline gives me 1992 bytes
for the outer function plus 384 bytes for the inner one. So it does
avoid the warning (barely), but not the problem that the warning tries
to point out.
Arnd
Re: mainline build failure for x86_64 allmodconfig with clang
On Thu, Aug 4, 2022 at 8:52 PM Linus Torvalds
wrote:
>
> On Thu, Aug 4, 2022 at 11:37 AM Sudip Mukherjee (Codethink)
> wrote:cov_trace_cmp
> >
> > git bisect points to 3876a8b5e241 ("drm/amd/display: Enable building new
> > display engine with KCOV enabled").
>
> Ahh. So that was presumably why it was disabled before - because it
> presumably does disgusting things that make KCOV generate even bigger
> stack frames than it already has.
>
> Those functions do seem to have fairly big stack footprints already (I
> didn't try to look into why, I assume it's partly due to aggressive
> inlining, and probably some automatic structures on stack). But gcc
> doesn't seem to make it all that much worse with KCOV (and my clang
> build doesn't enable KCOV).
>
> So it's presumably some KCOV-vs-clang thing. Nathan?
The dependency was originally added to avoid a link failure in 9d1d02ff3678
("drm/amd/display: Don't build DCN1 when kcov is enabled") after I reported the
problem in
https://lists.freedesktop.org/archives/dri-devel/2018-August/186131.html
The commit from the bisection just turns off KCOV for the entire directory
to avoid the link failure, so it's not actually a problem with KCOV vs clang,
but I think a problem with clang vs badly written code that was obscured
in allmodconfig builds prior to this.
The dml30_ModeSupportAndSystemConfigurationFull() function exercises
a few paths in the compiler that are otherwise rare. On thing it does is to
pass up to 60 arguments to other functions, and it heavily uses float and
double variables. Both of these make it rather fragile when it comes to
unusual compiler options, so the files keep coming up whenever a new
instrumentation feature gets added. There is probably some other flag
in allmodconfig that we can disable to improve this again, but I have not
checked this time.
Arnd
Re: [linux-next:master] BUILD REGRESSION 8cb8311e95e3bb58bd84d6350365f14a718faa6d
On Wed, May 25, 2022 at 11:35 PM kernel test robot wrote: > .__mulsi3.o.cmd: No such file or directory > Makefile:686: arch/h8300/Makefile: No such file or directory > Makefile:765: arch/h8300/Makefile: No such file or directory > arch/Kconfig:10: can't open file "arch/h8300/Kconfig" Please stop building h8300 after the asm-generic tree is merged, the architecture is getting removed. Arnd
[PATCH] drm/amd/display: fix apply_degamma_for_user_regamma() warning
From: Arnd Bergmann
It appears that the wrong argument was removed in this call:
drivers/gpu/drm/amd/amdgpu/../display/modules/color/color_gamma.c: In function
'apply_degamma_for_user_regamma':
drivers/gpu/drm/amd/amdgpu/../display/modules/color/color_gamma.c:1694:36:
error: implicit conversion from 'enum ' to 'enum
dc_transfer_func_predefined' [-Werror=enum-conversion]
1694 | build_coefficients(, true);
Fixes: 9b3d76527f6e ("drm/amd/display: Revert adding degamma coefficients")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/modules/color/color_gamma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/modules/color/color_gamma.c
b/drivers/gpu/drm/amd/display/modules/color/color_gamma.c
index 64a38f08f497..4cb6617059ae 100644
--- a/drivers/gpu/drm/amd/display/modules/color/color_gamma.c
+++ b/drivers/gpu/drm/amd/display/modules/color/color_gamma.c
@@ -1691,7 +1691,7 @@ static void apply_degamma_for_user_regamma(struct
pwl_float_data_ex *rgb_regamma
struct pwl_float_data_ex *rgb = rgb_regamma;
const struct hw_x_point *coord_x = coordinates_x;
- build_coefficients(, true);
+ build_coefficients(, TRANSFER_FUNCTION_SRGB);
i = 0;
while (i != hw_points_num + 1) {
--
2.29.2
[PATCH] drm/amdgpu: fix warning for overflow check
From: Arnd Bergmann
The overflow check in amdgpu_bo_list_create() causes a warning with
clang-14 on 64-bit architectures, since the limit can never be
exceeded.
drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c:74:18: error: result of comparison
of constant 256204778801521549 with expression of type 'unsigned int' is always
false [-Werror,-Wtautological-constant-out-of-range-compare]
if (num_entries > (SIZE_MAX - sizeof(struct amdgpu_bo_list))
~~~ ^ ~~
The check remains useful for 32-bit architectures, so just avoid the
warning by using size_t as the type for the count.
Fixes: 920990cb080a ("drm/amdgpu: allocate the bo_list array after the list")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
index 15c45b2a3983..714178f1b6c6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
@@ -61,7 +61,7 @@ static void amdgpu_bo_list_free(struct kref *ref)
int amdgpu_bo_list_create(struct amdgpu_device *adev, struct drm_file *filp,
struct drm_amdgpu_bo_list_entry *info,
- unsigned num_entries, struct amdgpu_bo_list **result)
+ size_t num_entries, struct amdgpu_bo_list **result)
{
unsigned last_entry = 0, first_userptr = num_entries;
struct amdgpu_bo_list_entry *array;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.h
index c905a4cfc173..044b41f0bfd9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.h
@@ -61,7 +61,7 @@ int amdgpu_bo_create_list_entry_array(struct
drm_amdgpu_bo_list_in *in,
int amdgpu_bo_list_create(struct amdgpu_device *adev,
struct drm_file *filp,
struct drm_amdgpu_bo_list_entry *info,
-unsigned num_entries,
+size_t num_entries,
struct amdgpu_bo_list **list);
static inline struct amdgpu_bo_list_entry *
--
2.29.2
[PATCH] gpu: amd: replace open-coded offsetof() with builtin
From: Arnd Bergmann The two AMD drivers have their own custom offsetof() implementation that now triggers a warning with recent versions of clang: drivers/gpu/drm/radeon/radeon_atombios.c:133:14: error: performing pointer subtraction with a null pointer has undefined behavior [-Werror,-Wnull-pointer-subtraction] Change all the instances to use the normal offsetof() provided by the kernel that does not have this problem. Signed-off-by: Arnd Bergmann --- drivers/gpu/drm/amd/display/dc/bios/command_table2.c | 4 +--- drivers/gpu/drm/amd/include/atombios.h| 2 +- drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomfwctrl.h | 4 ++-- drivers/gpu/drm/radeon/atombios.h | 2 +- 4 files changed, 5 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/bios/command_table2.c b/drivers/gpu/drm/amd/display/dc/bios/command_table2.c index f1f672a997d7..4f37be727332 100644 --- a/drivers/gpu/drm/amd/display/dc/bios/command_table2.c +++ b/drivers/gpu/drm/amd/display/dc/bios/command_table2.c @@ -44,9 +44,7 @@ bp->base.ctx->logger #define GET_INDEX_INTO_MASTER_TABLE(MasterOrData, FieldName)\ - (((char *)(&((\ - struct atom_master_list_of_##MasterOrData##_functions_v2_1 *)0)\ - ->FieldName)-(char *)0)/sizeof(uint16_t)) + (offsetof(struct atom_master_list_of_##MasterOrData##_functions_v2_1, FieldName) / sizeof(uint16_t)) #define EXEC_BIOS_CMD_TABLE(fname, params)\ (amdgpu_atom_execute_table(((struct amdgpu_device *)bp->base.ctx->driver_context)->mode_info.atom_context, \ diff --git a/drivers/gpu/drm/amd/include/atombios.h b/drivers/gpu/drm/amd/include/atombios.h index 6a505d1b82a5..da895d1f3b4f 100644 --- a/drivers/gpu/drm/amd/include/atombios.h +++ b/drivers/gpu/drm/amd/include/atombios.h @@ -7148,7 +7148,7 @@ typedef struct _ATOM_ASIC_INTERNAL_SS_INFO_V3 #define GET_COMMAND_TABLE_COMMANDSET_REVISION(TABLE_HEADER_OFFSET) (((static_cast(TABLE_HEADER_OFFSET))->ucTableFormatRevision )&0x3F) #define GET_COMMAND_TABLE_PARAMETER_REVISION(TABLE_HEADER_OFFSET) (((static_cast(TABLE_HEADER_OFFSET))->ucTableContentRevision)&0x3F) #else // not __cplusplus -#define GetIndexIntoMasterTable(MasterOrData, FieldName) (((char*)(&((ATOM_MASTER_LIST_OF_##MasterOrData##_TABLES*)0)->FieldName)-(char*)0)/sizeof(USHORT)) +#define GetIndexIntoMasterTable(MasterOrData, FieldName) (offsetof(ATOM_MASTER_LIST_OF_##MasterOrData##_TABLES, FieldName) / sizeof(USHORT)) #define GET_COMMAND_TABLE_COMMANDSET_REVISION(TABLE_HEADER_OFFSET) ATOM_COMMON_TABLE_HEADER*)TABLE_HEADER_OFFSET)->ucTableFormatRevision)&0x3F) #define GET_COMMAND_TABLE_PARAMETER_REVISION(TABLE_HEADER_OFFSET) ATOM_COMMON_TABLE_HEADER*)TABLE_HEADER_OFFSET)->ucTableContentRevision)&0x3F) diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomfwctrl.h b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomfwctrl.h index b7e2651b570b..2fc1733bcdcf 100644 --- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomfwctrl.h +++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomfwctrl.h @@ -29,9 +29,9 @@ typedef enum atom_smu9_syspll0_clock_id BIOS_CLKID; #define GetIndexIntoMasterCmdTable(FieldName) \ - (((char*)(&((struct atom_master_list_of_command_functions_v2_1*)0)->FieldName)-(char*)0)/sizeof(uint16_t)) + (offsetof(struct atom_master_list_of_command_functions_v2_1, FieldName) / sizeof(uint16_t)) #define GetIndexIntoMasterDataTable(FieldName) \ - (((char*)(&((struct atom_master_list_of_data_tables_v2_1*)0)->FieldName)-(char*)0)/sizeof(uint16_t)) + (offsetof(struct atom_master_list_of_data_tables_v2_1, FieldName) / sizeof(uint16_t)) #define PP_ATOMFWCTRL_MAX_VOLTAGE_ENTRIES 32 diff --git a/drivers/gpu/drm/radeon/atombios.h b/drivers/gpu/drm/radeon/atombios.h index 83e8b8547f9b..bd5dc09e860f 100644 --- a/drivers/gpu/drm/radeon/atombios.h +++ b/drivers/gpu/drm/radeon/atombios.h @@ -5983,7 +5983,7 @@ typedef struct _ATOM_ASIC_INTERNAL_SS_INFO_V3 #define GET_COMMAND_TABLE_COMMANDSET_REVISION(TABLE_HEADER_OFFSET) (((static_cast(TABLE_HEADER_OFFSET))->ucTableFormatRevision )&0x3F) #define GET_COMMAND_TABLE_PARAMETER_REVISION(TABLE_HEADER_OFFSET) (((static_cast(TABLE_HEADER_OFFSET))->ucTableContentRevision)&0x3F) #else // not __cplusplus -#defineGetIndexIntoMasterTable(MasterOrData, FieldName) (((char*)(&((ATOM_MASTER_LIST_OF_##MasterOrData##_TABLES*)0)->FieldName)-(char*)0)/sizeof(USHORT)) +#defineGetIndexIntoMasterTable(MasterOrData, FieldName) (offsetof(ATOM_MASTER_LIST_OF_##MasterOrData##_TABLES, FieldName)/sizeof(USHORT)) #define GET_COMMAND_TABLE_COMMANDSET_REVISION(TABLE_HEADER_OFFSET) ATOM_COMMON_TABLE_HEADER*)TABLE_HEADER_OFFSET)->ucTableFormatRevision)&0x3F) #define GET_COMMAND_TABLE_PARAMETER_REVISION(TABLE_HEADER_OFFSET) ATOM_COMMON_TABLE_HEADER*)TABLE_HEADER_OFFSET)->ucTableContentRevision)&0x3F) -- 2.29.2
[PATCH] drm/amdgpu: fix clang out-of-range warning
From: Arnd Bergmann
clang-14 points out that comparing an 'unsigned int' against a large
64-bit constantn is pointless:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1206:18: error: result of comparison
of constant 4294967296 with expression of type 'resource_size_t' (aka 'unsigned
int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
res->start > 0x1ull)
Rephrase the comparison using the upper_32_bits() macro, which should
keep it legible while avoiding the warning.
Fixes: 31b8adab3247 ("drm/amdgpu: require a root bus window above 4GB for BAR
resize")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index ab3794c42d36..741a55031ca1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1203,7 +1203,7 @@ int amdgpu_device_resize_fb_bar(struct amdgpu_device
*adev)
pci_bus_for_each_resource(root, res, i) {
if (res && res->flags & (IORESOURCE_MEM | IORESOURCE_MEM_64) &&
- res->start > 0x1ull)
+ upper_32_bits(res->start) != 0)
break;
}
--
2.29.2
[PATCH] [RESEND] drm/amdgpu: fix enum odm_combine_mode mismatch
From: Arnd Bergmann
A conversion from 'bool' to 'enum odm_combine_mode' was incomplete,
and gcc warns about this with many instances of
display/dc/dml/dcn20/display_mode_vba_20.c:3899:44: warning: implicit
conversion from 'enum ' to 'enum
odm_combine_mode' [-Wenum-conversion]
3899 | locals->ODMCombineEnablePerState[i][k] = false;
Change the ones that we get a warning for, using the same numerical
values to leave the behavior unchanged.
Fixes: 5fc11598166d ("drm/amd/display: expand dml structs")
Link: https://lore.kernel.org/all/20201026210039.3884312-3-a...@kernel.org/
Signed-off-by: Arnd Bergmann
---
I cannot tell if this is the correct conversion, please review
carefully.
Tested on v5.15-rc2, please just ignore if a patch is already pending
for v5.15.
I got now reply to this patch when I originally sent it. With -Werror
being the default now, it is still needed to make the driver build, please
have another look.
---
.../amd/display/dc/dml/dcn20/display_mode_vba_20.c | 8
.../amd/display/dc/dml/dcn20/display_mode_vba_20v2.c | 10 +-
.../amd/display/dc/dml/dcn21/display_mode_vba_21.c | 12 ++--
3 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20.c
index f34bc3c8da41..69c41e3e3ba2 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20.c
@@ -3901,14 +3901,14 @@ void dml20_ModeSupportAndSystemConfigurationFull(struct
display_mode_lib *mode_l
mode_lib->vba.PlaneRequiredDISPCLKWithODMCombine = mode_lib->vba.PixelClock[k]
/ 2
* (1 +
mode_lib->vba.DISPCLKDPPCLKDSCCLKDownSpreading / 100.0);
- locals->ODMCombineEnablePerState[i][k] = false;
+ locals->ODMCombineEnablePerState[i][k] =
dm_odm_combine_mode_disabled;
mode_lib->vba.PlaneRequiredDISPCLK =
mode_lib->vba.PlaneRequiredDISPCLKWithoutODMCombine;
if (mode_lib->vba.ODMCapability) {
if
(locals->PlaneRequiredDISPCLKWithoutODMCombine >
mode_lib->vba.MaxDispclkRoundedDownToDFSGranularity) {
-
locals->ODMCombineEnablePerState[i][k] = true;
+
locals->ODMCombineEnablePerState[i][k] = dm_odm_combine_mode_2to1;
mode_lib->vba.PlaneRequiredDISPCLK =
mode_lib->vba.PlaneRequiredDISPCLKWithODMCombine;
} else if (locals->HActive[k] >
DCN20_MAX_420_IMAGE_WIDTH && locals->OutputFormat[k] == dm_420) {
-
locals->ODMCombineEnablePerState[i][k] = true;
+
locals->ODMCombineEnablePerState[i][k] = dm_odm_combine_mode_2to1;
mode_lib->vba.PlaneRequiredDISPCLK =
mode_lib->vba.PlaneRequiredDISPCLKWithODMCombine;
}
}
@@ -3961,7 +3961,7 @@ void dml20_ModeSupportAndSystemConfigurationFull(struct
display_mode_lib *mode_l
locals->RequiredDISPCLK[i][j] = 0.0;
locals->DISPCLK_DPPCLK_Support[i][j] = true;
for (k = 0; k <=
mode_lib->vba.NumberOfActivePlanes - 1; k++) {
- locals->ODMCombineEnablePerState[i][k]
= false;
+ locals->ODMCombineEnablePerState[i][k]
= dm_odm_combine_mode_disabled;
if (locals->SwathWidthYSingleDPP[k] <=
locals->MaximumSwathWidth[k]) {
locals->NoOfDPP[i][j][k] = 1;
locals->RequiredDPPCLK[i][j][k]
= locals->MinDPPCLKUsingSingleDPP[k]
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20v2.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20v2.c
index 719949ad49ed..3c8c03496611 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20v2.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20v2.c
@@ -4012,17 +4012,17 @@ void
dml20v2_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode
mode_lib->vba.PlaneRequiredDISPCLKWithODMCombine = mode_lib->vba.PixelClock[k]
/ 2
* (1 +
mode_lib->vba.DISPCLKDPPCLKDSCCLKDownSpreadin
Re: [PATCH] Enable '-Werror' by default for all kernel builds
On Wed, Sep 8, 2021 at 10:55 PM Nathan Chancellor wrote: > On Tue, Sep 07, 2021 at 11:11:17AM +0200, Arnd Bergmann wrote: > > On Tue, Sep 7, 2021 at 4:32 AM Nathan Chancellor wrote: function 'rtw_aes_decrypt' [-Werror,-Wframe-larger-than] > > > arm32-fedora.log: > > > drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:3043:6: error: > > > stack frame size (1376) exceeds limit (1024) in function 'bw_calcs' > > > [-Werror,-Wframe-larger-than] > > > arm32-fedora.log: > > > drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:77:13: error: > > > stack frame size (5384) exceeds limit (1024) in function > > > 'calculate_bandwidth' [-Werror,-Wframe-larger-than] > > > > > > Aside from the dce_calcs.c warnings, these do not seem too bad. I > > > believe allmodconfig turns on UBSAN but it could also be aggressive > > > inlining by clang. I intend to look at all -Wframe-large-than warnings > > > closely later. > > > > I've had them close to zero in the past, but a couple of new ones came in. > > > > The amdgpu ones are probably not fixable unless they stop using 64-bit > > floats in the kernel for > > random calculations. The crypto/* ones tend to be compiler bugs, but hard > > to fix > > I have started taking a look at these. Most of the allmodconfig ones > appear to be related to CONFIG_KASAN, which is now supported for > CONFIG_ARM. > > The two in bpmp-debugfs.c appear regardless of CONFIG_KASAN and it turns > out that you actually submitted a patch for these: > > https://lore.kernel.org/r/20201204193714.3134651-1-a...@kernel.org/ > > Is it worth resending or pinging that? I'm now restarting from a clean tree for my randconfig patches to see which ones are actually needed, will hopefully get to that. > The dce_calcs.c ones also appear without CONFIG_KASAN, which you noted > is probably unavoidable. (adding amdgpu folks to Cc here) Harry Wentland did a nice rework for dcn_calcs.c that should also be portable to dce_calcs.c, I hope that he will be able to get to that as well. Looking at my older patches now, I found that I had only suppressed that one and given up fixing it, but I did put my analysis into https://bugs.llvm.org/show_bug.cgi?id=42551, which should be helpful for addressing it in either the kernel or the compiler. Arnd
[PATCH] drm/amd/display: fix empty debug macros
From: Arnd Bergmann
Using an empty macro expansion as a conditional expression
produces a W=1 warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.c: In function
'dce_aux_transfer_with_retries':
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.c:775:156: error: suggest
braces around empty body in an 'if' statement [-Werror=empty-body]
775 |
"dce_aux_transfer_with_retries: AUX_RET_SUCCESS:
AUX_TRANSACTION_REPLY_I2C_OVER_AUX_DEFER");
|
^
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.c:783:155: error: suggest
braces around empty body in an 'if' statement [-Werror=empty-body]
783 |
"dce_aux_transfer_with_retries: AUX_RET_SUCCESS:
AUX_TRANSACTION_REPLY_I2C_OVER_AUX_NACK");
|
^
Expand it to "do { } while (0)" instead to make the expression
more robust and avoid the warning.
Fixes: 56aca2309301 ("drm/amd/display: Add AUX I2C tracing.")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/dc/dce/dce_aux.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
index e14f99b4b0c3..3c3347341103 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
@@ -42,7 +42,7 @@
#define DC_LOGGER \
engine->ctx->logger
-#define DC_TRACE_LEVEL_MESSAGE(...) /* do nothing */
+#define DC_TRACE_LEVEL_MESSAGE(...) do { } while (0)
#define IS_DC_I2CAUX_LOGGING_ENABLED() (false)
#define LOG_FLAG_Error_I2cAux LOG_ERROR
#define LOG_FLAG_I2cAux_DceAux LOG_I2C_AUX
@@ -76,7 +76,7 @@ enum {
#define DEFAULT_AUX_ENGINE_MULT 0
#define DEFAULT_AUX_ENGINE_LENGTH 69
-#define DC_TRACE_LEVEL_MESSAGE(...) /* do nothing */
+#define DC_TRACE_LEVEL_MESSAGE(...) do { } while (0)
static void release_engine(
struct dce_aux *engine)
--
2.29.2
Re: [PATCH] drm/amd/display: Reduce stack size for dml21_ModeSupportAndSystemConfigurationFull
On Tue, Sep 14, 2021 at 11:05 PM 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. I suspect it's not the Pipe struct but rather the way that you call another function with a crazy number of arguments here. After your change, this likely gets inlined and you avoid the problem, so the patch ends up doing the right thing. If you do more patches like this, I would suggest mentioning the new stack usage of the calling function and the new noinline function, to make sure that the combined number isn't actually worse than the old number. You can get these numbers by recompiling the file with the frame size warning set to a low value, e.g. adding -Wframe-larger-than=100 to the command line. Acked-by: Arnd Bergmann
Re: [PATCH] Enable '-Werror' by default for all kernel builds
On Thu, Sep 9, 2021 at 1:43 PM Marco Elver wrote: > On Thu, 9 Sept 2021 at 13:00, Arnd Bergmann wrote: > > On Thu, Sep 9, 2021 at 12:54 PM Marco Elver wrote: > > > On Thu, 9 Sept 2021 at 07:59, Christoph Hellwig > > > wrote: > > > > On Wed, Sep 08, 2021 at 11:58:56PM +0200, Marco Elver wrote: > > > > > It'd be good to avoid. It has helped uncover build issues with KASAN > > > > > in > > > > > the past. Or at least make it dependent on the problematic > > > > > architecture. > > > > > For example if arm is a problem, something like this: > > > > > > > > I'm also seeing quite a few stack size warnings with KASAN on x86_64 > > > > without COMPILT_TEST using gcc 10.2.1 from Debian. In fact there are a > > > > few warnings without KASAN, but with KASAN there are a lot more. > > > > I'll try to find some time to dig into them. > > > > > > Right, this reminded me that we actually at least double the real > > > stack size for KASAN builds, because it inherently requires more stack > > > space. I think we need Wframe-larger-than to match that, otherwise > > > we'll just keep having this problem: > > > > > > https://lkml.kernel.org/r/20210909104925.809674-1-el...@google.com > > > > The problem with this is that it completely defeats the point of the > > stack size warnings in allmodconfig kernels when they have KASAN > > enabled and end up missing obvious code bugs in drivers that put > > large structures on the stack. Let's not go there. > > Sure, but the reality is that the real stack size is already doubled > for KASAN. And that should be reflected in Wframe-larger-than. I don't think "double" is an accurate description of what is going on, it's much more complex than this. There are some functions that completely explode with KASAN_STACK enabled on clang, and many other functions instances that don't grow much at all. I've been building randconfig kernels for a long time with KASAN_STACK enabled on gcc, and the limit increased to 1440 bytes for 32-bit and not increased beyond the normal 2048 bytes for 64-bit. I have some patches to address the outliers and should go through and resend some of those. With the same limits and patches using clang, and KASAN=y but KASAN_STACK=n I also get no warnings in randconfig builds, but KASAN_STACK on clang doesn't really seem to have a good limit that would make an allmodconfig kernel build with no warnings. These are the worst offenders I see based on configuration, using an 32-bit ARM allmodconfig with my fixups: gcc-11, KASAN, no KASAN_STACK, FRAME_WARN=1024: (nothing) gcc-11, KASAN_STACK: drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c:782:1: warning: the frame size of 1416 bytes is larger than 1024 bytes [-Wframe-larger-than=] drivers/media/dvb-frontends/mxl5xx.c:1575:1: warning: the frame size of 1240 bytes is larger than 1024 bytes [-Wframe-larger-than=] drivers/mtd/nftlcore.c:468:1: warning: the frame size of 1232 bytes is larger than 1024 bytes [-Wframe-larger-than=] drivers/char/ipmi/ipmi_msghandler.c:4880:1: warning: the frame size of 1232 bytes is larger than 1024 bytes [-Wframe-larger-than=] drivers/mtd/chips/cfi_cmdset_0001.c:1870:1: warning: the frame size of 1224 bytes is larger than 1024 bytes [-Wframe-larger-than=] drivers/net/wireless/ath/ath9k/ar9003_paprd.c:749:1: warning: the frame size of 1216 bytes is larger than 1024 bytes [-Wframe-larger-than=] drivers/net/ethernet/mellanox/mlx5/core/ipoib/ipoib.c:136:1: warning: the frame size of 1216 bytes is larger than 1024 bytes [-Wframe-larger-than=] drivers/ntb/hw/idt/ntb_hw_idt.c:1116:1: warning: the frame size of 1200 bytes is larger than 1024 bytes [-Wframe-larger-than=] net/dcb/dcbnl.c:1172:1: warning: the frame size of 1192 bytes is larger than 1024 bytes [-Wframe-larger-than=] fs/select.c:1042:1: warning: the frame size of 1192 bytes is larger than 1024 bytes [-Wframe-larger-than=] clang-12 KASAN, no KASAN_STACK, FRAME_WARN=1024: kernel/trace/trace_events_hist.c:4601:13: error: stack frame size 1384 exceeds limit 1024 in function 'hist_trigger_print_key' [-Werror,-Wframe-larger-than] drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:3045:6: error: stack frame size 1384 exceeds limit 1024 in function 'bw_calcs' [-Werror,-Wframe-larger-than] drivers/staging/fbtft/fbtft-core.c:992:5: error: stack frame size 1208 exceeds limit 1024 in function 'fbtft_init_display' [-Werror,-Wframe-larger-than] crypto/wp512.c:782:13: error: stack frame size 1176 exceeds limit 1024 in function 'wp512_process_buffer' [-Werror,-Wframe-larger-than] drivers/staging/fbtft/fbtft-core.c:902:12: error: stack frame size 1080 exceeds limit 1024 in function 'fbtft_init_display_from_property' [-Werror,-Wfra
Re: [PATCH] Enable '-Werror' by default for all kernel builds
On Thu, Sep 9, 2021 at 12:54 PM Marco Elver wrote: > On Thu, 9 Sept 2021 at 07:59, Christoph Hellwig wrote: > > On Wed, Sep 08, 2021 at 11:58:56PM +0200, Marco Elver wrote: > > > It'd be good to avoid. It has helped uncover build issues with KASAN in > > > the past. Or at least make it dependent on the problematic architecture. > > > For example if arm is a problem, something like this: > > > > I'm also seeing quite a few stack size warnings with KASAN on x86_64 > > without COMPILT_TEST using gcc 10.2.1 from Debian. In fact there are a > > few warnings without KASAN, but with KASAN there are a lot more. > > I'll try to find some time to dig into them. > > Right, this reminded me that we actually at least double the real > stack size for KASAN builds, because it inherently requires more stack > space. I think we need Wframe-larger-than to match that, otherwise > we'll just keep having this problem: > > https://lkml.kernel.org/r/20210909104925.809674-1-el...@google.com The problem with this is that it completely defeats the point of the stack size warnings in allmodconfig kernels when they have KASAN enabled and end up missing obvious code bugs in drivers that put large structures on the stack. Let's not go there. Arnd
[PATCH] amdgpu: securedisplay: simplify i2c hexdump output
From: Arnd Bergmann
A previous fix I did left a rather complicated loop in
amdgpu_securedisplay_debugfs_write() for what could be expressed in a
simple sprintf, as Rasmus pointed out.
This drops the leading 0x for each byte, but is otherwise
much nicer.
Suggested-by: Rasmus Villemoes
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c
index 69d7f6bff5d4..fc3ddd7aa6f0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c
@@ -92,9 +92,7 @@ static ssize_t amdgpu_securedisplay_debugfs_write(struct file
*f, const char __u
struct drm_device *dev = adev_to_drm(adev);
uint32_t phy_id;
uint32_t op;
- int i;
char str[64];
- char i2c_output[256];
int ret;
if (*pos || size > sizeof(str) - 1)
@@ -136,12 +134,9 @@ static ssize_t amdgpu_securedisplay_debugfs_write(struct
file *f, const char __u
ret = psp_securedisplay_invoke(psp,
TA_SECUREDISPLAY_COMMAND__SEND_ROI_CRC);
if (!ret) {
if (securedisplay_cmd->status ==
TA_SECUREDISPLAY_STATUS__SUCCESS) {
- int pos = 0;
- memset(i2c_output, 0, sizeof(i2c_output));
- for (i = 0; i <
TA_SECUREDISPLAY_I2C_BUFFER_SIZE; i++)
- pos += sprintf(i2c_output + pos, "
0x%X",
-
securedisplay_cmd->securedisplay_out_message.send_roi_crc.i2c_buf[i]);
- dev_info(adev->dev, "SECUREDISPLAY: I2C buffer
out put is :%s\n", i2c_output);
+ dev_info(adev->dev, "SECUREDISPLAY: I2C buffer
out put is: %*ph\n",
+TA_SECUREDISPLAY_I2C_BUFFER_SIZE,
+
securedisplay_cmd->securedisplay_out_message.send_roi_crc.i2c_buf);
} else {
psp_securedisplay_parse_resp_status(psp,
securedisplay_cmd->status);
}
--
2.29.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] amdgpu: fix gcc -Wrestrict warning
On Tue, Mar 23, 2021 at 4:57 PM Rasmus Villemoes
wrote:
> On 23/03/2021 14.04, Arnd Bergmann wrote:
> > if (securedisplay_cmd->status ==
> > TA_SECUREDISPLAY_STATUS__SUCCESS) {
> > + int pos = 0;
> > memset(i2c_output, 0, sizeof(i2c_output));
> > for (i = 0; i <
> > TA_SECUREDISPLAY_I2C_BUFFER_SIZE; i++)
> > - sprintf(i2c_output, "%s 0x%X",
> > i2c_output,
> > + pos += sprintf(i2c_output + pos, "
> > 0x%X",
> >
> > securedisplay_cmd->securedisplay_out_message.send_roi_crc.i2c_buf[i]);
> > dev_info(adev->dev, "SECUREDISPLAY: I2C
> > buffer out put is :%s\n", i2c_output);
>
> Eh, why not get rid of the 256 byte stack allocation and just replace
> all of this by
>
> dev_info(adev->dev, ""SECUREDISPLAY: I2C buffer out put is: %*ph\n",
> TA_SECUREDISPLAY_I2C_BUFFER_SIZE,
> securedisplay_cmd->securedisplay_out_message.send_roi_crc.i2c_buf);
>
> That's much less code (both in #LOC and .text), and avoids adding yet
> another place that will be audited over and over for "hm, yeah, that
> sprintf() is actually not gonna overflow".
>
> Yeah, it'll lose the 0x prefixes for each byte and use lowercase hex chars.
Ah, I didn't know the kernel's sprintf could do that, that's really nice.
I'll send a follow-up patch, as Alex has already applied the first one.
Alex, feel free to merge the two into one, or just keep as they are.
Arnd
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] amdgpu: fix gcc -Wrestrict warning
From: Arnd Bergmann
gcc warns about an sprintf() that uses the same buffer as source
and destination, which is undefined behavior in C99:
drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c: In function
'amdgpu_securedisplay_debugfs_write':
drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c:141:6: error: 'sprintf'
argument 3 overlaps destination object 'i2c_output' [-Werror=restrict]
141 | sprintf(i2c_output, "%s 0x%X", i2c_output,
| ^~
142 |
securedisplay_cmd->securedisplay_out_message.send_roi_crc.i2c_buf[i]);
|
~
drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c:97:7: note: destination
object referenced by 'restrict'-qualified argument 1 was declared here
97 | char i2c_output[256];
| ^~
Rewrite it to remember the current offset into the buffer instead.
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c
index 834440ab9ff7..69d7f6bff5d4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c
@@ -136,9 +136,10 @@ static ssize_t amdgpu_securedisplay_debugfs_write(struct
file *f, const char __u
ret = psp_securedisplay_invoke(psp,
TA_SECUREDISPLAY_COMMAND__SEND_ROI_CRC);
if (!ret) {
if (securedisplay_cmd->status ==
TA_SECUREDISPLAY_STATUS__SUCCESS) {
+ int pos = 0;
memset(i2c_output, 0, sizeof(i2c_output));
for (i = 0; i <
TA_SECUREDISPLAY_I2C_BUFFER_SIZE; i++)
- sprintf(i2c_output, "%s 0x%X",
i2c_output,
+ pos += sprintf(i2c_output + pos, "
0x%X",
securedisplay_cmd->securedisplay_out_message.send_roi_crc.i2c_buf[i]);
dev_info(adev->dev, "SECUREDISPLAY: I2C buffer
out put is :%s\n", i2c_output);
} else {
--
2.29.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] amdgpu: avoid incorrect %hu format string
From: Arnd Bergmann
clang points out that the %hu format string does not match the type
of the variables here:
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:263:7: warning: format specifies type
'unsigned short' but the argument has type 'unsigned int' [-Wformat]
version_major, version_minor);
^
include/drm/drm_print.h:498:19: note: expanded from macro 'DRM_ERROR'
__drm_err(fmt, ##__VA_ARGS__)
~~~^~~
Change it to a regular %u, the same way a previous patch did for
another instance of the same warning.
Fixes: 0b437e64e0af ("drm/amdgpu: remove h from printk format specifier")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
index e2ed4689118a..c6dbc0801604 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
@@ -259,7 +259,7 @@ int amdgpu_uvd_sw_init(struct amdgpu_device *adev)
if ((adev->asic_type == CHIP_POLARIS10 ||
adev->asic_type == CHIP_POLARIS11) &&
(adev->uvd.fw_version < FW_1_66_16))
- DRM_ERROR("POLARIS10/11 UVD firmware version %hu.%hu is
too old.\n",
+ DRM_ERROR("POLARIS10/11 UVD firmware version %u.%u is
too old.\n",
version_major, version_minor);
} else {
unsigned int enc_major, enc_minor, dec_minor;
--
2.29.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 1/1] drm/amdkfd: fix build error with AMD_IOMMU_V2=m
On Tue, Mar 9, 2021 at 7:34 PM Christian König wrote: > Am 09.03.21 um 18:59 schrieb Alex Deucher: > > There has been quite some effort for this already for generic PASID > interface etc.. But it looks like that effort is stalled by now. > > Anyway at least I'm perfectly fine to have the IOMMUv2 || !IOMMUv2 > dependency on the core amdgpu driver for x86. > > That should solve the build problem at hand quite nicely. Right, that sounds better than the IS_REACHABLE() hack, and would fix the immediate build regression until the driver is changed to use the proper IOMMU interfaces. Arnd ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 1/1] drm/amdkfd: fix build error with AMD_IOMMU_V2=m
On Tue, Mar 9, 2021 at 4:23 AM Felix Kuehling wrote: > > Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link > against the exported functions. If the GPU driver is built-in but the > IOMMU driver is a loadable module, the kfd_iommu.c file is indeed > built but does not work: > > x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function > `kfd_iommu_bind_process_to_device': > kfd_iommu.c:(.text+0x516): undefined reference to `amd_iommu_bind_pasid' > x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function > `kfd_iommu_unbind_process': > kfd_iommu.c:(.text+0x691): undefined reference to `amd_iommu_unbind_pasid' > x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function > `kfd_iommu_suspend': > kfd_iommu.c:(.text+0x966): undefined reference to > `amd_iommu_set_invalidate_ctx_cb' > x86_64-linux-ld: kfd_iommu.c:(.text+0x97f): undefined reference to > `amd_iommu_set_invalid_ppr_cb' > x86_64-linux-ld: kfd_iommu.c:(.text+0x9a4): undefined reference to > `amd_iommu_free_device' > x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function > `kfd_iommu_resume': > kfd_iommu.c:(.text+0xa9a): undefined reference to `amd_iommu_init_device' > x86_64-linux-ld: kfd_iommu.c:(.text+0xadc): undefined reference to > `amd_iommu_set_invalidate_ctx_cb' > x86_64-linux-ld: kfd_iommu.c:(.text+0xaff): undefined reference to > `amd_iommu_set_invalid_ppr_cb' > x86_64-linux-ld: kfd_iommu.c:(.text+0xc72): undefined reference to > `amd_iommu_bind_pasid' > x86_64-linux-ld: kfd_iommu.c:(.text+0xe08): undefined reference to > `amd_iommu_set_invalidate_ctx_cb' > x86_64-linux-ld: kfd_iommu.c:(.text+0xe26): undefined reference to > `amd_iommu_set_invalid_ppr_cb' > x86_64-linux-ld: kfd_iommu.c:(.text+0xe42): undefined reference to > `amd_iommu_free_device' > > Use IS_REACHABLE to only build IOMMU-V2 support if the amd_iommu symbols > are reachable by the amdkfd driver. Output a warning if they are not, > because that may not be what the user was expecting. This would fix the compile-time failure, but it still fails my CI because you introduce a compile-time warning. Can you change it into a runtime warning instead? Neither type of warning is likely to actually reach the person trying to debug the problem, so you still end up with machines that don't do what they should, but I can live with the runtime warning as long as the build doesn't break. I think the proper fix would be to not rely on custom hooks into a particular IOMMU driver, but to instead ensure that the amdgpu driver can do everything it needs through the regular linux/iommu.h interfaces. I realize this is more work, but I wonder if you've tried that, and why it didn't work out. Arnd ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] [variant b] drm/amdkfd: fix build error with missing AMD_IOMMU_V2
From: Arnd Bergmann
Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link
against the exported functions. If the GPU driver is built-in but the
IOMMU driver is a loadable module, the kfd_iommu.c file is indeed
built but does not work:
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_bind_process_to_device':
kfd_iommu.c:(.text+0x516): undefined reference to `amd_iommu_bind_pasid'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_unbind_process':
kfd_iommu.c:(.text+0x691): undefined reference to `amd_iommu_unbind_pasid'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_suspend':
kfd_iommu.c:(.text+0x966): undefined reference to
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0x97f): undefined reference to
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0x9a4): undefined reference to
`amd_iommu_free_device'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_resume':
kfd_iommu.c:(.text+0xa9a): undefined reference to `amd_iommu_init_device'
x86_64-linux-ld: kfd_iommu.c:(.text+0xadc): undefined reference to
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xaff): undefined reference to
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xc72): undefined reference to
`amd_iommu_bind_pasid'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe08): undefined reference to
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe26): undefined reference to
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe42): undefined reference to
`amd_iommu_free_device'
Change the 'imply' to a weak dependency that still allows compiling
in all other configurations but disallows the configuration that
causes a link failure.
Fixes: 64d1c3a43a6f ("drm/amdkfd: Centralize IOMMUv2 code and make it
conditional")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/amdkfd/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/Kconfig
b/drivers/gpu/drm/amd/amdkfd/Kconfig
index f02c938f75da..d01dba2af3bb 100644
--- a/drivers/gpu/drm/amd/amdkfd/Kconfig
+++ b/drivers/gpu/drm/amd/amdkfd/Kconfig
@@ -6,7 +6,7 @@
config HSA_AMD
bool "HSA kernel driver for AMD GPU devices"
depends on DRM_AMDGPU && (X86_64 || ARM64 || PPC64)
- imply AMD_IOMMU_V2 if X86_64
+ depends on AMD_IOMMU_V2=y || DRM_AMDGPU=m
select HMM_MIRROR
select MMU_NOTIFIER
select DRM_AMDGPU_USERPTR
--
2.29.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdkfd: fix build error with missing AMD_IOMMU_V2
On Mon, Mar 8, 2021 at 9:12 PM Christian König wrote: > Am 08.03.21 um 21:02 schrieb Felix Kuehling: > > Am 2021-03-08 um 2:33 p.m. schrieb Arnd Bergmann: > > I don't want to create a hard dependency on AMD_IOMMU_V2 if I can avoid > > it, because it is only really needed for a small number of AMD APUs, and > > even there it is now optional for more recent ones. > > > > Is there a better way to avoid build failures without creating a hard > > dependency? > > What you need is the same trick we used for AGP on radeon/nouveau: > > depends on AMD_IOMMU_V2 || !AMD_IOMMU_V2 > > This way when AMD_IOMMU_V2 is build as a module DRM_AMDGPU will be build > as a module as well. When it is disabled completely we don't care. Note that this trick only works if you put it into the DRM_AMDGPU Kconfig option itself, since that decides if the driver is built-in or a loadable module. If HSA_AMD is disabled, that dependency is not really necessary. The version I suggested -- adding "depends on AMD_IOMMU_V2=y || DRM_AMDGPU=m" to the HSA_AMD option -- might be slightly nicer since it lets you still build a kernel with DRM_AMDGPU=y and AMD_IOMMU_V2=m, but without the HSA_AMD. I can send a patch with either of those two options to replace my original patch. > >The documentation in > > Documentation/kbuild/kconfig-language.rst suggests using if > > (IS_REACHABLE(CONFIG_AMD_IOMMU_V2)) to guard those problematic function > > calls. I think more generally, we could guard all of kfd_iommu.c with > > > > #if IS_REACHABLE(CONFIG_AMD_IOMMU_V2) > > > > And use the same condition to define the stubs in kfd_iommu.h. This would fix the compile-time error, but it's also the one I'd least recommend out of all the options, because that causes the driver to silently not work as expected. This seems even worse than failing the build. Arnd ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdkfd: fix build error with missing AMD_IOMMU_V2
On Mon, Mar 8, 2021 at 8:11 PM Felix Kuehling wrote: > > Am 2021-03-08 um 2:05 p.m. schrieb Arnd Bergmann: > > On Mon, Mar 8, 2021 at 5:24 PM Felix Kuehling > > wrote: > >> The driver build should work without IOMMUv2. In amdkfd/Makefile, we > >> have this condition: > >> > >> ifneq ($(CONFIG_AMD_IOMMU_V2),) > >> AMDKFD_FILES += $(AMDKFD_PATH)/kfd_iommu.o > >> endif > >> > >> In amdkfd/kfd_iommu.h we define inline stubs of the functions that are > >> causing your link-failures if IOMMU_V2 is not enabled: > >> > >> #if defined(CONFIG_AMD_IOMMU_V2_MODULE) || defined(CONFIG_AMD_IOMMU_V2) > >> ... function declarations ... > >> #else > >> ... stubs ... > >> #endif > > Right, that is the problem I tried to explain in my patch description. > > > > Should we just drop the 'imply' then and add a proper dependency like this? > > > > depends on DRM_AMDGPU && (X86_64 || ARM64 || PPC64) > > depends on AMD_IOMMU_V2=y || DRM_AMDGPU=m > > > > I can send a v2 after some testing if you prefer this version. > > No. My point is, there should not be a hard dependency. The build should > work without CONFIG_AMD_IOMMU_V2. I don't understand why it's not > working for you. It looks like you're building kfd_iommu.o, which should > not be happening when AMD_IOMMU_V2 is not enabled. The condition in > amdkfd/Makefile should make sure that kfd_iommu.o doesn't get built with > your kernel config. Again, as I explained in the changelog text, AMD_IOMMU_V2 configured as a loadable module, while AMDGPU is configured as built-in. The causes a link failure for the vmlinux file, because the linker cannot resolve addresses of loadable modules at compile time -- they have not been loaded yet. Arnd ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdkfd: fix build error with missing AMD_IOMMU_V2
On Mon, Mar 8, 2021 at 5:24 PM Felix Kuehling wrote: > > The driver build should work without IOMMUv2. In amdkfd/Makefile, we > have this condition: > > ifneq ($(CONFIG_AMD_IOMMU_V2),) > AMDKFD_FILES += $(AMDKFD_PATH)/kfd_iommu.o > endif > > In amdkfd/kfd_iommu.h we define inline stubs of the functions that are > causing your link-failures if IOMMU_V2 is not enabled: > > #if defined(CONFIG_AMD_IOMMU_V2_MODULE) || defined(CONFIG_AMD_IOMMU_V2) > ... function declarations ... > #else > ... stubs ... > #endif Right, that is the problem I tried to explain in my patch description. Should we just drop the 'imply' then and add a proper dependency like this? depends on DRM_AMDGPU && (X86_64 || ARM64 || PPC64) depends on AMD_IOMMU_V2=y || DRM_AMDGPU=m I can send a v2 after some testing if you prefer this version. Arnd ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] drm/amdkfd: fix build error with missing AMD_IOMMU_V2
From: Arnd Bergmann
Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link
against the exported functions. If the GPU driver is built-in but the
IOMMU driver is a loadable module, the kfd_iommu.c file is indeed
built but does not work:
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_bind_process_to_device':
kfd_iommu.c:(.text+0x516): undefined reference to `amd_iommu_bind_pasid'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_unbind_process':
kfd_iommu.c:(.text+0x691): undefined reference to `amd_iommu_unbind_pasid'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_suspend':
kfd_iommu.c:(.text+0x966): undefined reference to
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0x97f): undefined reference to
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0x9a4): undefined reference to
`amd_iommu_free_device'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_resume':
kfd_iommu.c:(.text+0xa9a): undefined reference to `amd_iommu_init_device'
x86_64-linux-ld: kfd_iommu.c:(.text+0xadc): undefined reference to
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xaff): undefined reference to
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xc72): undefined reference to
`amd_iommu_bind_pasid'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe08): undefined reference to
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe26): undefined reference to
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe42): undefined reference to
`amd_iommu_free_device'
Use a stronger 'select' instead.
Fixes: 64d1c3a43a6f ("drm/amdkfd: Centralize IOMMUv2 code and make it
conditional")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/amdkfd/Kconfig | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/Kconfig
b/drivers/gpu/drm/amd/amdkfd/Kconfig
index f02c938f75da..91f85dfb7ba6 100644
--- a/drivers/gpu/drm/amd/amdkfd/Kconfig
+++ b/drivers/gpu/drm/amd/amdkfd/Kconfig
@@ -5,8 +5,9 @@
config HSA_AMD
bool "HSA kernel driver for AMD GPU devices"
- depends on DRM_AMDGPU && (X86_64 || ARM64 || PPC64)
- imply AMD_IOMMU_V2 if X86_64
+ depends on DRM_AMDGPU && ((X86_64 && IOMMU_SUPPORT && ACPI) || ARM64 ||
PPC64)
+ select AMD_IOMMU if X86_64
+ select AMD_IOMMU_V2 if X86_64
select HMM_MIRROR
select MMU_NOTIFIER
select DRM_AMDGPU_USERPTR
--
2.29.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/display: Fix an uninitialized index variable
On Thu, Feb 25, 2021 at 10:34 PM 'Nick Desaulniers' via Clang Built
Linux wrote:
> return parse_edid_cea(aconnector, edid_ext, EDID_LENGTH, vsdb_info) ? i :
> -ENODEV;
>
> would suffice, but the patch is still fine as is.
Right, I did not want to change more than necessary here, and the
original code already had the extra assignment instead of returning
the value.
> > @@ -9857,8 +9857,8 @@ void amdgpu_dm_update_freesync_caps(struct
> > drm_connector *connector,
> > }
> > }
> > } else if (edid && amdgpu_dm_connector->dc_sink->sink_signal ==
> > SIGNAL_TYPE_HDMI_TYPE_A) {
> > - hdmi_valid_vsdb_found =
> > parse_hdmi_amd_vsdb(amdgpu_dm_connector, edid, _info);
> > - if (hdmi_valid_vsdb_found && vsdb_info.freesync_supported) {
> > + i = parse_hdmi_amd_vsdb(amdgpu_dm_connector, edid,
> > _info);
> > + if (i >= 0 && vsdb_info.freesync_supported) {
>
> reusing `i` here is safe, for now, but reuse of variables like this in
> separate branches like this might not get noticed if the function is
> amended in the future.
>
> > timing = >detailed_timings[i];
> > data= >data.other_data;
The entire point of the patch is that 'i' is in fact used in the following line,
but was lacking an intialization.
Arnd
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/display: fix 64-bit integer division
On Thu, Feb 25, 2021 at 3:33 PM Arnd Bergmann wrote: > > From: Arnd Bergmann > > The new display synchronization code caused a regression > on all 32-bit architectures: > > ld.lld: error: undefined symbol: __aeabi_uldivmod > >>> referenced by dce_clock_source.c > >>> > >>> gpu/drm/amd/display/dc/dce/dce_clock_source.o:(get_pixel_clk_frequency_100hz) > >>> in archive drivers/built-in.a > > ld.lld: error: undefined symbol: __aeabi_ldivmod > >>> referenced by dc_resource.c > >>> > >>> gpu/drm/amd/display/dc/core/dc_resource.o:(resource_are_vblanks_synchronizable) > >>> in archive drivers/built-in.a > >>> referenced by dc_resource.c > >>> > >>> gpu/drm/amd/display/dc/core/dc_resource.o:(resource_are_vblanks_synchronizable) > >>> in archive drivers/built-in.a > >>> referenced by dc_resource.c > >>> > >>> gpu/drm/amd/display/dc/core/dc_resource.o:(resource_are_vblanks_synchronizable) > >>> in archive drivers/built-in.a > > This is not a fast path, so the use of an explicit div_u64/div_s64 > seems appropriate. I found two more instances: >>> referenced by dcn20_optc.c >>> >>> gpu/drm/amd/display/dc/dcn20/dcn20_optc.o:(optc2_align_vblanks) in archive >>> drivers/built-in.a >>> referenced by dcn10_hw_sequencer.c >>> >>> gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.o:(reduceSizeAndFraction) >>> in archive drivers/built-in.a I have patches for both, but will let the randconfig build box keep working on it over night to see if there are any others. Let me know if you want a combined patch or one per file once there are no more regressions. Arnd ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] drm/amd/display: Fix an uninitialized index variable
From: Arnd Bergmann
clang points out that the new logic uses an always-uninitialized
array index:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:9810:38: warning:
variable 'i' is uninitialized when used here [-Wuninitialized]
timing = >detailed_timings[i];
^
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:9720:7: note:
initialize the variable 'i' to silence this warning
My best guess is that the index should have been returned by the
parse_hdmi_amd_vsdb() function that walks an array here, so do that.
Fixes: f9b4f20c4777 ("drm/amd/display: Add Freesync HDMI support to DM")
Signed-off-by: Arnd Bergmann
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c| 16
1 file changed, 8 insertions(+), 8 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 b19b93c74bae..667c0d52dbfa 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -9736,7 +9736,7 @@ static bool parse_edid_cea(struct amdgpu_dm_connector
*aconnector,
return false;
}
-static bool parse_hdmi_amd_vsdb(struct amdgpu_dm_connector *aconnector,
+static int parse_hdmi_amd_vsdb(struct amdgpu_dm_connector *aconnector,
struct edid *edid, struct amdgpu_hdmi_vsdb_info *vsdb_info)
{
uint8_t *edid_ext = NULL;
@@ -9746,7 +9746,7 @@ static bool parse_hdmi_amd_vsdb(struct
amdgpu_dm_connector *aconnector,
/*- drm_find_cea_extension() -*/
/* No EDID or EDID extensions */
if (edid == NULL || edid->extensions == 0)
- return false;
+ return -ENODEV;
/* Find CEA extension */
for (i = 0; i < edid->extensions; i++) {
@@ -9756,14 +9756,15 @@ static bool parse_hdmi_amd_vsdb(struct
amdgpu_dm_connector *aconnector,
}
if (i == edid->extensions)
- return false;
+ return -ENODEV;
/*- cea_db_offsets() -*/
if (edid_ext[0] != CEA_EXT)
- return false;
+ return -ENODEV;
valid_vsdb_found = parse_edid_cea(aconnector, edid_ext, EDID_LENGTH,
vsdb_info);
- return valid_vsdb_found;
+
+ return valid_vsdb_found ? i : -ENODEV;
}
void amdgpu_dm_update_freesync_caps(struct drm_connector *connector,
@@ -9781,7 +9782,6 @@ void amdgpu_dm_update_freesync_caps(struct drm_connector
*connector,
struct amdgpu_device *adev = drm_to_adev(dev);
bool freesync_capable = false;
struct amdgpu_hdmi_vsdb_info vsdb_info = {0};
- bool hdmi_valid_vsdb_found = false;
if (!connector->state) {
DRM_ERROR("%s - Connector has no state", __func__);
@@ -9857,8 +9857,8 @@ void amdgpu_dm_update_freesync_caps(struct drm_connector
*connector,
}
}
} else if (edid && amdgpu_dm_connector->dc_sink->sink_signal ==
SIGNAL_TYPE_HDMI_TYPE_A) {
- hdmi_valid_vsdb_found =
parse_hdmi_amd_vsdb(amdgpu_dm_connector, edid, _info);
- if (hdmi_valid_vsdb_found && vsdb_info.freesync_supported) {
+ i = parse_hdmi_amd_vsdb(amdgpu_dm_connector, edid, _info);
+ if (i >= 0 && vsdb_info.freesync_supported) {
timing = >detailed_timings[i];
data= >data.other_data;
--
2.29.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] drm/amd/display: fix 64-bit integer division
From: Arnd Bergmann
The new display synchronization code caused a regression
on all 32-bit architectures:
ld.lld: error: undefined symbol: __aeabi_uldivmod
>>> referenced by dce_clock_source.c
>>>
>>> gpu/drm/amd/display/dc/dce/dce_clock_source.o:(get_pixel_clk_frequency_100hz)
>>> in archive drivers/built-in.a
ld.lld: error: undefined symbol: __aeabi_ldivmod
>>> referenced by dc_resource.c
>>>
>>> gpu/drm/amd/display/dc/core/dc_resource.o:(resource_are_vblanks_synchronizable)
>>> in archive drivers/built-in.a
>>> referenced by dc_resource.c
>>>
>>> gpu/drm/amd/display/dc/core/dc_resource.o:(resource_are_vblanks_synchronizable)
>>> in archive drivers/built-in.a
>>> referenced by dc_resource.c
>>>
>>> gpu/drm/amd/display/dc/core/dc_resource.o:(resource_are_vblanks_synchronizable)
>>> in archive drivers/built-in.a
This is not a fast path, so the use of an explicit div_u64/div_s64
seems appropriate.
Fixes: 77a2b7265f20 ("drm/amd/display: Synchronize displays with different
timings")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/dc/core/dc_resource.c| 12 ++--
.../gpu/drm/amd/display/dc/dce/dce_clock_source.c| 6 +++---
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
index 0241c9d96d7a..49214c59c836 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
@@ -441,15 +441,15 @@ bool resource_are_vblanks_synchronizable(
if (stream2->timing.pix_clk_100hz*100/stream2->timing.h_total/
stream2->timing.v_total > 60)
return false;
- frame_time_diff = (int64_t)1 *
+ frame_time_diff = div_s64(1ll *
stream1->timing.h_total *
stream1->timing.v_total *
- stream2->timing.pix_clk_100hz /
- stream1->timing.pix_clk_100hz /
- stream2->timing.h_total /
- stream2->timing.v_total;
+ stream2->timing.pix_clk_100hz,
+ stream1->timing.pix_clk_100hz *
+ stream2->timing.h_total *
+ stream2->timing.v_total);
for (i = 0; i < rr_count; i++) {
- int64_t diff = (frame_time_diff *
base60_refresh_rates[i]) / 10 - 1;
+ int64_t diff = div_s64(frame_time_diff *
base60_refresh_rates[i], 10) - 1;
if (diff < 0)
diff = -diff;
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
index 6f47f9bab5ee..85ed6f2c9647 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
@@ -1013,9 +1013,9 @@ static bool get_pixel_clk_frequency_100hz(
* not be programmed equal to DPREFCLK
*/
modulo_hz = REG_READ(MODULO[inst]);
- *pixel_clk_khz = ((uint64_t)clock_hz*
-
clock_source->ctx->dc->clk_mgr->dprefclk_khz*10)/
- modulo_hz;
+ *pixel_clk_khz = div_u64((uint64_t)clock_hz * 10 *
+ clock_source->ctx->dc->clk_mgr->dprefclk_khz,
+ modulo_hz);
} else {
/* NOTE: There is agreement with VBIOS here that MODULO
is
* programmed equal to DPREFCLK, in which case PHASE
will be
--
2.29.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/display: use div_s64() for 64-bit division
On Mon, Jan 25, 2021 at 1:51 PM Chen, Guchun wrote: > > [AMD Public Use] > > Hi Arnd Bergmann, > > Thanks for your patch. This link error during compile has been fixed by below > commit and been submitted to drm-next branch already. > > 5da047444e82 drm/amd/display: fix 64-bit division issue on 32-bit OS Ok, thanks. I assume this will make it into linux-next in the coming days then. Arnd ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] drm/amd/display: fix unused variable warning
From: Arnd Bergmann
After all users of the 'dm' warnings got hidden in an #ifdef,
the compiler started warning about it being unused:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:5380:33: error:
unused variable 'dm' [-Werror,-Wunused-variable]
Add another such #ifdef.
Fixes: 98ab5f3513f9 ("drm/amd/display: Fix deadlock during gpu reset v3")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index a90dc4d31c32..37bf2dd87e1e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5377,7 +5377,9 @@ static inline int dm_set_vblank(struct drm_crtc *crtc,
bool enable)
struct amdgpu_crtc *acrtc = to_amdgpu_crtc(crtc);
struct amdgpu_device *adev = drm_to_adev(crtc->dev);
struct dm_crtc_state *acrtc_state = to_dm_crtc_state(crtc->state);
+#if defined(CONFIG_DRM_AMD_DC_DCN)
struct amdgpu_display_manager *dm = >dm;
+#endif
int rc = 0;
if (enable) {
--
2.29.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] amdgpu: fix clang build warning
From: Arnd Bergmann
clang warns about the -mhard-float command line arguments
on architectures that do not support this:
clang: error: argument unused during compilation: '-mhard-float'
[-Werror,-Wunused-command-line-argument]
Move this into the gcc-specific arguments.
Fixes: e77165bf7b02 ("drm/amd/display: Add DCN3 blocks to Makefile")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/dc/dcn30/Makefile | 6 --
drivers/gpu/drm/amd/display/dc/dcn301/Makefile | 3 ++-
drivers/gpu/drm/amd/display/dc/dcn302/Makefile | 3 ++-
3 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/Makefile
b/drivers/gpu/drm/amd/display/dc/dcn30/Makefile
index c20331eb62e0..dfd77b3cc84d 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn30/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn30/Makefile
@@ -32,8 +32,8 @@ DCN30 = dcn30_init.o dcn30_hubbub.o dcn30_hubp.o dcn30_dpp.o
dcn30_optc.o \
ifdef CONFIG_X86
-CFLAGS_$(AMDDALPATH)/dc/dcn30/dcn30_resource.o := -mhard-float -msse
-CFLAGS_$(AMDDALPATH)/dc/dcn30/dcn30_optc.o := -mhard-float -msse
+CFLAGS_$(AMDDALPATH)/dc/dcn30/dcn30_resource.o := -msse
+CFLAGS_$(AMDDALPATH)/dc/dcn30/dcn30_optc.o := -msse
endif
ifdef CONFIG_PPC64
@@ -45,6 +45,8 @@ ifdef CONFIG_CC_IS_GCC
ifeq ($(call cc-ifversion, -lt, 0701, y), y)
IS_OLD_GCC = 1
endif
+CFLAGS_$(AMDDALPATH)/dc/dcn30/dcn30_resource.o += -mhard-float
+CFLAGS_$(AMDDALPATH)/dc/dcn30/dcn30_optc.o += -mhard-float
endif
ifdef CONFIG_X86
diff --git a/drivers/gpu/drm/amd/display/dc/dcn301/Makefile
b/drivers/gpu/drm/amd/display/dc/dcn301/Makefile
index 3ca7d911d25c..09264716d1dc 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn301/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn301/Makefile
@@ -14,7 +14,7 @@ DCN301 = dcn301_init.o dcn301_resource.o dcn301_dccg.o \
dcn301_dio_link_encoder.o dcn301_hwseq.o dcn301_panel_cntl.o
dcn301_hubbub.o
ifdef CONFIG_X86
-CFLAGS_$(AMDDALPATH)/dc/dcn301/dcn301_resource.o := -mhard-float -msse
+CFLAGS_$(AMDDALPATH)/dc/dcn301/dcn301_resource.o := -msse
endif
ifdef CONFIG_PPC64
@@ -25,6 +25,7 @@ ifdef CONFIG_CC_IS_GCC
ifeq ($(call cc-ifversion, -lt, 0701, y), y)
IS_OLD_GCC = 1
endif
+CFLAGS_$(AMDDALPATH)/dc/dcn301/dcn301_resource.o += -mhard-float
endif
ifdef CONFIG_X86
diff --git a/drivers/gpu/drm/amd/display/dc/dcn302/Makefile
b/drivers/gpu/drm/amd/display/dc/dcn302/Makefile
index 8d4924b7dc22..101620a8867a 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn302/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn302/Makefile
@@ -13,7 +13,7 @@
DCN3_02 = dcn302_init.o dcn302_hwseq.o dcn302_resource.o
ifdef CONFIG_X86
-CFLAGS_$(AMDDALPATH)/dc/dcn302/dcn302_resource.o := -mhard-float -msse
+CFLAGS_$(AMDDALPATH)/dc/dcn302/dcn302_resource.o := -msse
endif
ifdef CONFIG_PPC64
@@ -24,6 +24,7 @@ ifdef CONFIG_CC_IS_GCC
ifeq ($(call cc-ifversion, -lt, 0701, y), y)
IS_OLD_GCC = 1
endif
+CFLAGS_$(AMDDALPATH)/dc/dcn302/dcn302_resource.o += -mhard-float
endif
ifdef CONFIG_X86
--
2.29.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] drm/amd/display: use div_s64() for 64-bit division
From: Arnd Bergmann
The open-coded 64-bit division causes a link error on 32-bit
machines:
ERROR: modpost: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: modpost: "__divdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
Use the div_s64() to perform the division here. One of them was an
unsigned division originally, but it looks like signed division was
intended, so use that to consistently allow a negative delay.
Fixes: ea7154d8d9fb ("drm/amd/display: Update
dcn30_apply_idle_power_optimizations() code")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
index dff83c6a142a..a133e399e76d 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
@@ -772,8 +772,8 @@ bool dcn30_apply_idle_power_optimizations(struct dc *dc,
bool enable)
cursor_cache_enable ?
_attr : NULL)) {
unsigned int v_total =
stream->adjust.v_total_max ?
stream->adjust.v_total_max :
stream->timing.v_total;
- unsigned int refresh_hz = (unsigned long long)
stream->timing.pix_clk_100hz *
- 100LL / (v_total *
stream->timing.h_total);
+ unsigned int refresh_hz = div_s64((unsigned
long long) stream->timing.pix_clk_100hz *
+ 100LL, v_total *
stream->timing.h_total);
/*
* one frame time in microsec:
@@ -800,8 +800,8 @@ bool dcn30_apply_idle_power_optimizations(struct dc *dc,
bool enable)
unsigned int denom = refresh_hz * 6528;
unsigned int stutter_period =
dc->current_state->perf_params.stutter_period_us;
- tmr_delay = (((100LL + 2 * stutter_period *
refresh_hz) *
- (100LL +
dc->debug.mall_additional_timer_percent) + denom - 1) /
+ tmr_delay = div_s64(((100LL + 2 *
stutter_period * refresh_hz) *
+ (100LL +
dc->debug.mall_additional_timer_percent) + denom - 1),
denom) - 64LL;
/* scale should be increased until it fits into
6 bits */
@@ -815,8 +815,8 @@ bool dcn30_apply_idle_power_optimizations(struct dc *dc,
bool enable)
}
denom *= 2;
- tmr_delay = (((100LL + 2 *
stutter_period * refresh_hz) *
- (100LL +
dc->debug.mall_additional_timer_percent) + denom - 1) /
+ tmr_delay = div_s64(((100LL + 2 *
stutter_period * refresh_hz) *
+ (100LL +
dc->debug.mall_additional_timer_percent) + denom - 1),
denom) - 64LL;
}
--
2.29.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: make DRM_AMD_DC x86-only again
On Tue, Dec 8, 2020 at 7:21 PM 'Nick Desaulniers' via Clang Built Linux wrote: > > On Tue, Dec 8, 2020 at 6:26 AM Arnd Bergmann wrote: > > > > On Mon, Dec 7, 2020 at 11:28 PM 'Nick Desaulniers' via Clang Built > > Linux wrote: > Hmm...no warnings for me with that config on next-20201208: > $ make LLVM=1 -j71 olddefconfig > $ make LLVM=1 -j71 > ... > $ clang --version > clang version 12.0.0 (g...@github.com:llvm/llvm-project.git > 1c98f984105e552daa83ed8e92c61fba0e401410) > (ie. near ToT LLVM) > > I see CONFIG_KASAN=y in the .config, so that's a recurring theme with > clang; excessive stack usage. It does seem a shame to disable a > driver for a bunch of archs just due to KASAN stack usage. > $ grep KASAN=y 0x9077925C_defconfig > CONFIG_HAVE_ARCH_KASAN=y > CONFIG_KASAN=y > > Is there a different branch of a different tree that I should be > testing on instead? Otherwise, can you send the object file? I was on a slightly older linux-next, and the latest version contains the patch "ubsan: enable for all*config builds" in linux-next, which enables CONFIG_UBSAN_SANITIZE_ALL. It took me an hour to figure out, but after turning that option off, the warning is back. I'll send you the object for reference in a private mail, it's kind of large. Arnd ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: make DRM_AMD_DC x86-only again
On Mon, Dec 7, 2020 at 11:08 PM 'Nick Desaulniers' via Clang Built Linux wrote: > > On Mon, Dec 7, 2020 at 1:57 PM Arnd Bergmann wrote: > > > > Right, looking at my latest randconfig logs, I see the same problem on x86 > > builds with clang as well, though I'm not entirely sure which other > > configuration > > options are needed to trigger it. > > > > So my patch can be disregarded, but I agree this needs a better fix, > > either in clang or in the dcn driver. > > If you could give https://github.com/ClangBuiltLinux/frame-larger-than > a spin again, I would appreciate any feedback. I've already tried it, but the tool doesn't seem to like me, I never get the information out of it that I want. This time it failed because it could not parse the .o file correctly. Arnd ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: make DRM_AMD_DC x86-only again
On Mon, Dec 7, 2020 at 9:50 PM Christian König wrote: > Am 07.12.20 um 21:47 schrieb Alex Deucher: > > On Fri, Dec 4, 2020 at 3:13 AM Arnd Bergmann wrote: > >> From: Arnd Bergmann > >> > >> As the DRM_AMD_DC_DCN3_0 code was x86-only and fails to build on > >> arm64, merging it into DRM_AMD_DC means that the top-level symbol > >> is now x86-only as well. > >> > >> Compilation fails on arm64 with clang-12 with > >> > >> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn30/display_mode_vba_30.c:3641:6: > >> error: stack frame size of 2416 bytes in function > >> 'dml30_ModeSupportAndSystemConfigurationFull' > >> [-Werror,-Wframe-larger-than=] > >> void dml30_ModeSupportAndSystemConfigurationFull(struct display_mode_lib > >> *mode_lib) > >> > >> I tried to see if the stack usage can be reduced, but this is code > >> that is described as "This file is gcc-parsable HW gospel, coming > >> straight from HW engineers." and is written in a way that is inherently > >> nonportable and not meant to be understood by humans. > >> > >> There are probably no non-x86 users of this code, so simplify > >> the dependency list accordingly. > > + Daniel, Timothy > > > > Others contributed code to enable this on PPC64 and ARM64. > > Unfortunately, we don't have these platforms to test with within AMD. > > Does PPC64 have the same stack limitations as ARM64? Harry, Leo, can > > you take a look at fixing the stack usage? > > This reminds me that I wanted to reply on this. > > 2416 is even to much on x86 if you add -Werror :) > > So this needs to be fixed anyway. Right, looking at my latest randconfig logs, I see the same problem on x86 builds with clang as well, though I'm not entirely sure which other configuration options are needed to trigger it. So my patch can be disregarded, but I agree this needs a better fix, either in clang or in the dcn driver. Arnd ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] drm/amdgpu: fw_attestation: fix unused function warning
From: Arnd Bergmann
Without debugfs, the compiler notices one function that is not used at
all:
drivers/gpu/drm/amd/amdgpu/amdgpu_fw_attestation.c:123:12: error: unused
function 'amdgpu_is_fw_attestation_supported' [-Werror,-Wunused-function]
In fact the static const amdgpu_fw_attestation_debugfs_ops structure is
also unused here, but that warning is currently disabled.
Removing the #ifdef check does the right thing and leads to all of this
code to be dropped without warning.
Fixes: 19ae333001b3 ("drm/amdgpu: added support for psp fw attestation")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fw_attestation.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fw_attestation.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fw_attestation.c
index e47bca1c7635..7c6e02e35573 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fw_attestation.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fw_attestation.c
@@ -130,7 +130,6 @@ static int amdgpu_is_fw_attestation_supported(struct
amdgpu_device *adev)
void amdgpu_fw_attestation_debugfs_init(struct amdgpu_device *adev)
{
-#if defined(CONFIG_DEBUG_FS)
if (!amdgpu_is_fw_attestation_supported(adev))
return;
@@ -139,5 +138,4 @@ void amdgpu_fw_attestation_debugfs_init(struct
amdgpu_device *adev)
adev_to_drm(adev)->primary->debugfs_root,
adev,
_fw_attestation_debugfs_ops);
-#endif
}
--
2.27.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] drm/amdgpu: make DRM_AMD_DC x86-only again
From: Arnd Bergmann
As the DRM_AMD_DC_DCN3_0 code was x86-only and fails to build on
arm64, merging it into DRM_AMD_DC means that the top-level symbol
is now x86-only as well.
Compilation fails on arm64 with clang-12 with
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn30/display_mode_vba_30.c:3641:6:
error: stack frame size of 2416 bytes in function
'dml30_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than=]
void dml30_ModeSupportAndSystemConfigurationFull(struct display_mode_lib
*mode_lib)
I tried to see if the stack usage can be reduced, but this is code
that is described as "This file is gcc-parsable HW gospel, coming
straight from HW engineers." and is written in a way that is inherently
nonportable and not meant to be understood by humans.
There are probably no non-x86 users of this code, so simplify
the dependency list accordingly.
Fixes: 20f2ffe50472 ("drm/amdgpu: fold CONFIG_DRM_AMD_DC_DCN3* into
CONFIG_DRM_AMD_DC_DCN (v3)")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/Kconfig
b/drivers/gpu/drm/amd/display/Kconfig
index 797b5d4b43e5..54aa50d4deba 100644
--- a/drivers/gpu/drm/amd/display/Kconfig
+++ b/drivers/gpu/drm/amd/display/Kconfig
@@ -6,7 +6,7 @@ config DRM_AMD_DC
bool "AMD DC - Enable new display engine"
default y
select SND_HDA_COMPONENT if SND_HDA_CORE
- select DRM_AMD_DC_DCN if (X86 || PPC64 || (ARM64 && KERNEL_MODE_NEON))
&& !(KCOV_INSTRUMENT_ALL && KCOV_ENABLE_COMPARISONS)
+ select DRM_AMD_DC_DCN if X86 && !(KCOV_INSTRUMENT_ALL &&
KCOV_ENABLE_COMPARISONS)
help
Choose this option if you want to use the new display engine
support for AMDGPU. This adds required support for Vega and
--
2.27.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] drm/amdgpu: fix debugfs creation/removal, again
From: Arnd Bergmann
There is still a warning when CONFIG_DEBUG_FS is disabled:
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:1145:13: error:
'amdgpu_ras_debugfs_create_ctrl_node' defined but not used
[-Werror=unused-function]
1145 | static void amdgpu_ras_debugfs_create_ctrl_node(struct amdgpu_device
*adev)
Change the code again to make the compiler actually drop
this code but not warn about it.
Fixes: ae2bf61ff39e ("drm/amdgpu: guard ras debugfs creation/removal based on
CONFIG_DEBUG_FS")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 13 +
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h | 6 --
2 files changed, 5 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index 9d11b847e6ef..c136bd449744 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
@@ -1167,7 +1167,7 @@ static void amdgpu_ras_debugfs_create_ctrl_node(struct
amdgpu_device *adev)
con->dir, >disable_ras_err_cnt_harvest);
}
-void amdgpu_ras_debugfs_create(struct amdgpu_device *adev,
+static void amdgpu_ras_debugfs_create(struct amdgpu_device *adev,
struct ras_fs_if *head)
{
struct amdgpu_ras *con = amdgpu_ras_get_context(adev);
@@ -1189,7 +1189,6 @@ void amdgpu_ras_debugfs_create(struct amdgpu_device *adev,
void amdgpu_ras_debugfs_create_all(struct amdgpu_device *adev)
{
-#if defined(CONFIG_DEBUG_FS)
struct amdgpu_ras *con = amdgpu_ras_get_context(adev);
struct ras_manager *obj;
struct ras_fs_if fs_info;
@@ -1198,7 +1197,7 @@ void amdgpu_ras_debugfs_create_all(struct amdgpu_device
*adev)
* it won't be called in resume path, no need to check
* suspend and gpu reset status
*/
- if (!con)
+ if (!IS_ENABLED(CONFIG_DEBUG_FS) || !con)
return;
amdgpu_ras_debugfs_create_ctrl_node(adev);
@@ -1212,10 +1211,9 @@ void amdgpu_ras_debugfs_create_all(struct amdgpu_device
*adev)
amdgpu_ras_debugfs_create(adev, _info);
}
}
-#endif
}
-void amdgpu_ras_debugfs_remove(struct amdgpu_device *adev,
+static void amdgpu_ras_debugfs_remove(struct amdgpu_device *adev,
struct ras_common_if *head)
{
struct ras_manager *obj = amdgpu_ras_find_obj(adev, head);
@@ -1229,7 +1227,6 @@ void amdgpu_ras_debugfs_remove(struct amdgpu_device *adev,
static void amdgpu_ras_debugfs_remove_all(struct amdgpu_device *adev)
{
-#if defined(CONFIG_DEBUG_FS)
struct amdgpu_ras *con = amdgpu_ras_get_context(adev);
struct ras_manager *obj, *tmp;
@@ -1238,7 +1235,6 @@ static void amdgpu_ras_debugfs_remove_all(struct
amdgpu_device *adev)
}
con->dir = NULL;
-#endif
}
/* debugfs end */
@@ -1286,7 +1282,8 @@ static int amdgpu_ras_fs_init(struct amdgpu_device *adev)
static int amdgpu_ras_fs_fini(struct amdgpu_device *adev)
{
- amdgpu_ras_debugfs_remove_all(adev);
+ if (IS_ENABLED(CONFIG_DEBUG_FS))
+ amdgpu_ras_debugfs_remove_all(adev);
amdgpu_ras_sysfs_remove_all(adev);
return 0;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h
index 4667cce38582..762f5e46c007 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h
@@ -592,14 +592,8 @@ int amdgpu_ras_sysfs_create(struct amdgpu_device *adev,
int amdgpu_ras_sysfs_remove(struct amdgpu_device *adev,
struct ras_common_if *head);
-void amdgpu_ras_debugfs_create(struct amdgpu_device *adev,
- struct ras_fs_if *head);
-
void amdgpu_ras_debugfs_create_all(struct amdgpu_device *adev);
-void amdgpu_ras_debugfs_remove(struct amdgpu_device *adev,
- struct ras_common_if *head);
-
int amdgpu_ras_error_query(struct amdgpu_device *adev,
struct ras_query_if *info);
--
2.27.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 1/5] drm/amdgpu: fix enum mismatches
From: Arnd Bergmann
gcc -Wextra warns about an incorrect prototype causing multiple
mismatched enums:
display/dc/gpio/gpio_service.c: In function 'dal_gpio_service_create':
display/dc/gpio/gpio_service.c:70:50: warning: implicit conversion from 'enum
dce_environment' to 'enum dce_version' [-Wenum-conversion]
display/dc/gpio/gpio_service.c:71:4: warning: implicit conversion from 'enum
dce_version' to 'enum dce_environment' [-Wenum-conversion]
display/dc/gpio/gpio_service.c:76:46: warning: implicit conversion from 'enum
dce_environment' to 'enum dce_version' [-Wenum-conversion]
display/dc/gpio/gpio_service.c:77:4: warning: implicit conversion from 'enum
dce_version' to 'enum dce_environment' [-Wenum-conversion]
display/dc/core/dc.c: In function 'dc_construct':
display/dc/core/dc.c:718:10: warning: implicit conversion from 'enum
dce_version' to 'enum dce_environment' [-Wenum-conversion]
display/dc/core/dc.c:719:10: warning: implicit conversion from 'enum
dce_environment' to 'enum dce_version' [-Wenum-conversion]
Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/dc/gpio/gpio_service.c | 2 +-
drivers/gpu/drm/amd/display/include/gpio_service_interface.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/gpio/gpio_service.c
b/drivers/gpu/drm/amd/display/dc/gpio/gpio_service.c
index 92280cc05e2d..67bb5cc67255 100644
--- a/drivers/gpu/drm/amd/display/dc/gpio/gpio_service.c
+++ b/drivers/gpu/drm/amd/display/dc/gpio/gpio_service.c
@@ -54,7 +54,7 @@
struct gpio_service *dal_gpio_service_create(
enum dce_version dce_version_major,
- enum dce_version dce_version_minor,
+ enum dce_environment dce_version_minor,
struct dc_context *ctx)
{
struct gpio_service *service;
diff --git a/drivers/gpu/drm/amd/display/include/gpio_service_interface.h
b/drivers/gpu/drm/amd/display/include/gpio_service_interface.h
index 9c55d247227e..5f0f94e83d19 100644
--- a/drivers/gpu/drm/amd/display/include/gpio_service_interface.h
+++ b/drivers/gpu/drm/amd/display/include/gpio_service_interface.h
@@ -43,7 +43,7 @@ void dal_gpio_destroy(
struct gpio_service *dal_gpio_service_create(
enum dce_version dce_version_major,
- enum dce_version dce_version_minor,
+ enum dce_environment dce_version_minor,
struct dc_context *ctx);
struct gpio *dal_gpio_service_create_irq(
--
2.27.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 4/5] drm/amdgpu: fix build_coefficients() argument
From: Arnd Bergmann
gcc -Wextra warns about a function taking an enum argument
being called with a bool:
drivers/gpu/drm/amd/amdgpu/../display/modules/color/color_gamma.c: In function
'apply_degamma_for_user_regamma':
drivers/gpu/drm/amd/amdgpu/../display/modules/color/color_gamma.c:1617:29:
warning: implicit conversion from 'enum ' to 'enum
dc_transfer_func_predefined' [-Wenum-conversion]
1617 | build_coefficients(, true);
It appears that a patch was added using the old calling conventions
after the type was changed, and the value should actually be 0
(TRANSFER_FUNCTION_SRGB) here instead of 1 (true).
Fixes: 55a01d4023ce ("drm/amd/display: Add user_regamma to color module")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/modules/color/color_gamma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/modules/color/color_gamma.c
b/drivers/gpu/drm/amd/display/modules/color/color_gamma.c
index b8695660b480..09bc2c249e1a 100644
--- a/drivers/gpu/drm/amd/display/modules/color/color_gamma.c
+++ b/drivers/gpu/drm/amd/display/modules/color/color_gamma.c
@@ -1614,7 +1614,7 @@ static void apply_degamma_for_user_regamma(struct
pwl_float_data_ex *rgb_regamma
struct pwl_float_data_ex *rgb = rgb_regamma;
const struct hw_x_point *coord_x = coordinates_x;
- build_coefficients(, true);
+ build_coefficients(, TRANSFER_FUNCTION_SRGB);
i = 0;
while (i != hw_points_num + 1) {
--
2.27.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 5/5] drm/amdgpu: disable -Woverride-init warning
From: Arnd Bergmann Building with 'make W=1' produces countless warnings like amdgpu/../include/vega10_ip_offset.h:276:51: warning: initialized field overwritten [-Woverride-init] Shut these up by disabling the particular warning in the amdgpu driver. Signed-off-by: Arnd Bergmann --- drivers/gpu/drm/amd/amdgpu/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile b/drivers/gpu/drm/amd/amdgpu/Makefile index 247dd46e1681..5a46949bc17c 100644 --- a/drivers/gpu/drm/amd/amdgpu/Makefile +++ b/drivers/gpu/drm/amd/amdgpu/Makefile @@ -36,7 +36,8 @@ ccflags-y := -I$(FULL_AMD_PATH)/include/asic_reg \ -I$(FULL_AMD_DISPLAY_PATH)/include \ -I$(FULL_AMD_DISPLAY_PATH)/dc \ -I$(FULL_AMD_DISPLAY_PATH)/amdgpu_dm \ - -I$(FULL_AMD_PATH)/amdkfd + -I$(FULL_AMD_PATH)/amdkfd \ + -Wno-override-init amdgpu-y := amdgpu_drv.o -- 2.27.0 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
