Hi Luis,
please enable kmemleak in your build and watch out for any suspicious
messages in the system log.
Regards,
Christian.
Am 02.02.2018 um 00:03 schrieb Luís Mendes:
Hi Alexander,
I didn't notice improvements on this issue with that particular patch
applied. It still ends up failing to
Am 01.02.2018 um 22:49 schrieb Shaoyun Liu:
Change-Id: I9f794b9a4cbb3cc929ddc1e4f43d9509ce86d638
Signed-off-by: Shaoyun Liu
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/
Change-Id: I38b60d0be9dc800a3492dd9fb17dc56ade77c0db
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hw
Hi Tom,
The attached patch should be able to fix this issue.
Best Regards
Rex
-Original Message-
From: StDenis, Tom
Sent: Friday, February 02, 2018 2:58 AM
To: Deucher, Alexander; amd-gfx mailing list
Cc: Zhu, Rex; Lazare, Jordan; Wentland, Harry
Subject: Re: MCLK defaults high on sec
Change-Id: I2d7663e164ff8eeafe0a4fed99e106b1d130a285
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_h
Hi all,
We have gpu VM Fault problem sometimes with newest V4.15 kernel driver
and mesa V17.2.8
My gpu is Radeon Pro WX7100
There is a lot of kernel log printed like this:
Jan 31 13:35:44 ubuntu kernel: [120749.990185] amdgpu 000d:31:00.0: GPU fault
detected: 146 0x0608d20c
Jan 31 13:35:4
Change-Id: I6ff04e1199d1ebdbdb31d0e7e8ca3c240c61ab3a
Signed-off-by: Shaoyun Liu
---
drivers/gpu/drm/amd/amdgpu/Makefile | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 ++
drivers/gpu/drm/amd/amdgpu/emu_soc.c | 34 ++
drivers/gpu/drm/amd/amdgpu/soc15.c | 4 +
Add amdgpu_emu_mode module parameter to control the emulation mode
Avoid vbios operation on emulation since there is no vbios post duirng
emulation,
use the common hw_init to simulate the post
Change-Id: Iba32fa16e735490e7401e471219797b83c6c2a58
Signed-off-by: Shaoyun Liu
---
drivers/gpu/drm/am
Hi Alexander,
I didn't notice improvements on this issue with that particular patch
applied. It still ends up failing to allocate kernel memory after a
few hours of uptime with Xorg.
I will try to upgrade to mesa 18.0.0-rc3 and to amd-staging-drm-next
head, to see if the issue still occurs with t
Change-Id: I9f794b9a4cbb3cc929ddc1e4f43d9509ce86d638
Signed-off-by: Shaoyun Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 0f0b3ea
I don't care much, but the SRIOV guys are picky about how long we spend
with the GPU in exclusive mode and printing messages affect that quite a
bit.
Maybe print the config once after the whole initialization routine is
done or something like that.
Regards,
Christian.
Am 01.02.2018 um 22:13
We can certainly upstream ZFB support if we clean it up a bit more.
If we need some different default values and/or disable vbios access we
can add an amdgpu_emulation parameter to trigger setting those
automatically.
But please, no single #ifdef AMDGPU_EMULATOR_BUILD in the code. Nobody
out
Do you mind to change the DRM_DEBUG to DRM_INFO for this message ?
-Original Message-
From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com]
Sent: Thursday, February 01, 2018 4:11 PM
To: Liu, Shaoyun; Alex Deucher; Bridgman, John
Cc: Koenig, Christian; amd-gfx@lists.freedesktop
Am 01.02.2018 um 22:05 schrieb Liu, Shaoyun:
So you guys prefer to add some print out message of the bit mapping and
developer use that info to calculate the setting when load the module next
time ?
Yes, that would certainly help.
Christian.
Regards
Shaoyun.liu
-Original Message
So you guys prefer to add some print out message of the bit mapping and
developer use that info to calculate the setting when load the module next
time ?
Regards
Shaoyun.liu
-Original Message-
From: Alex Deucher [mailto:alexdeuc...@gmail.com]
Sent: Thursday, February 01, 2018 3:5
The changes I send out are try to minimize the emulation specific code , like
the ip_block_mask change , so developer can just change the module parameter
to enable the specific ip block during emulation. Otherwise we need a messy
ifdef to enable specific ip block for the specific ASIC to r
On Thu, Feb 1, 2018 at 3:44 PM, Liu, Shaoyun wrote:
> In that case , even existing implementation need to be changed and can we
> add VCE0 and VCE1 for ex as different IP type when necessary ?
That kind of waters down the meaning of block type. Plus if we ever
end up creating a chip with se
On 2018-02-01 03:02 PM, Alex Deucher wrote:
> On Thu, Feb 1, 2018 at 2:44 PM, wrote:
>> From: Mikita Lipski
>>
>> Call dm_suspend function instead of drm_kms suspend function in
>> order to cache current state
>>
>> Call DM_resume first to restore dc hardware, then amdgpu_dm_display_resume
>> t
In that case , even existing implementation need to be changed and can we
add VCE0 and VCE1 for ex as different IP type when necessary ?
Regards
Shaoyun.liu
-Original Message-
From: Alex Deucher [mailto:alexdeuc...@gmail.com]
Sent: Thursday, February 01, 2018 3:37 PM
To: Liu, Shaoy
On Thu, Feb 1, 2018 at 3:32 PM, Liu, Shaoyun wrote:
> Can you provide the example of which different block with the same type and
> why we want to do that ?
> With the old implementation , the bit mask is depends on the order that
> driver call the amdgpu_device_ip_block_add(), they are not fi
If it helps, my recollection was that Intel was also pushing some pre-silicon
support code upstream.
Agree that if the changes get big/messy/invasive we should rethink this, but my
impression is that the changes can be fairly small. There will be one Big
Honkin' function that programs ~10,000 r
On 2018-02-01 03:02 PM, Alex Deucher wrote:
> On Thu, Feb 1, 2018 at 2:44 PM, wrote:
>> From: Mikita Lipski
>>
>> Call dm_suspend function instead of drm_kms suspend function in
>> order to cache current state
>>
>> Call DM_resume first to restore dc hardware, then amdgpu_dm_display_resume
>>
Can you provide the example of which different block with the same type and why
we want to do that ?
With the old implementation , the bit mask is depends on the order that driver
call the amdgpu_device_ip_block_add(), they are not fixed . With this change
,at least developer can count out h
On Thu, Feb 1, 2018 at 7:39 PM, mikhail wrote:
> On Thu, 2018-02-01 at 18:34 +0100, Marek Olšák wrote:
>> On Thu, Feb 1, 2018 at 5:27 PM, mikhail > > wrote:
>> > On Tue, 2018-01-30 at 22:38 +0100, Marek Olšák wrote:
>> > > On Tue, Jan 30, 2018 at 10:36 PM, Marek Olšák
>> > > wrote:
>> > > > On Tu
On Thu, Feb 1, 2018 at 3:19 PM, Christian König
wrote:
> I don't think we should push any emulation specific code upstream.
>
> Nobody outside of AMD can test anything of that not actually make any use of
> it.
It makes it much easier to maintain the code however and debug things
on the emulator
I don't think we should push any emulation specific code upstream.
Nobody outside of AMD can test anything of that not actually make any
use of it.
Regards,
Christian.
Am 01.02.2018 um 21:15 schrieb Shaoyun Liu:
During emulation period, use the directly load for firmware also
only enable the
NAK, there might be different blocks with the same type and we want to
be able to disable/enable them individually.
But we could improve a bit printing which block has which number during
startup.
Regards,
Christian.
Am 01.02.2018 um 21:10 schrieb Shaoyun Liu:
Change-Id: I4bdc6dbcd82f32416f
There is no vbios post during emulation, use the common hw_init to
simulate the post
Change-Id: If363766cdd1d0dee9505c5b390732a35e6b80dee
Signed-off-by: Shaoyun Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff -
During emulation period, use the directly load for firmware also
only enable the GFX , SDMA and necessary common, gmc, ih IP block
Signed-off-by: Shaoyun Liu
Change-Id: I325910fa06be4060725f404e471cc79daaf343c3
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 10 +-
1 file changed, 9 inser
Change-Id: I4bdc6dbcd82f32416f65e0a38fb9c3cb580684bf
Signed-off-by: Shaoyun Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 21be5
Change-Id: I972b6d1e22434d01cdf819a528fc6360afc5a6bd
Signed-off-by: Shaoyun Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
index 915
On Thu, Feb 1, 2018 at 2:44 PM, wrote:
> From: Mikita Lipski
>
> Call dm_suspend function instead of drm_kms suspend function in
> order to cache current state
>
> Call DM_resume first to restore dc hardware, then amdgpu_dm_display_resume
> to restore dal's cached state.
We already call the IP
On Thu, Feb 1, 2018 at 2:44 PM, wrote:
> From: Mikita Lipski
>
> Call dm_suspend function instead of drm_kms suspend function in
> order to cache current state
>
> Call DM_resume first to restore dc hardware, then amdgpu_dm_display_resume
> to restore dal's cached state.
>
> Signed-off-by: Mikit
On 02/01/2018 02:44 PM, mikita.lip...@amd.com wrote:
From: Mikita Lipski
Call dm_suspend function instead of drm_kms suspend function in
order to cache current state
Call DM_resume first to restore dc hardware, then amdgpu_dm_display_resume
to restore dal's cached state.
Signed-off-by: Miki
From: Mikita Lipski
Call dm_suspend function instead of drm_kms suspend function in
order to cache current state
Call DM_resume first to restore dc hardware, then amdgpu_dm_display_resume
to restore dal's cached state.
Signed-off-by: Mikita Lipski
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.
On 01/02/18 01:54 PM, Deucher, Alexander wrote:
Does it also work properly with dc disabled? I suspect a bug somewhere
in the display info that dc generated when no displays are attached.
See smu7_program_display_gap().
Yup, with dc=0 the clock is correctly set.
I'll take a peak (tomorrow)
Does it also work properly with dc disabled? I suspect a bug somewhere in the
display info that dc generated when no displays are attached. See
smu7_program_display_gap().
Alex
From: StDenis, Tom
Sent: Thursday, February 1, 2018 1:43 PM
To: Deucher, Alexander;
On 01/02/18 01:36 PM, Deucher, Alexander wrote:
Are there any displays attached to the secondary card with the mclks
stuck high? If not, does attaching a display help?
Stealing the display from my primary (CZ in this case) does help, and
then putting it back the MCLK remains low.
Tom
Al
Are there any displays attached to the secondary card with the mclks stuck
high? If not, does attaching a display help?
Alex
From: amd-gfx on behalf of Tom St Denis
Sent: Thursday, February 1, 2018 1:14:43 PM
To: amd-gfx mailing list
Cc: Zhu, Rex
Subject: MC
Hi,
I have a setup with a CZ + Polaris10 and on the Polaris10 the SCLK idles
low and the MCLK stays in the 2nd state (1750MHz) but on my Workstation
which has a single 560 in it the card idles at 300MHz (with the stock
FC27 kernel).
Is there an issue with non-primary cards idling properly?
On Thu, Feb 1, 2018 at 5:27 PM, mikhail wrote:
> On Tue, 2018-01-30 at 22:38 +0100, Marek Olšák wrote:
>> On Tue, Jan 30, 2018 at 10:36 PM, Marek Olšák
>> wrote:
>> > On Tue, Jan 30, 2018 at 10:04 PM, mikhail > > .com> wrote:
>> > > On Tue, 2018-01-30 at 20:12 +0100, Marek Olšák wrote:
>> > > > C
On Tue, 2018-01-30 at 22:38 +0100, Marek Olšák wrote:
> On Tue, Jan 30, 2018 at 10:36 PM, Marek Olšák
> wrote:
> > On Tue, Jan 30, 2018 at 10:04 PM, mikhail > .com> wrote:
> > > On Tue, 2018-01-30 at 20:12 +0100, Marek Olšák wrote:
> > > > Can you record an apitrace on a driver that is not radeon
On Thu, Feb 1, 2018 at 12:08 AM, Harry Wentland wrote:
> On 2018-01-31 09:31 AM, Chris Chiu wrote:
>> Hi,
>> We are working with new laptops that have the AMD Ravenl Ridge
>> chipset with this `/proc/cpuinfo`
>> https://gist.github.com/mschiu77/b06dba574e89b9a30cf4c450eaec49bc
>>
>> With t
On 2018年02月01日 17:05, Christian König wrote:
With the addition of the mutex can I get your rb or ab for patch #3 as
well? Cause then it looks ready for commit.
Feel free to add my RB for that one.
Regards,
David Zhou
___
amd-gfx mailing list
amd-gfx
Am 01.02.2018 um 09:55 schrieb Chunming Zhou:
On 2018年02月01日 16:36, Christian König wrote:
reserved vmid is independent on id_mgr
And that is exactly the reason why I want to have that here.
If we don't fix this reserving a VMID would otherwise give the
process an unfair advantage while sch
On 2018年02月01日 16:36, Christian König wrote:
reserved vmid is independent on id_mgr
And that is exactly the reason why I want to have that here.
If we don't fix this reserving a VMID would otherwise give the process
an unfair advantage while scheduling jobs.
ok, I see your mean, that's same
Am 01.02.2018 um 06:44 schrieb Chunming Zhou:
On 2018年01月31日 23:47, Christian König wrote:
The variable is protected by the VMID mutex anyway.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 10 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ids.h | 2 +-
2 fi
reserved vmid is independent on id_mgr
And that is exactly the reason why I want to have that here.
If we don't fix this reserving a VMID would otherwise give the process
an unfair advantage while scheduling jobs.
Regards,
Christian.
Am 01.02.2018 um 05:42 schrieb Chunming Zhou:
NAK, reserve
48 matches
Mail list logo
