On 26/04/2023 19:29, Doug Anderson wrote:
Hi,
On Wed, Apr 19, 2023 at 8:43 AM Mark Yacoub <markyac...@chromium.org> wrote:
Hi all,
This is v10 of the HDCP patches. The patches are authored by Sean Paul.
I rebased and addressed the review comments in v6-v10.
Main change in v10 is handling the kernel test bot warnings.
Patches 1-4 focus on moving the common HDCP helpers to common DRM.
This introduces a slight change in the original intel flow
as it splits the unique driver protocol from the generic implementation.
Patches 5-7 split the HDCP flow on the i915 driver to make use of the common
DRM helpers.
Patches 8-10 implement HDCP on MSM driver.
Thanks,
-Mark Yacoub
Sean Paul (10):
drm/hdcp: Add drm_hdcp_atomic_check()
drm/hdcp: Avoid changing crtc state in hdcp atomic check
drm/hdcp: Update property value on content type and user changes
drm/hdcp: Expand HDCP helper library for enable/disable/check
drm/i915/hdcp: Consolidate HDCP setup/state cache
drm/i915/hdcp: Retain hdcp_capable return codes
drm/i915/hdcp: Use HDCP helpers for i915
dt-bindings: msm/dp: Add bindings for HDCP registers
arm64: dts: qcom: sc7180: Add support for HDCP in dp-controller
drm/msm: Implement HDCP 1.x using the new drm HDCP helpers
.../bindings/display/msm/dp-controller.yaml | 7 +-
arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 8 +
drivers/gpu/drm/display/drm_hdcp_helper.c | 1224 +++++++++++++++++
drivers/gpu/drm/i915/display/intel_atomic.c | 8 +-
drivers/gpu/drm/i915/display/intel_ddi.c | 32 +-
.../drm/i915/display/intel_display_debugfs.c | 12 +-
.../drm/i915/display/intel_display_types.h | 51 +-
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 352 ++---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 16 +-
drivers/gpu/drm/i915/display/intel_hdcp.c | 1060 +++-----------
drivers/gpu/drm/i915/display/intel_hdcp.h | 48 +-
drivers/gpu/drm/i915/display/intel_hdmi.c | 267 ++--
drivers/gpu/drm/msm/Kconfig | 1 +
drivers/gpu/drm/msm/Makefile | 1 +
drivers/gpu/drm/msm/dp/dp_catalog.c | 156 +++
drivers/gpu/drm/msm/dp/dp_catalog.h | 18 +
drivers/gpu/drm/msm/dp/dp_debug.c | 46 +-
drivers/gpu/drm/msm/dp/dp_debug.h | 11 +-
drivers/gpu/drm/msm/dp/dp_display.c | 39 +-
drivers/gpu/drm/msm/dp/dp_display.h | 5 +
drivers/gpu/drm/msm/dp/dp_drm.c | 39 +-
drivers/gpu/drm/msm/dp/dp_drm.h | 7 +
drivers/gpu/drm/msm/dp/dp_hdcp.c | 389 ++++++
drivers/gpu/drm/msm/dp/dp_hdcp.h | 33 +
drivers/gpu/drm/msm/dp/dp_parser.c | 14 +
drivers/gpu/drm/msm/dp/dp_parser.h | 4 +
drivers/gpu/drm/msm/dp/dp_reg.h | 30 +-
drivers/gpu/drm/msm/msm_atomic.c | 19 +
include/drm/display/drm_hdcp.h | 296 ++++
include/drm/display/drm_hdcp_helper.h | 23 +
30 files changed, 2867 insertions(+), 1349 deletions(-)
Mark asked me if I had any advice for getting this patch series
landed. I haven't been following the patch series super closely, but
as I understand it:
1. The first several patches (the generic ones) seem fairly well
reviewed and haven't changed in any significant ways in a while. The
ideal place to land these would be drm-misc, I think.
2. The i915 patches also seem OK to land. The ideal place would be the
Intel DRM tree, I think.
3. The msm patches are not fully baked yet. Not only is there a kernel
bot complaint on patch #10, but Mark also said that comments from v6
haven't yet fully been addressed and he's talked with Dmitry on IRC
about this and has a plan to move forward.
The question becomes: can/should we land the generic and maybe the
i915 patches now while the msm patches are reworked. Do folks have an
opinion here? If we're OK landing some of the patches, I guess we have
a few options:
a) Just land the generic patches to drm-misc and put the i915 ones on
the backburner until drm-misc has made it to somewhere that the
drm-intel tree is based on. If we want to go this route and nobody
objects, I don't mind being the person who does the gruntwork of
actually landing them on drm-misc-next, though I certainly wouldn't
rush to make sure that nobody is unhappy with this idea.
b) Land the generic patches in some type of immutable branch so they
can be pulled into drm-misc and the Intel DRM tree. Someone more
senior to me would need to help with this, but if we really want to go
this way I can poke folks on IRC.
c) Land the generic and Intel patches in the Intel tree. The msm
patches would not be able to land until these trickled up the chain,
but the msm patches aren't fully ready yet anyway so maybe this is OK.
d) Land the generic and Intel patches in the drm-misc tree. If folks
are OK with this I can be the person to pull the trigger, but I'd want
to be very sure that Intel DRM folks are on board. :-)
My preference would be c), then d), then a), then b). ...this is all
assuming, of course, that nobody on this thread objects to landing the
generic/i195 patches now.
I'd also vote for c) I think it would be the best if the relevan patches
can be taken in the drm-intel after the -rc1. Once the msm patches are
finalized, we can back-merge drm-next and apply our part on top of that.
-Doug
--
With best wishes
Dmitry
