drm/amd/display: Add signal type check when verify stream backends same

[ Upstream commit 047db281c026de5971cedb5bb486aa29bd16a39d ]

[Why]
For allow eDP hot-plug feature, the stream signal may chan

drm/amd/display: Add signal type check when verify stream backends same

[ Upstream commit 047db281c026de5971cedb5bb486aa29bd16a39d ]

[Why]
For allow eDP hot-plug feature, the stream signal may change to VIRTUAL
when plug-out and back to eDP when plug-in. OS will still setPathMode
with same timing for each plugging, but eDP gets no stream update as we
don't check signal type changing back as keeping it VIRTUAL. It's also
unsafe for future cases that stream signal is switched with same timing.

[How]
Check stream signal type change include previous HDMI signal case.

Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Wayne Lin <wayne.lin@amd.com>
Signed-off-by: Dale Zhao <dale.zhao@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

drm/amd/display: Fix stream->link_enc unassigned during stream removal

[ Upstream commit 3743e7f6fcb938b7d8b7967e6a9442805e269b3d ]

[Why]
Found when running igt@kms_atomic.

Userspace attempts to d

drm/amd/display: Fix stream->link_enc unassigned during stream removal

[ Upstream commit 3743e7f6fcb938b7d8b7967e6a9442805e269b3d ]

[Why]
Found when running igt@kms_atomic.

Userspace attempts to do a TEST_COMMIT when 0 streams which calls
dc_remove_stream_from_ctx. This in turn calls link_enc_unassign
which ends up modifying stream->link = NULL directly, causing the
global link_enc to be removed preventing further link activity
and future link validation from passing.

[How]
We take care of link_enc unassignment at the start of
link_enc_cfg_link_encs_assign so this call is no longer necessary.

Fixes global state from being modified while unlocked.

Reviewed-by: Jimmy Kizito <Jimmy.Kizito@amd.com>
Acked-by: Jasdeep Dhillon <jdhillon@amd.com>
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

drm/amd/display: Fix for the no Audio bug with Tiled Displays

[ Upstream commit 5ceaebcda9061c04f439c93961f0819878365c0f ]

[WHY]
It seems like after a series of plug/unplugs we end up in a situatio

drm/amd/display: Fix for the no Audio bug with Tiled Displays

[ Upstream commit 5ceaebcda9061c04f439c93961f0819878365c0f ]

[WHY]
It seems like after a series of plug/unplugs we end up in a situation
where tiled display doesnt support Audio.

[HOW]
The issue seems to be related to when we check streams changed after an
HPD, we should be checking the audio_struct as well to see if any of its
values changed.

Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Mustapha Ghaddar <mustapha.ghaddar@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

drm/amd/display: Add check for validating unsupported ODM plus MPO case

[Why]
We do not currently support ODM plus MPO on only one side of the
screen. This unsupported case causes validation calcula

drm/amd/display: Add check for validating unsupported ODM plus MPO case

[Why]
We do not currently support ODM plus MPO on only one side of the
screen. This unsupported case causes validation calculations to
divide by zero due to invalid viewport values.

[How]
Add stopgap for the validation of ODM plus MPO on one side of
screen case.

Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Jaehyun Chung <jaehyum.chung@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Fix typo in comments

Remove the repeated word 'the' from comments

Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amd/display: Fix 10bit 4K display on CIK GPUs

Commit 72a7cf0aec0c ("drm/amd/display: Keep linebuffer pixel depth at
30bpp for DCE-11.0.") doesn't seems to have fixed 10bit 4K rendering over
Disp

drm/amd/display: Fix 10bit 4K display on CIK GPUs

Commit 72a7cf0aec0c ("drm/amd/display: Keep linebuffer pixel depth at
30bpp for DCE-11.0.") doesn't seems to have fixed 10bit 4K rendering over
DisplayPort for CIK GPUs. On my machine with a HAWAII GPU I get a broken
image that looks like it has an effective resolution of 1920x1080 but
scaled up in an irregular way. Reverting the commit or applying this
patch fixes the problem on v5.14-rc1.

Fixes: 72a7cf0aec0c ("drm/amd/display: Keep linebuffer pixel depth at 30bpp for DCE-11.0.")
Acked-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Liviu Dudau <liviu@dudau.co.uk>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Fix 10bit 4K display on CIK GPUs

Commit 72a7cf0aec0c ("drm/amd/display: Keep linebuffer pixel depth at
30bpp for DCE-11.0.") doesn't seems to have fixed 10bit 4K rendering over
Disp

drm/amd/display: Fix 10bit 4K display on CIK GPUs

Commit 72a7cf0aec0c ("drm/amd/display: Keep linebuffer pixel depth at
30bpp for DCE-11.0.") doesn't seems to have fixed 10bit 4K rendering over
DisplayPort for CIK GPUs. On my machine with a HAWAII GPU I get a broken
image that looks like it has an effective resolution of 1920x1080 but
scaled up in an irregular way. Reverting the commit or applying this
patch fixes the problem on v5.14-rc1.

Fixes: 72a7cf0aec0c ("drm/amd/display: Keep linebuffer pixel depth at 30bpp for DCE-11.0.")
Acked-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Liviu Dudau <liviu@dudau.co.uk>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amdgpu/display: fold DRM_AMD_DC_DCN3_1 into DRM_AMD_DC_DCN

No need for a separate flag now that DCN3.1 is not in bring up.
Fold into DRM_AMD_DC_DCN like previous DCN IPs.

Reviewed-by: Nicholas

drm/amdgpu/display: fold DRM_AMD_DC_DCN3_1 into DRM_AMD_DC_DCN

No need for a separate flag now that DCN3.1 is not in bring up.
Fold into DRM_AMD_DC_DCN like previous DCN IPs.

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

show more ...

drm/amd/display: use ARRAY_SIZE for base60_refresh_rates

Use ARRAY_SIZE instead of dividing sizeof array with sizeof an
element.

Clean up the following coccicheck warning:

./drivers/gpu/drm/amd/di

drm/amd/display: use ARRAY_SIZE for base60_refresh_rates

Use ARRAY_SIZE instead of dividing sizeof array with sizeof an
element.

Clean up the following coccicheck warning:

./drivers/gpu/drm/amd/display/dc/core/dc_resource.c:448:47-48: WARNING:
Use ARRAY_SIZE.

Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Fix crash during MPO + ODM combine mode recalculation

[Why]
When calculating recout width for an MPO plane on a mode that's using
ODM combine, driver can calculate a negative value,

drm/amd/display: Fix crash during MPO + ODM combine mode recalculation

[Why]
When calculating recout width for an MPO plane on a mode that's using
ODM combine, driver can calculate a negative value, resulting in a
crash.

[How]
For negative widths, use zero such that validation will prune the
configuration correctly and disallow MPO.

Signed-off-by: Aric Cyr <aric.cyr@amd.com>
Reviewed-by: Krunoslav Kovac <Krunoslav.Kovac@amd.com>
Acked-by: Stylon Wang <stylon.wang@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Add DCN3.1 Resource

Container for hardware resources and blocks for DCN3.1, also adds
new DC debug flags used with DCN3.1.

Acked-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Ni

drm/amd/display: Add DCN3.1 Resource

Container for hardware resources and blocks for DCN3.1, also adds
new DC debug flags used with DCN3.1.

Acked-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Add DCN3.1 DIO

Add support for the DIO (Display IO) block of DCN3.1 which controls
legacy HDMI/DP stream/link encoding.

HW Blocks:

+--------+ +--------+
| DIO |

drm/amd/display: Add DCN3.1 DIO

Add support for the DIO (Display IO) block of DCN3.1 which controls
legacy HDMI/DP stream/link encoding.

HW Blocks:

+--------+ +--------+
| DIO | | DCCG |
+--------+ +--------+

Includes some updates to core logic for link encoder assignment and
future support for new high bandwidth output.

v2: squash in unused variable fix (Alex)

Acked-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Keep linebuffer pixel depth at 30bpp for DCE-11.0.

Testing on AMD Carizzo with DCE-11.0 display engine showed that
it doesn't like a 36 bpp linebuffer very much. The display just
sh

drm/amd/display: Keep linebuffer pixel depth at 30bpp for DCE-11.0.

Testing on AMD Carizzo with DCE-11.0 display engine showed that
it doesn't like a 36 bpp linebuffer very much. The display just
showed a solid green.

Testing on RavenRidge DCN-1.0, Polaris11 with DCE-11.2 and Kabini
with DCE-8.3 did not expose any problems, so for now only revert
to 30 bpp linebuffer depth on asics with DCE-11.0 display engine.

Fixes: a316db72096044 ("drm/amd/display: Increase linebuffer pixel depth to 36bpp.")
Reported-by: Tom StDenis <Tom.StDenis@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Increase linebuffer pixel depth to 36bpp.

Testing with the photometer shows that at least Raven Ridge DCN-1.0
does not achieve more than 10 bpc effective output precision with a
16

drm/amd/display: Increase linebuffer pixel depth to 36bpp.

Testing with the photometer shows that at least Raven Ridge DCN-1.0
does not achieve more than 10 bpc effective output precision with a
16 bpc unorm surface of type SURFACE_PIXEL_FORMAT_GRPH_ABGR16161616,
unless linebuffer depth is increased from LB_PIXEL_DEPTH_30BPP to
LB_PIXEL_DEPTH_36BPP. Otherwise precision gets truncated somewhere
to 10 bpc effective depth.

Strangely this increase was not needed on Polaris11 DCE-11.2 during
testing to get 12 bpc effective precision. It also is not needed for
fp16 framebuffers.

Tested on DCN-1.0 and DCE-11.2.

Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Add support for SURFACE_PIXEL_FORMAT_GRPH_ABGR16161616.

Add the necessary format definition, bandwidth and pixel size mappings,
prescaler setup, and pixelformat selection, following

drm/amd/display: Add support for SURFACE_PIXEL_FORMAT_GRPH_ABGR16161616.

Add the necessary format definition, bandwidth and pixel size mappings,
prescaler setup, and pixelformat selection, following the logic
already present for SURFACE_PIXEL_FORMAT_GRPH_ARGB16161616.

The new SURFACE_PIXEL_FORMAT_GRPH_ABGR16161616 is implemented as the
old SURFACE_PIXEL_FORMAT_GRPH_ARGB16161616 format, but with swapped
red <-> green color channel, by use of the hardware xbar.

Please note that on the DCN 1/2/3 display engines, the pixelformat
in hubp and dpp setup for the old SURFACE_PIXEL_FORMAT_GRPH_ARGB16161616
and the new SURFACE_PIXEL_FORMAT_GRPH_ABGR16161616 was changed from
format id 22 to id 26. See amd/include/navi10_enum.h for the meaning
of the id's.

For format 22, the display engine read the framebuffer in 16 bpc format,
but truncated to the 12 bpc actually supported by later pipeline stages.
However, the engine took the 12 LSB of each color component for
truncation, which is incompatible with rendering at least under Vulkan,
where content is 16 bit wide, and a 12 MSB alignment would be appropriate,
if any. Format 20 for ARGB16161616_12MSB does work, but even better, we
can choose format 26 for ARGB16161616_UNORM, keeping all 16 bits around
until later stages of the display pipeline.

This allows to directly consume what the rendering hw produces under
Vulkan for swapchain format VK_FORMAT_R16G16B16A16_UNORM, as tested
with a patched version of the current AMD open-source amdvlk driver
which maps swapchain format VK_FORMAT_R16G16B16A16_UNORM onto
DRM_FORMAT_XBGR16161616.

The old id 22 would cause colorful pixeltrash to be displayed instead.

Tested under DCN-1.0 and DCE-11.2.

Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: fix odm scaling

There are two issues with scaling calculations, odm recout
calculation and matching viewport to actual recout.

This change fixes both issues. Odm recout calculation

drm/amd/display: fix odm scaling

There are two issues with scaling calculations, odm recout
calculation and matching viewport to actual recout.

This change fixes both issues. Odm recout calculation via
special casing and viewport matching issue by reworking
the viewport calcualtion to use scaling ratios and recout
to derrive the required offset and size.

Signed-off-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Initial DC support for Beige Goby

[Why&How]
Add Beige Goby (DCN303) resource, irq service, & dmub loader.

v2: fix nbio include (Alex)

Signed-off-by: Chris Park <Chris.Park@amd.com

drm/amd/display: Initial DC support for Beige Goby

[Why&How]
Add Beige Goby (DCN303) resource, irq service, & dmub loader.

v2: fix nbio include (Alex)

Signed-off-by: Chris Park <Chris.Park@amd.com>
Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Set stream_count to 0 when dc_resource_state_destruct.

[Why]
When hardware need to be reset, driver need to reset stream objects but
dc_resource_state_destruct function omit resetti

drm/amd/display: Set stream_count to 0 when dc_resource_state_destruct.

[Why]
When hardware need to be reset, driver need to reset stream objects but
dc_resource_state_destruct function omit resetting stream_count. It will
lead page fault if some logic will touch stream object.

[How]
Set stream_count to 0 when dc_resource_state_destruct.

Signed-off-by: Paul Wu <paul.wu@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Wayne Lin <Wayne.Lin@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: remove checking sink in is_timing_changed

[Why]
Sometimes, such as sleep wake, the link->local sink pointer changed,
but the dc_stream_state->sink pointer is not changed. The checki

drm/amd/display: remove checking sink in is_timing_changed

[Why]
Sometimes, such as sleep wake, the link->local sink pointer changed,
but the dc_stream_state->sink pointer is not changed. The checking
of timing_changed reports wrong result, lead to link tear down
unexpected wrongly.

[How]
SST compare local sink, MST compare proper remote link.

Signed-off-by: Calvin Hou <Calvin.Hou@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Wayne Lin <Wayne.Lin@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Report Proper Quantization Range in AVI Infoframe

[Why?]
When a monitor does not set both QS and QY bits, DC does not
set Q0, Q1, QY0 and QY1 bits in AVI infoframe. Setting RGB bits

drm/amd/display: Report Proper Quantization Range in AVI Infoframe

[Why?]
When a monitor does not set both QS and QY bits, DC does not
set Q0, Q1, QY0 and QY1 bits in AVI infoframe. Setting RGB bits
should be separate from setting YCC bits.

[How?]
Separate logic for setting RGB and YCC quantization range bits
in the AVI infoframe.

Signed-off-by: Dillon Varone <dillon.varone@amd.com>
Reviewed-by: Chris Park <Chris.Park@amd.com>
Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Add dynamic link encoder selection.

[Why]
Some display endpoints may be programmably mapped to compatible link
encoders. The assignment of link encoders to links has to be dynamic t

drm/amd/display: Add dynamic link encoder selection.

[Why]
Some display endpoints may be programmably mapped to compatible link
encoders. The assignment of link encoders to links has to be dynamic to
accommodate the increased flexibility in comparison to conventional
display endpoints.

[How]
- Add link encoder assignment tracking variables.
- Execute link encoder assignment algorithm before enabling link and
release link encoders from links once they are disabled.

Signed-off-by: Jimmy Kizito <Jimmy.Kizito@amd.com>
Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Acked-by: Anson Jacob <Anson.Jacob@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Fix 64 bit divisions on 32 bit platforms by using div64 API

[why]
Synchronization displays with different timings feature uses division
operator for 64 bit division, which is not su

drm/amd/display: Fix 64 bit divisions on 32 bit platforms by using div64 API

[why]
Synchronization displays with different timings feature uses division
operator for 64 bit division, which is not supported by 32 bit platforms

[how]
Use div64 API for 64 bit division

Signed-off-by: Vladimir Stempen <vladimir.stempen@amd.com>
Tested-by: Bindu Ramamurthy<bindu.r@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Synchronize displays with different timings

[why]
Vendor based fan noise improvement

[how]
Report timing synchronizable when DP streams time frame
difference is less than 0.05 per

drm/amd/display: Synchronize displays with different timings

[why]
Vendor based fan noise improvement

[how]
Report timing synchronizable when DP streams time frame
difference is less than 0.05 percent. Adjust DP DTOs and
sync displays using MASTER_UPDATE_LOCK_DB_X_Y

Signed-off-by: Vladimir Stempen <vladimir.stempen@amd.com>
Acked-by: Bindu Ramamurthy <bindu.r@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Reject too small viewport size when validating plane

[why]
Overlay won't move to a new positon if viewport size is smaller than
what can be handled. It'd either disappear or stay at

drm/amd/display: Reject too small viewport size when validating plane

[why]
Overlay won't move to a new positon if viewport size is smaller than
what can be handled. It'd either disappear or stay at the old
position. This condition is for example hit if overlay is moved too
much outside of left or top edge of the screen, but it applies to
any non-cursor plane type.

[how]
Reject this contidion at validation time. This gives the calling
level a chance to handle this gracefully and avoid inconsistent
behaivor.

Signed-off-by: Nikola Cornij <nikola.cornij@amd.com>
Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: Anson Jacob <Anson.Jacob@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display/dc/core/dc_resource: Demote some kernel-doc abuses

Fixes the following W=1 kernel build warning(s):

drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1710: warning: Funct

drm/amd/display/dc/core/dc_resource: Demote some kernel-doc abuses

Fixes the following W=1 kernel build warning(s):

drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1710: warning: Function parameter or member 'old_stream' not described in 'dc_is_stream_unchanged'
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1710: warning: Function parameter or member 'stream' not described in 'dc_is_stream_unchanged'
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1726: warning: Function parameter or member 'old_stream' not described in 'dc_is_stream_scaling_unchanged'
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1726: warning: Function parameter or member 'stream' not described in 'dc_is_stream_scaling_unchanged'
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1843: warning: Function parameter or member 'dc' not described in 'dc_add_stream_to_ctx'
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1843: warning: Function parameter or member 'new_ctx' not described in 'dc_add_stream_to_ctx'
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1843: warning: Function parameter or member 'stream' not described in 'dc_add_stream_to_ctx'
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1870: warning: Function parameter or member 'dc' not described in 'dc_remove_stream_from_ctx'
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1870: warning: Function parameter or member 'new_ctx' not described in 'dc_remove_stream_from_ctx'
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1870: warning: Function parameter or member 'stream' not described in 'dc_remove_stream_from_ctx'

Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: amd-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...