From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
To: Doug Anderson <dianders@chromium.org>,
Mark Yacoub <markyacoub@chromium.org>
Cc: Jani Nikula <jani.nikula@intel.com>,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
Konrad Dybcio <konrad.dybcio@linaro.org>,
seanpaul@chromium.org, Daniel Vetter <daniel@ffwll.ch>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
freedreno@lists.freedesktop.org,
Mark Yacoub <markyacoub@google.com>
Subject: Re: [Intel-gfx] [PATCH v10 00/10] drm/hdcp: Pull HDCP auth/exchange/check into helpers
Date: Thu, 27 Apr 2023 18:51:37 +0300 [thread overview]
Message-ID: <30f8e69f-b1f1-a9c5-e2ee-1be021a11393@linaro.org> (raw)
In-Reply-To: <CAD=FV=V1+PMH3YGOcnvziOC7-_NY1yO4w=b4q2RLCdtEtETB3Q@mail.gmail.com>
On 26/04/2023 19:29, Doug Anderson wrote:
> Hi,
>
> On Wed, Apr 19, 2023 at 8:43 AM Mark Yacoub <markyacoub@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
next prev parent reply other threads:[~2023-04-27 15:51 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-19 15:43 [Intel-gfx] [PATCH v10 00/10] drm/hdcp: Pull HDCP auth/exchange/check into helpers Mark Yacoub
2023-04-19 15:43 ` [Intel-gfx] [PATCH v10 01/10] drm/hdcp: Add drm_hdcp_atomic_check() Mark Yacoub
2023-04-19 15:43 ` [Intel-gfx] [PATCH v10 02/10] drm/hdcp: Avoid changing crtc state in hdcp atomic check Mark Yacoub
2023-04-19 15:43 ` [Intel-gfx] [PATCH v10 03/10] drm/hdcp: Update property value on content type and user changes Mark Yacoub
2023-04-19 15:43 ` [Intel-gfx] [PATCH v10 04/10] drm/hdcp: Expand HDCP helper library for enable/disable/check Mark Yacoub
2023-04-19 15:43 ` [Intel-gfx] [PATCH v10 05/10] drm/i915/hdcp: Consolidate HDCP setup/state cache Mark Yacoub
2023-04-19 15:43 ` [Intel-gfx] [PATCH v10 06/10] drm/i915/hdcp: Retain hdcp_capable return codes Mark Yacoub
2023-04-19 15:43 ` [Intel-gfx] [PATCH v10 07/10] drm/i915/hdcp: Use HDCP helpers for i915 Mark Yacoub
2023-04-19 15:43 ` [Intel-gfx] [PATCH v10 08/10] dt-bindings: msm/dp: Add bindings for HDCP registers Mark Yacoub
2023-04-19 15:43 ` [Intel-gfx] [PATCH v10 09/10] arm64: dts: qcom: sc7180: Add support for HDCP in dp-controller Mark Yacoub
2023-04-19 15:43 ` [Intel-gfx] [PATCH v10 10/10] drm/msm: Implement HDCP 1.x using the new drm HDCP helpers Mark Yacoub
2023-04-20 7:41 ` kernel test robot
2023-04-20 11:39 ` kernel test robot
2023-04-19 18:00 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/hdcp: Pull HDCP auth/exchange/check into helpers (rev10) Patchwork
2023-04-26 16:29 ` [Intel-gfx] [PATCH v10 00/10] drm/hdcp: Pull HDCP auth/exchange/check into helpers Doug Anderson
2023-04-27 15:51 ` Dmitry Baryshkov [this message]
2023-05-19 16:55 ` Dmitry Baryshkov
2023-05-19 21:16 ` Rodrigo Vivi
2023-05-19 23:07 ` Dmitry Baryshkov
2023-05-22 12:59 ` Rodrigo Vivi
2023-05-25 23:46 ` Doug Anderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=30f8e69f-b1f1-a9c5-e2ee-1be021a11393@linaro.org \
--to=dmitry.baryshkov@linaro.org \
--cc=daniel@ffwll.ch \
--cc=dianders@chromium.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@intel.com \
--cc=konrad.dybcio@linaro.org \
--cc=markyacoub@chromium.org \
--cc=markyacoub@google.com \
--cc=rodrigo.vivi@intel.com \
--cc=seanpaul@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox