RE: [PATCH] drm/amdgpu: drop ras ta firmware loading for non-ras asic
[AMD Public Use]
Btw, the original purpose for the asic type check is to prevent any further
atombios call for RAS capability check. But it's not necessary to be there. We
shall consider to change it in a more reasonable approach by dropping the asic
type check.
Regards,
Hawking
-Original Message-
From: amd-gfx On Behalf Of Zhang,
Hawking
Sent: Monday, January 4, 2021 15:48
To: Chen, Guchun ; amd-gfx@lists.freedesktop.org; Deucher,
Alexander ; Yang, Stanley ;
Li, Dennis ; Zhou1, Tao ; Clements, John
Subject: RE: [PATCH] drm/amdgpu: drop ras ta firmware loading for non-ras asic
[AMD Public Use]
Then we can refine the wording, or make this to be debug message, although the
message already states explicitly this is "optional". Split
amdgpu_ras_checked_support may not be a good idea since this is strictly not
correct - RAS is not necessarily bind to ASIC type.
Regards,
Hawking
-Original Message-
From: Chen, Guchun
Sent: Monday, January 4, 2021 14:57
To: Zhang, Hawking ; amd-gfx@lists.freedesktop.org;
Deucher, Alexander ; Yang, Stanley
; Li, Dennis ; Zhou1, Tao
; Clements, John
Subject: RE: [PATCH] drm/amdgpu: drop ras ta firmware loading for non-ras asic
[AMD Public Use]
Hi Hawking,
Yes, these kernel messages are indeed not harmful, but some audiences may feel
confused on this, as they will guess why kernel said " ras ta ucode is not
available " during boot up, and furthermore, if the users miss some FWs? So
this is to exclude the confusion on the ASICs that don't have RAS feature.
Asic type check for ras is not introduced by this patch, it exists already as
it's used in amdgpu_ras_checked_support. This patch extends its scope by moving
it to header file(amdgpu_ras.h) for wide usage.
Regards,
Guchun
-Original Message-
From: Zhang, Hawking
Sent: Monday, January 4, 2021 2:23 PM
To: Chen, Guchun ; amd-gfx@lists.freedesktop.org; Deucher,
Alexander ; Yang, Stanley ;
Li, Dennis ; Zhou1, Tao ; Clements, John
Subject: RE: [PATCH] drm/amdgpu: drop ras ta firmware loading for non-ras asic
[AMD Public Use]
We shall check ras ta firmware image size or/and ras ta binary start address to
exclude ASICs that don't support ras.
Introduce asic type check here is unnecessary and the functional also need to
be modified every time we add a new asic with ras capablility.
Kernel message that indicates ras ta, and other ta are optional one seems no
harm to me. this is not limited to ras, but also hdcp/dtm.etc. If people have
concern on this kind of messages, we can leverage amdgpu_ras_checked_support to
only allow the message for ASICs that support RAS, although I don't think that
is necessary.
Regards,
Hawking
-Original Message-
From: Chen, Guchun
Sent: Monday, January 4, 2021 12:58
To: amd-gfx@lists.freedesktop.org; Deucher, Alexander
; Zhang, Hawking ; Yang,
Stanley ; Li, Dennis ; Zhou1, Tao
; Clements, John
Cc: Chen, Guchun
Subject: [PATCH] drm/amdgpu: drop ras ta firmware loading for non-ras asic
Otherwise, below confused message is always printed during boot for asics
without ras feature, but with common ta firmware.
amdgpu: RAS: optional ras ta ucode is not available
Signed-off-by: Guchun Chen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 5 +++--
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 22 --
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h | 2 ++
3 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index eb19ae734396..730bc1fe2036 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -1135,9 +1135,10 @@ static int psp_ras_initialize(struct psp_context *psp)
int ret;
/*
-* TODO: bypass the initialize in sriov for now
+* TODO: bypass the initialize in sriov and non-ras case
*/
- if (amdgpu_sriov_vf(psp->adev))
+ if (amdgpu_sriov_vf(psp->adev) ||
+ !amdgpu_ras_check_enablement_by_asic(psp->adev))
return 0;
if (!psp->adev->psp.ta_ras_ucode_size || diff --git
a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index c136bd449744..41d97e56271e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
@@ -1897,15 +1897,17 @@ int amdgpu_ras_request_reset_on_boot(struct
amdgpu_device *adev,
return 0;
}
-static int amdgpu_ras_check_asic_type(struct amdgpu_device *adev) -{
- if (adev->asic_type != CHIP_VEGA10 &&
- adev->asic_type != CHIP_VEGA20 &&
- adev->asic_type != CHIP_ARCTURUS &&
- adev->asic_type != CHIP_SIENNA_CICHLID)
- return 1;
- else
- return 0;
+bool amdgpu_ras_check_enablement_by_asic(struct amdgpu_device *adev) {
+ switch (adev->asic_type) {
+ case CHIP_VEGA10:
+ case CHIP_VEGA20:
+ c
RE: [PATCH] drm/amdgpu: drop ras ta firmware loading for non-ras asic
[AMD Public Use]
Then we can refine the wording, or make this to be debug message, although the
message already states explicitly this is "optional". Split
amdgpu_ras_checked_support may not be a good idea since this is strictly not
correct - RAS is not necessarily bind to ASIC type.
Regards,
Hawking
-Original Message-
From: Chen, Guchun
Sent: Monday, January 4, 2021 14:57
To: Zhang, Hawking ; amd-gfx@lists.freedesktop.org;
Deucher, Alexander ; Yang, Stanley
; Li, Dennis ; Zhou1, Tao
; Clements, John
Subject: RE: [PATCH] drm/amdgpu: drop ras ta firmware loading for non-ras asic
[AMD Public Use]
Hi Hawking,
Yes, these kernel messages are indeed not harmful, but some audiences may feel
confused on this, as they will guess why kernel said " ras ta ucode is not
available " during boot up, and furthermore, if the users miss some FWs? So
this is to exclude the confusion on the ASICs that don't have RAS feature.
Asic type check for ras is not introduced by this patch, it exists already as
it's used in amdgpu_ras_checked_support. This patch extends its scope by moving
it to header file(amdgpu_ras.h) for wide usage.
Regards,
Guchun
-Original Message-
From: Zhang, Hawking
Sent: Monday, January 4, 2021 2:23 PM
To: Chen, Guchun ; amd-gfx@lists.freedesktop.org; Deucher,
Alexander ; Yang, Stanley ;
Li, Dennis ; Zhou1, Tao ; Clements, John
Subject: RE: [PATCH] drm/amdgpu: drop ras ta firmware loading for non-ras asic
[AMD Public Use]
We shall check ras ta firmware image size or/and ras ta binary start address to
exclude ASICs that don't support ras.
Introduce asic type check here is unnecessary and the functional also need to
be modified every time we add a new asic with ras capablility.
Kernel message that indicates ras ta, and other ta are optional one seems no
harm to me. this is not limited to ras, but also hdcp/dtm.etc. If people have
concern on this kind of messages, we can leverage amdgpu_ras_checked_support to
only allow the message for ASICs that support RAS, although I don't think that
is necessary.
Regards,
Hawking
-Original Message-
From: Chen, Guchun
Sent: Monday, January 4, 2021 12:58
To: amd-gfx@lists.freedesktop.org; Deucher, Alexander
; Zhang, Hawking ; Yang,
Stanley ; Li, Dennis ; Zhou1, Tao
; Clements, John
Cc: Chen, Guchun
Subject: [PATCH] drm/amdgpu: drop ras ta firmware loading for non-ras asic
Otherwise, below confused message is always printed during boot for asics
without ras feature, but with common ta firmware.
amdgpu: RAS: optional ras ta ucode is not available
Signed-off-by: Guchun Chen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 5 +++--
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 22 --
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h | 2 ++
3 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index eb19ae734396..730bc1fe2036 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -1135,9 +1135,10 @@ static int psp_ras_initialize(struct psp_context *psp)
int ret;
/*
-* TODO: bypass the initialize in sriov for now
+* TODO: bypass the initialize in sriov and non-ras case
*/
- if (amdgpu_sriov_vf(psp->adev))
+ if (amdgpu_sriov_vf(psp->adev) ||
+ !amdgpu_ras_check_enablement_by_asic(psp->adev))
return 0;
if (!psp->adev->psp.ta_ras_ucode_size || diff --git
a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index c136bd449744..41d97e56271e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
@@ -1897,15 +1897,17 @@ int amdgpu_ras_request_reset_on_boot(struct
amdgpu_device *adev,
return 0;
}
-static int amdgpu_ras_check_asic_type(struct amdgpu_device *adev) -{
- if (adev->asic_type != CHIP_VEGA10 &&
- adev->asic_type != CHIP_VEGA20 &&
- adev->asic_type != CHIP_ARCTURUS &&
- adev->asic_type != CHIP_SIENNA_CICHLID)
- return 1;
- else
- return 0;
+bool amdgpu_ras_check_enablement_by_asic(struct amdgpu_device *adev) {
+ switch (adev->asic_type) {
+ case CHIP_VEGA10:
+ case CHIP_VEGA20:
+ case CHIP_ARCTURUS:
+ case CHIP_SIENNA_CICHLID:
+ return true;
+ default:
+ return false;
+ }
}
/*
@@ -1924,7 +1926,7 @@ static void amdgpu_ras_check_supported(struct
amdgpu_device *adev,
*supported = 0;
if (amdgpu_sriov_vf(adev) || !adev->is_atom_fw ||
- amdgpu_ras_check_asic_type(adev))
+ !amdgpu_ras_check_enablement_by_asic(adev))
return;
if (amdgpu_atomfirmware_mem_ecc_supported(adev)) { diff --git
a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h
b/drivers/gpu/drm/amd/amdgpu/amdg
RE: [PATCH] drm/amdgpu: drop ras ta firmware loading for non-ras asic
[AMD Public Use]
Hi Hawking,
Yes, these kernel messages are indeed not harmful, but some audiences may feel
confused on this, as they will guess why kernel said " ras ta ucode is not
available " during boot up, and furthermore, if the users miss some FWs? So
this is to exclude the confusion on the ASICs that don't have RAS feature.
Asic type check for ras is not introduced by this patch, it exists already as
it's used in amdgpu_ras_checked_support. This patch extends its scope by moving
it to header file(amdgpu_ras.h) for wide usage.
Regards,
Guchun
-Original Message-
From: Zhang, Hawking
Sent: Monday, January 4, 2021 2:23 PM
To: Chen, Guchun ; amd-gfx@lists.freedesktop.org; Deucher,
Alexander ; Yang, Stanley ;
Li, Dennis ; Zhou1, Tao ; Clements, John
Subject: RE: [PATCH] drm/amdgpu: drop ras ta firmware loading for non-ras asic
[AMD Public Use]
We shall check ras ta firmware image size or/and ras ta binary start address to
exclude ASICs that don't support ras.
Introduce asic type check here is unnecessary and the functional also need to
be modified every time we add a new asic with ras capablility.
Kernel message that indicates ras ta, and other ta are optional one seems no
harm to me. this is not limited to ras, but also hdcp/dtm.etc. If people have
concern on this kind of messages, we can leverage amdgpu_ras_checked_support to
only allow the message for ASICs that support RAS, although I don't think that
is necessary.
Regards,
Hawking
-Original Message-
From: Chen, Guchun
Sent: Monday, January 4, 2021 12:58
To: amd-gfx@lists.freedesktop.org; Deucher, Alexander
; Zhang, Hawking ; Yang,
Stanley ; Li, Dennis ; Zhou1, Tao
; Clements, John
Cc: Chen, Guchun
Subject: [PATCH] drm/amdgpu: drop ras ta firmware loading for non-ras asic
Otherwise, below confused message is always printed during boot for asics
without ras feature, but with common ta firmware.
amdgpu: RAS: optional ras ta ucode is not available
Signed-off-by: Guchun Chen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 5 +++--
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 22 --
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h | 2 ++
3 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index eb19ae734396..730bc1fe2036 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -1135,9 +1135,10 @@ static int psp_ras_initialize(struct psp_context *psp)
int ret;
/*
-* TODO: bypass the initialize in sriov for now
+* TODO: bypass the initialize in sriov and non-ras case
*/
- if (amdgpu_sriov_vf(psp->adev))
+ if (amdgpu_sriov_vf(psp->adev) ||
+ !amdgpu_ras_check_enablement_by_asic(psp->adev))
return 0;
if (!psp->adev->psp.ta_ras_ucode_size || diff --git
a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index c136bd449744..41d97e56271e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
@@ -1897,15 +1897,17 @@ int amdgpu_ras_request_reset_on_boot(struct
amdgpu_device *adev,
return 0;
}
-static int amdgpu_ras_check_asic_type(struct amdgpu_device *adev) -{
- if (adev->asic_type != CHIP_VEGA10 &&
- adev->asic_type != CHIP_VEGA20 &&
- adev->asic_type != CHIP_ARCTURUS &&
- adev->asic_type != CHIP_SIENNA_CICHLID)
- return 1;
- else
- return 0;
+bool amdgpu_ras_check_enablement_by_asic(struct amdgpu_device *adev) {
+ switch (adev->asic_type) {
+ case CHIP_VEGA10:
+ case CHIP_VEGA20:
+ case CHIP_ARCTURUS:
+ case CHIP_SIENNA_CICHLID:
+ return true;
+ default:
+ return false;
+ }
}
/*
@@ -1924,7 +1926,7 @@ static void amdgpu_ras_check_supported(struct
amdgpu_device *adev,
*supported = 0;
if (amdgpu_sriov_vf(adev) || !adev->is_atom_fw ||
- amdgpu_ras_check_asic_type(adev))
+ !amdgpu_ras_check_enablement_by_asic(adev))
return;
if (amdgpu_atomfirmware_mem_ecc_supported(adev)) { diff --git
a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h
index 762f5e46c007..06b5f9d14bea 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h
@@ -629,4 +629,6 @@ void amdgpu_ras_global_ras_isr(struct amdgpu_device *adev);
void amdgpu_ras_set_error_query_ready(struct amdgpu_device *adev, bool ready);
bool amdgpu_ras_need_emergency_restart(struct amdgpu_device *adev);
+
+bool amdgpu_ras_check_enablement_by_asic(struct amdgpu_device *adev);
#endif
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listin
RE: [PATCH] drm/amdgpu: drop ras ta firmware loading for non-ras asic
[AMD Public Use]
We shall check ras ta firmware image size or/and ras ta binary start address to
exclude ASICs that don't support ras.
Introduce asic type check here is unnecessary and the functional also need to
be modified every time we add a new asic with ras capablility.
Kernel message that indicates ras ta, and other ta are optional one seems no
harm to me. this is not limited to ras, but also hdcp/dtm.etc. If people have
concern on this kind of messages, we can leverage amdgpu_ras_checked_support to
only allow the message for ASICs that support RAS, although I don't think that
is necessary.
Regards,
Hawking
-Original Message-
From: Chen, Guchun
Sent: Monday, January 4, 2021 12:58
To: amd-gfx@lists.freedesktop.org; Deucher, Alexander
; Zhang, Hawking ; Yang,
Stanley ; Li, Dennis ; Zhou1, Tao
; Clements, John
Cc: Chen, Guchun
Subject: [PATCH] drm/amdgpu: drop ras ta firmware loading for non-ras asic
Otherwise, below confused message is always printed during boot for asics
without ras feature, but with common ta firmware.
amdgpu: RAS: optional ras ta ucode is not available
Signed-off-by: Guchun Chen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 5 +++--
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 22 --
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h | 2 ++
3 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index eb19ae734396..730bc1fe2036 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -1135,9 +1135,10 @@ static int psp_ras_initialize(struct psp_context *psp)
int ret;
/*
-* TODO: bypass the initialize in sriov for now
+* TODO: bypass the initialize in sriov and non-ras case
*/
- if (amdgpu_sriov_vf(psp->adev))
+ if (amdgpu_sriov_vf(psp->adev) ||
+ !amdgpu_ras_check_enablement_by_asic(psp->adev))
return 0;
if (!psp->adev->psp.ta_ras_ucode_size || diff --git
a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index c136bd449744..41d97e56271e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
@@ -1897,15 +1897,17 @@ int amdgpu_ras_request_reset_on_boot(struct
amdgpu_device *adev,
return 0;
}
-static int amdgpu_ras_check_asic_type(struct amdgpu_device *adev) -{
- if (adev->asic_type != CHIP_VEGA10 &&
- adev->asic_type != CHIP_VEGA20 &&
- adev->asic_type != CHIP_ARCTURUS &&
- adev->asic_type != CHIP_SIENNA_CICHLID)
- return 1;
- else
- return 0;
+bool amdgpu_ras_check_enablement_by_asic(struct amdgpu_device *adev) {
+ switch (adev->asic_type) {
+ case CHIP_VEGA10:
+ case CHIP_VEGA20:
+ case CHIP_ARCTURUS:
+ case CHIP_SIENNA_CICHLID:
+ return true;
+ default:
+ return false;
+ }
}
/*
@@ -1924,7 +1926,7 @@ static void amdgpu_ras_check_supported(struct
amdgpu_device *adev,
*supported = 0;
if (amdgpu_sriov_vf(adev) || !adev->is_atom_fw ||
- amdgpu_ras_check_asic_type(adev))
+ !amdgpu_ras_check_enablement_by_asic(adev))
return;
if (amdgpu_atomfirmware_mem_ecc_supported(adev)) { diff --git
a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h
index 762f5e46c007..06b5f9d14bea 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h
@@ -629,4 +629,6 @@ void amdgpu_ras_global_ras_isr(struct amdgpu_device *adev);
void amdgpu_ras_set_error_query_ready(struct amdgpu_device *adev, bool ready);
bool amdgpu_ras_need_emergency_restart(struct amdgpu_device *adev);
+
+bool amdgpu_ras_check_enablement_by_asic(struct amdgpu_device *adev);
#endif
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 2/2] drm/amdgpu/display: buffer INTERRUPT_LOW_IRQ_CONTEXT interrupt work
From: Xiaogang Chen
amdgpu DM handles INTERRUPT_LOW_IRQ_CONTEXT interrupt(hpd, hpd_rx) by
using work queue and uses single work_struct. If previous interrupt
has not been handled new interrupts(same type) will be discarded and
driver just sends "amdgpu_dm_irq_schedule_work FAILED" message out.
If some important hpd, hpd_rx related interrupts are missed by driver
the hot (un)plug devices may cause system hang or unstable, such as
system resumes from S3 sleep with mst device connected.
This patch dynamically allocates new amdgpu_dm_irq_handler_data for
new interrupts if previous INTERRUPT_LOW_IRQ_CONTEXT interrupt work
has not been handled. So the new interrupt works can be queued to the
same workqueue_struct, instead discard the new interrupts.
All allocated amdgpu_dm_irq_handler_data are put into a single linked
list and will be reused after.
Signed-off-by: Xiaogang Chen
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 14 +--
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c | 114 ++---
2 files changed, 80 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index c9d82b9..730e540 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -69,18 +69,6 @@ struct common_irq_params {
};
/**
- * struct irq_list_head - Linked-list for low context IRQ handlers.
- *
- * @head: The list_head within &struct handler_data
- * @work: A work_struct containing the deferred handler work
- */
-struct irq_list_head {
- struct list_head head;
- /* In case this interrupt needs post-processing, 'work' will be queued*/
- struct work_struct work;
-};
-
-/**
* struct dm_compressor_info - Buffer info used by frame buffer compression
* @cpu_addr: MMIO cpu addr
* @bo_ptr: Pointer to the buffer object
@@ -270,7 +258,7 @@ struct amdgpu_display_manager {
* Note that handlers are called in the same order as they were
* registered (FIFO).
*/
- struct irq_list_head irq_handler_list_low_tab[DAL_IRQ_SOURCES_NUMBER];
+ struct list_head irq_handler_list_low_tab[DAL_IRQ_SOURCES_NUMBER];
/**
* @irq_handler_list_high_tab:
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c
index 3577785..ada344a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c
@@ -82,6 +82,7 @@ struct amdgpu_dm_irq_handler_data {
struct amdgpu_display_manager *dm;
/* DAL irq source which registered for this interrupt. */
enum dc_irq_source irq_source;
+ struct work_struct work;
};
#define DM_IRQ_TABLE_LOCK(adev, flags) \
@@ -111,20 +112,10 @@ static void init_handler_common_data(struct
amdgpu_dm_irq_handler_data *hcd,
*/
static void dm_irq_work_func(struct work_struct *work)
{
- struct irq_list_head *irq_list_head =
- container_of(work, struct irq_list_head, work);
- struct list_head *handler_list = &irq_list_head->head;
- struct amdgpu_dm_irq_handler_data *handler_data;
-
- list_for_each_entry(handler_data, handler_list, list) {
- DRM_DEBUG_KMS("DM_IRQ: work_func: for dal_src=%d\n",
- handler_data->irq_source);
+ struct amdgpu_dm_irq_handler_data *handler_data =
+container_of(work, struct amdgpu_dm_irq_handler_data, work);
- DRM_DEBUG_KMS("DM_IRQ: schedule_work: for dal_src=%d\n",
- handler_data->irq_source);
-
- handler_data->handler(handler_data->handler_arg);
- }
+ handler_data->handler(handler_data->handler_arg);
/* Call a DAL subcomponent which registered for interrupt notification
* at INTERRUPT_LOW_IRQ_CONTEXT.
@@ -156,7 +147,7 @@ static struct list_head *remove_irq_handler(struct
amdgpu_device *adev,
break;
case INTERRUPT_LOW_IRQ_CONTEXT:
default:
- hnd_list = &adev->dm.irq_handler_list_low_tab[irq_source].head;
+ hnd_list = &adev->dm.irq_handler_list_low_tab[irq_source];
break;
}
@@ -287,7 +278,8 @@ void *amdgpu_dm_irq_register_interrupt(struct amdgpu_device
*adev,
break;
case INTERRUPT_LOW_IRQ_CONTEXT:
default:
- hnd_list = &adev->dm.irq_handler_list_low_tab[irq_source].head;
+ hnd_list = &adev->dm.irq_handler_list_low_tab[irq_source];
+ INIT_WORK(&handler_data->work, dm_irq_work_func);
break;
}
@@ -369,7 +361,7 @@ void amdgpu_dm_irq_unregister_interrupt(struct
amdgpu_device *adev,
int amdgpu_dm_irq_init(struct amdgpu_device *adev)
{
int src;
- struct irq_list_head *lh;
+ struct list_head *lh;
DRM_DEBUG_KMS("DM_IRQ\n
[PATCH 1/2] drm: distinguish return value of drm_dp_check_and_send_link_address.
From: Xiaogang Chen drm_dp_check_and_send_link_address discovers MST device topology. It can return both positive and negative values. When it returns positive values there is no error found. If it returns negative values there is error found, such as get NAK , timeout, etc. Following drm_kms_helper_hotplug_event should be called when drm_dp_check_and_send_link_address returns positive value. Signed-off-by: Xiaogang Chen --- drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index 17dbed0..3ef5206 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -2650,7 +2650,7 @@ static void drm_dp_mst_link_probe_work(struct work_struct *work) drm_dp_mst_topology_put_mstb(mstb); mutex_unlock(&mgr->probe_lock); - if (ret) + if (ret > 0) drm_kms_helper_hotplug_event(dev); } -- 2.7.4 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] drm/amdgpu: drop ras ta firmware loading for non-ras asic
Otherwise, below confused message is always printed during boot
for asics without ras feature, but with common ta firmware.
amdgpu: RAS: optional ras ta ucode is not available
Signed-off-by: Guchun Chen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 5 +++--
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 22 --
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h | 2 ++
3 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index eb19ae734396..730bc1fe2036 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -1135,9 +1135,10 @@ static int psp_ras_initialize(struct psp_context *psp)
int ret;
/*
-* TODO: bypass the initialize in sriov for now
+* TODO: bypass the initialize in sriov and non-ras case
*/
- if (amdgpu_sriov_vf(psp->adev))
+ if (amdgpu_sriov_vf(psp->adev) ||
+ !amdgpu_ras_check_enablement_by_asic(psp->adev))
return 0;
if (!psp->adev->psp.ta_ras_ucode_size ||
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index c136bd449744..41d97e56271e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
@@ -1897,15 +1897,17 @@ int amdgpu_ras_request_reset_on_boot(struct
amdgpu_device *adev,
return 0;
}
-static int amdgpu_ras_check_asic_type(struct amdgpu_device *adev)
-{
- if (adev->asic_type != CHIP_VEGA10 &&
- adev->asic_type != CHIP_VEGA20 &&
- adev->asic_type != CHIP_ARCTURUS &&
- adev->asic_type != CHIP_SIENNA_CICHLID)
- return 1;
- else
- return 0;
+bool amdgpu_ras_check_enablement_by_asic(struct amdgpu_device *adev)
+{
+ switch (adev->asic_type) {
+ case CHIP_VEGA10:
+ case CHIP_VEGA20:
+ case CHIP_ARCTURUS:
+ case CHIP_SIENNA_CICHLID:
+ return true;
+ default:
+ return false;
+ }
}
/*
@@ -1924,7 +1926,7 @@ static void amdgpu_ras_check_supported(struct
amdgpu_device *adev,
*supported = 0;
if (amdgpu_sriov_vf(adev) || !adev->is_atom_fw ||
- amdgpu_ras_check_asic_type(adev))
+ !amdgpu_ras_check_enablement_by_asic(adev))
return;
if (amdgpu_atomfirmware_mem_ecc_supported(adev)) {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h
index 762f5e46c007..06b5f9d14bea 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h
@@ -629,4 +629,6 @@ void amdgpu_ras_global_ras_isr(struct amdgpu_device *adev);
void amdgpu_ras_set_error_query_ready(struct amdgpu_device *adev, bool ready);
bool amdgpu_ras_need_emergency_restart(struct amdgpu_device *adev);
+
+bool amdgpu_ras_check_enablement_by_asic(struct amdgpu_device *adev);
#endif
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: fix potential NULL pointer when check_atom_bios() fails
Am 31.12.20 um 09:47 schrieb Jiawei Gu:
Asic funcs pointer needs being checked whether is NULL. Because when
check_atom_bios() fails in req_init_data handshake, asic funcs pointer
is not initialized yet.
Mhm, I'm wondering if we shouldn't change the init sequence then. The
asic_funcs is something pretty fundamental.
Signed-off-by: Jiawei Gu
Acked-by: Christian König for now.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
index 6333cada1e09..efdf639f6593 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
@@ -155,7 +155,7 @@ static bool amdgpu_read_bios_from_rom(struct amdgpu_device
*adev)
u8 header[AMD_VBIOS_SIGNATURE_END+1] = {0};
int len;
- if (!adev->asic_funcs->read_bios_from_rom)
+ if (!adev->asic_funcs || !adev->asic_funcs->read_bios_from_rom)
return false;
/* validate VBIOS signature */
@@ -348,7 +348,8 @@ static bool amdgpu_read_disabled_bios(struct amdgpu_device
*adev)
if (adev->flags & AMD_IS_APU)
return igp_read_bios_from_vram(adev);
else
- return amdgpu_asic_read_disabled_bios(adev);
+ return (!adev->asic_funcs ||
!adev->asic_funcs->read_disabled_bios) ?
+ false : amdgpu_asic_read_disabled_bios(adev);
}
#ifdef CONFIG_ACPI
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH v2] drm/amdgpu: Do not change amdgpu framebuffer format during page flip
Am 29.12.20 um 22:10 schrieb Zhan Liu: [Why] Driver cannot change amdgpu framebuffer (afb) format while doing page flip. Force system doing so will cause ioctl error, and result in breaking several functionalities including FreeSync. If afb format is forced to change during page flip, following message will appear in dmesg.log: "[drm:drm_mode_page_flip_ioctl [drm]] Page flip is not allowed to change frame buffer format." [How] Do not change afb format while doing page flip. It is okay to check whether afb format is valid here, however, forcing afb format change shouldn't happen here. I don't think this we can do this. It is perfectly valid for a page flip to switch between linear and tiled formats on an I+A or A+A laptop. Christian. Signed-off-by: Zhan Liu --- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) Thanks Nick and Bas. Here is my second patch for review. diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c index a638709e9c92..8a12e27ff4ec 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c @@ -832,7 +832,8 @@ static int convert_tiling_flags_to_modifier(struct amdgpu_framebuffer *afb) if (!format_info) return -EINVAL; - afb->base.format = format_info; + if (!afb->base.format) + afb->base.format = format_info; } } ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: amdgpu does not support 3840x2160@30Hz on kaveri apu
Hi You're probably best reporting the bug here: https://gitlab.freedesktop.org/drm/amd/-/issues Attach the output of dmesg from both Radeon and AMDGPU and the compositor / Wayland logs (as you're not using X) Cheers Mike On Sun, 3 Jan 2021, 06:32 Davide Corrado, wrote: > hello, I'd like to report this issue that I am having since I updated my > display (samsung U28E590). The amdgpu does not support the native > resolution of my new monitor, which is 3840x2160*.* Using a HDMI or DVI > connection (I tried both, same results), the maximum supported refresh is > 30Hz, so I'm stuck with that (don't have a displayport). The radeon module > works fine, I'm having this issue just when I use amdgpu (which I'd like > to, because performance is better). > > Some info of my hardware: > > cpu: AMD A10-7870K Radeon R7, 12 Compute Cores 4C+8G > kernel version (I tried different ones and different linux distros, same > results!): 5.9.16-200.fc33.x86_64 #1 SMP Mon Dec 21 14:08:22 UTC 2020 > x86_64 x86_64 x86_64 GNU/Linux > Monitor: Samsung U28E590. > > description: > If I boot the system using amdgpu and no video mode selection, the system > boots but I don't get a screen during boot and in wayland. I can connect > using ssh, so the system is running fine, just no display; If I force a > full HD resolution with "video:" in the kernel line, I can see the boot > process but the screen disappears when wayland starts (because the default > resolution is 3840x2160@30Hz). Using a full HD monitor results in no > issues, so it must be related to this very 4k resolution. > > As I have already stated, radeon module works with the same > software/hardware configuration. > thanks you so much for your time :-) > > -- > Davide Corrado > UNIX Team Leader > > Via Abramo Lincoln, 25 > 20129 Milano > > Tel +39 3474259950 > ___ > amd-gfx mailing list > amd-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx > ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
