RE: [PATCH v5 3/6] mei: clean pending read with vtag on bus
>
> From: Alexander Usyskin
>
> Client on bus have only one vtag map slot and should disregard the vtag
> value when cleaning pending read flag.
> Fixes read flow control message unexpectedly generated when clent on bus
> send messages with different vtags.
>
> Signed-off-by: Alexander Usyskin
> Signed-off-by: Alan Previn
Reviewed-by: Tomas Winkler
> ---
> drivers/misc/mei/client.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/misc/mei/client.c b/drivers/misc/mei/client.c index
> 9ddb854b8155..5c19097266fe 100644
> --- a/drivers/misc/mei/client.c
> +++ b/drivers/misc/mei/client.c
> @@ -1343,7 +1343,9 @@ static void mei_cl_reset_read_by_vtag(const struct
> mei_cl *cl, u8 vtag)
> struct mei_cl_vtag *vtag_l;
>
> list_for_each_entry(vtag_l, >vtag_map, list) {
> - if (vtag_l->vtag == vtag) {
> + /* The client on bus has one fixed vtag map */
> + if ((cl->cldev && mei_cldev_enabled(cl->cldev)) ||
> + vtag_l->vtag == vtag) {
> vtag_l->pending_read = false;
> break;
> }
> --
> 2.39.0
RE: [PATCH v5 1/6] mei: mei-me: resume device in prepare
>
> From: Alexander Usyskin
>
> Asynchronous runtime resume is not possible while the system is
> suspending.
> The power management subsystem resumes the device only in the suspend
> phase, not in the prepare phase.
> Force resume device in prepare to allow drivers on mei bus to communicate
> in their prepare callbacks.
>
> Signed-off-by: Alexander Usyskin
> Signed-off-by: Alan Previn
Reviewed-by: Tomas Winkler
> ---
> drivers/misc/mei/pci-me.c | 20 +++-
> 1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/misc/mei/pci-me.c b/drivers/misc/mei/pci-me.c index
> 704cd0caa172..9f6ff06a94fd 100644
> --- a/drivers/misc/mei/pci-me.c
> +++ b/drivers/misc/mei/pci-me.c
> @@ -340,6 +340,12 @@ static void mei_me_remove(struct pci_dev *pdev) }
>
> #ifdef CONFIG_PM_SLEEP
> +static int mei_me_pci_prepare(struct device *device) {
> + pm_runtime_resume(device);
> + return 0;
> +}
> +
> static int mei_me_pci_suspend(struct device *device) {
> struct pci_dev *pdev = to_pci_dev(device); @@ -396,7 +402,17 @@
> static int mei_me_pci_resume(struct device *device)
>
> return 0;
> }
> -#endif /* CONFIG_PM_SLEEP */
> +
> +static void mei_me_pci_complete(struct device *device) {
> + pm_runtime_suspend(device);
> +}
> +#else /* CONFIG_PM_SLEEP */
> +
> +#define mei_me_pci_prepare NULL
> +#define mei_me_pci_complete NULL
> +
> +#endif /* !CONFIG_PM_SLEEP */
>
> #ifdef CONFIG_PM
> static int mei_me_pm_runtime_idle(struct device *device) @@ -499,6
> +515,8 @@ static inline void mei_me_unset_pm_domain(struct mei_device
> *dev) }
>
> static const struct dev_pm_ops mei_me_pm_ops = {
> + .prepare = mei_me_pci_prepare,
> + .complete = mei_me_pci_complete,
> SET_SYSTEM_SLEEP_PM_OPS(mei_me_pci_suspend,
> mei_me_pci_resume)
> SET_RUNTIME_PM_OPS(
> --
> 2.39.0
RE: [PATCH] drm/i915: rename intel_gsc to intel_heci_gsc
>
>
> On 11/3/2022 3:41 AM, Winkler, Tomas wrote:
> >> Starting on MTL, the GSC FW is loaded at runtime and will be managed
> >> directly by i915. This means we now have a naming clash around the
> >> GSC, as we have 2 different aspects of it that we need to handle: the
> >> HECI interfaces we export pre-mtl and the new full FW loading and
> >> support we have to introduce starting from MTL. To avoid confusion,
> >> rename the existing intel_gsc structure to intel_heci_gsc, to make it
> >> clear it contains the data related to the HECI interfaces.
> >>
> > Are you sure you want to take this path, it will make backporting quite
> difficult.
>
> The diff is relatively small (< 50 lines), so it shouldn't be too bad.
> Otherwise, do you have any suggestion on how to avoid name clashing in a
> different way? I really want to avoid confusion around legacy heci gsc and
> new runtime-loaded gsc. My plan was to name them intel_heci_gsc and
> intel_gsc_uc respectively, to make it super clear which is which, but I'm open
> to alternatives.
I think if you use intel_gsc_uc and leave the old as it is (at least for few
kernel release cylces) it would good. There is always spike of issues with thew
new hardware that requires backports to stable kernels.
That's what I think.
Thanks
Tomas
>
> Daniele
>
> >
> >> Signed-off-by: Daniele Ceraolo Spurio
> >>
> >> Cc: Tomas Winkler
> >> Cc: Alexander Usyskin
> >> ---
> >> drivers/gpu/drm/i915/Makefile | 4 +-
> >> drivers/gpu/drm/i915/gt/intel_gt.c| 4 +-
> >> drivers/gpu/drm/i915/gt/intel_gt.h| 4 +-
> >> drivers/gpu/drm/i915/gt/intel_gt_irq.c| 2 +-
> >> drivers/gpu/drm/i915/gt/intel_gt_types.h | 4 +-
> >> .../i915/gt/{intel_gsc.c => intel_heci_gsc.c} | 43
> >> ++- .../i915/gt/{intel_gsc.h => intel_heci_gsc.h} | 22
> +-
> >> drivers/gpu/drm/i915/gt/uc/intel_huc.c| 10 ++---
> >> drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 2 +-
> >> 9 files changed, 48 insertions(+), 47 deletions(-) rename
> >> drivers/gpu/drm/i915/gt/{intel_gsc.c => intel_heci_gsc.c} (84%)
> >> rename drivers/gpu/drm/i915/gt/{intel_gsc.h => intel_heci_gsc.h}
> >> (52%)
> >>
> >> diff --git a/drivers/gpu/drm/i915/Makefile
> >> b/drivers/gpu/drm/i915/Makefile index 51704b54317c..2fa401dcf087
> >> 100644
> >> --- a/drivers/gpu/drm/i915/Makefile
> >> +++ b/drivers/gpu/drm/i915/Makefile
> >> @@ -206,8 +206,8 @@ i915-y += gt/uc/intel_uc.o \
> >> gt/uc/intel_huc_debugfs.o \
> >> gt/uc/intel_huc_fw.o
> >>
> >> -# graphics system controller (GSC) support -i915-y += gt/intel_gsc.o
> >> +# graphics system controller (GSC) HECI support i915-y +=
> >> +gt/intel_heci_gsc.o
> >>
> >> # graphics hardware monitoring (HWMON) support
> >> i915-$(CONFIG_HWMON) += i915_hwmon.o diff --git
> >> a/drivers/gpu/drm/i915/gt/intel_gt.c
> >> b/drivers/gpu/drm/i915/gt/intel_gt.c
> >> index 8e914c4066ed..6ca72479c943 100644
> >> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> >> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> >> @@ -454,7 +454,7 @@ void intel_gt_chipset_flush(struct intel_gt *gt)
> >>
> >> void intel_gt_driver_register(struct intel_gt *gt) {
> >> - intel_gsc_init(>gsc, gt->i915);
> >> + intel_heci_gsc_init(>heci_gsc, gt->i915);
> >>
> >>intel_rps_driver_register(>rps);
> >>
> >> @@ -785,7 +785,7 @@ void intel_gt_driver_unregister(struct intel_gt
> >> *gt)
> >>
> >>intel_gt_sysfs_unregister(gt);
> >>intel_rps_driver_unregister(>rps);
> >> - intel_gsc_fini(>gsc);
> >> + intel_heci_gsc_fini(>heci_gsc);
> >>
> >>intel_pxp_fini(>pxp);
> >>
> >> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
> >> b/drivers/gpu/drm/i915/gt/intel_gt.h
> >> index e0365d556248..43f73239a363 100644
> >> --- a/drivers/gpu/drm/i915/gt/intel_gt.h
> >> +++ b/drivers/gpu/drm/i915/gt/intel_gt.h
> >> @@ -39,9 +39,9 @@ static inline struct intel_gt *huc_to_gt(struct
> >> intel_huc
> >> *huc)
> >>return container_of(huc, struct intel_gt, uc.huc); }
> >>
> >> -static inline struct intel_gt *gsc_to_gt(struct intel_gsc *gsc)
> >> +static inline struct intel_gt *heci_gsc_to_gt(struct intel_heci_gsc
> >> +*heci_gsc)
> >
RE: [PATCH] drm/i915: rename intel_gsc to intel_heci_gsc
>
> Starting on MTL, the GSC FW is loaded at runtime and will be managed
> directly by i915. This means we now have a naming clash around the GSC, as
> we have 2 different aspects of it that we need to handle: the HECI interfaces
> we export pre-mtl and the new full FW loading and support we have to
> introduce starting from MTL. To avoid confusion, rename the existing
> intel_gsc structure to intel_heci_gsc, to make it clear it contains the data
> related to the HECI interfaces.
>
Are you sure you want to take this path, it will make backporting quite
difficult.
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Tomas Winkler
> Cc: Alexander Usyskin
> ---
> drivers/gpu/drm/i915/Makefile | 4 +-
> drivers/gpu/drm/i915/gt/intel_gt.c| 4 +-
> drivers/gpu/drm/i915/gt/intel_gt.h| 4 +-
> drivers/gpu/drm/i915/gt/intel_gt_irq.c| 2 +-
> drivers/gpu/drm/i915/gt/intel_gt_types.h | 4 +-
> .../i915/gt/{intel_gsc.c => intel_heci_gsc.c} | 43 ++-
> .../i915/gt/{intel_gsc.h => intel_heci_gsc.h} | 22 +-
> drivers/gpu/drm/i915/gt/uc/intel_huc.c| 10 ++---
> drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 2 +-
> 9 files changed, 48 insertions(+), 47 deletions(-) rename
> drivers/gpu/drm/i915/gt/{intel_gsc.c => intel_heci_gsc.c} (84%) rename
> drivers/gpu/drm/i915/gt/{intel_gsc.h => intel_heci_gsc.h} (52%)
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 51704b54317c..2fa401dcf087 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -206,8 +206,8 @@ i915-y += gt/uc/intel_uc.o \
> gt/uc/intel_huc_debugfs.o \
> gt/uc/intel_huc_fw.o
>
> -# graphics system controller (GSC) support -i915-y += gt/intel_gsc.o
> +# graphics system controller (GSC) HECI support i915-y +=
> +gt/intel_heci_gsc.o
>
> # graphics hardware monitoring (HWMON) support
> i915-$(CONFIG_HWMON) += i915_hwmon.o
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> b/drivers/gpu/drm/i915/gt/intel_gt.c
> index 8e914c4066ed..6ca72479c943 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -454,7 +454,7 @@ void intel_gt_chipset_flush(struct intel_gt *gt)
>
> void intel_gt_driver_register(struct intel_gt *gt) {
> - intel_gsc_init(>gsc, gt->i915);
> + intel_heci_gsc_init(>heci_gsc, gt->i915);
>
> intel_rps_driver_register(>rps);
>
> @@ -785,7 +785,7 @@ void intel_gt_driver_unregister(struct intel_gt *gt)
>
> intel_gt_sysfs_unregister(gt);
> intel_rps_driver_unregister(>rps);
> - intel_gsc_fini(>gsc);
> + intel_heci_gsc_fini(>heci_gsc);
>
> intel_pxp_fini(>pxp);
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
> b/drivers/gpu/drm/i915/gt/intel_gt.h
> index e0365d556248..43f73239a363 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.h
> @@ -39,9 +39,9 @@ static inline struct intel_gt *huc_to_gt(struct intel_huc
> *huc)
> return container_of(huc, struct intel_gt, uc.huc); }
>
> -static inline struct intel_gt *gsc_to_gt(struct intel_gsc *gsc)
> +static inline struct intel_gt *heci_gsc_to_gt(struct intel_heci_gsc
> +*heci_gsc)
> {
> - return container_of(gsc, struct intel_gt, gsc);
> + return container_of(heci_gsc, struct intel_gt, heci_gsc);
> }
>
> void intel_gt_common_init_early(struct intel_gt *gt); diff --git
> a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> index f26882fdc24c..3b4bd237659a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> @@ -75,7 +75,7 @@ gen11_other_irq_handler(struct intel_gt *gt, const u8
> instance,
> return intel_pxp_irq_handler(>pxp, iir);
>
> if (instance == OTHER_GSC_INSTANCE)
> - return intel_gsc_irq_handler(gt, iir);
> + return intel_heci_gsc_irq_handler(gt, iir);
>
> WARN_ONCE(1, "unhandled other interrupt instance=0x%x,
> iir=0x%x\n",
> instance, iir);
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> index a0cc73b401ef..80a0163dcc01 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> @@ -17,7 +17,7 @@
> #include
>
> #include "uc/intel_uc.h"
> -#include "intel_gsc.h"
> +#include "intel_heci_gsc.h"
>
> #include "i915_vma.h"
> #include "i915_perf_types.h"
> @@ -100,7 +100,7 @@ struct intel_gt {
> struct i915_ggtt *ggtt;
>
> struct intel_uc uc;
> - struct intel_gsc gsc;
> + struct intel_heci_gsc heci_gsc;
>
> struct {
> /* Serialize global tlb invalidations */ diff --git
> a/drivers/gpu/drm/i915/gt/intel_gsc.c
> b/drivers/gpu/drm/i915/gt/intel_heci_gsc.c
> similarity index 84%
> rename from drivers/gpu/drm/i915/gt/intel_gsc.c
> rename to drivers/gpu/drm/i915/gt/intel_heci_gsc.c
> index
RE: [PATCH v5 00/15] drm/i915: HuC loading for DG2
> On Wed, Sep 14, 2022 at 04:51:03PM +0000, Winkler, Tomas wrote: > > > > > > On DG2, HuC loading is performed by the GSC, via a PXP command. The > > > load operation itself is relatively simple (just send a message to > > > the GSC with the physical address of the HuC in LMEM), but there are > > > timing changes that requires special attention. In particular, to > > > send a PXP command we need to first export the GSC as an aux device > > > and then wait for the mei-gsc and mei- pxp modules to start, which > > > means that HuC load will complete after i915 load is complete. This > > > means that there is a small window of time after i915 is registered > > > and before HuC is loaded during which userspace could submit and/or > > > check the HuC load status, although this is quite unlikely to happen (HuC > is usually loaded before kernel init/resume completes). > > > We've consulted with the media team in regards to how to handle this > > > and they've asked us to stall all userspace VCS submission until HuC is > loaded. > > > Stalls are expected to be very rare (if any), due to the fact that > > > HuC is usually loaded before kernel init/resume is completed. > > > > > > Timeouts are in place to ensure all submissions are unlocked in case > > > something goes wrong. Since we need to monitor the status of the mei > > > driver to know what's happening and when to time out, a notifier has > > > been added so we get a callback when the status of the mei driver > changes. > > > > > > Note that this series includes several mei patches that add support > > > for sending the HuC loading command via mei-gsc. We plan to merge > > > those patches through the drm tree because i915 is the sole user. > > > > > > v2: address review comments, Reporting HuC loading still in progress > > > while we wait for mei-gsc init to complete, rebase on latest mei-gsc > series. > > > > > > v3: fix cc list in mei patches. > > > > > > v4: update mei patches, fix includes, rebase on new FW fetch logic > > > and merged mei-gsc support. > > > > > > v5: update mei patches > > > > Greg, I hope I've addressed most of your comments. > > Can you please check if the mei patches are in acceptable state or anything > else can be improved with this series. Appreciated. > > These were sent 2 days ago, in the middle of a conference travel. > Please relax, there's no special rush needed here, you know better. Sure > In the mean time, if you are just waiting for my review, please take the time > to review other pending patches from other developers to help lighten the > load on me, and other maintainers. Fair enough, that's all I do every day anyway. Thanks Tomas
RE: [PATCH v5 00/15] drm/i915: HuC loading for DG2
> > On DG2, HuC loading is performed by the GSC, via a PXP command. The load > operation itself is relatively simple (just send a message to the GSC with the > physical address of the HuC in LMEM), but there are timing changes that > requires special attention. In particular, to send a PXP command we need to > first export the GSC as an aux device and then wait for the mei-gsc and mei- > pxp modules to start, which means that HuC load will complete after i915 > load is complete. This means that there is a small window of time after i915 > is > registered and before HuC is loaded during which userspace could submit > and/or check the HuC load status, although this is quite unlikely to happen > (HuC is usually loaded before kernel init/resume completes). > We've consulted with the media team in regards to how to handle this and > they've asked us to stall all userspace VCS submission until HuC is loaded. > Stalls are expected to be very rare (if any), due to the fact that HuC is > usually > loaded before kernel init/resume is completed. > > Timeouts are in place to ensure all submissions are unlocked in case > something goes wrong. Since we need to monitor the status of the mei > driver to know what's happening and when to time out, a notifier has been > added so we get a callback when the status of the mei driver changes. > > Note that this series includes several mei patches that add support for > sending the HuC loading command via mei-gsc. We plan to merge those > patches through the drm tree because i915 is the sole user. > > v2: address review comments, Reporting HuC loading still in progress while > we wait for mei-gsc init to complete, rebase on latest mei-gsc series. > > v3: fix cc list in mei patches. > > v4: update mei patches, fix includes, rebase on new FW fetch logic and > merged mei-gsc support. > > v5: update mei patches Greg, I hope I've addressed most of your comments. Can you please check if the mei patches are in acceptable state or anything else can be improved with this series. Appreciated. Thanks Tomas > > Cc: Alan Previn > Cc: Tony Ye > Cc: Alexander Usyskin > Cc: Tomas Winkler > Cc: Greg Kroah-Hartman > > Daniele Ceraolo Spurio (7): > drm/i915/pxp: load the pxp module when we have a gsc-loaded huc > drm/i915/dg2: setup HuC loading via GSC > drm/i915/huc: track delayed HuC load with a fence > drm/i915/huc: stall media submission until HuC is loaded > drm/i915/huc: better define HuC status getparam possible return > values. > drm/i915/huc: define gsc-compatible HuC fw for DG2 > HAX: drm/i915: force INTEL_MEI_GSC and INTEL_MEI_PXP on for CI > > Tomas Winkler (5): > mei: add support to GSC extended header > mei: bus: enable sending gsc commands > mei: adjust extended header kdocs > mei: pxp: support matching with a gfx discrete card > drm/i915/pxp: add huc authentication and loading command > > Vitaly Lubart (3): > mei: bus: extend bus API to support command streamer API > mei: pxp: add command streamer API to the PXP driver > drm/i915/pxp: implement function for sending tee stream command > > drivers/gpu/drm/i915/Kconfig.debug| 2 + > drivers/gpu/drm/i915/Makefile | 11 +- > drivers/gpu/drm/i915/gt/intel_gsc.c | 22 +- > drivers/gpu/drm/i915/gt/uc/intel_guc.c| 1 + > drivers/gpu/drm/i915/gt/uc/intel_huc.c| 254 -- > drivers/gpu/drm/i915/gt/uc/intel_huc.h| 31 +++ > drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 34 +++ > drivers/gpu/drm/i915/gt/uc/intel_huc_fw.h | 1 + > drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 24 +- > drivers/gpu/drm/i915/i915_request.c | 24 ++ > drivers/gpu/drm/i915/pxp/intel_pxp.c | 32 ++- > drivers/gpu/drm/i915/pxp/intel_pxp.h | 32 --- > drivers/gpu/drm/i915/pxp/intel_pxp_huc.c | 69 + > drivers/gpu/drm/i915/pxp/intel_pxp_huc.h | 13 + > drivers/gpu/drm/i915/pxp/intel_pxp_irq.h | 8 + > drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 8 +- > drivers/gpu/drm/i915/pxp/intel_pxp_session.h | 11 +- > drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 138 +- > drivers/gpu/drm/i915/pxp/intel_pxp_tee.h | 5 + > .../drm/i915/pxp/intel_pxp_tee_interface.h| 23 +- > drivers/gpu/drm/i915/pxp/intel_pxp_types.h| 6 + > drivers/misc/mei/bus.c| 146 +- > drivers/misc/mei/client.c | 55 ++-- > drivers/misc/mei/hbm.c| 13 + > drivers/misc/mei/hw-me.c | 7 +- > drivers/misc/mei/hw.h | 89 +- > drivers/misc/mei/interrupt.c | 47 +++- > drivers/misc/mei/mei_dev.h| 8 + > drivers/misc/mei/pxp/mei_pxp.c| 38 ++- > include/drm/i915_pxp_tee_interface.h | 5 + > include/linux/mei_cl_bus.h| 6 + > include/uapi/drm/i915_drm.h
RE: [PATCH v4 06/15] mei: pxp: support matching with a gfx discrete card
> card
>
> On Fri, Sep 09, 2022 at 09:21:30AM +, Winkler, Tomas wrote:
> > > >
> > > > > -Original Message-
> > > > > From: Greg Kroah-Hartman
> > > > > Sent: Friday, September 09, 2022 09:16
> > > > > To: Ceraolo Spurio, Daniele
> > > > > Cc: intel-...@lists.freedesktop.org;
> > > > > dri-devel@lists.freedesktop.org; Winkler, Tomas
> > > > > ; Lubart, Vitaly
> > > > > ; Teres Alexis, Alan Previn
> > > > >
> > > > > Subject: Re: [PATCH v4 06/15] mei: pxp: support matching with a
> > > > > gfx discrete card
> > > > >
> > > > > On Thu, Sep 08, 2022 at 05:16:03PM -0700, Daniele Ceraolo Spurio
> wrote:
> > > > > > From: Tomas Winkler
> > > > > >
> > > > > > With on-boards graphics card, both i915 and MEI are in the
> > > > > > same device hierarchy with the same parent, while for discrete
> > > > > > gfx card the MEI is its child device.
> > > > > > Adjust the match function for that scenario by matching MEI
> > > > > > parent device with i915.
> > > > > >
> > > > > > V2:
> > > > > > 1. More detailed commit message 2. Check for dev is not null
> > > > > > before it is accessed.
> > > > > >
> > > > > > Signed-off-by: Tomas Winkler
> > > > > > Signed-off-by: Daniele Ceraolo Spurio
> > > > > >
> > > > > > Cc: Vitaly Lubart
> > > > > > Cc: Greg Kroah-Hartman
> > > > > > Reviewed-by: Alan Previn
> > > > > > ---
> > > > > > drivers/misc/mei/pxp/mei_pxp.c | 13 ++---
> > > > > > 1 file changed, 10 insertions(+), 3 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/misc/mei/pxp/mei_pxp.c
> > > > > > b/drivers/misc/mei/pxp/mei_pxp.c index
> > > > > > 17c5d201603f..afc047627800
> > > > > > 100644
> > > > > > --- a/drivers/misc/mei/pxp/mei_pxp.c
> > > > > > +++ b/drivers/misc/mei/pxp/mei_pxp.c
> > > > > > @@ -159,17 +159,24 @@ static int
> > > > > > mei_pxp_component_match(struct
> > > > > device
> > > > > > *dev, int subcomponent, {
> > > > > > struct device *base = data;
> > > > > >
> > > > > > + if (!dev)
> > > > > > + return 0;
> > > > >
> > > > > How can that happen?
> > > > >
> > > > > > +
> > > > > > if (!dev->driver || strcmp(dev->driver->name, "i915") ||
> > > > >
> > > > > That's crazy to assume, but whatever :(
> > > > Explained here:
> > > > https://lore.kernel.org/all/20220418175932.1809770-2-
> > > wonchung@google.c
> > > > om/
> > >
> > > Still crazy :(
> > >
> > > >
> > > > >
> > > > > > subcomponent != I915_COMPONENT_PXP)
> > > > > > return 0;
> > > > > >
> > > > > > base = base->parent;
> > > > > > - if (!base)
> > > > > > + if (!base) /* mei device */
> > > > >
> > > > > Why does this mean that?
> > > > >
> > > > > Where is that documented?
> > > > >
> > > > > > return 0;
> > > > > >
> > > > > > - base = base->parent;
> > > > > > - dev = dev->parent;
> > > > > > + base = base->parent; /* pci device */
> > > > >
> > > > > Again, why is this the case?
> > > > >
> > > > > > + /* for dgfx */
> > > > > > + if (base && dev == base)
> > > > > > + return 1;
> > > > > >
> > > > > > + /* for pch */
> > > > > > + dev = dev->parent;
> > > > >
> > > > > You are digging through a random device tree and assuming that
> > > > > you
> > > "know"
> > > > > what the topology is going to be, that feels very very fragile
> > > > > and ripe for problems going forward.
> > > >
>
RE: [PATCH v4 05/15] mei: pxp: add command streamer API to the PXP driver
>
> On Fri, Sep 09, 2022 at 06:38:33AM +, Winkler, Tomas wrote:
> > >
> > > On Thu, Sep 08, 2022 at 05:16:02PM -0700, Daniele Ceraolo Spurio wrote:
> > > > +static ssize_t mei_pxp_gsc_command(struct device *dev, u8
> > > > +client_id,
> > > u32 fence_id,
> > > > + struct scatterlist *sg_in, size_t
> > > > total_in_len,
> > > > + struct scatterlist *sg_out) {
> > > > + struct mei_cl_device *cldev;
> > > > +
> > > > + if (!dev || !sg_in || !sg_out)
> > > > + return -EINVAL;
> > >
> > > How can these ever be NULL? Doesn't the core control this, so why
> > > would that happen?
> > This is any interface function between modules, I think it is not
> > healthy to take assumptions here about how caller behaves, this is not an
> inner functions. This is important even for catching programmatical mistakes.
>
> It is a static function being called from a framework. Enforce this in the
> framework, don't sprinkle this stuff everywhere, the kernel is NOT defensive
> about internal users like this otherwise it will overwhelm every function
> call.
I'm not sure, this is the case here. The function is passed to i915 (other
driver) driver via struct i915_pxp_component_op.
This is outside of the component framework.
Thanks
Tomas
RE: [PATCH v4 06/15] mei: pxp: support matching with a gfx discrete card
> >
> > > -Original Message-
> > > From: Greg Kroah-Hartman
> > > Sent: Friday, September 09, 2022 09:16
> > > To: Ceraolo Spurio, Daniele
> > > Cc: intel-...@lists.freedesktop.org;
> > > dri-devel@lists.freedesktop.org; Winkler, Tomas
> > > ; Lubart, Vitaly ;
> > > Teres Alexis, Alan Previn
> > > Subject: Re: [PATCH v4 06/15] mei: pxp: support matching with a gfx
> > > discrete card
> > >
> > > On Thu, Sep 08, 2022 at 05:16:03PM -0700, Daniele Ceraolo Spurio wrote:
> > > > From: Tomas Winkler
> > > >
> > > > With on-boards graphics card, both i915 and MEI are in the same
> > > > device hierarchy with the same parent, while for discrete gfx card
> > > > the MEI is its child device.
> > > > Adjust the match function for that scenario by matching MEI parent
> > > > device with i915.
> > > >
> > > > V2:
> > > > 1. More detailed commit message
> > > > 2. Check for dev is not null before it is accessed.
> > > >
> > > > Signed-off-by: Tomas Winkler
> > > > Signed-off-by: Daniele Ceraolo Spurio
> > > >
> > > > Cc: Vitaly Lubart
> > > > Cc: Greg Kroah-Hartman
> > > > Reviewed-by: Alan Previn
> > > > ---
> > > > drivers/misc/mei/pxp/mei_pxp.c | 13 ++---
> > > > 1 file changed, 10 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/misc/mei/pxp/mei_pxp.c
> > > > b/drivers/misc/mei/pxp/mei_pxp.c index 17c5d201603f..afc047627800
> > > > 100644
> > > > --- a/drivers/misc/mei/pxp/mei_pxp.c
> > > > +++ b/drivers/misc/mei/pxp/mei_pxp.c
> > > > @@ -159,17 +159,24 @@ static int mei_pxp_component_match(struct
> > > device
> > > > *dev, int subcomponent, {
> > > > struct device *base = data;
> > > >
> > > > + if (!dev)
> > > > + return 0;
> > >
> > > How can that happen?
> > >
> > > > +
> > > > if (!dev->driver || strcmp(dev->driver->name, "i915") ||
> > >
> > > That's crazy to assume, but whatever :(
> > Explained here:
> > https://lore.kernel.org/all/20220418175932.1809770-2-
> wonchung@google.c
> > om/
>
> Still crazy :(
>
> >
> > >
> > > > subcomponent != I915_COMPONENT_PXP)
> > > > return 0;
> > > >
> > > > base = base->parent;
> > > > - if (!base)
> > > > + if (!base) /* mei device */
> > >
> > > Why does this mean that?
> > >
> > > Where is that documented?
> > >
> > > > return 0;
> > > >
> > > > - base = base->parent;
> > > > - dev = dev->parent;
> > > > + base = base->parent; /* pci device */
> > >
> > > Again, why is this the case?
> > >
> > > > + /* for dgfx */
> > > > + if (base && dev == base)
> > > > + return 1;
> > > >
> > > > + /* for pch */
> > > > + dev = dev->parent;
> > >
> > > You are digging through a random device tree and assuming that you
> "know"
> > > what the topology is going to be, that feels very very fragile and
> > > ripe for problems going forward.
> >
> > I don't think it is random.
>
> Today it is one specific way, but how do you know this always will be this
> way?
>
> > > How do you ensure that this really is they way the tree is for ALL
> systems?
> >
> > Yes we take the topology assumption in PCI hierarchy.
> > There is a case where both GFX and MEI are in PCH and you cannot stick
> additional PCI extender or anything else there.
> > And case where MEI is child on a standalone graphics card this is set
> > in software so topology is not going to change unless we rewrite
> everything. Be happy to hear your insights.
>
> This is ripe to break in the future if someone makes a differently structured
> device as there is nothing forcing the current layout to always be this way by
> hardware designers.
>
> The goal of the driver model is to NOT have these types of hard-coded
> topology assumptions because, supprise, assumptions like this have always
> come back to bite people in the end.
>
> This is your driver, so that's fine, but really this feels very very wrong
> and you
> will have a hard time guaranteeing that this will always be this way for the
> next 20+ years of hardware designs. So why not do it properly from the
> beginning and pass in the correct pointers to different places?
>
> There is a very good reason that the driver model/core does not make it easy
> to determine what type of device a 'struct device *' is, because you shouldn't
> have to rely on that type of thing ever. You are taking it one step further
> and
> just assuming that you know what the type is here, with no real way to
> ensure that this is the case.
>
> In short, this feels like a very bad design as it is very fragile.
I believe I understand your concern but I would need to invent another
addressing scheme to associate hw components that are already
addressable by let say PCI hierarchy. We've changed two subsystems for this
work
components and aux bus already. So let's have some fun in the future.
Thanks
Tomas
RE: [PATCH v4 06/15] mei: pxp: support matching with a gfx discrete card
> -Original Message-
> From: Greg Kroah-Hartman
> Sent: Friday, September 09, 2022 09:16
> To: Ceraolo Spurio, Daniele
> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> Winkler, Tomas ; Lubart, Vitaly
> ; Teres Alexis, Alan Previn
>
> Subject: Re: [PATCH v4 06/15] mei: pxp: support matching with a gfx discrete
> card
>
> On Thu, Sep 08, 2022 at 05:16:03PM -0700, Daniele Ceraolo Spurio wrote:
> > From: Tomas Winkler
> >
> > With on-boards graphics card, both i915 and MEI are in the same device
> > hierarchy with the same parent, while for discrete gfx card the MEI is
> > its child device.
> > Adjust the match function for that scenario by matching MEI parent
> > device with i915.
> >
> > V2:
> > 1. More detailed commit message
> > 2. Check for dev is not null before it is accessed.
> >
> > Signed-off-by: Tomas Winkler
> > Signed-off-by: Daniele Ceraolo Spurio
> >
> > Cc: Vitaly Lubart
> > Cc: Greg Kroah-Hartman
> > Reviewed-by: Alan Previn
> > ---
> > drivers/misc/mei/pxp/mei_pxp.c | 13 ++---
> > 1 file changed, 10 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/misc/mei/pxp/mei_pxp.c
> > b/drivers/misc/mei/pxp/mei_pxp.c index 17c5d201603f..afc047627800
> > 100644
> > --- a/drivers/misc/mei/pxp/mei_pxp.c
> > +++ b/drivers/misc/mei/pxp/mei_pxp.c
> > @@ -159,17 +159,24 @@ static int mei_pxp_component_match(struct
> device
> > *dev, int subcomponent, {
> > struct device *base = data;
> >
> > + if (!dev)
> > + return 0;
>
> How can that happen?
>
> > +
> > if (!dev->driver || strcmp(dev->driver->name, "i915") ||
>
> That's crazy to assume, but whatever :(
Explained here:
https://lore.kernel.org/all/20220418175932.1809770-2-wonch...@google.com/
>
> > subcomponent != I915_COMPONENT_PXP)
> > return 0;
> >
> > base = base->parent;
> > - if (!base)
> > + if (!base) /* mei device */
>
> Why does this mean that?
>
> Where is that documented?
>
> > return 0;
> >
> > - base = base->parent;
> > - dev = dev->parent;
> > + base = base->parent; /* pci device */
>
> Again, why is this the case?
>
> > + /* for dgfx */
> > + if (base && dev == base)
> > + return 1;
> >
> > + /* for pch */
> > + dev = dev->parent;
>
> You are digging through a random device tree and assuming that you "know"
> what the topology is going to be, that feels very very fragile and ripe for
> problems going forward.
I don't think it is random.
> How do you ensure that this really is they way the tree is for ALL systems?
Yes we take the topology assumption in PCI hierarchy.
There is a case where both GFX and MEI are in PCH and you cannot stick
additional PCI extender or anything else there.
And case where MEI is child on a standalone graphics card this is set in
software so topology is not going to change unless we rewrite
everything. Be happy to hear your insights.
Thanks
Tomas
RE: [PATCH v4 05/15] mei: pxp: add command streamer API to the PXP driver
>
> On Thu, Sep 08, 2022 at 05:16:02PM -0700, Daniele Ceraolo Spurio wrote:
> > +static ssize_t mei_pxp_gsc_command(struct device *dev, u8 client_id,
> u32 fence_id,
> > + struct scatterlist *sg_in, size_t
> > total_in_len,
> > + struct scatterlist *sg_out)
> > +{
> > + struct mei_cl_device *cldev;
> > +
> > + if (!dev || !sg_in || !sg_out)
> > + return -EINVAL;
>
> How can these ever be NULL? Doesn't the core control this, so why would
> that happen?
This is any interface function between modules, I think it is not healthy to
take assumptions here about how caller
behaves, this is not an inner functions. This is important even for catching
programmatical mistakes.
>
> Don't check for things that can never happen.
>
> > +
> > + cldev = to_mei_cl_device(dev);
> > +
> > + return mei_cldev_send_gsc_command(cldev, client_id, fence_id,
> sg_in,
> > +total_in_len, sg_out); }
> > +
> > static const struct i915_pxp_component_ops mei_pxp_ops = {
> > .owner = THIS_MODULE,
> > .send = mei_pxp_send_message,
> > .recv = mei_pxp_receive_message,
> > + .gsc_command = mei_pxp_gsc_command,
> > };
> >
> > static int mei_component_master_bind(struct device *dev) diff --git
> > a/include/drm/i915_pxp_tee_interface.h
> > b/include/drm/i915_pxp_tee_interface.h
> > index af593ec64469..a702b6ec17f7 100644
> > --- a/include/drm/i915_pxp_tee_interface.h
> > +++ b/include/drm/i915_pxp_tee_interface.h
> > @@ -8,6 +8,7 @@
> >
> > #include
> > #include
> > +struct scatterlist;
> >
> > /**
> > * struct i915_pxp_component_ops - ops for PXP services.
> > @@ -23,6 +24,10 @@ struct i915_pxp_component_ops {
> >
> > int (*send)(struct device *dev, const void *message, size_t size);
> > int (*recv)(struct device *dev, void *buffer, size_t size);
> > + ssize_t (*gsc_command)(struct device *dev, u8 client_id, u32
> fence_id,
> > + struct scatterlist *sg_in, size_t total_in_len,
> > + struct scatterlist *sg_out);
>
> No documentation for this new callback?
>
> The build should give you are warning :(
Will fix.
Thanks
Tomas
RE: [PATCH v4 01/15] mei: add support to GSC extended header
> On Thu, Sep 08, 2022 at 05:15:58PM -0700, Daniele Ceraolo Spurio wrote:
> > From: Tomas Winkler
> >
> > GSC extend header is of variable size and data is provided in a sgl
> > list inside the header and not in the data buffers, need to enable the
> > path.
> >
> > V2:
> > 1. Add missing kdoc for mei_cl_cb
> > 2. In mei_me_hbuf_write()
> >use dev_err() when validationg parameters instead of WARN_ON()
>
> This stuff goes below the --- line, as the documentation states, right?
> Why is it here?
Right, miscommunication between me and Daniele, the issue is that
What is under line goes away when patch is applied, so it was temporary
In the body, it should go under line when posted public.
Will fix.
Thanks
Tomas
>
> >
> > Signed-off-by: Tomas Winkler
> > Signed-off-by: Daniele Ceraolo Spurio
> >
> > Cc: Vitaly Lubart
> > Cc: Greg Kroah-Hartman
> > ---
> > drivers/misc/mei/client.c| 55 --
> > drivers/misc/mei/hbm.c | 13
> > drivers/misc/mei/hw-me.c | 7 -
> > drivers/misc/mei/hw.h| 57
>
> > drivers/misc/mei/interrupt.c | 47 -
> > drivers/misc/mei/mei_dev.h | 4 +++
> > 6 files changed, 160 insertions(+), 23 deletions(-)
> >
> > diff --git a/drivers/misc/mei/client.c b/drivers/misc/mei/client.c
> > index 0b2fbe1335a7..6c8b71ae32c8 100644
> > --- a/drivers/misc/mei/client.c
> > +++ b/drivers/misc/mei/client.c
> > @@ -322,6 +322,7 @@ void mei_io_cb_free(struct mei_cl_cb *cb)
> >
> > list_del(>list);
> > kfree(cb->buf.data);
> > + kfree(cb->ext_hdr);
> > kfree(cb);
> > }
> >
> > @@ -401,6 +402,7 @@ static struct mei_cl_cb *mei_io_cb_init(struct
> mei_cl *cl,
> > cb->buf_idx = 0;
> > cb->fop_type = type;
> > cb->vtag = 0;
> > + cb->ext_hdr = NULL;
> >
> > return cb;
> > }
> > @@ -1740,6 +1742,17 @@ static inline u8 mei_ext_hdr_set_vtag(void *ext,
> u8 vtag)
> > return vtag_hdr->hdr.length;
> > }
> >
> > +static inline bool mei_ext_hdr_is_gsc(struct mei_ext_hdr *ext) {
> > + return ext && ext->type == MEI_EXT_HDR_GSC; }
> > +
> > +static inline u8 mei_ext_hdr_set_gsc(struct mei_ext_hdr *ext, struct
> > +mei_ext_hdr *gsc_hdr) {
> > + memcpy(ext, gsc_hdr, mei_ext_hdr_len(gsc_hdr));
> > + return ext->length;
> > +}
> > +
> > /**
> > * mei_msg_hdr_init - allocate and initialize mei message header
> > *
> > @@ -1752,14 +1765,17 @@ static struct mei_msg_hdr
> *mei_msg_hdr_init(const struct mei_cl_cb *cb)
> > size_t hdr_len;
> > struct mei_ext_meta_hdr *meta;
> > struct mei_msg_hdr *mei_hdr;
> > - bool is_ext, is_vtag;
> > + bool is_ext, is_hbm, is_gsc, is_vtag;
> > + struct mei_ext_hdr *next_ext;
> >
> > if (!cb)
> > return ERR_PTR(-EINVAL);
> >
> > /* Extended header for vtag is attached only on the first fragment */
> > is_vtag = (cb->vtag && cb->buf_idx == 0);
> > - is_ext = is_vtag;
> > + is_hbm = cb->cl->me_cl->client_id == 0;
> > + is_gsc = ((!is_hbm) && cb->cl->dev->hbm_f_gsc_supported &&
> mei_ext_hdr_is_gsc(cb->ext_hdr));
> > + is_ext = is_vtag || is_gsc;
> >
> > /* Compute extended header size */
> > hdr_len = sizeof(*mei_hdr);
> > @@ -1771,6 +1787,9 @@ static struct mei_msg_hdr
> *mei_msg_hdr_init(const struct mei_cl_cb *cb)
> > if (is_vtag)
> > hdr_len += sizeof(struct mei_ext_hdr_vtag);
> >
> > + if (is_gsc)
> > + hdr_len += mei_ext_hdr_len(cb->ext_hdr);
> > +
> > setup_hdr:
> > mei_hdr = kzalloc(hdr_len, GFP_KERNEL);
> > if (!mei_hdr)
> > @@ -1785,10 +1804,20 @@ static struct mei_msg_hdr
> *mei_msg_hdr_init(const struct mei_cl_cb *cb)
> > goto out;
> >
> > meta = (struct mei_ext_meta_hdr *)mei_hdr->extension;
> > + meta->size = 0;
> > + next_ext = (struct mei_ext_hdr *)meta->hdrs;
> > if (is_vtag) {
> > meta->count++;
> > - meta->size += mei_ext_hdr_set_vtag(meta->hdrs, cb-
> >vtag);
> > + meta->size += mei_ext_hdr_set_vtag(next_ext, cb->vtag);
> > + next_ext = mei_ext_next(next_ext);
> > + }
> > +
> > + if (is_gsc) {
> > + meta->count++;
> > + meta->size += mei_ext_hdr_set_gsc(next_ext, cb-
> >ext_hdr);
> > + next_ext = mei_ext_next(next_ext);
> > }
> > +
> > out:
> > mei_hdr->length = hdr_len - sizeof(*mei_hdr);
> > return mei_hdr;
> > @@ -1812,14 +1841,14 @@ int mei_cl_irq_write(struct mei_cl *cl, struct
> mei_cl_cb *cb,
> > struct mei_msg_hdr *mei_hdr = NULL;
> > size_t hdr_len;
> > size_t hbuf_len, dr_len;
> > - size_t buf_len;
> > + size_t buf_len = 0;
> > size_t data_len;
> > int hbuf_slots;
> > u32 dr_slots;
> > u32 dma_len;
> > int rets;
> > bool first_chunk;
> > - const void *data;
> > + const void *data = NULL;
> >
> > if (WARN_ON(!cl || !cl->dev))
> > return -ENODEV;
> > @@ -1839,8 +1868,10 @@ int mei_cl_irq_write(struct mei_cl
RE: [PATCH v3 02/15] mei: add support to GSC extended header
> > > > > > On Fri, Aug 19, 2022 at 03:53:22PM -0700, Daniele Ceraolo Spurio wrote: > > > > --- a/drivers/misc/mei/hw-me.c > > > > +++ b/drivers/misc/mei/hw-me.c > > > > @@ -590,7 +590,10 @@ static int mei_me_hbuf_write(struct > > > > mei_device > > > *dev, > > > > u32 dw_cnt; > > > > int empty_slots; > > > > > > > > - if (WARN_ON(!hdr || !data || hdr_len & 0x3)) > > > > + if (WARN_ON(!hdr || hdr_len & 0x3)) > > > > + return -EINVAL; > > > > + > > > > + if (WARN_ON(!data && data_len)) > > > > > > Do not add more WARN_ON() calls, please just handle this properly > > > and do not reboot people's machines for a coding error :( > > > > As far as I understand WARN_ON() will produce solely a backtrace , > > Except when you have panic_on_warn() enabled in your systems, as many > do :( Was not aware, thanks for bringing to my attention. > > This particular condition should never ever happen in theory, > > Then don't check it! In theory :) > > anyhow we can use dev_err() here as well. > > That would be best. That how it was resolved in the V4 series that Daniele has sent, will be glad if you can review. Thanks Tomas
RE: [PATCH v4 00/15] drm/i915: HuC loading for DG2
> On DG2, HuC loading is performed by the GSC, via a PXP command. The load > operation itself is relatively simple (just send a message to the GSC with the > physical address of the HuC in LMEM), but there are timing changes that > requires special attention. In particular, to send a PXP command we need to > first export the GSC as an aux device and then wait for the mei-gsc and mei- > pxp modules to start, which means that HuC load will complete after i915 > load is complete. This means that there is a small window of time after i915 > is > registered and before HuC is loaded during which userspace could submit > and/or check the HuC load status, although this is quite unlikely to happen > (HuC is usually loaded before kernel init/resume completes). > We've consulted with the media team in regards to how to handle this and > they've asked us to stall all userspace VCS submission until HuC is loaded. > Stalls are expected to be very rare (if any), due to the fact that HuC is > usually > loaded before kernel init/resume is completed. > > Timeouts are in place to ensure all submissions are unlocked in case > something goes wrong. Since we need to monitor the status of the mei > driver to know what's happening and when to time out, a notifier has been > added so we get a callback when the status of the mei driver changes. > > Note that this series includes several mei patches that add support for > sending the HuC loading command via mei-gsc. We plan to merge those > patches through the drm tree because i915 is the sole user. > > v2: address review comments, Reporting HuC loading still in progress while > we wait for mei-gsc init to complete, rebase on latest mei-gsc series. > > v3: fix cc list in mei patches. > > v4: update mei patches, fix includes, rebase on new FW fetch logic and > merged mei-gsc support. > > Test-with: 20220818224216.3920822-1-daniele.ceraolospu...@intel.com > Cc: Alan Previn > Cc: Tony Ye > Cc: Alexander Usyskin > Cc: Tomas Winkler > Cc: Greg Kroah-Hartman > > Daniele Ceraolo Spurio (7): > drm/i915/pxp: load the pxp module when we have a gsc-loaded huc > drm/i915/dg2: setup HuC loading via GSC > drm/i915/huc: track delayed HuC load with a fence > drm/i915/huc: stall media submission until HuC is loaded > drm/i915/huc: better define HuC status getparam possible return > values. > drm/i915/huc: define gsc-compatible HuC fw for DG2 > HAX: drm/i915: force INTEL_MEI_GSC and INTEL_MEI_PXP on for CI > > Tomas Winkler (5): > mei: add support to GSC extended header > mei: bus: enable sending gsc commands > mei: adjust extended header kdocs > mei: pxp: support matching with a gfx discrete card > drm/i915/pxp: add huc authentication and loading command > > Vitaly Lubart (3): > mei: bus: extend bus API to support command streamer API > mei: pxp: add command streamer API to the PXP driver > drm/i915/pxp: implement function for sending tee stream command > > drivers/gpu/drm/i915/Kconfig.debug| 2 + > drivers/gpu/drm/i915/Makefile | 11 +- > drivers/gpu/drm/i915/gt/intel_gsc.c | 22 +- > drivers/gpu/drm/i915/gt/uc/intel_guc.c| 1 + > drivers/gpu/drm/i915/gt/uc/intel_huc.c| 254 -- > drivers/gpu/drm/i915/gt/uc/intel_huc.h| 31 +++ > drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 34 +++ > drivers/gpu/drm/i915/gt/uc/intel_huc_fw.h | 1 + > drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 24 +- > drivers/gpu/drm/i915/i915_request.c | 24 ++ > drivers/gpu/drm/i915/pxp/intel_pxp.c | 32 ++- > drivers/gpu/drm/i915/pxp/intel_pxp.h | 32 --- > drivers/gpu/drm/i915/pxp/intel_pxp_huc.c | 69 + > drivers/gpu/drm/i915/pxp/intel_pxp_huc.h | 13 + > drivers/gpu/drm/i915/pxp/intel_pxp_irq.h | 8 + > drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 8 +- > drivers/gpu/drm/i915/pxp/intel_pxp_session.h | 11 +- > drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 138 +- > drivers/gpu/drm/i915/pxp/intel_pxp_tee.h | 5 + > .../drm/i915/pxp/intel_pxp_tee_interface.h| 23 +- > drivers/gpu/drm/i915/pxp/intel_pxp_types.h| 6 + > drivers/misc/mei/bus.c| 145 +- > drivers/misc/mei/client.c | 55 ++-- > drivers/misc/mei/hbm.c| 13 + > drivers/misc/mei/hw-me.c | 7 +- > drivers/misc/mei/hw.h | 65 - > drivers/misc/mei/interrupt.c | 47 +++- > drivers/misc/mei/mei_dev.h| 8 + > drivers/misc/mei/pxp/mei_pxp.c| 41 ++- > include/drm/i915_pxp_tee_interface.h | 5 + > include/linux/mei_cl_bus.h| 6 + > include/uapi/drm/i915_drm.h | 16 ++ > 32 files changed, 1035 insertions(+), 122 deletions(-) create mode 100644 > drivers/gpu/drm/i915/pxp/intel_pxp_huc.c > create mode
RE: [PATCH v3 02/15] mei: add support to GSC extended header
> > On Fri, Aug 19, 2022 at 03:53:22PM -0700, Daniele Ceraolo Spurio wrote: > > --- a/drivers/misc/mei/hw-me.c > > +++ b/drivers/misc/mei/hw-me.c > > @@ -590,7 +590,10 @@ static int mei_me_hbuf_write(struct mei_device > *dev, > > u32 dw_cnt; > > int empty_slots; > > > > - if (WARN_ON(!hdr || !data || hdr_len & 0x3)) > > + if (WARN_ON(!hdr || hdr_len & 0x3)) > > + return -EINVAL; > > + > > + if (WARN_ON(!data && data_len)) > > Do not add more WARN_ON() calls, please just handle this properly and do > not reboot people's machines for a coding error :( As far as I understand WARN_ON() will produce solely a backtrace , This particular condition should never ever happen in theory, anyhow we can use dev_err() here as well. Thanks Tomas
RE: [PATCH v5 02/15] mei: pxp: export pavp client to me client bus
> From: Vitaly Lubart
>
> Export PAVP client to work with i915 driver, for binding it uses kernel
> component framework.
>
> Signed-off-by: Vitaly Lubart
> Signed-off-by: Tomas Winkler
> Signed-off-by: Daniele Ceraolo Spurio
> Reviewed-by: Rodrigo Vivi
> ---
> drivers/misc/mei/Kconfig | 2 +
> drivers/misc/mei/Makefile | 1 +
> drivers/misc/mei/pxp/Kconfig | 13 ++
> drivers/misc/mei/pxp/Makefile | 7 +
> drivers/misc/mei/pxp/mei_pxp.c | 233
> +
> drivers/misc/mei/pxp/mei_pxp.h | 18 +++
> 6 files changed, 274 insertions(+)
> create mode 100644 drivers/misc/mei/pxp/Kconfig create mode 100644
> drivers/misc/mei/pxp/Makefile create mode 100644
> drivers/misc/mei/pxp/mei_pxp.c create mode 100644
> drivers/misc/mei/pxp/mei_pxp.h
>
> diff --git a/drivers/misc/mei/Kconfig b/drivers/misc/mei/Kconfig index
> f5fd5b786607..0e0bcd0da852 100644
> --- a/drivers/misc/mei/Kconfig
> +++ b/drivers/misc/mei/Kconfig
> @@ -47,3 +47,5 @@ config INTEL_MEI_TXE
> Intel Bay Trail
>
> source "drivers/misc/mei/hdcp/Kconfig"
> +source "drivers/misc/mei/pxp/Kconfig"
> +
> diff --git a/drivers/misc/mei/Makefile b/drivers/misc/mei/Makefile index
> f1c76f7ee804..d8e5165917f2 100644
> --- a/drivers/misc/mei/Makefile
> +++ b/drivers/misc/mei/Makefile
> @@ -26,3 +26,4 @@ mei-$(CONFIG_EVENT_TRACING) += mei-trace.o
> CFLAGS_mei-trace.o = -I$(src)
>
> obj-$(CONFIG_INTEL_MEI_HDCP) += hdcp/
> +obj-$(CONFIG_INTEL_MEI_PXP) += pxp/
> diff --git a/drivers/misc/mei/pxp/Kconfig b/drivers/misc/mei/pxp/Kconfig
> new file mode 100644 index ..4029b96afc04
> --- /dev/null
> +++ b/drivers/misc/mei/pxp/Kconfig
> @@ -0,0 +1,13 @@
> +
> +# SPDX-License-Identifier: GPL-2.0
> +# Copyright (c) 2020, Intel Corporation. All rights reserved.
2020-2021
> +#
> +config INTEL_MEI_PXP
> + tristate "Intel PXP services of ME Interface"
> + select INTEL_MEI_ME
> + depends on DRM_I915
> + help
> + MEI Support for PXP Services on Intel platforms.
> +
> + Enables the ME FW services required for PXP support through
> + I915 display driver of Intel.
> diff --git a/drivers/misc/mei/pxp/Makefile b/drivers/misc/mei/pxp/Makefile
> new file mode 100644 index ..0329950d5794
> --- /dev/null
> +++ b/drivers/misc/mei/pxp/Makefile
> @@ -0,0 +1,7 @@
> +# SPDX-License-Identifier: GPL-2.0
> +#
> +# Copyright (c) 2020, Intel Corporation. All rights reserved.
> +#
> +# Makefile - PXP client driver for Intel MEI Bus Driver.
> +
> +obj-$(CONFIG_INTEL_MEI_PXP) += mei_pxp.o
> diff --git a/drivers/misc/mei/pxp/mei_pxp.c
> b/drivers/misc/mei/pxp/mei_pxp.c new file mode 100644 index
> ..cacfbedb640a
> --- /dev/null
> +++ b/drivers/misc/mei/pxp/mei_pxp.c
> @@ -0,0 +1,233 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright © 2020 Intel Corporation
> + */
> +
> +/**
> + * DOC: MEI_PXP Client Driver
> + *
> + * The mei_pxp driver acts as a translation layer between PXP
> + * protocol implementer (I915) and ME FW by translating PXP
> + * negotiation messages to ME FW command payloads and vice versa.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "mei_pxp.h"
> +
> +/**
> + * mei_pxp_send_message() - Sends a PXP message to ME FW.
> + * @dev: device corresponding to the mei_cl_device
> + * @message: a message buffer to send
> + * @size: size of the message
> + * Return: 0 on Success, <0 on Failure
> + */
> +static int
> +mei_pxp_send_message(struct device *dev, const void *message, size_t
> +size) {
> + struct mei_cl_device *cldev;
> + ssize_t byte;
> +
> + if (!dev || !message)
> + return -EINVAL;
> +
> + cldev = to_mei_cl_device(dev);
> +
> + /* temporary drop const qualifier till the API is fixed */
> + byte = mei_cldev_send(cldev, (u8 *)message, size);
> + if (byte < 0) {
> + dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
> + return byte;
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * mei_pxp_receive_message() - Receives a PXP message from ME FW.
> + * @dev: device corresponding to the mei_cl_device
> + * @buffer: a message buffer to contain the received message
> + * @size: size of the buffer
> + * Return: bytes sent on Success, <0 on Failure */ static int
> +mei_pxp_receive_message(struct device *dev, void *buffer, size_t size)
> +{
> + struct mei_cl_device *cldev;
> + ssize_t byte;
> +
> + if (!dev || !buffer)
> + return -EINVAL;
> +
> + cldev = to_mei_cl_device(dev);
> +
> + byte = mei_cldev_recv(cldev, buffer, size);
> + if (byte < 0) {
> + dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
> + return byte;
> + }
> +
> + return byte;
> +}
> +
> +static const struct i915_pxp_component_ops mei_pxp_ops = {
> + .owner = THIS_MODULE,
> + .send = mei_pxp_send_message,
> + .recv =
RE: [PATCH v3 10/16] misc/mei/hdcp: Fix AUTH_STREAM_REQ cmd buffer len
> > > > > -Original Message- > > From: Anshuman Gupta > > Sent: Friday, October 23, 2020 5:51 PM > > To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org > > Cc: seanp...@chromium.org; Nikula, Jani ; C, > > Ramalingam ; Li, Juston ; > > Shankar, Uma ; Gupta, Anshuman > > ; Winkler, Tomas > > Subject: [PATCH v3 10/16] misc/mei/hdcp: Fix AUTH_STREAM_REQ cmd > > buffer len > > > > Fix the size of WIRED_REPEATER_AUTH_STREAM_REQ cmd buffer size. > > It is based upon the actual number of MST streams and size of > > wired_cmd_repeater_auth_stream_req_in. > > Excluding the size of hdcp_cmd_header. > > > > v2: > > hdcp_cmd_header size annotation nitpick. [Tomas] > > Looks Good to me. > Reviewed-by: Uma Shankar Acked-by: Tomas Winkler > > > Cc: Tomas Winkler > > Cc: Ramalingam C > > Acked-by: Tomas Winkler > > Signed-off-by: Anshuman Gupta > > --- > > drivers/misc/mei/hdcp/mei_hdcp.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c > > b/drivers/misc/mei/hdcp/mei_hdcp.c > > index 9ae9669e46ea..3506a3534294 100644 > > --- a/drivers/misc/mei/hdcp/mei_hdcp.c > > +++ b/drivers/misc/mei/hdcp/mei_hdcp.c > > @@ -569,8 +569,7 @@ static int mei_hdcp_verify_mprime(struct 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->header.buffer_len = cmd_size - > > +sizeof(verify_mprime_in->header); > > > > verify_mprime_in->port.integrated_port_type = data->port_type; > > verify_mprime_in->port.physical_port = (u8)data->fw_ddi; > > -- > > 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v2 09/15] misc/mei/hdcp: Fix AUTH_STREAM_REQ cmd buffer len
> > On Tue, 20 Oct 2020, Anshuman Gupta wrote: > > Fix the size of WIRED_REPEATER_AUTH_STREAM_REQ cmd buffer size. > > It is based upon the actual number of MST streams and size of > > wired_cmd_repeater_auth_stream_req_in. > > Excluding the size of hdcp_cmd_header. > > > > Cc: Tomas Winkler > > Cc: Ramalingam C > > Signed-off-by: Anshuman Gupta > > Tomas, ack to merge this via drm-intel? I have no problem with merging it via drm-intel, just see a little nitpick bellow: > Thanks, > Jani. > > > --- > > drivers/misc/mei/hdcp/mei_hdcp.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c > > b/drivers/misc/mei/hdcp/mei_hdcp.c > > index 9ae9669e46ea..b10d266fb60a 100644 > > --- a/drivers/misc/mei/hdcp/mei_hdcp.c > > +++ b// > > @@ -569,8 +569,7 @@ static int mei_hdcp_verify_mprime(struct 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->header.buffer_len = cmd_size - sizeof(struct > > +hdcp_cmd_header); I believe the following annotation would be preferable: cmd_size - sizeof(verify_mprime_in->header) > > > > verify_mprime_in->port.integrated_port_type = data->port_type; > > verify_mprime_in->port.physical_port = (u8)data->fw_ddi; > > -- > Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v12 0/6] drm/i915: Enable HDCP 1.4 and 2.2 on Gen12+
> On 2019-08-28 at 22:12:10 +0530, Ramalingam C wrote: > > Enabling the HDCP1.4 and 2.2 on TGL by supporting the HW block > > movement from DDI into transcoder. > > > > v12: > > r-b and ack are collected. > > few review comments are addressed. > > Tomas, > > Thanks for reviewing the patches and providing the Ack/R-bes. > As we discussed offline, we need your ACK for submitting mei_hdcp patches > through dinq(drm-intel-next-queued). Please provide the same. ACK > > -Ram > > > > Ramalingam C (6): > > drm/i915: mei_hdcp: I915 sends ddi index as per ME FW > > drm: Move port definition back to i915 header > > drm: Extend I915 mei interface for transcoder info > > misc/mei/hdcp: Fill transcoder index in port info > > drm/i915/hdcp: update current transcoder into intel_hdcp > > drm/i915/hdcp: Enable HDCP 1.4 and 2.2 on Gen12+ > > > > drivers/gpu/drm/i915/display/intel_bios.h | 3 +- > > drivers/gpu/drm/i915/display/intel_display.h | 20 +- > > .../drm/i915/display/intel_display_types.h| 7 + > > drivers/gpu/drm/i915/display/intel_dp.c | 3 + > > drivers/gpu/drm/i915/display/intel_dp.h | 1 + > > drivers/gpu/drm/i915/display/intel_hdcp.c | 214 +- > > drivers/gpu/drm/i915/display/intel_hdcp.h | 4 + > > drivers/gpu/drm/i915/display/intel_hdmi.c | 13 +- > > drivers/gpu/drm/i915/display/intel_hdmi.h | 1 + > > drivers/gpu/drm/i915/display/intel_hotplug.h | 1 + > > drivers/gpu/drm/i915/display/intel_sdvo.h | 1 + > > drivers/gpu/drm/i915/i915_reg.h | 124 +- > > drivers/misc/mei/hdcp/mei_hdcp.c | 45 ++-- > > drivers/misc/mei/hdcp/mei_hdcp.h | 17 +- > > include/drm/i915_drm.h| 18 -- > > include/drm/i915_mei_hdcp_interface.h | 42 +++- > > 16 files changed, 389 insertions(+), 125 deletions(-) > > > > -- > > 2.20.1 > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v12 6/6] drm/i915/hdcp: Enable HDCP 1.4 and 2.2 on Gen12+
Now I'm reading this other patch about DG1 ' drm/i915/dg1: Initialize DDI ports
for DG1' , is this condition still correct here?
Is the condition 'INTEL_GEN(dev_priv) >= 12' sufficient ?
>
> >From Gen12 onwards, HDCP HW block is implemented within transcoders.
> Till Gen11 HDCP HW block was part of DDI.
>
> Hence required changes in HW programming is handled here.
>
> As ME FW needs the transcoder detail on which HDCP is enabled on Gen12+
> platform, we are populating the detail in hdcp_port_data.
>
> v2:
> _MMIO_TRANS is used [Lucas and Daniel]
> platform check is moved into the caller [Lucas]
> v3:
> platform check is moved into a macro [Shashank]
> v4:
> Few optimizations in the coding [Shashank]
> v5:
> Fixed alignment in macro definition in i915_reg.h [Shashank]
> unused variables "reg" is removed.
> v6:
> Configuring the transcoder at compute_config.
> transcoder is used instead of pipe in macros.
> Rebased.
> v7:
> transcoder is cached at intel_hdcp
> hdcp_port_data is configured with transcoder index asper ME FW.
> v8:
> s/trans/cpu_transcoder
> s/tc/cpu_transcoder
> v9:
> rep_ctl is prepared for TCD too.
> return moved into deault of rep_ctl prepare function [Shashank]
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Shashank Sharma
> Acked-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_hdcp.c | 152 ++
> drivers/gpu/drm/i915/display/intel_hdmi.c | 10 +-
> drivers/gpu/drm/i915/i915_reg.h | 124 --
> 3 files changed, 221 insertions(+), 65 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index edcec64a2c11..e69fa34528df 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -20,6 +20,7 @@
> #include "intel_display_types.h"
> #include "intel_hdcp.h"
> #include "intel_sideband.h"
> +#include "intel_connector.h"
>
> #define KEY_LOAD_TRIES 5
> #define ENCRYPT_STATUS_CHANGE_TIMEOUT_MS 50
> @@ -107,24 +108,20 @@ bool intel_hdcp2_capable(struct intel_connector
> *connector)
> return capable;
> }
>
> -static inline bool intel_hdcp_in_use(struct intel_connector *connector)
> +static inline
> +bool intel_hdcp_in_use(struct drm_i915_private *dev_priv,
> +enum transcoder cpu_transcoder, enum port port)
> {
> - 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;
> + return I915_READ(HDCP_STATUS(dev_priv, cpu_transcoder, port)) &
> +HDCP_STATUS_ENC;
> }
>
> -static inline bool intel_hdcp2_in_use(struct intel_connector *connector)
> +static inline
> +bool intel_hdcp2_in_use(struct drm_i915_private *dev_priv,
> + enum transcoder cpu_transcoder, enum port port)
> {
> - 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;
> + return I915_READ(HDCP2_STATUS(dev_priv, cpu_transcoder, port)) &
> +LINK_ENCRYPTION_STATUS;
> }
>
> static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port
> *intel_dig_port,
> @@ -255,9 +252,29 @@ static int intel_write_sha_text(struct
> drm_i915_private *dev_priv, u32 sha_text) }
>
> static
> -u32 intel_hdcp_get_repeater_ctl(struct intel_digital_port *intel_dig_port)
> +u32 intel_hdcp_get_repeater_ctl(struct drm_i915_private *dev_priv,
> + enum transcoder cpu_transcoder, enum port
> port)
> {
> - enum port port = intel_dig_port->base.port;
> + if (INTEL_GEN(dev_priv) >= 12) {
> + switch (cpu_transcoder) {
> + case TRANSCODER_A:
> + return HDCP_TRANSA_REP_PRESENT |
> +HDCP_TRANSA_SHA1_M0;
> + case TRANSCODER_B:
> + return HDCP_TRANSB_REP_PRESENT |
> +HDCP_TRANSB_SHA1_M0;
> + case TRANSCODER_C:
> + return HDCP_TRANSC_REP_PRESENT |
> +HDCP_TRANSC_SHA1_M0;
> + case TRANSCODER_D:
> + return HDCP_TRANSD_REP_PRESENT |
> +HDCP_TRANSD_SHA1_M0;
> + default:
> + DRM_ERROR("Unknown transcoder %d\n",
> cpu_transcoder);
> + return -EINVAL;
> + }
> + }
> +
> switch (port) {
> case PORT_A:
> return HDCP_DDIA_REP_PRESENT | HDCP_DDIA_SHA1_M0;
> @@ -270,18 +287,20 @@ u32 intel_hdcp_get_repeater_ctl(struct
> intel_digital_port *intel_dig_port)
> case PORT_E:
> return HDCP_DDIE_REP_PRESENT | HDCP_DDIE_SHA1_M0;
> default:
> -
RE: [PATCH v11 1/6] drm/i915: mei_hdcp: I915 sends ddi index as per ME FW
> I915 converts it's port value into ddi index defiend by ME FW and pass it as a
> member of hdcp_port_data structure.
>
> Hence expose the enum mei_fw_ddi to I915 through i915_mei_interface.h.
>
> v2:
> Copyright years are bumped [Tomas]
>
> Signed-off-by: Ramalingam C
> Acked-by: Jani Nikula
> Reviewed-by: Shashank Sharma
Ack
> ---
> drivers/gpu/drm/i915/display/intel_hdcp.c | 17 +++-
> drivers/misc/mei/hdcp/mei_hdcp.c | 34 ---
> drivers/misc/mei/hdcp/mei_hdcp.h | 12
> include/drm/i915_mei_hdcp_interface.h | 18 ++--
> 4 files changed, 42 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index 6ec5ceeab601..e8b04cc8fcb1 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -1,9 +1,11 @@
> /* SPDX-License-Identifier: MIT */
> /*
> * Copyright (C) 2017 Google, Inc.
> + * Copyright _ 2017-2019, Intel Corporation.
> *
> * Authors:
> * Sean Paul
> + * Ramalingam C
> */
>
> #include
> @@ -1749,13 +1751,26 @@ static const struct component_ops
> i915_hdcp_component_ops = {
> .unbind = i915_hdcp_component_unbind,
> };
>
> +static inline
> +enum mei_fw_ddi intel_get_mei_fw_ddi_index(enum port port) {
> + switch (port) {
> + case PORT_A:
> + return MEI_DDI_A;
> + case PORT_B ... PORT_F:
> + return (enum mei_fw_ddi)port;
> + default:
> + return MEI_DDI_INVALID_PORT;
> + }
> +}
> +
> static inline int initialize_hdcp_port_data(struct intel_connector
> *connector,
> const struct intel_hdcp_shim *shim)
> {
> struct intel_hdcp *hdcp = >hdcp;
> struct hdcp_port_data *data = >port_data;
>
> - data->port = connector->encoder->port;
> + data->fw_ddi = intel_get_mei_fw_ddi_index(connector->encoder-
> >port);
> data->port_type = (u8)HDCP_PORT_TYPE_INTEGRATED;
> data->protocol = (u8)shim->protocol;
>
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index c681f6fab342..3638c77eba26 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -27,18 +27,6 @@
>
> #include "mei_hdcp.h"
>
> -static inline u8 mei_get_ddi_index(enum port port) -{
> - switch (port) {
> - case PORT_A:
> - return MEI_DDI_A;
> - case PORT_B ... PORT_F:
> - return (u8)port;
> - default:
> - return MEI_DDI_INVALID_PORT;
> - }
> -}
> -
> /**
> * mei_hdcp_initiate_session() - Initiate a Wired HDCP2.2 Tx Session in ME FW
> * @dev: device corresponding to the mei_cl_device @@ -69,7 +57,7 @@
> mei_hdcp_initiate_session(struct device *dev, struct hdcp_port_data *data,
>
> WIRED_CMD_BUF_LEN_INITIATE_HDCP2_SESSION_IN;
>
> session_init_in.port.integrated_port_type = data->port_type;
> - session_init_in.port.physical_port = mei_get_ddi_index(data->port);
> + session_init_in.port.physical_port = (u8)data->fw_ddi;
> session_init_in.protocol = data->protocol;
>
> byte = mei_cldev_send(cldev, (u8 *)_init_in, @@ -138,7
> +126,7 @@ mei_hdcp_verify_receiver_cert_prepare_km(struct device *dev,
>
> WIRED_CMD_BUF_LEN_VERIFY_RECEIVER_CERT_IN;
>
> verify_rxcert_in.port.integrated_port_type = data->port_type;
> - verify_rxcert_in.port.physical_port = mei_get_ddi_index(data->port);
> + verify_rxcert_in.port.physical_port = (u8)data->fw_ddi;
>
> verify_rxcert_in.cert_rx = rx_cert->cert_rx;
> memcpy(verify_rxcert_in.r_rx, _cert->r_rx, HDCP_2_2_RRX_LEN);
> @@ -208,7 +196,7 @@ mei_hdcp_verify_hprime(struct device *dev, struct
> hdcp_port_data *data,
> 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 = mei_get_ddi_index(data->port);
> + send_hprime_in.port.physical_port = (u8)data->fw_ddi;
>
> memcpy(send_hprime_in.h_prime, rx_hprime->h_prime,
> HDCP_2_2_H_PRIME_LEN);
> @@ -265,7 +253,7 @@ mei_hdcp_store_pairing_info(struct device *dev, struct
> hdcp_port_data *data,
>
> WIRED_CMD_BUF_LEN_SEND_PAIRING_INFO_IN;
>
> pairing_info_in.port.integrated_port_type = data->port_type;
> - pairing_info_in.port.physical_port = mei_get_ddi_index(data->port);
> + pairing_info_in.port.physical_port = (u8)data->fw_ddi;
>
> memcpy(pairing_info_in.e_kh_km, pairing_info->e_kh_km,
> HDCP_2_2_E_KH_KM_LEN);
> @@ -323,7 +311,7 @@ mei_hdcp_initiate_locality_check(struct device *dev,
> 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 = mei_get_ddi_index(data->port);
> +
RE: [PATCH v11 1/6] drm/i915: mei_hdcp: I915 sends ddi index as per ME FW
> I915 converts it's port value into ddi index defiend by ME FW and pass it as a
> member of hdcp_port_data structure.
>
> Hence expose the enum mei_fw_ddi to I915 through i915_mei_interface.h.
>
> v2:
> Copyright years are bumped [Tomas]
>
> Signed-off-by: Ramalingam C
> Acked-by: Jani Nikula
> Reviewed-by: Shashank Sharma
ACK.
> ---
> drivers/gpu/drm/i915/display/intel_hdcp.c | 17 +++-
> drivers/misc/mei/hdcp/mei_hdcp.c | 34 ---
> drivers/misc/mei/hdcp/mei_hdcp.h | 12
> include/drm/i915_mei_hdcp_interface.h | 18 ++--
> 4 files changed, 42 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index 6ec5ceeab601..e8b04cc8fcb1 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -1,9 +1,11 @@
> /* SPDX-License-Identifier: MIT */
> /*
> * Copyright (C) 2017 Google, Inc.
> + * Copyright _ 2017-2019, Intel Corporation.
> *
> * Authors:
> * Sean Paul
> + * Ramalingam C
> */
>
> #include
> @@ -1749,13 +1751,26 @@ static const struct component_ops
> i915_hdcp_component_ops = {
> .unbind = i915_hdcp_component_unbind,
> };
>
> +static inline
> +enum mei_fw_ddi intel_get_mei_fw_ddi_index(enum port port) {
> + switch (port) {
> + case PORT_A:
> + return MEI_DDI_A;
> + case PORT_B ... PORT_F:
> + return (enum mei_fw_ddi)port;
> + default:
> + return MEI_DDI_INVALID_PORT;
> + }
> +}
> +
> static inline int initialize_hdcp_port_data(struct intel_connector
> *connector,
> const struct intel_hdcp_shim *shim)
> {
> struct intel_hdcp *hdcp = >hdcp;
> struct hdcp_port_data *data = >port_data;
>
> - data->port = connector->encoder->port;
> + data->fw_ddi = intel_get_mei_fw_ddi_index(connector->encoder-
> >port);
> data->port_type = (u8)HDCP_PORT_TYPE_INTEGRATED;
> data->protocol = (u8)shim->protocol;
>
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index c681f6fab342..3638c77eba26 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -27,18 +27,6 @@
>
> #include "mei_hdcp.h"
>
> -static inline u8 mei_get_ddi_index(enum port port) -{
> - switch (port) {
> - case PORT_A:
> - return MEI_DDI_A;
> - case PORT_B ... PORT_F:
> - return (u8)port;
> - default:
> - return MEI_DDI_INVALID_PORT;
> - }
> -}
> -
> /**
> * mei_hdcp_initiate_session() - Initiate a Wired HDCP2.2 Tx Session in ME FW
> * @dev: device corresponding to the mei_cl_device @@ -69,7 +57,7 @@
> mei_hdcp_initiate_session(struct device *dev, struct hdcp_port_data *data,
>
> WIRED_CMD_BUF_LEN_INITIATE_HDCP2_SESSION_IN;
>
> session_init_in.port.integrated_port_type = data->port_type;
> - session_init_in.port.physical_port = mei_get_ddi_index(data->port);
> + session_init_in.port.physical_port = (u8)data->fw_ddi;
> session_init_in.protocol = data->protocol;
>
> byte = mei_cldev_send(cldev, (u8 *)_init_in, @@ -138,7
> +126,7 @@ mei_hdcp_verify_receiver_cert_prepare_km(struct device *dev,
>
> WIRED_CMD_BUF_LEN_VERIFY_RECEIVER_CERT_IN;
>
> verify_rxcert_in.port.integrated_port_type = data->port_type;
> - verify_rxcert_in.port.physical_port = mei_get_ddi_index(data->port);
> + verify_rxcert_in.port.physical_port = (u8)data->fw_ddi;
>
> verify_rxcert_in.cert_rx = rx_cert->cert_rx;
> memcpy(verify_rxcert_in.r_rx, _cert->r_rx, HDCP_2_2_RRX_LEN);
> @@ -208,7 +196,7 @@ mei_hdcp_verify_hprime(struct device *dev, struct
> hdcp_port_data *data,
> 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 = mei_get_ddi_index(data->port);
> + send_hprime_in.port.physical_port = (u8)data->fw_ddi;
>
> memcpy(send_hprime_in.h_prime, rx_hprime->h_prime,
> HDCP_2_2_H_PRIME_LEN);
> @@ -265,7 +253,7 @@ mei_hdcp_store_pairing_info(struct device *dev, struct
> hdcp_port_data *data,
>
> WIRED_CMD_BUF_LEN_SEND_PAIRING_INFO_IN;
>
> pairing_info_in.port.integrated_port_type = data->port_type;
> - pairing_info_in.port.physical_port = mei_get_ddi_index(data->port);
> + pairing_info_in.port.physical_port = (u8)data->fw_ddi;
>
> memcpy(pairing_info_in.e_kh_km, pairing_info->e_kh_km,
> HDCP_2_2_E_KH_KM_LEN);
> @@ -323,7 +311,7 @@ mei_hdcp_initiate_locality_check(struct device *dev,
> 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 = mei_get_ddi_index(data->port);
> +
RE: [PATCH v11 6/6] drm/i915/hdcp: Enable HDCP 1.4 and 2.2 on Gen12+
>
> >From Gen12 onwards, HDCP HW block is implemented within transcoders.
> Till Gen11 HDCP HW block was part of DDI.
>
> Hence required changes in HW programming is handled here.
>
> As ME FW needs the transcoder detail on which HDCP is enabled on Gen12+
> platform, we are populating the detail in hdcp_port_data.
>
> v2:
> _MMIO_TRANS is used [Lucas and Daniel]
> platform check is moved into the caller [Lucas]
> v3:
> platform check is moved into a macro [Shashank]
> v4:
> Few optimizations in the coding [Shashank]
> v5:
> Fixed alignment in macro definition in i915_reg.h [Shashank]
> unused variables "reg" is removed.
> v6:
> Configuring the transcoder at compute_config.
> transcoder is used instead of pipe in macros.
> Rebased.
> v7:
> transcoder is cached at intel_hdcp
> hdcp_port_data is configured with transcoder index asper ME FW.
> v8:
> s/trans/cpu_transcoder
> s/tc/cpu_transcoder
> v9:
> rep_ctl is prepared for TCD too.
> return moved into deault of rep_ctl prepare function [Shashank]
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Shashank Sharma
> Acked-by: Jani Nikula
I don't like much this hiding the logic behind macros, but looks like this is a
style in i915. Maybe inline functions would be a better call here.
I'm a bit worry about not checking return values of some functions, like
intel_hdcp_get_repeater_ctl(), and feeding it directly to other call.
Otherwise, you can add my reviewed by.
Thanks
Tomas
> ---
> drivers/gpu/drm/i915/display/intel_hdcp.c | 152 ++
> drivers/gpu/drm/i915/display/intel_hdmi.c | 10 +-
> drivers/gpu/drm/i915/i915_reg.h | 124 --
> 3 files changed, 221 insertions(+), 65 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index 988d675f9f69..b855d6568987 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -20,6 +20,7 @@
> #include "intel_display_types.h"
> #include "intel_hdcp.h"
> #include "intel_sideband.h"
> +#include "intel_connector.h"
>
> #define KEY_LOAD_TRIES 5
> #define ENCRYPT_STATUS_CHANGE_TIMEOUT_MS 50
> @@ -107,24 +108,20 @@ bool intel_hdcp2_capable(struct intel_connector
> *connector)
> return capable;
> }
>
> -static inline bool intel_hdcp_in_use(struct intel_connector *connector)
> +static inline
> +bool intel_hdcp_in_use(struct drm_i915_private *dev_priv,
> +enum transcoder cpu_transcoder, enum port port)
> {
> - 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;
> + return I915_READ(HDCP_STATUS(dev_priv, cpu_transcoder, port)) &
> +HDCP_STATUS_ENC;
> }
>
> -static inline bool intel_hdcp2_in_use(struct intel_connector *connector)
> +static inline
> +bool intel_hdcp2_in_use(struct drm_i915_private *dev_priv,
> + enum transcoder cpu_transcoder, enum port port)
> {
> - 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;
> + return I915_READ(HDCP2_STATUS(dev_priv, cpu_transcoder, port)) &
> +LINK_ENCRYPTION_STATUS;
> }
>
> static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port
> *intel_dig_port,
> @@ -255,9 +252,29 @@ static int intel_write_sha_text(struct
> drm_i915_private *dev_priv, u32 sha_text) }
>
> static
> -u32 intel_hdcp_get_repeater_ctl(struct intel_digital_port *intel_dig_port)
> +u32 intel_hdcp_get_repeater_ctl(struct drm_i915_private *dev_priv,
> + enum transcoder cpu_transcoder, enum port
> port)
> {
> - enum port port = intel_dig_port->base.port;
> + if (INTEL_GEN(dev_priv) >= 12) {
> + switch (cpu_transcoder) {
> + case TRANSCODER_A:
> + return HDCP_TRANSA_REP_PRESENT |
> +HDCP_TRANSA_SHA1_M0;
> + case TRANSCODER_B:
> + return HDCP_TRANSB_REP_PRESENT |
> +HDCP_TRANSB_SHA1_M0;
> + case TRANSCODER_C:
> + return HDCP_TRANSC_REP_PRESENT |
> +HDCP_TRANSC_SHA1_M0;
> + case TRANSCODER_D:
> + return HDCP_TRANSD_REP_PRESENT |
> +HDCP_TRANSD_SHA1_M0;
> + default:
> + DRM_ERROR("Unknown transcoder %d\n",
> cpu_transcoder);
> + return -EINVAL;
> + }
> + }
> +
> switch (port) {
> case PORT_A:
> return HDCP_DDIA_REP_PRESENT | HDCP_DDIA_SHA1_M0;
> @@ -270,18 +287,20 @@ u32
RE: [PATCH v11 5/6] drm/i915/hdcp: update current transcoder into intel_hdcp
>
> On 2019-08-28 at 14:09:01 +0530, Winkler, Tomas wrote:
> > >
> > > On 2019-08-28 at 13:56:06 +0530, Winkler, Tomas wrote:
> > > >
> > > > > On gen12+ platforms, HDCP HW is associated to the transcoder.
> > > > > Hence on every modeset update associated transcoder into the
> > > > > intel_hdcp of the port.
> > > > >
> > > > > v2:
> > > > > s/trans/cpu_transcoder [Jani]
> > > > > v3:
> > > > > comment is added for fw_ddi init for gen12+ [Shashank]
> > > > > only hdcp capable transcoder is translated into fw_tc
> > > > > [Shashank]
> > > > > v4:
> > > > > fw_tc initialization is kept for modeset. [Tomas]
> > > > > few extra doc is added at port_data init [Tomas]
> > > > >
> > > > > Signed-off-by: Ramalingam C
> > > > > Acked-by: Jani Nikula
> > > > > ---
> > > > > .../drm/i915/display/intel_display_types.h| 7 +++
> > > > > drivers/gpu/drm/i915/display/intel_dp.c | 3 ++
> > > > > drivers/gpu/drm/i915/display/intel_hdcp.c | 48
> ++-
> > > > > drivers/gpu/drm/i915/display/intel_hdcp.h | 3 ++
> > > > > drivers/gpu/drm/i915/display/intel_hdmi.c | 3 ++
> > > > > 5 files changed, 63 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > > index 96514dcc7812..61277a87dbe7 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > > @@ -388,6 +388,13 @@ struct intel_hdcp {
> > > > > wait_queue_head_t cp_irq_queue;
> > > > > atomic_t cp_irq_count;
> > > > > int cp_irq_count_cached;
> > > > > +
> > > > > + /*
> > > > > + * HDCP register access for gen12+ need the transcoder
> associated.
> > > > > + * Transcoder attached to the connector could be changed at
> modeset.
> > > > > + * Hence caching the transcoder here.
> > > > > + */
> > > > > + enum transcoder cpu_transcoder;
> > > > > };
> > > > >
> > > > > struct intel_connector {
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > index 23908da1cd5d..e8471689f785 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > @@ -2248,6 +2248,9 @@ intel_dp_compute_config(struct
> > > > > intel_encoder *encoder,
> > > > >
> > > > > intel_psr_compute_config(intel_dp, pipe_config);
> > > > >
> > > > > + intel_hdcp_transcoder_config(intel_connector,
> > > > > + pipe_config->cpu_transcoder);
> > > > > +
> > > > > return 0;
> > > > > }
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > > > b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > > > index e8b04cc8fcb1..988d675f9f69 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > > > @@ -1764,13 +1764,59 @@ enum mei_fw_ddi
> > > > > intel_get_mei_fw_ddi_index(enum port port)
> > > > > }
> > > > > }
> > > > >
> > > > > +static inline
> > > > > +enum mei_fw_tc intel_get_mei_fw_tc(enum transcoder
> cpu_transcoder) {
> > > > > + switch (cpu_transcoder) {
> > > > > + case TRANSCODER_A ... TRANSCODER_D:
> > > > > + return (enum mei_fw_tc)(cpu_transcoder | 0x10);
> > > > > + default: /* eDP, DSI TRANSCODERS are non HDCP capable */
> > > > > + return MEI_INVALID_TRANSCODER;
> > > > > + }
> > > > > +}
> > > > > +
> > > > > +void intel_hdcp_transcoder_config(struct intel_connector *connector,
> > > > > +
RE: [PATCH v11 5/6] drm/i915/hdcp: update current transcoder into intel_hdcp
>
> On 2019-08-28 at 13:56:06 +0530, Winkler, Tomas wrote:
> >
> > > On gen12+ platforms, HDCP HW is associated to the transcoder.
> > > Hence on every modeset update associated transcoder into the
> > > intel_hdcp of the port.
> > >
> > > v2:
> > > s/trans/cpu_transcoder [Jani]
> > > v3:
> > > comment is added for fw_ddi init for gen12+ [Shashank]
> > > only hdcp capable transcoder is translated into fw_tc [Shashank]
> > > v4:
> > > fw_tc initialization is kept for modeset. [Tomas]
> > > few extra doc is added at port_data init [Tomas]
> > >
> > > Signed-off-by: Ramalingam C
> > > Acked-by: Jani Nikula
> > > ---
> > > .../drm/i915/display/intel_display_types.h| 7 +++
> > > drivers/gpu/drm/i915/display/intel_dp.c | 3 ++
> > > drivers/gpu/drm/i915/display/intel_hdcp.c | 48 ++-
> > > drivers/gpu/drm/i915/display/intel_hdcp.h | 3 ++
> > > drivers/gpu/drm/i915/display/intel_hdmi.c | 3 ++
> > > 5 files changed, 63 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > index 96514dcc7812..61277a87dbe7 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > @@ -388,6 +388,13 @@ struct intel_hdcp {
> > > wait_queue_head_t cp_irq_queue;
> > > atomic_t cp_irq_count;
> > > int cp_irq_count_cached;
> > > +
> > > + /*
> > > + * HDCP register access for gen12+ need the transcoder associated.
> > > + * Transcoder attached to the connector could be changed at modeset.
> > > + * Hence caching the transcoder here.
> > > + */
> > > + enum transcoder cpu_transcoder;
> > > };
> > >
> > > struct intel_connector {
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > index 23908da1cd5d..e8471689f785 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > @@ -2248,6 +2248,9 @@ intel_dp_compute_config(struct intel_encoder
> > > *encoder,
> > >
> > > intel_psr_compute_config(intel_dp, pipe_config);
> > >
> > > + intel_hdcp_transcoder_config(intel_connector,
> > > + pipe_config->cpu_transcoder);
> > > +
> > > return 0;
> > > }
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > index e8b04cc8fcb1..988d675f9f69 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > @@ -1764,13 +1764,59 @@ enum mei_fw_ddi
> > > intel_get_mei_fw_ddi_index(enum port port)
> > > }
> > > }
> > >
> > > +static inline
> > > +enum mei_fw_tc intel_get_mei_fw_tc(enum transcoder cpu_transcoder) {
> > > + switch (cpu_transcoder) {
> > > + case TRANSCODER_A ... TRANSCODER_D:
> > > + return (enum mei_fw_tc)(cpu_transcoder | 0x10);
> > > + default: /* eDP, DSI TRANSCODERS are non HDCP capable */
> > > + return MEI_INVALID_TRANSCODER;
> > > + }
> > > +}
> > > +
> > > +void intel_hdcp_transcoder_config(struct intel_connector *connector,
> > > + enum transcoder cpu_transcoder) {
> > > + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> > > + struct intel_hdcp *hdcp = >hdcp;
> > > +
> > > + if (!hdcp->shim)
> > > + return;
> > > +
> > > + if (INTEL_GEN(dev_priv) >= 12) {
> > > + mutex_lock(>mutex);
> > > + hdcp->cpu_transcoder = cpu_transcoder;
> > > + hdcp->port_data.fw_tc =
> > > intel_get_mei_fw_tc(cpu_transcoder);
> > > + mutex_unlock(>mutex);
> > > + }
> > > +}
> > > +
> > > static inline int initialize_hdcp_port_data(struct intel_connector
> *connector,
> > > const struct intel_hdcp_shim *shim)
> {
> > > + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> > > struct intel_hdcp *hdcp = >hdcp;
> > > struct hdcp_port
RE: [PATCH v11 5/6] drm/i915/hdcp: update current transcoder into intel_hdcp
> On gen12+ platforms, HDCP HW is associated to the transcoder.
> Hence on every modeset update associated transcoder into the intel_hdcp of
> the port.
>
> v2:
> s/trans/cpu_transcoder [Jani]
> v3:
> comment is added for fw_ddi init for gen12+ [Shashank]
> only hdcp capable transcoder is translated into fw_tc [Shashank]
> v4:
> fw_tc initialization is kept for modeset. [Tomas]
> few extra doc is added at port_data init [Tomas]
>
> Signed-off-by: Ramalingam C
> Acked-by: Jani Nikula
> ---
> .../drm/i915/display/intel_display_types.h| 7 +++
> drivers/gpu/drm/i915/display/intel_dp.c | 3 ++
> drivers/gpu/drm/i915/display/intel_hdcp.c | 48 ++-
> drivers/gpu/drm/i915/display/intel_hdcp.h | 3 ++
> drivers/gpu/drm/i915/display/intel_hdmi.c | 3 ++
> 5 files changed, 63 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 96514dcc7812..61277a87dbe7 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -388,6 +388,13 @@ struct intel_hdcp {
> wait_queue_head_t cp_irq_queue;
> atomic_t cp_irq_count;
> int cp_irq_count_cached;
> +
> + /*
> + * HDCP register access for gen12+ need the transcoder associated.
> + * Transcoder attached to the connector could be changed at modeset.
> + * Hence caching the transcoder here.
> + */
> + enum transcoder cpu_transcoder;
> };
>
> struct intel_connector {
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 23908da1cd5d..e8471689f785 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -2248,6 +2248,9 @@ intel_dp_compute_config(struct intel_encoder
> *encoder,
>
> intel_psr_compute_config(intel_dp, pipe_config);
>
> + intel_hdcp_transcoder_config(intel_connector,
> + pipe_config->cpu_transcoder);
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index e8b04cc8fcb1..988d675f9f69 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -1764,13 +1764,59 @@ enum mei_fw_ddi
> intel_get_mei_fw_ddi_index(enum port port)
> }
> }
>
> +static inline
> +enum mei_fw_tc intel_get_mei_fw_tc(enum transcoder cpu_transcoder) {
> + switch (cpu_transcoder) {
> + case TRANSCODER_A ... TRANSCODER_D:
> + return (enum mei_fw_tc)(cpu_transcoder | 0x10);
> + default: /* eDP, DSI TRANSCODERS are non HDCP capable */
> + return MEI_INVALID_TRANSCODER;
> + }
> +}
> +
> +void intel_hdcp_transcoder_config(struct intel_connector *connector,
> + enum transcoder cpu_transcoder)
> +{
> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> + struct intel_hdcp *hdcp = >hdcp;
> +
> + if (!hdcp->shim)
> + return;
> +
> + if (INTEL_GEN(dev_priv) >= 12) {
> + mutex_lock(>mutex);
> + hdcp->cpu_transcoder = cpu_transcoder;
> + hdcp->port_data.fw_tc =
> intel_get_mei_fw_tc(cpu_transcoder);
> + mutex_unlock(>mutex);
> + }
> +}
> +
> static inline int initialize_hdcp_port_data(struct intel_connector
> *connector,
> const struct intel_hdcp_shim *shim)
> {
> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> struct intel_hdcp *hdcp = >hdcp;
> struct hdcp_port_data *data = >port_data;
>
> - data->fw_ddi = intel_get_mei_fw_ddi_index(connector->encoder-
> >port);
> + if (INTEL_GEN(dev_priv) < 12) {
Now you have one liners, you should drop the brackets.
> + data->fw_ddi =
> + intel_get_mei_fw_ddi_index(connector->encoder-
> >port);
> + } else {
> +
> + /*
> + * As per ME FW API expectation, for GEN 12+, fw_ddi is filled
> + * with INVALID PORT index.
> + */
> + data->fw_ddi = MEI_DDI_INVALID_PORT;
In your previous patch you commented that this should be '0', need to make
comment consistent even if MEI_DDI_INVALID_PORT is 0
> + }
> +
> + /*
> + * As associated transcoder is set and modified at modeset, here fw_tc
> + * is initialized to invalid index.
> + */
> + data->fw_tc = MEI_INVALID_TRANSCODER;
In your previous you commented this should be '0', as for port.
> +
> data->port_type = (u8)HDCP_PORT_TYPE_INTEGRATED;
> data->protocol = (u8)shim->protocol;
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.h
> b/drivers/gpu/drm/i915/display/intel_hdcp.h
> index 59a2b40405cc..41c1053d9e38 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.h
> +++
RE: [PATCH v11 4/6] misc/mei/hdcp: Fill transcoder index in port info
>
> For gen12+ platform we need to pass the transcoder info as part of the port
> info into ME FW.
>
> This change fills the payload for ME FW from hdcp_port_data.
>
> v2:
> Doc is enhanced for physical_port and attached_transcoder [Tomas]
>
> Signed-off-by: Ramalingam C
> Acked-by: Jani Nikula
> Reviewed-by: Shashank Sharma
Ack
> ---
> drivers/misc/mei/hdcp/mei_hdcp.c | 11 +++
> drivers/misc/mei/hdcp/mei_hdcp.h | 5 -
> 2 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index 3638c77eba26..93027fd96c71 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -58,6 +58,7 @@ mei_hdcp_initiate_session(struct device *dev, struct
> hdcp_port_data *data,
>
> session_init_in.port.integrated_port_type = data->port_type;
> session_init_in.port.physical_port = (u8)data->fw_ddi;
> + session_init_in.port.attached_transcoder = (u8)data->fw_tc;
> session_init_in.protocol = data->protocol;
>
> byte = mei_cldev_send(cldev, (u8 *)_init_in, @@ -127,6
> +128,7 @@ mei_hdcp_verify_receiver_cert_prepare_km(struct device *dev,
>
> verify_rxcert_in.port.integrated_port_type = data->port_type;
> verify_rxcert_in.port.physical_port = (u8)data->fw_ddi;
> + verify_rxcert_in.port.attached_transcoder = (u8)data->fw_tc;
>
> verify_rxcert_in.cert_rx = rx_cert->cert_rx;
> memcpy(verify_rxcert_in.r_rx, _cert->r_rx, HDCP_2_2_RRX_LEN);
> @@ -197,6 +199,7 @@ mei_hdcp_verify_hprime(struct device *dev, struct
> hdcp_port_data *data,
>
> send_hprime_in.port.integrated_port_type = data->port_type;
> send_hprime_in.port.physical_port = (u8)data->fw_ddi;
> + send_hprime_in.port.attached_transcoder = (u8)data->fw_tc;
>
> memcpy(send_hprime_in.h_prime, rx_hprime->h_prime,
> HDCP_2_2_H_PRIME_LEN);
> @@ -254,6 +257,7 @@ mei_hdcp_store_pairing_info(struct device *dev, struct
> hdcp_port_data *data,
>
> pairing_info_in.port.integrated_port_type = data->port_type;
> pairing_info_in.port.physical_port = (u8)data->fw_ddi;
> + pairing_info_in.port.attached_transcoder = (u8)data->fw_tc;
>
> memcpy(pairing_info_in.e_kh_km, pairing_info->e_kh_km,
> HDCP_2_2_E_KH_KM_LEN);
> @@ -312,6 +316,7 @@ mei_hdcp_initiate_locality_check(struct device *dev,
>
> lc_init_in.port.integrated_port_type = data->port_type;
> lc_init_in.port.physical_port = (u8)data->fw_ddi;
> + lc_init_in.port.attached_transcoder = (u8)data->fw_tc;
>
> byte = mei_cldev_send(cldev, (u8 *)_init_in, sizeof(lc_init_in));
> if (byte < 0) {
> @@ -367,6 +372,7 @@ mei_hdcp_verify_lprime(struct device *dev, struct
> hdcp_port_data *data,
>
> verify_lprime_in.port.integrated_port_type = data->port_type;
> verify_lprime_in.port.physical_port = (u8)data->fw_ddi;
> + verify_lprime_in.port.attached_transcoder = (u8)data->fw_tc;
>
> memcpy(verify_lprime_in.l_prime, rx_lprime->l_prime,
> HDCP_2_2_L_PRIME_LEN);
> @@ -424,6 +430,7 @@ static int mei_hdcp_get_session_key(struct device
> *dev,
>
> get_skey_in.port.integrated_port_type = data->port_type;
> get_skey_in.port.physical_port = (u8)data->fw_ddi;
> + get_skey_in.port.attached_transcoder = (u8)data->fw_tc;
>
> byte = mei_cldev_send(cldev, (u8 *)_skey_in, sizeof(get_skey_in));
> if (byte < 0) {
> @@ -488,6 +495,7 @@ mei_hdcp_repeater_check_flow_prepare_ack(struct
> device *dev,
>
> verify_repeater_in.port.integrated_port_type = data->port_type;
> verify_repeater_in.port.physical_port = (u8)data->fw_ddi;
> + verify_repeater_in.port.attached_transcoder = (u8)data->fw_tc;
>
> memcpy(verify_repeater_in.rx_info, rep_topology->rx_info,
> HDCP_2_2_RXINFO_LEN);
> @@ -558,6 +566,7 @@ static int mei_hdcp_verify_mprime(struct device *dev,
>
> verify_mprime_in.port.integrated_port_type = data->port_type;
> verify_mprime_in.port.physical_port = (u8)data->fw_ddi;
> + verify_mprime_in.port.attached_transcoder = (u8)data->fw_tc;
>
> memcpy(verify_mprime_in.m_prime, stream_ready->m_prime,
> HDCP_2_2_MPRIME_LEN);
> @@ -619,6 +628,7 @@ static int mei_hdcp_enable_authentication(struct
> device *dev,
>
> enable_auth_in.port.integrated_port_type = data->port_type;
> enable_auth_in.port.physical_port = (u8)data->fw_ddi;
> + enable_auth_in.port.attached_transcoder = (u8)data->fw_tc;
> enable_auth_in.stream_type = data->streams[0].stream_type;
>
> byte = mei_cldev_send(cldev, (u8 *)_auth_in, @@ -673,6
> +683,7 @@ mei_hdcp_close_session(struct device *dev, struct hdcp_port_data
> *data)
>
> session_close_in.port.integrated_port_type = data->port_type;
> session_close_in.port.physical_port = (u8)data->fw_ddi;
> + session_close_in.port.attached_transcoder = (u8)data->fw_tc;
>
> byte =
RE: [PATCH v11 3/6] drm: Extend I915 mei interface for transcoder info
>
> On 2019-08-28 at 13:28:06 +0530, Winkler, Tomas wrote:
> > > I915 needs to send the index of the transcoder as per ME FW.
> > >
> > > To support this, define enum mei_fw_tc and add as a member into the
> > > struct hdcp_port_data.
> > >
> > > v2:
> > > Typo in commit msg is fixed [Shashank]
> > > v3:
> > > kdoc is added for mei_fw_tc [Tomas]
> > > s/MEI_TC_x/MEI_TRANSCODER_x
> > >
> > > Signed-off-by: Ramalingam C
> > > Acked-by: Jani Nikula
> >
> > LGTM, just need to updated the copyright year.
> Tomas,
>
> Copyright year for this i915_mei_hdcp_interface.h is updated in the 1st patch
> itself.
Okay.
>
> -Ram
> >
> > > ---
> > > include/drm/i915_mei_hdcp_interface.h | 24
>
> > > 1 file changed, 24 insertions(+)
> > >
> > > diff --git a/include/drm/i915_mei_hdcp_interface.h
> > > b/include/drm/i915_mei_hdcp_interface.h
> > > index 08670aa650d4..4d48de8890ca 100644
> > > --- a/include/drm/i915_mei_hdcp_interface.h
> > > +++ b/include/drm/i915_mei_hdcp_interface.h
> > > @@ -54,9 +54,32 @@ enum mei_fw_ddi {
> > > MEI_DDI_RANGE_END = MEI_DDI_A,
> > > };
> > >
> > > +/**
> > > + * enum mei_fw_tc - ME Firmware defined index for transcoders
> > > + * @MEI_INVALID_TRANSCODER: Index for Invalid transcoder
> > > + * @MEI_TRANSCODER_EDP: Index for EDP Transcoder
> > > + * @MEI_TRANSCODER_DSI0: Index for DSI0 Transcoder
> > > + * @MEI_TRANSCODER_DSI1: Index for DSI1 Transcoder
> > > + * @MEI_TRANSCODER_A: Index for Transcoder A
> > > + * @MEI_TRANSCODER_B: Index for Transcoder B
> > > + * @MEI_TRANSCODER_C: Index for Transcoder C
> > > + * @MEI_TRANSCODER_D: Index for Transcoder D */ enum mei_fw_tc {
> > > + MEI_INVALID_TRANSCODER = 0x00,
> > > + MEI_TRANSCODER_EDP,
> > > + MEI_TRANSCODER_DSI0,
> > > + MEI_TRANSCODER_DSI1,
> > > + MEI_TRANSCODER_A = 0x10,
> > > + MEI_TRANSCODER_B,
> > > + MEI_TRANSCODER_C,
> > > + MEI_TRANSCODER_D
> > > +};
> > > +
> > > /**
> > > * struct hdcp_port_data - intel specific HDCP port data
> > > * @fw_ddi: ddi index as per ME FW
> > > + * @fw_tc: transcoder index as per ME FW
> > > * @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 @@ -
> > > 69,6 +92,7 @@ enum mei_fw_ddi {
> > > */
> > > struct hdcp_port_data {
> > > enum mei_fw_ddi fw_ddi;
> > > + enum mei_fw_tc fw_tc;
> > > u8 port_type;
> > > u8 protocol;
> > > u16 k;
> > > --
> > > 2.20.1
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v11 3/6] drm: Extend I915 mei interface for transcoder info
> I915 needs to send the index of the transcoder as per ME FW.
>
> To support this, define enum mei_fw_tc and add as a member into the struct
> hdcp_port_data.
>
> v2:
> Typo in commit msg is fixed [Shashank]
> v3:
> kdoc is added for mei_fw_tc [Tomas]
> s/MEI_TC_x/MEI_TRANSCODER_x
>
> Signed-off-by: Ramalingam C
> Acked-by: Jani Nikula
LGTM, just need to updated the copyright year.
> ---
> include/drm/i915_mei_hdcp_interface.h | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/include/drm/i915_mei_hdcp_interface.h
> b/include/drm/i915_mei_hdcp_interface.h
> index 08670aa650d4..4d48de8890ca 100644
> --- a/include/drm/i915_mei_hdcp_interface.h
> +++ b/include/drm/i915_mei_hdcp_interface.h
> @@ -54,9 +54,32 @@ enum mei_fw_ddi {
> MEI_DDI_RANGE_END = MEI_DDI_A,
> };
>
> +/**
> + * enum mei_fw_tc - ME Firmware defined index for transcoders
> + * @MEI_INVALID_TRANSCODER: Index for Invalid transcoder
> + * @MEI_TRANSCODER_EDP: Index for EDP Transcoder
> + * @MEI_TRANSCODER_DSI0: Index for DSI0 Transcoder
> + * @MEI_TRANSCODER_DSI1: Index for DSI1 Transcoder
> + * @MEI_TRANSCODER_A: Index for Transcoder A
> + * @MEI_TRANSCODER_B: Index for Transcoder B
> + * @MEI_TRANSCODER_C: Index for Transcoder C
> + * @MEI_TRANSCODER_D: Index for Transcoder D */ enum mei_fw_tc {
> + MEI_INVALID_TRANSCODER = 0x00,
> + MEI_TRANSCODER_EDP,
> + MEI_TRANSCODER_DSI0,
> + MEI_TRANSCODER_DSI1,
> + MEI_TRANSCODER_A = 0x10,
> + MEI_TRANSCODER_B,
> + MEI_TRANSCODER_C,
> + MEI_TRANSCODER_D
> +};
> +
> /**
> * struct hdcp_port_data - intel specific HDCP port data
> * @fw_ddi: ddi index as per ME FW
> + * @fw_tc: transcoder index as per ME FW
> * @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 @@ -
> 69,6 +92,7 @@ enum mei_fw_ddi {
> */
> struct hdcp_port_data {
> enum mei_fw_ddi fw_ddi;
> + enum mei_fw_tc fw_tc;
> u8 port_type;
> u8 protocol;
> u16 k;
> --
> 2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v11 2/6] drm: Move port definition back to i915 header
>
> We dont need the definition of the enum port outside I915, anymore.
> Hence move enum port definition into I915 driver itself.
>
> v2:
> intel_display.h is included in intel_hdcp.h
> v3:
> enum port is declared in headers.
> v4:
> commit msg is rephrased.
> v5:
> copyright year is updated [Tomas]
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Jani Nikula
> Reviewed-by: Shashank Sharma
LGTM, you can add my Reviewed-by
> ---
> drivers/gpu/drm/i915/display/intel_bios.h| 3 ++-
> drivers/gpu/drm/i915/display/intel_display.h | 20 +++-
> drivers/gpu/drm/i915/display/intel_dp.h | 1 +
> drivers/gpu/drm/i915/display/intel_hdcp.h| 1 +
> drivers/gpu/drm/i915/display/intel_hdmi.h| 1 +
> drivers/gpu/drm/i915/display/intel_hotplug.h | 1 +
> drivers/gpu/drm/i915/display/intel_sdvo.h| 1 +
> include/drm/i915_drm.h | 18 --
> 8 files changed, 26 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.h
> b/drivers/gpu/drm/i915/display/intel_bios.h
> index 4969189e620f..98f064828a57 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.h
> +++ b/drivers/gpu/drm/i915/display/intel_bios.h
> @@ -1,5 +1,5 @@
> /*
> - * Copyright © 2016 Intel Corporation
> + * Copyright © 2016-2019 Intel Corporation
> *
> * Permission is hereby granted, free of charge, to any person obtaining a
> * copy of this software and associated documentation files (the "Software"),
> @@ -35,6 +35,7 @@ #include
>
> struct drm_i915_private;
> +enum port;
>
> enum intel_backlight_type {
> INTEL_BACKLIGHT_PMIC,
> diff --git a/drivers/gpu/drm/i915/display/intel_display.h
> b/drivers/gpu/drm/i915/display/intel_display.h
> index e57e6969051d..38fb1831df63 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.h
> +++ b/drivers/gpu/drm/i915/display/intel_display.h
> @@ -1,5 +1,5 @@
> /*
> - * Copyright © 2006-2017 Intel Corporation
> + * Copyright © 2006-2019 Intel Corporation
> *
> * Permission is hereby granted, free of charge, to any person obtaining a
> * copy of this software and associated documentation files (the "Software"),
> @@ -182,6 +182,24 @@ enum plane_id {
> for ((__p) = PLANE_PRIMARY; (__p) < I915_MAX_PLANES; (__p)++) \
> for_each_if((__crtc)->plane_ids_mask & BIT(__p))
>
> +enum port {
> + PORT_NONE = -1,
> +
> + PORT_A = 0,
> + PORT_B,
> + PORT_C,
> + PORT_D,
> + PORT_E,
> + PORT_F,
> + PORT_G,
> + PORT_H,
> + PORT_I,
> +
> + I915_MAX_PORTS
> +};
> +
> +#define port_name(p) ((p) + 'A')
> +
> /*
> * Ports identifier referenced from other drivers.
> * Expected to remain stable over time
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index 657bbb1f5ed0..e01d1f89409d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -13,6 +13,7 @@
> #include "i915_reg.h"
>
> enum pipe;
> +enum port;
> struct drm_connector_state;
> struct drm_encoder;
> struct drm_i915_private;
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.h
> b/drivers/gpu/drm/i915/display/intel_hdcp.h
> index 13555b054930..59a2b40405cc 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.h
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.h
> @@ -15,6 +15,7 @@ struct drm_connector_state; struct drm_i915_private;
> struct intel_connector; struct intel_hdcp_shim;
> +enum port;
>
> void intel_hdcp_atomic_check(struct drm_connector *connector,
>struct drm_connector_state *old_state, diff --git
> a/drivers/gpu/drm/i915/display/intel_hdmi.h
> b/drivers/gpu/drm/i915/display/intel_hdmi.h
> index 106c2e0bc3c9..cf1ea5427639 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.h
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.h
> @@ -23,6 +23,7 @@ struct intel_crtc_state; struct intel_hdmi; struct
> drm_connector_state; union hdmi_infoframe;
> +enum port;
>
> void intel_hdmi_init(struct drm_i915_private *dev_priv, i915_reg_t hdmi_reg,
>enum port port);
> diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.h
> b/drivers/gpu/drm/i915/display/intel_hotplug.h
> index b0cd447b7fbc..087b5f57b321 100644
> --- a/drivers/gpu/drm/i915/display/intel_hotplug.h
> +++ b/drivers/gpu/drm/i915/display/intel_hotplug.h
> @@ -13,6 +13,7 @@
> struct drm_i915_private;
> struct intel_connector;
> struct intel_encoder;
> +enum port;
>
> void intel_hpd_poll_init(struct drm_i915_private *dev_priv); enum
> intel_hotplug_state intel_encoder_hotplug(struct intel_encoder *encoder, diff
> -
> -git a/drivers/gpu/drm/i915/display/intel_sdvo.h
> b/drivers/gpu/drm/i915/display/intel_sdvo.h
> index c9e05bcdd141..a66f224aa17d 100644
> --- a/drivers/gpu/drm/i915/display/intel_sdvo.h
> +++ b/drivers/gpu/drm/i915/display/intel_sdvo.h
> @@ -14,6 +14,7 @@
>
> struct drm_i915_private;
> enum pipe;
> +enum port;
>
>
RE: [PATCH v10 5/6] drm/i915/hdcp: update current transcoder into intel_hdcp
>
> On 2019-08-27 at 20:03:21 +0530, Winkler, Tomas wrote:
> > > On gen12+ platforms, HDCP HW is associated to the transcoder.
> > > Hence on every modeset update associated transcoder into the
> > > intel_hdcp of the port.
> > >
> > > v2:
> > > s/trans/cpu_transcoder [Jani]
> > > v3:
> > > comment is added for fw_ddi init for gen12+ [Shashank]
> > > only hdcp capable transcoder is translated into fw_tc [Shashank]
> > >
> > > Signed-off-by: Ramalingam C
> > > Acked-by: Jani Nikula
> > > ---
> > > .../drm/i915/display/intel_display_types.h| 7 +++
> > > drivers/gpu/drm/i915/display/intel_dp.c | 3 ++
> > > drivers/gpu/drm/i915/display/intel_hdcp.c | 47 ++-
> > > drivers/gpu/drm/i915/display/intel_hdcp.h | 3 ++
> > > drivers/gpu/drm/i915/display/intel_hdmi.c | 3 ++
> > > 5 files changed, 62 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > index 96514dcc7812..61277a87dbe7 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > @@ -388,6 +388,13 @@ struct intel_hdcp {
> > > wait_queue_head_t cp_irq_queue;
> > > atomic_t cp_irq_count;
> > > int cp_irq_count_cached;
> > > +
> > > + /*
> > > + * HDCP register access for gen12+ need the transcoder associated.
> > > + * Transcoder attached to the connector could be changed at
> modeset.
> > > + * Hence caching the transcoder here.
> > > + */
> > > + enum transcoder cpu_transcoder;
> > > };
> > >
> > > struct intel_connector {
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > index 23908da1cd5d..e8471689f785 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > @@ -2248,6 +2248,9 @@ intel_dp_compute_config(struct intel_encoder
> > > *encoder,
> > >
> > > intel_psr_compute_config(intel_dp, pipe_config);
> > >
> > > + intel_hdcp_transcoder_config(intel_connector,
> > > + pipe_config->cpu_transcoder);
> > > +
> > > return 0;
> > > }
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > index 534832f435dc..3591b8f7fe30 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > @@ -1762,13 +1762,58 @@ enum mei_fw_ddi
> > > intel_get_mei_fw_ddi_index(enum port port)
> > > }
> > > }
> > >
> > > +static inline
> > > +enum mei_fw_tc intel_get_mei_fw_tc(enum transcoder cpu_transcoder)
> {
> > > + switch (cpu_transcoder) {
> > > + case TRANSCODER_A ... TRANSCODER_D:
> > > + return (enum mei_fw_tc)(cpu_transcoder | 0x10);
> > > + default: /* eDP, DSI TRANSCODERS are non HDCP capable */
> > > + return MEI_INVALID_TRANSCODER;
> > > + }
> > > +}
> > > +
> > > +void intel_hdcp_transcoder_config(struct intel_connector *connector,
> > > + enum transcoder cpu_transcoder) {
> > > + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> > > + struct intel_hdcp *hdcp = >hdcp;
> > > +
> > > + if (!hdcp->shim)
> > > + return;
> > > +
> > > + if (INTEL_GEN(dev_priv) >= 12) {
> > > + mutex_lock(>mutex);
> > > + hdcp->cpu_transcoder = cpu_transcoder;
> > > + hdcp->port_data.fw_tc =
> > > intel_get_mei_fw_tc(cpu_transcoder);
> > > + mutex_unlock(>mutex);
> > > + }
> > > +}
> > > +
> > > static inline int initialize_hdcp_port_data(struct intel_connector
> *connector,
> > > const struct intel_hdcp_shim
> *shim) {
> > > + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> > > struct intel_hdcp *hdcp = >hdcp;
> > > struct hdcp_port_data *data = >port_data;
> > > + struct intel_crtc *crtc;
> > > +
> > > + if (INTEL_GEN(dev_priv) < 12) {
> > >
RE: [PATCH v10 4/6] misc/mei/hdcp: Fill transcoder index in port info
>
> On 2019-08-27 at 19:49:19 +0530, Winkler, Tomas wrote:
> > > For gen12+ platform we need to pass the transcoder info as part of
> > > the port info into ME FW.
> > >
> > > This change fills the payload for ME FW from hdcp_port_data.
> > >
> > > Signed-off-by: Ramalingam C
> > > Acked-by: Jani Nikula
> > > Reviewed-by: Shashank Sharma
> > > ---
> > > drivers/misc/mei/hdcp/mei_hdcp.c | 11 +++
> > > drivers/misc/mei/hdcp/mei_hdcp.h | 4 +++-
> > > 2 files changed, 14 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> > > b/drivers/misc/mei/hdcp/mei_hdcp.c
> > > index 3638c77eba26..93027fd96c71 100644
> > > --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> > > +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> > > @@ -58,6 +58,7 @@ mei_hdcp_initiate_session(struct device *dev,
> > > struct hdcp_port_data *data,
> > >
> > > session_init_in.port.integrated_port_type = data->port_type;
> > > session_init_in.port.physical_port = (u8)data->fw_ddi;
> > > + session_init_in.port.attached_transcoder = (u8)data->fw_tc;
> > > session_init_in.protocol = data->protocol;
> > >
> > > byte = mei_cldev_send(cldev, (u8 *)_init_in, @@ -127,6
> > > +128,7 @@ mei_hdcp_verify_receiver_cert_prepare_km(struct device
> > > +*dev,
> > >
> > > verify_rxcert_in.port.integrated_port_type = data->port_type;
> > > verify_rxcert_in.port.physical_port = (u8)data->fw_ddi;
> > > + verify_rxcert_in.port.attached_transcoder = (u8)data->fw_tc;
> > >
> > > verify_rxcert_in.cert_rx = rx_cert->cert_rx;
> > > memcpy(verify_rxcert_in.r_rx, _cert->r_rx, HDCP_2_2_RRX_LEN);
> > > @@ -197,6 +199,7 @@ mei_hdcp_verify_hprime(struct device *dev,
> > > struct hdcp_port_data *data,
> > >
> > > send_hprime_in.port.integrated_port_type = data->port_type;
> > > send_hprime_in.port.physical_port = (u8)data->fw_ddi;
> > > + send_hprime_in.port.attached_transcoder = (u8)data->fw_tc;
> > >
> > > memcpy(send_hprime_in.h_prime, rx_hprime->h_prime,
> > > HDCP_2_2_H_PRIME_LEN);
> > > @@ -254,6 +257,7 @@ mei_hdcp_store_pairing_info(struct device *dev,
> > > struct hdcp_port_data *data,
> > >
> > > pairing_info_in.port.integrated_port_type = data->port_type;
> > > pairing_info_in.port.physical_port = (u8)data->fw_ddi;
> > > + pairing_info_in.port.attached_transcoder = (u8)data->fw_tc;
> > >
> > > memcpy(pairing_info_in.e_kh_km, pairing_info->e_kh_km,
> > > HDCP_2_2_E_KH_KM_LEN);
> > > @@ -312,6 +316,7 @@ mei_hdcp_initiate_locality_check(struct device
> > > *dev,
> > >
> > > lc_init_in.port.integrated_port_type = data->port_type;
> > > lc_init_in.port.physical_port = (u8)data->fw_ddi;
> > > + lc_init_in.port.attached_transcoder = (u8)data->fw_tc;
> > >
> > > byte = mei_cldev_send(cldev, (u8 *)_init_in, sizeof(lc_init_in));
> > > if (byte < 0) {
> > > @@ -367,6 +372,7 @@ mei_hdcp_verify_lprime(struct device *dev,
> > > struct hdcp_port_data *data,
> > >
> > > verify_lprime_in.port.integrated_port_type = data->port_type;
> > > verify_lprime_in.port.physical_port = (u8)data->fw_ddi;
> > > + verify_lprime_in.port.attached_transcoder = (u8)data->fw_tc;
> > >
> > > memcpy(verify_lprime_in.l_prime, rx_lprime->l_prime,
> > > HDCP_2_2_L_PRIME_LEN);
> > > @@ -424,6 +430,7 @@ static int mei_hdcp_get_session_key(struct
> > > device *dev,
> > >
> > > get_skey_in.port.integrated_port_type = data->port_type;
> > > get_skey_in.port.physical_port = (u8)data->fw_ddi;
> > > + get_skey_in.port.attached_transcoder = (u8)data->fw_tc;
> > >
> > > byte = mei_cldev_send(cldev, (u8 *)_skey_in, sizeof(get_skey_in));
> > > if (byte < 0) {
> > > @@ -488,6 +495,7 @@
> mei_hdcp_repeater_check_flow_prepare_ack(struct
> > > device *dev,
> > >
> > > verify_repeater_in.port.integrated_port_type = data->port_type;
> > > verify_repeater_in.port.physical_port = (u8)data->fw_ddi;
> > > + verify_repeater_in.port.attached_transcoder = (u8)data->fw_tc;
> > >
> > > memcpy(verify_repeater_in.rx_info, rep_topology->rx_info,
> > > HDCP_2_2_RXINFO_LEN);
> > > @
RE: [PATCH v10 5/6] drm/i915/hdcp: update current transcoder into intel_hdcp
> On gen12+ platforms, HDCP HW is associated to the transcoder.
> Hence on every modeset update associated transcoder into the intel_hdcp of
> the port.
>
> v2:
> s/trans/cpu_transcoder [Jani]
> v3:
> comment is added for fw_ddi init for gen12+ [Shashank]
> only hdcp capable transcoder is translated into fw_tc [Shashank]
>
> Signed-off-by: Ramalingam C
> Acked-by: Jani Nikula
> ---
> .../drm/i915/display/intel_display_types.h| 7 +++
> drivers/gpu/drm/i915/display/intel_dp.c | 3 ++
> drivers/gpu/drm/i915/display/intel_hdcp.c | 47 ++-
> drivers/gpu/drm/i915/display/intel_hdcp.h | 3 ++
> drivers/gpu/drm/i915/display/intel_hdmi.c | 3 ++
> 5 files changed, 62 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 96514dcc7812..61277a87dbe7 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -388,6 +388,13 @@ struct intel_hdcp {
> wait_queue_head_t cp_irq_queue;
> atomic_t cp_irq_count;
> int cp_irq_count_cached;
> +
> + /*
> + * HDCP register access for gen12+ need the transcoder associated.
> + * Transcoder attached to the connector could be changed at modeset.
> + * Hence caching the transcoder here.
> + */
> + enum transcoder cpu_transcoder;
> };
>
> struct intel_connector {
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 23908da1cd5d..e8471689f785 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -2248,6 +2248,9 @@ intel_dp_compute_config(struct intel_encoder
> *encoder,
>
> intel_psr_compute_config(intel_dp, pipe_config);
>
> + intel_hdcp_transcoder_config(intel_connector,
> + pipe_config->cpu_transcoder);
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index 534832f435dc..3591b8f7fe30 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -1762,13 +1762,58 @@ enum mei_fw_ddi
> intel_get_mei_fw_ddi_index(enum port port)
> }
> }
>
> +static inline
> +enum mei_fw_tc intel_get_mei_fw_tc(enum transcoder cpu_transcoder) {
> + switch (cpu_transcoder) {
> + case TRANSCODER_A ... TRANSCODER_D:
> + return (enum mei_fw_tc)(cpu_transcoder | 0x10);
> + default: /* eDP, DSI TRANSCODERS are non HDCP capable */
> + return MEI_INVALID_TRANSCODER;
> + }
> +}
> +
> +void intel_hdcp_transcoder_config(struct intel_connector *connector,
> + enum transcoder cpu_transcoder)
> +{
> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> + struct intel_hdcp *hdcp = >hdcp;
> +
> + if (!hdcp->shim)
> + return;
> +
> + if (INTEL_GEN(dev_priv) >= 12) {
> + mutex_lock(>mutex);
> + hdcp->cpu_transcoder = cpu_transcoder;
> + hdcp->port_data.fw_tc =
> intel_get_mei_fw_tc(cpu_transcoder);
> + mutex_unlock(>mutex);
> + }
> +}
> +
> static inline int initialize_hdcp_port_data(struct intel_connector
> *connector,
> const struct intel_hdcp_shim *shim)
> {
> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> struct intel_hdcp *hdcp = >hdcp;
> struct hdcp_port_data *data = >port_data;
> + struct intel_crtc *crtc;
> +
> + if (INTEL_GEN(dev_priv) < 12) {
> + data->fw_ddi =
> + intel_get_mei_fw_ddi_index(connector->encoder-
> >port);
> + } else {
> + crtc = to_intel_crtc(connector->base.state->crtc);
> + if (crtc) {
> + hdcp->cpu_transcoder = crtc->config->cpu_transcoder;
> + data->fw_tc = intel_get_mei_fw_tc(hdcp-
> >cpu_transcoder);
> + }
What is the 'else' action here, looks like there is no default value for fw_tc?
> + /*
> + * As per ME FW API expectation, for GEN 12+, fw_ddi is filled
> + * with INVALID PORT.
> + */
> + data->fw_ddi = intel_get_mei_fw_ddi_index(PORT_NONE);
> + }
>
> - data->fw_ddi = intel_get_mei_fw_ddi_index(connector->encoder-
> >port);
> data->port_type = (u8)HDCP_PORT_TYPE_INTEGRATED;
> data->protocol = (u8)shim->protocol;
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.h
> b/drivers/gpu/drm/i915/display/intel_hdcp.h
> index 59a2b40405cc..41c1053d9e38 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.h
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.h
> @@ -16,10 +16,13 @@ struct drm_i915_private; struct intel_connector; struct
> intel_hdcp_shim; enum port;
>
RE: [PATCH v10 4/6] misc/mei/hdcp: Fill transcoder index in port info
> For gen12+ platform we need to pass the transcoder info as part of the port
> info into ME FW.
>
> This change fills the payload for ME FW from hdcp_port_data.
>
> Signed-off-by: Ramalingam C
> Acked-by: Jani Nikula
> Reviewed-by: Shashank Sharma
> ---
> drivers/misc/mei/hdcp/mei_hdcp.c | 11 +++
> drivers/misc/mei/hdcp/mei_hdcp.h | 4 +++-
> 2 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index 3638c77eba26..93027fd96c71 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -58,6 +58,7 @@ mei_hdcp_initiate_session(struct device *dev, struct
> hdcp_port_data *data,
>
> session_init_in.port.integrated_port_type = data->port_type;
> session_init_in.port.physical_port = (u8)data->fw_ddi;
> + session_init_in.port.attached_transcoder = (u8)data->fw_tc;
> session_init_in.protocol = data->protocol;
>
> byte = mei_cldev_send(cldev, (u8 *)_init_in, @@ -127,6
> +128,7 @@ mei_hdcp_verify_receiver_cert_prepare_km(struct device *dev,
>
> verify_rxcert_in.port.integrated_port_type = data->port_type;
> verify_rxcert_in.port.physical_port = (u8)data->fw_ddi;
> + verify_rxcert_in.port.attached_transcoder = (u8)data->fw_tc;
>
> verify_rxcert_in.cert_rx = rx_cert->cert_rx;
> memcpy(verify_rxcert_in.r_rx, _cert->r_rx, HDCP_2_2_RRX_LEN);
> @@ -197,6 +199,7 @@ mei_hdcp_verify_hprime(struct device *dev, struct
> hdcp_port_data *data,
>
> send_hprime_in.port.integrated_port_type = data->port_type;
> send_hprime_in.port.physical_port = (u8)data->fw_ddi;
> + send_hprime_in.port.attached_transcoder = (u8)data->fw_tc;
>
> memcpy(send_hprime_in.h_prime, rx_hprime->h_prime,
> HDCP_2_2_H_PRIME_LEN);
> @@ -254,6 +257,7 @@ mei_hdcp_store_pairing_info(struct device *dev, struct
> hdcp_port_data *data,
>
> pairing_info_in.port.integrated_port_type = data->port_type;
> pairing_info_in.port.physical_port = (u8)data->fw_ddi;
> + pairing_info_in.port.attached_transcoder = (u8)data->fw_tc;
>
> memcpy(pairing_info_in.e_kh_km, pairing_info->e_kh_km,
> HDCP_2_2_E_KH_KM_LEN);
> @@ -312,6 +316,7 @@ mei_hdcp_initiate_locality_check(struct device *dev,
>
> lc_init_in.port.integrated_port_type = data->port_type;
> lc_init_in.port.physical_port = (u8)data->fw_ddi;
> + lc_init_in.port.attached_transcoder = (u8)data->fw_tc;
>
> byte = mei_cldev_send(cldev, (u8 *)_init_in, sizeof(lc_init_in));
> if (byte < 0) {
> @@ -367,6 +372,7 @@ mei_hdcp_verify_lprime(struct device *dev, struct
> hdcp_port_data *data,
>
> verify_lprime_in.port.integrated_port_type = data->port_type;
> verify_lprime_in.port.physical_port = (u8)data->fw_ddi;
> + verify_lprime_in.port.attached_transcoder = (u8)data->fw_tc;
>
> memcpy(verify_lprime_in.l_prime, rx_lprime->l_prime,
> HDCP_2_2_L_PRIME_LEN);
> @@ -424,6 +430,7 @@ static int mei_hdcp_get_session_key(struct device
> *dev,
>
> get_skey_in.port.integrated_port_type = data->port_type;
> get_skey_in.port.physical_port = (u8)data->fw_ddi;
> + get_skey_in.port.attached_transcoder = (u8)data->fw_tc;
>
> byte = mei_cldev_send(cldev, (u8 *)_skey_in, sizeof(get_skey_in));
> if (byte < 0) {
> @@ -488,6 +495,7 @@ mei_hdcp_repeater_check_flow_prepare_ack(struct
> device *dev,
>
> verify_repeater_in.port.integrated_port_type = data->port_type;
> verify_repeater_in.port.physical_port = (u8)data->fw_ddi;
> + verify_repeater_in.port.attached_transcoder = (u8)data->fw_tc;
>
> memcpy(verify_repeater_in.rx_info, rep_topology->rx_info,
> HDCP_2_2_RXINFO_LEN);
> @@ -558,6 +566,7 @@ static int mei_hdcp_verify_mprime(struct device *dev,
>
> verify_mprime_in.port.integrated_port_type = data->port_type;
> verify_mprime_in.port.physical_port = (u8)data->fw_ddi;
> + verify_mprime_in.port.attached_transcoder = (u8)data->fw_tc;
>
> memcpy(verify_mprime_in.m_prime, stream_ready->m_prime,
> HDCP_2_2_MPRIME_LEN);
> @@ -619,6 +628,7 @@ static int mei_hdcp_enable_authentication(struct
> device *dev,
>
> enable_auth_in.port.integrated_port_type = data->port_type;
> enable_auth_in.port.physical_port = (u8)data->fw_ddi;
> + enable_auth_in.port.attached_transcoder = (u8)data->fw_tc;
> enable_auth_in.stream_type = data->streams[0].stream_type;
>
> byte = mei_cldev_send(cldev, (u8 *)_auth_in, @@ -673,6
> +683,7 @@ mei_hdcp_close_session(struct device *dev, struct hdcp_port_data
> *data)
>
> session_close_in.port.integrated_port_type = data->port_type;
> session_close_in.port.physical_port = (u8)data->fw_ddi;
> + session_close_in.port.attached_transcoder = (u8)data->fw_tc;
>
> byte = mei_cldev_send(cldev, (u8 *)_close_in,
>
RE: [PATCH v10 3/6] drm: Extend I915 mei interface for transcoder info
>
> I915 needs to send the index of the transcoder as per ME FW.
>
> To support this, define enum mei_fw_tc and add as a member into the struct
> hdcp_port_data.
>
> v2:
> Typo in commit msg is fixed [Shashank]
>
> Signed-off-by: Ramalingam C
> Acked-by: Jani Nikula
> ---
> include/drm/i915_mei_hdcp_interface.h | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/include/drm/i915_mei_hdcp_interface.h
> b/include/drm/i915_mei_hdcp_interface.h
> index a97acf1c9710..0de629bf2f62 100644
> --- a/include/drm/i915_mei_hdcp_interface.h
> +++ b/include/drm/i915_mei_hdcp_interface.h
> @@ -54,9 +54,21 @@ enum mei_fw_ddi {
> MEI_DDI_RANGE_END = MEI_DDI_A,
> };
>
> +enum mei_fw_tc {
> + MEI_INVALID_TRANSCODER = 0x00, /* Invalid transcoder type */
> + MEI_TC_EDP, /* Transcoder for eDP */
> + MEI_TC_DSI0,/* Transcoder for DSI0 */
> + MEI_TC_DSI1,/* Transcoder for DSI1 */
> + MEI_TC_A = 0x10,/* Transcoder TCA */
> + MEI_TC_B, /* Transcoder TCB */
> + MEI_TC_C, /* Transcoder TCC */
> + MEI_TC_D/* Transcoder TCD */
> +};
You should use kdoc format here, please.
https://www.kernel.org/doc/html/v5.2/doc-guide/kernel-doc.html
Also TCA just means Transcoder A or TC has other meaning?
> +
> /**
> * struct hdcp_port_data - intel specific HDCP port data
> * @fw_ddi: ddi index as per ME FW
> + * @fw_tc: transcoder index as per ME FW
> * @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 @@ -
> 69,6 +81,7 @@ enum mei_fw_ddi {
> */
> struct hdcp_port_data {
> enum mei_fw_ddi fw_ddi;
> + enum mei_fw_tc fw_tc;
> u8 port_type;
> u8 protocol;
> u16 k;
> --
> 2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v10 0/6] drm/i915: Enable HDCP 1.4 and 2.2 on Gen12+
Only files are that are modified in this year should be updated. For example. include/drm/i915_mei_hdcp_interface.h - * Copyright © 2017-2018 Intel Corporation + * Copyright © 2017-2019 Intel Corporation > -Original Message- > From: C, Ramalingam > Sent: Tuesday, August 27, 2019 16:23 > To: Winkler, Tomas > Cc: intel-gfx ; dri-devel de...@lists.freedesktop.org>; Sharma, Shashank > ; Daniel Vetter ; Nikula, Jani > > Subject: Re: [PATCH v10 0/6] drm/i915: Enable HDCP 1.4 and 2.2 on Gen12+ > > On 2019-08-27 at 18:32:13 +0530, Winkler, Tomas wrote: > > > > > Enabling the HDCP1.4 and 2.2 on TGL by supporting the HW block > > > movement from DDI into transcoder. > > > > In some files needs to bump the copyright to 2019. > Tomas, > > I am not aware when a copyright year needs to be bumped, as copyright year > for many I915 files are not latest. > > Any guidelines here would help me to understand. > > Thanks, > -Ram. > > > > > > > > v10: > > > Review comments from shashank addressed > > > > > > Ramalingam C (6): > > > drm/i915: mei_hdcp: I915 sends ddi index as per ME FW > > > drm: Move port definition back to i915 header > > > drm: Extend I915 mei interface for transcoder info > > > misc/mei/hdcp: Fill transcoder index in port info > > > drm/i915/hdcp: update current transcoder into intel_hdcp > > > drm/i915/hdcp: Enable HDCP 1.4 and 2.2 on Gen12+ > > > > > > drivers/gpu/drm/i915/display/intel_bios.h | 1 + > > > drivers/gpu/drm/i915/display/intel_display.h | 18 ++ > > > .../drm/i915/display/intel_display_types.h| 7 + > > > drivers/gpu/drm/i915/display/intel_dp.c | 3 + > > > drivers/gpu/drm/i915/display/intel_dp.h | 1 + > > > drivers/gpu/drm/i915/display/intel_hdcp.c | 212 +- > > > drivers/gpu/drm/i915/display/intel_hdcp.h | 4 + > > > drivers/gpu/drm/i915/display/intel_hdmi.c | 13 +- > > > drivers/gpu/drm/i915/display/intel_hdmi.h | 1 + > > > drivers/gpu/drm/i915/display/intel_hotplug.h | 1 + > > > drivers/gpu/drm/i915/display/intel_sdvo.h | 1 + > > > drivers/gpu/drm/i915/i915_reg.h | 124 +- > > > drivers/misc/mei/hdcp/mei_hdcp.c | 45 ++-- > > > drivers/misc/mei/hdcp/mei_hdcp.h | 16 +- > > > include/drm/i915_drm.h| 18 -- > > > include/drm/i915_mei_hdcp_interface.h | 29 ++- > > > 16 files changed, 372 insertions(+), 122 deletions(-) > > > > > > -- > > > 2.20.1 > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v10 0/6] drm/i915: Enable HDCP 1.4 and 2.2 on Gen12+
> Enabling the HDCP1.4 and 2.2 on TGL by supporting the HW block movement > from DDI into transcoder. In some files needs to bump the copyright to 2019. > > v10: > Review comments from shashank addressed > > Ramalingam C (6): > drm/i915: mei_hdcp: I915 sends ddi index as per ME FW > drm: Move port definition back to i915 header > drm: Extend I915 mei interface for transcoder info > misc/mei/hdcp: Fill transcoder index in port info > drm/i915/hdcp: update current transcoder into intel_hdcp > drm/i915/hdcp: Enable HDCP 1.4 and 2.2 on Gen12+ > > drivers/gpu/drm/i915/display/intel_bios.h | 1 + > drivers/gpu/drm/i915/display/intel_display.h | 18 ++ > .../drm/i915/display/intel_display_types.h| 7 + > drivers/gpu/drm/i915/display/intel_dp.c | 3 + > drivers/gpu/drm/i915/display/intel_dp.h | 1 + > drivers/gpu/drm/i915/display/intel_hdcp.c | 212 +- > drivers/gpu/drm/i915/display/intel_hdcp.h | 4 + > drivers/gpu/drm/i915/display/intel_hdmi.c | 13 +- > drivers/gpu/drm/i915/display/intel_hdmi.h | 1 + > drivers/gpu/drm/i915/display/intel_hotplug.h | 1 + > drivers/gpu/drm/i915/display/intel_sdvo.h | 1 + > drivers/gpu/drm/i915/i915_reg.h | 124 +- > drivers/misc/mei/hdcp/mei_hdcp.c | 45 ++-- > drivers/misc/mei/hdcp/mei_hdcp.h | 16 +- > include/drm/i915_drm.h| 18 -- > include/drm/i915_mei_hdcp_interface.h | 29 ++- > 16 files changed, 372 insertions(+), 122 deletions(-) > > -- > 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v6 2/3] misc/mei_hdcp: Adding the transcoder detail in payload input
>
> ME FW takes the transcoder details for Gen12+ platforms, as HDCP HW block is
> moved to transcoders.
>
> hdcp_port_data is extended with enum transcoder. Payload structure is
> modified and populated from the hdcp_port_data.
>
> Signed-off-by: Ramalingam C
> ---
> drivers/misc/mei/hdcp/mei_hdcp.c | 27 +++
> drivers/misc/mei/hdcp/mei_hdcp.h | 15 ++-
> include/drm/i915_mei_hdcp_interface.h | 2 ++
> 3 files changed, 43 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index c681f6fab342..7efe3b65a986 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -39,6 +39,22 @@ static inline u8 mei_get_ddi_index(enum port port)
> }
> }
>
> +static inline u8 mei_get_tc_type(enum transcoder tc) {
> + switch (tc) {
> + case TRANSCODER_A ... TRANSCODER_D:
> + return (u8)(tc | 0x10);
> + case TRANSCODER_EDP:
> + return TC_EDP;
> + case TRANSCODER_DSI_0:
> + return TC_DSI0;
> + case TRANSCODER_DSI_1:
> + return TC_DSI1;
> + default:
> + return MEI_INVALID_TRANSCODER;
> + }
> +}
> +
> /**
> * mei_hdcp_initiate_session() - Initiate a Wired HDCP2.2 Tx Session in ME FW
> * @dev: device corresponding to the mei_cl_device @@ -70,6 +86,7 @@
> mei_hdcp_initiate_session(struct device *dev, struct hdcp_port_data *data,
>
> session_init_in.port.integrated_port_type = data->port_type;
> session_init_in.port.physical_port = mei_get_ddi_index(data->port);
> + session_init_in.port.attached_transcoder = mei_get_tc_type(data->tc);
> session_init_in.protocol = data->protocol;
>
> byte = mei_cldev_send(cldev, (u8 *)_init_in, @@ -139,6
> +156,7 @@ mei_hdcp_verify_receiver_cert_prepare_km(struct device *dev,
>
> verify_rxcert_in.port.integrated_port_type = data->port_type;
> verify_rxcert_in.port.physical_port = mei_get_ddi_index(data->port);
> + verify_rxcert_in.port.attached_transcoder = mei_get_tc_type(data-
> >tc);
>
> verify_rxcert_in.cert_rx = rx_cert->cert_rx;
> memcpy(verify_rxcert_in.r_rx, _cert->r_rx, HDCP_2_2_RRX_LEN);
> @@ -209,6 +227,7 @@ mei_hdcp_verify_hprime(struct device *dev, struct
> hdcp_port_data *data,
>
> send_hprime_in.port.integrated_port_type = data->port_type;
> send_hprime_in.port.physical_port = mei_get_ddi_index(data->port);
> + send_hprime_in.port.attached_transcoder = mei_get_tc_type(data-
> >tc);
>
> memcpy(send_hprime_in.h_prime, rx_hprime->h_prime,
> HDCP_2_2_H_PRIME_LEN);
> @@ -266,6 +285,7 @@ mei_hdcp_store_pairing_info(struct device *dev, struct
> hdcp_port_data *data,
>
> pairing_info_in.port.integrated_port_type = data->port_type;
> pairing_info_in.port.physical_port = mei_get_ddi_index(data->port);
> + pairing_info_in.port.attached_transcoder = mei_get_tc_type(data->tc);
>
> memcpy(pairing_info_in.e_kh_km, pairing_info->e_kh_km,
> HDCP_2_2_E_KH_KM_LEN);
> @@ -324,6 +344,7 @@ mei_hdcp_initiate_locality_check(struct device *dev,
>
> lc_init_in.port.integrated_port_type = data->port_type;
> lc_init_in.port.physical_port = mei_get_ddi_index(data->port);
> + lc_init_in.port.attached_transcoder = mei_get_tc_type(data->tc);
>
> byte = mei_cldev_send(cldev, (u8 *)_init_in, sizeof(lc_init_in));
> if (byte < 0) {
> @@ -379,6 +400,7 @@ mei_hdcp_verify_lprime(struct device *dev, struct
> hdcp_port_data *data,
>
> verify_lprime_in.port.integrated_port_type = data->port_type;
> verify_lprime_in.port.physical_port = mei_get_ddi_index(data->port);
> + verify_lprime_in.port.attached_transcoder = mei_get_tc_type(data-
> >tc);
>
> memcpy(verify_lprime_in.l_prime, rx_lprime->l_prime,
> HDCP_2_2_L_PRIME_LEN);
> @@ -436,6 +458,7 @@ static int mei_hdcp_get_session_key(struct device
> *dev,
>
> get_skey_in.port.integrated_port_type = data->port_type;
> get_skey_in.port.physical_port = mei_get_ddi_index(data->port);
> + get_skey_in.port.attached_transcoder = mei_get_tc_type(data->tc);
>
> byte = mei_cldev_send(cldev, (u8 *)_skey_in, sizeof(get_skey_in));
> if (byte < 0) {
> @@ -500,6 +523,7 @@ mei_hdcp_repeater_check_flow_prepare_ack(struct
> device *dev,
>
> verify_repeater_in.port.integrated_port_type = data->port_type;
> verify_repeater_in.port.physical_port = mei_get_ddi_index(data-
> >port);
> + verify_repeater_in.port.attached_transcoder =
> +mei_get_tc_type(data->tc);
>
> memcpy(verify_repeater_in.rx_info, rep_topology->rx_info,
> HDCP_2_2_RXINFO_LEN);
> @@ -570,6 +594,7 @@ static int mei_hdcp_verify_mprime(struct device *dev,
>
> verify_mprime_in.port.integrated_port_type = data->port_type;
> verify_mprime_in.port.physical_port = mei_get_ddi_index(data->port);
> +
RE: [PATCH v6 1/3] drm/i915: enum transcoder and pipe are moved into i915_drm.h
>
> For the reusability of the enum transcoder and enum pipe in other driver
> modules (like mei_hdcp), enum port definition is moved from I915 local header
> intel_display.h to drm/i915_drm.h
Don't you need to name space those definitions in the global space, I guess
there are a lot of 'pipe' variables and definitions you can conflict with.
I guess it should be enum i915_pipe, etc.
Thanks
Tomas
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/display/intel_display.h | 44 ---
> include/drm/i915_drm.h | 46
> 2 files changed, 46 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.h
> b/drivers/gpu/drm/i915/display/intel_display.h
> index e57e6969051d..56f3d9073159 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.h
> +++ b/drivers/gpu/drm/i915/display/intel_display.h
> @@ -71,50 +71,6 @@ enum i915_gpio {
> GPIOO,
> };
>
> -/*
> - * Keep the pipe enum values fixed: the code assumes that PIPE_A=0, the
> - * rest have consecutive values and match the enum values of transcoders
> - * with a 1:1 transcoder -> pipe mapping.
> - */
> -enum pipe {
> - INVALID_PIPE = -1,
> -
> - PIPE_A = 0,
> - PIPE_B,
> - PIPE_C,
> - PIPE_D,
> - _PIPE_EDP,
> -
> - I915_MAX_PIPES = _PIPE_EDP
> -};
> -
> -#define pipe_name(p) ((p) + 'A')
> -
> -enum transcoder {
> - /*
> - * The following transcoders have a 1:1 transcoder -> pipe mapping,
> - * keep their values fixed: the code assumes that TRANSCODER_A=0,
> the
> - * rest have consecutive values and match the enum values of the pipes
> - * they map to.
> - */
> - TRANSCODER_A = PIPE_A,
> - TRANSCODER_B = PIPE_B,
> - TRANSCODER_C = PIPE_C,
> - TRANSCODER_D = PIPE_D,
> -
> - /*
> - * The following transcoders can map to any pipe, their enum value
> - * doesn't need to stay fixed.
> - */
> - TRANSCODER_EDP,
> - TRANSCODER_DSI_0,
> - TRANSCODER_DSI_1,
> - TRANSCODER_DSI_A = TRANSCODER_DSI_0,/* legacy DSI */
> - TRANSCODER_DSI_C = TRANSCODER_DSI_1,/* legacy DSI */
> -
> - I915_MAX_TRANSCODERS
> -};
> -
> static inline const char *transcoder_name(enum transcoder transcoder) {
> switch (transcoder) {
> diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h index
> 23274cf92712..b0779b8267b9 100644
> --- a/include/drm/i915_drm.h
> +++ b/include/drm/i915_drm.h
> @@ -118,4 +118,50 @@ enum port {
>
> #define port_name(p) ((p) + 'A')
>
> +/*
> + * Keep the pipe enum values fixed: the code assumes that PIPE_A=0, the
> + * rest have consecutive values and match the enum values of
> +transcoders
> + * with a 1:1 transcoder -> pipe mapping.
> + */
> +enum pipe {
> + INVALID_PIPE = -1,
> +
> + PIPE_A = 0,
> + PIPE_B,
> + PIPE_C,
> + PIPE_D,
> + _PIPE_EDP,
> +
> + I915_MAX_PIPES = _PIPE_EDP
> +};
> +
> +#define pipe_name(p) ((p) + 'A')
> +
> +enum transcoder {
> + INVALID_TRANSCODER = -1,
> +
> + /*
> + * The following transcoders have a 1:1 transcoder -> pipe mapping,
> + * keep their values fixed: the code assumes that TRANSCODER_A=0,
> the
> + * rest have consecutive values and match the enum values of the pipes
> + * they map to.
> + */
> + TRANSCODER_A = PIPE_A,
> + TRANSCODER_B = PIPE_B,
> + TRANSCODER_C = PIPE_C,
> + TRANSCODER_D = PIPE_D,
> +
> + /*
> + * The following transcoders can map to any pipe, their enum value
> + * doesn't need to stay fixed.
> + */
> + TRANSCODER_EDP,
> + TRANSCODER_DSI_0,
> + TRANSCODER_DSI_1,
> + TRANSCODER_DSI_A = TRANSCODER_DSI_0,/* legacy DSI */
> + TRANSCODER_DSI_C = TRANSCODER_DSI_1,/* legacy DSI */
> +
> + I915_MAX_TRANSCODERS
> +};
> +
> #endif /* _I915_DRM_H_ */
> --
> 2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v15 00/16] drm/i915: Implement HDCP2.2
> On Mon, Feb 25, 2019 at 05:12:09AM +, C, Ramalingam wrote: > > Tomas, > > > > Lkp issue is complaining about the header > > drm/i915_mei_hdcp_interface.h, Which is already merged in drm-tip > > through below commit. So don’t think this is a genuine issue. May be > > this build was tried in different tree, where this commit is not added yet? > > Yeah our topic trees aren't pushed into linux-next, 0day can't find them. > Usually it will then fail to apply (and in that case it doesn't complain), > but it > does complain if everything applies but doesn't build. > -Daniel > > > > > commit 1626eab70ebc61d015e69a4bc3479d9228539343 > > Author: Ramalingam C > > Date: Fri Feb 15 14:04:58 2019 +0530 > > > > drm/i915: header for i915 - MEI_HDCP interface > > > > v15 is now part of github. I'm okay to go with this. Thanks Tomas > > > > Best Regards, > > Ramalingam C > > > > > > > -Original Message- > > > From: Winkler, Tomas > > > Sent: Monday, February 25, 2019 1:45 AM > > > To: C, Ramalingam ; > > > intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; > > > daniel.vet...@ffwll.ch; Shankar, Uma > > > Subject: RE: [PATCH v15 00/16] drm/i915: Implement HDCP2.2 > > > > > > Have you fixed the lkp issue? > > > I didn't see you pushed the code to github. > > > Thanks > > > > > > > > > > -Original Message- > > > > From: C, Ramalingam > > > > Sent: Sunday, February 24, 2019 18:33 > > > > To: intel-...@lists.freedesktop.org; > > > > dri-devel@lists.freedesktop.org; daniel.vet...@ffwll.ch; Winkler, > > > > Tomas ; Shankar, Uma > > > > > > > > Subject: Re: [PATCH v15 00/16] drm/i915: Implement HDCP2.2 > > > > > > > > Tomas, > > > > > > > > Could you please help to review and give final "Go" for the series? > > > > > > > > Thanks > > > > --Ram. > > > > > > > > On 2/21/2019 11:41 PM, Ramalingam C wrote: > > > > > This series enables the HDCP2.2 Type 0 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 streams. > > > > > > > > > > Test-with: > > > > > <1549566452-30175-1-git-send-email-ramalinga...@intel.com> > > > > > So that CP will be tested on BAT machine too. > > > > > > > > > > Major changes in v15 > > > > >- All I915 patches are merged. So dropping them. > > > > >- Few minor suggestions are incorporated at mei changes. > > > > > > > > > > To ease the review process, series is hosted at > > > > > https://github.com/ramalingampc2008/drm-tip.git hdcp2_2_v15 > > > > > > > > > > Ramalingam C (15): > > > > >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 > > > &
RE: [PATCH v15 00/16] drm/i915: Implement HDCP2.2
Have you fixed the lkp issue? I didn't see you pushed the code to github. Thanks > -Original Message- > From: C, Ramalingam > Sent: Sunday, February 24, 2019 18:33 > To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; > daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar, > Uma > Subject: Re: [PATCH v15 00/16] drm/i915: Implement HDCP2.2 > > Tomas, > > Could you please help to review and give final "Go" for the series? > > Thanks > --Ram. > > On 2/21/2019 11:41 PM, Ramalingam C wrote: > > This series enables the HDCP2.2 Type 0 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 streams. > > > > Test-with: <1549566452-30175-1-git-send-email-ramalinga...@intel.com> > > So that CP will be tested on BAT machine too. > > > > Major changes in v15 > >- All I915 patches are merged. So dropping them. > >- Few minor suggestions are incorporated at mei changes. > > > > To ease the review process, series is hosted at > > https://github.com/ramalingampc2008/drm-tip.git hdcp2_2_v15 > > > > Ramalingam C (15): > >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 > >FOR_TEST_ONLY: i915/Kconfig: Select mei_hdcp by I915 > > > > Tomas Winkler (1): > >mei: bus: whitelist hdcp client > > > > drivers/misc/mei/Kconfig | 11 + > > drivers/misc/mei/Makefile| 2 + > > drivers/misc/mei/bus-fixup.c | 16 + > > drivers/misc/mei/hdcp/Makefile | 7 + > > drivers/misc/mei/hdcp/mei_hdcp.c | 849 > +++ > > drivers/misc/mei/hdcp/mei_hdcp.h | 377 + > > 6 files changed, 1262 insertions(+) > > 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 > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v14 27/33] misc/mei/hdcp: Prepare Session Key
>
> 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]
> v9:
> renamed func as mei_hdcp_* [Tomas]
> Inline function is defined for DDI index [Tomas]
> v10:
> K-Doc fix. [Tomas]
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Uma Shankar
> Acked-by: Tomas Winkler
LGTM
> ---
> 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 869a6f22f68d..fe5070f901e8 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -409,6 +409,63 @@ mei_hdcp_verify_lprime(struct device *dev, struct
> hdcp_port_data *data,
> return 0;
> }
>
> +/**
> + * mei_hdcp_get_session_key() - Prepare SKE_Send_Eks.
> + * @dev: device corresponding to the mei_cl_device
> + * @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_hdcp_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 = mei_get_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,
> @@ -419,7 +476,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
> .store_pairing_info = mei_hdcp_store_pairing_info,
> .initiate_locality_check = mei_hdcp_initiate_locality_check,
> .verify_lprime = mei_hdcp_verify_lprime,
> - .get_session_key = NULL,
> + .get_session_key = mei_hdcp_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
RE: [PATCH v14 31/33] misc/mei/hdcp: Closing wired HDCP2.2 Tx Session
> 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]
> v9:
> renamed func as mei_hdcp_* [Tomas]
> Inline function is defined for DDI index [Tomas]
> v10:
> K-Doc fix. [Tomas]
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Uma Shankar
> Acked-by: Tomas Winkler
LGTM
> ---
> 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 d8e04e0621a1..2afc7d31dacc 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -658,6 +658,59 @@ static int mei_hdcp_enable_authentication(struct
> device *dev,
> return 0;
> }
>
> +/**
> + * mei_hdcp_close_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
> + * @data: Intel HW specific hdcp data
> + *
> + * Return: 0 on Success, <0 on Failure
> + */
> +static int
> +mei_hdcp_close_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 = mei_get_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,
> @@ -673,7 +726,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
> mei_hdcp_repeater_check_flow_prepare_ack,
> .verify_mprime = mei_hdcp_verify_mprime,
> .enable_hdcp_authentication = mei_hdcp_enable_authentication,
> - .close_hdcp_session = NULL,
> + .close_hdcp_session = mei_hdcp_close_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
RE: [PATCH v14 30/33] misc/mei/hdcp: Enabling the HDCP authentication
>
> 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]
> v9:
> renamed func as mei_hdcp_* [Tomas]
> Inline function is defined for DDI index [Tomas]
> v10:
> K-Doc fix. [Tomas]
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Uma Shankar
> Acked-by: Tomas Winkler
LGTM
> ---
> 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 721376fc9bf1..d8e04e0621a1 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -605,6 +605,59 @@ static int mei_hdcp_verify_mprime(struct device
> *dev,
> return 0;
> }
>
> +/**
> + * mei_hdcp_enable_authentication() - Mark a port as authenticated
> + * through ME FW
> + * @dev: device corresponding to the mei_cl_device
> + * @data: Intel HW specific hdcp data
> + *
> + * Return: 0 on Success, <0 on Failure
> + */
> +static int mei_hdcp_enable_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 = mei_get_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,
> @@ -619,7 +672,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
> .repeater_check_flow_prepare_ack =
> mei_hdcp_repeater_check_flow_prepare_ack,
> .verify_mprime = mei_hdcp_verify_mprime,
> - .enable_hdcp_authentication = NULL,
> + .enable_hdcp_authentication = mei_hdcp_enable_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
RE: [PATCH v14 28/33] misc/mei/hdcp: Repeater topology verification and ack
> ack
>
> 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]
> v9:
> renamed func as mei_hdcp_* [Tomas]
> Inline function is defined for DDI index [Tomas]
> v10:
> K-Doc fix. [Tomas]
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Uma Shankar
> Acked-by: Tomas Winkler
LGTM
> ---
> drivers/misc/mei/hdcp/mei_hdcp.c | 77
> +++-
> 1 file changed, 76 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index fe5070f901e8..c06a9805ac85 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -466,6 +466,80 @@ static int mei_hdcp_get_session_key(struct device
> *dev,
> return 0;
> }
>
> +/**
> + * mei_hdcp_repeater_check_flow_prepare_ack() - Validate the Downstream
> +topology
> + * and prepare rep_ack.
> + * @dev: device corresponding to the mei_cl_device
> + * @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_hdcp_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 = mei_get_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,
> @@ -477,7 +551,8 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
> .initiate_locality_check = mei_hdcp_initiate_locality_check,
> .verify_lprime = mei_hdcp_verify_lprime,
> .get_session_key = mei_hdcp_get_session_key,
> - .repeater_check_flow_prepare_ack = NULL,
> + .repeater_check_flow_prepare_ack =
> + mei_hdcp_repeater_check_flow_prepare_ack,
> .verify_mprime = NULL,
> .enable_hdcp_authentication = NULL,
> .close_hdcp_session =
RE: [PATCH v14 19/33] misc/mei/hdcp: Client driver for HDCP application
> > ME FW 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.2 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] > v7: > %s/UUID_LE/GUID_INIT [Tomas] > GPL Ver is 2.0 than 2.0+ [Tomas] > > Signed-off-by: Ramalingam C > Signed-off-by: Tomas Winkler > Acked-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 | 64 > > 4 files changed, 80 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..64a7b3483895 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 platforms. Usually we need around 4 lines of doc, When this should be selected? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v14 24/33] misc/mei/hdcp: Store the HDCP Pairing info
>
> 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.
> v9:
> renamed func as mei_hdcp_* [Tomas]
> Inline function is defined for DDI index [Tomas]
> v10:
> K-Doc fix. [Tomas]
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Uma Shankar
> Acked-by: Tomas Winkler
LGTM
> ---
> 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 0a4087a2efd5..1f5514244716 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -238,6 +238,64 @@ mei_hdcp_verify_hprime(struct device *dev, struct
> hdcp_port_data *data,
> return 0;
> }
>
> +/**
> + * mei_hdcp_store_pairing_info() - Store pairing info received at ME FW
> + * @dev: device corresponding to the mei_cl_device
> + * @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_hdcp_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 = mei_get_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,
> @@ -245,7 +303,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
> .verify_receiver_cert_prepare_km =
> mei_hdcp_verify_receiver_cert_prepare_km,
> .verify_hprime = mei_hdcp_verify_hprime,
> - .store_pairing_info = NULL,
> + .store_pairing_info = mei_hdcp_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
RE: [PATCH v14 29/33] misc/mei/hdcp: Verify M_prime
>
> 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.
> v9:
> renamed func as mei_hdcp_* [Tomas]
> Inline function is defined for DDI index [Tomas]
> v10:
> K-Doc fix. [Tomas]
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Uma Shankar
> Acked-by: Tomas Winkler
> ---
> +
> + verify_mprime_in.k = __swab16(data->k);
> +
cpu_to_be16(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;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v14 25/33] misc/mei/hdcp: Initiate Locality check
> 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]
> v9:
> renamed func as mei_hdcp_* [Tomas]
> Inline function is defined for DDI index [Tomas]
> v10:
> K-Doc fix. [Tomas]
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Uma Shankar
> Acked-by: Tomas Winkler
LGTM
> ---
> 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 1f5514244716..29ef61fd21d2 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -296,6 +296,61 @@ mei_hdcp_store_pairing_info(struct device *dev,
> struct hdcp_port_data *data,
> return 0;
> }
>
> +/**
> + * mei_hdcp_initiate_locality_check() - Prepare LC_Init
> + * @dev: device corresponding to the mei_cl_device
> + * @data: Intel HW specific hdcp data
> + * @lc_init_data: LC_Init msg output
> + *
> + * Return: 0 on Success, <0 on Failure
> + */
> +static int
> +mei_hdcp_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 = mei_get_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,
> @@ -304,7 +359,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
> mei_hdcp_verify_receiver_cert_prepare_km,
> .verify_hprime = mei_hdcp_verify_hprime,
> .store_pairing_info = mei_hdcp_store_pairing_info,
> - .initiate_locality_check = NULL,
> + .initiate_locality_check = mei_hdcp_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
RE: [PATCH v14 26/33] misc/mei/hdcp: Verify L_prime
> 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.
> v9:
> renamed func as mei_hdcp_* [Tomas]
> Inline function is defined for DDI index [Tomas]
> v10:
> K-Doc fix. [Tomas]
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Uma Shankar
> Acked-by: Tomas Winkler
LGTM
> ---
> 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 29ef61fd21d2..869a6f22f68d 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -351,6 +351,64 @@ mei_hdcp_initiate_locality_check(struct device *dev,
> return 0;
> }
>
> +/**
> + * mei_hdcp_verify_lprime() - Verify lprime.
> + * @dev: device corresponding to the mei_cl_device
> + * @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_hdcp_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 = mei_get_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,
> @@ -360,7 +418,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
> .verify_hprime = mei_hdcp_verify_hprime,
> .store_pairing_info = mei_hdcp_store_pairing_info,
> .initiate_locality_check = mei_hdcp_initiate_locality_check,
> - .verify_lprime = NULL,
> + .verify_lprime = mei_hdcp_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
RE: [PATCH v14 22/33] misc/mei/hdcp: Verify Receiver Cert and prepare km
> 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.
> v9:
> renamed func as mei_hdcp_* [Tomas]
> Inline function is defined for DDI index [Tomas]
> v10:
> Fixed the conversion of u8 to bool [Tomas]
> K-Doc fix [Tomas]
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Uma Shankar
> Acked-by: Tomas Winkler
LGTM
> ---
> drivers/misc/mei/hdcp/mei_hdcp.c | 83
> +++-
> 1 file changed, 82 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index 952bae79dd02..922c6a76bb9f 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -102,11 +102,92 @@ mei_hdcp_initiate_session(struct device *dev, struct
> hdcp_port_data *data,
> return 0;
> }
>
> +/**
> + * mei_hdcp_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
> + * @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_hdcp_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 = mei_get_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
RE: [PATCH v14 23/33] misc/mei/hdcp: Verify H_prime
> 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.
> v9:
> renamed func as mei_hdcp_* [Tomas]
> Inline function is defined for DDI index [Tomas]
> v10:
> K-Doc fix. [Tomas]
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Uma Shankar
> Acked-by: Tomas Winkler
LGTM
> ---
> 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 922c6a76bb9f..0a4087a2efd5 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -182,13 +182,69 @@ mei_hdcp_verify_receiver_cert_prepare_km(struct
> device *dev,
> return 0;
> }
>
> +/**
> + * mei_hdcp_verify_hprime() - Verify AKE_Send_H_prime at ME FW.
> + * @dev: device corresponding to the mei_cl_device
> + * @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_hdcp_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 = mei_get_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_hdcp_initiate_session,
> .verify_receiver_cert_prepare_km =
> mei_hdcp_verify_receiver_cert_prepare_km,
> - .verify_hprime = NULL,
> + .verify_hprime = mei_hdcp_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
RE: [PATCH v14 21/33] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session
> 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.
> v9:
> s/mei_hdcp_ddi/mei_fw_ddi
> s/i915_port/mei_i915_port [Tomas]
> renamed func as mei_hdcp_* [Tomas]
> Instead of macro, inline func for ddi index is used. [Tomas]
> v10:
> Switch case for the coversion between i915_port to mei_ddi [Tomas]
> Kernel doc fix.
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Uma Shankar
Signed-off-by: Tomas Winkler
> ---
> drivers/misc/mei/hdcp/mei_hdcp.c | 94
>
> drivers/misc/mei/hdcp/mei_hdcp.h | 11 +
> 2 files changed, 105 insertions(+)
>
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index 8df069c1b0cc..952bae79dd02 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -23,6 +23,100 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
> +
> +#include "mei_hdcp.h"
> +
> +static inline u8 mei_get_ddi_index(enum port port) {
> + switch (port) {
> + case PORT_A:
> + return MEI_DDI_A;
> + case PORT_B ... PORT_F:
> + return (u8)port;
> + default:
> + return MEI_DDI_INVALID_PORT;
> + }
> +}
> +
> +/**
> + * mei_hdcp_initiate_session() - Initiate a Wired HDCP2.2 Tx Session in
> +ME FW
> + * @dev: device corresponding to the mei_cl_device
> + * @data: Intel HW specific hdcp data
> + * @ake_data: AKE_Init msg output.
> + *
> + * Return: 0 on Success, <0 on Failure.
> + */
> +static int
> +mei_hdcp_initiate_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 = mei_get_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_hdcp_initiate_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 582a7e27ae29..1eca72a9c1c2 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.h
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.h
> @@ -363,4 +363,15 @@
RE: [PATCH v14 23/33] misc/mei/hdcp: Verify H_prime
>
> 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.
> v9:
> renamed func as mei_hdcp_* [Tomas]
> Inline function is defined for DDI index [Tomas]
> v10:
> K-Doc fix. [Tomas]
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Uma Shankar
> Acked-by: Tomas Winkler
LGTM
> ---
> 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 922c6a76bb9f..0a4087a2efd5 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -182,13 +182,69 @@ mei_hdcp_verify_receiver_cert_prepare_km(struct
> device *dev,
> return 0;
> }
>
> +/**
> + * mei_hdcp_verify_hprime() - Verify AKE_Send_H_prime at ME FW.
> + * @dev: device corresponding to the mei_cl_device
> + * @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_hdcp_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 = mei_get_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_hdcp_initiate_session,
> .verify_receiver_cert_prepare_km =
> mei_hdcp_verify_receiver_cert_prepare_km,
> - .verify_hprime = NULL,
> + .verify_hprime = mei_hdcp_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
RE: [PATCH v14 20/33] misc/mei/hdcp: Define ME FW interface for HDCP2.2
>
> 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 Acked-by Tomas
> Winkler
> ---
> 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 ..582a7e27ae29
> --- /dev/null
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.h
> @@ -0,0 +1,366 @@
> +/* SPDX-License-Identifier: (GPL-2.0+) */
> +/*
> + * Copyright © 2017-2018 Intel Corporation
2019
> + *
> + * 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,
> +
> +
RE: [PATCH v14 32/33] misc/mei/hdcp: Component framework for I915 Interface
>
> 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.
> v8:
> master comp is added to be matched with i915 subcomponent [daniel]
> v9:
> only comp_master is set and retrieved as driver_data [Daniel]
> Reviewed-by Daniel.
> v10:
> small corrections at probe [Tomas]
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Daniel Vetter
> ---
> drivers/misc/mei/hdcp/mei_hdcp.c | 82
> +++-
> 1 file changed, 80 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index 2afc7d31dacc..ad55b41550d6 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -23,6 +23,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include @@ -711,8 +712,7 @@
> mei_hdcp_close_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 = {
Should be 'const' too.
> .owner = THIS_MODULE,
> .initiate_hdcp2_session = mei_hdcp_initiate_session,
> .verify_receiver_cert_prepare_km =
> @@ -729,20 +729,98 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
> .close_hdcp_session = mei_hdcp_close_session, };
>
> +static int mei_component_master_bind(struct device *dev) {
> + struct mei_cl_device *cldev = to_mei_cl_device(dev);
> + struct i915_hdcp_comp_master *comp_master =
> +
> mei_cldev_get_drvdata(cldev);
> + int ret;
> +
> + dev_info(dev, "%s\n", __func__);
Need change this to dev_dbg() it will pollute log
> + comp_master->ops = _hdcp_ops;
> + comp_master->mei_dev = dev;
> + ret = component_bind_all(dev, comp_master);
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
> +
> +static void mei_component_master_unbind(struct device *dev) {
> + struct mei_cl_device *cldev = to_mei_cl_device(dev);
> + struct i915_hdcp_comp_master *comp_master =
> +
> mei_cldev_get_drvdata(cldev);
> +
> + dev_info(dev, "%s\n", __func__);
> + component_unbind_all(dev, comp_master); }
> +
> +static const struct component_master_ops mei_component_master_ops = {
> + .bind = mei_component_master_bind,
> + .unbind = mei_component_master_unbind, };
> +
> +static int mei_hdcp_component_match(struct device *dev, int subcomponent,
> + void *data)
> +{
> + return !strcmp(dev->driver->name, "i915") &&
> +subcomponent == I915_COMPONENT_HDCP; }
> +
> static int mei_hdcp_probe(struct mei_cl_device *cldev,
> const struct mei_cl_device_id *id) {
> + struct i915_hdcp_comp_master *comp_master;
> + struct component_match *master_match;
> int ret;
>
> ret = mei_cldev_enable(cldev);
> if (ret < 0)
> dev_err(>dev, "mei_cldev_enable Failed. %d\n", ret);
If this is not a fatal condition than should not print in dev_err()
>
> + comp_master = kzalloc(sizeof(*comp_master), GFP_KERNEL);
> + if (!comp_master) {
> + ret = -ENOMEM;
> + goto err_exit;
> + }
> +
> + master_match = NULL;
> + component_match_add_typed(>dev, _match,
> + mei_hdcp_component_match,
> comp_master);
> + if (IS_ERR_OR_NULL(master_match)) {
> + ret = -ENOMEM;
> + goto err_exit;
> + }
> +
> + mei_cldev_set_drvdata(cldev, comp_master);
> + ret = component_master_add_with_match(>dev,
> + _component_master_ops,
> + master_match);
> + if (ret < 0) {
> + dev_err(>dev, "Master comp add failed %d\n", ret);
> + goto err_exit;
> + }
> +
> + return 0;
> +
> +err_exit:
> + mei_cldev_set_drvdata(cldev, NULL);
> + kfree(comp_master);
> + mei_cldev_disable(cldev);
> +
> return ret;
> }
>
> static int mei_hdcp_remove(struct mei_cl_device *cldev) {
> + struct i915_hdcp_comp_master *comp_master =
> +
> mei_cldev_get_drvdata(cldev);
> +
> + component_master_del(>dev, _component_master_ops);
> + kfree(comp_master);
> + mei_cldev_set_drvdata(cldev, NULL);
> +
> return mei_cldev_disable(cldev);
> }
>
> --
> 2.7.4
___
dri-devel mailing
RE: [PATCH v12 32/38] misc/mei/hdcp: Verify M_prime
>
> 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.
> v9:
> renamed func as mei_hdcp_* [Tomas]
> Inline function is defined for DDI index [Tomas]
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Uma Shankar
> Acked-by: Tomas Winkler
> ---
> drivers/misc/mei/hdcp/mei_hdcp.c | 67
> +++-
> 1 file changed, 66 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index 6cd76b3bcaea..7d0562c2a773 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -535,6 +535,71 @@ mei_hdcp_repeater_check_flow_prepare_ack(struct
> device *dev,
> return 0;
> }
>
> +/**
> + * mei_hdcp_verify_mprime() - Verify mprime.
> + * @dev: device corresponding to the mei_cl_device
> + * @hdcp_data: Intel HW specific hdcp data
This should be @data across all the functions.
> + * @stream_ready: RepeaterAuth_Stream_Ready msg for ME FW verification.
> + *
> + * Return: 0 on Success, <0 on Failure
> + */
> +static int mei_hdcp_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 = mei_get_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,
> @@ -548,7 +613,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
> .get_session_key = mei_hdcp_get_session_key,
> .repeater_check_flow_prepare_ack =
> mei_hdcp_repeater_check_flow_prepare_ack,
> - .verify_mprime = NULL,
> + .verify_mprime = mei_hdcp_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
RE: [PATCH v12 24/38] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session
>
>
>
> On 2/10/2019 1:55 PM, Winkler, Tomas wrote:
> >> On 2/9/2019 9:39 PM, Winkler, Tomas wrote:
> >>>> 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.
> >>>> v9:
> >>>> s/mei_hdcp_ddi/mei_fw_ddi
> >>>> s/i915_port/mei_i915_port [Tomas]
> >>>> renamed func as mei_hdcp_* [Tomas]
> >>>> Instead of macro, inline func for ddi index is used. [Tomas]
> >>>>
> >>>> Signed-off-by: Ramalingam C
> >>>> Reviewed-by: Uma Shankar
> >>>> Acked-by: Tomas Winkler
> >>>> ---
> >>>>drivers/misc/mei/hdcp/mei_hdcp.c | 89
> >>>>
> >>>>drivers/misc/mei/hdcp/mei_hdcp.h | 23 +++
> >>>>2 files changed, 112 insertions(+)
> >>>>
> >>>> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> >>>> b/drivers/misc/mei/hdcp/mei_hdcp.c
> >>>> index 8df069c1b0cc..56d3ac1e6831 100644
> >>>> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> >>>> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> >>>> @@ -23,6 +23,95 @@
> >>>>#include
> >>>>#include
> >>>>#include
> >>>> +#include
> >>>> +#include
> >>>> +#include
> >>>> +
> >>>> +#include "mei_hdcp.h"
> >>>> +
> >>>> +static inline u8 mei_get_ddi_index(short int port) {
> >>>> +enum mei_i915_port i915_port = (enum mei_i915_port)port;
> >>>> +
> >>>> +return (u8)(i915_port == PORT_A ? MEI_DDI_A : i915_port); }
> >>>> +
> >>> Still the same code I haven't Acked that patch.
> >> Sorry. I will remove the ack part.
> >>
> >> I prefer this approach as it is not so complicated stuff here. still
> >> if you insist I will use switch case.
> > Yes, I believe that the translation should be understood.
> > This function should returns
> > MEI_DDI_XXX only (it could be u8)
> > It's by accident that MEI_DDI_B equals PORT_B etc.
> > Please also remove dual enum i915_port and eum port as well.
> this will do?
> static inline u8 mei_get_ddi_index(short int port) {
> switch (port) {
> case PORT_A:
> return (u8)MEI_DDI_A;
> case PORT_B:
> return (u8)MEI_DDI_B;
> case PORT_C:
> return (u8)MEI_DDI_C;
> case PORT_D:
> return (u8)MEI_DDI_D;
> case PORT_E:
> return (u8)MEI_DDI_E;
> case PORT_F:
> return (u8)MEI_DDI_F;
> default:
> return (u8)MEI_DDI_INVALID_PORT;
> }
> }
You can drop (u8)
>
+ switch (port) {
+ case PORT_A:
+ return MEI_DDI_A;
+ case PORT_B:
+ return MEI_DDI_B;
+ case PORT_C:
+ return MEI_DDI_C;
+ case PORT_D:
+ return MEI_DDI_D;
+ case PORT_E:
+ return MEI_DDI_E;
+ case PORT_F:
+ return MEI_DDI_F;
+ default:
+ return MEI_DDI_INVALID_PORT;
>
> -Ram
>
> > Thanks
> > Tomas
> >
> >> Thanks
> >> --Ram
> >>
> >>> Thanks
> >>> Tomas
> >>>
> >>>
> >>>> +/**
RE: [PATCH v12 24/38] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session
>
> On 2/9/2019 9:39 PM, Winkler, Tomas wrote:
> >> 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.
> >> v9:
> >>s/mei_hdcp_ddi/mei_fw_ddi
> >>s/i915_port/mei_i915_port [Tomas]
> >>renamed func as mei_hdcp_* [Tomas]
> >>Instead of macro, inline func for ddi index is used. [Tomas]
> >>
> >> Signed-off-by: Ramalingam C
> >> Reviewed-by: Uma Shankar
> >> Acked-by: Tomas Winkler
> >> ---
> >> drivers/misc/mei/hdcp/mei_hdcp.c | 89
> >>
> >> drivers/misc/mei/hdcp/mei_hdcp.h | 23 +++
> >> 2 files changed, 112 insertions(+)
> >>
> >> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> >> b/drivers/misc/mei/hdcp/mei_hdcp.c
> >> index 8df069c1b0cc..56d3ac1e6831 100644
> >> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> >> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> >> @@ -23,6 +23,95 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >> +#include
> >> +#include
> >> +
> >> +#include "mei_hdcp.h"
> >> +
> >> +static inline u8 mei_get_ddi_index(short int port) {
> >> + enum mei_i915_port i915_port = (enum mei_i915_port)port;
> >> +
> >> + return (u8)(i915_port == PORT_A ? MEI_DDI_A : i915_port); }
> >> +
> > Still the same code I haven't Acked that patch.
> Sorry. I will remove the ack part.
>
> I prefer this approach as it is not so complicated stuff here. still if you
> insist I
> will use switch case.
Yes, I believe that the translation should be understood.
This function should returns
MEI_DDI_XXX only (it could be u8)
It's by accident that MEI_DDI_B equals PORT_B etc.
Please also remove dual enum i915_port and eum port as well.
Thanks
Tomas
>
> Thanks
> --Ram
>
> > Thanks
> > Tomas
> >
> >
> >> +/**
> >> + * mei_hdcp_initiate_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_hdcp_initiate_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 = mei_get_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) {
> >> +
RE: [PATCH v12 24/38] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session
> 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.
> v9:
> s/mei_hdcp_ddi/mei_fw_ddi
> s/i915_port/mei_i915_port [Tomas]
> renamed func as mei_hdcp_* [Tomas]
> Instead of macro, inline func for ddi index is used. [Tomas]
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Uma Shankar
> Acked-by: Tomas Winkler
> ---
> drivers/misc/mei/hdcp/mei_hdcp.c | 89
>
> drivers/misc/mei/hdcp/mei_hdcp.h | 23 +++
> 2 files changed, 112 insertions(+)
>
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index 8df069c1b0cc..56d3ac1e6831 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -23,6 +23,95 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
> +
> +#include "mei_hdcp.h"
> +
> +static inline u8 mei_get_ddi_index(short int port) {
> + enum mei_i915_port i915_port = (enum mei_i915_port)port;
> +
> + return (u8)(i915_port == PORT_A ? MEI_DDI_A : i915_port); }
> +
Still the same code I haven't Acked that patch.
Thanks
Tomas
> +/**
> + * mei_hdcp_initiate_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_hdcp_initiate_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 = mei_get_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_hdcp_initiate_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 582a7e27ae29..28686f2ae88c 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.h
> +++
RE: [PATCH v12 21/38] mei: me: add ice lake point device id.
> > On Sat, Feb 09, 2019 at 12:42:50PM +0530, Ramalingam C wrote: > > From: Tomas Winkler > > > > Add icelake mei device id. > > > > Cc: > > Signed-off-by: Tomas Winkler > > Signed-off-by: Greg Kroah-Hartman > > Cherry-picked from > > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git > > char-misc-linus > > --- > > drivers/misc/mei/hw-me-regs.h | 2 ++ > > drivers/misc/mei/pci-me.c | 2 ++ > > 2 files changed, 4 insertions(+) > > Why are you sending us patches that are already applied? They're unslinging it for GFX CI so they need it in their queue, it was not merged into the master branch at the time. Thanks Tomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v11 39/42] misc/mei/hdcp: Component framework for I915 Interface
> 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.
> v8:
> master comp is added to be matched with i915 subcomponent [daniel]
> v9:
> only comp_master is set and retrieved as driver_data [Daniel]
> Reviewed-by Daniel.
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Daniel Vetter
> ---
> drivers/misc/mei/hdcp/mei_hdcp.c | 83
> +++-
> 1 file changed, 81 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index 615eed149837..beba6fb4d2e2 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -23,6 +23,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include @@ -706,8 +707,7 @@
> mei_hdcp_close_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_hdcp_initiate_session,
> .verify_receiver_cert_prepare_km =
> @@ -724,20 +724,99 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
> .close_hdcp_session = mei_hdcp_close_session, };
>
> +static int mei_component_master_bind(struct device *dev) {
> + struct mei_cl_device *cldev = to_mei_cl_device(dev);
> + struct i915_hdcp_comp_master *comp_master =
> +
> mei_cldev_get_drvdata(cldev);
> + int ret;
> +
> + dev_info(dev, "%s\n", __func__);
> + comp_master->ops = _hdcp_ops;
> + comp_master->mei_dev = dev;
> + ret = component_bind_all(dev, comp_master);
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
> +
> +static void mei_component_master_unbind(struct device *dev) {
> + struct mei_cl_device *cldev = to_mei_cl_device(dev);
> + struct i915_hdcp_comp_master *comp_master =
> +
> mei_cldev_get_drvdata(cldev);
> +
> + dev_info(dev, "%s\n", __func__);
> + component_unbind_all(dev, comp_master); }
> +
> +static const struct component_master_ops mei_component_master_ops = {
> + .bind = mei_component_master_bind,
> + .unbind = mei_component_master_unbind, };
> +
> +static int mei_hdcp_component_match(struct device *dev, int subcomponent,
> + void *data)
> +{
> + return !strcmp(dev->driver->name, "i915") &&
> +subcomponent == I915_COMPONENT_HDCP; }
> +
> static int mei_hdcp_probe(struct mei_cl_device *cldev,
> const struct mei_cl_device_id *id) {
> + struct i915_hdcp_comp_master *comp_master;
> + struct component_match *master_match;
> int ret;
>
> ret = mei_cldev_enable(cldev);
> if (ret < 0)
> dev_err(>dev, "mei_cldev_enable Failed. %d\n", ret);
>
> + comp_master = kzalloc(sizeof(*comp_master), GFP_KERNEL);
> + if (!comp_master) {
> + ret = -ENOMEM;
> + goto comp_master_exit;
> + }
> +
> + master_match = NULL;
> + component_match_add_typed(>dev, _match,
> + mei_hdcp_component_match,
> comp_master);
> + if (IS_ERR_OR_NULL(master_match)) {
> + ret = -ENOMEM;
> + goto match_add_exit;
> + }
> +
> + mei_cldev_set_drvdata(cldev, comp_master);
> + ret = component_master_add_with_match(>dev,
> + _component_master_ops,
> + master_match);
> + if (ret < 0) {
> + dev_err(>dev, "Master comp add failed %d\n", ret);
> + mei_cldev_set_drvdata(cldev, NULL);
Can be done in exit label.
> + goto match_add_exit;
> + }
> +
> + return 0;
> +
> +match_add_exit:
> + kfree(comp_master);
> +comp_master_exit:
You can use a single label as kfree is NULL safe.
> + mei_cldev_disable(cldev);
> +
> return ret;
> }
>
> static int mei_hdcp_remove(struct mei_cl_device *cldev) {
> + struct i915_hdcp_comp_master *comp_master =
> +
> mei_cldev_get_drvdata(cldev);
> +
> + component_master_del(>dev, _component_master_ops);
> + kfree(comp_master);
> + mei_cldev_set_drvdata(cldev, NULL);
> +
> return mei_cldev_disable(cldev);
> }
>
> --
> 2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
RE: [PATCH v11 36/42] misc/mei/hdcp: Verify M_prime
>
> 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.
> v9:
> renamed func as mei_hdcp_* [Tomas]
> Inline function is defined for DDI index [Tomas]
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Uma Shankar
Ack,
Thanks
Tomas
> ---
> drivers/misc/mei/hdcp/mei_hdcp.c | 67
> +++-
> 1 file changed, 66 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index a64578cec0c9..1ebfc4aa2f04 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -535,6 +535,71 @@ mei_hdcp_repeater_check_flow_prepare_ack(struct
> device *dev,
> return 0;
> }
>
> +/**
> + * mei_hdcp_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_hdcp_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 = mei_get_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,
> @@ -548,7 +613,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
> .get_session_key = mei_hdcp_get_session_key,
> .repeater_check_flow_prepare_ack =
> mei_hdcp_repeater_check_flow_prepare_ack,
> - .verify_mprime = NULL,
> + .verify_mprime = mei_hdcp_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
RE: [PATCH v11 38/42] misc/mei/hdcp: Closing wired HDCP2.2 Tx Session
>
> 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]
> v9:
> renamed func as mei_hdcp_* [Tomas]
> Inline function is defined for DDI index [Tomas]
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Uma Shankar
Ack
Thanks
Tomas
> ---
> 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 167ccfeeca9e..615eed149837 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -653,6 +653,59 @@ static int mei_hdcp_enable_authentication(struct
> device *dev,
> return 0;
> }
>
> +/**
> + * mei_hdcp_close_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_hdcp_close_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 = mei_get_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,
> @@ -668,7 +721,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
> mei_hdcp_repeater_check_flow_prepare_ack,
> .verify_mprime = mei_hdcp_verify_mprime,
> .enable_hdcp_authentication = mei_hdcp_enable_authentication,
> - .close_hdcp_session = NULL,
> + .close_hdcp_session = mei_hdcp_close_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
RE: [PATCH v11 37/42] misc/mei/hdcp: Enabling the HDCP authentication
>
> 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]
> v9:
> renamed func as mei_hdcp_* [Tomas]
> Inline function is defined for DDI index [Tomas]
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Uma Shankar
Ack
Thanks
Tomas
> ---
> 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 1ebfc4aa2f04..167ccfeeca9e 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -600,6 +600,59 @@ static int mei_hdcp_verify_mprime(struct device
> *dev,
> return 0;
> }
>
> +/**
> + * mei_hdcp_enable_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_hdcp_enable_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 = mei_get_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,
> @@ -614,7 +667,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
> .repeater_check_flow_prepare_ack =
> mei_hdcp_repeater_check_flow_prepare_ack,
> .verify_mprime = mei_hdcp_verify_mprime,
> - .enable_hdcp_authentication = NULL,
> + .enable_hdcp_authentication = mei_hdcp_enable_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
RE: [PATCH v11 34/42] misc/mei/hdcp: Prepare Session Key
>
> 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]
> v9:
> renamed func as mei_hdcp_* [Tomas]
> Inline function is defined for DDI index [Tomas]
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Uma Shankar
Ack
Thanks
Tomas
> ---
> 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 814d870347a0..d8665b02d6d5 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -404,6 +404,63 @@ mei_hdcp_verify_lprime(struct device *dev, struct
> hdcp_port_data *data,
> return 0;
> }
>
> +/**
> + * mei_hdcp_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_hdcp_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 = mei_get_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,
> @@ -414,7 +471,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
> .store_pairing_info = mei_hdcp_store_pairing_info,
> .initiate_locality_check = mei_hdcp_initiate_locality_check,
> .verify_lprime = mei_hdcp_verify_lprime,
> - .get_session_key = NULL,
> + .get_session_key = mei_hdcp_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
RE: [PATCH v11 35/42] misc/mei/hdcp: Repeater topology verification and ack
> 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]
> v9:
> renamed func as mei_hdcp_* [Tomas]
> Inline function is defined for DDI index [Tomas]
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Uma Shankar
Ack
Thanks
Tomas
> ---
> drivers/misc/mei/hdcp/mei_hdcp.c | 77
> +++-
> 1 file changed, 76 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index d8665b02d6d5..a64578cec0c9 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -461,6 +461,80 @@ static int mei_hdcp_get_session_key(struct device
> *dev,
> return 0;
> }
>
> +/**
> + * mei_hdcp_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_hdcp_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 = mei_get_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,
> @@ -472,7 +546,8 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
> .initiate_locality_check = mei_hdcp_initiate_locality_check,
> .verify_lprime = mei_hdcp_verify_lprime,
> .get_session_key = mei_hdcp_get_session_key,
> - .repeater_check_flow_prepare_ack = NULL,
> + .repeater_check_flow_prepare_ack =
> + mei_hdcp_repeater_check_flow_prepare_ack,
> .verify_mprime = NULL,
> .enable_hdcp_authentication = NULL,
> .close_hdcp_session = NULL,
> --
> 2.7.4
RE: [PATCH v11 33/42] misc/mei/hdcp: Verify L_prime
> 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.
> v9:
> renamed func as mei_hdcp_* [Tomas]
> Inline function is defined for DDI index [Tomas]
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Uma Shankar
Ack
Thanks
Tomas
> ---
> 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 c540d03470a6..814d870347a0 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -346,6 +346,64 @@ mei_hdcp_initiate_locality_check(struct device *dev,
> return 0;
> }
>
> +/**
> + * mei_hdcp_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_hdcp_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 = mei_get_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,
> @@ -355,7 +413,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
> .verify_hprime = mei_hdcp_verify_hprime,
> .store_pairing_info = mei_hdcp_store_pairing_info,
> .initiate_locality_check = mei_hdcp_initiate_locality_check,
> - .verify_lprime = NULL,
> + .verify_lprime = mei_hdcp_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
RE: [PATCH v11 31/42] misc/mei/hdcp: Store the HDCP Pairing info
> 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.
> v9:
> renamed func as mei_hdcp_* [Tomas]
> Inline function is defined for DDI index [Tomas]
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Uma Shankar
Ack
Thanks
Tomas
> ---
> 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 0bbc6992631a..17043fc60d18 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -233,6 +233,64 @@ mei_hdcp_verify_hprime(struct device *dev, struct
> hdcp_port_data *data,
> return 0;
> }
>
> +/**
> + * mei_hdcp_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_hdcp_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 = mei_get_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,
> @@ -240,7 +298,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
> .verify_receiver_cert_prepare_km =
> mei_hdcp_verify_receiver_cert_prepare_km,
> .verify_hprime = mei_hdcp_verify_hprime,
> - .store_pairing_info = NULL,
> + .store_pairing_info = mei_hdcp_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
RE: [PATCH v11 32/42] misc/mei/hdcp: Initiate Locality check
>
> 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]
> v9:
> renamed func as mei_hdcp_* [Tomas]
> Inline function is defined for DDI index [Tomas]
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Uma Shankar
Ack
Thanks
Tomas
> ---
> 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 17043fc60d18..c540d03470a6 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -291,6 +291,61 @@ mei_hdcp_store_pairing_info(struct device *dev,
> struct hdcp_port_data *data,
> return 0;
> }
>
> +/**
> + * mei_hdcp_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_hdcp_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 = mei_get_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,
> @@ -299,7 +354,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
> mei_hdcp_verify_receiver_cert_prepare_km,
> .verify_hprime = mei_hdcp_verify_hprime,
> .store_pairing_info = mei_hdcp_store_pairing_info,
> - .initiate_locality_check = NULL,
> + .initiate_locality_check = mei_hdcp_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
RE: [PATCH v11 30/42] misc/mei/hdcp: Verify H_prime
>
> 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.
> v9:
> renamed func as mei_hdcp_* [Tomas]
> Inline function is defined for DDI index [Tomas]
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Uma Shankar
Ack
Thanks
Tomas
> ---
> 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 4e471657c6f0..0bbc6992631a 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -177,13 +177,69 @@ mei_hdcp_verify_receiver_cert_prepare_km(struct
> device *dev,
> return 0;
> }
>
> +/**
> + * mei_hdcp_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_hdcp_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 = mei_get_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_hdcp_initiate_session,
> .verify_receiver_cert_prepare_km =
> mei_hdcp_verify_receiver_cert_prepare_km,
> - .verify_hprime = NULL,
> + .verify_hprime = mei_hdcp_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
RE: [PATCH v11 28/42] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session
> 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.
> v9:
> s/mei_hdcp_ddi/mei_fw_ddi
> s/i915_port/mei_i915_port [Tomas]
> renamed func as mei_hdcp_* [Tomas]
> Instead of macro, inline func for ddi index is used. [Tomas]
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Uma Shankar
> ---
> drivers/misc/mei/hdcp/mei_hdcp.c | 89
>
> drivers/misc/mei/hdcp/mei_hdcp.h | 23 +++
> 2 files changed, 112 insertions(+)
>
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index b8580b91e255..77dda13fcc88 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -23,6 +23,95 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
> +
> +#include "mei_hdcp.h"
> +
> +static inline u8 mei_get_ddi_index(short int port) {
> + enum mei_i915_port i915_port = (enum mei_i915_port)port;
> +
> + return (u8)(i915_port == PORT_A ? MEI_DDI_A : i915_port); }
This translations from enum port to short int, than to eum mei_i915_port and
then to u8 bothers me.
Should be a cleaner
Maybe it's a bit overhead but it will be much more readlbe if we do switch
statement here:
switch (port)
{
case PORT_A:
return MEI_DDI_A:
case PORT_B:
return MEI_DDI_B
etc.
case: I915_MAX_PORTS
default:
MEI_DDI_INVALID_PORT
}
Otherwise looks good to me.
> +
> +/**
> + * mei_hdcp_initiate_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_hdcp_initiate_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 = mei_get_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_hdcp_initiate_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,
RE: [PATCH v11 29/42] misc/mei/hdcp: Verify Receiver Cert and prepare km
> -Original Message-
> From: C, Ramalingam
> Sent: Wednesday, February 06, 2019 23:04
> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
> Uma
> Cc: C, Ramalingam
> Subject: [PATCH v11 29/42] misc/mei/hdcp: Verify Receiver Cert and prepare
> km
>
> 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.
> v9:
> renamed func as mei_hdcp_* [Tomas]
> Inline function is defined for DDI index [Tomas]
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Uma Shankar
> ---
> drivers/misc/mei/hdcp/mei_hdcp.c | 83
> +++-
> 1 file changed, 82 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index 77dda13fcc88..4e471657c6f0 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -97,11 +97,92 @@ mei_hdcp_initiate_session(struct device *dev, struct
> hdcp_port_data *data,
> return 0;
> }
>
> +/**
> + * mei_hdcp_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_hdcp_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 = mei_get_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,
> + v
RE: [PATCH v11 26/42] misc/mei/hdcp: Client driver for HDCP application
> ME FW 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.2 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]
> v7:
> %s/UUID_LE/GUID_INIT [Tomas]
> GPL Ver is 2.0 than 2.0+ [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.
This is not limited to SoC this goes for PCH based platforms as well.
> diff --git a/drivers/misc/mei/Makefile b/drivers/misc/mei/Makefile index
> d9215fc4e499..8c2d9565a4cb 100644
> --- a/drivers/misc/mei/Makefile
> +++ b/drivers/misc/mei/Makefile
> @@ -24,3 +24,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 ..e27d10754dbf
> --- /dev/null
> +++ b/drivers/misc/mei/hdcp/Makefile
> @@ -0,0 +1,7 @@
> +# SPDX-License-Identifier: GPL-2.0
> +#
> +# 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 ..b8580b91e255
> --- /dev/null
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -0,0 +1,65 @@
> +// SPDX-License-Identifier: (GPL-2.0)
> +/*
> + * Copyright © 2017-2018 Intel Corporation
> + *
> + * Mei_hdcp.c: HDCP client driver for mei bus
> + *
> + * Author:
> + * 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_HDCPGUID_INIT(0xB638AB7E, 0x94E2,
I would use space instead of tab here, it's not sable view between editors.
> 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 = {
> +
RE: [PATCH v11 07/42] drm/i915: Initialize HDCP2.2
> 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.
> v10:
> bool is used in struct to make coding simpler. [Daniel]
> hdmi hdcp init is placed correctly after encoder attachment.
> v11:
> hdcp2_capability check is moved into hdcp.c [Tomas]
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Daniel Vetter
> Reviewed-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/intel_drv.h | 11 +++
> drivers/gpu/drm/i915/intel_hdcp.c | 28 ++--
> drivers/gpu/drm/i915/intel_hdmi.c | 6 +++---
> 3 files changed, 40 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 90ba5436370e..030d962697dd 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -394,6 +394,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. */
> + bool 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 {
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index 8cb85b07cfde..7b1097d79fb8 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -832,14 +832,34 @@ bool is_hdcp_supported(struct drm_i915_private
> *dev_priv, enum port port)
> return INTEL_GEN(dev_priv) >= 9 && port < PORT_E; }
>
> +static bool is_hdcp2_supported(struct drm_i915_private *dev_priv) {
> + if (!IS_ENABLED(CONFIG_INTEL_MEI_HDCP))
> + return false;
Is this enough, you can have SKU where this is not enabled, and you can detect
that only during runtime.
> +
> + return (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv) ||
> + IS_KABYLAKE(dev_priv));
> +}
> +
> +static void intel_hdcp2_init(struct intel_connector *connector) {
> + struct intel_hdcp *hdcp = >hdcp;
> +
> + /* TODO: MEI interface needs to be initialized here */
> + hdcp->hdcp2_supported = true;
> +}
> +
> int intel_hdcp_init(struct intel_connector *connector,
> const struct intel_hdcp_shim *shim) {
> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> struct intel_hdcp *hdcp = >hdcp;
> int ret;
>
> - ret = drm_connector_attach_content_protection_property(
> - >base);
> + if (!shim)
> + return -EINVAL;
> +
> + ret =
> +drm_connector_attach_content_protection_property(>base);
> if (ret)
> return ret;
>
> @@ -847,6 +867,10 @@ int intel_hdcp_init(struct intel_connector *connector,
> mutex_init(>mutex);
> INIT_DELAYED_WORK(>check_work, intel_hdcp_check_work);
> INIT_WORK(>prop_work, intel_hdcp_prop_work);
> +
> + if (is_hdcp2_supported(dev_priv))
> + intel_hdcp2_init(connector);
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index f125a62eba8c..faeedf76db99 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -2427,6 +2427,9 @@ void intel_hdmi_init_connector(struct
> intel_digital_port *intel_dig_port,
>
> intel_hdmi_add_properties(intel_hdmi, connector);
>
> + intel_connector_attach_encoder(intel_connector, intel_encoder);
> + intel_hdmi->attached_connector = intel_connector;
> +
> if (is_hdcp_supported(dev_priv, port)) {
> int ret = intel_hdcp_init(intel_connector,
> _hdmi_hdcp_shim);
Won't this depend on the driver load order?
Thanks
Tomas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
RE: [PATCH v11 06/42] drm: header for i915 - MEI_HDCP interface
>
> Header defines the interface for the I915 and MEI_HDCP drivers.
> This interface is specific to the usage of mei_hdcp from gen9+ platforms for
> ME FW based HDCP2.2 services.
>
> And Generic HDCP2.2 protocol specific definitions are added at
> drm/drm_hdcp.h.
>
> v2:
> Commit msg is enhanced [Daniel]
> v3:
> i915_hdcp_comp_master is defined.
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Daniel Vetter
> Reviewed-by: Uma Shankar
> ---
> include/drm/i915_mei_hdcp_interface.h | 148
> ++
> 1 file changed, 148 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 ..bc5b0c71ed3c
> --- /dev/null
> +++ b/include/drm/i915_mei_hdcp_interface.h
> @@ -0,0 +1,148 @@
> +/* SPDX-License-Identifier: (GPL-2.0+) */
> +/*
> + * Copyright © 2017-2018 Intel Corporation
> + *
> + * Authors:
> + * Ramalingam C */
> +
> +#ifndef _I915_MEI_HDCP_INTERFACE_H_
> +#define _I915_MEI_HDCP_INTERFACE_H_
> +
> +#include
> +#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;
I wonder why 'short int' u are assigning it from the encoder 'enum port {} '
Then you down casting it to u8.
Maybe is best to export the eum port from intel_drv.h to include/drm/i915_*.h
Thanks
Tomas
> --
> 2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v11 05/42] drm/i915: Gathering the HDCP1.4 routines together
> 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
> Acked-by: Daniel Vetter
> Reviewed-by: Uma Shankar
Reviewed-by: Tomas Winkler
> ---
> 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 ce7ba3a9c000..8cb85b07cfde 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -730,6 +730,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),
> @@ -866,62 +925,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 =
RE: [PATCH v11 01/42] component: Add documentation
> > From: Daniel Vetter > > While typing these I think doing an s/component_master/aggregate/ would be > useful: > - it's shorter :-) > - I think component/aggregate is much more meaningful naming than > component/puppetmaster or something like that. At least to my > English ear "aggregate" emphasizes much more the "assemble a pile of > things into something bigger" aspect, and there's not really much > of a control hierarchy between aggregate and constituing components. > > But that's way more than a quick doc typing exercise ... > > Thanks to Ram for commenting on an initial draft of these docs. > > v2: Review from Rafael: > - git add Documenation/driver-api/component.rst > - lots of polish to the wording + spelling fixes. > > v3: Review from Russell: > - s/framework/helper > - clarify the documentation for component_match_add functions. > > Cc: "C, Ramalingam" > Cc: Greg Kroah-Hartman > Cc: Russell King > Cc: Rafael J. Wysocki > Cc: Jaroslav Kysela > Cc: Takashi Iwai > Cc: Rodrigo Vivi > Cc: Jani Nikula > Signed-off-by: Daniel Vetter > --- > Documentation/driver-api/component.rst | 17 + Not sure if you care, but the file missing the SPDX header. Thanks Tomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v11 24/42] mei: me: add ice lake point device ids
>
> From: Tomas Winkler
>
> Add icelake device ids: ICP LP, N and H
>
> Signed-off-by: Tomas Winkler
NACK, this goes via mei driver submission process.
Please drop it from the series.
> ---
> drivers/misc/mei/hw-me-regs.h | 4
> drivers/misc/mei/pci-me.c | 4
> 2 files changed, 8 insertions(+)
>
> diff --git a/drivers/misc/mei/hw-me-regs.h b/drivers/misc/mei/hw-me-regs.h
> index 23739a60517f..086e557c2872 100644
> --- a/drivers/misc/mei/hw-me-regs.h
> +++ b/drivers/misc/mei/hw-me-regs.h
> @@ -139,6 +139,10 @@
> #define MEI_DEV_ID_CNP_H 0xA360 /* Cannon Point H */
> #define MEI_DEV_ID_CNP_H_40xA364 /* Cannon Point H 4 (iTouch) */
>
> +#define MEI_DEV_ID_ICP_LP 0x34E0 /* Ice Lake Point LP */
> +#define MEI_DEV_ID_ICP_N 0x38E0 /* Ice Lake Point N */
> +#define MEI_DEV_ID_ICP_H 0x3DE0 /* Ice Lake Point H */
> +
> /*
> * MEI HW Section
> */
> diff --git a/drivers/misc/mei/pci-me.c b/drivers/misc/mei/pci-me.c index
> e89497f858ae..5ed5d28e6fe2 100644
> --- a/drivers/misc/mei/pci-me.c
> +++ b/drivers/misc/mei/pci-me.c
> @@ -105,6 +105,10 @@ static const struct pci_device_id mei_me_pci_tbl[] = {
> {MEI_PCI_DEVICE(MEI_DEV_ID_CNP_H, MEI_ME_PCH12_CFG)},
> {MEI_PCI_DEVICE(MEI_DEV_ID_CNP_H_4, MEI_ME_PCH8_CFG)},
>
> + {MEI_PCI_DEVICE(MEI_DEV_ID_ICP_LP, MEI_ME_PCH12_CFG)},
> + {MEI_PCI_DEVICE(MEI_DEV_ID_ICP_N, MEI_ME_PCH12_CFG)},
> + {MEI_PCI_DEVICE(MEI_DEV_ID_ICP_H, MEI_ME_PCH12_CFG)},
> +
> /* required last entry */
> {0, }
> };
> --
> 2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v10 25/40] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session
>
> > >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
> >
> > Latest set look ok. You can keep the RB.
> >
> > >---
> > > drivers/misc/mei/hdcp/mei_hdcp.c | 82
> > >
> > > drivers/misc/mei/hdcp/mei_hdcp.h | 28 ++
> > > 2 files changed, 110 insertions(+)
> > >
> > >diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> > >b/drivers/misc/mei/hdcp/mei_hdcp.c
> > >index ca5010ad7dd7..534d29c8ee86 100644
> > >--- a/drivers/misc/mei/hdcp/mei_hdcp.c
> > >+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> > >@@ -23,6 +23,88 @@
> > > #include
> > > #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) {
>
>
> Breaking naming conventions : all functions should be prefixed with mei_hdcp_
>
> e.g. mei_hdcp_ initiate_session()
>
> > >+ 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 582a7e27ae29..f831db3cbd54 100644
> > >--- a/drivers/misc/mei/hdcp/mei_hdcp.h
> > >+++ b/drivers/misc/mei/hdcp/mei_hdcp.h
> >
RE: [PATCH v10 26/40] misc/mei/hdcp: Verify Receiver Cert and prepare km
>
> >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
>
> Latest set look ok. You can keep the RB.
>
> >---
> > 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 534d29c8ee86..24665fff640d 100644
> >--- a/drivers/misc/mei/hdcp/mei_hdcp.c
> >+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> >@@ -90,11 +90,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,
mei_hdcp_ - prefix
> >+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,
> >+
RE: [PATCH v10 25/40] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session
> >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
>
> Latest set look ok. You can keep the RB.
>
> >---
> > drivers/misc/mei/hdcp/mei_hdcp.c | 82
> >
> > drivers/misc/mei/hdcp/mei_hdcp.h | 28 ++
> > 2 files changed, 110 insertions(+)
> >
> >diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> >b/drivers/misc/mei/hdcp/mei_hdcp.c
> >index ca5010ad7dd7..534d29c8ee86 100644
> >--- a/drivers/misc/mei/hdcp/mei_hdcp.c
> >+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> >@@ -23,6 +23,88 @@
> > #include
> > #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) {
Breaking naming conventions : all functions should be prefixed with mei_hdcp_
e.g. mei_hdcp_ initiate_session()
> >+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 582a7e27ae29..f831db3cbd54 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,
>
RE: [PATCH v10 24/40] misc/mei/hdcp: Define ME FW interface for HDCP2.2
>
> >-Original Message-
> >From: C, Ramalingam
> >Sent: Thursday, January 31, 2019 12:30 PM
> >To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> >daniel.vet...@ffwll.ch; Winkler, Tomas ;
> >Shankar, Uma
> >Cc: C, Ramalingam
> >Subject: [PATCH v10 24/40] misc/mei/hdcp: Define ME FW interface for
> >HDCP2.2
> >
> >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
>
> Looks ok to me.
> Reviewed-by: Uma Shankar
Acked-by Tomas Winkler
>
> >---
> > 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 ..582a7e27ae29
> >--- /dev/null
> >+++ b/drivers/misc/mei/hdcp/mei_hdcp.h
> >@@ -0,0 +1,366 @@
> >+/* SPDX-License-Identifier: (GPL-2.0+) */
> >+/*
> >+ * 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
RE: [PATCH v10 23/40] misc/mei/hdcp: Client driver for HDCP application
>
> 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
> d9215fc4e499..8c2d9565a4cb 100644
> --- a/drivers/misc/mei/Makefile
> +++ b/drivers/misc/mei/Makefile
> @@ -24,3 +24,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 ..b2de072aa0de
> --- /dev/null
> +++ b/drivers/misc/mei/hdcp/Makefile
> @@ -0,0 +1,7 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# 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 ..ca5010ad7dd7
> --- /dev/null
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -0,0 +1,65 @@
> +// SPDX-License-Identifier: (GPL-2.0+)
GPL-2.0 (drop +)
> +/*
> + * 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_HDCPUUID_LE(0xB638AB7E, 0x94E2,
> 0x4EA2, 0xA5, \
> + 0x52, 0xD1, 0xC5, 0x4B, \
> + 0x62, 0x7F, 0x04)
Should be now moving to GUID_INIT from UUID_LE()
Thought it may be done later.
> +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,
> +
RE: [PATCH v10 19/40] drm/i915: Add HDCP2.2 support for DP connectors
> -Original Message-
> From: C, Ramalingam
> Sent: Thursday, January 31, 2019 09:00
> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
> Uma
> Cc: C, Ramalingam
> Subject: [PATCH v10 19/40] drm/i915: Add HDCP2.2 support for DP connectors
>
> 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 4e36df266ab3..88c889770517 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -7301,7 +7301,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));
intel_hdcp_init is always called with is_hdcp2_supported() both for DP and
HDMI, so you can just remove the argument it's redundant.
Thanks
Tomas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v10 20/40] drm/i915: Add HDCP2.2 support for HDMI connectors
>
> 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 3b4fe7048af9..2c4bf6d0c39f 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -2621,7 +2621,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));
intel_hdcp_init is always called with is_hdcp2_supported() both for DP and
HDMI, so you can just remove the argument it's redundant.
if (is_hdcp2_supported())
intel_hdcp2_init(connector);
They are both defied in intel_hdcp.c.
Thanks
Tomas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v9 35/39] misc/mei/hdcp: Component framework for I915 Interface
From: C, Ramalingam
Sent: Thursday, December 20, 2018 18:00
To: Daniel Vetter ; Winkler, Tomas
Cc: Greg KH ; Rafael J. Wysocki
; intel-gfx ; dri-devel
; Sean Paul ; Shankar,
Uma ; Syrjala, Ville ;
Chris Wilson
Subject: Re: [PATCH v9 35/39] misc/mei/hdcp: Component framework for I915
Interface
On 12/19/2018 12:15 PM, C, Ramalingam wrote:
Tomas and Daniel,
From the discussion on this thread, I infer following understanding:
* At present(v9) I915 wants to be hard binded to mei_hdcp device-driver
binding status through components
* This means I915 driver load will get complete only when the mei_hdcp's
device and driver are bound.
* if mei_hdcp device reset I915 will unregister itself from userspace,
and wait for the mei_hdcp device-deriver rebinding.
* Could be due to FW error or any unexpected failures those are rare
occurances.
* when mei_hdcp module is removed i915 will unregister itself.
* Becasue of this, Ideally I915 dont expect the device reset from mei
for suspend and resume.
* At present Mei bus is designed as below:
* Device will disappear on FW failures, FW upgrade, suspend of the
system etc.
* And when the errors are handled or on system resume mei device will
reappear, hence binding with corresponding driver.
* Mei doesn't plan to avoid the device reset(disappearance and
reappearance) for suspend and resume in near future.
Based on above understanding, I propose the below approach. Please correct or
approve it.
* At present(v9) component_add from mei_hdcp indicates the mei_hdcp's
device-driver binded state.
* Instead lets use component to indicate the mei_hdcp's module availability,
* by adding the component at module_init and removing it from
module_exit.
* This way I915 will not be impacted due to the mei device reset at suspend.
* In such scenario I915 will have no idea about the device-driver bind
status of mei_hdcp.
* So incase of device is not available, mei_hdcp is responsible to prune
such calls with -EIO error.
* This approach avoid any future impact to I915, incase mei intended to
support suspend and resume.
I am aware this is not the ideal solution we want. But I feel this is the best
at present we could do for this I915-mei interface.
Best regards,
Ram
something like (un compiled code)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index b22a71e8c5d7..b5b57a883e3b 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -23,11 +23,15 @@
#include
#include
#include
+#include
#include
#include
#include "mei_hdcp.h"
+struct i915_component_master *i915_master_comp;
+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 +695,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 +710,84 @@ 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;
+
+ i915_master_comp = master_comp;
+
+ 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;
+ i915_master_comp = 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;
+
+ if (mei_hdcp_component_registered && i915_master_comp) {
+ i915_master_comp->mei_dev = dev;
+ return;
+ }
+
+ dev_info(dev, "MEI HDCP comp init\n");
+ ret = component_add(dev, _hdcp_component_bind_ops);
+ if (ret < 0) {
+ dev_err(dev
RE: [Intel-gfx] [PATCH v9 10/39] drm/i915: Implement HDCP2.2 receiver authentication
> On Wed, 19 Dec 2018, "Winkler, Tomas" wrote:
> >>
> >> On Wed, 19 Dec 2018, "C, Ramalingam" wrote:
> >> > On 12/19/2018 8:05 PM, Daniel Vetter wrote:
> >> >> On Thu, Dec 13, 2018 at 09:31:12AM +0530, Ramalingam C wrote:
> >> >>> 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;
> >> >> Make these two bool, will simplify the code a bunch.
> >> >
> >> > Seems there is a movement for not to use the bool in structures.
> >>
> >> No. Please use bools in structs when it makes sense. Avoid bools in
> >> structs when you need to care about memory footprint or alignment or
> >> packing or the like. This is not one of those cases.
> >>
> >> > Thats why I have changed these from bool to u8 from v8 onwards.
> >> > Checkpatch also complains on this
> >>
> >> Sorry to say, checkpatch is not the authority although we do send out
> >> automated checkpatch results.
> >
> > I believe it was Linus' call to not use bool in structs at all
> > https://lkml.org/lkml/2017/11/21/384
>
> I don't care. That's a valid judgement in the context referenced, but the
> conclusion "no bools in structs at all" isn't. In this case, I think bools
> are the
> better option, and anything else makes the code worse.
The solution was to use bit fields,
unsinged int is_paired:1;
unsinged int is_repeter:1
There is a strong point in consistency so there are no mistakes.
But frankly I don't really have strong feelings about it.
Thanks
Tomas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [Intel-gfx] [PATCH v9 10/39] drm/i915: Implement HDCP2.2 receiver authentication
>
> On Wed, 19 Dec 2018, "C, Ramalingam" wrote:
> > On 12/19/2018 8:05 PM, Daniel Vetter wrote:
> >> On Thu, Dec 13, 2018 at 09:31:12AM +0530, Ramalingam C wrote:
> >>> 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;
> >> Make these two bool, will simplify the code a bunch.
> >
> > Seems there is a movement for not to use the bool in structures.
>
> No. Please use bools in structs when it makes sense. Avoid bools in structs
> when you need to care about memory footprint or alignment or packing or
> the like. This is not one of those cases.
>
> > Thats why I have changed these from bool to u8 from v8 onwards.
> > Checkpatch also complains on this
>
> Sorry to say, checkpatch is not the authority although we do send out
> automated checkpatch results.
I believe it was Linus' call to not use bool in structs at all
https://lkml.org/lkml/2017/11/21/384
Thanks
Tomas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v9 02/39] drm: header for i915 - MEI_HDCP interface
>
> On Mon, Dec 17, 2018 at 12:28 PM Winkler, Tomas
> wrote:
> >
> > >
> > > 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
> >
> >
> > This should be just 'i915_hdcp_interface.h'
>
> We have other hdcp engines than the mei one. Discrete gpus will definitely get
> a differnt hdcp2 engine even, can't rely on ME for those. Keeping mei in the
> names to make that clear makes sense to me, removing it would just cause
> more confusion I think.
We would like to create a DHCP interface and hold the specific implementation
w/o hdcp_mei
>
> We already had the entire "should we have a common hdcp interface in drm"
> discussion when we orginally landed this, and looking at all the intel and
> non-
> intel implementations floating around that didn't make sense, due to lack of
> comonality of how things flow and interact with the hdmi/dp ports.
> -Daniel
Sorry, was not part of that discussion, though it looks strange to me as the
DHCP is a standard no Intel invention.
>
> >
> > > @@ -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_
> > Drop MEI
> > > +
> > > +#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
> > > + * @initia
RE: [PATCH v9 02/39] drm: header for i915 - MEI_HDCP interface
>
> 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
This should be just 'i915_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_
Drop MEI
> +
> +#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
RE: [PATCH v9 35/39] misc/mei/hdcp: Component framework for I915 Interface
> On Sat, Dec 15, 2018 at 09:20:38PM +0000, Winkler, Tomas wrote: > > > > > > On Thu, Dec 13, 2018 at 5:27 PM Winkler, Tomas > > > > > > wrote: > > > > > > > > > On Thu, Dec 13, 2018 at 1:36 PM C, Ramalingam > > > > > > > > > > wrote: > > > > > > > > > > > > Tomas and Daniel, > > > > > > > > > > > > We got an issue here. > > > > > > > > > > > > The relationship that we try to build between I915 and > > > > > > mei_hdcp is as > > > follows: > > > > > > > > > > > > We are using the components to establish the relationship. > > > > > > I915 is component master where as mei_hdcp is component. > > > > > > I915 adds the component master during the module load. > > > > > > mei_hdcp adds the > > > > > component when the driver->probe is called (on device driver binding). > > > > > > I915 forces itself such that until mei_hdcp component is added > > > > > > I915_load > > > > > wont be complete. > > > > > > Similarly on complete system, if mei_hdcp component is > > > > > > removed, > > > > > immediately I915 unregister itself and HW will be shutdown. > > > > > > > > > > > > This is completely fine when the modules are loaded and unloaded. > > > > > > > > > > > > But during suspend, mei device disappears and mei bus handles > > > > > > it by > > > > > unbinding device and driver by calling driver->remove. > > > > > > This in-turn removes the component and triggers the master > > > > > > unbind of I915 > > > > > where, I915 unregister itself. > > > > > > This cause the HW state mismatch during the suspend and resume. > > > > > > > > > > > > Please check the powerwell mismatch errors at CI report for v9 > > > > > > https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_3412/fi-glk-j4 > > > > > > 005/ > > > > > > igt@ > > > > > > gem_exec_susp...@basic-s3.html > > > > > > > > > > > > More over unregistering I915 during the suspend is not expected. > > > > > > So how do > > > > > we handle this? > > > > > > > > > > Bit more context from our irc discussion with Ram: > > > > > > > > > > I found this very surprising, since I don't know of any other > > > > > subsystems where the devices get outright removed when going > > > > > through a > > > suspend/resume cycle. > > > > > The device model was built to handle this stuff > > > > > correctly: First clients/devices/interfaces get suspend, then > > > > > the parent/bridge/bus. Same dance in reverse when resuming. This > > > > > even holds for lots of hotpluggable buses, where child devices > > > > > could indeed disappear on resume, but as long as they don't, > > > > > everything stays the same. It's really surprising for something > > > > > that's soldered onto the > > > board like ME. > > > > > > > > HDCP is an application in the ME it's not ME itself.. On the > > > > linux side HDCP2 is a virtual device on mei client virtual bus, > > > > the bus is teared > > > down on ME reset, which mostly happen on power transitions. > > > > Theoretically, we could keep it up during power transitions, but > > > > so fare it was not necessary and second it's not guarantie that > > > > the all ME > > > applications will reappear after reset. > > > > > > When does this happen that an ME application doesn't come back after e.g. > > > suspend/resume? > > No, this can happen in special flows such as fw updates and error > > conditions, > but is has to be supported as well. > > > > > > > > Also, what's all the place where this reset can happen? Just > > > suspend/resume/hibernate and all these, or also at other times? > > > > Also on errors and fw update, the basic assumption is here that it can > > happen > any time. > > If this can happen any time, what are we supposed to do if this happens while > we're doing something with the hdcp mei? If this is such a common occurence I > guess we
RE: [PATCH v9 35/39] misc/mei/hdcp: Component framework for I915 Interface
> > On Thu, Dec 13, 2018 at 5:27 PM Winkler, Tomas > wrote: > > > > > On Thu, Dec 13, 2018 at 1:36 PM C, Ramalingam > > > > > > wrote: > > > > > > > > Tomas and Daniel, > > > > > > > > We got an issue here. > > > > > > > > The relationship that we try to build between I915 and mei_hdcp is as > follows: > > > > > > > > We are using the components to establish the relationship. > > > > I915 is component master where as mei_hdcp is component. > > > > I915 adds the component master during the module load. mei_hdcp > > > > adds the > > > component when the driver->probe is called (on device driver binding). > > > > I915 forces itself such that until mei_hdcp component is added > > > > I915_load > > > wont be complete. > > > > Similarly on complete system, if mei_hdcp component is removed, > > > immediately I915 unregister itself and HW will be shutdown. > > > > > > > > This is completely fine when the modules are loaded and unloaded. > > > > > > > > But during suspend, mei device disappears and mei bus handles it > > > > by > > > unbinding device and driver by calling driver->remove. > > > > This in-turn removes the component and triggers the master unbind > > > > of I915 > > > where, I915 unregister itself. > > > > This cause the HW state mismatch during the suspend and resume. > > > > > > > > Please check the powerwell mismatch errors at CI report for v9 > > > > https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_3412/fi-glk-j4005/ > > > > igt@ > > > > gem_exec_susp...@basic-s3.html > > > > > > > > More over unregistering I915 during the suspend is not expected. > > > > So how do > > > we handle this? > > > > > > Bit more context from our irc discussion with Ram: > > > > > > I found this very surprising, since I don't know of any other > > > subsystems where the devices get outright removed when going through a > suspend/resume cycle. > > > The device model was built to handle this stuff > > > correctly: First clients/devices/interfaces get suspend, then the > > > parent/bridge/bus. Same dance in reverse when resuming. This even > > > holds for lots of hotpluggable buses, where child devices could > > > indeed disappear on resume, but as long as they don't, everything > > > stays the same. It's really surprising for something that's soldered onto > > > the > board like ME. > > > > HDCP is an application in the ME it's not ME itself.. On the linux > > side HDCP2 is a virtual device on mei client virtual bus, the bus is > > teared > down on ME reset, which mostly happen on power transitions. > > Theoretically, we could keep it up during power transitions, but so > > fare it was not necessary and second it's not guarantie that the all ME > applications will reappear after reset. > > When does this happen that an ME application doesn't come back after e.g. > suspend/resume? No, this can happen in special flows such as fw updates and error conditions, but is has to be supported as well. > > Also, what's all the place where this reset can happen? Just > suspend/resume/hibernate and all these, or also at other times? Also on errors and fw update, the basic assumption is here that it can happen any time. > How does userspace deal with the reset over s/r? I'm assuming that at least > the > device node file will become invalid (or whatever you're using as userspace > api), so if userspace is accessing stuff on the me at the same time as we do a > suspend/resume, what happens? > > > > Aside: We'll probably need a device_link to make sure mei_hdcp is > > > fully resumed before i915 gets resumed, but that's kinda a detail for > > > later > on. > > > > Frankly I don’t believe there is currently exact abstraction that > > supports this model, neither components nor device_link . > > So fare we used class interface for other purposes, it worked well. > > I'm not clear on what class interface has to do with component or device link. > They all solve different problems, at least as far as I understand all this > stuff ... > -Daniel It comes instead of it, device_link is mostly used for power management and component as we see know is not what we need as HDCP Is a b it volitle. class_interface gives you two handlers: add and remove device, that's all what is needed for the current im
RE: [PATCH v9 35/39] misc/mei/hdcp: Component framework for I915 Interface
> On Thu, Dec 13, 2018 at 1:36 PM C, Ramalingam
> wrote:
> >
> > Tomas and Daniel,
> >
> > We got an issue here.
> >
> > The relationship that we try to build between I915 and mei_hdcp is as
> > follows:
> >
> > We are using the components to establish the relationship.
> > I915 is component master where as mei_hdcp is component.
> > I915 adds the component master during the module load. mei_hdcp adds the
> component when the driver->probe is called (on device driver binding).
> > I915 forces itself such that until mei_hdcp component is added I915_load
> wont be complete.
> > Similarly on complete system, if mei_hdcp component is removed,
> immediately I915 unregister itself and HW will be shutdown.
> >
> > This is completely fine when the modules are loaded and unloaded.
> >
> > But during suspend, mei device disappears and mei bus handles it by
> unbinding device and driver by calling driver->remove.
> > This in-turn removes the component and triggers the master unbind of I915
> where, I915 unregister itself.
> > This cause the HW state mismatch during the suspend and resume.
> >
> > Please check the powerwell mismatch errors at CI report for v9
> > https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_3412/fi-glk-j4005/igt@
> > gem_exec_susp...@basic-s3.html
> >
> > More over unregistering I915 during the suspend is not expected. So how do
> we handle this?
>
> Bit more context from our irc discussion with Ram:
>
> I found this very surprising, since I don't know of any other subsystems where
> the devices get outright removed when going through a suspend/resume cycle.
> The device model was built to handle this stuff
> correctly: First clients/devices/interfaces get suspend, then the
> parent/bridge/bus. Same dance in reverse when resuming. This even holds for
> lots of hotpluggable buses, where child devices could indeed disappear on
> resume, but as long as they don't, everything stays the same. It's really
> surprising for something that's soldered onto the board like ME.
HDCP is an application in the ME it's not ME itself.. On the linux side HDCP2
is a virtual device on mei client virtual bus,
the bus is teared down on ME reset, which mostly happen on power transitions.
Theoretically, we could keep it up during power transitions, but so fare it
was not necessary
and second it's not guarantie that the all ME applications will reappear after
reset.
>
> Aside: We'll probably need a device_link to make sure mei_hdcp is fully
> resumed before i915 gets resumed, but that's kinda a detail for later on.
Frankly I don’t believe there is currently exact abstraction that supports this
model,
neither components nor device_link .
So fare we used class interface for other purposes, it worked well.
>
> Tomas, can you pls explain why mei is designed like this? Or is there
> something
> else we're missing (I didn't dig through the mei bus in detail at all, so not
> clear
> on what exactly is going on there).
Above.
>
> Also pulling in device model and suspend/resume experts.
>
> Thanks, Daniel
>
> >
> > -Ram
> >
> > On 12/13/2018 9:31 AM, Ramalingam C wrote:
> >
> > 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
RE: [PATCH v9 12/39] drm/i915: Implement HDCP2.2 repeater authentication
>
> 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);
cpu_to_be16(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.
> */
> +
RE: [PATCH v9 01/39] drm/i915: Gathering the HDCP1.4 routines together
>
> 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) {
Should be static
> + 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);
> -
RE: [PATCH v8 03/35] linux/mei: Header for mei_hdcp driver interface
> On Fri, Dec 07, 2018 at 07:23:06PM +0530, C, Ramalingam wrote:
> > Hi,
> >
> > In one of the offline discussion Tomas has shared his review comments on v8.
>
> Let's please have all review here on the mailing list for better coordination.
> Playing a game of telephone isn't efficient.
It's not different from IRC or meeting on a conference, after all we end up
with code we can comment on.
>
> > So I am sharing the abstract of his suggestions here for the discussion and
> > for
> the agreement of interface in the community.
> > Tomas please correct/add if I am missing any points.
> >
> > 1. Remove the include/linux/mei_hdcp.h to make the i915-mei interface
> >more generic.
> > 1. Move the definition of the struct mei_hdcp_data to i915 and
> >mei_hdcp.c and pass the void* in the ops' functions.
>
> I don't get this. Using void * instead of the actual type we're passing isn't
> more
> generic, it's just less safe. If we later on need to extend the api contract
> between mei_hdcp and i915 we can always do that. Like we already do with the
> i915/snd-hda-intel component contract in i915_component.h and
> drm_audio_component.h.
No I haven't suggesting using void *, what I've suggest is to use HDCP
construct instead of mei specific types.
> Aside: Header names for the audio interface are maybe not the best, this isn't
> primarily a component thing. So maybe call it i915_mei_hdcp_interface.h and
> stuff all the structures/function pointers that define the interface between
> the
> two drivers in there. Or some other suitable name you like better.
>
> > 2. Move the conversion of enum port value to mei_ddi_port value
> >into mei_hdcp.c. Let I915 pass the enum port value as such.
>
> logical port 2 physical register index mapping tends to shift around and is
> always highly machine specific. As long as we do it consistently somewhere we
> should be good. Seems fine to me.
>
> > 3. Modified local definition of the struct mei_hdcp_data will looks
> >like
>
> No local defintions of structures please. Otherwise I'm ok with whatever gets
> the job done.
>
> > 4.
> >
> >+/* hdcp data per port */
> >+struct hdcp_port_data {
> >+ short int port;
> >+ u8 port_type;
> >+ u8 protocol;
> >+ u16 k;
> >+ u32 seq_num_m;
> >+ struct hdcp2_streamid_type *streams;
> > };
> >
> > 2. Add K-Doc compliant commenting in the mei_hdcp.c
>
> If you do that, please include the relevant comments into the drm/i915
> docbook, like we do already with the audio stuff.
>
> > I have implemented these changes and posted for intel-gfx-trybot. Just
> > incase anyone wants to refer the code please look at
> https://patchwork.freedesktop.org/series/53655/ .
> > Not shared on #intel-gfx as further review discussions are on-going on
> > intel-
> gfx.
>
> As discussed, no void * in the interface, and we definitely need a shared
> header
> for ops/data structures. We want the compiler to help us catch when one side
> of this i915/mei_hdcp api contract changes as much as possible.
> All the other changes seem reasonable.
> Thanks, Daniel
I agree with no void *, that was not my intention.
It will be better to comment on v9 series.
> >
>
> > --Ram
> >
> > On 11/27/2018 4:13 PM, Ramalingam C wrote:
> > > Data structures and Enum for the I915-MEI_HDCP interface are defined
> > > at
> > >
> > > v2:
> > >Rebased.
> > > v3:
> > >mei_cl_device is removed from mei_hdcp_data [Tomas]
> > > v4:
> > >Comment style and typo fixed [Uma]
> > > v5:
> > >Rebased.
> > > v6:
> > >No changes.
> > > v7:
> > >Remove redundant text from the License header
> > >Change uintXX_t type to uXX_t types
> > >Remove unneeded include to mei_cl_bus.h
> > >Coding style fixed [Uma]
> > > V8:
> > >Tab cleanup
> > >Fix kdoc and namespaces
> > >Update MAINTAINERS
> > >
> > > Signed-off-by: Ramalingam C
> > > Signed-off-by: Tomas Winkler
> > > Reviewed-by: Uma Shankar
> > > ---
> > > MAINTAINERS | 1 +
> > > include/linux/mei_hdcp.h | 91
>
> > > 2 files changed, 92 insertions(+)
> > > create mode 100644 include/linux/mei_hdcp.h
> > >
> > > diff --git a/MAINTAINERS b/MAINTAINERS index
> > > 1026150ae90f..2fd6555bf040 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -7540,6 +7540,7 @@ L: linux-ker...@vger.kernel.org
> > > S: Supported
> > > F: include/uapi/linux/mei.h
> > > F: include/linux/mei_cl_bus.h
> > > +F: include/linux/mei_hdcp.h
> > > F: drivers/misc/mei/*
> > > F: drivers/watchdog/mei_wdt.c
> > > F: Documentation/misc-devices/mei/*
> > > diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h new
> > > file mode 100644 index ..716123003dd1
> > > --- /dev/null
> > > +++ b/include/linux/mei_hdcp.h
> > > @@ -0,0 +1,91 @@
> > > +/*
RE: [PATCH v8 04/35] drm/i915: Initialize HDCP2.2
> -Original Message- > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter > Sent: Friday, December 07, 2018 16:17 > To: C, Ramalingam > Cc: Daniel Vetter ; intel-...@lists.freedesktop.org; dri- > de...@lists.freedesktop.org; daniel.vet...@ffwll.ch; Winkler, Tomas > ; Shankar, Uma > Subject: Re: [PATCH v8 04/35] drm/i915: Initialize HDCP2.2 > > On Fri, Dec 07, 2018 at 10:24:26AM +0530, C, Ramalingam wrote: > > > > On 12/6/2018 3:33 PM, Daniel Vetter wrote: > > > On Tue, Nov 27, 2018 at 04:13:02PM +0530, Ramalingam C wrote: > > > > Add the HDCP2.2 initialization to the existing HDCP1.4 stack. > > > With the comments below addressed the commit message is a bit > > > untrue, since this just wires up a basic hdcp2_supported flag in a few > places. > > > Please make that clear. > > > > > > > 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 > > > > > > > > Signed-off-by: Ramalingam C > > > > --- > > > > drivers/gpu/drm/i915/i915_drv.c | 2 + > > > > drivers/gpu/drm/i915/intel_dp.c | 3 +- > > > > drivers/gpu/drm/i915/intel_drv.h | 16 +++- > > > > drivers/gpu/drm/i915/intel_hdcp.c | 172 -- > > > > > drivers/gpu/drm/i915/intel_hdmi.c | 2 +- > > > > 5 files changed, 130 insertions(+), 65 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c > > > > b/drivers/gpu/drm/i915/i915_drv.c index b1d23c73c147..fbedd5024afe > > > > 100644 > > > > --- a/drivers/gpu/drm/i915/i915_drv.c > > > > +++ b/drivers/gpu/drm/i915/i915_drv.c > > > > @@ -1755,6 +1755,8 @@ void i915_driver_unload(struct drm_device > *dev) > > > > disable_rpm_wakeref_asserts(dev_priv); > > > > + intel_hdcp_exit(dev_priv); > > > This smells like a separate patch. Needs to be split out. Looking at > > > the implementation of intel_hdcp_exit I think it's papering over > > > some unload trouble. We should be shutting down all the outputs on > > > driver unload, which mei should be triggering (with the component > > > stuff), which means this code should be unecessary. But I'm not sure. > > > > > > Either way needs to be split out, but I think proper solution is to > > > drop it. > > > > As we discussed, during v7-->v8 i changed the component usage such that it > wont affect i915 load/unload. > > During the first connector init, component master will be added. And > > during the mei_client dev and driver binding, component will be added hence > the binding will happen with interface initialization from mei. > > > > Upon HDCP2.2 request, component binding will be checked before > attempting for HDCP2.2 auth. > > So component master unbind triggered due to mei component_del, will > teardown the HDCP2.2 capability of the I915. > > > > So in case of I915 unload trigger, from whatsoever reason, we need to > > clear the HDCP activities and bring down the i915_hdcp_component_master > and the interface with mei. For this purpose only intel_hdcp_exit is written > here. > > Summarizing our irc discussion: > > - I like the component usage of v7 much more. > > - I still don't think we have a use-case for loading/unloading mei_hdcp on > demand, or at least not in lockstep with i915.ko: We are testing all the MEI modules reloading, this would be suddenly an exception. > - CrOS won't use
RE: [PATCH v2 10/42] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session
>
>
>
> On Thursday 08 March 2018 06:47 PM, Winkler, Tomas wrote:
> >> Request ME FW to start the HDCP2.2 session for a intel port.
> >> Prepares payloads for command WIRED_INITIATE_HDCP2_SESSION and
> sent
> >> 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.
> >>
> >> Signed-off-by: Ramalingam C <ramalinga...@intel.com>
> >> ---
> >> drivers/misc/mei/hdcp/mei_hdcp.c | 73
> >>
> >> include/linux/mei_hdcp.h | 11 ++
> >> 2 files changed, 84 insertions(+)
> >>
> >> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> >> b/drivers/misc/mei/hdcp/mei_hdcp.c
> >> index 63f77800a6f7..516ad6a40616 100644
> >> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> >> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> >> @@ -29,6 +29,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >>
> >> #include "mei_hdcp.h"
> >>
> >> @@ -46,6 +47,78 @@ static inline bool
> >> mei_cldev_active_and_enabled(struct mei_cl_device *cldev)
> >>return mei_cldev_enabled(cldev);
> >> }
> >>
> >> +/**
> >> + * mei_initiate_hdcp2_session:
> >> + *Function to start a Wired HDCP2.2 Tx Session with ME FW
> >> + *
> >> + * @data : Intel HW specific Data
> >> + * @ake_data : ptr to store AKE_Init
> >> + *
> >> + * Returns 0 on Success, <0 on Failure.
> >> + */
> >> +int mei_initiate_hdcp2_session(struct mei_hdcp_data *data,
> >> + struct hdcp2_ake_init *ake_data) {
> >
> > You should use cldev as a first argument for all those functions
> data has it as a member. Should it be explicit?
I believe, you should.
cldev is the object this function operates on so it should be explicitly and
data provides the input paramterss
Thanks
Tomas
> >
> >> + /* check for the mei_device enabled or not */
> >> + if (!mei_cldev_active_and_enabled(data->cldev))
> >> + return -ENODEV;
> > No reason cldev will be NULL here.
> Ok. But device could be disabled right? we might want to check the enabled
> state of the device?
The device might go under reset any time during operations.
so it is useless to test at this point (unless you know some other flow to take)
as the underlying service already checks that for you and will return
appropriate error (ENODEV).
Thanks
Tomas
> >
> >> + dev = >cldev->dev;
> >> +
> >> + /* Fill header details */
> > Those types of comments are redundant.
> >> + 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;
> >> +
> >> + /* Fill in the In Data */
> > Those types of comments are redundant.
> >> + session_init_in.port.integrated_port_type = data->port_type;
> >> + session_init_in.port.physical_port = data->port;
> >> + session_init_in.protocol = (uint8_t)data->protocol;
> >> +
> >> + /* Request to ME */
> >> + byte = mei_cldev_send(data->cldev, (u8 *)_init_in,
> >> +sizeof(session_init_in));
> >> + if (byte < 0) {
> >> + dev_err(dev, "mei_cldev_send failed. %d\n", (int)byte);
> >> + return byte;
> >> + }
> >> +
> >> + /* Response from ME */
> >> + byte = mei_cldev_recv(data->cldev, (u8 *)_init_out,
> >> +sizeof(session_init_out));
> >> + if (byte < 0) {
> >> + dev_err(dev, "mei_cldev_recv failed. %d\n", (int)byte);
> >> + return byte;
> >> + }
> >> +
> >> + status = (enum me_hdcp_status)session_init_out.header.status;
> > Useless cast
> Oops. Will remove it.
>
> --Ram
> >> + if (status != ME_HDCP_STATUS_SUCCESS) {
> >> + dev_err(dev, "ME cmd 0x%08X Failed. Status: 0x%X\n",
> >> + WIRED_INITIATE_HDCP2_SESSION, status);
> >> + return -1;
> >> + }
&
RE: [PATCH v2 04/42] misc/mei/hdcp: Client driver for HDCP application
> >> +MODULE_AUTHOR("Intel Corporation");
> >> +MODULE_LICENSE("GPL");
> >
> > Dual License
>
> MODULE_LICENSE("GPL-2.0+ OR BSD-3-Clause");
>
> Will this work?
No, it should be
MODULE_LICENSE("Dual BSD/GPL");
Tomas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
