drm/i915/hdcp: Allocate stream id after HDCP AKE stage

Allocate stream id after HDCP AKE stage and not before so that it
can also be done during link integrity check.
Right now for MST scenarios LIC fails after hdcp enablement for this
reason.

--v2
-no need for else block in prepare_streams function [Ankit]

--v3
-remove intel_hdcp argument from required_content_stream function
[Ankit]

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240226063051.1685326-6-suraj.kandpal@intel.com

drm/i915/hdcp: Don't enable HDCP1.4 directly from check_link

Whenever LIC fails instead of moving from ENABLED to DESIRED
CP property we directly enable HDCP1.4 without informing the userspace
of this failure in link integrity check.
Now we will just update the value to DESIRED send the event to
userspace and then continue with the normal flow of HDCP enablement.

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240226063051.1685326-5-suraj.kandpal@intel.com

drm/i915/hdcp: Don't enable HDCP2.2 directly from check_link

Whenever LIC fails instead of moving from ENABLED to DESIRED
CP property we directly enable HDCP2.2 without informing the userspace
of this failure in link integrity check.
Now we will just update the value to DESIRED send the event to
userspace and then continue with the normal flow of HDCP enablement.

--v2
-Don't change the function prototype in this function [Ankit]

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240226063051.1685326-4-suraj.kandpal@intel.com

drm/i915/hdcp: Add new remote capability check shim function

Create a remote HDCP capability shim function which can read the
remote monitor HDCP capability when in MST configuration.

--v2
-Add an assertion to make sure only mst encoder call this remote_cap
function [Ankit]

--v3
-rename remote_hdcp_cap to remote_hdcp_capability [Jani]

--v4
-fix hdcp2_prerequisite check condition
-Move intel_dp_hdcp_get_remote_capability to dp_mst shim instead of
having it in dp shim [Ankit]

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240226051017.1652970-2-suraj.kandpal@intel.com

drm/i915/hdcp: Rename hdcp capable functions

Rename hdcp_capable and hdcp_2_2_capable to hdcp_get_capability
and hdcp_2_2_get_capability to properly reflect what these functions
are doing.

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240223081453.1576918-7-suraj.kandpal@intel.com

drm/i915/hdcp: Move source hdcp2 checks into its own function

Move checks on the source side for HDCP2.2 into its own function
so that they can be used in the HDCP remote capability check
function.

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240223081453.1576918-4-suraj.kandpal@intel.com

drm/i915/hdcp: Fail Repeater authentication if Type1 device not present

Fail repeater authentication step in case RX_INFO indicates
HDCP1.x or HDCP2.0/2.1 device is present downstream in repeater
topology and content type set by userspace is Type1.

--v2
-Fix build error.

--v3
-remove mst encoder check as branch device also act as repeater

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231215050915.2070119-1-suraj.kandpal@intel.com

drm/i915/hdcp: fix intel_hdcp_get_repeater_ctl() error return value

intel_hdcp_get_repeater_ctl() is supposed to return unsigned register
contents. Returning negative error values is unexpected, and none of the
callers check for that.

Sort of fix the error cases by returning 0. I don't think we should hit
these cases anyway, and using 0 for the registers is safer than
0xffffffea (-EINVAL).

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231219104746.1065431-2-jani.nikula@intel.com

drm/i915/hdcp: unify connector logging format

It's customary to debug log connectors using [CONNECTOR:%d:%s]
format. Make the HDCP code follow suit.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231219104746.1065431-1-jani.nikula@intel.com

drm/i915/hdcp: Add more conditions to enable hdcp

When we dock a monitor we end up with a enable and disable connector
cycle but if hdcp content is running we get the userspace in
enabled state and driver maintaining a undesired state which causes
the content to stop playing and we only enable hdcp if the userspace
state in desired. This patch fixes that.

--v2
-Move code to intel_hdcp [Jani]

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231026121139.987437-4-suraj.kandpal@intel.com

drm/i915/hdcp: Convert intel_hdcp_enable to a blanket function

Let's convert intel_hdcp_enable to a blanket function
which just has some conditions which needs to be checked
before connectors enable hdcp.
This cleans up code and avoids code duplication.

--v3
-Keep function name as intel_hdcp_enable() [Jani]

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231026121139.987437-3-suraj.kandpal@intel.com

drm/i915/hdcp: Rename HCDP 1.4 enablement function

Rename hdcp 1.4 enablement function from _intel_hdcp_enable to
intel_hdcp1_enable to better represent what version of hdcp is
being enabled

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231026121139.987437-2-suraj.kandpal@intel.com

drm/i915/hdcp: Move checks for gsc health status

Move checks for gsc components required for HDCP 2.2
to work into intel_hdcp_gsc.c. This will also help
with XE refactor on HDCP's side.

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231009095537.653619-2-suraj.kandpal@intel.com

drm/i915/hdcp: Use intel_connector as argument for hdcp_2_2_capable

Use intel_connector as argument instead of intel_digital_port in
hdcp_2_2_capable function and dig_port can be later derived from
connector. This will help with getting the correct hdcp version of
particular monitor in a MST setup.

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230830073437.666263-2-suraj.kandpal@intel.com

drm/i915/hdcp: Use intel_connector argument in intel_hdcp_shim

Update intel_hdcp_shim funcs specifically read_2_2_message,
write_2_2_message and config_stream_type to use intel_connector
argument instead of intel_digital_port as this will help in getting
correct aux later for dp mst scenarios also already hdcp funcs
derive digital_port from connector and then many funcs again get back
the connector from dig_port which doesn't seem right.
Connector specific hdcp functions can derive dig_port on need basis.

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230828063401.600414-2-suraj.kandpal@intel.com

drm/i915/hdcp: Add a debug statement at hdcp2 capability check

Add a debug statement at hdcp2 capability check which indicates if
GSC CS is causing hdcp2 incapability

--v2
-correcttypo in commit header

--v3
-correct the other typo in commit header [Jani]

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230621085453.1996166-1-suraj.kandpal@intel.com

drm/i915/hdcp: Assign correct hdcp content type

Currently hdcp->content_type is being assigned the content_type field
in drm_connector_state which is wrong and instead it needs to be
assigned hdcp_content_type field from drm_connector_state

Fixes: 4c4279a8d58d ("drm/i915/hdcp: add intel_atomic_state argument to hdcp_enable function")
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Animesh Manna <animesh.manna@intel.com>

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230622083254.2057102-1-suraj.kandpal@intel.com

drm/i915/hdcp: Assign correct hdcp content type

Currently hdcp->content_type is being assigned the content_type field
in drm_connector_state which is wrong and instead it needs to be
assigned hdcp_content_type field from drm_connector_state

Fixes: 4c4279a8d58d ("drm/i915/hdcp: add intel_atomic_state argument to hdcp_enable function")
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Animesh Manna <animesh.manna@intel.com>

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230622083254.2057102-1-suraj.kandpal@intel.com
(cherry picked from commit 86a124424efce353778c4fab355e185e4781b63e)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

drm/i915: add a dedicated workqueue inside drm_i915_private

In order to avoid flush_scheduled_work() usage, add a dedicated
workqueue in the drm_i915_private structure. In this way, we don't
need to use the system queue anymore.

This change is mostly mechanical and based on Tetsuo's original
patch[1].

v6 by Jani:
- Also create unordered_wq for mock device

Link: https://patchwork.freedesktop.org/series/114608/ [1]
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/c816ebe17ef08d363981942a096a586a7658a65e.1686231190.git.jani.nikula@intel.com

drm/i915/hdcp: Rename comp_mutex to hdcp_mutex

Rename comp_mutex to hdcp_mutex as it does not just
protect component related variables which was a terminology
used when hdcp was to be binded as a mei component from MTL
we use gsc cs which does not use the component binding path
for HDCP.

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230529110740.1522985-4-suraj.kandpal@intel.com

drm/i915/hdcp: Move away from master naming to arbiter

Rename variables to move away from master convention to
arbiter
%s/hdcp.master/hdcp.arbiter
%s/i915_hdcp_master/i915_hdcp_arbiter
%s/comp_master/comp_arbiter

--v2
- delete i915_hdcp_comp_master redundant declaration [Chaitanya]
- use %s/foo/bar/ format in commit message to show changes [Chaitanya]

--v3
- replace i915_hdcp_comp_master declaration with i915_hdcp_arbiter
to avoid any compile fail with old compilers [Chaitanya]

Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230529110740.1522985-3-suraj.kandpal@intel.com

drm/i915/hdcp: Rename dev_priv to i915

Rename dev_priv to i915 to keep up with latest code standards.

Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230529110740.1522985-2-suraj.kandpal@intel.com

drm/i915/display: Move display runtime info to display structure

Move the runtime info specific to display into display-specific
structures as has already been done with the constant display info.

v2:
- Rename __runtime to __runtime_defaults for more clarity on the
purpose. (Andrzej)
- Move introduction of DISPLAY_INFO() to previous patch. (Andrzej)
- Drop NO_DISPLAY macro. (Andrzej)
v3:
- Use "{}" instead of "{ 0 }" for empty struct init. (Jani)

Cc: Andrzej Hajda <andrzej.hajda@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230523195609.73627-4-matthew.d.roper@intel.com

drm/i915/hdcp: Fill hdcp2_streamid_type and k in appropriate places

stream_id and k(no of streams) should be set in
intel_hdcp_set_content_streams. stream_type should be set in
intel_hdcp_required_content_stream.

--v5
-add missing stream_id assignment [Ankit]

Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230515112726.689116-1-suraj.kandpal@intel.com

drm/i915/hdcp: Fix modeset locking issue in hdcp mst

Since topology state is being added to drm_atomic_state now all
drm_modeset_lock required are being taken from core. This raises
an issue when we try to loop over connector and assign vcpi id to
our streams as we did not have atomic state to derive acquire_ctx
from. We fill in stream info if dpmst encoder is found before
enabling hdcp. intel_hdcp_required_stream will be broken which
will only set the content type.

--v2
-move prepare streams to beginning of intel_hdcp_enable to avoid
checking of mst encoder twice [Ankit]

--v3
-break intel_required_content_stream to two part and set the stream_id
at the beginning [Ankit]

--v4
-change return types for intel_hdcp_prepare_stream and
intel_hdcp_required content_stream [Ankit]
-rename intel_hdcp_set_content_stream to
intel_hdcp_set_stream [Ankit]
-place intel_hdcp_set_streams above caller [Ankit]

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230515103225.688830-4-suraj.kandpal@intel.com

drm/i915/hdcp: Remove enforce_type0 check outside loop

Remove enforce_type0 check outside the loop since it
does not make sense to keep it there as we use the same
digport and continue checking it again and again

Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230515103225.688830-3-suraj.kandpal@intel.com

drm/i915/hdcp: add intel_atomic_state argument to hdcp_enable function

Pass all the parameter in intel_encoder->enable()
to intel_hdcp_enable as we need intel_atomic_state
later down to get acquire_ctx.

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230515103225.688830-2-suraj.kandpal@intel.com

drm/i915/hdcp: Check if media_gt exists

Check if media_gt exists if we are using gsc cs

--v2
-correct typo [Ankit]
-assign gsc variable if gt exists [Ankit]

--v3
-declare gsc and gt variables in if block [Ankit]

--v4
-add fixes tag [Ankit]

Fixes: 883631771038 ("drm/i915/mtl: Add HDCP GSC interface")
Cc: Tomas Winkler <tomas.winkler@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Anshuman Gupta <anshuman.gupta@intel.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230505041512.585486-1-suraj.kandpal@intel.com
(cherry picked from commit 6986f05b557bf1efea5bac8dbdffb7ee89d0cf77)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

drm/i915/hdcp: Check if media_gt exists

Check if media_gt exists if we are using gsc cs

--v2
-correct typo [Ankit]
-assign gsc variable if gt exists [Ankit]

--v3
-declare gsc and gt variables in if block [Ankit]

--v4
-add fixes tag [Ankit]

Fixes: 883631771038 ("drm/i915/mtl: Add HDCP GSC interface")
Cc: Tomas Winkler <tomas.winkler@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Anshuman Gupta <anshuman.gupta@intel.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230505041512.585486-1-suraj.kandpal@intel.com

drm/i915/mtl: Add HDCP GSC interface

MTL uses GSC command streamer i.e gsc cs to send HDCP/PXP commands
to GSC f/w. It requires to keep hdcp display driver
agnostic to content protection f/w (ME/GSC fw) in the form of
i915_hdcp_fw_ops generic ops.

Adding HDCP GSC CS interface by leveraging the i915_hdcp_fw_ops generic
ops instead of I915_HDCP_COMPONENT as integral part of i915.

Adding checks to see if GSC is loaded and proxy is setup

--v6
-dont change the license date in same patch series [Jani]
-fix the license year {Jani]

--v8
-remove stale comment [Ankit]
-get headers in alphabetical order [Ankit]
-fix hdcp2_supported check [Ankit]

--v9
-remove return statement from hdcp_gsc_fini [Ankit]

Cc: Tomas Winkler <tomas.winkler@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230316092927.668980-7-suraj.kandpal@intel.com

drm/i915/hdcp: HDCP2.x Refactoring to agnostic hdcp

There are more than 1 type of content protection security firmware.
Make the name generic
%s/_mei_/_

--v3
-Changing names to drop cp_fw to make naming more agnostic[Jani]

--v4
-remove header reference in intel_display_core.h [Uma]
-fix commit message and prefix drm [Uma]

Cc: Tomas Winkler <tomas.winkler@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230316092927.668980-4-suraj.kandpal@intel.com

drm/i915/hdcp: Use generic names for HDCP helpers and structs

pre MTL we interact with mei interface to talk to
firmware and enable CP but going forward we will talk to gsc cs
because of which we are making all names for HDCP helpers and
structures generic as either mei or gsc cs maybe used.

Change the include/drm/i915_mei_hdcp_interface.h to
include/drm/i915_hdcp_interface.h

Change the i915_hdcp_interface.h header naming convention to
suit generic f/w type.
%s/MEI_/HDCP_
%s/mei_dev/hdcp_dev

Change structure name Accordingly.
%s/i915_hdcp_comp_master/i915_hdcp_master
%s/i915_hdcp_component_ops/i915_hdcp_ops

--v6
-make each patch build individually [Jani]

--v8
-change ME FW to ME/GSC FW [Ankit]
-fix formatting issue [Ankit]

--v9
-fix commit message and header [Uma]

--v10
-rename comp variable [Uma]

Cc: Tomas Winkler <tomas.winkler@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Acked-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230316092927.668980-3-suraj.kandpal@intel.com

drm/i915/display/hdmi: use intel_de_rmw if possible

The helper makes the code more compact and readable.

Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230105131046.2173431-6-andrzej.hajda@intel.com

drm/i915: move and group hdcp under display.hdcp

Move display hdcp related members under drm_i915_private display
sub-struct.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1083f5a58cce1507bd19bf7f98bf85e9351b741e.1661779055.git.jani.nikula@intel.com

drm/i915: move has_hdcp to runtime info

If it's modified runtime, it's runtime info.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Maarten Lankhort <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/b146250e02a4b2f086e7e587dd1742589e0e8fba.1660910433.git.jani.nikula@intel.com

drm/display/dp_mst: Move all payload info into the atomic state

Now that we've finally gotten rid of the non-atomic MST users leftover in
the kernel, we can finally get rid of all of the legacy payload code we
have and move as much as possible into the MST atomic state structs. The
main purpose of this is to make the MST code a lot less confusing to work
on, as there's a lot of duplicated logic that doesn't really need to be
here. As well, this should make introducing features like fallback link
retraining and DSC support far easier.

Since the old payload code was pretty gnarly and there's a Lot of changes
here, I expect this might be a bit difficult to review. So to make things
as easy as possible for reviewers, I'll sum up how both the old and new
code worked here (it took me a while to figure this out too!).

The old MST code basically worked by maintaining two different payload
tables - proposed_vcpis, and payloads. proposed_vcpis would hold the
modified payload we wanted to push to the topology, while payloads held the
payload table that was currently programmed in hardware. Modifications to
proposed_vcpis would be handled through drm_dp_allocate_vcpi(),
drm_dp_mst_deallocate_vcpi(), and drm_dp_mst_reset_vcpi_slots(). Then, they
would be pushed via drm_dp_mst_update_payload_step1() and
drm_dp_mst_update_payload_step2().

Furthermore, it's important to note how adding and removing VC payloads
actually worked with drm_dp_mst_update_payload_step1(). When a VC payload
is removed from the VC table, all VC payloads which come after the removed
VC payload's slots must have their time slots shifted towards the start of
the table. The old code handles this by looping through the entire payload
table and recomputing the start slot for every payload in the topology from
scratch. While very much overkill, this ends up doing the right thing
because we always order the VCPIs for payloads from first to last starting
timeslot.

It's important to also note that drm_dp_mst_update_payload_step2() isn't
actually limited to updating a single payload - the driver can use it to
queue up multiple payload changes so that as many of them can be sent as
possible before waiting for the ACT. This is -technically- not against
spec, but as Wayne Lin has pointed out it's not consistently implemented
correctly in hubs - so it might as well be.

drm_dp_mst_update_payload_step2() is pretty self explanatory and basically
the same between the old and new code, save for the fact we don't have a
second step for deleting payloads anymore -and thus rename it to
drm_dp_mst_add_payload_step2().

The new payload code stores all of the current payload info within the MST
atomic state and computes as much of the state as possible ahead of time.
This has the one exception of the starting timeslots for payloads, which
can't be determined at atomic check time since the starting time slots will
vary depending on what order CRTCs are enabled in the atomic state - which
varies from driver to driver. These are still stored in the atomic MST
state, but are only copied from the old MST state during atomic commit
time. Likewise, this is when new start slots are determined.

Adding/removing payloads now works much more closely to how things are
described in the spec. When we delete a payload, we loop through the
current list of payloads and update the start slots for any payloads whose
time slots came after the payload we just deleted. Determining the starting
time slots for new payloads being added is done by simply keeping track of
where the end of the VC table is in
drm_dp_mst_topology_mgr->next_start_slot. Additionally, it's worth noting
that we no longer have a single update_payload() function. Instead, we now
have drm_dp_mst_add_payload_step1|2() and drm_dp_mst_remove_payload(). As
such, it's now left it up to the driver to figure out when to add or remove
payloads. The driver already knows when it's disabling/enabling CRTCs, so
it also already knows when payloads should be added or removed.

Changes since v1:
* Refactor around all of the completely dead code changes that are
happening in amdgpu for some reason when they really shouldn't even be
there in the first place… :\
* Remove mention of sending one ACT per series of payload updates. As Wayne
Lin pointed out, there are apparently hubs on the market that don't work
correctly with this scheme and require a separate ACT per payload update.
* Fix accidental drop of mst_mgr.lock - Wayne Lin
* Remove mentions of allowing multiple ACT updates per payload change,
mention that this is a result of vendors not consistently supporting this
part of the spec and requiring a unique ACT for each payload change.
* Get rid of reference to drm_dp_mst_port in DC - turns out I just got
myself confused by DC and we don't actually need this.
Changes since v2:
* Get rid of fix for not sending payload deallocations if ddps=0 and just
go back to wayne's fix

Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: Wayne Lin <Wayne.Lin@amd.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Fangzhi Zuo <Jerry.Zuo@amd.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sean Paul <sean@poorly.run>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220817193847.557945-18-lyude@redhat.com

drm/i915/hdcp: split out hdcp registers to a separate file

Reduce the bloat of i915_reg.h. The registers are also only needed in a
few places, no need to have them defined everywhere.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ce8334342e8bdf92c17c714aa13574e66cad93bb.1659607033.git.jani.nikula@intel.com

drm/i915/pcode: Extend pcode functions for multiple gt's

Each gt contains an independent instance of pcode. Extend pcode functions
to interface with pcode on different gt's. To avoid creating dependency of
display functionality on intel_gt, pcode function interfaces are exposed in
terms of uncore rather than intel_gt. Callers have been converted to pass
in the appropritate (i915 or intel_gt) uncore to the pcode functions.

v2: Expose pcode functions in terms of uncore rather than gt (Jani/Rodrigo)
v3: Retain previous function names to eliminate needless #defines (Rodrigo)
v4: Move out i915_pcode_init() to a separate patch (Tvrtko)
Remove duplicated drm_err/drm_dbg from intel_pcode_init() (Tvrtko)

Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220519085732.1276255-2-tvrtko.ursulin@linux.intel.com
[tursulin: fixup merge conflict]

drm/display: Move HDCP helpers into display-helper module

Move DRM's HDCP helper library into the display/ subdirectory and add
it to DRM's display helpers. Split the header file into core and helpers.
Update all affected drivers. No functional changes.

v3:
* fix Kconfig dependencies
v2:
* fix include statements (Jani, Javier)
* update Kconfig symbols

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220421073108.19226-7-tzimmermann@suse.de

drm/i915: Move intel_display_power_well_is_enabled() to intel_display_power_well.c

Move intel_display_power_well_is_enabled() to intel_power_well.c, as a step
towards making the low-level power well internals (i915_power_well_ops/desc
structs) hidden.

Eventually the call to this function and in general accessing power
wells directly from elsewhere in the driver should be replaced by the
use of power domains.

No functional change.

Suggested-by: Jani Nikula <jani.nikula@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220222165137.1004194-9-imre.deak@intel.com

drm/i915/pcode: rename sandybridge_pcode_* to snb_pcode_*

Prefer acronym-based naming to be in line with the rest of the driver.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220112111740.1208374-1-jani.nikula@intel.com

drm/i915: split out intel_pcode.[ch] to separate file

The snb+ pcode mailbox code is not sideband, so split it out to a
separate file. As can be seen from the #include changes, very few places
use both sideband and pcode.

Code movement only.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/185deb18eb739e5ae019e27834b9997dcc1347bc.1634207064.git.jani.nikula@intel.com

drm/i915/hdcp: reuse rx_info for mst stream type1 capability check

On some MST docking stations, rx_info can only be read after
RepeaterAuth_Send_ReceiverID_List and the RxStatus READY bit is set
otherwise the read will return -EIO.

This behavior causes the mst stream type1 capability test to fail to
read rx_info and determine if the topology supports type1 and fallback
to type0.

To fix this, check for type1 capability when we receive rx_info within
the AKE flow when we read RepeaterAuth_Send_ReceiverID_List instead
of an explicit read just for type1 capability checking.

This does require moving where we set stream_types to after
hdcp2_authenticate_sink() when we get rx_info but this occurs before we
do hdcp2_propagate_stream_management_info.

Also, legacy HDCP 2.0/2.1 are not type 1 capable either so check for
that as well.

Changes since v5:
- rename intel_set_stream_types() to intel_hdcp_prepare_streams()
(Anshuman)

Changes since v4:
- move topology_type1_capable to intel_digital_port and rename it as
hdcp_mst_type1_capable (Anshuman)
- make a helper function intel_set_stream_types() to set stream types
in hdcp2_authenticate_and_encrypt() (Anshuman)
- break on failure to set stream types and retry instead of returning
- remove no longer used declaration for streams_type1_capable()

Changes since v2:
- Remove no longer used variables in _intel_hdcp2_enable()

Signed-off-by: Juston Li <juston.li@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Tested-by: Suraj K <suraj.kandpal@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210819184835.1181323-4-juston.li@intel.com

drm/i915: Don't include intel_de.h from intel_display_types.h

Hoist the intel_de.h include from intel_display_types.h one
level up. I need this in order to untangle the include order
so that I can add tracepoints into intel_de.h.

This little cocci script did most of the work for me:
@find@
@@
(
intel_de_read(...)
|
intel_de_read_fw(...)
|
intel_de_write(...)
|
intel_de_write_fw(...)
)

@has_include@
@@
(
#include "intel_de.h"
|
#include "display/intel_de.h"
)

@depends on find && !has_include@
@@
+ #include "intel_de.h"
#include "intel_display_types.h"

@depends on find && !has_include@
@@
+ #include "display/intel_de.h"
#include "display/intel_display_types.h"

Cc: Cooper Chiou <cooper.chiou@intel.com>
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210430143945.6776-1-ville.syrjala@linux.intel.com

drm/i915/display: rename display version macros

While converting the rest of the driver to use GRAPHICS_VER() and
MEDIA_VER(), following what was done for display, some discussions went
back on what we did for display:

1) Why is the == comparison special that deserves a separate
macro instead of just getting the version and comparing directly
like is done for >, >=, <=?

2) IS_DISPLAY_RANGE() is weird in that it omits the "_VER" for
brevity. If we remove the current users of IS_DISPLAY_VER(), we
could actually repurpose it for a range check

With (1) there could be an advantage if we used gen_mask since multiple
conditionals be combined by the compiler in a single and instruction and
check the result. However a) INTEL_GEN() doesn't use the mask since it
would make the code bigger everywhere else and b) in the cases it made
sense, it also made sense to convert to the _RANGE() variant.

So here we repurpose IS_DISPLAY_VER() to work with a [ from, to ] range
like was the IS_DISPLAY_RANGE() and convert the current IS_DISPLAY_VER()
users to use == and != operators. Aside from the definition changes,
this was done by the following semantic patch:

@@ expression dev_priv, E1; @@
- !IS_DISPLAY_VER(dev_priv, E1)
+ DISPLAY_VER(dev_priv) != E1

@@ expression dev_priv, E1; @@
- IS_DISPLAY_VER(dev_priv, E1)
+ DISPLAY_VER(dev_priv) == E1

@@ expression dev_priv, from, until; @@
- IS_DISPLAY_RANGE(dev_priv, from, until)
+ IS_DISPLAY_VER(dev_priv, from, until)

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
[Jani: Minor conflict resolve while applying.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-4-lucas.demarchi@intel.com

drm/i915/display: Eliminate IS_GEN9_{BC,LP}

Now that we've eliminated INTEL_GEN(), IS_GEN_RANGE(), etc. from the
display code, we should also kill off our use of the IS_GEN9_* macros
too. We'll do the conversion manually this time instead of using
Coccinelle since the most logical substitution can depend heavily on the
code context, and sometimes we can keep the code simpler if we make
additional adjustments such as swapping the order of if/else arms.

v2:
- Restore a lost negation in intel_pll_is_valid().

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210407203945.1432531-1-matthew.d.roper@intel.com
(cherry picked from commit 70bfb30743d5da73058b0a2271e9c127a84fb494)
[Jani: cherry picked to topic branch to reduce conflicts]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/display: Eliminate IS_GEN9_{BC,LP}

Now that we've eliminated INTEL_GEN(), IS_GEN_RANGE(), etc. from the
display code, we should also kill off our use of the IS_GEN9_* macros
too. We'll do the conversion manually this time instead of using
Coccinelle since the most logical substitution can depend heavily on the
code context, and sometimes we can keep the code simpler if we make
additional adjustments such as swapping the order of if/else arms.

v2:
- Restore a lost negation in intel_pll_is_valid().

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210407203945.1432531-1-matthew.d.roper@intel.com

drm/i915/display: Simplify GLK display version tests

GLK has always been a bit of a special case since it reports INTEL_GEN()
as 9, but has version 10 display IP. Now we can properly represent the
display version as 10 and simplify the display generation tests
throughout the display code.

Aside from manually adding the version to the glk_info structure, the
rest of this patch is generated with a Coccinelle semantic patch. Note
that we also need to switch any code that matches gen10 today but *not*
GLK to be CNL-specific:

@@ expression dev_priv; @@
- DISPLAY_VER(dev_priv) > 9
+ DISPLAY_VER(dev_priv) >= 10

@@ expression dev_priv, E; @@
(
- DISPLAY_VER(dev_priv) >= 10 && E
+ (DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) && E
|
- DISPLAY_VER(dev_priv) >= 10
+ DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)
|
- IS_DISPLAY_RANGE(dev_priv, 10, E)
+ IS_DISPLAY_RANGE(dev_priv, 11, E) || IS_CANNONLAKE(dev_priv)
)

@@ expression dev_priv, E, E2; @@
(
- (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
+ IS_DISPLAY_VER(dev_priv, 10)
|
- E || IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv)
+ E || IS_DISPLAY_VER(dev_priv, 10)
|
- (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv))
+ IS_DISPLAY_VER(dev_priv, 10)
|
- IS_GEMINILAKE(dev_priv) || E || IS_CANNONLAKE(dev_priv)
+ E || IS_DISPLAY_VER(dev_priv, 10)
|
- E || IS_GEMINILAKE(dev_priv) || E2 || IS_CANNONLAKE(dev_priv)
+ E || E2 || IS_DISPLAY_VER(dev_priv, 10)
|
- (IS_DISPLAY_VER(dev_priv, 10) || IS_GEMINILAKE(dev_priv))
+ IS_DISPLAY_VER(dev_priv, 10)
|
- (IS_GEMINILAKE(dev_priv) || IS_DISPLAY_VER(dev_priv, 10))
+ IS_DISPLAY_VER(dev_priv, 10)
)

@@ expression dev_priv; @@
- (IS_DISPLAY_VER(dev_priv, 9) && !IS_GEMINILAKE(dev_priv))
+ IS_DISPLAY_VER(dev_priv, 9)

@@ expression dev_priv; @@
(
- !(DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10))
+ DISPLAY_VER(dev_priv) < 10
|
- (DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10))
+ DISPLAY_VER(dev_priv) >= 10
)

@@ expression dev_priv, E; @@
- E || DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10)
+ E || DISPLAY_VER(dev_priv) >= 10

@@ expression dev_priv, E; @@
- (IS_DISPLAY_RANGE(dev_priv, 11, E) || IS_DISPLAY_VER(dev_priv, 10))
+ IS_DISPLAY_RANGE(dev_priv, 10, E)

@@ expression dev_priv; @@
(
- DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv) || IS_GEN9_LP(dev_priv)
+ DISPLAY_VER(dev_priv) >= 10 || IS_GEN9_LP(dev_priv)
|
- IS_GEN9_LP(dev_priv) || DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)
+ IS_GEN9_LP(dev_priv) || DISPLAY_VER(dev_priv) >= 10
)

@@ expression dev_priv, E; @@
- !(DISPLAY_VER(dev_priv) >= E)
+ DISPLAY_VER(dev_priv) < E

v2:
- Convert gen10 conditions that don't include GLK into CNL conditions.
(Ville)

v3:
- Rework coccinelle rules so that "ver>=10" turns into "ver>=11||is_cnl." (Ville)

v3.1:
- Manually re-add the ".display.version = 10" to glk_info after
regenerating patch via Coccinelle.

v4:
- Also apply cocci rules to intel_pm.c and i915_irq.c! (CI)

Cc: Ville Syrjälä <ville.syrjala@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210322233840.4056851-1-matthew.d.roper@intel.com

drm/i915/display: Eliminate most usage of INTEL_GEN()

Use Coccinelle to convert most of the usage of INTEL_GEN() and IS_GEN()
in the display code to use DISPLAY_VER() comparisons instead. The
following semantic patch was used:

@@ expression dev_priv, E; @@
- INTEL_GEN(dev_priv) == E
+ IS_DISPLAY_VER(dev_priv, E)

@@ expression dev_priv; @@
- INTEL_GEN(dev_priv)
+ DISPLAY_VER(dev_priv)

@@ expression dev_priv; expression E; @@
- IS_GEN(dev_priv, E)
+ IS_DISPLAY_VER(dev_priv, E)

@@
expression dev_priv;
expression from, until;
@@
- IS_GEN_RANGE(dev_priv, from, until)
+ IS_DISPLAY_RANGE(dev_priv, from, until)

There are still some display-related uses of INTEL_GEN() in intel_pm.c
(watermark code) and i915_irq.c. Those will be updated separately.

v2:
- Use new IS_DISPLAY_RANGE and IS_DISPLAY_VER helpers. (Jani)

Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210320044245.3920043-4-matthew.d.roper@intel.com

drm/i915/hdcp: return correct error code

hdcp2_enable_stream_encryption shouldn't get called in case
of any port authentication or encryption error, though
hdcp2_enable_stream_encryption checks for link encryption
before enabling stream encryption and returns error but
this return error code won't be correct in case of any error
due to port authentication and encryption.

Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210319100208.5886-4-anshuman.gupta@intel.com

drm/i915/hdcp: link hdcp2 recovery on link enc stopped

When stream encryption enabling fails due to Link encryption status
has stopped, prepare HDCP2 for recovery by disabling port authentication
and encryption such that it can re-attempt port authentication
and encryption.

Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210319100208.5886-3-anshuman.gupta@intel.com

drm/i915/hdcp: HDCP2.2 MST Link failure recovery

DP MST Link Check performed only for the connector involved with
HDCP port authentication and encryption, for other connector it
simply returns link check with true and update the uevent.
Therefore in case of HDCP 2.2 link failure, disable HDCP encryption
and de-authenticate the port so next time it can enable port
authentication and encryption.

Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210319100208.5886-2-anshuman.gupta@intel.com

drm/i915/hdcp: mst streams type1 capability check

It requires to check streams type1 capability in mst topology
by checking Rxinfo instead connector HDCP2.x capability in
order to enforce type0 stream encryption in a mix of
HDCP {1.x,2.x} mst topology.
Rxcaps always shows HDCP 2.x capability of immediate downstream
connector. Let's use Rxinfo HDCP1_DEVICE_DOWNSTREAM bit to
detect a HDCP {1.x,2.x} mix mst topology.

Cc: Sean Paul <seanpaul@chromium.org>
Cc: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210319091732.17547-1-anshuman.gupta@intel.com

drm/i915/hdcp: Fix uninitialized symbol

Move (num_hdcp_streams > 0) condition to stream_encryption()
code block, where it actually belongs.
This fixes the static analysis error of uninitialized symbol 'ret'.

v2:
- return 0 as the return value is already checked. [Ankit]

Cc: Ramalingam C <ramalingam.c@intel.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210120103032.15198-1-anshuman.gupta@intel.com

drm/i915/hdcp: Fix WARN_ON(data->k > INTEL_NUM_PIPES)

Initialize no. of streams transmitted on a port to zero
such that intel_hdcp_required_content_stream() can
prepared the content stream after subsequemt attmept to
enable hdcp after a HDCP failure.

v2:
- Initialize k at top level instead of else branch. [Jani]

Cc: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210119064655.1605-2-anshuman.gupta@intel.com

drm/i915/hdcp: Enable HDCP 2.2 MST support

Enable HDCP 2.2 MST support till Gen12.

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

drm/i915/hdcp: Configure HDCP2.2 MST steram encryption status

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: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-19-anshuman.gupta@intel.com

drm/i915/hdcp: Pass connector to check_2_2_link

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: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-16-anshuman.gupta@intel.com

drm/i915/hdcp: MST streams support in hdcp port_data

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: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Tested-by: Juston Li <juston.li@intel.com>
Acked-by: Juston Li <juston.li@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-15-anshuman.gupta@intel.com

drm/i915/hdcp: Encapsulate hdcp_port_data to dig_port

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: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-12-anshuman.gupta@intel.com

drm/i915/hdcp: Pass dig_port to intel_hdcp_init

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: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-11-anshuman.gupta@intel.com

drm/i915/hdcp: Configure HDCP1.4 MST steram encryption status

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: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-9-anshuman.gupta@intel.com

drm/i915/hdcp: Move HDCP enc status timeout to header

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 7e90e8d0c0ea ("drm/i915: Increase timeout for Encrypt
status change")'
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-7-anshuman.gupta@intel.com

drm/i915/hdcp: DP MST transcoder for link and stream

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: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-6-anshuman.gupta@intel.com

drm/i915/hdcp: No HDCP when encoder is't initialized

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: Karthik B S <karthik.b.s@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-5-anshuman.gupta@intel.com

drm/i915/hdcp: Get conn while content_type changed

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: a6597faa2d59 ("drm/i915: Protect workers against disappearing connectors")
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-3-anshuman.gupta@intel.com

drm/i915/hdcp: Update CP property in update_pipe

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: 33f9a623bfc6 ("drm/i915/hdcp: Update CP as per the kernel internal state")
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-2-anshuman.gupta@intel.com

drm/i915/hdcp: Get conn while content_type changed

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: a6597faa2d59 ("drm/i915: Protect workers against disappearing connectors")
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-3-anshuman.gupta@intel.com
(cherry picked from commit b3c6661aad979ec3d4f5675cf3e6a35828607d6a)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/hdcp: Update CP property in update_pipe

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: 33f9a623bfc6 ("drm/i915/hdcp: Update CP as per the kernel internal state")
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-2-anshuman.gupta@intel.com
(cherry picked from commit d276e16702e2d634094f75f69df3b493f359fe31)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: dont retry stream management at seq_num_m roll over

When roll over detected for seq_num_m, we shouldn't continue with stream
management with rolled over value.

So we are terminating the stream management retry, on roll over of the
seq_num_m.

v2:
using drm_dbg_kms instead of DRM_DEBUG_KMS [Anshuman]
v3:
dev_priv is used as i915 [JaniN]
v4:
roll over is detected at the start of the stream management.

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> [v3]
Tested-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200923132435.17039-3-anshuman.gupta@intel.com

drm/i915: terminate reauth at stream management failure

As per the HDCP2.2 compliance test 1B-10 expectation, when stream
management for a repeater fails, we retry thrice and when it fails
in all retries, HDCP2.2 reauthentication aborted at kernel.

v2:
seq_num_m++ is extended for steam management failures too.[Anshuman]
v3:
use drm_dbg_kms instead of DRM_DEBUG_KMS [Anshuman]
v4:
dev_priv is used as i915 [JaniN]
v5:
Few improvisements are done [Sean]

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200923132435.17039-2-anshuman.gupta@intel.com

drm/i915: Clear the repeater bit on HDCP disable

On HDCP disable, clear the repeater bit. This ensures if we connect a
non-repeater sink after a repeater, the bit is in the state we expect.

Fixes: ee5e5e7a5e0f ("drm/i915: Add HDCP framework + base implementation")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ramalingam C <ramalingam.c@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v4.17+
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-3-sean@poorly.run
(cherry picked from commit 2cc0c7b520bf8ea20ec42285d4e3d37b467eb7f9)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Fix sha_text population code

This patch fixes a few bugs:

1- We weren't taking into account sha_leftovers when adding multiple
ksvs to sha_text. As such, we were or'ing the end of ksv[j - 1] with
the beginning of ksv[j]

2- In the sha_leftovers == 2 and sha_leftovers == 3 case, bstatus was
being placed on the wrong half of sha_text, overlapping the leftover
ksv value

3- In the sha_leftovers == 2 case, we need to manually terminate the
byte stream with 0x80 since the hardware doesn't have enough room to
add it after writing M0

The upside is that all of the HDCP supported HDMI repeaters I could
find on Amazon just strip HDCP anyways, so it turns out to be _really_
hard to hit any of these cases without an MST hub, which is not (yet)
supported. Oh, and the sha_leftovers == 1 case works perfectly!

Fixes: ee5e5e7a5e0f ("drm/i915: Add HDCP framework + base implementation")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ramalingam C <ramalingam.c@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v4.17+
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-2-sean@poorly.run
(cherry picked from commit 1f0882214fd0037b74f245d9be75c31516fed040)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Add HDCP 1.4 support for MST connectors

Now that all the groundwork has been laid, we can turn on HDCP 1.4 over
MST. Everything except for toggling the HDCP signalling and HDCP 2.2
support is the same as the DP case, so we'll re-use those callbacks

Cc: Juston Li <juston.li@intel.com>
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-12-sean@poorly.run #v1
Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-13-sean@poorly.run #v2
Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-13-sean@poorly.run #v3
Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-15-sean@poorly.run #v4
Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-17-sean@poorly.run #v5
Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-17-sean@poorly.run #v6
Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-18-sean@poorly.run #v7

Changes in v2:
-Toggle HDCP from encoder disable/enable
-Don't disable HDCP on MST connector destroy, leave that for encoder
disable, just ensure the check_work routine isn't running any longer
Changes in v3:
-Place the shim in the new intel_dp_hdcp.c file (Ville)
Changes in v4:
-Actually use the mst shim for mst connections (Juston)
-Use QUERY_STREAM_ENC_STATUS MST message to verify channel is encrypted
Changes in v5:
-Add sleep on disable signalling to match hdmi delay
Changes in v6:
-Disable HDCP over MST on GEN12+ since I'm unsure how it should work and I
don't have hardware to test it
Changes in v7:
-Remove hdcp2 shims for MST in favor of skipping hdcp2 init (Ramalingam)
Changes in v8:
-None

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-18-sean@poorly.run

drm/i915: Add connector to hdcp_shim->check_link()

Currently we derive the connector from digital port in check_link(). For
MST, this isn't sufficient since the digital port passed into the
function can have multiple connectors downstream. This patch adds
connector to the check_link() arguments so we have it when we need it.

Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-13-sean@poorly.run #v4
Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-14-sean@poorly.run #v5
Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-14-sean@poorly.run #v6
Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-15-sean@poorly.run #v7

Changes in v4:
-Added to the set
Changes in v5:
-None
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-15-sean@poorly.run

drm/i915: Plumb port through hdcp init

This patch plumbs port through hdcp init instead of relying on
intel_attached_encoder() to return a non-NULL encoder which won't work
for MST connectors.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-13-sean@poorly.run #v5
Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-13-sean@poorly.run #v6
Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-14-sean@poorly.run #v7

Changes in v5:
-Added to the set
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-14-sean@poorly.run

drm/i915: Don't fully disable HDCP on a port if multiple pipes are using it

This patch is required for HDCP over MST. If a port is being used for
multiple HDCP streams, we don't want to fully disable HDCP on a port if
one of them is disabled. Instead, we just disable the HDCP signalling on
that particular pipe and exit early. The last pipe to disable HDCP will
also bring down HDCP on the port.

In order to achieve this, we need to keep a refcount in intel_digital_port
and protect it using a new hdcp_mutex.

Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-8-sean@poorly.run #v1
Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-9-sean@poorly.run #v2
Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-9-sean@poorly.run #v3
Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-9-sean@poorly.run #v4
Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-9-sean@poorly.run #v5
Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-9-sean@poorly.run #v6
Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-10-sean@poorly.run #v7

Changes in v2:
-Move the toggle_signalling call into _intel_hdcp_disable so it's called from check_work
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-Change WARN_ON to drm_WARN_ON
Changes in v6:
-None
Changes in v7:
-Split minor intel_hdcp_disable refactor into separate patch (Ramalingam)
Changes in v8:
-None

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-10-sean@poorly.run

drm/i915: Clean up intel_hdcp_disable

Add an out label and un-indent hdcp disable in preparation for
hdcp_mutex. No functional changes

Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-9-sean@poorly.run #v6
Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-9-sean@poorly.run #v7

Changes in v7:
-Split into separate patch (Ramalingam)
Changes in v8:
-None

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-9-sean@poorly.run

drm/i915: Protect workers against disappearing connectors

This patch adds some protection against connectors being destroyed
before the HDCP workers are finished.

For check_work, we do a synchronous cancel after the connector is
unregistered which will ensure that it is finished before destruction.

In the case of prop_work, we can't do a synchronous wait since it needs
to take connection_mutex which could cause deadlock. Instead, we'll take
a reference on the connector when scheduling prop_work and give it up
once we're done.

Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-8-sean@poorly.run #v2
Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-8-sean@poorly.run #v3
Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-8-sean@poorly.run #v4
Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-8-sean@poorly.run #v5
Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-8-sean@poorly.run #v6
Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-8-sean@poorly.run #v7

Changes in v2:
-Added to the set
Changes in v3:
-Change the WARN_ON condition in intel_hdcp_cleanup to allow for
initializing connectors as well
Changes in v4:
-None
Changes in v5:
-Change WARN_ON to drm_WARN_ON
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-8-sean@poorly.run

drm/i915: Factor out hdcp->value assignments

This is a bit of housecleaning for a future patch. Instead of sprinkling
hdcp->value assignments and prop_work scheduling everywhere, introduce a
function to do it for us.

Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-7-sean@poorly.run #v1
Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-7-sean@poorly.run #v2
Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-7-sean@poorly.run #v3
Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-7-sean@poorly.run #v4
Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-7-sean@poorly.run #v5
Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-7-sean@poorly.run #v6
Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-7-sean@poorly.run #v7

Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-Rebased on top of drm_* logging changes
Changes in v5:
-Change WARN_ON to drm_WARN_ON
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-7-sean@poorly.run

drm/i915: Use the cpu_transcoder in intel_hdcp to toggle HDCP signalling

Instead of using intel_dig_port's encoder pipe to determine which
transcoder to toggle signalling on, use the cpu_transcoder field already
stored in intel_hdmi.

This is particularly important for MST.

Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-6-sean@poorly.run #v2
Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-6-sean@poorly.run #v3
Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-6-sean@poorly.run #v4
Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-6-sean@poorly.run #v5
Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-6-sean@poorly.run #v6
Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-6-sean@poorly.run #v7

Changes in v2:
-Added to the set
Changes in v3:
-s/hdcp/hdmi/ in commit msg (Ram)
Changes in v4:
-Rebased on intel_de_(read|write) change
Changes in v5:
-Update hdcp->cpu_transcoder in intel_hdcp_enable so it works with pipe != 0
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-6-sean@poorly.run

drm/i915: Clear the repeater bit on HDCP disable

On HDCP disable, clear the repeater bit. This ensures if we connect a
non-repeater sink after a repeater, the bit is in the state we expect.

Fixes: ee5e5e7a5e0f ("drm/i915: Add HDCP framework + base implementation")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ramalingam C <ramalingam.c@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v4.17+
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-3-sean@poorly.run #v2
Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-3-sean@poorly.run #v3
Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-3-sean@poorly.run #v4
Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-3-sean@poorly.run #v5
Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-3-sean@poorly.run #v6
Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-3-sean@poorly.run #v7

Changes in v2:
-Added to the set
Changes in v3:
-None
I had previously agreed that clearing the rep_ctl bits on enable would
also be a good idea. However when I committed that idea to code, it
didn't look right. So let's rely on enables and disables being paired
and everything outside of that will be considered a bug
Changes in v4:
-s/I915_(READ|WRITE)/intel_de_(read|write)/
Changes in v5:
-None
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-3-sean@poorly.run

drm/i915: Fix sha_text population code

This patch fixes a few bugs:

1- We weren't taking into account sha_leftovers when adding multiple
ksvs to sha_text. As such, we were or'ing the end of ksv[j - 1] with
the beginning of ksv[j]

2- In the sha_leftovers == 2 and sha_leftovers == 3 case, bstatus was
being placed on the wrong half of sha_text, overlapping the leftover
ksv value

3- In the sha_leftovers == 2 case, we need to manually terminate the
byte stream with 0x80 since the hardware doesn't have enough room to
add it after writing M0

The upside is that all of the HDCP supported HDMI repeaters I could
find on Amazon just strip HDCP anyways, so it turns out to be _really_
hard to hit any of these cases without an MST hub, which is not (yet)
supported. Oh, and the sha_leftovers == 1 case works perfectly!

Fixes: ee5e5e7a5e0f ("drm/i915: Add HDCP framework + base implementation")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ramalingam C <ramalingam.c@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v4.17+
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-2-sean@poorly.run #v1
Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-2-sean@poorly.run #v2
Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-2-sean@poorly.run #v3
Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-2-sean@poorly.run #v4
Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-2-sean@poorly.run #v5
Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-2-sean@poorly.run #v6
Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-2-sean@poorly.run #v7

Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-Rebased on intel_de_write changes
Changes in v5:
-None
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-2-sean@poorly.run

drm/i915/hdcp: No direct access to power_well desc

HDCP code doesn't require to access power_well internal stuff,
instead it should use the intel_display_power_well_is_enabled()
to get the status of desired power_well.
No functional change.

v2:
- used with_intel_runtime_pm instead of get/put. [Jani]
v3:
- rebased.

Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200805114521.867-3-anshuman.gupta@intel.com

drm/i915/hdcp: Add update_pipe early return

Currently intel_hdcp_update_pipe() is also getting called for non-hdcp
connectors and get through its conditional code flow, which is completely
unnecessary for non-hdcp connectors, therefore it make sense to
have an early return. No functional change.

v2:
- rebased.

Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200805114521.867-2-anshuman.gupta@intel.com

drm/i915/hdcp: Fix the return handling of drm_hdcp_check_ksvs_revoked

drm_hdcp_check_ksvs_revoked() returns the number of revoked keys and
error codes when the SRM parsing is failed.

Errors in SRM parsing can't affect the HDCP auth, hence with this patch,
I915 will look out for revoked key count alone.

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
cc: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Sean Paul <sean@poorly.run>
Link: https://patchwork.freedesktop.org/patch/msgid/20200429134555.22106-1-ramalingam.c@intel.com

drm/i915/hdcp: Update CP as per the kernel internal state

Content Protection property should be updated as per the kernel
internal state. Let's say if Content protection is disabled
by userspace, CP property should be set to UNDESIRED so that
reauthentication will not happen until userspace request it again,
but when kernel disables the HDCP due to any DDI disabling sequences
like modeset/DPMS operation, kernel should set the property to
DESIRED, so that when opportunity arises, kernel will start the
HDCP authentication on its own.

Somewhere in the line, state machine to set content protection to
DESIRED from kernel was broken and IGT coverage was missing for it.
This patch fixes it.

v2:
- Fixing hdcp CP state in connector atomic check function
intel_hdcp_atomic_check(). [Maarten]
This will require to check hdcp->value in intel_hdcp_update_pipe()
in order to avoid enabling hdcp, if it was already enabled.

v3:
- Rebased.

Cc: Ramalingam C <ramalingam.c@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/350962/?series=72664&rev=2 #v1
Link: https://patchwork.freedesktop.org/patch/359396/?series=72251&rev=3 #v2
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200630082048.22308-1-anshuman.gupta@intel.com

drm/i915/display: prefer dig_port to reference intel_digital_port

We have a mix of dport, intel_dport, intel_dig_port and dig_port to
reference a intel_digital_port struct. Numbers are around

5 intel_dport
36 dport
479 intel_dig_port
352 dig_port

Since we already removed the intel_ prefix from most of our other
structs, do the same here and prefer dig_port.

v2: rename everything in i915, not just a few display sources and
reword commit message (from Matt Roper)

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200701045054.23357-1-lucas.demarchi@intel.com

drm/i915: Identify Cometlake platform

Cometlake is a small refresh of Coffeelake, but since we have found out a
difference in the plaforms, we need to identify them as separate platforms.

Since we previously took Coffeelake/Cometlake as identical, update all
IS_COFFEELAKE() to also include IS_COMETLAKE().

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200602140541.5481-1-chris@chris-wilson.co.uk

drm/i915: drop a bunch of superfluous inlines

Remove a number of inlines from .c files, and let the compiler decide
what's best. There's more to do, but need to start somewhere, and need
to start setting the example.

Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200420140438.14672-2-jani.nikula@intel.com

drm/i915: Pass atomic state to encoder hooks

We're going to want access to the atomic state for iterating
the slave crtcs when enabling the port sync master crtc. Pass
the atomic state all the way down.

The alternative would be yet another encoder hook which we'll
have to call after all the normal modeset stuff is done. Not
really a fan of yet another hook just for this.

Note that during readout state sanitation we are now going
to pass NULL as the atomic state since we don't have one.
We need to change that and then we can also s/crtc_state/crtc/
and s/conn_state/conn/ for the encoder hooks as well.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200313164831.5980-13-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>

drm/i915/hdcp: convert to struct drm_device based logging.

Converts various instances of the printk based drm logging macros to the
struct drm_device based logging macros in i915/display/intel_hdcp.c.
This also involves extracting the drm_i915_private device from the
intel_connector type for use in the macros.

v2 by Jani:
- rebase

Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Wambui Karuga <wambui.karugax@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/47d5e88dedc08ee48938344296ada550dedd5f90.1583766715.git.jani.nikula@intel.com

drm/i915/hdcp: Mandate (seq_num_V==0) at first RecvId msg

HDCP Repeater initializes seq_num_V to 0 at the beginning of
hdcp Session i.e. after AKE_init received, refer
HDCP 2.2 Spec HDMI PAGE 19, DP PAGE 20.

HDCP 2.2 Comp specs 1B-06 test verifies that whether DUT
considers failure of authentication if the repeater provides a
non-zero value in seq_num_V in the first,
RepeaterAuth_Send_ReceiverID_List message.

Make sure that HDCP repeater initializes seq_num_V to zero at
beginning of session i.e. after AKE_Init, fail the Auth if
there is non zero seq_num_V.

v2:
- Used existing hdcp2_encrypted flag instead of
declaring new flag. [Ram]

Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200220123217.23635-2-anshuman.gupta@intel.com

drm/i915/hdcp: conversion to struct drm_device based logging macros.

Converts remaining instances of the printk based logging macros in
i915/display/intel_hdcp.c with the struct drm_device based macros
manually.

This is continuation of commit 65833c463886 ("drm/i915/hdcp: conversion
to struct drm_device based logging macros.")

v2:
i915_dev_priv is used instead of drm_device for reusability [JaniN]
v3:
Made it independent from the series.
once instance of dev_priv naming is changed to i915 [Jani N]

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200212123007.6659-1-ramalingam.c@intel.com

drm/i915/display/hdcp: Make WARN* drm specific where drm_priv ptr is available

drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.

Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is
readily available.

The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.

@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}

@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}

Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200220165507.16823-7-pankaj.laxminarayan.bharadiya@intel.com

drm/i915: HDCP support on above PORT_E

As Gen12 onwards there are HDCP instances for each transcoder
instead of port, remove the (port < PORT_E) hdcp support
limitation for platform >= Gen12.

v2:
- Nuke the comment and cosmetic changes. [Jani]

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200207144116.20172-1-anshuman.gupta@intel.com

drm/i915/hdcp: move update pipe code to hdcp

The DDI encoder code shouln't have to know about the guts of
HDCP. Abstract the pipe update code to a new intel_hdcp_update_pipe() in
intel_hdcp.c. No functional changes.

Cc: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200128163803.5954-1-jani.nikula@intel.com

drm/i915/hdcp: use intel_de_*() functions for register access

The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().

Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().

No functional changes.

Generated using the following semantic patch:

@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)

@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)

@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)

@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)

@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)

Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/a58f536d25d9cd6da510da49663508cd264eee0f.1580149467.git.jani.nikula@intel.com

drm/i915/hdcp: conversion to struct drm_device based logging macros.

Converts various instances of the printk based logging macros in
i915/display/intel_hdcp.c with the struct drm_device based macros using
coccinelle. The script matches based on the existence of an existing
struct drm_i915_private device:
@rule1@
identifier fn, T;
@@

fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}

@rule2@
identifier fn, T;
@@

fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}

New checkpatch warnings were addressed manually.

Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200122110844.2022-7-wambui.karugax@gmail.com

drm/i915/hdcp: Clean up local variables

Eliminate the inconsistencies in the hdcp code local variables:
- use dev_priv over dev
- use to_i915() instead of dev->dev_private
- initialize variables when declaring them
- a bit of declaration suffling to appease ocd

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191204180549.1267-10-ville.syrjala@linux.intel.com
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>

drm/i915: Rename conn_to_dig_port() to intel_attached_dig_port()

Use the standard naming convention and rename conn_to_dig_port()
to intel_attached_dig_port().

@@
@@
- conn_to_dig_port
+ intel_attached_dig_port
(...)
{
...
}

@@
expression C;
@@
- conn_to_dig_port(C)
+ intel_attached_dig_port(C)

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191204180549.1267-9-ville.syrjala@linux.intel.com
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>

drm/i915: Use intel_attached_encoder()

It's easy to confuse the drm_connector->encoder (legacy state
adjusted during modeset) and intel_connector->encoder (the statically
(sans. MST) attached encoder of the connector). For the latter
let's use intel_attached_encoder() consistently.

@@
identifier F !~ "^intel_attached_encoder$";
struct intel_connector *C;
expression E;
@@
F(...)
{
<...
(
C->encoder = E
|
- C->encoder
+ intel_attached_encoder(C)
)
...>
}

@@
identifier F !~ "^intel_attached_encoder$";
struct drm_connector *C;
expression E;
@@
F(...)
{
<...
(
to_intel_connector(C)->encoder = E
|
- to_intel_connector(C)->encoder
+ intel_attached_encoder(to_intel_connector(C))
)
...>
}

v2: Regenerated

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191204180549.1267-6-ville.syrjala@linux.intel.com
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>

drm/i915/hdcp: Nuke intel_hdcp_transcoder_config()

intel_hdcp_transcoder_config() is clobbering some globally visible
state in .compute_config(). That is a big no no as .compute_config()
is supposed to have no visible side effects when either the commit
fails or it's just a TEST_ONLY commit.

Inline this stuff into intel_hdcp_enable() so that the state only
gets modified when we actually commit the state to the hardware.

Cc: Ramalingam C <ramalingam.c@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Fixes: 39e2df090c3c ("drm/i915/hdcp: update current transcoder into intel_hdcp")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191204180549.1267-2-ville.syrjala@linux.intel.com
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
(cherry picked from commit 67e1d5ed85a83e232a9e0b995f5778a86722b96e)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

drm/i915/hdcp: Nuke intel_hdcp_transcoder_config()

intel_hdcp_transcoder_config() is clobbering some globally visible
state in .compute_config(). That is a big no no as .compute_config()
is supposed to have no visible side effects when either the commit
fails or it's just a TEST_ONLY commit.

Inline this stuff into intel_hdcp_enable() so that the state only
gets modified when we actually commit the state to the hardware.

Cc: Ramalingam C <ramalingam.c@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Fixes: 39e2df090c3c ("drm/i915/hdcp: update current transcoder into intel_hdcp")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191204180549.1267-2-ville.syrjala@linux.intel.com
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>

drm/i915: coffeelake supports hdcp2.2

This includes other platforms that utilize the same gen graphics as
CFL: AML, WHL and CML.

Signed-off-by: Juston Li <juston.li@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191011181918.29618-1-juston.li@intel.com

drm/i915/display: Handle fused off HDCP

HDCP could be fused off, so not all GEN9+ platforms will support it.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Martin Peres <martin.peres@linux.intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191026001323.216052-2-jose.souza@intel.com

drm/i915/hdcp: Enable HDCP 1.4 and 2.2 on Gen12+

>From Gen12 onwards, HDCP HW block is implemented within transcoders.
Till Gen11 HDCP HW block was part of DDI.

Hence required changes in HW programming is handled here.

As ME FW needs the transcoder detail on which HDCP is enabled
on Gen12+ platform, we are populating the detail in hdcp_port_data.

v2:
_MMIO_TRANS is used [Lucas and Daniel]
platform check is moved into the caller [Lucas]
v3:
platform check is moved into a macro [Shashank]
v4:
Few optimizations in the coding [Shashank]
v5:
Fixed alignment in macro definition in i915_reg.h [Shashank]
unused variables "reg" is removed.
v6:
Configuring the transcoder at compute_config.
transcoder is used instead of pipe in macros.
Rebased.
v7:
transcoder is cached at intel_hdcp
hdcp_port_data is configured with transcoder index asper ME FW.
v8:
s/trans/cpu_transcoder
s/tc/cpu_transcoder
v9:
rep_ctl is prepared for TCD too.
return moved into deault of rep_ctl prepare function [Shashank]

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190828164216.405-7-ramalingam.c@intel.com

drm/i915/hdcp: update current transcoder into intel_hdcp

On gen12+ platforms, HDCP HW is associated to the transcoder.
Hence on every modeset update associated transcoder into the
intel_hdcp of the port.

v2:
s/trans/cpu_transcoder [Jani]
v3:
comment is added for fw_ddi init for gen12+ [Shashank]
only hdcp capable transcoder is translated into fw_tc [Shashank]
v4:
fw_tc initialization is kept for modeset. [Tomas]
few extra doc is added at port_data init [Tomas]
v5:
Few comments are improvised [Tomas]

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190828164216.405-6-ramalingam.c@intel.com

drm/i915: mei_hdcp: I915 sends ddi index as per ME FW

I915 converts it's port value into ddi index defiend by ME FW
and pass it as a member of hdcp_port_data structure.

Hence expose the enum mei_fw_ddi to I915 through
i915_mei_interface.h.

v2:
Copyright years are bumped [Tomas]

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Acked-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190828164216.405-2-ramalingam.c@intel.com

drm/i915: Wrappers for display register waits

To reduce the number of explicit dev_priv->uncore calls in the display
code ahead of the introduction of dev_priv->de_uncore, this patch
introduces a wrapper for one of the main usages of it, the register
waits. When we transition to the new uncore, we can just update the
wrapper to point to the appropriate structure.

Since the vast majority of waits are on a set or clear of a bit or mask,
add set & clear flavours of the wrapper to simplify the code.

Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190816012343.36433-7-daniele.ceraolospurio@intel.com

drm/i915: Move i915_power_well_id out of i915_reg.h

It has nothing to do with registers, so move it to the more appropriate
intel_display_power.h

Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190816012343.36433-2-daniele.ceraolospurio@intel.com

drm/i915: rename intel_drv.h to display/intel_display_types.h

Everything about the file is about display, and mostly about types
related to display. Move under display/ as intel_display_types.h to
reflect the facts.

There's still plenty to clean up, but start off with moving the file
where it logically belongs and naming according to contents.

v2: fix the include guard name in the renamed file

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190806113933.11799-1-jani.nikula@intel.com

drm/i915: update the hdcp state with uevent

drm function to update the content protection property state and to
generate a uevent is invoked from the intel hdcp property work.

Hence whenever kernel changes the property state, userspace will be
updated with a uevent.

v2:
state update is moved into drm function [daniel]

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/320965/?series=57232&rev=14

drm/i915: Attach content type property

Attaches the content type property for HDCP2.2 capable connectors.

Implements the update of content type from property and apply the
restriction on HDCP version selection.

Need ACK for content type property from userspace consumer.

v2:
s/cp_content_type/content_protection_type [daniel]
disable at hdcp_atomic_check to avoid check at atomic_set_property
[Maarten]
v3:
s/content_protection_type/hdcp_content_type [Pekka]
v4:
hdcp disable incase of type change is moved into commit [daniel].
v5:
Simplified the Type change procedure. [Daniel]
v6:
Type change with UNDESIRED state is ignored.

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/320959/?series=57232&rev=14

drm: Add Content protection type property

This patch adds a DRM ENUM property to the selected connectors.
This property is used for mentioning the protected content's type
from userspace to kernel HDCP authentication.

Type of the stream is decided by the protected content providers.
Type 0 content can be rendered on any HDCP protected display wires.
But Type 1 content can be rendered only on HDCP2.2 protected paths.

So when a userspace sets this property to Type 1 and starts the HDCP
enable, kernel will honour it only if HDCP2.2 authentication is through
for type 1. Else HDCP enable will be failed.

Pekka have completed the Weston DRM-backend review in
https://gitlab.freedesktop.org/wayland/weston/merge_requests/48
and the UAPI for HDCP 2.2 looks good.

The userspace is accepted in Weston.

v2:
cp_content_type is replaced with content_protection_type [daniel]
check at atomic_set_property is removed [Maarten]
v3:
%s/content_protection_type/hdcp_content_type [Pekka]
v4:
property is created for the first requested connector and then reused.
[Danvet]
v5:
kernel doc nits addressed [Daniel]
Rebased as part of patch reordering.
v6:
Kernel docs are modified [pekka]
v7:
More details in Kernel docs. [pekka]
v8:
Few more clarification into kernel doc of content type [pekka]
v9:
Small fixes in coding style.
v10:
Moving DRM_MODE_HDCP_CONTENT_TYPEx definition to drm_hdcp.h [pekka]

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/320957/?series=57232&rev=14

drm/i915: fix possible memory leak in intel_hdcp_auth_downstream()

'ksv_fifo' is malloced in intel_hdcp_auth_downstream() and should be
freed before leaving from the error handling cases, otherwise it will
cause memory leak.

Fixes: f26ae6a652f2 ("drm/i915: SRM revocation check for HDCP1.4 and 2.2")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190704104534.12508-1-weiyongjun1@huawei.com
(cherry picked from commit de70fdd7d24cd07e51fbec420f8704d956a47949)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: fix possible memory leak in intel_hdcp_auth_downstream()

'ksv_fifo' is malloced in intel_hdcp_auth_downstream() and should be
freed before leaving from the error handling cases, otherwise it will
cause memory leak.

Fixes: f26ae6a652f2 ("drm/i915: SRM revocation check for HDCP1.4 and 2.2")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190704104534.12508-1-weiyongjun1@huawei.com

drm/i915/hdcp: debug logs for sink related failures

Adding few more debug logs to identify the sink specific HDCP failures
along with a out of mem failure.

v2:
Capturing the Bug and a-b

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110991
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
cc: Daniel Vetter <daniel@ffwll.ch>
Acked-by: Daniel Vetter <daniel@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20190708113319.2517-1-ramalingam.c@intel.com

drm/i915: move modesetting core code under display/

Now that we have a new subdirectory for display code, continue by moving
modesetting core code.

display/intel_frontbuffer.h sticks out like a sore thumb, otherwise this
is, again, a surprisingly clean operation.

v2:
- don't move intel_sideband.[ch] (Ville)
- use tabs for Makefile file lists and sort them

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190613084416.6794-3-jani.nikula@intel.com