[Freedreno] [PATCH v10 00/10] drm/hdcp: Pull HDCP auth/exchange/check into helpers

[Dmitry Baryshkov]

On 26/04/2023 19:29, Doug Anderson wrote:
> Hi,
> 
> On Wed, Apr 19, 2023 at 8:43 AM Mark Yacoub <markyacoub at 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