Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb
On Wed, Apr 4, 2018 at 12:42 AM, Rob Clark wrote:
> Add an atomic helper to implement dirtyfb support. This is needed to
> support DSI command-mode panels with x11 userspace (ie. when we can't
> rely on pageflips to trigger a flush to the panel).
>
> To signal to the driver that the async atomic update needs to
> synchronize with fences, even though the fb didn't change, the
> drm_atomic_state::dirty flag is added.
>
> Signed-off-by: Rob Clark
> ---
> Background: there are a number of different folks working on getting
> upstream kernel working on various different phones/tablets with qcom
> SoC's.. many of them have command mode panels, so we kind of need a
> way to support the legacy dirtyfb ioctl for x11 support.
>
> I know there is work on a proprer non-legacy atomic property for
> userspace to communicate dirty-rect(s) to the kernel, so this can
> be improved from triggering a full-frame flush once that is in
> place. But we kinda needa a stop-gap solution.
>
> I had considered an in-driver solution for this, but things get a
> bit tricky if userspace ands up combining dirtyfb ioctls with page-
> flips, because we need to synchronize setting various CTL.FLUSH bits
> with setting the CTL.START bit. (ie. really all we need to do for
> cmd mode panels is bang CTL.START, but is this ends up racing with
> pageflips setting FLUSH bits, then bad things.) The easiest soln
> is to wrap this up as an atomic commit and rely on the worker to
> serialize things. Hence adding an atomic dirtyfb helper.
>
> I guess at least the helper, with some small addition to translate
> and pass-thru the dirty rect(s) is useful to the final atomic dirty-
> rect property solution. Depending on how far off that is, a stop-
> gap solution could be useful.
Adding Noralf, who iirc already posted the full dirty helpers already somewhere.
-Daniel
>
> drivers/gpu/drm/drm_atomic_helper.c | 66
> +
> drivers/gpu/drm/msm/msm_atomic.c| 5 ++-
> drivers/gpu/drm/msm/msm_fb.c| 1 +
> include/drm/drm_atomic_helper.h | 4 +++
> include/drm/drm_plane.h | 9 +
> 5 files changed, 84 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index c35654591c12..a578dc681b27 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3504,6 +3504,7 @@ void __drm_atomic_helper_plane_duplicate_state(struct
> drm_plane *plane,
> if (state->fb)
> drm_framebuffer_get(state->fb);
>
> + state->dirty = false;
> state->fence = NULL;
> state->commit = NULL;
> }
> @@ -3847,6 +3848,71 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc
> *crtc,
> }
> EXPORT_SYMBOL(drm_atomic_helper_legacy_gamma_set);
>
> +/**
> + * drm_atomic_helper_dirtyfb - helper for dirtyfb
> + *
> + * A helper to implement drm_framebuffer_funcs::dirty
> + */
> +int drm_atomic_helper_dirtyfb(struct drm_framebuffer *fb,
> + struct drm_file *file_priv, unsigned flags,
> + unsigned color, struct drm_clip_rect *clips,
> + unsigned num_clips)
> +{
> + struct drm_modeset_acquire_ctx ctx;
> + struct drm_atomic_state *state;
> + struct drm_plane *plane;
> + int ret = 0;
> +
> + /*
> +* When called from ioctl, we are interruptable, but not when
> +* called internally (ie. defio worker)
> +*/
> + drm_modeset_acquire_init(&ctx,
> + file_priv ? DRM_MODESET_ACQUIRE_INTERRUPTIBLE : 0);
> +
> + state = drm_atomic_state_alloc(fb->dev);
> + if (!state) {
> + ret = -ENOMEM;
> + goto out;
> + }
> + state->acquire_ctx = &ctx;
> +
> +retry:
> + drm_for_each_plane(plane, fb->dev) {
> + struct drm_plane_state *plane_state;
> +
> + if (plane->state->fb != fb)
> + continue;
> +
> + plane_state = drm_atomic_get_plane_state(state, plane);
> + if (IS_ERR(plane_state)) {
> + ret = PTR_ERR(plane_state);
> + goto out;
> + }
> +
> + plane_state->dirty = true;
> + }
> +
> + ret = drm_atomic_nonblocking_commit(state);
> +
> +out:
> + if (ret == -EDEADLK) {
> + drm_atomic_state_clear(state);
> + ret = drm_modeset_backoff(&ctx);
> + if (!ret)
> + goto retry;
> + }
> +
> + drm_atomic_state_put(state);
> +
> + drm_modeset_drop_locks(&ctx);
> + drm_modeset_acquire_fini(&ctx);
> +
> + return ret;
> +
> +}
> +EXPORT_SYMBOL(drm_atomic_helper_dirtyfb);
> +
> /**
> * __drm_atomic_helper_private_duplicate_state - copy atomic private state
> * @obj: CRTC object
> diff --git a/drivers/gpu/drm/msm/msm_atomic.c
> b/driver
RE: [PATCH v3 08/40] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session
> -Original Message-
> From: C, Ramalingam
> Sent: Tuesday, April 03, 2018 16:57
> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
> jani.nik...@linux.intel.com; Winkler, Tomas ;
> Usyskin, Alexander
> Cc: Vivi, Rodrigo ; C, Ramalingam
>
> Subject: [PATCH v3 08/40] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session
>
> Request ME FW to start the HDCP2.2 session for a intel port.
> Prepares payloads for command WIRED_INITIATE_HDCP2_SESSION and sent
> 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]
>
> Signed-off-by: Ramalingam C
> ---
> drivers/misc/mei/hdcp/mei_hdcp.c | 68
>
> include/linux/mei_hdcp.h | 11 +++
> 2 files changed, 79 insertions(+)
>
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index 2811a25f8c57..7caee0947761 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -33,9 +33,77 @@
> #include
> #include
> #include
> +#include
> +
> +#include "mei_hdcp.h"
>
> static BLOCKING_NOTIFIER_HEAD(mei_cldev_notifier_list);
>
> +/**
> + * mei_initiate_hdcp2_session:
> + * Function to start a Wired HDCP2.2 Tx Session with ME FW
> + *
> + * @cldev: Pointer for mei client device
> + * @data : Intel HW specific Data
> + * @ake_data : ptr to store AKE_Init
> + *
> + * Returns 0 on Success, <0 on Failure.
> + */
> +int mei_initiate_hdcp2_session(struct mei_cl_device *cldev,
> +struct mei_hdcp_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 device *dev;
> + ssize_t byte;
> +
> + if (!data || !ake_data)
> + return -EINVAL;
> +
> + dev = &cldev->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 = data->port;
> + session_init_in.protocol = (uint8_t)data->protocol;
> +
> + byte = mei_cldev_send(cldev, (u8 *)&session_init_in,
> + sizeof(session_init_in));
> + if (byte < 0) {
> + dev_dbg(dev, "mei_cldev_send failed. %d\n", (int)byte);
%zd don't require (int)
> + return byte;
> + }
> +
> + byte = mei_cldev_recv(cldev, (u8 *)&session_init_out,
> + sizeof(session_init_out));
> + if (byte < 0) {
> + dev_dbg(dev, "mei_cldev_recv failed. %d\n", (int)byte);
%zd don't require (int)
> + 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 -1;
It will be better to return some meaningful error code here.
> + }
> +
> + 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,
> +sizeof(session_init_out.r_tx));
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(mei_initiate_hdcp2_session);
> +
> void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool
> enabled)
> {
> if (enabled)
> diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h
> index 634c1a5bdf1e..bb4f27d3abcb 100644
> --- a/include/linux/mei_hdcp.h
> +++ b/include/linux/mei_hdcp.h
> @@ -28,6 +28,7 @@
> #define _LINUX_MEI_HDCP_H
>
> #include
> +#include
>
> enum mei_cldev_state {
> MEI_CLDEV_DISABLED,
> @@ -105,6 +106,9 @@ struct mei_hdcp_data {
> #ifdef CONFIG_INTEL_MEI_HDCP
> int mei_cldev_register_notify(struct notifier_block *nb);
> int mei_cldev_unregister_notify(struct notifier_block *nb);
> +int mei_initiate_hdcp2_session(struct mei_cl_device *cldev,
> +struct mei_hdcp_data *data,
> +struct hdcp2_ake_init *ake_data);
> #else
> static int mei_cldev_register_notify(struct notifier_block *nb)
> {
> @@ -114,5 +118,12 @@ static int mei_cldev_unregister_notify(struct
> notifier_block *nb)
> {
> return -ENODEV;
> }
> +static
Re: [PATCH v2 0/5] allow override of bus format in bridges
On Wed, Apr 4, 2018 at 12:28 AM, Laurent Pinchart
wrote:
> Hi Daniel,
>
> On Wednesday, 28 March 2018 10:08:26 EEST Daniel Vetter wrote:
>> On Mon, Mar 26, 2018 at 11:24:42PM +0200, Peter Rosin wrote:
>> > Hi!
>> >
>> > [I got to v2 sooner than expected]
>> >
>> > I have an Atmel sama5d31 hooked up to an lvds encoder and then
>> > on to an lvds panel. Which seems like something that has been
>> > done one or two times before...
>> >
>> > The problem is that the bus_format of the SoC and the panel do
>> > not agree. The SoC driver (atmel-hlcdc) can handle the
>> > rgb444, rgb565, rgb666 and rgb888 bus formats. The hardware is
>> > wired for the rgb565 case. The lvds encoder supports rgb888 on
>> > its input side with the LSB wires for each color simply pulled
>> > down internally in the encoder in my case which means that the
>> > rgb565 bus_format is the format that works best. And the panel
>> > is expecting lvds (vesa-24), which is what the encoder outputs.
>> >
>> > The reason I "blame" the bus_format of the drm_connector is that
>> > with the below DT snippet, things do not work *exactly* due to
>> > that. At least, it starts to work if I hack the panel-lvds driver
>> > to report the rgb565 bus_format instead of vesa-24.
>> >
>> > panel: panel {
>> > compatible = "panel-lvds";
>> >
>> > width-mm = <304>;
>> > height-mm = <228;
>> >
>> > data-mapping = "vesa-24";
>> >
>> > panel-timing {
>> > // 1024x768 @ 60Hz (typical)
>> > clock-frequency = <5214 6500 7110>;
>> > hactive = <1024>;
>> > vactive = <768>;
>> > hfront-porch = <48 88 88>;
>> > hback-porch = <96 168 168>;
>> > hsync-len = <32 64 64>;
>> > vfront-porch = <8 13 14>;
>> > vback-porch = <8 13 14>;
>> > vsync-len = <8 12 14>;
>> > };
>> >
>> > port {
>> > panel_input: endpoint {
>> > remote-endpoint = <&lvds_encoder_output>;
>> > };
>> > };
>> > };
>> >
>> > lvds-encoder {
>> > compatible = "ti,ds90c185", "lvds-encoder";
>> >
>> > ports {
>> > #address-cells = <1>;
>> > #size-cells = <0>;
>> >
>> > port@0 {
>> > reg = <0>;
>> >
>> > lvds_encoder_input: endpoint {
>> > remote-endpoint = <&hlcdc_output>;
>> > };
>> > };
>> >
>> > port@1 {
>> > reg = <1>;
>> >
>> > lvds_encoder_output: endpoint {
>> > remote-endpoint = <&panel_input>;
>> > };
>> > };
>> > };
>> > };
>> >
>> > But, instead of perverting the panel-lvds driver with support
>> > for a totally fake non-lvds bus_format, I intruduce an API that allows
>> > display controller drivers to query the required bus_format of any
>> > intermediate bridges, and match up with that instead of the formats
>> > given by the drm_connector. I trigger this with this addition to the
>> >
>> > lvds-encoder DT node:
>> > interface-pix-fmt = "rgb565";
>> >
>> > Naming is hard though, so I'm not sure if that's good?
>> >
>> > I threw in the first patch, since that is the actual lvds encoder
>> > I have in this case.
>> >
>> > Suggestions welcome.
>>
>> Took a quick look, feels rather un-atomic. And there's beend discussing
>> for other bridge related state that we might want to track (like the full
>> adjusted_mode that might need to be adjusted at each stage in the chain).
>> So here's my suggestions:
>>
>> - Add an optional per-bridge internal state struct using the support in
>>
>> https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#handling-driver-privat
>> e-state
>>
>> Yes it says "driver private", but since bridge is just helper stuff
>> that's all included. "driver private" == "not exposed as uapi" here.
>> Include all the usual convenience wrappers to get at the state for a
>> bridge.
>>
>> - Then stuff your bus_format into that new drm_bridge_state struct.
>>
>> - Add a new bridge callback atomic_check, which gets that bridge state as
>> parameter (similar to all the other atomic_check functions).
>>
>> This way we can even handle the bus_format dynamically, through the atomic
>> framework your bridge's atomic_check callback can look at the entire
>> atomic state (both up and down the chain if needed), it all neatly fits
>> into atomic overall and it's much easier to extend.
>
> While I think we'll eventually need bridge states, I don't think that's need
> yet. The bus formats reported by this patch s
RE: [PATCH v3 05/40] misc/mei/hdcp: Notifier chain for mei cldev state change
> -Original Message-
> From: C, Ramalingam
> Sent: Tuesday, April 03, 2018 16:57
> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
> jani.nik...@linux.intel.com; Winkler, Tomas ;
> Usyskin, Alexander
> Cc: Vivi, Rodrigo ; C, Ramalingam
>
> Subject: [PATCH v3 05/40] misc/mei/hdcp: Notifier chain for mei cldev state
> change
>
> Notifier Chain is defined to inform all its clients about the mei
> client device state change. Routine is defined for the clients to
> register and unregister for the notification on state change.
>
> v2:
> Rebased.
> v3:
> Notifier chain is adopted for cldev state update [Tomas]
>
> Signed-off-by: Ramalingam C
> ---
May be I miss something, but bus subsystem already has notifier chain.
(BUS_NOTIFY_ADD_DEVICE etc.)
We only ought to make mei_cl_bus_type available in header.
> drivers/misc/mei/hdcp/mei_hdcp.c | 36 +++---
> include/linux/mei_hdcp.h | 48
>
> 2 files changed, 81 insertions(+), 3 deletions(-)
> create mode 100644 include/linux/mei_hdcp.h
>
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index b334615728a7..2811a25f8c57 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -31,6 +31,32 @@
> #include
> #include
> #include
> +#include
> +#include
> +
> +static BLOCKING_NOTIFIER_HEAD(mei_cldev_notifier_list);
> +
> +void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool
> enabled)
> +{
> + if (enabled)
> + blocking_notifier_call_chain(&mei_cldev_notifier_list,
> + MEI_CLDEV_ENABLED, cldev);
> + else
> + blocking_notifier_call_chain(&mei_cldev_notifier_list,
> + MEI_CLDEV_DISABLED, NULL);
> +}
> +
> +int mei_cldev_register_notify(struct notifier_block *nb)
> +{
> + return blocking_notifier_chain_register(&mei_cldev_notifier_list,
> nb);
> +}
> +EXPORT_SYMBOL_GPL(mei_cldev_register_notify);
> +
> +int mei_cldev_unregister_notify(struct notifier_block *nb)
> +{
> + return blocking_notifier_chain_unregister(&mei_cldev_notifier_list,
> nb);
> +}
> +EXPORT_SYMBOL_GPL(mei_cldev_unregister_notify);
>
> static int mei_hdcp_probe(struct mei_cl_device *cldev,
> const struct mei_cl_device_id *id)
> @@ -38,14 +64,18 @@ static int mei_hdcp_probe(struct mei_cl_device
> *cldev,
> int ret;
>
> ret = mei_cldev_enable(cldev);
> - if (ret < 0)
> + if (ret < 0) {
> dev_err(&cldev->dev, "mei_cldev_enable Failed. %d\n", ret);
> + return ret;
> + }
>
> - return ret;
> + mei_cldev_state_notify_clients(cldev, true);
> + return 0;
> }
>
> static int mei_hdcp_remove(struct mei_cl_device *cldev)
> {
> + mei_cldev_state_notify_clients(cldev, false);
> mei_cldev_set_drvdata(cldev, NULL);
> return mei_cldev_disable(cldev);
> }
> @@ -71,4 +101,4 @@ module_mei_cl_driver(mei_hdcp_driver);
>
> MODULE_AUTHOR("Intel Corporation");
> MODULE_LICENSE("Dual BSD/GPL");
> -MODULE_DESCRIPTION("HDCP");
> +MODULE_DESCRIPTION("MEI HDCP");
> diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h
> new file mode 100644
> index ..3b46bebde718
> --- /dev/null
> +++ b/include/linux/mei_hdcp.h
> @@ -0,0 +1,48 @@
> +/* SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) */
> +/*
> + * Copyright © 2017-2018 Intel Corporation
> + *
> + * Permission to use, copy, modify, distribute, and sell this software and
> its
> + * documentation for any purpose is hereby granted without fee, provided
> that
> + * the above copyright notice appear in all copies and that both that
> copyright
> + * notice and this permission notice appear in supporting documentation,
> and
> + * that the name of the copyright holders not be used in advertising or
> + * publicity pertaining to distribution of the software without specific,
> + * written prior permission. The copyright holders make no representations
> + * about the suitability of this software for any purpose. It is provided
> "as
> + * is" without express or implied warranty.
> + *
> + * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO
> THIS SOFTWARE,
> + * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
> FITNESS, IN NO
> + * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL,
> INDIRECT OR
> + * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING
> FROM LOSS OF USE,
> + * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
> OR OTHER
> + * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE
> OR PERFORMANCE
> + * OF THIS SOFTWARE.
> + *
> + * Authors:
> + * Ramalingam C
> + */
> +
> +#ifndef _LINUX_MEI_HDCP_H
> +#define _LINUX_MEI_HDCP_H
> +
> +enum mei_cldev_state {
> + MEI_CLDEV_DISABLED
Re: [PATCH v3 24/40] drm/i915: Implement HDCP2.2 repeater authentication
Hi Ramalingam,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20180403]
[cannot apply to v4.16]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Ramalingam-C/drm-i915-Implement-HDCP2-2/20180404-031743
base: git://anongit.freedesktop.org/drm-intel for-linux-next
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/i915/intel_hdcp.c:1182:30: sparse: incorrect type in
>> assignment (different base types) @@expected restricted __be16
>> [assigned] [usertype] k @@got e] k @@
drivers/gpu/drm/i915/intel_hdcp.c:1182:30:expected restricted __be16
[assigned] [usertype] k
drivers/gpu/drm/i915/intel_hdcp.c:1182:30:got int
drivers/gpu/drm/i915/intel_hdcp.c:1277:12: warning:
'hdcp2_authenticate_sink' defined but not used [-Wunused-function]
static int hdcp2_authenticate_sink(struct intel_connector *connector)
^~~
In file included from drivers/gpu/drm/i915/intel_hdcp.c:13:0:
include/linux/mei_hdcp.h:148:12: warning: 'mei_cldev_unregister_notify'
defined but not used [-Wunused-function]
static int mei_cldev_unregister_notify(struct notifier_block *nb)
^~~
include/linux/mei_hdcp.h:144:12: warning: 'mei_cldev_register_notify'
defined but not used [-Wunused-function]
static int mei_cldev_register_notify(struct notifier_block *nb)
^
vim +1182 drivers/gpu/drm/i915/intel_hdcp.c
1163
1164 static
1165 int hdcp2_propagate_stream_management_info(struct intel_connector
*connector)
1166 {
1167 struct intel_digital_port *intel_dig_port =
conn_to_dig_port(connector);
1168 struct intel_hdcp *hdcp = &connector->hdcp;
1169 union {
1170 struct hdcp2_rep_stream_manage stream_manage;
1171 struct hdcp2_rep_stream_ready stream_ready;
1172 } msgs;
1173 const struct intel_hdcp_shim *shim = hdcp->hdcp_shim;
1174 int ret;
1175
1176 /* Prepare RepeaterAuth_Stream_Manage msg */
1177 msgs.stream_manage.msg_id = HDCP_2_2_REP_STREAM_MANAGE;
1178 reverse_endianness(msgs.stream_manage.seq_num_m,
HDCP_2_2_SEQ_NUM_LEN,
1179 (u8 *)&hdcp->seq_num_m);
1180
1181 /* K no of streams is fixed as 1. Stored as big-endian. */
> 1182 msgs.stream_manage.k = __swab16(1);
1183
1184 /* For HDMI this is forced to be 0x0. For DP SST also this is
0x0. */
1185 msgs.stream_manage.streams[0].stream_id = 0;
1186 msgs.stream_manage.streams[0].stream_type = hdcp->content_type;
1187
1188 /* Send it to Repeater */
1189 ret = shim->write_2_2_msg(intel_dig_port, &msgs.stream_manage,
1190sizeof(msgs.stream_manage));
1191 if (ret < 0)
1192 return ret;
1193
1194 ret = shim->read_2_2_msg(intel_dig_port,
HDCP_2_2_REP_STREAM_READY,
1195 &msgs.stream_ready,
sizeof(msgs.stream_ready));
1196 if (ret < 0)
1197 return ret;
1198
1199 hdcp->mei_data.seq_num_m = hdcp->seq_num_m;
1200 hdcp->mei_data.streams[0].stream_type = hdcp->content_type;
1201
1202 ret = hdcp2_verify_mprime(hdcp, &msgs.stream_ready);
1203 if (ret < 0)
1204 return ret;
1205
1206 hdcp->seq_num_m++;
1207
1208 if (hdcp->seq_num_m > HDCP_2_2_SEQ_NUM_MAX) {
1209 DRM_DEBUG_KMS("seq_num_m roll over.\n");
1210 return -1;
1211 }
1212 return 0;
1213 }
1214
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 98520] System randomly crashes / freezes while playing certain games
https://bugs.freedesktop.org/show_bug.cgi?id=98520 MirceaKitsune changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=105425 -- 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 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)
https://bugs.freedesktop.org/show_bug.cgi?id=105425 MirceaKitsune changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=98520 -- 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 98520] System randomly crashes / freezes while playing certain games
https://bugs.freedesktop.org/show_bug.cgi?id=98520 --- Comment #43 from MirceaKitsune --- (In reply to Timothy Arceri from comment #42) Sorry, I actually forgot about this report. I have a new one with fresh data and ongoing testing, which I'm trying to get more help with as I don't know what to do next. Please take a look at it over here: https://bugs.freedesktop.org/show_bug.cgi?id=105425 -- 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 98520] System randomly crashes / freezes while playing certain games
https://bugs.freedesktop.org/show_bug.cgi?id=98520 Timothy Arceri changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |FIXED --- Comment #42 from Timothy Arceri --- (In reply to MirceaKitsune from comment #41) > (In reply to wbrana from comment #40) > > Hi. I do not run Ubuntu, just openSUSE Tumbleweed. However they finally > upgraded to Mesa 17.3.2 recently, so I may test more games soon and see if > there are any crashes left. Since I reported this nearly two years ago, the > original crash was most certainly lost in all the changes done since... new > ones may still exist however. In that case we should close this bug. Please open a fresh bug report for any new issues. Thanks. -- 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
[RFC PATCH] misc/mei/hdcp: mei_cldev_state_notify_clients() can be static
Fixes: ca998fc3888e ("misc/mei/hdcp: Notifier chain for mei cldev state change")
Signed-off-by: Fengguang Wu
---
mei_hdcp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 2811a25..452e60d 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -36,7 +36,7 @@
static BLOCKING_NOTIFIER_HEAD(mei_cldev_notifier_list);
-void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool enabled)
+static void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool
enabled)
{
if (enabled)
blocking_notifier_call_chain(&mei_cldev_notifier_list,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/imx: Remove last traces of struct imx_drm_crtc
On Tue, Mar 27, 2018 at 6:39 PM, Leonard Crestez
wrote:
> When the definition of this struct was removed a forward declaration and an
> unused struct member were still left around. Remove them because they serve
> no purpose.
>
> Fixes 44b460cfe554 ("drm: imx: remove struct imx_drm_crtc and
> imx_drm_crtc_helper_funcs")
>
> Signed-off-by: Leonard Crestez
Reviewed-by: Fabio Estevam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103276] VEGA 64 3D Opengl does not work with kernel amd staging 4.13 on Fedora core 26
https://bugs.freedesktop.org/show_bug.cgi?id=103276 Timothy Arceri changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG --- Comment #3 from Timothy Arceri --- While 4.13 has some Vega support I believe it was on headless (non-display) support. I believe you need at least 4.15 for Vega if you want display support. -- 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: drm/scheduler for vc5
Christian König writes: > Hi Eric, > > nice to see that the scheduler gets used more and more. > > The feature your need to solve both your binning/rendering as well as > your MMU problem is dependency handling. See the "dependency" callback > of the backend operations. > > With this callback the driver can return dma_fences which need to signal > (or at least be scheduled if it targets the same ring buffer/fifo). > > Now you need dma_fences as result of your run_job callback for the > binning step anyway. So when you return this fence from the binning step > as dependency for your rendering step the scheduler does exactly what > you want, e.g. not start the rendering before the binning is finished. It looks like in order to use the bin's fence returned from run_job, render first needs to depend on exec->bin.base.s_fence->scheduled so that run_job has been called. Is there any reason not to just depend on exec->bin.base.s_fence->finished, instead? Finished will be signaled basically immediately after the run_job fence completes, right? Also, I hadn't quite followed your suggestion about MMU switching before. Your trick was that you return a newly-generated dependency on MMU switching as the final dependency, so that you only decide on serializing the MMU switch once you're ready to run and the scheduler was about to pick your job anyway. This seems good to me. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 12/40] misc/mei/hdcp: Initiate Locality check
Hi Ramalingam, Thank you for the patch! Yet something to improve: [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on next-20180403] [cannot apply to v4.16] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Ramalingam-C/drm-i915-Implement-HDCP2-2/20180404-031743 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: i386-allmodconfig (attached as .config) compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): drivers/misc/mei/hdcp/mei_hdcp.c:52:5: error: redefinition of 'mei_initiate_hdcp2_session' int mei_initiate_hdcp2_session(struct mei_cl_device *cldev, ^~ In file included from drivers/misc/mei/hdcp/mei_hdcp.c:35:0: include/linux/mei_hdcp.h:137:5: note: previous definition of 'mei_initiate_hdcp2_session' was here int mei_initiate_hdcp2_session(struct mei_cl_device *cldev, ^~ drivers/misc/mei/hdcp/mei_hdcp.c:122:1: error: redefinition of 'mei_verify_receiver_cert_prepare_km' mei_verify_receiver_cert_prepare_km(struct mei_cl_device *cldev, ^~~ In file included from drivers/misc/mei/hdcp/mei_hdcp.c:35:0: include/linux/mei_hdcp.h:144:1: note: previous definition of 'mei_verify_receiver_cert_prepare_km' was here mei_verify_receiver_cert_prepare_km(struct mei_cl_device *cldev, ^~~ drivers/misc/mei/hdcp/mei_hdcp.c:200:5: error: redefinition of 'mei_verify_hprime' int mei_verify_hprime(struct mei_cl_device *cldev, struct mei_hdcp_data *data, ^ In file included from drivers/misc/mei/hdcp/mei_hdcp.c:35:0: include/linux/mei_hdcp.h:154:5: note: previous definition of 'mei_verify_hprime' was here int mei_verify_hprime(struct mei_cl_device *cldev, struct mei_hdcp_data *data, ^ drivers/misc/mei/hdcp/mei_hdcp.c:258:5: error: redefinition of 'mei_store_pairing_info' int mei_store_pairing_info(struct mei_cl_device *cldev, ^~ In file included from drivers/misc/mei/hdcp/mei_hdcp.c:35:0: include/linux/mei_hdcp.h:160:5: note: previous definition of 'mei_store_pairing_info' was here int mei_store_pairing_info(struct mei_cl_device *cldev, ^~ >> drivers/misc/mei/hdcp/mei_hdcp.c:318:5: error: redefinition of >> 'mei_initiate_locality_check' int mei_initiate_locality_check(struct mei_cl_device *cldev, ^~~ In file included from drivers/misc/mei/hdcp/mei_hdcp.c:35:0: include/linux/mei_hdcp.h:167:5: note: previous definition of 'mei_initiate_locality_check' was here int mei_initiate_locality_check(struct mei_cl_device *cldev, ^~~ drivers/misc/mei/hdcp/mei_hdcp.c:374:5: error: redefinition of 'mei_cldev_register_notify' int mei_cldev_register_notify(struct notifier_block *nb) ^ In file included from drivers/misc/mei/hdcp/mei_hdcp.c:35:0: include/linux/mei_hdcp.h:128:12: note: previous definition of 'mei_cldev_register_notify' was here static int mei_cldev_register_notify(struct notifier_block *nb) ^ drivers/misc/mei/hdcp/mei_hdcp.c:380:5: error: redefinition of 'mei_cldev_unregister_notify' int mei_cldev_unregister_notify(struct notifier_block *nb) ^~~ In file included from drivers/misc/mei/hdcp/mei_hdcp.c:35:0: include/linux/mei_hdcp.h:132:12: note: previous definition of 'mei_cldev_unregister_notify' was here static int mei_cldev_unregister_notify(struct notifier_block *nb) ^~~ include/linux/mei_hdcp.h:132:12: warning: 'mei_cldev_unregister_notify' defined but not used [-Wunused-function] include/linux/mei_hdcp.h:128:12: warning: 'mei_cldev_register_notify' defined but not used [-Wunused-function] static int mei_cldev_register_notify(struct notifier_block *nb) ^ vim +/mei_initiate_locality_check +318 drivers/misc/mei/hdcp/mei_hdcp.c 246 247 /** 248 * mei_store_pairing_info: 249 * Function to store pairing info received from panel 250 * 251 * @cldev : Pointer for mei client device 252 * @data: Intel HW specific Data 253 * @pairing_info: Pointer for AKE_Send_Pairing_Info 254 * 255 * Returns 0 on Success, <0 on Failure 256 */ 257 > 258 int mei_store_pairing_info(struct mei
Re: [PATCH] drm/msm: Fix possible null dereference on failure of get_pages()
On Tue, Apr 03, 2018 at 11:38:45PM +0100, Ben Hutchings wrote:
> Commit 62e3a3e342af changed get_pages() to initialise
> msm_gem_object::pages before trying to initialise msm_gem_object::sgt,
> so that put_pages() would properly clean up pages in the failure
> case.
>
> However, this means that put_pages() now needs to check that
> msm_gem_object::sgt is not null before trying to clean it up, and
> this check was only applied to part of the cleanup code. Move
> it all into the conditional block. (Strictly speaking we don't
> need to make the kfree() conditional, but since we can't avoid
> checking for null ourselves we may as well do so.)
Seems legit to me. Thanks for the catch.
Reviewed-by: Jordan Crouse
> Fixes: 62e3a3e342af ("drm/msm: fix leak in failed get_pages")
> Signed-off-by: Ben Hutchings
> ---
> drivers/gpu/drm/msm/msm_gem.c | 20 +++-
> 1 file changed, 11 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
> index 07376de9ff4c..37ec3411297b 100644
> --- a/drivers/gpu/drm/msm/msm_gem.c
> +++ b/drivers/gpu/drm/msm/msm_gem.c
> @@ -132,17 +132,19 @@ static void put_pages(struct drm_gem_object *obj)
> struct msm_gem_object *msm_obj = to_msm_bo(obj);
>
> if (msm_obj->pages) {
> - /* For non-cached buffers, ensure the new pages are clean
> - * because display controller, GPU, etc. are not coherent:
> - */
> - if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
> - dma_unmap_sg(obj->dev->dev, msm_obj->sgt->sgl,
> - msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
> + if (msm_obj->sgt) {
> + /* For non-cached buffers, ensure the new
> + * pages are clean because display controller,
> + * GPU, etc. are not coherent:
> + */
> + if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
> + dma_unmap_sg(obj->dev->dev, msm_obj->sgt->sgl,
> + msm_obj->sgt->nents,
> + DMA_BIDIRECTIONAL);
>
> - if (msm_obj->sgt)
> sg_free_table(msm_obj->sgt);
> -
> - kfree(msm_obj->sgt);
> + kfree(msm_obj->sgt);
> + }
>
> if (use_pages(obj))
> drm_gem_put_pages(obj, msm_obj->pages, true, false);
> --
> 2.16.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC] drm/atomic+msm: add helper to implement legacy dirtyfb
Add an atomic helper to implement dirtyfb support. This is needed to
support DSI command-mode panels with x11 userspace (ie. when we can't
rely on pageflips to trigger a flush to the panel).
To signal to the driver that the async atomic update needs to
synchronize with fences, even though the fb didn't change, the
drm_atomic_state::dirty flag is added.
Signed-off-by: Rob Clark
---
Background: there are a number of different folks working on getting
upstream kernel working on various different phones/tablets with qcom
SoC's.. many of them have command mode panels, so we kind of need a
way to support the legacy dirtyfb ioctl for x11 support.
I know there is work on a proprer non-legacy atomic property for
userspace to communicate dirty-rect(s) to the kernel, so this can
be improved from triggering a full-frame flush once that is in
place. But we kinda needa a stop-gap solution.
I had considered an in-driver solution for this, but things get a
bit tricky if userspace ands up combining dirtyfb ioctls with page-
flips, because we need to synchronize setting various CTL.FLUSH bits
with setting the CTL.START bit. (ie. really all we need to do for
cmd mode panels is bang CTL.START, but is this ends up racing with
pageflips setting FLUSH bits, then bad things.) The easiest soln
is to wrap this up as an atomic commit and rely on the worker to
serialize things. Hence adding an atomic dirtyfb helper.
I guess at least the helper, with some small addition to translate
and pass-thru the dirty rect(s) is useful to the final atomic dirty-
rect property solution. Depending on how far off that is, a stop-
gap solution could be useful.
drivers/gpu/drm/drm_atomic_helper.c | 66 +
drivers/gpu/drm/msm/msm_atomic.c| 5 ++-
drivers/gpu/drm/msm/msm_fb.c| 1 +
include/drm/drm_atomic_helper.h | 4 +++
include/drm/drm_plane.h | 9 +
5 files changed, 84 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index c35654591c12..a578dc681b27 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3504,6 +3504,7 @@ void __drm_atomic_helper_plane_duplicate_state(struct
drm_plane *plane,
if (state->fb)
drm_framebuffer_get(state->fb);
+ state->dirty = false;
state->fence = NULL;
state->commit = NULL;
}
@@ -3847,6 +3848,71 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc
*crtc,
}
EXPORT_SYMBOL(drm_atomic_helper_legacy_gamma_set);
+/**
+ * drm_atomic_helper_dirtyfb - helper for dirtyfb
+ *
+ * A helper to implement drm_framebuffer_funcs::dirty
+ */
+int drm_atomic_helper_dirtyfb(struct drm_framebuffer *fb,
+ struct drm_file *file_priv, unsigned flags,
+ unsigned color, struct drm_clip_rect *clips,
+ unsigned num_clips)
+{
+ struct drm_modeset_acquire_ctx ctx;
+ struct drm_atomic_state *state;
+ struct drm_plane *plane;
+ int ret = 0;
+
+ /*
+* When called from ioctl, we are interruptable, but not when
+* called internally (ie. defio worker)
+*/
+ drm_modeset_acquire_init(&ctx,
+ file_priv ? DRM_MODESET_ACQUIRE_INTERRUPTIBLE : 0);
+
+ state = drm_atomic_state_alloc(fb->dev);
+ if (!state) {
+ ret = -ENOMEM;
+ goto out;
+ }
+ state->acquire_ctx = &ctx;
+
+retry:
+ drm_for_each_plane(plane, fb->dev) {
+ struct drm_plane_state *plane_state;
+
+ if (plane->state->fb != fb)
+ continue;
+
+ plane_state = drm_atomic_get_plane_state(state, plane);
+ if (IS_ERR(plane_state)) {
+ ret = PTR_ERR(plane_state);
+ goto out;
+ }
+
+ plane_state->dirty = true;
+ }
+
+ ret = drm_atomic_nonblocking_commit(state);
+
+out:
+ if (ret == -EDEADLK) {
+ drm_atomic_state_clear(state);
+ ret = drm_modeset_backoff(&ctx);
+ if (!ret)
+ goto retry;
+ }
+
+ drm_atomic_state_put(state);
+
+ drm_modeset_drop_locks(&ctx);
+ drm_modeset_acquire_fini(&ctx);
+
+ return ret;
+
+}
+EXPORT_SYMBOL(drm_atomic_helper_dirtyfb);
+
/**
* __drm_atomic_helper_private_duplicate_state - copy atomic private state
* @obj: CRTC object
diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index bf5f8c39f34d..bb55a048e98b 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -201,7 +201,10 @@ int msm_atomic_commit(struct drm_device *dev,
* Figure out what fence to wait for:
*/
for_each_oldnew_plane_in_state(state, plane, old_plane_state,
new_plane_state, i) {
- if ((new_plane_s
Re: [Intel-gfx] [PATCH v3 11/40] misc/mei/hdcp: Store the HDCP Pairing info
Hi Ramalingam,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20180403]
[cannot apply to v4.16]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Ramalingam-C/drm-i915-Implement-HDCP2-2/20180404-031743
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/misc/mei/hdcp/mei_hdcp.c:52:5: error: redefinition of
'mei_initiate_hdcp2_session'
int mei_initiate_hdcp2_session(struct mei_cl_device *cldev,
^~
In file included from drivers/misc/mei/hdcp/mei_hdcp.c:35:0:
include/linux/mei_hdcp.h:134:5: note: previous definition of
'mei_initiate_hdcp2_session' was here
int mei_initiate_hdcp2_session(struct mei_cl_device *cldev,
^~
drivers/misc/mei/hdcp/mei_hdcp.c:122:1: error: redefinition of
'mei_verify_receiver_cert_prepare_km'
mei_verify_receiver_cert_prepare_km(struct mei_cl_device *cldev,
^~~
In file included from drivers/misc/mei/hdcp/mei_hdcp.c:35:0:
include/linux/mei_hdcp.h:141:1: note: previous definition of
'mei_verify_receiver_cert_prepare_km' was here
mei_verify_receiver_cert_prepare_km(struct mei_cl_device *cldev,
^~~
drivers/misc/mei/hdcp/mei_hdcp.c:200:5: error: redefinition of
'mei_verify_hprime'
int mei_verify_hprime(struct mei_cl_device *cldev, struct mei_hdcp_data
*data,
^
In file included from drivers/misc/mei/hdcp/mei_hdcp.c:35:0:
include/linux/mei_hdcp.h:151:5: note: previous definition of
'mei_verify_hprime' was here
int mei_verify_hprime(struct mei_cl_device *cldev, struct mei_hdcp_data
*data,
^
>> drivers/misc/mei/hdcp/mei_hdcp.c:258:5: error: redefinition of
>> 'mei_store_pairing_info'
int mei_store_pairing_info(struct mei_cl_device *cldev,
^~
In file included from drivers/misc/mei/hdcp/mei_hdcp.c:35:0:
include/linux/mei_hdcp.h:157:5: note: previous definition of
'mei_store_pairing_info' was here
int mei_store_pairing_info(struct mei_cl_device *cldev,
^~
drivers/misc/mei/hdcp/mei_hdcp.c:318:5: error: redefinition of
'mei_cldev_register_notify'
int mei_cldev_register_notify(struct notifier_block *nb)
^
In file included from drivers/misc/mei/hdcp/mei_hdcp.c:35:0:
include/linux/mei_hdcp.h:125:12: note: previous definition of
'mei_cldev_register_notify' was here
static int mei_cldev_register_notify(struct notifier_block *nb)
^
drivers/misc/mei/hdcp/mei_hdcp.c:324:5: error: redefinition of
'mei_cldev_unregister_notify'
int mei_cldev_unregister_notify(struct notifier_block *nb)
^~~
In file included from drivers/misc/mei/hdcp/mei_hdcp.c:35:0:
include/linux/mei_hdcp.h:129:12: note: previous definition of
'mei_cldev_unregister_notify' was here
static int mei_cldev_unregister_notify(struct notifier_block *nb)
^~~
include/linux/mei_hdcp.h:129:12: warning: 'mei_cldev_unregister_notify'
defined but not used [-Wunused-function]
include/linux/mei_hdcp.h:125:12: warning: 'mei_cldev_register_notify'
defined but not used [-Wunused-function]
static int mei_cldev_register_notify(struct notifier_block *nb)
^
vim +/mei_store_pairing_info +258 drivers/misc/mei/hdcp/mei_hdcp.c
188
189 /**
190 * mei_verify_hprime:
191 * Function to verify AKE_Send_H_prime received
192 *
193 * @cldev : Pointer for mei client device
194 * @data: Intel HW specific Data
195 * @rx_hprime : Pointer for AKE_Send_H_prime
196 * @hprime_sz : Input buffer size
197 *
198 * Returns 0 on Success, <0 on Failure
199 */
> 200 int mei_verify_hprime(struct mei_cl_device *cldev, struct mei_hdcp_data
> *data,
201struct hdcp2_ake_send_hprime *rx_hprime)
202 {
203 struct wired_cmd_ake_send_hprime_in send_hprime_in = { { 0 } };
204 struct wired_cmd_ake_send_hprime_out send_hprime_out = { { 0 }
};
205 struct device *dev;
206 ssize_t byte;
207
208 if (!data || !rx_hprime)
209 return -EINVAL;
2
Re: [PATCH v2 0/5] allow override of bus format in bridges
Hi again,
On Wednesday, 4 April 2018 01:28:29 EEST Laurent Pinchart wrote:
> On Wednesday, 28 March 2018 10:08:26 EEST Daniel Vetter wrote:
> > On Mon, Mar 26, 2018 at 11:24:42PM +0200, Peter Rosin wrote:
> > > Hi!
> > >
> > > [I got to v2 sooner than expected]
> > >
> > > I have an Atmel sama5d31 hooked up to an lvds encoder and then
> > > on to an lvds panel. Which seems like something that has been
> > > done one or two times before...
> > >
> > > The problem is that the bus_format of the SoC and the panel do
> > > not agree. The SoC driver (atmel-hlcdc) can handle the
> > > rgb444, rgb565, rgb666 and rgb888 bus formats. The hardware is
> > > wired for the rgb565 case. The lvds encoder supports rgb888 on
> > > its input side with the LSB wires for each color simply pulled
> > > down internally in the encoder in my case which means that the
> > > rgb565 bus_format is the format that works best. And the panel
> > > is expecting lvds (vesa-24), which is what the encoder outputs.
> > >
> > > The reason I "blame" the bus_format of the drm_connector is that
> > > with the below DT snippet, things do not work *exactly* due to
> > > that. At least, it starts to work if I hack the panel-lvds driver
> > > to report the rgb565 bus_format instead of vesa-24.
> > >
> > > panel: panel {
> > > compatible = "panel-lvds";
> > >
> > > width-mm = <304>;
> > > height-mm = <228;
> > >
> > > data-mapping = "vesa-24";
> > >
> > > panel-timing {
> > > // 1024x768 @ 60Hz (typical)
> > > clock-frequency = <5214 6500 7110>;
> > > hactive = <1024>;
> > > vactive = <768>;
> > > hfront-porch = <48 88 88>;
> > > hback-porch = <96 168 168>;
> > > hsync-len = <32 64 64>;
> > > vfront-porch = <8 13 14>;
> > > vback-porch = <8 13 14>;
> > > vsync-len = <8 12 14>;
> > > };
> > >
> > > port {
> > > panel_input: endpoint {
> > > remote-endpoint = <&lvds_encoder_output>;
> > > };
> > > };
> > > };
> > >
> > > lvds-encoder {
> > > compatible = "ti,ds90c185", "lvds-encoder";
> > >
> > > ports {
> > > #address-cells = <1>;
> > > #size-cells = <0>;
> > >
> > > port@0 {
> > > reg = <0>;
> > >
> > > lvds_encoder_input: endpoint {
> > > remote-endpoint = <&hlcdc_output>;
> > > };
> > > };
> > >
> > > port@1 {
> > > reg = <1>;
> > >
> > > lvds_encoder_output: endpoint {
> > > remote-endpoint = <&panel_input>;
> > > };
> > > };
> > > };
> > > };
> > >
> > > But, instead of perverting the panel-lvds driver with support
> > > for a totally fake non-lvds bus_format, I intruduce an API that allows
> > > display controller drivers to query the required bus_format of any
> > > intermediate bridges, and match up with that instead of the formats
> > > given by the drm_connector. I trigger this with this addition to the
> > >
> > > lvds-encoder DT node:
> > > interface-pix-fmt = "rgb565";
> > >
> > > Naming is hard though, so I'm not sure if that's good?
> > >
> > > I threw in the first patch, since that is the actual lvds encoder
> > > I have in this case.
> > >
> > > Suggestions welcome.
> >
> > Took a quick look, feels rather un-atomic. And there's beend discussing
> > for other bridge related state that we might want to track (like the full
> > adjusted_mode that might need to be adjusted at each stage in the chain).
> > So here's my suggestions:
> >
> > - Add an optional per-bridge internal state struct using the support in
> >
> > https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#handling-driver-priv
> > at e-state
> >
> > Yes it says "driver private", but since bridge is just helper stuff
> > that's all included. "driver private" == "not exposed as uapi" here.
> > Include all the usual convenience wrappers to get at the state for a
> > bridge.
> >
> > - Then stuff your bus_format into that new drm_bridge_state struct.
> >
> > - Add a new bridge callback atomic_check, which gets that bridge state as
> > parameter (similar to all the other atomic_check functions).
> >
> > This way we can even handle the bus_format dynamically, through the atomic
> > framework your bridge's atomic_check callback can look at the entire
> > atomic state (both up and down the chain if needed), it
Re: [PATCH v2 0/5] allow override of bus format in bridges
Hi Daniel,
On Wednesday, 28 March 2018 10:08:26 EEST Daniel Vetter wrote:
> On Mon, Mar 26, 2018 at 11:24:42PM +0200, Peter Rosin wrote:
> > Hi!
> >
> > [I got to v2 sooner than expected]
> >
> > I have an Atmel sama5d31 hooked up to an lvds encoder and then
> > on to an lvds panel. Which seems like something that has been
> > done one or two times before...
> >
> > The problem is that the bus_format of the SoC and the panel do
> > not agree. The SoC driver (atmel-hlcdc) can handle the
> > rgb444, rgb565, rgb666 and rgb888 bus formats. The hardware is
> > wired for the rgb565 case. The lvds encoder supports rgb888 on
> > its input side with the LSB wires for each color simply pulled
> > down internally in the encoder in my case which means that the
> > rgb565 bus_format is the format that works best. And the panel
> > is expecting lvds (vesa-24), which is what the encoder outputs.
> >
> > The reason I "blame" the bus_format of the drm_connector is that
> > with the below DT snippet, things do not work *exactly* due to
> > that. At least, it starts to work if I hack the panel-lvds driver
> > to report the rgb565 bus_format instead of vesa-24.
> >
> > panel: panel {
> > compatible = "panel-lvds";
> >
> > width-mm = <304>;
> > height-mm = <228;
> >
> > data-mapping = "vesa-24";
> >
> > panel-timing {
> > // 1024x768 @ 60Hz (typical)
> > clock-frequency = <5214 6500 7110>;
> > hactive = <1024>;
> > vactive = <768>;
> > hfront-porch = <48 88 88>;
> > hback-porch = <96 168 168>;
> > hsync-len = <32 64 64>;
> > vfront-porch = <8 13 14>;
> > vback-porch = <8 13 14>;
> > vsync-len = <8 12 14>;
> > };
> >
> > port {
> > panel_input: endpoint {
> > remote-endpoint = <&lvds_encoder_output>;
> > };
> > };
> > };
> >
> > lvds-encoder {
> > compatible = "ti,ds90c185", "lvds-encoder";
> >
> > ports {
> > #address-cells = <1>;
> > #size-cells = <0>;
> >
> > port@0 {
> > reg = <0>;
> >
> > lvds_encoder_input: endpoint {
> > remote-endpoint = <&hlcdc_output>;
> > };
> > };
> >
> > port@1 {
> > reg = <1>;
> >
> > lvds_encoder_output: endpoint {
> > remote-endpoint = <&panel_input>;
> > };
> > };
> > };
> > };
> >
> > But, instead of perverting the panel-lvds driver with support
> > for a totally fake non-lvds bus_format, I intruduce an API that allows
> > display controller drivers to query the required bus_format of any
> > intermediate bridges, and match up with that instead of the formats
> > given by the drm_connector. I trigger this with this addition to the
> >
> > lvds-encoder DT node:
> > interface-pix-fmt = "rgb565";
> >
> > Naming is hard though, so I'm not sure if that's good?
> >
> > I threw in the first patch, since that is the actual lvds encoder
> > I have in this case.
> >
> > Suggestions welcome.
>
> Took a quick look, feels rather un-atomic. And there's beend discussing
> for other bridge related state that we might want to track (like the full
> adjusted_mode that might need to be adjusted at each stage in the chain).
> So here's my suggestions:
>
> - Add an optional per-bridge internal state struct using the support in
>
> https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#handling-driver-privat
> e-state
>
> Yes it says "driver private", but since bridge is just helper stuff
> that's all included. "driver private" == "not exposed as uapi" here.
> Include all the usual convenience wrappers to get at the state for a
> bridge.
>
> - Then stuff your bus_format into that new drm_bridge_state struct.
>
> - Add a new bridge callback atomic_check, which gets that bridge state as
> parameter (similar to all the other atomic_check functions).
>
> This way we can even handle the bus_format dynamically, through the atomic
> framework your bridge's atomic_check callback can look at the entire
> atomic state (both up and down the chain if needed), it all neatly fits
> into atomic overall and it's much easier to extend.
While I think we'll eventually need bridge states, I don't think that's need
yet. The bus formats reported by this pat
Re: [PATCH v2 1/5] dt-bindings: display: bridge: lvds-transmitter: add ti, ds90c185
Hi Peter, Thank you for the patch. On Tuesday, 27 March 2018 00:24:43 EEST Peter Rosin wrote: > Start list of actual chips compatible with "lvds-encoder". > > Signed-off-by: Peter Rosin Reviewed-by: Laurent Pinchart > --- > .../devicetree/bindings/display/bridge/lvds-transmitter.txt | 8 - > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git > a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt > b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt > index fd39ad34c383..50220190c203 100644 > --- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt > +++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt > @@ -22,7 +22,13 @@ among others. > > Required properties: > > -- compatible: Must be "lvds-encoder" > +- compatible: Must be one or more of the following > + - "ti,ds90c185" for the TI DS90C185 FPD-Link Serializer > + - "lvds-encoder" for a generic LVDS encoder device > + > + When compatible with the generic version, nodes must list the > + device-specific version corresponding to the device first > + followed by the generic version. > > Required nodes: -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 2/3] drm: bridge: panel: allow override of the bus format
Hi Jacopo,
On Tuesday, 27 March 2018 11:16:01 EEST jacopo mondi wrote:
> On Mon, Mar 26, 2018 at 10:03:31PM +0300, Laurent Pinchart wrote:
> > On Sunday, 25 March 2018 15:01:11 EEST Peter Rosin wrote:
> >> On 2018-03-20 14:56, Laurent Pinchart wrote:
> >>> On Sunday, 18 March 2018 00:15:24 EET Peter Rosin wrote:
> Useful if the bridge does some kind of conversion of the bus format.
>
> Signed-off-by: Peter Rosin
> ---
>
> drivers/gpu/drm/bridge/panel.c | 22 +-
> include/drm/drm_bridge.h | 1 +
> 2 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/panel.c
> b/drivers/gpu/drm/bridge/panel.c index 6d99d4a3beb3..ccef0283ff41
> 100644
> --- a/drivers/gpu/drm/bridge/panel.c
> +++ b/drivers/gpu/drm/bridge/panel.c
> @@ -22,6 +22,7 @@ struct panel_bridge {
> struct drm_connector connector;
> struct drm_panel *panel;
> u32 connector_type;
> +u32 bus_format;
> };
>
> static inline struct panel_bridge *
> @@ -40,8 +41,15 @@ static int panel_bridge_connector_get_modes(struct
> drm_connector *connector) {
> struct panel_bridge *panel_bridge =
> drm_connector_to_panel_bridge(connector);
> +int ret;
> +
> +ret = drm_panel_get_modes(panel_bridge->panel);
> +
> +if (panel_bridge->bus_format)
> +
> drm_display_info_set_bus_formats(&connector->display_info,
> +
> &panel_bridge->bus_format, 1);
> >>>
> >>> While I agree with the problem statement and, to some extent, the DT
> >>> bindings, I don't think this is the right implementation. You've
> >>> correctly noted that display controller shouldn't blindly use the
> >>> formats reported by the panel through the connector formats, and that
> >>> hacking the panel driver to override the formats isn't a good idea, so
> >>> I wouldn't override the formats reported by the connector. I would
> >>> instead extend the drm_bridge API to report formats at bridge inputs.
> >>> This would be more generic and allow each bridge to configure itself
> >>> according to the next bridge in the chain.
> >>>
> >>> I'm not sure whether this API extension should be in the form of a new
> >>> bridge function, or if the formats should be stored in the drm_bridge
> >>> structure directly as done for connectors in the display info
> >>> structure. I'm tempted by the former, but I'm open to discussions.
> >>
> >> Ok, I can look into that, but let me check if I got this right. From the
> >> very little of the code that I have looked at, I have gathered that
> >> display controllers handle bridges explicitly, right?
> >
> > That's correct, yes. Or, rather, they handle the first bridge in the
> > chain, and then other bridges are handled recursively.
> >
> >> If so, by extending the bridge (with either a new function or new data)
> >> you impose changes to all display controllers wanting to handle this new
> >> bridge input-format. If so, I assume I can leave out the changes to all
> >> display controllers that I do not care about. Correct?
> >
> > That's correct.
> >
> >> Also, don't hold your breath waiting for a v2, but I'll try to get to it
> >> :-)
> >
> > I won't hold my breath, but Jacopo might :-) He has a similar issue to
> > solve (reporting the LVDS modes supported by the bridge).
>
> I was not :) I jumped late on this, as I restarted the DRM bridge work
> yesterday. Peter, can I summarize you my current use case? (which is
> quite similar to yours actually)
>
> At the R-Car DU (Display Unit) output, we have an LVDS encoder
> connected to a 'transparent' LVDS bridge that converts the input LVDS
> stream into digital RGB output to be then HDMI encoded by another
> component.
>
> The 'transparent LVDS decoder', for which I'm now writing a driver,
> should report what pixel bus format it accepts as input as the DU LVDS
> encoder can output an LVDS stream with several different component ordering
> schemes. I was about to come up with a proposal last week but you beat
> me at time, so I'm happy to base my work on what comes out from this
> series.
>
> Laurent: On the THC63LVD driver
> Laurent: at the same time I would not block the THC63LVD1024 driver. I
> can extend bindings to include the "mode map" configuration property,
> and squash my Eagle DTS patch on top of Niklas' one. Then make the newly
> introduced driver use whatever API comes out from this series with an
> incremental patch. Does this work for you? It is true, though, that
> we're anyway late for v4.17 and I could send one single series based
> on some future version of this and that includes all (bridge driver
> and bindings, DU LVDS changes and Eagle DTS), but I feel it's easier
> if we got the bridge driver accepted first,
Re: [Intel-gfx] [PATCH v3 10/40] misc/mei/hdcp: Verify H_prime
Hi Ramalingam,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20180403]
[cannot apply to v4.16]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Ramalingam-C/drm-i915-Implement-HDCP2-2/20180404-031743
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/misc/mei/hdcp/mei_hdcp.c:52:5: error: redefinition of
'mei_initiate_hdcp2_session'
int mei_initiate_hdcp2_session(struct mei_cl_device *cldev,
^~
In file included from drivers/misc/mei/hdcp/mei_hdcp.c:35:0:
include/linux/mei_hdcp.h:131:5: note: previous definition of
'mei_initiate_hdcp2_session' was here
int mei_initiate_hdcp2_session(struct mei_cl_device *cldev,
^~
drivers/misc/mei/hdcp/mei_hdcp.c:122:1: error: redefinition of
'mei_verify_receiver_cert_prepare_km'
mei_verify_receiver_cert_prepare_km(struct mei_cl_device *cldev,
^~~
In file included from drivers/misc/mei/hdcp/mei_hdcp.c:35:0:
include/linux/mei_hdcp.h:138:1: note: previous definition of
'mei_verify_receiver_cert_prepare_km' was here
mei_verify_receiver_cert_prepare_km(struct mei_cl_device *cldev,
^~~
>> drivers/misc/mei/hdcp/mei_hdcp.c:200:5: error: redefinition of
>> 'mei_verify_hprime'
int mei_verify_hprime(struct mei_cl_device *cldev, struct mei_hdcp_data
*data,
^
In file included from drivers/misc/mei/hdcp/mei_hdcp.c:35:0:
include/linux/mei_hdcp.h:148:5: note: previous definition of
'mei_verify_hprime' was here
int mei_verify_hprime(struct mei_cl_device *cldev, struct mei_hdcp_data
*data,
^
drivers/misc/mei/hdcp/mei_hdcp.c:257:5: error: redefinition of
'mei_cldev_register_notify'
int mei_cldev_register_notify(struct notifier_block *nb)
^
In file included from drivers/misc/mei/hdcp/mei_hdcp.c:35:0:
include/linux/mei_hdcp.h:122:12: note: previous definition of
'mei_cldev_register_notify' was here
static int mei_cldev_register_notify(struct notifier_block *nb)
^
drivers/misc/mei/hdcp/mei_hdcp.c:263:5: error: redefinition of
'mei_cldev_unregister_notify'
int mei_cldev_unregister_notify(struct notifier_block *nb)
^~~
In file included from drivers/misc/mei/hdcp/mei_hdcp.c:35:0:
include/linux/mei_hdcp.h:126:12: note: previous definition of
'mei_cldev_unregister_notify' was here
static int mei_cldev_unregister_notify(struct notifier_block *nb)
^~~
include/linux/mei_hdcp.h:126:12: warning: 'mei_cldev_unregister_notify'
defined but not used [-Wunused-function]
include/linux/mei_hdcp.h:122:12: warning: 'mei_cldev_register_notify'
defined but not used [-Wunused-function]
static int mei_cldev_register_notify(struct notifier_block *nb)
^
vim +/mei_verify_hprime +200 drivers/misc/mei/hdcp/mei_hdcp.c
106
107 /**
108 * mei_verify_receiver_cert_prepare_km:
109 * Function to verify the Receiver Certificate AKE_Send_Cert
110 * and prepare AKE_Stored_Km or AKE_No_Stored_Km
111 *
112 * @cldev : Pointer for mei client device
113 * @data: Intel HW specific Data
114 * @rx_cert : Pointer for AKE_Send_Cert
115 * @km_stored : Pointer for pairing status flag
116 * @ek_pub_km : Pointer for output msg
117 * @msg_sz : Pointer for size of AKE_X_Km
118 *
119 * Returns 0 on Success, <0 on Failure
120 */
121 int
> 122 mei_verify_receiver_cert_prepare_km(struct mei_cl_device *cldev,
123 struct mei_hdcp_data *data,
124 struct hdcp2_ake_send_cert *rx_cert,
125 bool *km_stored,
126 struct hdcp2_ake_no_stored_km
*ek_pub_km,
127 size_t *msg_sz)
128 {
129 struct wired_cmd_verify_receiver_cert_in verify_rxcert_in = { {
0 } };
130 struct wired_cmd_verify_receiver_cert_out verify_rxcert_out = {
{ 0 } };
131 struct device *dev;
132 ssize_t byte;
133
134 if (!data || !rx_
Re: [Intel-gfx] [PATCH v3 09/40] misc/mei/hdcp: Verify Receiver Cert and prepare km
Hi Ramalingam,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20180403]
[cannot apply to v4.16]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Ramalingam-C/drm-i915-Implement-HDCP2-2/20180404-031743
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/misc/mei/hdcp/mei_hdcp.c:52:5: error: redefinition of
'mei_initiate_hdcp2_session'
int mei_initiate_hdcp2_session(struct mei_cl_device *cldev,
^~
In file included from drivers/misc/mei/hdcp/mei_hdcp.c:35:0:
include/linux/mei_hdcp.h:129:5: note: previous definition of
'mei_initiate_hdcp2_session' was here
int mei_initiate_hdcp2_session(struct mei_cl_device *cldev,
^~
>> drivers/misc/mei/hdcp/mei_hdcp.c:122:1: error: redefinition of
>> 'mei_verify_receiver_cert_prepare_km'
mei_verify_receiver_cert_prepare_km(struct mei_cl_device *cldev,
^~~
In file included from drivers/misc/mei/hdcp/mei_hdcp.c:35:0:
include/linux/mei_hdcp.h:136:1: note: previous definition of
'mei_verify_receiver_cert_prepare_km' was here
mei_verify_receiver_cert_prepare_km(struct mei_cl_device *cldev,
^~~
drivers/misc/mei/hdcp/mei_hdcp.c:199:5: error: redefinition of
'mei_cldev_register_notify'
int mei_cldev_register_notify(struct notifier_block *nb)
^
In file included from drivers/misc/mei/hdcp/mei_hdcp.c:35:0:
include/linux/mei_hdcp.h:120:12: note: previous definition of
'mei_cldev_register_notify' was here
static int mei_cldev_register_notify(struct notifier_block *nb)
^
drivers/misc/mei/hdcp/mei_hdcp.c:205:5: error: redefinition of
'mei_cldev_unregister_notify'
int mei_cldev_unregister_notify(struct notifier_block *nb)
^~~
In file included from drivers/misc/mei/hdcp/mei_hdcp.c:35:0:
include/linux/mei_hdcp.h:124:12: note: previous definition of
'mei_cldev_unregister_notify' was here
static int mei_cldev_unregister_notify(struct notifier_block *nb)
^~~
include/linux/mei_hdcp.h:124:12: warning: 'mei_cldev_unregister_notify'
defined but not used [-Wunused-function]
include/linux/mei_hdcp.h:120:12: warning: 'mei_cldev_register_notify'
defined but not used [-Wunused-function]
static int mei_cldev_register_notify(struct notifier_block *nb)
^
vim +/mei_verify_receiver_cert_prepare_km +122 drivers/misc/mei/hdcp/mei_hdcp.c
41
42 /**
43 * mei_initiate_hdcp2_session:
44 * Function to start a Wired HDCP2.2 Tx Session with ME FW
45 *
46 * @cldev : Pointer for mei client device
47 * @data: Intel HW specific Data
48 * @ake_data: ptr to store AKE_Init
49 *
50 * Returns 0 on Success, <0 on Failure.
51 */
> 52 int mei_initiate_hdcp2_session(struct mei_cl_device *cldev,
53 struct mei_hdcp_data *data,
54 struct hdcp2_ake_init *ake_data)
55 {
56 struct wired_cmd_initiate_hdcp2_session_in session_init_in = {
{ 0 } };
57 struct wired_cmd_initiate_hdcp2_session_out
58 session_init_out = { {
0 } };
59 struct device *dev;
60 ssize_t byte;
61
62 if (!data || !ake_data)
63 return -EINVAL;
64
65 dev = &cldev->dev;
66
67 session_init_in.header.api_version = HDCP_API_VERSION;
68 session_init_in.header.command_id =
WIRED_INITIATE_HDCP2_SESSION;
69 session_init_in.header.status = ME_HDCP_STATUS_SUCCESS;
70 session_init_in.header.buffer_len =
71
WIRED_CMD_BUF_LEN_INITIATE_HDCP2_SESSION_IN;
72
73 session_init_in.port.integrated_port_type = data->port_type;
74 session_init_in.port.physical_port = data->port;
75 session_init_in.protocol = (uint8_t)data->protocol;
76
77 byte = mei_cldev_send(cldev, (u8 *)&session_init_in,
78sizeof(session_init_in));
79 if (byte < 0) {
80 dev_dbg(dev, &qu
Re: [Freedreno] [PATCH 5/5] drm/msm/A6xx: Add support for using system cache(llc)
On Fri, Mar 23, 2018 at 12:49:51PM +0530, Sharat Masetty wrote:
> The last level system cache can be partitioned to 32
> different slices of which GPU has two slices preallocated.
> The "gpu" slice is used for caching GPU buffers and
> the "gpuhtw" slice is used for caching the GPU SMMU
> pagetables. This patch talks to the core system cache
> driver to acquire the slice handles, configure the SCID's
> to those slices and activates and deactivates the slices
> upon GPU power collapse and restore.
>
> Some support from the IOMMU driver is also needed to
> make use of the system cache. IOMMU_UPSTREAM_HINT is
> a buffer protection flag which enables caching GPU data
> buffers in the system cache with memory attributes such
> as outer cacheable, read-allocate, write-allocate for buffers.
> The GPU then has the ability to override a few cacheability
> parameters which it does to override write-allocate to
> write-no-allocate as the GPU hardware does not benefit much
> from it.
> Similarly DOMAIN_ATTR_USE_UPSTREAM_HINT is another domain level
> attribute used by the IOMMU driver to set the right attributes
> to cache the hardware pagetables into the system cache.
This has a dependency on the LLCC driver and the API to that may change (it is
under review now). When it does, this will have to naturally change as well but
that'll be a minor tweek and won't affect the functionality of this driver so
pending those changes..
Reviewed-by: Jordan Crouse
> Signed-off-by: Sharat Masetty
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 162
> +-
> drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 9 ++
> drivers/gpu/drm/msm/msm_iommu.c | 13 +++
> drivers/gpu/drm/msm/msm_mmu.h | 3 +
> 4 files changed, 186 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> index bd50674..e4554eb 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -13,6 +13,7 @@
>
> #include
> #include
> +#include
>
> #include "msm_gem.h"
> #include "msm_mmu.h"
> @@ -913,6 +914,154 @@ static irqreturn_t a6xx_irq(struct msm_gpu *gpu)
> ~0
> };
>
> +#define A6XX_LLC_NUM_GPU_SCIDS 5
> +#define A6XX_GPU_LLC_SCID_NUM_BITS 5
> +
> +#define A6XX_GPU_LLC_SCID_MASK \
> + ((1 << (A6XX_LLC_NUM_GPU_SCIDS * A6XX_GPU_LLC_SCID_NUM_BITS)) - 1)
> +
> +#define A6XX_GPUHTW_LLC_SCID_SHIFT 25
> +#define A6XX_GPUHTW_LLC_SCID_MASK \
> + (((1 << A6XX_GPU_LLC_SCID_NUM_BITS) - 1) << A6XX_GPUHTW_LLC_SCID_SHIFT)
> +
> +static inline void a6xx_gpu_cx_rmw(struct a6xx_llc *llc,
> + u32 reg, u32 mask, u32 or)
> +{
> + msm_rmw(llc->mmio + (reg << 2), mask, or);
> +}
> +
> +static void a6xx_llc_deactivate(struct msm_gpu *gpu)
> +{
> + struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
> + struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
> + struct a6xx_llc *llc = &a6xx_gpu->llc;
> +
> + llcc_slice_deactivate(llc->gpu_llc_slice);
> + llcc_slice_deactivate(llc->gpuhtw_llc_slice);
> +}
> +
> +static void a6xx_llc_activate(struct msm_gpu *gpu)
> +{
> + struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
> + struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
> + struct a6xx_llc *llc = &a6xx_gpu->llc;
> +
> + if (!llc->mmio)
> + return;
> +
> + if (llc->gpu_llc_slice)
> + if (!llcc_slice_activate(llc->gpu_llc_slice))
> + /* Program the sub-cache ID for all GPU blocks */
> + a6xx_gpu_cx_rmw(llc,
> + REG_A6XX_GPU_CX_MISC_SYSTEM_CACHE_CNTL_1,
> + A6XX_GPU_LLC_SCID_MASK,
> + (llc->cntl1_regval &
> + A6XX_GPU_LLC_SCID_MASK));
> +
> + if (llc->gpuhtw_llc_slice)
> + if (!llcc_slice_activate(llc->gpuhtw_llc_slice))
> + /* Program the sub-cache ID for GPU pagetables */
> + a6xx_gpu_cx_rmw(llc,
> + REG_A6XX_GPU_CX_MISC_SYSTEM_CACHE_CNTL_1,
> + A6XX_GPUHTW_LLC_SCID_MASK,
> + (llc->cntl1_regval &
> + A6XX_GPUHTW_LLC_SCID_MASK));
> +
> + /* Program cacheability overrides */
> + a6xx_gpu_cx_rmw(llc, REG_A6XX_GPU_CX_MISC_SYSTEM_CACHE_CNTL_0, 0xF,
> + llc->cntl0_regval);
> +}
> +
> +void a6xx_llc_slices_destroy(struct a6xx_llc *llc)
> +{
> + if (llc->mmio) {
> + iounmap(llc->mmio);
> + llc->mmio = NULL;
> + }
> +
> + llcc_slice_putd(llc->gpu_llc_slice);
> + llc->gpu_llc_slice = NULL;
> +
> + llcc_slice_putd(llc->gpuhtw_llc_slice);
> + llc->gpuhtw_llc_slice = NULL;
> +}
> +
> +static int a6xx_llc_slices_init(struct platform_device *pdev,
> + struct a6xx_llc *llc)
> +{
> + int i;
> +
> + /* Get the
Re: [Freedreno] [PATCH 4/5] drm/msm: Pass mmu features to generic layers
On Fri, Mar 23, 2018 at 12:49:50PM +0530, Sharat Masetty wrote:
> Allow different Adreno targets the ability to pass
> specific mmu features to the generic layers. This will
> help conditionally configure certain iommu features for
> certain Adreno targets.
>
> Also Add a few simple support functions to support a bitmask of
> features that a specific MMU implementation supports.
Reviewed-by: Jordan Crouse
> Signed-off-by: Sharat Masetty
> ---
> drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 2 +-
> drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 2 +-
> drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 2 +-
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 4 +++-
> drivers/gpu/drm/msm/adreno/adreno_gpu.h | 2 +-
> drivers/gpu/drm/msm/msm_gpu.c | 6 --
> drivers/gpu/drm/msm/msm_gpu.h | 1 +
> drivers/gpu/drm/msm/msm_mmu.h | 13 +
> 9 files changed, 26 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> index 1dd84d3..a7a8573 100644
> --- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> @@ -492,7 +492,7 @@ struct msm_gpu *a3xx_gpu_init(struct drm_device *dev)
> adreno_gpu->registers = a3xx_registers;
> adreno_gpu->reg_offsets = a3xx_register_offsets;
>
> - ret = adreno_gpu_init(dev, pdev, adreno_gpu, &funcs, 1);
> + ret = adreno_gpu_init(dev, pdev, adreno_gpu, &funcs, 1, 0);
> if (ret)
> goto fail;
>
> diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
> index 2884b1b..5e7e15d6 100644
> --- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
> @@ -574,7 +574,7 @@ struct msm_gpu *a4xx_gpu_init(struct drm_device *dev)
> adreno_gpu->registers = a4xx_registers;
> adreno_gpu->reg_offsets = a4xx_register_offsets;
>
> - ret = adreno_gpu_init(dev, pdev, adreno_gpu, &funcs, 1);
> + ret = adreno_gpu_init(dev, pdev, adreno_gpu, &funcs, 1, 0);
> if (ret)
> goto fail;
>
> diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> index a4f68af..c9e06ff 100644
> --- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> @@ -1295,7 +1295,7 @@ struct msm_gpu *a5xx_gpu_init(struct drm_device *dev)
>
> check_speed_bin(&pdev->dev);
>
> - ret = adreno_gpu_init(dev, pdev, adreno_gpu, &funcs, 4);
> + ret = adreno_gpu_init(dev, pdev, adreno_gpu, &funcs, 4, 0);
> if (ret) {
> a5xx_destroy(&(a5xx_gpu->base.base));
> return ERR_PTR(ret);
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> index e83b066..bd50674 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -1040,7 +1040,7 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev)
> adreno_gpu->registers = a6xx_registers;
> adreno_gpu->reg_offsets = a6xx_register_offsets;
>
> - ret = adreno_gpu_init(dev, pdev, adreno_gpu, &funcs, 4);
> + ret = adreno_gpu_init(dev, pdev, adreno_gpu, &funcs, 4, 0);
> if (ret) {
> a6xx_destroy(&(a6xx_gpu->base.base));
> return ERR_PTR(ret);
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index 6657461..a87ec6b 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -557,7 +557,8 @@ static int adreno_get_pwrlevels(struct device *dev,
>
> int adreno_gpu_init(struct drm_device *drm, struct platform_device *pdev,
> struct adreno_gpu *adreno_gpu,
> - const struct adreno_gpu_funcs *funcs, int nr_rings)
> + const struct adreno_gpu_funcs *funcs, int nr_rings,
> + unsigned long mmu_features)
> {
> struct adreno_platform_config *config = pdev->dev.platform_data;
> struct msm_gpu_config adreno_gpu_config = { 0 };
> @@ -576,6 +577,7 @@ int adreno_gpu_init(struct drm_device *drm, struct
> platform_device *pdev,
> adreno_gpu_config.va_end = 0x;
>
> adreno_gpu_config.nr_rings = nr_rings;
> + adreno_gpu_config.mmu_features = mmu_features;
>
> adreno_get_pwrlevels(&pdev->dev, gpu);
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> index bb9affd..19eda65 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> @@ -225,7 +225,7 @@ void adreno_submit(struct msm_gpu *gpu, struct
> msm_gem_submit *submit,
>
> int adreno_gpu_init(struct drm_device *drm, struct platform_device *pdev,
> struct adreno_gpu *gpu, const struct adreno_gpu_funcs *funcs,
> - int nr_rings);
> + int nr_rings, unsigned
Re: [Freedreno] [PATCH 3/5] drm/msm/adreno: Add registers in the GPU CX domain
On Fri, Mar 23, 2018 at 12:49:49PM +0530, Sharat Masetty wrote: > Add the registers needed for configuring the system cache slice info and > other parameters in the GPU. > Reviewed-by: Jordan Crouse > Signed-off-by: Sharat Masetty > --- > drivers/gpu/drm/msm/adreno/a6xx.xml.h | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/msm/adreno/a6xx.xml.h > b/drivers/gpu/drm/msm/adreno/a6xx.xml.h > index 17d1241..29ce813 100644 > --- a/drivers/gpu/drm/msm/adreno/a6xx.xml.h > +++ b/drivers/gpu/drm/msm/adreno/a6xx.xml.h > @@ -1596,5 +1596,9 @@ static inline uint32_t > A6XX_CP_PROTECT_REG_MASK_LEN(uint32_t val) > > #define REG_A6XX_PDC_GPU_SEQ_MEM_0 0x000a > > +#define REG_A6XX_GPU_CX_MISC_SYSTEM_CACHE_CNTL_0 0x0001 > + > +#define REG_A6XX_GPU_CX_MISC_SYSTEM_CACHE_CNTL_1 0x0002 > + > > #endif /* A6XX_XML */ > -- > 1.9.1 > > ___ > Freedreno mailing list > freedr...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/freedreno -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH 2/5] arm64:dts:sdm845: Add support for GPU LLCC
On Fri, Mar 23, 2018 at 12:49:48PM +0530, Sharat Masetty wrote: > Add client side bindings required for the GPU to use the last level > system cache. Also add a register range in the GPU CX domain. Reviewed-by: Jordan Crouse Also, these should go the the devicetree lists for review (but maybe wait until the other changes have gotten further through the process). > Signed-off-by: Sharat Masetty > --- > arch/arm64/boot/dts/qcom/sdm845.dtsi | 8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi > b/arch/arm64/boot/dts/qcom/sdm845.dtsi > index eb0a1b2..7e2d938 100644 > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi > @@ -887,8 +887,8 @@ > compatible = "qcom,adreno-630.2", "qcom,adreno"; > #stream-id-cells = <16>; > > - reg = <0x500 0x4>; > - reg-names = "kgsl_3d0_reg_memory"; > + reg = <0x500 0x4>, <0x509e000 0x10>; > + reg-names = "kgsl_3d0_reg_memory", "cx_mem"; > > /* >* Look ma, no clocks! The GPU clocks and power are controlled > @@ -898,6 +898,10 @@ > interrupts = <0 300 0>; > interrupt-names = "kgsl_3d0_irq"; > > + /* GPU related llc slices */ > + cache-slice-names = "gpu", "gpuhtw"; > + cache-slices = <&llcc 12>, <&llcc 11>; > + > iommus = <&kgsl_smmu 0>; > > operating-points-v2 = <&gpu_opp_table>; > -- > 1.9.1 > > ___ > Freedreno mailing list > freedr...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/freedreno -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v3 08/40] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session
Hi Ramalingam,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20180403]
[cannot apply to v4.16]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Ramalingam-C/drm-i915-Implement-HDCP2-2/20180404-031743
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
>> drivers/misc/mei/hdcp/mei_hdcp.c:52:5: error: redefinition of
>> 'mei_initiate_hdcp2_session'
int mei_initiate_hdcp2_session(struct mei_cl_device *cldev,
^~
In file included from drivers/misc/mei/hdcp/mei_hdcp.c:35:0:
include/linux/mei_hdcp.h:122:5: note: previous definition of
'mei_initiate_hdcp2_session' was here
int mei_initiate_hdcp2_session(struct mei_cl_device *cldev,
^~
drivers/misc/mei/hdcp/mei_hdcp.c:117:5: error: redefinition of
'mei_cldev_register_notify'
int mei_cldev_register_notify(struct notifier_block *nb)
^
In file included from drivers/misc/mei/hdcp/mei_hdcp.c:35:0:
include/linux/mei_hdcp.h:113:12: note: previous definition of
'mei_cldev_register_notify' was here
static int mei_cldev_register_notify(struct notifier_block *nb)
^
drivers/misc/mei/hdcp/mei_hdcp.c:123:5: error: redefinition of
'mei_cldev_unregister_notify'
int mei_cldev_unregister_notify(struct notifier_block *nb)
^~~
In file included from drivers/misc/mei/hdcp/mei_hdcp.c:35:0:
include/linux/mei_hdcp.h:117:12: note: previous definition of
'mei_cldev_unregister_notify' was here
static int mei_cldev_unregister_notify(struct notifier_block *nb)
^~~
include/linux/mei_hdcp.h:117:12: warning: 'mei_cldev_unregister_notify'
defined but not used [-Wunused-function]
include/linux/mei_hdcp.h:113:12: warning: 'mei_cldev_register_notify'
defined but not used [-Wunused-function]
static int mei_cldev_register_notify(struct notifier_block *nb)
^
vim +/mei_initiate_hdcp2_session +52 drivers/misc/mei/hdcp/mei_hdcp.c
41
42 /**
43 * mei_initiate_hdcp2_session:
44 * Function to start a Wired HDCP2.2 Tx Session with ME FW
45 *
46 * @cldev : Pointer for mei client device
47 * @data: Intel HW specific Data
48 * @ake_data: ptr to store AKE_Init
49 *
50 * Returns 0 on Success, <0 on Failure.
51 */
> 52 int mei_initiate_hdcp2_session(struct mei_cl_device *cldev,
53 struct mei_hdcp_data *data,
54 struct hdcp2_ake_init *ake_data)
55 {
56 struct wired_cmd_initiate_hdcp2_session_in session_init_in = {
{ 0 } };
57 struct wired_cmd_initiate_hdcp2_session_out
58 session_init_out = { {
0 } };
59 struct device *dev;
60 ssize_t byte;
61
62 if (!data || !ake_data)
63 return -EINVAL;
64
65 dev = &cldev->dev;
66
67 session_init_in.header.api_version = HDCP_API_VERSION;
68 session_init_in.header.command_id =
WIRED_INITIATE_HDCP2_SESSION;
69 session_init_in.header.status = ME_HDCP_STATUS_SUCCESS;
70 session_init_in.header.buffer_len =
71
WIRED_CMD_BUF_LEN_INITIATE_HDCP2_SESSION_IN;
72
73 session_init_in.port.integrated_port_type = data->port_type;
74 session_init_in.port.physical_port = data->port;
75 session_init_in.protocol = (uint8_t)data->protocol;
76
77 byte = mei_cldev_send(cldev, (u8 *)&session_init_in,
78sizeof(session_init_in));
79 if (byte < 0) {
80 dev_dbg(dev, "mei_cldev_send failed. %d\n", (int)byte);
81 return byte;
82 }
83
84 byte = mei_cldev_recv(cldev, (u8 *)&session_init_out,
85sizeof(session_init_out));
86 if (byte < 0) {
87 dev_dbg(dev, "mei_cldev_recv failed. %d\n", (int)byte);
88 return byte;
89 }
90
91 if (session_init_out.header.status != ME_HDCP_STATUS_SU
Re: [Freedreno] [PATCH 1/5] drm/msm: rearrange the gpu_rmw() function
On Fri, Mar 23, 2018 at 12:49:47PM +0530, Sharat Masetty wrote:
> The register read-modify-write construct is generic enough
> that it can be used by other subsystems as needed, create
> a more generic rmw() function and have the gpu_rmw() use
> this new function.
Reviewed-by: Jordan Crouse
> Signed-off-by: Sharat Masetty
> ---
> drivers/gpu/drm/msm/msm_drv.c | 8
> drivers/gpu/drm/msm/msm_drv.h | 1 +
> drivers/gpu/drm/msm/msm_gpu.h | 5 +
> 3 files changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index fbad854..a08b7d2 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -149,6 +149,14 @@ u32 msm_readl(const void __iomem *addr)
> return val;
> }
>
> +void msm_rmw(void __iomem *addr, u32 mask, u32 or)
> +{
> + u32 val = msm_readl(addr);
> +
> + val &= ~mask;
> + msm_writel(val | or, addr);
> +}
> +
> struct vblank_event {
> struct list_head node;
> int crtc_id;
> diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
> index 0a653dd..7e71354 100644
> --- a/drivers/gpu/drm/msm/msm_drv.h
> +++ b/drivers/gpu/drm/msm/msm_drv.h
> @@ -314,6 +314,7 @@ void __iomem *msm_ioremap(struct platform_device *pdev,
> const char *name,
> const char *dbgname);
> void msm_writel(u32 data, void __iomem *addr);
> u32 msm_readl(const void __iomem *addr);
> +void msm_rmw(void __iomem *addr, u32 mask, u32 or);
>
> struct msm_gpu_submitqueue;
> int msm_submitqueue_init(struct drm_device *drm, struct msm_file_private
> *ctx);
> diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
> index b9b86ef..96058d2 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.h
> +++ b/drivers/gpu/drm/msm/msm_gpu.h
> @@ -194,10 +194,7 @@ static inline u32 gpu_read(struct msm_gpu *gpu, u32 reg)
>
> static inline void gpu_rmw(struct msm_gpu *gpu, u32 reg, u32 mask, u32 or)
> {
> - uint32_t val = gpu_read(gpu, reg);
> -
> - val &= ~mask;
> - gpu_write(gpu, reg, val | or);
> + msm_rmw(gpu->mmio + (reg << 2), mask, or);
> }
>
> static inline u64 gpu_read64(struct msm_gpu *gpu, u32 lo, u32 hi)
> --
> 1.9.1
>
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH 4/4] drm/msm/A6xx: Enable preemption for A6xx targets
On Mon, Feb 26, 2018 at 01:08:23PM +0530, Sharat Masetty wrote:
> This patch simply increases the number of available ringbuffers,
> therefore enabling preemption.
>
Reviewed-by: Jordan Crouse
> Signed-off-by: Sharat Masetty
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> index b1a80ec..e83b066 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -1040,7 +1040,7 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev)
> adreno_gpu->registers = a6xx_registers;
> adreno_gpu->reg_offsets = a6xx_register_offsets;
>
> - ret = adreno_gpu_init(dev, pdev, adreno_gpu, &funcs, 1);
> + ret = adreno_gpu_init(dev, pdev, adreno_gpu, &funcs, 4);
> if (ret) {
> a6xx_destroy(&(a6xx_gpu->base.base));
> return ERR_PTR(ret);
> --
> 1.9.1
>
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH 3/4] drm/msm/A6xx: Implement preemption for A6XX targets
On Mon, Feb 26, 2018 at 01:08:22PM +0530, Sharat Masetty wrote:
> This patch implements preemption feature for A6xx targets, this allows
> the GPU to switch to a higher priority ringbuffer if one is ready. A6XX
> hardware as such supports multiple levels of preemption granularities,
> ranging from coarse grained(ringbuffer level) to a more fine grained
> such as draw-call level or a bin boundary level preemption. This patch
> enables the basic preemption level, with more fine grained preemption
> support to follow.
Reviewed-by: Jordan Crouse
> Signed-off-by: Sharat Masetty
> ---
> drivers/gpu/drm/msm/Makefile | 1 +
> drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 44
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 146 +++-
> drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 136 +++
> drivers/gpu/drm/msm/adreno/a6xx_preempt.c | 383
> ++
> 5 files changed, 708 insertions(+), 2 deletions(-)
> create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_preempt.c
>
> diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
> index 0b6e150..1978312 100644
> --- a/drivers/gpu/drm/msm/Makefile
> +++ b/drivers/gpu/drm/msm/Makefile
> @@ -13,6 +13,7 @@ msm-y := \
> adreno/a6xx_gpu.o \
> adreno/a6xx_gmu.o \
> adreno/a6xx_hfi.o \
> + adreno/a6xx_preempt.o \
> hdmi/hdmi.o \
> hdmi/hdmi_audio.o \
> hdmi/hdmi_bridge.o \
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> index 8d732e0..5c2a68a 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> @@ -1145,6 +1145,50 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu)
> iommu_domain_free(gmu->domain);
> }
>
> +#define A6XX_GMU_FENCED_WRITE_SLEEP_US 10 /* Sleep time between reads in us
> */
> +#define A6XX_GMU_FENCED_WRITE_TIMEOUT 600 /* Timeout in us */
> +int a6xx_gmu_fenced_write(struct a6xx_gpu *a6xx_gpu, unsigned int reg,
> + unsigned int value, unsigned int fence_mask)
> +{
> + struct a6xx_gmu *gmu = &a6xx_gpu->gmu;
> + struct adreno_gpu *adreno_gpu = &a6xx_gpu->base;
> + struct msm_gpu *gpu = &adreno_gpu->base;
> + unsigned int status;
> + ktime_t timeout = ktime_add_us(ktime_get(),
> + A6XX_GMU_FENCED_WRITE_TIMEOUT);
> +
> + /* Write to the GPU register */
> + gpu_write(gpu, reg, value);
> +
> + might_sleep_if(A6XX_GMU_FENCED_WRITE_SLEEP_US);
> + for (;;) {
> + status = gmu_read(gmu, REG_A6XX_GMU_AHB_FENCE_STATUS);
> + /*
> + * If no bits of the fence_mask are set in the status, then the
> + * write was successful
> + */
> + if (!(status & fence_mask))
> + return 0;
> +
> + if (ktime_compare(ktime_get(), timeout) > 0) {
> + /* Timed out, but check one last time */
> + status = gmu_read(gmu, REG_A6XX_GMU_AHB_FENCE_STATUS);
> + if (!(status & fence_mask))
> + return 0;
> +
> + break;
> + }
> +
> + usleep_range((A6XX_GMU_FENCED_WRITE_SLEEP_US >> 2) + 1,
> + A6XX_GMU_FENCED_WRITE_SLEEP_US);
> +
> + /* Try writing again */
> + gpu_write(gpu, reg, value);
> + }
> +
> + return -ETIMEDOUT;
> +}
> +
> int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct device_node *node)
> {
> struct a6xx_gmu *gmu = &a6xx_gpu->gmu;
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> index c72434b..b1a80ec 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -151,6 +151,8 @@ bool a6xx_idle(struct msm_gpu *gpu, struct msm_ringbuffer
> *ring)
>
> static void a6xx_flush(struct msm_gpu *gpu, struct msm_ringbuffer *ring)
> {
> + struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
> + struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
> uint32_t wptr;
> unsigned long flags;
>
> @@ -167,16 +169,52 @@ static void a6xx_flush(struct msm_gpu *gpu, struct
> msm_ringbuffer *ring)
> /* Make sure everything is posted before making a decision */
> mb();
>
> - gpu_write(gpu, REG_A6XX_CP_RB_WPTR, wptr);
> + /* Update HW if this is the current ring and we are not in preempt*/
> + if (a6xx_gpu->cur_ring == ring && !a6xx_in_preempt(a6xx_gpu))
> + gpu_write(gpu, REG_A6XX_CP_RB_WPTR, wptr);
> }
>
> static void a6xx_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit,
> struct msm_file_private *ctx)
> {
> + struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
> + struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
> struct msm_drm_private *priv = gpu->dev->dev_private;
> struct msm_ringbuffer *ring = submit->ring;
> + uint64_t scrat
Re: [Freedreno] [PATCH 2/4] drm/msm: Add new PM4 type7 opcodes
On Mon, Feb 26, 2018 at 01:08:21PM +0530, Sharat Masetty wrote:
> This patch adds the following two opcodes:
>
> CP_SET_MARKER opcode is a way to tell CP the current mode of GPU
> operation(useful if preemption is in use).
>
> CP_SET_PSEUDO_REG opcode will instruct CP to set a bunch of internal
> CP registers, again useful for the preemption save/restore sequence.
>
Reviewed-by: Jordan Crouse
> Signed-off-by: Sharat Masetty
> ---
> drivers/gpu/drm/msm/adreno/adreno_pm4.xml.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_pm4.xml.h
> b/drivers/gpu/drm/msm/adreno/adreno_pm4.xml.h
> index fb605a3..f0fd80e 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_pm4.xml.h
> +++ b/drivers/gpu/drm/msm/adreno/adreno_pm4.xml.h
> @@ -202,6 +202,8 @@ enum adreno_pm4_type3_packets {
> CP_EXEC_CS = 51,
> CP_PERFCOUNTER_ACTION = 80,
> CP_SMMU_TABLE_UPDATE = 83,
> + CP_SET_MARKER = 101,
> + CP_SET_PSEUDO_REG = 86,
> CP_CONTEXT_REG_BUNCH = 92,
> CP_YIELD_ENABLE = 28,
> CP_SKIP_IB2_ENABLE_GLOBAL = 29,
> --
> 1.9.1
>
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH 1/4] drm/msm: Add submitqueue setup and close
On Mon, Feb 26, 2018 at 01:08:20PM +0530, Sharat Masetty wrote:
> This patch adds a bit of infrastructure to give the different Adreno
> targets the flexibility to setup the submitqueues per their needs.
Reviewed-by: Jordan Crouse
> Signed-off-by: Sharat Masetty
> ---
> drivers/gpu/drm/msm/msm_gpu.h | 7 +++
> drivers/gpu/drm/msm/msm_submitqueue.c | 15 +--
> 2 files changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
> index b824117..b9b86ef 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.h
> +++ b/drivers/gpu/drm/msm/msm_gpu.h
> @@ -69,6 +69,10 @@ struct msm_gpu_funcs {
> int (*debugfs_init)(struct msm_gpu *gpu, struct drm_minor *minor);
> #endif
> int (*gpu_busy)(struct msm_gpu *gpu, uint64_t *value);
> + int (*submitqueue_setup)(struct msm_gpu *gpu,
> + struct msm_gpu_submitqueue *queue);
> + void (*submitqueue_close)(struct msm_gpu *gpu,
> + struct msm_gpu_submitqueue *queue);
> };
>
> struct msm_gpu {
> @@ -173,6 +177,9 @@ struct msm_gpu_submitqueue {
> int faults;
> struct list_head node;
> struct kref ref;
> + struct msm_gpu *gpu;
> + struct drm_gem_object *bo;
> + uint64_t bo_iova;
> };
>
> static inline void gpu_write(struct msm_gpu *gpu, u32 reg, u32 data)
> diff --git a/drivers/gpu/drm/msm/msm_submitqueue.c
> b/drivers/gpu/drm/msm/msm_submitqueue.c
> index 5115f75..1e696da 100644
> --- a/drivers/gpu/drm/msm/msm_submitqueue.c
> +++ b/drivers/gpu/drm/msm/msm_submitqueue.c
> @@ -18,6 +18,10 @@ void msm_submitqueue_destroy(struct kref *kref)
> {
> struct msm_gpu_submitqueue *queue = container_of(kref,
> struct msm_gpu_submitqueue, ref);
> + struct msm_gpu *gpu = queue->gpu;
> +
> + if (gpu && gpu->funcs->submitqueue_close)
> + gpu->funcs->submitqueue_close(gpu, queue);
>
> kfree(queue);
> }
> @@ -65,6 +69,7 @@ int msm_submitqueue_create(struct drm_device *drm, struct
> msm_file_private *ctx,
> {
> struct msm_drm_private *priv = drm->dev_private;
> struct msm_gpu_submitqueue *queue;
> + struct msm_gpu *gpu = priv->gpu;
>
> if (!ctx)
> return -ENODEV;
> @@ -77,11 +82,14 @@ int msm_submitqueue_create(struct drm_device *drm, struct
> msm_file_private *ctx,
> kref_init(&queue->ref);
> queue->flags = flags;
>
> - if (priv->gpu) {
> - if (prio >= priv->gpu->nr_rings)
> + if (gpu) {
> + if (prio >= gpu->nr_rings) {
> + kfree(queue);
> return -EINVAL;
> + }
>
> queue->prio = prio;
> + queue->gpu = gpu;
> }
>
> write_lock(&ctx->queuelock);
> @@ -95,6 +103,9 @@ int msm_submitqueue_create(struct drm_device *drm, struct
> msm_file_private *ctx,
>
> write_unlock(&ctx->queuelock);
>
> + if (gpu && gpu->funcs->submitqueue_setup)
> + gpu->funcs->submitqueue_setup(gpu, queue);
> +
> return 0;
> }
>
> --
> 1.9.1
>
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 37/40] drm/i915: Implement the HDCP2.2 support for DP
Hi Ramalingam,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20180403]
[cannot apply to v4.16]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Ramalingam-C/drm-i915-Implement-HDCP2-2/20180404-031743
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-a1-201813 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
drivers/gpu//drm/i915/intel_dp.c: In function
'intel_dp_hdcp2_read_rx_status':
>> drivers/gpu//drm/i915/intel_dp.c:5377:3: warning: format '%ld' expects
>> argument of type 'long int', but argument 2 has type 'ssize_t' [-Wformat=]
DRM_ERROR("Read bstatus from DP/AUX failed (%ld)\n", ret);
^
In file included from drivers/gpu//drm/i915/intel_dp.c:34:0:
drivers/gpu//drm/i915/intel_dp.c: At top level:
include/linux/mei_hdcp.h:144:12: warning: 'mei_cldev_register_notify'
defined but not used [-Wunused-function]
static int mei_cldev_register_notify(struct notifier_block *nb)
^
include/linux/mei_hdcp.h:148:12: warning: 'mei_cldev_unregister_notify'
defined but not used [-Wunused-function]
static int mei_cldev_unregister_notify(struct notifier_block *nb)
^
Cyclomatic Complexity 5 include/linux/compiler.h:__read_once_size
Cyclomatic Complexity 5 include/linux/compiler.h:__write_once_size
Cyclomatic Complexity 3 include/linux/string.h:memset
Cyclomatic Complexity 4 include/linux/string.h:memcpy
Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:ffs
Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:fls
Cyclomatic Complexity 1 include/linux/log2.h:__ilog2_u32
Cyclomatic Complexity 3 include/linux/log2.h:is_power_of_2
Cyclomatic Complexity 1 include/linux/list.h:INIT_LIST_HEAD
Cyclomatic Complexity 1 include/linux/err.h:ERR_PTR
Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:atomic_read
Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:atomic_set
Cyclomatic Complexity 1 include/asm-generic/atomic-long.h:atomic_long_read
Cyclomatic Complexity 1 include/asm-generic/getorder.h:__get_order
Cyclomatic Complexity 1 include/linux/mutex.h:__mutex_owner
Cyclomatic Complexity 1 include/linux/mutex.h:mutex_is_locked
Cyclomatic Complexity 1 include/linux/jiffies.h:_msecs_to_jiffies
Cyclomatic Complexity 3 include/linux/jiffies.h:msecs_to_jiffies
Cyclomatic Complexity 1 include/linux/jiffies.h:_usecs_to_jiffies
Cyclomatic Complexity 3 include/linux/jiffies.h:usecs_to_jiffies
Cyclomatic Complexity 1 include/linux/kasan.h:kasan_kmalloc
Cyclomatic Complexity 28 include/linux/slab.h:kmalloc_index
Cyclomatic Complexity 1 include/linux/slab.h:kmem_cache_alloc_trace
Cyclomatic Complexity 1 include/linux/slab.h:kmalloc_order_trace
Cyclomatic Complexity 67 include/linux/slab.h:kmalloc_large
Cyclomatic Complexity 5 include/linux/slab.h:kmalloc
Cyclomatic Complexity 1 include/linux/slab.h:kzalloc
Cyclomatic Complexity 1 include/linux/ww_mutex.h:ww_mutex_is_locked
Cyclomatic Complexity 1 include/drm/drm_modeset_lock.h:drm_modeset_is_locked
Cyclomatic Complexity 1
include/drm/drm_modeset_helper_vtables.h:drm_connector_helper_add
Cyclomatic Complexity 1 include/drm/drm_dp_helper.h:drm_dp_max_lane_count
Cyclomatic Complexity 3 include/drm/drm_dp_helper.h:drm_dp_enhanced_frame_cap
Cyclomatic Complexity 1 include/drm/drm_dp_helper.h:drm_dp_is_branch
Cyclomatic Complexity 1 include/drm/drm_dp_helper.h:drm_dp_has_quirk
Cyclomatic Complexity 1 drivers/gpu//drm/i915/i915_reg.h:i915_mmio_reg_offset
Cyclomatic Complexity 1 drivers/gpu//drm/i915/i915_reg.h:i915_mmio_reg_equal
Cyclomatic Complexity 1 drivers/gpu//drm/i915/i915_reg.h:i915_mmio_reg_valid
Cyclomatic Complexity 2 drivers/gpu//drm/i915/i915_utils.h:onoff
Cyclomatic Complexity 1 drivers/gpu//drm/i915/i915_drv.h:intel_info
Cyclomatic Complexity 1
drivers/gpu//drm/i915/i915_drv.h:msecs_to_jiffies_timeout
Cyclomatic Complexity 1
drivers/gpu//drm/i915/intel_drv.h:intel_get_crtc_for_pipe
Cyclomatic Complexity 1 drivers/gpu//drm/i915/intel_drv.h:intel_crtc_has_type
Cyclomatic Complexity 1
drivers/gpu//drm/i915/intel_drv.h:intel_crtc_has_dp_encoder
Cyclomatic Complexity 1
drivers/gpu//drm/i915/intel_drv.h:intel_dp_unused_lane_mask
Cyclomatic Complexity 3
drivers/gpu//drm/i915/intel_dp.c:intel_dp_rate_limit_len
Cyclomatic Complexity 1
drivers/gpu//drm/i915/intel_dp.c:intel_dp_common_len_rate_limit
Cyclomatic Complexity 1
drivers/gpu//drm/i915/intel_dp.c:intel_dp_max_common_rate
Cyclomatic Complexity 3
Re: [PATCH v2 2/2] drm/omap: partial workaround for DRA7xx DMM errata i878
Hi Peter,
Thank you for the patch.
On Thursday, 22 March 2018 15:42:06 EEST Peter Ujfalusi wrote:
> From: Tomi Valkeinen
>
> Errata i878 says that MPU should not be used to access RAM and DMM at
> the same time. As it's not possible to prevent MPU accessing RAM, we
> need to access DMM via a proxy.
>
> This patch changes DMM driver to access DMM registers via sDMA. Instead
> of doing a normal readl/writel call to read/write a register, we use
> sDMA to copy 4 bytes from/to the DMM registers.
>
> This patch provides only a partial workaround for i878, as not only DMM
> register reads/writes are affected, but also accesses to the DMM mapped
> buffers (framebuffers, usually).
I assume access to DMM-mapped buffers to be way more frequent than access to
the DMM registers. If that's the case, this partial workaround should only
slightly lower the probability of system lock-up. Do you have plans to
implement a workaround that will fix the problem completely ?
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/gpu/drm/omapdrm/omap_dmm_priv.h | 8 ++
> drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 153 +++-
> 2 files changed, 159 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
> b/drivers/gpu/drm/omapdrm/omap_dmm_priv.h index c2785cc98dc9..9ce9d1d7039a
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
> +++ b/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
> @@ -155,10 +155,12 @@ struct refill_engine {
>
> struct dmm_platform_data {
> u32 cpu_cache_flags;
> + bool errata_i878_wa;
> };
>
> struct dmm {
> struct device *dev;
> + dma_addr_t phys_base;
> void __iomem *base;
> int irq;
>
> @@ -189,6 +191,12 @@ struct dmm {
> struct list_head alloc_head;
>
> const struct dmm_platform_data *plat_data;
> +
> + bool dmm_workaround;
> + spinlock_t wa_lock;
> + u32 *wa_dma_data;
> + dma_addr_t wa_dma_handle;
> + struct dma_chan *wa_dma_chan;
> };
>
> #endif
> diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c index e84871e74615..27c67bc36203
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> +++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> @@ -18,6 +18,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -79,14 +80,138 @@ static const u32 reg[][4] = {
> DMM_PAT_DESCR__2, DMM_PAT_DESCR__3},
> };
>
> +static int dmm_dma_copy(struct dmm *dmm, dma_addr_t src, dma_addr_t dst)
> +{
> + struct dma_device *dma_dev = dmm->wa_dma_chan->device;
> + struct dma_async_tx_descriptor *tx;
> + enum dma_status status;
> + dma_cookie_t cookie;
> +
> + tx = dma_dev->device_prep_dma_memcpy(dmm->wa_dma_chan, dst, src, 4, 0);
> + if (!tx) {
> + dev_err(dmm->dev, "Failed to prepare DMA memcpy\n");
> + return -EIO;
> + }
> +
> + cookie = tx->tx_submit(tx);
> + if (dma_submit_error(cookie)) {
> + dev_err(dmm->dev, "Failed to do DMA tx_submit\n");
> + return -EIO;
> + }
> +
> + dma_async_issue_pending(dmm->wa_dma_chan);
> + status = dma_sync_wait(dmm->wa_dma_chan, cookie);
dma_sync_wait() has a 5s timeout. You're calling this function with a spinlock
held. The end result might be slightly better than a complete system lock as
caused by the bug described in i878, but only slightly.
Unless I'm mistaken the reason you can't sleep here is because of the need to
access registers in the interrupt handler. Could we use threaded IRQs to solve
this ?
> + if (status != DMA_COMPLETE)
> + dev_err(dmm->dev, "i878 wa DMA copy failure\n");
> +
> + dmaengine_terminate_all(dmm->wa_dma_chan);
> + return 0;
> +}
> +
> +static u32 dmm_read_wa(struct dmm *dmm, u32 reg)
> +{
> + dma_addr_t src, dst;
> + int r;
> +
> + src = dmm->phys_base + reg;
> + dst = dmm->wa_dma_handle;
> +
> + r = dmm_dma_copy(dmm, src, dst);
> + if (r) {
> + dev_err(dmm->dev, "sDMA read transfer timeout\n");
> + return readl(dmm->base + reg);
> + }
> +
> + /*
> + * As per i878 workaround, the DMA is used to access the DMM registers.
> + * Make sure that the readl is not moved by the compiler or the CPU
> + * earlier than the DMA finished writing the value to memory.
> + */
> + rmb();
> + return readl(dmm->wa_dma_data);
> +}
> +
> +static void dmm_write_wa(struct dmm *dmm, u32 val, u32 reg)
> +{
> + dma_addr_t src, dst;
> + int r;
> +
> + writel(val, dmm->wa_dma_data);
> + /*
> + * As per i878 workaround, the DMA is used to access the DMM registers.
> + * Make sure that the writel is not moved by the compiler or the CPU, so
> + * the data will be in place before we start the DMA to do the actual
> + * register write.
> + */
> + wmb();
> +
> + src = dmm->wa_dma_handle;
> +
[Bug 105869] clang crashes when compiling OpenCL kernel
https://bugs.freedesktop.org/show_bug.cgi?id=105869 Vedran Miletić changed: What|Removed |Added Blocks||99553 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=99553 [Bug 99553] Tracker bug for runnning OpenCL applications on Clover -- 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 99553] Tracker bug for runnning OpenCL applications on Clover
https://bugs.freedesktop.org/show_bug.cgi?id=99553 Vedran Miletić changed: What|Removed |Added Depends on||105869 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=105869 [Bug 105869] clang crashes when compiling OpenCL kernel -- 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 105869] clang crashes when compiling OpenCL kernel
https://bugs.freedesktop.org/show_bug.cgi?id=105869
Bug ID: 105869
Summary: clang crashes when compiling OpenCL kernel
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/Gallium/radeonsi
Assignee: dri-devel@lists.freedesktop.org
Reporter: ved...@miletic.net
QA Contact: dri-devel@lists.freedesktop.org
(from #radeon and https://paste.debian.net/1018363/)
When compiling the following OpenCL kernel
kernel void PulseWave(global float* buffer, size_t num_harmonics,
float duty_cycle)
{
size_t index = get_global_id(0);
float phase = buffer[index];
float sample = duty_cycle;
float precompute1 = (phase - duty_cycle / 2.0) * 2.0 * M_PI;
for (size_t i = 1; i <= num_harmonics; ++i)
{
float harmonic = 2.0 / (i * M_PI) * sin(M_PI * i * duty_cycle)
*
cos(i * precompute1);
sample += harmonic;
}
buffer[index] = sample * 2.0 - 1.0;
}
Clang will crash with
Thread 1 "ftz_chiptune_pu" received signal SIGSEGV, Segmentation fault.
0x7fffe6501ba1 in llvm::LiveRange::find(llvm::SlotIndex) () from
/usr/lib/x86_64-linux-gnu/libLLVM-5.0.so.1
(gdb) bt
#0 0x7fffe6501ba1 in llvm::LiveRange::find(llvm::SlotIndex) () from
/usr/lib/x86_64-linux-gnu/libLLVM-5.0.so.1
#1 0x7fffe66674a1 in ?? () from /usr/lib/x86_64-linux-gnu/libLLVM-5.0.so.1
#2 0x7fffe66676c1 in ?? () from /usr/lib/x86_64-linux-gnu/libLLVM-5.0.so.1
#3 0x7fffe66697e5 in llvm::RegPressureTracker::getLiveThroughAt(unsigned
int, llvm::SlotIndex) const () from /usr/lib/x86_64-linux-gnu/libLLVM-5.0.so.1
#4 0x7fffe6669af1 in
llvm::RegPressureTracker::recede(llvm::RegisterOperands const&,
llvm::SmallVectorImpl*) ()
from /usr/lib/x86_64-linux-gnu/libLLVM-5.0.so.1
#5 0x7fffe66a0229 in
llvm::ScheduleDAGInstrs::buildSchedGraph(llvm::AAResults*,
llvm::RegPressureTracker*, llvm::PressureDiffs*, llvm::LiveIntervals*, bool) ()
from /usr/lib/x86_64-linux-gnu/libLLVM-5.0.so.1
#6 0x7fffe65e7653 in llvm::ScheduleDAGMILive::buildDAGWithRegPressure() ()
from /usr/lib/x86_64-linux-gnu/libLLVM-5.0.so.1
#7 0x7fffe65e76b9 in llvm::ScheduleDAGMILive::schedule() () from
/usr/lib/x86_64-linux-gnu/libLLVM-5.0.so.1
#8 0x7fffe758e501 in llvm::GCNScheduleDAGMILive::schedule() () from
/usr/lib/x86_64-linux-gnu/libLLVM-5.0.so.1
#9 0x7fffe758e26e in llvm::GCNScheduleDAGMILive::finalizeSchedule() ()
from /usr/lib/x86_64-linux-gnu/libLLVM-5.0.so.1
#10 0x7fffe65e6fa7 in ?? () from /usr/lib/x86_64-linux-gnu/libLLVM-5.0.so.1
#11 0x7fffe657cae0 in
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) () from
/usr/lib/x86_64-linux-gnu/libLLVM-5.0.so.1
#12 0x7fffe63deac8 in llvm::FPPassManager::runOnFunction(llvm::Function&)
() from /usr/lib/x86_64-linux-gnu/libLLVM-5.0.so.1
#13 0x7fffe6fb7b50 in ?? () from /usr/lib/x86_64-linux-gnu/libLLVM-5.0.so.1
#14 0x7fffe63de3af in llvm::legacy::PassManagerImpl::run(llvm::Module&) ()
from /usr/lib/x86_64-linux-gnu/libLLVM-5.0.so.1
#15 0x742227ce in ?? () from
/usr/lib/x86_64-linux-gnu/libMesaOpenCL.so.1
#16 0x74222ed0 in ?? () from
/usr/lib/x86_64-linux-gnu/libMesaOpenCL.so.1
#17 0x7421e6a7 in ?? () from
/usr/lib/x86_64-linux-gnu/libMesaOpenCL.so.1
#18 0x7420fea1 in ?? () from
/usr/lib/x86_64-linux-gnu/libMesaOpenCL.so.1
#19 0x741efe02 in ?? () from
/usr/lib/x86_64-linux-gnu/libMesaOpenCL.so.1
#20 0x55561129 in cl::Program::build (this=0x7fffde10, options=0x0,
notifyFptr=0x0, data=0x0) at /usr/include/CL/cl2.hpp:6321
--
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 v3 05/40] misc/mei/hdcp: Notifier chain for mei cldev state change
Hi Ramalingam,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20180403]
[cannot apply to v4.16]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Ramalingam-C/drm-i915-Implement-HDCP2-2/20180404-031743
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
>> drivers/misc/mei/hdcp/mei_hdcp.c:49:5: error: redefinition of
>> 'mei_cldev_register_notify'
int mei_cldev_register_notify(struct notifier_block *nb)
^
In file included from drivers/misc/mei/hdcp/mei_hdcp.c:35:0:
include/linux/mei_hdcp.h:39:12: note: previous definition of
'mei_cldev_register_notify' was here
static int mei_cldev_register_notify(struct notifier_block *nb)
^
>> drivers/misc/mei/hdcp/mei_hdcp.c:55:5: error: redefinition of
>> 'mei_cldev_unregister_notify'
int mei_cldev_unregister_notify(struct notifier_block *nb)
^~~
In file included from drivers/misc/mei/hdcp/mei_hdcp.c:35:0:
include/linux/mei_hdcp.h:43:12: note: previous definition of
'mei_cldev_unregister_notify' was here
static int mei_cldev_unregister_notify(struct notifier_block *nb)
^~~
include/linux/mei_hdcp.h:43:12: warning: 'mei_cldev_unregister_notify'
defined but not used [-Wunused-function]
include/linux/mei_hdcp.h:39:12: warning: 'mei_cldev_register_notify' defined
but not used [-Wunused-function]
static int mei_cldev_register_notify(struct notifier_block *nb)
^
vim +/mei_cldev_register_notify +49 drivers/misc/mei/hdcp/mei_hdcp.c
48
> 49 int mei_cldev_register_notify(struct notifier_block *nb)
50 {
51 return
blocking_notifier_chain_register(&mei_cldev_notifier_list, nb);
52 }
53 EXPORT_SYMBOL_GPL(mei_cldev_register_notify);
54
> 55 int mei_cldev_unregister_notify(struct notifier_block *nb)
56 {
57 return
blocking_notifier_chain_unregister(&mei_cldev_notifier_list, nb);
58 }
59 EXPORT_SYMBOL_GPL(mei_cldev_unregister_notify);
60
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] dt-bindings: arm: omap: dmm: Document new compatible for DRA7xx family
Hi Peter, On Friday, 23 March 2018 10:31:53 EEST Peter Ujfalusi wrote: > On 2018-03-22 15:42, Peter Ujfalusi wrote: > > From: Tomi Valkeinen > > > > Define unique compatible string for the DMM in DRA7xx family. > > > > The new compatible can be used to apply DRA7xx specific workarounds for > > ERRATAs, like i878 (MPU Lockup with concurrent DMM and EMIF accesses) > > > > Signed-off-by: Tomi Valkeinen > > I have failed to add: > Signed-off-by: Peter Ujfalusi That's not mandatory. The SoB line only serves to notify that you adhere to the developer's certificate of origin as documented in Documentation/process/ submitting-patches.rst. If you haven't modified this patch, and if you intend to get it picked from the mailing list (as opposed to getting it pulled from your tree), you don't need to add your SoB. > > --- > > > > Documentation/devicetree/bindings/arm/omap/dmm.txt | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/Documentation/devicetree/bindings/arm/omap/dmm.txt > > b/Documentation/devicetree/bindings/arm/omap/dmm.txt index > > 8bd6d0a238a8..bbbe7cdba30c 100644 > > --- a/Documentation/devicetree/bindings/arm/omap/dmm.txt > > +++ b/Documentation/devicetree/bindings/arm/omap/dmm.txt > > @@ -8,7 +8,8 @@ translation for initiators which need contiguous dma bus > > addresses.> > > Required properties: > > - compatible: Should contain "ti,omap4-dmm" for OMAP4 family > > > > - Should contain "ti,omap5-dmm" for OMAP5 and DRA7x family > > + Should contain "ti,omap5-dmm" for OMAP5 family > > + Should contain "ti,dra7-dmm" for DRA7xx family > > > > - reg: Contains DMM register address range (base address and > > length) > > - interrupts: Should contain an interrupt-specifier for DMM_IRQ. > > - ti,hwmods: Name of the hwmod associated to DMM, which is typically > > "dmm" -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] dt-bindings: arm: omap: dmm: Document new compatible for DRA7xx family
Hi Peter, Thank you for the patch. On Thursday, 22 March 2018 15:42:05 EEST Peter Ujfalusi wrote: > From: Tomi Valkeinen > > Define unique compatible string for the DMM in DRA7xx family. > > The new compatible can be used to apply DRA7xx specific workarounds for > ERRATAs, like i878 (MPU Lockup with concurrent DMM and EMIF accesses) > > Signed-off-by: Tomi Valkeinen Reviewed-by: Laurent Pinchart > --- > Documentation/devicetree/bindings/arm/omap/dmm.txt | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/arm/omap/dmm.txt > b/Documentation/devicetree/bindings/arm/omap/dmm.txt index > 8bd6d0a238a8..bbbe7cdba30c 100644 > --- a/Documentation/devicetree/bindings/arm/omap/dmm.txt > +++ b/Documentation/devicetree/bindings/arm/omap/dmm.txt > @@ -8,7 +8,8 @@ translation for initiators which need contiguous dma bus > addresses. > > Required properties: > - compatible:Should contain "ti,omap4-dmm" for OMAP4 family > - Should contain "ti,omap5-dmm" for OMAP5 and DRA7x family > + Should contain "ti,omap5-dmm" for OMAP5 family > + Should contain "ti,dra7-dmm" for DRA7xx family > - reg: Contains DMM register address range (base address and > length) > - interrupts:Should contain an interrupt-specifier for DMM_IRQ. > - ti,hwmods: Name of the hwmod associated to DMM, which is typically "dmm" -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199101] AMDGPU Fury X random screen flicker on Linux kernel 4.16rc5
https://bugzilla.kernel.org/show_bug.cgi?id=199101 Berillions (berilli...@gmail.com) changed: What|Removed |Added CC||berilli...@gmail.com --- Comment #12 from Berillions (berilli...@gmail.com) --- I confirm that i have this issue too with final kernel 4.16, Rx560 and mesa-git. The issue does not appears with the Kernel 4.15.15 -- 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 20/40] drm/i915: Define HDCP2.2 related variables
Hi Ramalingam, Thank you for the patch! Yet something to improve: [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on next-20180403] [cannot apply to v4.16] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Ramalingam-C/drm-i915-Implement-HDCP2-2/20180404-031743 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: x86_64-randconfig-x001-201813 (attached as .config) compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): In file included from drivers/gpu//drm/i915/intel_drv.h:32:0, from drivers/gpu//drm/i915/i915_trace.h:11, from drivers/gpu//drm/i915/i915_drv.h:2919, from drivers/gpu//drm/i915/i915_drv.c:49: >> include/linux/mei_hdcp.h:148:12: error: 'mei_cldev_unregister_notify' >> defined but not used [-Werror=unused-function] static int mei_cldev_unregister_notify(struct notifier_block *nb) ^~~ >> include/linux/mei_hdcp.h:144:12: error: 'mei_cldev_register_notify' defined >> but not used [-Werror=unused-function] static int mei_cldev_register_notify(struct notifier_block *nb) ^ cc1: all warnings being treated as errors vim +/mei_cldev_unregister_notify +148 include/linux/mei_hdcp.h 3ce9e24eb Ramalingam C 2018-04-03 105 ca998fc38 Ramalingam C 2018-04-03 106 #ifdef CONFIG_INTEL_MEI_HDCP ca998fc38 Ramalingam C 2018-04-03 107 int mei_cldev_register_notify(struct notifier_block *nb); ca998fc38 Ramalingam C 2018-04-03 108 int mei_cldev_unregister_notify(struct notifier_block *nb); 5240fee41 Ramalingam C 2018-04-03 109 int mei_initiate_hdcp2_session(struct mei_cl_device *cldev, 5240fee41 Ramalingam C 2018-04-03 110 struct mei_hdcp_data *data, 5240fee41 Ramalingam C 2018-04-03 111 struct hdcp2_ake_init *ake_data); e33886f53 Ramalingam C 2018-04-03 112 int e33886f53 Ramalingam C 2018-04-03 113 mei_verify_receiver_cert_prepare_km(struct mei_cl_device *cldev, e33886f53 Ramalingam C 2018-04-03 114 struct mei_hdcp_data *data, e33886f53 Ramalingam C 2018-04-03 115 struct hdcp2_ake_send_cert *rx_cert, e33886f53 Ramalingam C 2018-04-03 116 bool *km_stored, e33886f53 Ramalingam C 2018-04-03 117 struct hdcp2_ake_no_stored_km *ek_pub_km, e33886f53 Ramalingam C 2018-04-03 118 size_t *msg_sz); a27b68fb5 Ramalingam C 2018-04-03 119 int mei_verify_hprime(struct mei_cl_device *cldev, struct mei_hdcp_data *data, a27b68fb5 Ramalingam C 2018-04-03 120struct hdcp2_ake_send_hprime *rx_hprime); dc86bde43 Ramalingam C 2018-04-03 121 int mei_store_pairing_info(struct mei_cl_device *cldev, dc86bde43 Ramalingam C 2018-04-03 122 struct mei_hdcp_data *data, dc86bde43 Ramalingam C 2018-04-03 123 struct hdcp2_ake_send_pairing_info *pairing_info); 67158470b Ramalingam C 2018-04-03 124 int mei_initiate_locality_check(struct mei_cl_device *cldev, 67158470b Ramalingam C 2018-04-03 125 struct mei_hdcp_data *data, 67158470b Ramalingam C 2018-04-03 126 struct hdcp2_lc_init *lc_init_data); b10099c9a Ramalingam C 2018-04-03 127 int mei_verify_lprime(struct mei_cl_device *cldev, struct mei_hdcp_data *data, b10099c9a Ramalingam C 2018-04-03 128struct hdcp2_lc_send_lprime *rx_lprime); 931c35709 Ramalingam C 2018-04-03 129 int mei_get_session_key(struct mei_cl_device *cldev, struct mei_hdcp_data *data, 931c35709 Ramalingam C 2018-04-03 130 struct hdcp2_ske_send_eks *ske_data); 654828e8b Ramalingam C 2018-04-03 131 int 654828e8b Ramalingam C 2018-04-03 132 mei_repeater_check_flow_prepare_ack(struct mei_cl_device *cldev, 654828e8b Ramalingam C 2018-04-03 133 struct mei_hdcp_data *data, 654828e8b Ramalingam C 2018-04-03 134 struct hdcp2_rep_send_receiverid_list 654828e8b Ramalingam C 2018-04-03 135 *rep_topology, 654828e8b Ramalingam C 2018-04-03 136 struct hdcp2_rep_send_ack *rep_send_ack); 315c37225 Ramalingam C 2018-04-03 137 int mei_verify_mprime(struct mei_cl_device *cldev, struct mei_hdcp_data *data, 315c37225 Ramalingam C 2018-04-03 138struct hdcp2_rep_stream_ready *stream_r
Re: [PATCH] drm: rcar-du: track dma-buf fences
On Tue, Apr 3, 2018 at 8:53 PM, Laurent Pinchart
wrote:
> Hello Emre,
>
> Thank you for the patch.
>
> On Tuesday, 3 April 2018 12:14:33 EEST Emre Ucan wrote:
>> We have to check dma-buf reservation objects
>> of our framebuffers before we use them.
>> Otherwise, another driver might be writing
>> on the same buffer which we are using.
>> This would cause visible tearing effects
>> on display.
>>
>> We can use existing atomic helper functions
>> to solve this problem.
>>
>> Signed-off-by: Emre Ucan
>> ---
>> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 ++
>> drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 20
>> 2 files changed, 22 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
>> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index 0329b35..f3da3d1 100644
>> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
>> @@ -255,6 +255,8 @@ static void rcar_du_atomic_commit_tail(struct
>> drm_atomic_state *old_state) {
>> struct drm_device *dev = old_state->dev;
>>
>> + drm_atomic_helper_wait_for_fences(dev, old_state, false);
>> +
>
> The commit_tail() function in drm_atomic_helper.c, which calls our
> atomic_commit_tail() implementation, already calls
> drm_atomic_helper_wait_for_fences(). Why is there a need to duplicate the call
> here ?
>
>> /* Apply the atomic update. */
>> drm_atomic_helper_commit_modeset_disables(dev, old_state);
>> drm_atomic_helper_commit_planes(dev, old_state,
>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
>> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c index 2c260c3..482e23c 100644
>> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
>> @@ -18,12 +18,16 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>> #include
>> +#include
>> +#include
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>>
>> @@ -203,6 +207,20 @@ static void rcar_du_vsp_plane_setup(struct
>> rcar_du_vsp_plane *plane) plane->index, &cfg);
>> }
>>
>> +static void rcar_du_vsp_set_fence_for_plane(struct drm_plane_state *state)
>> +{
>> + struct drm_gem_cma_object *gem;
>> + struct dma_buf *dma_buf;
>> + struct dma_fence *fence;
>> +
>> + gem = drm_fb_cma_get_gem_obj(state->fb, 0);
>> + dma_buf = gem->base.dma_buf;
>> + if (dma_buf) {
>> + fence = reservation_object_get_excl_rcu(dma_buf->resv);
>> + drm_atomic_set_fence_for_plane(state, fence);
>
> Unless I'm mistaken this is used for implicit fencing only. What is your use
> case, wouldn't it be better for userspace to use explicit fencing as that is
> the fence model that has been selected for display ?
Implicit fencing is very much still a thing on most X and wayland
setups. There's a push to eventually make everything explicit, but
it'll take a while I think.
-Daniel
>
>> + }
>> +}
>
> This looks very similar to drm_gem_fb_prepare_fb(), couldn't you use that
> function instead ?
>
>> static int rcar_du_vsp_plane_prepare_fb(struct drm_plane *plane,
>> struct drm_plane_state *state)
>> {
>> @@ -237,6 +255,8 @@ static int rcar_du_vsp_plane_prepare_fb(struct drm_plane
>> *plane, }
>> }
>>
>> + rcar_du_vsp_set_fence_for_plane(state);
>> +
>> return 0;
>>
>> fail:
>
> --
> Regards,
>
> Laurent Pinchart
>
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 37/40] drm/i915: Implement the HDCP2.2 support for DP
Hi Ramalingam,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20180403]
[cannot apply to v4.16]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Ramalingam-C/drm-i915-Implement-HDCP2-2/20180404-031743
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-x071-201813 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
In file included from include/drm/drm_mm.h:49:0,
from include/drm/drmP.h:73,
from drivers/gpu/drm/i915/intel_dp.c:36:
drivers/gpu/drm/i915/intel_dp.c: In function 'intel_dp_hdcp2_read_rx_status':
>> drivers/gpu/drm/i915/intel_dp.c:5377:13: warning: format '%ld' expects
>> argument of type 'long int', but argument 2 has type 'ssize_t {aka int}'
>> [-Wformat=]
DRM_ERROR("Read bstatus from DP/AUX failed (%ld)\n", ret);
^
include/drm/drm_print.h:239:10: note: in definition of macro 'DRM_ERROR'
drm_err(fmt, ##__VA_ARGS__)
^~~
In file included from drivers/gpu/drm/i915/intel_dp.c:34:0:
At top level:
include/linux/mei_hdcp.h:148:12: warning: 'mei_cldev_unregister_notify'
defined but not used [-Wunused-function]
static int mei_cldev_unregister_notify(struct notifier_block *nb)
^~~
include/linux/mei_hdcp.h:144:12: warning: 'mei_cldev_register_notify'
defined but not used [-Wunused-function]
static int mei_cldev_register_notify(struct notifier_block *nb)
^
vim +5377 drivers/gpu/drm/i915/intel_dp.c
5366
5367 static inline
5368 int intel_dp_hdcp2_read_rx_status(struct intel_digital_port
*intel_dig_port,
5369uint8_t *rx_status)
5370 {
5371 ssize_t ret;
5372
5373 ret = drm_dp_dpcd_read(&intel_dig_port->dp.aux,
5374 DP_HDCP_2_2_REG_RXSTATUS_OFFSET,
rx_status,
5375 HDCP_2_2_DP_RXSTATUS_LEN);
5376 if (ret != HDCP_2_2_DP_RXSTATUS_LEN) {
> 5377 DRM_ERROR("Read bstatus from DP/AUX failed (%ld)\n",
> ret);
5378 return ret >= 0 ? -EIO : ret;
5379 }
5380
5381 return 0;
5382 }
5383
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for v4.17-rc1
On Tue, Apr 03, 2018 at 11:15:13AM +0100, Liviu Dudau wrote: > Hi Daniel, > > On Tue, Apr 03, 2018 at 11:58:17AM +0200, Daniel Vetter wrote: > > On Thu, Mar 29, 2018 at 11:15:50AM +1000, Dave Airlie wrote: > > > Hi Linus, > > > > > > This is the main drm pull request for 4.17-rc1. > > > > > > I'm sending it early because Easter is coming and I'm going to be on > > > holidays/have relatives staying for most of the next three weeks. > > > I'll be near email for any emergency but otherwise not too engaged. > > > I'll likely have two days back before the end of the merge window > > > to vaccum up any fixes. Cannonlake and Vega12 support are probably the > > > two major things. This pull lacks nouveau, Ben had some unforseen > > > leave and a few other blockers so we'll see how things look or maybe > > > leave it for this merge window. > > > > > > I'm off to eat my weight in chocolate. > > > > Droppping down to dri-devel. > > > > I've had some great fun with scripting maintainer statistics recently. One > > thing I've done is looking at patches committed by the author themselves > > (= stuff pushed by maintainers/committers), and how much formal > > reviews/acks there are. > > > > Overall we're doing a fairly decent job, with 80+% of these patches > > reviewed. Big drivers (i915 and amdgpu) do a pretty much perfect job, as > > does everyone who's part of the drm-misc group. But the in-between drivers > > less so. And given that everyone else has to go through mandatory reviews > > (less than 50% of all patches are merged by maintainers/committers, even > > in drm) I don't see why maintainers should be special and can skip review. > > > > Also, most of the drivers where review doesn't consistently happen are > > developed by groups, so not hard to find a suitable review. Anyway, below > > the stats of unreviewed maintainer patches for this pull here. > > > > I think some drivers we could perhaps stuff into drm-misc, others should > > probably move to grou maintainership of some form. > > > > Cheers, Daniel > > > > Alex Deucher (2): > > Revert "drm/radeon/pm: autoswitch power state when in balanced mode" > > drm/amdgpu: add documentation for amdgpu_device.c > > > > Dave Airlie (1): > > drm/amd/pp: fix missing CONFIG_ACPI. > > > > Frank Rowand (4): > > of: change overlay apply input data from unflattened to FDT > > of: Documentation: of_overlay_apply() replaced by > > of_overlay_fdt_apply() > > of: convert unittest overlay devicetree source to sugar syntax > > of: improve reporting invalid overlay target path > > > > Joonas Lahtinen (5): > > drm/i915: Update DRIVER_DATE to 20180207 > > drm/i915: Update DRIVER_DATE to 20180214 > > drm/i915: Update DRIVER_DATE to 20180221 > > drm/i915: Update DRIVER_DATE to 20180305 > > drm/i915: Update DRIVER_DATE to 20180308 > > > > Liviu Dudau (5): > > drm/mali-dp: Rotated planes need a larger pitch size. > > drm/mali-dp: Align pitch size to be multiple of bus burst read size. > > drm/mali-dp: Don't enable scaling engine for planes that only rotate. > > drm/mali-dp: Fix malidp_atomic_commit_hw_done() for event sending. > > drm: mali-dp: Turn off CRTC vblank when removing module. > > On the mali-dp driver there was a period of time where it was only me doing > the work on mainline driver, with the promise that more people are going to > join. That has now happened, so there are people reviewing the patches > internally, but we are currently failing because of old habits to record > their Reviewed-by properly when we transition the patches from internal > discussions to the public ones. We're going to try harder in the future to > not let maintainer patches go without proper review tags into the drm-next > pull request. This is a dilemma that we suffer on drm-intel as well: Record or no record internal reviews when moving the code upstream. The benefits of recording: Keep credits. People did work and spent their time on reviewing the code already. Not recording it properly could demotivate people of doing any internal reviews. The cons of recording it: The upstream code might have moved a lot that the reviewed-by tag from the old version is not the same anymore. So, we decided for keeping the internal history, but using a common sense rule where the person in charge of upstreaming internal patches ping the old-reviewer, before merging, asking to do a double check to see if the old review is still valid or if a new review should happen before code gets really pushed. This is working pretty well so far. Either way the Review is very important and pays off. I regretted myself for merging some patches on internal without review at some point where I believed that only having the final review would be enough. A bad rubber stamp review shouldn't be an excuse to avoid reviews at all. The bad rubber stamp review should be addressed and fixed with a process that allow pr
Re: [PATCH] drm: rcar-du: track dma-buf fences
Hello Emre,
Thank you for the patch.
On Tuesday, 3 April 2018 12:14:33 EEST Emre Ucan wrote:
> We have to check dma-buf reservation objects
> of our framebuffers before we use them.
> Otherwise, another driver might be writing
> on the same buffer which we are using.
> This would cause visible tearing effects
> on display.
>
> We can use existing atomic helper functions
> to solve this problem.
>
> Signed-off-by: Emre Ucan
> ---
> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 ++
> drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 20
> 2 files changed, 22 insertions(+)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index 0329b35..f3da3d1 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -255,6 +255,8 @@ static void rcar_du_atomic_commit_tail(struct
> drm_atomic_state *old_state) {
> struct drm_device *dev = old_state->dev;
>
> + drm_atomic_helper_wait_for_fences(dev, old_state, false);
> +
The commit_tail() function in drm_atomic_helper.c, which calls our
atomic_commit_tail() implementation, already calls
drm_atomic_helper_wait_for_fences(). Why is there a need to duplicate the call
here ?
> /* Apply the atomic update. */
> drm_atomic_helper_commit_modeset_disables(dev, old_state);
> drm_atomic_helper_commit_planes(dev, old_state,
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c index 2c260c3..482e23c 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> @@ -18,12 +18,16 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> +#include
> +#include
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -203,6 +207,20 @@ static void rcar_du_vsp_plane_setup(struct
> rcar_du_vsp_plane *plane) plane->index, &cfg);
> }
>
> +static void rcar_du_vsp_set_fence_for_plane(struct drm_plane_state *state)
> +{
> + struct drm_gem_cma_object *gem;
> + struct dma_buf *dma_buf;
> + struct dma_fence *fence;
> +
> + gem = drm_fb_cma_get_gem_obj(state->fb, 0);
> + dma_buf = gem->base.dma_buf;
> + if (dma_buf) {
> + fence = reservation_object_get_excl_rcu(dma_buf->resv);
> + drm_atomic_set_fence_for_plane(state, fence);
Unless I'm mistaken this is used for implicit fencing only. What is your use
case, wouldn't it be better for userspace to use explicit fencing as that is
the fence model that has been selected for display ?
> + }
> +}
This looks very similar to drm_gem_fb_prepare_fb(), couldn't you use that
function instead ?
> static int rcar_du_vsp_plane_prepare_fb(struct drm_plane *plane,
> struct drm_plane_state *state)
> {
> @@ -237,6 +255,8 @@ static int rcar_du_vsp_plane_prepare_fb(struct drm_plane
> *plane, }
> }
>
> + rcar_du_vsp_set_fence_for_plane(state);
> +
> return 0;
>
> fail:
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/8] dma-buf: add peer2peer flag
On Tue, Apr 03, 2018 at 01:06:45PM -0400, Jerome Glisse wrote: > On Tue, Apr 03, 2018 at 11:09:09AM +0200, Daniel Vetter wrote: > > On Thu, Mar 29, 2018 at 01:34:24PM +0200, Christian König wrote: > > > Am 29.03.2018 um 08:57 schrieb Daniel Vetter: > > > > On Sun, Mar 25, 2018 at 12:59:56PM +0200, Christian König wrote: > > > > > Add a peer2peer flag noting that the importer can deal with device > > > > > resources which are not backed by pages. > > > > > > > > > > Signed-off-by: Christian König > > > > Um strictly speaking they all should, but ttm never bothered to use the > > > > real interfaces but just hacked around the provided sg list, grabbing > > > > the > > > > underlying struct pages, then rebuilding&remapping the sg list again. > > > > > > Actually that isn't correct. TTM converts them to a dma address array > > > because drivers need it like this (at least nouveau, radeon and amdgpu). > > > > > > I've fixed radeon and amdgpu to be able to deal without it and mailed with > > > Ben about nouveau, but the outcome is they don't really know. > > > > > > TTM itself doesn't have any need for the pages on imported BOs (you can't > > > mmap them anyway), the real underlying problem is that sg tables doesn't > > > provide what drivers need. > > > > > > I think we could rather easily fix sg tables, but that is a totally > > > separate > > > task. > > > > Looking at patch 8, the sg table seems perfectly sufficient to convey the > > right dma addresses to the importer. Ofcourse the exporter has to set up > > the right kind of iommu mappings to make this work. > > > > > > The entire point of using sg lists was exactly to allow this use case of > > > > peer2peer dma (or well in general have special exporters which managed > > > > memory/IO ranges not backed by struct page). So essentially you're > > > > having > > > > a "I'm totally not broken flag" here. > > > > > > No, independent of needed struct page pointers we need to note if the > > > exporter can handle peer2peer stuff from the hardware side in general. > > > > > > So what I've did is just to set peer2peer allowed on the importer because > > > of > > > the driver needs and clear it in the exporter if the hardware can't handle > > > that. > > > > The only thing the importer seems to do is call the > > pci_peer_traffic_supported, which the exporter could call too. What am I > > missing (since the sturct_page stuff sounds like it's fixed already by > > you)? > > -Daniel > > AFAIK Logan patchset require to register and initialize struct page > for the device memory you want to map (export from exporter point of > view). > > With GPU this isn't something we want, struct page is >~= 2^6 so for > 4GB GPU = 2^6*2^32/2^12 = 2^26 = 64MB of RAM > 8GB GPU = 2^6*2^33/2^12 = 2^27 = 128MB of RAM > 16GB GPU = 2^6*2^34/2^12 = 2^28 = 256MB of RAM > 32GB GPU = 2^6*2^34/2^12 = 2^29 = 512MB of RAM > > All this is mostly wasted as only a small sub-set (that can not be > constraint to specific range) will ever be exported at any point in > time. For GPU work load this is hardly justifiable, even for HMM i > do not plan to register all those pages. > > Hence why i argue that dma_map_resource() like use by Christian is > good enough for us. People that care about SG can fix that but i > rather not have to depend on that and waste system memory. I did not mean you should dma_map_sg/page. I just meant that using dma_map_resource to fill only the dma address part of the sg table seems perfectly sufficient. And that's exactly why the importer gets an already mapped sg table, so that it doesn't have to call dma_map_sg on something that dma_map_sg can't handle. Assuming you get an sg table that's been mapping by calling dma_map_sg was always a bit a case of bending the abstraction to avoid typing code. The only thing an importer ever should have done is look at the dma addresses in that sg table, nothing else. And p2p seems to perfectly fit into this (surprise, it was meant to). That's why I suggested we annotate the broken importers who assume the sg table is mapped using dma_map_sg or has a struct_page backing the memory (but there doesn't seem to be any left it seems) instead of annotating the ones that aren't broken with a flag that's confusing - you could also have a dma-buf sgt that points at some other memory that doesn't have struct pages backing it. Aside: At least internally in i915 we've been using this forever for our own private/stolen memory. Unfortunately no other device can access that range of memory, which is why we don't allow it to be imported to anything but i915 itself. But if that hw restriction doesn't exist, it'd would work. -Daniel -- 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: amdgpu hangs on boot or shutdown on AMD Raven Ridge CPU (Engineer Sample)
On Thu, Mar 22, 2018 at 3:09 AM, Daniel Drake wrote: > On Tue, Feb 20, 2018 at 10:18 PM, Alex Deucher wrote: >>> It seems that we are not alone seeing amdgpu-induced stability >>> problems on multiple Raven Ridge platforms. >>> https://www.phoronix.com/scan.php?page=news_item&px=AMD-Raven-Ridge-Mobo-Linux >>> >>> AMD, what can we do to help? >> >> Please file bugs: >> https://bugs.freedesktop.org > > Sorry for the delayed response. We're still seeing serious instability > here even on the latest kernel. Filed > https://bugs.freedesktop.org/show_bug.cgi?id=105684 No progress made on that bug report so far. What can we do to help this advance? Thanks, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm/virtio: remove drm_dev_set_unique workaround
On 29 March 2018 at 12:17, Laszlo Ersek wrote: > On 03/28/18 16:35, Emil Velikov wrote: >> On 28 March 2018 at 11:27, Laszlo Ersek wrote: >>> On 03/28/18 03:24, Emil Velikov wrote: > Gents, can someone double-check this please? Just in case. >>> >>> I guess I should test whether this series regresses the use case >>> described in c2cbc38b97; is that correct? >>> >> Precisely. > >> [3] https://github.com/evelikov/linux/commits/ioctl-cleanups > > Unfortunately, this series seems to reintroduce the regression fixed / > described earlier in commit c2cbc38b97. > Thank you very much for testing. Believe I've tracked it down to a broken commit from 2014 ;-) Please try the following branch [1] - it's untested, but I'm 99% sure it will work like a charm. If it doesn't please share the dmesg of a) the updated branch, and b) baseline + the debug patch [2] Thanks again! Emil [1] https://github.com/evelikov/linux/commits/ioctl-cleanups-v2 [2] https://github.com/evelikov/linux/commit/c2bc545d677001ffe5387aebb708d1adeb12b35b ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/8] dma-buf: add peer2peer flag
On Tue, Apr 03, 2018 at 11:09:09AM +0200, Daniel Vetter wrote: > On Thu, Mar 29, 2018 at 01:34:24PM +0200, Christian König wrote: > > Am 29.03.2018 um 08:57 schrieb Daniel Vetter: > > > On Sun, Mar 25, 2018 at 12:59:56PM +0200, Christian König wrote: > > > > Add a peer2peer flag noting that the importer can deal with device > > > > resources which are not backed by pages. > > > > > > > > Signed-off-by: Christian König > > > Um strictly speaking they all should, but ttm never bothered to use the > > > real interfaces but just hacked around the provided sg list, grabbing the > > > underlying struct pages, then rebuilding&remapping the sg list again. > > > > Actually that isn't correct. TTM converts them to a dma address array > > because drivers need it like this (at least nouveau, radeon and amdgpu). > > > > I've fixed radeon and amdgpu to be able to deal without it and mailed with > > Ben about nouveau, but the outcome is they don't really know. > > > > TTM itself doesn't have any need for the pages on imported BOs (you can't > > mmap them anyway), the real underlying problem is that sg tables doesn't > > provide what drivers need. > > > > I think we could rather easily fix sg tables, but that is a totally separate > > task. > > Looking at patch 8, the sg table seems perfectly sufficient to convey the > right dma addresses to the importer. Ofcourse the exporter has to set up > the right kind of iommu mappings to make this work. > > > > The entire point of using sg lists was exactly to allow this use case of > > > peer2peer dma (or well in general have special exporters which managed > > > memory/IO ranges not backed by struct page). So essentially you're having > > > a "I'm totally not broken flag" here. > > > > No, independent of needed struct page pointers we need to note if the > > exporter can handle peer2peer stuff from the hardware side in general. > > > > So what I've did is just to set peer2peer allowed on the importer because of > > the driver needs and clear it in the exporter if the hardware can't handle > > that. > > The only thing the importer seems to do is call the > pci_peer_traffic_supported, which the exporter could call too. What am I > missing (since the sturct_page stuff sounds like it's fixed already by > you)? > -Daniel AFAIK Logan patchset require to register and initialize struct page for the device memory you want to map (export from exporter point of view). With GPU this isn't something we want, struct page is >~= 2^6 so for 4GB GPU = 2^6*2^32/2^12 = 2^26 = 64MB of RAM 8GB GPU = 2^6*2^33/2^12 = 2^27 = 128MB of RAM 16GB GPU = 2^6*2^34/2^12 = 2^28 = 256MB of RAM 32GB GPU = 2^6*2^34/2^12 = 2^29 = 512MB of RAM All this is mostly wasted as only a small sub-set (that can not be constraint to specific range) will ever be exported at any point in time. For GPU work load this is hardly justifiable, even for HMM i do not plan to register all those pages. Hence why i argue that dma_map_resource() like use by Christian is good enough for us. People that care about SG can fix that but i rather not have to depend on that and waste system memory. Cheers, Jérôme ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/amdgpu: Add modeset module option
On Tue, Apr 03, 2018 at 05:02:35PM +0200, Daniel Vetter wrote: > On Tue, Apr 03, 2018 at 05:06:03PM +0300, Ville Syrjälä wrote: > > On Tue, Apr 03, 2018 at 03:47:57PM +0200, Michel Dänzer wrote: > > > On 2018-04-03 03:39 PM, Ilia Mirkin wrote: > > > > On Tue, Apr 3, 2018 at 9:32 AM, Michel Dänzer > > > > wrote: > > > >> On 2018-04-03 03:26 PM, Ilia Mirkin wrote: > > > >>> On Tue, Apr 3, 2018 at 5:29 AM, Daniel Vetter wrote: > > > On Sun, Apr 01, 2018 at 10:12:10PM +0200, Christian König wrote: > > > > Am 01.04.2018 um 20:21 schrieb Takashi Iwai: > > > >> On Sun, 01 Apr 2018 19:58:11 +0200, > > > >> Christian K6nig wrote: > > > >>> Am 01.04.2018 um 19:45 schrieb Ilia Mirkin: > > > On Sun, Apr 1, 2018 at 1:39 PM, Christian König > > > wrote: > > > > Am 30.03.2018 um 22:45 schrieb Takashi Iwai: > > > >> amdgpu driver lacks of modeset module option other drm drivers > > > >> provide > > > >> for enforcing or disabling the driver load. Interestingly, the > > > >> amdgpu_mode variable declaration is already found in the > > > >> header file, > > > >> but the actual implementation seems to have been forgotten. > > > >> > > > >> This patch adds the missing piece. > > > > NAK, modesetting is mandatory for amdgpu and we should probably > > > > remove the > > > > option to disable it from other DRM drivers without UMS support > > > > as well > > > > (pretty much all of them now). > > > > > > > > If you want to prevent a driver from loading I think the > > > > correct way to do > > > > so is to give modprobe.blacklist=amdgpu on the kernel > > > > commandline. > > > > > > > > That would remove the possibility to prevent the driver from > > > > loading when it > > > > is compiled in, but I don't see much of a problem with that. > > > Having a way to kill the graphics driver is a very useful > > > debugging > > > tool, and also a quick and easy way to get out of an unpleasant > > > situation where graphics are messed up / system hangs / etc. The > > > modprobe blacklist kernel arg only works in certain environments > > > (and > > > only if it's a module). > > > > > > Every other DRM driver has this and this is a well-documented > > > workaround for "graphics are messed up when I install linux", > > > why not > > > allow a uniform experience for the end users who are just trying > > > to > > > get their systems up and running? > > > >>> Because it is not well documented and repeated over and over > > > >>> again in > > > >>> drivers. > > > >>> > > > >>> The problem is that people don't realized that the driver isn't > > > >>> loaded > > > >>> at all without the modeset=0 module option and demand fixing the > > > >>> resulting bad performance without modesetting. > > > >> Hm, I don't get it. What this options has to do with performance > > > >> for > > > >> a KMS-only driver...? > > > > > > > > Well exactly that's the point, nothing. > > > > > > > > The problem is that the option name is confusing to the end user > > > > because the > > > > expectation is that "nomodeset" just means that they only can't > > > > change the > > > > display mode. > > > > > > > > Some (unfortunately quite a lot) people don't realize that for KMS > > > > drivers > > > > this means that the driver isn't even loaded and they also don't > > > > get any > > > > acceleration. > > > > > > > > We had to explain that numerous times now. I think it would be best > > > > to give > > > > the option a more meaningful name. > > > > > > Yeah, agreed with Christian. If we want a generic "pls disable all > > > gfx > > > accel" knob then probably best to put that into the drm core. And > > > just > > > outright fail loading the drm core if that happens, which will > > > prevent all > > > gfx drivers from loading. > > > > > > That likely means a hole bunch of stuff won't work (usually sound > > > keels > > > over too), but that's what you get for this. Only disabling > > > modesetting > > > without disabling the entire driver doesn't work (never has, except > > > for > > > this UMS+GEM combo only i915 support, and not for long). > > > > > > And once we have that knob, probably best to phase out all the > > > per-driver > > > options. > > > >>> > > > >>> Another use-case that the per-driver disables enable is "i915 works > > > >>> but nouveau is broken due to crazy ACPI / PCIe PM / whatever". It > > > >>> seems likely this could happen with amdgpu as well. > > > >> > > > >> mod
Re: [PATCH v3 36/40] drm/i915: Implement gmbus burst read
On Tue, Apr 03, 2018 at 07:27:49PM +0530, Ramalingam C wrote:
> Implements a interface for single burst read of data that is larger
> than 512 Bytes through gmbus.
>
> HDCP2.2 spec expects HDCP2.2 transmitter to read 522Bytes of HDCP
> receiver certificates in single burst read. On gmbus, to read more
> than 511Bytes, HW provides a workaround for burst read.
>
> This patch passes the burst read request through gmbus read functions.
> And implements the sequence of enabling and disabling the burst read.
>
> v2:
> No Changes.
> v3:
> No Changes.
>
> Signed-off-by: Ramalingam C
Why only enable this burst_read mode for hdcp, and not for all i2c
transactions? Seems to unecessarily complicate the code, since it requires
that you pass burst_read through the entire call chain. For other changes
we've done for hdcp (like enabling the read/write mode and other stuff)
we've enabled it for all i2c transactions. That also means more testing,
since it will be used even when HDCP is not in use.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +
> drivers/gpu/drm/i915/i915_reg.h | 3 +
> drivers/gpu/drm/i915/intel_i2c.c | 124
> +--
> 3 files changed, 112 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 6e740f6fe33f..72534a1e544b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3688,6 +3688,8 @@ extern void intel_teardown_gmbus(struct
> drm_i915_private *dev_priv);
> extern bool intel_gmbus_is_valid_pin(struct drm_i915_private *dev_priv,
>unsigned int pin);
> extern int intel_gmbus_output_aksv(struct i2c_adapter *adapter);
> +extern int intel_gmbus_burst_read(struct i2c_adapter *adapter,
> + unsigned int offset, void *buf, size_t size);
>
> extern struct i2c_adapter *
> intel_gmbus_get_adapter(struct drm_i915_private *dev_priv, unsigned int pin);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index f04ad3c15abd..56979bc4e9d8 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3123,6 +3123,7 @@ enum i915_power_well_id {
> #define GMBUS_RATE_400KHZ (2<<8) /* reserved on Pineview */
> #define GMBUS_RATE_1MHZ(3<<8) /* reserved on Pineview */
> #define GMBUS_HOLD_EXT (1<<7) /* 300ns hold time, rsvd on Pineview */
> +#define GMBUS_BYTE_CNT_OVERRIDE (1<<6)
> #define GMBUS_PIN_DISABLED 0
> #define GMBUS_PIN_SSC 1
> #define GMBUS_PIN_VGADDC 2
> @@ -3150,8 +3151,10 @@ enum i915_power_well_id {
> #define GMBUS_CYCLE_WAIT (1<<25)
> #define GMBUS_CYCLE_INDEX (2<<25)
> #define GMBUS_CYCLE_STOP (4<<25)
> +#define GMBUS_CYCLE_MASK (7<<25)
> #define GMBUS_BYTE_COUNT_SHIFT 16
> #define GMBUS_BYTE_COUNT_MAX 256U
> +#define GMBUS_BYTE_COUNT_HW_MAX 511U
> #define GMBUS_SLAVE_INDEX_SHIFT 8
> #define GMBUS_SLAVE_ADDR_SHIFT 1
> #define GMBUS_SLAVE_READ (1<<0)
> diff --git a/drivers/gpu/drm/i915/intel_i2c.c
> b/drivers/gpu/drm/i915/intel_i2c.c
> index e6875509bcd9..dcb2be0d54ee 100644
> --- a/drivers/gpu/drm/i915/intel_i2c.c
> +++ b/drivers/gpu/drm/i915/intel_i2c.c
> @@ -364,21 +364,30 @@ gmbus_wait_idle(struct drm_i915_private *dev_priv)
> static int
> gmbus_xfer_read_chunk(struct drm_i915_private *dev_priv,
> unsigned short addr, u8 *buf, unsigned int len,
> - u32 gmbus1_index)
> + u32 gmbus1_index, bool burst_read)
> {
> + unsigned int size = len;
> + int ret;
> +
> + if (burst_read) {
> + /* Seq to enable Burst Read */
> + I915_WRITE_FW(GMBUS0, (I915_READ_FW(GMBUS0) |
> + GMBUS_BYTE_CNT_OVERRIDE));
> + size = GMBUS_BYTE_COUNT_HW_MAX;
> + }
> +
> I915_WRITE_FW(GMBUS1,
> gmbus1_index |
> GMBUS_CYCLE_WAIT |
> - (len << GMBUS_BYTE_COUNT_SHIFT) |
> + (size << GMBUS_BYTE_COUNT_SHIFT) |
> (addr << GMBUS_SLAVE_ADDR_SHIFT) |
> GMBUS_SLAVE_READ | GMBUS_SW_RDY);
> while (len) {
> - int ret;
> u32 val, loop = 0;
>
> ret = gmbus_wait(dev_priv, GMBUS_HW_RDY, GMBUS_HW_RDY_EN);
> if (ret)
> - return ret;
> + goto exit;
>
> val = I915_READ_FW(GMBUS3);
> do {
> @@ -387,12 +396,29 @@ gmbus_xfer_read_chunk(struct drm_i915_private *dev_priv,
> } while (--len && ++loop < 4);
> }
>
> - return 0;
> +exit:
> + if (burst_read) {
> +
> + /* Seq to disable the Burst Read */
> + I915_WRITE_FW(GMBUS0, (I915_READ_FW(GMBUS0) &
> + ~GMBUS_BYTE_CNT_OVERRIDE));
> + I915_WRITE_FW(GMBUS1, (I915_READ_FW
Re: [PATCH 0/7] sunxi: Add DT representation for the MBUS controller
On Tue, Apr 3, 2018 at 8:29 AM, Maxime Ripard wrote: > Hi, > > We've had for quite some time to hack around in our drivers to take into > account the fact that our DMA accesses are not done through the parent > node, but through another bus with a different mapping than the CPU for the > RAM (0 instead of 0x4000 for most SoCs). > > After some discussion after the submission of a camera device suffering of > the same hacks, I've decided to put together a serie that introduce a > property called dma-parent that allows to express the DMA relationship > between a master and its bus, even if they are not direct parents in the DT. Reading thru v6 of the camera driver, it seems like having intermediate buses would solve the problem in your case? As Arnd mentioned in that thread, something new needs to address all the deficiencies with dma-ranges and describing DMA bus topologies. This doesn't address the needs of describing bus interconnects. There's been some efforts by the QCom folks with an interconnect binding. They've mostly punted (for now at least) to not describing the whole interconnect in DT and keeping the details in a driver. On the flip side, this does mirror the established pattern used by interrupts, so maybe it's okay on it's own. I'll wait for others to comment. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm 1/3] xf86drm: replace sprintf()+strdup() with asprintf()
On Monday, 2018-03-26 15:00:01 +0100, Emil Velikov wrote:
> On 26 March 2018 at 14:57, Jani Nikula wrote:
> > On Mon, 26 Mar 2018, Eric Engestrom wrote:
> >> Signed-off-by: Eric Engestrom
> >> ---
> >> xf86drm.c | 28 ++--
> >> 1 file changed, 14 insertions(+), 14 deletions(-)
> >>
> >> diff --git a/xf86drm.c b/xf86drm.c
> >> index 3a9d0ed2cc9b196ae7d1..b6e5d8cc1bb50ffe75a2 100644
> >> --- a/xf86drm.c
> >> +++ b/xf86drm.c
> >> @@ -2823,7 +2823,7 @@ static char *drmGetMinorNameForFD(int fd, int type)
> >> struct stat sbuf;
> >> const char *name = drmGetMinorName(type);
> >> int len;
> >> -char dev_name[64], buf[64];
> >> +char *dev_name, buf[64];
> >> int maj, min;
> >>
> >> if (!name)
> >> @@ -2848,20 +2848,22 @@ static char *drmGetMinorNameForFD(int fd, int type)
> >>
> >> while ((ent = readdir(sysdir))) {
> >> if (strncmp(ent->d_name, name, len) == 0) {
> >> -snprintf(dev_name, sizeof(dev_name), DRM_DIR_NAME "/%s",
> >> - ent->d_name);
> >> +if (asprintf(&dev_name, DRM_DIR_NAME "/%s",
> >
> > Just noting in passing that asprintf is a GNU extension, is that okay?
> >
> Was going to mention the same thing. Also POSIX please add it to the
> next version ;-)
> It doesn't seem to make the code shorter, so I'd go with let's drop this?
Those were just some local changes I had done at some random point when
coming across stuff that I thought could be better. I just sent them now
since my local changes will be lost by me leaving my current job, and
I didn't care enough to push them on a branch somewhere (:
Either these were thought to be good by someone else, or, as it is,
they're not and I'm dropping all three :)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102885] regression - 17.2 sparkle grid in shadows
https://bugs.freedesktop.org/show_bug.cgi?id=102885 --- Comment #13 from Thomas J. Moore --- (In reply to Timothy Arceri from comment #11) > Deleting the trace means no one else can investigate the bug. Is this still > a problem? I assumed Samuel Pitoiset already figured out what the problem was, particularly since the git bisect pointed to a change he made. Perhaps you can contact him directly? It's been six months, and multiple releases of Mesa, so I pretty much don't believe this bug will get looked at, and don't care if it gets fixed or not. Testing if it's still broken is already more trouble for me than it's worth. I don't trust dropbox, and have no intention of uploading this file again. (In reply to Timothy Arceri from comment #12) > Possibly a duplicate of bug 105152 Feel free to mark it as such, so I don't have to deal with it any more. It's not the first bug of mine that's been marked as a duplicate of a later bug report. (I didn't read it, but again, I don't care any more). If it's not really a duplicate, feel free to just close this as "won't fix". -- 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 v3 05/40] misc/mei/hdcp: Notifier chain for mei cldev state change
On Tue, Apr 03, 2018 at 07:27:18PM +0530, Ramalingam C wrote:
> Notifier Chain is defined to inform all its clients about the mei
> client device state change. Routine is defined for the clients to
> register and unregister for the notification on state change.
>
> v2:
> Rebased.
> v3:
> Notifier chain is adopted for cldev state update [Tomas]
>
> Signed-off-by: Ramalingam C
For managing interactions between multiple drivers notifier chains are
fairly problematic. The main reason is the locking embedded in the
notifier chain. To make things safe, that lock must be held everytime we
add/remove any part of the link, and when calling any callback. Usually
that means you get a neat deadlock sooner or later, because the
load/unload code has inverse paths compared to normal operation.
Notifiers also not not provide a clean way to handle suspend/resume
ordering.
There's two parts to do this properly.
1. Finding the other driver. Multi-part drivers are assembled nowadays
using the component framework. We're using that already to manage the
interaction between drm/i915 and snd-hda. If not all components are ready
yet, then the driver load sequence must be aborted by returning
-EPROBE_DEFER. That's going to be lots of fun, since for the mei/i915
interaction it's probably going to be i915 that needs to abort and retry
the driver load. But we do CI test all the abort points in our driver
load, so should work well.
2. Handling the ordering restrictions for suspend/resume. For i915/snd-hda
we used a early_resume/late_suspend callback trickery, but that doesn't
really scale to multiple levels. Since we've done that device_link has
been added. As a bonus device_link can also ensure that not only
suspend/resume (including runtime suspend/resume) is ordered correctly,
but also that driver bind/unbind works correctly. Still needs the
component stuff and initial -EPROBE_DEFER, but will all least make sure
we' only reprobe once more. See device_link_add + docs in device_link.rst.
One thing I didn't check is whether we want the device linke to also
manage runtime pm for us. It would mean that we keep the ME awake as long
as anything is using the gpu (any display on or any rendering happening).
That might be too much, but could also be that it won't matter (and then
using DL_FLAG_PM_RUNTIME would simply our code).
We might also need to convert the i915/snd-hda interactions to device_link
first, since the early/late_resume/suspend hack probably doesn't interact
too well with proper device_links.
Cheers, Daniel
> ---
> drivers/misc/mei/hdcp/mei_hdcp.c | 36 +++---
> include/linux/mei_hdcp.h | 48
>
> 2 files changed, 81 insertions(+), 3 deletions(-)
> create mode 100644 include/linux/mei_hdcp.h
>
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index b334615728a7..2811a25f8c57 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -31,6 +31,32 @@
> #include
> #include
> #include
> +#include
> +#include
> +
> +static BLOCKING_NOTIFIER_HEAD(mei_cldev_notifier_list);
> +
> +void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool
> enabled)
> +{
> + if (enabled)
> + blocking_notifier_call_chain(&mei_cldev_notifier_list,
> + MEI_CLDEV_ENABLED, cldev);
> + else
> + blocking_notifier_call_chain(&mei_cldev_notifier_list,
> + MEI_CLDEV_DISABLED, NULL);
> +}
> +
> +int mei_cldev_register_notify(struct notifier_block *nb)
> +{
> + return blocking_notifier_chain_register(&mei_cldev_notifier_list, nb);
> +}
> +EXPORT_SYMBOL_GPL(mei_cldev_register_notify);
> +
> +int mei_cldev_unregister_notify(struct notifier_block *nb)
> +{
> + return blocking_notifier_chain_unregister(&mei_cldev_notifier_list, nb);
> +}
> +EXPORT_SYMBOL_GPL(mei_cldev_unregister_notify);
>
> static int mei_hdcp_probe(struct mei_cl_device *cldev,
> const struct mei_cl_device_id *id)
> @@ -38,14 +64,18 @@ static int mei_hdcp_probe(struct mei_cl_device *cldev,
> int ret;
>
> ret = mei_cldev_enable(cldev);
> - if (ret < 0)
> + if (ret < 0) {
> dev_err(&cldev->dev, "mei_cldev_enable Failed. %d\n", ret);
> + return ret;
> + }
>
> - return ret;
> + mei_cldev_state_notify_clients(cldev, true);
> + return 0;
> }
>
> static int mei_hdcp_remove(struct mei_cl_device *cldev)
> {
> + mei_cldev_state_notify_clients(cldev, false);
> mei_cldev_set_drvdata(cldev, NULL);
> return mei_cldev_disable(cldev);
> }
> @@ -71,4 +101,4 @@ module_mei_cl_driver(mei_hdcp_driver);
>
> MODULE_AUTHOR("Intel Corporation");
> MODULE_LICENSE("Dual BSD/GPL");
> -MODULE_DESCRIPTION("HDCP");
> +MODULE_DESCRIPTION("MEI HDCP");
> diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdc
[Bug 99923] HITMAN (2016) having lighting and artefacting, and overly light room.
https://bugs.freedesktop.org/show_bug.cgi?id=99923 --- Comment #26 from Matt Arsenault --- Can you attach the temp dumps with/without the vectorizer enabled? -- 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 v2] drm/msm: don't deref error pointer in the msm_fbdev_create error path
On 28 March 2018 at 17:22, Emil Velikov wrote: > From: Emil Velikov > > Currently the error pointer returned by msm_alloc_stolen_fb gets passed > to drm_framebuffer_remove. The latter handles only NULL pointers, thus > a nasty crash will occur. > > Drop the unnecessary fail label and the associated checks - both err and > fb will be set at this stage. > > Cc: Rob Clark > Cc: linux-arm-...@vger.kernel.org > Cc: dri-devel@lists.freedesktop.org > Cc: freedr...@lists.freedesktop.org > Signed-off-by: Emil Velikov > --- > v2: really remove the fail label :-\ > --- Humble ping? -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Signal handling in a page fault handler
On Tue, Apr 03, 2018 at 07:48:29AM -0700, Matthew Wilcox wrote:
> On Tue, Apr 03, 2018 at 03:12:35PM +0200, Thomas Hellstrom wrote:
> > I think the TTM page fault handler originally set the standard for this.
> > First, IMO any critical section that waits for the GPU (like typically the
> > page fault handler does), should be locked at least killable. The need for
> > interruptible locks came from the X server's silken mouse relying on signals
> > for smooth mouse operations: You didn't want the X server to be stuck in the
> > kernel waiting for GPU completion when it should handle the cursor move
> > request.. Now that doesn't seem to be the case anymore but to reiterate
> > Chris' question, why would the signal persist once returned to user-space?
>
> Yeah, you graphics people have had to deal with much more recalcitrant
> hardware than most of the rest of us ... and less reasonable user
> expectations ("My graphics card was doing something and I expected
> everything else to keep going" vs "My hard drive died and my kernel
> paniced, oh well.")
>
> I don't know exactly how the signal code works at the delivery end;
> I'm not sure when TIF_SIGPENDING gets cleared. I just get concerned
> when I see one bit of kernel code doing things in a very complicated
> and careful manner and another bit of kernel code blithely assuming
> that everything's going to be OK.
I think you last line pretty much sums up the proper attitude when writing
gpu drivers:
https://i.imgflip.com/27nm7w.jpg
Cheers, Daniel
--
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/2] drm/amdgpu: Add modeset module option
On 2018-04-03 04:06 PM, Ville Syrjälä wrote: > On Tue, Apr 03, 2018 at 03:47:57PM +0200, Michel Dänzer wrote: >> On 2018-04-03 03:39 PM, Ilia Mirkin wrote: >>> On Tue, Apr 3, 2018 at 9:32 AM, Michel Dänzer wrote: On 2018-04-03 03:26 PM, Ilia Mirkin wrote: > On Tue, Apr 3, 2018 at 5:29 AM, Daniel Vetter wrote: >> On Sun, Apr 01, 2018 at 10:12:10PM +0200, Christian König wrote: >>> Am 01.04.2018 um 20:21 schrieb Takashi Iwai: On Sun, 01 Apr 2018 19:58:11 +0200, Christian K6nig wrote: > Am 01.04.2018 um 19:45 schrieb Ilia Mirkin: >> On Sun, Apr 1, 2018 at 1:39 PM, Christian König >> wrote: >>> Am 30.03.2018 um 22:45 schrieb Takashi Iwai: amdgpu driver lacks of modeset module option other drm drivers provide for enforcing or disabling the driver load. Interestingly, the amdgpu_mode variable declaration is already found in the header file, but the actual implementation seems to have been forgotten. This patch adds the missing piece. >>> NAK, modesetting is mandatory for amdgpu and we should probably >>> remove the >>> option to disable it from other DRM drivers without UMS support as >>> well >>> (pretty much all of them now). >>> >>> If you want to prevent a driver from loading I think the correct >>> way to do >>> so is to give modprobe.blacklist=amdgpu on the kernel commandline. >>> >>> That would remove the possibility to prevent the driver from >>> loading when it >>> is compiled in, but I don't see much of a problem with that. >> Having a way to kill the graphics driver is a very useful debugging >> tool, and also a quick and easy way to get out of an unpleasant >> situation where graphics are messed up / system hangs / etc. The >> modprobe blacklist kernel arg only works in certain environments (and >> only if it's a module). >> >> Every other DRM driver has this and this is a well-documented >> workaround for "graphics are messed up when I install linux", why not >> allow a uniform experience for the end users who are just trying to >> get their systems up and running? > Because it is not well documented and repeated over and over again in > drivers. > > The problem is that people don't realized that the driver isn't loaded > at all without the modeset=0 module option and demand fixing the > resulting bad performance without modesetting. Hm, I don't get it. What this options has to do with performance for a KMS-only driver...? >>> >>> Well exactly that's the point, nothing. >>> >>> The problem is that the option name is confusing to the end user >>> because the >>> expectation is that "nomodeset" just means that they only can't change >>> the >>> display mode. >>> >>> Some (unfortunately quite a lot) people don't realize that for KMS >>> drivers >>> this means that the driver isn't even loaded and they also don't get any >>> acceleration. >>> >>> We had to explain that numerous times now. I think it would be best to >>> give >>> the option a more meaningful name. >> >> Yeah, agreed with Christian. If we want a generic "pls disable all gfx >> accel" knob then probably best to put that into the drm core. And just >> outright fail loading the drm core if that happens, which will prevent >> all >> gfx drivers from loading. >> >> That likely means a hole bunch of stuff won't work (usually sound keels >> over too), but that's what you get for this. Only disabling modesetting >> without disabling the entire driver doesn't work (never has, except for >> this UMS+GEM combo only i915 support, and not for long). >> >> And once we have that knob, probably best to phase out all the per-driver >> options. > > Another use-case that the per-driver disables enable is "i915 works > but nouveau is broken due to crazy ACPI / PCIe PM / whatever". It > seems likely this could happen with amdgpu as well. modprobe.blacklist=amdgpu works as well as the modeset parameter for this. >>> >>> People who build their own kernels run into trouble too. >> >> There have always been various more or less serious issues with building >> amdgpu (and radeon) into the kernel. People who do so get to keep all >> pieces when it breaks. >> >> >>> Also does this work uniformly across all systems where it is a module? >> >> AFAIK yes. > > Sadly modprobe.blacklist doesn't prevent X/whatever from loading the > module anyway. AFAICT xf86-video-amdgpu and modesetting have never even tried loading the kernel module, and neither has xf86-video-ati for years at least.
Re: [PATCH 2/2] drm/amdgpu: Add modeset module option
On Tue, Apr 03, 2018 at 05:06:03PM +0300, Ville Syrjälä wrote: > On Tue, Apr 03, 2018 at 03:47:57PM +0200, Michel Dänzer wrote: > > On 2018-04-03 03:39 PM, Ilia Mirkin wrote: > > > On Tue, Apr 3, 2018 at 9:32 AM, Michel Dänzer wrote: > > >> On 2018-04-03 03:26 PM, Ilia Mirkin wrote: > > >>> On Tue, Apr 3, 2018 at 5:29 AM, Daniel Vetter wrote: > > On Sun, Apr 01, 2018 at 10:12:10PM +0200, Christian König wrote: > > > Am 01.04.2018 um 20:21 schrieb Takashi Iwai: > > >> On Sun, 01 Apr 2018 19:58:11 +0200, > > >> Christian K6nig wrote: > > >>> Am 01.04.2018 um 19:45 schrieb Ilia Mirkin: > > On Sun, Apr 1, 2018 at 1:39 PM, Christian König > > wrote: > > > Am 30.03.2018 um 22:45 schrieb Takashi Iwai: > > >> amdgpu driver lacks of modeset module option other drm drivers > > >> provide > > >> for enforcing or disabling the driver load. Interestingly, the > > >> amdgpu_mode variable declaration is already found in the header > > >> file, > > >> but the actual implementation seems to have been forgotten. > > >> > > >> This patch adds the missing piece. > > > NAK, modesetting is mandatory for amdgpu and we should probably > > > remove the > > > option to disable it from other DRM drivers without UMS support > > > as well > > > (pretty much all of them now). > > > > > > If you want to prevent a driver from loading I think the correct > > > way to do > > > so is to give modprobe.blacklist=amdgpu on the kernel commandline. > > > > > > That would remove the possibility to prevent the driver from > > > loading when it > > > is compiled in, but I don't see much of a problem with that. > > Having a way to kill the graphics driver is a very useful debugging > > tool, and also a quick and easy way to get out of an unpleasant > > situation where graphics are messed up / system hangs / etc. The > > modprobe blacklist kernel arg only works in certain environments > > (and > > only if it's a module). > > > > Every other DRM driver has this and this is a well-documented > > workaround for "graphics are messed up when I install linux", why > > not > > allow a uniform experience for the end users who are just trying to > > get their systems up and running? > > >>> Because it is not well documented and repeated over and over again > > >>> in > > >>> drivers. > > >>> > > >>> The problem is that people don't realized that the driver isn't > > >>> loaded > > >>> at all without the modeset=0 module option and demand fixing the > > >>> resulting bad performance without modesetting. > > >> Hm, I don't get it. What this options has to do with performance for > > >> a KMS-only driver...? > > > > > > Well exactly that's the point, nothing. > > > > > > The problem is that the option name is confusing to the end user > > > because the > > > expectation is that "nomodeset" just means that they only can't > > > change the > > > display mode. > > > > > > Some (unfortunately quite a lot) people don't realize that for KMS > > > drivers > > > this means that the driver isn't even loaded and they also don't get > > > any > > > acceleration. > > > > > > We had to explain that numerous times now. I think it would be best > > > to give > > > the option a more meaningful name. > > > > Yeah, agreed with Christian. If we want a generic "pls disable all gfx > > accel" knob then probably best to put that into the drm core. And just > > outright fail loading the drm core if that happens, which will prevent > > all > > gfx drivers from loading. > > > > That likely means a hole bunch of stuff won't work (usually sound keels > > over too), but that's what you get for this. Only disabling modesetting > > without disabling the entire driver doesn't work (never has, except for > > this UMS+GEM combo only i915 support, and not for long). > > > > And once we have that knob, probably best to phase out all the > > per-driver > > options. > > >>> > > >>> Another use-case that the per-driver disables enable is "i915 works > > >>> but nouveau is broken due to crazy ACPI / PCIe PM / whatever". It > > >>> seems likely this could happen with amdgpu as well. > > >> > > >> modprobe.blacklist=amdgpu > > >> > > >> works as well as the modeset parameter for this. > > > > > > People who build their own kernels run into trouble too. > > > > There have always been various more or less serious issues with building > > amdgpu (and radeon) into the kernel. People who do so get to keep all > > pieces when it breaks. fwiw, same roughly applies for i915. We try to
Re: [PATCH 5/7] drm/sun4i: Rely on dma-parent for our RAM offset
On Tue, Apr 03, 2018 at 03:29:18PM +0200, Maxime Ripard wrote:
> Now that we can express our DMA topology, rely on those property instead of
> hardcoding an offset from the dma_addr_t which wasn't really great.
>
> We still need to add some code to deal with the old DT that would lack that
> property, but we move the offset to the DRM device dma_pfn_offset to be
> able to rely on just the dma_addr_t associated to the GEM object.
>
> Signed-off-by: Maxime Ripard
Yay for hiding more bus address funies behind dma_map_* support. This
should also help with cleaner dma-buf import.
Acked-by: Daniel Vetter
> ---
> drivers/gpu/drm/sun4i/sun4i_backend.c | 28 +---
> 1 file changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c
> b/drivers/gpu/drm/sun4i/sun4i_backend.c
> index 847eecbe4d14..04e85d3ca36e 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
> @@ -222,13 +222,6 @@ int sun4i_backend_update_layer_buffer(struct
> sun4i_backend *backend,
> paddr = drm_fb_cma_get_gem_addr(fb, state, 0);
> DRM_DEBUG_DRIVER("Setting buffer address to %pad\n", &paddr);
>
> - /*
> - * backend DMA accesses DRAM directly, bypassing the system
> - * bus. As such, the address range is different and the buffer
> - * address needs to be corrected.
> - */
> - paddr -= PHYS_OFFSET;
> -
> /* Write the 32 lower bits of the address (in bits) */
> lo_paddr = paddr << 3;
> DRM_DEBUG_DRIVER("Setting address lower bits to 0x%x\n", lo_paddr);
> @@ -361,6 +354,27 @@ static int sun4i_backend_bind(struct device *dev, struct
> device *master,
> return -ENOMEM;
> dev_set_drvdata(dev, backend);
>
> + if (of_find_property(dev->of_node, "dma-parent", NULL)) {
> + /*
> + * This assume we have the same DMA constraints for all our the
> + * devices in our pipeline (all the backends, but also the
> + * frontends). This sounds bad, but it has always been the case
> + * for us, and DRM doesn't do per-device allocation either, so
> + * we would need to fix DRM first...
> + */
> + ret = of_dma_configure(drm->dev, dev->of_node);
> + if (ret)
> + return ret;
> + } else {
> + /*
> + * If we don't have the dma-parent property, most likely
> + * because of an old DT, we need to set the DMA offset by hand
> + * on our device since the RAM mapping is at 0 for the DMA bus,
> + * unlike the CPU.
> + */
> + drm->dev->dma_pfn_offset = PHYS_PFN_OFFSET;
> + }
> +
> backend->engine.node = dev->of_node;
> backend->engine.ops = &sun4i_backend_engine_ops;
> backend->engine.id = sun4i_backend_of_get_id(dev->of_node);
> --
> git-series 0.9.1
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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: [git pull] drm for v4.17-rc1
On Tue, Apr 3, 2018 at 3:23 PM, Jani Nikula wrote: > On Tue, 03 Apr 2018, Lucas Stach wrote: >> My _feeling_ is that the review economy in drm-misc, which gets DRM the >> bragging rights of 80% reviewed patches, has already lowered the weight >> associated with those reviews, as most of them are really shallow. This >> might be okay with you and I'm certainly not trying to change the way >> drm-misc is handled, but I doubt that this is the universal gold >> standard which should be applied to everything. > > I think you need to substantiate your claims about rubber stamping > reviews. I'm not seeing that. And I do pay attention to the reviews that > happen on i915 and drm display parts, kind of review-of-review. I'm > personally pretty diligent about review, and I'm honestly *more* ashamed > of patches I reviewed regressing than patches I wrote. Looking around, I > don't think I'm alone. Yeah, a thing to keep in mind is that we've had this "forced review" in drm-intel since well over 5 years (so much longer than commit rights). And the same rules apply to any core drm patches that get merged into drm-misc. Similar for amd drivers, and Dave Airlie as subsystem maintainer. Small drivers are explictly excempt from strict review requirements in drm-misc, there we just want an Acked-by: to signal a 2nd person at least looked at the patch. But even there a lot of the patches got through full review scrutinies, with a bunch of revisions until the patch is right. And all this has defacto run on a "you review mine, I review yours" review economy all this time. That amounts to 50+ people, some who've done this for 5+ years, you accused of doing rubber stamp reviews. I agree with Jani that this deserves some more concrete data than your personal feelings. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 36/40] drm/i915: Implement gmbus burst read
Implements a interface for single burst read of data that is larger
than 512 Bytes through gmbus.
HDCP2.2 spec expects HDCP2.2 transmitter to read 522Bytes of HDCP
receiver certificates in single burst read. On gmbus, to read more
than 511Bytes, HW provides a workaround for burst read.
This patch passes the burst read request through gmbus read functions.
And implements the sequence of enabling and disabling the burst read.
v2:
No Changes.
v3:
No Changes.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_reg.h | 3 +
drivers/gpu/drm/i915/intel_i2c.c | 124 +--
3 files changed, 112 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6e740f6fe33f..72534a1e544b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3688,6 +3688,8 @@ extern void intel_teardown_gmbus(struct drm_i915_private
*dev_priv);
extern bool intel_gmbus_is_valid_pin(struct drm_i915_private *dev_priv,
unsigned int pin);
extern int intel_gmbus_output_aksv(struct i2c_adapter *adapter);
+extern int intel_gmbus_burst_read(struct i2c_adapter *adapter,
+ unsigned int offset, void *buf, size_t size);
extern struct i2c_adapter *
intel_gmbus_get_adapter(struct drm_i915_private *dev_priv, unsigned int pin);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f04ad3c15abd..56979bc4e9d8 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3123,6 +3123,7 @@ enum i915_power_well_id {
#define GMBUS_RATE_400KHZ(2<<8) /* reserved on Pineview */
#define GMBUS_RATE_1MHZ (3<<8) /* reserved on Pineview */
#define GMBUS_HOLD_EXT (1<<7) /* 300ns hold time, rsvd on Pineview */
+#define GMBUS_BYTE_CNT_OVERRIDE (1<<6)
#define GMBUS_PIN_DISABLED 0
#define GMBUS_PIN_SSC1
#define GMBUS_PIN_VGADDC 2
@@ -3150,8 +3151,10 @@ enum i915_power_well_id {
#define GMBUS_CYCLE_WAIT (1<<25)
#define GMBUS_CYCLE_INDEX(2<<25)
#define GMBUS_CYCLE_STOP (4<<25)
+#define GMBUS_CYCLE_MASK (7<<25)
#define GMBUS_BYTE_COUNT_SHIFT 16
#define GMBUS_BYTE_COUNT_MAX 256U
+#define GMBUS_BYTE_COUNT_HW_MAX 511U
#define GMBUS_SLAVE_INDEX_SHIFT 8
#define GMBUS_SLAVE_ADDR_SHIFT 1
#define GMBUS_SLAVE_READ (1<<0)
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index e6875509bcd9..dcb2be0d54ee 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -364,21 +364,30 @@ gmbus_wait_idle(struct drm_i915_private *dev_priv)
static int
gmbus_xfer_read_chunk(struct drm_i915_private *dev_priv,
unsigned short addr, u8 *buf, unsigned int len,
- u32 gmbus1_index)
+ u32 gmbus1_index, bool burst_read)
{
+ unsigned int size = len;
+ int ret;
+
+ if (burst_read) {
+ /* Seq to enable Burst Read */
+ I915_WRITE_FW(GMBUS0, (I915_READ_FW(GMBUS0) |
+ GMBUS_BYTE_CNT_OVERRIDE));
+ size = GMBUS_BYTE_COUNT_HW_MAX;
+ }
+
I915_WRITE_FW(GMBUS1,
gmbus1_index |
GMBUS_CYCLE_WAIT |
- (len << GMBUS_BYTE_COUNT_SHIFT) |
+ (size << GMBUS_BYTE_COUNT_SHIFT) |
(addr << GMBUS_SLAVE_ADDR_SHIFT) |
GMBUS_SLAVE_READ | GMBUS_SW_RDY);
while (len) {
- int ret;
u32 val, loop = 0;
ret = gmbus_wait(dev_priv, GMBUS_HW_RDY, GMBUS_HW_RDY_EN);
if (ret)
- return ret;
+ goto exit;
val = I915_READ_FW(GMBUS3);
do {
@@ -387,12 +396,29 @@ gmbus_xfer_read_chunk(struct drm_i915_private *dev_priv,
} while (--len && ++loop < 4);
}
- return 0;
+exit:
+ if (burst_read) {
+
+ /* Seq to disable the Burst Read */
+ I915_WRITE_FW(GMBUS0, (I915_READ_FW(GMBUS0) &
+ ~GMBUS_BYTE_CNT_OVERRIDE));
+ I915_WRITE_FW(GMBUS1, (I915_READ_FW(GMBUS1) &
+ ~GMBUS_CYCLE_MASK) | GMBUS_CYCLE_STOP);
+
+ /*
+* On Burst read disable, GMBUS need more time to settle
+* down to Idle State.
+*/
+ ret = intel_wait_for_register_fw(dev_priv, GMBUS2,
+GMBUS_ACTIVE, 0, 50);
+ }
+
+ return ret;
}
static int
gmbus_xfer_read(struct drm_i915_private *dev_priv, struct i2c_msg *msg,
- u32 gmbus1_index)
+ u32 gmbus1_index, bool burst_read)
{
u8 *buf = msg->buf;
[PATCH v3 40/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:
No Changes.
Signed-off-by: Ramalingam C
---
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 a974d3e2097a..29689269dc80 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -2545,7 +2545,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,
- &intel_hdmi_hdcp_shim, false);
+&intel_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 v3 39/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:
No Changes.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_dp.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_hdcp.c | 1 -
3 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e5cb54ceda38..43318003ce14 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -6733,7 +6733,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, &intel_dp_hdcp_shim,
- false);
+ is_hdcp2_supported(dev_priv));
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 37f9a0e2ea13..2bb562738964 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1941,6 +1941,7 @@ int intel_hdcp_enable(struct intel_connector *connector);
int intel_hdcp_disable(struct intel_connector *connector);
bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port);
void intel_hdcp_handle_cp_irq(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 9386b451191e..9d5cade3b236 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -1723,7 +1723,6 @@ static int mei_cldev_notify(struct notifier_block *nb,
unsigned long event,
return NOTIFY_OK;
}
-static inline
bool is_hdcp2_supported(struct drm_i915_private *dev_priv)
{
return (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv) ||
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/amdgpu: Add modeset module option
On Tue, Apr 03, 2018 at 03:47:57PM +0200, Michel Dänzer wrote: > On 2018-04-03 03:39 PM, Ilia Mirkin wrote: > > On Tue, Apr 3, 2018 at 9:32 AM, Michel Dänzer wrote: > >> On 2018-04-03 03:26 PM, Ilia Mirkin wrote: > >>> On Tue, Apr 3, 2018 at 5:29 AM, Daniel Vetter wrote: > On Sun, Apr 01, 2018 at 10:12:10PM +0200, Christian König wrote: > > Am 01.04.2018 um 20:21 schrieb Takashi Iwai: > >> On Sun, 01 Apr 2018 19:58:11 +0200, > >> Christian K6nig wrote: > >>> Am 01.04.2018 um 19:45 schrieb Ilia Mirkin: > On Sun, Apr 1, 2018 at 1:39 PM, Christian König > wrote: > > Am 30.03.2018 um 22:45 schrieb Takashi Iwai: > >> amdgpu driver lacks of modeset module option other drm drivers > >> provide > >> for enforcing or disabling the driver load. Interestingly, the > >> amdgpu_mode variable declaration is already found in the header > >> file, > >> but the actual implementation seems to have been forgotten. > >> > >> This patch adds the missing piece. > > NAK, modesetting is mandatory for amdgpu and we should probably > > remove the > > option to disable it from other DRM drivers without UMS support as > > well > > (pretty much all of them now). > > > > If you want to prevent a driver from loading I think the correct > > way to do > > so is to give modprobe.blacklist=amdgpu on the kernel commandline. > > > > That would remove the possibility to prevent the driver from > > loading when it > > is compiled in, but I don't see much of a problem with that. > Having a way to kill the graphics driver is a very useful debugging > tool, and also a quick and easy way to get out of an unpleasant > situation where graphics are messed up / system hangs / etc. The > modprobe blacklist kernel arg only works in certain environments (and > only if it's a module). > > Every other DRM driver has this and this is a well-documented > workaround for "graphics are messed up when I install linux", why not > allow a uniform experience for the end users who are just trying to > get their systems up and running? > >>> Because it is not well documented and repeated over and over again in > >>> drivers. > >>> > >>> The problem is that people don't realized that the driver isn't loaded > >>> at all without the modeset=0 module option and demand fixing the > >>> resulting bad performance without modesetting. > >> Hm, I don't get it. What this options has to do with performance for > >> a KMS-only driver...? > > > > Well exactly that's the point, nothing. > > > > The problem is that the option name is confusing to the end user > > because the > > expectation is that "nomodeset" just means that they only can't change > > the > > display mode. > > > > Some (unfortunately quite a lot) people don't realize that for KMS > > drivers > > this means that the driver isn't even loaded and they also don't get any > > acceleration. > > > > We had to explain that numerous times now. I think it would be best to > > give > > the option a more meaningful name. > > Yeah, agreed with Christian. If we want a generic "pls disable all gfx > accel" knob then probably best to put that into the drm core. And just > outright fail loading the drm core if that happens, which will prevent > all > gfx drivers from loading. > > That likely means a hole bunch of stuff won't work (usually sound keels > over too), but that's what you get for this. Only disabling modesetting > without disabling the entire driver doesn't work (never has, except for > this UMS+GEM combo only i915 support, and not for long). > > And once we have that knob, probably best to phase out all the per-driver > options. > >>> > >>> Another use-case that the per-driver disables enable is "i915 works > >>> but nouveau is broken due to crazy ACPI / PCIe PM / whatever". It > >>> seems likely this could happen with amdgpu as well. > >> > >> modprobe.blacklist=amdgpu > >> > >> works as well as the modeset parameter for this. > > > > People who build their own kernels run into trouble too. > > There have always been various more or less serious issues with building > amdgpu (and radeon) into the kernel. People who do so get to keep all > pieces when it breaks. > > > > Also does this work uniformly across all systems where it is a module? > > AFAIK yes. Sadly modprobe.blacklist doesn't prevent X/whatever from loading the module anyway. I use modprobe.blacklist myself all the time for i915 development, but I also have all GUI junk disabled as well so that I can load the module myself when I'm actually ready for it (typically after
[PATCH v3 38/40] drm/i915: Implement the HDCP2.2 support for HDMI
Implements the HDMI adapatation specific HDCP2.2 operations.
Basically these are DDC read and write for authenticating through
HDCP2.2 messages.
v2:
Rebased.
v3:
No Changes.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdmi.c | 203 ++
1 file changed, 203 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index b8b1086c0cbd..a974d3e2097a 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1106,6 +1107,203 @@ bool intel_hdmi_hdcp_check_link(struct
intel_digital_port *intel_dig_port)
return true;
}
+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 inline
+int intel_hdmi_hdcp2_timeout_for_msg(uint8_t msg_id, bool is_paired)
+{
+ int timeout = -EINVAL;
+
+ switch (msg_id) {
+ case HDCP_2_2_AKE_SEND_CERT:
+ timeout = HDCP_2_2_CERT_TIMEOUT;
+ break;
+ case HDCP_2_2_AKE_SEND_HPRIME:
+ if (is_paired)
+ timeout = HDCP_2_2_HPRIME_PAIRED_TIMEOUT;
+ else
+ timeout = HDCP_2_2_HPRIME_NO_PAIRED_TIMEOUT;
+ break;
+ case HDCP_2_2_AKE_SEND_PARING_INFO:
+ timeout = HDCP_2_2_PAIRING_TIMEOUT;
+ break;
+ case HDCP_2_2_LC_SEND_LPRIME:
+ timeout = HDCP_2_2_HDMI_LPRIME_TIMEOUT;
+ break;
+ case HDCP_2_2_REP_SEND_RECVID_LIST:
+ timeout = HDCP_2_2_RECVID_LIST_TIMEOUT;
+ break;
+ case HDCP_2_2_REP_STREAM_READY:
+ timeout = HDCP_2_2_STREAM_READY_TIMEOUT;
+ break;
+ default:
+ DRM_ERROR("Unsupported msg_id: %d\n", (int)msg_id);
+ }
+ return timeout;
+}
+
+static inline
+int hdcp2_detect_msg_availability(struct intel_digital_port
*intel_digital_port,
+ uint8_t msg_id, bool *msg_ready,
+ ssize_t *msg_sz)
+{
+ uint8_t 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;
+}
+
+/**
+ * intel_hdmi_hdcp2_wait_for_msg: Detects the hdmi hdcp2.2 msg availability
+ * @hdcp: hdcp structure
+ * @msg_id:Message ID for which we are waiting
+ *
+ * Detects the HDMI HDCP2.2 Message availability
+ *
+ * Returns -ETIMEOUT in case of timeout, Message Size on success
+ */
+static ssize_t
+intel_hdmi_hdcp2_wait_for_msg(struct intel_digital_port *intel_dig_port,
+ uint8_t msg_id, bool paired)
+{
+ bool msg_ready = false;
+ int timeout, ret;
+ ssize_t msg_sz;
+
+ timeout = intel_hdmi_hdcp2_timeout_for_msg(msg_id, paired);
+ if (timeout < 0)
+ return timeout;
+
+ ret = __wait_for(ret = hdcp2_detect_msg_availability(intel_dig_port,
+msg_id, &msg_ready, &msg_sz),
+!ret && msg_ready && msg_sz, timeout * 1000,
+1000, 5 * 1000);
+ if (ret)
+ DRM_ERROR("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, size_t size)
+{
+ unsigned int offset;
+
+ offset = HDCP_2_2_HDMI_REG_WR_MSG_OFFSET;
+ return intel_hdmi_hdcp_write(intel_dig_port, offset, buf, size);
+}
+
+static
+int intel_hdmi_hdcp2_read_msg(struct intel_digital_port *intel_dig_port,
+ uint8_t msg_id, void *buf, size_t size)
+{
+ struct intel_hdmi *hdmi = &intel_dig_port->hdmi;
+ struct intel_hdcp *hdcp = &hdmi->attached_connector->hdcp;
+ struct drm_i915_private *dev_priv;
+ struct i2c_adapter *adapter;
+ unsigned int offset;
+ ssize_t ret;
+
+ ret = intel_hdmi_hdcp2_wait_for_msg(intel_dig_port, msg_id,
+
[PATCH v3 37/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.
Note: Chris Wilson suggested alternate method for waiting for CP_IRQ,
than completions concept. WIP to understand and implement that,
if needed. Just to unblock the review of other changes, v2 still
continues with completions.
v2:
wait for cp_irq is merged with this patch. Rebased.
v3:
wait_queue is used for wait for cp_irq [Chris Wilson]
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_dp.c | 352 ++
drivers/gpu/drm/i915/intel_drv.h | 7 +
drivers/gpu/drm/i915/intel_hdcp.c | 5 +
3 files changed, 364 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f92c0326fff5..e5cb54ceda38 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -5070,6 +5071,28 @@ void intel_dp_encoder_suspend(struct intel_encoder
*intel_encoder)
pps_unlock(intel_dp);
}
+static int intel_dp_hdcp_wait_for_cp_irq(struct intel_hdcp *hdcp,
+int timeout)
+{
+ long ret;
+
+ /* Reinit */
+ atomic_set(&hdcp->cp_irq_recved, 0);
+
+#define C (atomic_read(&hdcp->cp_irq_recved) > 0)
+ ret = wait_event_interruptible_timeout(hdcp->cp_irq_queue, C,
+ msecs_to_jiffies(timeout));
+
+ if (ret > 0) {
+ atomic_set(&hdcp->cp_irq_recved, 0);
+ return 0;
+ } else if (!ret) {
+ return -ETIMEDOUT;
+ }
+ return (int)ret;
+}
+
+
static
int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
u8 *an)
@@ -5288,6 +5311,329 @@ int intel_dp_hdcp_capable(struct intel_digital_port
*intel_dig_port,
return 0;
}
+static inline
+int intel_dpcd_offset_for_hdcp2_msgid(uint8_t byte, unsigned int *offset)
+{
+ switch (byte) {
+ case HDCP_2_2_AKE_INIT:
+ *offset = DP_HDCP_2_2_AKE_INIT_OFFSET;
+ break;
+ case HDCP_2_2_AKE_SEND_CERT:
+ *offset = DP_HDCP_2_2_AKE_SEND_CERT_OFFSET;
+ break;
+ case HDCP_2_2_AKE_NO_STORED_KM:
+ *offset = DP_HDCP_2_2_AKE_NO_STORED_KM_OFFSET;
+ break;
+ case HDCP_2_2_AKE_STORED_KM:
+ *offset = DP_HDCP_2_2_AKE_STORED_KM_OFFSET;
+ break;
+ case HDCP_2_2_AKE_SEND_HPRIME:
+ *offset = DP_HDCP_2_2_AKE_SEND_HPRIME_OFFSET;
+ break;
+ case HDCP_2_2_AKE_SEND_PARING_INFO:
+ *offset = DP_HDCP_2_2_AKE_SEND_PARING_INFO_OFFSET;
+ break;
+ case HDCP_2_2_LC_INIT:
+ *offset = DP_HDCP_2_2_LC_INIT_OFFSET;
+ break;
+ case HDCP_2_2_LC_SEND_LPRIME:
+ *offset = DP_HDCP_2_2_LC_SEND_LPRIME_OFFSET;
+ break;
+ case HDCP_2_2_SKE_SEND_EKS:
+ *offset = DP_HDCP_2_2_SKE_SEND_EKS_OFFSET;
+ break;
+ case HDCP_2_2_REP_SEND_RECVID_LIST:
+ *offset = DP_HDCP_2_2_REP_SEND_RECVID_LIST_OFFSET;
+ break;
+ case HDCP_2_2_REP_SEND_ACK:
+ *offset = DP_HDCP_2_2_REP_SEND_ACK_OFFSET;
+ break;
+ case HDCP_2_2_REP_STREAM_MANAGE:
+ *offset = DP_HDCP_2_2_REP_STREAM_MANAGE_OFFSET;
+ break;
+ case HDCP_2_2_REP_STREAM_READY:
+ *offset = DP_HDCP_2_2_REP_STREAM_READY_OFFSET;
+ break;
+ case HDCP_2_2_ERRATA_DP_STREAM_TYPE:
+ *offset = DP_HDCP_2_2_REG_STREAM_TYPE_OFFSET;
+ break;
+ default:
+ DRM_ERROR("Unrecognized Msg ID\n");
+ return -EINVAL;
+ }
+ return 0;
+}
+
+static inline
+int intel_dp_hdcp2_read_rx_status(struct intel_digital_port *intel_dig_port,
+ uint8_t *rx_status)
+{
+ ssize_t ret;
+
+ ret = drm_dp_dpcd_read(&intel_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_ERROR("Read bstatus from DP/AUX failed (%ld)\n", ret);
+ return ret >= 0 ? -EIO : ret;
+ }
+
+ return 0;
+}
+
+static inline
+int intel_dp_hdcp2_timeout_for_msg(uint8_t msg_id, bool paired)
+{
+ int timeout = -EINVAL;
+
+ switch (msg_id) {
+ case HDCP_2_2_AKE_SEND_CERT:
+ timeout = HDCP_2_2_CERT_TIMEOUT;
+ break;
+ case HDCP_2_2_AKE_SEND_HPRIME:
+ if (paired)
+ timeout = HDCP_2_2_HPRIME_PAIRED_TIMEOUT;
+ else
+ timeout = HDCP
[PATCH v3 35/40] drm/i915: Check HDCP 1.4 and 2.2 link on CP_IRQ
On DP HDCP1.4 and 2.2, when CP_IRQ is received, start the link
integrity check for the HDCP version that is enabled.
v2:
Rebased. Function name is changed.
v3:
No Changes.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_dp.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 2 +-
drivers/gpu/drm/i915/intel_hdcp.c | 31 ++-
3 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4a9f5a690528..f92c0326fff5 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4468,7 +4468,7 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
if (sink_irq_vector & DP_AUTOMATED_TEST_REQUEST)
intel_dp_handle_test_request(intel_dp);
if (sink_irq_vector & DP_CP_IRQ)
- intel_hdcp_check_link(intel_dp->attached_connector);
+ intel_hdcp_handle_cp_irq(intel_dp->attached_connector);
if (sink_irq_vector & 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 2f14756b4b0e..8e60ccd0d368 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1932,8 +1932,8 @@ 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);
+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 5707830a4617..8cf0eeb4b3f8 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -32,6 +32,7 @@ int intel_hdcp_read_valid_bksv(struct intel_digital_port
*intel_dig_port,
const struct intel_hdcp_shim *shim, u8 *bksv);
static
struct intel_digital_port *conn_to_dig_port(struct intel_connector *connector);
+static int intel_hdcp_check_link(struct intel_connector *connector);
static inline
bool panel_supports_hdcp(struct intel_connector *connector)
@@ -79,6 +80,26 @@ static inline bool intel_hdcp2_capable(struct
intel_connector *connector)
panel_supports_hdcp2(connector));
}
+static inline bool intel_hdcp_in_force(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_AUTH | HDCP_STATUS_ENC);
+}
+
+static inline bool intel_hdcp2_in_force(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 | LINK_AUTH_STATUS);
+}
+
static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
const struct intel_hdcp_shim *shim)
{
@@ -858,7 +879,7 @@ void intel_hdcp_atomic_check(struct drm_connector
*connector,
}
/* Implements Part 3 of the HDCP authorization procedure */
-int intel_hdcp_check_link(struct intel_connector *connector)
+static int intel_hdcp_check_link(struct intel_connector *connector)
{
struct intel_hdcp *hdcp = &connector->hdcp;
struct drm_i915_private *dev_priv = connector->base.dev->dev_private;
@@ -1734,3 +1755,11 @@ static int intel_hdcp2_init(struct intel_connector
*connector)
hdcp->hdcp2_supported = false;
return ret;
}
+
+void intel_hdcp_handle_cp_irq(struct intel_connector *connector)
+{
+ if (intel_hdcp_in_force(connector))
+ intel_hdcp_check_link(connector);
+ else if (intel_hdcp2_in_force(connector))
+ intel_hdcp2_check_link(connector);
+}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 34/40] drm/i915: hdcp_check_link only on CP_IRQ
HDCP check link is invoked only on CP_IRQ detection, instead of all
short pulses.
v3:
No Changes.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_dp.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 955a20208097..4a9f5a690528 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4467,8 +4467,10 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
if (sink_irq_vector & DP_AUTOMATED_TEST_REQUEST)
intel_dp_handle_test_request(intel_dp);
- if (sink_irq_vector & (DP_CP_IRQ | DP_SINK_SPECIFIC_IRQ))
- DRM_DEBUG_DRIVER("CP or sink specific irq unhandled\n");
+ if (sink_irq_vector & DP_CP_IRQ)
+ intel_hdcp_check_link(intel_dp->attached_connector);
+ if (sink_irq_vector & DP_SINK_SPECIFIC_IRQ)
+ DRM_DEBUG_DRIVER("Sink specific irq unhandled\n");
}
/* defer to the hotplug work for link retraining if needed */
@@ -5438,9 +5440,6 @@ intel_dp_hpd_pulse(struct intel_digital_port
*intel_dig_port, bool long_hpd)
handled = intel_dp_short_pulse(intel_dp);
- /* Short pulse can signify loss of hdcp authentication */
- intel_hdcp_check_link(intel_dp->attached_connector);
-
if (!handled) {
intel_dp->detect_done = false;
goto put_power;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 33/40] drm/i915: Enable HDCP1.4 incase of HDCP2.2 failure
When HDCP2.2 enabling fails and HDCP1.4 is supported, HDCP1.4 is
enabled.
v2:
Rebased.
v3:
No Changes.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index 01701d7b7b07..5707830a4617 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -786,7 +786,9 @@ int intel_hdcp_enable(struct intel_connector *connector)
*/
if (intel_hdcp2_capable(connector))
ret = _intel_hdcp2_enable(connector);
- else if (intel_hdcp_capable(connector))
+
+ /* When HDCP2.2 fails, HDCP1.4 will be attempted */
+ if (ret && intel_hdcp_capable(connector))
ret = _intel_hdcp_enable(connector);
if (!ret) {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 32/40] drm/i915: Enable superior HDCP ver that is capable
Considering that HDCP2.2 is more secure than HDCP1.4, When a setup
supports HDCP2.2 and HDCP1.4, HDCP2.2 will be enabled.
v2:
Included few optimization suggestions [Chris Wilson]
Commit message is updated as per the rebased version.
v3:
No changes.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 76 +++
1 file changed, 69 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index 383e35689fbd..01701d7b7b07 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -27,6 +27,57 @@ static int _intel_hdcp2_disable(struct intel_connector
*connector);
static void intel_hdcp2_check_work(struct work_struct *work);
static int intel_hdcp2_check_link(struct intel_connector *connector);
static int intel_hdcp2_init(struct intel_connector *connector);
+static inline
+int intel_hdcp_read_valid_bksv(struct intel_digital_port *intel_dig_port,
+ const struct intel_hdcp_shim *shim, u8 *bksv);
+static
+struct intel_digital_port *conn_to_dig_port(struct intel_connector *connector);
+
+static inline
+bool panel_supports_hdcp(struct intel_connector *connector)
+{
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+ struct intel_hdcp *hdcp = &connector->hdcp;
+ bool capable = false;
+ u8 bksv[5];
+
+ if (hdcp->hdcp_shim) {
+ if (hdcp->hdcp_shim->hdcp_capable) {
+ hdcp->hdcp_shim->hdcp_capable(intel_dig_port, &capable);
+ } else {
+ if (!intel_hdcp_read_valid_bksv(intel_dig_port,
+ hdcp->hdcp_shim, bksv))
+ capable = true;
+ }
+ }
+ return capable;
+}
+
+static inline
+bool panel_supports_hdcp2(struct intel_connector *connector)
+{
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+ struct intel_hdcp *hdcp = &connector->hdcp;
+ bool capable = false;
+
+ if (hdcp->hdcp2_supported)
+ hdcp->hdcp_shim->hdcp_2_2_capable(intel_dig_port, &capable);
+
+ return capable;
+}
+
+/* Is HDCP1.4 capable on Platform and Panel */
+static inline bool intel_hdcp_capable(struct intel_connector *connector)
+{
+ return (connector->hdcp.hdcp_shim && panel_supports_hdcp(connector));
+}
+
+/* Is HDCP2.2 capable on Platform and Panel */
+static inline bool intel_hdcp2_capable(struct intel_connector *connector)
+{
+ return (connector->hdcp.hdcp2_supported &&
+ panel_supports_hdcp2(connector));
+}
static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
const struct intel_hdcp_shim *shim)
@@ -722,20 +773,27 @@ int intel_hdcp_init(struct intel_connector *connector,
int intel_hdcp_enable(struct intel_connector *connector)
{
struct intel_hdcp *hdcp = &connector->hdcp;
- int ret;
+ int ret = -EINVAL;
if (!hdcp->hdcp_shim)
return -ENOENT;
mutex_lock(&hdcp->hdcp_mutex);
- ret = _intel_hdcp_enable(connector);
- if (ret)
- goto out;
+ /*
+* Considering that HDCP2.2 is more secure than HDCP1.4, If the setup
+* is capable of HDCP2.2, it is preferred to use HDCP2.2.
+*/
+ if (intel_hdcp2_capable(connector))
+ ret = _intel_hdcp2_enable(connector);
+ else if (intel_hdcp_capable(connector))
+ ret = _intel_hdcp_enable(connector);
+
+ if (!ret) {
+ hdcp->hdcp_value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
+ schedule_work(&hdcp->hdcp_prop_work);
+ }
- hdcp->hdcp_value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
- schedule_work(&hdcp->hdcp_prop_work);
-out:
mutex_unlock(&hdcp->hdcp_mutex);
return ret;
}
@@ -752,10 +810,14 @@ int intel_hdcp_disable(struct intel_connector *connector)
if (hdcp->hdcp_value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
hdcp->hdcp_value = DRM_MODE_CONTENT_PROTECTION_UNDESIRED;
+ if (hdcp->hdcp2_supported)
+ _intel_hdcp2_disable(connector);
+
ret = _intel_hdcp_disable(connector);
}
mutex_unlock(&hdcp->hdcp_mutex);
+ cancel_delayed_work_sync(&hdcp->hdcp2_check_work);
cancel_delayed_work_sync(&hdcp->hdcp_check_work);
return ret;
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 31/40] drm/i915: Schedule hdcp_check_link in _intel_hdcp_enable
As a preparation for making the intel_hdcp_enable as common function
for both HDCP1.4 and HDCP2.2, HDCP1.4 check_link scheduling is moved
into _intel_hdcp_enable() function.
v3:
No Changes.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index 6eb58a833c7d..383e35689fbd 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -627,7 +627,7 @@ static int _intel_hdcp_enable(struct intel_connector
*connector)
ret = intel_hdcp_auth(conn_to_dig_port(connector),
hdcp->hdcp_shim);
if (!ret)
- return 0;
+ break;
DRM_DEBUG_KMS("HDCP Auth failure (%d)\n", ret);
@@ -635,7 +635,12 @@ static int _intel_hdcp_enable(struct intel_connector
*connector)
_intel_hdcp_disable(connector);
}
- DRM_ERROR("HDCP authentication failed (%d tries/%d)\n", tries, ret);
+ if (i != tries)
+ schedule_delayed_work(&hdcp->hdcp_check_work,
+ DRM_HDCP_CHECK_PERIOD_MS);
+ else
+ DRM_ERROR("HDCP authentication failed (%d tries/%d)\n",
+ tries, ret);
return ret;
}
@@ -730,8 +735,6 @@ int intel_hdcp_enable(struct intel_connector *connector)
hdcp->hdcp_value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
schedule_work(&hdcp->hdcp_prop_work);
- schedule_delayed_work(&hdcp->hdcp_check_work,
- DRM_HDCP_CHECK_PERIOD_MS);
out:
mutex_unlock(&hdcp->hdcp_mutex);
return ret;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 30/40] drm/i915: Initialize HDCP2.2 and its MEI interface
Initialize HDCP2.2 support. This includes the mei interface
initialization along with required notifier registration.
v2:
mei interface handle is protected with mutex. [Chris Wilson]
v3:
Notifiers are used for the mei interface state.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_dp.c | 3 +-
drivers/gpu/drm/i915/intel_drv.h | 5 +-
drivers/gpu/drm/i915/intel_hdcp.c | 104 +-
drivers/gpu/drm/i915/intel_hdmi.c | 2 +-
4 files changed, 109 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 9a4a51e79fa1..955a20208097 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -6381,7 +6381,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, &intel_dp_hdcp_shim);
+ int ret = intel_hdcp_init(intel_connector, &intel_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 ca06d9a158f6..2f14756b4b0e 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -442,7 +442,7 @@ struct intel_hdcp {
/* mei interface related information */
struct mei_cl_device *cldev;
struct mei_hdcp_data mei_data;
-
+ struct notifier_block mei_cldev_nb;
struct delayed_work hdcp2_check_work;
};
@@ -1928,7 +1928,8 @@ 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);
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index 53d35ee8f683..6eb58a833c7d 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include "intel_drv.h"
#include "i915_reg.h"
@@ -25,6 +26,7 @@ static int _intel_hdcp2_enable(struct intel_connector
*connector);
static int _intel_hdcp2_disable(struct intel_connector *connector);
static void intel_hdcp2_check_work(struct work_struct *work);
static int intel_hdcp2_check_link(struct intel_connector *connector);
+static int intel_hdcp2_init(struct intel_connector *connector);
static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
const struct intel_hdcp_shim *shim)
@@ -686,11 +688,15 @@ bool is_hdcp_supported(struct drm_i915_private *dev_priv,
enum port port)
}
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)
{
struct intel_hdcp *hdcp = &connector->hdcp;
int ret;
+ if (!hdcp_shim)
+ return -EINVAL;
+
ret = drm_connector_attach_content_protection_property(
&connector->base);
if (ret)
@@ -699,7 +705,12 @@ int intel_hdcp_init(struct intel_connector *connector,
hdcp->hdcp_shim = hdcp_shim;
mutex_init(&hdcp->hdcp_mutex);
INIT_DELAYED_WORK(&hdcp->hdcp_check_work, intel_hdcp_check_work);
+ INIT_DELAYED_WORK(&hdcp->hdcp2_check_work, intel_hdcp2_check_work);
INIT_WORK(&hdcp->hdcp_prop_work, intel_hdcp_prop_work);
+
+ if (hdcp2_supported)
+ intel_hdcp2_init(connector);
+
return 0;
}
@@ -1565,3 +1576,94 @@ static void intel_hdcp2_check_work(struct work_struct
*work)
schedule_delayed_work(&hdcp->hdcp2_check_work,
DRM_HDCP2_CHECK_PERIOD_MS);
}
+
+static inline int initialize_mei_hdcp_data(struct intel_connector *connector)
+{
+ struct intel_hdcp *hdcp = &connector->hdcp;
+ struct mei_hdcp_data *data = &hdcp->mei_data;
+ enum port port;
+
+ if (connector->encoder) {
+ port = connector->encoder->port;
+ data->port = GET_MEI_DDI_INDEX(port);
+ }
+
+ data->port_type = INTEGRATED;
+ data->protocol = hdcp->hdcp_shim->hdcp_protocol();
+
+ data->k = 1;
+ if (!data->streams)
+ data->streams = kcall
[PATCH v3 24/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:
No Changes.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 135 ++
1 file changed, 135 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index ee9b7519fe73..d70320da85e4 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -1145,6 +1145,135 @@ static int hdcp2_session_key_exchange(struct
intel_connector *connector)
return 0;
}
+/*
+ * Lib endianness functions are aligned for 16/32/64 bits. Since here sequence
+ * num is 24bits developed a small conversion function.
+ */
+static inline void reverse_endianness(u8 *dest, size_t dst_sz, u8 *src)
+{
+ u32 index;
+
+ if (dest != NULL && dst_sz != 0) {
+ for (index = 0; index < dst_sz && index < sizeof(u32);
+index++) {
+ dest[dst_sz - index - 1] = src[index];
+ }
+ }
+}
+
+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 = &connector->hdcp;
+ union {
+ struct hdcp2_rep_stream_manage stream_manage;
+ struct hdcp2_rep_stream_ready stream_ready;
+ } msgs;
+ const struct intel_hdcp_shim *shim = hdcp->hdcp_shim;
+ int ret;
+
+ /* Prepare RepeaterAuth_Stream_Manage msg */
+ msgs.stream_manage.msg_id = HDCP_2_2_REP_STREAM_MANAGE;
+ reverse_endianness(msgs.stream_manage.seq_num_m, HDCP_2_2_SEQ_NUM_LEN,
+ (u8 *)&hdcp->seq_num_m);
+
+ /* K no of streams is fixed as 1. Stored as big-endian. */
+ msgs.stream_manage.k = __swab16(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, &msgs.stream_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,
+&msgs.stream_ready, sizeof(msgs.stream_ready));
+ if (ret < 0)
+ return ret;
+
+ hdcp->mei_data.seq_num_m = hdcp->seq_num_m;
+ hdcp->mei_data.streams[0].stream_type = hdcp->content_type;
+
+ ret = hdcp2_verify_mprime(hdcp, &msgs.stream_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 = &connector->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->hdcp_shim;
+ uint8_t *rx_info;
+ uint32_t seq_num_v;
+ int ret;
+
+ ret = shim->read_2_2_msg(intel_dig_port, HDCP_2_2_REP_SEND_RECVID_LIST,
+&msgs.recvid_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 -1;
+ }
+
+ /* Converting and Storing the seq_num_v to local variable as DWORD */
+ reverse_endianness((u8 *)&seq_num_v, HDCP_2_2_SEQ_NUM_LEN,
+ 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 -1;
+ }
+
+ ret = hdcp2_verify_rep_topology_prepare_ack(hdcp, &msgs.recvid_list,
+ &msgs.rep_ack);
+ if (ret < 0)
+ return ret;
+
+ hdcp->seq_num_v = seq_num_v;
+ ret = shim->write_2_2_msg(intel_dig_port, &msgs.rep_ack,
+ sizeof(msgs.rep_ack));
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
+static int hdcp2_authenticate_repeater(struct intel_connector *connector)
+{
+ int ret;
+
+ ret = hdcp2_authenticate_repeater_topology(conne
[PATCH v3 28/40] drm/i915: Handle HDCP2.2 downstream topology change
When repeater notifies a downstream topology change, this patch
reauthenticate the repeater alone with out disabling the hdcp
encryption. If that fails then complete reauthentication is executed.
v2:
Rebased.
v3:
No Changes.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index e2aec73aefe3..fd30e2b1ddc3 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -1497,8 +1497,23 @@ static int intel_hdcp2_check_link(struct intel_connector
*connector)
goto out;
}
- DRM_INFO("[%s:%d] HDCP2.2 link failed, retrying authentication\n",
-connector->base.name, connector->base.base.id);
+ if (ret == DRM_HDCP_TOPOLOGY_CHANGE) {
+ if (hdcp->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->hdcp_value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
+ schedule_work(&hdcp->hdcp_prop_work);
+ goto out;
+ }
+ DRM_ERROR("[%s:%d] Repeater topology auth failed.(%d)\n",
+ connector->base.name, connector->base.base.id, ret);
+ } else {
+ DRM_ERROR("[%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 v3 29/40] drm/i915: Pullout the bksv read and validation
For reusability purpose, this patch implements the hdcp1.4 bksv's
read and validation as a functions.
For detecting the HDMI panel's HDCP capability this fucntions will be
used.
v2:
Rebased.
v3:
No Changes.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 38 +-
1 file changed, 25 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index fd30e2b1ddc3..53d35ee8f683 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -152,6 +152,27 @@ bool intel_hdcp_is_ksv_valid(u8 *ksv)
return true;
}
+static inline
+int intel_hdcp_read_valid_bksv(struct intel_digital_port *intel_dig_port,
+ const struct intel_hdcp_shim *shim, u8 *bksv)
+{
+ int ret, i, tries = 2;
+
+ /* HDCP spec states that we must retry the bksv if it is invalid */
+ for (i = 0; i < tries; i++) {
+ ret = shim->read_bksv(intel_dig_port, bksv);
+ if (ret)
+ return ret;
+ if (intel_hdcp_is_ksv_valid(bksv))
+ break;
+ }
+ if (i == tries) {
+ DRM_ERROR("HDCP failed, Bksv is invalid\n");
+ return -ENODEV;
+ }
+ return 0;
+}
+
/* Implements Part 2 of the HDCP authorization procedure */
static
int intel_hdcp_auth_downstream(struct intel_digital_port *intel_dig_port,
@@ -411,7 +432,7 @@ static int intel_hdcp_auth(struct intel_digital_port
*intel_dig_port,
struct drm_i915_private *dev_priv;
enum port port;
unsigned long r0_prime_gen_start;
- int ret, i, tries = 2;
+ int ret, i;
union {
u32 reg[2];
u8 shim[DRM_HDCP_AN_LEN];
@@ -469,18 +490,9 @@ static int intel_hdcp_auth(struct intel_digital_port
*intel_dig_port,
memset(&bksv, 0, sizeof(bksv));
- /* HDCP spec states that we must retry the bksv if it is invalid */
- for (i = 0; i < tries; i++) {
- ret = shim->read_bksv(intel_dig_port, bksv.shim);
- if (ret)
- return ret;
- if (intel_hdcp_is_ksv_valid(bksv.shim))
- break;
- }
- if (i == tries) {
- DRM_ERROR("HDCP failed, Bksv is invalid\n");
- return -ENODEV;
- }
+ ret = intel_hdcp_read_valid_bksv(intel_dig_port, shim, bksv.shim);
+ if (ret < 0)
+ return ret;
I915_WRITE(PORT_HDCP_BKSVLO(port), bksv.reg[0]);
I915_WRITE(PORT_HDCP_BKSVHI(port), bksv.reg[1]);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 27/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:
No Changes.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 81 ++-
include/drm/drm_hdcp.h| 8
2 files changed, 88 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index 005627746ca5..e2aec73aefe3 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -23,6 +23,8 @@
static int _intel_hdcp2_enable(struct intel_connector *connector);
static int _intel_hdcp2_disable(struct intel_connector *connector);
+static void intel_hdcp2_check_work(struct work_struct *work);
+static int intel_hdcp2_check_link(struct intel_connector *connector);
static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
const struct intel_hdcp_shim *shim)
@@ -1456,6 +1458,83 @@ static int _intel_hdcp2_enable(struct intel_connector
*connector)
hdcp->hdcp_value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
schedule_work(&hdcp->hdcp_prop_work);
-
+ schedule_delayed_work(&hdcp->hdcp2_check_work,
+ DRM_HDCP2_CHECK_PERIOD_MS);
return 0;
}
+
+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 = &connector->hdcp;
+ enum port port = connector->encoder->port;
+ int ret = 0;
+
+ if (!hdcp->hdcp_shim)
+ return -ENOENT;
+
+ mutex_lock(&hdcp->hdcp_mutex);
+
+ if (hdcp->hdcp_value == DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
+ goto out;
+
+ if (!(I915_READ(HDCP2_STATUS_DDI(port)) & LINK_ENCRYPTION_STATUS)) {
+ DRM_ERROR("HDCP check failed: link is not encrypted, %x\n",
+ I915_READ(HDCP2_STATUS_DDI(port)));
+ ret = -ENXIO;
+ hdcp->hdcp_value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
+ schedule_work(&hdcp->hdcp_prop_work);
+ goto out;
+ }
+
+ ret = hdcp->hdcp_shim->check_2_2_link(intel_dig_port);
+ if (!ret) {
+ if (hdcp->hdcp_value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
+ hdcp->hdcp_value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
+ schedule_work(&hdcp->hdcp_prop_work);
+ }
+ goto out;
+ }
+
+ DRM_INFO("[%s:%d] HDCP2.2 link failed, retrying authentication\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->hdcp_value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
+ schedule_work(&hdcp->hdcp_prop_work);
+ goto out;
+ }
+
+ ret = _intel_hdcp2_enable(connector);
+ if (ret) {
+ DRM_ERROR("[%s:%d] Failed to enable hdcp2.2 (%d)\n",
+ connector->base.name, connector->base.base.id, ret);
+
+ hdcp->hdcp_value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
+ schedule_work(&hdcp->hdcp_prop_work);
+ goto out;
+ }
+
+out:
+ mutex_unlock(&hdcp->hdcp_mutex);
+ return ret;
+}
+
+static void intel_hdcp2_check_work(struct work_struct *work)
+{
+ struct intel_hdcp *hdcp = container_of(to_delayed_work(work),
+ struct intel_hdcp,
+ hdcp2_check_work);
+ struct intel_connector *connector = container_of(hdcp,
+ struct intel_connector,
+ hdcp);
+
+ if (!intel_hdcp2_check_link(connector))
+ schedule_delayed_work(&hdcp->hdcp2_check_work,
+ DRM_HDCP2_CHECK_PERIOD_MS);
+}
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index f3f28414b189..b0601215c798 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -11,6 +11,14 @@
/* 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
+
+enum
[PATCH v3 26/40] drm/i915: Implement HDCP2.2 En/Dis-able
Implements a sequence of enabling and disabling the HDCP2.2
(auth and encryption).
v2:
Rebased.
v3:
No Changes.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 75 +++
1 file changed, 75 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index 91cac643f083..005627746ca5 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -21,6 +21,9 @@
#define HDCP2_LC_RETRY_CNT 3
#define TIME_FOR_ENCRYPT_STATUS_CHANGE 32
+static int _intel_hdcp2_enable(struct intel_connector *connector);
+static int _intel_hdcp2_disable(struct intel_connector *connector);
+
static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
const struct intel_hdcp_shim *shim)
{
@@ -1384,3 +1387,75 @@ static int hdcp2_disable_encryption(struct
intel_connector *connector)
return ret;
}
+
+static int hdcp2_authenticate_and_encrypt(struct intel_connector *connector)
+{
+ int ret, i, tries = 3;
+
+ for (i = 0; i < tries; i++) {
+ ret = hdcp2_authenticate_sink(connector);
+ if (!ret)
+ break;
+
+ /* Clearing the mei hdcp session */
+ hdcp2_deauthenticate_port(&connector->hdcp);
+ DRM_DEBUG_KMS("HDCP2.2 Auth %d of %d Failed.(%d)\n",
+ i + 1, tries, ret);
+ }
+
+ if (i != tries) {
+
+ /*
+* Ensuring the required 200mSec min time interval between
+* Session Key Exchange and encryption.
+*/
+ msleep(HDCP_2_2_DELAY_BEFORE_ENCRYPTION_EN);
+ ret = hdcp2_enable_encryption(connector);
+ if (ret < 0) {
+ DRM_DEBUG_KMS("Encryption Enable Failed.(%d)\n", ret);
+ hdcp2_deauthenticate_port(&connector->hdcp);
+ }
+ }
+
+ return ret;
+}
+
+static int _intel_hdcp2_disable(struct intel_connector *connector)
+{
+ int ret;
+
+ DRM_DEBUG_KMS("[%s:%d] HDCP2.2 is being Disabled\n",
+ connector->base.name, connector->base.base.id);
+
+ ret = hdcp2_disable_encryption(connector);
+
+ hdcp2_deauthenticate_port(&connector->hdcp);
+
+ return ret;
+}
+
+static int _intel_hdcp2_enable(struct intel_connector *connector)
+{
+ struct intel_hdcp *hdcp = &connector->hdcp;
+ int ret;
+
+ DRM_DEBUG_KMS("[%s:%d] HDCP2.2 is being enabled. Type: %d\n",
+ connector->base.name, connector->base.base.id,
+ hdcp->content_type);
+
+ ret = hdcp2_authenticate_and_encrypt(connector);
+ if (ret) {
+ DRM_ERROR("HDCP2 Type%d Enabling Failed. (%d)\n",
+ hdcp->content_type, ret);
+ return ret;
+ }
+
+ DRM_DEBUG_KMS("[%s:%d] HDCP2.2 is enabled. Type %d\n",
+ connector->base.name, connector->base.base.id,
+ hdcp->content_type);
+
+ hdcp->hdcp_value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
+ schedule_work(&hdcp->hdcp_prop_work);
+
+ return 0;
+}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 25/40] drm/i915: Enable and Disable HDCP2.2 port encryption
Implements the enable and disable functions for HDCP2.2 encryption
of the PORT.
v2:
intel_wait_for_register is used instead of wait_for. [Chris Wilson]
v3:
No Changes.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 54 +++
1 file changed, 54 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index d70320da85e4..91cac643f083 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -19,6 +19,7 @@
(enum hdcp_physical_port) (port))
#define KEY_LOAD_TRIES 5
#define HDCP2_LC_RETRY_CNT 3
+#define TIME_FOR_ENCRYPT_STATUS_CHANGE 32
static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
const struct intel_hdcp_shim *shim)
@@ -1330,3 +1331,56 @@ static int hdcp2_authenticate_sink(struct
intel_connector *connector)
return ret;
}
+
+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 = &connector->hdcp;
+ enum port port = connector->encoder->port;
+ int ret;
+
+ if (I915_READ(HDCP2_STATUS_DDI(port)) & LINK_ENCRYPTION_STATUS)
+ return 0;
+
+ if (hdcp->hdcp_shim->toggle_signalling)
+ hdcp->hdcp_shim->toggle_signalling(intel_dig_port, true);
+
+ if (I915_READ(HDCP2_STATUS_DDI(port)) & LINK_AUTH_STATUS) {
+
+ /* Link is Authenticated. Now set for Encryption */
+ I915_WRITE(HDCP2_CTR_DDI(port),
+ I915_READ(HDCP2_CTR_DDI(port)) |
+ CTL_LINK_ENCRYPTION_REQ);
+ }
+
+ ret = intel_wait_for_register(dev_priv, HDCP2_STATUS_DDI(port),
+ LINK_ENCRYPTION_STATUS,
+ LINK_ENCRYPTION_STATUS,
+ TIME_FOR_ENCRYPT_STATUS_CHANGE);
+ return ret;
+}
+
+static int hdcp2_disable_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 = &connector->hdcp;
+ enum port port = connector->encoder->port;
+ int ret;
+
+ if (!(I915_READ(HDCP2_STATUS_DDI(port)) & LINK_ENCRYPTION_STATUS))
+ return 0;
+
+ I915_WRITE(HDCP2_CTR_DDI(port),
+ I915_READ(HDCP2_CTR_DDI(port)) & ~CTL_LINK_ENCRYPTION_REQ);
+
+ ret = intel_wait_for_register(dev_priv, HDCP2_STATUS_DDI(port),
+ LINK_ENCRYPTION_STATUS, 0x0,
+ TIME_FOR_ENCRYPT_STATUS_CHANGE);
+
+ if (hdcp->hdcp_shim->toggle_signalling)
+ hdcp->hdcp_shim->toggle_signalling(intel_dig_port, false);
+
+ return ret;
+}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 23/40] drm/i915: Implement HDCP2.2 receiver authentication
Implements HDCP2.2 authentication for hdcp2.2 receivers, with
following steps:
Authentication and Key enchange (AKE).
Locality Check (LC).
Session Key Exchange(SKE).
DP Errata for stream type confuguration 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_shim
defined.
v2:
Rebased.
v3:
No Changes.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 184 ++
1 file changed, 184 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index b4d56b21cf9b..ee9b7519fe73 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -18,6 +18,7 @@
#define GET_MEI_DDI_INDEX(port)(((port) == PORT_A) ? DDI_A : \
(enum hdcp_physical_port) (port))
#define KEY_LOAD_TRIES 5
+#define HDCP2_LC_RETRY_CNT 3
static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
const struct intel_hdcp_shim *shim)
@@ -1011,3 +1012,186 @@ static inline int hdcp2_deauthenticate_port(struct
intel_hdcp *hdcp)
{
return hdcp2_close_mei_session(hdcp);
}
+
+static int hdcp2_authentication_key_exchange(struct intel_connector *connector)
+{
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+ struct intel_hdcp *hdcp = &connector->hdcp;
+ union {
+ struct hdcp2_ake_init ake_init;
+ struct hdcp2_ake_send_cert send_cert;
+ struct hdcp2_ake_no_stored_km no_stored_km;
+ struct hdcp2_ake_send_hprime send_hprime;
+ struct hdcp2_ake_send_pairing_info pairing_info;
+ } msgs;
+ const struct intel_hdcp_shim *shim = hdcp->hdcp_shim;
+ size_t size;
+ int ret;
+
+ /* Init for seq_num */
+ hdcp->seq_num_v = 0;
+ hdcp->seq_num_m = 0;
+
+ ret = hdcp2_prepare_ake_init(hdcp, &msgs.ake_init);
+ if (ret < 0)
+ return ret;
+
+ ret = shim->write_2_2_msg(intel_dig_port, &msgs.ake_init,
+ sizeof(msgs.ake_init));
+ if (ret < 0)
+ return ret;
+
+ ret = shim->read_2_2_msg(intel_dig_port, HDCP_2_2_AKE_SEND_CERT,
+&msgs.send_cert, sizeof(msgs.send_cert));
+ if (ret < 0)
+ return ret;
+
+ if (msgs.send_cert.rx_caps[0] != HDCP_2_2_RX_CAPS_VERSION_VAL)
+ return -EINVAL;
+
+ hdcp->is_repeater = HDCP_2_2_RX_REPEATER(msgs.send_cert.rx_caps[2]);
+
+ /*
+* Here msgs.no_stored_km will hold msgs corresponding to the km
+* stored also.
+*/
+ ret = hdcp2_verify_rx_cert_prepare_km(hdcp, &msgs.send_cert,
+ &hdcp->is_paired,
+ &msgs.no_stored_km, &size);
+ if (ret < 0)
+ return ret;
+
+ ret = shim->write_2_2_msg(intel_dig_port, &msgs.no_stored_km, size);
+ if (ret < 0)
+ return ret;
+
+ ret = shim->read_2_2_msg(intel_dig_port, HDCP_2_2_AKE_SEND_HPRIME,
+&msgs.send_hprime, sizeof(msgs.send_hprime));
+ if (ret < 0)
+ return ret;
+
+ ret = hdcp2_verify_hprime(hdcp, &msgs.send_hprime);
+ if (ret < 0)
+ return ret;
+
+ if (!hdcp->is_paired) {
+ /* Pairing is required */
+ ret = shim->read_2_2_msg(intel_dig_port,
+HDCP_2_2_AKE_SEND_PARING_INFO,
+&msgs.pairing_info,
+sizeof(msgs.pairing_info));
+ if (ret < 0)
+ return ret;
+
+ ret = hdcp2_store_paring_info(hdcp, &msgs.pairing_info);
+ if (ret < 0)
+ return ret;
+ hdcp->is_paired = true;
+ }
+ return 0;
+}
+
+static int hdcp2_locality_check(struct intel_connector *connector)
+{
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+ struct intel_hdcp *hdcp = &connector->hdcp;
+ union {
+ struct hdcp2_lc_init lc_init;
+ struct hdcp2_lc_send_lprime send_lprime;
+ }
[PATCH v3 21/40] drm/i915: Define Intel HDCP2.2 registers
Intel HDCP2.2 registers are defined with addr offsets and bit details.
v2:
Replaced the arith calc with _PICK [Sean Paul]
v3:
No changes.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/i915_reg.h | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e6a8c0ee7df1..f04ad3c15abd 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8649,6 +8649,38 @@ enum skl_power_gate {
#define HDCP_STATUS_CIPHERBIT(16)
#define HDCP_STATUS_FRAME_CNT(x) ((x >> 8) & 0xff)
+/* HDCP2.2 Registers */
+#define _PORTA_HDCP2_BASE 0x66800
+#define _PORTB_HDCP2_BASE 0x66500
+#define _PORTC_HDCP2_BASE 0x66600
+#define _PORTD_HDCP2_BASE 0x66700
+#define _PORTE_HDCP2_BASE 0x66A00
+#define _PORTF_HDCP2_BASE 0x66900
+#define _PORT_HDCP2_BASE(port, x) _MMIO(_PICK(port, \
+ _PORTA_HDCP2_BASE, \
+ _PORTB_HDCP2_BASE, \
+ _PORTC_HDCP2_BASE, \
+ _PORTD_HDCP2_BASE, \
+ _PORTE_HDCP2_BASE, \
+ _PORTF_HDCP2_BASE) + x)
+
+#define HDCP2_AUTH_DDI(port) _PORT_HDCP2_BASE(port, 0x98)
+#define AUTH_LINK_AUTHENTICATED BIT(31)
+#define AUTH_LINK_TYPE BIT(30)
+#define AUTH_FORCE_CLR_INPUTCTR BIT(19)
+#define AUTH_CLR_KEYSBIT(18)
+
+#define HDCP2_CTR_DDI(port)_PORT_HDCP2_BASE(port, 0xB0)
+#define CTL_LINK_ENCRYPTION_REQ BIT(31)
+
+#define HDCP2_STATUS_DDI(port) _PORT_HDCP2_BASE(port, 0xB4)
+#define STREAM_ENCRYPTION_STATUS_A BIT(31)
+#define STREAM_ENCRYPTION_STATUS_B BIT(30)
+#define STREAM_ENCRYPTION_STATUS_C BIT(29)
+#define LINK_TYPE_STATUS BIT(22)
+#define LINK_AUTH_STATUS BIT(21)
+#define LINK_ENCRYPTION_STATUS BIT(20)
+
/* Per-pipe DDI Function Control */
#define _TRANS_DDI_FUNC_CTL_A 0x60400
#define _TRANS_DDI_FUNC_CTL_B 0x61400
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 11/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]
Signed-off-by: Ramalingam C
---
drivers/misc/mei/hdcp/mei_hdcp.c | 61
include/linux/mei_hdcp.h | 10 +++
2 files changed, 71 insertions(+)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index fa548310de7a..60afdd0cee79 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -244,6 +244,67 @@ int mei_verify_hprime(struct mei_cl_device *cldev, struct
mei_hdcp_data *data,
}
EXPORT_SYMBOL(mei_verify_hprime);
+/**
+ * mei_store_pairing_info:
+ * Function to store pairing info received from panel
+ *
+ * @cldev : Pointer for mei client device
+ * @data : Intel HW specific Data
+ * @pairing_info : Pointer for AKE_Send_Pairing_Info
+ *
+ * Returns 0 on Success, <0 on Failure
+ */
+
+int mei_store_pairing_info(struct mei_cl_device *cldev,
+ struct mei_hdcp_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 device *dev;
+ ssize_t byte;
+
+ if (!data || !pairing_info)
+ return -EINVAL;
+
+ dev = &cldev->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 = data->port;
+
+ memcpy(pairing_info_in.e_kh_km, pairing_info->e_kh_km,
+ sizeof(pairing_info_in.e_kh_km));
+
+ byte = mei_cldev_send(cldev, (u8 *)&pairing_info_in,
+ sizeof(pairing_info_in));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_send failed. %d\n", (int)byte);
+ return byte;
+ }
+
+ byte = mei_cldev_recv(cldev, (u8 *)&pairing_info_out,
+ sizeof(pairing_info_out));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_recv failed. %d\n", (int)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 -1;
+ }
+ return 0;
+}
+EXPORT_SYMBOL(mei_store_pairing_info);
+
void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool enabled)
{
if (enabled)
diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h
index 00bfde251ba4..be16e49d8018 100644
--- a/include/linux/mei_hdcp.h
+++ b/include/linux/mei_hdcp.h
@@ -118,6 +118,9 @@ mei_verify_receiver_cert_prepare_km(struct mei_cl_device
*cldev,
size_t *msg_sz);
int mei_verify_hprime(struct mei_cl_device *cldev, struct mei_hdcp_data *data,
struct hdcp2_ake_send_hprime *rx_hprime);
+int mei_store_pairing_info(struct mei_cl_device *cldev,
+ struct mei_hdcp_data *data,
+ struct hdcp2_ake_send_pairing_info *pairing_info);
#else
static int mei_cldev_register_notify(struct notifier_block *nb)
{
@@ -150,5 +153,12 @@ int mei_verify_hprime(struct mei_cl_device *cldev, struct
mei_hdcp_data *data,
{
return -ENODEV;
}
+static inline
+int mei_store_pairing_info(struct mei_cl_device *cldev,
+ struct mei_hdcp_data *data,
+ struct hdcp2_ake_send_pairing_info *pairing_info)
+{
+ return -ENODEV;
+}
#endif /* defined (CONFIG_INTEL_MEI_HDCP) */
#endif /* defined (_LINUX_MEI_HDCP_H) */
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 18/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]
Signed-off-by: Ramalingam C
---
drivers/misc/mei/hdcp/mei_hdcp.c | 55
include/linux/mei_hdcp.h | 7 +
2 files changed, 62 insertions(+)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index b5d1da41f1d9..ed402f1f2f64 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -686,6 +686,61 @@ int mei_enable_hdcp_authentication(struct mei_cl_device
*cldev,
}
EXPORT_SYMBOL(mei_enable_hdcp_authentication);
+/**
+ * me_close_hdcp_session:
+ * Function to close the Wired HDCP Tx session of ME FW.
+ * This also disables the authenticated state of the port.
+ *
+ * @data : Intel HW specific Data
+ *
+ * Returns 0 on Success, <0 on Failure
+ */
+int mei_close_hdcp_session(struct mei_cl_device *cldev,
+ struct mei_hdcp_data *data)
+{
+ struct wired_cmd_close_session_in session_close_in = { { 0 } };
+ struct wired_cmd_close_session_out session_close_out = { { 0 } };
+ struct device *dev;
+ ssize_t byte;
+
+ if (!data)
+ return -EINVAL;
+
+ dev = &cldev->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 = data->port;
+
+
+ byte = mei_cldev_send(cldev, (u8 *)&session_close_in,
+ sizeof(session_close_in));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_send failed. %d\n", (int)byte);
+ return byte;
+ }
+
+ byte = mei_cldev_recv(cldev, (u8 *)&session_close_out,
+ sizeof(session_close_out));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_recv failed. %d\n", (int)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 -1;
+ }
+ return 0;
+}
+EXPORT_SYMBOL(mei_close_hdcp_session);
+
void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool enabled)
{
if (enabled)
diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h
index 2366d0741abe..55cbde890571 100644
--- a/include/linux/mei_hdcp.h
+++ b/include/linux/mei_hdcp.h
@@ -138,6 +138,8 @@ int mei_verify_mprime(struct mei_cl_device *cldev, struct
mei_hdcp_data *data,
struct hdcp2_rep_stream_ready *stream_ready);
int mei_enable_hdcp_authentication(struct mei_cl_device *cldev,
struct mei_hdcp_data *data);
+int mei_close_hdcp_session(struct mei_cl_device *cldev,
+ struct mei_hdcp_data *data);
#else
static int mei_cldev_register_notify(struct notifier_block *nb)
{
@@ -216,5 +218,10 @@ static inline int mei_enable_hdcp_authentication(struct
mei_cl_device *cldev,
{
return -ENODEV;
}
+static inline int mei_close_hdcp_session(struct mei_cl_device *cldev,
+struct mei_hdcp_data *data)
+{
+ return -ENODEV;
+}
#endif /* defined (CONFIG_INTEL_MEI_HDCP) */
#endif /* defined (_LINUX_MEI_HDCP_H) */
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 13/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]
Signed-off-by: Ramalingam C
---
drivers/misc/mei/hdcp/mei_hdcp.c | 59
include/linux/mei_hdcp.h | 8 ++
2 files changed, 67 insertions(+)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 9bd7e66a91e4..ea84177311b7 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -361,6 +361,65 @@ int mei_initiate_locality_check(struct mei_cl_device
*cldev,
}
EXPORT_SYMBOL(mei_initiate_locality_check);
+/**
+ * mei_verify_lprime:
+ * Function to verify lprime.
+ *
+ * @cldev : Pointer for mei client device
+ * @data : Intel HW specific Data
+ * @rx_lprime : Pointer for LC_Send_L_prime
+ *
+ * Returns 0 on Success, <0 on Failure
+ */
+int mei_verify_lprime(struct mei_cl_device *cldev, struct mei_hdcp_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 device *dev;
+ ssize_t byte;
+
+ if (!data || !rx_lprime)
+ return -EINVAL;
+
+ dev = &cldev->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 = data->port;
+
+ memcpy(verify_lprime_in.l_prime, rx_lprime->l_prime,
+ sizeof(rx_lprime->l_prime));
+
+ byte = mei_cldev_send(cldev, (u8 *)&verify_lprime_in,
+ sizeof(verify_lprime_in));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_send failed. %d\n", (int)byte);
+ return byte;
+ }
+
+ byte = mei_cldev_recv(cldev, (u8 *)&verify_lprime_out,
+ sizeof(verify_lprime_out));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_recv failed. %d\n", (int)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 -1;
+ }
+ return 0;
+}
+EXPORT_SYMBOL(mei_verify_lprime);
+
void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool enabled)
{
if (enabled)
diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h
index d9c4cac0b276..792143563c46 100644
--- a/include/linux/mei_hdcp.h
+++ b/include/linux/mei_hdcp.h
@@ -124,6 +124,8 @@ int mei_store_pairing_info(struct mei_cl_device *cldev,
int mei_initiate_locality_check(struct mei_cl_device *cldev,
struct mei_hdcp_data *data,
struct hdcp2_lc_init *lc_init_data);
+int mei_verify_lprime(struct mei_cl_device *cldev, struct mei_hdcp_data *data,
+ struct hdcp2_lc_send_lprime *rx_lprime);
#else
static int mei_cldev_register_notify(struct notifier_block *nb)
{
@@ -170,5 +172,11 @@ int mei_initiate_locality_check(struct mei_cl_device
*cldev,
{
return -ENODEV;
}
+static inline
+int mei_verify_lprime(struct mei_cl_device *cldev, struct mei_hdcp_data *data,
+ struct hdcp2_lc_send_lprime *rx_lprime)
+{
+ return -ENODEV;
+}
#endif /* defined (CONFIG_INTEL_MEI_HDCP) */
#endif /* defined (_LINUX_MEI_HDCP_H) */
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 15/40] misc/mei/hdcp: Repeater topology verifcation and ack
Request ot ME to verify the downatream 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]
Signed-off-by: Ramalingam C
---
drivers/misc/mei/hdcp/mei_hdcp.c | 75
include/linux/mei_hdcp.h | 15
2 files changed, 90 insertions(+)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index abfcc57863b8..64fcecfa5b10 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -478,6 +478,81 @@ int mei_get_session_key(struct mei_cl_device *cldev,
struct mei_hdcp_data *data,
}
EXPORT_SYMBOL(mei_get_session_key);
+/**
+ * mei_repeater_check_flow_prepare_ack:
+ * Function to validate the Downstream topology and prepare rep_ack.
+ *
+ * @cldev : Pointer for mei client device
+ * @data : Intel HW specific Data
+ * @rep_topology : Pointer for Receiver Id List to be validated.
+ * @rep_send_ack : Pointer for repeater ack
+ *
+ * Returns 0 on Success, <0 on Failure
+ */
+
+int
+mei_repeater_check_flow_prepare_ack(struct mei_cl_device *cldev,
+ struct mei_hdcp_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 device *dev;
+ ssize_t byte;
+
+ if (!rep_topology || !rep_send_ack || !data)
+ return -EINVAL;
+
+ dev = &cldev->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 = 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_LPRIME_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 *)&verify_repeater_in,
+ sizeof(verify_repeater_in));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_send failed. %d\n", (int)byte);
+ return byte;
+ }
+
+ byte = mei_cldev_recv(cldev, (u8 *)&verify_repeater_out,
+ sizeof(verify_repeater_out));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_recv failed. %d\n", (int)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 -1;
+ }
+
+ memcpy(rep_send_ack->v, verify_repeater_out.v,
+ HDCP_2_2_LPRIME_HALF_LEN);
+ rep_send_ack->msg_id = HDCP_2_2_REP_SEND_ACK;
+ return 0;
+}
+EXPORT_SYMBOL(mei_repeater_check_flow_prepare_ack);
+
void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool enabled)
{
if (enabled)
diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h
index 534170d746af..46e2dc295d03 100644
--- a/include/linux/mei_hdcp.h
+++ b/include/linux/mei_hdcp.h
@@ -128,6 +128,12 @@ int mei_verify_lprime(struct mei_cl_device *cldev, struct
mei_hdcp_data *data,
struct hdcp2_lc_send_lprime *rx_lprime);
int mei_get_session_key(struct mei_cl_device *cldev, struct mei_hdcp_data
*data,
struct hdcp2_ske_send_eks *ske_data);
+int
+mei_repeater_check_flow_prepare_ack(struct mei_cl_device *cldev,
+ struct mei_hdcp_data *data,
+ struct hdcp2_rep_send_receiverid_list
+ *rep_topology,
+ struct hdcp2_rep_send_ack *rep_send_ack);
#else
static int mei_cldev_register_notify(struct notifier_block *nb)
{
@@ -186,5 +192,14 @@ int mei_get_session_key(str
[PATCH v3 17/40] misc/mei/hdcp: Enabling the HDCP authentication
Request to ME to configure a port as authenticated.
On Success, ME FW will mark th eport as authenticated and provides
HDCP chiper of the port with the encryption keys.
Enabling the Authentication can be requested once the all
stages of HDCP2.2 authentication is completed by interating 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]
Signed-off-by: Ramalingam C
---
drivers/misc/mei/hdcp/mei_hdcp.c | 54
include/linux/mei_hdcp.h | 7 ++
2 files changed, 61 insertions(+)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 68eb5267a8e7..b5d1da41f1d9 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -632,6 +632,60 @@ int mei_verify_mprime(struct mei_cl_device *cldev, struct
mei_hdcp_data *data,
}
EXPORT_SYMBOL(mei_verify_mprime);
+/**
+ * mei_enable_hdcp_authentication:
+ * Function to request ME FW to mark a port as authenticated.
+ *
+ * @cldev : Pointer for mei client device
+ * @data : Intel HW specific Data
+ *
+ * Returns 0 on Success, <0 on Failure
+ */
+int mei_enable_hdcp_authentication(struct mei_cl_device *cldev,
+ struct mei_hdcp_data *data)
+{
+ struct wired_cmd_enable_auth_in enable_auth_in = { { 0 } };
+ struct wired_cmd_enable_auth_out enable_auth_out = { { 0 } };
+ struct device *dev;
+ ssize_t byte;
+
+ if (!data)
+ return -EINVAL;
+
+ dev = &cldev->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 = data->port;
+ enable_auth_in.stream_type = data->streams[0].stream_type;
+
+ byte = mei_cldev_send(cldev, (u8 *)&enable_auth_in,
+ sizeof(enable_auth_in));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_send failed. %d\n", (int)byte);
+ return byte;
+ }
+
+ byte = mei_cldev_recv(cldev, (u8 *)&enable_auth_out,
+ sizeof(enable_auth_out));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_recv failed. %d\n", (int)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 -1;
+ }
+ return 0;
+}
+EXPORT_SYMBOL(mei_enable_hdcp_authentication);
+
void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool enabled)
{
if (enabled)
diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h
index dbc216e13f97..2366d0741abe 100644
--- a/include/linux/mei_hdcp.h
+++ b/include/linux/mei_hdcp.h
@@ -136,6 +136,8 @@ mei_repeater_check_flow_prepare_ack(struct mei_cl_device
*cldev,
struct hdcp2_rep_send_ack *rep_send_ack);
int mei_verify_mprime(struct mei_cl_device *cldev, struct mei_hdcp_data *data,
struct hdcp2_rep_stream_ready *stream_ready);
+int mei_enable_hdcp_authentication(struct mei_cl_device *cldev,
+ struct mei_hdcp_data *data);
#else
static int mei_cldev_register_notify(struct notifier_block *nb)
{
@@ -209,5 +211,10 @@ int mei_verify_mprime(struct mei_cl_device *cldev, struct
mei_hdcp_data *data,
{
return -ENODEV;
}
+static inline int mei_enable_hdcp_authentication(struct mei_cl_device *cldev,
+struct mei_hdcp_data *data)
+{
+ return -ENODEV;
+}
#endif /* defined (CONFIG_INTEL_MEI_HDCP) */
#endif /* defined (_LINUX_MEI_HDCP_H) */
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 19/40] drm/i915: wrapping all hdcp var into intel_hdcp
Considering the upcoming significant no HDCP2.2 variables, it will
be clean to have separate struct fo HDCP.
New structure called intel_hdcp is introduced.
v2:
struct hdcp statically allocated. [Sean Paul]
enable and disable function parameters are retained.[Sean Paul]
v3:
No Changes.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_display.c | 7 +--
drivers/gpu/drm/i915/intel_drv.h | 14 --
drivers/gpu/drm/i915/intel_hdcp.c| 94
3 files changed, 66 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 331084082545..2d7c47135e1a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15395,9 +15395,10 @@ static void intel_hpd_poll_fini(struct drm_device *dev)
for_each_intel_connector_iter(connector, &conn_iter) {
if (connector->modeset_retry_work.func)
cancel_work_sync(&connector->modeset_retry_work);
- if (connector->hdcp_shim) {
- cancel_delayed_work_sync(&connector->hdcp_check_work);
- cancel_work_sync(&connector->hdcp_prop_work);
+ if (connector->hdcp.hdcp_shim) {
+ cancel_delayed_work_sync(
+ &connector->hdcp.hdcp_check_work);
+ cancel_work_sync(&connector->hdcp.hdcp_prop_work);
}
}
drm_connector_list_iter_end(&conn_iter);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d4368589b355..fdffcb833cd2 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -377,6 +377,14 @@ struct intel_hdcp_shim {
bool *hdcp_capable);
};
+struct intel_hdcp {
+ const struct intel_hdcp_shim *hdcp_shim;
+ struct mutex hdcp_mutex;
+ uint64_t hdcp_value; /* protected by hdcp_mutex */
+ struct delayed_work hdcp_check_work;
+ struct work_struct hdcp_prop_work;
+};
+
struct intel_connector {
struct drm_connector base;
/*
@@ -409,11 +417,7 @@ struct intel_connector {
/* Work struct to schedule a uevent on link train failure */
struct work_struct modeset_retry_work;
- const struct intel_hdcp_shim *hdcp_shim;
- struct mutex hdcp_mutex;
- uint64_t hdcp_value; /* protected by hdcp_mutex */
- struct delayed_work hdcp_check_work;
- struct work_struct hdcp_prop_work;
+ struct intel_hdcp hdcp;
};
struct intel_digital_connector_state {
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index 14ca5d3057a7..1cca4f349064 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -547,6 +547,7 @@ struct intel_digital_port *conn_to_dig_port(struct
intel_connector *connector)
static int _intel_hdcp_disable(struct intel_connector *connector)
{
+ struct intel_hdcp *hdcp = &connector->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;
@@ -562,7 +563,7 @@ static int _intel_hdcp_disable(struct intel_connector
*connector)
return -ETIMEDOUT;
}
- ret = connector->hdcp_shim->toggle_signalling(intel_dig_port, false);
+ ret = hdcp->hdcp_shim->toggle_signalling(intel_dig_port, false);
if (ret) {
DRM_ERROR("Failed to disable HDCP signalling\n");
return ret;
@@ -574,6 +575,7 @@ static int _intel_hdcp_disable(struct intel_connector
*connector)
static int _intel_hdcp_enable(struct intel_connector *connector)
{
+ struct intel_hdcp *hdcp = &connector->hdcp;
struct drm_i915_private *dev_priv = connector->base.dev->dev_private;
int i, ret, tries = 3;
@@ -599,7 +601,7 @@ 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),
- connector->hdcp_shim);
+ hdcp->hdcp_shim);
if (!ret)
return 0;
@@ -615,36 +617,42 @@ static int _intel_hdcp_enable(struct intel_connector
*connector)
static void intel_hdcp_check_work(struct work_struct *work)
{
- struct intel_connector *connector = container_of(to_delayed_work(work),
+ struct intel_hdcp *hdcp = container_of(to_delayed_work(work),
+ struct intel_hdcp,
+ hdcp_check_work);
+ struct intel_connector *connector = container_of(hdcp,
[PATCH v3 22/40] drm/i915: Wrappers for mei HDCP2.2 services
Adds the wrapper for all mei hdcp2.2 service functions.
v2:
Rebased.
v3:
cldev is moved from mei_hdcp_data to hdcp.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 194 ++
1 file changed, 194 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index 1cca4f349064..b4d56b21cf9b 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -10,10 +10,13 @@
#include
#include
#include
+#include
#include "intel_drv.h"
#include "i915_reg.h"
+#define GET_MEI_DDI_INDEX(port)(((port) == PORT_A) ? DDI_A : \
+(enum hdcp_physical_port) (port))
#define KEY_LOAD_TRIES 5
static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
@@ -817,3 +820,194 @@ int intel_hdcp_check_link(struct intel_connector
*connector)
mutex_unlock(&hdcp->hdcp_mutex);
return ret;
}
+
+static int
+hdcp2_prepare_ake_init(struct intel_hdcp *hdcp, struct hdcp2_ake_init
*ake_data)
+{
+ struct mei_hdcp_data *data = &hdcp->mei_data;
+ struct intel_connector *connector = container_of(hdcp,
+struct intel_connector,
+hdcp);
+
+ if (!hdcp->cldev)
+ return -EINVAL;
+
+ if (data->port == INVALID_PORT && connector->encoder)
+ data->port = GET_MEI_DDI_INDEX(connector->encoder->port);
+
+ /* Clear ME FW instance for the port, just incase */
+ mei_close_hdcp_session(hdcp->cldev, data);
+
+ return mei_initiate_hdcp2_session(hdcp->cldev, data, ake_data);
+}
+
+static int hdcp2_close_mei_session(struct intel_hdcp *hdcp)
+{
+ struct mei_hdcp_data *data = &hdcp->mei_data;
+
+ if (!hdcp->cldev || data->port == INVALID_PORT)
+ return -EINVAL;
+
+ return mei_close_hdcp_session(hdcp->cldev, data);
+}
+
+static int
+hdcp2_verify_rx_cert_prepare_km(struct intel_hdcp *hdcp,
+ struct hdcp2_ake_send_cert *rx_cert,
+ bool *paired,
+ struct hdcp2_ake_no_stored_km *ek_pub_km,
+ size_t *msg_sz)
+{
+ struct mei_hdcp_data *data = &hdcp->mei_data;
+ int ret;
+
+ if (!hdcp->cldev)
+ return -EINVAL;
+
+ ret = mei_verify_receiver_cert_prepare_km(hdcp->cldev, data, rx_cert,
+ paired, ek_pub_km, msg_sz);
+ if (ret < 0)
+ mei_close_hdcp_session(hdcp->cldev, data);
+
+ return ret;
+}
+
+static int hdcp2_verify_hprime(struct intel_hdcp *hdcp,
+ struct hdcp2_ake_send_hprime *rx_hprime)
+{
+ struct mei_hdcp_data *data = &hdcp->mei_data;
+ int ret;
+
+ if (!hdcp->cldev)
+ return -EINVAL;
+
+ ret = mei_verify_hprime(hdcp->cldev, data, rx_hprime);
+ if (ret < 0)
+ mei_close_hdcp_session(hdcp->cldev, data);
+
+ return ret;
+}
+
+static int
+hdcp2_store_paring_info(struct intel_hdcp *hdcp,
+ struct hdcp2_ake_send_pairing_info *pairing_info)
+{
+ struct mei_hdcp_data *data = &hdcp->mei_data;
+ int ret;
+
+ if (!hdcp->cldev)
+ return -EINVAL;
+
+ ret = mei_store_pairing_info(hdcp->cldev, data, pairing_info);
+ if (ret < 0)
+ mei_close_hdcp_session(hdcp->cldev, data);
+
+ return ret;
+}
+
+static int
+hdcp2_prepare_lc_init(struct intel_hdcp *hdcp, struct hdcp2_lc_init *lc_init)
+{
+ struct mei_hdcp_data *data = &hdcp->mei_data;
+ int ret;
+
+ if (!hdcp->cldev)
+ return -EINVAL;
+
+ ret = mei_initiate_locality_check(hdcp->cldev, data, lc_init);
+ if (ret < 0)
+ mei_close_hdcp_session(hdcp->cldev, data);
+
+ return ret;
+}
+
+static int
+hdcp2_verify_lprime(struct intel_hdcp *hdcp,
+ struct hdcp2_lc_send_lprime *rx_lprime)
+{
+ struct mei_hdcp_data *data = &hdcp->mei_data;
+ int ret;
+
+ if (!hdcp->cldev)
+ return -EINVAL;
+
+ ret = mei_verify_lprime(hdcp->cldev, data, rx_lprime);
+ if (ret < 0)
+ mei_close_hdcp_session(hdcp->cldev, data);
+
+ return ret;
+}
+
+static int hdcp2_prepare_skey(struct intel_hdcp *hdcp,
+ struct hdcp2_ske_send_eks *ske_data)
+{
+ struct mei_hdcp_data *data = &hdcp->mei_data;
+ int ret;
+
+ if (!hdcp->cldev)
+ return -EINVAL;
+
+ ret = mei_get_session_key(hdcp->cldev, data, ske_data);
+ if (ret < 0)
+ mei_close_hdcp_session(hdcp->cldev, data);
+
+ return ret;
+}
+
+static int
+hdcp2_verify_rep_topology_prepare_ack(
+ struct intel_hdcp *hdcp,
+
[PATCH v3 20/40] drm/i915: Define HDCP2.2 related variables
For upcoming implementation of HDCP2.2 in I915, important variable
required for HDCP2.2 are defined.
HDCP_shim is extended to support encoder specific HDCP2.2 flows.
v2:
1.4 shim is extended to support hdcp2.2. [Sean Paul]
platform's/panel's hdcp ver capability is removed. [Sean Paul]
mei references in i915_private are moved to later patches. [Chris Wilson]
v3:
mei_cl_device ref is moved into intel_hdcp
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_drv.h | 61
1 file changed, 61 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index fdffcb833cd2..ca06d9a158f6 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include "i915_drv.h"
#include
@@ -375,6 +376,32 @@ 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);
+
+ /* 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,
+ uint8_t 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 Chiper for En/De-Cryption. Not applicable for HDMI.
+*/
+ int (*config_stream_type)(struct intel_digital_port *intel_dig_port,
+ void *buf, size_t size);
+
+ /* HDCP2.2 Link Integrity Check */
+ int (*check_2_2_link)(struct intel_digital_port *intel_dig_port);
+
+ /* Detects whether Panel is HDCP2.2 capable */
+ int (*hdcp_2_2_capable)(struct intel_digital_port *intel_dig_port,
+ bool *capable);
+
+ /* Detects the HDCP protocol(DP/HDMI) required on the port */
+ enum hdcp_protocol (*hdcp_protocol)(void);
};
struct intel_hdcp {
@@ -383,6 +410,40 @@ struct intel_hdcp {
uint64_t hdcp_value; /* protected by hdcp_mutex */
struct delayed_work hdcp_check_work;
struct work_struct hdcp_prop_work;
+
+ /** HDCP2.2 related definitions **/
+ 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;
+
+ 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.
+*/
+ uint32_t 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.
+*/
+ uint32_t seq_num_m;
+
+ /* mei interface related information */
+ struct mei_cl_device *cldev;
+ struct mei_hdcp_data mei_data;
+
+ struct delayed_work hdcp2_check_work;
};
struct intel_connector {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 14/40] misc/mei/hdcp: Prepare Session Key
Request to ME to prepare the encrypted session key.
On Success, ME provides Encrypted session key. Functions 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]
Signed-off-by: Ramalingam C
---
drivers/misc/mei/hdcp/mei_hdcp.c | 58
include/linux/mei_hdcp.h | 8 ++
2 files changed, 66 insertions(+)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index ea84177311b7..abfcc57863b8 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -420,6 +420,64 @@ int mei_verify_lprime(struct mei_cl_device *cldev, struct
mei_hdcp_data *data,
}
EXPORT_SYMBOL(mei_verify_lprime);
+/**
+ * mei_get_session_key:
+ * Function to prepare SKE_Send_Eks.
+ *
+ * @cldev : Pointer for mei client device
+ * @data : Intel HW specific Data
+ * @ske_data : Pointer for SKE_Send_Eks.
+ *
+ * Returns 0 on Success, <0 on Failure
+ */
+int mei_get_session_key(struct mei_cl_device *cldev, struct mei_hdcp_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 device *dev;
+ ssize_t byte;
+
+ if (!data || !ske_data)
+ return -EINVAL;
+
+ dev = &cldev->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 = data->port;
+
+ byte = mei_cldev_send(cldev, (u8 *)&get_skey_in, sizeof(get_skey_in));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_send failed. %d\n", (int)byte);
+ return byte;
+ }
+
+ byte = mei_cldev_recv(cldev, (u8 *)&get_skey_out, sizeof(get_skey_out));
+
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_recv failed. %d\n", (int)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 -1;
+ }
+
+ 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;
+}
+EXPORT_SYMBOL(mei_get_session_key);
+
void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool enabled)
{
if (enabled)
diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h
index 792143563c46..534170d746af 100644
--- a/include/linux/mei_hdcp.h
+++ b/include/linux/mei_hdcp.h
@@ -126,6 +126,8 @@ int mei_initiate_locality_check(struct mei_cl_device *cldev,
struct hdcp2_lc_init *lc_init_data);
int mei_verify_lprime(struct mei_cl_device *cldev, struct mei_hdcp_data *data,
struct hdcp2_lc_send_lprime *rx_lprime);
+int mei_get_session_key(struct mei_cl_device *cldev, struct mei_hdcp_data
*data,
+ struct hdcp2_ske_send_eks *ske_data);
#else
static int mei_cldev_register_notify(struct notifier_block *nb)
{
@@ -178,5 +180,11 @@ int mei_verify_lprime(struct mei_cl_device *cldev, struct
mei_hdcp_data *data,
{
return -ENODEV;
}
+static inline
+int mei_get_session_key(struct mei_cl_device *cldev, struct mei_hdcp_data
*data,
+ struct hdcp2_ske_send_eks *ske_data)
+{
+ return -ENODEV;
+}
#endif /* defined (CONFIG_INTEL_MEI_HDCP) */
#endif /* defined (_LINUX_MEI_HDCP_H) */
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 16/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]
Signed-off-by: Ramalingam C
---
drivers/misc/mei/hdcp/mei_hdcp.c | 79
include/linux/mei_hdcp.h | 8
2 files changed, 87 insertions(+)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 64fcecfa5b10..68eb5267a8e7 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -553,6 +553,85 @@ mei_repeater_check_flow_prepare_ack(struct mei_cl_device
*cldev,
}
EXPORT_SYMBOL(mei_repeater_check_flow_prepare_ack);
+static inline void reverse_endianness(u8 *dest, size_t dst_sz, u8 *src)
+{
+ u32 index;
+
+ if (dest != NULL && dst_sz != 0) {
+ for (index = 0; index < dst_sz && index < sizeof(u32);
+index++) {
+ dest[dst_sz - index - 1] = src[index];
+ }
+ }
+}
+
+/**
+ * mei_verify_mprime:
+ * Function to verify mprime.
+ *
+ * @cldev : Pointer for mei client device
+ * @data : Intel HW specific Data
+ * @stream_ready : pointer for RepeaterAuth_Stream_Ready message.
+ *
+ * Returns 0 on Success, <0 on Failure
+ */
+int mei_verify_mprime(struct mei_cl_device *cldev, struct mei_hdcp_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 device *dev;
+ ssize_t byte;
+
+ if (!stream_ready || !data)
+ return -EINVAL;
+
+ dev = &cldev->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 = data->port;
+
+ memcpy(verify_mprime_in.m_prime, stream_ready->m_prime,
+ HDCP_2_2_MPRIME_LEN);
+ reverse_endianness((u8 *)&verify_mprime_in.seq_num_m,
+ HDCP_2_2_SEQ_NUM_LEN, (u8 *)&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 *)&verify_mprime_in,
+ sizeof(verify_mprime_in));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_send failed. %d\n", (int)byte);
+ return byte;
+ }
+
+ byte = mei_cldev_recv(cldev, (u8 *)&verify_mprime_out,
+ sizeof(verify_mprime_out));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_recv failed. %d\n", (int)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 -1;
+ }
+ return 0;
+}
+EXPORT_SYMBOL(mei_verify_mprime);
+
void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool enabled)
{
if (enabled)
diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h
index 46e2dc295d03..dbc216e13f97 100644
--- a/include/linux/mei_hdcp.h
+++ b/include/linux/mei_hdcp.h
@@ -134,6 +134,8 @@ mei_repeater_check_flow_prepare_ack(struct mei_cl_device
*cldev,
struct hdcp2_rep_send_receiverid_list
*rep_topology,
struct hdcp2_rep_send_ack *rep_send_ack);
+int mei_verify_mprime(struct mei_cl_device *cldev, struct mei_hdcp_data *data,
+ struct hdcp2_rep_stream_ready *stream_ready);
#else
static int mei_cldev_register_notify(struct notifier_block *nb)
{
@@ -201,5 +203,11 @@ mei_repeater_check_flow_prepare_ack(struct mei_cl_device
*cldev,
{
return -ENODEV;
}
+static inline
+int mei_verify_mprime(struct mei_cl_device *cldev, struct mei_hdcp_data *data,
+ struct hdcp2_rep_stream_ready *stream_ready)
+{
+ return -ENODEV;
+}
#endif /* defin
[PATCH v3 10/40] misc/mei/hdcp: Verify H_prime
Requests for the verifcation of AKE_Send_H_prime.
ME will calculation the H and comparing it with received H_Prime.
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]
Signed-off-by: Ramalingam C
---
drivers/misc/mei/hdcp/mei_hdcp.c | 58
include/linux/mei_hdcp.h | 8 ++
2 files changed, 66 insertions(+)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 181994529058..fa548310de7a 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -186,6 +186,64 @@ mei_verify_receiver_cert_prepare_km(struct mei_cl_device
*cldev,
}
EXPORT_SYMBOL(mei_verify_receiver_cert_prepare_km);
+/**
+ * mei_verify_hprime:
+ * Function to verify AKE_Send_H_prime received
+ *
+ * @cldev : Pointer for mei client device
+ * @data : Intel HW specific Data
+ * @rx_hprime : Pointer for AKE_Send_H_prime
+ * @hprime_sz : Input buffer size
+ *
+ * Returns 0 on Success, <0 on Failure
+ */
+int mei_verify_hprime(struct mei_cl_device *cldev, struct mei_hdcp_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 device *dev;
+ ssize_t byte;
+
+ if (!data || !rx_hprime)
+ return -EINVAL;
+
+ dev = &cldev->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 = data->port;
+
+ memcpy(send_hprime_in.h_prime, rx_hprime->h_prime,
+ sizeof(rx_hprime->h_prime));
+
+ byte = mei_cldev_send(cldev, (u8 *)&send_hprime_in,
+ sizeof(send_hprime_in));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_send failed. %d\n", (int)byte);
+ return byte;
+ }
+
+ byte = mei_cldev_recv(cldev, (u8 *)&send_hprime_out,
+ sizeof(send_hprime_out));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_recv failed. %d\n", (int)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 -1;
+ }
+ return 0;
+}
+EXPORT_SYMBOL(mei_verify_hprime);
+
void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool enabled)
{
if (enabled)
diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h
index 314b15f6afc0..00bfde251ba4 100644
--- a/include/linux/mei_hdcp.h
+++ b/include/linux/mei_hdcp.h
@@ -116,6 +116,8 @@ mei_verify_receiver_cert_prepare_km(struct mei_cl_device
*cldev,
bool *km_stored,
struct hdcp2_ake_no_stored_km *ek_pub_km,
size_t *msg_sz);
+int mei_verify_hprime(struct mei_cl_device *cldev, struct mei_hdcp_data *data,
+ struct hdcp2_ake_send_hprime *rx_hprime);
#else
static int mei_cldev_register_notify(struct notifier_block *nb)
{
@@ -142,5 +144,11 @@ mei_verify_receiver_cert_prepare_km(struct mei_cl_device
*cldev,
{
return -ENODEV;
}
+static inline
+int mei_verify_hprime(struct mei_cl_device *cldev, struct mei_hdcp_data *data,
+ struct hdcp2_ake_send_hprime *rx_hprime)
+{
+ return -ENODEV;
+}
#endif /* defined (CONFIG_INTEL_MEI_HDCP) */
#endif /* defined (_LINUX_MEI_HDCP_H) */
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 08/40] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session
Request ME FW to start the HDCP2.2 session for a intel port.
Prepares payloads for command WIRED_INITIATE_HDCP2_SESSION and sent
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]
Signed-off-by: Ramalingam C
---
drivers/misc/mei/hdcp/mei_hdcp.c | 68
include/linux/mei_hdcp.h | 11 +++
2 files changed, 79 insertions(+)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 2811a25f8c57..7caee0947761 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -33,9 +33,77 @@
#include
#include
#include
+#include
+
+#include "mei_hdcp.h"
static BLOCKING_NOTIFIER_HEAD(mei_cldev_notifier_list);
+/**
+ * mei_initiate_hdcp2_session:
+ * Function to start a Wired HDCP2.2 Tx Session with ME FW
+ *
+ * @cldev : Pointer for mei client device
+ * @data : Intel HW specific Data
+ * @ake_data : ptr to store AKE_Init
+ *
+ * Returns 0 on Success, <0 on Failure.
+ */
+int mei_initiate_hdcp2_session(struct mei_cl_device *cldev,
+ struct mei_hdcp_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 device *dev;
+ ssize_t byte;
+
+ if (!data || !ake_data)
+ return -EINVAL;
+
+ dev = &cldev->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 = data->port;
+ session_init_in.protocol = (uint8_t)data->protocol;
+
+ byte = mei_cldev_send(cldev, (u8 *)&session_init_in,
+ sizeof(session_init_in));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_send failed. %d\n", (int)byte);
+ return byte;
+ }
+
+ byte = mei_cldev_recv(cldev, (u8 *)&session_init_out,
+ sizeof(session_init_out));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_recv failed. %d\n", (int)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 -1;
+ }
+
+ 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,
+ sizeof(session_init_out.r_tx));
+
+ return 0;
+}
+EXPORT_SYMBOL(mei_initiate_hdcp2_session);
+
void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool enabled)
{
if (enabled)
diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h
index 634c1a5bdf1e..bb4f27d3abcb 100644
--- a/include/linux/mei_hdcp.h
+++ b/include/linux/mei_hdcp.h
@@ -28,6 +28,7 @@
#define _LINUX_MEI_HDCP_H
#include
+#include
enum mei_cldev_state {
MEI_CLDEV_DISABLED,
@@ -105,6 +106,9 @@ struct mei_hdcp_data {
#ifdef CONFIG_INTEL_MEI_HDCP
int mei_cldev_register_notify(struct notifier_block *nb);
int mei_cldev_unregister_notify(struct notifier_block *nb);
+int mei_initiate_hdcp2_session(struct mei_cl_device *cldev,
+ struct mei_hdcp_data *data,
+ struct hdcp2_ake_init *ake_data);
#else
static int mei_cldev_register_notify(struct notifier_block *nb)
{
@@ -114,5 +118,12 @@ static int mei_cldev_unregister_notify(struct
notifier_block *nb)
{
return -ENODEV;
}
+static inline
+int mei_initiate_hdcp2_session(struct mei_cl_device *cldev,
+ struct mei_hdcp_data *data,
+ struct hdcp2_ake_init *ake_data)
+{
+ return -ENODEV;
+}
#endif /* defined (CONFIG_INTEL_MEI_HDCP) */
#endif /* defined (_LINUX_MEI_HDCP_H) */
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 12/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]
Signed-off-by: Ramalingam C
---
drivers/misc/mei/hdcp/mei_hdcp.c | 56
include/linux/mei_hdcp.h | 10 +++
2 files changed, 66 insertions(+)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 60afdd0cee79..9bd7e66a91e4 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -305,6 +305,62 @@ int mei_store_pairing_info(struct mei_cl_device *cldev,
}
EXPORT_SYMBOL(mei_store_pairing_info);
+/**
+ * mei_initiate_locality_check:
+ * Function to prepare LC_Init.
+ *
+ * @cldev : Pointer for mei client device
+ * @data : Intel HW specific Data
+ * @hdcp2_lc_init : Pointer for storing LC_Init
+ *
+ * Returns 0 on Success, <0 on Failure
+ */
+int mei_initiate_locality_check(struct mei_cl_device *cldev,
+ struct mei_hdcp_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 device *dev;
+ ssize_t byte;
+
+ if (!data || !lc_init_data)
+ return -EINVAL;
+
+ dev = &cldev->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 = data->port;
+
+ byte = mei_cldev_send(cldev, (u8 *)&lc_init_in, sizeof(lc_init_in));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_send failed. %d\n", (int)byte);
+ return byte;
+ }
+
+ byte = mei_cldev_recv(cldev, (u8 *)&lc_init_out, sizeof(lc_init_out));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_recv failed. %d\n", (int)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 -1;
+ }
+
+ 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;
+}
+EXPORT_SYMBOL(mei_initiate_locality_check);
+
void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool enabled)
{
if (enabled)
diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h
index be16e49d8018..d9c4cac0b276 100644
--- a/include/linux/mei_hdcp.h
+++ b/include/linux/mei_hdcp.h
@@ -121,6 +121,9 @@ int mei_verify_hprime(struct mei_cl_device *cldev, struct
mei_hdcp_data *data,
int mei_store_pairing_info(struct mei_cl_device *cldev,
struct mei_hdcp_data *data,
struct hdcp2_ake_send_pairing_info *pairing_info);
+int mei_initiate_locality_check(struct mei_cl_device *cldev,
+ struct mei_hdcp_data *data,
+ struct hdcp2_lc_init *lc_init_data);
#else
static int mei_cldev_register_notify(struct notifier_block *nb)
{
@@ -160,5 +163,12 @@ int mei_store_pairing_info(struct mei_cl_device *cldev,
{
return -ENODEV;
}
+static inline
+int mei_initiate_locality_check(struct mei_cl_device *cldev,
+ struct mei_hdcp_data *data,
+ struct hdcp2_lc_init *lc_init_data)
+{
+ return -ENODEV;
+}
#endif /* defined (CONFIG_INTEL_MEI_HDCP) */
#endif /* defined (_LINUX_MEI_HDCP_H) */
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 09/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]
Signed-off-by: Ramalingam C
---
drivers/misc/mei/hdcp/mei_hdcp.c | 82
include/linux/mei_hdcp.h | 17 +
2 files changed, 99 insertions(+)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 7caee0947761..181994529058 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -104,6 +104,88 @@ int mei_initiate_hdcp2_session(struct mei_cl_device *cldev,
}
EXPORT_SYMBOL(mei_initiate_hdcp2_session);
+/**
+ * mei_verify_receiver_cert_prepare_km:
+ * Function to verify the Receiver Certificate AKE_Send_Cert
+ * and prepare AKE_Stored_Km or AKE_No_Stored_Km
+ *
+ * @cldev : Pointer for mei client device
+ * @data : Intel HW specific Data
+ * @rx_cert: Pointer for AKE_Send_Cert
+ * @km_stored : Pointer for pairing status flag
+ * @ek_pub_km : Pointer for output msg
+ * @msg_sz : Pointer for size of AKE_X_Km
+ *
+ * Returns 0 on Success, <0 on Failure
+ */
+int
+mei_verify_receiver_cert_prepare_km(struct mei_cl_device *cldev,
+ struct mei_hdcp_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 device *dev;
+ ssize_t byte;
+
+ if (!data || !rx_cert || !km_stored || !ek_pub_km || !msg_sz)
+ return -EINVAL;
+
+ dev = &cldev->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 = data->port;
+
+ memcpy(&verify_rxcert_in.cert_rx, &rx_cert->cert_rx,
+ sizeof(rx_cert->cert_rx));
+ memcpy(verify_rxcert_in.r_rx, &rx_cert->r_rx, sizeof(rx_cert->r_rx));
+ memcpy(verify_rxcert_in.rx_caps, rx_cert->rx_caps, HDCP_2_2_RXCAPS_LEN);
+
+ byte = mei_cldev_send(cldev, (u8 *)&verify_rxcert_in,
+ sizeof(verify_rxcert_in));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_send failed: %d\n", (int)byte);
+ return byte;
+ }
+
+ byte = mei_cldev_recv(cldev, (u8 *)&verify_rxcert_out,
+ sizeof(verify_rxcert_out));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_recv failed: %d\n", (int)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 -1;
+ }
+
+ *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, &verify_rxcert_out.ekm_buff,
+ sizeof(verify_rxcert_out.ekm_buff));
+ return 0;
+}
+EXPORT_SYMBOL(mei_verify_receiver_cert_prepare_km);
+
void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool enabled)
{
if (enabled)
diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h
index bb4f27d3abcb..314b15f6afc0 100644
--- a/include/linux/mei_hdcp.h
+++ b/include/linux/mei_hdcp.h
@@ -109,6 +109,13 @@ int mei_cldev_unregister_notify(struct notifier_block *nb);
int mei_initiate_hdcp2_session(struct mei_cl_device *cldev,
struct mei_hdcp_data *data,
struct hdcp2_ake_init *ake_data);
+int
+mei_verify_receiver_cert_prepare_km(struct mei_
[PATCH v3 03/40] mei: bus: whitelist hdcp client
From: Tomas Winkler
Whitelist HDCP client for in kernel drm use
v2:
Rebased.
v3:
No changes.
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 0208c4b027c5..3df2a69fddfb 100644
--- a/drivers/misc/mei/bus-fixup.c
+++ b/drivers/misc/mei/bus-fixup.c
@@ -41,6 +41,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
/**
@@ -72,6 +75,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(&cldev->dev, "running hook %s\n", __func__);
+
+ cldev->do_match = 1;
+}
+
#define OSTYPE_LINUX2
struct mei_os_ver {
__le16 build;
@@ -399,6 +414,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 v3 07/40] linux/mei: Header for mei_hdcp driver interface
Data structures and Enum for the I915-MEI_HDCP interface are defined
at
v2:
Rebased.
v3:
mei_cl_device is removed from mei_hdcp_data [Tomas]
Signed-off-by: Ramalingam C
---
include/linux/mei_hdcp.h | 70
1 file changed, 70 insertions(+)
diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h
index 3b46bebde718..634c1a5bdf1e 100644
--- a/include/linux/mei_hdcp.h
+++ b/include/linux/mei_hdcp.h
@@ -27,11 +27,81 @@
#ifndef _LINUX_MEI_HDCP_H
#define _LINUX_MEI_HDCP_H
+#include
+
enum mei_cldev_state {
MEI_CLDEV_DISABLED,
MEI_CLDEV_ENABLED
};
+/*
+ * Enumeration of the physical DDI available on the platform
+ */
+enum hdcp_physical_port {
+ INVALID_PORT = 0x00,/* Not a valid port */
+
+ DDI_RANGE_BEGIN = 0x01, /* Beginning of the valid DDI port range */
+ DDI_B = 0x01, /* Port DDI B */
+ DDI_C = 0x02, /* Port DDI C */
+ DDI_D = 0x03, /* Port DDI D */
+ DDI_E = 0x04, /* Port DDI E */
+ DDI_F = 0x05, /* Port DDI F */
+ DDI_A = 0x07, /* Port DDI A */
+ DDI_RANGE_END = DDI_A,/* End of the valid DDI port range */
+};
+
+/* The types of HDCP 2.2 ports supported */
+enum hdcp_integrated_port_type {
+ HDCP_INVALID_TYPE = 0x00,
+
+ /* HDCP 2.x ports that are integrated into Intel HW */
+ INTEGRATED = 0x01,
+
+ /* HDCP2.2 discrete wired Tx port with LSPCON (HDMI 2.0) solution */
+ LSPCON = 0x02,
+
+ /* HDCP2.2 discrete wired Tx port using the CPDP (DP 1.3) solution */
+ CPDP= 0x03,
+};
+
+/**
+ * wired_protocol: Supported integrated wired HDCP protocol.
+ * Based on this value, Minor differenceneeded between wired specifications
+ * are handled.
+ */
+enum hdcp_protocol {
+ HDCP_PROTOCOL_INVALID,
+ HDCP_PROTOCOL_HDMI,
+ HDCP_PROTOCOL_DP
+};
+
+/**
+ * mei_hdcp_data: Input data to the mei_hdcp APIs.
+ */
+struct mei_hdcp_data {
+ enum hdcp_physical_port port;
+ enum hdcp_integrated_port_type port_type;
+ enum hdcp_protocol protocol;
+
+ /*
+* No of streams transmitted on a port.
+* In case of HDMI & DP SST, single stream will be
+* transmitted on a port.
+*/
+ uint16_t k;
+
+ /*
+* 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.
+*/
+ uint32_t seq_num_m;
+
+ /* k(No of Streams per port) x structure of wired_streamid_type */
+ struct hdcp2_streamid_type *streams;
+};
+
#ifdef CONFIG_INTEL_MEI_HDCP
int mei_cldev_register_notify(struct notifier_block *nb);
int mei_cldev_unregister_notify(struct notifier_block *nb);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
