Currently we enable FEC even when DSC is no used. While that is
theoretically valid supposedly there isn't much of a benefit from
this. But more importantly we do not account for the FEC link
bandwidth overhead (2.4%) in the non-DSC link bandwidth computations.
So the code may think we have enough bandwidth when we in fact
do not.

Cc: stable@vger.kernel.org
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Fixes: 240999cf ("i915/dp/fec: Add fec_enable to the crtc state.")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190326144903.6617-1-ville.syrjala@linux.intel.comReviewed-by: NManasi Navare <manasi.d.navare@intel.com>
(cherry picked from commit 6fd3134a)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Commit 7769db58 ("drm/i915/dp: optimize eDP 1.4+ link config fast
and narrow") started to optize the eDP 1.4+ link config, both per spec
and as preparation for display stream compression support.

Sadly, we again face panels that flat out fail with parameters they
claim to support. Revert, and go back to the drawing board.

v2: Actually revert to max params instead of just wide-and-slow.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109959
Fixes: 7769db58 ("drm/i915/dp: optimize eDP 1.4+ link config fast and narrow")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Matt Atwood <matthew.s.atwood@intel.com>
Cc: "Lee, Shawn C" <shawn.c.lee@intel.com>
Cc: Dave Airlie <airlied@gmail.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v5.0+
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Tested-by: Albert Astals Cid <aacid@kde.org> # v5.0 backport
Tested-by: Emanuele Panigati <ilpanich@gmail.com> # v5.0 backport
Tested-by: Matteo Iervasi <matteoiervasi@gmail.com> # v5.0 backport
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190405075220.9815-1-jani.nikula@intel.com
(cherry picked from commit f11cb1c1)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

In August 2018 the BSPEC changed the ICL port programming sequence to
closely resemble earlier gen programming sequence. Restrict combo phy to
HBR max rate unless eDP panel is connected to port.

v2: remove debug code that Imre found
v3: simplify translation table if-else
v4: edp translation table now based on link rate and low_swing
v5: Misc review comments + r-b
BSpec: 21257
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NClint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1545084827-5776-1-git-send-email-clinton.a.taylor@intel.com
(cherry picked from commit b265a2a6)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

This hotplug also isn't needed: drm_dp_mst_topology_mgr_set_mst()
already sends a hotplug on its own from drm_dp_destroy_connector_work()
after destroying connectors in the MST topology.
Signed-off-by: NLyude Paul <lyude@redhat.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190129191001.442-4-lyude@redhat.com

We have a bad habit of calling drm_fb_helper_hotplug_event() far more
then we actually need to. MST appears to be one of these cases, where we
call drm_fb_helper_hotplug_event() if we fail to resume a connected MST
topology in intel_dp_mst_resume(). We don't actually need to do this at
all though since hotplug events are already sent from
drm_dp_connector_destroy_work() every time connectors are unregistered
from userspace's PoV. Additionally, extra calls to
drm_fb_helper_hotplug_event() also just mean more of a chance of doing a
connector probe somewhere we shouldn't.

So, don't send any hotplug events during resume if the MST topology
fails to come up. Just rely on the DP MST helpers to send them for us.
Signed-off-by: NLyude Paul <lyude@redhat.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190129191001.442-3-lyude@redhat.com

We generally omit register polling from the i915_reg_rw tracepoint.
Understandable since polling could generate a lot of noise in the
trace. The downside is that the trace is incomplete. As a compromise
let's trace the final register value observed while polling. That
should be generally sufficient to observe what the code should be
doing next.

I suppose in some cases it might make sense to also trace the initial
register value, and maybe the number of times we polled. But that
would require a separate tracepoint so let's leave it for the future.

The other users of _NOTRACE() are i915_pmu and i2c bitbanging,
which I decided to leave alone.

Next we should do something to claw back the tracepoints for
planes and whatnot which were switched to _FW() a while back.
I guess just new macros for raw_rw+trace. The question is
what to call it?
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190204211644.21967-1-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

First of all GMCH can be considered a feature by itself
since it is a chip present in some platforms that connects
the IA processor to memory and other components in PC.

Also with the introduction of display block at device info,
we got a redundant definition:

.display.has_gmch_display = 1,

So, let's clean up things a bit and use the standardized
way of has_feature on displays side.

No functional change and no manual interaction to generate
this patch.

It is only:

sed -si -e 's/has_gmch_display/has_gmch/g' \
    	-e 's/HAS_GMCH_DISPLAY/HAS_GMCH/g' drivers/gpu/drm/i915/*{c,h}

Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190204222538.15842-1-rodrigo.vivi@intel.com

Having the probe helper stuff (which pretty much everyone needs) in
the drm_crtc_helper.h file (which atomic drivers should never need) is
confusing. Split them out.

To make sure I actually achieved the goal here I went through all
drivers. And indeed, all atomic drivers are now free of
drm_crtc_helper.h includes.

v2: Make it compile. There was so much compile fail on arm drivers
that I figured I'll better not include any of the acks on v1.

v3: Massive rebase because i915 has lost a lot of drmP.h includes, but
not all: Through drm_crtc_helper.h > drm_modeset_helper.h -> drmP.h
there was still one, which this patch largely removes. Which means
rolling out lots more includes all over.

This will also conflict with ongoing drmP.h cleanup by others I
expect.

v3: Rebase on top of atomic bochs.

v4: Review from Laurent for bridge/rcar/omap/shmob/core bits:
- (re)move some of the added includes, use the better include files in
  other places (all suggested from Laurent adopted unchanged).
- sort alphabetically

v5: Actually try to sort them, and while at it, sort all the ones I
touch.

v6: Rebase onto i915 changes.

v7: Rebase once more.
Acked-by: NHarry Wentland <harry.wentland@amd.com>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>
Acked-by: NJani Nikula <jani.nikula@intel.com>
Acked-by: NNeil Armstrong <narmstrong@baylibre.com>
Acked-by: NOleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Acked-by: NCK Hu <ck.hu@mediatek.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NLiviu Dudau <liviu.dudau@arm.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: virtualization@lists.linux-foundation.org
Cc: etnaviv@lists.freedesktop.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: intel-gfx@lists.freedesktop.org
Cc: linux-mediatek@lists.infradead.org
Cc: linux-amlogic@lists.infradead.org
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Cc: spice-devel@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-rockchip@lists.infradead.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-tegra@vger.kernel.org
Cc: xen-devel@lists.xen.org
Link: https://patchwork.freedesktop.org/patch/msgid/20190117210334.13234-1-daniel.vetter@ffwll.ch

Restore our saved values for backlight. This way even with fastset on
S4 resume we will correctly restore the backlight to the active values.

Changes since v1:
- Call enable_backlight() when backlight.level is set. On suspend
  backlight.enabled is always cleared, this makes it not a good
  indicator. Also check for crtc->state->active.
Changes since v2:
- Use the new update_pipe() callback to run this on resume as well.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Tolga Cakir <cevelnet@gmail.com>
Cc: Basil Eric Rabi <ericbasil.rabi@gmail.com>
Cc: Hans de Goede <jwrdegoede@fedoraproject.org>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190108160842.13396-1-maarten.lankhorst@linux.intel.com

It's superfluous.
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/7987938a7950853ac3ee43c82fb9cbb0cd59a2fa.1547726792.git.jani.nikula@intel.com

Mixed C99 and kernel types use is getting ugly. Prefer kernel types.

sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g'

Minor checkpatch/whitespace fixes sprinkled on top of the changed lines.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/3c030a12b4313eec512ce2b7a953cff439d8af67.1547629303.git.jani.nikula@intel.com

Something that I completely missed when implementing the new MST VCPI
atomic helpers is that with those helpers, there's technically a chance
of us having to grab additional modeset locks in ->compute_config() and
furthermore, that means we have the potential to hit a normal modeset
deadlock. However, because ->compute_config() only returns a bool this
means we can't return -EDEADLK when we need to drop locks and try again
which means we end up just failing the atomic check permanently. Whoops.

So, fix this by modifying ->compute_config() to pass down an actual
error code instead of a bool so that the atomic check can be restarted
on modeset deadlocks.

Thanks to Ville Syrjälä for pointing this out!

Changes since v1:
* Add some newlines
* Return only -EINVAL from hsw_crt_compute_config()
* Propogate return code from intel_dp_compute_dsc_params()
* Change all of the intel_dp_compute_link_config*() variants
* Don't miss if (hdmi_port_clock_valid()) branch in
  intel_hdmi_compute_config()

[Cherry-picked from drm-misc-next to drm-intel-next-queued to fix
 linux-next & drm-tip conflict, while waiting for proper propagation of
 the DP MST series that this commit fixes. In hindsight, a topic branch
 might have been a better approach for it.]
Signed-off-by: NLyude Paul <lyude@redhat.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Fixes: eceae147 ("drm/dp_mst: Start tracking per-port VCPI allocations")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190115200800.3121-1-lyude@redhat.com
(cherry picked from commit 96550555)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Acked-by: NDaniel Vetter <daniel@ffwll.ch>

Something that I completely missed when implementing the new MST VCPI
atomic helpers is that with those helpers, there's technically a chance
of us having to grab additional modeset locks in ->compute_config() and
furthermore, that means we have the potential to hit a normal modeset
deadlock. However, because ->compute_config() only returns a bool this
means we can't return -EDEADLK when we need to drop locks and try again
which means we end up just failing the atomic check permanently. Whoops.

So, fix this by modifying ->compute_config() to pass down an actual
error code instead of a bool so that the atomic check can be restarted
on modeset deadlocks.

Thanks to Ville Syrjälä for pointing this out!

Changes since v1:
* Add some newlines
* Return only -EINVAL from hsw_crt_compute_config()
* Propogate return code from intel_dp_compute_dsc_params()
* Change all of the intel_dp_compute_link_config*() variants
* Don't miss if (hdmi_port_clock_valid()) branch in
  intel_hdmi_compute_config()
Signed-off-by: NLyude Paul <lyude@redhat.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Fixes: eceae147 ("drm/dp_mst: Start tracking per-port VCPI allocations")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190115200800.3121-1-lyude@redhat.com

Track where and when we acquire and release the power well for pps
access along the dp aux link, with a view to detecting if we leak any
wakerefs.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: NJohn Harrison <John.C.Harrison@Intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190114142129.24398-18-chris@chris-wilson.co.uk

The majority of runtime-pm operations are bounded and scoped within a
function; these are easy to verify that the wakeref are handled
correctly. We can employ the compiler to help us, and reduce the number
of wakerefs tracked when debugging, by passing around cookies provided
by the various rpm_get functions to their rpm_put counterpart. This
makes the pairing explicit, and given the required wakeref cookie the
compiler can verify that we pass an initialised value to the rpm_put
(quite handy for double checking error paths).
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190114142129.24398-16-chris@chris-wilson.co.uk

Needs just a few additional includes here and there.

Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190108082709.3748-1-jani.nikula@intel.com

Do not make it an error to call intel_edp_drrs_enable while drrs has
already been enabled, instead exit silently in this case.

This is a preparation patch for ensuring that DRRS is enabled on fastsets.

Note that the removed WARN_ON could also be triggered from userspace
through the i915_drrs_ctl debugfs entry which was added by
commit 35954e88 ("drm/i915: Runtime disable for eDP DRRS")
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181220132120.15318-2-hdegoede@redhat.com

Add a fallback detection method for TypeC legacy ports in case the
VBT port information used to detect normally such ports is
incorrect.

For the fallback method we use the TypeC legacy mode specific HPD
interrupt flag which should only be raised for a legacy port.

WARN if the VBT port info is incorrect.

In a case where we'd detect the port in a contradicting way both as a
legacy and also as a USB DP and/or TBT alternate port treat the port
as legacy (by also emitting a WARN from icl_update_tc_port_type).

v2:
- Repurpose the detection as a fallback method instead of using
  it only for the DP legacy case. By now we should normally use VBT to
  detect DP legacy ports as well.
Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (v1)
Reviewed-by: NMika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181214182703.18865-5-imre.deak@intel.com

Atm HPD disconnect events on TypeC ports will break things, since we'll
switch the TypeC mode (between legacy and disconnected modes as well as
among USB DP alternate, Thunderbolt alternate and disconnected modes) on
the fly from the HPD disconnect interrupt work while the port may be
still active.

Even if the port happens to be not active during the disconnect we'd
still have a problem during a subsequent modeset or AUX transfer that
could happen regardless of the port's connected state. For instance the
system resume display mode restore code and userspace could perform a
modeset on the port or userspace could start an AUX transfer even if the
port is in disconnected state.

To fix this keep TypeC legacy ports in legacy mode whenever we're not
suspended. This mode is a static configuration as opposed to the
Thunderbolt and USB DP alternate modes between which we can switch
dynamically.

We determine if a TypeC port is legacy (wired to a legacy HDMI or a
legacy DP connector) via the VBT DDI port specific USB-TypeC and
Thunderbolt flags. If both these flags are cleared then the port is
configured for legacy mode.

On such legacy ports we'll run the TypeC PHY connect sequence explicitly
during driver loading and system resume (vs. running the sequence during
HPD processing). The connect will succeed even if the display is not
connected to begin with (or disappears during the suspended state) since
for legacy ports the PORT_TX_DFLEXDPPMS / DP_PHY_MODE_STATUS_COMPLETED
flag is always set (as opposed to the USB DP alternate mode where it
gets set only when a display is connected).

Correspondingly run the TypeC PHY disconnect sequence during system
suspend and driver unloading. For the unloading case I had to split
up intel_dp_encoder_destroy() to be able to have the 1. flush any
pending encoder work, 2. disconnect TC PHY, 3. call DRM core cleanup and
kfree on the encoder object.

For now run the PHY disconnect during suspend only for TypeC legacy
ports. We will need to disconnect even in USB DP alternate mode in the
future, but atm we don't have a way to reconnect the port in this mode
during resume if the display disappears while being suspended. So for
now punt on this case.

Note that we do not disconnect the port during runtime suspend; in
legacy mode there are no shared HW resources (PHY lanes) with other HW
blocks (USB), so no need to release / reacquire these resources as with
USB DP alternate mode. The only reason to disconnect legacy ports during
system suspend is that the PORT_TX_DFLEXDPPMS /
DP_PHY_MODE_STATUS_COMPLETED flag must be rechecked and the port must be
connected again during system resume. We'll also have to turn the check
for this flag into a poll, after figuring out what's the proper timeout
value for it.

v2:
- Remove the redundant special casing of legacy mode when doing a
  disconnect in icl_tc_port_connected(). It's guaranteed already that we
  won't disconnect legacy ports in that function.
- Add a note about the new intel_ddi_encoder_destroy() hook.
- Reword the commit message after switching to the VBT based detection.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108070
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108924
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181214182703.18865-4-imre.deak@intel.com

It's useful to see at which point a TypeC port gets disconnected, so add
a debug print for it.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181214182703.18865-2-imre.deak@intel.com

In August 2018 the BSPEC changed the ICL port programming sequence to
closely resemble earlier gen programming sequence. Restrict combo phy to
HBR max rate unless eDP panel is connected to port.

v2: remove debug code that Imre found
v3: simplify translation table if-else
v4: edp translation table now based on link rate and low_swing
v5: Misc review comments + r-b
BSpec: 21257
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NClint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1545084827-5776-1-git-send-email-clinton.a.taylor@intel.com

DSC can be supported per DP connector. This patch adds a per connector
debugfs node to expose DSC support capability by the kernel.
The same node can be used from userspace to force DSC enable.

force_dsc_en written through this debugfs node is used to force
DSC even for lower resolutions.

Credits to Ville Syrjala for suggesting the proper locks to be used
and to Lyude Paul for explaining how to use them in this context

v8:
* Add else if (ret) for drm_modeset_lock (Lyude)
v7:
* Get crtc, crtc_state from connector atomic state
and add proper locks and backoff (Ville, Chris Wilson, Lyude)
(Suggested-by: Ville Syrjala <ville.syrjala@linux.intel.com>)
* Use %zu for printing size_t variable (Lyude)
v6:
* Read fec_capable only for non edp (Manasi)
v5:
* Name it dsc sink support and also add
fec support in the same node (Ville)
v4:
* Add missed connector_status check (Manasi)
* Create i915_dsc_support node only for Gen >=10 (manasi)
* Access intel_dp->dsc_dpcd only if its not NULL (Manasi)
v3:
* Combine Force_dsc_en with this patch (Ville)
v2:
* Use kstrtobool_from_user to avoid explicit error checking (Lyude)
* Rebase on drm-tip (Manasi)

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Lyude Paul <lyude@redhat.com>
Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
Reviewed-by: NLyude Paul <lyude@redhat.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181206005407.4698-1-manasi.d.navare@intel.com

Define IS_GEN() similarly to our IS_GEN_RANGE(). but use gen instead of
gen_mask to do the comparison. Now callers can pass then gen as a parameter,
so we don't require one macro for each gen.

The following spatch was used to convert the users of these macros:

@@
expression e;
@@
(
- IS_GEN2(e)
+ IS_GEN(e, 2)
|
- IS_GEN3(e)
+ IS_GEN(e, 3)
|
- IS_GEN4(e)
+ IS_GEN(e, 4)
|
- IS_GEN5(e)
+ IS_GEN(e, 5)
|
- IS_GEN6(e)
+ IS_GEN(e, 6)
|
- IS_GEN7(e)
+ IS_GEN(e, 7)
|
- IS_GEN8(e)
+ IS_GEN(e, 8)
|
- IS_GEN9(e)
+ IS_GEN(e, 9)
|
- IS_GEN10(e)
+ IS_GEN(e, 10)
|
- IS_GEN11(e)
+ IS_GEN(e, 11)
)

v2: use IS_GEN rather than GT_GEN and compare to info.gen rather than
    using the bitmask
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-2-lucas.demarchi@intel.com

Adding a debug log when the DP_AUX_NATIVE_REPLY_ACK is missing
for aksv write. This helps to locate the possible non responding
DP HDCP sinks.

v2:
  Rewritten for readability [Sean Paul]
Signed-off-by: NRamalingam C <ramalingam.c@intel.com>
Reviewed-by: NSean Paul <sean@poorly.run>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1544010283-20223-4-git-send-email-ramalingam.c@intel.com

According to DP spec (2.9.3.1 of DP 1.4) if
EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT is set the addresses in DPCD
02200h through 0220Fh shall contain the DPRX's true capability. These
values will match 00000h through 0000Fh, except for DPCD_REV,
MAX_LINK_RATE, DOWN_STREAM_PORT_PRESENT.

Read from DPCD once for all 3 values as this is an expensive operation.
Spec mentions that all of address space 02200h through 0220Fh should
contain the right information however currently only 3 values can
differ.

There is no address space in the intel_dp->dpcd struct for addresses
02200h through 0220Fh, and since so much of the data is a identical,
simply overwrite the values stored in 00000h through 0000Fh with the
values that can be overwritten from addresses 02200h through 0220Fh.

This patch helps with backward compatibility for devices pre DP1.3.

v2: read only dpcd values which can be affected, remove incorrect check,
split into drm include changes into separate patch, commit message,
verbose debugging statements during overwrite.
v3: white space fixes
v4: make path dependent on DPCD revision > 1.2
v5: split into function, removed DPCD rev check
v6: add debugging prints for early exit conditions
v7 (From Manasi):
* Memcpy, memcmp and debig logging based on sizeof(dpcd_ext) (Jani N)
* Exit early (Jani N)
v8 (From Manasi):
* Get rid of superfluous debug prints (Jani N)
* Print entire base DPCD before memcpy (Jani N)
v9 (From Manasi):
* Add uniform newlines (Rodrigo)

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: NMatt Atwood <matthew.s.atwood@intel.com>
Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
Tested-by: NManasi Navare <manasi.d.navare@intel.com>
Acked-by: NManasi Navare <manasi.d.navare@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181129220058.19636-1-manasi.d.navare@intel.com

Always show the FEC capability as it is initialised to 0 before error.
Fixing,

drivers/gpu/drm/i915/intel_dp.c:3846 intel_dp_get_dsc_sink_cap() warn: inconsistent indenting

Fixes: 08cadae8 ("i915/dp/fec: Cache the FEC_CAPABLE DPCD register")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181120202439.13017-2-chris@chris-wilson.co.uk

Fix the intel_link_compute_m_n in case of display stream
compression. This patch passes the compressed_bpp to
intel_link_compute_m_n if compression is enabled.

Fixes: a4a15777 ("drm/i915/dp: Compute DSC pipe config in atomic check")
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181201010412.32372-1-manasi.d.navare@intel.com

For DP 1.4 and above, Display Stream compression can be
enabled only if Forward Error Correctin can be performed.

Add a crtc state for FEC. Currently, the state
is determined by platform, DP and DSC being
enabled. Moving forward we can use the state
to have error correction on other scenarios too
if needed.

v2:
- Control compression_enable with the fec_enable
parameter in crtc state and with intel_dp_supports_fec()
(Ville)

- intel_dp_can_fec()/intel_dp_supports_fec()(manasi)

v3: Check for FEC support along with setting crtc state.

v4: add checks to intel_dp_source_supports_dsc.(manasi)
- Move intel_dp_supports_fec() closer to
intel_dp_supports_dsc() (Anusha)

v5: Move fec check to intel_dp_supports_dsc(Ville)

v6: Remove warning. rebase.

v7: change crtc state to include DP sink and fec capability
of source.(Manasi)

v8: Set fec_enable in crtc in intel_dp_compute_config().

v9 (From Manasi):
* Combine the !edp and !fec_support check
* Derive dev_priv from intel_dp directly

v10 (From Manasi):
* Rebase
Suggested-by: NVille Syrjala <ville.syrjala@linux.intel.com>
Cc: dri-devel@lists.freedesktop.org
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: NManasi Navare <manasi.d.navare@intel.comk>
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181128202628.20238-14-manasi.d.navare@intel.com

This patch enables decompression support in sink device
before link training and disables the same during the
DDI disabling.

v3 (From manasi):
* Pass bool state to enable/disable (Ville)
v2:(From Manasi)
* Change the enable/disable function to take crtc_state
instead of intel_dp as an argument (Manasi)
* Use the compression_enable flag as part of crtc_state (Manasi)

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Gaurav K Singh <gaurav.k.singh@intel.com>
Signed-off-by: NGaurav K Singh <gaurav.k.singh@intel.com>
Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
Reviewed-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181128202628.20238-6-manasi.d.navare@intel.com

This patches does the following:

1. This patch defines all the DSC parameters as per the VESA
DSC specification. These are stored in the encoder and used
to compute the PPS parameters to be sent to the Sink.
2. Compute all the DSC parameters which are derived from DSC
state of intel_crtc_state.
3. Compute all parameters that are VESA DSC specific

This computation happens in the atomic check phase during
compute_config() to validate if display stream compression
can be enabled for the requested mode.

v8 (From Manasi):
* DEBUG_KMS instead of DRM_ERROR for user triggerable
errors (Ville)
v7: (From Manasi)
* Dont use signed int for rc_range_params (Manasi)
* Mask the range_bpg_offset to use only 6 bits
* Add SPDX identifier (Chris Wilson)
v6 (From Manasi):
* Add a check for line_buf_depth return value (Anusha)
* Remove DRM DSC constants to different patch (Manasi)
v5 (From Manasi):
* Add logic to limit the max line buf depth for DSC 1.1 to 13
as per DSC 1.1 spec
* Fix dim checkpatch warnings/checks

v4 (From Gaurav):
* Rebase on latest drm tip
* rename variable name(Manasi)
* Populate linebuf_depth variable(Manasi)

v3 (From Gaurav):
* Rebase my previous patches on top of Manasi's latest patch
series
* Using >>n rather than /2^n (Manasi)
* Change the commit message to explain what the patch is doing(Gaurav)

Fixed review comments from Ville:
* Don't use macro TWOS_COMPLEMENT
* Mention in comment about the source of RC params
* Return directly from case statements
* Using single asssignment for assigning rc_range_params
* Using <<n rather than *2^n and removing the comments
about the fixed point numbers

v2 (From Manasi):
* Update logic for minor version to consider the dpcd value
and what supported by the HW platform
* Use DRM DSC config struct instead of intel_dp struct
* Move the DSC constants to DRM DSC header file
* Use u16, u8 where bigger data types not needed
* * Compute the DSC parameters as part of DSC compute config
since the computation can fail (Manasi)

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Gaurav K Singh <gaurav.k.singh@intel.com>
Signed-off-by: NGaurav K Singh <gaurav.k.singh@intel.com>
Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
Co-developed-by: NManasi Navare <manasi.d.navare@intel.com>
Reviewed-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181129193827.7914-1-manasi.d.navare@intel.com

DSC params like the enable, compressed bpp, slice count and
dsc_split are added to the intel_crtc_state. These parameters
are set based on the requested mode and available link parameters
during the pipe configuration in atomic check phase.
These values are then later used to populate the remaining DSC
and RC parameters before enbaling DSC in atomic commit.

v15:
* Rebase over drm-tip
v14:
Remove leftovers, use dsc_bpc, refine dsc_compute_config (Ville)
v13:
* Compute DSC bpc only when DSC is req to be enabled (Ville)
v12:
* Override bpp with dsc dpcd color depth (Manasi)
v11:
* Const crtc_state, reject DSC on DP without FEC (Ville)
* Dont set dsc_split to false (Ville)
v10:
* Add a helper for dp_dsc support (Ville)
* Set pipe_config to max bpp, link params for DSC for now (Ville)
* Compute bpp - use dp dsc support helper (Ville)
v9:
* Rebase on top of drm-tip that now uses fast_narrow config
for edp (Manasi)
v8:
* Check for DSC bpc not 0 (manasi)

v7:
* Fix indentation in compute_m_n (Manasi)

v6 (From Gaurav):
* Remove function call of intel_dp_compute_dsc_params() and
invoke intel_dp_compute_dsc_params() in the patch where
it is defined to fix compilation warning (Gaurav)

v5:
Add drm_dsc_cfg in intel_crtc_state (Manasi)

v4:
* Rebase on refactoring of intel_dp_compute_config on tip (Manasi)
* Add a comment why we need to check PSR while enabling DSC (Gaurav)

v3:
* Check PPR > max_cdclock to use 2 VDSC instances (Ville)

v2:
* Add if-else for eDP/DP (Gaurav)

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Gaurav K Singh <gaurav.k.singh@intel.com>
Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
Reviewed-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: NVille Syrjala <ville.syrjala@linux.intel.com>
Acked-by: NJani Nikula <jani.nikula@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181128213621.21391-1-manasi.d.navare@intel.com

When a PSR error happens sink sets the PSR error register and also
set the link status to a error status.
So in the short pulse handling it was returning earlier and doing a
full detection and attempting to retrain but it fails as PSR HW is
in change of the main-link.

Just call intel_psr_short_pulse() before
intel_dp_needs_link_retrain() is not the right fix as
intel_dp_needs_link_retrain() would return true and trigger a full
detection while PSR HW is still in change of main-link.

Check for PSR active is also not safe as it could be inactive due a
frontbuffer invalidate and still doing the PSR exit sequence.

v3: added comment in intel_dp_needs_link_retrain()

Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181121225441.18785-2-jose.souza@intel.com

Some eDP panels do not set a valid sink count value and even for the
ones that sets is should always be one for eDP, that is why it is not
cached in intel_edp_init_dpcd().

But intel_dp_short_pulse() compares the old count with the read one
if there is a mistmatch a full port detection will be executed, what
was happening in the first short pulse interruption of eDP panels
that sets sink count.

Instead of just skip the compasison for eDP panels, lets not read
the sink count at all for eDP.

v2: the previous version of this patch it was caching the sink count
in intel_edp_init_dpcd() but I was pointed out by Ville a patch that
handled a case of a eDP panel that do not set sink count and as sink
count is not used to eDP certification was choosed to just not read
it at all.

Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181121225441.18785-1-jose.souza@intel.com

Conform to function naming in intel_bios.c.

Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181115105237.1237-1-jani.nikula@intel.com

intel_dp_detect() caches the aux_domain in the beginning of the
function as it is used twice, so lets also use it as the aux_domain
don't change in runtime.

v3: returning intel_dp_retrain_link() error insted of
connector_status_disconnected

Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181107235449.32264-1-jose.souza@intel.com

The MG DP mode needs to be configured for Type C static/fixed/legacy
HDMI ports too, the same way as it's configured for Type C
static/fixed/legacy, fix this.

Bspec: 4232, 21735
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Tested-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181102192656.4472-3-imre.deak@intel.com

The MG PHY clock gating needs to be configured for Type C
static/fixed/legacy HDMI ports the same way it's configured for Type C
static/fixed/legacy and aternate mode DP ports, fix this.

Bspec: 4232, 21735
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Tested-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181102192656.4472-2-imre.deak@intel.com

Similar to DSC DPCD registers, let us cache
FEC_CAPABLE register to avoid using stale
values. With this we can avoid aux reads
everytime and instead read the cached values.

v2: Avoid using memset and array for a single
field. (Manasi,Jani)

v3: Print FEC CAPABILITY value. (Manasi)
Suggested-by: NJani Nikula <jani.nikula@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181102041455.15818-1-anusha.srivatsa@intel.com

Use the newly added "max bpc" connector property to limit pipe bpp.

V3: Use drm_connector_state to access the "max bpc" property
V4: Initialize the drm property, add suuport to DP(Ville)
V5: Use the property in the connector and fix CI failure(Ville)
V6: Use the core function to attach max_bpc property, remove the redundant
    clamping of pipe bpp based on connector info
V7: Fix Checkpatch warnings
V9: Cleanup connected_sink_max_bpp and fix initial value in DP(Ville)
V12: Fix debug message(Ville)
V13: Remove the redundant check and simplify the check logic(Stan)
V14: Fix the check in connected_sink_max_bpp(Stan)
v15 (From Manasi): Add missing break (Stan)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Kishore Kadiyala <kishore.kadiyala@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: NRadhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181023014400.16055-1-manasi.d.navare@intel.com

From ICL onwards the AUX power domain may change dynamically based on
whether a DDI/TypeC port is in thunderbolt or non-thunderbolt mode, so
use a helper function instead of a static field to get the current
domain.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101140427.31026-5-imre.deak@intel.com