> -Original Message-
> From: Bjorn Helgaas [mailto:helg...@kernel.org]
> Sent: Tuesday, June 06, 2017 7:10 PM
> To: Christian König
> Cc: linux-...@vger.kernel.org; platform-driver-...@vger.kernel.org;
> Deucher, Alexander; David Airlie; amd-gfx@lists.freedesktop.org; dri-
> de...@lists.fre
Done!
https://bugs.freedesktop.org/show_bug.cgi?id=101325
Also, running ue4editor with R600_DEBUG=check_vm GALLIUM_DDEBUG="pipelined
1" set made a difference -- program crashed but didn't take out the
whole system. I take that as a good sign.
Luke
On 7 June 2017 at 00:09, Alex Deucher wrot
On 2017年06月06日 20:01, Christian König wrote:
Am 06.06.2017 um 11:27 schrieb Monk Liu:
for SR-IOV, we must keep the pipeline-sync in the protection
of COND_EXEC, otherwise the command consumed by CPG is not
consistent when world switch triggerd, e.g.:
world switch hit and the IB frame is skipp
Hi Alex,
> As I work more for open source driver, this digest mode becomes more
> annoying.
>
> I didn't even know that amd-gfx can send individual emails to me. As a
> result, I did not know how to ask correct question about my puzzling. I
> did ask around once.
>
> Now I wondered how I enab
On Tue, Jun 06, 2017 at 01:51:11PM +0200, Christian König wrote:
> Am 02.06.2017 um 22:26 schrieb Bjorn Helgaas:
> >On Fri, Jun 02, 2017 at 11:32:21AM +0200, Christian König wrote:
> >>Hi Bjorn,
> >>
> >>sorry for not responding earlier and thanks for picking this thread
> >>up again.
> >>
> >>Am 0
Thanks for the change. "static inline" may improve speed, though this
patch is not a critical code path. Perhaps it will be true in future...
Reviewed-by: Alex Xie
On 2017-06-06 06:19 PM, Alex Deucher wrote:
The same function was duplicated in all the gfx IPs. Use
a single implementation for
The same function was duplicated in all the gfx IPs. Use
a single implementation for all.
v2: use static inline (Alex Xie)
Suggested-by: Andres Rodriguez
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 13 +
drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 11 +++
> -Original Message-
> From: Panariti, David
> Sent: Tuesday, June 06, 2017 5:50 PM
> To: Deucher, Alexander; amd-gfx@lists.freedesktop.org
> Subject: RE: [PATCH 3/3] drm/amdgpu: Add kernel parameter to control use
> of ECC/EDC.
>
> Rather than inlining this in a number of places, Re verbo
For such a simple function, I would implement it inside the header file
with "static inline".
Thanks,
Alex Bin
On 2017-06-06 05:42 PM, Alex Deucher wrote:
The same function was duplicated in all the gfx IPs. Use
a single implementation for all.
Suggested-by: Andres Rodriguez
Signed-off-by:
Rather than inlining this in a number of places, Re verbosity:
I've worked in embedded environments and when dealing with intermittent
problems it's nice to have all of the information ASAP rather than waiting for
a problem to reoccur, especially if it's very intermittent.
I would've preferred mo
The same function was duplicated in all the gfx IPs. Use
a single implementation for all.
Suggested-by: Andres Rodriguez
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 13 +
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 2 ++
drivers/gpu/drm/amd/amdgpu/gfx_v6
On 2017-05-31 10:16 AM, Alex Deucher wrote:
Always use the max for the family rather than the per sku limits.
This makes sure the mask is always the max size to avoid reporting
the wrong number of CUs.
Cc: sta...@vger.kernel.org
Signed-off-by: Alex Deucher
Reviewed-by: Andres Rodriguez
---
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of David Panariti
> Sent: Tuesday, June 06, 2017 4:33 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Panariti, David
> Subject: [PATCH 3/3] drm/amdgpu: Add kernel parameter to control use of
> ECC/
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of David Panariti
> Sent: Tuesday, June 06, 2017 4:33 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Panariti, David
> Subject: [PATCH 1/3] drm/amdgpu: Moved gfx_v8_0_select_se_sh() in lieu
> of re
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of David Panariti
> Sent: Tuesday, June 06, 2017 4:33 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Panariti, David
> Subject: [PATCH 2/3] drm/amdgpu: Complete Carrizo EDC (Error Detection
> and C
Allow various kinds of memory integrity methods (e.g. ECC/EDC) to be enabled
or disabled. By default, all features are disabled.
EDC is Error Detection and Correction. It can detect ECC errors and do 0 or
more of: count SEC (single error corrected) and DED (double error detected,
i.e. uncorrecte
Will be needed for the rest of the EDC workarounds patch.
Signed-off-by: David Panariti
---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 46 +--
1 file changed, 23 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
b/drivers/gpu/drm/amd
I've made the workarounds function a bit verbose because EDC enabled CZs are
often used in an embedded environment and providing as much information as
possible can be very helpful in debugging.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
ht
The workarounds are unconditionally performed on CZs with EDC enabled.
EDC detects uncorrected ECC errors and uses data poisoning to prevent
corrupted compute results from being used (read).
EDC enabled CZs are often used in embedded environments.
Signed-off-by: David Panariti
---
drivers/gpu/dr
On Wed, May 31, 2017 at 10:16 AM, Alex Deucher wrote:
> Always use the max for the family rather than the per sku limits.
> This makes sure the mask is always the max size to avoid reporting
> the wrong number of CUs.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Alex Deucher
Ping?
Alex
> --
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Hawking Zhang
> Sent: Tuesday, June 06, 2017 4:36 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Zhang, Hawking
> Subject: [PATCH 2/2] drm/amd/powerplay: fix memory leak in cz_hwmgr
> backend
>
> -Original Message-
> From: Yu, Xiangliang
> Sent: Monday, June 05, 2017 10:33 PM
> To: Deucher, Alexander; amd-gfx@lists.freedesktop.org
> Subject: RE: [PATCH] drm/amdgpu: correct clock info for SRIOV
>
> > > Currently, get clock info from default clk of pm if dpm is disable.
> > > Buf S
On Tue, Jun 6, 2017 at 10:52 AM, Huang Rui wrote:
> On Tue, Jun 06, 2017 at 10:45:42PM +0800, Alex Deucher wrote:
>> On Tue, Jun 6, 2017 at 10:03 AM, Alex Deucher wrote:
>> > On Tue, Jun 6, 2017 at 7:22 AM, Christian König
>> > wrote:
>> >>> Yes, I agree with you. That's also my orignal opinion.
On Tue, Jun 06, 2017 at 10:52:46PM +0800, Huang Rui wrote:
> On Tue, Jun 06, 2017 at 10:45:42PM +0800, Alex Deucher wrote:
> > On Tue, Jun 6, 2017 at 10:03 AM, Alex Deucher wrote:
> > > On Tue, Jun 6, 2017 at 7:22 AM, Christian K?nig
> > > wrote:
> > >>> Yes, I agree with you. That's also my orig
On Tue, Jun 06, 2017 at 10:45:42PM +0800, Alex Deucher wrote:
> On Tue, Jun 6, 2017 at 10:03 AM, Alex Deucher wrote:
> > On Tue, Jun 6, 2017 at 7:22 AM, Christian König
> > wrote:
> >>> Yes, I agree with you. That's also my orignal opinion.
> >>> But we encountered a random buggy when we were cal
On Tue, Jun 6, 2017 at 10:03 AM, Alex Deucher wrote:
> On Tue, Jun 6, 2017 at 7:22 AM, Christian König
> wrote:
>>> Yes, I agree with you. That's also my orignal opinion.
>>> But we encountered a random buggy when we were calling
>>> device_cache_fw_images.
>>
>> That looks like an upstream bug i
On Mon, Jun 5, 2017 at 10:05 PM, Michel Dänzer wrote:
> On 03/06/17 07:46 AM, Luke Miller wrote:
>>
>> I have a recurring problem with one 3D program (UE4editor) crashing my
>> computer during a particular operation.
>>
>> I believe the problem is at the DRM layer.
>
> It's actually more likely in
On Tue, Jun 6, 2017 at 7:22 AM, Christian König
wrote:
>> Yes, I agree with you. That's also my orignal opinion.
>> But we encountered a random buggy when we were calling
>> device_cache_fw_images.
>
> That looks like an upstream bug in device_cache_fw_images.
>
> We should probably open a bug rep
On Mon, Jun 05, 2017 at 03:59:37PM -0400, Harry Wentland wrote:
> On 2017-06-05 03:50 PM, Alex Deucher wrote:
> > On Mon, Jun 5, 2017 at 2:43 PM, Harry Wentland
> > wrote:
> > > Create crtc/connector combinations based on actual adapter
> > > information obtained from drmModeRes.
> > >
> > > Als
Hi Michel,
Thanks.
As I work more for open source driver, this digest mode becomes more
annoying.
I didn't even know that amd-gfx can send individual emails to me. As a
result, I did not know how to ask correct question about my puzzling. I
did ask around once.
Now I wondered how I enab
On Tue, Jun 6, 2017 at 7:51 AM, Christian König wrote:
> Am 02.06.2017 um 22:26 schrieb Bjorn Helgaas:
>>
>> On Fri, Jun 02, 2017 at 11:32:21AM +0200, Christian König wrote:
>>>
>>> Hi Bjorn,
>>>
>>> sorry for not responding earlier and thanks for picking this thread
>>> up again.
>>>
>>> Am 01.06
Hi Samuel,
With all the other discussion aside here is some code specific input
which I'd hope you agree with.
On 31 May 2017 at 21:22, Samuel Li wrote:
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -45,6 +45,9 @@ AM_DISTCHECK_CONFIGURE_FLAGS = \
>
> pkgconfigdir = @pkgconfigdir@
> pkgconfig_D
On 2017-06-06 03:43 AM, Petri Latvala wrote:
On Mon, Jun 05, 2017 at 03:59:37PM -0400, Harry Wentland wrote:
On 2017-06-05 03:50 PM, Alex Deucher wrote:
On Mon, Jun 5, 2017 at 2:43 PM, Harry Wentland wrote:
Create crtc/connector combinations based on actual adapter
information obtained from
Fell free to add an Acked-by: Christian König
on both.
Christian.
Am 06.06.2017 um 13:43 schrieb Tom St Denis:
First is Reviewed-by: Tom St Denis and second is
Acked-by.
Cheers,
Tom
On 05/06/17 11:06 AM, Alex Deucher wrote:
Pipes provide better concurrency than queues, therefore we want
Am 06.06.2017 um 11:27 schrieb Monk Liu:
for SR-IOV, we must keep the pipeline-sync in the protection
of COND_EXEC, otherwise the command consumed by CPG is not
consistent when world switch triggerd, e.g.:
world switch hit and the IB frame is skipped so the fence
won't signal, thus CP will jump
Am 02.06.2017 um 22:26 schrieb Bjorn Helgaas:
On Fri, Jun 02, 2017 at 11:32:21AM +0200, Christian König wrote:
Hi Bjorn,
sorry for not responding earlier and thanks for picking this thread
up again.
Am 01.06.2017 um 22:14 schrieb Bjorn Helgaas:
[+cc ADMGPU, DRM folks]
On Tue, May 09, 2017 at
First is Reviewed-by: Tom St Denis and second is
Acked-by.
Cheers,
Tom
On 05/06/17 11:06 AM, Alex Deucher wrote:
Pipes provide better concurrency than queues, therefore we want to make
sure that apps use queues from different pipes whenever possible.
Optimize for the trivial case where an ap
Yes, I agree with you. That's also my orignal opinion.
But we encountered a random buggy when we were calling
device_cache_fw_images.
That looks like an upstream bug in device_cache_fw_images.
We should probably open a bug report and ping the maintainer. Most
likely we are not correctly using t
for SR-IOV, we must keep the pipeline-sync in the protection
of COND_EXEC, otherwise the command consumed by CPG is not
consistent when world switch triggerd, e.g.:
world switch hit and the IB frame is skipped so the fence
won't signal, thus CP will jump to the next DMAframe's pipeline-sync
comman
vddc_dep_on_dal_pwrl is allocated and initialized in cz_hwmgr_backend_init
Thus free the memory in cz_hwmgr_backend_fini
Change-Id: Idd6dd4b76894579674bf334339b71df8559637fd
Signed-off-by: Hawking Zhang
---
drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c | 6 ++
1 file changed, 6 insertions(+
vddc_dep_on_dal_pwrl and vq_budgeting_table are allocated and initialized
in rv_hwmgr_backend_init. Thus free the memory in rv_hwmgr_backend_fini
Change-Id: I15878ccb6a39848b764844e45f2ac375164906ad
Signed-off-by: Hawking Zhang
---
drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c | 10 ++
On Tue, Jun 06, 2017 at 04:00:29PM +0800, Christian König wrote:
> Hi Ray,
>
> mhm, indeed a nice catch.
>
> But why do we need to load the gpu info after resume in the first place?
>
> I mean we already know what GPU we have, loading it again looks
> superfluous to me.
>
Yes, I agree with you
Hi Ray,
mhm, indeed a nice catch.
But why do we need to load the gpu info after resume in the first place?
I mean we already know what GPU we have, loading it again looks
superfluous to me.
Regards,
Christian.
Am 06.06.2017 um 08:24 schrieb Huang Rui:
gpu_info firmware is released after da
43 matches
Mail list logo
