[PATCH 1/2] drm/amdgpu: avoid null pointer dereference
null ptr should be checked first to avoid null ptr access
Change-Id: I85c0a096eef77cad3a34265c995b1845451e04d0
Signed-off-by: Guchun Chen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index 090daf595469..c3090f0eb604 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
@@ -1334,13 +1334,13 @@ static int amdgpu_ras_save_bad_pages(struct
amdgpu_device *adev)
{
struct amdgpu_ras *con = amdgpu_ras_get_context(adev);
struct ras_err_handler_data *data;
- struct amdgpu_ras_eeprom_control *control =
- >psp.ras.ras->eeprom_control;
+ struct amdgpu_ras_eeprom_control *control;
int save_count;
if (!con || !con->eh_data)
return 0;
+ control = >psp.ras.ras->eeprom_control;
data = con->eh_data;
save_count = data->count - control->num_recs;
/* only new entries are saved */
--
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: remove redundant variable definition
No need to define the same variables in each loop of the function.
Change-Id: Id8bbcc5a2ac87e9d31a72244345fde2d6bb99d42
Signed-off-by: Guchun Chen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c
index d0e020ef73e3..20af0a17d00b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c
@@ -359,8 +359,9 @@ int amdgpu_ras_eeprom_process_recods(struct
amdgpu_ras_eeprom_control *control,
int num)
{
int i, ret = 0;
- struct i2c_msg *msgs;
- unsigned char *buffs;
+ struct i2c_msg *msgs, *msg;
+ unsigned char *buffs, *buff;
+ struct eeprom_table_record *record;
struct amdgpu_device *adev = to_amdgpu_device(control);
if (adev->asic_type != CHIP_VEGA20)
@@ -390,9 +391,9 @@ int amdgpu_ras_eeprom_process_recods(struct
amdgpu_ras_eeprom_control *control,
* 256b
*/
for (i = 0; i < num; i++) {
- unsigned char *buff = [i * (EEPROM_ADDRESS_SIZE +
EEPROM_TABLE_RECORD_SIZE)];
- struct eeprom_table_record *record = [i];
- struct i2c_msg *msg = [i];
+ buff = [i * (EEPROM_ADDRESS_SIZE +
EEPROM_TABLE_RECORD_SIZE)];
+ record = [i];
+ msg = [i];
control->next_addr =
__correct_eeprom_dest_address(control->next_addr);
@@ -432,8 +433,8 @@ int amdgpu_ras_eeprom_process_recods(struct
amdgpu_ras_eeprom_control *control,
if (!write) {
for (i = 0; i < num; i++) {
- unsigned char *buff = [i*(EEPROM_ADDRESS_SIZE +
EEPROM_TABLE_RECORD_SIZE)];
- struct eeprom_table_record *record = [i];
+ buff = [i*(EEPROM_ADDRESS_SIZE +
EEPROM_TABLE_RECORD_SIZE)];
+ record = [i];
__decode_table_record_from_buff(control, record, buff +
EEPROM_ADDRESS_SIZE);
}
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: flag navi12 and 14 as experimental for 5.4
Reviewed-by: Xiaojie Yuan
BR,
Xiaojie
> On Sep 18, 2019, at 3:52 AM, Alex Deucher wrote:
>
> We can remove this later as things get closer to launch.
>
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index c68e54a27a2c..5da72ca6f3e1 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -1011,15 +1011,15 @@ static const struct pci_device_id pciidlist[] = {
>{0x1002, 0x731B, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI10},
>{0x1002, 0x731F, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI10},
>/* Navi14 */
> -{0x1002, 0x7340, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI14},
> -{0x1002, 0x7341, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI14},
> -{0x1002, 0x7347, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI14},
> +{0x1002, 0x7340, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> CHIP_NAVI14|AMD_EXP_HW_SUPPORT},
> +{0x1002, 0x7341, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> CHIP_NAVI14|AMD_EXP_HW_SUPPORT},
> +{0x1002, 0x7347, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> CHIP_NAVI14|AMD_EXP_HW_SUPPORT},
>
>/* Renoir */
>{0x1002, 0x1636, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> CHIP_RENOIR|AMD_IS_APU|AMD_EXP_HW_SUPPORT},
>
>/* Navi12 */
> -{0x1002, 0x7360, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI12},
> +{0x1002, 0x7360, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> CHIP_NAVI12|AMD_EXP_HW_SUPPORT},
>
>{0, 0, 0}
> };
> --
> 2.20.1
>
> ___
> 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
RE: [PATCH 1/2] drm/amdgpu/psp: flush HDP write fifo after submitting cmds to the psp
Reviewed-by: Feifei Xu -Original Message- From: amd-gfx On Behalf Of Alex Deucher Sent: Wednesday, September 18, 2019 4:21 AM To: amd-gfx@lists.freedesktop.org Cc: Deucher, Alexander Subject: [PATCH 1/2] drm/amdgpu/psp: flush HDP write fifo after submitting cmds to the psp We need to make sure the fifo is flushed before we ask the psp to process the commands. Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/psp_v10_0.c | 1 + drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 1 + drivers/gpu/drm/amd/amdgpu/psp_v12_0.c | 1 + drivers/gpu/drm/amd/amdgpu/psp_v3_1.c | 1 + 4 files changed, 4 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v10_0.c b/drivers/gpu/drm/amd/amdgpu/psp_v10_0.c index 6ee33f368e21..b96484a72535 100644 --- a/drivers/gpu/drm/amd/amdgpu/psp_v10_0.c +++ b/drivers/gpu/drm/amd/amdgpu/psp_v10_0.c @@ -266,6 +266,7 @@ static int psp_v10_0_cmd_submit(struct psp_context *psp, write_frame->fence_addr_hi = upper_32_bits(fence_mc_addr); write_frame->fence_addr_lo = lower_32_bits(fence_mc_addr); write_frame->fence_value = index; + amdgpu_asic_flush_hdp(adev, NULL); /* Update the write Pointer in DWORDs */ psp_write_ptr_reg = (psp_write_ptr_reg + rb_frame_size_dw) % ring_size_dw; diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c index 64802e88a9a2..04318cfd50a8 100644 --- a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c +++ b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c @@ -549,6 +549,7 @@ static int psp_v11_0_cmd_submit(struct psp_context *psp, write_frame->fence_addr_hi = upper_32_bits(fence_mc_addr); write_frame->fence_addr_lo = lower_32_bits(fence_mc_addr); write_frame->fence_value = index; + amdgpu_asic_flush_hdp(adev, NULL); /* Update the write Pointer in DWORDs */ psp_write_ptr_reg = (psp_write_ptr_reg + rb_frame_size_dw) % ring_size_dw; diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c b/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c index c72e43f8e0be..8f553f6f92d6 100644 --- a/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c +++ b/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c @@ -378,6 +378,7 @@ static int psp_v12_0_cmd_submit(struct psp_context *psp, write_frame->fence_addr_hi = upper_32_bits(fence_mc_addr); write_frame->fence_addr_lo = lower_32_bits(fence_mc_addr); write_frame->fence_value = index; + amdgpu_asic_flush_hdp(adev, NULL); /* Update the write Pointer in DWORDs */ psp_write_ptr_reg = (psp_write_ptr_reg + rb_frame_size_dw) % ring_size_dw; diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v3_1.c b/drivers/gpu/drm/amd/amdgpu/psp_v3_1.c index d2c727f6a8bd..fdc00938327b 100644 --- a/drivers/gpu/drm/amd/amdgpu/psp_v3_1.c +++ b/drivers/gpu/drm/amd/amdgpu/psp_v3_1.c @@ -454,6 +454,7 @@ static int psp_v3_1_cmd_submit(struct psp_context *psp, write_frame->fence_addr_hi = upper_32_bits(fence_mc_addr); write_frame->fence_addr_lo = lower_32_bits(fence_mc_addr); write_frame->fence_value = index; + amdgpu_asic_flush_hdp(adev, NULL); /* Update the write Pointer in DWORDs */ psp_write_ptr_reg = (psp_write_ptr_reg + rb_frame_size_dw) % ring_size_dw; -- 2.20.1 ___ 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
RE: [PATCH 2/2] drm/amdgpu/psp: invalidate the hdp read cache before reading the psp response
Reviewed-by: Feifei Xu
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Wednesday, September 18, 2019 4:21 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH 2/2] drm/amdgpu/psp: invalidate the hdp read cache before
reading the psp response
Otherwise we may get stale data.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index bc46a429b4dc..7991edf58123 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -151,10 +151,12 @@ psp_cmd_submit_buf(struct psp_context *psp,
return ret;
}
+ amdgpu_asic_invalidate_hdp(psp->adev, NULL);
while (*((unsigned int *)psp->fence_buf) != index) {
if (--timeout == 0)
break;
msleep(1);
+ amdgpu_asic_invalidate_hdp(psp->adev, NULL);
}
/* In some cases, psp response status is not 0 even there is no
--
2.20.1
___
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
RE: [PATCH] drm/amdgpu: add psp ip block for arct
Reviewed-by: Feifei Xu -Original Message- From: amd-gfx On Behalf Of Zhang, Hawking Sent: Wednesday, September 18, 2019 7:09 AM To: amd-gfx@lists.freedesktop.org; Deucher, Alexander ; Clements, John Cc: Zhang, Hawking Subject: [PATCH] drm/amdgpu: add psp ip block for arct enable psp block for firmware loading and other security feature setup. Signed-off-by: Hawking Zhang --- drivers/gpu/drm/amd/amdgpu/soc15.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/soc15.c b/drivers/gpu/drm/amd/amdgpu/soc15.c index 284a6435bfdc..6faa1f625896 100644 --- a/drivers/gpu/drm/amd/amdgpu/soc15.c +++ b/drivers/gpu/drm/amd/amdgpu/soc15.c @@ -755,6 +755,8 @@ int soc15_set_ip_blocks(struct amdgpu_device *adev) amdgpu_device_ip_block_add(adev, _common_ip_block); amdgpu_device_ip_block_add(adev, _v9_0_ip_block); amdgpu_device_ip_block_add(adev, _ih_ip_block); + if (likely(adev->firmware.load_type == AMDGPU_FW_LOAD_PSP)) + amdgpu_device_ip_block_add(adev, _v11_0_ip_block); if (adev->enable_virtual_display || amdgpu_sriov_vf(adev)) amdgpu_device_ip_block_add(adev, _virtual_ip_block); amdgpu_device_ip_block_add(adev, _v9_0_ip_block); -- 2.17.1 ___ 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
RE: [PATCH] drm/amdgpu: do not init mec2 jt for renoir
Reviewed-by: Feifei Xu
-Original Message-
From: amd-gfx On Behalf Of Zhang,
Hawking
Sent: Wednesday, September 18, 2019 7:09 AM
To: amd-gfx@lists.freedesktop.org; Deucher, Alexander
; Clements, John
Cc: Zhang, Hawking
Subject: [PATCH] drm/amdgpu: do not init mec2 jt for renoir
For ASICs like renoir/arct, driver doesn't need to load mec2 jt.
when mec1 jt is loaded, mec2 jt will be loaded automatically since the write is
actaully broadcasted to both.
We need to more time to test other gfx9 asic. but for now we should be able to
draw conclusion that mec2 jt is not needed for renoir and arct.
Signed-off-by: Hawking Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 4
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 3 ++-
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index 6e49433dd874..ce36876d64df 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -1068,10 +1068,6 @@ static int psp_np_fw_load(struct psp_context *psp)
ucode->ucode_id == AMDGPU_UCODE_ID_CP_MEC2_JT))
/* skip mec JT when autoload is enabled */
continue;
- /* Renoir only needs to load mec jump table one time */
- if (adev->asic_type == CHIP_RENOIR &&
- ucode->ucode_id == AMDGPU_UCODE_ID_CP_MEC2_JT)
- continue;
psp_print_fw_hdr(psp, ucode);
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index 49c686e80ea5..b13e48332dc8 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -1321,7 +1321,8 @@ static int gfx_v9_0_init_cp_compute_microcode(struct
amdgpu_device *adev,
/* TODO: Determine if MEC2 JT FW loading can be removed
for all GFX V9 asic and above */
- if (adev->asic_type != CHIP_ARCTURUS) {
+ if (adev->asic_type != CHIP_ARCTURUS &&
+ adev->asic_type != CHIP_RENOIR) {
info =
>firmware.ucode[AMDGPU_UCODE_ID_CP_MEC2_JT];
info->ucode_id = AMDGPU_UCODE_ID_CP_MEC2_JT;
info->fw = adev->gfx.mec2_fw;
--
2.17.1
___
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
Re: [PATCH] drm: add drm device name
drmVersion::name = amdgpu, radeon, intel, etc. drmVersion::desc = vega10, vega12, vega20, ... The common Mesa code will use name and desc to select the driver. The AMD-specific Mesa code will use desc to identify the chip. Mesa won't receive any PCI IDs for future chips. Marek On Tue, Sep 17, 2019 at 10:33 AM Michel Dänzer wrote: > On 2019-09-17 1:20 p.m., Christian König wrote: > > Am 17.09.19 um 11:27 schrieb Michel Dänzer: > >> On 2019-09-17 11:23 a.m., Michel Dänzer wrote: > >>> On 2019-09-17 10:23 a.m., Koenig, Christian wrote: > Am 17.09.19 um 10:17 schrieb Daniel Vetter: > > On Tue, Sep 17, 2019 at 10:12 AM Christian König > > wrote: > >> Am 17.09.19 um 07:47 schrieb Jani Nikula: > >>> On Mon, 16 Sep 2019, Marek Olšák wrote: > The purpose is to get rid of all PCI ID tables for all drivers in > userspace. (or at least stop updating them) > > Mesa common code and modesetting will use this. > >>> I'd think this would warrant a high level description of what you > >>> want > >>> to achieve in the commit message. > >> And maybe explicitly call it uapi_name or even uapi_driver_name. > > If it's uapi_name, then why do we need a new one for every > generation? > > Userspace drivers tend to span a lot more than just 1 generation. And > > if you want to have per-generation data from the kernel to userspace, > > then imo that's much better suited in some amdgpu ioctl, instead of > > trying to encode that into the driver name. > Well we already have an IOCTL for that, but I thought the intention > here > was to get rid of the PCI-ID tables in userspace to figure out which > driver to load. > >>> That's just unrealistic in general, I'm afraid. See e.g. the ongoing > >>> transition from i965 to iris for recent Intel hardware. How is the > >>> kernel supposed to know which driver is to be used? > > > > Well how is userspace currently handling that? The kernel should NOT say > > which driver to use in userspace, but rather which one is used in the > > kernel. > > Would that really help though? E.g. the radeon kernel driver supports > radeon/r200/r300/r600/radeonsi DRI drivers, the i915 one i915/i965/iris > (and the amdgpu one radeonsi/amdgpu). > > The HW generation identifier proposed in these patches might be useful, > but I suspect there'll always be cases where userspace needs to know > more precisely. > > > > Mapping that information to an userspace driver still needs to be done > > somewhere else, but the difference is that you don't need to add all > > PCI-IDs twice. > > It should only really be necessary in Mesa. > > > On 2019-09-17 1:32 p.m., Daniel Vetter wrote: > > How are other compositors solving this? I don't expect they have a > > pciid table like modesetting copied to all of them ... > > They don't need any of this. The Xorg modesetting driver only did for > determining the client driver name to advertise via the DRI2 extension. > > > -- > Earthling Michel Dänzer | https://redhat.com > Libre software enthusiast | Mesa and X developer > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] drm/amdgpu: add psp ip block for arct
enable psp block for firmware loading and other security feature setup. Signed-off-by: Hawking Zhang --- drivers/gpu/drm/amd/amdgpu/soc15.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/soc15.c b/drivers/gpu/drm/amd/amdgpu/soc15.c index 284a6435bfdc..6faa1f625896 100644 --- a/drivers/gpu/drm/amd/amdgpu/soc15.c +++ b/drivers/gpu/drm/amd/amdgpu/soc15.c @@ -755,6 +755,8 @@ int soc15_set_ip_blocks(struct amdgpu_device *adev) amdgpu_device_ip_block_add(adev, _common_ip_block); amdgpu_device_ip_block_add(adev, _v9_0_ip_block); amdgpu_device_ip_block_add(adev, _ih_ip_block); + if (likely(adev->firmware.load_type == AMDGPU_FW_LOAD_PSP)) + amdgpu_device_ip_block_add(adev, _v11_0_ip_block); if (adev->enable_virtual_display || amdgpu_sriov_vf(adev)) amdgpu_device_ip_block_add(adev, _virtual_ip_block); amdgpu_device_ip_block_add(adev, _v9_0_ip_block); -- 2.17.1 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] drm/amdgpu: do not init mec2 jt for renoir
For ASICs like renoir/arct, driver doesn't need to load mec2 jt.
when mec1 jt is loaded, mec2 jt will be loaded automatically
since the write is actaully broadcasted to both.
We need to more time to test other gfx9 asic. but for now we should
be able to draw conclusion that mec2 jt is not needed for renoir and
arct.
Signed-off-by: Hawking Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 4
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 3 ++-
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index 6e49433dd874..ce36876d64df 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -1068,10 +1068,6 @@ static int psp_np_fw_load(struct psp_context *psp)
ucode->ucode_id == AMDGPU_UCODE_ID_CP_MEC2_JT))
/* skip mec JT when autoload is enabled */
continue;
- /* Renoir only needs to load mec jump table one time */
- if (adev->asic_type == CHIP_RENOIR &&
- ucode->ucode_id == AMDGPU_UCODE_ID_CP_MEC2_JT)
- continue;
psp_print_fw_hdr(psp, ucode);
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index 49c686e80ea5..b13e48332dc8 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -1321,7 +1321,8 @@ static int gfx_v9_0_init_cp_compute_microcode(struct
amdgpu_device *adev,
/* TODO: Determine if MEC2 JT FW loading can be removed
for all GFX V9 asic and above */
- if (adev->asic_type != CHIP_ARCTURUS) {
+ if (adev->asic_type != CHIP_ARCTURUS &&
+ adev->asic_type != CHIP_RENOIR) {
info =
>firmware.ucode[AMDGPU_UCODE_ID_CP_MEC2_JT];
info->ucode_id = AMDGPU_UCODE_ID_CP_MEC2_JT;
info->fw = adev->gfx.mec2_fw;
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/display: Create plane rotation property
On 9/12/19 10:32 AM, Pierre-Loup A. Griffais wrote: On 9/12/19 10:22 AM, Harry Wentland wrote: On 2019-09-12 1:01 p.m., Kazlauskas, Nicholas wrote: On 2019-09-12 12:44 p.m., Pierre-Loup A. Griffais wrote: It's otherwise properly supported, just needs exposing to userspace. Signed-off-by: Pierre-Loup A. Griffais I know IGT has some tests for plane rotation, do you happen to know what tests pass or fail when exposing this? I think DCN1 (Raven) should work as expected but I'd be concerned about DCE or DCN2. I think we have had some cursor bugs in the past with cursor rotation but they might only be exposed when used in conjunction with overlay planes. Windows guys had a fix (in DC) for cursor with HW rotation on DCN a few weeks ago. That might have fixed these issues. We should still make sure we can pass IGT tests that do rotation. How did you test? Weston? I've tested it with a patched kmscube to add the rotation property in the atomic path. 90, 180 and 270 all seem happy on Raven with that setup. I've not tested any other chip at this point. If there's more testing you'd like me to do, would anyone point me in the right direction? I'm new to all this, sorry. Thanks, - Pierre-Loup Harry I'd just like to make sure there's suitable testing at least if we're going to expose this to userspace. Nicholas Kazlauskas --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8 1 file changed, 8 insertions(+) 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 45be7a2132bb..3772763c6449 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -4680,6 +4680,7 @@ static int amdgpu_dm_plane_init(struct amdgpu_display_manager *dm, uint32_t formats[32]; int num_formats; int res = -EPERM; + unsigned int supported_rotations; num_formats = get_plane_formats(plane, plane_cap, formats, ARRAY_SIZE(formats)); @@ -4711,6 +4712,13 @@ static int amdgpu_dm_plane_init(struct amdgpu_display_manager *dm, DRM_COLOR_YCBCR_BT709, DRM_COLOR_YCBCR_LIMITED_RANGE); } + supported_rotations = + DRM_MODE_ROTATE_0 | DRM_MODE_ROTATE_90 | + DRM_MODE_ROTATE_180 | DRM_MODE_ROTATE_270; + + drm_plane_create_rotation_property(plane, DRM_MODE_ROTATE_0, + supported_rotations); + drm_plane_helper_add(plane, _plane_helper_funcs); /* Create (reset) the plane state */ ___ 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
Re: Re：[PATCH] drm/amdgpu: resvert "disable bulk moves for now"
Hello,
Applying this locally, the issue we were seeing with very high submit
times in high-end workloads seems largely gone. My methodology is to
measure the total time spent in DRM_IOCTL_AMDGPU_CS with `strace -T` for
the whole first scene of the Shadow of the Tomb Raider benchmark, and
divide by the frame count in that scene to get an idea of how much CPU
time is spent in submissions per frame. More details below.
On a Vega20 system with a 3900X, at High settings (~6 gigs of VRAM usage
according to UMR, no contention):
- 5.2.14: 1.1ms per frame in CS
- 5.2.14 + LRU bulk moves: 0.6ms per frame in CS
On a Polaris10 system with a i7-7820X, at Very High Settings (7.7G/8G
VRAM used, no contention):
- 5.2.15: 12.03ms per frame in CS (!)
- 5.2.15 + LRU bulk moves: 1.35ms per frame in CS
The issue is largely addressed. 1.35ms is still higher than I'd expect,
but it's still pretty reasonable. Note that on many of our usecases,
submission happens in a separate thread and doesn't typically impact
overall frame time/latency if you have extra CPU cores to work with.
However it very negatively affects performance as soon as the CPU gets
saturated, and burns a ton of power.
Thanks!
- Pierre-Loup
Methodology details:
# Mesa patched to kill() itself with SIGCONT in vkQueuePresent to act as
a frame marker in-band with the strace data.
# strace collection:
strace -f -p 13113 -e ioctl,kill -o sottr_first_scene_vanilla -T
# frame count:
cat sottr_first_scene_vanilla | grep kill\( | wc -l
616
# total time spent in _CS:
cat sottr_first_scene_vanilla | grep AMDGPU_CS | grep -v unfinished | tr
-s ' ' | cut -d ' ' -f7 | tr -d \< | tr -d \> | xargs | tr ' ' '+' | bc
7.411782
# seconds to milliseconds, then divide by frame count
(gdb) p 7.41 * 1000.0 / 616.0
$1 = 12.029220779220779
On 9/12/19 8:18 AM, Zhou, David(ChunMing) wrote:
I dont know dkms status，anyway, we should submit this one as early as
possible.
原始邮件
主题：Re: [PATCH] drm/amdgpu: resvert "disable bulk moves for now"
发件人：Christian König
收件人："Zhou, David(ChunMing)" ,amd-gfx@lists.freedesktop.org
抄送：
Just to double check: We do have that enabled in the DKMS package for a
while and doesn't encounter any more problems with it, correct?
Thanks,
Christian.
Am 12.09.19 um 16:02 schrieb Chunming Zhou:
> RB on it to go ahead.
>
> -David
>
> 在 2019/9/12 18:15, Christian König 写道:
>> This reverts commit a213c2c7e235cfc0e0a161a558f7fdf2fb3a624a.
>>
>> The changes to fix this should have landed in 5.1.
>>
>> Signed-off-by: Christian König
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 --
>> 1 file changed, 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> index 48349e4f0701..fd3fbaa73fa3 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> @@ -603,14 +603,12 @@ void amdgpu_vm_move_to_lru_tail(struct
amdgpu_device *adev,
>> struct ttm_bo_global *glob = adev->mman.bdev.glob;
>> struct amdgpu_vm_bo_base *bo_base;
>>
>> -#if 0
>> if (vm->bulk_moveable) {
>> spin_lock(>lru_lock);
>> ttm_bo_bulk_move_lru_tail(>lru_bulk_move);
>> spin_unlock(>lru_lock);
>> return;
>> }
>> -#endif
>>
>> memset(>lru_bulk_move, 0, sizeof(vm->lru_bulk_move));
>>
___
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
[PATCH 2/2] drm/amdgpu/psp: invalidate the hdp read cache before reading the psp response
Otherwise we may get stale data.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index bc46a429b4dc..7991edf58123 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -151,10 +151,12 @@ psp_cmd_submit_buf(struct psp_context *psp,
return ret;
}
+ amdgpu_asic_invalidate_hdp(psp->adev, NULL);
while (*((unsigned int *)psp->fence_buf) != index) {
if (--timeout == 0)
break;
msleep(1);
+ amdgpu_asic_invalidate_hdp(psp->adev, NULL);
}
/* In some cases, psp response status is not 0 even there is no
--
2.20.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 1/2] drm/amdgpu/psp: flush HDP write fifo after submitting cmds to the psp
We need to make sure the fifo is flushed before we ask the psp to process the commands. Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/psp_v10_0.c | 1 + drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 1 + drivers/gpu/drm/amd/amdgpu/psp_v12_0.c | 1 + drivers/gpu/drm/amd/amdgpu/psp_v3_1.c | 1 + 4 files changed, 4 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v10_0.c b/drivers/gpu/drm/amd/amdgpu/psp_v10_0.c index 6ee33f368e21..b96484a72535 100644 --- a/drivers/gpu/drm/amd/amdgpu/psp_v10_0.c +++ b/drivers/gpu/drm/amd/amdgpu/psp_v10_0.c @@ -266,6 +266,7 @@ static int psp_v10_0_cmd_submit(struct psp_context *psp, write_frame->fence_addr_hi = upper_32_bits(fence_mc_addr); write_frame->fence_addr_lo = lower_32_bits(fence_mc_addr); write_frame->fence_value = index; + amdgpu_asic_flush_hdp(adev, NULL); /* Update the write Pointer in DWORDs */ psp_write_ptr_reg = (psp_write_ptr_reg + rb_frame_size_dw) % ring_size_dw; diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c index 64802e88a9a2..04318cfd50a8 100644 --- a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c +++ b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c @@ -549,6 +549,7 @@ static int psp_v11_0_cmd_submit(struct psp_context *psp, write_frame->fence_addr_hi = upper_32_bits(fence_mc_addr); write_frame->fence_addr_lo = lower_32_bits(fence_mc_addr); write_frame->fence_value = index; + amdgpu_asic_flush_hdp(adev, NULL); /* Update the write Pointer in DWORDs */ psp_write_ptr_reg = (psp_write_ptr_reg + rb_frame_size_dw) % ring_size_dw; diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c b/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c index c72e43f8e0be..8f553f6f92d6 100644 --- a/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c +++ b/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c @@ -378,6 +378,7 @@ static int psp_v12_0_cmd_submit(struct psp_context *psp, write_frame->fence_addr_hi = upper_32_bits(fence_mc_addr); write_frame->fence_addr_lo = lower_32_bits(fence_mc_addr); write_frame->fence_value = index; + amdgpu_asic_flush_hdp(adev, NULL); /* Update the write Pointer in DWORDs */ psp_write_ptr_reg = (psp_write_ptr_reg + rb_frame_size_dw) % ring_size_dw; diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v3_1.c b/drivers/gpu/drm/amd/amdgpu/psp_v3_1.c index d2c727f6a8bd..fdc00938327b 100644 --- a/drivers/gpu/drm/amd/amdgpu/psp_v3_1.c +++ b/drivers/gpu/drm/amd/amdgpu/psp_v3_1.c @@ -454,6 +454,7 @@ static int psp_v3_1_cmd_submit(struct psp_context *psp, write_frame->fence_addr_hi = upper_32_bits(fence_mc_addr); write_frame->fence_addr_lo = lower_32_bits(fence_mc_addr); write_frame->fence_value = index; + amdgpu_asic_flush_hdp(adev, NULL); /* Update the write Pointer in DWORDs */ psp_write_ptr_reg = (psp_write_ptr_reg + rb_frame_size_dw) % ring_size_dw; -- 2.20.1 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] drm/amdgpu: flag navi12 and 14 as experimental for 5.4
We can remove this later as things get closer to launch.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index c68e54a27a2c..5da72ca6f3e1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1011,15 +1011,15 @@ static const struct pci_device_id pciidlist[] = {
{0x1002, 0x731B, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI10},
{0x1002, 0x731F, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI10},
/* Navi14 */
- {0x1002, 0x7340, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI14},
- {0x1002, 0x7341, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI14},
- {0x1002, 0x7347, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI14},
+ {0x1002, 0x7340, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_NAVI14|AMD_EXP_HW_SUPPORT},
+ {0x1002, 0x7341, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_NAVI14|AMD_EXP_HW_SUPPORT},
+ {0x1002, 0x7347, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_NAVI14|AMD_EXP_HW_SUPPORT},
/* Renoir */
{0x1002, 0x1636, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RENOIR|AMD_IS_APU|AMD_EXP_HW_SUPPORT},
/* Navi12 */
- {0x1002, 0x7360, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI12},
+ {0x1002, 0x7360, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_NAVI12|AMD_EXP_HW_SUPPORT},
{0, 0, 0}
};
--
2.20.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu/SRIOV: add navi12 pci id for SRIOV
On Tue, Sep 17, 2019 at 3:12 AM wrote:
>
> From: Jiange Zhao
>
> Add Navi12 PCI id support.
>
> Signed-off-by: Jiange Zhao
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 420888e941df..b52c7255e5e4 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -1034,6 +1034,7 @@ static const struct pci_device_id pciidlist[] = {
>
> /* Navi12 */
> {0x1002, 0x7360, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI12},
> + {0x1002, 0x7362, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI12},
>
> {0, 0, 0}
> };
> --
> 2.20.1
>
> ___
> 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
Re: [PATCH] drm/amdgpu/powerplay: add new mapping for APCC_DFLL feature
Reviewed-by: Kevin Wang
From: Yuan, Xiaojie
Sent: Tuesday, September 17, 2019 7:04 PM
To: amd-gfx@lists.freedesktop.org
Cc: Feng, Kenneth ; Quan, Evan ; Wang,
Kevin(Yang) ; Yuan, Xiaojie
Subject: [PATCH] drm/amdgpu/powerplay: add new mapping for APCC_DFLL feature
Signed-off-by: Xiaojie Yuan
---
drivers/gpu/drm/amd/powerplay/inc/smu_types.h | 1 +
drivers/gpu/drm/amd/powerplay/navi10_ppt.c| 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/powerplay/inc/smu_types.h
b/drivers/gpu/drm/amd/powerplay/inc/smu_types.h
index ab8c92a60fc4..12a1de55ce3c 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/smu_types.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/smu_types.h
@@ -252,6 +252,7 @@ enum smu_clk_type {
__SMU_DUMMY_MAP(TEMP_DEPENDENT_VMIN),\
__SMU_DUMMY_MAP(MMHUB_PG), \
__SMU_DUMMY_MAP(ATHUB_PG), \
+ __SMU_DUMMY_MAP(APCC_DFLL), \
__SMU_DUMMY_MAP(WAFL_CG),
#undef __SMU_DUMMY_MAP
diff --git a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
index 16634e657589..5a34d01f7f7c 100644
--- a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
+++ b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
@@ -176,6 +176,7 @@ static struct smu_11_0_cmn2aisc_mapping
navi10_feature_mask_map[SMU_FEATURE_COUN
FEA_MAP(TEMP_DEPENDENT_VMIN),
FEA_MAP(MMHUB_PG),
FEA_MAP(ATHUB_PG),
+ FEA_MAP(APCC_DFLL),
};
static struct smu_11_0_cmn2aisc_mapping navi10_table_map[SMU_TABLE_COUNT] = {
--
2.20.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm: add drm device name
On 2019-09-17 1:20 p.m., Christian König wrote: > Am 17.09.19 um 11:27 schrieb Michel Dänzer: >> On 2019-09-17 11:23 a.m., Michel Dänzer wrote: >>> On 2019-09-17 10:23 a.m., Koenig, Christian wrote: Am 17.09.19 um 10:17 schrieb Daniel Vetter: > On Tue, Sep 17, 2019 at 10:12 AM Christian König > wrote: >> Am 17.09.19 um 07:47 schrieb Jani Nikula: >>> On Mon, 16 Sep 2019, Marek Olšák wrote: The purpose is to get rid of all PCI ID tables for all drivers in userspace. (or at least stop updating them) Mesa common code and modesetting will use this. >>> I'd think this would warrant a high level description of what you >>> want >>> to achieve in the commit message. >> And maybe explicitly call it uapi_name or even uapi_driver_name. > If it's uapi_name, then why do we need a new one for every generation? > Userspace drivers tend to span a lot more than just 1 generation. And > if you want to have per-generation data from the kernel to userspace, > then imo that's much better suited in some amdgpu ioctl, instead of > trying to encode that into the driver name. Well we already have an IOCTL for that, but I thought the intention here was to get rid of the PCI-ID tables in userspace to figure out which driver to load. >>> That's just unrealistic in general, I'm afraid. See e.g. the ongoing >>> transition from i965 to iris for recent Intel hardware. How is the >>> kernel supposed to know which driver is to be used? > > Well how is userspace currently handling that? The kernel should NOT say > which driver to use in userspace, but rather which one is used in the > kernel. Would that really help though? E.g. the radeon kernel driver supports radeon/r200/r300/r600/radeonsi DRI drivers, the i915 one i915/i965/iris (and the amdgpu one radeonsi/amdgpu). The HW generation identifier proposed in these patches might be useful, but I suspect there'll always be cases where userspace needs to know more precisely. > Mapping that information to an userspace driver still needs to be done > somewhere else, but the difference is that you don't need to add all > PCI-IDs twice. It should only really be necessary in Mesa. On 2019-09-17 1:32 p.m., Daniel Vetter wrote: > How are other compositors solving this? I don't expect they have a > pciid table like modesetting copied to all of them ... They don't need any of this. The Xorg modesetting driver only did for determining the client driver name to advertise via the DRI2 extension. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/display: Restore backlight brightness after system resume
Applied. Thanks!
Alex
On Mon, Sep 2, 2019 at 4:16 PM Kai-Heng Feng
wrote:
>
> Laptops with AMD APU doesn't restore display backlight brightness after
> system resume.
>
> This issue started when DC was introduced.
>
> Let's use BL_CORE_SUSPENDRESUME so the backlight core calls
> update_status callback after system resume to restore the backlight
> level.
>
> Tested on Dell Inspiron 3180 (Stoney Ridge) and Dell Latitude 5495
> (Raven Ridge).
>
> Cc:
> Signed-off-by: Kai-Heng Feng
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 +
> 1 file changed, 1 insertion(+)
>
> 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 1b0949dd7808..183ef18ac6f3 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -2111,6 +2111,7 @@ static int amdgpu_dm_backlight_get_brightness(struct
> backlight_device *bd)
> }
>
> static const struct backlight_ops amdgpu_dm_backlight_ops = {
> + .options = BL_CORE_SUSPENDRESUME,
> .get_brightness = amdgpu_dm_backlight_get_brightness,
> .update_status = amdgpu_dm_backlight_update_status,
> };
> --
> 2.17.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC v4 00/16] new cgroup controller for gpu/drm subsystem
On Tue, Sep 10, 2019 at 01:54:48PM +0200, Michal Hocko wrote: > On Fri 06-09-19 08:45:39, Tejun Heo wrote: > > Hello, Daniel. > > > > On Fri, Sep 06, 2019 at 05:34:16PM +0200, Daniel Vetter wrote: > > > > Hmm... what'd be the fundamental difference from slab or socket memory > > > > which are handled through memcg? Is system memory used by GPUs have > > > > further global restrictions in addition to the amount of physical > > > > memory used? > > > > > > Sometimes, but that would be specific resources (kinda like vram), > > > e.g. CMA regions used by a gpu. But probably not something you'll run > > > in a datacenter and want cgroups for ... > > > > > > I guess we could try to integrate with the memcg group controller. One > > > trouble is that aside from i915 most gpu drivers do not really have a > > > full shrinker, so not sure how that would all integrate. > > > > So, while it'd great to have shrinkers in the longer term, it's not a > > strict requirement to be accounted in memcg. It already accounts a > > lot of memory which isn't reclaimable (a lot of slabs and socket > > buffer). > > Yeah, having a shrinker is preferred but the memory should better be > reclaimable in some form. If not by any other means then at least bound > to a user process context so that it goes away with a task being killed > by the OOM killer. If that is not the case then we cannot really charge > it because then the memcg controller is of no use. We can tolerate it to > some degree if the amount of memory charged like that is negligible to > the overall size. But from the discussion it seems that these buffers > are really large. I think we can just make "must have a shrinker" as a requirement for system memory cgroup thing for gpu buffers. There's mild locking inversion fun to be had when typing one, but I think the problem is well-understood enough that this isn't a huge hurdle to climb over. And should give admins an easier to mange system, since it works more like what they know already. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm: add drm device name
On Tue, Sep 17, 2019 at 11:27 AM Michel Dänzer wrote: > > On 2019-09-17 11:23 a.m., Michel Dänzer wrote: > > On 2019-09-17 10:23 a.m., Koenig, Christian wrote: > >> Am 17.09.19 um 10:17 schrieb Daniel Vetter: > >>> On Tue, Sep 17, 2019 at 10:12 AM Christian König > >>> wrote: > Am 17.09.19 um 07:47 schrieb Jani Nikula: > > On Mon, 16 Sep 2019, Marek Olšák wrote: > >> The purpose is to get rid of all PCI ID tables for all drivers in > >> userspace. (or at least stop updating them) > >> > >> Mesa common code and modesetting will use this. > > I'd think this would warrant a high level description of what you want > > to achieve in the commit message. > And maybe explicitly call it uapi_name or even uapi_driver_name. > >>> If it's uapi_name, then why do we need a new one for every generation? > >>> Userspace drivers tend to span a lot more than just 1 generation. And > >>> if you want to have per-generation data from the kernel to userspace, > >>> then imo that's much better suited in some amdgpu ioctl, instead of > >>> trying to encode that into the driver name. > >> > >> Well we already have an IOCTL for that, but I thought the intention here > >> was to get rid of the PCI-ID tables in userspace to figure out which > >> driver to load. > > > > That's just unrealistic in general, I'm afraid. See e.g. the ongoing > > transition from i965 to iris for recent Intel hardware. How is the > > kernel supposed to know which driver is to be used? > > > > > > For the Xorg modesetting driver, there's a simple solution, see > > https://gitlab.freedesktop.org/xorg/xserver/merge_requests/278 . > > Something similar can probably be done in Mesa as well. > > Another possibility might be for Xorg to use > https://www.khronos.org/registry/EGL/extensions/MESA/EGL_MESA_query_driver.txt > to determine the driver name. Then only Mesa might need any HW specific > code. How are other compositors solving this? I don't expect they have a pciid table like modesetting copied to all of them ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm: add drm device name
Am 17.09.19 um 11:27 schrieb Michel Dänzer: On 2019-09-17 11:23 a.m., Michel Dänzer wrote: On 2019-09-17 10:23 a.m., Koenig, Christian wrote: Am 17.09.19 um 10:17 schrieb Daniel Vetter: On Tue, Sep 17, 2019 at 10:12 AM Christian König wrote: Am 17.09.19 um 07:47 schrieb Jani Nikula: On Mon, 16 Sep 2019, Marek Olšák wrote: The purpose is to get rid of all PCI ID tables for all drivers in userspace. (or at least stop updating them) Mesa common code and modesetting will use this. I'd think this would warrant a high level description of what you want to achieve in the commit message. And maybe explicitly call it uapi_name or even uapi_driver_name. If it's uapi_name, then why do we need a new one for every generation? Userspace drivers tend to span a lot more than just 1 generation. And if you want to have per-generation data from the kernel to userspace, then imo that's much better suited in some amdgpu ioctl, instead of trying to encode that into the driver name. Well we already have an IOCTL for that, but I thought the intention here was to get rid of the PCI-ID tables in userspace to figure out which driver to load. That's just unrealistic in general, I'm afraid. See e.g. the ongoing transition from i965 to iris for recent Intel hardware. How is the kernel supposed to know which driver is to be used? Well how is userspace currently handling that? The kernel should NOT say which driver to use in userspace, but rather which one is used in the kernel. Mapping that information to an userspace driver still needs to be done somewhere else, but the difference is that you don't need to add all PCI-IDs twice. Christian. For the Xorg modesetting driver, there's a simple solution, see https://gitlab.freedesktop.org/xorg/xserver/merge_requests/278 . Something similar can probably be done in Mesa as well. Another possibility might be for Xorg to use https://www.khronos.org/registry/EGL/extensions/MESA/EGL_MESA_query_driver.txt to determine the driver name. Then only Mesa might need any HW specific code. ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
RE: [PATCH] drm/amdgpu/powerplay: add new mapping for APCC_DFLL feature
Reviewed-by: Evan Quan
-Original Message-
From: Yuan, Xiaojie
Sent: Tuesday, September 17, 2019 7:05 PM
To: amd-gfx@lists.freedesktop.org
Cc: Feng, Kenneth ; Quan, Evan ; Wang,
Kevin(Yang) ; Yuan, Xiaojie
Subject: [PATCH] drm/amdgpu/powerplay: add new mapping for APCC_DFLL feature
Signed-off-by: Xiaojie Yuan
---
drivers/gpu/drm/amd/powerplay/inc/smu_types.h | 1 +
drivers/gpu/drm/amd/powerplay/navi10_ppt.c| 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/powerplay/inc/smu_types.h
b/drivers/gpu/drm/amd/powerplay/inc/smu_types.h
index ab8c92a60fc4..12a1de55ce3c 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/smu_types.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/smu_types.h
@@ -252,6 +252,7 @@ enum smu_clk_type {
__SMU_DUMMY_MAP(TEMP_DEPENDENT_VMIN), \
__SMU_DUMMY_MAP(MMHUB_PG), \
__SMU_DUMMY_MAP(ATHUB_PG), \
+ __SMU_DUMMY_MAP(APCC_DFLL), \
__SMU_DUMMY_MAP(WAFL_CG),
#undef __SMU_DUMMY_MAP
diff --git a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
index 16634e657589..5a34d01f7f7c 100644
--- a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
+++ b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
@@ -176,6 +176,7 @@ static struct smu_11_0_cmn2aisc_mapping
navi10_feature_mask_map[SMU_FEATURE_COUN
FEA_MAP(TEMP_DEPENDENT_VMIN),
FEA_MAP(MMHUB_PG),
FEA_MAP(ATHUB_PG),
+ FEA_MAP(APCC_DFLL),
};
static struct smu_11_0_cmn2aisc_mapping navi10_table_map[SMU_TABLE_COUNT] = {
--
2.20.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] drm/amdgpu/powerplay: add new mapping for APCC_DFLL feature
Signed-off-by: Xiaojie Yuan
---
drivers/gpu/drm/amd/powerplay/inc/smu_types.h | 1 +
drivers/gpu/drm/amd/powerplay/navi10_ppt.c| 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/powerplay/inc/smu_types.h
b/drivers/gpu/drm/amd/powerplay/inc/smu_types.h
index ab8c92a60fc4..12a1de55ce3c 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/smu_types.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/smu_types.h
@@ -252,6 +252,7 @@ enum smu_clk_type {
__SMU_DUMMY_MAP(TEMP_DEPENDENT_VMIN), \
__SMU_DUMMY_MAP(MMHUB_PG), \
__SMU_DUMMY_MAP(ATHUB_PG), \
+ __SMU_DUMMY_MAP(APCC_DFLL), \
__SMU_DUMMY_MAP(WAFL_CG),
#undef __SMU_DUMMY_MAP
diff --git a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
index 16634e657589..5a34d01f7f7c 100644
--- a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
+++ b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
@@ -176,6 +176,7 @@ static struct smu_11_0_cmn2aisc_mapping
navi10_feature_mask_map[SMU_FEATURE_COUN
FEA_MAP(TEMP_DEPENDENT_VMIN),
FEA_MAP(MMHUB_PG),
FEA_MAP(ATHUB_PG),
+ FEA_MAP(APCC_DFLL),
};
static struct smu_11_0_cmn2aisc_mapping navi10_table_map[SMU_TABLE_COUNT] = {
--
2.20.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm: add drm device name
On 2019-09-17 11:23 a.m., Michel Dänzer wrote: > On 2019-09-17 10:23 a.m., Koenig, Christian wrote: >> Am 17.09.19 um 10:17 schrieb Daniel Vetter: >>> On Tue, Sep 17, 2019 at 10:12 AM Christian König >>> wrote: Am 17.09.19 um 07:47 schrieb Jani Nikula: > On Mon, 16 Sep 2019, Marek Olšák wrote: >> The purpose is to get rid of all PCI ID tables for all drivers in >> userspace. (or at least stop updating them) >> >> Mesa common code and modesetting will use this. > I'd think this would warrant a high level description of what you want > to achieve in the commit message. And maybe explicitly call it uapi_name or even uapi_driver_name. >>> If it's uapi_name, then why do we need a new one for every generation? >>> Userspace drivers tend to span a lot more than just 1 generation. And >>> if you want to have per-generation data from the kernel to userspace, >>> then imo that's much better suited in some amdgpu ioctl, instead of >>> trying to encode that into the driver name. >> >> Well we already have an IOCTL for that, but I thought the intention here >> was to get rid of the PCI-ID tables in userspace to figure out which >> driver to load. > > That's just unrealistic in general, I'm afraid. See e.g. the ongoing > transition from i965 to iris for recent Intel hardware. How is the > kernel supposed to know which driver is to be used? > > > For the Xorg modesetting driver, there's a simple solution, see > https://gitlab.freedesktop.org/xorg/xserver/merge_requests/278 . > Something similar can probably be done in Mesa as well. Another possibility might be for Xorg to use https://www.khronos.org/registry/EGL/extensions/MESA/EGL_MESA_query_driver.txt to determine the driver name. Then only Mesa might need any HW specific code. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm: add drm device name
On 2019-09-17 10:23 a.m., Koenig, Christian wrote: > Am 17.09.19 um 10:17 schrieb Daniel Vetter: >> On Tue, Sep 17, 2019 at 10:12 AM Christian König >> wrote: >>> Am 17.09.19 um 07:47 schrieb Jani Nikula: On Mon, 16 Sep 2019, Marek Olšák wrote: > The purpose is to get rid of all PCI ID tables for all drivers in > userspace. (or at least stop updating them) > > Mesa common code and modesetting will use this. I'd think this would warrant a high level description of what you want to achieve in the commit message. >>> And maybe explicitly call it uapi_name or even uapi_driver_name. >> If it's uapi_name, then why do we need a new one for every generation? >> Userspace drivers tend to span a lot more than just 1 generation. And >> if you want to have per-generation data from the kernel to userspace, >> then imo that's much better suited in some amdgpu ioctl, instead of >> trying to encode that into the driver name. > > Well we already have an IOCTL for that, but I thought the intention here > was to get rid of the PCI-ID tables in userspace to figure out which > driver to load. That's just unrealistic in general, I'm afraid. See e.g. the ongoing transition from i965 to iris for recent Intel hardware. How is the kernel supposed to know which driver is to be used? For the Xorg modesetting driver, there's a simple solution, see https://gitlab.freedesktop.org/xorg/xserver/merge_requests/278 . Something similar can probably be done in Mesa as well. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm: add drm device name
Am 17.09.19 um 10:17 schrieb Daniel Vetter: > On Tue, Sep 17, 2019 at 10:12 AM Christian König > wrote: >> Am 17.09.19 um 07:47 schrieb Jani Nikula: >>> On Mon, 16 Sep 2019, Marek Olšák wrote: The purpose is to get rid of all PCI ID tables for all drivers in userspace. (or at least stop updating them) Mesa common code and modesetting will use this. >>> I'd think this would warrant a high level description of what you want >>> to achieve in the commit message. >> And maybe explicitly call it uapi_name or even uapi_driver_name. > If it's uapi_name, then why do we need a new one for every generation? > Userspace drivers tend to span a lot more than just 1 generation. And > if you want to have per-generation data from the kernel to userspace, > then imo that's much better suited in some amdgpu ioctl, instead of > trying to encode that into the driver name. Well we already have an IOCTL for that, but I thought the intention here was to get rid of the PCI-ID tables in userspace to figure out which driver to load. I mean it could be perfectly valid to not only match the kernel, but also the hardware generation for that. Christian. > -Daniel ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm: add drm device name
On Tue, Sep 17, 2019 at 10:12 AM Christian König wrote: > > Am 17.09.19 um 07:47 schrieb Jani Nikula: > > On Mon, 16 Sep 2019, Marek Olšák wrote: > >> The purpose is to get rid of all PCI ID tables for all drivers in > >> userspace. (or at least stop updating them) > >> > >> Mesa common code and modesetting will use this. > > I'd think this would warrant a high level description of what you want > > to achieve in the commit message. > > And maybe explicitly call it uapi_name or even uapi_driver_name. If it's uapi_name, then why do we need a new one for every generation? Userspace drivers tend to span a lot more than just 1 generation. And if you want to have per-generation data from the kernel to userspace, then imo that's much better suited in some amdgpu ioctl, instead of trying to encode that into the driver name. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: use GPU PAGE SHIFT for umc retired page
Am 17.09.19 um 08:22 schrieb Zhou1, Tao:
umc retired page belongs to vram and it should be aligned to gpu page
size
Signed-off-by: Tao Zhou
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/umc_v6_1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/umc_v6_1.c
b/drivers/gpu/drm/amd/amdgpu/umc_v6_1.c
index 1c0da32c1561..47c4b96b14d1 100644
--- a/drivers/gpu/drm/amd/amdgpu/umc_v6_1.c
+++ b/drivers/gpu/drm/amd/amdgpu/umc_v6_1.c
@@ -213,7 +213,7 @@ static void umc_v6_1_query_error_address(struct
amdgpu_device *adev,
== 1) {
err_rec->address = err_addr;
/* page frame address is saved */
- err_rec->retired_page = retired_page >> PAGE_SHIFT;
+ err_rec->retired_page = retired_page >>
AMDGPU_GPU_PAGE_SHIFT;
err_rec->ts = (uint64_t)ktime_get_real_seconds();
err_rec->err_type =
AMDGPU_RAS_EEPROM_ERR_NON_RECOVERABLE;
err_rec->cu = 0;
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm: add drm device name
Am 17.09.19 um 07:47 schrieb Jani Nikula: On Mon, 16 Sep 2019, Marek Olšák wrote: The purpose is to get rid of all PCI ID tables for all drivers in userspace. (or at least stop updating them) Mesa common code and modesetting will use this. I'd think this would warrant a high level description of what you want to achieve in the commit message. And maybe explicitly call it uapi_name or even uapi_driver_name. Regards, Christian. BR, Jani. ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: cleanup creating BOs at fixed location
Am 16.09.19 um 22:06 schrieb Li, Sun peng (Leo): On 2019-09-13 8:08 a.m., Christian König wrote: [SNIP] - if (amdgpu_ras_reserve_vram(adev, bp << PAGE_SHIFT, - PAGE_SIZE, )) + if (amdgpu_bo_create_kernel_at(adev, bp << PAGE_SIZE, PAGE_SIZE, I'm getting a compile warning from the above line: drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:1408:43: warning: left shift count >= width of type [-Wshift-count-overflow] 1408 | if (amdgpu_bo_create_kernel_at(adev, bp << PAGE_SIZE, PAGE_SIZE, | ^~ Should it be << PAGE_SHIFT? Yeah, Alex already fixed that up yesterday. Sorry that I didn't noticed all those typos earlier, but I don't have hardware to test this. Christian. Thanks, Leo ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu/ras: use GPU PAGE_SIZE/SHIFT for reserving pages
Am 16.09.19 um 21:50 schrieb Alex Deucher:
We are reserving vram pages so they should be aligned to the
GPU page size.
Signed-off-by: Alex Deucher
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index ff1fc084ffe1..131c53fa8eff 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
@@ -1409,7 +1409,8 @@ int amdgpu_ras_reserve_bad_pages(struct amdgpu_device
*adev)
for (i = data->last_reserved; i < data->count; i++) {
bp = data->bps[i].retired_page;
- if (amdgpu_bo_create_kernel_at(adev, bp << PAGE_SHIFT, PAGE_SIZE,
+ if (amdgpu_bo_create_kernel_at(adev, bp <<
AMDGPU_GPU_PAGE_SHIFT,
+ AMDGPU_GPU_PAGE_SIZE,
AMDGPU_GEM_DOMAIN_VRAM,
, NULL))
DRM_ERROR("RAS ERROR: reserve vram %llx fail\n", bp);
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 1/2] drm/amdgpu: initialize bo in ras_reserve_bad_pages
Am 17.09.19 um 08:16 schrieb Zhou1, Tao: the bo pointer is reused for bad pages, initialize it in each loop Signed-off-by: Tao Zhou Reviewed-by: Christian König for the series. --- drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c index 5f623daf5078..090daf595469 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c @@ -1421,6 +1421,7 @@ int amdgpu_ras_reserve_bad_pages(struct amdgpu_device *adev) data->bps_bo[i] = bo; data->last_reserved = i + 1; + bo = NULL; } /* continue to save bad pages to eeprom even reesrve_vram fails */ ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/display: build failed for DCN2.1
Welcome^_^! Mark Brown 于2019年9月17日周二 上午6:36写道： > On Mon, Sep 16, 2019 at 11:12:03PM +0100, Mark Brown wrote: > > On Mon, Sep 16, 2019 at 01:51:15PM -0700, Nick Desaulniers wrote: > > > > > + Mark > > > I think this was a result of the resolved merge conflict. See the > > > -next only commit titled: > > > Merge remote-tracking branch 'drm/drm-next' > > > Yes, the DRM and the Kbuild people really need to coordinate with each > > other here I fear, it's pretty bad that stuff like this has to be done > > in a merge at all :/ The fact that make doesn't detect a missing endif > > is also concerning. > > Applied now, thanks Xinpeng. > ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/display: build failed for DCN2.1
On Mon, Sep 16, 2019 at 2:03 AM Xinpeng Liu wrote: > > drivers/gpu/drm/amd/amdgpu/../display/dc/dml/Makefile:70: *** missing > `endif'. Stop. > make[4]: *** [drivers/gpu/drm/amd/amdgpu] Error 2 > > Signed-off-by: Xinpeng Liu Tested-by: Nick Desaulniers + Mark I think this was a result of the resolved merge conflict. See the -next only commit titled: Merge remote-tracking branch 'drm/drm-next' > --- > drivers/gpu/drm/amd/display/dc/dml/Makefile | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile > b/drivers/gpu/drm/amd/display/dc/dml/Makefile > index a2eb59e..5b2a65b 100644 > --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile > +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile > @@ -44,6 +44,7 @@ CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_mode_vba_20.o := > $(dml_ccflags) > CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_rq_dlg_calc_20.o := $(dml_ccflags) > CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_mode_vba_20v2.o := $(dml_ccflags) > CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_rq_dlg_calc_20v2.o := > $(dml_ccflags) > +endif > ifdef CONFIG_DRM_AMD_DC_DCN2_1 > CFLAGS_$(AMDDALPATH)/dc/dml/dcn21/display_mode_vba_21.o := $(dml_ccflags) > CFLAGS_$(AMDDALPATH)/dc/dml/dcn21/display_rq_dlg_calc_21.o := $(dml_ccflags) > -- > 1.8.3.1 > -- Thanks, ~Nick Desaulniers ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] drm/amdgpu/SRIOV: add navi12 pci id for SRIOV
From: Jiange Zhao
Add Navi12 PCI id support.
Signed-off-by: Jiange Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 420888e941df..b52c7255e5e4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1034,6 +1034,7 @@ static const struct pci_device_id pciidlist[] = {
/* Navi12 */
{0x1002, 0x7360, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI12},
+ {0x1002, 0x7362, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI12},
{0, 0, 0}
};
--
2.20.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
RE: [PATCH] drm/amdgpu: replace DRM_ERROR with DRM_WARN in ras_reserve_bad_pages
Yeah, that's fine.
Reviewed-by: Guchun Chen
-Original Message-
From: Zhou1, Tao
Sent: Tuesday, September 17, 2019 3:01 PM
To: Chen, Guchun ; amd-gfx@lists.freedesktop.org; Zhang,
Hawking
Subject: RE: [PATCH] drm/amdgpu: replace DRM_ERROR with DRM_WARN in
ras_reserve_bad_pages
> -Original Message-
> From: Chen, Guchun
> Sent: 2019年9月17日 14:52
> To: Zhou1, Tao ; amd-gfx@lists.freedesktop.org;
> Zhang, Hawking
> Subject: RE: [PATCH] drm/amdgpu: replace DRM_ERROR with DRM_WARN in
> ras_reserve_bad_pages
>
>
>
> -Original Message-
> From: Zhou1, Tao
> Sent: Tuesday, September 17, 2019 2:25 PM
> To: amd-gfx@lists.freedesktop.org; Chen, Guchun ;
> Zhang, Hawking
> Cc: Zhou1, Tao
> Subject: [PATCH] drm/amdgpu: replace DRM_ERROR with DRM_WARN in
> ras_reserve_bad_pages
>
> There are two cases of reserve error should be ignored:
> 1) a ras bad page has been allocated (used by someone);
> 2) a ras bad page has been reserved (duplicate error injection for one
> page);
>
> DRM_ERROR is unnecessary for the failure of bad page reserve
>
> Signed-off-by: Tao Zhou
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> index 79e5e5be8b34..5f623daf5078 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> @@ -1409,10 +1409,15 @@ int amdgpu_ras_reserve_bad_pages(struct
> amdgpu_device *adev)
> for (i = data->last_reserved; i < data->count; i++) {
> bp = data->bps[i].retired_page;
>
> + /* There are two cases of reserve error should be ignored:
> + * 1) a ras bad page has been allocated (used by someone);
> + * 2) a ras bad page has been reserved (duplicate error
> injection
> + *for one page);
> + */
> if (amdgpu_bo_create_kernel_at(adev, bp << PAGE_SHIFT,
> PAGE_SIZE,
> AMDGPU_GEM_DOMAIN_VRAM,
> , NULL))
> [Guchun]Do we need to change PAGE_SHIFT to AMDGPU_GPU_PAGE_SHIFT here?
[Tao] Alex has another patch to fix it, you can find it in mail list.
>
> - DRM_ERROR("RAS ERROR: reserve vram %llx fail\n",
> bp);
> + DRM_WARN("RAS WARN: reserve vram for retired
> page %llx fail\n", bp);
>
> data->bps_bo[i] = bo;
> data->last_reserved = i + 1;
> --
> 2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
RE: [PATCH] drm/amdgpu: replace DRM_ERROR with DRM_WARN in ras_reserve_bad_pages
> -Original Message-
> From: Chen, Guchun
> Sent: 2019年9月17日 14:52
> To: Zhou1, Tao ; amd-gfx@lists.freedesktop.org;
> Zhang, Hawking
> Subject: RE: [PATCH] drm/amdgpu: replace DRM_ERROR with DRM_WARN in
> ras_reserve_bad_pages
>
>
>
> -Original Message-
> From: Zhou1, Tao
> Sent: Tuesday, September 17, 2019 2:25 PM
> To: amd-gfx@lists.freedesktop.org; Chen, Guchun
> ; Zhang, Hawking
> Cc: Zhou1, Tao
> Subject: [PATCH] drm/amdgpu: replace DRM_ERROR with DRM_WARN in
> ras_reserve_bad_pages
>
> There are two cases of reserve error should be ignored:
> 1) a ras bad page has been allocated (used by someone);
> 2) a ras bad page has been reserved (duplicate error injection for one page);
>
> DRM_ERROR is unnecessary for the failure of bad page reserve
>
> Signed-off-by: Tao Zhou
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> index 79e5e5be8b34..5f623daf5078 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> @@ -1409,10 +1409,15 @@ int amdgpu_ras_reserve_bad_pages(struct
> amdgpu_device *adev)
> for (i = data->last_reserved; i < data->count; i++) {
> bp = data->bps[i].retired_page;
>
> + /* There are two cases of reserve error should be ignored:
> + * 1) a ras bad page has been allocated (used by someone);
> + * 2) a ras bad page has been reserved (duplicate error
> injection
> + *for one page);
> + */
> if (amdgpu_bo_create_kernel_at(adev, bp << PAGE_SHIFT,
> PAGE_SIZE,
> AMDGPU_GEM_DOMAIN_VRAM,
> , NULL))
> [Guchun]Do we need to change PAGE_SHIFT to AMDGPU_GPU_PAGE_SHIFT
> here?
[Tao] Alex has another patch to fix it, you can find it in mail list.
>
> - DRM_ERROR("RAS ERROR: reserve vram %llx fail\n",
> bp);
> + DRM_WARN("RAS WARN: reserve vram for retired
> page %llx fail\n", bp);
>
> data->bps_bo[i] = bo;
> data->last_reserved = i + 1;
> --
> 2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
RE: [PATCH] drm/amdgpu: use GPU PAGE SHIFT for umc retired page
Reviewed-by: Guchun Chen
Regards,
Guchun
-Original Message-
From: Zhou1, Tao
Sent: Tuesday, September 17, 2019 2:22 PM
To: amd-gfx@lists.freedesktop.org; Chen, Guchun ; Zhang,
Hawking ; Deucher, Alexander
Cc: Zhou1, Tao
Subject: [PATCH] drm/amdgpu: use GPU PAGE SHIFT for umc retired page
umc retired page belongs to vram and it should be aligned to gpu page size
Signed-off-by: Tao Zhou
---
drivers/gpu/drm/amd/amdgpu/umc_v6_1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/umc_v6_1.c
b/drivers/gpu/drm/amd/amdgpu/umc_v6_1.c
index 1c0da32c1561..47c4b96b14d1 100644
--- a/drivers/gpu/drm/amd/amdgpu/umc_v6_1.c
+++ b/drivers/gpu/drm/amd/amdgpu/umc_v6_1.c
@@ -213,7 +213,7 @@ static void umc_v6_1_query_error_address(struct
amdgpu_device *adev,
== 1) {
err_rec->address = err_addr;
/* page frame address is saved */
- err_rec->retired_page = retired_page >> PAGE_SHIFT;
+ err_rec->retired_page = retired_page >>
AMDGPU_GPU_PAGE_SHIFT;
err_rec->ts = (uint64_t)ktime_get_real_seconds();
err_rec->err_type =
AMDGPU_RAS_EEPROM_ERR_NON_RECOVERABLE;
err_rec->cu = 0;
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
RE: [PATCH] drm/amdgpu: replace DRM_ERROR with DRM_WARN in ras_reserve_bad_pages
-Original Message-
From: Zhou1, Tao
Sent: Tuesday, September 17, 2019 2:25 PM
To: amd-gfx@lists.freedesktop.org; Chen, Guchun ; Zhang,
Hawking
Cc: Zhou1, Tao
Subject: [PATCH] drm/amdgpu: replace DRM_ERROR with DRM_WARN in
ras_reserve_bad_pages
There are two cases of reserve error should be ignored:
1) a ras bad page has been allocated (used by someone);
2) a ras bad page has been reserved (duplicate error injection for one page);
DRM_ERROR is unnecessary for the failure of bad page reserve
Signed-off-by: Tao Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index 79e5e5be8b34..5f623daf5078 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
@@ -1409,10 +1409,15 @@ int amdgpu_ras_reserve_bad_pages(struct amdgpu_device
*adev)
for (i = data->last_reserved; i < data->count; i++) {
bp = data->bps[i].retired_page;
+ /* There are two cases of reserve error should be ignored:
+* 1) a ras bad page has been allocated (used by someone);
+* 2) a ras bad page has been reserved (duplicate error
injection
+*for one page);
+*/
if (amdgpu_bo_create_kernel_at(adev, bp << PAGE_SHIFT,
PAGE_SIZE,
AMDGPU_GEM_DOMAIN_VRAM,
, NULL))
[Guchun]Do we need to change PAGE_SHIFT to AMDGPU_GPU_PAGE_SHIFT here?
- DRM_ERROR("RAS ERROR: reserve vram %llx fail\n", bp);
+ DRM_WARN("RAS WARN: reserve vram for retired page %llx
fail\n", bp);
data->bps_bo[i] = bo;
data->last_reserved = i + 1;
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
RE: [PATCH 2/2] drm/amdgpu: fix size calc error in bo_create_kernel_at
Series is: Reviewed-by: Guchun Chen Regards, Guchun -Original Message- From: Zhou1, Tao Sent: Tuesday, September 17, 2019 2:17 PM To: amd-gfx@lists.freedesktop.org; Chen, Guchun ; Koenig, Christian ; Zhang, Hawking Cc: Zhou1, Tao Subject: [PATCH 2/2] drm/amdgpu: fix size calc error in bo_create_kernel_at replace offset with size Signed-off-by: Tao Zhou --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c index ecad84e1b4e2..2fcd2d14cbf0 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c @@ -366,7 +366,7 @@ int amdgpu_bo_create_kernel_at(struct amdgpu_device *adev, int r; offset &= PAGE_MASK; - size = ALIGN(offset, PAGE_SIZE); + size = ALIGN(size, PAGE_SIZE); r = amdgpu_bo_create_reserved(adev, size, PAGE_SIZE, domain, bo_ptr, NULL, NULL); -- 2.17.1 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 2/2] SWDEV-191392 [Vega10]Vega10 BKM0.83 AVFS parameters patch for Linux Driver
From: zhexzhan
Issue: DROOP coef read by HDT appear to be mismatch with requirement of BKM0.83
Root cause: These values are supposed to be overwritten by PPLIB.
However, driver missed code of this part.
Solution: Add overwriting process when reading pptable from vBIOS
Hardcode specific coef with correct values:
GbVdroopTableCksoffA0 = 0xFFFCD2E7
GbVdroopTableCksoffA1 = 0x24902
GbVdroopTableCksoffA2 = 0x249BA
Signed-off-by: zhexzhan
---
drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.c
index 615cf2c0..b827c2c 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.c
@@ -293,6 +293,13 @@ int pp_atomfwctrl_get_avfs_information(struct pp_hwmgr
*hwmgr,
format_revision = ((struct atom_common_table_header
*)profile)->format_revision;
content_revision = ((struct atom_common_table_header
*)profile)->content_revision;
+ if (format_revision == 4)
+ {
+ profile->gb_vdroop_table_cksoff_a0 = 0xfffcd2e7;
+ profile->gb_vdroop_table_cksoff_a1 = 0x24902;
+ profile->gb_vdroop_table_cksoff_a2 = 0x249ba;
+ }
+
if (format_revision == 4 && content_revision == 1) {
param->ulMaxVddc = le32_to_cpu(profile->maxvddc);
param->ulMinVddc = le32_to_cpu(profile->minvddc);
--
2.7.4
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 1/2] SWDEV-195825 drm/amd/amdgpu:[Gibraltar][V320] tdr-1 test failed after 2 rounds
Issue: quark didn't trigger TDR correctly on compute ring Root cause: Default timeout value for compute ring is infinite Solution: In SR-IOV and passthrough mode, if compute ring timeout is set, then use user set value; if not set, then use same value as gfx ring timeout. Signed-off-by: Jesse Zhang --- drivers/gpu/drm/amd/amdgpu/soc15.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/soc15.c b/drivers/gpu/drm/amd/amdgpu/soc15.c index 7c7e9f5..4155cc1 100644 --- a/drivers/gpu/drm/amd/amdgpu/soc15.c +++ b/drivers/gpu/drm/amd/amdgpu/soc15.c @@ -687,6 +687,16 @@ int soc15_set_ip_blocks(struct amdgpu_device *adev) adev->rev_id = soc15_get_rev_id(adev); adev->nbio.funcs->detect_hw_virt(adev); + /* +* If running under SR-IOV or passthrough mode and user did not set +* custom value for compute ring timeout, set timeout to be the same +* as gfx ring timeout to avoid compute ring cannot detect an true +* hang. +*/ + if ((amdgpu_sriov_vf(adev) || amdgpu_passthrough(adev)) && + adev->compute_timeout == MAX_SCHEDULE_TIMEOUT) + adev->compute_timeout = adev->gfx_timeout; + if (amdgpu_sriov_vf(adev)) adev->virt.ops = _ai_virt_ops; -- 2.7.4 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] drm/amdgpu: replace DRM_ERROR with DRM_WARN in ras_reserve_bad_pages
There are two cases of reserve error should be ignored:
1) a ras bad page has been allocated (used by someone);
2) a ras bad page has been reserved (duplicate error injection for one page);
DRM_ERROR is unnecessary for the failure of bad page reserve
Signed-off-by: Tao Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index 79e5e5be8b34..5f623daf5078 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
@@ -1409,10 +1409,15 @@ int amdgpu_ras_reserve_bad_pages(struct amdgpu_device
*adev)
for (i = data->last_reserved; i < data->count; i++) {
bp = data->bps[i].retired_page;
+ /* There are two cases of reserve error should be ignored:
+* 1) a ras bad page has been allocated (used by someone);
+* 2) a ras bad page has been reserved (duplicate error
injection
+*for one page);
+*/
if (amdgpu_bo_create_kernel_at(adev, bp << PAGE_SHIFT,
PAGE_SIZE,
AMDGPU_GEM_DOMAIN_VRAM,
, NULL))
- DRM_ERROR("RAS ERROR: reserve vram %llx fail\n", bp);
+ DRM_WARN("RAS WARN: reserve vram for retired page %llx
fail\n", bp);
data->bps_bo[i] = bo;
data->last_reserved = i + 1;
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] drm/amdgpu: use GPU PAGE SHIFT for umc retired page
umc retired page belongs to vram and it should be aligned to gpu page
size
Signed-off-by: Tao Zhou
---
drivers/gpu/drm/amd/amdgpu/umc_v6_1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/umc_v6_1.c
b/drivers/gpu/drm/amd/amdgpu/umc_v6_1.c
index 1c0da32c1561..47c4b96b14d1 100644
--- a/drivers/gpu/drm/amd/amdgpu/umc_v6_1.c
+++ b/drivers/gpu/drm/amd/amdgpu/umc_v6_1.c
@@ -213,7 +213,7 @@ static void umc_v6_1_query_error_address(struct
amdgpu_device *adev,
== 1) {
err_rec->address = err_addr;
/* page frame address is saved */
- err_rec->retired_page = retired_page >> PAGE_SHIFT;
+ err_rec->retired_page = retired_page >>
AMDGPU_GPU_PAGE_SHIFT;
err_rec->ts = (uint64_t)ktime_get_real_seconds();
err_rec->err_type =
AMDGPU_RAS_EEPROM_ERR_NON_RECOVERABLE;
err_rec->cu = 0;
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 1/2] drm/amdgpu: initialize bo in ras_reserve_bad_pages
the bo pointer is reused for bad pages, initialize it in each loop Signed-off-by: Tao Zhou --- drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c index 5f623daf5078..090daf595469 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c @@ -1421,6 +1421,7 @@ int amdgpu_ras_reserve_bad_pages(struct amdgpu_device *adev) data->bps_bo[i] = bo; data->last_reserved = i + 1; + bo = NULL; } /* continue to save bad pages to eeprom even reesrve_vram fails */ -- 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: fix size calc error in bo_create_kernel_at
replace offset with size Signed-off-by: Tao Zhou --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c index ecad84e1b4e2..2fcd2d14cbf0 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c @@ -366,7 +366,7 @@ int amdgpu_bo_create_kernel_at(struct amdgpu_device *adev, int r; offset &= PAGE_MASK; - size = ALIGN(offset, PAGE_SIZE); + size = ALIGN(size, PAGE_SIZE); r = amdgpu_bo_create_reserved(adev, size, PAGE_SIZE, domain, bo_ptr, NULL, NULL); -- 2.17.1 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
