[PATCH AUTOSEL 5.4 5/8] drm/amd/display: Fix pixel clock programming
From: Ilya Bakoulin
[ Upstream commit 04fb918bf421b299feaee1006e82921d7d381f18 ]
[Why]
Some pixel clock values could cause HDMI TMDS SSCPs to be misaligned
between different HDMI lanes when using YCbCr420 10-bit pixel format.
BIOS functions for transmitter/encoder control take pixel clock in kHz
increments, whereas the function for setting the pixel clock is in 100Hz
increments. Setting pixel clock to a value that is not on a kHz boundary
will cause the issue.
[How]
Round pixel clock down to nearest kHz in 10/12-bpc cases.
Reviewed-by: Aric Cyr
Acked-by: Brian Chang
Signed-off-by: Ilya Bakoulin
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c | 2 ++
1 file changed, 2 insertions(+)
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 eca67d5d5b10..721be82ccebe 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
@@ -546,9 +546,11 @@ static void dce112_get_pix_clk_dividers_helper (
switch (pix_clk_params->color_depth) {
case COLOR_DEPTH_101010:
actual_pixel_clock_100hz = (actual_pixel_clock_100hz *
5) >> 2;
+ actual_pixel_clock_100hz -= actual_pixel_clock_100hz %
10;
break;
case COLOR_DEPTH_121212:
actual_pixel_clock_100hz = (actual_pixel_clock_100hz *
6) >> 2;
+ actual_pixel_clock_100hz -= actual_pixel_clock_100hz %
10;
break;
case COLOR_DEPTH_161616:
actual_pixel_clock_100hz = actual_pixel_clock_100hz * 2;
--
2.35.1
[PATCH AUTOSEL 4.19 1/5] drm/amd/display: clear optc underflow before turn off odm clock
From: Fudong Wang
[ Upstream commit b2a93490201300a749ad261b5c5d05cb50179c44 ]
[Why]
After ODM clock off, optc underflow bit will be kept there always and clear not
work.
We need to clear that before clock off.
[How]
Clear that if have when clock off.
Reviewed-by: Alvin Lee
Acked-by: Tom Chung
Signed-off-by: Fudong Wang
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c
index 411f89218e01..cb5c44b339e0 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c
@@ -452,6 +452,11 @@ void optc1_enable_optc_clock(struct timing_generator
*optc, bool enable)
OTG_CLOCK_ON, 1,
1, 1000);
} else {
+
+ //last chance to clear underflow, otherwise, it will always
there due to clock is off.
+ if (optc->funcs->is_optc_underflow_occurred(optc) == true)
+ optc->funcs->clear_optc_underflow(optc);
+
REG_UPDATE_2(OTG_CLOCK_CONTROL,
OTG_CLOCK_GATE_DIS, 0,
OTG_CLOCK_EN, 0);
--
2.35.1
[PATCH AUTOSEL 5.4 2/8] drm/amd/display: clear optc underflow before turn off odm clock
From: Fudong Wang
[ Upstream commit b2a93490201300a749ad261b5c5d05cb50179c44 ]
[Why]
After ODM clock off, optc underflow bit will be kept there always and clear not
work.
We need to clear that before clock off.
[How]
Clear that if have when clock off.
Reviewed-by: Alvin Lee
Acked-by: Tom Chung
Signed-off-by: Fudong Wang
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c
index e74a07d03fde..4b0200e96eb7 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c
@@ -425,6 +425,11 @@ void optc1_enable_optc_clock(struct timing_generator
*optc, bool enable)
OTG_CLOCK_ON, 1,
1, 1000);
} else {
+
+ //last chance to clear underflow, otherwise, it will always
there due to clock is off.
+ if (optc->funcs->is_optc_underflow_occurred(optc) == true)
+ optc->funcs->clear_optc_underflow(optc);
+
REG_UPDATE_2(OTG_CLOCK_CONTROL,
OTG_CLOCK_GATE_DIS, 0,
OTG_CLOCK_EN, 0);
--
2.35.1
[PATCH AUTOSEL 5.4 1/8] drm/amd/display: Avoid MPC infinite loop
From: Josip Pavic
[ Upstream commit 8de297dc046c180651c0500f8611663ae1c3828a ]
[why]
In some cases MPC tree bottom pipe ends up point to itself. This causes
iterating from top to bottom to hang the system in an infinite loop.
[how]
When looping to next MPC bottom pipe, check that the pointer is not same
as current to avoid infinite loop.
Reviewed-by: Josip Pavic
Reviewed-by: Jun Lei
Acked-by: Alex Hung
Signed-off-by: Aric Cyr
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_mpc.c | 6 ++
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_mpc.c | 6 ++
2 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_mpc.c
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_mpc.c
index 8b2f29f6dabd..068e79fa3490 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_mpc.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_mpc.c
@@ -118,6 +118,12 @@ struct mpcc *mpc1_get_mpcc_for_dpp(struct mpc_tree *tree,
int dpp_id)
while (tmp_mpcc != NULL) {
if (tmp_mpcc->dpp_id == dpp_id)
return tmp_mpcc;
+
+ /* avoid circular linked list */
+ ASSERT(tmp_mpcc != tmp_mpcc->mpcc_bot);
+ if (tmp_mpcc == tmp_mpcc->mpcc_bot)
+ break;
+
tmp_mpcc = tmp_mpcc->mpcc_bot;
}
return NULL;
diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_mpc.c
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_mpc.c
index 5a188b2bc033..0a00bd8e00ab 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_mpc.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_mpc.c
@@ -488,6 +488,12 @@ struct mpcc *mpc2_get_mpcc_for_dpp(struct mpc_tree *tree,
int dpp_id)
while (tmp_mpcc != NULL) {
if (tmp_mpcc->dpp_id == 0xf || tmp_mpcc->dpp_id == dpp_id)
return tmp_mpcc;
+
+ /* avoid circular linked list */
+ ASSERT(tmp_mpcc != tmp_mpcc->mpcc_bot);
+ if (tmp_mpcc == tmp_mpcc->mpcc_bot)
+ break;
+
tmp_mpcc = tmp_mpcc->mpcc_bot;
}
return NULL;
--
2.35.1
[PATCH AUTOSEL 5.10 08/11] drm/amdgpu: Increase tlb flush timeout for sriov
From: Dusica Milinkovic
[ Upstream commit 373008bfc9cdb0f050258947fa5a095f0657e1bc ]
[Why]
During multi-vf executing benchmark (Luxmark) observed kiq error timeout.
It happenes because all of VFs do the tlb invalidation at the same time.
Although each VF has the invalidate register set, from hardware side
the invalidate requests are queue to execute.
[How]
In case of 12 VF increase timeout on 12*100ms
Signed-off-by: Dusica Milinkovic
Acked-by: Shaoyun Liu
Acked-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 2 +-
drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 3 ++-
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 3 ++-
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index d949d6c52f24..ff353eb4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -283,7 +283,7 @@ enum amdgpu_kiq_irq {
AMDGPU_CP_KIQ_IRQ_DRIVER0 = 0,
AMDGPU_CP_KIQ_IRQ_LAST
};
-
+#define SRIOV_USEC_TIMEOUT 120 /* wait 12 * 100ms for SRIOV */
#define MAX_KIQ_REG_WAIT 5000 /* in usecs, 5ms */
#define MAX_KIQ_REG_BAILOUT_INTERVAL 5 /* in msecs, 5ms */
#define MAX_KIQ_REG_TRY 80 /* 20 -> 80 */
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
index 150fa5258fb6..2aa9242c58ab 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
@@ -371,6 +371,7 @@ static int gmc_v10_0_flush_gpu_tlb_pasid(struct
amdgpu_device *adev,
uint32_t seq;
uint16_t queried_pasid;
bool ret;
+ u32 usec_timeout = amdgpu_sriov_vf(adev) ? SRIOV_USEC_TIMEOUT :
adev->usec_timeout;
struct amdgpu_ring *ring = &adev->gfx.kiq.ring;
struct amdgpu_kiq *kiq = &adev->gfx.kiq;
@@ -389,7 +390,7 @@ static int gmc_v10_0_flush_gpu_tlb_pasid(struct
amdgpu_device *adev,
amdgpu_ring_commit(ring);
spin_unlock(&adev->gfx.kiq.ring_lock);
- r = amdgpu_fence_wait_polling(ring, seq, adev->usec_timeout);
+ r = amdgpu_fence_wait_polling(ring, seq, usec_timeout);
if (r < 1) {
dev_err(adev->dev, "wait for kiq fence error: %ld.\n",
r);
return -ETIME;
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index 3a864041968f..1673bf3bae55 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
@@ -839,6 +839,7 @@ static int gmc_v9_0_flush_gpu_tlb_pasid(struct
amdgpu_device *adev,
uint32_t seq;
uint16_t queried_pasid;
bool ret;
+ u32 usec_timeout = amdgpu_sriov_vf(adev) ? SRIOV_USEC_TIMEOUT :
adev->usec_timeout;
struct amdgpu_ring *ring = &adev->gfx.kiq.ring;
struct amdgpu_kiq *kiq = &adev->gfx.kiq;
@@ -878,7 +879,7 @@ static int gmc_v9_0_flush_gpu_tlb_pasid(struct
amdgpu_device *adev,
amdgpu_ring_commit(ring);
spin_unlock(&adev->gfx.kiq.ring_lock);
- r = amdgpu_fence_wait_polling(ring, seq, adev->usec_timeout);
+ r = amdgpu_fence_wait_polling(ring, seq, usec_timeout);
if (r < 1) {
dev_err(adev->dev, "wait for kiq fence error: %ld.\n",
r);
up_read(&adev->reset_sem);
--
2.35.1
[PATCH AUTOSEL 5.10 07/11] drm/amd/display: Fix pixel clock programming
From: Ilya Bakoulin
[ Upstream commit 04fb918bf421b299feaee1006e82921d7d381f18 ]
[Why]
Some pixel clock values could cause HDMI TMDS SSCPs to be misaligned
between different HDMI lanes when using YCbCr420 10-bit pixel format.
BIOS functions for transmitter/encoder control take pixel clock in kHz
increments, whereas the function for setting the pixel clock is in 100Hz
increments. Setting pixel clock to a value that is not on a kHz boundary
will cause the issue.
[How]
Round pixel clock down to nearest kHz in 10/12-bpc cases.
Reviewed-by: Aric Cyr
Acked-by: Brian Chang
Signed-off-by: Ilya Bakoulin
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c | 2 ++
1 file changed, 2 insertions(+)
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 bae3a146b2cc..89cc852cb27c 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
@@ -546,9 +546,11 @@ static void dce112_get_pix_clk_dividers_helper (
switch (pix_clk_params->color_depth) {
case COLOR_DEPTH_101010:
actual_pixel_clock_100hz = (actual_pixel_clock_100hz *
5) >> 2;
+ actual_pixel_clock_100hz -= actual_pixel_clock_100hz %
10;
break;
case COLOR_DEPTH_121212:
actual_pixel_clock_100hz = (actual_pixel_clock_100hz *
6) >> 2;
+ actual_pixel_clock_100hz -= actual_pixel_clock_100hz %
10;
break;
case COLOR_DEPTH_161616:
actual_pixel_clock_100hz = actual_pixel_clock_100hz * 2;
--
2.35.1
[PATCH AUTOSEL 5.10 06/11] drm/amd/pm: add missing ->fini_microcode interface for Sienna Cichlid
From: Evan Quan
[ Upstream commit 0a2d922a5618377cdf8fa476351362733ef55342 ]
To avoid any potential memory leak.
Signed-off-by: Evan Quan
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
index 8556c229ff59..49d7fa1d0842 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
@@ -2759,6 +2759,7 @@ static const struct pptable_funcs
sienna_cichlid_ppt_funcs = {
.dump_pptable = sienna_cichlid_dump_pptable,
.init_microcode = smu_v11_0_init_microcode,
.load_microcode = smu_v11_0_load_microcode,
+ .fini_microcode = smu_v11_0_fini_microcode,
.init_smc_tables = sienna_cichlid_init_smc_tables,
.fini_smc_tables = smu_v11_0_fini_smc_tables,
.init_power = smu_v11_0_init_power,
--
2.35.1
[PATCH AUTOSEL 5.10 03/11] drm/amd/display: clear optc underflow before turn off odm clock
From: Fudong Wang
[ Upstream commit b2a93490201300a749ad261b5c5d05cb50179c44 ]
[Why]
After ODM clock off, optc underflow bit will be kept there always and clear not
work.
We need to clear that before clock off.
[How]
Clear that if have when clock off.
Reviewed-by: Alvin Lee
Acked-by: Tom Chung
Signed-off-by: Fudong Wang
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c
index 800be2693fac..963d72f96dca 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c
@@ -464,6 +464,11 @@ void optc1_enable_optc_clock(struct timing_generator
*optc, bool enable)
OTG_CLOCK_ON, 1,
1, 1000);
} else {
+
+ //last chance to clear underflow, otherwise, it will always
there due to clock is off.
+ if (optc->funcs->is_optc_underflow_occurred(optc) == true)
+ optc->funcs->clear_optc_underflow(optc);
+
REG_UPDATE_2(OTG_CLOCK_CONTROL,
OTG_CLOCK_GATE_DIS, 0,
OTG_CLOCK_EN, 0);
--
2.35.1
[PATCH AUTOSEL 5.10 01/11] drm/amd/display: Avoid MPC infinite loop
From: Josip Pavic
[ Upstream commit 8de297dc046c180651c0500f8611663ae1c3828a ]
[why]
In some cases MPC tree bottom pipe ends up point to itself. This causes
iterating from top to bottom to hang the system in an infinite loop.
[how]
When looping to next MPC bottom pipe, check that the pointer is not same
as current to avoid infinite loop.
Reviewed-by: Josip Pavic
Reviewed-by: Jun Lei
Acked-by: Alex Hung
Signed-off-by: Aric Cyr
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_mpc.c | 6 ++
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_mpc.c | 6 ++
2 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_mpc.c
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_mpc.c
index 3fcd408e9103..855682590c1b 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_mpc.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_mpc.c
@@ -125,6 +125,12 @@ struct mpcc *mpc1_get_mpcc_for_dpp(struct mpc_tree *tree,
int dpp_id)
while (tmp_mpcc != NULL) {
if (tmp_mpcc->dpp_id == dpp_id)
return tmp_mpcc;
+
+ /* avoid circular linked list */
+ ASSERT(tmp_mpcc != tmp_mpcc->mpcc_bot);
+ if (tmp_mpcc == tmp_mpcc->mpcc_bot)
+ break;
+
tmp_mpcc = tmp_mpcc->mpcc_bot;
}
return NULL;
diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_mpc.c
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_mpc.c
index 99cc095dc33c..a701ea56c0aa 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_mpc.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_mpc.c
@@ -533,6 +533,12 @@ struct mpcc *mpc2_get_mpcc_for_dpp(struct mpc_tree *tree,
int dpp_id)
while (tmp_mpcc != NULL) {
if (tmp_mpcc->dpp_id == 0xf || tmp_mpcc->dpp_id == dpp_id)
return tmp_mpcc;
+
+ /* avoid circular linked list */
+ ASSERT(tmp_mpcc != tmp_mpcc->mpcc_bot);
+ if (tmp_mpcc == tmp_mpcc->mpcc_bot)
+ break;
+
tmp_mpcc = tmp_mpcc->mpcc_bot;
}
return NULL;
--
2.35.1
[PATCH AUTOSEL 5.10 02/11] drm/amd/display: For stereo keep "FLIP_ANY_FRAME"
From: Alvin Lee
[ Upstream commit 84ef99c728079dfd21d6bc70b4c3e4af20602b3c ]
[Description]
Observed in stereomode that programming FLIP_LEFT_EYE
can cause hangs. Keep FLIP_ANY_FRAME in stereo mode so
the surface flip can take place before left or right eye
Reviewed-by: Martin Leung
Acked-by: Tom Chung
Signed-off-by: Alvin Lee
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hubp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hubp.c
b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hubp.c
index af462fe4260d..b0fd8859bd2f 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hubp.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hubp.c
@@ -86,7 +86,7 @@ bool hubp3_program_surface_flip_and_addr(
VMID, address->vmid);
if (address->type == PLN_ADDR_TYPE_GRPH_STEREO) {
- REG_UPDATE(DCSURF_FLIP_CONTROL,
SURFACE_FLIP_MODE_FOR_STEREOSYNC, 0x1);
+ REG_UPDATE(DCSURF_FLIP_CONTROL,
SURFACE_FLIP_MODE_FOR_STEREOSYNC, 0);
REG_UPDATE(DCSURF_FLIP_CONTROL, SURFACE_FLIP_IN_STEREOSYNC,
0x1);
} else {
--
2.35.1
[PATCH AUTOSEL 5.15 13/20] drm/amdgpu: Increase tlb flush timeout for sriov
From: Dusica Milinkovic
[ Upstream commit 373008bfc9cdb0f050258947fa5a095f0657e1bc ]
[Why]
During multi-vf executing benchmark (Luxmark) observed kiq error timeout.
It happenes because all of VFs do the tlb invalidation at the same time.
Although each VF has the invalidate register set, from hardware side
the invalidate requests are queue to execute.
[How]
In case of 12 VF increase timeout on 12*100ms
Signed-off-by: Dusica Milinkovic
Acked-by: Shaoyun Liu
Acked-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 2 +-
drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 3 ++-
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 3 ++-
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 5f95d03fd46a..4f62f422bcb7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -312,7 +312,7 @@ enum amdgpu_kiq_irq {
AMDGPU_CP_KIQ_IRQ_DRIVER0 = 0,
AMDGPU_CP_KIQ_IRQ_LAST
};
-
+#define SRIOV_USEC_TIMEOUT 120 /* wait 12 * 100ms for SRIOV */
#define MAX_KIQ_REG_WAIT 5000 /* in usecs, 5ms */
#define MAX_KIQ_REG_BAILOUT_INTERVAL 5 /* in msecs, 5ms */
#define MAX_KIQ_REG_TRY 1000
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
index 93a4da4284ed..9c07ec8b9732 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
@@ -414,6 +414,7 @@ static int gmc_v10_0_flush_gpu_tlb_pasid(struct
amdgpu_device *adev,
uint32_t seq;
uint16_t queried_pasid;
bool ret;
+ u32 usec_timeout = amdgpu_sriov_vf(adev) ? SRIOV_USEC_TIMEOUT :
adev->usec_timeout;
struct amdgpu_ring *ring = &adev->gfx.kiq.ring;
struct amdgpu_kiq *kiq = &adev->gfx.kiq;
@@ -432,7 +433,7 @@ static int gmc_v10_0_flush_gpu_tlb_pasid(struct
amdgpu_device *adev,
amdgpu_ring_commit(ring);
spin_unlock(&adev->gfx.kiq.ring_lock);
- r = amdgpu_fence_wait_polling(ring, seq, adev->usec_timeout);
+ r = amdgpu_fence_wait_polling(ring, seq, usec_timeout);
if (r < 1) {
dev_err(adev->dev, "wait for kiq fence error: %ld.\n",
r);
return -ETIME;
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index 0e731016921b..70d24b522df8 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
@@ -863,6 +863,7 @@ static int gmc_v9_0_flush_gpu_tlb_pasid(struct
amdgpu_device *adev,
uint32_t seq;
uint16_t queried_pasid;
bool ret;
+ u32 usec_timeout = amdgpu_sriov_vf(adev) ? SRIOV_USEC_TIMEOUT :
adev->usec_timeout;
struct amdgpu_ring *ring = &adev->gfx.kiq.ring;
struct amdgpu_kiq *kiq = &adev->gfx.kiq;
@@ -902,7 +903,7 @@ static int gmc_v9_0_flush_gpu_tlb_pasid(struct
amdgpu_device *adev,
amdgpu_ring_commit(ring);
spin_unlock(&adev->gfx.kiq.ring_lock);
- r = amdgpu_fence_wait_polling(ring, seq, adev->usec_timeout);
+ r = amdgpu_fence_wait_polling(ring, seq, usec_timeout);
if (r < 1) {
dev_err(adev->dev, "wait for kiq fence error: %ld.\n",
r);
up_read(&adev->reset_sem);
--
2.35.1
[PATCH AUTOSEL 5.15 14/20] drm/amd/display: avoid doing vm_init multiple time
From: Charlene Liu
[ Upstream commit 5544a7b5a07480192eb5fd3536462faed2c21528 ]
[why]
this is to ensure that driver will not reprogram hvm_prefetch_req again if
it is done.
Reviewed-by: Martin Leung
Acked-by: Brian Chang
Signed-off-by: Charlene Liu
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c
b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c
index 36044cb8ec83..1c0f56d8ba8b 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c
@@ -67,9 +67,15 @@ static uint32_t convert_and_clamp(
void dcn21_dchvm_init(struct hubbub *hubbub)
{
struct dcn20_hubbub *hubbub1 = TO_DCN20_HUBBUB(hubbub);
- uint32_t riommu_active;
+ uint32_t riommu_active, prefetch_done;
int i;
+ REG_GET(DCHVM_RIOMMU_STAT0, HOSTVM_PREFETCH_DONE, &prefetch_done);
+
+ if (prefetch_done) {
+ hubbub->riommu_active = true;
+ return;
+ }
//Init DCHVM block
REG_UPDATE(DCHVM_CTRL0, HOSTVM_INIT_REQ, 1);
--
2.35.1
[PATCH AUTOSEL 5.15 11/20] drm/amd/pm: add missing ->fini_microcode interface for Sienna Cichlid
From: Evan Quan
[ Upstream commit 0a2d922a5618377cdf8fa476351362733ef55342 ]
To avoid any potential memory leak.
Signed-off-by: Evan Quan
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
index 918d5c7c2328..79976921dc46 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
@@ -3915,6 +3915,7 @@ static const struct pptable_funcs
sienna_cichlid_ppt_funcs = {
.dump_pptable = sienna_cichlid_dump_pptable,
.init_microcode = smu_v11_0_init_microcode,
.load_microcode = smu_v11_0_load_microcode,
+ .fini_microcode = smu_v11_0_fini_microcode,
.init_smc_tables = sienna_cichlid_init_smc_tables,
.fini_smc_tables = smu_v11_0_fini_smc_tables,
.init_power = smu_v11_0_init_power,
--
2.35.1
[PATCH AUTOSEL 5.15 12/20] drm/amd/display: Fix pixel clock programming
From: Ilya Bakoulin
[ Upstream commit 04fb918bf421b299feaee1006e82921d7d381f18 ]
[Why]
Some pixel clock values could cause HDMI TMDS SSCPs to be misaligned
between different HDMI lanes when using YCbCr420 10-bit pixel format.
BIOS functions for transmitter/encoder control take pixel clock in kHz
increments, whereas the function for setting the pixel clock is in 100Hz
increments. Setting pixel clock to a value that is not on a kHz boundary
will cause the issue.
[How]
Round pixel clock down to nearest kHz in 10/12-bpc cases.
Reviewed-by: Aric Cyr
Acked-by: Brian Chang
Signed-off-by: Ilya Bakoulin
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c | 2 ++
1 file changed, 2 insertions(+)
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 054823d12403..5f1b735da506 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
@@ -545,9 +545,11 @@ static void dce112_get_pix_clk_dividers_helper (
switch (pix_clk_params->color_depth) {
case COLOR_DEPTH_101010:
actual_pixel_clock_100hz = (actual_pixel_clock_100hz *
5) >> 2;
+ actual_pixel_clock_100hz -= actual_pixel_clock_100hz %
10;
break;
case COLOR_DEPTH_121212:
actual_pixel_clock_100hz = (actual_pixel_clock_100hz *
6) >> 2;
+ actual_pixel_clock_100hz -= actual_pixel_clock_100hz %
10;
break;
case COLOR_DEPTH_161616:
actual_pixel_clock_100hz = actual_pixel_clock_100hz * 2;
--
2.35.1
[PATCH AUTOSEL 5.19 25/38] drm/amdgpu: Increase tlb flush timeout for sriov
From: Dusica Milinkovic
[ Upstream commit 373008bfc9cdb0f050258947fa5a095f0657e1bc ]
[Why]
During multi-vf executing benchmark (Luxmark) observed kiq error timeout.
It happenes because all of VFs do the tlb invalidation at the same time.
Although each VF has the invalidate register set, from hardware side
the invalidate requests are queue to execute.
[How]
In case of 12 VF increase timeout on 12*100ms
Signed-off-by: Dusica Milinkovic
Acked-by: Shaoyun Liu
Acked-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 2 +-
drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 3 ++-
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 3 ++-
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 30ce6bb6fa77..310754b1f670 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -313,7 +313,7 @@ enum amdgpu_kiq_irq {
AMDGPU_CP_KIQ_IRQ_DRIVER0 = 0,
AMDGPU_CP_KIQ_IRQ_LAST
};
-
+#define SRIOV_USEC_TIMEOUT 120 /* wait 12 * 100ms for SRIOV */
#define MAX_KIQ_REG_WAIT 5000 /* in usecs, 5ms */
#define MAX_KIQ_REG_BAILOUT_INTERVAL 5 /* in msecs, 5ms */
#define MAX_KIQ_REG_TRY 1000
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
index 9077dfccaf3c..809408c8c79a 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
@@ -416,6 +416,7 @@ static int gmc_v10_0_flush_gpu_tlb_pasid(struct
amdgpu_device *adev,
uint32_t seq;
uint16_t queried_pasid;
bool ret;
+ u32 usec_timeout = amdgpu_sriov_vf(adev) ? SRIOV_USEC_TIMEOUT :
adev->usec_timeout;
struct amdgpu_ring *ring = &adev->gfx.kiq.ring;
struct amdgpu_kiq *kiq = &adev->gfx.kiq;
@@ -434,7 +435,7 @@ static int gmc_v10_0_flush_gpu_tlb_pasid(struct
amdgpu_device *adev,
amdgpu_ring_commit(ring);
spin_unlock(&adev->gfx.kiq.ring_lock);
- r = amdgpu_fence_wait_polling(ring, seq, adev->usec_timeout);
+ r = amdgpu_fence_wait_polling(ring, seq, usec_timeout);
if (r < 1) {
dev_err(adev->dev, "wait for kiq fence error: %ld.\n",
r);
return -ETIME;
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index 22761a3bb818..566c1243c051 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
@@ -896,6 +896,7 @@ static int gmc_v9_0_flush_gpu_tlb_pasid(struct
amdgpu_device *adev,
uint32_t seq;
uint16_t queried_pasid;
bool ret;
+ u32 usec_timeout = amdgpu_sriov_vf(adev) ? SRIOV_USEC_TIMEOUT :
adev->usec_timeout;
struct amdgpu_ring *ring = &adev->gfx.kiq.ring;
struct amdgpu_kiq *kiq = &adev->gfx.kiq;
@@ -935,7 +936,7 @@ static int gmc_v9_0_flush_gpu_tlb_pasid(struct
amdgpu_device *adev,
amdgpu_ring_commit(ring);
spin_unlock(&adev->gfx.kiq.ring_lock);
- r = amdgpu_fence_wait_polling(ring, seq, adev->usec_timeout);
+ r = amdgpu_fence_wait_polling(ring, seq, usec_timeout);
if (r < 1) {
dev_err(adev->dev, "wait for kiq fence error: %ld.\n",
r);
up_read(&adev->reset_domain->sem);
--
2.35.1
[PATCH AUTOSEL 5.15 06/20] drm/amd/display: clear optc underflow before turn off odm clock
From: Fudong Wang
[ Upstream commit b2a93490201300a749ad261b5c5d05cb50179c44 ]
[Why]
After ODM clock off, optc underflow bit will be kept there always and clear not
work.
We need to clear that before clock off.
[How]
Clear that if have when clock off.
Reviewed-by: Alvin Lee
Acked-by: Tom Chung
Signed-off-by: Fudong Wang
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c
index 37848f4577b1..92fee47278e5 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c
@@ -480,6 +480,11 @@ void optc1_enable_optc_clock(struct timing_generator
*optc, bool enable)
OTG_CLOCK_ON, 1,
1, 1000);
} else {
+
+ //last chance to clear underflow, otherwise, it will always
there due to clock is off.
+ if (optc->funcs->is_optc_underflow_occurred(optc) == true)
+ optc->funcs->clear_optc_underflow(optc);
+
REG_UPDATE_2(OTG_CLOCK_CONTROL,
OTG_CLOCK_GATE_DIS, 0,
OTG_CLOCK_EN, 0);
--
2.35.1
[PATCH AUTOSEL 5.15 04/20] drm/amd/display: Fix HDMI VSIF V3 incorrect issue
From: Leo Ma
[ Upstream commit 0591183699fceeafb4c4141072d47775de83ecfb ]
[Why]
Reported from customer the checksum in AMD VSIF V3 is incorrect and
causing blank screen issue.
[How]
Fix the packet length issue on AMD HDMI VSIF V3.
Reviewed-by: Anthony Koo
Acked-by: Tom Chung
Signed-off-by: Leo Ma
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../drm/amd/display/modules/freesync/freesync.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
index b99aa232bd8b..4bee6d018bfa 100644
--- a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
+++ b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
@@ -567,10 +567,6 @@ static void build_vrr_infopacket_data_v1(const struct
mod_vrr_params *vrr,
* Note: We should never go above the field rate of the mode timing set.
*/
infopacket->sb[8] = (unsigned char)((vrr->max_refresh_in_uhz + 50)
/ 100);
-
- /* FreeSync HDR */
- infopacket->sb[9] = 0;
- infopacket->sb[10] = 0;
}
static void build_vrr_infopacket_data_v3(const struct mod_vrr_params *vrr,
@@ -638,10 +634,6 @@ static void build_vrr_infopacket_data_v3(const struct
mod_vrr_params *vrr,
/* PB16 : Reserved bits 7:1, FixedRate bit 0 */
infopacket->sb[16] = (vrr->state == VRR_STATE_ACTIVE_FIXED) ? 1 : 0;
-
- //FreeSync HDR
- infopacket->sb[9] = 0;
- infopacket->sb[10] = 0;
}
static void build_vrr_infopacket_fs2_data(enum color_transfer_func app_tf,
@@ -726,8 +718,7 @@ static void build_vrr_infopacket_header_v2(enum signal_type
signal,
/* HB2 = [Bits 7:5 = 0] [Bits 4:0 = Length = 0x09] */
infopacket->hb2 = 0x09;
- *payload_size = 0x0A;
-
+ *payload_size = 0x09;
} else if (dc_is_dp_signal(signal)) {
/* HEADER */
@@ -776,9 +767,9 @@ static void build_vrr_infopacket_header_v3(enum signal_type
signal,
infopacket->hb1 = version;
/* HB2 = [Bits 7:5 = 0] [Bits 4:0 = Length] */
- *payload_size = 0x10;
- infopacket->hb2 = *payload_size - 1; //-1 for checksum
+ infopacket->hb2 = 0x10;
+ *payload_size = 0x10;
} else if (dc_is_dp_signal(signal)) {
/* HEADER */
--
2.35.1
[PATCH AUTOSEL 5.15 05/20] drm/amd/display: For stereo keep "FLIP_ANY_FRAME"
From: Alvin Lee
[ Upstream commit 84ef99c728079dfd21d6bc70b4c3e4af20602b3c ]
[Description]
Observed in stereomode that programming FLIP_LEFT_EYE
can cause hangs. Keep FLIP_ANY_FRAME in stereo mode so
the surface flip can take place before left or right eye
Reviewed-by: Martin Leung
Acked-by: Tom Chung
Signed-off-by: Alvin Lee
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hubp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hubp.c
b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hubp.c
index f24612523248..33c2337c4edf 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hubp.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hubp.c
@@ -86,7 +86,7 @@ bool hubp3_program_surface_flip_and_addr(
VMID, address->vmid);
if (address->type == PLN_ADDR_TYPE_GRPH_STEREO) {
- REG_UPDATE(DCSURF_FLIP_CONTROL,
SURFACE_FLIP_MODE_FOR_STEREOSYNC, 0x1);
+ REG_UPDATE(DCSURF_FLIP_CONTROL,
SURFACE_FLIP_MODE_FOR_STEREOSYNC, 0);
REG_UPDATE(DCSURF_FLIP_CONTROL, SURFACE_FLIP_IN_STEREOSYNC,
0x1);
} else {
--
2.35.1
[PATCH AUTOSEL 5.15 03/20] drm/amd/display: Avoid MPC infinite loop
From: Josip Pavic
[ Upstream commit 8de297dc046c180651c0500f8611663ae1c3828a ]
[why]
In some cases MPC tree bottom pipe ends up point to itself. This causes
iterating from top to bottom to hang the system in an infinite loop.
[how]
When looping to next MPC bottom pipe, check that the pointer is not same
as current to avoid infinite loop.
Reviewed-by: Josip Pavic
Reviewed-by: Jun Lei
Acked-by: Alex Hung
Signed-off-by: Aric Cyr
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_mpc.c | 6 ++
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_mpc.c | 6 ++
2 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_mpc.c
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_mpc.c
index 11019c2c62cc..8192f1967e92 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_mpc.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_mpc.c
@@ -126,6 +126,12 @@ struct mpcc *mpc1_get_mpcc_for_dpp(struct mpc_tree *tree,
int dpp_id)
while (tmp_mpcc != NULL) {
if (tmp_mpcc->dpp_id == dpp_id)
return tmp_mpcc;
+
+ /* avoid circular linked list */
+ ASSERT(tmp_mpcc != tmp_mpcc->mpcc_bot);
+ if (tmp_mpcc == tmp_mpcc->mpcc_bot)
+ break;
+
tmp_mpcc = tmp_mpcc->mpcc_bot;
}
return NULL;
diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_mpc.c
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_mpc.c
index 947eb0df3f12..142fc0a3a536 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_mpc.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_mpc.c
@@ -532,6 +532,12 @@ struct mpcc *mpc2_get_mpcc_for_dpp(struct mpc_tree *tree,
int dpp_id)
while (tmp_mpcc != NULL) {
if (tmp_mpcc->dpp_id == 0xf || tmp_mpcc->dpp_id == dpp_id)
return tmp_mpcc;
+
+ /* avoid circular linked list */
+ ASSERT(tmp_mpcc != tmp_mpcc->mpcc_bot);
+ if (tmp_mpcc == tmp_mpcc->mpcc_bot)
+ break;
+
tmp_mpcc = tmp_mpcc->mpcc_bot;
}
return NULL;
--
2.35.1
[PATCH AUTOSEL 5.19 24/38] drm/amd/display: Fix pixel clock programming
From: Ilya Bakoulin
[ Upstream commit 04fb918bf421b299feaee1006e82921d7d381f18 ]
[Why]
Some pixel clock values could cause HDMI TMDS SSCPs to be misaligned
between different HDMI lanes when using YCbCr420 10-bit pixel format.
BIOS functions for transmitter/encoder control take pixel clock in kHz
increments, whereas the function for setting the pixel clock is in 100Hz
increments. Setting pixel clock to a value that is not on a kHz boundary
will cause the issue.
[How]
Round pixel clock down to nearest kHz in 10/12-bpc cases.
Reviewed-by: Aric Cyr
Acked-by: Brian Chang
Signed-off-by: Ilya Bakoulin
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c | 2 ++
1 file changed, 2 insertions(+)
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 845aa8a1027d..c4040adb88b0 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
@@ -545,9 +545,11 @@ static void dce112_get_pix_clk_dividers_helper (
switch (pix_clk_params->color_depth) {
case COLOR_DEPTH_101010:
actual_pixel_clock_100hz = (actual_pixel_clock_100hz *
5) >> 2;
+ actual_pixel_clock_100hz -= actual_pixel_clock_100hz %
10;
break;
case COLOR_DEPTH_121212:
actual_pixel_clock_100hz = (actual_pixel_clock_100hz *
6) >> 2;
+ actual_pixel_clock_100hz -= actual_pixel_clock_100hz %
10;
break;
case COLOR_DEPTH_161616:
actual_pixel_clock_100hz = actual_pixel_clock_100hz * 2;
--
2.35.1
[PATCH AUTOSEL 5.19 30/38] drm/amdgpu: Fix interrupt handling on ih_soft ring
From: Mukul Joshi
[ Upstream commit de8341ee3ce7316883e836a2c4e9bf01ab651e0f ]
There are no backing hardware registers for ih_soft ring.
As a result, don't try to access hardware registers for read
and write pointers when processing interrupts on the IH soft
ring.
Signed-off-by: Mukul Joshi
Acked-by: Christian König
Reviewed-by: Felix Kuehling
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/navi10_ih.c | 7 ++-
drivers/gpu/drm/amd/amdgpu/vega10_ih.c | 7 ++-
drivers/gpu/drm/amd/amdgpu/vega20_ih.c | 7 ++-
3 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/navi10_ih.c
b/drivers/gpu/drm/amd/amdgpu/navi10_ih.c
index 4b5396d3e60f..eec13cb5bf75 100644
--- a/drivers/gpu/drm/amd/amdgpu/navi10_ih.c
+++ b/drivers/gpu/drm/amd/amdgpu/navi10_ih.c
@@ -409,9 +409,11 @@ static u32 navi10_ih_get_wptr(struct amdgpu_device *adev,
u32 wptr, tmp;
struct amdgpu_ih_regs *ih_regs;
- if (ih == &adev->irq.ih) {
+ if (ih == &adev->irq.ih || ih == &adev->irq.ih_soft) {
/* Only ring0 supports writeback. On other rings fall back
* to register-based code with overflow checking below.
+* ih_soft ring doesn't have any backing hardware registers,
+* update wptr and return.
*/
wptr = le32_to_cpu(*ih->wptr_cpu);
@@ -483,6 +485,9 @@ static void navi10_ih_set_rptr(struct amdgpu_device *adev,
{
struct amdgpu_ih_regs *ih_regs;
+ if (ih == &adev->irq.ih_soft)
+ return;
+
if (ih->use_doorbell) {
/* XXX check if swapping is necessary on BE */
*ih->rptr_cpu = ih->rptr;
diff --git a/drivers/gpu/drm/amd/amdgpu/vega10_ih.c
b/drivers/gpu/drm/amd/amdgpu/vega10_ih.c
index cdd599a08125..03b7066471f9 100644
--- a/drivers/gpu/drm/amd/amdgpu/vega10_ih.c
+++ b/drivers/gpu/drm/amd/amdgpu/vega10_ih.c
@@ -334,9 +334,11 @@ static u32 vega10_ih_get_wptr(struct amdgpu_device *adev,
u32 wptr, tmp;
struct amdgpu_ih_regs *ih_regs;
- if (ih == &adev->irq.ih) {
+ if (ih == &adev->irq.ih || ih == &adev->irq.ih_soft) {
/* Only ring0 supports writeback. On other rings fall back
* to register-based code with overflow checking below.
+* ih_soft ring doesn't have any backing hardware registers,
+* update wptr and return.
*/
wptr = le32_to_cpu(*ih->wptr_cpu);
@@ -409,6 +411,9 @@ static void vega10_ih_set_rptr(struct amdgpu_device *adev,
{
struct amdgpu_ih_regs *ih_regs;
+ if (ih == &adev->irq.ih_soft)
+ return;
+
if (ih->use_doorbell) {
/* XXX check if swapping is necessary on BE */
*ih->rptr_cpu = ih->rptr;
diff --git a/drivers/gpu/drm/amd/amdgpu/vega20_ih.c
b/drivers/gpu/drm/amd/amdgpu/vega20_ih.c
index 3b4eb8285943..2022ffbb8dba 100644
--- a/drivers/gpu/drm/amd/amdgpu/vega20_ih.c
+++ b/drivers/gpu/drm/amd/amdgpu/vega20_ih.c
@@ -385,9 +385,11 @@ static u32 vega20_ih_get_wptr(struct amdgpu_device *adev,
u32 wptr, tmp;
struct amdgpu_ih_regs *ih_regs;
- if (ih == &adev->irq.ih) {
+ if (ih == &adev->irq.ih || ih == &adev->irq.ih_soft) {
/* Only ring0 supports writeback. On other rings fall back
* to register-based code with overflow checking below.
+* ih_soft ring doesn't have any backing hardware registers,
+* update wptr and return.
*/
wptr = le32_to_cpu(*ih->wptr_cpu);
@@ -461,6 +463,9 @@ static void vega20_ih_set_rptr(struct amdgpu_device *adev,
{
struct amdgpu_ih_regs *ih_regs;
+ if (ih == &adev->irq.ih_soft)
+ return;
+
if (ih->use_doorbell) {
/* XXX check if swapping is necessary on BE */
*ih->rptr_cpu = ih->rptr;
--
2.35.1
[PATCH AUTOSEL 5.19 27/38] drm/amd/display: avoid doing vm_init multiple time
From: Charlene Liu
[ Upstream commit 5544a7b5a07480192eb5fd3536462faed2c21528 ]
[why]
this is to ensure that driver will not reprogram hvm_prefetch_req again if
it is done.
Reviewed-by: Martin Leung
Acked-by: Brian Chang
Signed-off-by: Charlene Liu
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c
b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c
index c5e200d09038..5752271f22df 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c
@@ -67,9 +67,15 @@ static uint32_t convert_and_clamp(
void dcn21_dchvm_init(struct hubbub *hubbub)
{
struct dcn20_hubbub *hubbub1 = TO_DCN20_HUBBUB(hubbub);
- uint32_t riommu_active;
+ uint32_t riommu_active, prefetch_done;
int i;
+ REG_GET(DCHVM_RIOMMU_STAT0, HOSTVM_PREFETCH_DONE, &prefetch_done);
+
+ if (prefetch_done) {
+ hubbub->riommu_active = true;
+ return;
+ }
//Init DCHVM block
REG_UPDATE(DCHVM_CTRL0, HOSTVM_INIT_REQ, 1);
--
2.35.1
[PATCH AUTOSEL 5.19 29/38] drm/amdgpu: Add secure display TA load for Renoir
From: Shane Xiao
[ Upstream commit e42dfa66d59240afbdd8d4b47b87486db39504aa ]
Add secure display TA load for Renoir
Signed-off-by: Shane Xiao
Reviewed-by: Aaron Liu
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/psp_v12_0.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c
b/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c
index a2588200ea58..0b2ac418e4ac 100644
--- a/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c
@@ -101,6 +101,16 @@ static int psp_v12_0_init_microcode(struct psp_context
*psp)
adev->psp.dtm_context.context.bin_desc.start_addr =
(uint8_t
*)adev->psp.hdcp_context.context.bin_desc.start_addr +
le32_to_cpu(ta_hdr->dtm.offset_bytes);
+
+ if (adev->apu_flags & AMD_APU_IS_RENOIR) {
+
adev->psp.securedisplay_context.context.bin_desc.fw_version =
+ le32_to_cpu(ta_hdr->securedisplay.fw_version);
+
adev->psp.securedisplay_context.context.bin_desc.size_bytes =
+ le32_to_cpu(ta_hdr->securedisplay.size_bytes);
+
adev->psp.securedisplay_context.context.bin_desc.start_addr =
+ (uint8_t
*)adev->psp.hdcp_context.context.bin_desc.start_addr +
+ le32_to_cpu(ta_hdr->securedisplay.offset_bytes);
+ }
}
return 0;
--
2.35.1
[PATCH AUTOSEL 5.19 28/38] drm/amdgpu: Add decode_iv_ts helper for ih_v6 block
From: Harish Kasiviswanathan
[ Upstream commit 1af9add1f1512b10d9ce44ec7137612bc81ff069 ]
Was missing. Add it.
Signed-off-by: Harish Kasiviswanathan
Reviewed-by: Hawking Zhang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/ih_v6_0.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/ih_v6_0.c
b/drivers/gpu/drm/amd/amdgpu/ih_v6_0.c
index 92dc60a9d209..085e613f3646 100644
--- a/drivers/gpu/drm/amd/amdgpu/ih_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/ih_v6_0.c
@@ -727,6 +727,7 @@ static const struct amd_ip_funcs ih_v6_0_ip_funcs = {
static const struct amdgpu_ih_funcs ih_v6_0_funcs = {
.get_wptr = ih_v6_0_get_wptr,
.decode_iv = amdgpu_ih_decode_iv_helper,
+ .decode_iv_ts = amdgpu_ih_decode_iv_ts_helper,
.set_rptr = ih_v6_0_set_rptr
};
--
2.35.1
[PATCH AUTOSEL 5.19 26/38] drm/amd/display: Fix plug/unplug external monitor will hang while playback MPO video
From: Tom Chung
[ Upstream commit e98459c06e3d45c2229b097f7b8cdd412357fa2f ]
[Why]
Pipes for MPO primary and overlay will be power down and power up during
plug/unplug external monitor while MPO video playback.
But the pipes were the same after plug/unplug and should not need to be
power down and power up or it will make page flip interrupt disabled and
cause hang issue.
[How]
Add pipe split change condition that not only check the top pipe pointer
but also check the index of top pipe if both top pipes are available.
Reviewed-by: Sun peng Li
Acked-by: Brian Chang
Signed-off-by: Tom Chung
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 7d69341acca0..9dbd965d8afb 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -1067,8 +1067,15 @@ static void disable_dangling_plane(struct dc *dc, struct
dc_state *context)
struct dc_stream_state *old_stream =
dc->current_state->res_ctx.pipe_ctx[i].stream;
bool should_disable = true;
- bool pipe_split_change =
- context->res_ctx.pipe_ctx[i].top_pipe !=
dc->current_state->res_ctx.pipe_ctx[i].top_pipe;
+ bool pipe_split_change = false;
+
+ if ((context->res_ctx.pipe_ctx[i].top_pipe) &&
+ (dc->current_state->res_ctx.pipe_ctx[i].top_pipe))
+ pipe_split_change =
context->res_ctx.pipe_ctx[i].top_pipe->pipe_idx !=
+
dc->current_state->res_ctx.pipe_ctx[i].top_pipe->pipe_idx;
+ else
+ pipe_split_change =
context->res_ctx.pipe_ctx[i].top_pipe !=
+ dc->current_state->res_ctx.pipe_ctx[i].top_pipe;
for (j = 0; j < context->stream_count; j++) {
if (old_stream == context->streams[j]) {
--
2.35.1
[PATCH AUTOSEL 5.19 23/38] drm/amd/pm: add missing ->fini_xxxx interfaces for some SMU13 asics
From: Evan Quan
[ Upstream commit 4bac1c846eff8042dd59ddecd0a43f3b9de5fd23 ]
Without these, potential memory leak may be induced.
Signed-off-by: Evan Quan
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 2 ++
drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
index 7432b3e76d3d..201546c36994 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
@@ -1583,7 +1583,9 @@ static const struct pptable_funcs smu_v13_0_0_ppt_funcs =
{
.dump_pptable = smu_v13_0_0_dump_pptable,
.init_microcode = smu_v13_0_init_microcode,
.load_microcode = smu_v13_0_load_microcode,
+ .fini_microcode = smu_v13_0_fini_microcode,
.init_smc_tables = smu_v13_0_0_init_smc_tables,
+ .fini_smc_tables = smu_v13_0_fini_smc_tables,
.init_power = smu_v13_0_init_power,
.fini_power = smu_v13_0_fini_power,
.check_fw_status = smu_v13_0_check_fw_status,
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 4e1861fb2c6a..9cde13b07dd2 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
@@ -1539,7 +1539,9 @@ static const struct pptable_funcs smu_v13_0_7_ppt_funcs =
{
.dump_pptable = smu_v13_0_7_dump_pptable,
.init_microcode = smu_v13_0_init_microcode,
.load_microcode = smu_v13_0_load_microcode,
+ .fini_microcode = smu_v13_0_fini_microcode,
.init_smc_tables = smu_v13_0_7_init_smc_tables,
+ .fini_smc_tables = smu_v13_0_fini_smc_tables,
.init_power = smu_v13_0_init_power,
.check_fw_status = smu_v13_0_7_check_fw_status,
.setup_pptable = smu_v13_0_7_setup_pptable,
--
2.35.1
[PATCH AUTOSEL 5.19 22/38] drm/amd/pm: add missing ->fini_microcode interface for Sienna Cichlid
From: Evan Quan
[ Upstream commit 0a2d922a5618377cdf8fa476351362733ef55342 ]
To avoid any potential memory leak.
Signed-off-by: Evan Quan
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
index 78f3d9e722bb..32bb6b1d9526 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
@@ -4281,6 +4281,7 @@ static const struct pptable_funcs
sienna_cichlid_ppt_funcs = {
.dump_pptable = sienna_cichlid_dump_pptable,
.init_microcode = smu_v11_0_init_microcode,
.load_microcode = smu_v11_0_load_microcode,
+ .fini_microcode = smu_v11_0_fini_microcode,
.init_smc_tables = sienna_cichlid_init_smc_tables,
.fini_smc_tables = smu_v11_0_fini_smc_tables,
.init_power = smu_v11_0_init_power,
--
2.35.1
[PATCH AUTOSEL 5.19 21/38] drm/amdgpu: disable 3DCGCG/CGLS temporarily due to stability issue
From: Evan Quan [ Upstream commit 1b586595df6d04c27088ef348b8202204ce26d45 ] Some stability issues were reported with these features. Signed-off-by: Evan Quan Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/soc21.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/soc21.c b/drivers/gpu/drm/amd/amdgpu/soc21.c index 9e18a2b22607..8d5c452a9100 100644 --- a/drivers/gpu/drm/amd/amdgpu/soc21.c +++ b/drivers/gpu/drm/amd/amdgpu/soc21.c @@ -530,8 +530,10 @@ static int soc21_common_early_init(void *handle) case IP_VERSION(11, 0, 0): adev->cg_flags = AMD_CG_SUPPORT_GFX_CGCG | AMD_CG_SUPPORT_GFX_CGLS | +#if 0 AMD_CG_SUPPORT_GFX_3D_CGCG | AMD_CG_SUPPORT_GFX_3D_CGLS | +#endif AMD_CG_SUPPORT_GFX_MGCG | AMD_CG_SUPPORT_REPEATER_FGCG | AMD_CG_SUPPORT_GFX_FGCG | -- 2.35.1
[PATCH AUTOSEL 5.19 14/38] drm/amd/pm: Fix a potential gpu_metrics_table memory leak
From: Zhen Ni [ Upstream commit 5afb76522a0af0513b6dc01f84128a73206b051b ] Memory is allocated for gpu_metrics_table in smu_v13_0_4_init_smc_tables(), but not freed in smu_v13_0_4_fini_smc_tables(). This may cause memory leaks, fix it. Reviewed-by: Evan Quan Signed-off-by: Zhen Ni Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_4_ppt.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_4_ppt.c b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_4_ppt.c index 5a17b51aa0f9..7df360c25d51 100644 --- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_4_ppt.c +++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_4_ppt.c @@ -190,6 +190,9 @@ static int smu_v13_0_4_fini_smc_tables(struct smu_context *smu) kfree(smu_table->watermarks_table); smu_table->watermarks_table = NULL; + kfree(smu_table->gpu_metrics_table); + smu_table->gpu_metrics_table = NULL; + return 0; } -- 2.35.1
[PATCH AUTOSEL 5.19 08/38] drm/amd/display: Fix HDMI VSIF V3 incorrect issue
From: Leo Ma
[ Upstream commit 0591183699fceeafb4c4141072d47775de83ecfb ]
[Why]
Reported from customer the checksum in AMD VSIF V3 is incorrect and
causing blank screen issue.
[How]
Fix the packet length issue on AMD HDMI VSIF V3.
Reviewed-by: Anthony Koo
Acked-by: Tom Chung
Signed-off-by: Leo Ma
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../drm/amd/display/modules/freesync/freesync.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
index 03fa63d56fa6..948151e73573 100644
--- a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
+++ b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
@@ -615,10 +615,6 @@ static void build_vrr_infopacket_data_v1(const struct
mod_vrr_params *vrr,
* Note: We should never go above the field rate of the mode timing set.
*/
infopacket->sb[8] = (unsigned char)((vrr->max_refresh_in_uhz + 50)
/ 100);
-
- /* FreeSync HDR */
- infopacket->sb[9] = 0;
- infopacket->sb[10] = 0;
}
static void build_vrr_infopacket_data_v3(const struct mod_vrr_params *vrr,
@@ -686,10 +682,6 @@ static void build_vrr_infopacket_data_v3(const struct
mod_vrr_params *vrr,
/* PB16 : Reserved bits 7:1, FixedRate bit 0 */
infopacket->sb[16] = (vrr->state == VRR_STATE_ACTIVE_FIXED) ? 1 : 0;
-
- //FreeSync HDR
- infopacket->sb[9] = 0;
- infopacket->sb[10] = 0;
}
static void build_vrr_infopacket_fs2_data(enum color_transfer_func app_tf,
@@ -774,8 +766,7 @@ static void build_vrr_infopacket_header_v2(enum signal_type
signal,
/* HB2 = [Bits 7:5 = 0] [Bits 4:0 = Length = 0x09] */
infopacket->hb2 = 0x09;
- *payload_size = 0x0A;
-
+ *payload_size = 0x09;
} else if (dc_is_dp_signal(signal)) {
/* HEADER */
@@ -824,9 +815,9 @@ static void build_vrr_infopacket_header_v3(enum signal_type
signal,
infopacket->hb1 = version;
/* HB2 = [Bits 7:5 = 0] [Bits 4:0 = Length] */
- *payload_size = 0x10;
- infopacket->hb2 = *payload_size - 1; //-1 for checksum
+ infopacket->hb2 = 0x10;
+ *payload_size = 0x10;
} else if (dc_is_dp_signal(signal)) {
/* HEADER */
--
2.35.1
[PATCH AUTOSEL 5.19 09/38] drm/amd/display: For stereo keep "FLIP_ANY_FRAME"
From: Alvin Lee
[ Upstream commit 84ef99c728079dfd21d6bc70b4c3e4af20602b3c ]
[Description]
Observed in stereomode that programming FLIP_LEFT_EYE
can cause hangs. Keep FLIP_ANY_FRAME in stereo mode so
the surface flip can take place before left or right eye
Reviewed-by: Martin Leung
Acked-by: Tom Chung
Signed-off-by: Alvin Lee
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hubp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hubp.c
b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hubp.c
index 6a4dcafb9bba..dc3e8df706b3 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hubp.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hubp.c
@@ -86,7 +86,7 @@ bool hubp3_program_surface_flip_and_addr(
VMID, address->vmid);
if (address->type == PLN_ADDR_TYPE_GRPH_STEREO) {
- REG_UPDATE(DCSURF_FLIP_CONTROL,
SURFACE_FLIP_MODE_FOR_STEREOSYNC, 0x1);
+ REG_UPDATE(DCSURF_FLIP_CONTROL,
SURFACE_FLIP_MODE_FOR_STEREOSYNC, 0);
REG_UPDATE(DCSURF_FLIP_CONTROL, SURFACE_FLIP_IN_STEREOSYNC,
0x1);
} else {
--
2.35.1
[PATCH AUTOSEL 5.19 13/38] drm/amdkfd: Handle restart of kfd_ioctl_wait_events
From: Felix Kuehling
[ Upstream commit bea9a56afbc4b5a41ea579b8b0dc5e189b439504 ]
When kfd_ioctl_wait_events needs to restart due to a signal, we need to
update the timeout to account for the time already elapsed. We also need
to undo auto_reset of events that have signaled already, so that the
restarted ioctl will be able to count those signals again.
This fixes infinite hangs when kfd_ioctl_wait_events is interrupted by a
signal.
Signed-off-by: Felix Kuehling
Reviewed-and-tested-by: Xiaogang Chen
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 2 +-
drivers/gpu/drm/amd/amdkfd/kfd_events.c | 24
drivers/gpu/drm/amd/amdkfd/kfd_priv.h| 2 +-
3 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index 1c7016958d6d..bfca17ca399c 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -814,7 +814,7 @@ static int kfd_ioctl_wait_events(struct file *filp, struct
kfd_process *p,
err = kfd_wait_on_events(p, args->num_events,
(void __user *)args->events_ptr,
(args->wait_for_all != 0),
- args->timeout, &args->wait_result);
+ &args->timeout, &args->wait_result);
return err;
}
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_events.c
b/drivers/gpu/drm/amd/amdkfd/kfd_events.c
index 4df9c36146ba..cbc20d779e5a 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_events.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_events.c
@@ -895,7 +895,8 @@ static long user_timeout_to_jiffies(uint32_t
user_timeout_ms)
return msecs_to_jiffies(user_timeout_ms) + 1;
}
-static void free_waiters(uint32_t num_events, struct kfd_event_waiter *waiters)
+static void free_waiters(uint32_t num_events, struct kfd_event_waiter *waiters,
+bool undo_auto_reset)
{
uint32_t i;
@@ -904,6 +905,9 @@ static void free_waiters(uint32_t num_events, struct
kfd_event_waiter *waiters)
spin_lock(&waiters[i].event->lock);
remove_wait_queue(&waiters[i].event->wq,
&waiters[i].wait);
+ if (undo_auto_reset && waiters[i].activated &&
+ waiters[i].event && waiters[i].event->auto_reset)
+ set_event(waiters[i].event);
spin_unlock(&waiters[i].event->lock);
}
@@ -912,7 +916,7 @@ static void free_waiters(uint32_t num_events, struct
kfd_event_waiter *waiters)
int kfd_wait_on_events(struct kfd_process *p,
uint32_t num_events, void __user *data,
- bool all, uint32_t user_timeout_ms,
+ bool all, uint32_t *user_timeout_ms,
uint32_t *wait_result)
{
struct kfd_event_data __user *events =
@@ -921,7 +925,7 @@ int kfd_wait_on_events(struct kfd_process *p,
int ret = 0;
struct kfd_event_waiter *event_waiters = NULL;
- long timeout = user_timeout_to_jiffies(user_timeout_ms);
+ long timeout = user_timeout_to_jiffies(*user_timeout_ms);
event_waiters = alloc_event_waiters(num_events);
if (!event_waiters) {
@@ -971,15 +975,11 @@ int kfd_wait_on_events(struct kfd_process *p,
}
if (signal_pending(current)) {
- /*
-* This is wrong when a nonzero, non-infinite timeout
-* is specified. We need to use
-* ERESTARTSYS_RESTARTBLOCK, but struct restart_block
-* contains a union with data for each user and it's
-* in generic kernel code that I don't want to
-* touch yet.
-*/
ret = -ERESTARTSYS;
+ if (*user_timeout_ms != KFD_EVENT_TIMEOUT_IMMEDIATE &&
+ *user_timeout_ms != KFD_EVENT_TIMEOUT_INFINITE)
+ *user_timeout_ms = jiffies_to_msecs(
+ max(0l, timeout-1));
break;
}
@@ -1020,7 +1020,7 @@ int kfd_wait_on_events(struct kfd_process *p,
event_waiters, events);
out_unlock:
- free_waiters(num_events, event_waiters);
+ free_waiters(num_events, event_waiters, ret == -ERESTARTSYS);
mutex_unlock(&p->event_mutex);
out:
if (ret)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
index 2585d6e61d42..c6eec54b8102 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
@@ -1314,7 +1314,7 @@ void kfd_event_free_process(struct kfd_process
[PATCH AUTOSEL 5.19 11/38] drm/amd/display: Fix TDR eDP and USB4 display light up issue
From: Meenakshikumar Somasundaram
[ Upstream commit 30456ffa65469d1d2e5e1da05017e6728d24c11c ]
[Why]
After TDR recovery, eDP and USB4 display does not light up. Because
dmub outbox notifications are not enabled after dmub reload and link
encoder assignments for the streams are not cleared before dc state
reset.
[How]
- Dmub outbox notification is enabled after tdr recovery by issuing
inbox command to dmub.
- Link encoders for the streams are unassigned before dc state reset.
Reviewed-by: Jimmy Kizito
Reviewed-by: Jun Lei
Acked-by: Tom Chung
Signed-off-by: Meenakshikumar Somasundaram
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 1 +
drivers/gpu/drm/amd/display/dc/dc_link.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index f14449401188..7d69341acca0 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -3783,6 +3783,7 @@ void dc_enable_dmub_outbox(struct dc *dc)
struct dc_context *dc_ctx = dc->ctx;
dmub_enable_outbox_notification(dc_ctx->dmub_srv);
+ DC_LOG_DC("%s: dmub outbox notifications enabled\n", __func__);
}
/**
diff --git a/drivers/gpu/drm/amd/display/dc/dc_link.h
b/drivers/gpu/drm/amd/display/dc/dc_link.h
index a3c37ee3f849..f96f53c1bc25 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_link.h
+++ b/drivers/gpu/drm/amd/display/dc/dc_link.h
@@ -337,6 +337,7 @@ enum dc_detect_reason {
DETECT_REASON_HPDRX,
DETECT_REASON_FALLBACK,
DETECT_REASON_RETRAIN,
+ DETECT_REASON_TDR,
};
bool dc_link_detect(struct dc_link *dc_link, enum dc_detect_reason reason);
--
2.35.1
[PATCH AUTOSEL 5.19 12/38] drm/amd/pm: skip pptable override for smu_v13_0_7
From: Kenneth Feng
[ Upstream commit 4e64b529c5b04e7944b41de554ee686ecab00744 ]
skip pptable override for smu_v13_0_7 secure boards only.
Signed-off-by: Kenneth Feng
Reviewed-by: Feifei Xu
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
index 5aa08c031f72..1d8a9e5b3cc0 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
@@ -203,6 +203,9 @@ int smu_v13_0_init_pptable_microcode(struct smu_context
*smu)
if (!adev->scpm_enabled)
return 0;
+ if (adev->ip_versions[MP1_HWIP][0] == IP_VERSION(13, 0, 7))
+ return 0;
+
/* override pptable_id from driver parameter */
if (amdgpu_smu_pptable_id >= 0) {
pptable_id = amdgpu_smu_pptable_id;
@@ -210,13 +213,6 @@ int smu_v13_0_init_pptable_microcode(struct smu_context
*smu)
} else {
pptable_id = smu->smu_table.boot_values.pp_table_id;
- if (adev->ip_versions[MP1_HWIP][0] == IP_VERSION(13, 0, 7) &&
- pptable_id == 3667)
- pptable_id = 36671;
-
- if (adev->ip_versions[MP1_HWIP][0] == IP_VERSION(13, 0, 7) &&
- pptable_id == 3688)
- pptable_id = 36881;
/*
* Temporary solution for SMU V13.0.0 with SCPM enabled:
* - use 36831 signed pptable when pp_table_id is 3683
--
2.35.1
[PATCH AUTOSEL 5.19 10/38] drm/amd/display: clear optc underflow before turn off odm clock
From: Fudong Wang
[ Upstream commit b2a93490201300a749ad261b5c5d05cb50179c44 ]
[Why]
After ODM clock off, optc underflow bit will be kept there always and clear not
work.
We need to clear that before clock off.
[How]
Clear that if have when clock off.
Reviewed-by: Alvin Lee
Acked-by: Tom Chung
Signed-off-by: Fudong Wang
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c
index b1671b00ce40..2349977b0abb 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c
@@ -464,6 +464,11 @@ void optc1_enable_optc_clock(struct timing_generator
*optc, bool enable)
OTG_CLOCK_ON, 1,
1, 1000);
} else {
+
+ //last chance to clear underflow, otherwise, it will always
there due to clock is off.
+ if (optc->funcs->is_optc_underflow_occurred(optc) == true)
+ optc->funcs->clear_optc_underflow(optc);
+
REG_UPDATE_2(OTG_CLOCK_CONTROL,
OTG_CLOCK_GATE_DIS, 0,
OTG_CLOCK_EN, 0);
--
2.35.1
[PATCH AUTOSEL 5.19 07/38] drm/amd/display: Avoid MPC infinite loop
From: Josip Pavic
[ Upstream commit 8de297dc046c180651c0500f8611663ae1c3828a ]
[why]
In some cases MPC tree bottom pipe ends up point to itself. This causes
iterating from top to bottom to hang the system in an infinite loop.
[how]
When looping to next MPC bottom pipe, check that the pointer is not same
as current to avoid infinite loop.
Reviewed-by: Josip Pavic
Reviewed-by: Jun Lei
Acked-by: Alex Hung
Signed-off-by: Aric Cyr
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_mpc.c | 6 ++
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_mpc.c | 6 ++
2 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_mpc.c
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_mpc.c
index 11019c2c62cc..8192f1967e92 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_mpc.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_mpc.c
@@ -126,6 +126,12 @@ struct mpcc *mpc1_get_mpcc_for_dpp(struct mpc_tree *tree,
int dpp_id)
while (tmp_mpcc != NULL) {
if (tmp_mpcc->dpp_id == dpp_id)
return tmp_mpcc;
+
+ /* avoid circular linked list */
+ ASSERT(tmp_mpcc != tmp_mpcc->mpcc_bot);
+ if (tmp_mpcc == tmp_mpcc->mpcc_bot)
+ break;
+
tmp_mpcc = tmp_mpcc->mpcc_bot;
}
return NULL;
diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_mpc.c
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_mpc.c
index 15734db0cdea..f3c311d09319 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_mpc.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_mpc.c
@@ -531,6 +531,12 @@ static struct mpcc *mpc2_get_mpcc_for_dpp(struct mpc_tree
*tree, int dpp_id)
while (tmp_mpcc != NULL) {
if (tmp_mpcc->dpp_id == 0xf || tmp_mpcc->dpp_id == dpp_id)
return tmp_mpcc;
+
+ /* avoid circular linked list */
+ ASSERT(tmp_mpcc != tmp_mpcc->mpcc_bot);
+ if (tmp_mpcc == tmp_mpcc->mpcc_bot)
+ break;
+
tmp_mpcc = tmp_mpcc->mpcc_bot;
}
return NULL;
--
2.35.1
[PATCH AUTOSEL 5.19 06/38] drm/amd/display: Device flash garbage before get in OS
From: Chiawen Huang [ Upstream commit 9c580e8f6cd6524d4e2c3490c440110526f7ddd6 ] [Why] Enabling stream with tg lock makes config settings pending causing the garbage until tg unlock. [How] Keep the original lock mechanism The driver doesn't lock tg if plane_state is null. Reviewed-by: Anthony Koo Acked-by: Tom Chung Signed-off-by: Chiawen Huang Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c index e3a62873c0e7..d9ab27991535 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c +++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c @@ -108,6 +108,7 @@ void dcn10_lock_all_pipes(struct dc *dc, */ if (pipe_ctx->top_pipe || !pipe_ctx->stream || + !pipe_ctx->plane_state || !tg->funcs->is_tg_enabled(tg)) continue; -- 2.35.1
[PATCH AUTOSEL 5.19 05/38] drm/amd/display: Add a missing register field for HPO DP stream encoder
From: Aurabindo Pillai [ Upstream commit 37bc31f0e7da4fbad4664e64d906ae7b9009e550 ] [Why&How] Add the missing definition to set the register field HBLANK_MINIMUM_SYMBOL_WIDTH Signed-off-by: Aurabindo Pillai Acked-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- .../gpu/drm/amd/display/dc/dcn31/dcn31_hpo_dp_stream_encoder.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_hpo_dp_stream_encoder.h b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_hpo_dp_stream_encoder.h index 7c77c71591a0..82c3b3ac1f0d 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_hpo_dp_stream_encoder.h +++ b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_hpo_dp_stream_encoder.h @@ -162,7 +162,8 @@ SE_SF(DP_SYM32_ENC0_DP_SYM32_ENC_SDP_AUDIO_CONTROL0, AIP_ENABLE, mask_sh),\ SE_SF(DP_SYM32_ENC0_DP_SYM32_ENC_SDP_AUDIO_CONTROL0, ACM_ENABLE, mask_sh),\ SE_SF(DP_SYM32_ENC0_DP_SYM32_ENC_VID_CRC_CONTROL, CRC_ENABLE, mask_sh),\ - SE_SF(DP_SYM32_ENC0_DP_SYM32_ENC_VID_CRC_CONTROL, CRC_CONT_MODE_ENABLE, mask_sh) + SE_SF(DP_SYM32_ENC0_DP_SYM32_ENC_VID_CRC_CONTROL, CRC_CONT_MODE_ENABLE, mask_sh),\ + SE_SF(DP_SYM32_ENC0_DP_SYM32_ENC_HBLANK_CONTROL, HBLANK_MINIMUM_SYMBOL_WIDTH, mask_sh) #define DCN3_1_HPO_DP_STREAM_ENC_REG_FIELD_LIST(type) \ -- 2.35.1
Re: [BUG][5.20] refcount_t: underflow; use-after-free
On Fri, Aug 19, 2022 at 5:13 PM Maíra Canal wrote: > > Hi Mikhail, > > Could you please specify the steps to reproduce this use-after-free? I > will try to reproduce it on the RX5700 XT and bisect the issue. > Hi Maíra, thanks for help. I'm afraid that it will be unrealistic to reproduce, because on a laptop with 6800M (also RDNA 2 graphics) the problem does not repeat. Sorry for the long silence, but I was trying to bisect the problem myself. git bisect start # status: waiting for both good and bad commits # good: [3d7cb6b04c3f3115719235cc6866b10326de34cd] Linux 5.19 git bisect good 3d7cb6b04c3f3115719235cc6866b10326de34cd # status: waiting for bad commit, 1 good commit known # bad: [7ebfc85e2cd7b08f518b526173e9a33b56b3913b] Merge tag 'net-6.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net git bisect bad 7ebfc85e2cd7b08f518b526173e9a33b56b3913b # bad: [b44f2fd87919b5ae6e1756d4c7ba2cbba22238e1] Merge tag 'drm-next-2022-08-03' of git://anongit.freedesktop.org/drm/drm # 001: GPU hangs + use-after-free issue - https://pastebin.com/z86E9ydx git bisect bad b44f2fd87919b5ae6e1756d4c7ba2cbba22238e1 # good: [526942b8134cc34d25d27f95dfff98b8ce2f6fcd] Merge tag 'ata-5.20-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata # 002: good - https://pastebin.com/9qki65Sj git bisect good 526942b8134cc34d25d27f95dfff98b8ce2f6fcd # good: [45490ce2ff833c4ec0de66705e46ba41320860cb] nfp: flower: add support for tunnel offload without key ID # 003: good - https://pastebin.com/vHk5eRkw git bisect good 45490ce2ff833c4ec0de66705e46ba41320860cb # skip: [e23a5e14aa278858c2e3d81ec34e83aa9a4177c5] Backmerge tag 'v5.19-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into drm-next # 004: GPU not switched in graphic mode - https://pastebin.com/RmqCTMLD git bisect skip e23a5e14aa278858c2e3d81ec34e83aa9a4177c5 # bad: [b2065fb21d9a789b14f737ea90facedabadeb8a4] drm/amdgpu: fix i2s_pdata out of bound array access # 005: GPU hangs + use-after-free issue - https://pastebin.com/Zgw5Hc48 git bisect bad b2065fb21d9a789b14f737ea90facedabadeb8a4 # skip: [344feb7ccf764756937cfd74fa4ac5caba069c99] Merge tag 'amd-drm-next-5.20-2022-07-05' of https://gitlab.freedesktop.org/agd5f/linux into drm-next # 006: GPU not switched in graphic mode - https://pastebin.com/b8BUBE7Q git bisect skip 344feb7ccf764756937cfd74fa4ac5caba069c99 # skip: [869b10ac8d2300327f554d83f4dbab041bf27d49] drm/amdgpu: add dm ip block for dcn 3.1.4 # 007: GPU not switched in graphic mode - https://pastebin.com/byd7HECH git bisect skip 869b10ac8d2300327f554d83f4dbab041bf27d49 # skip: [676ad8e997036e2f815c293b76c356fb7cc97a08] drm: rcar-du: Lift z-pos restriction on primary plane for Gen3 # 008: GPU not switched in graphic mode - https://pastebin.com/3fXCTinb git bisect skip 676ad8e997036e2f815c293b76c356fb7cc97a08 # skip: [5c57cbc390b166950c2e6c2f0c4edaeb0f47e97d] drm/bridge: lt9211: Convert to drm_of_get_data_lanes_count # 009: Build error - https://pastebin.com/rxHe9QRB git bisect skip 5c57cbc390b166950c2e6c2f0c4edaeb0f47e97d # skip: [6db5e0c8692e590734a7ec7455365d9cbaa15ef1] Merge tag 'drm-intel-next-2022-07-06' of git://anongit.freedesktop.org/drm/drm-intel into drm-next # 010: GPU not switched in graphic mode - https://pastebin.com/rqubSuc8 git bisect skip 6db5e0c8692e590734a7ec7455365d9cbaa15ef1 # skip: [5d763a9955f0fbf2681a2f1fa87c416056bd0c89] drm/amd/display: Remove compiler warning # 011: GPU not switched in graphic mode - https://pastebin.com/BrJs6ybP git bisect skip 5d763a9955f0fbf2681a2f1fa87c416056bd0c89 # skip: [e6c2db2be986158afb9991d9fa8a38fe65a88516] drm/i915: Don't use DRM_DEBUG_WARN_ON for unexpected l3bank/mslice config # 012: GPU not switched in graphic mode - https://pastebin.com/yxppyqbD git bisect skip e6c2db2be986158afb9991d9fa8a38fe65a88516 # bad: [cb6b81b21bd9cf09d72b7fe711be1b55001eb166] Merge tag 'drm-misc-next-fixes-2022-07-21' of git://anongit.freedesktop.org/drm/drm-misc into drm-next # 013: GPU hangs without use-after-free issue - https://pastebin.com/iRek4bBy git bisect bad cb6b81b21bd9cf09d72b7fe711be1b55001eb166 # skip: [48b927770f8ad3f8cf4a024a552abf272af9f592] drm/exynos/exynos7_drm_decon: free resources when clk_set_parent() failed. # 014: GPU not switched in graphic mode - https://pastebin.com/ekp10xhP git bisect skip 48b927770f8ad3f8cf4a024a552abf272af9f592 # skip: [c5da61cf5bab30059f22ea368702c445ee87171a] drm/amdgpu/display: add missing FP_START/END checks dcn32_clk_mgr.c # 015: GPU not switched in graphic mode - https://pastebin.com/YbskKWmA git bisect skip c5da61cf5bab30059f22ea368702c445ee87171a # skip: [a77f7c89e62c6dfe405a64995812746f27adc510] drm/edid: convert drm_gtf_modes_for_range() to drm_edid # 016: GPU not switched in graphic mode - https://pastebin.com/bA2AwkJ7 git bisect skip a77f7c89e62c6dfe405a64995812746f27adc510 # skip: [6fde8eec71796f3534f0c274066862829813b21f] drm/doc: Add KUnit documentation # 017: GPU not switched in graphic mode - https://pasteb
[PATCH 0/4] Add support for atomic async page-flips
This series adds support for DRM_MODE_PAGE_FLIP_ASYNC for atomic commits, aka. "immediate flip" (which might result in tearing). The feature was only available via the legacy uAPI, however for gaming use-cases it may be desirable to enable it via the atomic uAPI too. User-space patch: https://github.com/Plagman/gamescope/pull/595 IGT patch: https://patchwork.freedesktop.org/series/107681/ Tested on an AMD Picasso iGPU. Simon Ser (4): drm: introduce drm_mode_config.atomic_async_page_flip_not_supported drm: allow DRM_MODE_PAGE_FLIP_ASYNC for atomic commits drm: introduce DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP amd/display: indicate support for atomic async page-flips on DCN drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 1 + drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 1 + drivers/gpu/drm/amd/amdgpu/dce_v6_0.c| 1 + drivers/gpu/drm/amd/amdgpu/dce_v8_0.c| 1 + drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 1 + drivers/gpu/drm/drm_atomic_uapi.c| 28 +--- drivers/gpu/drm/drm_ioctl.c | 5 drivers/gpu/drm/i915/display/intel_display.c | 1 + drivers/gpu/drm/nouveau/nouveau_display.c| 1 + drivers/gpu/drm/radeon/radeon_display.c | 1 + drivers/gpu/drm/vc4/vc4_kms.c| 1 + include/drm/drm_mode_config.h| 11 include/uapi/drm/drm.h | 10 ++- 13 files changed, 59 insertions(+), 4 deletions(-) -- 2.37.2
RE: [PATCH] drm/amdgpu: Update mes_v11_api_def.h
[AMD Official Use Only - General]
Reviewed-by: Harish Kasiviswanathan
-Original Message-
From: amd-gfx On Behalf Of Graham Sider
Sent: Wednesday, August 17, 2022 9:44 AM
To: amd-gfx@lists.freedesktop.org
Cc: Xiao, Jack ; Kuehling, Felix ;
Sider, Graham ; Zhang, Hawking
Subject: [PATCH] drm/amdgpu: Update mes_v11_api_def.h
New GFX11 MES FW adds the trap_en bit. For now hardcode to 1 (traps enabled).
Signed-off-by: Graham Sider
Acked-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/mes_v11_0.c| 1 +
drivers/gpu/drm/amd/include/mes_v11_api_def.h | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/mes_v11_0.c
b/drivers/gpu/drm/amd/amdgpu/mes_v11_0.c
index 120ea294abef..cc3fdbbcd314 100644
--- a/drivers/gpu/drm/amd/amdgpu/mes_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/mes_v11_0.c
@@ -183,6 +183,7 @@ static int mes_v11_0_add_hw_queue(struct amdgpu_mes *mes,
mes_add_queue_pkt.trap_handler_addr = input->tba_addr;
mes_add_queue_pkt.tma_addr = input->tma_addr;
mes_add_queue_pkt.is_kfd_process = input->is_kfd_process;
+ mes_add_queue_pkt.trap_en = 1;
return mes_v11_0_submit_pkt_and_poll_completion(mes,
&mes_add_queue_pkt, sizeof(mes_add_queue_pkt), diff
--git a/drivers/gpu/drm/amd/include/mes_v11_api_def.h
b/drivers/gpu/drm/amd/include/mes_v11_api_def.h
index 80dab1146439..50bfa513cb35 100644
--- a/drivers/gpu/drm/amd/include/mes_v11_api_def.h
+++ b/drivers/gpu/drm/amd/include/mes_v11_api_def.h
@@ -268,7 +268,8 @@ union MESAPI__ADD_QUEUE {
uint32_t is_tmz_queue : 1;
uint32_t map_kiq_utility_queue : 1;
uint32_t is_kfd_process : 1;
- uint32_t reserved : 22;
+ uint32_t trap_en: 1;
+ uint32_t reserved : 21;
};
struct MES_API_STATUS api_status;
uint64_ttma_addr;
--
2.25.1
RE: [PATCH] drm/amd/pm: update SMU 13.0.0 driver_if header
[AMD Official Use Only - General]
Reviewed-by: Feifei Xu
-Original Message-
From: amd-gfx On Behalf Of Evan Quan
Sent: Tuesday, August 23, 2022 9:23 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Quan, Evan
; Zhang, Hawking
Subject: [PATCH] drm/amd/pm: update SMU 13.0.0 driver_if header
To fit the latest 78.53 PMFW.
Signed-off-by: Evan Quan
Change-Id: I16b36a3c209c82fc2d48325f7e6ef5a702678782
---
.../inc/pmfw_if/smu13_driver_if_v13_0_0.h | 31 +++
drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h | 2 +-
2 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_0.h
b/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_0.h
index 78620b0bd279..f745cd8f1ab7 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_0.h
+++ b/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_0.h
@@ -24,12 +24,8 @@
#ifndef SMU13_DRIVER_IF_V13_0_0_H
#define SMU13_DRIVER_IF_V13_0_0_H
-// *** IMPORTANT ***
-// PMFW TEAM: Always increment the interface version on any change to this
file -#define SMU13_DRIVER_IF_VERSION 0x23
-
//Increment this version if SkuTable_t or BoardTable_t change -#define
PPTABLE_VERSION 0x1D
+#define PPTABLE_VERSION 0x22
#define NUM_GFXCLK_DPM_LEVELS16
#define NUM_SOCCLK_DPM_LEVELS8
@@ -1193,8 +1189,17 @@ typedef struct {
// SECTION: Advanced Options
uint32_t DebugOverrides;
+ // Section: Total Board Power idle vs active coefficients
+ uint8_t TotalBoardPowerSupport;
+ uint8_t TotalBoardPowerPadding[3];
+
+ int16_t TotalIdleBoardPowerM;
+ int16_t TotalIdleBoardPowerB;
+ int16_t TotalBoardPowerM;
+ int16_t TotalBoardPowerB;
+
// SECTION: Sku Reserved
- uint32_t Spare[64];
+ uint32_t Spare[61];
// Padding for MMHUB - do not modify this
uint32_t MmHubPadding[8];
@@ -1259,7 +1264,8 @@ typedef struct {
// SECTION: Clock Spread Spectrum
// UCLK Spread Spectrum
- uint16_t UclkSpreadPadding;
+ uint8_t UclkTrainingModeSpreadPercent;
+ uint8_t UclkSpreadPadding;
uint16_t UclkSpreadFreq; // kHz
// UCLK Spread Spectrum
@@ -1272,11 +1278,7 @@ typedef struct {
// Section: Memory Config
uint8_t DramWidth; // Width of interface to the channel for each DRAM
module. See DRAM_BIT_WIDTH_TYPE_e
- uint8_t PaddingMem1[3];
-
- // Section: Total Board Power
- uint16_t TotalBoardPower; //Only needed for TCP Estimated case,
where TCP = TGP+Total Board Power
- uint16_t BoardPowerPadding;
+ uint8_t PaddingMem1[7];
// SECTION: UMC feature flags
uint8_t HsrEnabled;
@@ -1375,8 +1377,11 @@ typedef struct {
uint16_t Vcn1ActivityPercentage ;
uint32_t EnergyAccumulator;
- uint16_t AverageSocketPower;
+ uint16_t AverageSocketPower;
+ uint16_t AverageTotalBoardPower;
+
uint16_t AvgTemperature[TEMP_COUNT];
+ uint16_t TempPadding;
uint8_t PcieRate ;
uint8_t PcieWidth ;
diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h
b/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h
index 6fe2fe92ebd7..ac308e72241a 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h
+++ b/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h
@@ -30,7 +30,7 @@
#define SMU13_DRIVER_IF_VERSION_ALDE 0x08 #define
SMU13_DRIVER_IF_VERSION_SMU_V13_0_4 0x05 #define
SMU13_DRIVER_IF_VERSION_SMU_V13_0_5 0x04 -#define
SMU13_DRIVER_IF_VERSION_SMU_V13_0_0 0x2C
+#define SMU13_DRIVER_IF_VERSION_SMU_V13_0_0 0x2E
#define SMU13_DRIVER_IF_VERSION_SMU_V13_0_7 0x2C
#define SMU13_MODE1_RESET_WAIT_TIME_IN_MS 500 //500ms
--
2.29.0
Re: [PATCH] drm/amd/display: remove unneeded defines from bios parser
Applied. Thanks!
Alex
On Sun, Aug 21, 2022 at 2:41 AM Tales Aparecida
wrote:
>
> Removes DEFINEs that should have been removed after they were
> introduced to ObjectID.h by the commit abea57d70e90
> ("drm/amdgpu: Add BRACKET_LAYOUT_ENUMs to ObjectID.h")
>
> Signed-off-by: Tales Aparecida
> ---
> .../drm/amd/display/dc/bios/bios_parser2.c| 19 ---
> 1 file changed, 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
> b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
> index 09fbb7ad5362..ead4da11a992 100644
> --- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
> +++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
> @@ -44,25 +44,6 @@
>
> #include "bios_parser_common.h"
>
> -/* Temporarily add in defines until ObjectID.h patch is updated in a few
> days */
> -#ifndef GENERIC_OBJECT_ID_BRACKET_LAYOUT
> -#define GENERIC_OBJECT_ID_BRACKET_LAYOUT 0x05
> -#endif /* GENERIC_OBJECT_ID_BRACKET_LAYOUT */
> -
> -#ifndef GENERICOBJECT_BRACKET_LAYOUT_ENUM_ID1
> -#define GENERICOBJECT_BRACKET_LAYOUT_ENUM_ID1 \
> - (GRAPH_OBJECT_TYPE_GENERIC << OBJECT_TYPE_SHIFT |\
> - GRAPH_OBJECT_ENUM_ID1 << ENUM_ID_SHIFT |\
> - GENERIC_OBJECT_ID_BRACKET_LAYOUT << OBJECT_ID_SHIFT)
> -#endif /* GENERICOBJECT_BRACKET_LAYOUT_ENUM_ID1 */
> -
> -#ifndef GENERICOBJECT_BRACKET_LAYOUT_ENUM_ID2
> -#define GENERICOBJECT_BRACKET_LAYOUT_ENUM_ID2 \
> - (GRAPH_OBJECT_TYPE_GENERIC << OBJECT_TYPE_SHIFT |\
> - GRAPH_OBJECT_ENUM_ID2 << ENUM_ID_SHIFT |\
> - GENERIC_OBJECT_ID_BRACKET_LAYOUT << OBJECT_ID_SHIFT)
> -#endif /* GENERICOBJECT_BRACKET_LAYOUT_ENUM_ID2 */
> -
> #define DC_LOGGER \
> bp->base.ctx->logger
>
> --
> 2.37.2
>
[PATCH 10/14] drm/amd/display: Free phantom plane and stream properly
From: Alvin Lee
[Description]
Refcount is incremented on allocation and
when adding to the context. Therefore we must
release the phantom plane and stream after
removing from the context.
Reviewed-by: Aric Cyr
Acked-by: Brian Chang
Signed-off-by: Alvin Lee
---
.../gpu/drm/amd/display/dc/dcn32/dcn32_resource.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource.c
index b8a9606863f8..194d7dbdbcd7 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource.c
@@ -1729,13 +1729,26 @@ bool dcn32_remove_phantom_pipes(struct dc *dc, struct
dc_state *context)
{
int i;
bool removed_pipe = false;
+ struct dc_plane_state *phantom_plane = NULL;
+ struct dc_stream_state *phantom_stream = NULL;
for (i = 0; i < dc->res_pool->pipe_count; i++) {
struct pipe_ctx *pipe = &context->res_ctx.pipe_ctx[i];
// build scaling params for phantom pipes
if (pipe->plane_state && pipe->stream &&
pipe->stream->mall_stream_config.type == SUBVP_PHANTOM) {
+ phantom_plane = pipe->plane_state;
+ phantom_stream = pipe->stream;
+
dc_rem_all_planes_for_stream(dc, pipe->stream, context);
dc_remove_stream_from_ctx(dc, context, pipe->stream);
+
+ /* Ref count is incremented on allocation and also when
added to the context.
+* Therefore we must call release for the the phantom
plane and stream once
+* they are removed from the ctx to finally decrement
the refcount to 0 to free.
+*/
+ dc_plane_state_release(phantom_plane);
+ dc_stream_release(phantom_stream);
+
removed_pipe = true;
}
--
2.25.1
[PATCH 04/14] drm/amd/display: HDMI ODM Combine Policy Correction
From: Saaem Rizvi
[WHY]
Reprogramming the stream despite no changes in ODM combine mode.
Reprogramming the stream would cause intermittent black screen on
display which could only be recovered through enable/disable sequence.
[HOW]
Fixed bug where we detected a change in ODM combine mode despite ODM
combine mode being disabled. Also removed code which required stream to
be reprogrammed once a change in ODM combine mode was noticed. Lastly we
do not support dynamic ODM switching for HDMI TMDS and FRL on DCN32,
therefore we never want to change its ODM policy.
Reviewed-by: Samson Tam
Acked-by: Brian Chang
Signed-off-by: Saaem Rizvi
---
drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 3 ---
drivers/gpu/drm/amd/display/dc/dc_stream.h| 2 --
drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource.c | 4 +---
3 files changed, 1 insertion(+), 8 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 7dbab15bfa68..29f27e3fe3ac 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
@@ -1904,9 +1904,6 @@ bool dc_is_stream_unchanged(
if (memcmp(&old_stream->audio_info, &stream->audio_info,
sizeof(stream->audio_info)) != 0)
return false;
- if (old_stream->odm_2to1_policy_applied !=
stream->odm_2to1_policy_applied)
- return false;
-
return true;
}
diff --git a/drivers/gpu/drm/amd/display/dc/dc_stream.h
b/drivers/gpu/drm/amd/display/dc/dc_stream.h
index f87f852d4829..9fcf9dc5bce4 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_stream.h
+++ b/drivers/gpu/drm/amd/display/dc/dc_stream.h
@@ -268,8 +268,6 @@ struct dc_stream_state {
bool has_non_synchronizable_pclk;
bool vblank_synchronized;
struct mall_stream_config mall_stream_config;
-
- bool odm_2to1_policy_applied;
};
#define ABM_LEVEL_IMMEDIATE_DISABLE 255
diff --git a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource.c
index 8b887b552f2c..1524b6d1ce34 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource.c
@@ -1904,13 +1904,11 @@ int dcn32_populate_dml_pipes_from_context(
timing = &pipe->stream->timing;
pipes[pipe_cnt].pipe.dest.odm_combine_policy =
dm_odm_combine_policy_dal;
- res_ctx->pipe_ctx[i].stream->odm_2to1_policy_applied = false;
- if (context->stream_count == 1 && timing->dsc_cfg.num_slices_h
!= 1) {
+ if (context->stream_count == 1 &&
!dc_is_hdmi_signal(res_ctx->pipe_ctx[i].stream->signal)) {
if (dc->debug.enable_single_display_2to1_odm_policy) {
if (!((plane_count > 2) && pipe->top_pipe))
pipes[pipe_cnt].pipe.dest.odm_combine_policy = dm_odm_combine_policy_2to1;
}
- res_ctx->pipe_ctx[i].stream->odm_2to1_policy_applied =
true;
}
pipe_cnt++;
}
--
2.25.1
Re: [PATCH 1/4] drm/amdgpu: use proper DC check in amdgpu_display_supported_domains()
Ping on this series? Alex On Tue, Jul 19, 2022 at 2:35 PM Alex Deucher wrote: > > amdgpu_device_asic_has_dc_support() just checks the asic itself. > amdgpu_device_has_dc_support() is a runtime check which not > only checks the asic, but also other things in the driver > like whether virtual display is enabled. We want the latter > here. > > Signed-off-by: Alex Deucher > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c > index c20922a5af9f..b0fa5d065d50 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c > @@ -514,7 +514,7 @@ uint32_t amdgpu_display_supported_domains(struct > amdgpu_device *adev, > */ > if ((bo_flags & AMDGPU_GEM_CREATE_CPU_GTT_USWC) && > amdgpu_bo_support_uswc(bo_flags) && > - amdgpu_device_asic_has_dc_support(adev->asic_type) && > + amdgpu_device_has_dc_support(adev) && > adev->mode_info.gpu_vm_support) > domain |= AMDGPU_GEM_DOMAIN_GTT; > #endif > -- > 2.35.3 >
Re: [PATCH] gpu: move from strlcpy with unused retval to strscpy
Hi Wolfram,
Thank you for the patch.
On Thu, Aug 18, 2022 at 11:00:07PM +0200, Wolfram Sang wrote:
> Follow the advice of the below link and prefer 'strscpy' in this
> subsystem. Conversion is 1:1 because the return value is not used.
> Generated by a coccinelle script.
>
> Link:
> https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
> Signed-off-by: Wolfram Sang
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/amd/amdgpu/atom.c | 2 +-
> drivers/gpu/drm/amd/pm/legacy-dpm/legacy_dpm.c | 2 +-
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c | 6 +++---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
> drivers/gpu/drm/display/drm_dp_helper.c | 2 +-
> drivers/gpu/drm/display/drm_dp_mst_topology.c | 2 +-
> drivers/gpu/drm/drm_mipi_dsi.c | 2 +-
> drivers/gpu/drm/i2c/tda998x_drv.c | 2 +-
> drivers/gpu/drm/i915/selftests/i915_perf.c | 2 +-
> drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c | 2 +-
> drivers/gpu/drm/radeon/radeon_atombios.c| 4 ++--
> drivers/gpu/drm/radeon/radeon_combios.c | 4 ++--
> drivers/gpu/drm/rockchip/inno_hdmi.c| 2 +-
> drivers/gpu/drm/rockchip/rk3066_hdmi.c | 2 +-
> drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c | 2 +-
> 15 files changed, 19 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c
> b/drivers/gpu/drm/amd/amdgpu/atom.c
> index 1c5d9388ad0b..5f610e9a5f0f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/atom.c
> +++ b/drivers/gpu/drm/amd/amdgpu/atom.c
> @@ -1509,7 +1509,7 @@ struct atom_context *amdgpu_atom_parse(struct card_info
> *card, void *bios)
> str = CSTR(idx);
> if (*str != '\0') {
> pr_info("ATOM BIOS: %s\n", str);
> - strlcpy(ctx->vbios_version, str, sizeof(ctx->vbios_version));
> + strscpy(ctx->vbios_version, str, sizeof(ctx->vbios_version));
> }
>
> atom_rom_header = (struct _ATOM_ROM_HEADER *)CSTR(base);
> diff --git a/drivers/gpu/drm/amd/pm/legacy-dpm/legacy_dpm.c
> b/drivers/gpu/drm/amd/pm/legacy-dpm/legacy_dpm.c
> index d3fe149d8476..81fb4e5dd804 100644
> --- a/drivers/gpu/drm/amd/pm/legacy-dpm/legacy_dpm.c
> +++ b/drivers/gpu/drm/amd/pm/legacy-dpm/legacy_dpm.c
> @@ -794,7 +794,7 @@ void amdgpu_add_thermal_controller(struct amdgpu_device
> *adev)
> struct i2c_board_info info = { };
> const char *name =
> pp_lib_thermal_controller_names[controller->ucType];
> info.addr = controller->ucI2cAddress >> 1;
> - strlcpy(info.type, name, sizeof(info.type));
> + strscpy(info.type, name, sizeof(info.type));
>
> i2c_new_client_device(&adev->pm.i2c_bus->adapter, &info);
> }
> } else {
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
> index 7d2ed0ed2fe2..4efb62bcdb63 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
> @@ -542,8 +542,8 @@ static int snd_dw_hdmi_probe(struct platform_device *pdev)
> if (ret < 0)
> return ret;
>
> - strlcpy(card->driver, DRIVER_NAME, sizeof(card->driver));
> - strlcpy(card->shortname, "DW-HDMI", sizeof(card->shortname));
> + strscpy(card->driver, DRIVER_NAME, sizeof(card->driver));
> + strscpy(card->shortname, "DW-HDMI", sizeof(card->shortname));
> snprintf(card->longname, sizeof(card->longname),
>"%s rev 0x%02x, irq %d", card->shortname, revision,
>data->irq);
> @@ -561,7 +561,7 @@ static int snd_dw_hdmi_probe(struct platform_device *pdev)
>
> dw->pcm = pcm;
> pcm->private_data = dw;
> - strlcpy(pcm->name, DRIVER_NAME, sizeof(pcm->name));
> + strscpy(pcm->name, DRIVER_NAME, sizeof(pcm->name));
> snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_PLAYBACK, &snd_dw_hdmi_ops);
>
> /*
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index 25a60eb4d67c..4f3ae976e677 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -533,7 +533,7 @@ static struct i2c_adapter *dw_hdmi_i2c_adapter(struct
> dw_hdmi *hdmi)
> adap->owner = THIS_MODULE;
> adap->dev.parent = hdmi->dev;
> adap->algo = &dw_hdmi_algorithm;
> - strlcpy(adap->name, "DesignWare HDMI", sizeof(adap->name));
> + strscpy(adap->name, "DesignWare HDMI", sizeof(adap->name));
> i2c_set_adapdata(adap, hdmi);
>
> ret = i2c_add_adapter(adap);
> diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
> b/drivers/gpu/drm/display/drm_dp_helper.c
> index e5bab236b3ae..10a39b36a66
Re: [Bug 216373] New: Uncorrected errors reported for AMD GPU
[Adding amdgpu folks] On Wed, Aug 17, 2022 at 11:45:15PM +, bugzilla-dae...@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=216373 > > Bug ID: 216373 >Summary: Uncorrected errors reported for AMD GPU > Kernel Version: v6.0-rc1 > Regression: No > ... I marked this as a regression in bugzilla. > Hardware: > CPU: Intel i7-12700K (Alder Lake) > GPU: AMD RX 6700 XT [1002:73df] > Motherboard: ASUS Prime Z690-A > > Problem: > After upgrading to v6.0-rc1 the kernel is now reporting uncorrected PCI errors > for my GPU. Thank you very much for the report and for taking the trouble to bisect it and test Kai-Heng's patch! I suspect that booting with "pci=noaer" should be a temporary workaround for this issue. If it, can you add that to the bugzilla for anybody else who trips over this? > I have bisected this issue to: [8795e182b02dc87e343c79e73af6b8b7f9c5e635] > PCI/portdrv: Don't disable AER reporting in get_port_device_capability() > Reverting that commit causes the errors to cease. I suspect the errors still occur, but we just don't notice and log them. > I have also tried Kai-Heng Feng's patch[1] which seems to resolve a similar > problem, but it did not fix my issue. > > [1] > https://lore.kernel.org/linux-pci/20220706123244.18056-1-kai.heng.f...@canonical.com/ > > dmesg snippet: > > pcieport :00:01.0: AER: Multiple Uncorrected (Non-Fatal) error received: > :03:00.0 > amdgpu :03:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), > type=Transaction Layer, (Requester ID) > amdgpu :03:00.0: device [1002:73df] error status/mask=0010/ > amdgpu :03:00.0:[20] UnsupReq (First) > amdgpu :03:00.0: AER: TLP Header: 4001 000f 95e7f000 I think the TLP header decodes to: 0x4001 = 0100 ... 0001 binary 0x000f = ... binary Fmt 010b 3 DW header with data Type b 010 0 MWr Memory Write Request Length00 0001b1 DW Requester ID 0x 00:00.0 Tag 0x00 Last DW BEbmust be zero for 1 DW write First DW BE ball 4 bytes in DW enabled Address 0x95e7f000 Data 0x So I think this is a 32-bit write of zero to PCI bus address 0x95e7f000. Your dmesg log says: pci :02:00.0: PCI bridge to [bus 03] pci :02:00.0: bridge window [mem 0x95e0-0x95ff] pci :03:00.0: reg 0x24: [mem 0x95e0-0x95ef] [drm] register mmio base: 0x95E0 So this looks like a write to the device's BAR 5. I don't see a PCI reason why this should fail. Maybe there's some amdgpu reason? Bjorn
[PATCH v3 25/31] platform/x86: asus-wmi: Move acpi_backlight=native quirks to ACPI video_detect.c
Remove the asus-wmi quirk_entry.wmi_backlight_native quirk-flag, which
called acpi_video_set_dmi_backlight_type(acpi_backlight_native) and replace
it with acpi/video_detect.c video_detect_dmi_table[] entries using the
video_detect_force_native callback.
acpi_video_set_dmi_backlight_type() is troublesome because it may end up
getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
drivers/acpi/video_detect.c| 8
drivers/platform/x86/asus-nb-wmi.c | 14 --
drivers/platform/x86/asus-wmi.c| 3 ---
drivers/platform/x86/asus-wmi.h| 1 -
4 files changed, 8 insertions(+), 18 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 1574ff837e31..a871ee69fcb2 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -564,6 +564,14 @@ static const struct dmi_system_id video_detect_dmi_table[]
= {
DMI_MATCH(DMI_PRODUCT_NAME, "GA503"),
},
},
+ {
+.callback = video_detect_force_native,
+/* Asus UX303UB */
+.matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "UX303UB"),
+ },
+ },
/*
* Clevo NL5xRU and NL5xNU/TUXEDO Aura 15 Gen1 and Gen2 have both a
* working native and video interface. However the default detection
diff --git a/drivers/platform/x86/asus-nb-wmi.c
b/drivers/platform/x86/asus-nb-wmi.c
index 810a94557a85..bbfed85051ee 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -97,11 +97,6 @@ static struct quirk_entry quirk_asus_x200ca = {
.wmi_backlight_set_devstate = true,
};
-static struct quirk_entry quirk_asus_ux303ub = {
- .wmi_backlight_native = true,
- .wmi_backlight_set_devstate = true,
-};
-
static struct quirk_entry quirk_asus_x550lb = {
.wmi_backlight_set_devstate = true,
.xusb2pr = 0x01D9,
@@ -372,15 +367,6 @@ static const struct dmi_system_id asus_quirks[] = {
},
.driver_data = &quirk_asus_x200ca,
},
- {
- .callback = dmi_matched,
- .ident = "ASUSTeK COMPUTER INC. UX303UB",
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
- DMI_MATCH(DMI_PRODUCT_NAME, "UX303UB"),
- },
- .driver_data = &quirk_asus_ux303ub,
- },
{
.callback = dmi_matched,
.ident = "ASUSTeK COMPUTER INC. UX330UAK",
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 5cf9d9aff164..434249ac47a5 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -3634,9 +3634,6 @@ static int asus_wmi_add(struct platform_device *pdev)
if (asus->driver->quirks->wmi_force_als_set)
asus_wmi_set_als();
- if (asus->driver->quirks->wmi_backlight_native)
- acpi_video_set_dmi_backlight_type(acpi_backlight_native);
-
if (asus->driver->quirks->xusb2pr)
asus_wmi_set_xusb2pr(asus);
diff --git a/drivers/platform/x86/asus-wmi.h b/drivers/platform/x86/asus-wmi.h
index 30770e411301..f30252efe1db 100644
--- a/drivers/platform/x86/asus-wmi.h
+++ b/drivers/platform/x86/asus-wmi.h
@@ -29,7 +29,6 @@ struct quirk_entry {
bool hotplug_wireless;
bool scalar_panel_brightness;
bool store_backlight_power;
- bool wmi_backlight_native;
bool wmi_backlight_set_devstate;
bool wmi_force_als_set;
bool use_kbd_dock_devid;
--
2.37.2
[PATCH] drm/amdgpu: skip set_topology_info for VF
Skip set_topology_info as xgmi TA will now block it
and host needs to program it.
Signed-off-by: Vignesh Chander
---
drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
index 1b108d03e785..1a2b4c4b745c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
@@ -504,6 +504,9 @@ int amdgpu_xgmi_update_topology(struct amdgpu_hive_info
*hive, struct amdgpu_dev
{
int ret;
+ if (amdgpu_sriov_vf(adev))
+ return 0;
+
/* Each psp need to set the latest topology */
ret = psp_xgmi_set_topology_info(&adev->psp,
atomic_read(&hive->number_devices),
--
2.25.1
[RFC v4 15/17] drm/display/dp_mst: Maintain time slot allocations when deleting payloads
Currently, we set drm_dp_atomic_payload->time_slots to 0 in order to
indicate that we're about to delete a payload in the current atomic state.
Since we're going to be dropping all of the legacy code for handling the
payload table however, we need to be able to ensure that we still keep
track of the current time slot allocations for each payload so we can reuse
this info when asking the root MST hub to delete payloads. We'll also be
using it to recalculate the start slots of each VC.
So, let's keep track of the intent of a payload in drm_dp_atomic_payload by
adding ->delete, which we set whenever we're planning on deleting a payload
during the current atomic commit.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Jani Nikula
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 14 +++---
include/drm/display/drm_dp_mst_helper.h | 5 -
2 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index a5460cadf2c8..c4073d733c59 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -4407,7 +4407,7 @@ int drm_dp_atomic_find_time_slots(struct drm_atomic_state
*state,
* releasing and allocating the same timeslot allocation,
* which is an error
*/
- if (WARN_ON(!prev_slots)) {
+ if (drm_WARN_ON(mgr->dev, payload->delete)) {
drm_err(mgr->dev,
"cannot allocate and release time slots on [MST
PORT:%p] in the same state\n",
port);
@@ -4512,10 +4512,10 @@ int drm_dp_atomic_release_time_slots(struct
drm_atomic_state *state,
}
drm_dbg_atomic(mgr->dev, "[MST PORT:%p] TU %d -> 0\n", port,
payload->time_slots);
- if (payload->time_slots) {
+ if (!payload->delete) {
drm_dp_mst_put_port_malloc(port);
- payload->time_slots = 0;
payload->pbn = 0;
+ payload->delete = true;
}
return 0;
@@ -5239,7 +5239,7 @@ drm_dp_mst_duplicate_state(struct drm_private_obj *obj)
list_for_each_entry(pos, &old_state->payloads, next) {
/* Prune leftover freed timeslot allocations */
- if (!pos->time_slots)
+ if (pos->delete)
continue;
payload = kmemdup(pos, sizeof(*payload), GFP_KERNEL);
@@ -5271,8 +5271,8 @@ static void drm_dp_mst_destroy_state(struct
drm_private_obj *obj,
int i;
list_for_each_entry_safe(pos, tmp, &mst_state->payloads, next) {
- /* We only keep references to ports with non-zero VCPIs */
- if (pos->time_slots)
+ /* We only keep references to ports with active payloads */
+ if (!pos->delete)
drm_dp_mst_put_port_malloc(pos->port);
kfree(pos);
}
@@ -5400,7 +5400,7 @@ drm_dp_mst_atomic_check_payload_alloc_limits(struct
drm_dp_mst_topology_mgr *mgr
list_for_each_entry(payload, &mst_state->payloads, next) {
/* Releasing payloads is always OK-even if the port is gone */
- if (!payload->time_slots) {
+ if (payload->delete) {
drm_dbg_atomic(mgr->dev, "[MST PORT:%p] releases all
time slots\n",
payload->port);
continue;
diff --git a/include/drm/display/drm_dp_mst_helper.h
b/include/drm/display/drm_dp_mst_helper.h
index b9c361b242ea..8b847836a0b4 100644
--- a/include/drm/display/drm_dp_mst_helper.h
+++ b/include/drm/display/drm_dp_mst_helper.h
@@ -560,8 +560,11 @@ struct drm_dp_mst_atomic_payload {
int time_slots;
/** @pbn: The payload bandwidth for this payload */
int pbn;
+
+ /** @delete: Whether or not we intend to delete this payload during
this atomic commit */
+ bool delete : 1;
/** @dsc_enabled: Whether or not this payload has DSC enabled */
- bool dsc_enabled;
+ bool dsc_enabled : 1;
/** @next: The list node for this payload */
struct list_head next;
--
2.37.1
Re: [BUG][5.20] refcount_t: underflow; use-after-free
On 08/17, Mikhail Gavrilov wrote: > On Mon, Aug 15, 2022 at 3:37 PM Mikhail Gavrilov > wrote: > > > > Thanks, I tested this patch. > > But with this patch use-after-free problem happening in another place: > > Does anyone have an idea why the second use-after-free happened? > From the trace I don't understand which code is related. > I don't quite understand what the "Workqueue" entry in the trace means. Hi Mikhail, IIUC, you got this second user-after-free by applying the first version of Maíra's patch, right? So, that version was adding another unbalanced unlock to the cs ioctl flow, but it was solved in the latest version, that you can find here: https://patchwork.freedesktop.org/patch/497680/ If this is the situation, can you check this last version? Thanks, Melissa > > [ 408.358737] [ cut here ] > [ 408.358743] refcount_t: underflow; use-after-free. > [ 408.358760] WARNING: CPU: 9 PID: 62 at lib/refcount.c:28 > refcount_warn_saturate+0xba/0x110 > [ 408.358769] Modules linked in: uinput snd_seq_dummy rfcomm > snd_hrtimer nft_objref nf_conntrack_netbios_ns nf_conntrack_broadcast > nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet > nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat > nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables nfnetlink > qrtr bnep sunrpc binfmt_misc snd_seq_midi snd_seq_midi_event mt76x2u > mt76x2_common snd_hda_codec_realtek mt76x02_usb snd_hda_codec_generic > iwlmvm snd_hda_codec_hdmi mt76_usb intel_rapl_msr snd_hda_intel > mt76x02_lib intel_rapl_common snd_intel_dspcfg snd_intel_sdw_acpi mt76 > snd_hda_codec vfat fat snd_usb_audio snd_hda_core edac_mce_amd > mac80211 snd_usbmidi_lib snd_hwdep snd_rawmidi mc snd_seq btusb > kvm_amd iwlwifi snd_seq_device btrtl btbcm libarc4 btintel eeepc_wmi > snd_pcm iwlmei kvm btmtk asus_wmi ledtrig_audio irqbypass joydev > snd_timer sparse_keymap bluetooth platform_profile rapl cfg80211 snd > video wmi_bmof soundcore i2c_piix4 k10temp rfkill mei > [ 408.358853] asus_ec_sensors acpi_cpufreq zram hid_logitech_hidpp > amdgpu igb dca drm_ttm_helper ttm iommu_v2 crct10dif_pclmul gpu_sched > crc32_pclmul ucsi_ccg crc32c_intel drm_buddy nvme typec_ucsi > drm_display_helper ghash_clmulni_intel ccp typec nvme_core sp5100_tco > cec wmi ip6_tables ip_tables fuse > [ 408.358880] Unloaded tainted modules: amd64_edac():1 amd64_edac():1 > amd64_edac():1 amd64_edac():1 amd64_edac():1 amd64_edac():1 > amd64_edac():1 amd64_edac():1 amd64_edac():1 amd64_edac():1 > pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 pcc_cpufreq():1 > amd64_edac():1 amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 > pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 > pcc_cpufreq():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 > amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 > pcc_cpufreq():1 amd64_edac():1 amd64_edac():1 pcc_cpufreq():1 > pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 > pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 pcc_cpufreq():1 > amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 > amd64_edac():1 pcc_cpufreq():1 pcc_cpufreq():1 amd64_edac():1 > pcc_cpufreq():1 amd64_edac():1 amd64_edac():1 pcc_cpufreq():1 > amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 > pcc_cpufreq():1 pcc_cpufreq():1 fjes():1 pcc_cpufreq():1 fjes():1 > [ 408.358953] pcc_cpufreq():1 pcc_cpufreq():1 fjes():1 pcc_cpufreq():1 > fjes():1 fjes():1 fjes():1 fjes():1 fjes():1 > [ 408.358967] CPU: 9 PID: 62 Comm: kworker/9:0 Tainted: G W L --- > --- 6.0.0-0.rc1.13.fc38.x86_64+debug #1 > [ 408.358971] Hardware name: System manufacturer System Product > Name/ROG STRIX X570-I GAMING, BIOS 4403 04/27/2022 > [ 408.358974] Workqueue: events drm_sched_entity_kill_jobs_work [gpu_sched] > [ 408.358982] RIP: 0010:refcount_warn_saturate+0xba/0x110 > [ 408.358987] Code: 01 01 e8 d9 59 6f 00 0f 0b e9 a2 46 a5 00 80 3d 3e > 7e be 01 00 75 85 48 c7 c7 70 99 8e 92 c6 05 2e 7e be 01 01 e8 b6 59 > 6f 00 <0f> 0b e9 7f 46 a5 00 80 3d 19 7e be 01 00 0f 85 5e ff ff ff 48 > c7 > [ 408.358990] RSP: 0018:b124003efe60 EFLAGS: 00010286 > [ 408.358994] RAX: 0026 RBX: 9987a025d428 RCX: > > [ 408.358997] RDX: 0001 RSI: 928d0754 RDI: > > [ 408.358999] RBP: 9994e4ff5600 R08: R09: > b124003efd10 > [ 408.359001] R10: 0003 R11: 99952e2fffe8 R12: > 9994e4ffc800 > [ 408.359004] R13: 998600228cc0 R14: 9994e4ffc805 R15: > 9987a025d430 > [ 408.359006] FS: () GS:9994e4e0() > knlGS: > [ 408.359009] CS: 0010 DS: ES: CR0: 80050033 > [ 408.359012] CR2: 27ac39e78000 CR3: 0001a66d8000 CR4: > 00350ee0 > [ 408.359015] Call Trace: > [ 408.359017] > [ 408.359020] process_one_work+0x2a0/0x600 > [ 408.359032] worker_thread+0x4f/0x3a0 > [ 408.359036] ? process_one_work+0x600/0x600 > [ 408.359039]
Re: [PATCH] drm/amdgpu: TA unload messages are not actually sent to psp when amdgpu is uninstalled
On 2022-08-17 10:01, Andrey Grodzovsky wrote:
On 2022-08-17 09:44, Alex Deucher wrote:
On Tue, Aug 16, 2022 at 10:54 PM Chai, Thomas
wrote:
[AMD Official Use Only - General]
Hi Alex:
When removing an amdgpu device, it may be difficult to change the
order of psp_hw_fini calls.
1. The drm_dev_unplug call is at the beginning in the
amdgpu_pci_remove function, which makes the gpu device inaccessible
for userspace operations. If the call to psp_hw_fini was moved
before drm_dev_unplug, userspace could access the gpu device but
the psp might be removing. It has unknown issues.
+Andrey Grodzovsky
We should fix the ordering in amdgpu_pci_remove() then I guess? There
are lots of places where drm_dev_enter() is used to protect access to
the hardware which could be similarly affected.
Alex
We probably can try to move drm_dev_unplug after
amdgpu_driver_unload_kms. I don't remember now why drm_dev_unplug must
be the first thing we do in amdgpu_pci_remove and what impact it will
have but maybe give it a try.
Also see if you can run libdrm hotplug test suite before and after the
change.
Andrey
Thinking a bit more about this - i guess the main problem with this will
be that in case of real hot unplug (which is hard to test unless you
have a real GPU cage with extenal GPU) this move will cause trying to
accesses HW registers
or MMIO ranges from VRAM BOs when HW is missing when you try to shut
down the HW in HW fini IP block specific callbacks , this in turn will
return garbage for reads (or all 1s maybe) which is what we probably
were trying to avoid by putting drm_dev_unplug as the first thing. So
it's probably a bit problematic.
Andrey
2. psp_hw_fini is called by the .hw_fini iterator in
amdgpu_device_ip_fini_early, referring to the code starting from
amdgpu_pci_remove to .hw_fini is called,
there are many preparatory operations before calling .hw_fini,
which makes it very difficult to change the order of psp_hw_fini or
all block .hw_fini.
So can we do a workaround in psp_cmd_submit_buf when removing
amdgpu device?
-Original Message-
From: Alex Deucher
Sent: Monday, August 15, 2022 10:22 PM
To: Chai, Thomas
Cc: amd-gfx@lists.freedesktop.org; Zhang, Hawking
; Chen, Guchun ; Chai,
Thomas
Subject: Re: [PATCH] drm/amdgpu: TA unload messages are not actually
sent to psp when amdgpu is uninstalled
On Mon, Aug 15, 2022 at 3:06 AM YiPeng Chai
wrote:
The psp_cmd_submit_buf function is called by psp_hw_fini to send TA
unload messages to psp to terminate ras, asd and tmr.
But when amdgpu is uninstalled, drm_dev_unplug is called earlier than
psp_hw_fini in amdgpu_pci_remove, the calling order as follows:
static void amdgpu_pci_remove(struct pci_dev *pdev) {
drm_dev_unplug
..
amdgpu_driver_unload_kms->amdgpu_device_fini_hw->...
->.hw_fini->psp_hw_fini->...
->psp_ta_unload->psp_cmd_submit_buf
..
}
The program will return when calling drm_dev_enter in
psp_cmd_submit_buf.
So the call to drm_dev_enter in psp_cmd_submit_buf should be removed,
so that the TA unload messages can be sent to the psp when amdgpu is
uninstalled.
Signed-off-by: YiPeng Chai
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index b067ce45d226..0578d8d094a7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -585,9 +585,6 @@ psp_cmd_submit_buf(struct psp_context *psp,
if (psp->adev->no_hw_access)
return 0;
- if (!drm_dev_enter(adev_to_drm(psp->adev), &idx))
- return 0;
-
This check is to prevent the hardware from being accessed if the
card is removed. I think we need to fix the ordering elsewhere.
Alex
memset(psp->cmd_buf_mem, 0, PSP_CMD_BUFFER_SIZE);
memcpy(psp->cmd_buf_mem, cmd, sizeof(struct
psp_gfx_cmd_resp)); @@ -651,7 +648,6 @@ psp_cmd_submit_buf(struct
psp_context *psp,
}
exit:
- drm_dev_exit(idx);
return ret;
}
--
2.25.1
Re: [PATCHv2] drm/amdgpu: Fix interrupt handling on ih_soft ring
Am 15.08.22 um 21:25 schrieb Mukul Joshi:
There are no backing hardware registers for ih_soft ring.
As a result, don't try to access hardware registers for read
and write pointers when processing interrupts on the IH soft
ring.
Signed-off-by: Mukul Joshi
Acked-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/navi10_ih.c | 7 ++-
drivers/gpu/drm/amd/amdgpu/vega10_ih.c | 7 ++-
drivers/gpu/drm/amd/amdgpu/vega20_ih.c | 7 ++-
3 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/navi10_ih.c
b/drivers/gpu/drm/amd/amdgpu/navi10_ih.c
index 4b5396d3e60f..eec13cb5bf75 100644
--- a/drivers/gpu/drm/amd/amdgpu/navi10_ih.c
+++ b/drivers/gpu/drm/amd/amdgpu/navi10_ih.c
@@ -409,9 +409,11 @@ static u32 navi10_ih_get_wptr(struct amdgpu_device *adev,
u32 wptr, tmp;
struct amdgpu_ih_regs *ih_regs;
- if (ih == &adev->irq.ih) {
+ if (ih == &adev->irq.ih || ih == &adev->irq.ih_soft) {
/* Only ring0 supports writeback. On other rings fall back
* to register-based code with overflow checking below.
+* ih_soft ring doesn't have any backing hardware registers,
+* update wptr and return.
*/
wptr = le32_to_cpu(*ih->wptr_cpu);
@@ -483,6 +485,9 @@ static void navi10_ih_set_rptr(struct amdgpu_device *adev,
{
struct amdgpu_ih_regs *ih_regs;
+ if (ih == &adev->irq.ih_soft)
+ return;
+
if (ih->use_doorbell) {
/* XXX check if swapping is necessary on BE */
*ih->rptr_cpu = ih->rptr;
diff --git a/drivers/gpu/drm/amd/amdgpu/vega10_ih.c
b/drivers/gpu/drm/amd/amdgpu/vega10_ih.c
index cdd599a08125..03b7066471f9 100644
--- a/drivers/gpu/drm/amd/amdgpu/vega10_ih.c
+++ b/drivers/gpu/drm/amd/amdgpu/vega10_ih.c
@@ -334,9 +334,11 @@ static u32 vega10_ih_get_wptr(struct amdgpu_device *adev,
u32 wptr, tmp;
struct amdgpu_ih_regs *ih_regs;
- if (ih == &adev->irq.ih) {
+ if (ih == &adev->irq.ih || ih == &adev->irq.ih_soft) {
/* Only ring0 supports writeback. On other rings fall back
* to register-based code with overflow checking below.
+* ih_soft ring doesn't have any backing hardware registers,
+* update wptr and return.
*/
wptr = le32_to_cpu(*ih->wptr_cpu);
@@ -409,6 +411,9 @@ static void vega10_ih_set_rptr(struct amdgpu_device *adev,
{
struct amdgpu_ih_regs *ih_regs;
+ if (ih == &adev->irq.ih_soft)
+ return;
+
if (ih->use_doorbell) {
/* XXX check if swapping is necessary on BE */
*ih->rptr_cpu = ih->rptr;
diff --git a/drivers/gpu/drm/amd/amdgpu/vega20_ih.c
b/drivers/gpu/drm/amd/amdgpu/vega20_ih.c
index 3b4eb8285943..2022ffbb8dba 100644
--- a/drivers/gpu/drm/amd/amdgpu/vega20_ih.c
+++ b/drivers/gpu/drm/amd/amdgpu/vega20_ih.c
@@ -385,9 +385,11 @@ static u32 vega20_ih_get_wptr(struct amdgpu_device *adev,
u32 wptr, tmp;
struct amdgpu_ih_regs *ih_regs;
- if (ih == &adev->irq.ih) {
+ if (ih == &adev->irq.ih || ih == &adev->irq.ih_soft) {
/* Only ring0 supports writeback. On other rings fall back
* to register-based code with overflow checking below.
+* ih_soft ring doesn't have any backing hardware registers,
+* update wptr and return.
*/
wptr = le32_to_cpu(*ih->wptr_cpu);
@@ -461,6 +463,9 @@ static void vega20_ih_set_rptr(struct amdgpu_device *adev,
{
struct amdgpu_ih_regs *ih_regs;
+ if (ih == &adev->irq.ih_soft)
+ return;
+
if (ih->use_doorbell) {
/* XXX check if swapping is necessary on BE */
*ih->rptr_cpu = ih->rptr;
Re: [PATCH] drm/amdgpu: remove useless condition in amdgpu_job_stop_all_jobs_on_sched()
Applied. Thanks!
On Fri, Aug 12, 2022 at 7:13 AM Christian König
wrote:
>
> @Alex was that one already picked up?
>
> Am 25.07.22 um 18:40 schrieb Andrey Grodzovsky:
> > Reviewed-by: Andrey Grodzovsky
> >
> > Andrey
> >
> > On 2022-07-19 06:39, Andrey Strachuk wrote:
> >> Local variable 'rq' is initialized by an address
> >> of field of drm_sched_job, so it does not make
> >> sense to compare 'rq' with NULL.
> >>
> >> Found by Linux Verification Center (linuxtesting.org) with SVACE.
> >>
> >> Signed-off-by: Andrey Strachuk
> >> Fixes: 7c6e68c777f1 ("drm/amdgpu: Avoid HW GPU reset for RAS.")
> >> ---
> >> drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 4
> >> 1 file changed, 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> >> index 67f66f2f1809..600401f2a98f 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> >> @@ -285,10 +285,6 @@ void amdgpu_job_stop_all_jobs_on_sched(struct
> >> drm_gpu_scheduler *sched)
> >> /* Signal all jobs not yet scheduled */
> >> for (i = DRM_SCHED_PRIORITY_COUNT - 1; i >=
> >> DRM_SCHED_PRIORITY_MIN; i--) {
> >> struct drm_sched_rq *rq = &sched->sched_rq[i];
> >> -
> >> -if (!rq)
> >> -continue;
> >> -
> >> spin_lock(&rq->lock);
> >> list_for_each_entry(s_entity, &rq->entities, list) {
> >> while ((s_job =
> >> to_drm_sched_job(spsc_queue_pop(&s_entity->job_queue {
>
Re: [PATCH linux-next] drm/amdgpu/vcn: Remove unused assignment in vcn_v4_0_stop
On 8/15/22 20:15, Dong, Ruijing wrote:
[AMD Official Use Only - General]
Sorry, which "r" value was overwritten? I didn't see the point of making this
change.
Thanks
Ruijing
-Original Message-
From: Khalid Masum
Sent: Monday, August 15, 2022 3:01 AM
To: amd-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
linux-ker...@vger.kernel.org; linux-kernel-ment...@lists.linuxfoundation.org
Cc: Deucher, Alexander ; Koenig, Christian ; Pan, Xinhui
; David Airlie ; Daniel Vetter ; Zhu, James ;
Jiang, Sonny ; Dong, Ruijing ; Wan Jiabing ; Liu, Leo
; Khalid Masum
Subject: [PATCH linux-next] drm/amdgpu/vcn: Remove unused assignment in
vcn_v4_0_stop
The value assigned from vcn_v4_0_stop_dbg_mode to r is overwritten before it
can be used. Remove this assignment.
Addresses-Coverity: 1504988 ("Unused value")
Fixes: 8da1170a16e4 ("drm/amdgpu: add VCN4 ip block support")
Signed-off-by: Khalid Masum
---
drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
index ca14c3ef742e..80b8a2c66b36 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
@@ -1154,7 +1154,7 @@ static int vcn_v4_0_stop(struct amdgpu_device *adev)
fw_shared->sq.queue_mode |= FW_QUEUE_DPG_HOLD_OFF;
if (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG) {
- r = vcn_v4_0_stop_dpg_mode(adev, i);
+ vcn_v4_0_stop_dpg_mode(adev, i);
continue;
}
--
2.37.1
After value is overwritten soon right after the diff.
See:
drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
static int vcn_v4_0_stop(struct amdgpu_device *adev)
{
volatile struct amdgpu_vcn4_fw_shared *fw_shared;
...
for (i = 0; i < adev->vcn.num_vcn_inst; ++i) {
fw_shared = adev->vcn.inst[i].fw_shared.cpu_addr;
fw_shared->sq.queue_mode |= FW_QUEUE_DPG_HOLD_OFF;
if (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG) {
r = vcn_v4_0_stop_dpg_mode(adev, i);
continue;
}
/* wait for vcn idle */
r = SOC15_WAIT_ON_RREG(VCN, i, regUVD_STATUS,
UVD_STATUS__IDLE, 0x7);
Here, any value assigned to r is overwritten before it could
be used. So the assignment in the true branch of the if statement
here can be removed.
Thanks,
-- Khalid Masum
Re: [PATCH] drm/amdgpu: Fix use-after-free on amdgpu_bo_list mutex
On 08/15, Maíra Canal wrote:
> If amdgpu_cs_vm_handling returns r != 0, then it will unlock the
> bo_list_mutex inside the function amdgpu_cs_vm_handling and again on
> amdgpu_cs_parser_fini. This problem results in the following
> use-after-free problem:
>
> [ 220.280990] [ cut here ]
> [ 220.281000] refcount_t: underflow; use-after-free.
> [ 220.281019] WARNING: CPU: 1 PID: 3746 at lib/refcount.c:28
> refcount_warn_saturate+0xba/0x110
> [ 220.281029] [ cut here ]
> [ 220.281415] CPU: 1 PID: 3746 Comm: chrome:cs0 Tainted: G W L --- ---
> 5.20.0-0.rc0.20220812git7ebfc85e2cd7.10.fc38.x86_64 #1
> [ 220.281421] Hardware name: System manufacturer System Product Name/ROG
> STRIX X570-I GAMING, BIOS 4403 04/27/2022
> [ 220.281426] RIP: 0010:refcount_warn_saturate+0xba/0x110
> [ 220.281431] Code: 01 01 e8 79 4a 6f 00 0f 0b e9 42 47 a5 00 80 3d de
> 7e be 01 00 75 85 48 c7 c7 f8 98 8e 98 c6 05 ce 7e be 01 01 e8 56 4a
> 6f 00 <0f> 0b e9 1f 47 a5 00 80 3d b9 7e be 01 00 0f 85 5e ff ff ff 48
> c7
> [ 220.281437] RSP: 0018:b4b0d18d7a80 EFLAGS: 00010282
> [ 220.281443] RAX: 0026 RBX: 0003 RCX:
>
> [ 220.281448] RDX: 0001 RSI: 988d06dc RDI:
>
> [ 220.281452] RBP: R08: R09:
> b4b0d18d7930
> [ 220.281457] R10: 0003 R11: a0672e2fffe8 R12:
> a058ca360400
> [ 220.281461] R13: a05846c50a18 R14: fe00 R15:
> 0003
> [ 220.281465] FS: 7f82683e06c0() GS:a066e2e0()
> knlGS:
> [ 220.281470] CS: 0010 DS: ES: CR0: 80050033
> [ 220.281475] CR2: 3590005cc000 CR3: 0001fca46000 CR4:
> 00350ee0
> [ 220.281480] Call Trace:
> [ 220.281485]
> [ 220.281490] amdgpu_cs_ioctl+0x4e2/0x2070 [amdgpu]
> [ 220.281806] ? amdgpu_cs_find_mapping+0xe0/0xe0 [amdgpu]
> [ 220.282028] drm_ioctl_kernel+0xa4/0x150
> [ 220.282043] drm_ioctl+0x21f/0x420
> [ 220.282053] ? amdgpu_cs_find_mapping+0xe0/0xe0 [amdgpu]
> [ 220.282275] ? lock_release+0x14f/0x460
> [ 220.282282] ? _raw_spin_unlock_irqrestore+0x30/0x60
> [ 220.282290] ? _raw_spin_unlock_irqrestore+0x30/0x60
> [ 220.282297] ? lockdep_hardirqs_on+0x7d/0x100
> [ 220.282305] ? _raw_spin_unlock_irqrestore+0x40/0x60
> [ 220.282317] amdgpu_drm_ioctl+0x4a/0x80 [amdgpu]
> [ 220.282534] __x64_sys_ioctl+0x90/0xd0
> [ 220.282545] do_syscall_64+0x5b/0x80
> [ 220.282551] ? futex_wake+0x6c/0x150
> [ 220.282568] ? lock_is_held_type+0xe8/0x140
> [ 220.282580] ? do_syscall_64+0x67/0x80
> [ 220.282585] ? lockdep_hardirqs_on+0x7d/0x100
> [ 220.282592] ? do_syscall_64+0x67/0x80
> [ 220.282597] ? do_syscall_64+0x67/0x80
> [ 220.282602] ? lockdep_hardirqs_on+0x7d/0x100
> [ 220.282609] entry_SYSCALL_64_after_hwframe+0x63/0xcd
> [ 220.282616] RIP: 0033:0x7f8282a4f8bf
> [ 220.282639] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10
> 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00
> 0f 05 <89> c2 3d 00 f0 ff ff 77 18 48 8b 44 24 18 64 48 2b 04 25 28 00
> 00
> [ 220.282644] RSP: 002b:7f82683df410 EFLAGS: 0246 ORIG_RAX:
> 0010
> [ 220.282651] RAX: ffda RBX: 7f82683df588 RCX:
> 7f8282a4f8bf
> [ 220.282655] RDX: 7f82683df4d0 RSI: c0186444 RDI:
> 0018
> [ 220.282659] RBP: 7f82683df4d0 R08: 7f82683df5e0 R09:
> 7f82683df4b0
> [ 220.282663] R10: 1d04000a0600 R11: 0246 R12:
> c0186444
> [ 220.282667] R13: 0018 R14: 7f82683df588 R15:
> 0003
> [ 220.282689]
> [ 220.282693] irq event stamp: 6232311
> [ 220.282697] hardirqs last enabled at (6232319): []
> __up_console_sem+0x5e/0x70
> [ 220.282704] hardirqs last disabled at (6232326): []
> __up_console_sem+0x43/0x70
> [ 220.282709] softirqs last enabled at (6232072): []
> __irq_exit_rcu+0xf9/0x170
> [ 220.282716] softirqs last disabled at (6232061): []
> __irq_exit_rcu+0xf9/0x170
> [ 220.282722] ---[ end trace ]---
>
> Therefore, remove the mutex_unlock from the amdgpu_cs_vm_handling
> function, so that amdgpu_cs_submit and amdgpu_cs_parser_fini can handle
> the unlock.
>
> Fixes: 90af0ca047f3 ("drm/amdgpu: Protect the amdgpu_bo_list list with a
> mutex v2")
> Reported-by: Mikhail Gavrilov
> Signed-off-by: Maíra Canal
> ---
> Thanks Melissa and Christian for the feedback on mutex_unlock.
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> index d8f1335bc68f..b7bae833c804 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> @@ -837,16 +837,12 @@ static int amdgpu_cs_vm_handling(struct
> amdgpu_cs_parser *p)
> continue;
>
> r = amdgpu_vm_bo_update(adev, bo_va, false);
Re: [PATCH] drm/amdgpu: TA unload messages are not actually sent to psp when amdgpu is uninstalled
On Mon, Aug 15, 2022 at 3:06 AM YiPeng Chai wrote:
>
> The psp_cmd_submit_buf function is called by psp_hw_fini to
> send TA unload messages to psp to terminate ras, asd and tmr.
> But when amdgpu is uninstalled, drm_dev_unplug is called
> earlier than psp_hw_fini in amdgpu_pci_remove, the calling
> order as follows:
> static void amdgpu_pci_remove(struct pci_dev *pdev)
> {
> drm_dev_unplug
> ..
> amdgpu_driver_unload_kms->amdgpu_device_fini_hw->...
> ->.hw_fini->psp_hw_fini->...
> ->psp_ta_unload->psp_cmd_submit_buf
> ..
> }
> The program will return when calling drm_dev_enter in
> psp_cmd_submit_buf.
>
> So the call to drm_dev_enter in psp_cmd_submit_buf should
> be removed, so that the TA unload messages can be sent to the
> psp when amdgpu is uninstalled.
>
> Signed-off-by: YiPeng Chai
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> index b067ce45d226..0578d8d094a7 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> @@ -585,9 +585,6 @@ psp_cmd_submit_buf(struct psp_context *psp,
> if (psp->adev->no_hw_access)
> return 0;
>
> - if (!drm_dev_enter(adev_to_drm(psp->adev), &idx))
> - return 0;
> -
This check is to prevent the hardware from being accessed if the card
is removed. I think we need to fix the ordering elsewhere.
Alex
> memset(psp->cmd_buf_mem, 0, PSP_CMD_BUFFER_SIZE);
>
> memcpy(psp->cmd_buf_mem, cmd, sizeof(struct psp_gfx_cmd_resp));
> @@ -651,7 +648,6 @@ psp_cmd_submit_buf(struct psp_context *psp,
> }
>
> exit:
> - drm_dev_exit(idx);
> return ret;
> }
>
> --
> 2.25.1
>
[PATCH] drm/amdgpu: Fix UBSAN shift-out-of-bounds for gfx v9_0
Check shift number to avoid doing a shift operation when the number
of bits shifted equal to or greater than number of bits in the operand.
Signed-off-by: Candice Li
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index 7f187558220e9a..0b9215b6e4b316 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -2494,7 +2494,7 @@ static u32 gfx_v9_0_get_rb_active_bitmap(struct
amdgpu_device *adev)
static void gfx_v9_0_setup_rb(struct amdgpu_device *adev)
{
int i, j;
- u32 data;
+ u32 data, shift_num;
u32 active_rbs = 0;
u32 rb_bitmap_width_per_sh = adev->gfx.config.max_backends_per_se /
adev->gfx.config.max_sh_per_se;
@@ -2504,8 +2504,10 @@ static void gfx_v9_0_setup_rb(struct amdgpu_device *adev)
for (j = 0; j < adev->gfx.config.max_sh_per_se; j++) {
gfx_v9_0_select_se_sh(adev, i, j, 0x);
data = gfx_v9_0_get_rb_active_bitmap(adev);
- active_rbs |= data << ((i *
adev->gfx.config.max_sh_per_se + j) *
- rb_bitmap_width_per_sh);
+ shift_num = min(((i * adev->gfx.config.max_sh_per_se +
j) *
+ rb_bitmap_width_per_sh),
__builtin_clz(data));
+ if (data)
+ active_rbs |= data << shift_num;
}
}
gfx_v9_0_select_se_sh(adev, 0x, 0x, 0x);
--
2.17.1
RE: [PATCH 1/2] drm/amdgpu: The call to amdgpu_xgmi_remove_device needs to be earlier than psp_hw_fini
[AMD Official Use Only - General]
Ping on this series.
-Original Message-
From: Chai, Thomas
Sent: Friday, August 12, 2022 5:13 PM
To: amd-gfx@lists.freedesktop.org
Cc: Chai, Thomas ; Zhang, Hawking ;
Wang, Yang(Kevin) ; Chai, Thomas
Subject: [PATCH 1/2] drm/amdgpu: The call to amdgpu_xgmi_remove_device needs to
be earlier than psp_hw_fini
The amdgpu_xgmi_remove_device function will send unload command to psp through
psp ring to terminate xgmi, but psp ring has been destroyed in psp_hw_fini.
Signed-off-by: YiPeng Chai
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index c84fdef0ac45..2445255bbf01 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2787,6 +2787,9 @@ static int amdgpu_device_ip_fini_early(struct
amdgpu_device *adev)
amdgpu_amdkfd_suspend(adev, false);
+ if (adev->gmc.xgmi.num_physical_nodes > 1)
+ amdgpu_xgmi_remove_device(adev);
+
/* Workaroud for ASICs need to disable SMC first */
amdgpu_device_smu_fini_early(adev);
@@ -2830,9 +2833,6 @@ static int amdgpu_device_ip_fini(struct amdgpu_device
*adev)
if (amdgpu_sriov_vf(adev) && adev->virt.ras_init_done)
amdgpu_virt_release_ras_err_handler_data(adev);
- if (adev->gmc.xgmi.num_physical_nodes > 1)
- amdgpu_xgmi_remove_device(adev);
-
amdgpu_amdkfd_device_fini_sw(adev);
for (i = adev->num_ip_blocks - 1; i >= 0; i--) {
--
2.25.1
[PATCH 10/14] drm/amd/display: Modify header inclusion pattern
From: Chaitanya Dhere
[Why]
Recent backport from opensource broke the Nightly tool build
that tests DC and DML for bugs and regressions. This was
because the backport had a header inclusion that was not
consistent with the AMD style of including headers was allowed
to be merged back in DML code that caused tool compilation
failures.
[How]
Modify the way in which the header file in included so that it
is consistent with AMD style of including headers. This then
automatically fixes the tool compilation process and also
helps maintain the code quality and consistency.
Reviewed-by: Alvin Lee
Reviewed-by: Jun Lei
Acked-by: Brian Chang
Signed-off-by: Chaitanya Dhere
---
drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c | 2 +-
.../gpu/drm/amd/display/dc/dml/dcn31/display_rq_dlg_calc_31.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c
index 3fab19134480..d63b4209b14c 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c
@@ -26,7 +26,7 @@
#include "dc.h"
#include "dc_link.h"
#include "../display_mode_lib.h"
-#include "dml/dcn30/display_mode_vba_30.h"
+#include "../dcn30/display_mode_vba_30.h"
#include "display_mode_vba_31.h"
#include "../dml_inline_defs.h"
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_rq_dlg_calc_31.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_rq_dlg_calc_31.c
index 66b82e4f05c6..35d10b4d018b 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_rq_dlg_calc_31.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_rq_dlg_calc_31.c
@@ -27,7 +27,7 @@
#include "../display_mode_vba.h"
#include "../dml_inline_defs.h"
#include "display_rq_dlg_calc_31.h"
-#include "dml/dcn30/display_mode_vba_30.h"
+#include "../dcn30/display_mode_vba_30.h"
static bool is_dual_plane(enum source_format_class source_format)
{
--
2.25.1
Re: [Linaro-mm-sig] [PATCH v3 6/9] dma-buf: Move dma-buf attachment to dynamic locking specification
Am 24.08.22 um 12:22 schrieb Dmitry Osipenko:
Move dma-buf attachment API functions to the dynamic locking specification.
The strict locking convention prevents deadlock situations for dma-buf
importers and exporters.
Previously, the "unlocked" versions of the attachment API functions
weren't taking the reservation lock and this patch makes them to take
the lock.
Intel and AMD GPU drivers already were mapping the attached dma-bufs under
the held lock during attachment, hence these drivers are updated to use
the locked functions.
Signed-off-by: Dmitry Osipenko
---
drivers/dma-buf/dma-buf.c | 115 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 4 +-
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 8 +-
drivers/gpu/drm/i915/gem/i915_gem_object.c | 12 +++
include/linux/dma-buf.h| 20 ++--
5 files changed, 110 insertions(+), 49 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 4556a12bd741..f2a5a122da4a 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -559,7 +559,7 @@ static struct file *dma_buf_getfile(struct dma_buf *dmabuf,
int flags)
* 2. Userspace passes this file-descriptors to all drivers it wants this
buffer
*to share with: First the file descriptor is converted to a &dma_buf
using
*dma_buf_get(). Then the buffer is attached to the device using
- *dma_buf_attach().
+ *dma_buf_attach_unlocked().
Now I get why this is confusing me so much.
The _unlocked postfix implies that there is another function which
should be called with the locks already held, but this is not the case
for attach/detach (because they always need to grab the lock themselves).
So I suggest to drop the _unlocked postfix for the attach/detach
functions. Another step would then be to unify attach/detach with
dynamic_attach/dynamic_detach when both have the same locking convention
anyway.
Sorry that this is going so much back and forth, it's really complicated
to keep all the stuff in my head at the moment :)
Thanks a lot for looking into this,
Christian.
*
*Up to this stage the exporter is still free to migrate or reallocate the
*backing storage.
@@ -569,8 +569,8 @@ static struct file *dma_buf_getfile(struct dma_buf *dmabuf,
int flags)
*dma_buf_map_attachment() and dma_buf_unmap_attachment().
*
* 4. Once a driver is done with a shared buffer it needs to call
- *dma_buf_detach() (after cleaning up any mappings) and then release the
- *reference acquired with dma_buf_get() by calling dma_buf_put().
+ *dma_buf_detach_unlocked() (after cleaning up any mappings) and then
+ *release the reference acquired with dma_buf_get() by calling
dma_buf_put().
*
* For the detailed semantics exporters are expected to implement see
* &dma_buf_ops.
@@ -802,7 +802,7 @@ static struct sg_table * __map_dma_buf(struct
dma_buf_attachment *attach,
* @importer_priv:[in]importer private pointer for the attachment
*
* Returns struct dma_buf_attachment pointer for this attachment. Attachments
- * must be cleaned up by calling dma_buf_detach().
+ * must be cleaned up by calling dma_buf_detach_unlocked().
*
* Optionally this calls &dma_buf_ops.attach to allow device-specific attach
* functionality.
@@ -858,8 +858,8 @@ dma_buf_dynamic_attach_unlocked(struct dma_buf *dmabuf,
struct device *dev,
dma_buf_is_dynamic(dmabuf)) {
struct sg_table *sgt;
+ dma_resv_lock(attach->dmabuf->resv, NULL);
if (dma_buf_is_dynamic(attach->dmabuf)) {
- dma_resv_lock(attach->dmabuf->resv, NULL);
ret = dmabuf->ops->pin(attach);
if (ret)
goto err_unlock;
@@ -872,8 +872,7 @@ dma_buf_dynamic_attach_unlocked(struct dma_buf *dmabuf,
struct device *dev,
ret = PTR_ERR(sgt);
goto err_unpin;
}
- if (dma_buf_is_dynamic(attach->dmabuf))
- dma_resv_unlock(attach->dmabuf->resv);
+ dma_resv_unlock(attach->dmabuf->resv);
attach->sgt = sgt;
attach->dir = DMA_BIDIRECTIONAL;
}
@@ -889,8 +888,7 @@ dma_buf_dynamic_attach_unlocked(struct dma_buf *dmabuf,
struct device *dev,
dmabuf->ops->unpin(attach);
err_unlock:
- if (dma_buf_is_dynamic(attach->dmabuf))
- dma_resv_unlock(attach->dmabuf->resv);
+ dma_resv_unlock(attach->dmabuf->resv);
dma_buf_detach_unlocked(dmabuf, attach);
return ERR_PTR(ret);
@@ -927,7 +925,7 @@ static void __unmap_dma_buf(struct dma_buf_attachment
*attach,
* @dmabuf: [in]buffer to detach from.
* @attach: [in]attachment to be detached; is free'd after this call.
*
- * Clean up a device attachment obtained by calling dma_buf_attach().
+ * Clean up a
Re: [PATCH v3 6/9] dma-buf: Move dma-buf attachment to dynamic locking specification
Am 24.08.22 um 17:03 schrieb Dmitry Osipenko: On 8/24/22 17:08, Christian König wrote: Am 24.08.22 um 12:22 schrieb Dmitry Osipenko: Move dma-buf attachment API functions to the dynamic locking specification. The strict locking convention prevents deadlock situations for dma-buf importers and exporters. Previously, the "unlocked" versions of the attachment API functions weren't taking the reservation lock and this patch makes them to take the lock. Didn't we concluded that we need to keep the attach and detach callbacks without the lock and only move the map/unmap callbacks over? Otherwise it won't be possible for drivers to lock multiple buffers if they have to shuffle things around for a specific attachment. We did conclude that. The attach/detach dma-buf ops are unlocked, but the map_dma_buf/unmap_dma_buf must be invoked under lock and dma_buf_dynamic_attach_unlocked() maps dma-buf if either importer or exporter can't handle the dynamic mapping [1]. Ah! You are confusing me over and over again with that :) Ok in this case that here is fine, I just need to re-read the patch. Thanks, Christian. [1] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Fv6.0-rc2%2Fsource%2Fdrivers%2Fdma-buf%2Fdma-buf.c%23L869&data=05%7C01%7Cchristian.koenig%40amd.com%7Cdf23d89db8b84bf6d4c008da85e1dc6c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637969502441026991%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=d8kWKjDCFn%2B3KmK135Gcv6%2FMLffEYcipouqWxfc%2BKXM%3D&reserved=0 Hence I re-arranged the dma_resv_lock() in dma_buf_dynamic_attach_unlocked() to move both pinning and mapping under the held lock.
[PATCH 3/4] drm: introduce DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP
This new kernel capability indicates whether async page-flips are
supported via the atomic uAPI. DRM clients can use it to check
for support before feeding DRM_MODE_PAGE_FLIP_ASYNC to the kernel.
Make it clear that DRM_CAP_ASYNC_PAGE_FLIP is for legacy uAPI only.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Joshua Ashton
Cc: Melissa Wen
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
---
drivers/gpu/drm/drm_ioctl.c | 5 +
include/uapi/drm/drm.h | 10 +-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index ca2a6e6101dc..5b1591e2b46c 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -302,6 +302,11 @@ static int drm_getcap(struct drm_device *dev, void *data,
struct drm_file *file_
case DRM_CAP_CRTC_IN_VBLANK_EVENT:
req->value = 1;
break;
+ case DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP:
+ req->value = drm_core_check_feature(dev, DRIVER_ATOMIC) &&
+dev->mode_config.async_page_flip &&
+
!dev->mode_config.atomic_async_page_flip_not_supported;
+ break;
default:
return -EINVAL;
}
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 642808520d92..b1962628ecda 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -706,7 +706,8 @@ struct drm_gem_open {
/**
* DRM_CAP_ASYNC_PAGE_FLIP
*
- * If set to 1, the driver supports &DRM_MODE_PAGE_FLIP_ASYNC.
+ * If set to 1, the driver supports &DRM_MODE_PAGE_FLIP_ASYNC for legacy
+ * page-flips.
*/
#define DRM_CAP_ASYNC_PAGE_FLIP0x7
/**
@@ -767,6 +768,13 @@ struct drm_gem_open {
* Documentation/gpu/drm-mm.rst, section "DRM Sync Objects".
*/
#define DRM_CAP_SYNCOBJ_TIMELINE 0x14
+/**
+ * DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP
+ *
+ * If set to 1, the driver supports &DRM_MODE_PAGE_FLIP_ASYNC for atomic
+ * commits.
+ */
+#define DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP 0x15
/* DRM_IOCTL_GET_CAP ioctl argument type */
struct drm_get_cap {
--
2.37.2
[PATCH 4/4] amd/display: indicate support for atomic async page-flips on DCN
amdgpu_dm_commit_planes already sets the flip_immediate flag for async page-flips. This flag is used to set the UNP_FLIP_CONTROL register. Thus, no additional change is required to handle async page-flips with the atomic uAPI. Note, async page-flips are still unsupported on DCE with the atomic uAPI. The mode_set_base callbacks unconditionally set the GRPH_SURFACE_UPDATE_H_RETRACE_EN field of the GRPH_FLIP_CONTROL register to 0, which disables async page-flips. Signed-off-by: Simon Ser Cc: Daniel Vetter Cc: Joshua Ashton Cc: Melissa Wen Cc: Alex Deucher Cc: Harry Wentland Cc: Nicholas Kazlauskas --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 - 1 file changed, 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 ef816bf295eb..9ab01c58bedb 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -3804,7 +3804,6 @@ static int amdgpu_dm_mode_config_init(struct amdgpu_device *adev) adev_to_drm(adev)->mode_config.prefer_shadow = 0; /* indicates support for immediate flip */ adev_to_drm(adev)->mode_config.async_page_flip = true; - adev_to_drm(adev)->mode_config.atomic_async_page_flip_not_supported = true; adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base; -- 2.37.2
[PATCH 2/4] drm: allow DRM_MODE_PAGE_FLIP_ASYNC for atomic commits
If the driver supports it, allow user-space to supply the
DRM_MODE_PAGE_FLIP_ASYNC flag to request an async page-flip.
Set drm_crtc_state.async_flip accordingly.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Joshua Ashton
Cc: Melissa Wen
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
---
drivers/gpu/drm/drm_atomic_uapi.c | 28 +---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 79730fa1dd8e..ee24ed7e2edb 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -1278,6 +1278,18 @@ static void complete_signaling(struct drm_device *dev,
kfree(fence_state);
}
+static void
+set_async_flip(struct drm_atomic_state *state)
+{
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *crtc_state;
+ int i;
+
+ for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
+ crtc_state->async_flip = true;
+ }
+}
+
int drm_mode_atomic_ioctl(struct drm_device *dev,
void *data, struct drm_file *file_priv)
{
@@ -1318,9 +1330,16 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
}
if (arg->flags & DRM_MODE_PAGE_FLIP_ASYNC) {
- drm_dbg_atomic(dev,
- "commit failed: invalid flag
DRM_MODE_PAGE_FLIP_ASYNC\n");
- return -EINVAL;
+ if (!dev->mode_config.async_page_flip) {
+ drm_dbg_atomic(dev,
+ "commit failed: DRM_MODE_PAGE_FLIP_ASYNC
not supported\n");
+ return -EINVAL;
+ }
+ if (dev->mode_config.atomic_async_page_flip_not_supported) {
+ drm_dbg_atomic(dev,
+ "commit failed: DRM_MODE_PAGE_FLIP_ASYNC
not supported with atomic\n");
+ return -EINVAL;
+ }
}
/* can't test and expect an event at the same time. */
@@ -1418,6 +1437,9 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
if (ret)
goto out;
+ if (arg->flags & DRM_MODE_PAGE_FLIP_ASYNC)
+ set_async_flip(state);
+
if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY) {
ret = drm_atomic_check_only(state);
} else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
--
2.37.2
[PATCH 1/4] drm: introduce drm_mode_config.atomic_async_page_flip_not_supported
This new field indicates whether the driver has the necessary logic to support async page-flips via the atomic uAPI. This is leveraged by the next commit to allow user-space to use this functionality. All drivers setting drm_mode_config.async_page_flip are updated to also set drm_mode_config.atomic_async_page_flip_not_supported. We will gradually check and update these drivers to properly handle drm_crtc_state.async_flip in their atomic logic. The goal of this negative flag is the same as fb_modifiers_not_supported: we want to eventually get rid of all drivers missing atomic support for async flips. New drivers should not set this flag, instead they should support atomic async flips (if they support async flips at all). IOW, we don't want more drivers with async flip support for legacy but not atomic. Signed-off-by: Simon Ser Cc: Daniel Vetter Cc: Joshua Ashton Cc: Melissa Wen Cc: Alex Deucher Cc: Harry Wentland Cc: Nicholas Kazlauskas --- drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 1 + drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 1 + drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 1 + drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 1 + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 + drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 1 + drivers/gpu/drm/i915/display/intel_display.c | 1 + drivers/gpu/drm/nouveau/nouveau_display.c | 1 + drivers/gpu/drm/radeon/radeon_display.c | 1 + drivers/gpu/drm/vc4/vc4_kms.c | 1 + include/drm/drm_mode_config.h | 11 +++ 11 files changed, 21 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c index 9c964cd3b5d4..76ccd57e3663 100644 --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c @@ -2791,6 +2791,7 @@ static int dce_v10_0_sw_init(void *handle) adev_to_drm(adev)->mode_config.funcs = &amdgpu_mode_funcs; adev_to_drm(adev)->mode_config.async_page_flip = true; + adev_to_drm(adev)->mode_config.atomic_async_page_flip_not_supported = true; adev_to_drm(adev)->mode_config.max_width = 16384; adev_to_drm(adev)->mode_config.max_height = 16384; diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c index e0ad9f27dc3f..c7702c5bfbd0 100644 --- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c +++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c @@ -2909,6 +2909,7 @@ static int dce_v11_0_sw_init(void *handle) adev_to_drm(adev)->mode_config.funcs = &amdgpu_mode_funcs; adev_to_drm(adev)->mode_config.async_page_flip = true; + adev_to_drm(adev)->mode_config.atomic_async_page_flip_not_supported = true; adev_to_drm(adev)->mode_config.max_width = 16384; adev_to_drm(adev)->mode_config.max_height = 16384; diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c index 77f5e998a120..c9a2372f8ea2 100644 --- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c +++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c @@ -2670,6 +2670,7 @@ static int dce_v6_0_sw_init(void *handle) adev_to_drm(adev)->mode_config.funcs = &amdgpu_mode_funcs; adev_to_drm(adev)->mode_config.async_page_flip = true; + adev_to_drm(adev)->mode_config.atomic_async_page_flip_not_supported = true; adev_to_drm(adev)->mode_config.max_width = 16384; adev_to_drm(adev)->mode_config.max_height = 16384; adev_to_drm(adev)->mode_config.preferred_depth = 24; diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c index 802e5c753271..09c07820d494 100644 --- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c +++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c @@ -2688,6 +2688,7 @@ static int dce_v8_0_sw_init(void *handle) adev_to_drm(adev)->mode_config.funcs = &amdgpu_mode_funcs; adev_to_drm(adev)->mode_config.async_page_flip = true; + adev_to_drm(adev)->mode_config.atomic_async_page_flip_not_supported = true; adev_to_drm(adev)->mode_config.max_width = 16384; adev_to_drm(adev)->mode_config.max_height = 16384; 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 9ab01c58bedb..ef816bf295eb 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -3804,6 +3804,7 @@ static int amdgpu_dm_mode_config_init(struct amdgpu_device *adev) adev_to_drm(adev)->mode_config.prefer_shadow = 0; /* indicates support for immediate flip */ adev_to_drm(adev)->mode_config.async_page_flip = true; + adev_to_drm(adev)->mode_config.atomic_async_page_flip_not_supported = true; adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base; diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c index f
Re: [PATCH] drm/sced: Add FIFO policy for scheduler rq
On 2022-08-24 04:29, Michel Dänzer wrote: On 2022-08-22 22:09, Andrey Grodzovsky wrote: Poblem: Given many entities competing for same rq on same scheduler an uncceptabliy long wait time for some jobs waiting stuck in rq before being picked up are observed (seen using GPUVis). The issue is due to Round Robin policy used by scheduler to pick up the next entity for execution. Under stress of many entities and long job queus within entity some jobs could be stack for very long time in it's entity's queue before being popped from the queue and executed while for other entites with samller job queues a job might execute ealier even though that job arrived later then the job in the long queue. Fix: Add FIFO selection policy to entites in RQ, chose next enitity on rq in such order that if job on one entity arrived ealrier then job on another entity the first job will start executing ealier regardless of the length of the entity's job queue. Instead of ordering based on when jobs are added, might it be possible to order them based on when they become ready to run? Otherwise it seems possible to e.g. submit a large number of inter-dependent jobs at once, and they would all run before any jobs from another queue get a chance. While any of them is not ready (i.e. still having unfulfilled dependency) this job will not be chosen to run (see drm_sched_entity_is_ready). In this scenario if an earlier job from entity E1 is not ready to run it will be skipped and a later job from entity E2 (which is ready) will be chosen to run so E1 job is not blocking E2 job. The moment E1 job does become ready it seems to me logical to let it run ASAP as it's by now it spent the most time of anyone waiting for execution, and I don't think it matters that part of this time was because it waited for dependency job to complete it's run. Andrey
[PATCH] drm/amdgpu: disable FRU access on special SIENNA CICHLID card
Below driver load error will be printed, not friendly to end user.
amdgpu: ATOM BIOS: 113-D603GLXE-077
[drm] FRU: Failed to get size field
[drm:amdgpu_fru_get_product_info [amdgpu]] *ERROR* Failed to read FRU
Manufacturer, ret:-5
Signed-off-by: Guchun Chen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
index ecada5eadfe3..9d612b8745aa 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
@@ -66,10 +66,15 @@ static bool is_fru_eeprom_supported(struct amdgpu_device
*adev)
return true;
case CHIP_SIENNA_CICHLID:
if (strnstr(atom_ctx->vbios_version, "D603",
- sizeof(atom_ctx->vbios_version)))
- return true;
- else
+ sizeof(atom_ctx->vbios_version))) {
+ if (strnstr(atom_ctx->vbios_version, "D603GLXE",
+sizeof(atom_ctx->vbios_version)))
+ return false;
+ else
+ return true;
+ } else {
return false;
+ }
default:
return false;
}
--
2.25.1
Re: [PATCH v3 0/9] Move all drivers to a common dma-buf locking convention
Reviewed-by: Christian König to patches #2-#4 Am 24.08.22 um 12:22 schrieb Dmitry Osipenko: Hello, This series moves all drivers to a dynamic dma-buf locking specification. From now on all dma-buf importers are made responsible for holding dma-buf's reservation lock around all operations performed over dma-bufs in accordance to the locking specification. This allows us to utilize reservation lock more broadly around kernel without fearing of a potential deadlocks. This patchset passes all i915 selftests. It was also tested using VirtIO, Panfrost, Lima, Tegra, udmabuf, AMDGPU and Nouveau drivers. I tested cases of display+GPU, display+V4L and GPU+V4L dma-buf sharing (where appropriate), which covers majority of kernel drivers since rest of the drivers share same or similar code paths. Changelog: v3: - Factored out dma_buf_mmap_unlocked() and attachment functions into aseparate patches, like was suggested by Christian König. - Corrected and factored out dma-buf locking documentation into a separate patch, like was suggested by Christian König. - Intel driver dropped the reservation locking fews days ago from its BO-release code path, but we need that locking for the imported GEMs because in the end that code path unmaps the imported GEM. So I added back the locking needed by the imported GEMs, updating the "dma-buf attachment locking specification" patch appropriately. - Tested Nouveau+Intel dma-buf import/export combo. - Tested udmabuf import to i915/Nouveau/AMDGPU. - Fixed few places in Etnaviv, Panfrost and Lima drivers that I missed to switch to locked dma-buf vmapping in the drm/gem: Take reservation lock for vmap/vunmap operations" patch. In a result invalidated the Christian's r-b that he gave to v2. - Added locked dma-buf vmap/vunmap functions that are needed for fixing vmappping of Etnaviv, Panfrost and Lima drivers mentioned above. I actually had this change stashed for the drm-shmem shrinker patchset, but then realized that it's already needed by the dma-buf patches. Also improved my tests to better cover these code paths. v2: - Changed locking specification to avoid problems with a cross-driver ww locking, like was suggested by Christian König. Now the attach/detach callbacks are invoked without the held lock and exporter should take the lock. - Added "locking convention" documentation that explains which dma-buf functions and callbacks are locked/unlocked for importers and exporters, which was requested by Christian König. - Added ack from Tomasz Figa to the V4L patches that he gave to v1. Dmitry Osipenko (9): dma-buf: Add _unlocked postfix to function names dma-buf: Add locked variant of dma_buf_vmap/vunmap() drm/gem: Take reservation lock for vmap/vunmap operations dma-buf: Move dma_buf_vmap/vunmap_unlocked() to dynamic locking specification dma-buf: Move dma_buf_mmap_unlocked() to dynamic locking specification dma-buf: Move dma-buf attachment to dynamic locking specification dma-buf: Document dynamic locking convention media: videobuf2: Stop using internal dma-buf lock dma-buf: Remove internal lock Documentation/driver-api/dma-buf.rst | 6 + drivers/dma-buf/dma-buf.c | 276 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 +- drivers/gpu/drm/armada/armada_gem.c | 14 +- drivers/gpu/drm/drm_client.c | 4 +- drivers/gpu/drm/drm_gem.c | 24 ++ drivers/gpu/drm/drm_gem_dma_helper.c | 6 +- drivers/gpu/drm/drm_gem_framebuffer_helper.c | 6 +- drivers/gpu/drm/drm_gem_shmem_helper.c| 2 +- drivers/gpu/drm/drm_gem_ttm_helper.c | 9 +- drivers/gpu/drm/drm_prime.c | 12 +- drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 4 +- drivers/gpu/drm/exynos/exynos_drm_gem.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 6 +- drivers/gpu/drm/i915/gem/i915_gem_object.c| 12 + .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 20 +- drivers/gpu/drm/lima/lima_sched.c | 4 +- drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 8 +- drivers/gpu/drm/panfrost/panfrost_dump.c | 4 +- drivers/gpu/drm/panfrost/panfrost_perfcnt.c | 6 +- drivers/gpu/drm/qxl/qxl_object.c | 17 +- drivers/gpu/drm/qxl/qxl_prime.c | 4 +- drivers/gpu/drm/tegra/gem.c | 27 +- drivers/infiniband/core/umem_dmabuf.c | 11 +- .../common/videobuf2/videobuf2-dma-contig.c | 26 +- .../media/common/videobuf2/videobuf2-dma-sg.c | 23 +- .../common/videobuf2/videobuf2-vmalloc.c | 17 +- .../platform/nvidia/tegra-vde/dmabuf-cache.c | 12 +- drivers/misc/fastrpc.c| 12 +- drivers/xen/gntdev-dmabuf.c
Re: [PATCH v3 9/9] dma-buf: Remove internal lock
Am 24.08.22 um 12:22 schrieb Dmitry Osipenko:
The internal dma-buf lock isn't needed anymore because the updated
locking specification claims that dma-buf reservation must be locked
by importers, and thus, the internal data is already protected by the
reservation lock. Remove the obsoleted internal lock.
Signed-off-by: Dmitry Osipenko
Reviewed-by: Christian König
---
drivers/dma-buf/dma-buf.c | 14 --
include/linux/dma-buf.h | 9 -
2 files changed, 4 insertions(+), 19 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 696d132b02f4..a0406254f0ae 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -656,7 +656,6 @@ struct dma_buf *dma_buf_export(const struct
dma_buf_export_info *exp_info)
dmabuf->file = file;
- mutex_init(&dmabuf->lock);
INIT_LIST_HEAD(&dmabuf->attachments);
mutex_lock(&db_list.lock);
@@ -1503,7 +1502,7 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_mmap_unlocked, DMA_BUF);
int dma_buf_vmap(struct dma_buf *dmabuf, struct iosys_map *map)
{
struct iosys_map ptr;
- int ret = 0;
+ int ret;
iosys_map_clear(map);
@@ -1515,28 +1514,25 @@ int dma_buf_vmap(struct dma_buf *dmabuf, struct iosys_map *map)
if (!dmabuf->ops->vmap)
return -EINVAL;
- mutex_lock(&dmabuf->lock);
if (dmabuf->vmapping_counter) {
dmabuf->vmapping_counter++;
BUG_ON(iosys_map_is_null(&dmabuf->vmap_ptr));
*map = dmabuf->vmap_ptr;
- goto out_unlock;
+ return 0;
}
BUG_ON(iosys_map_is_set(&dmabuf->vmap_ptr));
ret = dmabuf->ops->vmap(dmabuf, &ptr);
if (WARN_ON_ONCE(ret))
- goto out_unlock;
+ return ret;
dmabuf->vmap_ptr = ptr;
dmabuf->vmapping_counter = 1;
*map = dmabuf->vmap_ptr;
-out_unlock:
- mutex_unlock(&dmabuf->lock);
- return ret;
+ return 0;
}
EXPORT_SYMBOL_NS_GPL(dma_buf_vmap, DMA_BUF);
@@ -1578,13 +1574,11 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, struct iosys_map *map)
BUG_ON(dmabuf->vmapping_counter == 0);
BUG_ON(!iosys_map_is_equal(&dmabuf->vmap_ptr, map));
- mutex_lock(&dmabuf->lock);
if (--dmabuf->vmapping_counter == 0) {
if (dmabuf->ops->vunmap)
dmabuf->ops->vunmap(dmabuf, map);
iosys_map_clear(&dmabuf->vmap_ptr);
}
- mutex_unlock(&dmabuf->lock);
}
EXPORT_SYMBOL_NS_GPL(dma_buf_vunmap, DMA_BUF);
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index d48d534dc55c..aed6695bbb50 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -326,15 +326,6 @@ struct dma_buf {
/** @ops: dma_buf_ops associated with this buffer object. */
const struct dma_buf_ops *ops;
- /**
-* @lock:
-*
-* Used internally to serialize list manipulation, attach/detach and
-* vmap/unmap. Note that in many cases this is superseeded by
-* dma_resv_lock() on @resv.
-*/
- struct mutex lock;
-
/**
* @vmapping_counter:
*
Re: [PATCH v3 9/9] dma-buf: Remove internal lock
Am 24.08.22 um 12:22 schrieb Dmitry Osipenko:
The internal dma-buf lock isn't needed anymore because the updated
locking specification claims that dma-buf reservation must be locked
by importers, and thus, the internal data is already protected by the
reservation lock. Remove the obsoleted internal lock.
Signed-off-by: Dmitry Osipenko
Reviewed-by: Christian König
---
drivers/dma-buf/dma-buf.c | 14 --
include/linux/dma-buf.h | 9 -
2 files changed, 4 insertions(+), 19 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 696d132b02f4..a0406254f0ae 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -656,7 +656,6 @@ struct dma_buf *dma_buf_export(const struct
dma_buf_export_info *exp_info)
dmabuf->file = file;
- mutex_init(&dmabuf->lock);
INIT_LIST_HEAD(&dmabuf->attachments);
mutex_lock(&db_list.lock);
@@ -1503,7 +1502,7 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_mmap_unlocked, DMA_BUF);
int dma_buf_vmap(struct dma_buf *dmabuf, struct iosys_map *map)
{
struct iosys_map ptr;
- int ret = 0;
+ int ret;
iosys_map_clear(map);
@@ -1515,28 +1514,25 @@ int dma_buf_vmap(struct dma_buf *dmabuf, struct iosys_map *map)
if (!dmabuf->ops->vmap)
return -EINVAL;
- mutex_lock(&dmabuf->lock);
if (dmabuf->vmapping_counter) {
dmabuf->vmapping_counter++;
BUG_ON(iosys_map_is_null(&dmabuf->vmap_ptr));
*map = dmabuf->vmap_ptr;
- goto out_unlock;
+ return 0;
}
BUG_ON(iosys_map_is_set(&dmabuf->vmap_ptr));
ret = dmabuf->ops->vmap(dmabuf, &ptr);
if (WARN_ON_ONCE(ret))
- goto out_unlock;
+ return ret;
dmabuf->vmap_ptr = ptr;
dmabuf->vmapping_counter = 1;
*map = dmabuf->vmap_ptr;
-out_unlock:
- mutex_unlock(&dmabuf->lock);
- return ret;
+ return 0;
}
EXPORT_SYMBOL_NS_GPL(dma_buf_vmap, DMA_BUF);
@@ -1578,13 +1574,11 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, struct iosys_map *map)
BUG_ON(dmabuf->vmapping_counter == 0);
BUG_ON(!iosys_map_is_equal(&dmabuf->vmap_ptr, map));
- mutex_lock(&dmabuf->lock);
if (--dmabuf->vmapping_counter == 0) {
if (dmabuf->ops->vunmap)
dmabuf->ops->vunmap(dmabuf, map);
iosys_map_clear(&dmabuf->vmap_ptr);
}
- mutex_unlock(&dmabuf->lock);
}
EXPORT_SYMBOL_NS_GPL(dma_buf_vunmap, DMA_BUF);
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index d48d534dc55c..aed6695bbb50 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -326,15 +326,6 @@ struct dma_buf {
/** @ops: dma_buf_ops associated with this buffer object. */
const struct dma_buf_ops *ops;
- /**
-* @lock:
-*
-* Used internally to serialize list manipulation, attach/detach and
-* vmap/unmap. Note that in many cases this is superseeded by
-* dma_resv_lock() on @resv.
-*/
- struct mutex lock;
-
/**
* @vmapping_counter:
*
Re: [PATCH v3 9/9] dma-buf: Remove internal lock
Am 24.08.22 um 12:22 schrieb Dmitry Osipenko:
The internal dma-buf lock isn't needed anymore because the updated
locking specification claims that dma-buf reservation must be locked
by importers, and thus, the internal data is already protected by the
reservation lock. Remove the obsoleted internal lock.
Signed-off-by: Dmitry Osipenko
Reviewed-by: Christian König
---
drivers/dma-buf/dma-buf.c | 14 --
include/linux/dma-buf.h | 9 -
2 files changed, 4 insertions(+), 19 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 696d132b02f4..a0406254f0ae 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -656,7 +656,6 @@ struct dma_buf *dma_buf_export(const struct
dma_buf_export_info *exp_info)
dmabuf->file = file;
- mutex_init(&dmabuf->lock);
INIT_LIST_HEAD(&dmabuf->attachments);
mutex_lock(&db_list.lock);
@@ -1503,7 +1502,7 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_mmap_unlocked, DMA_BUF);
int dma_buf_vmap(struct dma_buf *dmabuf, struct iosys_map *map)
{
struct iosys_map ptr;
- int ret = 0;
+ int ret;
iosys_map_clear(map);
@@ -1515,28 +1514,25 @@ int dma_buf_vmap(struct dma_buf *dmabuf, struct iosys_map *map)
if (!dmabuf->ops->vmap)
return -EINVAL;
- mutex_lock(&dmabuf->lock);
if (dmabuf->vmapping_counter) {
dmabuf->vmapping_counter++;
BUG_ON(iosys_map_is_null(&dmabuf->vmap_ptr));
*map = dmabuf->vmap_ptr;
- goto out_unlock;
+ return 0;
}
BUG_ON(iosys_map_is_set(&dmabuf->vmap_ptr));
ret = dmabuf->ops->vmap(dmabuf, &ptr);
if (WARN_ON_ONCE(ret))
- goto out_unlock;
+ return ret;
dmabuf->vmap_ptr = ptr;
dmabuf->vmapping_counter = 1;
*map = dmabuf->vmap_ptr;
-out_unlock:
- mutex_unlock(&dmabuf->lock);
- return ret;
+ return 0;
}
EXPORT_SYMBOL_NS_GPL(dma_buf_vmap, DMA_BUF);
@@ -1578,13 +1574,11 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, struct iosys_map *map)
BUG_ON(dmabuf->vmapping_counter == 0);
BUG_ON(!iosys_map_is_equal(&dmabuf->vmap_ptr, map));
- mutex_lock(&dmabuf->lock);
if (--dmabuf->vmapping_counter == 0) {
if (dmabuf->ops->vunmap)
dmabuf->ops->vunmap(dmabuf, map);
iosys_map_clear(&dmabuf->vmap_ptr);
}
- mutex_unlock(&dmabuf->lock);
}
EXPORT_SYMBOL_NS_GPL(dma_buf_vunmap, DMA_BUF);
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index d48d534dc55c..aed6695bbb50 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -326,15 +326,6 @@ struct dma_buf {
/** @ops: dma_buf_ops associated with this buffer object. */
const struct dma_buf_ops *ops;
- /**
-* @lock:
-*
-* Used internally to serialize list manipulation, attach/detach and
-* vmap/unmap. Note that in many cases this is superseeded by
-* dma_resv_lock() on @resv.
-*/
- struct mutex lock;
-
/**
* @vmapping_counter:
*
Re: [PATCH v3 6/9] dma-buf: Move dma-buf attachment to dynamic locking specification
Am 24.08.22 um 12:22 schrieb Dmitry Osipenko:
Move dma-buf attachment API functions to the dynamic locking specification.
The strict locking convention prevents deadlock situations for dma-buf
importers and exporters.
Previously, the "unlocked" versions of the attachment API functions
weren't taking the reservation lock and this patch makes them to take
the lock.
Didn't we concluded that we need to keep the attach and detach callbacks
without the lock and only move the map/unmap callbacks over?
Otherwise it won't be possible for drivers to lock multiple buffers if
they have to shuffle things around for a specific attachment.
Regards,
Christian.
Intel and AMD GPU drivers already were mapping the attached dma-bufs under
the held lock during attachment, hence these drivers are updated to use
the locked functions.
Signed-off-by: Dmitry Osipenko
---
drivers/dma-buf/dma-buf.c | 115 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 4 +-
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 8 +-
drivers/gpu/drm/i915/gem/i915_gem_object.c | 12 +++
include/linux/dma-buf.h| 20 ++--
5 files changed, 110 insertions(+), 49 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 4556a12bd741..f2a5a122da4a 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -559,7 +559,7 @@ static struct file *dma_buf_getfile(struct dma_buf *dmabuf,
int flags)
* 2. Userspace passes this file-descriptors to all drivers it wants this
buffer
*to share with: First the file descriptor is converted to a &dma_buf
using
*dma_buf_get(). Then the buffer is attached to the device using
- *dma_buf_attach().
+ *dma_buf_attach_unlocked().
*
*Up to this stage the exporter is still free to migrate or reallocate the
*backing storage.
@@ -569,8 +569,8 @@ static struct file *dma_buf_getfile(struct dma_buf *dmabuf,
int flags)
*dma_buf_map_attachment() and dma_buf_unmap_attachment().
*
* 4. Once a driver is done with a shared buffer it needs to call
- *dma_buf_detach() (after cleaning up any mappings) and then release the
- *reference acquired with dma_buf_get() by calling dma_buf_put().
+ *dma_buf_detach_unlocked() (after cleaning up any mappings) and then
+ *release the reference acquired with dma_buf_get() by calling
dma_buf_put().
*
* For the detailed semantics exporters are expected to implement see
* &dma_buf_ops.
@@ -802,7 +802,7 @@ static struct sg_table * __map_dma_buf(struct
dma_buf_attachment *attach,
* @importer_priv:[in]importer private pointer for the attachment
*
* Returns struct dma_buf_attachment pointer for this attachment. Attachments
- * must be cleaned up by calling dma_buf_detach().
+ * must be cleaned up by calling dma_buf_detach_unlocked().
*
* Optionally this calls &dma_buf_ops.attach to allow device-specific attach
* functionality.
@@ -858,8 +858,8 @@ dma_buf_dynamic_attach_unlocked(struct dma_buf *dmabuf,
struct device *dev,
dma_buf_is_dynamic(dmabuf)) {
struct sg_table *sgt;
+ dma_resv_lock(attach->dmabuf->resv, NULL);
if (dma_buf_is_dynamic(attach->dmabuf)) {
- dma_resv_lock(attach->dmabuf->resv, NULL);
ret = dmabuf->ops->pin(attach);
if (ret)
goto err_unlock;
@@ -872,8 +872,7 @@ dma_buf_dynamic_attach_unlocked(struct dma_buf *dmabuf,
struct device *dev,
ret = PTR_ERR(sgt);
goto err_unpin;
}
- if (dma_buf_is_dynamic(attach->dmabuf))
- dma_resv_unlock(attach->dmabuf->resv);
+ dma_resv_unlock(attach->dmabuf->resv);
attach->sgt = sgt;
attach->dir = DMA_BIDIRECTIONAL;
}
@@ -889,8 +888,7 @@ dma_buf_dynamic_attach_unlocked(struct dma_buf *dmabuf,
struct device *dev,
dmabuf->ops->unpin(attach);
err_unlock:
- if (dma_buf_is_dynamic(attach->dmabuf))
- dma_resv_unlock(attach->dmabuf->resv);
+ dma_resv_unlock(attach->dmabuf->resv);
dma_buf_detach_unlocked(dmabuf, attach);
return ERR_PTR(ret);
@@ -927,7 +925,7 @@ static void __unmap_dma_buf(struct dma_buf_attachment
*attach,
* @dmabuf: [in]buffer to detach from.
* @attach: [in]attachment to be detached; is free'd after this call.
*
- * Clean up a device attachment obtained by calling dma_buf_attach().
+ * Clean up a device attachment obtained by calling dma_buf_attach_unlocked().
*
* Optionally this calls &dma_buf_ops.detach for device-specific detach.
*/
@@ -937,21 +935,19 @@ void dma_buf_detach_unlocked(struct dma_buf *dmabuf,
if (WARN_ON(!dmabuf || !attach))
return;
+ dma_resv_lock(attach->dmabuf->resv, NULL);
+
if (atta
Re: [PATCH v3 5/9] dma-buf: Move dma_buf_mmap_unlocked() to dynamic locking specification
This should work, but I'm really wondering if this makes a difference
for somebody.
Anyway the approach is fine with me: Acked-by: Christian König
Regards,
Christian.
Am 24.08.22 um 12:22 schrieb Dmitry Osipenko:
Move dma_buf_mmap_unlocked() function to the dynamic locking specification
by taking the reservation lock. Neither of the today's drivers take the
reservation lock within the mmap() callback, hence it's safe to enforce
the locking.
Signed-off-by: Dmitry Osipenko
---
drivers/dma-buf/dma-buf.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index f358af401360..4556a12bd741 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1348,6 +1348,8 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_end_cpu_access, DMA_BUF);
int dma_buf_mmap_unlocked(struct dma_buf *dmabuf, struct vm_area_struct *vma,
unsigned long pgoff)
{
+ int ret;
+
if (WARN_ON(!dmabuf || !vma))
return -EINVAL;
@@ -1368,7 +1370,11 @@ int dma_buf_mmap_unlocked(struct dma_buf *dmabuf, struct vm_area_struct *vma,
vma_set_file(vma, dmabuf->file);
vma->vm_pgoff = pgoff;
- return dmabuf->ops->mmap(dmabuf, vma);
+ dma_resv_lock(dmabuf->resv, NULL);
+ ret = dmabuf->ops->mmap(dmabuf, vma);
+ dma_resv_unlock(dmabuf->resv);
+
+ return ret;
}
EXPORT_SYMBOL_NS_GPL(dma_buf_mmap_unlocked, DMA_BUF);
Re: [PATCH v4 11/31] drm/i915: Call acpi_video_register_backlight() (v2)
On Wed, 24 Aug 2022, Hans de Goede wrote:
> Hi,
>
> On 8/24/22 14:47, Jani Nikula wrote:
>> On Wed, 24 Aug 2022, Hans de Goede wrote:
>>> On machins without an i915 opregion the acpi_video driver immediately
>>> probes the ACPI video bus and used to also immediately register
>>> acpi_video# backlight devices when supported.
>>>
>>> Once the drm/kms driver then loaded later and possibly registered
>>> a native backlight device then the drivers/acpi/video_detect.c code
>>> unregistered the acpi_video0 device to avoid there being 2 backlight
>>> devices (when acpi_video_get_backlight_type()==native).
>>>
>>> This means that userspace used to briefly see 2 devices and the
>>> disappearing of acpi_video0 after a brief time confuses the systemd
>>> backlight level save/restore code, see e.g.:
>>> https://bbs.archlinux.org/viewtopic.php?id=269920
>>>
>>> To fix this the ACPI video code has been modified to make backlight class
>>> device registration a separate step, relying on the drm/kms driver to
>>> ask for the acpi_video backlight registration after it is done setting up
>>> its native backlight device.
>>>
>>> Add a call to the new acpi_video_register_backlight() after the i915 calls
>>> acpi_video_register() (after setting up the i915 opregion) so that the
>>> acpi_video backlight devices get registered on systems where the i915
>>> native backlight device is not registered.
>>>
>>> Changes in v2:
>>> -Only call acpi_video_register_backlight() when a panel is detected
>>>
>>> Signed-off-by: Hans de Goede
>>> ---
>>> drivers/gpu/drm/i915/display/intel_display.c | 8
>>> drivers/gpu/drm/i915/display/intel_panel.c | 3 +++
>>> drivers/gpu/drm/i915/i915_drv.h | 2 ++
>>> 3 files changed, 13 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
>>> b/drivers/gpu/drm/i915/display/intel_display.c
>>> index 6103b02c081f..2bb53efdb149 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_display.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_display.c
>>> @@ -9088,6 +9088,14 @@ void intel_display_driver_register(struct
>>> drm_i915_private *i915)
>>> /* Must be done after probing outputs */
>>> intel_opregion_register(i915);
>>> acpi_video_register();
>>> + /*
>>> +* Only call this if i915 is driving the internal panel. If the internal
>>> +* panel is not driven by i915 then another GPU driver may still
>>> register
>>> +* a native backlight driver later and this should only be called after
>>> +* any native backlights have been registered.
>>> +*/
>>> + if (i915->have_panel)
>>> + acpi_video_register_backlight();
>>
>> Apologies for procrastinating the review.
>>
>> Please let's not add new flags like have_panel to i915; we're trying to
>> clean it up instead.
>>
>> The code here needs to iterate over the connectors to decide. Maybe
>> better abstracted a function.
>
> So something like add a i915_have_panel() helper which iterates over all
> the connectors and then of 1 of them is of the LVDS / eDP / DSI type
> return true ?
Or abstract the acpi_video_register_backlight() calling in a function
that does the loop and calls if necessary.
BR,
Jani.
>
> Regards,
>
> Hans
>
>
>
>>> intel_audio_init(i915);
>>>
>>> diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
>>> b/drivers/gpu/drm/i915/display/intel_panel.c
>>> index 237a40623dd7..4536c527f50c 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_panel.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_panel.c
>>> @@ -646,8 +646,11 @@ intel_panel_mode_valid(struct intel_connector
>>> *connector,
>>>
>>> int intel_panel_init(struct intel_connector *connector)
>>> {
>>> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
>>> struct intel_panel *panel = &connector->panel;
>>>
>>> + dev_priv->have_panel = true;
>>> +
>>> intel_backlight_init_funcs(panel);
>>>
>>> drm_dbg_kms(connector->base.dev,
>>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
>>> b/drivers/gpu/drm/i915/i915_drv.h
>>> index 69ce6db6a7c1..14b0dcaf25c2 100644
>>> --- a/drivers/gpu/drm/i915/i915_drv.h
>>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>>> @@ -756,6 +756,8 @@ struct drm_i915_private {
>>>
>>> bool ipc_enabled;
>>>
>>> + bool have_panel;
>>> +
>>> struct intel_audio_private audio;
>>>
>>> struct i915_pmu pmu;
>>
>
--
Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH v4 02/31] drm/i915: Don't register backlight when another backlight should be used
On Wed, 24 Aug 2022, Hans de Goede wrote:
> Before this commit when we want userspace to use the acpi_video backlight
> device we register both the GPU's native backlight device and acpi_video's
> firmware acpi_video# backlight device. This relies on userspace preferring
> firmware type backlight devices over native ones.
>
> Registering 2 backlight devices for a single display really is
> undesirable, don't register the GPU's native backlight device when
> another backlight device should be used.
>
> Signed-off-by: Hans de Goede
> ---
> drivers/gpu/drm/i915/display/intel_backlight.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c
> b/drivers/gpu/drm/i915/display/intel_backlight.c
> index 681ebcda97ad..a4dd7924e0c1 100644
> --- a/drivers/gpu/drm/i915/display/intel_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_backlight.c
> @@ -8,6 +8,8 @@
> #include
> #include
>
> +#include
> +
> #include "intel_backlight.h"
> #include "intel_backlight_regs.h"
> #include "intel_connector.h"
> @@ -952,6 +954,11 @@ int intel_backlight_device_register(struct
> intel_connector *connector)
>
> WARN_ON(panel->backlight.max == 0);
>
> + if (!acpi_video_backlight_use_native()) {
> + DRM_INFO("Skipping intel_backlight registration\n");
Could use drm_info with drm_device.
Either way,
Reviewed-by: Jani Nikula
and ack for merging via whichever tree suits you best.
> + return 0;
> + }
> +
> memset(&props, 0, sizeof(props));
> props.type = BACKLIGHT_RAW;
--
Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH v4 11/31] drm/i915: Call acpi_video_register_backlight() (v2)
On Wed, 24 Aug 2022, Hans de Goede wrote:
> On machins without an i915 opregion the acpi_video driver immediately
> probes the ACPI video bus and used to also immediately register
> acpi_video# backlight devices when supported.
>
> Once the drm/kms driver then loaded later and possibly registered
> a native backlight device then the drivers/acpi/video_detect.c code
> unregistered the acpi_video0 device to avoid there being 2 backlight
> devices (when acpi_video_get_backlight_type()==native).
>
> This means that userspace used to briefly see 2 devices and the
> disappearing of acpi_video0 after a brief time confuses the systemd
> backlight level save/restore code, see e.g.:
> https://bbs.archlinux.org/viewtopic.php?id=269920
>
> To fix this the ACPI video code has been modified to make backlight class
> device registration a separate step, relying on the drm/kms driver to
> ask for the acpi_video backlight registration after it is done setting up
> its native backlight device.
>
> Add a call to the new acpi_video_register_backlight() after the i915 calls
> acpi_video_register() (after setting up the i915 opregion) so that the
> acpi_video backlight devices get registered on systems where the i915
> native backlight device is not registered.
>
> Changes in v2:
> -Only call acpi_video_register_backlight() when a panel is detected
>
> Signed-off-by: Hans de Goede
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 8
> drivers/gpu/drm/i915/display/intel_panel.c | 3 +++
> drivers/gpu/drm/i915/i915_drv.h | 2 ++
> 3 files changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 6103b02c081f..2bb53efdb149 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -9088,6 +9088,14 @@ void intel_display_driver_register(struct
> drm_i915_private *i915)
> /* Must be done after probing outputs */
> intel_opregion_register(i915);
> acpi_video_register();
> + /*
> + * Only call this if i915 is driving the internal panel. If the internal
> + * panel is not driven by i915 then another GPU driver may still
> register
> + * a native backlight driver later and this should only be called after
> + * any native backlights have been registered.
> + */
> + if (i915->have_panel)
> + acpi_video_register_backlight();
Apologies for procrastinating the review.
Please let's not add new flags like have_panel to i915; we're trying to
clean it up instead.
The code here needs to iterate over the connectors to decide. Maybe
better abstracted a function.
BR,
Jani.
>
> intel_audio_init(i915);
>
> diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
> b/drivers/gpu/drm/i915/display/intel_panel.c
> index 237a40623dd7..4536c527f50c 100644
> --- a/drivers/gpu/drm/i915/display/intel_panel.c
> +++ b/drivers/gpu/drm/i915/display/intel_panel.c
> @@ -646,8 +646,11 @@ intel_panel_mode_valid(struct intel_connector *connector,
>
> int intel_panel_init(struct intel_connector *connector)
> {
> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> struct intel_panel *panel = &connector->panel;
>
> + dev_priv->have_panel = true;
> +
> intel_backlight_init_funcs(panel);
>
> drm_dbg_kms(connector->base.dev,
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 69ce6db6a7c1..14b0dcaf25c2 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -756,6 +756,8 @@ struct drm_i915_private {
>
> bool ipc_enabled;
>
> + bool have_panel;
> +
> struct intel_audio_private audio;
>
> struct i915_pmu pmu;
--
Jani Nikula, Intel Open Source Graphics Center
RE: [PATCH] drm/amdkfd: Fix isa version for the GC 10.3.7
[Public]
Add more for the review and awareness.
Regards,
--Prike
-Original Message-
From: Prike Liang
Sent: Wednesday, August 24, 2022 2:41 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Huang, Ray
; Zhang, Yifan ; Liang, Prike
Subject: [PATCH] drm/amdkfd: Fix isa version for the GC 10.3.7
Correct the isa version for handling KFD test.
Fixes: 7c4f4f197e0c ("drm/amdkfd: Add GC 10.3.6 and 10.3.7 KFD definitions")
Signed-off-by: Prike Liang
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
index fdad1415f8bd..5ebbeac61379 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
@@ -388,7 +388,7 @@ struct kfd_dev *kgd2kfd_probe(struct amdgpu_device *adev,
bool vf)
f2g = &gfx_v10_3_kfd2kgd;
break;
case IP_VERSION(10, 3, 7):
- gfx_target_version = 100307;
+ gfx_target_version = 100306;
if (!vf)
f2g = &gfx_v10_3_kfd2kgd;
break;
--
2.25.1
Re: [PATCH v3 8/9] media: videobuf2: Stop using internal dma-buf lock
Nice!
Acked-by: Hans Verkuil
Regards,
Hans
On 24/08/2022 12:22, Dmitry Osipenko wrote:
> All drivers that use dma-bufs have been moved to the updated locking
> specification and now dma-buf reservation is guaranteed to be locked
> by importers during the mapping operations. There is no need to take
> the internal dma-buf lock anymore. Remove locking from the videobuf2
> memory allocators.
>
> Acked-by: Tomasz Figa
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/media/common/videobuf2/videobuf2-dma-contig.c | 11 +--
> drivers/media/common/videobuf2/videobuf2-dma-sg.c | 11 +--
> drivers/media/common/videobuf2/videobuf2-vmalloc.c| 11 +--
> 3 files changed, 3 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> index de762dbdaf78..2c69bf0470e7 100644
> --- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> +++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> @@ -382,18 +382,12 @@ static struct sg_table *vb2_dc_dmabuf_ops_map(
> struct dma_buf_attachment *db_attach, enum dma_data_direction dma_dir)
> {
> struct vb2_dc_attachment *attach = db_attach->priv;
> - /* stealing dmabuf mutex to serialize map/unmap operations */
> - struct mutex *lock = &db_attach->dmabuf->lock;
> struct sg_table *sgt;
>
> - mutex_lock(lock);
> -
> sgt = &attach->sgt;
> /* return previously mapped sg table */
> - if (attach->dma_dir == dma_dir) {
> - mutex_unlock(lock);
> + if (attach->dma_dir == dma_dir)
> return sgt;
> - }
>
> /* release any previous cache */
> if (attach->dma_dir != DMA_NONE) {
> @@ -409,14 +403,11 @@ static struct sg_table *vb2_dc_dmabuf_ops_map(
> if (dma_map_sgtable(db_attach->dev, sgt, dma_dir,
> DMA_ATTR_SKIP_CPU_SYNC)) {
> pr_err("failed to map scatterlist\n");
> - mutex_unlock(lock);
> return ERR_PTR(-EIO);
> }
>
> attach->dma_dir = dma_dir;
>
> - mutex_unlock(lock);
> -
> return sgt;
> }
>
> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> index 39e11600304a..e63e718c0bf7 100644
> --- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> +++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> @@ -424,18 +424,12 @@ static struct sg_table *vb2_dma_sg_dmabuf_ops_map(
> struct dma_buf_attachment *db_attach, enum dma_data_direction dma_dir)
> {
> struct vb2_dma_sg_attachment *attach = db_attach->priv;
> - /* stealing dmabuf mutex to serialize map/unmap operations */
> - struct mutex *lock = &db_attach->dmabuf->lock;
> struct sg_table *sgt;
>
> - mutex_lock(lock);
> -
> sgt = &attach->sgt;
> /* return previously mapped sg table */
> - if (attach->dma_dir == dma_dir) {
> - mutex_unlock(lock);
> + if (attach->dma_dir == dma_dir)
> return sgt;
> - }
>
> /* release any previous cache */
> if (attach->dma_dir != DMA_NONE) {
> @@ -446,14 +440,11 @@ static struct sg_table *vb2_dma_sg_dmabuf_ops_map(
> /* mapping to the client with new direction */
> if (dma_map_sgtable(db_attach->dev, sgt, dma_dir, 0)) {
> pr_err("failed to map scatterlist\n");
> - mutex_unlock(lock);
> return ERR_PTR(-EIO);
> }
>
> attach->dma_dir = dma_dir;
>
> - mutex_unlock(lock);
> -
> return sgt;
> }
>
> diff --git a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> index 7831bf545874..41db707e43a4 100644
> --- a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> +++ b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> @@ -267,18 +267,12 @@ static struct sg_table *vb2_vmalloc_dmabuf_ops_map(
> struct dma_buf_attachment *db_attach, enum dma_data_direction dma_dir)
> {
> struct vb2_vmalloc_attachment *attach = db_attach->priv;
> - /* stealing dmabuf mutex to serialize map/unmap operations */
> - struct mutex *lock = &db_attach->dmabuf->lock;
> struct sg_table *sgt;
>
> - mutex_lock(lock);
> -
> sgt = &attach->sgt;
> /* return previously mapped sg table */
> - if (attach->dma_dir == dma_dir) {
> - mutex_unlock(lock);
> + if (attach->dma_dir == dma_dir)
> return sgt;
> - }
>
> /* release any previous cache */
> if (attach->dma_dir != DMA_NONE) {
> @@ -289,14 +283,11 @@ static struct sg_table *vb2_vmalloc_dmabuf_ops_map(
> /* mapping to the client with new direction */
> if (dma_map_sgtable(db_attach->dev, sgt, dma_dir, 0)) {
> pr_err("failed to map scatterlist\n");
> - mutex_unlock(lock);
> return ERR_PTR(-EIO);
> }
>
>
Re: [PATCH] drm/sced: Add FIFO policy for scheduler rq
On 2022-08-22 22:09, Andrey Grodzovsky wrote: > Poblem: Given many entities competing for same rq on > same scheduler an uncceptabliy long wait time for some > jobs waiting stuck in rq before being picked up are > observed (seen using GPUVis). > The issue is due to Round Robin policy used by scheduler > to pick up the next entity for execution. Under stress > of many entities and long job queus within entity some > jobs could be stack for very long time in it's entity's > queue before being popped from the queue and executed > while for other entites with samller job queues a job > might execute ealier even though that job arrived later > then the job in the long queue. > > Fix: > Add FIFO selection policy to entites in RQ, chose next enitity > on rq in such order that if job on one entity arrived > ealrier then job on another entity the first job will start > executing ealier regardless of the length of the entity's job > queue. Instead of ordering based on when jobs are added, might it be possible to order them based on when they become ready to run? Otherwise it seems possible to e.g. submit a large number of inter-dependent jobs at once, and they would all run before any jobs from another queue get a chance. -- Earthling Michel Dänzer| https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
Re: [Bug 216373] New: Uncorrected errors reported for AMD GPU
On Sat, Aug 20, 2022 at 2:53 AM Lazar, Lijo wrote: > > Missed the remap part, the offset is here - > > https://elixir.bootlin.com/linux/v6.0-rc1/source/drivers/gpu/drm/amd/amdgpu/nv.c#L680 > > > The trace is coming from *_flush_hdp. > > You may also check if *_remap_hdp_registers() is getting called. It is > done in nbio_vx_y files, most likely this one for your device - > https://elixir.bootlin.com/linux/v6.0-rc1/source/drivers/gpu/drm/amd/amdgpu/nbio_v2_3.c#L68 > > Thanks, > Lijo Hi Lijo, I would be happy to test any patches that you think would shed some light on this.
Re: [Bug 216373] New: Uncorrected errors reported for AMD GPU #forregzbot
TWIMC: this mail is primarily send for documentation purposes and for regzbot, my Linux kernel regression tracking bot. These mails usually contain '#forregzbot' in the subject, to make them easy to spot and filter. [TLDR: I'm adding this regression report to the list of tracked regressions; all text from me you find below is based on a few templates paragraphs you might have encountered already already in similar form.] Hi, this is your Linux kernel regression tracker. On 18.08.22 22:38, Bjorn Helgaas wrote: > [Adding amdgpu folks] > > On Wed, Aug 17, 2022 at 11:45:15PM +, bugzilla-dae...@kernel.org wrote: >> https://bugzilla.kernel.org/show_bug.cgi?id=216373 >> >> Bug ID: 216373 >>Summary: Uncorrected errors reported for AMD GPU >> Kernel Version: v6.0-rc1 >> Regression: No >> ... > > I marked this as a regression in bugzilla. > >> Hardware: >> CPU: Intel i7-12700K (Alder Lake) >> GPU: AMD RX 6700 XT [1002:73df] >> Motherboard: ASUS Prime Z690-A >> >> Problem: >> After upgrading to v6.0-rc1 the kernel is now reporting uncorrected PCI >> errors >> for my GPU. > > Thank you very much for the report and for taking the trouble to > bisect it and test Kai-Heng's patch! > > I suspect that booting with "pci=noaer" should be a temporary > workaround for this issue. If it, can you add that to the bugzilla > for anybody else who trips over this? > >> I have bisected this issue to: [8795e182b02dc87e343c79e73af6b8b7f9c5e635] >> PCI/portdrv: Don't disable AER reporting in get_port_device_capability() >> Reverting that commit causes the errors to cease. > > I suspect the errors still occur, but we just don't notice and log > them. > >> I have also tried Kai-Heng Feng's patch[1] which seems to resolve a similar >> problem, but it did not fix my issue. >> >> [1] >> https://lore.kernel.org/linux-pci/20220706123244.18056-1-kai.heng.f...@canonical.com/ >> >> dmesg snippet: >> >> pcieport :00:01.0: AER: Multiple Uncorrected (Non-Fatal) error received: >> :03:00.0 >> amdgpu :03:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), >> type=Transaction Layer, (Requester ID) >> amdgpu :03:00.0: device [1002:73df] error status/mask=0010/ >> amdgpu :03:00.0:[20] UnsupReq (First) >> amdgpu :03:00.0: AER: TLP Header: 4001 000f 95e7f000 > > I think the TLP header decodes to: > > 0x4001 = 0100 ... 0001 binary > 0x000f = ... binary > > Fmt 010b 3 DW header with data > Type b 010 0 MWr Memory Write Request > Length00 0001b1 DW > Requester ID 0x 00:00.0 > Tag 0x00 > Last DW BEbmust be zero for 1 DW write > First DW BE ball 4 bytes in DW enabled > Address 0x95e7f000 > Data 0x > > So I think this is a 32-bit write of zero to PCI bus address > 0x95e7f000. > > Your dmesg log says: > > pci :02:00.0: PCI bridge to [bus 03] > pci :02:00.0: bridge window [mem 0x95e0-0x95ff] > pci :03:00.0: reg 0x24: [mem 0x95e0-0x95ef] > [drm] register mmio base: 0x95E0 > > So this looks like a write to the device's BAR 5. I don't see a PCI > reason why this should fail. Maybe there's some amdgpu reason? I'd like to add to the tracking to ensure it's not forgotten. #regzbot introduced: v5.19..v6.0-rc1 ^ https://bugzilla.kernel.org/show_bug.cgi?id=216373 #regzbot title: pci or amdgpu: Uncorrected errors reported for AMD GPU Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) P.S.: As the Linux kernel's regression tracker I deal with a lot of reports and sometimes miss something important when writing mails like this. If that's the case here, don't hesitate to tell me in a public reply, it's in everyone's interest to set the public record straight.
Re: [REGRESSION 5.19.x] AMD HD-audio devices missing on 5.19
On Tue, Aug 23, 2022 at 10:01:57PM +0100, Robin Murphy wrote: > > diff --git a/drivers/iommu/amd/iommu_v2.c b/drivers/iommu/amd/iommu_v2.c > > index 696dbe5794..6a1f02c62dffcc 100644 > > --- a/drivers/iommu/amd/iommu_v2.c > > +++ b/drivers/iommu/amd/iommu_v2.c > > @@ -777,6 +777,8 @@ int amd_iommu_init_device(struct pci_dev *pdev, int > > pasids) > > if (dev_state->domain == NULL) > > goto out_free_states; > > + /* See iommu_is_default_domain() */ > > + dev_state->domain->type = IOMMU_DOMAIN_IDENTITY; > > amd_iommu_domain_direct_map(dev_state->domain); > > Same question as 6 months ago, apparently: allocating an unmanaged domain > with a pagetable then sucking out the pagetable is silly enough, but if > we're going to then also call it a proper identity domain, we should really > just allocate an identity domain directly; but then why not just enable_v2 > on the identity domain that we know is already there courtesy of > def_domain_type? Yeah, nobody who knows this code answered that question either.. Looking at it a bit, I think this comment will start to be a problem: /* * Save us all sanity checks whether devices already in the * domain support IOMMUv2. Just force that the domain has no * devices attached when it is switched into IOMMUv2 mode. */ ret = -EBUSY; if (domain->dev_cnt > 0 || domain->flags & PD_IOMMUV2_MASK) goto out; Beacuse we should have dev_cnt != 0 on the existing identity domain at this point - worse if the probe order is backwards the sound driver may even already be running when we reach this. Plus the challenge of undoing it when the PASID user goes away. Overall I can see how it is easier and more logical to transition between two domains. We already have good infrastructure for doing that. >From a core perspective I don't have a real problem with iommu drivers using multiple iommu_domains to manage their internal operations, eg for different operating modes. But you are right that it should be cleaner and directly allocate the special domains it needs. This would be much more self-descriptive if it called a function 'allocate v2 identity domain', for instance. I think it would also make sense for the core to provide some API to change the default domain (ie dma API domain) of a group, and that would be a more logical, and self explanatory, API for iommu drivers to use than attach/detach. ie: iommu_change_default_domain(group, amd_identity_domain_v2): iommu_change_default_domain(group, amd_identity_domain_v1): At least for this effort I wanted something simple enough to backport that maybe doesn't need to be an expert in the amd iommu to write.. [I checked some more and the hack to change the type looks like it is OK on the free path, so maybe this even works] My general hope is that we can convince AMD to work on this once the generic PASID & PRI series lands, as this entire private path to the GPU driver and non-standard PASID handling all needs to be aligned with the upcoming core code. When doing that work it would make sense to tidy and modernize this better. I added a bunch of AMD people to this thread to that end. It sure would be good if AMD participated in that series since they are going to have to use it too. https://lore.kernel.org/linux-iommu/20220817012024.3251276-1-baolu...@linux.intel.com/ Regards, Jason
