RE: [PATCH] drm/amdgpu: correct clock info for SRIOV

2017-06-05 Thread Yu, Xiangliang 
> > Currently, get clock info from default clk of pm if dpm is disable.
> > Buf SRIOV doesn't support dpm and pm, can't get anything from pm.
> > Only get clock info only from default clk of amdgpu for SRIOV.
> >
> > And driver get pm default clk also from amdgpu default clk and never
> > be changed by others. So use amdgpu default clk value for SRIOV and
> > non-dpm cases.
> 
> This won't work for vega10 or Raven since we don't parse the default clock
> info on them anymore due to atom firmware changes.

I don't get the info.
Even so, we need to support this for VI family.

> 
> Alex
> 
> >
> > Signed-off-by: Xiangliang Yu 
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> > index 4947f04..1935f07 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> > @@ -530,8 +530,8 @@ static int amdgpu_info_ioctl(struct drm_device
> > *dev, void *data, struct drm_file
> > dev_info.max_engine_clock =
> > amdgpu_dpm_get_sclk(adev, false) * 10;
> > dev_info.max_memory_clock =
> > amdgpu_dpm_get_mclk(adev, false) * 10;
> > } else {
> > -   dev_info.max_engine_clock = adev-
> > >pm.default_sclk * 10;
> > -   dev_info.max_memory_clock = adev-
> > >pm.default_mclk * 10;
> > +   dev_info.max_engine_clock = adev-
> > >clock.default_sclk * 10;
> > +   dev_info.max_memory_clock = adev-
> > >clock.default_mclk * 10;
> > }
> > dev_info.enabled_rb_pipes_mask = adev-
> > >gfx.config.backend_enable_mask;
> > dev_info.num_rb_pipes = adev-
> > >gfx.config.max_backends_per_se *
> > --
> > 2.7.4
> >
> > ___
> > 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: Bug reports for beginners.

2017-06-05 Thread Michel Dänzer 
On 03/06/17 07:46 AM, Luke Miller wrote:
> 
> I have a recurring problem with one 3D program (UE4editor) crashing my
> computer during a particular operation.
> 
> I believe the problem is at the DRM layer.

It's actually more likely in Mesa. If you set either or both of the
following environment variables for running ue4editor:

R600_DEBUG=check_vm GALLIUM_DDEBUG="pipelined 1"

it should create a file in ~/ddebug_dumps/ with more information about
the GPU hang.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

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

Re: amd-gfx Digest, Vol 13, Issue 29

2017-06-05 Thread Michel Dänzer 
On 05/06/17 11:42 PM, Xie, AlexBin wrote:
> 
> I have found the original patch which introduce the duplicate code.
> 
> The patch is in:
> amd-gfx Digest, Vol 11, Issue 301

FYI, such a reference is useless for people who aren't subscribed to the
list in digest mode (which is presumably the majority). Better look it
up either in patchwork:

https://patchwork.freedesktop.org/project/amd-xorg-ddx/patches/

or in the list archives:

https://lists.freedesktop.org/archives/amd-gfx/2017-June/thread.html

and reference its URL there.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: . [PATCH] drm/amd/amdgpu: Fix ring initialization for GFX9

2017-06-05 Thread Andres Rodriguez 



On 2017-06-05 03:48 PM, Xie, AlexBin wrote:

Hi Andres,

I think the original patch was written by you. Would you comment? Is it a bug 
or intentional?

Thank you.

Alex Bin Xie


Message: 1
Date: Mon, 5 Jun 2017 10:36:59 -0400
From: Tom St Denis 
To: amd-gfx@lists.freedesktop.org
Subject: Re: amd-gfx Digest, Vol 13, Issue 29
Message-ID: <58773ac0-93a7-e494-d447-88e93ded9...@amd.com>
Content-Type: text/plain; charset=utf-8; format=flowed

On 05/06/17 10:24 AM, Xie, AlexBin wrote:

Hi, Tom,

You have found a bug.

Your patch looks fine for me.

Have you confirmed the deleted part is older version? Perhaps search email list 
or git history to confirm?


It looks like the edits to the older GFX files (7/8) simply changed that
block of code whereas the gfx9 version they pasted in the fixed block
moving the old block down.


Yeah there was a problem with the rebase here. Tom/Alex's fix on the 
mailing list is the intended solution.


Regards,
Andres



Tom


___
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] drm/amd/amdgpu: Fix ring initialization for GFX9

2017-06-05 Thread Xie, AlexBin 
Hi Andres,

I think the original patch was written by you. Would you comment? Is it a bug 
or intentional?

Thank you.

Alex Bin Xie


Message: 1
Date: Mon, 5 Jun 2017 10:36:59 -0400
From: Tom St Denis 
To: amd-gfx@lists.freedesktop.org
Subject: Re: amd-gfx Digest, Vol 13, Issue 29
Message-ID: <58773ac0-93a7-e494-d447-88e93ded9...@amd.com>
Content-Type: text/plain; charset=utf-8; format=flowed

On 05/06/17 10:24 AM, Xie, AlexBin wrote:
> Hi, Tom,
> 
> You have found a bug.
> 
> Your patch looks fine for me.
> 
> Have you confirmed the deleted part is older version? Perhaps search email 
> list or git history to confirm?

It looks like the edits to the older GFX files (7/8) simply changed that 
block of code whereas the gfx9 version they pasted in the fixed block 
moving the old block down.

Tom


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

Re: [PATCH i-g-t] tests/kms_setmode: Dynamic crtc/connector combinations

2017-06-05 Thread Harry Wentland 

On 2017-06-05 03:50 PM, Alex Deucher wrote:

On Mon, Jun 5, 2017 at 2:43 PM, Harry Wentland  wrote:

Create crtc/connector combinations based on actual adapter
information obtained from drmModeRes.

Also set MAX_CRTCs to 6 for AMD GPUs.

Signed-off-by: Harry Wentland 


The code is kind of hard to follow, but it looks good to me:
Acked-by: Alex Deucher 



I agree, that's why I only tried to limit the scope of this patch to the 
size of the combinations struct.


Thanks for the Ack. Is it okay to merge into drm/igt-gpu-tools? Do you 
know what the rules are on that? 
https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-intel.html is 
quite vague on IGT patches.


Harry


---
  tests/kms_setmode.c | 24 ++--
  1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/tests/kms_setmode.c b/tests/kms_setmode.c
index 430568a1c24e..a7a48de44b0e 100644
--- a/tests/kms_setmode.c
+++ b/tests/kms_setmode.c
@@ -31,15 +31,13 @@
  #include 
  #include 
  #include 
-
+#include 
  #include "intel_bufmgr.h"

  #define MAX_CONNECTORS  10
-#define MAX_CRTCS   3
+#define MAX_CRTCS   6

  /* max combinations with repetitions */
-#define MAX_COMBINATION_COUNT   \
-   (MAX_CONNECTORS * MAX_CONNECTORS * MAX_CONNECTORS)
  #define MAX_COMBINATION_ELEMS   MAX_CRTCS

  static int drm_fd;
@@ -702,7 +700,8 @@ struct combination {

  struct combination_set {
 int count;
-   struct combination items[MAX_COMBINATION_COUNT];
+   int capacity;
+   struct combination *items;
  };

  /*
@@ -716,7 +715,7 @@ static void iterate_combinations(int n, int k, bool 
allow_repetitions,
 int v;

 if (!k) {
-   igt_assert(set->count < ARRAY_SIZE(set->items));
+   igt_assert(set->count < set->capacity);
 set->items[set->count++] = *comb;
 return;
 }
@@ -751,6 +750,16 @@ static void test_combinations(const struct test_config 
*tconf,
 if (connector_count > 2 && (tconf->flags & TEST_STEALING))
 return;

+   igt_assert(tconf->resources);
+
+   connector_combs.capacity = pow(tconf->resources->count_connectors,
+  tconf->resources->count_crtcs + 1);
+   crtc_combs.capacity = pow(tconf->resources->count_crtcs,
+ tconf->resources->count_crtcs + 1);
+
+   connector_combs.items = malloc(connector_combs.capacity * sizeof(struct 
combination));
+   crtc_combs.items = malloc(crtc_combs.capacity * sizeof(struct 
combination));
+
 get_combinations(tconf->resources->count_connectors, connector_count,
  false, _combs);
 get_combinations(tconf->resources->count_crtcs, connector_count,
@@ -787,6 +796,9 @@ static void test_combinations(const struct test_config 
*tconf,
  free_cconfs:
 free(cconfs);
 }
+
+   free(connector_combs.items);
+   free(crtc_combs.items);
  }

  static void run_test(const struct test_config *tconf)
--
2.11.0

___
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 i-g-t] tests/kms_setmode: Dynamic crtc/connector combinations

2017-06-05 Thread Alex Deucher 
On Mon, Jun 5, 2017 at 2:43 PM, Harry Wentland  wrote:
> Create crtc/connector combinations based on actual adapter
> information obtained from drmModeRes.
>
> Also set MAX_CRTCs to 6 for AMD GPUs.
>
> Signed-off-by: Harry Wentland 

The code is kind of hard to follow, but it looks good to me:
Acked-by: Alex Deucher 

> ---
>  tests/kms_setmode.c | 24 ++--
>  1 file changed, 18 insertions(+), 6 deletions(-)
>
> diff --git a/tests/kms_setmode.c b/tests/kms_setmode.c
> index 430568a1c24e..a7a48de44b0e 100644
> --- a/tests/kms_setmode.c
> +++ b/tests/kms_setmode.c
> @@ -31,15 +31,13 @@
>  #include 
>  #include 
>  #include 
> -
> +#include 
>  #include "intel_bufmgr.h"
>
>  #define MAX_CONNECTORS  10
> -#define MAX_CRTCS   3
> +#define MAX_CRTCS   6
>
>  /* max combinations with repetitions */
> -#define MAX_COMBINATION_COUNT   \
> -   (MAX_CONNECTORS * MAX_CONNECTORS * MAX_CONNECTORS)
>  #define MAX_COMBINATION_ELEMS   MAX_CRTCS
>
>  static int drm_fd;
> @@ -702,7 +700,8 @@ struct combination {
>
>  struct combination_set {
> int count;
> -   struct combination items[MAX_COMBINATION_COUNT];
> +   int capacity;
> +   struct combination *items;
>  };
>
>  /*
> @@ -716,7 +715,7 @@ static void iterate_combinations(int n, int k, bool 
> allow_repetitions,
> int v;
>
> if (!k) {
> -   igt_assert(set->count < ARRAY_SIZE(set->items));
> +   igt_assert(set->count < set->capacity);
> set->items[set->count++] = *comb;
> return;
> }
> @@ -751,6 +750,16 @@ static void test_combinations(const struct test_config 
> *tconf,
> if (connector_count > 2 && (tconf->flags & TEST_STEALING))
> return;
>
> +   igt_assert(tconf->resources);
> +
> +   connector_combs.capacity = pow(tconf->resources->count_connectors,
> +  tconf->resources->count_crtcs + 1);
> +   crtc_combs.capacity = pow(tconf->resources->count_crtcs,
> + tconf->resources->count_crtcs + 1);
> +
> +   connector_combs.items = malloc(connector_combs.capacity * 
> sizeof(struct combination));
> +   crtc_combs.items = malloc(crtc_combs.capacity * sizeof(struct 
> combination));
> +
> get_combinations(tconf->resources->count_connectors, connector_count,
>  false, _combs);
> get_combinations(tconf->resources->count_crtcs, connector_count,
> @@ -787,6 +796,9 @@ static void test_combinations(const struct test_config 
> *tconf,
>  free_cconfs:
> free(cconfs);
> }
> +
> +   free(connector_combs.items);
> +   free(crtc_combs.items);
>  }
>
>  static void run_test(const struct test_config *tconf)
> --
> 2.11.0
>
> ___
> 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: Bug reports for beginners.

2017-06-05 Thread Alex Deucher 
On Mon, Jun 5, 2017 at 2:36 PM, Harry Wentland  wrote:
> Hi Luke,
>
> the first things to check would be the saved kern.log and Xorg.0.log from
> before the crash occured. Both should be in /var/log. These logs will keep a
> long record but you should be able to find the bad run as kern.log is
> timestamped and with Xorg.0.log you should be able to scroll back to the
> previous X run.
>
> That might give some indication, either by logging an error or even showing
> a stack trace, but sometimes they don't flush out completely when the system
> crashes.
>
> Some of the other experts on here (Alex, Michel, Christian, etc) might give
> you more ideas should these logs not show anything.

Basically include your xorg log and dmesg output and a description of
the problem you are seeing.  If possible, can you get remote access to
the system (e.g., ssh)?  If you lose your console, you can still get
the logs remotely.  Another option would be to blacklist the driver
(append modprobe.blacklist=radeon,amdgpu to the kernel command line in
grub) and then boot to a non-X runlevel.   Then manually load the
driver (modprobe radeon or modprobe amdgpu) and see if you can get
better logs.

Alex

>
> Harry
>
>
> On 2017-06-02 06:46 PM, Luke Miller wrote:
>>
>> Greetings, thanks for the awesome drivers.
>>
>> I have a recurring problem with one 3D program (UE4editor) crashing my
>> computer during a particular operation.
>>
>> I believe the problem is at the DRM layer.
>>
>> Brief details:
>> Radeon 7850HD
>> It crashes using radeon and amdgpu (on ubuntu 17.04, linux 4.12, padoka
>> ppa).
>> It does not crash using the fglrx driver (on ubuntu 14.04).
>> The entire machine hangs and requires a reset.
>>
>> My question:
>> How can I go about collecting more information to fix/report the problem?
>> Is there a tutorial on which logs to look at? I may even be able to fix it
>> myself if I could get a stack trace.
>>
>> Part of the fun is that it is an older card.
>>
>>
>>
>>
>>
>>
>> ___
>> 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

RE: [PATCH drm] tests/amdgpu: Fix device_id option

2017-06-05 Thread Deucher, Alexander 
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Tom St Denis
> Sent: Monday, June 05, 2017 2:04 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: StDenis, Tom
> Subject: [PATCH drm] tests/amdgpu: Fix device_id option
> 
> The device_id option [-d] was badly broken.  This commit fixes
> the width (was 8 is now 16 bits) as well as enables searches
> without specifying a bus id.  It was also comparing "dev" from
> the bus field which is not the PCI device id.
> 
> Signed-off-by: Tom St Denis 

Reviewed-by: Alex Deucher 

> ---
>  tests/amdgpu/amdgpu_test.c | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/tests/amdgpu/amdgpu_test.c b/tests/amdgpu/amdgpu_test.c
> index 3fd6820a1ecf..546a01115603 100644
> --- a/tests/amdgpu/amdgpu_test.c
> +++ b/tests/amdgpu/amdgpu_test.c
> @@ -264,25 +264,25 @@ static void amdgpu_print_devices()
>  /* Find a match AMD device in PCI bus
>   * Return the index of the device or -1 if not found
>   */
> -static int amdgpu_find_device(uint8_t bus, uint8_t dev)
> +static int amdgpu_find_device(uint8_t bus, uint16_t dev)
>  {
>   int i;
>   drmDevicePtr device;
> 
> - for (i = 0; i < MAX_CARDS_SUPPORTED && drm_amdgpu[i] >=0; i++)
> + for (i = 0; i < MAX_CARDS_SUPPORTED && drm_amdgpu[i] >= 0; i++)
> {
>   if (drmGetDevice2(drm_amdgpu[i],
>   DRM_DEVICE_GET_PCI_REVISION,
>   ) == 0) {
>   if (device->bustype == DRM_BUS_PCI)
> - if (device->businfo.pci->bus == bus &&
> - device->businfo.pci->dev == dev) {
> -
> + if ((bus == 0xFF || device->businfo.pci->bus
> == bus) &&
> + device->deviceinfo.pci->device_id ==
> dev) {
>   drmFreeDevice();
>   return i;
>   }
> 
>   drmFreeDevice();
>   }
> + }
> 
>   return -1;
>  }
> @@ -325,7 +325,7 @@ int main(int argc, char **argv)
>   pci_bus_id = atoi(optarg);
>   break;
>   case 'd':
> - pci_device_id = atoi(optarg);
> + sscanf(optarg, "%x", _device_id);
>   break;
>   case 'p':
>   display_devices = 1;
> @@ -359,10 +359,10 @@ int main(int argc, char **argv)
>   exit(EXIT_SUCCESS);
>   }
> 
> - if (pci_bus_id > 0) {
> + if (pci_bus_id > 0 || pci_device_id) {
>   /* A device was specified to run the test */
> - test_device_index =
> amdgpu_find_device((uint8_t)pci_bus_id,
> -
>   (uint8_t)pci_device_id);
> + test_device_index = amdgpu_find_device(pci_bus_id,
> +pci_device_id);
> 
>   if (test_device_index >= 0) {
>   /* Most tests run on device of drm_amdgpu[0].
> --
> 2.12.0
> 
> ___
> 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

[PATCH i-g-t] tests/kms_setmode: Dynamic crtc/connector combinations

2017-06-05 Thread Harry Wentland 
Create crtc/connector combinations based on actual adapter
information obtained from drmModeRes.

Also set MAX_CRTCs to 6 for AMD GPUs.

Signed-off-by: Harry Wentland 
---
 tests/kms_setmode.c | 24 ++--
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/tests/kms_setmode.c b/tests/kms_setmode.c
index 430568a1c24e..a7a48de44b0e 100644
--- a/tests/kms_setmode.c
+++ b/tests/kms_setmode.c
@@ -31,15 +31,13 @@
 #include 
 #include 
 #include 
-
+#include 
 #include "intel_bufmgr.h"
 
 #define MAX_CONNECTORS  10
-#define MAX_CRTCS   3
+#define MAX_CRTCS   6
 
 /* max combinations with repetitions */
-#define MAX_COMBINATION_COUNT   \
-   (MAX_CONNECTORS * MAX_CONNECTORS * MAX_CONNECTORS)
 #define MAX_COMBINATION_ELEMS   MAX_CRTCS
 
 static int drm_fd;
@@ -702,7 +700,8 @@ struct combination {
 
 struct combination_set {
int count;
-   struct combination items[MAX_COMBINATION_COUNT];
+   int capacity;
+   struct combination *items;
 };
 
 /*
@@ -716,7 +715,7 @@ static void iterate_combinations(int n, int k, bool 
allow_repetitions,
int v;
 
if (!k) {
-   igt_assert(set->count < ARRAY_SIZE(set->items));
+   igt_assert(set->count < set->capacity);
set->items[set->count++] = *comb;
return;
}
@@ -751,6 +750,16 @@ static void test_combinations(const struct test_config 
*tconf,
if (connector_count > 2 && (tconf->flags & TEST_STEALING))
return;
 
+   igt_assert(tconf->resources);
+
+   connector_combs.capacity = pow(tconf->resources->count_connectors,
+  tconf->resources->count_crtcs + 1);
+   crtc_combs.capacity = pow(tconf->resources->count_crtcs,
+ tconf->resources->count_crtcs + 1);
+
+   connector_combs.items = malloc(connector_combs.capacity * sizeof(struct 
combination));
+   crtc_combs.items = malloc(crtc_combs.capacity * sizeof(struct 
combination));
+
get_combinations(tconf->resources->count_connectors, connector_count,
 false, _combs);
get_combinations(tconf->resources->count_crtcs, connector_count,
@@ -787,6 +796,9 @@ static void test_combinations(const struct test_config 
*tconf,
 free_cconfs:
free(cconfs);
}
+
+   free(connector_combs.items);
+   free(crtc_combs.items);
 }
 
 static void run_test(const struct test_config *tconf)
-- 
2.11.0

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

Re: Bug reports for beginners.

2017-06-05 Thread Harry Wentland 

Hi Luke,

the first things to check would be the saved kern.log and Xorg.0.log 
from before the crash occured. Both should be in /var/log. These logs 
will keep a long record but you should be able to find the bad run as 
kern.log is timestamped and with Xorg.0.log you should be able to scroll 
back to the previous X run.


That might give some indication, either by logging an error or even 
showing a stack trace, but sometimes they don't flush out completely 
when the system crashes.


Some of the other experts on here (Alex, Michel, Christian, etc) might 
give you more ideas should these logs not show anything.


Harry

On 2017-06-02 06:46 PM, Luke Miller wrote:

Greetings, thanks for the awesome drivers.

I have a recurring problem with one 3D program (UE4editor) crashing my 
computer during a particular operation.


I believe the problem is at the DRM layer.

Brief details:
Radeon 7850HD
It crashes using radeon and amdgpu (on ubuntu 17.04, linux 4.12, padoka 
ppa).

It does not crash using the fglrx driver (on ubuntu 14.04).
The entire machine hangs and requires a reset.

My question:
How can I go about collecting more information to fix/report the 
problem? Is there a tutorial on which logs to look at? I may even be 
able to fix it myself if I could get a stack trace.


Part of the fun is that it is an older card.






___
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 2/2] drm/amdgpu/gfx9: new queue policy, take first 2 queues of each pipe

2017-06-05 Thread Andres Rodriguez 

Reviewed-by: Andres Rodriguez 

-Andres

On 2017-06-05 11:06 AM, Alex Deucher wrote:

Instead of taking the first pipe and giving the rest to kfd, take the
first 2 queues of each pipe.

Effectively, amdgpu and amdkfd own the same number of queues. But
because the queues are spread over multiple pipes the hardware will be
able to better handle concurrent compute workloads.

amdgpu goes from 1 pipe to 4 pipes, i.e. from 1 compute threads to 4
amdkfd goes from 3 pipe to 4 pipes, i.e. from 3 compute threads to 4

gfx9 was missed when this patch set was rebased to include gfx9.

Signed-off-by: Alex Deucher 
---
  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index 0c48f6c..276dc06 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -873,8 +873,8 @@ static void gfx_v9_0_compute_queue_acquire(struct 
amdgpu_device *adev)
if (mec >= adev->gfx.mec.num_mec)
break;
  
-		/* policy: amdgpu owns all queues in the first pipe */

-   if (mec == 0 && pipe == 0)
+   /* policy: amdgpu owns the first two queues of the first MEC */
+   if (mec == 0 && queue < 2)
set_bit(i, adev->gfx.mec.queue_bitmap);
}
  


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

RE: [PATCH libdrm v6 1/1] amdgpu: move asic id table to a separate file

2017-06-05 Thread Li, Samuel 
> what is the purpose of the file version
The initial purpose is to act like a version tag, not necessarily format 
related. 

Sam

-Original Message-
From: Michel Dänzer [mailto:mic...@daenzer.net] 
Sent: Sunday, June 04, 2017 10:10 PM
To: Li, Samuel 
Cc: amd-gfx@lists.freedesktop.org; Yuan, Xiaojie 
Subject: Re: [PATCH libdrm v6 1/1] amdgpu: move asic id table to a separate file

On 01/06/17 05:22 AM, Samuel Li wrote:
> From: Xiaojie Yuan 
> 
> v2: fix an off by one error and leading white spaces
> v3: use thread safe strtok_r(); initialize len before calling getline();
> change printf() to drmMsg(); add initial amdgpu.ids
> v4: integrate some recent internal changes, including format changes
> v5: fix line number for empty/commented lines; realloc to save memory; 
> indentation changes
> v6: remove a line error
> 
> Change-Id: I12216da14910f5e2b0970bc1fafc2a20b0ef1ba9
> Reviewed-by: Junwei Zhang 
> Signed-off-by: Samuel Li 

[...]

> + /* 1st valid line is file version */
> + while ((n = getline(, , fp)) != -1) {
> + /* trim trailing newline */
> + if (line[n - 1] == '\n')
> + line[n - 1] = '\0';
> +
> + /* ignore empty line and commented line */
> + if (strlen(line) == 0 || line[0] == '#') {
> + line_num++;
> + continue;
> + }
> +
> + drmMsg("%s version: %s\n", AMDGPU_ASIC_ID_TABLE, line);
> + break;
> + }

BTW, what is the purpose of the file version? If it's about the format of the 
file, we need to check here that the file has a format we can parse, something 
like

if ( != 1)
return -EINVAL;


Note that making backwards incompatible changes to the file format would pretty 
much kill the idea of updating the file with a script like update-pciids.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: number of rings broken

2017-06-05 Thread Tom St Denis 

On 05/06/17 11:32 AM, Alex Deucher wrote:

On Mon, Jun 5, 2017 at 7:34 AM, Tom St Denis  wrote:

Hi all,

Just back after a week off ... first thing I see on my vega10 system is this
patch:

83866f0fc72017d55f40cbd4160cd1e42a2cc3a8 is the first bad commit
commit 83866f0fc72017d55f40cbd4160cd1e42a2cc3a8
Author: Andres Rodriguez 
Date:   Thu Feb 2 00:38:22 2017 -0500

 drm/amdgpu: allow split of queues with kfd at queue granularity v4

 Previously the queue/pipe split with kfd operated with pipe
 granularity. This patch allows amdgpu to take ownership of an arbitrary
 set of queues.

 It also consolidates the last few magic numbers in the compute
 initialization process into mec_init.

 v2: support for gfx9
 v3: renamed AMDGPU_MAX_QUEUES to AMDGPU_MAX_COMPUTE_QUEUES
 v4: fix off-by-one in num_mec checks in *_compute_queue_acquire

 Reviewed-by: Edward O'Callaghan 
 Reviewed-by: Felix Kuehling 
 Acked-by: Christian König 
 Signed-off-by: Andres Rodriguez 
 Signed-off-by: Alex Deucher 

:04 04 cafdad84e9fd950112e9ff56956526fa47dcaa59
48647a91855c0b2d4b3dfedffb89bd93da25c0eb M  drivers


Looks like some of Andres' later patches were not properly rebased for
gfx9.  Do to the two patches I send out this morning help?


By visual inspection patch 1/2 seems to copy the patch I sent to the 
list this morning. I'll apply both on top of stg-4.11 and see what pops out.


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

Re: number of rings broken

2017-06-05 Thread Alex Deucher 
On Mon, Jun 5, 2017 at 7:34 AM, Tom St Denis  wrote:
> Hi all,
>
> Just back after a week off ... first thing I see on my vega10 system is this
> patch:
>
> 83866f0fc72017d55f40cbd4160cd1e42a2cc3a8 is the first bad commit
> commit 83866f0fc72017d55f40cbd4160cd1e42a2cc3a8
> Author: Andres Rodriguez 
> Date:   Thu Feb 2 00:38:22 2017 -0500
>
> drm/amdgpu: allow split of queues with kfd at queue granularity v4
>
> Previously the queue/pipe split with kfd operated with pipe
> granularity. This patch allows amdgpu to take ownership of an arbitrary
> set of queues.
>
> It also consolidates the last few magic numbers in the compute
> initialization process into mec_init.
>
> v2: support for gfx9
> v3: renamed AMDGPU_MAX_QUEUES to AMDGPU_MAX_COMPUTE_QUEUES
> v4: fix off-by-one in num_mec checks in *_compute_queue_acquire
>
> Reviewed-by: Edward O'Callaghan 
> Reviewed-by: Felix Kuehling 
> Acked-by: Christian König 
> Signed-off-by: Andres Rodriguez 
> Signed-off-by: Alex Deucher 
>
> :04 04 cafdad84e9fd950112e9ff56956526fa47dcaa59
> 48647a91855c0b2d4b3dfedffb89bd93da25c0eb M  drivers

Looks like some of Andres' later patches were not properly rebased for
gfx9.  Do to the two patches I send out this morning help?

Thanks,

Alex


>
> Causes the driver to fail to init properly with these messages:
>
> [   21.983487] [drm] amdgpu: irq initialized.
> [   22.012073] amdgpu: [powerplay] amdgpu: powerplay sw initialized
> [   22.015161] amdgpu :03:00.0: fence driver on ring 0 use gpu addr
> 0x00f5ff08, cpu addr 0x8802143fc008
> [   22.015208] amdgpu :03:00.0: fence driver on ring 1 use gpu addr
> 0x00f5ff10, cpu addr 0x8802143fc010
> [   22.015243] amdgpu :03:00.0: fence driver on ring 2 use gpu addr
> 0x00f5ff18, cpu addr 0x8802143fc018
> [   22.015278] amdgpu :03:00.0: fence driver on ring 3 use gpu addr
> 0x00f5ff28, cpu addr 0x8802143fc028
> [   22.015310] amdgpu :03:00.0: fence driver on ring 4 use gpu addr
> 0x00f5ff30, cpu addr 0x8802143fc030
> [   22.015342] amdgpu :03:00.0: fence driver on ring 5 use gpu addr
> 0x00f5ff38, cpu addr 0x8802143fc038
> [   22.015374] amdgpu :03:00.0: fence driver on ring 6 use gpu addr
> 0x00f5ff48, cpu addr 0x8802143fc048
> [   22.015412] amdgpu :03:00.0: fence driver on ring 7 use gpu addr
> 0x00f5ff50, cpu addr 0x8802143fc050
> [   22.015445] amdgpu :03:00.0: fence driver on ring 8 use gpu addr
> 0x00f5ff58, cpu addr 0x8802143fc058
> [   22.015457] amdgpu :03:00.0: fence driver on ring 1 use gpu addr
> 0x00f5ff68, cpu addr 0x8802143fc068
> [   22.015565] [drm:amdgpu_ring_init [amdgpu]] *ERROR* Failed to register
> debugfs file for rings !
> [   22.015573] amdgpu :03:00.0: fence driver on ring 2 use gpu addr
> 0x00f5ff70, cpu addr 0x8802143fc070
> [   22.015616] [drm:amdgpu_ring_init [amdgpu]] *ERROR* Failed to register
> debugfs file for rings !
> [   22.015620] amdgpu :03:00.0: fence driver on ring 3 use gpu addr
> 0x00f5ff78, cpu addr 0x8802143fc078
> [   22.015660] [drm:amdgpu_ring_init [amdgpu]] *ERROR* Failed to register
> debugfs file for rings !
> [   22.015663] amdgpu :03:00.0: fence driver on ring 4 use gpu addr
> 0x00f5ff88, cpu addr 0x8802143fc088
> [   22.015702] [drm:amdgpu_ring_init [amdgpu]] *ERROR* Failed to register
> debugfs file for rings !
> [   22.015705] amdgpu :03:00.0: fence driver on ring 5 use gpu addr
> 0x00f5ff90, cpu addr 0x8802143fc090
> [   22.015745] [drm:amdgpu_ring_init [amdgpu]] *ERROR* Failed to register
> debugfs file for rings !
> [   22.015748] amdgpu :03:00.0: fence driver on ring 6 use gpu addr
> 0x00f5ff98, cpu addr 0x8802143fc098
> [   22.015787] [drm:amdgpu_ring_init [amdgpu]] *ERROR* Failed to register
> debugfs file for rings !
> [   22.015792] amdgpu :03:00.0: fence driver on ring 7 use gpu addr
> 0x00f5ffa8, cpu addr 0x8802143fc0a8
> [   22.015836] [drm:amdgpu_ring_init [amdgpu]] *ERROR* Failed to register
> debugfs file for rings !
> [   22.015842] amdgpu :03:00.0: fence driver on ring 8 use gpu addr
> 0x00f5ffb0, cpu addr 0x8802143fc0b0
> [   22.015881] [drm:amdgpu_ring_init [amdgpu]] *ERROR* Failed to register
> debugfs file for rings !
> [   22.015920] [drm:gfx_v9_0_sw_init [amdgpu]] *ERROR* Too many (8) compute
> rings!
>
> I haven't diagnosed why that is a problem but effectively various constants
> have changed it seems.  On the same system the module inits for carrizo just
> fine so it seems to be a GFX9 issue.
>
> Tom
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
>

RE: [PATCH] drm/amdgpu: correct clock info for SRIOV

2017-06-05 Thread Deucher, Alexander 
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Xiangliang Yu
> Sent: Saturday, June 03, 2017 5:45 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Yu, Xiangliang
> Subject: [PATCH] drm/amdgpu: correct clock info for SRIOV
> 
> Currently, get clock info from default clk of pm if dpm is disable.
> Buf SRIOV doesn't support dpm and pm, can't get anything from pm.
> Only get clock info only from default clk of amdgpu for SRIOV.
> 
> And driver get pm default clk also from amdgpu default clk and never
> be changed by others. So use amdgpu default clk value for SRIOV
> and non-dpm cases.

This won't work for vega10 or Raven since we don't parse the default clock info 
on them anymore due to atom firmware changes.

Alex

> 
> Signed-off-by: Xiangliang Yu 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> index 4947f04..1935f07 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> @@ -530,8 +530,8 @@ static int amdgpu_info_ioctl(struct drm_device *dev,
> void *data, struct drm_file
>   dev_info.max_engine_clock =
> amdgpu_dpm_get_sclk(adev, false) * 10;
>   dev_info.max_memory_clock =
> amdgpu_dpm_get_mclk(adev, false) * 10;
>   } else {
> - dev_info.max_engine_clock = adev-
> >pm.default_sclk * 10;
> - dev_info.max_memory_clock = adev-
> >pm.default_mclk * 10;
> + dev_info.max_engine_clock = adev-
> >clock.default_sclk * 10;
> + dev_info.max_memory_clock = adev-
> >clock.default_mclk * 10;
>   }
>   dev_info.enabled_rb_pipes_mask = adev-
> >gfx.config.backend_enable_mask;
>   dev_info.num_rb_pipes = adev-
> >gfx.config.max_backends_per_se *
> --
> 2.7.4
> 
> ___
> 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

[PATCH 1/2] drm/amdgpu/gfx9: allocate queues horizontally across pipes

2017-06-05 Thread Alex Deucher 
Pipes provide better concurrency than queues, therefore we want to make
sure that apps use queues from different pipes whenever possible.

Optimize for the trivial case where an app will consume rings in order,
therefore we don't want adjacent rings to belong to the same pipe.

gfx9 was missed when these patches were rebased.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 115 +++---
 1 file changed, 52 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index 9502353..0c48f6c 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -1483,9 +1483,44 @@ static int gfx_v9_0_ngg_en(struct amdgpu_device *adev)
return 0;
 }
 
+static int gfx_v9_0_compute_ring_init(struct amdgpu_device *adev, int ring_id,
+ int mec, int pipe, int queue)
+{
+   int r;
+   unsigned irq_type;
+   struct amdgpu_ring *ring = >gfx.compute_ring[ring_id];
+
+   ring = >gfx.compute_ring[ring_id];
+
+   /* mec0 is me1 */
+   ring->me = mec + 1;
+   ring->pipe = pipe;
+   ring->queue = queue;
+
+   ring->ring_obj = NULL;
+   ring->use_doorbell = true;
+   ring->doorbell_index = AMDGPU_DOORBELL_MEC_RING0 + ring_id;
+   ring->eop_gpu_addr = adev->gfx.mec.hpd_eop_gpu_addr
+   + (ring_id * GFX9_MEC_HPD_SIZE);
+   sprintf(ring->name, "comp_%d.%d.%d", ring->me, ring->pipe, ring->queue);
+
+   irq_type = AMDGPU_CP_IRQ_COMPUTE_MEC1_PIPE0_EOP
+   + ((ring->me - 1) * adev->gfx.mec.num_pipe_per_mec)
+   + ring->pipe;
+
+   /* type-2 packets are deprecated on MEC, use type-3 instead */
+   r = amdgpu_ring_init(adev, ring, 1024,
+>gfx.eop_irq, irq_type);
+   if (r)
+   return r;
+
+
+   return 0;
+}
+
 static int gfx_v9_0_sw_init(void *handle)
 {
-   int i, r, ring_id;
+   int i, j, k, r, ring_id;
struct amdgpu_ring *ring;
struct amdgpu_kiq *kiq;
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
@@ -1547,69 +1582,23 @@ static int gfx_v9_0_sw_init(void *handle)
return r;
}
 
-   /* set up the compute queues */
-   for (i = 0, ring_id = 0; i < AMDGPU_MAX_COMPUTE_QUEUES; i++) {
-   unsigned irq_type;
-
-   if (!test_bit(i, adev->gfx.mec.queue_bitmap))
-   continue;
-
-   if (WARN_ON(ring_id >= AMDGPU_MAX_COMPUTE_RINGS))
-   break;
-
-   ring = >gfx.compute_ring[ring_id];
-
-   /* mec0 is me1 */
-   ring->me = ((i / adev->gfx.mec.num_queue_per_pipe)
-   / adev->gfx.mec.num_pipe_per_mec)
-   + 1;
-   ring->pipe = (i / adev->gfx.mec.num_queue_per_pipe)
-   % adev->gfx.mec.num_pipe_per_mec;
-   ring->queue = i % adev->gfx.mec.num_queue_per_pipe;
-
-   ring->ring_obj = NULL;
-   ring->use_doorbell = true;
-   ring->eop_gpu_addr = adev->gfx.mec.hpd_eop_gpu_addr + (ring_id 
* GFX9_MEC_HPD_SIZE);
-   ring->doorbell_index = AMDGPU_DOORBELL_MEC_RING0 + ring_id;
-   sprintf(ring->name, "comp_%d.%d.%d", ring->me, ring->pipe, 
ring->queue);
-
-   irq_type = AMDGPU_CP_IRQ_COMPUTE_MEC1_PIPE0_EOP
-   + ((ring->me - 1) * adev->gfx.mec.num_pipe_per_mec)
-   + ring->pipe;
-
-   /* type-2 packets are deprecated on MEC, use type-3 instead */
-   r = amdgpu_ring_init(adev, ring, 1024, >gfx.eop_irq,
-irq_type);
-   if (r)
-   return r;
-
-   ring_id++;
-   }
-
-   /* set up the compute queues */
-   for (i = 0, ring_id = 0; i < AMDGPU_MAX_COMPUTE_QUEUES; i++) {
-   unsigned irq_type;
-
-   /* max 32 queues per MEC */
-   if ((i >= 32) || (i >= AMDGPU_MAX_COMPUTE_RINGS)) {
-   DRM_ERROR("Too many (%d) compute rings!\n", i);
-   break;
+   /* set up the compute queues - allocate horizontally across pipes */
+   ring_id = 0;
+   for (i = 0; i < adev->gfx.mec.num_mec; ++i) {
+   for (j = 0; j < adev->gfx.mec.num_queue_per_pipe; j++) {
+   for (k = 0; k < adev->gfx.mec.num_pipe_per_mec; k++) {
+   if (!amdgpu_is_mec_queue_enabled(adev, i, k, j))
+   continue;
+
+   r = gfx_v9_0_compute_ring_init(adev,
+  ring_id,
+  i, k, j);
+

RE: amd-gfx Digest, Vol 13, Issue 29

2017-06-05 Thread Xie, AlexBin 
Hi Tom,

I have found the original patch which introduce the duplicate code.

The patch is in:
amd-gfx Digest, Vol 11, Issue 301

Alex Bin Xie

-Original Message-
From: Xie, AlexBin 
Sent: Monday, June 5, 2017 10:25 AM
To: amd-gfx@lists.freedesktop.org
Subject: RE: amd-gfx Digest, Vol 13, Issue 29

Hi, Tom,

You have found a bug.

Your patch looks fine for me.

Have you confirmed the deleted part is older version? Perhaps search email list 
or git history to confirm? 

Alex Bin Xie

-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of 
amd-gfx-requ...@lists.freedesktop.org
Sent: Monday, June 5, 2017 8:00 AM
To: amd-gfx@lists.freedesktop.org
Subject: amd-gfx Digest, Vol 13, Issue 29

Send amd-gfx mailing list submissions to
amd-gfx@lists.freedesktop.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
or, via email, send a message with subject or body 'help' to
amd-gfx-requ...@lists.freedesktop.org

You can reach the person managing the list at
amd-gfx-ow...@lists.freedesktop.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of amd-gfx digest..."


Today's Topics:

   1. [PATCH] drm/amd/amdgpu:  Fix ring initialization for GFX9
  (Tom St Denis)


--

Message: 1
Date: Mon,  5 Jun 2017 07:46:01 -0400
From: Tom St Denis 
To: amd-gfx@lists.freedesktop.org
Cc: Tom St Denis 
Subject: [PATCH] drm/amd/amdgpu:  Fix ring initialization for GFX9
Message-ID: <20170605114601.11995-1-tom.stde...@amd.com>
Content-Type: text/plain

The commit 83866f0fc72017d55f40cbd4160cd1e42a2cc3a8 erroneously included the
old ring init sequence along with the new one which uses shared header 
definitions.

The fix which works on my vega10 seems to be to drop the old init sequence.

Signed-off-by: Tom St Denis 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 26 --
 1 file changed, 26 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index 9502353ec325..8388893e0b11 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -1586,32 +1586,6 @@ static int gfx_v9_0_sw_init(void *handle)
ring_id++;
}
 
-   /* set up the compute queues */
-   for (i = 0, ring_id = 0; i < AMDGPU_MAX_COMPUTE_QUEUES; i++) {
-   unsigned irq_type;
-
-   /* max 32 queues per MEC */
-   if ((i >= 32) || (i >= AMDGPU_MAX_COMPUTE_RINGS)) {
-   DRM_ERROR("Too many (%d) compute rings!\n", i);
-   break;
-   }
-   ring = >gfx.compute_ring[i];
-   ring->ring_obj = NULL;
-   ring->use_doorbell = true;
-   ring->doorbell_index = (AMDGPU_DOORBELL64_MEC_RING0 + i) << 1;
-   ring->me = 1; /* first MEC */
-   ring->pipe = i / 8;
-   ring->queue = i % 8;
-   ring->eop_gpu_addr = adev->gfx.mec.hpd_eop_gpu_addr + (i * 
GFX9_MEC_HPD_SIZE);
-   sprintf(ring->name, "comp_%d.%d.%d", ring->me, ring->pipe, 
ring->queue);
-   irq_type = AMDGPU_CP_IRQ_COMPUTE_MEC1_PIPE0_EOP + ring->pipe;
-   /* type-2 packets are deprecated on MEC, use type-3 instead */
-   r = amdgpu_ring_init(adev, ring, 1024,
->gfx.eop_irq, irq_type);
-   if (r)
-   return r;
-   }
-
r = gfx_v9_0_kiq_init(adev);
if (r) {
DRM_ERROR("Failed to init KIQ BOs!\n");
-- 
2.12.0



--

Subject: Digest Footer

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


--

End of amd-gfx Digest, Vol 13, Issue 29
***
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] drm/amd/amdgpu: Fix ring initialization for GFX9

2017-06-05 Thread Tom St Denis 
The commit 83866f0fc72017d55f40cbd4160cd1e42a2cc3a8 erroneously included the
old ring init sequence along with the new one which uses shared header 
definitions.

The fix which works on my vega10 seems to be to drop the old init sequence.

Signed-off-by: Tom St Denis 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 26 --
 1 file changed, 26 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index 9502353ec325..8388893e0b11 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -1586,32 +1586,6 @@ static int gfx_v9_0_sw_init(void *handle)
ring_id++;
}
 
-   /* set up the compute queues */
-   for (i = 0, ring_id = 0; i < AMDGPU_MAX_COMPUTE_QUEUES; i++) {
-   unsigned irq_type;
-
-   /* max 32 queues per MEC */
-   if ((i >= 32) || (i >= AMDGPU_MAX_COMPUTE_RINGS)) {
-   DRM_ERROR("Too many (%d) compute rings!\n", i);
-   break;
-   }
-   ring = >gfx.compute_ring[i];
-   ring->ring_obj = NULL;
-   ring->use_doorbell = true;
-   ring->doorbell_index = (AMDGPU_DOORBELL64_MEC_RING0 + i) << 1;
-   ring->me = 1; /* first MEC */
-   ring->pipe = i / 8;
-   ring->queue = i % 8;
-   ring->eop_gpu_addr = adev->gfx.mec.hpd_eop_gpu_addr + (i * 
GFX9_MEC_HPD_SIZE);
-   sprintf(ring->name, "comp_%d.%d.%d", ring->me, ring->pipe, 
ring->queue);
-   irq_type = AMDGPU_CP_IRQ_COMPUTE_MEC1_PIPE0_EOP + ring->pipe;
-   /* type-2 packets are deprecated on MEC, use type-3 instead */
-   r = amdgpu_ring_init(adev, ring, 1024,
->gfx.eop_irq, irq_type);
-   if (r)
-   return r;
-   }
-
r = gfx_v9_0_kiq_init(adev);
if (r) {
DRM_ERROR("Failed to init KIQ BOs!\n");
-- 
2.12.0

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

number of rings broken

2017-06-05 Thread Tom St Denis 

Hi all,

Just back after a week off ... first thing I see on my vega10 system is 
this patch:


83866f0fc72017d55f40cbd4160cd1e42a2cc3a8 is the first bad commit
commit 83866f0fc72017d55f40cbd4160cd1e42a2cc3a8
Author: Andres Rodriguez 
Date:   Thu Feb 2 00:38:22 2017 -0500

drm/amdgpu: allow split of queues with kfd at queue granularity v4

Previously the queue/pipe split with kfd operated with pipe
granularity. This patch allows amdgpu to take ownership of an arbitrary
set of queues.

It also consolidates the last few magic numbers in the compute
initialization process into mec_init.

v2: support for gfx9
v3: renamed AMDGPU_MAX_QUEUES to AMDGPU_MAX_COMPUTE_QUEUES
v4: fix off-by-one in num_mec checks in *_compute_queue_acquire

Reviewed-by: Edward O'Callaghan 
Reviewed-by: Felix Kuehling 
Acked-by: Christian König 
Signed-off-by: Andres Rodriguez 
Signed-off-by: Alex Deucher 

:04 04 cafdad84e9fd950112e9ff56956526fa47dcaa59 
48647a91855c0b2d4b3dfedffb89bd93da25c0eb M  drivers


Causes the driver to fail to init properly with these messages:

[   21.983487] [drm] amdgpu: irq initialized.
[   22.012073] amdgpu: [powerplay] amdgpu: powerplay sw initialized
[   22.015161] amdgpu :03:00.0: fence driver on ring 0 use gpu addr 
0x00f5ff08, cpu addr 0x8802143fc008
[   22.015208] amdgpu :03:00.0: fence driver on ring 1 use gpu addr 
0x00f5ff10, cpu addr 0x8802143fc010
[   22.015243] amdgpu :03:00.0: fence driver on ring 2 use gpu addr 
0x00f5ff18, cpu addr 0x8802143fc018
[   22.015278] amdgpu :03:00.0: fence driver on ring 3 use gpu addr 
0x00f5ff28, cpu addr 0x8802143fc028
[   22.015310] amdgpu :03:00.0: fence driver on ring 4 use gpu addr 
0x00f5ff30, cpu addr 0x8802143fc030
[   22.015342] amdgpu :03:00.0: fence driver on ring 5 use gpu addr 
0x00f5ff38, cpu addr 0x8802143fc038
[   22.015374] amdgpu :03:00.0: fence driver on ring 6 use gpu addr 
0x00f5ff48, cpu addr 0x8802143fc048
[   22.015412] amdgpu :03:00.0: fence driver on ring 7 use gpu addr 
0x00f5ff50, cpu addr 0x8802143fc050
[   22.015445] amdgpu :03:00.0: fence driver on ring 8 use gpu addr 
0x00f5ff58, cpu addr 0x8802143fc058
[   22.015457] amdgpu :03:00.0: fence driver on ring 1 use gpu addr 
0x00f5ff68, cpu addr 0x8802143fc068
[   22.015565] [drm:amdgpu_ring_init [amdgpu]] *ERROR* Failed to 
register debugfs file for rings !
[   22.015573] amdgpu :03:00.0: fence driver on ring 2 use gpu addr 
0x00f5ff70, cpu addr 0x8802143fc070
[   22.015616] [drm:amdgpu_ring_init [amdgpu]] *ERROR* Failed to 
register debugfs file for rings !
[   22.015620] amdgpu :03:00.0: fence driver on ring 3 use gpu addr 
0x00f5ff78, cpu addr 0x8802143fc078
[   22.015660] [drm:amdgpu_ring_init [amdgpu]] *ERROR* Failed to 
register debugfs file for rings !
[   22.015663] amdgpu :03:00.0: fence driver on ring 4 use gpu addr 
0x00f5ff88, cpu addr 0x8802143fc088
[   22.015702] [drm:amdgpu_ring_init [amdgpu]] *ERROR* Failed to 
register debugfs file for rings !
[   22.015705] amdgpu :03:00.0: fence driver on ring 5 use gpu addr 
0x00f5ff90, cpu addr 0x8802143fc090
[   22.015745] [drm:amdgpu_ring_init [amdgpu]] *ERROR* Failed to 
register debugfs file for rings !
[   22.015748] amdgpu :03:00.0: fence driver on ring 6 use gpu addr 
0x00f5ff98, cpu addr 0x8802143fc098
[   22.015787] [drm:amdgpu_ring_init [amdgpu]] *ERROR* Failed to 
register debugfs file for rings !
[   22.015792] amdgpu :03:00.0: fence driver on ring 7 use gpu addr 
0x00f5ffa8, cpu addr 0x8802143fc0a8
[   22.015836] [drm:amdgpu_ring_init [amdgpu]] *ERROR* Failed to 
register debugfs file for rings !
[   22.015842] amdgpu :03:00.0: fence driver on ring 8 use gpu addr 
0x00f5ffb0, cpu addr 0x8802143fc0b0
[   22.015881] [drm:amdgpu_ring_init [amdgpu]] *ERROR* Failed to 
register debugfs file for rings !
[   22.015920] [drm:gfx_v9_0_sw_init [amdgpu]] *ERROR* Too many (8) 
compute rings!


I haven't diagnosed why that is a problem but effectively various 
constants have changed it seems.  On the same system the module inits 
for carrizo just fine so it seems to be a GFX9 issue.


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