date:20161011

Re: [PATCH] drm/amd/amdgpu: Allow broadcast on debugfs read (v2)

2016-10-11 Thread Michel Dänzer

On 11/10/16 09:32 PM, StDenis, Tom wrote:
> It's used by the UMD though they read from 0/*/* when reading the
> RASTER_CONFIG registers (which may be a bug...)

We should probably clarify what userspace is trying to do there, and
whether the hardware actually does that.


-- 
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/i915: Before pageflip, also wait for shared dmabuf fences.

2016-10-11 Thread Michel Dänzer

On 11/10/16 09:04 PM, Christian König wrote:
> Am 11.10.2016 um 05:58 schrieb Michel Dänzer:
>> On 07/10/16 09:34 PM, Mike Lothian wrote:
>>> This has discussion has gone a little quiet
>>>
>>> Was there any agreement about what needed doing to get this working
>>> for i965/amdgpu?
>> Christian, do you see anything which could prevent the solution I
>> outlined from working?
> 
> I thought about that approach as well, but unfortunately it also has a
> couple of downsides. Especially keeping the exclusive fence set while we
> actually don't need it isn't really clean either.

I was wondering if it's possible to have a singleton pseudo exclusive
fence which is used for all BOs. That might keep the overhead acceptably
low.


> I'm currently a bit busy with other tasks and so put Nayan on a road to
> get a bit into the kernel driver (he asked for that anyway).
> 
> Implementing the simple workaround to sync when we export the DMA-buf
> should be something like 20 lines of code and fortunately Nayan has an
> I+A system and so can actually test it.
> 
> If it turns out to be more problematic or somebody really starts to need
> it I'm going to hack on that myself a bit more.

If you mean only syncing when a DMA-buf is exported, that's not enough,
as I explained before. The BOs being shared are long-lived, and
synchronization between GPUs is required for every command stream
submission.


-- 
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 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 
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 
 Reviewed-by: Alex Deucher 

:04 04 a8f2ca9290985991b3cc37cbeb902f060573fdbb 
2309b176a1d4ff9e59eaf25688b5db6eb9759dd0 M  drivers





From: amd-gfx  on behalf of StDenis, Tom 

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 
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  on behalf of StDenis, Tom 

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  on behalf of Andy Furniss 

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:

Re: [PATCH] drm/amd/powerplay: don't give up if DPM is already running

2016-10-11 Thread Alex Deucher

+Rex to review this.

Alex

On Sun, Oct 9, 2016 at 3:23 PM, Grazvydas Ignotas  wrote:
> Currently the driver crashes if smu7_enable_dpm_tasks() returns early,
> which it does if DPM is already active. It seems to be better just to
> continue anyway, at least I haven't noticed any ill effects. It's also
> unclear at what state the hardware was left by the previous driver, so
> IMO it's better to always fully initialize.
>
> Way to reproduce:
> $ modprobe amdgpu
> $ rmmod amdgpu
> $ modprobe amdgpu
> ...
> DPM is already running right now, no need to enable DPM!
> ...
> failed to send message 18b ret is 0
> BUG: unable to handle kernel paging request at ed01fc9ab21f
> Call Trace:
>  smu7_set_power_state_tasks+0x499/0x1940 [amdgpu]
>  phm_set_power_state+0xcb/0x120 [amdgpu]
>  psm_adjust_power_state_dynamic+0x11e/0x1b0 [amdgpu]
>  pem_task_adjust_power_state+0xb9/0xd0 [amdgpu]
>  pem_excute_event_chain+0x7d/0xe0 [amdgpu]
>  pem_handle_event_unlocked+0x49/0x60 [amdgpu]
>  pem_handle_event+0xe/0x10 [amdgpu]
>  pp_dpm_dispatch_tasks+0xe0/0x190 [amdgpu]
>  amdgpu_pm_compute_clocks+0x10c/0xc60 [amdgpu]
>  dce_v11_0_crtc_dpms+0x7d/0x150 [amdgpu]
>  dce_v11_0_crtc_disable+0x90/0x4a0 [amdgpu]
>  drm_helper_disable_unused_functions+0x67/0x80 [drm_kms_helper]
>  amdgpu_fbdev_init+0x13e/0x170 [amdgpu]
>  amdgpu_device_init+0x1aeb/0x2490 [amdgpu]
>
> Signed-off-by: Grazvydas Ignotas 
> ---
>  drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c 
> b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> index f6afa6a..327030b 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> @@ -1166,8 +1166,8 @@ static int smu7_enable_dpm_tasks(struct pp_hwmgr *hwmgr)
>
> tmp_result = (!smum_is_dpm_running(hwmgr)) ? 0 : -1;
> PP_ASSERT_WITH_CODE(tmp_result == 0,
> -   "DPM is already running right now, no need to enable 
> DPM!",
> -   return 0);
> +   "DPM is already running",
> +   );
>
> if (smu7_voltage_control(hwmgr)) {
> tmp_result = smu7_enable_voltage_control(hwmgr);
> --
> 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

More debugfs entries

2016-10-11 Thread Tom St Denis

Resending the MMIO upgrades for completeness.  Christian offered
an ACK but I'd like to see a RB or NAK.

This also adds a debugfs entry used to read wave data on CZ/VI
platforms (tested on my Carrizo).  

The patch #3 already has a use in reading SQ information from
user space so I'd like to advocate for that one as well.

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

[PATCH 2/3] drm/amd/amdgpu: Allow broadcast on debugfs read (v2)

2016-10-11 Thread Tom St Denis

Allow any of the se/sh/instance fields to be
specified as a broadcast by submitting 0x3FF.

(v2) Fix broadcast range checking

Signed-off-by: Tom St Denis 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index b1ab6358fa0f..c37d016b6256 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2574,6 +2574,13 @@ static ssize_t amdgpu_debugfs_regs_read(struct file *f, 
char __user *buf,
se_bank = (*pos >> 24) & 0x3FF;
sh_bank = (*pos >> 34) & 0x3FF;
instance_bank = (*pos >> 44) & 0x3FF;
+
+   if (se_bank == 0x3FF)
+   se_bank = 0x;
+   if (sh_bank == 0x3FF)
+   sh_bank = 0x;
+   if (instance_bank == 0x3FF)
+   instance_bank = 0x;
use_bank = 1;
} else {
use_bank = 0;
@@ -2582,8 +2589,8 @@ static ssize_t amdgpu_debugfs_regs_read(struct file *f, 
char __user *buf,
*pos &= 0x3;
 
if (use_bank) {
-   if (sh_bank >= adev->gfx.config.max_sh_per_se ||
-   se_bank >= adev->gfx.config.max_shader_engines)
+   if ((sh_bank != 0x && sh_bank >= 
adev->gfx.config.max_sh_per_se) ||
+   (se_bank != 0x && se_bank >= 
adev->gfx.config.max_shader_engines))
return -EINVAL;
mutex_lock(>grbm_idx_mutex);
amdgpu_gfx_select_se_sh(adev, se_bank,
-- 
2.10.0

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

[PATCH 3/3] drm/amd/amdgpu: Make debugfs write compliment read

2016-10-11 Thread Tom St Denis

Add PG lock support as well as bank selection to
the MMIO write function.

Signed-off-by: Tom St Denis 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 43 ++
 1 file changed, 43 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index c37d016b6256..6f8bd16205db 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2637,10 +2637,45 @@ static ssize_t amdgpu_debugfs_regs_write(struct file 
*f, const char __user *buf,
struct amdgpu_device *adev = f->f_inode->i_private;
ssize_t result = 0;
int r;
+   bool pm_pg_lock, use_bank;
+   unsigned instance_bank, sh_bank, se_bank;
 
if (size & 0x3 || *pos & 0x3)
return -EINVAL;
 
+   /* are we reading registers for which a PG lock is necessary? */
+   pm_pg_lock = (*pos >> 23) & 1;
+
+   if (*pos & (1ULL << 62)) {
+   se_bank = (*pos >> 24) & 0x3FF;
+   sh_bank = (*pos >> 34) & 0x3FF;
+   instance_bank = (*pos >> 44) & 0x3FF;
+
+   if (se_bank == 0x3FF)
+   se_bank = 0x;
+   if (sh_bank == 0x3FF)
+   sh_bank = 0x;
+   if (instance_bank == 0x3FF)
+   instance_bank = 0x;
+   use_bank = 1;
+   } else {
+   use_bank = 0;
+   }
+
+   *pos &= 0x3;
+
+   if (use_bank) {
+   if ((sh_bank != 0x && sh_bank >= 
adev->gfx.config.max_sh_per_se) ||
+   (se_bank != 0x && se_bank >= 
adev->gfx.config.max_shader_engines))
+   return -EINVAL;
+   mutex_lock(>grbm_idx_mutex);
+   amdgpu_gfx_select_se_sh(adev, se_bank,
+   sh_bank, instance_bank);
+   }
+
+   if (pm_pg_lock)
+   mutex_lock(>pm.mutex);
+
while (size) {
uint32_t value;
 
@@ -2659,6 +2694,14 @@ static ssize_t amdgpu_debugfs_regs_write(struct file *f, 
const char __user *buf,
size -= 4;
}
 
+   if (use_bank) {
+   amdgpu_gfx_select_se_sh(adev, 0x, 0x, 
0x);
+   mutex_unlock(>grbm_idx_mutex);
+   }
+
+   if (pm_pg_lock)
+   mutex_unlock(>pm.mutex);
+
return result;
 }
 
-- 
2.10.0

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

Re: [PATCH] drm/amdgpu: fix broken VCE startup in phys mode

2016-10-11 Thread Andy Furniss


I can boot OK with this.

Christian König wrote:

From: Christian König 

Add type, align_mask and nop to the physical mode VCE funcs as well.

Signed-off-by: Christian König 
---
  drivers/gpu/drm/amd/amdgpu/vce_v3_0.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c 
b/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
index f7dbd0d..c7ddbef 100644
--- a/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
@@ -829,6 +829,9 @@ const struct amd_ip_funcs vce_v3_0_ip_funcs = {
  };

  static const struct amdgpu_ring_funcs vce_v3_0_ring_phys_funcs = {
+   .type = AMDGPU_RING_TYPE_VCE,
+   .align_mask = 0xf,
+   .nop = VCE_CMD_NO_OP,
.get_rptr = vce_v3_0_ring_get_rptr,
.get_wptr = vce_v3_0_ring_get_wptr,
.set_wptr = vce_v3_0_ring_set_wptr,



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

RE: [PATCH] drm/amdgpu: fix broken VCE startup in phys mode

2016-10-11 Thread Deucher, Alexander

> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Christian König
> Sent: Tuesday, October 11, 2016 1:34 PM
> To: amd-gfx@lists.freedesktop.org
> Subject: [PATCH] drm/amdgpu: fix broken VCE startup in phys mode
> 
> From: Christian König 
> 
> Add type, align_mask and nop to the physical mode VCE funcs as well.
> 
> Signed-off-by: Christian König 


Please update uvd6 physical mode as well.

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdgpu/vce_v3_0.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
> b/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
> index f7dbd0d..c7ddbef 100644
> --- a/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
> @@ -829,6 +829,9 @@ const struct amd_ip_funcs vce_v3_0_ip_funcs = {
>  };
> 
>  static const struct amdgpu_ring_funcs vce_v3_0_ring_phys_funcs = {
> + .type = AMDGPU_RING_TYPE_VCE,
> + .align_mask = 0xf,
> + .nop = VCE_CMD_NO_OP,
>   .get_rptr = vce_v3_0_ring_get_rptr,
>   .get_wptr = vce_v3_0_ring_get_wptr,
>   .set_wptr = vce_v3_0_ring_set_wptr,
> --
> 2.5.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] drm/amdgpu: fix broken VCE startup in phys mode

2016-10-11 Thread StDenis, Tom

Yup, with it I get a normal modprobe.


Can add my


Ack-By: Tom St Denis 



From: amd-gfx  on behalf of Christian 
König 
Sent: Tuesday, October 11, 2016 13:33
To: amd-gfx@lists.freedesktop.org
Subject: [PATCH] drm/amdgpu: fix broken VCE startup in phys mode

From: Christian König 

Add type, align_mask and nop to the physical mode VCE funcs as well.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/vce_v3_0.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c 
b/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
index f7dbd0d..c7ddbef 100644
--- a/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
@@ -829,6 +829,9 @@ const struct amd_ip_funcs vce_v3_0_ip_funcs = {
 };

 static const struct amdgpu_ring_funcs vce_v3_0_ring_phys_funcs = {
+   .type = AMDGPU_RING_TYPE_VCE,
+   .align_mask = 0xf,
+   .nop = VCE_CMD_NO_OP,
 .get_rptr = vce_v3_0_ring_get_rptr,
 .get_wptr = vce_v3_0_ring_get_wptr,
 .set_wptr = vce_v3_0_ring_set_wptr,
--
2.5.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
amd-gfx Info Page - 
lists.freedesktop.org
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 8/8] drm/amdgpu: move align_mask and nop into ring funcs as well

2016-10-11 Thread Christian König

Turned out I just missed adding the three lines to the physical mode for 
VCE on Tonga as well.

Please test and review the patch I've just send to the mailing list.

Regards,
Christian.

Am 11.10.2016 um 15:28 schrieb StDenis, Tom:

It dies on my Tonga just FYI (save you some trouble).

Tom

*From:* amd-gfx  on behalf of 
Christian König 

*Sent:* Tuesday, October 11, 2016 09:26
*To:* Andy Furniss; amd-gfx@lists.freedesktop.org
*Subject:* Re: [PATCH 8/8] drm/amdgpu: move align_mask and nop into 
ring funcs as well

Am 11.10.2016 um 15:13 schrieb Andy Furniss:
> Christian König wrote:
>> From: Christian König 
>>
>> They are constant as well.
>
> I die on driver load with this commit on R9285 testing on 4.9-wip.
>
>
Probably just a typo in the hardware handling.

Going to switch to my Tonga in a minute, but I only got about half an
hour left before I need to get my daughter from kindergarten.

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

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

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

[PATCH] drm/amdgpu: fix broken VCE startup in phys mode

2016-10-11 Thread Christian König

From: Christian König 

Add type, align_mask and nop to the physical mode VCE funcs as well.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/vce_v3_0.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c 
b/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
index f7dbd0d..c7ddbef 100644
--- a/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
@@ -829,6 +829,9 @@ const struct amd_ip_funcs vce_v3_0_ip_funcs = {
 };
 
 static const struct amdgpu_ring_funcs vce_v3_0_ring_phys_funcs = {
+   .type = AMDGPU_RING_TYPE_VCE,
+   .align_mask = 0xf,
+   .nop = VCE_CMD_NO_OP,
.get_rptr = vce_v3_0_ring_get_rptr,
.get_wptr = vce_v3_0_ring_get_wptr,
.set_wptr = vce_v3_0_ring_set_wptr,
-- 
2.5.0

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

[PATCH 2/2] drm/radeon: fix modeset tear down code

2016-10-11 Thread Alex Deucher

The ordering caused problems.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=98200

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/radeon_display.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
b/drivers/gpu/drm/radeon/radeon_display.c
index b8ab30a..cdb8cb56 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -1675,20 +1675,20 @@ int radeon_modeset_init(struct radeon_device *rdev)
 
 void radeon_modeset_fini(struct radeon_device *rdev)
 {
-   radeon_fbdev_fini(rdev);
-   kfree(rdev->mode_info.bios_hardcoded_edid);
-
-   /* free i2c buses */
-   radeon_i2c_fini(rdev);
-
if (rdev->mode_info.mode_config_initialized) {
-   radeon_afmt_fini(rdev);
drm_kms_helper_poll_fini(rdev->ddev);
radeon_hpd_fini(rdev);
drm_crtc_force_disable_all(rdev->ddev);
+   radeon_fbdev_fini(rdev);
+   radeon_afmt_fini(rdev);
drm_mode_config_cleanup(rdev->ddev);
rdev->mode_info.mode_config_initialized = false;
}
+
+   kfree(rdev->mode_info.bios_hardcoded_edid);
+
+   /* free i2c buses */
+   radeon_i2c_fini(rdev);
 }
 
 static bool is_hdtv_mode(const struct drm_display_mode *mode)
-- 
2.5.5

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

Re: [PATCH 8/8] drm/amdgpu: move align_mask and nop into ring funcs as well

2016-10-11 Thread StDenis, Tom

It dies on my Tonga just FYI (save you some trouble).

Tom

From: amd-gfx  on behalf of Christian 
König 
Sent: Tuesday, October 11, 2016 09:26
To: Andy Furniss; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 8/8] drm/amdgpu: move align_mask and nop into ring funcs as 
well

Am 11.10.2016 um 15:13 schrieb Andy Furniss:
> Christian König wrote:
>> From: Christian König 
>>
>> They are constant as well.
>
> I die on driver load with this commit on R9285 testing on 4.9-wip.
>
>
Probably just a typo in the hardware handling.

Going to switch to my Tonga in a minute, but I only got about half an
hour left before I need to get my daughter from kindergarten.

Christian.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
amd-gfx Info Page - 
lists.freedesktop.org
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 8/8] drm/amdgpu: move align_mask and nop into ring funcs as well

2016-10-11 Thread Christian König


Am 11.10.2016 um 15:13 schrieb Andy Furniss:

Christian König wrote:

From: Christian König 

They are constant as well.


I die on driver load with this commit on R9285 testing on 4.9-wip.



Probably just a typo in the hardware handling.

Going to switch to my Tonga in a minute, but I only got about half an 
hour left before I need to get my daughter from kindergarten.


Christian.
___
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

Yup confirmed...


[root@fx6 linux]# git bisect good
da00756f75422b04befae381e7e48d0cacf299f3 is the first bad commit
commit da00756f75422b04befae381e7e48d0cacf299f3
Author: Christian König 
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 
Reviewed-by: Alex Deucher 

:04 04 a8f2ca9290985991b3cc37cbeb902f060573fdbb 
2309b176a1d4ff9e59eaf25688b5db6eb9759dd0 M  drivers





From: amd-gfx  on behalf of StDenis, Tom 

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 
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  on behalf of StDenis, 
> Tom 
> 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  on behalf of Andy 
> Furniss 
> 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:

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 
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  on behalf of StDenis, 
> Tom 
> 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  on behalf of Andy 
> Furniss 
> 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 -

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  on behalf of StDenis, Tom 

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  on behalf of Andy Furniss 

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
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] drm/amd/amdgpu: Make debugfs write compliment read

2016-10-11 Thread Christian König

Hi Tom,

yeah, the timing issue is a good argument. In this case just go ahead 
and add my Acked-by to the patch.

Regards,
Christian.

Am 11.10.2016 um 14:19 schrieb StDenis, Tom:

Hi Christian,

I agree with the crux of your argument but you can crash the system 
with carefully timed read/writes from the GFX registers, or MC, or ... 
That's why the entries are root only.

The issue with locking excessively is you might change behaviour of 
something you're trying to debug because the kernel then has to wait 
on the lock (or you're waiting on the lock).  For instance, suppose 
you want to read DCE registers and the kernel is doing some gfx/grbm 
related your DCE read will either block the GFX activity or you're 
waiting on it which means the behaviour of the system could be 
different than from the case where you're not probing the registers.

The goal is to be as unobtrusive as possible.  Heck I often mmap the 
BAR so I can read MMIO registers directly and not waste CPU cycles on 
syscalls.

The PM lock is because reading PGFSM registers during a powerup/down 
results in a GPU hang, and we only take the GRBM lock when users want 
to read from specific banks.  For any other case we don't need a lock. 
 In the kernel they should be mutually exclusive.  The PM lock is only 
taken in PP when performing a transition (or initializing the core) 
and I have yet to see a place where PP/PM related code also grabs the 
grbm index lock.

I don't have strong feelings against your proposal but I do prefer not 
to take the locks when I don't need to.  Ultimately I'll leave the 
decision up to you and Alex.  I'd like to get the 2nd patch through 
though as it makes the write side of the mmio reg complimentary (e.g. 
bank selection/pm lock).

Cheers,
Tom

*From:* Christian König 
*Sent:* Tuesday, October 11, 2016 08:11
*To:* StDenis, Tom; amd-gfx@lists.freedesktop.org
*Subject:* Re: [PATCH] drm/amd/amdgpu: Make debugfs write compliment read

The only downside to taking the locks all the time is for 99% of 
debug reads it's unnecessary and in theory could lead to 
performance/behaviour problems.

Yeah, but performance isn't critical here and taking two locks 
compared to the rest of what we (IOCTL etc...) do is completely 
negligibly.

I've been using this on read for a while now and haven't noticed a 
problem.

My concern is rather that somebody tries to write to the PM regs on 
accident or purpose without taking the lock.

See, the kernel is usually responsible to keep people from doing 
stupid things with the hardware, even if those people are root and 
could do stupid things anyway. Well, you know what I mean?

Regards,
Christian.

Am 10.10.2016 um 22:21 schrieb StDenis, Tom:

The only downside to taking the locks all the time is for 99% of 
debug reads it's unnecessary and in theory could lead to 
performance/behaviour problems.

I've been using this on read for a while now and haven't noticed a 
problem.

Tom

*From:* Christian König 
*Sent:* Monday, October 10, 2016 09:49
*To:* Tom St Denis; amd-gfx@lists.freedesktop.org
*Cc:* StDenis, Tom
*Subject:* Re: [PATCH] drm/amd/amdgpu: Make debugfs write compliment 
read
Would it hurt us to always take the looks (both the pm as well as 
grbm idx lock)?

I don't think that would be much of an issue and I would have a 
better feeling with that.

Christian.

Am 10.10.2016 um 15:38 schrieb Tom St Denis:

that's kind of the point.  Its for debugging only.  Also reads can 
already lock

On Mon, Oct 10, 2016, 09:25 Christian König > wrote:

Mhm, that userspace controls if the lock is taken or not is a bit
problematic, on the other hand only root could access that.

Christian.

Am 10.10.2016 um 14:51 schrieb Tom St Denis:
> Add PG lock support as well as bank selection to
> the MMIO write function.
>
> Signed-off-by: Tom St Denis >
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 43
++
>   1 file changed, 43 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 04c4aee70452..a9d83c1d7a43 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -2637,10 +2637,45 @@ static ssize_t
amdgpu_debugfs_regs_write(struct file *f, const char __user *buf,
>   struct amdgpu_device *adev = f->f_inode->i_private;
>   ssize_t result = 0;
>   int r;
> + bool pm_pg_lock, use_bank;
> + unsigned instance_bank, sh_bank, se_bank;
>
>   if (size & 0x3 || *pos & 0x3)
>

Re: [PATCH] drm/amd/amdgpu: Allow broadcast on debugfs read (v2)

2016-10-11 Thread StDenis, Tom

It's used by the UMD though they read from 0/*/* when reading the RASTER_CONFIG 
registers (which may be a bug...)

I only added it because the previous interface was either */*/* or x/y/z (where 
none are *).  Now it supports arbitrary bank selections.

Tom

From: Christian König 
Sent: Tuesday, October 11, 2016 08:30
To: StDenis, Tom; Michel Dänzer
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amd/amdgpu: Allow broadcast on debugfs read (v2)

I briefly remember reading in some hardware doc that this actually has a 
defined behavior.

It was something about applying either bit wise "and" or "or" on the resulting 
bits and returning that to the reader.

This way you can check with a single broadcast read if an error occurred or if 
any of the instances are busy.

But if you don't actually use it I suggest to not implement this.

Regards,
Christian.

Am 11.10.2016 um 12:26 schrieb StDenis, Tom:

That actually makes sense.  It came up because mmPA_SC_RASTER_CONFIG (and _1) 
are read by libdrm with a selection of 0/*/* for se/sh/instance so I wanted to 
be able to reproduce that via the debugfs interface for testing.

But ya, if you use the broadcast bit who are you reading from then ... hmm..

Tom

From: amd-gfx 

 on behalf of Michel Dänzer 

Sent: Monday, October 10, 2016 23:52
To: Tom St Denis
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amd/amdgpu: Allow broadcast on debugfs read (v2)

On 09/10/16 08:58 PM, Tom St Denis wrote:
> Allow any of the se/sh/instance fields to be
> specified as a broadcast by submitting 0x3FF.
>
> (v2) Fix broadcast range checking
>
> Signed-off-by: Tom St Denis 

I'm not sure how a "broadcast read" is supposed to work? I can only see
the register specs talking about broadcast in connection with writes.

--
Earthling Michel Dänzer   |   http://www.amd.com
Graphics, Processors and Immersive VR Solutions | AMD 
www.amd.com
Explore a wide range of innovative next generation computing processors, 
graphics, and Immersive VR solutions by Advanced Micro Devices (AMD). Visit 
AMD.com now!

Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
amd-gfx Info Page - 
lists.freedesktop.org
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

___
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  on behalf of StDenis, Tom 

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  on behalf of Andy Furniss 

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
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 1/2] drm/amdgpu: clarify why we evict vram twice on suspend

2016-10-11 Thread Christian König


Am 10.10.2016 um 18:49 schrieb Alex Deucher:

Update the comment to explain why we do this.

Signed-off-by: Alex Deucher 


Reviewed-by: Christian König  for both.


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

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index bfca676..b88a3b7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1958,7 +1958,10 @@ int amdgpu_device_suspend(struct drm_device *dev, bool 
suspend, bool fbcon)
  
  	r = amdgpu_suspend(adev);
  
-	/* evict remaining vram memory */

+   /* evict remaining vram memory
+* This second call to evict vram is to evict the gart page table
+* using the CPU.
+*/
amdgpu_bo_evict_vram(adev);
  
  	pci_save_state(dev->pdev);



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

Re: [PATCH 1/6] drm/amdgpu: add AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS flag v3

2016-10-11 Thread Christian König


Am 07.10.2016 um 23:19 schrieb Felix Kuehling:

On 16-09-27 05:49 AM, Christian König wrote:

--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1195,6 +1195,15 @@ int amdgpu_cs_sysvm_access_required(struct 
amdgpu_cs_parser *parser)
r = amdgpu_ttm_bind(>tbo, >tbo.mem);
if (unlikely(r))
return r;
+
+   if (bo->flags & AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS)
+   continue;

Should you also continue if the BO is not VRAM?


No, the placement of the BO at this point isn't final. For older UVD 
blocks this can still be shuffled around to fulfill the placement 
restrictions.


So the BO could still move into VRAM even after this.

Regards,
Christian.



Regards,
   Felix


+
+   bo->flags |= AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS;
+   amdgpu_ttm_placement_from_domain(bo, bo->allowed_domains);
+   r = ttm_bo_validate(>tbo, >placement, false, false);
+   if (unlikely(r))
+   return r;
}
  
  	return 0;



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

Re: [PATCH] drm/amd/amdgpu: Allow broadcast on debugfs read (v2)

Re: [PATCH] drm/i915: Before pageflip, also wait for shared dmabuf fences.

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

Re: [PATCH] drm/amd/powerplay: don't give up if DPM is already running

More debugfs entries

[PATCH 2/3] drm/amd/amdgpu: Allow broadcast on debugfs read (v2)

[PATCH 3/3] drm/amd/amdgpu: Make debugfs write compliment read

Re: [PATCH] drm/amdgpu: fix broken VCE startup in phys mode

RE: [PATCH] drm/amdgpu: fix broken VCE startup in phys mode

Re: [PATCH] drm/amdgpu: fix broken VCE startup in phys mode

Re: [PATCH 8/8] drm/amdgpu: move align_mask and nop into ring funcs as well

[PATCH] drm/amdgpu: fix broken VCE startup in phys mode

[PATCH 2/2] drm/radeon: fix modeset tear down code

Re: [PATCH 8/8] drm/amdgpu: move align_mask and nop into ring funcs as well

Re: [PATCH 8/8] drm/amdgpu: move align_mask and nop into ring funcs as well

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

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

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

Re: [PATCH] drm/amd/amdgpu: Make debugfs write compliment read

Re: [PATCH] drm/amd/amdgpu: Allow broadcast on debugfs read (v2)

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

Re: [PATCH 1/2] drm/amdgpu: clarify why we evict vram twice on suspend

Re: [PATCH 1/6] drm/amdgpu: add AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS flag v3

23 matches

Site Navigation

Mail list logo

Footer information