[Bug 104854] smu7_populate_single_firmware_entry fails to load powerplay firmware.
https://bugs.freedesktop.org/show_bug.cgi?id=104854
José Pekkarinen changed:
What|Removed |Added
Attachment #137911|0 |1
is obsolete||
--- Comment #4 from José Pekkarinen ---
Created attachment 137923
--> https://bugs.freedesktop.org/attachment.cgi?id=137923&action=edit
Right boot initialization
Unfortunately it seems to have been once that it booted properly, today it
doesn't boot well anymore. Here is what I could recover from that one. The plus
of the kernel is for the following irrelevant patch that hogs my boot in a
different way:
diff --git a/block/blk-core.c b/block/blk-core.c
index 82b92adf3477..f05714bea9ad 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -3650,10 +3650,6 @@ EXPORT_SYMBOL(blk_finish_plug);
*/
void blk_pm_runtime_init(struct request_queue *q, struct device *dev)
{
- /* not support for RQF_PM and ->rpm_status in blk-mq yet */
- if (q->mq_ops)
- return;
-
q->dev = dev;
q->rpm_status = RPM_ACTIVE;
pm_runtime_set_autosuspend_delay(q->dev, -1);
Please don't hesitate to ask for any other output you may need.
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
Re: [PATCH v2 2/6] drm/i915: Move DP modeset retry work into intel_dp
On Thu, Mar 08, 2018 at 06:41:22PM -0500, Lyude Paul wrote:
> While having the modeset_retry_work in intel_connector makes sense with
> SST, this paradigm doesn't make a whole ton of sense when it comes to
> MST since we have to deal with multiple connectors. In most cases, it's
> more useful to just use the intel_dp struct since it indicates whether
> or not we're dealing with an MST device, along with being able to easily
> trace the intel_dp struct back to it's respective connector (if there is
> any). So, move the modeset_retry_work function out of the
> intel_connector struct and into intel_dp.
>
> V2:
> - Remove accidental duplicate modeset_retry_work in intel_connector
>
> Signed-off-by: Lyude Paul
> Cc: Manasi Navare
> Cc: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 23 +--
> drivers/gpu/drm/i915/intel_dp.c | 10 --
> drivers/gpu/drm/i915/intel_dp_link_training.c | 2 +-
> drivers/gpu/drm/i915/intel_drv.h | 6 +++---
> 4 files changed, 29 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index f424fff477f6..85d5af4e4f5b 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15394,16 +15394,35 @@ static void intel_hpd_poll_fini(struct drm_device
> *dev)
> {
> struct intel_connector *connector;
> struct drm_connector_list_iter conn_iter;
> + struct work_struct *work;
>
> /* Kill all the work that may have been queued by hpd. */
> drm_connector_list_iter_begin(dev, &conn_iter);
> 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->base.connector_type !=
> + DRM_MODE_CONNECTOR_DisplayPort)
I know we dont fallback on eDP now but since link training is a common code
between
eDP and DP, this modeset retry can also be called from eDP. So we should check
against
DRM_MODE_CONNECTOR_eDP type as well.
Other than that, I agree that it is better for this work function to be part of
intel_dp struct
as opposed to intel_connector.
So after this change,
Reviewed-by: Manasi Navare
Manasi
> + continue;
> +
> + if (connector->mst_port) {
> + work = &connector->mst_port->modeset_retry_work;
> + } else {
> + struct intel_encoder *intel_encoder =
> + connector->encoder;
> + struct intel_dp *intel_dp;
> +
> + if (!intel_encoder)
> + continue;
> +
> + intel_dp = enc_to_intel_dp(&intel_encoder->base);
> + work = &intel_dp->modeset_retry_work;
> + }
> +
> + cancel_work_sync(work);
> }
> drm_connector_list_iter_end(&conn_iter);
> }
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 4dd1b2287dd6..5abf0c95725a 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -6261,12 +6261,10 @@ static bool intel_edp_init_connector(struct intel_dp
> *intel_dp,
>
> static void intel_dp_modeset_retry_work_fn(struct work_struct *work)
> {
> - struct intel_connector *intel_connector;
> - struct drm_connector *connector;
> + struct intel_dp *intel_dp = container_of(work, typeof(*intel_dp),
> + modeset_retry_work);
> + struct drm_connector *connector = &intel_dp->attached_connector->base;
>
> - intel_connector = container_of(work, typeof(*intel_connector),
> -modeset_retry_work);
> - connector = &intel_connector->base;
> DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
> connector->name);
>
> @@ -6295,7 +6293,7 @@ intel_dp_init_connector(struct intel_digital_port
> *intel_dig_port,
> int type;
>
> /* Initialize the work for modeset in case of link train failure */
> - INIT_WORK(&intel_connector->modeset_retry_work,
> + INIT_WORK(&intel_dp->modeset_retry_work,
> intel_dp_modeset_retry_work_fn);
>
> if (WARN(intel_dig_port->max_lanes < 1,
> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
> b/drivers/gpu/drm/i915/intel_dp_link_training.c
> index f59b59bb0a21..2cfa58ce1f95 100644
> --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> @@ -340,7 +340,7 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
>
Re: [PATCH 1/6] drm/i915: Remove unused DP_LINK_CHECK_TIMEOUT
On Thu, Mar 08, 2018 at 06:24:15PM -0500, Lyude Paul wrote: > Signed-off-by: Lyude Paul > Cc: Manasi Navare > Cc: Ville Syrjälä Reviewed-by: Manasi Navare > --- > drivers/gpu/drm/i915/intel_dp.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index 9a4a51e79fa1..4dd1b2287dd6 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -43,7 +43,6 @@ > #include > #include "i915_drv.h" > > -#define DP_LINK_CHECK_TIMEOUT(10 * 1000) > #define DP_DPRX_ESI_LEN 14 > > /* Compliance test status bits */ > -- > 2.14.3 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm fixes for 4.16-rc5
Hi Linus, There are a small set of sun4i and i915 fixes: sun4i: divide by zero, clock and LVDS fixes i915: 1 fix for perf and a 1 race fix However amdgpu is a bit more than we are normally comfortable with at this point, however it does fix a lot of display issues with the new DC code which result in black screens in various configurations along with some run of the mill gpu configuration fixes. I'm happy enough that the fixes are limited to the DC code and should fix a bunch of issues on the new raven ridge APUs that we are seeing shipped now. Thanks, Dave. The following changes since commit 661e50bc853209e41a5c14a290ca4decc43cbfd1: Linux 4.16-rc4 (2018-03-04 14:54:11 -0800) are available in the Git repository at: git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.16-rc5 for you to fetch changes up to b0655d668fc4faf0c1985e828820f9b9ca13abe6: Merge branch 'drm-fixes-4.16' of git://people.freedesktop.org/~agd5f/linux into drm-fixes (2018-03-09 09:23:02 +1000) amdgfx, i915, sun4i fixes Alex Deucher (3): drm/amdgpu: used cached pcie gen info for SI (v2) drm/radeon: fix KV harvesting drm/amdgpu: fix KV harvesting Bhawanpreet Lakha (1): drm/amd/display: Fix takover from VGA mode Chris Wilson (1): drm/i915: Suspend submission tasklets around wedging Dave Airlie (3): Merge tag 'drm-intel-fixes-2018-03-07' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Merge tag 'drm-misc-fixes-2018-03-07' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Merge branch 'drm-fixes-4.16' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Eric Yang (3): drm/amd/display: fix cursor related Pstate hang drm/amd/display: update infoframe after dig fe is turned on drm/amd/display: early return if not in vga mode in disable_vga Giulio Benetti (1): drm/sun4i: Fix dclk_set_phase Harry Wentland (11): drm/amd/display: Don't blow up if TG is NULL in dce110_vblank_set drm/amd/display: Default HDMI6G support to true. Log VBIOS table error. drm/amd/display: Move MAX_TMDS_CLOCK define to header drm/amd/display: Remove unnecessary fail labels in create_stream_for_sink drm/amd/display: Pass signal directly to enable_tmds_output drm/amd/display: Don't allow dual-link DVI on all ASICs. drm/amd/display: Don't block dual-link DVI modes drm/amd/display: Make create_stream_for_sink more consistent drm/amd/display: Call update_stream_signal directly from amdgpu_dm drm/amd/display: Use crtc enable/disable_vblank hooks drm/amd/display: Return success when enabling interrupt James Zhu (2): drm/amdgpu:Correct max uvd handles drm/amdgpu:Always save uvd vcpu_bo in VM Mode Jernej Skrabec (1): drm/sun4i: Release exclusive clock lock when disabling TCON Jerry (Fangzhi) Zuo (2): drm/amd/display: Fix topology change issue in MST rehook drm/amd/display: Fixed non-native modes not lighting up Leo (Sunpeng) Li (1): drm/amd/display: Fix memleaks when atomic check fails. Lionel Landwerlin (1): drm/i915/perf: fix perf stream opening lock Maxime Ripard (3): drm/sun4i: tcon: Reduce the scope of the LVDS error a bit drm/sun4i: rgb: Fix potential division by zero drm/sun4i: crtc: Call drm_crtc_vblank_on / drm_crtc_vblank_off Michel Dänzer (1): drm/amdgpu/dce6: Use DRM_DEBUG instead of DRM_INFO for HPD IRQ info Mikita Lipski (1): drm/amd/display: Set irq state only on existing crtcs Rex Zhu (1): drm/amdgpu: Notify sbios device ready before send request Roman Li (3): drm/amd/display: Fix active dongle hotplug drm/amd/display: Fix FBC topology change drm/amd/display: fix boot-up on vega10 Shirish S (5): drm/amd/display: defer modeset check in dm_update_planes_state drm/amd/display: validate plane in dce110 for scaling drm/amd/display: update plane params before validation drm/amd/display: disable CRTCs with NULL FB on their primary plane (V2) drm/amd/display: validate plane format on primary plane Tom St Denis (1): drm/amd/amdgpu: Mask rptr as well in ring debugfs drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 3 + drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c| 13 +- drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 2 +- drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 30 +--- drivers/gpu/drm/amd/amdgpu/si.c| 22 ++- drivers/gpu/drm/amd/amdgpu/si_dpm.c| 50 ++- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 165 +++-- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c | 6 +- .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 6 + drivers/gpu/d
[PATCH v7 5/9] drm: Handle aspect-ratio info in getblob
From: Ankit Nautiyal
If the user-space does not support aspect-ratio, then getblob called
with the blob id of a user-mode, should clear the aspect-ratio
information in the blob data.
Currently for a given blob id, there is no way to determine if the
blob stores user-mode or not. This can only be ascertained when the
blob is used for an atomic modeset call.
This patch:
-adds a new field 'is_video_mode' in drm_property_blob to
differentiate between the video mode blobs and the other blobs.
-sets the field 'is_video_mode' when the blob is used for modeset.
-removes the aspect-ratio info from the user-mode data if aspect-ratio
is not supported by the user, while returning the blob to the user,
in getblob ioctl.
Signed-off-by: Ankit Nautiyal
V6: As suggested by Ville:
-added helper functions for determining if aspect-ratio is
expected in user-mode and for allowing/disallowing the
aspect-ratio, if its not expected.
-avoided clobbering of blob-data, instead cleared the aspect-ratio
in the user-mode only, so that another client with aspect-ratio
cap, can still get the aspect-ratio information from getblob.
V7: Fixed warning [Wint-to-pointer-cast] for 32 bit platforms.
---
drivers/gpu/drm/drm_atomic.c | 1 +
drivers/gpu/drm/drm_modes.c| 44 ++
drivers/gpu/drm/drm_property.c | 5 +
include/drm/drm_modes.h| 4
include/drm/drm_property.h | 2 ++
5 files changed, 56 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 34b7d42..2b1c88a 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -464,6 +464,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
else if (property == config->prop_mode_id) {
struct drm_property_blob *mode =
drm_property_lookup_blob(dev, val);
+ mode->is_video_mode = true;
ret = drm_atomic_set_mode_prop_for_crtc(state, mode);
drm_property_blob_put(mode);
return ret;
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index a48672c..4430294 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1761,3 +1761,47 @@ bool drm_mode_is_420(const struct drm_display_info
*display,
drm_mode_is_420_also(display, mode);
}
EXPORT_SYMBOL(drm_mode_is_420);
+
+/**
+ * drm_mode_aspect_ratio_allowed - checks if the aspect-ratio information
+ * is expected from the user-mode.
+ *
+ * If the user has set aspect-ratio cap, then the flag of the user-mode is
+ * allowed to contain aspect-ratio value.
+ * If the user does not set aspect-ratio cap, then the only value allowed in
the
+ * flags bits is aspect-ratio NONE.
+ *
+ * @file_priv: file private structure to get the user capabilities
+ * @flags: 32 bit flag that contains the aspect-ratio information.
+ *
+ * Returns:
+ * true if the aspect-ratio info is allowed in the user-mode flags.
+ * false, otherwise.
+ */
+bool
+drm_mode_aspect_ratio_allowed(const struct drm_file *file_priv, uint32_t flags)
+{
+ return file_priv->aspect_ratio_allowed ||
+ (flags & DRM_MODE_FLAG_PIC_AR_MASK) == DRM_MODE_FLAG_PIC_AR_NONE;
+}
+EXPORT_SYMBOL(drm_mode_aspect_ratio_allowed);
+
+/**
+ * drm_mode_handle_aspect_ratio - handles the aspect-ratio bits in the
user-mode
+ * flags.
+ *
+ * Checks if the aspect-ratio information is allowed. Resets the aspect-ratio
+ * bits in the user-mode flag, if aspect-ratio info is not allowed.
+ *
+ * @file_priv: file private structure to get the user capabilities.
+ * @flags: 32 bit flag that is to be modified, in case the aspect
+ * ratio info is not allowed.
+ *
+ */
+void
+drm_mode_handle_aspect_ratio(const struct drm_file *file_priv, uint32_t *flags)
+{
+ if (!drm_mode_aspect_ratio_allowed(file_priv, *flags))
+ *flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
+}
+EXPORT_SYMBOL(drm_mode_handle_aspect_ratio);
diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
index c37ac41..0a9c879 100644
--- a/drivers/gpu/drm/drm_property.c
+++ b/drivers/gpu/drm/drm_property.c
@@ -757,6 +757,11 @@ int drm_mode_getblob_ioctl(struct drm_device *dev,
ret = -EFAULT;
goto unref;
}
+ if (blob->is_video_mode) {
+ struct drm_mode_modeinfo __user *mode =
+ u64_to_user_ptr(out_resp->data);
+ drm_mode_handle_aspect_ratio(file_priv, &mode->flags);
+ }
}
out_resp->length = blob->length;
unref:
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 2f78b7e..51d1188 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -461,6 +461,10 @@ bool drm_mode_is_420_also(const struct drm_display_info
*display,
const struct drm_display_mode *mode);
boo
linux-next: Signed-off-by missing for commit in the drm tree
Hi all,
Commit
37a94791a097 ("drm/amd/pp: Add #ifdef checks for CONFIG_ACPI")
is missing a Signed-off-by from its committer.
--
Cheers,
Stephen Rothwell
pgpu1EfZWi3LI.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [DPU PATCH 10/11] drm/msm: Switch to atomic_helper_commit()
On 2018-02-28 11:19, Sean Paul wrote:
Now that all of the msm-specific goo is tucked safely away we can
switch
over to using the atomic helper commit directly. \o/
[Abhinav] Can we say something like "Move remaining msm-specific
operations to private handles and switch to atomic helper commit for the
rest.
Change-Id: Ieab0bd0c526b2a9d3b3345eeba402ac4857fe418
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/msm_atomic.c | 120 +--
drivers/gpu/drm/msm/msm_drv.c| 7 +-
drivers/gpu/drm/msm/msm_drv.h| 3 +-
3 files changed, 8 insertions(+), 122 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_atomic.c
b/drivers/gpu/drm/msm/msm_atomic.c
index 204c66cbfd31..91ffded576d8 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -18,8 +18,6 @@
#include "msm_drv.h"
#include "msm_kms.h"
-#include "msm_gem.h"
-#include "msm_fence.h"
static void msm_atomic_wait_for_commit_done(
struct drm_device *dev,
@@ -39,7 +37,7 @@ static void msm_atomic_wait_for_commit_done(
}
}
-static void msm_atomic_commit_tail(struct drm_atomic_state *state)
+void msm_atomic_commit_tail(struct drm_atomic_state *state)
{
struct drm_device *dev = state->dev;
struct msm_drm_private *priv = dev->dev_private;
@@ -81,119 +79,3 @@ static void msm_atomic_commit_tail(struct
drm_atomic_state *state)
kms->funcs->complete_commit(kms, state);
}
-
-/* The (potentially) asynchronous part of the commit. At this point
- * nothing can fail short of armageddon.
- */
-static void commit_tail(struct drm_atomic_state *state)
-{
- drm_atomic_helper_wait_for_fences(state->dev, state, false);
-
- drm_atomic_helper_wait_for_dependencies(state);
-
- msm_atomic_commit_tail(state);
-
- drm_atomic_helper_commit_cleanup_done(state);
-
- drm_atomic_state_put(state);
-}
-
-static void commit_work(struct work_struct *work)
-{
- struct drm_atomic_state *state = container_of(work,
- struct drm_atomic_state,
- commit_work);
- commit_tail(state);
-}
-
-/**
- * drm_atomic_helper_commit - commit validated state object
- * @dev: DRM device
- * @state: the driver state object
- * @nonblock: nonblocking commit
- *
- * This function commits a with drm_atomic_helper_check()
pre-validated state
- * object. This can still fail when e.g. the framebuffer reservation
fails.
- *
- * RETURNS
- * Zero for success or -errno.
- */
-int msm_atomic_commit(struct drm_device *dev,
- struct drm_atomic_state *state, bool nonblock)
-{
- struct msm_drm_private *priv = dev->dev_private;
- struct drm_crtc *crtc;
- struct drm_crtc_state *crtc_state;
- struct drm_plane *plane;
- struct drm_plane_state *old_plane_state, *new_plane_state;
- int i, ret;
-
- /*
-* Note that plane->atomic_async_check() should fail if we need
-* to re-assign hwpipe or anything that touches global atomic
-* state, so we'll never go down the async update path in those
-* cases.
-*/
- if (state->async_update) {
- ret = drm_atomic_helper_prepare_planes(dev, state);
- if (ret)
- return ret;
-
- drm_atomic_helper_async_commit(dev, state);
- drm_atomic_helper_cleanup_planes(dev, state);
- return 0;
- }
-
- ret = drm_atomic_helper_setup_commit(state, nonblock);
- if (ret)
- return ret;
-
- INIT_WORK(&state->commit_work, commit_work);
-
- ret = drm_atomic_helper_prepare_planes(dev, state);
- if (ret)
- return ret;
-
- if (!nonblock) {
- ret = drm_atomic_helper_wait_for_fences(dev, state, true);
- if (ret)
- goto error;
- }
-
- /*
- * This is the point of no return - everything below never fails
except
- * when the hw goes bonghits. Which means we can commit the new state
on
-* the software side now.
-*
-* swap driver private state while still holding state_lock
-*/
- BUG_ON(drm_atomic_helper_swap_state(state, false) < 0);
-
- /*
- * Everything below can be run asynchronously without the need to
grab
- * any modeset locks at all under one conditions: It must be
guaranteed
- * that the asynchronous work has either been cancelled (if the
driver
-* supports it, which at least requires that the framebuffers get
-* cleaned up with drm_atomic_helper_cleanup_planes()) or completed
-* before the new state gets committed on the software side with
-* drm_atomic_helper_swap_state().
-*
-* This scheme allows new atomic state updates to be prepared and
-* checked in parallel to the asynchronous completion of the previous
- * update. Whi
Re: [PATCH] dt-bindings: exynos: Document #sound-dai-cells property of the HDMI node
Hi Sylwester, 2018년 03월 08일 20:22에 Sylwester Nawrocki 이(가) 쓴 글: > Hi Inki, > > Cc: alsa-de...@alsa-project.org > > On 03/08/2018 09:15 AM, Inki Dae wrote: >> By the way, it seems 'sound-dai-cells' property never affect >> Exynos4210/4212> 5420/5433. It seems that even through ALSA TM2 audio >> driver(tm2_wm5110.c) >> exists the driver never check the property. >> >> However, this patch adds below description. >> >> "Optional properties for Exynos 4210, 4212, 5420 and 5433" >> >> Is there a possibility for other boards based on Exynos4210/4212/5420/5433 >> SoC to use this property later? > > All these SoCs have the HDMI IP block which has one input DAI, connected > internally over I2S bus with the IS2 controller. > > I think there is no advantage in limiting ourselves now only to SoC's > for which we currently rely on that DT property in current kernel code, > just to update this documentation later when we actually put the property > in dts files. > > In case of exynos5420 we already require #sound-dai-cells for Odroid and Maybe exynos5422? Odroid XU3/4 use Exynos5422. > I have also a patch for exynos5420-peach-pit board which will need it as > well. > > As far as exynos4210 and exynos4212 are concerned it's a matter of adding > support for Odroid-U3, then we will also need this property because > we are going to use "multi-codec" (HDMI and external I2S0 pins for CODEC > are wired in parallel). > > In case of exynos5433 it just happens that the code in current driver > doesn't require #sound-dai-cells property - one of the reasons I made it > this way was to avoid dependency on dts, but it doesn't imply we should > describe the HW in DT incompletely. Once the property is in dtbs we can > update the driver to use more generic code, instead of open coding things. > Good idea. > Actually I have forgotten to add also exynos5250 to the list. Seems that '#sound-dai-cells' is required mandatorily in case of Exynos5422 because Odroid XU3/4 Audio driver checks this property, and the driver returns error if the property doesn't exist in its device tree. And if other SoCs - Exynos4210/4212/5250/5420/5433 - require this property with additional driver works later then this property would also be required mandatorily for them not optionally. In this case we may need to modify the description again. So my opinion is to add only the description required mandatorily if I understood correctly. Thanks, Inki Dae > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [DPU PATCH 07/11] drm/msm: Use atomic private_obj instead of subclassing
On 2018-02-28 11:19, Sean Paul wrote:
Instead of subclassing atomic state, store driver private data in
private_obj/state. This allows us to remove the swap_state driver hook
for mdp5 and get closer to using the atomic helpers entirely.
Change-Id: I65a4a2887593ae257d584e00b352b5daf00e4e61
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 37 ++
drivers/gpu/drm/msm/msm_atomic.c | 30 ---
drivers/gpu/drm/msm/msm_drv.c| 65 ++--
drivers/gpu/drm/msm/msm_drv.h| 4 +-
drivers/gpu/drm/msm/msm_kms.h| 28 +-
5 files changed, 95 insertions(+), 69 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 6d8e3a9a6fc0..f1a248419655 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -74,36 +74,32 @@ struct mdp5_state *mdp5_get_state(struct
drm_atomic_state *s)
{
struct msm_drm_private *priv = s->dev->dev_private;
struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(priv->kms));
- struct msm_kms_state *state = to_kms_state(s);
- struct mdp5_state *new_state;
+ struct msm_kms_state *kms_state;
int ret;
- if (state->state)
- return state->state;
-
ret = drm_modeset_lock(&mdp5_kms->state_lock, s->acquire_ctx);
if (ret)
return ERR_PTR(ret);
- new_state = kmalloc(sizeof(*mdp5_kms->state), GFP_KERNEL);
- if (!new_state)
- return ERR_PTR(-ENOMEM);
+ kms_state = msm_kms_get_state(s);
+ if (IS_ERR_OR_NULL(kms_state))
+ return (struct mdp5_state *)kms_state; /* casting ERR_PTR
*/
- /* Copy state: */
- new_state->hwpipe = mdp5_kms->state->hwpipe;
- new_state->hwmixer = mdp5_kms->state->hwmixer;
- if (mdp5_kms->smp)
- new_state->smp = mdp5_kms->state->smp;
+ return kms_state->state;
+}
- state->state = new_state;
+static void *mdp5_duplicate_state(void *state)
+{
+ if (!state)
+ return kzalloc(sizeof(struct mdp5_state), GFP_KERNEL);
- return new_state;
+ return kmemdup(state, sizeof(struct mdp5_state), GFP_KERNEL);
}
-static void mdp5_swap_state(struct msm_kms *kms, struct
drm_atomic_state
*state)
+static void mdp5_destroy_state(void *state)
{
- struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
- swap(to_kms_state(state)->state, mdp5_kms->state);
+ struct mdp5_state *mdp_state = state;
+ kfree(mdp_state);
}
static void mdp5_prepare_commit(struct msm_kms *kms, struct
drm_atomic_state *state)
@@ -229,7 +225,8 @@ static const struct mdp_kms_funcs kms_funcs = {
.irq = mdp5_irq,
.enable_vblank = mdp5_enable_vblank,
.disable_vblank = mdp5_disable_vblank,
- .swap_state = mdp5_swap_state,
+ .duplicate_state = mdp5_duplicate_state,
+ .destroy_state = mdp5_destroy_state,
.prepare_commit = mdp5_prepare_commit,
.complete_commit = mdp5_complete_commit,
.wait_for_crtc_commit_done =
mdp5_wait_for_crtc_commit_done,
@@ -726,8 +723,6 @@ static void mdp5_destroy(struct platform_device
*pdev)
if (mdp5_kms->rpm_enabled)
pm_runtime_disable(&pdev->dev);
-
- kfree(mdp5_kms->state);
}
static int construct_pipes(struct mdp5_kms *mdp5_kms, int cnt,
diff --git a/drivers/gpu/drm/msm/msm_atomic.c
b/drivers/gpu/drm/msm/msm_atomic.c
index 7e54eb65d096..1f53262ea46b 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -169,9 +169,6 @@ int msm_atomic_commit(struct drm_device *dev,
*/
BUG_ON(drm_atomic_helper_swap_state(state, false) < 0);
- if (to_kms_state(state)->state)
- priv->kms->funcs->swap_state(priv->kms, state);
-
/*
* Provide the driver a chance to prepare for output fences. This
is
* done after the point of no return, but before asynchronous
commits
@@ -210,30 +207,3 @@ int msm_atomic_commit(struct drm_device *dev,
drm_atomic_helper_cleanup_planes(dev, state);
return ret;
}
-
-struct drm_atomic_state *msm_atomic_state_alloc(struct drm_device
*dev)
-{
- struct msm_kms_state *state = kzalloc(sizeof(*state), GFP_KERNEL);
-
- if (!state || drm_atomic_state_init(dev, &state->base) < 0) {
- kfree(state);
- return NULL;
- }
-
- return &state->base;
-}
-
-void msm_atomic_state_clear(struct drm_atomic_state *s)
-{
- struct msm_kms_state *state = to_kms_state(s);
- drm_atomic_state_default_clear(&state->base);
- kfree(state->state);
- state->state = NULL;
-}
-
-void msm_atomic_state_free(struct drm_atomic_state *state)
-{
- kfree(to_kms_state(state)->state);
- drm_atomic_sta
Re: [DPU PATCH 09/11] drm/msm: Remove prepare_fence kms_function
On 2018-02-28 11:19, Sean Paul wrote:
This is the last piece that is keeping us from matching the atomic
helper commit function. By removing this (now unused) hook, we can
switch to drm_atomic_helper_commit()
Change-Id: I081056a6e1689807871f5deedc76499bb91b6969
Signed-off-by: Sean Paul
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/msm_atomic.c | 10 --
drivers/gpu/drm/msm/msm_kms.h| 2 --
2 files changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_atomic.c
b/drivers/gpu/drm/msm/msm_atomic.c
index 1f53262ea46b..204c66cbfd31 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -169,16 +169,6 @@ int msm_atomic_commit(struct drm_device *dev,
*/
BUG_ON(drm_atomic_helper_swap_state(state, false) < 0);
- /*
-* Provide the driver a chance to prepare for output fences. This is
-* done after the point of no return, but before asynchronous commits
-* are dispatched to work queues, so that the fence preparation is
-* finished before the .atomic_commit returns.
-*/
- if (priv && priv->kms && priv->kms->funcs &&
- priv->kms->funcs->prepare_fence)
- priv->kms->funcs->prepare_fence(priv->kms, state);
-
/*
* Everything below can be run asynchronously without the need to
grab
* any modeset locks at all under one conditions: It must be
guaranteed
diff --git a/drivers/gpu/drm/msm/msm_kms.h
b/drivers/gpu/drm/msm/msm_kms.h
index 4c5a69258c42..25800c046bd1 100644
--- a/drivers/gpu/drm/msm/msm_kms.h
+++ b/drivers/gpu/drm/msm/msm_kms.h
@@ -60,8 +60,6 @@ struct msm_kms_funcs {
void *(*duplicate_state)(void *state);
void (*destroy_state)(void *state);
/* modeset, bracketing atomic_commit(): */
- void (*prepare_fence)(struct msm_kms *kms,
- struct drm_atomic_state *state);
void (*prepare_commit)(struct msm_kms *kms,
struct drm_atomic_state *state);
void (*commit)(struct msm_kms *kms, struct drm_atomic_state *state);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [DPU PATCH 06/11] drm/msm: Remove msm_commit/kthread, use atomic helper commit
On 2018-03-02 06:56, Sean Paul wrote:
On Thu, Mar 01, 2018 at 07:37:10PM -0500, Rob Clark wrote:
On Thu, Mar 1, 2018 at 3:37 PM, wrote:
> On 2018-03-01 07:27, Sean Paul wrote:
>>
>> On Wed, Feb 28, 2018 at 08:07:00PM -0800, jsa...@codeaurora.org
wrote:
>>>
>>> On 2018-02-28 11:19, Sean Paul wrote:
>>> > Moving further towards switching fully to the the atomic helpers,
this
>>> > patch removes the hand-rolled kthread nonblock commit code and
uses
>>
>> the
>>>
>>> > atomic helpers commit_work model.
>>> >
>>> > There's still a lot of copypasta here, but it's still needed to
>>> > facilitate the swap_state and prepare_fence private functions.
These
>>> > will be sorted out in a follow-on patch.
>>> >
>>> > Change-Id: I9fcba27824ba63d3fab96cb2bc194bfa6f3475b7
>>> > Signed-off-by: Sean Paul
>>> > ---
>>> > drivers/gpu/drm/msm/msm_atomic.c | 199
>>
>> ++-
>>>
>>> > drivers/gpu/drm/msm/msm_drv.c| 1 -
>>> > drivers/gpu/drm/msm/msm_drv.h| 4 -
>>> > 3 files changed, 35 insertions(+), 169 deletions(-)
>>> >
>>> > diff --git a/drivers/gpu/drm/msm/msm_atomic.c
>>> > b/drivers/gpu/drm/msm/msm_atomic.c
>>> > index 3a18bd3dc215..7e54eb65d096 100644
>>> > --- a/drivers/gpu/drm/msm/msm_atomic.c
>>> > +++ b/drivers/gpu/drm/msm/msm_atomic.c
>>> > @@ -21,51 +21,6 @@
>>> > #include "msm_gem.h"
>>> > #include "msm_fence.h"
>>> >
>>> > -struct msm_commit {
>>> > - struct drm_device *dev;
>>> > - struct drm_atomic_state *state;
>>> > - uint32_t crtc_mask;
>>> > - bool nonblock;
>>> > - struct kthread_work commit_work;
>>> > -};
>>> > -
>>> > -/* block until specified crtcs are no longer pending update, and
>>> > - * atomically mark them as pending update
>>> > - */
>>> > -static int start_atomic(struct msm_drm_private *priv, uint32_t
>>> > crtc_mask)
>>> > -{
>>> > - int ret;
>>> > -
>>> > - spin_lock(&priv->pending_crtcs_event.lock);
>>> > - ret =
wait_event_interruptible_locked(priv->pending_crtcs_event,
>>> > - !(priv->pending_crtcs & crtc_mask));
>>> > - if (ret == 0) {
>>> > - DBG("start: %08x", crtc_mask);
>>> > - priv->pending_crtcs |= crtc_mask;
>>> > - }
>>> > - spin_unlock(&priv->pending_crtcs_event.lock);
>>> > -
>>> > - return ret;
>>> > -}
>>> > -
>>> > -/* clear specified crtcs (no longer pending update)
>>> > - */
>>> > -static void end_atomic(struct msm_drm_private *priv, uint32_t
>>> > crtc_mask)
>>> > -{
>>> > - spin_lock(&priv->pending_crtcs_event.lock);
>>> > - DBG("end: %08x", crtc_mask);
>>> > - priv->pending_crtcs &= ~crtc_mask;
>>> > - wake_up_all_locked(&priv->pending_crtcs_event);
>>> > - spin_unlock(&priv->pending_crtcs_event.lock);
>>> > -}
>>> > -
>>> > -static void commit_destroy(struct msm_commit *c)
>>> > -{
>>> > - end_atomic(c->dev->dev_private, c->crtc_mask);
>>> > - if (c->nonblock)
>>> > - kfree(c);
>>> > -}
>>> > -
>>> > static void msm_atomic_wait_for_commit_done(
>>> > struct drm_device *dev,
>>> > struct drm_atomic_state *old_state)
>>> > @@ -118,6 +73,10 @@ static void msm_atomic_commit_tail(struct
>>> > drm_atomic_state *state)
>>> >
>>> > msm_atomic_wait_for_commit_done(dev, state);
>>> >
>>> > + drm_atomic_helper_commit_hw_done(state);
>>> > +
>>> > + drm_atomic_helper_wait_for_vblanks(dev, state);
>>> > +
>>> > drm_atomic_helper_cleanup_planes(dev, state);
>>> >
>>> > kms->funcs->complete_commit(kms, state);
>>> > @@ -126,109 +85,25 @@ static void msm_atomic_commit_tail(struct
>>> > drm_atomic_state *state)
>>> > /* The (potentially) asynchronous part of the commit. At this
point
>>> > * nothing can fail short of armageddon.
>>> > */
>>> > -static void complete_commit(struct msm_commit *c)
>>> > +static void commit_tail(struct drm_atomic_state *state)
>>> > {
>>> > - struct drm_atomic_state *state = c->state;
>>> > - struct drm_device *dev = state->dev;
>>> > + drm_atomic_helper_wait_for_fences(state->dev, state, false);
>>> >
>>> > - drm_atomic_helper_wait_for_fences(dev, state, false);
>>> > + drm_atomic_helper_wait_for_dependencies(state);
>>> >
>>> > msm_atomic_commit_tail(state);
>>> >
>>> > - drm_atomic_state_put(state);
>>> > -}
>>> > -
>>> > -static void _msm_drm_commit_work_cb(struct kthread_work *work)
>>> > -{
>>> > - struct msm_commit *commit = NULL;
>>> > -
>>> > - if (!work) {
>>> > - DRM_ERROR("%s: Invalid commit work data!\n",
__func__);
>>> > - return;
>>> > - }
>>> > -
>>> > - commit = container_of(work, struct msm_commit, commit_work);
>>> > -
>>> > - complete_commit(commit);
>>> > -
>>> > - commit_destroy(commit);
>>> > -}
>>> > -
>>> > -static struct msm_commit *commit_init(struct drm_atomic_state
*state,
>>> > - bool nonblock)
>>> > -{
>>> > - struct msm_commit *c = kzalloc(sizeof(*c), GFP_KERNEL);
>>> > + dr
Re: [DPU PATCH 03/11] drm/msm: Refactor complete_commit() to look more the helpers
On 2018-02-28 11:18, Sean Paul wrote:
Factor out the commit_tail() portions of complete_commit() into a
separate function to facilitate moving to the atomic helpers in future
patches.
Change-Id: I4b858ad9fe356b31ed0ed9eecdb394a61048e39c
Signed-off-by: Sean Paul
Reviewed-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/msm_atomic.c | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_atomic.c
b/drivers/gpu/drm/msm/msm_atomic.c
index f5794dce25dd..eb2ccda5da0f 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -84,18 +84,12 @@ static void msm_atomic_wait_for_commit_done(
}
}
-/* The (potentially) asynchronous part of the commit. At this point
- * nothing can fail short of armageddon.
- */
-static void complete_commit(struct msm_commit *c)
+static void msm_atomic_commit_tail(struct drm_atomic_state *state)
{
- struct drm_atomic_state *state = c->state;
struct drm_device *dev = state->dev;
struct msm_drm_private *priv = dev->dev_private;
struct msm_kms *kms = priv->kms;
- drm_atomic_helper_wait_for_fences(dev, state, false);
-
kms->funcs->prepare_commit(kms, state);
drm_atomic_helper_commit_modeset_disables(dev, state);
@@ -127,10 +121,21 @@ static void complete_commit(struct msm_commit *c)
drm_atomic_helper_cleanup_planes(dev, state);
kms->funcs->complete_commit(kms, state);
+}
- drm_atomic_state_put(state);
+/* The (potentially) asynchronous part of the commit. At this point
+ * nothing can fail short of armageddon.
+ */
+static void complete_commit(struct msm_commit *c)
+{
+ struct drm_atomic_state *state = c->state;
+ struct drm_device *dev = state->dev;
- commit_destroy(c);
+ drm_atomic_helper_wait_for_fences(dev, state, false);
+
+ msm_atomic_commit_tail(state);
+
+ drm_atomic_state_put(state);
}
static void _msm_drm_commit_work_cb(struct kthread_work *work)
@@ -145,6 +150,8 @@ static void _msm_drm_commit_work_cb(struct
kthread_work *work)
commit = container_of(work, struct msm_commit, commit_work);
complete_commit(commit);
+
+ commit_destroy(commit);
}
static struct msm_commit *commit_init(struct drm_atomic_state *state,
--
Jeykumar S
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [DPU PATCH 02/11] drm/msm: Don't duplicate modeset_enables atomic helper
On 2018-02-28 11:18, Sean Paul wrote:
Instead, shuffle things around so we kickoff crtc after enabling
encoder
during modesets. Also moves the vblank wait to after the frame.
Change-Id: I16c7b7f9390d04f6050aa20e17a5335fbf49eba3
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 9 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 5 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 31 -
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 2 +
drivers/gpu/drm/msm/msm_atomic.c| 132 +---
5 files changed, 48 insertions(+), 131 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index a3ab6ed2bf1d..94fab2dcca5b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -3525,6 +3525,12 @@ static void dpu_crtc_enable(struct drm_crtc
*crtc,
DPU_EVT32_VERBOSE(DRMID(crtc));
dpu_crtc = to_dpu_crtc(crtc);
+ if (msm_is_mode_seamless(&crtc->state->adjusted_mode) ||
+ msm_is_mode_seamless_vrr(&crtc->state->adjusted_mode)) {
+ DPU_DEBUG("Skipping crtc enable, seamless mode\n");
+ return;
+ }
+
pm_runtime_get_sync(crtc->dev->dev);
drm_for_each_encoder(encoder, crtc->dev) {
@@ -3572,6 +3578,9 @@ static void dpu_crtc_enable(struct drm_crtc
*crtc,
DPU_POWER_EVENT_POST_ENABLE | DPU_POWER_EVENT_POST_DISABLE
|
DPU_POWER_EVENT_PRE_DISABLE,
dpu_crtc_handle_power_event, crtc, dpu_crtc->name);
+
+ if (msm_needs_vblank_pre_modeset(&crtc->state->adjusted_mode))
+ drm_crtc_wait_one_vblank(crtc);
}
struct plane_state {
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 28ceb589ee40..4d1e3652dbf4 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -3693,8 +3693,11 @@ static void
dpu_encoder_frame_done_timeout(struct
timer_list *t)
static const struct drm_encoder_helper_funcs dpu_encoder_helper_funcs
= {
.mode_set = dpu_encoder_virt_mode_set,
.disable = dpu_encoder_virt_disable,
- .enable = dpu_encoder_virt_enable,
+ .enable = dpu_kms_encoder_enable,
.atomic_check = dpu_encoder_virt_atomic_check,
+
+ /* This is called by dpu_kms_encoder_enable */
+ .commit = dpu_encoder_virt_enable,
};
static const struct drm_encoder_funcs dpu_encoder_funcs = {
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 81fd3a429e9f..3d83037e8305 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -425,14 +425,37 @@ static void dpu_kms_prepare_commit(struct msm_kms
*kms,
dpu_encoder_prepare_commit(encoder);
}
-static void dpu_kms_commit(struct msm_kms *kms,
- struct drm_atomic_state *old_state)
+/*
+ * Override the encoder enable since we need to setup the inline
rotator
and do
+ * some crtc magic before enabling any bridge that might be present.
+ */
+void dpu_kms_encoder_enable(struct drm_encoder *encoder)
+{
+ const struct drm_encoder_helper_funcs *funcs =
encoder->helper_private;
+ struct drm_crtc *crtc = encoder->crtc;
+
+ /* Forward this enable call to the commit hook */
+ if (funcs && funcs->commit)
+ funcs->commit(encoder);
The purpose of this function is not clear. Where are we setting up the
inline rotator?
Why do we need a kickoff here?
+
+ if (crtc && crtc->state->active) {
+ DPU_EVT32(DRMID(crtc));
+ dpu_crtc_commit_kickoff(crtc);
+ }
+}
+
+static void dpu_kms_commit(struct msm_kms *kms, struct
drm_atomic_state
*state)
{
struct drm_crtc *crtc;
- struct drm_crtc_state *old_crtc_state;
+ struct drm_crtc_state *crtc_state;
+ struct dpu_crtc_state *cstate;
int i;
- for_each_old_crtc_in_state(old_state, crtc, old_crtc_state, i) {
+ for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
+ /* If modeset is required, kickoff is run in
encoder_enable */
+ if (drm_atomic_crtc_needs_modeset(crtc_state))
+ continue;
+
if (crtc->state->active) {
DPU_EVT32(DRMID(crtc));
dpu_crtc_commit_kickoff(crtc);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
index 8cadd29a48b1..42c809ed9467 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
@@ -529,4 +529,6 @@ int dpu_kms_fbo_reference(struct dpu_kms_fbo *fbo);
*/
void dpu_kms_fbo_unreference(struct dpu_kms_fbo *fbo);
+void dpu_kms_encoder_enable(struct drm_encoder *encoder);
+
#endif /* __dpu_kms_H__ */
diff --git a/drivers/gpu/drm/msm/msm_atomic.c
b/dri
[PATCH v2 1/4] drm/vc4: Set premultiplied for alpha formats
Alpha formats in DRM are assumed to be premultiplied, so we should be
setting the PREMULT bit in the plane configuration for HVS.
Changes from v1:
- Use correct has_alpha
Signed-off-by: Stefan Schake
---
drivers/gpu/drm/vc4/vc4_plane.c | 3 ++-
drivers/gpu/drm/vc4/vc4_regs.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index c4c7af1..831e195 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -618,13 +618,14 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
SCALER_POS1_SCL_HEIGHT));
}
- /* Position Word 2: Source Image Size, Alpha Mode */
+ /* Position Word 2: Source Image Size, Alpha */
vc4_state->pos2_offset = vc4_state->dlist_count;
vc4_dlist_write(vc4_state,
VC4_SET_FIELD(fb->format->has_alpha ?
SCALER_POS2_ALPHA_MODE_PIPELINE :
SCALER_POS2_ALPHA_MODE_FIXED,
SCALER_POS2_ALPHA_MODE) |
+ (fb->format->has_alpha ? SCALER_POS2_ALPHA_PREMULT : 0)
|
VC4_SET_FIELD(vc4_state->src_w[0], SCALER_POS2_WIDTH) |
VC4_SET_FIELD(vc4_state->src_h[0], SCALER_POS2_HEIGHT));
diff --git a/drivers/gpu/drm/vc4/vc4_regs.h b/drivers/gpu/drm/vc4/vc4_regs.h
index b9749cb..a141496 100644
--- a/drivers/gpu/drm/vc4/vc4_regs.h
+++ b/drivers/gpu/drm/vc4/vc4_regs.h
@@ -848,6 +848,7 @@ enum hvs_pixel_format {
#define SCALER_POS2_ALPHA_MODE_FIXED 1
#define SCALER_POS2_ALPHA_MODE_FIXED_NONZERO 2
#define SCALER_POS2_ALPHA_MODE_FIXED_OVER_0x07 3
+#define SCALER_POS2_ALPHA_PREMULT BIT(29)
#define SCALER_POS2_HEIGHT_MASKVC4_MASK(27, 16)
#define SCALER_POS2_HEIGHT_SHIFT 16
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/4] drm/vc4: Check if plane requires background fill
Considering a single plane only, we have to enable background color
when the plane has an alpha format and could be blending from the
background or when it doesn't cover the entire screen.
Changes from v1:
- Drop unrelated change
- Move needs_bg_fill to plane state
Signed-off-by: Stefan Schake
---
drivers/gpu/drm/vc4/vc4_plane.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 831e195..8be9a87 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -73,6 +73,12 @@ struct vc4_plane_state {
/* Our allocation in LBM for temporary storage during scaling. */
struct drm_mm_node lbm;
+
+ /* Set when the plane has per-pixel alpha content or does not cover
+* the entire screen. This is a hint to the CRTC that it might need
+* to enable background color fill.
+*/
+ bool needs_bg_fill;
};
static inline struct vc4_plane_state *
@@ -521,6 +527,7 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
u32 ctl0_offset = vc4_state->dlist_count;
const struct hvs_format *format =
vc4_get_hvs_format(fb->format->format);
int num_planes = drm_format_num_planes(format->drm);
+ bool covers_screen;
u32 scl0, scl1, pitch0;
u32 lbm_size, tiling;
unsigned long irqflags;
@@ -701,6 +708,16 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
vc4_state->dlist[ctl0_offset] |=
VC4_SET_FIELD(vc4_state->dlist_count, SCALER_CTL0_SIZE);
+ /* crtc_* are already clipped coordinates. */
+ covers_screen = vc4_state->crtc_x == 0 && vc4_state->crtc_y == 0 &&
+ vc4_state->crtc_w == state->crtc->mode.hdisplay &&
+ vc4_state->crtc_h == state->crtc->mode.vdisplay;
+ /* Background fill might be necessary when the plane has per-pixel
+* alpha content and blends from the background or does not cover
+* the entire screen.
+*/
+ vc4_state->needs_bg_fill = fb->format->has_alpha || !covers_screen;
+
return 0;
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/4] drm/vc4: Move plane state to header
We need to reference it from the CRTC to make a decision for enabling
background color fill.
Signed-off-by: Stefan Schake
---
drivers/gpu/drm/vc4/vc4_drv.h | 60 +
drivers/gpu/drm/vc4/vc4_plane.c | 60 -
2 files changed, 60 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index fefa166..1b4cd1f 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -310,6 +310,66 @@ to_vc4_plane(struct drm_plane *plane)
return (struct vc4_plane *)plane;
}
+enum vc4_scaling_mode {
+ VC4_SCALING_NONE,
+ VC4_SCALING_TPZ,
+ VC4_SCALING_PPF,
+};
+
+struct vc4_plane_state {
+ struct drm_plane_state base;
+ /* System memory copy of the display list for this element, computed
+* at atomic_check time.
+*/
+ u32 *dlist;
+ u32 dlist_size; /* Number of dwords allocated for the display list */
+ u32 dlist_count; /* Number of used dwords in the display list. */
+
+ /* Offset in the dlist to various words, for pageflip or
+* cursor updates.
+*/
+ u32 pos0_offset;
+ u32 pos2_offset;
+ u32 ptr0_offset;
+
+ /* Offset where the plane's dlist was last stored in the
+* hardware at vc4_crtc_atomic_flush() time.
+*/
+ u32 __iomem *hw_dlist;
+
+ /* Clipped coordinates of the plane on the display. */
+ int crtc_x, crtc_y, crtc_w, crtc_h;
+ /* Clipped area being scanned from in the FB. */
+ u32 src_x, src_y;
+
+ u32 src_w[2], src_h[2];
+
+ /* Scaling selection for the RGB/Y plane and the Cb/Cr planes. */
+ enum vc4_scaling_mode x_scaling[2], y_scaling[2];
+ bool is_unity;
+ bool is_yuv;
+
+ /* Offset to start scanning out from the start of the plane's
+* BO.
+*/
+ u32 offsets[3];
+
+ /* Our allocation in LBM for temporary storage during scaling. */
+ struct drm_mm_node lbm;
+
+ /* Set when the plane has per-pixel alpha content or does not cover
+* the entire screen. This is a hint to the CRTC that it might need
+* to enable background color fill.
+*/
+ bool needs_bg_fill;
+};
+
+static inline struct vc4_plane_state *
+to_vc4_plane_state(struct drm_plane_state *state)
+{
+ return (struct vc4_plane_state *)state;
+}
+
enum vc4_encoder_type {
VC4_ENCODER_TYPE_NONE,
VC4_ENCODER_TYPE_HDMI,
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 8be9a87..ce39390 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -27,66 +27,6 @@
#include "vc4_drv.h"
#include "vc4_regs.h"
-enum vc4_scaling_mode {
- VC4_SCALING_NONE,
- VC4_SCALING_TPZ,
- VC4_SCALING_PPF,
-};
-
-struct vc4_plane_state {
- struct drm_plane_state base;
- /* System memory copy of the display list for this element, computed
-* at atomic_check time.
-*/
- u32 *dlist;
- u32 dlist_size; /* Number of dwords allocated for the display list */
- u32 dlist_count; /* Number of used dwords in the display list. */
-
- /* Offset in the dlist to various words, for pageflip or
-* cursor updates.
-*/
- u32 pos0_offset;
- u32 pos2_offset;
- u32 ptr0_offset;
-
- /* Offset where the plane's dlist was last stored in the
-* hardware at vc4_crtc_atomic_flush() time.
-*/
- u32 __iomem *hw_dlist;
-
- /* Clipped coordinates of the plane on the display. */
- int crtc_x, crtc_y, crtc_w, crtc_h;
- /* Clipped area being scanned from in the FB. */
- u32 src_x, src_y;
-
- u32 src_w[2], src_h[2];
-
- /* Scaling selection for the RGB/Y plane and the Cb/Cr planes. */
- enum vc4_scaling_mode x_scaling[2], y_scaling[2];
- bool is_unity;
- bool is_yuv;
-
- /* Offset to start scanning out from the start of the plane's
-* BO.
-*/
- u32 offsets[3];
-
- /* Our allocation in LBM for temporary storage during scaling. */
- struct drm_mm_node lbm;
-
- /* Set when the plane has per-pixel alpha content or does not cover
-* the entire screen. This is a hint to the CRTC that it might need
-* to enable background color fill.
-*/
- bool needs_bg_fill;
-};
-
-static inline struct vc4_plane_state *
-to_vc4_plane_state(struct drm_plane_state *state)
-{
- return (struct vc4_plane_state *)state;
-}
-
static const struct hvs_format {
u32 drm; /* DRM_FORMAT_* */
u32 hvs; /* HVS_FORMAT_* */
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/4] drm/vc4: Enable background color fill when necessary
Using the hint from the plane state, we turn on the background color
to avoid display corruption from planes blending with the background.
Changes from v1:
- Use needs_bg_fill from plane state
Signed-off-by: Stefan Schake
---
drivers/gpu/drm/vc4/vc4_crtc.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index ce1e3b9..bf46674 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -643,9 +643,12 @@ static void vc4_crtc_atomic_flush(struct drm_crtc *crtc,
{
struct drm_device *dev = crtc->dev;
struct vc4_dev *vc4 = to_vc4_dev(dev);
+ struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(crtc->state);
struct drm_plane *plane;
+ struct vc4_plane_state *vc4_plane_state;
bool debug_dump_regs = false;
+ bool enable_bg_fill = false;
u32 __iomem *dlist_start = vc4->hvs->dlist + vc4_state->mm.start;
u32 __iomem *dlist_next = dlist_start;
@@ -656,6 +659,20 @@ static void vc4_crtc_atomic_flush(struct drm_crtc *crtc,
/* Copy all the active planes' dlist contents to the hardware dlist. */
drm_atomic_crtc_for_each_plane(plane, crtc) {
+ /* Is this the first active plane? */
+ if (dlist_next == dlist_start) {
+ /* We need to enable background fill when a plane
+* could be alpha blending from the background, i.e.
+* where no other plane is underneath. It suffices to
+* consider the first active plane here since we set
+* needs_bg_fill such that either the first plane
+* already needs it or all planes on top blend from
+* the first or a lower plane.
+*/
+ vc4_plane_state = to_vc4_plane_state(plane->state);
+ enable_bg_fill = vc4_plane_state->needs_bg_fill;
+ }
+
dlist_next += vc4_plane_write_dlist(plane, dlist_next);
}
@@ -664,6 +681,14 @@ static void vc4_crtc_atomic_flush(struct drm_crtc *crtc,
WARN_ON_ONCE(dlist_next - dlist_start != vc4_state->mm.size);
+ if (enable_bg_fill)
+ /* This sets a black background color fill, as is the case
+* with other DRM drivers.
+*/
+ HVS_WRITE(SCALER_DISPBKGNDX(vc4_crtc->channel),
+ HVS_READ(SCALER_DISPBKGNDX(vc4_crtc->channel)) |
+ SCALER_DISPBKGND_FILL);
+
/* Only update DISPLIST if the CRTC was already running and is not
* being disabled.
* vc4_crtc_enable() takes care of updating the dlist just after
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/4] drm/vc4: Improve alpha format plane support
This series improves the handling of alpha formats with the VC4 HVS compositor. Alpha formats are marked as premultiplied as is standard for DRM. Further fix a display corruption issue when planes with per-pixel alpha try blending from the (nonexistent) background by selectively enabling a black background color fill. This series follows the changes suggested by Eric Anholt in a previous patch discussion: https://patchwork.freedesktop.org/patch/207667/ A simple test program for the display corruption issue is available: https://github.com/stschake/vc4-alpha-test v2 of the series fixes the has_alpha confusion and moves needs_bg_fill into the plane state. This unfortunately necessitated moving the plane state to a header where it can be referenced from vc4_crtc. Stefan Schake (4): drm/vc4: Set premultiplied for alpha formats drm/vc4: Check if plane requires background fill drm/vc4: Move plane state to header drm/vc4: Enable background color fill when necessary drivers/gpu/drm/vc4/vc4_crtc.c | 25 +++ drivers/gpu/drm/vc4/vc4_drv.h | 60 drivers/gpu/drm/vc4/vc4_plane.c | 68 - drivers/gpu/drm/vc4/vc4_regs.h | 1 + 4 files changed, 99 insertions(+), 55 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/6] drm/i915: Move DP modeset retry work into intel_dp
While having the modeset_retry_work in intel_connector makes sense with
SST, this paradigm doesn't make a whole ton of sense when it comes to
MST since we have to deal with multiple connectors. In most cases, it's
more useful to just use the intel_dp struct since it indicates whether
or not we're dealing with an MST device, along with being able to easily
trace the intel_dp struct back to it's respective connector (if there is
any). So, move the modeset_retry_work function out of the
intel_connector struct and into intel_dp.
V2:
- Remove accidental duplicate modeset_retry_work in intel_connector
Signed-off-by: Lyude Paul
Cc: Manasi Navare
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 23 +--
drivers/gpu/drm/i915/intel_dp.c | 10 --
drivers/gpu/drm/i915/intel_dp_link_training.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 6 +++---
4 files changed, 29 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f424fff477f6..85d5af4e4f5b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15394,16 +15394,35 @@ static void intel_hpd_poll_fini(struct drm_device
*dev)
{
struct intel_connector *connector;
struct drm_connector_list_iter conn_iter;
+ struct work_struct *work;
/* Kill all the work that may have been queued by hpd. */
drm_connector_list_iter_begin(dev, &conn_iter);
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->base.connector_type !=
+ DRM_MODE_CONNECTOR_DisplayPort)
+ continue;
+
+ if (connector->mst_port) {
+ work = &connector->mst_port->modeset_retry_work;
+ } else {
+ struct intel_encoder *intel_encoder =
+ connector->encoder;
+ struct intel_dp *intel_dp;
+
+ if (!intel_encoder)
+ continue;
+
+ intel_dp = enc_to_intel_dp(&intel_encoder->base);
+ work = &intel_dp->modeset_retry_work;
+ }
+
+ cancel_work_sync(work);
}
drm_connector_list_iter_end(&conn_iter);
}
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4dd1b2287dd6..5abf0c95725a 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -6261,12 +6261,10 @@ static bool intel_edp_init_connector(struct intel_dp
*intel_dp,
static void intel_dp_modeset_retry_work_fn(struct work_struct *work)
{
- struct intel_connector *intel_connector;
- struct drm_connector *connector;
+ struct intel_dp *intel_dp = container_of(work, typeof(*intel_dp),
+modeset_retry_work);
+ struct drm_connector *connector = &intel_dp->attached_connector->base;
- intel_connector = container_of(work, typeof(*intel_connector),
- modeset_retry_work);
- connector = &intel_connector->base;
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
connector->name);
@@ -6295,7 +6293,7 @@ intel_dp_init_connector(struct intel_digital_port
*intel_dig_port,
int type;
/* Initialize the work for modeset in case of link train failure */
- INIT_WORK(&intel_connector->modeset_retry_work,
+ INIT_WORK(&intel_dp->modeset_retry_work,
intel_dp_modeset_retry_work_fn);
if (WARN(intel_dig_port->max_lanes < 1,
diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index f59b59bb0a21..2cfa58ce1f95 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -340,7 +340,7 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
intel_dp->link_rate,
intel_dp->lane_count))
/* Schedule a Hotplug Uevent to userspace to start
modeset */
- schedule_work(&intel_connector->modeset_retry_work);
+ schedule_work(&intel_dp->modeset_retry_work);
} else {
DRM_ERROR("[CONNECTOR:%d:%s] Link Training failed at link rate
= %d, lane count = %d",
intel_connector->base.base.id,
diff --git
[PATCH 6/6] drm/i915: Implement proper fallback training for MST
For a while we actually haven't had any way of retraining MST links with
fallback link parameters like we do with SST. While uncommon, certain
setups such as my Caldigit TS3 + EVGA MST hub require this since
otherwise, they end up getting stuck in an infinite MST retraining loop.
MST retraining is somewhat different then SST retraining. While it's
possible during the normal link retraining sequence for a hub to indicate
bad link status, it's also possible for a hub to only indicate this
status through ESI messages and it's possible for this to happen after
the initial link training succeeds. This can lead to a pattern that
looks like this:
- Train MST link
- Training completes successfully
- MST hub sets Channel EQ failed bit in ESI
- Retraining starts
- Retraining completes successfully
- MST hub sets Channel EQ failed bit in ESI again
- Rinse and repeat
In these situations, we need to be able to actually trigger fallback
link training from the ESI handler as well, along with using the ESI
handler during retraining to figure out whether or not our retraining
actually succeeded.
This gets a bit more complicated since we have to ensure that we don't
block the ESI handler at all while doing retraining. If we do, due to
DisplayPort's general issues with being sensitive to IRQ latency most
MST hubs will just stop responding to us if their interrupts aren't
handled in a timely manner.
So: move retraining into it's own seperate handler. Running in a
seperate handler allows us to avoid stalling the ESI during link
retraining, and we can have the ESI signal that the channel EQ bit was
cleared through a simple completion struct. Additionally, we take care
to stick as much of this into the SST retraining path as possible since
sharing is caring.
Signed-off-by: Lyude Paul
Cc: Manasi Navare
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 342 +++-
drivers/gpu/drm/i915/intel_dp_mst.c | 42 -
drivers/gpu/drm/i915/intel_drv.h| 8 +
3 files changed, 302 insertions(+), 90 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 5645a194de92..7626652732b6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -45,6 +45,8 @@
#define DP_DPRX_ESI_LEN 14
+#define DP_MST_RETRAIN_TIMEOUT (msecs_to_jiffies(100))
+
/* Compliance test status bits */
#define INTEL_DP_RESOLUTION_SHIFT_MASK 0
#define INTEL_DP_RESOLUTION_PREFERRED (1 << INTEL_DP_RESOLUTION_SHIFT_MASK)
@@ -4224,6 +4226,118 @@ static void intel_dp_handle_test_request(struct
intel_dp *intel_dp)
DRM_DEBUG_KMS("Could not write test response to sink\n");
}
+/* Get a mask of the CRTCs that are running on the given intel_dp struct. For
+ * MST, this returns a crtc mask containing all of the CRTCs driving
+ * downstream sinks, for SST it just returns a mask of the attached
+ * connector's CRTC.
+ */
+int
+intel_dp_get_crtc_mask(struct intel_dp *intel_dp)
+{
+ struct drm_device *dev = dp_to_dig_port(intel_dp)->base.base.dev;
+ struct drm_connector *connector;
+ struct drm_connector_state *conn_state;
+ struct intel_connector *intel_connector;
+ struct drm_crtc *crtc;
+ int crtc_mask = 0;
+
+ WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
+
+ if (intel_dp->is_mst) {
+ struct drm_connector_list_iter conn_iter;
+
+ drm_connector_list_iter_begin(dev, &conn_iter);
+ for_each_intel_connector_iter(intel_connector, &conn_iter) {
+ if (intel_connector->mst_port != intel_dp)
+ continue;
+
+ conn_state = intel_connector->base.state;
+ if (!conn_state->crtc)
+ continue;
+
+ crtc_mask |= drm_crtc_mask(conn_state->crtc);
+ }
+ drm_connector_list_iter_end(&conn_iter);
+ } else {
+ connector = &intel_dp->attached_connector->base;
+ crtc = connector->state->crtc;
+
+ if (crtc)
+ crtc_mask |= drm_crtc_mask(crtc);
+ }
+
+ return crtc_mask;
+}
+
+static bool
+intel_dp_needs_link_retrain(struct intel_dp *intel_dp,
+ const u8 esi[DP_DPRX_ESI_LEN])
+{
+ u8 buf[max(DP_LINK_STATUS_SIZE, DP_DPRX_ESI_LEN)];
+ const u8 *link_status = NULL;
+
+ if (intel_dp->is_mst) {
+ if (!intel_dp->active_mst_links)
+ return false;
+ if (intel_dp->mst_link_is_bad)
+ return false;
+
+ if (esi) {
+ link_status = &esi[10];
+ } else {
+ /* We're not running from the ESI handler, so wait a
+* little bit to see if the ESI handler lets us know
+* that the link status is
[PATCH 4/6] drm/dp_mst: Add drm_dp_mst_topology_mgr_lower_link_rate()
Unlike SST, MST can have far more then a single display hooked up on a
single port. What this also means however, is that if the DisplayPort
link to the top-level MST branch device becomes unstable then every
single branch device also has an unstable link. Additionally, MST has a
few more steps that must be taken in order to properly retrain the
entire topology under a lower link rate. Since the VCID allocations for
each mstb is determined based off the link rate for the top of the
topology, we also have to recalculate all of the VCID allocations for
the downstream ports as well to ensure that we still have enough link
bandwidth to drive each mstb.
Additionally, since we have multiple downstream connectors per port,
setting the link status of the parent mstb's port to bad isn't enough:
all of the downstream mstb ports have to have their link status set to
bad.
This basically follows the same paradigm that our DP link status logic
in DRM does, in that we simply tell userspace that all of the mstb ports
need retraining and additionally applying the new lower bandwidth
constraints to all of the atomic commits on the topology that follow.
Since the work of figuring out which connectors live downstream on an
MST topology and updating their link status is something that any driver
supporting MST is going to need to do in order to retrain MST links
properly, we add the drm_dp_mst_topology_mgr_lower_link_rate() helper
which simply recalculates the pbn_div for a given mst topology, then
marks the link status of all connectors living in that topology as bad.
We'll make use of it in i915 later in this series.
Signed-off-by: Lyude Paul
Cc: Manasi Navare
Cc: Ville Syrjälä
---
drivers/gpu/drm/drm_dp_mst_topology.c | 73 ++-
include/drm/drm_dp_mst_helper.h | 3 ++
2 files changed, 75 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 6fac4129e6a2..0d6604500b29 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2076,7 +2076,7 @@ static bool drm_dp_get_vc_payload_bw(int dp_link_bw,
{
switch (dp_link_bw) {
default:
- DRM_DEBUG_KMS("invalid link bandwidth in DPCD: %x (link count:
%d)\n",
+ DRM_DEBUG_KMS("invalid link bandwidth: %x (link count: %d)\n",
dp_link_bw, dp_link_count);
return false;
@@ -2096,6 +2096,77 @@ static bool drm_dp_get_vc_payload_bw(int dp_link_bw,
return true;
}
+static void drm_dp_set_mstb_link_status(struct drm_dp_mst_branch *mstb,
+ enum drm_link_status status)
+{
+ struct drm_dp_mst_branch *rmstb;
+ struct drm_dp_mst_port *port;
+
+ list_for_each_entry(port, &mstb->ports, next) {
+ rmstb = drm_dp_get_validated_mstb_ref(mstb->mgr, port->mstb);
+ if (rmstb) {
+ drm_dp_set_mstb_link_status(rmstb, status);
+ drm_dp_put_mst_branch_device(rmstb);
+ }
+
+ if (port->connector)
+ port->connector->state->link_status = status;
+ }
+}
+
+/**
+ * drm_dp_mst_topology_mgr_lower_link_rate() - Override the DP link bw/count
+ * for all connectors in a given MST topology
+ * @mgr: manager to set state for
+ * @dp_link_bw: The new DP link bandwidth
+ * @dp_link_count: The new DP link count
+ *
+ * This is called by the driver when it detects that the current DP link for
+ * the given topology manager is unstable, and needs to be retrained at a
+ * lower link rate.
+ *
+ * This takes care of updating the link status on all downstream connectors
+ * along with recalculating the VC payloads. The driver should send a hotplug
+ * event after calling this function to notify userspace of the link status
+ * change.
+ *
+ * RETURNS:
+ *
+ * True for success, or negative error code on failure.
+ */
+int drm_dp_mst_topology_mgr_lower_link_rate(struct drm_dp_mst_topology_mgr
*mgr,
+ int dp_link_bw, int dp_link_count)
+{
+ struct drm_device *dev = mgr->dev;
+ struct drm_dp_mst_branch *mst_primary;
+ int new_pbn_div;
+ int ret = 0;
+
+ drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
+
+ if (!drm_dp_get_vc_payload_bw(drm_dp_link_rate_to_bw_code(dp_link_bw),
+ dp_link_count, &new_pbn_div)) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ mst_primary = drm_dp_get_validated_mstb_ref(mgr, mgr->mst_primary);
+ if (!mst_primary)
+ goto out;
+
+ DRM_DEBUG_KMS("MST link failed to retrain, lowering pbn_div to %d\n",
+ new_pbn_div);
+ mgr->pbn_div = new_pbn_div;
+
+ drm_dp_set_mstb_link_status(mst_primary, DRM_MODE_LINK_STATUS_BAD);
+
+ drm_dp_put_mst_branch_device(mst_primar
[PATCH 0/6] Implement proper MST fallback retraining in i915
This is the first version of my patch series to implement MST fallback retraining in i915, along with improving the stability of i915's mst retraining in general. Additionally, it also introduces helpers into DRM to help with correctly handling MST fallback retraining so that other drivers may also implement it. If your driver has a homegrown implementation of this, you should convert it to these helpers to ensure that the behavior of atomic commits and connector's link status properties in the event of requiring retraining on an MST topology remains consistent between DRM drivers. Additionally, this lets me use the DisplayPort on my dock so I can finally free up the thunderbolt 3 connector on it for more useful things. At long last :). Cc: Manasi Navare Cc: Ville Syrjälä Lyude Paul (6): drm/i915: Remove unused DP_LINK_CHECK_TIMEOUT drm/i915: Move DP modeset retry work into intel_dp drm/i915: Only use one link bw config for MST topologies drm/dp_mst: Add drm_dp_mst_topology_mgr_lower_link_rate() drm/dp_mst: Add drm_atomic_dp_mst_retrain_topology() drm/i915: Implement proper fallback training for MST drivers/gpu/drm/drm_dp_mst_topology.c | 296 - drivers/gpu/drm/i915/intel_display.c | 23 +- drivers/gpu/drm/i915/intel_dp.c | 360 +++--- drivers/gpu/drm/i915/intel_dp_link_training.c | 2 +- drivers/gpu/drm/i915/intel_dp_mst.c | 64 +++-- drivers/gpu/drm/i915/intel_drv.h | 23 +- include/drm/drm_dp_mst_helper.h | 5 + 7 files changed, 662 insertions(+), 111 deletions(-) -- 2.14.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/6] drm/i915: Move DP modeset retry work into intel_dp
While having the modeset_retry_work in intel_connector makes sense with
SST, this paradigm doesn't make a whole ton of sense when it comes to
MST since we have to deal with multiple connectors. In most cases, it's
more useful to just use the intel_dp struct since it indicates whether
or not we're dealing with an MST device, along with being able to easily
trace the intel_dp struct back to it's respective connector (if there is
any). So, move the modeset_retry_work function out of the
intel_connector struct and into intel_dp.
Signed-off-by: Lyude Paul
Cc: Manasi Navare
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 23 +--
drivers/gpu/drm/i915/intel_dp.c | 10 --
drivers/gpu/drm/i915/intel_dp_link_training.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 9 ++---
4 files changed, 32 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f424fff477f6..85d5af4e4f5b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15394,16 +15394,35 @@ static void intel_hpd_poll_fini(struct drm_device
*dev)
{
struct intel_connector *connector;
struct drm_connector_list_iter conn_iter;
+ struct work_struct *work;
/* Kill all the work that may have been queued by hpd. */
drm_connector_list_iter_begin(dev, &conn_iter);
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->base.connector_type !=
+ DRM_MODE_CONNECTOR_DisplayPort)
+ continue;
+
+ if (connector->mst_port) {
+ work = &connector->mst_port->modeset_retry_work;
+ } else {
+ struct intel_encoder *intel_encoder =
+ connector->encoder;
+ struct intel_dp *intel_dp;
+
+ if (!intel_encoder)
+ continue;
+
+ intel_dp = enc_to_intel_dp(&intel_encoder->base);
+ work = &intel_dp->modeset_retry_work;
+ }
+
+ cancel_work_sync(work);
}
drm_connector_list_iter_end(&conn_iter);
}
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4dd1b2287dd6..5abf0c95725a 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -6261,12 +6261,10 @@ static bool intel_edp_init_connector(struct intel_dp
*intel_dp,
static void intel_dp_modeset_retry_work_fn(struct work_struct *work)
{
- struct intel_connector *intel_connector;
- struct drm_connector *connector;
+ struct intel_dp *intel_dp = container_of(work, typeof(*intel_dp),
+modeset_retry_work);
+ struct drm_connector *connector = &intel_dp->attached_connector->base;
- intel_connector = container_of(work, typeof(*intel_connector),
- modeset_retry_work);
- connector = &intel_connector->base;
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
connector->name);
@@ -6295,7 +6293,7 @@ intel_dp_init_connector(struct intel_digital_port
*intel_dig_port,
int type;
/* Initialize the work for modeset in case of link train failure */
- INIT_WORK(&intel_connector->modeset_retry_work,
+ INIT_WORK(&intel_dp->modeset_retry_work,
intel_dp_modeset_retry_work_fn);
if (WARN(intel_dig_port->max_lanes < 1,
diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index f59b59bb0a21..2cfa58ce1f95 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -340,7 +340,7 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
intel_dp->link_rate,
intel_dp->lane_count))
/* Schedule a Hotplug Uevent to userspace to start
modeset */
- schedule_work(&intel_connector->modeset_retry_work);
+ schedule_work(&intel_dp->modeset_retry_work);
} else {
DRM_ERROR("[CONNECTOR:%d:%s] Link Training failed at link rate
= %d, lane count = %d",
intel_connector->base.base.id,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
[PATCH 1/6] drm/i915: Remove unused DP_LINK_CHECK_TIMEOUT
Signed-off-by: Lyude Paul Cc: Manasi Navare Cc: Ville Syrjälä --- drivers/gpu/drm/i915/intel_dp.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 9a4a51e79fa1..4dd1b2287dd6 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -43,7 +43,6 @@ #include #include "i915_drv.h" -#define DP_LINK_CHECK_TIMEOUT (10 * 1000) #define DP_DPRX_ESI_LEN 14 /* Compliance test status bits */ -- 2.14.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/6] drm/i915: Only use one link bw config for MST topologies
When a DP MST link needs retraining, sometimes the hub will detect that
the current link bw config is impossible and will update it's RX caps in
the DPCD to reflect the new maximum link rate. Currently, we make the
assumption that the RX caps in the dpcd will never change like this.
This means if the sink changes it's RX caps after we've already set up
an MST link and we attempt to add or remove another sink from the
topology, we could put ourselves into an invalid state where we've tried
to configure different sinks on the same MST topology with different
link rates. We could also run into this situation if a sink reports a
higher link rate after suspend, usually from us having trained it with a
fallback bw configuration before suspending.
So: "lock" the bw config by only using the max DP link rate/lane count
on the first modeset for an MST topology. For every modeset following,
we instead use the last configured link bw for this topology. We only
unlock the bw config when we've detected a new MST sink.
Signed-off-by: Lyude Paul
Cc: Manasi Navare
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 11 +--
drivers/gpu/drm/i915/intel_dp_mst.c | 22 +++---
drivers/gpu/drm/i915/intel_drv.h| 6 ++
3 files changed, 30 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 5abf0c95725a..5645a194de92 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3871,18 +3871,25 @@ intel_dp_can_mst(struct intel_dp *intel_dp)
static void
intel_dp_configure_mst(struct intel_dp *intel_dp)
{
+ bool was_mst;
+
if (!i915_modparams.enable_dp_mst)
return;
if (!intel_dp->can_mst)
return;
+ was_mst = intel_dp->is_mst;
intel_dp->is_mst = intel_dp_can_mst(intel_dp);
- if (intel_dp->is_mst)
+ if (intel_dp->is_mst) {
DRM_DEBUG_KMS("Sink is MST capable\n");
- else
+
+ if (!was_mst)
+ intel_dp->mst_bw_locked = false;
+ } else {
DRM_DEBUG_KMS("Sink is not MST capable\n");
+ }
drm_dp_mst_topology_mgr_set_mst(&intel_dp->mst_mgr,
intel_dp->is_mst);
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index c3de0918ee13..c0553456b18e 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -42,7 +42,7 @@ static bool intel_dp_mst_compute_config(struct intel_encoder
*encoder,
to_intel_connector(conn_state->connector);
struct drm_atomic_state *state = pipe_config->base.state;
int bpp;
- int lane_count, slots;
+ int lane_count, link_rate, slots;
const struct drm_display_mode *adjusted_mode =
&pipe_config->base.adjusted_mode;
int mst_pbn;
bool reduce_m_n = drm_dp_has_quirk(&intel_dp->desc,
@@ -56,16 +56,22 @@ static bool intel_dp_mst_compute_config(struct
intel_encoder *encoder,
bpp);
}
/*
-* for MST we always configure max link bw - the spec doesn't
-* seem to suggest we should do otherwise.
+* for MST we always configure max link bw if we don't know better -
+* the spec doesn't seem to suggest we should do otherwise. But,
+* ensure it always stays consistent with the rest of this hub's
+* state.
*/
- lane_count = intel_dp_max_lane_count(intel_dp);
+ if (intel_dp->mst_bw_locked) {
+ lane_count = intel_dp->lane_count;
+ link_rate = intel_dp->link_rate;
+ } else {
+ lane_count = intel_dp_max_lane_count(intel_dp);
+ link_rate = intel_dp_max_link_rate(intel_dp);
+ }
pipe_config->lane_count = lane_count;
-
pipe_config->pipe_bpp = bpp;
-
- pipe_config->port_clock = intel_dp_max_link_rate(intel_dp);
+ pipe_config->port_clock = link_rate;
if (drm_dp_mst_port_has_audio(&intel_dp->mst_mgr, connector->port))
pipe_config->has_audio = true;
@@ -221,6 +227,8 @@ static void intel_mst_pre_enable_dp(struct intel_encoder
*encoder,
connector->encoder = encoder;
intel_mst->connector = connector;
+ intel_dp->mst_bw_locked = true;
+
DRM_DEBUG_KMS("active links %d\n", intel_dp->active_mst_links);
drm_dp_send_power_updown_phy(&intel_dp->mst_mgr, connector->port, true);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3700fcfddb1f..e5d3ef6754a5 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1110,6 +1110,12 @@ struct intel_dp {
bool can_mst; /* this port supports mst */
bool is_mst;
int active_mst_links;
+ /* Set when we've already decided on a link bw for mst, to prevent us
+* fr
[PATCH 5/6] drm/dp_mst: Add drm_atomic_dp_mst_retrain_topology()
Retraining MST is rather difficult. In order to do it properly while
guaranteeing that we'll never run into a spot where we commit a
physically impossible configuration, we have to do a lot of checks on
atomic commits which affect MST topologies. All of this work is going to
need to be repeated for every driver at some point, so let's save
ourselves some trouble and just implement these atomic checks as
a single helper.
Signed-off-by: Lyude Paul
Cc: Manasi Navare
Cc: Ville Syrjälä
---
drivers/gpu/drm/drm_dp_mst_topology.c | 223 ++
include/drm/drm_dp_mst_helper.h | 2 +
2 files changed, 225 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 0d6604500b29..c4a91b1ba61b 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2167,6 +2167,229 @@ int drm_dp_mst_topology_mgr_lower_link_rate(struct
drm_dp_mst_topology_mgr *mgr,
}
EXPORT_SYMBOL(drm_dp_mst_topology_mgr_lower_link_rate);
+static bool drm_atomic_dp_mst_state_only_disables_mstbs(struct
drm_atomic_state *state,
+ struct
drm_dp_mst_topology_mgr *mgr,
+ struct
drm_dp_mst_branch *mstb)
+{
+ struct drm_dp_mst_branch *rmstb;
+ struct drm_dp_mst_port *port;
+ struct drm_connector *connector;
+ struct drm_connector_state *conn_state;
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *crtc_state;
+ int ret;
+
+ list_for_each_entry(port, &mstb->ports, next) {
+ rmstb = drm_dp_get_validated_mstb_ref(mstb->mgr, port->mstb);
+ if (rmstb) {
+ ret = drm_atomic_dp_mst_state_only_disables_mstbs(
+ state, mgr, rmstb);
+ drm_dp_put_mst_branch_device(rmstb);
+ if (!ret)
+ return false;
+ }
+
+ connector = port->connector;
+ if (!connector)
+ continue;
+
+ conn_state = drm_atomic_get_new_connector_state(
+ state, connector);
+ if (!conn_state)
+ continue;
+
+ crtc = conn_state->crtc;
+ if (!crtc)
+ continue;
+
+ crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
+ if (!crtc_state)
+ continue;
+
+ if (drm_atomic_crtc_needs_modeset(crtc_state))
+ return false;
+ }
+
+ return true;
+}
+
+static int drm_atomic_dp_mst_all_mstbs_disabled(struct drm_atomic_state *state,
+ struct drm_dp_mst_topology_mgr
*mgr,
+ struct drm_dp_mst_branch *mstb)
+{
+ struct drm_dp_mst_branch *rmstb;
+ struct drm_dp_mst_port *port;
+ struct drm_connector *connector;
+ struct drm_connector_state *conn_state;
+ int ret;
+
+ list_for_each_entry(port, &mstb->ports, next) {
+ rmstb = drm_dp_get_validated_mstb_ref(mstb->mgr, port->mstb);
+ if (rmstb) {
+ ret = drm_atomic_dp_mst_all_mstbs_disabled(
+ state, mgr, rmstb);
+ drm_dp_put_mst_branch_device(rmstb);
+ if (ret <= 0)
+ return ret;
+ }
+
+ connector = port->connector;
+ if (!connector)
+ continue;
+
+ conn_state = drm_atomic_get_connector_state(
+ state, connector);
+ if (IS_ERR(conn_state))
+ return PTR_ERR(conn_state);
+
+ if (conn_state->crtc)
+ return false;
+ }
+
+ /* No enabled CRTCs found */
+ return true;
+}
+
+static int drm_atomic_dp_mst_retrain_mstb(struct drm_atomic_state *state,
+ struct drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_mst_branch *mstb,
+ bool full_modeset)
+{
+ struct drm_dp_mst_branch *rmstb;
+ struct drm_dp_mst_port *port;
+ struct drm_connector *connector;
+ struct drm_connector_state *conn_state;
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *crtc_state;
+ int ret;
+
+ list_for_each_entry(port, &mstb->ports, next) {
+ rmstb = drm_dp_get_validated_mstb_ref(mstb->mgr, port->mstb);
+ if (rmstb) {
+ ret = drm_atomic_dp_mst_retrain_mstb(
+ state, mgr, rmstb, full_modeset);
+ drm_dp_put_mst_branch_device(rmstb);
+ if (ret)
+
Re: [PATCH v4 03/38] drm/bridge: analogix_dp: detect Sink PSR state after configuring the PSR
Hi Enric,
Am Montag, 5. März 2018, 23:22:55 CET schrieb Enric Balletbo i Serra:
> From: Yakir Yang
>
> Make sure the request PSR state takes effect in analogix_dp_send_psr_spd()
> function, or print the sink PSR error state if we failed to apply the
> requested PSR setting.
>
> Cc: 征增 王
> Cc: Stéphane Marchesin
> Signed-off-by: Yakir Yang
> [seanpaul changed timeout loop to a readx poll]
> Signed-off-by: Sean Paul
> Signed-off-by: Thierry Escande
> Signed-off-by: Enric Balletbo i Serra
as this modifies the generic part of the analogix_dp, I think we'll
need some form of Ack from the drm-bridge maintainers.
[Or bridge maintainers applying it].
Change itself looks good, at least to me :-) .
It seems your recipient list is missing some bridge maintainers though.
MAINTAINERS, tells us that
Archit Taneja
Andrzej Hajda
Laurent Pinchart
should be CCed, but right now I only see Archit.
As there are quite a lot of general patches in here, I'd think this calls
for a v5, including Mareks tested-tag and including the missing people.
Heiko
>
> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 6 ++--
> drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 6 ++--
> drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 35
> +++---
> 3 files changed, 37 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index a693ab3078f0..e738aa6de1af 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -122,8 +122,7 @@ int analogix_dp_enable_psr(struct analogix_dp_device *dp)
> psr_vsc.DB0 = 0;
> psr_vsc.DB1 = EDP_VSC_PSR_STATE_ACTIVE | EDP_VSC_PSR_CRC_VALUES_VALID;
>
> - analogix_dp_send_psr_spd(dp, &psr_vsc);
> - return 0;
> + return analogix_dp_send_psr_spd(dp, &psr_vsc);
> }
> EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);
>
> @@ -149,8 +148,7 @@ int analogix_dp_disable_psr(struct analogix_dp_device *dp)
> if (ret != 1)
> dev_err(dp->dev, "Failed to set DP Power0 %d\n", ret);
>
> - analogix_dp_send_psr_spd(dp, &psr_vsc);
> - return 0;
> + return analogix_dp_send_psr_spd(dp, &psr_vsc);
> }
> EXPORT_SYMBOL_GPL(analogix_dp_disable_psr);
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> index 5c6a28806129..b039b28d8fcc 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> @@ -20,6 +20,8 @@
> #define MAX_CR_LOOP 5
> #define MAX_EQ_LOOP 5
>
> +#define DP_TIMEOUT_PSR_LOOP_MS 300
> +
> /* DP_MAX_LANE_COUNT */
> #define DPCD_ENHANCED_FRAME_CAP(x) (((x) >> 7) & 0x1)
> #define DPCD_MAX_LANE_COUNT(x) ((x) & 0x1f)
> @@ -247,8 +249,8 @@ void analogix_dp_config_video_slave_mode(struct
> analogix_dp_device *dp);
> void analogix_dp_enable_scrambling(struct analogix_dp_device *dp);
> void analogix_dp_disable_scrambling(struct analogix_dp_device *dp);
> void analogix_dp_enable_psr_crc(struct analogix_dp_device *dp);
> -void analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
> - struct edp_vsc_psr *vsc);
> +int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
> + struct edp_vsc_psr *vsc);
> ssize_t analogix_dp_transfer(struct analogix_dp_device *dp,
>struct drm_dp_aux_msg *msg);
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> index 303083ad28e3..005a3f7005d2 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> @@ -10,10 +10,11 @@
> * option) any later version.
> */
>
> -#include
> -#include
> #include
> +#include
> #include
> +#include
> +#include
>
> #include
>
> @@ -992,10 +993,25 @@ void analogix_dp_enable_psr_crc(struct
> analogix_dp_device *dp)
> writel(PSR_VID_CRC_ENABLE, dp->reg_base + ANALOGIX_DP_CRC_CON);
> }
>
> -void analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
> - struct edp_vsc_psr *vsc)
> +static ssize_t analogix_dp_get_psr_status(struct analogix_dp_device *dp)
> +{
> + ssize_t val;
> + u8 status;
> +
> + val = drm_dp_dpcd_readb(&dp->aux, DP_PSR_STATUS, &status);
> + if (val < 0) {
> + dev_err(dp->dev, "PSR_STATUS read failed ret=%zd", val);
> + return val;
> + }
> + return status;
> +}
> +
> +int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
> + struct edp_vsc_psr *vsc)
> {
> unsigned int val;
> + int ret;
> + ssize_t psr_status;
>
> /* don't send info frame */
> val = readl(dp->reg_base + ANALOGIX_DP_PKT
Re: [PATCH v4 02/38] drm/rockchip: Don't use atomic constructs for psr
Am Montag, 5. März 2018, 23:22:54 CET schrieb Enric Balletbo i Serra: > From: Sean Paul > > Instead of using timer and spinlocks, use delayed_work and > mutexes for rockchip psr. This allows us to make blocking > calls when enabling/disabling psr (which is sort of important > given we're talking over dpcd to the display). > > Cc: Caesar Wang > Cc: 征增 王 > Cc: Stéphane Marchesin > Signed-off-by: Sean Paul > Signed-off-by: Thierry Escande > Signed-off-by: Enric Balletbo i Serra applied to drm-misc-next after checking on both pinky (rk3288) and kevin (rk3399). Heiko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 01/38] drm/bridge: analogix_dp: set psr activate/deactivate when enable/disable bridge
Am Montag, 5. März 2018, 23:22:53 CET schrieb Enric Balletbo i Serra: > From: zain wang > > There's a race between when bridge_disable and when vop_crtc_disable > are called. If the flush timer triggers a new psr work between these, > we will operate eDP without power shutdowned by bridge_disable. In this > case, moving activate/deactivate to enable/disable bridge to avoid it. > > Cc: Stéphane Marchesin > Signed-off-by: zain wang > Signed-off-by: Caesar Wang > Signed-off-by: Sean Paul > Signed-off-by: Thierry Escande > Signed-off-by: Enric Balletbo i Serra adapted the subject to drm/rockchip, as it only touches the rockchip glue driver for the analogix_dp and applied to drm-misc-next after checking on both pinky (rk3288) and kevin (rk3399). Heiko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 2/2 v4] drm_hwcomposer: Add platformhisi buffer importer for hikey and hikey960
On Thu, Mar 8, 2018 at 3:16 AM, Robert Foss wrote: > Hey John, > > This patch looks good to me. > > I have yet to build it, and I haven't brought my HiKey960 up for testing > quite yet. > > > On 03/07/2018 12:19 AM, John Stultz wrote: >> >> This allows for importing buffers allocated from the >> hikey and hikey960 gralloc implelementations. > > > "implelementations" -> "implementations" Fixed in my tree. Let me know if you have any further feedback after testing and I'll re-submit. thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 93727] [Regression] [r600g] Core profile is 3.2 instead of 3.3 in Big Endian PPC
https://bugs.freedesktop.org/show_bug.cgi?id=93727 --- Comment #5 from erhar...@mailbox.org --- Still core profile 3.2 on r600g, Mesa 18.0.0-rc4 $ glxinfo | grep -i opengl OpenGL vendor string: X.Org OpenGL renderer string: AMD CAICOS (DRM 2.49.0 / 4.9.85-gentoo) OpenGL core profile version string: 3.2 (Core Profile) Mesa 18.0.0-rc4 OpenGL core profile shading language version string: 1.50 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 18.0.0-rc4 OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.1 Mesa 18.0.0-rc4 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10 OpenGL ES profile extensions: -- 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 105401] Unable to start X on Vega AMDGPU(0): amdgpu_setup_kernel_mem failed
https://bugs.freedesktop.org/show_bug.cgi?id=105401 Timothy Pearson changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #4 from Timothy Pearson --- Version tested was 2.4.90. Will retest with 2.4.91. -- 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 105401] Unable to start X on Vega AMDGPU(0): amdgpu_setup_kernel_mem failed
https://bugs.freedesktop.org/show_bug.cgi?id=105401 --- Comment #3 from Andrey Grodzovsky --- Please check your libdrm and verify it's version is 2.4.91 https://lists.freedesktop.org/archives/dri-devel/2018-March/168156.html I believe it should be fixed by amdgpu: Fix mistake in initial hole size calculation. Andrey -- 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 1/1] drivers/gpu/drm/i915/intel_guc_log.c: work around gcc-4.4.4 union initializer issue
On Thu, 08 Mar 2018 12:06:46 +0200 Jani Nikula wrote: > On Wed, 07 Mar 2018, a...@linux-foundation.org wrote: > > From: Andrew Morton > > Subject: drivers/gpu/drm/i915/intel_guc_log.c: work around gcc-4.4.4 union > > initializer issue > > > > gcc-4.4.4 has problems with initalizers of anon unions. > > > > drivers/gpu/drm/i915/intel_guc_log.c: In function 'guc_log_control': > > drivers/gpu/drm/i915/intel_guc_log.c:64: error: unknown field > > 'logging_enabled' specified in initializer > > > > Work around this. > > Thanks for the patch, pushed to drm-intel-next-queued. > > That said, how long do we have to care about old compilers? I thought we > were converging on at the very least GCC 4.5 being required. Yes, I've seen some talk about that and it is about time for us to do it. I'm not sure what stage things are at though. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104854] smu7_populate_single_firmware_entry fails to load powerplay firmware.
https://bugs.freedesktop.org/show_bug.cgi?id=104854 --- Comment #3 from Alex Deucher --- What kernel are you using? I don't see any way the fw loading type could not be set correctly for any chip unless a module parameter was provided. Please attach your full dmesg output. What module parameters are you using? -- 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 104854] smu7_populate_single_firmware_entry fails to load powerplay firmware.
https://bugs.freedesktop.org/show_bug.cgi?id=104854 --- Comment #2 from José Pekkarinen --- Created attachment 137911 --> https://bugs.freedesktop.org/attachment.cgi?id=137911&action=edit Initialization output on SMU firmware load. Seems that autodetection of firmware method to load fails to get a proper default, setting firmware load to SMU on /etc/modprobe.d fixes the issue for me. $ DRI_PRIME=1 glxinfo|grep OpenGL OpenGL vendor string: X.Org OpenGL renderer string: AMD Radeon (TM) R7 M360 (ICELAND / DRM 3.23.0 / 4.15.7+, LLVM 5.0.1) OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.0.0-rc4 OpenGL core profile shading language version string: 4.50 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 18.0.0-rc4 OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.1 Mesa 18.0.0-rc4 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10 OpenGL ES profile extensions: -- 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: [Freedreno] [PATCH 2/2] arm64: dts: sdm845: Support GPU/GMU
On Wed, Mar 07, 2018 at 10:36:24AM +0530, Viresh Kumar wrote: > On 06-03-18, 08:37, Jordan Crouse wrote: > > I'll try to explain but I might need Stephen or some of the other folks to > > jump > > in and save me. > > Maybe you should start using his kernel.org address then ? :) > > > On sdm845 there are shared power resources controlled by the RPMh which is > > programed by a series of commands from the regulator driver; but in the case > > of the GPU the votes are passed to the GMU (graphics management unit) which > > communicates with the RPMh on behalf of the GPU. > > > > In order to construct the RPMh vote we need first need a voltage level that > > we > > can look up in a database. qcom,arc-level is the voltage level associated > > with > > a specific OPP. > > > > I had previously been abusing this with opp-microvolt but that was wrong for > > obvious reasons and then Stephen pointed out that this would be a better > > way. > > Glad that you shared that :) > > A solution is already in progress for that and is partially merged as > well. > > Look for "performance_state" in genpd and OPP cores (already merged), > followed by this series here: > > https://lkml.kernel.org/r/cover.1513926033.git.viresh.ku...@linaro.org It seems to me that performance_state has a direct relationship with genpd which is good for CPU votes but in this case, we're just passing along raw data to an independent microcontroller. The 'qcom,arc-level' is used to construct the actual values that the GMU will program into the RPMh. Since these are informational (from the CPU perspective) rather than functional I feel like that using performance_state for this would be as hacky as using opp-microvolt or something else. Jordan -- 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
[Bug 199047] [amdgpu CARRIZO] disabled backlight after S3 resume
https://bugzilla.kernel.org/show_bug.cgi?id=199047 --- Comment #7 from Johannes Hirte (johannes.hi...@datenkhaos.de) --- (In reply to Alex Deucher from comment #6) > Created attachment 274621 [details] > possible fix > > Does this fix it? Yes, fixed with this patch. -- 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
[PATCH] drm/meson: Add support for DMT modes on HDMI
This patch adds support for DMT display modes over HDMI.
The modes timings configurations are from the Amlogic Vendor linux tree
and tested over multiples monitors.
Previously only a selected number of CEA modes were supported.
Only these following modes are supported with these changes:
- 640x480@60Hz
- 800x600@60Hz
- 1024x768@60Hz
- 1152x864@75Hz
- 1280x1024@60Hz
- 1600x1200@60Hz
- 1920x1080@60Hz
The associated code to handle the clock rates is also added.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_dw_hdmi.c | 21 +-
drivers/gpu/drm/meson/meson_vclk.c| 219 -
drivers/gpu/drm/meson/meson_venc.c| 347 +-
drivers/gpu/drm/meson/meson_venc.h| 1 +
4 files changed, 570 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index 17de3af..fd1d365 100644
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -554,12 +554,12 @@ dw_hdmi_mode_valid(struct drm_connector *connector,
mode->vdisplay, mode->vsync_start,
mode->vsync_end, mode->vtotal, mode->type, mode->flags);
- /* For now, only accept VIC modes */
- if (!vic)
- return MODE_BAD;
-
- /* For now, filter by supported VIC modes */
- if (!meson_venc_hdmi_supported_vic(vic))
+ /* Check against non-VIC supported modes */
+ if (!vic) {
+ if (!meson_venc_hdmi_supported_mode(mode))
+ return MODE_BAD;
+ /* Check against supported VIC modes */
+ } else if (meson_venc_hdmi_supported_vic(vic))
return MODE_BAD;
vclk_freq = mode->clock;
@@ -585,9 +585,14 @@ dw_hdmi_mode_valid(struct drm_connector *connector,
/* Finally filter by configurable vclk frequencies */
switch (vclk_freq) {
+ case 25175:
+ case 4:
case 54000:
+ case 65000:
case 74250:
+ case 108000:
case 148500:
+ case 162000:
case 297000:
case 594000:
return MODE_OK;
@@ -652,10 +657,6 @@ static void meson_venc_hdmi_encoder_mode_set(struct
drm_encoder *encoder,
DRM_DEBUG_DRIVER("%d:\"%s\" vic %d\n",
mode->base.id, mode->name, vic);
- /* Should have been filtered */
- if (!vic)
- return;
-
/* VENC + VENC-DVI Mode setup */
meson_venc_hdmi_mode_set(priv, vic, mode);
diff --git a/drivers/gpu/drm/meson/meson_vclk.c
b/drivers/gpu/drm/meson/meson_vclk.c
index 4767704..f051122 100644
--- a/drivers/gpu/drm/meson/meson_vclk.c
+++ b/drivers/gpu/drm/meson/meson_vclk.c
@@ -328,14 +328,24 @@ static void meson_venci_cvbs_clock_config(struct
meson_drm *priv)
#define MESON_VCLK_HDMI_DDR_54000 2
/* 2970 /4 /1 /1 /5 /1 => /1 /2 */
#define MESON_VCLK_HDMI_DDR_148500 3
+/* 4028 /4 /4 /1 /5 /2 => /1 /1 */
+#define MESON_VCLK_HDMI_25175 4
+/* 3200 /4 /2 /1 /5 /2 => /1 /1 */
+#define MESON_VCLK_HDMI_4 5
+/* 5200 /4 /2 /1 /5 /2 => /1 /1 */
+#define MESON_VCLK_HDMI_65000 6
/* 2970 /2 /2 /2 /5 /1 => /1 /1 */
-#define MESON_VCLK_HDMI_74250 4
+#define MESON_VCLK_HDMI_74250 7
+/* 4320 /4 /1 /1 /5 /2 => /1 /1 */
+#define MESON_VCLK_HDMI_108000 8
/* 2970 /1 /2 /2 /5 /1 => /1 /1 */
-#define MESON_VCLK_HDMI_148500 5
+#define MESON_VCLK_HDMI_148500 9
+/* 3240 /2 /1 /1 /5 /2 => /1 /1 */
+#define MESON_VCLK_HDMI_162000 10
/* 2970 /1 /1 /1 /5 /2 => /1 /1 */
-#define MESON_VCLK_HDMI_297000 6
+#define MESON_VCLK_HDMI_297000 11
/* 5940 /1 /1 /2 /5 /1 => /1 /1 */
-#define MESON_VCLK_HDMI_594000 7
+#define MESON_VCLK_HDMI_594000 12
struct meson_vclk_params {
unsigned int pll_base_freq;
@@ -401,6 +411,46 @@ struct meson_vclk_params {
.vid_pll_div = VID_PLL_DIV_5,
.vclk_div = 1,
},
+ [MESON_VCLK_HDMI_25175] = {
+ .pll_base_freq = 4028000,
+ .pll_od1 = 4,
+ .pll_od2 = 4,
+ .pll_od3 = 1,
+ .vid_pll_div = VID_PLL_DIV_5,
+ .vclk_div = 2,
+ },
+ [MESON_VCLK_HDMI_4] = {
+ .pll_base_freq = 320,
+ .pll_od1 = 4,
+ .pll_od2 = 2,
+ .pll_od3 = 1,
+ .vid_pll_div = VID_PLL_DIV_5,
+ .vclk_div = 2,
+ },
+ [MESON_VCLK_HDMI_65000] = {
+ .pll_base_freq = 520,
+ .pll_od1 = 4,
+ .pll_od2 = 2,
+ .pll_od3 = 1,
+ .vid_pll_div = VID_PLL_DIV_5,
+ .vclk_div = 2,
+ },
+ [MESON_VCLK_HDMI_108000] = {
+ .pll_base_freq = 432,
+ .pll_od1 = 4,
+ .pll_od2 = 1,
+ .pll_od3 = 1,
+ .vid_pll_div
Re: [RFC][PATCH 1/2] drm_hwcomposer: Error out on YUV layer as it would fail for single planes
On Thu, Mar 8, 2018 at 3:10 AM, Robert Foss wrote:
> Hey John,
>
>
> On 03/07/2018 12:19 AM, John Stultz wrote:
>>
>> As suggested by Alexandru-Cosmin Gheorghe:
>>
>> ConvertHALFormatToDrm logic would work only for 1 plane formats,
>> and probably gets rejected by drmModeAddFb2, but to save
>> debugging time maybe it worth removing DRM_FORMAT_YVU420 from
>> ConvertHALFormatToDrm and checking it's return code.
>>
>> So this patch tries to do this.
>>
>> Cc: Marissa Wall
>> Cc: Sean Paul
>> Cc: Dmitry Shmidt
>> Cc: Robert Foss
>> Cc: Matt Szczesiak
>> Cc: Liviu Dudau
>> Cc: David Hanna
>> Cc: Rob Herring
>> Cc: Alexandru-Cosmin Gheorghe
>> Signed-off-by: John Stultz
>> ---
>> platformdrmgeneric.cpp | 15 +++
>> 1 file changed, 11 insertions(+), 4 deletions(-)
>>
>> diff --git a/platformdrmgeneric.cpp b/platformdrmgeneric.cpp
>> index 741d42b..33f1ea0 100644
>> --- a/platformdrmgeneric.cpp
>> +++ b/platformdrmgeneric.cpp
>> @@ -76,8 +76,6 @@ uint32_t
>> DrmGenericImporter::ConvertHalFormatToDrm(uint32_t hal_format) {
>> return DRM_FORMAT_ABGR;
>> case HAL_PIXEL_FORMAT_RGB_565:
>> return DRM_FORMAT_BGR565;
>> -case HAL_PIXEL_FORMAT_YV12:
>> - return DRM_FORMAT_YVU420;
>
>
> I'm not sure I understand the rationale for removing YVU420.
Mostly its on Alexandru's suggestion, as I don't have any experience
w/ using YVU420. Per his suggestion, my sense was that since its a
multi-plane format it was expected to fail with drmModeAddFB2().
If that's incorrect, I'm fine with dropping this change.
thanks
-john
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 5/6] drm/i915: Introduce 'priority offset' for GPU contexts (v2)
On Thu, Mar 08, 2018 at 06:55:34PM +, Chris Wilson wrote: > Quoting Chris Wilson (2018-03-08 18:48:51) > > Quoting Matt Roper (2018-03-08 18:22:06) > > > * Option 2: Allow priority offset to be set in a much larger range > > >(e.g., [SHRT_MIN+1023,SHRT_MAX-1023]). This allows cgroups to have > > >effective priority ranges that don't overlap. cgroup ranges can also > > >be intentionally set above I915_PRIORITY_DISPLAY to allow us to > > >define classes of applications whose work is more important than > > >maintaining a stable framerate on the display. We'd also probably > > >need to shift the kernel idle context down to something like INT_MIN > > >instead of using -1024. > > > > INT_MIN+1 just to be awkward. (INT_MIN is I915_PRIORITY_INVALID.) > > > > Something to bear in mind is that I want to reserve the low 8 bits of > > ctx->priority for internal use (heuristic adjustments by the scheduler). > > Can shrink that to say 3 bits in the current scheme. > > > > 3bits for internal adjustment > > 20bits for user priority. > > 8bits for cgroup offset. > > signbit. > > > > Nothing prohibits us from moving to 64b if required. But 32b should be > > enough range for plenty of clients and cgroups, imo. Reducing cgroup > > offset to 6 bits would be nice :) > > Forgot to comment on the policy decision of I915_PRIORITY_DISPLAY. > It's naughty that it's a magic constant that isn't exposed to the > sysadmin, so I would still set it to the maximum priority possible under > the extended scheme (i.e. INT_MAX), but allow for it to be adjusted. > I915_SETPARAM *shivers* Maybe that's a topic for cgroup as well if we can > associate the pageflip with a process and find its interactivity settings. > > Can I expose just about any random policy decision through cgroup? > -Chris If the policy applies to a cgroup of processes, then we can deal with pretty much any kind of policy as long as we stick to the driver ioctl approach in this series. E.g., we could add a cgroup setting "eligible for display boost" so that only specific processes are eligible for a display boost. If we want to control a single overall system value (e.g., "set the display boost fixed value") we could technically do that by having such parameters set on the v2 hierarchy's root cgroup, but that seems a bit counterintuitive and I'm not sure if there's a benefit to doing so. Using a more general interface like I915_SETPARAM or sysfs or something seems more appropriate in that case. Matt -- Matt Roper Graphics Software Engineer IoTG Platform Enabling & Development Intel Corporation (916) 356-2795 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105401] Unable to start X on Vega AMDGPU(0): amdgpu_setup_kernel_mem failed
https://bugs.freedesktop.org/show_bug.cgi?id=105401 Alex Deucher changed: What|Removed |Added Product|DRI |Mesa Version|XOrg git|unspecified Component|DRM/AMDgpu |Drivers/Gallium/radeonsi QA Contact||dri-devel@lists.freedesktop ||.org -- 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 105273] [r350] missing background, transparency not working & other glitches in ETR (AGP, ppc, mesa-18.0.0_rc4)
https://bugs.freedesktop.org/show_bug.cgi?id=105273 --- Comment #6 from erhar...@mailbox.org --- Tried a Radeon HD 6450 on my PCIe PowerMac G5 11,2 for another comparison. Graphics are rendered correctly! So it seems this bug is a specific r300 driver problem, not a generic Big Endian problem. $ glxinfo | grep -i opengl OpenGL vendor string: X.Org OpenGL renderer string: AMD CAICOS (DRM 2.49.0 / 4.9.85-gentoo) OpenGL core profile version string: 3.2 (Core Profile) Mesa 18.0.0-rc4 OpenGL core profile shading language version string: 1.50 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 18.0.0-rc4 OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.1 Mesa 18.0.0-rc4 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10 OpenGL ES profile extensions: -- 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 5/6] drm/i915: Introduce 'priority offset' for GPU contexts (v2)
Quoting Chris Wilson (2018-03-08 18:48:51) > Quoting Matt Roper (2018-03-08 18:22:06) > > * Option 2: Allow priority offset to be set in a much larger range > >(e.g., [SHRT_MIN+1023,SHRT_MAX-1023]). This allows cgroups to have > >effective priority ranges that don't overlap. cgroup ranges can also > >be intentionally set above I915_PRIORITY_DISPLAY to allow us to > >define classes of applications whose work is more important than > >maintaining a stable framerate on the display. We'd also probably > >need to shift the kernel idle context down to something like INT_MIN > >instead of using -1024. > > INT_MIN+1 just to be awkward. (INT_MIN is I915_PRIORITY_INVALID.) > > Something to bear in mind is that I want to reserve the low 8 bits of > ctx->priority for internal use (heuristic adjustments by the scheduler). > Can shrink that to say 3 bits in the current scheme. > > 3bits for internal adjustment > 20bits for user priority. > 8bits for cgroup offset. > signbit. > > Nothing prohibits us from moving to 64b if required. But 32b should be > enough range for plenty of clients and cgroups, imo. Reducing cgroup > offset to 6 bits would be nice :) Forgot to comment on the policy decision of I915_PRIORITY_DISPLAY. It's naughty that it's a magic constant that isn't exposed to the sysadmin, so I would still set it to the maximum priority possible under the extended scheme (i.e. INT_MAX), but allow for it to be adjusted. I915_SETPARAM *shivers* Maybe that's a topic for cgroup as well if we can associate the pageflip with a process and find its interactivity settings. Can I expose just about any random policy decision through cgroup? -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99859] Glamor Crashes on big endian Hardware
https://bugs.freedesktop.org/show_bug.cgi?id=99859
--- Comment #23 from erhar...@mailbox.org ---
Tried Glamor on a more recent xorg stack on my PM G5 11,2 which works perfectly
well! It's on a Radeon HD 6450 however, so a r600 card and not a radeonsi as
the HD 7750.
I am running:
sys-kernel/gentoo-sources-4.9.85
x11-libs/libdrm-2.4.90
x11-drivers/xf86-video-ati-7.10.0
media-libs/mesa-18.0.0_rc4
[ 153.370] (--) Depth 24 pixmap format is 32 bpp
[ 153.372] (II) RADEON(0): [DRI2] Setup complete
[ 153.372] (II) RADEON(0): [DRI2] DRI driver: r600
[ 153.372] (II) RADEON(0): [DRI2] VDPAU driver: r600
[ 153.374] (II) RADEON(0): Front buffer size: 8160K
[ 153.374] (II) RADEON(0): VRAM usage limit set to 218116K
[ 153.378] (II) RADEON(0): SYNC extension fences enabled
[ 153.379] (II) RADEON(0): Present extension enabled
[ 153.379] (==) RADEON(0): DRI3 enabled
[ 153.379] (==) RADEON(0): Backing store enabled
[ 153.379] (II) RADEON(0): Direct rendering enabled
[ 153.484] (II) RADEON(0): Use GLAMOR acceleration.
[ 153.485] (II) RADEON(0): Acceleration enabled
[ 153.485] (==) RADEON(0): DPMS enabled
[ 153.485] (==) RADEON(0): Silken mouse enabled
[ 153.485] (II) RADEON(0): Set up textured video (glamor)
[ 153.485] (II) RADEON(0): [XvMC] Associated with GLAMOR Textured Video.
[ 153.485] (II) RADEON(0): [XvMC] Extension initialized.
[ 153.485] (II) RADEON(0): RandR 1.2 enabled, ignore the following RandR
disabled message.
[ 153.487] (--) RandR disabled
[ 153.492] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
[ 153.492] (II) AIGLX: enabled GLX_ARB_create_context
[ 153.492] (II) AIGLX: enabled GLX_ARB_create_context_profile
[ 153.492] (II) AIGLX: enabled GLX_EXT_create_context_es{,2}_profile
[ 153.492] (II) AIGLX: enabled GLX_INTEL_swap_event
[ 153.492] (II) AIGLX: enabled GLX_SGI_swap_control
[ 153.492] (II) AIGLX: enabled GLX_EXT_framebuffer_sRGB
[ 153.492] (II) AIGLX: enabled GLX_ARB_fbconfig_float
[ 153.492] (II) AIGLX: enabled GLX_EXT_fbconfig_packed_float
[ 153.492] (II) AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects
[ 153.492] (II) AIGLX: enabled GLX_ARB_create_context_robustness
[ 153.494] (II) AIGLX: Loaded and initialized r600
[ 153.494] (II) GLX: Initialized DRI2 GL provider for screen 0
[ 153.498] (II) RADEON(0): Setting screen physical size to 508 x 285
Only downside at the moment is that I need to run a 4.9.x kernel to get 2D/3D
acceleration 'cause of bug #99851.
--
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 5/6] drm/i915: Introduce 'priority offset' for GPU contexts (v2)
Quoting Matt Roper (2018-03-08 18:22:06) > On Thu, Mar 08, 2018 at 01:11:33PM +, Chris Wilson wrote: > > Quoting Chris Wilson (2018-03-08 11:32:04) > > > Quoting Matt Roper (2018-03-06 23:46:59) > > > > There are cases where a system integrator may wish to raise/lower the > > > > priority of GPU workloads being submitted by specific OS process(es), > > > > independently of how the software self-classifies its own priority. > > > > Exposing "priority offset" as an i915-specific cgroup parameter will > > > > enable such system-level configuration. > > > > > > > > Normally GPU contexts start with a priority value of 0 > > > > (I915_CONTEXT_DEFAULT_PRIORITY) and then may be adjusted up/down from > > > > there via other mechanisms. We'd like to provide a system-level input > > > > to the priority decision that will be taken into consideration, even > > > > when userspace later attempts to set an absolute priority value via > > > > I915_CONTEXT_PARAM_PRIORITY. The priority offset introduced here > > > > provides a base value that will always be added to (or subtracted from) > > > > the software's self-assigned priority value. > > > > > > > > This patch makes priority offset a cgroup-specific value; contexts will > > > > be created with a priority offset based on the cgroup membership of the > > > > process creating the context at the time the context is created. Note > > > > that priority offset is assigned at context creation time; migrating a > > > > process to a different cgroup or changing the offset associated with a > > > > cgroup will only affect new context creation and will not alter the > > > > behavior of existing contexts previously created by the process. > > > > > > > > v2: > > > > - Rebase onto new cgroup_priv API > > > > - Use current instead of drm_file->pid to determine which process to > > > >lookup priority for. (Chris) > > > > - Don't forget to subtract priority offset in context_getparam ioctl to > > > >make it match setparam behavior. (Chris) > > > > > > > > Signed-off-by: Matt Roper > > > > > > For ctx->priority/ctx->priority_offset > > > Reviewed-by: Chris Wilson > > > > As a reminder, we do have the question of how to bound ctx->priority + > > ctx->priority_offset. Currently, outside of the user range is privileged > > space reserved for the kernel (both above and below). Now we can move > > those even further to accommodate multiple non-overlapping cgroups. > > Yep, I mentioned this as an open question in the series coverletter. > > My understanding is that today we limit userspace-assigned priorities to > [1023,1023] and that the kernel can use the userspace range plus -1024 > (for the kernel idle context), 1024 (for boosting contexts the display > is waiting on), and INT_MAX (for the preempt context). Are there any > other special values we use today that I'm overlooking? > > I think we have the following options with how to proceed: > > * Option 1: Silently limit (priority+priority offset) to the existing >[-1023,1023] range. That means that if, for example, a user context >had a priority offset of 600 and tried to manually boost its context >priority to 600, it would simply be treated as a 1023 for scheduling >purposes. This approach is simple, but doesn't allow us to force >contexts in different cgroups into non-overlapping priority ranges >(i.e., lowest possible priority in one cgroup is still higher than >the highest possible priority in another cgroup). It also isn't >possible to define a class of applications as "more important than >display" via cgroup, which I think might be useful in some cases. Agreed, non-overlapping seems to be a useful property (apply the usual disclaimer for the rudimentary scheduler). > * Option 2: Allow priority offset to be set in a much larger range >(e.g., [SHRT_MIN+1023,SHRT_MAX-1023]). This allows cgroups to have >effective priority ranges that don't overlap. cgroup ranges can also >be intentionally set above I915_PRIORITY_DISPLAY to allow us to >define classes of applications whose work is more important than >maintaining a stable framerate on the display. We'd also probably >need to shift the kernel idle context down to something like INT_MIN >instead of using -1024. INT_MIN+1 just to be awkward. (INT_MIN is I915_PRIORITY_INVALID.) Something to bear in mind is that I want to reserve the low 8 bits of ctx->priority for internal use (heuristic adjustments by the scheduler). Can shrink that to say 3 bits in the current scheme. 3bits for internal adjustment 20bits for user priority. 8bits for cgroup offset. signbit. Nothing prohibits us from moving to 64b if required. But 32b should be enough range for plenty of clients and cgroups, imo. Reducing cgroup offset to 6 bits would be nice :) > * Option 3: No limits, leave behavior as it stands now in this patch >series (unrestricted range). If you're privileged enough to define >the
[Bug 105308] X log ballooning in size with "drmmode_wait_vblank failed for scanout update" and "get vblank counter failed"
https://bugs.freedesktop.org/show_bug.cgi?id=105308 --- Comment #12 from Michel Dänzer --- This might work better if you enable DC with amdgpu.dc=1 on the kernel command line. -- 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 5/6] drm/i915: Introduce 'priority offset' for GPU contexts (v2)
On Thu, Mar 08, 2018 at 01:11:33PM +, Chris Wilson wrote: > Quoting Chris Wilson (2018-03-08 11:32:04) > > Quoting Matt Roper (2018-03-06 23:46:59) > > > There are cases where a system integrator may wish to raise/lower the > > > priority of GPU workloads being submitted by specific OS process(es), > > > independently of how the software self-classifies its own priority. > > > Exposing "priority offset" as an i915-specific cgroup parameter will > > > enable such system-level configuration. > > > > > > Normally GPU contexts start with a priority value of 0 > > > (I915_CONTEXT_DEFAULT_PRIORITY) and then may be adjusted up/down from > > > there via other mechanisms. We'd like to provide a system-level input > > > to the priority decision that will be taken into consideration, even > > > when userspace later attempts to set an absolute priority value via > > > I915_CONTEXT_PARAM_PRIORITY. The priority offset introduced here > > > provides a base value that will always be added to (or subtracted from) > > > the software's self-assigned priority value. > > > > > > This patch makes priority offset a cgroup-specific value; contexts will > > > be created with a priority offset based on the cgroup membership of the > > > process creating the context at the time the context is created. Note > > > that priority offset is assigned at context creation time; migrating a > > > process to a different cgroup or changing the offset associated with a > > > cgroup will only affect new context creation and will not alter the > > > behavior of existing contexts previously created by the process. > > > > > > v2: > > > - Rebase onto new cgroup_priv API > > > - Use current instead of drm_file->pid to determine which process to > > >lookup priority for. (Chris) > > > - Don't forget to subtract priority offset in context_getparam ioctl to > > >make it match setparam behavior. (Chris) > > > > > > Signed-off-by: Matt Roper > > > > For ctx->priority/ctx->priority_offset > > Reviewed-by: Chris Wilson > > As a reminder, we do have the question of how to bound ctx->priority + > ctx->priority_offset. Currently, outside of the user range is privileged > space reserved for the kernel (both above and below). Now we can move > those even further to accommodate multiple non-overlapping cgroups. Yep, I mentioned this as an open question in the series coverletter. My understanding is that today we limit userspace-assigned priorities to [1023,1023] and that the kernel can use the userspace range plus -1024 (for the kernel idle context), 1024 (for boosting contexts the display is waiting on), and INT_MAX (for the preempt context). Are there any other special values we use today that I'm overlooking? I think we have the following options with how to proceed: * Option 1: Silently limit (priority+priority offset) to the existing [-1023,1023] range. That means that if, for example, a user context had a priority offset of 600 and tried to manually boost its context priority to 600, it would simply be treated as a 1023 for scheduling purposes. This approach is simple, but doesn't allow us to force contexts in different cgroups into non-overlapping priority ranges (i.e., lowest possible priority in one cgroup is still higher than the highest possible priority in another cgroup). It also isn't possible to define a class of applications as "more important than display" via cgroup, which I think might be useful in some cases. * Option 2: Allow priority offset to be set in a much larger range (e.g., [SHRT_MIN+1023,SHRT_MAX-1023]). This allows cgroups to have effective priority ranges that don't overlap. cgroup ranges can also be intentionally set above I915_PRIORITY_DISPLAY to allow us to define classes of applications whose work is more important than maintaining a stable framerate on the display. We'd also probably need to shift the kernel idle context down to something like INT_MIN instead of using -1024. * Option 3: No limits, leave behavior as it stands now in this patch series (unrestricted range). If you're privileged enough to define the cgroup settings for a system and you decide to shoot yourself in the foot by setting them to nonsense values, that's your own fault. Thoughts? Any other options to consider? > We also have the presumption that only privileged processes can raise a > priority, but I presume the cgroup property itself is protected. > -Chris The way the code is written write now, anyone who has write access to the cgroup itself (i.e., can migrate processes into/out of the cgroup) is allowed to adjust the i915-specific cgroup settings. So this depends on how the cgroups-v2 filesystem was initially mounted and/or how the filesystem permissions were adjusted after the fact; the details may vary from system to system depending on the policy decisions of the system integrator / system administrator. But I think an off-the-shelf Linux dis
Re: [PATCH libdrm] freedreno: add missing symbols to symbol-check
On 7 March 2018 at 08:48, Christian Gmeiner wrote: > 2018-03-06 16:37 GMT+01:00 Eric Engestrom : >> Fixes: 1384c081233751569473 "freedreno: add interface to get buffer address" >> Signed-off-by: Eric Engestrom > > Reviewed-by: Christian Gmeiner > ... and pushed to master since I was fitting that lovely case ;-) Thanks guys Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] meson: use pkg-config to detect libatomic_ops
On 5 March 2018 at 12:03, Eric Engestrom wrote:
> Ping? :)
> Both for this patch and the equivalent autotools patch it replies to.
>
The autotools one needs the CFLAGS added - meson does it automatically for us.
> On Wednesday, 2018-02-07 14:24:33 +, Eric Engestrom wrote:
>> Signed-off-by: Eric Engestrom
>> ---
>> amdgpu/meson.build| 2 +-
>> etnaviv/meson.build | 2 +-
>> freedreno/meson.build | 2 +-
>> intel/meson.build | 2 +-
>> meson.build | 3 ++-
>> nouveau/meson.build | 2 +-
>> omap/meson.build | 2 +-
>> radeon/meson.build| 2 +-
>> tegra/meson.build | 2 +-
>> 9 files changed, 10 insertions(+), 9 deletions(-)
>>
>> diff --git a/amdgpu/meson.build b/amdgpu/meson.build
>> index 8b0452056e2513892c2c..7040ebab86e271022323 100644
>> --- a/amdgpu/meson.build
>> +++ b/amdgpu/meson.build
>> @@ -37,7 +37,7 @@ libdrm_amdgpu = shared_library(
>>],
>>include_directories : [inc_root, inc_drm],
>>link_with : libdrm,
>> - dependencies : dep_pthread_stubs,
>> + dependencies : [dep_pthread_stubs, dep_atomic_ops],
>>version : '1.0.0',
>>install : true,
>> )
>> diff --git a/etnaviv/meson.build b/etnaviv/meson.build
>> index 1767733bd510efdaad86..ca2aa544c58924a15d8b 100644
>> --- a/etnaviv/meson.build
>> +++ b/etnaviv/meson.build
>> @@ -31,7 +31,7 @@ libdrm_etnaviv = shared_library(
>>include_directories : [inc_root, inc_drm],
>>link_with : libdrm,
>>c_args : warn_c_args,
>> - dependencies : [dep_pthread_stubs, dep_rt],
>> + dependencies : [dep_pthread_stubs, dep_rt, dep_atomic_ops],
>>version : '1.0.0',
>>install : true,
>> )
>> diff --git a/freedreno/meson.build b/freedreno/meson.build
>> index de6a413fa93e63c0ad4a..da993c10355578838f29 100644
>> --- a/freedreno/meson.build
>> +++ b/freedreno/meson.build
>> @@ -44,7 +44,7 @@ libdrm_freedreno = shared_library(
>>[files_freedreno, config_file],
>>c_args : warn_c_args,
>>include_directories : [inc_root, inc_drm],
>> - dependencies : [dep_valgrind, dep_pthread_stubs, dep_rt],
>> + dependencies : [dep_valgrind, dep_pthread_stubs, dep_rt, dep_atomic_ops],
>>link_with : libdrm,
>>version : '1.0.0',
>>install : true,
>> diff --git a/intel/meson.build b/intel/meson.build
>> index ad877274f8d488a80d54..42402f60e38cd5e7359f 100644
>> --- a/intel/meson.build
>> +++ b/intel/meson.build
>> @@ -29,7 +29,7 @@ libdrm_intel = shared_library(
>>],
>>include_directories : [inc_root, inc_drm],
>>link_with : libdrm,
>> - dependencies : [dep_pciaccess, dep_pthread_stubs, dep_rt, dep_valgrind],
>> + dependencies : [dep_pciaccess, dep_pthread_stubs, dep_rt, dep_valgrind,
>> dep_atomic_ops],
>>c_args : warn_c_args,
>>version : '1.0.0',
>>install : true,
>> diff --git a/meson.build b/meson.build
>> index a19e600c7475b2578e2d..f45c14a70baa2456582d 100644
>> --- a/meson.build
>> +++ b/meson.build
>> @@ -51,6 +51,7 @@ cc = meson.get_compiler('c')
>> intel_atomics = false
>> lib_atomics = false
>>
>> +dep_atomic_ops = dependency('atomic_ops', required : false)
>> if cc.compiles('''
>> int atomic_add(int *i) { return __sync_add_and_fetch (i, 1); }
>> int atomic_cmpxchg(int *i, int j, int k) { return
>> __sync_val_compare_and_swap (i, j, k); }
>> @@ -58,7 +59,7 @@ if cc.compiles('''
>> name : 'Intel Atomics')
>>intel_atomics = true
>>with_atomics = true
>
> Change added here locally; there's no need to link again `dep_atomic_ops`
> in this branch, although it doesn't hurt:
>
> + dep_atomic_ops = []
>
The dummy dep_atomic_ops is needed for almost all cases in the if/else
ladder. The exception being the .found() case.
With that
Reviewed-by: Emil Velikov
-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] configure/Makefile.am: use pkg-config to discover libatomic_ops
On 6 February 2018 at 21:19, Peter Seiderer wrote: > From: Thomas Petazzoni > > The configure script currently tests the availability of libatomic_ops > by checking the presence of atomic_ops.h. While this is good enough as > an availability test, it is not sufficient as on some platforms, > libatomic_ops provides an actual shared library against which we > should be linked to access libatomic_ops functionality. > > Therefore, we instead use PKG_CHECK_MODULES() to test the availability > of libatomic_ops. Besides testing its availability, this also fills in > the ATOMIC_OPS_LIBS variable with the list of libraries we need to > link with to use libatomic_ops. > > All Mesa drivers that include xf86atomic.h have been updated to link > against ATOMIC_OPS_LIBS. > > Of course, if we're not using libatomic_ops, ATOMIC_OPS_LIBS is empty, > and we don't link against it. > > Signed-off-by: Thomas Petazzoni > Signed-off-by: Peter Seiderer > [Bernd: PKG_CHECK_MODULES should not fail when libatomic_ops is missing] > Signed-off-by: Bernd Kuhls > --- > amdgpu/Makefile.am| 2 +- > configure.ac | 2 +- > etnaviv/Makefile.am | 3 ++- > freedreno/Makefile.am | 3 ++- > intel/Makefile.am | 3 ++- > nouveau/Makefile.am | 2 +- > omap/Makefile.am | 2 +- > radeon/Makefile.am| 2 +- > tegra/Makefile.am | 2 +- You're adding ATOMIC_OPS_LIBS to all the correct places, although ATOMIC_OPS_CFLAGS seems to be missing. Can you re-spin with that one added? Thanks Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: nouveau 30bpp / deep color status
Hi, On 8 March 2018 at 17:08, Ilia Mirkin wrote: > On Thu, Mar 8, 2018 at 11:57 AM, Mario Kleiner > wrote: >> Under EGL there is matching of channel masks, so only X11+GLX is >> problematic. Not sure if anything special would need to be done for >> XWayland, haven't looked at that at all so far. Or the modesetting ddx, >> which currently assumes xrgb ordering for 10 bit. > > For the modesetting ddx, it has to switch to drmAddFB2 so that it > knows the exact format. No other way around that, unfortunately. But > that'll require work, and I'm happy enough that xf86-video-nouveau > works (as that is what I recommend to anyone who'll listen). modesetting now uses AddFB2, as of relatively recently. >> There are some from Daniel which unify the handling of formats inside egl, >> not with any abgr2101010 definitions though. Indeed on master compositing >> doesn't work for depth 30 windows. I have some patches that fix this, and >> some hack for EGL/x11 compositing that seems to work. Will send them out >> soon. > > D'oh! Those patches were definitely there. I guess they got dropped at > some point. Daniel, can you resend those? Oops. Is this X11 or Wayland compositing? I'll resend those two, but it would probably be better to hold off merging them until you can verify I haven't done anything stupid. Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v3 09/12] drm: Add API for in-kernel clients
Den 06.03.2018 09.56, skrev Daniel Vetter:
On Thu, Feb 22, 2018 at 09:06:50PM +0100, Noralf Trønnes wrote:
This adds an API for writing in-kernel clients.
TODO:
- Flesh out and complete documentation.
- Cloned displays is not tested.
- Complete tiled display support and test it.
- Test plug/unplug different monitors.
- A runtime knob to prevent clients from attaching for debugging purposes.
- Maybe a way to unbind individual client instances.
- Maybe take the sysrq support in drm_fb_helper and move it here somehow.
- Add suspend/resume callbacks.
Does anyone know why fbdev requires suspend/resume?
Signed-off-by: Noralf Trønnes
The core client api I like. Some of the opens I'm seeing:
- If we go with using the internal kms api directly instead of IOCTL
wrappers then a huge pile of the functions you have here aren't needed
(e.g. all the event stuff we can just directly use vblank events instead
of all the wrapping). I'm leaning ever more into that direction, since
much less code to add.
Looking at drm_fb_helper once again I now see an opportunity to simplify
the modesetting code by nuking drm_fb_helper_connector and stop
maintaining an array of connectors. It looks to be possible to just
create an array temporarily in drm_setup_crtcs() for the duration of the
function. The connectors we care about are ref counted and attached to
modesets. This would remove the need for drm_fb_helper_add_one_connector().
So I might be able to do struct drm_fb_helper_crtc -> drm_client_crtc
and let the client API take over drm_setup_crtcs(). I'll give it a try.
There is one challenge I see upfront and that's the i915 fb_helper
callback in drm_setup_crtcs().
- The register/unregister model needs more thought. Allowing both clients
to register whenever they want to, and drm_device instances to come and
go is what fbcon has done, and the resulting locking is a horror show.
I think if we require that all in-kernel drm_clients are registers when
loading drm.ko (and enabled/disabled only per module options and
Kconfig), then we can throw out all the locking. That avoids a lot of
the headaches.
2nd, if the list of clients is static over the lifetime of drm.ko, we
also don't need to iterate existing drivers. Which avoids me having to
review the iterator patch (that's the other aspect where fbcon totally
falls over and essentially just ignores a bunch of races).
Are you talking about linking the clients into drm.ko?
drivers/gpu/drm/Makefile:
drm-$(CONFIG_DRM_CLIENT_BOOTSPLASH) += client/drm_bootsplash.o
drivers/gpu/drm/drm_drv.c:
static int __init drm_core_init(void)
{
+ drm_bootsplash_register();
+ drm_fbdev_register();
}
drivers/gpu/drm/drm_internal.h:
#ifdef DRM_CLIENT_BOOTSPLASH
void drm_bootsplash_register(void);
#else
static inline void drm_bootsplash_register(void)
{
}
#endif
drivers/gpu/drm/client/drm_bootsplash.c:
static const struct drm_client_funcs drm_bootsplash_funcs = {
.name = "drm_bootsplash",
.new = drm_bootsplash_new,
.remove = drm_bootsplash_remove,
.hotplug = drm_bootsplash_hotplug,
};
void drm_bootsplash_register(void)
{
drm_client_register(&drm_bootsplash_funcs);
}
drivers/gpu/drm/drm_client.c:
static LIST_HEAD(drm_client_funcs_list);
void drm_client_register(const struct drm_client_funcs *funcs)
{
struct drm_client_funcs_entry *funcs_entry;
funcs_entry = kzalloc(sizeof(*funcs_entry), GFP_KERNEL);
if (!funcs_entry) {
DRM_ERROR("Failed to register: %s\n", funcs->name);
return;
}
funcs_entry->funcs = funcs;
list_add(&funcs_entry->list, &drm_client_funcs_list);
DRM_DEBUG_KMS("%s\n", funcs->name);
}
And each client having a runtime enable/disable knob:
drivers/gpu/drm/client/drm_bootsplash.c:
static bool drm_bootsplash_enabled = true;
module_param_named(bootsplash_enabled, drm_bootsplash_enabled, bool, 0600);
MODULE_PARM_DESC(bootsplash_enabled, "Enable bootsplash client
[default=true]");
Simple USB Display
A few months back while looking at the udl shmem code, I got the idea
that I could turn a Raspberry Pi Zero into a $5 USB to HDMI/DSI/DPI/DBI/TV
adapter. The host side would be a simple tinydrm driver using the kernel
compression lib to speed up transfers. The gadget/device side would be a
userspace app decompressing the buffer into an exported dumb buffer.
While working with this client API I realized that I could use it and
write a kernel gadget driver instead avoiding the challenge of going
back and forth to userspace with the framebuffer. For such a client I
would have preferred it to be a loadable module not linked into drm.ko
to increase the chance that distributions would enable it.
Noralf.
---
drivers/gpu/drm/Kconfig |2 +
drivers/gpu/drm/Makefile|3 +-
drivers/gpu/drm/client/Kconfig |4 +
drivers/gpu/drm/client/Makefile |1 +
drivers/gpu/drm/client/drm_client.c | 161
Re: nouveau 30bpp / deep color status
On Thu, Mar 8, 2018 at 11:57 AM, Mario Kleiner wrote: > Cc'ing mesa-dev, which was left out. > > > On 03/05/2018 01:40 PM, Ilia Mirkin wrote: >> >> On Mon, Mar 5, 2018 at 2:25 AM, Mario Kleiner >> wrote: >>> Afaics EGL does the right thing wrt. channelmask matching of EGLConfigs >>> to >>> DRIconfigs, so we could probably implement dri_loader_get_cap(screen, >>> DRI_LOADER_CAP_RGBA_ORDERING) == TRUE for the EGL loaders. >>> >>> But for GLX it is not so easy or quick. I looked if i could make the >>> servers >>> GLX send proper channelmask attributes and Mesa parsing them, but there >>> aren't any GLX tags defined for channel masks, and all other tags come >>> from >>> official GLX extension headers. I'm not sure what the proper procedure >>> for >>> defining new tags is? Do we have to define a new GLX extension for that >>> and >>> get it in the Khronos registry and then back into the server/mesa >>> code-base? >> >> >> Can all of this be solved by a healthy dose of "don't do that"? i.e. >> make sure that the DDX only ever exposes one of these at a time? And >> also make the mesa driver only expose one as a DISPLAY_TARGET? >> > > Yes, if "don't do that" is consistently possible on all future drivers. I don't think it'd be undue burden for a driver to have to decide on one ordering which is The Way To Do It (tm) for that hw, even if the hw supports both. Could also drop some logic into the glx thing to always pick a specific one in case both are supported, and hopefully the DDX would have identical logic. > Under EGL there is matching of channel masks, so only X11+GLX is > problematic. Not sure if anything special would need to be done for > XWayland, haven't looked at that at all so far. Or the modesetting ddx, > which currently assumes xrgb ordering for 10 bit. For the modesetting ddx, it has to switch to drmAddFB2 so that it knows the exact format. No other way around that, unfortunately. But that'll require work, and I'm happy enough that xf86-video-nouveau works (as that is what I recommend to anyone who'll listen). > >>> >>> The current patches in mesa for XBGR also lack enablement pieces for EGL, >>> Wayland and X11 compositing, but that's a different problem. >> >> >> EGL/drm and EGL/wayland should be enabled (look at Daniel Stone's >> patches from a short while back, also upstream now). kmscube (with >> some patches that are upstream now) and weston both run OK for me. I >> think EGL/x11 is iffy though - haven't played with it. >> >>-ilia >> > > There are some from Daniel which unify the handling of formats inside egl, > not with any abgr2101010 definitions though. Indeed on master compositing > doesn't work for depth 30 windows. I have some patches that fix this, and > some hack for EGL/x11 compositing that seems to work. Will send them out > soon. D'oh! Those patches were definitely there. I guess they got dropped at some point. Daniel, can you resend those? -ilia ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: nouveau 30bpp / deep color status
Cc'ing mesa-dev, which was left out. On 03/05/2018 01:40 PM, Ilia Mirkin wrote: On Mon, Mar 5, 2018 at 2:25 AM, Mario Kleiner wrote: On 02/05/2018 12:50 AM, Ilia Mirkin wrote: In case anyone's curious about 30bpp framebuffer support, here's the current status: Kernel: Ben and I have switched the code to using a 256-based LUT for Kepler+, and I've also written a patch to cause the addfb ioctl to use the proper format. You can pick this up at: https://github.com/skeggsb/linux/commits/linux-4.16 (note the branch!) https://patchwork.freedesktop.org/patch/202322/ With these two, you should be able to use "X -depth 30" again on any G80+ GPU to bring up a screen (as you could in kernel 4.9 and earlier). However this still has some deficiencies, some of which I've addressed: xf86-video-nouveau: DRI3 was broken, and Xv was broken. Patches available at: https://github.com/imirkin/xf86-video-nouveau/commits/master mesa: The NVIDIA hardware (pre-Kepler) can only do XBGR scanout. Further the nouveau KMS doesn't add XRGB scanout for Kepler+ (although it could). Mesa was only enabled for XRGB, so I've piped XBGR through all the same places: https://github.com/imirkin/mesa/commits/30bpp Wrt. mesa, those patches are now in master and i think we have a bit of a problem under X11+GLX: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/dri/dri_screen.c#n108 dri_fill_in_modes() defines MESA_FORMAT_R10G10B10A2_UNORM, MESA_FORMAT_R10G10B10X2_UNORM at the top inbetween the BGRX/A formats ignoring the instructions that "/* The 32-bit RGBA format must not precede the 32-bit BGRA format. * Likewise for RGBX and BGRX. Otherwise, the GLX client and the GLX * server may disagree on which format the GLXFBConfig represents, * resulting in swapped color channels." RGBA/X formats should only be exposed if (dri_loader_get_cap(screen, DRI_LOADER_CAP_RGBA_ORDERING)) and that is only the case for the Android loader. The GLX code doesn't use the red/green/blueChannelMasks for proper matching of formats, and the server doesn't even transmit those masks to the client in the case of GLX. So whatever 10 bit format comes first will win when building the assignment to GLXFBConfigs. I looked at the code and how it behaves. In practice Intel gfx works because it's a classic DRI driver with its own method of building the DRIconfig's, and it only exposes the BGR101010 formats, so no danger of mixups. AMD's gallium drivers expose both BGR and RGB ordered 10 bit formats, but due to the ordering, the matching ends up only assigning the desired BGR formats that are good for AMD hw, discarding the RGB formats. nouveau works because it only exposes the desired RGB format for the hw. But with other gallium drivers for some SoC's or future gallium drivers it is not so clear if the right thing will happen. E.g., freedreno seems to support both BGR and RGB 10 bit formats as PIPE_BIND_DISPLAY_TARGET afaics, so i don't know if by luck the right thing would happen? FWIW freedreno does not presently support 10bpc scanout. Afaics EGL does the right thing wrt. channelmask matching of EGLConfigs to DRIconfigs, so we could probably implement dri_loader_get_cap(screen, DRI_LOADER_CAP_RGBA_ORDERING) == TRUE for the EGL loaders. But for GLX it is not so easy or quick. I looked if i could make the servers GLX send proper channelmask attributes and Mesa parsing them, but there aren't any GLX tags defined for channel masks, and all other tags come from official GLX extension headers. I'm not sure what the proper procedure for defining new tags is? Do we have to define a new GLX extension for that and get it in the Khronos registry and then back into the server/mesa code-base? Can all of this be solved by a healthy dose of "don't do that"? i.e. make sure that the DDX only ever exposes one of these at a time? And also make the mesa driver only expose one as a DISPLAY_TARGET? Yes, if "don't do that" is consistently possible on all future drivers. Under EGL there is matching of channel masks, so only X11+GLX is problematic. Not sure if anything special would need to be done for XWayland, haven't looked at that at all so far. Or the modesetting ddx, which currently assumes xrgb ordering for 10 bit. The current patches in mesa for XBGR also lack enablement pieces for EGL, Wayland and X11 compositing, but that's a different problem. EGL/drm and EGL/wayland should be enabled (look at Daniel Stone's patches from a short while back, also upstream now). kmscube (with some patches that are upstream now) and weston both run OK for me. I think EGL/x11 is iffy though - haven't played with it. -ilia There are some from Daniel which unify the handling of formats inside egl, not with any abgr2101010 definitions though. Indeed on master compositing doesn't work for depth 30 windows. I have some patches that fix this, and some hack for EGL/x11 compositing that seems to work. Will send them out soon. -mario __
Re: [PATCH v9 4/5] drm/rockchip: dw_hdmi: Move HDMI vpll clock enable to bind()
Am Freitag, 2. März 2018, 18:57:56 CET schrieb Enric Balletbo i Serra:
> From: Jeffy Chen
>
> The HDMI vpll clock should be enabled when bind() is called. So move the
> clk_prepare_enable of that clock to bind() function and add the missing
> clk_disable_unprepare() required in error handling path and unbind().
>
> Fixes: 12b9f204e804 ("drm: bridge/dw_hdmi: add rockchip rk3288 support")
> Signed-off-by: Jeffy Chen
> Signed-off-by: Thierry Escande
> Signed-off-by: Enric Balletbo i Serra
applied to drm-misc-next
Thanks
Heiko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 3/5] drm/rockchip: inno_hdmi: reorder clk_disable_unprepare call in unbind
Am Freitag, 2. März 2018, 18:57:55 CET schrieb Enric Balletbo i Serra:
> From: Jeffy Chen
>
> In bind the clk_prepare_enable of the HDMI pclk is called before adding the
> i2c_adapter. So it should be the other way around in unbind, first remove
> the i2c_adapter and then call the clk_disable_unprepare.
>
> Fixes: 412d4ae6b7a5 ("drm/rockchip: hdmi: add Innosilicon HDMI support")
> Signed-off-by: Jeffy Chen
> Signed-off-by: Thierry Escande
> Signed-off-by: Enric Balletbo i Serra
applied to drm-misc-next
Thanks
Heiko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 1/5] drm/rockchip: dw-mipi-dsi: Fix connector and encoder cleanup.
Am Freitag, 2. März 2018, 18:57:53 CET schrieb Enric Balletbo i Serra: > From: Jeffy Chen > > In bind()'s error handling path call destroy functions instead of > cleanup functions for encoder and connector and reorder to match how is > called in bind(). > > In unbind() call the connector and encoder destroy functions. > > Signed-off-by: Jeffy Chen > Signed-off-by: Thierry Escande > Signed-off-by: Enric Balletbo i Serra applied to drm-misc-next Thanks Heiko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 2/5] drm/rockchip: inno_hdmi: Fix error handling path.
Am Freitag, 2. März 2018, 18:57:54 CET schrieb Enric Balletbo i Serra:
> From: Jeffy Chen
>
> Add missing error handling in bind().
>
> Fixes: 412d4ae6b7a5 ("drm/rockchip: hdmi: add Innosilicon HDMI support")
> Signed-off-by: Jeffy Chen
> Signed-off-by: Thierry Escande
> [moved clk_disable_unprepare reordering in unbind to separate patch]
> Signed-off-by: Enric Balletbo i Serra
applied to drm-misc-next
Thanks
Heiko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau: Replace the iturbt_709 prop with the standarad COLOR_ENCODNIG prop
On Tue, Feb 27, 2018 at 10:49:39AM +0200, Ville Syrjälä wrote: > On Tue, Feb 27, 2018 at 12:54:47AM -0500, Ilia Mirkin wrote: > > On Tue, Feb 20, 2018 at 9:25 AM, Ilia Mirkin wrote: > > > On Tue, Feb 20, 2018 at 8:48 AM, Ville Syrjala > > > wrote: > > >> From: Ville Syrjälä > > >> > > >> Replace the ad-hoc iturbt_709 property with the new standard > > >> COLOR_ENCODING property. Compiles, but not tested. > > >> > > >> Cc: Daniel Vetter > > >> Cc: nouv...@lists.freedesktop.org > > >> Cc: Ben Skeggs > > >> Cc: Ilia Mirkin > > >> Signed-off-by: Ville Syrjälä > > > > > > s/standarad/standard/ in subject > > > > > > I'd like the opportunity to test this out on real hardware, but I > > > don't have any pre-NV41 boards plugged in right now. I should be able > > > to attend to it within 7 days. If you don't hear back from me by then, > > > I'd appreciate a ping, as I do let things (hopefully occasionally) > > > slip through. > > > > Tested this out on a NV34. Seems to work - at least the green SMPTE > > bar looks different in the two different modes (had to hack modetest > > to use the SMPTE pattern on planes). > > > > I do wonder about the new color range property... that's more of a > > connector thing than a plane thing no? Presumably over S-Video it's a > > partial range, and over VGA it's full? I'd flip it to always full here > > tbh. (Or just not provide it at all.) > > No, this property is just about the range of the input data. Full range > YCbCr isn't exaclty common so you'd rarely need this. JPEG uses full > range I believe. > > > > > Anyways, with the subject typo(s! noticed ENCODNIG -> ENCODING just > > now) fixed, this is > > > > Reviewed-by: Ilia Mirkin > > Cool. Thanks. Pushed to drm-misc-next with Ben's ack. 17:27 friendly reminder about https://patchwork.freedesktop.org/patch/205620/ -- ville was wondering whether you'd take it, or if he should push via drm-misc. 17:27 ack, i'd say ville should take it in drm-misc for now -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105401] Unable to start X on Vega AMDGPU(0): amdgpu_setup_kernel_mem failed
https://bugs.freedesktop.org/show_bug.cgi?id=105401 Timothy Pearson changed: What|Removed |Added Hardware|Other |PowerPC OS|All |Linux (All) -- 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 105401] Unable to start X on Vega AMDGPU(0): amdgpu_setup_kernel_mem failed
https://bugs.freedesktop.org/show_bug.cgi?id=105401 --- Comment #2 from Timothy Pearson --- Created attachment 137901 --> https://bugs.freedesktop.org/attachment.cgi?id=137901&action=edit Xorg.0.log after load attempt -- 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 105401] Unable to start X on Vega AMDGPU(0): amdgpu_setup_kernel_mem failed
https://bugs.freedesktop.org/show_bug.cgi?id=105401 --- Comment #1 from Timothy Pearson --- Created attachment 137900 --> https://bugs.freedesktop.org/attachment.cgi?id=137900&action=edit dmesg after xorg load attempt -- 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 105401] Unable to start X on Vega AMDGPU(0): amdgpu_setup_kernel_mem failed
https://bugs.freedesktop.org/show_bug.cgi?id=105401 Bug ID: 105401 Summary: Unable to start X on Vega AMDGPU(0): amdgpu_setup_kernel_mem failed Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: tpear...@raptorengineering.com A similar issue to the one described in Bug #105172 is affecting Vega GPUs on POWER9 machines. Log files attached. System configuration: Software versions: Linux 4.16.0-rc4 ppc64el GPU hardware: Radeon RX Vega 56 CPU hardware: POWER9 PowerNV -- 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 199047] [amdgpu CARRIZO] disabled backlight after S3 resume
https://bugzilla.kernel.org/show_bug.cgi?id=199047 --- Comment #6 from Alex Deucher (alexdeuc...@gmail.com) --- Created attachment 274621 --> https://bugzilla.kernel.org/attachment.cgi?id=274621&action=edit possible fix Does this fix it? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103953] [DC] Polaris10: Missing modes when enabling DC
https://bugs.freedesktop.org/show_bug.cgi?id=103953 --- Comment #12 from Alex Deucher --- (In reply to Aleksei from comment #11) > I'm losing refresh rates higher than 60Hz with dc=1 on 4.15.6 kernel - is > that fixed too? > > Monitor 1920x1080 144Hz, GPU RX 560, connection over DVI-D. With dc=0 I can > set 1920x1080 144Hz, with dc=1 only 1920x1080 60Hz. You'll need the latest 4.16 with the fixes I sent out yesterday. -- 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 10/42] 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.
>
> Signed-off-by: Ramalingam C
> ---
> drivers/misc/mei/hdcp/mei_hdcp.c | 73
>
> include/linux/mei_hdcp.h | 11 ++
> 2 files changed, 84 insertions(+)
>
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index 63f77800a6f7..516ad6a40616 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
>
> #include "mei_hdcp.h"
>
> @@ -46,6 +47,78 @@ static inline bool
> mei_cldev_active_and_enabled(struct mei_cl_device *cldev)
> return mei_cldev_enabled(cldev);
> }
>
> +/**
> + * mei_initiate_hdcp2_session:
> + * Function to start a Wired HDCP2.2 Tx Session with ME FW
> + *
> + * @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_hdcp_data *data,
> +struct hdcp2_ake_init *ake_data) {
You should use cldev as a first argument for all those functions
> + struct wired_cmd_initiate_hdcp2_session_in session_init_in = { { 0 }
> };
> + struct wired_cmd_initiate_hdcp2_session_out
> + session_init_out = { { 0 } };
> + enum me_hdcp_status status;
> + struct device *dev;
> + ssize_t byte;
> +
> + if (!data || !ake_data)
> + return -EINVAL;
> +
> + /* check for the mei_device enabled or not */
> + if (!mei_cldev_active_and_enabled(data->cldev))
> + return -ENODEV;
No reason cldev will be NULL here.
> + dev = &data->cldev->dev;
> +
> + /* Fill header details */
Those types of comments are redundant.
> + 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;
> +
> + /* Fill in the In Data */
Those types of comments are redundant.
> + 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;
> +
> + /* Request to ME */
> + byte = mei_cldev_send(data->cldev, (u8 *)&session_init_in,
> + sizeof(session_init_in));
> + if (byte < 0) {
> + dev_err(dev, "mei_cldev_send failed. %d\n", (int)byte);
> + return byte;
> + }
> +
> + /* Response from ME */
> + byte = mei_cldev_recv(data->cldev, (u8 *)&session_init_out,
> + sizeof(session_init_out));
> + if (byte < 0) {
> + dev_err(dev, "mei_cldev_recv failed. %d\n", (int)byte);
> + return byte;
> + }
> +
> + status = (enum me_hdcp_status)session_init_out.header.status;
Useless cast
> + if (status != ME_HDCP_STATUS_SUCCESS) {
> + dev_err(dev, "ME cmd 0x%08X Failed. Status: 0x%X\n",
> + WIRED_INITIATE_HDCP2_SESSION, 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);
> +
> static int mei_hdcp_probe(struct mei_cl_device *cldev,
> const struct mei_cl_device_id *id) { diff --git
> a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h index
> 9a869d1cbd5d..c333528b9c1e 100644
> --- a/include/linux/mei_hdcp.h
> +++ b/include/linux/mei_hdcp.h
> @@ -24,6 +24,7 @@
> #define _LINUX_MEI_HDCP_H
>
> #include
> +#include
>
> /*
> * Enumeration of the physical DDI available on the platform @@ -101,6
> +102,9 @@ int mei_hdcp_cldev_get_reference(void *client_data,
> struct mei_cl_device
> *cldev));
> void mei_hdcp_cldev_put_reference(struct mei_cl_device *cldev);
> +
> +int mei_initiate_hdcp2_session(struct mei_hdcp_data *data,
> +struct hdcp2_ake_init *ake_data);
> #else
> static inline
> int mei_hdcp_cldev_get_reference(void *client_data, @@ -114,5 +118,12
> @@ int mei_hdcp_cldev_get_reference(void *client_data, static inline void
> mei_hdcp_cldev_put_reference(struct mei_cl_device *cldev) {}
> +
> +static inline
> +int mei_initiate_hdcp2_session(struct mei_hdcp_da
RE: [PATCH v2 09/42] linux/mei: Header for mei_hdcp driver interface
> Data structures and Enum for the I915-MEI_HDCP interface are defined at
>
>
> v2:
> Rebased.
>
> Signed-off-by: Ramalingam C
> ---
> include/linux/mei_hdcp.h | 71
>
> 1 file changed, 71 insertions(+)
>
> diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h index
> 774b26da0c26..9a869d1cbd5d 100644
> --- a/include/linux/mei_hdcp.h
> +++ b/include/linux/mei_hdcp.h
> @@ -23,6 +23,77 @@
> #ifndef _LINUX_MEI_HDCP_H
> #define _LINUX_MEI_HDCP_H
Missing license.
>
> +#include
> +
> +/*
> + * Enumeration of the physical DDI available on the platform */ enum
> +physical_port {
If this is public header you need a proper prefix for types.
> + 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 {
> + struct mei_cl_device *cldev;
Not why this device is here?
+ enum 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_hdcp_cldev_get_reference(void *client_data,
>struct mei_cl_device **cldev,
> --
> 2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 5/6] drm/i915: Introduce 'priority offset' for GPU contexts (v2)
Quoting Chris Wilson (2018-03-08 11:32:04) > Quoting Matt Roper (2018-03-06 23:46:59) > > There are cases where a system integrator may wish to raise/lower the > > priority of GPU workloads being submitted by specific OS process(es), > > independently of how the software self-classifies its own priority. > > Exposing "priority offset" as an i915-specific cgroup parameter will > > enable such system-level configuration. > > > > Normally GPU contexts start with a priority value of 0 > > (I915_CONTEXT_DEFAULT_PRIORITY) and then may be adjusted up/down from > > there via other mechanisms. We'd like to provide a system-level input > > to the priority decision that will be taken into consideration, even > > when userspace later attempts to set an absolute priority value via > > I915_CONTEXT_PARAM_PRIORITY. The priority offset introduced here > > provides a base value that will always be added to (or subtracted from) > > the software's self-assigned priority value. > > > > This patch makes priority offset a cgroup-specific value; contexts will > > be created with a priority offset based on the cgroup membership of the > > process creating the context at the time the context is created. Note > > that priority offset is assigned at context creation time; migrating a > > process to a different cgroup or changing the offset associated with a > > cgroup will only affect new context creation and will not alter the > > behavior of existing contexts previously created by the process. > > > > v2: > > - Rebase onto new cgroup_priv API > > - Use current instead of drm_file->pid to determine which process to > >lookup priority for. (Chris) > > - Don't forget to subtract priority offset in context_getparam ioctl to > >make it match setparam behavior. (Chris) > > > > Signed-off-by: Matt Roper > > For ctx->priority/ctx->priority_offset > Reviewed-by: Chris Wilson As a reminder, we do have the question of how to bound ctx->priority + ctx->priority_offset. Currently, outside of the user range is privileged space reserved for the kernel (both above and below). Now we can move those even further to accommodate multiple non-overlapping cgroups. We also have the presumption that only privileged processes can raise a priority, but I presume the cgroup property itself is protected. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v2 07/42] misc/mei/hdcp: Get & Put for mei cl_device
> Interfaces to obtain and release the cl_device reference is developed.
> Using these interfaces intel hdcp driver will get the reference to the mei
> client devices, so that hdcp2.2 service calls can be routed to that client
> device.
>
> During registration, call back function will be registered with mei_hdcp
> driver
> so that when the client device is removed intel hdcp driver can be informed.
>
> At a time only one reference is allowed in this interfaces.
>
> v2:
> Rebased.
Linux kernel already provide notification chain, please use that.
This is not needed and I'm not sure it will ever work.
Tomas
> Signed-off-by: Ramalingam C
> ---
> drivers/misc/mei/hdcp/mei_hdcp.c | 55
> +++-
> drivers/misc/mei/hdcp/mei_hdcp.h | 9 +++
> include/linux/mei_hdcp.h | 47 ++
> 3 files changed, 110 insertions(+), 1 deletion(-) 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 25df7034cfb4..63f77800a6f7 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -55,18 +55,71 @@ static int mei_hdcp_probe(struct mei_cl_device
> *cldev,
> mei_cldev_set_drvdata(cldev, &mei_hdcp);
>
> ret = mei_cldev_enable(cldev);
> - if (ret < 0)
> + if (ret < 0) {
> dev_err(&cldev->dev, "mei_cldev_enable Failed. %d\n", ret);
> + goto err;
> + }
> +
> + if (mei_hdcp.notify_on_cldev_change)
> + mei_hdcp.notify_on_cldev_change(mei_hdcp.client, cldev);
> +
> + return 0;
> +err:
> + if (mei_hdcp.notify_on_cldev_change)
> + mei_hdcp.notify_on_cldev_change(mei_hdcp.client, NULL);
>
> return ret;
> }
>
> static int mei_hdcp_remove(struct mei_cl_device *cldev) {
> + struct mei_hdcp *mei_hdcp = mei_cldev_get_drvdata(cldev);
> +
> + if (mei_hdcp->notify_on_cldev_change)
> + mei_hdcp->notify_on_cldev_change(mei_hdcp->client, NULL);
> +
> mei_cldev_disable(cldev);
> +
> return 0;
> }
>
> +int mei_hdcp_cldev_get_reference(void *client_data,
> + struct mei_cl_device **cldev,
> + void (*notify_change)(void *client,
> +struct mei_cl_device
> +*cldev))
> +{
> + if (!notify_change || !client_data)
> + return -EINVAL;
> +
> + if (mei_hdcp.ref_cnt)
> + return -EBUSY;
> +
> + if (!mei_cldev_active_and_enabled(mei_hdcp.cldev)) {
> + if (!notify_change)
> + return -EAGAIN;
> + } else {
> + *cldev = mei_hdcp.cldev;
> + }
> +
> + mei_hdcp.ref_cnt++;
> + mei_hdcp.client = client_data;
> + mei_hdcp.notify_on_cldev_change = notify_change;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(mei_hdcp_cldev_get_reference);
> +
> +void mei_hdcp_cldev_put_reference(struct mei_cl_device *cldev) {
> + if (cldev == mei_hdcp.cldev) {
> + mei_hdcp.ref_cnt--;
> + mei_hdcp.client = NULL;
> + mei_hdcp.notify_on_cldev_change = NULL;
> + }
> +}
> +EXPORT_SYMBOL(mei_hdcp_cldev_put_reference);
> +
> #define WIDI_HECI_CLIENT_GUIDUUID_LE(0xB638AB7E, 0x94E2,
> 0x4EA2, 0xA5, \
> 0x52, 0xD1, 0xC5, 0x4B, \
> 0x62, 0x7F, 0x04)
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.h
> b/drivers/misc/mei/hdcp/mei_hdcp.h
> index c06c0d767c4f..7d792b5ad703 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.h
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.h
> @@ -27,6 +27,15 @@
>
> struct mei_hdcp {
> struct mei_cl_device *cldev;
> +
> + /* Reference to the HDCP2.2 service consumer */
> + void *client;
> +
> + /* Callback function for the consumer on cl_device state change */
> + void (*notify_on_cldev_change)(void *client,
> + struct mei_cl_device *cldev);
> +
> + int ref_cnt;
> };
>
> #endif /* __MEI_HDCP_H__ */
> diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h new file
> mode 100644 index ..774b26da0c26
> --- /dev/null
> +++ b/include/linux/mei_hdcp.h
> @@ -0,0 +1,47 @@
> +/*
> + * Copyright (c) 2017 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
> + * a
RE: [PATCH v2 04/42] misc/mei/hdcp: Client driver for HDCP application
> Subject: [PATCH v2 04/42] misc/mei/hdcp: Client driver for HDCP application
I prefer this will be squashed together with [PATCH v2 05/42] misc/mei/hdcp:
Add KBuild for mei hdcp driver
so it can be compiled.
>
> ME FW is contributes a vital role in HDCP2.2 authentication.
> HDCP2.2 driver needs to communicate to ME FW for each step of the
> HDCP2.2 authentication.
>
> ME FW prepare and HDCP2.2 authentication parameters and encrypt them
> as per spec. With such parameter Driver prepares HDCP2.2 auth messages
> and communicate with HDCP2.2 sink.
>
> Similarly HDCP2. sink's response is shared with ME FW for decrypt and
> verification.
>
> Once All the steps of HDCP2.2 authentications are complete on driver's
> request ME FW will configure the port as authenticated and supply the HDCP
> keys to the Gen HW for encryption.
>
> Only after this stage HDCP2.2 driver can start the HDCP2.2 encryption for a
> port.
>
> ME FW is interfaced to kernel through MEI Bus Driver. To obtain the
> HDCP2.2 services from the ME FW through MEI Bus driver MEI Client Driver is
> developed.
>
> v2:
> hdcp files are moved to drivers/misc/mei/hdcp/ [Tomas]
>
> Signed-off-by: Ramalingam C
> Signed-off-by: Tomas Winkler
> ---
> drivers/misc/mei/hdcp/mei_hdcp.c | 80
>
> drivers/misc/mei/hdcp/mei_hdcp.h | 32
> 2 files changed, 112 insertions(+)
> create mode 100644 drivers/misc/mei/hdcp/mei_hdcp.c create mode
> 100644 drivers/misc/mei/hdcp/mei_hdcp.h
>
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> new file mode 100644
> index ..aa211763e520
> --- /dev/null
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -0,0 +1,80 @@
> +/*
> + * Copyright © 2017 Intel Corporation
Please use SPDX notation, for HECI devices we force dual license
/* SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) */
/*
* Copyright © 2017-2018 Intel Corporation
*/
> + *
> + * Mei_hdcp.c: client driver for mei bus driver
> + *
> + * Permission is hereby granted, free of charge, to any person
> +obtaining a
> + * copy of this software and associated documentation files (the
> +"Software"),
> + * to deal in the Software without restriction, including without
> +limitation
> + * the rights to use, copy, modify, merge, publish, distribute,
> +sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom
> +the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the
> +next
> + * paragraph) shall be included in all copies or substantial portions
> +of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> +EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> +MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO
> EVENT
> +SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
> DAMAGES OR
> +OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> +ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> OTHER
> + * DEALINGS IN THE SOFTWARE.
> + *
> + * Authors:
> + * Ramalingam C
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include "mei_hdcp.h"
> +
> +struct mei_hdcp mei_hdcp;
> +
> +static int mei_hdcp_probe(struct mei_cl_device *cldev,
> + const struct mei_cl_device_id *id) {
> + int ret;
> +
> + mei_hdcp.cldev = cldev;
> + mei_cldev_set_drvdata(cldev, &mei_hdcp);
> +
> + ret = mei_cldev_enable(cldev);
> + if (ret < 0)
> + dev_err(&cldev->dev, "mei_cldev_enable Failed. %d\n", ret);
> +
> + return ret;
> +}
> +
> +static int mei_hdcp_remove(struct mei_cl_device *cldev) {
mei_cldev_set_drvdata(cldev, NULL);
> + mei_cldev_disable(cldev);
return mei_cldev_disable(cldev);
> + return 0;
> +}
> +
> +#define WIDI_HECI_CLIENT_GUIDUUID_LE(0xB638AB7E, 0x94E2,
> 0x4EA2, 0xA5, \
> + 0x52, 0xD1, 0xC5, 0x4B, \
> + 0x62, 0x7F, 0x04)
> +#define MEI_HDCP2_2_UUID WIDI_HECI_CLIENT_GUID
Please use the same string as defined in whitelist patch
> +
> +static struct mei_cl_device_id mei_hdcp_tbl[] = {
> + { .uuid = MEI_HDCP2_2_UUID, .version = MEI_CL_VERSION_ANY },
> + { }
> +};
> +MODULE_DEVICE_TABLE(mei, mei_hdcp_tbl);
> +
> +static struct mei_cl_driver mei_hdcp_driver = {
> + .id_table = mei_hdcp_tbl,
> + .name = KBUILD_MODNAME,
> + .probe = mei_hdcp_probe,
> + .remove = mei_hdcp_remove,
> +};
> +
> +module_mei_cl_driver(mei_hdcp_driver);
> +
> +MODULE_AUTHOR("Intel Corporation");
> +MODULE_LICENSE("GPL");
Dual License
> +MODULE_DESCRIPTION("HDCP");
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.h
> b/drivers/misc/mei/hdcp/mei_hdcp.h
> new file mode 100644
>
RE: [PATCH v2 06/42] misc/mei/hdcp: Verify mei client device status
>
> v2:
> Rebased.
>
> Signed-off-by: Ramalingam C
> ---
> drivers/misc/mei/hdcp/mei_hdcp.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index aa211763e520..25df7034cfb4 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -34,6 +34,18 @@
>
> struct mei_hdcp mei_hdcp;
>
> +/**
> + * mei_cldev_active_and_enabled:
> + * Return: true if me client for HDCP is initialized and connected
> + */
> +static inline bool mei_cldev_active_and_enabled(struct mei_cl_device
> +*cldev) {
> + if (!cldev)
> + return false;
> +
> + return mei_cldev_enabled(cldev);
> +}
>
I think this is a useless wrapper, if you needed it there is something wrong
with your code.
Please drop this patch, if needed open code it.
Tomas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103953] [DC] Polaris10: Missing modes when enabling DC
https://bugs.freedesktop.org/show_bug.cgi?id=103953 --- Comment #11 from Aleksei --- I'm losing refresh rates higher than 60Hz with dc=1 on 4.15.6 kernel - is that fixed too? Monitor 1920x1080 144Hz, GPU RX 560, connection over DVI-D. With dc=0 I can set 1920x1080 144Hz, with dc=1 only 1920x1080 60Hz. -- 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 00/42] drm/i915: Implement HDCP2.2
On Thursday 08 March 2018 06:00 PM, Winkler, Tomas wrote: -Original Message- From: C, Ramalingam Sent: Thursday, March 08, 2018 13:58 To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; seanp...@chromium.org; ch...@chris-wilson.co.uk; Winkler, Tomas ; jani.nik...@linux.intel.com Cc: Vivi, Rodrigo ; Sharma, Shashank ; Shankar, Uma ; C, Ramalingam Subject: [PATCH v2 00/42] drm/i915: Implement HDCP2.2 Based on HDCP1.4 framework introduced by Sean Paul, this series implements the HDCP2.2 in I915. I didn't see HDCP 1.4 framework being merged upstream? What tree is this based on? This is based on drm-tip branch of https://cgit.freedesktop.org/drm-tip/ --Ram Thanks Tomas 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v2 00/42] drm/i915: Implement HDCP2.2
> -Original Message- > From: C, Ramalingam > Sent: Thursday, March 08, 2018 13:58 > To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; > seanp...@chromium.org; ch...@chris-wilson.co.uk; Winkler, Tomas > ; jani.nik...@linux.intel.com > Cc: Vivi, Rodrigo ; Sharma, Shashank > ; Shankar, Uma ; C, > Ramalingam > Subject: [PATCH v2 00/42] drm/i915: Implement HDCP2.2 > > Based on HDCP1.4 framework introduced by Sean Paul, this series > implements the HDCP2.2 in I915. I didn't see HDCP 1.4 framework being merged upstream? What tree is this based on? Thanks Tomas > 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 42/42] 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.
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 12f6aca947b6..f6da323fe2fc 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 v2 40/42] 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.
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 41d2505a964b..12f6aca947b6 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,
+ hdcp->is_paire
[PATCH v2 41/42] 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.
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 248fd570fc0f..1b3e56783b93 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -6771,7 +6771,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 e931877deb69..a76ad5b421bd 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1929,6 +1929,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 16144ae1bbac..84a0a3cf4f10 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -1735,7 +1735,6 @@ void intel_mei_cldev_reference_notify(void *client,
drm_connector_list_iter_end(&conn_iter);
}
-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
[PATCH v2 35/42] 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.
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 1f3b0db0b70d..152cb1eebd90 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -785,7 +785,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 v2 39/42] 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.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_dp.c | 350 ++
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_hdcp.c | 3 +
3 files changed, 354 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 5d0699538e7a..248fd570fc0f 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
@@ -5085,6 +5086,26 @@ void intel_dp_encoder_suspend(struct intel_encoder
*intel_encoder)
pps_unlock(intel_dp);
}
+static int intel_dp_hdcp_wait_for_cp_irq(struct completion *cp_irq_recved,
+int timeout)
+{
+ long ret;
+
+ if (completion_done(cp_irq_recved))
+ reinit_completion(cp_irq_recved);
+
+ ret = wait_for_completion_interruptible_timeout(cp_irq_recved,
+ msecs_to_jiffies(
+ timeout));
+ reinit_completion(cp_irq_recved);
+ if (ret < 0)
+ return (int)ret;
+ else if (!ret)
+ return -ETIMEDOUT;
+ return 0;
+}
+
+
static
int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
u8 *an)
@@ -5301,6 +5322,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_2_2_HPRIME_NO_PAIRED_TIMEOUT;
+
[PATCH v2 38/42] 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 Change.
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 0e35e24948a3..6991ba72b18b 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 08dafd7e9278..bc5aecd1cbcc 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3114,6 +3114,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
@@ -3141,8 +3142,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;
unsigned int rx_
[PATCH v2 36/42] drm/i915: hdcp_check_link only on CP_IRQ
HDCP check link is invoked only on CP_IRQ detection, instead of all
short pulses.
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 42f3b3331e90..2fce0d6329a5 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4470,8 +4470,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");
}
intel_dp_check_link_status(intel_dp);
@@ -5478,9 +5480,6 @@ intel_dp_hpd_pulse(struct intel_digital_port
*intel_dig_port, bool long_hpd)
drm_modeset_acquire_fini(&ctx);
WARN(iret, "Acquiring modeset locks failed with %i\n", iret);
- /* 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 v2 37/42] 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.
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 2fce0d6329a5..5d0699538e7a 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4471,7 +4471,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 b431e7027bc9..17e6c054e171 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1926,8 +1926,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 152cb1eebd90..336116032ff7 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -31,6 +31,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)
@@ -78,6 +79,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)
{
@@ -857,7 +878,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;
@@ -1753,3 +1774,11 @@ static int intel_hdcp2_init(struct intel_connector
*connector)
hdcp->hdcp2_supported = true;
return 0;
}
+
+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 v2 33/42] 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.
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 2265121e1102..0642c14126a1 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -626,7 +626,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);
@@ -634,7 +634,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;
}
@@ -729,8 +734,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 v2 34/42] 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.
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 0642c14126a1..1f3b0db0b70d 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -26,6 +26,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)
@@ -721,20 +772,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;
}
@@ -751,10 +809,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 v2 29/42] 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.
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 41915d626d20..2bc952b828b2 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 check_link_respon
[PATCH v2 30/42] 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.
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 2bc952b828b2..a5e4678e54bc 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 v2 31/42] 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.
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 a5e4678e54bc..2cb50db3b063 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 v2 32/42] drm/i915: Initialize HDCP2.2 and its MEI interface
Initialize HDCP2.2 support. This includes the mei interface
initialization also.
v2:
mei interface handle is protected with mutex. [Chris Wilson]
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 7 +++
drivers/gpu/drm/i915/intel_dp.c | 3 +-
drivers/gpu/drm/i915/intel_drv.h | 3 +-
drivers/gpu/drm/i915/intel_hdcp.c | 123 +-
drivers/gpu/drm/i915/intel_hdmi.c | 2 +-
6 files changed, 135 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index aaa861b51024..d178b3ec0a60 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -917,6 +917,7 @@ static int i915_driver_init_early(struct drm_i915_private
*dev_priv,
mutex_init(&dev_priv->av_mutex);
mutex_init(&dev_priv->wm.wm_mutex);
mutex_init(&dev_priv->pps_mutex);
+ mutex_init(&dev_priv->mei_interface_mutex);
intel_uc_init_early(dev_priv);
i915_memcpy_init_early(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 82a106b1bdbc..0e35e24948a3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1815,6 +1815,8 @@ struct intel_cdclk_state {
u8 voltage_level;
};
+struct mei_cl_device;
+
struct drm_i915_private {
struct drm_device drm;
@@ -2375,6 +2377,11 @@ struct drm_i915_private {
struct i915_pmu pmu;
+ /* MEI Interface for HDCP2.2 */
+ struct mei_cl_device *mei_cldev;
+ bool mei_init_deferred;
+ struct mutex mei_interface_mutex;
+
/*
* NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
* will be rejected. Instead look for a better place.
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 2c3eb90b9499..42f3b3331e90 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -6421,7 +6421,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 67f507bb4d0d..b431e7027bc9 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1922,7 +1922,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 2cb50db3b063..2265121e1102 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -25,6 +25,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 +687,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 +704,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);
[PATCH v2 27/42] 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]
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 53314f8e491a..38cecf533cb9 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -19,6 +19,7 @@
(enum 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 v2 28/42] drm/i915: Implement HDCP2.2 En/Dis-able
Implements a sequence of enabling and disabling the HDCP2.2
(auth and encryption).
v2:
Rebased.
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 38cecf533cb9..41915d626d20 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 v2 26/42] 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.
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 6fb9fd4d6e1c..53314f8e491a 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(connector);
+ if
[PATCH v2 25/42] 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.
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 8e4d281613f0..6fb9fd4d6e1c 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 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;
+ } msgs;
+ const st
[PATCH v2 24/42] drm/i915: Wrappers for mei HDCP2.2 services
Adds the wrapper for all mei hdcp2.2 service functions.
v2:
Rebased.
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..8e4d281613f0 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 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 (!data->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(data);
+
+ return mei_initiate_hdcp2_session(data, ake_data);
+}
+
+static int hdcp2_close_mei_session(struct intel_hdcp *hdcp)
+{
+ struct mei_hdcp_data *data = &hdcp->mei_data;
+
+ if (!data->cldev || data->port == INVALID_PORT)
+ return -EINVAL;
+
+ return mei_close_hdcp_session(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 (!data->cldev)
+ return -EINVAL;
+
+ ret = mei_verify_receiver_cert_prepare_km(data, rx_cert, paired,
+ ek_pub_km, msg_sz);
+ if (ret < 0)
+ mei_close_hdcp_session(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 (!data->cldev)
+ return -EINVAL;
+
+ ret = mei_verify_hprime(data, rx_hprime);
+ if (ret < 0)
+ mei_close_hdcp_session(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 (!data->cldev)
+ return -EINVAL;
+
+ ret = mei_store_pairing_info(data, pairing_info);
+ if (ret < 0)
+ mei_close_hdcp_session(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 (!data->cldev)
+ return -EINVAL;
+
+ ret = mei_initiate_locality_check(data, lc_init);
+ if (ret < 0)
+ mei_close_hdcp_session(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 (!data->cldev)
+ return -EINVAL;
+
+ ret = mei_verify_lprime(data, rx_lprime);
+ if (ret < 0)
+ mei_close_hdcp_session(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 (!data->cldev)
+ return -EINVAL;
+
+ ret = mei_get_session_key(data, ske_data);
+ if (ret < 0)
+ mei_close_hdcp_session(data);
+
+ return ret;
+}
+
+static int
+hdcp2_verify_rep_topology_prepare_ack(
+ struct intel_hdcp *hdcp,
+ struct hdcp2_rep_send_receiverid_list *rep_topology,
+ struct hdcp2_rep_send_ack *rep_send_ack)
+{
+ struct mei_hdcp_data *data = &hdcp->mei_data;
+ int ret;
+
+ if (!data->cldev)
+ return -EI
[PATCH v2 23/42] 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]
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 eea5b2c537d4..08dafd7e9278 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8605,6 +8605,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 v2 21/42] 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]
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 65c8487be7c7..197639f39765 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15396,9 +15396,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 8f38e584d375..1b2560ec52ab 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -376,6 +376,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;
/*
@@ -408,11 +416,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 v2 20/42] 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.
Signed-off-by: Ramalingam C
---
drivers/misc/mei/hdcp/mei_hdcp.c | 63
include/linux/mei_hdcp.h | 5
2 files changed, 68 insertions(+)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index c73715ba9693..e237ddb44b9d 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -765,6 +765,69 @@ int mei_enable_hdcp_authentication(struct mei_hdcp_data
*data)
}
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_hdcp_data *data)
+{
+ struct wired_cmd_close_session_in session_close_in = { { 0 } };
+ struct wired_cmd_close_session_out session_close_out = { { 0 } };
+ enum me_hdcp_status status;
+ struct device *dev;
+ ssize_t byte;
+
+ if (!data)
+ return -EINVAL;
+
+ /* check for the mei_device enabled or not */
+ if (!mei_cldev_active_and_enabled(data->cldev))
+ return -ENODEV;
+
+ dev = &data->cldev->dev;
+
+ /* Fill header details */
+ 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;
+
+ /* Fill in the In Data */
+ session_close_in.port.integrated_port_type = data->port_type;
+ session_close_in.port.physical_port = data->port;
+
+
+ /* Request to ME */
+ byte = mei_cldev_send(data->cldev, (u8 *)&session_close_in,
+ sizeof(session_close_in));
+ if (byte < 0) {
+ dev_err(dev, "mei_cldev_send failed. %d\n", (int)byte);
+ return byte;
+ }
+
+ /* Response from ME */
+ byte = mei_cldev_recv(data->cldev, (u8 *)&session_close_out,
+ sizeof(session_close_out));
+ if (byte < 0) {
+ dev_err(dev, "mei_cldev_recv failed. %d\n", (int)byte);
+ return byte;
+ }
+
+ status = (enum me_hdcp_status)session_close_out.header.status;
+ if (status != ME_HDCP_STATUS_SUCCESS) {
+ dev_err(dev, "Session Close Failed. status: 0x%X\n", status);
+ return -1;
+ }
+ return 0;
+}
+EXPORT_SYMBOL(mei_close_hdcp_session);
+
static int mei_hdcp_probe(struct mei_cl_device *cldev,
const struct mei_cl_device_id *id)
{
diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h
index cb8bf3b0f022..031251a1424a 100644
--- a/include/linux/mei_hdcp.h
+++ b/include/linux/mei_hdcp.h
@@ -129,6 +129,7 @@ mei_repeater_check_flow_prepare_ack(struct mei_hdcp_data
*data,
int mei_verify_mprime(struct mei_hdcp_data *data,
struct hdcp2_rep_stream_ready *stream_ready);
int mei_enable_hdcp_authentication(struct mei_hdcp_data *data);
+int mei_close_hdcp_session(struct mei_hdcp_data *data);
#else
static inline
int mei_hdcp_cldev_get_reference(void *client_data,
@@ -206,5 +207,9 @@ static inline int mei_enable_hdcp_authentication(struct
mei_hdcp_data *data)
{
return -ENODEV;
}
+static inline int mei_close_hdcp_session(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 v2 22/42] 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]
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_drv.h | 60
1 file changed, 60 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 1b2560ec52ab..67f507bb4d0d 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
@@ -374,6 +375,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 {
@@ -382,6 +409,39 @@ 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_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 v2 19/42] 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.
Signed-off-by: Ramalingam C
---
drivers/misc/mei/hdcp/mei_hdcp.c | 61
include/linux/mei_hdcp.h | 5
2 files changed, 66 insertions(+)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 0e70213cded8..c73715ba9693 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -704,6 +704,67 @@ int mei_verify_mprime(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.
+ *
+ * @data : Intel HW specific Data
+ *
+ * Returns 0 on Success, <0 on Failure
+ */
+int mei_enable_hdcp_authentication(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 } };
+ enum me_hdcp_status status;
+ struct device *dev;
+ ssize_t byte;
+
+ if (!data)
+ return -EINVAL;
+
+ if (!mei_cldev_active_and_enabled(data->cldev))
+ return -ENODEV;
+
+ dev = &data->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;
+
+ /* Fill in the In Data */
+ 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;
+
+ /* Request to ME */
+ byte = mei_cldev_send(data->cldev, (u8 *)&enable_auth_in,
+ sizeof(enable_auth_in));
+ if (byte < 0) {
+ dev_err(dev, "mei_cldev_send failed. %d\n", (int)byte);
+ return byte;
+ }
+
+ /* Response from ME */
+ byte = mei_cldev_recv(data->cldev, (u8 *)&enable_auth_out,
+ sizeof(enable_auth_out));
+ if (byte < 0) {
+ dev_err(dev, "mei_cldev_recv failed. %d\n", (int)byte);
+ return byte;
+ }
+
+ status = (enum me_hdcp_status)enable_auth_out.header.status;
+ if (status != ME_HDCP_STATUS_SUCCESS) {
+ dev_err(dev, "ME cmd 0x%08X failed. status: 0x%X\n",
+ WIRED_ENABLE_AUTH, status);
+ return -1;
+ }
+ return 0;
+}
+EXPORT_SYMBOL(mei_enable_hdcp_authentication);
+
static int mei_hdcp_probe(struct mei_cl_device *cldev,
const struct mei_cl_device_id *id)
{
diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h
index 560fc62b2b41..cb8bf3b0f022 100644
--- a/include/linux/mei_hdcp.h
+++ b/include/linux/mei_hdcp.h
@@ -128,6 +128,7 @@ mei_repeater_check_flow_prepare_ack(struct mei_hdcp_data
*data,
struct hdcp2_rep_send_ack *rep_send_ack);
int mei_verify_mprime(struct mei_hdcp_data *data,
struct hdcp2_rep_stream_ready *stream_ready);
+int mei_enable_hdcp_authentication(struct mei_hdcp_data *data);
#else
static inline
int mei_hdcp_cldev_get_reference(void *client_data,
@@ -201,5 +202,9 @@ int mei_verify_mprime(struct mei_hdcp_data *data,
{
return -ENODEV;
}
+static inline int mei_enable_hdcp_authentication(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 v2 18/42] 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.
Signed-off-by: Ramalingam C
---
drivers/misc/mei/hdcp/mei_hdcp.c | 85
include/linux/mei_hdcp.h | 8
2 files changed, 93 insertions(+)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 02c90770dcb6..0e70213cded8 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -619,6 +619,91 @@ mei_repeater_check_flow_prepare_ack(struct mei_hdcp_data
*data,
}
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.
+ *
+ * @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_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 } };
+ enum me_hdcp_status status;
+ struct device *dev;
+ ssize_t byte;
+
+ if (!stream_ready || !data)
+ return -EINVAL;
+
+ /* check for the mei_device enabled or not */
+ if (!mei_cldev_active_and_enabled(data->cldev))
+ return -ENODEV;
+
+ dev = &data->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);
+
+ /* Request to ME */
+ byte = mei_cldev_send(data->cldev, (u8 *)&verify_mprime_in,
+ sizeof(verify_mprime_in));
+ if (byte < 0) {
+ dev_err(dev, "mei_cldev_send failed. %d\n", (int)byte);
+ return byte;
+ }
+
+ /* Response from ME */
+ byte = mei_cldev_recv(data->cldev, (u8 *)&verify_mprime_out,
+ sizeof(verify_mprime_out));
+ if (byte < 0) {
+ dev_err(dev, "mei_cldev_recv failed. %d\n", (int)byte);
+ return byte;
+ }
+
+ status = (enum me_hdcp_status)verify_mprime_out.header.status;
+ if (status != ME_HDCP_STATUS_SUCCESS) {
+ dev_err(dev, "ME cmd 0x%08X failed. status: 0x%X\n",
+ WIRED_REPEATER_AUTH_STREAM_REQ, status);
+ return -1;
+ }
+ return 0;
+}
+EXPORT_SYMBOL(mei_verify_mprime);
+
static int mei_hdcp_probe(struct mei_cl_device *cldev,
const struct mei_cl_device_id *id)
{
diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h
index c8f6fc90f475..560fc62b2b41 100644
--- a/include/linux/mei_hdcp.h
+++ b/include/linux/mei_hdcp.h
@@ -126,6 +126,8 @@ mei_repeater_check_flow_prepare_ack(struct mei_hdcp_data
*data,
struct hdcp2_rep_send_receiverid_list
*rep_topology,
struct hdcp2_rep_send_ack *rep_send_ack);
+int mei_verify_mprime(struct mei_hdcp_data *data,
+ struct hdcp2_rep_stream_ready *stream_ready);
#else
static inline
int mei_hdcp_cldev_get_reference(void *client_data,
@@ -193,5 +195,11 @@ mei_repeater_check_flow_prepare_ack(struct mei_hdcp_data
*data,
{
return -ENODEV;
}
+static inline
+int mei_verify_mprime(struct mei_hdcp_data *data,
+ struct hdcp2_rep_stream_ready *stream_ready)
+{
+ return -EN
