>
> On Thu, Sep 19, 2024 at 09:54:24AM +, Winkler, Tomas wrote:
> > > On Mon, Sep 16, 2024 at 04:49:17PM +0300, Alexander Usyskin wrote:
>
> > > > @@ -0,0 +1,142 @@
> > > > +// SPDX-License-Identifier: GPL-2.0
> > > > +/*
> > &
>
> On Mon, Sep 16, 2024 at 04:49:20PM +0300, Alexander Usyskin wrote:
>
> > From: Tomas Winkler
> >
> > Register the on-die spi device with the mtd subsystem.
> > Refcount spi object on _get and _put mtd callbacks.
>
> This is a MTD driver, it should be in drivers/mtd.
Okay.
>
> > +static
>
> On Mon, Sep 16, 2024 at 04:49:18PM +0300, Alexander Usyskin wrote:
>
> > In intel-dg spi, there is no access to the spi controller, the
> > information is extracted from the descriptor region.
>
> Which information? I can't tell what this patch is supposed to do; as with
> the
> first patc
>
> On Mon, Sep 16, 2024 at 04:49:17PM +0300, Alexander Usyskin wrote:
>
> > Add auxiliary driver for intel discrete graphics on-die spi device.
>
> This doesn't actually do anything AFAICT? It doesn't register with any
> subsystem or anything. Please don't submit empty boilerplate like this
> -Original Message-
> From: Teres Alexis, Alan Previn
> Sent: Tuesday, November 14, 2023 5:32 PM
> To: ville.syrj...@linux.intel.com; Winkler, Tomas
> Cc: gre...@linuxfoundation.org; Usyskin, Alexander
> ; linux-ker...@vger.kernel.org; intel-
> g...@lists.fr
>
> On Wed, Sep 20, 2023 at 01:52:07PM +, Usyskin, Alexander wrote:
>
> > I've tried to register spi controller with a spi-mem ops, but I can't find
> > a way
> to connect to mtd subsystem.
> > I took spi-intel as example, which connects to spi-nor but it relies on
> > JDEC ID
> of flash
> __le64 and friends should go through the cpu_to_* and *_to_cpu
> accessors:
>
> drivers/gpu/drm/i915/pxp/intel_pxp_huc.c:41:35: warning: incorrect type in
> assignment (different base types)
> drivers/gpu/drm/i915/pxp/intel_pxp_huc.c:41:35:expected restricted
> __le64 [assigned] [usertype]
>
> 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 Usyski
>
> 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
> i
>
>
> On 21/11/2022 09:35, Winkler, Tomas wrote:
> >>
> >> From: José Roberto de Souza
> >>
> >> For multi-tile setups the GSC operational only on the tile 0.
> >> Skip GSC auxiliary device creation for all other tiles in GSC device init
&
>
> From: José Roberto de Souza
>
> For multi-tile setups the GSC operational only on the tile 0.
> Skip GSC auxiliary device creation for all other tiles in GSC device init
> code.
> Initialize basic GSC fields and use the same path as HECI1 (HECI_PXP) device
> disable.
>
> Cc: Tomas Winkler
>
>
> 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
>
> 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
>
> On Mon, Oct 31, 2022 at 07:51:17AM +0200, Alexander Usyskin wrote:
> > From: José Roberto de Souza
> >
> > For multi-tile setups the GSC operational only on the tile 0.
> > Skip GSC auxiliary device creation for all other tiles.
> >
> > Cc: Tomas Winkler
> > Cc: Vitaly Lubart
> > Signed-o
> 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 add
>
> 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
> 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
> > > >
>
> 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
&g
> >
> > > -Original Message-
> > > From: Greg Kroah-Hartman
> > > Sent: Friday, September 09, 2022 09:16
> > > To: Ceraolo Spurio, Daniele
> > > Cc: intel-gfx@lists.freedesktop.org;
> > > dri-de...@lists.freedesktop.org; Wink
> -Original Message-
> From: Greg Kroah-Hartman
> Sent: Friday, September 09, 2022 09:16
> To: Ceraolo Spurio, Daniele
> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> Winkler, Tomas ; Lubart, Vitaly
> ; Teres Alexis, Alan Previn
>
>
>
> 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 sc
> 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 f
> > >
> > > 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;
> > > >
> 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
>
> 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(!
>
>
>
> On 9/7/2022 8:58 AM, Tomas Winkler wrote:
> > From: Vitaly Lubart
> >
> > Exported common mkhi definitions from bus-fixup.c into a separate
> > header file mkhi.h for other driver usage.
> >
> > Signed-off-by: Vitaly Lubart
> > Signed-off-by: Tomas Winkler
> > Signed-off-by: Alexander
>
>
> On 8/6/2022 5:26 AM, Tomas Winkler wrote:
> > From: Vitaly Lubart
> >
> > Exported common mkhi definitions from bus-fixup.c into a separate
> > header file mkhi.h for other driver usage.
> >
> > Signed-off-by: Vitaly Lubart
> > Signed-off-by: Tomas Winkler
> > Signed-off-by: Alexander U
> -Original Message-
> From: Teres Alexis, Alan Previn
> Sent: Thursday, August 04, 2022 01:08
> To: Ceraolo Spurio, Daniele ; intel-
> g...@lists.freedesktop.org
> Cc: Winkler, Tomas ; Lubart, Vitaly
>
> Subject: Re: [PATCH 02/15] mei: add support to GSC ex
>
> Looks good, just a minor nit.
>
> Reviewed-by: Alan Previn
>
>
> On Wed, 2022-07-06 at 14:43 +0300, Alexander Usyskin wrote:
> > From: Tomas Winkler
> >
> > GSC requires more operational memory than available on chip.
> > Reserve 4M of LMEM for GSC operation. The memory is provided to the
>
> On Wed, Jul 06, 2022 at 02:43:33PM +0300, Alexander Usyskin wrote:
> > Add slow_fw flag to the mei auxiliary device info to inform the mei
> > driver about slow underlying firmware.
> > Such firmware will require to use larger operation timeouts.
> >
> > Signed-off-by: Alexander Usyskin
> >
>
> On Sun, Jun 19, 2022 at 04:37:20PM +0300, Alexander Usyskin wrote:
> > From: Tomas Winkler
> >
> > CC: Vitaly Lubart
> > Signed-off-by: Tomas Winkler
>
> We can not take patches without any changelog text, you know this :(
Okay, will add some more info.
>
> > ---
> > drivers/misc/mei/d
Thank you, we will handle that.
Please mind our weekend.
Thanks
Tomas
> -Original Message-
> From: Pavel Machek
> Sent: Sunday, October 17, 2021 10:24
> To: kernel list ; Lubart, Vitaly
> ; Winkler, Tomas ;
> Ceraolo Spurio, Daniele ;
> jani.nik...@linux.in
>
>
> > - Ursprüngliche Mail -
> > >> > I'm not sure whether we want to take that path.
> > >
> > > Hi Richard is there any way we can try to unclutter this ?
> >
> > Of course there is a way. :-)
> > Your use-case really seems to be special and MTD needs an improvement.
> > Miquel, Vigne
> - Ursprüngliche Mail -
> >> > I'm not sure whether we want to take that path.
> >
> > Hi Richard is there any way we can try to unclutter this ?
>
> Of course there is a way. :-)
> Your use-case really seems to be special and MTD needs an improvement.
> Miquel, Vignesh and I just need t
> On Wed, 17 Feb 2021, "Winkler, Tomas" wrote:
> >> On Tue, 16 Feb 2021, Tomas Winkler wrote:
> >> > Add the dGFX spi region map and convey it via mfd cell platform
> >> > data to the spi child device.
> >> >
> >> > Cc:
>
>
> >
> > )On Tue, Feb 16, 2021 at 7:26 PM Tomas Winkler
> >
> > wrote:
> > > Because the graphic card may undergo reset at any time and basically
> > > hot unplug all its child devices, this series also provides a fix to
> > > the mtd framework to make the reset graceful.
> >
> > Well, just
> On Thu, Feb 18, 2021 at 10:06:08PM -0800, Winkler, Tomas wrote:
> >
> >>
> >> On Wed, Feb 17, 2021 at 08:58:12PM +, Winkler, Tomas wrote:
> >> >>
> >> >> On Tue, 16 Feb 2021, Tomas Winkler
> wrote:
> >> >> >
>
> On Wed, Feb 17, 2021 at 08:58:12PM +, Winkler, Tomas wrote:
> >>
> >> On Tue, 16 Feb 2021, Tomas Winkler wrote:
> >> > Add the platform driver for i915 on-die spi device, exposed via mfd
> >> > framework.
> >> >
> >>
>
> On Wed, Feb 17, 2021 at 08:58:12PM +, Winkler, Tomas wrote:
> >>
> >> On Tue, 16 Feb 2021, Tomas Winkler wrote:
> >> > Add the platform driver for i915 on-die spi device, exposed via mfd
> >> > framework.
> >> >
> >>
>
> On Tue, 16 Feb 2021, Tomas Winkler wrote:
> > Add the platform driver for i915 on-die spi device, exposed via mfd
> > framework.
> >
> > Cc: Rodrigo Vivi
> > Cc: Lucas De Marchi
> > Signed-off-by: Tomas Winkler
> > ---
> > drivers/gpu/drm/i915/Kconfig | 2 +
> > drivers/gpu/
> On Tue, 16 Feb 2021, Tomas Winkler wrote:
> > Add the dGFX spi region map and convey it via mfd cell platform data
> > to the spi child device.
> >
> > Cc: Rodrigo Vivi
> > Cc: Lucas De Marchi
> > Signed-off-by: Tomas Winkler
> > ---
> > drivers/gpu/drm/i915/spi/intel_spi.c | 9 +
> >
> On Tue, Feb 16, 2021 at 08:19:17PM +0200, Tomas Winkler wrote:
> >Enable access to internal spi on descrete devices via a child device.
> >The spi child device is exposed via MFD framework.
> >
> >Cc: Rodrigo Vivi
> >Cc: Lucas De Marchi # v3
> >Signed-off-by: Tomas Winkler
> >---
> > drivers
>
> On Tue, 16 Feb 2021, Tomas Winkler wrote:
> > Intel discrete graphic devices have internal spi storage, that holds
> > firmware and oprom images. The spi device is exposed to the user space
> > via mtd framework to be accessed during manufacturing.
> > The device is hardware locked after manu
>
> On Tue, 16 Feb 2021, Tomas Winkler wrote:
> > Intel discrete graphic devices have internal spi storage, that holds
> > firmware and oprom images. The spi device is exposed to the user space
> > via mtd framework to be accessed during manufacturing.
> > The device is hardware locked after ma
>
> )On Tue, Feb 16, 2021 at 7:26 PM Tomas Winkler
> wrote:
> > Because the graphic card may undergo reset at any time and basically
> > hot unplug all its child devices, this series also provides a fix to
> > the mtd framework to make the reset graceful.
>
> Well, just because MTD does not wo
> -Original Message-
> From: Joonas Lahtinen
> Sent: Monday, November 16, 2020 11:47
> To: Huang, Sean Z ; Intel-
> g...@lists.freedesktop.org
> Cc: Winkler, Tomas
> Subject: Re: [Intel-gfx] [PATCH 23/27] mei: bus: enable pavp device.
>
> Obviously needs
, 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 num
>
> 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
>
> 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 a
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
> 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: Ja
> 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 Niku
> 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 Nik
>
> >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 deta
>
> 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
>
> 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.
> > >
> >
> 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 t
>
> 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 Nik
>
> 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.
> >
> 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
>
> Sig
>
> 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 up
>
> 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.
> > >
> > >
>
> 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.
> > >
> 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 tr
> 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 | 1
>
> 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/i91
019 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 wrot
> 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
>
> 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/me
>
> 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'
>
> During i915 unload, it appears that it may get stuck waiting on a workqueue
> being hogged by mei:
Thanks for the bug report, but this is not a proper fix, we will try to work it
out.
Thanks
Tomas
>
> <7> [212.666912] i915 :00:02.0: [drm:drm_client_release] drm_fb_helper
> <3> [308.544
e
> >
> > 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
> >
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-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> daniel.vet...@ffwll.ch; Wink
> 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]
>
> 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
>
> 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]
>
> 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:
> clde
>
> 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 me
>
> 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]
>
>
> 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
> manageme
> 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 com
> 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 pair
> 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:
>
> 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]
> R
>
> 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]
>
> 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/
>
> 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/\/\*\*/\/
>
> 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 he
>
> 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
> managem
>
>
>
> 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
&
>
> 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 star
> 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:
> c
>
> 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-m
> 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
>
> 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 [To
>
> 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
> manageme
>
> 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
>
> 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]
>
> 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 pass
> 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 com
1 - 100 of 148 matches
Mail list logo
