[PATCH v2 2/2] drm/amdkfd: fix resume error when iommu disabled in Picasso

When IOMMU disabled in sbios and kfd in iommuv2 path, IOMMU resume failure blocks system resume. Don't allow kfd to use iommu v2 when iommu is disabled. Reported-by: youling Tested-by: youling Signed-off-by: Yifan Zhang --- drivers/gpu/drm/amd/amdkfd/kfd_device.c | 1 + 1 file changed, 1 inser

[PATCH v2 1/2] drm/amdkfd: fix boot failure when iommu is disabled in Picasso.

When IOMMU disabled in sbios and kfd in iommuv2 path, iommuv2 init will fail. But this failure should not block amdgpu driver init. Reported-by: youling Tested-by: youling Signed-off-by: Yifan Zhang --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 drivers/gpu/drm/amd/amdkfd/kfd_device.

Re: [PATCH 0/5] 0 MHz is not a valid current frequency

On 10/13/2021 8:40 AM, Luben Tuikov wrote: Some ASIC support low-power functionality for the whole ASIC or just an IP block. When in such low-power mode, some sysfs interfaces would report a frequency of 0, e.g., $cat /sys/class/drm/card0/device/pp_dpm_sclk 0: 500Mhz 1: 0Mhz * 2: 2200Mhz $_

[PATCH 1/5] drm/amd/pm: Slight function rename

Rename sienna_cichlid_is_support_fine_grained_dpm() to sienna_cichlid_support_fine_grained_dpm(). Rename navi10_is_support_fine_grained_dpm() to navi10_supports_fine_grained_dpm(). Signed-off-by: Luben Tuikov --- drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c | 7 --- drivers/gpu/d

[PATCH 3/5] drm/amd/pm: Rename freq_values --> freq_value

By usage: read freq_values[x] to freq_value[x]. Signed-off-by: Luben Tuikov --- .../gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c| 16 .../amd/pm/swsmu/smu11/sienna_cichlid_ppt.c| 18 +- 2 files changed, 17 insertions(+), 17 deletions(-) diff --git a/drivers/g

[PATCH 4/5] dpm/amd/pm: Sienna: 0 MHz is not a current clock frequency

A current value of a clock frequency of 0, means that the IP block is in some kind of low power state. Ignore it and don't report it here. Here we only report the possible operating (non-zero) frequencies of the block requested. So, if the current clock value is 0, then report as the current clock

[PATCH 5/5] dpm/amd/pm: Navi10: 0 MHz is not a current clock frequency

A current value of a clock frequency of 0, means that the IP block is in some kind of low power state. Ignore it and don't report it here. Here we only report the possible operating (non-zero) frequencies of the block requested. So, if the current clock value is 0, then report as the current clock

[PATCH 2/5] drm/amd/pm: Rename cur_value to curr_value

Rename "cur_value", which stands for "cursor value" to "curr_value", which stands for "current value". Signed-off-by: Luben Tuikov --- drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c | 12 ++-- .../drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 15 --- 2 files changed, 14

[PATCH 0/5] 0 MHz is not a valid current frequency

Some ASIC support low-power functionality for the whole ASIC or just an IP block. When in such low-power mode, some sysfs interfaces would report a frequency of 0, e.g., $cat /sys/class/drm/card0/device/pp_dpm_sclk 0: 500Mhz 1: 0Mhz * 2: 2200Mhz $_ An operating frequency of 0 MHz doesn't make s

[PATCH AUTOSEL 5.10 06/11] drm/amdgpu/display: fix dependencies for DRM_AMD_DC_SI

From: Alex Deucher [ Upstream commit 4702b34d1de9582df9dfa0e583ea28fff7de29df ] Depends on DRM_AMDGPU_SI and DRM_AMD_DC Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff -

[PATCH AUTOSEL 5.14 09/17] drm/amdgpu: init iommu after amdkfd device init

From: Yifan Zhang [ Upstream commit 714d9e4574d54596973ee3b0624ee4a16264d700 ] This patch is to fix clinfo failure in Raven/Picasso: Number of platforms: 1 Platform Profile: FULL_PROFILE Platform Version: OpenCL 2.2 AMD-APP (3364.0) Platform Name: AMD Accelerated Parallel Processing Pla

[PATCH AUTOSEL 5.14 08/17] drm/amdgpu/display: fix dependencies for DRM_AMD_DC_SI

From: Alex Deucher [ Upstream commit 4702b34d1de9582df9dfa0e583ea28fff7de29df ] Depends on DRM_AMDGPU_SI and DRM_AMD_DC Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff -

Re: [PATCH v1 00/12] MEMORY_DEVICE_COHERENT for CPU-accessible coherent device memory

Am 2021-10-12 um 3:03 p.m. schrieb Andrew Morton: > On Tue, 12 Oct 2021 15:56:29 -0300 Jason Gunthorpe wrote: > >>> To what other uses will this infrastructure be put? >>> >>> Because I must ask: if this feature is for one single computer which >>> presumably has a custom kernel, why add it to mai

Re: [PATCH v2 1/3] drm/amdkfd: ratelimited svm debug messages

Am 2021-10-12 um 9:55 a.m. schrieb Philip Yang: > No function change, use pr_debug_ratelimited to avoid per page debug > message overflowing dmesg buf and console log. > > use dev_err to show error message from unexpected situation, to provide > clue to help debug without enabling dynamic debug log

Re: [PATCH v4 2/3] drm/amdkfd: handle svm partial migration cpages 0

Am 2021-10-12 um 6:39 p.m. schrieb Philip Yang: > migrate_vma_setup may return cpages 0, means 0 page can be migrated, > treat this as error case to skip the rest of vma migration steps. > > Change svm_migrate_vma_to_vram and svm_migrate_vma_to_ram to return the > number of pages migrated success

[PATCH v4 2/3] drm/amdkfd: handle svm partial migration cpages 0

migrate_vma_setup may return cpages 0, means 0 page can be migrated, treat this as error case to skip the rest of vma migration steps. Change svm_migrate_vma_to_vram and svm_migrate_vma_to_ram to return the number of pages migrated successfully or error code. The caller add up all the successful m

Re: [PATCH v3 2/3] drm/amdkfd: handle svm partial migration cpages 0

Am 2021-10-12 um 5:00 p.m. schrieb Philip Yang: > migrate_vma_setup may return cpages 0, means 0 page can be migrated, > treat this as error case to skip the rest of vma migration steps. > > Change svm_migrate_vma_to_vram and svm_migrate_vma_to_ram to return the > number of pages migrated success

Re: [PATCH v5] amd/display: only require overlay plane to cover whole CRTC on ChromeOS

On Tue, Oct 12, 2021 at 4:57 PM Harry Wentland wrote: > > > > On 10/12/21 3:57 PM, Alex Deucher wrote: > > On Tue, Oct 12, 2021 at 10:39 AM Harry Wentland > > wrote: > >> > >> On 2021-10-11 11:16, Simon Ser wrote: > >>> Commit ddab8bd788f5 ("drm/amd/display: Fix two cursor duplication when > >>>

[PATCH v3 2/3] drm/amdkfd: handle svm partial migration cpages 0

migrate_vma_setup may return cpages 0, means 0 page can be migrated, treat this as error case to skip the rest of vma migration steps. Change svm_migrate_vma_to_vram and svm_migrate_vma_to_ram to return the number of pages migrated successfully or error code. The caller add up all the successful m

Re: [PATCH v5] amd/display: only require overlay plane to cover whole CRTC on ChromeOS

On 10/12/21 3:57 PM, Alex Deucher wrote: On Tue, Oct 12, 2021 at 10:39 AM Harry Wentland wrote: On 2021-10-11 11:16, Simon Ser wrote: Commit ddab8bd788f5 ("drm/amd/display: Fix two cursor duplication when using overlay") changed the atomic validation code to forbid the overlay plane from b

[PATCH] drm/amdgpu: Warn when bad pages approaches threshold

Currently dmesg doesn't warn when the number of bad pages approaches the threshold for page retirement. WARN when the number of bad pages is at 90% or greater for easier checks and planning, instead of waiting until the GPU is full of bad pages Signed-off-by: Kent Russell --- drivers/gpu/drm/amd

Re: Fwd: [PATCH] Size can be any value and is user controlled resulting in overwriting the 40 byte array wr_buf with an arbitrary length of data from buf.

On Tue, Oct 12, 2021 at 4:45 PM T. Williams wrote: > > Should I resubmit the patch email with correct formatting? MITRE assigned > this bug as CVE-2021-42327. Does AMD/kernel do public vulnerability reports? > Do I need to email someone else or something(sorry for dumb questions this is > my fi

Re: Fwd: [PATCH] Size can be any value and is user controlled resulting in overwriting the 40 byte array wr_buf with an arbitrary length of data from buf.

Should I resubmit the patch email with correct formatting? MITRE assigned this bug as CVE-2021-42327. Does AMD/kernel do public vulnerability reports? Do I need to email someone else or something(sorry for dumb questions this is my first time doing this and I don't know what to do)? I am trying to

Re: [PATCH v1 00/12] MEMORY_DEVICE_COHERENT for CPU-accessible coherent device memory

On Tue, Oct 12, 2021 at 04:24:25PM -0400, Felix Kuehling wrote: > > Am 2021-10-12 um 3:11 p.m. schrieb Matthew Wilcox: > > On Tue, Oct 12, 2021 at 11:39:57AM -0700, Andrew Morton wrote: > >> Because I must ask: if this feature is for one single computer which > >> presumably has a custom kernel, w

Re: [PATCH v1 00/12] MEMORY_DEVICE_COHERENT for CPU-accessible coherent device memory

Am 2021-10-12 um 3:11 p.m. schrieb Matthew Wilcox: > On Tue, Oct 12, 2021 at 11:39:57AM -0700, Andrew Morton wrote: >> Because I must ask: if this feature is for one single computer which >> presumably has a custom kernel, why add it to mainline Linux? > I think in particular patch 2 deserves to

Re: [PATCH v5] amd/display: only require overlay plane to cover whole CRTC on ChromeOS

On Tue, Oct 12, 2021 at 10:39 AM Harry Wentland wrote: > > On 2021-10-11 11:16, Simon Ser wrote: > > Commit ddab8bd788f5 ("drm/amd/display: Fix two cursor duplication when > > using overlay") changed the atomic validation code to forbid the > > overlay plane from being used if it doesn't cover the

Re: [PATCH] drm/amdgpu: enable display for cyan skillfish

On Tue, Oct 12, 2021 at 2:16 AM Lang Yu wrote: > > Display support for cyan skillfish is ready now. Enable it! > > Signed-off-by: Lang Yu Whoops. this is my mistake. I lost the display enablement when the IP discovery patches and the cyan skillfish display patches crossed. Reviewed-by: Alex De

Re: [PATCH v1 00/12] MEMORY_DEVICE_COHERENT for CPU-accessible coherent device memory

On Tue, Oct 12, 2021 at 11:39:57AM -0700, Andrew Morton wrote: > Because I must ask: if this feature is for one single computer which > presumably has a custom kernel, why add it to mainline Linux? I think in particular patch 2 deserves to be merged because it removes a ton of cruft from every cal

Re: [PATCH v1 00/12] MEMORY_DEVICE_COHERENT for CPU-accessible coherent device memory

On Tue, 12 Oct 2021 15:56:29 -0300 Jason Gunthorpe wrote: > > To what other uses will this infrastructure be put? > > > > Because I must ask: if this feature is for one single computer which > > presumably has a custom kernel, why add it to mainline Linux? > > Well, it certainly isn't just "one

Re: [PATCH v1 00/12] MEMORY_DEVICE_COHERENT for CPU-accessible coherent device memory

Am 2021-10-12 um 2:39 p.m. schrieb Andrew Morton: > On Tue, 12 Oct 2021 12:12:35 -0500 Alex Sierra wrote: > >> This patch series introduces MEMORY_DEVICE_COHERENT, a type of memory >> owned by a device that can be mapped into CPU page tables like >> MEMORY_DEVICE_GENERIC and can also be migrated l

Re: [PATCH v1 00/12] MEMORY_DEVICE_COHERENT for CPU-accessible coherent device memory

On Tue, Oct 12, 2021 at 11:39:57AM -0700, Andrew Morton wrote: > On Tue, 12 Oct 2021 12:12:35 -0500 Alex Sierra wrote: > > > This patch series introduces MEMORY_DEVICE_COHERENT, a type of memory > > owned by a device that can be mapped into CPU page tables like > > MEMORY_DEVICE_GENERIC and can a

Re: [PATCH v1 00/12] MEMORY_DEVICE_COHERENT for CPU-accessible coherent device memory

On Tue, 12 Oct 2021 12:12:35 -0500 Alex Sierra wrote: > This patch series introduces MEMORY_DEVICE_COHERENT, a type of memory > owned by a device that can be mapped into CPU page tables like > MEMORY_DEVICE_GENERIC and can also be migrated like MEMORY_DEVICE_PRIVATE. > With MEMORY_DEVICE_COHERENT

[PATCH v1 10/12] lib: add support for device coherent type in test_hmm

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 sup

[PATCH v1 12/12] tools: update test_hmm script to support SP config

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 --- tools/testing/selftests/vm/test_hmm.sh | 20

[PATCH v1 11/12] tools: update hmm-test to support device coherent type

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 migrat

[PATCH v1 09/12] lib: test_hmm add module param for zone device type

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 --- lib/test_hmm.c

[PATCH v1 07/12] drm/amdkfd: coherent type as sys mem on migration to ram

Coherent device type memory on VRAM to RAM migration, has similar access as System RAM from the CPU. This flag sets the source from the sender. Which in Coherent type case, should be set as MIGRATE_VMA_SELECT_DEVICE_COHERENT. Signed-off-by: Alex Sierra Reviewed-by: Felix Kuehling --- drivers/gp

[PATCH v1 08/12] lib: test_hmm add ioctl to get zone device type

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 --- lib/test_hmm.c | 15 ++- lib/test_hmm_uapi.h | 7 +++ 2 files changed, 21 insertions(+), 1 deletion(-) diff --git a/lib/test_hm

[PATCH v1 06/12] drm/amdkfd: add SPM support for SVM

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. Sig

[PATCH v1 05/12] drm/amdkfd: ref count init for device pages

Ref counter from device pages is init to zero during memmap init zone. The first time a new device page is allocated to migrate data into it, its ref counter needs to be initialized to one. Signed-off-by: Alex Sierra --- drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 3 ++- 1 file changed, 2 inserti

[PATCH v1 04/12] mm: add device coherent vma selection for memory migration

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 --- v2: condition added when migrations from device coherent pages. --- include/linux/migrate.h | 1 + mm/migr

[PATCH v1 02/12] mm: remove extra ZONE_DEVICE struct page refcount

From: Ralph Campbell ZONE_DEVICE struct pages have an extra reference count that complicates the code for put_page() and several places in the kernel that need to check the reference count to see that a page is not being used (gup, compaction, migration, etc.). Clean up the code so the reference

[PATCH v1 03/12] mm: add zone device coherent type memory support

Device memory that is cache coherent from device and CPU point of view. This is use on platform that have an advance system bus (like CAPI or CCIX). Any page of a process can be migrated to such memory. However, no one should be allow to pin such memory so that it can always be evicted. Signed-off

[PATCH v1 01/12] ext4/xfs: add page refcount helper

From: Ralph Campbell There are several places where ZONE_DEVICE struct pages assume a reference count == 1 means the page is idle and free. Instead of open coding this, add a helper function to hide this detail. Signed-off-by: Ralph Campbell Signed-off-by: Alex Sierra Reviewed-by: Christoph He

[PATCH v1 00/12] MEMORY_DEVICE_COHERENT for CPU-accessible coherent device memory

This patch series introduces MEMORY_DEVICE_COHERENT, a type of memory owned by a device that can be mapped into CPU page tables like MEMORY_DEVICE_GENERIC and can also be migrated like MEMORY_DEVICE_PRIVATE. With MEMORY_DEVICE_COHERENT, we isolate the new memory type from other subsystems as far as

[PATCH] drm/amdgpu/gfx10: fix typo in gfx_v10_0_update_gfx_clock_gating()

Check was incorrectly converted to IP version checking. Fixes: 4b0ad8425498ba ("drm/amdgpu/gfx10: convert to IP version checking") Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/a

[PATCH 3/3] drm/amdgpu/psp: add some missing cases to psp_check_pmfw_centralized_cstate_management

Missed a few asics. Fixes: 82d05736c47b19 ("drm/amdgpu/amdgpu_psp: convert to IP version checking") 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/

[PATCH 2/3] drm/amdgpu/swsmu: fix is_support_sw_smu() for VEGA20

VEGA20 is 11.0.2, but it's handled by powerplay, not swsmu. Fixes: a8967967f6a554 ("drm/amdgpu/amdgpu_smu: convert to IP version checking") Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/amd/pm/sws

[PATCH 1/3] drm/amdgpu/smu11: fix firmware version check for vangogh

Was missed in the conversion to IP version checking. Fixes: af3b89d3a639d5 ("drm/amdgpu/smu11.0: convert to IP version checking") Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd

RE: [PATCH 2/2] drm/amdgpu: Fix RAS page retirement with mode2 reset on Aldebaran

[AMD Official Use Only] Thanks Tao. I will add a comment as you suggested before committing the change. Regards, Mukul From: Zhou1, Tao Sent: Monday, October 11, 2021 11:55 PM To: Joshi, Mukul ; amd-gfx@lists.freedesktop.org Cc: Clements, John Subject: Re: [PATCH 2/2] drm/amdgpu: Fix RAS page

Re: [PATCH v5] amd/display: only require overlay plane to cover whole CRTC on ChromeOS

On 2021-10-11 11:16, Simon Ser wrote: > Commit ddab8bd788f5 ("drm/amd/display: Fix two cursor duplication when > using overlay") changed the atomic validation code to forbid the > overlay plane from being used if it doesn't cover the whole CRTC. The > motivation is that ChromeOS uses the atomic API

Re: [PATCH 1/2] drm/amdkfd: fix boot failure when iommu is disabled in Picasso.

[AMD Official Use Only] From: Zhang, Yifan Sent: Monday, October 11, 2021 8:57 AM To: amd-gfx@lists.freedesktop.org Cc: Kuehling, Felix ; Zhu, James ; youling...@gmail.com ; Zhang, Yifan Subject: [PATCH 1/2] drm/amdkfd: fix boot failure when iommu is disabled

Re: [PATCH] drm/amd/display: fix null pointer deref when plugging in display

On 2021-10-12 09:26, Aurabindo Pillai wrote: > [Why&How] > When system boots in headless mode, connecting a 4k display creates a > null pointer dereference due to hubp for a certain plane being null. > Add a condition to check for null hubp before dereferencing it. > > Signed-off-by: Aurabindo Pil

Re: [PATCH] drm/amd/display: Fix surface optimization regression on Carrizo

On 2021-10-12 10:11, Nicholas Kazlauskas wrote: > [Why] > DCE legacy optimization path isn't well tested under new DC optimization > flow which can result in underflow occuring when initializing X11 on > Carrizo. > > [How] > Retain the legacy optimization flow for DCE and keep the new one for D

Re: [PATCH] drm/amd/display: Fix surface optimization regression on Carrizo

[AMD Official Use Only] Tested-by: Tom St Denis Thanks. From: Alex Deucher Sent: Tuesday, October 12, 2021 10:15 To: Kazlauskas, Nicholas Cc: amd-gfx list; Lakha, Bhawanpreet; Lipski, Mikita; StDenis, Tom Subject: Re: [PATCH] drm/amd/display: Fix surfac

Re: [PATCH] drm/amd/display: Enable PSR by default on DCN3.1

On 2021-10-08 12:14, Nicholas Kazlauskas wrote: > [Why] > New idle optimizations for DCN3.1 require PSR for optimal power savings > on panels that support it. > > This was previously left disabled by default because of issues with > compositors that do not pageflip and scan out directly to the > f

Re: [PATCH] drm/amd/display: Fix surface optimization regression on Carrizo

On Tue, Oct 12, 2021 at 10:11 AM Nicholas Kazlauskas wrote: > > [Why] > DCE legacy optimization path isn't well tested under new DC optimization > flow which can result in underflow occuring when initializing X11 on > Carrizo. > > [How] > Retain the legacy optimization flow for DCE and keep the ne

[PATCH] drm/amd/display: Fix surface optimization regression on Carrizo

[Why] DCE legacy optimization path isn't well tested under new DC optimization flow which can result in underflow occuring when initializing X11 on Carrizo. [How] Retain the legacy optimization flow for DCE and keep the new one for DCN to satisfy optimizations being correctly applied for ASIC that

[PATCH v2 3/3] drm/amdkfd: create unregister svm range not overlap with TTM range

When creating new svm range to recover retry fault, avoid svm range to overlap with ranges or userptr ranges managed by TTM, otherwise svm migration will trigger TTM or userptr eviction, to evict user queues unexpectedly. Change helper amdgpu_ttm_tt_affect_userptr to return userptr which is inside

[PATCH v2 2/3] drm/amdkfd: handle svm partial migration cpages 0

migrate_vma_setup may return cpages 0, means 0 page can be migrated, treat this as error case to skip the rest of vma migration steps. Change svm_migrate_vma_to_vram and svm_migrate_vma_to_ram to return the number of pages migrated successfully. The caller add up all the successful migration pages

[PATCH v2 1/3] drm/amdkfd: ratelimited svm debug messages

No function change, use pr_debug_ratelimited to avoid per page debug message overflowing dmesg buf and console log. use dev_err to show error message from unexpected situation, to provide clue to help debug without enabling dynamic debug log. Define dev_fmt to output function name in error message

Re: [PATCH] drm/amd/display: Enable PSR by default on DCN3.1

On 2021-10-11 1:04 a.m., Vishwakarma, Pratik wrote: On 10/8/2021 9:44 PM, Nicholas Kazlauskas wrote: [Why] New idle optimizations for DCN3.1 require PSR for optimal power savings on panels that support it. This was previously left disabled by default because of issues with compositors that do

[PATCH] drm/amd/display: fix null pointer deref when plugging in display

[Why&How] When system boots in headless mode, connecting a 4k display creates a null pointer dereference due to hubp for a certain plane being null. Add a condition to check for null hubp before dereferencing it. Signed-off-by: Aurabindo Pillai --- drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwse

Re: [PATCH Review 1/1] drm/ttm: fix debugfs node create failed

On 10/12/2021 1:58 PM, Stanley.Yang wrote: Test scenario: modprobe amdgpu -> rmmod amdgpu -> modprobe amdgpu Error log: [ 54.396807] debugfs: File 'page_pool' in directory 'amdttm' already present! [ 54.396833] debugfs: File 'page_pool_shrink' in directory 'amdttm' already

[PATCH 1/1] drm/amdgpu: release gtt bo after each move test

When gart size is < gtt size this test will fail with -ENOMEM as we are not freeing gtt bo after each move test. This is generally not an issue when gart size >= gtt size. Reported-by: zhang Signed-off-by: Nirmoy Das --- drivers/gpu/drm/amd/amdgpu/amdgpu_test.c | 2 +- 1 file changed, 1 inserti

[PATCH Review 1/1] drm/ttm: fix debugfs node create failed

Test scenario: modprobe amdgpu -> rmmod amdgpu -> modprobe amdgpu Error log: [ 54.396807] debugfs: File 'page_pool' in directory 'amdttm' already present! [ 54.396833] debugfs: File 'page_pool_shrink' in directory 'amdttm' already present! [ 54.396848] debugfs: File 'buffer_

Re: [PATCH v5] amd/display: only require overlay plane to cover whole CRTC on ChromeOS

On Tuesday, October 12th, 2021 at 11:24, Paul Menzel wrote: > Thank you for the explanation. Then I misunderstood commit ddab8bd7 > (drm/amd/display: Fix two cursor duplication when using overlay) from > the Fixes tag, as commit ddab8bd7 does not mention Chrome OS, and also > does not carry a fi

Re: [PATCH v5] amd/display: only require overlay plane to cover whole CRTC on ChromeOS

Dear Simon, Am 12.10.21 um 11:15 schrieb Simon Ser: On Tuesday, October 12th, 2021 at 11:08, Paul Menzel wrote: the cursor plane (which uses the legacy API). Thus amdgpu must always be prepared to enable/disable/move the cursor plane at any time without failing (or else ChromeOS will trip o

RE: [PATCH] drm/amdgpu: enable display for cyan skillfish

[Public] >-Original Message- >From: Paul Menzel >Sent: Tuesday, October 12, 2021 4:51 PM >To: Yu, Lang >Cc: Deucher, Alexander ; Huang, Ray >; amd-gfx@lists.freedesktop.org >Subject: Re: [PATCH] drm/amdgpu: enable display for cyan skillfish > >Dear Lang, > > >Am 12.10.21 um 08:16 schri

Re: [PATCH v5] amd/display: only require overlay plane to cover whole CRTC on ChromeOS

On Tuesday, October 12th, 2021 at 11:08, Paul Menzel wrote: > > the cursor plane (which uses the legacy API). Thus amdgpu must always > > be prepared to enable/disable/move the cursor plane at any time without > > failing (or else ChromeOS will trip over). > > What ChromeOS version did you test

Re: [PATCH v5] amd/display: only require overlay plane to cover whole CRTC on ChromeOS

Dear Simon, Am 11.10.21 um 17:16 schrieb Simon Ser: Commit ddab8bd788f5 ("drm/amd/display: Fix two cursor duplication when using overlay") changed the atomic validation code to forbid the overlay plane from being used if it doesn't cover the whole CRTC. The motivation is that ChromeOS uses the

Re: [PATCH] drm/amdgpu: enable display for cyan skillfish

Dear Lang, Am 12.10.21 um 08:16 schrieb Lang Yu: Display support for cyan skillfish is ready now. What is the last commit making it “ready”? Enable it! How did you test the patch? Signed-off-by: Lang Yu --- drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 3 +-- 1 file changed, 1 ins

RE: [PATCH] drm/amdgpu: enable display for cyan skillfish

[AMD Official Use Only] + Charlene. Reviewed-by: Huang Rui -Original Message- From: Yu, Lang Sent: Tuesday, October 12, 2021 2:16 PM To: amd-gfx@lists.freedesktop.org Cc: Deucher, Alexander ; Huang, Ray ; Yu, Lang Subject: [PATCH] drm/amdgpu: enable display for cyan skillfish Displ

Re: Fwd: [PATCH] Size can be any value and is user controlled resulting in overwriting the 40 byte array wr_buf with an arbitrary length of data from buf.

Am 11.10.21 um 22:24 schrieb T. Williams: -- Forwarded message - From: *docfate111* > Date: Mon, Oct 11, 2021 at 4:22 PM Subject: [PATCH] Size can be any value and is user controlled resulting in overwriting the 40 byte array wr_buf with an arbit