History log of /linux-master/drivers/gpu/drm/amd/display/dc/os_types.h
Revision Date Author Comments
# 5d72e247 20-Sep-2023 Hamza Mahfooz <hamza.mahfooz@amd.com>

drm/amd/display: switch DC over to the new DRM logging macros

For multi-GPU systems it is difficult to tell which GPU a particular
message is being printed for and that is undesirable because it
complicates debugging efforts. Also, the new macros allow us to enable
logging for particular parts of the codebase more selectively (since we
no longer need to throw everything at DRM_DEBUG_KMS()). So, for the
reasons outlined above we should switch to the new macros.

We can accomplish this by using the existing DC_LOGGER code to pass
around the relevant `struct drm_device` which will be fed to the new
macros in logger_types.h. Also, we must get rid of all instances of the
DC_LOG_.*() functions that are currently in amdgpu_dm since we don't use
the DC logger there and we can simply refer to the macros directly
there instead.

Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>


# 4652ae7a 14-Feb-2023 Harry Wentland <harry.wentland@amd.com>

drm/amd/display: Rename DCN config to FP

[Why & How]
The only reason we have the DCN config is for
floating point support. Rename it to make that
clear and (hopefully) avoid misuse of the config
in the future.

Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com>
Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>


# 75072128 06-Jul-2022 Guo Zhengkui <guozhengkui@vivo.com>

drm/amd/display: remove repeated includes

Remove a repeated "#include <drm/drm_print.h>"

Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Guo Zhengkui <guozhengkui@vivo.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>


# 09de5cd2 22-Nov-2019 Harry Wentland <harry.wentland@amd.com>

drm/amd/display: Move all linux includes into OS types

Move all linux includes into OS types.

Acked-by: Alan Liu <HaoPing.Liu@amd.com>
Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>


# da68386d 21-Apr-2022 Thomas Zimmermann <tzimmermann@suse.de>

drm: Rename dp/ to display/

Rename dp/ to display/ to account for additional display-related
helpers, such as HDMI. Update all related include statements. No
functional changes.

Various drivers, such as i915 and amdgpu, use similar naming scheme
by putting code for video-output standards into a local display/
directory. The new directory's name is aligned with this convention.

v2:
* update commit message (Javier)

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220421073108.19226-3-tzimmermann@suse.de


# 5b529e8d 13-Jan-2022 Thomas Zimmermann <tzimmermann@suse.de>

drm/dp: Move public DisplayPort headers into dp/

Move all public DisplayPort headers into dp/ and update users. No
functional changes.

v3:
* rebased onto latest drm-tip

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Daniel Vetter <daniel@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20220114114535.29157-5-tzimmermann@suse.de


# 178fbb6d 09-Apr-2021 Jimmy Kizito <Jimmy.Kizito@amd.com>

drm/amd/display: Implement DPIA training loop

[Why]
Training of DPIA link differs enough from that of conventional
DP link to warrant a separate implementation.

[How]
- Implement top-level of DPIA training loop.
- Make functions shared between DP and DPIA link training "public".

Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Acked-by: Wayne Lin <Wayne.Lin@amd.com>
Acked-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Jimmy Kizito <Jimmy.Kizito@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>


# 6131538b 22-Sep-2021 Harry Wentland <harry.wentland@amd.com>

drm/amd/display: Only define DP 2.0 symbols if not already defined

[Why]
For some reason we're defining DP 2.0 definitions inside our
driver. Now that patches to introduce relevant definitions
are slated to be merged into drm-next this is causing conflicts.

In file included from drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c:33:
In file included from ./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu.h:70:
In file included from ./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu_mode.h:36:
./include/drm/drm_dp_helper.h:1322:9: error: 'DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER' macro redefined [-Werror,-Wmacro-redefined]
^
./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: note: previous definition is here
^
1 error generated.

[How]
Guard all display driver defines with #ifndef for now. Once we pull
in the new definitions into amd-staging-drm-next we will follow
up and drop definitions from our driver and provide follow-up
header updates for any addition DP 2.0 definitions required
by our driver.

We also ensure drm_dp_helper.h is included before dc_dp_types.h.

v3: Ensure drm_dp_helper.h is included before dc_dp_types.h

v2: Add one missing endif

Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Fangzhi Zuo <Jerry.Zuo@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>


# 96ee6373 26-Jul-2021 Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>

drm/amd/display: Add control mechanism for FPU

DC invokes DC_FPU_START/END in multiple parts of the code; this can
create a situation where we invoke this FPU operation in a nested way or
exit too early. For avoiding this situation, this commit adds a
mechanism where dc_fpu_begin/end manages the access to
kernel_fpu_begin/end.

Change since V3:
- Christian: Move PPC64 code to dc_fpu_begin/end.

Change since V2:
- Christian: Do not use this_cpu_* between get/put_cpu_ptr().

Change since V1:
- Use a better variable names
- Use get_cpu_ptr and put_cpu_ptr to better balance preemption enable
and disable

Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Anson Jacob <Anson.Jacob@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Hersen Wu <hersenxs.wu@amd.com>
Cc: Aric Cyr <aric.cyr@amd.com>
Cc: Jun Lei <jun.lei@amd.com>
Cc: Dmytro Laktyushkin <dmytro.laktyushkin@amd.com>
Cc: Qingqing Zhuo <qingqing.zhuo@amd.com>
Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>


# 88d5cb25 04-Jan-2021 Alex Deucher <alexander.deucher@amd.com>

drm/amdgpu/display: drop DCN support for aarch64

From Ard:

"Simply disabling -mgeneral-regs-only left and right is risky, given that
the standard AArch64 ABI permits the use of FP/SIMD registers anywhere,
and GCC is known to use SIMD registers for spilling, and may invent
other uses of the FP/SIMD register file that have nothing to do with the
floating point code in question. Note that putting kernel_neon_begin()
and kernel_neon_end() around the code that does use FP is not sufficient
here, the problem is in all the other code that may be emitted with
references to SIMD registers in it.

So the only way to do this properly is to put all floating point code in
a separate compilation unit, and only compile that unit with
-mgeneral-regs-only."

Disable support until the code can be properly refactored to support this
properly on aarch64.

Acked-by: Will Deacon <will@kernel.org>
Reported-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>


# c241ed2f 04-Jan-2021 Alex Deucher <alexander.deucher@amd.com>

drm/amdgpu/display: drop DCN support for aarch64

From Ard:

"Simply disabling -mgeneral-regs-only left and right is risky, given that
the standard AArch64 ABI permits the use of FP/SIMD registers anywhere,
and GCC is known to use SIMD registers for spilling, and may invent
other uses of the FP/SIMD register file that have nothing to do with the
floating point code in question. Note that putting kernel_neon_begin()
and kernel_neon_end() around the code that does use FP is not sufficient
here, the problem is in all the other code that may be emitted with
references to SIMD registers in it.

So the only way to do this properly is to put all floating point code in
a separate compilation unit, and only compile that unit with
-mgeneral-regs-only."

Disable support until the code can be properly refactored to support this
properly on aarch64.

Acked-by: Will Deacon <will@kernel.org>
Reported-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>


# bcc3775d 23-Oct-2020 Takashi Iwai <tiwai@suse.de>

drm/amd/display: Clean up debug macros

This patch simplifies the ASSERT*() and BREAK_TO_DEBUGGER() macros:
- Move the dependency check of CONFIG_KGDB into Kconfig
- Unify the kgdb_breakpoint() call
- Drop the non-existing CONFIG_HAVE_KGDB

Also align the behavior of ASSERT() macro in both cases with and
without CONFIG_DEBUG_KERNEL_DC.

Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>


# 8b7dc1fe 23-Oct-2020 Takashi Iwai <tiwai@suse.de>

drm/amd/display: Don't invoke kgdb_breakpoint() unconditionally

ASSERT_CRITICAL() invokes kgdb_breakpoint() whenever either
CONFIG_KGDB or CONFIG_HAVE_KGDB is set. This, however, may lead to a
kernel panic when no kdb stuff is attached, since the
kgdb_breakpoint() call issues INT3. It's nothing but a surprise for
normal end-users.

For avoiding the pitfall, make the kgdb_breakpoint() call only when
CONFIG_DEBUG_KERNEL_DC is set.

https://bugzilla.opensuse.org/show_bug.cgi?id=1177973
Cc: <stable@vger.kernel.org>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>


# c5ff0c19 23-Oct-2020 Takashi Iwai <tiwai@suse.de>

drm/amd/display: Clean up debug macros

This patch simplifies the ASSERT*() and BREAK_TO_DEBUGGER() macros:
- Move the dependency check of CONFIG_KGDB into Kconfig
- Unify the kgdb_breakpoint() call
- Drop the non-existing CONFIG_HAVE_KGDB

Also align the behavior of ASSERT() macro in both cases with and
without CONFIG_DEBUG_KERNEL_DC.

Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>


# 0ca34182 23-Oct-2020 Takashi Iwai <tiwai@suse.de>

drm/amd/display: Don't invoke kgdb_breakpoint() unconditionally

ASSERT_CRITICAL() invokes kgdb_breakpoint() whenever either
CONFIG_KGDB or CONFIG_HAVE_KGDB is set. This, however, may lead to a
kernel panic when no kdb stuff is attached, since the
kgdb_breakpoint() call issues INT3. It's nothing but a surprise for
normal end-users.

For avoiding the pitfall, make the kgdb_breakpoint() call only when
CONFIG_DEBUG_KERNEL_DC is set.

https://bugzilla.opensuse.org/show_bug.cgi?id=1177973
Cc: <stable@vger.kernel.org>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>


# c38d444e 08-Aug-2020 Daniel Kolesa <daniel@octaforge.org>

drm/amd/display: add DCN support for aarch64

This adds ARM64 support into the DCN. This mainly enables support
for Navi graphics cards. The dcn10 changes haven't been tested,
since I don't have the relevant hardware available, but there
is no way to conditionally disable them, so I've done them anyway.

Signed-off-by: Daniel Kolesa <daniel@octaforge.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>


# f86c9b8b 03-Jun-2020 Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>

drm/amd/display: Only actually breakpoint if DEBUG_KERNEL_DC is enabled

To match previous behavior and to not hang the kernel if someone
accidentally builds with KGDB enabled.

Fixes: 1aad7078191116f ("drm/amd/display: Make BREAK_TO_DEBUGGER() a debug print")

Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>


# 1aad7078 22-May-2020 Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>

drm/amd/display: Make BREAK_TO_DEBUGGER() a debug print

[Why]
Warnings in the kernel are generally treated as errors.

The BREAK_TO_DEBUGGER macro is not a critical error or warning, but
rather intended for developer use to help investigate behavior and
sequences for other issues.

We do still make use of DC_ERROR/ASSERT(0) in various places in the
code for things that are genuine issues.

Since most developers don't actually KGDB while debugging the kernel
these essentially would have no value on their own since the KGDB
breakpoint wouldn't trigger - ASSERT(0) was used as a shortcut to get
a stacktrace.

[How]
Turn it into a DRM_DEBUG_DRIVER print instead. We unfortunately lose
the stacktrace, but we still do retain some of the useful debug
information this offers by having at least the function and line
number loggable.

If KGDB is supported in the kernel this will still trigger a real
breakpoint as well.

Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>


# f33a6dec 29-Apr-2020 Michel Dänzer <mdaenzer@redhat.com>

drm/amdgpu/dc: Use WARN_ON_ONCE for ASSERT

Once should generally be enough for diagnosing what lead up to it,
repeating it over and over can be pretty annoying.

Signed-off-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>


# ff6772b0 29-Apr-2020 Michel Dänzer <mdaenzer@redhat.com>

drm/amdgpu/dc: Use WARN_ON_ONCE for ASSERT

Once should generally be enough for diagnosing what lead up to it,
repeating it over and over can be pretty annoying.

Signed-off-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>


# 16a9dea1 07-Dec-2019 Timothy Pearson <tpearson@raptorengineering.com>

amdgpu: Enable initial DCN support on POWER

DCN requires floating point support to operate. Add the appropriate
x86/ppc64 guards and FPU / AltiVec / VSX context switches to DCN.

Note that the current DC20 code doesn't contain all required FPU
wrappers on x86 or POWER, so this patch is insufficient to fully
enable DC20 on POWER.

v2: s/X86_64/X86/g to retain previous behavior.

Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>


# 6ca3928d 07-Dec-2019 Timothy Pearson <tpearson@raptorengineering.com>

amdgpu: Prepare DCN floating point macros for generic arch support

Introduce DC_FP_START()/DC_FP_END() macros to help enable floating
point kernel mode support across various architectures.

v2: move copyright update to commit which adds the changes

Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>


# b86a1aa3 06-Nov-2019 Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>

drm/amd/display: rename DCN1_0 kconfig to DCN

Since dcn20 and dcn21 are under dcn1 it doesnt make sense to
have it named dcn1.

Change it to "dcn" to make it generic

Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>


# 3a1627b0 25-Oct-2019 Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>

drm/amd/display: Add DMUB support to DC

DC will use DMUB for command submission and flow control during
initialization.

Register offloading as well as submitting some BIOS commands are part
of the DC internal interface but are guarded behind debug options.

It won't be functional in amdgpu_dm yet since we don't pass the
DMUB service to DC for use.

Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Hersen Wu <hersenxs.wu@amd.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>


# 4fc4dca8 09-Jun-2019 Sam Ravnborg <sam@ravnborg.org>

drm/amd: drop use of drmp.h in os_types.h

Drop use of the deprecated drmP.h from display/dc/os_types.h

Fix all fallout after this change.
Most of the fixes was adding a missing include of vmalloc.h.

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: "David (ChunMing) Zhou" <David1.Zhou@amd.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20190609220757.10862-4-sam@ravnborg.org


# 1fcb748d 23-Oct-2018 David Howells <dhowells@redhat.com>

amd-gpu: Don't undefine READ and WRITE

Remove the undefinition of READ and WRITE because these constants may be
used elsewhere in subsequently included header files, thus breaking them.

These constants don't actually appear to be used in the driver, so the
undefinition seems pointless.

Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)")
Signed-off-by: David Howells <dhowells@redhat.com>


# dc37a9a0 16-Aug-2018 Leo (Sunpeng) Li <sunpeng.li@amd.com>

Revert "drm/amdgpu/display: Replace CONFIG_DRM_AMD_DC_DCN1_0 with CONFIG_X86"

This reverts commit 8624c3c4dbfe24fc6740687236a2e196f5f4bfb0.

We need CONFIG_DRM_AMD_DC_DCN1_0 to guard code that is using fp math.

Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Leo (Sunpeng) Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>


# 48412031 16-Jul-2018 Michel Dänzer <michel.daenzer@amd.com>

drm/amdgpu/display: Replace CONFIG_DRM_AMD_DC_DCN1_0 with CONFIG_X86

Allowing CONFIG_DRM_AMD_DC_DCN1_0 to be disabled on X86 was an
opportunity for display with Raven Ridge accidentally not working.

Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>


# 160b8e75 20-Mar-2018 Rex Zhu <Rex.Zhu@amd.com>

drm/amdgpu: Remove wrapper layer of cgs irq handling

v2: add Vega12 support

1. remove struct cgs_os_ops
2. delete cgs_linux.h
3. refine the irq code for vega10, can fix set pp table
failed issue.
4. add common smu irq process function

Acked-by: Christian König <christian.koenig@amd.com>
Acked-by: Junwei Zhang <Jerry.Zhang@amd.com>
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>


# e8e722d6 27-Nov-2017 Harry Wentland <harry.wentland@amd.com>

drm/amd/display: Don't spam debug log on long reg waits

Certain reg waits take up to a frame. Don't spam the log when this
happens.

Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Jordan Lazare <Jordan.Lazare@amd.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>


# 963aa22d 15-Nov-2017 Harry Wentland <harry.wentland@amd.com>

drm/amd/display: Clean up os_types.h a bit

Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>


# d8eed826 02-Nov-2017 Arnd Bergmann <arnd@arndb.de>

drm/amdgpu/display: provide ASSERT macros unconditionally

It seems impossible to build this driver without setting either
CONFIG_DEBUG_KERNEL or CONFIG_DEBUG_DRIVER:

drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h: In function 'set_reg_field_value_ex':
drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:132:2: error: implicit declaration of function 'ASSERT'; did you mean 'IS_ERR'? [-Werror=implicit-function-declaration]

This moves the ASSERT() macro and related helpers outside of
the #ifdef to get it to build again.

Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>


# 75e68891 11-Oct-2017 Harry Wentland <harry.wentland@amd.com>

drm/amd/display: Move OS types to os_types.h

Some of this stuff is not really dm_services

Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Acked-by: Harry Wentland <Harry.Wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>


# 93052132 02-Oct-2017 Dave Airlie <airlied@redhat.com>

amdgpu/dc: convert dc_transfer to use a kref.

Rolling your own atomic ref counts is frowned upon.

Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>


# 7d7024ca 09-Jan-2017 Dave Airlie <airlied@redhat.com>

drm/amd/display: drop min/max wrappers

These aren't needed, and aren't really used in too many places.

Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Reviewed-by: Harry Wentland <Harry.Wentland@amd.com>
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>


# b32c34ae 01-Dec-2016 Harry Wentland <harry.wentland@amd.com>

drm/amd/display: Removing extra newline

Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Acked-by: Harry Wentland <Harry.Wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>


# 4562236b 12-Sep-2017 Harry Wentland <harry.wentland@amd.com>

drm/amd/dc: Add dc display driver (v2)

Supported DCE versions: 8.0, 10.0, 11.0, 11.2

v2: rebase against 4.11

Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>