Re: [PATCH] drm/amdkfd: report the real PCI bus number

Am 2020-05-20 um 11:34 p.m. schrieb Evan Quan: > Since the PCI bus number retrieved by PCI_BUS_NUM(pdev->devfn) > is wrong. > > Change-Id: I882a8531a65cdf91be20e34a034aca1f43f658b4 > Signed-off-by: Evan Quan Reviewed-by: Felix Kuehling > --- > drivers/gpu/drm/amd/amdkfd/kfd_iommu.c | 2 +-

[PATCH] drm/amdkfd: report the real PCI bus number

Since the PCI bus number retrieved by PCI_BUS_NUM(pdev->devfn) is wrong. Change-Id: I882a8531a65cdf91be20e34a034aca1f43f658b4 Signed-off-by: Evan Quan --- drivers/gpu/drm/amd/amdkfd/kfd_iommu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: slow rx 5600 xt fps

I think you are overcomplicating things. Just try and get X running on just the AMD GPU on bare metal. Introducing virtualization is just adding more uncertainty. If you can't configure X to not use the integrated GPU, just blacklist the i915 driver (append modprobe.blacklist=i915 to the kernel

Re: [PATCH v1 13/25] dma-buf: Use sequence counter with associated wound/wait mutex

On Wed, May 20, 2020, Christian König wrote: > Am 19.05.20 um 23:45 schrieb Ahmed S. Darwish: > > A sequence counter write side critical section must be protected by some > > form of locking to serialize writers. If the serialization primitive is > > not disabling preemption implicitly, preemption

[PATCH 1/1] drm/amdgpu: Sync with VM root BO when switching VM to CPU update mode

This fixes an intermittent bug where a root PD clear operation still in progress could overwrite a PDE update done by the CPU, resulting in a VM fault. Fixes: 108b4d928c03 ("drm/amd/amdgpu: Update VM function pointer") Reported-by: Jay Cornwall Tested-by: Jay Cornwall Signed-off-by: Felix

RE: Flaky brightness on Renoir

[AMD Official Use Only - Internal Distribution Only] It's touching around that area, but just the endian-ness change itself would not cause the boot-to-boot variation observed here. But it could cause broken backlight behavior. I also don't know what driver is being tested, so I don't know

Re: Flaky brightness on Renoir

On 2020-05-20 6:03 p.m., Koo, Anthony wrote: > [AMD Official Use Only - Internal Distribution Only] > > Hi Harry, > > It does sound like a firmware issue. > I think we will need to do some investigation here. I would be curious if > this is a driver regression or just never worked (not sure how

Re: slow rx 5600 xt fps

Thanks Alex, Here's my plan: since my laptop's os is pretty customized, e.g. compiling my own kernel, building latest xorg, latest xorg-driver-amdgpu, etc etc, im going to use the intel iommu and pass through my rx 5600 into a virtual machine, which will be a 100% stock ubuntu installation. then,

RE: Flaky brightness on Renoir

[AMD Official Use Only - Internal Distribution Only] Hi Harry, It does sound like a firmware issue. I think we will need to do some investigation here. I would be curious if this is a driver regression or just never worked (not sure how new the driver being tested is). This point below seems

Re: Flaky brightness on Renoir

We've seen similar problems internally. Michael, does this "fix" your issue? Anthony, looks like smooth_brightness is problematic on (some) renoir systems. Thoughts? Thanks, Harry On 2020-05-20 5:47 p.m., Alex Deucher wrote: > Adding some display people. > > On Wed, May 20, 2020 at 5:46 PM

Re: Flaky brightness on Renoir

Adding some display people. On Wed, May 20, 2020 at 5:46 PM Alexander Monakov wrote: > > Hello, > > I have a laptop with the recent Renoir SoC. Screen brightness is > controlled via the amdgpu driver. Unfortunately it doesn't work > properly: brightness doesn't go below a certain threshold. In

Flaky brightness on Renoir

Hello, I have a laptop with the recent Renoir SoC. Screen brightness is controlled via the amdgpu driver. Unfortunately it doesn't work properly: brightness doesn't go below a certain threshold. In one experiment I've found the threshold to be about 95 (of 255), which is quite high. There's a

Re: [PATCH 2/2] drm/amd/display: Enable fp16 also on DCE-11.0 - DCE-12.

On Wed, May 20, 2020 at 9:07 PM Kazlauskas, Nicholas < nicholas.kazlaus...@amd.com> wrote: > On 2020-05-20 2:44 p.m., Mario Kleiner wrote: > > On Wed, May 20, 2020 at 8:25 PM Alex Deucher > > wrote: > > > > On Wed, May 20, 2020 at 12:39 PM Harry Wentland >

Re: [PATCH] drm/amd/amdkfd: Fix large framesize for kfd_smi_ev_read()

Am 2020-05-20 um 9:53 a.m. schrieb Aurabindo Pillai: > The buffer allocated is of 1024 bytes. Allocate this from > heap instead of stack. > > Also remove check for stack size since we're allocating from heap > > Signed-off-by: Aurabindo Pillai > Tested-by: Amber Lin See one comment inline. With

Re: [PATCH 2/2] drm/amd/display: Enable fp16 also on DCE-11.0 - DCE-12.

On 2020-05-20 2:44 p.m., Mario Kleiner wrote: On Wed, May 20, 2020 at 8:25 PM Alex Deucher > wrote: On Wed, May 20, 2020 at 12:39 PM Harry Wentland mailto:hwent...@amd.com>> wrote: > > On 2020-05-15 1:19 a.m., Mario Kleiner wrote: > > Testing on

Re: [PATCH 2/2] drm/amd/display: Enable fp16 also on DCE-11.0 - DCE-12.

On Wed, May 20, 2020 at 8:25 PM Alex Deucher wrote: > On Wed, May 20, 2020 at 12:39 PM Harry Wentland wrote: > > > > On 2020-05-15 1:19 a.m., Mario Kleiner wrote: > > > Testing on a Polaris11 gpu with DCE-11.2 suggests that it > > > seems to work fine there, so optimistically enable it for > >

Re: [PATCH v3] drm/amdgpu: off by one in amdgpu_device_attr_create_groups() error handling

Applied. Thanks! Alex On Wed, May 20, 2020 at 11:33 AM Christian König wrote: > Am 20.05.20 um 17:31 schrieb Ruhl, Michael J: > >> -Original Message- > >> From: Dan Carpenter > >> Sent: Wednesday, May 20, 2020 11:26 AM > >> To: Alex Deucher ; Kevin Wang > >> ; Ruhl, Michael J > >>

Re: [PATCH 2/2] drm/amd/display: Enable fp16 also on DCE-11.0 - DCE-12.

On Wed, May 20, 2020 at 12:39 PM Harry Wentland wrote: > > On 2020-05-15 1:19 a.m., Mario Kleiner wrote: > > Testing on a Polaris11 gpu with DCE-11.2 suggests that it > > seems to work fine there, so optimistically enable it for > > DCE-11 and later. > > > > Signed-off-by: Mario Kleiner > > ---

Re: [PATCH] drm/amd/amdkfd: Fix large framesize for kfd_smi_ev_read()

On Wed, May 20, 2020 at 9:53 AM Aurabindo Pillai wrote: > > The buffer allocated is of 1024 bytes. Allocate this from > heap instead of stack. > > Also remove check for stack size since we're allocating from heap > > Signed-off-by: Aurabindo Pillai > Tested-by: Amber Lin Reviewed-by: Alex

Re: [PATCH 3/3] drm/amdgpu: add apu flags

On Wed, May 20, 2020 at 5:59 AM Christian König wrote: > > Am 18.05.20 um 16:06 schrieb Alex Deucher: > > On Mon, May 18, 2020 at 3:31 AM Christian König > > wrote: > >> Am 15.05.20 um 20:31 schrieb Alex Deucher: > >>> Add some APU flags to simplify handling of different APU > >>> variants.

Re: [PATCH] drm/amdgpu/smu10: Replace one-element array and use struct_size() helper

Applied. thanks! Alex On Wed, May 20, 2020 at 3:42 AM Christian König wrote: > > Am 20.05.20 um 00:55 schrieb Gustavo A. R. Silva: > > The current codebase makes use of one-element arrays in the following > > form: > > > > struct something { > > int length; > > u8 data[1]; > > }; > >

Re: [PATCH 2/2] drm/amd/display: Enable fp16 also on DCE-11.0 - DCE-12.

On 2020-05-15 1:19 a.m., Mario Kleiner wrote: > Testing on a Polaris11 gpu with DCE-11.2 suggests that it > seems to work fine there, so optimistically enable it for > DCE-11 and later. > > Signed-off-by: Mario Kleiner > --- > drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c | 2 +- >

Re: [RFC] Deprecate AGP GART support for Radeon/Nouveau/TTM

On 2020-05-20 4:43 p.m., Christian König wrote: > Am 13.05.20 um 13:03 schrieb Christian König: >> Unfortunately AGP is still to widely used as we could just drop >> support for using its GART. >> >> Not using the AGP GART also doesn't mean a loss in functionality since >> drivers will just

Re: [RFC] Deprecate AGP GART support for Radeon/Nouveau/TTM

On Wed, May 20, 2020 at 10:43 AM Christian König wrote: > > Am 13.05.20 um 13:03 schrieb Christian König: > > Unfortunately AGP is still to widely used as we could just drop support for > > using its GART. > > > > Not using the AGP GART also doesn't mean a loss in functionality since > >

Re: [RFC] Deprecate AGP GART support for Radeon/Nouveau/TTM

Hi, Christian, On Wed, 20 May 2020 at 16:00, Christian König wrote: > > So I've used an ancient system (32bit) to setup a test box for this. > > > The first GPU I could test is an RV280 (Radeon 9200 PRO) which is easily > 15 years old. Oh, I have one of those in box somewhere, but no AGP

Re: [PATCH] drm/amd/display: Handle GPU reset for DC block

On 2020-05-20 11:29 a.m., Bhawanpreet Lakha wrote: [Why] Previously we used the s3 codepath for gpu reset. This can lead to issues in certain case where we end of waiting for fences which will never come (because parts of the hw are off due to gpu reset) and we end up waiting forever causing a

Re: [PATCH v3] drm/amdgpu: off by one in amdgpu_device_attr_create_groups() error handling

Am 20.05.20 um 17:31 schrieb Ruhl, Michael J: -Original Message- From: Dan Carpenter Sent: Wednesday, May 20, 2020 11:26 AM To: Alex Deucher ; Kevin Wang ; Ruhl, Michael J Cc: Christian König ; David Airlie ; Daniel Vetter ; Evan Quan ; Rui Huang ; Kenneth Feng ; Yintian Tao ; Hawking

RE: [PATCH v3] drm/amdgpu: off by one in amdgpu_device_attr_create_groups() error handling

>-Original Message- >From: Dan Carpenter >Sent: Wednesday, May 20, 2020 11:26 AM >To: Alex Deucher ; Kevin Wang >; Ruhl, Michael J >Cc: Christian König ; David Airlie >; Daniel Vetter ; Evan Quan >; Rui Huang ; Kenneth Feng >; Yintian Tao ; Hawking Zhang >; amd-gfx@lists.freedesktop.org;

[PATCH] drm/amd/display: Handle GPU reset for DC block

[Why] Previously we used the s3 codepath for gpu reset. This can lead to issues in certain case where we end of waiting for fences which will never come (because parts of the hw are off due to gpu reset) and we end up waiting forever causing a deadlock. [How] Handle GPU reset separately from

[PATCH v3] drm/amdgpu: off by one in amdgpu_device_attr_create_groups() error handling

This loop in the error handling code should start a "i - 1" and end at "i == 0". Currently it starts a "i" and ends at "i == 1". The result is that it removes one attribute that wasn't created yet, and leaks the zeroeth attribute. Fixes: 4e01847c38f7 ("drm/amdgpu: optimize amdgpu device

RE: [PATCH v2] drm/amdgpu: off by on in amdgpu_device_attr_create_groups() error handling

"off by on" or "off by one" ? M >-Original Message- >From: dri-devel On Behalf Of Dan >Carpenter >Sent: Wednesday, May 20, 2020 9:08 AM >To: Alex Deucher ; Kevin Wang > >Cc: David Airlie ; kernel-janit...@vger.kernel.org; linux- >ker...@vger.kernel.org;

Re: [PATCH 2/2] drm/amd/display: Enable fp16 also on DCE-11.0 - DCE-12.

On 2020-05-15 1:19 a.m., Mario Kleiner wrote: Testing on a Polaris11 gpu with DCE-11.2 suggests that it seems to work fine there, so optimistically enable it for DCE-11 and later. Signed-off-by: Mario Kleiner Series is: Reviewed-by: Nicholas Kazlauskas Thanks! ---

Re: [PATCH] drm/amd/powerpay: Disable gfxoff when setting manual mode on picasso and raven

On Wed, May 20, 2020 at 4:32 AM chen gong wrote: > > [Problem description] > 1. Boot up picasso platform, launches desktop, Don't do anything (APU enter > into "gfxoff" state) > 2. Remote login to platform using SSH, then type the command line: >sudo su -c "echo manual > >

Re: [RFC] Deprecate AGP GART support for Radeon/Nouveau/TTM

Am 13.05.20 um 13:03 schrieb Christian König: Unfortunately AGP is still to widely used as we could just drop support for using its GART. Not using the AGP GART also doesn't mean a loss in functionality since drivers will just fallback to the driver specific PCI GART. For now just deprecate

[PATCH] drm/amd/amdkfd: Fix large framesize for kfd_smi_ev_read()

The buffer allocated is of 1024 bytes. Allocate this from heap instead of stack. Also remove check for stack size since we're allocating from heap Signed-off-by: Aurabindo Pillai Tested-by: Amber Lin --- drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c | 26 +++-- 1 file changed,

Re: [PATCH v2] drm/amdgpu: off by on in amdgpu_device_attr_create_groups() error handling

[AMD Official Use Only - Internal Distribution Only] thanks. Reviewed-by: Kevin Wang Best Regads, Kevin From: Dan Carpenter Sent: Wednesday, May 20, 2020 9:08 PM To: Deucher, Alexander ; Wang, Kevin(Yang) Cc: Koenig, Christian ; David Airlie ; Daniel Vetter

Re: [PATCH] drm/amd/powerplay: unify the prompts on thermal interrupts

On Wed, May 20, 2020 at 6:40 AM Evan Quan wrote: > > The prompts will contain pci address(segment/bus/port/function), > severity(warn or error) and some keywords(GPU, amdgpu). Also this > address the issue that pci bus retrieved by PCI_BUS_NUM(adev->pdev->devfn) > is wrong. > > Change-Id:

[PATCH v2] drm/amdgpu: off by on in amdgpu_device_attr_create_groups() error handling

This loop in the error handling code should start a "i - 1" and end at "i == 0". Currently it starts a "i" and ends at "i == 1". The result is that it removes one attribute that wasn't created yet, and leaks the zeroeth attribute. Fixes: 4e01847c38f7 ("drm/amdgpu: optimize amdgpu device

Re: [PATCH 1/2] drm/amd/powerplay: remove the support of xgmi pstate on vega20 from swsmu

[AMD Public Use] Series is: Reviewed-by: Alex Deucher From: Wang, Kevin(Yang) Sent: Tuesday, May 19, 2020 11:50 PM To: amd-gfx@lists.freedesktop.org Cc: Zhang, Hawking ; Deucher, Alexander ; Wang, Kevin(Yang) Subject: [PATCH 1/2] drm/amd/powerplay: remove the

Re: [PATCH] drm/amdgpu: off by on in amdgpu_device_attr_create_groups() error handling

On Wed, May 20, 2020 at 02:05:19PM +0200, Christian König wrote: > Am 20.05.20 um 14:00 schrieb Dan Carpenter: > > This loop in the error handling code should start a "i - 1" and end at > > "i == 0". Currently it starts a "i" and ends at "i == 1". The result > > is that it removes one attribute

Re: [PATCH] drm/amdgpu: off by on in amdgpu_device_attr_create_groups() error handling

Am 20.05.20 um 14:00 schrieb Dan Carpenter: This loop in the error handling code should start a "i - 1" and end at "i == 0". Currently it starts a "i" and ends at "i == 1". The result is that it removes one attribute that wasn't created yet, and leaks the zeroeth attribute. Fixes:

[PATCH] drm/amdgpu: off by on in amdgpu_device_attr_create_groups() error handling

This loop in the error handling code should start a "i - 1" and end at "i == 0". Currently it starts a "i" and ends at "i == 1". The result is that it removes one attribute that wasn't created yet, and leaks the zeroeth attribute. Fixes: 4e01847c38f7 ("drm/amdgpu: optimize amdgpu device

Re: [PATCH] dma-fence: add might_sleep annotation to _wait()

On Wed, May 20, 2020 at 08:54:36AM +0200, Christian König wrote: > Am 19.05.20 um 15:27 schrieb Daniel Vetter: > > Do it uncontionally, there's a separate peek function with > > dma_fence_is_signalled() which can be called from atomic context. > > > > v2: Consensus calls for an unconditional

Re: [PATCH v1 13/25] dma-buf: Use sequence counter with associated wound/wait mutex

Am 19.05.20 um 23:45 schrieb Ahmed S. Darwish: A sequence counter write side critical section must be protected by some form of locking to serialize writers. If the serialization primitive is not disabling preemption implicitly, preemption has to be explicitly disabled before entering the

[PATCH] drm/amd/powerplay: unify the prompts on thermal interrupts

The prompts will contain pci address(segment/bus/port/function), severity(warn or error) and some keywords(GPU, amdgpu). Also this address the issue that pci bus retrieved by PCI_BUS_NUM(adev->pdev->devfn) is wrong. Change-Id: I714d1dffb30a6cf76dcede087cf5d9302f683ed8 Signed-off-by: Evan Quan

Re: [PATCH 3/3] drm/amdgpu: add apu flags

Am 18.05.20 um 16:06 schrieb Alex Deucher: On Mon, May 18, 2020 at 3:31 AM Christian König wrote: Am 15.05.20 um 20:31 schrieb Alex Deucher: Add some APU flags to simplify handling of different APU variants. It's easier to understand the special cases if we use names flags rather than

[PATCH] drm/amd/powerpay: Disable gfxoff when setting manual mode on picasso and raven

[Problem description] 1. Boot up picasso platform, launches desktop, Don't do anything (APU enter into "gfxoff" state) 2. Remote login to platform using SSH, then type the command line: sudo su -c "echo manual > /sys/class/drm/card0/device/power_dpm_force_performance_level" sudo su -c

Re: [PATCH] drm/amdgpu/smu10: Replace one-element array and use struct_size() helper

Am 20.05.20 um 00:55 schrieb Gustavo A. R. Silva: The current codebase makes use of one-element arrays in the following form: struct something { int length; u8 data[1]; }; struct something *instance; instance = kmalloc(sizeof(*instance) + size, GFP_KERNEL); instance->length = size;

WARNINGs in amdgpu dcn20_hwseq.c:127 dcn20_setup_gsl_group_as_lock

Dear all (please cc) Hardware: Radeon RX 5700 XT, i7-6700K CPU Software: - kernel 5.7.0-rc5+ commit 12bf0b632ed09 - Debian/sid boot log lines kernel: [drm] initializing kernel modesetting (NAVI10 0x1002:0x731F 0x1462:0x3810 0xC1). kernel: [drm] register mmio base: 0xDFC0 kernel: [drm]

Re: [PATCH] dma-fence: add might_sleep annotation to _wait()

Am 19.05.20 um 15:27 schrieb Daniel Vetter: Do it uncontionally, there's a separate peek function with dma_fence_is_signalled() which can be called from atomic context. v2: Consensus calls for an unconditional might_sleep (Chris, Christian) Full audit: - dma-fence.h: Uses MAX_SCHEDULE_TIMOUT,