Hi Felix,
the pfn (mem->start) is set by the address space manager to
AMDGPU_BO_INVALID_OFFSET which is a very high number.
So setting the lpfn to an explicit value for the validation will result
in reallocation of the backing store because AMDGPU_BO_INVALID_OFFSET
will always be larger than
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 = a
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 ... hm
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 fr
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 rel
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.
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/gp
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/a
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
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
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
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
Fro
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/wri
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.
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.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gf
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.free
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
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 a
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 f
On Sun, Oct 9, 2016 at 1:28 PM, Grazvydas Ignotas wrote:
> When DisplayPort AUX channel i2c adapter is registered, drm_connector's
> kdev member is used as a parent, so we get sysfs structure like:
> /drm/card1/card1-DP-2/i2c-12
> Because of that, there is a problem when drm core (and not the dr
Port the amdgpu fixes from Grazvydas to radeon.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=98200
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_connectors.c | 18 ++
drivers/gpu/drm/radeon/radeon_i2c.c| 3 +--
2 files changed, 19 insertions(+), 2 d
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
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_
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
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:
> -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
>
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/am
Thanks for the explanation (and the one on patch 1). The whole series is
Reviewed-by: Felix Kuehling
On 16-10-11 05:34 AM, Christian König wrote:
> Hi Felix,
>
> the pfn (mem->start) is set by the address space manager to
> AMDGPU_BO_INVALID_OFFSET which is a very high number.
>
> So setting th
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
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/a
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 advoc
Currently supports CZ/VI. Allows nearly atomic read
of wave data from GPU.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 74 ++
1 file changed, 74 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm
Add type, align_mask and nop to the physical mode UVD funcs as well.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c
b/drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c
index 15708f8..8f8a5dd
+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
Rex what is your opinion on exposing the amdgpu drm structure through
to powerplay? We could do an intermediate interface, but that just
seems like extra hoops to jump through for pretty questionable gain.
Alex
On Fri, Oct 7, 2016 at 2:28 PM, Alex Deucher wrote:
> Used by the powerplay dpm code
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 a
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
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änze
On 12/10/16 01:26 AM, Alex Deucher wrote:
> Port the amdgpu fixes from Grazvydas to radeon.
>
> bug:
> https://bugs.freedesktop.org/show_bug.cgi?id=98200
>
> Signed-off-by: Alex Deucher
[...]
> @@ -938,6 +948,7 @@ static void radeon_connector_destroy(struct drm_connector
> *connector)
>
39 matches
Mail list logo
