date:20180308

https://bugs.freedesktop.org/show_bug.cgi?id=105302

--- Comment #6 from Andrew Sheldon  ---
(In reply to Alex Deucher from comment #5)
> I'd rather not support running things out of spec in the driver.  The source
> is open.  If you want to adjust the code allow something like that you can.

Fair enough, it's simple enough to patch the source for a higher limit.

-- 
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 28433] Mesa DRI Intel 845G GEM Drivers returning artifacts in textures that can lockup PC on glxSwapBuffers.

https://bugs.freedesktop.org/show_bug.cgi?id=28433

--- Comment #4 from Gert Wollny  ---
I can't see any artefacts on i915 with GM45. In fact there the rendering looks
better then with the llvmpipe software renderer and r600. These two create
over-bright pixels that are not present with i915.

Versions tested: 
- i915 and llvmpipe: Mesa 13.0.6
- r600 and llvmpipe: Mesa 18.1.0-devel (git-dcd8730445

-- 
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 103234] KWin crashed when Alt+Tab-ing through open windows

https://bugs.freedesktop.org/show_bug.cgi?id=103234

--- Comment #16 from Roman Gilg  ---
I can't reproduce the issue currently. What is weird, since it didn't work for
months.

Maybe it's working now again because I deleted the $HOME/.cache content?

Could someone with the same problem do the same to see if it works afterwards
as well for him again?

-- 
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

2018-03-08 Thread Jani Nikula

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.

BR,
Jani.

>
> Fixes: 35fe703c3161 ("drm/i915/guc: Change values for i915_guc_log_control")
> Cc: Michal Wajdeczko 
> Cc: Sagar Arun Kamble 
> Cc: Daniele Ceraolo Spurio 
> Cc: Tvrtko Ursulin 
> Cc: Joonas Lahtinen 
> Cc: Chris Wilson 
> Signed-off-by: Andrew Morton 
> ---
>
>  drivers/gpu/drm/i915/intel_guc_log.c |6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff -puN 
> drivers/gpu/drm/i915/intel_guc_log.c~drivers-gpu-drm-i915-intel_guc_logc-work-around-gcc-444-union-initializer-issue
>  drivers/gpu/drm/i915/intel_guc_log.c
> --- 
> a/drivers/gpu/drm/i915/intel_guc_log.c~drivers-gpu-drm-i915-intel_guc_logc-work-around-gcc-444-union-initializer-issue
> +++ a/drivers/gpu/drm/i915/intel_guc_log.c
> @@ -61,8 +61,10 @@ static int guc_log_flush(struct intel_gu
>  static int guc_log_control(struct intel_guc *guc, bool enable, u32 verbosity)
>  {
>   union guc_log_control control_val = {
> - .logging_enabled = enable,
> - .verbosity = verbosity,
> + {
> + .logging_enabled = enable,
> + .verbosity = verbosity,
> + },
>   };
>   u32 action[] = {
>   INTEL_GUC_ACTION_UK_LOG_ENABLE_LOGGING,
> _
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC][PATCH 1/2] drm_hwcomposer: Error out on YUV layer as it would fail for single planes

2018-03-08 Thread Robert Foss


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.


  default:
ALOGE("Cannot convert hal format to drm format %u", hal_format);
return -EINVAL;
@@ -88,10 +86,15 @@ EGLImageKHR DrmGenericImporter::ImportImage(EGLDisplay 
egl_display, buffer_handl
gralloc_drm_handle_t *gr_handle = gralloc_drm_handle(handle);
if (!gr_handle)
  return NULL;
+
+  EGLint fmt = ConvertHalFormatToDrm(gr_handle->format);
+  if (fmt < 0)
+   return NULL;
+
EGLint attr[] = {
  EGL_WIDTH, gr_handle->width,
  EGL_HEIGHT, gr_handle->height,
-EGL_LINUX_DRM_FOURCC_EXT, (EGLint)ConvertHalFormatToDrm(gr_handle->format),
+EGL_LINUX_DRM_FOURCC_EXT, fmt,
  EGL_DMA_BUF_PLANE0_FD_EXT, gr_handle->prime_fd,
  EGL_DMA_BUF_PLANE0_OFFSET_EXT, 0,
  EGL_DMA_BUF_PLANE0_PITCH_EXT, gr_handle->stride,
@@ -112,10 +115,14 @@ int DrmGenericImporter::ImportBuffer(buffer_handle_t 
handle, hwc_drm_bo_t *bo) {
  return ret;
}
  
+  uint32_t  fmt = ConvertHalFormatToDrm(gr_handle->format);

+  if (fmt < 0)
+return fmt;
+
memset(bo, 0, sizeof(hwc_drm_bo_t));
bo->width = gr_handle->width;
bo->height = gr_handle->height;
-  bo->format = ConvertHalFormatToDrm(gr_handle->format);
+  bo->format = fmt;
bo->usage = gr_handle->usage;
bo->pitches[0] = gr_handle->stride;
bo->gem_handles[0] = gem_handle;


___
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

2018-03-08 Thread Robert Foss


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"



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 
---
v2:
* Make platformhisi and the generic importer exclusive in the
   build
* Fixup vendor check
v3:
* Unify format conversions
* Subclass the platformdrmgeneric importer implementation to
   reduce code duplication
* Rework to avoid board specific logic (tweak gralloc to be
   consistent between the two)
v4:
* Minor cleanups as suggested by Alexandru-Cosmin Gheorghe
---
  Android.mk   |  13 +
  platformdrmgeneric.h |   2 +-
  platformhisi.cpp | 135 +++
  platformhisi.h   |  48 ++
  4 files changed, 197 insertions(+), 1 deletion(-)
  create mode 100644 platformhisi.cpp
  create mode 100644 platformhisi.h

diff --git a/Android.mk b/Android.mk
index ee5b8bf..f37e4c3 100644
--- a/Android.mk
+++ b/Android.mk
@@ -74,7 +74,20 @@ LOCAL_CPPFLAGS += \
-DHWC2_USE_CPP11 \
-DHWC2_INCLUDE_STRINGIFICATION
  
+

+ifeq ($(TARGET_PRODUCT),hikey960)
+LOCAL_CPPFLAGS += -DUSE_HISI_IMPORTER
+LOCAL_SRC_FILES += platformhisi.cpp
+LOCAL_C_INCLUDES += device/linaro/hikey/gralloc960/
+else
+ifeq ($(TARGET_PRODUCT),hikey)
+LOCAL_CPPFLAGS += -DUSE_HISI_IMPORTER
+LOCAL_SRC_FILES += platformhisi.cpp
+LOCAL_C_INCLUDES += device/linaro/hikey/gralloc/
+else
  LOCAL_CPPFLAGS += -DUSE_DRM_GENERIC_IMPORTER
+endif
+endif
  
  LOCAL_MODULE := hwcomposer.drm

  LOCAL_MODULE_TAGS := optional
diff --git a/platformdrmgeneric.h b/platformdrmgeneric.h
index 8376580..fbe059b 100644
--- a/platformdrmgeneric.h
+++ b/platformdrmgeneric.h
@@ -35,8 +35,8 @@ class DrmGenericImporter : public Importer {
int ImportBuffer(buffer_handle_t handle, hwc_drm_bo_t *bo) override;
int ReleaseBuffer(hwc_drm_bo_t *bo) override;
  
- private:

uint32_t ConvertHalFormatToDrm(uint32_t hal_format);
+ private:
  
DrmResources *drm_;
  
diff --git a/platformhisi.cpp b/platformhisi.cpp

new file mode 100644
index 000..16c5e6f
--- /dev/null
+++ b/platformhisi.cpp
@@ -0,0 +1,135 @@
+/*
+ * Copyright (C) 2015 The Android Open Source Project
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#define LOG_TAG "hwc-platform-hisi"
+
+#include "drmresources.h"
+#include "platform.h"
+#include "platformhisi.h"
+
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include "gralloc_priv.h"
+
+
+namespace android {
+
+Importer *Importer::CreateInstance(DrmResources *drm) {
+  HisiImporter *importer = new HisiImporter(drm);
+  if (!importer)
+return NULL;
+
+  int ret = importer->Init();
+  if (ret) {
+ALOGE("Failed to initialize the hisi importer %d", ret);
+delete importer;
+return NULL;
+  }
+  return importer;
+}
+
+HisiImporter::HisiImporter(DrmResources *drm) : DrmGenericImporter(drm), 
drm_(drm) {
+}
+
+HisiImporter::~HisiImporter() {
+}
+
+int HisiImporter::Init() {
+  int ret = hw_get_module(GRALLOC_HARDWARE_MODULE_ID,
+  (const hw_module_t **)&gralloc_);
+  if (ret) {
+ALOGE("Failed to open gralloc module %d", ret);
+return ret;
+  }
+
+  if (strcasecmp(gralloc_->common.author, "ARM Ltd."))
+ALOGW("Using non-ARM gralloc module: %s/%s\n", gralloc_->common.name,
+  gralloc_->common.author);
+
+  return 0;
+}
+
+EGLImageKHR HisiImporter::ImportImage(EGLDisplay egl_display, buffer_handle_t 
handle) {
+  private_handle_t const *hnd = reinterpret_cast < private_handle_t const 
*>(handle);
+  if (!hnd)
+return NULL;
+
+  EGLint fmt = ConvertHalFormatToDrm(hnd->req_format);
+  if (fmt < 0)
+   return NULL;
+
+  EGLint attr[] = {
+EGL_WIDTH, hnd->width,
+EGL_HEIGHT, hnd->height,
+EGL_LINUX_DRM_FOURCC_EXT, fmt,
+EGL_DMA_BUF_PLANE0_FD_EXT, hnd->share_fd,
+EGL_DMA_BUF_PLANE0_OFFSET_EXT, 0,
+EGL_DMA_BUF_PLANE0_PITCH_EXT, hnd->byte_stride,
+EGL_NONE,
+  };
+  return eglCreateImageKHR(egl_display, EGL_NO_CONTEXT, EGL_LINUX_DMA_BUF_EXT, 
NULL, attr);
+}
+
+int HisiImporter::ImportBuffer(buffer_handle_t handle, hwc_drm_bo_t *b

Re: [PATCH] dt-bindings: exynos: Document #sound-dai-cells property of the HDMI node

2018-03-08 Thread 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 
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.

Actually I have forgotten to add also exynos5250 to the list.

-- 
Regards,
Sylwester
___
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-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 

At the end of the day, everything that is modifiable by context is going
to want cgroup constraint, but like priority_offset each will require
some thought as to how to express the constraint.

Interesting conundrum, and still we want a consistent interface for all
the gpus on a system.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] video: fbdev: via_aux_vt1632: remove VLA usage

Hi Gustavo,

On 7 March 2018 at 19:54, Gustavo A. R. Silva  wrote:
> In preparation to enabling -Wvla, remove VLA and replace it
> with a fixed-length array instead. Also, remove variable 'len'.
>
What is the reason behind adding -Wvla? Is there a thread some that I
can read up on?

> Notice that no new IDs have been added in seven years.
>
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/video/fbdev/via/via_aux_vt1632.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/fbdev/via/via_aux_vt1632.c 
> b/drivers/video/fbdev/via/via_aux_vt1632.c
> index d24f4cd..0cd0d2a 100644
> --- a/drivers/video/fbdev/via/via_aux_vt1632.c
> +++ b/drivers/video/fbdev/via/via_aux_vt1632.c
> @@ -35,10 +35,10 @@ static void probe(struct via_aux_bus *bus, u8 addr)
> .addr   =   addr,
> .name   =   name};
> /* check vendor id and device id */
> -   const u8 id[] = {0x06, 0x11, 0x92, 0x31}, len = ARRAY_SIZE(id);
> -   u8 tmp[len];
> +   const u8 id[4] = {0x06, 0x11, 0x92, 0x31};
> +   u8 tmp[4];
>
> -   if (!via_aux_read(&drv, 0x00, tmp, len) || memcmp(id, tmp, len))
> +   if (!via_aux_read(&drv, 0x00, tmp, 4) || memcmp(id, tmp, 4))

Generally, hard coding a bunch of numbers like that makes for
confusing and fragile code.

A lot simpler and more obvious solution is like the following.
It silences the compiler warning (-Wvla - pedantic) you while keeping
the original clarity.

const u8 id[] = {0x06, 0x11, 0x92, 0x31}, len = ARRAY_SIZE(id);
-   u8 tmp[len];
+   u8 tmp[ARRAY_SIZE(id)]; // Using len causes a Wvla warning

HTH
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 03/42] mei: bus: whitelist hdcp client

From: Tomas Winkler 

Whitelist HDCP client for in kernel drm use

v2:
  Rebased.

Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/bus-fixup.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/misc/mei/bus-fixup.c b/drivers/misc/mei/bus-fixup.c
index 0208c4b027c5..3df2a69fddfb 100644
--- a/drivers/misc/mei/bus-fixup.c
+++ b/drivers/misc/mei/bus-fixup.c
@@ -41,6 +41,9 @@ static const uuid_le mei_nfc_info_guid = MEI_UUID_NFC_INFO;
 #define MEI_UUID_MKHIF_FIX UUID_LE(0x55213584, 0x9a29, 0x4916, \
0xba, 0xdf, 0xf, 0xb7, 0xed, 0x68, 0x2a, 0xeb)
 
+#define MEI_UUID_HDCP UUID_LE(0xB638AB7E, 0x94E2, 0x4EA2, \
+ 0xA5, 0x52, 0xD1, 0xC5, 0x4B, 0x62, 0x7F, 0x04)
+
 #define MEI_UUID_ANY NULL_UUID_LE
 
 /**
@@ -72,6 +75,18 @@ static void blacklist(struct mei_cl_device *cldev)
cldev->do_match = 0;
 }
 
+/**
+ * whitelist - forcefully whitelist client
+ *
+ * @cldev: me clients device
+ */
+static void whitelist(struct mei_cl_device *cldev)
+{
+   dev_dbg(&cldev->dev, "running hook %s\n", __func__);
+
+   cldev->do_match = 1;
+}
+
 #define OSTYPE_LINUX2
 struct mei_os_ver {
__le16 build;
@@ -399,6 +414,7 @@ static struct mei_fixup {
MEI_FIXUP(MEI_UUID_NFC_HCI, mei_nfc),
MEI_FIXUP(MEI_UUID_WD, mei_wd),
MEI_FIXUP(MEI_UUID_MKHIF_FIX, mei_mkhi_fix),
+   MEI_FIXUP(MEI_UUID_HDCP, whitelist),
 };
 
 /**
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 02/42] drm: HDMI and DP specific HDCP2.2 defines

In preparation for implementing HDCP2.2 in I915, this patch adds
HDCP register definitions for HDMI and DP HDCP adaptations.

HDMI specific HDCP2.2 register definitions are added into drm_hdcp.h,
where are HDCP2.2 register offsets in DPCD offsets are defined at
drm_dp_helper.h.

v2:
  bit_field definitions are replaced by macros. [Tomas and Jany]

Signed-off-by: Ramalingam C 
---
 include/drm/drm_dp_helper.h | 54 +
 include/drm/drm_hdcp.h  | 29 
 2 files changed, 83 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 4de97e94ef9d..2185b3a88911 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -887,6 +887,60 @@
 #define DP_AUX_HDCP_KSV_FIFO   0x6802C
 #define DP_AUX_HDCP_AINFO  0x6803B
 
+/**
+ * DP HDCP2.2 parameter offsets in DPCD address space
+ */
+#define DP_HDCP_2_2_REG_RTX_OFFSET 0x69000
+#define DP_HDCP_2_2_REG_TXCAPS_OFFSET  0x69008
+#define DP_HDCP_2_2_REG_CERT_RX_OFFSET 0x6900B
+#define DP_HDCP_2_2_REG_RRX_OFFSET 0x69215
+#define DP_HDCP_2_2_REG_RX_CAPS_OFFSET 0x6921D
+#define DP_HDCP_2_2_REG_EKPUB_KM_OFFSET0x69220
+#define DP_HDCP_2_2_REG_EKH_KM_OFFSET  0x692A0
+#define DP_HDCP_2_2_REG_M_OFFSET   0x692B0
+#define DP_HDCP_2_2_REG_HPRIME_OFFSET  0x692C0
+#define DP_HDCP_2_2_REG_EKH_KM_RD_OFFSET   0x692E0
+#define DP_HDCP_2_2_REG_RN_OFFSET  0x692F0
+#define DP_HDCP_2_2_REG_LPRIME_OFFSET  0x692F8
+#define DP_HDCP_2_2_REG_EDKEY_KS_OFFSET0x69318
+#defineDP_HDCP_2_2_REG_RIV_OFFSET  0x69328
+#define DP_HDCP_2_2_REG_RXINFO_OFFSET  0x69330
+#define DP_HDCP_2_2_REG_SEQ_NUM_V_OFFSET   0x69332
+#define DP_HDCP_2_2_REG_VPRIME_OFFSET  0x69335
+#define DP_HDCP_2_2_REG_RECV_ID_LIST_OFFSET0x69345
+#define DP_HDCP_2_2_REG_V_OFFSET   0x693E0
+#define DP_HDCP_2_2_REG_SEQ_NUM_M_OFFSET   0x693F0
+#define DP_HDCP_2_2_REG_K_OFFSET   0x693F3
+#define DP_HDCP_2_2_REG_STREAM_ID_TYPE_OFFSET  0x693F5
+#define DP_HDCP_2_2_REG_MPRIME_OFFSET  0x69473
+#define DP_HDCP_2_2_REG_RXSTATUS_OFFSET0x69493
+#define DP_HDCP_2_2_REG_STREAM_TYPE_OFFSET 0x69494
+#define DP_HDCP_2_2_REG_DBG_OFFSET 0x69518
+
+/**
+ * DP HDCP message start offsets in DPCD address space
+ */
+#define DP_HDCP_2_2_AKE_INIT_OFFSETDP_HDCP_2_2_REG_RTX_OFFSET
+#define DP_HDCP_2_2_AKE_SEND_CERT_OFFSET   DP_HDCP_2_2_REG_CERT_RX_OFFSET
+#define DP_HDCP_2_2_AKE_NO_STORED_KM_OFFSETDP_HDCP_2_2_REG_EKPUB_KM_OFFSET
+#define DP_HDCP_2_2_AKE_STORED_KM_OFFSET   DP_HDCP_2_2_REG_EKH_KM_OFFSET
+#define DP_HDCP_2_2_AKE_SEND_HPRIME_OFFSET DP_HDCP_2_2_REG_HPRIME_OFFSET
+#define DP_HDCP_2_2_AKE_SEND_PARING_INFO_OFFSET
DP_HDCP_2_2_REG_EKH_KM_RD_OFFSET
+#define DP_HDCP_2_2_LC_INIT_OFFSET DP_HDCP_2_2_REG_RN_OFFSET
+#define DP_HDCP_2_2_LC_SEND_LPRIME_OFFSET  DP_HDCP_2_2_REG_LPRIME_OFFSET
+#define DP_HDCP_2_2_SKE_SEND_EKS_OFFSET
DP_HDCP_2_2_REG_EDKEY_KS_OFFSET
+#define DP_HDCP_2_2_REP_SEND_RECVID_LIST_OFFSET
DP_HDCP_2_2_REG_RXINFO_OFFSET
+#define DP_HDCP_2_2_REP_SEND_ACK_OFFSETDP_HDCP_2_2_REG_V_OFFSET
+#define DP_HDCP_2_2_REP_STREAM_MANAGE_OFFSET   DP_HDCP_2_2_REG_SEQ_NUM_M_OFFSET
+#define DP_HDCP_2_2_REP_STREAM_READY_OFFSETDP_HDCP_2_2_REG_MPRIME_OFFSET
+
+#define HDCP_2_2_DP_RXSTATUS_LEN   1
+#define HDCP_2_2_DP_RXSTATUS_READY(x)  (x & BIT(0))
+#define HDCP_2_2_DP_RXSTATUS_H_PRIME(x)(x & BIT(1))
+#define HDCP_2_2_DP_RXSTATUS_PAIRING(x)(x & BIT(2))
+#define HDCP_2_2_DP_RXSTATUS_REAUTH_REQ(x) (x & BIT(3))
+#define HDCP_2_2_DP_RXSTATUS_LINK_FAILED(x)(x & BIT(4))
+
 /* DP 1.2 Sideband message defines */
 /* peer device type - DP 1.2a Table 2-92 */
 #define DP_PEER_DEVICE_NONE0x0
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index 5e0a5ed1a08e..f3f28414b189 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -221,4 +221,33 @@ struct hdcp2_dp_errata_stream_type {
uint8_t stream_type;
 } __packed;
 
+/* HDCP2.2 TIMEOUTs in mSec */
+#define HDCP_2_2_CERT_TIMEOUT  100
+#define HDCP_2_2_HPRIME_NO_PAIRED_TIMEOUT  1000
+#define HDCP_2_2_HPRIME_PAIRED_TIMEOUT 200
+#define HDCP_2_2_PAIRING_TIMEOUT   200
+#defineHDCP_2_2_HDMI_LPRIME_TIMEOUT20
+#define HDCP_2_2_DP_LPRIME_TIMEOUT 7
+#define HDCP_2_2_RECVID_LIST_TIMEOUT   3000
+#define HDCP_2_2_STREAM_READY_TIMEOUT  100
+
+/* HDMI HDCP2.2 Register Offsets */
+#define HDCP_2_2_HDMI_REG_VER_OFFSET   0x50
+#define HDCP_2_2_HDMI_REG_WR_MSG_OFFSET0x60
+#define HDCP_2_2_HDMI_REG_RXSTATUS_OFFSET  0x70
+#define HDCP_2_2_HDMI_REG_RD_MSG

[PATCH v2 01/42] drm: hdcp2.2 authentication msg definitions

This patch defines the hdcp2.2 protocol messages for the
HDCP2.2 authentication.

v2:
  bit_fields are removed. Instead bitmasking used. [Tomas and Jani]
  prefix HDCP_2_2_ is added to the macros. [Tomas]

Signed-off-by: Ramalingam C 
---
 include/drm/drm_hdcp.h | 183 +
 1 file changed, 183 insertions(+)

diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index 562fa7df2637..5e0a5ed1a08e 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -38,4 +38,187 @@
 #define DRM_HDCP_DDC_BSTATUS   0x41
 #define DRM_HDCP_DDC_KSV_FIFO  0x43
 
+#define DRM_HDCP_1_4_SRM_ID0x8
+#define DRM_HDCP_1_4_VRL_LENGTH_SIZE   3
+#define DRM_HDCP_1_4_DCP_SIG_SIZE  40
+
+/**
+ * Protocol message definition for HDCP2.2 specification
+ */
+
+#define HDCP_STREAM_TYPE0  0x00
+#define HDCP_STREAM_TYPE1  0x01
+
+/* HDCP2.2 Msg IDs */
+#define HDCP_2_2_NULL_MSG  1
+#define HDCP_2_2_AKE_INIT  2
+#define HDCP_2_2_AKE_SEND_CERT 3
+#define HDCP_2_2_AKE_NO_STORED_KM  4
+#define HDCP_2_2_AKE_STORED_KM 5
+#define HDCP_2_2_AKE_SEND_HPRIME   7
+#define HDCP_2_2_AKE_SEND_PARING_INFO  8
+#define HDCP_2_2_LC_INIT   9
+#define HDCP_2_2_LC_SEND_LPRIME10
+#define HDCP_2_2_SKE_SEND_EKS  11
+#define HDCP_2_2_REP_SEND_RECVID_LIST  12
+#define HDCP_2_2_REP_SEND_ACK  15
+#define HDCP_2_2_REP_STREAM_MANAGE 16
+#define HDCP_2_2_REP_STREAM_READY  17
+#define HDCP_2_2_ERRATA_DP_STREAM_TYPE 50
+
+#define HDCP_2_2_RTX_LEN   8
+#define HDCP_2_2_RRX_LEN   8
+
+#define HDCP_2_2_K_PUB_RX_MOD_N_LEN128
+#define HDCP_2_2_K_PUB_RX_EXP_E_LEN3
+#define HDCP_2_2_K_PUB_RX_LEN  (HDCP_2_2_K_PUB_RX_MOD_N_LEN + \
+HDCP_2_2_K_PUB_RX_EXP_E_LEN)
+
+#define HDCP_2_2_DCP_LLC_SIG_LEN   384
+
+#define HDCP_2_2_E_KPUB_KM_LEN 128
+#define HDCP_2_2_E_KH_KM_M_LEN (16 + 16)
+#define HDCP_2_2_H_PRIME_LEN   32
+#define HDCP_2_2_E_KH_KM_LEN   16
+#define HDCP_2_2_RN_LEN8
+#define HDCP_2_2_L_PRIME_LEN   32
+#define HDCP_2_2_E_DKEY_KS_LEN 16
+#define HDCP_2_2_RIV_LEN   8
+#define HDCP_2_2_SEQ_NUM_LEN   3
+#define HDCP_2_2_LPRIME_HALF_LEN   (HDCP_2_2_L_PRIME_LEN / 2)
+#define HDCP_2_2_RECEIVER_ID_LEN   DRM_HDCP_KSV_LEN
+#define HDCP_2_2_MAX_DEVICE_COUNT  31
+#define HDCP_2_2_RECEIVER_IDS_MAX_LEN  (HDCP_2_2_RECEIVER_ID_LEN * \
+HDCP_2_2_MAX_DEVICE_COUNT)
+#define HDCP_2_2_MPRIME_LEN32
+
+/**
+ * TODO: This has to be changed for DP MST, as multiple stream on
+ * same port is possible.
+ * For HDCP2.2 on HDMI and DP SST this value is always 1.
+ */
+#define HDCP_2_2_MAX_CONTENT_STREAMS_CNT   1
+#define HDCP_2_2_TXCAP_MASK_LEN2
+#define HDCP_2_2_RXCAPS_LEN3
+#define HDCP_2_2_RX_REPEATER(x)(x & BIT(0))
+#define HDCP_2_2_DP_HDCP_CAPABLE(x)(x & BIT(1))
+#define HDCP_2_2_RXINFO_LEN2
+
+/* HDCP1.x compliant device in downstream */
+#define HDCP_2_2_HDCP1_DEVICE_CONNECTED(x) (x & BIT(0))
+
+/* HDCP2.0 Compliant repeater in downstream */
+#define HDCP_2_2_HDCP_2_0_REP_CONNECTED(x) (x & BIT(1))
+#define HDCP_2_2_MAX_CASCADE_EXCEEDED(x)   (x & BIT(2))
+#define HDCP_2_2_MAX_DEVS_EXCEEDED(x)  (x & BIT(3))
+#define HDCP_2_2_DEV_COUNT_LO(x)   ((x & (0xF << 4)) >> 4)
+#define HDCP_2_2_DEV_COUNT_HI(x)   (x & BIT(0))
+#define HDCP_2_2_DEPTH(x)  ((x & (0x7 << 1)) >> 1)
+
+struct hdcp2_cert_rx {
+   uint8_t receiver_id[HDCP_2_2_RECEIVER_ID_LEN];
+   uint8_t kpub_rx[HDCP_2_2_K_PUB_RX_LEN];
+   uint8_t reserved[2];
+   uint8_t dcp_signature[HDCP_2_2_DCP_LLC_SIG_LEN];
+} __packed;
+
+struct hdcp2_streamid_type {
+   uint8_t stream_id;
+   uint8_t stream_type;
+} __packed;
+
+/**
+ * The TxCaps field specified in the HDCP HDMI, DP specs
+ * This field is big endian as specified in the errata.
+ */
+struct hdcp2_tx_caps {
+   /* Transmitter must set this to 0x2 */
+   uint8_t version;
+
+   /* Reserved for HDCP and DP Spec. Read as Zero */
+   uint8_t tx_cap_mask[HDCP_2_2_TXCAP_MASK_LEN];
+} __packed;
+
+/*
+ * Main structures for HDCP2.2 protocol communication
+ */
+struct hdcp2_ake_init {
+   uint8_t msg_id;
+   uint8_t r_tx[HDCP_2_2_RTX_LEN];

[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.

The sequence for HDCP2.2 authentication and encryption is implemented
in I915. Encoder specific implementations are moved into hdcp_shim.

Intel HWs supports HDCP2.2 through ME FW. Hence this series
introduces a client driver for mei bus, so that for HDCP2.2
authentication, HDCP2.2 stack in I915 can avail the services from
ME FW.

Userspace interface remains unchanged as version agnostic. When
userspace request for HDCP enable, Kernel will detect the HDCP source
and sink's HDCP version(1.4/2.2)capability and enable the best capable
version for that combination.

This series enables the HDCP2.2 for Type0 content streams.

Yes its bit lengthy series. Please tolerate. Thanks

Major Changes in v2:
  - Synchronous implementation of HDCP authentication [SeanPaul]
  - Removal of bit-fields usage.[Tomas and Jani]
  - Protecting the mei_interface handle with mutex [Chris]
  - Droped, added and squashed few patches
  - Extended hdcp_shim to support hdcp2.2 operations too. [SeanPaul]
  - Used Intel_wait_for_registers(), Where ever it is applicable.[Chris]
  - mei_hdcp driver is moved into drivers/misc/mei/hdcp/ [Tomas]
  - Adapted the static declaration for struct intel_hdcp and mei_hdcp_data.
[SeanPaul]

Sincere thanks for Sean Paul, Jani Nikula, Chris Wilson and Tomas Winkler
for the review comments on v1 series.


Ramalingam C (41):
  drm: hdcp2.2 authentication msg definitions
  drm: HDMI and DP specific HDCP2.2 defines
  misc/mei/hdcp: Client driver for HDCP application
  misc/mei/hdcp: Add KBuild for mei hdcp driver
  misc/mei/hdcp: Verify mei client device status
  misc/mei/hdcp: Get & Put for mei cl_device
  misc/mei/hdcp: Define ME FW interface for HDCP2.2
  linux/mei: Header for mei_hdcp driver interface
  misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session
  misc/mei/hdcp: Verify Receiver Cert and prepare km
  misc/mei/hdcp: Verify H_prime
  misc/mei/hdcp: Store the HDCP Pairing info
  misc/mei/hdcp: Initiate Locality check
  misc/mei/hdcp: Verify L_prime
  misc/mei/hdcp: Prepare Session Key
  misc/mei/hdcp: Repeater topology verifcation and ack
  misc/mei/hdcp: Verify M_prime
  misc/mei/hdcp: Enabling the HDCP authentication
  misc/mei/hdcp: Closing wired HDCP2.2 Tx Session
  drm/i915: wrapping all hdcp var into intel_hdcp
  drm/i915: Define HDCP2.2 related variables
  drm/i915: Define Intel HDCP2.2 registers
  drm/i915: Wrappers for mei HDCP2.2 services
  drm/i915: Implement HDCP2.2 receiver authentication
  drm/i915: Implement HDCP2.2 repeater authentication
  drm/i915: Enable and Disable HDCP2.2 port encryption
  drm/i915: Implement HDCP2.2 En/Dis-able
  drm/i915: Implement HDCP2.2 link integrity check
  drm/i915: Handle HDCP2.2 downstream topology change
  drm/i915: Pullout the bksv read and validation
  drm/i915: Initialize HDCP2.2 and its MEI interface
  drm/i915: Schedule hdcp_check_link in _intel_hdcp_enable
  drm/i915: Enable superior HDCP ver that is capable
  drm/i915: Enable HDCP1.4 incase of HDCP2.2 failure
  drm/i915: hdcp_check_link only on CP_IRQ
  drm/i915: Check HDCP 1.4 and 2.2 link on CP_IRQ
  drm/i915: Implement gmbus burst read
  drm/i915: Implement the HDCP2.2 support for DP
  drm/i915: Implement the HDCP2.2 support for HDMI
  drm/i915: Add HDCP2.2 support for DP connectors
  drm/i915: Add HDCP2.2 support for HDMI connectors

Tomas Winkler (1):
  mei: bus: whitelist hdcp client

 drivers/gpu/drm/i915/i915_drv.c  |1 +
 drivers/gpu/drm/i915/i915_drv.h  |9 +
 drivers/gpu/drm/i915/i915_reg.h  |   35 ++
 drivers/gpu/drm/i915/intel_display.c |7 +-
 drivers/gpu/drm/i915/intel_dp.c  |  362 ++-
 drivers/gpu/drm/i915/intel_drv.h |   81 ++-
 drivers/gpu/drm/i915/intel_hdcp.c| 1107 --
 drivers/gpu/drm/i915/intel_hdmi.c|  206 ++-
 drivers/gpu/drm/i915/intel_i2c.c |  124 +++-
 drivers/misc/mei/Kconfig |6 +
 drivers/misc/mei/Makefile|2 +
 drivers/misc/mei/bus-fixup.c |   16 +
 drivers/misc/mei/hdcp/Makefile   |6 +
 drivers/misc/mei/hdcp/mei_hdcp.c |  927 
 drivers/misc/mei/hdcp/mei_hdcp.h |  566 +
 include/drm/drm_dp_helper.h  |   54 ++
 include/drm/drm_hdcp.h   |  220 +++
 include/linux/mei_hdcp.h |  215 +++
 18 files changed, 3846 insertions(+), 98 deletions(-)
 create mode 100644 drivers/misc/mei/hdcp/Makefile
 create mode 100644 drivers/misc/mei/hdcp/mei_hdcp.c
 create mode 100644 drivers/misc/mei/hdcp/mei_hdcp.h
 create mode 100644 include/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 04/42] misc/mei/hdcp: Client driver for HDCP application

ME FW is contributes a vital role in HDCP2.2 authentication.
HDCP2.2 driver needs to communicate to ME FW for each step of the
HDCP2.2 authentication.

ME FW prepare and HDCP2.2 authentication  parameters and encrypt them
as per spec. With such parameter Driver prepares HDCP2.2 auth messages
and communicate with HDCP2.2 sink.

Similarly HDCP2. sink's response is shared with ME FW for decrypt and
verification.

Once All the steps of HDCP2.2 authentications are complete on driver's
request ME FW will configure the port as authenticated and supply the
HDCP keys to the Gen HW for encryption.

Only after this stage HDCP2.2 driver can start the HDCP2.2 encryption
for a port.

ME FW is interfaced to kernel through MEI Bus Driver. To obtain the
HDCP2.2 services from the ME FW through MEI Bus driver MEI Client
Driver is developed.

v2:
  hdcp files are moved to drivers/misc/mei/hdcp/ [Tomas]

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
+ *
+ * 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_disable(cldev);
+   return 0;
+}
+
+#define WIDI_HECI_CLIENT_GUID  UUID_LE(0xB638AB7E, 0x94E2, 0x4EA2, 0xA5, \
+   0x52, 0xD1, 0xC5, 0x4B, \
+   0x62, 0x7F, 0x04)
+#define MEI_HDCP2_2_UUID   WIDI_HECI_CLIENT_GUID
+
+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");
+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
index ..c06c0d767c4f
--- /dev/null
+++ b/drivers/misc/mei/hdcp/mei_hdcp.h
@@ -0,0 +1,32 @@
+/*
+ * Copyright (c) 2017 Intel Corporation
+ *
+ * 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 SOFTWAR

[PATCH v2 06/42] misc/mei/hdcp: Verify mei client device status

Checks whether mei client device for hdcp2.2 is enabled?

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);
+}
+
 static int mei_hdcp_probe(struct mei_cl_device *cldev,
  const struct mei_cl_device_id *id)
 {
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 05/42] misc/mei/hdcp: Add KBuild for mei hdcp driver

v2:
  including the hdcp folder with a Makefile. [Tomas]

Signed-off-by: Ramalingam C 
---
 drivers/misc/mei/Kconfig   | 6 ++
 drivers/misc/mei/Makefile  | 2 ++
 drivers/misc/mei/hdcp/Makefile | 6 ++
 3 files changed, 14 insertions(+)
 create mode 100644 drivers/misc/mei/hdcp/Makefile

diff --git a/drivers/misc/mei/Kconfig b/drivers/misc/mei/Kconfig
index c49e1d2269af..90977132d1e2 100644
--- a/drivers/misc/mei/Kconfig
+++ b/drivers/misc/mei/Kconfig
@@ -43,3 +43,9 @@ config INTEL_MEI_TXE
 
  Supported SoCs:
  Intel Bay Trail
+
+config INTEL_MEI_HDCP
+   tristate "Intel HDCP2.2 services of ME Interface"
+   depends on INTEL_MEI && DRM_I915
+   help
+ MEI Support for HDCP2.2 Services on Intel SoCs.
diff --git a/drivers/misc/mei/Makefile b/drivers/misc/mei/Makefile
index cd6825afa8e1..e64d1212fb85 100644
--- a/drivers/misc/mei/Makefile
+++ b/drivers/misc/mei/Makefile
@@ -23,3 +23,5 @@ mei-txe-objs += hw-txe.o
 
 mei-$(CONFIG_EVENT_TRACING) += mei-trace.o
 CFLAGS_mei-trace.o = -I$(src)
+
+obj-$(CONFIG_INTEL_MEI_HDCP) += hdcp/
diff --git a/drivers/misc/mei/hdcp/Makefile b/drivers/misc/mei/hdcp/Makefile
new file mode 100644
index ..75ac50203223
--- /dev/null
+++ b/drivers/misc/mei/hdcp/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Makefile - HDCP client driver for Intel MEI Bus Driver.
+# Copyright (c) 2010-2014, Intel Corporation.
+#
+obj-$(CONFIG_INTEL_MEI_HDCP) += mei_hdcp.o
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[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.

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_GUID  UUID_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
+ * about the suitability of this software for any purpose.  It is provided "as
+ * is" without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
+ * EVENT SHALL THE COPYRIGHT HOLDERS BE LIAB

[PATCH v2 08/42] misc/mei/hdcp: Define ME FW interface for HDCP2.2

Defines the HDCP specific ME FW interfaces such as Request CMDs,
payload structure for CMDs and their response status codes.

This patch defines payload size(Excluding the Header)for each WIRED
HDCP2.2 CMDs.

v2:
  Rebased.

Signed-off-by: Ramalingam C 
---
 drivers/misc/mei/hdcp/mei_hdcp.h | 525 +++
 1 file changed, 525 insertions(+)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.h b/drivers/misc/mei/hdcp/mei_hdcp.h
index 7d792b5ad703..32fb844554f5 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.h
+++ b/drivers/misc/mei/hdcp/mei_hdcp.h
@@ -24,6 +24,8 @@
 #define __MEI_HDCP_H__
 
 #include 
+#include 
+#include 
 
 struct mei_hdcp {
struct mei_cl_device *cldev;
@@ -38,4 +40,527 @@ struct mei_hdcp {
int ref_cnt;
 };
 
+/**
+ * @enum me_hdcp_status: Enumeration of all HDCP Status Codes
+ */
+enum me_hdcp_status {
+   ME_HDCP_STATUS_SUCCESS  = 0x,
+
+   /* WiDi Generic Status Codes */
+   ME_HDCP_STATUS_INTERNAL_ERROR   = 0x1000,
+   ME_HDCP_STATUS_UNKNOWN_ERROR= 0x1001,
+   ME_HDCP_STATUS_INCORRECT_API_VERSION= 0x1002,
+   ME_HDCP_STATUS_INVALID_FUNCTION = 0x1003,
+   ME_HDCP_STATUS_INVALID_BUFFER_LENGTH= 0x1004,
+   ME_HDCP_STATUS_INVALID_PARAMS   = 0x1005,
+   ME_HDCP_STATUS_AUTHENTICATION_FAILED= 0x1006,
+
+   /* WiDi Status Codes */
+   ME_HDCP_INVALID_SESSION_STATE   = 0x6000,
+   ME_HDCP_SRM_FRAGMENT_UNEXPECTED = 0x6001,
+   ME_HDCP_SRM_INVALID_LENGTH  = 0x6002,
+   ME_HDCP_SRM_FRAGMENT_OFFSET_INVALID = 0x6003,
+   ME_HDCP_SRM_VERIFICATION_FAILED = 0x6004,
+   ME_HDCP_SRM_VERSION_TOO_OLD = 0x6005,
+   ME_HDCP_RX_CERT_VERIFICATION_FAILED = 0x6006,
+   ME_HDCP_RX_REVOKED  = 0x6007,
+   ME_HDCP_H_VERIFICATION_FAILED   = 0x6008,
+   ME_HDCP_REPEATER_CHECK_UNEXPECTED   = 0x6009,
+   ME_HDCP_TOPOLOGY_MAX_EXCEEDED   = 0x600A,
+   ME_HDCP_V_VERIFICATION_FAILED   = 0x600B,
+   ME_HDCP_L_VERIFICATION_FAILED   = 0x600C,
+   ME_HDCP_STREAM_KEY_ALLOC_FAILED = 0x600D,
+   ME_HDCP_BASE_KEY_RESET_FAILED   = 0x600E,
+   ME_HDCP_NONCE_GENERATION_FAILED = 0x600F,
+   ME_HDCP_STATUS_INVALID_E_KEY_STATE  = 0x6010,
+   ME_HDCP_STATUS_INVALID_CS_ICV   = 0x6011,
+   ME_HDCP_STATUS_INVALID_KB_KEY_STATE = 0x6012,
+   ME_HDCP_STATUS_INVALID_PAVP_MODE_ICV= 0x6013,
+   ME_HDCP_STATUS_INVALID_PAVP_MODE= 0x6014,
+   ME_HDCP_STATUS_LC_MAX_ATTEMPTS  = 0x6015,
+
+   /* New status for HDCP 2.1 */
+   ME_HDCP_STATUS_MISMATCH_IN_M= 0x6016,
+
+   /* New status code for HDCP 2.2 Rx */
+   ME_HDCP_STATUS_RX_PROV_NOT_ALLOWED  = 0x6017,
+   ME_HDCP_STATUS_RX_PROV_WRONG_SUBJECT= 0x6018,
+   ME_HDCP_RX_NEEDS_PROVISIONING   = 0x6019,
+   ME_HDCP_BKSV_ICV_AUTH_FAILED= 0x6020,
+   ME_HDCP_STATUS_INVALID_STREAM_ID= 0x6021,
+   ME_HDCP_STATUS_CHAIN_NOT_INITIALIZED= 0x6022,
+   ME_HDCP_FAIL_NOT_EXPECTED   = 0x6023,
+   ME_HDCP_FAIL_HDCP_OFF   = 0x6024,
+   ME_HDCP_FAIL_INVALID_PAVP_MEMORY_MODE   = 0x6025,
+   ME_HDCP_FAIL_AES_ECB_FAILURE= 0x6026,
+   ME_HDCP_FEATURE_NOT_SUPPORTED   = 0x6027,
+   ME_HDCP_DMA_READ_ERROR  = 0x6028,
+   ME_HDCP_DMA_WRITE_ERROR = 0x6029,
+   ME_HDCP_FAIL_INVALID_PACKET_SIZE= 0x6030,
+   ME_HDCP_H264_PARSING_ERROR  = 0x6031,
+   ME_HDCP_HDCP2_ERRATA_VIDEO_VIOLATION= 0x6032,
+   ME_HDCP_HDCP2_ERRATA_AUDIO_VIOLATION= 0x6033,
+   ME_HDCP_TX_ACTIVE_ERROR = 0x6034,
+   ME_HDCP_MODE_CHANGE_ERROR   = 0x6035,
+   ME_HDCP_STREAM_TYPE_ERROR   = 0x6036,
+   ME_HDCP_STREAM_MANAGE_NOT_POSSIBLE  = 0x6037,
+
+   ME_HDCP_STATUS_PORT_INVALID_COMMAND = 0x6038,
+   ME_HDCP_STATUS_UNSUPPORTED_PROTOCOL = 0x6039,
+   ME_HDCP_STATUS_INVALID_PORT_INDEX   = 0x603a,
+   ME_HDCP_STATUS_TX_AUTH_NEEDED   = 0x603b,
+   ME_HDCP_STATUS_NOT_INTEGRATED_PORT  = 0x603c,
+   ME_HDCP_STATUS_SESSION_MAX_REACHED  = 0x603d,
+
+   /* hdcp capable bit is not set in rx_caps(error is unique to DP) */
+   ME_HDCP_STATUS_NOT_HDCP_CAPABLE = 0x6041,
+
+   ME_HDCP_STATUS_INVALID_STREAM_COUNT = 0x6042,
+};
+
+#define HDCP_API_VERSION   0x0001
+
+#define HDCP_M_LEN 16
+#define HDCP_KH_LEN16
+
+/*
+ * Payload Buffer size(Excluding Header) for each CMD and corresponding 
response
+ */
+/* Wired_Tx_AKE  */
+#defineWIRED_CMD_BUF_LEN_INITIATE_HDCP2_SESSION_IN (4 + 1)
+#defineWIRED_CM

[PATCH v2 11/42] misc/mei/hdcp: Verify Receiver Cert and prepare km

Requests for verification for receiver certification and also the
preparation for next AKE auth message with km.

On Success ME FW validate the HDCP2.2 receivers certificate and do the
revocation check on the receiver ID. AKE_Stored_Km will be prepared if
the receiver is already paired, else AKE_No_Stored_Km will be prepared.

Here AKE_Stored_Km and AKE_No_Stored_Km are HDCP2.2 protocol msgs.

v2:
  Rebased.

Signed-off-by: Ramalingam C 
---
 drivers/misc/mei/hdcp/mei_hdcp.c | 89 
 include/linux/mei_hdcp.h | 15 +++
 2 files changed, 104 insertions(+)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 516ad6a40616..7c3f02c2e324 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -119,6 +119,95 @@ int mei_initiate_hdcp2_session(struct mei_hdcp_data *data,
 }
 EXPORT_SYMBOL(mei_initiate_hdcp2_session);
 
+/**
+ * mei_verify_receiver_cert_prepare_km:
+ * Function to verify the Receiver Certificate AKE_Send_Cert
+ * and prepare AKE_Stored_Km or AKE_No_Stored_Km
+ *
+ * @data   : Intel HW specific Data
+ * @rx_cert: Pointer for AKE_Send_Cert
+ * @km_stored  : Pointer for pairing status flag
+ * @ek_pub_km  : Pointer for output msg
+ * @msg_sz : Pointer for size of AKE_X_Km
+ *
+ * Returns 0 on Success, <0 on Failure
+ */
+int
+mei_verify_receiver_cert_prepare_km(struct mei_hdcp_data *data,
+   struct hdcp2_ake_send_cert *rx_cert,
+   bool *km_stored,
+   struct hdcp2_ake_no_stored_km *ek_pub_km,
+   size_t *msg_sz)
+{
+   struct wired_cmd_verify_receiver_cert_in verify_rxcert_in = { { 0 } };
+   struct wired_cmd_verify_receiver_cert_out verify_rxcert_out = { { 0 } };
+   enum me_hdcp_status status;
+   struct device *dev;
+   ssize_t byte;
+
+   if (!data || !rx_cert || !km_stored || !ek_pub_km || !msg_sz)
+   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 */
+   verify_rxcert_in.header.api_version = HDCP_API_VERSION;
+   verify_rxcert_in.header.command_id = WIRED_VERIFY_RECEIVER_CERT;
+   verify_rxcert_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   verify_rxcert_in.header.buffer_len =
+   WIRED_CMD_BUF_LEN_VERIFY_RECEIVER_CERT_IN;
+
+   /* Fill the data */
+   verify_rxcert_in.port.integrated_port_type = data->port_type;
+   verify_rxcert_in.port.physical_port = data->port;
+
+   memcpy(&verify_rxcert_in.cert_rx, &rx_cert->cert_rx,
+  sizeof(rx_cert->cert_rx));
+   memcpy(verify_rxcert_in.r_rx, &rx_cert->r_rx, sizeof(rx_cert->r_rx));
+   memcpy(verify_rxcert_in.rx_caps, rx_cert->rx_caps, HDCP_2_2_RXCAPS_LEN);
+
+   /* Request to ME */
+   byte = mei_cldev_send(data->cldev, (u8 *)&verify_rxcert_in,
+ sizeof(verify_rxcert_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_rxcert_out,
+ sizeof(verify_rxcert_out));
+   if (byte < 0) {
+   dev_err(dev, "mei_cldev_recv failed: %d\n", (int)byte);
+   return byte;
+   }
+
+   status = (enum me_hdcp_status)verify_rxcert_out.header.status;
+   if (status != ME_HDCP_STATUS_SUCCESS) {
+   dev_err(dev, "ME cmd 0x%08X Failed. Status: 0x%X\n",
+   WIRED_VERIFY_RECEIVER_CERT, status);
+   return -1;
+   }
+
+   *km_stored = verify_rxcert_out.km_stored;
+   if (verify_rxcert_out.km_stored) {
+   ek_pub_km->msg_id = HDCP_2_2_AKE_STORED_KM;
+   *msg_sz = sizeof(struct hdcp2_ake_stored_km);
+   } else {
+   ek_pub_km->msg_id = HDCP_2_2_AKE_NO_STORED_KM;
+   *msg_sz = sizeof(struct hdcp2_ake_no_stored_km);
+   }
+
+   memcpy(ek_pub_km->e_kpub_km, &verify_rxcert_out.ekm_buff,
+  sizeof(verify_rxcert_out.ekm_buff));
+   return 0;
+}
+EXPORT_SYMBOL(mei_verify_receiver_cert_prepare_km);
+
 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 c333528b9c1e..510a5c1ff1ff 100644
--- a/include/linux/mei_hdcp.h
+++ b/include/linux/mei_hdcp.h
@@ -105,6 +105,12 @@ 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_dat

[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)
+{
+   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;
+
+   dev = &data->cldev->dev;
+
+   /* Fill header details */
+   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 */
+   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;
+   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_data *data,
+  struct hdcp2_ake_init *ake_data)
+{
+   return -ENODEV;
+}
 #endif /* defined (CONFIG_INTEL_MEI_HDCP) */
 #endif /* defined (_LINUX_MEI_HDCP_H) */
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.

[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
 
+#include 
+
+/*
+ * Enumeration of the physical DDI available on the platform
+ */
+enum physical_port {
+   INVALID_PORT = 0x00,/* Not a valid port */
+
+   DDI_RANGE_BEGIN = 0x01, /* Beginning of the valid DDI port range */
+   DDI_B   = 0x01, /* Port DDI B */
+   DDI_C   = 0x02, /* Port DDI C */
+   DDI_D   = 0x03, /* Port DDI D */
+   DDI_E   = 0x04, /* Port DDI E */
+   DDI_F   = 0x05, /* Port DDI F */
+   DDI_A   = 0x07, /* Port DDI A */
+   DDI_RANGE_END   = DDI_A,/* End of the valid DDI port range */
+};
+
+/* The types of HDCP 2.2 ports supported */
+enum hdcp_integrated_port_type {
+   HDCP_INVALID_TYPE   = 0x00,
+
+   /* HDCP 2.x ports that are integrated into Intel HW */
+   INTEGRATED  = 0x01,
+
+   /* HDCP2.2 discrete wired Tx port with LSPCON (HDMI 2.0) solution */
+   LSPCON  = 0x02,
+
+   /* HDCP2.2 discrete wired Tx port using the CPDP (DP 1.3) solution */
+   CPDP= 0x03,
+};
+
+/**
+ * wired_protocol: Supported integrated wired HDCP protocol.
+ * Based on this value, Minor differenceneeded between wired specifications
+ * are handled.
+ */
+enum hdcp_protocol {
+   HDCP_PROTOCOL_INVALID,
+   HDCP_PROTOCOL_HDMI,
+   HDCP_PROTOCOL_DP
+};
+
+/**
+ * mei_hdcp_data: Input data to the mei_hdcp APIs.
+ */
+struct mei_hdcp_data {
+   struct mei_cl_device *cldev;
+   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

[PATCH v2 14/42] misc/mei/hdcp: Initiate Locality check

Requests ME to start the second stage of HDCP2.2 authentication,
called Locality Check.

On Success, ME FW will provide LC_Init message to send to hdcp sink.

v2:
  Rebased.

Signed-off-by: Ramalingam C 
---
 drivers/misc/mei/hdcp/mei_hdcp.c | 64 
 include/linux/mei_hdcp.h |  8 +
 2 files changed, 72 insertions(+)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 753a6a466611..ff19de58222f 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -339,6 +339,70 @@ int mei_store_pairing_info(struct mei_hdcp_data *data,
 }
 EXPORT_SYMBOL(mei_store_pairing_info);
 
+/**
+ * mei_initiate_locality_check:
+ * Function to prepare LC_Init.
+ *
+ * @data   : Intel HW specific Data
+ * @hdcp2_lc_init  : Pointer for storing LC_Init
+ *
+ * Returns 0 on Success, <0 on Failure
+ */
+int mei_initiate_locality_check(struct mei_hdcp_data *data,
+   struct hdcp2_lc_init *lc_init_data)
+{
+   struct wired_cmd_init_locality_check_in lc_init_in = { { 0 } };
+   struct wired_cmd_init_locality_check_out lc_init_out = { { 0 } };
+   enum me_hdcp_status status;
+   struct device *dev;
+   ssize_t byte;
+
+   if (!data || !lc_init_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;
+
+   lc_init_in.header.api_version = HDCP_API_VERSION;
+   lc_init_in.header.command_id = WIRED_INIT_LOCALITY_CHECK;
+   lc_init_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   lc_init_in.header.buffer_len = WIRED_CMD_BUF_LEN_INIT_LOCALITY_CHECK_IN;
+
+   lc_init_in.port.integrated_port_type = data->port_type;
+   lc_init_in.port.physical_port = data->port;
+
+   /* Request to ME */
+   byte = mei_cldev_send(data->cldev, (u8 *)&lc_init_in,
+ sizeof(lc_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 *)&lc_init_out,
+ sizeof(lc_init_out));
+   if (byte < 0) {
+   dev_err(dev, "mei_cldev_recv failed. %d\n", (int)byte);
+   return byte;
+   }
+
+   status = (enum me_hdcp_status)lc_init_out.header.status;
+   if (status != ME_HDCP_STATUS_SUCCESS) {
+   dev_err(dev, "ME cmd 0x%08X Failed. status: 0x%X\n",
+   WIRED_INIT_LOCALITY_CHECK, status);
+   return -1;
+   }
+
+   lc_init_data->msg_id = HDCP_2_2_LC_INIT;
+   memcpy(lc_init_data->r_n, lc_init_out.r_n, HDCP_2_2_RN_LEN);
+   return 0;
+}
+EXPORT_SYMBOL(mei_initiate_locality_check);
+
 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 449ac3af4d53..fd8a26dddacb 100644
--- a/include/linux/mei_hdcp.h
+++ b/include/linux/mei_hdcp.h
@@ -115,6 +115,8 @@ int mei_verify_hprime(struct mei_hdcp_data *data,
  struct hdcp2_ake_send_hprime *rx_hprime);
 int mei_store_pairing_info(struct mei_hdcp_data *data,
   struct hdcp2_ake_send_pairing_info *pairing_info);
+int mei_initiate_locality_check(struct mei_hdcp_data *data,
+   struct hdcp2_lc_init *lc_init_data);
 #else
 static inline
 int mei_hdcp_cldev_get_reference(void *client_data,
@@ -156,5 +158,11 @@ int mei_store_pairing_info(struct mei_hdcp_data *data,
 {
return -ENODEV;
 }
+static inline
+int mei_initiate_locality_check(struct mei_hdcp_data *data,
+   struct hdcp2_lc_init *lc_init_data)
+{
+   return -ENODEV;
+}
 #endif /* defined (CONFIG_INTEL_MEI_HDCP) */
 #endif /* defined (_LINUX_MEI_HDCP_H) */
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 15/42] misc/mei/hdcp: Verify L_prime

Request to ME to verify the LPrime received from HDCP sink.

On Success, ME FW will verify the received Lprime by calculating and
comparing with L.

This represents the completion of Locality Check.

v2:
  Rebased.

Signed-off-by: Ramalingam C 
---
 drivers/misc/mei/hdcp/mei_hdcp.c | 65 
 include/linux/mei_hdcp.h |  8 +
 2 files changed, 73 insertions(+)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index ff19de58222f..c3c8b9a28498 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -403,6 +403,71 @@ int mei_initiate_locality_check(struct mei_hdcp_data *data,
 }
 EXPORT_SYMBOL(mei_initiate_locality_check);
 
+/**
+ * mei_verify_lprime:
+ * Function to verify lprime.
+ *
+ * @data   : Intel HW specific Data
+ * @rx_lprime  : Pointer for LC_Send_L_prime
+ *
+ * Returns 0 on Success, <0 on Failure
+ */
+int mei_verify_lprime(struct mei_hdcp_data *data,
+ struct hdcp2_lc_send_lprime *rx_lprime)
+{
+   struct wired_cmd_validate_locality_in verify_lprime_in = { { 0 } };
+   struct wired_cmd_validate_locality_out verify_lprime_out = { { 0 } };
+   enum me_hdcp_status status;
+   struct device *dev;
+   ssize_t byte;
+
+   if (!data || !rx_lprime)
+   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_lprime_in.header.api_version = HDCP_API_VERSION;
+   verify_lprime_in.header.command_id = WIRED_VALIDATE_LOCALITY;
+   verify_lprime_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   verify_lprime_in.header.buffer_len =
+   WIRED_CMD_BUF_LEN_VALIDATE_LOCALITY_IN;
+
+   verify_lprime_in.port.integrated_port_type = data->port_type;
+   verify_lprime_in.port.physical_port = data->port;
+
+   memcpy(verify_lprime_in.l_prime, rx_lprime->l_prime,
+  sizeof(rx_lprime->l_prime));
+
+   /* Request to ME */
+   byte = mei_cldev_send(data->cldev, (u8 *)&verify_lprime_in,
+ sizeof(verify_lprime_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_lprime_out,
+ sizeof(verify_lprime_out));
+   if (byte < 0) {
+   dev_err(dev, "mei_cldev_recv failed. %d\n", (int)byte);
+   return byte;
+   }
+
+   status = (enum me_hdcp_status)verify_lprime_out.header.status;
+   if (status != ME_HDCP_STATUS_SUCCESS) {
+   dev_err(dev, "ME cmd 0x%08X failed. status: 0x%X\n",
+   WIRED_VALIDATE_LOCALITY, status);
+   return -1;
+   }
+   return 0;
+}
+EXPORT_SYMBOL(mei_verify_lprime);
+
 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 fd8a26dddacb..d8c2b440cd81 100644
--- a/include/linux/mei_hdcp.h
+++ b/include/linux/mei_hdcp.h
@@ -117,6 +117,8 @@ int mei_store_pairing_info(struct mei_hdcp_data *data,
   struct hdcp2_ake_send_pairing_info *pairing_info);
 int mei_initiate_locality_check(struct mei_hdcp_data *data,
struct hdcp2_lc_init *lc_init_data);
+int mei_verify_lprime(struct mei_hdcp_data *data,
+ struct hdcp2_lc_send_lprime *rx_lprime);
 #else
 static inline
 int mei_hdcp_cldev_get_reference(void *client_data,
@@ -164,5 +166,11 @@ int mei_initiate_locality_check(struct mei_hdcp_data *data,
 {
return -ENODEV;
 }
+static inline
+int mei_verify_lprime(struct mei_hdcp_data *data,
+ struct hdcp2_lc_send_lprime *rx_lprime)
+{
+   return -ENODEV;
+}
 #endif /* defined (CONFIG_INTEL_MEI_HDCP) */
 #endif /* defined (_LINUX_MEI_HDCP_H) */
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 12/42] misc/mei/hdcp: Verify H_prime

Requests for the verifcation of AKE_Send_H_prime.

ME will calculation the H and comparing it with received H_Prime.
Here AKE_Send_H_prime is a HDCP2.2 Authentication msg.

v2:
  Rebased.

Signed-off-by: Ramalingam C 
---
 drivers/misc/mei/hdcp/mei_hdcp.c | 65 
 include/linux/mei_hdcp.h |  8 +
 2 files changed, 73 insertions(+)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 7c3f02c2e324..37faca9a3cc8 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -208,6 +208,71 @@ mei_verify_receiver_cert_prepare_km(struct mei_hdcp_data 
*data,
 }
 EXPORT_SYMBOL(mei_verify_receiver_cert_prepare_km);
 
+/**
+ * mei_verify_hprime:
+ * Function to verify AKE_Send_H_prime received
+ *
+ * @data   : Intel HW specific Data
+ * @rx_hprime  : Pointer for AKE_Send_H_prime
+ * @hprime_sz  : Input buffer size
+ *
+ * Returns 0 on Success, <0 on Failure
+ */
+int mei_verify_hprime(struct mei_hdcp_data *data,
+ struct hdcp2_ake_send_hprime *rx_hprime)
+{
+   struct wired_cmd_ake_send_hprime_in send_hprime_in = { { 0 } };
+   struct wired_cmd_ake_send_hprime_out send_hprime_out = { { 0 } };
+   enum me_hdcp_status status;
+   struct device *dev;
+   ssize_t byte;
+
+   if (!data || !rx_hprime)
+   return -EINVAL;
+
+   /* check for the mei_device enabled or not */
+   if (!mei_cldev_active_and_enabled(data->cldev))
+   return -ENODEV;
+
+   dev = &data->cldev->dev;
+
+   send_hprime_in.header.api_version = HDCP_API_VERSION;
+   send_hprime_in.header.command_id = WIRED_AKE_SEND_HPRIME;
+   send_hprime_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   send_hprime_in.header.buffer_len = WIRED_CMD_BUF_LEN_AKE_SEND_HPRIME_IN;
+
+   send_hprime_in.port.integrated_port_type = data->port_type;
+   send_hprime_in.port.physical_port = data->port;
+
+   memcpy(send_hprime_in.h_prime, rx_hprime->h_prime,
+  sizeof(rx_hprime->h_prime));
+
+   /* Request to ME */
+   byte = mei_cldev_send(data->cldev, (u8 *)&send_hprime_in,
+ sizeof(send_hprime_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 *)&send_hprime_out,
+ sizeof(send_hprime_out));
+   if (byte < 0) {
+   dev_err(dev, "mei_cldev_recv failed. %d\n", (int)byte);
+   return byte;
+   }
+
+   status = (enum me_hdcp_status)send_hprime_out.header.status;
+   if (status != ME_HDCP_STATUS_SUCCESS) {
+   dev_err(dev, "ME cmd 0x%08X Failed. Status: 0x%X\n",
+   WIRED_AKE_SEND_HPRIME, status);
+   return -1;
+   }
+   return 0;
+}
+EXPORT_SYMBOL(mei_verify_hprime);
+
 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 510a5c1ff1ff..3590e3421134 100644
--- a/include/linux/mei_hdcp.h
+++ b/include/linux/mei_hdcp.h
@@ -111,6 +111,8 @@ mei_verify_receiver_cert_prepare_km(struct mei_hdcp_data 
*data,
bool *km_stored,
struct hdcp2_ake_no_stored_km *ek_pub_km,
size_t *msg_sz);
+int mei_verify_hprime(struct mei_hdcp_data *data,
+ struct hdcp2_ake_send_hprime *rx_hprime);
 #else
 static inline
 int mei_hdcp_cldev_get_reference(void *client_data,
@@ -140,5 +142,11 @@ mei_verify_receiver_cert_prepare_km(struct mei_hdcp_data 
*data,
 {
return -ENODEV;
 }
+static inline
+int mei_verify_hprime(struct mei_hdcp_data *data,
+ struct hdcp2_ake_send_hprime *rx_hprime)
+{
+   return -ENODEV;
+}
 #endif /* defined (CONFIG_INTEL_MEI_HDCP) */
 #endif /* defined (_LINUX_MEI_HDCP_H) */
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 13/42] misc/mei/hdcp: Store the HDCP Pairing info

Provides Pairing info to ME to store.

Pairing is a process to fast track the subsequent authentication
with the same HDCP sink.

On Success, received HDCP pairing info is stored in non-volatile
memory of ME.

v2:
  Rebased.

Signed-off-by: Ramalingam C 
---
 drivers/misc/mei/hdcp/mei_hdcp.c | 66 
 include/linux/mei_hdcp.h |  8 +
 2 files changed, 74 insertions(+)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 37faca9a3cc8..753a6a466611 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -273,6 +273,72 @@ int mei_verify_hprime(struct mei_hdcp_data *data,
 }
 EXPORT_SYMBOL(mei_verify_hprime);
 
+/**
+ * mei_store_pairing_info:
+ * Function to store pairing info received from panel
+ *
+ * @data   : Intel HW specific Data
+ * @pairing_info   : Pointer for AKE_Send_Pairing_Info
+ *
+ * Returns 0 on Success, <0 on Failure
+ */
+
+int mei_store_pairing_info(struct mei_hdcp_data *data,
+  struct hdcp2_ake_send_pairing_info *pairing_info)
+{
+   struct wired_cmd_ake_send_pairing_info_in pairing_info_in = { { 0 } };
+   struct wired_cmd_ake_send_pairing_info_out pairing_info_out = { { 0 } };
+   enum me_hdcp_status status = ME_HDCP_STATUS_UNKNOWN_ERROR;
+   struct device *dev;
+   ssize_t byte;
+
+   if (!data || !pairing_info)
+   return -EINVAL;
+
+   /* check for the mei_device enabled or not */
+   if (!mei_cldev_active_and_enabled(data->cldev))
+   return -ENODEV;
+
+   dev = &data->cldev->dev;
+
+   pairing_info_in.header.api_version = HDCP_API_VERSION;
+   pairing_info_in.header.command_id = WIRED_AKE_SEND_PAIRING_INFO;
+   pairing_info_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   pairing_info_in.header.buffer_len =
+   WIRED_CMD_BUF_LEN_SEND_PAIRING_INFO_IN;
+
+   pairing_info_in.port.integrated_port_type = data->port_type;
+   pairing_info_in.port.physical_port = data->port;
+
+   memcpy(pairing_info_in.e_kh_km, pairing_info->e_kh_km,
+  sizeof(pairing_info_in.e_kh_km));
+
+   /* Request to ME */
+   byte = mei_cldev_send(data->cldev, (u8 *)&pairing_info_in,
+ sizeof(pairing_info_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 *)&pairing_info_out,
+ sizeof(pairing_info_out));
+   if (byte < 0) {
+   dev_err(dev, "mei_cldev_recv failed. %d\n", (int)byte);
+   return byte;
+   }
+
+   status = (enum me_hdcp_status)pairing_info_out.header.status;
+   if (status != ME_HDCP_STATUS_SUCCESS) {
+   dev_err(dev, "ME cmd 0x%08X failed. Status: 0x%X\n",
+   WIRED_AKE_SEND_PAIRING_INFO, status);
+   return -1;
+   }
+   return 0;
+}
+EXPORT_SYMBOL(mei_store_pairing_info);
+
 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 3590e3421134..449ac3af4d53 100644
--- a/include/linux/mei_hdcp.h
+++ b/include/linux/mei_hdcp.h
@@ -113,6 +113,8 @@ mei_verify_receiver_cert_prepare_km(struct mei_hdcp_data 
*data,
size_t *msg_sz);
 int mei_verify_hprime(struct mei_hdcp_data *data,
  struct hdcp2_ake_send_hprime *rx_hprime);
+int mei_store_pairing_info(struct mei_hdcp_data *data,
+  struct hdcp2_ake_send_pairing_info *pairing_info);
 #else
 static inline
 int mei_hdcp_cldev_get_reference(void *client_data,
@@ -148,5 +150,11 @@ int mei_verify_hprime(struct mei_hdcp_data *data,
 {
return -ENODEV;
 }
+static inline
+int mei_store_pairing_info(struct mei_hdcp_data *data,
+  struct hdcp2_ake_send_pairing_info *pairing_info)
+{
+   return -ENODEV;
+}
 #endif /* defined (CONFIG_INTEL_MEI_HDCP) */
 #endif /* defined (_LINUX_MEI_HDCP_H) */
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 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

[PATCH v2 16/42] misc/mei/hdcp: Prepare Session Key

Request to ME to prepare the encrypted session key.

On Success, ME provides Encrypted session key. Functions populates
the HDCP2.2 authentication msg SKE_Send_Eks.

v2:
  Rebased.

Signed-off-by: Ramalingam C 
---
 drivers/misc/mei/hdcp/mei_hdcp.c | 67 
 include/linux/mei_hdcp.h |  8 +
 2 files changed, 75 insertions(+)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index c3c8b9a28498..fbb88a56e10c 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -468,6 +468,73 @@ int mei_verify_lprime(struct mei_hdcp_data *data,
 }
 EXPORT_SYMBOL(mei_verify_lprime);
 
+/**
+ * mei_get_session_key:
+ * Function to prepare SKE_Send_Eks.
+ *
+ * @data   : Intel HW specific Data
+ * @ske_data   : Pointer for SKE_Send_Eks.
+ *
+ * Returns 0 on Success, <0 on Failure
+ */
+int mei_get_session_key(struct mei_hdcp_data *data,
+   struct hdcp2_ske_send_eks *ske_data)
+{
+   struct wired_cmd_get_session_key_in get_skey_in = { { 0 } };
+   struct wired_cmd_get_session_key_out get_skey_out = { { 0 } };
+   enum me_hdcp_status status;
+   struct device *dev;
+   ssize_t byte;
+
+   if (!data || !ske_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;
+
+   get_skey_in.header.api_version = HDCP_API_VERSION;
+   get_skey_in.header.command_id = WIRED_GET_SESSION_KEY;
+   get_skey_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   get_skey_in.header.buffer_len = WIRED_CMD_BUF_LEN_GET_SESSION_KEY_IN;
+
+   get_skey_in.port.integrated_port_type = data->port_type;
+   get_skey_in.port.physical_port = data->port;
+
+   /* Request to ME */
+   byte = mei_cldev_send(data->cldev, (u8 *)&get_skey_in,
+ sizeof(get_skey_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 *)&get_skey_out,
+ sizeof(get_skey_out));
+
+   if (byte < 0) {
+   dev_err(dev, "mei_cldev_recv failed. %d\n", (int)byte);
+   return byte;
+   }
+
+   status = (enum me_hdcp_status)get_skey_out.header.status;
+   if (status != ME_HDCP_STATUS_SUCCESS) {
+   dev_err(dev, "ME cmd 0x%08X failed. status: 0x%X\n",
+   WIRED_GET_SESSION_KEY, status);
+   return -1;
+   }
+
+   ske_data->msg_id = HDCP_2_2_SKE_SEND_EKS;
+   memcpy(ske_data->e_dkey_ks, get_skey_out.e_dkey_ks,
+  HDCP_2_2_E_DKEY_KS_LEN);
+   memcpy(ske_data->riv, get_skey_out.r_iv, HDCP_2_2_RIV_LEN);
+   return 0;
+}
+EXPORT_SYMBOL(mei_get_session_key);
+
 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 d8c2b440cd81..193f23ba8fbc 100644
--- a/include/linux/mei_hdcp.h
+++ b/include/linux/mei_hdcp.h
@@ -119,6 +119,8 @@ int mei_initiate_locality_check(struct mei_hdcp_data *data,
struct hdcp2_lc_init *lc_init_data);
 int mei_verify_lprime(struct mei_hdcp_data *data,
  struct hdcp2_lc_send_lprime *rx_lprime);
+int mei_get_session_key(struct mei_hdcp_data *data,
+   struct hdcp2_ske_send_eks *ske_data);
 #else
 static inline
 int mei_hdcp_cldev_get_reference(void *client_data,
@@ -172,5 +174,11 @@ int mei_verify_lprime(struct mei_hdcp_data *data,
 {
return -ENODEV;
 }
+static inline
+int mei_get_session_key(struct mei_hdcp_data *data,
+   struct hdcp2_ske_send_eks *ske_data)
+{
+   return -ENODEV;
+}
 #endif /* defined (CONFIG_INTEL_MEI_HDCP) */
 #endif /* defined (_LINUX_MEI_HDCP_H) */
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 17/42] misc/mei/hdcp: Repeater topology verifcation and ack

Request ot ME to verify the downatream topology information received.

ME FW will validate the Repeaters receiver id list and
downstream topology.

On Success ME FW will provide the Least Significant
128bits of VPrime, which forms the repeater ack.

v2:
  Rebased.

Signed-off-by: Ramalingam C 
---
 drivers/misc/mei/hdcp/mei_hdcp.c | 84 
 include/linux/mei_hdcp.h | 13 +++
 2 files changed, 97 insertions(+)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index fbb88a56e10c..02c90770dcb6 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -535,6 +535,90 @@ int mei_get_session_key(struct mei_hdcp_data *data,
 }
 EXPORT_SYMBOL(mei_get_session_key);
 
+/**
+ * mei_repeater_check_flow_prepare_ack:
+ * Function to validate the Downstream topology and prepare rep_ack.
+ *
+ * @data   : Intel HW specific Data
+ * @rep_topology   : Pointer for Receiver Id List to be validated.
+ * @rep_send_ack   : Pointer for repeater ack
+ *
+ * Returns 0 on Success, <0 on Failure
+ */
+
+int
+mei_repeater_check_flow_prepare_ack(struct mei_hdcp_data *data,
+   struct hdcp2_rep_send_receiverid_list
+   *rep_topology,
+   struct hdcp2_rep_send_ack *rep_send_ack)
+{
+   struct wired_cmd_verify_repeater_in verify_repeater_in = { { 0 } };
+   struct wired_cmd_verify_repeater_out verify_repeater_out = { { 0 } };
+   enum me_hdcp_status status;
+   struct device *dev;
+   ssize_t byte;
+
+   if (!rep_topology || !rep_send_ack || !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_repeater_in.header.api_version = HDCP_API_VERSION;
+   verify_repeater_in.header.command_id = WIRED_VERIFY_REPEATER;
+   verify_repeater_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   verify_repeater_in.header.buffer_len =
+   WIRED_CMD_BUF_LEN_VERIFY_REPEATER_IN;
+
+   verify_repeater_in.port.integrated_port_type = data->port_type;
+   verify_repeater_in.port.physical_port = data->port;
+
+   memcpy(verify_repeater_in.rx_info, rep_topology->rx_info,
+  HDCP_2_2_RXINFO_LEN);
+   memcpy(verify_repeater_in.seq_num_v, rep_topology->seq_num_v,
+  HDCP_2_2_SEQ_NUM_LEN);
+   memcpy(verify_repeater_in.v_prime, rep_topology->v_prime,
+  HDCP_2_2_LPRIME_HALF_LEN);
+   memcpy(verify_repeater_in.receiver_ids, rep_topology->receiver_ids,
+  HDCP_2_2_RECEIVER_IDS_MAX_LEN);
+
+   /* Request to ME */
+   byte = mei_cldev_send(data->cldev, (u8 *)&verify_repeater_in,
+ sizeof(verify_repeater_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_repeater_out,
+ sizeof(verify_repeater_out));
+   if (byte < 0) {
+   dev_err(dev, "mei_cldev_recv failed. %d\n", (int)byte);
+   return byte;
+   }
+
+   status = (enum me_hdcp_status)verify_repeater_out.header.status;
+   if (status != ME_HDCP_STATUS_SUCCESS) {
+   dev_err(dev, "ME cmd 0x%08X failed. status: 0x%X\n",
+   WIRED_VERIFY_REPEATER, status);
+   return -1;
+   }
+
+   /*
+* Need to send the last byte of the V prime back to
+* the Repeater
+*/
+   memcpy(rep_send_ack->v, verify_repeater_out.v,
+  HDCP_2_2_LPRIME_HALF_LEN);
+   rep_send_ack->msg_id = HDCP_2_2_REP_SEND_ACK;
+   return 0;
+}
+EXPORT_SYMBOL(mei_repeater_check_flow_prepare_ack);
+
 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 193f23ba8fbc..c8f6fc90f475 100644
--- a/include/linux/mei_hdcp.h
+++ b/include/linux/mei_hdcp.h
@@ -121,6 +121,11 @@ int mei_verify_lprime(struct mei_hdcp_data *data,
  struct hdcp2_lc_send_lprime *rx_lprime);
 int mei_get_session_key(struct mei_hdcp_data *data,
struct hdcp2_ske_send_eks *ske_data);
+int
+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);
 #else
 static inline
 int mei_hdcp_cldev_get_reference(void *client_data,
@@ -180,5 +185,13 @@ int mei_get_session_key(str

[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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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

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

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

[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 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

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 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 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 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 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

[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

[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 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 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

--- 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

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

Re: [PATCH] drm/nouveau: Replace the iturbt_709 prop with the standarad COLOR_ENCODNIG prop

2018-03-08 Thread Ville Syrjälä

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

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 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 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 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: nouveau 30bpp / deep color status

2018-03-08 Thread Mario Kleiner

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: nouveau 30bpp / deep color status

2018-03-08 Thread Ilia Mirkin

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: [RFC v3 09/12] drm: Add API for in-kernel clients

2018-03-08 Thread Noralf Trønnes



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

2018-03-08 Thread Daniel Stone

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: [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: [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 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 v3 5/6] drm/i915: Introduce 'priority offset' for GPU contexts (v2)

2018-03-08 Thread Matt Roper

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

[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)

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 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 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 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

[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

Re: [PATCH v3 5/6] drm/i915: Introduce 'priority offset' for GPU contexts (v2)

2018-03-08 Thread Matt Roper

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

Re: [RFC][PATCH 1/2] drm_hwcomposer: Error out on YUV layer as it would fail for single planes

2018-03-08 Thread John Stultz

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

[PATCH] drm/meson: Add support for DMT modes on HDMI

2018-03-08 Thread Neil Armstrong

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

[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

Re: [Freedreno] [PATCH 2/2] arm64: dts: sdm845: Support GPU/GMU

2018-03-08 Thread Jordan Crouse

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 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

[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

Re: [patch 1/1] drivers/gpu/drm/i915/intel_guc_log.c: work around gcc-4.4.4 union initializer issue

2018-03-08 Thread Andrew Morton

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 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

[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 93727] [Regression] [r600g] Core profile is 3.2 instead of 3.3 in Big Endian PPC