On Wed, Feb 01, 2023 at 03:28:01PM -0800, Matt Atwood wrote:
> This patch fixes memory leaks on error escapes in i915_scatterlist.c
>
> Fixes: c3bfba9a2225 ("drm/i915: Check for integer truncation on scatterlist
> creation")
> Cc: Chris Wilson
> Signed-off-by: Matt Atwood
Reviewed-by: Harish
On 01.02.2023 17:51, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
As the logic for selecting the register and corresponsing values grew, the
code become a bit unsightly. Consolidate by storing the required values at
engine init time in the engine itself, and by doing so minimise the amount
of
Gentle Reminder!
The patch is pending since a long time.
Thanks and Regards,
Arun R Murthy
---
> -Original Message-
> From: Murthy, Arun R
> Sent: Monday, January 23, 2023 12:14 PM
> To: 'Ville Syrjälä'
> Cc: 'intel-gfx@lists.freedesktop.org' ;
> Syrjala, Ville
>
> -Original Message-
> From: Alex Williamson
> Sent: Thursday, February 2, 2023 12:15 PM
> To: Liu, Yi L
> Cc: Matthew Rosato ; pbonz...@redhat.com;
> j...@nvidia.com; coh...@redhat.com; far...@linux.ibm.com;
> pmo...@linux.ibm.com; borntrae...@linux.ibm.com;
> fran...@linux.ibm.com;
On Thu, 2 Feb 2023 03:46:59 +
"Liu, Yi L" wrote:
> > From: Alex Williamson
> > Sent: Thursday, February 2, 2023 7:28 AM
> >
> > On Wed, 1 Feb 2023 14:20:10 -0500
> > Matthew Rosato wrote:
> >
> > > After 51cdc8bc120e, we have another deadlock scenario between the
> > > kvm->lock and
> From: Alex Williamson
> Sent: Thursday, February 2, 2023 7:28 AM
> >
> > +#ifdef CONFIG_HAVE_KVM
> > +static bool vfio_kvm_get_kvm_safe(struct vfio_device *device, struct kvm
> *kvm)
>
> I'm tempted to name these vfio_device_get_kvm_safe() and only pass the
> vfio_device, where of course we
> From: Liu, Yi L
> Sent: Thursday, February 2, 2023 11:47 AM
> > > ret = vfio_device_open(device, device->group->iommufd,
> > > device->group->kvm);
> >
> > We're using device->group->kvm outside of kvm_ref_lock here, it should
> > be using device->kvm.
>
> Existing
> From: Alex Williamson
> Sent: Thursday, February 2, 2023 7:28 AM
>
> On Wed, 1 Feb 2023 14:20:10 -0500
> Matthew Rosato wrote:
>
> > After 51cdc8bc120e, we have another deadlock scenario between the
> > kvm->lock and the vfio group_lock with two different codepaths acquiring
> > the locks
== Series Details ==
Series: drm/i915/hwmon: Enable PL1 power limit
URL : https://patchwork.freedesktop.org/series/113578/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12681 -> Patchwork_113578v1
Summary
---
> From: Matthew Rosato
> Sent: Wednesday, February 1, 2023 10:43 PM
>
> On 2/1/23 7:43 AM, Liu, Yi L wrote:
> >> From: Jason Gunthorpe
> >> Sent: Wednesday, February 1, 2023 4:26 AM
> >>
> >> On Tue, Jan 31, 2023 at 03:06:35PM -0500, Matthew Rosato wrote:
> >>> @@ -799,13 +794,14 @@
> >>
Previous documentation suggested that PL1 power limit is always
enabled. However we now find this not to be the case on some
platforms (such as ATSM). Therefore enable PL1 power limit during hwmon
initialization.
Signed-off-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/i915_hwmon.c | 5 +
1
On Tue, 2023-01-17 at 23:15 -0800, Niranjana Vishwanathapura wrote:
> DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM
> buffer objects (BOs) or sections of a BOs at specified GPU virtual
> addresses on a specified address space (VM). Multiple mappings can map
> to the same
== Series Details ==
Series: vfio: fix deadlock between group lock and kvm lock (rev3)
URL : https://patchwork.freedesktop.org/series/113535/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12681_full -> Patchwork_113535v3_full
== Series Details ==
Series: drm/i915: Fix memory leaks in scatterlist
URL : https://patchwork.freedesktop.org/series/113576/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12681 -> Patchwork_113576v1
Summary
---
== Series Details ==
Series: vfio: fix deadlock between group lock and kvm lock (rev3)
URL : https://patchwork.freedesktop.org/series/113535/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12681 -> Patchwork_113535v3
== Series Details ==
Series: series starting with [1/4] drm/i915/pvc: Annotate two more
workaround/tuning registers as MCR
URL : https://patchwork.freedesktop.org/series/113573/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12681_full -> Patchwork_113573v1_full
== Series Details ==
Series: vfio: fix deadlock between group lock and kvm lock (rev3)
URL : https://patchwork.freedesktop.org/series/113535/
State : warning
== Summary ==
Error: dim checkpatch failed
c2474b730a36 vfio: fix deadlock between group lock and kvm lock
-:23:
This patch fixes memory leaks on error escapes in i915_scatterlist.c
Fixes: c3bfba9a2225 ("drm/i915: Check for integer truncation on scatterlist
creation")
Cc: Chris Wilson
Signed-off-by: Matt Atwood
---
drivers/gpu/drm/i915/i915_scatterlist.c | 8 ++--
1 file changed, 6 insertions(+), 2
On Wed, 1 Feb 2023 14:20:10 -0500
Matthew Rosato wrote:
> After 51cdc8bc120e, we have another deadlock scenario between the
> kvm->lock and the vfio group_lock with two different codepaths acquiring
> the locks in different order. Specifically in vfio_open_device, vfio
> holds the vfio
== Series Details ==
Series: series starting with [1/4] drm/i915/pvc: Annotate two more
workaround/tuning registers as MCR
URL : https://patchwork.freedesktop.org/series/113573/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12681 -> Patchwork_113573v1
== Series Details ==
Series: series starting with [1/4] drm/i915/pvc: Annotate two more
workaround/tuning registers as MCR
URL : https://patchwork.freedesktop.org/series/113573/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be
Although register information in the bspec includes a field that is
supposed to reflect a register's reset characteristics (i.e., whether a
register maintains its value through engine resets), it's been
discovered that this information is incorrect for some register ranges
(i.e., registers that
The UNSLICE_UNIT_LEVEL_CLKGATE register programmed by this workaround
has 'BUS' style reset, indicating that it does not lose its value on
engine resets. Furthermore, this register is part of the GT forcewake
domain rather than the RENDER domain, so it should not be impacted by
RCS engine resets.
XEHPC_LNCFMISCCFGREG0 and XEHPC_L3SCRUB are both in MCR register ranges
on PVC (with HALFBSLICE and L3BANK replication respectively), so they
should be explicitly declared as MCR registers and use MCR-aware
workaround handlers.
The workarounds/tuning settings should still be applied properly on
Although registers in the L3 bank/node configuration ranges are marked
as having "DEV" reset characteristics in the bspec, this appears to be a
hold-over from pre-Xe_HP platforms. In reality, these registers
maintain their values across engine resets, meaning that workarounds
and tuning settings
On Wed, Feb 01, 2023 at 10:37:06AM -0800, John Harrison wrote:
> On 2/1/2023 07:31, Rodrigo Vivi wrote:
> > On Wed, Feb 01, 2023 at 03:11:31PM +1100, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > On Tue, 31 Jan 2023 10:27:29 -0800 John Harrison
> > > wrote:
> > > > On 1/31/2023 04:44, Andy
== Series Details ==
Series: vfio: fix deadlock between group lock and kvm lock (rev2)
URL : https://patchwork.freedesktop.org/series/113535/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12680_full -> Patchwork_113535v2_full
== Series Details ==
Series: vfio: fix deadlock between group lock and kvm lock (rev2)
URL : https://patchwork.freedesktop.org/series/113535/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12680 -> Patchwork_113535v2
== Series Details ==
Series: drm/i915: Consolidate TLB invalidation flow
URL : https://patchwork.freedesktop.org/series/113563/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12680_full -> Patchwork_113563v1_full
Summary
== Series Details ==
Series: drm/i915/quirks: Add inverted backlight quirk for HP 14-r206nv
URL : https://patchwork.freedesktop.org/series/113568/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12680 -> Patchwork_113568v1
After 51cdc8bc120e, we have another deadlock scenario between the
kvm->lock and the vfio group_lock with two different codepaths acquiring
the locks in different order. Specifically in vfio_open_device, vfio
holds the vfio group_lock when issuing device->ops->open_device but some
drivers (like
On Wed, 01 Feb 2023, Mavroudis Chatzilaridis wrote:
> This laptop uses inverted backlight PWM. Thus, without this quirk,
> backlight brightness decreases as the brightness value increases and
> vice versa.
>
> Signed-off-by: Mavroudis Chatzilaridis
Thanks for the patch, but this really needs a
Hi Kamil,
On Wednesday, 1 February 2023 19:21:57 CET Kamil Konieczny wrote:
> Hi Janusz,
>
> please send patches to igt ML and add other addresses to cc:
> I have one nit, see below.
>
> On 2023-01-31 at 10:17:31 +0100, Janusz Krzysztofik wrote:
> > Add a new subtest focused on exercising
This laptop uses inverted backlight PWM. Thus, without this quirk,
backlight brightness decreases as the brightness value increases and
vice versa.
Signed-off-by: Mavroudis Chatzilaridis
---
drivers/gpu/drm/i915/display/intel_quirks.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
On Wed, 2023-02-01 at 10:07 -0800, Lucas De Marchi wrote:
> On Wed, Feb 01, 2023 at 09:20:42AM -0800, Coelho, Luciano wrote:
> > On Wed, 2023-02-01 at 19:09 +0200, Jani Nikula wrote:
> > > On Wed, 01 Feb 2023, Luca Coelho wrote:
> > > > There are a few macros (e.g. DPLL()) that implicitly use
On 1/31/2023 13:44, Michal Wajdeczko wrote:
Just recently we switched over to new GuC oriented log macros but in
the meantime yet another message was added that we missed to update.
While around improve that new message by adding engine name and use
existing helpers to check for context state.
On 2/1/2023 07:31, Rodrigo Vivi wrote:
On Wed, Feb 01, 2023 at 03:11:31PM +1100, Stephen Rothwell wrote:
Hi all,
On Tue, 31 Jan 2023 10:27:29 -0800 John Harrison
wrote:
On 1/31/2023 04:44, Andy Shevchenko wrote:
On Tue, Jan 31, 2023 at 01:03:05PM +1100, Stephen Rothwell wrote:
Today's
Hi Janusz,
please send patches to igt ML and add other addresses to cc:
I have one nit, see below.
On 2023-01-31 at 10:17:31 +0100, Janusz Krzysztofik wrote:
> Add a new subtest focused on exercising interaction between perf open /
> close operations, which replace active barriers with perf
== Series Details ==
Series: drm/i915: Consolidate TLB invalidation flow
URL : https://patchwork.freedesktop.org/series/113563/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12680 -> Patchwork_113563v1
Summary
---
On Wed, Feb 01, 2023 at 09:20:42AM -0800, Coelho, Luciano wrote:
On Wed, 2023-02-01 at 19:09 +0200, Jani Nikula wrote:
On Wed, 01 Feb 2023, Luca Coelho wrote:
> There are a few macros (e.g. DPLL()) that implicitly use dev_priv, by
> using other macros that implcitily use dev_priv.
>
> In an
== Series Details ==
Series: drm/i915: Consolidate TLB invalidation flow
URL : https://patchwork.freedesktop.org/series/113563/
State : warning
== Summary ==
Error: dim checkpatch failed
c0fc33d4e83f drm/i915: Consolidate TLB invalidation flow
-:99: CHECK:PARENTHESIS_ALIGNMENT: Alignment
On Tue, Jan 31, 2023 at 02:21:26AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> On icl+ SAGV is controlled by masking of the QGV points.
> Reduce the QGV point mask to the same kind of enabled vs.
> disable information that we had on previous platforms.
> Will be useful in answering the
On Tue, Jan 31, 2023 at 02:21:24AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Due to a workaround we have to make sure the WM1 watermarks block/lines
> values are sensible even when WM1 is disabled. To that end we copy those
> values from WM0.
>
> However since we now keep each wm
== Series Details ==
Series: drm/i915: add guard page to ggtt->error_capture
URL : https://patchwork.freedesktop.org/series/113560/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12680 -> Patchwork_113560v1
Summary
---
On Wed, Feb 01, 2023 at 09:26:29AM -0800, Lucas De Marchi wrote:
> On Wed, Feb 01, 2023 at 02:09:54PM +0200, Ville Syrjälä wrote:
> >On Wed, Feb 01, 2023 at 11:59:19AM +0200, Jani Nikula wrote:
> >> On Tue, 31 Jan 2023, Lucas De Marchi wrote:
> >> > Instead of using the common
On Wed, Feb 01, 2023 at 02:09:54PM +0200, Ville Syrjälä wrote:
On Wed, Feb 01, 2023 at 11:59:19AM +0200, Jani Nikula wrote:
On Tue, 31 Jan 2023, Lucas De Marchi wrote:
> Instead of using the common DISPLAY_MMIO_BASE(dev_priv) in all single
> macros, only use them in the macros that are to be
Hi Niranjana,
On Tue, Jan 17, 2023 at 11:15:50PM -0800, Niranjana Vishwanathapura wrote:
> As persistent vmas can be partialled mapped to an object,
> remove restriction which require vma resource sg table to
> be just pointer to object's sg table.
>
> Reviewed-by: Matthew Auld
> Signed-off-by:
Hi Niranjana,
On Tue, Jan 17, 2023 at 11:15:49PM -0800, Niranjana Vishwanathapura wrote:
> Expose i915_gem_object_max_page_size() function non-static
> which will be used by the vm_bind feature.
>
> Reviewed-by: Matthew Auld
> Signed-off-by: Niranjana Vishwanathapura
> Signed-off-by: Andi
On Wed, 2023-02-01 at 19:09 +0200, Jani Nikula wrote:
> On Wed, 01 Feb 2023, Luca Coelho wrote:
> > There are a few macros (e.g. DPLL()) that implicitly use dev_priv, by
> > using other macros that implcitily use dev_priv.
> >
> > In an effort to align all definitions of struct drm_i915_private
On Wed, Feb 01, 2023 at 07:09:12PM +0200, Jani Nikula wrote:
On Wed, 01 Feb 2023, Luca Coelho wrote:
There are a few macros (e.g. DPLL()) that implicitly use dev_priv, by
using other macros that implcitily use dev_priv.
In an effort to align all definitions of struct drm_i915_private to be
Hi Niranjana,
On Tue, Jan 17, 2023 at 11:15:48PM -0800, Niranjana Vishwanathapura wrote:
> Add function __i915_sw_fence_await_reservation() for
> asynchronous wait on a dma-resv object with specified
> dma_resv_usage. This is required for async vma unbind
> with vm_bind.
>
> Reviewed-by: Matthew
On Wed, 01 Feb 2023, Luca Coelho wrote:
> There are a few macros (e.g. DPLL()) that implicitly use dev_priv, by
> using other macros that implcitily use dev_priv.
>
> In an effort to align all definitions of struct drm_i915_private to be
> declared as i915 instead of arbitrarily using either i915
On Wed, 2023-02-01 at 17:10 +0100, Andrzej Hajda wrote:
> On 01.02.2023 14:53, Luca Coelho wrote:
> > There are a few macros (e.g. DPLL()) that implicitly use dev_priv, by
> > using other macros that implcitily use dev_priv.
> >
> > In an effort to align all definitions of struct drm_i915_private
From: Tvrtko Ursulin
As the logic for selecting the register and corresponsing values grew, the
code become a bit unsightly. Consolidate by storing the required values at
engine init time in the engine itself, and by doing so minimise the amount
of invariant platform and engine checks during
On 01.02.2023 14:53, Luca Coelho wrote:
There are a few macros (e.g. DPLL()) that implicitly use dev_priv, by
using other macros that implcitily use dev_priv.
In an effort to align all definitions of struct drm_i915_private to be
declared as i915 instead of arbitrarily using either i915 or
Hi Ashutosh,
On Tuesday, 31 January 2023 19:36:50 CET Dixit, Ashutosh wrote:
> On Tue, 31 Jan 2023 09:36:30 -0800, Janusz Krzysztofik wrote:
> >
> > Since Chris' subtest didn't help in triggering the list corruption, I've
> > developed a new subtest that can do it. Since it is almost identical
On Wed, Feb 01, 2023 at 03:11:31PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> On Tue, 31 Jan 2023 10:27:29 -0800 John Harrison
> wrote:
> >
> > On 1/31/2023 04:44, Andy Shevchenko wrote:
> > > On Tue, Jan 31, 2023 at 01:03:05PM +1100, Stephen Rothwell wrote:
> > >>
> > >> Today's linux-next
Some platforms (ADL, RPL, DG2) during CPU read of mapped GTT pages
tries to prefetch data beyond page table boundary. If the next PTE
in GTT points to invalid address it can cause DMAR errors.
Adding guard PTE pointing to scratch page solves the issue
in case of ggtt->error_capture.
On Tue, Jan 31, 2023 at 06:13:10PM -0500, Lyude Paul wrote:
> On Tue, 2023-01-31 at 17:05 +0200, Imre Deak wrote:
> > Atm, drm_dp_remove_payload() uses the same payload state to both get the
> > vc_start_slot required for the payload removal DPCD message and to
> > deduct time_slots from
On 2/1/23 7:43 AM, Liu, Yi L wrote:
>> From: Jason Gunthorpe
>> Sent: Wednesday, February 1, 2023 4:26 AM
>>
>> On Tue, Jan 31, 2023 at 03:06:35PM -0500, Matthew Rosato wrote:
>>> @@ -799,13 +794,14 @@
>> EXPORT_SYMBOL_GPL(vfio_file_enforced_coherent);
>>> void vfio_file_set_kvm(struct file
On Tue, Jan 31, 2023 at 05:47:11PM -0500, Lyude Paul wrote:
> On Tue, 2023-01-31 at 17:05 +0200, Imre Deak wrote:
> > The DELL P2715Q monitor's MST hub has a payload allocation problem,
>
> LMAO hello yet again, Dell P2715Q. It's been a while.
>
> > where the VCPI used to reserve the last two
On 2/1/23 7:42 AM, Liu, Yi L wrote:
>> From: Matthew Rosato
...
>> +if (device->kvm) {
>> +vfio_kvm_put_kvm(device);
>> +device->put_kvm = NULL;
>
> Can "device->put_kvm = NULL;" be part of vfio_kvm_put_kvm()?
Sure
On 2/1/23 1:13 AM, Tian, Kevin wrote:
>> From: Matthew Rosato
>> Sent: Wednesday, February 1, 2023 4:07 AM
>>
>> -device->kvm = kvm;
>> +/*
>> + * Get the KVM pointer currently associated with the group, if there
>> + * is one, and obtain a reference now that will be held until
On Wed, Feb 01, 2023 at 11:41:47AM +0200, Jani Nikula wrote:
> On Tue, 31 Jan 2023, Imre Deak wrote:
> > Read out and verify an MST encoder's HW state after any of the
> > MST connectors driven by the encoder is modeset.
> >
> > Cc: Ville Syrjälä
> > Signed-off-by: Imre Deak
> > ---
> >
On Wed, 2023-02-01 at 15:53 +0200, Luca Coelho wrote:
> There are a few macros (e.g. DPLL()) that implicitly use dev_priv, by
> using other macros that implcitily use dev_priv.
>
> In an effort to align all definitions of struct drm_i915_private to be
> declared as i915 instead of arbitrarily
== Series Details ==
Series: drm/i915: make dev_priv usage explitic in some macros
URL : https://patchwork.freedesktop.org/series/113555/
State : failure
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/113555/revisions/1/mbox/ not
applied
Applying: drm/i915: make
There are a few macros (e.g. DPLL()) that implicitly use dev_priv, by
using other macros that implcitily use dev_priv.
In an effort to align all definitions of struct drm_i915_private to be
declared as i915 instead of arbitrarily using either i915 or dev_priv,
we need to make these macros
On Wed, Feb 01, 2023 at 01:00:59PM +0200, Lisovskiy, Stanislav wrote:
> On Tue, Jan 31, 2023 at 05:41:45PM +0200, Ville Syrjälä wrote:
> > On Tue, Jan 31, 2023 at 05:20:44PM +0200, Lisovskiy, Stanislav wrote:
> > > On Tue, Jan 31, 2023 at 05:00:30PM +0200, Ville Syrjälä wrote:
> > > > On Mon, Jan
> From: Jason Gunthorpe
> Sent: Wednesday, February 1, 2023 4:26 AM
>
> On Tue, Jan 31, 2023 at 03:06:35PM -0500, Matthew Rosato wrote:
> > @@ -799,13 +794,14 @@
> EXPORT_SYMBOL_GPL(vfio_file_enforced_coherent);
> > void vfio_file_set_kvm(struct file *file, struct kvm *kvm)
> > {
> >
> From: Matthew Rosato
> Sent: Wednesday, February 1, 2023 4:07 AM
>
> After 51cdc8bc120e, we have another deadlock scenario between the
> kvm->lock and the vfio group_lock with two different codepaths acquiring
> the locks in different order. Specifically in vfio_open_device, vfio
> holds the
On Wed, Feb 01, 2023 at 11:59:19AM +0200, Jani Nikula wrote:
> On Tue, 31 Jan 2023, Lucas De Marchi wrote:
> > Instead of using the common DISPLAY_MMIO_BASE(dev_priv) in all single
> > macros, only use them in the macros that are to be used outside the
> > header. This reduces the use of the
Hi Dave, Daniel,
Here goes the final pull request for 6.3.
Aside a few fixes, the reset is split between refactoring of the
workarounds code and correcting some workaround placement to correctly
align for new platforms, and converting the GuC code to use dedicated
logging macros, as was done for
On Tue, Jan 31, 2023 at 05:41:45PM +0200, Ville Syrjälä wrote:
> On Tue, Jan 31, 2023 at 05:20:44PM +0200, Lisovskiy, Stanislav wrote:
> > On Tue, Jan 31, 2023 at 05:00:30PM +0200, Ville Syrjälä wrote:
> > > On Mon, Jan 16, 2023 at 01:19:37PM +0200, Stanislav Lisovskiy wrote:
> > > > According to
== Series Details ==
Series: Enable HDCP2.x via GSC CS (rev10)
URL : https://patchwork.freedesktop.org/series/111876/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12676_full -> Patchwork_111876v10_full
Summary
---
On Tue, 31 Jan 2023, Lucas De Marchi wrote:
> Instead of using the common DISPLAY_MMIO_BASE(dev_priv) in all single
> macros, only use them in the macros that are to be used outside the
> header. This reduces the use of the implicit dev_priv, making it easier
> to remove it later.
>
>
== Series Details ==
Series: Enable HDCP2.x via GSC CS (rev10)
URL : https://patchwork.freedesktop.org/series/111876/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12676 -> Patchwork_111876v10
Summary
---
On Tue, 31 Jan 2023, Imre Deak wrote:
> Read out and verify an MST encoder's HW state after any of the
> MST connectors driven by the encoder is modeset.
>
> Cc: Ville Syrjälä
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 91 +--
>
It requires to move intel specific HDCP API structures to
i915_hdcp_interface.h from driver/misc/mei/hdcp/mei_hdcp.h
so that any content protection fw interfaces can use these
structures.
Cc: Tomas Winkler
Cc: Rodrigo Vivi
Cc: Uma Shankar
Cc: Ankit Nautiyal
Signed-off-by: Anshuman Gupta
MTL uses GSC command streamer i.e gsc cs to send HDCP/PXP commands
to GSC f/w. It requires to keep hdcp display driver
agnostic to content protection f/w (ME/GSC fw) in the form of
i915_hdcp_fw_ops generic ops.
Adding HDCP GSC CS interface by leveraging the i915_hdcp_fw_ops generic
ops instead of
Add function that takes care of sending command to gsc cs. We start
of with allocation of memory for our command intel_hdcp_gsc_message that
contains gsc cs memory header as directed in specs followed by the
actual payload hdcp message that we want to send.
Spec states that we need to poll pending
HDCP and PXP will require a common function to allow it to
submit commands to the gsc cs. Also adding the gsc mtl header
that needs to be added on to the existing payloads of HDCP
and PXP.
--v4
-Seprate gsc load and heci cmd submission into different
functions in different files for better
As now we have more then one type of content protection
secrity firmware. Let change the i915_hdcp_interface.h
header naming convention to suit generic f/w type.
%s/MEI_/HDCP_
%s/mei_dev/hdcp_dev
As interface to CP FW can be either a non i915 component or
i915 intergral component, change
From: Anshuman Gupta
Change the include/drm/i915_mei_hdcp_interface.h to
include/drm/i915_hdcp_interface.h
--v6
-make each patch build individually [Jani]
--v8
-change ME FW to ME/GSC FW [Ankit]
-fix formatting issue [Ankit]
Cc: Tomas Winkler
Cc: Rodrigo Vivi
Cc: Uma Shankar
Cc: Ankit
These patches enable HDCP2.x on machines MTL and above.
>From MTL onwards CSME is spilt into GSC and CSC and now
we use GSC CS instead of MEI to talk to firmware to start
HDCP authentication
--v2
-Fixing some checkpatch changes which I forgot before sending
out the series
--v3
-Drop cp and fw to
> From: Teres Alexis, Alan Previn
> Sent: Wednesday, February 1, 2023 2:18 PM
> To: Kandpal, Suraj ; intel-
> g...@lists.freedesktop.org
> Cc: Shankar, Uma ; Nautiyal, Ankit K
> ; Ceraolo Spurio, Daniele
> ; Gupta, Anshuman
>
> Subject: Re: [PATCH v9 5/6] drm/i915/mtl: Add function to send
Conditional Rb with below fix in intel_hdcp_gsc_free_message:
Reviewed-by: Alan Previn
On Tue, 2023-01-31 at 12:03 +0530, Kandpal, Suraj wrote:
> Add function that takes care of sending command to gsc cs. We start
> of with allocation of memory for our command intel_hdcp_gsc_message that
>
86 matches
Mail list logo
