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

drm/amd/display: Add fast_validate parameter

2019-04-15T05:22:11+00:00

Add a fast_validate parameter in dc_validate_global_state for future use

Signed-off-by: Joshua Aberback 
Reviewed-by: Tony Cheng 
Acked-by: Bhawanpreet Lakha 
Signed-off-by: Alex Deucher

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: Fix multi-thread writing to 1 state

2019-04-03T16:57:07+00:00

[Why]
Multiple threads were writing back to one global VBA in DC resulting
in multiple threads overwriting eachother's data

[How]
Add an instance of DML (which contains VBA) to each context and
change all calls that used dc->dml to use context->dml. Created a
seperate copy constructor for linux in a case where there is no
access to DC.

Signed-off-by: Aidan Wood 
Reviewed-by: Jun Lei 
Acked-by: Bhawanpreet Lakha 
Signed-off-by: Alex Deucher

drm/amd/display: use dc_is_virtual instead of ENUM

2019-03-28T03:42:51+00:00

Signed-off-by: Eric Bernstein 
Reviewed-by: Dmytro Laktyushkin 
Reviewed-by: Nevenko Stupar 
Acked-by: Bhawanpreet Lakha 
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: remove sink reference in dc_stream_state

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

[why]
dc_stream_state containing a pointer to sink is poor design.
Sink describes the display, and the specifications or capabilities
it has.  That information is irrelevant for dc_stream_state, which describes
hardware state, and is generally used for hardware programming.  It
could further be argued that dc_sink itself is just a convenience dc
provides, and DC should be perfectly capable of programming hardware
without any dc_sinks (for example, emulated sinks).

[how]
Phase 1:
Deprecate use of dc_sink pointer in dc_stream.  Most references are trivial
to remove, but some call sites are risky (such as is_timing_changed) with
no obvious logical replacement.  These will be removed in follow up change.

Add dc_link pointer to dc_stream.  This is the typical reason DC really needed
sink pointer, and most call sites are replaced with this.

DMs also need minor updates, as all 3 DMs leverage stream->sink for
some functionality.  this is replaced instead by a pointer to private data
inside dc_stream_state, which is used by DMs as a quality of life improvment
for some key functionality.  it allows DMs to set pointers have to their own objects
which associate OS objects to dc_stream_states (such as DisplayTarget
and amdgpu_dm_connector).  Without the private pointer, DMs would be
forced to perform a lookup for callbacks.

Signed-off-by: Jun Lei 
Reviewed-by: Aric Cyr 
Acked-by: David Francis 
Acked-by: Leo Li 
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