On 2022-06-27 15:05, Deucher, Alexander
wrote:
[Public]
-Original Message-
From: amd-gfx On Behalf Of Philip
Yang
Sent: Monday, June 27, 2022 1:32 PM
To: amd-gfx@lists.freedesktop.org
Cc: Yang, Philip
Subject: [PATCH 1/1] Revert
From: Alex Deucher
[ Upstream commit f15345a377c6ea9c7cc74f079616af8856aff37f ]
Certain GL unit tests for large textures can cause problems
with the OOM killer since there is no way to link this memory
to a process. This was originally mitigated (but not necessarily
eliminated) by limiting the
From: Alex Deucher
[ Upstream commit f15345a377c6ea9c7cc74f079616af8856aff37f ]
Certain GL unit tests for large textures can cause problems
with the OOM killer since there is no way to link this memory
to a process. This was originally mitigated (but not necessarily
eliminated) by limiting the
From: Alex Deucher
[ Upstream commit f15345a377c6ea9c7cc74f079616af8856aff37f ]
Certain GL unit tests for large textures can cause problems
with the OOM killer since there is no way to link this memory
to a process. This was originally mitigated (but not necessarily
eliminated) by limiting the
From: Alex Deucher
[ Upstream commit f15345a377c6ea9c7cc74f079616af8856aff37f ]
Certain GL unit tests for large textures can cause problems
with the OOM killer since there is no way to link this memory
to a process. This was originally mitigated (but not necessarily
eliminated) by limiting the
From: Alex Deucher
[ Upstream commit f15345a377c6ea9c7cc74f079616af8856aff37f ]
Certain GL unit tests for large textures can cause problems
with the OOM killer since there is no way to link this memory
to a process. This was originally mitigated (but not necessarily
eliminated) by limiting the
Reviewed-by: Guchun Chen
Regards,
Guchun
-Original Message-
From: amd-gfx On Behalf Of Leslie Shi
Sent: Monday, June 27, 2022 1:02 PM
To: amd-gfx@lists.freedesktop.org
Cc: Shi, Leslie ; Chen, Guchun ;
Zhang, Hawking
Subject: [PATCH] drm/amdgpu: Remove useless
This keeps track of kfd system mem used and kfd ttm mem used.
Signed-off-by: Alex Sierra
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 3 +++
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 19 +++
drivers/gpu/drm/amd/amdkfd/kfd_debugfs.c | 2 ++
3 files changed, 24
[WHY]
Unified memory with xnack off should be tracked, as userptr mappings
and legacy allocations do. To avoid oversuscribe system memory when
xnack off.
[How]
Exposing functions reserve_mem_limit and unreserve_mem_limit to SVM
API and call them on every prange creation and free.
Signed-off-by:
TTM used to track the "acc_size" of all BOs internally. We needed to
keep track of it in our memory reservation to avoid TTM running out
of memory in its own accounting. However, that "acc_size" accounting
has since been removed from TTM. Therefore we don't really need to
track it any more.
Add two more parameters to set spm_addr_dev0 & spm_addr_dev1
addresses. These two parameters configure the start SP
addresses for each device in test_hmm driver.
Consequently, this configures zone device type as coherent.
Signed-off-by: Alex Sierra
Acked-by: Felix Kuehling
Reviewed-by: Alistair
Device Coherent type uses device memory that is coherently accesible by
the CPU. This could be shown as SP (special purpose) memory range
at the BIOS-e820 memory enumeration. If no SP memory is supported in
system, this could be faked by setting CONFIG_EFI_FAKE_MEMMAP.
Currently, test_hmm only
The intention is to test hmm device coherent type under different get
user pages paths. Also, test gup with FOLL_LONGTERM flag set in
device coherent pages. These pages should get migrated back to system
memory.
Signed-off-by: Alex Sierra
Reviewed-by: Alistair Popple
---
Test cases such as migrate_fault and migrate_multiple, were modified to
explicit migrate from device to sys memory without the need of page
faults, when using device coherent type.
Snapshot test case updated to read memory device type first and based
on that, get the proper returned results
The objective is to test device migration mechanism in pages marked
as COW, for private and coherent device type. In case of writing to
COW private page(s), a page fault will migrate pages back to system
memory first. Then, these pages will be duplicated. In case of COW
device coherent type, pages
When CPU is connected throug XGMI, it has coherent
access to VRAM resource. In this case that resource
is taken from a table in the device gmc aperture base.
This resource is used along with the device type, which could
be DEVICE_PRIVATE or DEVICE_COHERENT to create the device
page map region.
new ioctl cmd added to query zone device type. This will be
used once the test_hmm adds zone device coherent type.
Signed-off-by: Alex Sierra
Acked-by: Felix Kuehling
Reviewed-by: Alistair Poppple
Signed-off-by: Christoph Hellwig
---
lib/test_hmm.c | 11 +--
lib/test_hmm_uapi.h
is_device_coherent checker was added to is_pinnable_page and renamed
to is_longterm_pinnable_page. The reason is that device coherent
pages are not supported for longterm pinning.
Signed-off-by: Alex Sierra
---
include/linux/memremap.h | 25 +
include/linux/mm.h |
In order to configure device coherent in test_hmm, two module parameters
should be passed, which correspond to the SP start address of each
device (2) spm_addr_dev0 & spm_addr_dev1. If no parameters are passed,
private device type is configured.
Signed-off-by: Alex Sierra
Acked-by: Felix
This case is used to migrate pages from device memory, back to system
memory. Device coherent type memory is cache coherent from device and CPU
point of view.
Signed-off-by: Alex Sierra
Acked-by: Felix Kuehling
Reviewed-by: Alistair Poppple
Signed-off-by: Christoph Hellwig
---
From: Alistair Popple
migrate_vma_setup() checks that a valid vma is passed so that the page
tables can be walked to find the pfns associated with a given address
range. However in some cases the pfns are already known, such as when
migrating device coherent pages during pin_user_pages() meaning
From: Alistair Popple
Currently any attempts to pin a device coherent page will fail. This is
because device coherent pages need to be managed by a device driver, and
pinning them would prevent a driver from migrating them off the device.
However this is no reason to fail pinning of these
With DEVICE_COHERENT, we'll soon have vm_normal_pages() return
device-managed anonymous pages that are not LRU pages. Although they
behave like normal pages for purposes of mapping in CPU page, and for
COW. They do not support LRU lists, NUMA migration or THP.
We also introduced a FOLL_LRU flag
Device memory that is cache coherent from device and CPU point of view.
This is used on platforms that have an advanced system bus (like CAPI
or CXL). Any page of a process can be migrated to such memory. However,
no one should be allowed to pin such memory so that it can always be
evicted.
This is our MEMORY_DEVICE_COHERENT patch series rebased and updated
for current 5.19.0-rc4
Changes since the last version:
- Fixed problems with migration during long-term pinning in
get_user_pages
- Open coded vm_normal_lru_pages as suggested in previous code review
- Update hmm_gup_test with
Applied. Thanks!
Alex
On Mon, Jun 27, 2022 at 9:20 AM Aurabindo Pillai
wrote:
>
>
>
> On 2022-06-26 10:46, Tom Rix wrote:
> > sparse reports
> > drivers/gpu/drm/amd/amdgpu/../display/dc/irq/dcn32/irq_service_dcn32.c:39:20:
> > warning: symbol 'to_dal_irq_source_dcn32' was not declared. Should
Applied. Thanks!
Alex
On Mon, Jun 27, 2022 at 9:20 AM Aurabindo Pillai
wrote:
>
>
>
> On 2022-06-26 10:20, Tom Rix wrote:
> > sparse reports
> > drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:3885:6: warning:
> > symbol 'FORCE_RATE' was not declared. Should it be static?
> >
Ping?
On Thu, Jun 23, 2022 at 12:41 PM Alex Deucher wrote:
>
> Fixes this issue:
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:5094: warning: expecting prototype
> for amdgpu_device_gpu_recover_imp(). Prototype was for
> amdgpu_device_gpu_recover() instead
>
> Fixes: cf727044144d ("drm/amdgpu:
Applied. Thanks!
Alex
On Fri, Jun 24, 2022 at 9:42 PM Souptick Joarder wrote:
>
> From: "Souptick Joarder (HPE)"
>
> Kernel test robot throws below warning ->
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:
> In function 'dc_link_reduce_mst_payload':
>
On Tue, Jun 21, 2022 at 10:42 AM Luben Tuikov wrote:
>
> This reverts commit e68efb27647f2106d6b545667f35b2ea39746b57.
>
> We see that the bo validate list gets corrupted, in
> amdgpu_cs_list_validate(), the lobj->tv.bo is NULL. Then getting usermm on
> the next line, references a NULL bo and we
Properly handle FP code in dcn32_clk_mgr.c.
Fixes: 265280b99822 ("drm/amd/display: add CLKMGR changes for DCN32/321")
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/display/dc/clk_mgr/dcn32/dcn32_clk_mgr.c | 4
1 file changed, 4 insertions(+)
diff --git
On Mon, Jun 27, 2022 at 03:22:24PM -0400, Alex Xu (Hello71) wrote:
> Hi,
>
> Since Linux 5.19-ish, I consistently get these types of errors when
> resuming from S3:
>
> [15652.909157] rcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks:
> { 11-... } 7 jiffies s: 9981 root: 0x800/.
>
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: aab35c3d5112df6e329a1a5a5a1881e5c4ca3821 Add linux-next specific
files for 20220627
Error/Warning: (recently discovered and may have been fixed)
arch/powerpc/kernel/interrupt.c:542:55: error
Hi,
Since Linux 5.19-ish, I consistently get these types of errors when
resuming from S3:
[15652.909157] rcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks: {
11-... } 7 jiffies s: 9981 root: 0x800/.
[15652.909162] rcu: blocking rcu_node structures (internal RCU debug):
[Public]
> -Original Message-
> From: amd-gfx On Behalf Of Philip
> Yang
> Sent: Monday, June 27, 2022 1:32 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Yang, Philip
> Subject: [PATCH 1/1] Revert "drm/amdkfd: Free queue after unmap queue
> success"
>
> This reverts commit
[AMD Official Use Only - General]
> -Original Message-
> From: Deucher, Alexander
> Sent: Monday, June 27, 2022 2:18 PM
> To: Vijendar Mukunda ; broo...@kernel.org;
> alsa-de...@alsa-project.org; dri-de...@lists.freedesktop.org; amd-
> g...@lists.freedesktop.org
> Cc: Dommati, Sunil-kumar
[AMD Official Use Only - General]
> -Original Message-
> From: amd-gfx On Behalf Of
> Vijendar Mukunda
> Sent: Monday, June 27, 2022 8:59 AM
> To: broo...@kernel.org; alsa-de...@alsa-project.org; dri-
> de...@lists.freedesktop.org; amd-gfx@lists.freedesktop.org
> Cc: Dommati, Sunil-kumar
This reverts commit 150c1266d78fbaa0fc5f89461daafae416db1c3e.
This causes KFDTest regression on gfx9, will submit new patch after
fixing.
---
.../drm/amd/amdkfd/kfd_device_queue_manager.c | 28 ---
.../amd/amdkfd/kfd_process_queue_manager.c| 2 +-
2 files changed, 12
On Mon, Jun 27, 2022 at 1:02 AM Javier Martinez Canillas
wrote:
>
> The flag was dropped because it was causing drivers that requested their
> memory resource with pci_request_region() to fail with -EBUSY (e.g: the
> vmwgfx driver):
>
> https://www.spinics.net/lists/dri-devel/msg329672.html
See,
On Mon, Jun 27, 2022 at 12:01 PM Eric Huang wrote:
>
> No. There is only internal link for now, because it is under review.
> Once it is submitted, external link should be in gerritgit for libhsakmt.
We need to have that available at the same time so that the kernel
side can be properly reviewed
No. There is only internal link for now, because it is under review.
Once it is submitted, external link should be in gerritgit for libhsakmt.
Regards,
Eric
On 2022-06-27 11:58, Alex Deucher wrote:
On Mon, Jun 27, 2022 at 11:36 AM Eric Huang wrote:
On Mon, Jun 27, 2022 at 11:36 AM Eric Huang wrote:
>
> http://gerrit-git.amd.com/c/compute/ec/libhsakmt/+/697296
Got an external link?
Alex
>
> Regards,
> Eric
>
> On 2022-06-27 11:33, Alex Deucher wrote:
> > On Fri, Jun 24, 2022 at 12:03 PM Eric Huang
> > wrote:
> >> It is to add new
http://gerrit-git.amd.com/c/compute/ec/libhsakmt/+/697296
Regards,
Eric
On 2022-06-27 11:33, Alex Deucher wrote:
On Fri, Jun 24, 2022 at 12:03 PM Eric Huang wrote:
It is to add new options for always keeping gpu mapping
and custom of coarse grain allocation intead of fine
grain as default.
On Fri, Jun 24, 2022 at 12:03 PM Eric Huang wrote:
>
> It is to add new options for always keeping gpu mapping
> and custom of coarse grain allocation intead of fine
> grain as default.
>
> Signed-off-by: Eric Huang
Can you provide a link to the proposed userspace for this?
Alex
> ---
>
On 2022-06-26 06:15, Chandan Vurdigere Nataraj wrote:
[Why]
Redundant if-else cases for repeater and non-repeater checks
[How]
Without changing the core logic, rearranged the code by removing
redundant checks
Signed-off-by: Chandan Vurdigere Nataraj
diff --git
[Why]
Some userspace expect a backwards compatible modifier on DCN32/321. For
hardware with num_pipes more than 16, we expose the most efficient
modifier first. As a fall back method, we need to expose slightly inefficient
modifier AMD_FMT_MOD_TILE_GFX9_64K_R_X after the best option.
Also set the
On 2022-06-26 10:20, Tom Rix wrote:
sparse reports
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:3885:6: warning:
symbol 'FORCE_RATE' was not declared. Should it be static?
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:3886:10: warning:
symbol 'FORCE_LANE_COUNT'
On 2022-06-26 10:46, Tom Rix wrote:
sparse reports
drivers/gpu/drm/amd/amdgpu/../display/dc/irq/dcn32/irq_service_dcn32.c:39:20:
warning: symbol 'to_dal_irq_source_dcn32' was not declared. Should it be static?
to_dal_irq_source_dnc32() is only referenced in irq_service_dnc32.c, so change
From: vijendar
Fixed below checkpatch warnings and errors
drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:131: CHECK: Comparison to NULL could be
written "apd"
drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:150: CHECK: Comparison to NULL could be
written "apd"
drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:196:
From: "Souptick Joarder (HPE)"
Kernel test robot throws below warning ->
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:
In function 'dc_link_reduce_mst_payload':
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:3782:32:
warning: variable 'ret' set but not used
So this has been going on for a while, and it's quite annoying.
At bootup, my main desktop (Threadripper 3970X with radeon graphics)
now complains about
resource sanity check: requesting [mem 0xd000-0xdfff], which
spans more than BOOTFB [mem 0xd000-0xd02f]
and then gives me a
sparse reports
drivers/gpu/drm/amd/amdgpu/../display/dc/irq/dcn32/irq_service_dcn32.c:39:20:
warning: symbol 'to_dal_irq_source_dcn32' was not declared. Should it be static?
to_dal_irq_source_dnc32() is only referenced in irq_service_dnc32.c, so change
its
storage class specifier to static.
sparse reports
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:3885:6: warning:
symbol 'FORCE_RATE' was not declared. Should it be static?
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:3886:10: warning:
symbol 'FORCE_LANE_COUNT' was not declared. Should it be static?
On Sun, Jun 19, 2022 at 09:31:03PM -0100, Melissa Wen wrote:
> Add 3D LUT for gammar correction using a 3D lookup table. The position
> in the color correction pipeline where 3D LUT is applied depends on hw
> design, being after CTM or gamma. If just after CTM, a shaper lut must
> be set to shape
Hi
Am 26.06.22 um 20:54 schrieb Linus Torvalds:
So this has been going on for a while, and it's quite annoying.
At bootup, my main desktop (Threadripper 3970X with radeon graphics)
now complains about
resource sanity check: requesting [mem 0xd000-0xdfff], which
spans more than
Hello Linus,
On 6/26/22 20:54, Linus Torvalds wrote:
> So this has been going on for a while, and it's quite annoying.
>
> At bootup, my main desktop (Threadripper 3970X with radeon graphics)
> now complains about
>
> resource sanity check: requesting [mem 0xd000-0xdfff], which
>
[AMD Official Use Only - General]
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: amd-gfx On Behalf Of Leslie Shi
Sent: Monday, June 27, 2022 13:02
To: amd-gfx@lists.freedesktop.org
Cc: Shi, Leslie ; Chen, Guchun ;
Zhang, Hawking
Subject: [PATCH] drm/amdgpu:
57 matches
Mail list logo
