Start following the usual naming pattern for functions. No functional
changes.
Reviewed-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/e37623750c592c08720f3b340cf85862d0f0ca12.1610127741.git.jani.nikula@intel.com

In a long overdue refactoring, split out all panel sequencer code from
intel_dp.c to new intel_pps.[ch].

The first part is mostly just code movement as-is, without cleanups or
functional changes.

We need to add a vlv_get_dpll() helper to get at the vlv/chv dpll from
pps code.

v2: Rebase.
Reviewed-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/14cc59d5734432ad976cd49ff8efce8fa413e5b2.1610127741.git.jani.nikula@intel.com

Always prefer the kernel types over stdint types in i915.

Cc: Imre Deak <imre.deak@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@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/20210113141158.25513-1-jani.nikula@intel.com

skl_scaler_get_filter_select() isn't static and can't be inline.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210113143726.19701-1-jani.nikula@intel.com

The DP PHY vswing/pre-emphasis level programming the driver does is
related to the DPTX -> first LTTPR link segment only. Accordingly it
should be only programmed when link training the first LTTPR and kept
as-is when training subsequent LTTPRs and the DPRX. For these latter
PHYs the vs/pe levels will be set in response to writing the
DP_TRAINING_LANEx_SET_PHY_REPEATERy DPCD registers (by an upstream LTTPR
TX PHY snooping this write access of its downstream LTTPR/DPRX RX PHY).
The above is also described in DP Standard v2.0 under 3.6.6.1.

While at it simplify and add the LTTPR that is link trained to the debug
message in intel_dp_set_signal_levels().

Fixes: b30edfd8 ("drm/i915: Switch to LTTPR non-transparent mode link training")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201229172201.4155327-2-imre.deak@intel.com

intel_dp_set_signal_levels() is needed for link training, so move it to
intel_dp_link_training.c.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201229172201.4155327-1-imre.deak@intel.com

Enable HDCP 2.2 MST support till Gen12.

Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: NRamalingam C <ramalingam.c@intel.com>
Tested-by: NKarthik B S <karthik.b.s@intel.com>
Signed-off-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-20-anshuman.gupta@intel.com

Authenticate and enable port encryption only once for
an active HDCP 2.2 session, once port is authenticated
and encrypted enable encryption for each stream that
requires encryption on this port.

Similarly disable the stream encryption for each encrypted
stream, once all encrypted stream encryption is disabled,
disable the port HDCP encryption and deauthenticate the port.

v2:
- Add connector details in drm_err. [Ram]
- 's/port_auth/hdcp_auth_status'. [Ram]
- Added a debug print for stream enc.
v3:
- uniformity for connector detail in DMESG. [Ram]

Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: NUma Shankar <uma.shankar@intel.com>
Reviewed-by: NRamalingam C <ramalingam.c@intel.com>
Tested-by: NKarthik B S <karthik.b.s@intel.com>
Signed-off-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-19-anshuman.gupta@intel.com

Add support for HDCP 2.2 DP MST shim callback.
This adds existing DP HDCP shim callback for Link Authentication
and Encryption and HDCP 2.2 stream encryption
callback.

v2:
- Added a WARN_ON() instead of drm_err. [Uma]
- Cosmetic changes. [Uma]
v3:
- 's/port_data/hdcp_port_data' [Ram]
- skip redundant link check. [Ram]
v4:
- use pipe instead of port to access HDCP2_STREAM_STATUS

Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: NUma Shankar <uma.shankar@intel.com>
Reviewed-by: NRamalingam C <ramalingam.c@intel.com>
Tested-by: NKarthik B S <karthik.b.s@intel.com>
Signed-off-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-18-anshuman.gupta@intel.com

Add HDCP 2.2 DP MST HDCP2_STREAM_STATUS
and HDCP2_AUTH_STREAM register in i915_reg header.

B.Spec: 21780
B.Spec: 14410
B.Spec: 50573

v2
- Modified naming convention of HDCP2_STREAM_STATUS
  for pre-gen12 platforms inline with B.Spec.

Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: NUma Shankar <uma.shankar@intel.com>
Reviewed-by: NRamalingam C <ramalingam.c@intel.com>
Tested-by: NKarthik B S <karthik.b.s@intel.com>
Signed-off-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-17-anshuman.gupta@intel.com

This requires for HDCP 2.2 MST check link.
As for DP/HDMI shims check_2_2_link retrieves the connector
from dig_port, this is not sufficient or DP MST connector,
there can be multiple DP MST topology connector associated
with same dig_port.

Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: NUma Shankar <uma.shankar@intel.com>
Reviewed-by: NRamalingam C <ramalingam.c@intel.com>
Tested-by: NKarthik B S <karthik.b.s@intel.com>
Signed-off-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-16-anshuman.gupta@intel.com

Add support for multiple mst stream in hdcp port data
which will be used by RepeaterAuthStreamManage msg and
HDCP 2.2 security f/w for m' validation.

Security f/w doesn't have any provision to mark the stream_type
for each stream separately, it just take single input of
stream_type while authenticating the port and applies the
same stream_type to all streams. So driver mark each stream_type
with common highest supported content type for all streams
in DP MST Topology.

Security f/w supports RepeaterAuthStreamManage msg and m'
validation only once during port authentication and encryption.
Though it is not compulsory, security fw should support dynamic
update of content_type and should support RepeaterAuthStreamManage
msg and m' validation whenever required.

v2:
- Init the hdcp port data k for HDMI/DP SST stream.
v3:
- Cosmetic changes. [Uma]
v4:
- 's/port_auth/hdcp_port_auth'. [Ram]
- Commit log improvement.
v5:
- Comment and commit log improvement. [Ram]
v6:
- Check first connector connected status before intel_encoder_is_mst
  to avoid any NULL pointer dereference.

Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: NUma Shankar <uma.shankar@intel.com>
Reviewed-by: NRamalingam C <ramalingam.c@intel.com>
Tested-by: NKarthik B S <karthik.b.s@intel.com>
Signed-off-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Tested-by: NJuston Li <juston.li@intel.com>
Acked-by: NJuston Li <juston.li@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-15-anshuman.gupta@intel.com

Fix the size of WIRED_REPEATER_AUTH_STREAM_REQ cmd buffer size.
It is based upon the actual number of MST streams and size
of wired_cmd_repeater_auth_stream_req_in.
Excluding the size of hdcp_cmd_header.

v2:
- hdcp_cmd_header size annotation nitpick. [Tomas]

Cc: Tomas Winkler <tomas.winkler@intel.com>
Cc: Ramalingam C <ramalingam.c@intel.com>
Acked-by: NTomas Winkler <tomas.winkler@intel.com>
Reviewed-by: NUma Shankar <uma.shankar@intel.com>
Reviewed-by: NRamalingam C <ramalingam.c@intel.com>
Tested-by: NKarthik B S <karthik.b.s@intel.com>
Signed-off-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-13-anshuman.gupta@intel.com

hdcp_port_data is specific to a port on which HDCP
encryption is getting enabled, so encapsulate it to
intel_digital_port.
This will be required to enable HDCP 2.2 stream encryption.

v2:
- 's/port_data/hdcp_port_data'. [Ram]

Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: NUma Shankar <uma.shankar@intel.com>
Reviewed-by: NRamalingam C <ramalingam.c@intel.com>
Tested-by: NKarthik B S <karthik.b.s@intel.com>
Signed-off-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-12-anshuman.gupta@intel.com

Pass dig_port as an argument to intel_hdcp_init()
and intel_hdcp2_init().
This will be required for HDCP 2.2 stream encryption.

Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: NUma Shankar <uma.shankar@intel.com>
Reviewed-by: NRamalingam C <ramalingam.c@intel.com>
Tested-by: NKarthik B S <karthik.b.s@intel.com>
Signed-off-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-11-anshuman.gupta@intel.com

Enable HDCP 1.4 over DP MST for Gen12.

v2:
- Enable HDCP for <= Gen12 platforms. [Ram]
v3:
- Connector detials in debug msg. [Ram]

Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: NRamalingam C <ramalingam.c@intel.com>
Tested-by: NKarthik B S <karthik.b.s@intel.com>
Signed-off-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-10-anshuman.gupta@intel.com

Enable HDCP 1.4 DP MST stream encryption.

Enable stream encryption once encryption is enabled on
the DP transport driving the link for each stream which
has requested encryption.

Disable stream encryption for each stream that no longer
requires encryption before disabling HDCP encryption on
the link.

v2:
- Added debug print for stream encryption.
- Disable the hdcp on port after disabling last stream
  encryption.
v3:
- Cosmetic change, removed the value less comment. [Uma]
v4:
- Split the Gen12 HDCP enablement patch. [Ram]
- Add connector details in drm_err.
v5:
- uniformity for connector detail in DMESG. [Ram]
- comments improvement. [Ram]

Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: NUma Shankar <uma.shankar@intel.com>
Reviewed-by: NRamalingam C <ramalingam.c@intel.com>
Tested-by: NKarthik B S <karthik.b.s@intel.com>
Signed-off-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-9-anshuman.gupta@intel.com

Both HDCP_{1.x,2.x} requires to select/deselect Multistream HDCP bit
in TRANS_DDI_FUNC_CTL in order to enable/disable stream HDCP
encryption over DP MST Transport Link.

HDCP 1.4 stream encryption requires to validate the stream encryption
status in HDCP_STATUS_{TRANSCODER,PORT} register driving that link
in order to enable/disable the stream encryption.

Both of above requirement are same for all Gen with respect to
B.Spec Documentation.

v2:
- Cosmetic changes function name, error msg print and
  stream typo fixes. [Uma]
v3:
- uniformity for connector detail in DMESG. [Ram]

Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: NUma Shankar <uma.shankar@intel.com>
Reviewed-by: NRamalingam C <ramalingam.c@intel.com>
Tested-by: NKarthik B S <karthik.b.s@intel.com>
Signed-off-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-8-anshuman.gupta@intel.com

DP MST stream encryption status requires time of a link frame
in order to change its status, but as there were some HDCP
encryption timeout observed earlier, it is safer to use
ENCRYPT_STATUS_CHANGE_TIMEOUT_MS timeout for stream status too,
it requires to move the macro to a header.
It will be used by both HDCP{1.x,2.x} stream status timeout.

Related: 'commit 7e90e8d0 ("drm/i915: Increase timeout for Encrypt
status change")'
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: NUma Shankar <uma.shankar@intel.com>
Reviewed-by: NRamalingam C <ramalingam.c@intel.com>
Tested-by: NKarthik B S <karthik.b.s@intel.com>
Signed-off-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-7-anshuman.gupta@intel.com

Gen12 has H/W delta with respect to HDCP{1.x,2.x} display engine
instances lies in Transcoder instead of DDI as in Gen11.

This requires hdcp driver to use mst_master_transcoder for link
authentication and stream transcoder for stream encryption
separately.

This will be used for both HDCP 1.4 and HDCP 2.2 over DP MST
on Gen12.

Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: NUma Shankar <uma.shankar@intel.com>
Reviewed-by: NRamalingam C <ramalingam.c@intel.com>
Tested-by: NKarthik B S <karthik.b.s@intel.com>
Signed-off-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-6-anshuman.gupta@intel.com

There can be situation when DP MST connector is created without
mst modeset being done, in those cases connector->encoder will be
NULL. MST connector->encoder initializes after modeset.
Don't enable HDCP in such cases to prevent any crash.

Cc: Ramalingam C <ramalingam.c@intel.com>
Cc: Juston Li <juston.li@intel.com>
Tested-by: NKarthik B S <karthik.b.s@intel.com>
Reviewed-by: NRamalingam C <ramalingam.c@intel.com>
Signed-off-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-5-anshuman.gupta@intel.com

Handle CP_IRQ in DEVICE_SERVICE_IRQ_VECTOR_ESI0
It requires to call intel_hdcp_handle_cp_irq() in case
of CP_IRQ is triggered by a sink in DP-MST topology.

Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: NUma Shankar <uma.shankar@intel.com>
Reviewed-by: NRamalingam C <ramalingam.c@intel.com>
Tested-by: NKarthik B S <karthik.b.s@intel.com>
Signed-off-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-4-anshuman.gupta@intel.com

Get DRM connector reference count while scheduling a prop work
to avoid any possible destroy of DRM connector when it is in
DRM_CONNECTOR_REGISTERED state.

Fixes: a6597faa ("drm/i915: Protect workers against disappearing connectors")
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: NUma Shankar <uma.shankar@intel.com>
Reviewed-by: NRamalingam C <ramalingam.c@intel.com>
Tested-by: NKarthik B S <karthik.b.s@intel.com>
Signed-off-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-3-anshuman.gupta@intel.com

When crtc state need_modeset is true it is not necessary
it is going to be a real modeset, it can turns to be a
fastset instead of modeset.
This turns content protection property to be DESIRED and hdcp
update_pipe left with property to be in DESIRED state but
actual hdcp->value was ENABLED.

This issue is caught with DP MST setup, where we have multiple
connector in same DP_MST topology. When disabling HDCP on one of
DP MST connector leads to set the crtc state need_modeset to true
for all other crtc driving the other DP-MST topology connectors.
This turns up other DP MST connectors CP property to be DESIRED
despite the actual hdcp->value is ENABLED.
Above scenario fails the DP MST HDCP IGT test, disabling HDCP on
one MST stream should not cause to disable HDCP on another MST
stream on same DP MST topology.

v2:
- Fixed connector->base.registration_state == DRM_CONNECTOR_REGISTERED
  WARN_ON.

v3:
- Commit log improvement. [Uma]
- Added a comment before scheduling prop_work. [Uma]

Fixes: 33f9a623 ("drm/i915/hdcp: Update CP as per the kernel internal state")
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: NUma Shankar <uma.shankar@intel.com>
Reviewed-by: NRamalingam C <ramalingam.c@intel.com>
Tested-by: NKarthik B S <karthik.b.s@intel.com>
Signed-off-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-2-anshuman.gupta@intel.com

DG1's vswing tables are the same for eDP and HDMI but have slight
differences from ICL/TGL for DP.

v2:
 - Use a "_hbr2_hbr3" suffix on the table name to make it more clear
   that the same table is used for both HBR2 and HBR3 link rates.
   (Swathi)

Bspec: 49291
Cc: Clinton Taylor <Clinton.A.Taylor@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: Swathi Dhanavanthri <swathi.dhanavanthri@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210108222528.1954514-1-matthew.d.roper@intel.comReviewed-by: NClint Taylor <Clinton.A.Taylor@intel.com>

Some new eDP panels don't like to operate at the max parameters, and
instead we need to go for an optimal confiugration. That unfortunately
doesn't work with older eDP panels which are generally only guaranteed
to work at the max parameters.

To solve these two conflicting requirements let's start with the optimal
setup, and if that fails we start again with the max parameters. The
downside is probably an extra modeset when we switch strategies but
I don't see a good way to avoid that.

For a bit of history we first tried to go for the fast+narrow in
commit 7769db58 ("drm/i915/dp: optimize eDP 1.4+ link config
fast and narrow"). but that had to be reverted due to regression
on older panels in commit f11cb1c1 ("drm/i915/dp: revert back
to max link rate and lane count on eDP"). So now we try to get
the best of both worlds by using both strategies.

v2: Deal with output_bpp and uapi vs. hw state split
    Reword some comments
v3: Rebase

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Albert Astals Cid <aacid@kde.org> # v5.0 backport
Cc: Emanuele Panigati <ilpanich@gmail.com> # v5.0 backport
Cc: Matteo Iervasi <matteoiervasi@gmail.com> # v5.0 backport
Cc: Timo Aaltonen <tjaalton@ubuntu.com>
Cc: Kai-Heng Feng <kai.heng.feng@canonical.com>
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=105267
References: https://bugs.freedesktop.org/show_bug.cgi?id=109959
References: https://gitlab.freedesktop.org/drm/intel/issues/272Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210107182026.24848-1-ville.syrjala@linux.intel.com

Eliminate checkpatch warnings from intel_cursor.c:
WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
WARNING: Possible repeated word: 'by'
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201110175624.3524-2-ville.syrjala@linux.intel.comReviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>

There was some misinterpretation of specification, when DDIX_USED is
set, the next bit means 0 for DP and 1 for HDMI.

Anyways this misinterpretation is not causing any issues, this change
is just to comply with specification.
Also as for us it do not matters if it is HDMI or DP, not checking the
port type that HTI is using.

Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210108134802.21280-1-jose.souza@intel.com

The pch_get_backlight(), lpt_get_backlight(), and lpt_set_backlight()
functions operate directly on the hardware registers. If inverting the
value is needed, using intel_panel_compute_brightness(), it should only
be done in the interface between hardware registers and
panel->backlight.level.

The CPU mode takeover code added in commit 5b1ec9ac
("drm/i915/backlight: Fix backlight takeover on LPT, v3.") reads the
hardware register and converts to panel->backlight.level correctly,
however the value written back should remain in the hardware register
"domain".

This hasn't been an issue, because GM45 machines are the only known
users of i915.invert_brightness and the brightness invert quirk, and
without one of them no conversion is made. It's likely nobody's ever hit
the problem.

Fixes: 5b1ec9ac ("drm/i915/backlight: Fix backlight takeover on LPT, v3.")
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Lyude Paul <lyude@redhat.com>
Cc: <stable@vger.kernel.org> # v5.1+
Reviewed-by: NLyude Paul <lyude@redhat.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210108152841.6944-1-jani.nikula@intel.com

As with the regular suspend paths, also disable the wakeref assertions
as we disable the driver during shutdown.
Reported-by: NHans de Goede <hdegoede@redhat.com>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2899
Fixes: fe0f1e3b ("drm/i915: Shut down displays gracefully on reboot")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Tested-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210104203905.19248-1-chris@chris-wilson.co.uk

We need a power_domain wakeref in pps_{lock,unlock} to prevent
a race while resetting pps state in intel_power_sequencer_reset().

intel_power_sequencer_reset() need a pps_mutex to access pps_pipe
but it can't grab pps_mutex due to deadlock with power_well
functions are called while holding pps_mutex.
intel_power_sequencer_reset() is called by power_well function
associated with legacy platforms like vlv and chv therefore re-use
the POWER_DOMAIN_DISPLAY_CORE power domain, which only used
by vlv and chv display power domain.

This will avoids the unnecessary noise of unrelated power wells
in pps_{lock,unlock}.

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Acked-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210107112500.16216-1-anshuman.gupta@intel.com

drm/i915/dsi: Use unconditional msleep for the panel_on_delay when there is no reset-deassert MIPI-sequence

Commit 25b4620e ("drm/i915/dsi: Skip delays for v3 VBTs in vid-mode")
added an intel_dsi_msleep() helper which skips sleeping if the
MIPI-sequences have a version of 3 or newer and the panel is in vid-mode;
and it moved a bunch of msleep-s over to this new helper.

This was based on my reading of the big comment around line 730 which
starts with "Panel enable/disable sequences from the VBT spec.",
where the "v3 video mode seq" column does not have any wait t# entries.

Given that this code has been used on a lot of different devices without
issues until now, it seems that my interpretation of the spec here is
mostly correct.

But now I have encountered one device, an Acer Aspire Switch 10 E
SW3-016, where the panel will not light up unless we do actually honor the
panel_on_delay after exexuting the MIPI_SEQ_PANEL_ON sequence.

What seems to set this model apart is that it is lacking a
MIPI_SEQ_DEASSERT_RESET sequence, which is where the power-on
delay usually happens.

Fix the panel not lighting up on this model by using an unconditional
msleep(panel_on_delay) instead of intel_dsi_msleep() when there is
no MIPI_SEQ_DEASSERT_RESET sequence.

Fixes: 25b4620e ("drm/i915/dsi: Skip delays for v3 VBTs in vid-mode")
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201118124058.26021-1-hdegoede@redhat.com

The bspec has been updated with new vswing programming for RKL DP.  No
data is provided for HDMI or eDP, so for now we'll continue to assume
that those are the same as TGL.

Bspec: 49291
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201218040535.45492-1-matthew.d.roper@intel.comReviewed-by: NSwathi Dhanavanthri <swathi.dhanavanthri@intel.com>

After boot into kernel. Driver configured ddc pin mapping based on
predefined table in parse_ddi_port(). Now driver configure rkl
ddc pin mapping depends on icp_ddc_pin_map[]. Then this table will
give incorrect gmbus port number to cause HDMI can't work.

Refer to commit cd0a8952 ("drm/i915/rkl: Add DDC pin mapping").
Create two ddc pin table for rkl TGP and CMP pch. Then HDMI can
works properly on rkl.

v2: update patch based on latest dinq branch.
v3: update ddc table for RKL+TGP sku.
    RKL+CNP sku will load cnp_ddc_pin_map[] setting.
v4: modify the if/else judgment to avoid nesting.
v5: fix typo in v4.

Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Aditya Swarup <aditya.swarup@intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Cooper Chiou <cooper.chiou@intel.com>
Cc: Khaled Almahallawy <khaled.almahallawy@intel.com>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2577Signed-off-by: NLee Shawn C <shawn.c.lee@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NLyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201117142629.28729-1-shawn.c.lee@intel.com

It programs Plane's calculated x, y, offset to Plane SF register.
It does the calculation of x and y offsets using
skl_calc_main_surface_offset().

v3: Update commit message

Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Reviewed-by: NGwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Tested-by: NGwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210104205654.238928-4-jose.souza@intel.com

The calculation the offsets of the main surface will be needed by PSR2
selective fetch code so here splitting and exporting it.
No functional changes were done here.

v3: Rebased

Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Reviewed-by: NGwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Tested-by: NGwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210104205654.238928-3-jose.souza@intel.com

Now using plane damage clips property to calcualte the damaged area.
Selective fetch only supports one region to be fetched so software
needs to calculate a bounding box around all damage clips.

Now that we are not complete fetching each plane, there is another
loop needed as all the plane areas that intersect with the pipe
damaged area needs to be fetched from memory so the complete blending
of all planes can happen.

v2:
- do not shifting new_plane_state->uapi.dst only src is in 16.16 format

v4:
- setting plane selective fetch area using the whole pipe damage area
- mark the whole plane area damaged if plane visibility or alpha
changed

v5:
- taking in consideration src.y1 in the damage coordinates
- adding to the pipe damaged area planes that were visible but are
invisible in the new state

v6:
- consider old state plane coordinates when visibility changes or it
moved to calculate damaged area
- remove from damaged area the portion not in src clip

v7:
- intersec every damage clip with src to minimize damaged area

v8:
- adjust pipe_damaged area to 4 lines grouping
- adjust calculation now that is understood that uapi.src is the
framebuffer coordinates that plane will start to fetch from

v9:
- Only add plane dst or src to damaged_area if visible
- Early skip plane damage calculation if it was not visible in old and
new state

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Reviewed-by: NGwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210104205654.238928-2-jose.souza@intel.com

Because clk_disable_unprepare() already checked NULL clock parameter,
so the additional check is unnecessary, just remove them.
Signed-off-by: NXu Wang <vulab@iscas.ac.cn>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Because clk_disable_unprepare() already checked NULL clock parameter,
so the additional check is unnecessary, just remove them.
Signed-off-by: NXu Wang <vulab@iscas.ac.cn>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

A non-const structure containing function pointers is a possible attack
vector. The drm_driver structure is already const in most drivers, but
there are a few exceptions. Constify the structure in the drivers that
don't need to modify at, as a low-hanging fruit. The rest of the drivers
will need a more complex fix.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>