[+Philip]
On 2018-11-07 12:25 a.m., Zhang, Jerry(Junwei) wrote:
> On 11/7/18 1:15 PM, Trigger Huang wrote:
>> Currently, SDMA page queue is not used under SR-IOV VF, and this
>> queue will
>> cause ring test failure in amdgpu module reload case. So just disable
>> it.
>>
>> Signed-off-by: Trigger
Use the paging queue for buffer functions to avoid contention
with the other queues.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
From: David Francis
[Why]
DMCU firmware is not required - the system is expected to run
fine without it. Therefore, wherever dmcu functions could be
called, dmcu initialization shoudl be checked
[How]
Use the helpful hook dmcu_funcs->is_dmcu_initialized
Change-Id:
From: Murton Liu
[why]
Gamma was always being set as identity on SDR monitor,
leading to no changes in gamma. This caused nightlight to
not apply correctly.
[how]
Added a default gamma structure to compare against
in the sdr case.
Change-Id: I1d26459b94c341f248092c98e98684ced062565c
From: Nikola Cornij
[why]
The condition to check for two pixels per containter has become rather
long and is used in number of places.
[how]
Move the check to a helper function.
Change-Id: I02a32f72633d9e7fa1e6797f2e5b28a3a87f8ca3
Signed-off-by: Nikola Cornij
Reviewed-by: Eric Bernstein
Use page queue 0 rather than 1 to avoid contention with GPUVM
updates using page queue 0.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
[Why]
Many panels support more than 8bpc but some modes are unavailable while
running at greater than 8bpc due to DP/HDMI bandwidth constraints.
Support for more than 8bpc was added recently in the driver but it
defaults to the maximum supported bpc - locking out these modes.
This should be a
[Why]
Many panels support more than 8bpc but some modes are unavailable while
running at greater than 8bpc due to DP/HDMI bandwidth constraints.
Support for more than 8bpc was added recently in the driver but it
defaults to the maximum supported bpc - locking out these modes.
This should be a
From: David Francis
[Why]
dc_state has an array of dc_stream_status that contain
pointers to the dc_plane_state and other useful information
Confusingly, dc_stream_state also contains a dc_stream_status
called status. This struct was partially initialized and
used in a few places
[How]
From: Jun Lei
[why]
HUBP underflow is never cleared, which causes underflow in one
test to fail another test, violating the independence requirements
[how]
Rather than make clearing implicit, we explicitly clear underflow
status in DTN.
Change-Id: I52074dfca63e362c11a935308beb2a20bc2acce1
From: Nevenko Stupar
expose this functions for future use.
Change-Id: I67768f3940564b45db7d49079c8c95185a994925
Signed-off-by: Nevenko Stupar
Reviewed-by: Tony Cheng
Acked-by: Bhawanpreet Lakha
---
drivers/gpu/drm/amd/display/dc/dce/dce_clk_mgr.c | 2 +-
From: Dmytro Laktyushkin
Change the math to work in viewport rotation when calculating
viewport and viewport adjustment. This simplifies the math
for viewport calculation and makes viewport adjustment easier to
understand.
Change-Id: I23be05c3f1c77e994fa3767fed3628cc0c4a8bc1
Signed-off-by:
From: David Francis
[Why]
dc_link_set_backlight_level can be called from a context
where the stream is unknown. In this case, we can still
find which controller is driving this particular backlight
[How]
Compare links for equality instead of streams
Change-Id:
From: Dmytro Laktyushkin
A number of registers need to be updated for all active
pipes wherever any pipe causes a change in watermarks.
This change separates programming of these registers into
a separate function call that is called for all active pipes
during a bw update.
Change-Id:
From: Xiaodong Yan
DPCD Extended Receiver Capability Field
[Why]
1.dpcd extended receiver capability sometimes read fail,
and corrupted data leads to sink caps is not correct.
2.sometimes sink reply ack with fewer data
[How]
check the return value of core_link_read_dpcd,
try to read
From: Eric Bernstein
[Why]
For some complicated blending transition cases, the head
pipe of the second stream may end up being a higher pipe
index than the free pipe. In those cases dc_add_plane_to_context
will incorrectly set the tail_pipe to the free pipe, which
will cause the top_pipe and
From: Steven Chiu
Change-Id: I390073a04173c88b70db1e668ce70b7fdc97ac92
Signed-off-by: Steven Chiu
Reviewed-by: Tony Cheng
Acked-by: Bhawanpreet Lakha
---
drivers/gpu/drm/amd/display/dc/dc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Joshua Aberback
[Why]
We observed an issue where a display would not accept programming of
the ignore_MSA_timing_param bit if the stream was blanked.
[How]
move enable_stream_features from enable_link_dp to
core_link_enable_stream, after unblank_stream
Change-Id:
From: Jun Lei
[why]
Underflow is asserted due to some timing condition which does not
actually result in visible underflow (i.e. it occurs while blanked).
[how]
Force clear underflow occured bit whenver we unblank.
Change-Id: I80a3aa71fcf671b4e2059623842c31bc96e6ec12
Signed-off-by: Jun Lei
From: David Francis
[Why]
There was a full clock request struct of which only
one value was being used.
[How]
Replace the struct with a uint32_t
Change-Id: Ic38e74f29ad920c5fa8dd9736435d30f1e130c37
Signed-off-by: David Francis
Reviewed-by: Nicholas Kazlauskas
Reviewed-by: Sun peng Li
Summary of Changes
*fix hubp programming
*Redesign scaling rotation math
*various code cleanups
Charlene Liu (1):
drm/amd/display: expose surface confirm color function
David Francis (5):
drm/amd/display: Remove
From: Charlene Liu
expose dcn10_get_surface_visual_confirm_color() to be used in the
future
Change-Id: I71cbf4c051cd1f545cc144703e26505f742d9b0a
Signed-off-by: Charlene Liu
Reviewed-by: Dmytro Laktyushkin
Acked-by: Bhawanpreet Lakha
---
From: Steven Chiu
Change-Id: I4825c915ba5dc0043043437796b68573fefa1450
Signed-off-by: Steven Chiu
Reviewed-by: Tony Cheng
Acked-by: Bhawanpreet Lakha
---
drivers/gpu/drm/amd/display/dc/dc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Wenjing Liu
[Why]
dc_add_stream_to_context is used to check bw requirement.
It is not an error if it fails.
[How]
Replace DC_ERROR with DC_LOG_WARNING.
Change-Id: I6f32020d40bc36dcf41edceaad31331fbd8aaad3
Signed-off-by: Wenjing Liu
Reviewed-by: Jun Lei
Acked-by: Bhawanpreet Lakha
---
From: Yongqiang Sun
[Why]
Typo for return check value.
[How]
Correct one should be "return enable ? true : false;"
Change-Id: Idc045e1503b5f02b55e83a338ed8002713132774
Signed-off-by: Yongqiang Sun
Reviewed-by: Tony Cheng
Acked-by: Bhawanpreet Lakha
---
From: David Francis
[Why]
Unused variable "refresh" and incorrect comment formatting
[How]
Remove variable, reindent comments
Change-Id: I4ff57166184fcaed15ee5131c9df10d8860ff901
Signed-off-by: David Francis
Reviewed-by: Tony Cheng
Acked-by: Bhawanpreet Lakha
---
From: Yogesh Mohan Marimuthu
[why]
phy_pix_clk is one of the variable used to check if one PLL can be shared
with displays having common mode set configuration. As of now
phy_pix_clock varialbe is calculated in function dc_validate_stream().
dc_validate_stream() function is called after clocks
On 11/8/18 1:29 AM, Alex Deucher wrote:
Use page queue 0 rather than 1 to avoid contention with GPUVM
updates using page queue 0.
Signed-off-by: Alex Deucher
A little confuse, I thought we were going to use page queue(in any
instance) for PT update,
gfx ring for general sdma jobs.
Any
On 2018-11-07 12:53 p.m., Kuehling, Felix wrote:
> [+Philip]
>
> On 2018-11-07 12:25 a.m., Zhang, Jerry(Junwei) wrote:
>> On 11/7/18 1:15 PM, Trigger Huang wrote:
>>> Currently, SDMA page queue is not used under SR-IOV VF, and this
>>> queue will
>>> cause ring test failure in amdgpu module reload
On 11/8/18 1:29 AM, Alex Deucher wrote:
Use the paging queue for buffer functions to avoid contention
with the other queues.
Signed-off-by: Alex Deucher
Reviewed-by: Junwei Zhang
---
drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 12 +++-
1 file changed, 11 insertions(+), 1
Benjamin Herrenschmidt wrote:
> There's a whole pile of power management stuff for ancient laptops that
> never quite made it from radeonfb to the radeon DRM driver... sadly it
> also prevents sleep on old PowerBooks but I haven't had many complaints
> so...
Thanks for the confirmation that
Hi Dave,
Fixes for 4.20:
- DC MST fixes
- DC FBC fix
- Vega20 updates to support the latest vbios
- KFD type fixes for ioctl headers
The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a:
Linux 4.20-rc1 (2018-11-04 15:37:52 -0800)
are available in the git repository at:
On Wed, Nov 7, 2018 at 9:11 PM Zhang, Jerry(Junwei) wrote:
>
> On 11/8/18 1:29 AM, Alex Deucher wrote:
> > Use page queue 0 rather than 1 to avoid contention with GPUVM
> > updates using page queue 0.
> >
> > Signed-off-by: Alex Deucher
>
> A little confuse, I thought we were going to use page
On Wed, Nov 7, 2018 at 9:05 PM Zhang, Jerry(Junwei) wrote:
>
> On 11/8/18 1:29 AM, Alex Deucher wrote:
> > Use the paging queue for buffer functions to avoid contention
> > with the other queues.
> >
> > Signed-off-by: Alex Deucher
> Reviewed-by: Junwei Zhang
Can someone with a vega10 test
+ Curry
On 11/8/18 10:59 AM, Alex Deucher wrote:
On Wed, Nov 7, 2018 at 9:05 PM Zhang, Jerry(Junwei) wrote:
On 11/8/18 1:29 AM, Alex Deucher wrote:
Use the paging queue for buffer functions to avoid contention
with the other queues.
Signed-off-by: Alex Deucher
Reviewed-by: Junwei Zhang
Change-Id: I844949ae1738adae3dfad431a270913d04832f56
Signed-off-by: Jim Qu
---
.../drm/amd/powerplay/hwmgr/vega20_hwmgr.c| 135 ++
1 file changed, 45 insertions(+), 90 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
Hi Christian
Thanks for sharing,
Do you further know why we need recoverable page faults ? is it prepared for
PRT (or something like kernel page fault handling on CPU/MMU side)?
For SRIOV, in theoretically any feature*not* related with hardware scheduling
(MES) or OS preemption (buggy with
On 11/7/18 3:55 PM, Koenig, Christian wrote:
Am 07.11.18 um 08:41 schrieb Zhang, Jerry(Junwei):
On 11/7/18 3:29 PM, Koenig, Christian wrote:
Hi guys,
this is necessary for recoverable page fault handling.
When the normal SDMA queue is blocked because of a page fault the SDMA
firmware will
> is it prepared for PRT (or something like kernel page fault handling
> on CPU/MMU side)?
That is for providing shared virtual address space (e.g. when the CPU
and GPU have the same VA view) as well as changing our memory management
in general.
> For SRIOV, in theoretically any feature*not*
Yeah, we allow max up to 500ms to let RLCV finish the IDLE command for CP/GFX
and SDMA together, and this already introduce very poor user experience ...
Looks like this feature doesn't applicable for world switch case
/Monk
-Original Message-
From: Koenig, Christian
Sent: Wednesday,
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Jim Qu
Sent: Wednesday, November 7, 2018 5:42:12 AM
To: amd-gfx@lists.freedesktop.org
Cc: Qu, Jim
Subject: [PATCH] drm/amd/powerplay: correct code style
Change-Id: I844949ae1738adae3dfad431a270913d04832f56
1-877-336-1283 8051546
From: amd-gfx on behalf of Panariti,
David
Sent: Wednesday, November 7, 2018 9:59:42 AM
To: amd-gfx@lists.freedesktop.org
Subject: Same bridge number?
___
amd-gfx mailing list
On Tue, Nov 6, 2018 at 8:37 PM Evan Quan wrote:
>
> With UCLK DPM enabled, slow switching is not supported any more.
>
> Change-Id: I6242e782441272487aebd161836868785a6f7ee8
> Signed-off-by: Evan Quan
Reviewed-by: Alex Deucher
> ---
> .../drm/amd/powerplay/hwmgr/vega20_hwmgr.c| 37
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
On 11/7/18 9:57 AM, Wentland, Harry wrote:
>
>
> On 2018-11-06 3:24 p.m., Nicholas Kazlauskas wrote:
>> These include the drm_connector 'vrr_capable' and the drm_crtc
>> 'vrr_enabled' properties.
>>
>> Signed-off-by: Nicholas Kazlauskas
>> Cc: Harry Wentland
>> Cc: Manasi Navare
>> Cc: Pekka
On Tue, Nov 6, 2018 at 8:37 PM Evan Quan wrote:
>
> For Vega20, LBPW feature is disabled at default.
>
> Change-Id: I184520cbb03ab8cba9321cd94d1deb0ce38b7e17
> Signed-off-by: Evan Quan
> ---
> drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff
On Tue, Nov 6, 2018 at 8:42 PM Xu, Feifei wrote:
>
> Seriel is reviewed-by: Feifei Xu
>
> -Original Message-
> From: amd-gfx On Behalf Of Evan Quan
> Sent: Wednesday, November 7, 2018 9:38 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Quan, Evan
> Subject: [PATCH 1/3] drm/amd/powerplay:
[Why]
Many panels support more than 8bpc but some modes are unavailable while
running at greater than 8bpc due to DP/HDMI bandwidth constraints.
Support for more than 8bpc was added recently in the driver but it's
defaults to the maximum supported bpc - locking out these modes.
This should be a
[Why]
Many panels support more than 8bpc but some modes are unavailable while
running at greater than 8bpc due to DP/HDMI bandwidth constraints.
Support for more than 8bpc was added recently in the driver but it's
defaults to the maximum supported bpc - locking out these modes.
This should be a
On 2018-11-06 3:24 p.m., Nicholas Kazlauskas wrote:
> These include the drm_connector 'vrr_capable' and the drm_crtc
> 'vrr_enabled' properties.
>
> Signed-off-by: Nicholas Kazlauskas
> Cc: Harry Wentland
> Cc: Manasi Navare
> Cc: Pekka Paalanen
> Cc: Ville Syrjälä
> Cc: Michel Dänzer
>
On 2018-11-06 3:24 p.m., Nicholas Kazlauskas wrote:
> When variable refresh rate is active the hardware counter can return
> a position >= vtotal. This results in a vpos being returned from
> amdgpu_display_get_crtc_scanoutpos that's a positive value. The
> positive value indicates to the caller
On Wed, Nov 7, 2018 at 11:09 AM Kazlauskas, Nicholas
wrote:
>
> On 11/7/18 10:40 AM, Deucher, Alexander wrote:
> > FWIW there is a common property patch:
> >
> > https://patchwork.kernel.org/patch/10606697/
> >
> > When should try and be compatible so we can transition.
> >
> >
> > Alex
>
>
From: Leo Li
These two fields are used by DC, and their purposes are not immediately
clear.
Signed-off-by: Leo Li
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
On Wed, Nov 7, 2018 at 11:56 AM wrote:
>
> From: Leo Li
>
> These two fields are used by DC, and their purposes are not immediately
> clear.
>
> Signed-off-by: Leo Li
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 20
> 1 file changed, 20
FWIW there is a common property patch:
https://patchwork.kernel.org/patch/10606697/
When should try and be compatible so we can transition.
Alex
From: amd-gfx on behalf of Nicholas
Kazlauskas
Sent: Wednesday, November 7, 2018 9:56:54 AM
To:
On 2018-11-07 9:56 a.m., Nicholas Kazlauskas wrote:
> [Why]
> Many panels support more than 8bpc but some modes are unavailable while
> running at greater than 8bpc due to DP/HDMI bandwidth constraints.
>
> Support for more than 8bpc was added recently in the driver but it's
> defaults to the
On 2018-11-07 9:56 a.m., Nicholas Kazlauskas wrote:
> [Why]
> Many panels support more than 8bpc but some modes are unavailable while
> running at greater than 8bpc due to DP/HDMI bandwidth constraints.
>
> Support for more than 8bpc was added recently in the driver but it's
> defaults to the
On 11/7/18 10:40 AM, Deucher, Alexander wrote:
> FWIW there is a common property patch:
>
> https://patchwork.kernel.org/patch/10606697/
>
> When should try and be compatible so we can transition.
>
>
> Alex
Thanks for the heads up. I remember seeing the i915 patch but I missed
the common
58 matches
Mail list logo
