from:"Dieter Nützel"

Re: [Mesa-dev] [PATCH] drm/radeon: Fix vram_size/visible values in DRM_RADEON_GEM_INFO ioctl

2017-01-31 Thread Dieter Nützel


Hello Michel,

as this is for radeon, do you think this could/should fix
the wrong reported VRAM size with Unigine_Heaven/-Valley, too?
Maybe speed things up? ;-)

Unigine_Valley-1.0

GPU: Unknown GPU x1
System memory: 24102 MB
Video memory:  256 MB
Sync threads:  7
Async threads: 8

I'll try patching openSUSE Kernel:stable 4.9.6-2 with this
and maybe this could then go into 4.10-rc7 'cause it is a
bugfix. - Alex?

Greetings,
Dieter

Am 31.01.2017 07:54, schrieb Michel Dänzer:

From: Michel Dänzer 

vram_size is supposed to be the total amount of VRAM that can be used 
by

userspace, which corresponds to the TTM VRAM manager size (which is
normally the full amount of VRAM, but can be just the visible VRAM when
DMA can't be used for BO migration for some reason).

The above was incorrectly used for vram_visible before, resulting in
generally too large values being reported.

Signed-off-by: Michel Dänzer 
---
 drivers/gpu/drm/radeon/radeon_drv.c | 3 ++-
 drivers/gpu/drm/radeon/radeon_gem.c | 4 ++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index a252bc407aa2..88c41d43ec3d 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -97,9 +97,10 @@
  *   2.46.0 - Add PFP_SYNC_ME support on evergreen
  *   2.47.0 - Add UVD_NO_OP register support
  *   2.48.0 - TA_CS_BC_BASE_ADDR allowed on SI
+ *   2.49.0 - DRM_RADEON_GEM_INFO ioctl returns correct
vram_size/visible values
  */
 #define KMS_DRIVER_MAJOR   2
-#define KMS_DRIVER_MINOR   48
+#define KMS_DRIVER_MINOR   49
 #define KMS_DRIVER_PATCHLEVEL  0
 int radeon_driver_load_kms(struct drm_device *dev, unsigned long 
flags);

 int radeon_driver_unload_kms(struct drm_device *dev);
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index 0bcffd8a7bd3..96683f5b2b1b 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -220,8 +220,8 @@ int radeon_gem_info_ioctl(struct drm_device *dev,
void *data,

man = >mman.bdev.man[TTM_PL_VRAM];

-   args->vram_size = rdev->mc.real_vram_size;
-   args->vram_visible = (u64)man->size << PAGE_SHIFT;
+   args->vram_size = (u64)man->size << PAGE_SHIFT;
+   args->vram_visible = rdev->mc.visible_vram_size;
args->vram_visible -= rdev->vram_pin_size;
args->gart_size = rdev->mc.gtt_size;
args->gart_size -= rdev->gart_pin_size;

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [Mesa-dev] [PATCH] drm/radeon: Fix vram_size/visible values in DRM_RADEON_GEM_INFO ioctl

2017-01-31 Thread Dieter Nützel


Am 31.01.2017 16:43, schrieb Deucher, Alexander:

-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
Of Dieter Nützel
Sent: Tuesday, January 31, 2017 6:25 AM
To: Michel Dänzer
Cc: Alex Deucher; mesa-...@lists.freedesktop.org; amd-
g...@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH] drm/radeon: Fix vram_size/visible 
values in

DRM_RADEON_GEM_INFO ioctl

Hello Michel,

as this is for radeon, do you think this could/should fix
the wrong reported VRAM size with Unigine_Heaven/-Valley, too?
Maybe speed things up? ;-)

Unigine_Valley-1.0

GPU: Unknown GPU x1
System memory: 24102 MB
Video memory:  256 MB
Sync threads:  7
Async threads: 8

I'll try patching openSUSE Kernel:stable 4.9.6-2 with this
and maybe this could then go into 4.10-rc7 'cause it is a
bugfix. - Alex?


This patch just fixes the case of the HUD reporting the wrong amount
of visible vram.  Most 3D apps just default to 256MB if they don't
know how much vram is.  The problem is GL never provided a core way to
determine how much vram is available on a GPU so lots of vendor
specific extensions and driver specific methods popped up to address
this.

Alex


Ah, no hurry then.

Thanks for clarification.

Dieter


Greetings,
Dieter

Am 31.01.2017 07:54, schrieb Michel Dänzer:
> From: Michel Dänzer <michel.daen...@amd.com>
>
> vram_size is supposed to be the total amount of VRAM that can be used
> by
> userspace, which corresponds to the TTM VRAM manager size (which is
> normally the full amount of VRAM, but can be just the visible VRAM when
> DMA can't be used for BO migration for some reason).
>
> The above was incorrectly used for vram_visible before, resulting in
> generally too large values being reported.
>
> Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
> ---
>  drivers/gpu/drm/radeon/radeon_drv.c | 3 ++-
>  drivers/gpu/drm/radeon/radeon_gem.c | 4 ++--
>  2 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
> b/drivers/gpu/drm/radeon/radeon_drv.c
> index a252bc407aa2..88c41d43ec3d 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> @@ -97,9 +97,10 @@
>   *   2.46.0 - Add PFP_SYNC_ME support on evergreen
>   *   2.47.0 - Add UVD_NO_OP register support
>   *   2.48.0 - TA_CS_BC_BASE_ADDR allowed on SI
> + *   2.49.0 - DRM_RADEON_GEM_INFO ioctl returns correct
> vram_size/visible values
>   */
>  #define KMS_DRIVER_MAJOR  2
> -#define KMS_DRIVER_MINOR  48
> +#define KMS_DRIVER_MINOR  49
>  #define KMS_DRIVER_PATCHLEVEL 0
>  int radeon_driver_load_kms(struct drm_device *dev, unsigned long
> flags);
>  int radeon_driver_unload_kms(struct drm_device *dev);
> diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
> b/drivers/gpu/drm/radeon/radeon_gem.c
> index 0bcffd8a7bd3..96683f5b2b1b 100644
> --- a/drivers/gpu/drm/radeon/radeon_gem.c
> +++ b/drivers/gpu/drm/radeon/radeon_gem.c
> @@ -220,8 +220,8 @@ int radeon_gem_info_ioctl(struct drm_device *dev,
> void *data,
>
>man = >mman.bdev.man[TTM_PL_VRAM];
>
> -  args->vram_size = rdev->mc.real_vram_size;
> -  args->vram_visible = (u64)man->size << PAGE_SHIFT;
> +  args->vram_size = (u64)man->size << PAGE_SHIFT;
> +  args->vram_visible = rdev->mc.visible_vram_size;
>args->vram_visible -= rdev->vram_pin_size;
>args->gart_size = rdev->mc.gtt_size;
>args->gart_size -= rdev->gart_pin_size;
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: Resizeable PCI BAR support V5

2017-06-29 Thread Dieter Nützel


Hello Christian,

I've running this since you've sent it on-top of amd-staging-4.11. But I 
think my poor little FUJITSU PRIMERGY TX150 S7, Xeon X3470 (Nehalem), 
PCIe 2.0, 24 GB is to old for this stuff...


[1.066475] pci :05:00.0: VF(n) BAR0 space: [mem 
0x-0x0003 64bit] (contains BAR0 for 16 VFs)
[1.066489] pci :05:00.0: VF(n) BAR2 space: [mem 
0x-0x003f 64bit] (contains BAR2 for 16 VFs)
[1.121656] pci :00:1c.0: BAR 15: assigned [mem 
0x8000-0x801f 64bit pref]
[1.121659] pci :00:1c.6: BAR 15: assigned [mem 
0x8020-0x803f 64bit pref]
[1.121662] pci :01:00.0: BAR 6: assigned [mem 
0xb012-0xb013 pref]
[1.121681] pci :05:00.0: BAR 6: assigned [mem 
0xb028-0xb02f pref]
[1.121683] pci :05:00.0: BAR 9: no space for [mem size 
0x0040 64bit]
[1.121684] pci :05:00.0: BAR 9: failed to assign [mem size 
0x0040 64bit]
[1.121685] pci :05:00.0: BAR 7: no space for [mem size 
0x0004 64bit]
[1.121687] pci :05:00.0: BAR 7: failed to assign [mem size 
0x0004 64bit]
[3.874180] amdgpu :01:00.0: BAR 0: releasing [mem 
0xc000-0xcfff 64bit pref]
[3.874182] amdgpu :01:00.0: BAR 2: releasing [mem 
0xb040-0xb05f 64bit pref]
[3.874198] pcieport :00:03.0: BAR 15: releasing [mem 
0xb040-0xcfff 64bit pref]
[3.874215] pcieport :00:03.0: BAR 15: no space for [mem size 
0x3 64bit pref]
[3.874217] pcieport :00:03.0: BAR 15: failed to assign [mem size 
0x3 64bit pref]
[3.874221] amdgpu :01:00.0: BAR 0: no space for [mem size 
0x2 64bit pref]
[3.874223] amdgpu :01:00.0: BAR 0: failed to assign [mem size 
0x2 64bit pref]
[3.874226] amdgpu :01:00.0: BAR 2: no space for [mem size 
0x0020 64bit pref]
[3.874227] amdgpu :01:00.0: BAR 2: failed to assign [mem size 
0x0020 64bit pref]

[3.874258] [drm] Not enough PCI address space for a large BAR.
[3.874261] amdgpu :01:00.0: BAR 0: assigned [mem 
0xc000-0xcfff 64bit pref]
[3.874269] amdgpu :01:00.0: BAR 2: assigned [mem 
0xb040-0xb05f 64bit pref]

[3.874288] [drm] Detected VRAM RAM=8192M, BAR=256M

Anyway rebase for current amd-staging-4.11 needed.
Find attached dmesg-amd-staging-4.11-1.g7262353-default+.log.xz

Greetings,
Dieter

Am 09.06.2017 10:59, schrieb Christian König:

Hi everyone,

This is the fith incarnation of this set of patches. It enables device
drivers to resize and most likely also relocate the PCI BAR of devices
they manage to allow the CPU to access all of the device local memory 
at once.


This is very useful for GFX device drivers where the default PCI BAR is 
only
about 256MB in size for compatibility reasons, but the device easily 
have

multiple gigabyte of local memory.

Some changes since V4:
1. Rebased on 4.11.
2. added the rb from Andy Shevchenko to patches which look complete 
now.
3. Move releasing the BAR and reallocating it on error to the driver 
side.

4. Add amdgpu support for GMC V6 hardware generation as well.

Please review and/or comment,
Christian.

___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

dmesg-amd-staging-4.11-1.g7262353-default+.log.xz
Description: application/xz
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: Resizeable PCI BAR support V5

2017-08-06 Thread Dieter Nützel


Hello Christian,

after (long ;-)) vacation, injured wife (bad lumbago/luckily NO disc 
prolapse) on 2cond day @ our target, our daughter's 12th birthday, 
school start for both kids and mostly dad work I'm back...


Do you have a V6 handy.
Will do my fingers dirty if no Intel guy beats me at it.

Greetings,
Dieter

Am 30.06.2017 14:55, schrieb Christian König:

Hi Dieter,

thanks a lot for testing that.

But I think my poor little FUJITSU PRIMERGY TX150 S7, Xeon X3470 
(Nehalem), PCIe 2.0, 24 GB is to old for this stuff...

Well, actually you only need to figure out how to enable a PCIe window
above the 4GB limit.

Could be that the BIOS supports this with the ACPI tables (totally
unlikely) or you could try to dig up the Northbridge documentation for
this CPU from Intel and use my patch for the AMD CPUs as blueprint how
to do this on an Intel CPU as well.

Fact is you GFX hardware is perfectly capable of doing this, it's just
that the BIOS/Motherboard didn't enabled a PCIe window per default to
avoid problems with 32bit OSes.

Regards,
Christian.

Am 30.06.2017 um 01:51 schrieb Dieter Nützel:

Hello Christian,

I've running this since you've sent it on-top of amd-staging-4.11. But 
I think my poor little FUJITSU PRIMERGY TX150 S7, Xeon X3470 
(Nehalem), PCIe 2.0, 24 GB is to old for this stuff...


[1.066475] pci :05:00.0: VF(n) BAR0 space: [mem 
0x-0x0003 64bit] (contains BAR0 for 16 VFs)
[1.066489] pci :05:00.0: VF(n) BAR2 space: [mem 
0x-0x003f 64bit] (contains BAR2 for 16 VFs)
[1.121656] pci :00:1c.0: BAR 15: assigned [mem 
0x8000-0x801f 64bit pref]
[1.121659] pci :00:1c.6: BAR 15: assigned [mem 
0x8020-0x803f 64bit pref]
[1.121662] pci :01:00.0: BAR 6: assigned [mem 
0xb012-0xb013 pref]
[1.121681] pci :05:00.0: BAR 6: assigned [mem 
0xb028-0xb02f pref]
[1.121683] pci :05:00.0: BAR 9: no space for [mem size 
0x0040 64bit]
[1.121684] pci :05:00.0: BAR 9: failed to assign [mem size 
0x0040 64bit]
[1.121685] pci :05:00.0: BAR 7: no space for [mem size 
0x0004 64bit]
[1.121687] pci :05:00.0: BAR 7: failed to assign [mem size 
0x0004 64bit]
[3.874180] amdgpu :01:00.0: BAR 0: releasing [mem 
0xc000-0xcfff 64bit pref]
[3.874182] amdgpu :01:00.0: BAR 2: releasing [mem 
0xb040-0xb05f 64bit pref]
[3.874198] pcieport :00:03.0: BAR 15: releasing [mem 
0xb040-0xcfff 64bit pref]
[3.874215] pcieport :00:03.0: BAR 15: no space for [mem size 
0x3 64bit pref]
[3.874217] pcieport :00:03.0: BAR 15: failed to assign [mem 
size 0x3 64bit pref]
[3.874221] amdgpu :01:00.0: BAR 0: no space for [mem size 
0x2 64bit pref]
[3.874223] amdgpu :01:00.0: BAR 0: failed to assign [mem size 
0x2 64bit pref]
[3.874226] amdgpu :01:00.0: BAR 2: no space for [mem size 
0x0020 64bit pref]
[3.874227] amdgpu :01:00.0: BAR 2: failed to assign [mem size 
0x0020 64bit pref]

[3.874258] [drm] Not enough PCI address space for a large BAR.
[3.874261] amdgpu :01:00.0: BAR 0: assigned [mem 
0xc000-0xcfff 64bit pref]
[3.874269] amdgpu :01:00.0: BAR 2: assigned [mem 
0xb040-0xb05f 64bit pref]

[3.874288] [drm] Detected VRAM RAM=8192M, BAR=256M

Anyway rebase for current amd-staging-4.11 needed.
Find attached dmesg-amd-staging-4.11-1.g7262353-default+.log.xz

Greetings,
Dieter

Am 09.06.2017 10:59, schrieb Christian König:

Hi everyone,

This is the fith incarnation of this set of patches. It enables 
device
drivers to resize and most likely also relocate the PCI BAR of 
devices
they manage to allow the CPU to access all of the device local memory 
at once.


This is very useful for GFX device drivers where the default PCI BAR 
is only
about 256MB in size for compatibility reasons, but the device easily 
have

multiple gigabyte of local memory.

Some changes since V4:
1. Rebased on 4.11.
2. added the rb from Andy Shevchenko to patches which look complete 
now.
3. Move releasing the BAR and reallocating it on error to the driver 
side.

4. Add amdgpu support for GMC V6 hardware generation as well.

Please review and/or comment,
Christian.

___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amd/display: Fix non-DCN build

2017-10-13 Thread Dieter Nützel


Am 13.10.2017 18:44, schrieb Harry Wentland:

Acquire_first_split_pipe only makes sense for DCN.

Signed-off-by: Harry Wentland <harry.wentl...@amd.com>


Tested-by: Dieter Nützel <die...@nuetzel-hh.de>


---
 drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
index 2a5c91772473..55feb16b1fd7 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
@@ -1684,8 +1684,10 @@ enum dc_status resource_map_pool_resources(
/* acquire new resources */
pipe_idx = acquire_first_free_pipe(>res_ctx, pool, stream);

+#ifdef CONFIG_DRM_AMD_DC_DCN1_0
if (pipe_idx < 0)
 		pipe_idx = acquire_first_split_pipe(>res_ctx, pool, 
stream);

+#endif

if (pipe_idx < 0)
return DC_NO_CONTROLLER_RESOURCE;

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [amd-staging-drm-next] compilation error with latest commit #1b006d838f78

2017-10-13 Thread Dieter Nützel


Am 13.10.2017 21:22, schrieb Harry Wentland:

On 2017-10-12 08:22 PM, Dieter Nützel wrote:

Hello,

next (regression) compilation error:

drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c: In 
function ‘resource_map_pool_resources’:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1688:14: 
error: implicit declaration of function ‘acquire_first_split_pipe’; 
did you mean ‘acquire_first_free_pipe’? 
[-Werror=implicit-function-declaration]
   pipe_idx = acquire_first_split_pipe(>res_ctx, pool, 
stream);

  ^~~~
  acquire_first_free_pipe


It is wrongly (?) guarded behind:

#if defined(CONFIG_DRM_AMD_DC_DCN1_0)
static int acquire_first_split_pipe(
    struct resource_context *res_ctx,
    const struct resource_pool *pool,
    struct dc_stream_state *stream)
[snip]



Sent and merged a patch. This function only makes sense for DCN and 
shouldn't
be called otherwise. Thanks for reporting this. I gotta make sure to 
build

without the DCN flag in the future to avoid this.


Hello Harry,

I've included it by hand and tested it with and without
CONFIG_DRM_AMD_DC_FBC (and already send my t-b).

The sad thing is, that latest amd-staging-drm-next (#1c630e83443a) do 
NOT come back from screen blanking (KDE screen saver, blank after x 
minutes) any longer.

I have to reboot. Nothing in the logs.

Apart from this '[amd-staging-drm-next] regression - no fan info 
(sensors) on RX580' still stands.

https://lists.freedesktop.org/archives/amd-gfx/2017-October/014065.html

Last thing:
'amd-staging-drm-next' is still based on 4.13.0-rc5.
Could it be 'updated' (rebased) on 4.13.4+ at least?
Since 4.12-rc there seems to be an e1000 issue in the Linux kernel tree, 
which is fixed for my Fujitsu workstation with 4.13.4+, but not with 
'amd-staging-drm-next'.

Or should I switch to 'drm-next-4.15[-dc]-wip'?

Thank you for GREAT OSS gfx-support from AMD!

Dieter



Harry


Thanks,
Dieter

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[amd-staging-drm-next] regression - no fan info (sensors) on RX580

2017-09-29 Thread Dieter Nützel


Hello all,

since latest update

1d7da702e70d3c27408a3bb312c71d6be9f7bebe
drm/amd/powerplay: fix spelling mistake: "dividable" -> "divisible"

I didn't get fan info with my RX580 (Polaris21) any longer.

Worked with this commit:

786df0b89fe5a0b405d4de0a1ce03003c0743ec3
drm/amd/display: fix pflip irq registor for raven

Sorry, I do not have full time for bisect, because we are on way to our 
vacation.


Maybe in the evening (only a few commits).

Greetings,
Dieter
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [amd-staging-drm-next] regression - no fan info (sensors) on RX580

2017-10-08 Thread Dieter Nützel


Sorry Rex,

after return from our vacation,
I've tested latest amd-staging-drm-next (e5f6a57e350a)
but it is NOT solved on my RX580.
I'll try bisecting if I find some more time in the coming days.

amdgpu-pci-0100
Adapter: PCI adapter
temp1:+27.0°C  (crit =  +0.0°C, hyst =  +0.0°C)

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. 
[AMD/ATI] Ellesmere [Radeon RX 470/480/570/580] (rev e7) (prog-if 00 
[VGA controller])

Subsystem: Sapphire Technology Limited Radeon RX 570

[36.740] (--) AMDGPU(0): Chipset: "Radeon RX 580 Series" (ChipID = 
0x67df)


Thanks,
Dieter

Am 30.09.2017 05:09, schrieb Zhu, Rex:

Yes, caused by the commit e37a7b4088da
("drm/amd/powerplay: tidy up ret checks in amd_powerplay.c")

Replace error when split patches.

Have sent the fix patch.
Please review.

Best Regards
Rex


-Original Message-
From: Alex Deucher [mailto:alexdeuc...@gmail.com]
Sent: Friday, September 29, 2017 10:11 PM
To: Dieter Nützel; Zhu, Rex
Cc: amd-devel; DRI Devel; Wentland, Harry; Michel Dänzer
Subject: Re: [amd-staging-drm-next] regression - no fan info (sensors) 
on RX580


Rex, probably related to the recent cleanups in powerplay.

On Fri, Sep 29, 2017 at 10:09 AM, Dieter Nützel <die...@nuetzel-hh.de> 
wrote:

Hello all,

since latest update

1d7da702e70d3c27408a3bb312c71d6be9f7bebe
drm/amd/powerplay: fix spelling mistake: "dividable" -> "divisible"

I didn't get fan info with my RX580 (Polaris21) any longer.

Worked with this commit:

786df0b89fe5a0b405d4de0a1ce03003c0743ec3
drm/amd/display: fix pflip irq registor for raven

Sorry, I do not have full time for bisect, because we are on way to
our vacation.

Maybe in the evening (only a few commits).

Greetings,
Dieter

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [amd-staging-drm-next] regression - no fan info (sensors) on RX580

2017-10-08 Thread Dieter Nützel


OK, got it but can't revert the commit clean.

amdgpu-pci-0100
Adapter: PCI adapter
fan1: 873 RPM
temp1:+26.0°C  (crit =  +0.0°C, hyst =  +0.0°C)

SOURCE/amd-staging-drm-next> git bisect good
0944c350c8eddf4064e7abb881dd245032fdfa23 is the first bad commit
commit 0944c350c8eddf4064e7abb881dd245032fdfa23
Author: Rex Zhu <rex@amd.com>
Date:   Mon Sep 25 18:51:50 2017 +0800

drm/amdgpu: delete pp_enable in adev

amdgpu not care powerplay or dpm is enabled.
just check ip functions and pp functions

Change-Id: Iaac75d45170ef9b20e212465f837eaaa798365bd
Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>
Signed-off-by: Rex Zhu <rex@amd.com>

:04 04 72361654709479890586e383ec73088e535a1cf5 
2b6d5a75ffc3b6fd48c63e79bf28faddcc734918 M drivers


Greetings,
Dieter


Am 09.10.2017 02:19, schrieb Dieter Nützel:

Sorry Rex,

after return from our vacation,
I've tested latest amd-staging-drm-next (e5f6a57e350a)
but it is NOT solved on my RX580.
I'll try bisecting if I find some more time in the coming days.

amdgpu-pci-0100
Adapter: PCI adapter
temp1:+27.0°C  (crit =  +0.0°C, hyst =  +0.0°C)

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
[AMD/ATI] Ellesmere [Radeon RX 470/480/570/580] (rev e7) (prog-if 00
[VGA controller])
Subsystem: Sapphire Technology Limited Radeon RX 570

[36.740] (--) AMDGPU(0): Chipset: "Radeon RX 580 Series" (ChipID = 
0x67df)


Thanks,
Dieter

Am 30.09.2017 05:09, schrieb Zhu, Rex:

Yes, caused by the commit e37a7b4088da
("drm/amd/powerplay: tidy up ret checks in amd_powerplay.c")

Replace error when split patches.

Have sent the fix patch.
Please review.

Best Regards
Rex


-Original Message-
From: Alex Deucher [mailto:alexdeuc...@gmail.com]
Sent: Friday, September 29, 2017 10:11 PM
To: Dieter Nützel; Zhu, Rex
Cc: amd-devel; DRI Devel; Wentland, Harry; Michel Dänzer
Subject: Re: [amd-staging-drm-next] regression - no fan info (sensors) 
on RX580


Rex, probably related to the recent cleanups in powerplay.

On Fri, Sep 29, 2017 at 10:09 AM, Dieter Nützel <die...@nuetzel-hh.de> 
wrote:

Hello all,

since latest update

1d7da702e70d3c27408a3bb312c71d6be9f7bebe
drm/amd/powerplay: fix spelling mistake: "dividable" -> "divisible"

I didn't get fan info with my RX580 (Polaris21) any longer.

Worked with this commit:

786df0b89fe5a0b405d4de0a1ce03003c0743ec3
drm/amd/display: fix pflip irq registor for raven

Sorry, I do not have full time for bisect, because we are on way to
our vacation.

Maybe in the evening (only a few commits).

Greetings,
Dieter

___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[amd-staging-drm-next] compilation error with latest commit #1b006d838f78

2017-10-12 Thread Dieter Nützel


Hello,

next (regression) compilation error:

drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c: In function 
‘resource_map_pool_resources’:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1688:14: 
error: implicit declaration of function ‘acquire_first_split_pipe’; did 
you mean ‘acquire_first_free_pipe’? 
[-Werror=implicit-function-declaration]

   pipe_idx = acquire_first_split_pipe(>res_ctx, pool, stream);
  ^~~~
  acquire_first_free_pipe


It is wrongly (?) guarded behind:

#if defined(CONFIG_DRM_AMD_DC_DCN1_0)
static int acquire_first_split_pipe(
struct resource_context *res_ctx,
const struct resource_pool *pool,
struct dc_stream_state *stream)
[snip]

Thanks,
Dieter
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: Operation context for TTM

2017-11-20 Thread Dieter Nützel


Hello Christian,

your latest 'amd-staging-drm-next' commit
drm/amdgpu: fix VCE buffer placement restrictions v2
#9f896d936c9d4ea936a02d52eaeb14fdd209193b

static int amdgpu_vce_validate_bo(struct amdgpu_cs_parser *p, uint32_t 
ib_idx,

  int lo, int hi, unsigned size, int32_t index)

[-]

return ttm_bo_validate(>tbo, >placement, false, false);

^^
'ttm_bo_validate' with 4 than 3 parameter clash.

drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c: In function 
‘amdgpu_vce_validate_bo’:
drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c:590:9: error: too many arguments 
to function ‘ttm_bo_validate’

  return ttm_bo_validate(>tbo, >placement, false, false);
 ^~~
In file included from drivers/gpu/drm/amd/amdgpu/amdgpu.h:39:0,
 from drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c:33:
./include/drm/ttm/ttm_bo_api.h:334:5: note: declared here
 int ttm_bo_validate(struct ttm_buffer_object *bo,
 ^~~

New version comming?

Thanks,
Dieter


Am 20.11.2017 05:35, schrieb Dieter Nützel:

For the series:

Tested-by: Dieter Nützel <die...@nuetzel-hh.de>

on RX580
amd-staging-drm-next 85d09ce5e5039644487e9508d6359f9f4cf64427

with glmark2, DiRT Rally and F1 2017 (radv)

Dieter

Am 17.11.2017 11:49, schrieb Christian König:

Hi everyone,

Michel already reviewed this back in April, but I didn't found time to
actually fully test it before now.

So sending this one out once more because it's an interface change
which affects all driver using TTM.

Please review and/or comment.

Regards,
Christian.

___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu: don't skip attributes when powerplay is enabled

2017-11-20 Thread Dieter Nützel


Am 20.11.2017 23:57, schrieb Alex Deucher:

The function checks non-powerplay structures so regressed when
the pp_enabled check was removed.  This should ideally be
implemented similarly for powerplay.

Fixes: 6d07fe7bcae57 ("drm/amdgpu: delete pp_enable in adev")
Signed-off-by: Alex Deucher 


Tested-by: Dieter Nützel <die...@nuetzel-hh.de>

against 'amd-staging-drm-next' on RX580


---
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c

index 3506758349dc..6f56ff606e43 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
@@ -945,6 +945,10 @@ static umode_t hwmon_attributes_visible(struct 
kobject *kobj,

struct amdgpu_device *adev = dev_get_drvdata(dev);
umode_t effective_mode = attr->mode;

+   /* no skipping for powerplay */
+   if (adev->powerplay.cgs_device)
+   return effective_mode;
+
/* Skip limit attributes if DPM is not enabled */
if (!adev->pm.dpm_enabled &&
(attr == _dev_attr_temp1_crit.dev_attr.attr ||

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [amd-staging-drm-next] regression - no fan info (sensors) on RX580

2017-11-20 Thread Dieter Nützel


That did it.

a716d5540346 (HEAD -> amd-staging-drm-next) drm/amdgpu: don't skip 
attributes when powerplay is enabled
9f896d936c9d (origin/amd-staging-drm-next) drm/amdgpu: fix VCE buffer 
placement restrictions v2

ca9b5d953735 drm/amdgpu: align GTT start to 4GB v2
52364b9f0226 drm/amdgpu: remove VRAM size reduction v2
95d8c587cba5 drm/amd/pp: fix typecast error in powerplay.
[-]

amdgpu-pci-0100
Adapter: PCI adapter
fan1: 881 RPM
temp1:+29.0°C  (crit =  +0.0°C, hyst =  +0.0°C)

Tested-by: Dieter Nützel <die...@nuetzel-hh.de>

Thank you very much Alex!

Dieter

Am 20.11.2017 23:57, schrieb Alex Deucher:
On Sun, Oct 8, 2017 at 10:31 PM, Dieter Nützel <die...@nuetzel-hh.de> 
wrote:

OK, got it but can't revert the commit clean.

amdgpu-pci-0100
Adapter: PCI adapter
fan1: 873 RPM
temp1:+26.0°C  (crit =  +0.0°C, hyst =  +0.0°C)

SOURCE/amd-staging-drm-next> git bisect good
0944c350c8eddf4064e7abb881dd245032fdfa23 is the first bad commit
commit 0944c350c8eddf4064e7abb881dd245032fdfa23
Author: Rex Zhu <rex@amd.com>
Date:   Mon Sep 25 18:51:50 2017 +0800

drm/amdgpu: delete pp_enable in adev

amdgpu not care powerplay or dpm is enabled.
just check ip functions and pp functions

Change-Id: Iaac75d45170ef9b20e212465f837eaaa798365bd
Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>
Signed-off-by: Rex Zhu <rex@amd.com>

:04 04 72361654709479890586e383ec73088e535a1cf5
2b6d5a75ffc3b6fd48c63e79bf28faddcc734918 M drivers


I think the attached patch should fix it.

Alex



Greetings,
Dieter



Am 09.10.2017 02:19, schrieb Dieter Nützel:


Sorry Rex,

after return from our vacation,
I've tested latest amd-staging-drm-next (e5f6a57e350a)
but it is NOT solved on my RX580.
I'll try bisecting if I find some more time in the coming days.

amdgpu-pci-0100
Adapter: PCI adapter
temp1:+27.0°C  (crit =  +0.0°C, hyst =  +0.0°C)

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
[AMD/ATI] Ellesmere [Radeon RX 470/480/570/580] (rev e7) (prog-if 00
[VGA controller])
Subsystem: Sapphire Technology Limited Radeon RX 570

[36.740] (--) AMDGPU(0): Chipset: "Radeon RX 580 Series" (ChipID 
=

0x67df)

Thanks,
Dieter

Am 30.09.2017 05:09, schrieb Zhu, Rex:


Yes, caused by the commit e37a7b4088da
("drm/amd/powerplay: tidy up ret checks in amd_powerplay.c")

Replace error when split patches.

Have sent the fix patch.
Please review.

Best Regards
Rex


-Original Message-
From: Alex Deucher [mailto:alexdeuc...@gmail.com]
Sent: Friday, September 29, 2017 10:11 PM
To: Dieter Nützel; Zhu, Rex
Cc: amd-devel; DRI Devel; Wentland, Harry; Michel Dänzer
Subject: Re: [amd-staging-drm-next] regression - no fan info 
(sensors) on

RX580

Rex, probably related to the recent cleanups in powerplay.

On Fri, Sep 29, 2017 at 10:09 AM, Dieter Nützel 
<die...@nuetzel-hh.de>

wrote:


Hello all,

since latest update

1d7da702e70d3c27408a3bb312c71d6be9f7bebe
drm/amd/powerplay: fix spelling mistake: "dividable" -> "divisible"

I didn't get fan info with my RX580 (Polaris21) any longer.

Worked with this commit:

786df0b89fe5a0b405d4de0a1ce03003c0743ec3
drm/amd/display: fix pflip irq registor for raven

Sorry, I do not have full time for bisect, because we are on way to
our vacation.

Maybe in the evening (only a few commits).

Greetings,
Dieter


___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v2 0/2] AMDGPU scheduler move, take 2

2017-12-06 Thread Dieter Nützel


For the series:

Tested-by: Dieter Nützel <die...@nuetzel-hh.de>

on RX580 8GB

with UH, UV, Blender 2.79, smoketest (Vulkan), glmark2 (parallel with 
OpenCL (/opt/opencl-example>./run_tests.sh))


Dieter

Am 06.12.2017 17:49, schrieb Lucas Stach:

Hi all,

second try to move the AMDGPU scheduler into a common location, this
time rebased onto drm-next-4.16-wip.

I've tested my etnaviv series on top of this and things seem to work
fine. I checked that AMDGPU still builds, but I don't have any means
to actually runtime test this currently, so I would be very happy to
receive some tested-bys from the AMD side.

Alex, if this looks good please pull this in so it gets your usual
testing.

Thanks,
Lucas

Lucas Stach (2):
  drm: move amd_gpu_scheduler into common location
  drm/sched: move fence slab handling to module init/exit

 drivers/gpu/drm/Kconfig|   5 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/amd/amdgpu/Makefile|   5 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu.h|  16 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |   6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c|  38 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|   8 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c  |   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_job.c|  20 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c   |  14 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h   |  12 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c  |  20 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_sched.h  |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c   |   6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c|   8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h|   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c|   8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.h|   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c|   8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.h|   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c|  14 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h|   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c |  10 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |   7 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  |   4 +-
 drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c  |   8 +-
 drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c  |   8 +-
 drivers/gpu/drm/amd/scheduler/gpu_scheduler.h  | 186 -
 drivers/gpu/drm/scheduler/Makefile |   4 +
 .../gpu/drm/{amd => }/scheduler/gpu_scheduler.c| 296 
++---

 drivers/gpu/drm/{amd => }/scheduler/sched_fence.c  | 122 +
 include/drm/gpu_scheduler.h| 173 
 .../drm/gpu_scheduler_trace.h  |  14 +-
 .../drm/amd/scheduler => include/drm}/spsc_queue.h |   7 +-
 35 files changed, 529 insertions(+), 523 deletions(-)
 delete mode 100644 drivers/gpu/drm/amd/scheduler/gpu_scheduler.h
 create mode 100644 drivers/gpu/drm/scheduler/Makefile
 rename drivers/gpu/drm/{amd => }/scheduler/gpu_scheduler.c (65%)
 rename drivers/gpu/drm/{amd => }/scheduler/sched_fence.c (58%)
 create mode 100644 include/drm/gpu_scheduler.h
 rename drivers/gpu/drm/amd/scheduler/gpu_sched_trace.h =>
include/drm/gpu_scheduler_trace.h (82%)
 rename {drivers/gpu/drm/amd/scheduler => include/drm}/spsc_queue.h 
(95%)

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/ttm: swap consecutive allocated pooled pages v4

2017-12-06 Thread Dieter Nützel


Tested-by: Dieter Nützel <die...@nuetzel-hh.de>

Dieter

Am 05.12.2017 13:54, schrieb Christian König:

When we detect consecutive allocation of pages swap them to avoid
accidentally freeing them as huge page.

v2: use swap
v3: check if it's really the first allocated page
v4: don't touch the loop variable

Signed-off-by: Christian König <christian.koe...@amd.com>
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index b6f7ce286fb1..44343a2bf55c 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -958,8 +958,15 @@ static int ttm_get_pages(struct page **pages,
unsigned npages, int flags,
r = ttm_page_pool_get_pages(pool, , flags, cstate,
npages - count, 0);

-   list_for_each_entry(p, , lru)
-   pages[count++] = p;
+   first = count;
+   list_for_each_entry(p, , lru) {
+   struct page *tmp = p;
+
+   /* Swap the pages if we detect consecutive order */
+   if (count > first && pages[count - 1] == tmp - 1)
+   swap(tmp, pages[count - 1]);
+   pages[count++] = tmp;
+   }

if (r) {
/* If there is any pages in the list put them back to

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/ttm: once more fix ttm_buffer_object_transfer

2017-10-30 Thread Dieter Nützel


Hello Christian,

is this for these warnings flooding my dmesg-log or do I have to open a 
new ticket:


Current amd-staging-drm-next commit #7781a8c68a6a from you ;-)

[ 6588.429302] WARNING: CPU: 5 PID: 2957 at 
drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:132 
generic_reg_update_ex+0xdc/0x120 [amdgpu]
[ 6588.429303] Modules linked in: fuse rfcomm rpcsec_gss_krb5 
auth_rpcgss nfsv4 nf_log_ipv6 xt_comment nf_log_ipv4 nf_log_common 
xt_LOG xt_limit dns_resolver nfs lockd nfnetlink_cthelper nfnetlink 
grace sunrpc fscache af_packet ipmi_ssif iscsi_ibft iscsi_boot_sysfs 
ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ipt_REJECT 
nf_reject_ipv4 xt_pkttype xt_tcpudp iptable_filter ip6table_mangle 
nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 
nf_defrag_ipv4 ip_tables xt_conntrack nf_conntrack libcrc32c bnep 
ip6table_filter ip6_tables x_tables jc42 joydev snd_hda_codec_hdmi 
snd_hda_intel intel_powerclamp coretemp snd_hda_codec kvm_intel 
snd_hwdep kvm snd_hda_core snd_pcm e1000e iTCO_wdt hid_generic snd_timer 
iTCO_vendor_support snd usbhid irqbypass btusb crc32c_intel btrtl btbcm
[ 6588.429340]  pcspkr ptp soundcore btintel bluetooth pps_core 
i7core_edac i2c_i801 tpm_infineon tpm_tis lpc_ich shpchp tpm_tis_core 
ipmi_si tpm ipmi_devintf ipmi_msghandler ac button rfkill ecdh_generic 
acpi_cpufreq tcp_bbr raid1 md_mod amdkfd amd_iommu_v2 serio_raw amdgpu 
sr_mod cdrom chash i2c_algo_bit drm_kms_helper syscopyarea ehci_pci 
sysfillrect sysimgblt ehci_hcd fb_sys_fops mpt3sas raid_class ttm 
scsi_transport_sas usbcore drm sg dm_multipath dm_mod scsi_dh_rdac 
scsi_dh_emc scsi_dh_alua
[ 6588.429370] CPU: 5 PID: 2957 Comm: X Tainted: GW   
4.13.0-rc5-1.g7262353-default+ #1
[ 6588.429371] Hardware name: FUJITSU  PRIMERGY 
TX150 S7 /D2759, BIOS 6.00 Rev. 1.19.2759.A1   
09/26/2012

[ 6588.429373] task: 8841a3658080 task.stack: 9ce4c3c38000
[ 6588.429426] RIP: 0010:generic_reg_update_ex+0xdc/0x120 [amdgpu]
[ 6588.429427] RSP: 0018:9ce4c3c3b760 EFLAGS: 00010246
[ 6588.429429] RAX: 0030 RBX:  RCX: 

[ 6588.429430] RDX: 0001 RSI:  RDI: 
8841a36c1980
[ 6588.429431] RBP: 9ce4c3c3b7c8 R08: 00ff R09: 
9ce4c3c3b778
[ 6588.429432] R10:  R11: 0002 R12: 
9ce4c3c3b7f8
[ 6588.429433] R13:  R14:  R15: 

[ 6588.429436] FS:  7f206d780a40() GS:8841bfd4() 
knlGS:

[ 6588.429437] CS:  0010 DS:  ES:  CR0: 80050033
[ 6588.429439] CR2: 7f745636a000 CR3: 0006654a5000 CR4: 
06e0

[ 6588.429439] Call Trace:
[ 6588.429498]  dce_mi_program_pte_vm+0x211/0x270 [amdgpu]
[ 6588.429555]  dce110_program_front_end_for_pipe+0x256/0x370 [amdgpu]
[ 6588.429613]  dce110_apply_ctx_for_surface+0xda/0x200 [amdgpu]
[ 6588.429668]  dc_commit_updates_for_stream+0x46a/0x4e0 [amdgpu]
[ 6588.429725]  dc_commit_planes_to_stream+0x322/0x380 [amdgpu]
[ 6588.429783]  amdgpu_dm_atomic_commit_tail+0x72a/0xaf0 [amdgpu]
[ 6588.429787]  ? ww_mutex_unlock+0x26/0x30
[ 6588.429844]  ? dm_plane_helper_prepare_fb+0xd2/0x230 [amdgpu]
[ 6588.429853]  ? drm_atomic_helper_wait_for_dependencies+0x89/0x160 
[drm_kms_helper]
[ 6588.429861]  ? drm_atomic_helper_swap_state+0x18d/0x360 
[drm_kms_helper]

[ 6588.429868]  commit_tail+0x3f/0x60 [drm_kms_helper]
[ 6588.429875]  drm_atomic_helper_commit+0x106/0x110 [drm_kms_helper]
[ 6588.429931]  amdgpu_dm_atomic_commit+0x8d/0xa0 [amdgpu]
[ 6588.429948]  drm_atomic_commit+0x4b/0x50 [drm]
[ 6588.429957]  drm_atomic_helper_legacy_gamma_set+0x114/0x150 
[drm_kms_helper]

[ 6588.429971]  drm_mode_gamma_set_ioctl+0x127/0x190 [drm]
[ 6588.429985]  ? drm_mode_crtc_set_gamma_size+0xb0/0xb0 [drm]
[ 6588.429997]  drm_ioctl_kernel+0x5d/0xb0 [drm]
[ 6588.430009]  drm_ioctl+0x31a/0x3d0 [drm]
[ 6588.430024]  ? drm_mode_crtc_set_gamma_size+0xb0/0xb0 [drm]
[ 6588.430027]  ? vfs_writev+0xaa/0xf0
[ 6588.430063]  amdgpu_drm_ioctl+0x4f/0x90 [amdgpu]
[ 6588.430065]  do_vfs_ioctl+0x92/0x5c0
[ 6588.430067]  ? __fget+0x6e/0x90
[ 6588.430069]  ? __fget+0x6e/0x90
[ 6588.430071]  SyS_ioctl+0x79/0x90
[ 6588.430075]  entry_SYSCALL_64_fastpath+0x1e/0xa9
[ 6588.430077] RIP: 0033:0x7f206b0fa077
[ 6588.430078] RSP: 002b:7ffd89a37978 EFLAGS: 3246 ORIG_RAX: 
0010
[ 6588.430080] RAX: ffda RBX: 00c3495ed210 RCX: 
7f206b0fa077
[ 6588.430081] RDX: 7ffd89a379b0 RSI: c02064a5 RDI: 
000d
[ 6588.430082] RBP: 00c34a30a690 R08: 00c349740ce0 R09: 
00c349740ee0
[ 6588.430083] R10: 0001 R11: 3246 R12: 
00c3488cd300
[ 6588.430084] R13: 00c34a30a690 R14: 00c34a6c3980 R15: 
0020
[ 6588.430086] Code: 45 21 e8 44 31 c3 41 39 d3 75 ab 45 84 d2 75 45 48 
8b 7f 18 89 da 48 8b 07 ff 50 38 48 83 c4 48 89 d8 5b 41 5a 41 5c

Re: [pull] amdgpu dc drm-next-4.15-dc

2017-10-26 Thread Dieter Nützel

Am 26.10.2017 19:26, schrieb Alex Deucher:
On Thu, Oct 26, 2017 at 10:10 AM, Dieter Nützel <die...@nuetzel-hh.de>
wrote:

Hello Alex & Rex,

any progress?
The 'screen blank' (monitor standby mode) is really annoying.

Does this patch help?
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-staging-drm-next=ddabbf65aae36e21b4c79354940f80eae6c36104

Alex

Yes, it seems so. Many thanks to Jerry for this fix.
I've tested it with latest amd-staging-drm-next #4ce527eb8bb3 on my
Polaris 20. Both cases (kdm_greet and 'screen blank') are solved. W'll
apply it on drm-next-4.15-dc, too.

Side note:
HDMI audio is _gone_ after logout and relogin.
Missing reinitialization?

Next:
Fix fan speed...

Thank you very much!
Dieter

Thanks,
Dieter

Am 23.10.2017 03:03, schrieb Dieter Nützel:

Am 22.10.2017 23:48, schrieb Dieter Nützel:

Am 21.10.2017 23:22, schrieb Alex Deucher:

Hi Dave,

Last batch of new stuff for DC. Highlights:
- Fix some memory leaks
- S3 fixes
- Hotplug fixes
- Fix some CX multi-display issues
- MST fixes
- DML updates from the hw team
- Various code cleanups
- Misc bug fixes

Now this tree has the same fan regression as 'amd-staging-drm-next'
startet with 0944c350c8eddf4064e7abb881dd245032fdfa23.

Look here:
[amd-staging-drm-next] regression - no fan info (sensors) on RX580
https://lists.freedesktop.org/archives/amd-gfx/2017-October/014065.html

Second:
KDE's greeter 'kdm_greet' (login screen went into dpms) and KDE's
'screen blank' (energy saving / dpms off) never came back. All I can
do is a clean reboot. So I have to disable all 'dpms'.
But I could attach gdb remotely on it.
'kdm_greet' hang in 'poll'.
Nothing alarming in 'dmesg' and 'Xorg.0.log'. (Both available taken
from 'amd-staging-drm-next' if needed).

Hello Alex and Rex,

I've found good hint from Jan (randomsalad) on phoronix for the
'screen blank' (monitor standby mode):

https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/984483-amdgpu-dc-gets-a-final-batch-of-changes-before-linux-4-15?p=984555#post984555

My Reply:

https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/984483-amdgpu-dc-gets-a-final-batch-of-changes-before-linux-4-15?p=984581#post984581

I can swear, that I could 'return' one time (the first time, maybe
due

to only warm reboot) on 'drm-next-4.15-dc-wip' directly from within
KDE session with replugging the video cable, but for all later tests
on both kernels I have to blindly switching back to login screen
(kdm_greet) and then replugging the video cable.

For me these regression started with 'amd-staging-drm-next' much
earlier than with the latest commit.

Dieter
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [pull] amdgpu dc drm-next-4.15-dc

2017-10-26 Thread Dieter Nützel

Hello Alex & Rex,

any progress?
The 'screen blank' (monitor standby mode) is really annoying.

Thanks,
Dieter

Am 23.10.2017 03:03, schrieb Dieter Nützel:

Am 22.10.2017 23:48, schrieb Dieter Nützel:

Am 21.10.2017 23:22, schrieb Alex Deucher:

Hi Dave,

Now this tree has the same fan regression as 'amd-staging-drm-next'
startet with 0944c350c8eddf4064e7abb881dd245032fdfa23.

Look here:
[amd-staging-drm-next] regression - no fan info (sensors) on RX580
https://lists.freedesktop.org/archives/amd-gfx/2017-October/014065.html

Hello Alex and Rex,

I've found good hint from Jan (randomsalad) on phoronix for the
'screen blank' (monitor standby mode):
https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/984483-amdgpu-dc-gets-a-final-batch-of-changes-before-linux-4-15?p=984555#post984555

My Reply:
https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/984483-amdgpu-dc-gets-a-final-batch-of-changes-before-linux-4-15?p=984581#post984581

I can swear, that I could 'return' one time (the first time, maybe due
to only warm reboot) on 'drm-next-4.15-dc-wip' directly from within
KDE session with replugging the video cable, but for all later tests
on both kernels I have to blindly switching back to login screen
(kdm_greet) and then replugging the video cable.

For me these regression started with 'amd-staging-drm-next' much
earlier than with the latest commit.

Dieter
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [pull] amdgpu dc drm-next-4.15-dc

2017-10-22 Thread Dieter Nützel

Am 22.10.2017 23:48, schrieb Dieter Nützel:

Am 21.10.2017 23:22, schrieb Alex Deucher:

Hi Dave,

Now this tree has the same fan regression as 'amd-staging-drm-next'
startet with 0944c350c8eddf4064e7abb881dd245032fdfa23.

Look here:
[amd-staging-drm-next] regression - no fan info (sensors) on RX580
https://lists.freedesktop.org/archives/amd-gfx/2017-October/014065.html

Hello Alex and Rex,

I've found good hint from Jan (randomsalad) on phoronix for the 'screen
blank' (monitor standby mode):

https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/984483-amdgpu-dc-gets-a-final-batch-of-changes-before-linux-4-15?p=984555#post984555

My Reply:
https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/984483-amdgpu-dc-gets-a-final-batch-of-changes-before-linux-4-15?p=984581#post984581

I can swear, that I could 'return' one time (the first time, maybe due
to only warm reboot) on 'drm-next-4.15-dc-wip' directly from within KDE
session with replugging the video cable, but for all later tests on both
kernels I have to blindly switching back to login screen (kdm_greet) and
then replugging the video cable.

For me these regression started with 'amd-staging-drm-next' much earlier
than with the latest commit.

Dieter
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [amd-staging-drm-next] compilation error with latest commit #1b006d838f78

2017-10-22 Thread Dieter Nützel


Am 17.10.2017 16:59, schrieb Michel Dänzer:

On 17/10/17 04:53 PM, Harry Wentland wrote:

On 2017-10-17 10:47 AM, Michel Dänzer wrote:

On 13/10/17 09:22 PM, Harry Wentland wrote:

On 2017-10-12 08:22 PM, Dieter Nützel wrote:


next (regression) compilation error:

drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c: In 
function ‘resource_map_pool_resources’:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1688:14: 
error: implicit declaration of function ‘acquire_first_split_pipe’; 
did you mean ‘acquire_first_free_pipe’? 
[-Werror=implicit-function-declaration]
   pipe_idx = acquire_first_split_pipe(>res_ctx, pool, 
stream);

  ^~~~
  acquire_first_free_pipe


It is wrongly (?) guarded behind:

#if defined(CONFIG_DRM_AMD_DC_DCN1_0)
static int acquire_first_split_pipe(
    struct resource_context *res_ctx,
    const struct resource_pool *pool,
    struct dc_stream_state *stream)
[snip]



Sent and merged a patch. This function only makes sense for DCN and 
shouldn't
be called otherwise. Thanks for reporting this. I gotta make sure to 
build

without the DCN flag in the future to avoid this.


Would it be possible to drop options like DRM_AMD_DC_FBC and
DRM_AMD_DC_DCN1_0 from amd-staging-drm-next (but especially 
upstream),

and just always compile the code?


DRM_AMD_DC_FBC should be pretty stable by now and can probably be 
dropped.

I'll check with Roma who implemented it.


Cool, thanks.


I'm running my RX580 under 'amd-staging-drm-next' and 
'drm-next-4.15-dc-wip' with it and don't see any problems so far.


Greetings,
Dieter
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[amd-staging-drm-next]: amdgpu: [powerplay] pp_get_power_profile_mode was not implemented.

2018-01-19 Thread Dieter Nützel


Hello Rex,

is this expected on Polaris 20 (RX580)?
I get this in dmesg when I try to query some values.

[ 7948.845940] amdgpu: [powerplay] pp_get_power_profile_mode was not 
implemented.


amd-staging-drm-next git
#f1182e58cded (HEAD -> amd-staging-drm-next, 
origin/amd-staging-drm-next) drm/ttm: Don't unreserve swapped BOs that 
were previously reserved


Thanks,
Dieter
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 1/6] drm/amdgpu/pm: handle fan properly when card is powered down

2018-01-25 Thread Dieter Nützel


For the series:

COOL stuff!

RX580 (Polaris20) during 'idle' (single HD 1920x1080):
amd-staging-drm-next

amdgpu-pci-0100
Adapter: PCI adapter
vddgfx:   +0.75 V
fan1: 904 RPM
temp1:+25.0°C  (crit = +94.0°C, hyst = -273.1°C)
power1:   32.00 W

Thank you very much Alex et al.!

Dieter
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [amd-staging-drm-next] regression - ERROR Don't have enable_spread_spectrum_on_ppll for v4

2018-01-25 Thread Dieter Nützel


Am 03.01.2018 16:03, schrieb Harry Wentland:

On 2017-12-27 04:04 AM, Michel Dänzer wrote:

On 2017-12-27 05:43 AM, Dieter Nützel wrote:

Hello AMD team,

I got this since latest 'amd-staging-drm-next' git update
(#b956c586e58a) during boot with Polaris RX580 DC on:

[    3.586342] [drm:dal_bios_parser_init_cmd_tbl [amdgpu]] *ERROR* 
Don't

have enable_spread_spectrum_on_ppll for v4
[    3.586410] [drm:dal_bios_parser_init_cmd_tbl [amdgpu]] *ERROR* 
Don't

have program_clock for v7

Latest GOOD commit was #b341a19e8039 (drm/radeon: Remove
KFD_CIK_SDMA_QUEUE_OFFSET).

I'll bisect if I have some time.
Maybe someone send a hint to the right commit.


I don't think bisecting is useful, it'll most likely just identify
commit 040dda2e1f52 ("drm/amd/display: Error print when ATOM BIOS
implementation is missing") which started printing these messages for
missing ATOM BIOS implementations.

I'm not sure, but I suspect these messages are harmless, given that
things are otherwise presumably still working as well as they were 
before.


These are harmless. I wrongfully assumed that printing errors here
should be fine on all ASICs as I assumed all relevant functions were
implemented. Apparently they're not, proving me wrong and proving the
usefulness of some sort of print here. I'll send a patch to demote the
prints to debug level.

Harry


Thank you Harry,

current amd-staging-drm-next (#0a7d506e54ca) calmed it, at least for me. 
;-)


Greetings,
Dieter
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[amd-staging-drm-next] regression - ERROR Don't have enable_spread_spectrum_on_ppll for v4

2017-12-26 Thread Dieter Nützel


Hello AMD team,

I got this since latest 'amd-staging-drm-next' git update 
(#b956c586e58a) during boot with Polaris RX580 DC on:


[3.586342] [drm:dal_bios_parser_init_cmd_tbl [amdgpu]] *ERROR* Don't 
have enable_spread_spectrum_on_ppll for v4
[3.586410] [drm:dal_bios_parser_init_cmd_tbl [amdgpu]] *ERROR* Don't 
have program_clock for v7


Latest GOOD commit was #b341a19e8039 (drm/radeon: Remove 
KFD_CIK_SDMA_QUEUE_OFFSET).


I'll bisect if I have some time.
Maybe someone send a hint to the right commit.

Thanks,
Dieter[0.00] microcode: microcode updated early to revision 0x7, date = 
2013-08-20
[0.00] Linux version 4.15.0-rc2-1.g7262353-default+ (dieter@SunWave1) 
(gcc version 7.2.1 20171020 [gcc-7-branch revision 253932] (SUSE Linux)) #1 SMP 
PREEMPT Wed Dec 20 22:10:01 CET 2017
[0.00] Command line: 
BOOT_IMAGE=/boot/vmlinuz-4.15.0-rc2-1.g7262353-default+ 
root=UUID=e19dd5e4-9df9-4ed6-8962-2d8f4993b6a5 video=1920x1080 noresume 
splash=silent quiet showopts amdgpu.dc=1
[0.00] x86/fpu: x87 FPU will use FXSAVE
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009b7ff] usable
[0.00] BIOS-e820: [mem 0x0009b800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000d-0x000d7fff] reserved
[0.00] BIOS-e820: [mem 0x000e4000-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x7f7a] usable
[0.00] BIOS-e820: [mem 0x7f7b-0x7f7bbfff] ACPI data
[0.00] BIOS-e820: [mem 0x7f7bc000-0x7f7bcfff] ACPI NVS
[0.00] BIOS-e820: [mem 0x7f7bd000-0x7fff] reserved
[0.00] BIOS-e820: [mem 0xe000-0xefff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfecf] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00067fff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] random: fast init done
[0.00] SMBIOS 2.6 present.
[0.00] DMI: FUJITSU  PRIMERGY TX150 S7  
   /D2759, BIOS 6.00 Rev. 1.19.2759.A1   09/26/2012
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x68 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-C7FFF write-protect
[0.00]   C8000-D uncachable
[0.00]   E-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0 mask F8000 write-back
[0.00]   1 base 1 mask F write-back
[0.00]   2 base 2 mask E write-back
[0.00]   3 base 4 mask E write-back
[0.00]   4 base 6 mask F8000 write-back
[0.00]   5 base 0FE00 mask FFE00 uncachable
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[0.00] e820: update [mem 0x8000-0x] usable ==> reserved
[0.00] e820: last_pfn = 0x7f7b0 max_arch_pfn = 0x4
[0.00] found SMP MP-table at [mem 0x000f97c0-0x000f97cf] mapped at [
(ptrval)]
[0.00] Scanning 1 areas for low memory corruption
[0.00] Base memory trampoline at [(ptrval)] 95000 size 24576
[0.00] BRK [0x35d3d, 0x35d3d0fff] PGTABLE
[0.00] BRK [0x35d3d1000, 0x35d3d1fff] PGTABLE
[0.00] BRK [0x35d3d2000, 0x35d3d2fff] PGTABLE
[0.00] BRK [0x35d3d3000, 0x35d3d3fff] PGTABLE
[0.00] BRK [0x35d3d4000, 0x35d3d4fff] PGTABLE
[0.00] BRK [0x35d3d5000, 0x35d3d5fff] PGTABLE
[0.00] BRK [0x35d3d6000, 0x35d3d6fff] PGTABLE
[0.00] BRK [0x35d3d7000, 0x35d3d7fff] PGTABLE
[0.00] RAMDISK: [mem 0x36517000-0x37282fff]
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x000F9790 24 (v02 PTLTD )
[0.00] ACPI: XSDT 0x7F7B4206 00010C (v01 PTLTD  ? XSDT   
0006  LTP )
[0.00] ACPI: FACP 0x7F7B9D07 F4 (v03 FTSD2759/Ax 
0006 FTS  000F4240)
[0.00] ACPI BIOS Warning (bug): 32/64X length mismatch in 
FADT/Pm1aControlBlock: 16/32 (20170831/tbfadt-603)
[0.00] ACPI BIOS Warning (bug): 32/64X length mismatch in 
FADT/Pm2ControlBlock: 8/32 (20170831/tbfadt-603)
[0.00] ACPI BIOS Warning (bug): 32/64X length mismatch in 
FADT/PmTimerBlock: 32/24 (20170831/tbfadt-603)
[0.00]

Re: [PATCH] drm/scheduler: fix setting the priorty for entities

2018-08-02 Thread Dieter Nützel


Hello Christian, AMD guys,

this one _together_ with these series
[PATCH 1/7] drm/amdgpu: use new scheduler load balancing for VMs
https://lists.freedesktop.org/archives/amd-gfx/2018-August/024802.html

on top of
amd-staging-drm-next 53d5f1e4a6d9

freeze whole system (Intel Xeon X3470, RX580) during _first_ mouse move.
Same for sddm login or first move in KDE Plasma 5.
NO logs so far. - Expected?

Greetings,
Dieter

Am 01.08.2018 16:27, schrieb Christian König:

Since we now deal with multiple rq we need to update all of them, not
just the current one.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c   |  3 +--
 drivers/gpu/drm/scheduler/gpu_scheduler.c | 36 
---

 include/drm/gpu_scheduler.h   |  5 ++---
 3 files changed, 26 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
index df6965761046..9fcc14e2dfcf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
@@ -407,12 +407,11 @@ void amdgpu_ctx_priority_override(struct 
amdgpu_ctx *ctx,

for (i = 0; i < adev->num_rings; i++) {
ring = adev->rings[i];
entity = >rings[i].entity;
-   rq = >sched.sched_rq[ctx_prio];

if (ring->funcs->type == AMDGPU_RING_TYPE_KIQ)
continue;

-   drm_sched_entity_set_rq(entity, rq);
+   drm_sched_entity_set_priority(entity, ctx_prio);
}
 }

diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c
b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index 05dc6ecd4003..85908c7f913e 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -419,29 +419,39 @@ static void drm_sched_entity_clear_dep(struct
dma_fence *f, struct dma_fence_cb
 }

 /**
- * drm_sched_entity_set_rq - Sets the run queue for an entity
+ * drm_sched_entity_set_rq_priority - helper for 
drm_sched_entity_set_priority

+ */
+static void drm_sched_entity_set_rq_priority(struct drm_sched_rq **rq,
+enum drm_sched_priority priority)
+{
+   *rq = &(*rq)->sched->sched_rq[priority];
+}
+
+/**
+ * drm_sched_entity_set_priority - Sets priority of the entity
  *
  * @entity: scheduler entity
- * @rq: scheduler run queue
+ * @priority: scheduler priority
  *
- * Sets the run queue for an entity and removes the entity from the 
previous

- * run queue in which was present.
+ * Update the priority of runqueus used for the entity.
  */
-void drm_sched_entity_set_rq(struct drm_sched_entity *entity,
-struct drm_sched_rq *rq)
+void drm_sched_entity_set_priority(struct drm_sched_entity *entity,
+  enum drm_sched_priority priority)
 {
-   if (entity->rq == rq)
-   return;
-
-   BUG_ON(!rq);
+   unsigned int i;

spin_lock(>rq_lock);
+
+   for (i = 0; i < entity->num_rq_list; ++i)
+   drm_sched_entity_set_rq_priority(>rq_list[i], priority);
+
drm_sched_rq_remove_entity(entity->rq, entity);
-   entity->rq = rq;
-   drm_sched_rq_add_entity(rq, entity);
+   drm_sched_entity_set_rq_priority(>rq, priority);
+   drm_sched_rq_add_entity(entity->rq, entity);
+
spin_unlock(>rq_lock);
 }
-EXPORT_SYMBOL(drm_sched_entity_set_rq);
+EXPORT_SYMBOL(drm_sched_entity_set_priority);

 /**
  * drm_sched_dependency_optimized
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index 0c4cfe689d4c..22c0f88f7d8f 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -298,9 +298,8 @@ void drm_sched_entity_fini(struct drm_sched_entity 
*entity);

 void drm_sched_entity_destroy(struct drm_sched_entity *entity);
 void drm_sched_entity_push_job(struct drm_sched_job *sched_job,
   struct drm_sched_entity *entity);
-void drm_sched_entity_set_rq(struct drm_sched_entity *entity,
-struct drm_sched_rq *rq);
-
+void drm_sched_entity_set_priority(struct drm_sched_entity *entity,
+  enum drm_sched_priority priority);
 struct drm_sched_fence *drm_sched_fence_create(
struct drm_sched_entity *s_entity, void *owner);
 void drm_sched_fence_scheduled(struct drm_sched_fence *fence);

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/scheduler: fix setting the priorty for entities - bisected

2018-08-05 Thread Dieter Nützel


Am 04.08.2018 06:18, schrieb Dieter Nützel:

Am 04.08.2018 06:12, schrieb Dieter Nützel:

Am 04.08.2018 05:27, schrieb Dieter Nützel:

Am 03.08.2018 13:09, schrieb Christian König:

Am 03.08.2018 um 03:08 schrieb Dieter Nützel:

Hello Christian, AMD guys,

this one _together_ with these series
[PATCH 1/7] drm/amdgpu: use new scheduler load balancing for VMs
https://lists.freedesktop.org/archives/amd-gfx/2018-August/024802.html

on top of
amd-staging-drm-next 53d5f1e4a6d9

freeze whole system (Intel Xeon X3470, RX580) during _first_ mouse 
move.

Same for sddm login or first move in KDE Plasma 5.
NO logs so far. - Expected?


Not even remotely, can you double check which patch from the "[PATCH
1/7] drm/amdgpu: use new scheduler load balancing for VMs" series is
causing the issue?


Ups,

_both_ 'series' on top of

bf1fd52b0632 (origin/amd-staging-drm-next) drm/amdgpu: move gem
definitions into amdgpu_gem header

works without a hitch.

But I have new (latest) µcode from openSUSE Tumbleweed.
kernel-firmware-20180730-35.1.src.rpm

Tested-by: Dieter Nützel 


I take this back.

Last much longer.
Mouse freeze.
Could grep a dmesg with remote phone ;-)

See the attachment.
Dieter


Argh, shi...
wrong dmesg version.

Should be this one. (For sure...)


Puh,

this took some time...
During the 'last' git bisect run => 'first bad commit is' I got next 
freeze.

But I could get a new dmesg.log file per remote phone (see attachment).

git bisect log show this:

SOURCE/amd-staging-drm-next> git bisect log
git bisect start
# good: [adebfff9c806afe1143d69a0174d4580cd27b23d] drm/scheduler: fix 
setting the priorty for entities

git bisect good adebfff9c806afe1143d69a0174d4580cd27b23d
# bad: [43202e67a4e6fcb0e6b773e8eb1ed56e1721e882] drm/amdgpu: use entity 
instead of ring for CS

git bisect bad 43202e67a4e6fcb0e6b773e8eb1ed56e1721e882
# bad: [9867b3a6ddfb73ee3105871541053f8e49949478] drm/amdgpu: use 
scheduler load balancing for compute CS

git bisect bad 9867b3a6ddfb73ee3105871541053f8e49949478
# good: [5d097a4591aa2be16b21adbaa19a8abb76e47ea1] drm/amdgpu: use 
scheduler load balancing for SDMA CS

git bisect good 5d097a4591aa2be16b21adbaa19a8abb76e47ea1
# first bad commit: [9867b3a6ddfb73ee3105871541053f8e49949478] 
drm/amdgpu: use scheduler load balancing for compute CS


git log --oneline
5d097a4591aa (HEAD, 
refs/bisect/good-5d097a4591aa2be16b21adbaa19a8abb76e47ea1) drm/amdgpu: 
use scheduler load balancing for SDMA CS

d12ae5172f1f drm/amdgpu: use new scheduler load balancing for VMs
adebfff9c806 (refs/bisect/good-adebfff9c806afe1143d69a0174d4580cd27b23d) 
drm/scheduler: fix setting the priorty for entities
bf1fd52b0632 (origin/amd-staging-drm-next) drm/amdgpu: move gem 
definitions into amdgpu_gem header

5031ae5f9e5c drm/amdgpu: move psp macro into amdgpu_psp header
[-]

I'm not really sure that
drm/amdgpu: use scheduler load balancing for compute CS
is the offender.

One step earlier could it be, too.
drm/amdgpu: use scheduler load balancing for SDMA CS

I'm try running with the SDMA CS patch for the next days.

If you need more ask!

Dieter




Thanks,
Christian.



Greetings,
Dieter

Am 01.08.2018 16:27, schrieb Christian König:
Since we now deal with multiple rq we need to update all of them, 
not

just the current one.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c   |  3 +--
 drivers/gpu/drm/scheduler/gpu_scheduler.c | 36 
---

 include/drm/gpu_scheduler.h   |  5 ++---
 3 files changed, 26 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
index df6965761046..9fcc14e2dfcf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
@@ -407,12 +407,11 @@ void amdgpu_ctx_priority_override(struct 
amdgpu_ctx *ctx,

 for (i = 0; i < adev->num_rings; i++) {
 ring = adev->rings[i];
 entity = >rings[i].entity;
-    rq = >sched.sched_rq[ctx_prio];

 if (ring->funcs->type == AMDGPU_RING_TYPE_KIQ)
 continue;

-    drm_sched_entity_set_rq(entity, rq);
+    drm_sched_entity_set_priority(entity, ctx_prio);
 }
 }

diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c
b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index 05dc6ecd4003..85908c7f913e 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -419,29 +419,39 @@ static void 
drm_sched_entity_clear_dep(struct

dma_fence *f, struct dma_fence_cb
 }

 /**
- * drm_sched_entity_set_rq - Sets the run queue for an entity
+ * drm_sched_entity_set_rq_priority - helper for 
drm_sched_entity_set_priority

+ */
+static void drm_sched_entity_set_rq_priority(struct drm_sched_rq 
**rq,

+ enum drm_sched_priority priority)
+{
+    *rq = &(*rq)->sched->sched_rq[priority];
+}
+
+/**
+ * drm_sched_entity_set_priority - Sets pr

Re: [PATCH] drm/scheduler: fix setting the priorty for entities

2018-08-03 Thread Dieter Nützel


Am 03.08.2018 13:09, schrieb Christian König:

Am 03.08.2018 um 03:08 schrieb Dieter Nützel:

Hello Christian, AMD guys,

this one _together_ with these series
[PATCH 1/7] drm/amdgpu: use new scheduler load balancing for VMs
https://lists.freedesktop.org/archives/amd-gfx/2018-August/024802.html

on top of
amd-staging-drm-next 53d5f1e4a6d9

freeze whole system (Intel Xeon X3470, RX580) during _first_ mouse 
move.

Same for sddm login or first move in KDE Plasma 5.
NO logs so far. - Expected?


Not even remotely, can you double check which patch from the "[PATCH
1/7] drm/amdgpu: use new scheduler load balancing for VMs" series is
causing the issue?


Ups,

_both_ 'series' on top of

bf1fd52b0632 (origin/amd-staging-drm-next) drm/amdgpu: move gem 
definitions into amdgpu_gem header


works without a hitch.

But I have new (latest) µcode from openSUSE Tumbleweed.
kernel-firmware-20180730-35.1.src.rpm

Tested-by: Dieter Nützel 

Sorry about the noise.
Dieter



Thanks,
Christian.



Greetings,
Dieter

Am 01.08.2018 16:27, schrieb Christian König:

Since we now deal with multiple rq we need to update all of them, not
just the current one.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c   |  3 +--
 drivers/gpu/drm/scheduler/gpu_scheduler.c | 36 
---

 include/drm/gpu_scheduler.h   |  5 ++---
 3 files changed, 26 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
index df6965761046..9fcc14e2dfcf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
@@ -407,12 +407,11 @@ void amdgpu_ctx_priority_override(struct 
amdgpu_ctx *ctx,

 for (i = 0; i < adev->num_rings; i++) {
 ring = adev->rings[i];
 entity = >rings[i].entity;
-    rq = >sched.sched_rq[ctx_prio];

 if (ring->funcs->type == AMDGPU_RING_TYPE_KIQ)
 continue;

-    drm_sched_entity_set_rq(entity, rq);
+    drm_sched_entity_set_priority(entity, ctx_prio);
 }
 }

diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c
b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index 05dc6ecd4003..85908c7f913e 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -419,29 +419,39 @@ static void drm_sched_entity_clear_dep(struct
dma_fence *f, struct dma_fence_cb
 }

 /**
- * drm_sched_entity_set_rq - Sets the run queue for an entity
+ * drm_sched_entity_set_rq_priority - helper for 
drm_sched_entity_set_priority

+ */
+static void drm_sched_entity_set_rq_priority(struct drm_sched_rq 
**rq,

+ enum drm_sched_priority priority)
+{
+    *rq = &(*rq)->sched->sched_rq[priority];
+}
+
+/**
+ * drm_sched_entity_set_priority - Sets priority of the entity
  *
  * @entity: scheduler entity
- * @rq: scheduler run queue
+ * @priority: scheduler priority
  *
- * Sets the run queue for an entity and removes the entity from the 
previous

- * run queue in which was present.
+ * Update the priority of runqueus used for the entity.
  */
-void drm_sched_entity_set_rq(struct drm_sched_entity *entity,
- struct drm_sched_rq *rq)
+void drm_sched_entity_set_priority(struct drm_sched_entity *entity,
+   enum drm_sched_priority priority)
 {
-    if (entity->rq == rq)
-    return;
-
-    BUG_ON(!rq);
+    unsigned int i;

 spin_lock(>rq_lock);
+
+    for (i = 0; i < entity->num_rq_list; ++i)
+ drm_sched_entity_set_rq_priority(>rq_list[i], priority);
+
 drm_sched_rq_remove_entity(entity->rq, entity);
-    entity->rq = rq;
-    drm_sched_rq_add_entity(rq, entity);
+    drm_sched_entity_set_rq_priority(>rq, priority);
+    drm_sched_rq_add_entity(entity->rq, entity);
+
 spin_unlock(>rq_lock);
 }
-EXPORT_SYMBOL(drm_sched_entity_set_rq);
+EXPORT_SYMBOL(drm_sched_entity_set_priority);

 /**
  * drm_sched_dependency_optimized
diff --git a/include/drm/gpu_scheduler.h 
b/include/drm/gpu_scheduler.h

index 0c4cfe689d4c..22c0f88f7d8f 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -298,9 +298,8 @@ void drm_sched_entity_fini(struct 
drm_sched_entity *entity);

 void drm_sched_entity_destroy(struct drm_sched_entity *entity);
 void drm_sched_entity_push_job(struct drm_sched_job *sched_job,
    struct drm_sched_entity *entity);
-void drm_sched_entity_set_rq(struct drm_sched_entity *entity,
- struct drm_sched_rq *rq);
-
+void drm_sched_entity_set_priority(struct drm_sched_entity *entity,
+   enum drm_sched_priority priority);
 struct drm_sched_fence *drm_sched_fence_create(
 struct drm_sched_entity *s_entity, void *owner);
 void drm_sched_fence_scheduled(struct drm_sched_fence *fence);

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/scheduler: fix setting the priorty for entities

2018-08-03 Thread Dieter Nützel


Am 04.08.2018 05:27, schrieb Dieter Nützel:

Am 03.08.2018 13:09, schrieb Christian König:

Am 03.08.2018 um 03:08 schrieb Dieter Nützel:

Hello Christian, AMD guys,

this one _together_ with these series
[PATCH 1/7] drm/amdgpu: use new scheduler load balancing for VMs
https://lists.freedesktop.org/archives/amd-gfx/2018-August/024802.html

on top of
amd-staging-drm-next 53d5f1e4a6d9

freeze whole system (Intel Xeon X3470, RX580) during _first_ mouse 
move.

Same for sddm login or first move in KDE Plasma 5.
NO logs so far. - Expected?


Not even remotely, can you double check which patch from the "[PATCH
1/7] drm/amdgpu: use new scheduler load balancing for VMs" series is
causing the issue?


Ups,

_both_ 'series' on top of

bf1fd52b0632 (origin/amd-staging-drm-next) drm/amdgpu: move gem
definitions into amdgpu_gem header

works without a hitch.

But I have new (latest) µcode from openSUSE Tumbleweed.
kernel-firmware-20180730-35.1.src.rpm

Tested-by: Dieter Nützel 


I take this back.

Last much longer.
Mouse freeze.
Could grep a dmesg with remote phone ;-)

See the attachment.
Dieter




Thanks,
Christian.



Greetings,
Dieter

Am 01.08.2018 16:27, schrieb Christian König:
Since we now deal with multiple rq we need to update all of them, 
not

just the current one.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c   |  3 +--
 drivers/gpu/drm/scheduler/gpu_scheduler.c | 36 
---

 include/drm/gpu_scheduler.h   |  5 ++---
 3 files changed, 26 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
index df6965761046..9fcc14e2dfcf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
@@ -407,12 +407,11 @@ void amdgpu_ctx_priority_override(struct 
amdgpu_ctx *ctx,

 for (i = 0; i < adev->num_rings; i++) {
 ring = adev->rings[i];
 entity = >rings[i].entity;
-    rq = >sched.sched_rq[ctx_prio];

 if (ring->funcs->type == AMDGPU_RING_TYPE_KIQ)
 continue;

-    drm_sched_entity_set_rq(entity, rq);
+    drm_sched_entity_set_priority(entity, ctx_prio);
 }
 }

diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c
b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index 05dc6ecd4003..85908c7f913e 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -419,29 +419,39 @@ static void drm_sched_entity_clear_dep(struct
dma_fence *f, struct dma_fence_cb
 }

 /**
- * drm_sched_entity_set_rq - Sets the run queue for an entity
+ * drm_sched_entity_set_rq_priority - helper for 
drm_sched_entity_set_priority

+ */
+static void drm_sched_entity_set_rq_priority(struct drm_sched_rq 
**rq,

+ enum drm_sched_priority priority)
+{
+    *rq = &(*rq)->sched->sched_rq[priority];
+}
+
+/**
+ * drm_sched_entity_set_priority - Sets priority of the entity
  *
  * @entity: scheduler entity
- * @rq: scheduler run queue
+ * @priority: scheduler priority
  *
- * Sets the run queue for an entity and removes the entity from the 
previous

- * run queue in which was present.
+ * Update the priority of runqueus used for the entity.
  */
-void drm_sched_entity_set_rq(struct drm_sched_entity *entity,
- struct drm_sched_rq *rq)
+void drm_sched_entity_set_priority(struct drm_sched_entity *entity,
+   enum drm_sched_priority priority)
 {
-    if (entity->rq == rq)
-    return;
-
-    BUG_ON(!rq);
+    unsigned int i;

 spin_lock(>rq_lock);
+
+    for (i = 0; i < entity->num_rq_list; ++i)
+ drm_sched_entity_set_rq_priority(>rq_list[i], priority);
+
 drm_sched_rq_remove_entity(entity->rq, entity);
-    entity->rq = rq;
-    drm_sched_rq_add_entity(rq, entity);
+    drm_sched_entity_set_rq_priority(>rq, priority);
+    drm_sched_rq_add_entity(entity->rq, entity);
+
 spin_unlock(>rq_lock);
 }
-EXPORT_SYMBOL(drm_sched_entity_set_rq);
+EXPORT_SYMBOL(drm_sched_entity_set_priority);

 /**
  * drm_sched_dependency_optimized
diff --git a/include/drm/gpu_scheduler.h 
b/include/drm/gpu_scheduler.h

index 0c4cfe689d4c..22c0f88f7d8f 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -298,9 +298,8 @@ void drm_sched_entity_fini(struct 
drm_sched_entity *entity);

 void drm_sched_entity_destroy(struct drm_sched_entity *entity);
 void drm_sched_entity_push_job(struct drm_sched_job *sched_job,
    struct drm_sched_entity *entity);
-void drm_sched_entity_set_rq(struct drm_sched_entity *entity,
- struct drm_sched_rq *rq);
-
+void drm_sched_entity_set_priority(struct drm_sched_entity *entity,
+   enum drm_sched_priority priority);
 struct drm_sched_fence *drm_sched_fence_create(
 struct drm_sched_entity *s_entity, void *owner);
 void drm_sched_fence_scheduled(struct drm_sc

Re: [PATCH] drm/scheduler: fix setting the priorty for entities - bisected

2018-08-07 Thread Dieter Nützel


Am 06.08.2018 02:13, schrieb Dieter Nützel:

Am 04.08.2018 06:18, schrieb Dieter Nützel:

Am 04.08.2018 06:12, schrieb Dieter Nützel:

Am 04.08.2018 05:27, schrieb Dieter Nützel:

Am 03.08.2018 13:09, schrieb Christian König:

Am 03.08.2018 um 03:08 schrieb Dieter Nützel:

Hello Christian, AMD guys,

this one _together_ with these series
[PATCH 1/7] drm/amdgpu: use new scheduler load balancing for VMs
https://lists.freedesktop.org/archives/amd-gfx/2018-August/024802.html

on top of
amd-staging-drm-next 53d5f1e4a6d9

freeze whole system (Intel Xeon X3470, RX580) during _first_ mouse 
move.

Same for sddm login or first move in KDE Plasma 5.
NO logs so far. - Expected?


Not even remotely, can you double check which patch from the 
"[PATCH
1/7] drm/amdgpu: use new scheduler load balancing for VMs" series 
is

causing the issue?


Ups,

_both_ 'series' on top of

bf1fd52b0632 (origin/amd-staging-drm-next) drm/amdgpu: move gem
definitions into amdgpu_gem header

works without a hitch.

But I have new (latest) µcode from openSUSE Tumbleweed.
kernel-firmware-20180730-35.1.src.rpm

Tested-by: Dieter Nützel 


I take this back.

Last much longer.
Mouse freeze.
Could grep a dmesg with remote phone ;-)

See the attachment.
Dieter


Argh, shi...
wrong dmesg version.

Should be this one. (For sure...)


Puh,

this took some time...
During the 'last' git bisect run => 'first bad commit is' I got next 
freeze.

But I could get a new dmesg.log file per remote phone (see attachment).

git bisect log show this:

SOURCE/amd-staging-drm-next> git bisect log
git bisect start
# good: [adebfff9c806afe1143d69a0174d4580cd27b23d] drm/scheduler: fix
setting the priorty for entities
git bisect good adebfff9c806afe1143d69a0174d4580cd27b23d
# bad: [43202e67a4e6fcb0e6b773e8eb1ed56e1721e882] drm/amdgpu: use
entity instead of ring for CS
git bisect bad 43202e67a4e6fcb0e6b773e8eb1ed56e1721e882
# bad: [9867b3a6ddfb73ee3105871541053f8e49949478] drm/amdgpu: use
scheduler load balancing for compute CS
git bisect bad 9867b3a6ddfb73ee3105871541053f8e49949478
# good: [5d097a4591aa2be16b21adbaa19a8abb76e47ea1] drm/amdgpu: use
scheduler load balancing for SDMA CS
git bisect good 5d097a4591aa2be16b21adbaa19a8abb76e47ea1
# first bad commit: [9867b3a6ddfb73ee3105871541053f8e49949478]
drm/amdgpu: use scheduler load balancing for compute CS

git log --oneline
5d097a4591aa (HEAD,
refs/bisect/good-5d097a4591aa2be16b21adbaa19a8abb76e47ea1) drm/amdgpu:
use scheduler load balancing for SDMA CS
d12ae5172f1f drm/amdgpu: use new scheduler load balancing for VMs
adebfff9c806
(refs/bisect/good-adebfff9c806afe1143d69a0174d4580cd27b23d)
drm/scheduler: fix setting the priorty for entities
bf1fd52b0632 (origin/amd-staging-drm-next) drm/amdgpu: move gem
definitions into amdgpu_gem header
5031ae5f9e5c drm/amdgpu: move psp macro into amdgpu_psp header
[-]

I'm not really sure that
drm/amdgpu: use scheduler load balancing for compute CS
is the offender.

One step earlier could it be, too.
drm/amdgpu: use scheduler load balancing for SDMA CS

I'm try running with the SDMA CS patch for the next days.

If you need more ask!


Hello Christian,

running the second day _without_ the 2. patch
[2/7] drm/amdgpu: use scheduler load balancing for SDMA CS
my system is stable, again.

To be clear.
I've now only #1 applied on top of amd-staging-drm-next.
'This one' is still in.
So we should switching the thread.

Dieter




Thanks,
Christian.



Greetings,
Dieter

Am 01.08.2018 16:27, schrieb Christian König:
Since we now deal with multiple rq we need to update all of them, 
not

just the current one.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c   |  3 +--
 drivers/gpu/drm/scheduler/gpu_scheduler.c | 36 
---

 include/drm/gpu_scheduler.h   |  5 ++---
 3 files changed, 26 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
index df6965761046..9fcc14e2dfcf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
@@ -407,12 +407,11 @@ void amdgpu_ctx_priority_override(struct 
amdgpu_ctx *ctx,

 for (i = 0; i < adev->num_rings; i++) {
 ring = adev->rings[i];
 entity = >rings[i].entity;
-    rq = >sched.sched_rq[ctx_prio];

 if (ring->funcs->type == AMDGPU_RING_TYPE_KIQ)
 continue;

-    drm_sched_entity_set_rq(entity, rq);
+    drm_sched_entity_set_priority(entity, ctx_prio);
 }
 }

diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c
b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index 05dc6ecd4003..85908c7f913e 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -419,29 +419,39 @@ static void 
drm_sched_entity_clear_dep(struct

dma_fence *f, struct dma_fence_cb
 }

 /**
- * drm_sched_entity_set_rq - Sets the run queue for an entity
+ * drm_

Re: [PATCH v3 0/5] drm/ttm,amdgpu: Introduce LRU bulk move functionality

2018-08-15 Thread Dieter Nützel


For the series

Tested-by: Dieter Nützel 

on RX580,
amd-staging-drm-next
#5024f8dfe478

Dieter

Am 13.08.2018 11:58, schrieb Huang Rui:
The idea and proposal is originally from Christian, and I continue to 
work to

deliver it.

Background:
amdgpu driver will move all PD/PT and PerVM BOs into idle list. Then 
move all of
them on the end of LRU list one by one. Thus, that cause so many BOs 
moved to

the end of the LRU, and impact performance seriously.

Then Christian provided a workaround to not move PD/PT BOs on LRU with 
below

patch:
"drm/amdgpu: band aid validating VM PTs"
Commit 0bbf32026cf5ba41e9922b30e26e1bed1ecd38ae

However, the final solution should bulk move all PD/PT and PerVM BOs on 
the LRU

instead of one by one.

Whenever amdgpu_vm_validate_pt_bos() is called and we have BOs which 
need to be
validated we move all BOs together to the end of the LRU without 
dropping the

lock for the LRU.

While doing so we note the beginning and end of this block in the LRU 
list.


Now when amdgpu_vm_validate_pt_bos() is called and we don't have 
anything to do,
we don't move every BO one by one, but instead cut the LRU list into 
pieces so

that we bulk move everything to the end in just one operation.

Test data:
+--+-+---+---+
|  |The Talos|Clpeak(OCL)|BusSpeedReadback(OCL)
  |
|  |Principle(Vulkan)|   |
  |
++
|  | |   |0.319 ms(1k) 0.314
ms(2K) 0.308 ms(4K) |
| Original |  147.7 FPS  |  76.86 us |0.307 ms(8K) 0.310
ms(16K) |
++
| Orignial + WA| |   |0.254 ms(1K) 0.241
ms(2K)  |
|(don't move   |  162.1 FPS  |  42.15 us |0.230 ms(4K) 0.223
ms(8K) 0.204 ms(16K)|
|PT BOs on LRU)| |   |
  |
++
| Bulk move|  163.1 FPS  |  40.52 us |0.244 ms(1K) 0.252
ms(2K) 0.213 ms(4K) |
|  | |   |0.214 ms(8K) 0.225
ms(16K) |
+--+-+---+---+

After test them with above three benchmarks include vulkan and opencl. 
We can
see the visible improvement than original, and even better than 
original with

workaround.

Changes from V1 -> V2:
- Fix to missed the BOs in relocated/moved that should be also moved to 
the end

  of LRU.

Changes from V2 -> V3:
- Remove unused parameter and use list_for_each_entry instead of the 
one with

  save entry.

Thanks,
Rui

Christian König (2):
  drm/ttm: add helper structures for bulk moves on lru list
  drm/ttm: revise ttm_bo_move_to_lru_tail to support bulk moves

Huang Rui (3):
  drm/ttm: add bulk move function on LRU
  drm/amdgpu: use bulk moves for efficient VM LRU handling (v3)
  drm/amdgpu: move PD/PT bos on LRU again

 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 75 


 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |  4 ++
 drivers/gpu/drm/ttm/ttm_bo.c   | 78 
+-

 include/drm/ttm/ttm_bo_api.h   | 16 ++-
 include/drm/ttm/ttm_bo_driver.h| 28 
 5 files changed, 182 insertions(+), 19 deletions(-)

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[amd-staging-drm-next] - commit 'Set disp clk in a safe way to avoid over high dpp clk.' makes 'CONFIG_DRM_AMD_DC_DCN1_0=y' mandatory, again

2018-03-14 Thread Dieter Nützel


Hello,

commit # 680acc64120cd7fe4fb21d816a0fc0854018fe59
drm/amd/display: Set disp clk in a safe way to avoid over high dpp clk.

makes CONFIG_DRM_AMD_DC_DCN1_0=y mandatory, again.
I think it was not intentional?

Without it I get:

Kernel: arch/x86/boot/bzImage is ready  (#1)
ERROR: "dcn_find_dcfclk_suits_all" 
[drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!

make[1]: *** [scripts/Makefile.modpost:92: __modpost] Fehler 1
make: *** [Makefile:1257: modules] Fehler 2

drm/amd> grep -r dcn_find_dcfclk_suits_all *
Übereinstimmungen in Binärdatei amdgpu/amdgpu.o
display/dc/calcs/dcn_calcs.c:unsigned int dcn_find_dcfclk_suits_all(
display/dc/inc/dcn_calcs.h:unsigned int dcn_find_dcfclk_suits_all(
display/dc/dce/dce_clocks.c:
dcn_find_dcfclk_suits_all(core_dc, >cur_clocks_value);

Übereinstimmungen in Binärdatei display/dc/dce/dce_clocks.o
drm/amd> l display/dc/calcs/dcn_calcs.c display/dc/inc/dcn_calcs.h 
display/dc/dce/dce_clocks.c
-rw-r--r-- 1 dieter users 66423 13. Mär 23:08 
display/dc/calcs/dcn_calcs.c
-rw-r--r-- 1 dieter users 25680 13. Mär 23:08 
display/dc/dce/dce_clocks.c

-rw-r--r-- 1 dieter users 26059 20. Dez 22:07 display/dc/inc/dcn_calcs.h

Thanks,
Dieter
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [amd-staging-drm-next] power1: Watt numbers do not appear since some days (Polaris 20)

2018-04-21 Thread Dieter Nützel


Tested-by: Dieter Nützel <die...@nuetzel-hh.de>

Even better 'idle' (KDE Plasma 5 desktop, single monitor) then _ever_:

amdgpu-pci-0100
Adapter: PCI adapter
vddgfx:   +0.75 V
fan1: 900 RPM
temp1:+26.0°C  (crit = +94.0°C, hyst = -273.1°C)
power1:   31.04 W  (cap = 175.00 W)

But 'hyst = -273.1°C'?
Read about a fix for this earlier, but...;-)

Thanks,
Dieter

Am 21.04.2018 21:13, schrieb Alex Deucher:

+ Rex

On Fri, Apr 20, 2018 at 9:25 PM, Dieter Nützel <die...@nuetzel-hh.de> 
wrote:

Hello Harry and Alex,

Watt numbers are broken for some days (5 to 7).

Polaris 20 (RX580), Sapphire Nitro+, 8 GB

amdgpu-pci-0100
Adapter: PCI adapter
vddgfx:   +0.75 V
fan1:1048 RPM
temp1:+28.0°C  (crit = +94.0°C, hyst = -273.1°C)
power1:0.00 W  (cap = 175.00 W)

Should I open a ticket, bisect?



Should be fixed with this patch.

Alex




Thanks,
Dieter

PS I do have litte time, summer in spring (April) here in 'good old
Germany'...

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Fw: [Bug 109650] [amd-staging-drm-next] - Polaris 20 dc - idle power regession 3x [bisected]

2019-02-16 Thread Dieter Nützel


Hello Yong,

this was your commit ;-)

Greetings,
Dieter

 Originalnachricht 
Betreff: [Bug 109650] [amd-staging-drm-next] - Polaris 20 dc - idle 
power regession 3x [bisected]

Datum: 16.02.2019 00:42
Von: bugzilla-dae...@freedesktop.org
An: dri-de...@lists.freedesktop.org

BUG ID
109650 [1]

SUMMARY
[amd-staging-drm-next] - Polaris 20 dc - idle power regession 3x
[bisected]

PRODUCT
DRI

VERSION
DRI git

HARDWARE
x86-64 (AMD64)

OS
Linux (All)

STATUS
NEW

SEVERITY
normal

PRIORITY
medium

COMPONENT
DRM/AMDgpu

ASSIGNEE
dri-de...@lists.freedesktop.org

REPORTER
die...@nuetzel-hh.de

Polaris 20

Idle power went up from ~32 W to ~96 W.

With broken commits:

amdgpu-pci-0100
Adapter: PCI adapter
vddgfx:   +1.20 V
fan1: 888 RPM  (min =0 RPM, max = 3200 RPM)
temp1:+55.0°C  (crit = +94.0°C, hyst = -273.1°C)
power1:   96.04 W  (cap = 175.00 W)

Bisected to:

764c85fef41722db0f21558c6c2fb38bee172d19 is the first bad commit
commit 764c85fef41722db0f21558c6c2fb38bee172d19
Author: Yong Zhao 
Date:   Tue Feb 5 15:17:40 2019 -0500

drm/amdgpu: Fix bugs in setting CP RB/MEC DOORBELL_RANGE registers

CP_RB_DOORBELL_RANGE_LOWER/UPPER and
CP_MEC_DOORBELL_RANGE_LOWER/UPPER
are used for waking up an idle scheduler and for power gating
support.
Usually the first few doorbells in pci doorbell bar are used for RB
and all leftover for MEC. This patch fixes the incorrect settings.

Theoretically, gfx ring doorbells should come before all MEC
doorbells
to be consistent with the design. However, since the doorbell
allocations are agreed by all and we are not free to change them,
also
considering the kernel MEC ring doorbells which are before gfx ring
doorbells are not used often, we compromise by leaving the doorbell
allocations unchanged.

Change-Id: I402a56ce9a80e6c2ed2f96be431ae71ca88e73a4
Signed-off-by: Yong Zhao 
Reviewed-by: Felix Kuehling 

:04 04 a5747a6be3d388ae851855eebe7ebbf20488ba22
7b516291deb849c593199a4c8df3ad08c5b7a769 M drivers

After reverting both related commits from current
amd-staging-drm-next (256445aee13f)

9affde0e44af (HEAD -> amd-staging-drm-next) Revert "drm/amdgpu: Fix bugs
in
setting CP RB/MEC DOORBELL_RANGE registers"
8e73059158d8 Revert "drm/amdgpu: Delete user queue doorbell variables"
256445aee13f (origin/amd-staging-drm-next) drm/amdgpu: remove some old
unused
dpm helpers

I get these numbers, again (somewhat higher then Win... as some other
pointed
out):

amdgpu-pci-0100
Adapter: PCI adapter
vddgfx:   +0.75 V
fan1: 900 RPM  (min =0 RPM, max = 3200 RPM)
temp1:+30.0°C  (crit = +94.0°C, hyst = -273.1°C)
power1:   32.16 W  (cap = 175.00 W)

-
 You are receiving this mail because:

* You are the assignee for the bug.



Links:
--
[1] https://bugs.freedesktop.org/show_bug.cgi?id=109650
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [amd-staging-drm-next] broken after Navi merge

2019-06-24 Thread Dieter Nützel


Hello Hawking, hello all,

up and running.
I saw that Alex sent it in for 5.3 already.

Thank you very much!

BTW
This isn't needed for pre Navi?
CONFIG_DRM_AMD_DC_DCN2_0=y
CONFIG_DRM_AMD_DC_DSC_SUPPORT=y
But do not harm?

glmark2 seems to be somewhat faster, again ;-)

Dieter

Am 24.06.2019 15:53, schrieb Zhang, Hawking:

Ah, sorry, it has not landed yet. but the patch is in review list now.
[PATCH] drm/amdgpu: fix modprobe failure for uvd_4/5/6

Regards,
Hawking
-Original Message-
From: amd-gfx  On Behalf Of
Zhang, Hawking
Sent: 2019年6月24日 21:50
To: Dieter Nützel ; Alex Deucher 


Cc: amd-devel 
Subject: RE: [amd-staging-drm-next] broken after Navi merge

Please pull my latest fixes that probably helps on issue you ran into.
61adda1f6f080717a9ee4c96a74c8df6ffab1ff0 drm/amdgpu: fix modprobe
failure for uvd_4/5/6

Regards,
Hawking
-Original Message-
From: amd-gfx  On Behalf Of 
Dieter Nützel

Sent: 2019年6月24日 21:29
To: Alex Deucher 
Cc: amd-devel 
Subject: [amd-staging-drm-next] broken after Navi merge

Hello Alex,

after your latest Navi merge 'amd-staging-drm-next' is broken with 
Polaris 20.


It hangs with very light gray (mostly black) screen after first mode 
switch.


Tested commit:
317d5033ab6c (HEAD -> amd-staging-drm-next, 
origin/amd-staging-drm-next)

drm/amdgpu: add job->preamble_status back to status value

Even run mode 3|1 with grub2 do not works.

See also:
https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1108500-amd-sends-in-navi-support-other-remaining-amdgpu-changes-for-linux-5-3?p=1108686#post1108686

I have to roll back before Navi commits to get working
'amd-staging-drm-next' kernel, again.

Maybe you have some 'spare' time despite all your Navi enablement work
to lift 'amd-staging-drm-next' to at least 5.2-rc6 (the Steam TCP
thing).

Greetings,
Dieter
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[amd-staging-drm-next] broken after Navi merge

2019-06-24 Thread Dieter Nützel


Hello Alex,

after your latest Navi merge 'amd-staging-drm-next' is broken with 
Polaris 20.


It hangs with very light gray (mostly black) screen after first mode 
switch.


Tested commit:
317d5033ab6c (HEAD -> amd-staging-drm-next, origin/amd-staging-drm-next) 
drm/amdgpu: add job->preamble_status back to status value


Even run mode 3|1 with grub2 do not works.

See also:
https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1108500-amd-sends-in-navi-support-other-remaining-amdgpu-changes-for-linux-5-3?p=1108686#post1108686

I have to roll back before Navi commits to get working 
'amd-staging-drm-next' kernel, again.


Maybe you have some 'spare' time despite all your Navi enablement work 
to lift 'amd-staging-drm-next' to at least 5.2-rc6 (the Steam TCP 
thing).


Greetings,
Dieter
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amd/powerplay/smu7_hwmgr: replace blocking delay with non-blocking

2019-06-12 Thread Dieter Nützel


CC trimmed

Hello Alex and Harry,

any comments on this?
I'm running my Xeon X3470 (4c/8t) with this under amd-staging-drm-next 
(as always ;-) ) and see no issues so far.


Thanks!
Dieter

Am 04.06.2019 22:21, schrieb Yrjan Skrimstad:

On Thu, May 30, 2019 at 02:08:21AM +0200, Yrjan Skrimstad wrote:

This driver currently contains a repeated 500ms blocking delay call
which causes frequent major buffer underruns in PulseAudio. This patch
fixes this issue by replacing the blocking delay with a non-blocking
sleep call.


I see that I have not explained this bug well enough, and I hope that 
is
the reason for the lack of replies on this patch. I will here attempt 
to

explain the situation better.

To start with some hardware description I am here using an AMD R9 380
GPU, an AMD Ryzen 7 1700 Eight-Core Processor and an AMD X370 chipset.
If any more hardware or software specifications are necessary, please
ask.

The bug is as follows: When playing audio I will regularly have major
audio issues, similar to that of a skipping CD. This is reported by
PulseAudio as scheduling delays and buffer underruns when running
PulseAudio verbosely and these scheduling delays are always just under
500ms, typically around 490ms. This makes listening to any music quite
the horrible experience as PulseAudio constantly will attempt to rewind
and catch up. It is not a great situation, and seems to me to quite
clearly be a case where regular user space behaviour has been broken.

I want to note that this audio problem was not something I experienced
until recently, it is therefore a new bug.

I have bisected the kernel to find out where the problem originated and
found the following commit:

# first bad commit: [f5742ec36422a39b57f0256e4847f61b3c432f8c]
drm/amd/powerplay: correct power reading on fiji

This commit introduces a blocking delay (mdelay) of 500ms, whereas the
old behaviour was a smaller blocking delay of only 1ms. This seems to 
me

to be very curious as the scheduling delays of PulseAudio are always
almost 500ms. I have therefore with the previous patch replaced the
scheduling delay with a non-blocking sleep (msleep).

The results of the patch seems promising as I have yet to encounter any
of the old <500ms scheduling delays when using it and I have also not
encountered any kernel log messages regarding sleeping in an atomic
context.
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v5 1/6] drm/amd/display: wait for fence without holding reservation lock

2019-04-22 Thread Dieter Nützel


Hello Andrey,

this series can't apply (brake on #3) on top of amd-staging-drm-next.
v2 works (Thu, 11 Apr 2019).

Dieter

Am 18.04.2019 17:00, schrieb Andrey Grodzovsky:

From: Christian König 

Don't block others while waiting for the fences to finish, concurrent
submission is perfectly valid in this case and holding the lock can
prevent killed applications from terminating.

Signed-off-by: Christian König 
Reviewed-by: Nicholas Kazlauskas 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

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 380a7f9..ad4f0e5 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4814,23 +4814,26 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
continue;
}

+   abo = gem_to_amdgpu_bo(fb->obj[0]);
+
+   /* Wait for all fences on this FB */
+   r = reservation_object_wait_timeout_rcu(abo->tbo.resv, true,
+   false,
+   MAX_SCHEDULE_TIMEOUT);
+   WARN_ON(r < 0);
+
/*
 * TODO This might fail and hence better not used, wait
 * explicitly on fences instead
 * and in general should be called for
 * blocking commit to as per framework helpers
 */
-   abo = gem_to_amdgpu_bo(fb->obj[0]);
r = amdgpu_bo_reserve(abo, true);
if (unlikely(r != 0)) {
DRM_ERROR("failed to reserve buffer before flip\n");
WARN_ON(1);
}

-   /* Wait for all fences on this FB */
-		WARN_ON(reservation_object_wait_timeout_rcu(abo->tbo.resv, true, 
false,

-   
MAX_SCHEDULE_TIMEOUT) < 0);
-
amdgpu_bo_get_tiling_flags(abo, _flags);

amdgpu_bo_unreserve(abo);

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re：[PATCH] drm/amdgpu: resvert "disable bulk moves for now"

2019-09-13 Thread Dieter Nützel


Hello Christian and David,

I've running Alex's 'amd-staging-drm-next' with it enabled.
Great numbers with vkmark (radv) and glmark2.

Sadly 'amd-staging-drm-next' still stands on 5.2.0-rc1 - no changes 
during the last 2 weeks.

Is Alex on vacation/traveling?

Greetings,
Dieter

[-]
Zhou, David(ChunMing) David1.Zhou at amd.com
Thu Sep 12 15:18:43 UTC 2019

I dont know dkms status，anyway, we should submit this one as early as 
possible.


 原始邮件 
主题：Re: [PATCH] drm/amdgpu: resvert "disable bulk moves for now"
发件人：Christian König
收件人："Zhou, David(ChunMing)" ,amd-gfx at lists.freedesktop.org
抄送：

Just to double check: We do have that enabled in the DKMS package for a
while and doesn't encounter any more problems with it, correct?

Thanks,
Christian.

Am 12.09.19 um 16:02 schrieb Chunming Zhou:

RB on it to go ahead.

-David

在 2019/9/12 18:15, Christian König 写道:

This reverts commit a213c2c7e235cfc0e0a161a558f7fdf2fb3a624a.

The changes to fix this should have landed in 5.1.

Signed-off-by: Christian König 
---
   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 --
   1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c

index 48349e4f0701..fd3fbaa73fa3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -603,14 +603,12 @@ void amdgpu_vm_move_to_lru_tail(struct 
amdgpu_device *adev,

  struct ttm_bo_global *glob = adev->mman.bdev.glob;
  struct amdgpu_vm_bo_base *bo_base;

-#if 0
  if (vm->bulk_moveable) {
  spin_lock(>lru_lock);
  ttm_bo_bulk_move_lru_tail(>lru_bulk_move);
  spin_unlock(>lru_lock);
  return;
  }
-#endif

  memset(>lru_bulk_move, 0, sizeof(vm->lru_bulk_move));


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[amd-staging-drm-nex] Planned move to 5.4-rc6+ soon?

2019-11-04 Thread Dieter Nützel


Hello Alex,

like AMD...;-)

[Why]
5.3-rcX (-rc3)
- has broken (regressed) block layer (CD/DVD, games...) - fixed in 5.3 
final

- ACPI (power management) regression - fixed in 5.3 final
- USB 3.1/3.2 regression (5.000 vs 10.000 Mbit/s mode, in use heavily 
here)
   even with AMD's partner ASMedia (ASM 2142+ chips) - fixed in 5.4-rc 
(!!!)

- Navi problems (e.g. SDMA) some progress/mitigation with 5.4-rc

[How]
Switch to 5.4-rc4 (or better -rc6) as soon as possible

Back to pp power consumption testing then...

Greetings,
Dieter
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Power consumption of Navi and Polaris

2019-11-04 Thread Dieter Nützel


Hello Alex et al.,

can you please have a look at this bug report and findings?

Sapphire Pulse RX 5700 XT power consumption
https://bugs.freedesktop.org/show_bug.cgi?id=111482
e.g.
https://bugs.freedesktop.org/show_bug.cgi?id=111482#c30

Thanks,
Dieter
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[amd-staging-drm-nex] Planned move to 5.3+ soon?

2019-09-20 Thread Dieter Nützel


Hello Alex,

after release of 5.3 my devel system was migrated to compressed firmware 
files.
So current 'amd-staging-drm-next' can't boot any longer and I can't test 
anything on it for you (AMD) ;-)


Greetings,
Dieter

PS I'm NOT on amd-gfx.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

41 matches

Mail list logo