>
> 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
>
> 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 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 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-...@lists.freedesktop.org;
> > > dri-devel@lists.freedesktop.org; Wink
> -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
>
>
>
> 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(!
> 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
, 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'
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-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> daniel.vet...@ffwll.ch; Wink
>
> 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 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
> 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
> 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:
>
> 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 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
> 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/
>
> 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]
>
>
> 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 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 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 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
> 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]
> Red
>
> 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]
>
> 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:
> cl
> -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/4
> 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 messag
> 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.
> C
>
> 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 enhanc
> 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 +++
>
> 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"
>
> 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 change
>
> > >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.
> >
>
> >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
> >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.
>
>
> >-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, Ramal
>
> 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
> -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/4
>
> 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
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
> 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:
>
> 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;
> >>>
>
> 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_hdc
>
> 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
> 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
&g
>
> 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 h
> 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 mast
>
> 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]
>
1 - 100 of 112 matches
Mail list logo
