Re: [PATCH v10 07/40] drm/i915: hdcp1.4 CP_IRQ handling and SW encryption tracking
On Thu, Jan 31, 2019 at 12:29:23PM +0530, Ramalingam C wrote:
> "hdcp_encrypted" flag is defined to denote the HDCP1.4 encryption status.
> This SW tracking is used to determine the need for real hdcp1.4 disable
> and hdcp_check_link upon CP_IRQ.
>
> On CP_IRQ we filter the CP_IRQ related to the states like Link failure
> and reauthentication req etc and handle them in hdcp_check_link.
> CP_IRQ corresponding to the authentication msg availability are ignored.
>
> WARN_ON is added for the abrupt stop of HDCP encryption of a port.
>
> v2:
> bool is used in struct for the cleaner coding. [Daniel]
> check_link work_fn is scheduled for cp_irq handling [Daniel]
Just doing a delta-review, v2 addresses my comment about synchronization
with the worker, so
Reviewed-by: Daniel Vetter
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/intel_dp.c | 2 +-
> drivers/gpu/drm/i915/intel_drv.h | 5 ++-
> drivers/gpu/drm/i915/intel_hdcp.c | 73
> ---
> 3 files changed, 58 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 815ee68efa2f..9ce05819fc11 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4776,7 +4776,7 @@ static void intel_dp_check_service_irq(struct intel_dp
> *intel_dp)
> intel_dp_handle_test_request(intel_dp);
>
> if (val & DP_CP_IRQ)
> - intel_hdcp_check_link(intel_dp->attached_connector);
> + intel_hdcp_handle_cp_irq(intel_dp->attached_connector);
>
> if (val & DP_SINK_SPECIFIC_IRQ)
> DRM_DEBUG_DRIVER("Sink specific irq unhandled\n");
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 63e009286d5f..13a41e8cf4ff 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -399,6 +399,9 @@ struct intel_hdcp {
> struct delayed_work check_work;
> struct work_struct prop_work;
>
> + /* HDCP1.4 Encryption status */
> + bool hdcp_encrypted;
> +
> /* HDCP2.2 related definitions */
> /* Flag indicates whether this connector supports HDCP2.2 or not. */
> bool hdcp2_supported;
> @@ -2073,10 +2076,10 @@ int intel_hdcp_init(struct intel_connector *connector,
> bool hdcp2_supported);
> int intel_hdcp_enable(struct intel_connector *connector);
> int intel_hdcp_disable(struct intel_connector *connector);
> -int intel_hdcp_check_link(struct intel_connector *connector);
> bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port);
> bool intel_hdcp_capable(struct intel_connector *connector);
> bool is_hdcp2_supported(struct drm_i915_private *dev_priv);
> +void intel_hdcp_handle_cp_irq(struct intel_connector *connector);
>
> /* intel_psr.c */
> #define CAN_PSR(dev_priv) (HAS_PSR(dev_priv) && dev_priv->psr.sink_support)
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index e0bb5f32ba90..c1b057f1501b 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -74,6 +74,16 @@ bool intel_hdcp_capable(struct intel_connector *connector)
> return capable;
> }
>
> +static inline bool intel_hdcp_in_use(struct intel_connector *connector)
> +{
> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> + enum port port = connector->encoder->port;
> + u32 reg;
> +
> + reg = I915_READ(PORT_HDCP_STATUS(port));
> + return reg & HDCP_STATUS_ENC;
> +}
> +
> static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port
> *intel_dig_port,
> const struct intel_hdcp_shim *shim)
> {
> @@ -668,6 +678,7 @@ static int _intel_hdcp_disable(struct intel_connector
> *connector)
> DRM_DEBUG_KMS("[%s:%d] HDCP is being disabled...\n",
> connector->base.name, connector->base.base.id);
>
> + hdcp->hdcp_encrypted = false;
> I915_WRITE(PORT_HDCP_CONF(port), 0);
> if (intel_wait_for_register(dev_priv, PORT_HDCP_STATUS(port), ~0, 0,
> ENCRYPT_STATUS_CHANGE_TIMEOUT_MS)) {
> @@ -713,8 +724,10 @@ static int _intel_hdcp_enable(struct intel_connector
> *connector)
> /* Incase of authentication failures, HDCP spec expects reauth. */
> for (i = 0; i < tries; i++) {
> ret = intel_hdcp_auth(conn_to_dig_port(connector), hdcp->shim);
> - if (!ret)
> + if (!ret) {
> + hdcp->hdcp_encrypted = true;
> return 0;
> + }
>
> DRM_DEBUG_KMS("HDCP Auth failure (%d)\n", ret);
>
> @@ -741,16 +754,17 @@ int intel_hdcp_check_link(struct intel_connector
> *connector)
> enum port port = intel_dig_port->base.port;
> int ret = 0;
>
> - if (!hdcp->shim)
> - return -ENOENT;
> -
> mutex_lock(>mutex);
>
> -
Re: [PATCH v10 01/40] components: multiple components for a device
On Thu, Jan 31, 2019 at 12:29:17PM +0530, Ramalingam C wrote:
> +void component_match_add_typed(struct device *master,
> + struct component_match **matchptr,
> + int (*compare_typed)(struct device *, int, void *), void *compare_data)
> +{
> + __component_match_add(master, matchptr, NULL, NULL, compare_typed,
> + compare_data);
> +}
> +EXPORT_SYMBOL(component_match_add_typed);
No comment at all as to what this new global function does?
> +int component_add_typed(struct device *dev, const struct component_ops *ops,
> + int subcomponent)
> +{
> + if (WARN_ON(subcomponent == 0))
> + return -EINVAL;
> +
> + return __component_add(dev, ops, subcomponent);
> +}
> +EXPORT_SYMBOL_GPL(component_add_typed);
Same here, no comments at all?
Please at the very least, document new things that you add, I thought I
asked for this the last time this patch was posted :(
greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 40/40] FOR_TESTING_ONLY: debugfs: Excluding the LSPCon for HDCP1.4
Just excluding the LSPCon HDMI ports from the HDCP1.4 testing.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/i915_debugfs.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index fa2c226fc779..4935448891be 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4794,6 +4794,9 @@ static int i915_hdcp_sink_capability_show(struct seq_file
*m, void *data)
{
struct drm_connector *connector = m->private;
struct intel_connector *intel_connector = to_intel_connector(connector);
+ struct intel_digital_port *intel_dig_port =
+ conn_to_dig_port(intel_connector);
+ bool is_hdcp14;
if (connector->status != connector_status_connected)
return -ENODEV;
@@ -4804,8 +4807,11 @@ static int i915_hdcp_sink_capability_show(struct
seq_file *m, void *data)
seq_printf(m, "%s:%d HDCP version: ", connector->name,
connector->base.id);
- seq_printf(m, "%s ", !intel_hdcp_capable(intel_connector) ?
- "None" : "HDCP1.4");
+
+ /* Excluding the Lspcon for Testing Purpose */
+ is_hdcp14 = intel_hdcp_capable(intel_connector) &&
+ !intel_dig_port->lspcon.active;
+ seq_printf(m, "%s ", !is_hdcp14 ? "None" : "HDCP1.4");
seq_puts(m, "\n");
return 0;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 34/40] misc/mei/hdcp: Enabling the HDCP authentication
Request to ME to configure a port as authenticated.
On Success, ME FW will mark the port as authenticated and provides
HDCP cipher with the encryption keys.
Enabling the Authentication can be requested once all stages of
HDCP2.2 authentication is completed by interacting with ME FW.
Only after this stage, driver can enable the HDCP encryption for
the port, through HW registers.
v2: Rebased.
v3:
cldev is passed as first parameter [Tomas]
Redundant comments and cast are removed [Tomas]
v4:
%zd for ssize_t [Alexander]
%s/return -1/return -EIO [Alexander]
Style and typos fixed [Uma]
v5: Rebased.
v6:
Collected the Rb-ed by.
Rebased.
v7:
Adjust to the new mei interface.
Fix for Kdoc.
v8:
K-Doc addition. [Tomas]
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/misc/mei/hdcp/mei_hdcp.c | 54 +++-
1 file changed, 53 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 91f7b08d1df1..5303c729612b 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -587,6 +587,58 @@ static int mei_verify_mprime(struct device *dev, struct
hdcp_port_data *data,
return 0;
}
+/**
+ * mei_enable_hdcp_authentication() - Mark a port as authenticated through ME
FW
+ * @dev: device corresponding to the mei_cl_device
+ * @hdcp_data: Intel HW specific hdcp data
+ *
+ * Return: 0 on Success, <0 on Failure
+ */
+static int
+mei_enable_hdcp_authentication(struct device *dev, struct hdcp_port_data *data)
+{
+ struct wired_cmd_enable_auth_in enable_auth_in = { { 0 } };
+ struct wired_cmd_enable_auth_out enable_auth_out = { { 0 } };
+ struct mei_cl_device *cldev;
+ ssize_t byte;
+
+ if (!dev || !data)
+ return -EINVAL;
+
+ cldev = to_mei_cl_device(dev);
+
+ enable_auth_in.header.api_version = HDCP_API_VERSION;
+ enable_auth_in.header.command_id = WIRED_ENABLE_AUTH;
+ enable_auth_in.header.status = ME_HDCP_STATUS_SUCCESS;
+ enable_auth_in.header.buffer_len = WIRED_CMD_BUF_LEN_ENABLE_AUTH_IN;
+
+ enable_auth_in.port.integrated_port_type = data->port_type;
+ enable_auth_in.port.physical_port = (u8)GET_MEI_DDI_INDEX(data->port);
+ enable_auth_in.stream_type = data->streams[0].stream_type;
+
+ byte = mei_cldev_send(cldev, (u8 *)_auth_in,
+ sizeof(enable_auth_in));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+ return byte;
+ }
+
+ byte = mei_cldev_recv(cldev, (u8 *)_auth_out,
+ sizeof(enable_auth_out));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
+ return byte;
+ }
+
+ if (enable_auth_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+ dev_dbg(dev, "ME cmd 0x%08X failed. status: 0x%X\n",
+ WIRED_ENABLE_AUTH, enable_auth_out.header.status);
+ return -EIO;
+ }
+
+ return 0;
+}
+
static __attribute__((unused))
struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
@@ -599,7 +651,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
.get_session_key = mei_get_session_key,
.repeater_check_flow_prepare_ack = mei_repeater_check_flow_prepare_ack,
.verify_mprime = mei_verify_mprime,
- .enable_hdcp_authentication = NULL,
+ .enable_hdcp_authentication = mei_enable_hdcp_authentication,
.close_hdcp_session = NULL,
};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 39/40] FOR_TEST: i915/Kconfig: Select mei_hdcp by I915
FOR TESTING PURPOSE ONLY. By default INTEL_MEI_HDCP is set to y. This patch is created to test the interface between I915 and MEI_HDCP. Signed-off-by: Ramalingam C --- drivers/misc/mei/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/misc/mei/Kconfig b/drivers/misc/mei/Kconfig index 9c518b7f0011..90ed55210447 100644 --- a/drivers/misc/mei/Kconfig +++ b/drivers/misc/mei/Kconfig @@ -48,5 +48,6 @@ config INTEL_MEI_HDCP tristate "Intel HDCP2.2 services of ME Interface" select INTEL_MEI_ME depends on DRM_I915 + default y help MEI Support for HDCP2.2 Services on Intel SoCs. -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 26/40] misc/mei/hdcp: Verify Receiver Cert and prepare km
Requests for verification for receiver certification and also the
preparation for next AKE auth message with km.
On Success ME FW validate the HDCP2.2 receivers certificate and do the
revocation check on the receiver ID. AKE_Stored_Km will be prepared if
the receiver is already paired, else AKE_No_Stored_Km will be prepared.
Here AKE_Stored_Km and AKE_No_Stored_Km are HDCP2.2 protocol msgs.
v2: Rebased.
v3:
cldev is passed as first parameter [Tomas]
Redundant comments and cast are removed [Tomas]
v4:
%zd is used for ssize_t [Alexander]
%s/return -1/return -EIO [Alexander]
v5: Rebased.
v6:
Collected the Rb-ed by.
Rebasing.
v7:
Adjust to the new mei interface.
Fix for Kdoc.
v8:
K-Doc Addition. [Tomas]
memcpy for const length.
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/misc/mei/hdcp/mei_hdcp.c | 81 +++-
1 file changed, 80 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 534d29c8ee86..24665fff640d 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -90,11 +90,90 @@ mei_initiate_hdcp2_session(struct device *dev, struct
hdcp_port_data *data,
return 0;
}
+/**
+ * mei_verify_receiver_cert_prepare_km() - Verify the Receiver Certificate
+ * AKE_Send_Cert and prepare AKE_Stored_Km/AKE_No_Stored_Km
+ * @dev: device corresponding to the mei_cl_device
+ * @hdcp_data: Intel HW specific hdcp data
+ * @rx_cert: AKE_Send_Cert for verification
+ * @km_stored: Pairing status flag output
+ * @ek_pub_km: AKE_Stored_Km/AKE_No_Stored_Km output msg
+ * @msg_sz : size of AKE_X_Km output msg
+ *
+ * Return: 0 on Success, <0 on Failure
+ */
+static int
+mei_verify_receiver_cert_prepare_km(struct device *dev,
+ struct hdcp_port_data *data,
+ struct hdcp2_ake_send_cert *rx_cert,
+ bool *km_stored,
+ struct hdcp2_ake_no_stored_km *ek_pub_km,
+ size_t *msg_sz)
+{
+ struct wired_cmd_verify_receiver_cert_in verify_rxcert_in = { { 0 } };
+ struct wired_cmd_verify_receiver_cert_out verify_rxcert_out = { { 0 } };
+ struct mei_cl_device *cldev;
+ ssize_t byte;
+
+ if (!dev || !data || !rx_cert || !km_stored || !ek_pub_km || !msg_sz)
+ return -EINVAL;
+
+ cldev = to_mei_cl_device(dev);
+
+ verify_rxcert_in.header.api_version = HDCP_API_VERSION;
+ verify_rxcert_in.header.command_id = WIRED_VERIFY_RECEIVER_CERT;
+ verify_rxcert_in.header.status = ME_HDCP_STATUS_SUCCESS;
+ verify_rxcert_in.header.buffer_len =
+ WIRED_CMD_BUF_LEN_VERIFY_RECEIVER_CERT_IN;
+
+ verify_rxcert_in.port.integrated_port_type = data->port_type;
+ verify_rxcert_in.port.physical_port = (u8)GET_MEI_DDI_INDEX(data->port);
+
+ verify_rxcert_in.cert_rx = rx_cert->cert_rx;
+ memcpy(verify_rxcert_in.r_rx, _cert->r_rx, HDCP_2_2_RRX_LEN);
+ memcpy(verify_rxcert_in.rx_caps, rx_cert->rx_caps, HDCP_2_2_RXCAPS_LEN);
+
+ byte = mei_cldev_send(cldev, (u8 *)_rxcert_in,
+ sizeof(verify_rxcert_in));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_send failed: %zd\n", byte);
+ return byte;
+ }
+
+ byte = mei_cldev_recv(cldev, (u8 *)_rxcert_out,
+ sizeof(verify_rxcert_out));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_recv failed: %zd\n", byte);
+ return byte;
+ }
+
+ if (verify_rxcert_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+ dev_dbg(dev, "ME cmd 0x%08X Failed. Status: 0x%X\n",
+ WIRED_VERIFY_RECEIVER_CERT,
+ verify_rxcert_out.header.status);
+ return -EIO;
+ }
+
+ *km_stored = verify_rxcert_out.km_stored;
+ if (verify_rxcert_out.km_stored) {
+ ek_pub_km->msg_id = HDCP_2_2_AKE_STORED_KM;
+ *msg_sz = sizeof(struct hdcp2_ake_stored_km);
+ } else {
+ ek_pub_km->msg_id = HDCP_2_2_AKE_NO_STORED_KM;
+ *msg_sz = sizeof(struct hdcp2_ake_no_stored_km);
+ }
+
+ memcpy(ek_pub_km->e_kpub_km, _rxcert_out.ekm_buff,
+ sizeof(verify_rxcert_out.ekm_buff));
+
+ return 0;
+}
+
static __attribute__((unused))
struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
.initiate_hdcp2_session = mei_initiate_hdcp2_session,
- .verify_receiver_cert_prepare_km = NULL,
+ .verify_receiver_cert_prepare_km = mei_verify_receiver_cert_prepare_km,
.verify_hprime = NULL,
.store_pairing_info = NULL,
.initiate_locality_check = NULL,
--
2.7.4
___
dri-devel mailing list
[PATCH v10 33/40] misc/mei/hdcp: Verify M_prime
Request to ME to verify the M_Prime received from the HDCP sink.
ME FW will calculate the M and compare with M_prime received
as part of RepeaterAuth_Stream_Ready, which is HDCP2.2 protocol msg.
On successful completion of this stage, downstream propagation of
the stream management info is completed.
v2: Rebased.
v3:
cldev is passed as first parameter [Tomas]
Redundant comments and cast are removed [Tomas]
v4:
%zd for ssize_t [Alexander]
%s/return -1/return -EIO [Alexander]
endianness conversion func is moved to drm_hdcp.h [Uma]
v5: Rebased.
v6:
Collected the Rb-ed by.
Rebasing.
v7:
Adjust to the new mei interface.
Fix for Kdoc.
v8:
K-Doc addition. [Tomas]
drm_hdcp2_u32_to_seq_num() is used for u32 to seq_num.
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/misc/mei/hdcp/mei_hdcp.c | 66 +++-
1 file changed, 65 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index c157c18371b4..91f7b08d1df1 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -523,6 +523,70 @@ mei_repeater_check_flow_prepare_ack(struct device *dev,
return 0;
}
+/**
+ * mei_verify_mprime() - Verify mprime.
+ * @dev: device corresponding to the mei_cl_device
+ * @hdcp_data: Intel HW specific hdcp data
+ * @stream_ready: RepeaterAuth_Stream_Ready msg for ME FW verification.
+ *
+ * Return: 0 on Success, <0 on Failure
+ */
+static int mei_verify_mprime(struct device *dev, struct hdcp_port_data *data,
+struct hdcp2_rep_stream_ready *stream_ready)
+{
+ struct wired_cmd_repeater_auth_stream_req_in
+ verify_mprime_in = { { 0 } };
+ struct wired_cmd_repeater_auth_stream_req_out
+ verify_mprime_out = { { 0 } };
+ struct mei_cl_device *cldev;
+ ssize_t byte;
+
+ if (!dev || !stream_ready || !data)
+ return -EINVAL;
+
+ cldev = to_mei_cl_device(dev);
+
+ verify_mprime_in.header.api_version = HDCP_API_VERSION;
+ verify_mprime_in.header.command_id = WIRED_REPEATER_AUTH_STREAM_REQ;
+ verify_mprime_in.header.status = ME_HDCP_STATUS_SUCCESS;
+ verify_mprime_in.header.buffer_len =
+ WIRED_CMD_BUF_LEN_REPEATER_AUTH_STREAM_REQ_MIN_IN;
+
+ verify_mprime_in.port.integrated_port_type = data->port_type;
+ verify_mprime_in.port.physical_port = (u8)GET_MEI_DDI_INDEX(data->port);
+
+ memcpy(verify_mprime_in.m_prime, stream_ready->m_prime,
+ HDCP_2_2_MPRIME_LEN);
+ drm_hdcp2_u32_to_seq_num(verify_mprime_in.seq_num_m, data->seq_num_m);
+ memcpy(verify_mprime_in.streams, data->streams,
+ (data->k * sizeof(struct hdcp2_streamid_type)));
+
+ verify_mprime_in.k = __swab16(data->k);
+
+ byte = mei_cldev_send(cldev, (u8 *)_mprime_in,
+ sizeof(verify_mprime_in));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+ return byte;
+ }
+
+ byte = mei_cldev_recv(cldev, (u8 *)_mprime_out,
+ sizeof(verify_mprime_out));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
+ return byte;
+ }
+
+ if (verify_mprime_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+ dev_dbg(dev, "ME cmd 0x%08X failed. status: 0x%X\n",
+ WIRED_REPEATER_AUTH_STREAM_REQ,
+ verify_mprime_out.header.status);
+ return -EIO;
+ }
+
+ return 0;
+}
+
static __attribute__((unused))
struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
@@ -534,7 +598,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
.verify_lprime = mei_verify_lprime,
.get_session_key = mei_get_session_key,
.repeater_check_flow_prepare_ack = mei_repeater_check_flow_prepare_ack,
- .verify_mprime = NULL,
+ .verify_mprime = mei_verify_mprime,
.enable_hdcp_authentication = NULL,
.close_hdcp_session = NULL,
};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 38/40] drm/i915: Fix KBL HDCP2.2 encrypt status signalling
Implement the required WA sequence for KBL to fix the
incorrect positioning of the window of oppurtunity and enc_en
signalling.
v2:
WA is moved into the toggle_signalling [Daniel]
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdmi.c | 42 +++
1 file changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 2c4bf6d0c39f..ae20288f7bbf 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1083,10 +1083,44 @@ int intel_hdmi_hdcp_read_v_prime_part(struct
intel_digital_port *intel_dig_port,
return ret;
}
+static int kbl_repositioning_enc_en_signal(struct intel_connector *connector)
+{
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+ struct drm_crtc *crtc = connector->base.state->crtc;
+ struct intel_crtc *intel_crtc = container_of(crtc,
+struct intel_crtc, base);
+ u32 scanline;
+ int ret;
+
+ for (;;) {
+ scanline = I915_READ(PIPEDSL(intel_crtc->pipe));
+ if (scanline > 100 && scanline < 200)
+ break;
+ usleep_range(25, 50);
+ }
+
+ ret = intel_ddi_toggle_hdcp_signalling(_dig_port->base, false);
+ if (ret) {
+ DRM_ERROR("Disable HDCP signalling failed (%d)\n", ret);
+ return ret;
+ }
+ ret = intel_ddi_toggle_hdcp_signalling(_dig_port->base, true);
+ if (ret) {
+ DRM_ERROR("Enable HDCP signalling failed (%d)\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
static
int intel_hdmi_hdcp_toggle_signalling(struct intel_digital_port
*intel_dig_port,
bool enable)
{
+ struct intel_hdmi *hdmi = _dig_port->hdmi;
+ struct intel_connector *connector = hdmi->attached_connector;
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
int ret;
if (!enable)
@@ -1098,6 +1132,14 @@ int intel_hdmi_hdcp_toggle_signalling(struct
intel_digital_port *intel_dig_port,
enable ? "Enable" : "Disable", ret);
return ret;
}
+
+ /*
+* WA: To fix incorrect positioning of the window of
+* opportunity and enc_en signalling in KABYLAKE.
+*/
+ if (IS_KABYLAKE(dev_priv) && enable)
+ return kbl_repositioning_enc_en_signal(connector);
+
return 0;
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 37/40] drm/i915: Commit CP without modeset
Commits the content protection change of a connector,
without crtc modeset. This improves the user experience.
Originally proposed by Sean Paul at v3 of HDCP1.4 framework
https://patchwork.freedesktop.org/patch/191759/. For some
reason this was dropped, but needed for the proper functionality
of HDCP encryption.
Signed-off-by: Ramalingam C
Suggested-by: Sean Paul
---
drivers/gpu/drm/i915/intel_ddi.c | 7 ---
drivers/gpu/drm/i915/intel_display.c | 10 ++
drivers/gpu/drm/i915/intel_drv.h | 5 +
drivers/gpu/drm/i915/intel_hdcp.c| 32
4 files changed, 43 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index ca705546a0ab..9cb03c1b0abc 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3495,11 +3495,6 @@ static void intel_enable_ddi(struct intel_encoder
*encoder,
intel_enable_ddi_hdmi(encoder, crtc_state, conn_state);
else
intel_enable_ddi_dp(encoder, crtc_state, conn_state);
-
- /* Enable hdcp if it's desired */
- if (conn_state->content_protection ==
- DRM_MODE_CONTENT_PROTECTION_DESIRED)
- intel_hdcp_enable(to_intel_connector(conn_state->connector));
}
static void intel_disable_ddi_dp(struct intel_encoder *encoder,
@@ -3542,8 +3537,6 @@ static void intel_disable_ddi(struct intel_encoder
*encoder,
const struct intel_crtc_state *old_crtc_state,
const struct drm_connector_state *old_conn_state)
{
- intel_hdcp_disable(to_intel_connector(old_conn_state->connector));
-
if (intel_crtc_has_type(old_crtc_state, INTEL_OUTPUT_HDMI))
intel_disable_ddi_hdmi(encoder, old_crtc_state, old_conn_state);
else
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a025efb1d7c6..9b964dabb57c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13034,6 +13034,8 @@ static void intel_atomic_commit_tail(struct
drm_atomic_state *state)
struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_crtc_state *old_crtc_state, *new_crtc_state;
struct intel_crtc_state *new_intel_crtc_state, *old_intel_crtc_state;
+ struct drm_connector_state *old_conn_state, *new_conn_state;
+ struct drm_connector *connector;
struct drm_crtc *crtc;
struct intel_crtc *intel_crtc;
u64 put_domains[I915_MAX_PIPES] = {};
@@ -13128,9 +13130,17 @@ static void intel_atomic_commit_tail(struct
drm_atomic_state *state)
}
}
+ for_each_oldnew_connector_in_state(state, connector, old_conn_state,
+ new_conn_state, i)
+ intel_hdcp_atomic_pre_commit(connector, old_conn_state,
+new_conn_state);
+
/* Now enable the clocks, plane, pipe, and connectors that we set up. */
dev_priv->display.update_crtcs(state);
+ for_each_new_connector_in_state(state, connector, new_conn_state, i)
+ intel_hdcp_atomic_commit(connector, new_conn_state);
+
/* FIXME: We should call drm_atomic_helper_commit_hw_done() here
* already, but still need the state for the delayed optimization. To
* fix this:
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 1901d12bacc4..e6b6e920ab01 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -2129,6 +2129,11 @@ static inline void
intel_backlight_device_unregister(struct intel_connector *con
void intel_hdcp_atomic_check(struct drm_connector *connector,
struct drm_connector_state *old_state,
struct drm_connector_state *new_state);
+void intel_hdcp_atomic_pre_commit(struct drm_connector *connector,
+ struct drm_connector_state *old_state,
+ struct drm_connector_state *new_state);
+void intel_hdcp_atomic_commit(struct drm_connector *connector,
+ struct drm_connector_state *new_state);
int intel_hdcp_init(struct intel_connector *connector,
const struct intel_hdcp_shim *hdcp_shim,
bool hdcp2_supported);
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index f38feeadb363..ef127dc7a241 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -1876,7 +1876,6 @@ void intel_hdcp_atomic_check(struct drm_connector
*connector,
{
u64 old_cp = old_state->content_protection;
u64 new_cp = new_state->content_protection;
- struct drm_crtc_state *crtc_state;
if (!new_state->crtc) {
/*
@@ -1897,10 +1896,35 @@ void
[PATCH v10 36/40] misc/mei/hdcp: Component framework for I915 Interface
Mei hdcp driver is designed as component slave for the I915 component
master.
v2: Rebased.
v3:
Notifier chain is adopted for cldev state update [Tomas]
v4:
Made static dummy functions as inline in mei_hdcp.h
API for polling client device status
IS_ENABLED used in header, for config status for mei_hdcp.
v5:
Replacing the notifier with component framework. [Daniel]
v6:
Rebased on the I915 comp master redesign.
v7:
mei_hdcp_component_registered is made static [Uma]
Need for global static variable mei_cldev is removed.
v8:
master comp is added to be matched with i915 subcomponent [daniel]
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/misc/mei/hdcp/mei_hdcp.c | 90 +++-
drivers/misc/mei/hdcp/mei_hdcp.h | 5 +++
2 files changed, 93 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index edfc70fb0617..be2ce12ca460 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -692,8 +693,7 @@ mei_close_hdcp_session(struct device *dev, struct
hdcp_port_data *data)
return 0;
}
-static __attribute__((unused))
-struct i915_hdcp_component_ops mei_hdcp_ops = {
+static struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
.initiate_hdcp2_session = mei_initiate_hdcp2_session,
.verify_receiver_cert_prepare_km = mei_verify_receiver_cert_prepare_km,
@@ -708,20 +708,106 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
.close_hdcp_session = mei_close_hdcp_session,
};
+static int mei_component_master_bind(struct device *dev)
+{
+ struct mei_cl_device *cldev = to_mei_cl_device(dev);
+ struct mei_hdcp_drv_data *drv_data = mei_cldev_get_drvdata(cldev);
+ int ret;
+
+ dev_info(dev, "%s\n", __func__);
+ drv_data->comp_master->ops = _hdcp_ops;
+ drv_data->comp_master->mei_dev = dev;
+ ret = component_bind_all(dev, drv_data->comp_master);
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
+static void mei_component_master_unbind(struct device *dev)
+{
+ struct mei_cl_device *cldev = to_mei_cl_device(dev);
+ struct mei_hdcp_drv_data *drv_data = mei_cldev_get_drvdata(cldev);
+
+ dev_info(dev, "%s\n", __func__);
+ component_unbind_all(dev, drv_data->comp_master);
+}
+
+static const struct component_master_ops mei_component_master_ops = {
+ .bind = mei_component_master_bind,
+ .unbind = mei_component_master_unbind,
+};
+
+static int mei_hdcp_component_match(struct device *dev, int subcomponent,
+ void *data)
+{
+ return !strcmp(dev->driver->name, "i915") &&
+ subcomponent == I915_COMPONENT_HDCP;
+}
+
static int mei_hdcp_probe(struct mei_cl_device *cldev,
const struct mei_cl_device_id *id)
{
+ struct mei_hdcp_drv_data *drv_data;
int ret;
ret = mei_cldev_enable(cldev);
if (ret < 0)
dev_err(>dev, "mei_cldev_enable Failed. %d\n", ret);
+ drv_data = kzalloc(sizeof(*drv_data), GFP_KERNEL);
+ if (!drv_data) {
+ ret = -ENOMEM;
+ goto drv_data_exit;
+ }
+
+ drv_data->comp_master = kzalloc(sizeof(*drv_data->comp_master),
+ GFP_KERNEL);
+ if (!drv_data->comp_master) {
+ ret = -ENOMEM;
+ goto comp_master_exit;
+ }
+
+ drv_data->master_match = NULL;
+ component_match_add_typed(>dev, _data->master_match,
+ mei_hdcp_component_match,
+ drv_data->comp_master);
+ if (IS_ERR_OR_NULL(drv_data->master_match)) {
+ ret = -ENOMEM;
+ goto match_add_exit;
+ }
+
+ mei_cldev_set_drvdata(cldev, drv_data);
+ ret = component_master_add_with_match(>dev,
+ _component_master_ops,
+ drv_data->master_match);
+ if (ret < 0) {
+ dev_err(>dev, "Master comp add failed %d\n", ret);
+ mei_cldev_set_drvdata(cldev, NULL);
+ goto match_add_exit;
+ }
+
+ return 0;
+
+match_add_exit:
+ kfree(drv_data->comp_master);
+comp_master_exit:
+ kfree(drv_data);
+drv_data_exit:
+ mei_cldev_disable(cldev);
+
return ret;
}
static int mei_hdcp_remove(struct mei_cl_device *cldev)
{
+ struct mei_hdcp_drv_data *drv_data = mei_cldev_get_drvdata(cldev);
+
+ component_master_del(>dev, _component_master_ops);
+ kfree(drv_data->comp_master);
+ kfree(drv_data);
+ mei_cldev_set_drvdata(cldev, NULL);
+
return mei_cldev_disable(cldev);
}
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.h
[PATCH v10 32/40] misc/mei/hdcp: Repeater topology verification and ack
Request ME to verify the downstream topology information received.
ME FW will validate the Repeaters receiver id list and
downstream topology.
On Success ME FW will provide the Least Significant
128bits of VPrime, which forms the repeater ack.
v2: Rebased.
v3:
cldev is passed as first parameter [Tomas]
Redundant comments and cast are removed [Tomas]
v4:
%zd for ssize_t [Alexander]
%s/return -1/return -EIO [Alexander]
Style and typos fixed [Uma]
v5: Rebased.
v6: Rebasing.
v7:
Adjust to the new mei interface.
Fix for Kdoc.
v8:
K-Doc addition. [Tomas]
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/misc/mei/hdcp/mei_hdcp.c | 76 +++-
1 file changed, 75 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 2be7b6b949c2..c157c18371b4 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -449,6 +449,80 @@ static int mei_get_session_key(struct device *dev, struct
hdcp_port_data *data,
return 0;
}
+/**
+ * mei_repeater_check_flow_prepare_ack() - Validate the Downstream topology
+ * and prepare rep_ack.
+ * @dev: device corresponding to the mei_cl_device
+ * @hdcp_data: Intel HW specific hdcp data
+ * @rep_topology: Receiver ID List to be validated
+ * @rep_send_ack : repeater ack from ME FW.
+ *
+ * Return: 0 on Success, <0 on Failure
+ */
+static int
+mei_repeater_check_flow_prepare_ack(struct device *dev,
+ struct hdcp_port_data *data,
+ struct hdcp2_rep_send_receiverid_list
+ *rep_topology,
+ struct hdcp2_rep_send_ack *rep_send_ack)
+{
+ struct wired_cmd_verify_repeater_in verify_repeater_in = { { 0 } };
+ struct wired_cmd_verify_repeater_out verify_repeater_out = { { 0 } };
+ struct mei_cl_device *cldev;
+ ssize_t byte;
+
+ if (!dev || !rep_topology || !rep_send_ack || !data)
+ return -EINVAL;
+
+ cldev = to_mei_cl_device(dev);
+
+ verify_repeater_in.header.api_version = HDCP_API_VERSION;
+ verify_repeater_in.header.command_id = WIRED_VERIFY_REPEATER;
+ verify_repeater_in.header.status = ME_HDCP_STATUS_SUCCESS;
+ verify_repeater_in.header.buffer_len =
+ WIRED_CMD_BUF_LEN_VERIFY_REPEATER_IN;
+
+ verify_repeater_in.port.integrated_port_type = data->port_type;
+ verify_repeater_in.port.physical_port =
+ (u8)GET_MEI_DDI_INDEX(data->port);
+
+ memcpy(verify_repeater_in.rx_info, rep_topology->rx_info,
+ HDCP_2_2_RXINFO_LEN);
+ memcpy(verify_repeater_in.seq_num_v, rep_topology->seq_num_v,
+ HDCP_2_2_SEQ_NUM_LEN);
+ memcpy(verify_repeater_in.v_prime, rep_topology->v_prime,
+ HDCP_2_2_V_PRIME_HALF_LEN);
+ memcpy(verify_repeater_in.receiver_ids, rep_topology->receiver_ids,
+ HDCP_2_2_RECEIVER_IDS_MAX_LEN);
+
+ byte = mei_cldev_send(cldev, (u8 *)_repeater_in,
+ sizeof(verify_repeater_in));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+ return byte;
+ }
+
+ byte = mei_cldev_recv(cldev, (u8 *)_repeater_out,
+ sizeof(verify_repeater_out));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
+ return byte;
+ }
+
+ if (verify_repeater_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+ dev_dbg(dev, "ME cmd 0x%08X failed. status: 0x%X\n",
+ WIRED_VERIFY_REPEATER,
+ verify_repeater_out.header.status);
+ return -EIO;
+ }
+
+ memcpy(rep_send_ack->v, verify_repeater_out.v,
+ HDCP_2_2_V_PRIME_HALF_LEN);
+ rep_send_ack->msg_id = HDCP_2_2_REP_SEND_ACK;
+
+ return 0;
+}
+
static __attribute__((unused))
struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
@@ -459,7 +533,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
.initiate_locality_check = mei_initiate_locality_check,
.verify_lprime = mei_verify_lprime,
.get_session_key = mei_get_session_key,
- .repeater_check_flow_prepare_ack = NULL,
+ .repeater_check_flow_prepare_ack = mei_repeater_check_flow_prepare_ack,
.verify_mprime = NULL,
.enable_hdcp_authentication = NULL,
.close_hdcp_session = NULL,
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 30/40] misc/mei/hdcp: Verify L_prime
Request to ME to verify the LPrime received from HDCP sink.
On Success, ME FW will verify the received Lprime by calculating and
comparing with L.
This represents the completion of Locality Check.
v2: Rebased.
v3:
cldev is passed as first parameter [Tomas]
Redundant comments and cast are removed [Tomas]
v4:
%zd for ssize_t [Alexander]
%s/return -1/return -EIO [Alexander]
Style fixed [Uma]
v5: Rebased.
v6:
Collected the Rb-ed by.
Rebasing.
v7:
Adjust to the new mei interface.
Fix for Kdoc.
v8:
K-Doc addition. [Tomas]
memcpy for const length.
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/misc/mei/hdcp/mei_hdcp.c | 59 +++-
1 file changed, 58 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 412a33e29d7d..3d7767d944dc 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -336,6 +336,63 @@ mei_initiate_locality_check(struct device *dev, struct
hdcp_port_data *data,
return 0;
}
+/**
+ * mei_verify_lprime() - Verify lprime.
+ * @dev: device corresponding to the mei_cl_device
+ * @hdcp_data: Intel HW specific hdcp data
+ * @rx_lprime: LC_Send_L_prime msg for ME FW verification
+ *
+ * Return: 0 on Success, <0 on Failure
+ */
+static int mei_verify_lprime(struct device *dev, struct hdcp_port_data *data,
+struct hdcp2_lc_send_lprime *rx_lprime)
+{
+ struct wired_cmd_validate_locality_in verify_lprime_in = { { 0 } };
+ struct wired_cmd_validate_locality_out verify_lprime_out = { { 0 } };
+ struct mei_cl_device *cldev;
+ ssize_t byte;
+
+ if (!dev || !data || !rx_lprime)
+ return -EINVAL;
+
+ cldev = to_mei_cl_device(dev);
+
+ verify_lprime_in.header.api_version = HDCP_API_VERSION;
+ verify_lprime_in.header.command_id = WIRED_VALIDATE_LOCALITY;
+ verify_lprime_in.header.status = ME_HDCP_STATUS_SUCCESS;
+ verify_lprime_in.header.buffer_len =
+ WIRED_CMD_BUF_LEN_VALIDATE_LOCALITY_IN;
+
+ verify_lprime_in.port.integrated_port_type = data->port_type;
+ verify_lprime_in.port.physical_port = (u8)GET_MEI_DDI_INDEX(data->port);
+
+ memcpy(verify_lprime_in.l_prime, rx_lprime->l_prime,
+ HDCP_2_2_L_PRIME_LEN);
+
+ byte = mei_cldev_send(cldev, (u8 *)_lprime_in,
+ sizeof(verify_lprime_in));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+ return byte;
+ }
+
+ byte = mei_cldev_recv(cldev, (u8 *)_lprime_out,
+ sizeof(verify_lprime_out));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
+ return byte;
+ }
+
+ if (verify_lprime_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+ dev_dbg(dev, "ME cmd 0x%08X failed. status: 0x%X\n",
+ WIRED_VALIDATE_LOCALITY,
+ verify_lprime_out.header.status);
+ return -EIO;
+ }
+
+ return 0;
+}
+
static __attribute__((unused))
struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
@@ -344,7 +401,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
.verify_hprime = mei_verify_hprime,
.store_pairing_info = mei_store_pairing_info,
.initiate_locality_check = mei_initiate_locality_check,
- .verify_lprime = NULL,
+ .verify_lprime = mei_verify_lprime,
.get_session_key = NULL,
.repeater_check_flow_prepare_ack = NULL,
.verify_mprime = NULL,
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 35/40] misc/mei/hdcp: Closing wired HDCP2.2 Tx Session
Request the ME to terminate the HDCP2.2 session for a port.
On Success, ME FW will mark the intel port as Deauthenticated and
terminate the wired HDCP2.2 Tx session started due to the cmd
WIRED_INITIATE_HDCP2_SESSION.
v2: Rebased.
v3:
cldev is passed as first parameter [Tomas]
Redundant comments and cast are removed [Tomas]
v4:
%zd for ssize_t [Alexander]
%s/return -1/return -EIO [Alexander]
Style and typos fixed [Uma]
v5:
Extra line is removed.
v6:
Collected the Rb-ed by.
Rebased.
v7:
Adjust to the new mei interface.
Fix for Kdoc.
v8:
K-Doc addition.[Tomas]
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/misc/mei/hdcp/mei_hdcp.c | 55 +++-
1 file changed, 54 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 5303c729612b..edfc70fb0617 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -639,6 +639,59 @@ mei_enable_hdcp_authentication(struct device *dev, struct
hdcp_port_data *data)
return 0;
}
+/**
+ * mei_close_hdcp_session() - Close the Wired HDCP Tx session of ME FW per
port.
+ * This also disables the authenticated state of the port.
+ * @dev: device corresponding to the mei_cl_device
+ * @hdcp_data: Intel HW specific hdcp data
+ *
+ * Return: 0 on Success, <0 on Failure
+ */
+static int
+mei_close_hdcp_session(struct device *dev, struct hdcp_port_data *data)
+{
+ struct wired_cmd_close_session_in session_close_in = { { 0 } };
+ struct wired_cmd_close_session_out session_close_out = { { 0 } };
+ struct mei_cl_device *cldev;
+ ssize_t byte;
+
+ if (!dev || !data)
+ return -EINVAL;
+
+ cldev = to_mei_cl_device(dev);
+
+ session_close_in.header.api_version = HDCP_API_VERSION;
+ session_close_in.header.command_id = WIRED_CLOSE_SESSION;
+ session_close_in.header.status = ME_HDCP_STATUS_SUCCESS;
+ session_close_in.header.buffer_len =
+ WIRED_CMD_BUF_LEN_CLOSE_SESSION_IN;
+
+ session_close_in.port.integrated_port_type = data->port_type;
+ session_close_in.port.physical_port = (u8)GET_MEI_DDI_INDEX(data->port);
+
+ byte = mei_cldev_send(cldev, (u8 *)_close_in,
+ sizeof(session_close_in));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+ return byte;
+ }
+
+ byte = mei_cldev_recv(cldev, (u8 *)_close_out,
+ sizeof(session_close_out));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
+ return byte;
+ }
+
+ if (session_close_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+ dev_dbg(dev, "Session Close Failed. status: 0x%X\n",
+ session_close_out.header.status);
+ return -EIO;
+ }
+
+ return 0;
+}
+
static __attribute__((unused))
struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
@@ -652,7 +705,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
.repeater_check_flow_prepare_ack = mei_repeater_check_flow_prepare_ack,
.verify_mprime = mei_verify_mprime,
.enable_hdcp_authentication = mei_enable_hdcp_authentication,
- .close_hdcp_session = NULL,
+ .close_hdcp_session = mei_close_hdcp_session,
};
static int mei_hdcp_probe(struct mei_cl_device *cldev,
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 29/40] misc/mei/hdcp: Initiate Locality check
Requests ME to start the second stage of HDCP2.2 authentication,
called Locality Check.
On Success, ME FW will provide LC_Init message to send to hdcp sink.
v2: Rebased.
v3:
cldev is passed as first parameter [Tomas]
Redundant comments and cast are removed [Tomas]
v4:
%zd used for ssize_t [Alexander]
%s/return -1/return -EIO [Alexander]
Style fixed [Uma]
v5: Rebased.
v6:
Collected the Rb-ed by.
Rebasing.
v7:
Adjust to the new mei interface.
Fix for Kdoc.
v8:
K-Doc addition. [Tomas]
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/misc/mei/hdcp/mei_hdcp.c | 56 +++-
1 file changed, 55 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index e8396c723ab0..412a33e29d7d 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -282,6 +282,60 @@ mei_store_pairing_info(struct device *dev, struct
hdcp_port_data *data,
return 0;
}
+/**
+ * mei_initiate_locality_check() - Prepare LC_Init
+ * @dev: device corresponding to the mei_cl_device
+ * @hdcp_data: Intel HW specific hdcp data
+ * @lc_init_data: LC_Init msg output
+ *
+ * Return: 0 on Success, <0 on Failure
+ */
+static int
+mei_initiate_locality_check(struct device *dev, struct hdcp_port_data *data,
+ struct hdcp2_lc_init *lc_init_data)
+{
+ struct wired_cmd_init_locality_check_in lc_init_in = { { 0 } };
+ struct wired_cmd_init_locality_check_out lc_init_out = { { 0 } };
+ struct mei_cl_device *cldev;
+ ssize_t byte;
+
+ if (!dev || !data || !lc_init_data)
+ return -EINVAL;
+
+ cldev = to_mei_cl_device(dev);
+
+ lc_init_in.header.api_version = HDCP_API_VERSION;
+ lc_init_in.header.command_id = WIRED_INIT_LOCALITY_CHECK;
+ lc_init_in.header.status = ME_HDCP_STATUS_SUCCESS;
+ lc_init_in.header.buffer_len = WIRED_CMD_BUF_LEN_INIT_LOCALITY_CHECK_IN;
+
+ lc_init_in.port.integrated_port_type = data->port_type;
+ lc_init_in.port.physical_port = (u8)GET_MEI_DDI_INDEX(data->port);
+
+ byte = mei_cldev_send(cldev, (u8 *)_init_in, sizeof(lc_init_in));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+ return byte;
+ }
+
+ byte = mei_cldev_recv(cldev, (u8 *)_init_out, sizeof(lc_init_out));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
+ return byte;
+ }
+
+ if (lc_init_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+ dev_dbg(dev, "ME cmd 0x%08X Failed. status: 0x%X\n",
+ WIRED_INIT_LOCALITY_CHECK, lc_init_out.header.status);
+ return -EIO;
+ }
+
+ lc_init_data->msg_id = HDCP_2_2_LC_INIT;
+ memcpy(lc_init_data->r_n, lc_init_out.r_n, HDCP_2_2_RN_LEN);
+
+ return 0;
+}
+
static __attribute__((unused))
struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
@@ -289,7 +343,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
.verify_receiver_cert_prepare_km = mei_verify_receiver_cert_prepare_km,
.verify_hprime = mei_verify_hprime,
.store_pairing_info = mei_store_pairing_info,
- .initiate_locality_check = NULL,
+ .initiate_locality_check = mei_initiate_locality_check,
.verify_lprime = NULL,
.get_session_key = NULL,
.repeater_check_flow_prepare_ack = NULL,
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 31/40] misc/mei/hdcp: Prepare Session Key
Request to ME to prepare the encrypted session key.
On Success, ME provides Encrypted session key. Function populates
the HDCP2.2 authentication msg SKE_Send_Eks.
v2: Rebased.
v3:
cldev is passed as first parameter [Tomas]
Redundant comments and cast are removed [Tomas]
v4:
%zd for ssize_t [Alexander]
%s/return -1/return -EIO [Alexander]
Style fixed [Uma]
v5: Rebased.
v6:
Collected the Rb-ed by.
Rebasing.
v7:
Adjust to the new mei interface.
Fix for Kdoc.
v8:
K-Doc addition. [Tomas]
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/misc/mei/hdcp/mei_hdcp.c | 58 +++-
1 file changed, 57 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 3d7767d944dc..2be7b6b949c2 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -393,6 +393,62 @@ static int mei_verify_lprime(struct device *dev, struct
hdcp_port_data *data,
return 0;
}
+/**
+ * mei_get_session_key() - Prepare SKE_Send_Eks.
+ * @dev: device corresponding to the mei_cl_device
+ * @hdcp_data: Intel HW specific hdcp data
+ * @ske_data: SKE_Send_Eks msg output from ME FW.
+ *
+ * Return: 0 on Success, <0 on Failure
+ */
+static int mei_get_session_key(struct device *dev, struct hdcp_port_data *data,
+ struct hdcp2_ske_send_eks *ske_data)
+{
+ struct wired_cmd_get_session_key_in get_skey_in = { { 0 } };
+ struct wired_cmd_get_session_key_out get_skey_out = { { 0 } };
+ struct mei_cl_device *cldev;
+ ssize_t byte;
+
+ if (!dev || !data || !ske_data)
+ return -EINVAL;
+
+ cldev = to_mei_cl_device(dev);
+
+ get_skey_in.header.api_version = HDCP_API_VERSION;
+ get_skey_in.header.command_id = WIRED_GET_SESSION_KEY;
+ get_skey_in.header.status = ME_HDCP_STATUS_SUCCESS;
+ get_skey_in.header.buffer_len = WIRED_CMD_BUF_LEN_GET_SESSION_KEY_IN;
+
+ get_skey_in.port.integrated_port_type = data->port_type;
+ get_skey_in.port.physical_port = (u8)GET_MEI_DDI_INDEX(data->port);
+
+ byte = mei_cldev_send(cldev, (u8 *)_skey_in, sizeof(get_skey_in));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+ return byte;
+ }
+
+ byte = mei_cldev_recv(cldev, (u8 *)_skey_out, sizeof(get_skey_out));
+
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
+ return byte;
+ }
+
+ if (get_skey_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+ dev_dbg(dev, "ME cmd 0x%08X failed. status: 0x%X\n",
+ WIRED_GET_SESSION_KEY, get_skey_out.header.status);
+ return -EIO;
+ }
+
+ ske_data->msg_id = HDCP_2_2_SKE_SEND_EKS;
+ memcpy(ske_data->e_dkey_ks, get_skey_out.e_dkey_ks,
+ HDCP_2_2_E_DKEY_KS_LEN);
+ memcpy(ske_data->riv, get_skey_out.r_iv, HDCP_2_2_RIV_LEN);
+
+ return 0;
+}
+
static __attribute__((unused))
struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
@@ -402,7 +458,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
.store_pairing_info = mei_store_pairing_info,
.initiate_locality_check = mei_initiate_locality_check,
.verify_lprime = mei_verify_lprime,
- .get_session_key = NULL,
+ .get_session_key = mei_get_session_key,
.repeater_check_flow_prepare_ack = NULL,
.verify_mprime = NULL,
.enable_hdcp_authentication = NULL,
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 22/40] mei: bus: export to_mei_cl_device for mei client device drivers
From: Tomas Winkler
Export to_mei_cl_device macro, it is needed also in mei client drivers.
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/bus.c | 1 -
include/linux/mei_cl_bus.h | 2 ++
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index fc3872fe7b25..e5456faf00e6 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -28,7 +28,6 @@
#include "client.h"
#define to_mei_cl_driver(d) container_of(d, struct mei_cl_driver, driver)
-#define to_mei_cl_device(d) container_of(d, struct mei_cl_device, dev)
/**
* __mei_cl_send - internal client send (write)
diff --git a/include/linux/mei_cl_bus.h b/include/linux/mei_cl_bus.h
index 7fde40e17c8b..03b6ba2a63f8 100644
--- a/include/linux/mei_cl_bus.h
+++ b/include/linux/mei_cl_bus.h
@@ -55,6 +55,8 @@ struct mei_cl_device {
void *priv_data;
};
+#define to_mei_cl_device(d) container_of(d, struct mei_cl_device, dev)
+
struct mei_cl_driver {
struct device_driver driver;
const char *name;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 28/40] misc/mei/hdcp: Store the HDCP Pairing info
Provides Pairing info to ME to store.
Pairing is a process to fast track the subsequent authentication
with the same HDCP sink.
On Success, received HDCP pairing info is stored in non-volatile
memory of ME.
v2: Rebased.
v3:
cldev is passed as first parameter [Tomas]
Redundant comments and cast are removed [Tomas]
v4:
%zd for ssize_t [Alexander]
%s/return -1/return -EIO [Alexander]
Style fixed [Uma]
v5: Rebased.
v6:
Collected the Rb-ed by.
Rebasing.
v7:
Adjust to the new mei interface.
Fix for Kdoc.
v8:
K-Doc addition. [Tomas]
memcpy for const length.
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/misc/mei/hdcp/mei_hdcp.c | 60 +++-
1 file changed, 59 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 74219e1487d3..e8396c723ab0 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -224,13 +224,71 @@ static int mei_verify_hprime(struct device *dev, struct
hdcp_port_data *data,
return 0;
}
+/**
+ * mei_store_pairing_info() - Store pairing info received at ME FW
+ * @dev: device corresponding to the mei_cl_device
+ * @hdcp_data: Intel HW specific hdcp data
+ * @pairing_info: AKE_Send_Pairing_Info msg input to ME FW
+ *
+ * Return: 0 on Success, <0 on Failure
+ */
+static int
+mei_store_pairing_info(struct device *dev, struct hdcp_port_data *data,
+ struct hdcp2_ake_send_pairing_info *pairing_info)
+{
+ struct wired_cmd_ake_send_pairing_info_in pairing_info_in = { { 0 } };
+ struct wired_cmd_ake_send_pairing_info_out pairing_info_out = { { 0 } };
+ struct mei_cl_device *cldev;
+ ssize_t byte;
+
+ if (!dev || !data || !pairing_info)
+ return -EINVAL;
+
+ cldev = to_mei_cl_device(dev);
+
+ pairing_info_in.header.api_version = HDCP_API_VERSION;
+ pairing_info_in.header.command_id = WIRED_AKE_SEND_PAIRING_INFO;
+ pairing_info_in.header.status = ME_HDCP_STATUS_SUCCESS;
+ pairing_info_in.header.buffer_len =
+ WIRED_CMD_BUF_LEN_SEND_PAIRING_INFO_IN;
+
+ pairing_info_in.port.integrated_port_type = data->port_type;
+ pairing_info_in.port.physical_port = (u8)GET_MEI_DDI_INDEX(data->port);
+
+ memcpy(pairing_info_in.e_kh_km, pairing_info->e_kh_km,
+ HDCP_2_2_E_KH_KM_LEN);
+
+ byte = mei_cldev_send(cldev, (u8 *)_info_in,
+ sizeof(pairing_info_in));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+ return byte;
+ }
+
+ byte = mei_cldev_recv(cldev, (u8 *)_info_out,
+ sizeof(pairing_info_out));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
+ return byte;
+ }
+
+ if (pairing_info_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+ dev_dbg(dev, "ME cmd 0x%08X failed. Status: 0x%X\n",
+ WIRED_AKE_SEND_PAIRING_INFO,
+ pairing_info_out.header.status);
+ return -EIO;
+ }
+
+ return 0;
+}
+
static __attribute__((unused))
struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
.initiate_hdcp2_session = mei_initiate_hdcp2_session,
.verify_receiver_cert_prepare_km = mei_verify_receiver_cert_prepare_km,
.verify_hprime = mei_verify_hprime,
- .store_pairing_info = NULL,
+ .store_pairing_info = mei_store_pairing_info,
.initiate_locality_check = NULL,
.verify_lprime = NULL,
.get_session_key = NULL,
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 27/40] misc/mei/hdcp: Verify H_prime
Requests for the verification of AKE_Send_H_prime.
ME will calculate the H and comparing it with received H_Prime.
The result will be returned as status.
Here AKE_Send_H_prime is a HDCP2.2 Authentication msg.
v2: Rebased.
v3:
cldev is passed as first parameter [Tomas]
Redundant comments and cast are removed [Tomas]
v4:
%zd for ssize_t [Alexander]
%s/return -1/return -EIO [Alexander]
Styles and typos fixed [Uma]
v5: Rebased.
v6:
Collected the Rb-ed by.
Rebasing.
v7:
Adjust to the new mei interface.
Fix for Kdoc.
v8:
K-Doc Addition [Tomas]
memcpy for const length.
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/misc/mei/hdcp/mei_hdcp.c | 57 +++-
1 file changed, 56 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 24665fff640d..74219e1487d3 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -169,12 +169,67 @@ mei_verify_receiver_cert_prepare_km(struct device *dev,
return 0;
}
+/**
+ * mei_verify_hprime() - Verify AKE_Send_H_prime at ME FW.
+ * @dev: device corresponding to the mei_cl_device
+ * @hdcp_data: Intel HW specific hdcp data
+ * @rx_hprime: AKE_Send_H_prime msg for ME FW verification
+ *
+ * Return: 0 on Success, <0 on Failure
+ */
+static int mei_verify_hprime(struct device *dev, struct hdcp_port_data *data,
+struct hdcp2_ake_send_hprime *rx_hprime)
+{
+ struct wired_cmd_ake_send_hprime_in send_hprime_in = { { 0 } };
+ struct wired_cmd_ake_send_hprime_out send_hprime_out = { { 0 } };
+ struct mei_cl_device *cldev;
+ ssize_t byte;
+
+ if (!dev || !data || !rx_hprime)
+ return -EINVAL;
+
+ cldev = to_mei_cl_device(dev);
+
+ send_hprime_in.header.api_version = HDCP_API_VERSION;
+ send_hprime_in.header.command_id = WIRED_AKE_SEND_HPRIME;
+ send_hprime_in.header.status = ME_HDCP_STATUS_SUCCESS;
+ send_hprime_in.header.buffer_len = WIRED_CMD_BUF_LEN_AKE_SEND_HPRIME_IN;
+
+ send_hprime_in.port.integrated_port_type = data->port_type;
+ send_hprime_in.port.physical_port = (u8)GET_MEI_DDI_INDEX(data->port);
+
+ memcpy(send_hprime_in.h_prime, rx_hprime->h_prime,
+ HDCP_2_2_H_PRIME_LEN);
+
+ byte = mei_cldev_send(cldev, (u8 *)_hprime_in,
+ sizeof(send_hprime_in));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+ return byte;
+ }
+
+ byte = mei_cldev_recv(cldev, (u8 *)_hprime_out,
+ sizeof(send_hprime_out));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
+ return byte;
+ }
+
+ if (send_hprime_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+ dev_dbg(dev, "ME cmd 0x%08X Failed. Status: 0x%X\n",
+ WIRED_AKE_SEND_HPRIME, send_hprime_out.header.status);
+ return -EIO;
+ }
+
+ return 0;
+}
+
static __attribute__((unused))
struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
.initiate_hdcp2_session = mei_initiate_hdcp2_session,
.verify_receiver_cert_prepare_km = mei_verify_receiver_cert_prepare_km,
- .verify_hprime = NULL,
+ .verify_hprime = mei_verify_hprime,
.store_pairing_info = NULL,
.initiate_locality_check = NULL,
.verify_lprime = NULL,
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 17/40] drm/i915: Implement the HDCP2.2 support for HDMI
Implements the HDMI adaptation specific HDCP2.2 operations.
Basically these are DDC read and write for authenticating through
HDCP2.2 messages.
v2: Rebased.
v3:
No more special handling of Gmbus burst read for AKE_SEND_CERT.
Style fixed with few naming. [Uma]
%s/PARING/PAIRING
v4:
msg_sz is initialized at definition.
Lookup table is defined for HDMI HDCP2.2 msgs [Daniel].
v5: Rebased.
v6:
Make a function as inline [Uma]
%s/uintxx_t/uxx
v7:
Errors due to sinks are reported as DEBUG logs.
Adjust to the new mei interface.
v8:
ARRAY_SIZE for the # of array members [Jon & Daniel].
hdcp adaptation is added as a const in the hdcp_shim [Daniel]
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_hdmi.c | 189 ++
1 file changed, 189 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index ab376a31cdab..3b4fe7048af9 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1129,6 +1129,190 @@ bool intel_hdmi_hdcp_check_link(struct
intel_digital_port *intel_dig_port)
return true;
}
+static struct hdcp2_hdmi_msg_data {
+ u8 msg_id;
+ u32 timeout;
+ u32 timeout2;
+ } hdcp2_msg_data[] = {
+ {HDCP_2_2_AKE_INIT, 0, 0},
+ {HDCP_2_2_AKE_SEND_CERT, HDCP_2_2_CERT_TIMEOUT_MS, 0},
+ {HDCP_2_2_AKE_NO_STORED_KM, 0, 0},
+ {HDCP_2_2_AKE_STORED_KM, 0, 0},
+ {HDCP_2_2_AKE_SEND_HPRIME, HDCP_2_2_HPRIME_PAIRED_TIMEOUT_MS,
+ HDCP_2_2_HPRIME_NO_PAIRED_TIMEOUT_MS},
+ {HDCP_2_2_AKE_SEND_PAIRING_INFO, HDCP_2_2_PAIRING_TIMEOUT_MS,
+ 0},
+ {HDCP_2_2_LC_INIT, 0, 0},
+ {HDCP_2_2_LC_SEND_LPRIME, HDCP_2_2_HDMI_LPRIME_TIMEOUT_MS, 0},
+ {HDCP_2_2_SKE_SEND_EKS, 0, 0},
+ {HDCP_2_2_REP_SEND_RECVID_LIST,
+ HDCP_2_2_RECVID_LIST_TIMEOUT_MS, 0},
+ {HDCP_2_2_REP_SEND_ACK, 0, 0},
+ {HDCP_2_2_REP_STREAM_MANAGE, 0, 0},
+ {HDCP_2_2_REP_STREAM_READY, HDCP_2_2_STREAM_READY_TIMEOUT_MS,
+ 0},
+ };
+
+static
+int intel_hdmi_hdcp2_read_rx_status(struct intel_digital_port *intel_dig_port,
+ uint8_t *rx_status)
+{
+ return intel_hdmi_hdcp_read(intel_dig_port,
+ HDCP_2_2_HDMI_REG_RXSTATUS_OFFSET,
+ rx_status,
+ HDCP_2_2_HDMI_RXSTATUS_LEN);
+}
+
+static int get_hdcp2_msg_timeout(u8 msg_id, bool is_paired)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(hdcp2_msg_data); i++)
+ if (hdcp2_msg_data[i].msg_id == msg_id &&
+ (msg_id != HDCP_2_2_AKE_SEND_HPRIME || is_paired))
+ return hdcp2_msg_data[i].timeout;
+ else if (hdcp2_msg_data[i].msg_id == msg_id)
+ return hdcp2_msg_data[i].timeout2;
+
+ return -EINVAL;
+}
+
+static inline
+int hdcp2_detect_msg_availability(struct intel_digital_port
*intel_digital_port,
+ u8 msg_id, bool *msg_ready,
+ ssize_t *msg_sz)
+{
+ u8 rx_status[HDCP_2_2_HDMI_RXSTATUS_LEN];
+ int ret;
+
+ ret = intel_hdmi_hdcp2_read_rx_status(intel_digital_port, rx_status);
+ if (ret < 0) {
+ DRM_DEBUG_KMS("rx_status read failed. Err %d\n", ret);
+ return ret;
+ }
+
+ *msg_sz = ((HDCP_2_2_HDMI_RXSTATUS_MSG_SZ_HI(rx_status[1]) << 8) |
+ rx_status[0]);
+
+ if (msg_id == HDCP_2_2_REP_SEND_RECVID_LIST)
+ *msg_ready = (HDCP_2_2_HDMI_RXSTATUS_READY(rx_status[1]) &&
+*msg_sz);
+ else
+ *msg_ready = *msg_sz;
+
+ return 0;
+}
+
+static ssize_t
+intel_hdmi_hdcp2_wait_for_msg(struct intel_digital_port *intel_dig_port,
+ u8 msg_id, bool paired)
+{
+ bool msg_ready = false;
+ int timeout, ret;
+ ssize_t msg_sz = 0;
+
+ timeout = get_hdcp2_msg_timeout(msg_id, paired);
+ if (timeout < 0)
+ return timeout;
+
+ ret = __wait_for(ret = hdcp2_detect_msg_availability(intel_dig_port,
+msg_id, _ready,
+_sz),
+!ret && msg_ready && msg_sz, timeout * 1000,
+1000, 5 * 1000);
+ if (ret)
+ DRM_DEBUG_KMS("msg_id: %d, ret: %d, timeout: %d\n",
+ msg_id, ret, timeout);
+
+ return ret ? ret : msg_sz;
+}
+
+static
+int intel_hdmi_hdcp2_write_msg(struct intel_digital_port *intel_dig_port,
+ void *buf,
[PATCH v10 25/40] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session
Request ME FW to start the HDCP2.2 session for an intel port.
Prepares payloads for command WIRED_INITIATE_HDCP2_SESSION and sends
to ME FW.
On Success, ME FW will start a HDCP2.2 session for the port and
provides the content for HDCP2.2 AKE_Init message.
v2: Rebased.
v3:
cldev is add as a separate parameter [Tomas]
Redundant comment and typecast are removed [Tomas]
v4:
%zd is used for size [Alexander]
%s/return -1/return -EIO [Alexander]
Spellings in commit msg is fixed [Uma]
v5: Rebased.
v6:
Collected the rb-ed by.
Realigning the patches in the series.
v7:
Adjust to the new mei interface.
Fix for kdoc.
v8:
K-Doc Addition.
memcpy for const length.
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/misc/mei/hdcp/mei_hdcp.c | 82
drivers/misc/mei/hdcp/mei_hdcp.h | 28 ++
2 files changed, 110 insertions(+)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index ca5010ad7dd7..534d29c8ee86 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -23,6 +23,88 @@
#include
#include
#include
+#include
+#include
+#include
+
+#include "mei_hdcp.h"
+
+/**
+ * mei_initiate_hdcp2_session() - Initiate a Wired HDCP2.2 Tx Session in ME FW
+ * @dev: device corresponding to the mei_cl_device
+ * @hdcp_data: Intel HW specific hdcp data
+ * @ake_data: AKE_Init msg output.
+ *
+ * Return: 0 on Success, <0 on Failure.
+ */
+static int
+mei_initiate_hdcp2_session(struct device *dev, struct hdcp_port_data *data,
+ struct hdcp2_ake_init *ake_data)
+{
+ struct wired_cmd_initiate_hdcp2_session_in session_init_in = { { 0 } };
+ struct wired_cmd_initiate_hdcp2_session_out
+ session_init_out = { { 0 } };
+ struct mei_cl_device *cldev;
+ ssize_t byte;
+
+ if (!dev || !data || !ake_data)
+ return -EINVAL;
+
+ cldev = to_mei_cl_device(dev);
+
+ session_init_in.header.api_version = HDCP_API_VERSION;
+ session_init_in.header.command_id = WIRED_INITIATE_HDCP2_SESSION;
+ session_init_in.header.status = ME_HDCP_STATUS_SUCCESS;
+ session_init_in.header.buffer_len =
+ WIRED_CMD_BUF_LEN_INITIATE_HDCP2_SESSION_IN;
+
+ session_init_in.port.integrated_port_type = data->port_type;
+ session_init_in.port.physical_port = (u8)GET_MEI_DDI_INDEX(data->port);
+ session_init_in.protocol = data->protocol;
+
+ byte = mei_cldev_send(cldev, (u8 *)_init_in,
+ sizeof(session_init_in));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+ return byte;
+ }
+
+ byte = mei_cldev_recv(cldev, (u8 *)_init_out,
+ sizeof(session_init_out));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
+ return byte;
+ }
+
+ if (session_init_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+ dev_dbg(dev, "ME cmd 0x%08X Failed. Status: 0x%X\n",
+ WIRED_INITIATE_HDCP2_SESSION,
+ session_init_out.header.status);
+ return -EIO;
+ }
+
+ ake_data->msg_id = HDCP_2_2_AKE_INIT;
+ ake_data->tx_caps = session_init_out.tx_caps;
+ memcpy(ake_data->r_tx, session_init_out.r_tx, HDCP_2_2_RTX_LEN);
+
+ return 0;
+}
+
+static __attribute__((unused))
+struct i915_hdcp_component_ops mei_hdcp_ops = {
+ .owner = THIS_MODULE,
+ .initiate_hdcp2_session = mei_initiate_hdcp2_session,
+ .verify_receiver_cert_prepare_km = NULL,
+ .verify_hprime = NULL,
+ .store_pairing_info = NULL,
+ .initiate_locality_check = NULL,
+ .verify_lprime = NULL,
+ .get_session_key = NULL,
+ .repeater_check_flow_prepare_ack = NULL,
+ .verify_mprime = NULL,
+ .enable_hdcp_authentication = NULL,
+ .close_hdcp_session = NULL,
+};
static int mei_hdcp_probe(struct mei_cl_device *cldev,
const struct mei_cl_device_id *id)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.h b/drivers/misc/mei/hdcp/mei_hdcp.h
index 582a7e27ae29..f831db3cbd54 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.h
+++ b/drivers/misc/mei/hdcp/mei_hdcp.h
@@ -363,4 +363,32 @@ struct wired_cmd_repeater_auth_stream_req_out {
struct hdcp_port_id port;
} __packed;
+enum mei_hdcp_ddi {
+ MEI_DDI_INVALID_PORT = 0x0,
+
+ MEI_DDI_B = 1,
+ MEI_DDI_C,
+ MEI_DDI_D,
+ MEI_DDI_E,
+ MEI_DDI_F,
+ MEI_DDI_A = 7,
+ MEI_DDI_RANGE_END = MEI_DDI_A,
+};
+
+enum i915_port {
+ PORT_NONE = -1,
+
+ PORT_A = 0,
+ PORT_B,
+ PORT_C,
+ PORT_D,
+ PORT_E,
+ PORT_F,
+ I915_MAX_PORTS,
+};
+
+#define GET_MEI_DDI_INDEX(p) ({
[PATCH v10 24/40] misc/mei/hdcp: Define ME FW interface for HDCP2.2
Defines the HDCP specific ME FW interfaces such as Request CMDs,
payload structure for CMDs and their response status codes.
This patch defines payload size(Excluding the Header)for each WIRED
HDCP2.2 CMDs.
v2: Rebased.
v3:
Extra comments are removed.
v4:
%s/\/\*\*/\/\*
v5:
Extra lines are removed.
v6:
Remove redundant text from the License header
%s/LPRIME_HALF/V_PRIME_HALF
%s/uintxx_t/uxx
v7:
Extra taps removed.
Signed-off-by: Ramalingam C
---
drivers/misc/mei/hdcp/mei_hdcp.h | 366 +++
1 file changed, 366 insertions(+)
create mode 100644 drivers/misc/mei/hdcp/mei_hdcp.h
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.h b/drivers/misc/mei/hdcp/mei_hdcp.h
new file mode 100644
index ..582a7e27ae29
--- /dev/null
+++ b/drivers/misc/mei/hdcp/mei_hdcp.h
@@ -0,0 +1,366 @@
+/* SPDX-License-Identifier: (GPL-2.0+) */
+/*
+ * Copyright © 2017-2018 Intel Corporation
+ *
+ * Authors:
+ * Ramalingam C
+ */
+
+#ifndef __MEI_HDCP_H__
+#define __MEI_HDCP_H__
+
+#include
+
+/* me_hdcp_status: Enumeration of all HDCP Status Codes */
+enum me_hdcp_status {
+ ME_HDCP_STATUS_SUCCESS = 0x,
+
+ /* WiDi Generic Status Codes */
+ ME_HDCP_STATUS_INTERNAL_ERROR = 0x1000,
+ ME_HDCP_STATUS_UNKNOWN_ERROR= 0x1001,
+ ME_HDCP_STATUS_INCORRECT_API_VERSION= 0x1002,
+ ME_HDCP_STATUS_INVALID_FUNCTION = 0x1003,
+ ME_HDCP_STATUS_INVALID_BUFFER_LENGTH= 0x1004,
+ ME_HDCP_STATUS_INVALID_PARAMS = 0x1005,
+ ME_HDCP_STATUS_AUTHENTICATION_FAILED= 0x1006,
+
+ /* WiDi Status Codes */
+ ME_HDCP_INVALID_SESSION_STATE = 0x6000,
+ ME_HDCP_SRM_FRAGMENT_UNEXPECTED = 0x6001,
+ ME_HDCP_SRM_INVALID_LENGTH = 0x6002,
+ ME_HDCP_SRM_FRAGMENT_OFFSET_INVALID = 0x6003,
+ ME_HDCP_SRM_VERIFICATION_FAILED = 0x6004,
+ ME_HDCP_SRM_VERSION_TOO_OLD = 0x6005,
+ ME_HDCP_RX_CERT_VERIFICATION_FAILED = 0x6006,
+ ME_HDCP_RX_REVOKED = 0x6007,
+ ME_HDCP_H_VERIFICATION_FAILED = 0x6008,
+ ME_HDCP_REPEATER_CHECK_UNEXPECTED = 0x6009,
+ ME_HDCP_TOPOLOGY_MAX_EXCEEDED = 0x600A,
+ ME_HDCP_V_VERIFICATION_FAILED = 0x600B,
+ ME_HDCP_L_VERIFICATION_FAILED = 0x600C,
+ ME_HDCP_STREAM_KEY_ALLOC_FAILED = 0x600D,
+ ME_HDCP_BASE_KEY_RESET_FAILED = 0x600E,
+ ME_HDCP_NONCE_GENERATION_FAILED = 0x600F,
+ ME_HDCP_STATUS_INVALID_E_KEY_STATE = 0x6010,
+ ME_HDCP_STATUS_INVALID_CS_ICV = 0x6011,
+ ME_HDCP_STATUS_INVALID_KB_KEY_STATE = 0x6012,
+ ME_HDCP_STATUS_INVALID_PAVP_MODE_ICV= 0x6013,
+ ME_HDCP_STATUS_INVALID_PAVP_MODE= 0x6014,
+ ME_HDCP_STATUS_LC_MAX_ATTEMPTS = 0x6015,
+
+ /* New status for HDCP 2.1 */
+ ME_HDCP_STATUS_MISMATCH_IN_M= 0x6016,
+
+ /* New status code for HDCP 2.2 Rx */
+ ME_HDCP_STATUS_RX_PROV_NOT_ALLOWED = 0x6017,
+ ME_HDCP_STATUS_RX_PROV_WRONG_SUBJECT= 0x6018,
+ ME_HDCP_RX_NEEDS_PROVISIONING = 0x6019,
+ ME_HDCP_BKSV_ICV_AUTH_FAILED= 0x6020,
+ ME_HDCP_STATUS_INVALID_STREAM_ID= 0x6021,
+ ME_HDCP_STATUS_CHAIN_NOT_INITIALIZED= 0x6022,
+ ME_HDCP_FAIL_NOT_EXPECTED = 0x6023,
+ ME_HDCP_FAIL_HDCP_OFF = 0x6024,
+ ME_HDCP_FAIL_INVALID_PAVP_MEMORY_MODE = 0x6025,
+ ME_HDCP_FAIL_AES_ECB_FAILURE= 0x6026,
+ ME_HDCP_FEATURE_NOT_SUPPORTED = 0x6027,
+ ME_HDCP_DMA_READ_ERROR = 0x6028,
+ ME_HDCP_DMA_WRITE_ERROR = 0x6029,
+ ME_HDCP_FAIL_INVALID_PACKET_SIZE= 0x6030,
+ ME_HDCP_H264_PARSING_ERROR = 0x6031,
+ ME_HDCP_HDCP2_ERRATA_VIDEO_VIOLATION= 0x6032,
+ ME_HDCP_HDCP2_ERRATA_AUDIO_VIOLATION= 0x6033,
+ ME_HDCP_TX_ACTIVE_ERROR = 0x6034,
+ ME_HDCP_MODE_CHANGE_ERROR = 0x6035,
+ ME_HDCP_STREAM_TYPE_ERROR = 0x6036,
+ ME_HDCP_STREAM_MANAGE_NOT_POSSIBLE = 0x6037,
+
+ ME_HDCP_STATUS_PORT_INVALID_COMMAND = 0x6038,
+ ME_HDCP_STATUS_UNSUPPORTED_PROTOCOL = 0x6039,
+ ME_HDCP_STATUS_INVALID_PORT_INDEX = 0x603a,
+ ME_HDCP_STATUS_TX_AUTH_NEEDED = 0x603b,
+ ME_HDCP_STATUS_NOT_INTEGRATED_PORT = 0x603c,
+ ME_HDCP_STATUS_SESSION_MAX_REACHED = 0x603d,
+
+ /* hdcp capable bit is not set in rx_caps(error is unique to DP) */
+ ME_HDCP_STATUS_NOT_HDCP_CAPABLE = 0x6041,
+
+ ME_HDCP_STATUS_INVALID_STREAM_COUNT = 0x6042,
+};
+
+#define HDCP_API_VERSION 0x0001
+
+#define HDCP_M_LEN 16
+#define
[PATCH v10 14/40] drm/i915: Handle HDCP2.2 downstream topology change
When repeater notifies a downstream topology change, this patch
reauthenticate the repeater alone without disabling the hdcp
encryption. If that fails then complete reauthentication is executed.
v2:
Rebased.
v3:
Typo in commit msg is fixed [Uma]
v4:
Rebased as part of patch reordering.
Minor style fixes.
v5:
Rebased.
v6:
Rebased.
v7:
Errors due to sinks are reported as DEBUG logs.
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_hdcp.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index 3feff921a547..7ff29fb0aa2f 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -1617,8 +1617,24 @@ static int intel_hdcp2_check_link(struct intel_connector
*connector)
goto out;
}
- DRM_DEBUG_KMS("[%s:%d] HDCP2.2 link failed, retrying auth\n",
- connector->base.name, connector->base.base.id);
+ if (ret == HDCP_TOPOLOGY_CHANGE) {
+ if (hdcp->value == DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
+ goto out;
+
+ DRM_DEBUG_KMS("HDCP2.2 Downstream topology change\n");
+ ret = hdcp2_authenticate_repeater_topology(connector);
+ if (!ret) {
+ hdcp->value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
+ schedule_work(>prop_work);
+ goto out;
+ }
+ DRM_DEBUG_KMS("[%s:%d] Repeater topology auth failed.(%d)\n",
+ connector->base.name, connector->base.base.id,
+ ret);
+ } else {
+ DRM_DEBUG_KMS("[%s:%d] HDCP2.2 link failed, retrying auth\n",
+ connector->base.name, connector->base.base.id);
+ }
ret = _intel_hdcp2_disable(connector);
if (ret) {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 23/40] misc/mei/hdcp: Client driver for HDCP application
ME FW is contributes a vital role in HDCP2.2 authentication.
HDCP2.2 driver needs to communicate to ME FW for each step of the
HDCP2.2 authentication.
ME FW prepare and HDCP2.2 authentication parameters and encrypt them
as per spec. With such parameter Driver prepares HDCP2.2 auth messages
and communicate with HDCP2.2 sink.
Similarly HDCP2. sink's response is shared with ME FW for decrypt and
verification.
Once All the steps of HDCP2.2 authentications are complete on driver's
request ME FW will configure the port as authenticated and supply the
HDCP keys to the Gen HW for encryption.
Only after this stage HDCP2.2 driver can start the HDCP2.2 encryption
for a port.
ME FW is interfaced to kernel through MEI Bus Driver. To obtain the
HDCP2.2 services from the ME FW through MEI Bus driver MEI Client
Driver is developed.
v2:
hdcp files are moved to drivers/misc/mei/hdcp/ [Tomas]
v3:
Squashed the Kbuild support [Tomas]
UUID renamed and Module License is modified [Tomas]
drv_data is set to null at remove [Tomas]
v4:
Module name is changed to "MEI HDCP"
I915 Selects the MEI_HDCP
v5:
Remove redundant text from the License header
Fix malformed licence
Removed the drv_data resetting.
v6:
K-Doc addition. [Tomas]
Signed-off-by: Ramalingam C
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/Kconfig | 7 +
drivers/misc/mei/Makefile| 2 ++
drivers/misc/mei/hdcp/Makefile | 7 +
drivers/misc/mei/hdcp/mei_hdcp.c | 65
4 files changed, 81 insertions(+)
create mode 100644 drivers/misc/mei/hdcp/Makefile
create mode 100644 drivers/misc/mei/hdcp/mei_hdcp.c
diff --git a/drivers/misc/mei/Kconfig b/drivers/misc/mei/Kconfig
index c49e1d2269af..9c518b7f0011 100644
--- a/drivers/misc/mei/Kconfig
+++ b/drivers/misc/mei/Kconfig
@@ -43,3 +43,10 @@ config INTEL_MEI_TXE
Supported SoCs:
Intel Bay Trail
+
+config INTEL_MEI_HDCP
+ tristate "Intel HDCP2.2 services of ME Interface"
+ select INTEL_MEI_ME
+ depends on DRM_I915
+ help
+ MEI Support for HDCP2.2 Services on Intel SoCs.
diff --git a/drivers/misc/mei/Makefile b/drivers/misc/mei/Makefile
index d9215fc4e499..8c2d9565a4cb 100644
--- a/drivers/misc/mei/Makefile
+++ b/drivers/misc/mei/Makefile
@@ -24,3 +24,5 @@ mei-txe-objs += hw-txe.o
mei-$(CONFIG_EVENT_TRACING) += mei-trace.o
CFLAGS_mei-trace.o = -I$(src)
+
+obj-$(CONFIG_INTEL_MEI_HDCP) += hdcp/
diff --git a/drivers/misc/mei/hdcp/Makefile b/drivers/misc/mei/hdcp/Makefile
new file mode 100644
index ..b2de072aa0de
--- /dev/null
+++ b/drivers/misc/mei/hdcp/Makefile
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (c) 2017-2018, Intel Corporation.
+#
+# Makefile - HDCP client driver for Intel MEI Bus Driver.
+
+obj-$(CONFIG_INTEL_MEI_HDCP) += mei_hdcp.o
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
new file mode 100644
index ..ca5010ad7dd7
--- /dev/null
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -0,0 +1,65 @@
+// SPDX-License-Identifier: (GPL-2.0+)
+/*
+ * Copyright © 2017-2018 Intel Corporation
+ *
+ * Mei_hdcp.c: HDCP client driver for mei bus
+ *
+ * Authors:
+ * Ramalingam C
+ */
+
+/**
+ * DOC: MEI_HDCP Client Driver
+ *
+ * This is a client driver to the mei_bus to make the HDCP2.2 services of
+ * ME FW available for the interested consumers like I915.
+ *
+ * This module will act as a translation layer between HDCP protocol
+ * implementor(I915) and ME FW by translating HDCP2.2 authentication
+ * messages to ME FW command payloads and vice versa.
+ */
+
+#include
+#include
+#include
+#include
+
+static int mei_hdcp_probe(struct mei_cl_device *cldev,
+ const struct mei_cl_device_id *id)
+{
+ int ret;
+
+ ret = mei_cldev_enable(cldev);
+ if (ret < 0)
+ dev_err(>dev, "mei_cldev_enable Failed. %d\n", ret);
+
+ return ret;
+}
+
+static int mei_hdcp_remove(struct mei_cl_device *cldev)
+{
+ return mei_cldev_disable(cldev);
+}
+
+#define MEI_UUID_HDCP UUID_LE(0xB638AB7E, 0x94E2, 0x4EA2, 0xA5, \
+ 0x52, 0xD1, 0xC5, 0x4B, \
+ 0x62, 0x7F, 0x04)
+
+static struct mei_cl_device_id mei_hdcp_tbl[] = {
+ { .uuid = MEI_UUID_HDCP, .version = MEI_CL_VERSION_ANY },
+ { }
+};
+MODULE_DEVICE_TABLE(mei, mei_hdcp_tbl);
+
+static struct mei_cl_driver mei_hdcp_driver = {
+ .id_table = mei_hdcp_tbl,
+ .name = KBUILD_MODNAME,
+ .probe = mei_hdcp_probe,
+ .remove = mei_hdcp_remove,
+};
+
+module_mei_cl_driver(mei_hdcp_driver);
+
+MODULE_AUTHOR("Intel Corporation");
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("MEI HDCP");
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 13/40] drm/i915: Implement HDCP2.2 link integrity check
Implements the link integrity check once in 500mSec.
Once encryption is enabled, an ongoing Link Integrity Check is
performed by the HDCP Receiver to check that cipher synchronization
is maintained between the HDCP Transmitter and the HDCP Receiver.
On the detection of synchronization lost, the HDCP Receiver must assert
the corresponding bits of the RxStatus register. The Transmitter polls
the RxStatus register and it may initiate re-authentication.
v2:
Rebased.
v3:
enum check_link_response is used check the link status [Uma]
v4:
Rebased as part of patch reordering.
v5:
Required members of intel_hdcp is defined [Sean Paul]
v6:
hdcp2_check_link is cancelled at required places.
v7:
Rebased for the component i/f changes.
Errors due to the sinks are reported as DEBUG logs.
v8:
hdcp_check_work is used for both hdcp1 and hdcp2 check_link [Daniel]
hdcp2.2 encryption status check is put under WARN_ON [Daniel]
drm_hdcp.h changes are moved into separate patch [Daniel]
v9:
enum check_link_status is defined at intel_drv.h [Daniel]
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_drv.h | 10 +
drivers/gpu/drm/i915/intel_hdcp.c | 88 ---
2 files changed, 93 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index e6792304520a..747fe7361287 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -314,6 +314,13 @@ struct intel_panel {
struct intel_digital_port;
+enum check_link_response {
+ HDCP_LINK_PROTECTED = 0,
+ HDCP_TOPOLOGY_CHANGE,
+ HDCP_LINK_INTEGRITY_FAILURE,
+ HDCP_REAUTH_REQUEST
+};
+
/*
* This structure serves as a translation layer between the generic HDCP code
* and the bus-specific code. What that means is that HDCP over HDMI differs
@@ -409,6 +416,9 @@ struct intel_hdcp_shim {
*/
int (*config_stream_type)(struct intel_digital_port *intel_dig_port,
bool is_repeater, u8 type);
+
+ /* HDCP2.2 Link Integrity Check */
+ int (*check_2_2_link)(struct intel_digital_port *intel_dig_port);
};
struct intel_hdcp {
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index 3b8d3a4b5e6e..3feff921a547 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -102,6 +102,16 @@ static inline bool intel_hdcp_in_use(struct
intel_connector *connector)
return reg & HDCP_STATUS_ENC;
}
+static inline bool intel_hdcp2_in_use(struct intel_connector *connector)
+{
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ enum port port = connector->encoder->port;
+ u32 reg;
+
+ reg = I915_READ(HDCP2_STATUS_DDI(port));
+ return reg & LINK_ENCRYPTION_STATUS;
+}
+
static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
const struct intel_hdcp_shim *shim)
{
@@ -1571,6 +1581,69 @@ static int _intel_hdcp2_disable(struct intel_connector
*connector)
return ret;
}
+/* Implements the Link Integrity Check for HDCP2.2 */
+static int intel_hdcp2_check_link(struct intel_connector *connector)
+{
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct intel_hdcp *hdcp = >hdcp;
+ enum port port = connector->encoder->port;
+ int ret = 0;
+
+ mutex_lock(>mutex);
+
+ /* hdcp2_check_link is expected only when HDCP2.2 is Enabled */
+ if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_ENABLED ||
+ !hdcp->hdcp2_encrypted) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ if (WARN_ON(!intel_hdcp2_in_use(connector))) {
+ DRM_ERROR("HDCP2.2 link stopped the encryption, %x\n",
+ I915_READ(HDCP2_STATUS_DDI(port)));
+ ret = -ENXIO;
+ hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
+ schedule_work(>prop_work);
+ goto out;
+ }
+
+ ret = hdcp->shim->check_2_2_link(intel_dig_port);
+ if (ret == HDCP_LINK_PROTECTED) {
+ if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
+ hdcp->value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
+ schedule_work(>prop_work);
+ }
+ goto out;
+ }
+
+ DRM_DEBUG_KMS("[%s:%d] HDCP2.2 link failed, retrying auth\n",
+ connector->base.name, connector->base.base.id);
+
+ ret = _intel_hdcp2_disable(connector);
+ if (ret) {
+ DRM_ERROR("[%s:%d] Failed to disable hdcp2.2 (%d)\n",
+ connector->base.name, connector->base.base.id, ret);
+ hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
+
[PATCH v10 15/40] drm: removing the DP Errata msg and its msg id
Since DP ERRATA message is not defined at spec, those structure
definition is removed from drm_hdcp.h
Signed-off-by: Ramalingam C
Suggested-by: Daniel Vetter
---
include/drm/drm_hdcp.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index d4e98b11b4aa..f243408ecf26 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -69,7 +69,6 @@
#define HDCP_2_2_REP_SEND_ACK 15
#define HDCP_2_2_REP_STREAM_MANAGE 16
#define HDCP_2_2_REP_STREAM_READY 17
-#define HDCP_2_2_ERRATA_DP_STREAM_TYPE 50
#define HDCP_2_2_RTX_LEN 8
#define HDCP_2_2_RRX_LEN 8
@@ -220,11 +219,6 @@ struct hdcp2_rep_stream_ready {
u8 m_prime[HDCP_2_2_MPRIME_LEN];
} __packed;
-struct hdcp2_dp_errata_stream_type {
- u8 msg_id;
- u8 stream_type;
-} __packed;
-
/* HDCP2.2 TIMEOUTs in mSec */
#define HDCP_2_2_CERT_TIMEOUT_MS 100
#define HDCP_2_2_HPRIME_NO_PAIRED_TIMEOUT_MS 1000
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 21/40] mei: bus: whitelist hdcp client
From: Tomas Winkler
Whitelist HDCP client for in kernel drm use
v2:
Rebased.
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/bus-fixup.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/misc/mei/bus-fixup.c b/drivers/misc/mei/bus-fixup.c
index 80215c312f0e..5fcac02233af 100644
--- a/drivers/misc/mei/bus-fixup.c
+++ b/drivers/misc/mei/bus-fixup.c
@@ -40,6 +40,9 @@ static const uuid_le mei_nfc_info_guid = MEI_UUID_NFC_INFO;
#define MEI_UUID_MKHIF_FIX UUID_LE(0x55213584, 0x9a29, 0x4916, \
0xba, 0xdf, 0xf, 0xb7, 0xed, 0x68, 0x2a, 0xeb)
+#define MEI_UUID_HDCP UUID_LE(0xB638AB7E, 0x94E2, 0x4EA2, \
+ 0xA5, 0x52, 0xD1, 0xC5, 0x4B, 0x62, 0x7F, 0x04)
+
#define MEI_UUID_ANY NULL_UUID_LE
/**
@@ -71,6 +74,18 @@ static void blacklist(struct mei_cl_device *cldev)
cldev->do_match = 0;
}
+/**
+ * whitelist - forcefully whitelist client
+ *
+ * @cldev: me clients device
+ */
+static void whitelist(struct mei_cl_device *cldev)
+{
+ dev_dbg(>dev, "running hook %s\n", __func__);
+
+ cldev->do_match = 1;
+}
+
#define OSTYPE_LINUX2
struct mei_os_ver {
__le16 build;
@@ -472,6 +487,7 @@ static struct mei_fixup {
MEI_FIXUP(MEI_UUID_NFC_HCI, mei_nfc),
MEI_FIXUP(MEI_UUID_WD, mei_wd),
MEI_FIXUP(MEI_UUID_MKHIF_FIX, mei_mkhi_fix),
+ MEI_FIXUP(MEI_UUID_HDCP, whitelist),
};
/**
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 19/40] drm/i915: Add HDCP2.2 support for DP connectors
On DP connector init, intel_hdcp_init is passed with a flag for hdcp2.2
support based on the platform capability.
v2:
Rebased.
v3:
Collected the reviewed-by received.
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4e36df266ab3..88c889770517 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -7301,7 +7301,7 @@ intel_dp_init_connector(struct intel_digital_port
*intel_dig_port,
if (is_hdcp_supported(dev_priv, port) && !intel_dp_is_edp(intel_dp)) {
int ret = intel_hdcp_init(intel_connector, _dp_hdcp_shim,
- false);
+ is_hdcp2_supported(dev_priv));
if (ret)
DRM_DEBUG_KMS("HDCP init failed, skipping.\n");
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 20/40] drm/i915: Add HDCP2.2 support for HDMI connectors
On HDMI connector init, intel_hdcp_init is passed with a flag for hdcp2.2
support based on the platform capability.
v2:
Rebased.
v3:
Collected the reviewed-by received.
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_hdmi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 3b4fe7048af9..2c4bf6d0c39f 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -2621,7 +2621,8 @@ void intel_hdmi_init_connector(struct intel_digital_port
*intel_dig_port,
if (is_hdcp_supported(dev_priv, port)) {
int ret = intel_hdcp_init(intel_connector,
- _hdmi_hdcp_shim, false);
+_hdmi_hdcp_shim,
+is_hdcp2_supported(dev_priv));
if (ret)
DRM_DEBUG_KMS("HDCP init failed, skipping.\n");
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 18/40] drm/i915: CP_IRQ handling for DP HDCP2.2 msgs
Implements the
Waitqueue is created to wait for CP_IRQ
Signaling the CP_IRQ arrival through atomic variable.
For applicable DP HDCP2.2 msgs read wait for CP_IRQ.
As per HDCP2.2 spec "HDCP Transmitters must process CP_IRQ interrupts
when they are received from HDCP Receivers"
Without CP_IRQ processing, DP HDCP2.2 H_Prime msg was getting corrupted
while reading it based on corresponding status bit. This creates the
random failures in reading the DP HDCP2.2 msgs.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_dp.c | 33 +
drivers/gpu/drm/i915/intel_drv.h | 7 +++
drivers/gpu/drm/i915/intel_hdcp.c | 6 ++
3 files changed, 38 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index b13c41220ce0..4e36df266ab3 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5619,6 +5619,24 @@ void intel_dp_encoder_suspend(struct intel_encoder
*intel_encoder)
edp_panel_vdd_off_sync(intel_dp);
}
+static void intel_dp_hdcp_wait_for_cp_irq(struct intel_hdcp *hdcp,
+ int timeout)
+{
+ long ret;
+
+ /* Reinit */
+ atomic_set(>cp_irq_recved, 0);
+
+#define C (atomic_read(>cp_irq_recved) > 0)
+ ret = wait_event_interruptible_timeout(hdcp->cp_irq_queue, C,
+ msecs_to_jiffies(timeout));
+
+ if (ret > 0)
+ atomic_set(>cp_irq_recved, 0);
+ else if (!ret)
+ DRM_DEBUG_KMS("Timedout at waiting for CP_IRQ\n");
+}
+
static
int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
u8 *an)
@@ -5963,14 +5981,13 @@ intel_dp_hdcp2_wait_for_msg(struct intel_digital_port
*intel_dig_port,
mdelay(timeout);
ret = 0;
} else {
- /* TODO: In case if you need to wait on CP_IRQ, do it here */
- ret = __wait_for(ret =
-hdcp2_detect_msg_availability(intel_dig_port,
- msg_id,
- _ready),
-!ret && msg_ready, timeout * 1000,
-1000, 5 * 1000);
-
+ /*
+* Ignoring the return of the intel_dp_hdcp_wait_for_cp_irq,
+* Just to detect the msg availability before failing it.
+*/
+ intel_dp_hdcp_wait_for_cp_irq(hdcp, timeout);
+ ret = hdcp2_detect_msg_availability(intel_dig_port,
+ msg_id, _ready);
if (!msg_ready)
ret = -ETIMEDOUT;
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 747fe7361287..1901d12bacc4 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -464,6 +464,13 @@ struct intel_hdcp {
* over re-Auth has to be triggered.
*/
u32 seq_num_m;
+
+ /*
+* Work queue to signal the CP_IRQ. Used for the waiters to read the
+* available information from HDCP DP sink.
+*/
+ wait_queue_head_t cp_irq_queue;
+ atomic_t cp_irq_recved;
};
struct intel_connector {
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index 7ff29fb0aa2f..f38feeadb363 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -1805,6 +1805,9 @@ int intel_hdcp_init(struct intel_connector *connector,
if (hdcp2_supported)
intel_hdcp2_init(connector);
+ atomic_set(>cp_irq_recved, 0);
+ init_waitqueue_head(>cp_irq_queue);
+
return 0;
}
@@ -1908,6 +1911,9 @@ void intel_hdcp_handle_cp_irq(struct intel_connector
*connector)
if (!hdcp->shim)
return;
+ atomic_set(>hdcp.cp_irq_recved, 1);
+ wake_up_all(>hdcp.cp_irq_queue);
+
/*
* CP_IRQ could be triggered due to 1. HDCP2.2 auth msgs availability,
* 2. link failure and 3. repeater reauth request. At present we dont
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 16/40] drm/i915: Implement the HDCP2.2 support for DP
Implements the DP adaptation specific HDCP2.2 functions.
These functions perform the DPCD read and write for communicating the
HDCP2.2 auth message back and forth.
v2:
wait for cp_irq is merged with this patch. Rebased.
v3:
wait_queue is used for wait for cp_irq [Chris Wilson]
v4:
Style fixed.
%s/PARING/PAIRING
Few style fixes [Uma]
v5:
Lookup table for DP HDCP2.2 msg details [Daniel].
Extra lines are removed.
v6: Rebased.
v7:
Fixed some regression introduced at v5. [Ankit]
Macro HDCP_2_2_RX_CAPS_VERSION_VAL is reused [Uma]
Converted a function to inline [Uma]
%s/uintxx_t/uxx
v8:
Error due to the sinks are reported as DEBUG logs.
Adjust to the new mei interface.
v9:
ARRAY_SIZE for no of array members [Jon & Daniel]
return of the wait_for_cp_irq is made as void [Daniel]
Wait for HDCP2.2 msg is done based on polling the reg bit than
CP_IRQ based. [Daniel]
hdcp adaptation is added as a const in the hdcp_shim [Daniel]
v10:
config_stream_type is redefined [Daniel]
DP Errata specific defines are moved into intel_dp.c.
Signed-off-by: Ramalingam C
Signed-off-by: Ankit K Nautiyal
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_dp.c | 333
1 file changed, 333 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 9ce05819fc11..b13c41220ce0 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5843,6 +5843,333 @@ int intel_dp_hdcp_capable(struct intel_digital_port
*intel_dig_port,
return 0;
}
+struct hdcp2_dp_errata_stream_type {
+ u8 msg_id;
+ u8 stream_type;
+} __packed;
+
+static struct hdcp2_dp_msg_data {
+ u8 msg_id;
+ u32 offset;
+ bool msg_detectable;
+ u32 timeout;
+ u32 timeout2; /* Added for non_paired situation */
+ } hdcp2_msg_data[] = {
+ {HDCP_2_2_AKE_INIT, DP_HDCP_2_2_AKE_INIT_OFFSET, false, 0, 0},
+ {HDCP_2_2_AKE_SEND_CERT, DP_HDCP_2_2_AKE_SEND_CERT_OFFSET,
+ false, HDCP_2_2_CERT_TIMEOUT_MS, 0},
+ {HDCP_2_2_AKE_NO_STORED_KM, DP_HDCP_2_2_AKE_NO_STORED_KM_OFFSET,
+ false, 0, 0},
+ {HDCP_2_2_AKE_STORED_KM, DP_HDCP_2_2_AKE_STORED_KM_OFFSET,
+ false, 0, 0},
+ {HDCP_2_2_AKE_SEND_HPRIME, DP_HDCP_2_2_AKE_SEND_HPRIME_OFFSET,
+ true, HDCP_2_2_HPRIME_PAIRED_TIMEOUT_MS,
+ HDCP_2_2_HPRIME_NO_PAIRED_TIMEOUT_MS},
+ {HDCP_2_2_AKE_SEND_PAIRING_INFO,
+ DP_HDCP_2_2_AKE_SEND_PAIRING_INFO_OFFSET, true,
+ HDCP_2_2_PAIRING_TIMEOUT_MS, 0},
+ {HDCP_2_2_LC_INIT, DP_HDCP_2_2_LC_INIT_OFFSET, false, 0, 0},
+ {HDCP_2_2_LC_SEND_LPRIME, DP_HDCP_2_2_LC_SEND_LPRIME_OFFSET,
+ false, HDCP_2_2_DP_LPRIME_TIMEOUT_MS, 0},
+ {HDCP_2_2_SKE_SEND_EKS, DP_HDCP_2_2_SKE_SEND_EKS_OFFSET, false,
+ 0, 0},
+ {HDCP_2_2_REP_SEND_RECVID_LIST,
+ DP_HDCP_2_2_REP_SEND_RECVID_LIST_OFFSET, true,
+ HDCP_2_2_RECVID_LIST_TIMEOUT_MS, 0},
+ {HDCP_2_2_REP_SEND_ACK, DP_HDCP_2_2_REP_SEND_ACK_OFFSET, false,
+ 0, 0},
+ {HDCP_2_2_REP_STREAM_MANAGE,
+ DP_HDCP_2_2_REP_STREAM_MANAGE_OFFSET, false,
+ 0, 0},
+ {HDCP_2_2_REP_STREAM_READY, DP_HDCP_2_2_REP_STREAM_READY_OFFSET,
+ false, HDCP_2_2_STREAM_READY_TIMEOUT_MS, 0},
+/* local define to shovel this through the write_2_2 interface */
+#define HDCP_2_2_ERRATA_DP_STREAM_TYPE 50
+ {HDCP_2_2_ERRATA_DP_STREAM_TYPE,
+ DP_HDCP_2_2_REG_STREAM_TYPE_OFFSET, false,
+ 0, 0},
+ };
+
+static inline
+int intel_dp_hdcp2_read_rx_status(struct intel_digital_port *intel_dig_port,
+ u8 *rx_status)
+{
+ ssize_t ret;
+
+ ret = drm_dp_dpcd_read(_dig_port->dp.aux,
+ DP_HDCP_2_2_REG_RXSTATUS_OFFSET, rx_status,
+ HDCP_2_2_DP_RXSTATUS_LEN);
+ if (ret != HDCP_2_2_DP_RXSTATUS_LEN) {
+ DRM_DEBUG_KMS("Read bstatus from DP/AUX failed (%zd)\n", ret);
+ return ret >= 0 ? -EIO : ret;
+ }
+
+ return 0;
+}
+
+static
+int hdcp2_detect_msg_availability(struct intel_digital_port *intel_dig_port,
+ u8 msg_id, bool *msg_ready)
+{
+ u8 rx_status;
+ int ret;
+
+ *msg_ready = false;
+ ret = intel_dp_hdcp2_read_rx_status(intel_dig_port, _status);
+ if (ret < 0)
+ return ret;
+
+ switch (msg_id)
[PATCH v10 07/40] drm/i915: hdcp1.4 CP_IRQ handling and SW encryption tracking
"hdcp_encrypted" flag is defined to denote the HDCP1.4 encryption status.
This SW tracking is used to determine the need for real hdcp1.4 disable
and hdcp_check_link upon CP_IRQ.
On CP_IRQ we filter the CP_IRQ related to the states like Link failure
and reauthentication req etc and handle them in hdcp_check_link.
CP_IRQ corresponding to the authentication msg availability are ignored.
WARN_ON is added for the abrupt stop of HDCP encryption of a port.
v2:
bool is used in struct for the cleaner coding. [Daniel]
check_link work_fn is scheduled for cp_irq handling [Daniel]
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_dp.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 5 ++-
drivers/gpu/drm/i915/intel_hdcp.c | 73 ---
3 files changed, 58 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 815ee68efa2f..9ce05819fc11 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4776,7 +4776,7 @@ static void intel_dp_check_service_irq(struct intel_dp
*intel_dp)
intel_dp_handle_test_request(intel_dp);
if (val & DP_CP_IRQ)
- intel_hdcp_check_link(intel_dp->attached_connector);
+ intel_hdcp_handle_cp_irq(intel_dp->attached_connector);
if (val & DP_SINK_SPECIFIC_IRQ)
DRM_DEBUG_DRIVER("Sink specific irq unhandled\n");
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 63e009286d5f..13a41e8cf4ff 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -399,6 +399,9 @@ struct intel_hdcp {
struct delayed_work check_work;
struct work_struct prop_work;
+ /* HDCP1.4 Encryption status */
+ bool hdcp_encrypted;
+
/* HDCP2.2 related definitions */
/* Flag indicates whether this connector supports HDCP2.2 or not. */
bool hdcp2_supported;
@@ -2073,10 +2076,10 @@ int intel_hdcp_init(struct intel_connector *connector,
bool hdcp2_supported);
int intel_hdcp_enable(struct intel_connector *connector);
int intel_hdcp_disable(struct intel_connector *connector);
-int intel_hdcp_check_link(struct intel_connector *connector);
bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port);
bool intel_hdcp_capable(struct intel_connector *connector);
bool is_hdcp2_supported(struct drm_i915_private *dev_priv);
+void intel_hdcp_handle_cp_irq(struct intel_connector *connector);
/* intel_psr.c */
#define CAN_PSR(dev_priv) (HAS_PSR(dev_priv) && dev_priv->psr.sink_support)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index e0bb5f32ba90..c1b057f1501b 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -74,6 +74,16 @@ bool intel_hdcp_capable(struct intel_connector *connector)
return capable;
}
+static inline bool intel_hdcp_in_use(struct intel_connector *connector)
+{
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ enum port port = connector->encoder->port;
+ u32 reg;
+
+ reg = I915_READ(PORT_HDCP_STATUS(port));
+ return reg & HDCP_STATUS_ENC;
+}
+
static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
const struct intel_hdcp_shim *shim)
{
@@ -668,6 +678,7 @@ static int _intel_hdcp_disable(struct intel_connector
*connector)
DRM_DEBUG_KMS("[%s:%d] HDCP is being disabled...\n",
connector->base.name, connector->base.base.id);
+ hdcp->hdcp_encrypted = false;
I915_WRITE(PORT_HDCP_CONF(port), 0);
if (intel_wait_for_register(dev_priv, PORT_HDCP_STATUS(port), ~0, 0,
ENCRYPT_STATUS_CHANGE_TIMEOUT_MS)) {
@@ -713,8 +724,10 @@ static int _intel_hdcp_enable(struct intel_connector
*connector)
/* Incase of authentication failures, HDCP spec expects reauth. */
for (i = 0; i < tries; i++) {
ret = intel_hdcp_auth(conn_to_dig_port(connector), hdcp->shim);
- if (!ret)
+ if (!ret) {
+ hdcp->hdcp_encrypted = true;
return 0;
+ }
DRM_DEBUG_KMS("HDCP Auth failure (%d)\n", ret);
@@ -741,16 +754,17 @@ int intel_hdcp_check_link(struct intel_connector
*connector)
enum port port = intel_dig_port->base.port;
int ret = 0;
- if (!hdcp->shim)
- return -ENOENT;
-
mutex_lock(>mutex);
- if (hdcp->value == DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
+ /* Check_link valid only when HDCP1.4 is enabled */
+ if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_ENABLED ||
+ !hdcp->hdcp_encrypted) {
+ ret = -EINVAL;
goto out;
+ }
- if (!(I915_READ(PORT_HDCP_STATUS(port)) &
[PATCH v10 12/40] drm: HDCP2.2 link check period
Time period for HDCP2.2 link check. Signed-off-by: Ramalingam C Reviewed-by: Daniel Vetter --- include/drm/drm_hdcp.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h index 7260b31af276..d4e98b11b4aa 100644 --- a/include/drm/drm_hdcp.h +++ b/include/drm/drm_hdcp.h @@ -13,6 +13,7 @@ /* Period of hdcp checks (to ensure we're still authenticated) */ #define DRM_HDCP_CHECK_PERIOD_MS (128 * 16) +#define DRM_HDCP2_CHECK_PERIOD_MS 500 /* Shared lengths/masks between HDMI/DVI/DisplayPort */ #define DRM_HDCP_AN_LEN8 -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 10/40] drm: helper functions for hdcp2 seq_num to from u32
Library functions for endianness are aligned for 16/32/64 bits.
But hdcp sequence numbers are 24bits(big endian).
So for their conversion to and from u32 helper functions are developed.
v2:
Comment is updated. [Daniel]
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
include/drm/drm_hdcp.h | 18 ++
1 file changed, 18 insertions(+)
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index d6dfef8cff6a..7260b31af276 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -252,4 +252,22 @@ struct hdcp2_dp_errata_stream_type {
#define HDCP_2_2_HDMI_RXSTATUS_READY(x)((x) & BIT(2))
#define HDCP_2_2_HDMI_RXSTATUS_REAUTH_REQ(x) ((x) & BIT(3))
+/*
+ * Helper functions to convert 24bit big endian hdcp sequence number to
+ * host format and back
+ */
+static inline
+u32 drm_hdcp2_seq_num_to_u32(u8 seq_num[HDCP_2_2_SEQ_NUM_LEN])
+{
+ return (u32)(seq_num[2] | seq_num[1] << 8 | seq_num[0] << 16);
+}
+
+static inline
+void drm_hdcp2_u32_to_seq_num(u8 seq_num[HDCP_2_2_SEQ_NUM_LEN], u32 val)
+{
+ seq_num[0] = val >> 16;
+ seq_num[1] = val >> 8;
+ seq_num[2] = val;
+}
+
#endif
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 01/40] components: multiple components for a device
From: Daniel Vetter
Component framework is extended to support multiple components for
a struct device. These will be matched with different masters based on
its sub component value.
We are introducing this, as I915 needs two different components
with different subcomponent value, which will be matched to two
different component masters(Audio and HDCP) based on the subcomponent
values.
Signed-off-by: Daniel Vetter
Signed-off-by: Ramalingam C
cc: Greg Kroah-Hartman
cc: Russell King
cc: Rafael J. Wysocki
cc: Jaroslav Kysela
cc: Takashi Iwai
cc: Rodrigo Vivi
cc: Jani Nikula
---
drivers/base/component.c | 67 +++
include/linux/component.h | 5
2 files changed, 61 insertions(+), 11 deletions(-)
diff --git a/drivers/base/component.c b/drivers/base/component.c
index ddcea8739c12..30309c0449ed 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -21,6 +21,7 @@ struct component;
struct component_match_array {
void *data;
int (*compare)(struct device *, void *);
+ int (*compare_typed)(struct device *, int, void *);
void (*release)(struct device *, void *);
struct component *component;
bool duplicate;
@@ -48,6 +49,7 @@ struct component {
bool bound;
const struct component_ops *ops;
+ int subcomponent;
struct device *dev;
};
@@ -132,7 +134,7 @@ static struct master *__master_find(struct device *dev,
}
static struct component *find_component(struct master *master,
- int (*compare)(struct device *, void *), void *compare_data)
+ struct component_match_array *mc)
{
struct component *c;
@@ -140,8 +142,13 @@ static struct component *find_component(struct master
*master,
if (c->master && c->master != master)
continue;
- if (compare(c->dev, compare_data))
+ if (mc->compare_typed) {
+ if (mc->compare_typed(c->dev, c->subcomponent,
+ mc->data))
+ return c;
+ } else if (mc->compare(c->dev, mc->data)) {
return c;
+ }
}
return NULL;
@@ -166,7 +173,7 @@ static int find_components(struct master *master)
if (match->compare[i].component)
continue;
- c = find_component(master, mc->compare, mc->data);
+ c = find_component(master, mc);
if (!c) {
ret = -ENXIO;
break;
@@ -301,15 +308,12 @@ static int component_match_realloc(struct device *dev,
return 0;
}
-/*
- * Add a component to be matched, with a release function.
- *
- * The match array is first created or extended if necessary.
- */
-void component_match_add_release(struct device *master,
+static void __component_match_add(struct device *master,
struct component_match **matchptr,
void (*release)(struct device *, void *),
- int (*compare)(struct device *, void *), void *compare_data)
+ int (*compare)(struct device *, void *),
+ int (*compare_typed)(struct device *, int, void *),
+ void *compare_data)
{
struct component_match *match = *matchptr;
@@ -341,13 +345,37 @@ void component_match_add_release(struct device *master,
}
match->compare[match->num].compare = compare;
+ match->compare[match->num].compare_typed = compare_typed;
match->compare[match->num].release = release;
match->compare[match->num].data = compare_data;
match->compare[match->num].component = NULL;
match->num++;
}
+
+/*
+ * Add a component to be matched, with a release function.
+ *
+ * The match array is first created or extended if necessary.
+ */
+void component_match_add_release(struct device *master,
+ struct component_match **matchptr,
+ void (*release)(struct device *, void *),
+ int (*compare)(struct device *, void *), void *compare_data)
+{
+ __component_match_add(master, matchptr, release, compare, NULL,
+ compare_data);
+}
EXPORT_SYMBOL(component_match_add_release);
+void component_match_add_typed(struct device *master,
+ struct component_match **matchptr,
+ int (*compare_typed)(struct device *, int, void *), void *compare_data)
+{
+ __component_match_add(master, matchptr, NULL, NULL, compare_typed,
+ compare_data);
+}
+EXPORT_SYMBOL(component_match_add_typed);
+
static void free_master(struct master *master)
{
struct component_match *match = master->match;
@@ -537,7 +565,8 @@ int component_bind_all(struct device *master_dev, void
*data)
}
EXPORT_SYMBOL_GPL(component_bind_all);
-int component_add(struct device *dev, const struct component_ops *ops)
+static int __component_add(struct device *dev, const struct component_ops
[PATCH v10 04/40] drm: header for i915 - MEI_HDCP interface
Header defines the interface for the I915 and MEI_HDCP drivers.
This interface is specific to the usage of mei_hdcp from gen9+
platforms for ME FW based HDCP2.2 services.
And Generic HDCP2.2 protocol specific definitions
are added at drm/drm_hdcp.h.
v2: Commit msg is enhanced [Daniel]
v3: i915_hdcp_comp_master is defined.
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
include/drm/i915_mei_hdcp_interface.h | 148 ++
1 file changed, 148 insertions(+)
create mode 100644 include/drm/i915_mei_hdcp_interface.h
diff --git a/include/drm/i915_mei_hdcp_interface.h
b/include/drm/i915_mei_hdcp_interface.h
new file mode 100644
index ..bc5b0c71ed3c
--- /dev/null
+++ b/include/drm/i915_mei_hdcp_interface.h
@@ -0,0 +1,148 @@
+/* SPDX-License-Identifier: (GPL-2.0+) */
+/*
+ * Copyright © 2017-2018 Intel Corporation
+ *
+ * Authors:
+ * Ramalingam C
+ */
+
+#ifndef _I915_MEI_HDCP_INTERFACE_H_
+#define _I915_MEI_HDCP_INTERFACE_H_
+
+#include
+#include
+#include
+
+/**
+ * enum hdcp_port_type - HDCP port implementation type defined by ME FW
+ * @HDCP_PORT_TYPE_INVALID: Invalid hdcp port type
+ * @HDCP_PORT_TYPE_INTEGRATED: In-Host HDCP2.x port
+ * @HDCP_PORT_TYPE_LSPCON: HDCP2.2 discrete wired Tx port with LSPCON
+ *(HDMI 2.0) solution
+ * @HDCP_PORT_TYPE_CPDP: HDCP2.2 discrete wired Tx port using the CPDP (DP 1.3)
+ * solution
+ */
+enum hdcp_port_type {
+ HDCP_PORT_TYPE_INVALID,
+ HDCP_PORT_TYPE_INTEGRATED,
+ HDCP_PORT_TYPE_LSPCON,
+ HDCP_PORT_TYPE_CPDP
+};
+
+/**
+ * enum hdcp_wired_protocol - HDCP adaptation used on the port
+ * @HDCP_PROTOCOL_INVALID: Invalid HDCP adaptation protocol
+ * @HDCP_PROTOCOL_HDMI: HDMI adaptation of HDCP used on the port
+ * @HDCP_PROTOCOL_DP: DP adaptation of HDCP used on the port
+ */
+enum hdcp_wired_protocol {
+ HDCP_PROTOCOL_INVALID,
+ HDCP_PROTOCOL_HDMI,
+ HDCP_PROTOCOL_DP
+};
+
+/**
+ * struct hdcp_port_data - intel specific HDCP port data
+ * @port: port index as per I915
+ * @port_type: HDCP port type as per ME FW classification
+ * @protocol: HDCP adaptation as per ME FW
+ * @k: No of streams transmitted on a port. Only on DP MST this is != 1
+ * @seq_num_m: Count of RepeaterAuth_Stream_Manage msg propagated.
+ *Initialized to 0 on AKE_INIT. Incremented after every successful
+ *transmission of RepeaterAuth_Stream_Manage message. When it rolls
+ *over re-Auth has to be triggered.
+ * @streams: struct hdcp2_streamid_type[k]. Defines the type and id for the
+ * streams
+ */
+struct hdcp_port_data {
+ short int port;
+ u8 port_type;
+ u8 protocol;
+ u16 k;
+ u32 seq_num_m;
+ struct hdcp2_streamid_type *streams;
+};
+
+/**
+ * struct i915_hdcp_component_ops- ops for HDCP2.2 services.
+ * @owner: Module providing the ops
+ * @initiate_hdcp2_session: Initiate a Wired HDCP2.2 Tx Session.
+ * And Prepare AKE_Init.
+ * @verify_receiver_cert_prepare_km: Verify the Receiver Certificate
+ * AKE_Send_Cert and prepare
+AKE_Stored_Km/AKE_No_Stored_Km
+ * @verify_hprime: Verify AKE_Send_H_prime
+ * @store_pairing_info: Store pairing info received
+ * @initiate_locality_check: Prepare LC_Init
+ * @verify_lprime: Verify lprime
+ * @get_session_key: Prepare SKE_Send_Eks
+ * @repeater_check_flow_prepare_ack: Validate the Downstream topology
+ * and prepare rep_ack
+ * @verify_mprime: Verify mprime
+ * @enable_hdcp_authentication: Mark a port as authenticated.
+ * @close_hdcp_session: Close the Wired HDCP Tx session per port.
+ * This also disables the authenticated state of the port.
+ */
+struct i915_hdcp_component_ops {
+ /**
+* @owner: mei_hdcp module
+*/
+ struct module *owner;
+
+ int (*initiate_hdcp2_session)(struct device *dev,
+ struct hdcp_port_data *data,
+ struct hdcp2_ake_init *ake_data);
+ int (*verify_receiver_cert_prepare_km)(struct device *dev,
+ struct hdcp_port_data *data,
+ struct hdcp2_ake_send_cert
+ *rx_cert,
+ bool *km_stored,
+ struct hdcp2_ake_no_stored_km
+ *ek_pub_km,
+ size_t *msg_sz);
+ int (*verify_hprime)(struct device *dev,
+struct hdcp_port_data *data,
+struct hdcp2_ake_send_hprime *rx_hprime);
+ int (*store_pairing_info)(struct device *dev,
+
[PATCH v10 11/40] drm/i915: Implement HDCP2.2 repeater authentication
Implements the HDCP2.2 repeaters authentication steps such as verifying
the downstream topology and sending stream management information.
v2: Rebased.
v3:
-EINVAL is returned for topology error and rollover scenario.
Endianness conversion func from drm_hdcp.h is used [Uma]
v4:
Rebased as part of patches reordering.
Defined the mei service functions [Daniel]
v5:
Redefined the mei service functions as per comp redesign.
v6:
%s/uintxx_t/uxx
Check for comp_master is removed.
v7:
Adjust to the new mei interface.
style issue fixed.
v8:
drm_hdcp.h change is moved into separate patch [Daniel]
v9:
%s/__swab16/cpu_to_be16. [Tomas]
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_hdcp.c | 125 +-
1 file changed, 123 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index 1c81e17dc6c4..3b8d3a4b5e6e 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -1032,7 +1032,7 @@ static int hdcp2_prepare_skey(struct intel_connector
*connector,
return ret;
}
-static __attribute__((unused)) int
+static int
hdcp2_verify_rep_topology_prepare_ack(struct intel_connector *connector,
struct hdcp2_rep_send_receiverid_list
*rep_topology,
@@ -1061,7 +1061,7 @@ hdcp2_verify_rep_topology_prepare_ack(struct
intel_connector *connector,
return ret;
}
-static __attribute__((unused)) int
+static int
hdcp2_verify_mprime(struct intel_connector *connector,
struct hdcp2_rep_stream_ready *stream_ready)
{
@@ -1270,6 +1270,119 @@ static int hdcp2_session_key_exchange(struct
intel_connector *connector)
return 0;
}
+static
+int hdcp2_propagate_stream_management_info(struct intel_connector *connector)
+{
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+ struct intel_hdcp *hdcp = >hdcp;
+ union {
+ struct hdcp2_rep_stream_manage stream_manage;
+ struct hdcp2_rep_stream_ready stream_ready;
+ } msgs;
+ const struct intel_hdcp_shim *shim = hdcp->shim;
+ int ret;
+
+ /* Prepare RepeaterAuth_Stream_Manage msg */
+ msgs.stream_manage.msg_id = HDCP_2_2_REP_STREAM_MANAGE;
+ drm_hdcp2_u32_to_seq_num(msgs.stream_manage.seq_num_m, hdcp->seq_num_m);
+
+ /* K no of streams is fixed as 1. Stored as big-endian. */
+ msgs.stream_manage.k = cpu_to_be16(1);
+
+ /* For HDMI this is forced to be 0x0. For DP SST also this is 0x0. */
+ msgs.stream_manage.streams[0].stream_id = 0;
+ msgs.stream_manage.streams[0].stream_type = hdcp->content_type;
+
+ /* Send it to Repeater */
+ ret = shim->write_2_2_msg(intel_dig_port, _manage,
+ sizeof(msgs.stream_manage));
+ if (ret < 0)
+ return ret;
+
+ ret = shim->read_2_2_msg(intel_dig_port, HDCP_2_2_REP_STREAM_READY,
+_ready, sizeof(msgs.stream_ready));
+ if (ret < 0)
+ return ret;
+
+ hdcp->port_data.seq_num_m = hdcp->seq_num_m;
+ hdcp->port_data.streams[0].stream_type = hdcp->content_type;
+
+ ret = hdcp2_verify_mprime(connector, _ready);
+ if (ret < 0)
+ return ret;
+
+ hdcp->seq_num_m++;
+
+ if (hdcp->seq_num_m > HDCP_2_2_SEQ_NUM_MAX) {
+ DRM_DEBUG_KMS("seq_num_m roll over.\n");
+ return -1;
+ }
+
+ return 0;
+}
+
+static
+int hdcp2_authenticate_repeater_topology(struct intel_connector *connector)
+{
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+ struct intel_hdcp *hdcp = >hdcp;
+ union {
+ struct hdcp2_rep_send_receiverid_list recvid_list;
+ struct hdcp2_rep_send_ack rep_ack;
+ } msgs;
+ const struct intel_hdcp_shim *shim = hdcp->shim;
+ u8 *rx_info;
+ u32 seq_num_v;
+ int ret;
+
+ ret = shim->read_2_2_msg(intel_dig_port, HDCP_2_2_REP_SEND_RECVID_LIST,
+_list, sizeof(msgs.recvid_list));
+ if (ret < 0)
+ return ret;
+
+ rx_info = msgs.recvid_list.rx_info;
+
+ if (HDCP_2_2_MAX_CASCADE_EXCEEDED(rx_info[1]) ||
+ HDCP_2_2_MAX_DEVS_EXCEEDED(rx_info[1])) {
+ DRM_DEBUG_KMS("Topology Max Size Exceeded\n");
+ return -EINVAL;
+ }
+
+ /* Converting and Storing the seq_num_v to local variable as DWORD */
+ seq_num_v = drm_hdcp2_seq_num_to_u32(msgs.recvid_list.seq_num_v);
+
+ if (seq_num_v < hdcp->seq_num_v) {
+ /* Roll over of the seq_num_v from repeater. Reauthenticate. */
+ DRM_DEBUG_KMS("Seq_num_v roll over.\n");
+ return -EINVAL;
+ }
+
+ ret =
[PATCH v10 09/40] drm/i915: Implement HDCP2.2 receiver authentication
Implements HDCP2.2 authentication for hdcp2.2 receivers, with
following steps:
Authentication and Key exchange (AKE).
Locality Check (LC).
Session Key Exchange(SKE).
DP Errata for stream type configuration for receivers.
At AKE, the HDCP Receiver’s public key certificate is verified by the
HDCP Transmitter. A Master Key k m is exchanged.
At LC, the HDCP Transmitter enforces locality on the content by
requiring that the Round Trip Time (RTT) between a pair of messages
is not more than 20 ms.
At SKE, The HDCP Transmitter exchanges Session Key ks with
the HDCP Receiver.
In DP HDCP2.2 encryption and decryption logics use the stream type as
one of the parameter. So Before enabling the Encryption DP HDCP2.2
receiver needs to be communicated with stream type. This is added to
spec as ERRATA.
This generic implementation is complete only with the hdcp2 specific
functions defined at hdcp_shim.
v2: Rebased.
v3:
%s/PARING/PAIRING
Coding style fixing [Uma]
v4:
Rebased as part of patch reordering.
Defined the functions for mei services. [Daniel]
v5:
Redefined the mei service functions as per comp redesign.
Required intel_hdcp members are defined [Sean Paul]
v6:
Typo of cipher is Fixed [Uma]
%s/uintxx_t/uxx
Check for comp_master is removed.
v7:
Adjust to the new interface.
Avoid using bool structure members. [Tomas]
v8: Rebased.
v9:
bool is used in struct intel_hdcp [Daniel]
config_stream_type is redesigned [Daniel]
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_drv.h | 34 +++
drivers/gpu/drm/i915/intel_hdcp.c | 197 +++---
2 files changed, 216 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 31c7a4577ca9..e6792304520a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -393,6 +393,22 @@ struct intel_hdcp_shim {
/* Detects whether Panel is HDCP2.2 capable */
int (*hdcp_2_2_capable)(struct intel_digital_port *intel_dig_port,
bool *capable);
+
+ /* Write HDCP2.2 messages */
+ int (*write_2_2_msg)(struct intel_digital_port *intel_dig_port,
+void *buf, size_t size);
+
+ /* Read HDCP2.2 messages */
+ int (*read_2_2_msg)(struct intel_digital_port *intel_dig_port,
+ u8 msg_id, void *buf, size_t size);
+
+ /*
+* Implementation of DP HDCP2.2 Errata for the communication of stream
+* type to Receivers. In DP HDCP2.2 Stream type is one of the input to
+* the HDCP2.2 Cipher for En/De-Cryption. Not applicable for HDMI.
+*/
+ int (*config_stream_type)(struct intel_digital_port *intel_dig_port,
+ bool is_repeater, u8 type);
};
struct intel_hdcp {
@@ -420,6 +436,24 @@ struct intel_hdcp {
*/
u8 content_type;
struct hdcp_port_data port_data;
+
+ bool is_paired;
+ bool is_repeater;
+
+ /*
+* Count of ReceiverID_List received. Initialized to 0 at AKE_INIT.
+* Incremented after processing the RepeaterAuth_Send_ReceiverID_List.
+* When it rolls over re-auth has to be triggered.
+*/
+ u32 seq_num_v;
+
+ /*
+* Count of RepeaterAuth_Stream_Manage msg propagated.
+* Initialized to 0 on AKE_INIT. Incremented after every successful
+* transmission of RepeaterAuth_Stream_Manage message. When it rolls
+* over re-Auth has to be triggered.
+*/
+ u32 seq_num_m;
};
struct intel_connector {
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index fbf8b7893bfa..1c81e17dc6c4 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -17,6 +17,7 @@
#define KEY_LOAD_TRIES 5
#define ENCRYPT_STATUS_CHANGE_TIMEOUT_MS 50
+#define HDCP2_LC_RETRY_CNT 3
static
bool intel_hdcp_is_ksv_valid(u8 *ksv)
@@ -853,7 +854,7 @@ bool is_hdcp_supported(struct drm_i915_private *dev_priv,
enum port port)
return INTEL_GEN(dev_priv) >= 9 && port < PORT_E;
}
-static __attribute__((unused)) int
+static int
hdcp2_prepare_ake_init(struct intel_connector *connector,
struct hdcp2_ake_init *ake_data)
{
@@ -878,7 +879,7 @@ hdcp2_prepare_ake_init(struct intel_connector *connector,
return ret;
}
-static __attribute__((unused)) int
+static int
hdcp2_verify_rx_cert_prepare_km(struct intel_connector *connector,
struct hdcp2_ake_send_cert *rx_cert,
bool *paired,
@@ -908,9 +909,8 @@ hdcp2_verify_rx_cert_prepare_km(struct intel_connector
*connector,
return ret;
}
-static __attribute__((unused)) int
-hdcp2_verify_hprime(struct intel_connector *connector,
- struct
[PATCH v10 05/40] drm/i915: Initialize HDCP2.2
Add the HDCP2.2 initialization to the existing HDCP1.4 stack.
v2:
mei interface handle is protected with mutex. [Chris Wilson]
v3:
Notifiers are used for the mei interface state.
v4:
Poll for mei client device state
Error msg for out of mem [Uma]
Inline req for init function removed [Uma]
v5:
Rebase as Part of reordering.
Component is used for the I915 and MEI_HDCP interface [Daniel]
v6:
HDCP2.2 uses the I915 component master to communicate with mei_hdcp
- [Daniel]
Required HDCP2.2 variables defined [Sean Paul]
v7:
intel_hdcp2.2_init returns void [Uma]
Realigning the codes.
v8:
Avoid using bool structure members.
MEI interface related changes are moved into separate patch.
Commit msg is updated accordingly.
intel_hdcp_exit is defined and used from i915_unload
v9:
Movement of the hdcp_check_link is moved to new patch [Daniel]
intel_hdcp2_exit is removed as mei_comp will be unbind in i915_unload.
v10:
bool is used in struct to make coding simpler. [Daniel]
hdmi hdcp init is placed correctly after encoder attachment.
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dp.c | 3 ++-
drivers/gpu/drm/i915/intel_drv.h | 15 ++-
drivers/gpu/drm/i915/intel_hdcp.c | 33 ++---
drivers/gpu/drm/i915/intel_hdmi.c | 8
4 files changed, 50 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 681e88405ada..815ee68efa2f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -6950,7 +6950,8 @@ intel_dp_init_connector(struct intel_digital_port
*intel_dig_port,
intel_dp_add_properties(intel_dp, connector);
if (is_hdcp_supported(dev_priv, port) && !intel_dp_is_edp(intel_dp)) {
- int ret = intel_hdcp_init(intel_connector, _dp_hdcp_shim);
+ int ret = intel_hdcp_init(intel_connector, _dp_hdcp_shim,
+ false);
if (ret)
DRM_DEBUG_KMS("HDCP init failed, skipping.\n");
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 90ba5436370e..0ac870feb5e9 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -394,6 +394,17 @@ struct intel_hdcp {
u64 value;
struct delayed_work check_work;
struct work_struct prop_work;
+
+ /* HDCP2.2 related definitions */
+ /* Flag indicates whether this connector supports HDCP2.2 or not. */
+ bool hdcp2_supported;
+
+ /*
+* Content Stream Type defined by content owner. TYPE0(0x0) content can
+* flow in the link protected by HDCP2.2 or HDCP1.4, where as TYPE1(0x1)
+* content can flow only through a link protected by HDCP2.2.
+*/
+ u8 content_type;
};
struct intel_connector {
@@ -2053,12 +2064,14 @@ void intel_hdcp_atomic_check(struct drm_connector
*connector,
struct drm_connector_state *old_state,
struct drm_connector_state *new_state);
int intel_hdcp_init(struct intel_connector *connector,
- const struct intel_hdcp_shim *hdcp_shim);
+ const struct intel_hdcp_shim *hdcp_shim,
+ bool hdcp2_supported);
int intel_hdcp_enable(struct intel_connector *connector);
int intel_hdcp_disable(struct intel_connector *connector);
int intel_hdcp_check_link(struct intel_connector *connector);
bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port);
bool intel_hdcp_capable(struct intel_connector *connector);
+bool is_hdcp2_supported(struct drm_i915_private *dev_priv);
/* intel_psr.c */
#define CAN_PSR(dev_priv) (HAS_PSR(dev_priv) && dev_priv->psr.sink_support)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index 8cb85b07cfde..1a85dc46692d 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -832,14 +832,37 @@ bool is_hdcp_supported(struct drm_i915_private *dev_priv,
enum port port)
return INTEL_GEN(dev_priv) >= 9 && port < PORT_E;
}
+bool is_hdcp2_supported(struct drm_i915_private *dev_priv)
+{
+ if (!IS_ENABLED(CONFIG_INTEL_MEI_HDCP))
+ return false;
+
+ return (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv) ||
+ IS_KABYLAKE(dev_priv));
+}
+
+static void intel_hdcp2_init(struct intel_connector *connector)
+{
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct intel_hdcp *hdcp = >hdcp;
+
+ WARN_ON(!is_hdcp2_supported(dev_priv));
+
+ /* TODO: MEI interface needs to be initialized here */
+ hdcp->hdcp2_supported = true;
+}
+
int intel_hdcp_init(struct intel_connector *connector,
- const struct intel_hdcp_shim *shim)
+ const struct intel_hdcp_shim *shim,
[PATCH v10 06/40] drm/i915: MEI interface definition
Defining the mei-i915 interface functions and initialization of
the interface.
v2:
Adjust to the new interface changes. [Tomas]
Added further debug logs for the failures at MEI i/f.
port in hdcp_port data is equipped to handle -ve values.
v3:
mei comp is matched for global i915 comp master. [Daniel]
In hdcp_shim hdcp_protocol() is replaced with const variable. [Daniel]
mei wrappers are adjusted as per the i/f change [Daniel]
v4:
port initialization is done only at hdcp2_init only [Danvet]
v5:
I915 registers a subcomponent to be matched with mei_hdcp [Daniel]
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 7 +
drivers/gpu/drm/i915/intel_drv.h | 5 +
drivers/gpu/drm/i915/intel_hdcp.c | 378 +-
include/drm/i915_component.h | 3 +
5 files changed, 393 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a7aaa1ac4c99..75aff907ba69 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -904,6 +904,7 @@ static int i915_driver_init_early(struct drm_i915_private
*dev_priv)
mutex_init(_priv->av_mutex);
mutex_init(_priv->wm.wm_mutex);
mutex_init(_priv->pps_mutex);
+ mutex_init(_priv->hdcp_comp_mutex);
i915_memcpy_init_early(dev_priv);
intel_runtime_pm_init_early(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 22da9df1f0a7..d9a0771af4d1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -55,6 +55,7 @@
#include
#include
#include
+#include
#include "i915_fixed.h"
#include "i915_params.h"
@@ -2043,6 +2044,12 @@ struct drm_i915_private {
struct i915_pmu pmu;
+ struct i915_hdcp_comp_master *hdcp_master;
+ bool hdcp_comp_added;
+
+ /* Mutex to protect the above hdcp component related values. */
+ struct mutex hdcp_comp_mutex;
+
/*
* NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
* will be rejected. Instead look for a better place.
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 0ac870feb5e9..63e009286d5f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -41,6 +41,7 @@
#include
#include
#include
+#include
#include
struct drm_printer;
@@ -385,6 +386,9 @@ struct intel_hdcp_shim {
/* Detects panel's hdcp capability. This is optional for HDMI. */
int (*hdcp_capable)(struct intel_digital_port *intel_dig_port,
bool *hdcp_capable);
+
+ /* HDCP adaptation(DP/HDMI) required on the port */
+ enum hdcp_wired_protocol protocol;
};
struct intel_hdcp {
@@ -405,6 +409,7 @@ struct intel_hdcp {
* content can flow only through a link protected by HDCP2.2.
*/
u8 content_type;
+ struct hdcp_port_data port_data;
};
struct intel_connector {
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index 1a85dc46692d..e0bb5f32ba90 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -7,8 +7,10 @@
*/
#include
+#include
#include
#include
+#include
#include "intel_drv.h"
#include "i915_reg.h"
@@ -832,6 +834,348 @@ bool is_hdcp_supported(struct drm_i915_private *dev_priv,
enum port port)
return INTEL_GEN(dev_priv) >= 9 && port < PORT_E;
}
+static __attribute__((unused)) int
+hdcp2_prepare_ake_init(struct intel_connector *connector,
+ struct hdcp2_ake_init *ake_data)
+{
+ struct hdcp_port_data *data = >hdcp.port_data;
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct i915_hdcp_comp_master *comp;
+ int ret;
+
+ mutex_lock(_priv->hdcp_comp_mutex);
+ comp = dev_priv->hdcp_master;
+
+ if (!comp || !comp->ops) {
+ mutex_unlock(_priv->hdcp_comp_mutex);
+ return -EINVAL;
+ }
+
+ ret = comp->ops->initiate_hdcp2_session(comp->mei_dev, data, ake_data);
+ if (ret)
+ DRM_DEBUG_KMS("Prepare_ake_init failed. %d\n", ret);
+ mutex_unlock(_priv->hdcp_comp_mutex);
+
+ return ret;
+}
+
+static __attribute__((unused)) int
+hdcp2_verify_rx_cert_prepare_km(struct intel_connector *connector,
+ struct hdcp2_ake_send_cert *rx_cert,
+ bool *paired,
+ struct hdcp2_ake_no_stored_km *ek_pub_km,
+ size_t *msg_sz)
+{
+ struct hdcp_port_data *data = >hdcp.port_data;
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct i915_hdcp_comp_master *comp;
+ int ret;
+
+ mutex_lock(_priv->hdcp_comp_mutex);
+ comp =
[PATCH v10 03/40] drm/i915: Gathering the HDCP1.4 routines together
All HDCP1.4 routines are gathered together, followed by the generic
functions those can be extended for HDCP2.2 too.
Signed-off-by: Ramalingam C
Acked-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_hdcp.c | 118 +++---
1 file changed, 59 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index ce7ba3a9c000..8cb85b07cfde 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -730,6 +730,65 @@ struct intel_connector *intel_hdcp_to_connector(struct
intel_hdcp *hdcp)
return container_of(hdcp, struct intel_connector, hdcp);
}
+/* Implements Part 3 of the HDCP authorization procedure */
+int intel_hdcp_check_link(struct intel_connector *connector)
+{
+ struct intel_hdcp *hdcp = >hdcp;
+ struct drm_i915_private *dev_priv = connector->base.dev->dev_private;
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+ enum port port = intel_dig_port->base.port;
+ int ret = 0;
+
+ if (!hdcp->shim)
+ return -ENOENT;
+
+ mutex_lock(>mutex);
+
+ if (hdcp->value == DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
+ goto out;
+
+ if (!(I915_READ(PORT_HDCP_STATUS(port)) & HDCP_STATUS_ENC)) {
+ DRM_ERROR("%s:%d HDCP check failed: link is not encrypted,%x\n",
+ connector->base.name, connector->base.base.id,
+ I915_READ(PORT_HDCP_STATUS(port)));
+ ret = -ENXIO;
+ hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
+ schedule_work(>prop_work);
+ goto out;
+ }
+
+ if (hdcp->shim->check_link(intel_dig_port)) {
+ if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
+ hdcp->value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
+ schedule_work(>prop_work);
+ }
+ goto out;
+ }
+
+ DRM_DEBUG_KMS("[%s:%d] HDCP link failed, retrying authentication\n",
+ connector->base.name, connector->base.base.id);
+
+ ret = _intel_hdcp_disable(connector);
+ if (ret) {
+ DRM_ERROR("Failed to disable hdcp (%d)\n", ret);
+ hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
+ schedule_work(>prop_work);
+ goto out;
+ }
+
+ ret = _intel_hdcp_enable(connector);
+ if (ret) {
+ DRM_ERROR("Failed to enable hdcp (%d)\n", ret);
+ hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
+ schedule_work(>prop_work);
+ goto out;
+ }
+
+out:
+ mutex_unlock(>mutex);
+ return ret;
+}
+
static void intel_hdcp_check_work(struct work_struct *work)
{
struct intel_hdcp *hdcp = container_of(to_delayed_work(work),
@@ -866,62 +925,3 @@ void intel_hdcp_atomic_check(struct drm_connector
*connector,
new_state->crtc);
crtc_state->mode_changed = true;
}
-
-/* Implements Part 3 of the HDCP authorization procedure */
-int intel_hdcp_check_link(struct intel_connector *connector)
-{
- struct intel_hdcp *hdcp = >hdcp;
- struct drm_i915_private *dev_priv = connector->base.dev->dev_private;
- struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
- enum port port = intel_dig_port->base.port;
- int ret = 0;
-
- if (!hdcp->shim)
- return -ENOENT;
-
- mutex_lock(>mutex);
-
- if (hdcp->value == DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
- goto out;
-
- if (!(I915_READ(PORT_HDCP_STATUS(port)) & HDCP_STATUS_ENC)) {
- DRM_ERROR("%s:%d HDCP check failed: link is not encrypted,%x\n",
- connector->base.name, connector->base.base.id,
- I915_READ(PORT_HDCP_STATUS(port)));
- ret = -ENXIO;
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
- schedule_work(>prop_work);
- goto out;
- }
-
- if (hdcp->shim->check_link(intel_dig_port)) {
- if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
- schedule_work(>prop_work);
- }
- goto out;
- }
-
- DRM_DEBUG_KMS("[%s:%d] HDCP link failed, retrying authentication\n",
- connector->base.name, connector->base.base.id);
-
- ret = _intel_hdcp_disable(connector);
- if (ret) {
- DRM_ERROR("Failed to disable hdcp (%d)\n", ret);
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
- schedule_work(>prop_work);
- goto out;
- }
-
- ret = _intel_hdcp_enable(connector);
- if (ret) {
-
[PATCH v10 00/40] drm/i915: Implement HDCP2.2
This series enables the HDCP2.2 Type 0 for I915. The sequence for HDCP2.2 authentication and encryption is implemented as a generic flow between HDMI and DP. Encoder specific implementations are moved into hdcp_shim. Intel HWs supports HDCP2.2 through ME FW. Hence this series introduces a client driver for mei bus, so that for HDCP2.2 authentication, HDCP2.2 stack in I915 can avail the services from ME FW. To enable this client driver set the config variable CONFIG_INTEL_MEI_HDCP. Userspace interface remains unchanged as version agnostic. When userspace request for HDCP enable, Kernel will detect the HDCP source and sink's HDCP version(1.4/2.2)capability and enable the best capable version for that combination. This series enables the HDCP2.2 for Type0 content streams. Major changes in v10: - I915-MEI interface is implemented with component framework. - I915 detects the mei_hdcp device availability to enabled HDCP2.2. Hopefully we are near the end of this series. To ease the review process, series is hosted at https://github.com/ramalingampc2008/drm-tip.git hdcp2_2_v10 Daniel Vetter (2): components: multiple components for a device i915/snd_hdac: I915 subcomponent for the snd_hdac Ramalingam C (36): drm/i915: Gathering the HDCP1.4 routines together drm: header for i915 - MEI_HDCP interface drm/i915: Initialize HDCP2.2 drm/i915: MEI interface definition drm/i915: hdcp1.4 CP_IRQ handling and SW encryption tracking drm/i915: Enable and Disable of HDCP2.2 drm/i915: Implement HDCP2.2 receiver authentication drm: helper functions for hdcp2 seq_num to from u32 drm/i915: Implement HDCP2.2 repeater authentication drm: HDCP2.2 link check period drm/i915: Implement HDCP2.2 link integrity check drm/i915: Handle HDCP2.2 downstream topology change drm: removing the DP Errata msg and its msg id drm/i915: Implement the HDCP2.2 support for DP drm/i915: Implement the HDCP2.2 support for HDMI drm/i915: CP_IRQ handling for DP HDCP2.2 msgs drm/i915: Add HDCP2.2 support for DP connectors drm/i915: Add HDCP2.2 support for HDMI connectors misc/mei/hdcp: Client driver for HDCP application misc/mei/hdcp: Define ME FW interface for HDCP2.2 misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session misc/mei/hdcp: Verify Receiver Cert and prepare km misc/mei/hdcp: Verify H_prime misc/mei/hdcp: Store the HDCP Pairing info misc/mei/hdcp: Initiate Locality check misc/mei/hdcp: Verify L_prime misc/mei/hdcp: Prepare Session Key misc/mei/hdcp: Repeater topology verification and ack misc/mei/hdcp: Verify M_prime misc/mei/hdcp: Enabling the HDCP authentication misc/mei/hdcp: Closing wired HDCP2.2 Tx Session misc/mei/hdcp: Component framework for I915 Interface drm/i915: Commit CP without modeset drm/i915: Fix KBL HDCP2.2 encrypt status signalling FOR_TEST: i915/Kconfig: Select mei_hdcp by I915 FOR_TESTING_ONLY: debugfs: Excluding the LSPCon for HDCP1.4 Tomas Winkler (2): mei: bus: whitelist hdcp client mei: bus: export to_mei_cl_device for mei client device drivers drivers/base/component.c | 67 +- drivers/gpu/drm/i915/i915_debugfs.c | 10 +- drivers/gpu/drm/i915/i915_drv.c |1 + drivers/gpu/drm/i915/i915_drv.h |7 + drivers/gpu/drm/i915/intel_audio.c|4 +- drivers/gpu/drm/i915/intel_ddi.c |7 - drivers/gpu/drm/i915/intel_display.c | 10 + drivers/gpu/drm/i915/intel_dp.c | 355 +- drivers/gpu/drm/i915/intel_drv.h | 88 ++- drivers/gpu/drm/i915/intel_hdcp.c | 1248 ++--- drivers/gpu/drm/i915/intel_hdmi.c | 240 ++- drivers/misc/mei/Kconfig |8 + drivers/misc/mei/Makefile |2 + drivers/misc/mei/bus-fixup.c | 16 + drivers/misc/mei/bus.c|1 - drivers/misc/mei/hdcp/Makefile|7 + drivers/misc/mei/hdcp/mei_hdcp.c | 835 ++ drivers/misc/mei/hdcp/mei_hdcp.h | 399 +++ include/drm/drm_hdcp.h| 25 +- include/drm/i915_component.h |7 + include/drm/i915_mei_hdcp_interface.h | 148 include/linux/component.h |5 + include/linux/mei_cl_bus.h|2 + include/sound/hda_component.h |5 +- sound/hda/hdac_component.c|4 +- sound/hda/hdac_i915.c |6 +- 26 files changed, 3352 insertions(+), 155 deletions(-) create mode 100644 drivers/misc/mei/hdcp/Makefile create mode 100644 drivers/misc/mei/hdcp/mei_hdcp.c create mode 100644 drivers/misc/mei/hdcp/mei_hdcp.h create mode 100644 include/drm/i915_mei_hdcp_interface.h -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 02/40] i915/snd_hdac: I915 subcomponent for the snd_hdac
From: Daniel Vetter
Since we need multiple components for I915 for different purposes
(Audio & Mei_hdcp), we adopt the subcomponents methodology introduced
by the previous patch (mentioned below).
Author: Daniel Vetter
Date: Mon Jan 28 17:08:20 2019 +0530
components: multiple components for a device
Signed-off-by: Daniel Vetter
Signed-off-by: Ramalingam C
cc: Greg Kroah-Hartman
cc: Russell King
cc: Rafael J. Wysocki
cc: Jaroslav Kysela
cc: Takashi Iwai
cc: Rodrigo Vivi
cc: Jani Nikula
---
drivers/gpu/drm/i915/intel_audio.c | 4 +++-
include/drm/i915_component.h | 4
include/sound/hda_component.h | 5 +++--
sound/hda/hdac_component.c | 4 ++--
sound/hda/hdac_i915.c | 6 --
5 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_audio.c
b/drivers/gpu/drm/i915/intel_audio.c
index de26cd0a5497..5104c6bbd66f 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -984,7 +984,9 @@ void i915_audio_component_init(struct drm_i915_private
*dev_priv)
{
int ret;
- ret = component_add(dev_priv->drm.dev, _audio_component_bind_ops);
+ ret = component_add_typed(dev_priv->drm.dev,
+ _audio_component_bind_ops,
+ I915_COMPONENT_AUDIO);
if (ret < 0) {
DRM_ERROR("failed to add audio component (%d)\n", ret);
/* continue with reduced functionality */
diff --git a/include/drm/i915_component.h b/include/drm/i915_component.h
index fca22d463e1b..72fbb037f9b3 100644
--- a/include/drm/i915_component.h
+++ b/include/drm/i915_component.h
@@ -26,6 +26,10 @@
#include "drm_audio_component.h"
+enum i915_component_type {
+ I915_COMPONENT_AUDIO = 1,
+};
+
/* MAX_PORT is the number of port
* It must be sync with I915_MAX_PORTS defined i915_drv.h
*/
diff --git a/include/sound/hda_component.h b/include/sound/hda_component.h
index 2ec31b358950..d4804c72d959 100644
--- a/include/sound/hda_component.h
+++ b/include/sound/hda_component.h
@@ -20,7 +20,7 @@ int snd_hdac_acomp_get_eld(struct hdac_device *codec,
hda_nid_t nid, int dev_id,
bool *audio_enabled, char *buffer, int max_bytes);
int snd_hdac_acomp_init(struct hdac_bus *bus,
const struct drm_audio_component_audio_ops *aops,
- int (*match_master)(struct device *, void *),
+ int (*match_master)(struct device *, int, void *),
size_t extra_size);
int snd_hdac_acomp_exit(struct hdac_bus *bus);
int snd_hdac_acomp_register_notifier(struct hdac_bus *bus,
@@ -47,7 +47,8 @@ static inline int snd_hdac_acomp_get_eld(struct hdac_device
*codec, hda_nid_t ni
}
static inline int snd_hdac_acomp_init(struct hdac_bus *bus,
const struct
drm_audio_component_audio_ops *aops,
- int (*match_master)(struct device *, void
*),
+ int (*match_master)(struct device *,
+ int, void *),
size_t extra_size)
{
return -ENODEV;
diff --git a/sound/hda/hdac_component.c b/sound/hda/hdac_component.c
index a6d37b9d6413..5c95933e739a 100644
--- a/sound/hda/hdac_component.c
+++ b/sound/hda/hdac_component.c
@@ -269,7 +269,7 @@ EXPORT_SYMBOL_GPL(snd_hdac_acomp_register_notifier);
*/
int snd_hdac_acomp_init(struct hdac_bus *bus,
const struct drm_audio_component_audio_ops *aops,
- int (*match_master)(struct device *, void *),
+ int (*match_master)(struct device *, int, void *),
size_t extra_size)
{
struct component_match *match = NULL;
@@ -288,7 +288,7 @@ int snd_hdac_acomp_init(struct hdac_bus *bus,
bus->audio_component = acomp;
devres_add(dev, acomp);
- component_match_add(dev, , match_master, bus);
+ component_match_add_typed(dev, , match_master, bus);
ret = component_master_add_with_match(dev, _component_master_ops,
match);
if (ret < 0)
diff --git a/sound/hda/hdac_i915.c b/sound/hda/hdac_i915.c
index 617ff1aa818f..7aee090e3d27 100644
--- a/sound/hda/hdac_i915.c
+++ b/sound/hda/hdac_i915.c
@@ -82,9 +82,11 @@ void snd_hdac_i915_set_bclk(struct hdac_bus *bus)
}
EXPORT_SYMBOL_GPL(snd_hdac_i915_set_bclk);
-static int i915_component_master_match(struct device *dev, void *data)
+static int i915_component_master_match(struct device *dev, int subcomponent,
+ void *data)
{
- return !strcmp(dev->driver->name, "i915");
+ return !strcmp(dev->driver->name, "i915") &&
+ subcomponent == I915_COMPONENT_AUDIO;
}
/* check whether intel graphics is present */
--
[PATCH v10 08/40] drm/i915: Enable and Disable of HDCP2.2
Considering that HDCP2.2 is more secure than HDCP1.4, When a setup
supports HDCP2.2 and HDCP1.4, HDCP2.2 will be enabled.
When HDCP2.2 enabling fails and HDCP1.4 is supported, HDCP1.4 is
enabled.
This change implements a sequence of enabling and disabling of
HDCP2.2 authentication and HDCP2.2 port encryption.
v2:
Included few optimization suggestions [Chris Wilson]
Commit message is updated as per the rebased version.
intel_wait_for_register is used instead of wait_for. [Chris Wilson]
v3:
Extra comment added and Style issue fixed [Uma]
v4:
Rebased as part of patch reordering.
HDCP2 encryption status is tracked.
HW state check is moved into WARN_ON [Daniel]
v5:
Redefined the mei service functions as per comp redesign.
Merged patches related to hdcp2.2 enabling and disabling [Sean Paul].
Required shim functionality is defined [Sean Paul]
v6:
Return values are handles [Uma]
Realigned the code.
Check for comp_master is removed.
v7:
HDCP2.2 is attempted only if mei interface is up.
Adjust to the new interface
Avoid bool usage in struct [Tomas]
v8:
mei_binded status check is removed.
%s/hdcp2_in_use/hdcp2_encrypted
v9:
bool is used in struct intel_hdcp. [Daniel]
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_drv.h | 7 ++
drivers/gpu/drm/i915/intel_hdcp.c | 202 +++---
2 files changed, 195 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 13a41e8cf4ff..31c7a4577ca9 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -389,6 +389,10 @@ struct intel_hdcp_shim {
/* HDCP adaptation(DP/HDMI) required on the port */
enum hdcp_wired_protocol protocol;
+
+ /* Detects whether Panel is HDCP2.2 capable */
+ int (*hdcp_2_2_capable)(struct intel_digital_port *intel_dig_port,
+ bool *capable);
};
struct intel_hdcp {
@@ -406,6 +410,9 @@ struct intel_hdcp {
/* Flag indicates whether this connector supports HDCP2.2 or not. */
bool hdcp2_supported;
+ /* HDCP2.2 Encryption status */
+ bool hdcp2_encrypted;
+
/*
* Content Stream Type defined by content owner. TYPE0(0x0) content can
* flow in the link protected by HDCP2.2 or HDCP1.4, where as TYPE1(0x1)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index c1b057f1501b..fbf8b7893bfa 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -74,6 +74,23 @@ bool intel_hdcp_capable(struct intel_connector *connector)
return capable;
}
+/* Is HDCP2.2 capable on Platform and Sink */
+static bool intel_hdcp2_capable(struct intel_connector *connector)
+{
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+ struct intel_hdcp *hdcp = >hdcp;
+ bool capable = false;
+
+ /* I915 support for HDCP2.2 */
+ if (!hdcp->hdcp2_supported)
+ return false;
+
+ /* Sink's capability for HDCP2.2 */
+ hdcp->shim->hdcp_2_2_capable(intel_dig_port, );
+
+ return capable;
+}
+
static inline bool intel_hdcp_in_use(struct intel_connector *connector)
{
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
@@ -1094,8 +,7 @@ int hdcp2_authenticate_port(struct intel_connector
*connector)
return ret;
}
-static __attribute__((unused))
-int hdcp2_close_mei_session(struct intel_connector *connector)
+static int hdcp2_close_mei_session(struct intel_connector *connector)
{
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct i915_hdcp_comp_master *comp;
@@ -1116,12 +1132,157 @@ int hdcp2_close_mei_session(struct intel_connector
*connector)
return ret;
}
-static __attribute__((unused))
-int hdcp2_deauthenticate_port(struct intel_connector *connector)
+static int hdcp2_deauthenticate_port(struct intel_connector *connector)
{
return hdcp2_close_mei_session(connector);
}
+static int hdcp2_authenticate_sink(struct intel_connector *connector)
+{
+ DRM_ERROR("Sink authentication is done in subsequent patches\n");
+
+ return -EINVAL;
+}
+
+static int hdcp2_enable_encryption(struct intel_connector *connector)
+{
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct intel_hdcp *hdcp = >hdcp;
+ enum port port = connector->encoder->port;
+ int ret;
+
+ WARN_ON(I915_READ(HDCP2_STATUS_DDI(port)) & LINK_ENCRYPTION_STATUS);
+
+ if (hdcp->shim->toggle_signalling) {
+ ret = hdcp->shim->toggle_signalling(intel_dig_port, true);
+ if (ret) {
+ DRM_ERROR("Failed to enable HDCP signalling. %d\n",
+ ret);
+
[Bug 202445] amdgpu/dc: framerate dropping below adaptive sync range causes screen flickering
https://bugzilla.kernel.org/show_bug.cgi?id=202445 --- Comment #9 from Clément Guérin (li...@protonmail.com) --- I just tested built `drm-next-5.1-wip` (8054c54a6), it's flickering/stuttering as well. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202445] amdgpu/dc: framerate dropping below adaptive sync range causes screen flickering
https://bugzilla.kernel.org/show_bug.cgi?id=202445 --- Comment #8 from Clément Guérin (li...@protonmail.com) --- Strange. It looks like this commit has been merged in the mainline kernel before rc1. https://github.com/torvalds/linux/commit/180db303ff466a3887c841e805568b92233e2d0e#diff-730f0f79c9b013ef9a2c68f236d473b0 This should be a legitimate bug then. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108487] Wayland compositors are unable to use hardware acceleration on i915
https://bugs.freedesktop.org/show_bug.cgi?id=108487 --- Comment #13 from Daniel Stone --- A Weston patch is available here, but needs testing: https://gitlab.freedesktop.org/wayland/weston/merge_requests/92 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4.1 2/3] drm: Add CRTC background color property (v4)
On Wed, Jan 30, 2019 at 11:01:25PM +0200, Ville Syrjälä wrote:
> On Wed, Jan 30, 2019 at 10:51:21AM -0800, Matt Roper wrote:
> > Some display controllers can be programmed to present non-black colors
> > for pixels not covered by any plane (or pixels covered by the
> > transparent regions of higher planes). Compositors that want a UI with
> > a solid color background can potentially save memory bandwidth by
> > setting the CRTC background property and using smaller planes to display
> > the rest of the content.
> >
> > To avoid confusion between different ways of encoding RGB data, we
> > define a standard 64-bit format that should be used for this property's
> > value. Helper functions and macros are provided to generate and dissect
> > values in this standard format with varying component precision values.
> >
> > v2:
> > - Swap internal representation's blue and red bits to make it easier
> >to read if printed out. (Ville)
> > - Document bgcolor property in drm_blend.c. (Sean Paul)
> > - s/background_color/bgcolor/ for consistency between property name and
> >value storage field. (Sean Paul)
> > - Add a convenience function to attach property to a given crtc.
> >
> > v3:
> > - Restructure ARGB component extraction macros to be easier to
> >understand and enclose the parameters in () to avoid calculations
> >if expressions are passed. (Sean Paul)
> > - s/rgba/argb/ in helper function/macro names. Even though the idea is
> >to not worry about the internal representation of the u64, it can
> >still be confusing to look at code that uses 'rgba' terminology, but
> >stores values with argb ordering. (Ville)
> >
> > v4:
> > - Drop the bgcolor_changed flag. (Ville, Brian Starkey)
> > - Clarify in kerneldoc that background color is expected to undergo the
> >same pipe-level degamma/csc/gamma transformations that planes do.
> >(Brian Starkey)
> > - Update kerneldoc to indicate non-opaque colors are allowed, but are
> >generally only useful in special cases such as when writeback
> >connectors are used (Brian Starkey / Eric Anholt)
> >
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: wei.c...@intel.com
> > Cc: harish.krupo@intel.com
> > Cc: Ville Syrjälä
> > Cc: Sean Paul
> > Cc: Brian Starkey
> > Cc: Eric Anholt
> > Cc: Stéphane Marchesin
> > Cc: Daniel Vetter
> > Signed-off-by: Matt Roper
> > Reviewed-by(v2): Sean Paul
> > Reviewed-by: Brian Starkey
> > ---
> > drivers/gpu/drm/drm_atomic_uapi.c | 4
> > drivers/gpu/drm/drm_blend.c | 27 ---
> > drivers/gpu/drm/drm_mode_config.c | 6 ++
> > include/drm/drm_blend.h | 1 +
> > include/drm/drm_crtc.h| 12
> > include/drm/drm_mode_config.h | 5 +
> > include/uapi/drm/drm_mode.h | 28
> > 7 files changed, 80 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index 9a1f41adfc67..d569e20e34e3 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -469,6 +469,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
> > *crtc,
> > return -EFAULT;
> >
> > set_out_fence_for_crtc(state->state, crtc, fence_ptr);
> > + } else if (property == config->bgcolor_property) {
> > + state->bgcolor = val;
> > } else if (crtc->funcs->atomic_set_property) {
> > return crtc->funcs->atomic_set_property(crtc, state, property,
> > val);
> > } else {
> > @@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
> > *val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
> > else if (property == config->prop_out_fence_ptr)
> > *val = 0;
> > + else if (property == config->bgcolor_property)
> > + *val = state->bgcolor;
> > else if (crtc->funcs->atomic_get_property)
> > return crtc->funcs->atomic_get_property(crtc, state, property,
> > val);
> > else
> > diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> > index 0c78ca386cbe..d451ac9e1d6d 100644
> > --- a/drivers/gpu/drm/drm_blend.c
> > +++ b/drivers/gpu/drm/drm_blend.c
> > @@ -175,9 +175,22 @@
> > * plane does not expose the "alpha" property, then this is
> > * assumed to be 1.0
> > *
> > - * Note that all the property extensions described here apply either to the
> > - * plane or the CRTC (e.g. for the background color, which currently is not
> > - * exposed and assumed to be black).
> > + * The property extensions described above all apply to the plane. Drivers
> > + * may also expose the following crtc property extension:
> > + *
> > + * BACKGROUND_COLOR:
> > + * Background color is setup with drm_crtc_add_bgcolor_property(). It
> > + * controls the ARGB color of a full-screen layer that exists below all
> > + * planes. This
Re: [PATCH 1/2] drm/vmwgfx: Fix setting of dma masks
For the series
Reviewed-by: Deepak Rawat
On Tue, 2019-01-29 at 14:35 +0100, Thomas Hellstrom wrote:
> Previously we set only the dma mask and not the coherent mask. Fix
> that.
> Also, for clarity, make sure both are initially set to 64 bits.
>
> Fixes: 0d00c488f3de: ("drm/vmwgfx: Fix the driver for large dma
> addresses")
> Signed-off-by: Thomas Hellstrom
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index 3e2bcff34032..ae9df4432bfc 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -600,13 +600,16 @@ static int vmw_dma_select_mode(struct
> vmw_private *dev_priv)
> static int vmw_dma_masks(struct vmw_private *dev_priv)
> {
> struct drm_device *dev = dev_priv->dev;
> + int ret = 0;
>
> - if (intel_iommu_enabled &&
> + ret = dma_set_mask_and_coherent(dev->dev, DMA_BIT_MASK(64));
> + if (dev_priv->map_mode != vmw_dma_phys &&
> (sizeof(unsigned long) == 4 || vmw_restrict_dma_mask)) {
> DRM_INFO("Restricting DMA addresses to 44 bits.\n");
> - return dma_set_mask(dev->dev, DMA_BIT_MASK(44));
> + return dma_set_mask_and_coherent(dev->dev,
> DMA_BIT_MASK(44));
> }
> - return 0;
> +
> + return ret;
> }
>
> static int vmw_driver_load(struct drm_device *dev, unsigned long
> chipset)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v4.1 0/3] CRTC background color
On Wed, Jan 30, 2019 at 09:57:10PM +0100, Daniel Vetter wrote: > On Wed, Jan 30, 2019 at 10:56:26AM -0800, Matt Roper wrote: > > On Wed, Jan 30, 2019 at 10:51:19AM -0800, Matt Roper wrote: > > > Previous patch series was here: > > > > > > https://lists.freedesktop.org/archives/dri-devel/2018-December/201949.html > > > > > > I'm told the ChromeOS userspace code to make use of the background color > > > has been reviewed and is ready for use: > > > * https://chromium-review.googlesource.com/c/chromium/src/+/1278858 > > > * https://chromium-review.googlesource.com/c/chromium/src/+/1278858 > > > > Woops, the second link here should have been to > > > > > > https://chromium-review.googlesource.com/c/chromiumos/platform/drm-tests/+/1241436 > > > > which I believe is some unit tests to go along with the main userspace > > code. > > Do we have this as igts too? > -Daniel Yeah, I posted it along with some of the earlier revisions of the series, but haven't reposted the latest copy lately. I'll check and see if it needs a rebase and then post it shortly. Unfortunately the IGT isn't as useful as I'd like it to be since the CRC's for a plane filled with a solid color never come up the same as a pure background color (at least on the APL platform I'm using). I can run the IGT in interactive mode and the colors seem identical to visual inspection, but the CRC values never agree, so I've disabled the CRC comparison in the test for now. I'm not sure if this is related to the other blending quirks of gen9; it will be interesting to see if the CRC's match on an Icelake or something. FWIW, I've mmap'd the Cairo-generated plane framebuffer and verified that it contains exactly the pixel values we'd expect (so it's not a matter of bad roundoff in Cairo), and I've tried flipping both 8bpc and 10bpc pixel formats (to match the background color's 10 bits per component), but nothing seems to make the CRC's match. :-( Matt > > > > > > > Matt > > > > > > > > So I think ABI-wise we've met the userspace consumer requirements to > > > upstream this; we just need to get reviews on the two i915-specific > > > patches and a clean CI report. > > > > > > v4.1 is identical to v4 aside from a rebase onto the latest drm-tip. > > > > > > > > > Matt Roper (3): > > > drm/i915: Force background color to black for gen9+ (v2) > > > drm: Add CRTC background color property (v4) > > > drm/i915/gen9+: Add support for pipe background color (v4) > > > > > > drivers/gpu/drm/drm_atomic_uapi.c| 4 > > > drivers/gpu/drm/drm_blend.c | 27 +++--- > > > drivers/gpu/drm/drm_mode_config.c| 6 + > > > drivers/gpu/drm/i915/i915_debugfs.c | 9 > > > drivers/gpu/drm/i915/i915_reg.h | 6 + > > > drivers/gpu/drm/i915/intel_display.c | 43 > > > > > > include/drm/drm_blend.h | 1 + > > > include/drm/drm_crtc.h | 12 ++ > > > include/drm/drm_mode_config.h| 5 + > > > include/uapi/drm/drm_mode.h | 28 +++ > > > 10 files changed, 138 insertions(+), 3 deletions(-) > > > > > > -- > > > 2.14.5 > > > > > > > -- > > Matt Roper > > Graphics Software Engineer > > IoTG Platform Enabling & Development > > Intel Corporation > > (916) 356-2795 > > ___ > > Intel-gfx mailing list > > intel-...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch -- Matt Roper Graphics Software Engineer IoTG Platform Enabling & Development Intel Corporation (916) 356-2795 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On Wed, Jan 30, 2019 at 10:51:55PM +, Jason Gunthorpe wrote: > On Wed, Jan 30, 2019 at 05:47:05PM -0500, Jerome Glisse wrote: > > On Wed, Jan 30, 2019 at 10:33:04PM +, Jason Gunthorpe wrote: > > > On Wed, Jan 30, 2019 at 05:30:27PM -0500, Jerome Glisse wrote: > > > > > > > > What is the problem in the HMM mirror that it needs this restriction? > > > > > > > > No restriction at all here. I think i just wasn't understood. > > > > > > Are you are talking about from the exporting side - where the thing > > > creating the VMA can really only put one distinct object into it? > > > > The message i was trying to get accross is that HMM mirror will > > always succeed for everything* except for special vma ie mmap of > > device file. For those it can only succeed if a p2p_map() call > > succeed. > > > > So any user of HMM mirror might to know why the mirroring fail ie > > was it because something exceptional is happening ? Or is it because > > i was trying to map a special vma which can be forbiden. > > > > Hence why i assume that you might want to know about such p2p_map > > failure at the time you create the umem odp object as it might be > > some failure you might want to report differently and handle > > differently. If you do not care about differentiating OOM or > > exceptional failure from p2p_map failure than you have nothing to > > worry about you will get the same error from HMM for both. > > I think my hope here was that we could have some kind of 'trial' > interface where very eary users can call > 'hmm_mirror_is_maybe_supported(dev, user_ptr, len)' and get a failure > indication. > > We probably wouldn't call this on the full address space though Yes we can do special wrapper around the general case that allow caller to differentiate failure. So at creation you call the special flavor and get proper distinction between error. Afterward during normal operation any failure is just treated in a same way no matter what is the reasons (munmap, mremap, mprotect, ...). > Beyond that it is just inevitable there can be problems faulting if > the memory map is messed with after MR is created. > > And here again, I don't want to worry about any particular VMA > boundaries.. You do not have to worry about boundaries HMM will return -EFAULT if there is no valid vma behind the address you are trying to map (or if the vma prot does not allow you to access it). So then you can handle that failure just like you do now and as my ODP HMM patch preserve. Cheers, Jérôme ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On Wed, Jan 30, 2019 at 10:33:04PM +, Jason Gunthorpe wrote: > On Wed, Jan 30, 2019 at 05:30:27PM -0500, Jerome Glisse wrote: > > > > What is the problem in the HMM mirror that it needs this restriction? > > > > No restriction at all here. I think i just wasn't understood. > > Are you are talking about from the exporting side - where the thing > creating the VMA can really only put one distinct object into it? The message i was trying to get accross is that HMM mirror will always succeed for everything* except for special vma ie mmap of device file. For those it can only succeed if a p2p_map() call succeed. So any user of HMM mirror might to know why the mirroring fail ie was it because something exceptional is happening ? Or is it because i was trying to map a special vma which can be forbiden. Hence why i assume that you might want to know about such p2p_map failure at the time you create the umem odp object as it might be some failure you might want to report differently and handle differently. If you do not care about differentiating OOM or exceptional failure from p2p_map failure than you have nothing to worry about you will get the same error from HMM for both. Cheers, Jérôme * Everything except when they are exceptional condition like OOM or poisonous memory. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On Wed, Jan 30, 2019 at 09:56:07PM +, Jason Gunthorpe wrote: > On Wed, Jan 30, 2019 at 04:45:25PM -0500, Jerome Glisse wrote: > > On Wed, Jan 30, 2019 at 08:50:00PM +, Jason Gunthorpe wrote: > > > On Wed, Jan 30, 2019 at 03:43:32PM -0500, Jerome Glisse wrote: > > > > On Wed, Jan 30, 2019 at 08:11:19PM +, Jason Gunthorpe wrote: > > > > > On Wed, Jan 30, 2019 at 01:00:02PM -0700, Logan Gunthorpe wrote: > > > > > > > > > > > We never changed SGLs. We still use them to pass p2pdma pages, only > > > > > > we > > > > > > need to be a bit careful where we send the entire SGL. I see no > > > > > > reason > > > > > > why we can't continue to be careful once their in userspace if > > > > > > there's > > > > > > something in GUP to deny them. > > > > > > > > > > > > It would be nice to have heterogeneous SGLs and it is something we > > > > > > should work toward but in practice they aren't really necessary at > > > > > > the > > > > > > moment. > > > > > > > > > > RDMA generally cannot cope well with an API that requires homogeneous > > > > > SGLs.. User space can construct complex MRs (particularly with the > > > > > proposed SGL MR flow) and we must marshal that into a single SGL or > > > > > the drivers fall apart. > > > > > > > > > > Jerome explained that GPU is worse, a single VMA may have a random mix > > > > > of CPU or device pages.. > > > > > > > > > > This is a pretty big blocker that would have to somehow be fixed. > > > > > > > > Note that HMM takes care of that RDMA ODP with my ODP to HMM patch, > > > > so what you get for an ODP umem is just a list of dma address you > > > > can program your device to. The aim is to avoid the driver to care > > > > about that. The access policy when the UMEM object is created by > > > > userspace through verbs API should however ascertain that for mmap > > > > of device file it is only creating a UMEM that is fully covered by > > > > one and only one vma. GPU device driver will have one vma per logical > > > > GPU object. I expect other kind of device do that same so that they > > > > can match a vma to a unique object in their driver. > > > > > > A one VMA rule is not really workable. > > > > > > With ODP VMA boundaries can move around across the lifetime of the MR > > > and we have no obvious way to fail anything if userpace puts a VMA > > > boundary in the middle of an existing ODP MR address range. > > > > This is true only for vma that are not mmap of a device file. This is > > what i was trying to get accross. An mmap of a file is never merge > > so it can only get split/butcher by munmap/mremap but when that happen > > you also need to reflect the virtual address space change to the > > device ie any access to a now invalid range must trigger error. > > Why is it invalid? The address range still has valid process memory? If you do munmap(A, size) then all address in the range [A, A+size] are invalid. This is what i am refering too here. Same for mremap. > > What is the problem in the HMM mirror that it needs this restriction? No restriction at all here. I think i just wasn't understood. > There is also the situation where we create an ODP MR that spans 0 -> > U64_MAX in the process address space. In this case there are lots of > different VMAs it covers and we expect it to fully track all changes > to all VMAs. Yes and that works however any memory access above TASK_SIZE will return -EFAULT as this is kernel address space so you can only access anything that is a valid process virtual address. > > So we have to spin up dedicated umem_odps that carefully span single > VMAs, and somehow track changes to VMA ? No you do not. > > mlx5 odp does some of this already.. But yikes, this needs some pretty > careful testing in all these situations. Sorry if i confused you even more than the first time. Everything works you have nothing to worry about :) > > > > I think the HMM mirror API really needs to deal with this for the > > > driver somehow. > > > > Yes the HMM does deal with this for you, you do not have to worry about > > it. Sorry if that was not clear. I just wanted to stress that vma that > > are mmap of a file do not behave like other vma hence when you create > > the UMEM you can check for those if you feel the need. > > What properties do we get from HMM mirror? Will it tell us when to > create more umems to cover VMA seams or will it just cause undesired > no-mapped failures in some cases? You do not get anything from HMM mirror, i might add a flag so that HMM can report this special condition if driver wants to know. If you want to know you have to look at the vma by yourself. GPU driver will definitly want to know whem importing so i might add a flag so that they do not have to lookup the vma themself to know. Again if you do not care then just ignore everything here, it is handled by HMM and you do not have to worry one bit. If it worked with GUP it will work with HMM and with those p2p patches if it will even
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On Wed, Jan 30, 2019 at 08:50:00PM +, Jason Gunthorpe wrote: > On Wed, Jan 30, 2019 at 03:43:32PM -0500, Jerome Glisse wrote: > > On Wed, Jan 30, 2019 at 08:11:19PM +, Jason Gunthorpe wrote: > > > On Wed, Jan 30, 2019 at 01:00:02PM -0700, Logan Gunthorpe wrote: > > > > > > > We never changed SGLs. We still use them to pass p2pdma pages, only we > > > > need to be a bit careful where we send the entire SGL. I see no reason > > > > why we can't continue to be careful once their in userspace if there's > > > > something in GUP to deny them. > > > > > > > > It would be nice to have heterogeneous SGLs and it is something we > > > > should work toward but in practice they aren't really necessary at the > > > > moment. > > > > > > RDMA generally cannot cope well with an API that requires homogeneous > > > SGLs.. User space can construct complex MRs (particularly with the > > > proposed SGL MR flow) and we must marshal that into a single SGL or > > > the drivers fall apart. > > > > > > Jerome explained that GPU is worse, a single VMA may have a random mix > > > of CPU or device pages.. > > > > > > This is a pretty big blocker that would have to somehow be fixed. > > > > Note that HMM takes care of that RDMA ODP with my ODP to HMM patch, > > so what you get for an ODP umem is just a list of dma address you > > can program your device to. The aim is to avoid the driver to care > > about that. The access policy when the UMEM object is created by > > userspace through verbs API should however ascertain that for mmap > > of device file it is only creating a UMEM that is fully covered by > > one and only one vma. GPU device driver will have one vma per logical > > GPU object. I expect other kind of device do that same so that they > > can match a vma to a unique object in their driver. > > A one VMA rule is not really workable. > > With ODP VMA boundaries can move around across the lifetime of the MR > and we have no obvious way to fail anything if userpace puts a VMA > boundary in the middle of an existing ODP MR address range. This is true only for vma that are not mmap of a device file. This is what i was trying to get accross. An mmap of a file is never merge so it can only get split/butcher by munmap/mremap but when that happen you also need to reflect the virtual address space change to the device ie any access to a now invalid range must trigger error. > > I think the HMM mirror API really needs to deal with this for the > driver somehow. Yes the HMM does deal with this for you, you do not have to worry about it. Sorry if that was not clear. I just wanted to stress that vma that are mmap of a file do not behave like other vma hence when you create the UMEM you can check for those if you feel the need. Cheers, Jérôme ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/doc: Move hdmi infoframe docs
On Wed, Jan 30, 2019 at 05:13:13PM +, Kazlauskas, Nicholas wrote: > On 1/30/19 11:30 AM, Daniel Vetter wrote: > > .. next to all the other sink helpers. The rect library is more used > > for handling plane clipping, so belongs to those imo. > > > > Signed-off-by: Daniel Vetter > > Reviewed-by: Nicholas Kazlauskas > > Looks better than being sandwiched between the HDMI helpers. Flip work > is also plane related in a sense. Yup, that's what I meant with plane helpers - the kms helper intro groups all these (flip, plane helpers, rect stuff, ...) into a plane related helpers pile. Thanks for taking a look, patch merged. -Daniel > > Nicholas Kazlauskas > > > --- > > Documentation/gpu/drm-kms-helpers.rst | 24 > > 1 file changed, 12 insertions(+), 12 deletions(-) > > > > diff --git a/Documentation/gpu/drm-kms-helpers.rst > > b/Documentation/gpu/drm-kms-helpers.rst > > index fbd11b2fe5b5..17ca7f8bf3d3 100644 > > --- a/Documentation/gpu/drm-kms-helpers.rst > > +++ b/Documentation/gpu/drm-kms-helpers.rst > > @@ -296,18 +296,6 @@ SCDC Helper Functions Reference > > .. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c > > :export: > > > > -Rectangle Utilities Reference > > -= > > - > > -.. kernel-doc:: include/drm/drm_rect.h > > - :doc: rect utils > > - > > -.. kernel-doc:: include/drm/drm_rect.h > > - :internal: > > - > > -.. kernel-doc:: drivers/gpu/drm/drm_rect.c > > - :export: > > - > > HDMI Infoframes Helper Reference > > > > > > @@ -322,6 +310,18 @@ libraries and hence is also included here. > > .. kernel-doc:: drivers/video/hdmi.c > > :export: > > > > +Rectangle Utilities Reference > > += > > + > > +.. kernel-doc:: include/drm/drm_rect.h > > + :doc: rect utils > > + > > +.. kernel-doc:: include/drm/drm_rect.h > > + :internal: > > + > > +.. kernel-doc:: drivers/gpu/drm/drm_rect.c > > + :export: > > + > > Flip-work Helper Reference > > == > > > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/doc: Drop chapter "KMS Initialization and Cleanup"
On Wed, Jan 30, 2019 at 09:04:23PM +, Kazlauskas, Nicholas wrote:
> On 1/30/19 4:02 PM, Daniel Vetter wrote:
> > On Wed, Jan 30, 2019 at 05:33:00PM +, Kazlauskas, Nicholas wrote:
> >> On 1/30/19 11:30 AM, Daniel Vetter wrote:
> >>> It only talks about crtc, brings up intel as an exampel and I think is
> >>
> >> nit: Should be "example".
> >
> > Will fix when applying.
> >
> >>> more misleading than useful really. Plus we have lots of discussion
> >>> about how your standard kms driver should be initialized/cleaned up,
> >>> so maybe better to document this when we have a better idea.
> >>>
> >>> Signed-off-by: Daniel Vetter
> >>> ---
> >>>Documentation/gpu/drm-kms.rst | 96 ---
> >>>1 file changed, 96 deletions(-)
> >>>
> >>> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> >>> index 75c882e09fee..23a3c986ef6d 100644
> >>> --- a/Documentation/gpu/drm-kms.rst
> >>> +++ b/Documentation/gpu/drm-kms.rst
> >>> @@ -410,102 +410,6 @@ Encoder Functions Reference
> >>>.. kernel-doc:: drivers/gpu/drm/drm_encoder.c
> >>> :export:
> >>>
> >>> -KMS Initialization and Cleanup
> >>> -==
> >>> -
> >>> -A KMS device is abstracted and exposed as a set of planes, CRTCs,
> >>> -encoders and connectors. KMS drivers must thus create and initialize all
> >>> -those objects at load time after initializing mode setting.
> >>> -
> >>> -CRTCs (:c:type:`struct drm_crtc `)
> >>> -
> >>> -
> >>> -A CRTC is an abstraction representing a part of the chip that contains a
> >>> -pointer to a scanout buffer. Therefore, the number of CRTCs available
> >>> -determines how many independent scanout buffers can be active at any
> >>> -given time. The CRTC structure contains several fields to support this:
> >>> -a pointer to some video memory (abstracted as a frame buffer object), a
> >>> -display mode, and an (x, y) offset into the video memory to support
> >>> -panning or configurations where one piece of video memory spans multiple
> >>> -CRTCs.
> >>
> >> This is mostly a duplicate of what's already in the CRTC abstraction
> >> section but it may be worth carrying over the bit about "the number of
> >> CRTCs available determining the number of independent scanout buffers
> >> that can be active at any given time".
> >
> > Oh I didn't even read this. This is just plain wrong and probably predates
> > drm_plane (when it kinda was true-ish, if you'd ignore cursors). Now this
> > would map to number of drm_planes, except
> > - cursors can still be an exceptions
> > - yuv multi-planar might or might not be multiple planes per drm_plane.
> >
> > Aka it's really complicated :-)
> >
> > This is definitely much better explained in the kms overview section at
> > the top of:
> >
> > https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#overview
> >
> > Plus everything that's getting linked from there ofc.
> >
> >>> -
> >>> -CRTC Initialization
> >>> -~~~
> >>> -
> >>> -A KMS device must create and register at least one struct
> >>> -:c:type:`struct drm_crtc ` instance. The instance is
> >>> -allocated and zeroed by the driver, possibly as part of a larger
> >>> -structure, and registered with a call to :c:func:`drm_crtc_init()`
> >>> -with a pointer to CRTC functions.
> >>> -
> >>> -
> >>> -Cleanup
> >>>
> >>> -
> >>> -The DRM core manages its objects' lifetime. When an object is not needed
> >>> -anymore the core calls its destroy function, which must clean up and
> >>> -free every resource allocated for the object. Every
> >>> -:c:func:`drm_\*_init()` call must be matched with a corresponding
> >>> -:c:func:`drm_\*_cleanup()` call to cleanup CRTCs
> >>> -(:c:func:`drm_crtc_cleanup()`), planes
> >>> -(:c:func:`drm_plane_cleanup()`), encoders
> >>> -(:c:func:`drm_encoder_cleanup()`) and connectors
> >>> -(:c:func:`drm_connector_cleanup()`). Furthermore, connectors that
> >>> -have been added to sysfs must be removed by a call to
> >>> -:c:func:`drm_connector_unregister()` before calling
> >>> -:c:func:`drm_connector_cleanup()`.
> >>> -
> >>> -Connectors state change detection must be cleanup up with a call to
> >>> -:c:func:`drm_kms_helper_poll_fini()`.
> >>> -
> >>> -Output discovery and initialization example
> >>>
> >>> -
> >>> -.. code-block:: c
> >>> -
> >>> -void intel_crt_init(struct drm_device *dev)
> >>> -{
> >>> -struct drm_connector *connector;
> >>> -struct intel_output *intel_output;
> >>> -
> >>> -intel_output = kzalloc(sizeof(struct intel_output), GFP_KERNEL);
> >>> -if (!intel_output)
> >>> -return;
> >>> -
> >>> -connector = _output->base;
> >>> -drm_connector_init(dev, _output->base,
> >>> - _crt_connector_funcs, DRM_MODE_CONNECTOR_VGA);
> >>> -
> >>> -drm_encoder_init(dev, _output->enc, _crt_enc_funcs,
>
Re: [PATCH v4.1 3/3] drm/i915/gen9+: Add support for pipe background color (v4)
On Wed, Jan 30, 2019 at 10:51:22AM -0800, Matt Roper wrote:
> Gen9+ platforms allow CRTC's to be programmed with a background/canvas
> color below the programmable planes. Let's expose this for use by
> compositors.
>
> v2:
> - Split out bgcolor sanitization and programming of csc/gamma bits to a
>separate patch that we can land before the ABI changes are ready to
>go in. (Ville)
> - Change a temporary variable name to be more consistent with
>other similar functions. (Ville)
> - Change register name to SKL_CANVAS for consistency with the
>CHV_CANVAS register.
>
> v3:
> - Switch register name back to SKL_BOTTOM_COLOR. (Ville)
> - Use non-_FW register write. (Ville)
> - Minor parameter rename for consistency. (Ville)
>
> v4:
> - Removed use of bgcolor_changed flag.
>
> Cc: dri-devel@lists.freedesktop.org
> Cc: wei.c...@intel.com
> Cc: harish.krupo@intel.com
> Cc: Ville Syrjälä
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 9 +++
> drivers/gpu/drm/i915/intel_display.c | 46
> +++-
> 2 files changed, 44 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index fa2c226fc779..8b07dd05c54e 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -3092,6 +3092,15 @@ static int i915_display_info(struct seq_file *m, void
> *unused)
> intel_plane_info(m, crtc);
> }
>
> + if (INTEL_GEN(dev_priv) >= 9 && pipe_config->base.active) {
> + uint64_t background = pipe_config->base.bgcolor;
> +
> + seq_printf(m, "\tbackground color (10bpc): r=%x g=%x
> b=%x\n",
> +DRM_ARGB_RED(background, 10),
> +DRM_ARGB_GREEN(background, 10),
> +DRM_ARGB_BLUE(background, 10));
> + }
> +
> seq_printf(m, "\tunderrun reporting: cpu=%s pch=%s \n",
> yesno(!crtc->cpu_fifo_underrun_disabled),
> yesno(!crtc->pch_fifo_underrun_disabled));
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index a025efb1d7c6..bc78743e1411 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3896,6 +3896,28 @@ void intel_finish_reset(struct drm_i915_private
> *dev_priv)
> clear_bit(I915_RESET_MODESET, _priv->gpu_error.flags);
> }
>
> +static void
> +skl_update_background_color(const struct intel_crtc_state *crtc_state)
> +{
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + uint64_t propval = crtc_state->base.bgcolor;
> + uint32_t tmp;
> +
> + /* Hardware is programmed with 10 bits of precision */
> + tmp = DRM_ARGB_RED(propval, 10) << 20
> + | DRM_ARGB_GREEN(propval, 10) << 10
> + | DRM_ARGB_BLUE(propval, 10);
> +
> + /*
> + * Set CSC and gamma for bottom color to ensure background pixels
> + * receive the same color transformations as plane content.
> + */
> + tmp |= SKL_BOTTOM_COLOR_CSC_ENABLE | SKL_BOTTOM_COLOR_GAMMA_ENABLE;
> +
> + I915_WRITE(SKL_BOTTOM_COLOR(crtc->pipe), tmp);
> +}
Readout + state check would be nice too.
Anyways
Reviewed-by: Ville Syrjälä
> +
> static void intel_update_pipe_config(const struct intel_crtc_state
> *old_crtc_state,
>const struct intel_crtc_state
> *new_crtc_state)
> {
> @@ -3931,15 +3953,8 @@ static void intel_update_pipe_config(const struct
> intel_crtc_state *old_crtc_sta
> ironlake_pfit_disable(old_crtc_state);
> }
>
> - /*
> - * We don't (yet) allow userspace to control the pipe background color,
> - * so force it to black, but apply pipe gamma and CSC so that its
> - * handling will match how we program our planes.
> - */
> if (INTEL_GEN(dev_priv) >= 9)
> - I915_WRITE(SKL_BOTTOM_COLOR(crtc->pipe),
> -SKL_BOTTOM_COLOR_GAMMA_ENABLE |
> -SKL_BOTTOM_COLOR_CSC_ENABLE);
> + skl_update_background_color(new_crtc_state);
> }
>
> static void intel_fdi_normal_train(struct intel_crtc *crtc)
> @@ -11042,6 +11057,8 @@ static int intel_crtc_atomic_check(struct drm_crtc
> *crtc,
> struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> struct intel_crtc_state *pipe_config =
> to_intel_crtc_state(crtc_state);
> + struct drm_crtc_state *old_crtc_state =
> + drm_atomic_get_old_crtc_state(crtc_state->state, crtc);
> int ret;
> bool mode_changed = needs_modeset(crtc_state);
>
> @@ -11069,6 +11086,9 @@ static int intel_crtc_atomic_check(struct drm_crtc
> *crtc,
>
Re: [PATCH v4.1 2/3] drm: Add CRTC background color property (v4)
On Wed, Jan 30, 2019 at 10:51:21AM -0800, Matt Roper wrote:
> Some display controllers can be programmed to present non-black colors
> for pixels not covered by any plane (or pixels covered by the
> transparent regions of higher planes). Compositors that want a UI with
> a solid color background can potentially save memory bandwidth by
> setting the CRTC background property and using smaller planes to display
> the rest of the content.
>
> To avoid confusion between different ways of encoding RGB data, we
> define a standard 64-bit format that should be used for this property's
> value. Helper functions and macros are provided to generate and dissect
> values in this standard format with varying component precision values.
>
> v2:
> - Swap internal representation's blue and red bits to make it easier
>to read if printed out. (Ville)
> - Document bgcolor property in drm_blend.c. (Sean Paul)
> - s/background_color/bgcolor/ for consistency between property name and
>value storage field. (Sean Paul)
> - Add a convenience function to attach property to a given crtc.
>
> v3:
> - Restructure ARGB component extraction macros to be easier to
>understand and enclose the parameters in () to avoid calculations
>if expressions are passed. (Sean Paul)
> - s/rgba/argb/ in helper function/macro names. Even though the idea is
>to not worry about the internal representation of the u64, it can
>still be confusing to look at code that uses 'rgba' terminology, but
>stores values with argb ordering. (Ville)
>
> v4:
> - Drop the bgcolor_changed flag. (Ville, Brian Starkey)
> - Clarify in kerneldoc that background color is expected to undergo the
>same pipe-level degamma/csc/gamma transformations that planes do.
>(Brian Starkey)
> - Update kerneldoc to indicate non-opaque colors are allowed, but are
>generally only useful in special cases such as when writeback
>connectors are used (Brian Starkey / Eric Anholt)
>
> Cc: dri-devel@lists.freedesktop.org
> Cc: wei.c...@intel.com
> Cc: harish.krupo@intel.com
> Cc: Ville Syrjälä
> Cc: Sean Paul
> Cc: Brian Starkey
> Cc: Eric Anholt
> Cc: Stéphane Marchesin
> Cc: Daniel Vetter
> Signed-off-by: Matt Roper
> Reviewed-by(v2): Sean Paul
> Reviewed-by: Brian Starkey
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 4
> drivers/gpu/drm/drm_blend.c | 27 ---
> drivers/gpu/drm/drm_mode_config.c | 6 ++
> include/drm/drm_blend.h | 1 +
> include/drm/drm_crtc.h| 12
> include/drm/drm_mode_config.h | 5 +
> include/uapi/drm/drm_mode.h | 28
> 7 files changed, 80 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 9a1f41adfc67..d569e20e34e3 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -469,6 +469,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
> *crtc,
> return -EFAULT;
>
> set_out_fence_for_crtc(state->state, crtc, fence_ptr);
> + } else if (property == config->bgcolor_property) {
> + state->bgcolor = val;
> } else if (crtc->funcs->atomic_set_property) {
> return crtc->funcs->atomic_set_property(crtc, state, property,
> val);
> } else {
> @@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
> *val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
> else if (property == config->prop_out_fence_ptr)
> *val = 0;
> + else if (property == config->bgcolor_property)
> + *val = state->bgcolor;
> else if (crtc->funcs->atomic_get_property)
> return crtc->funcs->atomic_get_property(crtc, state, property,
> val);
> else
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index 0c78ca386cbe..d451ac9e1d6d 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -175,9 +175,22 @@
> *plane does not expose the "alpha" property, then this is
> *assumed to be 1.0
> *
> - * Note that all the property extensions described here apply either to the
> - * plane or the CRTC (e.g. for the background color, which currently is not
> - * exposed and assumed to be black).
> + * The property extensions described above all apply to the plane. Drivers
> + * may also expose the following crtc property extension:
> + *
> + * BACKGROUND_COLOR:
> + * Background color is setup with drm_crtc_add_bgcolor_property(). It
> + * controls the ARGB color of a full-screen layer that exists below all
> + * planes. This color will be used for pixels not covered by any plane
> + * and may also be blended with plane contents as allowed by a plane's
> + * alpha values. The background color defaults to black, and is assumed
> + * to be black for
Re: [PATCH 2/3] drm/doc: Drop chapter "KMS Initialization and Cleanup"
On Wed, Jan 30, 2019 at 05:33:00PM +, Kazlauskas, Nicholas wrote:
> On 1/30/19 11:30 AM, Daniel Vetter wrote:
> > It only talks about crtc, brings up intel as an exampel and I think is
>
> nit: Should be "example".
Will fix when applying.
> > more misleading than useful really. Plus we have lots of discussion
> > about how your standard kms driver should be initialized/cleaned up,
> > so maybe better to document this when we have a better idea.
> >
> > Signed-off-by: Daniel Vetter
> > ---
> > Documentation/gpu/drm-kms.rst | 96 ---
> > 1 file changed, 96 deletions(-)
> >
> > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> > index 75c882e09fee..23a3c986ef6d 100644
> > --- a/Documentation/gpu/drm-kms.rst
> > +++ b/Documentation/gpu/drm-kms.rst
> > @@ -410,102 +410,6 @@ Encoder Functions Reference
> > .. kernel-doc:: drivers/gpu/drm/drm_encoder.c
> > :export:
> >
> > -KMS Initialization and Cleanup
> > -==
> > -
> > -A KMS device is abstracted and exposed as a set of planes, CRTCs,
> > -encoders and connectors. KMS drivers must thus create and initialize all
> > -those objects at load time after initializing mode setting.
> > -
> > -CRTCs (:c:type:`struct drm_crtc `)
> > -
> > -
> > -A CRTC is an abstraction representing a part of the chip that contains a
> > -pointer to a scanout buffer. Therefore, the number of CRTCs available
> > -determines how many independent scanout buffers can be active at any
> > -given time. The CRTC structure contains several fields to support this:
> > -a pointer to some video memory (abstracted as a frame buffer object), a
> > -display mode, and an (x, y) offset into the video memory to support
> > -panning or configurations where one piece of video memory spans multiple
> > -CRTCs.
>
> This is mostly a duplicate of what's already in the CRTC abstraction
> section but it may be worth carrying over the bit about "the number of
> CRTCs available determining the number of independent scanout buffers
> that can be active at any given time".
Oh I didn't even read this. This is just plain wrong and probably predates
drm_plane (when it kinda was true-ish, if you'd ignore cursors). Now this
would map to number of drm_planes, except
- cursors can still be an exceptions
- yuv multi-planar might or might not be multiple planes per drm_plane.
Aka it's really complicated :-)
This is definitely much better explained in the kms overview section at
the top of:
https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#overview
Plus everything that's getting linked from there ofc.
> > -
> > -CRTC Initialization
> > -~~~
> > -
> > -A KMS device must create and register at least one struct
> > -:c:type:`struct drm_crtc ` instance. The instance is
> > -allocated and zeroed by the driver, possibly as part of a larger
> > -structure, and registered with a call to :c:func:`drm_crtc_init()`
> > -with a pointer to CRTC functions.
> > -
> > -
> > -Cleanup
> >
> > -
> > -The DRM core manages its objects' lifetime. When an object is not needed
> > -anymore the core calls its destroy function, which must clean up and
> > -free every resource allocated for the object. Every
> > -:c:func:`drm_\*_init()` call must be matched with a corresponding
> > -:c:func:`drm_\*_cleanup()` call to cleanup CRTCs
> > -(:c:func:`drm_crtc_cleanup()`), planes
> > -(:c:func:`drm_plane_cleanup()`), encoders
> > -(:c:func:`drm_encoder_cleanup()`) and connectors
> > -(:c:func:`drm_connector_cleanup()`). Furthermore, connectors that
> > -have been added to sysfs must be removed by a call to
> > -:c:func:`drm_connector_unregister()` before calling
> > -:c:func:`drm_connector_cleanup()`.
> > -
> > -Connectors state change detection must be cleanup up with a call to
> > -:c:func:`drm_kms_helper_poll_fini()`.
> > -
> > -Output discovery and initialization example
> >
> > -
> > -.. code-block:: c
> > -
> > -void intel_crt_init(struct drm_device *dev)
> > -{
> > -struct drm_connector *connector;
> > -struct intel_output *intel_output;
> > -
> > -intel_output = kzalloc(sizeof(struct intel_output), GFP_KERNEL);
> > -if (!intel_output)
> > -return;
> > -
> > -connector = _output->base;
> > -drm_connector_init(dev, _output->base,
> > - _crt_connector_funcs, DRM_MODE_CONNECTOR_VGA);
> > -
> > -drm_encoder_init(dev, _output->enc, _crt_enc_funcs,
> > - DRM_MODE_ENCODER_DAC);
> > -
> > -drm_connector_attach_encoder(_output->base,
> > - _output->enc);
> > -
> > -/* Set up the DDC bus. */
> > -intel_output->ddc_bus = intel_i2c_create(dev, GPIOA, "CRTDDC_A");
> > -if (!intel_output->ddc_bus) {
> > -dev_printk(KERN_ERR, >pdev->dev, "DDC bus
Re: [PATCH 2/3] drm/doc: Drop chapter "KMS Initialization and Cleanup"
On 1/30/19 4:02 PM, Daniel Vetter wrote:
> On Wed, Jan 30, 2019 at 05:33:00PM +, Kazlauskas, Nicholas wrote:
>> On 1/30/19 11:30 AM, Daniel Vetter wrote:
>>> It only talks about crtc, brings up intel as an exampel and I think is
>>
>> nit: Should be "example".
>
> Will fix when applying.
>
>>> more misleading than useful really. Plus we have lots of discussion
>>> about how your standard kms driver should be initialized/cleaned up,
>>> so maybe better to document this when we have a better idea.
>>>
>>> Signed-off-by: Daniel Vetter
>>> ---
>>>Documentation/gpu/drm-kms.rst | 96 ---
>>>1 file changed, 96 deletions(-)
>>>
>>> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
>>> index 75c882e09fee..23a3c986ef6d 100644
>>> --- a/Documentation/gpu/drm-kms.rst
>>> +++ b/Documentation/gpu/drm-kms.rst
>>> @@ -410,102 +410,6 @@ Encoder Functions Reference
>>>.. kernel-doc:: drivers/gpu/drm/drm_encoder.c
>>> :export:
>>>
>>> -KMS Initialization and Cleanup
>>> -==
>>> -
>>> -A KMS device is abstracted and exposed as a set of planes, CRTCs,
>>> -encoders and connectors. KMS drivers must thus create and initialize all
>>> -those objects at load time after initializing mode setting.
>>> -
>>> -CRTCs (:c:type:`struct drm_crtc `)
>>> -
>>> -
>>> -A CRTC is an abstraction representing a part of the chip that contains a
>>> -pointer to a scanout buffer. Therefore, the number of CRTCs available
>>> -determines how many independent scanout buffers can be active at any
>>> -given time. The CRTC structure contains several fields to support this:
>>> -a pointer to some video memory (abstracted as a frame buffer object), a
>>> -display mode, and an (x, y) offset into the video memory to support
>>> -panning or configurations where one piece of video memory spans multiple
>>> -CRTCs.
>>
>> This is mostly a duplicate of what's already in the CRTC abstraction
>> section but it may be worth carrying over the bit about "the number of
>> CRTCs available determining the number of independent scanout buffers
>> that can be active at any given time".
>
> Oh I didn't even read this. This is just plain wrong and probably predates
> drm_plane (when it kinda was true-ish, if you'd ignore cursors). Now this
> would map to number of drm_planes, except
> - cursors can still be an exceptions
> - yuv multi-planar might or might not be multiple planes per drm_plane.
>
> Aka it's really complicated :-)
>
> This is definitely much better explained in the kms overview section at
> the top of:
>
> https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#overview
>
> Plus everything that's getting linked from there ofc.
>
>>> -
>>> -CRTC Initialization
>>> -~~~
>>> -
>>> -A KMS device must create and register at least one struct
>>> -:c:type:`struct drm_crtc ` instance. The instance is
>>> -allocated and zeroed by the driver, possibly as part of a larger
>>> -structure, and registered with a call to :c:func:`drm_crtc_init()`
>>> -with a pointer to CRTC functions.
>>> -
>>> -
>>> -Cleanup
>>>
>>> -
>>> -The DRM core manages its objects' lifetime. When an object is not needed
>>> -anymore the core calls its destroy function, which must clean up and
>>> -free every resource allocated for the object. Every
>>> -:c:func:`drm_\*_init()` call must be matched with a corresponding
>>> -:c:func:`drm_\*_cleanup()` call to cleanup CRTCs
>>> -(:c:func:`drm_crtc_cleanup()`), planes
>>> -(:c:func:`drm_plane_cleanup()`), encoders
>>> -(:c:func:`drm_encoder_cleanup()`) and connectors
>>> -(:c:func:`drm_connector_cleanup()`). Furthermore, connectors that
>>> -have been added to sysfs must be removed by a call to
>>> -:c:func:`drm_connector_unregister()` before calling
>>> -:c:func:`drm_connector_cleanup()`.
>>> -
>>> -Connectors state change detection must be cleanup up with a call to
>>> -:c:func:`drm_kms_helper_poll_fini()`.
>>> -
>>> -Output discovery and initialization example
>>>
>>> -
>>> -.. code-block:: c
>>> -
>>> -void intel_crt_init(struct drm_device *dev)
>>> -{
>>> -struct drm_connector *connector;
>>> -struct intel_output *intel_output;
>>> -
>>> -intel_output = kzalloc(sizeof(struct intel_output), GFP_KERNEL);
>>> -if (!intel_output)
>>> -return;
>>> -
>>> -connector = _output->base;
>>> -drm_connector_init(dev, _output->base,
>>> - _crt_connector_funcs, DRM_MODE_CONNECTOR_VGA);
>>> -
>>> -drm_encoder_init(dev, _output->enc, _crt_enc_funcs,
>>> - DRM_MODE_ENCODER_DAC);
>>> -
>>> -drm_connector_attach_encoder(_output->base,
>>> - _output->enc);
>>> -
>>> -/* Set up the DDC bus. */
>>> -intel_output->ddc_bus = intel_i2c_create(dev, GPIOA, "CRTDDC_A");
>>> -if
Re: [PATCH v4.1 1/3] drm/i915: Force background color to black for gen9+ (v2)
On Wed, Jan 30, 2019 at 10:51:20AM -0800, Matt Roper wrote:
> We don't yet allow userspace to control the CRTC background color, but
> we should manually program the color to black to ensure the BIOS didn't
> leave us with some other color. We should also set the pipe gamma and
> pipe CSC bits so that the background color goes through the same color
> management transformations that a plane with black pixels would.
>
> v2: Rename register to SKL_BOTTOM_COLOR to more closely follow
> bspec naming. (Ville)
>
> Cc: Ville Syrjälä
> Signed-off-by: Matt Roper
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_reg.h | 6 ++
> drivers/gpu/drm/i915/intel_display.c | 19 +++
> 2 files changed, 25 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 03adcf3838de..a64deeb4e517 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5710,6 +5710,12 @@ enum {
> #define PIPEMISC_DITHER_TYPE_SP(0 << 2)
> #define PIPEMISC(pipe) _MMIO_PIPE2(pipe, _PIPE_MISC_A)
>
> +/* Skylake+ pipe bottom (background) color */
> +#define _SKL_BOTTOM_COLOR_A 0x70034
> +#define SKL_BOTTOM_COLOR_GAMMA_ENABLE (1 << 31)
> +#define SKL_BOTTOM_COLOR_CSC_ENABLE(1 << 30)
> +#define SKL_BOTTOM_COLOR(pipe) _MMIO_PIPE2(pipe,
> _SKL_BOTTOM_COLOR_A)
> +
> #define VLV_DPFLIPSTAT _MMIO(VLV_DISPLAY_BASE
> + 0x70028)
> #define PIPEB_LINE_COMPARE_INT_EN (1 << 29)
> #define PIPEB_HLINE_INT_EN (1 << 28)
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 539d8915b55f..a025efb1d7c6 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3930,6 +3930,16 @@ static void intel_update_pipe_config(const struct
> intel_crtc_state *old_crtc_sta
> else if (old_crtc_state->pch_pfit.enabled)
> ironlake_pfit_disable(old_crtc_state);
> }
> +
> + /*
> + * We don't (yet) allow userspace to control the pipe background color,
> + * so force it to black, but apply pipe gamma and CSC so that its
> + * handling will match how we program our planes.
> + */
> + if (INTEL_GEN(dev_priv) >= 9)
> + I915_WRITE(SKL_BOTTOM_COLOR(crtc->pipe),
> +SKL_BOTTOM_COLOR_GAMMA_ENABLE |
> +SKL_BOTTOM_COLOR_CSC_ENABLE);
> }
>
> static void intel_fdi_normal_train(struct intel_crtc *crtc)
> @@ -15488,6 +15498,15 @@ static void intel_sanitize_crtc(struct intel_crtc
> *crtc,
> plane->base.type != DRM_PLANE_TYPE_PRIMARY)
> intel_plane_disable_noatomic(crtc, plane);
> }
> +
> + /*
> + * Disable any background color set by the BIOS, but enable the
> + * gamma and CSC to match how we program our planes.
> + */
> + if (INTEL_GEN(dev_priv) >= 9)
> + I915_WRITE(SKL_BOTTOM_COLOR(crtc->pipe),
> +SKL_BOTTOM_COLOR_GAMMA_ENABLE |
> +SKL_BOTTOM_COLOR_CSC_ENABLE);
> }
>
> /* Adjust the state of the output pipe according to whether we
> --
> 2.14.5
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v4.1 0/3] CRTC background color
On Wed, Jan 30, 2019 at 10:56:26AM -0800, Matt Roper wrote: > On Wed, Jan 30, 2019 at 10:51:19AM -0800, Matt Roper wrote: > > Previous patch series was here: > > https://lists.freedesktop.org/archives/dri-devel/2018-December/201949.html > > > > I'm told the ChromeOS userspace code to make use of the background color > > has been reviewed and is ready for use: > > * https://chromium-review.googlesource.com/c/chromium/src/+/1278858 > > * https://chromium-review.googlesource.com/c/chromium/src/+/1278858 > > Woops, the second link here should have been to > > > https://chromium-review.googlesource.com/c/chromiumos/platform/drm-tests/+/1241436 > > which I believe is some unit tests to go along with the main userspace > code. Do we have this as igts too? -Daniel > > > Matt > > > > > So I think ABI-wise we've met the userspace consumer requirements to > > upstream this; we just need to get reviews on the two i915-specific > > patches and a clean CI report. > > > > v4.1 is identical to v4 aside from a rebase onto the latest drm-tip. > > > > > > Matt Roper (3): > > drm/i915: Force background color to black for gen9+ (v2) > > drm: Add CRTC background color property (v4) > > drm/i915/gen9+: Add support for pipe background color (v4) > > > > drivers/gpu/drm/drm_atomic_uapi.c| 4 > > drivers/gpu/drm/drm_blend.c | 27 +++--- > > drivers/gpu/drm/drm_mode_config.c| 6 + > > drivers/gpu/drm/i915/i915_debugfs.c | 9 > > drivers/gpu/drm/i915/i915_reg.h | 6 + > > drivers/gpu/drm/i915/intel_display.c | 43 > > > > include/drm/drm_blend.h | 1 + > > include/drm/drm_crtc.h | 12 ++ > > include/drm/drm_mode_config.h| 5 + > > include/uapi/drm/drm_mode.h | 28 +++ > > 10 files changed, 138 insertions(+), 3 deletions(-) > > > > -- > > 2.14.5 > > > > -- > Matt Roper > Graphics Software Engineer > IoTG Platform Enabling & Development > Intel Corporation > (916) 356-2795 > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On Wed, Jan 30, 2019 at 08:11:19PM +, Jason Gunthorpe wrote: > On Wed, Jan 30, 2019 at 01:00:02PM -0700, Logan Gunthorpe wrote: > > > We never changed SGLs. We still use them to pass p2pdma pages, only we > > need to be a bit careful where we send the entire SGL. I see no reason > > why we can't continue to be careful once their in userspace if there's > > something in GUP to deny them. > > > > It would be nice to have heterogeneous SGLs and it is something we > > should work toward but in practice they aren't really necessary at the > > moment. > > RDMA generally cannot cope well with an API that requires homogeneous > SGLs.. User space can construct complex MRs (particularly with the > proposed SGL MR flow) and we must marshal that into a single SGL or > the drivers fall apart. > > Jerome explained that GPU is worse, a single VMA may have a random mix > of CPU or device pages.. > > This is a pretty big blocker that would have to somehow be fixed. Note that HMM takes care of that RDMA ODP with my ODP to HMM patch, so what you get for an ODP umem is just a list of dma address you can program your device to. The aim is to avoid the driver to care about that. The access policy when the UMEM object is created by userspace through verbs API should however ascertain that for mmap of device file it is only creating a UMEM that is fully covered by one and only one vma. GPU device driver will have one vma per logical GPU object. I expect other kind of device do that same so that they can match a vma to a unique object in their driver. > > > That doesn't even necessarily need to be the case. For HMM, I > > understand, struct pages may not point to any accessible memory and the > > memory that backs it (or not) may change over the life time of it. So > > they don't have to be strictly tied to BARs addresses. p2pdma pages are > > strictly tied to BAR addresses though. > > No idea, but at least for this case I don't think we need magic HMM > pages to make simple VMA ops p2p_map/umap work.. Yes, you do not need page for simple driver, if we start creating struct page for all PCIE BAR we are gonna waste a lot of memory and resources for no good reason. I doubt all of the PCIE BAR of a device enabling p2p will ever be map as p2p. So simple driver do not need struct page, GPU driver that do not use HMM (all GPU that are more than 2 years old) do not need struct page. Struct page is a burden here more than anything else. I have not seen one good thing the struct page gives you. Cheers, Jérôme ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On Wed, Jan 30, 2019 at 12:52:44PM -0700, Logan Gunthorpe wrote: > > > On 2019-01-30 12:22 p.m., Jerome Glisse wrote: > > On Wed, Jan 30, 2019 at 06:56:59PM +, Jason Gunthorpe wrote: > >> On Wed, Jan 30, 2019 at 10:17:27AM -0700, Logan Gunthorpe wrote: > >>> > >>> > >>> On 2019-01-29 9:18 p.m., Jason Gunthorpe wrote: > Every attempt to give BAR memory to struct page has run into major > trouble, IMHO, so I like that this approach avoids that. > > And if you don't have struct page then the only kernel object left to > hang meta data off is the VMA itself. > > It seems very similar to the existing P2P work between in-kernel > consumers, just that VMA is now mediating a general user space driven > discovery process instead of being hard wired into a driver. > >>> > >>> But the kernel now has P2P bars backed by struct pages and it works > >>> well. > >> > >> I don't think it works that well.. > >> > >> We ended up with a 'sgl' that is not really a sgl, and doesn't work > >> with many of the common SGL patterns. sg_copy_buffer doesn't work, > >> dma_map, doesn't work, sg_page doesn't work quite right, etc. > >> > >> Only nvme and rdma got the special hacks to make them understand these > >> p2p-sgls, and I'm still not convinced some of the RDMA drivers that > >> want access to CPU addresses from the SGL (rxe, usnic, hfi, qib) don't > >> break in this scenario. > >> > >> Since the SGLs become broken, it pretty much means there is no path to > >> make GUP work generically, we have to go through and make everything > >> safe to use with p2p-sgls before allowing GUP. Which, frankly, sounds > >> impossible with all the competing objections. > >> > >> But GPU seems to have a problem unrelated to this - what Jerome wants > >> is to have two faulting domains for VMA's - visible-to-cpu and > >> visible-to-dma. The new op is essentially faulting the pages into the > >> visible-to-dma category and leaving them invisible-to-cpu. > >> > >> So that duality would still have to exists, and I think p2p_map/unmap > >> is a much simpler implementation than trying to create some kind of > >> special PTE in the VMA.. > >> > >> At least for RDMA, struct page or not doesn't really matter. > >> > >> We can make struct pages for the BAR the same way NVMe does. GPU is > >> probably the same, just with more mememory at stake? > >> > >> And maybe this should be the first implementation. The p2p_map VMA > >> operation should return a SGL and the caller should do the existing > >> pci_p2pdma_map_sg() flow.. > > > > For GPU it would not work, GPU might want to use main memory (because > > it is running out of BAR space) it is a lot easier if the p2p_map > > callback calls the right dma map function (for page or io) rather than > > having to define some format that would pass down the information. > > >> > >> Worry about optimizing away the struct page overhead later? > > > > Struct page do not fit well for GPU as the BAR address can be reprogram > > to point to any page inside the device memory (think 256M BAR versus > > 16GB device memory). Forcing struct page on GPU driver would require > > major surgery to the GPU driver inner working and there is no benefit > > to have from the struct page. So it is hard to justify this. > > I think we have to consider the struct pages to track the address space, > not what backs it (essentially what HMM is doing). If we need to add > operations for the driver to map the address space/struct pages back to > physical memory then do that. Creating a whole new idea that's tied to > userspace VMAs still seems wrong to me. VMA is the object RDMA works on, GPU driver have been working with VMA too, where VMA is tie to only one specific GPU object. So the most disrupting approach here is using struct page. It was never use and will not be use in many driver. Updating those to struct page is too risky and too much changes. The vma call back is something you can remove at any time if you have something better that do not need major surgery to GPU driver. Cheers, Jérôme ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202449] vrr_capable not showing up in xrandr with eDP display.
https://bugzilla.kernel.org/show_bug.cgi?id=202449 --- Comment #8 from Haxk20 (haxk...@gmail.com) --- Also is there any way i can test if variable refresh rate is working on linux right now ? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202449] vrr_capable not showing up in xrandr with eDP display.
https://bugzilla.kernel.org/show_bug.cgi?id=202449 --- Comment #7 from Haxk20 (haxk...@gmail.com) --- (In reply to Nicholas Kazlauskas from comment #5) > Created attachment 280873 [details] > 0001-drm-amd-display-Attach-VRR-properties-for-eDP-connec.patch > > I'm not sure if this will actually let you use variable refresh rate > features but this should attach the properties for your eDP panel at least. This fixes the issue. I know its too late for this to be sent into 5.0 but can you send this into drm-next-5.1-wip so that this makes it into 5.1 ? Thank you. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202449] vrr_capable not showing up in xrandr with eDP display.
https://bugzilla.kernel.org/show_bug.cgi?id=202449 --- Comment #6 from Haxk20 (haxk...@gmail.com) --- (In reply to Nicholas Kazlauskas from comment #5) > Created attachment 280873 [details] > 0001-drm-amd-display-Attach-VRR-properties-for-eDP-connec.patch > > I'm not sure if this will actually let you use variable refresh rate > features but this should attach the properties for your eDP panel at least. Gonna compile right now. I surely wont be able to use vrr still since i need to edit EDID to report a freesync range but at least eDP now has a way to enable it. Thank you. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] vmwgfx-fixes-5.0-190130
Hi, On 1/30/19 11:55 AM, Thomas Hellstrom wrote: Dave, Daniel A fix for a DMA API change from Christoph Hellwig for vmwgfx, and Two stable fixes for regressions in the vmwgfx driver The following changes since commit f0e7ce1eef5854584dfb59b3824a67edee37580f: Merge tag 'drm-msm-fixes-2019-01-24' of git://people.freedesktop.org/~robclark/linux into drm-fixes (2019-01-25 07:45:00 +1000) are available in the Git repository at: git://people.freedesktop.org/~thomash/linux tags/vmwgfx-fixes-5.0-190130 for you to fetch changes up to 46984feb928ade4af744eb4e4cc8b242ffaf14e3: drm/vmwgfx: Also check for crtc status while checking for DU active (2019-01-29 13:57:56 +0100) Please ignore this pull request. I got notified about an uninitialized variable warning which looks false, but since they typically aren't false I'd like to investigate further. In any case I don't want to introduce that warning message in a stable patch. Thanks, Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On Wed, Jan 30, 2019 at 06:56:59PM +, Jason Gunthorpe wrote: > On Wed, Jan 30, 2019 at 10:17:27AM -0700, Logan Gunthorpe wrote: > > > > > > On 2019-01-29 9:18 p.m., Jason Gunthorpe wrote: > > > Every attempt to give BAR memory to struct page has run into major > > > trouble, IMHO, so I like that this approach avoids that. > > > > > > And if you don't have struct page then the only kernel object left to > > > hang meta data off is the VMA itself. > > > > > > It seems very similar to the existing P2P work between in-kernel > > > consumers, just that VMA is now mediating a general user space driven > > > discovery process instead of being hard wired into a driver. > > > > But the kernel now has P2P bars backed by struct pages and it works > > well. > > I don't think it works that well.. > > We ended up with a 'sgl' that is not really a sgl, and doesn't work > with many of the common SGL patterns. sg_copy_buffer doesn't work, > dma_map, doesn't work, sg_page doesn't work quite right, etc. > > Only nvme and rdma got the special hacks to make them understand these > p2p-sgls, and I'm still not convinced some of the RDMA drivers that > want access to CPU addresses from the SGL (rxe, usnic, hfi, qib) don't > break in this scenario. > > Since the SGLs become broken, it pretty much means there is no path to > make GUP work generically, we have to go through and make everything > safe to use with p2p-sgls before allowing GUP. Which, frankly, sounds > impossible with all the competing objections. > > But GPU seems to have a problem unrelated to this - what Jerome wants > is to have two faulting domains for VMA's - visible-to-cpu and > visible-to-dma. The new op is essentially faulting the pages into the > visible-to-dma category and leaving them invisible-to-cpu. > > So that duality would still have to exists, and I think p2p_map/unmap > is a much simpler implementation than trying to create some kind of > special PTE in the VMA.. > > At least for RDMA, struct page or not doesn't really matter. > > We can make struct pages for the BAR the same way NVMe does. GPU is > probably the same, just with more mememory at stake? > > And maybe this should be the first implementation. The p2p_map VMA > operation should return a SGL and the caller should do the existing > pci_p2pdma_map_sg() flow.. For GPU it would not work, GPU might want to use main memory (because it is running out of BAR space) it is a lot easier if the p2p_map callback calls the right dma map function (for page or io) rather than having to define some format that would pass down the information. > > Worry about optimizing away the struct page overhead later? Struct page do not fit well for GPU as the BAR address can be reprogram to point to any page inside the device memory (think 256M BAR versus 16GB device memory). Forcing struct page on GPU driver would require major surgery to the GPU driver inner working and there is no benefit to have from the struct page. So it is hard to justify this. Cheers, Jérôme ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4.1 0/3] CRTC background color
On Wed, Jan 30, 2019 at 10:51:19AM -0800, Matt Roper wrote: > Previous patch series was here: > https://lists.freedesktop.org/archives/dri-devel/2018-December/201949.html > > I'm told the ChromeOS userspace code to make use of the background color > has been reviewed and is ready for use: > * https://chromium-review.googlesource.com/c/chromium/src/+/1278858 > * https://chromium-review.googlesource.com/c/chromium/src/+/1278858 Woops, the second link here should have been to https://chromium-review.googlesource.com/c/chromiumos/platform/drm-tests/+/1241436 which I believe is some unit tests to go along with the main userspace code. Matt > > So I think ABI-wise we've met the userspace consumer requirements to > upstream this; we just need to get reviews on the two i915-specific > patches and a clean CI report. > > v4.1 is identical to v4 aside from a rebase onto the latest drm-tip. > > > Matt Roper (3): > drm/i915: Force background color to black for gen9+ (v2) > drm: Add CRTC background color property (v4) > drm/i915/gen9+: Add support for pipe background color (v4) > > drivers/gpu/drm/drm_atomic_uapi.c| 4 > drivers/gpu/drm/drm_blend.c | 27 +++--- > drivers/gpu/drm/drm_mode_config.c| 6 + > drivers/gpu/drm/i915/i915_debugfs.c | 9 > drivers/gpu/drm/i915/i915_reg.h | 6 + > drivers/gpu/drm/i915/intel_display.c | 43 > > include/drm/drm_blend.h | 1 + > include/drm/drm_crtc.h | 12 ++ > include/drm/drm_mode_config.h| 5 + > include/uapi/drm/drm_mode.h | 28 +++ > 10 files changed, 138 insertions(+), 3 deletions(-) > > -- > 2.14.5 > -- Matt Roper Graphics Software Engineer IoTG Platform Enabling & Development Intel Corporation (916) 356-2795 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4.1 2/3] drm: Add CRTC background color property (v4)
Some display controllers can be programmed to present non-black colors
for pixels not covered by any plane (or pixels covered by the
transparent regions of higher planes). Compositors that want a UI with
a solid color background can potentially save memory bandwidth by
setting the CRTC background property and using smaller planes to display
the rest of the content.
To avoid confusion between different ways of encoding RGB data, we
define a standard 64-bit format that should be used for this property's
value. Helper functions and macros are provided to generate and dissect
values in this standard format with varying component precision values.
v2:
- Swap internal representation's blue and red bits to make it easier
to read if printed out. (Ville)
- Document bgcolor property in drm_blend.c. (Sean Paul)
- s/background_color/bgcolor/ for consistency between property name and
value storage field. (Sean Paul)
- Add a convenience function to attach property to a given crtc.
v3:
- Restructure ARGB component extraction macros to be easier to
understand and enclose the parameters in () to avoid calculations
if expressions are passed. (Sean Paul)
- s/rgba/argb/ in helper function/macro names. Even though the idea is
to not worry about the internal representation of the u64, it can
still be confusing to look at code that uses 'rgba' terminology, but
stores values with argb ordering. (Ville)
v4:
- Drop the bgcolor_changed flag. (Ville, Brian Starkey)
- Clarify in kerneldoc that background color is expected to undergo the
same pipe-level degamma/csc/gamma transformations that planes do.
(Brian Starkey)
- Update kerneldoc to indicate non-opaque colors are allowed, but are
generally only useful in special cases such as when writeback
connectors are used (Brian Starkey / Eric Anholt)
Cc: dri-devel@lists.freedesktop.org
Cc: wei.c...@intel.com
Cc: harish.krupo@intel.com
Cc: Ville Syrjälä
Cc: Sean Paul
Cc: Brian Starkey
Cc: Eric Anholt
Cc: Stéphane Marchesin
Cc: Daniel Vetter
Signed-off-by: Matt Roper
Reviewed-by(v2): Sean Paul
Reviewed-by: Brian Starkey
---
drivers/gpu/drm/drm_atomic_uapi.c | 4
drivers/gpu/drm/drm_blend.c | 27 ---
drivers/gpu/drm/drm_mode_config.c | 6 ++
include/drm/drm_blend.h | 1 +
include/drm/drm_crtc.h| 12
include/drm/drm_mode_config.h | 5 +
include/uapi/drm/drm_mode.h | 28
7 files changed, 80 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 9a1f41adfc67..d569e20e34e3 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -469,6 +469,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
*crtc,
return -EFAULT;
set_out_fence_for_crtc(state->state, crtc, fence_ptr);
+ } else if (property == config->bgcolor_property) {
+ state->bgcolor = val;
} else if (crtc->funcs->atomic_set_property) {
return crtc->funcs->atomic_set_property(crtc, state, property,
val);
} else {
@@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
else if (property == config->prop_out_fence_ptr)
*val = 0;
+ else if (property == config->bgcolor_property)
+ *val = state->bgcolor;
else if (crtc->funcs->atomic_get_property)
return crtc->funcs->atomic_get_property(crtc, state, property,
val);
else
diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index 0c78ca386cbe..d451ac9e1d6d 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -175,9 +175,22 @@
* plane does not expose the "alpha" property, then this is
* assumed to be 1.0
*
- * Note that all the property extensions described here apply either to the
- * plane or the CRTC (e.g. for the background color, which currently is not
- * exposed and assumed to be black).
+ * The property extensions described above all apply to the plane. Drivers
+ * may also expose the following crtc property extension:
+ *
+ * BACKGROUND_COLOR:
+ * Background color is setup with drm_crtc_add_bgcolor_property(). It
+ * controls the ARGB color of a full-screen layer that exists below all
+ * planes. This color will be used for pixels not covered by any plane
+ * and may also be blended with plane contents as allowed by a plane's
+ * alpha values. The background color defaults to black, and is assumed
+ * to be black for drivers that do not expose this property. Although
+ * background color isn't a plane, it is assumed that the color provided
+ * here undergoes the same pipe-level degamma/CSC/gamma transformations
+ * that planes
[PATCH v4.1 3/3] drm/i915/gen9+: Add support for pipe background color (v4)
Gen9+ platforms allow CRTC's to be programmed with a background/canvas
color below the programmable planes. Let's expose this for use by
compositors.
v2:
- Split out bgcolor sanitization and programming of csc/gamma bits to a
separate patch that we can land before the ABI changes are ready to
go in. (Ville)
- Change a temporary variable name to be more consistent with
other similar functions. (Ville)
- Change register name to SKL_CANVAS for consistency with the
CHV_CANVAS register.
v3:
- Switch register name back to SKL_BOTTOM_COLOR. (Ville)
- Use non-_FW register write. (Ville)
- Minor parameter rename for consistency. (Ville)
v4:
- Removed use of bgcolor_changed flag.
Cc: dri-devel@lists.freedesktop.org
Cc: wei.c...@intel.com
Cc: harish.krupo@intel.com
Cc: Ville Syrjälä
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_debugfs.c | 9 +++
drivers/gpu/drm/i915/intel_display.c | 46 +++-
2 files changed, 44 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index fa2c226fc779..8b07dd05c54e 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3092,6 +3092,15 @@ static int i915_display_info(struct seq_file *m, void
*unused)
intel_plane_info(m, crtc);
}
+ if (INTEL_GEN(dev_priv) >= 9 && pipe_config->base.active) {
+ uint64_t background = pipe_config->base.bgcolor;
+
+ seq_printf(m, "\tbackground color (10bpc): r=%x g=%x
b=%x\n",
+ DRM_ARGB_RED(background, 10),
+ DRM_ARGB_GREEN(background, 10),
+ DRM_ARGB_BLUE(background, 10));
+ }
+
seq_printf(m, "\tunderrun reporting: cpu=%s pch=%s \n",
yesno(!crtc->cpu_fifo_underrun_disabled),
yesno(!crtc->pch_fifo_underrun_disabled));
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a025efb1d7c6..bc78743e1411 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3896,6 +3896,28 @@ void intel_finish_reset(struct drm_i915_private
*dev_priv)
clear_bit(I915_RESET_MODESET, _priv->gpu_error.flags);
}
+static void
+skl_update_background_color(const struct intel_crtc_state *crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ uint64_t propval = crtc_state->base.bgcolor;
+ uint32_t tmp;
+
+ /* Hardware is programmed with 10 bits of precision */
+ tmp = DRM_ARGB_RED(propval, 10) << 20
+ | DRM_ARGB_GREEN(propval, 10) << 10
+ | DRM_ARGB_BLUE(propval, 10);
+
+ /*
+* Set CSC and gamma for bottom color to ensure background pixels
+* receive the same color transformations as plane content.
+*/
+ tmp |= SKL_BOTTOM_COLOR_CSC_ENABLE | SKL_BOTTOM_COLOR_GAMMA_ENABLE;
+
+ I915_WRITE(SKL_BOTTOM_COLOR(crtc->pipe), tmp);
+}
+
static void intel_update_pipe_config(const struct intel_crtc_state
*old_crtc_state,
const struct intel_crtc_state
*new_crtc_state)
{
@@ -3931,15 +3953,8 @@ static void intel_update_pipe_config(const struct
intel_crtc_state *old_crtc_sta
ironlake_pfit_disable(old_crtc_state);
}
- /*
-* We don't (yet) allow userspace to control the pipe background color,
-* so force it to black, but apply pipe gamma and CSC so that its
-* handling will match how we program our planes.
-*/
if (INTEL_GEN(dev_priv) >= 9)
- I915_WRITE(SKL_BOTTOM_COLOR(crtc->pipe),
- SKL_BOTTOM_COLOR_GAMMA_ENABLE |
- SKL_BOTTOM_COLOR_CSC_ENABLE);
+ skl_update_background_color(new_crtc_state);
}
static void intel_fdi_normal_train(struct intel_crtc *crtc)
@@ -11042,6 +11057,8 @@ static int intel_crtc_atomic_check(struct drm_crtc
*crtc,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_crtc_state *pipe_config =
to_intel_crtc_state(crtc_state);
+ struct drm_crtc_state *old_crtc_state =
+ drm_atomic_get_old_crtc_state(crtc_state->state, crtc);
int ret;
bool mode_changed = needs_modeset(crtc_state);
@@ -11069,6 +11086,9 @@ static int intel_crtc_atomic_check(struct drm_crtc
*crtc,
crtc_state->planes_changed = true;
}
+ if (crtc_state->bgcolor != old_crtc_state->bgcolor)
+ pipe_config->update_pipe = true;
+
ret = 0;
if (dev_priv->display.compute_pipe_wm) {
ret =
[PATCH v4.1 0/3] CRTC background color
Previous patch series was here: https://lists.freedesktop.org/archives/dri-devel/2018-December/201949.html I'm told the ChromeOS userspace code to make use of the background color has been reviewed and is ready for use: * https://chromium-review.googlesource.com/c/chromium/src/+/1278858 * https://chromium-review.googlesource.com/c/chromium/src/+/1278858 So I think ABI-wise we've met the userspace consumer requirements to upstream this; we just need to get reviews on the two i915-specific patches and a clean CI report. v4.1 is identical to v4 aside from a rebase onto the latest drm-tip. Matt Roper (3): drm/i915: Force background color to black for gen9+ (v2) drm: Add CRTC background color property (v4) drm/i915/gen9+: Add support for pipe background color (v4) drivers/gpu/drm/drm_atomic_uapi.c| 4 drivers/gpu/drm/drm_blend.c | 27 +++--- drivers/gpu/drm/drm_mode_config.c| 6 + drivers/gpu/drm/i915/i915_debugfs.c | 9 drivers/gpu/drm/i915/i915_reg.h | 6 + drivers/gpu/drm/i915/intel_display.c | 43 include/drm/drm_blend.h | 1 + include/drm/drm_crtc.h | 12 ++ include/drm/drm_mode_config.h| 5 + include/uapi/drm/drm_mode.h | 28 +++ 10 files changed, 138 insertions(+), 3 deletions(-) -- 2.14.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4.1 1/3] drm/i915: Force background color to black for gen9+ (v2)
We don't yet allow userspace to control the CRTC background color, but
we should manually program the color to black to ensure the BIOS didn't
leave us with some other color. We should also set the pipe gamma and
pipe CSC bits so that the background color goes through the same color
management transformations that a plane with black pixels would.
v2: Rename register to SKL_BOTTOM_COLOR to more closely follow
bspec naming. (Ville)
Cc: Ville Syrjälä
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_reg.h | 6 ++
drivers/gpu/drm/i915/intel_display.c | 19 +++
2 files changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 03adcf3838de..a64deeb4e517 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5710,6 +5710,12 @@ enum {
#define PIPEMISC_DITHER_TYPE_SP (0 << 2)
#define PIPEMISC(pipe) _MMIO_PIPE2(pipe, _PIPE_MISC_A)
+/* Skylake+ pipe bottom (background) color */
+#define _SKL_BOTTOM_COLOR_A0x70034
+#define SKL_BOTTOM_COLOR_GAMMA_ENABLE(1 << 31)
+#define SKL_BOTTOM_COLOR_CSC_ENABLE (1 << 30)
+#define SKL_BOTTOM_COLOR(pipe) _MMIO_PIPE2(pipe, _SKL_BOTTOM_COLOR_A)
+
#define VLV_DPFLIPSTAT _MMIO(VLV_DISPLAY_BASE +
0x70028)
#define PIPEB_LINE_COMPARE_INT_EN(1 << 29)
#define PIPEB_HLINE_INT_EN (1 << 28)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 539d8915b55f..a025efb1d7c6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3930,6 +3930,16 @@ static void intel_update_pipe_config(const struct
intel_crtc_state *old_crtc_sta
else if (old_crtc_state->pch_pfit.enabled)
ironlake_pfit_disable(old_crtc_state);
}
+
+ /*
+* We don't (yet) allow userspace to control the pipe background color,
+* so force it to black, but apply pipe gamma and CSC so that its
+* handling will match how we program our planes.
+*/
+ if (INTEL_GEN(dev_priv) >= 9)
+ I915_WRITE(SKL_BOTTOM_COLOR(crtc->pipe),
+ SKL_BOTTOM_COLOR_GAMMA_ENABLE |
+ SKL_BOTTOM_COLOR_CSC_ENABLE);
}
static void intel_fdi_normal_train(struct intel_crtc *crtc)
@@ -15488,6 +15498,15 @@ static void intel_sanitize_crtc(struct intel_crtc
*crtc,
plane->base.type != DRM_PLANE_TYPE_PRIMARY)
intel_plane_disable_noatomic(crtc, plane);
}
+
+ /*
+* Disable any background color set by the BIOS, but enable the
+* gamma and CSC to match how we program our planes.
+*/
+ if (INTEL_GEN(dev_priv) >= 9)
+ I915_WRITE(SKL_BOTTOM_COLOR(crtc->pipe),
+ SKL_BOTTOM_COLOR_GAMMA_ENABLE |
+ SKL_BOTTOM_COLOR_CSC_ENABLE);
}
/* Adjust the state of the output pipe according to whether we
--
2.14.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On Wed, Jan 30, 2019 at 11:13:11AM -0700, Logan Gunthorpe wrote: > > > On 2019-01-30 10:44 a.m., Jason Gunthorpe wrote: > > I don't see why a special case with a VMA is really that different. > > Well one *really* big difference is the VMA changes necessarily expose > specialized new functionality to userspace which has to be supported > forever and may be difficult to change. The p2pdma code is largely > in-kernel and we can rework and change the interfaces all we want as we > improve our struct page infrastructure. I do not see how VMA changes are any different than using struct page in respect to userspace exposure. Those vma callback do not need to be set by everyone, in fact expectation is that only handful of driver will set those. How can we do p2p between RDMA and GPU for instance, without exposure to userspace ? At some point you need to tell userspace hey this kernel does allow you to do that :) RDMA works on vma, and GPU driver can easily setup vma for an object hence why vma sounds like a logical place. In fact vma (mmap of a device file) is very common device driver pattern. In the model i am proposing the exporting device is in control of policy ie wether to allow or not the peer to peer mapping. So each device driver can define proper device specific API to enable and expose that feature to userspace. If they do, the only thing we have to preserve is the end result for the user. The userspace does not care one bit if we achieve this in the kernel with a set of new callback within the vm_operations struct or in some other way. Only the end result matter. So question is do we want to allow RDMA to access GPU driver object ? I believe we do, they are people using non upstream solution with open source driver to do just that, so it is a testimony that they are users for this. More use case have been propose too. > > I'd also argue that p2pdma isn't nearly as specialized as this VMA thing > and can be used pretty generically to do other things. Though, the other > ideas we've talked about doing are pretty far off and may have other > challenges. I believe p2p is highly specialize on non cache-coherent inter-connect platform like x86 with PCIE. So i do not think that using struct page for this is a good idea, it is not warranted/needed, and it can only be problematic if some random kernel code get holds of those struct page without understanding it is not regular memory. I believe the vma callback are the simplest solution with the minimum burden for the device driver and for the kernel. If they are any better solution that emerge there is nothing that would block us to remove this to replace it with the other solution. Cheers, Jérôme ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v6 04/28] drm/dp: DRM DP helper/macros to get DP sink DSC parameters
On Wed, Jan 30, 2019 at 01:06:57PM -0500, Sean Paul wrote:
> On Wed, Jan 30, 2019 at 12:06:45PM +0100, Daniel Vetter wrote:
> > On Wed, Dec 19, 2018 at 7:54 PM Daniel Vetter wrote:
> > >
> > > On Wed, Oct 24, 2018 at 03:28:16PM -0700, Manasi Navare wrote:
> > > > This patch adds inline functions and helpers for obtaining
> > > > DP sink's supported DSC parameters like DSC sink support,
> > > > eDP compressed BPP supported, maximum slice count supported
> > > > by the sink devices, DSC line buffer bit depth supported on DP sink,
> > > > DSC sink maximum color depth by parsing corresponding DPCD registers.
> > > >
> > > > v4:
> > > > * Add helper to give line buf bit depth (Manasi)
> > > > * Correct the bit masking in color depth helper (manasi)
> > > > v3:
> > > > * Use SLICE_CAP_2 for DP (Anusha)
> > > > v2:
> > > > * Add DSC sink support macro (Jani N)
> > > >
> > > > Cc: Gaurav K Singh
> > > > Cc: dri-devel@lists.freedesktop.org
> > > > Cc: Jani Nikula
> > > > Cc: Ville Syrjala
> > > > Cc: Anusha Srivatsa
> > > > Signed-off-by: Manasi Navare
> > > > Reviewed-by: Anusha Srivatsa
> > > > Reviewed-by: Gaurav K Singh
> > > > ---
> > > > drivers/gpu/drm/drm_dp_helper.c | 90 +
> > > > include/drm/drm_dp_helper.h | 30 +++
> > > > 2 files changed, 120 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > > > b/drivers/gpu/drm/drm_dp_helper.c
> > > > index 37c01b6076ec..6d483487f2b4 100644
> > > > --- a/drivers/gpu/drm/drm_dp_helper.c
> > > > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > > > @@ -1352,3 +1352,93 @@ int drm_dp_read_desc(struct drm_dp_aux *aux,
> > > > struct drm_dp_desc *desc,
> > > > return 0;
> > > > }
> > > > EXPORT_SYMBOL(drm_dp_read_desc);
> > > > +
> > > > +/**
> > > > + * DRM DP Helpers for DSC
> > > > + */
> > >
> > > This isn't really kerneldoc. Can you pls fix it, including all the other
> > > new exported functions?
> >
> > Ping. Still not fixed, and it's well over one month now. Would be nice
> > to get this sorted. I'd type the docs myself, but I don't really have
> > an idea about DSC.
> >
>
> Ha, this is good timing, I just stumbled over the following htmldocs warnings:
> ../drivers/gpu/drm/drm_dp_helper.c:1368: warning: Function parameter or
> member 'dsc_dpcd' not described in 'drm_dp_dsc_sink_max_slice_count'
> ../drivers/gpu/drm/drm_dp_helper.c:1368: warning: Function parameter or
> member 'is_edp' not described in 'drm_dp_dsc_sink_max_slice_count'
>
> I tried to add them, but there's a lot of dsc functions that need docs and I
> don't have the time/energy to document them properly.
>
> So, I'll echo Daniel's request.
>
> Sean
>
Thanks Sean, I will update the kernel doc for these dsc helpers in
drm_dp_helpers.c as well.
Regards
Manasi
> > Thanks, Daniel
> >
> > >
> > > Thanks, Daniel
> > >
> > > > +u8 drm_dp_dsc_sink_max_slice_count(const u8
> > > > dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
> > > > +bool is_edp)
> > > > +{
> > > > + u8 slice_cap1 = dsc_dpcd[DP_DSC_SLICE_CAP_1 - DP_DSC_SUPPORT];
> > > > +
> > > > + if (is_edp) {
> > > > + /* For eDP, register DSC_SLICE_CAPABILITIES_1 gives slice
> > > > count */
> > > > + if (slice_cap1 & DP_DSC_4_PER_DP_DSC_SINK)
> > > > + return 4;
> > > > + if (slice_cap1 & DP_DSC_2_PER_DP_DSC_SINK)
> > > > + return 2;
> > > > + if (slice_cap1 & DP_DSC_1_PER_DP_DSC_SINK)
> > > > + return 1;
> > > > + } else {
> > > > + /* For DP, use values from DSC_SLICE_CAP_1 and
> > > > DSC_SLICE_CAP2 */
> > > > + u8 slice_cap2 = dsc_dpcd[DP_DSC_SLICE_CAP_2 -
> > > > DP_DSC_SUPPORT];
> > > > +
> > > > + if (slice_cap2 & DP_DSC_24_PER_DP_DSC_SINK)
> > > > + return 24;
> > > > + if (slice_cap2 & DP_DSC_20_PER_DP_DSC_SINK)
> > > > + return 20;
> > > > + if (slice_cap2 & DP_DSC_16_PER_DP_DSC_SINK)
> > > > + return 16;
> > > > + if (slice_cap1 & DP_DSC_12_PER_DP_DSC_SINK)
> > > > + return 12;
> > > > + if (slice_cap1 & DP_DSC_10_PER_DP_DSC_SINK)
> > > > + return 10;
> > > > + if (slice_cap1 & DP_DSC_8_PER_DP_DSC_SINK)
> > > > + return 8;
> > > > + if (slice_cap1 & DP_DSC_6_PER_DP_DSC_SINK)
> > > > + return 6;
> > > > + if (slice_cap1 & DP_DSC_4_PER_DP_DSC_SINK)
> > > > + return 4;
> > > > + if (slice_cap1 & DP_DSC_2_PER_DP_DSC_SINK)
> > > > + return 2;
> > > > + if (slice_cap1 & DP_DSC_1_PER_DP_DSC_SINK)
> > > > + return 1;
> > > > + }
> > > > +
> > > > + return 0;
> > > > +}
> > > > +EXPORT_SYMBOL(drm_dp_dsc_sink_max_slice_count);
> > > > +
> > > > +u8
Re: [Intel-gfx] [PATCH v6 04/28] drm/dp: DRM DP helper/macros to get DP sink DSC parameters
On Wed, Jan 30, 2019 at 12:06:45PM +0100, Daniel Vetter wrote:
> On Wed, Dec 19, 2018 at 7:54 PM Daniel Vetter wrote:
> >
> > On Wed, Oct 24, 2018 at 03:28:16PM -0700, Manasi Navare wrote:
> > > This patch adds inline functions and helpers for obtaining
> > > DP sink's supported DSC parameters like DSC sink support,
> > > eDP compressed BPP supported, maximum slice count supported
> > > by the sink devices, DSC line buffer bit depth supported on DP sink,
> > > DSC sink maximum color depth by parsing corresponding DPCD registers.
> > >
> > > v4:
> > > * Add helper to give line buf bit depth (Manasi)
> > > * Correct the bit masking in color depth helper (manasi)
> > > v3:
> > > * Use SLICE_CAP_2 for DP (Anusha)
> > > v2:
> > > * Add DSC sink support macro (Jani N)
> > >
> > > Cc: Gaurav K Singh
> > > Cc: dri-devel@lists.freedesktop.org
> > > Cc: Jani Nikula
> > > Cc: Ville Syrjala
> > > Cc: Anusha Srivatsa
> > > Signed-off-by: Manasi Navare
> > > Reviewed-by: Anusha Srivatsa
> > > Reviewed-by: Gaurav K Singh
> > > ---
> > > drivers/gpu/drm/drm_dp_helper.c | 90 +
> > > include/drm/drm_dp_helper.h | 30 +++
> > > 2 files changed, 120 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > > b/drivers/gpu/drm/drm_dp_helper.c
> > > index 37c01b6076ec..6d483487f2b4 100644
> > > --- a/drivers/gpu/drm/drm_dp_helper.c
> > > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > > @@ -1352,3 +1352,93 @@ int drm_dp_read_desc(struct drm_dp_aux *aux,
> > > struct drm_dp_desc *desc,
> > > return 0;
> > > }
> > > EXPORT_SYMBOL(drm_dp_read_desc);
> > > +
> > > +/**
> > > + * DRM DP Helpers for DSC
> > > + */
> >
> > This isn't really kerneldoc. Can you pls fix it, including all the other
> > new exported functions?
>
> Ping. Still not fixed, and it's well over one month now. Would be nice
> to get this sorted. I'd type the docs myself, but I don't really have
> an idea about DSC.
>
> Thanks, Daniel
>
Thanks Daniel for pointing this out. Yes I will add the description for the DSC
kernel doc
for each of these helper functions. On it, thanks again and sorry for the delay.
Regards
Manasi
> >
> > Thanks, Daniel
> >
> > > +u8 drm_dp_dsc_sink_max_slice_count(const u8
> > > dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
> > > +bool is_edp)
> > > +{
> > > + u8 slice_cap1 = dsc_dpcd[DP_DSC_SLICE_CAP_1 - DP_DSC_SUPPORT];
> > > +
> > > + if (is_edp) {
> > > + /* For eDP, register DSC_SLICE_CAPABILITIES_1 gives slice
> > > count */
> > > + if (slice_cap1 & DP_DSC_4_PER_DP_DSC_SINK)
> > > + return 4;
> > > + if (slice_cap1 & DP_DSC_2_PER_DP_DSC_SINK)
> > > + return 2;
> > > + if (slice_cap1 & DP_DSC_1_PER_DP_DSC_SINK)
> > > + return 1;
> > > + } else {
> > > + /* For DP, use values from DSC_SLICE_CAP_1 and
> > > DSC_SLICE_CAP2 */
> > > + u8 slice_cap2 = dsc_dpcd[DP_DSC_SLICE_CAP_2 -
> > > DP_DSC_SUPPORT];
> > > +
> > > + if (slice_cap2 & DP_DSC_24_PER_DP_DSC_SINK)
> > > + return 24;
> > > + if (slice_cap2 & DP_DSC_20_PER_DP_DSC_SINK)
> > > + return 20;
> > > + if (slice_cap2 & DP_DSC_16_PER_DP_DSC_SINK)
> > > + return 16;
> > > + if (slice_cap1 & DP_DSC_12_PER_DP_DSC_SINK)
> > > + return 12;
> > > + if (slice_cap1 & DP_DSC_10_PER_DP_DSC_SINK)
> > > + return 10;
> > > + if (slice_cap1 & DP_DSC_8_PER_DP_DSC_SINK)
> > > + return 8;
> > > + if (slice_cap1 & DP_DSC_6_PER_DP_DSC_SINK)
> > > + return 6;
> > > + if (slice_cap1 & DP_DSC_4_PER_DP_DSC_SINK)
> > > + return 4;
> > > + if (slice_cap1 & DP_DSC_2_PER_DP_DSC_SINK)
> > > + return 2;
> > > + if (slice_cap1 & DP_DSC_1_PER_DP_DSC_SINK)
> > > + return 1;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +EXPORT_SYMBOL(drm_dp_dsc_sink_max_slice_count);
> > > +
> > > +u8 drm_dp_dsc_sink_line_buf_depth(const u8
> > > dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
> > > +{
> > > + u8 line_buf_depth = dsc_dpcd[DP_DSC_LINE_BUF_BIT_DEPTH -
> > > DP_DSC_SUPPORT];
> > > +
> > > + switch (line_buf_depth & DP_DSC_LINE_BUF_BIT_DEPTH_MASK) {
> > > + case DP_DSC_LINE_BUF_BIT_DEPTH_9:
> > > + return 9;
> > > + case DP_DSC_LINE_BUF_BIT_DEPTH_10:
> > > + return 10;
> > > + case DP_DSC_LINE_BUF_BIT_DEPTH_11:
> > > + return 11;
> > > + case DP_DSC_LINE_BUF_BIT_DEPTH_12:
> > > + return 12;
> > > + case DP_DSC_LINE_BUF_BIT_DEPTH_13:
> > > + return 13;
> > > + case DP_DSC_LINE_BUF_BIT_DEPTH_14:
> > > + return 14;
> > > + case
Re: [PATCH 5/5] drm/i2c: tda998x: improve correctness of quantisation range
On Wed, Jan 30, 2019 at 03:53:04PM +, Brian Starkey wrote:
> Hi Russell,
>
> On Fri, Jan 25, 2019 at 09:43:29AM +, Russell King wrote:
> > CEA-861 says: "A Source shall not send a non-zero Q value that does
> > not correspond to the default RGB Quantization Range for the
> > transmitted Picture unless the Sink indicates support for the Q bit
> > in a Video Capabilities Data Block."
> >
> > Make TDA998x compliant by using the helper to set the quantisation
> > range in the infoframe, and using the TDA998x's colour scaling to
> > appropriately adjust the RGB values sent to the monitor.
> >
> > This ensures that monitors that do not support the Q bit are sent
> > RGB values that are within the expected range. Monitors with
> > support for the Q bit will be sent full-range RGB.
> >
> > Signed-off-by: Russell King
> > ---
> > drivers/gpu/drm/i2c/tda998x_drv.c | 39
> > ++-
> > 1 file changed, 34 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
> > b/drivers/gpu/drm/i2c/tda998x_drv.c
> > index b0ed2ef49c62..7d9aea79aff2 100644
> > --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> > +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> > @@ -50,6 +50,8 @@ struct tda998x_priv {
> > bool is_on;
> > bool supports_infoframes;
> > bool sink_has_audio;
> > + bool has_rgb_quant;
> > + enum hdmi_quantization_range rgb_quant_range;
> > u8 vip_cntrl_0;
> > u8 vip_cntrl_1;
> > u8 vip_cntrl_2;
> > @@ -869,7 +871,9 @@ tda998x_write_avi(struct tda998x_priv *priv, const
> > struct drm_display_mode *mode
> >
> > drm_hdmi_avi_infoframe_from_display_mode(,
> > >connector, mode);
> > - frame.avi.quantization_range = HDMI_QUANTIZATION_RANGE_FULL;
> > + drm_hdmi_avi_infoframe_quant_range(, mode,
> > + priv->rgb_quant_range,
> > + priv->has_rgb_quant, false);
> >
> > tda998x_write_if(priv, DIP_IF_FLAGS_IF2, REG_IF2_HB0, );
> > }
> > @@ -1259,6 +1263,7 @@ static int tda998x_connector_get_modes(struct
> > drm_connector *connector)
> > mutex_lock(>audio_mutex);
> > n = drm_add_edid_modes(connector, edid);
> > priv->sink_has_audio = drm_detect_monitor_audio(edid);
> > + priv->has_rgb_quant = drm_rgb_quant_range_selectable(edid);
> > mutex_unlock(>audio_mutex);
> >
> > kfree(edid);
> > @@ -1385,6 +1390,15 @@ static void tda998x_bridge_mode_set(struct
> > drm_bridge *bridge,
> > u8 reg, div, rep, sel_clk;
> >
> > /*
> > +* Since we are "computer" like, our source invariably produces
> > +* full-range RGB. If the monitor supports full-range, then use
> > +* it, otherwise reduce to limited-range.
> > +*/
> > + priv->rgb_quant_range = priv->has_rgb_quant ?
> > + HDMI_QUANTIZATION_RANGE_FULL :
> > + drm_default_rgb_quant_range(adjusted_mode);
> > +
> > + /*
> > * Internally TDA998x is using ITU-R BT.656 style sync but
> > * we get VESA style sync. TDA998x is using a reference pixel
> > * relative to ITU to sync to the input frame and for output
> > @@ -1499,10 +1513,25 @@ static void tda998x_bridge_mode_set(struct
> > drm_bridge *bridge,
> > reg_write(priv, REG_PLL_SERIAL_2, PLL_SERIAL_2_SRL_NOSC(div) |
> > PLL_SERIAL_2_SRL_PR(rep));
> >
> > - /* set color matrix bypass flag: */
> > - reg_write(priv, REG_MAT_CONTRL, MAT_CONTRL_MAT_BP |
> > - MAT_CONTRL_MAT_SC(1));
> > - reg_set(priv, REG_FEAT_POWERDOWN, FEAT_POWERDOWN_CSC);
> > + /* set color matrix according to output rgb quant range */
> > + if (priv->rgb_quant_range == HDMI_QUANTIZATION_RANGE_LIMITED) {
> > + static u8 tda998x_full_to_limited_range[] = {
> > + MAT_CONTRL_MAT_SC(2),
> > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > + 0x03, 0x6f, 0x00, 0x00, 0x00, 0x00,
> > + 0x00, 0x00, 0x03, 0x6f, 0x00, 0x00,
> > + 0x00, 0x00, 0x00, 0x00, 0x03, 0x6f,
> > + 0x00, 0x40, 0x00, 0x40, 0x00, 0x40
> > + };
>
> I couldn't figure out from the datasheet I have what the expected data
> bit-depth is here, but I assume from this offset that it's 12-bit?
No, the data sheet makes it clear that (eg) MAT_OI1_MSB contains
OFFSET_IN1[10:8] and MAT_OI1_LSB contains OFFSET_IN1[7:0] - so that's
11 bits of offset - which looks like from the information I have that
it's twos complement. Similar applies to the output offsets.
The above is the list of register values starting at MAT_CONTRL (0x80),
with the input offsets in the first line, then the G/Y output
coefficients, R/CR coefficients, B/CB coefficients and finally the
output offsets on the last line.
Each line is a pair of MSB, LSB values, starting at G/Y input, R/CR
input, B/CB input.
The above is equivalent to:
GY_OUT = (GY_IN + 0) * 0x36f / 0x400
Re: [Intel-gfx] [PATCH v6 04/28] drm/dp: DRM DP helper/macros to get DP sink DSC parameters
On Wed, Jan 30, 2019 at 12:06:45PM +0100, Daniel Vetter wrote:
> On Wed, Dec 19, 2018 at 7:54 PM Daniel Vetter wrote:
> >
> > On Wed, Oct 24, 2018 at 03:28:16PM -0700, Manasi Navare wrote:
> > > This patch adds inline functions and helpers for obtaining
> > > DP sink's supported DSC parameters like DSC sink support,
> > > eDP compressed BPP supported, maximum slice count supported
> > > by the sink devices, DSC line buffer bit depth supported on DP sink,
> > > DSC sink maximum color depth by parsing corresponding DPCD registers.
> > >
> > > v4:
> > > * Add helper to give line buf bit depth (Manasi)
> > > * Correct the bit masking in color depth helper (manasi)
> > > v3:
> > > * Use SLICE_CAP_2 for DP (Anusha)
> > > v2:
> > > * Add DSC sink support macro (Jani N)
> > >
> > > Cc: Gaurav K Singh
> > > Cc: dri-devel@lists.freedesktop.org
> > > Cc: Jani Nikula
> > > Cc: Ville Syrjala
> > > Cc: Anusha Srivatsa
> > > Signed-off-by: Manasi Navare
> > > Reviewed-by: Anusha Srivatsa
> > > Reviewed-by: Gaurav K Singh
> > > ---
> > > drivers/gpu/drm/drm_dp_helper.c | 90 +
> > > include/drm/drm_dp_helper.h | 30 +++
> > > 2 files changed, 120 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > > b/drivers/gpu/drm/drm_dp_helper.c
> > > index 37c01b6076ec..6d483487f2b4 100644
> > > --- a/drivers/gpu/drm/drm_dp_helper.c
> > > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > > @@ -1352,3 +1352,93 @@ int drm_dp_read_desc(struct drm_dp_aux *aux,
> > > struct drm_dp_desc *desc,
> > > return 0;
> > > }
> > > EXPORT_SYMBOL(drm_dp_read_desc);
> > > +
> > > +/**
> > > + * DRM DP Helpers for DSC
> > > + */
> >
> > This isn't really kerneldoc. Can you pls fix it, including all the other
> > new exported functions?
>
> Ping. Still not fixed, and it's well over one month now. Would be nice
> to get this sorted. I'd type the docs myself, but I don't really have
> an idea about DSC.
>
Ha, this is good timing, I just stumbled over the following htmldocs warnings:
../drivers/gpu/drm/drm_dp_helper.c:1368: warning: Function parameter or member
'dsc_dpcd' not described in 'drm_dp_dsc_sink_max_slice_count'
../drivers/gpu/drm/drm_dp_helper.c:1368: warning: Function parameter or member
'is_edp' not described in 'drm_dp_dsc_sink_max_slice_count'
I tried to add them, but there's a lot of dsc functions that need docs and I
don't have the time/energy to document them properly.
So, I'll echo Daniel's request.
Sean
> Thanks, Daniel
>
> >
> > Thanks, Daniel
> >
> > > +u8 drm_dp_dsc_sink_max_slice_count(const u8
> > > dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
> > > +bool is_edp)
> > > +{
> > > + u8 slice_cap1 = dsc_dpcd[DP_DSC_SLICE_CAP_1 - DP_DSC_SUPPORT];
> > > +
> > > + if (is_edp) {
> > > + /* For eDP, register DSC_SLICE_CAPABILITIES_1 gives slice
> > > count */
> > > + if (slice_cap1 & DP_DSC_4_PER_DP_DSC_SINK)
> > > + return 4;
> > > + if (slice_cap1 & DP_DSC_2_PER_DP_DSC_SINK)
> > > + return 2;
> > > + if (slice_cap1 & DP_DSC_1_PER_DP_DSC_SINK)
> > > + return 1;
> > > + } else {
> > > + /* For DP, use values from DSC_SLICE_CAP_1 and
> > > DSC_SLICE_CAP2 */
> > > + u8 slice_cap2 = dsc_dpcd[DP_DSC_SLICE_CAP_2 -
> > > DP_DSC_SUPPORT];
> > > +
> > > + if (slice_cap2 & DP_DSC_24_PER_DP_DSC_SINK)
> > > + return 24;
> > > + if (slice_cap2 & DP_DSC_20_PER_DP_DSC_SINK)
> > > + return 20;
> > > + if (slice_cap2 & DP_DSC_16_PER_DP_DSC_SINK)
> > > + return 16;
> > > + if (slice_cap1 & DP_DSC_12_PER_DP_DSC_SINK)
> > > + return 12;
> > > + if (slice_cap1 & DP_DSC_10_PER_DP_DSC_SINK)
> > > + return 10;
> > > + if (slice_cap1 & DP_DSC_8_PER_DP_DSC_SINK)
> > > + return 8;
> > > + if (slice_cap1 & DP_DSC_6_PER_DP_DSC_SINK)
> > > + return 6;
> > > + if (slice_cap1 & DP_DSC_4_PER_DP_DSC_SINK)
> > > + return 4;
> > > + if (slice_cap1 & DP_DSC_2_PER_DP_DSC_SINK)
> > > + return 2;
> > > + if (slice_cap1 & DP_DSC_1_PER_DP_DSC_SINK)
> > > + return 1;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +EXPORT_SYMBOL(drm_dp_dsc_sink_max_slice_count);
> > > +
> > > +u8 drm_dp_dsc_sink_line_buf_depth(const u8
> > > dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
> > > +{
> > > + u8 line_buf_depth = dsc_dpcd[DP_DSC_LINE_BUF_BIT_DEPTH -
> > > DP_DSC_SUPPORT];
> > > +
> > > + switch (line_buf_depth & DP_DSC_LINE_BUF_BIT_DEPTH_MASK) {
> > > + case DP_DSC_LINE_BUF_BIT_DEPTH_9:
> > > + return 9;
> > > + case DP_DSC_LINE_BUF_BIT_DEPTH_10:
> > > + return 10;
> > > +
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On Wed, Jan 30, 2019 at 06:26:53PM +0100, Christoph Hellwig wrote: > On Wed, Jan 30, 2019 at 10:55:43AM -0500, Jerome Glisse wrote: > > Even outside GPU driver, device driver like RDMA just want to share their > > doorbell to other device and they do not want to see those doorbell page > > use in direct I/O or anything similar AFAICT. > > At least Mellanox HCA support and inline data feature where you > can copy data directly into the BAR. For something like a usrspace > NVMe target it might be very useful to do direct I/O straight into > the BAR for that. And what i am proposing is not exclusive of that. If exporting device wants to have struct page for its BAR than it can do so. What i do not want is imposing that burden on everyone as many devices do not want or do not care for that. Moreover having struct page and allowing that struct page to trickle know in obscure corner of the kernel means that exporter that want that will also have the burden to check that what they are doing does not end up in something terribly bad. While i would like a one API fits all i do not think that we can sanely do that for P2P. They are too much differences between how different devices expose and manage their BAR to make any such attempt reasonably sane. Maybe thing will evolve oragnicaly, but for now i do not see a way out side the API i am proposing (again this is not exclusive of the struct page API that is upstream both can co-exist and a device can use both or just one). Cheers, Jérôme ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] drm/i2c: tda998x: add support for writing SPD
On Wed, Jan 30, 2019 at 05:23:40PM +, Russell King - ARM Linux admin wrote:
> On Wed, Jan 30, 2019 at 03:41:04PM +, Brian Starkey wrote:
> > Hi Russell,
> >
> > These did eventually reach me on Saturday evening.
> >
> > On Fri, Jan 25, 2019 at 09:43:19AM +, Russell King wrote:
> > > Add support for writing the SPD infoframe to the TDA998x. Identify us
> > > as "Generic" vendor "PC" product, and as "PC general" source device
> > > information.
> > >
> > > Signed-off-by: Russell King
> > > ---
> >
> > As this infoframe is optional, and is intended to provide a "useful"
> > name to the user, I wonder if there's really much value in just
> > sending "Generic"/"PC"? It seems that it might be better to just not
> > send the SPD infoframe until we have a way to put something more
> > useful there (e.g. specified by the host driver).
>
> It's along the lines of what other drivers do - are you suggesting
> that other drivers should not send the SPD infoframe either?
>
> E.g.
>
> static void vc4_hdmi_set_spd_infoframe(struct drm_encoder *encoder)
> {
> union hdmi_infoframe frame;
> int ret;
>
> ret = hdmi_spd_infoframe_init(, "Broadcom", "Videocore");
> ===
> mtk_hdmi_setup_spd_infoframe(hdmi, "mediatek", "On-chip HDMI");
> ===
> ret = hdmi_spd_infoframe_init(, "Intel", "Integrated gfx");
>
> None of these convey a "useful" name to the user, unless the user
> knows what is inside their device - eg, "it's a mediatek SoC" or
> "it's a Broadcom SoC".
I grepped the same, but I came to a different conclusion. From
"Broadcom", "mediatek" and "Intel" I can identify a device, if I know
it contains one of those components. From "Generic"/"PC" I can't tell
anything at all.
>
> I could send instead "Philips" "TDA998x" which would be on-par with
> these strings.
>
I don't agree that it would be "on-par", but IMO it would be an
improvement over "Generic"/"PC". The strings above describe the "host"
driver/device, rather than the transmitter per-se. I think it's fair
to say a user is more likely to know what SoC their device contains
than which HDMI transmitter is connected to that SoC.
> Maybe there should be a way to set these from DT and/or userspace?
DT is a nice idea. Maybe Product from /model and Vendor from
/compatible (though how you turn a DT compatible into a human-readable
vendor could be fun).
That sounds like something which shouldn't be local to tda998x,
though.
Thanks,
-Brian
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/doc: Drop chapter "KMS Initialization and Cleanup"
On 1/30/19 11:30 AM, Daniel Vetter wrote:
> It only talks about crtc, brings up intel as an exampel and I think is
nit: Should be "example".
> more misleading than useful really. Plus we have lots of discussion
> about how your standard kms driver should be initialized/cleaned up,
> so maybe better to document this when we have a better idea.
>
> Signed-off-by: Daniel Vetter
> ---
> Documentation/gpu/drm-kms.rst | 96 ---
> 1 file changed, 96 deletions(-)
>
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 75c882e09fee..23a3c986ef6d 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -410,102 +410,6 @@ Encoder Functions Reference
> .. kernel-doc:: drivers/gpu/drm/drm_encoder.c
> :export:
>
> -KMS Initialization and Cleanup
> -==
> -
> -A KMS device is abstracted and exposed as a set of planes, CRTCs,
> -encoders and connectors. KMS drivers must thus create and initialize all
> -those objects at load time after initializing mode setting.
> -
> -CRTCs (:c:type:`struct drm_crtc `)
> -
> -
> -A CRTC is an abstraction representing a part of the chip that contains a
> -pointer to a scanout buffer. Therefore, the number of CRTCs available
> -determines how many independent scanout buffers can be active at any
> -given time. The CRTC structure contains several fields to support this:
> -a pointer to some video memory (abstracted as a frame buffer object), a
> -display mode, and an (x, y) offset into the video memory to support
> -panning or configurations where one piece of video memory spans multiple
> -CRTCs.
This is mostly a duplicate of what's already in the CRTC abstraction
section but it may be worth carrying over the bit about "the number of
CRTCs available determining the number of independent scanout buffers
that can be active at any given time".
> -
> -CRTC Initialization
> -~~~
> -
> -A KMS device must create and register at least one struct
> -:c:type:`struct drm_crtc ` instance. The instance is
> -allocated and zeroed by the driver, possibly as part of a larger
> -structure, and registered with a call to :c:func:`drm_crtc_init()`
> -with a pointer to CRTC functions.
> -
> -
> -Cleanup
>
> -
> -The DRM core manages its objects' lifetime. When an object is not needed
> -anymore the core calls its destroy function, which must clean up and
> -free every resource allocated for the object. Every
> -:c:func:`drm_\*_init()` call must be matched with a corresponding
> -:c:func:`drm_\*_cleanup()` call to cleanup CRTCs
> -(:c:func:`drm_crtc_cleanup()`), planes
> -(:c:func:`drm_plane_cleanup()`), encoders
> -(:c:func:`drm_encoder_cleanup()`) and connectors
> -(:c:func:`drm_connector_cleanup()`). Furthermore, connectors that
> -have been added to sysfs must be removed by a call to
> -:c:func:`drm_connector_unregister()` before calling
> -:c:func:`drm_connector_cleanup()`.
> -
> -Connectors state change detection must be cleanup up with a call to
> -:c:func:`drm_kms_helper_poll_fini()`.
> -
> -Output discovery and initialization example
>
> -
> -.. code-block:: c
> -
> -void intel_crt_init(struct drm_device *dev)
> -{
> -struct drm_connector *connector;
> -struct intel_output *intel_output;
> -
> -intel_output = kzalloc(sizeof(struct intel_output), GFP_KERNEL);
> -if (!intel_output)
> -return;
> -
> -connector = _output->base;
> -drm_connector_init(dev, _output->base,
> - _crt_connector_funcs, DRM_MODE_CONNECTOR_VGA);
> -
> -drm_encoder_init(dev, _output->enc, _crt_enc_funcs,
> - DRM_MODE_ENCODER_DAC);
> -
> -drm_connector_attach_encoder(_output->base,
> - _output->enc);
> -
> -/* Set up the DDC bus. */
> -intel_output->ddc_bus = intel_i2c_create(dev, GPIOA, "CRTDDC_A");
> -if (!intel_output->ddc_bus) {
> -dev_printk(KERN_ERR, >pdev->dev, "DDC bus registration "
> - "failed.\n");
> -return;
> -}
> -
> -intel_output->type = INTEL_OUTPUT_ANALOG;
> -connector->interlace_allowed = 0;
> -connector->doublescan_allowed = 0;
> -
> -drm_encoder_helper_add(_output->enc, _crt_helper_funcs);
> -drm_connector_helper_add(connector,
> _crt_connector_helper_funcs);
> -
> -drm_connector_register(connector);
> -}
> -
> -In the example above (taken from the i915 driver), a CRTC, connector and
> -encoder combination is created. A device-specific i2c bus is also
> -created for fetching EDID data and performing monitor detection. Once
> -the process is complete, the new connector is registered with sysfs to
> -make its properties available to applications.
> -
> KMS Locking
> ===
>
>
Re: [PATCH 3/5] drm/i2c: tda998x: add support for writing SPD
On Wed, Jan 30, 2019 at 03:41:04PM +, Brian Starkey wrote:
> Hi Russell,
>
> These did eventually reach me on Saturday evening.
>
> On Fri, Jan 25, 2019 at 09:43:19AM +, Russell King wrote:
> > Add support for writing the SPD infoframe to the TDA998x. Identify us
> > as "Generic" vendor "PC" product, and as "PC general" source device
> > information.
> >
> > Signed-off-by: Russell King
> > ---
>
> As this infoframe is optional, and is intended to provide a "useful"
> name to the user, I wonder if there's really much value in just
> sending "Generic"/"PC"? It seems that it might be better to just not
> send the SPD infoframe until we have a way to put something more
> useful there (e.g. specified by the host driver).
It's along the lines of what other drivers do - are you suggesting
that other drivers should not send the SPD infoframe either?
E.g.
static void vc4_hdmi_set_spd_infoframe(struct drm_encoder *encoder)
{
union hdmi_infoframe frame;
int ret;
ret = hdmi_spd_infoframe_init(, "Broadcom", "Videocore");
===
mtk_hdmi_setup_spd_infoframe(hdmi, "mediatek", "On-chip HDMI");
===
ret = hdmi_spd_infoframe_init(, "Intel", "Integrated gfx");
None of these convey a "useful" name to the user, unless the user
knows what is inside their device - eg, "it's a mediatek SoC" or
"it's a Broadcom SoC".
I could send instead "Philips" "TDA998x" which would be on-par with
these strings.
Maybe there should be a way to set these from DT and/or userspace?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/doc: Move hdmi infoframe docs
On 1/30/19 11:30 AM, Daniel Vetter wrote: > .. next to all the other sink helpers. The rect library is more used > for handling plane clipping, so belongs to those imo. > > Signed-off-by: Daniel Vetter Reviewed-by: Nicholas Kazlauskas Looks better than being sandwiched between the HDMI helpers. Flip work is also plane related in a sense. Nicholas Kazlauskas > --- > Documentation/gpu/drm-kms-helpers.rst | 24 > 1 file changed, 12 insertions(+), 12 deletions(-) > > diff --git a/Documentation/gpu/drm-kms-helpers.rst > b/Documentation/gpu/drm-kms-helpers.rst > index fbd11b2fe5b5..17ca7f8bf3d3 100644 > --- a/Documentation/gpu/drm-kms-helpers.rst > +++ b/Documentation/gpu/drm-kms-helpers.rst > @@ -296,18 +296,6 @@ SCDC Helper Functions Reference > .. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c > :export: > > -Rectangle Utilities Reference > -= > - > -.. kernel-doc:: include/drm/drm_rect.h > - :doc: rect utils > - > -.. kernel-doc:: include/drm/drm_rect.h > - :internal: > - > -.. kernel-doc:: drivers/gpu/drm/drm_rect.c > - :export: > - > HDMI Infoframes Helper Reference > > > @@ -322,6 +310,18 @@ libraries and hence is also included here. > .. kernel-doc:: drivers/video/hdmi.c > :export: > > +Rectangle Utilities Reference > += > + > +.. kernel-doc:: include/drm/drm_rect.h > + :doc: rect utils > + > +.. kernel-doc:: include/drm/drm_rect.h > + :internal: > + > +.. kernel-doc:: drivers/gpu/drm/drm_rect.c > + :export: > + > Flip-work Helper Reference > == > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202445] amdgpu/dc: framerate dropping below adaptive sync range causes screen flickering
https://bugzilla.kernel.org/show_bug.cgi?id=202445 --- Comment #7 from Clément Guérin (li...@protonmail.com) --- Thanks. I'll try it out asap. I strongly feel that this feature should be backported to 5.0 since the freesync implementation seems broken without it. I understand if that's not possible. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/doc: fix VRR_ENABLED casing
On Wed, Jan 30, 2019 at 04:57:48PM +, Kazlauskas, Nicholas wrote:
> On 1/30/19 11:30 AM, Daniel Vetter wrote:
> > Yes it's inconsitent with vrr_capable, but this is the actual uapi as
> > exercise by igt.
> >
> > Fixes: ab7a664f7a2d ("drm: Document variable refresh properties")
> > Cc: Nicholas Kazlauskas
> > Cc: Harry Wentland
> > Cc: Pekka Paalanen
> > Cc: Alex Deucher
> > Signed-off-by: Daniel Vetter
>
> Reviewed-by: Nicholas Kazlauskas
>
> It's what xf86-video-amdgpu expects too - the casing is intentional to
> match up with the other default CRTC properties.
>
> Thanks!
Applied, thanks for your review. Can I motivate you to take a look at the
other patches in this series too?
Thanks, Daniel
>
> Nicholas Kazlauskas
>
> > ---
> > drivers/gpu/drm/drm_connector.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_connector.c
> > b/drivers/gpu/drm/drm_connector.c
> > index 847539645558..e3ff73695c32 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -1367,7 +1367,7 @@ EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
> >*
> >*Absence of the property should indicate absence of support.
> >*
> > - * "vrr_enabled":
> > + * "VRR_ENABLED":
> >*Default _crtc boolean property that notifies the driver
> > that the
> >*content on the CRTC is suitable for variable refresh rate
> > presentation.
> >*The driver will take this property as a hint to enable variable
> >
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/doc: fix VRR_ENABLED casing
On 1/30/19 11:30 AM, Daniel Vetter wrote:
> Yes it's inconsitent with vrr_capable, but this is the actual uapi as
> exercise by igt.
>
> Fixes: ab7a664f7a2d ("drm: Document variable refresh properties")
> Cc: Nicholas Kazlauskas
> Cc: Harry Wentland
> Cc: Pekka Paalanen
> Cc: Alex Deucher
> Signed-off-by: Daniel Vetter
Reviewed-by: Nicholas Kazlauskas
It's what xf86-video-amdgpu expects too - the casing is intentional to
match up with the other default CRTC properties.
Thanks!
Nicholas Kazlauskas
> ---
> drivers/gpu/drm/drm_connector.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 847539645558..e3ff73695c32 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1367,7 +1367,7 @@ EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
>*
>* Absence of the property should indicate absence of support.
>*
> - * "vrr_enabled":
> + * "VRR_ENABLED":
>* Default _crtc boolean property that notifies the driver that the
>* content on the CRTC is suitable for variable refresh rate presentation.
>* The driver will take this property as a hint to enable variable
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202445] amdgpu/dc: framerate dropping below adaptive sync range causes screen flickering
https://bugzilla.kernel.org/show_bug.cgi?id=202445 --- Comment #6 from Nicholas Kazlauskas (nicholas.kazlaus...@amd.com) --- Should be: https://patchwork.freedesktop.org/series/53559/ "drm/amd/display: Add below the range support for FreeSync" -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202445] amdgpu/dc: framerate dropping below adaptive sync range causes screen flickering
https://bugzilla.kernel.org/show_bug.cgi?id=202445 --- Comment #5 from Clément Guérin (li...@protonmail.com) --- Can you point me to the commits introducing this feature? Thanks. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/5] dt-bindings: display: renesas: lvds: Document r8a7744 bindings
On Tue, 22 Jan 2019 15:25:46 +, Biju Das wrote: > Document the RZ/G1N (R8A7744) LVDS bindings. > > Signed-off-by: Biju Das > --- > Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/5] dt-bindings: display: renesas: lvds: Document r8a7744 bindings
On Tue, Jan 22, 2019 at 05:44:28PM +0200, Laurent Pinchart wrote: > Hi Biju, > > Thank you for the patch. > > On Tue, Jan 22, 2019 at 03:25:46PM +, Biju Das wrote: > > Document the RZ/G1N (R8A7744) LVDS bindings. > > > > Signed-off-by: Biju Das > > Reviewed-by: Laurent Pinchart > > and taken in my tree. But not in linux-next? Or you did some $subject fixups which breaks my detecting that. :( Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/savage: mark expected switch fall-throughs
On Tue, Jan 29, 2019 at 02:20:06PM -0600, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> This patch fixes the following warnings:
>
> drivers/gpu/drm/savage/savage_state.c:301:8: warning: this statement may fall
> through [-Wimplicit-fallthrough=]
> drivers/gpu/drm/savage/savage_state.c:438:8: warning: this statement may fall
> through [-Wimplicit-fallthrough=]
> drivers/gpu/drm/savage/savage_state.c:559:8: warning: this statement may fall
> through [-Wimplicit-fallthrough=]
> drivers/gpu/drm/savage/savage_state.c:697:8: warning: this statement may fall
> through [-Wimplicit-fallthrough=]
>
> Warning level 3 was used: -Wimplicit-fallthrough=3
>
> This patch is part of the ongoing efforts to enabling
> -Wimplicit-fallthrough.
>
> Signed-off-by: Gustavo A. R. Silva
This and the via patch merged to drm-misc-next, thanks.
-Daniel
> ---
> drivers/gpu/drm/savage/savage_state.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/savage/savage_state.c
> b/drivers/gpu/drm/savage/savage_state.c
> index 7559a820bd43..ebb8b7d32b33 100644
> --- a/drivers/gpu/drm/savage/savage_state.c
> +++ b/drivers/gpu/drm/savage/savage_state.c
> @@ -299,6 +299,7 @@ static int savage_dispatch_dma_prim(drm_savage_private_t
> * dev_priv,
> case SAVAGE_PRIM_TRILIST_201:
> reorder = 1;
> prim = SAVAGE_PRIM_TRILIST;
> + /* fall through */
> case SAVAGE_PRIM_TRILIST:
> if (n % 3 != 0) {
> DRM_ERROR("wrong number of vertices %u in TRILIST\n",
> @@ -436,6 +437,7 @@ static int savage_dispatch_vb_prim(drm_savage_private_t *
> dev_priv,
> case SAVAGE_PRIM_TRILIST_201:
> reorder = 1;
> prim = SAVAGE_PRIM_TRILIST;
> + /* fall through */
> case SAVAGE_PRIM_TRILIST:
> if (n % 3 != 0) {
> DRM_ERROR("wrong number of vertices %u in TRILIST\n",
> @@ -557,6 +559,7 @@ static int savage_dispatch_dma_idx(drm_savage_private_t *
> dev_priv,
> case SAVAGE_PRIM_TRILIST_201:
> reorder = 1;
> prim = SAVAGE_PRIM_TRILIST;
> + /* fall through */
> case SAVAGE_PRIM_TRILIST:
> if (n % 3 != 0) {
> DRM_ERROR("wrong number of indices %u in TRILIST\n", n);
> @@ -695,6 +698,7 @@ static int savage_dispatch_vb_idx(drm_savage_private_t *
> dev_priv,
> case SAVAGE_PRIM_TRILIST_201:
> reorder = 1;
> prim = SAVAGE_PRIM_TRILIST;
> + /* fall through */
> case SAVAGE_PRIM_TRILIST:
> if (n % 3 != 0) {
> DRM_ERROR("wrong number of indices %u in TRILIST\n", n);
> --
> 2.20.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm: dpu: Don't set frame_busy_mask for async updates
From: Sean Paul The frame_busy mask is used in frame_done event handling, which is not invoked for async commits. So an async commit will leave the frame_busy mask populated after it completes and future commits will start with the busy mask incorrect. This showed up on disable after cursor move. I was hitting the "this should not happen" comment in the frame event worker since frame_busy was set, we queued the event, but there were no frames pending (since async also doesn't set that). Signed-off-by: Sean Paul --- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c index 36158b7d99cd..1a81c4daabc9 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c @@ -1558,8 +1558,14 @@ static void _dpu_encoder_kickoff_phys(struct dpu_encoder_virt *dpu_enc, if (!ctl) continue; - if (phys->split_role != ENC_ROLE_SLAVE) + /* +* This is cleared in frame_done worker, which isn't invoked +* for async commits. So don't set this for async, since it'll +* roll over to the next commit. +*/ + if (!async && phys->split_role != ENC_ROLE_SLAVE) set_bit(i, dpu_enc->frame_busy_mask); + if (!phys->ops.needs_single_flush || !phys->ops.needs_single_flush(phys)) _dpu_encoder_trigger_flush(_enc->base, phys, 0x0, -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/doc: Move hdmi infoframe docs
.. next to all the other sink helpers. The rect library is more used for handling plane clipping, so belongs to those imo. Signed-off-by: Daniel Vetter --- Documentation/gpu/drm-kms-helpers.rst | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst index fbd11b2fe5b5..17ca7f8bf3d3 100644 --- a/Documentation/gpu/drm-kms-helpers.rst +++ b/Documentation/gpu/drm-kms-helpers.rst @@ -296,18 +296,6 @@ SCDC Helper Functions Reference .. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c :export: -Rectangle Utilities Reference -= - -.. kernel-doc:: include/drm/drm_rect.h - :doc: rect utils - -.. kernel-doc:: include/drm/drm_rect.h - :internal: - -.. kernel-doc:: drivers/gpu/drm/drm_rect.c - :export: - HDMI Infoframes Helper Reference @@ -322,6 +310,18 @@ libraries and hence is also included here. .. kernel-doc:: drivers/video/hdmi.c :export: +Rectangle Utilities Reference += + +.. kernel-doc:: include/drm/drm_rect.h + :doc: rect utils + +.. kernel-doc:: include/drm/drm_rect.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/drm_rect.c + :export: + Flip-work Helper Reference == -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/doc: fix VRR_ENABLED casing
Yes it's inconsitent with vrr_capable, but this is the actual uapi as
exercise by igt.
Fixes: ab7a664f7a2d ("drm: Document variable refresh properties")
Cc: Nicholas Kazlauskas
Cc: Harry Wentland
Cc: Pekka Paalanen
Cc: Alex Deucher
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_connector.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 847539645558..e3ff73695c32 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1367,7 +1367,7 @@ EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
*
* Absence of the property should indicate absence of support.
*
- * "vrr_enabled":
+ * "VRR_ENABLED":
* Default _crtc boolean property that notifies the driver that the
* content on the CRTC is suitable for variable refresh rate presentation.
* The driver will take this property as a hint to enable variable
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/doc: Drop chapter "KMS Initialization and Cleanup"
It only talks about crtc, brings up intel as an exampel and I think is
more misleading than useful really. Plus we have lots of discussion
about how your standard kms driver should be initialized/cleaned up,
so maybe better to document this when we have a better idea.
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms.rst | 96 ---
1 file changed, 96 deletions(-)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 75c882e09fee..23a3c986ef6d 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -410,102 +410,6 @@ Encoder Functions Reference
.. kernel-doc:: drivers/gpu/drm/drm_encoder.c
:export:
-KMS Initialization and Cleanup
-==
-
-A KMS device is abstracted and exposed as a set of planes, CRTCs,
-encoders and connectors. KMS drivers must thus create and initialize all
-those objects at load time after initializing mode setting.
-
-CRTCs (:c:type:`struct drm_crtc `)
-
-
-A CRTC is an abstraction representing a part of the chip that contains a
-pointer to a scanout buffer. Therefore, the number of CRTCs available
-determines how many independent scanout buffers can be active at any
-given time. The CRTC structure contains several fields to support this:
-a pointer to some video memory (abstracted as a frame buffer object), a
-display mode, and an (x, y) offset into the video memory to support
-panning or configurations where one piece of video memory spans multiple
-CRTCs.
-
-CRTC Initialization
-~~~
-
-A KMS device must create and register at least one struct
-:c:type:`struct drm_crtc ` instance. The instance is
-allocated and zeroed by the driver, possibly as part of a larger
-structure, and registered with a call to :c:func:`drm_crtc_init()`
-with a pointer to CRTC functions.
-
-
-Cleanup
-
-The DRM core manages its objects' lifetime. When an object is not needed
-anymore the core calls its destroy function, which must clean up and
-free every resource allocated for the object. Every
-:c:func:`drm_\*_init()` call must be matched with a corresponding
-:c:func:`drm_\*_cleanup()` call to cleanup CRTCs
-(:c:func:`drm_crtc_cleanup()`), planes
-(:c:func:`drm_plane_cleanup()`), encoders
-(:c:func:`drm_encoder_cleanup()`) and connectors
-(:c:func:`drm_connector_cleanup()`). Furthermore, connectors that
-have been added to sysfs must be removed by a call to
-:c:func:`drm_connector_unregister()` before calling
-:c:func:`drm_connector_cleanup()`.
-
-Connectors state change detection must be cleanup up with a call to
-:c:func:`drm_kms_helper_poll_fini()`.
-
-Output discovery and initialization example
-
-.. code-block:: c
-
-void intel_crt_init(struct drm_device *dev)
-{
-struct drm_connector *connector;
-struct intel_output *intel_output;
-
-intel_output = kzalloc(sizeof(struct intel_output), GFP_KERNEL);
-if (!intel_output)
-return;
-
-connector = _output->base;
-drm_connector_init(dev, _output->base,
- _crt_connector_funcs, DRM_MODE_CONNECTOR_VGA);
-
-drm_encoder_init(dev, _output->enc, _crt_enc_funcs,
- DRM_MODE_ENCODER_DAC);
-
-drm_connector_attach_encoder(_output->base,
- _output->enc);
-
-/* Set up the DDC bus. */
-intel_output->ddc_bus = intel_i2c_create(dev, GPIOA, "CRTDDC_A");
-if (!intel_output->ddc_bus) {
-dev_printk(KERN_ERR, >pdev->dev, "DDC bus registration "
- "failed.\n");
-return;
-}
-
-intel_output->type = INTEL_OUTPUT_ANALOG;
-connector->interlace_allowed = 0;
-connector->doublescan_allowed = 0;
-
-drm_encoder_helper_add(_output->enc, _crt_helper_funcs);
-drm_connector_helper_add(connector, _crt_connector_helper_funcs);
-
-drm_connector_register(connector);
-}
-
-In the example above (taken from the i915 driver), a CRTC, connector and
-encoder combination is created. A device-specific i2c bus is also
-created for fetching EDID data and performing monitor detection. Once
-the process is complete, the new connector is registered with sysfs to
-make its properties available to applications.
-
KMS Locking
===
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108889] [CI][SHARDS] igt@sw_sync@sync_busy_fork_unixsocket - incomplete - __igt_fork_helper: Assertion `!proc->running' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=108889 --- Comment #6 from CI Bug Log --- The CI Bug Log issue associated to this bug has been updated. ### New filters associated * BLB BWR HSW BSW: Incomplete - igt_stop_helper: Assertion `helper_was_alive(proc, status) failed - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_195/fi-blb-e6850/igt@sw_sync@sync_busy_fork.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_195/fi-bsw-n3050/igt@sw_sync@sync_busy_fork.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_189/fi-hsw-peppy/igt@sw_sync@sync_busy_fork.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_194/fi-bwr-2160/igt@sw_sync@sync_busy_fork.html -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109493] [CI][DRMTIP] igt@gem_cpu_reloc@forked - fail - igt_skip: Assertion `!test_child' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=109493 --- Comment #4 from Chris Wilson --- Found the skip, patch sent. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/vkms: Bugfix extra vblank frame
kms_flip tests are breaking on vkms when simulate vblank because vblank event sequence count returns one extra frame after arm vblank event to make a page flip. When vblank interrupt happens, userspace processes the vblank event and issues the next page flip command. Kernel calls queue_work to call commit_planes and arm the new page flip. The next vblank picks up the newly armed vblank event and vblank interrupt happens again. The arm and vblank event are asynchronous, then, on the next vblank, we receive x+2 from `get_vblank_timestamp`, instead x+1, although timestamp and vblank seqno matches. Function `get_vblank_timestamp` is reached by 2 ways: - from `drm_mode_page_flip_ioctl`: driver is doing one atomic operation to synchronize planes in the same output. There is no vblank simulation, the `drm_crtc_arm_vblank_event` function adds 1 on vblank count, and the variable in_vblank_irq is false - from `vkms_vblank_simulate`: since the driver is doing a vblank simulation, the variable in_vblank_irq is true. Fix this problem subtracting one vblank period from vblank_time when `get_vblank_timestamp` is called from trace `drm_mode_page_flip_ioctl`, i.e., is not a real vblank interrupt, and getting the timestamp and vblank seqno when it is a real vblank interrupt. The reason for all this is that get_vblank_timestamp always supplies the timestamp for the next vblank event. The hrtimer is the vblank simulator, and it needs the correct previous value to present the next vblank. Since this is how hw timestamp registers work and what the vblank core expects. Signed-off-by: Shayenne Moura Signed-off-by: Daniel Vetter --- drivers/gpu/drm/vkms/vkms_crtc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c index d44bfc392491..23146ff2a25b 100644 --- a/drivers/gpu/drm/vkms/vkms_crtc.c +++ b/drivers/gpu/drm/vkms/vkms_crtc.c @@ -87,6 +87,9 @@ bool vkms_get_vblank_timestamp(struct drm_device *dev, unsigned int pipe, *vblank_time = output->vblank_hrtimer.node.expires; + if (!in_vblank_irq) + *vblank_time -= output->period_ns; + return true; } -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm: vkms: Bugfix racing hrtimer vblank handle
When the vblank irq happens, kernel time subsystem executes
`vkms_vblank_simulate`. In parallel or not, it prepares all stuff
necessary to the next vblank with arm, and it must flush these
stuff before the next vblank irq. However, vblank counter is ahead
when arm is executed in parallel with handle vblank.
CPU 0: CPU 1:
| |
atomic_commit_tail is ongoing|
| |
| hrtimer: vkms_vblank_simulate()
| |
| drm_crtc_handle_vblank()
| |
drm_crtc_arm_vblank()|
| |
->get_vblank_timestamp() |
| |
| hrtimer_forward_now()
Then, we should guarantee that the vblank interval time is correct
(not changed) before finish the vblank handle.
Fix the bug including the call to `hrtimer_forward_now()` in the same
lock of `drm_crtc_handle_vblank()` to ensure that the timestamp update
is correct when finish the vblank handle.
Signed-off-by: Shayenne Moura
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/vkms/vkms_crtc.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index 23146ff2a25b..5a095610726b 100644
--- a/drivers/gpu/drm/vkms/vkms_crtc.c
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -10,13 +10,17 @@
#include
#include
-static void _vblank_handle(struct vkms_output *output)
+static enum hrtimer_restart vkms_vblank_simulate(struct hrtimer *timer)
{
+ struct vkms_output *output = container_of(timer, struct vkms_output,
+ vblank_hrtimer);
struct drm_crtc *crtc = >crtc;
struct vkms_crtc_state *state = to_vkms_crtc_state(crtc->state);
+ int ret_overrun;
bool ret;
spin_lock(>lock);
+
ret = drm_crtc_handle_vblank(crtc);
if (!ret)
DRM_ERROR("vkms failure on handling vblank");
@@ -37,19 +41,9 @@ static void _vblank_handle(struct vkms_output *output)
DRM_WARN("failed to queue vkms_crc_work_handle");
}
- spin_unlock(>lock);
-}
-
-static enum hrtimer_restart vkms_vblank_simulate(struct hrtimer *timer)
-{
- struct vkms_output *output = container_of(timer, struct vkms_output,
- vblank_hrtimer);
- int ret_overrun;
-
- _vblank_handle(output);
-
ret_overrun = hrtimer_forward_now(>vblank_hrtimer,
output->period_ns);
+ spin_unlock(>lock);
return HRTIMER_RESTART;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] drm/vkms: Bugfix for igt-tests
This patchset contains patches to fix the extra frame bug on kms_flip igt-test. First patch solves the extra vblank frame that breaks many tests on kms_flip and second patch solves the race condition caused by the solution added in the first one. Shayenne Moura (2): drm/vkms: Bugfix extra vblank frame drm/vkms: Bugfix racing hrtimer vblank handle drivers/gpu/drm/vkms/vkms_crtc.c | 21 + 1 file changed, 9 insertions(+), 12 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
