[PATCH 4/4] drm/amdgpu: used cached gca values for vi_read_register (v2)

2016-10-14 Thread Alex Deucher 
Using the cached values has less latency for bare metal
and SR-IOV, and prevents reading back bogus values if the
engine is powergated.

v2: fix typo in tile idx calculation

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/vi.c | 117 +---
 1 file changed, 97 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
index 657de2a..82f72cd 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -556,21 +556,100 @@ static const struct amdgpu_allowed_register_entry 
vi_allowed_read_registers[] =
{mmPA_SC_RASTER_CONFIG_1, false, true},
 };
 
-static uint32_t vi_read_indexed_register(struct amdgpu_device *adev, u32 
se_num,
-u32 sh_num, u32 reg_offset)
-{
-   uint32_t val;
+static uint32_t vi_get_register_value(struct amdgpu_device *adev,
+ bool indexed, u32 se_num,
+ u32 sh_num, u32 reg_offset)
+{
+   if (indexed) {
+   uint32_t val;
+   unsigned se_idx = (se_num == 0x) ? 0 : se_num;
+   unsigned sh_idx = (sh_num == 0x) ? 0 : sh_num;
+
+   switch (reg_offset) {
+   case mmCC_RB_BACKEND_DISABLE:
+   return 
adev->gfx.config.rb_config[se_idx][sh_idx].rb_backend_disable;
+   case mmGC_USER_RB_BACKEND_DISABLE:
+   return 
adev->gfx.config.rb_config[se_idx][sh_idx].user_rb_backend_disable;
+   case mmPA_SC_RASTER_CONFIG:
+   return 
adev->gfx.config.rb_config[se_idx][sh_idx].raster_config;
+   case mmPA_SC_RASTER_CONFIG_1:
+   return 
adev->gfx.config.rb_config[se_idx][sh_idx].raster_config_1;
+   }
 
-   mutex_lock(>grbm_idx_mutex);
-   if (se_num != 0x || sh_num != 0x)
-   amdgpu_gfx_select_se_sh(adev, se_num, sh_num, 0x);
+   mutex_lock(>grbm_idx_mutex);
+   if (se_num != 0x || sh_num != 0x)
+   amdgpu_gfx_select_se_sh(adev, se_num, sh_num, 
0x);
 
-   val = RREG32(reg_offset);
+   val = RREG32(reg_offset);
 
-   if (se_num != 0x || sh_num != 0x)
-   amdgpu_gfx_select_se_sh(adev, 0x, 0x, 
0x);
-   mutex_unlock(>grbm_idx_mutex);
-   return val;
+   if (se_num != 0x || sh_num != 0x)
+   amdgpu_gfx_select_se_sh(adev, 0x, 0x, 
0x);
+   mutex_unlock(>grbm_idx_mutex);
+   return val;
+   } else {
+   unsigned idx;
+
+   switch (reg_offset) {
+   case mmGB_ADDR_CONFIG:
+   return adev->gfx.config.gb_addr_config;
+   case mmMC_ARB_RAMCFG:
+   return adev->gfx.config.mc_arb_ramcfg;
+   case mmGB_TILE_MODE0:
+   case mmGB_TILE_MODE1:
+   case mmGB_TILE_MODE2:
+   case mmGB_TILE_MODE3:
+   case mmGB_TILE_MODE4:
+   case mmGB_TILE_MODE5:
+   case mmGB_TILE_MODE6:
+   case mmGB_TILE_MODE7:
+   case mmGB_TILE_MODE8:
+   case mmGB_TILE_MODE9:
+   case mmGB_TILE_MODE10:
+   case mmGB_TILE_MODE11:
+   case mmGB_TILE_MODE12:
+   case mmGB_TILE_MODE13:
+   case mmGB_TILE_MODE14:
+   case mmGB_TILE_MODE15:
+   case mmGB_TILE_MODE16:
+   case mmGB_TILE_MODE17:
+   case mmGB_TILE_MODE18:
+   case mmGB_TILE_MODE19:
+   case mmGB_TILE_MODE20:
+   case mmGB_TILE_MODE21:
+   case mmGB_TILE_MODE22:
+   case mmGB_TILE_MODE23:
+   case mmGB_TILE_MODE24:
+   case mmGB_TILE_MODE25:
+   case mmGB_TILE_MODE26:
+   case mmGB_TILE_MODE27:
+   case mmGB_TILE_MODE28:
+   case mmGB_TILE_MODE29:
+   case mmGB_TILE_MODE30:
+   case mmGB_TILE_MODE31:
+   idx = (reg_offset - mmGB_TILE_MODE0);
+   return adev->gfx.config.tile_mode_array[idx];
+   case mmGB_MACROTILE_MODE0:
+   case mmGB_MACROTILE_MODE1:
+   case mmGB_MACROTILE_MODE2:
+   case mmGB_MACROTILE_MODE3:
+   case mmGB_MACROTILE_MODE4:
+   case mmGB_MACROTILE_MODE5:
+   case mmGB_MACROTILE_MODE6:
+   case mmGB_MACROTILE_MODE7:
+   case mmGB_MACROTILE_MODE8:
+   case mmGB_MACROTILE_MODE9:
+   case mmGB_MACROTILE_MODE10:
+   case mmGB_MACROTILE_MODE11:
+   case

Re: [PATCH 4/4] drm/amdgpu: used cached gca values for vi_read_register

2016-10-14 Thread Andy Furniss 

Alex Deucher wrote:

On Tue, Oct 11, 2016 at 7:48 PM, Andy Furniss  wrote:

The boot vce/uvd issue is fixed in 4.9-wip now, so I can boot latest but -

The segfault on startx is still there.


Fixed in v2.


Yea, all OK now.

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

Re: [PATCH 4/4] drm/amdgpu: used cached gca values for vi_read_register

2016-10-13 Thread Alex Deucher 
On Tue, Oct 11, 2016 at 7:48 PM, Andy Furniss <adf.li...@gmail.com> wrote:
> The boot vce/uvd issue is fixed in 4.9-wip now, so I can boot latest but -
>
> The segfault on startx is still there.

Fixed in v2.

Alex

>
> I still can't shutdown/reboot
> as in https://bugs.freedesktop.org/show_bug.cgi?id=98200
> which is fixed for radeon, but apparently not (for me at least) with amdgpu.
> Reverting amdgpu always apply pci shutdown callbacks has fixed this
> for recent kernels, though it's not that simple, as I do have a kernel
> from last month that has the commit but works OK.
>
>
> StDenis, Tom wrote:
>>
>> Yup confirmed...
>>
>>
>> [root@fx6 linux]# git bisect good
>> da00756f75422b04befae381e7e48d0cacf299f3 is the first bad commit
>> commit da00756f75422b04befae381e7e48d0cacf299f3
>> Author: Christian König <christian.koe...@amd.com>
>> Date:   Wed Oct 5 16:09:32 2016 +0200
>>
>>  drm/amdgpu: move align_mask and nop into ring funcs as well
>>
>>  They are constant as well.
>>
>>  Signed-off-by: Christian König <christian.koe...@amd.com>
>>  Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>
>>
>> :04 04 a8f2ca9290985991b3cc37cbeb902f060573fdbb
>> 2309b176a1d4ff9e59eaf25688b5db6eb9759dd0 M  drivers
>>
>>
>>
>>
>> 
>> From: amd-gfx <amd-gfx-boun...@lists.freedesktop.org> on behalf of
>> StDenis, Tom <tom.stde...@amd.com>
>> Sent: Tuesday, October 11, 2016 09:20
>> To: Andy Furniss; amd-gfx@lists.freedesktop.org
>> Cc: Deucher, Alexander
>> Subject: Re: [PATCH 4/4] drm/amdgpu: used cached gca values for
>> vi_read_register
>>
>>
>> Hi Andy,
>>
>>
>> Ha, I'm 1 step away (that was my last bad commit) from determining that.
>> I'll finish up for formality sake but I suspect that is the bad one.
>>
>>
>> Cheers,
>>
>> Tom
>>
>>
>> 
>> From: Andy Furniss <adf.li...@gmail.com>
>> Sent: Tuesday, October 11, 2016 09:10
>> To: StDenis, Tom; amd-gfx@lists.freedesktop.org
>> Cc: Deucher, Alexander
>> Subject: Re: [PATCH 4/4] drm/amdgpu: used cached gca values for
>> vi_read_register
>>
>> StDenis, Tom wrote:
>>>
>>> Actually NAK that, I don't have the cache patch internally.  So my Tonga
>>> crash is something else.
>>
>>
>> Yes, seems the boot fail starts with the tip commit =
>>
>> drm/amdgpu: move align_mask and nop into ring funcs as well
>> They are constant as well.
>>
>> Will also reply to that patch.
>>
>>>
>>>
>>> Tom
>>>
>>>
>>> 
>>> From: amd-gfx <amd-gfx-boun...@lists.freedesktop.org> on behalf of
>>> StDenis, Tom <tom.stde...@amd.com>
>>> Sent: Tuesday, October 11, 2016 08:11
>>> To: Andy Furniss; amd-gfx@lists.freedesktop.org
>>> Cc: Deucher, Alexander
>>> Subject: Re: [PATCH 4/4] drm/amdgpu: used cached gca values for
>>> vi_read_register
>>>
>>>
>>> Yup, my Tonga system dies on modprobe with the tip of stg-4.7 this
>>> morning.
>>>
>>>
>>> Tom
>>>
>>>
>>> 
>>> From: amd-gfx <amd-gfx-boun...@lists.freedesktop.org> on behalf of Andy
>>> Furniss <adf.li...@gmail.com>
>>> Sent: Tuesday, October 11, 2016 08:07
>>> To: Alex Deucher; amd-gfx@lists.freedesktop.org
>>> Cc: Deucher, Alexander
>>> Subject: Re: [PATCH 4/4] drm/amdgpu: used cached gca values for
>>> vi_read_register
>>>
>>> Alex Deucher wrote:
>>>>
>>>> Using the cached values has less latency for bare metal and SR-IOV,
>>>> and prevents reading back bogus values if the engine is powergated.
>>>
>>>
>>> I can't startx since this on r9285.
>>>
>>> Seems there are further issues later in current 4.9-wip = I die on
>>> driver load, will see if that's related or one of Christians patches
>>> later.
>>>
>>> Also anyone on list have shutdown/reboot issues - I can't for the past
>>> few 4.9-wips (I did tag on to someone elses bug, but that's gone quiet).
>>>
>>> One thing at a time this commit for me, boots into fbcon OK but then
>>> segfaults -
>>>
>>> [19.694] (II) AIGLX: Loaded and initialized radeonsi
>>> [19.69

Re: [PATCH 4/4] drm/amdgpu: used cached gca values for vi_read_register

2016-10-12 Thread Andy Furniss 

Grazvydas Ignotas wrote:

On Wed, Oct 12, 2016 at 2:48 AM, Andy Furniss  wrote:


I still can't shutdown/reboot
as in https://bugs.freedesktop.org/show_bug.cgi?id=98200
which is fixed for radeon, but apparently not (for me at least) with amdgpu.


You probably need a951ed85abd46 that went to 4.8-fixes and is not part
of 4.9-wip.


Thanks, it's OK with that.


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

Re: [PATCH 4/4] drm/amdgpu: used cached gca values for vi_read_register

2016-10-12 Thread Grazvydas Ignotas 
On Wed, Oct 12, 2016 at 2:48 AM, Andy Furniss  wrote:
>
> I still can't shutdown/reboot
> as in https://bugs.freedesktop.org/show_bug.cgi?id=98200
> which is fixed for radeon, but apparently not (for me at least) with amdgpu.

You probably need a951ed85abd46 that went to 4.8-fixes and is not part
of 4.9-wip.

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

Re: [PATCH 4/4] drm/amdgpu: used cached gca values for vi_read_register

2016-10-11 Thread Andy Furniss 

The boot vce/uvd issue is fixed in 4.9-wip now, so I can boot latest but -

The segfault on startx is still there.

I still can't shutdown/reboot
as in https://bugs.freedesktop.org/show_bug.cgi?id=98200
which is fixed for radeon, but apparently not (for me at least) with amdgpu.
Reverting amdgpu always apply pci shutdown callbacks has fixed this
for recent kernels, though it's not that simple, as I do have a kernel
from last month that has the commit but works OK.


StDenis, Tom wrote:

Yup confirmed...


[root@fx6 linux]# git bisect good
da00756f75422b04befae381e7e48d0cacf299f3 is the first bad commit
commit da00756f75422b04befae381e7e48d0cacf299f3
Author: Christian König <christian.koe...@amd.com>
Date:   Wed Oct 5 16:09:32 2016 +0200

 drm/amdgpu: move align_mask and nop into ring funcs as well

 They are constant as well.

 Signed-off-by: Christian König <christian.koe...@amd.com>
 Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

:04 04 a8f2ca9290985991b3cc37cbeb902f060573fdbb 
2309b176a1d4ff9e59eaf25688b5db6eb9759dd0 M  drivers





From: amd-gfx <amd-gfx-boun...@lists.freedesktop.org> on behalf of StDenis, Tom 
<tom.stde...@amd.com>
Sent: Tuesday, October 11, 2016 09:20
To: Andy Furniss; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: Re: [PATCH 4/4] drm/amdgpu: used cached gca values for vi_read_register


Hi Andy,


Ha, I'm 1 step away (that was my last bad commit) from determining that.  I'll 
finish up for formality sake but I suspect that is the bad one.


Cheers,

Tom



From: Andy Furniss <adf.li...@gmail.com>
Sent: Tuesday, October 11, 2016 09:10
To: StDenis, Tom; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: Re: [PATCH 4/4] drm/amdgpu: used cached gca values for vi_read_register

StDenis, Tom wrote:

Actually NAK that, I don't have the cache patch internally.  So my Tonga crash 
is something else.


Yes, seems the boot fail starts with the tip commit =

drm/amdgpu: move align_mask and nop into ring funcs as well
They are constant as well.

Will also reply to that patch.




Tom



From: amd-gfx <amd-gfx-boun...@lists.freedesktop.org> on behalf of StDenis, Tom 
<tom.stde...@amd.com>
Sent: Tuesday, October 11, 2016 08:11
To: Andy Furniss; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: Re: [PATCH 4/4] drm/amdgpu: used cached gca values for vi_read_register


Yup, my Tonga system dies on modprobe with the tip of stg-4.7 this morning.


Tom



From: amd-gfx <amd-gfx-boun...@lists.freedesktop.org> on behalf of Andy Furniss 
<adf.li...@gmail.com>
Sent: Tuesday, October 11, 2016 08:07
To: Alex Deucher; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: Re: [PATCH 4/4] drm/amdgpu: used cached gca values for vi_read_register

Alex Deucher wrote:

Using the cached values has less latency for bare metal and SR-IOV,
and prevents reading back bogus values if the engine is powergated.


I can't startx since this on r9285.

Seems there are further issues later in current 4.9-wip = I die on
driver load, will see if that's related or one of Christians patches later.

Also anyone on list have shutdown/reboot issues - I can't for the past
few 4.9-wips (I did tag on to someone elses bug, but that's gone quiet).

One thing at a time this commit for me, boots into fbcon OK but then
segfaults -

[19.694] (II) AIGLX: Loaded and initialized radeonsi
[19.694] (II) GLX: Initialized DRI2 GL provider for screen 0
[19.694] (EE)
[19.694] (EE) Backtrace:
[19.717] (EE) 0: /usr/libexec/Xorg (OsSigHandler+0x29) [0x5853b9]
[19.726] (EE) 1: /lib/libc.so.6 (killpg+0x40) [0x7f97e86cb68f]
[19.756] (EE) 2: /usr/lib/dri/radeonsi_dri.so
(amdgpu_surface_init+0x486) [0x7f97e1a40746]
[19.757] (EE) 3: /usr/lib/dri/radeonsi_dri.so
(r600_texture_create_object+0xd7) [0x7f97e1a5dfe7]
[19.759] (EE) 4: /usr/lib/dri/radeonsi_dri.so
(r600_texture_create+0x75) [0x7f97e1a5ea15]
[19.771] (EE) 5: /usr/lib/dri/radeonsi_dri.so
(st_texture_create+0x5b) [0x7f97e178af1b]
[19.773] (EE) 6: /usr/lib/dri/radeonsi_dri.so
(guess_and_alloc_texture+0x1ac) [0x7f97e173ae9c]
[19.774] (EE) 7: /usr/lib/dri/radeonsi_dri.so
(st_AllocTextureImageBuffer+0x3a4) [0x7f97e173b3d4]
[19.775] (EE) 8: /usr/lib/dri/radeonsi_dri.so (st_TexImage+0x6c)
[0x7f97e173f9ac]
[19.786] (EE) 9: /usr/lib/dri/radeonsi_dri.so
(_mesa_get_fallback_texture+0x193) [0x7f97e16cb763]
[19.786] (EE) 10: /usr/lib/dri/radeonsi_dri.so
(_mesa_update_texture+0x1a7) [0x7f97e16d1c37]
[19.787] (EE) 11: /usr/lib/dri/radeonsi_dri.so
(_mesa_update_state_locked+0x683) [0x7f97e16b00e3]
[19.787] (EE) 12: /usr/lib/dri/radeonsi_dri.so
(_mesa_update_state+0x11) [0x7f97e16b0441]
[19.787] (EE) 13: /usr/lib/dri/radeonsi_dri.so
(_mesa_EGLImageTargetTexture2DOES+0x168)

Re: [PATCH 4/4] drm/amdgpu: used cached gca values for vi_read_register

2016-10-11 Thread StDenis, Tom 
Yup confirmed...


[root@fx6 linux]# git bisect good
da00756f75422b04befae381e7e48d0cacf299f3 is the first bad commit
commit da00756f75422b04befae381e7e48d0cacf299f3
Author: Christian König <christian.koe...@amd.com>
Date:   Wed Oct 5 16:09:32 2016 +0200

drm/amdgpu: move align_mask and nop into ring funcs as well

They are constant as well.

Signed-off-by: Christian König <christian.koe...@amd.com>
Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

:04 04 a8f2ca9290985991b3cc37cbeb902f060573fdbb 
2309b176a1d4ff9e59eaf25688b5db6eb9759dd0 M  drivers





From: amd-gfx <amd-gfx-boun...@lists.freedesktop.org> on behalf of StDenis, Tom 
<tom.stde...@amd.com>
Sent: Tuesday, October 11, 2016 09:20
To: Andy Furniss; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: Re: [PATCH 4/4] drm/amdgpu: used cached gca values for vi_read_register


Hi Andy,


Ha, I'm 1 step away (that was my last bad commit) from determining that.  I'll 
finish up for formality sake but I suspect that is the bad one.


Cheers,

Tom



From: Andy Furniss <adf.li...@gmail.com>
Sent: Tuesday, October 11, 2016 09:10
To: StDenis, Tom; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: Re: [PATCH 4/4] drm/amdgpu: used cached gca values for vi_read_register

StDenis, Tom wrote:
> Actually NAK that, I don't have the cache patch internally.  So my Tonga 
> crash is something else.

Yes, seems the boot fail starts with the tip commit =

drm/amdgpu: move align_mask and nop into ring funcs as well
They are constant as well.

Will also reply to that patch.

>
>
> Tom
>
>
> 
> From: amd-gfx <amd-gfx-boun...@lists.freedesktop.org> on behalf of StDenis, 
> Tom <tom.stde...@amd.com>
> Sent: Tuesday, October 11, 2016 08:11
> To: Andy Furniss; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander
> Subject: Re: [PATCH 4/4] drm/amdgpu: used cached gca values for 
> vi_read_register
>
>
> Yup, my Tonga system dies on modprobe with the tip of stg-4.7 this morning.
>
>
> Tom
>
>
> 
> From: amd-gfx <amd-gfx-boun...@lists.freedesktop.org> on behalf of Andy 
> Furniss <adf.li...@gmail.com>
> Sent: Tuesday, October 11, 2016 08:07
> To: Alex Deucher; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander
> Subject: Re: [PATCH 4/4] drm/amdgpu: used cached gca values for 
> vi_read_register
>
> Alex Deucher wrote:
>> Using the cached values has less latency for bare metal and SR-IOV,
>> and prevents reading back bogus values if the engine is powergated.
>
> I can't startx since this on r9285.
>
> Seems there are further issues later in current 4.9-wip = I die on
> driver load, will see if that's related or one of Christians patches later.
>
> Also anyone on list have shutdown/reboot issues - I can't for the past
> few 4.9-wips (I did tag on to someone elses bug, but that's gone quiet).
>
> One thing at a time this commit for me, boots into fbcon OK but then
> segfaults -
>
> [19.694] (II) AIGLX: Loaded and initialized radeonsi
> [19.694] (II) GLX: Initialized DRI2 GL provider for screen 0
> [19.694] (EE)
> [19.694] (EE) Backtrace:
> [19.717] (EE) 0: /usr/libexec/Xorg (OsSigHandler+0x29) [0x5853b9]
> [19.726] (EE) 1: /lib/libc.so.6 (killpg+0x40) [0x7f97e86cb68f]
> [19.756] (EE) 2: /usr/lib/dri/radeonsi_dri.so
> (amdgpu_surface_init+0x486) [0x7f97e1a40746]
> [19.757] (EE) 3: /usr/lib/dri/radeonsi_dri.so
> (r600_texture_create_object+0xd7) [0x7f97e1a5dfe7]
> [19.759] (EE) 4: /usr/lib/dri/radeonsi_dri.so
> (r600_texture_create+0x75) [0x7f97e1a5ea15]
> [19.771] (EE) 5: /usr/lib/dri/radeonsi_dri.so
> (st_texture_create+0x5b) [0x7f97e178af1b]
> [19.773] (EE) 6: /usr/lib/dri/radeonsi_dri.so
> (guess_and_alloc_texture+0x1ac) [0x7f97e173ae9c]
> [19.774] (EE) 7: /usr/lib/dri/radeonsi_dri.so
> (st_AllocTextureImageBuffer+0x3a4) [0x7f97e173b3d4]
> [19.775] (EE) 8: /usr/lib/dri/radeonsi_dri.so (st_TexImage+0x6c)
> [0x7f97e173f9ac]
> [19.786] (EE) 9: /usr/lib/dri/radeonsi_dri.so
> (_mesa_get_fallback_texture+0x193) [0x7f97e16cb763]
> [19.786] (EE) 10: /usr/lib/dri/radeonsi_dri.so
> (_mesa_update_texture+0x1a7) [0x7f97e16d1c37]
> [19.787] (EE) 11: /usr/lib/dri/radeonsi_dri.so
> (_mesa_update_state_locked+0x683) [0x7f97e16b00e3]
> [19.787] (EE) 12: /usr/lib/dri/radeonsi_dri.so
> (_mesa_update_state+0x11) [0x7f97e16b0441]
> [19.787] (EE) 13: /usr/lib/dri/radeonsi_dri.so
> (_mesa_EGLImageTargetTexture2DOES+0x168) [0x7f97e16c5c88]
> [19.802] (EE) 14: /usr/lib/xorg/modules/libglamoregl.so
> (glamor_create_texture_from_image+0xaa) [0x7

Re: [PATCH 4/4] drm/amdgpu: used cached gca values for vi_read_register

2016-10-11 Thread StDenis, Tom 
Hi Andy,


Ha, I'm 1 step away (that was my last bad commit) from determining that.  I'll 
finish up for formality sake but I suspect that is the bad one.


Cheers,

Tom



From: Andy Furniss <adf.li...@gmail.com>
Sent: Tuesday, October 11, 2016 09:10
To: StDenis, Tom; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: Re: [PATCH 4/4] drm/amdgpu: used cached gca values for vi_read_register

StDenis, Tom wrote:
> Actually NAK that, I don't have the cache patch internally.  So my Tonga 
> crash is something else.

Yes, seems the boot fail starts with the tip commit =

drm/amdgpu: move align_mask and nop into ring funcs as well
They are constant as well.

Will also reply to that patch.

>
>
> Tom
>
>
> 
> From: amd-gfx <amd-gfx-boun...@lists.freedesktop.org> on behalf of StDenis, 
> Tom <tom.stde...@amd.com>
> Sent: Tuesday, October 11, 2016 08:11
> To: Andy Furniss; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander
> Subject: Re: [PATCH 4/4] drm/amdgpu: used cached gca values for 
> vi_read_register
>
>
> Yup, my Tonga system dies on modprobe with the tip of stg-4.7 this morning.
>
>
> Tom
>
>
> 
> From: amd-gfx <amd-gfx-boun...@lists.freedesktop.org> on behalf of Andy 
> Furniss <adf.li...@gmail.com>
> Sent: Tuesday, October 11, 2016 08:07
> To: Alex Deucher; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander
> Subject: Re: [PATCH 4/4] drm/amdgpu: used cached gca values for 
> vi_read_register
>
> Alex Deucher wrote:
>> Using the cached values has less latency for bare metal and SR-IOV,
>> and prevents reading back bogus values if the engine is powergated.
>
> I can't startx since this on r9285.
>
> Seems there are further issues later in current 4.9-wip = I die on
> driver load, will see if that's related or one of Christians patches later.
>
> Also anyone on list have shutdown/reboot issues - I can't for the past
> few 4.9-wips (I did tag on to someone elses bug, but that's gone quiet).
>
> One thing at a time this commit for me, boots into fbcon OK but then
> segfaults -
>
> [19.694] (II) AIGLX: Loaded and initialized radeonsi
> [19.694] (II) GLX: Initialized DRI2 GL provider for screen 0
> [19.694] (EE)
> [19.694] (EE) Backtrace:
> [19.717] (EE) 0: /usr/libexec/Xorg (OsSigHandler+0x29) [0x5853b9]
> [19.726] (EE) 1: /lib/libc.so.6 (killpg+0x40) [0x7f97e86cb68f]
> [19.756] (EE) 2: /usr/lib/dri/radeonsi_dri.so
> (amdgpu_surface_init+0x486) [0x7f97e1a40746]
> [19.757] (EE) 3: /usr/lib/dri/radeonsi_dri.so
> (r600_texture_create_object+0xd7) [0x7f97e1a5dfe7]
> [19.759] (EE) 4: /usr/lib/dri/radeonsi_dri.so
> (r600_texture_create+0x75) [0x7f97e1a5ea15]
> [19.771] (EE) 5: /usr/lib/dri/radeonsi_dri.so
> (st_texture_create+0x5b) [0x7f97e178af1b]
> [19.773] (EE) 6: /usr/lib/dri/radeonsi_dri.so
> (guess_and_alloc_texture+0x1ac) [0x7f97e173ae9c]
> [19.774] (EE) 7: /usr/lib/dri/radeonsi_dri.so
> (st_AllocTextureImageBuffer+0x3a4) [0x7f97e173b3d4]
> [19.775] (EE) 8: /usr/lib/dri/radeonsi_dri.so (st_TexImage+0x6c)
> [0x7f97e173f9ac]
> [19.786] (EE) 9: /usr/lib/dri/radeonsi_dri.so
> (_mesa_get_fallback_texture+0x193) [0x7f97e16cb763]
> [19.786] (EE) 10: /usr/lib/dri/radeonsi_dri.so
> (_mesa_update_texture+0x1a7) [0x7f97e16d1c37]
> [19.787] (EE) 11: /usr/lib/dri/radeonsi_dri.so
> (_mesa_update_state_locked+0x683) [0x7f97e16b00e3]
> [19.787] (EE) 12: /usr/lib/dri/radeonsi_dri.so
> (_mesa_update_state+0x11) [0x7f97e16b0441]
> [19.787] (EE) 13: /usr/lib/dri/radeonsi_dri.so
> (_mesa_EGLImageTargetTexture2DOES+0x168) [0x7f97e16c5c88]
> [19.802] (EE) 14: /usr/lib/xorg/modules/libglamoregl.so
> (glamor_create_texture_from_image+0xaa) [0x7f97d93bf89a]
> [19.803] (EE) 15: /usr/lib/xorg/modules/libglamoregl.so
> (glamor_egl_create_textured_pixmap+0x12d) [0x7f97d93bfafd]
> [19.803] (EE) 16: /usr/lib/xorg/modules/libglamoregl.so
> (glamor_egl_create_textured_screen+0x33) [0x7f97d93bfc23]
> [19.811] (EE) 17: /usr/lib/xorg/modules/drivers/amdgpu_drv.so
> (amdgpu_glamor_create_screen_resources+0x67) [0x7f97e2ea7cf7]
> [19.812] (EE) 18: /usr/lib/xorg/modules/drivers/amdgpu_drv.so
> (AMDGPUCreateScreenResources_KMS+0x27e) [0x7f97e2e9fe3e]
> [19.813] (EE) 19: /usr/libexec/Xorg
> (xf86CrtcCreateScreenResources+0x2e) [0x4a3b7e]
> [19.814] (EE) 20: /usr/libexec/Xorg (dix_main+0x26e) [0x438ebe]
> [19.815] (EE) 21: /lib/libc.so.6 (__libc_start_main+0xf0)
> [0x7f97e86b85e0]
> [19.816] (EE) 22: /usr/libexec/Xorg (_start+0x29) [0x424659]
> [19.816] (EE)
> [19.816] (EE) Segmentation faul

Re: [PATCH 4/4] drm/amdgpu: used cached gca values for vi_read_register

2016-10-11 Thread Andy Furniss 

StDenis, Tom wrote:

Actually NAK that, I don't have the cache patch internally.  So my Tonga crash 
is something else.


Yes, seems the boot fail starts with the tip commit =

drm/amdgpu: move align_mask and nop into ring funcs as well
They are constant as well.

Will also reply to that patch.




Tom



From: amd-gfx <amd-gfx-boun...@lists.freedesktop.org> on behalf of StDenis, Tom 
<tom.stde...@amd.com>
Sent: Tuesday, October 11, 2016 08:11
To: Andy Furniss; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: Re: [PATCH 4/4] drm/amdgpu: used cached gca values for vi_read_register


Yup, my Tonga system dies on modprobe with the tip of stg-4.7 this morning.


Tom



From: amd-gfx <amd-gfx-boun...@lists.freedesktop.org> on behalf of Andy Furniss 
<adf.li...@gmail.com>
Sent: Tuesday, October 11, 2016 08:07
To: Alex Deucher; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: Re: [PATCH 4/4] drm/amdgpu: used cached gca values for vi_read_register

Alex Deucher wrote:

Using the cached values has less latency for bare metal and SR-IOV,
and prevents reading back bogus values if the engine is powergated.


I can't startx since this on r9285.

Seems there are further issues later in current 4.9-wip = I die on
driver load, will see if that's related or one of Christians patches later.

Also anyone on list have shutdown/reboot issues - I can't for the past
few 4.9-wips (I did tag on to someone elses bug, but that's gone quiet).

One thing at a time this commit for me, boots into fbcon OK but then
segfaults -

[19.694] (II) AIGLX: Loaded and initialized radeonsi
[19.694] (II) GLX: Initialized DRI2 GL provider for screen 0
[19.694] (EE)
[19.694] (EE) Backtrace:
[19.717] (EE) 0: /usr/libexec/Xorg (OsSigHandler+0x29) [0x5853b9]
[19.726] (EE) 1: /lib/libc.so.6 (killpg+0x40) [0x7f97e86cb68f]
[19.756] (EE) 2: /usr/lib/dri/radeonsi_dri.so
(amdgpu_surface_init+0x486) [0x7f97e1a40746]
[19.757] (EE) 3: /usr/lib/dri/radeonsi_dri.so
(r600_texture_create_object+0xd7) [0x7f97e1a5dfe7]
[19.759] (EE) 4: /usr/lib/dri/radeonsi_dri.so
(r600_texture_create+0x75) [0x7f97e1a5ea15]
[19.771] (EE) 5: /usr/lib/dri/radeonsi_dri.so
(st_texture_create+0x5b) [0x7f97e178af1b]
[19.773] (EE) 6: /usr/lib/dri/radeonsi_dri.so
(guess_and_alloc_texture+0x1ac) [0x7f97e173ae9c]
[19.774] (EE) 7: /usr/lib/dri/radeonsi_dri.so
(st_AllocTextureImageBuffer+0x3a4) [0x7f97e173b3d4]
[19.775] (EE) 8: /usr/lib/dri/radeonsi_dri.so (st_TexImage+0x6c)
[0x7f97e173f9ac]
[19.786] (EE) 9: /usr/lib/dri/radeonsi_dri.so
(_mesa_get_fallback_texture+0x193) [0x7f97e16cb763]
[19.786] (EE) 10: /usr/lib/dri/radeonsi_dri.so
(_mesa_update_texture+0x1a7) [0x7f97e16d1c37]
[19.787] (EE) 11: /usr/lib/dri/radeonsi_dri.so
(_mesa_update_state_locked+0x683) [0x7f97e16b00e3]
[19.787] (EE) 12: /usr/lib/dri/radeonsi_dri.so
(_mesa_update_state+0x11) [0x7f97e16b0441]
[19.787] (EE) 13: /usr/lib/dri/radeonsi_dri.so
(_mesa_EGLImageTargetTexture2DOES+0x168) [0x7f97e16c5c88]
[19.802] (EE) 14: /usr/lib/xorg/modules/libglamoregl.so
(glamor_create_texture_from_image+0xaa) [0x7f97d93bf89a]
[19.803] (EE) 15: /usr/lib/xorg/modules/libglamoregl.so
(glamor_egl_create_textured_pixmap+0x12d) [0x7f97d93bfafd]
[19.803] (EE) 16: /usr/lib/xorg/modules/libglamoregl.so
(glamor_egl_create_textured_screen+0x33) [0x7f97d93bfc23]
[19.811] (EE) 17: /usr/lib/xorg/modules/drivers/amdgpu_drv.so
(amdgpu_glamor_create_screen_resources+0x67) [0x7f97e2ea7cf7]
[19.812] (EE) 18: /usr/lib/xorg/modules/drivers/amdgpu_drv.so
(AMDGPUCreateScreenResources_KMS+0x27e) [0x7f97e2e9fe3e]
[19.813] (EE) 19: /usr/libexec/Xorg
(xf86CrtcCreateScreenResources+0x2e) [0x4a3b7e]
[19.814] (EE) 20: /usr/libexec/Xorg (dix_main+0x26e) [0x438ebe]
[19.815] (EE) 21: /lib/libc.so.6 (__libc_start_main+0xf0)
[0x7f97e86b85e0]
[19.816] (EE) 22: /usr/libexec/Xorg (_start+0x29) [0x424659]
[19.816] (EE)
[19.816] (EE) Segmentation fault at address 0x4023321cc
[19.816] (EE)
Fatal server error:
[19.816] (EE) Caught signal 11 (Segmentation fault). Server aborting
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
amd-gfx Info Page - 
lists.freedesktop.org<https://lists.freedesktop.org/mailman/listinfo/amd-gfx>
lists.freedesktop.org
To see the collection of prior postings to the list, visit the amd-gfx 
Archives. Using amd-gfx: To post a message to all the list members, send email 
...






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

Re: [PATCH 4/4] drm/amdgpu: used cached gca values for vi_read_register

2016-10-11 Thread StDenis, Tom 
Actually NAK that, I don't have the cache patch internally.  So my Tonga crash 
is something else.


Tom



From: amd-gfx <amd-gfx-boun...@lists.freedesktop.org> on behalf of StDenis, Tom 
<tom.stde...@amd.com>
Sent: Tuesday, October 11, 2016 08:11
To: Andy Furniss; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: Re: [PATCH 4/4] drm/amdgpu: used cached gca values for vi_read_register


Yup, my Tonga system dies on modprobe with the tip of stg-4.7 this morning.


Tom



From: amd-gfx <amd-gfx-boun...@lists.freedesktop.org> on behalf of Andy Furniss 
<adf.li...@gmail.com>
Sent: Tuesday, October 11, 2016 08:07
To: Alex Deucher; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: Re: [PATCH 4/4] drm/amdgpu: used cached gca values for vi_read_register

Alex Deucher wrote:
> Using the cached values has less latency for bare metal and SR-IOV,
> and prevents reading back bogus values if the engine is powergated.

I can't startx since this on r9285.

Seems there are further issues later in current 4.9-wip = I die on
driver load, will see if that's related or one of Christians patches later.

Also anyone on list have shutdown/reboot issues - I can't for the past
few 4.9-wips (I did tag on to someone elses bug, but that's gone quiet).

One thing at a time this commit for me, boots into fbcon OK but then
segfaults -

[19.694] (II) AIGLX: Loaded and initialized radeonsi
[19.694] (II) GLX: Initialized DRI2 GL provider for screen 0
[19.694] (EE)
[19.694] (EE) Backtrace:
[19.717] (EE) 0: /usr/libexec/Xorg (OsSigHandler+0x29) [0x5853b9]
[19.726] (EE) 1: /lib/libc.so.6 (killpg+0x40) [0x7f97e86cb68f]
[19.756] (EE) 2: /usr/lib/dri/radeonsi_dri.so
(amdgpu_surface_init+0x486) [0x7f97e1a40746]
[19.757] (EE) 3: /usr/lib/dri/radeonsi_dri.so
(r600_texture_create_object+0xd7) [0x7f97e1a5dfe7]
[19.759] (EE) 4: /usr/lib/dri/radeonsi_dri.so
(r600_texture_create+0x75) [0x7f97e1a5ea15]
[19.771] (EE) 5: /usr/lib/dri/radeonsi_dri.so
(st_texture_create+0x5b) [0x7f97e178af1b]
[19.773] (EE) 6: /usr/lib/dri/radeonsi_dri.so
(guess_and_alloc_texture+0x1ac) [0x7f97e173ae9c]
[19.774] (EE) 7: /usr/lib/dri/radeonsi_dri.so
(st_AllocTextureImageBuffer+0x3a4) [0x7f97e173b3d4]
[19.775] (EE) 8: /usr/lib/dri/radeonsi_dri.so (st_TexImage+0x6c)
[0x7f97e173f9ac]
[19.786] (EE) 9: /usr/lib/dri/radeonsi_dri.so
(_mesa_get_fallback_texture+0x193) [0x7f97e16cb763]
[19.786] (EE) 10: /usr/lib/dri/radeonsi_dri.so
(_mesa_update_texture+0x1a7) [0x7f97e16d1c37]
[19.787] (EE) 11: /usr/lib/dri/radeonsi_dri.so
(_mesa_update_state_locked+0x683) [0x7f97e16b00e3]
[19.787] (EE) 12: /usr/lib/dri/radeonsi_dri.so
(_mesa_update_state+0x11) [0x7f97e16b0441]
[19.787] (EE) 13: /usr/lib/dri/radeonsi_dri.so
(_mesa_EGLImageTargetTexture2DOES+0x168) [0x7f97e16c5c88]
[19.802] (EE) 14: /usr/lib/xorg/modules/libglamoregl.so
(glamor_create_texture_from_image+0xaa) [0x7f97d93bf89a]
[19.803] (EE) 15: /usr/lib/xorg/modules/libglamoregl.so
(glamor_egl_create_textured_pixmap+0x12d) [0x7f97d93bfafd]
[19.803] (EE) 16: /usr/lib/xorg/modules/libglamoregl.so
(glamor_egl_create_textured_screen+0x33) [0x7f97d93bfc23]
[19.811] (EE) 17: /usr/lib/xorg/modules/drivers/amdgpu_drv.so
(amdgpu_glamor_create_screen_resources+0x67) [0x7f97e2ea7cf7]
[19.812] (EE) 18: /usr/lib/xorg/modules/drivers/amdgpu_drv.so
(AMDGPUCreateScreenResources_KMS+0x27e) [0x7f97e2e9fe3e]
[19.813] (EE) 19: /usr/libexec/Xorg
(xf86CrtcCreateScreenResources+0x2e) [0x4a3b7e]
[19.814] (EE) 20: /usr/libexec/Xorg (dix_main+0x26e) [0x438ebe]
[19.815] (EE) 21: /lib/libc.so.6 (__libc_start_main+0xf0)
[0x7f97e86b85e0]
[19.816] (EE) 22: /usr/libexec/Xorg (_start+0x29) [0x424659]
[19.816] (EE)
[19.816] (EE) Segmentation fault at address 0x4023321cc
[19.816] (EE)
Fatal server error:
[19.816] (EE) Caught signal 11 (Segmentation fault). Server aborting
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
amd-gfx Info Page - 
lists.freedesktop.org<https://lists.freedesktop.org/mailman/listinfo/amd-gfx>
lists.freedesktop.org
To see the collection of prior postings to the list, visit the amd-gfx 
Archives. Using amd-gfx: To post a message to all the list members, send email 
...



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

[PATCH 4/4] drm/amdgpu: used cached gca values for vi_read_register

2016-10-10 Thread Alex Deucher 
Using the cached values has less latency for bare metal
and SR-IOV, and prevents reading back bogus values if the
engine is powergated.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/vi.c | 117 +---
 1 file changed, 97 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
index 657de2a..8352946 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -556,21 +556,100 @@ static const struct amdgpu_allowed_register_entry 
vi_allowed_read_registers[] =
{mmPA_SC_RASTER_CONFIG_1, false, true},
 };
 
-static uint32_t vi_read_indexed_register(struct amdgpu_device *adev, u32 
se_num,
-u32 sh_num, u32 reg_offset)
-{
-   uint32_t val;
+static uint32_t vi_get_register_value(struct amdgpu_device *adev,
+ bool indexed, u32 se_num,
+ u32 sh_num, u32 reg_offset)
+{
+   if (indexed) {
+   uint32_t val;
+   unsigned se_idx = (se_num == 0x) ? 0 : se_num;
+   unsigned sh_idx = (sh_num == 0x) ? 0 : sh_num;
+
+   switch (reg_offset) {
+   case mmCC_RB_BACKEND_DISABLE:
+   return 
adev->gfx.config.rb_config[se_idx][sh_idx].rb_backend_disable;
+   case mmGC_USER_RB_BACKEND_DISABLE:
+   return 
adev->gfx.config.rb_config[se_idx][sh_idx].user_rb_backend_disable;
+   case mmPA_SC_RASTER_CONFIG:
+   return 
adev->gfx.config.rb_config[se_idx][sh_idx].raster_config;
+   case mmPA_SC_RASTER_CONFIG_1:
+   return 
adev->gfx.config.rb_config[se_idx][sh_idx].raster_config_1;
+   }
 
-   mutex_lock(>grbm_idx_mutex);
-   if (se_num != 0x || sh_num != 0x)
-   amdgpu_gfx_select_se_sh(adev, se_num, sh_num, 0x);
+   mutex_lock(>grbm_idx_mutex);
+   if (se_num != 0x || sh_num != 0x)
+   amdgpu_gfx_select_se_sh(adev, se_num, sh_num, 
0x);
 
-   val = RREG32(reg_offset);
+   val = RREG32(reg_offset);
 
-   if (se_num != 0x || sh_num != 0x)
-   amdgpu_gfx_select_se_sh(adev, 0x, 0x, 
0x);
-   mutex_unlock(>grbm_idx_mutex);
-   return val;
+   if (se_num != 0x || sh_num != 0x)
+   amdgpu_gfx_select_se_sh(adev, 0x, 0x, 
0x);
+   mutex_unlock(>grbm_idx_mutex);
+   return val;
+   } else {
+   unsigned idx;
+
+   switch (reg_offset) {
+   case mmGB_ADDR_CONFIG:
+   return adev->gfx.config.gb_addr_config;
+   case mmMC_ARB_RAMCFG:
+   return adev->gfx.config.mc_arb_ramcfg;
+   case mmGB_TILE_MODE0:
+   case mmGB_TILE_MODE1:
+   case mmGB_TILE_MODE2:
+   case mmGB_TILE_MODE3:
+   case mmGB_TILE_MODE4:
+   case mmGB_TILE_MODE5:
+   case mmGB_TILE_MODE6:
+   case mmGB_TILE_MODE7:
+   case mmGB_TILE_MODE8:
+   case mmGB_TILE_MODE9:
+   case mmGB_TILE_MODE10:
+   case mmGB_TILE_MODE11:
+   case mmGB_TILE_MODE12:
+   case mmGB_TILE_MODE13:
+   case mmGB_TILE_MODE14:
+   case mmGB_TILE_MODE15:
+   case mmGB_TILE_MODE16:
+   case mmGB_TILE_MODE17:
+   case mmGB_TILE_MODE18:
+   case mmGB_TILE_MODE19:
+   case mmGB_TILE_MODE20:
+   case mmGB_TILE_MODE21:
+   case mmGB_TILE_MODE22:
+   case mmGB_TILE_MODE23:
+   case mmGB_TILE_MODE24:
+   case mmGB_TILE_MODE25:
+   case mmGB_TILE_MODE26:
+   case mmGB_TILE_MODE27:
+   case mmGB_TILE_MODE28:
+   case mmGB_TILE_MODE29:
+   case mmGB_TILE_MODE30:
+   case mmGB_TILE_MODE31:
+   idx = (reg_offset - mmGB_TILE_MODE0) / 32;
+   return adev->gfx.config.tile_mode_array[idx];
+   case mmGB_MACROTILE_MODE0:
+   case mmGB_MACROTILE_MODE1:
+   case mmGB_MACROTILE_MODE2:
+   case mmGB_MACROTILE_MODE3:
+   case mmGB_MACROTILE_MODE4:
+   case mmGB_MACROTILE_MODE5:
+   case mmGB_MACROTILE_MODE6:
+   case mmGB_MACROTILE_MODE7:
+   case mmGB_MACROTILE_MODE8:
+   case mmGB_MACROTILE_MODE9:
+   case mmGB_MACROTILE_MODE10:
+   case mmGB_MACROTILE_MODE11:
+   case mmGB_MACROTILE_MODE12:
+   case