[why]
It's required for debug purposes.

[how]
Add a dsc_bpp_increment_div debug option that overrides DPCD
BITS_PER_PIXEL_INCREMENT value. The value dsc_bpp_increment_div should
be set to is the one after parsing, i.e. it could be 1, 2, 4, 8 or 16
(meaning 1pix, 1/2pix, ..., 1/16pix).
Signed-off-by: NNikola Cornij <nikola.cornij@amd.com>
Reviewed-by: NTony Cheng <Tony.Cheng@amd.com>
Acked-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
Firmware state and tracebuffer shouldn't be considered stable API
between firmware versions.

Driver shouldn't be querying anything from firmware state or tracebuffer
outside of debugging.

Commands are the stable API for this once we have the outbox.

[How]
Add metadata struct to the end of the data firmware that describes
fw_state_size and some reserved area for future use.

Drop the tracebuffer and firmware state headers since they can differ
per version.
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: NTony Cheng <Tony.Cheng@amd.com>
Acked-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
The DMUB is put into reset on suspend and is not running on resume,
disabling PSR/ABM features.

[How]
Move the allocation of the framebuffer to sw_init.

Do DMUB hardware init and framebuffer filling only from hw_init.

On resume the contents of the framebuffer will be invalid so those
should be cleared.
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: NRoman Li <Roman.Li@amd.com>
Acked-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
Some 10bit eDP panels don't lightup after we cap bpc to 8.

[How]
Set default max_bpc to 16 for edp connector type.
Signed-off-by: NRoman Li <roman.li@amd.com>
Reviewed-by: NNicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This reverts commit 1c425915.

S/G display is not stable with the IOMMU enabled on some
platforms.

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205523Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This reverts commit 1c425915.

S/G display is not stable with the IOMMU enabled on some
platforms.

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205523Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

This reverts commit 1c425915.

S/G display is not stable with the IOMMU enabled on some
platforms.

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205523Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
Before we had a disable_type1 flag, this forced HDCP 2.2 to type0
There was no way to force type1.

[How]
Remove disable_type1 flag and instead add a flag to force type0/1.
Signed-off-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
We need to do this to support HDCP over MST

Currently we save a display per link, in a MST case we need to save
multiple displays per link.

[How]
We can create an array per link to cache the displays, but it
complicates the design. Instead we can use the module to cache the
displays.

Now we will always add all the displays to the module, but we use the
adjustment flag to disable hdcp on all of them before they are added.

When we want to enable hdcp we just query the display(cache), remove
it then add it back with different adjustments. Its the similar for
disable.
Signed-off-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
HDCP 2.2 uses type0 and type1 content type. This is passed to the receiver
to stream the proper content.

For example, in a MST case if the main
device is HDCP2.2 capable but the secondary device is only 1.4 capabale
we can use Type0

Type0 content: use HDCP 1.4 or HDCP2.2 type0
Type1 content: Only use HDCP 2.2 type1

[How]
We use the "hdcp content type" property in drm. We use the
disable_type1 flag in hdcp module to select the type based on the
properties.

For updating the property we use the same logic as 1.4, but now we
consider content_type as well and update the property if the
requirements are met
Signed-off-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[why]
Previous patch allowed to initialize debugfs entries on both MST
and SST connectors, but MST connectors get registered much later
which exposed an issue of debugfs entries being initialized in the
same folder.

[how]
Return SST debugfs entries' initialization back to where it was.
For MST connectors we should initialize debugfs entries in connector
register function after the connector is registered.
Signed-off-by: NMikita Lipski <mikita.lipski@amd.com>
Reviewed-by: NNicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[why]
We were missing debugfs files on MST connectors as the files
weren't initialized.

[how]
Move connector debugfs initialization into connoctor's
init helper function so it will be called by both SST and MST
connectors. Also move connector registration so it will be
registered before we create the entries.
Signed-off-by: NMikita Lipski <mikita.lipski@amd.com>
Reviewed-by: NNicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
HDMI 2.0 HF-VSDB in EDID defines supported color depths in YCBCR420 modes.
But we did not honor these bit masks when choosing pixel encoding.
HDMI 2.0 compliance tests with deep color and YCBCR420 failed as a result.

[How]
Cap color depth based on y420_dc_modes from EDID.
Signed-off-by: NStylon Wang <stylon.wang@amd.com>
Reviewed-by: NNicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c: In function dm_determine_update_type_for_commit:
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:6516:36: warning: variable old_plane_crtc set but not used [-Wunused-but-set-variable]

It is introduced by commit a87fa993 ("drm/amd/display:
Build stream update and plane updates in dm"), but never used,
so remove it.
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: Nzhengbin <zhengbin13@huawei.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

dm_dcn_crtc_high_irq() is only used when CONFIG_DRM_AMD_DC_DCN is set.
Reviewed-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Need to protect some DSC functions.
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

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: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]

DCN21 is stable enough to be build by default. So drop the flags.

[How]

Remove them using the unifdef tool. The following commands were executed
in sequence:

$ find -name '*.c' -exec unifdef -m -DCONFIG_DRM_AMD_DC_DCN2_1 -UCONFIG_TRIM_DRM_AMD_DC_DCN2_1 '{}' ';'
$ find -name '*.h' -exec unifdef -m -DCONFIG_DRM_AMD_DC_DCN2_1 -UCONFIG_TRIM_DRM_AMD_DC_DCN2_1 '{}' ';'

In addition:

* Remove from kconfig, and replace any dependencies with DCN1_0.
* Remove from any makefiles.
* Fix and cleanup Renoir definitions in dal_asic_id.h
* Expand DCN1 ifdef to include DCN21 code in the following files:
    * clk_mgr/clk_mgr.c: dc_clk_mgr_create()
    * core/dc_resources.c: dc_create_resource_pool()
    * gpio/hw_factory.c: dal_hw_factory_init()
    * gpio/hw_translate.c: dal_hw_translate_init()
Signed-off-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]

DCN2 and DSC are stable enough to be build by default. So drop the flags.

[How]

Remove them using the unifdef tool. The following commands were executed
in sequence:

$ find -name '*.c' -exec unifdef -m -DCONFIG_DRM_AMD_DC_DSC_SUPPORT -DCONFIG_DRM_AMD_DC_DCN2_0 -UCONFIG_TRIM_DRM_AMD_DC_DCN2_0 '{}' ';'
$ find -name '*.h' -exec unifdef -m -DCONFIG_DRM_AMD_DC_DSC_SUPPORT -DCONFIG_DRM_AMD_DC_DCN2_0 -UCONFIG_TRIM_DRM_AMD_DC_DCN2_0 '{}' ';'

In addition:

* Remove from kconfig, and replace any dependencies with DCN1_0.
* Remove from any makefiles.
* Fix and cleanup NV defninitions in dal_asic_id.h
* Expand DCN1 ifdef to include DCN2 code in the following files:
    * clk_mgr/clk_mgr.c: dc_clk_mgr_create()
    * core/dc_resources.c: dc_create_resource_pool()
    * dce/dce_dmcu.c: dcn20_*lock_phy()
    * dce/dce_dmcu.c: dcn20_funcs
    * dce/dce_dmcu.c: dcn20_dmcu_create()
    * gpio/hw_factory.c: dal_hw_factory_init()
    * gpio/hw_translate.c: dal_hw_translate_init()
Signed-off-by: NLeo Li <sunpeng.li@amd.com>
Signed-off-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]

On DCN hardware, the crtc_high_irq handler makes vupdate_high_irq
handler redundant.

All the vupdate handler does is handle vblank events, and update vrr
for DCE hw (excluding VEGA, more on that later). As far as usermode is
concerned. vstartup happens close enough to vupdate on DCN that it can
be considered the "same". Handling vblank and updating vrr at vstartup
effectively replaces vupdate on DCN.

Vega is a bit special. Like DCN, the VRR registers on Vega are
double-buffered, and swapped at vupdate. But Unlike DCN, it lacks a
vstartup interrupt. This means we can't quite remove the vupdate handler
for it, since delayed user events due to vrr are sent off there.

[How]

Remove registration of vupdate interrupt handler for DCN. Disable
vupdate interrupt if asic family DCN, enable otherwise.
Reviewed-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: NLeo Li <sunpeng.li@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]

For DCN hardware, the crtc_high_irq handler is assigned to the vstartup
interrupt. This is different from DCE, which has it assigned to vblank
start.

We'd like to send vblank and user events at vstartup because:

* It happens close enough to vupdate - the point of no return for HW.

* It is programmed as lines relative to vblank end - i.e. it is not in
  the variable portion when VRR is enabled. We should signal user
  events here.

* The pflip interrupt responsible for sending user events today only
  fires if the DCH HUBP component is not clock gated. In situations
  where planes are disabled - but the CRTC is enabled - user events won't
  be sent out, leading to flip done timeouts.

Consequently, this makes vupdate on DCN hardware redundant. It will be
removed in the next change.

[How]

Add a DCN-specific crtc_high_irq handler, and hook it to the VStartup
signal. Inside the DCN handler, we send off user events if the pflip
handler hasn't already done so.
Reviewed-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: NLeo Li <sunpeng.li@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
It is confusing to sinks if we send VSC SDP only on some format. Today we
signal colorimetry format using MSA while in formats like sRGB.
But when we switch to BT2020 we set the bit to ignore MSA  colorimetry and
instead use the colorimetry information in the VSC SDP.

But if sink supports signaling of colorimetry via VSC SDP we should always
set the MSA MISC1 bit 6, instead of doing so selectively.

[How]
If sink supports signaling of colorimetry via VSC SDP, and we are sending
the colorimetry info via VSC SDP with packet revision 05h, then always
set MSA MISC1 bit 6.
Signed-off-by: NAnthony Koo <Anthony.Koo@amd.com>
Reviewed-by: NAric Cyr <Aric.Cyr@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
Support for DMUB only depends on support for DC. It doesn't use floating
point so we don't need to guard it by any specific DCN revision.

[How]
Drop the guards and cleanup the newlines around each one.
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: NHersen Wu <hersenxs.wu@amd.com>
Acked-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
DC can utilize the DMUB server to send commands to the DMUB but it's
the DM responsibility to pass it the service to use.

[How]
Create the dc_dmub_srv after we finish initializing the dmub_srv.
Cleanup the dc_dmub_srv before destroying the dmub_srv or dc.
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: NHersen Wu <hersenxs.wu@amd.com>
Acked-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
We need DMCUB on Renoir to support DMCU and PHY initialization.
The DMUB service provides a mechanism to load the DMCUB.

[How]
Include the DMUB service in amdgpu_dm.

Frontdoor loading of the DMCUB firmware needs to happen via PSP. To
pass the firmware to PSP we need to hand it off to the firmware list
in the base driver during software initialization.

Most of the DMUB service can technically be initialized at this point
in time, but we don't want to be allocating framebuffer memory for
hardware that doesn't support the DMCUB and in order to check that we
need to be able to read registers - something DM helpers aren't setup
to do in software initialization.

So everything but the service creation itself will get deferred to
hardware initialization.
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: NHersen Wu <hersenxs.wu@amd.com>
Acked-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

- Adding encoder atomic check to find vcpi slots for a connector
- Using DRM helper functions to calculate PBN
- Adding connector atomic check to release vcpi slots if connector
loses CRTC
- Calculate  PBN and VCPI slots only once during atomic
check and store them on crtc_state to eliminate
redundant calculation
- Call drm_dp_mst_atomic_check to verify validity of MST topology
during state atomic check

v2: squashed previous 3 separate patches, removed DSC PBN calculation,
and added PBN and VCPI slots properties to amdgpu connector

v3:
- moved vcpi_slots and pbn properties to dm_crtc_state and dc_stream_state
- updates stream's vcpi_slots and pbn on commit
- separated patch from the DSC MST series

v4:
- set vcpi_slots and pbn properties to dm_connector_state
- copy porperties from connector state on to crtc state

v5:
- keep the pbn and vcpi values only on connnector state
- added a void pointer to the stream state instead on two ints,
because dc_stream_state is OS agnostic. Pointer points to the
current dm_connector_state.

v6:
- Remove new param from stream

v7:
- Fix error with using max capable bpc

v8:
- squash in fix from Gustavo A. R. Silva
Reviewed-by: NLyude Paul <lyude@redhat.com>
Reviewed-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: NMikita Lipski <mikita.lipski@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Use the ddc pointer provided by the generic connector.
Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@collabora.com>
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ <40293fa4e619d1d1af213a076b1d03440e50c56c.1566845537.git.andrzej.p@collabora.com

Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NNeil Mayhew <neil@neil.mayhew.name>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]

Some LED panel drivers might not like fractional PWM. In such cases,
backlight flickering may be observed.

[How]

Add a DC feature mask to disable fractional PWM, and associate it with
the preexisting dc_config flag.

The flag is only plumbed through the dmcu firmware, so plumb it through
the driver path as well.

To disable, add the following to the linux cmdline:
amdgpu.dcfeaturemask=0x4

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204957Signed-off-by: NLeo Li <sunpeng.li@amd.com>
Reviewed-by: NAnthony Koo <anthony.koo@amd.com>
Tested-by: NLukáš Krejčí <lskrejci@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
Adding psr mask to dc features allows selectively disable/enable psr.
Current psr implementation may not work with non-pageflipping application.
Until resolved it should be disabled by default.

[How]
Add dcfeaturemask for psr enablement. Disable by default.
To enable set amdgpu.dcfeaturemask=0x8 in grub kernel command line.
Signed-off-by: NRoman Li <Roman.Li@amd.com>
Reviewed-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
PSR (Panel Self-Refresh) is a power-saving feature for eDP panels.
The feature has support in DMCU (Display MicroController Unit).
DMCU/driver communication is implemented in DC.
DM can use existing DC PSR interface to use PSR feature.

[How]
- Read psr caps via dpcd
- Send vsc infoframe if panel supports psr
- Disable psr before h/w programming (FULL_UPDATE)
- Enable psr after h/w programming
- Disable psr for fb console
Signed-off-by: NRoman Li <Roman.Li@amd.com>
Reviewed-by: NNicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: NLeo Li <sunpeng.li@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
While setting hdmi_vic, hv_frame.vic is not initialized and might
assign a wrong value to hdmi_vic. Cause to send out VSIF with
abnormal value.

[How]
Initialize hv_frame and avi_frame
Signed-off-by: NWayne Lin <Wayne.Lin@amd.com>
Reviewed-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This allows blocking for BOs to become available
in the memory management.

Amdgpu is doing this for quite a while now during CS. Now
apply the new behavior to all drivers using TTM.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Acked-by: NThomas Hellstrom <thellstrom@vmware.com>
Link: https://patchwork.freedesktop.org/patch/332878/

Finally! For a very long time, our MST helpers have had one very
annoying issue: They don't know how to reprobe the topology state when
coming out of suspend. This means that if a user has a machine connected
to an MST topology and decides to suspend their machine, we lose all
topology changes that happened during that period. That can be a big
problem if the machine was connected to a different topology on the same
port before resuming, as we won't bother reprobing any of the ports and
likely cause the user's monitors not to come back up as expected.

So, we start fixing this by teaching our MST helpers how to reprobe the
link addresses of each connected topology when resuming. As it turns
out, the behavior that we want here is identical to the behavior we want
when initially probing a newly connected MST topology, with a couple of
important differences:

- We need to be more careful about handling the potential races between
  events from the MST hub that could change the topology state as we're
  performing the link address reprobe
- We need to be more careful about handling unlikely state changes on
  ports - such as an input port turning into an output port, something
  that would be far more likely to happen in situations like the MST hub
  we're connected to being changed while we're suspend

Both of which have been solved by previous commits. That leaves one
requirement:

- We need to prune any MST ports in our in-memory topology state that
  were present when suspending, but have not appeared in the post-resume
  link address response from their parent branch device

Which we can now handle in this commit by modifying
drm_dp_send_link_address(). We then introduce suspend/resume reprobing
by introducing drm_dp_mst_topology_mgr_invalidate_mstb(), which we call
in drm_dp_mst_topology_mgr_suspend() to traverse the in-memory topology
state to indicate that each mstb needs it's link address resent and PBN
resources reprobed.

On resume, we start back up &mgr->work and have it reprobe the topology
in the same way we would on a hotplug, removing any leftover ports that
no longer appear in the topology state.

Changes since v4:
* Split indenting changes in drm_dp_mst_topology_mgr_resume() into a
  separate patch
* Only fire hotplugs when something has actually changed after a link
  address probe
* Don't try to change port->connector at all on ports, just throw out
  ports that need their connectors removed to make things easier.

Cc: Juston Li <juston.li@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Harry Wentland <hwentlan@amd.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NSean Paul <sean@poorly.run>
Signed-off-by: NLyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191022023641.8026-14-lyude@redhat.com

Since we're going to be reprobing the entire topology state on resume
now using sideband transactions, we need to ensure that we actually have
short HPD irqs enabled before calling drm_dp_mst_topology_mgr_resume().
So, do that.

Changes since v3:
* Fix typo in comments

Cc: Juston Li <juston.li@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Harry Wentland <hwentlan@amd.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NLyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191022023641.8026-13-lyude@redhat.com

Currently, every single piece of code in amdgpu that loops through
connectors does it incorrectly and doesn't use the proper list iteration
helpers, drm_connector_list_iter_begin() and
drm_connector_list_iter_end(). Yeesh.

So, do that.

Cc: Juston Li <juston.li@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Harry Wentland <hwentlan@amd.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NLyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191022023641.8026-12-lyude@redhat.com

[Why]
HDMI 2.0 requires scrambling under specific conditions. We refer to
stream property LTE_340MCSC_SCRAMBLE to determine whether en/dis
scrambling.
While creating stream for sink, we setup LTE_340MCSC_SCRAMBLE by
referring to edid_caps. However, dm_helpers_parse_edid_caps()
doesn't construct HDMI Forum block data for edid_caps.
Moreover, fill_stream_properties_from_drm_display_mode() aslo
unconsciously clear the LTE_340MCSC_SCRAMBLE flag.

[How]
Drm already provides drm_display_info to refer HDMI Forum vsdb info.
Set stream LTE_340MCSC_SCRAMBLE by drm_display_info and remove
memset in fill_stream_properties_from_drm_display_mode()
Signed-off-by: NWayne Lin <Wayne.Lin@amd.com>
Reviewed-by: NNicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
Didn't send VSIF infopacket when it's 4k mode defined in HDMI 1.4b.
For HDMI 1.4b, While displaying 4k modes, it should send VSP.

[How]
Call mod_build_hf_vsif_infopacket() function to build info frame
and send it.
Signed-off-by: NWayne Lin <Wayne.Lin@amd.com>
Reviewed-by: NNicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
While displaying 4k modes defined in HDMI1.4b, should set VIC to 0
and use VSP HDMI_VIC to indicate the mode.

[How]
Use functions defined in drm to set up the VIC correspondingly.
Signed-off-by: NWayne Lin <Wayne.Lin@amd.com>
Reviewed-by: NNicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

p and g are switched in 'amdpgu_dm'
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>