On 2018-03-26 10:00 PM, sunpeng...@amd.com wrote:
> From: "Leo (Sunpeng) Li"
>
> This change adds a few functions in preparation of enabling CRTC color
> managment via the randr interface.
>
> The driver-private CRTC object now contains a list of properties,
> mirroring the
On 2018-03-26 10:00 PM, sunpeng...@amd.com wrote:
> From: "Leo (Sunpeng) Li"
>
> Copy code from output_create_resources, insert into configure &
> change helper, and rename variables. Some formatting changes as well.
> Modify doc-string to reflect change.
>
> Signed-off-by:
On 2018-03-26 10:00 PM, sunpeng...@amd.com wrote:
> From: "Leo (Sunpeng) Li"
>
> In cases where CRTC properties are updated without going through
> RRChangeOutputProperty, we don't update the properties in user land.
>
> Consider setting legacy gamma. It doesn't go through
>
On Mon, Apr 9, 2018 at 3:47 AM, Michel Dänzer wrote:
> On 2018-04-06 09:54 PM, Alex Deucher wrote:
>> Steal 9 MB for vga emulation and fb if vga is enabled, otherwise,
>> steal enough to cover the current display size as set by the vbios.
>>
>> If no memory is used (e.g.,
This commit
commit 5fadc6fe773862f59f8a54480f06f097f0719c26
Author: Bhawanpreet Lakha
Date: Thu Mar 15 13:01:46 2018 -0400
drm/amd/display: Add Dynamic debug prints
Created Macros for DC_LOG_XXX to pr_debug() & DRM_DEBUG_KMS.
Signed-off-by:
On 2018-03-26 10:00 PM, sunpeng...@amd.com wrote:
> From: "Leo (Sunpeng) Li"
>
> The functions insert into the output resource creation, and property
> change functions. CRTC destroy is also hooked-up for proper cleanup of
> the CRTC property list.
>
> Signed-off-by: Leo
Christian,
Thanks for the response. That got me in the right direction.
After trial and error I found the cause - Thunderbolt Boot Support option
must be disabled in BIOS.
If I disable it I can boot to Ubuntu and looks like amdgpu inits okay. If I
enable with no other changes, init fails.
The
OK, tested with DC disabled , no issues on resume (no visible corruption
on display or errors in log). Now the display itself freezes after
amdgpu is loaded with DC disabled, this happens only when BIOS in VGA
mode , in console mode no such problem. Happens before my and Alex
patches, looks
On 2018-04-09 01:36 PM, Tom St Denis wrote:
This commit
commit 5fadc6fe773862f59f8a54480f06f097f0719c26
Author: Bhawanpreet Lakha
Date: Thu Mar 15 13:01:46 2018 -0400
drm/amd/display: Add Dynamic debug prints
Created Macros for DC_LOG_XXX to pr_debug()
On Mon, Apr 9, 2018 at 2:37 PM, Harry Wentland wrote:
> We enabled this upstream by default now and no longer need the flag.
>
> Signed-off-by: Harry Wentland
Reviewed-by: Alex Deucher
> ---
>
On 2018-04-09 01:48 PM, Leo Li wrote:
>
> On 2018-04-09 01:36 PM, Tom St Denis wrote:
>> This commit
>>
>> commit 5fadc6fe773862f59f8a54480f06f097f0719c26
>> Author: Bhawanpreet Lakha
>> Date: Thu Mar 15 13:01:46 2018 -0400
>>
>> drm/amd/display: Add Dynamic
Tested-by: Tom St Denis
Works for me!
Thanks,
Tom
On 04/09/2018 02:06 PM, Harry Wentland wrote:
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/amd/display/include/logger_types.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
We enabled this upstream by default now and no longer need the flag.
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 ---
drivers/gpu/drm/amd/display/Kconfig| 8
2 files changed, 11 deletions(-)
diff --git
=== What is adaptive sync and VRR? ===
Adaptive sync has been part of the DisplayPort spec for a while now and allows
graphics adapters to drive displays with varying frame timings. VRR (variable
refresh rate) is essentially the same, but defined for HDMI.
=== Why allow variable frame
Adding dri-devel, which I should've included from the start.
On 2018-04-09 03:56 PM, Harry Wentland wrote:
> === What is adaptive sync and VRR? ===
>
> Adaptive sync has been part of the DisplayPort spec for a while now and
> allows graphics adapters to drive displays with varying frame
On Sat, Apr 7, 2018 at 11:13 AM, Nico Sneck wrote:
> With this the dGPU turns on correctly.
>
> Signed-off-by: Nico Sneck
Applied. Thanks!
Alex
> ---
> drivers/gpu/drm/radeon/radeon_device.c | 4
> 1 file changed, 4 insertions(+)
>
> diff
There's an ongoing effort to remove VLAs[1] from the kernel to eventually
turn on -Wvla. The single VLA usage in the amdkfd driver is actually
constant across all current platforms. Switch to a constant size array
instead.
[1] https://lkml.org/lkml/2018/3/7/621
Signed-off-by: Laura Abbott
Thanks for initiating the discussion. Find my comments below:
On Mon, Apr 09, 2018 at 04:00:21PM -0400, Harry Wentland wrote:
> Adding dri-devel, which I should've included from the start.
>
> On 2018-04-09 03:56 PM, Harry Wentland wrote:
> > === What is adaptive sync and VRR? ===
> >
> >
On 2018年04月09日 18:18, Christian König wrote:
Instead of the global (inaccurate) counter.
Signed-off-by: Christian König
Reviewed-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 10 +++---
1 file changed, 3
On 2018年04月09日 18:18, Christian König wrote:
The detection if a BO was placed in CPU visible VRAM was incorrect.
Fix it and merge it with the correct detection in amdgpu_ttm.c
Signed-off-by: Christian König
Reviewed-by: Chunming Zhou
---
On 2018年04月09日 18:19, Christian König wrote:
That should purely be handled by preferred/allowed domains.
Although this flag isn't exported to user space yet, I'm curious that
how preferred/allowed domains handle no_fallback?
IIRC, currently, our driver will always add GTT fallback for VRAM
Change-Id: I21e6f2bda6c95381fd96f76d23a70f1089b40007
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 ++
drivers/gpu/drm/amd/amdgpu/vega10_reg_init.c | 3 ++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git
pp_soc15.h is vega10 specific. Update powerplay code to use soc15 common
macros defined in soc15_common.h.
Change-Id: I43c9a89e1a1f5d9a031465e2c2ba1525486aba9a
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c | 7 +-
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/amd/display/include/logger_types.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/include/logger_types.h
b/drivers/gpu/drm/amd/display/include/logger_types.h
index
Change-Id: Ie9a684d018f9ed43e3baadc6ba2c7525da97d659
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 13 -
drivers/gpu/drm/amd/powerplay/inc/vega10_ppsmc.h | 1 +
2 files changed, 5 insertions(+), 9 deletions(-)
diff --git
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 84 +++---
1 file changed, 41 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c| 4
drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 4
drivers/gpu/drm/amd/powerplay/inc/hwmgr.h | 2 ++
drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c
is_blanked() hook is a dummy one for underlay pipe, hence
when called, it loops for ~300ms at boot.
This patch removes this dummy call and adds missing checks.
Signed-off-by: Shirish S
Reviewed-by: Harry Wentland
---
You can add descriptions like:
fix bug read wrong engine clock when in deep sleep.
Reviewed-by: Rex Zhu
Best Regards
Rex
From: amd-gfx on behalf of Evan Quan
Sent: Tuesday,
The detection if a BO was placed in CPU visible VRAM was incorrect.
Fix it and merge it with the correct detection in amdgpu_ttm.c
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 6 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h |
That should purely be handled by preferred/allowed domains.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
Instead of the global (inaccurate) counter.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
Looks like for some reason this patch did not end up on amd-gfx.
Is that problematic? Or is this trivial enough not to need ending up there?
With this the dGPU turns on correctly.
Signed-off-by: Nico Sneck
---
Hi All ,
Sometimes it happens Oops in linux kernel 4.16.0 AMDGPU driver, and it
nerver happen in 4.15 kernel.
Software environment:Ubuntu17.10 + newest stable kernel 4.16.0 + mesa v17.2.8
GPU: Radeon Pro WX5100 CPU: arm64
Here is the calltrace:
.
Apr 8 14:56:01 ubuntu kernel:
With this the dGPU turns on correctly.
Signed-off-by: Nico Sneck
---
drivers/gpu/drm/radeon/radeon_device.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index 90e17e2..59c8a66
On Fri, Apr 06, 2018 at 02:54:09PM -0500, Alex Deucher wrote:
> Steal 9 MB for vga emulation and fb if vga is enabled, otherwise,
> steal enough to cover the current display size as set by the vbios.
>
> If no memory is used (e.g., secondary or headless card), skip
> stolen memory reserve.
>
>
On 2018-04-06 09:54 PM, Alex Deucher wrote:
> Steal 9 MB for vga emulation and fb if vga is enabled, otherwise,
> steal enough to cover the current display size as set by the vbios.
>
> If no memory is used (e.g., secondary or headless card), skip
> stolen memory reserve.
>
> v2: skip
Please provide the full dmesg of the system as well as the output of
"lspci -s :16:00.0 -" as attachment.
Thanks,
Christian.
Am 09.04.2018 um 06:00 schrieb Andrey Grodzovsky:
Just from a quick look it seems to fail in amdgpu_device_init->ioremap
with ENOMEM, that would explain why
v2: not always sleep 20 ms to read back the power value.
just delay 1 ms, and check the return value.
Do not check whether the smu message was supported by firmware.
send the message with parameter 0. if the return value not changed,
we use another way to read power.
There is no impact if
We don't need to check the alignment of the offset and there was
potential a buffer overflow as well.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git
On 2018-04-09 12:18 PM, Christian König wrote:
> The detection if a BO was placed in CPU visible VRAM was incorrect.
>
> Fix it and merge it with the correct detection in amdgpu_ttm.c
>
> Signed-off-by: Christian König
Good catch! All three patches are
Reviewed-by:
If trap_en and priv are set in the SQ_WAVE_STATUS
then read 12 or 16 words from 0x6C (SQ_WAVE_TTMP0...)
and display inline with rest of SGPRs.
Signed-off-by: Tom St Denis
---
src/app/print_waves.c | 33 ++---
src/lib/read_gpr.c| 16
Hi Leo,
apologies for the late follow-up; I was on vacation and then backlogged.
On 2018-03-26 10:00 PM, sunpeng...@amd.com wrote:
> From: "Leo (Sunpeng) Li"
>
> These patches will enable modification of non-legacy color management
> properties via xrandr.
>
> On top of
Top posting (mobile)
I tested S3 with DC enabled only. Even if I disable DC I need a device with
less then 8M VRAM to reproduce it, don't I ? Otherwise we just gonna reserve
pre OS FB size of VRAM and not corrupt it. Right ? Should probably test it with
forcing VRAM size to less then 8M...
Hi Daniel,
your problem is that the system BIOS is buggy and doesn't assign
resources to the card:
Region 0: Memory at (64-bit, prefetchable)
Region 2: Memory at (64-bit, prefetchable)
Region 4: I/O ports at 9000 [size=256]
Region 5: Memory at (32-bit, non-prefetchable)
Hi Andrey,
I think the problem Ray wants to point to is that we now release the
stolen memory after device initialization.
So during S3 we might run into issues because the first 8MB of VRAM are
corrupted after startup.
Christian.
Am 09.04.2018 um 15:26 schrieb Grodzovsky, Andrey:
Top
46 matches
Mail list logo