Hi, On Wed, Apr 19, 2023 at 8:43 AM Mark Yacoub <markyacoub@xxxxxxxxxxxx> 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. -Doug
