[PATCH] drm/radeon: use time_after(a,b) to replace "a>b"
time_after() deals with timer wrapping correctly.
Signed-off-by: Yu Zhe
---
drivers/gpu/drm/radeon/radeon_pm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index e765abcb3b01..04c693ca419a 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -1899,7 +1899,7 @@ static void radeon_dynpm_idle_work_handler(struct
work_struct *work)
* to false since we want to wait for vbl to avoid flicker.
*/
if (rdev->pm.dynpm_planned_action != DYNPM_ACTION_NONE &&
- jiffies > rdev->pm.dynpm_action_timeout) {
+ time_after(jiffies, rdev->pm.dynpm_action_timeout)) {
radeon_pm_get_dynpm_state(rdev);
radeon_pm_set_clocks(rdev);
}
--
2.11.0
Re: [PATCH] drm: Remove the unused param "struct drm_buddy *mm"
On 27 6月 22 16:54:04, Cai Huoqing wrote:
> Remove the param "struct drm_buddy *mm" which is unused in
> the function drm_block_alloc()/drm_block_free().
Just ping this patch
>
> Signed-off-by: Cai Huoqing
> ---
> drivers/gpu/drm/drm_buddy.c | 25 +++--
> 1 file changed, 11 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
> index 11bb59399471..192c8b99fb43 100644
> --- a/drivers/gpu/drm/drm_buddy.c
> +++ b/drivers/gpu/drm/drm_buddy.c
> @@ -11,10 +11,8 @@
>
> static struct kmem_cache *slab_blocks;
>
> -static struct drm_buddy_block *drm_block_alloc(struct drm_buddy *mm,
> -struct drm_buddy_block *parent,
> -unsigned int order,
> -u64 offset)
> +static struct drm_buddy_block *
> +drm_block_alloc(struct drm_buddy_block *parent, unsigned int order, u64
> offset)
> {
> struct drm_buddy_block *block;
>
> @@ -32,8 +30,7 @@ static struct drm_buddy_block *drm_block_alloc(struct
> drm_buddy *mm,
> return block;
> }
>
> -static void drm_block_free(struct drm_buddy *mm,
> -struct drm_buddy_block *block)
> +static void drm_block_free(struct drm_buddy_block *block)
> {
> kmem_cache_free(slab_blocks, block);
> }
> @@ -131,7 +128,7 @@ int drm_buddy_init(struct drm_buddy *mm, u64 size, u64
> chunk_size)
> root_size = rounddown_pow_of_two(size);
> order = ilog2(root_size) - ilog2(chunk_size);
>
> - root = drm_block_alloc(mm, NULL, order, offset);
> + root = drm_block_alloc(NULL, order, offset);
> if (!root)
> goto out_free_roots;
>
> @@ -151,7 +148,7 @@ int drm_buddy_init(struct drm_buddy *mm, u64 size, u64
> chunk_size)
>
> out_free_roots:
> while (i--)
> - drm_block_free(mm, mm->roots[i]);
> + drm_block_free(mm->roots[i]);
> kfree(mm->roots);
> out_free_list:
> kfree(mm->free_list);
> @@ -172,7 +169,7 @@ void drm_buddy_fini(struct drm_buddy *mm)
>
> for (i = 0; i < mm->n_roots; ++i) {
> WARN_ON(!drm_buddy_block_is_free(mm->roots[i]));
> - drm_block_free(mm, mm->roots[i]);
> + drm_block_free(mm->roots[i]);
> }
>
> WARN_ON(mm->avail != mm->size);
> @@ -191,14 +188,14 @@ static int split_block(struct drm_buddy *mm,
> BUG_ON(!drm_buddy_block_is_free(block));
> BUG_ON(!drm_buddy_block_order(block));
>
> - block->left = drm_block_alloc(mm, block, block_order, offset);
> + block->left = drm_block_alloc(block, block_order, offset);
> if (!block->left)
> return -ENOMEM;
>
> - block->right = drm_block_alloc(mm, block, block_order,
> + block->right = drm_block_alloc(block, block_order,
> offset + (mm->chunk_size <<
> block_order));
> if (!block->right) {
> - drm_block_free(mm, block->left);
> + drm_block_free(block->left);
> return -ENOMEM;
> }
>
> @@ -257,8 +254,8 @@ static void __drm_buddy_free(struct drm_buddy *mm,
>
> list_del(>link);
>
> - drm_block_free(mm, block);
> - drm_block_free(mm, buddy);
> + drm_block_free(block);
> + drm_block_free(buddy);
>
> block = parent;
> }
> --
> 2.25.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 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 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 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 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 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 = >gfx.kiq.ring;
struct amdgpu_kiq *kiq = >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(>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 = >gfx.kiq.ring;
struct amdgpu_kiq *kiq = >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(>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(>reset_sem);
--
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.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 = >gfx.kiq.ring;
struct amdgpu_kiq *kiq = >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(>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 = >gfx.kiq.ring;
struct amdgpu_kiq *kiq = >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(>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(>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 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 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 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 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, _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.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 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 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 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 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 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 == >irq.ih) {
+ if (ih == >irq.ih || ih == >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 == >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 == >irq.ih) {
+ if (ih == >irq.ih || ih == >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 == >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 == >irq.ih) {
+ if (ih == >irq.ih || ih == >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 == >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 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 = >gfx.kiq.ring;
struct amdgpu_kiq *kiq = >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(>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 = >gfx.kiq.ring;
struct amdgpu_kiq *kiq = >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(>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(>reset_domain->sem);
--
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 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, _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 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 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 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 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 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 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, >wait_result);
+ >timeout, >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([i].event->lock);
remove_wait_queue([i].event->wq,
[i].wait);
+ if (undo_auto_reset && waiters[i].activated &&
+ waiters[i].event && waiters[i].event->auto_reset)
+ set_event(waiters[i].event);
spin_unlock([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(>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 *p);
int kfd_event_mmap(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 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 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 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 05/38] drm/amd/display: Add a missing register field for HPO DP stream encoder
From: Aurabindo Pillai [ Upstream commit 37bc31f0e7da4fbad4664e64d906ae7b9009e550 ] [Why] 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: [PATCH v3] drm/msm/dp: correct 1.62G link rate at dp_catalog_ctrl_config_msa()
Hi,
On Wed, Aug 24, 2022 at 1:16 PM Kuogee Hsieh wrote:
>
> At current implementation there is an extra 0 at 1.62G link rate which cause
> no correct pixel_div selected for 1.62G link rate to calculate mvid and nvid.
> This patch delete the extra 0 to have mvid and nvid be calculated correctly.
>
> Changes in v2:
> -- fix Fixes tag's text
>
> Changes in v3:
> -- fix misspelling of "Reviewed-by"
>
> Fixes: 937f941ca06f ("drm/msm/dp: Use qmp phy for DP PLL and PHY")
> Signed-off-by: Kuogee Hsieh
>
> Reviewed-by: Stephen Boyd
> Reviewed-by: Abhinav Kumar
> ---
> drivers/gpu/drm/msm/dp/dp_catalog.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Douglas Anderson
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 -
[PATCH drm-misc-next v3 0/4] Fixes for vc4 hotplug rework
Hi, I've found a few potential issues left after the hotplug rework. In vc4_hdmi.c we're missing two mutex_unlock() calls when the device is unplugged. vc4_crtc and vc4_plane seem to miss some drm_dev_enter()/drm_dev_exit() calls to protect against resource access after the device/driver is unbound, but the DRM potentially isn't freed yet and userspace can still call into the driver. Changes in v2: - Use drm_device pointer from struct drm_plane (Maxime) - Protect entire functions to increase readability (Maxime) - Add another patch to fix an uncovered MMIO access in vc4_hvs.c Changes in v3: - vc4_plane: Actually protect entire functions to increase readability (Maxime) Danilo Krummrich (4): drm/vc4: hdmi: unlock mutex when device is unplugged drm/vc4: plane: protect device resources after removal drm/vc4: crtc: protect device resources after removal drm/vc4: hvs: protect drm_print_regset32() drivers/gpu/drm/vc4/vc4_crtc.c | 41 - drivers/gpu/drm/vc4/vc4_hdmi.c | 7 -- drivers/gpu/drm/vc4/vc4_hvs.c | 4 ++-- drivers/gpu/drm/vc4/vc4_plane.c | 20 4 files changed, 67 insertions(+), 5 deletions(-) base-commit: 4d07b0bc403403438d9cf88450506240c5faf92f -- 2.37.2
Re: [PATCH v3,2/2] drm: mediatek: Adjust the dpi output format to MT8186
On Wed, Aug 24, 2022 at 09:59:21AM +0800, xinlei.lee wrote:
> On Tue, 2022-08-23 at 16:16 -0400, Nícolas F. R. A. Prado wrote:
> > On Tue, Aug 23, 2022 at 02:18:37PM +0800, xinlei@mediatek.com
> > wrote:
> > > From: Xinlei Lee
> > >
> > > Dpi output needs to adjust the output format to dual edge for
> > > MT8186.
> > > Because MT8186 HW has been modified at that time, SW needs to
> > > cooperate.
> > > And the register (MMSYS) reserved for dpi will be used for output
> > > format control (dual_edge/single_edge).
> > >
> > > Co-developed-by: Jitao Shi
> > > Signed-off-by: Jitao Shi
> > > Signed-off-by: Xinlei Lee
> > >
> > > ---
> >
> > [..]
> > > --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> >
> > [..]
> > > * @yuv422_en_bit: Enable bit of yuv422.
> > > * @csc_enable_bit: Enable bit of CSC.
> > > * @pixels_per_iter: Quantity of transferred pixels per iteration.
> > > + * @rgb888_dual_enable: Control output format for mt8186.
> >
> > Let's not mention mt8186 in the description to keep the property
> > generic. Also,
> > this description should say what having 'rgb888_dual_enable = true'
> > indicates
> > about the hardware (in this case mt8186) and it currently doesn't.
> >
> > Let's take a step back. What does 'dual enable' mean in this context
> > and how
> > does it relate to 'dual edge' and the dpi output format? By answering
> > those
> > questions we can find a description (and maybe variable name) that
> > makes more
> > sense.
> >
> > > */
> >
> > [..]
> > > @@ -449,6 +454,9 @@ static void mtk_dpi_dual_edge(struct mtk_dpi
> > > *dpi)
> > > mtk_dpi_mask(dpi, DPI_OUTPUT_SETTING,
> > >dpi->output_fmt ==
> > > MEDIA_BUS_FMT_RGB888_2X12_LE ?
> > >EDGE_SEL : 0, EDGE_SEL);
> > > + if (dpi->conf->rgb888_dual_enable)
> > > + mtk_mmsys_ddp_dpi_fmt_config(dpi->mmsys_dev,
> > > DPI_RGB888_DDR_CON,
> > > + DPI_FORMAT_MASK, NULL);
> >
> > This if block should be further indented.
> >
> > > } else {
> > > mtk_dpi_mask(dpi, DPI_DDR_SETTING, DDR_EN | DDR_4PHASE,
> > > 0);
> > > }
> >
> > [..]
> > > --- a/drivers/gpu/drm/mediatek/mtk_dpi_regs.h
> > > +++ b/drivers/gpu/drm/mediatek/mtk_dpi_regs.h
> > > @@ -235,4 +235,8 @@
> > > #define MATRIX_SEL_RGB_TO_JPEG 0
> > > #define MATRIX_SEL_RGB_TO_BT601 2
> > >
> > > +#define DPI_FORMAT_MASK 0x1
> > > +#define DPI_RGB888_DDR_CON BIT(0)
> > > +#define DPI_RGB565_SDR_CON BIT(1)
> >
> > I'm not sure if it would make more sense to have these definitions in
> > the mmsys
> > header since they're configurations of a register in mmsys'
> > iospace... I think
> > we can keep them here but at least add a comment above:
> >
> > /* Values for DPI configuration in MMSYS address space */
> >
> > Thanks,
> > Nícolas
>
> Hi Nícolas:
> Thanks for your careful review!
> I will modify the description of this member variable and add the
> hardware state corresponding to the software setting.
> (eg. rgb888_dual_enable = true the hardware output rgb888_dual_edge
> format data)
>
> Your suggestion is very necessary, maybe my name is not accurate
> enough, this flag is to enable RGB888_dual_edge format output.
> Would it be better for the variable to be called
> RGB888_dual_edge_enable then?
The thing is, we also output in rgb888 dual edge format on mt8183 and mt8192,
and therefore set DDR_EN in mtk_dpi_dual_edge(), right? But, as you said, we
don't need to enable this new rgb888_dual_enable variable on those platforms,
only on mt8186. So that's why I don't think the current name/description is
suitable. If the variable only needs to be set on mt8186, it should have a name
and description that shows what is different between mt8186 and the others. But
without containing the "mt8186" name, since this might happen on other SoCs
later on.
My understanding is that even though both mt8186 and mt8192 output in the rgb888
dual edge format, only mt8186 is able to configure the edge setting in MMSYS (so
on mt8192 it would be hardwired to dual edge and not possible to change). So
what I propose is
Name: edge_cfg_in_mmsys
Description: "If the edge configuration for DPI's output needs to be set in
MMSYS"
But maybe since you know the hardware, you might be able to find an even better
name/description.
Thanks,
Nícolas
[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
Re: [PATCH] dma-buf: Use dma_fence_unwrap_for_each when importing fences
Am 24.08.22 um 16:47 schrieb Jason Ekstrand:
On Mon, Aug 8, 2022 at 11:39 AM Jason Ekstrand
wrote:
On Sun, 2022-08-07 at 18:35 +0200, Christian König wrote:
> Am 02.08.22 um 23:01 schrieb Jason Ekstrand:
> > Ever since 68129f431faa ("dma-buf: warn about containers in
> > dma_resv object"),
> > dma_resv_add_shared_fence will warn if you attempt to add a
> > container fence.
> > While most drivers were fine, fences can also be added to a
> > dma_resv via the
> > recently added DMA_BUF_IOCTL_IMPORT_SYNC_FILE. Use
> > dma_fence_unwrap_for_each
> > to add each fence one at a time.
> >
> > Fixes: 594740497e99 ("dma-buf: Add an API for importing sync files
> > (v10)")
> > Signed-off-by: Jason Ekstrand
> > Reported-by: Sarah Walker
> > Cc: Christian König
> > ---
> > drivers/dma-buf/dma-buf.c | 23 +--
> > 1 file changed, 17 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> > index 630133284e2b..8d5d45112f52 100644
> > --- a/drivers/dma-buf/dma-buf.c
> > +++ b/drivers/dma-buf/dma-buf.c
> > @@ -15,6 +15,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -391,8 +392,10 @@ static long dma_buf_import_sync_file(struct
> > dma_buf *dmabuf,
> > const void __user *user_data)
> > {
> > struct dma_buf_import_sync_file arg;
> > - struct dma_fence *fence;
> > + struct dma_fence *fence, *f;
> > enum dma_resv_usage usage;
> > + struct dma_fence_unwrap iter;
> > + unsigned int num_fences;
> > int ret = 0;
> >
> > if (copy_from_user(, user_data, sizeof(arg)))
> > @@ -411,13 +414,21 @@ static long dma_buf_import_sync_file(struct
> > dma_buf *dmabuf,
> > usage = (arg.flags & DMA_BUF_SYNC_WRITE) ?
> > DMA_RESV_USAGE_WRITE :
> >
> > DMA_RESV_USAGE_READ;
> >
> > - dma_resv_lock(dmabuf->resv, NULL);
> > + num_fences = 0;
> > + dma_fence_unwrap_for_each(f, , fence)
> > + ++num_fences;
> >
> > - ret = dma_resv_reserve_fences(dmabuf->resv, 1);
> > - if (!ret)
> > - dma_resv_add_fence(dmabuf->resv, fence, usage);
> > + if (num_fences > 0) {
> > + dma_resv_lock(dmabuf->resv, NULL);
> >
> > - dma_resv_unlock(dmabuf->resv);
> > + ret = dma_resv_reserve_fences(dmabuf->resv,
> > num_fences);
>
> That looks like it is misplaced.
>
> You *must* only lock the reservation object once and then add all
> fences
> in one go.
That's what I'm doing. Lock, reserve, add a bunch, unlock. I am
assuming that the iterator won't suddenly want to iterate more fences
between my initial count and when I go to add them but I think that
assumption is ok.
Bump. This has been sitting here for a couple of weeks. I still don't
see the problem.
I've send you a patch for a bug fix in the dma_resv object regarding this.
Apart from that I've just seen that I miss read the code a bit, didn't
realized that there where two loops with dma_fence_unwrap_for_each().
Regards,
Christian.
--Jason
--Jason
> Thinking now about it we probably had a bug around that before as
> well.
> Going to double check tomorrow.
>
> Regards,
> Christian.
>
> > + if (!ret) {
> > + dma_fence_unwrap_for_each(f, , fence)
> >
+ dma_resv_add_fence(dmabuf->resv, f,
> > usage);
> > + }
> > +
> > + dma_resv_unlock(dmabuf->resv);
> > + }
> >
> > dma_fence_put(fence);
> >
>
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 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(, 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 = >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
[PATCH v4 23/31] platform/x86: asus-wmi: Drop DMI chassis-type check from backlight handling
Remove this check from the asus-wmi backlight handling: /* Some Asus desktop boards export an acpi-video backlight interface, stop this from showing up */ chassis_type = dmi_get_system_info(DMI_CHASSIS_TYPE); if (chassis_type && !strcmp(chassis_type, "3")) acpi_video_set_dmi_backlight_type(acpi_backlight_vendor); This acpi_video_set_dmi_backlight_type(acpi_backlight_vendor) call must be removed because other changes in this series change the native backlight drivers to no longer unconditionally register their backlight. Instead these drivers now do this check: if (acpi_video_get_backlight_type(false) != acpi_backlight_native) return 0; /* bail */ So leaving this in place can break things on laptops with a broken DMI chassis-type, which would have GPU native brightness control before the addition of the acpi_video_get_backlight_type() != native check. Removing this should be ok now, since the ACPI video code has improved heuristics for this itself now (which includes a chassis-type check). Signed-off-by: Hans de Goede --- drivers/platform/x86/asus-wmi.c | 7 --- 1 file changed, 7 deletions(-) diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c index 89b604e04d7f..301166a5697d 100644 --- a/drivers/platform/x86/asus-wmi.c +++ b/drivers/platform/x86/asus-wmi.c @@ -3553,7 +3553,6 @@ static int asus_wmi_add(struct platform_device *pdev) struct platform_driver *pdrv = to_platform_driver(pdev->dev.driver); struct asus_wmi_driver *wdrv = to_asus_wmi_driver(pdrv); struct asus_wmi *asus; - const char *chassis_type; acpi_status status; int err; u32 result; @@ -3635,12 +3634,6 @@ static int asus_wmi_add(struct platform_device *pdev) if (asus->driver->quirks->wmi_force_als_set) asus_wmi_set_als(); - /* Some Asus desktop boards export an acpi-video backlight interface, - stop this from showing up */ - chassis_type = dmi_get_system_info(DMI_CHASSIS_TYPE); - if (chassis_type && !strcmp(chassis_type, "3")) - acpi_video_set_dmi_backlight_type(acpi_backlight_vendor); - if (asus->driver->quirks->wmi_backlight_power) acpi_video_set_dmi_backlight_type(acpi_backlight_vendor); -- 2.37.2
Re: [Intel-gfx] [PATCH v2 02/21] drm/i915: Parse and set stepping for platforms with GMD
On 18.08.2022 16:41, Radhakrishna Sripada wrote:
> From: José Roberto de Souza
>
> The GMD step field do not properly match the current stepping convention
> that we use(STEP_A0, STEP_A1, STEP_B0...).
>
> One platform could have { arch = 12, rel = 70, step = 1 } and the
> actual stepping is STEP_B0 but without the translation of the step
> field would mean STEP_A1.
> That is why we will need to have gmd_to_intel_step tables for each IP.
>
> Signed-off-by: José Roberto de Souza
> Signed-off-by: Radhakrishna Sripada
> ---
> drivers/gpu/drm/i915/intel_step.c | 60 +++
> 1 file changed, 60 insertions(+)
Reviewed-by: Balasubramani Vivekanandan
>
> diff --git a/drivers/gpu/drm/i915/intel_step.c
> b/drivers/gpu/drm/i915/intel_step.c
> index 42b3133d8387..0fa7147c7d0f 100644
> --- a/drivers/gpu/drm/i915/intel_step.c
> +++ b/drivers/gpu/drm/i915/intel_step.c
> @@ -135,6 +135,48 @@ static const struct intel_step_info adlp_n_revids[] = {
> [0x0] = { COMMON_GT_MEDIA_STEP(A0), .display_step = STEP_D0 },
> };
>
> +struct gmd_to_intel_step {
> + struct ip_version gmd;
> + enum intel_step step;
> +};
> +
> +static const struct gmd_to_intel_step gmd_graphics_table[] = {
> + { .gmd.ver = 12, .gmd.rel = 70, .gmd.step = 0, .step = STEP_A0 },
> + { .gmd.ver = 12, .gmd.rel = 70, .gmd.step = 4, .step = STEP_B0 },
> + { .gmd.ver = 12, .gmd.rel = 71, .gmd.step = 0, .step = STEP_A0 },
> + { .gmd.ver = 12, .gmd.rel = 71, .gmd.step = 4, .step = STEP_B0 },
> + { .gmd.ver = 12, .gmd.rel = 73, .gmd.step = 0, .step = STEP_A0 },
> + { .gmd.ver = 12, .gmd.rel = 73, .gmd.step = 4, .step = STEP_B0 },
> +};
> +
> +static const struct gmd_to_intel_step gmd_media_table[] = {
> + { .gmd.ver = 13, .gmd.rel = 70, .gmd.step = 0, .step = STEP_A0 },
> + { .gmd.ver = 13, .gmd.rel = 70, .gmd.step = 4, .step = STEP_B0 },
> +};
> +
> +static const struct gmd_to_intel_step gmd_display_table[] = {
> + { .gmd.ver = 14, .gmd.rel = 0, .gmd.step = 0, .step = STEP_A0 },
> + { .gmd.ver = 14, .gmd.rel = 0, .gmd.step = 4, .step = STEP_B0 },
> +};
> +
> +static u8 gmd_to_intel_step(struct drm_i915_private *i915,
> + struct ip_version *gmd,
> + const struct gmd_to_intel_step *table,
> + int len)
> +{
> + int i;
> +
> + for (i = 0; i < len; i++) {
> + if (table[i].gmd.ver == gmd->ver &&
> + table[i].gmd.rel == gmd->rel &&
> + table[i].gmd.step == gmd->step)
> + return table[i].step;
> + }
> +
> + drm_dbg(>drm, "Using future steppings\n");
> + return STEP_FUTURE;
> +}
> +
> static void pvc_step_init(struct drm_i915_private *i915, int pci_revid);
>
> void intel_step_init(struct drm_i915_private *i915)
> @@ -144,6 +186,24 @@ void intel_step_init(struct drm_i915_private *i915)
> int revid = INTEL_REVID(i915);
> struct intel_step_info step = {};
>
> + if (HAS_GMD_ID(i915)) {
> + step.graphics_step = gmd_to_intel_step(i915,
> +
> _INFO(i915)->graphics,
> +gmd_graphics_table,
> +
> ARRAY_SIZE(gmd_graphics_table));
> + step.media_step = gmd_to_intel_step(i915,
> + _INFO(i915)->media,
> + gmd_media_table,
> +
> ARRAY_SIZE(gmd_media_table));
> + step.display_step = gmd_to_intel_step(i915,
> +
> _INFO(i915)->display,
> + gmd_display_table,
> +
> ARRAY_SIZE(gmd_display_table));
> + RUNTIME_INFO(i915)->step = step;
> +
> + return;
> + }
> +
> if (IS_PONTEVECCHIO(i915)) {
> pvc_step_init(i915, revid);
> return;
> --
> 2.25.1
>
[PATCH 3/4] dt-bindings: display: Document Jadard JD9365DA-H3 DSI panel
Jadard JD9365DA-H3 is WUXGA MIPI DSI panel and it support TFT
dot matrix LCD with 800RGBx1280 dots at maximum.
Document it.
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Jagan Teki
---
.../display/panel/jadard,jd9365da-h3.yaml | 70 +++
MAINTAINERS | 5 ++
2 files changed, 75 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml
b/Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml
new file mode 100644
index ..23dfd5b5496e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/jadard,jd9365da-h3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Jadard JD9365DA-HE WUXGA DSI panel
+
+maintainers:
+ - Jagan Teki
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+items:
+ - enum:
+ - chongzhou,cz101b4001
+ - const: jadard,jd9365da-h3
+
+ reg: true
+
+ vdd-supply:
+description: supply regulator for VDD, usually 3.3V
+
+ vccio-supply:
+description: supply regulator for VCCIO, usually 1.8V
+
+ reset-gpios: true
+
+ backlight: true
+
+ port: true
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+ - vccio-supply
+ - reset-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+panel@0 {
+compatible = "chongzhou,cz101b4001", "jadard,jd9365da-h3";
+reg = <0>;
+vdd-supply = <_3v3>;
+vccio-supply = <_1v8>;
+reset-gpios = < RK_PC2 GPIO_ACTIVE_HIGH>;
+backlight = <>;
+
+port {
+mipi_in_panel: endpoint {
+remote-endpoint = <_out_panel>;
+};
+};
+};
+};
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index 5c96115c620f..2ef50447e6e8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6466,6 +6466,11 @@ S: Orphan / Obsolete
F: drivers/gpu/drm/i810/
F: include/uapi/drm/i810_drm.h
+DRM DRIVER FOR JADARD JD9365DA-H3 MIPI-DSI LCD PANELS
+M: Jagan Teki
+S: Maintained
+F: Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml
+
DRM DRIVER FOR LOGICVC DISPLAY CONTROLLER
M: Paul Kocialkowski
S: Supported
--
2.25.1
Re: [PATCH] disp/dpu1: fix repeated words in comments
Please fix the subject line .
It should be drm/msm/dpu: fix repeated words in comments
Also, you can add
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
On 8/23/2022 4:51 AM, Jilin Yuan wrote:
Delete the redundant word 'is'.
Signed-off-by: Jilin Yuan
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index bce47647d891..59ca7d70a652 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1169,7 +1169,7 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
/*
* max crtc width is equal to the max mixer width * 2 and max height is
-* is 4K
+* 4K
*/
dev->mode_config.max_width =
dpu_kms->catalog->caps->max_mixer_width * 2;
[PATCH] i915/gvt: fix repeated words in comments
Delete the redundant word 'the'. Signed-off-by: wangjianli --- drivers/gpu/drm/i915/gvt/gtt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c index b4f69364f9a1..62e5f27adca9 100644 --- a/drivers/gpu/drm/i915/gvt/gtt.c +++ b/drivers/gpu/drm/i915/gvt/gtt.c @@ -2786,7 +2786,7 @@ int intel_gvt_init_gtt(struct intel_gvt *gvt) * @gvt: GVT device * * This function is called at the driver unloading stage, to clean up the - * the mm components of a GVT device. + * mm components of a GVT device. * */ void intel_gvt_clean_gtt(struct intel_gvt *gvt) -- 2.36.1
[PATCH] gpu/drm: fix repeated words in comments
Delete the redundant word 'the'. Signed-off-by: wangjianli --- drivers/gpu/drm/drm_mipi_dsi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c index c40bde96cfdf..fd2790a5664d 100644 --- a/drivers/gpu/drm/drm_mipi_dsi.c +++ b/drivers/gpu/drm/drm_mipi_dsi.c @@ -606,7 +606,7 @@ EXPORT_SYMBOL(mipi_dsi_turn_on_peripheral); /* * mipi_dsi_set_maximum_return_packet_size() - specify the maximum size of the - *the payload in a long packet transmitted from the peripheral back to the + *payload in a long packet transmitted from the peripheral back to the *host processor * @dsi: DSI peripheral device * @value: the maximum size of the payload -- 2.36.1
[PATCH] gpu/drm/display: fix repeated words in comments
Delete the redundant word 'the'. Signed-off-by: wangjianli --- drivers/gpu/drm/display/drm_dp_helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/display/drm_dp_helper.c b/drivers/gpu/drm/display/drm_dp_helper.c index e7c22c2ca90c..499f75768523 100644 --- a/drivers/gpu/drm/display/drm_dp_helper.c +++ b/drivers/gpu/drm/display/drm_dp_helper.c @@ -1597,7 +1597,7 @@ static int drm_dp_aux_reply_duration(const struct drm_dp_aux_msg *msg) * Calculate the length of the i2c transfer in usec, assuming * the i2c bus speed is as specified. Gives the the "worst" * case estimate, ie. successful while as long as possible. - * Doesn't account the the "MOT" bit, and instead assumes each + * Doesn't account the "MOT" bit, and instead assumes each * message includes a START, ADDRESS and STOP. Neither does it * account for additional random variables such as clock stretching. */ -- 2.36.1
[PATCH] drm/i915: fix repeated words in comments
Delete the redundant word 'other'. Delete the redundant word 'the'. Delete the redundant word 'will'. Signed-off-by: Jilin Yuan --- drivers/gpu/drm/i915/i915_gem_evict.c | 2 +- drivers/gpu/drm/i915/i915_irq.c | 4 ++-- drivers/gpu/drm/i915/i915_memcpy.h| 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c b/drivers/gpu/drm/i915/i915_gem_evict.c index f025ee4fa526..028e509e1628 100644 --- a/drivers/gpu/drm/i915/i915_gem_evict.c +++ b/drivers/gpu/drm/i915/i915_gem_evict.c @@ -256,7 +256,7 @@ i915_gem_evict_something(struct i915_address_space *vm, goto search_again; found: - /* drm_mm doesn't allow any other other operations while + /* drm_mm doesn't allow any other operations while * scanning, therefore store to-be-evicted objects on a * temporary list and take a reference for all before * calling unbind (which may remove the active reference diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 73cebc6aa650..1e4a705bc5cc 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -65,7 +65,7 @@ /* * Interrupt statistic for PMU. Increments the counter only if the - * interrupt originated from the the GPU so interrupts from a device which + * interrupt originated from the GPU so interrupts from a device which * shares the interrupt line are not accounted. */ static inline void pmu_irq_stats(struct drm_i915_private *i915, @@ -2175,7 +2175,7 @@ static irqreturn_t ilk_irq_handler(int irq, void *arg) raw_reg_write(regs, DEIER, de_ier & ~DE_MASTER_IRQ_CONTROL); /* Disable south interrupts. We'll only write to SDEIIR once, so further -* interrupts will will be stored on its back queue, and then we'll be +* interrupts will be stored on its back queue, and then we'll be * able to process them after we restore SDEIER (as soon as we restore * it, we'll get an interrupt if SDEIIR still has something to process * due to its back queue). */ diff --git a/drivers/gpu/drm/i915/i915_memcpy.h b/drivers/gpu/drm/i915/i915_memcpy.h index 3df063a3293b..126dfb4352f0 100644 --- a/drivers/gpu/drm/i915/i915_memcpy.h +++ b/drivers/gpu/drm/i915/i915_memcpy.h @@ -18,7 +18,7 @@ void i915_unaligned_memcpy_from_wc(void *dst, const void *src, unsigned long len /* The movntdqa instructions used for memcpy-from-wc require 16-byte alignment, * as well as SSE4.1 support. i915_memcpy_from_wc() will report if it cannot * perform the operation. To check beforehand, pass in the parameters to - * to i915_can_memcpy_from_wc() - since we only care about the low 4 bits, + * i915_can_memcpy_from_wc() - since we only care about the low 4 bits, * you only need to pass in the minor offsets, page-aligned pointers are * always valid. * -- 2.36.1
[PATCH] gpu/drm: fix repeated words in comments
Delete the redundant word 'old'. Delete the redundant word 'new'. Signed-off-by: Jilin Yuan --- drivers/gpu/drm/drm_context.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_context.c b/drivers/gpu/drm/drm_context.c index c6e6a3e7219a..2d871159162b 100644 --- a/drivers/gpu/drm/drm_context.c +++ b/drivers/gpu/drm/drm_context.c @@ -267,8 +267,8 @@ int drm_legacy_setsareactx(struct drm_device *dev, void *data, * Switch context. * * \param dev DRM device. - * \param old old context handle. - * \param new new context handle. + * \param old context handle. + * \param new context handle. * \return zero on success or a negative number on failure. * * Attempt to set drm_device::context_flag. @@ -294,7 +294,7 @@ static int drm_context_switch(struct drm_device * dev, int old, int new) * Complete context switch. * * \param dev DRM device. - * \param new new context handle. + * \param new context handle. * \return zero on success or a negative number on failure. * * Updates drm_device::last_context and drm_device::last_switch. Verifies the -- 2.36.1
[PATCH v2 4/4] drm/tests: Set also mock plane src_x, src_y, src_w and src_h
We need to set also src_x, src_y, src_w and src_h for the mock plane.
After fix for drm_atomic_helper_damage_iter_init we are using these
when iterating damage_clips.
Signed-off-by: Jouni Högander
---
drivers/gpu/drm/tests/drm_damage_helper_test.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/tests/drm_damage_helper_test.c
b/drivers/gpu/drm/tests/drm_damage_helper_test.c
index bf250bd08d7e..c608ae06f0e3 100644
--- a/drivers/gpu/drm/tests/drm_damage_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_damage_helper_test.c
@@ -59,6 +59,11 @@ static int drm_damage_helper_init(struct kunit *test)
static void set_plane_src(struct drm_plane_state *state, int x1, int y1, int
x2,
int y2)
{
+ state->src_x = x1;
+ state->src_y = y1;
+ state->src_w = x2 - x1;
+ state->src_h = y2 - y1;
+
state->src.x1 = x1;
state->src.y1 = y1;
state->src.x2 = x2;
--
2.34.1
Re: [PATCH v4 5/6] dt-bindings: drm/msm/gpu: Add optional resets
On 19/08/2022 19:40, Akhil P Oommen wrote: > Documentation/devicetree/bindings/display/msm/gpu.yaml | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/Documentation/devicetree/bindings/display/msm/gpu.yaml > b/Documentation/devicetree/bindings/display/msm/gpu.yaml > index 3397bc3..4576b31 100644 > --- a/Documentation/devicetree/bindings/display/msm/gpu.yaml > +++ b/Documentation/devicetree/bindings/display/msm/gpu.yaml > @@ -109,6 +109,13 @@ properties: >For GMU attached devices a phandle to the GMU device that will >control the power for the GPU. > > + resets: > +maxItems: 1 > + > + reset-names: > +items: > + - const: cx_collapse > + Just one blank line, not two. You can keep Rob's ack with that change. > required: >- compatible Best regards, Krzysztof
[PATCH v8 8/8] drm/i915: Remove truncation warning for large objects
From: Chris Wilson
Having addressed the issues surrounding incorrect types for local
variables and potential integer truncation in using the scatterlist API,
we have closed all the loop holes we had previously identified with
dangerously large object creation. As such, we can eliminate the warning
put in place to remind us to complete the review.
Signed-off-by: Chris Wilson
Signed-off-by: Gwan-gyeong Mun
Cc: Tvrtko Ursulin
Cc: Brian Welty
Cc: Matthew Auld
Cc: Thomas Hellström
Testcase: igt@gem_create@create-massive
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4991
Reviewed-by: Nirmoy Das
Reviewed-by: Mauro Carvalho Chehab
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/i915/gem/i915_gem_object.h | 15 ---
1 file changed, 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 0cf31adbfd41..dd2762da332f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -20,25 +20,10 @@
enum intel_region_id;
-/*
- * XXX: There is a prevalence of the assumption that we fit the
- * object's page count inside a 32bit _signed_ variable. Let's document
- * this and catch if we ever need to fix it. In the meantime, if you do
- * spot such a local variable, please consider fixing!
- *
- * We can check for invalidly typed locals with typecheck(), see for example
- * i915_gem_object_get_sg().
- */
-#define GEM_CHECK_SIZE_OVERFLOW(sz) \
- GEM_WARN_ON((sz) >> PAGE_SHIFT > INT_MAX)
-
static inline bool i915_gem_object_size_2big(u64 size)
{
struct drm_i915_gem_object *obj;
- if (GEM_CHECK_SIZE_OVERFLOW(size))
- return true;
-
if (overflows_type(size, obj->base.size))
return true;
--
2.37.1
[PATCH] dt-bindings: display: synopsys, dw-hdmi: drop ref from reg-io-width
reg-io-width is a standard property, so no need for defining its type with $ref. Signed-off-by: Krzysztof Kozlowski --- .../devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml | 1 - 1 file changed, 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml b/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml index b00246faea57..4b7e54a8f037 100644 --- a/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml @@ -26,7 +26,6 @@ properties: reg-io-width: description: Width (in bytes) of the registers specified by the reg property. -$ref: /schemas/types.yaml#/definitions/uint32 enum: [1, 4] default: 1 -- 2.34.1
Re: [PATCH 1/3] dt-bindings: mediatek: Add gamma compatible for mt8195
On 22/08/2022 12:19, zheng-yan.chen wrote: > mt8195 uses 10bit-to-12bit gamma-LUT, which is different from > current 9bit-to-10bit gamma-LUT, so this patch add its own compatible > for mt8195. I am not sure if this explains the need for change. Is mt8195 still compatible with mt8183 or not? Your driver change suggests that it is and points that this commit is wrong. > > Signed-off-by: zheng-yan.chen > > --- > .../devicetree/bindings/display/mediatek/mediatek,gamma.yaml | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git > a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml > b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml > index a89ea0ea7542..fbd7b9664a78 100644 > --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml > @@ -25,11 +25,12 @@ properties: >- const: mediatek,mt8173-disp-gamma >- items: >- const: mediatek,mt8183-disp-gamma > + - items: > + - const: mediatek,mt8195-disp-gamma >- items: >- enum: >- mediatek,mt8186-disp-gamma >- mediatek,mt8192-disp-gamma > - - mediatek,mt8195-disp-gamma Best regards, Krzysztof
RE: [PATCH v1 2/4] drm/hyperv: Don't forget to put PCI device when removing conflicting FB fails
"Michael Kelley (LINUX)" writes:
> From: Vitaly Kuznetsov Sent: Thursday, August 18, 2022
> 7:25 AM
>>
>> When drm_aperture_remove_conflicting_pci_framebuffers() fails, 'pdev'
>> needs to be released with pci_dev_put().
>>
>> Fixes: 76c56a5affeb ("drm/hyperv: Add DRM driver for hyperv synthetic video
>> device")
>> Signed-off-by: Vitaly Kuznetsov
>> ---
>> drivers/gpu/drm/hyperv/hyperv_drm_drv.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
>> b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
>> index 46f6c454b820..ca4e517b95ca 100644
>> --- a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
>> +++ b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
>> @@ -82,7 +82,7 @@ static int hyperv_setup_gen1(struct hyperv_drm_device *hv)
>> ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev,
>> _driver);
>> if (ret) {
>> drm_err(dev, "Not able to remove boot fb\n");
>> -return ret;
>> +goto error;
>> }
>>
>> if (pci_request_region(pdev, 0, DRIVER_NAME) != 0)
>> --
>> 2.37.1
>
> This patch appears to be obsoleted by commit a0ab5abced55
> that was merged into 6.0-rc1. Of course, it does beg the question of
> why the original function hyperv_setup_gen2(), which is now renamed
> to hyperv_setup_vram(), doesn't check the return value from
> drm_aperture_remove_conflicting_framebuffers().
AFAICT this commit (which I've obviously missed) also solves the worst
issue I'm trying to address with this series: conflict between
framebuffer and SR-IOV VF config space. It would probably still make
sense to reserve the whole FB region on Gen1 first thing and use it
as-is for DRM/FB later (Patches 3-4).
--
Vitaly
[PATCH] drm/amd: fix potential memory leak
This patch fix potential memory leak (clk_src) when function run into last return NULL. Signed-off-by: Bernard Zhao --- drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c index 85f32206a766..76f263846c6b 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c +++ b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c @@ -1715,6 +1715,7 @@ static struct clock_source *dcn30_clock_source_create( } BREAK_TO_DEBUGGER(); + free(clk_src); return NULL; } -- 2.33.1
[PATCH] drm/amd: remove possible condition with no effect (if == else)
This patch fix cocci warning: drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c:1816:6-8: WARNING: possible condition with no effect (if == else). Signed-off-by: Bernard Zhao --- drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c index 85f32206a766..dccc9794e6a2 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c +++ b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c @@ -1813,8 +1813,6 @@ static bool dcn314_resource_construct( if (dc->ctx->dce_environment == DCE_ENV_PRODUCTION_DRV) dc->debug = debug_defaults_drv; - else if (dc->ctx->dce_environment == DCE_ENV_FPGA_MAXIMUS) - dc->debug = debug_defaults_diags; else dc->debug = debug_defaults_diags; // Init the vm_helper -- 2.33.1
Re: [PATCH v2 3/4] drm: rcar-du: fix DSI enable & disable sequence
Hi Tomi, I love your patch! Perhaps something to improve: [auto build test WARNING on pinchartl-media/drm/du/next] [also build test WARNING on linus/master] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Tomi-Valkeinen/drm-rcar-du-DSI-fixes/20220822-210756 base: git://linuxtv.org/pinchartl/media.git drm/du/next config: riscv-randconfig-r042-20220821 (https://download.01.org/0day-ci/archive/20220823/202208231031.hfwndaul-...@intel.com/config) compiler: clang version 16.0.0 (https://github.com/llvm/llvm-project abce7acebd4c06c977bc4bd79170697f1122bc5e) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install riscv cross compiling tool for clang build # apt-get install binutils-riscv64-linux-gnu # https://github.com/intel-lab-lkp/linux/commit/d037472981c443d699c022aa91c5335f686d82ad git remote add linux-review https://github.com/intel-lab-lkp/linux git fetch --no-tags linux-review Tomi-Valkeinen/drm-rcar-du-DSI-fixes/20220822-210756 git checkout d037472981c443d699c022aa91c5335f686d82ad # save the config file mkdir build_dir && cp config build_dir/.config COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=riscv SHELL=/bin/bash drivers/gpu/drm/rcar-du/ If you fix the issue, kindly add following tag where applicable Reported-by: kernel test robot All warnings (new ones prefixed by >>): In file included from drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c:10: In file included from include/linux/io.h:13: In file included from arch/riscv/include/asm/io.h:136: include/asm-generic/io.h:464:31: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] val = __raw_readb(PCI_IOBASE + addr); ~~ ^ include/asm-generic/io.h:477:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] val = __le16_to_cpu((__le16 __force)__raw_readw(PCI_IOBASE + addr)); ~~ ^ include/uapi/linux/byteorder/little_endian.h:36:51: note: expanded from macro '__le16_to_cpu' #define __le16_to_cpu(x) ((__force __u16)(__le16)(x)) ^ In file included from drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c:10: In file included from include/linux/io.h:13: In file included from arch/riscv/include/asm/io.h:136: include/asm-generic/io.h:490:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + addr)); ~~ ^ include/uapi/linux/byteorder/little_endian.h:34:51: note: expanded from macro '__le32_to_cpu' #define __le32_to_cpu(x) ((__force __u32)(__le32)(x)) ^ In file included from drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c:10: In file included from include/linux/io.h:13: In file included from arch/riscv/include/asm/io.h:136: include/asm-generic/io.h:501:33: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] __raw_writeb(value, PCI_IOBASE + addr); ~~ ^ include/asm-generic/io.h:511:59: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] __raw_writew((u16 __force)cpu_to_le16(value), PCI_IOBASE + addr); ~~ ^ include/asm-generic/io.h:521:59: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] __raw_writel((u32 __force)cpu_to_le32(value), PCI_IOBASE + addr); ~~ ^ include/asm-generic/io.h:1024:55: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] return (port > MMIO_UPPER_LIMIT) ? NULL : PCI_IOBASE + port; ~~ ^ >> drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c:615:6: warning: no previous >> prototype for function 'rcar_mipi_dsi_pclk_enable' [-Wmissing-prototypes] void rcar_mipi_dsi_pclk_enable(struct drm_bridge *bridge, ^ drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c:615:1: note: declare 'static' if the function is not intended to be used outside of this
[PATCH] Revert "drm: bridge: analogix/dp: add panel prepare/unprepare in suspend/resume time"
This reverts commit 211f276ed3d96e964d2d1106a198c7f4a4b3f4c0.
For quite some time, core DRM helpers already ensure that any relevant
connectors/CRTCs/etc. are disabled, as well as their associated
components (e.g., bridges) when suspending the system. Thus,
analogix_dp_bridge_{enable,disable}() already get called, which in turn
call drm_panel_{prepare,unprepare}(). This makes these drm_panel_*()
calls redundant.
Besides redundancy, there are a few problems with this handling:
(1) drm_panel_{prepare,unprepare}() are *not* reference-counted APIs and
are not in general designed to be handled by multiple callers --
although some panel drivers have a coarse 'prepared' flag that mitigates
some damage, at least. So at a minimum this is redundant and confusing,
but in some cases, this could be actively harmful.
(2) The error-handling is a bit non-standard. We ignored errors in
suspend(), but handled errors in resume(). And recently, people noticed
that the clk handling is unbalanced in error paths, and getting *that*
right is not actually trivial, given the current way errors are mostly
ignored.
(3) In the particular way analogix_dp_{suspend,resume}() get used (e.g.,
in rockchip_dp_*(), as a late/early callback), we don't necessarily have
a proper PM relationship between the DP/bridge device and the panel
device. So while the DP bridge gets resumed, the panel's parent device
(e.g., platform_device) may still be suspended, and so any prepare()
calls may fail.
So remove the superfluous, possibly-harmful suspend()/resume() handling
of panel state.
Fixes: 211f276ed3d9 ("drm: bridge: analogix/dp: add panel prepare/unprepare in
suspend/resume time")
Link: https://lore.kernel.org/all/yv2cpbd3picg%2f...@google.com/
Signed-off-by: Brian Norris
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 8aadcc0aa90b..df9370e0ff23 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1864,12 +1864,6 @@ EXPORT_SYMBOL_GPL(analogix_dp_remove);
int analogix_dp_suspend(struct analogix_dp_device *dp)
{
clk_disable_unprepare(dp->clock);
-
- if (dp->plat_data->panel) {
- if (drm_panel_unprepare(dp->plat_data->panel))
- DRM_ERROR("failed to turnoff the panel\n");
- }
-
return 0;
}
EXPORT_SYMBOL_GPL(analogix_dp_suspend);
@@ -1884,13 +1878,6 @@ int analogix_dp_resume(struct analogix_dp_device *dp)
return ret;
}
- if (dp->plat_data->panel) {
- if (drm_panel_prepare(dp->plat_data->panel)) {
- DRM_ERROR("failed to setup the panel\n");
- return -EBUSY;
- }
- }
-
return 0;
}
EXPORT_SYMBOL_GPL(analogix_dp_resume);
--
2.37.2.609.g9ff673ca1a-goog
Re: [PATCH 3/7] drm/msm/dp: Add DP and EDP compatibles for SC8280XP
On 10/08/2022 06:50, Bjorn Andersson wrote: The SC8280XP platform has four DisplayPort controllers, per MDSS instance, all with widebus support. The first two are defined to be DisplayPort only, while the latter pair (of each instance) can be either DisplayPort or Embedded DisplayPort. The two sets are tied to the possible compatibels. Signed-off-by: Bjorn Andersson Reviewed-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/dp/dp_display.c | 22 ++ drivers/gpu/drm/msm/msm_drv.h | 1 + 2 files changed, 23 insertions(+)-- With best wishes Dmitry
Re: [PATCH] drm/msm/dpu: Fix comment typo
On 24/07/2022 23:42, Jason Wang wrote:
The double `be' is duplicated in the comment, remove one.
Signed-off-by: Jason Wang
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 71fe4c505f5b..38aa38ab1568 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -76,7 +76,7 @@ enum {
/**
* MDP TOP BLOCK features
- * @DPU_MDP_PANIC_PER_PIPE Panic configuration needs to be be done per pipe
+ * @DPU_MDP_PANIC_PER_PIPE Panic configuration needs to be done per pipe
* @DPU_MDP_10BIT_SUPPORT, Chipset supports 10 bit pixel formats
* @DPU_MDP_BWC, MDSS HW supports Bandwidth compression.
* @DPU_MDP_UBWC_1_0, This chipsets supports Universal Bandwidth
--
With best wishes
Dmitry
Re: [PATCH] drm/bridge: ps8640: Add double reset T4 and T5 to power-on sequence
Hi, On Thu, Aug 18, 2022 at 8:03 AM Doug Anderson wrote: > > Hi, > > On Wed, Aug 17, 2022 at 8:22 PM Hsin-Yi Wang wrote: > > > > On Thu, Aug 18, 2022 at 11:19 AM Rock Chiu > > wrote: > > > > > > How does T4/T5 impact the real case? We talked previously the T4/T5 > > > shouldn't cause user impact. > > > Do we have testing data from ODM? > > > > > Please leave comments below the previous comment's headline. > > > > I'm confused. The reason I upstreamed this patch is because this is in > > your application note and you asked us to help upstream it. Now do you > > mean that we don't need T4 and T5? > > I think Rock is asking what problems the extra delay is causing. In > other words: why do we care about keeping these delays short? > > The answer is that it affects boot speed and also resume speed of > devices. Adding these two delays here means that there's an extra 100 > ms before the user can see something on the screen. That may not seem > like a lot, but those kinds of delays add up quickly. At least on > Chromebooks, booting quickly is always a big goal. While I'm not very happy with this change and I don't really understand why these delays need to be so long, if folks are really certain that we need them and can't make them shorter then I guess we can land it. I'll wait a few more days in case anyone wants to chime in with their thoughts. -Doug
[PATCH v3 4/5] drm: rcar-du: fix DSI enable & disable sequence
From: Tomi Valkeinen
The rcar crtc depends on the clock provided from the rcar DSI bridge.
When the DSI bridge is disabled, the clock is stopped, which causes the
crtc disable to timeout.
Also, while I have no issue with the enable, the documentation suggests
to enable the DSI before the crtc so that the crtc has its clock enabled
at enable time. This is also not done by the current driver.
To fix this, we need to keep the DSI bridge enabled until the crtc has
disabled itself, and enable the DSI bridge before crtc enables itself.
Add functions rcar_mipi_dsi_pclk_enable and rcar_mipi_dsi_pclk_disable
to the rcar DSI bridge driver which the rcar driver can use to
enable/disable the DSI clock when needed. This is similar to what is
already done with the rcar LVDS bridge.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 26 +++
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 2 ++
drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 4 +++
drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 25 +-
drivers/gpu/drm/rcar-du/rcar_mipi_dsi.h | 31 +++
5 files changed, 82 insertions(+), 6 deletions(-)
create mode 100644 drivers/gpu/drm/rcar-du/rcar_mipi_dsi.h
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index d38092d85df7..3619e1ddeb62 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -29,6 +29,7 @@
#include "rcar_du_regs.h"
#include "rcar_du_vsp.h"
#include "rcar_lvds.h"
+#include "rcar_mipi_dsi.h"
static u32 rcar_du_crtc_read(struct rcar_du_crtc *rcrtc, u32 reg)
{
@@ -747,6 +748,18 @@ static void rcar_du_crtc_atomic_enable(struct drm_crtc
*crtc,
rcar_lvds_pclk_enable(bridge, mode->clock * 1000);
}
+ /*
+* Similarly to LVDS, on V3U the dot clock is provided by the DSI
+* encoder, and we need to enable the DSI clocks before enabling the
CRTC.
+*/
+ if ((rcdu->info->dsi_clk_mask & BIT(rcrtc->index)) &&
+ (rstate->outputs &
+(BIT(RCAR_DU_OUTPUT_DSI0) | BIT(RCAR_DU_OUTPUT_DSI1 {
+ struct drm_bridge *bridge = rcdu->dsi[rcrtc->index];
+
+ rcar_mipi_dsi_pclk_enable(bridge, state);
+ }
+
rcar_du_crtc_start(rcrtc);
/*
@@ -780,6 +793,19 @@ static void rcar_du_crtc_atomic_disable(struct drm_crtc
*crtc,
rcar_lvds_pclk_disable(bridge);
}
+ if ((rcdu->info->dsi_clk_mask & BIT(rcrtc->index)) &&
+ (rstate->outputs &
+(BIT(RCAR_DU_OUTPUT_DSI0) | BIT(RCAR_DU_OUTPUT_DSI1 {
+ struct drm_bridge *bridge = rcdu->dsi[rcrtc->index];
+
+ /*
+* Disable the DSI clock output, see
+* rcar_du_crtc_atomic_enable().
+*/
+
+ rcar_mipi_dsi_pclk_disable(bridge);
+ }
+
spin_lock_irq(>dev->event_lock);
if (crtc->state->event) {
drm_crtc_send_vblank_event(crtc, crtc->state->event);
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index bfad7775d9a1..9367c2f59431 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -91,6 +91,7 @@ struct rcar_du_device_info {
#define RCAR_DU_MAX_GROUPS DIV_ROUND_UP(RCAR_DU_MAX_CRTCS, 2)
#define RCAR_DU_MAX_VSPS 4
#define RCAR_DU_MAX_LVDS 2
+#define RCAR_DU_MAX_DSI2
struct rcar_du_device {
struct device *dev;
@@ -107,6 +108,7 @@ struct rcar_du_device {
struct platform_device *cmms[RCAR_DU_MAX_CRTCS];
struct rcar_du_vsp vsps[RCAR_DU_MAX_VSPS];
struct drm_bridge *lvds[RCAR_DU_MAX_LVDS];
+ struct drm_bridge *dsi[RCAR_DU_MAX_DSI];
struct {
struct drm_property *colorkey;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
index 60d6be78323b..ac93e08e8af4 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
@@ -84,6 +84,10 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
if (output == RCAR_DU_OUTPUT_LVDS0 ||
output == RCAR_DU_OUTPUT_LVDS1)
rcdu->lvds[output - RCAR_DU_OUTPUT_LVDS0] = bridge;
+
+ if (output == RCAR_DU_OUTPUT_DSI0 ||
+ output == RCAR_DU_OUTPUT_DSI1)
+ rcdu->dsi[output - RCAR_DU_OUTPUT_DSI0] = bridge;
}
/*
diff --git a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
index 9c79fe2fc70b..06250f2f3499 100644
--- a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
+++ b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
@@ -598,7 +598,22 @@ static int rcar_mipi_dsi_attach(struct drm_bridge *bridge,
static void
Re: vm binding interfaces and parallel with mmap
Am 22.08.22 um 10:34 schrieb Bas Nieuwenhuizen: On Mon, Aug 22, 2022 at 9:28 AM Dave Airlie wrote: On Mon, 22 Aug 2022 at 17:05, Dave Airlie wrote: Hey, I've just been looking at the vm bind type interfaces and wanted to at least document how we think the unmapping API should work. I know I've talked on irc before about this, but wanted to solidify things a bit more around what is required vs what is a nice to have. My main concerns/thoughts are around the unbind interfaces and how close to munmap they should be. I think the mapping operation is mostly consistent MAP(bo handle, offset into bo, range, VM offset, VM flags) which puts the range inside to bo at the offset in the current VM (maybe take an optional vm_id). now the simplest unmap I can see if one that parallel munmap UNMAP(vmaddr, range); But it begs the question on then how much the kernel needs to deal with here, if we support random vmaddr,range then we really need to be able to do everything munmap does for CPU VMA, which means splitting ranges, joining ranges etc. like MAP(1, 0, 0x8000, 0xc) UNMAP(0xc1000, 0x1000) should that be possible? Do we have any API usage (across Vulkan/CL/CUDA/ROCm etc) that requires this sort of control, or should we be fine with only unmapping objects exactly like how they were mapped in the first place, and not have any splitting/joining? Vulkan allows for this, though I haven't checked to what extent apps use it. This is massively used for partial resident textures under OpenGL as far as I know. E.g. you map a range like 1->10 as PRT and then then map real textures at 2, 5 and 7 or something like that. Saying that a functionality to map/enable PRT for a range is necessary as well. On amdgpu we have a special flag for that and in this case the BO to map can be NULL. We could technically split all mapping/unmapping to be per single tile in the userspace driver, which avoids the need for splitting/merging, but that could very much be a pessimization. That would be pretty much a NAK from my side. A couple of hardware optimizations require mappings to be as large as possible. Otherwise we wouldn't be able to use huge/giant (2MiB, 1GiB) pages, power of two TLB reach optimizations (8KiB, 16KiB, 32KiB.) as well as texture fetcher optimizations. I suppose it also asks the question around paralleling fd = open() ptr = mmap(fd,) close(fd) the mapping is still valid. I suppose our equiv is handle = bo_alloc() gpu_addr = vm_bind(handle,) gem_close(handle) is the gpu_addr still valid does the VM hold a reference on the kernel bo internally. For Vulkan it looks like this is undefined and the above is not necessary: "It is important to note that freeing a VkDeviceMemory object with vkFreeMemory will not cause resources (or resource regions) bound to the memory object to become unbound. Applications must not access resources bound to memory that has been freed." (32.7.6) Additional to what was discussed here so far we need an array on in and out drm_syncobj for both map as well as unmap. E.g. when the mapping/unmapping should happen and when it is completed etc... Christian. Dave. Dave.
Re: [PATCH v5 3/4] drm/lcdif: Clean up debug prints and comments
Hello Marek,
Am Freitag, 19. August 2022, 16:08:51 CEST schrieb Marek Vasut:
> Update debug print to report bridge timings over connector ones.
> Drop missed comment commit from mxsfb.
>
> Acked-by: Sam Ravnborg
> Reviewed-by: Liu Ying
> Reported-by: Liu Ying
> Tested-by: Martyn Welch
> Fixes: 9db35bb349a0e ("drm: lcdif: Add support for i.MX8MP LCDIF variant")
> Signed-off-by: Marek Vasut
> Cc: Alexander Stein
> Cc: Laurent Pinchart
> Cc: Liu Ying
> Cc: Lucas Stach
> Cc: Marek Vasut
> Cc: Martyn Welch
> Cc: Peng Fan
> Cc: Robby Cai
> Cc: Sam Ravnborg
> Cc: Stefan Agner
> ---
> V2: Add RB from Liu
> V3: Add TB from Martyn from V1
> V4: Add AB from Sam from V2
> V5: Rebase on current drm-misc-next
> ---
> drivers/gpu/drm/mxsfb/lcdif_kms.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> b/drivers/gpu/drm/mxsfb/lcdif_kms.c index db7a90e5497c6..b1092aab14231
> 100644
> --- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> +++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
> @@ -203,7 +203,7 @@ static void lcdif_crtc_mode_set_nofb(struct
> lcdif_drm_private *lcdif, DRM_DEV_DEBUG_DRIVER(drm->dev, "Pixel clock:
> %dkHz (actual: %dkHz)\n", m->crtc_clock,
>(int)(clk_get_rate(lcdif->clk) / 1000));
> - DRM_DEV_DEBUG_DRIVER(drm->dev, "Connector bus_flags: 0x%08X\n",
> + DRM_DEV_DEBUG_DRIVER(drm->dev, "Bridge bus_flags: 0x%08X\n",
>bus_flags);
> DRM_DEV_DEBUG_DRIVER(drm->dev, "Mode flags: 0x%08X\n", m->flags);
Is there any benefit to explicitly state it is the bridge input flags?
Anyway:
Reviewed-by: Alexander Stein
Re: Rust in our code base
On Sun, Aug 21, 2022 at 7:43 PM Karol Herbst wrote: > > On Sun, Aug 21, 2022 at 5:46 PM Rob Clark wrote: > > > > On Sat, Aug 20, 2022 at 5:23 AM Karol Herbst wrote: > > > > > > Hey everybody, > > > > > > so I think it's time to have this discussion for real. > > > > > > I am working on Rusticl > > > (https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15439) > > > which I would like to merge quite soon. > > > > > > Others might also plan on starting kernel drivers written in Rust (and > > > if people feel comfortable to discuss this as well, they might reply > > > here) > > > > > > The overall implication of that is: if we are doing this, people (that > > > is we) have to accept that touching Rust code will be part of our > > > development process. There is no other sane way of doing it. > > > > > > I am not willing to wrap things in Rusticl so changing gallium APIs > > > won't involve touching Rust code, and we also can't expect people to > > > design their kernel drivers in weird ways "just because somebody > > > doesn't want to deal with Rust" > > > > > > If we are going to do this, we have to do it for real, which means, > > > Rust code will call C APIs directly and a change in those APIs will > > > also require changes in Rust code making use of those APIs. > > > > > > I am so explicit on this very point, because we had some discussion on > > > IRC where this was seen as a no-go at least from some people, which > > > makes me think we have to find a mutual agreement on how it should be > > > going forward. > > > > > > And I want to be very explicit here about the future of Rusticl as > > > well: if the agreement is that people don't want to have to deal with > > > Rust changing e.g. gallium, Rusticl is a dead project. I am not > > > willing to come up with some trashy external-internal API just to > > > maintain Rusticl outside of the mesa git repo. > > > And doing it on a kernel level is even more of a no-go. > > > > > > So what are we all thinking about Rust in our core repos? > > > > I think there has to be willingness on the part of rust folks to help > > others who aren't so familiar with rust with these sorts of API > > changes. You can't completely impose the burden on others who have > > never touched rust before. That said, I expect a lot of API changes > > over time are simple enough that other devs could figure out the > > related rust side changes. > > > > yeah, I agree here. I wouldn't say it's all the responsibility of > developers changing APIs to also know how to change the code. So e.g. > if an MR fails to compile and it's because of rusticl, I will help out > and do the changes myself if necessary. But long term we have to > accept that API changes also come with the implication of also having > to touch Rust code. > > Short term it might be a learning opportunity for some/most, but long > term it has to be accepted as a part of development to deal with Rust. > > > As long as folks who want to start introducing rust in mesa and drm > > realize they are also signing up to play the role of rust tutor and > > technical assistance, I don't see a problem. But if they aren't > > around and willing to help, I could see this going badly. > > > > Yep, I fully agree here. This is also the main reason I am bringing > this up. Nobody should be left alone with having to deal with changing > the code. On the other hand a "not having to touch Rust code when > changing APIs" guarantee is something which is simply impossible to > have in any sane architecture. So we should figure out under which > circumstances it will be okay for everybody. > > At least I don't see a way how I can structure Rusticl so that > somebody working on gallium won't have to also deal with rusticl. One > possibility would be to have a libgallium.so file I can link to, but > then it's all about "stable gallium API" vs "not having to touch rust > code" and I hope everybody prefers the second :) > uhm... I meant "stable gallium API" vs "dealing with Rust code on API changes" > > I do also wonder a bit about code tooling (indexers, etc).. I'm not > > sure what the state of things when it comes to cross c<->rust > > integration. Ie. it is usually straightforward enough to track down > > all the spots in C code which would be affected by some change. It > > might be easier to overlook things on the rust side. On the mesa > > side, pre-merge CI jobs help to catch these issues. Less sure about > > how to handle that on the kernel side. > > > > At least for Rusticl it's all within meson/ninja. We use bindgen to > generate the bindings automatically so you simply run into compilation > issues. And for the kernel side I think that Linus wanted Rust to be > non optional. If something uses it, you also make sure the Rust side > compiles. And the build system is dynamic enough that you can also > wire up bindgen and make it part of the normal development model. > > In regards to code tooling, for rust you usually rely
RE: [PATCH] drm/amd/display: fix i386 frame size warning
From: Hamza Mahfooz > Sent: 18 August 2022 17:49 > > Addresses the following warning: > drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn30/display_mode_vba_30.c:3596:6: > error: stack frame > size (2092) exceeds limit (2048) in > 'dml30_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe- > larger-than] > void dml30_ModeSupportAndSystemConfigurationFull(struct display_mode_lib > *mode_lib) > ^ > > UseMinimumDCFCLK() is eating away at > dml30_ModeSupportAndSystemConfigurationFull()'s stack space, so use a > pointer to struct vba_vars_st instead of passing lots of large arrays > as parameters by value. > > Signed-off-by: Hamza Mahfooz > --- > .../dc/dml/dcn30/display_mode_vba_30.c| 295 -- > 1 file changed, 63 insertions(+), 232 deletions(-) > > diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c > b/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c > index 876b321b30ca..b7fa003ffe06 100644 > --- a/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c > +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c > @@ -396,64 +396,10 @@ static void CalculateUrgentBurstFactor( > > static void UseMinimumDCFCLK( > struct display_mode_lib *mode_lib, > - int MaxInterDCNTileRepeaters, > + struct vba_vars_st *v, You should probably add 'const' in there. Thinks will likely break if v->xxx gets changed. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
[PATCH drm-misc-next 7/8] drm/arm/malidp: crtc: protect device resources after removal
(Hardware) resources which are bound to the driver and device lifecycle
must not be accessed after the device and driver are unbound.
However, the DRM device isn't freed as long as the last user didn't
close it, hence userspace can still call into the driver.
Therefore protect the critical sections which are accessing those
resources with drm_dev_enter() and drm_dev_exit().
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/arm/malidp_crtc.c | 41 +--
1 file changed, 39 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_crtc.c
b/drivers/gpu/drm/arm/malidp_crtc.c
index dc01c43f6193..fa95278abae6 100644
--- a/drivers/gpu/drm/arm/malidp_crtc.c
+++ b/drivers/gpu/drm/arm/malidp_crtc.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -27,6 +28,7 @@ static enum drm_mode_status malidp_crtc_mode_valid(struct
drm_crtc *crtc,
{
struct malidp_drm *malidp = crtc_to_malidp_device(crtc);
struct malidp_hw_device *hwdev = malidp->dev;
+ int idx;
/*
* check that the hardware can drive the required clock rate,
@@ -34,6 +36,9 @@ static enum drm_mode_status malidp_crtc_mode_valid(struct
drm_crtc *crtc,
*/
long rate, req_rate = mode->crtc_clock * 1000;
+ if (!drm_dev_enter(>base, ))
+ return MODE_NOCLOCK;
+
if (req_rate) {
rate = clk_round_rate(hwdev->pxlclk, req_rate);
if (rate != req_rate) {
@@ -43,6 +48,8 @@ static enum drm_mode_status malidp_crtc_mode_valid(struct
drm_crtc *crtc,
}
}
+ drm_dev_exit(idx);
+
return MODE_OK;
}
@@ -53,6 +60,10 @@ static void malidp_crtc_atomic_enable(struct drm_crtc *crtc,
struct malidp_hw_device *hwdev = malidp->dev;
struct videomode vm;
int err = pm_runtime_get_sync(crtc->dev->dev);
+ int idx;
+
+ if (!drm_dev_enter(>base, ))
+ return;
if (err < 0) {
DRM_DEBUG_DRIVER("Failed to enable runtime power management:
%d\n", err);
@@ -68,6 +79,8 @@ static void malidp_crtc_atomic_enable(struct drm_crtc *crtc,
hwdev->hw->modeset(hwdev, );
hwdev->hw->leave_config_mode(hwdev);
drm_crtc_vblank_on(crtc);
+
+ drm_dev_exit(idx);
}
static void malidp_crtc_atomic_disable(struct drm_crtc *crtc,
@@ -77,7 +90,10 @@ static void malidp_crtc_atomic_disable(struct drm_crtc *crtc,
crtc);
struct malidp_drm *malidp = crtc_to_malidp_device(crtc);
struct malidp_hw_device *hwdev = malidp->dev;
- int err;
+ int err, idx;
+
+ if (!drm_dev_enter(>base, ))
+ return;
/* always disable planes on the CRTC that is being turned off */
drm_atomic_helper_disable_planes_on_crtc(old_state, false);
@@ -91,6 +107,8 @@ static void malidp_crtc_atomic_disable(struct drm_crtc *crtc,
if (err < 0) {
DRM_DEBUG_DRIVER("Failed to disable runtime power management:
%d\n", err);
}
+
+ drm_dev_exit(idx);
}
static const struct gamma_curve_segment {
@@ -260,7 +278,10 @@ static int malidp_crtc_atomic_check_scaling(struct
drm_crtc *crtc,
u32 h_upscale_factor = 0; /* U16.16 */
u32 v_upscale_factor = 0; /* U16.16 */
u8 scaling = cs->scaled_planes_mask;
- int ret;
+ int idx, ret;
+
+ if (!drm_dev_enter(>base, ))
+ return -ENODEV;
if (!scaling) {
s->scale_enable = false;
@@ -334,6 +355,9 @@ static int malidp_crtc_atomic_check_scaling(struct drm_crtc
*crtc,
ret = hwdev->hw->se_calc_mclk(hwdev, s, );
if (ret < 0)
return -EINVAL;
+
+ drm_dev_exit(idx);
+
return 0;
}
@@ -498,9 +522,16 @@ static int malidp_crtc_enable_vblank(struct drm_crtc *crtc)
{
struct malidp_drm *malidp = crtc_to_malidp_device(crtc);
struct malidp_hw_device *hwdev = malidp->dev;
+ int idx;
+
+ if (!drm_dev_enter(>base, ))
+ return -ENODEV;
malidp_hw_enable_irq(hwdev, MALIDP_DE_BLOCK,
hwdev->hw->map.de_irq_map.vsync_irq);
+
+ drm_dev_exit(idx);
+
return 0;
}
@@ -508,9 +539,15 @@ static void malidp_crtc_disable_vblank(struct drm_crtc
*crtc)
{
struct malidp_drm *malidp = crtc_to_malidp_device(crtc);
struct malidp_hw_device *hwdev = malidp->dev;
+ int idx;
+
+ if (!drm_dev_enter(>base, ))
+ return;
malidp_hw_disable_irq(hwdev, MALIDP_DE_BLOCK,
hwdev->hw->map.de_irq_map.vsync_irq);
+
+ drm_dev_exit(idx);
}
static const struct drm_crtc_funcs malidp_crtc_funcs = {
--
2.37.2
[PATCH drm-misc-next 4/8] drm/arm/malidp: plane: use drm managed resources
Use drm managed resource allocation (drmm_universal_plane_alloc()) in
order to get rid of the explicit destroy hook in struct drm_plane_funcs.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/arm/malidp_planes.c | 28 +++-
1 file changed, 7 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_planes.c
b/drivers/gpu/drm/arm/malidp_planes.c
index 815d9199752f..34547edf1ee3 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -68,14 +68,6 @@
/* readahead for partial-frame prefetch */
#define MALIDP_MMU_PREFETCH_READAHEAD 8
-static void malidp_de_plane_destroy(struct drm_plane *plane)
-{
- struct malidp_plane *mp = to_malidp_plane(plane);
-
- drm_plane_cleanup(plane);
- kfree(mp);
-}
-
/*
* Replicate what the default ->reset hook does: free the state pointer and
* allocate a new empty object. We just need enough space to store
@@ -260,7 +252,6 @@ static bool malidp_format_mod_supported_per_plane(struct
drm_plane *plane,
static const struct drm_plane_funcs malidp_de_plane_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
- .destroy = malidp_de_plane_destroy,
.reset = malidp_plane_reset,
.atomic_duplicate_state = malidp_duplicate_plane_state,
.atomic_destroy_state = malidp_destroy_plane_state,
@@ -972,12 +963,6 @@ int malidp_de_planes_init(struct drm_device *drm)
for (i = 0; i < map->n_layers; i++) {
u8 id = map->layers[i].id;
- plane = kzalloc(sizeof(*plane), GFP_KERNEL);
- if (!plane) {
- ret = -ENOMEM;
- goto cleanup;
- }
-
/* build the list of DRM supported formats based on the map */
for (n = 0, j = 0; j < map->n_pixel_formats; j++) {
if ((map->pixel_formats[j].layer & id) == id)
@@ -990,13 +975,14 @@ int malidp_de_planes_init(struct drm_device *drm)
/*
* All the layers except smart layer supports AFBC modifiers.
*/
- ret = drm_universal_plane_init(drm, >base, crtcs,
- _de_plane_funcs, formats, n,
- (id == DE_SMART) ? linear_only_modifiers :
modifiers,
- plane_type, NULL);
-
- if (ret < 0)
+ plane = drmm_universal_plane_alloc(drm, struct malidp_plane,
base,
+ crtcs,
_de_plane_funcs, formats, n,
+ (id == DE_SMART) ?
linear_only_modifiers :
+ modifiers, plane_type, NULL);
+ if (IS_ERR(plane)) {
+ ret = PTR_ERR(plane);
goto cleanup;
+ }
drm_plane_helper_add(>base,
_de_plane_helper_funcs);
--
2.37.2
Re: [PATCH 2/2] [WIP]: media: Add Synaptics compressed tiled format
Le vendredi 19 août 2022 à 23:44 +0800, Hsia-Jun Li a écrit :
>
> On 8/19/22 23:28, Nicolas Dufresne wrote:
> > CAUTION: Email originated externally, do not click links or open
> > attachments unless you recognize the sender and know the content is safe.
> >
> >
> > Le vendredi 19 août 2022 à 02:13 +0300, Laurent Pinchart a écrit :
> > > On Thu, Aug 18, 2022 at 02:33:42PM +0800, Hsia-Jun Li wrote:
> > > > On 8/18/22 14:06, Tomasz Figa wrote:
> > > > > On Tue, Aug 9, 2022 at 1:28 AM Hsia-Jun Li
> > > > > wrote:
> > > > > >
> > > > > > From: "Hsia-Jun(Randy) Li"
> > > > > >
> > > > > > The most of detail has been written in the drm.
> > >
> > > This patch still needs a description of the format, which should go to
> > > Documentation/userspace-api/media/v4l/.
> > >
> > > > > > Please notice that the tiled formats here request
> > > > > > one more plane for storing the motion vector metadata.
> > > > > > This buffer won't be compressed, so you can't append
> > > > > > it to luma or chroma plane.
> > > > >
> > > > > Does the motion vector buffer need to be exposed to userspace? Is the
> > > > > decoder stateless (requires userspace to specify the reference frames)
> > > > > or stateful (manages the entire decoding process internally)?
> > > >
> > > > No, users don't need to access them at all. Just they need a different
> > > > dma-heap.
> > > >
> > > > You would only get the stateful version of both encoder and decoder.
> > >
> > > Shouldn't the motion vectors be stored in a separate V4L2 buffer,
> > > submitted through a different queue then ?
> >
> > Imho, I believe these should be invisible to users and pooled separately to
> > reduce the overhead. The number of reference is usually lower then the
> > number of
> > allocated display buffers.
> >
> You can't. The motion vector buffer can't share with the luma and chroma
> data planes, nor the data plane for the compression meta data.
>
> You could consider this as a security requirement(the memory region for
> the MV could only be accessed by the decoder) or hardware limitation.
>
> It is also not very easy to manage such a large buffer that would change
> when the resolution changed.
Your argument are just aiming toward the fact that you should not let the user
allocate these in the first place. They should not be bound to the v4l2 buffer.
Allocate these in your driver, and leave to your user the pixel buffer (and
compress meta) allocation work.
Other driver handle this just fine, if your v4l2 driver implement the v4l2
resolution change mechanism, is should be very simple to manage.
> > >
> > > > > > Signed-off-by: Hsia-Jun(Randy) Li
> > > > > > ---
> > > > > >drivers/media/v4l2-core/v4l2-common.c | 1 +
> > > > > >drivers/media/v4l2-core/v4l2-ioctl.c | 2 ++
> > > > > >include/uapi/linux/videodev2.h| 2 ++
> > > > > >3 files changed, 5 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/media/v4l2-core/v4l2-common.c
> > > > > > b/drivers/media/v4l2-core/v4l2-common.c
> > > > > > index e0fbe6ba4b6c..f645278b3055 100644
> > > > > > --- a/drivers/media/v4l2-core/v4l2-common.c
> > > > > > +++ b/drivers/media/v4l2-core/v4l2-common.c
> > > > > > @@ -314,6 +314,7 @@ const struct v4l2_format_info
> > > > > > *v4l2_format_info(u32 format)
> > > > > > { .format = V4L2_PIX_FMT_SGBRG12,
> > > > > > .pixel_enc = V4L2_PIXEL_ENC_BAYER, .mem_planes = 1, .comp_planes =
> > > > > > 1, .bpp = { 2, 0, 0, 0 }, .hdiv = 1, .vdiv = 1 },
> > > > > > { .format = V4L2_PIX_FMT_SGRBG12,
> > > > > > .pixel_enc = V4L2_PIXEL_ENC_BAYER, .mem_planes = 1, .comp_planes =
> > > > > > 1, .bpp = { 2, 0, 0, 0 }, .hdiv = 1, .vdiv = 1 },
> > > > > > { .format = V4L2_PIX_FMT_SRGGB12,
> > > > > > .pixel_enc = V4L2_PIXEL_ENC_BAYER, .mem_planes = 1, .comp_planes =
> > > > > > 1, .bpp = { 2, 0, 0, 0 }, .hdiv = 1, .vdiv = 1 },
> > > > > > + { .format = V4L2_PIX_FMT_NV12M_V4H1C, .pixel_enc =
> > > > > > V4L2_PIXEL_ENC_YUV, .mem_planes = 5, .comp_planes = 2, .bpp = { 1,
> > > > > > 2, 0, 0 }, .hdiv = 2, .vdiv = 2, .block_w = { 128, 128 }, .block_h
> > > > > > = { 128, 128 } },
> > > > > > };
> > > > > > unsigned int i;
> > > > > >
> > > > > > diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
> > > > > > b/drivers/media/v4l2-core/v4l2-ioctl.c
> > > > > > index e6fd355a2e92..8f65964aff08 100644
> > > > > > --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> > > > > > +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> > > > > > @@ -1497,6 +1497,8 @@ static void v4l_fill_fmtdesc(struct
> > > > > > v4l2_fmtdesc *fmt)
> > > > > > case V4L2_PIX_FMT_MT21C:descr = "Mediatek
> > > > > > Compressed Format"; break;
> > > > > > case V4L2_PIX_FMT_QC08C:descr = "QCOM
> > > > > > Compressed 8-bit Format"; break;
> > > > > > case V4L2_PIX_FMT_QC10C:descr = "QCOM
> > > > > >
Re: [PATCH 2/2] [WIP]: media: Add Synaptics compressed tiled format
Le jeudi 18 août 2022 à 14:33 +0800, Hsia-Jun Li a écrit :
>
> On 8/18/22 14:06, Tomasz Figa wrote:
> > CAUTION: Email originated externally, do not click links or open
> > attachments unless you recognize the sender and know the content is safe.
> >
> >
> > Hi Randy,
> >
> > On Tue, Aug 9, 2022 at 1:28 AM Hsia-Jun Li wrote:
> > >
> > > From: "Hsia-Jun(Randy) Li"
> > >
> > > The most of detail has been written in the drm.
> > > Please notice that the tiled formats here request
> > > one more plane for storing the motion vector metadata.
> > > This buffer won't be compressed, so you can't append
> > > it to luma or chroma plane.
> >
> > Does the motion vector buffer need to be exposed to userspace? Is the
> > decoder stateless (requires userspace to specify the reference frames)
> > or stateful (manages the entire decoding process internally)?
> >
> No, users don't need to access them at all. Just they need a different
> dma-heap.
>
> You would only get the stateful version of both encoder and decoder.
Can't you just allocate and manage these internally in the kernel driver without
adding kernel APIs ? This is notably what Mediatek and (downstream) RPi HEVC
driver do, as it allow reducing quite a lot the memory usage. In Hantro, we bind
them due to HW limitation.
Nicolas
> > Best regards,
> > Tomasz
> >
> > >
> > > Signed-off-by: Hsia-Jun(Randy) Li
> > > ---
> > > drivers/media/v4l2-core/v4l2-common.c | 1 +
> > > drivers/media/v4l2-core/v4l2-ioctl.c | 2 ++
> > > include/uapi/linux/videodev2.h| 2 ++
> > > 3 files changed, 5 insertions(+)
> > >
> > > diff --git a/drivers/media/v4l2-core/v4l2-common.c
> > > b/drivers/media/v4l2-core/v4l2-common.c
> > > index e0fbe6ba4b6c..f645278b3055 100644
> > > --- a/drivers/media/v4l2-core/v4l2-common.c
> > > +++ b/drivers/media/v4l2-core/v4l2-common.c
> > > @@ -314,6 +314,7 @@ const struct v4l2_format_info *v4l2_format_info(u32
> > > format)
> > > { .format = V4L2_PIX_FMT_SGBRG12, .pixel_enc =
> > > V4L2_PIXEL_ENC_BAYER, .mem_planes = 1, .comp_planes = 1, .bpp = { 2, 0,
> > > 0, 0 }, .hdiv = 1, .vdiv = 1 },
> > > { .format = V4L2_PIX_FMT_SGRBG12, .pixel_enc =
> > > V4L2_PIXEL_ENC_BAYER, .mem_planes = 1, .comp_planes = 1, .bpp = { 2, 0,
> > > 0, 0 }, .hdiv = 1, .vdiv = 1 },
> > > { .format = V4L2_PIX_FMT_SRGGB12, .pixel_enc =
> > > V4L2_PIXEL_ENC_BAYER, .mem_planes = 1, .comp_planes = 1, .bpp = { 2, 0,
> > > 0, 0 }, .hdiv = 1, .vdiv = 1 },
> > > + { .format = V4L2_PIX_FMT_NV12M_V4H1C, .pixel_enc =
> > > V4L2_PIXEL_ENC_YUV, .mem_planes = 5, .comp_planes = 2, .bpp = { 1, 2, 0,
> > > 0 }, .hdiv = 2, .vdiv = 2, .block_w = { 128, 128 }, .block_h = { 128, 128
> > > } },
> > > };
> > > unsigned int i;
> > >
> > > diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
> > > b/drivers/media/v4l2-core/v4l2-ioctl.c
> > > index e6fd355a2e92..8f65964aff08 100644
> > > --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> > > +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> > > @@ -1497,6 +1497,8 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc
> > > *fmt)
> > > case V4L2_PIX_FMT_MT21C:descr = "Mediatek
> > > Compressed Format"; break;
> > > case V4L2_PIX_FMT_QC08C:descr = "QCOM Compressed
> > > 8-bit Format"; break;
> > > case V4L2_PIX_FMT_QC10C:descr = "QCOM Compressed
> > > 10-bit Format"; break;
> > > + case V4L2_PIX_FMT_NV12M_V4H1C: descr = "Synaptics
> > > Compressed 8-bit tiled Format";break;
> > > + case V4L2_PIX_FMT_NV12M_10_V4H3P8C: descr =
> > > "Synaptics Compressed 10-bit tiled Format";break;
> > > default:
> > > if (fmt->description[0])
> > > return;
> > > diff --git a/include/uapi/linux/videodev2.h
> > > b/include/uapi/linux/videodev2.h
> > > index 01e630f2ec78..7e928cb69e7c 100644
> > > --- a/include/uapi/linux/videodev2.h
> > > +++ b/include/uapi/linux/videodev2.h
> > > @@ -661,6 +661,8 @@ struct v4l2_pix_format {
> > > #define V4L2_PIX_FMT_NV12MT_16X16 v4l2_fourcc('V', 'M', '1', '2') /* 12
> > > Y/CbCr 4:2:0 16x16 tiles */
> > > #define V4L2_PIX_FMT_NV12M_8L128 v4l2_fourcc('N', 'A', '1', '2')
> > > /* Y/CbCr 4:2:0 8x128 tiles */
> > > #define V4L2_PIX_FMT_NV12M_10BE_8L128 v4l2_fourcc_be('N', 'T', '1',
> > > '2') /* Y/CbCr 4:2:0 10-bit 8x128 tiles */
> > > +#define V4L2_PIX_FMT_NV12M_V4H1C v4l2_fourcc('S', 'Y', '1', '2') /* 12
> > > Y/CbCr 4:2:0 tiles */
> > > +#define V4L2_PIX_FMT_NV12M_10_V4H3P8C v4l2_fourcc('S', 'Y', '1', '0')
> > > /* 12 Y/CbCr 4:2:0 10-bits tiles */
> > >
> > > /* Bayer formats - see
> > >
Re: [PATCH] drm/mediatek: dsi: Add atomic {destroy, duplicate}_state, reset callbacks
On Fri, Jul 22, 2022 at 1:27 AM AngeloGioacchino Del Regno
wrote:
>
> Add callbacks for atomic_destroy_state, atomic_duplicate_state and
> atomic_reset to restore functionality of the DSI driver: this solves
> vblank timeouts when another bridge is present in the chain.
>
> Tested bridge chain: DSI <=> ANX7625 => aux-bus panel
>
> Fixes: 7f6335c6a258 ("drm/mediatek: Modify dsi funcs to atomic operations")
> Signed-off-by: AngeloGioacchino Del Regno
>
This patch is now needed on top of v6.0-rc1, otherwise booting will
stall for a while waiting for display vblank, which never happens
because the DSI pipeline is not configured correctly.
ChenYu
> ---
>
> Note: The commit that has been mentioned in the Fixes tag should
> *not* have my Reviewed-by tag, as the author changed it but
> erroneously retained the tag that I had released for an
> earlier version of that commit (which was fine, but the new
> version broke mtk_dsi!).
>
> drivers/gpu/drm/mediatek/mtk_dsi.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 9cc406e1eee1..5b624e0f5b0a 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -808,10 +808,13 @@ static void mtk_dsi_bridge_atomic_post_disable(struct
> drm_bridge *bridge,
>
> static const struct drm_bridge_funcs mtk_dsi_bridge_funcs = {
> .attach = mtk_dsi_bridge_attach,
> + .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
> .atomic_disable = mtk_dsi_bridge_atomic_disable,
> + .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
> .atomic_enable = mtk_dsi_bridge_atomic_enable,
> .atomic_pre_enable = mtk_dsi_bridge_atomic_pre_enable,
> .atomic_post_disable = mtk_dsi_bridge_atomic_post_disable,
> + .atomic_reset = drm_atomic_helper_bridge_reset,
> .mode_set = mtk_dsi_bridge_mode_set,
> };
>
> --
> 2.35.1
>
Re: [PATCH 0/4] Allow MMIO regions to be exported through dma-buf
On Thu, Aug 18, 2022 at 03:37:01PM +0200, Christian König wrote: > Am 18.08.22 um 15:16 schrieb Jason Gunthorpe: > > On Thu, Aug 18, 2022 at 02:58:10PM +0200, Christian König wrote: > > > > > > > The only thing I'm not 100% convinced of is dma_buf_try_get(), I've > > > > > seen > > > > > this incorrectly used so many times that I can't count them any more. > > > > > > > > > > Would that be somehow avoidable? Or could you at least explain the > > > > > use case > > > > > a bit better. > > > > I didn't see a way, maybe you know of one > > > For GEM objects we usually don't use the reference count of the DMA-buf, > > > but > > > rather that of the GEM object for this. But that's not an ideal solution > > > either. > > You can't really ignore the dmabuf refcount. At some point you have to > > deal with the dmabuf being asynchronously released by userspace. > > Yeah, but in this case the dma-buf is just a reference to the real/private > object which holds the backing store. The gem approach is backwards to what I did here. GEM holds a singleton pointer to the dmabuf and holds a reference on it as long as it has the pointer. This means the dmabuf can not be freed until the GEM object is freed. For this I held a "weak reference" on the dmabuf in a list, and we convert the weak reference to a strong reference in the usual way using a try_get. The reason it is different is because the VFIO interface allows creating a DMABUF with unique parameters on every user request. Eg the user can select a BAR index and a slice of the MMIO space unique to each each request and this results in a unique DMABUF. Due to this we have to store a list of DMABUFs and we need the DMABUF's to clean up their memory when the user closes the file. > > So we could delete the try_buf and just rely on move being safe on > > partially destroyed dma_buf's as part of the API design. > > I think that might be the more defensive approach. A comment on the > dma_buf_move_notify() function should probably be a good idea. IMHO, it is an anti-pattern. The caller should hold a strong reference on an object before invoking any API surface. Upgrading a weak reference to a strong reference requires the standard "try get" API. But if you feel strongly I don't mind dropping the try_get around move. Jason
Re: [PATCH 1/3] drm: Use original src rect while initializing damage iterator
Hi Jouni,
On 7/15/22 10:49, Jouni Högander wrote:
> drm_plane_state->src might be modified by the driver. This is done
> e.g. in i915 driver when there is bigger framebuffer than the plane
> and there is some offset within framebuffer. I915 driver calculates
> separate offset and adjusts src rect coords to be relative to this
> offset. Damage clips are still relative to original src coords
> provided by user-space.
>
> This patch ensures original coordinates provided by user-space are
> used when initiliazing damage iterator.
>
drm_damage_helper has some KUnit tests on drivers/gpu/drm/tests, and by
applying this patch the drm_damage_helper tests started to fail. Could
you also refactor the drm_damage_helper tests?
To run the tests, you can run:
$ ./tools/testing/kunit/kunit.py run \
--kunitconfig=drivers/gpu/drm/tests \
--kconfig_add CONFIG_UML_PCI_OVER_VIRTIO=y \
--kconfig_add CONFIG_VIRTIO_UML=y
There is also some documentation on the DRM KUnit Tests on [1].
[1] https://docs.kernel.org/gpu/drm-internals.html#unit-testing
Best Regards,
- Maíra Canal
> Signed-off-by: Jouni Högander > ---
> drivers/gpu/drm/drm_damage_helper.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_damage_helper.c
> b/drivers/gpu/drm/drm_damage_helper.c
> index 937b699ac2a8..d8b2955e88fd 100644
> --- a/drivers/gpu/drm/drm_damage_helper.c
> +++ b/drivers/gpu/drm/drm_damage_helper.c
> @@ -224,6 +224,7 @@ drm_atomic_helper_damage_iter_init(struct
> drm_atomic_helper_damage_iter *iter,
> const struct drm_plane_state *old_state,
> const struct drm_plane_state *state)
> {
> + struct drm_rect src;
> memset(iter, 0, sizeof(*iter));
>
> if (!state || !state->crtc || !state->fb || !state->visible)
> @@ -233,10 +234,12 @@ drm_atomic_helper_damage_iter_init(struct
> drm_atomic_helper_damage_iter *iter,
> iter->num_clips = drm_plane_get_damage_clips_count(state);
>
> /* Round down for x1/y1 and round up for x2/y2 to catch all pixels */
> - iter->plane_src.x1 = state->src.x1 >> 16;
> - iter->plane_src.y1 = state->src.y1 >> 16;
> - iter->plane_src.x2 = (state->src.x2 >> 16) + !!(state->src.x2 & 0x);
> - iter->plane_src.y2 = (state->src.y2 >> 16) + !!(state->src.y2 & 0x);
> + src = drm_plane_state_src(state);
> +
> + iter->plane_src.x1 = src.x1 >> 16;
> + iter->plane_src.y1 = src.y1 >> 16;
> + iter->plane_src.x2 = (src.x2 >> 16) + !!(src.x2 & 0x);
> + iter->plane_src.y2 = (src.y2 >> 16) + !!(src.y2 & 0x);
>
> if (!iter->clips || !drm_rect_equals(>src, _state->src)) {
> iter->clips = NULL;
[PATCH drm-misc-next 2/3] drm/vc4: plane: protect device resources after removal
(Hardware) resources which are bound to the driver and device lifecycle
must not be accessed after the device and driver are unbound.
However, the DRM device isn't freed as long as the last user closed it,
hence userspace can still call into the driver.
Therefore protect the critical sections which are accessing those
resources with drm_dev_enter() and drm_dev_exit().
Fixes: 9872c7a31921 ("drm/vc4: plane: Switch to drmm_universal_plane_alloc()")
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/vc4/vc4_drv.h | 1 +
drivers/gpu/drm/vc4/vc4_plane.c | 25 +
2 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 418a8242691f..80da9a9337cc 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -341,6 +341,7 @@ struct vc4_hvs {
struct vc4_plane {
struct drm_plane base;
+ struct drm_device *dev;
};
static inline struct vc4_plane *
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index eff9c63adfa7..cb13bb583546 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1218,14 +1219,22 @@ static void vc4_plane_atomic_update(struct drm_plane
*plane,
u32 vc4_plane_write_dlist(struct drm_plane *plane, u32 __iomem *dlist)
{
struct vc4_plane_state *vc4_state = to_vc4_plane_state(plane->state);
+ struct vc4_plane *vc4_plane = to_vc4_plane(plane);
int i;
+ int idx;
vc4_state->hw_dlist = dlist;
+ if (!drm_dev_enter(vc4_plane->dev, ))
+ goto out;
+
/* Can't memcpy_toio() because it needs to be 32-bit writes. */
for (i = 0; i < vc4_state->dlist_count; i++)
writel(vc4_state->dlist[i], [i]);
+ drm_dev_exit(idx);
+
+out:
return vc4_state->dlist_count;
}
@@ -1243,8 +1252,10 @@ u32 vc4_plane_dlist_size(const struct drm_plane_state
*state)
void vc4_plane_async_set_fb(struct drm_plane *plane, struct drm_framebuffer
*fb)
{
struct vc4_plane_state *vc4_state = to_vc4_plane_state(plane->state);
+ struct vc4_plane *vc4_plane = to_vc4_plane(plane);
struct drm_gem_dma_object *bo = drm_fb_dma_get_gem_obj(fb, 0);
uint32_t addr;
+ int idx;
/* We're skipping the address adjustment for negative origin,
* because this is only called on the primary plane.
@@ -1252,12 +1263,17 @@ void vc4_plane_async_set_fb(struct drm_plane *plane,
struct drm_framebuffer *fb)
WARN_ON_ONCE(plane->state->crtc_x < 0 || plane->state->crtc_y < 0);
addr = bo->dma_addr + fb->offsets[0];
+ if (!drm_dev_enter(vc4_plane->dev, ))
+ return;
+
/* Write the new address into the hardware immediately. The
* scanout will start from this address as soon as the FIFO
* needs to refill with pixels.
*/
writel(addr, _state->hw_dlist[vc4_state->ptr0_offset]);
+ drm_dev_exit(idx);
+
/* Also update the CPU-side dlist copy, so that any later
* atomic updates that don't do a new modeset on our plane
* also use our updated address.
@@ -1271,6 +1287,8 @@ static void vc4_plane_atomic_async_update(struct
drm_plane *plane,
struct drm_plane_state *new_plane_state =
drm_atomic_get_new_plane_state(state,
plane);
struct vc4_plane_state *vc4_state, *new_vc4_state;
+ struct vc4_plane *vc4_plane = to_vc4_plane(plane);
+ int idx;
swap(plane->state->fb, new_plane_state->fb);
plane->state->crtc_x = new_plane_state->crtc_x;
@@ -1323,6 +1341,9 @@ static void vc4_plane_atomic_async_update(struct
drm_plane *plane,
vc4_state->dlist[vc4_state->ptr0_offset] =
new_vc4_state->dlist[vc4_state->ptr0_offset];
+ if (!drm_dev_enter(vc4_plane->dev, ))
+ return;
+
/* Note that we can't just call vc4_plane_write_dlist()
* because that would smash the context data that the HVS is
* currently using.
@@ -1333,6 +1354,8 @@ static void vc4_plane_atomic_async_update(struct
drm_plane *plane,
_state->hw_dlist[vc4_state->pos2_offset]);
writel(vc4_state->dlist[vc4_state->ptr0_offset],
_state->hw_dlist[vc4_state->ptr0_offset]);
+
+ drm_dev_exit(idx);
}
static int vc4_plane_atomic_async_check(struct drm_plane *plane,
@@ -1521,6 +1544,8 @@ struct drm_plane *vc4_plane_init(struct drm_device *dev,
modifiers, type, NULL);
if (IS_ERR(vc4_plane))
return ERR_CAST(vc4_plane);
+
+ vc4_plane->dev = dev;
plane = _plane->base;
if (vc4->is_vc5)
--
2.37.2
[PATCH v2 15/21] drm/i915/mtl: Obtain SAGV values from MMIO instead of GT pcode mailbox
>From Meteorlake, Latency Level, SAGV bloack time are read from
LATENCY_SAGV register instead of the GT driver pcode mailbox. DDR type
and QGV information are also to be read from Mem SS registers.
v2:
- Simplify MTL_MEM_SS_INFO_QGV_POINT macro(MattR)
- Nit: Rearrange the bit def's from higher to lower(MattR)
- Restore platform definition for ADL-P(MattR)
- Move back intel_qgv_point def to intel_bw.c(Jani)
Bspec: 64636, 64608
Cc: Matt Roper
Cc: Jani Nikula
Original Author: Caz Yokoyama
Signed-off-by: José Roberto de Souza
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/display/intel_bw.c | 42 ++---
drivers/gpu/drm/i915/i915_reg.h | 16 ++
drivers/gpu/drm/i915/intel_dram.c | 41 +++-
drivers/gpu/drm/i915/intel_pm.c | 8 -
4 files changed, 100 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index 79269d2c476b..46b63afd536a 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -137,6 +137,42 @@ int icl_pcode_restrict_qgv_points(struct drm_i915_private
*dev_priv,
return 0;
}
+static int mtl_read_qgv_point_info(struct drm_i915_private *dev_priv,
+ struct intel_qgv_point *sp, int point)
+{
+ u32 val, val2;
+ u16 dclk;
+
+ val = intel_uncore_read(_priv->uncore,
+ MTL_MEM_SS_INFO_QGV_POINT_LOW(point));
+ val2 = intel_uncore_read(_priv->uncore,
+MTL_MEM_SS_INFO_QGV_POINT_HIGH(point));
+ dclk = REG_FIELD_GET(MTL_DCLK_MASK, val);
+ sp->dclk = DIV_ROUND_UP((16667 * dclk), 1000);
+ sp->t_rp = REG_FIELD_GET(MTL_TRP_MASK, val);
+ sp->t_rcd = REG_FIELD_GET(MTL_TRCD_MASK, val);
+
+ sp->t_rdpre = REG_FIELD_GET(MTL_TRDPRE_MASK, val2);
+ sp->t_ras = REG_FIELD_GET(MTL_TRAS_MASK, val2);
+
+ sp->t_rc = sp->t_rp + sp->t_ras;
+
+ return 0;
+}
+
+static int
+intel_read_qgv_point_info(struct drm_i915_private *dev_priv,
+ struct intel_qgv_point *sp,
+ int point)
+{
+ if (DISPLAY_VER(dev_priv) >= 14)
+ return mtl_read_qgv_point_info(dev_priv, sp, point);
+ else if (IS_DG1(dev_priv))
+ return dg1_mchbar_read_qgv_point_info(dev_priv, sp, point);
+ else
+ return icl_pcode_read_qgv_point_info(dev_priv, sp, point);
+}
+
static int icl_get_qgv_points(struct drm_i915_private *dev_priv,
struct intel_qgv_info *qi,
bool is_y_tile)
@@ -193,11 +229,7 @@ static int icl_get_qgv_points(struct drm_i915_private
*dev_priv,
for (i = 0; i < qi->num_points; i++) {
struct intel_qgv_point *sp = >points[i];
- if (IS_DG1(dev_priv))
- ret = dg1_mchbar_read_qgv_point_info(dev_priv, sp, i);
- else
- ret = icl_pcode_read_qgv_point_info(dev_priv, sp, i);
-
+ ret = intel_read_qgv_point_info(dev_priv, sp, i);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b2d5e1230c25..5245af8d0ea8 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8397,4 +8397,20 @@ enum skl_power_gate {
#define MTL_LATENCY_LEVEL0_2_4_MASK REG_GENMASK(12, 0)
#define MTL_LATENCY_LEVEL1_3_5_MASK REG_GENMASK(28, 16)
+#define MTL_LATENCY_SAGV _MMIO(0x4578c)
+#define MTL_LATENCY_QCLK_SAGV REG_GENMASK(12, 0)
+
+#define MTL_MEM_SS_INFO_GLOBAL _MMIO(0x45700)
+#define MTL_DDR_TYPE_MASK REG_GENMASK(3, 0)
+#define MTL_N_OF_POPULATED_CH_MASKREG_GENMASK(7, 4)
+#define MTL_N_OF_ENABLED_QGV_POINTS_MASK REG_GENMASK(11, 8)
+
+#define MTL_MEM_SS_INFO_QGV_POINT_LOW(point)_MMIO(0x45710 + (point) * 2)
+#define MTL_MEM_SS_INFO_QGV_POINT_HIGH(point) _MMIO(0x45714 + (point) * 2)
+#define MTL_TRCD_MASK REG_GENMASK(31, 24)
+#define MTL_TRP_MASK REG_GENMASK(23, 16)
+#define MTL_TRAS_MASK REG_GENMASK(16, 8)
+#define MTL_DCLK_MASK REG_GENMASK(15, 0)
+#define MTL_TRDPRE_MASK REG_GENMASK(7, 0)
+
#endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_dram.c
b/drivers/gpu/drm/i915/intel_dram.c
index 437447119770..2403ccd52c74 100644
--- a/drivers/gpu/drm/i915/intel_dram.c
+++ b/drivers/gpu/drm/i915/intel_dram.c
@@ -466,6 +466,43 @@ static int gen12_get_dram_info(struct drm_i915_private
*i915)
return icl_pcode_read_mem_global_info(i915);
}
+static int xelpdp_get_dram_info(struct drm_i915_private *i915)
+{
+ u32 val = intel_uncore_read(>uncore, MTL_MEM_SS_INFO_GLOBAL);
+ struct dram_info *dram_info =
[PATCH v2 08/21] drm/i915/mtl: Add VBT port and AUX_CH mapping
From: Imre Deak
Add the proper VBT port,AUX_CH -> i915 port,AUX_CH mapping which just
follows the ADL_P one.
Reviewed-by: Matt Roper
Signed-off-by: Imre Deak
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/display/intel_bios.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index 198a2f4920cc..81d6cfbd2615 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -2420,7 +2420,7 @@ static enum port dvo_port_to_port(struct drm_i915_private
*i915,
[PORT_TC4] = { DVO_PORT_HDMII, DVO_PORT_DPI, -1 },
};
- if (DISPLAY_VER(i915) == 13)
+ if (DISPLAY_VER(i915) >= 13)
return __dvo_port_to_port(ARRAY_SIZE(xelpd_port_mapping),
ARRAY_SIZE(xelpd_port_mapping[0]),
xelpd_port_mapping,
@@ -3578,7 +3578,7 @@ enum aux_ch intel_bios_port_aux_ch(struct
drm_i915_private *i915,
aux_ch = AUX_CH_C;
break;
case DP_AUX_D:
- if (DISPLAY_VER(i915) == 13)
+ if (DISPLAY_VER(i915) >= 13)
aux_ch = AUX_CH_D_XELPD;
else if (IS_ALDERLAKE_S(i915))
aux_ch = AUX_CH_USBC3;
@@ -3588,7 +3588,7 @@ enum aux_ch intel_bios_port_aux_ch(struct
drm_i915_private *i915,
aux_ch = AUX_CH_D;
break;
case DP_AUX_E:
- if (DISPLAY_VER(i915) == 13)
+ if (DISPLAY_VER(i915) >= 13)
aux_ch = AUX_CH_E_XELPD;
else if (IS_ALDERLAKE_S(i915))
aux_ch = AUX_CH_USBC4;
@@ -3596,25 +3596,25 @@ enum aux_ch intel_bios_port_aux_ch(struct
drm_i915_private *i915,
aux_ch = AUX_CH_E;
break;
case DP_AUX_F:
- if (DISPLAY_VER(i915) == 13)
+ if (DISPLAY_VER(i915) >= 13)
aux_ch = AUX_CH_USBC1;
else
aux_ch = AUX_CH_F;
break;
case DP_AUX_G:
- if (DISPLAY_VER(i915) == 13)
+ if (DISPLAY_VER(i915) >= 13)
aux_ch = AUX_CH_USBC2;
else
aux_ch = AUX_CH_G;
break;
case DP_AUX_H:
- if (DISPLAY_VER(i915) == 13)
+ if (DISPLAY_VER(i915) >= 13)
aux_ch = AUX_CH_USBC3;
else
aux_ch = AUX_CH_H;
break;
case DP_AUX_I:
- if (DISPLAY_VER(i915) == 13)
+ if (DISPLAY_VER(i915) >= 13)
aux_ch = AUX_CH_USBC4;
else
aux_ch = AUX_CH_I;
--
2.25.1
[PATCH v2 09/21] drm/i915/mtl: Add support for MTL in Display Init sequences
The initialization sequence for Meteorlake reuses the sequence for icelake for most parts. Some changes viz. reset PICA handshake are added. Bspec: 49189 Reviewed-by: Matt Roper Signed-off-by: Radhakrishna Sripada --- drivers/gpu/drm/i915/display/intel_display_power.c | 3 +++ drivers/gpu/drm/i915/i915_reg.h| 3 ++- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c b/drivers/gpu/drm/i915/display/intel_display_power.c index f7e8d1ff62cf..9c1fefb2da55 100644 --- a/drivers/gpu/drm/i915/display/intel_display_power.c +++ b/drivers/gpu/drm/i915/display/intel_display_power.c @@ -1382,6 +1382,9 @@ static void intel_pch_reset_handshake(struct drm_i915_private *dev_priv, reset_bits = RESET_PCH_HANDSHAKE_ENABLE; } + if (DISPLAY_VER(dev_priv) >= 14) + reset_bits |= MTL_RESET_PICA_HANDSHAKE_EN; + val = intel_de_read(dev_priv, reg); if (enable) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 15a53cb5e1ee..e2e9932fa484 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -5821,7 +5821,8 @@ _BW_BUDDY1_PAGE_MASK)) #define HSW_NDE_RSTWRN_OPT _MMIO(0x46408) -#define RESET_PCH_HANDSHAKE_ENABLE(1 << 4) +#define MTL_RESET_PICA_HANDSHAKE_EN REG_BIT(6) +#define RESET_PCH_HANDSHAKE_ENABLEREG_BIT(4) #define GEN8_CHICKEN_DCPR_1_MMIO(0x46430) #define SKL_SELECT_ALTERNATE_DC_EXIT REG_BIT(30) -- 2.25.1
[PATCH v2 05/15] mei: pxp: add command streamer API to the PXP driver
From: Vitaly Lubart
The discrete graphics card with GSC firmware
using command streamer API hence it requires to enhance
pxp module with the new gsc_command() handler.
The handler is implemented via mei_pxp_gsc_command() which is
just just a thin wrapper around mei_cldev_send_gsc_command()
V2:
1. More detailed commit message
2. Fix typo in the comments
Signed-off-by: Vitaly Lubart
Signed-off-by: Tomas Winkler
Signed-off-by: Daniele Ceraolo Spurio
Reviewed-by: Alan Previn
---
drivers/misc/mei/pxp/mei_pxp.c | 28
include/drm/i915_pxp_tee_interface.h | 5 +
2 files changed, 33 insertions(+)
diff --git a/drivers/misc/mei/pxp/mei_pxp.c b/drivers/misc/mei/pxp/mei_pxp.c
index 5c39457e3f53..17c5d201603f 100644
--- a/drivers/misc/mei/pxp/mei_pxp.c
+++ b/drivers/misc/mei/pxp/mei_pxp.c
@@ -77,10 +77,38 @@ mei_pxp_receive_message(struct device *dev, void *buffer,
size_t size)
return byte;
}
+/**
+ * mei_pxp_gsc_command() - sends a gsc command, by sending
+ * a sgl mei message to gsc and receiving reply from gsc
+ *
+ * @dev: device corresponding to the mei_cl_device
+ * @client_id: client id to send the command to
+ * @fence_id: fence id to send the command to
+ * @sg_in: scatter gather list containing addresses for rx message buffer
+ * @total_in_len: total length of data in 'in' sg, can be less than the sum of
buffers sizes
+ * @sg_out: scatter gather list containing addresses for tx message buffer
+ *
+ * Return: bytes sent on Success, <0 on Failure
+ */
+static ssize_t mei_pxp_gsc_command(struct device *dev, u8 client_id, u32
fence_id,
+ struct scatterlist *sg_in, size_t
total_in_len,
+ struct scatterlist *sg_out)
+{
+ struct mei_cl_device *cldev;
+
+ if (!dev || !sg_in || !sg_out)
+ return -EINVAL;
+
+ cldev = to_mei_cl_device(dev);
+
+ return mei_cldev_send_gsc_command(cldev, client_id, fence_id, sg_in,
total_in_len, sg_out);
+}
+
static const struct i915_pxp_component_ops mei_pxp_ops = {
.owner = THIS_MODULE,
.send = mei_pxp_send_message,
.recv = mei_pxp_receive_message,
+ .gsc_command = mei_pxp_gsc_command,
};
static int mei_component_master_bind(struct device *dev)
diff --git a/include/drm/i915_pxp_tee_interface.h
b/include/drm/i915_pxp_tee_interface.h
index af593ec64469..67d44a1827f9 100644
--- a/include/drm/i915_pxp_tee_interface.h
+++ b/include/drm/i915_pxp_tee_interface.h
@@ -8,6 +8,7 @@
#include
#include
+#include
/**
* struct i915_pxp_component_ops - ops for PXP services.
@@ -23,6 +24,10 @@ struct i915_pxp_component_ops {
int (*send)(struct device *dev, const void *message, size_t size);
int (*recv)(struct device *dev, void *buffer, size_t size);
+ ssize_t (*gsc_command)(struct device *dev, u8 client_id, u32 fence_id,
+ struct scatterlist *sg_in, size_t total_in_len,
+ struct scatterlist *sg_out);
+
};
/**
--
2.37.2
[PATCH v2 04/15] mei: bus: extend bus API to support command streamer API
From: Vitaly Lubart
Add mei bus API for sending gsc commands: mei_cldev_send_gsc_command()
The GSC commands are originated in the graphics stack
and are in form of SGL DMA buffers.
The GSC commands are synchronous, the response is received
in the same call on the out sg list buffers.
The function setups pointers for in and out sg lists in the
mei sgl extended header and sends it to the firmware.
V2:
1. More detailed commit message
2. Fix typo in the comments
Signed-off-by: Vitaly Lubart
Signed-off-by: Tomas Winkler
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/misc/mei/bus.c | 125 +
include/linux/mei_cl_bus.h | 6 ++
2 files changed, 131 insertions(+)
diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index 225f0b04c021..fc885ba94b36 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -838,6 +838,131 @@ int mei_cldev_disable(struct mei_cl_device *cldev)
}
EXPORT_SYMBOL_GPL(mei_cldev_disable);
+/**
+ * mei_cldev_send_gsc_command - sends a gsc command, by sending
+ * a gsl mei message to gsc and receiving reply from gsc
+ *
+ * @cldev: me client device
+ * @client_id: client id to send the command to
+ * @fence_id: fence id to send the command to
+ * @sg_in: scatter gather list containing addresses for rx message buffer
+ * @total_in_len: total length of data in 'in' sg, can be less than the sum of
buffers sizes
+ * @sg_out: scatter gather list containing addresses for tx message buffer
+ *
+ * Return:
+ * * written size in bytes
+ * * < 0 on error
+ */
+ssize_t mei_cldev_send_gsc_command(struct mei_cl_device *cldev,
+ u8 client_id, u32 fence_id,
+ struct scatterlist *sg_in,
+ size_t total_in_len,
+ struct scatterlist *sg_out)
+{
+ struct mei_cl *cl;
+ struct mei_device *bus;
+ ssize_t ret = 0;
+
+ struct mei_ext_hdr_gsc_h2f *ext_hdr;
+ size_t buf_sz = sizeof(struct mei_ext_hdr_gsc_h2f);
+ int sg_out_nents, sg_in_nents;
+ int i;
+ struct scatterlist *sg;
+ struct mei_ext_hdr_gsc_f2h rx_msg;
+ unsigned int sg_len;
+
+ if (!cldev || !sg_in || !sg_out)
+ return -EINVAL;
+
+ cl = cldev->cl;
+ bus = cldev->bus;
+
+ dev_dbg(bus->dev, "client_id %u, fence_id %u\n", client_id, fence_id);
+
+ if (!bus->hbm_f_gsc_supported)
+ return -EOPNOTSUPP;
+
+ sg_out_nents = sg_nents(sg_out);
+ sg_in_nents = sg_nents(sg_in);
+ /* at least one entry in tx and rx sgls must be present */
+ if (sg_out_nents <= 0 || sg_in_nents <= 0)
+ return -EINVAL;
+
+ buf_sz += (sg_out_nents + sg_in_nents) * sizeof(struct mei_gsc_sgl);
+ ext_hdr = kzalloc(buf_sz, GFP_KERNEL);
+ if (!ext_hdr)
+ return -ENOMEM;
+
+ /* construct the GSC message */
+ ext_hdr->hdr.type = MEI_EXT_HDR_GSC;
+ ext_hdr->hdr.length = buf_sz / sizeof(u32); /* length is in dw */
+
+ ext_hdr->client_id = client_id;
+ ext_hdr->addr_type = GSC_ADDRESS_TYPE_PHYSICAL_SGL;
+ ext_hdr->fence_id = fence_id;
+ ext_hdr->input_address_count = sg_in_nents;
+ ext_hdr->output_address_count = sg_out_nents;
+ ext_hdr->reserved[0] = 0;
+ ext_hdr->reserved[1] = 0;
+
+ /* copy in-sgl to the message */
+ for (i = 0, sg = sg_in; i < sg_in_nents; i++, sg++) {
+ ext_hdr->sgl[i].low = lower_32_bits(sg_dma_address(sg));
+ ext_hdr->sgl[i].high = upper_32_bits(sg_dma_address(sg));
+ sg_len = min_t(unsigned int, sg_dma_len(sg), PAGE_SIZE);
+ ext_hdr->sgl[i].length = (sg_len <= total_in_len) ? sg_len :
total_in_len;
+ total_in_len -= ext_hdr->sgl[i].length;
+ }
+
+ /* copy out-sgl to the message */
+ for (i = sg_in_nents, sg = sg_out; i < sg_in_nents + sg_out_nents; i++,
sg++) {
+ ext_hdr->sgl[i].low = lower_32_bits(sg_dma_address(sg));
+ ext_hdr->sgl[i].high = upper_32_bits(sg_dma_address(sg));
+ sg_len = min_t(unsigned int, sg_dma_len(sg), PAGE_SIZE);
+ ext_hdr->sgl[i].length = sg_len;
+ }
+
+ /* send the message to GSC */
+ ret = __mei_cl_send(cl, (u8 *)ext_hdr, buf_sz, 0, MEI_CL_IO_SGL);
+ if (ret < 0) {
+ dev_err(bus->dev, "__mei_cl_send failed, returned %zd\n", ret);
+ goto end;
+ }
+ if (ret != buf_sz) {
+ dev_err(bus->dev, "__mei_cl_send returned %zd instead of
expected %zd\n",
+ ret, buf_sz);
+ ret = -EIO;
+ goto end;
+ }
+
+ /* receive the reply from GSC, note that at this point sg_in should
contain the reply */
+ ret = __mei_cl_recv(cl, (u8 *)_msg, sizeof(rx_msg), NULL,
MEI_CL_IO_SGL, 0);
+
+ if (ret != sizeof(rx_msg)) {
+
[PATCH v2 02/15] mei: add support to GSC extended header
From: Tomas Winkler
GSC extend header is of variable size and data
is provided in a sgl list inside the header
and not in the data buffers, need to enable the path.
Signed-off-by: Tomas Winkler
Signed-off-by: Daniele Ceraolo Spurio
Cc: Vitaly Lubart
---
drivers/misc/mei/client.c| 55 --
drivers/misc/mei/hbm.c | 13
drivers/misc/mei/hw-me.c | 5 +++-
drivers/misc/mei/hw.h| 57
drivers/misc/mei/interrupt.c | 47 -
drivers/misc/mei/mei_dev.h | 3 ++
6 files changed, 157 insertions(+), 23 deletions(-)
diff --git a/drivers/misc/mei/client.c b/drivers/misc/mei/client.c
index e7a16d9b2241..8860a708ed19 100644
--- a/drivers/misc/mei/client.c
+++ b/drivers/misc/mei/client.c
@@ -322,6 +322,7 @@ void mei_io_cb_free(struct mei_cl_cb *cb)
list_del(>list);
kfree(cb->buf.data);
+ kfree(cb->ext_hdr);
kfree(cb);
}
@@ -401,6 +402,7 @@ static struct mei_cl_cb *mei_io_cb_init(struct mei_cl *cl,
cb->buf_idx = 0;
cb->fop_type = type;
cb->vtag = 0;
+ cb->ext_hdr = NULL;
return cb;
}
@@ -1740,6 +1742,17 @@ static inline u8 mei_ext_hdr_set_vtag(void *ext, u8 vtag)
return vtag_hdr->hdr.length;
}
+static inline bool mei_ext_hdr_is_gsc(struct mei_ext_hdr *ext)
+{
+ return ext && ext->type == MEI_EXT_HDR_GSC;
+}
+
+static inline u8 mei_ext_hdr_set_gsc(struct mei_ext_hdr *ext, struct
mei_ext_hdr *gsc_hdr)
+{
+ memcpy(ext, gsc_hdr, mei_ext_hdr_len(gsc_hdr));
+ return ext->length;
+}
+
/**
* mei_msg_hdr_init - allocate and initialize mei message header
*
@@ -1752,14 +1765,17 @@ static struct mei_msg_hdr *mei_msg_hdr_init(const
struct mei_cl_cb *cb)
size_t hdr_len;
struct mei_ext_meta_hdr *meta;
struct mei_msg_hdr *mei_hdr;
- bool is_ext, is_vtag;
+ bool is_ext, is_hbm, is_gsc, is_vtag;
+ struct mei_ext_hdr *next_ext;
if (!cb)
return ERR_PTR(-EINVAL);
/* Extended header for vtag is attached only on the first fragment */
is_vtag = (cb->vtag && cb->buf_idx == 0);
- is_ext = is_vtag;
+ is_hbm = cb->cl->me_cl->client_id == 0;
+ is_gsc = ((!is_hbm) && cb->cl->dev->hbm_f_gsc_supported &&
mei_ext_hdr_is_gsc(cb->ext_hdr));
+ is_ext = is_vtag || is_gsc;
/* Compute extended header size */
hdr_len = sizeof(*mei_hdr);
@@ -1771,6 +1787,9 @@ static struct mei_msg_hdr *mei_msg_hdr_init(const struct
mei_cl_cb *cb)
if (is_vtag)
hdr_len += sizeof(struct mei_ext_hdr_vtag);
+ if (is_gsc)
+ hdr_len += mei_ext_hdr_len(cb->ext_hdr);
+
setup_hdr:
mei_hdr = kzalloc(hdr_len, GFP_KERNEL);
if (!mei_hdr)
@@ -1785,10 +1804,20 @@ static struct mei_msg_hdr *mei_msg_hdr_init(const
struct mei_cl_cb *cb)
goto out;
meta = (struct mei_ext_meta_hdr *)mei_hdr->extension;
+ meta->size = 0;
+ next_ext = (struct mei_ext_hdr *)meta->hdrs;
if (is_vtag) {
meta->count++;
- meta->size += mei_ext_hdr_set_vtag(meta->hdrs, cb->vtag);
+ meta->size += mei_ext_hdr_set_vtag(next_ext, cb->vtag);
+ next_ext = mei_ext_next(next_ext);
+ }
+
+ if (is_gsc) {
+ meta->count++;
+ meta->size += mei_ext_hdr_set_gsc(next_ext, cb->ext_hdr);
+ next_ext = mei_ext_next(next_ext);
}
+
out:
mei_hdr->length = hdr_len - sizeof(*mei_hdr);
return mei_hdr;
@@ -1812,14 +1841,14 @@ int mei_cl_irq_write(struct mei_cl *cl, struct
mei_cl_cb *cb,
struct mei_msg_hdr *mei_hdr = NULL;
size_t hdr_len;
size_t hbuf_len, dr_len;
- size_t buf_len;
+ size_t buf_len = 0;
size_t data_len;
int hbuf_slots;
u32 dr_slots;
u32 dma_len;
int rets;
bool first_chunk;
- const void *data;
+ const void *data = NULL;
if (WARN_ON(!cl || !cl->dev))
return -ENODEV;
@@ -1839,8 +1868,10 @@ int mei_cl_irq_write(struct mei_cl *cl, struct mei_cl_cb
*cb,
return 0;
}
- buf_len = buf->size - cb->buf_idx;
- data = buf->data + cb->buf_idx;
+ if (buf->data) {
+ buf_len = buf->size - cb->buf_idx;
+ data = buf->data + cb->buf_idx;
+ }
hbuf_slots = mei_hbuf_empty_slots(dev);
if (hbuf_slots < 0) {
rets = -EOVERFLOW;
@@ -1858,9 +1889,6 @@ int mei_cl_irq_write(struct mei_cl *cl, struct mei_cl_cb
*cb,
goto err;
}
- cl_dbg(dev, cl, "Extended Header %d vtag = %d\n",
- mei_hdr->extended, cb->vtag);
-
hdr_len = sizeof(*mei_hdr) + mei_hdr->length;
/**
@@ -1889,7 +1917,7 @@ int mei_cl_irq_write(struct mei_cl *cl, struct mei_cl_cb
*cb,
}
[PATCH v3 28/31] ACPI: video: Drop "Samsung X360" acpi_backlight=native quirk
acpi_backlight=native is the default for the "Samsung X360", but as
the comment explains the quirk was still necessary because even
briefly registering the acpi_video0 backlight; and then unregistering
it once the native driver showed up, was leading to issues.
After the "ACPI: video: Make backlight class device registration
a separate step" patch from earlier in this patch-series, we no
longer briefly register the acpi_video0 backlight on systems where
the native driver should be used.
So this is no longer an issue an the quirk is no longer needed.
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
drivers/acpi/video_detect.c | 15 ---
1 file changed, 15 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 84ae22670e54..ce6d89fcdc0e 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -132,21 +132,6 @@ static int video_detect_force_none(const struct
dmi_system_id *d)
}
static const struct dmi_system_id video_detect_dmi_table[] = {
- /* On Samsung X360, the BIOS will set a flag (VDRV) if generic
-* ACPI backlight device is used. This flag will definitively break
-* the backlight interface (even the vendor interface) until next
-* reboot. It's why we should prevent video.ko from being used here
-* and we can't rely on a later call to acpi_video_unregister().
-*/
- {
-.callback = video_detect_force_vendor,
-/* X360 */
-.matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
- DMI_MATCH(DMI_PRODUCT_NAME, "X360"),
- DMI_MATCH(DMI_BOARD_NAME, "X360"),
- },
- },
{
/* https://bugzilla.redhat.com/show_bug.cgi?id=1128309 */
.callback = video_detect_force_vendor,
--
2.37.2
[PATCH v3 15/31] platform/x86: nvidia-wmi-ec-backlight: Move fw interface definitions to a header
Move the WMI interface definitions to a header, so that the definitions
can be shared with drivers/acpi/video_detect.c .
Suggested-by: Daniel Dadap
Signed-off-by: Hans de Goede
---
MAINTAINERS | 1 +
.../platform/x86/nvidia-wmi-ec-backlight.c| 66 +
.../x86/nvidia-wmi-ec-backlight.h | 70 +++
3 files changed, 72 insertions(+), 65 deletions(-)
create mode 100644 include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 8a5012ba6ff9..8d59c6e9b4db 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14526,6 +14526,7 @@ M: Daniel Dadap
L: platform-driver-...@vger.kernel.org
S: Supported
F: drivers/platform/x86/nvidia-wmi-ec-backlight.c
+F: include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
NVM EXPRESS DRIVER
M: Keith Busch
diff --git a/drivers/platform/x86/nvidia-wmi-ec-backlight.c
b/drivers/platform/x86/nvidia-wmi-ec-backlight.c
index 61e37194df70..e84e1d629b14 100644
--- a/drivers/platform/x86/nvidia-wmi-ec-backlight.c
+++ b/drivers/platform/x86/nvidia-wmi-ec-backlight.c
@@ -7,74 +7,10 @@
#include
#include
#include
+#include
#include
#include
-/**
- * enum wmi_brightness_method - WMI method IDs
- * @WMI_BRIGHTNESS_METHOD_LEVEL: Get/Set EC brightness level status
- * @WMI_BRIGHTNESS_METHOD_SOURCE: Get/Set EC Brightness Source
- */
-enum wmi_brightness_method {
- WMI_BRIGHTNESS_METHOD_LEVEL = 1,
- WMI_BRIGHTNESS_METHOD_SOURCE = 2,
- WMI_BRIGHTNESS_METHOD_MAX
-};
-
-/**
- * enum wmi_brightness_mode - Operation mode for WMI-wrapped method
- * @WMI_BRIGHTNESS_MODE_GET:Get the current brightness
level/source.
- * @WMI_BRIGHTNESS_MODE_SET:Set the brightness level.
- * @WMI_BRIGHTNESS_MODE_GET_MAX_LEVEL: Get the maximum brightness level. This
- * is only valid when the WMI method is
- * %WMI_BRIGHTNESS_METHOD_LEVEL.
- */
-enum wmi_brightness_mode {
- WMI_BRIGHTNESS_MODE_GET = 0,
- WMI_BRIGHTNESS_MODE_SET = 1,
- WMI_BRIGHTNESS_MODE_GET_MAX_LEVEL = 2,
- WMI_BRIGHTNESS_MODE_MAX
-};
-
-/**
- * enum wmi_brightness_source - Backlight brightness control source selection
- * @WMI_BRIGHTNESS_SOURCE_GPU: Backlight brightness is controlled by the GPU.
- * @WMI_BRIGHTNESS_SOURCE_EC: Backlight brightness is controlled by the
- * system's Embedded Controller (EC).
- * @WMI_BRIGHTNESS_SOURCE_AUX: Backlight brightness is controlled over the
- * DisplayPort AUX channel.
- */
-enum wmi_brightness_source {
- WMI_BRIGHTNESS_SOURCE_GPU = 1,
- WMI_BRIGHTNESS_SOURCE_EC = 2,
- WMI_BRIGHTNESS_SOURCE_AUX = 3,
- WMI_BRIGHTNESS_SOURCE_MAX
-};
-
-/**
- * struct wmi_brightness_args - arguments for the WMI-wrapped ACPI method
- * @mode:Pass in an wmi_brightness_mode value to select between
- * getting or setting a value.
- * @val: In parameter for value to set when using %WMI_BRIGHTNESS_MODE_SET
- * mode. Not used in conjunction with %WMI_BRIGHTNESS_MODE_GET or
- * %WMI_BRIGHTNESS_MODE_GET_MAX_LEVEL mode.
- * @ret: Out parameter returning retrieved value when operating in
- * %WMI_BRIGHTNESS_MODE_GET or %WMI_BRIGHTNESS_MODE_GET_MAX_LEVEL
- * mode. Not used in %WMI_BRIGHTNESS_MODE_SET mode.
- * @ignored: Padding; not used. The ACPI method expects a 24 byte params
struct.
- *
- * This is the parameters structure for the WmiBrightnessNotify ACPI method as
- * wrapped by WMI. The value passed in to @val or returned by @ret will be a
- * brightness value when the WMI method ID is %WMI_BRIGHTNESS_METHOD_LEVEL, or
- * an wmi_brightness_source value with %WMI_BRIGHTNESS_METHOD_SOURCE.
- */
-struct wmi_brightness_args {
- u32 mode;
- u32 val;
- u32 ret;
- u32 ignored[3];
-};
-
/**
* wmi_brightness_notify() - helper function for calling WMI-wrapped ACPI
method
* @w:Pointer to the struct wmi_device identified by %WMI_BRIGHTNESS_GUID
diff --git a/include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
b/include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
new file mode 100644
index ..d83104c6c6cb
--- /dev/null
+++ b/include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
@@ -0,0 +1,70 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __PLATFORM_DATA_X86_NVIDIA_WMI_EC_BACKLIGHT_H
+#define __PLATFORM_DATA_X86_NVIDIA_WMI_EC_BACKLIGHT_H
+
+/**
+ * enum wmi_brightness_method - WMI method IDs
+ * @WMI_BRIGHTNESS_METHOD_LEVEL: Get/Set EC brightness level status
+ * @WMI_BRIGHTNESS_METHOD_SOURCE: Get/Set EC Brightness Source
+ */
+enum wmi_brightness_method {
+ WMI_BRIGHTNESS_METHOD_LEVEL = 1,
+ WMI_BRIGHTNESS_METHOD_SOURCE = 2,
+ WMI_BRIGHTNESS_METHOD_MAX
+};
+
+/**
+ * enum wmi_brightness_mode - Operation mode for
[PATCH v3 02/31] drm/i915: Don't register backlight when another backlight should be used
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 262b2fda37e5..9ad67be13f54 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"
@@ -951,6 +953,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");
+ return 0;
+ }
+
memset(, 0, sizeof(props));
props.type = BACKLIGHT_RAW;
--
2.37.2
[PATCH v1 2/4] drm/hyperv: Don't forget to put PCI device when removing conflicting FB fails
When drm_aperture_remove_conflicting_pci_framebuffers() fails, 'pdev'
needs to be released with pci_dev_put().
Fixes: 76c56a5affeb ("drm/hyperv: Add DRM driver for hyperv synthetic video
device")
Signed-off-by: Vitaly Kuznetsov
---
drivers/gpu/drm/hyperv/hyperv_drm_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
index 46f6c454b820..ca4e517b95ca 100644
--- a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
+++ b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
@@ -82,7 +82,7 @@ static int hyperv_setup_gen1(struct hyperv_drm_device *hv)
ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev,
_driver);
if (ret) {
drm_err(dev, "Not able to remove boot fb\n");
- return ret;
+ goto error;
}
if (pci_request_region(pdev, 0, DRIVER_NAME) != 0)
--
2.37.1
Re: (subset) [PATCH v2 0/7] Devm helpers for regulator get and enable
On Fri, 12 Aug 2022 13:08:17 +0300, Matti Vaittinen wrote: > Devm helpers for regulator get and enable > > First patch in the series is actually just a simple documentation fix > which could be taken in as it is now. > > A few* drivers seem to use pattern demonstrated by pseudocode: > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next Thanks! [2/7] regulator: Add devm helpers for get and enable commit: da279e6965b3838e99e5c0ab8f76b87bf86b31a5 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
[PATCH 2/2] drm/panel: simple: Add EDT ETML1010G0DKA panel
Add support for the EDT ETML1010G0DKA 10.1" 1280x800 LVDS panel.
Signed-off-by: Dominik Haller
---
drivers/gpu/drm/panel/panel-simple.c | 29
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index f9e1f85daef7..9314db24ab51 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1779,6 +1779,32 @@ static const struct panel_desc edt_etml0700y5dha = {
.connector_type = DRM_MODE_CONNECTOR_LVDS,
};
+static const struct drm_display_mode edt_etml1010g0dka_mode = {
+ .clock = 7,
+ .hdisplay = 1280,
+ .hsync_start = 1280 + 100,
+ .hsync_end = 1280 + 100 + 19,
+ .htotal = 1280 + 100 + 19 + 41,
+ .vdisplay = 800,
+ .vsync_start = 800 + 4,
+ .vsync_end = 800 + 4 + 4,
+ .vtotal = 800 + 4 + 4 + 15,
+ .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
+};
+
+static const struct panel_desc edt_etml1010g0dka = {
+ .modes = _etml1010g0dka_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 216,
+ .height = 135,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH,
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
+};
+
static const struct drm_display_mode edt_etmv570g2dhu_mode = {
.clock = 25175,
.hdisplay = 640,
@@ -4057,6 +4083,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "edt,etml0700y5dha",
.data = _etml0700y5dha,
+ }, {
+ .compatible = "edt,etml1010g0dka",
+ .data = _etml1010g0dka,
}, {
.compatible = "edt,etmv570g2dhu",
.data = _etmv570g2dhu,
--
2.25.1
Re: [PATCH 5/5] drm/msm: Skip tlbinv on unmap from non-current pgtables
On Wed, Aug 24, 2022 at 10:46 AM Akhil P Oommen wrote: > > On 8/21/2022 11:49 PM, Rob Clark wrote: > > From: Rob Clark > > > > We can rely on the tlbinv done by CP_SMMU_TABLE_UPDATE in this case. > > > > Signed-off-by: Rob Clark > > --- > > drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 6 ++ > > drivers/gpu/drm/msm/msm_iommu.c | 29 +++ > > 2 files changed, 35 insertions(+) > > > > diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c > > b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c > > index c8ad8aeca777..1ba0ed629549 100644 > > --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c > > +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c > > @@ -1180,6 +1180,12 @@ static int hw_init(struct msm_gpu *gpu) > > /* Always come up on rb 0 */ > > a6xx_gpu->cur_ring = gpu->rb[0]; > > > > + /* > > + * Note, we cannot assume anything about the state of the SMMU when > > + * coming back from power collapse, so force a CP_SMMU_TABLE_UPDATE > > + * on the first submit. Also, msm_iommu_pagetable_unmap() relies on > > + * this behavior. > > + */ > > gpu->cur_ctx_seqno = 0; > > > > /* Enable the SQE_to start the CP engine */ > > diff --git a/drivers/gpu/drm/msm/msm_iommu.c > > b/drivers/gpu/drm/msm/msm_iommu.c > > index 94c8c09980d1..218074a58081 100644 > > --- a/drivers/gpu/drm/msm/msm_iommu.c > > +++ b/drivers/gpu/drm/msm/msm_iommu.c > > @@ -45,8 +45,37 @@ static int msm_iommu_pagetable_unmap(struct msm_mmu > > *mmu, u64 iova, > > size -= 4096; > > } > > > > + /* > > + * A CP_SMMU_TABLE_UPDATE is always sent for the first > > + * submit after resume, and that does a TLB invalidate. > > + * So we can skip that if the device is not currently > > + * powered. > > + */ > > + if (!pm_runtime_get_if_in_use(pagetable->parent->dev)) > > + goto out; > > + > > + /* > > + * If we are not the current pgtables, we can rely on the > > + * TLB invalidate done by CP_SMMU_TABLE_UPDATE. > > + * > > + * We'll always be racing with the GPU updating ttbr0, > > + * but there are only two cases: > > + * > > + * + either we are not the the current pgtables and there > > + *will be a tlbinv done by the GPU before we are again > > + * > > + * + or we are.. there might have already been a tblinv > > + *if we raced with the GPU, but we have to assume the > > + *worse and do the tlbinv > > + */ > > + if (adreno_smmu->get_ttbr0(adreno_smmu->cookie) != pagetable->ttbr) > > + goto out_put; > > + > > adreno_smmu->tlb_inv_by_id(adreno_smmu->cookie, pagetable->asid); > > > > +out_put: > > + pm_runtime_put(pagetable->parent->dev); > > +out: > > return (unmapped == size) ? 0 : -EINVAL; > > } > > > Asking because it is a *security issue* if we get this wrong: > 1. Is there any measure benefit with this patch? I believe tlb > invalidation doesn't contribute much to the unmap latency. It turned out to not make a huge difference.. although I expect the part about skipping the inv when runtime suspended is still useful from a power standpoint (but don't have a great setup to measure that) BR, -R > 2. We at least should insert a full memory barrier before reading the > ttbr0 register to ensure that everything we did prior to that is visible > to smmu. But then I guess the cost of the full barrier would be similar > to the tlb invalidation. > > Because it could lead to security issues or other very hard to debug > issues, I would prefer this optimization only if there is a significant > measurable gain. > > -Akhil. >
Re: [PATCH 0/4] Allow MMIO regions to be exported through dma-buf
On Thu, Aug 18, 2022 at 01:07:16PM +0200, Christian König wrote:
> Am 17.08.22 um 18:11 schrieb Jason Gunthorpe:
> > dma-buf has become a way to safely acquire a handle to non-struct page
> > memory that can still have lifetime controlled by the exporter. Notably
> > RDMA can now import dma-buf FDs and build them into MRs which allows for
> > PCI P2P operations. Extend this to allow vfio-pci to export MMIO memory
> > from PCI device BARs.
> >
> > This series supports a use case for SPDK where a NVMe device will be owned
> > by SPDK through VFIO but interacting with a RDMA device. The RDMA device
> > may directly access the NVMe CMB or directly manipulate the NVMe device's
> > doorbell using PCI P2P.
> >
> > However, as a general mechanism, it can support many other scenarios with
> > VFIO. I imagine this dmabuf approach to be usable by iommufd as well for
> > generic and safe P2P mappings.
>
> In general looks good to me, but we really need to get away from using
> sg_tables for this here.
>
> The only thing I'm not 100% convinced of is dma_buf_try_get(), I've seen
> this incorrectly used so many times that I can't count them any more.
>
> Would that be somehow avoidable? Or could you at least explain the use case
> a bit better.
I didn't see a way, maybe you know of one
VFIO needs to maintain a list of dmabuf FDs that have been created by
the user attached to each vfio_device:
int vfio_pci_core_feature_dma_buf(struct vfio_pci_core_device *vdev, u32 flags,
struct vfio_device_feature_dma_buf __user
*arg,
size_t argsz)
{
down_write(>memory_lock);
list_add_tail(>dmabufs_elm, >dmabufs);
up_write(>memory_lock);
And dmabuf FD's are removed from the list when the user closes the FD:
static void vfio_pci_dma_buf_release(struct dma_buf *dmabuf)
{
down_write(>vdev->memory_lock);
list_del_init(>dmabufs_elm);
up_write(>vdev->memory_lock);
Which then poses the problem: How do you iterate over only dma_buf's
that are still alive to execute move?
This seems necessary as parts of the dma_buf have already been
destroyed by the time the user's release function is called.
Which I solved like this:
down_write(>memory_lock);
list_for_each_entry_safe(priv, tmp, >dmabufs, dmabufs_elm) {
if (!dma_buf_try_get(priv->dmabuf))
continue;
So the scenarios resolve as:
- Concurrent release is not in progress: dma_buf_try_get() succeeds
and prevents concurrent release from starting
- Release has started but not reached its memory_lock:
dma_buf_try_get() fails
- Release has started but passed its memory_lock: dmabuf is not on
the list so dma_buf_try_get() is not called.
Jason
Re: [PATCH v2] drm/ast: add dmabuf/prime buffer sharing support
Am 18.08.22 um 11:45 schrieb oushixiong:
This patch adds ast specific codes for DRM prime feature, this is to
allow for offloading of rending in one direction and outputs in other.
v1->v2:
- Fix the comment.
Signed-off-by: oushixiong
---
drivers/gpu/drm/ast/ast_drv.c | 22 ++
drivers/gpu/drm/ast/ast_mode.c | 125 -
2 files changed, 146 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
index 7465c4f0156a..6c1f75174368 100644
--- a/drivers/gpu/drm/ast/ast_drv.c
+++ b/drivers/gpu/drm/ast/ast_drv.c
@@ -28,6 +28,7 @@
#include
#include
+#include
#include
#include
@@ -50,6 +51,23 @@ module_param_named(modeset, ast_modeset, int, 0400);
DEFINE_DRM_GEM_FOPS(ast_fops);
+static struct drm_gem_object *ast_gem_prime_import_sg_table(struct drm_device *dev,
+ struct dma_buf_attachment *attach,
+ struct sg_table *sg)
+{
+ struct drm_gem_vram_object *gbo;
+ struct dma_resv *resv = attach->dmabuf->resv;
+
+ ww_mutex_lock(>lock, NULL);
+ gbo = drm_gem_vram_create(dev, attach->dmabuf->size, 0);
+ ww_mutex_unlock(>lock);
+
+ if (IS_ERR(gbo))
+ return NULL;
Well where do you use the sg_table here?
Christian.
+
+ return >bo.base;
+}
+
static const struct drm_driver ast_driver = {
.driver_features = DRIVER_ATOMIC |
DRIVER_GEM |
@@ -63,6 +81,10 @@ static const struct drm_driver ast_driver = {
.minor = DRIVER_MINOR,
.patchlevel = DRIVER_PATCHLEVEL,
+ .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
+ .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
+ .gem_prime_import_sg_table = ast_gem_prime_import_sg_table,
+
DRM_GEM_VRAM_DRIVER
};
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 45b56b39ad47..ebe732705e34 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -48,6 +48,8 @@
#include "ast_drv.h"
#include "ast_tables.h"
+MODULE_IMPORT_NS(DMA_BUF);
+
static inline void ast_load_palette_index(struct ast_private *ast,
u8 index, u8 red, u8 green,
u8 blue)
@@ -1535,8 +1537,129 @@ static const struct drm_mode_config_helper_funcs
ast_mode_config_helper_funcs =
.atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
};
+static int ast_handle_damage(struct drm_framebuffer *fb, int x, int y,
+ int width, int height)
+{
+ struct drm_gem_vram_object *dst_bo = NULL;
+ void *dst = NULL;
+ int ret = 0, i;
+ unsigned long offset = 0;
+ bool unmap = false;
+ unsigned int bytesPerPixel;
+ struct iosys_map map;
+ struct iosys_map dmabuf_map;
+
+ bytesPerPixel = fb->format->cpp[0];
+
+ if (!fb->obj[0]->import_attach)
+ return -EINVAL;
+
+ if (!fb->obj[0]->import_attach->dmabuf->vmap_ptr.vaddr) {
+ ret = dma_buf_vmap(fb->obj[0]->import_attach->dmabuf,
_map);
+ if (ret)
+ return 0;
+ } else
+ dmabuf_map.vaddr =
fb->obj[0]->import_attach->dmabuf->vmap_ptr.vaddr;
+
+ dst_bo = drm_gem_vram_of_gem(fb->obj[0]);
+
+ ret = drm_gem_vram_pin(dst_bo, 0);
+ if (ret) {
+ DRM_ERROR("ast_bo_pin failed\n");
+ goto error;
+ }
+
+ if (!dst_bo->map.vaddr) {
+ ret = drm_gem_vram_vmap(dst_bo, );
+ if (ret) {
+ DRM_ERROR("failed to vmap fbcon\n");
+ drm_gem_vram_unpin(dst_bo);
+ goto error;
+ }
+ unmap = true;
+ }
+ dst = dst_bo->map.vaddr;
+
+ for (i = y; i < y + height; i++) {
+ offset = i * fb->pitches[0] + (x * bytesPerPixel);
+ memcpy_toio(dst + offset, dmabuf_map.vaddr + offset,
+ width * bytesPerPixel);
+ }
+
+ if (unmap)
+ drm_gem_vram_vunmap(dst_bo, );
+
+ drm_gem_vram_unpin(dst_bo);
+error:
+ return 0;
+}
+
+
+static int ast_user_framebuffer_dirty(struct drm_framebuffer *fb,
+ struct drm_file *file,
+ unsigned int flags,
+ unsigned int color,
+ struct drm_clip_rect *clips,
+ unsigned int num_clips)
+{
+ int i, ret = 0;
+
+ drm_modeset_lock_all(fb->dev);
+ if (fb->obj[0]->import_attach) {
+ ret =
dma_buf_begin_cpu_access(fb->obj[0]->import_attach->dmabuf,
+ DMA_FROM_DEVICE);
+ if (ret)
+ goto unlock;
+ }
+
+ for (i = 0; i <
