Re: [PATCH] drm/amdgpu: Move IH clientid defs to separate file

Am 09.03.2018 um 00:24 schrieb Oak Zeng: This is preparation for sharing client ID definitions between amdgpu and amdkfd Change-Id: Ie0b7b14c9c2366fd896745a51b74a9ba97ee3224 Signed-off-by: Oak Zeng --- drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h | 44 +--

Re: [PATCH 2/2] drm/amdgpu/soc15: always load the psp IP module

Hi Rex, I think still initializing the PSP even when you don't need it for firmware upload sounds like a good idea to me. But take that with a grain of salt since I really on don't know that part of the hardware so well. Christian. Am 09.03.2018 um 06:10 schrieb Zhu, Rex: Hi Alex, How

Re: deprecated register issues

That would be a possibility, but I don't think reading the register once during driver startup is a real issue. See you need to hammer on the problematic registers to trigger the misbehavior, e.g. not read it once or twice but thousands of times. Additional to that as I said before, VM

Re: [PATCH] drm/amdgpu: Move IH clientid defs to separate file

On 2018年03月09日 07:24, Oak Zeng wrote: This is preparation for sharing client ID definitions between amdgpu and amdkfd Change-Id: Ie0b7b14c9c2366fd896745a51b74a9ba97ee3224 Signed-off-by: Oak Zeng --- drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h | 44 +--

Re: [PATCH 2/2] drm/amdgpu/soc15: always load the psp IP module

Hi Alex, How about keep the firmware type checking in set_ip_blocks. and remove the same check code in psp module. also no need to change load type if psp load firmware failed in psp module. Please review the attached patch. Best Regards Rex From: amd-gfx

Re: [PATCH] drm/amdgpu: Move IH clientid defs to separate file

On Thu, Mar 8, 2018 at 11:26 PM, Alex Deucher wrote: > On Thu, Mar 8, 2018 at 6:24 PM, Oak Zeng wrote: >> This is preparation for sharing client ID definitions >> between amdgpu and amdkfd >> >> Change-Id: Ie0b7b14c9c2366fd896745a51b74a9ba97ee3224 >>

Re: [PATCH] drm/amdgpu: Remove some unused elements from amdgpu_connector struct

On Thu, Mar 8, 2018 at 8:45 PM, Harry Wentland wrote: > They were used by amdgpu_dm at some point but since it has its own > amdgpu_dm_connector now these aren't needed anymore. > > Signed-off-by: Harry Wentland Reviewed-by: Alex Deucher

Re: [PATCH] drm/amdgpu: Move IH clientid defs to separate file

On Thu, Mar 8, 2018 at 6:24 PM, Oak Zeng wrote: > This is preparation for sharing client ID definitions > between amdgpu and amdkfd > > Change-Id: Ie0b7b14c9c2366fd896745a51b74a9ba97ee3224 > Signed-off-by: Oak Zeng > --- >

[PATCH] drm/amdgpu: Move IH clientid defs to separate file

This is preparation for sharing client ID definitions between amdgpu and amdkfd Change-Id: Ie0b7b14c9c2366fd896745a51b74a9ba97ee3224 Signed-off-by: Oak Zeng --- drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h | 44 +--

Re: deprecated register issues

Can GIM read the value and pass it to the VF's via the vbios or the shared area? Alex From: Liu, Monk Sent: Thursday, March 8, 2018 9:59:34 PM To: Koenig, Christian; Deucher, Alexander; Mao, David Cc: Jin, Jian-Rong; amd-gfx@lists.freedesktop.org Subject: RE:

RE: deprecated register issues

> Although KMD now use a cache way to give libdrm the CC_RB_BACKEND_DISABLE > value, but KMD still need to read it at least one shot during loading driver > right ? Correct, but we do this while having exclusive access. The problem is although for VF0 it is reading this register in exclusive

[PATCH] drm/amdgpu: Remove some unused elements from amdgpu_connector struct

They were used by amdgpu_dm at some point but since it has its own amdgpu_dm_connector now these aren't needed anymore. Signed-off-by: Harry Wentland --- drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 29 - 1 file changed, 29 deletions(-) diff

[PATCH 1/2] drm/amdgpu/psp: add a few more fw load type checks

We already checked and returned early in most of the IP functions, fill in the rest as well. Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c

[PATCH 2/2] drm/amdgpu/soc15: always load the psp IP module

We already handle the firmware loading type checks in the psp module directly, no need for an additional check. Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/soc15.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git

[PATCH] drm/amdgpu: save/restore backlight level in legacy dce code

Save/restore the backlight level scratch register in S3/S4 so the backlight level comes back at the previously requested level. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=199047 Fixes: 4ec6ecf48c64d (drm/amdgpu: drop scratch regs save and restore from S3/S4 handling) Signed-off-by: Alex

Re: [PATCH libdrm] amdgpu:support 16 ibs per submit for PAL/SRIOV

On Thu, Mar 8, 2018 at 12:31 PM, Marek Olšák wrote: > From: Qiang Yu > > to support SRIOV and MCBP, need 16 IBs per submit > > Signed-off-by: Qiang Yu > Reviewed-by: Junwei Zhang Reviewed-by: Alex Deucher

Re: [PATCH libdrm] amdgpu:support 16 ibs per submit for PAL/SRIOV

Am 08.03.2018 um 18:31 schrieb Marek Olšák: From: Qiang Yu to support SRIOV and MCBP, need 16 IBs per submit Signed-off-by: Qiang Yu Reviewed-by: Junwei Zhang Acked-by: Christian König ---

[PATCH xf86-video-amdgpu] Pass extents to amdgpu_scanout_do_update by value

From: Michel Dänzer amdgpu_scanout_extents_intersect could leave the scanout damage region in an invalid state, triggering debugging checks in pixman: *** BUG *** In pixman_region_append_non_o: The expression r->x1 < r->x2 was false Set a breakpoint on

[PATCH libdrm] amdgpu:support 16 ibs per submit for PAL/SRIOV

From: Qiang Yu to support SRIOV and MCBP, need 16 IBs per submit Signed-off-by: Qiang Yu Reviewed-by: Junwei Zhang --- amdgpu/amdgpu.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/amdgpu/amdgpu.h

Re: [PATCH xf86-video-ati] Only change Set/MoveCursor hooks from what we expect

On 2018-03-07 10:33 AM, Mario Kleiner wrote: > On 03/07/2018 09:50 AM, Michel Dänzer wrote: >> On 2018-03-07 04:45 AM, Mario Kleiner wrote: >>> On 03/05/2018 10:56 PM, Alex Deucher wrote: On Mon, Mar 5, 2018 at 12:44 PM, Michel Dänzer wrote: > From: Michel Dänzer

Re: Ryzen 5 2400g - colors/contrast messed up on amd-staging-drm-next and drm-next-4.17-wip

+ Harry, Leo I saw this as well with tonga. It seems to be related to the CTM/regamma changes. Alex From: amd-gfx on behalf of Hubert Łępicki Sent: Thursday, March 8, 2018 7:03:06 AM To:

Ryzen 5 2400g - colors/contrast messed up on amd-staging-drm-next and drm-next-4.17-wip

Hey, I was giving a shot your work in progress branch for the AMDGPU driver, hoping maybe it brings some fixes to Ryzen 5 2400g. It does not look like it, but I might have discovered a bug (or you may be well aware of it since it's work in progress...). Either way, just to let you know: Graphics

Re: [PATCH] drm/amdgpu: query vram type from atombios

On Thu, Mar 8, 2018 at 5:02 AM, Hawking Zhang wrote: > The vram type for dGPU is stored in umc_info while sys mem type > for APU is stored in integratedsysteminfo > > Change-Id: Iec14a0cac407f3da37245786c8f1b688968f8726 > Signed-off-by: Hawking Zhang

Re: [PATCH 4/8] drm/amd/pp: Clean up the code for RV in powerplay

On Wed, Mar 7, 2018 at 11:42 PM, Zhu, Rex wrote: >>Is this consistent with our other smu implementations? If we never use the >>errors, I'm ok with removing them, but I don't want to have to add them again >>later if we decide we >>actually need them. > > Rex: until

Re: deprecated register issues

Although KMD now use a cache way to give libdrm the CC_RB_BACKEND_DISABLE value, but KMD still need to read it at least one shot during loading driver right ? Correct, but we do this while having exclusive access. Not only tlb flush, other ring’s vm flush of VF2 can all be ruined by this

RE: deprecated register issues

To be more specific let me give you an example we face with now: Although KMD now use a cache way to give libdrm the CC_RB_BACKEND_DISABLE value, but KMD still need to read it at least one shot during loading driver right ? For SR-IOV there is still chance that VF2 is doing CPU based tlb flush

RE: deprecated register issues

Yeah, I agree with you we’d better find all those registers Stitch together the REQ and ACK part only avoid this issue for vm flush only, and we may still hit the issue in other place, I knew it. The frustrating job is how can we find all those registers ? And more is since this

[PATCH] drm/amdgpu: query vram type from atombios

The vram type for dGPU is stored in umc_info while sys mem type for APU is stored in integratedsysteminfo Change-Id: Iec14a0cac407f3da37245786c8f1b688968f8726 Signed-off-by: Hawking Zhang --- drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c | 95 +++-

RE: [PATCH] drm/amdgpu: query vram type from atombios

Please ignore this patch since it doesn't sync up to the latest code base. I will re-send another review later Regards, Hawking -Original Message- From: Hawking Zhang Sent: 2018年3月8日 17:37 To: amd-gfx@lists.freedesktop.org Cc: Zhang, Hawking

Re: deprecated register issues

Hi Monk, While we can avoid such vm flush failure by stitch together of the sending REQ and reading ACK part, at least for compute ring this is confirmed. Well there are two misunderstanding here. First of all this solution doesn't really work, it just hides the problem because we don't do

[PATCH] drm/amdgpu: query vram type from atombios

The vram type info for dGPU is saved in umc_info while sys mem type info for APU is saved in integratedsysteminfo Change-Id: I08b84c65e4e31c65e2e5a277a1acdf032ec04d2e Signed-off-by: Hawking Zhang --- drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c | 95

Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

Am 08.03.2018 um 09:35 schrieb Michel Dänzer: On 2018-03-07 10:47 AM, Christian König wrote: Am 07.03.2018 um 09:42 schrieb Michel Dänzer: On 2018-03-06 07:23 PM, Christian König wrote: E.g. the last time I tested it placing things into GTT still resulted in quite a performance penalty for

Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

On 2018-03-07 10:47 AM, Christian König wrote: > Am 07.03.2018 um 09:42 schrieb Michel Dänzer: >> On 2018-03-06 07:23 PM, Christian König wrote: >> >>> E.g. the last time I tested it placing things into GTT still resulted >>> in quite a performance penalty for rendering. >> FWIW, I think the