Re: scripts/kernel-doc does not handle duplicate struct & function names (e.g., in amdgpu)
Hi Randy,
> [just documenting this for posterity or in case someone wants to fix it.]
>
> In drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c, one can find both
>
> struct amdgpu_vm_tlb_seq_cb {...};
>
> and
> static void amdgpu_vm_tlb_seq_cb(...)
>
> Of course C has no problem with this, but kernel-doc reports:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:833: WARNING: Duplicate C declaration,
> also defined at gpu/amdgpu/driver-core:115.
>
> And of course, if the name of one of them is changed, kernel-doc is all
> happy...
> not that I am suggesting that one of them should be changed.
>
> I just want to make people aware of this. (or maybe people are already aware
> of this?)
The duplicate warning is emitted from Sphinx, not kernel-doc.
This is a bug of Sphinx >=3.1, first reported by Mauro back in September 2020
at:
https://github.com/sphinx-doc/sphinx/issues/8241
It was closed when a local fix was presented. Unfortunately, it was not
merged at the time and a subsequent pull request was opened at:
https://github.com/sphinx-doc/sphinx/pull/8313
It is not merged yet and carries a milestone of Sphinx 7.x.
Looks like we need to wait patiently.
Thanks, Akira
>
> --
> ~Randy
scripts/kernel-doc does not handle duplicate struct & function names (e.g., in amdgpu)
[just documenting this for posterity or in case someone wants to fix it.]
In drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c, one can find both
struct amdgpu_vm_tlb_seq_cb {...};
and
static void amdgpu_vm_tlb_seq_cb(...)
Of course C has no problem with this, but kernel-doc reports:
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:833: WARNING: Duplicate C declaration,
also defined at gpu/amdgpu/driver-core:115.
And of course, if the name of one of them is changed, kernel-doc is all happy...
not that I am suggesting that one of them should be changed.
I just want to make people aware of this. (or maybe people are already aware of
this?)
--
~Randy
[PATCH] drm/amd/display: dc.h: eliminate kernel-doc warnings
Quash 175 kernel-doc warnings in dc.h by unmarking 2 struct
comments as containing kernel-doc notation and by spelling one
struct field correctly in a kernel-doc comment.
Fixes: 1682bd1a6b5f ("drm/amd/display: Expand kernel doc for DC")
Fixes: ea76895ffab1 ("drm/amd/display: Document pipe split policy")
Fixes: f6ae69f49fcf ("drm/amd/display: Include surface of unaffected streams")
Signed-off-by: Randy Dunlap
Cc: Harry Wentland
Cc: Leo Li
Cc: Rodrigo Siqueira
Cc: Aurabindo Pillai
Cc: Alex Deucher
Cc: amd-gfx@lists.freedesktop.org
Cc: Alex Deucher
Cc: Christian König
Cc: "Pan, Xinhui"
Cc: dri-de...@lists.freedesktop.org
---
drivers/gpu/drm/amd/display/dc/dc.h |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff -- a/drivers/gpu/drm/amd/display/dc/dc.h
b/drivers/gpu/drm/amd/display/dc/dc.h
--- a/drivers/gpu/drm/amd/display/dc/dc.h
+++ b/drivers/gpu/drm/amd/display/dc/dc.h
@@ -506,7 +506,7 @@ enum dcn_zstate_support_state {
DCN_ZSTATE_SUPPORT_DISALLOW,
};
-/**
+/*
* struct dc_clocks - DC pipe clocks
*
* For any clocks that may differ per pipe only the max is stored in this
@@ -728,7 +728,7 @@ struct resource_pool;
struct dce_hwseq;
struct link_service;
-/**
+/*
* struct dc_debug_options - DC debug struct
*
* This struct provides a simple mechanism for developers to change some
@@ -756,7 +756,7 @@ struct dc_debug_options {
bool use_max_lb;
enum dcc_option disable_dcc;
- /**
+ /*
* @pipe_split_policy: Define which pipe split policy is used by the
* display core.
*/
@@ -1334,7 +1334,7 @@ struct dc_validation_set {
struct dc_stream_state *stream;
/**
-* @plane_state: Surface state
+* @plane_states: Surface state
*/
struct dc_plane_state *plane_states[MAX_SURFACES];
Re: [PATCH] Revert "drm/amd/display: Program OTG vtotal min/max selectors unconditionally for DCN1+"
On 11/07/2023 15:22, Aurabindo Pillai wrote:
> [...]
> Hi,
>
> Sorry for the delayed response, this patch went unnoticed. This revert would
> break asics. Could you try the attached patch without reverting this one ?
Hi Aurabindo, thanks for your response!
I've tried kernel 6.5-rc1, and it seems the issue is present, due to the
patch being merged on Linus tree [as 1598fc576420 ("drm/amd/display:
Program OTG vtotal min/max selectors unconditionally for DCN1+")].
Then, I tried both your attached patches on top of that, and
unfortunately, the behavior is the same: Steam Deck doesn't boot with
graphics, and we can see the single error "amdgpu :04:00.0: [drm]
*ERROR* [CRTC:67:crtc-0] flip_done timed out" on dmesg.
Do you / Alex think we could get this revert for 6.5-rc2, so at least we
could boot mainline there while the issue is handled? It would be an
intermediate fix. You mentioned it breaks some asics, but did they work
until now, without your patch?
Thanks,
Guilherme
Re: scripts/kernel-doc does not handle duplicate struct & function names (e.g., in amdgpu)
On 7/11/23 20:32, Akira Yokosawa wrote:
> Hi Randy,
>
>> [just documenting this for posterity or in case someone wants to fix it.]
>>
>> In drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c, one can find both
>>
>> struct amdgpu_vm_tlb_seq_cb {...};
>>
>> and
>> static void amdgpu_vm_tlb_seq_cb(...)
>>
>> Of course C has no problem with this, but kernel-doc reports:
>>
>> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:833: WARNING: Duplicate C
>> declaration, also defined at gpu/amdgpu/driver-core:115.
>>
>> And of course, if the name of one of them is changed, kernel-doc is all
>> happy...
>> not that I am suggesting that one of them should be changed.
>>
>> I just want to make people aware of this. (or maybe people are already aware
>> of this?)
>
> The duplicate warning is emitted from Sphinx, not kernel-doc.
>
> This is a bug of Sphinx >=3.1, first reported by Mauro back in September 2020
> at:
>
> https://github.com/sphinx-doc/sphinx/issues/8241
>
> It was closed when a local fix was presented. Unfortunately, it was not
> merged at the time and a subsequent pull request was opened at:
>
> https://github.com/sphinx-doc/sphinx/pull/8313
>
> It is not merged yet and carries a milestone of Sphinx 7.x.
>
> Looks like we need to wait patiently.
>
> Thanks, Akira
Ooooh, thanks for your assistance. Waiting :)
--
~Randy
Re: [PATCH] drm/amd/display: Use root connector's colorspace property for MST
On 7/11/23 21:50, Harry Wentland wrote:
> After driver init we shouldn't create new properties. Doing so
> will lead to a warning storm from __drm_mode_object_add.
>
> We don't really need to create the property for MST connectors.
> Re-using the mst_root connector's property is fine.
>
> Signed-off-by: Harry Wentland
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 5722b14a6bec..ba493d325dcb 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -7359,8 +7359,13 @@ void amdgpu_dm_connector_init_helper(struct
> amdgpu_display_manager *dm,
>
> drm_connector_attach_colorspace_property(&aconnector->base);
> } else if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> connector_type == DRM_MODE_CONNECTOR_eDP) {
> - if (!drm_mode_create_dp_colorspace_property(&aconnector->base,
> supported_colorspaces))
> -
> drm_connector_attach_colorspace_property(&aconnector->base);
> + if (!aconnector->mst_root)
> + if
> (!drm_mode_create_dp_colorspace_property(&aconnector->base,
> supported_colorspaces))
> +
> drm_connector_attach_colorspace_property(&aconnector->base);
> + else /* use root connector's property */
> + if (aconnector->mst_root->base.colorspace_property)
> +
> drm_connector_attach_colorspace_property(&aconnector->mst_root->base);
> +
../drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function
‘amdgpu_dm_connector_init_helper’:
../drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:7361:20:
warning: suggest explicit braces to avoid ambiguous ‘else’ [-Wdangling-else]
7361 | if (!aconnector->mst_root)
|^
I think coding style asks for curly braces around both cases as well.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
Re: [PATCH] drm/amdgpu: Rename to amdgpu_vm_tlb_seq_struct
Am 12.07.23 um 08:58 schrieb Luben Tuikov:
Rename struct amdgpu_vm_tlb_seq_cb {...} to struct amdgpu_vm_tlb_seq_struct
{...}, so as to not conflict with documentation processing tools. Of course, C
has no problem with this.
Hui? What exactly is duplicated here? Is the structure defined in
different files with a different meaning?
Christian.
Cc: Randy Dunlap
Cc: Alex Deucher
Cc: Christian König
Link:
https://lore.kernel.org/r/b5ebc891-ee63-1638-0377-7b512d34b...@infradead.org
Signed-off-by: Luben Tuikov
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 92a84e7b0db85b..32adc31c093d84 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -111,9 +111,9 @@ struct amdgpu_prt_cb {
};
/**
- * struct amdgpu_vm_tlb_seq_cb - Helper to increment the TLB flush sequence
+ * struct amdgpu_vm_tlb_seq_struct - Helper to increment the TLB flush sequence
*/
-struct amdgpu_vm_tlb_seq_cb {
+struct amdgpu_vm_tlb_seq_struct {
/**
* @vm: pointer to the amdgpu_vm structure to set the fence sequence on
*/
@@ -833,7 +833,7 @@ int amdgpu_vm_update_pdes(struct amdgpu_device *adev,
static void amdgpu_vm_tlb_seq_cb(struct dma_fence *fence,
struct dma_fence_cb *cb)
{
- struct amdgpu_vm_tlb_seq_cb *tlb_cb;
+ struct amdgpu_vm_tlb_seq_struct *tlb_cb;
tlb_cb = container_of(cb, typeof(*tlb_cb), cb);
atomic64_inc(&tlb_cb->vm->tlb_seq);
@@ -871,7 +871,7 @@ int amdgpu_vm_update_range(struct amdgpu_device *adev,
struct amdgpu_vm *vm,
struct dma_fence **fence)
{
struct amdgpu_vm_update_params params;
- struct amdgpu_vm_tlb_seq_cb *tlb_cb;
+ struct amdgpu_vm_tlb_seq_struct *tlb_cb;
struct amdgpu_res_cursor cursor;
enum amdgpu_sync_mode sync_mode;
int r, idx;
base-commit: 50db2d96b49b7d6cdb12e71e4204cf7180d3bab5
Re: [PATCH] drm/amdgpu: Rename to amdgpu_vm_tlb_seq_struct
On 2023-07-12 03:57, Christian König wrote:
> Am 12.07.23 um 08:58 schrieb Luben Tuikov:
>> Rename struct amdgpu_vm_tlb_seq_cb {...} to struct amdgpu_vm_tlb_seq_struct
>> {...}, so as to not conflict with documentation processing tools. Of course,
>> C
>> has no problem with this.
>
> Hui? What exactly is duplicated here? Is the structure defined in
> different files with a different meaning?
The same name is used for the function and for the structure.
struct amdgpu_vm_tlb_seq_cb {...}
and
static void amdgpu_vm_tlb_seq_cb(struct dma_fence *fence,
struct dma_fence_cb *cb)
C has no problem with this, but document processing tools do,
and in general it doesn't seem like a good practice to have
the same name for both.
Regards,
Luben
>
> Christian.
>
>>
>> Cc: Randy Dunlap
>> Cc: Alex Deucher
>> Cc: Christian König
>> Link:
>> https://lore.kernel.org/r/b5ebc891-ee63-1638-0377-7b512d34b...@infradead.org
>> Signed-off-by: Luben Tuikov
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 8
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> index 92a84e7b0db85b..32adc31c093d84 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> @@ -111,9 +111,9 @@ struct amdgpu_prt_cb {
>> };
>>
>> /**
>> - * struct amdgpu_vm_tlb_seq_cb - Helper to increment the TLB flush sequence
>> + * struct amdgpu_vm_tlb_seq_struct - Helper to increment the TLB flush
>> sequence
>>*/
>> -struct amdgpu_vm_tlb_seq_cb {
>> +struct amdgpu_vm_tlb_seq_struct {
>> /**
>> * @vm: pointer to the amdgpu_vm structure to set the fence sequence on
>> */
>> @@ -833,7 +833,7 @@ int amdgpu_vm_update_pdes(struct amdgpu_device *adev,
>> static void amdgpu_vm_tlb_seq_cb(struct dma_fence *fence,
>> struct dma_fence_cb *cb)
>> {
>> -struct amdgpu_vm_tlb_seq_cb *tlb_cb;
>> +struct amdgpu_vm_tlb_seq_struct *tlb_cb;
>>
>> tlb_cb = container_of(cb, typeof(*tlb_cb), cb);
>> atomic64_inc(&tlb_cb->vm->tlb_seq);
>> @@ -871,7 +871,7 @@ int amdgpu_vm_update_range(struct amdgpu_device *adev,
>> struct amdgpu_vm *vm,
>> struct dma_fence **fence)
>> {
>> struct amdgpu_vm_update_params params;
>> -struct amdgpu_vm_tlb_seq_cb *tlb_cb;
>> +struct amdgpu_vm_tlb_seq_struct *tlb_cb;
>> struct amdgpu_res_cursor cursor;
>> enum amdgpu_sync_mode sync_mode;
>> int r, idx;
>>
>> base-commit: 50db2d96b49b7d6cdb12e71e4204cf7180d3bab5
>
Re: [PATCH v4] drm/amdgpu/vkms: relax timer deactivation by hrtimer_try_to_cancel
Am 12.07.23 um 03:34 schrieb Guchun Chen:
In below thousands of screen rotation loop tests with virtual display
enabled, a CPU hard lockup issue may happen, leading system to unresponsive
and crash.
do {
xrandr --output Virtual --rotate inverted
xrandr --output Virtual --rotate right
xrandr --output Virtual --rotate left
xrandr --output Virtual --rotate normal
} while (1);
NMI watchdog: Watchdog detected hard LOCKUP on cpu 1
? hrtimer_run_softirq+0x140/0x140
? store_vblank+0xe0/0xe0 [drm]
hrtimer_cancel+0x15/0x30
amdgpu_vkms_disable_vblank+0x15/0x30 [amdgpu]
drm_vblank_disable_and_save+0x185/0x1f0 [drm]
drm_crtc_vblank_off+0x159/0x4c0 [drm]
? record_print_text.cold+0x11/0x11
? wait_for_completion_timeout+0x232/0x280
? drm_crtc_wait_one_vblank+0x40/0x40 [drm]
? bit_wait_io_timeout+0xe0/0xe0
? wait_for_completion_interruptible+0x1d7/0x320
? mutex_unlock+0x81/0xd0
amdgpu_vkms_crtc_atomic_disable
It's caused by a stuck in lock dependency in such scenario on different
CPUs.
CPU1 CPU2
drm_crtc_vblank_off hrtimer_interrupt
grab event_lock (irq disabled) __hrtimer_run_queues
grab vbl_lock/vblank_time_block
amdgpu_vkms_vblank_simulate
amdgpu_vkms_disable_vblank drm_handle_vblank
hrtimer_cancel grab
dev->event_lock
So CPU1 stucks in hrtimer_cancel as timer callback is running endless on
current clock base, as that timer queue on CPU2 has no chance to finish it
because of failing to hold the lock. So NMI watchdog will throw the errors
after its threshold, and all later CPUs are impacted/blocked.
So use hrtimer_try_to_cancel to fix this, as disable_vblank callback
does not need to wait the handler to finish. And also it's not necessary
to check the return value of hrtimer_try_to_cancel, because even if it's
-1 which means current timer callback is running, it will be reprogrammed
in hrtimer_start with calling enable_vblank to make it works.
v2: only re-arm timer when vblank is enabled (Christian) and add a Fixes
tag as well
v3: drop warn printing (Christian)
v4: drop superfluous check of blank->enabled in timer function, as it's
guaranteed in drm_handle_vblank (Christian)
Fixes: 84ec374bd580("drm/amdgpu: create amdgpu_vkms (v4)")
Cc: sta...@vger.kernel.org
Suggested-by: Christian König
Signed-off-by: Guchun Chen
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
index 53ff91fc6cf6..d0748bcfad16 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
@@ -55,8 +55,9 @@ static enum hrtimer_restart
amdgpu_vkms_vblank_simulate(struct hrtimer *timer)
DRM_WARN("%s: vblank timer overrun\n", __func__);
ret = drm_crtc_handle_vblank(crtc);
+ /* Don't queue timer again when vblank is disabled. */
if (!ret)
- DRM_ERROR("amdgpu_vkms failure on handling vblank");
+ return HRTIMER_NORESTART;
return HRTIMER_RESTART;
}
@@ -81,7 +82,7 @@ static void amdgpu_vkms_disable_vblank(struct drm_crtc *crtc)
{
struct amdgpu_crtc *amdgpu_crtc = to_amdgpu_crtc(crtc);
- hrtimer_cancel(&amdgpu_crtc->vblank_timer);
+ hrtimer_try_to_cancel(&amdgpu_crtc->vblank_timer);
}
static bool amdgpu_vkms_get_vblank_timestamp(struct drm_crtc *crtc,
Re: [PATCH] drm/amdgpu: Rename to amdgpu_vm_tlb_seq_struct
Am 12.07.23 um 10:03 schrieb Luben Tuikov:
On 2023-07-12 03:57, Christian König wrote:
Am 12.07.23 um 08:58 schrieb Luben Tuikov:
Rename struct amdgpu_vm_tlb_seq_cb {...} to struct amdgpu_vm_tlb_seq_struct
{...}, so as to not conflict with documentation processing tools. Of course, C
has no problem with this.
Hui? What exactly is duplicated here? Is the structure defined in
different files with a different meaning?
The same name is used for the function and for the structure.
Ah, yeah that wasn't obvious.
In this case the patch is Reviewed-by: Christian König
Thanks,
Christian.
struct amdgpu_vm_tlb_seq_cb {...}
and
static void amdgpu_vm_tlb_seq_cb(struct dma_fence *fence,
struct dma_fence_cb *cb)
C has no problem with this, but document processing tools do,
and in general it doesn't seem like a good practice to have
the same name for both.
Regards,
Luben
Christian.
Cc: Randy Dunlap
Cc: Alex Deucher
Cc: Christian König
Link:
https://lore.kernel.org/r/b5ebc891-ee63-1638-0377-7b512d34b...@infradead.org
Signed-off-by: Luben Tuikov
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 92a84e7b0db85b..32adc31c093d84 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -111,9 +111,9 @@ struct amdgpu_prt_cb {
};
/**
- * struct amdgpu_vm_tlb_seq_cb - Helper to increment the TLB flush sequence
+ * struct amdgpu_vm_tlb_seq_struct - Helper to increment the TLB flush sequence
*/
-struct amdgpu_vm_tlb_seq_cb {
+struct amdgpu_vm_tlb_seq_struct {
/**
* @vm: pointer to the amdgpu_vm structure to set the fence sequence on
*/
@@ -833,7 +833,7 @@ int amdgpu_vm_update_pdes(struct amdgpu_device *adev,
static void amdgpu_vm_tlb_seq_cb(struct dma_fence *fence,
struct dma_fence_cb *cb)
{
- struct amdgpu_vm_tlb_seq_cb *tlb_cb;
+ struct amdgpu_vm_tlb_seq_struct *tlb_cb;
tlb_cb = container_of(cb, typeof(*tlb_cb), cb);
atomic64_inc(&tlb_cb->vm->tlb_seq);
@@ -871,7 +871,7 @@ int amdgpu_vm_update_range(struct amdgpu_device *adev,
struct amdgpu_vm *vm,
struct dma_fence **fence)
{
struct amdgpu_vm_update_params params;
- struct amdgpu_vm_tlb_seq_cb *tlb_cb;
+ struct amdgpu_vm_tlb_seq_struct *tlb_cb;
struct amdgpu_res_cursor cursor;
enum amdgpu_sync_mode sync_mode;
int r, idx;
base-commit: 50db2d96b49b7d6cdb12e71e4204cf7180d3bab5
Re: [PATCH 3/6] drm/amdgpu: Rework coredump to use memory dynamically
Am 11.07.23 um 23:34 schrieb André Almeida:
Instead of storing coredump information inside amdgpu_device struct,
move if to a proper separated struct and allocate it dynamically. This
will make it easier to further expand the logged information.
Verry big NAK to this. The problem is that memory allocation isn't
allowed during a GPU reset.
What you could do is to allocate the memory with GFP_ATOMIC or similar,
but for a large structure that might not be possible.
Regards,
Christian.
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 14 +++--
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 65 ++
2 files changed, 51 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index dbe062a087c5..e1cc83a89d46 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1068,11 +1068,6 @@ struct amdgpu_device {
uint32_t*reset_dump_reg_list;
uint32_t*reset_dump_reg_value;
int num_regs;
-#ifdef CONFIG_DEV_COREDUMP
- struct amdgpu_task_info reset_task_info;
- boolreset_vram_lost;
- struct timespec64 reset_time;
-#endif
boolscpm_enabled;
uint32_tscpm_status;
@@ -1085,6 +1080,15 @@ struct amdgpu_device {
uint32_taid_mask;
};
+#ifdef CONFIG_DEV_COREDUMP
+struct amdgpu_coredump_info {
+ struct amdgpu_device*adev;
+ struct amdgpu_task_info reset_task_info;
+ struct timespec64 reset_time;
+ boolreset_vram_lost;
+};
+#endif
+
static inline struct amdgpu_device *drm_to_adev(struct drm_device *ddev)
{
return container_of(ddev, struct amdgpu_device, ddev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index e25f085ee886..23b9784e9787 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4963,12 +4963,17 @@ static int amdgpu_reset_reg_dumps(struct amdgpu_device
*adev)
return 0;
}
-#ifdef CONFIG_DEV_COREDUMP
+#ifndef CONFIG_DEV_COREDUMP
+static void amdgpu_coredump(struct amdgpu_device *adev, bool vram_lost,
+ struct amdgpu_reset_context *reset_context)
+{
+}
+#else
static ssize_t amdgpu_devcoredump_read(char *buffer, loff_t offset,
size_t count, void *data, size_t datalen)
{
struct drm_printer p;
- struct amdgpu_device *adev = data;
+ struct amdgpu_coredump_info *coredump = data;
struct drm_print_iterator iter;
int i;
@@ -4982,21 +4987,21 @@ static ssize_t amdgpu_devcoredump_read(char *buffer, loff_t offset,
drm_printf(&p, " AMDGPU Device Coredump \n");
drm_printf(&p, "kernel: " UTS_RELEASE "\n");
drm_printf(&p, "module: " KBUILD_MODNAME "\n");
- drm_printf(&p, "time: %lld.%09ld\n", adev->reset_time.tv_sec,
adev->reset_time.tv_nsec);
- if (adev->reset_task_info.pid)
+ drm_printf(&p, "time: %lld.%09ld\n", coredump->reset_time.tv_sec,
coredump->reset_time.tv_nsec);
+ if (coredump->reset_task_info.pid)
drm_printf(&p, "process_name: %s PID: %d\n",
- adev->reset_task_info.process_name,
- adev->reset_task_info.pid);
+ coredump->reset_task_info.process_name,
+ coredump->reset_task_info.pid);
- if (adev->reset_vram_lost)
+ if (coredump->reset_vram_lost)
drm_printf(&p, "VRAM is lost due to GPU reset!\n");
- if (adev->num_regs) {
+ if (coredump->adev->num_regs) {
drm_printf(&p, "AMDGPU register dumps:\nOffset: Value:\n");
- for (i = 0; i < adev->num_regs; i++)
+ for (i = 0; i < coredump->adev->num_regs; i++)
drm_printf(&p, "0x%08x: 0x%08x\n",
- adev->reset_dump_reg_list[i],
- adev->reset_dump_reg_value[i]);
+ coredump->adev->reset_dump_reg_list[i],
+ coredump->adev->reset_dump_reg_value[i]);
}
return count - iter.remain;
@@ -5004,14 +5009,34 @@ static ssize_t amdgpu_devcoredump_read(char *buffer,
loff_t offset,
static void amdgpu_devcoredump_free(void *data)
{
+ kfree(data);
}
-static void amdgpu_reset_capture_coredumpm(struct amdgpu_device *adev)
+static void amdgpu_coredump(struct amdgpu_device *adev, bool vram_lost,
+ struct amdgpu_reset_context *reset_context)
{
+ struct amdgpu_coredump_info *coredump;
struct drm_device *dev = ad
Re: [PATCH 2/6] drm/amdgpu: Mark contexts guilty for causing soft recoveries
Am 11.07.23 um 23:34 schrieb André Almeida:
If a DRM fence is set to -ENODATA, that means that this context was a
cause of a soft reset, but is never marked as guilty. Flag it as guilty
and log to user that this context won't accept more submissions.
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
index 0dc9c655c4fb..fe8e47d063da 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
@@ -459,6 +459,12 @@ int amdgpu_ctx_get_entity(struct amdgpu_ctx *ctx, u32
hw_ip, u32 instance,
ctx_entity = &ctx->entities[hw_ip][ring]->entity;
r = drm_sched_entity_error(ctx_entity);
if (r) {
+ if (r == -ENODATA) {
+ DRM_ERROR("%s (%d) context caused a reset,"
+ "marking it guilty and refusing new
submissions.\n",
+ current->comm, current->pid);
+ atomic_set(&ctx->guilty, 1);
+ }
I'm going back and forth with that as well.
Michel has a very good point that it often is sufficient to cancel just
one rough shader to keep going.
But Marek has a very good point as well that when that happens multiple
times we probably want to block the application from making further
submissions.
Christian.
DRM_DEBUG("error entity %p\n", ctx_entity);
return r;
}
Re: [PATCH 3/6] drm/amdgpu: Rework coredump to use memory dynamically
Am Mittwoch, dem 12.07.2023 um 10:37 +0200 schrieb Christian König:
> Am 11.07.23 um 23:34 schrieb André Almeida:
> > Instead of storing coredump information inside amdgpu_device struct,
> > move if to a proper separated struct and allocate it dynamically. This
> > will make it easier to further expand the logged information.
>
> Verry big NAK to this. The problem is that memory allocation isn't
> allowed during a GPU reset.
>
> What you could do is to allocate the memory with GFP_ATOMIC or similar,
> but for a large structure that might not be possible.
>
I'm still not fully clear on what the rules are here. In etnaviv we do
devcoredump allocation in the GPU reset path with __GFP_NOWARN |
__GFP_NORETRY, which means the allocation will kick memory reclaim if
necessary, but will just give up if no memory could be made available
easily. This satisfies the forward progress guarantee in the absence of
successful memory allocation, which is the most important property in
this path, I think.
However, I'm not sure if the reclaim could lead to locking issues or
something like that with the more complex use-cases with MMU notifiers
and stuff like that. Christian, do you have any experience or
information that would be good to share in this regard?
Regards,
Lucas
> Regards,
> Christian.
>
> >
> > Signed-off-by: André Almeida
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu.h| 14 +++--
> > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 65 ++
> > 2 files changed, 51 insertions(+), 28 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > index dbe062a087c5..e1cc83a89d46 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > @@ -1068,11 +1068,6 @@ struct amdgpu_device {
> > uint32_t*reset_dump_reg_list;
> > uint32_t*reset_dump_reg_value;
> > int num_regs;
> > -#ifdef CONFIG_DEV_COREDUMP
> > - struct amdgpu_task_info reset_task_info;
> > - boolreset_vram_lost;
> > - struct timespec64 reset_time;
> > -#endif
> >
> > boolscpm_enabled;
> > uint32_tscpm_status;
> > @@ -1085,6 +1080,15 @@ struct amdgpu_device {
> > uint32_taid_mask;
> > };
> >
> > +#ifdef CONFIG_DEV_COREDUMP
> > +struct amdgpu_coredump_info {
> > + struct amdgpu_device*adev;
> > + struct amdgpu_task_info reset_task_info;
> > + struct timespec64 reset_time;
> > + boolreset_vram_lost;
> > +};
> > +#endif
> > +
> > static inline struct amdgpu_device *drm_to_adev(struct drm_device *ddev)
> > {
> > return container_of(ddev, struct amdgpu_device, ddev);
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > index e25f085ee886..23b9784e9787 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > @@ -4963,12 +4963,17 @@ static int amdgpu_reset_reg_dumps(struct
> > amdgpu_device *adev)
> > return 0;
> > }
> >
> > -#ifdef CONFIG_DEV_COREDUMP
> > +#ifndef CONFIG_DEV_COREDUMP
> > +static void amdgpu_coredump(struct amdgpu_device *adev, bool vram_lost,
> > + struct amdgpu_reset_context *reset_context)
> > +{
> > +}
> > +#else
> > static ssize_t amdgpu_devcoredump_read(char *buffer, loff_t offset,
> > size_t count, void *data, size_t datalen)
> > {
> > struct drm_printer p;
> > - struct amdgpu_device *adev = data;
> > + struct amdgpu_coredump_info *coredump = data;
> > struct drm_print_iterator iter;
> > int i;
> >
> > @@ -4982,21 +4987,21 @@ static ssize_t amdgpu_devcoredump_read(char
> > *buffer, loff_t offset,
> > drm_printf(&p, " AMDGPU Device Coredump \n");
> > drm_printf(&p, "kernel: " UTS_RELEASE "\n");
> > drm_printf(&p, "module: " KBUILD_MODNAME "\n");
> > - drm_printf(&p, "time: %lld.%09ld\n", adev->reset_time.tv_sec,
> > adev->reset_time.tv_nsec);
> > - if (adev->reset_task_info.pid)
> > + drm_printf(&p, "time: %lld.%09ld\n", coredump->reset_time.tv_sec,
> > coredump->reset_time.tv_nsec);
> > + if (coredump->reset_task_info.pid)
> > drm_printf(&p, "process_name: %s PID: %d\n",
> > - adev->reset_task_info.process_name,
> > - adev->reset_task_info.pid);
> > + coredump->reset_task_info.process_name,
> > + coredump->reset_task_info.pid);
> >
> > - if (adev->reset_vram_lost)
> > + if (coredump->reset_vram_lost)
> > drm_printf(&p, "VRAM is lost due to GPU reset!\n");
> > - if (adev->num_regs) {
> > + if (coredump->adev->num_regs) {
> > drm_printf(&p, "AMDGPU regist
Re: [PATCH 3/6] drm/amdgpu: Rework coredump to use memory dynamically
Am 12.07.23 um 10:59 schrieb Lucas Stach:
Am Mittwoch, dem 12.07.2023 um 10:37 +0200 schrieb Christian König:
Am 11.07.23 um 23:34 schrieb André Almeida:
Instead of storing coredump information inside amdgpu_device struct,
move if to a proper separated struct and allocate it dynamically. This
will make it easier to further expand the logged information.
Verry big NAK to this. The problem is that memory allocation isn't
allowed during a GPU reset.
What you could do is to allocate the memory with GFP_ATOMIC or similar,
but for a large structure that might not be possible.
I'm still not fully clear on what the rules are here. In etnaviv we do
devcoredump allocation in the GPU reset path with __GFP_NOWARN |
__GFP_NORETRY, which means the allocation will kick memory reclaim if
necessary, but will just give up if no memory could be made available
easily. This satisfies the forward progress guarantee in the absence of
successful memory allocation, which is the most important property in
this path, I think.
However, I'm not sure if the reclaim could lead to locking issues or
something like that with the more complex use-cases with MMU notifiers
and stuff like that. Christian, do you have any experience or
information that would be good to share in this regard?
Yeah, very good question.
__GFP_NORETRY isn't sufficient as far as I know. Reclaim must be
completely suppressed to be able to allocate in a GPU reset handler.
Daniel added lockdep annotation to some of the dma-fence signaling paths
and this yielded quite a bunch of potential deadlocks.
It's not even that reclaim itself waits for dma_fences (that can happen,
but is quite unlikely), but rather that reclaim needs locks and under
those locks we then wait for dma_fences.
We should probably add a define somewhere which documents that
(GFP_ATOMIC | __NO_WARN) should be used in the GPU reset handlers when
allocating memory for coredumps.
Regards,
Christian.
Regards,
Lucas
Regards,
Christian.
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 14 +++--
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 65 ++
2 files changed, 51 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index dbe062a087c5..e1cc83a89d46 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1068,11 +1068,6 @@ struct amdgpu_device {
uint32_t*reset_dump_reg_list;
uint32_t*reset_dump_reg_value;
int num_regs;
-#ifdef CONFIG_DEV_COREDUMP
- struct amdgpu_task_info reset_task_info;
- boolreset_vram_lost;
- struct timespec64 reset_time;
-#endif
boolscpm_enabled;
uint32_tscpm_status;
@@ -1085,6 +1080,15 @@ struct amdgpu_device {
uint32_taid_mask;
};
+#ifdef CONFIG_DEV_COREDUMP
+struct amdgpu_coredump_info {
+ struct amdgpu_device*adev;
+ struct amdgpu_task_info reset_task_info;
+ struct timespec64 reset_time;
+ boolreset_vram_lost;
+};
+#endif
+
static inline struct amdgpu_device *drm_to_adev(struct drm_device *ddev)
{
return container_of(ddev, struct amdgpu_device, ddev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index e25f085ee886..23b9784e9787 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4963,12 +4963,17 @@ static int amdgpu_reset_reg_dumps(struct amdgpu_device
*adev)
return 0;
}
-#ifdef CONFIG_DEV_COREDUMP
+#ifndef CONFIG_DEV_COREDUMP
+static void amdgpu_coredump(struct amdgpu_device *adev, bool vram_lost,
+ struct amdgpu_reset_context *reset_context)
+{
+}
+#else
static ssize_t amdgpu_devcoredump_read(char *buffer, loff_t offset,
size_t count, void *data, size_t datalen)
{
struct drm_printer p;
- struct amdgpu_device *adev = data;
+ struct amdgpu_coredump_info *coredump = data;
struct drm_print_iterator iter;
int i;
@@ -4982,21 +4987,21 @@ static ssize_t amdgpu_devcoredump_read(char *buffer, loff_t offset,
drm_printf(&p, " AMDGPU Device Coredump \n");
drm_printf(&p, "kernel: " UTS_RELEASE "\n");
drm_printf(&p, "module: " KBUILD_MODNAME "\n");
- drm_printf(&p, "time: %lld.%09ld\n", adev->reset_time.tv_sec,
adev->reset_time.tv_nsec);
- if (adev->reset_task_info.pid)
+ drm_printf(&p, "time: %lld.%09ld\n", coredump->reset_time.tv_sec,
coredump->reset_time.tv_nsec);
+ if (coredump->reset_task_info.pid)
drm_printf(&p, "process_name: %s PID: %d\n"
Re: [PATCH 3/6] drm/amdgpu: Rework coredump to use memory dynamically
Am Mittwoch, dem 12.07.2023 um 12:39 +0200 schrieb Christian König:
> Am 12.07.23 um 10:59 schrieb Lucas Stach:
> > Am Mittwoch, dem 12.07.2023 um 10:37 +0200 schrieb Christian König:
> > > Am 11.07.23 um 23:34 schrieb André Almeida:
> > > > Instead of storing coredump information inside amdgpu_device struct,
> > > > move if to a proper separated struct and allocate it dynamically. This
> > > > will make it easier to further expand the logged information.
> > > Verry big NAK to this. The problem is that memory allocation isn't
> > > allowed during a GPU reset.
> > >
> > > What you could do is to allocate the memory with GFP_ATOMIC or similar,
> > > but for a large structure that might not be possible.
> > >
> > I'm still not fully clear on what the rules are here. In etnaviv we do
> > devcoredump allocation in the GPU reset path with __GFP_NOWARN |
> > __GFP_NORETRY, which means the allocation will kick memory reclaim if
> > necessary, but will just give up if no memory could be made available
> > easily. This satisfies the forward progress guarantee in the absence of
> > successful memory allocation, which is the most important property in
> > this path, I think.
> >
> > However, I'm not sure if the reclaim could lead to locking issues or
> > something like that with the more complex use-cases with MMU notifiers
> > and stuff like that. Christian, do you have any experience or
> > information that would be good to share in this regard?
>
> Yeah, very good question.
>
> __GFP_NORETRY isn't sufficient as far as I know. Reclaim must be
> completely suppressed to be able to allocate in a GPU reset handler.
>
> Daniel added lockdep annotation to some of the dma-fence signaling paths
> and this yielded quite a bunch of potential deadlocks.
>
> It's not even that reclaim itself waits for dma_fences (that can happen,
> but is quite unlikely), but rather that reclaim needs locks and under
> those locks we then wait for dma_fences.
>
> We should probably add a define somewhere which documents that
> (GFP_ATOMIC | __NO_WARN) should be used in the GPU reset handlers when
> allocating memory for coredumps.
>
> Regards,
> Christian.
>
> >
> > Regards,
> > Lucas
> >
> > > Regards,
> > > Christian.
> > >
> > > > Signed-off-by: André Almeida
> > > > ---
> > > >drivers/gpu/drm/amd/amdgpu/amdgpu.h| 14 +++--
> > > >drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 65
> > > > ++
> > > >2 files changed, 51 insertions(+), 28 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > > > index dbe062a087c5..e1cc83a89d46 100644
> > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > > > @@ -1068,11 +1068,6 @@ struct amdgpu_device {
> > > > uint32_t*reset_dump_reg_list;
> > > > uint32_t*reset_dump_reg_value;
> > > > int num_regs;
> > > > -#ifdef CONFIG_DEV_COREDUMP
> > > > - struct amdgpu_task_info reset_task_info;
> > > > - boolreset_vram_lost;
> > > > - struct timespec64 reset_time;
> > > > -#endif
> > > >
> > > > boolscpm_enabled;
> > > > uint32_tscpm_status;
> > > > @@ -1085,6 +1080,15 @@ struct amdgpu_device {
> > > > uint32_taid_mask;
> > > >};
> > > >
> > > > +#ifdef CONFIG_DEV_COREDUMP
> > > > +struct amdgpu_coredump_info {
> > > > + struct amdgpu_device*adev;
> > > > + struct amdgpu_task_info reset_task_info;
> > > > + struct timespec64 reset_time;
> > > > + boolreset_vram_lost;
> > > > +};
> > > > +#endif
> > > > +
> > > >static inline struct amdgpu_device *drm_to_adev(struct drm_device
> > > > *ddev)
> > > >{
> > > > return container_of(ddev, struct amdgpu_device, ddev);
> > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > > index e25f085ee886..23b9784e9787 100644
> > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > > @@ -4963,12 +4963,17 @@ static int amdgpu_reset_reg_dumps(struct
> > > > amdgpu_device *adev)
> > > > return 0;
> > > >}
> > > >
> > > > -#ifdef CONFIG_DEV_COREDUMP
> > > > +#ifndef CONFIG_DEV_COREDUMP
> > > > +static void amdgpu_coredump(struct amdgpu_device *adev, bool vram_lost,
> > > > + struct amdgpu_reset_context *reset_context)
> > > > +{
> > > > +}
> > > > +#else
> > > >static ssize_t amdgpu_devcoredump_read(char *buffer, loff_t offset,
> > > > size_t count, void *data, size_t datalen)
> > > >{
> > > > struct drm_printer p;
> > > > - st
Re: [PATCH 3/6] drm/amdgpu: Rework coredump to use memory dynamically
Sorry, accidentally hit sent on the previous mail.
Am Mittwoch, dem 12.07.2023 um 12:39 +0200 schrieb Christian König:
> Am 12.07.23 um 10:59 schrieb Lucas Stach:
> > Am Mittwoch, dem 12.07.2023 um 10:37 +0200 schrieb Christian König:
> > > Am 11.07.23 um 23:34 schrieb André Almeida:
> > > > Instead of storing coredump information inside amdgpu_device struct,
> > > > move if to a proper separated struct and allocate it dynamically. This
> > > > will make it easier to further expand the logged information.
> > > Verry big NAK to this. The problem is that memory allocation isn't
> > > allowed during a GPU reset.
> > >
> > > What you could do is to allocate the memory with GFP_ATOMIC or similar,
> > > but for a large structure that might not be possible.
> > >
> > I'm still not fully clear on what the rules are here. In etnaviv we do
> > devcoredump allocation in the GPU reset path with __GFP_NOWARN |
> > __GFP_NORETRY, which means the allocation will kick memory reclaim if
> > necessary, but will just give up if no memory could be made available
> > easily. This satisfies the forward progress guarantee in the absence of
> > successful memory allocation, which is the most important property in
> > this path, I think.
> >
> > However, I'm not sure if the reclaim could lead to locking issues or
> > something like that with the more complex use-cases with MMU notifiers
> > and stuff like that. Christian, do you have any experience or
> > information that would be good to share in this regard?
>
> Yeah, very good question.
>
> __GFP_NORETRY isn't sufficient as far as I know. Reclaim must be
> completely suppressed to be able to allocate in a GPU reset handler.
>
> Daniel added lockdep annotation to some of the dma-fence signaling paths
> and this yielded quite a bunch of potential deadlocks.
>
> It's not even that reclaim itself waits for dma_fences (that can happen,
> but is quite unlikely), but rather that reclaim needs locks and under
> those locks we then wait for dma_fences.
>
> We should probably add a define somewhere which documents that
> (GFP_ATOMIC | __NO_WARN) should be used in the GPU reset handlers when
> allocating memory for coredumps.
>
Hm, if the problem is the direct reclaim path where we might recurse on
a lock through those indirect dependencies then we should document this
somewhere. kswapd reclaim should be fine as far as I can see, as we'll
guarantee progress without waiting for the background reclaim.
I don't think it's appropriate to dip into the atomic allocation
reserves for a best-effort thing like writing the devcoredump, so I
think this should be GFP_NOWAIT, which will also avoid the direct
reclaim path.
Regards,
Lucas
> Regards,
> Christian.
>
> >
> > Regards,
> > Lucas
> >
> > > Regards,
> > > Christian.
> > >
> > > > Signed-off-by: André Almeida
> > > > ---
> > > >drivers/gpu/drm/amd/amdgpu/amdgpu.h| 14 +++--
> > > >drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 65
> > > > ++
> > > >2 files changed, 51 insertions(+), 28 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > > > index dbe062a087c5..e1cc83a89d46 100644
> > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > > > @@ -1068,11 +1068,6 @@ struct amdgpu_device {
> > > > uint32_t*reset_dump_reg_list;
> > > > uint32_t*reset_dump_reg_value;
> > > > int num_regs;
> > > > -#ifdef CONFIG_DEV_COREDUMP
> > > > - struct amdgpu_task_info reset_task_info;
> > > > - boolreset_vram_lost;
> > > > - struct timespec64 reset_time;
> > > > -#endif
> > > >
> > > > boolscpm_enabled;
> > > > uint32_tscpm_status;
> > > > @@ -1085,6 +1080,15 @@ struct amdgpu_device {
> > > > uint32_taid_mask;
> > > >};
> > > >
> > > > +#ifdef CONFIG_DEV_COREDUMP
> > > > +struct amdgpu_coredump_info {
> > > > + struct amdgpu_device*adev;
> > > > + struct amdgpu_task_info reset_task_info;
> > > > + struct timespec64 reset_time;
> > > > + boolreset_vram_lost;
> > > > +};
> > > > +#endif
> > > > +
> > > >static inline struct amdgpu_device *drm_to_adev(struct drm_device
> > > > *ddev)
> > > >{
> > > > return container_of(ddev, struct amdgpu_device, ddev);
> > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > > index e25f085ee886..23b9784e9787 100644
> > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > > @@ -4963,12 +4963,17 @@ static int amdgpu_reset_reg_dumps(struct
> >
Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
Uwe Kleine-König writes: [dropping some recipients since my SMTP server was complaining about the size] > Hello Thomas, > > On Wed, Jul 12, 2023 at 12:19:37PM +0200, Thomas Zimmermann wrote: >> Am 12.07.23 um 11:46 schrieb Uwe Kleine-König: >> > Hello, >> > >> > while I debugged an issue in the imx-lcdc driver I was constantly >> > irritated about struct drm_device pointer variables being named "dev" >> > because with that name I usually expect a struct device pointer. >> > >> > I think there is a big benefit when these are all renamed to "drm_dev". >> >> If you rename drm_crtc.dev, you should also address *all* other data >> structures. > > Yes. Changing drm_crtc::dev was some effort, so I thought to send that > one out before doing the same to > > drm_dp_mst_topology_mgr > drm_atomic_state > drm_master > drm_bridge > drm_client_dev > drm_connector > drm_debugfs_entry > drm_encoder > drm_fb_helper > drm_minor > drm_framebuffer > drm_gem_object > drm_plane > drm_property > drm_property_blob > drm_vblank_crtc > > when in the end the intention isn't welcome. > >> > I have no strong preference here though, so "drmdev" or "drm" are fine >> > for me, too. Let the bikesheding begin! >> >> We've discussed this to death. IIRC 'drm' would be the prefered choice. > > "drm" at least has the advantage to be the 2nd most common name. With > Paul Kocialkowski prefering "drm_dev" there is no clear favourite yet. I think that either "drm" or "drm_dev" would be more clear than "dev", which I also found it confusing and thinking about a "struct device". Probably leaning to "drm", since as you said is the second most used name in drivers that assign crtc->dev to a local variable. > Maybe all the other people with strong opinions are dead if this was > "discussed to death" before? :-) > > Best regards > Uwe > > -- > Pengutronix e.K. | Uwe Kleine-König| > Industrial Linux Solutions | https://www.pengutronix.de/ | -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 3/6] drm/amdgpu: Rework coredump to use memory dynamically
Am 12.07.23 um 12:56 schrieb Lucas Stach:
Sorry, accidentally hit sent on the previous mail.
Am Mittwoch, dem 12.07.2023 um 12:39 +0200 schrieb Christian König:
Am 12.07.23 um 10:59 schrieb Lucas Stach:
Am Mittwoch, dem 12.07.2023 um 10:37 +0200 schrieb Christian König:
Am 11.07.23 um 23:34 schrieb André Almeida:
Instead of storing coredump information inside amdgpu_device struct,
move if to a proper separated struct and allocate it dynamically. This
will make it easier to further expand the logged information.
Verry big NAK to this. The problem is that memory allocation isn't
allowed during a GPU reset.
What you could do is to allocate the memory with GFP_ATOMIC or similar,
but for a large structure that might not be possible.
I'm still not fully clear on what the rules are here. In etnaviv we do
devcoredump allocation in the GPU reset path with __GFP_NOWARN |
__GFP_NORETRY, which means the allocation will kick memory reclaim if
necessary, but will just give up if no memory could be made available
easily. This satisfies the forward progress guarantee in the absence of
successful memory allocation, which is the most important property in
this path, I think.
However, I'm not sure if the reclaim could lead to locking issues or
something like that with the more complex use-cases with MMU notifiers
and stuff like that. Christian, do you have any experience or
information that would be good to share in this regard?
Yeah, very good question.
__GFP_NORETRY isn't sufficient as far as I know. Reclaim must be
completely suppressed to be able to allocate in a GPU reset handler.
Daniel added lockdep annotation to some of the dma-fence signaling paths
and this yielded quite a bunch of potential deadlocks.
It's not even that reclaim itself waits for dma_fences (that can happen,
but is quite unlikely), but rather that reclaim needs locks and under
those locks we then wait for dma_fences.
We should probably add a define somewhere which documents that
(GFP_ATOMIC | __NO_WARN) should be used in the GPU reset handlers when
allocating memory for coredumps.
Hm, if the problem is the direct reclaim path where we might recurse on
a lock through those indirect dependencies then we should document this
somewhere. kswapd reclaim should be fine as far as I can see, as we'll
guarantee progress without waiting for the background reclaim.
I don't think it's appropriate to dip into the atomic allocation
reserves for a best-effort thing like writing the devcoredump,
Yeah, that was also my concern the last time we discussed this.
so I think this should be GFP_NOWAIT, which will also avoid the direct
reclaim path.
Yeah, good idea. I wasn't aware that this existed.
Regards,
Christian.
Regards,
Lucas
Regards,
Christian.
Regards,
Lucas
Regards,
Christian.
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 14 +++--
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 65 ++
2 files changed, 51 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index dbe062a087c5..e1cc83a89d46 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1068,11 +1068,6 @@ struct amdgpu_device {
uint32_t*reset_dump_reg_list;
uint32_t*reset_dump_reg_value;
int num_regs;
-#ifdef CONFIG_DEV_COREDUMP
- struct amdgpu_task_info reset_task_info;
- boolreset_vram_lost;
- struct timespec64 reset_time;
-#endif
boolscpm_enabled;
uint32_tscpm_status;
@@ -1085,6 +1080,15 @@ struct amdgpu_device {
uint32_taid_mask;
};
+#ifdef CONFIG_DEV_COREDUMP
+struct amdgpu_coredump_info {
+ struct amdgpu_device*adev;
+ struct amdgpu_task_info reset_task_info;
+ struct timespec64 reset_time;
+ boolreset_vram_lost;
+};
+#endif
+
static inline struct amdgpu_device *drm_to_adev(struct drm_device *ddev)
{
return container_of(ddev, struct amdgpu_device, ddev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index e25f085ee886..23b9784e9787 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4963,12 +4963,17 @@ static int amdgpu_reset_reg_dumps(struct amdgpu_device
*adev)
return 0;
}
-#ifdef CONFIG_DEV_COREDUMP
+#ifndef CONFIG_DEV_COREDUMP
+static void amdgpu_coredump(struct amdgpu_device *adev, bool vram_lost,
+ struct amdgpu_reset_context *reset_context)
+{
+}
+#else
static ssize_t amdgpu_devcoredump_read(char *buffer, loff_t offset,
size_t count, void *dat
[PATCH] drm/amdgpu: replace 1-element arrays with flexible arrays
UBSAN complains about out-of-bounds array indexes on all 1-element
arrays defined on this driver:
UBSAN: array-index-out-of-bounds in
/home/rcn/work/repos/kernelci/kernelci-core/linux_kernel_mainline/drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/processpptables.c:1249:61
Substitute them with proper flexible arrays.
Tested on an Acer R721T (grunt) Chromebook.
Signed-off-by: Ricardo Cañuelo
---
drivers/gpu/drm/amd/include/pptable.h | 36 +++
1 file changed, 20 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/include/pptable.h
b/drivers/gpu/drm/amd/include/pptable.h
index 0b6a057e0a4c..a65e2807dc06 100644
--- a/drivers/gpu/drm/amd/include/pptable.h
+++ b/drivers/gpu/drm/amd/include/pptable.h
@@ -473,14 +473,14 @@ typedef struct _ATOM_PPLIB_STATE_V2
/**
* Driver will read the first ucNumDPMLevels in this array
*/
- UCHAR clockInfoIndex[1];
+ __DECLARE_FLEX_ARRAY(UCHAR, clockInfoIndex);
} ATOM_PPLIB_STATE_V2;
typedef struct _StateArray{
//how many states we have
UCHAR ucNumEntries;
-ATOM_PPLIB_STATE_V2 states[1];
+__DECLARE_FLEX_ARRAY(ATOM_PPLIB_STATE_V2, states);
}StateArray;
@@ -491,7 +491,7 @@ typedef struct _ClockInfoArray{
//sizeof(ATOM_PPLIB_CLOCK_INFO)
UCHAR ucEntrySize;
-UCHAR clockInfo[1];
+__DECLARE_FLEX_ARRAY(UCHAR, clockInfo);
}ClockInfoArray;
typedef struct _NonClockInfoArray{
@@ -501,7 +501,7 @@ typedef struct _NonClockInfoArray{
//sizeof(ATOM_PPLIB_NONCLOCK_INFO)
UCHAR ucEntrySize;
-ATOM_PPLIB_NONCLOCK_INFO nonClockInfo[1];
+__DECLARE_FLEX_ARRAY(ATOM_PPLIB_NONCLOCK_INFO, nonClockInfo);
}NonClockInfoArray;
typedef struct _ATOM_PPLIB_Clock_Voltage_Dependency_Record
@@ -514,7 +514,8 @@ typedef struct _ATOM_PPLIB_Clock_Voltage_Dependency_Record
typedef struct _ATOM_PPLIB_Clock_Voltage_Dependency_Table
{
UCHAR ucNumEntries;//
Number of entries.
-ATOM_PPLIB_Clock_Voltage_Dependency_Record entries[1]; //
Dynamically allocate entries.
+/* Dynamically allocate entries. */
+__DECLARE_FLEX_ARRAY(ATOM_PPLIB_Clock_Voltage_Dependency_Record, entries);
}ATOM_PPLIB_Clock_Voltage_Dependency_Table;
typedef struct _ATOM_PPLIB_Clock_Voltage_Limit_Record
@@ -530,7 +531,8 @@ typedef struct _ATOM_PPLIB_Clock_Voltage_Limit_Record
typedef struct _ATOM_PPLIB_Clock_Voltage_Limit_Table
{
UCHAR ucNumEntries;//
Number of entries.
-ATOM_PPLIB_Clock_Voltage_Limit_Record entries[1]; //
Dynamically allocate entries.
+/* Dynamically allocate entries. */
+__DECLARE_FLEX_ARRAY(ATOM_PPLIB_Clock_Voltage_Limit_Record, entries);
}ATOM_PPLIB_Clock_Voltage_Limit_Table;
union _ATOM_PPLIB_CAC_Leakage_Record
@@ -554,7 +556,8 @@ typedef union _ATOM_PPLIB_CAC_Leakage_Record
ATOM_PPLIB_CAC_Leakage_Record;
typedef struct _ATOM_PPLIB_CAC_Leakage_Table
{
UCHAR ucNumEntries; //
Number of entries.
-ATOM_PPLIB_CAC_Leakage_Record entries[1]; //
Dynamically allocate entries.
+/* Dynamically allocate entries. */
+__DECLARE_FLEX_ARRAY(ATOM_PPLIB_CAC_Leakage_Record, entries);
}ATOM_PPLIB_CAC_Leakage_Table;
typedef struct _ATOM_PPLIB_PhaseSheddingLimits_Record
@@ -569,7 +572,8 @@ typedef struct _ATOM_PPLIB_PhaseSheddingLimits_Record
typedef struct _ATOM_PPLIB_PhaseSheddingLimits_Table
{
UCHAR ucNumEntries; //
Number of entries.
-ATOM_PPLIB_PhaseSheddingLimits_Record entries[1]; //
Dynamically allocate entries.
+/* Dynamically allocate entries. */
+__DECLARE_FLEX_ARRAY(ATOM_PPLIB_PhaseSheddingLimits_Record, entries);
}ATOM_PPLIB_PhaseSheddingLimits_Table;
typedef struct _VCEClockInfo{
@@ -581,7 +585,7 @@ typedef struct _VCEClockInfo{
typedef struct _VCEClockInfoArray{
UCHAR ucNumEntries;
-VCEClockInfo entries[1];
+__DECLARE_FLEX_ARRAY(VCEClockInfo, entries);
}VCEClockInfoArray;
typedef struct _ATOM_PPLIB_VCE_Clock_Voltage_Limit_Record
@@ -593,7 +597,7 @@ typedef struct _ATOM_PPLIB_VCE_Clock_Voltage_Limit_Record
typedef struct _ATOM_PPLIB_VCE_Clock_Voltage_Limit_Table
{
UCHAR numEntries;
-ATOM_PPLIB_VCE_Clock_Voltage_Limit_Record entries[1];
+__DECLARE_FLEX_ARRAY(ATOM_PPLIB_VCE_Clock_Voltage_Limit_Record, entries);
}ATOM_PPLIB_VCE_Clock_Voltage_Limit_Table;
typedef struct _ATOM_PPLIB_VCE_State_Record
@@ -605,7 +609,7 @@ typedef struct _ATOM_PPLIB_VCE_State_Record
typedef struct _ATOM_PPLIB_VCE_State_Table
{
UCHAR numEntries;
-ATOM_PPLIB_VCE_State_Record entries[1];
+__DECLARE_FLEX_ARRAY(ATOM_PPLIB_VCE_State_Record, entries);
}ATOM_PPLIB_VCE_State_Table;
@@ -627,7 +631,7 @@ typedef struct _UVDClockInfo{
typedef struct _UVDClockInfoArray{
UCHAR ucNumEntries;
-UVD
Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
Hello Thomas, On Wed, Jul 12, 2023 at 12:19:37PM +0200, Thomas Zimmermann wrote: > Am 12.07.23 um 11:46 schrieb Uwe Kleine-König: > > Hello, > > > > while I debugged an issue in the imx-lcdc driver I was constantly > > irritated about struct drm_device pointer variables being named "dev" > > because with that name I usually expect a struct device pointer. > > > > I think there is a big benefit when these are all renamed to "drm_dev". > > If you rename drm_crtc.dev, you should also address *all* other data > structures. Yes. Changing drm_crtc::dev was some effort, so I thought to send that one out before doing the same to drm_dp_mst_topology_mgr drm_atomic_state drm_master drm_bridge drm_client_dev drm_connector drm_debugfs_entry drm_encoder drm_fb_helper drm_minor drm_framebuffer drm_gem_object drm_plane drm_property drm_property_blob drm_vblank_crtc when in the end the intention isn't welcome. > > I have no strong preference here though, so "drmdev" or "drm" are fine > > for me, too. Let the bikesheding begin! > > We've discussed this to death. IIRC 'drm' would be the prefered choice. "drm" at least has the advantage to be the 2nd most common name. With Paul Kocialkowski prefering "drm_dev" there is no clear favourite yet. Maybe all the other people with strong opinions are dead if this was "discussed to death" before? :-) Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
On Wed, Jul 12, 2023 at 12:46:33PM +0200, Christian König wrote: > Am 12.07.23 um 11:46 schrieb Uwe Kleine-König: > > Hello, > > > > while I debugged an issue in the imx-lcdc driver I was constantly > > irritated about struct drm_device pointer variables being named "dev" > > because with that name I usually expect a struct device pointer. > > > > I think there is a big benefit when these are all renamed to "drm_dev". > > I have no strong preference here though, so "drmdev" or "drm" are fine > > for me, too. Let the bikesheding begin! > > > > Some statistics: > > > > $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq > > -c | sort -n > >1 struct drm_device *adev_to_drm > >1 struct drm_device *drm_ > >1 struct drm_device *drm_dev > >1 struct drm_device*drm_dev > >1 struct drm_device *pdev > >1 struct drm_device *rdev > >1 struct drm_device *vdev > >2 struct drm_device *dcss_drv_dev_to_drm > >2 struct drm_device **ddev > >2 struct drm_device *drm_dev_alloc > >2 struct drm_device *mock > >2 struct drm_device *p_ddev > >5 struct drm_device *device > >9 struct drm_device * dev > > 25 struct drm_device *d > > 95 struct drm_device * > > 216 struct drm_device *ddev > > 234 struct drm_device *drm_dev > > 611 struct drm_device *drm > > 4190 struct drm_device *dev > > > > This series starts with renaming struct drm_crtc::dev to drm_dev. If > > it's not only me and others like the result of this effort it should be > > followed up by adapting the other structs and the individual usages in > > the different drivers. > > > > To make this series a bit easier handleable, I first added an alias for > > drm_crtc::dev, then converted the drivers one after another and the last > > patch drops the "dev" name. This has the advantage of being easier to > > review, and if I should have missed an instance only the last patch must > > be dropped/reverted. Also this series might conflict with other patches, > > in this case the remaining patches can still go in (apart from the last > > one of course). Maybe it also makes sense to delay applying the last > > patch by one development cycle? > > When you automatically generate the patch (with cocci for example) I usually > prefer a single patch instead. Maybe I'm too stupid, but only parts of this patch were created by coccinelle. I failed to convert code like - spin_lock_irq(&crtc->dev->event_lock); + spin_lock_irq(&crtc->drm_dev->event_lock); Added Julia to Cc, maybe she has a hint?! (Up to now it's only @@ struct drm_crtc *crtc; @@ -crtc->dev +crtc->drm_dev ) > Background is that this makes merge conflicts easier to handle and detect. Really? Each file (apart from include/drm/drm_crtc.h) is only touched once. So unless I'm missing something you don't get less or easier conflicts by doing it all in a single patch. But you gain the freedom to drop a patch for one driver without having to drop the rest with it. So I still like the split version better, but I'm open to a more verbose reasoning from your side. > When you have multiple patches and a merge conflict because of some added > lines using the old field the build breaks only on the last patch which > removes the old field. Then you can revert/drop the last patch without having to respin the whole single patch and thus caring for still more conflicts that arise until the new version is sent. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
[PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
Hello, while I debugged an issue in the imx-lcdc driver I was constantly irritated about struct drm_device pointer variables being named "dev" because with that name I usually expect a struct device pointer. I think there is a big benefit when these are all renamed to "drm_dev". I have no strong preference here though, so "drmdev" or "drm" are fine for me, too. Let the bikesheding begin! Some statistics: $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq -c | sort -n 1 struct drm_device *adev_to_drm 1 struct drm_device *drm_ 1 struct drm_device *drm_dev 1 struct drm_device*drm_dev 1 struct drm_device *pdev 1 struct drm_device *rdev 1 struct drm_device *vdev 2 struct drm_device *dcss_drv_dev_to_drm 2 struct drm_device **ddev 2 struct drm_device *drm_dev_alloc 2 struct drm_device *mock 2 struct drm_device *p_ddev 5 struct drm_device *device 9 struct drm_device * dev 25 struct drm_device *d 95 struct drm_device * 216 struct drm_device *ddev 234 struct drm_device *drm_dev 611 struct drm_device *drm 4190 struct drm_device *dev This series starts with renaming struct drm_crtc::dev to drm_dev. If it's not only me and others like the result of this effort it should be followed up by adapting the other structs and the individual usages in the different drivers. To make this series a bit easier handleable, I first added an alias for drm_crtc::dev, then converted the drivers one after another and the last patch drops the "dev" name. This has the advantage of being easier to review, and if I should have missed an instance only the last patch must be dropped/reverted. Also this series might conflict with other patches, in this case the remaining patches can still go in (apart from the last one of course). Maybe it also makes sense to delay applying the last patch by one development cycle? The series was compile tested for arm, arm64, powerpc and amd64 using an allmodconfig (though I only build drivers/gpu/). Best regards Uwe Uwe Kleine-König (52): drm/crtc: Start renaming struct drm_crtc::dev to drm_dev drm/core: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/amd: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/armada: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/arm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/aspeed: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/ast: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/atmel-hlcdc: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/exynos: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/fsl-dcu: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/gma500: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/gud: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/hisilicon: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/hyperv: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/i915: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/imx: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/ingenic: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/kmb: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/logicvc: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/mcde: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/mediatek: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/meson: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/mgag200: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/msm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/mxsfb: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/nouveau: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/omapdrm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/panel-ili9341: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/pl111: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/qxl: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/radeon: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/renesas: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/rockchip: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/solomon: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/sprd: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/sti: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/stm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/sun4i: Use struct drm_crtc::drm_
Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
On Wed, 12 Jul 2023, Uwe Kleine-König wrote: > On Wed, Jul 12, 2023 at 12:46:33PM +0200, Christian König wrote: > > Am 12.07.23 um 11:46 schrieb Uwe Kleine-König: > > > Hello, > > > > > > while I debugged an issue in the imx-lcdc driver I was constantly > > > irritated about struct drm_device pointer variables being named "dev" > > > because with that name I usually expect a struct device pointer. > > > > > > I think there is a big benefit when these are all renamed to "drm_dev". > > > I have no strong preference here though, so "drmdev" or "drm" are fine > > > for me, too. Let the bikesheding begin! > > > > > > Some statistics: > > > > > > $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq > > > -c | sort -n > > >1 struct drm_device *adev_to_drm > > >1 struct drm_device *drm_ > > >1 struct drm_device *drm_dev > > >1 struct drm_device*drm_dev > > >1 struct drm_device *pdev > > >1 struct drm_device *rdev > > >1 struct drm_device *vdev > > >2 struct drm_device *dcss_drv_dev_to_drm > > >2 struct drm_device **ddev > > >2 struct drm_device *drm_dev_alloc > > >2 struct drm_device *mock > > >2 struct drm_device *p_ddev > > >5 struct drm_device *device > > >9 struct drm_device * dev > > > 25 struct drm_device *d > > > 95 struct drm_device * > > > 216 struct drm_device *ddev > > > 234 struct drm_device *drm_dev > > > 611 struct drm_device *drm > > > 4190 struct drm_device *dev > > > > > > This series starts with renaming struct drm_crtc::dev to drm_dev. If > > > it's not only me and others like the result of this effort it should be > > > followed up by adapting the other structs and the individual usages in > > > the different drivers. > > > > > > To make this series a bit easier handleable, I first added an alias for > > > drm_crtc::dev, then converted the drivers one after another and the last > > > patch drops the "dev" name. This has the advantage of being easier to > > > review, and if I should have missed an instance only the last patch must > > > be dropped/reverted. Also this series might conflict with other patches, > > > in this case the remaining patches can still go in (apart from the last > > > one of course). Maybe it also makes sense to delay applying the last > > > patch by one development cycle? > > > > When you automatically generate the patch (with cocci for example) I usually > > prefer a single patch instead. > > Maybe I'm too stupid, but only parts of this patch were created by > coccinelle. I failed to convert code like > > - spin_lock_irq(&crtc->dev->event_lock); > + spin_lock_irq(&crtc->drm_dev->event_lock); > > Added Julia to Cc, maybe she has a hint?! A priori, I see no reason why the rule below should not apply to the above code. Is there a parsing problem in the containing function? You can run spatch --parse-c file.c If there is a paring problem, please let me know and i will try to fix it so the while thing can be done automatically. julia > > (Up to now it's only > > @@ > struct drm_crtc *crtc; > @@ > -crtc->dev > +crtc->drm_dev > > ) > > > Background is that this makes merge conflicts easier to handle and detect. > > Really? Each file (apart from include/drm/drm_crtc.h) is only touched > once. So unless I'm missing something you don't get less or easier > conflicts by doing it all in a single patch. But you gain the freedom to > drop a patch for one driver without having to drop the rest with it. So > I still like the split version better, but I'm open to a more verbose > reasoning from your side. > > > When you have multiple patches and a merge conflict because of some added > > lines using the old field the build breaks only on the last patch which > > removes the old field. > > Then you can revert/drop the last patch without having to respin the > whole single patch and thus caring for still more conflicts that arise > until the new version is sent. > > Best regards > Uwe > > -- > Pengutronix e.K. | Uwe Kleine-König| > Industrial Linux Solutions | https://www.pengutronix.de/ | >
Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
On 12.07.2023 13:07, Julia Lawall wrote: On Wed, 12 Jul 2023, Uwe Kleine-König wrote: On Wed, Jul 12, 2023 at 12:46:33PM +0200, Christian König wrote: Am 12.07.23 um 11:46 schrieb Uwe Kleine-König: Hello, while I debugged an issue in the imx-lcdc driver I was constantly irritated about struct drm_device pointer variables being named "dev" because with that name I usually expect a struct device pointer. I think there is a big benefit when these are all renamed to "drm_dev". I have no strong preference here though, so "drmdev" or "drm" are fine for me, too. Let the bikesheding begin! Some statistics: $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq -c | sort -n 1 struct drm_device *adev_to_drm 1 struct drm_device *drm_ 1 struct drm_device *drm_dev 1 struct drm_device*drm_dev 1 struct drm_device *pdev 1 struct drm_device *rdev 1 struct drm_device *vdev 2 struct drm_device *dcss_drv_dev_to_drm 2 struct drm_device **ddev 2 struct drm_device *drm_dev_alloc 2 struct drm_device *mock 2 struct drm_device *p_ddev 5 struct drm_device *device 9 struct drm_device * dev 25 struct drm_device *d 95 struct drm_device * 216 struct drm_device *ddev 234 struct drm_device *drm_dev 611 struct drm_device *drm 4190 struct drm_device *dev This series starts with renaming struct drm_crtc::dev to drm_dev. If it's not only me and others like the result of this effort it should be followed up by adapting the other structs and the individual usages in the different drivers. To make this series a bit easier handleable, I first added an alias for drm_crtc::dev, then converted the drivers one after another and the last patch drops the "dev" name. This has the advantage of being easier to review, and if I should have missed an instance only the last patch must be dropped/reverted. Also this series might conflict with other patches, in this case the remaining patches can still go in (apart from the last one of course). Maybe it also makes sense to delay applying the last patch by one development cycle? When you automatically generate the patch (with cocci for example) I usually prefer a single patch instead. Maybe I'm too stupid, but only parts of this patch were created by coccinelle. I failed to convert code like - spin_lock_irq(&crtc->dev->event_lock); + spin_lock_irq(&crtc->drm_dev->event_lock); Added Julia to Cc, maybe she has a hint?! A priori, I see no reason why the rule below should not apply to the above code. Is there a parsing problem in the containing function? You can run spatch --parse-c file.c If there is a paring problem, please let me know and i will try to fix it so the while thing can be done automatically. I guess some clever macros can fool spatch, at least I observe such things in i915 which often uses custom iterators. Regards Andrzej julia (Up to now it's only @@ struct drm_crtc *crtc; @@ -crtc->dev +crtc->drm_dev ) Background is that this makes merge conflicts easier to handle and detect. Really? Each file (apart from include/drm/drm_crtc.h) is only touched once. So unless I'm missing something you don't get less or easier conflicts by doing it all in a single patch. But you gain the freedom to drop a patch for one driver without having to drop the rest with it. So I still like the split version better, but I'm open to a more verbose reasoning from your side. When you have multiple patches and a merge conflict because of some added lines using the old field the build breaks only on the last patch which removes the old field. Then you can revert/drop the last patch without having to respin the whole single patch and thus caring for still more conflicts that arise until the new version is sent. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | >
Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
Am 12.07.23 um 11:46 schrieb Uwe Kleine-König: Hello, while I debugged an issue in the imx-lcdc driver I was constantly irritated about struct drm_device pointer variables being named "dev" because with that name I usually expect a struct device pointer. I think there is a big benefit when these are all renamed to "drm_dev". I have no strong preference here though, so "drmdev" or "drm" are fine for me, too. Let the bikesheding begin! Some statistics: $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq -c | sort -n 1 struct drm_device *adev_to_drm 1 struct drm_device *drm_ 1 struct drm_device *drm_dev 1 struct drm_device*drm_dev 1 struct drm_device *pdev 1 struct drm_device *rdev 1 struct drm_device *vdev 2 struct drm_device *dcss_drv_dev_to_drm 2 struct drm_device **ddev 2 struct drm_device *drm_dev_alloc 2 struct drm_device *mock 2 struct drm_device *p_ddev 5 struct drm_device *device 9 struct drm_device * dev 25 struct drm_device *d 95 struct drm_device * 216 struct drm_device *ddev 234 struct drm_device *drm_dev 611 struct drm_device *drm 4190 struct drm_device *dev This series starts with renaming struct drm_crtc::dev to drm_dev. If it's not only me and others like the result of this effort it should be followed up by adapting the other structs and the individual usages in the different drivers. To make this series a bit easier handleable, I first added an alias for drm_crtc::dev, then converted the drivers one after another and the last patch drops the "dev" name. This has the advantage of being easier to review, and if I should have missed an instance only the last patch must be dropped/reverted. Also this series might conflict with other patches, in this case the remaining patches can still go in (apart from the last one of course). Maybe it also makes sense to delay applying the last patch by one development cycle? When you automatically generate the patch (with cocci for example) I usually prefer a single patch instead. Background is that this makes merge conflicts easier to handle and detect. When you have multiple patches and a merge conflict because of some added lines using the old field the build breaks only on the last patch which removes the old field. In such cases reviewing the patch just means automatically re-generating it and double checking that you don't see anything funky. Apart from that I honestly absolutely don't care what the name is. Cheers, Christian. The series was compile tested for arm, arm64, powerpc and amd64 using an allmodconfig (though I only build drivers/gpu/). Best regards Uwe Uwe Kleine-König (52): drm/crtc: Start renaming struct drm_crtc::dev to drm_dev drm/core: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/amd: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/armada: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/arm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/aspeed: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/ast: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/atmel-hlcdc: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/exynos: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/fsl-dcu: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/gma500: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/gud: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/hisilicon: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/hyperv: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/i915: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/imx: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/ingenic: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/kmb: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/logicvc: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/mcde: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/mediatek: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/meson: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/mgag200: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/msm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/mxsfb: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/nouveau: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/omapdrm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/panel-ili9341: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/pl111: Use struct d
[PATCH RFC v1 31/52] drm/radeon: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
Prepare dropping the alias "dev" for struct drm_crtc::drm_dev. "drm_dev"
is the better name as "dev" is usually a struct device pointer.
No semantic changes.
Signed-off-by: Uwe Kleine-König
---
drivers/gpu/drm/radeon/atombios_crtc.c | 54 ++---
drivers/gpu/drm/radeon/radeon_cursor.c | 14 +++---
drivers/gpu/drm/radeon/radeon_display.c | 28 +--
drivers/gpu/drm/radeon/radeon_kms.c | 6 +--
drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 16 +++---
5 files changed, 60 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index ade13173921b..76a2924a8590 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -39,7 +39,7 @@ static void atombios_overscan_setup(struct drm_crtc *crtc,
struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
{
- struct drm_device *dev = crtc->dev;
+ struct drm_device *dev = crtc->drm_dev;
struct radeon_device *rdev = dev->dev_private;
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
SET_CRTC_OVERSCAN_PS_ALLOCATION args;
@@ -82,7 +82,7 @@ static void atombios_overscan_setup(struct drm_crtc *crtc,
static void atombios_scaler_setup(struct drm_crtc *crtc)
{
- struct drm_device *dev = crtc->dev;
+ struct drm_device *dev = crtc->drm_dev;
struct radeon_device *rdev = dev->dev_private;
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
ENABLE_SCALER_PS_ALLOCATION args;
@@ -167,7 +167,7 @@ static void atombios_scaler_setup(struct drm_crtc *crtc)
static void atombios_lock_crtc(struct drm_crtc *crtc, int lock)
{
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
- struct drm_device *dev = crtc->dev;
+ struct drm_device *dev = crtc->drm_dev;
struct radeon_device *rdev = dev->dev_private;
int index =
GetIndexIntoMasterTable(COMMAND, UpdateCRTC_DoubleBufferRegisters);
@@ -184,7 +184,7 @@ static void atombios_lock_crtc(struct drm_crtc *crtc, int
lock)
static void atombios_enable_crtc(struct drm_crtc *crtc, int state)
{
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
- struct drm_device *dev = crtc->dev;
+ struct drm_device *dev = crtc->drm_dev;
struct radeon_device *rdev = dev->dev_private;
int index = GetIndexIntoMasterTable(COMMAND, EnableCRTC);
ENABLE_CRTC_PS_ALLOCATION args;
@@ -200,7 +200,7 @@ static void atombios_enable_crtc(struct drm_crtc *crtc, int
state)
static void atombios_enable_crtc_memreq(struct drm_crtc *crtc, int state)
{
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
- struct drm_device *dev = crtc->dev;
+ struct drm_device *dev = crtc->drm_dev;
struct radeon_device *rdev = dev->dev_private;
int index = GetIndexIntoMasterTable(COMMAND, EnableCRTCMemReq);
ENABLE_CRTC_PS_ALLOCATION args;
@@ -226,7 +226,7 @@ static const u32 vga_control_regs[6] =
static void atombios_blank_crtc(struct drm_crtc *crtc, int state)
{
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
- struct drm_device *dev = crtc->dev;
+ struct drm_device *dev = crtc->drm_dev;
struct radeon_device *rdev = dev->dev_private;
int index = GetIndexIntoMasterTable(COMMAND, BlankCRTC);
BLANK_CRTC_PS_ALLOCATION args;
@@ -251,7 +251,7 @@ static void atombios_blank_crtc(struct drm_crtc *crtc, int
state)
static void atombios_powergate_crtc(struct drm_crtc *crtc, int state)
{
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
- struct drm_device *dev = crtc->dev;
+ struct drm_device *dev = crtc->drm_dev;
struct radeon_device *rdev = dev->dev_private;
int index = GetIndexIntoMasterTable(COMMAND, EnableDispPowerGating);
ENABLE_DISP_POWER_GATING_PARAMETERS_V2_1 args;
@@ -266,7 +266,7 @@ static void atombios_powergate_crtc(struct drm_crtc *crtc,
int state)
void atombios_crtc_dpms(struct drm_crtc *crtc, int mode)
{
- struct drm_device *dev = crtc->dev;
+ struct drm_device *dev = crtc->drm_dev;
struct radeon_device *rdev = dev->dev_private;
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
@@ -303,7 +303,7 @@ atombios_set_crtc_dtd_timing(struct drm_crtc *crtc,
struct drm_display_mode *mode)
{
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
- struct drm_device *dev = crtc->dev;
+ struct drm_device *dev = crtc->drm_dev;
struct radeon_device *rdev = dev->dev_private;
SET_CRTC_USING_DTD_TIMING_PARAMETERS args;
int index = GetIndexIntoMasterTable(COMMAND, SetCRTC_UsingDTDTiming);
@@ -350,7 +350,7 @@ static void atombios_crtc_set_timing(struct drm_crtc *crtc,
struct drm_display_mode *
Re: [PATCH 10/17] hid/picolcd: Remove flag FBINFO_FLAG_DEFAULT from fbdev driver
On Mon, 10 Jul 2023 14:50:14 +0200 Thomas Zimmermann wrote: > The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct > fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do > not set it. > > Flags should signal differences from the default values. After cleaning > up all occurences of FBINFO_FLAG_DEFAULT, the token can be removed. > > Signed-off-by: Thomas Zimmermann > Cc: "Bruno Prémont" > Cc: Jiri Kosina > Cc: Benjamin Tissoires Acked-by: Bruno Prémont Cheers, Bruno > --- > drivers/hid/hid-picolcd_fb.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/hid/hid-picolcd_fb.c b/drivers/hid/hid-picolcd_fb.c > index dabcd054dad9..d726aaafb146 100644 > --- a/drivers/hid/hid-picolcd_fb.c > +++ b/drivers/hid/hid-picolcd_fb.c > @@ -527,7 +527,6 @@ int picolcd_init_framebuffer(struct picolcd_data *data) > info->var = picolcdfb_var; > info->fix = picolcdfb_fix; > info->fix.smem_len = PICOLCDFB_SIZE*8; > - info->flags = FBINFO_FLAG_DEFAULT; > > fbdata = info->par; > spin_lock_init(&fbdata->lock);
[PATCH RFC v1 03/52] drm/amd: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
Prepare dropping the alias "dev" for struct drm_crtc::drm_dev. "drm_dev"
is the better name as "dev" is usually a struct device pointer.
No semantic changes.
Signed-off-by: Uwe Kleine-König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 18 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 6 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_pll.c | 6 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c | 8 ++---
drivers/gpu/drm/amd/amdgpu/atombios_crtc.c| 22 +++---
drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 26 -
drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 28 +-
drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 26 -
drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 26 -
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29 ++-
.../drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 20 ++---
.../amd/display/amdgpu_dm/amdgpu_dm_crtc.c| 8 ++---
.../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 22 +++---
.../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 2 +-
14 files changed, 125 insertions(+), 122 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index b702f499f5fb..cc796e56c3d7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -147,14 +147,14 @@ static void amdgpu_display_flip_work_func(struct
work_struct *__work)
}
/* We borrow the event spin lock for protecting flip_status */
- spin_lock_irqsave(&crtc->dev->event_lock, flags);
+ spin_lock_irqsave(&crtc->drm_dev->event_lock, flags);
/* Do the flip (mmio) */
adev->mode_info.funcs->page_flip(adev, work->crtc_id, work->base,
work->async);
/* Set the flip status */
amdgpu_crtc->pflip_status = AMDGPU_FLIP_SUBMITTED;
- spin_unlock_irqrestore(&crtc->dev->event_lock, flags);
+ spin_unlock_irqrestore(&crtc->drm_dev->event_lock, flags);
drm_dbg_vbl(adev_to_drm(adev),
@@ -191,7 +191,7 @@ int amdgpu_display_crtc_page_flip_target(struct drm_crtc
*crtc,
uint32_t page_flip_flags, uint32_t target,
struct drm_modeset_acquire_ctx *ctx)
{
- struct drm_device *dev = crtc->dev;
+ struct drm_device *dev = crtc->drm_dev;
struct amdgpu_device *adev = drm_to_adev(dev);
struct amdgpu_crtc *amdgpu_crtc = to_amdgpu_crtc(crtc);
struct drm_gem_object *obj;
@@ -262,10 +262,10 @@ int amdgpu_display_crtc_page_flip_target(struct drm_crtc
*crtc,
amdgpu_get_vblank_counter_kms(crtc);
/* we borrow the event spin lock for protecting flip_wrok */
- spin_lock_irqsave(&crtc->dev->event_lock, flags);
+ spin_lock_irqsave(&crtc->drm_dev->event_lock, flags);
if (amdgpu_crtc->pflip_status != AMDGPU_FLIP_NONE) {
DRM_DEBUG_DRIVER("flip queue: crtc already busy\n");
- spin_unlock_irqrestore(&crtc->dev->event_lock, flags);
+ spin_unlock_irqrestore(&crtc->drm_dev->event_lock, flags);
r = -EBUSY;
goto pflip_cleanup;
}
@@ -278,7 +278,7 @@ int amdgpu_display_crtc_page_flip_target(struct drm_crtc
*crtc,
amdgpu_crtc->crtc_id, amdgpu_crtc,
work);
/* update crtc fb */
crtc->primary->fb = fb;
- spin_unlock_irqrestore(&crtc->dev->event_lock, flags);
+ spin_unlock_irqrestore(&crtc->drm_dev->event_lock, flags);
amdgpu_display_flip_work_func(&work->flip_work.work);
return 0;
@@ -316,7 +316,7 @@ int amdgpu_display_crtc_set_config(struct drm_mode_set *set,
if (!set || !set->crtc)
return -EINVAL;
- dev = set->crtc->dev;
+ dev = set->crtc->drm_dev;
ret = pm_runtime_get_sync(dev->dev);
if (ret < 0)
@@ -1353,7 +1353,7 @@ bool amdgpu_display_crtc_scaling_mode_fixup(struct
drm_crtc *crtc,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
{
- struct drm_device *dev = crtc->dev;
+ struct drm_device *dev = crtc->drm_dev;
struct drm_encoder *encoder;
struct amdgpu_crtc *amdgpu_crtc = to_amdgpu_crtc(crtc);
struct amdgpu_encoder *amdgpu_encoder;
@@ -1587,7 +1587,7 @@ bool amdgpu_crtc_get_scanout_position(struct drm_crtc
*crtc,
int *hpos, ktime_t *stime, ktime_t *etime,
const struct drm_display_mode *mode)
{
- struct drm_device *dev = crtc->dev;
+ struct drm_device *dev = crtc->drm_dev;
unsigned int pipe = crtc->index;
return amdgpu_display_get_crtc_scanoutpos(dev, pipe, 0, vpos, hpos,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index cca5a495611f
Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
Hi Am 12.07.23 um 11:46 schrieb Uwe Kleine-König: Hello, while I debugged an issue in the imx-lcdc driver I was constantly irritated about struct drm_device pointer variables being named "dev" because with that name I usually expect a struct device pointer. I think there is a big benefit when these are all renamed to "drm_dev". If you rename drm_crtc.dev, you should also address *all* other data structures. I have no strong preference here though, so "drmdev" or "drm" are fine for me, too. Let the bikesheding begin! We've discussed this to death. IIRC 'drm' would be the prefered choice. Best regards Thomas Some statistics: $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq -c | sort -n 1 struct drm_device *adev_to_drm 1 struct drm_device *drm_ 1 struct drm_device *drm_dev 1 struct drm_device*drm_dev 1 struct drm_device *pdev 1 struct drm_device *rdev 1 struct drm_device *vdev 2 struct drm_device *dcss_drv_dev_to_drm 2 struct drm_device **ddev 2 struct drm_device *drm_dev_alloc 2 struct drm_device *mock 2 struct drm_device *p_ddev 5 struct drm_device *device 9 struct drm_device * dev 25 struct drm_device *d 95 struct drm_device * 216 struct drm_device *ddev 234 struct drm_device *drm_dev 611 struct drm_device *drm 4190 struct drm_device *dev This series starts with renaming struct drm_crtc::dev to drm_dev. If it's not only me and others like the result of this effort it should be followed up by adapting the other structs and the individual usages in the different drivers. To make this series a bit easier handleable, I first added an alias for drm_crtc::dev, then converted the drivers one after another and the last patch drops the "dev" name. This has the advantage of being easier to review, and if I should have missed an instance only the last patch must be dropped/reverted. Also this series might conflict with other patches, in this case the remaining patches can still go in (apart from the last one of course). Maybe it also makes sense to delay applying the last patch by one development cycle? The series was compile tested for arm, arm64, powerpc and amd64 using an allmodconfig (though I only build drivers/gpu/). Best regards Uwe Uwe Kleine-König (52): drm/crtc: Start renaming struct drm_crtc::dev to drm_dev drm/core: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/amd: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/armada: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/arm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/aspeed: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/ast: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/atmel-hlcdc: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/exynos: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/fsl-dcu: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/gma500: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/gud: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/hisilicon: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/hyperv: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/i915: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/imx: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/ingenic: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/kmb: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/logicvc: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/mcde: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/mediatek: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/meson: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/mgag200: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/msm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/mxsfb: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/nouveau: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/omapdrm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/panel-ili9341: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/pl111: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/qxl: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/radeon: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/renesas: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/rockchip: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/solomon: Use stru
Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
Hi Uwe, On Wed 12 Jul 23, 11:46, Uwe Kleine-König wrote: > Hello, > > while I debugged an issue in the imx-lcdc driver I was constantly > irritated about struct drm_device pointer variables being named "dev" > because with that name I usually expect a struct device pointer. Well personally I usually expect that the "dev" member of a subsystem-specific struct refers to a device of that subsystem, so for me having "dev" refer to a drm_device for e.g. drm_crtc makes good sense. I would only expect dev to refer to a struct device in the subsystem-specific device structure (drm_device). I don't think it makes much sense to carry the struct device in any other subsystem-specific structure anyway. So IMO things are fine as-is but this is not a very strong opinion either. > I think there is a big benefit when these are all renamed to "drm_dev". > I have no strong preference here though, so "drmdev" or "drm" are fine > for me, too. Let the bikesheding begin! I would definitely prefer "drm_dev" over "drmdev" (hard to read, feels like aborted camelcase, pretty ugly) or "drm" (too vague). Cheers, Paul > Some statistics: > > $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq -c > | sort -n > 1 struct drm_device *adev_to_drm > 1 struct drm_device *drm_ > 1 struct drm_device *drm_dev > 1 struct drm_device*drm_dev > 1 struct drm_device *pdev > 1 struct drm_device *rdev > 1 struct drm_device *vdev > 2 struct drm_device *dcss_drv_dev_to_drm > 2 struct drm_device **ddev > 2 struct drm_device *drm_dev_alloc > 2 struct drm_device *mock > 2 struct drm_device *p_ddev > 5 struct drm_device *device > 9 struct drm_device * dev > 25 struct drm_device *d > 95 struct drm_device * > 216 struct drm_device *ddev > 234 struct drm_device *drm_dev > 611 struct drm_device *drm >4190 struct drm_device *dev > > This series starts with renaming struct drm_crtc::dev to drm_dev. If > it's not only me and others like the result of this effort it should be > followed up by adapting the other structs and the individual usages in > the different drivers. > > To make this series a bit easier handleable, I first added an alias for > drm_crtc::dev, then converted the drivers one after another and the last > patch drops the "dev" name. This has the advantage of being easier to > review, and if I should have missed an instance only the last patch must > be dropped/reverted. Also this series might conflict with other patches, > in this case the remaining patches can still go in (apart from the last > one of course). Maybe it also makes sense to delay applying the last > patch by one development cycle? > > The series was compile tested for arm, arm64, powerpc and amd64 using an > allmodconfig (though I only build drivers/gpu/). > > Best regards > Uwe > > Uwe Kleine-König (52): > drm/crtc: Start renaming struct drm_crtc::dev to drm_dev > drm/core: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev > drm/amd: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev > drm/armada: Use struct drm_crtc::drm_dev instead of struct > drm_crtc::dev > drm/arm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev > drm/aspeed: Use struct drm_crtc::drm_dev instead of struct > drm_crtc::dev > drm/ast: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev > drm/atmel-hlcdc: Use struct drm_crtc::drm_dev instead of struct > drm_crtc::dev > drm/exynos: Use struct drm_crtc::drm_dev instead of struct > drm_crtc::dev > drm/fsl-dcu: Use struct drm_crtc::drm_dev instead of struct > drm_crtc::dev > drm/gma500: Use struct drm_crtc::drm_dev instead of struct > drm_crtc::dev > drm/gud: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev > drm/hisilicon: Use struct drm_crtc::drm_dev instead of struct > drm_crtc::dev > drm/hyperv: Use struct drm_crtc::drm_dev instead of struct > drm_crtc::dev > drm/i915: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev > drm/imx: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev > drm/ingenic: Use struct drm_crtc::drm_dev instead of struct > drm_crtc::dev > drm/kmb: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev > drm/logicvc: Use struct drm_crtc::drm_dev instead of struct > drm_crtc::dev > drm/mcde: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev > drm/mediatek: Use struct drm_crtc::drm_dev instead of struct > drm_crtc::dev > drm/meson: Use struct drm_crtc::drm_dev instead of struct > drm_crtc::dev > drm/mgag200: Use struct drm_crtc::drm_dev instead of struct > drm_crtc::dev > drm/msm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev > drm/mxsfb: Use struct drm_crtc::drm_dev instead of struct > drm_crtc::dev > drm/nouveau: Use struct drm_crtc::drm_dev instead of struct > drm_crtc
[PATCH 1/7] drm/radeon: switch over to drm_exec
Just a straightforward conversion without any optimization.
Signed-off-by: Christian König
Cc: amd-gfx@lists.freedesktop.org
---
drivers/gpu/drm/radeon/Kconfig | 1 +
drivers/gpu/drm/radeon/radeon.h| 7 ++--
drivers/gpu/drm/radeon/radeon_cs.c | 45 +-
drivers/gpu/drm/radeon/radeon_gem.c| 39 --
drivers/gpu/drm/radeon/radeon_object.c | 25 +++---
drivers/gpu/drm/radeon/radeon_object.h | 2 +-
drivers/gpu/drm/radeon/radeon_vm.c | 10 +++---
7 files changed, 66 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/radeon/Kconfig b/drivers/gpu/drm/radeon/Kconfig
index fe498c8af1bb..fdfede471a6d 100644
--- a/drivers/gpu/drm/radeon/Kconfig
+++ b/drivers/gpu/drm/radeon/Kconfig
@@ -12,6 +12,7 @@ config DRM_RADEON
select DRM_TTM
select DRM_TTM_HELPER
select FB_IO_HELPERS if DRM_FBDEV_EMULATION
+ select DRM_EXEC
select SND_HDA_COMPONENT if SND_HDA_CORE
select POWER_SUPPLY
select HWMON
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 8afb03bbce29..37a932a5195f 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -75,8 +75,8 @@
#include
#include
-#include
+#include
#include
#include
#include
@@ -458,7 +458,8 @@ struct radeon_mman {
struct radeon_bo_list {
struct radeon_bo*robj;
- struct ttm_validate_buffer tv;
+ struct list_headlist;
+ boolshared;
uint64_tgpu_offset;
unsignedpreferred_domains;
unsignedallowed_domains;
@@ -1031,6 +1032,7 @@ struct radeon_cs_parser {
struct radeon_bo_list *vm_bos;
struct list_headvalidated;
unsigneddma_reloc_idx;
+ struct drm_exec exec;
/* indices of various chunks */
struct radeon_cs_chunk *chunk_ib;
struct radeon_cs_chunk *chunk_relocs;
@@ -1044,7 +1046,6 @@ struct radeon_cs_parser {
u32 cs_flags;
u32 ring;
s32 priority;
- struct ww_acquire_ctx ticket;
};
static inline u32 radeon_get_ib_value(struct radeon_cs_parser *p, int idx)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index a6700d7278bf..ea0a1ed56bd8 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -182,11 +182,8 @@ static int radeon_cs_parser_relocs(struct radeon_cs_parser
*p)
}
}
- p->relocs[i].tv.bo = &p->relocs[i].robj->tbo;
- p->relocs[i].tv.num_shared = !r->write_domain;
-
- radeon_cs_buckets_add(&buckets, &p->relocs[i].tv.head,
- priority);
+ p->relocs[i].shared = !r->write_domain;
+ radeon_cs_buckets_add(&buckets, &p->relocs[i].list, priority);
}
radeon_cs_buckets_get_list(&buckets, &p->validated);
@@ -197,7 +194,7 @@ static int radeon_cs_parser_relocs(struct radeon_cs_parser
*p)
if (need_mmap_lock)
mmap_read_lock(current->mm);
- r = radeon_bo_list_validate(p->rdev, &p->ticket, &p->validated,
p->ring);
+ r = radeon_bo_list_validate(p->rdev, &p->exec, &p->validated, p->ring);
if (need_mmap_lock)
mmap_read_unlock(current->mm);
@@ -253,12 +250,11 @@ static int radeon_cs_sync_rings(struct radeon_cs_parser
*p)
struct radeon_bo_list *reloc;
int r;
- list_for_each_entry(reloc, &p->validated, tv.head) {
+ list_for_each_entry(reloc, &p->validated, list) {
struct dma_resv *resv;
resv = reloc->robj->tbo.base.resv;
- r = radeon_sync_resv(p->rdev, &p->ib.sync, resv,
-reloc->tv.num_shared);
+ r = radeon_sync_resv(p->rdev, &p->ib.sync, resv, reloc->shared);
if (r)
return r;
}
@@ -276,6 +272,7 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void
*data)
s32 priority = 0;
INIT_LIST_HEAD(&p->validated);
+ drm_exec_init(&p->exec, DRM_EXEC_INTERRUPTIBLE_WAIT);
if (!cs->num_chunks) {
return 0;
@@ -397,8 +394,8 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void
*data)
static int cmp_size_smaller_first(void *priv, const struct list_head *a,
const struct list_head *b)
{
- struct radeon_bo_list *la = list_entry(a, struct radeon_bo_list,
tv.head);
- struct radeon_bo_list *lb = list_entry(b, struct radeon_bo_list,
tv.head);
+ struct radeon_bo_list *la = list_entry(a, struct radeon_bo_list, list);
+ struct radeon_bo_list *lb = list_entry
Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
On Wed, Jul 12, 2023 at 01:02:53PM +0200, Uwe Kleine-König wrote: > > Background is that this makes merge conflicts easier to handle and detect. > > Really? FWIW, I agree with Christian here. > Each file (apart from include/drm/drm_crtc.h) is only touched once. So > unless I'm missing something you don't get less or easier conflicts by > doing it all in a single patch. But you gain the freedom to drop a > patch for one driver without having to drop the rest with it. Not really, because the last patch removed the union anyway. So you have to revert both the last patch, plus that driver one. And then you need to add a TODO to remove that union eventually. > So I still like the split version better, but I'm open to a more > verbose reasoning from your side. You're doing only one thing here, really: you change the name of a structure field. If it was shared between multiple maintainers, then sure, splitting that up is easier for everyone, but this will go through drm-misc, so I can't see the benefit it brings. Maxime signature.asc Description: PGP signature
Re: [PATCH v5 6/6] drm/doc: Define KMS atomic state set
On Saturday, July 8th, 2023 at 00:40, André Almeida wrote: > +KMS atomic state > + > + > +An atomic commit can change multiple KMS properties in an atomic fashion, > +without ever applying intermediate or partial state changes. Either the > whole > +commit succeeds or fails, and it will never be applied partially. This is the > +fundamental improvement of the atomic API over the older non-atomic API > which is > +referred to as the "legacy API". Applying intermediate state could > unexpectedly > +fail, cause visible glitches, or delay reaching the final state. > + > +An atomic commit can be flagged with DRM_MODE_ATOMIC_TEST_ONLY, which means > the Can we linkify these #defines? This can be done like so: … flagged with :c:macro:`DRM_MODE_ATOMIC_TEST_ONLY`, which means … This should create a link to the docs for this flag.
Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
Hello Maxime, On Wed, Jul 12, 2023 at 02:52:38PM +0200, Maxime Ripard wrote: > On Wed, Jul 12, 2023 at 01:02:53PM +0200, Uwe Kleine-König wrote: > > > Background is that this makes merge conflicts easier to handle and detect. > > > > Really? > > FWIW, I agree with Christian here. > > > Each file (apart from include/drm/drm_crtc.h) is only touched once. So > > unless I'm missing something you don't get less or easier conflicts by > > doing it all in a single patch. But you gain the freedom to drop a > > patch for one driver without having to drop the rest with it. > > Not really, because the last patch removed the union anyway. So you have > to revert both the last patch, plus that driver one. And then you need > to add a TODO to remove that union eventually. Yes, with a single patch you have only one revert (but 194 files changed, 1264 insertions(+), 1296 deletions(-)) instead of two (one of them: 1 file changed, 9 insertions(+), 1 deletion(-); the other maybe a bit bigger). (And maybe you get away with just reverting the last patch.) With a single patch the TODO after a revert is "redo it all again (and prepare for a different set of conflicts)" while with the split series it's only "fix that one driver that was forgotten/borked" + reapply that 10 line patch. As the one who gets that TODO, I prefer the latter. So in sum: If your metric is "small count of reverted commits", you're right. If however your metric is: Better get 95% of this series' change in than maybe 0%, the split series is the way to do it. With me having spend ~3h on this series' changes, it's maybe understandable that I did it the way I did. FTR: This series was created on top of v6.5-rc1. If you apply it to drm-misc-next you get a (trivial) conflict in patch #2. If I consider to be the responsible maintainer who applies this series, I like being able to just do git am --skip then. FTR#2: In drm-misc-next is a new driver (drivers/gpu/drm/loongson/lsdc_crtc.c) so skipping the last patch for now might indeed be a good idea. > > So I still like the split version better, but I'm open to a more > > verbose reasoning from your side. > > You're doing only one thing here, really: you change the name of a > structure field. If it was shared between multiple maintainers, then > sure, splitting that up is easier for everyone, but this will go through > drm-misc, so I can't see the benefit it brings. I see your argument, but I think mine weights more. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
On Wed, Jul 12, 2023 at 03:38:03PM +0200, Uwe Kleine-König wrote: > Hello Maxime, > > On Wed, Jul 12, 2023 at 02:52:38PM +0200, Maxime Ripard wrote: > > On Wed, Jul 12, 2023 at 01:02:53PM +0200, Uwe Kleine-König wrote: > > > > Background is that this makes merge conflicts easier to handle and > > > > detect. > > > > > > Really? > > > > FWIW, I agree with Christian here. > > > > > Each file (apart from include/drm/drm_crtc.h) is only touched once. So > > > unless I'm missing something you don't get less or easier conflicts by > > > doing it all in a single patch. But you gain the freedom to drop a > > > patch for one driver without having to drop the rest with it. > > > > Not really, because the last patch removed the union anyway. So you have > > to revert both the last patch, plus that driver one. And then you need > > to add a TODO to remove that union eventually. > > Yes, with a single patch you have only one revert (but 194 files changed, > 1264 insertions(+), 1296 deletions(-)) instead of two (one of them: 1 > file changed, 9 insertions(+), 1 deletion(-); the other maybe a bit > bigger). (And maybe you get away with just reverting the last patch.) > > With a single patch the TODO after a revert is "redo it all again (and > prepare for a different set of conflicts)" while with the split series > it's only "fix that one driver that was forgotten/borked" + reapply that > 10 line patch. As the one who gets that TODO, I prefer the latter. > > So in sum: If your metric is "small count of reverted commits", you're > right. If however your metric is: Better get 95% of this series' change > in than maybe 0%, the split series is the way to do it. I guess that's where we disagree: I don't see the point of having 95% of it, either 0 or 100. > With me having spend ~3h on this series' changes, it's maybe > understandable that I did it the way I did. I'm sorry, but that's never been an argument? I'm sure you and I both have had series that took much longer dropped because it wasn't the right approach. > FTR: This series was created on top of v6.5-rc1. If you apply it to > drm-misc-next you get a (trivial) conflict in patch #2. If I consider to > be the responsible maintainer who applies this series, I like being able > to just do git am --skip then. Or we can ask that the driver is based on drm-misc-next ... > FTR#2: In drm-misc-next is a new driver > (drivers/gpu/drm/loongson/lsdc_crtc.c) so skipping the last patch for > now might indeed be a good idea. ... which is going to fix that one too. Maxime signature.asc Description: PGP signature
Re: [PATCH] drm/amd/display: dc.h: eliminate kernel-doc warnings
On 2023-07-11 22:23, Randy Dunlap wrote:
> Quash 175 kernel-doc warnings in dc.h by unmarking 2 struct
> comments as containing kernel-doc notation and by spelling one
> struct field correctly in a kernel-doc comment.
>
> Fixes: 1682bd1a6b5f ("drm/amd/display: Expand kernel doc for DC")
> Fixes: ea76895ffab1 ("drm/amd/display: Document pipe split policy")
> Fixes: f6ae69f49fcf ("drm/amd/display: Include surface of unaffected streams")
> Signed-off-by: Randy Dunlap
> Cc: Harry Wentland
> Cc: Leo Li
> Cc: Rodrigo Siqueira
> Cc: Aurabindo Pillai
> Cc: Alex Deucher
> Cc: amd-gfx@lists.freedesktop.org
> Cc: Alex Deucher
> Cc: Christian König
> Cc: "Pan, Xinhui"
> Cc: dri-de...@lists.freedesktop.org
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/dc/dc.h |8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff -- a/drivers/gpu/drm/amd/display/dc/dc.h
> b/drivers/gpu/drm/amd/display/dc/dc.h
> --- a/drivers/gpu/drm/amd/display/dc/dc.h
> +++ b/drivers/gpu/drm/amd/display/dc/dc.h
> @@ -506,7 +506,7 @@ enum dcn_zstate_support_state {
> DCN_ZSTATE_SUPPORT_DISALLOW,
> };
>
> -/**
> +/*
> * struct dc_clocks - DC pipe clocks
> *
> * For any clocks that may differ per pipe only the max is stored in this
> @@ -728,7 +728,7 @@ struct resource_pool;
> struct dce_hwseq;
> struct link_service;
>
> -/**
> +/*
> * struct dc_debug_options - DC debug struct
> *
> * This struct provides a simple mechanism for developers to change some
> @@ -756,7 +756,7 @@ struct dc_debug_options {
> bool use_max_lb;
> enum dcc_option disable_dcc;
>
> - /**
> + /*
>* @pipe_split_policy: Define which pipe split policy is used by the
>* display core.
>*/
> @@ -1334,7 +1334,7 @@ struct dc_validation_set {
> struct dc_stream_state *stream;
>
> /**
> - * @plane_state: Surface state
> + * @plane_states: Surface state
>*/
> struct dc_plane_state *plane_states[MAX_SURFACES];
>
Re: [PATCH] drm/amd/display: dc.h: eliminate kernel-doc warnings
Applied. Thanks!
Alex
On Wed, Jul 12, 2023 at 9:58 AM Harry Wentland wrote:
>
> On 2023-07-11 22:23, Randy Dunlap wrote:
> > Quash 175 kernel-doc warnings in dc.h by unmarking 2 struct
> > comments as containing kernel-doc notation and by spelling one
> > struct field correctly in a kernel-doc comment.
> >
> > Fixes: 1682bd1a6b5f ("drm/amd/display: Expand kernel doc for DC")
> > Fixes: ea76895ffab1 ("drm/amd/display: Document pipe split policy")
> > Fixes: f6ae69f49fcf ("drm/amd/display: Include surface of unaffected
> > streams")
> > Signed-off-by: Randy Dunlap
> > Cc: Harry Wentland
> > Cc: Leo Li
> > Cc: Rodrigo Siqueira
> > Cc: Aurabindo Pillai
> > Cc: Alex Deucher
> > Cc: amd-gfx@lists.freedesktop.org
> > Cc: Alex Deucher
> > Cc: Christian König
> > Cc: "Pan, Xinhui"
> > Cc: dri-de...@lists.freedesktop.org
>
> Reviewed-by: Harry Wentland
>
> Harry
>
> > ---
> > drivers/gpu/drm/amd/display/dc/dc.h |8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff -- a/drivers/gpu/drm/amd/display/dc/dc.h
> > b/drivers/gpu/drm/amd/display/dc/dc.h
> > --- a/drivers/gpu/drm/amd/display/dc/dc.h
> > +++ b/drivers/gpu/drm/amd/display/dc/dc.h
> > @@ -506,7 +506,7 @@ enum dcn_zstate_support_state {
> > DCN_ZSTATE_SUPPORT_DISALLOW,
> > };
> >
> > -/**
> > +/*
> > * struct dc_clocks - DC pipe clocks
> > *
> > * For any clocks that may differ per pipe only the max is stored in this
> > @@ -728,7 +728,7 @@ struct resource_pool;
> > struct dce_hwseq;
> > struct link_service;
> >
> > -/**
> > +/*
> > * struct dc_debug_options - DC debug struct
> > *
> > * This struct provides a simple mechanism for developers to change some
> > @@ -756,7 +756,7 @@ struct dc_debug_options {
> > bool use_max_lb;
> > enum dcc_option disable_dcc;
> >
> > - /**
> > + /*
> >* @pipe_split_policy: Define which pipe split policy is used by the
> >* display core.
> >*/
> > @@ -1334,7 +1334,7 @@ struct dc_validation_set {
> > struct dc_stream_state *stream;
> >
> > /**
> > - * @plane_state: Surface state
> > + * @plane_states: Surface state
> >*/
> > struct dc_plane_state *plane_states[MAX_SURFACES];
> >
>
Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
Am 12.07.23 um 15:38 schrieb Uwe Kleine-König: Hello Maxime, On Wed, Jul 12, 2023 at 02:52:38PM +0200, Maxime Ripard wrote: On Wed, Jul 12, 2023 at 01:02:53PM +0200, Uwe Kleine-König wrote: Background is that this makes merge conflicts easier to handle and detect. Really? FWIW, I agree with Christian here. Each file (apart from include/drm/drm_crtc.h) is only touched once. So unless I'm missing something you don't get less or easier conflicts by doing it all in a single patch. But you gain the freedom to drop a patch for one driver without having to drop the rest with it. Not really, because the last patch removed the union anyway. So you have to revert both the last patch, plus that driver one. And then you need to add a TODO to remove that union eventually. Yes, with a single patch you have only one revert (but 194 files changed, 1264 insertions(+), 1296 deletions(-)) instead of two (one of them: 1 file changed, 9 insertions(+), 1 deletion(-); the other maybe a bit bigger). (And maybe you get away with just reverting the last patch.) With a single patch the TODO after a revert is "redo it all again (and prepare for a different set of conflicts)" while with the split series it's only "fix that one driver that was forgotten/borked" + reapply that 10 line patch. Yeah, but for a maintainer the size of the patches doesn't matter. That's only interesting if you need to manually review the patch, which you hopefully doesn't do in case of something auto-generated. In other words if the patch is auto-generated re-applying it completely is less work than fixing things up individually. As the one who gets that TODO, I prefer the latter. Yeah, but your personal preferences are not a technical relevant argument to a maintainer. At the end of the day Dave or Daniel need to decide, because they need to live with it. Regards, Christian. So in sum: If your metric is "small count of reverted commits", you're right. If however your metric is: Better get 95% of this series' change in than maybe 0%, the split series is the way to do it. With me having spend ~3h on this series' changes, it's maybe understandable that I did it the way I did. FTR: This series was created on top of v6.5-rc1. If you apply it to drm-misc-next you get a (trivial) conflict in patch #2. If I consider to be the responsible maintainer who applies this series, I like being able to just do git am --skip then. FTR#2: In drm-misc-next is a new driver (drivers/gpu/drm/loongson/lsdc_crtc.c) so skipping the last patch for now might indeed be a good idea. So I still like the split version better, but I'm open to a more verbose reasoning from your side. You're doing only one thing here, really: you change the name of a structure field. If it was shared between multiple maintainers, then sure, splitting that up is easier for everyone, but this will go through drm-misc, so I can't see the benefit it brings. I see your argument, but I think mine weights more. Best regards Uwe
Re: [PATCH] drm/amdgpu: replace 1-element arrays with flexible arrays
On Wed, Jul 12, 2023 at 8:04 AM Ricardo Cañuelo
wrote:
>
> UBSAN complains about out-of-bounds array indexes on all 1-element
> arrays defined on this driver:
>
> UBSAN: array-index-out-of-bounds in
> /home/rcn/work/repos/kernelci/kernelci-core/linux_kernel_mainline/drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/processpptables.c:1249:61
>
> Substitute them with proper flexible arrays.
+ Gustavo, Paulo
I haven't kept up with the flexible arrays stuff. Is this equivalent
to a zero sized array? We've been bitten by these kind of changes in
the past. These structures define the layout of data in a rom image
on the board. If the struct size changes, that could lead to errors
in the code that deals with these structures.
Alex
>
> Tested on an Acer R721T (grunt) Chromebook.
>
> Signed-off-by: Ricardo Cañuelo
> ---
> drivers/gpu/drm/amd/include/pptable.h | 36 +++
> 1 file changed, 20 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/include/pptable.h
> b/drivers/gpu/drm/amd/include/pptable.h
> index 0b6a057e0a4c..a65e2807dc06 100644
> --- a/drivers/gpu/drm/amd/include/pptable.h
> +++ b/drivers/gpu/drm/amd/include/pptable.h
> @@ -473,14 +473,14 @@ typedef struct _ATOM_PPLIB_STATE_V2
>/**
>* Driver will read the first ucNumDPMLevels in this array
>*/
> - UCHAR clockInfoIndex[1];
> + __DECLARE_FLEX_ARRAY(UCHAR, clockInfoIndex);
> } ATOM_PPLIB_STATE_V2;
>
> typedef struct _StateArray{
> //how many states we have
> UCHAR ucNumEntries;
>
> -ATOM_PPLIB_STATE_V2 states[1];
> +__DECLARE_FLEX_ARRAY(ATOM_PPLIB_STATE_V2, states);
> }StateArray;
>
>
> @@ -491,7 +491,7 @@ typedef struct _ClockInfoArray{
> //sizeof(ATOM_PPLIB_CLOCK_INFO)
> UCHAR ucEntrySize;
>
> -UCHAR clockInfo[1];
> +__DECLARE_FLEX_ARRAY(UCHAR, clockInfo);
> }ClockInfoArray;
>
> typedef struct _NonClockInfoArray{
> @@ -501,7 +501,7 @@ typedef struct _NonClockInfoArray{
> //sizeof(ATOM_PPLIB_NONCLOCK_INFO)
> UCHAR ucEntrySize;
>
> -ATOM_PPLIB_NONCLOCK_INFO nonClockInfo[1];
> +__DECLARE_FLEX_ARRAY(ATOM_PPLIB_NONCLOCK_INFO, nonClockInfo);
> }NonClockInfoArray;
>
> typedef struct _ATOM_PPLIB_Clock_Voltage_Dependency_Record
> @@ -514,7 +514,8 @@ typedef struct _ATOM_PPLIB_Clock_Voltage_Dependency_Record
> typedef struct _ATOM_PPLIB_Clock_Voltage_Dependency_Table
> {
> UCHAR ucNumEntries;//
> Number of entries.
> -ATOM_PPLIB_Clock_Voltage_Dependency_Record entries[1]; //
> Dynamically allocate entries.
> +/* Dynamically allocate entries. */
> +__DECLARE_FLEX_ARRAY(ATOM_PPLIB_Clock_Voltage_Dependency_Record,
> entries);
> }ATOM_PPLIB_Clock_Voltage_Dependency_Table;
>
> typedef struct _ATOM_PPLIB_Clock_Voltage_Limit_Record
> @@ -530,7 +531,8 @@ typedef struct _ATOM_PPLIB_Clock_Voltage_Limit_Record
> typedef struct _ATOM_PPLIB_Clock_Voltage_Limit_Table
> {
> UCHAR ucNumEntries;//
> Number of entries.
> -ATOM_PPLIB_Clock_Voltage_Limit_Record entries[1]; //
> Dynamically allocate entries.
> +/* Dynamically allocate entries. */
> +__DECLARE_FLEX_ARRAY(ATOM_PPLIB_Clock_Voltage_Limit_Record, entries);
> }ATOM_PPLIB_Clock_Voltage_Limit_Table;
>
> union _ATOM_PPLIB_CAC_Leakage_Record
> @@ -554,7 +556,8 @@ typedef union _ATOM_PPLIB_CAC_Leakage_Record
> ATOM_PPLIB_CAC_Leakage_Record;
> typedef struct _ATOM_PPLIB_CAC_Leakage_Table
> {
> UCHAR ucNumEntries; //
> Number of entries.
> -ATOM_PPLIB_CAC_Leakage_Record entries[1]; //
> Dynamically allocate entries.
> +/* Dynamically allocate entries. */
> +__DECLARE_FLEX_ARRAY(ATOM_PPLIB_CAC_Leakage_Record, entries);
> }ATOM_PPLIB_CAC_Leakage_Table;
>
> typedef struct _ATOM_PPLIB_PhaseSheddingLimits_Record
> @@ -569,7 +572,8 @@ typedef struct _ATOM_PPLIB_PhaseSheddingLimits_Record
> typedef struct _ATOM_PPLIB_PhaseSheddingLimits_Table
> {
> UCHAR ucNumEntries; //
> Number of entries.
> -ATOM_PPLIB_PhaseSheddingLimits_Record entries[1]; //
> Dynamically allocate entries.
> +/* Dynamically allocate entries. */
> +__DECLARE_FLEX_ARRAY(ATOM_PPLIB_PhaseSheddingLimits_Record, entries);
> }ATOM_PPLIB_PhaseSheddingLimits_Table;
>
> typedef struct _VCEClockInfo{
> @@ -581,7 +585,7 @@ typedef struct _VCEClockInfo{
>
> typedef struct _VCEClockInfoArray{
> UCHAR ucNumEntries;
> -VCEClockInfo entries[1];
> +__DECLARE_FLEX_ARRAY(VCEClockInfo, entries);
> }VCEClockInfoArray;
>
> typedef struct _ATOM_PPLIB_VCE_Clock_Voltage_Limit_Record
> @@ -593,7 +597,7 @@ typedef struct _ATOM_PPLIB_VCE_Clock_Voltage_Limit_Record
> typedef struct _ATOM_PPLIB_VCE_Clock_Voltage_Limit_Table
> {
> UCHAR numEntries;
> -ATOM_PPLIB_VCE_Clock_V
[PATCH 3/5] drm/amdkfd: use vma_is_stack() and vma_is_heap()
Use the helpers to simplify code. Signed-off-by: Kefeng Wang --- drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c index 479c4f66afa7..19ce68a7e1a8 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c @@ -2623,10 +2623,7 @@ svm_range_get_range_boundaries(struct kfd_process *p, int64_t addr, return -EFAULT; } - *is_heap_stack = (vma->vm_start <= vma->vm_mm->brk && - vma->vm_end >= vma->vm_mm->start_brk) || -(vma->vm_start <= vma->vm_mm->start_stack && - vma->vm_end >= vma->vm_mm->start_stack); + *is_heap_stack = vma_is_heap(vma) || vma_is_stack(vma); start_limit = max(vma->vm_start >> PAGE_SHIFT, (unsigned long)ALIGN_DOWN(addr, 2UL << 8)); -- 2.41.0
Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
On Wed, 12 Jul 2023, Uwe Kleine-König wrote: > Hello, > > while I debugged an issue in the imx-lcdc driver I was constantly > irritated about struct drm_device pointer variables being named "dev" > because with that name I usually expect a struct device pointer. > > I think there is a big benefit when these are all renamed to "drm_dev". > I have no strong preference here though, so "drmdev" or "drm" are fine > for me, too. Let the bikesheding begin! > > Some statistics: > > $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq -c > | sort -n > 1 struct drm_device *adev_to_drm > 1 struct drm_device *drm_ > 1 struct drm_device *drm_dev > 1 struct drm_device*drm_dev > 1 struct drm_device *pdev > 1 struct drm_device *rdev > 1 struct drm_device *vdev > 2 struct drm_device *dcss_drv_dev_to_drm > 2 struct drm_device **ddev > 2 struct drm_device *drm_dev_alloc > 2 struct drm_device *mock > 2 struct drm_device *p_ddev > 5 struct drm_device *device > 9 struct drm_device * dev > 25 struct drm_device *d > 95 struct drm_device * > 216 struct drm_device *ddev > 234 struct drm_device *drm_dev > 611 struct drm_device *drm >4190 struct drm_device *dev > > This series starts with renaming struct drm_crtc::dev to drm_dev. If > it's not only me and others like the result of this effort it should be > followed up by adapting the other structs and the individual usages in > the different drivers. I think this is an unnecessary change. In drm, a dev is usually a drm device, i.e. struct drm_device *. As shown by the numbers above. If folks insist on following through with this anyway, I'm firmly in the camp the name should be "drm" and nothing else. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH 3/5] drm/amdkfd: use vma_is_stack() and vma_is_heap()
On Wed, Jul 12, 2023 at 10:38:29PM +0800, Kefeng Wang wrote: > Use the helpers to simplify code. Nothing against your addition of a helper, but a GPU driver really should have no business even looking at this information..
[PATCH 1/5] mm: introduce vma_is_stack() and vma_is_heap()
Introduce the two helpers for general use.
Signed-off-by: Kefeng Wang
---
include/linux/mm.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 1462cf15badf..0bbeb31ac750 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -926,6 +926,18 @@ static inline bool vma_is_anonymous(struct vm_area_struct
*vma)
return !vma->vm_ops;
}
+static inline bool vma_is_heap(struct vm_area_struct *vma)
+{
+ return vma->vm_start <= vma->vm_mm->brk &&
+ vma->vm_end >= vma->vm_mm->start_brk;
+}
+
+static inline bool vma_is_stack(struct vm_area_struct *vma)
+{
+ return vma->vm_start <= vma->vm_mm->start_stack &&
+ vma->vm_end >= vma->vm_mm->start_stack;
+}
+
static inline bool vma_is_temporary_stack(struct vm_area_struct *vma)
{
int maybe_stack = vma->vm_flags & (VM_GROWSDOWN | VM_GROWSUP);
--
2.41.0
[PATCH 5/5] perf/core: use vma_is_stack() and vma_is_heap()
Use the helpers to simplify code, also kill unneeded goto cpy_name.
Signed-off-by: Kefeng Wang
---
kernel/events/core.c | 22 +++---
1 file changed, 7 insertions(+), 15 deletions(-)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 78ae7b6f90fd..cb271f449b81 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -8685,22 +8685,14 @@ static void perf_event_mmap_event(struct
perf_mmap_event *mmap_event)
}
name = (char *)arch_vma_name(vma);
- if (name)
- goto cpy_name;
-
- if (vma->vm_start <= vma->vm_mm->start_brk &&
- vma->vm_end >= vma->vm_mm->brk) {
- name = "[heap]";
- goto cpy_name;
+ if (!name) {
+ if (vma_is_heap(vma))
+ name = "[heap]";
+ else if (vma_is_stack(vma))
+ name = "[stack]";
+ else
+ name = "//anon";
}
- if (vma->vm_start <= vma->vm_mm->start_stack &&
- vma->vm_end >= vma->vm_mm->start_stack) {
- name = "[stack]";
- goto cpy_name;
- }
-
- name = "//anon";
- goto cpy_name;
}
cpy_name:
--
2.41.0
[PATCH 0/5] mm: convert to vma_is_heap/stack()
Add vma_is_stack() and vma_is_heap() helper and use them to simplify code. Kefeng Wang (5): mm: introduce vma_is_stack() and vma_is_heap() mm: use vma_is_stack() and vma_is_heap() drm/amdkfd: use vma_is_stack() and vma_is_heap() selinux: use vma_is_stack() and vma_is_heap() perf/core: use vma_is_stack() and vma_is_heap() drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 5 + fs/proc/task_mmu.c | 24 fs/proc/task_nommu.c | 15 +-- include/linux/mm.h | 12 kernel/events/core.c | 22 +++--- security/selinux/hooks.c | 7 ++- 6 files changed, 27 insertions(+), 58 deletions(-) -- 2.41.0
[PATCH 2/5] mm: use vma_is_stack() and vma_is_heap()
Use the helpers to simplify code.
Signed-off-by: Kefeng Wang
---
fs/proc/task_mmu.c | 24
fs/proc/task_nommu.c | 15 +--
2 files changed, 5 insertions(+), 34 deletions(-)
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index cfab855fe7e9..05e9893552ce 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -236,21 +236,6 @@ static int do_maps_open(struct inode *inode, struct file
*file,
sizeof(struct proc_maps_private));
}
-/*
- * Indicate if the VMA is a stack for the given task; for
- * /proc/PID/maps that is the stack of the main task.
- */
-static int is_stack(struct vm_area_struct *vma)
-{
- /*
-* We make no effort to guess what a given thread considers to be
-* its "stack". It's not even well-defined for programs written
-* languages like Go.
-*/
- return vma->vm_start <= vma->vm_mm->start_stack &&
- vma->vm_end >= vma->vm_mm->start_stack;
-}
-
static void show_vma_header_prefix(struct seq_file *m,
unsigned long start, unsigned long end,
vm_flags_t flags, unsigned long long pgoff,
@@ -327,13 +312,12 @@ show_map_vma(struct seq_file *m, struct vm_area_struct
*vma)
goto done;
}
- if (vma->vm_start <= mm->brk &&
- vma->vm_end >= mm->start_brk) {
+ if (vma_is_heap(vma)) {
name = "[heap]";
goto done;
}
- if (is_stack(vma)) {
+ if (vma_is_stack(vma)) {
name = "[stack]";
goto done;
}
@@ -1974,9 +1958,9 @@ static int show_numa_map(struct seq_file *m, void *v)
if (file) {
seq_puts(m, " file=");
seq_file_path(m, file, "\n\t= ");
- } else if (vma->vm_start <= mm->brk && vma->vm_end >= mm->start_brk) {
+ } else if (vma_is_heap(vma)) {
seq_puts(m, " heap");
- } else if (is_stack(vma)) {
+ } else if (vma_is_stack(vma)) {
seq_puts(m, " stack");
}
diff --git a/fs/proc/task_nommu.c b/fs/proc/task_nommu.c
index 2c8b62265981..f42c84172b9e 100644
--- a/fs/proc/task_nommu.c
+++ b/fs/proc/task_nommu.c
@@ -121,19 +121,6 @@ unsigned long task_statm(struct mm_struct *mm,
return size;
}
-static int is_stack(struct vm_area_struct *vma)
-{
- struct mm_struct *mm = vma->vm_mm;
-
- /*
-* We make no effort to guess what a given thread considers to be
-* its "stack". It's not even well-defined for programs written
-* languages like Go.
-*/
- return vma->vm_start <= mm->start_stack &&
- vma->vm_end >= mm->start_stack;
-}
-
/*
* display a single VMA to a sequenced file
*/
@@ -171,7 +158,7 @@ static int nommu_vma_show(struct seq_file *m, struct
vm_area_struct *vma)
if (file) {
seq_pad(m, ' ');
seq_file_path(m, file, "");
- } else if (mm && is_stack(vma)) {
+ } else if (mm && vma_is_stack(vma)) {
seq_pad(m, ' ');
seq_puts(m, "[stack]");
}
--
2.41.0
[PATCH 4/5] selinux: use vma_is_stack() and vma_is_heap()
Use the helpers to simplify code.
Signed-off-by: Kefeng Wang
---
security/selinux/hooks.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 4e46cf3d67b6..289ef2d6a427 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -3775,13 +3775,10 @@ static int selinux_file_mprotect(struct vm_area_struct
*vma,
if (default_noexec &&
(prot & PROT_EXEC) && !(vma->vm_flags & VM_EXEC)) {
int rc = 0;
- if (vma->vm_start >= vma->vm_mm->start_brk &&
- vma->vm_end <= vma->vm_mm->brk) {
+ if (vma_is_heap(vma)) {
rc = avc_has_perm(sid, sid, SECCLASS_PROCESS,
PROCESS__EXECHEAP, NULL);
- } else if (!vma->vm_file &&
- ((vma->vm_start <= vma->vm_mm->start_stack &&
-vma->vm_end >= vma->vm_mm->start_stack) ||
+ } else if (!vma->vm_file && vma_is_stack(vma) ||
vma_is_stack_for_current(vma))) {
rc = avc_has_perm(sid, sid, SECCLASS_PROCESS,
PROCESS__EXECSTACK, NULL);
--
2.41.0
Re: [PATCH] Revert "drm/amd/display: Program OTG vtotal min/max selectors unconditionally for DCN1+"
[Public]
Hi Guilherme,
Sorry there was one more patch which I missed to attach. Please add this 3rd
patch and retry.
Reverting that patch would cause high power consumption on Navi2x GPU also
cause hangs on certain multi monitor configurations. With these 3 patches,
you're getting the same effect as reverting the aforementioned patches, but it
makes the reverted sequence available only for Steam deck hardware.
--
Regards,
Jay
From: Guilherme G. Piccoli
Sent: Tuesday, July 11, 2023 7:15 PM
To: Pillai, Aurabindo ; Deucher, Alexander
Cc: amd-gfx@lists.freedesktop.org ; Koenig,
Christian ; Pan, Xinhui ;
dri-de...@lists.freedesktop.org ;
kernel-...@igalia.com ; cristian.ciocal...@collabora.com
; André Almeida ;
Melissa Wen ; Siqueira, Rodrigo
Subject: Re: [PATCH] Revert "drm/amd/display: Program OTG vtotal min/max
selectors unconditionally for DCN1+"
On 11/07/2023 15:22, Aurabindo Pillai wrote:
> [...]
> Hi,
>
> Sorry for the delayed response, this patch went unnoticed. This revert would
> break asics. Could you try the attached patch without reverting this one ?
Hi Aurabindo, thanks for your response!
I've tried kernel 6.5-rc1, and it seems the issue is present, due to the
patch being merged on Linus tree [as 1598fc576420 ("drm/amd/display:
Program OTG vtotal min/max selectors unconditionally for DCN1+")].
Then, I tried both your attached patches on top of that, and
unfortunately, the behavior is the same: Steam Deck doesn't boot with
graphics, and we can see the single error "amdgpu :04:00.0: [drm]
*ERROR* [CRTC:67:crtc-0] flip_done timed out" on dmesg.
Do you / Alex think we could get this revert for 6.5-rc2, so at least we
could boot mainline there while the issue is handled? It would be an
intermediate fix. You mentioned it breaks some asics, but did they work
until now, without your patch?
Thanks,
Guilherme
0001-drm-amd-display-switch-to-DCN301-specific-TG-init.patch
Description: 0001-drm-amd-display-switch-to-DCN301-specific-TG-init.patch
Re: [PATCH] drm/amdgpu: Rename to amdgpu_vm_tlb_seq_struct
On 7/12/23 01:34, Christian König wrote:
> Am 12.07.23 um 10:03 schrieb Luben Tuikov:
>> On 2023-07-12 03:57, Christian König wrote:
>>> Am 12.07.23 um 08:58 schrieb Luben Tuikov:
Rename struct amdgpu_vm_tlb_seq_cb {...} to struct amdgpu_vm_tlb_seq_struct
{...}, so as to not conflict with documentation processing tools. Of
course, C
has no problem with this.
>>> Hui? What exactly is duplicated here? Is the structure defined in
>>> different files with a different meaning?
>> The same name is used for the function and for the structure.
>
> Ah, yeah that wasn't obvious.
>
> In this case the patch is Reviewed-by: Christian König
>
Reviewed-by: Randy Dunlap
Thanks.
>
> Thanks,
> Christian.
>
>>
>> struct amdgpu_vm_tlb_seq_cb {...}
>>
>> and
>>
>> static void amdgpu_vm_tlb_seq_cb(struct dma_fence *fence,
>> struct dma_fence_cb *cb)
>>
>> C has no problem with this, but document processing tools do,
>> and in general it doesn't seem like a good practice to have
>> the same name for both.
>>
>> Regards,
>> Luben
>>
>>> Christian.
>>>
Cc: Randy Dunlap
Cc: Alex Deucher
Cc: Christian König
Link:
https://lore.kernel.org/r/b5ebc891-ee63-1638-0377-7b512d34b...@infradead.org
Signed-off-by: Luben Tuikov
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 92a84e7b0db85b..32adc31c093d84 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -111,9 +111,9 @@ struct amdgpu_prt_cb {
};
/**
- * struct amdgpu_vm_tlb_seq_cb - Helper to increment the TLB flush
sequence
+ * struct amdgpu_vm_tlb_seq_struct - Helper to increment the TLB flush
sequence
*/
-struct amdgpu_vm_tlb_seq_cb {
+struct amdgpu_vm_tlb_seq_struct {
/**
* @vm: pointer to the amdgpu_vm structure to set the fence
sequence on
*/
@@ -833,7 +833,7 @@ int amdgpu_vm_update_pdes(struct amdgpu_device *adev,
static void amdgpu_vm_tlb_seq_cb(struct dma_fence *fence,
struct dma_fence_cb *cb)
{
-struct amdgpu_vm_tlb_seq_cb *tlb_cb;
+struct amdgpu_vm_tlb_seq_struct *tlb_cb;
tlb_cb = container_of(cb, typeof(*tlb_cb), cb);
atomic64_inc(&tlb_cb->vm->tlb_seq);
@@ -871,7 +871,7 @@ int amdgpu_vm_update_range(struct amdgpu_device *adev,
struct amdgpu_vm *vm,
struct dma_fence **fence)
{
struct amdgpu_vm_update_params params;
-struct amdgpu_vm_tlb_seq_cb *tlb_cb;
+struct amdgpu_vm_tlb_seq_struct *tlb_cb;
struct amdgpu_res_cursor cursor;
enum amdgpu_sync_mode sync_mode;
int r, idx;
base-commit: 50db2d96b49b7d6cdb12e71e4204cf7180d3bab5
>
--
~Randy
[PATCH] drm/amdgpu: expand runpm parameter
Allow the user to specify -2 as auto enabled with displays.
By default we don't enter runtime suspend when there are
displays attached because it does not work well in some
desktop environments due to the driver sending hotplug
events on resume in case any new displays were attached
while the GPU was powered down. Some users still want
this functionality though, so this lets you enable it.
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2428
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 37 +
1 file changed, 20 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 721f3c6160bcb..33e370d998a87 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -350,8 +350,9 @@ module_param_named(aspm, amdgpu_aspm, int, 0444);
* Override for runtime power management control for dGPUs. The amdgpu driver
can dynamically power down
* the dGPUs when they are idle if supported. The default is -1 (auto enable).
* Setting the value to 0 disables this functionality.
+ * Setting the value to -2 is auto enabled with power down when displays are
attached.
*/
-MODULE_PARM_DESC(runpm, "PX runtime pm (2 = force enable with BAMACO, 1 =
force enable with BACO, 0 = disable, -1 = auto)");
+MODULE_PARM_DESC(runpm, "PX runtime pm (2 = force enable with BAMACO, 1 =
force enable with BACO, 0 = disable, -1 = auto, -2 = autowith displays)");
module_param_named(runpm, amdgpu_runtime_pm, int, 0444);
/**
@@ -2657,24 +2658,26 @@ static int amdgpu_runtime_idle_check_display(struct
device *dev)
struct drm_connector_list_iter iter;
int ret = 0;
- /* XXX: Return busy if any displays are connected to avoid
-* possible display wakeups after runtime resume due to
-* hotplug events in case any displays were connected while
-* the GPU was in suspend. Remove this once that is fixed.
-*/
- mutex_lock(&drm_dev->mode_config.mutex);
- drm_connector_list_iter_begin(drm_dev, &iter);
- drm_for_each_connector_iter(list_connector, &iter) {
- if (list_connector->status ==
connector_status_connected) {
- ret = -EBUSY;
- break;
+ if (amdgpu_runtime_pm != -2) {
+ /* XXX: Return busy if any displays are connected to
avoid
+* possible display wakeups after runtime resume due to
+* hotplug events in case any displays were connected
while
+* the GPU was in suspend. Remove this once that is
fixed.
+*/
+ mutex_lock(&drm_dev->mode_config.mutex);
+ drm_connector_list_iter_begin(drm_dev, &iter);
+ drm_for_each_connector_iter(list_connector, &iter) {
+ if (list_connector->status ==
connector_status_connected) {
+ ret = -EBUSY;
+ break;
+ }
}
- }
- drm_connector_list_iter_end(&iter);
- mutex_unlock(&drm_dev->mode_config.mutex);
+ drm_connector_list_iter_end(&iter);
+ mutex_unlock(&drm_dev->mode_config.mutex);
- if (ret)
- return ret;
+ if (ret)
+ return ret;
+ }
if (adev->dc_enabled) {
struct drm_crtc *crtc;
--
2.41.0
Re: [PATCH] Revert "drm/amd/display: Program OTG vtotal min/max selectors unconditionally for DCN1+"
On 12/07/2023 11:47, Pillai, Aurabindo wrote: > Hi Guilherme, > > Sorry there was one more patch which I missed to attach. Please add this > 3^rd patch and retry. > > Reverting that patch would cause high power consumption on Navi2x GPU > also cause hangs on certain multi monitor configurations. With these 3 > patches, you're getting the same effect as reverting the aforementioned > patches, but it makes the reverted sequence available only for Steam > deck hardware. > Thanks a lot for your detailed explanation, and the 3rd patch! Indeed, amdgpu works fine on Deck with that - great =) Feel free to add my: Tested-by: Guilherme G. Piccoli #Steam Deck Oh, a fixes tag would also makes sense, I guess. BTW, if possible to submit the 3 patches in a proper series to get it merged on 6.5-rc cycle (the sooner the better), I'd really appreciate! Cheers, Guilherme
Re: [PATCH] Revert "drm/amd/display: Program OTG vtotal min/max selectors unconditionally for DCN1+"
On 7/12/2023 11:50 AM, Guilherme G. Piccoli wrote: On 12/07/2023 11:47, Pillai, Aurabindo wrote: Hi Guilherme, Sorry there was one more patch which I missed to attach. Please add this 3^rd patch and retry. Reverting that patch would cause high power consumption on Navi2x GPU also cause hangs on certain multi monitor configurations. With these 3 patches, you're getting the same effect as reverting the aforementioned patches, but it makes the reverted sequence available only for Steam deck hardware. Thanks a lot for your detailed explanation, and the 3rd patch! Indeed, amdgpu works fine on Deck with that - great =) Feel free to add my: Tested-by: Guilherme G. Piccoli #Steam Deck Oh, a fixes tag would also makes sense, I guess. BTW, if possible to submit the 3 patches in a proper series to get it merged on 6.5-rc cycle (the sooner the better), I'd really appreciate! Thanks for confirmation! I'll add the fixes tag so that it gets picked up.
Re: [PATCH v5 04/10] drm/amdgpu: create GFX-gen11 usermode queue
On 11/07/2023 21:51, Felix Kuehling wrote:
On 2023-07-06 09:39, Christian König wrote:
Am 06.07.23 um 15:37 schrieb Shashank Sharma:
On 06/07/2023 15:22, Christian König wrote:
Am 06.07.23 um 14:35 schrieb Shashank Sharma:
A Memory queue descriptor (MQD) of a userqueue defines it in
the hw's context. As MQD format can vary between different
graphics IPs, we need gfx GEN specific handlers to create MQDs.
This patch:
- Introduces MQD handler functions for the usermode queues.
- Adds new functions to create and destroy userqueue MQD for
GFX-GEN-11 IP
V1: Worked on review comments from Alex:
- Make MQD functions GEN and IP specific
V2: Worked on review comments from Alex:
- Reuse the existing adev->mqd[ip] for MQD creation
- Formatting and arrangement of code
V3:
- Integration with doorbell manager
V4: Review comments addressed:
- Do not create a new file for userq, reuse gfx_v11_0.c (Alex)
- Align name of structure members (Luben)
- Don't break up the Cc tag list and the Sob tag list in commit
message (Luben)
V5:
- No need to reserve the bo for MQD (Christian).
- Some more changes to support IP specific MQD creation.
Cc: Alex Deucher
Cc: Christian Koenig
Signed-off-by: Shashank Sharma
Signed-off-by: Arvind Yadav
---
drivers/gpu/drm/amd/amdgpu/amdgpu_userqueue.c | 16
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 73
+++
.../gpu/drm/amd/include/amdgpu_userqueue.h | 7 ++
3 files changed, 96 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_userqueue.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_userqueue.c
index e37b5da5a0d0..bb774144c372 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_userqueue.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_userqueue.c
@@ -134,12 +134,28 @@ int amdgpu_userq_ioctl(struct drm_device
*dev, void *data,
return r;
}
+extern const struct amdgpu_userq_funcs userq_gfx_v11_funcs;
+
+static void
+amdgpu_userqueue_setup_gfx(struct amdgpu_userq_mgr *uq_mgr)
+{
+ int maj;
+ struct amdgpu_device *adev = uq_mgr->adev;
+ uint32_t version = adev->ip_versions[GC_HWIP][0];
+
+ /* We support usermode queue only for GFX V11 as of now */
+ maj = IP_VERSION_MAJ(version);
+ if (maj == 11)
+ uq_mgr->userq_funcs[AMDGPU_HW_IP_GFX] =
&userq_gfx_v11_funcs;
+}
+
int amdgpu_userq_mgr_init(struct amdgpu_userq_mgr *userq_mgr,
struct amdgpu_device *adev)
{
mutex_init(&userq_mgr->userq_mutex);
idr_init_base(&userq_mgr->userq_idr, 1);
userq_mgr->adev = adev;
+ amdgpu_userqueue_setup_gfx(userq_mgr);
return 0;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
index c4940b6ea1c4..e76e1b86b434 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
@@ -30,6 +30,7 @@
#include "amdgpu_psp.h"
#include "amdgpu_smu.h"
#include "amdgpu_atomfirmware.h"
+#include "amdgpu_userqueue.h"
#include "imu_v11_0.h"
#include "soc21.h"
#include "nvd.h"
@@ -6486,3 +6487,75 @@ const struct amdgpu_ip_block_version
gfx_v11_0_ip_block =
.rev = 0,
.funcs = &gfx_v11_0_ip_funcs,
};
+
+static int gfx_v11_0_userq_mqd_create(struct amdgpu_userq_mgr
*uq_mgr,
+ struct drm_amdgpu_userq_in *args_in,
+ struct amdgpu_usermode_queue *queue)
+{
+ struct amdgpu_device *adev = uq_mgr->adev;
+ struct amdgpu_mqd *mqd_gfx_generic =
&adev->mqds[AMDGPU_HW_IP_GFX];
+ struct drm_amdgpu_userq_mqd_gfx_v11_0 mqd_user;
+ struct amdgpu_mqd_prop userq_props;
+ int r;
+
+ /* Incoming MQD parameters from userspace to be saved here */
+ memset(&mqd_user, 0, sizeof(mqd_user));
+
+ /* Structure to initialize MQD for userqueue using generic
MQD init function */
+ memset(&userq_props, 0, sizeof(userq_props));
+
+ if (args_in->mqd_size != sizeof(struct
drm_amdgpu_userq_mqd_gfx_v11_0)) {
+ DRM_ERROR("MQD size mismatch\n");
+ return -EINVAL;
+ }
+
+ if (copy_from_user(&mqd_user, u64_to_user_ptr(args_in->mqd),
args_in->mqd_size)) {
+ DRM_ERROR("Failed to get user MQD\n");
+ return -EFAULT;
+ }
+
+ /* Create BO for actual Userqueue MQD now */
+ r = amdgpu_bo_create_kernel(adev, mqd_gfx_generic->mqd_size,
PAGE_SIZE,
+ AMDGPU_GEM_DOMAIN_GTT,
+ &queue->mqd.obj,
+ &queue->mqd.gpu_addr,
+ &queue->mqd.cpu_ptr);
+ if (r) {
+ DRM_ERROR("Failed to allocate BO for userqueue (%d)", r);
+ return -ENOMEM;
+ }
Using amdgpu_bo_create_kernel() for the MQD is most likely not a
good idea in the long term, but should work for now.
I was a bit curious about this, the scope of this MQD object is
kernel internal and used for queue mapping only, userspace doesn't
know much about it. Do you still think we should not create a kernel
object for it ?
Well we should use a kernel BO.
Re: [PATCH v5 04/10] drm/amdgpu: create GFX-gen11 usermode queue
Am 2023-07-12 um 11:55 schrieb Shashank Sharma:
On 11/07/2023 21:51, Felix Kuehling wrote:
On 2023-07-06 09:39, Christian König wrote:
Am 06.07.23 um 15:37 schrieb Shashank Sharma:
On 06/07/2023 15:22, Christian König wrote:
Am 06.07.23 um 14:35 schrieb Shashank Sharma:
A Memory queue descriptor (MQD) of a userqueue defines it in
the hw's context. As MQD format can vary between different
graphics IPs, we need gfx GEN specific handlers to create MQDs.
This patch:
- Introduces MQD handler functions for the usermode queues.
- Adds new functions to create and destroy userqueue MQD for
GFX-GEN-11 IP
V1: Worked on review comments from Alex:
- Make MQD functions GEN and IP specific
V2: Worked on review comments from Alex:
- Reuse the existing adev->mqd[ip] for MQD creation
- Formatting and arrangement of code
V3:
- Integration with doorbell manager
V4: Review comments addressed:
- Do not create a new file for userq, reuse gfx_v11_0.c (Alex)
- Align name of structure members (Luben)
- Don't break up the Cc tag list and the Sob tag list in commit
message (Luben)
V5:
- No need to reserve the bo for MQD (Christian).
- Some more changes to support IP specific MQD creation.
Cc: Alex Deucher
Cc: Christian Koenig
Signed-off-by: Shashank Sharma
Signed-off-by: Arvind Yadav
---
drivers/gpu/drm/amd/amdgpu/amdgpu_userqueue.c | 16
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 73
+++
.../gpu/drm/amd/include/amdgpu_userqueue.h | 7 ++
3 files changed, 96 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_userqueue.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_userqueue.c
index e37b5da5a0d0..bb774144c372 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_userqueue.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_userqueue.c
@@ -134,12 +134,28 @@ int amdgpu_userq_ioctl(struct drm_device
*dev, void *data,
return r;
}
+extern const struct amdgpu_userq_funcs userq_gfx_v11_funcs;
+
+static void
+amdgpu_userqueue_setup_gfx(struct amdgpu_userq_mgr *uq_mgr)
+{
+ int maj;
+ struct amdgpu_device *adev = uq_mgr->adev;
+ uint32_t version = adev->ip_versions[GC_HWIP][0];
+
+ /* We support usermode queue only for GFX V11 as of now */
+ maj = IP_VERSION_MAJ(version);
+ if (maj == 11)
+ uq_mgr->userq_funcs[AMDGPU_HW_IP_GFX] =
&userq_gfx_v11_funcs;
+}
+
int amdgpu_userq_mgr_init(struct amdgpu_userq_mgr *userq_mgr,
struct amdgpu_device *adev)
{
mutex_init(&userq_mgr->userq_mutex);
idr_init_base(&userq_mgr->userq_idr, 1);
userq_mgr->adev = adev;
+ amdgpu_userqueue_setup_gfx(userq_mgr);
return 0;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
index c4940b6ea1c4..e76e1b86b434 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
@@ -30,6 +30,7 @@
#include "amdgpu_psp.h"
#include "amdgpu_smu.h"
#include "amdgpu_atomfirmware.h"
+#include "amdgpu_userqueue.h"
#include "imu_v11_0.h"
#include "soc21.h"
#include "nvd.h"
@@ -6486,3 +6487,75 @@ const struct amdgpu_ip_block_version
gfx_v11_0_ip_block =
.rev = 0,
.funcs = &gfx_v11_0_ip_funcs,
};
+
+static int gfx_v11_0_userq_mqd_create(struct amdgpu_userq_mgr
*uq_mgr,
+ struct drm_amdgpu_userq_in *args_in,
+ struct amdgpu_usermode_queue *queue)
+{
+ struct amdgpu_device *adev = uq_mgr->adev;
+ struct amdgpu_mqd *mqd_gfx_generic =
&adev->mqds[AMDGPU_HW_IP_GFX];
+ struct drm_amdgpu_userq_mqd_gfx_v11_0 mqd_user;
+ struct amdgpu_mqd_prop userq_props;
+ int r;
+
+ /* Incoming MQD parameters from userspace to be saved here */
+ memset(&mqd_user, 0, sizeof(mqd_user));
+
+ /* Structure to initialize MQD for userqueue using generic
MQD init function */
+ memset(&userq_props, 0, sizeof(userq_props));
+
+ if (args_in->mqd_size != sizeof(struct
drm_amdgpu_userq_mqd_gfx_v11_0)) {
+ DRM_ERROR("MQD size mismatch\n");
+ return -EINVAL;
+ }
+
+ if (copy_from_user(&mqd_user, u64_to_user_ptr(args_in->mqd),
args_in->mqd_size)) {
+ DRM_ERROR("Failed to get user MQD\n");
+ return -EFAULT;
+ }
+
+ /* Create BO for actual Userqueue MQD now */
+ r = amdgpu_bo_create_kernel(adev, mqd_gfx_generic->mqd_size,
PAGE_SIZE,
+ AMDGPU_GEM_DOMAIN_GTT,
+ &queue->mqd.obj,
+ &queue->mqd.gpu_addr,
+ &queue->mqd.cpu_ptr);
+ if (r) {
+ DRM_ERROR("Failed to allocate BO for userqueue (%d)", r);
+ return -ENOMEM;
+ }
Using amdgpu_bo_create_kernel() for the MQD is most likely not a
good idea in the long term, but should work for now.
I was a bit curious about this, the scope of this MQD object is
kernel internal and used for queue mapping only, userspace doesn't
know much about it. Do you still think we should not create a
kernel ob
Re: [PATCH v5 04/10] drm/amdgpu: create GFX-gen11 usermode queue
On 12/07/2023 18:01, Felix Kuehling wrote:
Am 2023-07-12 um 11:55 schrieb Shashank Sharma:
On 11/07/2023 21:51, Felix Kuehling wrote:
On 2023-07-06 09:39, Christian König wrote:
Am 06.07.23 um 15:37 schrieb Shashank Sharma:
On 06/07/2023 15:22, Christian König wrote:
Am 06.07.23 um 14:35 schrieb Shashank Sharma:
A Memory queue descriptor (MQD) of a userqueue defines it in
the hw's context. As MQD format can vary between different
graphics IPs, we need gfx GEN specific handlers to create MQDs.
This patch:
- Introduces MQD handler functions for the usermode queues.
- Adds new functions to create and destroy userqueue MQD for
GFX-GEN-11 IP
V1: Worked on review comments from Alex:
- Make MQD functions GEN and IP specific
V2: Worked on review comments from Alex:
- Reuse the existing adev->mqd[ip] for MQD creation
- Formatting and arrangement of code
V3:
- Integration with doorbell manager
V4: Review comments addressed:
- Do not create a new file for userq, reuse gfx_v11_0.c (Alex)
- Align name of structure members (Luben)
- Don't break up the Cc tag list and the Sob tag list in
commit
message (Luben)
V5:
- No need to reserve the bo for MQD (Christian).
- Some more changes to support IP specific MQD creation.
Cc: Alex Deucher
Cc: Christian Koenig
Signed-off-by: Shashank Sharma
Signed-off-by: Arvind Yadav
---
drivers/gpu/drm/amd/amdgpu/amdgpu_userqueue.c | 16
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 73
+++
.../gpu/drm/amd/include/amdgpu_userqueue.h | 7 ++
3 files changed, 96 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_userqueue.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_userqueue.c
index e37b5da5a0d0..bb774144c372 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_userqueue.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_userqueue.c
@@ -134,12 +134,28 @@ int amdgpu_userq_ioctl(struct drm_device
*dev, void *data,
return r;
}
+extern const struct amdgpu_userq_funcs userq_gfx_v11_funcs;
+
+static void
+amdgpu_userqueue_setup_gfx(struct amdgpu_userq_mgr *uq_mgr)
+{
+ int maj;
+ struct amdgpu_device *adev = uq_mgr->adev;
+ uint32_t version = adev->ip_versions[GC_HWIP][0];
+
+ /* We support usermode queue only for GFX V11 as of now */
+ maj = IP_VERSION_MAJ(version);
+ if (maj == 11)
+ uq_mgr->userq_funcs[AMDGPU_HW_IP_GFX] =
&userq_gfx_v11_funcs;
+}
+
int amdgpu_userq_mgr_init(struct amdgpu_userq_mgr *userq_mgr,
struct amdgpu_device *adev)
{
mutex_init(&userq_mgr->userq_mutex);
idr_init_base(&userq_mgr->userq_idr, 1);
userq_mgr->adev = adev;
+ amdgpu_userqueue_setup_gfx(userq_mgr);
return 0;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
index c4940b6ea1c4..e76e1b86b434 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
@@ -30,6 +30,7 @@
#include "amdgpu_psp.h"
#include "amdgpu_smu.h"
#include "amdgpu_atomfirmware.h"
+#include "amdgpu_userqueue.h"
#include "imu_v11_0.h"
#include "soc21.h"
#include "nvd.h"
@@ -6486,3 +6487,75 @@ const struct amdgpu_ip_block_version
gfx_v11_0_ip_block =
.rev = 0,
.funcs = &gfx_v11_0_ip_funcs,
};
+
+static int gfx_v11_0_userq_mqd_create(struct amdgpu_userq_mgr
*uq_mgr,
+ struct drm_amdgpu_userq_in *args_in,
+ struct amdgpu_usermode_queue *queue)
+{
+ struct amdgpu_device *adev = uq_mgr->adev;
+ struct amdgpu_mqd *mqd_gfx_generic =
&adev->mqds[AMDGPU_HW_IP_GFX];
+ struct drm_amdgpu_userq_mqd_gfx_v11_0 mqd_user;
+ struct amdgpu_mqd_prop userq_props;
+ int r;
+
+ /* Incoming MQD parameters from userspace to be saved here */
+ memset(&mqd_user, 0, sizeof(mqd_user));
+
+ /* Structure to initialize MQD for userqueue using generic
MQD init function */
+ memset(&userq_props, 0, sizeof(userq_props));
+
+ if (args_in->mqd_size != sizeof(struct
drm_amdgpu_userq_mqd_gfx_v11_0)) {
+ DRM_ERROR("MQD size mismatch\n");
+ return -EINVAL;
+ }
+
+ if (copy_from_user(&mqd_user,
u64_to_user_ptr(args_in->mqd), args_in->mqd_size)) {
+ DRM_ERROR("Failed to get user MQD\n");
+ return -EFAULT;
+ }
+
+ /* Create BO for actual Userqueue MQD now */
+ r = amdgpu_bo_create_kernel(adev,
mqd_gfx_generic->mqd_size, PAGE_SIZE,
+ AMDGPU_GEM_DOMAIN_GTT,
+ &queue->mqd.obj,
+ &queue->mqd.gpu_addr,
+ &queue->mqd.cpu_ptr);
+ if (r) {
+ DRM_ERROR("Failed to allocate BO for userqueue (%d)", r);
+ return -ENOMEM;
+ }
Using amdgpu_bo_create_kernel() for the MQD is most likely not a
good idea in the long term, but should work for now.
I was a bit curious about this, the scope of this MQD object is
kernel internal and used for queue mapping only, userspace doesn't
know much about it. Do y
Re: [PATCH 6/6] drm/amd/display: Eliminate warnings in amdgpu_dm_helpers.c
On 6/29/2023 12:46 AM, Srinivasan Shanmugam wrote:
Fix the following warnings reported by checkpatch:
WARNING: Block comments use a trailing */ on a separate line
WARNING: Prefer using '"%s...", __func__' to using
'execute_synaptics_rc_command', this function's name, in a string
WARNING: Prefer using '"%s...", __func__' to using
'apply_synaptics_fifo_reset_wa', this function's name, in a string
WARNING: braces {} are not necessary for single statement blocks
Cc: Rodrigo Siqueira
Cc: Aurabindo Pillai
Signed-off-by: Srinivasan Shanmugam
---
.../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 29 +--
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index a6be04ad387f..66909bb5e5b0 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -68,15 +68,13 @@ static void apply_edid_quirks(struct edid *edid, struct
dc_edid_caps *edid_caps)
}
}
-/* dm_helpers_parse_edid_caps
+/**
+ * dm_helpers_parse_edid_caps() - Parse edid caps
*
- * Parse edid caps
+ * @edid_caps: [in] pointer to edid caps
*
- * @edid: [in] pointer to edid
- * edid_caps: [in] pointer to edid caps
- * @return
- * void
- * */
+ * Return: void
+ */
enum dc_edid_status dm_helpers_parse_edid_caps(
struct dc_link *link,
const struct dc_edid *edid,
@@ -255,7 +253,8 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
/* Accessing the connector state is required for vcpi_slots allocation
* and directly relies on behaviour in commit check
* that blocks before commit guaranteeing that the state
-* is not gonna be swapped while still in use in commit tail */
+* is not gonna be swapped while still in use in commit tail
+*/
if (!aconnector || !aconnector->mst_root)
return false;
@@ -282,7 +281,8 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
/* mst_mgr->->payloads are VC payload notify MST branch using DPCD or
* AUX message. The sequence is slot 1-63 allocated sequence for each
* stream. AMD ASIC stream slot allocation should follow the same
-* sequence. copy DRM MST allocation to dc */
+* sequence. copy DRM MST allocation to dc
+*/
fill_dc_mst_payload_table_from_drm(stream->link, enable,
target_payload, proposed_table);
return true;
@@ -633,7 +633,7 @@ static bool execute_synaptics_rc_command(struct drm_dp_aux
*aux,
ret = drm_dp_dpcd_write(aux, SYNAPTICS_RC_COMMAND, &rc_cmd,
sizeof(rc_cmd));
if (ret < 0) {
- DRM_ERROR("execute_synaptics_rc_command - write cmd ..., err
= %d\n", ret);
+ DRM_ERROR("%s: write cmd ..., err = %d\n", __func__, ret);
return false;
}
@@ -655,7 +655,7 @@ static bool execute_synaptics_rc_command(struct drm_dp_aux *aux,
drm_dp_dpcd_read(aux, SYNAPTICS_RC_DATA, data, length);
}
- DC_LOG_DC(" execute_synaptics_rc_command - success = %d\n", success);
+ DC_LOG_DC("%s: success = %d\n", __func__, success);
return success;
}
@@ -664,7 +664,7 @@ static void apply_synaptics_fifo_reset_wa(struct drm_dp_aux
*aux)
{
unsigned char data[16] = {0};
- DC_LOG_DC("Start apply_synaptics_fifo_reset_wa\n");
+ DC_LOG_DC("Start %s\n", __func__);
// Step 2
data[0] = 'P';
@@ -722,7 +722,7 @@ static void apply_synaptics_fifo_reset_wa(struct drm_dp_aux
*aux)
if (!execute_synaptics_rc_command(aux, true, 0x02, 0, 0, NULL))
return;
- DC_LOG_DC("Done apply_synaptics_fifo_reset_wa\n");
+ DC_LOG_DC("Done %s\n", __func__);
}
/* MST Dock */
@@ -995,9 +995,8 @@ void dm_helpers_override_panel_settings(
struct dc_panel_config *panel_config)
{
// Feature DSC
- if (amdgpu_dc_debug_mask & DC_DISABLE_DSC) {
+ if (amdgpu_dc_debug_mask & DC_DISABLE_DSC)
panel_config->dsc.disable_dsc_edp = true;
- }
}
void *dm_helpers_allocate_gpu_mem(
Reviewed-by: Aurabindo Pillai
Re: [PATCH 2/6] drm/amd/display: Remove spaces before tabs in amdgpu_dm_hdcp.c
On 6/29/2023 12:46 AM, Srinivasan Shanmugam wrote: Conform to Linux kernel coding style. Reported by checkpatch: WARNING: please, no space before tabs And promote sysfs entry for set/get srm to kdoc Suggested-by: Rodrigo Siqueira Cc: Rodrigo Siqueira Cc: Aurabindo Pillai Signed-off-by: Srinivasan Shanmugam --- .../amd/display/amdgpu_dm/amdgpu_dm_hdcp.c| 50 +++ 1 file changed, 28 insertions(+), 22 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_hdcp.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_hdcp.c index 5536d17306d0..308f2b0687b5 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_hdcp.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_hdcp.c @@ -576,7 +576,10 @@ static void update_config(void *handle, struct cp_psp_stream_config *config) } -/* NOTE: From the usermodes prospective you only need to call write *ONCE*, the kernel +/** + * DOC: Add sysfs interface for set/get srm + * + * NOTE: From the usermodes prospective you only need to call write *ONCE*, the kernel * will automatically call once or twice depending on the size * * call: "cat file > /sys/class/drm/card0/device/hdcp_srm" from usermode no matter what the size is @@ -591,19 +594,19 @@ static void update_config(void *handle, struct cp_psp_stream_config *config) * cannot throw errors early as it will stop the kernel from writing to sysfs * * Example 1: - * Good SRM size = 5096 - * first call to write 4096 -> PSP fails - * Second call to write 1000 -> PSP Pass -> SRM is set + * Good SRM size = 5096 + * first call to write 4096 -> PSP fails + * Second call to write 1000 -> PSP Pass -> SRM is set * * Example 2: - * Bad SRM size = 4096 - * first call to write 4096 -> PSP fails (This is the same as above, but we don't know if this - * is the last call) + * Bad SRM size = 4096 + * first call to write 4096 -> PSP fails (This is the same as above, but we don't know if this + * is the last call) * * Solution?: - * 1: Parse the SRM? -> It is signed so we don't know the EOF - * 2: We can have another sysfs that passes the size before calling set. -> simpler solution - * below + * 1: Parse the SRM? -> It is signed so we don't know the EOF + * 2: We can have another sysfs that passes the size before calling set. -> simpler solution + * below * * Easy Solution: * Always call get after Set to verify if set was successful. @@ -612,14 +615,14 @@ static void update_config(void *handle, struct cp_psp_stream_config *config) * +--+ * PSP will only update its srm if its older than the one we are trying to load. * Always do set first than get. - * -if we try to "1. SET" a older version PSP will reject it and we can "2. GET" the newer - * version and save it + * -if we try to "1. SET" a older version PSP will reject it and we can "2. GET" the newer + * version and save it * - * -if we try to "1. SET" a newer version PSP will accept it and we can "2. GET" the - * same(newer) version back and save it + * -if we try to "1. SET" a newer version PSP will accept it and we can "2. GET" the + * same(newer) version back and save it * - * -if we try to "1. SET" a newer version and PSP rejects it. That means the format is - * incorrect/corrupted and we should correct our SRM by getting it from PSP + * -if we try to "1. SET" a newer version and PSP rejects it. That means the format is + * incorrect/corrupted and we should correct our SRM by getting it from PSP */ static ssize_t srm_data_write(struct file *filp, struct kobject *kobj, struct bin_attribute *bin_attr, char *buffer, loff_t pos, size_t count) @@ -681,12 +684,15 @@ static ssize_t srm_data_read(struct file *filp, struct kobject *kobj, struct bin return ret; } -/* From the hdcp spec (5.Renewability) SRM needs to be stored in a non-volatile memory. +/** + * DOC: SRM should be persistent across boot/reboots/suspend/resume/shutdown + * + * From the hdcp spec (5.Renewability) SRM needs to be stored in a non-volatile memory. * * For example, - * if Application "A" sets the SRM (ver 2) and we reboot/suspend and later when Application "B" - * needs to use HDCP, the version in PSP should be SRM(ver 2). So SRM should be persistent - * across boot/reboots/suspend/resume/shutdown + * if Application "A" sets the SRM (ver 2) and we reboot/suspend and later when Application "B" + * needs to use HDCP, the version in PSP should be SRM(ver 2). So SRM should be persistent + * across boot/reboots/suspend/resume/shutdown * * Currently when the system goes down (suspend/shutdown) the SRM is cleared from PSP. For HDCP we need * to make the SRM persistent. @@ -699,8 +705,8 @@ static ssize_t srm_data_read(struct file *filp, struct kobject *kobj,
Re: [PATCH] Revert "drm/amd/display: Program OTG vtotal min/max selectors unconditionally for DCN1+"
On 07/12, Pillai, Aurabindo wrote:
> [Public]
>
> Hi Guilherme,
>
> Sorry there was one more patch which I missed to attach. Please add this 3rd
> patch and retry.
>
> Reverting that patch would cause high power consumption on Navi2x GPU also
> cause hangs on certain multi monitor configurations. With these 3 patches,
> you're getting the same effect as reverting the aforementioned patches, but
> it makes the reverted sequence available only for Steam deck hardware.
>
Hi Jay,
Thanks for looking at this issue.
You mention power consumption and multi-monitor configuration issues
that can affect a driver if we revert this OTG change, and both sounds
quite relevant to me. Can they not affect DCN301 too? Is there something
that needs further work so the DCN301 can benefit from this improvement
as well?
Also, let us know if we can contribute in any way.
Best Regards,
Melissa
> --
>
> Regards,
> Jay
>
> From: Guilherme G. Piccoli
> Sent: Tuesday, July 11, 2023 7:15 PM
> To: Pillai, Aurabindo ; Deucher, Alexander
>
> Cc: amd-gfx@lists.freedesktop.org ; Koenig,
> Christian ; Pan, Xinhui ;
> dri-de...@lists.freedesktop.org ;
> kernel-...@igalia.com ;
> cristian.ciocal...@collabora.com ; André
> Almeida ; Melissa Wen ; Siqueira,
> Rodrigo
> Subject: Re: [PATCH] Revert "drm/amd/display: Program OTG vtotal min/max
> selectors unconditionally for DCN1+"
>
> On 11/07/2023 15:22, Aurabindo Pillai wrote:
> > [...]
> > Hi,
> >
> > Sorry for the delayed response, this patch went unnoticed. This revert
> > would break asics. Could you try the attached patch without reverting this
> > one ?
>
> Hi Aurabindo, thanks for your response!
>
> I've tried kernel 6.5-rc1, and it seems the issue is present, due to the
> patch being merged on Linus tree [as 1598fc576420 ("drm/amd/display:
> Program OTG vtotal min/max selectors unconditionally for DCN1+")].
>
> Then, I tried both your attached patches on top of that, and
> unfortunately, the behavior is the same: Steam Deck doesn't boot with
> graphics, and we can see the single error "amdgpu :04:00.0: [drm]
> *ERROR* [CRTC:67:crtc-0] flip_done timed out" on dmesg.
>
> Do you / Alex think we could get this revert for 6.5-rc2, so at least we
> could boot mainline there while the issue is handled? It would be an
> intermediate fix. You mentioned it breaks some asics, but did they work
> until now, without your patch?
>
> Thanks,
>
>
> Guilherme
signature.asc
Description: PGP signature
Re: [PATCH 3/5] drm/amdkfd: use vma_is_stack() and vma_is_heap()
Allocations in the heap and stack tend to be small, with several allocations sharing the same page. Sharing the same page for different allocations with different access patterns leads to thrashing when we migrate data back and forth on GPU and CPU access. To avoid this we disable HMM migrations for head and stack VMAs. Regards, Felix Am 2023-07-12 um 10:42 schrieb Christoph Hellwig: On Wed, Jul 12, 2023 at 10:38:29PM +0800, Kefeng Wang wrote: Use the helpers to simplify code. Nothing against your addition of a helper, but a GPU driver really should have no business even looking at this information..
Re: [PATCH] Revert "drm/amd/display: Program OTG vtotal min/max selectors unconditionally for DCN1+"
On 7/12/2023 12:24 PM, Melissa Wen wrote: On 07/12, Pillai, Aurabindo wrote: [Public] Hi Guilherme, Sorry there was one more patch which I missed to attach. Please add this 3rd patch and retry. Reverting that patch would cause high power consumption on Navi2x GPU also cause hangs on certain multi monitor configurations. With these 3 patches, you're getting the same effect as reverting the aforementioned patches, but it makes the reverted sequence available only for Steam deck hardware. Hi Jay, Thanks for looking at this issue. You mention power consumption and multi-monitor configuration issues that can affect a driver if we revert this OTG change, and both sounds quite relevant to me. Can they not affect DCN301 too? Is there something that needs further work so the DCN301 can benefit from this improvement as well? Also, let us know if we can contribute in any way. Hi Melissa, Unfortunately, DCN301 does not support Firmware Assisted Memory Clock Switching, which is the feature that gets blocked on Navi2x if we revert the patch in question. This is the feature that enables lower power consumption on some multi monitor configurations and high refresh rate single monitor configurations. Navi2x is configured to use FAMS in the driver, but without this change, firmware wont be able to actually enable the feature in DMCUB, which puts the driver in a unexpected state. On DCN301, this unexpected state will not occur, because there is no FAMS support in driver nor firmware. -- Jay
Re: [PATCH] Revert "drm/amd/display: Program OTG vtotal min/max selectors unconditionally for DCN1+"
On 07/12, Aurabindo Pillai wrote: > > > On 7/12/2023 12:24 PM, Melissa Wen wrote: > > On 07/12, Pillai, Aurabindo wrote: > > > [Public] > > > > > > Hi Guilherme, > > > > > > Sorry there was one more patch which I missed to attach. Please add this > > > 3rd patch and retry. > > > > > > Reverting that patch would cause high power consumption on Navi2x GPU > > > also cause hangs on certain multi monitor configurations. With these 3 > > > patches, you're getting the same effect as reverting the aforementioned > > > patches, but it makes the reverted sequence available only for Steam deck > > > hardware. > > > > > > > Hi Jay, > > > > Thanks for looking at this issue. > > > > You mention power consumption and multi-monitor configuration issues > > that can affect a driver if we revert this OTG change, and both sounds > > quite relevant to me. Can they not affect DCN301 too? Is there something > > that needs further work so the DCN301 can benefit from this improvement > > as well? > > > > Also, let us know if we can contribute in any way. > > > > Hi Melissa, > > Unfortunately, DCN301 does not support Firmware Assisted Memory Clock > Switching, which is the feature that gets blocked on Navi2x if we revert the > patch in question. This is the feature that enables lower power consumption > on some multi monitor configurations and high refresh rate single monitor > configurations. > > Navi2x is configured to use FAMS in the driver, but without this change, > firmware wont be able to actually enable the feature in DMCUB, which puts > the driver in a unexpected state. On DCN301, this unexpected state will not > occur, because there is no FAMS support in driver nor firmware. Oh, got it. Sounds fine. Many thanks for explaning the context of this change. Best Regards, Melissa > > -- > Jay > > > signature.asc Description: PGP signature
[PATCH 00/33] DC Patches July 12, 2023
This DC patchset brings improvements in multiple areas. In summary, we have: * Setup stream encoder before link enable for TMDS * Use is_dig_enable function instead of dcn10 hardcode * Re-add aux intercept disable delay generically for 2+ LTTPRs * Add polling method to handle MST reply packet * Improve the include of header file * Remove unused function * Add missing static * Hardcode vco_freq for dcn316 * Reduce stack size * Skip enabling DMCUB when using emulation * check TG is non-null before checking if enabled * Update scaler recout data for visual confirm * Skip querying caps when DMCUB emulation is in use * Update 128b/132b downspread factor to 0.3% * Add helpers to get DMUB FW boot options * Initialize necessary uninitialized variables * Add stream overhead in BW calculations for 128b/132b * Add link encoding to timing BW calculation parameters * Prevent vtotal from being set to 0 * Fix race condition when turning off an output alone * Keep PHY active for DP displays on DCN31 * Fix ASIC check in aux timeout workaround * ABM pause toggle * Add missing triggers for full updates * Disable MPC split by default on special asic * add additional refresh rate conditions for SubVP cases * Fix DP2 link training failure with RCO * Reenable all root clock gating options * Cache backlight_millinits in link structure and setting brightness accordingly * refine to decide the verified link setting * Update SW cursor fallback for subvp high refresh Cc: Daniel Wheeler Alan Liu (2): drm/amd/display: Hardcode vco_freq for dcn316 drm/amd/display: Fix race condition when turning off an output alone Alvin Lee (2): drm/amd/display: Add missing triggers for full updates drm/amd/display: Update SW cursor fallback for subvp high refresh Aric Cyr (2): drm/amd/display: Promote DAL to 3.2.242 drm/amd/display: Promote DAL to 3.2.243 Cruise Hung (1): drm/amd/display: Add helpers to get DMUB FW boot options Daniel Miess (3): drm/amd/display: Prevent vtotal from being set to 0 drm/amd/display: Fix DP2 link training failure with RCO drm/amd/display: Reenable all root clock gating options George Shen (3): drm/amd/display: Update 128b/132b downspread factor to 0.3% drm/amd/display: Add stream overhead in BW calculations for 128b/132b drm/amd/display: Add link encoding to timing BW calculation parameters JinZe Xu (1): drm/amd/display: Setup stream encoder before link enable for TMDS Leo Ma (1): drm/amd/display: Update scaler recout data for visual confirm Meera Patel (1): drm/amd/display: Initialize necessary uninitialized variables Michael Strauss (1): drm/amd/display: Re-add aux intercept disable delay generically for 2+ LTTPRs Nicholas Kazlauskas (3): drm/amd/display: Use is_dig_enable function instead of dcn10 hardcode drm/amd/display: Skip querying caps when DMCUB emulation is in use drm/amd/display: Keep PHY active for DP displays on DCN31 Nicholas Susanto (1): drm/amd/display: Cache backlight_millinits in link structure and setting brightness accordingly Reza Amini (1): drm/amd/display: ABM pause toggle Rodrigo Siqueira (4): drm/amd/display: Improve the include of header file drm/amd/display: Remove unused function drm/amd/display: Add missing static drm/amd/display: Reduce stack size Samson Tam (1): drm/amd/display: add additional refresh rate conditions for SubVP cases Taimur Hassan (3): drm/amd/display: Skip enabling DMCUB when using emulation drm/amd/display: check TG is non-null before checking if enabled drm/amd/display: Fix ASIC check in aux timeout workaround Wayne Lin (1): drm/amd/display: Add polling method to handle MST reply packet Zhikai Zhai (2): drm/amd/display: Disable MPC split by default on special asic drm/amd/display: refine to decide the verified link setting .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 244 +++--- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 7 + .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 124 - .../display/amdgpu_dm/amdgpu_dm_mst_types.h | 11 + .../drm/amd/display/dc/basics/conversion.c| 2 +- .../gpu/drm/amd/display/dc/basics/vector.c| 11 +- .../gpu/drm/amd/display/dc/bios/bios_parser.c | 16 +- .../drm/amd/display/dc/bios/bios_parser2.c| 20 +- .../display/dc/clk_mgr/dcn31/dcn31_clk_mgr.c | 5 + .../dc/clk_mgr/dcn316/dcn316_clk_mgr.c| 44 +--- .../display/dc/clk_mgr/dcn32/dcn32_clk_mgr.c | 2 +- drivers/gpu/drm/amd/display/dc/core/dc.c | 94 +-- .../drm/amd/display/dc/core/dc_hw_sequencer.c | 1 + .../drm/amd/display/dc/core/dc_link_exports.c | 18 ++ .../gpu/drm/amd/display/dc/core/dc_resource.c | 22 ++ .../gpu/drm/amd/display/dc/core/dc_stream.c | 35 ++- drivers/gpu/drm/amd/display/dc/dc.h | 25 +- drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c | 3 + drivers/gpu/drm/amd/display/dc/dc_dsc.h | 2 + drivers/gpu/drm/amd/display/dc/dc_types.h | 15 +- drivers/gpu/drm/amd/display
[PATCH 01/33] drm/amd/display: Setup stream encoder before link enable for TMDS
From: JinZe Xu [Why] HDMI spec requires TMDS clock to be not more than 340MHz. Stream encoder ensure this requirement but driver enable stream encoder later than PHY. So PHY will output full speed TMDS clock first. [How] Enable stream encoder first in TMDS case. Reviewed-by: Nicholas Kazlauskas Acked-by: Alan Liu Signed-off-by: JinZe Xu --- drivers/gpu/drm/amd/display/dc/link/link_dpms.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/link/link_dpms.c b/drivers/gpu/drm/amd/display/dc/link/link_dpms.c index 1a7b93e41e35..d8fcff0e5319 100644 --- a/drivers/gpu/drm/amd/display/dc/link/link_dpms.c +++ b/drivers/gpu/drm/amd/display/dc/link/link_dpms.c @@ -1971,6 +1971,7 @@ static void enable_link_hdmi(struct pipe_ctx *pipe_ctx) bool is_vga_mode = (stream->timing.h_addressable == 640) && (stream->timing.v_addressable == 480); struct dc *dc = pipe_ctx->stream->ctx->dc; + const struct link_hwss *link_hwss = get_link_hwss(link, &pipe_ctx->link_res); if (stream->phy_pix_clk == 0) stream->phy_pix_clk = stream->timing.pix_clk_100hz / 10; @@ -2010,6 +2011,12 @@ static void enable_link_hdmi(struct pipe_ctx *pipe_ctx) if (stream->timing.pixel_encoding == PIXEL_ENCODING_YCBCR422) display_color_depth = COLOR_DEPTH_888; + /* We need to enable stream encoder for TMDS first to apply 1/4 TMDS +* character clock in case that beyond 340MHz. +*/ + if (dc_is_hdmi_tmds_signal(pipe_ctx->stream->signal)) + link_hwss->setup_stream_encoder(pipe_ctx); + dc->hwss.enable_tmds_link_output( link, &pipe_ctx->link_res, -- 2.34.1
[PATCH 02/33] drm/amd/display: Use is_dig_enable function instead of dcn10 hardcode
From: Nicholas Kazlauskas
[Why]
This can differ depending on ASIC and we can end up skipping all
transmitter control if we're relying on the wrong bit as a shortcut
for whether link is on/off.
[How]
The ASIC table itself provides the correct DIG check, use that instead
of the dcn10 hardcode.
Reviewed-by: Syed Hassan
Acked-by: Alan Liu
Signed-off-by: Nicholas Kazlauskas
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_link_encoder.c | 2 +-
drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dio_link_encoder.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_link_encoder.c
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_link_encoder.c
index ee08b545aaea..377f1ba1a81b 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_link_encoder.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_link_encoder.c
@@ -1056,7 +1056,7 @@ void dcn10_link_encoder_disable_output(
struct bp_transmitter_control cntl = { 0 };
enum bp_result result;
- if (!dcn10_is_dig_enabled(enc)) {
+ if (enc->funcs->is_dig_enabled && !enc->funcs->is_dig_enabled(enc)) {
/* OF_SKIP_POWER_DOWN_INACTIVE_ENCODER */
/*in DP_Alt_No_Connect case, we turn off the dig already,
after excuation the PHY w/a sequence, not allow touch PHY any more*/
diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dio_link_encoder.c
b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dio_link_encoder.c
index bd62502380d8..4596f3bac1b4 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dio_link_encoder.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dio_link_encoder.c
@@ -558,7 +558,7 @@ void dcn31_link_encoder_disable_output(
struct dmub_cmd_dig_dpia_control_data dpia_control = { 0 };
struct dc_link *link;
- if (!dcn10_is_dig_enabled(enc))
+ if (enc->funcs->is_dig_enabled &&
!enc->funcs->is_dig_enabled(enc))
return;
link = link_enc_cfg_get_link_using_link_enc(enc->ctx->dc,
enc->preferred_engine);
--
2.34.1
[PATCH 03/33] drm/amd/display: Re-add aux intercept disable delay generically for 2+ LTTPRs
From: Michael Strauss
[WHY]
Issue not display generic, required for multiple 2+ LTTPR link configurations.
[HOW]
Revert monitor patch change and remove delay for single LTTPR case
Reviewed-by: George Shen
Acked-by: Alan Liu
Signed-off-by: Michael Strauss
---
drivers/gpu/drm/amd/display/dc/dc.h | 1 +
drivers/gpu/drm/amd/display/dc/dc_types.h | 1 -
.../link_dp_training_fixed_vs_pe_retimer.c| 25 +--
3 files changed, 13 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dc.h
b/drivers/gpu/drm/amd/display/dc/dc.h
index 358cfa86b7fa..194f185e7798 100644
--- a/drivers/gpu/drm/amd/display/dc/dc.h
+++ b/drivers/gpu/drm/amd/display/dc/dc.h
@@ -861,6 +861,7 @@ struct dc_debug_options {
bool psr_skip_crtc_disable;
union dpia_debug_options dpia_debug;
bool disable_fixed_vs_aux_timeout_wa;
+ uint32_t fixed_vs_aux_delay_config_wa;
bool force_disable_subvp;
bool force_subvp_mclk_switch;
bool allow_sw_cursor_fallback;
diff --git a/drivers/gpu/drm/amd/display/dc/dc_types.h
b/drivers/gpu/drm/amd/display/dc/dc_types.h
index 0ce7728a5a4b..0564f55aa595 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_types.h
+++ b/drivers/gpu/drm/amd/display/dc/dc_types.h
@@ -189,7 +189,6 @@ struct dc_panel_patch {
unsigned int disable_fams;
unsigned int skip_avmute;
unsigned int mst_start_top_delay;
- unsigned int delay_disable_aux_intercept_ms;
};
struct dc_edid_caps {
diff --git
a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_training_fixed_vs_pe_retimer.c
b/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_training_fixed_vs_pe_retimer.c
index 15faaf645b14..2a4f70acc7fa 100644
---
a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_training_fixed_vs_pe_retimer.c
+++
b/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_training_fixed_vs_pe_retimer.c
@@ -244,10 +244,6 @@ enum link_training_result
dp_perform_fixed_vs_pe_training_sequence_legacy(
uint8_t toggle_rate;
uint8_t rate;
- if (link->local_sink)
- pre_disable_intercept_delay_ms =
-
link->local_sink->edid_caps.panel_patch.delay_disable_aux_intercept_ms;
-
/* Only 8b/10b is supported */
ASSERT(link_dp_get_encoding_format(<_settings->link_settings) ==
DP_8b_10b_ENCODING);
@@ -260,10 +256,13 @@ enum link_training_result
dp_perform_fixed_vs_pe_training_sequence_legacy(
if (offset != 0xFF) {
vendor_lttpr_write_address +=
((DP_REPEATER_CONFIGURATION_AND_STATUS_SIZE) *
(offset - 1));
+ if (offset == 2) {
+ pre_disable_intercept_delay_ms =
link->dc->debug.fixed_vs_aux_delay_config_wa;
/* Certain display and cable configuration require extra delay
*/
- if (offset > 2)
- pre_disable_intercept_delay_ms =
pre_disable_intercept_delay_ms * 2;
+ } else if (offset > 2) {
+ pre_disable_intercept_delay_ms =
link->dc->debug.fixed_vs_aux_delay_config_wa * 2;
+ }
}
/* Vendor specific: Reset lane settings */
@@ -596,9 +595,10 @@ enum link_training_result
dp_perform_fixed_vs_pe_training_sequence(
const uint8_t vendor_lttpr_write_data_adicora_eq1[4] = {0x1, 0x55,
0x63, 0x2E};
const uint8_t vendor_lttpr_write_data_adicora_eq2[4] = {0x1, 0x55,
0x63, 0x01};
const uint8_t vendor_lttpr_write_data_adicora_eq3[4] = {0x1, 0x55,
0x63, 0x68};
+ uint32_t pre_disable_intercept_delay_ms = 0;
uint8_t vendor_lttpr_write_data_vs[4] = {0x1, 0x51, 0x63, 0x0};
uint8_t vendor_lttpr_write_data_pe[4] = {0x1, 0x52, 0x63, 0x0};
- uint32_t pre_disable_intercept_delay_ms = 0;
+
uint32_t vendor_lttpr_write_address = 0xF004F;
enum link_training_result status = LINK_TRAINING_SUCCESS;
uint8_t lane = 0;
@@ -607,10 +607,6 @@ enum link_training_result
dp_perform_fixed_vs_pe_training_sequence(
uint8_t toggle_rate;
uint8_t rate;
- if (link->local_sink)
- pre_disable_intercept_delay_ms =
-
link->local_sink->edid_caps.panel_patch.delay_disable_aux_intercept_ms;
-
/* Only 8b/10b is supported */
ASSERT(link_dp_get_encoding_format(<_settings->link_settings) ==
DP_8b_10b_ENCODING);
@@ -623,10 +619,13 @@ enum link_training_result
dp_perform_fixed_vs_pe_training_sequence(
if (offset != 0xFF) {
vendor_lttpr_write_address +=
((DP_REPEATER_CONFIGURATION_AND_STATUS_SIZE) *
(offset - 1));
+ if (offset == 2) {
+ pre_disable_intercept_delay_ms =
link->dc->debug.fixed_vs_aux_delay_config_wa;
/* Certain display and cable configuration require extra delay
*/
-
[PATCH 04/33] drm/amd/display: Add polling method to handle MST reply packet
From: Wayne Lin
[Why]
Specific TBT4 dock doesn't send out short HPD to notify source
that IRQ event DOWN_REP_MSG_RDY is set. Which violates the spec
and cause source can't send out streams to mst sinks.
[How]
To cover this misbehavior, add an additional polling method to detect
DOWN_REP_MSG_RDY is set. HPD driven handling method is still kept.
Just hook up our handler to drm mgr->cbs->poll_hpd_irq().
Cc: Mario Limonciello
Cc: Alex Deucher
Cc: sta...@vger.kernel.org
Reviewed-by: Jerry Zuo
Acked-by: Alan Liu
Signed-off-by: Wayne Lin
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 117 +-
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 7 ++
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 110
.../display/amdgpu_dm/amdgpu_dm_mst_types.h | 11 ++
4 files changed, 159 insertions(+), 86 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 28f8ac6007fb..42fa632523a2 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1347,6 +1347,15 @@ static void dm_handle_hpd_rx_offload_work(struct
work_struct *work)
if (amdgpu_in_reset(adev))
goto skip;
+ if (offload_work->data.bytes.device_service_irq.bits.UP_REQ_MSG_RDY ||
+
offload_work->data.bytes.device_service_irq.bits.DOWN_REP_MSG_RDY) {
+ dm_handle_mst_sideband_msg_ready_event(&aconnector->mst_mgr,
DOWN_OR_UP_MSG_RDY_EVENT);
+ spin_lock_irqsave(&offload_work->offload_wq->offload_lock,
flags);
+ offload_work->offload_wq->is_handling_mst_msg_rdy_event = false;
+ spin_unlock_irqrestore(&offload_work->offload_wq->offload_lock,
flags);
+ goto skip;
+ }
+
mutex_lock(&adev->dm.dc_lock);
if (offload_work->data.bytes.device_service_irq.bits.AUTOMATED_TEST) {
dc_link_dp_handle_automated_test(dc_link);
@@ -3232,87 +3241,6 @@ static void handle_hpd_irq(void *param)
}
-static void dm_handle_mst_sideband_msg(struct amdgpu_dm_connector *aconnector)
-{
- u8 esi[DP_PSR_ERROR_STATUS - DP_SINK_COUNT_ESI] = { 0 };
- u8 dret;
- bool new_irq_handled = false;
- int dpcd_addr;
- int dpcd_bytes_to_read;
-
- const int max_process_count = 30;
- int process_count = 0;
-
- const struct dc_link_status *link_status =
dc_link_get_status(aconnector->dc_link);
-
- if (link_status->dpcd_caps->dpcd_rev.raw < 0x12) {
- dpcd_bytes_to_read = DP_LANE0_1_STATUS - DP_SINK_COUNT;
- /* DPCD 0x200 - 0x201 for downstream IRQ */
- dpcd_addr = DP_SINK_COUNT;
- } else {
- dpcd_bytes_to_read = DP_PSR_ERROR_STATUS - DP_SINK_COUNT_ESI;
- /* DPCD 0x2002 - 0x2005 for downstream IRQ */
- dpcd_addr = DP_SINK_COUNT_ESI;
- }
-
- dret = drm_dp_dpcd_read(
- &aconnector->dm_dp_aux.aux,
- dpcd_addr,
- esi,
- dpcd_bytes_to_read);
-
- while (dret == dpcd_bytes_to_read &&
- process_count < max_process_count) {
- u8 ack[DP_PSR_ERROR_STATUS - DP_SINK_COUNT_ESI] = {};
- u8 retry;
-
- dret = 0;
-
- process_count++;
-
- DRM_DEBUG_DRIVER("ESI %02x %02x %02x\n", esi[0], esi[1],
esi[2]);
- /* handle HPD short pulse irq */
- if (aconnector->mst_mgr.mst_state)
- drm_dp_mst_hpd_irq_handle_event(&aconnector->mst_mgr,
- esi,
- ack,
- &new_irq_handled);
-
- if (new_irq_handled) {
- /* ACK at DPCD to notify down stream */
- for (retry = 0; retry < 3; retry++) {
- ssize_t wret;
-
- wret =
drm_dp_dpcd_writeb(&aconnector->dm_dp_aux.aux,
- dpcd_addr + 1,
- ack[1]);
- if (wret == 1)
- break;
- }
-
- if (retry == 3) {
- DRM_ERROR("Failed to ack MST event.\n");
- return;
- }
-
-
drm_dp_mst_hpd_irq_send_new_request(&aconnector->mst_mgr);
- /* check if there is new irq to be handled */
- dret = drm_dp_dpcd_read(
- &aconnector->dm_dp_aux.aux,
- dpcd_addr,
- esi,
- dpcd_bytes_to_read);
-
-
[PATCH 05/33] drm/amd/display: Improve the include of header file
From: Rodrigo Siqueira This commit improves the include of some header files to make them align with other includes. Reviewed-by: Hamza Mahfooz Acked-by: Alan Liu Signed-off-by: Rodrigo Siqueira --- drivers/gpu/drm/amd/display/dc/basics/conversion.c| 2 +- drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/basics/conversion.c b/drivers/gpu/drm/amd/display/dc/basics/conversion.c index 352e9afb85c6..e295a839ab47 100644 --- a/drivers/gpu/drm/amd/display/dc/basics/conversion.c +++ b/drivers/gpu/drm/amd/display/dc/basics/conversion.c @@ -24,7 +24,7 @@ */ #include "dm_services.h" -#include "conversion.h" +#include "basics/conversion.h" #define DIVIDER 1 diff --git a/drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c b/drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c index 3935fd455f0f..061221394ce0 100644 --- a/drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c +++ b/drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c @@ -58,13 +58,13 @@ #include "dce/dce_i2c.h" /* TODO remove this include */ -#include "dce80_resource.h" - #ifndef mmMC_HUB_RDREQ_DMIF_LIMIT #include "gmc/gmc_7_1_d.h" #include "gmc/gmc_7_1_sh_mask.h" #endif +#include "dce80/dce80_resource.h" + #ifndef mmDP_DPHY_INTERNAL_CTRL #define mmDP_DPHY_INTERNAL_CTRL 0x1CDE #define mmDP0_DP_DPHY_INTERNAL_CTRL 0x1CDE -- 2.34.1
[PATCH 06/33] drm/amd/display: Remove unused function
From: Rodrigo Siqueira
The get_engine_type is never used in the code, for this reason, this
commit drops this function.
Reviewed-by: Hamza Mahfooz
Acked-by: Alan Liu
Signed-off-by: Rodrigo Siqueira
---
drivers/gpu/drm/amd/display/dc/inc/hw/aux_engine.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/inc/hw/aux_engine.h
b/drivers/gpu/drm/amd/display/dc/inc/hw/aux_engine.h
index 7254182b7c72..af6b9509d09d 100644
--- a/drivers/gpu/drm/amd/display/dc/inc/hw/aux_engine.h
+++ b/drivers/gpu/drm/amd/display/dc/inc/hw/aux_engine.h
@@ -172,8 +172,6 @@ struct aux_engine_funcs {
struct aux_engine *engine,
uint8_t *returned_bytes);
bool (*is_engine_available)(struct aux_engine *engine);
- enum i2caux_engine_type (*get_engine_type)(
- const struct aux_engine *engine);
bool (*acquire)(
struct aux_engine *engine,
struct ddc *ddc);
--
2.34.1
[PATCH 07/33] drm/amd/display: Add missing static
From: Rodrigo Siqueira
After enable DRM_AMDGPU_WERROR, clang highlight multiple functions that
need to have `static`, and this commit address those issues and also
improve the indents.
Reviewed-by: Hamza Mahfooz
Acked-by: Alan Liu
Signed-off-by: Rodrigo Siqueira
---
.../gpu/drm/amd/display/dc/basics/vector.c| 11 +-
.../gpu/drm/amd/display/dc/bios/bios_parser.c | 16 +++
.../drm/amd/display/dc/bios/bios_parser2.c| 20 ---
drivers/gpu/drm/amd/display/dc/core/dc.c | 6 --
.../drm/amd/display/dc/core/dc_hw_sequencer.c | 1 +
drivers/gpu/drm/amd/display/dc/dce/dce_dmcu.c | 6 +++---
.../gpu/drm/amd/display/dc/dce/dce_i2c_hw.c | 16 +++
.../gpu/drm/amd/display/dc/dce/dce_i2c_sw.c | 16 ++-
.../gpu/drm/amd/display/dc/dcn21/dcn21_dccg.c | 2 +-
.../gpu/drm/amd/display/dc/dcn21/dcn21_dccg.h | 1 -
.../dc/irq/dcn314/irq_service_dcn314.c| 7 +++
11 files changed, 45 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/basics/vector.c
b/drivers/gpu/drm/amd/display/dc/basics/vector.c
index 84aeccf36b4b..6d2924114a3e 100644
--- a/drivers/gpu/drm/amd/display/dc/basics/vector.c
+++ b/drivers/gpu/drm/amd/display/dc/basics/vector.c
@@ -50,12 +50,11 @@ bool dal_vector_construct(
return true;
}
-static bool dal_vector_presized_costruct(
- struct vector *vector,
- struct dc_context *ctx,
- uint32_t count,
- void *initial_value,
- uint32_t struct_size)
+static bool dal_vector_presized_costruct(struct vector *vector,
+struct dc_context *ctx,
+uint32_t count,
+void *initial_value,
+uint32_t struct_size)
{
uint32_t i;
diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
index 27af9d3c2b73..4f005ae1516c 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
@@ -2593,11 +2593,10 @@ static struct integrated_info
*bios_parser_create_integrated_info(
return NULL;
}
-static enum bp_result update_slot_layout_info(
- struct dc_bios *dcb,
- unsigned int i,
- struct slot_layout_info *slot_layout_info,
- unsigned int record_offset)
+static enum bp_result update_slot_layout_info(struct dc_bios *dcb,
+ unsigned int i,
+ struct slot_layout_info
*slot_layout_info,
+ unsigned int record_offset)
{
unsigned int j;
struct bios_parser *bp;
@@ -2696,10 +2695,9 @@ static enum bp_result update_slot_layout_info(
}
-static enum bp_result get_bracket_layout_record(
- struct dc_bios *dcb,
- unsigned int bracket_layout_id,
- struct slot_layout_info *slot_layout_info)
+static enum bp_result get_bracket_layout_record(struct dc_bios *dcb,
+ unsigned int bracket_layout_id,
+ struct slot_layout_info
*slot_layout_info)
{
unsigned int i;
unsigned int record_offset;
diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
index cce47d3f1a13..540d19efad8f 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
@@ -340,9 +340,8 @@ static struct atom_display_object_path_v2 *get_bios_object(
}
/* from graphics_object_id, find display path which includes the object_id */
-static struct atom_display_object_path_v3 *get_bios_object_from_path_v3(
- struct bios_parser *bp,
- struct graphics_object_id id)
+static struct atom_display_object_path_v3 *get_bios_object_from_path_v3(struct
bios_parser *bp,
+ struct
graphics_object_id id)
{
unsigned int i;
struct graphics_object_id obj_id = {0};
@@ -521,9 +520,8 @@ static enum bp_result get_gpio_i2c_info(
return BP_RESULT_OK;
}
-static struct atom_hpd_int_record *get_hpd_record_for_path_v3(
- struct bios_parser *bp,
- struct atom_display_object_path_v3 *object)
+static struct atom_hpd_int_record *get_hpd_record_for_path_v3(struct
bios_parser *bp,
+ struct
atom_display_object_path_v3 *object)
{
struct atom_common_record_header *header;
uint32_t offset;
@@ -2175,9 +2173,8 @@ static struct atom_disp_connector_caps_record
*get_disp_connector_caps_record(
return NULL;
}
-static struct atom_connector_caps_record *get_connector_caps_record(
- struct bios_parser *bp,
- struct atom_display_object_path_v3 *object)
+sta
[PATCH 08/33] drm/amd/display: Hardcode vco_freq for dcn316
From: Alan Liu
There is no need to calculate the VCO frequency. In our internal branch
we've hard-coded this for a while, so it's well-tested. This also allows
us to remove the now unused code for calculating the VCO frequency.
Reviewed-by: Harry Wentland
Acked-by: Alan Liu
Signed-off-by: Alan Liu
---
.../dc/clk_mgr/dcn316/dcn316_clk_mgr.c| 44 +--
1 file changed, 2 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn316/dcn316_clk_mgr.c
b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn316/dcn316_clk_mgr.c
index d7de756301cf..0349631991b8 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn316/dcn316_clk_mgr.c
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn316/dcn316_clk_mgr.c
@@ -55,14 +55,6 @@ struct IP_BASE
struct IP_BASE_INSTANCE instance[MAX_INSTANCE];
};
-static const struct IP_BASE CLK_BASE = { { { { 0x00016C00, 0x02401800, 0, 0,
0, 0 } },
-{ { 0x00016E00, 0x02401C00, 0, 0, 0, 0
} },
-{ { 0x00017000, 0x02402000, 0, 0, 0, 0
} },
-{ { 0x00017200, 0x02402400, 0, 0, 0, 0
} },
-{ { 0x0001B000, 0x0242D800, 0, 0, 0, 0
} },
-{ { 0x0001B200, 0x0242DC00, 0, 0, 0, 0
} },
-{ { 0x0001B400, 0x0242E000, 0, 0, 0, 0
} } } };
-
#define regCLK1_CLK_PLL_REQ0x0237
#define regCLK1_CLK_PLL_REQ_BASE_IDX 0
@@ -73,9 +65,6 @@ static const struct IP_BASE CLK_BASE = { { { { 0x00016C00,
0x02401800, 0, 0, 0,
#define CLK1_CLK_PLL_REQ__PllSpineDiv_MASK 0xF000L
#define CLK1_CLK_PLL_REQ__FbMult_frac_MASK 0xL
-#define REG(reg_name) \
- (CLK_BASE.instance[0].segment[reg ## reg_name ## _BASE_IDX] + reg ##
reg_name)
-
#define TO_CLK_MGR_DCN316(clk_mgr)\
container_of(clk_mgr, struct clk_mgr_dcn316, base)
@@ -577,36 +566,6 @@ static struct clk_mgr_funcs dcn316_funcs = {
};
extern struct clk_mgr_funcs dcn3_fpga_funcs;
-static int get_vco_frequency_from_reg(struct clk_mgr_internal *clk_mgr)
-{
- /* get FbMult value */
- struct fixed31_32 pll_req;
- unsigned int fbmult_frac_val = 0;
- unsigned int fbmult_int_val = 0;
-
- /*
-* Register value of fbmult is in 8.16 format, we are converting to
31.32
-* to leverage the fix point operations available in driver
-*/
-
- REG_GET(CLK1_CLK_PLL_REQ, FbMult_frac, &fbmult_frac_val); /* 16 bit
fractional part*/
- REG_GET(CLK1_CLK_PLL_REQ, FbMult_int, &fbmult_int_val); /* 8 bit
integer part */
-
- pll_req = dc_fixpt_from_int(fbmult_int_val);
-
- /*
-* since fractional part is only 16 bit in register definition but is
32 bit
-* in our fix point definiton, need to shift left by 16 to obtain
correct value
-*/
- pll_req.value |= fbmult_frac_val << 16;
-
- /* multiply by REFCLK period */
- pll_req = dc_fixpt_mul_int(pll_req, clk_mgr->dfs_ref_freq_khz);
-
- /* integer part is now VCO frequency in kHz */
- return dc_fixpt_floor(pll_req);
-}
-
void dcn316_clk_mgr_construct(
struct dc_context *ctx,
struct clk_mgr_dcn316 *clk_mgr,
@@ -660,7 +619,8 @@ void dcn316_clk_mgr_construct(
clk_mgr->base.smu_present = true;
// Skip this for now as it did not work on DCN315, renable during bring
up
- clk_mgr->base.base.dentist_vco_freq_khz =
get_vco_frequency_from_reg(&clk_mgr->base);
+ //clk_mgr->base.base.dentist_vco_freq_khz =
get_vco_frequency_from_reg(&clk_mgr->base);
+ clk_mgr->base.base.dentist_vco_freq_khz = 250;
/* in case we don't get a value from the register, use default */
if (clk_mgr->base.base.dentist_vco_freq_khz == 0)
--
2.34.1
[PATCH 11/33] drm/amd/display: check TG is non-null before checking if enabled
From: Taimur Hassan
[Why & How]
If there is no TG allocation we can dereference a NULL pointer when
checking if the TG is enabled.
Cc: Mario Limonciello
Cc: Alex Deucher
Cc: sta...@vger.kernel.org
Reviewed-by: Nicholas Kazlauskas
Acked-by: Alan Liu
Signed-off-by: Taimur Hassan
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
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 a50309039d08..9834b75f1837 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
@@ -3278,7 +3278,8 @@ void dcn10_wait_for_mpcc_disconnect(
if
(pipe_ctx->stream_res.opp->mpcc_disconnect_pending[mpcc_inst]) {
struct hubp *hubp = get_hubp_by_inst(res_pool,
mpcc_inst);
- if
(pipe_ctx->stream_res.tg->funcs->is_tg_enabled(pipe_ctx->stream_res.tg))
+ if (pipe_ctx->stream_res.tg &&
+
pipe_ctx->stream_res.tg->funcs->is_tg_enabled(pipe_ctx->stream_res.tg))
res_pool->mpc->funcs->wait_for_idle(res_pool->mpc, mpcc_inst);
pipe_ctx->stream_res.opp->mpcc_disconnect_pending[mpcc_inst] = false;
hubp->funcs->set_blank(hubp, true);
--
2.34.1
[PATCH 10/33] drm/amd/display: Skip enabling DMCUB when using emulation
From: Taimur Hassan [Why & How] Shouldn't be touching path for HW DMCUB when emulating. Reviewed-by: Nicholas Kazlauskas Acked-by: Alan Liu Signed-off-by: Taimur Hassan --- drivers/gpu/drm/amd/display/dmub/src/dmub_srv.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dmub/src/dmub_srv.c b/drivers/gpu/drm/amd/display/dmub/src/dmub_srv.c index bdaf43892f47..3253162e3701 100644 --- a/drivers/gpu/drm/amd/display/dmub/src/dmub_srv.c +++ b/drivers/gpu/drm/amd/display/dmub/src/dmub_srv.c @@ -639,11 +639,11 @@ enum dmub_status dmub_srv_hw_init(struct dmub_srv *dmub, if (dmub->hw_funcs.enable_dmub_boot_options) dmub->hw_funcs.enable_dmub_boot_options(dmub, params); - if (dmub->hw_funcs.skip_dmub_panel_power_sequence) + if (dmub->hw_funcs.skip_dmub_panel_power_sequence && !dmub->is_virtual) dmub->hw_funcs.skip_dmub_panel_power_sequence(dmub, params->skip_panel_power_sequence); - if (dmub->hw_funcs.reset_release) + if (dmub->hw_funcs.reset_release && !dmub->is_virtual) dmub->hw_funcs.reset_release(dmub); dmub->hw_init = true; -- 2.34.1
[PATCH 12/33] drm/amd/display: Update scaler recout data for visual confirm
From: Leo Ma
[Why]
Visual confirm color is not as expected for Autoa Color Management
feature test.
[How]
Calculate scaler recout data when visual confirm enabled to update
the visual confirm bar on the display.
Reviewed-by: Aric Cyr
Acked-by: Alan Liu
Signed-off-by: Leo Ma
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 3 ++-
.../gpu/drm/amd/display/dc/core/dc_resource.c | 22 +++
.../drm/amd/display/dc/dcn10/dcn10_dpp_dscl.c | 18 +--
3 files changed, 25 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index de3b891cba51..2d8a8c8ff47d 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -4304,7 +4304,8 @@ static bool full_update_required(struct dc_surface_update
*srf_updates,
srf_updates[i].in_transfer_func ||
srf_updates[i].func_shaper ||
srf_updates[i].lut3d_func ||
- srf_updates[i].blend_tf))
+ srf_updates[i].blend_tf ||
+ srf_updates[i].surface->force_full_update))
return true;
}
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
index 2f3d9a698486..1859350dffc6 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
@@ -69,6 +69,9 @@
#include "../dcn32/dcn32_resource.h"
#include "../dcn321/dcn321_resource.h"
+#define VISUAL_CONFIRM_RECT_HEIGHT_DEFAULT 3
+#define VISUAL_CONFIRM_RECT_HEIGHT_MIN 1
+#define VISUAL_CONFIRM_RECT_HEIGHT_MAX 10
#define DC_LOGGER_INIT(logger)
@@ -808,6 +811,8 @@ static void calculate_recout(struct pipe_ctx *pipe_ctx)
struct rect surf_clip = plane_state->clip_rect;
bool split_tb = stream->view_format == VIEW_3D_FORMAT_TOP_AND_BOTTOM;
int split_count, split_idx;
+ struct dpp *dpp = pipe_ctx->plane_res.dpp;
+ unsigned short visual_confirm_rect_height =
VISUAL_CONFIRM_RECT_HEIGHT_DEFAULT;
calculate_split_count_and_index(pipe_ctx, &split_count, &split_idx);
if (stream->view_format == VIEW_3D_FORMAT_SIDE_BY_SIDE)
@@ -876,6 +881,23 @@ static void calculate_recout(struct pipe_ctx *pipe_ctx)
data->recout.width = data->h_active -
data->recout.x;
}
}
+
+ /* Check bounds to ensure the VC bar height was set to a sane value */
+ if (dpp != NULL) {
+ if ((dpp->ctx->dc->debug.visual_confirm_rect_height >=
VISUAL_CONFIRM_RECT_HEIGHT_MIN) &&
+ (dpp->ctx->dc->debug.visual_confirm_rect_height <=
VISUAL_CONFIRM_RECT_HEIGHT_MAX)) {
+ visual_confirm_rect_height =
dpp->ctx->dc->debug.visual_confirm_rect_height;
+ }
+
+ if (dpp->ctx->dc->debug.visual_confirm !=
+ VISUAL_CONFIRM_DISABLE)
+ data->recout.height = data->recout.height -
+ 2 * ((pipe_ctx->prev_odm_pipe ||
+ (pipe_ctx->top_pipe &&
+ pipe_ctx->top_pipe->plane_state ==
+ pipe_ctx->plane_state)) +
+visual_confirm_rect_height);
+ }
}
static void calculate_scaling_ratios(struct pipe_ctx *pipe_ctx)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp_dscl.c
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp_dscl.c
index b33955928bd0..7e140c35a0ce 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp_dscl.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp_dscl.c
@@ -39,9 +39,6 @@
#define BLACK_OFFSET_RGB_Y 0x0
#define BLACK_OFFSET_CBCR 0x8000
-#define VISUAL_CONFIRM_RECT_HEIGHT_DEFAULT 3
-#define VISUAL_CONFIRM_RECT_HEIGHT_MIN 1
-#define VISUAL_CONFIRM_RECT_HEIGHT_MAX 10
#define REG(reg)\
dpp->tf_regs->reg
@@ -591,18 +588,6 @@ static void dpp1_dscl_set_manual_ratio_init(
static void dpp1_dscl_set_recout(struct dcn10_dpp *dpp,
const struct rect *recout)
{
- int visual_confirm_on = 0;
- unsigned short visual_confirm_rect_height =
VISUAL_CONFIRM_RECT_HEIGHT_DEFAULT;
-
- if (dpp->base.ctx->dc->debug.visual_confirm != VISUAL_CONFIRM_DISABLE)
- visual_confirm_on = 1;
-
- /* Check bounds to ensure the VC bar height was set to a sane value */
- if ((dpp->base.ctx->dc->debug.visual_confirm_rect_height >=
VISUAL_CONFIRM_RECT_HEIGHT_MIN) &&
- (dpp->base.ctx->dc->debug.visual_confirm_rect_height <=
VISUAL_CONFIRM_RECT_HEIGHT_MAX)) {
- visual_confirm_rect_height =
dpp->base.ctx->dc->debug.visual_confirm_rect_height;
- }
-
REG_SET_2(RECOUT_START, 0
[PATCH 13/33] drm/amd/display: Skip querying caps when DMCUB emulation is in use
From: Nicholas Kazlauskas
[Why]
Workaround to avoid accessing DMCUB state too early if the emulator
is in use - we don't support any of the features the caps are querying
with emulation anyway.
[How]
Guard the query if emulation is in use.
Reviewed-by: Charlene Liu
Acked-by: Alan Liu
Signed-off-by: Nicholas Kazlauskas
---
drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
b/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
index c753c6f30dd7..24433409d7de 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
+++ b/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
@@ -381,6 +381,9 @@ void dc_dmub_srv_query_caps_cmd(struct dc_dmub_srv
*dc_dmub_srv)
{
union dmub_rb_cmd cmd = { 0 };
+ if (dc_dmub_srv->ctx->dc->debug.dmcub_emulation)
+ return;
+
memset(&cmd, 0, sizeof(cmd));
/* Prepare fw command */
--
2.34.1
[PATCH 14/33] drm/amd/display: Promote DAL to 3.2.242
From: Aric Cyr This version brings along following fixes: - Setup stream encoder before link enable for TMDS - Use is_dig_enable function instead of dcn10 hardcode - Re-add aux intercept disable delay generically for 2+ LTTPRs - Add polling method to handle MST reply packet - Remove unused function - Improve the include of header file - Add missing static - Hardcode vco_freq for dcn316 - Reduce stack size - Skip enabling DMCUB when using emulation - Check TG is non-null before checking if enabled - Update scaler recout data for visual confirm - Skip querying caps when DMCUB emulation is in use Acked-by: Alan Liu Signed-off-by: Aric Cyr --- drivers/gpu/drm/amd/display/dc/dc.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dc.h b/drivers/gpu/drm/amd/display/dc/dc.h index 194f185e7798..819c326baefe 100644 --- a/drivers/gpu/drm/amd/display/dc/dc.h +++ b/drivers/gpu/drm/amd/display/dc/dc.h @@ -45,7 +45,7 @@ struct aux_payload; struct set_config_cmd_payload; struct dmub_notification; -#define DC_VER "3.2.241" +#define DC_VER "3.2.242" #define MAX_SURFACES 3 #define MAX_PLANES 6 -- 2.34.1
[PATCH 15/33] drm/amd/display: Update 128b/132b downspread factor to 0.3%
From: George Shen
[Why]
Updating downspread factor to 0.3% to add additional margin to account
for potential link rate deviations (up to 300ppm as per the DP spec).
Reviewed-by: Wenjing Liu
Acked-by: Alan Liu
Signed-off-by: George Shen
---
drivers/gpu/drm/amd/display/include/link_service_types.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/include/link_service_types.h
b/drivers/gpu/drm/amd/display/include/link_service_types.h
index cd870af5fd25..1b8ab20f1715 100644
--- a/drivers/gpu/drm/amd/display/include/link_service_types.h
+++ b/drivers/gpu/drm/amd/display/include/link_service_types.h
@@ -53,7 +53,7 @@ enum {
BITS_PER_DP_BYTE = 10,
DATA_EFFICIENCY_8b_10b_x1 = 8000, /* 80% data efficiency */
DATA_EFFICIENCY_8b_10b_FEC_EFFICIENCY_x100 = 97, /* 97% data efficiency
when FEC is enabled */
- DATA_EFFICIENCY_128b_132b_x1 = 9646, /* 96.71% data efficiency x
99.75% downspread factor */
+ DATA_EFFICIENCY_128b_132b_x1 = 9641, /* 96.71% data efficiency x
99.7% downspread factor */
};
enum lttpr_mode {
--
2.34.1
[PATCH 16/33] drm/amd/display: Add helpers to get DMUB FW boot options
From: Cruise Hung
[Why & How]
To query the bits and print them out for debug purposes.
Reviewed-by: Nicholas Kazlauskas
Acked-by: Alan Liu
Signed-off-by: Cruise Hung
---
drivers/gpu/drm/amd/display/dmub/dmub_srv.h | 4
drivers/gpu/drm/amd/display/dmub/src/dmub_dcn31.c | 8
drivers/gpu/drm/amd/display/dmub/src/dmub_dcn31.h | 2 ++
drivers/gpu/drm/amd/display/dmub/src/dmub_srv.c | 15 +++
4 files changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dmub/dmub_srv.h
b/drivers/gpu/drm/amd/display/dmub/dmub_srv.h
index 4585e0419da6..53bd9bf8f0c8 100644
--- a/drivers/gpu/drm/amd/display/dmub/dmub_srv.h
+++ b/drivers/gpu/drm/amd/display/dmub/dmub_srv.h
@@ -378,6 +378,7 @@ struct dmub_srv_hw_funcs {
union dmub_fw_boot_status (*get_fw_status)(struct dmub_srv *dmub);
+ union dmub_fw_boot_options (*get_fw_boot_option)(struct dmub_srv *dmub);
void (*set_gpint)(struct dmub_srv *dmub,
union dmub_gpint_data_register reg);
@@ -778,6 +779,9 @@ void dmub_flush_buffer_mem(const struct dmub_fb *fb);
enum dmub_status dmub_srv_get_fw_boot_status(struct dmub_srv *dmub,
union dmub_fw_boot_status *status);
+enum dmub_status dmub_srv_get_fw_boot_option(struct dmub_srv *dmub,
+union dmub_fw_boot_options
*option);
+
enum dmub_status dmub_srv_cmd_with_reply_data(struct dmub_srv *dmub,
union dmub_rb_cmd *cmd);
diff --git a/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn31.c
b/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn31.c
index 5e952541e72d..094e9f864557 100644
--- a/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn31.c
+++ b/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn31.c
@@ -352,6 +352,14 @@ union dmub_fw_boot_status
dmub_dcn31_get_fw_boot_status(struct dmub_srv *dmub)
return status;
}
+union dmub_fw_boot_options dmub_dcn31_get_fw_boot_option(struct dmub_srv *dmub)
+{
+ union dmub_fw_boot_options option;
+
+ option.all = REG_READ(DMCUB_SCRATCH14);
+ return option;
+}
+
void dmub_dcn31_enable_dmub_boot_options(struct dmub_srv *dmub, const struct
dmub_srv_hw_params *params)
{
union dmub_fw_boot_options boot_options = {0};
diff --git a/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn31.h
b/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn31.h
index 89c5a948b67d..4d520a893c7b 100644
--- a/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn31.h
+++ b/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn31.h
@@ -239,6 +239,8 @@ void dmub_dcn31_skip_dmub_panel_power_sequence(struct
dmub_srv *dmub, bool skip)
union dmub_fw_boot_status dmub_dcn31_get_fw_boot_status(struct dmub_srv *dmub);
+union dmub_fw_boot_options dmub_dcn31_get_fw_boot_option(struct dmub_srv
*dmub);
+
void dmub_dcn31_setup_outbox0(struct dmub_srv *dmub,
const struct dmub_region *outbox0);
diff --git a/drivers/gpu/drm/amd/display/dmub/src/dmub_srv.c
b/drivers/gpu/drm/amd/display/dmub/src/dmub_srv.c
index 3253162e3701..70af110af687 100644
--- a/drivers/gpu/drm/amd/display/dmub/src/dmub_srv.c
+++ b/drivers/gpu/drm/amd/display/dmub/src/dmub_srv.c
@@ -255,6 +255,7 @@ static bool dmub_srv_hw_setup(struct dmub_srv *dmub, enum
dmub_asic asic)
funcs->get_gpint_response = dmub_dcn31_get_gpint_response;
funcs->get_gpint_dataout = dmub_dcn31_get_gpint_dataout;
funcs->get_fw_status = dmub_dcn31_get_fw_boot_status;
+ funcs->get_fw_boot_option = dmub_dcn31_get_fw_boot_option;
funcs->enable_dmub_boot_options =
dmub_dcn31_enable_dmub_boot_options;
funcs->skip_dmub_panel_power_sequence =
dmub_dcn31_skip_dmub_panel_power_sequence;
//outbox0 call stacks
@@ -846,6 +847,20 @@ enum dmub_status dmub_srv_get_fw_boot_status(struct
dmub_srv *dmub,
return DMUB_STATUS_OK;
}
+enum dmub_status dmub_srv_get_fw_boot_option(struct dmub_srv *dmub,
+union dmub_fw_boot_options *option)
+{
+ option->all = 0;
+
+ if (!dmub->sw_init)
+ return DMUB_STATUS_INVALID;
+
+ if (dmub->hw_funcs.get_fw_boot_option)
+ *option = dmub->hw_funcs.get_fw_boot_option(dmub);
+
+ return DMUB_STATUS_OK;
+}
+
enum dmub_status dmub_srv_cmd_with_reply_data(struct dmub_srv *dmub,
union dmub_rb_cmd *cmd)
{
--
2.34.1
[PATCH 17/33] drm/amd/display: Initialize necessary uninitialized variables
From: Meera Patel
This commit initializes uninitialized variables.
For some compilers uninitialized variable warnings are treated as Error.
Reviewed-by: Wenjing Liu
Acked-by: Alan Liu
Signed-off-by: Meera Patel
---
.../drm/amd/display/dc/clk_mgr/dcn32/dcn32_clk_mgr.c | 2 +-
drivers/gpu/drm/amd/display/dc/core/dc.c | 10 +-
.../gpu/drm/amd/display/dc/dcn315/dcn315_resource.c| 2 +-
drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource.c | 2 +-
.../drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c | 2 +-
.../drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c | 2 +-
.../amd/display/dc/dml/dcn314/display_mode_vba_314.c | 2 +-
.../display/dc/dml/dcn32/display_mode_vba_util_32.c| 2 +-
8 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn32/dcn32_clk_mgr.c
b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn32/dcn32_clk_mgr.c
index 402340f17a3a..ccd60aff19e7 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn32/dcn32_clk_mgr.c
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn32/dcn32_clk_mgr.c
@@ -297,7 +297,7 @@ void dcn32_update_clocks_update_dpp_dto(struct
clk_mgr_internal *clk_mgr,
clk_mgr->dccg->ref_dppclk = clk_mgr->base.clks.dppclk_khz;
for (i = 0; i < clk_mgr->base.ctx->dc->res_pool->pipe_count; i++) {
- int dpp_inst, dppclk_khz, prev_dppclk_khz;
+ int dpp_inst = 0, dppclk_khz, prev_dppclk_khz;
dppclk_khz =
context->res_ctx.pipe_ctx[i].plane_res.bw.dppclk_khz;
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 2d8a8c8ff47d..4284a3609e98 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -4090,9 +4090,9 @@ static bool commit_minimal_transition_state(struct dc *dc,
struct dc_state *transition_base_context)
{
struct dc_state *transition_context = dc_create_state(dc);
- enum pipe_split_policy tmp_mpc_policy;
- bool temp_dynamic_odm_policy;
- bool temp_subvp_policy;
+ enum pipe_split_policy tmp_mpc_policy = 0;
+ bool temp_dynamic_odm_policy = 0;
+ bool temp_subvp_policy = 0;
enum dc_status ret = DC_ERROR_UNEXPECTED;
unsigned int i, j;
unsigned int pipe_in_use = 0;
@@ -4372,8 +4372,8 @@ bool dc_update_planes_and_stream(struct dc *dc,
* cause underflow. Apply stream configuration with minimal pipe
* split first to avoid unsupported transitions for active pipes.
*/
- bool force_minimal_pipe_splitting;
- bool is_plane_addition;
+ bool force_minimal_pipe_splitting = 0;
+ bool is_plane_addition = 0;
populate_fast_updates(fast_update, srf_updates, surface_count,
stream_update);
force_minimal_pipe_splitting = could_mpcc_tree_change_for_active_pipes(
diff --git a/drivers/gpu/drm/amd/display/dc/dcn315/dcn315_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn315/dcn315_resource.c
index df3a438abda8..2e3fa0fb8bd4 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn315/dcn315_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn315/dcn315_resource.c
@@ -1659,7 +1659,7 @@ static int dcn315_populate_dml_pipes_from_context(
{
int i, pipe_cnt, crb_idx, crb_pipes;
struct resource_context *res_ctx = &context->res_ctx;
- struct pipe_ctx *pipe;
+ struct pipe_ctx *pipe = NULL;
const int max_usable_det =
context->bw_ctx.dml.ip.config_return_buffer_size_in_kbytes -
DCN3_15_MIN_COMPBUF_SIZE_KB;
int remaining_det_segs = max_usable_det / DCN3_15_CRB_SEGMENT_SIZE_KB;
bool pixel_rate_crb = allow_pixel_rate_crb(dc, context);
diff --git a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource.c
index 1cc09799f92d..0d1f18f8348e 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource.c
@@ -1892,7 +1892,7 @@ int dcn32_populate_dml_pipes_from_context(
{
int i, pipe_cnt;
struct resource_context *res_ctx = &context->res_ctx;
- struct pipe_ctx *pipe;
+ struct pipe_ctx *pipe = NULL;
bool subvp_in_use = false;
struct dc_crtc_timing *timing;
bool vsr_odm_support = false;
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c
index f294f2f8c75b..57cf0358cc43 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c
@@ -3194,7 +3194,7 @@ static void CalculateFlipSchedule(
unsigned int HostVMDynamicLevels;
double TimeForFetchingMetaPTEImmediateFlip;
double TimeForFetchingRowInVBlankImmediateFlip;
- double ImmediateFlipBW;
+ double ImmediateFlipBW = 1.0;
double HostVMInefficiencyFactor;
dou
[PATCH 18/33] drm/amd/display: Add stream overhead in BW calculations for 128b/132b
From: George Shen
[Why]
Current BW calculations do not account for the additional padding added
for uncompressed pixel-to-symbol packing.
This results in X.Y being too low for 128b/132b SST streams in certain
scenarios. If X.Y is too low, end user can observe image corruption.
[How]
Add function to calculate stream overhead to timing BW calculation for
128b/132b SST cases.
Reviewed-by: Wenjing Liu
Acked-by: Alan Liu
Signed-off-by: George Shen
---
drivers/gpu/drm/amd/display/dc/dc.h | 2 +
drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c | 42 +
2 files changed, 44 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/dc.h
b/drivers/gpu/drm/amd/display/dc/dc.h
index 819c326baefe..7aa7085c3bec 100644
--- a/drivers/gpu/drm/amd/display/dc/dc.h
+++ b/drivers/gpu/drm/amd/display/dc/dc.h
@@ -1410,6 +1410,8 @@ struct dc_plane_state *dc_get_surface_for_mpcc(struct dc
*dc,
uint32_t dc_get_opp_for_plane(struct dc *dc, struct dc_plane_state *plane);
+void dc_set_disable_128b_132b_stream_overhead(bool disable);
+
/* The function returns minimum bandwidth required to drive a given timing
* return - minimum required timing bandwidth in kbps.
*/
diff --git a/drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c
b/drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c
index 58dd62cce4bb..aed0d3dafa24 100644
--- a/drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c
+++ b/drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c
@@ -40,6 +40,8 @@ static bool dsc_policy_enable_dsc_when_not_needed;
static bool dsc_policy_disable_dsc_stream_overhead;
+static bool disable_128b_132b_stream_overhead;
+
#ifndef MAX
#define MAX(X, Y) ((X) > (Y) ? (X) : (Y))
#endif
@@ -47,6 +49,41 @@ static bool dsc_policy_disable_dsc_stream_overhead;
#define MIN(X, Y) ((X) < (Y) ? (X) : (Y))
#endif
+/* Need to account for padding due to pixel-to-symbol packing
+ * for uncompressed 128b/132b streams.
+ */
+static uint32_t apply_128b_132b_stream_overhead(
+ const struct dc_crtc_timing *timing, const uint32_t kbps)
+{
+ uint32_t total_kbps = kbps;
+
+ if (disable_128b_132b_stream_overhead)
+ return kbps;
+
+ if (!timing->flags.DSC) {
+ struct fixed31_32 bpp;
+ struct fixed31_32 overhead_factor;
+
+ bpp = dc_fixpt_from_int(kbps);
+ bpp = dc_fixpt_div_int(bpp, timing->pix_clk_100hz / 10);
+
+ /* Symbols_per_HActive = HActive * bpp / (4 lanes * 32-bit
symbol size)
+* Overhead_factor = ceil(Symbols_per_HActive) /
Symbols_per_HActive
+*/
+ overhead_factor = dc_fixpt_from_int(timing->h_addressable);
+ overhead_factor = dc_fixpt_mul(overhead_factor, bpp);
+ overhead_factor = dc_fixpt_div_int(overhead_factor, 128);
+ overhead_factor = dc_fixpt_div(
+ dc_fixpt_from_int(dc_fixpt_ceil(overhead_factor)),
+ overhead_factor);
+
+ total_kbps = dc_fixpt_ceil(
+ dc_fixpt_mul_int(overhead_factor, total_kbps));
+ }
+
+ return total_kbps;
+}
+
uint32_t dc_bandwidth_in_kbps_from_timing(
const struct dc_crtc_timing *timing)
{
@@ -1165,6 +1202,11 @@ void dc_dsc_policy_set_disable_dsc_stream_overhead(bool
disable)
dsc_policy_disable_dsc_stream_overhead = disable;
}
+void dc_set_disable_128b_132b_stream_overhead(bool disable)
+{
+ disable_128b_132b_stream_overhead = disable;
+}
+
void dc_dsc_get_default_config_option(const struct dc *dc, struct
dc_dsc_config_options *options)
{
options->dsc_min_slice_height_override =
dc->debug.dsc_min_slice_height_override;
--
2.34.1
[PATCH 20/33] drm/amd/display: Prevent vtotal from being set to 0
From: Daniel Miess [Why] In dcn314 DML the destination pipe vtotal was being set to the crtc adjustment vtotal_min value even in cases where that value is 0. [How] Only set vtotal to the crtc adjustment vtotal_min value in cases where the value is non-zero. Cc: Mario Limonciello Cc: Alex Deucher Cc: sta...@vger.kernel.org Reviewed-by: Nicholas Kazlauskas Acked-by: Alan Liu Signed-off-by: Daniel Miess --- drivers/gpu/drm/amd/display/dc/dml/dcn314/dcn314_fpu.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn314/dcn314_fpu.c b/drivers/gpu/drm/amd/display/dc/dml/dcn314/dcn314_fpu.c index d9e049e7ff0a..ed8ddb75b333 100644 --- a/drivers/gpu/drm/amd/display/dc/dml/dcn314/dcn314_fpu.c +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn314/dcn314_fpu.c @@ -295,7 +295,11 @@ int dcn314_populate_dml_pipes_from_context_fpu(struct dc *dc, struct dc_state *c pipe = &res_ctx->pipe_ctx[i]; timing = &pipe->stream->timing; - pipes[pipe_cnt].pipe.dest.vtotal = pipe->stream->adjust.v_total_min; + if (pipe->stream->adjust.v_total_min != 0) + pipes[pipe_cnt].pipe.dest.vtotal = pipe->stream->adjust.v_total_min; + else + pipes[pipe_cnt].pipe.dest.vtotal = timing->v_total; + pipes[pipe_cnt].pipe.dest.vblank_nom = timing->v_total - pipes[pipe_cnt].pipe.dest.vactive; pipes[pipe_cnt].pipe.dest.vblank_nom = min(pipes[pipe_cnt].pipe.dest.vblank_nom, dcn3_14_ip.VBlankNomDefaultUS); pipes[pipe_cnt].pipe.dest.vblank_nom = max(pipes[pipe_cnt].pipe.dest.vblank_nom, timing->v_sync_width); -- 2.34.1
[PATCH 19/33] drm/amd/display: Add link encoding to timing BW calculation parameters
From: George Shen
[Why]
There certain cases where the timing BW is dependent on the type of link
encoding in use. Thus to calculate the correct BW required for a given
timing, the link encoding should be added as a parameter.
Reviewed-by: Wenjing Liu
Acked-by: Alan Liu
Signed-off-by: George Shen
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8 ++-
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 14 +++
.../drm/amd/display/dc/core/dc_link_exports.c | 18 ++
drivers/gpu/drm/amd/display/dc/dc.h | 12 +-
drivers/gpu/drm/amd/display/dc/dc_dsc.h | 2 ++
drivers/gpu/drm/amd/display/dc/dc_types.h | 10 +++-
drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c | 24 ++-
.../gpu/drm/amd/display/dc/link/link_dpms.c | 11 +++--
.../drm/amd/display/dc/link/link_validation.c | 8 ---
.../dc/link/protocols/link_dp_capability.c| 5 ++--
.../dc/link/protocols/link_dp_training.c | 9 ++-
.../link/protocols/link_edp_panel_control.c | 2 +-
12 files changed, 101 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 6372347edd3f..88057641972d 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5797,6 +5797,7 @@ static void apply_dsc_policy_for_edp(struct
amdgpu_dm_connector *aconnector,
edp_min_bpp_x16, edp_max_bpp_x16,
dsc_caps,
&stream->timing,
+
dc_link_get_highest_encoding_format(aconnector->dc_link),
&bw_range)) {
if (bw_range.max_kbps < link_bw_in_kbps) {
@@ -5805,6 +5806,7 @@ static void apply_dsc_policy_for_edp(struct
amdgpu_dm_connector *aconnector,
&dsc_options,
0,
&stream->timing,
+
dc_link_get_highest_encoding_format(aconnector->dc_link),
&dsc_cfg)) {
stream->timing.dsc_cfg = dsc_cfg;
stream->timing.flags.DSC = 1;
@@ -5819,6 +5821,7 @@ static void apply_dsc_policy_for_edp(struct
amdgpu_dm_connector *aconnector,
&dsc_options,
link_bw_in_kbps,
&stream->timing,
+
dc_link_get_highest_encoding_format(aconnector->dc_link),
&dsc_cfg)) {
stream->timing.dsc_cfg = dsc_cfg;
stream->timing.flags.DSC = 1;
@@ -5862,12 +5865,14 @@ static void apply_dsc_policy_for_stream(struct
amdgpu_dm_connector *aconnector,
&dsc_options,
link_bandwidth_kbps,
&stream->timing,
+
dc_link_get_highest_encoding_format(aconnector->dc_link),
&stream->timing.dsc_cfg)) {
stream->timing.flags.DSC = 1;
DRM_DEBUG_DRIVER("%s: [%s] DSC is selected from
SST RX\n", __func__, drm_connector->name);
}
} else if (sink->link->dpcd_caps.dongle_type ==
DISPLAY_DONGLE_DP_HDMI_CONVERTER) {
- timing_bw_in_kbps =
dc_bandwidth_in_kbps_from_timing(&stream->timing);
+ timing_bw_in_kbps =
dc_bandwidth_in_kbps_from_timing(&stream->timing,
+
dc_link_get_highest_encoding_format(aconnector->dc_link));
max_supported_bw_in_kbps = link_bandwidth_kbps;
dsc_max_supported_bw_in_kbps = link_bandwidth_kbps;
@@ -5879,6 +5884,7 @@ static void apply_dsc_policy_for_stream(struct
amdgpu_dm_connector *aconnector,
&dsc_options,
dsc_max_supported_bw_in_kbps,
&stream->timing,
+
dc_link_get_highest_encoding_format(aconnector->dc_link),
&stream->timing.dsc_cfg)) {
stream->timing.flags.DSC = 1;
DRM_DEBUG_DRIVER("%s: [%s] DSC is
selected from DP-HDMI PCON\n",
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 1d343f16e5b8..1abdec14344e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm
[PATCH 21/33] drm/amd/display: Fix race condition when turning off an output alone
From: Alan Liu
[Why]
When 2 threads are doing commit_tail parallelly, one thread could
commit new streams to dc state but another thread remove it from dc
right away.
[How]
If we don't have new dm state change from commit_check, then we should
not call dc_commit_streams() in commit_tail. A new function
amdgpu_dm_commit_streams() is introduced to refator dc_commit_stream()
adjacent code and fix this issue.
Reviewed-by: Harry Wentland
Acked-by: Alan Liu
Signed-off-by: Alan Liu
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 114 +-
1 file changed, 55 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 88057641972d..1e1a38014475 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7937,7 +7937,6 @@ static inline uint32_t get_mem_type(struct
drm_framebuffer *fb)
}
static void amdgpu_dm_commit_planes(struct drm_atomic_state *state,
- struct dc_state *dc_state,
struct drm_device *dev,
struct amdgpu_display_manager *dm,
struct drm_crtc *pcrtc,
@@ -8417,52 +8416,17 @@ static void amdgpu_dm_crtc_copy_transient_flags(struct
drm_crtc_state *crtc_stat
stream_state->mode_changed = drm_atomic_crtc_needs_modeset(crtc_state);
}
-/**
- * amdgpu_dm_atomic_commit_tail() - AMDgpu DM's commit tail implementation.
- * @state: The atomic state to commit
- *
- * This will tell DC to commit the constructed DC state from atomic_check,
- * programming the hardware. Any failures here implies a hardware failure,
since
- * atomic check should have filtered anything non-kosher.
- */
-static void amdgpu_dm_atomic_commit_tail(struct drm_atomic_state *state)
+static void amdgpu_dm_commit_streams(struct drm_atomic_state *state,
+ struct dc_state *dc_state)
{
struct drm_device *dev = state->dev;
struct amdgpu_device *adev = drm_to_adev(dev);
struct amdgpu_display_manager *dm = &adev->dm;
- struct dm_atomic_state *dm_state;
- struct dc_state *dc_state = NULL, *dc_state_temp = NULL;
- u32 i, j;
struct drm_crtc *crtc;
struct drm_crtc_state *old_crtc_state, *new_crtc_state;
- unsigned long flags;
- bool wait_for_vblank = true;
- struct drm_connector *connector;
- struct drm_connector_state *old_con_state, *new_con_state;
struct dm_crtc_state *dm_old_crtc_state, *dm_new_crtc_state;
- int crtc_disable_count = 0;
bool mode_set_reset_required = false;
- int r;
-
- trace_amdgpu_dm_atomic_commit_tail_begin(state);
-
- r = drm_atomic_helper_wait_for_fences(dev, state, false);
- if (unlikely(r))
- DRM_ERROR("Waiting for fences timed out!");
-
- drm_atomic_helper_update_legacy_modeset_state(dev, state);
- drm_dp_mst_atomic_wait_for_dependencies(state);
-
- dm_state = dm_atomic_get_new_state(state);
- if (dm_state && dm_state->context) {
- dc_state = dm_state->context;
- } else {
- /* No state changes, retain current state. */
- dc_state_temp = dc_create_state(dm->dc);
- ASSERT(dc_state_temp);
- dc_state = dc_state_temp;
- dc_resource_state_copy_construct_current(dm->dc, dc_state);
- }
+ u32 i;
for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
@@ -8561,24 +8525,22 @@ static void amdgpu_dm_atomic_commit_tail(struct
drm_atomic_state *state)
}
} /* for_each_crtc_in_state() */
- if (dc_state) {
- /* if there mode set or reset, disable eDP PSR */
- if (mode_set_reset_required) {
- if (dm->vblank_control_workqueue)
- flush_workqueue(dm->vblank_control_workqueue);
+ /* if there mode set or reset, disable eDP PSR */
+ if (mode_set_reset_required) {
+ if (dm->vblank_control_workqueue)
+ flush_workqueue(dm->vblank_control_workqueue);
- amdgpu_dm_psr_disable_all(dm);
- }
+ amdgpu_dm_psr_disable_all(dm);
+ }
- dm_enable_per_frame_crtc_master_sync(dc_state);
- mutex_lock(&dm->dc_lock);
- WARN_ON(!dc_commit_streams(dm->dc, dc_state->streams,
dc_state->stream_count));
+ dm_enable_per_frame_crtc_master_sync(dc_state);
+ mutex_lock(&dm->dc_lock);
+ WARN_ON(!dc_commit_streams(dm->dc, dc_state->streams,
dc_state->stream_count));
- /* Allow idle optimization when vblank count is 0 for display
off */
- if (dm->active_vblank_irq_count ==
[PATCH 23/33] drm/amd/display: Fix ASIC check in aux timeout workaround
From: Taimur Hassan
[Why]
Aux write was meant to be ASIC specific, and is
causing compliance failures on newer parts.
[How]
Make workaround specific to single ASIC.
Reviewed-by: Michael Strauss
Acked-by: Alan Liu
Signed-off-by: Taimur Hassan
---
drivers/gpu/drm/amd/display/dc/link/protocols/link_ddc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/link/protocols/link_ddc.c
b/drivers/gpu/drm/amd/display/dc/link/protocols/link_ddc.c
index 0fa1228bc178..0f19c07011b5 100644
--- a/drivers/gpu/drm/amd/display/dc/link/protocols/link_ddc.c
+++ b/drivers/gpu/drm/amd/display/dc/link/protocols/link_ddc.c
@@ -427,7 +427,7 @@ bool try_to_configure_aux_timeout(struct ddc_service *ddc,
if ((ddc->link->chip_caps & EXT_DISPLAY_PATH_CAPS__DP_FIXED_VS_EN) &&
!ddc->link->dc->debug.disable_fixed_vs_aux_timeout_wa &&
-
ASICREV_IS_YELLOW_CARP(ddc->ctx->asic_id.hw_internal_rev)) {
+ ddc->ctx->dce_version == DCN_VERSION_3_1) {
/* Fixed VS workaround for AUX timeout */
const uint32_t fixed_vs_address = 0xF004F;
const uint8_t fixed_vs_data[4] = {0x1, 0x22, 0x63, 0xc};
--
2.34.1
[PATCH 22/33] drm/amd/display: Keep PHY active for DP displays on DCN31
From: Nicholas Kazlauskas
[Why & How]
Port of a change that went into DCN314 to keep the PHY enabled
when we have a connected and active DP display.
The PHY can hang if PHY refclk is disabled inadvertently.
Cc: Mario Limonciello
Cc: Alex Deucher
Cc: sta...@vger.kernel.org
Reviewed-by: Josip Pavic
Acked-by: Alan Liu
Signed-off-by: Nicholas Kazlauskas
---
drivers/gpu/drm/amd/display/dc/clk_mgr/dcn31/dcn31_clk_mgr.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn31/dcn31_clk_mgr.c
b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn31/dcn31_clk_mgr.c
index 7ccd96959256..3db4ef564b99 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn31/dcn31_clk_mgr.c
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn31/dcn31_clk_mgr.c
@@ -87,6 +87,11 @@ static int dcn31_get_active_display_cnt_wa(
stream->signal == SIGNAL_TYPE_DVI_SINGLE_LINK ||
stream->signal == SIGNAL_TYPE_DVI_DUAL_LINK)
tmds_present = true;
+
+ /* Checking stream / link detection ensuring that PHY is
active*/
+ if (dc_is_dp_signal(stream->signal) && !stream->dpms_off)
+ display_count++;
+
}
for (i = 0; i < dc->link_count; i++) {
--
2.34.1
[PATCH 24/33] drm/amd/display: ABM pause toggle
From: Reza Amini
[why]
Allow ABM states to be transferred across display
adapters for smooth display transitions.
[how]
We call DMUB to pause and get ABM states. We
transfer data to other gpu, and deliver data and
ask ABM to un-pause.
Reviewed-by: Harry Vanzylldejong
Acked-by: Alan Liu
Signed-off-by: Reza Amini
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 53 +++
drivers/gpu/drm/amd/display/dc/dc.h | 7 +
drivers/gpu/drm/amd/display/dc/dce/dmub_abm.c | 28
.../gpu/drm/amd/display/dc/dce/dmub_abm_lcd.c | 46 ++
.../gpu/drm/amd/display/dc/dce/dmub_abm_lcd.h | 6 +
drivers/gpu/drm/amd/display/dc/inc/hw/abm.h | 6 +
.../gpu/drm/amd/display/dmub/inc/dmub_cmd.h | 131 ++
7 files changed, 277 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 4284a3609e98..5d29b0aa6056 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -5276,3 +5276,56 @@ void dc_notify_vsync_int_state(struct dc *dc, struct
dc_stream_state *stream, bo
if (pipe->stream_res.abm && pipe->stream_res.abm->funcs->set_abm_pause)
pipe->stream_res.abm->funcs->set_abm_pause(pipe->stream_res.abm, !enable, i,
pipe->stream_res.tg->inst);
}
+
+/*
+ * dc_abm_save_restore() - Interface to DC for save+pause and restore+un-pause
+ * ABM
+ * @dc: dc structure
+ * @stream: stream where vsync int state changed
+ * @pData: abm hw states
+ *
+ /
+bool dc_abm_save_restore(
+ struct dc *dc,
+ struct dc_stream_state *stream,
+ struct abm_save_restore *pData)
+{
+ int i;
+ int edp_num;
+ struct pipe_ctx *pipe = NULL;
+ struct dc_link *link = stream->sink->link;
+ struct dc_link *edp_links[MAX_NUM_EDP];
+
+
+ /*find primary pipe associated with stream*/
+ for (i = 0; i < MAX_PIPES; i++) {
+ pipe = &dc->current_state->res_ctx.pipe_ctx[i];
+
+ if (pipe->stream == stream && pipe->stream_res.tg)
+ break;
+ }
+
+ if (i == MAX_PIPES) {
+ ASSERT(0);
+ return false;
+ }
+
+ dc_get_edp_links(dc, edp_links, &edp_num);
+
+ /* Determine panel inst */
+ for (i = 0; i < edp_num; i++)
+ if (edp_links[i] == link)
+ break;
+
+ if (i == edp_num)
+ return false;
+
+ if (pipe->stream_res.abm &&
+ pipe->stream_res.abm->funcs->save_restore)
+ return pipe->stream_res.abm->funcs->save_restore(
+ pipe->stream_res.abm,
+ i,
+ pData);
+ return false;
+}
+
diff --git a/drivers/gpu/drm/amd/display/dc/dc.h
b/drivers/gpu/drm/amd/display/dc/dc.h
index b0f53ef8c848..b9e5d217573c 100644
--- a/drivers/gpu/drm/amd/display/dc/dc.h
+++ b/drivers/gpu/drm/amd/display/dc/dc.h
@@ -40,6 +40,8 @@
#include "inc/hw/dmcu.h"
#include "dml/display_mode_lib.h"
+struct abm_save_restore;
+
/* forward declaration */
struct aux_payload;
struct set_config_cmd_payload;
@@ -2243,6 +2245,11 @@ void dc_z10_save_init(struct dc *dc);
bool dc_is_dmub_outbox_supported(struct dc *dc);
bool dc_enable_dmub_notifications(struct dc *dc);
+bool dc_abm_save_restore(
+ struct dc *dc,
+ struct dc_stream_state *stream,
+ struct abm_save_restore *pData);
+
void dc_enable_dmub_outbox(struct dc *dc);
bool dc_process_dmub_aux_transfer_async(struct dc *dc,
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dmub_abm.c
b/drivers/gpu/drm/amd/display/dc/dce/dmub_abm.c
index 2fb9572ce25d..d3e6544022b7 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dmub_abm.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dmub_abm.c
@@ -27,6 +27,7 @@
#include "dmub_abm_lcd.h"
#include "dc.h"
#include "core_types.h"
+#include "dmub_cmd.h"
#define TO_DMUB_ABM(abm)\
container_of(abm, struct dce_abm, base)
@@ -118,6 +119,32 @@ static bool dmub_abm_set_pause_ex(struct abm *abm, bool
pause, unsigned int pane
return ret;
}
+/*
+ * dmub_abm_save_restore_ex() - calls dmub_abm_save_restore for preserving
DMUB's
+ * Varibright states for LCD only. OLED is TBD
+ * @abm: used to check get dc context
+ * @panel_inst: panel instance index
+ * @pData: contains command to pause/un-pause abm and abm parameters
+ *
+ *
+ ***/
+static bool dmub_abm_save_restore_ex(
+ struct abm *abm,
+ unsigned int panel_inst,
+ struct abm_save_
[PATCH 09/33] drm/amd/display: Reduce stack size
From: Rodrigo Siqueira
Reduce stack size pointed by clang:
amdgpu_dm/amdgpu_dm.c:8655:13: error: stack frame size (1048) exceeds limit
(1024) in 'amdgpu_dm_atomic_commit_tail' [-Werror,-Wframe-larger-than]
Reviewed-by: Harry Wentland
Acked-by: Alan Liu
Signed-off-by: Rodrigo Siqueira
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 42fa632523a2..6372347edd3f 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -8714,13 +8714,12 @@ static void amdgpu_dm_atomic_commit_tail(struct
drm_atomic_state *state)
struct dm_connector_state *dm_new_con_state =
to_dm_connector_state(new_con_state);
struct dm_connector_state *dm_old_con_state =
to_dm_connector_state(old_con_state);
struct amdgpu_crtc *acrtc =
to_amdgpu_crtc(dm_new_con_state->base.crtc);
- struct dc_surface_update dummy_updates[MAX_SURFACES];
+ struct dc_surface_update *dummy_updates;
struct dc_stream_update stream_update;
struct dc_info_packet hdr_packet;
struct dc_stream_status *status = NULL;
bool abm_changed, hdr_changed, scaling_changed;
- memset(&dummy_updates, 0, sizeof(dummy_updates));
memset(&stream_update, 0, sizeof(stream_update));
if (acrtc) {
@@ -8779,6 +8778,7 @@ static void amdgpu_dm_atomic_commit_tail(struct
drm_atomic_state *state)
* Here we create an empty update on each plane.
* To fix this, DC should permit updating only stream
properties.
*/
+ dummy_updates = kzalloc(sizeof(struct dc_surface_update) *
MAX_SURFACES, GFP_ATOMIC);
for (j = 0; j < status->plane_count; j++)
dummy_updates[j].surface = status->plane_states[0];
@@ -8790,6 +8790,7 @@ static void amdgpu_dm_atomic_commit_tail(struct
drm_atomic_state *state)
dm_new_crtc_state->stream,
&stream_update);
mutex_unlock(&dm->dc_lock);
+ kfree(dummy_updates);
}
/**
--
2.34.1
[PATCH 25/33] drm/amd/display: Add missing triggers for full updates
From: Alvin Lee
[Description]
- Full update was missed for the following cases:
- Idle optimization is enabled
- Plane is not in current context
- Also don't clear surface updates at end of
commit_plane_for_stream_fast as they are cleared at
the beginning of each flip (only stream updates need
to be cleared in case there is no stream update in
the next flip)
Reviewed-by: Samson Tam
Acked-by: Alan Liu
Signed-off-by: Alvin Lee
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 5d29b0aa6056..7cac14f493f6 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -3584,9 +3584,9 @@ static void commit_planes_for_stream_fast(struct dc *dc,
context->block_sequence_steps);
/* Clear update flags so next flip doesn't have redundant programming
* (if there's no stream update, the update flags are not cleared).
+* Surface updates are cleared unconditionally at the beginning of each
flip,
+* so no need to clear here.
*/
- if (top_pipe_to_program->plane_state)
- top_pipe_to_program->plane_state->update_flags.raw = 0;
if (top_pipe_to_program->stream)
top_pipe_to_program->stream->update_flags.raw = 0;
}
@@ -4286,7 +4286,8 @@ static bool fast_updates_exist(struct dc_fast_update
*fast_update, int surface_c
return false;
}
-static bool full_update_required(struct dc_surface_update *srf_updates,
+static bool full_update_required(struct dc *dc,
+ struct dc_surface_update *srf_updates,
int surface_count,
struct dc_stream_update *stream_update,
struct dc_stream_state *stream)
@@ -4294,6 +4295,7 @@ static bool full_update_required(struct dc_surface_update
*srf_updates,
int i;
struct dc_stream_status *stream_status;
+ const struct dc_state *context = dc->current_state;
for (i = 0; i < surface_count; i++) {
if (srf_updates &&
@@ -4305,7 +4307,10 @@ static bool full_update_required(struct
dc_surface_update *srf_updates,
srf_updates[i].func_shaper ||
srf_updates[i].lut3d_func ||
srf_updates[i].blend_tf ||
- srf_updates[i].surface->force_full_update))
+ srf_updates[i].surface->force_full_update ||
+ (srf_updates[i].flip_addr &&
+ srf_updates[i].flip_addr->address.tmz_surface
!= srf_updates[i].surface->address.tmz_surface) ||
+ !is_surface_in_context(context,
srf_updates[i].surface)))
return true;
}
@@ -4343,18 +4348,21 @@ static bool full_update_required(struct
dc_surface_update *srf_updates,
if (stream_status == NULL || stream_status->plane_count !=
surface_count)
return true;
}
+ if (dc->idle_optimizations_allowed)
+ return true;
return false;
}
-static bool fast_update_only(struct dc_fast_update *fast_update,
+static bool fast_update_only(struct dc *dc,
+ struct dc_fast_update *fast_update,
struct dc_surface_update *srf_updates,
int surface_count,
struct dc_stream_update *stream_update,
struct dc_stream_state *stream)
{
return fast_updates_exist(fast_update, surface_count)
- && !full_update_required(srf_updates, surface_count,
stream_update, stream);
+ && !full_update_required(dc, srf_updates,
surface_count, stream_update, stream);
}
bool dc_update_planes_and_stream(struct dc *dc,
@@ -4426,7 +4434,7 @@ bool dc_update_planes_and_stream(struct dc *dc,
}
update_seamless_boot_flags(dc, context, surface_count, stream);
- if (fast_update_only(fast_update, srf_updates, surface_count,
stream_update, stream) &&
+ if (fast_update_only(dc, fast_update, srf_updates, surface_count,
stream_update, stream) &&
!dc->debug.enable_legacy_fast_update) {
commit_planes_for_stream_fast(dc,
srf_updates,
@@ -4572,7 +4580,7 @@ void dc_commit_updates_for_stream(struct dc *dc,
TRACE_DC_PIPE_STATE(pipe_ctx, i, MAX_PIPES);
update_seamless_boot_flags(dc, context, surface_count, stream);
- if (fast_update_only(fast_update, srf_updates, surface_count,
stream_update, stream) &&
+ if (fast_update_only(dc, fast_update, srf_updates, surface_count,
stream_update, stream) &&
!dc->debug.enable_legacy_fast_update) {
commit_
[PATCH 26/33] drm/amd/display: Disable MPC split by default on special asic
From: Zhikai Zhai
[WHY]
All of pipes will be used when the MPC split enable on the dcn
which just has 2 pipes. Then MPO enter will trigger the minimal
transition which need programe dcn from 2 pipes MPC split to 2
pipes MPO. This action will cause lag if happen frequently.
[HOW]
Disable the MPC split for the platform which dcn resource is limited
Cc: Mario Limonciello
Cc: Alex Deucher
Cc: sta...@vger.kernel.org
Reviewed-by: Alvin Lee
Acked-by: Alan Liu
Signed-off-by: Zhikai Zhai
---
drivers/gpu/drm/amd/display/dc/dcn303/dcn303_resource.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn303/dcn303_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn303/dcn303_resource.c
index 45956ef6f3f9..131b8b82afc0 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn303/dcn303_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn303/dcn303_resource.c
@@ -65,7 +65,7 @@ static const struct dc_debug_options debug_defaults_drv = {
.timing_trace = false,
.clock_trace = true,
.disable_pplib_clock_request = true,
- .pipe_split_policy = MPC_SPLIT_DYNAMIC,
+ .pipe_split_policy = MPC_SPLIT_AVOID,
.force_single_disp_pipe_split = false,
.disable_dcc = DCC_ENABLE,
.vsr_support = true,
--
2.34.1
[PATCH 27/33] drm/amd/display: add additional refresh rate conditions for SubVP cases
From: Samson Tam
[Why]
Want to further constrain these refresh rate conditions for SubVP:
- SubVP + SubVP: either both <= 120Hz or both between 120-165Hz
- SubVP + DRR: SubVP <= 120Hz
- SubVP + VBlank: SubVP <= 120Hz
[How]
Add constraints in subvp_subvp_admissable(),
dcn32_subvp_drr_admissable() and dcn32_subvp_vblank_admissable()
Reviewed-by: Alvin Lee
Acked-by: Alan Liu
Signed-off-by: Samson Tam
---
.../display/dc/dcn32/dcn32_resource_helpers.c | 24 +++
.../drm/amd/display/dc/dml/dcn32/dcn32_fpu.c | 20 +---
2 files changed, 31 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource_helpers.c
b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource_helpers.c
index 5be242a1b82c..db9c55a09d9f 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource_helpers.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource_helpers.c
@@ -641,6 +641,7 @@ bool dcn32_subvp_drr_admissable(struct dc *dc, struct
dc_state *context)
uint8_t non_subvp_pipes = 0;
bool drr_pipe_found = false;
bool drr_psr_capable = false;
+ uint64_t refresh_rate = 0;
for (i = 0; i < dc->res_pool->pipe_count; i++) {
struct pipe_ctx *pipe = &context->res_ctx.pipe_ctx[i];
@@ -649,8 +650,14 @@ bool dcn32_subvp_drr_admissable(struct dc *dc, struct
dc_state *context)
continue;
if (pipe->plane_state && !pipe->top_pipe) {
- if (pipe->stream->mall_stream_config.type == SUBVP_MAIN)
+ if (pipe->stream->mall_stream_config.type ==
SUBVP_MAIN) {
subvp_count++;
+
+ refresh_rate =
(pipe->stream->timing.pix_clk_100hz * (uint64_t)100 +
+ pipe->stream->timing.v_total *
pipe->stream->timing.h_total - (uint64_t)1);
+ refresh_rate = div_u64(refresh_rate,
pipe->stream->timing.v_total);
+ refresh_rate = div_u64(refresh_rate,
pipe->stream->timing.h_total);
+ }
if (pipe->stream->mall_stream_config.type ==
SUBVP_NONE) {
non_subvp_pipes++;
drr_psr_capable = (drr_psr_capable ||
dcn32_is_psr_capable(pipe));
@@ -662,7 +669,8 @@ bool dcn32_subvp_drr_admissable(struct dc *dc, struct
dc_state *context)
}
}
- if (subvp_count == 1 && non_subvp_pipes == 1 && drr_pipe_found &&
!drr_psr_capable)
+ if (subvp_count == 1 && non_subvp_pipes == 1 && drr_pipe_found &&
!drr_psr_capable &&
+ ((uint32_t)refresh_rate < 120))
result = true;
return result;
@@ -693,6 +701,7 @@ bool dcn32_subvp_vblank_admissable(struct dc *dc, struct
dc_state *context, int
bool drr_pipe_found = false;
struct vba_vars_st *vba = &context->bw_ctx.dml.vba;
bool vblank_psr_capable = false;
+ uint64_t refresh_rate = 0;
for (i = 0; i < dc->res_pool->pipe_count; i++) {
struct pipe_ctx *pipe = &context->res_ctx.pipe_ctx[i];
@@ -701,8 +710,14 @@ bool dcn32_subvp_vblank_admissable(struct dc *dc, struct
dc_state *context, int
continue;
if (pipe->plane_state && !pipe->top_pipe) {
- if (pipe->stream->mall_stream_config.type == SUBVP_MAIN)
+ if (pipe->stream->mall_stream_config.type ==
SUBVP_MAIN) {
subvp_count++;
+
+ refresh_rate =
(pipe->stream->timing.pix_clk_100hz * (uint64_t)100 +
+ pipe->stream->timing.v_total *
pipe->stream->timing.h_total - (uint64_t)1);
+ refresh_rate = div_u64(refresh_rate,
pipe->stream->timing.v_total);
+ refresh_rate = div_u64(refresh_rate,
pipe->stream->timing.h_total);
+ }
if (pipe->stream->mall_stream_config.type ==
SUBVP_NONE) {
non_subvp_pipes++;
vblank_psr_capable = (vblank_psr_capable ||
dcn32_is_psr_capable(pipe));
@@ -715,7 +730,8 @@ bool dcn32_subvp_vblank_admissable(struct dc *dc, struct
dc_state *context, int
}
if (subvp_count == 1 && non_subvp_pipes == 1 && !drr_pipe_found &&
!vblank_psr_capable &&
- vba->DRAMClockChangeSupport[vlevel][vba->maxMpcComb] ==
dm_dram_clock_change_vblank_w_mall_sub_vp)
+ ((uint32_t)refresh_rate < 120) &&
+ vba->DRAMClockChangeSupport[vlevel][vba->maxMpcComb] ==
dm_dram_clock_change_vblank_w_mall_sub_vp)
result = true;
return result;
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn32/dcn32_fpu.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn32/dcn32_fpu.c
index a95034801712.
[PATCH 28/33] drm/amd/display: Fix DP2 link training failure with RCO
From: Daniel Miess
[Why]
When RCO is enabled for symclk32_le we get failures during
DP2 link traing compliance tests.
[How]
Break out symclk32_le RCO into a separate function that is
called for hpo when link is enabled/disabled.
Reviewed-by: Nicholas Kazlauskas
Acked-by: Alan Liu
Signed-off-by: Daniel Miess
---
.../gpu/drm/amd/display/dc/dcn31/dcn31_dccg.c | 49 +++
.../gpu/drm/amd/display/dc/dcn31/dcn31_dccg.h | 5 ++
.../drm/amd/display/dc/dcn314/dcn314_dccg.c | 1 +
drivers/gpu/drm/amd/display/dc/inc/hw/dccg.h | 5 ++
.../display/dc/link/hwss/link_hwss_hpo_dp.c | 10
5 files changed, 50 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dccg.c
b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dccg.c
index 65c1d754e2d6..96b73d79f980 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dccg.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dccg.c
@@ -284,19 +284,11 @@ void dccg31_enable_symclk32_le(
/* select one of the PHYD32CLKs as the source for symclk32_le */
switch (hpo_le_inst) {
case 0:
- if
(dccg->ctx->dc->debug.root_clock_optimization.bits.symclk32_le)
- REG_UPDATE_2(DCCG_GATE_DISABLE_CNTL3,
- SYMCLK32_LE0_GATE_DISABLE, 1,
- SYMCLK32_ROOT_LE0_GATE_DISABLE, 1);
REG_UPDATE_2(SYMCLK32_LE_CNTL,
SYMCLK32_LE0_SRC_SEL, phyd32clk,
SYMCLK32_LE0_EN, 1);
break;
case 1:
- if
(dccg->ctx->dc->debug.root_clock_optimization.bits.symclk32_le)
- REG_UPDATE_2(DCCG_GATE_DISABLE_CNTL3,
- SYMCLK32_LE1_GATE_DISABLE, 1,
- SYMCLK32_ROOT_LE1_GATE_DISABLE, 1);
REG_UPDATE_2(SYMCLK32_LE_CNTL,
SYMCLK32_LE1_SRC_SEL, phyd32clk,
SYMCLK32_LE1_EN, 1);
@@ -319,19 +311,38 @@ void dccg31_disable_symclk32_le(
REG_UPDATE_2(SYMCLK32_LE_CNTL,
SYMCLK32_LE0_SRC_SEL, 0,
SYMCLK32_LE0_EN, 0);
- if
(dccg->ctx->dc->debug.root_clock_optimization.bits.symclk32_le)
- REG_UPDATE_2(DCCG_GATE_DISABLE_CNTL3,
- SYMCLK32_LE0_GATE_DISABLE, 0,
- SYMCLK32_ROOT_LE0_GATE_DISABLE, 0);
break;
case 1:
REG_UPDATE_2(SYMCLK32_LE_CNTL,
SYMCLK32_LE1_SRC_SEL, 0,
SYMCLK32_LE1_EN, 0);
- if
(dccg->ctx->dc->debug.root_clock_optimization.bits.symclk32_le)
- REG_UPDATE_2(DCCG_GATE_DISABLE_CNTL3,
- SYMCLK32_LE1_GATE_DISABLE, 0,
- SYMCLK32_ROOT_LE1_GATE_DISABLE, 0);
+ break;
+ default:
+ BREAK_TO_DEBUGGER();
+ return;
+ }
+}
+
+void dccg31_set_symclk32_le_root_clock_gating(
+ struct dccg *dccg,
+ int hpo_le_inst,
+ bool enable)
+{
+ struct dcn_dccg *dccg_dcn = TO_DCN_DCCG(dccg);
+
+ if (!dccg->ctx->dc->debug.root_clock_optimization.bits.symclk32_le)
+ return;
+
+ switch (hpo_le_inst) {
+ case 0:
+ REG_UPDATE_2(DCCG_GATE_DISABLE_CNTL3,
+ SYMCLK32_LE0_GATE_DISABLE, enable ? 1 : 0,
+ SYMCLK32_ROOT_LE0_GATE_DISABLE, enable ? 1 : 0);
+ break;
+ case 1:
+ REG_UPDATE_2(DCCG_GATE_DISABLE_CNTL3,
+ SYMCLK32_LE1_GATE_DISABLE, enable ? 1 : 0,
+ SYMCLK32_ROOT_LE1_GATE_DISABLE, enable ? 1 : 0);
break;
default:
BREAK_TO_DEBUGGER();
@@ -660,10 +671,8 @@ void dccg31_init(struct dccg *dccg)
dccg31_disable_symclk32_se(dccg, 2);
dccg31_disable_symclk32_se(dccg, 3);
- if (dccg->ctx->dc->debug.root_clock_optimization.bits.symclk32_le) {
- dccg31_disable_symclk32_le(dccg, 0);
- dccg31_disable_symclk32_le(dccg, 1);
- }
+ dccg31_set_symclk32_le_root_clock_gating(dccg, 0, false);
+ dccg31_set_symclk32_le_root_clock_gating(dccg, 1, false);
if (dccg->ctx->dc->debug.root_clock_optimization.bits.dpstream) {
dccg31_disable_dpstreamclk(dccg, 0);
diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dccg.h
b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dccg.h
index 0902ce5eb8a1..e3caaacf7493 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dccg.h
+++ b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dccg.h
@@ -179,6 +179,11 @@ void dccg31_disable_symclk32_le(
[PATCH 29/33] drm/amd/display: Reenable all root clock gating options
From: Daniel Miess
[Why & How]
Re-enable all RCO options now that all known issues with
RCO have been addressed
Reviewed-by: Nicholas Kazlauskas
Acked-by: Alan Liu
Signed-off-by: Daniel Miess
---
.../amd/display/dc/dcn314/dcn314_resource.c| 18 +-
1 file changed, 9 insertions(+), 9 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 6a9024aa3285..9b8e0f6f32b4 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c
@@ -908,15 +908,15 @@ static const struct dc_debug_options debug_defaults_drv =
{
.root_clock_optimization = {
.bits = {
.dpp = true,
- .dsc = false,
- .hdmistream = false,
- .hdmichar = false,
- .dpstream = false,
- .symclk32_se = false,
- .symclk32_le = false,
- .symclk_fe = false,
- .physymclk = false,
- .dpiasymclk = false,
+ .dsc = true,
+ .hdmistream = true,
+ .hdmichar = true,
+ .dpstream = true,
+ .symclk32_se = true,
+ .symclk32_le = true,
+ .symclk_fe = true,
+ .physymclk = true,
+ .dpiasymclk = true,
}
},
--
2.34.1
[PATCH 30/33] drm/amd/display: Cache backlight_millinits in link structure and setting brightness accordingly
From: Nicholas Susanto
[Why]
Need to save the cached backlight level so that display lights up using
appropriate brightness level instead of the default brightness when
waking up from s0i3.
[How]
Adding a backlight level cache in link structure. Also instead on
calling set_default_brightness_aux, check if cached values exists.
Reviewed-by: Nicholas Kazlauskas
Reviewed-by: Wenjing Liu
Acked-by: Alan Liu
Signed-off-by: Nicholas Susanto
---
drivers/gpu/drm/amd/display/dc/dc.h | 1 +
drivers/gpu/drm/amd/display/dc/dc_types.h | 4
drivers/gpu/drm/amd/display/dc/link/link_detection.c | 3 +--
drivers/gpu/drm/amd/display/dc/link/link_dpms.c | 3 ++-
.../dc/link/protocols/link_edp_panel_control.c| 11 +++
.../dc/link/protocols/link_edp_panel_control.h| 1 +
6 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dc.h
b/drivers/gpu/drm/amd/display/dc/dc.h
index b9e5d217573c..ec7edb7087b4 100644
--- a/drivers/gpu/drm/amd/display/dc/dc.h
+++ b/drivers/gpu/drm/amd/display/dc/dc.h
@@ -1521,6 +1521,7 @@ struct dc_link {
enum edp_revision edp_revision;
union dpcd_sink_ext_caps dpcd_sink_ext_caps;
+ struct backlight_settings backlight_settings;
struct psr_settings psr_settings;
/* Drive settings read from integrated info table */
diff --git a/drivers/gpu/drm/amd/display/dc/dc_types.h
b/drivers/gpu/drm/amd/display/dc/dc_types.h
index e6299e99335f..14d7804b70b2 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_types.h
+++ b/drivers/gpu/drm/amd/display/dc/dc_types.h
@@ -1002,6 +1002,10 @@ struct link_mst_stream_allocation_table {
struct link_mst_stream_allocation
stream_allocations[MAX_CONTROLLER_NUM];
};
+struct backlight_settings {
+ uint32_t backlight_millinits;
+};
+
/* PSR feature flags */
struct psr_settings {
bool psr_feature_enabled; // PSR is supported by sink
diff --git a/drivers/gpu/drm/amd/display/dc/link/link_detection.c
b/drivers/gpu/drm/amd/display/dc/link/link_detection.c
index 8041b8369e45..c9b6676eaf53 100644
--- a/drivers/gpu/drm/amd/display/dc/link/link_detection.c
+++ b/drivers/gpu/drm/amd/display/dc/link/link_detection.c
@@ -876,8 +876,7 @@ static bool detect_link_and_local_sink(struct dc_link *link,
(link->dpcd_sink_ext_caps.bits.oled == 1)) {
dpcd_set_source_specific_data(link);
msleep(post_oui_delay);
- set_default_brightness_aux(link);
- //TODO: use cached
+ set_cached_brightness_aux(link);
}
return true;
diff --git a/drivers/gpu/drm/amd/display/dc/link/link_dpms.c
b/drivers/gpu/drm/amd/display/dc/link/link_dpms.c
index b3cfa3dc5f98..7997936613fc 100644
--- a/drivers/gpu/drm/amd/display/dc/link/link_dpms.c
+++ b/drivers/gpu/drm/amd/display/dc/link/link_dpms.c
@@ -2143,7 +2143,8 @@ static enum dc_status enable_link_dp(struct dc_state
*state,
if (link->dpcd_sink_ext_caps.bits.oled == 1 ||
link->dpcd_sink_ext_caps.bits.sdr_aux_backlight_control == 1 ||
link->dpcd_sink_ext_caps.bits.hdr_aux_backlight_control == 1) {
- set_default_brightness_aux(link); // TODO: use cached if known
+ set_cached_brightness_aux(link);
+
if (link->dpcd_sink_ext_caps.bits.oled == 1)
msleep(bl_oled_enable_delay);
edp_backlight_enable_aux(link, true);
diff --git
a/drivers/gpu/drm/amd/display/dc/link/protocols/link_edp_panel_control.c
b/drivers/gpu/drm/amd/display/dc/link/protocols/link_edp_panel_control.c
index 78368b1204b8..92f58a719c07 100644
--- a/drivers/gpu/drm/amd/display/dc/link/protocols/link_edp_panel_control.c
+++ b/drivers/gpu/drm/amd/display/dc/link/protocols/link_edp_panel_control.c
@@ -164,6 +164,7 @@ bool edp_set_backlight_level_nits(struct dc_link *link,
*(uint32_t *)&dpcd_backlight_set.backlight_level_millinits =
backlight_millinits;
*(uint16_t *)&dpcd_backlight_set.backlight_transition_time_ms =
(uint16_t)transition_time_in_ms;
+ link->backlight_settings.backlight_millinits = backlight_millinits;
if (!link->dpcd_caps.panel_luminance_control) {
if (core_link_write_dpcd(link, DP_SOURCE_BACKLIGHT_LEVEL,
@@ -276,6 +277,16 @@ bool set_default_brightness_aux(struct dc_link *link)
return false;
}
+bool set_cached_brightness_aux(struct dc_link *link)
+{
+ if (link->backlight_settings.backlight_millinits)
+ return edp_set_backlight_level_nits(link, true,
+
link->backlight_settings.backlight_millinits, 0);
+ else
+ return set_default_brightness_aux(link);
+ return false;
+}
+
bool edp_is_ilr_optimization_required(struct dc_link *link,
struct dc_crtc_tim
[PATCH 31/33] drm/amd/display: refine to decide the verified link setting
From: Zhikai Zhai
[WHY]
We return false by default when link training fail at link loss.
It will cause we get a fail verified link caps directly.
[HOW]
Record the highest verified link caps. Use the recorded value as
the verified link caps if it is not successful in the last attempt
to avoid to use the lowest link setting.
Reviewed-by: Wenjing Liu
Acked-by: Alan Liu
Signed-off-by: Zhikai Zhai
---
.../dc/link/protocols/link_dp_capability.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c
b/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c
index 08a1961e00a4..b38ac3ea06b0 100644
--- a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c
+++ b/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c
@@ -2166,7 +2166,9 @@ static bool dp_verify_link_cap(
link,
&irq_data))
(*fail_count)++;
-
+ } else if (status == LINK_TRAINING_LINK_LOSS) {
+ success = true;
+ (*fail_count)++;
} else {
(*fail_count)++;
}
@@ -2189,6 +2191,7 @@ bool dp_verify_link_cap_with_retries(
int i = 0;
bool success = false;
int fail_count = 0;
+ struct dc_link_settings last_verified_link_cap =
fail_safe_link_settings;
dp_trace_detect_lt_init(link);
@@ -2205,10 +2208,14 @@ bool dp_verify_link_cap_with_retries(
if (!link_detect_connection_type(link, &type) || type ==
dc_connection_none) {
link->verified_link_cap = fail_safe_link_settings;
break;
- } else if (dp_verify_link_cap(link, known_limit_link_setting,
- &fail_count) && fail_count == 0) {
- success = true;
- break;
+ } else if (dp_verify_link_cap(link, known_limit_link_setting,
&fail_count)) {
+ last_verified_link_cap = link->verified_link_cap;
+ if (fail_count == 0) {
+ success = true;
+ break;
+ }
+ } else {
+ link->verified_link_cap = last_verified_link_cap;
}
fsleep(10 * 1000);
}
--
2.34.1
[PATCH 32/33] drm/amd/display: Update SW cursor fallback for subvp high refresh
From: Alvin Lee
[Description]
Since SubVP high refresh is now enabled, we must
fallback to SW cursor under if we're in a SubVP
high refresh config
Reviewed-by: Samson Tam
Acked-by: Alan Liu
Signed-off-by: Alvin Lee
---
.../gpu/drm/amd/display/dc/core/dc_stream.c | 35 ---
1 file changed, 31 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
b/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
index 6e11d2b701f8..ea3d4b328e8e 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
@@ -306,6 +306,32 @@ bool dc_optimize_timing_for_fsft(
}
#endif
+static bool is_subvp_high_refresh_candidate(struct dc_stream_state *stream)
+{
+ uint32_t refresh_rate;
+ struct dc *dc = stream->ctx->dc;
+
+ refresh_rate = (stream->timing.pix_clk_100hz * (uint64_t)100 +
+ stream->timing.v_total * stream->timing.h_total - (uint64_t)1);
+ refresh_rate = div_u64(refresh_rate, stream->timing.v_total);
+ refresh_rate = div_u64(refresh_rate, stream->timing.h_total);
+
+ /* If there's any stream that fits the SubVP high refresh criteria,
+* we must return true. This is because cursor updates are asynchronous
+* with full updates, so we could transition into a SubVP config and
+* remain in HW cursor mode if there's no cursor update which will
+* then cause corruption.
+*/
+ if ((refresh_rate >= 120 && refresh_rate <= 165 &&
+ stream->timing.v_addressable >= 1440 &&
+ stream->timing.v_addressable <= 2160) &&
+ (dc->current_state->stream_count > 1 ||
+ (dc->current_state->stream_count == 1 &&
!stream->allow_freesync)))
+ return true;
+
+ return false;
+}
+
/*
* dc_stream_set_cursor_attributes() - Update cursor attributes and set cursor
surface address
*/
@@ -334,12 +360,13 @@ bool dc_stream_set_cursor_attributes(
/* SubVP is not compatible with HW cursor larger than 64 x 64 x 4.
* Therefore, if cursor is greater than 64 x 64 x 4, fallback to SW
cursor in the following case:
-* 1. For single display cases, if resolution is >= 5K and refresh rate
< 120hz
-* 2. For multi display cases, if resolution is >= 4K and refresh rate
< 120hz
-*
-* [< 120hz is a requirement for SubVP configs]
+* 1. If the config is a candidate for SubVP high refresh (both single
an dual display configs)
+* 2. If not subvp high refresh, for single display cases, if
resolution is >= 5K and refresh rate < 120hz
+* 3. If not subvp high refresh, for multi display cases, if resolution
is >= 4K and refresh rate < 120hz
*/
if (dc->debug.allow_sw_cursor_fallback && attributes->height *
attributes->width * 4 > 16384) {
+ if (!dc->debug.disable_subvp_high_refresh &&
is_subvp_high_refresh_candidate(stream))
+ return false;
if (dc->current_state->stream_count == 1 &&
stream->timing.v_addressable >= 2880 &&
((stream->timing.pix_clk_100hz * 100) /
stream->timing.v_total / stream->timing.h_total) < 120)
return false;
--
2.34.1
[PATCH 33/33] drm/amd/display: Promote DAL to 3.2.243
From: Aric Cyr This version brings along following fixes: - Update 128b/132b downspread factor to 0.3% - Add helpers to get DMUB FW boot options - Initialize necessary uninitialized variables - Add stream overhead in BW calculations for 128b/132b - Add link encoding to timing BW calculation parameters - Prevent vtotal from being set to 0 - Fix race condition when turning off an output alone - Keep PHY active for DP displays on DCN31 - Fix ASIC check in aux timeout workaround - ABM pause toggle - Add missing triggers for full updates - Disable MPC split by default on special asic - Add additional refresh rate conditions for SubVP cases - Fix DP2 link training failure with RCO - Reenable all root clock gating options - Cache backlight_millinits in link structure and setting brightness accordingly - Refine to decide the verified link setting - Update SW cursor fallback for subvp high refresh Acked-by: Alan Liu Signed-off-by: Aric Cyr --- drivers/gpu/drm/amd/display/dc/dc.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dc.h b/drivers/gpu/drm/amd/display/dc/dc.h index ec7edb7087b4..41e68d694c17 100644 --- a/drivers/gpu/drm/amd/display/dc/dc.h +++ b/drivers/gpu/drm/amd/display/dc/dc.h @@ -47,7 +47,7 @@ struct aux_payload; struct set_config_cmd_payload; struct dmub_notification; -#define DC_VER "3.2.242" +#define DC_VER "3.2.243" #define MAX_SURFACES 3 #define MAX_PLANES 6 -- 2.34.1
[pull] amdgpu drm-fixes-6.5
Hi Dave, Daniel, Fixes for 6.5. The following changes since commit 6725f33228077902ddac2a05e0ab361dee36e4ba: Merge tag 'drm-misc-next-fixes-2023-07-06' of git://anongit.freedesktop.org/drm/drm-misc into drm-next (2023-07-07 11:05:16 +1000) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-fixes-6.5-2023-07-12 for you to fetch changes up to e701156ccc6c7a5f104a968dda74cd6434178712: drm/amd: Align SMU11 SMU_MSG_OverridePcieParameters implementation with SMU13 (2023-07-12 12:21:23 -0400) amd-drm-fixes-6.5-2023-07-12: amdgpu: - SMU i2c locking fix - Fix a possible deadlock in process restoration for ROCm apps - Disable PCIe lane/speed switching on Intel platforms (the platforms don't support it) Evan Quan (1): drm/amd/pm: share the code around SMU13 pcie parameters update Mario Limonciello (3): drm/amd/pm: conditionally disable pcie lane/speed switching for SMU13 drm/amd: Move helper for dynamic speed switch check out of smu13 drm/amd: Align SMU11 SMU_MSG_OverridePcieParameters implementation with SMU13 Yang Wang (1): drm/amd/pm: fix smu i2c data read risk gaba (1): drm/amdgpu: avoid restore process run into dead loop. drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 3 + drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 19 + drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h | 4 + drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c | 2 +- drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c| 2 +- .../drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c| 91 +- drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c | 2 +- drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c | 48 .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 35 + .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c | 2 +- .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c | 33 +--- 12 files changed, 101 insertions(+), 141 deletions(-)
[PATCH] Revert "drm/amdgpu: enable mcbp by default on gfx9"
This reverts commit 50a7c8765ca69543ffdbf855de0fd69aea769ccf. This breaks some SQA tests on gfx9 dGPUs. Chistian also reported problems. Cc: candice...@amd.com Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 5 - drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 6 +++--- 2 files changed, 3 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index bbe4ea93db611..3673015a7f93a 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -3699,11 +3699,6 @@ static void amdgpu_device_set_mcbp(struct amdgpu_device *adev) if (amdgpu_mcbp == 1) adev->gfx.mcbp = true; - if ((adev->ip_versions[GC_HWIP][0] >= IP_VERSION(9, 0, 0)) && - (adev->ip_versions[GC_HWIP][0] < IP_VERSION(10, 0, 0)) && - adev->gfx.num_gfx_rings) - adev->gfx.mcbp = true; - if (amdgpu_sriov_vf(adev)) adev->gfx.mcbp = true; diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c index 33e370d998a87..f829a80e52924 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c @@ -180,7 +180,7 @@ uint amdgpu_dc_feature_mask = 2; uint amdgpu_dc_debug_mask; uint amdgpu_dc_visual_confirm; int amdgpu_async_gfx_ring = 1; -int amdgpu_mcbp = -1; +int amdgpu_mcbp; int amdgpu_discovery = -1; int amdgpu_mes; int amdgpu_mes_kiq; @@ -635,10 +635,10 @@ module_param_named(async_gfx_ring, amdgpu_async_gfx_ring, int, 0444); /** * DOC: mcbp (int) - * It is used to enable mid command buffer preemption. (0 = disabled, 1 = enabled, -1 auto (default)) + * It is used to enable mid command buffer preemption. (0 = disabled (default), 1 = enabled) */ MODULE_PARM_DESC(mcbp, - "Enable Mid-command buffer preemption (0 = disabled, 1 = enabled), -1 = auto (default)"); + "Enable Mid-command buffer preemption (0 = disabled (default), 1 = enabled)"); module_param_named(mcbp, amdgpu_mcbp, int, 0444); /** -- 2.41.0
Re: [Freedreno] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
On Wed, Jul 12, 2023 at 10:52 AM Jani Nikula wrote: > > On Wed, 12 Jul 2023, Uwe Kleine-König wrote: > > Hello, > > > > while I debugged an issue in the imx-lcdc driver I was constantly > > irritated about struct drm_device pointer variables being named "dev" > > because with that name I usually expect a struct device pointer. > > > > I think there is a big benefit when these are all renamed to "drm_dev". > > I have no strong preference here though, so "drmdev" or "drm" are fine > > for me, too. Let the bikesheding begin! > > > > Some statistics: > > > > $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq > > -c | sort -n > > 1 struct drm_device *adev_to_drm > > 1 struct drm_device *drm_ > > 1 struct drm_device *drm_dev > > 1 struct drm_device*drm_dev > > 1 struct drm_device *pdev > > 1 struct drm_device *rdev > > 1 struct drm_device *vdev > > 2 struct drm_device *dcss_drv_dev_to_drm > > 2 struct drm_device **ddev > > 2 struct drm_device *drm_dev_alloc > > 2 struct drm_device *mock > > 2 struct drm_device *p_ddev > > 5 struct drm_device *device > > 9 struct drm_device * dev > > 25 struct drm_device *d > > 95 struct drm_device * > > 216 struct drm_device *ddev > > 234 struct drm_device *drm_dev > > 611 struct drm_device *drm > >4190 struct drm_device *dev > > > > This series starts with renaming struct drm_crtc::dev to drm_dev. If > > it's not only me and others like the result of this effort it should be > > followed up by adapting the other structs and the individual usages in > > the different drivers. > > I think this is an unnecessary change. In drm, a dev is usually a drm > device, i.e. struct drm_device *. As shown by the numbers above. > I'd really prefer this patch (series or single) is not accepted. This will cause problems for everyone cherry-picking patches to a downstream kernel (LTS or distro tree). I usually wouldn't expect sympathy here, but the questionable benefit does not outweigh the cost IM[biased]O. Sean > If folks insist on following through with this anyway, I'm firmly in the > camp the name should be "drm" and nothing else. > > > BR, > Jani. > > > -- > Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
Hello Jani,
On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote:
> On Wed, 12 Jul 2023, Uwe Kleine-König wrote:
> > Hello,
> >
> > while I debugged an issue in the imx-lcdc driver I was constantly
> > irritated about struct drm_device pointer variables being named "dev"
> > because with that name I usually expect a struct device pointer.
> >
> > I think there is a big benefit when these are all renamed to "drm_dev".
> > I have no strong preference here though, so "drmdev" or "drm" are fine
> > for me, too. Let the bikesheding begin!
> >
> > Some statistics:
> >
> > $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq
> > -c | sort -n
> > 1 struct drm_device *adev_to_drm
> > 1 struct drm_device *drm_
> > 1 struct drm_device *drm_dev
> > 1 struct drm_device*drm_dev
> > 1 struct drm_device *pdev
> > 1 struct drm_device *rdev
> > 1 struct drm_device *vdev
> > 2 struct drm_device *dcss_drv_dev_to_drm
> > 2 struct drm_device **ddev
> > 2 struct drm_device *drm_dev_alloc
> > 2 struct drm_device *mock
> > 2 struct drm_device *p_ddev
> > 5 struct drm_device *device
> > 9 struct drm_device * dev
> > 25 struct drm_device *d
> > 95 struct drm_device *
> > 216 struct drm_device *ddev
> > 234 struct drm_device *drm_dev
> > 611 struct drm_device *drm
> >4190 struct drm_device *dev
> >
> > This series starts with renaming struct drm_crtc::dev to drm_dev. If
> > it's not only me and others like the result of this effort it should be
> > followed up by adapting the other structs and the individual usages in
> > the different drivers.
>
> I think this is an unnecessary change. In drm, a dev is usually a drm
> device, i.e. struct drm_device *.
Well, unless it's not. Prominently there is
struct drm_device {
...
struct device *dev;
...
};
which yields quite a few code locations using dev->dev which is
IMHO unnecessary irritating:
$ git grep '\dev' v6.5-rc1 drivers/gpu/drm | wc -l
1633
Also the functions that deal with both a struct device and a struct
drm_device often use "dev" for the struct device and then "ddev" for
the drm_device (see for example amdgpu_device_get_pcie_replay_count()).
> If folks insist on following through with this anyway, I'm firmly in the
> camp the name should be "drm" and nothing else.
Up to now positive feedback is in the majority.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
Re: [Freedreno] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
On 12/07/2023 20:31, Sean Paul wrote: >>> 216 struct drm_device *ddev >>> 234 struct drm_device *drm_dev >>> 611 struct drm_device *drm >>>4190 struct drm_device *dev >>> >>> This series starts with renaming struct drm_crtc::dev to drm_dev. If >>> it's not only me and others like the result of this effort it should be >>> followed up by adapting the other structs and the individual usages in >>> the different drivers. >> >> I think this is an unnecessary change. In drm, a dev is usually a drm >> device, i.e. struct drm_device *. As shown by the numbers above. >> > > I'd really prefer this patch (series or single) is not accepted. This > will cause problems for everyone cherry-picking patches to a > downstream kernel (LTS or distro tree). I usually wouldn't expect > sympathy here, but the questionable benefit does not outweigh the cost > IM[biased]O. You know, every code cleanup and style adjustment is interfering with backporting. The only argument for a fast-pacing kernel should be whether the developers of this code find it more readable with such cleanup. Best regards, Krzysztof
