linux-stable.git/drivers/gpu/drm/amd/display/dc/dce80, branch linux-5.2.y Linux kernel stable tree drm/amd/display: Add fast_validate parameter 2019-04-15T05:22:11+00:00 Joshua Aberback joshua.aberback@amd.com 2019-04-01T19:18:29+00:00 afcd526b1ba9dbc5707f9bd8d2d032ae62e337dc Add a fast_validate parameter in dc_validate_global_state for future use Signed-off-by: Joshua Aberback <joshua.aberback@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
Add a fast_validate parameter in dc_validate_global_state for future use

Signed-off-by: Joshua Aberback <joshua.aberback@amd.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: expand plane caps to include fp16 and scaling capability 2019-04-15T05:19:54+00:00 Jun Lei Jun.Lei@amd.com 2019-03-26T21:32:59+00:00 ea36ad34c5b2d6d2e079efc20fb0784e63dad438 [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 <Jun.Lei@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com> Acked-by: Harry Wentland <Harry.Wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
[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 <Jun.Lei@amd.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com>
Acked-by: Harry Wentland <Harry.Wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: Fix multi-thread writing to 1 state 2019-04-03T16:57:07+00:00 Aidan Wood Aidan.Wood@amd.com 2019-02-22T18:37:03+00:00 813d20dccf93f84f4c16236f7c037dc34db48f10 [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 <Aidan.Wood@amd.com> Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
[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 <Aidan.Wood@amd.com>
Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Merge branch 'drm-next-5.2' of git://people.freedesktop.org/~agd5f/linux into drm-next 2019-04-03T03:26:11+00:00 Dave Airlie airlied@redhat.com 2019-04-03T01:36:52+00:00 457109829f4ee4107e8c7108237afba21fabbb5e amdgpu: - Switch to HMM for userptr (reverted until HMM fixes land) - New experimental SMU 11 replacement for powerplay for vega20 (not enabled by default) - Initial RAS support for vega20 - BACO support for vega12 - BACO fixes for vega20 - Rework IH handling for page fault and retry interrupts - Cleanly split CPU and GPU paths for GPUVM updates - Powerplay fixes - XGMI fixes - Rework how DC interacts with atomic for planes - Clean up and simplify DC/Powerplay interfaces - Misc cleanups and bug fixes amdkfd: - Switch to HMM for userptr (reverted until HMM fixes land) - Add initial RAS support - MQD fixes ttm: - Unify DRM_FILE_PAGE_OFFSET handling - Account for kernel allocations in kernel zone only - Misc cleanups Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190402170820.22197-1-alexander.deucher@amd.com 
amdgpu:
- Switch to HMM for userptr (reverted until HMM fixes land)
- New experimental SMU 11 replacement for powerplay for vega20 (not enabled by default)
- Initial RAS support for vega20
- BACO support for vega12
- BACO fixes for vega20
- Rework IH handling for page fault and retry interrupts
- Cleanly split CPU and GPU paths for GPUVM updates
- Powerplay fixes
- XGMI fixes
- Rework how DC interacts with atomic for planes
- Clean up and simplify DC/Powerplay interfaces
- Misc cleanups and bug fixes

amdkfd:
- Switch to HMM for userptr (reverted until HMM fixes land)
- Add initial RAS support
- MQD fixes

ttm:
- Unify DRM_FILE_PAGE_OFFSET handling
- Account for kernel allocations in kernel zone only
- Misc cleanups

Signed-off-by: Dave Airlie <airlied@redhat.com>

From: Alex Deucher <alexdeucher@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190402170820.22197-1-alexander.deucher@amd.com
drm/amd/display: Add plane capabilities to dc_caps 2019-03-19T20:04:03+00:00 Nicholas Kazlauskas nicholas.kazlauskas@amd.com 2019-02-05T17:50:01+00:00 e5c419709097e77e7f14a751591ea05f04cf5570 [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 <nicholas.kazlauskas@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
[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 <nicholas.kazlauskas@amd.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Merge v5.0 into drm-next 2019-03-04T02:02:55+00:00 Dave Airlie airlied@redhat.com 2019-03-04T02:02:55+00:00 2c3cd66f4c66b169c18a2dbebbc894681d282278 There is a really hairy resolution involving amdgpu fixes, that I'd rather confirm here. Also some misc fixes are landed by me, but the pr has them as well. Signed-off-by: Dave Airlie <airlied@redhat.com> 
There is a really hairy resolution involving amdgpu fixes, that I'd rather confirm here.

Also some misc fixes are landed by me, but the pr has them as well.

Signed-off-by: Dave Airlie <airlied@redhat.com>
drm/amd/display: set clocks to 0 on suspend on dce80 2019-02-20T21:58:06+00:00 Bhawanpreet Lakha Bhawanpreet.Lakha@amd.com 2019-02-05T19:03:52+00:00 4ece61a22be5ab5d49cc5fc20a19a0afa24a019d [Why] When a dce80 asic was suspended, the clocks were not set to 0. Upon resume, the new clock was compared to the existing clock, they were found to be the same, and so the clock was not set. This resulted in a blackscreen. [How] In atomic commit, check to see if there are any active pipes. If no, set clocks to 0 Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org 
[Why]
When a dce80 asic was suspended, the clocks were not set to 0.
Upon resume, the new clock was compared to the existing clock,
they were found to be the same, and so the clock was not set.
This resulted in a blackscreen.

[How]
In atomic commit, check to see if there are any active pipes.
If no, set clocks to 0

Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
drm/amd/display: fix optimize_bandwidth func pointer for dce80 2019-02-20T21:57:47+00:00 Bhawanpreet Lakha Bhawanpreet.Lakha@amd.com 2019-02-05T18:55:20+00:00 9f7ddbea2bb826a2147309f735726a8b09950944 [Why] optimize_bandwidth was using dce100_prepare_bandwidth this is incorrect [How] change it to dce100_optimize_bandwidth Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Reviewed-by: Charlene Liu <Charlene.Liu@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org 
[Why]
optimize_bandwidth was using dce100_prepare_bandwidth this is incorrect

[How]
change it to dce100_optimize_bandwidth

Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Charlene Liu <Charlene.Liu@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
drm/amd/display: fix eDP fast bootup for pre-raven asic 2019-01-25T21:15:36+00:00 hersen wu hersenxs.wu@amd.com 2019-01-11T15:39:30+00:00 c69dffab819f5abd98f9791fdb8aede1ec2f172f [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 <hersenxs.wu@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Charlene Liu <Charlene.Liu@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Acked-by: Yongqiang Sun <yongqiang.sun@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
[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 <hersenxs.wu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Charlene Liu <Charlene.Liu@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Acked-by: Yongqiang Sun <yongqiang.sun@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: Change from aux_engine to dce_aux 2019-01-14T20:40:48+00:00 David Francis David.Francis@amd.com 2018-11-30T15:32:01+00:00 1877ccf6eea42993c4ca0d5e6876ced8b5b4ee8a [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 <David.Francis@amd.com> Reviewed-by: Harry Wentland <Harry.Wentland@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
[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 <David.Francis@amd.com>
Reviewed-by: Harry Wentland <Harry.Wentland@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>