* [PATCH 0/1] Fix Navi cards crashing with FP exception on 5.6+
@ 2020-04-29 15:02 Daniel Kolesa
2020-04-29 15:02 ` [PATCH 1/1] drm/amd/display: work around fp code being emitted outside of DC_FP_START/END Daniel Kolesa
0 siblings, 1 reply; 3+ messages in thread
From: Daniel Kolesa @ 2020-04-29 15:02 UTC (permalink / raw
To: amd-gfx; +Cc: Daniel Kolesa
This is not a real fix, but rather a workaround that should be applied to the
5.6 tree and newer. The idea here is to work around the compiler emitting FP
instructions outside the DC_FP_START/DC_FP_END blocks, which it currently does,
which causes crashes at least on ppc64le.
A proper solution would be to move all the floating point code into its own
files, then compile those with hard-float and strictly wrap all calls into
those with the DC_FP_START/DC_FP_END blocks, with the rest of the code being
compiled without floating point, but that's too extensive of a change to do,
and would not be possible in a stable tree.
The proper solution is already being discussed, it seems:
https://lore.kernel.org/lkml/CAG48ez2Sx4ELkM94aD_h_J7K7KBOeuGmvZLKRkg3n_f2WoZ_cg@mail.gmail.com/
Daniel Kolesa (1):
drm/amd/display: work around fp code being emitted outside of
DC_FP_START/END
.../drm/amd/display/dc/dcn20/dcn20_resource.c | 31 ++++++++++++++-----
1 file changed, 23 insertions(+), 8 deletions(-)
--
2.26.2
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply [flat|nested] 3+ messages in thread
* [PATCH 1/1] drm/amd/display: work around fp code being emitted outside of DC_FP_START/END
2020-04-29 15:02 [PATCH 0/1] Fix Navi cards crashing with FP exception on 5.6+ Daniel Kolesa
@ 2020-04-29 15:02 ` Daniel Kolesa
2020-04-30 14:58 ` Alex Deucher
0 siblings, 1 reply; 3+ messages in thread
From: Daniel Kolesa @ 2020-04-29 15:02 UTC (permalink / raw
To: amd-gfx; +Cc: Daniel Kolesa
The dcn20_validate_bandwidth function would have code touching the
incorrect registers emitted outside of the boundaries of the
DC_FP_START/END macros, at least on ppc64le. Work around the
problem by wrapping the whole function instead.
Signed-off-by: Daniel Kolesa <daniel@octaforge.org>
---
.../drm/amd/display/dc/dcn20/dcn20_resource.c | 31 ++++++++++++++-----
1 file changed, 23 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
index e310d67..1b0bca9 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
@@ -3034,25 +3034,32 @@ static bool dcn20_validate_bandwidth_internal(struct dc *dc, struct dc_state *co
return out;
}
-
-bool dcn20_validate_bandwidth(struct dc *dc, struct dc_state *context,
- bool fast_validate)
+/*
+ * This must be noinline to ensure anything that deals with FP registers
+ * is contained within this call; previously our compiling with hard-float
+ * would result in fp instructions being emitted outside of the boundaries
+ * of the DC_FP_START/END macros, which makes sense as the compiler has no
+ * idea about what is wrapped and what is not
+ *
+ * This is largely just a workaround to avoid breakage introduced with 5.6,
+ * ideally all fp-using code should be moved into its own file, only that
+ * should be compiled with hard-float, and all code exported from there
+ * should be strictly wrapped with DC_FP_START/END
+ */
+static noinline bool dcn20_validate_bandwidth_fp(struct dc *dc,
+ struct dc_state *context, bool fast_validate)
{
bool voltage_supported = false;
bool full_pstate_supported = false;
bool dummy_pstate_supported = false;
double p_state_latency_us;
- DC_FP_START();
p_state_latency_us = context->bw_ctx.dml.soc.dram_clock_change_latency_us;
context->bw_ctx.dml.soc.disable_dram_clock_change_vactive_support =
dc->debug.disable_dram_clock_change_vactive_support;
if (fast_validate) {
- voltage_supported = dcn20_validate_bandwidth_internal(dc, context, true);
-
- DC_FP_END();
- return voltage_supported;
+ return dcn20_validate_bandwidth_internal(dc, context, true);
}
// Best case, we support full UCLK switch latency
@@ -3081,7 +3088,15 @@ bool dcn20_validate_bandwidth(struct dc *dc, struct dc_state *context,
restore_dml_state:
context->bw_ctx.dml.soc.dram_clock_change_latency_us = p_state_latency_us;
+ return voltage_supported;
+}
+bool dcn20_validate_bandwidth(struct dc *dc, struct dc_state *context,
+ bool fast_validate)
+{
+ bool voltage_supported = false;
+ DC_FP_START();
+ voltage_supported = dcn20_validate_bandwidth_fp(dc, context, fast_validate);
DC_FP_END();
return voltage_supported;
}
--
2.26.2
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH 1/1] drm/amd/display: work around fp code being emitted outside of DC_FP_START/END
2020-04-29 15:02 ` [PATCH 1/1] drm/amd/display: work around fp code being emitted outside of DC_FP_START/END Daniel Kolesa
@ 2020-04-30 14:58 ` Alex Deucher
0 siblings, 0 replies; 3+ messages in thread
From: Alex Deucher @ 2020-04-30 14:58 UTC (permalink / raw
To: Daniel Kolesa; +Cc: amd-gfx list
On Wed, Apr 29, 2020 at 11:08 AM Daniel Kolesa <daniel@octaforge.org> wrote:
>
> The dcn20_validate_bandwidth function would have code touching the
> incorrect registers emitted outside of the boundaries of the
> DC_FP_START/END macros, at least on ppc64le. Work around the
> problem by wrapping the whole function instead.
>
> Signed-off-by: Daniel Kolesa <daniel@octaforge.org>
Applied. Thanks!
Alex
> ---
> .../drm/amd/display/dc/dcn20/dcn20_resource.c | 31 ++++++++++++++-----
> 1 file changed, 23 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
> index e310d67..1b0bca9 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
> @@ -3034,25 +3034,32 @@ static bool dcn20_validate_bandwidth_internal(struct dc *dc, struct dc_state *co
> return out;
> }
>
> -
> -bool dcn20_validate_bandwidth(struct dc *dc, struct dc_state *context,
> - bool fast_validate)
> +/*
> + * This must be noinline to ensure anything that deals with FP registers
> + * is contained within this call; previously our compiling with hard-float
> + * would result in fp instructions being emitted outside of the boundaries
> + * of the DC_FP_START/END macros, which makes sense as the compiler has no
> + * idea about what is wrapped and what is not
> + *
> + * This is largely just a workaround to avoid breakage introduced with 5.6,
> + * ideally all fp-using code should be moved into its own file, only that
> + * should be compiled with hard-float, and all code exported from there
> + * should be strictly wrapped with DC_FP_START/END
> + */
> +static noinline bool dcn20_validate_bandwidth_fp(struct dc *dc,
> + struct dc_state *context, bool fast_validate)
> {
> bool voltage_supported = false;
> bool full_pstate_supported = false;
> bool dummy_pstate_supported = false;
> double p_state_latency_us;
>
> - DC_FP_START();
> p_state_latency_us = context->bw_ctx.dml.soc.dram_clock_change_latency_us;
> context->bw_ctx.dml.soc.disable_dram_clock_change_vactive_support =
> dc->debug.disable_dram_clock_change_vactive_support;
>
> if (fast_validate) {
> - voltage_supported = dcn20_validate_bandwidth_internal(dc, context, true);
> -
> - DC_FP_END();
> - return voltage_supported;
> + return dcn20_validate_bandwidth_internal(dc, context, true);
> }
>
> // Best case, we support full UCLK switch latency
> @@ -3081,7 +3088,15 @@ bool dcn20_validate_bandwidth(struct dc *dc, struct dc_state *context,
>
> restore_dml_state:
> context->bw_ctx.dml.soc.dram_clock_change_latency_us = p_state_latency_us;
> + return voltage_supported;
> +}
>
> +bool dcn20_validate_bandwidth(struct dc *dc, struct dc_state *context,
> + bool fast_validate)
> +{
> + bool voltage_supported = false;
> + DC_FP_START();
> + voltage_supported = dcn20_validate_bandwidth_fp(dc, context, fast_validate);
> DC_FP_END();
> return voltage_supported;
> }
> --
> 2.26.2
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-04-30 14:58 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-04-29 15:02 [PATCH 0/1] Fix Navi cards crashing with FP exception on 5.6+ Daniel Kolesa
2020-04-29 15:02 ` [PATCH 1/1] drm/amd/display: work around fp code being emitted outside of DC_FP_START/END Daniel Kolesa
2020-04-30 14:58 ` Alex Deucher
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.