linux.git/drivers/gpu/drm/amd/display/dc/dce120, branch v5.2

drm/amd/display: expand plane caps to include fp16 and scaling capability

2019-04-15T05:19:54+00:00

[why]
there are some scaling capabilities such as fp16 which are known to be unsupported
on a given ASIC.  exposing these static capabilities allows much simpler implementation
for OS interfaces which require to report such static capabilities to reduce the
number of dynamic validation calls

[how]
refactor the existing plane caps to be more extensible, and add fp16 and scaling
capabilities

Signed-off-by: Jun Lei 
Reviewed-by: Tony Cheng 
Acked-by: Bhawanpreet Lakha 
Acked-by: Harry Wentland 
Signed-off-by: Alex Deucher

drm/amd/display: Add plane capabilities to dc_caps

2019-03-19T20:04:03+00:00

[Why]
The current dc_caps doesn't provide the information needed to
determine the count and type of each plane to be exposed to userspace.

There are three types of DRM planes that are exposed to userspace:

1. Primary planes (can be used for modesetting)
2. Overlay planes (can be blended below or above a primary plane)
3. Cursor planes (blended topmost)

We need to know the number and type of each in amdgpu_dm to expose
to userspace.

Hardware supports blending planes below, above or both ways depending
on the ASIC. Alpha support is also ASIC dependent. Some hardware has
dedicated pipes for overlays and other hardware combines the pipes.

All of this should be exposed in a way that DM can query and use.

[How]
Introduce the dc_plane_cap structure that describes the capabilities
for the hw planes.

It describes:
- the type of the plane
- whether the plane can blend with planes below it
- whether the plane can blend with planes above it
- whether the plane supports per pixel alpha blending
- supported formats on the plane (partial list for now)

Pre DCN ASICs don't have their full capabilities described for now.
They can be updated as needed in the future.

Signed-off-by: Nicholas Kazlauskas 
Reviewed-by: Tony Cheng 
Acked-by: Bhawanpreet Lakha 
Signed-off-by: Alex Deucher

drm/amd/display: fix eDP fast bootup for pre-raven asic

2019-01-25T21:15:36+00:00

[Why]
For fastboot, Bios will light up eDP before SW driver is loaded. SW
driver will check if eDP is lit by bios through reading the
BIOS_SCRATCH_3 register. If lit, SW driver will not power down eDP
power and phy to save time.

Definition of BIOS_SCRATCH_3 are missing for pre-raven asic. This
causes eDP fast boot to not work property. For some eDP panels, even
if dp tx sends NoVideoStream_flag =1 and dpcd 0x600=2, eDP rx may not
handle properly. This may cause a short flash on screen.

[How] Add definition of BIOS_SCRATCH_3 for all asic

Signed-off-by: hersen wu 
Reviewed-by: Alex Deucher 
Reviewed-by: Charlene Liu 
Acked-by: Leo Li 
Acked-by: Yongqiang Sun 
Signed-off-by: Alex Deucher

drm/amd/display: Change from aux_engine to dce_aux

2019-01-14T20:40:48+00:00

[Why]
The aux_engine struct is needlessly complex and
is defined multiple times.  It contains function pointers
that each have only one version and are called only from
inside dce_aux.

[How]
Replace aux_engine with a new struct called dce_aux.
Remove all function pointers and call functions directly.
Remove unused functions

Signed-off-by: David Francis 
Reviewed-by: Harry Wentland 
Acked-by: Leo Li 
Signed-off-by: Alex Deucher

drm/amd/display: Compensate for XGMI SS downspread on dprefclk

2019-01-14T20:04:41+00:00

[Why]
When XGMI is enabled, we need to adjust the dprefclk according to the
WAFL link's spread spectrum info. This is for VG20 (DCE121) only.

[How]
dce_clk_mgr already stores SS info, currently being used by audio clock.
Therefore, patch the clk_mgr's SS info with the xGMI SS info, if xGMI
is enabled. For display clock, adjust it during dce12_update_clocks()
before calling set_clock().

Since we rely on a mmhub register to reliably determine if xGMI is
enabled, the patching step needs to happen after resource_construct()
has initialized the hardware sequencer.

Signed-off-by: Leo Li 
Reviewed-by: Hersen Wu 
Acked-by: Harry Wentland 
Signed-off-by: Alex Deucher

drm/amd/display: rename dccg to clk_mgr

2018-11-05T19:20:48+00:00

In preparation for adding the actual dccg block since the
current implementation of dccg is mor eof a clock manager
than a hw block

Signed-off-by: Dmytro Laktyushkin 
Reviewed-by: Charlene Liu 
Acked-by: Bhawanpreet Lakha 
Signed-off-by: Alex Deucher

drm/amd/display: Add link encoder dp_ycbcr420_supported feature flag

2018-11-05T19:20:46+00:00

[Why]
Need separate feature flag for DP 4:2:0 support, since existing
flag is used for HDMI

[How]
Added dp_ycbcr420_supported to struct encoder_feature_support

Signed-off-by: Eric Bernstein 
Reviewed-by: Tony Cheng 
Acked-by: Bhawanpreet Lakha 
Signed-off-by: Alex Deucher

drm/amd/display: split dccg clock manager into asic folders

2018-11-05T19:20:42+00:00

Currently dccg contains code related to every dcn revision in
a single file.

This change splits out the dcn parts of code into correct folders

Signed-off-by: Dmytro Laktyushkin 
Reviewed-by: Charlene Liu 
Acked-by: Bhawanpreet Lakha 
Signed-off-by: Alex Deucher

drm/amd/display: move pplib/smu notification to dccg block

2018-11-05T19:20:40+00:00

This is done to clear up the clock programming sequence
since the only time we need to notify pplib is after
clock update.

This also renames the clk block to dccg, at the moment
this block contains both clock management and dccg
functionality.

Signed-off-by: Dmytro Laktyushkin 
Reviewed-by: Tony Cheng 
Acked-by: Bhawanpreet Lakha 
Signed-off-by: Alex Deucher

drm/amd/display: fix memory leak in resource pools

2018-10-09T22:03:31+00:00

[why]
ddc engines were recently changed to be independently tracked
from pipe count.  the change was reflected in resource constructor
but not in destructor.  this manifests as a memory leak when
pipe harvesting is enabled, since not all constructed ddc engines
are freed

[how]
make destructor symmetric with constructor for all dcX_resource

Signed-off-by: Jun Lei 
Reviewed-by: Aric Cyr 
Acked-by: Leo Li 
Signed-off-by: Alex Deucher