Re: [PATCH v2] drm/atomic: add ATOMIC_AMEND flag to the Atomic IOCTL.

[Tomasz Figa]

Hi Helen,

On Sat, Nov 24, 2018 at 6:54 AM Helen Koike  wrote:
>
> This flag tells core to jump ahead the queued update if the conditions
> in drm_atomic_async_check() are met. That means we are only able to do an
> async update if no modeset is pending and update for the same plane is
> not queued.

First of all, thanks for the patch. Please see my comments below.

If the description above applies (and AFAICT that's what the existing
code does indeed), then this doesn't sound like "amend" to me. It
sounds exactly as the kernel code calls it - "async update" or perhaps
"instantaneous commit" could better describe it?

>
> It uses the already in place infrastructure for async updates.
>
> It is useful for cursor updates and async PageFlips over the atomic
> ioctl, otherwise in some cases updates may be delayed to the point the
> user will notice it. Note that for now it's only enabled for cursor
> planes.
>
> DRM_MODE_ATOMIC_AMEND should be passed to the Atomic IOCTL to use this
> feature.
>
> Signed-off-by: Gustavo Padovan 
> Signed-off-by: Enric Balletbo i Serra 
> [updated for upstream]
> Signed-off-by: Helen Koike 
> ---
> Hi,
>
> This is the second attempt to introduce the new ATOMIC_AMEND flag for atomic
> operations, see the commit message for a more detailed description.
>
> This was tested using a small program that exercises the uAPI for easy
> sanity testing. The program was created by Alexandros and modified by
> Enric to test the capability flag [2].
>
> To test, just build the program and use the --atomic flag to use the cursor
> plane with the ATOMIC_AMEND flag. E.g.
>
>   drm_cursor --atomic
>
> The test worked on a rockchip Ficus v1.1 board on top of mainline plus
> the patch to update cursors asynchronously through atomic for the
> drm/rockchip driver plus the DRM_CAP_ASYNC_UPDATE patch.
>
> Alexandros also did a proof-of-concept to use this flag and draw cursors
> using atomic if possible on ozone [1].
>
> Thanks
> Helen
>
> [1] https://chromium-review.googlesource.com/c/chromium/src/+/1092711
> [2] https://gitlab.collabora.com/eballetbo/drm-cursor/commits/async-capability
>
>
> Changes in v2:
> - rebase tree
> - do not fall back to a non-async update if if there isn't any
> pending commit to amend
>
> Changes in v1:
> - https://patchwork.freedesktop.org/patch/243088/
> - Only enable it if userspace requests it.
> - Only allow async update for cursor type planes.
> - Rename ASYNC_UPDATE for ATOMIC_AMEND.
>
>  drivers/gpu/drm/drm_atomic_helper.c | 6 +-
>  drivers/gpu/drm/drm_atomic_uapi.c   | 6 ++
>  include/uapi/drm/drm_mode.h | 4 +++-
>  3 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 269f1a74de38..333190c6a0a4 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -934,7 +934,7 @@ int drm_atomic_helper_check(struct drm_device *dev,
> if (ret)
> return ret;
>
> -   if (state->legacy_cursor_update)
> +   if (state->async_update || state->legacy_cursor_update)
> state->async_update = !drm_atomic_helper_async_check(dev, 
> state);
>
> return ret;
> @@ -1602,6 +1602,10 @@ int drm_atomic_helper_async_check(struct drm_device 
> *dev,
> if (new_plane_state->fence)
> return -EINVAL;
>
> +   /* Only allow async update for cursor type planes. */
> +   if (plane->type != DRM_PLANE_TYPE_CURSOR)
> +   return -EINVAL;
> +

So the existing upstream code already allowed this for any planes and
we're restricting this to cursor planes only. Is this expected? No
potential users that already started using this for other plane types?

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

[Bug 201273] Fatal error during GPU init amdgpu RX560

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=201273

--- Comment #19 from quirin.blae...@freenet.de ---
Created attachment 279983
  --> https://bugzilla.kernel.org/attachment.cgi?id=279983=edit
dmesg lsmod additional infos

Error message returned. v4.19.7 no patches
Archive contains dmesg and lsmod, both for error and normal startup.
It also contains some additional infos, e.g. describing changed behavior of my
monitor at bootup, Xorg.0.log (normal) and Xorg.0.log.old (error).

-- 
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: [Intel-gfx] [PATCH 2/4] drm/i915: Use drm_hdmi_avi_infoframe_quant_range() for SDVO HDMI as well

[Ville Syrjälä]

On Wed, Dec 12, 2018 at 04:32:02PM -0800, Dhinakaran Pandiyan wrote:
> On Tue, 2018-11-20 at 18:13 +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > Fill out the AVI infoframe quantization range bits using
> > drm_hdmi_avi_infoframe_quant_range() for SDVO HDMI encoder as well.
> > 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_sdvo.c | 19 ++-
> >  1 file changed, 10 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
> > b/drivers/gpu/drm/i915/intel_sdvo.c
> > index 1277d31adb54..9c16e273fb8d 100644
> > --- a/drivers/gpu/drm/i915/intel_sdvo.c
> > +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> > @@ -984,6 +984,8 @@ static bool intel_sdvo_set_avi_infoframe(struct
> > intel_sdvo *intel_sdvo,
> >  const struct intel_crtc_state
> > *pipe_config,
> >  const struct
> > drm_connector_state *conn_state)
> >  {
> > +   const struct drm_display_mode *adjusted_mode =
> > +   _config->base.adjusted_mode;
> > uint8_t sdvo_data[HDMI_INFOFRAME_SIZE(AVI)];
> > union hdmi_infoframe frame;
> > int ret;
> > @@ -991,20 +993,19 @@ static bool intel_sdvo_set_avi_infoframe(struct
> > intel_sdvo *intel_sdvo,
> >  
> > ret = drm_hdmi_avi_infoframe_from_display_mode(,
> >conn_state-
> > >connector,
> > -  _config-
> > >base.adjusted_mode);
> > +  adjusted_mode);
> > if (ret < 0) {
> > DRM_ERROR("couldn't fill AVI infoframe\n");
> > return false;
> > }
> >  
> > -   if (intel_sdvo->rgb_quant_range_selectable) {
> > -   if (pipe_config->limited_color_range)
> > -   frame.avi.quantization_range =
> > -   HDMI_QUANTIZATION_RANGE_LIMITED;
> > -   else
> > -   frame.avi.quantization_range =
> > -   HDMI_QUANTIZATION_RANGE_FULL;
> > -   }
> > +   drm_hdmi_avi_infoframe_quant_range(,
> > +  conn_state->connector,
> > +  adjusted_mode,
> > +  pipe_config-
> > >limited_color_range ?
> > +  rgb_quant_range_selectableTE
> > D :
> > +  HDMI_QUANTIZATION_RANGE_FULL
> > ,
> > +  intel_sdvo-
> > >rgb_quant_range_selectable);
> 
> Seems like avi.quantization_range can now get set to _LIMITED or _FULL
> even when ->rgb_quant_range_selectable == false, i.e., it is not
> _DEFAULT anymore. Is that change in behavior intended?

->quant_range_selectable will be passed to
drm_hdmi_avi_infoframe_quant_range() which will do the right thing with
it.

That said, there is a slight behavioural change in that it will set
the Q bit even with QS==1 iff the quantization range matches the
default quantization range for the mode. I noted this in the radeon
patch but forgot to mention it here.

> 
> 
> >  
> > len = hdmi_infoframe_pack(, sdvo_data,
> > sizeof(sdvo_data));
> > if (len < 0)

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH AUTOSEL 4.4 05/23] drm/msm: Grab a vblank reference when waiting for commit_done

[Sasha Levin]

From: Sean Paul 

[ Upstream commit 3b712e43e3876b42b38321ecf790a1f5fe59c834 ]

Similar to the atomic helpers, we should enable vblank while we're
waiting for the commit to finish. DPU needs this, MDP5 seems to work
fine without it.

Reviewed-by: Abhinav Kumar 
Signed-off-by: Sean Paul 
Signed-off-by: Rob Clark 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/msm/msm_atomic.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index 7eb253bc24df..221eaea651d4 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -107,7 +107,12 @@ static void msm_atomic_wait_for_commit_done(struct 
drm_device *dev,
if (old_state->legacy_cursor_update)
continue;
 
+   if (drm_crtc_vblank_get(crtc))
+   continue;
+
kms->funcs->wait_for_crtc_commit_done(kms, crtc);
+
+   drm_crtc_vblank_put(crtc);
}
 }
 
-- 
2.19.1

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

[PATCH AUTOSEL 4.9 28/34] drm/ast: Fix connector leak during driver unload

[Sasha Levin]

From: Sam Bobroff 

[ Upstream commit e594a5e349ddbfdaca1951bb3f8d72f3f1660d73 ]

When unloading the ast driver, a warning message is printed by
drm_mode_config_cleanup() because a reference is still held to one of
the drm_connector structs.

Correct this by calling drm_crtc_force_disable_all() in
ast_fbdev_destroy().

Signed-off-by: Sam Bobroff 
Reviewed-by: Daniel Vetter 
Signed-off-by: Dave Airlie 
Link: 
https://patchwork.freedesktop.org/patch/msgid/1e613f3c630c7bbc72e04a44b178259b9164d2f6.1543798395.git.sbobr...@linux.ibm.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/ast/ast_fb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
index 7a86e24e2687..5e0d3e561b04 100644
--- a/drivers/gpu/drm/ast/ast_fb.c
+++ b/drivers/gpu/drm/ast/ast_fb.c
@@ -286,6 +286,7 @@ static void ast_fbdev_destroy(struct drm_device *dev,
 {
struct ast_framebuffer *afb = >afb;
 
+   drm_crtc_force_disable_all(dev);
drm_fb_helper_unregister_fbi(>helper);
drm_fb_helper_release_fbi(>helper);
 
-- 
2.19.1

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

[PATCH AUTOSEL 4.9 05/34] drm/msm: Grab a vblank reference when waiting for commit_done

[Sasha Levin]

From: Sean Paul 

[ Upstream commit 3b712e43e3876b42b38321ecf790a1f5fe59c834 ]

Similar to the atomic helpers, we should enable vblank while we're
waiting for the commit to finish. DPU needs this, MDP5 seems to work
fine without it.

Reviewed-by: Abhinav Kumar 
Signed-off-by: Sean Paul 
Signed-off-by: Rob Clark 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/msm/msm_atomic.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index 73bae382eac3..5c58a98f67c0 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -98,7 +98,12 @@ static void msm_atomic_wait_for_commit_done(struct 
drm_device *dev,
if (old_state->legacy_cursor_update)
continue;
 
+   if (drm_crtc_vblank_get(crtc))
+   continue;
+
kms->funcs->wait_for_crtc_commit_done(kms, crtc);
+
+   drm_crtc_vblank_put(crtc);
}
 }
 
-- 
2.19.1

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

[PATCH AUTOSEL 4.14 32/41] drm/ast: Fix connector leak during driver unload

[Sasha Levin]

From: Sam Bobroff 

[ Upstream commit e594a5e349ddbfdaca1951bb3f8d72f3f1660d73 ]

When unloading the ast driver, a warning message is printed by
drm_mode_config_cleanup() because a reference is still held to one of
the drm_connector structs.

Correct this by calling drm_crtc_force_disable_all() in
ast_fbdev_destroy().

Signed-off-by: Sam Bobroff 
Reviewed-by: Daniel Vetter 
Signed-off-by: Dave Airlie 
Link: 
https://patchwork.freedesktop.org/patch/msgid/1e613f3c630c7bbc72e04a44b178259b9164d2f6.1543798395.git.sbobr...@linux.ibm.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/ast/ast_fb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
index 0cd827e11fa2..de26df0c6044 100644
--- a/drivers/gpu/drm/ast/ast_fb.c
+++ b/drivers/gpu/drm/ast/ast_fb.c
@@ -263,6 +263,7 @@ static void ast_fbdev_destroy(struct drm_device *dev,
 {
struct ast_framebuffer *afb = >afb;
 
+   drm_crtc_force_disable_all(dev);
drm_fb_helper_unregister_fbi(>helper);
 
if (afb->obj) {
-- 
2.19.1

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

[PATCH AUTOSEL 4.14 17/41] drm/msm: Fix error return checking

[Sasha Levin]

From: Wen Yang 

[ Upstream commit 098336deb946f37a70afc0979af388b615c378bf ]

The error checks on ret for a negative error return always fails because
the return value of iommu_map_sg() is unsigned and can never be negative.

Detected with Coccinelle:
drivers/gpu/drm/msm/msm_iommu.c:69:9-12: WARNING: Unsigned expression
compared with zero: ret < 0

Signed-off-by: Wen Yang 
CC: Rob Clark 
CC: David Airlie 
CC: Julia Lawall 
CC: linux-arm-...@vger.kernel.org
CC: dri-devel@lists.freedesktop.org
CC: freedr...@lists.freedesktop.org
CC: linux-ker...@vger.kernel.org
Signed-off-by: Sean Paul 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/msm/msm_iommu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
index b23d33622f37..2a90aa4caec0 100644
--- a/drivers/gpu/drm/msm/msm_iommu.c
+++ b/drivers/gpu/drm/msm/msm_iommu.c
@@ -66,7 +66,7 @@ static int msm_iommu_map(struct msm_mmu *mmu, uint64_t iova,
 // pm_runtime_get_sync(mmu->dev);
ret = iommu_map_sg(iommu->domain, iova, sgt->sgl, sgt->nents, prot);
 // pm_runtime_put_sync(mmu->dev);
-   WARN_ON(ret < 0);
+   WARN_ON(!ret);
 
return (ret == len) ? 0 : -EINVAL;
 }
-- 
2.19.1

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

[PATCH AUTOSEL 4.14 06/41] drm/msm: Grab a vblank reference when waiting for commit_done

[Sasha Levin]

From: Sean Paul 

[ Upstream commit 3b712e43e3876b42b38321ecf790a1f5fe59c834 ]

Similar to the atomic helpers, we should enable vblank while we're
waiting for the commit to finish. DPU needs this, MDP5 seems to work
fine without it.

Reviewed-by: Abhinav Kumar 
Signed-off-by: Sean Paul 
Signed-off-by: Rob Clark 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/msm/msm_atomic.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index 025d454163b0..8f77047a226d 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -93,7 +93,12 @@ static void msm_atomic_wait_for_commit_done(struct 
drm_device *dev,
if (!new_crtc_state->active)
continue;
 
+   if (drm_crtc_vblank_get(crtc))
+   continue;
+
kms->funcs->wait_for_crtc_commit_done(kms, crtc);
+
+   drm_crtc_vblank_put(crtc);
}
 }
 
-- 
2.19.1

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

[PATCH AUTOSEL 4.19 62/73] drm/ast: Fix connector leak during driver unload

[Sasha Levin]

From: Sam Bobroff 

[ Upstream commit e594a5e349ddbfdaca1951bb3f8d72f3f1660d73 ]

When unloading the ast driver, a warning message is printed by
drm_mode_config_cleanup() because a reference is still held to one of
the drm_connector structs.

Correct this by calling drm_crtc_force_disable_all() in
ast_fbdev_destroy().

Signed-off-by: Sam Bobroff 
Reviewed-by: Daniel Vetter 
Signed-off-by: Dave Airlie 
Link: 
https://patchwork.freedesktop.org/patch/msgid/1e613f3c630c7bbc72e04a44b178259b9164d2f6.1543798395.git.sbobr...@linux.ibm.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/ast/ast_fb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
index 0cd827e11fa2..de26df0c6044 100644
--- a/drivers/gpu/drm/ast/ast_fb.c
+++ b/drivers/gpu/drm/ast/ast_fb.c
@@ -263,6 +263,7 @@ static void ast_fbdev_destroy(struct drm_device *dev,
 {
struct ast_framebuffer *afb = >afb;
 
+   drm_crtc_force_disable_all(dev);
drm_fb_helper_unregister_fbi(>helper);
 
if (afb->obj) {
-- 
2.19.1

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

[PATCH AUTOSEL 4.19 59/73] drm/amdgpu/vcn: Update vcn.cur_state during suspend

[Sasha Levin]

From: James Zhu 

[ Upstream commit 0a9b89b2e2e7b6d90f81ddc47e489be1043e01b1 ]

Replace vcn_v1_0_stop with vcn_v1_0_set_powergating_state during suspend,
to keep adev->vcn.cur_state update. It will fix VCN S3 hung issue.

Signed-off-by: James Zhu 
Reviewed-by: Leo Liu 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c 
b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
index 072371ef5975..4f8f3bb21832 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
@@ -43,6 +43,7 @@ static void vcn_v1_0_set_enc_ring_funcs(struct amdgpu_device 
*adev);
 static void vcn_v1_0_set_jpeg_ring_funcs(struct amdgpu_device *adev);
 static void vcn_v1_0_set_irq_funcs(struct amdgpu_device *adev);
 static void vcn_v1_0_jpeg_ring_set_patch_ring(struct amdgpu_ring *ring, 
uint32_t ptr);
+static int vcn_v1_0_set_powergating_state(void *handle, enum 
amd_powergating_state state);
 
 /**
  * vcn_v1_0_early_init - set function pointers
@@ -216,7 +217,7 @@ static int vcn_v1_0_hw_fini(void *handle)
struct amdgpu_ring *ring = >vcn.ring_dec;
 
if (RREG32_SOC15(VCN, 0, mmUVD_STATUS))
-   vcn_v1_0_stop(adev);
+   vcn_v1_0_set_powergating_state(adev, AMD_PG_STATE_GATE);
 
ring->ready = false;
 
-- 
2.19.1

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

[PATCH AUTOSEL 4.19 36/73] drm/amd/powerplay: issue pre-display settings for display change event

[Sasha Levin]

From: Evan Quan 

[ Upstream commit 10cb3e6b63bf4266a5198813526fdd7259ffb8be ]

For display config change event only, pre-display config settings are
needed.

Signed-off-by: Evan Quan 
Acked-by: Alex Deucher 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c  | 3 +++
 drivers/gpu/drm/amd/powerplay/hwmgr/pp_psm.c | 2 --
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
index 8994aa5c8cf8..64596029b696 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
@@ -365,6 +365,9 @@ int hwmgr_handle_task(struct pp_hwmgr *hwmgr, enum 
amd_pp_task task_id,
 
switch (task_id) {
case AMD_PP_TASK_DISPLAY_CONFIG_CHANGE:
+   ret = phm_pre_display_configuration_changed(hwmgr);
+   if (ret)
+   return ret;
ret = phm_set_cpu_power_state(hwmgr);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/pp_psm.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/pp_psm.c
index 91ffb7bc4ee7..56437866d120 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/pp_psm.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/pp_psm.c
@@ -265,8 +265,6 @@ int psm_adjust_power_state_dynamic(struct pp_hwmgr *hwmgr, 
bool skip,
if (skip)
return 0;
 
-   phm_pre_display_configuration_changed(hwmgr);
-
phm_display_configuration_changed(hwmgr);
 
if (hwmgr->ps)
-- 
2.19.1

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

[PATCH AUTOSEL 4.19 35/73] drm/msm: Fix error return checking

[Sasha Levin]

From: Wen Yang 

[ Upstream commit 098336deb946f37a70afc0979af388b615c378bf ]

The error checks on ret for a negative error return always fails because
the return value of iommu_map_sg() is unsigned and can never be negative.

Detected with Coccinelle:
drivers/gpu/drm/msm/msm_iommu.c:69:9-12: WARNING: Unsigned expression
compared with zero: ret < 0

Signed-off-by: Wen Yang 
CC: Rob Clark 
CC: David Airlie 
CC: Julia Lawall 
CC: linux-arm-...@vger.kernel.org
CC: dri-devel@lists.freedesktop.org
CC: freedr...@lists.freedesktop.org
CC: linux-ker...@vger.kernel.org
Signed-off-by: Sean Paul 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/msm/msm_iommu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
index b23d33622f37..2a90aa4caec0 100644
--- a/drivers/gpu/drm/msm/msm_iommu.c
+++ b/drivers/gpu/drm/msm/msm_iommu.c
@@ -66,7 +66,7 @@ static int msm_iommu_map(struct msm_mmu *mmu, uint64_t iova,
 // pm_runtime_get_sync(mmu->dev);
ret = iommu_map_sg(iommu->domain, iova, sgt->sgl, sgt->nents, prot);
 // pm_runtime_put_sync(mmu->dev);
-   WARN_ON(ret < 0);
+   WARN_ON(!ret);
 
return (ret == len) ? 0 : -EINVAL;
 }
-- 
2.19.1

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

[PATCH AUTOSEL 4.19 32/73] drm/msm/hdmi: Enable HPD after HDMI IRQ is set up

[Sasha Levin]

From: Todor Tomov 

[ Upstream commit ee4456359640defe3f51cc6b728bfce4bc444c9e ]

SoCs that contain MDP5 have a top level wrapper called MDSS that
manages locks, power and irq for the sub-blocks within it.

Irq for HDMI is also routed through the MDSS.

Shortly after the Hot Plug Detection (HPD) is enabled in HDMI,
HDMI interrupts are recieved by the MDSS interrupt handler.
However at this moment the HDMI irq is still not mapped to
the MDSS irq domain so the HDMI irq handler cannot be called
to process the interrupts.

This leads to a flood of HDMI interrupts on CPU 0.

If we are lucky to have the HDMI initialization running on a
different CPU, it will eventually map the HDMI irq to MDSS irq
domain, the next HDMI interrupt will be handled by the HDMI irq
handler, the interrupt flood will stop and we will recover.

If the HDMI initialization is running on CPU 0, then it cannot
complete and there is nothing to stop the interrupt flood on
CPU 0. The system is stuck.

Fix this by moving the HPD enablement after the HDMI irq is
mapped to the MDSS irq domain.

Signed-off-by: Todor Tomov 
Signed-off-by: Rob Clark 
Signed-off-by: Sean Paul 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/msm/hdmi/hdmi.c   |  6 ++
 drivers/gpu/drm/msm/hdmi/hdmi.h   |  1 +
 drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 10 ++
 3 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index c79659ca5706..33e083f71a17 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -332,6 +332,12 @@ int msm_hdmi_modeset_init(struct hdmi *hdmi,
goto fail;
}
 
+   ret = msm_hdmi_hpd_enable(hdmi->connector);
+   if (ret < 0) {
+   DRM_DEV_ERROR(>pdev->dev, "failed to enable HPD: %d\n", 
ret);
+   goto fail;
+   }
+
encoder->bridge = hdmi->bridge;
 
priv->bridges[priv->num_bridges++]   = hdmi->bridge;
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.h b/drivers/gpu/drm/msm/hdmi/hdmi.h
index accc9a61611d..5c5df6ab2a57 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.h
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.h
@@ -245,6 +245,7 @@ void msm_hdmi_bridge_destroy(struct drm_bridge *bridge);
 
 void msm_hdmi_connector_irq(struct drm_connector *connector);
 struct drm_connector *msm_hdmi_connector_init(struct hdmi *hdmi);
+int msm_hdmi_hpd_enable(struct drm_connector *connector);
 
 /*
  * i2c adapter for ddc:
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c 
b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
index e9c9a0af508e..30e908dfded7 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
@@ -167,8 +167,9 @@ static void enable_hpd_clocks(struct hdmi *hdmi, bool 
enable)
}
 }
 
-static int hpd_enable(struct hdmi_connector *hdmi_connector)
+int msm_hdmi_hpd_enable(struct drm_connector *connector)
 {
+   struct hdmi_connector *hdmi_connector = to_hdmi_connector(connector);
struct hdmi *hdmi = hdmi_connector->hdmi;
const struct hdmi_platform_config *config = hdmi->config;
struct device *dev = >pdev->dev;
@@ -450,7 +451,6 @@ struct drm_connector *msm_hdmi_connector_init(struct hdmi 
*hdmi)
 {
struct drm_connector *connector = NULL;
struct hdmi_connector *hdmi_connector;
-   int ret;
 
hdmi_connector = kzalloc(sizeof(*hdmi_connector), GFP_KERNEL);
if (!hdmi_connector)
@@ -471,12 +471,6 @@ struct drm_connector *msm_hdmi_connector_init(struct hdmi 
*hdmi)
connector->interlace_allowed = 0;
connector->doublescan_allowed = 0;
 
-   ret = hpd_enable(hdmi_connector);
-   if (ret) {
-   dev_err(>pdev->dev, "failed to enable HPD: %d\n", ret);
-   return ERR_PTR(ret);
-   }
-
drm_connector_attach_encoder(connector, hdmi->encoder);
 
return connector;
-- 
2.19.1

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

[PATCH AUTOSEL 4.19 33/73] drm/msm: dpu: Don't set legacy plane->crtc pointer

[Sasha Levin]

From: Sean Paul 

[ Upstream commit 081679c51ef2fd7b23cf9ddb7d775b17f75de18c ]

It causes a WARN in drm_atomic_get_plane_state(), and is not used by
atomic (or dpu).

Signed-off-by: Sean Paul 
Reviewed-by: Daniel Vetter 
Signed-off-by: Rob Clark 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index cd02eae884cc..4752f08f0884 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -2122,7 +2122,6 @@ struct drm_crtc *dpu_crtc_init(struct drm_device *dev, 
struct drm_plane *plane)
NULL);
 
drm_crtc_helper_add(crtc, _crtc_helper_funcs);
-   plane->crtc = crtc;
 
/* save user friendly CRTC name for later */
snprintf(dpu_crtc->name, DPU_CRTC_NAME_SIZE, "crtc%u", crtc->base.id);
-- 
2.19.1

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

[PATCH AUTOSEL 4.19 34/73] drm/msm: dpu: Fix "WARNING: invalid free of devm_ allocated data"

[Sasha Levin]

From: YueHaibing 

[ Upstream commit ce25aa3ee6939d83979cccf7adc5737cba9a0cb7 ]

'dpu_enc' is a member of 'drm_enc'
And 'drm_enc' got allocated with devm_kzalloc in dpu_encoder_init.

This gives this error message:
./drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:459:1-6:
 WARNING: invalid free of devm_ allocated data

Signed-off-by: YueHaibing 
Signed-off-by: Rob Clark 
Signed-off-by: Sean Paul 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 1b4de3486ef9..ec3fd67378c1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -503,8 +503,6 @@ static void dpu_encoder_destroy(struct drm_encoder *drm_enc)
 
drm_encoder_cleanup(drm_enc);
mutex_destroy(_enc->enc_lock);
-
-   kfree(dpu_enc);
 }
 
 void dpu_encoder_helper_split_config(
-- 
2.19.1

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

[PATCH AUTOSEL 4.19 18/73] drm/amdgpu: wait for IB test on first device open

[Sasha Levin]

From: Christian König 

[ Upstream commit 3bfa8897e4d08f822d1d58cf6cbbffbccef82e08 ]

Instead of delaying that to the first query. Otherwise we could try to use the
SDMA for VM updates before the IB tests are done.

Signed-off-by: Christian König 
Reviewed-by: Chunming Zhou 
Reviewed-by: Junwei Zhang 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index bd98cc5fb97b..fd825d30edf1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -292,9 +292,6 @@ static int amdgpu_info_ioctl(struct drm_device *dev, void 
*data, struct drm_file
if (!info->return_size || !info->return_pointer)
return -EINVAL;
 
-   /* Ensure IB tests are run on ring */
-   flush_delayed_work(>late_init_work);
-
switch (info->query) {
case AMDGPU_INFO_ACCEL_WORKING:
ui32 = adev->accel_working;
@@ -861,6 +858,9 @@ int amdgpu_driver_open_kms(struct drm_device *dev, struct 
drm_file *file_priv)
struct amdgpu_fpriv *fpriv;
int r, pasid;
 
+   /* Ensure IB tests are run on ring */
+   flush_delayed_work(>late_init_work);
+
file_priv->driver_priv = NULL;
 
r = pm_runtime_get_sync(dev->dev);
-- 
2.19.1

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

[PATCH AUTOSEL 4.19 17/73] drm/ttm: fix LRU handling in ttm_buffer_object_transfer

[Sasha Levin]

From: Christian König 

[ Upstream commit d6e820fcd4cf08b11d291a1dd7bbd0636914647c ]

We need to set the NO_EVICT flag on the ghost object or otherwise we are
adding it to the LRU.

When it is added to the LRU we can run into a race between destroying
and evicting it again.

Signed-off-by: Christian König 
Acked-by: Alex Deucher 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/ttm/ttm_bo_util.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 046a6dda690a..40904e84f883 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -492,8 +492,10 @@ static int ttm_buffer_object_transfer(struct 
ttm_buffer_object *bo,
if (!fbo)
return -ENOMEM;
 
-   ttm_bo_get(bo);
fbo->base = *bo;
+   fbo->base.mem.placement |= TTM_PL_FLAG_NO_EVICT;
+
+   ttm_bo_get(bo);
fbo->bo = bo;
 
/**
-- 
2.19.1

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

[PATCH AUTOSEL 4.19 14/73] drm/msm: fix handling of cmdstream offset

[Sasha Levin]

From: Rob Clark 

[ Upstream commit 47e7f506ee6590ceb2efa1f08aca7f9f2ee5c1d3 ]

Userspace hasn't used submit cmds with submit_offset != 0 for a while,
but this starts cropping up again with cmdstream sub-buffer-allocation
in libdrm_freedreno.

Doesn't do much good to increment the buf ptr before assigning it.

Fixes: 78b8e5b847b4 drm/msm: dump a rd GPUADDR header for all buffers in the 
command
Reviewed-by: Kristian H. Kristensen 
Signed-off-by: Rob Clark 
Signed-off-by: Sean Paul 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/msm/msm_rd.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/msm_rd.c b/drivers/gpu/drm/msm/msm_rd.c
index 3aa8a8576abe..f7a0edea4705 100644
--- a/drivers/gpu/drm/msm/msm_rd.c
+++ b/drivers/gpu/drm/msm/msm_rd.c
@@ -316,10 +316,11 @@ static void snapshot_buf(struct msm_rd_state *rd,
uint64_t iova, uint32_t size)
 {
struct msm_gem_object *obj = submit->bos[idx].obj;
+   unsigned offset = 0;
const char *buf;
 
if (iova) {
-   buf += iova - submit->bos[idx].iova;
+   offset = iova - submit->bos[idx].iova;
} else {
iova = submit->bos[idx].iova;
size = obj->base.size;
@@ -340,6 +341,8 @@ static void snapshot_buf(struct msm_rd_state *rd,
if (IS_ERR(buf))
return;
 
+   buf += offset;
+
rd_write_section(rd, RD_BUFFER_CONTENTS, buf, size);
 
msm_gem_put_vaddr(>base);
-- 
2.19.1

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

[PATCH AUTOSEL 4.19 16/73] drm/msm: Grab a vblank reference when waiting for commit_done

[Sasha Levin]

From: Sean Paul 

[ Upstream commit 3b712e43e3876b42b38321ecf790a1f5fe59c834 ]

Similar to the atomic helpers, we should enable vblank while we're
waiting for the commit to finish. DPU needs this, MDP5 seems to work
fine without it.

Reviewed-by: Abhinav Kumar 
Signed-off-by: Sean Paul 
Signed-off-by: Rob Clark 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/msm/msm_atomic.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index c1f1779c980f..2b7bb6e166d3 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -32,7 +32,12 @@ static void msm_atomic_wait_for_commit_done(struct 
drm_device *dev,
if (!new_crtc_state->active)
continue;
 
+   if (drm_crtc_vblank_get(crtc))
+   continue;
+
kms->funcs->wait_for_crtc_commit_done(kms, crtc);
+
+   drm_crtc_vblank_put(crtc);
}
 }
 
-- 
2.19.1

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

[PATCH AUTOSEL 4.19 10/73] drm/amd/display: Fix 6x4K displays light-up on Vega20 (v2)

[Sasha Levin]

From: Roman Li 

[ Upstream commit c679fd55b1ba903c2a770127edbf6aef6f27 ]

[Why]
More than 4x4K didn't lightup on Vega20 due to low dcfclk value.
Powerplay expects valid min requirement for dcfclk from DC.

[How]
Update min_dcfclock_khz based on min_engine_clock value.

v2: backport to 4.20 (Alex)

Reviewed-by: Hersen Wu 
Reviewed-by: Feifei Xu 
Reviewed-by: Evan Quan 
Acked-by: Alex Deucher 
Signed-off-by: Roman Li 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c 
b/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
index b2f308766a9e..0941f3c689bc 100644
--- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
@@ -2530,6 +2530,8 @@ static void pplib_apply_display_requirements(
dc,
context->bw.dce.sclk_khz);
 
+   pp_display_cfg->min_dcfclock_khz = pp_display_cfg->min_engine_clock_khz;
+
pp_display_cfg->min_engine_clock_deep_sleep_khz
= context->bw.dce.sclk_deep_sleep_khz;
 
-- 
2.19.1

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

[PATCH AUTOSEL 4.19 15/73] drm/msm/dsi: configure VCO rate for 10nm PLL driver

[Sasha Levin]

From: Abhinav Kumar 

[ Upstream commit 8531f0587f5c9e1a74cd9543a97617349f5e0706 ]

Currenty the VCO rate in the 10nm PLL driver relies
on the parent rate which is not configured.

Configure the VCO rate to 19.2 Mhz as required by
the 10nm PLL driver.

Signed-off-by: Abhinav Kumar 
Signed-off-by: Sean Paul 
Signed-off-by: Rob Clark 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c 
b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
index 4c03f0b7343e..41bec570c518 100644
--- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
+++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
@@ -39,6 +39,8 @@
 #define DSI_PIXEL_PLL_CLK  1
 #define NUM_PROVIDED_CLKS  2
 
+#define VCO_REF_CLK_RATE   1920
+
 struct dsi_pll_regs {
u32 pll_prop_gain_rate;
u32 pll_lockdet_rate;
@@ -316,7 +318,7 @@ static int dsi_pll_10nm_vco_set_rate(struct clk_hw *hw, 
unsigned long rate,
parent_rate);
 
pll_10nm->vco_current_rate = rate;
-   pll_10nm->vco_ref_clk_rate = parent_rate;
+   pll_10nm->vco_ref_clk_rate = VCO_REF_CLK_RATE;
 
dsi_pll_setup_config(pll_10nm);
 
-- 
2.19.1

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

[PATCH AUTOSEL 4.19 13/73] drm/msm/gpu: Fix a couple memory leaks in debugfs

[Sasha Levin]

From: Dan Carpenter 

[ Upstream commit 51270de91412b819f654b849db3bf92dac0a0855 ]

The msm_gpu_open() function should free "show_priv" on error or it
causes static checker warnings.

Fixes: 4f776f4511c7 ("drm/msm/gpu: Convert the GPU show function to use the GPU 
state")
Signed-off-by: Dan Carpenter 
Signed-off-by: Rob Clark 
Signed-off-by: Sean Paul 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/msm/msm_debugfs.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_debugfs.c 
b/drivers/gpu/drm/msm/msm_debugfs.c
index f0da0d3c8a80..d756436c1fcd 100644
--- a/drivers/gpu/drm/msm/msm_debugfs.c
+++ b/drivers/gpu/drm/msm/msm_debugfs.c
@@ -84,7 +84,7 @@ static int msm_gpu_open(struct inode *inode, struct file 
*file)
 
ret = mutex_lock_interruptible(>struct_mutex);
if (ret)
-   return ret;
+   goto free_priv;
 
pm_runtime_get_sync(>pdev->dev);
show_priv->state = gpu->funcs->gpu_state_get(gpu);
@@ -94,13 +94,20 @@ static int msm_gpu_open(struct inode *inode, struct file 
*file)
 
if (IS_ERR(show_priv->state)) {
ret = PTR_ERR(show_priv->state);
-   kfree(show_priv);
-   return ret;
+   goto free_priv;
}
 
show_priv->dev = dev;
 
-   return single_open(file, msm_gpu_show, show_priv);
+   ret = single_open(file, msm_gpu_show, show_priv);
+   if (ret)
+   goto free_priv;
+
+   return 0;
+
+free_priv:
+   kfree(show_priv);
+   return ret;
 }
 
 static const struct file_operations msm_gpu_fops = {
-- 
2.19.1

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

[PATCH AUTOSEL 4.19 12/73] drm/msm: Fix task dump in gpu recovery

[Sasha Levin]

From: Sharat Masetty 

[ Upstream commit 482f96324a4e08818db7d75bb12beaaea6c9561d ]

The current recovery code gets a pointer to the task struct and does a
few things all within the rcu_read_lock. This puts constraints on the
types of gfp flags that can be used within the rcu lock. This patch
instead gets a reference to the task within the rcu lock and releases
the lock immediately, this way the task stays afloat until we need it and
we also get to use the desired gfp flags.

Signed-off-by: Sharat Masetty 
Signed-off-by: Rob Clark 
Signed-off-by: Sean Paul 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/msm/msm_gpu.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 46e6b82f7b66..52a2146dc1f2 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -425,10 +425,9 @@ static void recover_worker(struct work_struct *work)
if (submit) {
struct task_struct *task;
 
-   rcu_read_lock();
-   task = pid_task(submit->pid, PIDTYPE_PID);
+   task = get_pid_task(submit->pid, PIDTYPE_PID);
if (task) {
-   comm = kstrdup(task->comm, GFP_ATOMIC);
+   comm = kstrdup(task->comm, GFP_KERNEL);
 
/*
 * So slightly annoying, in other paths like
@@ -441,10 +440,10 @@ static void recover_worker(struct work_struct *work)
 * about the submit going away.
 */
mutex_unlock(>struct_mutex);
-   cmd = kstrdup_quotable_cmdline(task, GFP_ATOMIC);
+   cmd = kstrdup_quotable_cmdline(task, GFP_KERNEL);
+   put_task_struct(task);
mutex_lock(>struct_mutex);
}
-   rcu_read_unlock();
 
if (comm && cmd) {
dev_err(dev->dev, "%s: offending task: %s (%s)\n",
-- 
2.19.1

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

[PATCH v9 33/39] misc/mei/hdcp: Enabling the HDCP authentication

[Ramalingam C]

Request to ME to configure a port as authenticated.

On Success, ME FW will mark the port as authenticated and provides
HDCP cipher with the encryption keys.

Enabling the Authentication can be requested once all stages of
HDCP2.2 authentication is completed by interacting with ME FW.

Only after this stage, driver can enable the HDCP encryption for
the port, through HW registers.

v2: Rebased.
v3:
  cldev is passed as first parameter [Tomas]
  Redundant comments and cast are removed [Tomas]
v4:
  %zd for ssize_t [Alexander]
  %s/return -1/return -EIO [Alexander]
  Style and typos fixed [Uma]
v5: Rebased.
v6:
  Collected the Rb-ed by.
  Rebased.
v7:
  Adjust to the new mei interface.
  Fix for Kdoc.
v8:
  K-Doc addition. [Tomas]

Signed-off-by: Ramalingam C 
Reviewed-by: Uma Shankar 
---
 drivers/misc/mei/hdcp/mei_hdcp.c | 54 +++-
 1 file changed, 53 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 9f24a66e3260..9569a5b85fd0 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -586,6 +586,58 @@ static int mei_verify_mprime(struct device *dev, struct 
hdcp_port_data *data,
return 0;
 }
 
+/**
+ * mei_enable_hdcp_authentication() - Mark a port as authenticated through ME 
FW
+ * @dev: device corresponding to the mei_cl_device
+ * @hdcp_data: Intel HW specific hdcp data
+ *
+ * Return: 0 on Success, <0 on Failure
+ */
+static int
+mei_enable_hdcp_authentication(struct device *dev, struct hdcp_port_data *data)
+{
+   struct wired_cmd_enable_auth_in enable_auth_in = { { 0 } };
+   struct wired_cmd_enable_auth_out enable_auth_out = { { 0 } };
+   struct mei_cl_device *cldev;
+   ssize_t byte;
+
+   if (!dev || !data)
+   return -EINVAL;
+
+   cldev = to_mei_cl_device(dev);
+
+   enable_auth_in.header.api_version = HDCP_API_VERSION;
+   enable_auth_in.header.command_id = WIRED_ENABLE_AUTH;
+   enable_auth_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   enable_auth_in.header.buffer_len = WIRED_CMD_BUF_LEN_ENABLE_AUTH_IN;
+
+   enable_auth_in.port.integrated_port_type = data->port_type;
+   enable_auth_in.port.physical_port = (u8)GET_MEI_DDI_INDEX(data->port);
+   enable_auth_in.stream_type = data->streams[0].stream_type;
+
+   byte = mei_cldev_send(cldev, (u8 *)_auth_in,
+ sizeof(enable_auth_in));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+   return byte;
+   }
+
+   byte = mei_cldev_recv(cldev, (u8 *)_auth_out,
+ sizeof(enable_auth_out));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
+   return byte;
+   }
+
+   if (enable_auth_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+   dev_dbg(dev, "ME cmd 0x%08X failed. status: 0x%X\n",
+   WIRED_ENABLE_AUTH, enable_auth_out.header.status);
+   return -EIO;
+   }
+
+   return 0;
+}
+
 static __attribute__((unused))
 struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
@@ -598,7 +650,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
.get_session_key = mei_get_session_key,
.repeater_check_flow_prepare_ack = mei_repeater_check_flow_prepare_ack,
.verify_mprime = mei_verify_mprime,
-   .enable_hdcp_authentication = NULL,
+   .enable_hdcp_authentication = mei_enable_hdcp_authentication,
.close_hdcp_session = NULL,
 };
 
-- 
2.7.4

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

[PATCH v9 34/39] misc/mei/hdcp: Closing wired HDCP2.2 Tx Session

[Ramalingam C]

Request the ME to terminate the HDCP2.2 session for a port.

On Success, ME FW will mark the intel port as Deauthenticated and
terminate the wired HDCP2.2 Tx session started due to the cmd
WIRED_INITIATE_HDCP2_SESSION.

v2: Rebased.
v3:
  cldev is passed as first parameter [Tomas]
  Redundant comments and cast are removed [Tomas]
v4:
  %zd for ssize_t [Alexander]
  %s/return -1/return -EIO [Alexander]
  Style and typos fixed [Uma]
v5:
  Extra line is removed.
v6:
  Collected the Rb-ed by.
  Rebased.
v7:
  Adjust to the new mei interface.
  Fix for Kdoc.
v8:
  K-Doc addition.[Tomas]

Signed-off-by: Ramalingam C 
Reviewed-by: Uma Shankar 
---
 drivers/misc/mei/hdcp/mei_hdcp.c | 55 +++-
 1 file changed, 54 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 9569a5b85fd0..b22a71e8c5d7 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -638,6 +638,59 @@ mei_enable_hdcp_authentication(struct device *dev, struct 
hdcp_port_data *data)
return 0;
 }
 
+/**
+ * mei_close_hdcp_session() - Close the Wired HDCP Tx session of ME FW per 
port.
+ * This also disables the authenticated state of the port.
+ * @dev: device corresponding to the mei_cl_device
+ * @hdcp_data: Intel HW specific hdcp data
+ *
+ * Return: 0 on Success, <0 on Failure
+ */
+static int
+mei_close_hdcp_session(struct device *dev, struct hdcp_port_data *data)
+{
+   struct wired_cmd_close_session_in session_close_in = { { 0 } };
+   struct wired_cmd_close_session_out session_close_out = { { 0 } };
+   struct mei_cl_device *cldev;
+   ssize_t byte;
+
+   if (!dev || !data)
+   return -EINVAL;
+
+   cldev = to_mei_cl_device(dev);
+
+   session_close_in.header.api_version = HDCP_API_VERSION;
+   session_close_in.header.command_id = WIRED_CLOSE_SESSION;
+   session_close_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   session_close_in.header.buffer_len =
+   WIRED_CMD_BUF_LEN_CLOSE_SESSION_IN;
+
+   session_close_in.port.integrated_port_type = data->port_type;
+   session_close_in.port.physical_port = (u8)GET_MEI_DDI_INDEX(data->port);
+
+   byte = mei_cldev_send(cldev, (u8 *)_close_in,
+ sizeof(session_close_in));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+   return byte;
+   }
+
+   byte = mei_cldev_recv(cldev, (u8 *)_close_out,
+ sizeof(session_close_out));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
+   return byte;
+   }
+
+   if (session_close_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+   dev_dbg(dev, "Session Close Failed. status: 0x%X\n",
+   session_close_out.header.status);
+   return -EIO;
+   }
+
+   return 0;
+}
+
 static __attribute__((unused))
 struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
@@ -651,7 +704,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
.repeater_check_flow_prepare_ack = mei_repeater_check_flow_prepare_ack,
.verify_mprime = mei_verify_mprime,
.enable_hdcp_authentication = mei_enable_hdcp_authentication,
-   .close_hdcp_session = NULL,
+   .close_hdcp_session = mei_close_hdcp_session,
 };
 
 static int mei_hdcp_probe(struct mei_cl_device *cldev,
-- 
2.7.4

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

[PATCH v9 24/39] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session

[Ramalingam C]

Request ME FW to start the HDCP2.2 session for an intel port.
Prepares payloads for command WIRED_INITIATE_HDCP2_SESSION and sends
to ME FW.

On Success, ME FW will start a HDCP2.2 session for the port and
provides the content for HDCP2.2 AKE_Init message.

v2: Rebased.
v3:
  cldev is add as a separate parameter [Tomas]
  Redundant comment and typecast are removed [Tomas]
v4:
  %zd is used for size [Alexander]
  %s/return -1/return -EIO [Alexander]
  Spellings in commit msg is fixed [Uma]
v5: Rebased.
v6:
  Collected the rb-ed by.
  Realigning the patches in the series.
v7:
  Adjust to the new mei interface.
  Fix for kdoc.
v8:
  K-Doc Addition.
  memcpy for const length.

Signed-off-by: Ramalingam C 
Reviewed-by: Uma Shankar 
---
 drivers/misc/mei/hdcp/mei_hdcp.c | 81 
 drivers/misc/mei/hdcp/mei_hdcp.h | 28 ++
 2 files changed, 109 insertions(+)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 6e7101512842..124f02e2b7c4 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -23,6 +23,87 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+
+#include "mei_hdcp.h"
+
+/**
+ * mei_initiate_hdcp2_session() - Initiate a Wired HDCP2.2 Tx Session in ME FW
+ * @dev: device corresponding to the mei_cl_device
+ * @hdcp_data: Intel HW specific hdcp data
+ * @ake_data: AKE_Init msg output.
+ *
+ * Return:  0 on Success, <0 on Failure.
+ */
+static int
+mei_initiate_hdcp2_session(struct device *dev, struct hdcp_port_data *data,
+  struct hdcp2_ake_init *ake_data)
+{
+   struct wired_cmd_initiate_hdcp2_session_in session_init_in = { { 0 } };
+   struct wired_cmd_initiate_hdcp2_session_out
+   session_init_out = { { 0 } };
+   struct mei_cl_device *cldev;
+   ssize_t byte;
+
+   if (!dev || !data || !ake_data)
+   return -EINVAL;
+
+   cldev = to_mei_cl_device(dev);
+
+   session_init_in.header.api_version = HDCP_API_VERSION;
+   session_init_in.header.command_id = WIRED_INITIATE_HDCP2_SESSION;
+   session_init_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   session_init_in.header.buffer_len =
+   WIRED_CMD_BUF_LEN_INITIATE_HDCP2_SESSION_IN;
+
+   session_init_in.port.integrated_port_type = data->port_type;
+   session_init_in.port.physical_port = (u8)GET_MEI_DDI_INDEX(data->port);
+   session_init_in.protocol = data->protocol;
+
+   byte = mei_cldev_send(cldev, (u8 *)_init_in,
+ sizeof(session_init_in));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+   return byte;
+   }
+
+   byte = mei_cldev_recv(cldev, (u8 *)_init_out,
+ sizeof(session_init_out));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
+   return byte;
+   }
+
+   if (session_init_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+   dev_dbg(dev, "ME cmd 0x%08X Failed. Status: 0x%X\n",
+   WIRED_INITIATE_HDCP2_SESSION,
+   session_init_out.header.status);
+   return -EIO;
+   }
+
+   ake_data->msg_id = HDCP_2_2_AKE_INIT;
+   ake_data->tx_caps = session_init_out.tx_caps;
+   memcpy(ake_data->r_tx, session_init_out.r_tx, HDCP_2_2_RTX_LEN);
+
+   return 0;
+}
+
+static __attribute__((unused))
+struct i915_hdcp_component_ops mei_hdcp_ops = {
+   .owner = THIS_MODULE,
+   .initiate_hdcp2_session = mei_initiate_hdcp2_session,
+   .verify_receiver_cert_prepare_km = NULL,
+   .verify_hprime = NULL,
+   .store_pairing_info = NULL,
+   .initiate_locality_check = NULL,
+   .verify_lprime = NULL,
+   .get_session_key = NULL,
+   .repeater_check_flow_prepare_ack = NULL,
+   .verify_mprime = NULL,
+   .enable_hdcp_authentication = NULL,
+   .close_hdcp_session = NULL,
+};
 
 static int mei_hdcp_probe(struct mei_cl_device *cldev,
  const struct mei_cl_device_id *id)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.h b/drivers/misc/mei/hdcp/mei_hdcp.h
index d1456e3dbf22..cac1a525476d 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.h
+++ b/drivers/misc/mei/hdcp/mei_hdcp.h
@@ -363,4 +363,32 @@ struct wired_cmd_repeater_auth_stream_req_out {
struct hdcp_port_id port;
 } __packed;
 
+enum mei_hdcp_ddi {
+   MEI_DDI_INVALID_PORT = 0x0,
+
+   MEI_DDI_B = 1,
+   MEI_DDI_C,
+   MEI_DDI_D,
+   MEI_DDI_E,
+   MEI_DDI_F,
+   MEI_DDI_A = 7,
+   MEI_DDI_RANGE_END = MEI_DDI_A,
+};
+
+enum i915_port {
+   PORT_NONE = -1,
+
+   PORT_A = 0,
+   PORT_B,
+   PORT_C,
+   PORT_D,
+   PORT_E,
+   PORT_F,
+   I915_MAX_PORTS,
+};
+
+#define GET_MEI_DDI_INDEX(p) ({

[PATCH v9 28/39] misc/mei/hdcp: Initiate Locality check

[Ramalingam C]

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

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

v2: Rebased.
v3:
  cldev is passed as first parameter [Tomas]
  Redundant comments and cast are removed [Tomas]
v4:
  %zd used for ssize_t [Alexander]
  %s/return -1/return -EIO [Alexander]
  Style fixed [Uma]
v5: Rebased.
v6:
  Collected the Rb-ed by.
  Rebasing.
v7:
  Adjust to the new mei interface.
  Fix for Kdoc.
v8:
  K-Doc addition. [Tomas]

Signed-off-by: Ramalingam C 
Reviewed-by: Uma Shankar 
---
 drivers/misc/mei/hdcp/mei_hdcp.c | 56 +++-
 1 file changed, 55 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 809d6270b6c1..db1492f64d6b 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -281,6 +281,60 @@ mei_store_pairing_info(struct device *dev, struct 
hdcp_port_data *data,
return 0;
 }
 
+/**
+ * mei_initiate_locality_check() - Prepare LC_Init
+ * @dev: device corresponding to the mei_cl_device
+ * @hdcp_data: Intel HW specific hdcp data
+ * @lc_init_data: LC_Init msg output
+ *
+ * Return: 0 on Success, <0 on Failure
+ */
+static int
+mei_initiate_locality_check(struct device *dev, struct hdcp_port_data *data,
+   struct hdcp2_lc_init *lc_init_data)
+{
+   struct wired_cmd_init_locality_check_in lc_init_in = { { 0 } };
+   struct wired_cmd_init_locality_check_out lc_init_out = { { 0 } };
+   struct mei_cl_device *cldev;
+   ssize_t byte;
+
+   if (!dev || !data || !lc_init_data)
+   return -EINVAL;
+
+   cldev = to_mei_cl_device(dev);
+
+   lc_init_in.header.api_version = HDCP_API_VERSION;
+   lc_init_in.header.command_id = WIRED_INIT_LOCALITY_CHECK;
+   lc_init_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   lc_init_in.header.buffer_len = WIRED_CMD_BUF_LEN_INIT_LOCALITY_CHECK_IN;
+
+   lc_init_in.port.integrated_port_type = data->port_type;
+   lc_init_in.port.physical_port = (u8)GET_MEI_DDI_INDEX(data->port);
+
+   byte = mei_cldev_send(cldev, (u8 *)_init_in, sizeof(lc_init_in));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+   return byte;
+   }
+
+   byte = mei_cldev_recv(cldev, (u8 *)_init_out, sizeof(lc_init_out));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
+   return byte;
+   }
+
+   if (lc_init_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+   dev_dbg(dev, "ME cmd 0x%08X Failed. status: 0x%X\n",
+   WIRED_INIT_LOCALITY_CHECK, lc_init_out.header.status);
+   return -EIO;
+   }
+
+   lc_init_data->msg_id = HDCP_2_2_LC_INIT;
+   memcpy(lc_init_data->r_n, lc_init_out.r_n, HDCP_2_2_RN_LEN);
+
+   return 0;
+}
+
 static __attribute__((unused))
 struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
@@ -288,7 +342,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
.verify_receiver_cert_prepare_km = mei_verify_receiver_cert_prepare_km,
.verify_hprime = mei_verify_hprime,
.store_pairing_info = mei_store_pairing_info,
-   .initiate_locality_check = NULL,
+   .initiate_locality_check = mei_initiate_locality_check,
.verify_lprime = NULL,
.get_session_key = NULL,
.repeater_check_flow_prepare_ack = NULL,
-- 
2.7.4

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

[PATCH v9 37/39] drm/i915: Fix KBL HDCP2.2 encrypt status signalling

[Ramalingam C]

Implement the required WA sequence for KBL to fix the
incorrect positioning of the window of oppurtunity and enc_en
signalling.

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 42327ed30903..2b9e1b6d0b1e 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "intel_drv.h"
 #include "i915_reg.h"
@@ -20,6 +21,27 @@
 #define ENCRYPT_STATUS_CHANGE_TIMEOUT_MS   50
 #define HDCP2_LC_RETRY_CNT 3
 
+static void kbl_repositioning_enc_en_signal(struct intel_connector *connector)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+   struct intel_hdcp *hdcp = >hdcp;
+   struct drm_crtc *crtc = connector->base.state->crtc;
+   struct intel_crtc *intel_crtc = container_of(crtc,
+struct intel_crtc, base);
+   u32 scanline;
+
+   for (;;) {
+   scanline = I915_READ(PIPEDSL(intel_crtc->pipe));
+   if (scanline > 100 && scanline < 200)
+   break;
+   usleep_range(25, 50);
+   }
+
+   hdcp->shim->toggle_signalling(intel_dig_port, false);
+   hdcp->shim->toggle_signalling(intel_dig_port, true);
+}
+
 static
 bool intel_hdcp_is_ksv_valid(u8 *ksv)
 {
@@ -1382,6 +1404,13 @@ static int hdcp2_enable_encryption(struct 
intel_connector *connector)
}
 
if (I915_READ(HDCP2_STATUS_DDI(port)) & LINK_AUTH_STATUS) {
+   /*
+* WA: To fix incorrect positioning of the window of
+* opportunity and enc_en signalling in KABYLAKE.
+*/
+   if (IS_KABYLAKE(dev_priv) && hdcp->shim->toggle_signalling)
+   kbl_repositioning_enc_en_signal(connector);
+
/* Link is Authenticated. Now set for Encryption */
I915_WRITE(HDCP2_CTL_DDI(port),
   I915_READ(HDCP2_CTL_DDI(port)) |
-- 
2.7.4

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

[PATCH v9 39/39] FOR_TESTING_ONLY: debugfs: Excluding the LSPCon for HDCP1.4

[Ramalingam C]

Just excluding the LSPCon HDMI ports from the HDCP1.4 testing.

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 40a61ef9aac1..c4badca83523 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -5076,6 +5076,9 @@ static int i915_hdcp_sink_capability_show(struct seq_file 
*m, void *data)
 {
struct drm_connector *connector = m->private;
struct intel_connector *intel_connector = to_intel_connector(connector);
+   struct intel_digital_port *intel_dig_port =
+   conn_to_dig_port(intel_connector);
+   bool is_hdcp14;
 
if (connector->status != connector_status_connected)
return -ENODEV;
@@ -5086,8 +5089,11 @@ static int i915_hdcp_sink_capability_show(struct 
seq_file *m, void *data)
 
seq_printf(m, "%s:%d HDCP version: ", connector->name,
   connector->base.id);
-   seq_printf(m, "%s ", !intel_hdcp_capable(intel_connector) ?
-  "None" : "HDCP1.4");
+
+   /* Excluding the Lspcon for Testing Purpose */
+   is_hdcp14 = intel_hdcp_capable(intel_connector) &&
+   !intel_dig_port->lspcon.active;
+   seq_printf(m, "%s ", !is_hdcp14 ? "None" : "HDCP1.4");
seq_puts(m, "\n");
 
return 0;
-- 
2.7.4

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

[PATCH v9 21/39] mei: bus: export to_mei_cl_device for mei client device drivers

[Ramalingam C]

From: Tomas Winkler 

Export to_mei_cl_device macro, it is needed also in mei client drivers.

Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/bus.c | 1 -
 include/linux/mei_cl_bus.h | 2 ++
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index fc3872fe7b25..e5456faf00e6 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -28,7 +28,6 @@
 #include "client.h"
 
 #define to_mei_cl_driver(d) container_of(d, struct mei_cl_driver, driver)
-#define to_mei_cl_device(d) container_of(d, struct mei_cl_device, dev)
 
 /**
  * __mei_cl_send - internal client send (write)
diff --git a/include/linux/mei_cl_bus.h b/include/linux/mei_cl_bus.h
index 7fde40e17c8b..03b6ba2a63f8 100644
--- a/include/linux/mei_cl_bus.h
+++ b/include/linux/mei_cl_bus.h
@@ -55,6 +55,8 @@ struct mei_cl_device {
void *priv_data;
 };
 
+#define to_mei_cl_device(d) container_of(d, struct mei_cl_device, dev)
+
 struct mei_cl_driver {
struct device_driver driver;
const char *name;
-- 
2.7.4

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

[PATCH v9 32/39] misc/mei/hdcp: Verify M_prime

[Ramalingam C]

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

ME FW will calculate the M and compare with M_prime received
as part of RepeaterAuth_Stream_Ready, which is HDCP2.2 protocol msg.

On successful completion of this stage, downstream propagation of
the stream management info is completed.

v2: Rebased.
v3:
  cldev is passed as first parameter [Tomas]
  Redundant comments and cast are removed [Tomas]
v4:
  %zd for ssize_t [Alexander]
  %s/return -1/return -EIO [Alexander]
  endianness conversion func is moved to drm_hdcp.h [Uma]
v5: Rebased.
v6:
  Collected the Rb-ed by.
  Rebasing.
v7:
  Adjust to the new mei interface.
  Fix for Kdoc.
v8:
  K-Doc addition. [Tomas]
  drm_hdcp2_u32_to_seq_num() is used for u32 to seq_num.

Signed-off-by: Ramalingam C 
Reviewed-by: Uma Shankar 
---
 drivers/misc/mei/hdcp/mei_hdcp.c | 66 +++-
 1 file changed, 65 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index b8c039107d0f..9f24a66e3260 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -522,6 +522,70 @@ mei_repeater_check_flow_prepare_ack(struct device *dev,
return 0;
 }
 
+/**
+ * mei_verify_mprime() - Verify mprime.
+ * @dev: device corresponding to the mei_cl_device
+ * @hdcp_data: Intel HW specific hdcp data
+ * @stream_ready: RepeaterAuth_Stream_Ready msg for ME FW verification.
+ *
+ * Return: 0 on Success, <0 on Failure
+ */
+static int mei_verify_mprime(struct device *dev, struct hdcp_port_data *data,
+struct hdcp2_rep_stream_ready *stream_ready)
+{
+   struct wired_cmd_repeater_auth_stream_req_in
+   verify_mprime_in = { { 0 } };
+   struct wired_cmd_repeater_auth_stream_req_out
+   verify_mprime_out = { { 0 } };
+   struct mei_cl_device *cldev;
+   ssize_t byte;
+
+   if (!dev || !stream_ready || !data)
+   return -EINVAL;
+
+   cldev = to_mei_cl_device(dev);
+
+   verify_mprime_in.header.api_version = HDCP_API_VERSION;
+   verify_mprime_in.header.command_id = WIRED_REPEATER_AUTH_STREAM_REQ;
+   verify_mprime_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   verify_mprime_in.header.buffer_len =
+   WIRED_CMD_BUF_LEN_REPEATER_AUTH_STREAM_REQ_MIN_IN;
+
+   verify_mprime_in.port.integrated_port_type = data->port_type;
+   verify_mprime_in.port.physical_port = (u8)GET_MEI_DDI_INDEX(data->port);
+
+   memcpy(verify_mprime_in.m_prime, stream_ready->m_prime,
+  HDCP_2_2_MPRIME_LEN);
+   drm_hdcp2_u32_to_seq_num(verify_mprime_in.seq_num_m, data->seq_num_m);
+   memcpy(verify_mprime_in.streams, data->streams,
+  (data->k * sizeof(struct hdcp2_streamid_type)));
+
+   verify_mprime_in.k = __swab16(data->k);
+
+   byte = mei_cldev_send(cldev, (u8 *)_mprime_in,
+ sizeof(verify_mprime_in));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+   return byte;
+   }
+
+   byte = mei_cldev_recv(cldev, (u8 *)_mprime_out,
+ sizeof(verify_mprime_out));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
+   return byte;
+   }
+
+   if (verify_mprime_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+   dev_dbg(dev, "ME cmd 0x%08X failed. status: 0x%X\n",
+   WIRED_REPEATER_AUTH_STREAM_REQ,
+   verify_mprime_out.header.status);
+   return -EIO;
+   }
+
+   return 0;
+}
+
 static __attribute__((unused))
 struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
@@ -533,7 +597,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
.verify_lprime = mei_verify_lprime,
.get_session_key = mei_get_session_key,
.repeater_check_flow_prepare_ack = mei_repeater_check_flow_prepare_ack,
-   .verify_mprime = NULL,
+   .verify_mprime = mei_verify_mprime,
.enable_hdcp_authentication = NULL,
.close_hdcp_session = NULL,
 };
-- 
2.7.4

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

[PATCH v9 31/39] misc/mei/hdcp: Repeater topology verification and ack

[Ramalingam C]

Request ME to verify the downstream topology information received.

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

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

v2: Rebased.
v3:
  cldev is passed as first parameter [Tomas]
  Redundant comments and cast are removed [Tomas]
v4:
  %zd for ssize_t [Alexander]
  %s/return -1/return -EIO [Alexander]
  Style and typos fixed [Uma]
v5: Rebased.
v6: Rebasing.
v7:
  Adjust to the new mei interface.
  Fix for Kdoc.
v8:
  K-Doc addition. [Tomas]

Signed-off-by: Ramalingam C 
Reviewed-by: Uma Shankar 
---
 drivers/misc/mei/hdcp/mei_hdcp.c | 76 +++-
 1 file changed, 75 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 554e07ba69c3..b8c039107d0f 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -448,6 +448,80 @@ static int mei_get_session_key(struct device *dev, struct 
hdcp_port_data *data,
return 0;
 }
 
+/**
+ * mei_repeater_check_flow_prepare_ack() - Validate the Downstream topology
+ * and prepare rep_ack.
+ * @dev: device corresponding to the mei_cl_device
+ * @hdcp_data: Intel HW specific hdcp data
+ * @rep_topology: Receiver ID List to be validated
+ * @rep_send_ack : repeater ack from ME FW.
+ *
+ * Return: 0 on Success, <0 on Failure
+ */
+static int
+mei_repeater_check_flow_prepare_ack(struct device *dev,
+   struct hdcp_port_data *data,
+   struct hdcp2_rep_send_receiverid_list
+   *rep_topology,
+   struct hdcp2_rep_send_ack *rep_send_ack)
+{
+   struct wired_cmd_verify_repeater_in verify_repeater_in = { { 0 } };
+   struct wired_cmd_verify_repeater_out verify_repeater_out = { { 0 } };
+   struct mei_cl_device *cldev;
+   ssize_t byte;
+
+   if (!dev || !rep_topology || !rep_send_ack || !data)
+   return -EINVAL;
+
+   cldev = to_mei_cl_device(dev);
+
+   verify_repeater_in.header.api_version = HDCP_API_VERSION;
+   verify_repeater_in.header.command_id = WIRED_VERIFY_REPEATER;
+   verify_repeater_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   verify_repeater_in.header.buffer_len =
+   WIRED_CMD_BUF_LEN_VERIFY_REPEATER_IN;
+
+   verify_repeater_in.port.integrated_port_type = data->port_type;
+   verify_repeater_in.port.physical_port =
+   (u8)GET_MEI_DDI_INDEX(data->port);
+
+   memcpy(verify_repeater_in.rx_info, rep_topology->rx_info,
+  HDCP_2_2_RXINFO_LEN);
+   memcpy(verify_repeater_in.seq_num_v, rep_topology->seq_num_v,
+  HDCP_2_2_SEQ_NUM_LEN);
+   memcpy(verify_repeater_in.v_prime, rep_topology->v_prime,
+  HDCP_2_2_V_PRIME_HALF_LEN);
+   memcpy(verify_repeater_in.receiver_ids, rep_topology->receiver_ids,
+  HDCP_2_2_RECEIVER_IDS_MAX_LEN);
+
+   byte = mei_cldev_send(cldev, (u8 *)_repeater_in,
+ sizeof(verify_repeater_in));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+   return byte;
+   }
+
+   byte = mei_cldev_recv(cldev, (u8 *)_repeater_out,
+ sizeof(verify_repeater_out));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
+   return byte;
+   }
+
+   if (verify_repeater_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+   dev_dbg(dev, "ME cmd 0x%08X failed. status: 0x%X\n",
+   WIRED_VERIFY_REPEATER,
+   verify_repeater_out.header.status);
+   return -EIO;
+   }
+
+   memcpy(rep_send_ack->v, verify_repeater_out.v,
+  HDCP_2_2_V_PRIME_HALF_LEN);
+   rep_send_ack->msg_id = HDCP_2_2_REP_SEND_ACK;
+
+   return 0;
+}
+
 static __attribute__((unused))
 struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
@@ -458,7 +532,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
.initiate_locality_check = mei_initiate_locality_check,
.verify_lprime = mei_verify_lprime,
.get_session_key = mei_get_session_key,
-   .repeater_check_flow_prepare_ack = NULL,
+   .repeater_check_flow_prepare_ack = mei_repeater_check_flow_prepare_ack,
.verify_mprime = NULL,
.enable_hdcp_authentication = NULL,
.close_hdcp_session = NULL,
-- 
2.7.4

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

[PATCH v9 36/39] drm/i915: Commit CP without modeset

[Ramalingam C]

Commits the content protection change of a connector,
without crtc modeset. This improves the user experience.

Originally proposed by Sean Paul at v3 of HDCP1.4 framework
https://patchwork.freedesktop.org/patch/191759/. For some
reason this was dropped, but needed for the proper functionality
of HDCP encryption.

Signed-off-by: Ramalingam C 
Suggested-by: Sean Paul 
---
 drivers/gpu/drm/i915/intel_ddi.c |  7 ---
 drivers/gpu/drm/i915/intel_display.c | 10 ++
 drivers/gpu/drm/i915/intel_drv.h |  5 +
 drivers/gpu/drm/i915/intel_hdcp.c| 32 
 4 files changed, 43 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 92c0bf70fe09..feb78780976d 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3548,11 +3548,6 @@ static void intel_enable_ddi(struct intel_encoder 
*encoder,
intel_enable_ddi_hdmi(encoder, crtc_state, conn_state);
else
intel_enable_ddi_dp(encoder, crtc_state, conn_state);
-
-   /* Enable hdcp if it's desired */
-   if (conn_state->content_protection ==
-   DRM_MODE_CONTENT_PROTECTION_DESIRED)
-   intel_hdcp_enable(to_intel_connector(conn_state->connector));
 }
 
 static void intel_disable_ddi_dp(struct intel_encoder *encoder,
@@ -3595,8 +3590,6 @@ static void intel_disable_ddi(struct intel_encoder 
*encoder,
  const struct intel_crtc_state *old_crtc_state,
  const struct drm_connector_state *old_conn_state)
 {
-   intel_hdcp_disable(to_intel_connector(old_conn_state->connector));
-
if (intel_crtc_has_type(old_crtc_state, INTEL_OUTPUT_HDMI))
intel_disable_ddi_hdmi(encoder, old_crtc_state, old_conn_state);
else
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 13e5650b6f31..05bae91512cd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12922,6 +12922,8 @@ static void intel_atomic_commit_tail(struct 
drm_atomic_state *state)
struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_crtc_state *old_crtc_state, *new_crtc_state;
struct intel_crtc_state *new_intel_crtc_state, *old_intel_crtc_state;
+   struct drm_connector_state *old_conn_state, *new_conn_state;
+   struct drm_connector *connector;
struct drm_crtc *crtc;
struct intel_crtc *intel_crtc;
u64 put_domains[I915_MAX_PIPES] = {};
@@ -13015,9 +13017,17 @@ static void intel_atomic_commit_tail(struct 
drm_atomic_state *state)
}
}
 
+   for_each_oldnew_connector_in_state(state, connector, old_conn_state,
+  new_conn_state, i)
+   intel_hdcp_atomic_pre_commit(connector, old_conn_state,
+new_conn_state);
+
/* Now enable the clocks, plane, pipe, and connectors that we set up. */
dev_priv->display.update_crtcs(state);
 
+   for_each_new_connector_in_state(state, connector, new_conn_state, i)
+   intel_hdcp_atomic_commit(connector, new_conn_state);
+
/* FIXME: We should call drm_atomic_helper_commit_hw_done() here
 * already, but still need the state for the delayed optimization. To
 * fix this:
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 60d1359e55f4..40357e17324e 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -2100,6 +2100,11 @@ static inline void 
intel_backlight_device_unregister(struct intel_connector *con
 void intel_hdcp_atomic_check(struct drm_connector *connector,
 struct drm_connector_state *old_state,
 struct drm_connector_state *new_state);
+void intel_hdcp_atomic_pre_commit(struct drm_connector *connector,
+ struct drm_connector_state *old_state,
+ struct drm_connector_state *new_state);
+void intel_hdcp_atomic_commit(struct drm_connector *connector,
+ struct drm_connector_state *new_state);
 int intel_hdcp_init(struct intel_connector *connector,
const struct intel_hdcp_shim *hdcp_shim,
bool hdcp2_supported);
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index cafda8903b50..42327ed30903 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -1760,7 +1760,6 @@ void intel_hdcp_atomic_check(struct drm_connector 
*connector,
 {
uint64_t old_cp = old_state->content_protection;
uint64_t new_cp = new_state->content_protection;
-   struct drm_crtc_state *crtc_state;
 
if (!new_state->crtc) {
/*
@@ -1781,10 +1780,35 @@ void 

[PATCH v9 30/39] misc/mei/hdcp: Prepare Session Key

[Ramalingam C]

Request to ME to prepare the encrypted session key.

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

v2: Rebased.
v3:
  cldev is passed as first parameter [Tomas]
  Redundant comments and cast are removed [Tomas]
v4:
  %zd for ssize_t [Alexander]
  %s/return -1/return -EIO [Alexander]
  Style fixed [Uma]
v5: Rebased.
v6:
  Collected the Rb-ed by.
  Rebasing.
v7:
  Adjust to the new mei interface.
  Fix for Kdoc.
v8:
  K-Doc addition. [Tomas]

Signed-off-by: Ramalingam C 
Reviewed-by: Uma Shankar 
---
 drivers/misc/mei/hdcp/mei_hdcp.c | 58 +++-
 1 file changed, 57 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index b6cc55c13d4a..554e07ba69c3 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -392,6 +392,62 @@ static int mei_verify_lprime(struct device *dev, struct 
hdcp_port_data *data,
return 0;
 }
 
+/**
+ * mei_get_session_key() - Prepare SKE_Send_Eks.
+ * @dev: device corresponding to the mei_cl_device
+ * @hdcp_data: Intel HW specific hdcp data
+ * @ske_data: SKE_Send_Eks msg output from ME FW.
+ *
+ * Return: 0 on Success, <0 on Failure
+ */
+static int mei_get_session_key(struct device *dev, struct hdcp_port_data *data,
+  struct hdcp2_ske_send_eks *ske_data)
+{
+   struct wired_cmd_get_session_key_in get_skey_in = { { 0 } };
+   struct wired_cmd_get_session_key_out get_skey_out = { { 0 } };
+   struct mei_cl_device *cldev;
+   ssize_t byte;
+
+   if (!dev || !data || !ske_data)
+   return -EINVAL;
+
+   cldev = to_mei_cl_device(dev);
+
+   get_skey_in.header.api_version = HDCP_API_VERSION;
+   get_skey_in.header.command_id = WIRED_GET_SESSION_KEY;
+   get_skey_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   get_skey_in.header.buffer_len = WIRED_CMD_BUF_LEN_GET_SESSION_KEY_IN;
+
+   get_skey_in.port.integrated_port_type = data->port_type;
+   get_skey_in.port.physical_port = (u8)GET_MEI_DDI_INDEX(data->port);
+
+   byte = mei_cldev_send(cldev, (u8 *)_skey_in, sizeof(get_skey_in));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+   return byte;
+   }
+
+   byte = mei_cldev_recv(cldev, (u8 *)_skey_out, sizeof(get_skey_out));
+
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
+   return byte;
+   }
+
+   if (get_skey_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+   dev_dbg(dev, "ME cmd 0x%08X failed. status: 0x%X\n",
+   WIRED_GET_SESSION_KEY, get_skey_out.header.status);
+   return -EIO;
+   }
+
+   ske_data->msg_id = HDCP_2_2_SKE_SEND_EKS;
+   memcpy(ske_data->e_dkey_ks, get_skey_out.e_dkey_ks,
+  HDCP_2_2_E_DKEY_KS_LEN);
+   memcpy(ske_data->riv, get_skey_out.r_iv, HDCP_2_2_RIV_LEN);
+
+   return 0;
+}
+
 static __attribute__((unused))
 struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
@@ -401,7 +457,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
.store_pairing_info = mei_store_pairing_info,
.initiate_locality_check = mei_initiate_locality_check,
.verify_lprime = mei_verify_lprime,
-   .get_session_key = NULL,
+   .get_session_key = mei_get_session_key,
.repeater_check_flow_prepare_ack = NULL,
.verify_mprime = NULL,
.enable_hdcp_authentication = NULL,
-- 
2.7.4

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

[PATCH v9 26/39] misc/mei/hdcp: Verify H_prime

[Ramalingam C]

Requests for the verification of AKE_Send_H_prime.

ME will calculate the H and comparing it with received H_Prime.
The result will be returned as status.

Here AKE_Send_H_prime is a HDCP2.2 Authentication msg.

v2: Rebased.
v3:
  cldev is passed as first parameter [Tomas]
  Redundant comments and cast are removed [Tomas]
v4:
  %zd for ssize_t [Alexander]
  %s/return -1/return -EIO [Alexander]
  Styles and typos fixed [Uma]
v5: Rebased.
v6:
  Collected the Rb-ed by.
  Rebasing.
v7:
  Adjust to the new mei interface.
  Fix for Kdoc.
v8:
  K-Doc Addition [Tomas]
  memcpy for const length.

Signed-off-by: Ramalingam C 
Reviewed-by: Uma Shankar 
---
 drivers/misc/mei/hdcp/mei_hdcp.c | 57 +++-
 1 file changed, 56 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 270baf24f21b..3e4f91e8b8f4 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -168,12 +168,67 @@ mei_verify_receiver_cert_prepare_km(struct device *dev,
return 0;
 }
 
+/**
+ * mei_verify_hprime() - Verify AKE_Send_H_prime at ME FW.
+ * @dev: device corresponding to the mei_cl_device
+ * @hdcp_data: Intel HW specific hdcp data
+ * @rx_hprime: AKE_Send_H_prime msg for ME FW verification
+ *
+ * Return: 0 on Success, <0 on Failure
+ */
+static int mei_verify_hprime(struct device *dev, struct hdcp_port_data *data,
+struct hdcp2_ake_send_hprime *rx_hprime)
+{
+   struct wired_cmd_ake_send_hprime_in send_hprime_in = { { 0 } };
+   struct wired_cmd_ake_send_hprime_out send_hprime_out = { { 0 } };
+   struct mei_cl_device *cldev;
+   ssize_t byte;
+
+   if (!dev || !data || !rx_hprime)
+   return -EINVAL;
+
+   cldev = to_mei_cl_device(dev);
+
+   send_hprime_in.header.api_version = HDCP_API_VERSION;
+   send_hprime_in.header.command_id = WIRED_AKE_SEND_HPRIME;
+   send_hprime_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   send_hprime_in.header.buffer_len = WIRED_CMD_BUF_LEN_AKE_SEND_HPRIME_IN;
+
+   send_hprime_in.port.integrated_port_type = data->port_type;
+   send_hprime_in.port.physical_port = (u8)GET_MEI_DDI_INDEX(data->port);
+
+   memcpy(send_hprime_in.h_prime, rx_hprime->h_prime,
+  HDCP_2_2_H_PRIME_LEN);
+
+   byte = mei_cldev_send(cldev, (u8 *)_hprime_in,
+ sizeof(send_hprime_in));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+   return byte;
+   }
+
+   byte = mei_cldev_recv(cldev, (u8 *)_hprime_out,
+ sizeof(send_hprime_out));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
+   return byte;
+   }
+
+   if (send_hprime_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+   dev_dbg(dev, "ME cmd 0x%08X Failed. Status: 0x%X\n",
+   WIRED_AKE_SEND_HPRIME, send_hprime_out.header.status);
+   return -EIO;
+   }
+
+   return 0;
+}
+
 static __attribute__((unused))
 struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
.initiate_hdcp2_session = mei_initiate_hdcp2_session,
.verify_receiver_cert_prepare_km = mei_verify_receiver_cert_prepare_km,
-   .verify_hprime = NULL,
+   .verify_hprime = mei_verify_hprime,
.store_pairing_info = NULL,
.initiate_locality_check = NULL,
.verify_lprime = NULL,
-- 
2.7.4

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

[PATCH v9 35/39] misc/mei/hdcp: Component framework for I915 Interface

[Ramalingam C]

Mei hdcp driver is designed as component slave for the I915 component
master.

v2: Rebased.
v3:
  Notifier chain is adopted for cldev state update [Tomas]
v4:
  Made static dummy functions as inline in mei_hdcp.h
  API for polling client device status
  IS_ENABLED used in header, for config status for mei_hdcp.
v5:
  Replacing the notifier with component framework. [Daniel]
v6:
  Rebased on the I915 comp master redesign.
v7:
  mei_hdcp_component_registered is made static [Uma]
  Need for global static variable mei_cldev is removed.

Signed-off-by: Ramalingam C 
Reviewed-by: Uma Shankar 
---
 drivers/misc/mei/hdcp/mei_hdcp.c | 67 +---
 1 file changed, 63 insertions(+), 4 deletions(-)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index b22a71e8c5d7..3de1700dcc9f 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -23,11 +23,14 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
 #include "mei_hdcp.h"
 
+static bool mei_hdcp_component_registered;
+
 /**
  * mei_initiate_hdcp2_session() - Initiate a Wired HDCP2.2 Tx Session in ME FW
  * @dev: device corresponding to the mei_cl_device
@@ -691,8 +694,7 @@ mei_close_hdcp_session(struct device *dev, struct 
hdcp_port_data *data)
return 0;
 }
 
-static __attribute__((unused))
-struct i915_hdcp_component_ops mei_hdcp_ops = {
+static struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
.initiate_hdcp2_session = mei_initiate_hdcp2_session,
.verify_receiver_cert_prepare_km = mei_verify_receiver_cert_prepare_km,
@@ -707,20 +709,77 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
.close_hdcp_session = mei_close_hdcp_session,
 };
 
+static int mei_hdcp_component_bind(struct device *mei_kdev,
+  struct device *i915_kdev, void *data)
+{
+   struct i915_component_master *master_comp = data;
+
+   dev_info(mei_kdev, "MEI HDCP comp bind\n");
+   WARN_ON(master_comp->hdcp_ops);
+   master_comp->hdcp_ops = _hdcp_ops;
+   master_comp->mei_dev = mei_kdev;
+
+   return 0;
+}
+
+static void mei_hdcp_component_unbind(struct device *mei_kdev,
+ struct device *i915_kdev, void *data)
+{
+   struct i915_component_master *master_comp = data;
+
+   dev_info(mei_kdev, "MEI HDCP comp unbind\n");
+   master_comp->hdcp_ops = NULL;
+   master_comp->mei_dev = NULL;
+}
+
+static const struct component_ops mei_hdcp_component_bind_ops = {
+   .bind   = mei_hdcp_component_bind,
+   .unbind = mei_hdcp_component_unbind,
+};
+
+static void mei_hdcp_component_init(struct device *dev)
+{
+   int ret;
+
+   dev_info(dev, "MEI HDCP comp init\n");
+   ret = component_add(dev, _hdcp_component_bind_ops);
+   if (ret < 0) {
+   dev_err(dev, "Failed to add MEI HDCP comp (%d)\n", ret);
+   return;
+   }
+
+   mei_hdcp_component_registered = true;
+}
+
+static void mei_hdcp_component_cleanup(struct device *dev)
+{
+   if (!mei_hdcp_component_registered)
+   return;
+
+   dev_info(dev, "MEI HDCP comp cleanup\n");
+   component_del(dev, _hdcp_component_bind_ops);
+   mei_hdcp_component_registered = false;
+}
+
 static int mei_hdcp_probe(struct mei_cl_device *cldev,
  const struct mei_cl_device_id *id)
 {
int ret;
 
ret = mei_cldev_enable(cldev);
-   if (ret < 0)
+   if (ret < 0) {
dev_err(>dev, "mei_cldev_enable Failed. %d\n", ret);
+   return ret;
+   }
+   mei_hdcp_component_init(>dev);
 
-   return ret;
+   return 0;
 }
 
 static int mei_hdcp_remove(struct mei_cl_device *cldev)
 {
+   mei_hdcp_component_cleanup(>dev);
+
return mei_cldev_disable(cldev);
 }
 
-- 
2.7.4

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

[PATCH v9 25/39] misc/mei/hdcp: Verify Receiver Cert and prepare km

[Ramalingam C]

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

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

Here AKE_Stored_Km and AKE_No_Stored_Km are HDCP2.2 protocol msgs.

v2: Rebased.
v3:
  cldev is passed as first parameter [Tomas]
  Redundant comments and cast are removed [Tomas]
v4:
  %zd is used for ssize_t [Alexander]
  %s/return -1/return -EIO [Alexander]
v5: Rebased.
v6:
  Collected the Rb-ed by.
  Rebasing.
v7:
  Adjust to the new mei interface.
  Fix for Kdoc.
v8:
  K-Doc Addition. [Tomas]
  memcpy for const length.

Signed-off-by: Ramalingam C 
Reviewed-by: Uma Shankar 
---
 drivers/misc/mei/hdcp/mei_hdcp.c | 81 +++-
 1 file changed, 80 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 124f02e2b7c4..270baf24f21b 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -89,11 +89,90 @@ mei_initiate_hdcp2_session(struct device *dev, struct 
hdcp_port_data *data,
return 0;
 }
 
+/**
+ * mei_verify_receiver_cert_prepare_km() - Verify the Receiver Certificate
+ * AKE_Send_Cert and prepare AKE_Stored_Km/AKE_No_Stored_Km
+ * @dev: device corresponding to the mei_cl_device
+ * @hdcp_data: Intel HW specific hdcp data
+ * @rx_cert: AKE_Send_Cert for verification
+ * @km_stored: Pairing status flag output
+ * @ek_pub_km: AKE_Stored_Km/AKE_No_Stored_Km output msg
+ * @msg_sz : size of AKE_X_Km output msg
+ *
+ * Return: 0 on Success, <0 on Failure
+ */
+static int
+mei_verify_receiver_cert_prepare_km(struct device *dev,
+   struct hdcp_port_data *data,
+   struct hdcp2_ake_send_cert *rx_cert,
+   bool *km_stored,
+   struct hdcp2_ake_no_stored_km *ek_pub_km,
+   size_t *msg_sz)
+{
+   struct wired_cmd_verify_receiver_cert_in verify_rxcert_in = { { 0 } };
+   struct wired_cmd_verify_receiver_cert_out verify_rxcert_out = { { 0 } };
+   struct mei_cl_device *cldev;
+   ssize_t byte;
+
+   if (!dev || !data || !rx_cert || !km_stored || !ek_pub_km || !msg_sz)
+   return -EINVAL;
+
+   cldev = to_mei_cl_device(dev);
+
+   verify_rxcert_in.header.api_version = HDCP_API_VERSION;
+   verify_rxcert_in.header.command_id = WIRED_VERIFY_RECEIVER_CERT;
+   verify_rxcert_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   verify_rxcert_in.header.buffer_len =
+   WIRED_CMD_BUF_LEN_VERIFY_RECEIVER_CERT_IN;
+
+   verify_rxcert_in.port.integrated_port_type = data->port_type;
+   verify_rxcert_in.port.physical_port = (u8)GET_MEI_DDI_INDEX(data->port);
+
+   verify_rxcert_in.cert_rx = rx_cert->cert_rx;
+   memcpy(verify_rxcert_in.r_rx, _cert->r_rx, HDCP_2_2_RRX_LEN);
+   memcpy(verify_rxcert_in.rx_caps, rx_cert->rx_caps, HDCP_2_2_RXCAPS_LEN);
+
+   byte = mei_cldev_send(cldev, (u8 *)_rxcert_in,
+ sizeof(verify_rxcert_in));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_send failed: %zd\n", byte);
+   return byte;
+   }
+
+   byte = mei_cldev_recv(cldev, (u8 *)_rxcert_out,
+ sizeof(verify_rxcert_out));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_recv failed: %zd\n", byte);
+   return byte;
+   }
+
+   if (verify_rxcert_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+   dev_dbg(dev, "ME cmd 0x%08X Failed. Status: 0x%X\n",
+   WIRED_VERIFY_RECEIVER_CERT,
+   verify_rxcert_out.header.status);
+   return -EIO;
+   }
+
+   *km_stored = verify_rxcert_out.km_stored;
+   if (verify_rxcert_out.km_stored) {
+   ek_pub_km->msg_id = HDCP_2_2_AKE_STORED_KM;
+   *msg_sz = sizeof(struct hdcp2_ake_stored_km);
+   } else {
+   ek_pub_km->msg_id = HDCP_2_2_AKE_NO_STORED_KM;
+   *msg_sz = sizeof(struct hdcp2_ake_no_stored_km);
+   }
+
+   memcpy(ek_pub_km->e_kpub_km, _rxcert_out.ekm_buff,
+  sizeof(verify_rxcert_out.ekm_buff));
+
+   return 0;
+}
+
 static __attribute__((unused))
 struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
.initiate_hdcp2_session = mei_initiate_hdcp2_session,
-   .verify_receiver_cert_prepare_km = NULL,
+   .verify_receiver_cert_prepare_km = mei_verify_receiver_cert_prepare_km,
.verify_hprime = NULL,
.store_pairing_info = NULL,
.initiate_locality_check = NULL,
-- 
2.7.4

___
dri-devel mailing list

[PATCH v9 38/39] FOR_TEST: i915/Kconfig: Select mei_hdcp by I915

[Ramalingam C]

FOR TESTING PURPOSE ONLY.

By default INTEL_MEI_HDCP is set to y. This patch is created to
test the interface between I915 and MEI_HDCP.

Signed-off-by: Ramalingam C 
---
 drivers/misc/mei/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/misc/mei/Kconfig b/drivers/misc/mei/Kconfig
index 9c518b7f0011..90ed55210447 100644
--- a/drivers/misc/mei/Kconfig
+++ b/drivers/misc/mei/Kconfig
@@ -48,5 +48,6 @@ config INTEL_MEI_HDCP
tristate "Intel HDCP2.2 services of ME Interface"
select INTEL_MEI_ME
depends on DRM_I915
+   default y
help
  MEI Support for HDCP2.2 Services on Intel SoCs.
-- 
2.7.4

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

[PATCH v9 29/39] misc/mei/hdcp: Verify L_prime

[Ramalingam C]

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

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

This represents the completion of Locality Check.

v2: Rebased.
v3:
  cldev is passed as first parameter [Tomas]
  Redundant comments and cast are removed [Tomas]
v4:
  %zd for ssize_t [Alexander]
  %s/return -1/return -EIO [Alexander]
  Style fixed [Uma]
v5: Rebased.
v6:
  Collected the Rb-ed by.
  Rebasing.
v7:
  Adjust to the new mei interface.
  Fix for Kdoc.
v8:
  K-Doc addition. [Tomas]
  memcpy for const length.

Signed-off-by: Ramalingam C 
Reviewed-by: Uma Shankar 
---
 drivers/misc/mei/hdcp/mei_hdcp.c | 59 +++-
 1 file changed, 58 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index db1492f64d6b..b6cc55c13d4a 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -335,6 +335,63 @@ mei_initiate_locality_check(struct device *dev, struct 
hdcp_port_data *data,
return 0;
 }
 
+/**
+ * mei_verify_lprime() - Verify lprime.
+ * @dev: device corresponding to the mei_cl_device
+ * @hdcp_data: Intel HW specific hdcp data
+ * @rx_lprime: LC_Send_L_prime msg for ME FW verification
+ *
+ * Return: 0 on Success, <0 on Failure
+ */
+static int mei_verify_lprime(struct device *dev, struct hdcp_port_data *data,
+struct hdcp2_lc_send_lprime *rx_lprime)
+{
+   struct wired_cmd_validate_locality_in verify_lprime_in = { { 0 } };
+   struct wired_cmd_validate_locality_out verify_lprime_out = { { 0 } };
+   struct mei_cl_device *cldev;
+   ssize_t byte;
+
+   if (!dev || !data || !rx_lprime)
+   return -EINVAL;
+
+   cldev = to_mei_cl_device(dev);
+
+   verify_lprime_in.header.api_version = HDCP_API_VERSION;
+   verify_lprime_in.header.command_id = WIRED_VALIDATE_LOCALITY;
+   verify_lprime_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   verify_lprime_in.header.buffer_len =
+   WIRED_CMD_BUF_LEN_VALIDATE_LOCALITY_IN;
+
+   verify_lprime_in.port.integrated_port_type = data->port_type;
+   verify_lprime_in.port.physical_port = (u8)GET_MEI_DDI_INDEX(data->port);
+
+   memcpy(verify_lprime_in.l_prime, rx_lprime->l_prime,
+  HDCP_2_2_L_PRIME_LEN);
+
+   byte = mei_cldev_send(cldev, (u8 *)_lprime_in,
+ sizeof(verify_lprime_in));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+   return byte;
+   }
+
+   byte = mei_cldev_recv(cldev, (u8 *)_lprime_out,
+ sizeof(verify_lprime_out));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
+   return byte;
+   }
+
+   if (verify_lprime_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+   dev_dbg(dev, "ME cmd 0x%08X failed. status: 0x%X\n",
+   WIRED_VALIDATE_LOCALITY,
+   verify_lprime_out.header.status);
+   return -EIO;
+   }
+
+   return 0;
+}
+
 static __attribute__((unused))
 struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
@@ -343,7 +400,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
.verify_hprime = mei_verify_hprime,
.store_pairing_info = mei_store_pairing_info,
.initiate_locality_check = mei_initiate_locality_check,
-   .verify_lprime = NULL,
+   .verify_lprime = mei_verify_lprime,
.get_session_key = NULL,
.repeater_check_flow_prepare_ack = NULL,
.verify_mprime = NULL,
-- 
2.7.4

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

[PATCH v9 27/39] misc/mei/hdcp: Store the HDCP Pairing info

[Ramalingam C]

Provides Pairing info to ME to store.

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

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

v2: Rebased.
v3:
  cldev is passed as first parameter [Tomas]
  Redundant comments and cast are removed [Tomas]
v4:
  %zd for ssize_t [Alexander]
  %s/return -1/return -EIO [Alexander]
  Style fixed [Uma]
v5: Rebased.
v6:
  Collected the Rb-ed by.
  Rebasing.
v7:
  Adjust to the new mei interface.
  Fix for Kdoc.
v8:
  K-Doc addition. [Tomas]
  memcpy for const length.

Signed-off-by: Ramalingam C 
Reviewed-by: Uma Shankar 
---
 drivers/misc/mei/hdcp/mei_hdcp.c | 60 +++-
 1 file changed, 59 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 3e4f91e8b8f4..809d6270b6c1 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -223,13 +223,71 @@ static int mei_verify_hprime(struct device *dev, struct 
hdcp_port_data *data,
return 0;
 }
 
+/**
+ * mei_store_pairing_info() - Store pairing info received at ME FW
+ * @dev: device corresponding to the mei_cl_device
+ * @hdcp_data: Intel HW specific hdcp data
+ * @pairing_info: AKE_Send_Pairing_Info msg input to ME FW
+ *
+ * Return: 0 on Success, <0 on Failure
+ */
+static int
+mei_store_pairing_info(struct device *dev, struct hdcp_port_data *data,
+  struct hdcp2_ake_send_pairing_info *pairing_info)
+{
+   struct wired_cmd_ake_send_pairing_info_in pairing_info_in = { { 0 } };
+   struct wired_cmd_ake_send_pairing_info_out pairing_info_out = { { 0 } };
+   struct mei_cl_device *cldev;
+   ssize_t byte;
+
+   if (!dev || !data || !pairing_info)
+   return -EINVAL;
+
+   cldev = to_mei_cl_device(dev);
+
+   pairing_info_in.header.api_version = HDCP_API_VERSION;
+   pairing_info_in.header.command_id = WIRED_AKE_SEND_PAIRING_INFO;
+   pairing_info_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   pairing_info_in.header.buffer_len =
+   WIRED_CMD_BUF_LEN_SEND_PAIRING_INFO_IN;
+
+   pairing_info_in.port.integrated_port_type = data->port_type;
+   pairing_info_in.port.physical_port = (u8)GET_MEI_DDI_INDEX(data->port);
+
+   memcpy(pairing_info_in.e_kh_km, pairing_info->e_kh_km,
+  HDCP_2_2_E_KH_KM_LEN);
+
+   byte = mei_cldev_send(cldev, (u8 *)_info_in,
+ sizeof(pairing_info_in));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+   return byte;
+   }
+
+   byte = mei_cldev_recv(cldev, (u8 *)_info_out,
+ sizeof(pairing_info_out));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
+   return byte;
+   }
+
+   if (pairing_info_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+   dev_dbg(dev, "ME cmd 0x%08X failed. Status: 0x%X\n",
+   WIRED_AKE_SEND_PAIRING_INFO,
+   pairing_info_out.header.status);
+   return -EIO;
+   }
+
+   return 0;
+}
+
 static __attribute__((unused))
 struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
.initiate_hdcp2_session = mei_initiate_hdcp2_session,
.verify_receiver_cert_prepare_km = mei_verify_receiver_cert_prepare_km,
.verify_hprime = mei_verify_hprime,
-   .store_pairing_info = NULL,
+   .store_pairing_info = mei_store_pairing_info,
.initiate_locality_check = NULL,
.verify_lprime = NULL,
.get_session_key = NULL,
-- 
2.7.4

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

[PATCH v9 14/39] drm/i915: Implement HDCP2.2 link integrity check

[Ramalingam C]

Implements the link integrity check once in 500mSec.

Once encryption is enabled, an ongoing Link Integrity Check is
performed by the HDCP Receiver to check that cipher synchronization
is maintained between the HDCP Transmitter and the HDCP Receiver.

On the detection of synchronization lost, the HDCP Receiver must assert
the corresponding bits of the RxStatus register. The Transmitter polls
the RxStatus register and it may initiate re-authentication.

v2:
  Rebased.
v3:
  enum check_link_response is used check the link status [Uma]
v4:
  Rebased as part of patch reordering.
v5:
  Required members of intel_hdcp is defined [Sean Paul]
v6:
  hdcp2_check_link is cancelled at required places.
v7:
  Rebased for the component i/f changes.
  Errors due to the sinks are reported as DEBUG logs.
v8:
  hdcp_check_work is used for both hdcp1 and hdcp2 check_link [Daniel]
  hdcp2.2 encryption status check is put under WARN_ON [Daniel]
  drm_hdcp.h changes are moved into separate patch [Daniel]

Signed-off-by: Ramalingam C 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/intel_drv.h  |  3 ++
 drivers/gpu/drm/i915/intel_hdcp.c | 90 ---
 2 files changed, 87 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a6b632d71490..60d1359e55f4 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -403,6 +403,9 @@ struct intel_hdcp_shim {
 */
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);
 };
 
 struct intel_hdcp {
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index b52da5c3159d..6fac570fcbac 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -103,6 +103,16 @@ static inline bool intel_hdcp_in_use(struct 
intel_connector *connector)
return reg & HDCP_STATUS_ENC;
 }
 
+static inline bool intel_hdcp2_in_use(struct intel_connector *connector)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   enum port port = connector->encoder->port;
+   u32 reg;
+
+   reg = I915_READ(HDCP2_STATUS_DDI(port));
+   return reg & LINK_ENCRYPTION_STATUS;
+}
+
 static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
const struct intel_hdcp_shim *shim)
 {
@@ -1491,11 +1501,77 @@ static int _intel_hdcp2_disable(struct intel_connector 
*connector)
return ret;
 }
 
+/* Implements the Link Integrity Check for HDCP2.2 */
+static int intel_hdcp2_check_link(struct intel_connector *connector)
+{
+   struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_hdcp *hdcp = >hdcp;
+   enum port port = connector->encoder->port;
+   int ret = 0;
+
+   mutex_lock(>mutex);
+
+   /* hdcp2_check_link is expected only when HDCP2.2 is Enabled */
+   if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_ENABLED ||
+   !hdcp->hdcp2_encrypted) {
+   ret = -EINVAL;
+   goto out;
+   }
+
+   if (WARN_ON(!intel_hdcp2_in_use(connector))) {
+   DRM_ERROR("HDCP2.2 link stopped the encryption, %x\n",
+ I915_READ(HDCP2_STATUS_DDI(port)));
+   ret = -ENXIO;
+   hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
+   schedule_work(>prop_work);
+   goto out;
+   }
+
+   ret = hdcp->shim->check_2_2_link(intel_dig_port);
+   if (ret == DRM_HDCP_LINK_PROTECTED) {
+   if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
+   hdcp->value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
+   schedule_work(>prop_work);
+   }
+   goto out;
+   }
+
+   DRM_DEBUG_KMS("[%s:%d] HDCP2.2 link failed, retrying auth\n",
+ connector->base.name, connector->base.base.id);
+
+   ret = _intel_hdcp2_disable(connector);
+   if (ret) {
+   DRM_ERROR("[%s:%d] Failed to disable hdcp2.2 (%d)\n",
+ connector->base.name, connector->base.base.id, ret);
+   hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
+   schedule_work(>prop_work);
+   goto out;
+   }
+
+   ret = _intel_hdcp2_enable(connector);
+   if (ret) {
+   DRM_DEBUG_KMS("[%s:%d] Failed to enable hdcp2.2 (%d)\n",
+ connector->base.name, connector->base.base.id,
+ ret);
+   hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
+   schedule_work(>prop_work);
+   goto out;
+   

[PATCH v9 20/39] mei: bus: whitelist hdcp client

[Ramalingam C]

From: Tomas Winkler 

Whitelist HDCP client for in kernel drm use

v2:
  Rebased.

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

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

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

[PATCH v9 19/39] drm/i915: Add HDCP2.2 support for HDMI connectors

[Ramalingam C]

On HDMI connector init, intel_hdcp_init is passed with a flag for hdcp2.2
support based on the platform capability.

v2:
  Rebased.
v3:
  Collected the reviewed-by received.

Signed-off-by: Ramalingam C 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/intel_hdmi.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 5f179f1dd4ad..0c3b287bff24 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -2623,7 +2623,8 @@ void intel_hdmi_init_connector(struct intel_digital_port 
*intel_dig_port,
 
if (is_hdcp_supported(dev_priv, port)) {
int ret = intel_hdcp_init(intel_connector,
- _hdmi_hdcp_shim, false);
+_hdmi_hdcp_shim,
+is_hdcp2_supported(dev_priv));
if (ret)
DRM_DEBUG_KMS("HDCP init failed, skipping.\n");
}
-- 
2.7.4

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

[PATCH v9 16/39] drm/i915: Implement the HDCP2.2 support for DP

[Ramalingam C]

Implements the DP adaptation specific HDCP2.2 functions.

These functions perform the DPCD read and write for communicating the
HDCP2.2 auth message back and forth.

v2:
  wait for cp_irq is merged with this patch. Rebased.
v3:
  wait_queue is used for wait for cp_irq [Chris Wilson]
v4:
  Style fixed.
  %s/PARING/PAIRING
  Few style fixes [Uma]
v5:
  Lookup table for DP HDCP2.2 msg details [Daniel].
  Extra lines are removed.
v6: Rebased.
v7:
  Fixed some regression introduced at v5. [Ankit]
  Macro HDCP_2_2_RX_CAPS_VERSION_VAL is reused [Uma]
  Converted a function to inline [Uma]
  %s/uintxx_t/uxx
v8:
  Error due to the sinks are reported as DEBUG logs.
  Adjust to the new mei interface.
v9:
  ARRAY_SIZE for no of array members [Jon & Daniel]
  return of the wait_for_cp_irq is made as void [Daniel]
  Wait for HDCP2.2 msg is done based on polling the reg bit than
CP_IRQ based. [Daniel]
  hdcp adaptation is added as a const in the hdcp_shim [Daniel]

Signed-off-by: Ramalingam C 
Signed-off-by: Ankit K Nautiyal 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/intel_dp.c | 310 
 1 file changed, 310 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 89315e15fb34..a8ace7d85918 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5797,6 +5797,310 @@ int intel_dp_hdcp_capable(struct intel_digital_port 
*intel_dig_port,
return 0;
 }
 
+static struct hdcp2_dp_msg_data {
+   u8 msg_id;
+   u32 offset;
+   bool msg_detectable;
+   u32 timeout;
+   u32 timeout2; /* Added for non_paired situation */
+   } hdcp2_msg_data[] = {
+   {HDCP_2_2_AKE_INIT, DP_HDCP_2_2_AKE_INIT_OFFSET, false, 0, 0},
+   {HDCP_2_2_AKE_SEND_CERT, DP_HDCP_2_2_AKE_SEND_CERT_OFFSET,
+   false, HDCP_2_2_CERT_TIMEOUT_MS, 0},
+   {HDCP_2_2_AKE_NO_STORED_KM, DP_HDCP_2_2_AKE_NO_STORED_KM_OFFSET,
+   false, 0, 0},
+   {HDCP_2_2_AKE_STORED_KM, DP_HDCP_2_2_AKE_STORED_KM_OFFSET,
+   false, 0, 0},
+   {HDCP_2_2_AKE_SEND_HPRIME, DP_HDCP_2_2_AKE_SEND_HPRIME_OFFSET,
+   true, HDCP_2_2_HPRIME_PAIRED_TIMEOUT_MS,
+   HDCP_2_2_HPRIME_NO_PAIRED_TIMEOUT_MS},
+   {HDCP_2_2_AKE_SEND_PAIRING_INFO,
+   DP_HDCP_2_2_AKE_SEND_PAIRING_INFO_OFFSET, true,
+   HDCP_2_2_PAIRING_TIMEOUT_MS, 0},
+   {HDCP_2_2_LC_INIT, DP_HDCP_2_2_LC_INIT_OFFSET, false, 0, 0},
+   {HDCP_2_2_LC_SEND_LPRIME, DP_HDCP_2_2_LC_SEND_LPRIME_OFFSET,
+   false, HDCP_2_2_DP_LPRIME_TIMEOUT_MS, 0},
+   {HDCP_2_2_SKE_SEND_EKS, DP_HDCP_2_2_SKE_SEND_EKS_OFFSET, false,
+   0, 0},
+   {HDCP_2_2_REP_SEND_RECVID_LIST,
+   DP_HDCP_2_2_REP_SEND_RECVID_LIST_OFFSET, true,
+   HDCP_2_2_RECVID_LIST_TIMEOUT_MS, 0},
+   {HDCP_2_2_REP_SEND_ACK, DP_HDCP_2_2_REP_SEND_ACK_OFFSET, false,
+   0, 0},
+   {HDCP_2_2_REP_STREAM_MANAGE,
+   DP_HDCP_2_2_REP_STREAM_MANAGE_OFFSET, false,
+   0, 0},
+   {HDCP_2_2_REP_STREAM_READY, DP_HDCP_2_2_REP_STREAM_READY_OFFSET,
+   false, HDCP_2_2_STREAM_READY_TIMEOUT_MS, 0},
+   {HDCP_2_2_ERRATA_DP_STREAM_TYPE,
+   DP_HDCP_2_2_REG_STREAM_TYPE_OFFSET, false,
+   0, 0},
+   };
+
+static inline
+int intel_dp_hdcp2_read_rx_status(struct intel_digital_port *intel_dig_port,
+ u8 *rx_status)
+{
+   ssize_t ret;
+
+   ret = drm_dp_dpcd_read(_dig_port->dp.aux,
+  DP_HDCP_2_2_REG_RXSTATUS_OFFSET, rx_status,
+  HDCP_2_2_DP_RXSTATUS_LEN);
+   if (ret != HDCP_2_2_DP_RXSTATUS_LEN) {
+   DRM_DEBUG_KMS("Read bstatus from DP/AUX failed (%zd)\n", ret);
+   return ret >= 0 ? -EIO : ret;
+   }
+
+   return 0;
+}
+
+static
+int hdcp2_detect_msg_availability(struct intel_digital_port *intel_dig_port,
+ u8 msg_id, bool *msg_ready)
+{
+   u8 rx_status;
+   int ret;
+
+   *msg_ready = false;
+   ret = intel_dp_hdcp2_read_rx_status(intel_dig_port, _status);
+   if (ret < 0)
+   return ret;
+
+   switch (msg_id) {
+   case HDCP_2_2_AKE_SEND_HPRIME:
+   if (HDCP_2_2_DP_RXSTATUS_H_PRIME(rx_status))
+   *msg_ready = true;
+   break;
+   case HDCP_2_2_AKE_SEND_PAIRING_INFO:
+   if (HDCP_2_2_DP_RXSTATUS_PAIRING(rx_status))
+   *msg_ready = true;
+  

[PATCH v9 12/39] drm/i915: Implement HDCP2.2 repeater authentication

[Ramalingam C]

Implements the HDCP2.2 repeaters authentication steps such as verifying
the downstream topology and sending stream management information.

v2: Rebased.
v3:
  -EINVAL is returned for topology error and rollover scenario.
  Endianness conversion func from drm_hdcp.h is used [Uma]
v4:
  Rebased as part of patches reordering.
  Defined the mei service functions [Daniel]
v5:
  Redefined the mei service functions as per comp redesign.
v6:
  %s/uintxx_t/uxx
  Check for comp_master is removed.
v7:
  Adjust to the new mei interface.
  style issue fixed.
v8:
  drm_hdcp.h change is moved into separate patch [Daniel]

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 123 +-
 1 file changed, 121 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index f1f0ef294e20..b52da5c3159d 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -978,7 +978,7 @@ static int hdcp2_prepare_skey(struct intel_connector 
*connector,
return ret;
 }
 
-static __attribute__((unused)) int
+static int
 hdcp2_verify_rep_topology_prepare_ack(struct intel_connector *connector,
  struct hdcp2_rep_send_receiverid_list
*rep_topology,
@@ -999,7 +999,7 @@ hdcp2_verify_rep_topology_prepare_ack(struct 
intel_connector *connector,
return ret;
 }
 
-static __attribute__((unused)) int
+static int
 hdcp2_verify_mprime(struct intel_connector *connector,
struct hdcp2_rep_stream_ready *stream_ready)
 {
@@ -1182,6 +1182,119 @@ static int hdcp2_session_key_exchange(struct 
intel_connector *connector)
return 0;
 }
 
+static
+int hdcp2_propagate_stream_management_info(struct intel_connector *connector)
+{
+   struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+   struct intel_hdcp *hdcp = >hdcp;
+   union {
+   struct hdcp2_rep_stream_manage stream_manage;
+   struct hdcp2_rep_stream_ready stream_ready;
+   } msgs;
+   const struct intel_hdcp_shim *shim = hdcp->shim;
+   int ret;
+
+   /* Prepare RepeaterAuth_Stream_Manage msg */
+   msgs.stream_manage.msg_id = HDCP_2_2_REP_STREAM_MANAGE;
+   drm_hdcp2_u32_to_seq_num(msgs.stream_manage.seq_num_m, hdcp->seq_num_m);
+
+   /* K no of streams is fixed as 1. Stored as big-endian. */
+   msgs.stream_manage.k = __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, _manage,
+ sizeof(msgs.stream_manage));
+   if (ret < 0)
+   return ret;
+
+   ret = shim->read_2_2_msg(intel_dig_port, HDCP_2_2_REP_STREAM_READY,
+_ready, sizeof(msgs.stream_ready));
+   if (ret < 0)
+   return ret;
+
+   hdcp->port_data.seq_num_m = hdcp->seq_num_m;
+   hdcp->port_data.streams[0].stream_type = hdcp->content_type;
+
+   ret = hdcp2_verify_mprime(connector, _ready);
+   if (ret < 0)
+   return ret;
+
+   hdcp->seq_num_m++;
+
+   if (hdcp->seq_num_m > HDCP_2_2_SEQ_NUM_MAX) {
+   DRM_DEBUG_KMS("seq_num_m roll over.\n");
+   return -1;
+   }
+
+   return 0;
+}
+
+static
+int hdcp2_authenticate_repeater_topology(struct intel_connector *connector)
+{
+   struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+   struct intel_hdcp *hdcp = >hdcp;
+   union {
+   struct hdcp2_rep_send_receiverid_list recvid_list;
+   struct hdcp2_rep_send_ack rep_ack;
+   } msgs;
+   const struct intel_hdcp_shim *shim = hdcp->shim;
+   u8 *rx_info;
+   u32 seq_num_v;
+   int ret;
+
+   ret = shim->read_2_2_msg(intel_dig_port, HDCP_2_2_REP_SEND_RECVID_LIST,
+_list, sizeof(msgs.recvid_list));
+   if (ret < 0)
+   return ret;
+
+   rx_info = msgs.recvid_list.rx_info;
+
+   if (HDCP_2_2_MAX_CASCADE_EXCEEDED(rx_info[1]) ||
+   HDCP_2_2_MAX_DEVS_EXCEEDED(rx_info[1])) {
+   DRM_DEBUG_KMS("Topology Max Size Exceeded\n");
+   return -EINVAL;
+   }
+
+   /* Converting and Storing the seq_num_v to local variable as DWORD */
+   drm_hdcp2_seq_num_to_u32(_num_v, msgs.recvid_list.seq_num_v);
+
+   if (seq_num_v < hdcp->seq_num_v) {
+   /* Roll over of the seq_num_v from repeater. Reauthenticate. */
+   DRM_DEBUG_KMS("Seq_num_v roll over.\n");
+   return -EINVAL;
+   }
+
+   ret = hdcp2_verify_rep_topology_prepare_ack(connector,
+ 

[PATCH v9 17/39] drm/i915: Implement the HDCP2.2 support for HDMI

[Ramalingam C]

Implements the HDMI adaptation specific HDCP2.2 operations.

Basically these are DDC read and write for authenticating through
HDCP2.2 messages.

v2: Rebased.
v3:
  No more special handling of Gmbus burst read for AKE_SEND_CERT.
  Style fixed with few naming. [Uma]
  %s/PARING/PAIRING
v4:
  msg_sz is initialized at definition.
  Lookup table is defined for HDMI HDCP2.2 msgs [Daniel].
v5: Rebased.
v6:
  Make a function as inline [Uma]
  %s/uintxx_t/uxx
v7:
  Errors due to sinks are reported as DEBUG logs.
  Adjust to the new mei interface.
v8:
  ARRAY_SIZE for the # of array members [Jon & Daniel].
  hdcp adaptation is added as a const in the hdcp_shim [Daniel]

Signed-off-by: Ramalingam C 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/intel_hdmi.c | 189 ++
 1 file changed, 189 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 38fe0fdbf8d8..5f179f1dd4ad 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1134,6 +1134,190 @@ bool intel_hdmi_hdcp_check_link(struct 
intel_digital_port *intel_dig_port)
return true;
 }
 
+static struct hdcp2_hdmi_msg_data {
+   u8 msg_id;
+   u32 timeout;
+   u32 timeout2;
+   } hdcp2_msg_data[] = {
+   {HDCP_2_2_AKE_INIT, 0, 0},
+   {HDCP_2_2_AKE_SEND_CERT, HDCP_2_2_CERT_TIMEOUT_MS, 0},
+   {HDCP_2_2_AKE_NO_STORED_KM, 0, 0},
+   {HDCP_2_2_AKE_STORED_KM, 0, 0},
+   {HDCP_2_2_AKE_SEND_HPRIME, HDCP_2_2_HPRIME_PAIRED_TIMEOUT_MS,
+   HDCP_2_2_HPRIME_NO_PAIRED_TIMEOUT_MS},
+   {HDCP_2_2_AKE_SEND_PAIRING_INFO, HDCP_2_2_PAIRING_TIMEOUT_MS,
+   0},
+   {HDCP_2_2_LC_INIT, 0, 0},
+   {HDCP_2_2_LC_SEND_LPRIME, HDCP_2_2_HDMI_LPRIME_TIMEOUT_MS, 0},
+   {HDCP_2_2_SKE_SEND_EKS, 0, 0},
+   {HDCP_2_2_REP_SEND_RECVID_LIST,
+   HDCP_2_2_RECVID_LIST_TIMEOUT_MS, 0},
+   {HDCP_2_2_REP_SEND_ACK, 0, 0},
+   {HDCP_2_2_REP_STREAM_MANAGE, 0, 0},
+   {HDCP_2_2_REP_STREAM_READY, HDCP_2_2_STREAM_READY_TIMEOUT_MS,
+   0},
+   };
+
+static
+int intel_hdmi_hdcp2_read_rx_status(struct intel_digital_port *intel_dig_port,
+   uint8_t *rx_status)
+{
+   return intel_hdmi_hdcp_read(intel_dig_port,
+   HDCP_2_2_HDMI_REG_RXSTATUS_OFFSET,
+   rx_status,
+   HDCP_2_2_HDMI_RXSTATUS_LEN);
+}
+
+static int get_hdcp2_msg_timeout(u8 msg_id, bool is_paired)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(hdcp2_msg_data); i++)
+   if (hdcp2_msg_data[i].msg_id == msg_id &&
+   (msg_id != HDCP_2_2_AKE_SEND_HPRIME || is_paired))
+   return hdcp2_msg_data[i].timeout;
+   else if (hdcp2_msg_data[i].msg_id == msg_id)
+   return hdcp2_msg_data[i].timeout2;
+
+   return -EINVAL;
+}
+
+static inline
+int hdcp2_detect_msg_availability(struct intel_digital_port 
*intel_digital_port,
+ u8 msg_id, bool *msg_ready,
+ ssize_t *msg_sz)
+{
+   u8 rx_status[HDCP_2_2_HDMI_RXSTATUS_LEN];
+   int ret;
+
+   ret = intel_hdmi_hdcp2_read_rx_status(intel_digital_port, rx_status);
+   if (ret < 0) {
+   DRM_DEBUG_KMS("rx_status read failed. Err %d\n", ret);
+   return ret;
+   }
+
+   *msg_sz = ((HDCP_2_2_HDMI_RXSTATUS_MSG_SZ_HI(rx_status[1]) << 8) |
+ rx_status[0]);
+
+   if (msg_id == HDCP_2_2_REP_SEND_RECVID_LIST)
+   *msg_ready = (HDCP_2_2_HDMI_RXSTATUS_READY(rx_status[1]) &&
+*msg_sz);
+   else
+   *msg_ready = *msg_sz;
+
+   return 0;
+}
+
+static ssize_t
+intel_hdmi_hdcp2_wait_for_msg(struct intel_digital_port *intel_dig_port,
+ u8 msg_id, bool paired)
+{
+   bool msg_ready = false;
+   int timeout, ret;
+   ssize_t msg_sz = 0;
+
+   timeout = get_hdcp2_msg_timeout(msg_id, paired);
+   if (timeout < 0)
+   return timeout;
+
+   ret = __wait_for(ret = hdcp2_detect_msg_availability(intel_dig_port,
+msg_id, _ready,
+_sz),
+!ret && msg_ready && msg_sz, timeout * 1000,
+1000, 5 * 1000);
+   if (ret)
+   DRM_DEBUG_KMS("msg_id: %d, ret: %d, timeout: %d\n",
+ msg_id, ret, timeout);
+
+   return ret ? ret : msg_sz;
+}
+
+static
+int intel_hdmi_hdcp2_write_msg(struct intel_digital_port *intel_dig_port,
+  void *buf, 

[PATCH v9 11/39] drm: helper functions for hdcp2 seq_num to from u32

[Ramalingam C]

Library functions for endianness are aligned for 16/32/64 bits.
But hdcp sequence numbers are 24bits(big endian).
So for their conversion to and from u32 helper functions are developed.

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

diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index a6de09c5e47f..d8093ecf3ddc 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -250,4 +250,22 @@ struct hdcp2_dp_errata_stream_type {
 #define HDCP_2_2_HDMI_RXSTATUS_READY(x)((x) & BIT(2))
 #define HDCP_2_2_HDMI_RXSTATUS_REAUTH_REQ(x)   ((x) & BIT(3))
 
+/*
+ * Library functions for endianness are aligned for 16/32/64 bits.
+ * But hdcp sequence numbers are 24bits(big endian). So for their conversion
+ * from and to u32 below functions are developed.
+ */
+static inline void
+drm_hdcp2_seq_num_to_u32(u32 *val, u8 seq_num[HDCP_2_2_SEQ_NUM_LEN])
+{
+   *val = seq_num[2] | seq_num[1] << 8 | seq_num[0] << 16;
+}
+
+static inline void drm_hdcp2_u32_to_seq_num(u8 *seq_num, u32 val)
+{
+   seq_num[0] = (val & (0xff << 16)) >> 16;
+   seq_num[1] = (val & (0xff << 8)) >> 8;
+   seq_num[2] = val & 0xff;
+}
+
 #endif
-- 
2.7.4

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

[PATCH v9 22/39] misc/mei/hdcp: Client driver for HDCP application

[Ramalingam C]

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

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

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

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

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

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

v2:
  hdcp files are moved to drivers/misc/mei/hdcp/ [Tomas]
v3:
  Squashed the Kbuild support [Tomas]
  UUID renamed and Module License is modified [Tomas]
  drv_data is set to null at remove [Tomas]
v4:
  Module name is changed to "MEI HDCP"
  I915 Selects the MEI_HDCP
v5:
  Remove redundant text from the License header
  Fix malformed licence
  Removed the drv_data resetting.
v6:
  K-Doc addition. [Tomas]

Signed-off-by: Ramalingam C 
Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/Kconfig |  7 +
 drivers/misc/mei/Makefile|  2 ++
 drivers/misc/mei/hdcp/Makefile   |  7 +
 drivers/misc/mei/hdcp/mei_hdcp.c | 65 
 4 files changed, 81 insertions(+)
 create mode 100644 drivers/misc/mei/hdcp/Makefile
 create mode 100644 drivers/misc/mei/hdcp/mei_hdcp.c

diff --git a/drivers/misc/mei/Kconfig b/drivers/misc/mei/Kconfig
index c49e1d2269af..9c518b7f0011 100644
--- a/drivers/misc/mei/Kconfig
+++ b/drivers/misc/mei/Kconfig
@@ -43,3 +43,10 @@ config INTEL_MEI_TXE
 
  Supported SoCs:
  Intel Bay Trail
+
+config INTEL_MEI_HDCP
+   tristate "Intel HDCP2.2 services of ME Interface"
+   select INTEL_MEI_ME
+   depends on DRM_I915
+   help
+ MEI Support for HDCP2.2 Services on Intel SoCs.
diff --git a/drivers/misc/mei/Makefile b/drivers/misc/mei/Makefile
index 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 ..c1a86dd9782b
--- /dev/null
+++ b/drivers/misc/mei/hdcp/Makefile
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
+#
+# Copyright (c) 2017-2018, Intel Corporation.
+#
+# Makefile - HDCP client driver for Intel MEI Bus Driver.
+
+obj-$(CONFIG_INTEL_MEI_HDCP) += mei_hdcp.o
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
new file mode 100644
index ..6e7101512842
--- /dev/null
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -0,0 +1,65 @@
+/* SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) */
+/*
+ * Copyright © 2017-2018 Intel Corporation
+ *
+ * Mei_hdcp.c: HDCP client driver for mei bus
+ *
+ * Authors:
+ * Ramalingam C 
+ */
+
+/**
+ * DOC: MEI_HDCP Client Driver
+ *
+ * This is a client driver to the mei_bus to make the HDCP2.2 services of
+ * ME FW available for the interested consumers like I915.
+ *
+ * This module will act as a translation layer between HDCP protocol
+ * implementor(I915) and ME FW by translating HDCP2.2 authentication
+ * messages to ME FW command payloads and vice versa.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+static int mei_hdcp_probe(struct mei_cl_device *cldev,
+ const struct mei_cl_device_id *id)
+{
+   int ret;
+
+   ret = mei_cldev_enable(cldev);
+   if (ret < 0)
+   dev_err(>dev, "mei_cldev_enable Failed. %d\n", ret);
+
+   return ret;
+}
+
+static int mei_hdcp_remove(struct mei_cl_device *cldev)
+{
+   return mei_cldev_disable(cldev);
+}
+
+#define MEI_UUID_HDCP  UUID_LE(0xB638AB7E, 0x94E2, 0x4EA2, 0xA5, \
+   0x52, 0xD1, 0xC5, 0x4B, \
+   0x62, 0x7F, 0x04)
+
+static struct mei_cl_device_id mei_hdcp_tbl[] = {
+   { .uuid = MEI_UUID_HDCP, .version = MEI_CL_VERSION_ANY },
+   { }
+};
+MODULE_DEVICE_TABLE(mei, mei_hdcp_tbl);
+
+static struct mei_cl_driver mei_hdcp_driver = {
+   .id_table   = mei_hdcp_tbl,
+   .name   = KBUILD_MODNAME,
+   .probe  = mei_hdcp_probe,
+   .remove = mei_hdcp_remove,
+};
+
+module_mei_cl_driver(mei_hdcp_driver);
+
+MODULE_AUTHOR("Intel Corporation");
+MODULE_LICENSE("Dual BSD/GPL");
+MODULE_DESCRIPTION("MEI HDCP");
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org

[PATCH v9 23/39] misc/mei/hdcp: Define ME FW interface for HDCP2.2

[Ramalingam C]

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

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

v2: Rebased.
v3:
  Extra comments are removed.
v4:
  %s/\/\*\*/\/\*
v5:
  Extra lines are removed.
v6:
  Remove redundant text from the License header
  %s/LPRIME_HALF/V_PRIME_HALF
  %s/uintxx_t/uxx
v7:
  Extra taps removed.

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

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.h b/drivers/misc/mei/hdcp/mei_hdcp.h
new file mode 100644
index ..d1456e3dbf22
--- /dev/null
+++ b/drivers/misc/mei/hdcp/mei_hdcp.h
@@ -0,0 +1,366 @@
+/* SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) */
+/*
+ * Copyright © 2017-2018 Intel Corporation
+ *
+ * Authors:
+ * Ramalingam C 
+ */
+
+#ifndef __MEI_HDCP_H__
+#define __MEI_HDCP_H__
+
+#include 
+
+/* me_hdcp_status: Enumeration of all HDCP Status Codes */
+enum me_hdcp_status {
+   ME_HDCP_STATUS_SUCCESS  = 0x,
+
+   /* WiDi Generic Status Codes */
+   ME_HDCP_STATUS_INTERNAL_ERROR   = 0x1000,
+   ME_HDCP_STATUS_UNKNOWN_ERROR= 0x1001,
+   ME_HDCP_STATUS_INCORRECT_API_VERSION= 0x1002,
+   ME_HDCP_STATUS_INVALID_FUNCTION = 0x1003,
+   ME_HDCP_STATUS_INVALID_BUFFER_LENGTH= 0x1004,
+   ME_HDCP_STATUS_INVALID_PARAMS   = 0x1005,
+   ME_HDCP_STATUS_AUTHENTICATION_FAILED= 0x1006,
+
+   /* WiDi Status Codes */
+   ME_HDCP_INVALID_SESSION_STATE   = 0x6000,
+   ME_HDCP_SRM_FRAGMENT_UNEXPECTED = 0x6001,
+   ME_HDCP_SRM_INVALID_LENGTH  = 0x6002,
+   ME_HDCP_SRM_FRAGMENT_OFFSET_INVALID = 0x6003,
+   ME_HDCP_SRM_VERIFICATION_FAILED = 0x6004,
+   ME_HDCP_SRM_VERSION_TOO_OLD = 0x6005,
+   ME_HDCP_RX_CERT_VERIFICATION_FAILED = 0x6006,
+   ME_HDCP_RX_REVOKED  = 0x6007,
+   ME_HDCP_H_VERIFICATION_FAILED   = 0x6008,
+   ME_HDCP_REPEATER_CHECK_UNEXPECTED   = 0x6009,
+   ME_HDCP_TOPOLOGY_MAX_EXCEEDED   = 0x600A,
+   ME_HDCP_V_VERIFICATION_FAILED   = 0x600B,
+   ME_HDCP_L_VERIFICATION_FAILED   = 0x600C,
+   ME_HDCP_STREAM_KEY_ALLOC_FAILED = 0x600D,
+   ME_HDCP_BASE_KEY_RESET_FAILED   = 0x600E,
+   ME_HDCP_NONCE_GENERATION_FAILED = 0x600F,
+   ME_HDCP_STATUS_INVALID_E_KEY_STATE  = 0x6010,
+   ME_HDCP_STATUS_INVALID_CS_ICV   = 0x6011,
+   ME_HDCP_STATUS_INVALID_KB_KEY_STATE = 0x6012,
+   ME_HDCP_STATUS_INVALID_PAVP_MODE_ICV= 0x6013,
+   ME_HDCP_STATUS_INVALID_PAVP_MODE= 0x6014,
+   ME_HDCP_STATUS_LC_MAX_ATTEMPTS  = 0x6015,
+
+   /* New status for HDCP 2.1 */
+   ME_HDCP_STATUS_MISMATCH_IN_M= 0x6016,
+
+   /* New status code for HDCP 2.2 Rx */
+   ME_HDCP_STATUS_RX_PROV_NOT_ALLOWED  = 0x6017,
+   ME_HDCP_STATUS_RX_PROV_WRONG_SUBJECT= 0x6018,
+   ME_HDCP_RX_NEEDS_PROVISIONING   = 0x6019,
+   ME_HDCP_BKSV_ICV_AUTH_FAILED= 0x6020,
+   ME_HDCP_STATUS_INVALID_STREAM_ID= 0x6021,
+   ME_HDCP_STATUS_CHAIN_NOT_INITIALIZED= 0x6022,
+   ME_HDCP_FAIL_NOT_EXPECTED   = 0x6023,
+   ME_HDCP_FAIL_HDCP_OFF   = 0x6024,
+   ME_HDCP_FAIL_INVALID_PAVP_MEMORY_MODE   = 0x6025,
+   ME_HDCP_FAIL_AES_ECB_FAILURE= 0x6026,
+   ME_HDCP_FEATURE_NOT_SUPPORTED   = 0x6027,
+   ME_HDCP_DMA_READ_ERROR  = 0x6028,
+   ME_HDCP_DMA_WRITE_ERROR = 0x6029,
+   ME_HDCP_FAIL_INVALID_PACKET_SIZE= 0x6030,
+   ME_HDCP_H264_PARSING_ERROR  = 0x6031,
+   ME_HDCP_HDCP2_ERRATA_VIDEO_VIOLATION= 0x6032,
+   ME_HDCP_HDCP2_ERRATA_AUDIO_VIOLATION= 0x6033,
+   ME_HDCP_TX_ACTIVE_ERROR = 0x6034,
+   ME_HDCP_MODE_CHANGE_ERROR   = 0x6035,
+   ME_HDCP_STREAM_TYPE_ERROR   = 0x6036,
+   ME_HDCP_STREAM_MANAGE_NOT_POSSIBLE  = 0x6037,
+
+   ME_HDCP_STATUS_PORT_INVALID_COMMAND = 0x6038,
+   ME_HDCP_STATUS_UNSUPPORTED_PROTOCOL = 0x6039,
+   ME_HDCP_STATUS_INVALID_PORT_INDEX   = 0x603a,
+   ME_HDCP_STATUS_TX_AUTH_NEEDED   = 0x603b,
+   ME_HDCP_STATUS_NOT_INTEGRATED_PORT  = 0x603c,
+   ME_HDCP_STATUS_SESSION_MAX_REACHED  = 0x603d,
+
+   /* hdcp capable bit is not set in rx_caps(error is unique to DP) */
+   ME_HDCP_STATUS_NOT_HDCP_CAPABLE = 0x6041,
+
+   ME_HDCP_STATUS_INVALID_STREAM_COUNT = 0x6042,
+};
+
+#define HDCP_API_VERSION   0x0001
+
+#define HDCP_M_LEN 16

[PATCH v9 15/39] drm/i915: Handle HDCP2.2 downstream topology change

[Ramalingam C]

When repeater notifies a downstream topology change, this patch
reauthenticate the repeater alone without disabling the hdcp
encryption. If that fails then complete reauthentication is executed.

v2:
  Rebased.
v3:
  Typo in commit msg is fixed [Uma]
v4:
  Rebased as part of patch reordering.
  Minor style fixes.
v5:
  Rebased.
v6:
  Rebased.
v7:
  Errors due to sinks are reported as DEBUG logs.

Signed-off-by: Ramalingam C 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 6fac570fcbac..cafda8903b50 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -1537,8 +1537,24 @@ static int intel_hdcp2_check_link(struct intel_connector 
*connector)
goto out;
}
 
-   DRM_DEBUG_KMS("[%s:%d] HDCP2.2 link failed, retrying auth\n",
- connector->base.name, connector->base.base.id);
+   if (ret == DRM_HDCP_TOPOLOGY_CHANGE) {
+   if (hdcp->value == DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
+   goto out;
+
+   DRM_DEBUG_KMS("HDCP2.2 Downstream topology change\n");
+   ret = hdcp2_authenticate_repeater_topology(connector);
+   if (!ret) {
+   hdcp->value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
+   schedule_work(>prop_work);
+   goto out;
+   }
+   DRM_DEBUG_KMS("[%s:%d] Repeater topology auth failed.(%d)\n",
+ connector->base.name, connector->base.base.id,
+ ret);
+   } else {
+   DRM_DEBUG_KMS("[%s:%d] HDCP2.2 link failed, retrying auth\n",
+ connector->base.name, connector->base.base.id);
+   }
 
ret = _intel_hdcp2_disable(connector);
if (ret) {
-- 
2.7.4

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

[PATCH v9 18/39] drm/i915: Add HDCP2.2 support for DP connectors

[Ramalingam C]

On DP connector init, intel_hdcp_init is passed with a flag for hdcp2.2
support based on the platform capability.

v2:
  Rebased.
v3:
  Collected the reviewed-by received.

Signed-off-by: Ramalingam C 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/intel_dp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index a8ace7d85918..87078dcc372c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -7213,7 +7213,7 @@ intel_dp_init_connector(struct intel_digital_port 
*intel_dig_port,
 
if (is_hdcp_supported(dev_priv, port) && !intel_dp_is_edp(intel_dp)) {
int ret = intel_hdcp_init(intel_connector, _dp_hdcp_shim,
- false);
+ is_hdcp2_supported(dev_priv));
if (ret)
DRM_DEBUG_KMS("HDCP init failed, skipping.\n");
}
-- 
2.7.4

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

[PATCH v9 13/39] drm: HDCP2.2 link check related constants

[Ramalingam C]

Enums and macros are defined for HDCP2.2 link check.

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

diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index d8093ecf3ddc..21a128e7020a 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_response {
+   DRM_HDCP_LINK_PROTECTED = 0,
+   DRM_HDCP_TOPOLOGY_CHANGE,
+   DRM_HDCP_LINK_INTEGRITY_FAILURE,
+   DRM_HDCP_REAUTH_REQUEST
+};
 
 /* Shared lengths/masks between HDMI/DVI/DisplayPort */
 #define DRM_HDCP_AN_LEN8
-- 
2.7.4

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

[PATCH v9 09/39] drm/i915: Enable and Disable of HDCP2.2

[Ramalingam C]

Considering that HDCP2.2 is more secure than HDCP1.4, When a setup
supports HDCP2.2 and HDCP1.4, HDCP2.2 will be enabled.

When HDCP2.2 enabling fails and HDCP1.4 is supported, HDCP1.4 is
enabled.

This change implements a sequence of enabling and disabling of
HDCP2.2 authentication and HDCP2.2 port encryption.

v2:
  Included few optimization suggestions [Chris Wilson]
  Commit message is updated as per the rebased version.
  intel_wait_for_register is used instead of wait_for. [Chris Wilson]
v3:
  Extra comment added and Style issue fixed [Uma]
v4:
  Rebased as part of patch reordering.
  HDCP2 encryption status is tracked.
  HW state check is moved into WARN_ON [Daniel]
v5:
  Redefined the mei service functions as per comp redesign.
  Merged patches related to hdcp2.2 enabling and disabling [Sean Paul].
  Required shim functionality is defined [Sean Paul]
v6:
  Return values are handles [Uma]
  Realigned the code.
  Check for comp_master is removed.
v7:
  HDCP2.2 is attempted only if mei interface is up.
  Adjust to the new interface
  Avoid bool usage in struct [Tomas]
v8:
  mei_binded status check is removed.
  %s/hdcp2_in_use/hdcp2_encrypted

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/intel_drv.h  |   7 ++
 drivers/gpu/drm/i915/intel_hdcp.c | 202 +++---
 2 files changed, 195 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index decd0346c6a7..6d5361616ca3 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -383,6 +383,10 @@ struct intel_hdcp_shim {
 
/* HDCP adaptation(DP/HDMI) required on the port */
enum hdcp_wired_protocol protocol;
+
+   /* Detects whether Panel is HDCP2.2 capable */
+   int (*hdcp_2_2_capable)(struct intel_digital_port *intel_dig_port,
+   bool *capable);
 };
 
 struct intel_hdcp {
@@ -400,6 +404,9 @@ struct intel_hdcp {
/* Flag indicates whether this connector supports HDCP2.2 or not. */
u8 hdcp2_supported;
 
+   /* HDCP2.2 Encryption status */
+   u8 hdcp2_encrypted;
+
/*
 * Content Stream Type defined by content owner. TYPE0(0x0) content can
 * flow in the link protected by HDCP2.2 or HDCP1.4, where as TYPE1(0x1)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 2b7814a6f12b..f0ee448e6546 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -75,6 +75,23 @@ bool intel_hdcp_capable(struct intel_connector *connector)
return capable;
 }
 
+/* Is HDCP2.2 capable on Platform and Sink */
+static bool intel_hdcp2_capable(struct intel_connector *connector)
+{
+   struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+   struct intel_hdcp *hdcp = >hdcp;
+   bool capable = false;
+
+   /* I915 support for HDCP2.2 */
+   if (!hdcp->hdcp2_supported)
+   return false;
+
+   /* Sink's capability for HDCP2.2 */
+   hdcp->shim->hdcp_2_2_capable(intel_dig_port, );
+
+   return capable;
+}
+
 static inline bool intel_hdcp_in_use(struct intel_connector *connector)
 {
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
@@ -1014,8 +1031,7 @@ int hdcp2_authenticate_port(struct intel_connector 
*connector)
return ret;
 }
 
-static __attribute__((unused))
-int hdcp2_close_mei_session(struct intel_connector *connector)
+static int hdcp2_close_mei_session(struct intel_connector *connector)
 {
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct i915_component_master *comp = dev_priv->comp_master;
@@ -1024,12 +1040,157 @@ int hdcp2_close_mei_session(struct intel_connector 
*connector)
  >hdcp.port_data);
 }
 
-static __attribute__((unused))
-int hdcp2_deauthenticate_port(struct intel_connector *connector)
+static int hdcp2_deauthenticate_port(struct intel_connector *connector)
 {
return hdcp2_close_mei_session(connector);
 }
 
+static int hdcp2_authenticate_sink(struct intel_connector *connector)
+{
+   DRM_ERROR("Sink authentication is done in subsequent patches\n");
+
+   return -EINVAL;
+}
+
+static int hdcp2_enable_encryption(struct intel_connector *connector)
+{
+   struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_hdcp *hdcp = >hdcp;
+   enum port port = connector->encoder->port;
+   int ret;
+
+   WARN_ON(I915_READ(HDCP2_STATUS_DDI(port)) & LINK_ENCRYPTION_STATUS);
+
+   if (hdcp->shim->toggle_signalling) {
+   ret = hdcp->shim->toggle_signalling(intel_dig_port, true);
+   if (ret) {
+   DRM_ERROR("Failed to enable HDCP signalling. %d\n",
+ ret);
+   

[PATCH v9 10/39] drm/i915: Implement HDCP2.2 receiver authentication

[Ramalingam C]

Implements HDCP2.2 authentication for hdcp2.2 receivers, with
following steps:
Authentication and Key exchange (AKE).
Locality Check (LC).
Session Key Exchange(SKE).
DP Errata for stream type configuration for receivers.

At AKE, the HDCP Receiver’s public key certificate is verified by the
HDCP Transmitter. A Master Key k m is exchanged.

At LC, the HDCP Transmitter enforces locality on the content by
requiring that the Round Trip Time (RTT) between a pair of messages
is not more than 20 ms.

At SKE, The HDCP Transmitter exchanges Session Key ks with
the HDCP Receiver.

In DP HDCP2.2 encryption and decryption logics use the stream type as
one of the parameter. So Before enabling the Encryption DP HDCP2.2
receiver needs to be communicated with stream type. This is added to
spec as ERRATA.

This generic implementation is complete only with the hdcp2 specific
functions defined at hdcp_shim.

v2: Rebased.
v3:
  %s/PARING/PAIRING
  Coding style fixing [Uma]
v4:
  Rebased as part of patch reordering.
  Defined the functions for mei services. [Daniel]
v5:
  Redefined the mei service functions as per comp redesign.
  Required intel_hdcp members are defined [Sean Paul]
v6:
  Typo of cipher is Fixed [Uma]
  %s/uintxx_t/uxx
  Check for comp_master is removed.
v7:
  Adjust to the new interface.
  Avoid using bool structure members. [Tomas]
v8: Rebased.

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/intel_drv.h  |  34 ++
 drivers/gpu/drm/i915/intel_hdcp.c | 211 +++---
 2 files changed, 230 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 6d5361616ca3..a6b632d71490 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -387,6 +387,22 @@ struct intel_hdcp_shim {
/* Detects whether Panel is HDCP2.2 capable */
int (*hdcp_2_2_capable)(struct intel_digital_port *intel_dig_port,
bool *capable);
+
+   /* Write HDCP2.2 messages */
+   int (*write_2_2_msg)(struct intel_digital_port *intel_dig_port,
+void *buf, size_t size);
+
+   /* Read HDCP2.2 messages */
+   int (*read_2_2_msg)(struct intel_digital_port *intel_dig_port,
+   u8 msg_id, void *buf, size_t size);
+
+   /*
+* Implementation of DP HDCP2.2 Errata for the communication of stream
+* type to Receivers. In DP HDCP2.2 Stream type is one of the input to
+* the HDCP2.2 Cipher for En/De-Cryption. Not applicable for HDMI.
+*/
+   int (*config_stream_type)(struct intel_digital_port *intel_dig_port,
+ void *buf, size_t size);
 };
 
 struct intel_hdcp {
@@ -414,6 +430,24 @@ struct intel_hdcp {
 */
u8 content_type;
struct hdcp_port_data port_data;
+
+   u8 is_paired;
+   u8 is_repeater;
+
+   /*
+* Count of ReceiverID_List received. Initialized to 0 at AKE_INIT.
+* Incremented after processing the RepeaterAuth_Send_ReceiverID_List.
+* When it rolls over re-auth has to be triggered.
+*/
+   u32 seq_num_v;
+
+   /*
+* Count of RepeaterAuth_Stream_Manage msg propagated.
+* Initialized to 0 on AKE_INIT. Incremented after every successful
+* transmission of RepeaterAuth_Stream_Manage message. When it rolls
+* over re-Auth has to be triggered.
+*/
+   u32 seq_num_m;
 };
 
 struct intel_connector {
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index f0ee448e6546..f1f0ef294e20 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -18,6 +18,7 @@
 
 #define KEY_LOAD_TRIES 5
 #define ENCRYPT_STATUS_CHANGE_TIMEOUT_MS   50
+#define HDCP2_LC_RETRY_CNT 3
 
 static
 bool intel_hdcp_is_ksv_valid(u8 *ksv)
@@ -854,7 +855,7 @@ bool is_hdcp_supported(struct drm_i915_private *dev_priv, 
enum port port)
return INTEL_GEN(dev_priv) >= 9 && port < PORT_E;
 }
 
-static __attribute__((unused)) int
+static int
 hdcp2_prepare_ake_init(struct intel_connector *connector,
   struct hdcp2_ake_init *ake_data)
 {
@@ -875,7 +876,7 @@ hdcp2_prepare_ake_init(struct intel_connector *connector,
return ret;
 }
 
-static __attribute__((unused)) int
+static int
 hdcp2_verify_rx_cert_prepare_km(struct intel_connector *connector,
struct hdcp2_ake_send_cert *rx_cert,
bool *paired,
@@ -897,9 +898,8 @@ hdcp2_verify_rx_cert_prepare_km(struct intel_connector 
*connector,
return ret;
 }
 
-static __attribute__((unused)) int
-hdcp2_verify_hprime(struct intel_connector *connector,
-   struct hdcp2_ake_send_hprime *rx_hprime)
+static int hdcp2_verify_hprime(struct intel_connector *connector,
+  struct 

[PATCH v9 07/39] drm/i915: MEI interface definition

[Ramalingam C]

Defining the mei-i915 interface functions and initialization of
the interface.

v2:
  Adjust to the new interface changes. [Tomas]
  Added further debug logs for the failures at MEI i/f.
  port in hdcp_port data is equipped to handle -ve values.
v3:
  mei comp is matched for global i915 comp master. [Daniel]
  In hdcp_shim hdcp_protocol() is replaced with const variable. [Daniel]
  mei wrappers are adjusted as per the i/f change [Daniel]

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/intel_drv.h  |   5 +
 drivers/gpu/drm/i915/intel_hdcp.c | 248 +-
 include/drm/i915_component.h  |   7 ++
 3 files changed, 259 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index dd9371647a8c..191b6e0f086c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /**
@@ -379,6 +380,9 @@ struct intel_hdcp_shim {
/* Detects panel's hdcp capability. This is optional for HDMI. */
int (*hdcp_capable)(struct intel_digital_port *intel_dig_port,
bool *hdcp_capable);
+
+   /* HDCP adaptation(DP/HDMI) required on the port */
+   enum hdcp_wired_protocol protocol;
 };
 
 struct intel_hdcp {
@@ -399,6 +403,7 @@ struct intel_hdcp {
 * content can flow only through a link protected by HDCP2.2.
 */
u8 content_type;
+   struct hdcp_port_data port_data;
 };
 
 struct intel_connector {
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 584d27f3c699..9405fce07b93 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -8,8 +8,10 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 
 #include "intel_drv.h"
 #include "i915_reg.h"
@@ -833,6 +835,232 @@ bool is_hdcp_supported(struct drm_i915_private *dev_priv, 
enum port port)
return INTEL_GEN(dev_priv) >= 9 && port < PORT_E;
 }
 
+static __attribute__((unused)) int
+hdcp2_prepare_ake_init(struct intel_connector *connector,
+  struct hdcp2_ake_init *ake_data)
+{
+   struct hdcp_port_data *data = >hdcp.port_data;
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct i915_component_master *comp = dev_priv->comp_master;
+   int ret;
+
+   /* During the connector init encoder might not be initialized */
+   if (data->port == PORT_NONE)
+   data->port = connector->encoder->port;
+
+   ret = comp->hdcp_ops->initiate_hdcp2_session(comp->mei_dev,
+data, ake_data);
+   if (ret)
+   DRM_DEBUG_KMS("Prepare_ake_init failed. %d\n", ret);
+
+   return ret;
+}
+
+static __attribute__((unused)) int
+hdcp2_verify_rx_cert_prepare_km(struct intel_connector *connector,
+   struct hdcp2_ake_send_cert *rx_cert,
+   bool *paired,
+   struct hdcp2_ake_no_stored_km *ek_pub_km,
+   size_t *msg_sz)
+{
+   struct hdcp_port_data *data = >hdcp.port_data;
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct i915_component_master *comp = dev_priv->comp_master;
+   int ret;
+
+   ret = comp->hdcp_ops->verify_receiver_cert_prepare_km(comp->mei_dev,
+ data, rx_cert,
+ paired, ek_pub_km,
+ msg_sz);
+   if (ret < 0)
+   DRM_DEBUG_KMS("Verify rx_cert failed. %d\n", ret);
+
+   return ret;
+}
+
+static __attribute__((unused)) int
+hdcp2_verify_hprime(struct intel_connector *connector,
+   struct hdcp2_ake_send_hprime *rx_hprime)
+{
+   struct hdcp_port_data *data = >hdcp.port_data;
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct i915_component_master *comp = dev_priv->comp_master;
+   int ret;
+
+   ret = comp->hdcp_ops->verify_hprime(comp->mei_dev, data, rx_hprime);
+   if (ret < 0)
+   DRM_DEBUG_KMS("Verify hprime failed. %d\n", ret);
+
+   return ret;
+}
+
+static __attribute__((unused)) int
+hdcp2_store_pairing_info(struct intel_connector *connector,
+struct hdcp2_ake_send_pairing_info *pairing_info)
+{
+   struct hdcp_port_data *data = >hdcp.port_data;
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct i915_component_master *comp = dev_priv->comp_master;
+   int ret;
+
+   ret = comp->hdcp_ops->store_pairing_info(comp->mei_dev, data,
+pairing_info);
+   if (ret < 0)
+   DRM_DEBUG_KMS("Store pairing info failed. 

[PATCH v9 08/39] drm/i915: hdcp1.4 CP_IRQ handling and SW encryption tracking

[Ramalingam C]

"hdcp_encrypted" flag is defined to denote the HDCP1.4 encryption status.
This SW tracking is used to determine the need for real hdcp1.4 disable
and hdcp_check_link upon CP_IRQ.

On CP_IRQ we filter the CP_IRQ related to the states like Link failure
and reauthentication req etc and handle them in hdcp_check_link.
CP_IRQ corresponding to the authentication msg availability are ignored.

WARN_ON is added for the abrupt stop of HDCP encryption of a port.

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/intel_dp.c   |  2 +-
 drivers/gpu/drm/i915/intel_drv.h  |  5 ++-
 drivers/gpu/drm/i915/intel_hdcp.c | 89 ++-
 3 files changed, 74 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index aba884c64879..89315e15fb34 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4758,7 +4758,7 @@ static void intel_dp_check_service_irq(struct intel_dp 
*intel_dp)
intel_dp_handle_test_request(intel_dp);
 
if (val & DP_CP_IRQ)
-   intel_hdcp_check_link(intel_dp->attached_connector);
+   intel_hdcp_handle_cp_irq(intel_dp->attached_connector);
 
if (val & DP_SINK_SPECIFIC_IRQ)
DRM_DEBUG_DRIVER("Sink specific irq unhandled\n");
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 191b6e0f086c..decd0346c6a7 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -393,6 +393,9 @@ struct intel_hdcp {
struct delayed_work check_work;
struct work_struct prop_work;
 
+   /* HDCP1.4 Encryption status */
+   u8 hdcp_encrypted;
+
/* HDCP2.2 related definitions */
/* Flag indicates whether this connector supports HDCP2.2 or not. */
u8 hdcp2_supported;
@@ -2058,10 +2061,10 @@ int intel_hdcp_init(struct intel_connector *connector,
bool hdcp2_supported);
 int intel_hdcp_enable(struct intel_connector *connector);
 int intel_hdcp_disable(struct intel_connector *connector);
-int intel_hdcp_check_link(struct intel_connector *connector);
 bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port);
 bool intel_hdcp_capable(struct intel_connector *connector);
 bool is_hdcp2_supported(struct drm_i915_private *dev_priv);
+void intel_hdcp_handle_cp_irq(struct intel_connector *connector);
 
 /* intel_psr.c */
 #define CAN_PSR(dev_priv) (HAS_PSR(dev_priv) && dev_priv->psr.sink_support)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 9405fce07b93..2b7814a6f12b 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -75,6 +75,16 @@ bool intel_hdcp_capable(struct intel_connector *connector)
return capable;
 }
 
+static inline bool intel_hdcp_in_use(struct intel_connector *connector)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   enum port port = connector->encoder->port;
+   u32 reg;
+
+   reg = I915_READ(PORT_HDCP_STATUS(port));
+   return reg & HDCP_STATUS_ENC;
+}
+
 static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
const struct intel_hdcp_shim *shim)
 {
@@ -669,6 +679,7 @@ static int _intel_hdcp_disable(struct intel_connector 
*connector)
DRM_DEBUG_KMS("[%s:%d] HDCP is being disabled...\n",
  connector->base.name, connector->base.base.id);
 
+   hdcp->hdcp_encrypted = 0;
I915_WRITE(PORT_HDCP_CONF(port), 0);
if (intel_wait_for_register(dev_priv, PORT_HDCP_STATUS(port), ~0, 0,
ENCRYPT_STATUS_CHANGE_TIMEOUT_MS)) {
@@ -714,8 +725,10 @@ static int _intel_hdcp_enable(struct intel_connector 
*connector)
/* Incase of authentication failures, HDCP spec expects reauth. */
for (i = 0; i < tries; i++) {
ret = intel_hdcp_auth(conn_to_dig_port(connector), hdcp->shim);
-   if (!ret)
+   if (!ret) {
+   hdcp->hdcp_encrypted = 1;
return 0;
+   }
 
DRM_DEBUG_KMS("HDCP Auth failure (%d)\n", ret);
 
@@ -742,16 +755,17 @@ int intel_hdcp_check_link(struct intel_connector 
*connector)
enum port port = intel_dig_port->base.port;
int ret = 0;
 
-   if (!hdcp->shim)
-   return -ENOENT;
-
mutex_lock(>mutex);
 
-   if (hdcp->value == DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
+   /* Check_link valid only when HDCP1.4 is enabled */
+   if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_ENABLED ||
+   !hdcp->hdcp_encrypted) {
+   ret = -EINVAL;
goto out;
+   }
 
-   if (!(I915_READ(PORT_HDCP_STATUS(port)) & HDCP_STATUS_ENC)) {
-   DRM_ERROR("%s:%d HDCP check failed: link is not encrypted,%x\n",
+   if 

[PATCH v9 03/39] drivers/base: use a worker for sysfs unbind

[Ramalingam C]

From: Daniel Vetter 

Drivers might want to remove some sysfs files, which needs the same
locks and ends up angering lockdep. Relevant snippet of the stack
trace:

  kernfs_remove_by_name_ns+0x3b/0x80
  bus_remove_driver+0x92/0xa0
  acpi_video_unregister+0x24/0x40
  i915_driver_unload+0x42/0x130 [i915]
  i915_pci_remove+0x19/0x30 [i915]
  pci_device_remove+0x36/0xb0
  device_release_driver_internal+0x185/0x250
  unbind_store+0xaf/0x180
  kernfs_fop_write+0x104/0x190

I've stumbled over this because some new patches by Ram connect the
snd-hda-intel unload (where we do use sysfs unbind) with the locking
chains in the i915 unload code (but without creating a new loop),
which upset our CI. But the bug is already there and can be easily
reproduced by unbind i915 directly.

No idea whether this is the correct place to fix this, should at least
get CI happy again.

Note that the bus locking is already done by device_release_driver ->
device_release_driver_internal, so I dropped that part. Also note that
we don't recheck that the device is still bound by the same driver,
but neither does the current code do that without races. And I figured
that's a obscure enough corner case to not bother.

v2: Use a task work. An entirely async work leads to impressive
fireworks in our CI, notably in the vtcon bind/unbind code. Task work
will be as synchronous as the current code, and so keep all these
preexisting races neatly tugged under the rug.

Cc: Ramalingam C 
Signed-off-by: Daniel Vetter 
---
 drivers/base/bus.c | 35 +--
 1 file changed, 29 insertions(+), 6 deletions(-)

diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index 8bfd27ec73d6..095c4a140d76 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "base.h"
 #include "power/power.h"
 
@@ -174,22 +175,44 @@ static const struct kset_uevent_ops bus_uevent_ops = {
 
 static struct kset *bus_kset;
 
+struct unbind_work {
+   struct callback_head twork;
+   struct device *dev;
+};
+
+void unbind_work_fn(struct callback_head *work)
+{
+   struct unbind_work *unbind_work =
+   container_of(work, struct unbind_work, twork);
+
+   device_release_driver_internal(unbind_work->dev, NULL,
+  unbind_work->dev->parent);
+   put_device(unbind_work->dev);
+   kfree(unbind_work);
+}
+
 /* Manually detach a device from its associated driver. */
 static ssize_t unbind_store(struct device_driver *drv, const char *buf,
size_t count)
 {
struct bus_type *bus = bus_get(drv->bus);
+   struct unbind_work *unbind_work;
struct device *dev;
int err = -ENODEV;
 
dev = bus_find_device_by_name(bus, NULL, buf);
if (dev && dev->driver == drv) {
-   if (dev->parent && dev->bus->need_parent_lock)
-   device_lock(dev->parent);
-   device_release_driver(dev);
-   if (dev->parent && dev->bus->need_parent_lock)
-   device_unlock(dev->parent);
-   err = count;
+   unbind_work = kmalloc(sizeof(*unbind_work), GFP_KERNEL);
+   if (unbind_work) {
+   unbind_work->dev = dev;
+   get_device(dev);
+   init_task_work(_work->twork, unbind_work_fn);
+   task_work_add(current, _work->twork, true);
+
+   err = count;
+   } else {
+   err = -ENOMEM;
+   }
}
put_device(dev);
bus_put(bus);
-- 
2.7.4

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

[PATCH v9 01/39] drm/i915: Gathering the HDCP1.4 routines together

[Ramalingam C]

All HDCP1.4 routines are gathered together, followed by the generic
functions those can be extended for HDCP2.2 too.

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 118 +++---
 1 file changed, 59 insertions(+), 59 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index e000e54ad569..506b4cc6f46b 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -731,6 +731,65 @@ struct intel_connector *intel_hdcp_to_connector(struct 
intel_hdcp *hdcp)
return container_of(hdcp, struct intel_connector, hdcp);
 }
 
+/* Implements Part 3 of the HDCP authorization procedure */
+int intel_hdcp_check_link(struct intel_connector *connector)
+{
+   struct intel_hdcp *hdcp = >hdcp;
+   struct drm_i915_private *dev_priv = connector->base.dev->dev_private;
+   struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+   enum port port = intel_dig_port->base.port;
+   int ret = 0;
+
+   if (!hdcp->shim)
+   return -ENOENT;
+
+   mutex_lock(>mutex);
+
+   if (hdcp->value == DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
+   goto out;
+
+   if (!(I915_READ(PORT_HDCP_STATUS(port)) & HDCP_STATUS_ENC)) {
+   DRM_ERROR("%s:%d HDCP check failed: link is not encrypted,%x\n",
+ connector->base.name, connector->base.base.id,
+ I915_READ(PORT_HDCP_STATUS(port)));
+   ret = -ENXIO;
+   hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
+   schedule_work(>prop_work);
+   goto out;
+   }
+
+   if (hdcp->shim->check_link(intel_dig_port)) {
+   if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
+   hdcp->value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
+   schedule_work(>prop_work);
+   }
+   goto out;
+   }
+
+   DRM_DEBUG_KMS("[%s:%d] HDCP link failed, retrying authentication\n",
+ connector->base.name, connector->base.base.id);
+
+   ret = _intel_hdcp_disable(connector);
+   if (ret) {
+   DRM_ERROR("Failed to disable hdcp (%d)\n", ret);
+   hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
+   schedule_work(>prop_work);
+   goto out;
+   }
+
+   ret = _intel_hdcp_enable(connector);
+   if (ret) {
+   DRM_ERROR("Failed to enable hdcp (%d)\n", ret);
+   hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
+   schedule_work(>prop_work);
+   goto out;
+   }
+
+out:
+   mutex_unlock(>mutex);
+   return ret;
+}
+
 static void intel_hdcp_check_work(struct work_struct *work)
 {
struct intel_hdcp *hdcp = container_of(to_delayed_work(work),
@@ -867,62 +926,3 @@ void intel_hdcp_atomic_check(struct drm_connector 
*connector,
   new_state->crtc);
crtc_state->mode_changed = true;
 }
-
-/* Implements Part 3 of the HDCP authorization procedure */
-int intel_hdcp_check_link(struct intel_connector *connector)
-{
-   struct intel_hdcp *hdcp = >hdcp;
-   struct drm_i915_private *dev_priv = connector->base.dev->dev_private;
-   struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
-   enum port port = intel_dig_port->base.port;
-   int ret = 0;
-
-   if (!hdcp->shim)
-   return -ENOENT;
-
-   mutex_lock(>mutex);
-
-   if (hdcp->value == DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
-   goto out;
-
-   if (!(I915_READ(PORT_HDCP_STATUS(port)) & HDCP_STATUS_ENC)) {
-   DRM_ERROR("%s:%d HDCP check failed: link is not encrypted,%x\n",
- connector->base.name, connector->base.base.id,
- I915_READ(PORT_HDCP_STATUS(port)));
-   ret = -ENXIO;
-   hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
-   schedule_work(>prop_work);
-   goto out;
-   }
-
-   if (hdcp->shim->check_link(intel_dig_port)) {
-   if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
-   hdcp->value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
-   schedule_work(>prop_work);
-   }
-   goto out;
-   }
-
-   DRM_DEBUG_KMS("[%s:%d] HDCP link failed, retrying authentication\n",
- connector->base.name, connector->base.base.id);
-
-   ret = _intel_hdcp_disable(connector);
-   if (ret) {
-   DRM_ERROR("Failed to disable hdcp (%d)\n", ret);
-   hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
-   schedule_work(>prop_work);
-   goto out;
-   }
-
-   ret = _intel_hdcp_enable(connector);
-   if (ret) {
-   DRM_DEBUG_KMS("Failed 

[PATCH v9 06/39] drm/i915: Initialize HDCP2.2

[Ramalingam C]

Add the HDCP2.2 initialization to the existing HDCP1.4 stack.

v2:
  mei interface handle is protected with mutex. [Chris Wilson]
v3:
  Notifiers are used for the mei interface state.
v4:
  Poll for mei client device state
  Error msg for out of mem [Uma]
  Inline req for init function removed [Uma]
v5:
  Rebase as Part of reordering.
  Component is used for the I915 and MEI_HDCP interface [Daniel]
v6:
  HDCP2.2 uses the I915 component master to communicate with mei_hdcp
- [Daniel]
  Required HDCP2.2 variables defined [Sean Paul]
v7:
  intel_hdcp2.2_init returns void [Uma]
  Realigning the codes.
v8:
  Avoid using bool structure members.
  MEI interface related changes are moved into separate patch.
  Commit msg is updated accordingly.
  intel_hdcp_exit is defined and used from i915_unload
v9:
  Movement of the hdcp_check_link is moved to new patch [Daniel]
  intel_hdcp2_exit is removed as mei_comp will be unbind in i915_unload.

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/intel_dp.c   |  3 ++-
 drivers/gpu/drm/i915/intel_drv.h  | 15 ++-
 drivers/gpu/drm/i915/intel_hdcp.c | 30 +++---
 drivers/gpu/drm/i915/intel_hdmi.c |  2 +-
 4 files changed, 44 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e94faa0a42eb..aba884c64879 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -6902,7 +6902,8 @@ intel_dp_init_connector(struct intel_digital_port 
*intel_dig_port,
intel_dp_add_properties(intel_dp, connector);
 
if (is_hdcp_supported(dev_priv, port) && !intel_dp_is_edp(intel_dp)) {
-   int ret = intel_hdcp_init(intel_connector, _dp_hdcp_shim);
+   int ret = intel_hdcp_init(intel_connector, _dp_hdcp_shim,
+ false);
if (ret)
DRM_DEBUG_KMS("HDCP init failed, skipping.\n");
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d08f08f607dd..dd9371647a8c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -388,6 +388,17 @@ struct intel_hdcp {
u64 value;
struct delayed_work check_work;
struct work_struct prop_work;
+
+   /* HDCP2.2 related definitions */
+   /* Flag indicates whether this connector supports HDCP2.2 or not. */
+   u8 hdcp2_supported;
+
+   /*
+* Content Stream Type defined by content owner. TYPE0(0x0) content can
+* flow in the link protected by HDCP2.2 or HDCP1.4, where as TYPE1(0x1)
+* content can flow only through a link protected by HDCP2.2.
+*/
+   u8 content_type;
 };
 
 struct intel_connector {
@@ -2038,12 +2049,14 @@ void intel_hdcp_atomic_check(struct drm_connector 
*connector,
 struct drm_connector_state *old_state,
 struct drm_connector_state *new_state);
 int intel_hdcp_init(struct intel_connector *connector,
-   const struct intel_hdcp_shim *hdcp_shim);
+   const struct intel_hdcp_shim *hdcp_shim,
+   bool hdcp2_supported);
 int intel_hdcp_enable(struct intel_connector *connector);
 int intel_hdcp_disable(struct intel_connector *connector);
 int intel_hdcp_check_link(struct intel_connector *connector);
 bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port);
 bool intel_hdcp_capable(struct intel_connector *connector);
+bool is_hdcp2_supported(struct drm_i915_private *dev_priv);
 
 /* intel_psr.c */
 #define CAN_PSR(dev_priv) (HAS_PSR(dev_priv) && dev_priv->psr.sink_support)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 506b4cc6f46b..584d27f3c699 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -833,14 +833,34 @@ bool is_hdcp_supported(struct drm_i915_private *dev_priv, 
enum port port)
return INTEL_GEN(dev_priv) >= 9 && port < PORT_E;
 }
 
+bool is_hdcp2_supported(struct drm_i915_private *dev_priv)
+{
+   return ((INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv) ||
+IS_KABYLAKE(dev_priv)) && IS_ENABLED(CONFIG_INTEL_MEI_HDCP));
+}
+
+static void intel_hdcp2_init(struct intel_connector *connector)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_hdcp *hdcp = >hdcp;
+
+   WARN_ON(!is_hdcp2_supported(dev_priv));
+
+   /* TODO: MEI interface needs to be initialized here */
+   hdcp->hdcp2_supported = 1;
+}
+
 int intel_hdcp_init(struct intel_connector *connector,
-   const struct intel_hdcp_shim *shim)
+   const struct intel_hdcp_shim *shim,
+   bool hdcp2_supported)
 {
struct intel_hdcp *hdcp = >hdcp;
int ret;
 
-   ret = drm_connector_attach_content_protection_property(
-   >base);
+   

[PATCH v9 04/39] component: alloc component_match without any comp to match

[Ramalingam C]

If all the components associated to a component master is not added
to the component framework due to the HW capability or Kconfig
selection, component_match will be NULL at
component_master_add_with_match().

To avoid this, component_match_alloc() is added to the framework,
to allcoate the struct component_match with zero associated components.
Hence component master can be added with a component_match with zero
associated components.

This helps the component master bind call to get triggered,
even if no component is registered for that particular master.

This is meant for big PCI device drivers where small/optional
features are external components, and based on usecases different
combination of components are build as entire driver.

In such PCI device driver Load, if we use the component master for
waiting for few  components(features) availability, only if they are
supported by the underlying HW, then we need to allocate memory for
component_match using the API introduced in this change before
the call to component_master_add_with_match.

v2:
  No Change.

Signed-off-by: Ramalingam C 
Suggested-by: Daniel Vetter 
Cc: Greg Kroah-Hartman 
Cc: Kate Stewart 
Cc: Thomas Gleixner 
Cc: Philippe Ombredanne 
Cc: linux-ker...@vger.kernel.org
---
 drivers/base/component.c  | 30 ++
 include/linux/component.h |  2 ++
 2 files changed, 32 insertions(+)

diff --git a/drivers/base/component.c b/drivers/base/component.c
index e8d676fad0c9..0ab36b2255ea 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -312,6 +312,36 @@ static int component_match_realloc(struct device *dev,
 }
 
 /*
+ * Allocate the match without any component_match_array elements.
+ *
+ * This function is useful when the component master might end up
+ * registering itself without any matching components.
+ */
+void component_match_alloc(struct device *master,
+   struct component_match **matchptr)
+{
+   struct component_match *match = *matchptr;
+
+   if (IS_ERR(match))
+   return;
+
+   if (match)
+   return;
+
+   match = devres_alloc(devm_component_match_release,
+sizeof(*match), GFP_KERNEL);
+   if (!match) {
+   *matchptr = ERR_PTR(-ENOMEM);
+   return;
+   }
+
+   devres_add(master, match);
+
+   *matchptr = match;
+}
+EXPORT_SYMBOL(component_match_alloc);
+
+/*
  * Add a component to be matched, with a release function.
  *
  * The match array is first created or extended if necessary.
diff --git a/include/linux/component.h b/include/linux/component.h
index e71fbbbc74e2..3f6b420a58f8 100644
--- a/include/linux/component.h
+++ b/include/linux/component.h
@@ -37,6 +37,8 @@ void component_match_add_release(struct device *master,
struct component_match **matchptr,
void (*release)(struct device *, void *),
int (*compare)(struct device *, void *), void *compare_data);
+void component_match_alloc(struct device *master,
+   struct component_match **matchptr);
 
 static inline void component_match_add(struct device *master,
struct component_match **matchptr,
-- 
2.7.4

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

[PATCH v9 05/39] drm/i915: component master at i915 driver load

[Ramalingam C]

A generic component master is added to hold the i915 registration
until all required kernel modules are up and active.

This is achieved through following steps:
  - moving the i915 driver registration to the component master's
bind call
  - all required kernel modules will add one component each to
component_match of I915 component master.

If no component is added to the I915 component master, due to CONFIG
selection or HW limitation, component master's bind call (i915
registration) will be triggered with no wait.

Similarly when a associated component is removed for some reasons,
I915 will be unregistered through component master unbind.

v2:
  i915_driver_unregister is added to the unbind of master.
v3:
  In master_unbind i915_unregister->drm_atomic_helper_shutdown->
component_unbind_all [Daniel]

Signed-off-by: Ramalingam C 
Suggested-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_drv.c | 86 +
 drivers/gpu/drm/i915/i915_drv.h |  3 ++
 include/drm/i915_component.h| 11 ++
 3 files changed, 92 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index b310a897a4ad..b8a204072e60 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -39,12 +39,14 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include "i915_drv.h"
 #include "i915_trace.h"
@@ -1577,8 +1579,6 @@ static void i915_driver_register(struct drm_i915_private 
*dev_priv)
if (IS_GEN5(dev_priv))
intel_gpu_ips_init(dev_priv);
 
-   intel_audio_init(dev_priv);
-
/*
 * Some ports require correctly set-up hpd registers for detection to
 * work properly (leading to ghost connected connector status), e.g. VGA
@@ -1609,7 +1609,6 @@ static void i915_driver_unregister(struct 
drm_i915_private *dev_priv)
intel_power_domains_disable(dev_priv);
 
intel_fbdev_unregister(dev_priv);
-   intel_audio_deinit(dev_priv);
 
/*
 * After flushing the fbdev (incl. a late async config which will
@@ -1694,6 +1693,48 @@ static void i915_driver_destroy(struct drm_i915_private 
*i915)
pci_set_drvdata(pdev, NULL);
 }
 
+static void i915_driver_load_tail(struct drm_i915_private *dev_priv)
+{
+   i915_driver_register(dev_priv);
+
+   DRM_INFO("load_tail: I915 driver registered\n");
+}
+
+static void i915_driver_unload_head(struct drm_i915_private *dev_priv)
+{
+   i915_driver_unregister(dev_priv);
+
+   DRM_INFO("unload_head: I915 driver unregistered\n");
+}
+
+static int i915_component_master_bind(struct device *dev)
+{
+   struct drm_i915_private *dev_priv = kdev_to_i915(dev);
+   int ret;
+
+   ret = component_bind_all(dev, dev_priv->comp_master);
+   if (ret < 0)
+   return ret;
+
+   i915_driver_load_tail(dev_priv);
+
+   return 0;
+}
+
+static void i915_component_master_unbind(struct device *dev)
+{
+   struct drm_i915_private *dev_priv = kdev_to_i915(dev);
+
+   i915_driver_unload_head(dev_priv);
+   drm_atomic_helper_shutdown(_priv->drm);
+   component_unbind_all(dev, dev_priv->comp_master);
+}
+
+static const struct component_master_ops i915_component_master_ops = {
+   .bind = i915_component_master_bind,
+   .unbind = i915_component_master_unbind,
+};
+
 /**
  * i915_driver_load - setup chip and create an initial config
  * @pdev: PCI device
@@ -1720,9 +1761,22 @@ int i915_driver_load(struct pci_dev *pdev, const struct 
pci_device_id *ent)
if (!i915_modparams.nuclear_pageflip && match_info->gen < 5)
dev_priv->drm.driver_features &= ~DRIVER_ATOMIC;
 
+   dev_priv->comp_master = kzalloc(sizeof(*dev_priv->comp_master),
+   GFP_KERNEL);
+   if (!dev_priv->comp_master) {
+   ret = -ENOMEM;
+   goto out_fini;
+   }
+
+   component_match_alloc(dev_priv->drm.dev, _priv->master_match);
+   if (!dev_priv->master_match) {
+   ret = -ENOMEM;
+   goto out_comp_master_clean;
+   }
+
ret = pci_enable_device(pdev);
if (ret)
-   goto out_fini;
+   goto out_comp_master_clean;
 
ret = i915_driver_init_early(dev_priv);
if (ret < 0)
@@ -1742,14 +1796,27 @@ int i915_driver_load(struct pci_dev *pdev, const struct 
pci_device_id *ent)
if (ret < 0)
goto out_cleanup_hw;
 
-   i915_driver_register(dev_priv);
+   ret = component_master_add_with_match(dev_priv->drm.dev,
+ _component_master_ops,
+ dev_priv->master_match);
+   if (ret < 0) {
+   DRM_DEV_ERROR(>dev, "Master comp add failed %d\n",
+ ret);
+   goto out_cleanup_modeset;
+   }
+
+   

[PATCH v9 02/39] drm: header for i915 - MEI_HDCP interface

[Ramalingam C]

Header defines the interface for the I915 and MEI_HDCP drivers.

Signed-off-by: Ramalingam C 
---
 include/drm/i915_mei_hdcp_interface.h | 132 ++
 1 file changed, 132 insertions(+)
 create mode 100644 include/drm/i915_mei_hdcp_interface.h

diff --git a/include/drm/i915_mei_hdcp_interface.h 
b/include/drm/i915_mei_hdcp_interface.h
new file mode 100644
index ..e3b7fb32612a
--- /dev/null
+++ b/include/drm/i915_mei_hdcp_interface.h
@@ -0,0 +1,132 @@
+/* SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) */
+/*
+ * Copyright © 2017-2018 Intel Corporation
+ *
+ * Authors:
+ * Ramalingam C 
+ */
+
+#ifndef _I915_MEI_HDCP_INTERFACE_H_
+#define _I915_MEI_HDCP_INTERFACE_H_
+
+#include 
+#include 
+
+/**
+ * enum hdcp_port_type - HDCP port implementation type defined by ME FW
+ * @HDCP_PORT_TYPE_INVALID: Invalid hdcp port type
+ * @HDCP_PORT_TYPE_INTEGRATED: In-Host HDCP2.x port
+ * @HDCP_PORT_TYPE_LSPCON: HDCP2.2 discrete wired Tx port with LSPCON
+ *(HDMI 2.0) solution
+ * @HDCP_PORT_TYPE_CPDP: HDCP2.2 discrete wired Tx port using the CPDP (DP 1.3)
+ *  solution
+ */
+enum hdcp_port_type {
+   HDCP_PORT_TYPE_INVALID,
+   HDCP_PORT_TYPE_INTEGRATED,
+   HDCP_PORT_TYPE_LSPCON,
+   HDCP_PORT_TYPE_CPDP
+};
+
+/**
+ * enum hdcp_wired_protocol - HDCP adaptation used on the port
+ * @HDCP_PROTOCOL_INVALID: Invalid HDCP adaptation protocol
+ * @HDCP_PROTOCOL_HDMI: HDMI adaptation of HDCP used on the port
+ * @HDCP_PROTOCOL_DP: DP adaptation of HDCP used on the port
+ */
+enum hdcp_wired_protocol {
+   HDCP_PROTOCOL_INVALID,
+   HDCP_PROTOCOL_HDMI,
+   HDCP_PROTOCOL_DP
+};
+
+/**
+ * struct hdcp_port_data - intel specific HDCP port data
+ * @port: port index as per I915
+ * @port_type: HDCP port type as per ME FW classification
+ * @protocol: HDCP adaptation as per ME FW
+ * @k: No of streams transmitted on a port. Only on DP MST this is != 1
+ * @seq_num_m: Count of RepeaterAuth_Stream_Manage msg propagated.
+ *Initialized to 0 on AKE_INIT. Incremented after every successful
+ *transmission of RepeaterAuth_Stream_Manage message. When it rolls
+ *over re-Auth has to be triggered.
+ * @streams: struct hdcp2_streamid_type[k]. Defines the type and id for the
+ *  streams
+ */
+struct hdcp_port_data {
+   short int port;
+   u8 port_type;
+   u8 protocol;
+   u16 k;
+   u32 seq_num_m;
+   struct hdcp2_streamid_type *streams;
+};
+
+/**
+ * struct i915_hdcp_component_ops- ops for HDCP2.2 services.
+ * @owner: Module providing the ops
+ * @initiate_hdcp2_session: Initiate a Wired HDCP2.2 Tx Session.
+ * And Prepare AKE_Init.
+ * @verify_receiver_cert_prepare_km: Verify the Receiver Certificate
+ *  AKE_Send_Cert and prepare
+AKE_Stored_Km/AKE_No_Stored_Km
+ * @verify_hprime: Verify AKE_Send_H_prime
+ * @store_pairing_info: Store pairing info received
+ * @initiate_locality_check: Prepare LC_Init
+ * @verify_lprime: Verify lprime
+ * @get_session_key: Prepare SKE_Send_Eks
+ * @repeater_check_flow_prepare_ack: Validate the Downstream topology
+ *  and prepare rep_ack
+ * @verify_mprime: Verify mprime
+ * @enable_hdcp_authentication:  Mark a port as authenticated.
+ * @close_hdcp_session: Close the Wired HDCP Tx session per port.
+ * This also disables the authenticated state of the port.
+ */
+struct i915_hdcp_component_ops {
+   /**
+* @owner: mei_hdcp module
+*/
+   struct module *owner;
+
+   int (*initiate_hdcp2_session)(struct device *dev,
+ struct hdcp_port_data *data,
+ struct hdcp2_ake_init *ake_data);
+   int (*verify_receiver_cert_prepare_km)(struct device *dev,
+  struct hdcp_port_data *data,
+  struct hdcp2_ake_send_cert
+   *rx_cert,
+  bool *km_stored,
+  struct hdcp2_ake_no_stored_km
+   *ek_pub_km,
+  size_t *msg_sz);
+   int (*verify_hprime)(struct device *dev,
+struct hdcp_port_data *data,
+struct hdcp2_ake_send_hprime *rx_hprime);
+   int (*store_pairing_info)(struct device *dev,
+ struct hdcp_port_data *data,
+ struct hdcp2_ake_send_pairing_info
+   *pairing_info);
+   int (*initiate_locality_check)(struct device *dev,
+  struct 

[PATCH v9 00/39] drm/i915: Implement HDCP2.2

[Ramalingam C]

This series enables the HDCP2.2 for I915. The sequence for HDCP2.2
authentication and encryption is implemented as a generic flow
between HDMI and DP. Encoder specific implementations are moved
into hdcp_shim.

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

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

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

Major changes in v9:
  - Mei_hdcp component binding status will impact I915_load [Daniel].
  - worker for sysfs unbind from daniel.
  - i915-mei_hdcp interface defined at i915_mei_hdcp_interface.h
  - Same check_work is used for HDCP1.4 and 2.2 link check. [Daniel]
  - seq_num to and from u32 is done through a helper. [Daniel]
  - hdcp_wired_protocol() is replaced with a const [Daniel]
  - Kdocs are added to mei_hdcp.c [Tomas]
  - i915 port -> mei_ddi_index conversion moved to mei_hdcp [Tomas]
  - SW tracking of the HDCP spec enabled is used [Daniel]

Hopefully covered all suggestions from Tomas and Daniel.

To ease the review process, series is hosted at
https://github.com/ramalingampc2008/drm-tip.git hdcp2_2_v9

Daniel Vetter (1):
  drivers/base: use a worker for sysfs unbind

Ramalingam C (36):
  drm/i915: Gathering the HDCP1.4 routines together
  drm: header for i915 - MEI_HDCP interface
  component: alloc component_match without any comp to match
  drm/i915: component master at i915 driver load
  drm/i915: Initialize HDCP2.2
  drm/i915: MEI interface definition
  drm/i915: hdcp1.4 CP_IRQ handling and SW encryption tracking
  drm/i915: Enable and Disable of HDCP2.2
  drm/i915: Implement HDCP2.2 receiver authentication
  drm: helper functions for hdcp2 seq_num to from u32
  drm/i915: Implement HDCP2.2 repeater authentication
  drm: HDCP2.2 link check related constants
  drm/i915: Implement HDCP2.2 link integrity check
  drm/i915: Handle HDCP2.2 downstream topology change
  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
  misc/mei/hdcp: Client driver for HDCP application
  misc/mei/hdcp: Define ME FW interface for HDCP2.2
  misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session
  misc/mei/hdcp: Verify Receiver Cert and prepare km
  misc/mei/hdcp: Verify H_prime
  misc/mei/hdcp: Store the HDCP Pairing info
  misc/mei/hdcp: Initiate Locality check
  misc/mei/hdcp: Verify L_prime
  misc/mei/hdcp: Prepare Session Key
  misc/mei/hdcp: Repeater topology verification and ack
  misc/mei/hdcp: Verify M_prime
  misc/mei/hdcp: Enabling the HDCP authentication
  misc/mei/hdcp: Closing wired HDCP2.2 Tx Session
  misc/mei/hdcp: Component framework for I915 Interface
  drm/i915: Commit CP without modeset
  drm/i915: Fix KBL HDCP2.2 encrypt status signalling
  FOR_TEST: i915/Kconfig: Select mei_hdcp by I915
  FOR_TESTING_ONLY: debugfs: Excluding the LSPCon for HDCP1.4

Tomas Winkler (2):
  mei: bus: whitelist hdcp client
  mei: bus: export to_mei_cl_device for mei client device drivers

 drivers/base/bus.c|   35 +-
 drivers/base/component.c  |   30 +
 drivers/gpu/drm/i915/i915_debugfs.c   |   10 +-
 drivers/gpu/drm/i915/i915_drv.c   |   86 ++-
 drivers/gpu/drm/i915/i915_drv.h   |3 +
 drivers/gpu/drm/i915/intel_ddi.c  |7 -
 drivers/gpu/drm/i915/intel_display.c  |   10 +
 drivers/gpu/drm/i915/intel_dp.c   |  315 -
 drivers/gpu/drm/i915/intel_drv.h  |   74 ++-
 drivers/gpu/drm/i915/intel_hdcp.c | 1178 +
 drivers/gpu/drm/i915/intel_hdmi.c |  192 +-
 drivers/misc/mei/Kconfig  |8 +
 drivers/misc/mei/Makefile |2 +
 drivers/misc/mei/bus-fixup.c  |   16 +
 drivers/misc/mei/bus.c|1 -
 drivers/misc/mei/hdcp/Makefile|7 +
 drivers/misc/mei/hdcp/mei_hdcp.c  |  807 ++
 drivers/misc/mei/hdcp/mei_hdcp.h  |  394 +++
 include/drm/drm_hdcp.h|   26 +
 include/drm/i915_component.h  |   18 +
 include/drm/i915_mei_hdcp_interface.h |  132 
 include/linux/component.h |2 +
 include/linux/mei_cl_bus.h|2 +
 23 files changed, 3207 insertions(+), 148 deletions(-)
 create mode 100644 drivers/misc/mei/hdcp/Makefile
 create mode 100644 drivers/misc/mei/hdcp/mei_hdcp.c
 create mode 100644 drivers/misc/mei/hdcp/mei_hdcp.h
 create mode 100644 include/drm/i915_mei_hdcp_interface.h

-- 
2.7.4

___
dri-devel mailing list

Re: [PATCH] drm: add capability DRM_CAP_ASYNC_UPDATE

[Tomasz Figa]

On Thu, Dec 6, 2018 at 1:12 AM Helen Koike  wrote:
>
> Hi Ville
>
> On 11/27/18 11:34 AM, Ville Syrjälä wrote:
> > On Fri, Nov 23, 2018 at 07:53:26PM -0200, Helen Koike wrote:
> >> Allow userspace to identify if the driver supports async update.
> >
> > And what exactly is an "async update"?
>
> I agree we are lacking docs on this, I'll send in the next version as
> soon as we agree on a name (please see below).
>
> For reference:
> https://lists.freedesktop.org/archives/dri-devel/2017-April/138586.html
>
> >
> > I keep asking people to come up with the a better name for this, and to
> > document what it actually means. Recently I've been think we should
> > maybe just adopt the vulkan terminology (immediate/fifo/mailbox) to
> > avoid introducing yet another set of names for the same thing. We'd
> > still want to document things properly though.
>
> Another name it was suggested was "atomic amend", this feature basically
> allows userspace to complement an update previously sent (i.e. its in
> the queue and wasn't commited yet), it allows adding a plane update to
> the next commit. So what do you think in renaming it to "atomic amend"?

Note that it doesn't seem to be what the code currently is doing. For
example, for cursor updates, it doesn't seem to be working on the
currently pending commit, but just directly issues an atomic async
update call to the planes. The code actually seems to fall back to a
normal sync commit, if there is an already pending commit touching the
same plane or including a modeset.

Best regards,
Tomasz

> Or do you suggest another name? I am not familiar with vulkan terminology.
>
>
> Thanks
> Helen
>
> >
> >>
> >> Signed-off-by: Enric Balletbo i Serra 
> >> [prepared for upstream]
> >> Signed-off-by: Helen Koike 
> >>
> >> ---
> >> Hi,
> >>
> >> This patch introduces the ASYNC_UPDATE cap, which originated from the
> >> discussion regarding DRM_MODE_ATOMIC_AMEND on [1], to allow user to
> >> figure that async_update exists.
> >>
> >> This was tested using a small program that exercises the uAPI for easy
> >> sanity testing. The program was created by Alexandros and modified by
> >> Enric to test the capability flag [2].
> >>
> >> The test worked on a rockchip Ficus v1.1 board on top of mainline plus
> >> the patch to update cursors asynchronously through atomic plus the patch
> >> that introduces the ATOMIC_AMEND flag for the drm/rockchip driver.
> >>
> >> To test, just build the program and use the --atomic flag to use the cursor
> >> plane with the ATOMIC_AMEND flag. E.g.
> >>
> >>   drm_cursor --atomic
> >>
> >> [1] https://patchwork.freedesktop.org/patch/243088/
> >> [2] 
> >> https://gitlab.collabora.com/eballetbo/drm-cursor/commits/async-capability
> >>
> >> Thanks
> >> Helen
> >>
> >>
> >>  drivers/gpu/drm/drm_ioctl.c | 11 +++
> >>  include/uapi/drm/drm.h  |  1 +
> >>  2 files changed, 12 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> >> index 94bd872d56c4..4a7e0f874171 100644
> >> --- a/drivers/gpu/drm/drm_ioctl.c
> >> +++ b/drivers/gpu/drm/drm_ioctl.c
> >> @@ -31,6 +31,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>  #include "drm_legacy.h"
> >>  #include "drm_internal.h"
> >>  #include "drm_crtc_internal.h"
> >> @@ -229,6 +230,7 @@ static int drm_getcap(struct drm_device *dev, void 
> >> *data, struct drm_file *file_
> >>  {
> >>  struct drm_get_cap *req = data;
> >>  struct drm_crtc *crtc;
> >> +struct drm_plane *plane;
> >>
> >>  req->value = 0;
> >>
> >> @@ -292,6 +294,15 @@ static int drm_getcap(struct drm_device *dev, void 
> >> *data, struct drm_file *file_
> >>  case DRM_CAP_CRTC_IN_VBLANK_EVENT:
> >>  req->value = 1;
> >>  break;
> >> +case DRM_CAP_ASYNC_UPDATE:
> >> +req->value = 1;
> >> +list_for_each_entry(plane, >mode_config.plane_list, 
> >> head) {
> >> +if (!plane->helper_private->atomic_async_update) {
> >> +req->value = 0;
> >> +break;
> >> +}
> >> +}
> >> +break;
> >>  default:
> >>  return -EINVAL;
> >>  }
> >> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> >> index 300f336633f2..ff01540cbb1d 100644
> >> --- a/include/uapi/drm/drm.h
> >> +++ b/include/uapi/drm/drm.h
> >> @@ -649,6 +649,7 @@ struct drm_gem_open {
> >>  #define DRM_CAP_PAGE_FLIP_TARGET0x11
> >>  #define DRM_CAP_CRTC_IN_VBLANK_EVENT0x12
> >>  #define DRM_CAP_SYNCOBJ 0x13
> >> +#define DRM_CAP_ASYNC_UPDATE0x14
> >>
> >>  /** DRM_IOCTL_GET_CAP ioctl argument type */
> >>  struct drm_get_cap {
> >> --
> >> 2.19.1
> >>
> >> ___
> >> dri-devel mailing list
> >> dri-devel@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >

Re: [PATCH v8 05/35] drm/i915: MEI interface definition

[C, Ramalingam]

On 12/12/2018 4:34 PM, C, Ramalingam wrote:



On 12/12/2018 4:08 PM, Daniel Vetter wrote:

On Wed, Dec 12, 2018 at 02:28:29PM +0530, C, Ramalingam wrote:

On 12/7/2018 7:59 PM, Daniel Vetter wrote:

On Fri, Dec 07, 2018 at 11:22:44AM +0530, C, Ramalingam wrote:

On 12/6/2018 3:53 PM, Daniel Vetter wrote:

On Tue, Nov 27, 2018 at 04:13:03PM +0530, Ramalingam C wrote:

+static void i915_hdcp_component_master_unbind(struct device *dev)
+{
+   struct drm_i915_private *dev_priv = kdev_to_i915(dev);
+
+   intel_connectors_hdcp_disable(dev_priv);

Why this code? Once we've unregistered the driver, we should have shut
down the hardware completely. Which should have shut down all the hdcp
users too.

This unbind might be triggered either due to master_del or component_del.
if its triggered from mei through component_del, then before teardown of
the i/f in component_unbind(), disable the ongoing HDCP session through
hdcp_disable() for each connectors.

I looked at your v7 component code again. I think if we put the
drm_atomic_helper_shutdown() call into master_unbind, then we'll have taken care
of that. Essentially what you're doing here is open-coding part of that
function. Better to just move the existing call to the right place.

And shutting down the entire hw is kinda what master_unbind should be
doing I think. We might also need to move the general hw quiescent into
master_unbind, that should work too.

Need some more information on this. As per v7 on master_unbind will invoke
i915_unload_head that is i915_driver_unregister(dev_priv);
Similarly master_bind will call the load_tail that is 
i915_driver_register(dev_priv);

We are not initializing/shutting the HW in master_bind/unbind .
But this comment is contradicting with current approach. Could you please 
elaborate.?

So my understanding is that we need to shut down all hdcp usage before
master_unbind completes, because otherwise we'll blow up: The mei_hdcp
component is gone already.

Now the other case for master_unbind is that the i915 pci device is
unloaded, and in that case again I think it makes sense to shut down the
hardware in master_unbind.

Now when I looked at v7, right after the component_unbind code in the i915
unload sequences comes the function calls to shut down the hardware. I
think it would make sense to them (or at least the
drm_atomic_helper_shutdown() call) into master_unbind.

This is somewhat asymetric, but that's ok: Load path doesn't enable
anything, we just keep the hardware as-is (to be able to support
flicker-free boôt-up). First modest is done by usersapce. Exception is if
you have fbcon enabled (and not use the fastboot patches that Hans just
merged), in that case the kernel will do the first modeset when we
regiseter the fbdev device.

Anyway, moving the drm_atomic_helper_shutdown() into the master_unbind
function in v7 should take care of disabling all outputs, and hence also
disabling all usage of hdcp component.

But in that case master_bind should do the reverse of the 
drm_atomic_helper_shutdown()right?
else lets say mei_hdcp is removed, master_unbind triggered and hence all hw is 
shutdown.
And then mei_hdcp is loaded so master_bind should initialize the hw right? 
Which is not the scenario right now.


Summarizing the #intel-gfx IRC discussion:

As i915 load and unload  are already asymetric, there is no harm in moving
the drm_atomic_helper_shutdown() into the master_unbind(). So going
ahead with daniel's suggestion.

-Ram



-Ram

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

Re: [PATCH] drm/sun4i: fix HSYNC and VSYNC polarity

[Jonathan Liu]

Hi Giulio,

On Wed, 12 Dec 2018 at 04:20, Giulio Benetti
 wrote:
>
> Hi Jonathan,
>
> Il 11/12/2018 11:49, Jonathan Liu ha scritto:
> > Hi Giulio,
> >
> > On Thu, 6 Dec 2018 at 22:00, Giulio Benetti
> >  wrote:
> >>
> >> Hi Jonathan,
> >>
> >> Il 06/12/2018 08:29, Jonathan Liu ha scritto:
> >>> Hi Giulio,
> >>>
> >>> On Thu, 15 Feb 2018 at 17:54, Giulio Benetti
> >>>  wrote:
> 
>  Differently from other Lcd signals, HSYNC and VSYNC signals
>  result inverted if their bits are cleared to 0.
> 
>  Invert their settings of IO_POL register.
> 
>  Signed-off-by: Giulio Benetti 
>  ---
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 
>  diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
>  b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>  index 3c15cf2..aaf911a 100644
>  --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>  +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>  @@ -389,10 +389,10 @@ static void sun4i_tcon0_mode_set_rgb(struct 
>  sun4i_tcon *tcon,
> SUN4I_TCON0_BASIC3_H_SYNC(hsync));
> 
>    /* Setup the polarity of the various signals */
>  -   if (!(mode->flags & DRM_MODE_FLAG_PHSYNC))
>  +   if (mode->flags & DRM_MODE_FLAG_PHSYNC)
>    val |= SUN4I_TCON0_IO_POL_HSYNC_POSITIVE;
> 
>  -   if (!(mode->flags & DRM_MODE_FLAG_PVSYNC))
>  +   if (mode->flags & DRM_MODE_FLAG_PVSYNC)
>    val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;
> 
>    regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,
> >>>
> >>> I am running Linux 4.19.6 and noticed with Olimex LCD-OLinuXino-7TS 7"
> >>> LCD touchscreen (Innolux AT070TN92) connected to Olimex
> >>> A20-OLinuXino-MICRO that the image does not display correctly after
> >>> this change.
> >>> The image is shifted to the right.
> >>>
> >>> Reverting the change results in the image being displayed correctly on
> >>> the screen.
> >>>
> >>> I have in the device tree a "panel" node with compatible =
> >>> "innolux,at070tn92" which uses the timings in
> >>> drivers/gpu/drm/panel/panel-simple.c.
> >>>
> >>> Any ideas?
> >
> >>
> >> Checking Display Datasheet:
> >> https://www.olimex.com/Products/Retired/A13-LCD7-TS/resources/S700-AT070TN92.pdf
> >>
> >> Page 13 section 3.3.2 you can see it needs active low VS and HS.
> >>
> >> You can refer to this Thread and check scope captures about VS and HS
> >> versus TCON0_IOPOL register:
> >> https://lists.freedesktop.org/archives/dri-devel/2018-January/163874.html
> >>
> >> There should be something that wrongly sets one of these or both:
> >> mode->flags |= DRM_MODE_FLAG_PHSYNC;
> >> and/or
> >> mode->flags |= DRM_MODE_FLAG_PVSYNC;
> >>
> >> Checked in panel-simple.c but it's not there.

> >
> > flags is 0 because it is not assigned in the struct definition for the 
> > panel.
>
> I don't think it is 0, because otherwise IO_POL_REG wouldn't be set to
> 0x0300 but to 0.
> What is checked is exactly mode->flags, so the problem seems to be upstream.
>
> This is my doubt, it seems mode->flags is not initialized or overriden
> at a certain point, this is why I want to debug it with Jtag tomorrow.
>

If you look at the change made by your patch:
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -389,10 +389,10 @@ static void sun4i_tcon0_mode_set_rgb(struct
sun4i_tcon *tcon,
 SUN4I_TCON0_BASIC3_H_SYNC(hsync));

/* Setup the polarity of the various signals */
-   if (!(mode->flags & DRM_MODE_FLAG_PHSYNC))
+   if (mode->flags & DRM_MODE_FLAG_PHSYNC)
val |= SUN4I_TCON0_IO_POL_HSYNC_POSITIVE;

-   if (!(mode->flags & DRM_MODE_FLAG_PVSYNC))
+   if (mode->flags & DRM_MODE_FLAG_PVSYNC)
val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;

regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,

If mode->flags is 0, then before your change it would set
SUN4I_TCON0_IO_POL_HSYNC_POSITIVE and
SUN4I_TCON0_IO_POL_VSYNC_POSITIVE bits to 1 (resulting in 0x0300).
If mode->flags is not 0, then after your change it would not set
SUN4I_TCON0_IO_POL_HSYNC_POSITIVE and
SUN4I_TCON0_IO_POL_VSYNC_POSITIVE bits to 1 (resulting in 0x).

> > Before this change, TCON0_IO_POL_REG would be 0x0300 (both bits
> > set to 1) and image displays correctly > After this change, 
> > TCON0_IO_POL_REG is 0x (both bits set to 0)
> > and image doesn't display correctly.
> >
> > Checked using "devmem2 0x01c0c088" on A20-OLinuXino-MICRO Rev J.
>
> 0x0300 as I've triple checked with scope means Positive H/Vsync,
> and 0x Negative H/VSync.
>
> Please check on the Thread I've pointed you above where there are all
> the links to the scope captures.
>
> Are you completely sure you're using the correct panel?

Yes, I am sure I am using the correct panel. It has the following
marking on sticker:
AT070TN92V.X 

Re: [PATCH] drm/sun4i: fix HSYNC and VSYNC polarity

[Jonathan Liu]

Hi Giulio,

On Wed, 12 Dec 2018 at 04:39, Giulio Benetti
 wrote:
>
> Forgot to ask you,
>
> Il 11/12/2018 18:20, Giulio Benetti ha scritto:
> > Hi Jonathan,
> >
> > Il 11/12/2018 11:49, Jonathan Liu ha scritto:
> >> Hi Giulio,
> >>
> >> On Thu, 6 Dec 2018 at 22:00, Giulio Benetti
> >>  wrote:
> >>>
> >>> Hi Jonathan,
> >>>
> >>> Il 06/12/2018 08:29, Jonathan Liu ha scritto:
>  Hi Giulio,
> 
>  On Thu, 15 Feb 2018 at 17:54, Giulio Benetti
>   wrote:
> >
> > Differently from other Lcd signals, HSYNC and VSYNC signals
> > result inverted if their bits are cleared to 0.
> >
> > Invert their settings of IO_POL register.
> >
> > Signed-off-by: Giulio Benetti 
> > ---
> >drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 ++--
> >1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > index 3c15cf2..aaf911a 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > @@ -389,10 +389,10 @@ static void sun4i_tcon0_mode_set_rgb(struct
> > sun4i_tcon *tcon,
> >SUN4I_TCON0_BASIC3_H_SYNC(hsync));
> >
> >   /* Setup the polarity of the various signals */
> > -   if (!(mode->flags & DRM_MODE_FLAG_PHSYNC))
> > +   if (mode->flags & DRM_MODE_FLAG_PHSYNC)
> >   val |= SUN4I_TCON0_IO_POL_HSYNC_POSITIVE;
> >
> > -   if (!(mode->flags & DRM_MODE_FLAG_PVSYNC))
> > +   if (mode->flags & DRM_MODE_FLAG_PVSYNC)
> >   val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;
> >
> >   regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,
> 
>  I am running Linux 4.19.6 and noticed with Olimex LCD-OLinuXino-7TS 7"
>  LCD touchscreen (Innolux AT070TN92) connected to Olimex
>  A20-OLinuXino-MICRO that the image does not display correctly after
>  this change.
>  The image is shifted to the right.
> 
>  Reverting the change results in the image being displayed correctly on
>  the screen.
> 
>  I have in the device tree a "panel" node with compatible =
>  "innolux,at070tn92" which uses the timings in
>  drivers/gpu/drm/panel/panel-simple.c.
> 
>  Any ideas?
> >>
> >>>
> >>> Checking Display Datasheet:
> >>> https://www.olimex.com/Products/Retired/A13-LCD7-TS/resources/S700-AT070TN92.pdf
> >>>
> >>>
> >>> Page 13 section 3.3.2 you can see it needs active low VS and HS.
> >>>
> >>> You can refer to this Thread and check scope captures about VS and HS
> >>> versus TCON0_IOPOL register:
> >>> https://lists.freedesktop.org/archives/dri-devel/2018-January/163874.html
> >>>
> >>>
> >>> There should be something that wrongly sets one of these or both:
> >>> mode->flags |= DRM_MODE_FLAG_PHSYNC;
> >>> and/or
> >>> mode->flags |= DRM_MODE_FLAG_PVSYNC;
> >>>
> >>> Checked in panel-simple.c but it's not there.
> >>
> >> flags is 0 because it is not assigned in the struct definition for the
> >> panel.
> >
> > I don't think it is 0, because otherwise IO_POL_REG wouldn't be set to
> > 0x0300 but to 0.
> > What is checked is exactly mode->flags, so the problem seems to be
> > upstream.
> >
> > This is my doubt, it seems mode->flags is not initialized or overriden
> > at a certain point, this is why I want to debug it with Jtag tomorrow.
> >
> >> Before this change, TCON0_IO_POL_REG would be 0x0300 (both bits
> >> set to 1) and image displays correctly > After this change,
> >> TCON0_IO_POL_REG is 0x (both bits set to 0)
> >> and image doesn't display correctly.
> >>
> >> Checked using "devmem2 0x01c0c088" on A20-OLinuXino-MICRO Rev J.
> >
> > 0x0300 as I've triple checked with scope means Positive H/Vsync,
> > and 0x Negative H/VSync.
> >
> > Please check on the Thread I've pointed you above where there are all
> > the links to the scope captures.
> >
> > Are you completely sure you're using the correct panel?
> > This is because if with 0x0300 it works correctly, it means that
> > you're using Positive VS and HS but on datasheet on Figure 3.2 it shows
> > that they must be negative.
> >
> > Do you have any chance to measure those signals with a scope?
> >
> > Tomorrow, while debugging, I'll re-check H/Vsync signals again.
> >
> > Kind regards

>
> Can you precisely point me the sources of:
> - u-boot
> - kernel
> - dts
>
> you're using?
>
> Thanks

U-Boot - git tag v2017.03
Linux - git tag v4.19.6
DTS - see device tree changes in
https://github.com/net147/linux/tree/sun7i-drm-wip but change the
compatible to "innolux,at070tn92"

Thanks.

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

Re: [GIT PULL] mediatek drm fixes for 4.20

[CK Hu]

Hi, Dave:

On Thu, 2018-12-13 at 10:17 +1000, Dave Airlie wrote:
> On Thu, 13 Dec 2018 at 07:32, Dave Airlie  wrote:
> >
> > On Mon, 10 Dec 2018 at 12:13, CK Hu  wrote:
> > >
> > > Hi, Dave:
> > >
> > > Here is one fix.
> > >
> > > Regards,
> > > CK
> > >
> > > The following changes since commit
> > > 651022382c7f8da46cb4872a545ee1da6d097d2a:
> > >
> > >   Linux 4.20-rc1 (2018-11-04 15:37:52 -0800)
> > >
> > > are available in the Git repository at:
> > >
> > >   https://github.com/ckhu-mediatek/linux.git-tags.git a0071bc455da
> >
> > Something went wrong with your git pull, you didn't get a tag or
> > branch for me to pull from.
> >
> 
> Btw for this occasion I've pulled from the branch on github which has
> this patch,
> but in future please make sure the pull req you send out is valid.

Sorry for the inconvenience, I would make sure the pull request is valid
in future.

Regards,
CK 

> 
> Dave.
> 
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek


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

[Bug 108862] OpenGL CTS KHR-GL31.CommonBugs.CommonBug_ParenthesisInLayoutQualifierIntegerValue failed

[bugzilla-daemon]

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

Chen Xi  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Chen Xi  ---
This issue is not reproduced with newly released MESA 18.3.0

https://mesa.freedesktop.org/archive/mesa-18.3.0.tar.gz

So close the issue.

-- 
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 108876] OpenGL CTS glCreateShader() call failed.: glGetError() returned GL_INVALID_ENUM at gl3cCommonBugsTests.cpp:5590

[bugzilla-daemon]

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

Chen Xi  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #4 from Chen Xi  ---
This issue is not reproduced with newly released MESA 18.3.0
https://mesa.freedesktop.org/archive/mesa-18.3.0.tar.gz

So close this issue.

-- 
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: [Intel-gfx] [PATCH v2] drm/i915: correct the pitch check for NV12 framebuffer

[Hwang, Dongseong]

On Wed, Dec 12, 2018 at 1:15 PM Ville Syrjälä
 wrote:
>
> On Wed, Dec 12, 2018 at 09:33:49PM +0100, Daniel Vetter wrote:
> > On Wed, Dec 12, 2018 at 9:24 PM Ville Syrjälä
> >  wrote:
> > >
> > > On Tue, Dec 11, 2018 at 04:39:05PM -0800, Dongseong Hwang wrote:
> > > > framebuffer for NV12 requires the pitch to the multiplier of 4, instead
> > > > of the width. This patch corrects it.
> > > >
> > > > For instance, a 480p video, whose width and pitch are 854 and 896
> > > > respectively, is excluded for NV12 plane so far.
> > > >
> > > > Signed-off-by: Dongseong Hwang 
> > > > Cc: Chandra Konduru 
> > > > Cc: Vidya Srinivas 
> > > > Cc: Ville Syrjälä 
> > > > Cc: Juha-Pekka Heikkila 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_display.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > > b/drivers/gpu/drm/i915/intel_display.c
> > > > index 13e5650..8a3de12 100644
> > > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > @@ -14600,7 +14600,7 @@ static int intel_framebuffer_init(struct 
> > > > intel_framebuffer *intel_fb,
> > > >   if (fb->format->format == DRM_FORMAT_NV12 &&
> > > >   (fb->width < SKL_MIN_YUV_420_SRC_W ||
> > > >fb->height < SKL_MIN_YUV_420_SRC_H ||
> > > > -  (fb->width % 4) != 0 || (fb->height % 4) != 0)) {
> > > > +  (fb->pitches[0] % 4) != 0 || (fb->height % 4) != 0)) {
> > >
> > > The stride can never be misaligned like that. It'll be at least tile
> > > aligned, or 64 byte aligned with linear buffers.
> > >
> > > Anyways this entire piece of code doesn't make too much sense. The fb
> > > size doesn't really matter for us, only the src viewport size matters.
> > > That one we limit to a minimum of 2x2 pixels w/o scaling, and 16x16
> > > pixems w/ scaling. So looks like this code can be just ripped out.
> >
> > Do we have igt testcases for these cornercases in igt? Obviously would
> > need to be intel specific subtests ...
>
> Can't spot anything quite that specific. Someone would need to write
> one I suppose. Also Imre has a test somewhere on the list for testing
> the plane clipping underrun fails which tests small src viewport sizes,
> and JP has been working on a rotation vs. clipping test that is also
> somewhat related. Not sure if we could combine any of these somehow
> to avoid having too many similar tests.

Ap pointed out there is i915 workaround

1106 Display NV12, Rotation, Horizontal flip
Display corruption/color shift observed when using NV12 with 270
rotation or 90 rotation + horizontal flip.
WA: NV12 with 270 rotation or 90 rotation + horizontal flip requires
the programmed plane height to be a multiple of 4.
GEN9:ALL
GLK:ALL
GLV:ALL
CNL:*:A
CNL:*:B

I think this condition was introduced to deal with the workaround, and
I think the stride restriction is enough for the above workaround.
Ville, if I add the igt covering this change, is it good to land?

Best regards,
Dongseong


>
> --
> Ville Syrjälä
> Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/3] drm/exynos: add support for dynamic zpos in DECON and FIMD

[Inki Dae]

18. 12. 12. 오후 5:43에 Andrzej Hajda 이(가) 쓴 글:
> On 12.12.2018 00:26, Inki Dae wrote:
>>
>> 18. 12. 11. 오후 5:36에 Andrzej Hajda 이(가) 쓴 글:
>>> On 11.12.2018 09:01, Inki Dae wrote:
 18. 12. 11. 오후 4:49에 Andrzej Hajda 이(가) 쓴 글:
> On 11.12.2018 00:45, Inki Dae wrote:
>> Hi Andrzej,
>>
>> 18. 12. 10. 오후 4:35에 Andrzej Hajda 이(가) 쓴 글:
>>> Hi Inki,
>>>
>>> On 10.12.2018 03:25, Inki Dae wrote:
 Hi Andrzej,

 18. 12. 6. 오후 6:38에 Andrzej Hajda 이(가) 쓴 글:
> Hi Inki,
>
> This small patchset adds dynamic zpos support for DECON and FIMD.
 This patch will allow user space to change zpos. However, DECON and 
 FIMD devices have fixed priority of HW overlays.
 This would mean that zpos change by user space doesn't guarantee 
 correct HW overlay priority.

 Why do you want to support mutable zpos?
>>> Practically you have patches which proves it works, you can see that
>>> changing zpos value results in adequate change in displayed image.
>>>
>>> Conceptually it is just a matter of disconnecting hardware windows
>>> present in DECON and FIMD from DRM planes which are software entities.
>>>
>>> You can reason about it this way:
>>>
>>> - drm plane is a framebuffer plus informations how it should be
>>> transformed/displayed on DECON/FIMD,
>>>
>>> - hw window in DECON/FIMD is just a channel through which plane is send
>>> to the display.
>>>
>>> DECON and FIMD has fixed hw windows order - windows with lower numbers
>>> are displayed below windows with higher number. To display planes in
>>> given z-order you just need to send them via windows with appropriate
>>> index - farthest plane should go always via win0, closer one via win1,
>>> ..., till the last plane.
>>>
>>> So for example if you have three planes and want to display them in
>>> following order (first one farthest, last one closest):
>>>
>>> plane2, plane1, plane3
>>>
>>> you should map them to planes as follow:
>>>
>>> plane2 -> win0, plane1 -> win1, plane3 -> win2
>>>
>>> then for example plane2 is disabled, we will have following mapping:
>>>
>>> plane1 -> win0, plane3 -> win1, win2 - disabled
>> Plane1 is displayed below Plane3.
> And this is what we wanted, the initial order was: plane2, plane1,
> plane3, first farthest (or lowest if you prefer this naming schema).
>
>
>>> then if you change zorder of planes to: plane3, plane1:
>>>
>>> plane3 -> win0, plane1 -> win1
>> Plane3 is displayed below Plane1 because DECON/FIMD HW aren't able to 
>> change HW overlay priroty.
> No, plane3 is displayed below plane1 because we sent it via win0, if we
> want inverse we can send plane3 via win1 and plane1 via win0.
>
>
>> However, user space wanted that Plane1 is displayed below Plane3. Like 
>> this, zpos change by user space doesn't guarantee correct HW overlay 
>> priority.
> As I said before in this example userspace wanted plane3 below plane1,
> and as I wrote in comment above any order of planes user want driver is
> able to realize with this patch.
>
>
>> And there is no any reason to change zpos in user space excepting Mixer 
>> device which supports HW overlay priority change.
> Lack of special registry for manipulating windows order does not mean it
> cannot support dynamic zpos.
>
 Why changing zpos in user space is required?

>> In fact, we supported mutable zpos before but changed it to immutable 
>> with same reason.
> It was just broken if I remember correctly.
>
 No, I worked well and real user used it I remember.

>> Lastly, your patch made real user broken.
> Who? How?
 Window server of Tizen didn't work and you can test it with below image - 
 I didn't check why it doesn't. Anyway, we don't have to break real user.
 http://download.tizen.org/snapshots/tizen/unified/latest/images/standard/mobile-wayland-armv7l-tm2/
>>>
>>> Are you saying it works with latest mainline without my patches?
>> Right. actually, I checked your patch with Tizen image released in Sept and 
>> it worked well without your patch but with your patch it didn't work.
> 
> 
> No surprise, it did not work with mixer for the same reason (broken
> dynamic zpos handling), userspace code was written for and tested on
> specific version of hardware.
> 
> Beside userspace there could be some differences on kernel side
> regarding zpos, I will look and test tizen kernel and let you know.
> 
> 
>> With latest Tizen image Display is keeping black screen without your patch 
>> but window server worked well. Seems latest Tizen image has some problem.
> 
> 
> Here is sample script for modetest on tm2 with mainline kernel, which
> shows how dynamic zpos works:
> 
> 
> 
> #!/bin/bash -x
> 

[Bug 105251] [Vega10] GPU lockup on boot: VMC page fault

[bugzilla-daemon]

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

--- Comment #61 from Benjamin Hodgetts  ---
Created attachment 142797
  --> https://bugs.freedesktop.org/attachment.cgi?id=142797=edit
New Error Since 4.19.X

Ok, so some time between my last report and now (started happening since
4.19.something, I don't know which version specifically) this problem has
changed in how it manifests itself. Previously you'd get the "[gfxhub] VMC page
fault" messages. Now it manifests itself in considerably more serious looking
errors (with none of the "VMC page faults" in sight). Log file attached.

Once something triggers this, the card will become basically unresponsive and
anything that tries to use it will start throwing more of the errors seen in
the attached log.

It's not random though. For example I can run Unigine valley/superposition or
Elder Scrolls Online (via Wine+DXVK) for as long as I like, stress-testing or
benchmarking and it'll be fine. But as soon a I try one of the problem
programs, it'll basically "break" the graphics card until I hard reset.

-- 
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: [Intel-gfx] [PATCH 2/4] drm/i915: Use drm_hdmi_avi_infoframe_quant_range() for SDVO HDMI as well

[Dhinakaran Pandiyan]

On Tue, 2018-11-20 at 18:13 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Fill out the AVI infoframe quantization range bits using
> drm_hdmi_avi_infoframe_quant_range() for SDVO HDMI encoder as well.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_sdvo.c | 19 ++-
>  1 file changed, 10 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
> b/drivers/gpu/drm/i915/intel_sdvo.c
> index 1277d31adb54..9c16e273fb8d 100644
> --- a/drivers/gpu/drm/i915/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> @@ -984,6 +984,8 @@ static bool intel_sdvo_set_avi_infoframe(struct
> intel_sdvo *intel_sdvo,
>const struct intel_crtc_state
> *pipe_config,
>const struct
> drm_connector_state *conn_state)
>  {
> + const struct drm_display_mode *adjusted_mode =
> + _config->base.adjusted_mode;
>   uint8_t sdvo_data[HDMI_INFOFRAME_SIZE(AVI)];
>   union hdmi_infoframe frame;
>   int ret;
> @@ -991,20 +993,19 @@ static bool intel_sdvo_set_avi_infoframe(struct
> intel_sdvo *intel_sdvo,
>  
>   ret = drm_hdmi_avi_infoframe_from_display_mode(,
>  conn_state-
> >connector,
> -_config-
> >base.adjusted_mode);
> +adjusted_mode);
>   if (ret < 0) {
>   DRM_ERROR("couldn't fill AVI infoframe\n");
>   return false;
>   }
>  
> - if (intel_sdvo->rgb_quant_range_selectable) {
> - if (pipe_config->limited_color_range)
> - frame.avi.quantization_range =
> - HDMI_QUANTIZATION_RANGE_LIMITED;
> - else
> - frame.avi.quantization_range =
> - HDMI_QUANTIZATION_RANGE_FULL;
> - }
> + drm_hdmi_avi_infoframe_quant_range(,
> +conn_state->connector,
> +adjusted_mode,
> +pipe_config-
> >limited_color_range ?
> +rgb_quant_range_selectableTE
> D :
> +HDMI_QUANTIZATION_RANGE_FULL
> ,
> +intel_sdvo-
> >rgb_quant_range_selectable);

Seems like avi.quantization_range can now get set to _LIMITED or _FULL
even when ->rgb_quant_range_selectable == false, i.e., it is not
_DEFAULT anymore. Is that change in behavior intended?


>  
>   len = hdmi_infoframe_pack(, sdvo_data,
> sizeof(sdvo_data));
>   if (len < 0)

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

Re: [GIT PULL] mediatek drm fixes for 4.20

[Dave Airlie]

On Thu, 13 Dec 2018 at 07:32, Dave Airlie  wrote:
>
> On Mon, 10 Dec 2018 at 12:13, CK Hu  wrote:
> >
> > Hi, Dave:
> >
> > Here is one fix.
> >
> > Regards,
> > CK
> >
> > The following changes since commit
> > 651022382c7f8da46cb4872a545ee1da6d097d2a:
> >
> >   Linux 4.20-rc1 (2018-11-04 15:37:52 -0800)
> >
> > are available in the Git repository at:
> >
> >   https://github.com/ckhu-mediatek/linux.git-tags.git a0071bc455da
>
> Something went wrong with your git pull, you didn't get a tag or
> branch for me to pull from.
>

Btw for this occasion I've pulled from the branch on github which has
this patch,
but in future please make sure the pull req you send out is valid.

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

Re: [pull] amdgpu drm-next-4.21

[Dave Airlie]

On Thu, 13 Dec 2018 at 07:13, Alex Deucher  wrote:
>
> Hi Dave,
>
> Updates for 4.21:
> - Powerplay updates for newer polaris variants
> - Add cursor plane update fast path
> - Enable gpu reset by default on CI parts
> - Fix config with KFD/HSA not enabled
> - Misc bug fixes
>

Either this or the previous one broke the etnaviv build, I see two
reports on the list of this breakage from the kbuild robot but no
mention of it, can you guys either stick some arm cross compiles in
your build paths or keep an eye on the kbuild robot emails for your
branches.

I created my own fix and pushed it in the merge commit.

Dave.

> The following changes since commit 22666cc1481ae3814d9c7718418cc4a3aa7d90c3:
>
>   drm/amdgpu: move IV prescreening into the GMC code (2018-12-07 18:14:26 
> -0500)
>
> are available in the git repository at:
>
>   git://people.freedesktop.org/~agd5f/linux drm-next-4.21
>
> for you to fetch changes up to 674e78acae0dfb4beb56132e41cbae5b60f7d662:
>
>   drm/amd/display: Add fast path for cursor plane updates (2018-12-12 
> 15:32:10 -0500)
>
> 
> Alex Deucher (1):
>   drm/amdgpu/powerplay: Add special avfs cases for some polaris asics (v3)
>
> Andrey Grodzovsky (1):
>   drm/amdgpu: Enable GPU recovery by default for CI
>
> Kuehling, Felix (1):
>   drm/amdgpu: Fix stub function name
>
> Nicholas Kazlauskas (4):
>   Revert "drm/amd/display: Set RMX_ASPECT as default"
>   drm/amd/display: Fix unintialized max_bpc state values
>   drm/amd/display: Fix duplicating scaling/underscan connector state
>   drm/amd/display: Add fast path for cursor plane updates
>
> Rex Zhu (1):
>   drm/amdgpu: Limit vm max ctx number to 4096
>
> Tiecheng Zhou (1):
>   drm/amdgpu: bypass RLC init under sriov for Tonga (v2)
>
> YueHaibing (1):
>   drm/amdgpu: remove set but not used variable 'grbm_soft_reset'
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h|  1 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c |  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  2 +
>  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  | 11 +--
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  | 79 
> --
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h  |  8 +++
>  .../drm/amd/powerplay/smumgr/polaris10_smumgr.c| 54 +++
>  8 files changed, 147 insertions(+), 12 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/3] drm/exynos: add support for dynamic zpos in DECON and FIMD

[Inki Dae]

18. 12. 12. 오후 5:30에 Andrzej Hajda 이(가) 쓴 글:
> On 12.12.2018 00:48, Inki Dae wrote:
>>
>> 18. 12. 11. 오후 10:20에 Andrzej Hajda 이(가) 쓴 글:
>>> Hi again,
>>>
>>> It seems I have missed two questions:
>>>
>>> On 11.12.2018 09:36, Andrzej Hajda wrote:
 On 11.12.2018 09:01, Inki Dae wrote:
> 18. 12. 11. 오후 4:49에 Andrzej Hajda 이(가) 쓴 글:
>> On 11.12.2018 00:45, Inki Dae wrote:
>>> Hi Andrzej,
>>>
>>> 18. 12. 10. 오후 4:35에 Andrzej Hajda 이(가) 쓴 글:
 Hi Inki,

 On 10.12.2018 03:25, Inki Dae wrote:
> Hi Andrzej,
>
> 18. 12. 6. 오후 6:38에 Andrzej Hajda 이(가) 쓴 글:
>> Hi Inki,
>>
>> This small patchset adds dynamic zpos support for DECON and FIMD.
> This patch will allow user space to change zpos. However, DECON and 
> FIMD devices have fixed priority of HW overlays.
> This would mean that zpos change by user space doesn't guarantee 
> correct HW overlay priority.
>
> Why do you want to support mutable zpos?
 Practically you have patches which proves it works, you can see that
 changing zpos value results in adequate change in displayed image.

 Conceptually it is just a matter of disconnecting hardware windows
 present in DECON and FIMD from DRM planes which are software entities.

 You can reason about it this way:

 - drm plane is a framebuffer plus informations how it should be
 transformed/displayed on DECON/FIMD,

 - hw window in DECON/FIMD is just a channel through which plane is send
 to the display.

 DECON and FIMD has fixed hw windows order - windows with lower numbers
 are displayed below windows with higher number. To display planes in
 given z-order you just need to send them via windows with appropriate
 index - farthest plane should go always via win0, closer one via win1,
 ..., till the last plane.

 So for example if you have three planes and want to display them in
 following order (first one farthest, last one closest):

 plane2, plane1, plane3

 you should map them to planes as follow:

 plane2 -> win0, plane1 -> win1, plane3 -> win2

 then for example plane2 is disabled, we will have following mapping:

 plane1 -> win0, plane3 -> win1, win2 - disabled
>>> Plane1 is displayed below Plane3.
>> And this is what we wanted, the initial order was: plane2, plane1,
>> plane3, first farthest (or lowest if you prefer this naming schema).
>>
>>
 then if you change zorder of planes to: plane3, plane1:

 plane3 -> win0, plane1 -> win1
>>> Plane3 is displayed below Plane1 because DECON/FIMD HW aren't able to 
>>> change HW overlay priroty.
>> No, plane3 is displayed below plane1 because we sent it via win0, if we
>> want inverse we can send plane3 via win1 and plane1 via win0.
>>
>>
>>> However, user space wanted that Plane1 is displayed below Plane3. Like 
>>> this, zpos change by user space doesn't guarantee correct HW overlay 
>>> priority.
>> As I said before in this example userspace wanted plane3 below plane1,
>> and as I wrote in comment above any order of planes user want driver is
>> able to realize with this patch.
>>
>>
>>> And there is no any reason to change zpos in user space excepting Mixer 
>>> device which supports HW overlay priority change.
>> Lack of special registry for manipulating windows order does not mean it
>> cannot support dynamic zpos.
>>
> Why changing zpos in user space is required?
>>>
>>> I didn't say it is required, but usually it is better if the driver
>>> supports more features than less.
>> Supporting more feature is ok but without HW support I don't see what 
>> benefit there is excepting making user space confusing.
> 
> 
> But I want to emphasize again, this patch adds real support for dynamic
> zpos on planes, it is not fake, why it should be confusing for userspace?
It's because user space already know that each HW overlay of DECON and FIMD 
device has a fixed priority, actually they have definitely fixed HW overlays.

> 
> It will make exynos_drm planes consistent (all real planes will support
> dynamic zpos) and flexible - userspace will be able to change plane
> order with simple property adjustment.
> 
> Other argument for it is that most drivers having zpos use dynamic zpos
> (msm, omap, rcar, tegra, sun4i, sti), immutable_zpos is used only by sti
> and only for cursor.

Right, they support mutable zpos. In addition, seems they also support priority 
change of HW overlay - I just checked omap and sun4i drivers,
omap case:
dispc_ovl_setup_common(...u8 zorder, ...)
...
dispc_ovl_set_zorder(..., zorder);

sun4i case:

Re: [PATCH] [RFC] MAINTAINERS: Daniel for drm co-maintainer

[Dave Airlie]

On Thu, 13 Dec 2018 at 01:45, Sean Paul  wrote:
>
> On Mon, Dec 10, 2018 at 11:30:01AM +0100, Daniel Vetter wrote:
> > lkml and Linus gained a CoC, and it's serious this time. Which means
> > my no 1 reason for declining to officially step up as drm maintainer
> > is gone, and I didn't find any new good excuse.
> >
> > I chatted with a few people in private already, and the biggest
> > concern is that I mislay my community hat and start running around
> > with my intel hat only. Or some other convenient abuse of trust.
> >
> > That's why this patch doesn't just need a lot of acks that mean "yeah
> > seems fine to me", but a lot of acks that mean "yeah we'll tell you
> > when you're over the line and usurp you from that comfy chair if you
> > don't get it".
>
> Hang on, I didn't get a comfy chair when I signed up for drm-misc! I guess
> that's only for top-level maintainers, huh? ;-)
>
>
> > Which I think we've been done a fairly good job here at
> > dri-devel in general, but better to be clear.
>
> Completely agree, I have 0 doubts.
>
> Acked-by: Sean Paul 

Daniel, thanks for all the work you've done, experiments with
maintainer ship, atomic push, and community fostering are things I
don't think I could have ever made happen.

Personally I've wanted to apply this patch for a few years, thanks for
taking the final leap, patch applied to drm-fixes.

As for me, I'm not retiring, I'm not even sure how we are going to
rebalance things, with all the misc tools and patchwork I've got a
pretty decent workflow now that isn't based on me, but I'd like to let
Daniel push forward into gitlab and other areas and maybe I'll just
keep shovelling along with the legacy until he's ready :-)

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

[pull] drm/msm: msm-next for 4.21

[Rob Clark]

Hi Dave,

A little bigger this time, but still negative diffstat.

This time around, seeing some love for some older hw:

 - a2xx gpu support for apq8060 (hp touchpad) and imx5 (headless
   gpu-only mode)
 - a2xx gpummu support (a2xx was pre-iommu)
 - mdp4 display support for apq8060/touchpad

For display/dpu:

 - a big pile of continuing dpu fixes and cleanups

On the gpu side of things:

 - per-submit statistics and traceevents for better profiling
 - a6xx crashdump support
 - decouple get_iova() and page pinning.. so we can unpin from
   physical memory inactive bo's while using softpin to lower
   cpu overhead
 - new interface to set debug names on GEM BOs and debugfs
   output improvements
 - additional submit flag to indicate buffers that are usef
   to dump (so $debugfs/rd cmdstream dumping is useful with
   softpin + state-objects)



The following changes since commit e69aa5f9b97f7f871643336deb281db5cb14878b:

  Merge tag 'drm-misc-next-2018-12-06' of
git://anongit.freedesktop.org/drm/drm-misc into drm-next (2018-12-07
11:23:05 +1000)

are available in the Git repository at:

  git://people.freedesktop.org/~robclark/linux drm-msm-next-2018-12-12

for you to fetch changes up to ba0ede185ef4c74bfecfe1c992be5dbcc5c5ac04:

  drm/msm/dpu: Fix clock issue after bind failure (2018-12-11 13:10:19 -0500)


Abhinav Kumar (1):
  drm/msm/dsi: fix dsi clock names in DSI 10nm PLL driver

Bruce Wang (4):
  drm/msm/dpu: Remove dpu_kms_pm_suspend/resume
  drm/msm: Cut dpu_kms hooks from msm_pm_suspend/resume
  drm/msm/dpu: Remove suspend state tracking from crtc
  drm/msm/dpu: Replace dpu_crtc_reset by atomic helper

Douglas Anderson (1):
  drm/msm: Only add available components

Jayant Shekhar (2):
  drm/msm/dpu: Correct dpu destroy and disable order
  drm/msm/dpu: Fix clock issue after bind failure

Jeykumar Sankaran (1):
  drm/msm/dpu: set geometry for iommu domain

Jonathan Marek (10):
  drm/msm/mdp4: only use lut_clk on mdp4.2+
  drm/msm/mdp4: allocate blank_cursor_no with MSM_BO_SCANOUT flag
  drm/msm: use contiguous vram for MSM_BO_SCANOUT when possible
  drm/msm/adreno: add a2xx
  drm/msm/mdp5: add config for msm8917
  drm/msm: set priv->kms to NULL before uninit
  drm/msm: implement a2xx mmu
  drm/msm/mdp4: add lcdc-align-lsb flag to control lane alignment
  dt-bindings: display: msm/gpu: document amd,imageon compatible
  drm/msm: add headless gpu device for imx5

Jordan Crouse (29):
  drm/msm/gpu: Allocate the correct size for the GPU memptrs
  drm/msm: Gracefully handle failure in _msm_gem_kernel_new
  drm/msm/gpu: Add per-submission statistics
  drm/msm/gpu: Add trace events for tracking GPU submissions
  drm/msm/gpu: Only store local command buffers in the GPU state
  drm/msm/gpu: Move gpu_poll_timeout() to adreno_gpu.h
  drm/msm/adreno: Don't capture register values if target doesn't
define them
  drm/msm/a6xx: Add a6xx gpu state
  drm/msm/a6xx: Track and manage a6xx state memory
  drm/msm: Add a common function to free kernel buffer objects
  drm/msm: Remove sgt from the mmu unmap function
  drm/msm: Split msm_gem_get_iova into two steps
  drm/msm: Clean up and enhance the output of the 'gem' debugfs node
  drm/msm: Add msm_gem_get_and_pin_iova()
  drm/msm: Count how many times iova memory is pinned
  drm/msm: Add a name field for gem objects
  drm/msm/gpu: Map the ringbuffer in the iova at create time
  drm/msm/a6xx: Use new kernel API free function for gpu state
  drm/msm/a6xx: Add a name for the crashdumper buffer
  drm/msm/dpu: Remove dpu_dbg
  drm/msm/dpu: Remove dpu_crtc_get_mixer_height
  drm/msm/dpu: Remove dpu_crtc_is_enabled()
  drm/msm/dpu: Remove unused functions
  drm/msm/dpu: Cleanup callers of dpu_hw_blk_init
  drm/msm: Make irq_postinstall optional
  drm/msm/dpu: Remove dpu_irq and unused functions
  drm/msm/dpu: Cleanup the debugfs functions
  drm/msm/dpu: Further cleanups for static inline functions
  drm/msm/dpu: Clean up dpu_media_info.h static inline functions

Mamta Shukla (1):
  drm: msm: Use DRM_DEV_* instead of dev_*

Matthias Kaehlcke (1):
  dt-bindings: msm/dsi: Add ref clock for PHYs

Rob Clark (5):
  drm/msm: update generated headers
  drm/msm/gpu: add submit flag to hint which buffers should be dumped
  drm/msm: rework GEM_INFO ioctl
  drm/msm: add uapi to get/set debug name
  drm/msm: bump UAPI version

Sean Paul (35):
  drm/msm: dpu: Add tracing around CTL_FLUSH
  drm/msm: Remove dpu_encoder_phys_ops->hw_reset()
  drm/msm: dpu: Remove unused functions from msm_media_info.h
  drm/msm: dpu: Remove _dpu_encoder_power_enable()
  drm/msm: dpu: Remove 'inline' from several functions
  drm/msm: dpu: Remove empty/useless labels
  drm/msm: dpu: Clean up 

Re: [GIT PULL] mediatek drm fixes for 4.20

[Dave Airlie]

On Mon, 10 Dec 2018 at 12:13, CK Hu  wrote:
>
> Hi, Dave:
>
> Here is one fix.
>
> Regards,
> CK
>
> The following changes since commit
> 651022382c7f8da46cb4872a545ee1da6d097d2a:
>
>   Linux 4.20-rc1 (2018-11-04 15:37:52 -0800)
>
> are available in the Git repository at:
>
>   https://github.com/ckhu-mediatek/linux.git-tags.git a0071bc455da

Something went wrong with your git pull, you didn't get a tag or
branch for me to pull from.

Dave.

>
> for you to fetch changes up to a0071bc455da7b830b9517058933a83eb6cc902a:
>
>   drm/mediatek: Only try to attach bridge if there is one (2018-12-03
> 11:08:22 +0800)
>
> 
> Nicolas Boichat (1):
>   drm/mediatek: Only try to attach bridge if there is one
>
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows

[bugzilla-daemon]

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

tempel.jul...@gmail.com changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #78 from tempel.jul...@gmail.com ---
It's queued now for 4.21:
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.21-wip=0e65ba74dbd61f54f2dc74035d07490d5fd99a38
Thanks, guys! Tested with latest 4.21-wip kernel and seems to be working fine
on a quick try.

I just wanna mention here that Alex assumes the following bug regarding stutter
with gamma adjustments roots to the driver being atomic as well:
https://bugs.freedesktop.org/show_bug.cgi?id=108917
Would be nice if this could be solved a bit faster than the cursor issue
(Nicholas Kazlauskas to the rescue? :) ).

I guess I can close this ticket regarding the cursor now.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v6 0/2] arm64: dts: Add sdm845 GPU/GMU and SMMU

[Jordan Crouse]

Now that more of the sdm845 bindings are headed upstream this a refresh of
of https://patchwork.freedesktop.org/series/39308/ to add bindings and nodes
for the GPU/GMU and GPU SMMU for sdm845.

This is based on :
git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git for-next

with:
https://lore.kernel.org/patchwork/patch/1018365/

This change requires the following dependencies:

include/dt-bindings/power/qcom-rpmpd.h:
https://patchwork.kernel.org/patch/1079/

qcom,smmu-v2 binding:
https://patchwork.kernel.org/patch/10581911/

v6: Update GPU bindings for a6xx and make the examples match the nodes and vice
 versa.  Clean up types and rebase on
 https://lore.kernel.org/patchwork/patch/1018365/ to help facilitate merging.
v5: Use symbolic names for the RPMH power levels defined in OPP table,
 move the opp tables as children of their respective nodes and rename
 the iommu device.
v4: Rebase
v3: Split GMU PDC region into two GPU specific sections, fix indentation,
  really use qcom,gmu for the phandle name
v2: changed qcom,arc-level to qcom,level following discussion with Viresh;
  change gmu phandle to qcom,gmu per Rob

*** BLURB HERE ***

Jordan Crouse (2):
  dt-bindings: drm/msm/a6xx: Document GMU and update GPU bindings
  arm64: dts: sdm845: Add gpu and gmu device nodes

 .../devicetree/bindings/display/msm/gmu.txt   |  56 
 .../devicetree/bindings/display/msm/gpu.txt   |  41 +-
 arch/arm64/boot/dts/qcom/sdm845.dtsi  | 123 ++
 3 files changed, 217 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/msm/gmu.txt

-- 
2.18.0

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

[PATCH v6 1/2] dt-bindings: drm/msm/a6xx: Document GMU and update GPU bindings

[Jordan Crouse]

Update the GPU bindings and document the new bindings for the GMU
device found with Adreno a6xx targets.

Signed-off-by: Jordan Crouse 
---
 .../devicetree/bindings/display/msm/gmu.txt   | 56 +++
 .../devicetree/bindings/display/msm/gpu.txt   | 41 +-
 2 files changed, 94 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/msm/gmu.txt

diff --git a/Documentation/devicetree/bindings/display/msm/gmu.txt 
b/Documentation/devicetree/bindings/display/msm/gmu.txt
new file mode 100644
index ..6152cb551d29
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/gmu.txt
@@ -0,0 +1,56 @@
+Qualcomm adreno/snapdragon GMU (Graphics management unit)
+
+The GMU is a programmable power controller for the GPU. the CPU controls the
+GMU which in turn handles power controls for the GPU.
+
+Required properties:
+- compatible:
+  * "qcom,adreno-gmu"
+- reg: Physical base address and length of the GMU registers.
+- reg-names: Matching names for the register regions
+  * "gmu"
+  * "gmu_pdc"
+  * "gmu_pdc_seg"
+- interrupts: The interrupt signals from the GMU.
+- interrupt-names: Matching names for the interrupts
+  * "hfi"
+  * "gmu"
+- clocks: phandles to the device clocks
+- clock-names: Matching names for the clocks
+   * "gmu"
+   * "cxo"
+   * "axi"
+   * "mnoc"
+- power-domains: should be <_gpucc GPU_CX_GDSC>
+- iommus: phandle to the adreno iommu
+- operating-points-v2: phandle to the OPP operating points
+
+Example:
+
+/ {
+   ...
+
+   gmu: gmu@506a000 {
+   compatible="qcom,adreno-gmu";
+
+   reg = <0x506a000 0x3>,
+   <0xb28 0x1>,
+   <0xb48 0x1>;
+   reg-names = "gmu", "gmu_pdc", "gmu_pdc_seq";
+
+   interrupts = ,
+;
+   interrupt-names = "hfi", "gmu";
+
+   clocks = < GPU_CC_CX_GMU_CLK>,
+   < GPU_CC_CXO_CLK>,
+   < GCC_DDRSS_GPU_AXI_CLK>,
+   < GCC_GPU_MEMNOC_GFX_CLK>;
+   clock-names = "gmu", "cxo", "axi", "memnoc";
+
+   power-domains = < GPU_CX_GDSC>;
+   iommus = <_smmu 5>;
+
+   operating-points-v2 = <_opp_table>;
+   };
+};
diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt 
b/Documentation/devicetree/bindings/display/msm/gpu.txt
index 43fac0fe09bb..8d9415180c22 100644
--- a/Documentation/devicetree/bindings/display/msm/gpu.txt
+++ b/Documentation/devicetree/bindings/display/msm/gpu.txt
@@ -8,14 +8,21 @@ Required properties:
   with the chip-id.
 - reg: Physical base address and length of the controller's registers.
 - interrupts: The interrupt signal from the gpu.
-- clocks: device clocks
+- interrupt-names: List of names for the interrupt signals. The following can 
be
+  provided:
+  * "kgsl_3d0_irq"
+- clocks: device clocks (if applicable)
   See ../clocks/clock-bindings.txt for details.
-- clock-names: the following clocks are required:
+- clock-names: the following clocks can be provided:
   * "core"
   * "iface"
   * "mem_iface"
+- iommus: optional phandle to an adreno iommu instance
+- operating-points-v2: optional phandle to the OPP operating points
+- qcom,gmu: For a6xx and newer targets a phandle to the GMU device that will
+  control the power for the GPU
 
-Example:
+Example 3xx/4xx/a5xx:
 
 / {
...
@@ -36,3 +43,31 @@ Example:
< MMSS_IMEM_AHB_CLK>;
};
 };
+
+Example a6xx (with GMU):
+
+/ {
+   ...
+
+   gpu@500 {
+   compatible = "qcom,adreno-630.2", "qcom,adreno";
+   #stream-id-cells = <16>;
+
+   reg = <0x500 0x4>, <0x509e000 0x10>;
+   reg-names = "kgsl_3d0_reg_memory", "cx_mem";
+
+   /*
+* Look ma, no clocks! The GPU clocks and power are
+* controlled entirely by the GMU
+*/
+
+   interrupts = ;
+   interrupt-names = "kgsl_3d0_irq";
+
+   iommus = <_smmu 0>;
+
+   operating-points-v2 = <_opp_table>;
+
+   qcom,gmu = <>;
+   };
+};
-- 
2.18.0

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

[PATCH v6 2/2] arm64: dts: sdm845: Add gpu and gmu device nodes

[Jordan Crouse]

Add the nodes to describe the Adreno GPU and GMU devices.

Signed-off-by: Jordan Crouse 
---
 arch/arm64/boot/dts/qcom/sdm845.dtsi | 123 +++
 1 file changed, 123 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 233a5898ebc2..a608afed502e 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1349,6 +1350,128 @@
};
};
 
+
+   gpu@500 {
+   compatible = "qcom,adreno-630.2", "qcom,adreno";
+   #stream-id-cells = <16>;
+
+   reg = <0x500 0x4>, <0x509e000 0x10>;
+   reg-names = "kgsl_3d0_reg_memory", "cx_mem";
+
+   /*
+* Look ma, no clocks! The GPU clocks and power are
+* controlled entirely by the GMU
+*/
+
+   interrupts = ;
+   interrupt-names = "kgsl_3d0_irq";
+
+   iommus = <_smmu 0>;
+
+   operating-points-v2 = <_opp_table>;
+
+   qcom,gmu = <>;
+
+   gpu_opp_table: opp-table {
+   compatible = "operating-points-v2-qcom-level";
+
+   opp-71000 {
+   opp-hz = /bits/ 64 <71000>;
+   qcom,level = 
;
+   };
+
+   opp-67500 {
+   opp-hz = /bits/ 64 <67500>;
+   qcom,level = 
;
+   };
+
+   opp-59600 {
+   opp-hz = /bits/ 64 <59600>;
+   qcom,level = 
;
+   };
+
+   opp-52000 {
+   opp-hz = /bits/ 64 <52000>;
+   qcom,level = ;
+   };
+
+   opp-41400 {
+   opp-hz = /bits/ 64 <41400>;
+   qcom,level = 
;
+   };
+
+   opp-34200 {
+   opp-hz = /bits/ 64 <34200>;
+   qcom,level = ;
+   };
+
+   opp-25700 {
+   opp-hz = /bits/ 64 <25700>;
+   qcom,level = 
;
+   };
+   };
+   };
+
+   adreno_smmu: iommu@504 {
+   compatible = "qcom,sdm845-smmu-v2", "qcom,smmu-v2";
+   reg = <0x504 0x1>;
+   #iommu-cells = <1>;
+   #global-interrupts = <2>;
+   interrupts = ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ;
+   clocks = < GCC_GPU_MEMNOC_GFX_CLK>,
+   < GCC_GPU_CFG_AHB_CLK>;
+   clock-names = "bus", "iface";
+
+   power-domains = < GPU_CX_GDSC>;
+   };
+
+   gmu: gmu@506a000 {
+   compatible="qcom,adreno-gmu";
+
+   reg = <0x506a000 0x3>,
+   <0xb28 0x1>,
+   <0xb48 0x1>;
+   reg-names = "gmu", "gmu_pdc", "gmu_pdc_seq";
+
+   interrupts = ,
+;
+   interrupt-names = "hfi", "gmu";
+
+   clocks = < GPU_CC_CX_GMU_CLK>,
+   < GPU_CC_CXO_CLK>,
+   < GCC_DDRSS_GPU_AXI_CLK>,
+   < GCC_GPU_MEMNOC_GFX_CLK>;
+   clock-names = "gmu", "cxo", "axi", "memnoc";
+
+   power-domains = < GPU_CX_GDSC>;
+   iommus = <_smmu 5>;
+
+   operating-points-v2 = <_opp_table>;
+
+   gmu_opp_table: opp-table {
+   compatible = "operating-points-v2-qcom-level";
+
+   

Re: [Intel-gfx] [PATCH v2] drm/i915: correct the pitch check for NV12 framebuffer

[Ville Syrjälä]

On Wed, Dec 12, 2018 at 09:33:49PM +0100, Daniel Vetter wrote:
> On Wed, Dec 12, 2018 at 9:24 PM Ville Syrjälä
>  wrote:
> >
> > On Tue, Dec 11, 2018 at 04:39:05PM -0800, Dongseong Hwang wrote:
> > > framebuffer for NV12 requires the pitch to the multiplier of 4, instead
> > > of the width. This patch corrects it.
> > >
> > > For instance, a 480p video, whose width and pitch are 854 and 896
> > > respectively, is excluded for NV12 plane so far.
> > >
> > > Signed-off-by: Dongseong Hwang 
> > > Cc: Chandra Konduru 
> > > Cc: Vidya Srinivas 
> > > Cc: Ville Syrjälä 
> > > Cc: Juha-Pekka Heikkila 
> > > ---
> > >  drivers/gpu/drm/i915/intel_display.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 13e5650..8a3de12 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -14600,7 +14600,7 @@ static int intel_framebuffer_init(struct 
> > > intel_framebuffer *intel_fb,
> > >   if (fb->format->format == DRM_FORMAT_NV12 &&
> > >   (fb->width < SKL_MIN_YUV_420_SRC_W ||
> > >fb->height < SKL_MIN_YUV_420_SRC_H ||
> > > -  (fb->width % 4) != 0 || (fb->height % 4) != 0)) {
> > > +  (fb->pitches[0] % 4) != 0 || (fb->height % 4) != 0)) {
> >
> > The stride can never be misaligned like that. It'll be at least tile
> > aligned, or 64 byte aligned with linear buffers.
> >
> > Anyways this entire piece of code doesn't make too much sense. The fb
> > size doesn't really matter for us, only the src viewport size matters.
> > That one we limit to a minimum of 2x2 pixels w/o scaling, and 16x16
> > pixems w/ scaling. So looks like this code can be just ripped out.
> 
> Do we have igt testcases for these cornercases in igt? Obviously would
> need to be intel specific subtests ...

Can't spot anything quite that specific. Someone would need to write
one I suppose. Also Imre has a test somewhere on the list for testing
the plane clipping underrun fails which tests small src viewport sizes,
and JP has been working on a rotation vs. clipping test that is also
somewhat related. Not sure if we could combine any of these somehow
to avoid having too many similar tests.

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] amdgpu drm-next-4.21

[Alex Deucher]

Hi Dave,

Updates for 4.21:
- Powerplay updates for newer polaris variants
- Add cursor plane update fast path
- Enable gpu reset by default on CI parts
- Fix config with KFD/HSA not enabled
- Misc bug fixes

The following changes since commit 22666cc1481ae3814d9c7718418cc4a3aa7d90c3:

  drm/amdgpu: move IV prescreening into the GMC code (2018-12-07 18:14:26 -0500)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-next-4.21

for you to fetch changes up to 674e78acae0dfb4beb56132e41cbae5b60f7d662:

  drm/amd/display: Add fast path for cursor plane updates (2018-12-12 15:32:10 
-0500)


Alex Deucher (1):
  drm/amdgpu/powerplay: Add special avfs cases for some polaris asics (v3)

Andrey Grodzovsky (1):
  drm/amdgpu: Enable GPU recovery by default for CI

Kuehling, Felix (1):
  drm/amdgpu: Fix stub function name

Nicholas Kazlauskas (4):
  Revert "drm/amd/display: Set RMX_ASPECT as default"
  drm/amd/display: Fix unintialized max_bpc state values
  drm/amd/display: Fix duplicating scaling/underscan connector state
  drm/amd/display: Add fast path for cursor plane updates

Rex Zhu (1):
  drm/amdgpu: Limit vm max ctx number to 4096

Tiecheng Zhou (1):
  drm/amdgpu: bypass RLC init under sriov for Tonga (v2)

YueHaibing (1):
  drm/amdgpu: remove set but not used variable 'grbm_soft_reset'

 drivers/gpu/drm/amd/amdgpu/amdgpu.h|  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  2 +
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  | 11 +--
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  | 79 --
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h  |  8 +++
 .../drm/amd/powerplay/smumgr/polaris10_smumgr.c| 54 +++
 8 files changed, 147 insertions(+), 12 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] drm-misc-fixes

[Sean Paul]

Hi Dave,
One lonely patch to fix a new WARN on rockchip rk3399 chromebooks.

drm-misc-fixes-2018-12-12:
- rockchip: Revert change causing WARN on shutdown (Brian)

Cc: Brian Norris 

Cheers, Sean


The following changes since commit b31a3ca745a4a47ba63208d37cd50abffe58280f:

  drm/fb-helper: Fix typo in parameter description (2018-12-04 14:22:20 +0100)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2018-12-12

for you to fetch changes up to 63238173b2faf3d6b85a416f1c69af6c7be2413f:

  Revert "drm/rockchip: Allow driver to be shutdown on reboot/kexec" 
(2018-12-11 15:15:57 +0100)


- rockchip: Revert change causing WARN on shutdown (Brian)

Cc: Brian Norris 


Brian Norris (1):
  Revert "drm/rockchip: Allow driver to be shutdown on reboot/kexec"

 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 6 --
 1 file changed, 6 deletions(-)

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/5] drm/msm/dpu: Initialize supported modifiers

[Sean Paul]

On Wed, Dec 12, 2018 at 10:02:26AM -0800, Fritz Koenig wrote:
> On Wed, Dec 12, 2018 at 8:12 AM Sean Paul  wrote:
> >
> > On Tue, Dec 11, 2018 at 10:42:23AM -0800, Fritz Koenig wrote:
> > > Pass list of supported modifiers to plane init.
> > >
> > > Signed-off-by: Fritz Koenig 
> > > ---
> > >  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 8 +++-
> > >  1 file changed, 7 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
> > > b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > > index 9381c8af76d7..d2d4720f6f8c 100644
> > > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > > @@ -119,6 +119,12 @@ struct dpu_plane {
> > >   bool debugfs_default_scale;
> > >  };
> > >
> > > +static const uint64_t supported_format_modifiers[] = {
> > > + DRM_FORMAT_MOD_QCOM_COMPRESSED,
> >
> > Did you confirm that all the planes support this?
> >
> 
> I have not confirmed that all planes support this.  My testing has
> been mostly with null_platform_test.  There are a few comments on in
> the code that seem to indicate to me that the same modifier must be
> used on all planes.
> 
> from dpu_formats.c
> /*
> * Currently only support exactly zero or one modifier.
> * All planes use the same modifier.
> */
> 
> from dpu_hw_catalog.h
> /**
>  * struct dpu_format_extended - define dpu specific pixel format+modifier
>  * @fourcc_format: Base FOURCC pixel format code
>  * @modifier: 64-bit drm format modifier, same modifier must be applied to all
>  *framebuffer planes
>  */

Ah cool, that's good enough for me. I'll pick these into dpu-staging.

Sean

> 
> > Change is
> >
> > Reviewed-by: Sean Paul 
> >
> >
> > > + DRM_FORMAT_MOD_LINEAR,
> > > + DRM_FORMAT_MOD_INVALID
> > > +};
> > > +
> > >  #define to_dpu_plane(x) container_of(x, struct dpu_plane, base)
> > >
> > >  static struct dpu_kms *_dpu_plane_get_kms(struct drm_plane *plane)
> > > @@ -1521,7 +1527,7 @@ struct drm_plane *dpu_plane_init(struct drm_device 
> > > *dev,
> > >
> > >   ret = drm_universal_plane_init(dev, plane, 0xff, _plane_funcs,
> > >   format_list, num_formats,
> > > - NULL, type, NULL);
> > > + supported_format_modifiers, type, NULL);
> > >   if (ret)
> > >   goto clean_sspp;
> > >
> > > --
> > > 2.20.0.rc2.403.gdbc3b29805-goog
> > >
> >
> > --
> > Sean Paul, Software Engineer, Google / Chromium OS

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH v2] drm/i915: correct the pitch check for NV12 framebuffer

[Daniel Vetter]

On Wed, Dec 12, 2018 at 9:24 PM Ville Syrjälä
 wrote:
>
> On Tue, Dec 11, 2018 at 04:39:05PM -0800, Dongseong Hwang wrote:
> > framebuffer for NV12 requires the pitch to the multiplier of 4, instead
> > of the width. This patch corrects it.
> >
> > For instance, a 480p video, whose width and pitch are 854 and 896
> > respectively, is excluded for NV12 plane so far.
> >
> > Signed-off-by: Dongseong Hwang 
> > Cc: Chandra Konduru 
> > Cc: Vidya Srinivas 
> > Cc: Ville Syrjälä 
> > Cc: Juha-Pekka Heikkila 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 13e5650..8a3de12 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -14600,7 +14600,7 @@ static int intel_framebuffer_init(struct 
> > intel_framebuffer *intel_fb,
> >   if (fb->format->format == DRM_FORMAT_NV12 &&
> >   (fb->width < SKL_MIN_YUV_420_SRC_W ||
> >fb->height < SKL_MIN_YUV_420_SRC_H ||
> > -  (fb->width % 4) != 0 || (fb->height % 4) != 0)) {
> > +  (fb->pitches[0] % 4) != 0 || (fb->height % 4) != 0)) {
>
> The stride can never be misaligned like that. It'll be at least tile
> aligned, or 64 byte aligned with linear buffers.
>
> Anyways this entire piece of code doesn't make too much sense. The fb
> size doesn't really matter for us, only the src viewport size matters.
> That one we limit to a minimum of 2x2 pixels w/o scaling, and 16x16
> pixems w/ scaling. So looks like this code can be just ripped out.

Do we have igt testcases for these cornercases in igt? Obviously would
need to be intel specific subtests ...
-Daniel

>
> >   DRM_DEBUG_KMS("src dimensions not correct for NV12\n");
> >   goto err;
> >   }
> > --
> > 2.7.4
>
> --
> Ville Syrjälä
> Intel
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] amdgpu, amdkfd drm-fixes-4.20

[Alex Deucher]

Hi Dave,

Fixes for 4.20:
- Stability fixes for new polaris variants (e.g., RX590)
- New vega pci ids
- Vega20 smu fix
- Ctx locking fix

The following changes since commit e594a5e349ddbfdaca1951bb3f8d72f3f1660d73:

  drm/ast: Fix connector leak during driver unload (2018-12-06 14:12:02 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-fixes-4.20

for you to fetch changes up to 676fff1a5512e7971aa9a235052d253df8f5284a:

  drm/amdgpu: drop fclk/gfxclk ratio setting (2018-12-12 14:52:29 -0500)


Alex Deucher (5):
  drm/amdgpu: update smu firmware images for VI variants (v2)
  drm/amdgpu: add some additional vega10 pci ids
  drm/amdgpu: add some additional vega20 pci ids
  drm/amdkfd: add new vega10 pci ids
  drm/amdkfd: add new vega20 pci id

Andrey Grodzovsky (1):
  drm/amdgpu: Fix DEBUG_LOCKS_WARN_ON(depth <= 0) in amdgpu_ctx.lock

Evan Quan (1):
  drm/amdgpu: drop fclk/gfxclk ratio setting

Junwei Zhang (1):
  drm/amdgpu: update SMC firmware image for polaris10 variants

Kenneth Feng (1):
  drm/amdgpu/powerplay: Apply avfs cks-off voltages on VI

 drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c| 36 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |  4 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|  7 +
 drivers/gpu/drm/amd/amdkfd/kfd_device.c|  7 +
 drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c |  2 +-
 drivers/gpu/drm/amd/powerplay/inc/smu7_ppsmc.h |  2 ++
 .../drm/amd/powerplay/smumgr/polaris10_smumgr.c|  6 
 drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c  |  3 ++
 8 files changed, 58 insertions(+), 9 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/i915: correct the pitch check for NV12 framebuffer

[Ville Syrjälä]

On Tue, Dec 11, 2018 at 04:39:05PM -0800, Dongseong Hwang wrote:
> framebuffer for NV12 requires the pitch to the multiplier of 4, instead
> of the width. This patch corrects it.
> 
> For instance, a 480p video, whose width and pitch are 854 and 896
> respectively, is excluded for NV12 plane so far.
> 
> Signed-off-by: Dongseong Hwang 
> Cc: Chandra Konduru 
> Cc: Vidya Srinivas 
> Cc: Ville Syrjälä 
> Cc: Juha-Pekka Heikkila 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 13e5650..8a3de12 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14600,7 +14600,7 @@ static int intel_framebuffer_init(struct 
> intel_framebuffer *intel_fb,
>   if (fb->format->format == DRM_FORMAT_NV12 &&
>   (fb->width < SKL_MIN_YUV_420_SRC_W ||
>fb->height < SKL_MIN_YUV_420_SRC_H ||
> -  (fb->width % 4) != 0 || (fb->height % 4) != 0)) {
> +  (fb->pitches[0] % 4) != 0 || (fb->height % 4) != 0)) {

The stride can never be misaligned like that. It'll be at least tile
aligned, or 64 byte aligned with linear buffers.

Anyways this entire piece of code doesn't make too much sense. The fb
size doesn't really matter for us, only the src viewport size matters.
That one we limit to a minimum of 2x2 pixels w/o scaling, and 16x16
pixems w/ scaling. So looks like this code can be just ripped out.

>   DRM_DEBUG_KMS("src dimensions not correct for NV12\n");
>   goto err;
>   }
> -- 
> 2.7.4

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH libdrm 2/2] libdrm: Use DRM_IOCTL_GET_PCIINFO on DragonFly

[François Tigeot]

It is a cleaner and less fragile way to get PCI IDs than the one
currently used by local DPorts patches.

Signed-off-by: François Tigeot 
---
 xf86drm.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xf86drm.c b/xf86drm.c
index 5ddf9366..6db1ab96 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -101,7 +101,7 @@
 #define DRM_MAJOR 226 /* Linux */
 #endif
 
-#ifdef __OpenBSD__
+#if defined(__OpenBSD__) || defined(__DragonFly__)
 struct drm_pciinfo {
uint16_tdomain;
uint8_t bus;
@@ -3065,7 +3065,7 @@ static int drmParsePciBusInfo(int maj, int min, 
drmPciBusInfoPtr info)
 info->func = func;
 
 return 0;
-#elif defined(__OpenBSD__)
+#elif defined(__OpenBSD__) || defined(__DragonFly__)
 struct drm_pciinfo pinfo;
 int fd, type;
 
@@ -3231,7 +3231,7 @@ static int drmParsePciDeviceInfo(int maj, int min,
 return parse_config_sysfs_file(maj, min, device);
 
 return 0;
-#elif defined(__OpenBSD__)
+#elif defined(__OpenBSD__) || defined(__DragonFly__)
 struct drm_pciinfo pinfo;
 int fd, type;
 
-- 
2.19.2

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

[PATCH libdrm 1/2] xf86drm: implement drmParseSubsystemType for DragonFly

[François Tigeot]

Like on OpenBSD, the DragonFly BSD kernel only contains
pci drm drivers.

Signed-off-by: François Tigeot 
---
 xf86drm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xf86drm.c b/xf86drm.c
index 0085bf17..5ddf9366 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -3016,7 +3016,7 @@ static int drmParseSubsystemType(int maj, int min)
 }
 
 return -EINVAL;
-#elif defined(__OpenBSD__)
+#elif defined(__OpenBSD__) || defined(__DragonFly__)
 return DRM_BUS_PCI;
 #else
 #warning "Missing implementation of drmParseSubsystemType"
-- 
2.19.2

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

Re: [PATCH v5 1/2] dt-bindings: Document,qcom,adreno-gmu

[Jordan Crouse]

On Wed, Dec 12, 2018 at 11:26:46AM -0800, Doug Anderson wrote:
> Hi,
> 
> On Wed, Dec 12, 2018 at 9:31 AM Jordan Crouse  wrote:
> >
> > Document the device tree bindings for the Adreno GMU device
> > available on Adreno a6xx targets.
> >
> > Reviewed-by: Rob Herring 
> > Signed-off-by: Jordan Crouse 
> > ---
> >  .../devicetree/bindings/display/msm/gmu.txt   | 54 +++
> >  .../devicetree/bindings/display/msm/gpu.txt   |  2 +
> >  2 files changed, 56 insertions(+)
> 
> nit: Why does subject have a "," after "Document"?

Typo.

> nit: Should subject start "dt-bindings: drm/msm/a6xx" or something
> like that?  I thought you wanted not just "dt-bindings" but also a
> subsystem prefix?

I was trying to reuse the subject from the previous versions, but I would be
happy to change it.

> 
> >  create mode 100644 Documentation/devicetree/bindings/display/msm/gmu.txt
> >
> > diff --git a/Documentation/devicetree/bindings/display/msm/gmu.txt 
> > b/Documentation/devicetree/bindings/display/msm/gmu.txt
> > new file mode 100644
> > index ..f65bb49fff36
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/msm/gmu.txt
> > @@ -0,0 +1,54 @@
> > +Qualcomm adreno/snapdragon GMU (Graphics management unit)
> > +
> > +The GMU is a programmable power controller for the GPU. the CPU controls 
> > the
> > +GMU which in turn handles power controls for the GPU.
> > +
> > +Required properties:
> > +- compatible:
> > +  * "qcom,adreno-gmu"
> > +- reg: Physical base address and length of the GMU registers.
> > +- reg-names: Matching names for the register regions
> > +  * "gmu"
> > +  * "gmu_pdc"
> > +- interrupts: The interrupt signals from the GMU.
> > +- interrupt-names: Matching names for the interrupts
> > +  * "hfi"
> > +  * "gmu"
> > +- clocks: phandles to the device clocks
> > +- clock-names: Matching names for the clocks
> > +   * "gmu"
> > +   * "cxo"
> > +   * "axi"
> > +   * "mnoc"
> > +- power-domains: should be <_gpucc GPU_CX_GDSC>
> > +- iommus: phandle to the adreno iommu
> > +- operating-points-v2: phandle to the OPP operating points
> > +
> > +Example:
> > +
> > +/ {
> > +   ...
> > +
> > +   gmu: gmu@506a000 {
> > +   compatible="qcom,adreno-gmu";
> > +
> > +   reg = <0x506a000 0x3>,
> > +   <0xb20 0x30>;
> > +   reg-names = "gmu", "gmu_pdc";
> 
> Your implementation has 3 register ranges but your bindings have 2.
> You also have a different address for "gmu_pdc" even though it looks
> like your examples are supposed to be based on sdm845.
>
> (you'd want to not only change the example but also the bindings above)

I'll update the settings - a new region has indeed been added since the last
time we were here.

> 
> > +
> > +   interrupts = ,
> > +   ;
> > +   interrupt-names = "hfi", "gmu";
> > +
> > +   clocks = <_gpucc GPU_CC_CX_GMU_CLK>,
> > +   <_gpucc GPU_CC_CXO_CLK>,
> > +   <_gcc GCC_DDRSS_GPU_AXI_CLK>,
> > +   <_gcc GCC_GPU_MEMNOC_GFX_CLK>;
> 
> nit: might as well update to "" to match the style of clock
> controller labels used in sdm845.dts.
> 
> 
> > +   clock-names = "gmu", "cxo", "axi", "memnoc";
> > +
> > +   power-domains = <_gpucc GPU_CX_GDSC>;
> > +   iommus = <_smmu 5>;
> > +
> > +   i   operating-points-v2 = <_opp_table>;
> 
> Why "i"?

Also a typo.

> ...also: worth actually including the operating table here in the example?

I say no.  It might good practice to have the opp tables in the child node but I
don't think it is mandatory from a bindings perspective.

The bindings are documented elsewhere and to me that seems enough for our
purposes - at least thats our story for smmu and gpucc and other phandles.

> 
> > +   };
> > +};
> > diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt 
> > b/Documentation/devicetree/bindings/display/msm/gpu.txt
> > index 43fac0fe09bb..754f6c6f34e5 100644
> > --- a/Documentation/devicetree/bindings/display/msm/gpu.txt
> > +++ b/Documentation/devicetree/bindings/display/msm/gpu.txt
> > @@ -14,6 +14,8 @@ Required properties:
> >* "core"
> >* "iface"
> >* "mem_iface"
> > +- qcom,gmu: For a6xx and newer targets a phandle to the GMU device that 
> > will
> > +  control the power for the GPU
> 
> You seem to have lost something between the previous version of this
> and the latest.  In the last version (and the version Rob gave his
> review to) you added some extra text.  Diffing your old patch to your
> new one:
> 
> -Optional properties.
> -- clocks: device clocks. Required for a3xx, a4xx and a5xx targets. a6xx and
> -  newer with a GMU attached do not have direct clock control from the CPU and
> -  do not need to provide clock properties.
> +- clocks: device clocks
>See ../clocks/clock-bindings.txt for details.
> -- clock-names: the following clocks can be 

Re: [PATCH v5 1/2] dt-bindings: Document,qcom,adreno-gmu

[Doug Anderson]

Hi,

On Wed, Dec 12, 2018 at 9:31 AM Jordan Crouse  wrote:
>
> Document the device tree bindings for the Adreno GMU device
> available on Adreno a6xx targets.
>
> Reviewed-by: Rob Herring 
> Signed-off-by: Jordan Crouse 
> ---
>  .../devicetree/bindings/display/msm/gmu.txt   | 54 +++
>  .../devicetree/bindings/display/msm/gpu.txt   |  2 +
>  2 files changed, 56 insertions(+)

nit: Why does subject have a "," after "Document"?

nit: Should subject start "dt-bindings: drm/msm/a6xx" or something
like that?  I thought you wanted not just "dt-bindings" but also a
subsystem prefix?


>  create mode 100644 Documentation/devicetree/bindings/display/msm/gmu.txt
>
> diff --git a/Documentation/devicetree/bindings/display/msm/gmu.txt 
> b/Documentation/devicetree/bindings/display/msm/gmu.txt
> new file mode 100644
> index ..f65bb49fff36
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/msm/gmu.txt
> @@ -0,0 +1,54 @@
> +Qualcomm adreno/snapdragon GMU (Graphics management unit)
> +
> +The GMU is a programmable power controller for the GPU. the CPU controls the
> +GMU which in turn handles power controls for the GPU.
> +
> +Required properties:
> +- compatible:
> +  * "qcom,adreno-gmu"
> +- reg: Physical base address and length of the GMU registers.
> +- reg-names: Matching names for the register regions
> +  * "gmu"
> +  * "gmu_pdc"
> +- interrupts: The interrupt signals from the GMU.
> +- interrupt-names: Matching names for the interrupts
> +  * "hfi"
> +  * "gmu"
> +- clocks: phandles to the device clocks
> +- clock-names: Matching names for the clocks
> +   * "gmu"
> +   * "cxo"
> +   * "axi"
> +   * "mnoc"
> +- power-domains: should be <_gpucc GPU_CX_GDSC>
> +- iommus: phandle to the adreno iommu
> +- operating-points-v2: phandle to the OPP operating points
> +
> +Example:
> +
> +/ {
> +   ...
> +
> +   gmu: gmu@506a000 {
> +   compatible="qcom,adreno-gmu";
> +
> +   reg = <0x506a000 0x3>,
> +   <0xb20 0x30>;
> +   reg-names = "gmu", "gmu_pdc";

Your implementation has 3 register ranges but your bindings have 2.
You also have a different address for "gmu_pdc" even though it looks
like your examples are supposed to be based on sdm845.

(you'd want to not only change the example but also the bindings above)


> +
> +   interrupts = ,
> +   ;
> +   interrupt-names = "hfi", "gmu";
> +
> +   clocks = <_gpucc GPU_CC_CX_GMU_CLK>,
> +   <_gpucc GPU_CC_CXO_CLK>,
> +   <_gcc GCC_DDRSS_GPU_AXI_CLK>,
> +   <_gcc GCC_GPU_MEMNOC_GFX_CLK>;

nit: might as well update to "" to match the style of clock
controller labels used in sdm845.dts.


> +   clock-names = "gmu", "cxo", "axi", "memnoc";
> +
> +   power-domains = <_gpucc GPU_CX_GDSC>;
> +   iommus = <_smmu 5>;
> +
> +   i   operating-points-v2 = <_opp_table>;

Why "i"?

...also: worth actually including the operating table here in the example?


> +   };
> +};
> diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt 
> b/Documentation/devicetree/bindings/display/msm/gpu.txt
> index 43fac0fe09bb..754f6c6f34e5 100644
> --- a/Documentation/devicetree/bindings/display/msm/gpu.txt
> +++ b/Documentation/devicetree/bindings/display/msm/gpu.txt
> @@ -14,6 +14,8 @@ Required properties:
>* "core"
>* "iface"
>* "mem_iface"
> +- qcom,gmu: For a6xx and newer targets a phandle to the GMU device that will
> +  control the power for the GPU

You seem to have lost something between the previous version of this
and the latest.  In the last version (and the version Rob gave his
review to) you added some extra text.  Diffing your old patch to your
new one:

-Optional properties.
-- clocks: device clocks. Required for a3xx, a4xx and a5xx targets. a6xx and
-  newer with a GMU attached do not have direct clock control from the CPU and
-  do not need to provide clock properties.
+- clocks: device clocks
   See ../clocks/clock-bindings.txt for details.
-- clock-names: the following clocks can be provided:
+- clock-names: the following clocks are required:

Did you mean to remove that?  Your current bindings now say that the
clocks are required but then your device tree patch for sdm845 says
they're not.

>  Example:

While you're touching this file, maybe update the "Example" so instead
of saying "qcom,kgsl-3d0@" it says "gpu@"


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

Re: [PATCH v5 2/2] arm64: dts: sdm845: Add gpu and gmu device nodes

[Doug Anderson]

Hi,

On Wed, Dec 12, 2018 at 9:31 AM Jordan Crouse  wrote:
>
> Add the nodes to describe the Adreno GPU and GMU devices.
>
> Signed-off-by: Jordan Crouse 
> ---
>  arch/arm64/boot/dts/qcom/sdm845.dtsi | 123 +++
>  1 file changed, 123 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index c27cbd3bcb0a..daa404b05a70 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -7,9 +7,11 @@
>
>  #include 
>  #include 
> +#include 

Probably don't need to add this in your patch since (presumably) your
patch needs to be based atop
 and that already
adds the #include (and also the node that you depend on).


>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1348,6 +1350,127 @@
> };
> };
>
> +   gpu@500 {
> +   compatible = "qcom,adreno-630.2", "qcom,adreno";
> +   #stream-id-cells = <16>;
> +
> +   reg = <0x500 0x4>, <0x509e000 0x10>;
> +   reg-names = "kgsl_3d0_reg_memory", "cx_mem";

The second register range isn't in your bindings patch.  Can you add it?


> +   /*
> +* Look ma, no clocks! The GPU clocks and power are
> +* controlled entirely by the GMU
> +*/
> +
> +   interrupts = ;
> +   interrupt-names = "kgsl_3d0_irq";
> +
> +   iommus = <_smmu 0>;

It it worth mentioning the iommus and #stream-id-cells in the bindings?


> +   operating-points-v2 = <_opp_table>;

Is it worth mentioning the operating-points-v2 in the bindings patch?


> +
> +   qcom,gmu = <>;
> +
> +   gpu_opp_table: adreno-opp-table {

nit: since this is no longer at the top level you can just call it
"opp-table" now.  That matches what the latest RPMh PD node looks
like.


> +   compatible = "operating-points-v2-qcom-level";
> +
> +   opp-71000 {
> +   opp-hz = /bits/ 64 <71000>;
> +   qcom,level = 
> ;
> +   };
> +
> +   opp-67500 {
> +   opp-hz = /bits/ 64 <67500>;
> +   qcom,level = 
> ;
> +   };
> +
> +   opp-59600 {
> +   opp-hz = /bits/ 64 <59600>;
> +   qcom,level = 
> ;
> +   };
> +
> +   opp-52000 {
> +   opp-hz = /bits/ 64 <52000>;
> +   qcom,level = 
> ;
> +   };
> +
> +   opp-41400 {
> +   opp-hz = /bits/ 64 <41400>;
> +   qcom,level = 
> ;
> +   };
> +
> +   opp-34200 {
> +   opp-hz = /bits/ 64 <34200>;
> +   qcom,level = 
> ;
> +   };
> +
> +   opp-25700 {
> +   opp-hz = /bits/ 64 <25700>;
> +   qcom,level = 
> ;
> +   };
> +   };
> +   };
> +
> +   adreno_smmu: iommu@504 {
> +   compatible = "qcom,sdm845-smmu-v2", "qcom,smmu-v2";
> +   reg = <0x504 0x1>;
> +   #iommu-cells = <1>;
> +   #global-interrupts = <2>;
> +   interrupts = ,
> +   ,
> +   ,
> +   ,
> +   ,
> +   ,
> +   ,
> +   ,
> +   ,
> +   ;
> +   clocks = < GCC_GPU_MEMNOC_GFX_CLK>,
> +   < GCC_GPU_CFG_AHB_CLK>;
> +   clock-names = "bus", "iface";
> +
> +   power-domains = < GPU_CX_GDSC>;
> +   };
> +
> +   gmu: gmu@506a000 {
> +   compatible="qcom,adreno-gmu";
> +
> +   reg = <0x506a000 0x3>,
> +  

Re: [PATCH -fixes] drm/vmwgfx: Protect from excessive execbuf kernel memory allocations v2

[Deepak Singh Rawat]

Reviewed-by: Deepak Rawat 

On Wed, 2018-12-12 at 10:38 -0800, Thomas Hellstrom wrote:
> Hi, Deepak,
> 
> On Wed, 2018-12-12 at 10:00 -0800, Deepak Singh Rawat wrote:
> > On Wed, 2018-12-12 at 15:35 +0100, Thomas Hellstrom wrote:
> > > With the new validation code, a malicious user-space app could
> > > potentially submit command streams with enough buffer-object and
> > > resource
> > > references in them to have the resulting allocated validion nodes
> > > and
> > > relocations make the kernel run out of GFP_KERNEL memory.
> > > 
> > > Protect from this by having the validation code reserve TTM
> > > graphics
> > > memory when allocating.
> > > 
> > > Signed-off-by: Thomas Hellstrom 
> > > ---
> > > v2: Removed leftover debug printouts
> > > ---
> > >  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c|  4 ++-
> > >  drivers/gpu/drm/vmwgfx/vmwgfx_drv.h|  5 +++
> > >  drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c|  2 ++
> > >  drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c   | 36
> > > +
> > >  drivers/gpu/drm/vmwgfx/vmwgfx_validation.c | 18 ++-
> > >  drivers/gpu/drm/vmwgfx/vmwgfx_validation.h | 37
> > > ++
> > >  6 files changed, 100 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> > > b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> > > index 61a84b958d67..d7a2dfb8ee9b 100644
> > > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> > > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> > > @@ -49,6 +49,8 @@
> > >  
> > >  #define VMWGFX_REPO "In Tree"
> > >  
> > > +#define VMWGFX_VALIDATION_MEM_GRAN (16*PAGE_SIZE)
> > > +
> > >  
> > >  /**
> > >   * Fully encoded drm commands. Might move to vmw_drm.h
> > > @@ -918,7 +920,7 @@ static int vmw_driver_load(struct drm_device
> > > *dev, unsigned long chipset)
> > >   spin_unlock(_priv->cap_lock);
> > >   }
> > >  
> > > -
> > > + vmw_validation_mem_init_ttm(dev_priv,
> > > VMWGFX_VALIDATION_MEM_GRAN);
> > >   ret = vmw_kms_init(dev_priv);
> > >   if (unlikely(ret != 0))
> > >   goto out_no_kms;
> > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> > > b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> > > index 59f614225bcd..aca974b14b55 100644
> > > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> > > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> > > @@ -606,6 +606,9 @@ struct vmw_private {
> > >  
> > >   struct vmw_cmdbuf_man *cman;
> > >   DECLARE_BITMAP(irqthread_pending, VMW_IRQTHREAD_MAX);
> > > +
> > > + /* Validation memory reservation */
> > > + struct vmw_validation_mem vvm;
> > >  };
> > >  
> > >  static inline struct vmw_surface *vmw_res_to_srf(struct
> > > vmw_resource
> > > *res)
> > > @@ -846,6 +849,8 @@ extern int vmw_ttm_global_init(struct
> > > vmw_private
> > > *dev_priv);
> > >  extern void vmw_ttm_global_release(struct vmw_private
> > > *dev_priv);
> > >  extern int vmw_mmap(struct file *filp, struct vm_area_struct
> > > *vma);
> > >  
> > > +extern void vmw_validation_mem_init_ttm(struct vmw_private
> > > *dev_priv,
> > > + size_t gran);
> > >  /**
> > >   * TTM buffer object driver - vmwgfx_ttm_buffer.c
> > >   */
> > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> > > b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> > > index 260650bb5560..f2d13a72c05d 100644
> > > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> > > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> > > @@ -3835,6 +3835,8 @@ int vmw_execbuf_process(struct drm_file
> > > *file_priv,
> > >   struct sync_file *sync_file = NULL;
> > >   DECLARE_VAL_CONTEXT(val_ctx, _context->res_ht, 1);
> > >  
> > > + vmw_validation_set_val_mem(_ctx, _priv->vvm);
> > > +
> > >   if (flags & DRM_VMW_EXECBUF_FLAG_EXPORT_FENCE_FD) {
> > >   out_fence_fd = get_unused_fd_flags(O_CLOEXEC);
> > >   if (out_fence_fd < 0) {
> > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
> > > b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
> > > index 7b1e5a5cbd2c..f88247046721 100644
> > > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
> > > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
> > > @@ -96,3 +96,39 @@ void vmw_ttm_global_release(struct vmw_private
> > > *dev_priv)
> > >   drm_global_item_unref(_priv->bo_global_ref.ref);
> > >   drm_global_item_unref(_priv->mem_global_ref);
> > >  }
> > > +
> > > +/* struct vmw_validation_mem callback */
> > > +static int vmw_vmt_reserve(struct vmw_validation_mem *m, size_t
> > > size)
> > > +{
> > > + static struct ttm_operation_ctx ctx = {.interruptible = false,
> > > +.no_wait_gpu = false};
> > > + struct vmw_private *dev_priv = container_of(m, struct
> > > vmw_private, vvm);
> > > +
> > > + return ttm_mem_global_alloc(vmw_mem_glob(dev_priv), size,
> > > );
> > > +}
> > > +
> > > +/* struct vmw_validation_mem callback */
> > > +static void vmw_vmt_unreserve(struct vmw_validation_mem *m,
> > > size_t
> > > size)
> > > +{
> > > + struct vmw_private *dev_priv = container_of(m, struct
> > > vmw_private, 

Re: [PATCH -fixes] drm/vmwgfx: Protect from excessive execbuf kernel memory allocations v2

[Thomas Hellstrom]

Hi, Deepak,

On Wed, 2018-12-12 at 10:00 -0800, Deepak Singh Rawat wrote:
> On Wed, 2018-12-12 at 15:35 +0100, Thomas Hellstrom wrote:
> > With the new validation code, a malicious user-space app could
> > potentially submit command streams with enough buffer-object and
> > resource
> > references in them to have the resulting allocated validion nodes
> > and
> > relocations make the kernel run out of GFP_KERNEL memory.
> > 
> > Protect from this by having the validation code reserve TTM
> > graphics
> > memory when allocating.
> > 
> > Signed-off-by: Thomas Hellstrom 
> > ---
> > v2: Removed leftover debug printouts
> > ---
> >  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c|  4 ++-
> >  drivers/gpu/drm/vmwgfx/vmwgfx_drv.h|  5 +++
> >  drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c|  2 ++
> >  drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c   | 36
> > +
> >  drivers/gpu/drm/vmwgfx/vmwgfx_validation.c | 18 ++-
> >  drivers/gpu/drm/vmwgfx/vmwgfx_validation.h | 37
> > ++
> >  6 files changed, 100 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> > b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> > index 61a84b958d67..d7a2dfb8ee9b 100644
> > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> > @@ -49,6 +49,8 @@
> >  
> >  #define VMWGFX_REPO "In Tree"
> >  
> > +#define VMWGFX_VALIDATION_MEM_GRAN (16*PAGE_SIZE)
> > +
> >  
> >  /**
> >   * Fully encoded drm commands. Might move to vmw_drm.h
> > @@ -918,7 +920,7 @@ static int vmw_driver_load(struct drm_device
> > *dev, unsigned long chipset)
> > spin_unlock(_priv->cap_lock);
> > }
> >  
> > -
> > +   vmw_validation_mem_init_ttm(dev_priv,
> > VMWGFX_VALIDATION_MEM_GRAN);
> > ret = vmw_kms_init(dev_priv);
> > if (unlikely(ret != 0))
> > goto out_no_kms;
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> > b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> > index 59f614225bcd..aca974b14b55 100644
> > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> > @@ -606,6 +606,9 @@ struct vmw_private {
> >  
> > struct vmw_cmdbuf_man *cman;
> > DECLARE_BITMAP(irqthread_pending, VMW_IRQTHREAD_MAX);
> > +
> > +   /* Validation memory reservation */
> > +   struct vmw_validation_mem vvm;
> >  };
> >  
> >  static inline struct vmw_surface *vmw_res_to_srf(struct
> > vmw_resource
> > *res)
> > @@ -846,6 +849,8 @@ extern int vmw_ttm_global_init(struct
> > vmw_private
> > *dev_priv);
> >  extern void vmw_ttm_global_release(struct vmw_private *dev_priv);
> >  extern int vmw_mmap(struct file *filp, struct vm_area_struct
> > *vma);
> >  
> > +extern void vmw_validation_mem_init_ttm(struct vmw_private
> > *dev_priv,
> > +   size_t gran);
> >  /**
> >   * TTM buffer object driver - vmwgfx_ttm_buffer.c
> >   */
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> > b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> > index 260650bb5560..f2d13a72c05d 100644
> > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> > @@ -3835,6 +3835,8 @@ int vmw_execbuf_process(struct drm_file
> > *file_priv,
> > struct sync_file *sync_file = NULL;
> > DECLARE_VAL_CONTEXT(val_ctx, _context->res_ht, 1);
> >  
> > +   vmw_validation_set_val_mem(_ctx, _priv->vvm);
> > +
> > if (flags & DRM_VMW_EXECBUF_FLAG_EXPORT_FENCE_FD) {
> > out_fence_fd = get_unused_fd_flags(O_CLOEXEC);
> > if (out_fence_fd < 0) {
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
> > b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
> > index 7b1e5a5cbd2c..f88247046721 100644
> > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
> > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
> > @@ -96,3 +96,39 @@ void vmw_ttm_global_release(struct vmw_private
> > *dev_priv)
> > drm_global_item_unref(_priv->bo_global_ref.ref);
> > drm_global_item_unref(_priv->mem_global_ref);
> >  }
> > +
> > +/* struct vmw_validation_mem callback */
> > +static int vmw_vmt_reserve(struct vmw_validation_mem *m, size_t
> > size)
> > +{
> > +   static struct ttm_operation_ctx ctx = {.interruptible = false,
> > +  .no_wait_gpu = false};
> > +   struct vmw_private *dev_priv = container_of(m, struct
> > vmw_private, vvm);
> > +
> > +   return ttm_mem_global_alloc(vmw_mem_glob(dev_priv), size,
> > );
> > +}
> > +
> > +/* struct vmw_validation_mem callback */
> > +static void vmw_vmt_unreserve(struct vmw_validation_mem *m, size_t
> > size)
> > +{
> > +   struct vmw_private *dev_priv = container_of(m, struct
> > vmw_private, vvm);
> > +
> > +   return ttm_mem_global_free(vmw_mem_glob(dev_priv), size);
> > +}
> > +
> > +/**
> > + * vmw_validation_mem_init_ttm - Interface the validation memory
> > tracker
> > + * to ttm.
> > + * @dev_priv: Pointer to struct vmw_private. The reason we choose
> > a
> > vmw private
> > + * rather than 

Re: [PATCH 4/5] drm/msm/dpu: Initialize supported modifiers

[Fritz Koenig]

On Wed, Dec 12, 2018 at 8:12 AM Sean Paul  wrote:
>
> On Tue, Dec 11, 2018 at 10:42:23AM -0800, Fritz Koenig wrote:
> > Pass list of supported modifiers to plane init.
> >
> > Signed-off-by: Fritz Koenig 
> > ---
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 8 +++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > index 9381c8af76d7..d2d4720f6f8c 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > @@ -119,6 +119,12 @@ struct dpu_plane {
> >   bool debugfs_default_scale;
> >  };
> >
> > +static const uint64_t supported_format_modifiers[] = {
> > + DRM_FORMAT_MOD_QCOM_COMPRESSED,
>
> Did you confirm that all the planes support this?
>

I have not confirmed that all planes support this.  My testing has
been mostly with null_platform_test.  There are a few comments on in
the code that seem to indicate to me that the same modifier must be
used on all planes.

from dpu_formats.c
/*
* Currently only support exactly zero or one modifier.
* All planes use the same modifier.
*/

from dpu_hw_catalog.h
/**
 * struct dpu_format_extended - define dpu specific pixel format+modifier
 * @fourcc_format: Base FOURCC pixel format code
 * @modifier: 64-bit drm format modifier, same modifier must be applied to all
 *framebuffer planes
 */

> Change is
>
> Reviewed-by: Sean Paul 
>
>
> > + DRM_FORMAT_MOD_LINEAR,
> > + DRM_FORMAT_MOD_INVALID
> > +};
> > +
> >  #define to_dpu_plane(x) container_of(x, struct dpu_plane, base)
> >
> >  static struct dpu_kms *_dpu_plane_get_kms(struct drm_plane *plane)
> > @@ -1521,7 +1527,7 @@ struct drm_plane *dpu_plane_init(struct drm_device 
> > *dev,
> >
> >   ret = drm_universal_plane_init(dev, plane, 0xff, _plane_funcs,
> >   format_list, num_formats,
> > - NULL, type, NULL);
> > + supported_format_modifiers, type, NULL);
> >   if (ret)
> >   goto clean_sspp;
> >
> > --
> > 2.20.0.rc2.403.gdbc3b29805-goog
> >
>
> --
> Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel