RE: [PATCH] drm/amdkfd: make sure VM is ready for updating operations
[Public]
> I never saw this problem in my testing, probably because I never got my page
> tables evicted?
I observed this problem on APUs with default 512MB VRAM when allocating memory
aggressively from different APPs.
Will try to modify the patch per your suggestions. Thanks!
Regards,
Lang
From: Kuehling, Felix
Sent: Wednesday, April 10, 2024 8:32 AM
To: Koenig, Christian ; Yu, Lang ;
amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdkfd: make sure VM is ready for updating operations
On 2024-04-08 3:55, Christian König wrote:
Am 07.04.24 um 06:52 schrieb Lang Yu:
When VM is in evicting state, amdgpu_vm_update_range would return -EBUSY.
Then restore_process_worker runs into a dead loop.
Fixes: 2fdba514ad5a ("drm/amdgpu: Auto-validate DMABuf imports in compute VMs")
Mhm, while it would be good to have this case handled as error it should never
occur in practice since we should have validated the VM before validating the
DMA-bufs.
@Felix isn't that something we have taken care of?
The problem I saw when I implemented Auto-validate was, that migration of a BO
invalidates its DMABuf attachments. So I need to validate the DMABuf
attachments after validating the BOs they attach to. This auto-validation
happens in amdgpu_vm_validate. So I needed to do the VM validation after the BO
validation. The problem now seems to be that the BO validation happens in the
same loop as the page table update. And the page table update fails if the VM
is not valid.
I never saw this problem in my testing, probably because I never got my page
tables evicted?
Anyway, I think the solution is to split the BO validation and page table
update into two separate loops in amdgpu_amdkfd_restore_process_pos:
1. Validate BOs
2. Validate VM (and DMABuf attachments)
3. Update page tables for the BOs validated above
Regards,
Felix
Regards,
Christian.
Signed-off-by: Lang Yu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 0ae9fd844623..8c71fe07807a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -2900,6 +2900,12 @@ int amdgpu_amdkfd_gpuvm_restore_process_bos(void *info,
struct dma_fence __rcu *
amdgpu_sync_create(_obj);
+ret = process_validate_vms(process_info, NULL);
+if (ret) {
+pr_debug("Validating VMs failed, ret: %d\n", ret);
+goto validate_map_fail;
+}
+
/* Validate BOs and map them to GPUVM (update VM page tables). */
list_for_each_entry(mem, _info->kfd_bo_list,
validate_list) {
Re: [PATCH] drm/amdkfd: make sure VM is ready for updating operations
On 2024-04-08 3:55, Christian König wrote:
Am 07.04.24 um 06:52 schrieb Lang Yu:
When VM is in evicting state, amdgpu_vm_update_range would return
-EBUSY.
Then restore_process_worker runs into a dead loop.
Fixes: 2fdba514ad5a ("drm/amdgpu: Auto-validate DMABuf imports in
compute VMs")
Mhm, while it would be good to have this case handled as error it
should never occur in practice since we should have validated the VM
before validating the DMA-bufs.
@Felix isn't that something we have taken care of?
The problem I saw when I implemented Auto-validate was, that migration
of a BO invalidates its DMABuf attachments. So I need to validate the
DMABuf attachments after validating the BOs they attach to. This
auto-validation happens in amdgpu_vm_validate. So I needed to do the VM
validation after the BO validation. The problem now seems to be that the
BO validation happens in the same loop as the page table update. And the
page table update fails if the VM is not valid.
I never saw this problem in my testing, probably because I never got my
page tables evicted?
Anyway, I think the solution is to split the BO validation and page
table update into two separate loops in amdgpu_amdkfd_restore_process_pos:
1. Validate BOs
2. Validate VM (and DMABuf attachments)
3. Update page tables for the BOs validated above
Regards,
Felix
Regards,
Christian.
Signed-off-by: Lang Yu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 0ae9fd844623..8c71fe07807a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -2900,6 +2900,12 @@ int
amdgpu_amdkfd_gpuvm_restore_process_bos(void *info, struct dma_fence
__rcu *
amdgpu_sync_create(_obj);
+ ret = process_validate_vms(process_info, NULL);
+ if (ret) {
+ pr_debug("Validating VMs failed, ret: %d\n", ret);
+ goto validate_map_fail;
+ }
+
/* Validate BOs and map them to GPUVM (update VM page tables). */
list_for_each_entry(mem, _info->kfd_bo_list,
validate_list) {
Re: [PATCH] drm/amd/amdgpu: Update PF2VF Header
[AMD Official Use Only - General]
Acked-by: Alex Deucher
From: amd-gfx on behalf of Luqmaan
Irshad
Sent: Tuesday, April 2, 2024 6:01 PM
To: amd-gfx@lists.freedesktop.org
Cc: Irshad, Luqmaan
Subject: [PATCH] drm/amd/amdgpu: Update PF2VF Header
Adding a new field for GPU Capacity to align the header with the host.
Signed-off-by: Luqmaan Irshad
---
drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h
b/drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h
index 0de78d6a83fe..fb2b394bb9c5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h
@@ -158,7 +158,7 @@ struct amd_sriov_msg_pf2vf_info_header {
uint32_t reserved[2];
};
-#define AMD_SRIOV_MSG_PF2VF_INFO_FILLED_SIZE (48)
+#define AMD_SRIOV_MSG_PF2VF_INFO_FILLED_SIZE (49)
struct amd_sriov_msg_pf2vf_info {
/* header contains size and version */
struct amd_sriov_msg_pf2vf_info_header header;
@@ -209,6 +209,8 @@ struct amd_sriov_msg_pf2vf_info {
struct amd_sriov_msg_uuid_info uuid_info;
/* PCIE atomic ops support flag */
uint32_t pcie_atomic_ops_support_flags;
+ /* Portion of GPU memory occupied by VF. MAX value is 65535, but set
to uint32_t to maintain alignment with reserved size */
+ uint32_t gpu_capacity;
/* reserved */
uint32_t reserved[256 - AMD_SRIOV_MSG_PF2VF_INFO_FILLED_SIZE];
};
--
2.44.0
[linux-next:master] BUILD REGRESSION a053fd3ca5d1b927a8655f239c84b0d790218fda
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: a053fd3ca5d1b927a8655f239c84b0d790218fda Add linux-next specific files for 20240409 Error/Warning reports: https://lore.kernel.org/oe-kbuild-all/202404091516.9h8idamm-...@intel.com https://lore.kernel.org/oe-kbuild-all/202404091749.scnpj8j4-...@intel.com https://lore.kernel.org/oe-kbuild-all/202404091959.he2hjvyl-...@intel.com Error/Warning: (recently discovered and may have been fixed) WARNING: modpost: vmlinux: section mismatch in reference: (unknown)+0x14d0 (section: __ex_table) -> .LASF112 (section: .debug_str) WARNING: modpost: vmlinux: section mismatch in reference: (unknown)+0x14d4 (section: __ex_table) -> .LASF114 (section: .debug_str) WARNING: modpost: vmlinux: section mismatch in reference: (unknown)+0x14dc (section: __ex_table) -> .LASF116 (section: .debug_str) WARNING: modpost: vmlinux: section mismatch in reference: (unknown)+0x14e0 (section: __ex_table) -> .LASF118 (section: .debug_str) WARNING: modpost: vmlinux: section mismatch in reference: ___se_sys_chroot+0xd0 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: ___se_sys_inotify_add_watch+0x12a (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: ___se_sys_landlock_add_rule+0x1b0 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: ___se_sys_open_by_handle_at+0x1ea (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: __dev_queue_xmit+0x1d4 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: __do_sys_fsmount+0xf2 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: __do_sys_pivot_root+0x28a (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: __hw_addr_del_entry+0x44 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: __hw_addr_flush+0x48 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: __u64_stats_update_begin+0x16 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: ahci_platform_get_resources+0x84 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: altera_msi_probe+0x80 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: armada8k_pcie_probe+0x144 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: atmel_sha_probe+0x36a (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: btrfs_init_new_device+0x14e (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: cqhci_pltfm_init+0x1a (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: default_device_exit_net+0x128 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: do_coredump+0x454 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: do_utimes+0xea (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: dpm_suspend+0xa2 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: dpm_suspend_late+0x86 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: dpm_suspend_noirq+0xa2 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: edma_probe+0xf2 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: free_filters_list+0x3c (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: img_hash_probe+0x3a0 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: ipv6_icmp_error+0x20 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: kernel_read_file_from_path_initns+0xe6 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: kmb_ocs_aes_probe+0x1c2 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: kmb_ocs_ecc_probe+0x172 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: ks_pcie_pro
RE: [PATCH] drm/amdgpu: Fix incorrect return value
[AMD Official Use Only - General]
OK
-
Best Regards,
Thomas
-Original Message-
From: Zhou1, Tao
Sent: Tuesday, April 9, 2024 10:52 AM
To: Chai, Thomas ; amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Li, Candice ;
Wang, Yang(Kevin) ; Yang, Stanley
Subject: RE: [PATCH] drm/amdgpu: Fix incorrect return value
[AMD Official Use Only - General]
> -Original Message-
> From: Chai, Thomas
> Sent: Wednesday, April 3, 2024 3:07 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Chai, Thomas ; Zhang, Hawking
> ; Zhou1, Tao ; Li, Candice
> ; Wang, Yang(Kevin) ;
> Yang, Stanley ; Chai, Thomas
>
> Subject: [PATCH] drm/amdgpu: Fix incorrect return value
>
> [Why]
> After calling amdgpu_vram_mgr_reserve_range multiple times with the
> same address, calling amdgpu_vram_mgr_query_page_status will always
> return - EBUSY.
> From the second call to amdgpu_vram_mgr_reserve_range, the same
> address will be added to the reservations_pending list again and is
> never moved to the reserved_pages list because the address had been reserved.
>
> [How]
> First add the address status check before calling
> amdgpu_vram_mgr_do_reserve, if the address is already reserved, do
> nothing; If the address is already in the reservations_pending list,
> directly reserve memory; only add new nodes for the addresses that are
> not in the reserved_pages list and reservations_pending list.
>
> Signed-off-by: YiPeng Chai
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 28
> +---
> 1 file changed, 19 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> index 1e36c428d254..0bf3f4092900 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> @@ -317,7 +317,6 @@ static void amdgpu_vram_mgr_do_reserve(struct
> ttm_resource_manager *man)
>
> dev_dbg(adev->dev, "Reservation 0x%llx - %lld, Succeeded\n",
> rsv->start, rsv->size);
> -
> vis_usage = amdgpu_vram_mgr_vis_size(adev, block);
> atomic64_add(vis_usage, >vis_usage);
> spin_lock(>bdev->lru_lock); @@ -340,19 +339,30 @@
> int amdgpu_vram_mgr_reserve_range(struct
> amdgpu_vram_mgr *mgr,
> uint64_t start, uint64_t size) {
> struct amdgpu_vram_reservation *rsv;
> + int ret = 0;
>
> - rsv = kzalloc(sizeof(*rsv), GFP_KERNEL);
> - if (!rsv)
> - return -ENOMEM;
> + ret = amdgpu_vram_mgr_query_page_status(mgr, start);
> + if (!ret)
> + return 0;
> +
> + if (ret == -ENOENT) {
> + rsv = kzalloc(sizeof(*rsv), GFP_KERNEL);
> + if (!rsv)
> + return -ENOMEM;
>
> - INIT_LIST_HEAD(>allocated);
> - INIT_LIST_HEAD(>blocks);
> + INIT_LIST_HEAD(>allocated);
> + INIT_LIST_HEAD(>blocks);
>
> - rsv->start = start;
> - rsv->size = size;
> + rsv->start = start;
> + rsv->size = size;
> +
> + mutex_lock(>lock);
> + list_add_tail(>blocks, >reservations_pending);
> + mutex_unlock(>lock);
[Tao] we can drop the mutex_unlock and add if (ret != -ENOENT) for the second
mutex_lock to avoid unlocking/locking repeatedly.
> +
> + }
>
> mutex_lock(>lock);
> - list_add_tail(>blocks, >reservations_pending);
> amdgpu_vram_mgr_do_reserve(>manager);
> mutex_unlock(>lock);
>
> --
> 2.34.1
Re: 6.5.5: UBSAN: radeon_atombios.c: index 1 is out of range for type 'UCHAR [1]'
On 10/1/23 17:12, Justin Piszcz wrote: [Sun Oct 1 15:59:04 2023] UBSAN: array-index-out-of-bounds in drivers/gpu/drm/radeon/radeon_atombios.c:2620:43 [Sun Oct 1 15:59:04 2023] index 1 is out of range for type 'UCHAR [1]' [Sun Oct 1 15:59:04 2023] CPU: 5 PID: 1 Comm: swapper/0 Tainted: G T 6.5.5 #13 55df8de52754ef95effc50a55e9206abdea304ac [Sun Oct 1 15:59:04 2023] Hardware name: Supermicro X9SRL-F/X9SRL-F, BIOS 3.3 11/13/2018 [Sun Oct 1 15:59:04 2023] Call Trace: [Sun Oct 1 15:59:04 2023] [Sun Oct 1 15:59:04 2023] dump_stack_lvl+0x36/0x50 [Sun Oct 1 15:59:04 2023] __ubsan_handle_out_of_bounds+0xc7/0x110 [Sun Oct 1 15:59:04 2023] radeon_atombios_get_power_modes+0x87a/0x8f0 [Sun Oct 1 15:59:04 2023] radeon_pm_init+0x13a/0x7e0 [Sun Oct 1 15:59:04 2023] evergreen_init+0x13d/0x3d0 [Sun Oct 1 15:59:04 2023] radeon_device_init+0x60a/0xbf0 [Sun Oct 1 15:59:04 2023] radeon_driver_load_kms+0xb1/0x250 [Sun Oct 1 15:59:04 2023] drm_dev_register+0xfc/0x250 [Sun Oct 1 15:59:04 2023] radeon_pci_probe+0xd0/0x150 [Sun Oct 1 15:59:04 2023] pci_device_probe+0x97/0x130 [Sun Oct 1 15:59:04 2023] really_probe+0xbe/0x2f0 [Sun Oct 1 15:59:04 2023] ? __pfx___driver_attach+0x10/0x10 [Sun Oct 1 15:59:04 2023] __driver_probe_device+0x6e/0x120 [Sun Oct 1 15:59:04 2023] driver_probe_device+0x1a/0x90 [Sun Oct 1 15:59:04 2023] __driver_attach+0xd4/0x170 [Sun Oct 1 15:59:04 2023] bus_for_each_dev+0x87/0xe0 [Sun Oct 1 15:59:04 2023] bus_add_driver+0xf3/0x1f0 [Sun Oct 1 15:59:04 2023] driver_register+0x58/0x120 [Sun Oct 1 15:59:04 2023] ? __pfx_radeon_module_init+0x10/0x10 [Sun Oct 1 15:59:04 2023] do_one_initcall+0x93/0x4a0 [Sun Oct 1 15:59:04 2023] kernel_init_freeable+0x301/0x580 [Sun Oct 1 15:59:04 2023] ? __pfx_kernel_init+0x10/0x10 [Sun Oct 1 15:59:04 2023] kernel_init+0x15/0x1b0 [Sun Oct 1 15:59:04 2023] ret_from_fork+0x2f/0x50 [Sun Oct 1 15:59:04 2023] ? __pfx_kernel_init+0x10/0x10 [Sun Oct 1 15:59:04 2023] ret_from_fork_asm+0x1b/0x30 [Sun Oct 1 15:59:04 2023] [Sun Oct 1 15:59:04 2023] [Sun Oct 1 15:59:04 2023] [drm] radeon: dpm initialized [Sun Oct 1 15:59:04 2023] [drm] GART: num cpu pages 262144, num gpu pages 262144 [Sun Oct 1 15:59:04 2023] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 [Sun Oct 1 15:59:04 2023] [drm] PCIE GART of 1024M enabled (table at 0x0014C000). [Sun Oct 1 15:59:04 2023] radeon :03:00.0: WB enabled [Sun Oct 1 15:59:04 2023] radeon :03:00.0: fence driver on ring 0 use gpu addr 0x4c00 [Sun Oct 1 15:59:04 2023] radeon :03:00.0: fence driver on ring 3 use gpu addr 0x4c0c [Sun Oct 1 15:59:04 2023] radeon :03:00.0: fence driver on ring 5 use gpu addr 0x0005c418 [Sun Oct 1 15:59:04 2023] radeon :03:00.0: radeon: MSI limited to 32-bit [Sun Oct 1 15:59:04 2023] radeon :03:00.0: radeon: using MSI. [Sun Oct 1 15:59:04 2023] [drm] radeon: irq initialized. Please also open an issue on freedesktop tracker [1]. Thanks. [1]: https://gitlab.freedesktop.org/drm/amd/-/issues Issue opened: https://gitlab.freedesktop.org/drm/amd/-/issues/2894 Regards, Justin +Kees since I've worked with him on several of these flexible array issues. I just happened to look at kernel logs today for my ath1*k driver maintenance and see the subject issue is present on my device, running 6.9.0-rc1. The freedesktop issue tracker says the issue is closed, but any fix has not landed in the upstream kernel. Is there a -next patch somewhere? [ 12.105270] UBSAN: array-index-out-of-bounds in drivers/gpu/drm/radeon/radeon_atombios.c:2718:34 [ 12.105272] index 48 is out of range for type 'UCHAR [1]' [ If there isn't really an upstream fix, I can probably supply one. /jeff
[PATCH 5.15 579/690] drm/amdgpu: Use drm_mode_copy()
5.15-stable review patch. If anyone has any objections, please let me know.
--
From: Ville Syrjälä
[ Upstream commit 426c89aa203bcec9d9cf6eea36735eafa1b1f099 ]
struct drm_display_mode embeds a list head, so overwriting
the full struct with another one will corrupt the list
(if the destination mode is on a list). Use drm_mode_copy()
instead which explicitly preserves the list head of
the destination mode.
Even if we know the destination mode is not on any list
using drm_mode_copy() seems decent as it sets a good
example. Bad examples of not using it might eventually
get copied into code where preserving the list head
actually matters.
Obviously one case not covered here is when the mode
itself is embedded in a larger structure and the whole
structure is copied. But if we are careful when copying
into modes embedded in structures I think we can be a
little more reassured that bogus list heads haven't been
propagated in.
@is_mode_copy@
@@
drm_mode_copy(...)
{
...
}
@depends on !is_mode_copy@
struct drm_display_mode *mode;
expression E, S;
@@
(
- *mode = E
+ drm_mode_copy(mode, )
|
- memcpy(mode, E, S)
+ drm_mode_copy(mode, E)
)
@depends on !is_mode_copy@
struct drm_display_mode mode;
expression E;
@@
(
- mode = E
+ drm_mode_copy(, )
|
- memcpy(, E, S)
+ drm_mode_copy(, E)
)
@@
struct drm_display_mode *mode;
@@
- &*mode
+ mode
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Leo Li
Cc: Rodrigo Siqueira
Cc: amd-gfx@lists.freedesktop.org
Reviewed-by: Harry Wentland
Signed-off-by: Ville Syrjälä
Signed-off-by: Alex Deucher
Stable-dep-of: 79f3e38f60e5 ("drm/amd/display: Preserve original aspect ratio
in create stream")
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c| 4 ++--
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index c777aff164b76..654f99f4107ea 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -625,7 +625,7 @@ amdgpu_connector_fixup_lcd_native_mode(struct drm_encoder
*encoder,
if (mode->type & DRM_MODE_TYPE_PREFERRED) {
if (mode->hdisplay != native_mode->hdisplay ||
mode->vdisplay != native_mode->vdisplay)
- memcpy(native_mode, mode, sizeof(*mode));
+ drm_mode_copy(native_mode, mode);
}
}
@@ -634,7 +634,7 @@ amdgpu_connector_fixup_lcd_native_mode(struct drm_encoder
*encoder,
list_for_each_entry_safe(mode, t, >probed_modes,
head) {
if (mode->hdisplay == native_mode->hdisplay &&
mode->vdisplay == native_mode->vdisplay) {
- *native_mode = *mode;
+ drm_mode_copy(native_mode, mode);
drm_mode_set_crtcinfo(native_mode,
CRTC_INTERLACE_HALVE_V);
DRM_DEBUG_KMS("Determined LVDS native mode
details from EDID\n");
break;
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 7385efe699f88..9356decd14513 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6219,7 +6219,7 @@ get_highest_refresh_rate_mode(struct amdgpu_dm_connector
*aconnector,
}
}
- aconnector->freesync_vid_base = *m_pref;
+ drm_mode_copy(>freesync_vid_base, m_pref);
return m_pref;
}
@@ -6333,8 +6333,8 @@ create_stream_for_sink(struct amdgpu_dm_connector
*aconnector,
is_freesync_video_mode(, aconnector);
if (recalculate_timing) {
freesync_mode =
get_highest_refresh_rate_mode(aconnector, false);
- saved_mode = mode;
- mode = *freesync_mode;
+ drm_mode_copy(_mode, );
+ drm_mode_copy(, freesync_mode);
} else {
decide_crtc_timing_for_drm_display_mode(
, preferred_mode, scale);
--
2.43.0
[PATCH] drm/amdgpu: remove "num_pages" local variable in amdgpu_gtt_mgr_new
amdgpu_gtt_mgr_new and ttm_range_man_alloc share similar logic, but
"num_pages" in amdgpu_gtt_mgr_new is defined as local variable which
is calculate directly in ttm_range_man_alloc.
Signed-off-by: brolerliew
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index 44367f03316f..0c56e4057d85 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -116,7 +116,6 @@ static int amdgpu_gtt_mgr_new(struct
ttm_resource_manager *man,
struct ttm_resource **res)
{
struct amdgpu_gtt_mgr *mgr = to_gtt_mgr(man);
- uint32_t num_pages = PFN_UP(tbo->base.size);
struct ttm_range_mgr_node *node;
int r;
@@ -134,7 +133,7 @@ static int amdgpu_gtt_mgr_new(struct
ttm_resource_manager *man,
if (place->lpfn) {
spin_lock(>lock);
r = drm_mm_insert_node_in_range(>mm, >mm_nodes[0],
- num_pages, tbo->page_alignment,
+
PFN_UP(node->base.size), tbo->page_alignment,
0, place->fpfn, place->lpfn,
DRM_MM_INSERT_BEST);
spin_unlock(>lock);
--
2.40.1
Re: [PATCH] drm/amdgpu: remove "num_pages" local variable in amdgpu_gtt_mgr_new
sorry, this patch has format problem. abandon. I send another email
use qq mail instead.
>
> amdgpu_gtt_mgr_new and ttm_range_man_alloc share similar logic, but
> "num_pages" in amdgpu_gtt_mgr_new is defined as local variable which
> is calculate directly in ttm_range_man_alloc.
>
> Signed-off-by: brolerliew
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> index 44367f03316f..0c56e4057d85 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> @@ -116,7 +116,6 @@ static int amdgpu_gtt_mgr_new(struct
> ttm_resource_manager *man,
> struct ttm_resource **res)
> {
>struct amdgpu_gtt_mgr *mgr = to_gtt_mgr(man);
> - uint32_t num_pages = PFN_UP(tbo->base.size);
>struct ttm_range_mgr_node *node;
>int r;
>
> @@ -134,7 +133,7 @@ static int amdgpu_gtt_mgr_new(struct
> ttm_resource_manager *man,
>if (place->lpfn) {
>spin_lock(>lock);
>r = drm_mm_insert_node_in_range(>mm, >mm_nodes[0],
> - num_pages,
> tbo->page_alignment,
> +
> PFN_UP(node->base.size), tbo->page_alignment,
>0, place->fpfn, place->lpfn,
>DRM_MM_INSERT_BEST);
>spin_unlock(>lock);
> --
> 2.40.1
[PATCH] drm/amdgpu: remove "num_pages" local variable in amdgpu_gtt_mgr_new
From: brolerliew
amdgpu_gtt_mgr_new and ttm_range_man_alloc share similar logic, but
"num_pages" in amdgpu_gtt_mgr_new is defined as local variable which
is calculate directly in ttm_range_man_alloc.
Signed-off-by: brolerliew <575705...@qq.com>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index 44367f03316f..0c56e4057d85 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -116,7 +116,6 @@ static int amdgpu_gtt_mgr_new(struct ttm_resource_manager
*man,
struct ttm_resource **res)
{
struct amdgpu_gtt_mgr *mgr = to_gtt_mgr(man);
- uint32_t num_pages = PFN_UP(tbo->base.size);
struct ttm_range_mgr_node *node;
int r;
@@ -134,7 +133,7 @@ static int amdgpu_gtt_mgr_new(struct ttm_resource_manager
*man,
if (place->lpfn) {
spin_lock(>lock);
r = drm_mm_insert_node_in_range(>mm, >mm_nodes[0],
- num_pages, tbo->page_alignment,
+ PFN_UP(node->base.size),
tbo->page_alignment,
0, place->fpfn, place->lpfn,
DRM_MM_INSERT_BEST);
spin_unlock(>lock);
--
2.40.1
