Re: [Intel-gfx] [PATCH] drm/i915: Fix memory leaks in scatterlist
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 Chegondi
> ---
> drivers/gpu/drm/i915/i915_scatterlist.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_scatterlist.c
> b/drivers/gpu/drm/i915/i915_scatterlist.c
> index 756289e43dff6..7c7a86921b1c7 100644
> --- a/drivers/gpu/drm/i915/i915_scatterlist.c
> +++ b/drivers/gpu/drm/i915/i915_scatterlist.c
> @@ -98,8 +98,10 @@ struct i915_refct_sgt *i915_rsgt_from_mm_node(const struct
> drm_mm_node *node,
> st = >table;
> /* restricted by sg_alloc_table */
> if (WARN_ON(overflows_type(DIV_ROUND_UP_ULL(node->size, segment_pages),
> -unsigned int)))
> +unsigned int))) {
> + i915_refct_sgt_put(rsgt);
> return ERR_PTR(-E2BIG);
> + }
>
> if (sg_alloc_table(st, DIV_ROUND_UP_ULL(node->size, segment_pages),
> GFP_KERNEL)) {
> @@ -183,8 +185,10 @@ struct i915_refct_sgt
> *i915_rsgt_from_buddy_resource(struct ttm_resource *res,
> i915_refct_sgt_init(rsgt, size);
> st = >table;
> /* restricted by sg_alloc_table */
> - if (WARN_ON(overflows_type(PFN_UP(res->size), unsigned int)))
> + if (WARN_ON(overflows_type(PFN_UP(res->size), unsigned int))) {
> + i915_refct_sgt_put(rsgt);
> return ERR_PTR(-E2BIG);
> + }
>
> if (sg_alloc_table(st, PFN_UP(res->size), GFP_KERNEL)) {
> i915_refct_sgt_put(rsgt);
> --
> 2.39.1
>
Re: [Intel-gfx] [PATCH v3] drm/i915: Consolidate TLB invalidation flow
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 invariant platform and engine checks during each and every TLB
invalidation.
v2:
* Fail engine probe if TLB invlidations registers are unknown.
v3:
* Rebase.
Signed-off-by: Tvrtko Ursulin
Cc: Andrzej Hajda
Cc: Matt Roper
Reviewed-by: Andrzej Hajda # v1
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 96 +
drivers/gpu/drm/i915/gt/intel_engine_types.h | 15 ++
drivers/gpu/drm/i915/gt/intel_gt.c | 138 +++
3 files changed, 133 insertions(+), 116 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index d4e29da74612..e430945743ec 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -9,6 +9,7 @@
#include "gem/i915_gem_context.h"
#include "gem/i915_gem_internal.h"
+#include "gt/intel_gt_print.h"
#include "gt/intel_gt_regs.h"
#include "i915_cmd_parser.h"
@@ -1143,12 +1144,107 @@ static int init_status_page(struct intel_engine_cs
*engine)
return ret;
}
+static int intel_engine_init_tlb_invalidation(struct intel_engine_cs *engine)
+{
+ static const union intel_engine_tlb_inv_reg gen8_regs[] = {
+ [RENDER_CLASS].reg = GEN8_RTCR,
+ [VIDEO_DECODE_CLASS].reg= GEN8_M1TCR, /* , GEN8_M2TCR */
+ [VIDEO_ENHANCEMENT_CLASS].reg = GEN8_VTCR,
+ [COPY_ENGINE_CLASS].reg = GEN8_BTCR,
+ };
+ static const union intel_engine_tlb_inv_reg gen12_regs[] = {
+ [RENDER_CLASS].reg = GEN12_GFX_TLB_INV_CR,
+ [VIDEO_DECODE_CLASS].reg= GEN12_VD_TLB_INV_CR,
+ [VIDEO_ENHANCEMENT_CLASS].reg = GEN12_VE_TLB_INV_CR,
+ [COPY_ENGINE_CLASS].reg = GEN12_BLT_TLB_INV_CR,
+ [COMPUTE_CLASS].reg = GEN12_COMPCTX_TLB_INV_CR,
+ };
+ static const union intel_engine_tlb_inv_reg xehp_regs[] = {
+ [RENDER_CLASS].mcr_reg= XEHP_GFX_TLB_INV_CR,
+ [VIDEO_DECODE_CLASS].mcr_reg = XEHP_VD_TLB_INV_CR,
+ [VIDEO_ENHANCEMENT_CLASS].mcr_reg = XEHP_VE_TLB_INV_CR,
+ [COPY_ENGINE_CLASS].mcr_reg = XEHP_BLT_TLB_INV_CR,
+ [COMPUTE_CLASS].mcr_reg = XEHP_COMPCTX_TLB_INV_CR,
+ };
+ struct drm_i915_private *i915 = engine->i915;
+ const union intel_engine_tlb_inv_reg *regs;
+ union intel_engine_tlb_inv_reg reg;
+ unsigned int class = engine->class;
+ unsigned int num = 0;
+ u32 val;
+
+ /*
+* New platforms should not be added with catch-all-newer (>=)
+* condition so that any later platform added triggers the below warning
+* and in turn mandates a human cross-check of whether the invalidation
+* flows have compatible semantics.
+*
+* For instance with the 11.00 -> 12.00 transition three out of five
+* respective engine registers were moved to masked type. Then after the
+* 12.00 -> 12.50 transition multi cast handling is required too.
+*/
+
+ if (GRAPHICS_VER_FULL(i915) == IP_VER(12, 50) ||
+ GRAPHICS_VER_FULL(i915) == IP_VER(12, 55)) {
+ regs = xehp_regs;
+ num = ARRAY_SIZE(xehp_regs);
+ } else if (GRAPHICS_VER_FULL(i915) == IP_VER(12, 0) ||
+ GRAPHICS_VER_FULL(i915) == IP_VER(12, 10)) {
+ regs = gen12_regs;
+ num = ARRAY_SIZE(gen12_regs);
+ } else if (GRAPHICS_VER(i915) >= 8 && GRAPHICS_VER(i915) <= 11) {
+ regs = gen8_regs;
+ num = ARRAY_SIZE(gen8_regs);
+ } else if (GRAPHICS_VER(i915) < 8) {
+ return 0;
+ }
+
+ if (gt_WARN_ONCE(engine->gt, !num,
+"Platform does not implement TLB invalidation!"))
+ return -ENODEV;
+
+ if (gt_WARN_ON_ONCE(engine->gt,
+class >= num ||
+(!regs[class].reg.reg &&
+ !regs[class].mcr_reg.reg)))
+ return -ERANGE;
+
+ reg = regs[class];
+
+ if (GRAPHICS_VER(i915) == 8 && class == VIDEO_DECODE_CLASS) {
As selftest pointed out it should cover also gen 9-11.
Btw maybe it is worth to convert this pseudo array indexing to direct
assignment:
if ((GRAPHICS_VER(i915) <= 11 && class == VIDEO_DECODE_CLASS &&
engine->instance == 1) {
reg.reg = GEN8_M2TCR;
val = 0;
}
Regards
Andrzej
+ reg.reg.reg += 4 * engine->instance; /* GEN8_M2TCR */
+ val = 0;
+ } else {
+
Re: [Intel-gfx] [PATCHv3] drm/i915: Support Async Flip on Linear buffers
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 > Subject: RE: [Intel-gfx] [PATCHv3] drm/i915: Support Async Flip on Linear > buffers > > Any review comments on this. Gentle Reminder! > > Thanks and Regards, > Arun R Murthy > > > > -Original Message- > > From: Murthy, Arun R > > Sent: Tuesday, January 17, 2023 2:09 PM > > To: 'Ville Syrjälä' > > Cc: 'intel-gfx@lists.freedesktop.org' > > ; > > Syrjala, Ville > > Subject: RE: [Intel-gfx] [PATCHv3] drm/i915: Support Async Flip on > > Linear buffers > > > > Gentle Reminder! > > > > Thanks and Regards, > > Arun R Murthy > > --- > > > > > -Original Message- > > > From: Murthy, Arun R > > > Sent: Friday, January 13, 2023 12:57 PM > > > To: Ville Syrjälä > > > Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville > > > > > > Subject: RE: [Intel-gfx] [PATCHv3] drm/i915: Support Async Flip on > > > Linear buffers > > > > > > > On Fri, Oct 28, 2022 at 03:23:02AM +, Murthy, Arun R wrote: > > > > > Gentle Reminder! > > > > > > > > Is the igt stuff merged, and did this pass the test? > > > > > > > With IGT alone the tests will fail without the kernel patch. > > > The > > > tests(https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_112722v2/shard > > > s- > > > all.html?testfilter=kms_async_flips) are passing with IGT and kernel > patch. > > > > > > Thanks and Regards, > > > Arun R Murthy > > > > > > > > > > > > > > -Original Message- > > > > > > From: Murthy, Arun R > > > > > > Sent: Monday, October 10, 2022 1:24 PM > > > > > > To: 'intel-gfx@lists.freedesktop.org' > > > > > > > > > > > > Cc: Syrjala, Ville > > > > > > Subject: RE: [PATCHv3] drm/i915: Support Async Flip on Linear > > > > > > buffers > > > > > > > > > > > > Ville, > > > > > > Gentle reminder! > > > > > > > > > > > > Thanks and Regards, > > > > > > Arun R Murthy > > > > > > > > > > > > > > > > > > > -Original Message- > > > > > > > From: Murthy, Arun R > > > > > > > Sent: Monday, September 19, 2022 10:38 AM > > > > > > > To: 'intel-gfx@lists.freedesktop.org' > > > > > > > > > > > > > > Cc: Syrjala, Ville > > > > > > > Subject: RE: [PATCHv3] drm/i915: Support Async Flip on > > > > > > > Linear buffers > > > > > > > > > > > > > > If no comments, can anyone merge the patch! > > > > > > > > > > > > > > Thanks and Regards, > > > > > > > Arun R Murthy > > > > > > > > > > > > > > > > > > > > > > -Original Message- > > > > > > > > From: Murthy, Arun R > > > > > > > > Sent: Wednesday, September 14, 2022 4:21 PM > > > > > > > > To: Murthy, Arun R ; intel- > > > > > > > > g...@lists.freedesktop.org > > > > > > > > Cc: Syrjala, Ville > > > > > > > > Subject: RE: [PATCHv3] drm/i915: Support Async Flip on > > > > > > > > Linear buffers > > > > > > > > > > > > > > > > Gentle Reminder! > > > > > > > > Any comments? > > > > > > > > > > > > > > > > Thanks and Regards, > > > > > > > > Arun R Murthy > > > > > > > > > > > > > > > > > > > > > > > > > -Original Message- > > > > > > > > > From: Intel-gfx > > > > > > > > > > > > > > > > > > On Behalf Of Murthy, Arun R > > > > > > > > > Sent: Friday, September 9, 2022 9:17 AM > > > > > > > > > To: intel-gfx@lists.freedesktop.org > > > > > > > > > Cc: Syrjala, Ville > > > > > > > > > Subject: Re: [Intel-gfx] [PATCHv3] drm/i915: Support > > > > > > > > > Async Flip on Linear buffers > > > > > > > > > > > > > > > > > > Gentle Reminder! > > > > > > > > > > > > > > > > > > > -Original Message- > > > > > > > > > > From: Murthy, Arun R > > > > > > > > > > Sent: Tuesday, September 6, 2022 9:18 AM > > > > > > > > > > To: intel-gfx@lists.freedesktop.org > > > > > > > > > > Cc: ville.syrj...@linux.intel.com; Murthy, Arun R > > > > > > > > > > > > > > > > > > > > Subject: [PATCHv3] drm/i915: Support Async Flip on > > > > > > > > > > Linear buffers > > > > > > > > > > > > > > > > > > > > Starting from Gen12 Async Flip is supported on linear > > > > > > > > > > buffers. > > > > > > > > > > This patch enables support for async on linear buffer. > > > > > > > > > > > > > > > > > > > > UseCase: In Hybrid graphics, for hardware unsupported > > > > > > > > > > pixel formats it will be converted to linear memory > > > > > > > > > > and then > > > composed. > > > > > > > > > > > > > > > > > > > > v2: Added use case > > > > > > > > > > v3: Added FIXME for ICL indicating the restrictions > > > > > > > > > > > > > > > > > > > > Signed-off-by: Arun R Murthy > > > > > > > > > > --- > > > > > > > > > > drivers/gpu/drm/i915/display/intel_display.c | 14 > > > > > > > > > > ++ > > > > > > > > > > 1 file changed, 14 insertions(+) > > > > > > > > > > > > > > > > > > >
Re: [Intel-gfx] [PATCH v2] vfio: fix deadlock between group lock and kvm lock
> -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; imbre...@linux.ibm.com; da...@redhat.com;
> akrow...@linux.ibm.com; jjhe...@linux.ibm.com; pa...@linux.ibm.com;
> zhen...@linux.intel.com; Wang, Zhi A ;
> Christopherson,, Sean ; Tian, Kevin
> ; linux-s...@vger.kernel.org; k...@vger.kernel.org;
> intel-gvt-...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH v2] vfio: fix deadlock between group lock and kvm lock
>
> 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 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 vfio-ap) need to acquire kvm->lock during their
> open_device
> > > > routine; Meanwhile, kvm_vfio_release will acquire the kvm->lock first
> > > > before calling vfio_file_set_kvm which will acquire the vfio group_lock.
> > > >
> > > > To resolve this, let's remove the need for the vfio group_lock from the
> > > > kvm_vfio_release codepath. This is done by introducing a new
> spinlock to
> > > > protect modifications to the vfio group kvm pointer, and acquiring a
> kvm
> > > > ref from within vfio while holding this spinlock, with the reference
> > > > held
> > > > until the last close for the device in question.
> > > >
> > > > Fixes: 51cdc8bc120e ("kvm/vfio: Fix potential deadlock on vfio
> group_lock")
> > > > Reported-by: Anthony Krowiak
> > > > Suggested-by: Jason Gunthorpe
> > > > Signed-off-by: Matthew Rosato
> > > > ---
> > > > Changes from v1:
> > > > * use spin_lock instead of spin_lock_irqsave (Jason)
> > > > * clear device->kvm_put as part of vfio_kvm_put_kvm (Yi)
> > > > * Re-arrange code to avoid referencing the group contents from
> within
> > > > vfio_main (Kevin) which meant moving most of the code in this patch
> > > > to group.c along with getting/dropping of the dev_set lock
> > > > ---
> > > > drivers/vfio/group.c | 90
> > > +---
> > > > drivers/vfio/vfio.h | 1 +
> > > > drivers/vfio/vfio_main.c | 11 ++---
> > > > include/linux/vfio.h | 2 +-
> > > > 4 files changed, 91 insertions(+), 13 deletions(-)
> > > >
> > > > diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c
> > > > index bb24b2f0271e..52f434861294 100644
> > > > --- a/drivers/vfio/group.c
> > > > +++ b/drivers/vfio/group.c
> > > > @@ -13,6 +13,9 @@
> > > > #include
> > > > #include
> > > > #include
> > > > +#ifdef CONFIG_HAVE_KVM
> > > > +#include
> > > > +#endif
> > > > #include "vfio.h"
> > > >
> > > > static struct vfio {
> > > > @@ -154,6 +157,55 @@ static int
> vfio_group_ioctl_set_container(struct
> > > vfio_group *group,
> > > > return ret;
> > > > }
> > > >
> > > > +#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 can get the kvm pointer from the
> group
> > > internally.
> > >
> > > > +{
> > > > + void (*pfn)(struct kvm *kvm);
> > > > + bool (*fn)(struct kvm *kvm);
> > > > + bool ret;
> > > > +
> > >
> > > We should assert_lockdep_held(>dev_set->lock) in both of
> these
> > > since that seems to be what's protecting device->kvm and
> > > device->put_kvm.
> > >
> > > If we change as above to get the kvm pointer from the group within this
> > > function, we can also move the kvm_ref_lock here, which seems to
> > > simplify the caller quite a bit.
> > >
> > > > + pfn = symbol_get(kvm_put_kvm);
> > > > + if (WARN_ON(!pfn))
> > > > + return false;
> > > > +
> > > > + fn = symbol_get(kvm_get_kvm_safe);
> > > > + if (WARN_ON(!fn)) {
> > > > + symbol_put(kvm_put_kvm);
> > > > + return false;
> > > > + }
> > > > +
> > > > + ret = fn(kvm);
> > > > + if (ret)
> > > > + device->put_kvm = pfn;
> > > > + else
> > > > + symbol_put(kvm_put_kvm);
> > > > +
> > > > + symbol_put(kvm_get_kvm_safe);
> > > > +
> > > > + return ret;
> > > > +}
> > > > +
> > > > +static void vfio_kvm_put_kvm(struct vfio_device *device)
> > > > +{
> > > > + if (WARN_ON(!device->kvm || !device->put_kvm))
> > > > + return;
> > >
> > > It simplifies the
Re: [Intel-gfx] [PATCH v2] vfio: fix deadlock between group lock and kvm lock
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 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 vfio-ap) need to acquire kvm->lock during their open_device
> > > routine; Meanwhile, kvm_vfio_release will acquire the kvm->lock first
> > > before calling vfio_file_set_kvm which will acquire the vfio group_lock.
> > >
> > > To resolve this, let's remove the need for the vfio group_lock from the
> > > kvm_vfio_release codepath. This is done by introducing a new spinlock to
> > > protect modifications to the vfio group kvm pointer, and acquiring a kvm
> > > ref from within vfio while holding this spinlock, with the reference held
> > > until the last close for the device in question.
> > >
> > > Fixes: 51cdc8bc120e ("kvm/vfio: Fix potential deadlock on vfio
> > > group_lock")
> > > Reported-by: Anthony Krowiak
> > > Suggested-by: Jason Gunthorpe
> > > Signed-off-by: Matthew Rosato
> > > ---
> > > Changes from v1:
> > > * use spin_lock instead of spin_lock_irqsave (Jason)
> > > * clear device->kvm_put as part of vfio_kvm_put_kvm (Yi)
> > > * Re-arrange code to avoid referencing the group contents from within
> > > vfio_main (Kevin) which meant moving most of the code in this patch
> > > to group.c along with getting/dropping of the dev_set lock
> > > ---
> > > drivers/vfio/group.c | 90
> > +---
> > > drivers/vfio/vfio.h | 1 +
> > > drivers/vfio/vfio_main.c | 11 ++---
> > > include/linux/vfio.h | 2 +-
> > > 4 files changed, 91 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c
> > > index bb24b2f0271e..52f434861294 100644
> > > --- a/drivers/vfio/group.c
> > > +++ b/drivers/vfio/group.c
> > > @@ -13,6 +13,9 @@
> > > #include
> > > #include
> > > #include
> > > +#ifdef CONFIG_HAVE_KVM
> > > +#include
> > > +#endif
> > > #include "vfio.h"
> > >
> > > static struct vfio {
> > > @@ -154,6 +157,55 @@ static int vfio_group_ioctl_set_container(struct
> > vfio_group *group,
> > > return ret;
> > > }
> > >
> > > +#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 can get the kvm pointer from the group
> > internally.
> >
> > > +{
> > > + void (*pfn)(struct kvm *kvm);
> > > + bool (*fn)(struct kvm *kvm);
> > > + bool ret;
> > > +
> >
> > We should assert_lockdep_held(>dev_set->lock) in both of these
> > since that seems to be what's protecting device->kvm and
> > device->put_kvm.
> >
> > If we change as above to get the kvm pointer from the group within this
> > function, we can also move the kvm_ref_lock here, which seems to
> > simplify the caller quite a bit.
> >
> > > + pfn = symbol_get(kvm_put_kvm);
> > > + if (WARN_ON(!pfn))
> > > + return false;
> > > +
> > > + fn = symbol_get(kvm_get_kvm_safe);
> > > + if (WARN_ON(!fn)) {
> > > + symbol_put(kvm_put_kvm);
> > > + return false;
> > > + }
> > > +
> > > + ret = fn(kvm);
> > > + if (ret)
> > > + device->put_kvm = pfn;
> > > + else
> > > + symbol_put(kvm_put_kvm);
> > > +
> > > + symbol_put(kvm_get_kvm_safe);
> > > +
> > > + return ret;
> > > +}
> > > +
> > > +static void vfio_kvm_put_kvm(struct vfio_device *device)
> > > +{
> > > + if (WARN_ON(!device->kvm || !device->put_kvm))
> > > + return;
> >
> > It simplifies the caller if we can use this even in the !device->kvm
> > case.
> >
> > > +
> > > + device->put_kvm(device->kvm);
> > > + device->put_kvm = NULL;
> > > + symbol_put(kvm_put_kvm);
> > > +}
> > > +
> > > +#else
> > > +static bool vfio_kvm_get_kvm_safe(struct vfio_device *device, struct
> > kvm *kvm)
> > > +{
> > > + return false;
> > > +}
> > > +
> > > +static void vfio_kvm_put_kvm(struct vfio_device *device)
> > > +{
> > > +}
> > > +#endif
> > > +
> > > static int vfio_device_group_open(struct vfio_device *device)
> > > {
> > > int ret;
> > > @@ -164,14 +216,32 @@ static int vfio_device_group_open(struct
> > vfio_device *device)
> > > goto out_unlock;
> > > }
> > >
> > > + mutex_lock(>dev_set->lock);
> > > +
> > > /*
> > > - * Here we pass the KVM pointer with the group under the lock. If
> > the
> > > - * device driver will use it, it must obtain a reference and release it
> > > - * during close_device.
> > > + * Before the first device open, get the KVM pointer currently
> > > + * associated with the group (if
Re: [Intel-gfx] [PATCH v2] vfio: fix deadlock between group lock and kvm lock
> 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 can get the kvm pointer from the group > internally. > I have a different thought. In the end the cdev series also need the similar safe get/put logic then it's better to keep it in vfio_main.c called by the group/cdev path individually.
Re: [Intel-gfx] [PATCH v2] vfio: fix deadlock between group lock and kvm lock
> 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 code set device->kvm in the vfio_device_first_open() which is > called by vfio_device_open(). After above change, seems not necessary > to pass kvm pointer into the call chain. Isn't it? > Looks so.
Re: [Intel-gfx] [PATCH v2] vfio: fix deadlock between group lock and kvm lock
> 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 in different order. Specifically in vfio_open_device, vfio
> > holds the vfio group_lock when issuing device->ops->open_device but
> some
> > drivers (like vfio-ap) need to acquire kvm->lock during their open_device
> > routine; Meanwhile, kvm_vfio_release will acquire the kvm->lock first
> > before calling vfio_file_set_kvm which will acquire the vfio group_lock.
> >
> > To resolve this, let's remove the need for the vfio group_lock from the
> > kvm_vfio_release codepath. This is done by introducing a new spinlock to
> > protect modifications to the vfio group kvm pointer, and acquiring a kvm
> > ref from within vfio while holding this spinlock, with the reference held
> > until the last close for the device in question.
> >
> > Fixes: 51cdc8bc120e ("kvm/vfio: Fix potential deadlock on vfio group_lock")
> > Reported-by: Anthony Krowiak
> > Suggested-by: Jason Gunthorpe
> > Signed-off-by: Matthew Rosato
> > ---
> > Changes from v1:
> > * use spin_lock instead of spin_lock_irqsave (Jason)
> > * clear device->kvm_put as part of vfio_kvm_put_kvm (Yi)
> > * Re-arrange code to avoid referencing the group contents from within
> > vfio_main (Kevin) which meant moving most of the code in this patch
> > to group.c along with getting/dropping of the dev_set lock
> > ---
> > drivers/vfio/group.c | 90
> +---
> > drivers/vfio/vfio.h | 1 +
> > drivers/vfio/vfio_main.c | 11 ++---
> > include/linux/vfio.h | 2 +-
> > 4 files changed, 91 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c
> > index bb24b2f0271e..52f434861294 100644
> > --- a/drivers/vfio/group.c
> > +++ b/drivers/vfio/group.c
> > @@ -13,6 +13,9 @@
> > #include
> > #include
> > #include
> > +#ifdef CONFIG_HAVE_KVM
> > +#include
> > +#endif
> > #include "vfio.h"
> >
> > static struct vfio {
> > @@ -154,6 +157,55 @@ static int vfio_group_ioctl_set_container(struct
> vfio_group *group,
> > return ret;
> > }
> >
> > +#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 can get the kvm pointer from the group
> internally.
>
> > +{
> > + void (*pfn)(struct kvm *kvm);
> > + bool (*fn)(struct kvm *kvm);
> > + bool ret;
> > +
>
> We should assert_lockdep_held(>dev_set->lock) in both of these
> since that seems to be what's protecting device->kvm and
> device->put_kvm.
>
> If we change as above to get the kvm pointer from the group within this
> function, we can also move the kvm_ref_lock here, which seems to
> simplify the caller quite a bit.
>
> > + pfn = symbol_get(kvm_put_kvm);
> > + if (WARN_ON(!pfn))
> > + return false;
> > +
> > + fn = symbol_get(kvm_get_kvm_safe);
> > + if (WARN_ON(!fn)) {
> > + symbol_put(kvm_put_kvm);
> > + return false;
> > + }
> > +
> > + ret = fn(kvm);
> > + if (ret)
> > + device->put_kvm = pfn;
> > + else
> > + symbol_put(kvm_put_kvm);
> > +
> > + symbol_put(kvm_get_kvm_safe);
> > +
> > + return ret;
> > +}
> > +
> > +static void vfio_kvm_put_kvm(struct vfio_device *device)
> > +{
> > + if (WARN_ON(!device->kvm || !device->put_kvm))
> > + return;
>
> It simplifies the caller if we can use this even in the !device->kvm
> case.
>
> > +
> > + device->put_kvm(device->kvm);
> > + device->put_kvm = NULL;
> > + symbol_put(kvm_put_kvm);
> > +}
> > +
> > +#else
> > +static bool vfio_kvm_get_kvm_safe(struct vfio_device *device, struct
> kvm *kvm)
> > +{
> > + return false;
> > +}
> > +
> > +static void vfio_kvm_put_kvm(struct vfio_device *device)
> > +{
> > +}
> > +#endif
> > +
> > static int vfio_device_group_open(struct vfio_device *device)
> > {
> > int ret;
> > @@ -164,14 +216,32 @@ static int vfio_device_group_open(struct
> vfio_device *device)
> > goto out_unlock;
> > }
> >
> > + mutex_lock(>dev_set->lock);
> > +
> > /*
> > -* Here we pass the KVM pointer with the group under the lock. If
> the
> > -* device driver will use it, it must obtain a reference and release it
> > -* during close_device.
> > +* Before the first device open, get the KVM pointer currently
> > +* associated with the group (if there is one) and obtain a reference
> > +* now that will be held until the open_count reaches 0 again. Save
> > +* the pointer in the device for use by drivers.
> > */
> > + if (device->open_count == 0) {
> > + spin_lock(>group->kvm_ref_lock);
> > + if (device->group->kvm &&
> > +
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/hwmon: Enable PL1 power limit
== 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
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113578v1/index.html
Participating hosts (25 -> 25)
--
Additional (1): fi-apl-guc
Missing(1): fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113578v1:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@hangcheck:
- {bat-rpls-1}: [PASS][1] -> [ABORT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/bat-rpls-1/igt@i915_selftest@l...@hangcheck.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113578v1/bat-rpls-1/igt@i915_selftest@l...@hangcheck.html
Known issues
Here are the changes found in Patchwork_113578v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@fbdev@write:
- fi-blb-e6850: [PASS][3] -> [SKIP][4] ([fdo#109271]) +4 similar
issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/fi-blb-e6850/igt@fb...@write.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113578v1/fi-blb-e6850/igt@fb...@write.html
* igt@gem_lmem_swapping@basic:
- fi-apl-guc: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613]) +3
similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113578v1/fi-apl-guc/igt@gem_lmem_swapp...@basic.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-apl-guc: NOTRUN -> [DMESG-FAIL][6] ([i915#5334])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113578v1/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
* igt@kms_chamelium_hpd@vga-hpd-fast:
- fi-apl-guc: NOTRUN -> [SKIP][7] ([fdo#109271]) +21 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113578v1/fi-apl-guc/igt@kms_chamelium_...@vga-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
[i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
[i915#7852]: https://gitlab.freedesktop.org/drm/intel/issues/7852
[i915#7977]: https://gitlab.freedesktop.org/drm/intel/issues/7977
Build changes
-
* Linux: CI_DRM_12681 -> Patchwork_113578v1
CI-20190529: 20190529
CI_DRM_12681: 8ee2ec597aa4b8331124bf852432c2ca2fd7b8d1 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7143: c7b12dcc460fc2348e1fa7f4dcb791bb82e29e44 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_113578v1: 8ee2ec597aa4b8331124bf852432c2ca2fd7b8d1 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
0153ee93659c drm/i915/hwmon: Enable PL1 power limit
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113578v1/index.html
Re: [Intel-gfx] [PATCH] vfio: fix deadlock between group lock and kvm lock
> 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 @@
> >> EXPORT_SYMBOL_GPL(vfio_file_enforced_coherent);
> >>> void vfio_file_set_kvm(struct file *file, struct kvm *kvm)
> >>> {
> >>> struct vfio_group *group = file->private_data;
> >>> + unsigned long flags;
> >>>
> >>> if (!vfio_file_is_group(file))
> >>> return;
> >>>
> >>> - mutex_lock(>group_lock);
> >>> + spin_lock_irqsave(>kvm_ref_lock, flags);
> >>> group->kvm = kvm;
> >>> - mutex_unlock(>group_lock);
> >>> + spin_unlock_irqrestore(>kvm_ref_lock, flags);
> >>
> >> We know we are in a sleeping context here so these are just
> >> 'spin_lock()', same with the other one
> >
> > a dumb question. Why spinlock is required here?
> >
>
> You mean as opposed to another mutex? I don't think it's required per se
> (we are replacing a mutex so we could have again used another mutex
> here), but all current users of this new lock hold it over a very short window
> (e.g. set a pointer as above, or refcount++ and copy the pointer as in the
> first device_open)
I see. Just not sure if spinlock is required for a special reason.
Regards,
Yi Liu
[Intel-gfx] [PATCH] drm/i915/hwmon: Enable PL1 power limit
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 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_hwmon.c b/drivers/gpu/drm/i915/i915_hwmon.c index 1225bc432f0d5..4683a5b96eff1 100644 --- a/drivers/gpu/drm/i915/i915_hwmon.c +++ b/drivers/gpu/drm/i915/i915_hwmon.c @@ -687,6 +687,11 @@ hwm_get_preregistration_info(struct drm_i915_private *i915) for_each_gt(gt, i915, i) hwm_energy(>ddat_gt[i], ); } + + /* Enable PL1 power limit */ + if (i915_mmio_reg_valid(hwmon->rg.pkg_rapl_limit)) + hwm_locked_with_pm_intel_uncore_rmw(ddat, hwmon->rg.pkg_rapl_limit, + PKG_PWR_LIM_1_EN, PKG_PWR_LIM_1_EN); } void i915_hwmon_register(struct drm_i915_private *i915) -- 2.38.0
Re: [Intel-gfx] [PATCH v10 00/23] drm/i915/vm_bind: Add VM_BIND functionality
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 physical pages of an object (aliasing). These mappings (also > referred to as persistent mappings) will be persistent across multiple > GPU submissions (execbuf calls) issued by the UMD, without user having > to provide a list of all required mappings during each submission (as > required by older execbuf mode). > > This patch series support VM_BIND version 1, as described by the param > I915_PARAM_VM_BIND_VERSION. > > Add new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only works in > vm_bind mode. The vm_bind mode only works with this new execbuf3 ioctl. > The new execbuf3 ioctl will not have any execlist support and all the > legacy support like relocations etc., are removed. > > NOTEs: > * It is based on below VM_BIND design+uapi rfc. > Documentation/gpu/rfc/i915_vm_bind.rst > > * The IGT RFC series is posted as, > [PATCH i-g-t v10 0/19] vm_bind: Add VM_BIND validation support FYI, I created a Draft MR for the Mesa implementation: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21057 A Draft MR should be easier to track than simply a branch on a personal tree. Feel free to put this link in the next cover letters for v11 and above. > > v2: Address various review comments > v3: Address review comments and other fixes > v4: Remove vm_unbind out fence uapi which is not supported yet, > replace vm->vm_bind_mode check with i915_gem_vm_is_vm_bind_mode() > v5: Render kernel-doc, use PIN_NOEVICT, limit vm_bind support to > non-recoverable faults > v6: Rebased, minor fixes, add reserved fields to drm_i915_gem_vm_bind, > add new patch for async vm_unbind support > v7: Rebased, minor cleanups as per review feedback > v8: Rebased, add capture support > v9: Address capture support feedback from v8 > v10: Properly handle vma->resource for mappings with capture request > > Test-with: 20230118071350.17498-1-niranjana.vishwanathap...@intel.com > > Signed-off-by: Niranjana Vishwanathapura > > Niranjana Vishwanathapura (23): > drm/i915/vm_bind: Expose vm lookup function > drm/i915/vm_bind: Add __i915_sw_fence_await_reservation() > drm/i915/vm_bind: Expose i915_gem_object_max_page_size() > drm/i915/vm_bind: Support partially mapped vma resource > drm/i915/vm_bind: Add support to create persistent vma > drm/i915/vm_bind: Implement bind and unbind of object > drm/i915/vm_bind: Support for VM private BOs > drm/i915/vm_bind: Add support to handle object evictions > drm/i915/vm_bind: Support persistent vma activeness tracking > drm/i915/vm_bind: Add out fence support > drm/i915/vm_bind: Abstract out common execbuf functions > drm/i915/vm_bind: Use common execbuf functions in execbuf path > drm/i915/vm_bind: Implement I915_GEM_EXECBUFFER3 ioctl > drm/i915/vm_bind: Update i915_vma_verify_bind_complete() > drm/i915/vm_bind: Expose i915_request_await_bind() > drm/i915/vm_bind: Handle persistent vmas in execbuf3 > drm/i915/vm_bind: userptr dma-resv changes > drm/i915/vm_bind: Limit vm_bind mode to non-recoverable contexts > drm/i915/vm_bind: Add uapi for user to enable vm_bind_mode > drm/i915/vm_bind: Render VM_BIND documentation > drm/i915/vm_bind: Async vm_unbind support > drm/i915/vm_bind: Properly build persistent map sg table > drm/i915/vm_bind: Support capture of persistent mappings > > Documentation/gpu/i915.rst| 78 +- > drivers/gpu/drm/i915/Makefile | 3 + > drivers/gpu/drm/i915/gem/i915_gem_context.c | 43 +- > drivers/gpu/drm/i915/gem/i915_gem_context.h | 17 + > drivers/gpu/drm/i915/gem/i915_gem_create.c| 72 +- > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 6 + > .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 522 +-- > .../gpu/drm/i915/gem/i915_gem_execbuffer3.c | 872 ++ > .../drm/i915/gem/i915_gem_execbuffer_common.c | 671 ++ > .../drm/i915/gem/i915_gem_execbuffer_common.h | 76 ++ > drivers/gpu/drm/i915/gem/i915_gem_ioctls.h| 2 + > drivers/gpu/drm/i915/gem/i915_gem_object.c| 3 + > drivers/gpu/drm/i915/gem/i915_gem_object.h| 2 + > .../gpu/drm/i915/gem/i915_gem_object_types.h | 6 + > drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 19 + > drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h | 30 + > .../drm/i915/gem/i915_gem_vm_bind_object.c| 463 ++ > drivers/gpu/drm/i915/gt/intel_gtt.c | 22 + > drivers/gpu/drm/i915/gt/intel_gtt.h | 28 + > drivers/gpu/drm/i915/i915_driver.c| 4 + > drivers/gpu/drm/i915/i915_drv.h | 2 + > drivers/gpu/drm/i915/i915_gem.c | 14 +- > drivers/gpu/drm/i915/i915_gem_gtt.c | 39 + >
[Intel-gfx] ✓ Fi.CI.IGT: success for vfio: fix deadlock between group lock and kvm lock (rev3)
== 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
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v3/index.html
Participating hosts (10 -> 10)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113535v3_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-mmap-wc:
- {shard-dg1}:NOTRUN -> [DMESG-WARN][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v3/shard-dg1-13/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-mmap-wc.html
Known issues
Here are the changes found in Patchwork_113535v3_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][2] -> [FAIL][3] ([i915#2842])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-glk7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v3/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@kms_cursor_legacy@single-bo@pipe-b:
- shard-glk: [PASS][4] -> [DMESG-WARN][5] ([i915#118])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-glk3/igt@kms_cursor_legacy@single...@pipe-b.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v3/shard-glk8/igt@kms_cursor_legacy@single...@pipe-b.html
Possible fixes
* igt@drm_fdinfo@virtual-idle:
- {shard-rkl}:[FAIL][6] ([i915#7742]) -> [PASS][7] +1 similar issue
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-2/igt@drm_fdi...@virtual-idle.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v3/shard-rkl-3/igt@drm_fdi...@virtual-idle.html
* igt@drm_read@short-buffer-block:
- {shard-tglu}: [SKIP][8] ([i915#7651]) -> [PASS][9] +6 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-tglu-6/igt@drm_r...@short-buffer-block.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v3/shard-tglu-3/igt@drm_r...@short-buffer-block.html
* igt@fbdev@write:
- {shard-tglu}: [SKIP][10] ([i915#2582]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-tglu-6/igt@fb...@write.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v3/shard-tglu-3/igt@fb...@write.html
* igt@feature_discovery@psr2:
- {shard-rkl}:[SKIP][12] ([i915#658]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-1/igt@feature_discov...@psr2.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v3/shard-rkl-6/igt@feature_discov...@psr2.html
* igt@gem_exec_endless@dispatch@bcs0:
- {shard-rkl}:[SKIP][14] ([i915#6247]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-5/igt@gem_exec_endless@dispa...@bcs0.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v3/shard-rkl-6/igt@gem_exec_endless@dispa...@bcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- {shard-rkl}:[FAIL][16] ([i915#2842]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-5/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v3/shard-rkl-5/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_exec_reloc@basic-write-gtt:
- {shard-rkl}:[SKIP][18] ([i915#3281]) -> [PASS][19] +3 similar
issues
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-6/igt@gem_exec_re...@basic-write-gtt.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v3/shard-rkl-5/igt@gem_exec_re...@basic-write-gtt.html
* igt@gem_pread@uncached:
- {shard-rkl}:[SKIP][20] ([i915#3282]) -> [PASS][21] +2 similar
issues
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-2/igt@gem_pr...@uncached.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v3/shard-rkl-5/igt@gem_pr...@uncached.html
* igt@gen9_exec_parse@bb-chained:
- {shard-rkl}:[SKIP][22] ([i915#2527]) -> [PASS][23]
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-2/igt@gen9_exec_pa...@bb-chained.html
[23]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix memory leaks in scatterlist
== 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
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113576v1/index.html
Participating hosts (25 -> 25)
--
Additional (1): fi-apl-guc
Missing(1): fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113576v1:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@slpc:
- {bat-rpls-1}: [DMESG-FAIL][1] ([i915#7996]) -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/bat-rpls-1/igt@i915_selftest@l...@slpc.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113576v1/bat-rpls-1/igt@i915_selftest@l...@slpc.html
* igt@i915_suspend@basic-s3-without-i915:
- {bat-adln-1}: [PASS][3] -> [DMESG-WARN][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/bat-adln-1/igt@i915_susp...@basic-s3-without-i915.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113576v1/bat-adln-1/igt@i915_susp...@basic-s3-without-i915.html
Known issues
Here are the changes found in Patchwork_113576v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@fbdev@write:
- fi-blb-e6850: [PASS][5] -> [SKIP][6] ([fdo#109271]) +4 similar
issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/fi-blb-e6850/igt@fb...@write.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113576v1/fi-blb-e6850/igt@fb...@write.html
* igt@gem_lmem_swapping@basic:
- fi-apl-guc: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) +3
similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113576v1/fi-apl-guc/igt@gem_lmem_swapp...@basic.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-apl-guc: NOTRUN -> [DMESG-FAIL][8] ([i915#5334])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113576v1/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
* igt@kms_chamelium_hpd@vga-hpd-fast:
- fi-apl-guc: NOTRUN -> [SKIP][9] ([fdo#109271]) +21 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113576v1/fi-apl-guc/igt@kms_chamelium_...@vga-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
[i915#6311]: https://gitlab.freedesktop.org/drm/intel/issues/6311
[i915#7359]: https://gitlab.freedesktop.org/drm/intel/issues/7359
[i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
[i915#7996]: https://gitlab.freedesktop.org/drm/intel/issues/7996
Build changes
-
* Linux: CI_DRM_12681 -> Patchwork_113576v1
CI-20190529: 20190529
CI_DRM_12681: 8ee2ec597aa4b8331124bf852432c2ca2fd7b8d1 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7143: c7b12dcc460fc2348e1fa7f4dcb791bb82e29e44 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_113576v1: 8ee2ec597aa4b8331124bf852432c2ca2fd7b8d1 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
2f7b05e8380d drm/i915: Fix memory leaks in scatterlist
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113576v1/index.html
[Intel-gfx] ✓ Fi.CI.BAT: success for vfio: fix deadlock between group lock and kvm lock (rev3)
== 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
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v3/index.html
Participating hosts (25 -> 25)
--
Additional (1): fi-apl-guc
Missing(1): fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113535v3:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-adlp-6}: [PASS][1] -> [DMESG-WARN][2] +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/bat-adlp-6/igt@gem_exec_suspend@basic...@smem.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v3/bat-adlp-6/igt@gem_exec_suspend@basic...@smem.html
Known issues
Here are the changes found in Patchwork_113535v3 that come from known issues:
### IGT changes ###
Issues hit
* igt@fbdev@write:
- fi-blb-e6850: [PASS][3] -> [SKIP][4] ([fdo#109271]) +4 similar
issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/fi-blb-e6850/igt@fb...@write.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v3/fi-blb-e6850/igt@fb...@write.html
* igt@gem_lmem_swapping@basic:
- fi-apl-guc: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613]) +3
similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v3/fi-apl-guc/igt@gem_lmem_swapp...@basic.html
* igt@kms_chamelium_hpd@vga-hpd-fast:
- fi-apl-guc: NOTRUN -> [SKIP][6] ([fdo#109271]) +21 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v3/fi-apl-guc/igt@kms_chamelium_...@vga-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#6311]: https://gitlab.freedesktop.org/drm/intel/issues/6311
[i915#7359]: https://gitlab.freedesktop.org/drm/intel/issues/7359
Build changes
-
* Linux: CI_DRM_12681 -> Patchwork_113535v3
CI-20190529: 20190529
CI_DRM_12681: 8ee2ec597aa4b8331124bf852432c2ca2fd7b8d1 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7143: c7b12dcc460fc2348e1fa7f4dcb791bb82e29e44 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_113535v3: 8ee2ec597aa4b8331124bf852432c2ca2fd7b8d1 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
603f233f2121 vfio: fix deadlock between group lock and kvm lock
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v3/index.html
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/4] drm/i915/pvc: Annotate two more workaround/tuning registers as MCR
== 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
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113573v1/index.html
Participating hosts (10 -> 11)
--
Additional (1): shard-rkl0
Known issues
Here are the changes found in Patchwork_113573v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_eio@in-flight-contexts-immediate:
- shard-glk: [PASS][1] -> [TIMEOUT][2] ([i915#3063])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-glk9/igt@gem_...@in-flight-contexts-immediate.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113573v1/shard-glk9/igt@gem_...@in-flight-contexts-immediate.html
* igt@gen9_exec_parse@allowed-single:
- shard-glk: [PASS][3] -> [ABORT][4] ([i915#5566])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-glk9/igt@gen9_exec_pa...@allowed-single.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113573v1/shard-glk8/igt@gen9_exec_pa...@allowed-single.html
Possible fixes
* igt@drm_fdinfo@virtual-idle:
- {shard-rkl}:[FAIL][5] ([i915#7742]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-2/igt@drm_fdi...@virtual-idle.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113573v1/shard-rkl-3/igt@drm_fdi...@virtual-idle.html
* igt@drm_read@short-buffer-block:
- {shard-tglu}: [SKIP][7] ([i915#7651]) -> [PASS][8] +6 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-tglu-6/igt@drm_r...@short-buffer-block.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113573v1/shard-tglu-4/igt@drm_r...@short-buffer-block.html
* igt@fbdev@unaligned-read:
- {shard-rkl}:[SKIP][9] ([i915#2582]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-5/igt@fb...@unaligned-read.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113573v1/shard-rkl-6/igt@fb...@unaligned-read.html
* igt@fbdev@write:
- {shard-tglu}: [SKIP][11] ([i915#2582]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-tglu-6/igt@fb...@write.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113573v1/shard-tglu-4/igt@fb...@write.html
* igt@gem_ctx_persistence@engines-hang@bcs0:
- {shard-rkl}:[SKIP][13] ([i915#6252]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-5/igt@gem_ctx_persistence@engines-h...@bcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113573v1/shard-rkl-6/igt@gem_ctx_persistence@engines-h...@bcs0.html
* igt@gem_exec_endless@dispatch@bcs0:
- {shard-rkl}:[SKIP][15] ([i915#6247]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-5/igt@gem_exec_endless@dispa...@bcs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113573v1/shard-rkl-6/igt@gem_exec_endless@dispa...@bcs0.html
* igt@gem_exec_fair@basic-deadline:
- {shard-rkl}:[FAIL][17] ([i915#2846]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-1/igt@gem_exec_f...@basic-deadline.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113573v1/shard-rkl-5/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_reloc@basic-wc-gtt-noreloc:
- {shard-rkl}:[SKIP][19] ([i915#3281]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-1/igt@gem_exec_re...@basic-wc-gtt-noreloc.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113573v1/shard-rkl-5/igt@gem_exec_re...@basic-wc-gtt-noreloc.html
* igt@i915_pm_dc@dc9-dpms:
- {shard-rkl}:[SKIP][21] ([i915#3361]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-5/igt@i915_pm...@dc9-dpms.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113573v1/shard-rkl-4/igt@i915_pm...@dc9-dpms.html
* igt@i915_pm_rpm@modeset-lpsp:
- {shard-dg1}:[SKIP][23] ([i915#1397]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-dg1-17/igt@i915_pm_...@modeset-lpsp.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113573v1/shard-dg1-14/igt@i915_pm_...@modeset-lpsp.html
* igt@i915_pm_rpm@modeset-lpsp-stress:
- {shard-tglu}: [SKIP][25] ([i915#1397]) -> [PASS][26]
[25]:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for vfio: fix deadlock between group lock and kvm lock (rev3)
== 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: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#23:
> Fixes: 51cdc8bc120e ("kvm/vfio: Fix potential deadlock on vfio group_lock")
-:320: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment
#320: FILE: drivers/vfio/vfio.h:77:
+ spinlock_t kvm_ref_lock;
-:403: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s)
total: 1 errors, 1 warnings, 1 checks, 205 lines checked
[Intel-gfx] [PATCH] drm/i915: Fix memory leaks in scatterlist
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 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_scatterlist.c
b/drivers/gpu/drm/i915/i915_scatterlist.c
index 756289e43dff6..7c7a86921b1c7 100644
--- a/drivers/gpu/drm/i915/i915_scatterlist.c
+++ b/drivers/gpu/drm/i915/i915_scatterlist.c
@@ -98,8 +98,10 @@ struct i915_refct_sgt *i915_rsgt_from_mm_node(const struct
drm_mm_node *node,
st = >table;
/* restricted by sg_alloc_table */
if (WARN_ON(overflows_type(DIV_ROUND_UP_ULL(node->size, segment_pages),
- unsigned int)))
+ unsigned int))) {
+ i915_refct_sgt_put(rsgt);
return ERR_PTR(-E2BIG);
+ }
if (sg_alloc_table(st, DIV_ROUND_UP_ULL(node->size, segment_pages),
GFP_KERNEL)) {
@@ -183,8 +185,10 @@ struct i915_refct_sgt
*i915_rsgt_from_buddy_resource(struct ttm_resource *res,
i915_refct_sgt_init(rsgt, size);
st = >table;
/* restricted by sg_alloc_table */
- if (WARN_ON(overflows_type(PFN_UP(res->size), unsigned int)))
+ if (WARN_ON(overflows_type(PFN_UP(res->size), unsigned int))) {
+ i915_refct_sgt_put(rsgt);
return ERR_PTR(-E2BIG);
+ }
if (sg_alloc_table(st, PFN_UP(res->size), GFP_KERNEL)) {
i915_refct_sgt_put(rsgt);
--
2.39.1
Re: [Intel-gfx] [PATCH v2] vfio: fix deadlock between group lock and kvm lock
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 group_lock when issuing device->ops->open_device but some
> drivers (like vfio-ap) need to acquire kvm->lock during their open_device
> routine; Meanwhile, kvm_vfio_release will acquire the kvm->lock first
> before calling vfio_file_set_kvm which will acquire the vfio group_lock.
>
> To resolve this, let's remove the need for the vfio group_lock from the
> kvm_vfio_release codepath. This is done by introducing a new spinlock to
> protect modifications to the vfio group kvm pointer, and acquiring a kvm
> ref from within vfio while holding this spinlock, with the reference held
> until the last close for the device in question.
>
> Fixes: 51cdc8bc120e ("kvm/vfio: Fix potential deadlock on vfio group_lock")
> Reported-by: Anthony Krowiak
> Suggested-by: Jason Gunthorpe
> Signed-off-by: Matthew Rosato
> ---
> Changes from v1:
> * use spin_lock instead of spin_lock_irqsave (Jason)
> * clear device->kvm_put as part of vfio_kvm_put_kvm (Yi)
> * Re-arrange code to avoid referencing the group contents from within
> vfio_main (Kevin) which meant moving most of the code in this patch
> to group.c along with getting/dropping of the dev_set lock
> ---
> drivers/vfio/group.c | 90 +---
> drivers/vfio/vfio.h | 1 +
> drivers/vfio/vfio_main.c | 11 ++---
> include/linux/vfio.h | 2 +-
> 4 files changed, 91 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c
> index bb24b2f0271e..52f434861294 100644
> --- a/drivers/vfio/group.c
> +++ b/drivers/vfio/group.c
> @@ -13,6 +13,9 @@
> #include
> #include
> #include
> +#ifdef CONFIG_HAVE_KVM
> +#include
> +#endif
> #include "vfio.h"
>
> static struct vfio {
> @@ -154,6 +157,55 @@ static int vfio_group_ioctl_set_container(struct
> vfio_group *group,
> return ret;
> }
>
> +#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 can get the kvm pointer from the group
internally.
> +{
> + void (*pfn)(struct kvm *kvm);
> + bool (*fn)(struct kvm *kvm);
> + bool ret;
> +
We should assert_lockdep_held(>dev_set->lock) in both of these
since that seems to be what's protecting device->kvm and
device->put_kvm.
If we change as above to get the kvm pointer from the group within this
function, we can also move the kvm_ref_lock here, which seems to
simplify the caller quite a bit.
> + pfn = symbol_get(kvm_put_kvm);
> + if (WARN_ON(!pfn))
> + return false;
> +
> + fn = symbol_get(kvm_get_kvm_safe);
> + if (WARN_ON(!fn)) {
> + symbol_put(kvm_put_kvm);
> + return false;
> + }
> +
> + ret = fn(kvm);
> + if (ret)
> + device->put_kvm = pfn;
> + else
> + symbol_put(kvm_put_kvm);
> +
> + symbol_put(kvm_get_kvm_safe);
> +
> + return ret;
> +}
> +
> +static void vfio_kvm_put_kvm(struct vfio_device *device)
> +{
> + if (WARN_ON(!device->kvm || !device->put_kvm))
> + return;
It simplifies the caller if we can use this even in the !device->kvm
case.
> +
> + device->put_kvm(device->kvm);
> + device->put_kvm = NULL;
> + symbol_put(kvm_put_kvm);
> +}
> +
> +#else
> +static bool vfio_kvm_get_kvm_safe(struct vfio_device *device, struct kvm
> *kvm)
> +{
> + return false;
> +}
> +
> +static void vfio_kvm_put_kvm(struct vfio_device *device)
> +{
> +}
> +#endif
> +
> static int vfio_device_group_open(struct vfio_device *device)
> {
> int ret;
> @@ -164,14 +216,32 @@ static int vfio_device_group_open(struct vfio_device
> *device)
> goto out_unlock;
> }
>
> + mutex_lock(>dev_set->lock);
> +
> /*
> - * Here we pass the KVM pointer with the group under the lock. If the
> - * device driver will use it, it must obtain a reference and release it
> - * during close_device.
> + * Before the first device open, get the KVM pointer currently
> + * associated with the group (if there is one) and obtain a reference
> + * now that will be held until the open_count reaches 0 again. Save
> + * the pointer in the device for use by drivers.
>*/
> + if (device->open_count == 0) {
> + spin_lock(>group->kvm_ref_lock);
> + if (device->group->kvm &&
> + vfio_kvm_get_kvm_safe(device, device->group->kvm))
> + device->kvm = device->group->kvm;
> + spin_unlock(>group->kvm_ref_lock);
> + }
> +
> ret = vfio_device_open(device, device->group->iommufd,
>
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915/pvc: Annotate two more workaround/tuning registers as MCR
== 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
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113573v1/index.html
Participating hosts (25 -> 26)
--
Additional (2): fi-kbl-soraka fi-apl-guc
Missing(1): fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113573v1:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@slpc:
- {bat-rpls-1}: [DMESG-FAIL][1] ([i915#7996]) -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/bat-rpls-1/igt@i915_selftest@l...@slpc.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113573v1/bat-rpls-1/igt@i915_selftest@l...@slpc.html
Known issues
Here are the changes found in Patchwork_113573v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@fbdev@write:
- fi-blb-e6850: [PASS][3] -> [SKIP][4] ([fdo#109271]) +4 similar
issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/fi-blb-e6850/igt@fb...@write.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113573v1/fi-blb-e6850/igt@fb...@write.html
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113573v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-apl-guc: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613]) +3
similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113573v1/fi-apl-guc/igt@gem_lmem_swapp...@basic.html
- fi-kbl-soraka: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) +3
similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113573v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@i915_module_load@load:
- fi-kbl-soraka: NOTRUN -> [DMESG-WARN][8] ([i915#1982])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113573v1/fi-kbl-soraka/igt@i915_module_l...@load.html
* igt@i915_selftest@live@execlists:
- fi-kbl-soraka: NOTRUN -> [INCOMPLETE][9] ([i915#7156])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113573v1/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][10] ([i915#1886])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113573v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@kms_chamelium_frames@hdmi-crc-fast:
- fi-kbl-soraka: NOTRUN -> [SKIP][11] ([fdo#109271]) +15 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113573v1/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html
* igt@kms_chamelium_hpd@vga-hpd-fast:
- fi-apl-guc: NOTRUN -> [SKIP][12] ([fdo#109271]) +21 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113573v1/fi-apl-guc/igt@kms_chamelium_...@vga-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#7156]: https://gitlab.freedesktop.org/drm/intel/issues/7156
[i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
[i915#7996]: https://gitlab.freedesktop.org/drm/intel/issues/7996
Build changes
-
* Linux: CI_DRM_12681 -> Patchwork_113573v1
CI-20190529: 20190529
CI_DRM_12681: 8ee2ec597aa4b8331124bf852432c2ca2fd7b8d1 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7143: c7b12dcc460fc2348e1fa7f4dcb791bb82e29e44 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_113573v1: 8ee2ec597aa4b8331124bf852432c2ca2fd7b8d1 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
b3e9a2d1859c drm/i915/selftest: Use forcewake to sanity check engine wa lists
f597ef46ad8b drm/i915/xehp: LNCF/LBCF workarounds should be on the GT list
0df255708104 drm/i915/gen11: Wa_1408615072/Wa_1407596294 should be on GT list
b31067342c98 drm/i915/pvc: Annotate two
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/4] drm/i915/pvc: Annotate two more workaround/tuning registers as MCR
== 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 checked separately. - +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1:
[Intel-gfx] [PATCH 4/4] drm/i915/selftest: Use forcewake to sanity check engine wa lists
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 are not affected by engine resets are tagged in a
way that indicates they would be).
We can sanity check workaround registers placed on the RCS/CCS engine
workaround lists (including those placed there via the
general_render_compute_wa_init() function) by comparing against the
forcewake table. As far as we know, there's never a case where a
register that lives outside the RENDER powerwell will be reset by an
RCS/CCS engine reset.
Signed-off-by: Matt Roper
---
.../gpu/drm/i915/gt/selftest_workarounds.c| 52 +++
1 file changed, 52 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/selftest_workarounds.c
b/drivers/gpu/drm/i915/gt/selftest_workarounds.c
index 14a8b25b6204..1bc8febc5c1d 100644
--- a/drivers/gpu/drm/i915/gt/selftest_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/selftest_workarounds.c
@@ -1362,12 +1362,64 @@ live_engine_reset_workarounds(void *arg)
return ret;
}
+/*
+ * The bspec's documentation for register reset behavior can be unreliable for
+ * some MMIO ranges. But in general we do not expect registers outside the
+ * RENDER forcewake domain to be reset by RCS/CCS engine resets. If we find
+ * workaround registers on an RCS or CCS engine's list, it likely indicates
+ * the register is misdocumented in the bspec and the workaround implementation
+ * should be moved to the GT workaround list instead.
+ */
+static int
+live_check_engine_workarounds_fw(void *arg)
+{
+ struct intel_gt *gt = arg;
+ struct intel_engine_cs *engine;
+ struct wa_lists *lists;
+ enum intel_engine_id id;
+ int ret = 0;
+
+ lists = kzalloc(sizeof(*lists), GFP_KERNEL);
+ if (!lists)
+ return -ENOMEM;
+
+ reference_lists_init(gt, lists);
+
+ for_each_engine(engine, gt, id) {
+ struct i915_wa_list *wal = >engine[id].wa_list;
+ struct i915_wa *wa;
+ int i;
+
+ if (engine->class != RENDER_CLASS &&
+ engine->class != COMPUTE_CLASS)
+ continue;
+
+ for (i = 0, wa = wal->list; i < wal->count; i++, wa++) {
+ enum forcewake_domains fw;
+
+ fw = intel_uncore_forcewake_for_reg(gt->uncore, wa->reg,
+ FW_REG_READ |
FW_REG_WRITE);
+ if ((fw & FORCEWAKE_RENDER) == 0) {
+ pr_err("%s: Register %#x not in RENDER
forcewake domain!\n",
+ engine->name,
i915_mmio_reg_offset(wa->reg));
+ ret = -EINVAL;
+ }
+ }
+ }
+
+ reference_lists_fini(gt, lists);
+ kfree(lists);
+
+ return ret;
+}
+
int intel_workarounds_live_selftests(struct drm_i915_private *i915)
{
static const struct i915_subtest tests[] = {
SUBTEST(live_dirty_whitelist),
SUBTEST(live_reset_whitelist),
SUBTEST(live_isolated_whitelist),
+ SUBTEST(live_check_engine_workarounds_fw),
SUBTEST(live_gpu_reset_workarounds),
SUBTEST(live_engine_reset_workarounds),
};
--
2.39.1
[Intel-gfx] [PATCH 2/4] drm/i915/gen11: Wa_1408615072/Wa_1407596294 should be on GT list
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. As such, we should implement this on the GT
workaround list rather than an engine list.
Bspec: 19219
Fixes: 3551ff928744 ("drm/i915/gen11: Moving WAs to rcs_engine_wa_init()")
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index f45ca3d4a07c..7e93ba6b3208 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1405,6 +1405,13 @@ icl_gt_workarounds_init(struct intel_gt *gt, struct
i915_wa_list *wal)
GAMT_CHKN_BIT_REG,
GAMT_CHKN_DISABLE_L3_COH_PIPE);
+ /*
+* Wa_1408615072:icl,ehl (vsunit)
+* Wa_1407596294:icl,ehl (hsunit)
+*/
+ wa_write_or(wal, UNSLICE_UNIT_LEVEL_CLKGATE,
+ VSUNIT_CLKGATE_DIS | HSUNIT_CLKGATE_DIS);
+
/* Wa_1407352427:icl,ehl */
wa_write_or(wal, UNSLICE_UNIT_LEVEL_CLKGATE2,
PSDUNIT_CLKGATE_DIS);
@@ -2536,13 +2543,6 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
struct i915_wa_list *wal)
wa_masked_en(wal, GEN9_CSFE_CHICKEN1_RCS,
GEN11_ENABLE_32_PLANE_MODE);
- /*
-* Wa_1408615072:icl,ehl (vsunit)
-* Wa_1407596294:icl,ehl (hsunit)
-*/
- wa_write_or(wal, UNSLICE_UNIT_LEVEL_CLKGATE,
- VSUNIT_CLKGATE_DIS | HSUNIT_CLKGATE_DIS);
-
/*
* Wa_1408767742:icl[a2..forever],ehl[all]
* Wa_1605460711:icl[a0..c0]
--
2.39.1
[Intel-gfx] [PATCH 1/4] drm/i915/pvc: Annotate two more workaround/tuning registers as MCR
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 PVC
even without the MCR annotation, but readback verification on
CONFIG_DRM_I915_DEBUG_GEM builds could potentitally give false positive
"workaround lost on load" warnings on parts fused such that a unicast
read targets a terminated register instance.
Fixes: a9e69428b1b4 ("drm/i915: Define MCR registers explicitly")
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 4 ++--
drivers/gpu/drm/i915/gt/intel_workarounds.c | 12 +---
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 7fa18a3b3957..928698c621e5 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -979,7 +979,7 @@
#define GEN7_WA_FOR_GEN7_L3_CONTROL 0x3C47FF8C
#define GEN7_L3AGDIS (1 << 19)
-#define XEHPC_LNCFMISCCFGREG0 _MMIO(0xb01c)
+#define XEHPC_LNCFMISCCFGREG0 MCR_REG(0xb01c)
#define XEHPC_HOSTCACHEENREG_BIT(1)
#define XEHPC_OVRLSCCC REG_BIT(0)
@@ -1042,7 +1042,7 @@
#define XEHP_L3SCQREG7 MCR_REG(0xb188)
#define BLEND_FILL_CACHING_OPT_DIS REG_BIT(3)
-#define XEHPC_L3SCRUB _MMIO(0xb18c)
+#define XEHPC_L3SCRUB MCR_REG(0xb18c)
#define SCRUB_CL_DWNGRADE_SHARED REG_BIT(12)
#define SCRUB_RATE_PER_BANK_MASK REG_GENMASK(2, 0)
#define SCRUB_RATE_4B_PER_CLK
REG_FIELD_PREP(SCRUB_RATE_PER_BANK_MASK, 0x6)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 29718d0595f4..f45ca3d4a07c 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -240,6 +240,12 @@ wa_write(struct i915_wa_list *wal, i915_reg_t reg, u32 set)
wa_write_clr_set(wal, reg, ~0, set);
}
+static void
+wa_mcr_write(struct i915_wa_list *wal, i915_mcr_reg_t reg, u32 set)
+{
+ wa_mcr_write_clr_set(wal, reg, ~0, set);
+}
+
static void
wa_write_or(struct i915_wa_list *wal, i915_reg_t reg, u32 set)
{
@@ -2892,9 +2898,9 @@ add_render_compute_tuning_settings(struct
drm_i915_private *i915,
struct i915_wa_list *wal)
{
if (IS_PONTEVECCHIO(i915)) {
- wa_write(wal, XEHPC_L3SCRUB,
+ wa_mcr_write(wal, XEHPC_L3SCRUB,
SCRUB_CL_DWNGRADE_SHARED | SCRUB_RATE_4B_PER_CLK);
- wa_masked_en(wal, XEHPC_LNCFMISCCFGREG0, XEHPC_HOSTCACHEEN);
+ wa_mcr_masked_en(wal, XEHPC_LNCFMISCCFGREG0, XEHPC_HOSTCACHEEN);
}
if (IS_DG2(i915)) {
@@ -2984,7 +2990,7 @@ general_render_compute_wa_init(struct intel_engine_cs
*engine, struct i915_wa_li
if (IS_PONTEVECCHIO(i915)) {
/* Wa_16016694945 */
- wa_masked_en(wal, XEHPC_LNCFMISCCFGREG0, XEHPC_OVRLSCCC);
+ wa_mcr_masked_en(wal, XEHPC_LNCFMISCCFGREG0, XEHPC_OVRLSCCC);
}
if (IS_XEHPSDV(i915)) {
--
2.39.1
[Intel-gfx] [PATCH 3/4] drm/i915/xehp: LNCF/LBCF workarounds should be on the GT list
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 targetting them should be placed on the GT
workaround list rather than an engine workaround list.
Note that an extra clue here is that these registers moved from the
RENDER forcewake domain to the GT forcewake domain in Xe_HP; generally
RCS/CCS engine resets should not lead to the reset of a register that
lives outside the RENDER domain.
Re-applying these registers on engine resets wouldn't actually hurt
anything, but is unnecessary and just makes it more confusing to anyone
trying to decipher how these registers really work.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 61 +
1 file changed, 38 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 7e93ba6b3208..09c9837458b5 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1499,6 +1499,12 @@ xehpsdv_gt_workarounds_init(struct intel_gt *gt, struct
i915_wa_list *wal)
/* Wa_1409757795:xehpsdv */
wa_mcr_write_or(wal, SCCGCTL94DC, CG3DDISURB);
+ /* Wa_18011725039:xehpsdv */
+ if (IS_XEHPSDV_GRAPHICS_STEP(i915, STEP_A1, STEP_B0)) {
+ wa_mcr_masked_dis(wal, MLTICTXCTL, TDONRENDER);
+ wa_mcr_write_or(wal, L3SQCREG1_CCS0, FLUSHALLNONCOH);
+ }
+
/* Wa_16011155590:xehpsdv */
if (IS_XEHPSDV_GRAPHICS_STEP(i915, STEP_A0, STEP_B0))
wa_write_or(wal, UNSLICE_UNIT_LEVEL_CLKGATE,
@@ -1548,6 +1554,9 @@ xehpsdv_gt_workarounds_init(struct intel_gt *gt, struct
i915_wa_list *wal)
/* Wa_14014368820:xehpsdv */
wa_mcr_write_or(wal, XEHP_GAMCNTRL_CTRL,
INVALIDATION_BROADCAST_MODE_DIS |
GLOBAL_INVALIDATION_MODE);
+
+ /* Wa_14010670810:xehpsdv */
+ wa_mcr_write_or(wal, XEHP_L3NODEARBCFG, XEHP_LNESPARE);
}
static void
@@ -1684,6 +1693,9 @@ pvc_gt_workarounds_init(struct intel_gt *gt, struct
i915_wa_list *wal)
wa_mcr_write_or(wal, COMP_MOD_CTRL, FORCE_MISS_FTLB);
wa_mcr_write_or(wal, XEHP_VDBX_MOD_CTRL, FORCE_MISS_FTLB);
wa_mcr_write_or(wal, XEHP_VEBX_MOD_CTRL, FORCE_MISS_FTLB);
+
+ /* Wa_16016694945 */
+ wa_mcr_masked_en(wal, XEHPC_LNCFMISCCFGREG0, XEHPC_OVRLSCCC);
}
static void
@@ -1724,11 +1736,36 @@ xelpmp_gt_workarounds_init(struct intel_gt *gt, struct
i915_wa_list *wal)
debug_dump_steering(gt);
}
+/*
+ * The bspec performance guide has recommended MMIO tuning settings. These
+ * aren't truly "workarounds" but we want to program them through the
+ * workaround infrastructure to make sure they're (re)applied at the proper
+ * times.
+ *
+ * The settings in this function are for settings that persist through
+ * engine resets and also are not part of any engine's register state context.
+ * I.e., settings that only need to be re-applied in the event of a full GT
+ * reset.
+ */
+static void gt_tuning_settings(struct intel_gt *gt, struct i915_wa_list *wal)
+{
+ if (IS_PONTEVECCHIO(gt->i915)) {
+ wa_mcr_write(wal, XEHPC_L3SCRUB,
+SCRUB_CL_DWNGRADE_SHARED | SCRUB_RATE_4B_PER_CLK);
+ wa_mcr_masked_en(wal, XEHPC_LNCFMISCCFGREG0, XEHPC_HOSTCACHEEN);
+ }
+
+ if (IS_DG2(gt->i915))
+ wa_mcr_write_or(wal, XEHP_L3SCQREG7,
BLEND_FILL_CACHING_OPT_DIS);
+}
+
static void
gt_init_workarounds(struct intel_gt *gt, struct i915_wa_list *wal)
{
struct drm_i915_private *i915 = gt->i915;
+ gt_tuning_settings(gt, wal);
+
if (gt->type == GT_MEDIA) {
if (MEDIA_VER(i915) >= 13)
xelpmp_gt_workarounds_init(gt, wal);
@@ -2897,16 +2934,8 @@ static void
add_render_compute_tuning_settings(struct drm_i915_private *i915,
struct i915_wa_list *wal)
{
- if (IS_PONTEVECCHIO(i915)) {
- wa_mcr_write(wal, XEHPC_L3SCRUB,
-SCRUB_CL_DWNGRADE_SHARED | SCRUB_RATE_4B_PER_CLK);
- wa_mcr_masked_en(wal, XEHPC_LNCFMISCCFGREG0, XEHPC_HOSTCACHEEN);
- }
-
- if (IS_DG2(i915)) {
- wa_mcr_write_or(wal, XEHP_L3SCQREG7,
BLEND_FILL_CACHING_OPT_DIS);
+ if (IS_DG2(i915))
wa_mcr_write_clr_set(wal, RT_CTRL, STACKID_CTRL,
STACKID_CTRL_512);
- }
/*
* This tuning setting proves beneficial only on ATS-M designs; the
@@ -2988,11 +3017,6 @@ general_render_compute_wa_init(struct intel_engine_cs
*engine, struct i915_wa_li
0, false);
}
- if (IS_PONTEVECCHIO(i915)) {
- /*
Re: [Intel-gfx] linux-next: manual merge of the usb tree with the drm-intel-fixes tree
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 Shevchenko wrote:
> > > > > On Tue, Jan 31, 2023 at 01:03:05PM +1100, Stephen Rothwell wrote:
> > > > > > Today's linux-next merge of the usb tree got a conflict in:
> > > > > >
> > > > > > drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > > > >
> > > > > > between commit:
> > > > > >
> > > > > > 5bc4b43d5c6c ("drm/i915: Fix up locking around dumping requests
> > > > > > lists")
> > > > > >
> > > > > > from the drm-intel-fixes tree and commit:
> > > > > >
> > > > > > 4d70c74659d9 ("i915: Move list_count() to list.h as
> > > > > > list_count_nodes() for broader use")
> > > > > >
> > > > > > from the usb tree.
> > > > > >
> > > > > > I fixed it up (the former removed the code changed by the latter)
> > > > > Hmm... Currently I see that
> > > > > 20230127002842.3169194-4-john.c.harri...@intel.com
> > > > > moves the code to the
> > > > > drivers/gpu/drm/i915/gt/intel_execlists_submission.c.
> > > > >
> > > > > Is there any new series beside the above mentioned that touches that
> > > > > file and
> > > > > actually _removes_ that code?
> > > > As long as the removal is limited to list_count/list_count_nodes,
> > > > that's fine. I only moved it from one file to another because the one
> > > > and only function that was using it was being moved to the other
> > > > file. If someone else has found a use for the same and wants to move
> > > > it to a more common place then great. I assume there was no conflict
> > > > happening in the i915 specific code.
> > > I have added this fix up patch to linux-next today (more or less - this
> > > is a hand hacked version, but you get the idea):
> > >
> > > From: Stephen Rothwell
> > > Date: Wed, 1 Feb 2023 13:13:01 +1100
> > > Subject: [PATCH] i915: fix up for "drm/i915: Fix up locking around
> > > dumping requests lists"
> > >
> > > interacting with "i915: Move list_count() to list.h as list_count_nodes()
> > > for broader use"
> > >
> > > Signed-off-by: Stephen Rothwell
> > > ---
> > > .../gpu/drm/i915/gt/intel_execlists_submission.c| 15 +
> > > 1 file changed, 2 insertion(+), 13 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > > b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > > index 3c573d41d404..e919d41a48d9 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > > @@ -4150,17 +4150,6 @@ void intel_execlists_show_requests(struct
> > > intel_engine_cs *engine,
> > > spin_unlock_irqrestore(_engine->lock, flags);
> > > }
> > > -static unsigned long list_count(struct list_head *list)
> > > -{
> > > - struct list_head *pos;
> > > - unsigned long count = 0;
> > > -
> > > - list_for_each(pos, list)
> > > - count++;
> > > -
> > > - return count;
> > > -}
> > > -
> > > void intel_execlists_dump_active_requests(struct intel_engine_cs
> > > *engine,
> > > struct i915_request *hung_rq,
> > > struct drm_printer *m)
> > > @@ -4172,7 +4161,7 @@ void intel_execlists_dump_active_requests(struct
> > > intel_engine_cs *engine,
> > >
> > > intel_engine_dump_active_requests(>sched_engine->requests,
> > > hung_rq, m);
> > > - drm_printf(m, "\tOn hold?: %lu\n",
> > > -list_count(>sched_engine->hold));
> > > + drm_printf(m, "\tOn hold?: %zu\n",
> > > +list_count_nodes(>sched_engine->hold));
> > something awkward here.
> > The resolution on linux-next should align with the resolution on drm-tip
> > where we have the list_count still there as we preferred the version
> > on drm-intel-gt-next as the resolution of the conflict instead of the
> > fixes one.
> Not following why you want to keep list_count as a local function in the
> i915 driver? Surely the correct fix is to move it to the common header and
> share the code? In which case, the correct name is list_count_nodes() as
> that is what got merged to the common header.
right. please ignore my previous email and accept my apologies for the
unnecessary noise. I had just read the commit '4d70c74659d9 ("i915: Move
list_count() to list.h as list_count_nodes() for broader use")'
and it now the final resolution makes total sense. And that patch had
been reviewed and acked by us, so everything is good.
I just confused with other conflict that we have with our on gt-next
and -fixes tree but with an easier resolution.
Sorry,
Rodrigo.
>
> John.
>
> >
> > > spin_unlock_irqrestore(>sched_engine->lock, flags);
> > > }
> > > --
> > > 2.35.1
> > >
> > > --
> > > Cheers,
> > > Stephen Rothwell
> >
>
[Intel-gfx] ✓ Fi.CI.IGT: success for vfio: fix deadlock between group lock and kvm lock (rev2)
== 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
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v2/index.html
Participating hosts (11 -> 10)
--
Missing(1): shard-rkl0
Known issues
Here are the changes found in Patchwork_113535v2_full that come from known
issues:
### IGT changes ###
Possible fixes
* igt@drm_fdinfo@most-busy-check-all@rcs0:
- {shard-rkl}:[FAIL][1] ([i915#7742]) -> [PASS][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12680/shard-rkl-4/igt@drm_fdinfo@most-busy-check-...@rcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v2/shard-rkl-2/igt@drm_fdinfo@most-busy-check-...@rcs0.html
* igt@feature_discovery@psr2:
- {shard-rkl}:[SKIP][3] ([i915#658]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12680/shard-rkl-3/igt@feature_discov...@psr2.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v2/shard-rkl-6/igt@feature_discov...@psr2.html
* igt@gem_bad_reloc@negative-reloc-lut:
- {shard-rkl}:[SKIP][5] ([i915#3281]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12680/shard-rkl-4/igt@gem_bad_re...@negative-reloc-lut.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v2/shard-rkl-5/igt@gem_bad_re...@negative-reloc-lut.html
* igt@gem_ctx_persistence@engines-hang@bcs0:
- {shard-rkl}:[SKIP][7] ([i915#6252]) -> [PASS][8] +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12680/shard-rkl-5/igt@gem_ctx_persistence@engines-h...@bcs0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v2/shard-rkl-4/igt@gem_ctx_persistence@engines-h...@bcs0.html
* igt@gem_exec_endless@dispatch@bcs0:
- {shard-rkl}:[SKIP][9] ([i915#6247]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12680/shard-rkl-5/igt@gem_exec_endless@dispa...@bcs0.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v2/shard-rkl-6/igt@gem_exec_endless@dispa...@bcs0.html
* igt@gem_exec_fair@basic-none-vip@rcs0:
- {shard-rkl}:[FAIL][11] ([i915#2842]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12680/shard-rkl-4/igt@gem_exec_fair@basic-none-...@rcs0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v2/shard-rkl-5/igt@gem_exec_fair@basic-none-...@rcs0.html
* igt@gem_exec_fair@basic-none@rcs0:
- shard-glk: [FAIL][13] ([i915#2842]) -> [PASS][14] +1 similar
issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12680/shard-glk3/igt@gem_exec_fair@basic-n...@rcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v2/shard-glk5/igt@gem_exec_fair@basic-n...@rcs0.html
* igt@gen9_exec_parse@bb-large:
- {shard-rkl}:[SKIP][15] ([i915#2527]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12680/shard-rkl-4/igt@gen9_exec_pa...@bb-large.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v2/shard-rkl-5/igt@gen9_exec_pa...@bb-large.html
* igt@i915_pm_dc@dc9-dpms:
- {shard-rkl}:[SKIP][17] ([i915#3361]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12680/shard-rkl-5/igt@i915_pm...@dc9-dpms.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v2/shard-rkl-2/igt@i915_pm...@dc9-dpms.html
* igt@i915_pm_rpm@cursor:
- {shard-rkl}:[SKIP][19] ([i915#1849]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12680/shard-rkl-5/igt@i915_pm_...@cursor.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v2/shard-rkl-6/igt@i915_pm_...@cursor.html
* igt@i915_pm_rpm@dpms-mode-unset-lpsp:
- {shard-rkl}:[SKIP][21] ([i915#1397]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12680/shard-rkl-3/igt@i915_pm_...@dpms-mode-unset-lpsp.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v2/shard-rkl-6/igt@i915_pm_...@dpms-mode-unset-lpsp.html
* igt@kms_big_fb@x-tiled-32bpp-rotate-0:
- {shard-rkl}:[SKIP][23] ([i915#1845] / [i915#4098]) -> [PASS][24]
+24 similar issues
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12680/shard-rkl-3/igt@kms_big...@x-tiled-32bpp-rotate-0.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v2/shard-rkl-6/igt@kms_big...@x-tiled-32bpp-rotate-0.html
* igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions-varying-size:
- shard-glk: [FAIL][25] ([i915#2346]) -> [PASS][26]
[25]:
[Intel-gfx] ✓ Fi.CI.BAT: success for vfio: fix deadlock between group lock and kvm lock (rev2)
== 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
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v2/index.html
Participating hosts (26 -> 25)
--
Missing(1): fi-snb-2520m
Known issues
Here are the changes found in Patchwork_113535v2 that come from known issues:
### IGT changes ###
Possible fixes
* igt@i915_selftest@live@gt_pm:
- {bat-rpls-2}: [DMESG-FAIL][1] ([i915#4258]) -> [PASS][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12680/bat-rpls-2/igt@i915_selftest@live@gt_pm.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v2/bat-rpls-2/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@migrate:
- {bat-dg2-11}: [DMESG-WARN][3] ([i915#7699]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12680/bat-dg2-11/igt@i915_selftest@l...@migrate.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v2/bat-dg2-11/igt@i915_selftest@l...@migrate.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#4258]: https://gitlab.freedesktop.org/drm/intel/issues/4258
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#6311]: https://gitlab.freedesktop.org/drm/intel/issues/6311
[i915#7359]: https://gitlab.freedesktop.org/drm/intel/issues/7359
[i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
Build changes
-
* Linux: CI_DRM_12680 -> Patchwork_113535v2
CI-20190529: 20190529
CI_DRM_12680: 06086656e6f03cbcbb4b99273734a7943e923fc9 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7143: c7b12dcc460fc2348e1fa7f4dcb791bb82e29e44 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_113535v2: 06086656e6f03cbcbb4b99273734a7943e923fc9 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
a4f804de37f7 vfio: fix deadlock between group lock and kvm lock
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v2/index.html
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Consolidate TLB invalidation flow
== 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
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113563v1/index.html
Participating hosts (11 -> 11)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113563v1_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_invalid_mode@bad-vtotal@hdmi-a-4-pipe-a:
- {shard-dg1}:[PASS][1] -> [ABORT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12680/shard-dg1-15/igt@kms_invalid_mode@bad-vto...@hdmi-a-4-pipe-a.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113563v1/shard-dg1-15/igt@kms_invalid_mode@bad-vto...@hdmi-a-4-pipe-a.html
* igt@kms_invalid_mode@bad-vtotal@hdmi-a-4-pipe-d:
- {shard-dg1}:[PASS][3] -> [DMESG-WARN][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12680/shard-dg1-15/igt@kms_invalid_mode@bad-vto...@hdmi-a-4-pipe-d.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113563v1/shard-dg1-15/igt@kms_invalid_mode@bad-vto...@hdmi-a-4-pipe-d.html
Known issues
Here are the changes found in Patchwork_113563v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@kms_flip@2x-plain-flip-fb-recreate@ac-hdmi-a1-hdmi-a2:
- shard-glk: [PASS][5] -> [FAIL][6] ([i915#2122])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12680/shard-glk6/igt@kms_flip@2x-plain-flip-fb-recre...@ac-hdmi-a1-hdmi-a2.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113563v1/shard-glk5/igt@kms_flip@2x-plain-flip-fb-recre...@ac-hdmi-a1-hdmi-a2.html
Possible fixes
* igt@drm_fdinfo@most-busy-check-all@rcs0:
- {shard-rkl}:[FAIL][7] ([i915#7742]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12680/shard-rkl-4/igt@drm_fdinfo@most-busy-check-...@rcs0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113563v1/shard-rkl-1/igt@drm_fdinfo@most-busy-check-...@rcs0.html
* igt@drm_read@short-buffer-block:
- {shard-rkl}:[SKIP][9] ([i915#4098]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12680/shard-rkl-1/igt@drm_r...@short-buffer-block.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113563v1/shard-rkl-6/igt@drm_r...@short-buffer-block.html
* igt@fbdev@write:
- {shard-rkl}:[SKIP][11] ([i915#2582]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12680/shard-rkl-1/igt@fb...@write.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113563v1/shard-rkl-6/igt@fb...@write.html
* igt@feature_discovery@psr2:
- {shard-rkl}:[SKIP][13] ([i915#658]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12680/shard-rkl-3/igt@feature_discov...@psr2.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113563v1/shard-rkl-6/igt@feature_discov...@psr2.html
* igt@gem_ctx_persistence@engines-hang@bcs0:
- {shard-rkl}:[SKIP][15] ([i915#6252]) -> [PASS][16] +1 similar
issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12680/shard-rkl-5/igt@gem_ctx_persistence@engines-h...@bcs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113563v1/shard-rkl-1/igt@gem_ctx_persistence@engines-h...@bcs0.html
* igt@gem_exec_endless@dispatch@bcs0:
- {shard-rkl}:[SKIP][17] ([i915#6247]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12680/shard-rkl-5/igt@gem_exec_endless@dispa...@bcs0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113563v1/shard-rkl-3/igt@gem_exec_endless@dispa...@bcs0.html
* igt@gem_exec_reloc@basic-gtt-read-noreloc:
- {shard-rkl}:[SKIP][19] ([i915#3281]) -> [PASS][20] +5 similar
issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12680/shard-rkl-1/igt@gem_exec_re...@basic-gtt-read-noreloc.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113563v1/shard-rkl-5/igt@gem_exec_re...@basic-gtt-read-noreloc.html
* igt@gem_madvise@dontneed-before-exec:
- {shard-rkl}:[SKIP][21] ([i915#3282]) -> [PASS][22] +3 similar
issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12680/shard-rkl-4/igt@gem_madv...@dontneed-before-exec.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113563v1/shard-rkl-5/igt@gem_madv...@dontneed-before-exec.html
* igt@gen9_exec_parse@bb-start-far:
- {shard-rkl}:
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/quirks: Add inverted backlight quirk for HP 14-r206nv
== 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
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_113568v1 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_113568v1, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113568v1/index.html
Participating hosts (26 -> 26)
--
Additional (1): fi-kbl-soraka
Missing(1): fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113568v1:
### IGT changes ###
Possible regressions
* igt@i915_suspend@basic-s3-without-i915:
- fi-skl-6600u: [PASS][1] -> [ABORT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12680/fi-skl-6600u/igt@i915_susp...@basic-s3-without-i915.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113568v1/fi-skl-6600u/igt@i915_susp...@basic-s3-without-i915.html
Known issues
Here are the changes found in Patchwork_113568v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113568v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3
similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113568v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@i915_module_load@load:
- fi-kbl-soraka: NOTRUN -> [DMESG-WARN][5] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113568v1/fi-kbl-soraka/igt@i915_module_l...@load.html
* igt@i915_selftest@live@execlists:
- fi-kbl-soraka: NOTRUN -> [INCOMPLETE][6] ([i915#7156])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113568v1/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][7] ([i915#1886])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113568v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@kms_chamelium_frames@hdmi-crc-fast:
- fi-kbl-soraka: NOTRUN -> [SKIP][8] ([fdo#109271]) +15 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113568v1/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html
Possible fixes
* igt@i915_selftest@live@migrate:
- {bat-dg2-11}: [DMESG-WARN][9] ([i915#7699]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12680/bat-dg2-11/igt@i915_selftest@l...@migrate.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113568v1/bat-dg2-11/igt@i915_selftest@l...@migrate.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#6311]: https://gitlab.freedesktop.org/drm/intel/issues/6311
[i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
[i915#7156]: https://gitlab.freedesktop.org/drm/intel/issues/7156
[i915#7359]: https://gitlab.freedesktop.org/drm/intel/issues/7359
[i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
[i915#7996]: https://gitlab.freedesktop.org/drm/intel/issues/7996
Build changes
-
* Linux: CI_DRM_12680 -> Patchwork_113568v1
CI-20190529: 20190529
CI_DRM_12680: 06086656e6f03cbcbb4b99273734a7943e923fc9 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7143: c7b12dcc460fc2348e1fa7f4dcb791bb82e29e44 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_113568v1: 06086656e6f03cbcbb4b99273734a7943e923fc9 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
5bfe004e71e2 drm/i915/quirks: Add inverted backlight quirk for HP 14-r206nv
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113568v1/index.html
[Intel-gfx] [PATCH v2] vfio: fix deadlock between group lock and kvm lock
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 vfio-ap) need to acquire kvm->lock during their open_device
routine; Meanwhile, kvm_vfio_release will acquire the kvm->lock first
before calling vfio_file_set_kvm which will acquire the vfio group_lock.
To resolve this, let's remove the need for the vfio group_lock from the
kvm_vfio_release codepath. This is done by introducing a new spinlock to
protect modifications to the vfio group kvm pointer, and acquiring a kvm
ref from within vfio while holding this spinlock, with the reference held
until the last close for the device in question.
Fixes: 51cdc8bc120e ("kvm/vfio: Fix potential deadlock on vfio group_lock")
Reported-by: Anthony Krowiak
Suggested-by: Jason Gunthorpe
Signed-off-by: Matthew Rosato
---
Changes from v1:
* use spin_lock instead of spin_lock_irqsave (Jason)
* clear device->kvm_put as part of vfio_kvm_put_kvm (Yi)
* Re-arrange code to avoid referencing the group contents from within
vfio_main (Kevin) which meant moving most of the code in this patch
to group.c along with getting/dropping of the dev_set lock
---
drivers/vfio/group.c | 90 +---
drivers/vfio/vfio.h | 1 +
drivers/vfio/vfio_main.c | 11 ++---
include/linux/vfio.h | 2 +-
4 files changed, 91 insertions(+), 13 deletions(-)
diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c
index bb24b2f0271e..52f434861294 100644
--- a/drivers/vfio/group.c
+++ b/drivers/vfio/group.c
@@ -13,6 +13,9 @@
#include
#include
#include
+#ifdef CONFIG_HAVE_KVM
+#include
+#endif
#include "vfio.h"
static struct vfio {
@@ -154,6 +157,55 @@ static int vfio_group_ioctl_set_container(struct
vfio_group *group,
return ret;
}
+#ifdef CONFIG_HAVE_KVM
+static bool vfio_kvm_get_kvm_safe(struct vfio_device *device, struct kvm *kvm)
+{
+ void (*pfn)(struct kvm *kvm);
+ bool (*fn)(struct kvm *kvm);
+ bool ret;
+
+ pfn = symbol_get(kvm_put_kvm);
+ if (WARN_ON(!pfn))
+ return false;
+
+ fn = symbol_get(kvm_get_kvm_safe);
+ if (WARN_ON(!fn)) {
+ symbol_put(kvm_put_kvm);
+ return false;
+ }
+
+ ret = fn(kvm);
+ if (ret)
+ device->put_kvm = pfn;
+ else
+ symbol_put(kvm_put_kvm);
+
+ symbol_put(kvm_get_kvm_safe);
+
+ return ret;
+}
+
+static void vfio_kvm_put_kvm(struct vfio_device *device)
+{
+ if (WARN_ON(!device->kvm || !device->put_kvm))
+ return;
+
+ device->put_kvm(device->kvm);
+ device->put_kvm = NULL;
+ symbol_put(kvm_put_kvm);
+}
+
+#else
+static bool vfio_kvm_get_kvm_safe(struct vfio_device *device, struct kvm *kvm)
+{
+ return false;
+}
+
+static void vfio_kvm_put_kvm(struct vfio_device *device)
+{
+}
+#endif
+
static int vfio_device_group_open(struct vfio_device *device)
{
int ret;
@@ -164,14 +216,32 @@ static int vfio_device_group_open(struct vfio_device
*device)
goto out_unlock;
}
+ mutex_lock(>dev_set->lock);
+
/*
-* Here we pass the KVM pointer with the group under the lock. If the
-* device driver will use it, it must obtain a reference and release it
-* during close_device.
+* Before the first device open, get the KVM pointer currently
+* associated with the group (if there is one) and obtain a reference
+* now that will be held until the open_count reaches 0 again. Save
+* the pointer in the device for use by drivers.
*/
+ if (device->open_count == 0) {
+ spin_lock(>group->kvm_ref_lock);
+ if (device->group->kvm &&
+ vfio_kvm_get_kvm_safe(device, device->group->kvm))
+ device->kvm = device->group->kvm;
+ spin_unlock(>group->kvm_ref_lock);
+ }
+
ret = vfio_device_open(device, device->group->iommufd,
device->group->kvm);
+ if (ret && device->kvm && device->open_count == 0) {
+ vfio_kvm_put_kvm(device);
+ device->kvm = NULL;
+ }
+
+ mutex_unlock(>dev_set->lock);
+
out_unlock:
mutex_unlock(>group->group_lock);
return ret;
@@ -180,7 +250,16 @@ static int vfio_device_group_open(struct vfio_device
*device)
void vfio_device_group_close(struct vfio_device *device)
{
mutex_lock(>group->group_lock);
+ mutex_lock(>dev_set->lock);
+
vfio_device_close(device, device->group->iommufd);
+
+ if (device->kvm && device->open_count == 0) {
+ vfio_kvm_put_kvm(device);
+ device->kvm = NULL;
+ }
+
+ mutex_unlock(>dev_set->lock);
Re: [Intel-gfx] [PATCH] drm/i915/quirks: Add inverted backlight quirk for HP 14-r206nv
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 bug filed at fdo gitlab
with dmesg, VBT, etc. [1]
I don't doubt you, but the fix may need to be different. All the
previous quirks were on ancient GM45, and I was pretty sure the problems
were limited to that platform. I'm hesitant to add the quirk to other
platforms without more info.
Thanks,
Jani.
[1] https://gitlab.freedesktop.org/drm/intel/wikis/How-to-file-i915-bugs
> ---
> drivers/gpu/drm/i915/display/intel_quirks.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c
> b/drivers/gpu/drm/i915/display/intel_quirks.c
> index 6e48d3bcdfec..a280448df771 100644
> --- a/drivers/gpu/drm/i915/display/intel_quirks.c
> +++ b/drivers/gpu/drm/i915/display/intel_quirks.c
> @@ -199,6 +199,8 @@ static struct intel_quirk intel_quirks[] = {
> /* ECS Liva Q2 */
> { 0x3185, 0x1019, 0xa94d, quirk_increase_ddi_disabled_time },
> { 0x3184, 0x1019, 0xa94d, quirk_increase_ddi_disabled_time },
> + /* HP Notebook - 14-r206nv */
> + { 0x0f31, 0x103c, 0x220f, quirk_invert_brightness },
> };
>
> void intel_init_quirks(struct drm_i915_private *i915)
> --
> 2.34.1
>
>
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH i-g-t 2/2] tests/i915/perf: Exercise barrier race
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 interaction between perf open /
> > close operations, which replace active barriers with perf requests, and
> > concurrent barrier preallocate / acquire operations performed during
> > context first pin / last unpin.
> >
> > References: https://gitlab.freedesktop.org/drm/intel/-/issues/6333
> > Signed-off-by: Janusz Krzysztofik
> > Cc: Chris Wilson
> > ---
> > tests/i915/perf.c | 41 +++--
> > 1 file changed, 39 insertions(+), 2 deletions(-)
> >
> > diff --git a/tests/i915/perf.c b/tests/i915/perf.c
> > index e33cacc443..11a3ec21ab 100644
> > --- a/tests/i915/perf.c
> > +++ b/tests/i915/perf.c
> > @@ -39,6 +39,7 @@
> > #include
> >
> > #include "i915/gem.h"
> > +#include "i915/gem_create.h"
> > #include "i915/perf.h"
> > #include "igt.h"
> > #include "igt_perf.h"
> > @@ -4885,7 +4886,27 @@ test_whitelisted_registers_userspace_config(void)
> > i915_perf_remove_config(drm_fd, config_id);
> > }
> >
> > -static void test_open_race(const struct intel_execution_engine2 *e, int
> > timeout)
> > +static void gem_exec_nop(int i915, const struct intel_execution_engine2 *e)
> > +{
> > + const uint32_t bbe = MI_BATCH_BUFFER_END;
> > + struct drm_i915_gem_exec_object2 obj = { };
> > + struct drm_i915_gem_execbuffer2 execbuf = {
> > + .buffers_ptr = to_user_pointer(),
> > + .buffer_count = 1,
> > + };
> > +
> > + obj.handle = gem_create(i915, 4096);
> > + gem_write(i915, obj.handle, 0, , sizeof(bbe));
> > +
> > + execbuf.flags = e->flags;
> > + gem_execbuf(i915, );
> > +
> > + gem_sync(i915, obj.handle);
> > + gem_close(i915, obj.handle);
> > +}
> > +
> > +static void test_open_race(const struct intel_execution_engine2 *e, int
> > timeout,
> > + bool use_spin)
> -- ^
> This is not the best way to develop new code, it may be good
> for fast development but imho it is better to refactor existing
> code and avoiding to add bool logic into function.
I'm not sure what you mean. By refactoring, do you mean moving the code
common to both processing paths out to a separate helper, then call it from
two distinct functions, each implementing only one scenario? What's wrong
with passing flags that select one of alternative processing paths within one
function? Or are you just not happy with bool type?
> It can be done later as this is revealing the bug.
>
> > {
> > int *done;
> >
> > @@ -4926,6 +4947,12 @@ static void test_open_race(const struct
> > intel_execution_engine2 *e, int timeout)
> > ctx = gem_context_create_for_engine(i915,
> > e->class, e->instance);
> > gem_context_set_persistence(i915, ctx,
> > persistence);
> >
> > + if (!use_spin) {
> > + gem_exec_nop(i915, e);
> > + gem_context_destroy(i915, ctx);
> > + continue;
> > + }
> > +
> > spin = __igt_spin_new(i915, ctx, .ahnd = ahnd);
> > for (int i = random() % 7; i--; ) {
> > if (random() & 1) {
> > @@ -5330,7 +5357,17 @@ igt_main
> > for_each_physical_engine(drm_fd, e)
> > if (e->class == I915_ENGINE_CLASS_RENDER)
> > igt_dynamic_f("%s", e->name)
> > - test_open_race(e, 5);
> > + test_open_race(e, 5, true);
> > + }
> > +
>
> Please add here some TODO comments from discussions and a note
> which will help bug filling team to classify that.
TODO about moving the subtest to a different test -- OK. But instructions for
Bug Filling team? Hmm, what if this subtest triggers a completely different
bug in the future? Are we going to update the comments then? Do Bug Filling
team members really read the sources while classifying bugs?
Please have another look at an example of expected dmesg from the currently
triggered bug:
<4> [192.634015] list_del corruption. prev->next should be 8881479d34e0,
but was 888108af4ce0. (prev=888127335160)
<4> [192.634032] WARNING: CPU: 1 PID: 1286 at lib/list_debug.c:59
__list_del_entry_valid+0xb7/0xe0
<4> [192.634041] Modules linked in: vgem drm_shmem_helper fuse
snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio
x86_pkg_temp_thermal coretemp i915 prime_numbers i2c_algo_bit kvm_intel ttm
snd_hda_intel snd_intel_dspcfg kvm drm_buddy mei_pxp snd_hda_codec smsc75xx
irqbypass mei_hdcp e1000e drm_display_helper usbnet
[Intel-gfx] [PATCH] drm/i915/quirks: Add inverted backlight quirk for HP 14-r206nv
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 a/drivers/gpu/drm/i915/display/intel_quirks.c
b/drivers/gpu/drm/i915/display/intel_quirks.c
index 6e48d3bcdfec..a280448df771 100644
--- a/drivers/gpu/drm/i915/display/intel_quirks.c
+++ b/drivers/gpu/drm/i915/display/intel_quirks.c
@@ -199,6 +199,8 @@ static struct intel_quirk intel_quirks[] = {
/* ECS Liva Q2 */
{ 0x3185, 0x1019, 0xa94d, quirk_increase_ddi_disabled_time },
{ 0x3184, 0x1019, 0xa94d, quirk_increase_ddi_disabled_time },
+ /* HP Notebook - 14-r206nv */
+ { 0x0f31, 0x103c, 0x220f, quirk_invert_brightness },
};
void intel_init_quirks(struct drm_i915_private *i915)
--
2.34.1
Re: [Intel-gfx] [RFC] drm/i915: make dev_priv usage explitic in some macros
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 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 explicitly use dev_priv, so that we can > > > > change them later to be defined as i915. > > > > > > Lucas posted a slightly related patch [1], and I think based on the > > > discussion we should probably add AUX and DPLL registers that are > > > VLV/CHV specific, and include the MMIO offset directly without dev_priv, > > > and non-VLV/CHV macros that will have MMIO offset 0. This would reduce > > > the implicit dev_priv considerably, and avoid the need to pass i915 > > > pointer to those register macros altogether. > > > > Yes, I saw that. > > > > > > > > diff --git a/drivers/gpu/drm/i915/display/vlv_dsi_regs.h > > > > b/drivers/gpu/drm/i915/display/vlv_dsi_regs.h > > > > index abbe427e462e..d00e9321064a 100644 > > > > --- a/drivers/gpu/drm/i915/display/vlv_dsi_regs.h > > > > +++ b/drivers/gpu/drm/i915/display/vlv_dsi_regs.h > > > > @@ -100,7 +100,7 @@ > > > > > > > > #define _MIPIA_DEVICE_READY(_MIPI_MMIO_BASE(dev_priv) + > > > > 0xb000) > > > > #define _MIPIC_DEVICE_READY(_MIPI_MMIO_BASE(dev_priv) + > > > > 0xb800) > > > > -#define MIPI_DEVICE_READY(port)_MMIO_MIPI(port, > > > > _MIPIA_DEVICE_READY, _MIPIC_DEVICE_READY) > > > > +#define MIPI_DEVICE_READY(dev_priv, port) _MMIO_MIPI(port, > > > > _MIPIA_DEVICE_READY, _MIPIC_DEVICE_READY) > > > > > > While this kind of passes dev_priv as parameter, the dev_priv in > > > _MIPIA_DEVICE_READY and _MIPIC_DEVICE_READY is still implicit. > > > > Yes, this was on purpose and my second change is to modify the the > > calls to the inner macros to pass the parameter as well. > > > > In any case, this already works as is, even if we pass i915 to > > MIPI_DEVICE_READY() here, because the dev_priv that MIPI*_DEVICE_READY > > use will be expanded to whatever we passed as dev_priv to the outer > > macro. > > > > > > > I think these could use a similar treatment as in [1], moving the > > > _MIPI_MMIO_BASE() part one level up. > > > > Yes, and this can also be done with more rules after my other patches. > > The problem is if we all start making changes in this area at the same > > time, then there will be conflict after conflict. > > As I shared previously I think these manual changes need to come > *before* not after - why would you change the callers to pass dev_priv > and then ultimately remove? Let the scripted changes only do the > addition of dev_priv to the callers, after you removed the ones that > shouldn't have it at all > > This makes the script easier to write and run and can be postponed to > when the branches are in sync if we are going to cross the display/ > boundary. Yes, you're totally right. Sorry if my comment came out negative, that was not my intent. We're obviously all working on the same code base so we work in parallel and conflicts are a part of nature. :) > Anyway since you are changing this, I'll hold off on more patches > related to it. It's maybe a bit easier like that, but in any case the beauty of semantic patches is that they should "understand" other changes and act accordingly. With your changes, my rules wouldn't matchthose cases anymore, but would still match other ones. Regarding adding arguments just to remove them later, I think it's okay if we don't want to do everything in a gigantic patch. One patch is lying the foundation for the next that will actually make things cleaner. It's a bit easier to review, IMHO. We probably can, in the end, before actually merging the changes, squash everything together to avoid adding-just-to-remove. Let's see how it goes. Thanks for the comments! -- Cheers, Luca.
Re: [Intel-gfx] [PATCH] drm/i915/guc: Improve debug message on context reset notification
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.
Signed-off-by: Michal Wajdeczko
Cc: John Harrison
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 53f3ed3244d5..be495e657d66 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4660,9 +4660,10 @@ static void guc_handle_context_reset(struct intel_guc
*guc,
{
trace_intel_context_reset(ce);
- drm_dbg(_to_gt(guc)->i915->drm, "Got GuC reset of 0x%04X, exiting = %d, banned = %d\n",
- ce->guc_id.id, test_bit(CONTEXT_EXITING, >flags),
- test_bit(CONTEXT_BANNED, >flags));
+ guc_dbg(guc, "Got context reset notification: 0x%04X on %s, exiting = %s,
banned = %s\n",
+ ce->guc_id.id, ce->engine->name,
+ str_yes_no(intel_context_is_exiting(ce)),
+ str_yes_no(intel_context_is_banned(ce)));
if (likely(intel_context_is_schedulable(ce))) {
capture_error_state(guc, ce);
Re: [Intel-gfx] linux-next: manual merge of the usb tree with the drm-intel-fixes tree
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 linux-next merge of the usb tree got a conflict in:
drivers/gpu/drm/i915/gt/intel_engine_cs.c
between commit:
5bc4b43d5c6c ("drm/i915: Fix up locking around dumping requests lists")
from the drm-intel-fixes tree and commit:
4d70c74659d9 ("i915: Move list_count() to list.h as list_count_nodes() for
broader use")
from the usb tree.
I fixed it up (the former removed the code changed by the latter)
Hmm... Currently I see that 20230127002842.3169194-4-john.c.harri...@intel.com
moves the code to the drivers/gpu/drm/i915/gt/intel_execlists_submission.c.
Is there any new series beside the above mentioned that touches that file and
actually _removes_ that code?
As long as the removal is limited to list_count/list_count_nodes,
that's fine. I only moved it from one file to another because the one
and only function that was using it was being moved to the other
file. If someone else has found a use for the same and wants to move
it to a more common place then great. I assume there was no conflict
happening in the i915 specific code.
I have added this fix up patch to linux-next today (more or less - this
is a hand hacked version, but you get the idea):
From: Stephen Rothwell
Date: Wed, 1 Feb 2023 13:13:01 +1100
Subject: [PATCH] i915: fix up for "drm/i915: Fix up locking around dumping requests
lists"
interacting with "i915: Move list_count() to list.h as list_count_nodes() for
broader use"
Signed-off-by: Stephen Rothwell
---
.../gpu/drm/i915/gt/intel_execlists_submission.c| 15 +
1 file changed, 2 insertion(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 3c573d41d404..e919d41a48d9 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -4150,17 +4150,6 @@ void intel_execlists_show_requests(struct
intel_engine_cs *engine,
spin_unlock_irqrestore(_engine->lock, flags);
}
-static unsigned long list_count(struct list_head *list)
-{
- struct list_head *pos;
- unsigned long count = 0;
-
- list_for_each(pos, list)
- count++;
-
- return count;
-}
-
void intel_execlists_dump_active_requests(struct intel_engine_cs *engine,
struct i915_request *hung_rq,
struct drm_printer *m)
@@ -4172,7 +4161,7 @@ void intel_execlists_dump_active_requests(struct
intel_engine_cs *engine,
intel_engine_dump_active_requests(>sched_engine->requests,
hung_rq, m);
- drm_printf(m, "\tOn hold?: %lu\n",
- list_count(>sched_engine->hold));
+ drm_printf(m, "\tOn hold?: %zu\n",
+ list_count_nodes(>sched_engine->hold));
something awkward here.
The resolution on linux-next should align with the resolution on drm-tip
where we have the list_count still there as we preferred the version
on drm-intel-gt-next as the resolution of the conflict instead of the
fixes one.
Not following why you want to keep list_count as a local function in the
i915 driver? Surely the correct fix is to move it to the common header
and share the code? In which case, the correct name is
list_count_nodes() as that is what got merged to the common header.
John.
spin_unlock_irqrestore(>sched_engine->lock, flags);
}
--
2.35.1
--
Cheers,
Stephen Rothwell
Re: [Intel-gfx] [PATCH i-g-t 2/2] tests/i915/perf: Exercise barrier race
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 requests, and
> concurrent barrier preallocate / acquire operations performed during
> context first pin / last unpin.
>
> References: https://gitlab.freedesktop.org/drm/intel/-/issues/6333
> Signed-off-by: Janusz Krzysztofik
> Cc: Chris Wilson
> ---
> tests/i915/perf.c | 41 +++--
> 1 file changed, 39 insertions(+), 2 deletions(-)
>
> diff --git a/tests/i915/perf.c b/tests/i915/perf.c
> index e33cacc443..11a3ec21ab 100644
> --- a/tests/i915/perf.c
> +++ b/tests/i915/perf.c
> @@ -39,6 +39,7 @@
> #include
>
> #include "i915/gem.h"
> +#include "i915/gem_create.h"
> #include "i915/perf.h"
> #include "igt.h"
> #include "igt_perf.h"
> @@ -4885,7 +4886,27 @@ test_whitelisted_registers_userspace_config(void)
> i915_perf_remove_config(drm_fd, config_id);
> }
>
> -static void test_open_race(const struct intel_execution_engine2 *e, int
> timeout)
> +static void gem_exec_nop(int i915, const struct intel_execution_engine2 *e)
> +{
> + const uint32_t bbe = MI_BATCH_BUFFER_END;
> + struct drm_i915_gem_exec_object2 obj = { };
> + struct drm_i915_gem_execbuffer2 execbuf = {
> + .buffers_ptr = to_user_pointer(),
> + .buffer_count = 1,
> + };
> +
> + obj.handle = gem_create(i915, 4096);
> + gem_write(i915, obj.handle, 0, , sizeof(bbe));
> +
> + execbuf.flags = e->flags;
> + gem_execbuf(i915, );
> +
> + gem_sync(i915, obj.handle);
> + gem_close(i915, obj.handle);
> +}
> +
> +static void test_open_race(const struct intel_execution_engine2 *e, int
> timeout,
> +bool use_spin)
-- ^
This is not the best way to develop new code, it may be good
for fast development but imho it is better to refactor existing
code and avoiding to add bool logic into function.
It can be done later as this is revealing the bug.
> {
> int *done;
>
> @@ -4926,6 +4947,12 @@ static void test_open_race(const struct
> intel_execution_engine2 *e, int timeout)
> ctx = gem_context_create_for_engine(i915,
> e->class, e->instance);
> gem_context_set_persistence(i915, ctx,
> persistence);
>
> + if (!use_spin) {
> + gem_exec_nop(i915, e);
> + gem_context_destroy(i915, ctx);
> + continue;
> + }
> +
> spin = __igt_spin_new(i915, ctx, .ahnd = ahnd);
> for (int i = random() % 7; i--; ) {
> if (random() & 1) {
> @@ -5330,7 +5357,17 @@ igt_main
> for_each_physical_engine(drm_fd, e)
> if (e->class == I915_ENGINE_CLASS_RENDER)
> igt_dynamic_f("%s", e->name)
> - test_open_race(e, 5);
> + test_open_race(e, 5, true);
> + }
> +
Please add here some TODO comments from discussions and a note
which will help bug filling team to classify that.
Regards,
Kamil
> + igt_describe("Exercise perf open/close against intensive barrier
> preallocate/acquire");
> + igt_subtest_with_dynamic("barrier-race") {
> + const struct intel_execution_engine2 *e;
> +
> + for_each_physical_engine(drm_fd, e)
> + if (e->class == I915_ENGINE_CLASS_RENDER)
> + igt_dynamic_f("%s", e->name)
> + test_open_race(e, 5, false);
> }
>
> igt_fixture {
> --
> 2.25.1
>
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Consolidate TLB invalidation flow
== 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
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113563v1/index.html
Participating hosts (26 -> 25)
--
Missing(1): fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113563v1:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@i915_selftest@live@gt_tlb}:
- fi-kbl-7567u: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12680/fi-kbl-7567u/igt@i915_selftest@live@gt_tlb.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113563v1/fi-kbl-7567u/igt@i915_selftest@live@gt_tlb.html
- {bat-kbl-2}:[PASS][3] -> [DMESG-FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12680/bat-kbl-2/igt@i915_selftest@live@gt_tlb.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113563v1/bat-kbl-2/igt@i915_selftest@live@gt_tlb.html
- fi-cfl-8109u: [PASS][5] -> [DMESG-FAIL][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12680/fi-cfl-8109u/igt@i915_selftest@live@gt_tlb.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113563v1/fi-cfl-8109u/igt@i915_selftest@live@gt_tlb.html
* igt@i915_selftest@live@slpc:
- {bat-rpls-1}: [DMESG-FAIL][7] ([i915#7996]) -> [DMESG-FAIL][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12680/bat-rpls-1/igt@i915_selftest@l...@slpc.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113563v1/bat-rpls-1/igt@i915_selftest@l...@slpc.html
Known issues
Here are the changes found in Patchwork_113563v1 that come from known issues:
### IGT changes ###
Possible fixes
* igt@i915_selftest@live@migrate:
- {bat-dg2-11}: [DMESG-WARN][9] ([i915#7699]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12680/bat-dg2-11/igt@i915_selftest@l...@migrate.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113563v1/bat-dg2-11/igt@i915_selftest@l...@migrate.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
[i915#7996]: https://gitlab.freedesktop.org/drm/intel/issues/7996
Build changes
-
* Linux: CI_DRM_12680 -> Patchwork_113563v1
CI-20190529: 20190529
CI_DRM_12680: 06086656e6f03cbcbb4b99273734a7943e923fc9 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7143: c7b12dcc460fc2348e1fa7f4dcb791bb82e29e44 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_113563v1: 06086656e6f03cbcbb4b99273734a7943e923fc9 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
eee9e2013646 drm/i915: Consolidate TLB invalidation flow
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113563v1/index.html
Re: [Intel-gfx] [RFC] drm/i915: make dev_priv usage explitic in some macros
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 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 explicitly use dev_priv, so that we can > change them later to be defined as i915. Lucas posted a slightly related patch [1], and I think based on the discussion we should probably add AUX and DPLL registers that are VLV/CHV specific, and include the MMIO offset directly without dev_priv, and non-VLV/CHV macros that will have MMIO offset 0. This would reduce the implicit dev_priv considerably, and avoid the need to pass i915 pointer to those register macros altogether. Yes, I saw that. > diff --git a/drivers/gpu/drm/i915/display/vlv_dsi_regs.h b/drivers/gpu/drm/i915/display/vlv_dsi_regs.h > index abbe427e462e..d00e9321064a 100644 > --- a/drivers/gpu/drm/i915/display/vlv_dsi_regs.h > +++ b/drivers/gpu/drm/i915/display/vlv_dsi_regs.h > @@ -100,7 +100,7 @@ > > #define _MIPIA_DEVICE_READY (_MIPI_MMIO_BASE(dev_priv) + 0xb000) > #define _MIPIC_DEVICE_READY (_MIPI_MMIO_BASE(dev_priv) + 0xb800) > -#define MIPI_DEVICE_READY(port) _MMIO_MIPI(port, _MIPIA_DEVICE_READY, _MIPIC_DEVICE_READY) > +#define MIPI_DEVICE_READY(dev_priv, port) _MMIO_MIPI(port, _MIPIA_DEVICE_READY, _MIPIC_DEVICE_READY) While this kind of passes dev_priv as parameter, the dev_priv in _MIPIA_DEVICE_READY and _MIPIC_DEVICE_READY is still implicit. Yes, this was on purpose and my second change is to modify the the calls to the inner macros to pass the parameter as well. In any case, this already works as is, even if we pass i915 to MIPI_DEVICE_READY() here, because the dev_priv that MIPI*_DEVICE_READY use will be expanded to whatever we passed as dev_priv to the outer macro. I think these could use a similar treatment as in [1], moving the _MIPI_MMIO_BASE() part one level up. Yes, and this can also be done with more rules after my other patches. The problem is if we all start making changes in this area at the same time, then there will be conflict after conflict. As I shared previously I think these manual changes need to come *before* not after - why would you change the callers to pass dev_priv and then ultimately remove? Let the scripted changes only do the addition of dev_priv to the callers, after you removed the ones that shouldn't have it at all This makes the script easier to write and run and can be postponed to when the branches are in sync if we are going to cross the display/ boundary. Anyway since you are changing this, I'll hold off on more patches related to it. Lucas De Marchi -- Cheers, Luca.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Consolidate TLB invalidation flow
== 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 should match open parenthesis
#99: FILE: drivers/gpu/drm/i915/gt/intel_engine_cs.c:1207:
+ if (gt_WARN_ON_ONCE(engine->gt,
+class >= num ||
-:157: ERROR:OPEN_BRACE: open brace '{' following struct go on the same line
#157: FILE: drivers/gpu/drm/i915/gt/intel_engine_types.h:350:
+struct intel_engine_tlb_inv
+{
total: 1 errors, 0 warnings, 1 checks, 324 lines checked
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Keep sagv status updated on icl+
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 question whether SAGV is
> actually enabled or not.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Stanislav Lisovskiy
> ---
> drivers/gpu/drm/i915/display/intel_bw.c | 49 +++--
> 1 file changed, 29 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> b/drivers/gpu/drm/i915/display/intel_bw.c
> index 1c236f02b380..202321ffbe2a 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -119,6 +119,32 @@ static int adls_pcode_read_psf_gv_point_info(struct
> drm_i915_private *dev_priv,
> return 0;
> }
>
> +static u16 icl_qgv_points_mask(struct drm_i915_private *i915)
> +{
> + unsigned int num_psf_gv_points =
> i915->display.bw.max[0].num_psf_gv_points;
> + unsigned int num_qgv_points = i915->display.bw.max[0].num_qgv_points;
> + u16 qgv_points = 0, psf_points = 0;
> +
> + /*
> + * We can _not_ use the whole ADLS_QGV_PT_MASK here, as PCode rejects
> + * it with failure if we try masking any unadvertised points.
> + * So need to operate only with those returned from PCode.
> + */
> + if (num_qgv_points > 0)
> + qgv_points = GENMASK(num_qgv_points - 1, 0);
> +
> + if (num_psf_gv_points > 0)
> + psf_points = GENMASK(num_psf_gv_points - 1, 0);
> +
> + return ICL_PCODE_REQ_QGV_PT(qgv_points) |
> ADLS_PCODE_REQ_PSF_PT(psf_points);
> +}
> +
> +static bool is_sagv_enabled(struct drm_i915_private *i915, u16 points_mask)
> +{
> + return !is_power_of_2(~points_mask & icl_qgv_points_mask(i915) &
> + ICL_PCODE_REQ_QGV_PT_MASK);
> +}
> +
> int icl_pcode_restrict_qgv_points(struct drm_i915_private *dev_priv,
> u32 points_mask)
> {
> @@ -136,6 +162,9 @@ int icl_pcode_restrict_qgv_points(struct drm_i915_private
> *dev_priv,
> return ret;
> }
>
> + dev_priv->display.sagv.status = is_sagv_enabled(dev_priv, points_mask) ?
> + I915_SAGV_ENABLED : I915_SAGV_DISABLED;
> +
> return 0;
> }
>
> @@ -965,26 +994,6 @@ int intel_bw_calc_min_cdclk(struct intel_atomic_state
> *state,
> return 0;
> }
>
> -static u16 icl_qgv_points_mask(struct drm_i915_private *i915)
> -{
> - unsigned int num_psf_gv_points =
> i915->display.bw.max[0].num_psf_gv_points;
> - unsigned int num_qgv_points = i915->display.bw.max[0].num_qgv_points;
> - u16 qgv_points = 0, psf_points = 0;
> -
> - /*
> - * We can _not_ use the whole ADLS_QGV_PT_MASK here, as PCode rejects
> - * it with failure if we try masking any unadvertised points.
> - * So need to operate only with those returned from PCode.
> - */
> - if (num_qgv_points > 0)
> - qgv_points = GENMASK(num_qgv_points - 1, 0);
> -
> - if (num_psf_gv_points > 0)
> - psf_points = GENMASK(num_psf_gv_points - 1, 0);
> -
> - return ICL_PCODE_REQ_QGV_PT(qgv_points) |
> ADLS_PCODE_REQ_PSF_PT(psf_points);
> -}
> -
> static int intel_bw_check_data_rate(struct intel_atomic_state *state, bool
> *changed)
> {
> struct drm_i915_private *i915 = to_i915(state->base.dev);
> --
> 2.39.1
>
Re: [Intel-gfx] [PATCH 1/4] drm/i915: Don't do the WM0->WM1 copy w/a if WM1 is already enabled
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 level enabled on a per-plane basis
> it doesn't seem necessary to do that copy when we already have an
> enabled WM1 on the current plane. That is, we might be in a situation
> where another plane can only do WM0 (and thus needs the copy) but
> the current plane's WM1 is still perfectly valid (ie. fits into the
> current DDB allocation).
>
> Skipping the copy could avoid reprogramming the plane's registers
> needlessly in some cases.
>
> Fixes: a301cb0fca2d ("drm/i915: Keep plane watermarks enabled more
> aggressively")
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/skl_watermark.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c
> b/drivers/gpu/drm/i915/display/skl_watermark.c
> index 261cdab390b4..0c605034356f 100644
> --- a/drivers/gpu/drm/i915/display/skl_watermark.c
> +++ b/drivers/gpu/drm/i915/display/skl_watermark.c
> @@ -1586,7 +1586,8 @@ skl_crtc_allocate_plane_ddb(struct intel_atomic_state
> *state,
> skl_check_wm_level(>wm[level], ddb);
>
> if (icl_need_wm1_wa(i915, plane_id) &&
> - level == 1 && wm->wm[0].enable) {
> + level == 1 && !wm->wm[level].enable &&
> + wm->wm[0].enable) {
> wm->wm[level].blocks = wm->wm[0].blocks;
> wm->wm[level].lines = wm->wm[0].lines;
> wm->wm[level].ignore_lines =
> wm->wm[0].ignore_lines;
Took some time to remember once again the logic here :)
We probably need to make this more easily readable, because the comment
kinda suggests that we disable all wms starting from level + 1 here, while
we actually do also check with ddb allocation first.
Reviewed-by: Stanislav Lisovskiy
> --
> 2.39.1
>
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: add guard page to ggtt->error_capture
== 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
---
**FAILURE**
Serious unknown changes coming with Patchwork_113560v1 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_113560v1, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v1/index.html
Participating hosts (26 -> 26)
--
Additional (1): fi-kbl-soraka
Missing(1): fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113560v1:
### IGT changes ###
Possible regressions
* igt@dmabuf@all-tests@dma_fence:
- fi-cfl-8109u: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12680/fi-cfl-8109u/igt@dmabuf@all-tests@dma_fence.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v1/fi-cfl-8109u/igt@dmabuf@all-tests@dma_fence.html
* igt@dmabuf@all-tests@sanitycheck:
- fi-cfl-8109u: [PASS][3] -> [ABORT][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12680/fi-cfl-8109u/igt@dmabuf@all-te...@sanitycheck.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v1/fi-cfl-8109u/igt@dmabuf@all-te...@sanitycheck.html
* igt@i915_module_load@load:
- fi-blb-e6850: [PASS][5] -> [ABORT][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12680/fi-blb-e6850/igt@i915_module_l...@load.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v1/fi-blb-e6850/igt@i915_module_l...@load.html
Known issues
Here are the changes found in Patchwork_113560v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@fbdev@eof:
- fi-kbl-soraka: NOTRUN -> [DMESG-WARN][7] ([i915#1982])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v1/fi-kbl-soraka/igt@fb...@eof.html
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#2190])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#4613]) +3
similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@i915_selftest@live@execlists:
- fi-kbl-soraka: NOTRUN -> [INCOMPLETE][10] ([i915#7156])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v1/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][11] ([i915#1886])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@kms_chamelium_frames@hdmi-crc-fast:
- fi-kbl-soraka: NOTRUN -> [SKIP][12] ([fdo#109271]) +15 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v1/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-n3050: [PASS][13] -> [FAIL][14] ([i915#6298])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12680/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v1/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
Possible fixes
* igt@i915_selftest@live@migrate:
- {bat-dg2-11}: [DMESG-WARN][15] ([i915#7699]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12680/bat-dg2-11/igt@i915_selftest@l...@migrate.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v1/bat-dg2-11/igt@i915_selftest@l...@migrate.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
[i915#7156]:
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Move common mmio base out of private macros
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 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. > >> > > >> > Signed-off-by: Lucas De Marchi > >> > --- > >> > drivers/gpu/drm/i915/i915_reg.h | 73 ++--- > >> > 1 file changed, 39 insertions(+), 34 deletions(-) > >> > > >> > diff --git a/drivers/gpu/drm/i915/i915_reg.h > >> > b/drivers/gpu/drm/i915/i915_reg.h > >> > index 943db8ec63f8..1cde3bcb9c88 100644 > >> > --- a/drivers/gpu/drm/i915/i915_reg.h > >> > +++ b/drivers/gpu/drm/i915/i915_reg.h > >> > @@ -1182,9 +1182,9 @@ > >> > #define PM_VEBOX_CS_ERROR_INTERRUPT (1 << 12) /* hsw+ */ > >> > #define PM_VEBOX_USER_INTERRUPT (1 << 10) /* hsw+ */ > >> > > >> > -#define GT_PARITY_ERROR(dev_priv) \ > >> > +#define GT_PARITY_ERROR(__i915) \ > >> > (GT_RENDER_L3_PARITY_ERROR_INTERRUPT | \ > >> > - (IS_HASWELL(dev_priv) ? GT_RENDER_L3_PARITY_ERROR_INTERRUPT_S1 > >> > : 0)) > >> > + (IS_HASWELL(__i915) ? GT_RENDER_L3_PARITY_ERROR_INTERRUPT_S1 : > >> > 0)) > >> > >> Unrelated change. > >> > >> > > >> > /* These are all the "old" interrupts */ > >> > #define ILK_BSD_USER_INTERRUPT (1 << 5) > >> > @@ -1403,10 +1403,11 @@ > >> > /* > >> > * Clock control & power management > >> > */ > >> > -#define _DPLL_A (DISPLAY_MMIO_BASE(dev_priv) + 0x6014) > >> > -#define _DPLL_B (DISPLAY_MMIO_BASE(dev_priv) + 0x6018) > >> > -#define _CHV_DPLL_C (DISPLAY_MMIO_BASE(dev_priv) + 0x6030) > >> > -#define DPLL(pipe) _MMIO_PIPE3((pipe), _DPLL_A, _DPLL_B, _CHV_DPLL_C) > >> > +#define _DPLL_A 0x6014 > >> > +#define _DPLL_B 0x6018 > >> > +#define _CHV_DPLL_C 0x6030 > >> > +#define DPLL(pipe) _MMIO(DISPLAY_MMIO_BASE(dev_priv) + \ > >> > + _PIPE3((pipe), _DPLL_A, _DPLL_B, _CHV_DPLL_C)) > >> > > >> > #define VGA0_MMIO(0x6000) > >> > #define VGA1_MMIO(0x6004) > >> > @@ -1502,10 +1503,11 @@ > >> > #define SDVO_MULTIPLIER_SHIFT_HIRES 4 > >> > #define SDVO_MULTIPLIER_SHIFT_VGA 0 > >> > > >> > -#define _DPLL_A_MD (DISPLAY_MMIO_BASE(dev_priv) + 0x601c) > >> > -#define _DPLL_B_MD (DISPLAY_MMIO_BASE(dev_priv) + 0x6020) > >> > -#define _CHV_DPLL_C_MD (DISPLAY_MMIO_BASE(dev_priv) + 0x603c) > >> > -#define DPLL_MD(pipe) _MMIO_PIPE3((pipe), _DPLL_A_MD, _DPLL_B_MD, > >> > _CHV_DPLL_C_MD) > >> > +#define _DPLL_A_MD 0x601c > >> > +#define _DPLL_B_MD 0x6020 > >> > +#define _CHV_DPLL_C_MD 0x603c > >> > +#define DPLL_MD(pipe) _MMIO(DISPLAY_MMIO_BASE(dev_priv) + \ > >> > +_PIPE3((pipe), _DPLL_A_MD, _DPLL_B_MD, > >> > _CHV_DPLL_C_MD)) > >> > > >> > /* > >> > * UDI pixel divider, controlling how many pixels are stuffed into a > >> > packet. > >> > @@ -3323,42 +3325,45 @@ > >> > * is 20 bytes in each direction, hence the 5 fixed > >> > * data registers > >> > */ > >> > -#define _DPA_AUX_CH_CTL (DISPLAY_MMIO_BASE(dev_priv) + 0x64010) > >> > -#define _DPA_AUX_CH_DATA1 (DISPLAY_MMIO_BASE(dev_priv) + 0x64014) > >> > - > >> > -#define _DPB_AUX_CH_CTL (DISPLAY_MMIO_BASE(dev_priv) + 0x64110) > >> > -#define _DPB_AUX_CH_DATA1 (DISPLAY_MMIO_BASE(dev_priv) + 0x64114) > >> > - > >> > -#define DP_AUX_CH_CTL(aux_ch) _MMIO_PORT(aux_ch, _DPA_AUX_CH_CTL, > >> > _DPB_AUX_CH_CTL) > >> > -#define DP_AUX_CH_DATA(aux_ch, i) _MMIO(_PORT(aux_ch, > >> > _DPA_AUX_CH_DATA1, _DPB_AUX_CH_DATA1) + (i) * 4) /* 5 registers */ > >> > +#define _DPA_AUX_CH_CTL 0x64010 > >> > +#define _DPA_AUX_CH_DATA1 0x64014 > >> > +#define _DPB_AUX_CH_CTL 0x64110 > >> > +#define _DPB_AUX_CH_DATA1 0x64114 > >> > +#define DP_AUX_CH_CTL(aux_ch) _MMIO(DISPLAY_MMIO_BASE(dev_priv) + \ > >> > + _PORT(aux_ch, _DPA_AUX_CH_CTL, > >> > _DPB_AUX_CH_CTL)) > >> > +#define DP_AUX_CH_DATA(aux_ch, i) \ > >> > +_MMIO(DISPLAY_MMIO_BASE(dev_priv) + \ > >> > + _PORT(aux_ch, _DPA_AUX_CH_DATA1, _DPB_AUX_CH_DATA1) + (i) > >> > * 4) /* 5 registers */ > >> > > >> > #define _XELPDP_USBC1_AUX_CH_CTL0x16F210 > >> > #define _XELPDP_USBC2_AUX_CH_CTL0x16F410 > >> > #define _XELPDP_USBC3_AUX_CH_CTL0x16F610 > >> > #define _XELPDP_USBC4_AUX_CH_CTL0x16F810 > >> > > >> > -#define XELPDP_DP_AUX_CH_CTL(aux_ch)_MMIO(_PICK(aux_ch, \ > >> > - _DPA_AUX_CH_CTL, > >> > \ > >> > -
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Move common mmio base out of private macros
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 used outside the > header. This reduces the use of the implicit dev_priv, making it easier > to remove it later. > > Signed-off-by: Lucas De Marchi > --- > drivers/gpu/drm/i915/i915_reg.h | 73 ++--- > 1 file changed, 39 insertions(+), 34 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h > index 943db8ec63f8..1cde3bcb9c88 100644 > --- a/drivers/gpu/drm/i915/i915_reg.h > +++ b/drivers/gpu/drm/i915/i915_reg.h > @@ -1182,9 +1182,9 @@ > #define PM_VEBOX_CS_ERROR_INTERRUPT (1 << 12) /* hsw+ */ > #define PM_VEBOX_USER_INTERRUPT (1 << 10) /* hsw+ */ > > -#define GT_PARITY_ERROR(dev_priv) \ > +#define GT_PARITY_ERROR(__i915) \ >(GT_RENDER_L3_PARITY_ERROR_INTERRUPT | \ > - (IS_HASWELL(dev_priv) ? GT_RENDER_L3_PARITY_ERROR_INTERRUPT_S1 : 0)) > + (IS_HASWELL(__i915) ? GT_RENDER_L3_PARITY_ERROR_INTERRUPT_S1 : 0)) Unrelated change. > > /* These are all the "old" interrupts */ > #define ILK_BSD_USER_INTERRUPT(1 << 5) > @@ -1403,10 +1403,11 @@ > /* > * Clock control & power management > */ > -#define _DPLL_A (DISPLAY_MMIO_BASE(dev_priv) + 0x6014) > -#define _DPLL_B (DISPLAY_MMIO_BASE(dev_priv) + 0x6018) > -#define _CHV_DPLL_C (DISPLAY_MMIO_BASE(dev_priv) + 0x6030) > -#define DPLL(pipe) _MMIO_PIPE3((pipe), _DPLL_A, _DPLL_B, _CHV_DPLL_C) > +#define _DPLL_A 0x6014 > +#define _DPLL_B 0x6018 > +#define _CHV_DPLL_C 0x6030 > +#define DPLL(pipe) _MMIO(DISPLAY_MMIO_BASE(dev_priv) + \ > + _PIPE3((pipe), _DPLL_A, _DPLL_B, _CHV_DPLL_C)) > > #define VGA0 _MMIO(0x6000) > #define VGA1 _MMIO(0x6004) > @@ -1502,10 +1503,11 @@ > #define SDVO_MULTIPLIER_SHIFT_HIRES 4 > #define SDVO_MULTIPLIER_SHIFT_VGA 0 > > -#define _DPLL_A_MD (DISPLAY_MMIO_BASE(dev_priv) + 0x601c) > -#define _DPLL_B_MD (DISPLAY_MMIO_BASE(dev_priv) + 0x6020) > -#define _CHV_DPLL_C_MD (DISPLAY_MMIO_BASE(dev_priv) + 0x603c) > -#define DPLL_MD(pipe) _MMIO_PIPE3((pipe), _DPLL_A_MD, _DPLL_B_MD, _CHV_DPLL_C_MD) > +#define _DPLL_A_MD0x601c > +#define _DPLL_B_MD0x6020 > +#define _CHV_DPLL_C_MD0x603c > +#define DPLL_MD(pipe) _MMIO(DISPLAY_MMIO_BASE(dev_priv) + \ > + _PIPE3((pipe), _DPLL_A_MD, _DPLL_B_MD, _CHV_DPLL_C_MD)) > > /* > * UDI pixel divider, controlling how many pixels are stuffed into a packet. > @@ -3323,42 +3325,45 @@ > * is 20 bytes in each direction, hence the 5 fixed > * data registers > */ > -#define _DPA_AUX_CH_CTL (DISPLAY_MMIO_BASE(dev_priv) + 0x64010) > -#define _DPA_AUX_CH_DATA1 (DISPLAY_MMIO_BASE(dev_priv) + 0x64014) > - > -#define _DPB_AUX_CH_CTL (DISPLAY_MMIO_BASE(dev_priv) + 0x64110) > -#define _DPB_AUX_CH_DATA1 (DISPLAY_MMIO_BASE(dev_priv) + 0x64114) > - > -#define DP_AUX_CH_CTL(aux_ch) _MMIO_PORT(aux_ch, _DPA_AUX_CH_CTL, _DPB_AUX_CH_CTL) > -#define DP_AUX_CH_DATA(aux_ch, i) _MMIO(_PORT(aux_ch, _DPA_AUX_CH_DATA1, _DPB_AUX_CH_DATA1) + (i) * 4) /* 5 registers */ > +#define _DPA_AUX_CH_CTL 0x64010 > +#define _DPA_AUX_CH_DATA1 0x64014 > +#define _DPB_AUX_CH_CTL 0x64110 > +#define _DPB_AUX_CH_DATA1 0x64114 > +#define DP_AUX_CH_CTL(aux_ch) _MMIO(DISPLAY_MMIO_BASE(dev_priv) + \ > +_PORT(aux_ch, _DPA_AUX_CH_CTL, _DPB_AUX_CH_CTL)) > +#define DP_AUX_CH_DATA(aux_ch, i) \ > + _MMIO(DISPLAY_MMIO_BASE(dev_priv) + \ > +_PORT(aux_ch, _DPA_AUX_CH_DATA1, _DPB_AUX_CH_DATA1) + (i) * 4) /* 5 registers */ > > #define _XELPDP_USBC1_AUX_CH_CTL 0x16F210 > #define _XELPDP_USBC2_AUX_CH_CTL 0x16F410 > #define _XELPDP_USBC3_AUX_CH_CTL 0x16F610 > #define _XELPDP_USBC4_AUX_CH_CTL 0x16F810 > > -#define XELPDP_DP_AUX_CH_CTL(aux_ch) _MMIO(_PICK(aux_ch, \ > - _DPA_AUX_CH_CTL, \ > - _DPB_AUX_CH_CTL, \ > - 0, /* port/aux_ch C is non-existent */ \ > - _XELPDP_USBC1_AUX_CH_CTL, \ > - _XELPDP_USBC2_AUX_CH_CTL, \ > - _XELPDP_USBC3_AUX_CH_CTL, \ > - _XELPDP_USBC4_AUX_CH_CTL)) > +#define XELPDP_DP_AUX_CH_CTL(aux_ch) _MMIO(DISPLAY_MMIO_BASE(dev_priv) + \ Note that only VLV and CHV have DISPLAY_MMIO_BASE() != 0. This is an XELPDP specific macro. Just drop the DISPLAY_MMIO_BASE()
Re: [Intel-gfx] [PATCH v10 04/23] drm/i915/vm_bind: Support partially mapped vma resource
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: Niranjana Vishwanathapura Reviewed-by: Andi Shyti Andi > --- > drivers/gpu/drm/i915/i915_vma.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c > index 34f0e6c923c2..79b2e19a299f 100644 > --- a/drivers/gpu/drm/i915/i915_vma.c > +++ b/drivers/gpu/drm/i915/i915_vma.c > @@ -2060,8 +2060,7 @@ static struct dma_fence *__i915_vma_unbind_async(struct > i915_vma *vma) > if (!drm_mm_node_allocated(>node)) > return NULL; > > - if (i915_vma_is_pinned(vma) || > - >obj->mm.rsgt->table != vma->resource->bi.pages) > + if (i915_vma_is_pinned(vma)) > return ERR_PTR(-EAGAIN); > > /* > -- > 2.21.0.rc0.32.g243a4c7e27
Re: [Intel-gfx] [PATCH v10 03/23] drm/i915/vm_bind: Expose i915_gem_object_max_page_size()
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 Shyti
> ---
> drivers/gpu/drm/i915/gem/i915_gem_create.c | 18 +-
> drivers/gpu/drm/i915/gem/i915_gem_object.h | 2 ++
> 2 files changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
> b/drivers/gpu/drm/i915/gem/i915_gem_create.c
> index 005a7f842784..86469710bd59 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
> @@ -15,10 +15,18 @@
> #include "i915_trace.h"
> #include "i915_user_extensions.h"
>
> -static u32 object_max_page_size(struct intel_memory_region **placements,
> - unsigned int n_placements)
> +/**
> + * i915_gem_object_max_page_size() - max of min_page_size of the regions
> + * @placements: list of regions
> + * @n_placements: number of the placements
> + *
> + * Returns the largest of min_page_size of the @placements,
> + * or I915_GTT_PAGE_SIZE_4K if @n_placements is 0.
> + */
> +u32 i915_gem_object_max_page_size(struct intel_memory_region **placements,
> + unsigned int n_placements)
> {
> - u32 max_page_size = 0;
> + u32 max_page_size = I915_GTT_PAGE_SIZE_4K;
> int i;
>
> for (i = 0; i < n_placements; i++) {
> @@ -28,7 +36,6 @@ static u32 object_max_page_size(struct intel_memory_region
> **placements,
> max_page_size = max_t(u32, max_page_size, mr->min_page_size);
> }
>
> - GEM_BUG_ON(!max_page_size);
this change, though, is not described in the commit log. Can you
please add two lines?
Thanks,
Andi
> return max_page_size;
> }
>
> @@ -99,7 +106,8 @@ __i915_gem_object_create_user_ext(struct drm_i915_private
> *i915, u64 size,
>
> i915_gem_flush_free_objects(i915);
>
> - size = round_up(size, object_max_page_size(placements, n_placements));
> + size = round_up(size, i915_gem_object_max_page_size(placements,
> + n_placements));
> if (size == 0)
> return ERR_PTR(-EINVAL);
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> index 3db53769864c..5455ca0eabe9 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> @@ -47,6 +47,8 @@ static inline bool i915_gem_object_size_2big(u64 size)
> }
>
> void i915_gem_init__objects(struct drm_i915_private *i915);
> +u32 i915_gem_object_max_page_size(struct intel_memory_region **placements,
> + unsigned int n_placements);
>
> void i915_objects_module_exit(void);
> int i915_objects_module_init(void);
> --
> 2.21.0.rc0.32.g243a4c7e27
Re: [Intel-gfx] [RFC] drm/i915: make dev_priv usage explitic in some macros
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 to be > > declared as i915 instead of arbitrarily using either i915 or dev_priv, > > we need to make these macros explicitly use dev_priv, so that we can > > change them later to be defined as i915. > > Lucas posted a slightly related patch [1], and I think based on the > discussion we should probably add AUX and DPLL registers that are > VLV/CHV specific, and include the MMIO offset directly without dev_priv, > and non-VLV/CHV macros that will have MMIO offset 0. This would reduce > the implicit dev_priv considerably, and avoid the need to pass i915 > pointer to those register macros altogether. Yes, I saw that. > > diff --git a/drivers/gpu/drm/i915/display/vlv_dsi_regs.h > > b/drivers/gpu/drm/i915/display/vlv_dsi_regs.h > > index abbe427e462e..d00e9321064a 100644 > > --- a/drivers/gpu/drm/i915/display/vlv_dsi_regs.h > > +++ b/drivers/gpu/drm/i915/display/vlv_dsi_regs.h > > @@ -100,7 +100,7 @@ > > > > #define _MIPIA_DEVICE_READY(_MIPI_MMIO_BASE(dev_priv) + > > 0xb000) > > #define _MIPIC_DEVICE_READY(_MIPI_MMIO_BASE(dev_priv) + > > 0xb800) > > -#define MIPI_DEVICE_READY(port)_MMIO_MIPI(port, > > _MIPIA_DEVICE_READY, _MIPIC_DEVICE_READY) > > +#define MIPI_DEVICE_READY(dev_priv, port) _MMIO_MIPI(port, > > _MIPIA_DEVICE_READY, _MIPIC_DEVICE_READY) > > While this kind of passes dev_priv as parameter, the dev_priv in > _MIPIA_DEVICE_READY and _MIPIC_DEVICE_READY is still implicit. Yes, this was on purpose and my second change is to modify the the calls to the inner macros to pass the parameter as well. In any case, this already works as is, even if we pass i915 to MIPI_DEVICE_READY() here, because the dev_priv that MIPI*_DEVICE_READY use will be expanded to whatever we passed as dev_priv to the outer macro. > I think these could use a similar treatment as in [1], moving the > _MIPI_MMIO_BASE() part one level up. Yes, and this can also be done with more rules after my other patches. The problem is if we all start making changes in this area at the same time, then there will be conflict after conflict. -- Cheers, Luca.
Re: [Intel-gfx] [RFC] drm/i915: make dev_priv usage explitic in some macros
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 declared as i915 instead of arbitrarily using either i915 or dev_priv, we need to make these macros explicitly use dev_priv, so that we can change them later to be defined as i915. Lucas posted a slightly related patch [1], and I think based on the discussion we should probably add AUX and DPLL registers that are VLV/CHV specific, and include the MMIO offset directly without dev_priv, and non-VLV/CHV macros that will have MMIO offset 0. This would reduce the implicit dev_priv considerably, and avoid the need to pass i915 pointer to those register macros altogether. diff --git a/drivers/gpu/drm/i915/display/vlv_dsi_regs.h b/drivers/gpu/drm/i915/display/vlv_dsi_regs.h index abbe427e462e..d00e9321064a 100644 --- a/drivers/gpu/drm/i915/display/vlv_dsi_regs.h +++ b/drivers/gpu/drm/i915/display/vlv_dsi_regs.h @@ -100,7 +100,7 @@ #define _MIPIA_DEVICE_READY(_MIPI_MMIO_BASE(dev_priv) + 0xb000) #define _MIPIC_DEVICE_READY(_MIPI_MMIO_BASE(dev_priv) + 0xb800) -#define MIPI_DEVICE_READY(port)_MMIO_MIPI(port, _MIPIA_DEVICE_READY, _MIPIC_DEVICE_READY) +#define MIPI_DEVICE_READY(dev_priv, port) _MMIO_MIPI(port, _MIPIA_DEVICE_READY, _MIPIC_DEVICE_READY) While this kind of passes dev_priv as parameter, the dev_priv in _MIPIA_DEVICE_READY and _MIPIC_DEVICE_READY is still implicit. I think these could use a similar treatment as in [1], moving the _MIPI_MMIO_BASE() part one level up. Agreed. I think we should have these manual changes first: they make the interface better and can even be merged without churn to the codebase, as they are header-only. Then the rest we mass convert with a script like shared here. Lucas De Marchi
Re: [Intel-gfx] [PATCH v10 02/23] drm/i915/vm_bind: Add __i915_sw_fence_await_reservation()
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 Auld
> Signed-off-by: Niranjana Vishwanathapura
Reviewed-by: Andi Shyti
Andi
> ---
> drivers/gpu/drm/i915/i915_sw_fence.c | 28 +---
> drivers/gpu/drm/i915/i915_sw_fence.h | 23 +--
> 2 files changed, 38 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c
> b/drivers/gpu/drm/i915/i915_sw_fence.c
> index cc2a8821d22a..ae06d35db056 100644
> --- a/drivers/gpu/drm/i915/i915_sw_fence.c
> +++ b/drivers/gpu/drm/i915/i915_sw_fence.c
> @@ -7,7 +7,6 @@
> #include
> #include
> #include
> -#include
>
> #include "i915_sw_fence.h"
> #include "i915_selftest.h"
> @@ -569,11 +568,26 @@ int __i915_sw_fence_await_dma_fence(struct
> i915_sw_fence *fence,
> return ret;
> }
>
> -int i915_sw_fence_await_reservation(struct i915_sw_fence *fence,
> - struct dma_resv *resv,
> - bool write,
> - unsigned long timeout,
> - gfp_t gfp)
> +/**
> + * __i915_sw_fence_await_reservation() - Setup a fence to wait on a dma-resv
> + * object with specified usage.
> + * @fence: the fence that needs to wait
> + * @resv: dma-resv object
> + * @usage: dma_resv_usage (See enum dma_resv_usage)
> + * @timeout: how long to wait in jiffies
> + * @gfp: allocation mode
> + *
> + * Setup the @fence to asynchronously wait on dma-resv object @resv for
> + * @usage to complete before signaling.
> + *
> + * Returns 0 if there is nothing to wait on, -ve error code upon error
> + * and >0 upon successfully setting up the wait.
> + */
> +int __i915_sw_fence_await_reservation(struct i915_sw_fence *fence,
> + struct dma_resv *resv,
> + enum dma_resv_usage usage,
> + unsigned long timeout,
> + gfp_t gfp)
> {
> struct dma_resv_iter cursor;
> struct dma_fence *f;
> @@ -582,7 +596,7 @@ int i915_sw_fence_await_reservation(struct i915_sw_fence
> *fence,
> debug_fence_assert(fence);
> might_sleep_if(gfpflags_allow_blocking(gfp));
>
> - dma_resv_iter_begin(, resv, dma_resv_usage_rw(write));
> + dma_resv_iter_begin(, resv, usage);
> dma_resv_for_each_fence_unlocked(, f) {
> pending = i915_sw_fence_await_dma_fence(fence, f, timeout,
> gfp);
> diff --git a/drivers/gpu/drm/i915/i915_sw_fence.h
> b/drivers/gpu/drm/i915/i915_sw_fence.h
> index f752bfc7c6e1..9c4859dc4c0d 100644
> --- a/drivers/gpu/drm/i915/i915_sw_fence.h
> +++ b/drivers/gpu/drm/i915/i915_sw_fence.h
> @@ -10,13 +10,13 @@
> #define _I915_SW_FENCE_H_
>
> #include
> +#include
> #include
> #include
> #include /* for NOTIFY_DONE */
> #include
>
> struct completion;
> -struct dma_resv;
> struct i915_sw_fence;
>
> enum i915_sw_fence_notify {
> @@ -89,11 +89,22 @@ int i915_sw_fence_await_dma_fence(struct i915_sw_fence
> *fence,
> unsigned long timeout,
> gfp_t gfp);
>
> -int i915_sw_fence_await_reservation(struct i915_sw_fence *fence,
> - struct dma_resv *resv,
> - bool write,
> - unsigned long timeout,
> - gfp_t gfp);
> +int __i915_sw_fence_await_reservation(struct i915_sw_fence *fence,
> + struct dma_resv *resv,
> + enum dma_resv_usage usage,
> + unsigned long timeout,
> + gfp_t gfp);
> +
> +static inline int i915_sw_fence_await_reservation(struct i915_sw_fence
> *fence,
> + struct dma_resv *resv,
> + bool write,
> + unsigned long timeout,
> + gfp_t gfp)
> +{
> + return __i915_sw_fence_await_reservation(fence, resv,
> + dma_resv_usage_rw(write),
> + timeout, gfp);
> +}
>
> bool i915_sw_fence_await(struct i915_sw_fence *fence);
> void i915_sw_fence_complete(struct i915_sw_fence *fence);
> --
> 2.21.0.rc0.32.g243a4c7e27
Re: [Intel-gfx] [RFC] drm/i915: make dev_priv usage explitic in some macros
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 or dev_priv, > we need to make these macros explicitly use dev_priv, so that we can > change them later to be defined as i915. Lucas posted a slightly related patch [1], and I think based on the discussion we should probably add AUX and DPLL registers that are VLV/CHV specific, and include the MMIO offset directly without dev_priv, and non-VLV/CHV macros that will have MMIO offset 0. This would reduce the implicit dev_priv considerably, and avoid the need to pass i915 pointer to those register macros altogether. > diff --git a/drivers/gpu/drm/i915/display/vlv_dsi_regs.h > b/drivers/gpu/drm/i915/display/vlv_dsi_regs.h > index abbe427e462e..d00e9321064a 100644 > --- a/drivers/gpu/drm/i915/display/vlv_dsi_regs.h > +++ b/drivers/gpu/drm/i915/display/vlv_dsi_regs.h > @@ -100,7 +100,7 @@ > > #define _MIPIA_DEVICE_READY (_MIPI_MMIO_BASE(dev_priv) + 0xb000) > #define _MIPIC_DEVICE_READY (_MIPI_MMIO_BASE(dev_priv) + 0xb800) > -#define MIPI_DEVICE_READY(port) _MMIO_MIPI(port, > _MIPIA_DEVICE_READY, _MIPIC_DEVICE_READY) > +#define MIPI_DEVICE_READY(dev_priv, port) _MMIO_MIPI(port, > _MIPIA_DEVICE_READY, _MIPIC_DEVICE_READY) While this kind of passes dev_priv as parameter, the dev_priv in _MIPIA_DEVICE_READY and _MIPIC_DEVICE_READY is still implicit. I think these could use a similar treatment as in [1], moving the _MIPI_MMIO_BASE() part one level up. BR, Jani. [1] https://patchwork.freedesktop.org/patch/msgid/20230131191542.1695398-2-lucas.demar...@intel.com -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [RFC] drm/i915: make dev_priv usage explitic in some macros
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 to be
> > declared as i915 instead of arbitrarily using either i915 or dev_priv,
> > we need to make these macros explicitly use dev_priv, so that we can
> > change them later to be defined as i915.
> >
> > In order to find and change all occurrences, the following semantic
> > patch rules were used:
>
> Quite challenging task.
It was definitely a very nice exercise! :)
> > @macros_noargs@
> > identifier m;
> > expression e =~ "dev_priv";
> > @@
> >
> > @nested_macros@
> > identifier macros_noargs.m;
> > identifier nm;
> > identifier list il;
> > @@
>
> Out of curiosity, what is purpose of above stances? Matching sections
> are empty.
>
Oops, it seems that git removed the lines that start with # when I
entered the commit message, since it ignores all lines starting with #.
This is how these two should actually look like:
@macros_noargs@
identifier m;
expression e =~ "dev_priv";
@@
#define m <+...e...+>
@nested_macros@
identifier macros_noargs.m;
identifier nm;
identifier list il;
@@
#define nm(il) <+...m...+>
I basically use the first one to match all "inner" macros that use
dev_priv and the second one I use to match all "outer" macros that use
the ones I found before.
> > @@
> > identifier nested_macros.nm;
> > identifier dev_priv, f;
> > expression list el;
> > @@
> > f(...) {
> > ...
> > struct drm_i915_private *dev_priv = ...;
> >
> > <+...
> > nm(
> > + dev_priv,
> > el)
> > ...+>
> > }
> >
> > @@
> > identifier nested_macros.nm;
> > identifier dev_priv, f;
> > expression list el;
> > @@
> > f(..., struct drm_i915_private *dev_priv, ...) {
> > <+...
> > nm(
> > + dev_priv,
> > el)
> > ...+>
> > }
> >
> > @@
> > identifier nested_macros.nm;
> > identifier list il;
> > expression e;
> > @@
> > -#define nm(il) e
> > +#define nm(dev_priv,il) e
> >
> > Signed-off-by: Luca Coelho
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 34 ++-
> > .../drm/i915/display/intel_display_power.c| 2 +-
> > .../i915/display/intel_display_power_well.c | 22 +-
> > drivers/gpu/drm/i915/display/intel_dp_aux.c | 40 +--
> > drivers/gpu/drm/i915/display/intel_dpll.c | 57 ++--
> > drivers/gpu/drm/i915/display/intel_dvo.c | 6 +-
> > drivers/gpu/drm/i915/display/intel_pps.c | 2 +-
> > drivers/gpu/drm/i915/display/vlv_dsi.c| 266 +++---
> > drivers/gpu/drm/i915/display/vlv_dsi_pll.c| 6 +-
> > drivers/gpu/drm/i915/display/vlv_dsi_regs.h | 93 +++---
> > drivers/gpu/drm/i915/gvt/handlers.c | 22 +-
> > drivers/gpu/drm/i915/i915_reg.h | 26 +-
> > drivers/gpu/drm/i915/intel_gvt_mmio_table.c | 6 +-
> > 13 files changed, 316 insertions(+), 266 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index e37cca6b18c6..f563d6dd3b4f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -469,11 +469,11 @@ void vlv_wait_port_ready(struct drm_i915_private
> > *dev_priv,
> > fallthrough;
> > case PORT_B:
> > port_mask = DPLL_PORTB_READY_MASK;
> > - dpll_reg = DPLL(0);
> > + dpll_reg = DPLL(dev_priv, 0);
> > break;
> > case PORT_C:
> > port_mask = DPLL_PORTC_READY_MASK;
> > - dpll_reg = DPLL(0);
> > + dpll_reg = DPLL(dev_priv, 0);
> > expected_mask <<= 4;
> > break;
> > case PORT_D:
> > @@ -3248,14 +3248,16 @@ static bool i9xx_get_pipe_config(struct intel_crtc
> > *crtc,
> > if (IS_CHERRYVIEW(dev_priv) && crtc->pipe != PIPE_A)
> > tmp = dev_priv->display.state.chv_dpll_md[crtc->pipe];
> > else
> > - tmp = intel_de_read(dev_priv, DPLL_MD(crtc->pipe));
> > + tmp = intel_de_read(dev_priv,
> > + DPLL_MD(dev_priv, crtc->pipe));
> > pipe_config->pixel_multiplier =
> > ((tmp & DPLL_MD_UDI_MULTIPLIER_MASK)
> > >> DPLL_MD_UDI_MULTIPLIER_SHIFT) + 1;
> > pipe_config->dpll_hw_state.dpll_md = tmp;
> > } else if (IS_I945G(dev_priv) || IS_I945GM(dev_priv) ||
> >IS_G33(dev_priv) || IS_PINEVIEW(dev_priv)) {
> > - tmp = intel_de_read(dev_priv, DPLL(crtc->pipe));
> > + tmp = intel_de_read(dev_priv,
> > + DPLL(dev_priv, crtc->pipe));
> > pipe_config->pixel_multiplier =
> > ((tmp & SDVO_MULTIPLIER_MASK)
> > >>
[Intel-gfx] [PATCH v3] drm/i915: Consolidate TLB invalidation flow
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 each and every TLB
invalidation.
v2:
* Fail engine probe if TLB invlidations registers are unknown.
v3:
* Rebase.
Signed-off-by: Tvrtko Ursulin
Cc: Andrzej Hajda
Cc: Matt Roper
Reviewed-by: Andrzej Hajda # v1
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 96 +
drivers/gpu/drm/i915/gt/intel_engine_types.h | 15 ++
drivers/gpu/drm/i915/gt/intel_gt.c | 138 +++
3 files changed, 133 insertions(+), 116 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index d4e29da74612..e430945743ec 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -9,6 +9,7 @@
#include "gem/i915_gem_context.h"
#include "gem/i915_gem_internal.h"
+#include "gt/intel_gt_print.h"
#include "gt/intel_gt_regs.h"
#include "i915_cmd_parser.h"
@@ -1143,12 +1144,107 @@ static int init_status_page(struct intel_engine_cs
*engine)
return ret;
}
+static int intel_engine_init_tlb_invalidation(struct intel_engine_cs *engine)
+{
+ static const union intel_engine_tlb_inv_reg gen8_regs[] = {
+ [RENDER_CLASS].reg = GEN8_RTCR,
+ [VIDEO_DECODE_CLASS].reg= GEN8_M1TCR, /* , GEN8_M2TCR */
+ [VIDEO_ENHANCEMENT_CLASS].reg = GEN8_VTCR,
+ [COPY_ENGINE_CLASS].reg = GEN8_BTCR,
+ };
+ static const union intel_engine_tlb_inv_reg gen12_regs[] = {
+ [RENDER_CLASS].reg = GEN12_GFX_TLB_INV_CR,
+ [VIDEO_DECODE_CLASS].reg= GEN12_VD_TLB_INV_CR,
+ [VIDEO_ENHANCEMENT_CLASS].reg = GEN12_VE_TLB_INV_CR,
+ [COPY_ENGINE_CLASS].reg = GEN12_BLT_TLB_INV_CR,
+ [COMPUTE_CLASS].reg = GEN12_COMPCTX_TLB_INV_CR,
+ };
+ static const union intel_engine_tlb_inv_reg xehp_regs[] = {
+ [RENDER_CLASS].mcr_reg= XEHP_GFX_TLB_INV_CR,
+ [VIDEO_DECODE_CLASS].mcr_reg = XEHP_VD_TLB_INV_CR,
+ [VIDEO_ENHANCEMENT_CLASS].mcr_reg = XEHP_VE_TLB_INV_CR,
+ [COPY_ENGINE_CLASS].mcr_reg = XEHP_BLT_TLB_INV_CR,
+ [COMPUTE_CLASS].mcr_reg = XEHP_COMPCTX_TLB_INV_CR,
+ };
+ struct drm_i915_private *i915 = engine->i915;
+ const union intel_engine_tlb_inv_reg *regs;
+ union intel_engine_tlb_inv_reg reg;
+ unsigned int class = engine->class;
+ unsigned int num = 0;
+ u32 val;
+
+ /*
+* New platforms should not be added with catch-all-newer (>=)
+* condition so that any later platform added triggers the below warning
+* and in turn mandates a human cross-check of whether the invalidation
+* flows have compatible semantics.
+*
+* For instance with the 11.00 -> 12.00 transition three out of five
+* respective engine registers were moved to masked type. Then after the
+* 12.00 -> 12.50 transition multi cast handling is required too.
+*/
+
+ if (GRAPHICS_VER_FULL(i915) == IP_VER(12, 50) ||
+ GRAPHICS_VER_FULL(i915) == IP_VER(12, 55)) {
+ regs = xehp_regs;
+ num = ARRAY_SIZE(xehp_regs);
+ } else if (GRAPHICS_VER_FULL(i915) == IP_VER(12, 0) ||
+ GRAPHICS_VER_FULL(i915) == IP_VER(12, 10)) {
+ regs = gen12_regs;
+ num = ARRAY_SIZE(gen12_regs);
+ } else if (GRAPHICS_VER(i915) >= 8 && GRAPHICS_VER(i915) <= 11) {
+ regs = gen8_regs;
+ num = ARRAY_SIZE(gen8_regs);
+ } else if (GRAPHICS_VER(i915) < 8) {
+ return 0;
+ }
+
+ if (gt_WARN_ONCE(engine->gt, !num,
+"Platform does not implement TLB invalidation!"))
+ return -ENODEV;
+
+ if (gt_WARN_ON_ONCE(engine->gt,
+class >= num ||
+(!regs[class].reg.reg &&
+ !regs[class].mcr_reg.reg)))
+ return -ERANGE;
+
+ reg = regs[class];
+
+ if (GRAPHICS_VER(i915) == 8 && class == VIDEO_DECODE_CLASS) {
+ reg.reg.reg += 4 * engine->instance; /* GEN8_M2TCR */
+ val = 0;
+ } else {
+ val = engine->instance;
+ }
+
+ val = BIT(val);
+
+ engine->tlb_inv.mcr = regs == xehp_regs;
+ engine->tlb_inv.reg = reg;
+ engine->tlb_inv.done = val;
+
+ if (GRAPHICS_VER(i915) >= 12 &&
+ (engine->class == VIDEO_DECODE_CLASS ||
+engine->class == VIDEO_ENHANCEMENT_CLASS ||
+
Re: [Intel-gfx] [RFC] drm/i915: make dev_priv usage explitic in some macros
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 dev_priv,
we need to make these macros explicitly use dev_priv, so that we can
change them later to be defined as i915.
In order to find and change all occurrences, the following semantic
patch rules were used:
Quite challenging task.
@macros_noargs@
identifier m;
expression e =~ "dev_priv";
@@
@nested_macros@
identifier macros_noargs.m;
identifier nm;
identifier list il;
@@
Out of curiosity, what is purpose of above stances? Matching sections
are empty.
@@
identifier nested_macros.nm;
identifier dev_priv, f;
expression list el;
@@
f(...) {
...
struct drm_i915_private *dev_priv = ...;
<+...
nm(
+ dev_priv,
el)
...+>
}
@@
identifier nested_macros.nm;
identifier dev_priv, f;
expression list el;
@@
f(..., struct drm_i915_private *dev_priv, ...) {
<+...
nm(
+ dev_priv,
el)
...+>
}
@@
identifier nested_macros.nm;
identifier list il;
expression e;
@@
-#define nm(il) e
+#define nm(dev_priv,il) e
Signed-off-by: Luca Coelho
---
drivers/gpu/drm/i915/display/intel_display.c | 34 ++-
.../drm/i915/display/intel_display_power.c| 2 +-
.../i915/display/intel_display_power_well.c | 22 +-
drivers/gpu/drm/i915/display/intel_dp_aux.c | 40 +--
drivers/gpu/drm/i915/display/intel_dpll.c | 57 ++--
drivers/gpu/drm/i915/display/intel_dvo.c | 6 +-
drivers/gpu/drm/i915/display/intel_pps.c | 2 +-
drivers/gpu/drm/i915/display/vlv_dsi.c| 266 +++---
drivers/gpu/drm/i915/display/vlv_dsi_pll.c| 6 +-
drivers/gpu/drm/i915/display/vlv_dsi_regs.h | 93 +++---
drivers/gpu/drm/i915/gvt/handlers.c | 22 +-
drivers/gpu/drm/i915/i915_reg.h | 26 +-
drivers/gpu/drm/i915/intel_gvt_mmio_table.c | 6 +-
13 files changed, 316 insertions(+), 266 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index e37cca6b18c6..f563d6dd3b4f 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -469,11 +469,11 @@ void vlv_wait_port_ready(struct drm_i915_private
*dev_priv,
fallthrough;
case PORT_B:
port_mask = DPLL_PORTB_READY_MASK;
- dpll_reg = DPLL(0);
+ dpll_reg = DPLL(dev_priv, 0);
break;
case PORT_C:
port_mask = DPLL_PORTC_READY_MASK;
- dpll_reg = DPLL(0);
+ dpll_reg = DPLL(dev_priv, 0);
expected_mask <<= 4;
break;
case PORT_D:
@@ -3248,14 +3248,16 @@ static bool i9xx_get_pipe_config(struct intel_crtc
*crtc,
if (IS_CHERRYVIEW(dev_priv) && crtc->pipe != PIPE_A)
tmp = dev_priv->display.state.chv_dpll_md[crtc->pipe];
else
- tmp = intel_de_read(dev_priv, DPLL_MD(crtc->pipe));
+ tmp = intel_de_read(dev_priv,
+ DPLL_MD(dev_priv, crtc->pipe));
pipe_config->pixel_multiplier =
((tmp & DPLL_MD_UDI_MULTIPLIER_MASK)
>> DPLL_MD_UDI_MULTIPLIER_SHIFT) + 1;
pipe_config->dpll_hw_state.dpll_md = tmp;
} else if (IS_I945G(dev_priv) || IS_I945GM(dev_priv) ||
IS_G33(dev_priv) || IS_PINEVIEW(dev_priv)) {
- tmp = intel_de_read(dev_priv, DPLL(crtc->pipe));
+ tmp = intel_de_read(dev_priv,
+ DPLL(dev_priv, crtc->pipe));
pipe_config->pixel_multiplier =
((tmp & SDVO_MULTIPLIER_MASK)
>> SDVO_MULTIPLIER_SHIFT_HIRES) + 1;
@@ -3266,7 +3268,7 @@ static bool i9xx_get_pipe_config(struct intel_crtc *crtc,
pipe_config->pixel_multiplier = 1;
}
pipe_config->dpll_hw_state.dpll = intel_de_read(dev_priv,
- DPLL(crtc->pipe));
+ DPLL(dev_priv,
crtc->pipe));
if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) {
pipe_config->dpll_hw_state.fp0 = intel_de_read(dev_priv,
FP0(crtc->pipe));
@@ -3973,7 +3975,8 @@ static bool bxt_get_dsi_transcoder_state(struct
intel_crtc *crtc,
if (!(tmp & DPI_ENABLE))
continue;
- tmp = intel_de_read(dev_priv, MIPI_CTRL(port));
+ tmp = intel_de_read(dev_priv,
+ MIPI_CTRL(dev_priv,
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 0/2] tests/i915/perf: Add stress / race exercises
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 to the > > one Chris added, I decided to reuse his code, then add my new subtest to > > perf > > as well. But maybe you are right that my subtest better fits to another > > test. > > not perf. I'll think this over. > > > > I hope this clarifies things for you. > > Thanks Janusz. Of course the test is valid but because it is not triggering > bugs in perf perhaps it is better added to a different IGT file. Maybe > gem_ctx_persistence? Maybe perf is also ok. Anyway something to think > about. I raised this point on today's IGT workroup meeting, asking for opinion. Since the new subtests depend on perf, we agreed that what needs to be done first is to provide an IGT library with perf helpers. As soon as it is available, other tests can use it if needed. Since I'm not familiar with perf, and I have other tasks in my queue, I've no time to spend on learning perf and working on that library. Then, for now I'll keep the new subtests inside the perf test. We can move them elsewhere at a later time, when the library is ready. Thanks, Janusz > > Thanks. > -- > Ashutosh >
Re: [Intel-gfx] linux-next: manual merge of the usb tree with the drm-intel-fixes tree
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 merge of the usb tree got a conflict in:
> > >>
> > >>drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > >>
> > >> between commit:
> > >>
> > >>5bc4b43d5c6c ("drm/i915: Fix up locking around dumping requests
> > >> lists")
> > >>
> > >> from the drm-intel-fixes tree and commit:
> > >>
> > >>4d70c74659d9 ("i915: Move list_count() to list.h as
> > >> list_count_nodes() for broader use")
> > >>
> > >> from the usb tree.
> > >>
> > >> I fixed it up (the former removed the code changed by the latter)
> > > Hmm... Currently I see that
> > > 20230127002842.3169194-4-john.c.harri...@intel.com
> > > moves the code to the
> > > drivers/gpu/drm/i915/gt/intel_execlists_submission.c.
> > >
> > > Is there any new series beside the above mentioned that touches that file
> > > and
> > > actually _removes_ that code?
> > As long as the removal is limited to list_count/list_count_nodes,
> > that's fine. I only moved it from one file to another because the one
> > and only function that was using it was being moved to the other
> > file. If someone else has found a use for the same and wants to move
> > it to a more common place then great. I assume there was no conflict
> > happening in the i915 specific code.
>
> I have added this fix up patch to linux-next today (more or less - this
> is a hand hacked version, but you get the idea):
>
> From: Stephen Rothwell
> Date: Wed, 1 Feb 2023 13:13:01 +1100
> Subject: [PATCH] i915: fix up for "drm/i915: Fix up locking around dumping
> requests lists"
>
> interacting with "i915: Move list_count() to list.h as list_count_nodes() for
> broader use"
>
> Signed-off-by: Stephen Rothwell
> ---
> .../gpu/drm/i915/gt/intel_execlists_submission.c| 15 +
> 1 file changed, 2 insertion(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> index 3c573d41d404..e919d41a48d9 100644
> --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> @@ -4150,17 +4150,6 @@ void intel_execlists_show_requests(struct
> intel_engine_cs *engine,
> spin_unlock_irqrestore(_engine->lock, flags);
> }
>
> -static unsigned long list_count(struct list_head *list)
> -{
> - struct list_head *pos;
> - unsigned long count = 0;
> -
> - list_for_each(pos, list)
> - count++;
> -
> - return count;
> -}
> -
> void intel_execlists_dump_active_requests(struct intel_engine_cs *engine,
> struct i915_request *hung_rq,
> struct drm_printer *m)
> @@ -4172,7 +4161,7 @@ void intel_execlists_dump_active_requests(struct
> intel_engine_cs *engine,
> intel_engine_dump_active_requests(>sched_engine->requests,
> hung_rq, m);
>
> - drm_printf(m, "\tOn hold?: %lu\n",
> -list_count(>sched_engine->hold));
> + drm_printf(m, "\tOn hold?: %zu\n",
> +list_count_nodes(>sched_engine->hold));
something awkward here.
The resolution on linux-next should align with the resolution on drm-tip
where we have the list_count still there as we preferred the version
on drm-intel-gt-next as the resolution of the conflict instead of the
fixes one.
>
> spin_unlock_irqrestore(>sched_engine->lock, flags);
> }
> --
> 2.35.1
>
> --
> Cheers,
> Stephen Rothwell
[Intel-gfx] [PATCH] drm/i915: add guard page to ggtt->error_capture
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.
Signed-off-by: Andrzej Hajda
---
This patch tries to diminish plague of DMAR errors present
in CI for ADL*, RPL*, DG2 platforms, see for example [1] (grep DMAR).
This is upstreamed internal patch, with slightly modified commit message.
[1]: http://gfx-ci.igk.intel.com/tree/drm-tip/CI_DRM_12678/bat-adln-1/dmesg0.txt
Regards
Andrzej
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 842e69c7b21e49..bdc1636375374a 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -503,6 +503,13 @@ static void cleanup_init_ggtt(struct i915_ggtt *ggtt)
mutex_destroy(>error_mutex);
}
+static void ggtt_insert_scratch_page(struct i915_ggtt *ggtt, u64 offset)
+{
+ struct i915_address_space *vm = >vm;
+
+ vm->insert_page(vm, px_dma(vm->scratch[0]), offset, I915_CACHE_NONE, 0);
+}
+
static int init_ggtt(struct i915_ggtt *ggtt)
{
/*
@@ -552,7 +559,7 @@ static int init_ggtt(struct i915_ggtt *ggtt)
* the only likely reason for failure to insert is a driver
* bug, which we expect to cause other failures...
*/
- ggtt->error_capture.size = I915_GTT_PAGE_SIZE;
+ ggtt->error_capture.size = 2 * I915_GTT_PAGE_SIZE;
ggtt->error_capture.color = I915_COLOR_UNEVICTABLE;
if (drm_mm_reserve_node(>vm.mm, >error_capture))
drm_mm_insert_node_in_range(>vm.mm,
@@ -562,11 +569,21 @@ static int init_ggtt(struct i915_ggtt *ggtt)
0, ggtt->mappable_end,
DRM_MM_INSERT_LOW);
}
- if (drm_mm_node_allocated(>error_capture))
+ if (drm_mm_node_allocated(>error_capture)) {
+ u64 start = ggtt->error_capture.start;
+ u64 end = ggtt->error_capture.start + ggtt->error_capture.size;
+ u64 i;
+
+ /*
+* During error capture, memcpying from the GGTT is triggering a
+* prefetch of the following PTE, so fill it with a guard page.
+*/
+ for (i = start + I915_GTT_PAGE_SIZE; i < end; i +=
I915_GTT_PAGE_SIZE)
+ ggtt_insert_scratch_page(ggtt, i);
drm_dbg(>vm.i915->drm,
"Reserved GGTT:[%llx, %llx] for use by error capture\n",
- ggtt->error_capture.start,
- ggtt->error_capture.start + ggtt->error_capture.size);
+ start, end);
+ }
/*
* The upper portion of the GuC address space has a sizeable hole
--
2.34.1
Re: [Intel-gfx] [PATCH v2 02/17] drm/display/dp_mst: Handle old/new payload states in drm_dp_remove_payload()
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 vc_start_slot of all payloads after the one being
> > removed.
> >
> > The above isn't always correct, as vc_start_slot must be the up-to-date
> > version contained in the new payload state, but time_slots must be the
> > one used when the payload was previously added, contained in the old
> > payload state. The new payload's time_slots can change vs. the old one
> > if the current atomic commit changes the corresponding mode.
> >
> > This patch let's drivers pass the old and new payload states to
> > drm_dp_remove_payload(), but keeps these the same for now in all drivers
> > not to change the behavior. A follow-up i915 patch will pass in that
> > driver the correct old and new states to the function.
>
> Oh wow, this was definitely a mistake on my part, thanks for catching this!
> TBH, I think this behavior is correct so (now that I actually have a setup
> capable of testing amdgpu's MST fully thanks to gitlab issue 2171…) if you'd
> like to change it on other drivers as well I can test it fully.
I only checked that the other drivers pass the new payload state to
drm_dp_remove_payload(), so not sure how that works atm if the same
commit has to both remove the payload (with the old time_slots value)
and add it back (with a new time_slots value). Maybe that can't happen
in those drivers, or time_slots get updated between remove and readd.
> Or feel free to leave it to me, shouldn't be too difficult I think :).
Yes, this patch should have no functional change, so please check what
would apply to other drivers as well.
Could you also check Ville's comment about storing start_slot elsewhere
than the atomic state (leaving only time_slots there). I wonder if that
would work, at least it would simplify things I think.
> For 0-2:
>
> Reviewed-by: Lyude Paul
Thanks.
>
> >
> > Cc: Lyude Paul
> > Cc: Ville Syrjälä
> > Cc: Ben Skeggs
> > Cc: Karol Herbst
> > Cc: Harry Wentland
> > Cc: Alex Deucher
> > Cc: Wayne Lin
> > Cc: sta...@vger.kernel.org # 6.1
> > Cc: dri-de...@lists.freedesktop.org
> > Reviewed-by: Ville Syrjälä
> > Signed-off-by: Imre Deak
> > ---
> > .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +-
> > drivers/gpu/drm/display/drm_dp_mst_topology.c | 26 ++-
> > drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 ++-
> > drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
> > include/drm/display/drm_dp_mst_helper.h | 3 ++-
> > 5 files changed, 21 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > index a50319fc42b11..180d3893b68da 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > @@ -208,7 +208,7 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
> > if (enable)
> > drm_dp_add_payload_part1(mst_mgr, mst_state, payload);
> > else
> > - drm_dp_remove_payload(mst_mgr, mst_state, payload);
> > + drm_dp_remove_payload(mst_mgr, mst_state, payload, payload);
> >
> > /* mst_mgr->->payloads are VC payload notify MST branch using DPCD or
> > * AUX message. The sequence is slot 1-63 allocated sequence for each
> > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > index 847c10aa2098c..1990ff5dc7ddd 100644
> > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > @@ -3342,7 +3342,8 @@ EXPORT_SYMBOL(drm_dp_add_payload_part1);
> > * drm_dp_remove_payload() - Remove an MST payload
> > * @mgr: Manager to use.
> > * @mst_state: The MST atomic state
> > - * @payload: The payload to write
> > + * @old_payload: The payload with its old state
> > + * @new_payload: The payload to write
> > *
> > * Removes a payload from an MST topology if it was successfully assigned
> > a start slot. Also updates
> > * the starting time slots of all other payloads which would have been
> > shifted towards the start of
> > @@ -3350,36 +3351,37 @@ EXPORT_SYMBOL(drm_dp_add_payload_part1);
> > */
> > void drm_dp_remove_payload(struct drm_dp_mst_topology_mgr *mgr,
> >struct drm_dp_mst_topology_state *mst_state,
> > - struct drm_dp_mst_atomic_payload *payload)
> > + const struct drm_dp_mst_atomic_payload *old_payload,
> > + struct drm_dp_mst_atomic_payload *new_payload)
> > {
> > struct drm_dp_mst_atomic_payload *pos;
> > bool send_remove = false;
> >
> > /* We failed to make the payload, so
Re: [Intel-gfx] [PATCH] vfio: fix deadlock between group lock and kvm lock
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 *file, struct kvm *kvm)
>>> {
>>> struct vfio_group *group = file->private_data;
>>> + unsigned long flags;
>>>
>>> if (!vfio_file_is_group(file))
>>> return;
>>>
>>> - mutex_lock(>group_lock);
>>> + spin_lock_irqsave(>kvm_ref_lock, flags);
>>> group->kvm = kvm;
>>> - mutex_unlock(>group_lock);
>>> + spin_unlock_irqrestore(>kvm_ref_lock, flags);
>>
>> We know we are in a sleeping context here so these are just
>> 'spin_lock()', same with the other one
>
> a dumb question. Why spinlock is required here?
>
You mean as opposed to another mutex? I don't think it's required per se (we
are replacing a mutex so we could have again used another mutex here), but all
current users of this new lock hold it over a very short window (e.g. set a
pointer as above, or refcount++ and copy the pointer as in the first
device_open)
Re: [Intel-gfx] [PATCH v2 16/17] drm/i915/dp_mst: Add workaround for a DELL P2715Q payload allocation problem
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 time slots (at position
> > 0x3e, 0x3f) in the hub's payload table, this VCPI can't be reused for
> > later payload configurations.
> >
> > The problem results at least in streams reusing older VCPIs to stay
> > blank on the screen and the payload table containing bogus VCPIs
> > (repeating the one earlier used to reserve the 0x3e, 0x3f slots) after
> > the last reservered slot.
>
> WOW. you know I've been trying for ages to figure out what is up with this
> exact monitor and I think I just gave up because it's the only monitor I've
> ever seen do this.
>
> (Also yes, I do have two of this exact monitor. I think we even have this
> model mentioned in our testcases. I looked up a google photo of it just to
> confirm. I think ours is the P2715Qb, but it looks identical and the problem
> you're describing sounds identical as well).
>
> This patch looks fine to me, we could probably also put this in the MST
> helpers as well if you can think of a way to do that and I can handle testing
> it on nouveau/amdgpu, but this is basically the only monitor I've ever seen do
> this - so I don't think it's a big deal either way.
Ok, it would be good if you could repro the same issue on your side.
I think the driver specific part is to detect the issue and force a full
modeset in the next commit. The MST core could then clear the payload
table internally, maybe based on some flag the driver passed.
Also the detection and forcing a full modeset as in this patch is probably
better done during the connector check phase of the next commit, which
could check the previous payload allocations, I'll check if that works.
> either way:
>
> Reviewed-by: Lyude Paul
Thanks.
> > To work around the problem detect this monitor and the condition for the
> > problem (when the last two slots get allocated in a commit), force a
> > full modeset of the MST topology in the subsequent commit and reset the
> > payload table during the latter commit after all payloads have been
> > freed.
> >
> > Cc: Ville Syrjälä
> > Cc: Lyude Paul
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/display/intel_atomic.c | 13 +++--
> > drivers/gpu/drm/i915/display/intel_atomic.h | 3 +-
> > .../drm/i915/display/intel_display_types.h| 1 +
> > drivers/gpu/drm/i915/display/intel_dp.c | 5 +-
> > drivers/gpu/drm/i915/display/intel_dp_mst.c | 48 +--
> > 5 files changed, 61 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> > b/drivers/gpu/drm/i915/display/intel_atomic.c
> > index 0f1c5b9c9a826..04e5f0e0fffa6 100644
> > --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> > +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> > @@ -616,7 +616,8 @@ intel_atomic_get_crtc_state(struct drm_atomic_state
> > *state,
> > }
> >
> > static int modeset_pipe(struct intel_atomic_state *state,
> > - struct intel_crtc *crtc, const char *reason)
> > + struct intel_crtc *crtc, const char *reason,
> > + bool allow_fastset)
> > {
> > struct drm_i915_private *i915 = to_i915(state->base.dev);
> > struct intel_crtc_state *crtc_state;
> > @@ -629,6 +630,8 @@ static int modeset_pipe(struct intel_atomic_state
> > *state,
> > return PTR_ERR(crtc_state);
> >
> > crtc_state->uapi.mode_changed = true;
> > + if (!allow_fastset)
> > + crtc_state->uapi.connectors_changed = true;
> > crtc_state->update_pipe = false;
> >
> > return intel_atomic_add_affected_planes(state, crtc);
> > @@ -639,6 +642,7 @@ static int modeset_pipe(struct intel_atomic_state
> > *state,
> > * @state: atomic state
> > * @connector: connector to add the state for
> > * @reason: the reason why the connector needs to be added
> > + * @allow_fastset: allow a fastset
> > *
> > * Add the @connector to the atomic state with its CRTC state and force a
> > modeset
> > * on the CRTC if any.
> > @@ -648,7 +652,8 @@ static int modeset_pipe(struct intel_atomic_state
> > *state,
> > * Returns 0 in case of success, a negative error code on failure.
> > */
> > int intel_atomic_modeset_connector(struct intel_atomic_state *state,
> > - struct intel_connector *connector, const
> > char *reason)
> > + struct intel_connector *connector, const
> > char *reason,
> > + bool allow_fastset)
> > {
> > struct drm_i915_private *i915 = to_i915(state->base.dev);
> > struct drm_connector_state *conn_state;
> > @@ -671,7 +676,7 @@ int intel_atomic_modeset_connector(struct
> > intel_atomic_state *state,
> > if (ret)
> >
Re: [Intel-gfx] [PATCH] vfio: fix deadlock between group lock and kvm lock
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
Re: [Intel-gfx] [PATCH] vfio: fix deadlock between group lock and kvm lock
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 the
>> + * open_count reaches 0. Save the pointer in the device for use by
>> + * drivers.
>> + */
>> +spin_lock_irqsave(>kvm_ref_lock, flags);
>> +if (group->kvm && vfio_kvm_get_kvm_safe(device, group->kvm))
>> +device->kvm = group->kvm;
>> +spin_unlock_irqrestore(>kvm_ref_lock, flags);
>> +
>
> No group reference in vfio_main.c.
OK -- I think to do that I'll have to move the lock/unlock of the dev_set lock
to group.c right before we call vfio_device_{open,close} and check open_count
there to make decisions about the kvm ref (before calling vfio_device_open to
decide to get kvm ref, after returning from vfio_device_open to see if we to
drop ref on error, after close to see if we need to drop ref).
>
> btw Yi, looks the deadlock issue also exists in your cdev work.
>
> kvm_vfio_release() holds kvm lock and then try to acquire
> device->device_set->lock in vfio_device_file_set_kvm().
>
> vfio_device_ioctl_bind_iommufd() holds device->device_set->lock
> and then call vfio_device_open() which finally hit kvm lock
> acquisition in driver's open_device routine (e.g. vfio-ap).
>
> A similar fix is required in your series.
>
> Thanks
> Kevin
Re: [Intel-gfx] [PATCH v2 17/17] drm/i915/dp_mst: Verify the HW state of MST encoders
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
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c | 91 +--
> > drivers/gpu/drm/i915/display/intel_display.c | 2 +-
> > .../drm/i915/display/intel_display_types.h| 18
> > drivers/gpu/drm/i915/display/intel_dp_mst.c | 68 +-
> > drivers/gpu/drm/i915/display/intel_dp_mst.h | 2 +-
> > .../drm/i915/display/intel_modeset_verify.c | 2 +-
> > drivers/gpu/drm/i915/i915_reg.h | 6 +-
> > 7 files changed, 173 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 254559abedfba..6acda4d357af3 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -661,13 +661,23 @@ int intel_ddi_toggle_hdcp_bits(struct intel_encoder
> > *intel_encoder,
> > return ret;
> > }
> >
> > +static enum transcoder get_transcoder_for_pipe(const struct intel_encoder
> > *encoder,
> > + enum pipe pipe)
> > +{
> > + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> > +
> > + if (HAS_TRANSCODER(i915, TRANSCODER_EDP) && encoder->port == PORT_A)
> > + return TRANSCODER_EDP;
> > + else
> > + return (enum transcoder) pipe;
> > +}
> > +
> > bool intel_ddi_connector_get_hw_state(struct intel_connector
> > *intel_connector)
> > {
> > struct drm_device *dev = intel_connector->base.dev;
> > struct drm_i915_private *dev_priv = to_i915(dev);
> > struct intel_encoder *encoder = intel_attached_encoder(intel_connector);
> > int type = intel_connector->base.connector_type;
> > - enum port port = encoder->port;
> > enum transcoder cpu_transcoder;
> > intel_wakeref_t wakeref;
> > enum pipe pipe = 0;
> > @@ -684,10 +694,7 @@ bool intel_ddi_connector_get_hw_state(struct
> > intel_connector *intel_connector)
> > goto out;
> > }
> >
> > - if (HAS_TRANSCODER(dev_priv, TRANSCODER_EDP) && port == PORT_A)
> > - cpu_transcoder = TRANSCODER_EDP;
> > - else
> > - cpu_transcoder = (enum transcoder) pipe;
> > + cpu_transcoder = get_transcoder_for_pipe(encoder, pipe);
> >
> > tmp = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder));
> >
> > @@ -2155,17 +2162,29 @@ i915_reg_t dp_tp_ctl_reg(struct intel_encoder
> > *encoder,
> > return DP_TP_CTL(encoder->port);
> > }
> >
> > -i915_reg_t dp_tp_status_reg(struct intel_encoder *encoder,
> > - const struct intel_crtc_state *crtc_state)
> > +static i915_reg_t __dp_tp_status_reg(struct intel_encoder *encoder,
> > +enum transcoder transcoder)
> > {
> > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> >
> > if (DISPLAY_VER(dev_priv) >= 12)
> > - return TGL_DP_TP_STATUS(tgl_dp_tp_transcoder(crtc_state));
> > + return TGL_DP_TP_STATUS(transcoder);
> > else
> > return DP_TP_STATUS(encoder->port);
> > }
> >
> > +i915_reg_t dp_tp_status_reg(struct intel_encoder *encoder,
> > + const struct intel_crtc_state *crtc_state)
> > +{
> > + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > + enum transcoder transcoder = INVALID_TRANSCODER;
> > +
> > + if (DISPLAY_VER(dev_priv) >= 12)
> > + transcoder = tgl_dp_tp_transcoder(crtc_state);
> > +
> > + return __dp_tp_status_reg(encoder, transcoder);
> > +}
> > +
> > static void intel_dp_sink_set_msa_timing_par_ignore_state(struct intel_dp
> > *intel_dp,
> > const struct
> > intel_crtc_state *crtc_state,
> > bool enable)
> > @@ -3500,6 +3519,61 @@ static void intel_ddi_get_config(struct
> > intel_encoder *encoder,
> > intel_audio_codec_get_config(encoder, pipe_config);
> > }
> >
> > +static bool intel_ddi_get_hw_mst_state(struct intel_encoder *encoder,
> > + struct intel_encoder_mst_state *state)
> > +{
> > + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> > + enum transcoder transcoder;
> > + u8 vc_pipe_mask = 0;
> > + u8 pipe_mask;
> > + bool is_mst;
> > + u32 dp_status;
> > + bool in_mst_mode;
> > + int vc;
> > +
> > + intel_ddi_get_encoder_pipes(encoder, _mask, _mst);
> > + if (!is_mst || !pipe_mask)
> > + return false;
> > +
> > + transcoder = get_transcoder_for_pipe(encoder, ffs(pipe_mask) - 1);
> > + dp_status = intel_de_read(i915, __dp_tp_status_reg(encoder,
> > transcoder));
> > +
> > + in_mst_mode =
Re: [Intel-gfx] [RFC] drm/i915: make dev_priv usage explitic in some macros
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 using either i915 or dev_priv,
> we need to make these macros explicitly use dev_priv, so that we can
> change them later to be defined as i915.
>
> In order to find and change all occurrences, the following semantic
> patch rules were used:
>
> @macros_noargs@
> identifier m;
> expression e =~ "dev_priv";
> @@
>
> @nested_macros@
> identifier macros_noargs.m;
> identifier nm;
> identifier list il;
> @@
>
> @@
> identifier nested_macros.nm;
> identifier dev_priv, f;
> expression list el;
> @@
> f(...) {
> ...
> struct drm_i915_private *dev_priv = ...;
>
> <+...
> nm(
> + dev_priv,
> el)
> ...+>
> }
>
> @@
> identifier nested_macros.nm;
> identifier dev_priv, f;
> expression list el;
> @@
> f(..., struct drm_i915_private *dev_priv, ...) {
> <+...
> nm(
> + dev_priv,
> el)
> ...+>
> }
>
> @@
> identifier nested_macros.nm;
> identifier list il;
> expression e;
> @@
> -#define nm(il) e
> +#define nm(dev_priv,il) e
>
> Signed-off-by: Luca Coelho
> ---
Running this rules require --recursive-includes as argument to cocci
and takes a looong time, so I had to run some rules and files
separately. Additionally, I had to use the latest git head of cocci
from github, where some bugs related to finding which files to include
were fixed.
This patch may still need some manual trimming. But before I spend
more time on this, I would like to know what you all thing about it, so
comments are very welcome.
If this is the right way to go, I can create more rules to change the
inner macros to also receive dev_priv as a parameter and, later, to
change all dev_priv's to i915. :)
--
Cheers,
Luca.
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: make dev_priv usage explitic in some macros
== 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 dev_priv usage explitic in some macros Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/display/intel_display.c M drivers/gpu/drm/i915/display/intel_display_power.c M drivers/gpu/drm/i915/display/intel_dvo.c M drivers/gpu/drm/i915/display/intel_pps.c M drivers/gpu/drm/i915/display/vlv_dsi.c M drivers/gpu/drm/i915/display/vlv_dsi_pll.c M drivers/gpu/drm/i915/i915_reg.h M drivers/gpu/drm/i915/intel_gvt_mmio_table.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/intel_gvt_mmio_table.c Auto-merging drivers/gpu/drm/i915/i915_reg.h Auto-merging drivers/gpu/drm/i915/display/vlv_dsi_pll.c Auto-merging drivers/gpu/drm/i915/display/vlv_dsi.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/display/vlv_dsi.c Auto-merging drivers/gpu/drm/i915/display/intel_pps.c Auto-merging drivers/gpu/drm/i915/display/intel_dvo.c Auto-merging drivers/gpu/drm/i915/display/intel_display_power.c Auto-merging drivers/gpu/drm/i915/display/intel_display.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 drm/i915: make dev_priv usage explitic in some macros When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort".
[Intel-gfx] [RFC] drm/i915: make dev_priv usage explitic in some macros
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 explicitly use dev_priv, so that we can
change them later to be defined as i915.
In order to find and change all occurrences, the following semantic
patch rules were used:
@macros_noargs@
identifier m;
expression e =~ "dev_priv";
@@
@nested_macros@
identifier macros_noargs.m;
identifier nm;
identifier list il;
@@
@@
identifier nested_macros.nm;
identifier dev_priv, f;
expression list el;
@@
f(...) {
...
struct drm_i915_private *dev_priv = ...;
<+...
nm(
+ dev_priv,
el)
...+>
}
@@
identifier nested_macros.nm;
identifier dev_priv, f;
expression list el;
@@
f(..., struct drm_i915_private *dev_priv, ...) {
<+...
nm(
+ dev_priv,
el)
...+>
}
@@
identifier nested_macros.nm;
identifier list il;
expression e;
@@
-#define nm(il) e
+#define nm(dev_priv,il) e
Signed-off-by: Luca Coelho
---
drivers/gpu/drm/i915/display/intel_display.c | 34 ++-
.../drm/i915/display/intel_display_power.c| 2 +-
.../i915/display/intel_display_power_well.c | 22 +-
drivers/gpu/drm/i915/display/intel_dp_aux.c | 40 +--
drivers/gpu/drm/i915/display/intel_dpll.c | 57 ++--
drivers/gpu/drm/i915/display/intel_dvo.c | 6 +-
drivers/gpu/drm/i915/display/intel_pps.c | 2 +-
drivers/gpu/drm/i915/display/vlv_dsi.c| 266 +++---
drivers/gpu/drm/i915/display/vlv_dsi_pll.c| 6 +-
drivers/gpu/drm/i915/display/vlv_dsi_regs.h | 93 +++---
drivers/gpu/drm/i915/gvt/handlers.c | 22 +-
drivers/gpu/drm/i915/i915_reg.h | 26 +-
drivers/gpu/drm/i915/intel_gvt_mmio_table.c | 6 +-
13 files changed, 316 insertions(+), 266 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index e37cca6b18c6..f563d6dd3b4f 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -469,11 +469,11 @@ void vlv_wait_port_ready(struct drm_i915_private
*dev_priv,
fallthrough;
case PORT_B:
port_mask = DPLL_PORTB_READY_MASK;
- dpll_reg = DPLL(0);
+ dpll_reg = DPLL(dev_priv, 0);
break;
case PORT_C:
port_mask = DPLL_PORTC_READY_MASK;
- dpll_reg = DPLL(0);
+ dpll_reg = DPLL(dev_priv, 0);
expected_mask <<= 4;
break;
case PORT_D:
@@ -3248,14 +3248,16 @@ static bool i9xx_get_pipe_config(struct intel_crtc
*crtc,
if (IS_CHERRYVIEW(dev_priv) && crtc->pipe != PIPE_A)
tmp = dev_priv->display.state.chv_dpll_md[crtc->pipe];
else
- tmp = intel_de_read(dev_priv, DPLL_MD(crtc->pipe));
+ tmp = intel_de_read(dev_priv,
+ DPLL_MD(dev_priv, crtc->pipe));
pipe_config->pixel_multiplier =
((tmp & DPLL_MD_UDI_MULTIPLIER_MASK)
>> DPLL_MD_UDI_MULTIPLIER_SHIFT) + 1;
pipe_config->dpll_hw_state.dpll_md = tmp;
} else if (IS_I945G(dev_priv) || IS_I945GM(dev_priv) ||
IS_G33(dev_priv) || IS_PINEVIEW(dev_priv)) {
- tmp = intel_de_read(dev_priv, DPLL(crtc->pipe));
+ tmp = intel_de_read(dev_priv,
+ DPLL(dev_priv, crtc->pipe));
pipe_config->pixel_multiplier =
((tmp & SDVO_MULTIPLIER_MASK)
>> SDVO_MULTIPLIER_SHIFT_HIRES) + 1;
@@ -3266,7 +3268,7 @@ static bool i9xx_get_pipe_config(struct intel_crtc *crtc,
pipe_config->pixel_multiplier = 1;
}
pipe_config->dpll_hw_state.dpll = intel_de_read(dev_priv,
- DPLL(crtc->pipe));
+ DPLL(dev_priv,
crtc->pipe));
if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) {
pipe_config->dpll_hw_state.fp0 = intel_de_read(dev_priv,
FP0(crtc->pipe));
@@ -3973,7 +3975,8 @@ static bool bxt_get_dsi_transcoder_state(struct
intel_crtc *crtc,
if (!(tmp & DPI_ENABLE))
continue;
- tmp = intel_de_read(dev_priv, MIPI_CTRL(port));
+ tmp = intel_de_read(dev_priv,
+ MIPI_CTRL(dev_priv, port));
if ((tmp & BXT_PIPE_SELECT_MASK) != BXT_PIPE_SELECT(crtc->pipe))
continue;
@@ -8786,11 +8789,12 @@ void
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Implement UHBR bandwidth check
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 16, 2023 at 01:19:37PM +0200, Stanislav Lisovskiy wrote:
> > > > > According to spec, we should check if output_bpp * pixel_rate is less
> > > > > than DDI clock * 72, if UHBR is used.
> > > > >
> > > > > HSDES: 1406899791
> > > > > BSPEC: 49259
> > > > >
> > > > > v2: - Removed wrong comment(Rodrigo Vivi)
> > > > > - Added HSDES to the commit msg(Rodrigo Vivi)
> > > > > - Moved UHBR check to the MST specific code
> > > > >
> > > > > v3: - Changed commit subject(Rodrigo Vivi)
> > > > > - Fixed the error message if check fails(Rodrigo Vivi)
> > > > >
> > > > > v4: - Move UHBR check to new helper function
> > > > > - Now both for non-DSC/DSC we use that new check as
> > > > > one of the constraints, when figuring out output bpp
> > > > > to be used(Ville Syrjälä)
> > > > >
> > > > > Signed-off-by: Stanislav Lisovskiy
> > > > > ---
> > > > > drivers/gpu/drm/i915/display/intel_dp_mst.c | 13 -
> > > > > 1 file changed, 12 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > > index e3e7c305fece..b95051fed23d 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > > @@ -47,8 +47,19 @@
> > > > >
> > > > > static int intel_dp_mst_check_constraints(struct drm_i915_private
> > > > > *i915, int bpp,
> > > > > const struct drm_display_mode
> > > > > *adjusted_mode,
> > > > > - struct intel_crtc_state
> > > > > *crtc_state)
> > > > > + struct intel_crtc_state
> > > > > *pipe_config)
> > > > > {
> > > > > + if (intel_dp_is_uhbr(pipe_config)) {
> > > > > + int output_bpp = bpp;
> > > > > +
> > > > > + if (output_bpp * adjusted_mode->crtc_clock >=
> > > > > + pipe_config->port_clock * 72) {
> > > >
> > > > This seems to be some DSC specific constraint, but this code appears to
> > > > apply it also to uncompresed output.
> > >
> > > Was thinking about that. Looking at the initial HSD, also to the DSC page
> > > in the BSpec, I have a strong feeling that this applies to any output bpp,
> > > regardless if its compressed or not.
> > > So decided to make this check more generic. I think this is a just general
> > > Link BW limitation which just happened to be mentioned on DSC page.
> > > I will clarify that.
> > >
> > > >
> > > > Also DDICLK != port_clock, so this looks to be off by quite a lot.
> > >
> > > Any hints, what should I use instead?..
> >
> > DDICLK looks to be the symbol clock more or less (for 32bit symbols),
> > so presumably you want a /32, with maybe an extra factor of 10^n in
> > there, or not.
> >
> > That magic 72 is also strange. Maybe a 2*36, but dunno what that would
> > really be either. The spec could really use some better explanations.
>
> There is another check mentioned right above in the same place, which
> I believe is related(btw, we probably need that one as well, if not added):
>
> Output bpp < Number of lanes * DDICLK frequency * Bits per lane / Pixel clock
>
> and bits per lane have to be:
>
> DisplayPort 8b/10b bits per lane = 8
> DisplayPort 2 128b/132b bits per lane = 32
>
> The check we are talking here is:
>
> Output bpp * Pixel clock < DDICLK frequency * 72 bits
>
> Which means
>
> Output bpp < (DDICLK frequency * 72 bits) / Pixel clock
>
> So I guess that means that to get DDICLK I need to divide port_clock by
> bits_per_lane.
>
> And 72 bits is a probably max symbol width which can be used due to some HW
> restrictions.
It would help if we knew what "DPT" was. It might be some max bits per
clock limit of the DSC encoder, or something. Looks like it's getting
doubled again in future projects.
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH] vfio: fix deadlock between group lock and kvm lock
> 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)
> > {
> > struct vfio_group *group = file->private_data;
> > + unsigned long flags;
> >
> > if (!vfio_file_is_group(file))
> > return;
> >
> > - mutex_lock(>group_lock);
> > + spin_lock_irqsave(>kvm_ref_lock, flags);
> > group->kvm = kvm;
> > - mutex_unlock(>group_lock);
> > + spin_unlock_irqrestore(>kvm_ref_lock, flags);
>
> We know we are in a sleeping context here so these are just
> 'spin_lock()', same with the other one
a dumb question. Why spinlock is required here?
Regards,
Yi Liu
Re: [Intel-gfx] [PATCH] vfio: fix deadlock between group lock and kvm lock
> 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 vfio group_lock when issuing device->ops->open_device but
> some
> drivers (like vfio-ap) need to acquire kvm->lock during their open_device
> routine; Meanwhile, kvm_vfio_release will acquire the kvm->lock first
> before calling vfio_file_set_kvm which will acquire the vfio group_lock.
>
> To resolve this, let's remove the need for the vfio group_lock from the
> kvm_vfio_release codepath. This is done by introducing a new spinlock to
> protect modifications to the vfio group kvm pointer, and acquiring a kvm
> ref from within vfio while holding this spinlock, with the reference held
> until the last close for the device in question.
>
> Fixes: 51cdc8bc120e ("kvm/vfio: Fix potential deadlock on vfio group_lock")
> Reported-by: Anthony Krowiak
> Suggested-by: Jason Gunthorpe
> Signed-off-by: Matthew Rosato
> ---
> drivers/vfio/group.c | 14 +++
> drivers/vfio/vfio.h | 5 ++-
> drivers/vfio/vfio_main.c | 88
>
> include/linux/vfio.h | 2 +-
> 4 files changed, 88 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c
> index bb24b2f0271e..8f67d33e0e8d 100644
> --- a/drivers/vfio/group.c
> +++ b/drivers/vfio/group.c
> @@ -164,13 +164,7 @@ static int vfio_device_group_open(struct
> vfio_device *device)
> goto out_unlock;
> }
>
> - /*
> - * Here we pass the KVM pointer with the group under the lock. If
> the
> - * device driver will use it, it must obtain a reference and release it
> - * during close_device.
> - */
> - ret = vfio_device_open(device, device->group->iommufd,
> -device->group->kvm);
> + ret = vfio_device_open(device, device->group);
>
> out_unlock:
> mutex_unlock(>group->group_lock);
> @@ -450,6 +444,7 @@ static struct vfio_group *vfio_group_alloc(struct
> iommu_group *iommu_group,
>
> refcount_set(>drivers, 1);
> mutex_init(>group_lock);
> + spin_lock_init(>kvm_ref_lock);
> INIT_LIST_HEAD(>device_list);
> mutex_init(>device_lock);
> group->iommu_group = iommu_group;
> @@ -799,13 +794,14 @@
> EXPORT_SYMBOL_GPL(vfio_file_enforced_coherent);
> void vfio_file_set_kvm(struct file *file, struct kvm *kvm)
> {
> struct vfio_group *group = file->private_data;
> + unsigned long flags;
>
> if (!vfio_file_is_group(file))
> return;
>
> - mutex_lock(>group_lock);
> + spin_lock_irqsave(>kvm_ref_lock, flags);
> group->kvm = kvm;
> - mutex_unlock(>group_lock);
> + spin_unlock_irqrestore(>kvm_ref_lock, flags);
> }
> EXPORT_SYMBOL_GPL(vfio_file_set_kvm);
>
> diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
> index f8219a438bfb..d153ad35de24 100644
> --- a/drivers/vfio/vfio.h
> +++ b/drivers/vfio/vfio.h
> @@ -15,11 +15,11 @@ struct iommufd_ctx;
> struct iommu_group;
> struct vfio_device;
> struct vfio_container;
> +struct vfio_group;
>
> void vfio_device_put_registration(struct vfio_device *device);
> bool vfio_device_try_get_registration(struct vfio_device *device);
> -int vfio_device_open(struct vfio_device *device,
> - struct iommufd_ctx *iommufd, struct kvm *kvm);
> +int vfio_device_open(struct vfio_device *device, struct vfio_group
> *group);
> void vfio_device_close(struct vfio_device *device,
> struct iommufd_ctx *iommufd);
>
> @@ -74,6 +74,7 @@ struct vfio_group {
> struct file *opened_file;
> struct blocking_notifier_head notifier;
> struct iommufd_ctx *iommufd;
> + spinlock_t kvm_ref_lock;
> };
>
> int vfio_device_set_group(struct vfio_device *device,
> diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
> index 5177bb061b17..b0defb0d0d87 100644
> --- a/drivers/vfio/vfio_main.c
> +++ b/drivers/vfio/vfio_main.c
> @@ -16,6 +16,9 @@
> #include
> #include
> #include
> +#ifdef CONFIG_HAVE_KVM
> +#include
> +#endif
> #include
> #include
> #include
> @@ -344,9 +347,59 @@ static bool vfio_assert_device_open(struct
> vfio_device *device)
> return !WARN_ON_ONCE(!READ_ONCE(device->open_count));
> }
>
> +#ifdef CONFIG_HAVE_KVM
> +static bool vfio_kvm_get_kvm_safe(struct vfio_device *device, struct kvm
> *kvm)
> +{
> + void (*pfn)(struct kvm *kvm);
> + bool (*fn)(struct kvm *kvm);
> + bool ret;
> +
> + pfn = symbol_get(kvm_put_kvm);
> + if (WARN_ON(!pfn))
> + return false;
> +
> + fn = symbol_get(kvm_get_kvm_safe);
> + if (WARN_ON(!fn)) {
> + symbol_put(kvm_put_kvm);
> + return false;
> + }
> +
> + ret =
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Move common mmio base out of private macros
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 implicit dev_priv, making it easier > > to remove it later. > > > > Signed-off-by: Lucas De Marchi > > --- > > drivers/gpu/drm/i915/i915_reg.h | 73 ++--- > > 1 file changed, 39 insertions(+), 34 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h > > b/drivers/gpu/drm/i915/i915_reg.h > > index 943db8ec63f8..1cde3bcb9c88 100644 > > --- a/drivers/gpu/drm/i915/i915_reg.h > > +++ b/drivers/gpu/drm/i915/i915_reg.h > > @@ -1182,9 +1182,9 @@ > > #define PM_VEBOX_CS_ERROR_INTERRUPT(1 << 12) /* hsw+ */ > > #define PM_VEBOX_USER_INTERRUPT(1 << 10) /* hsw+ */ > > > > -#define GT_PARITY_ERROR(dev_priv) \ > > +#define GT_PARITY_ERROR(__i915) \ > > (GT_RENDER_L3_PARITY_ERROR_INTERRUPT | \ > > -(IS_HASWELL(dev_priv) ? GT_RENDER_L3_PARITY_ERROR_INTERRUPT_S1 : 0)) > > +(IS_HASWELL(__i915) ? GT_RENDER_L3_PARITY_ERROR_INTERRUPT_S1 : 0)) > > Unrelated change. > > > > > /* These are all the "old" interrupts */ > > #define ILK_BSD_USER_INTERRUPT (1 << 5) > > @@ -1403,10 +1403,11 @@ > > /* > > * Clock control & power management > > */ > > -#define _DPLL_A (DISPLAY_MMIO_BASE(dev_priv) + 0x6014) > > -#define _DPLL_B (DISPLAY_MMIO_BASE(dev_priv) + 0x6018) > > -#define _CHV_DPLL_C (DISPLAY_MMIO_BASE(dev_priv) + 0x6030) > > -#define DPLL(pipe) _MMIO_PIPE3((pipe), _DPLL_A, _DPLL_B, _CHV_DPLL_C) > > +#define _DPLL_A0x6014 > > +#define _DPLL_B0x6018 > > +#define _CHV_DPLL_C0x6030 > > +#define DPLL(pipe) _MMIO(DISPLAY_MMIO_BASE(dev_priv) + \ > > +_PIPE3((pipe), _DPLL_A, _DPLL_B, _CHV_DPLL_C)) > > > > #define VGA0 _MMIO(0x6000) > > #define VGA1 _MMIO(0x6004) > > @@ -1502,10 +1503,11 @@ > > #define SDVO_MULTIPLIER_SHIFT_HIRES 4 > > #define SDVO_MULTIPLIER_SHIFT_VGA0 > > > > -#define _DPLL_A_MD (DISPLAY_MMIO_BASE(dev_priv) + 0x601c) > > -#define _DPLL_B_MD (DISPLAY_MMIO_BASE(dev_priv) + 0x6020) > > -#define _CHV_DPLL_C_MD (DISPLAY_MMIO_BASE(dev_priv) + 0x603c) > > -#define DPLL_MD(pipe) _MMIO_PIPE3((pipe), _DPLL_A_MD, _DPLL_B_MD, > > _CHV_DPLL_C_MD) > > +#define _DPLL_A_MD 0x601c > > +#define _DPLL_B_MD 0x6020 > > +#define _CHV_DPLL_C_MD 0x603c > > +#define DPLL_MD(pipe) _MMIO(DISPLAY_MMIO_BASE(dev_priv) + \ > > + _PIPE3((pipe), _DPLL_A_MD, _DPLL_B_MD, > > _CHV_DPLL_C_MD)) > > > > /* > > * UDI pixel divider, controlling how many pixels are stuffed into a > > packet. > > @@ -3323,42 +3325,45 @@ > > * is 20 bytes in each direction, hence the 5 fixed > > * data registers > > */ > > -#define _DPA_AUX_CH_CTL(DISPLAY_MMIO_BASE(dev_priv) + 0x64010) > > -#define _DPA_AUX_CH_DATA1 (DISPLAY_MMIO_BASE(dev_priv) + 0x64014) > > - > > -#define _DPB_AUX_CH_CTL(DISPLAY_MMIO_BASE(dev_priv) + 0x64110) > > -#define _DPB_AUX_CH_DATA1 (DISPLAY_MMIO_BASE(dev_priv) + 0x64114) > > - > > -#define DP_AUX_CH_CTL(aux_ch) _MMIO_PORT(aux_ch, _DPA_AUX_CH_CTL, > > _DPB_AUX_CH_CTL) > > -#define DP_AUX_CH_DATA(aux_ch, i) _MMIO(_PORT(aux_ch, _DPA_AUX_CH_DATA1, > > _DPB_AUX_CH_DATA1) + (i) * 4) /* 5 registers */ > > +#define _DPA_AUX_CH_CTL0x64010 > > +#define _DPA_AUX_CH_DATA1 0x64014 > > +#define _DPB_AUX_CH_CTL0x64110 > > +#define _DPB_AUX_CH_DATA1 0x64114 > > +#define DP_AUX_CH_CTL(aux_ch) _MMIO(DISPLAY_MMIO_BASE(dev_priv) + \ > > + _PORT(aux_ch, _DPA_AUX_CH_CTL, > > _DPB_AUX_CH_CTL)) > > +#define DP_AUX_CH_DATA(aux_ch, i) \ > > + _MMIO(DISPLAY_MMIO_BASE(dev_priv) + \ > > + _PORT(aux_ch, _DPA_AUX_CH_DATA1, _DPB_AUX_CH_DATA1) + (i) * 4) /* > > 5 registers */ > > > > #define _XELPDP_USBC1_AUX_CH_CTL 0x16F210 > > #define _XELPDP_USBC2_AUX_CH_CTL 0x16F410 > > #define _XELPDP_USBC3_AUX_CH_CTL 0x16F610 > > #define _XELPDP_USBC4_AUX_CH_CTL 0x16F810 > > > > -#define XELPDP_DP_AUX_CH_CTL(aux_ch) _MMIO(_PICK(aux_ch, \ > > - _DPA_AUX_CH_CTL, \ > > - _DPB_AUX_CH_CTL, \ > > - 0, /* port/aux_ch C is > > non-existent */ \ > > - > > _XELPDP_USBC1_AUX_CH_CTL, \ > > - > > _XELPDP_USBC2_AUX_CH_CTL, \ > > - > > _XELPDP_USBC3_AUX_CH_CTL, \ > > - > >
[Intel-gfx] [PULL] drm-intel-gt-next
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 the whole of the GT in the previous pull. Some minor random future platform prep as well, and a back merge to fix a conflict between drm-intel-next and drm-intel-gt-next. Regards, Tvrtko drm-intel-gt-next-2023-02-01: Driver Changes: Fixes/improvements/new stuff: - Fix bcs default context on Meteorlake (Lucas De Marchi) - GAM registers don't need to be re-applied on engine resets (Matt Roper) - Correct implementation of Wa_18018781329 (Matt Roper) - Avoid potential vm use-after-free (Rob Clark) - GuC error capture fixes (John Harrison) - Fix potential bit_17 double-free (Rob Clark) - Don't complain about missing regs on MTL (John Harrison) Future platform enablement: - Convert PSS_MODE2 to multicast register (Gustavo Sousa) - Move/adjust register definitions related to Wa_22011450934 (Matt Roper) - Move LSC_CHICKEN_BIT* workarounds to correct function (Gustavo Sousa) - Document where to implement register workarounds (Gustavo Sousa) - Use uabi engines for the default engine map (Tvrtko Ursulin) - Flush all tiles on test exit (Tvrtko Ursulin) - Annotate a couple more workaround registers as MCR (Matt Roper) Driver refactors: - Add and use GuC oriented print macros (Michal Wajdeczko) Miscellaneous: - Fix intel_selftest_modify_policy argument types (Arnd Bergmann) Backmerges: Merge drm/drm-next into drm-intel-gt-next (for conflict resolution) (Tvrtko Ursulin) The following changes since commit 045e8d102f44ad75dca0b0ec9eede15ea89da673: Merge tag 'drm-intel-gt-next-2023-01-18' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2023-01-24 16:20:43 +0100) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-gt-next-2023-02-01 for you to fetch changes up to 003e11ed2ef4af01b808f0f193eaa5a32f32383b: drm/i915/mtl: Wa_22011802037: don't complain about missing regs on MTL (2023-01-31 15:17:30 -0800) Driver Changes: Fixes/improvements/new stuff: - Fix bcs default context on Meteorlake (Lucas De Marchi) - GAM registers don't need to be re-applied on engine resets (Matt Roper) - Correct implementation of Wa_18018781329 (Matt Roper) - Avoid potential vm use-after-free (Rob Clark) - GuC error capture fixes (John Harrison) - Fix potential bit_17 double-free (Rob Clark) - Don't complain about missing regs on MTL (John Harrison) Future platform enablement: - Convert PSS_MODE2 to multicast register (Gustavo Sousa) - Move/adjust register definitions related to Wa_22011450934 (Matt Roper) - Move LSC_CHICKEN_BIT* workarounds to correct function (Gustavo Sousa) - Document where to implement register workarounds (Gustavo Sousa) - Use uabi engines for the default engine map (Tvrtko Ursulin) - Flush all tiles on test exit (Tvrtko Ursulin) - Annotate a couple more workaround registers as MCR (Matt Roper) Driver refactors: - Add and use GuC oriented print macros (Michal Wajdeczko) Miscellaneous: - Fix intel_selftest_modify_policy argument types (Arnd Bergmann) Backmerges: Merge drm/drm-next into drm-intel-gt-next (for conflict resolution) (Tvrtko Ursulin) Arnd Bergmann (1): drm/i915/selftest: fix intel_selftest_modify_policy argument types Gustavo Sousa (3): drm/i915/doc: Document where to implement register workarounds drm/i915/gt: Move LSC_CHICKEN_BIT* workarounds to correct function drm/i915/gt: Convert PSS_MODE2 to multicast register John Harrison (9): drm/i915/guc: Fix locking when searching for a hung request drm/i915: Fix request ref counting during error capture & debugfs dump drm/i915: Fix up locking around dumping requests lists drm/i915: Allow error capture without a request drm/i915: Allow error capture of a pending request drm/i915/guc: Look for a guilty context when an engine reset fails drm/i915/guc: Add a debug print on GuC triggered reset drm/i915/guc: Rename GuC register state capture node to be more obvious drm/i915/mtl: Wa_22011802037: don't complain about missing regs on MTL Lucas De Marchi (1): drm/i915/mtl: Fix bcs default context Matt Roper (4): drm/i915: Move/adjust register definitions related to Wa_22011450934 drm/i915/xehp: GAM registers don't need to be re-applied on engine resets drm/i915/mtl: Correct implementation of Wa_18018781329 drm/i915/xehp: Annotate a couple more workaround registers as MCR Michal Wajdeczko (8): drm/i915/guc: Add GuC oriented print macros drm/i915/guc: Update GuC messages in intel_guc.c drm/i915/guc: Update GuC messages in
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Implement UHBR bandwidth check
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 spec, we should check if output_bpp * pixel_rate is less
> > > > than DDI clock * 72, if UHBR is used.
> > > >
> > > > HSDES: 1406899791
> > > > BSPEC: 49259
> > > >
> > > > v2: - Removed wrong comment(Rodrigo Vivi)
> > > > - Added HSDES to the commit msg(Rodrigo Vivi)
> > > > - Moved UHBR check to the MST specific code
> > > >
> > > > v3: - Changed commit subject(Rodrigo Vivi)
> > > > - Fixed the error message if check fails(Rodrigo Vivi)
> > > >
> > > > v4: - Move UHBR check to new helper function
> > > > - Now both for non-DSC/DSC we use that new check as
> > > > one of the constraints, when figuring out output bpp
> > > > to be used(Ville Syrjälä)
> > > >
> > > > Signed-off-by: Stanislav Lisovskiy
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_dp_mst.c | 13 -
> > > > 1 file changed, 12 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > index e3e7c305fece..b95051fed23d 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > @@ -47,8 +47,19 @@
> > > >
> > > > static int intel_dp_mst_check_constraints(struct drm_i915_private
> > > > *i915, int bpp,
> > > > const struct drm_display_mode
> > > > *adjusted_mode,
> > > > - struct intel_crtc_state
> > > > *crtc_state)
> > > > + struct intel_crtc_state
> > > > *pipe_config)
> > > > {
> > > > + if (intel_dp_is_uhbr(pipe_config)) {
> > > > + int output_bpp = bpp;
> > > > +
> > > > + if (output_bpp * adjusted_mode->crtc_clock >=
> > > > + pipe_config->port_clock * 72) {
> > >
> > > This seems to be some DSC specific constraint, but this code appears to
> > > apply it also to uncompresed output.
> >
> > Was thinking about that. Looking at the initial HSD, also to the DSC page
> > in the BSpec, I have a strong feeling that this applies to any output bpp,
> > regardless if its compressed or not.
> > So decided to make this check more generic. I think this is a just general
> > Link BW limitation which just happened to be mentioned on DSC page.
> > I will clarify that.
> >
> > >
> > > Also DDICLK != port_clock, so this looks to be off by quite a lot.
> >
> > Any hints, what should I use instead?..
>
> DDICLK looks to be the symbol clock more or less (for 32bit symbols),
> so presumably you want a /32, with maybe an extra factor of 10^n in
> there, or not.
>
> That magic 72 is also strange. Maybe a 2*36, but dunno what that would
> really be either. The spec could really use some better explanations.
There is another check mentioned right above in the same place, which
I believe is related(btw, we probably need that one as well, if not added):
Output bpp < Number of lanes * DDICLK frequency * Bits per lane / Pixel clock
and bits per lane have to be:
DisplayPort 8b/10b bits per lane = 8
DisplayPort 2 128b/132b bits per lane = 32
The check we are talking here is:
Output bpp * Pixel clock < DDICLK frequency * 72 bits
Which means
Output bpp < (DDICLK frequency * 72 bits) / Pixel clock
So I guess that means that to get DDICLK I need to divide port_clock by
bits_per_lane.
And 72 bits is a probably max symbol width which can be used due to some HW
restrictions.
Stan
>
> --
> Ville Syrjälä
> Intel
[Intel-gfx] ✓ Fi.CI.IGT: success for Enable HDCP2.x via GSC CS (rev10)
== 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
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v10/index.html
Participating hosts (10 -> 11)
--
Additional (1): shard-rkl0
Known issues
Here are the changes found in Patchwork_111876v10_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][1] -> [FAIL][2] ([i915#2842])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12676/shard-glk3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v10/shard-glk2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions-varying-size:
- shard-glk: [PASS][3] -> [FAIL][4] ([i915#2346])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12676/shard-glk1/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v10/shard-glk1/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html
* igt@kms_flip@2x-flip-vs-expired-vblank@ac-hdmi-a1-hdmi-a2:
- shard-glk: [PASS][5] -> [FAIL][6] ([i915#79]) +1 similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12676/shard-glk8/igt@kms_flip@2x-flip-vs-expired-vbl...@ac-hdmi-a1-hdmi-a2.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v10/shard-glk3/igt@kms_flip@2x-flip-vs-expired-vbl...@ac-hdmi-a1-hdmi-a2.html
Possible fixes
* igt@drm_fdinfo@idle@rcs0:
- {shard-rkl}:[FAIL][7] ([i915#7742]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12676/shard-rkl-4/igt@drm_fdinfo@i...@rcs0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v10/shard-rkl-5/igt@drm_fdinfo@i...@rcs0.html
* igt@fbdev@read:
- {shard-rkl}:[SKIP][9] ([i915#2582]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12676/shard-rkl-3/igt@fb...@read.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v10/shard-rkl-6/igt@fb...@read.html
* igt@gem_eio@in-flight-suspend:
- {shard-rkl}:[FAIL][11] ([fdo#103375]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12676/shard-rkl-4/igt@gem_...@in-flight-suspend.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v10/shard-rkl-2/igt@gem_...@in-flight-suspend.html
* igt@gem_exec_fair@basic-none@vcs0:
- {shard-rkl}:[FAIL][13] ([i915#2842]) -> [PASS][14] +2 similar
issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12676/shard-rkl-6/igt@gem_exec_fair@basic-n...@vcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v10/shard-rkl-5/igt@gem_exec_fair@basic-n...@vcs0.html
* igt@gem_exec_reloc@basic-write-read-noreloc:
- {shard-rkl}:[SKIP][15] ([i915#3281]) -> [PASS][16] +10 similar
issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12676/shard-rkl-6/igt@gem_exec_re...@basic-write-read-noreloc.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v10/shard-rkl-5/igt@gem_exec_re...@basic-write-read-noreloc.html
* igt@gem_pread@bench:
- {shard-rkl}:[SKIP][17] ([i915#3282]) -> [PASS][18] +4 similar
issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12676/shard-rkl-2/igt@gem_pr...@bench.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v10/shard-rkl-5/igt@gem_pr...@bench.html
* igt@gen9_exec_parse@bb-start-out:
- {shard-rkl}:[SKIP][19] ([i915#2527]) -> [PASS][20] +2 similar
issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12676/shard-rkl-6/igt@gen9_exec_pa...@bb-start-out.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v10/shard-rkl-5/igt@gen9_exec_pa...@bb-start-out.html
* igt@i915_hangman@gt-engine-error@bcs0:
- {shard-rkl}:[SKIP][21] ([i915#6258]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12676/shard-rkl-5/igt@i915_hangman@gt-engine-er...@bcs0.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v10/shard-rkl-6/igt@i915_hangman@gt-engine-er...@bcs0.html
* igt@kms_atomic@atomic_plane_damage:
- {shard-rkl}:[SKIP][23] ([i915#4098]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12676/shard-rkl-3/igt@kms_atomic@atomic_plane_damage.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v10/shard-rkl-6/igt@kms_atomic@atomic_plane_damage.html
*
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Move common mmio base out of private macros
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. > > Signed-off-by: Lucas De Marchi > --- > drivers/gpu/drm/i915/i915_reg.h | 73 ++--- > 1 file changed, 39 insertions(+), 34 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h > index 943db8ec63f8..1cde3bcb9c88 100644 > --- a/drivers/gpu/drm/i915/i915_reg.h > +++ b/drivers/gpu/drm/i915/i915_reg.h > @@ -1182,9 +1182,9 @@ > #define PM_VEBOX_CS_ERROR_INTERRUPT (1 << 12) /* hsw+ */ > #define PM_VEBOX_USER_INTERRUPT (1 << 10) /* hsw+ */ > > -#define GT_PARITY_ERROR(dev_priv) \ > +#define GT_PARITY_ERROR(__i915) \ > (GT_RENDER_L3_PARITY_ERROR_INTERRUPT | \ > - (IS_HASWELL(dev_priv) ? GT_RENDER_L3_PARITY_ERROR_INTERRUPT_S1 : 0)) > + (IS_HASWELL(__i915) ? GT_RENDER_L3_PARITY_ERROR_INTERRUPT_S1 : 0)) Unrelated change. > > /* These are all the "old" interrupts */ > #define ILK_BSD_USER_INTERRUPT (1 << 5) > @@ -1403,10 +1403,11 @@ > /* > * Clock control & power management > */ > -#define _DPLL_A (DISPLAY_MMIO_BASE(dev_priv) + 0x6014) > -#define _DPLL_B (DISPLAY_MMIO_BASE(dev_priv) + 0x6018) > -#define _CHV_DPLL_C (DISPLAY_MMIO_BASE(dev_priv) + 0x6030) > -#define DPLL(pipe) _MMIO_PIPE3((pipe), _DPLL_A, _DPLL_B, _CHV_DPLL_C) > +#define _DPLL_A 0x6014 > +#define _DPLL_B 0x6018 > +#define _CHV_DPLL_C 0x6030 > +#define DPLL(pipe) _MMIO(DISPLAY_MMIO_BASE(dev_priv) + \ > + _PIPE3((pipe), _DPLL_A, _DPLL_B, _CHV_DPLL_C)) > > #define VGA0 _MMIO(0x6000) > #define VGA1 _MMIO(0x6004) > @@ -1502,10 +1503,11 @@ > #define SDVO_MULTIPLIER_SHIFT_HIRES4 > #define SDVO_MULTIPLIER_SHIFT_VGA 0 > > -#define _DPLL_A_MD (DISPLAY_MMIO_BASE(dev_priv) + 0x601c) > -#define _DPLL_B_MD (DISPLAY_MMIO_BASE(dev_priv) + 0x6020) > -#define _CHV_DPLL_C_MD (DISPLAY_MMIO_BASE(dev_priv) + 0x603c) > -#define DPLL_MD(pipe) _MMIO_PIPE3((pipe), _DPLL_A_MD, _DPLL_B_MD, > _CHV_DPLL_C_MD) > +#define _DPLL_A_MD 0x601c > +#define _DPLL_B_MD 0x6020 > +#define _CHV_DPLL_C_MD 0x603c > +#define DPLL_MD(pipe) _MMIO(DISPLAY_MMIO_BASE(dev_priv) + \ > + _PIPE3((pipe), _DPLL_A_MD, _DPLL_B_MD, > _CHV_DPLL_C_MD)) > > /* > * UDI pixel divider, controlling how many pixels are stuffed into a packet. > @@ -3323,42 +3325,45 @@ > * is 20 bytes in each direction, hence the 5 fixed > * data registers > */ > -#define _DPA_AUX_CH_CTL (DISPLAY_MMIO_BASE(dev_priv) + 0x64010) > -#define _DPA_AUX_CH_DATA1(DISPLAY_MMIO_BASE(dev_priv) + 0x64014) > - > -#define _DPB_AUX_CH_CTL (DISPLAY_MMIO_BASE(dev_priv) + 0x64110) > -#define _DPB_AUX_CH_DATA1(DISPLAY_MMIO_BASE(dev_priv) + 0x64114) > - > -#define DP_AUX_CH_CTL(aux_ch)_MMIO_PORT(aux_ch, _DPA_AUX_CH_CTL, > _DPB_AUX_CH_CTL) > -#define DP_AUX_CH_DATA(aux_ch, i)_MMIO(_PORT(aux_ch, _DPA_AUX_CH_DATA1, > _DPB_AUX_CH_DATA1) + (i) * 4) /* 5 registers */ > +#define _DPA_AUX_CH_CTL 0x64010 > +#define _DPA_AUX_CH_DATA10x64014 > +#define _DPB_AUX_CH_CTL 0x64110 > +#define _DPB_AUX_CH_DATA10x64114 > +#define DP_AUX_CH_CTL(aux_ch)_MMIO(DISPLAY_MMIO_BASE(dev_priv) + \ > + _PORT(aux_ch, _DPA_AUX_CH_CTL, > _DPB_AUX_CH_CTL)) > +#define DP_AUX_CH_DATA(aux_ch, i)\ > + _MMIO(DISPLAY_MMIO_BASE(dev_priv) + \ > + _PORT(aux_ch, _DPA_AUX_CH_DATA1, _DPB_AUX_CH_DATA1) + (i) * 4) /* > 5 registers */ > > #define _XELPDP_USBC1_AUX_CH_CTL 0x16F210 > #define _XELPDP_USBC2_AUX_CH_CTL 0x16F410 > #define _XELPDP_USBC3_AUX_CH_CTL 0x16F610 > #define _XELPDP_USBC4_AUX_CH_CTL 0x16F810 > > -#define XELPDP_DP_AUX_CH_CTL(aux_ch) _MMIO(_PICK(aux_ch, \ > -_DPA_AUX_CH_CTL, \ > -_DPB_AUX_CH_CTL, \ > -0, /* port/aux_ch C is > non-existent */ \ > - > _XELPDP_USBC1_AUX_CH_CTL, \ > - > _XELPDP_USBC2_AUX_CH_CTL, \ > - > _XELPDP_USBC3_AUX_CH_CTL, \ > - > _XELPDP_USBC4_AUX_CH_CTL)) > +#define XELPDP_DP_AUX_CH_CTL(aux_ch) > _MMIO(DISPLAY_MMIO_BASE(dev_priv) + \ Note that only VLV and CHV have DISPLAY_MMIO_BASE() != 0. This is an XELPDP specific macro. Just drop the DISPLAY_MMIO_BASE() part altogether,
[Intel-gfx] ✓ Fi.CI.BAT: success for Enable HDCP2.x via GSC CS (rev10)
== 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
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v10/index.html
Participating hosts (27 -> 25)
--
Missing(2): fi-kbl-soraka fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_111876v10:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@slpc:
- {bat-rpls-1}: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12676/bat-rpls-1/igt@i915_selftest@l...@slpc.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v10/bat-rpls-1/igt@i915_selftest@l...@slpc.html
Known issues
Here are the changes found in Patchwork_111876v10 that come from known issues:
### IGT changes ###
Possible fixes
* igt@fbdev@write:
- fi-blb-e6850: [SKIP][3] ([fdo#109271]) -> [PASS][4] +4 similar
issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12676/fi-blb-e6850/igt@fb...@write.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v10/fi-blb-e6850/igt@fb...@write.html
* igt@i915_selftest@live@hangcheck:
- {bat-dg2-11}: [ABORT][5] ([i915#7913]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12676/bat-dg2-11/igt@i915_selftest@l...@hangcheck.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v10/bat-dg2-11/igt@i915_selftest@l...@hangcheck.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#6311]: https://gitlab.freedesktop.org/drm/intel/issues/6311
[i915#7359]: https://gitlab.freedesktop.org/drm/intel/issues/7359
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
[i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
[i915#7982]: https://gitlab.freedesktop.org/drm/intel/issues/7982
Build changes
-
* Linux: CI_DRM_12676 -> Patchwork_111876v10
CI-20190529: 20190529
CI_DRM_12676: 3775348312c45a69754d1ed47103a2c62ae18485 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7143: c7b12dcc460fc2348e1fa7f4dcb791bb82e29e44 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_111876v10: 3775348312c45a69754d1ed47103a2c62ae18485 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
e7a84aca705e drm/i915/mtl: Add HDCP GSC interface
044a2e6438f8 drm/i915/mtl: Add function to send command to GSC CS
2a6665aee54e drm/i915/hdcp: Refactor HDCP API structures
aefa0410d94a i915/hdcp: HDCP2.x Refactoring to agnostic hdcp
fbc70f8e71cd drm/i915/hdcp: Keep hdcp agonstic naming convention
8cd66e2b28b7 drm/i915/gsc: Create GSC request submission mechanism
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v10/index.html
Re: [Intel-gfx] [PATCH v2 17/17] drm/i915/dp_mst: Verify the HW state of MST encoders
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 +--
> drivers/gpu/drm/i915/display/intel_display.c | 2 +-
> .../drm/i915/display/intel_display_types.h| 18
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 68 +-
> drivers/gpu/drm/i915/display/intel_dp_mst.h | 2 +-
> .../drm/i915/display/intel_modeset_verify.c | 2 +-
> drivers/gpu/drm/i915/i915_reg.h | 6 +-
> 7 files changed, 173 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 254559abedfba..6acda4d357af3 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -661,13 +661,23 @@ int intel_ddi_toggle_hdcp_bits(struct intel_encoder
> *intel_encoder,
> return ret;
> }
>
> +static enum transcoder get_transcoder_for_pipe(const struct intel_encoder
> *encoder,
> +enum pipe pipe)
> +{
> + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> +
> + if (HAS_TRANSCODER(i915, TRANSCODER_EDP) && encoder->port == PORT_A)
> + return TRANSCODER_EDP;
> + else
> + return (enum transcoder) pipe;
> +}
> +
> bool intel_ddi_connector_get_hw_state(struct intel_connector
> *intel_connector)
> {
> struct drm_device *dev = intel_connector->base.dev;
> struct drm_i915_private *dev_priv = to_i915(dev);
> struct intel_encoder *encoder = intel_attached_encoder(intel_connector);
> int type = intel_connector->base.connector_type;
> - enum port port = encoder->port;
> enum transcoder cpu_transcoder;
> intel_wakeref_t wakeref;
> enum pipe pipe = 0;
> @@ -684,10 +694,7 @@ bool intel_ddi_connector_get_hw_state(struct
> intel_connector *intel_connector)
> goto out;
> }
>
> - if (HAS_TRANSCODER(dev_priv, TRANSCODER_EDP) && port == PORT_A)
> - cpu_transcoder = TRANSCODER_EDP;
> - else
> - cpu_transcoder = (enum transcoder) pipe;
> + cpu_transcoder = get_transcoder_for_pipe(encoder, pipe);
>
> tmp = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder));
>
> @@ -2155,17 +2162,29 @@ i915_reg_t dp_tp_ctl_reg(struct intel_encoder
> *encoder,
> return DP_TP_CTL(encoder->port);
> }
>
> -i915_reg_t dp_tp_status_reg(struct intel_encoder *encoder,
> - const struct intel_crtc_state *crtc_state)
> +static i915_reg_t __dp_tp_status_reg(struct intel_encoder *encoder,
> + enum transcoder transcoder)
> {
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>
> if (DISPLAY_VER(dev_priv) >= 12)
> - return TGL_DP_TP_STATUS(tgl_dp_tp_transcoder(crtc_state));
> + return TGL_DP_TP_STATUS(transcoder);
> else
> return DP_TP_STATUS(encoder->port);
> }
>
> +i915_reg_t dp_tp_status_reg(struct intel_encoder *encoder,
> + const struct intel_crtc_state *crtc_state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + enum transcoder transcoder = INVALID_TRANSCODER;
> +
> + if (DISPLAY_VER(dev_priv) >= 12)
> + transcoder = tgl_dp_tp_transcoder(crtc_state);
> +
> + return __dp_tp_status_reg(encoder, transcoder);
> +}
> +
> static void intel_dp_sink_set_msa_timing_par_ignore_state(struct intel_dp
> *intel_dp,
> const struct
> intel_crtc_state *crtc_state,
> bool enable)
> @@ -3500,6 +3519,61 @@ static void intel_ddi_get_config(struct intel_encoder
> *encoder,
> intel_audio_codec_get_config(encoder, pipe_config);
> }
>
> +static bool intel_ddi_get_hw_mst_state(struct intel_encoder *encoder,
> +struct intel_encoder_mst_state *state)
> +{
> + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> + enum transcoder transcoder;
> + u8 vc_pipe_mask = 0;
> + u8 pipe_mask;
> + bool is_mst;
> + u32 dp_status;
> + bool in_mst_mode;
> + int vc;
> +
> + intel_ddi_get_encoder_pipes(encoder, _mask, _mst);
> + if (!is_mst || !pipe_mask)
> + return false;
> +
> + transcoder = get_transcoder_for_pipe(encoder, ffs(pipe_mask) - 1);
> + dp_status = intel_de_read(i915, __dp_tp_status_reg(encoder,
> transcoder));
> +
> + in_mst_mode = REG_FIELD_GET(DP_TP_STATUS_MODE_STATUS_MST, dp_status);
> + if (drm_WARN_ON(>drm, !in_mst_mode))
> + return false;
> +
> + state->num_mst_streams =
> REG_FIELD_GET(DP_TP_STATUS_NUM_STREAMS_ENABLED,
[Intel-gfx] [PATCH v10 4/6] drm/i915/hdcp: Refactor HDCP API structures
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
Signed-off-by: Suraj Kandpal
Reviewed-by: Ankit Nautiyal
---
drivers/misc/mei/hdcp/mei_hdcp.c | 44 ++--
drivers/misc/mei/hdcp/mei_hdcp.h | 354 -
include/drm/i915_hdcp_interface.h | 355 ++
3 files changed, 377 insertions(+), 376 deletions(-)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index b2c49599809c..a262e1fa3b48 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -52,7 +52,7 @@ mei_hdcp_initiate_session(struct device *dev, struct
hdcp_port_data *data,
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.status = FW_HDCP_STATUS_SUCCESS;
session_init_in.header.buffer_len =
WIRED_CMD_BUF_LEN_INITIATE_HDCP2_SESSION_IN;
@@ -75,7 +75,7 @@ mei_hdcp_initiate_session(struct device *dev, struct
hdcp_port_data *data,
return byte;
}
- if (session_init_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+ if (session_init_out.header.status != FW_HDCP_STATUS_SUCCESS) {
dev_dbg(dev, "ME cmd 0x%08X Failed. Status: 0x%X\n",
WIRED_INITIATE_HDCP2_SESSION,
session_init_out.header.status);
@@ -122,7 +122,7 @@ mei_hdcp_verify_receiver_cert_prepare_km(struct 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.status = FW_HDCP_STATUS_SUCCESS;
verify_rxcert_in.header.buffer_len =
WIRED_CMD_BUF_LEN_VERIFY_RECEIVER_CERT_IN;
@@ -148,7 +148,7 @@ mei_hdcp_verify_receiver_cert_prepare_km(struct device *dev,
return byte;
}
- if (verify_rxcert_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+ if (verify_rxcert_out.header.status != FW_HDCP_STATUS_SUCCESS) {
dev_dbg(dev, "ME cmd 0x%08X Failed. Status: 0x%X\n",
WIRED_VERIFY_RECEIVER_CERT,
verify_rxcert_out.header.status);
@@ -194,7 +194,7 @@ mei_hdcp_verify_hprime(struct device *dev, struct
hdcp_port_data *data,
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.status = FW_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;
@@ -218,7 +218,7 @@ mei_hdcp_verify_hprime(struct device *dev, struct
hdcp_port_data *data,
return byte;
}
- if (send_hprime_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+ if (send_hprime_out.header.status != FW_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;
@@ -251,7 +251,7 @@ mei_hdcp_store_pairing_info(struct device *dev, struct
hdcp_port_data *data,
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.status = FW_HDCP_STATUS_SUCCESS;
pairing_info_in.header.buffer_len =
WIRED_CMD_BUF_LEN_SEND_PAIRING_INFO_IN;
@@ -276,7 +276,7 @@ mei_hdcp_store_pairing_info(struct device *dev, struct
hdcp_port_data *data,
return byte;
}
- if (pairing_info_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+ if (pairing_info_out.header.status != FW_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);
@@ -311,7 +311,7 @@ mei_hdcp_initiate_locality_check(struct 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.status = FW_HDCP_STATUS_SUCCESS;
lc_init_in.header.buffer_len = WIRED_CMD_BUF_LEN_INIT_LOCALITY_CHECK_IN;
[Intel-gfx] [PATCH v10 6/6] drm/i915/mtl: Add HDCP GSC interface
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 I915_HDCP_COMPONENT as integral part of i915.
Adding checks to see if GSC is loaded and proxy is setup
--v6
-dont change the license date in same patch series [Jani]
-fix the license year {Jani]
--v8
-remove stale comment [Ankit]
-get headers in alphabetical order [Ankit]
-fix hdcp2_supported check [Ankit]
--v9
-remove return statement from hdcp_gsc_fini [Ankit]
Cc: Tomas Winkler
Cc: Rodrigo Vivi
Cc: Uma Shankar
Cc: Ankit Nautiyal
Signed-off-by: Anshuman Gupta
Signed-off-by: Suraj Kandpal
Reviewed-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 28 +-
drivers/gpu/drm/i915/display/intel_hdcp_gsc.c | 637 +-
drivers/gpu/drm/i915/display/intel_hdcp_gsc.h | 3 +
3 files changed, 660 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 0d6aed1eb171..61bb2bbd0349 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -23,6 +23,7 @@
#include "intel_display_power_well.h"
#include "intel_display_types.h"
#include "intel_hdcp.h"
+#include "intel_hdcp_gsc.h"
#include "intel_hdcp_regs.h"
#include "intel_pcode.h"
@@ -203,13 +204,20 @@ bool intel_hdcp2_capable(struct intel_connector
*connector)
struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_hdcp *hdcp = >hdcp;
+ struct intel_gt *gt = dev_priv->media_gt;
+ struct intel_gsc_uc *gsc = >uc.gsc;
bool capable = false;
/* I915 support for HDCP2.2 */
if (!hdcp->hdcp2_supported)
return false;
- /* MEI interface is solid */
+ /* If MTL+ make sure gsc is loaded and proxy is setup */
+ if (intel_hdcp_gsc_cs_required(dev_priv))
+ if (!intel_uc_fw_is_running(>fw))
+ return false;
+
+ /* MEI/GSC interface is solid depending on which is used */
mutex_lock(_priv->display.hdcp.comp_mutex);
if (!dev_priv->display.hdcp.comp_added ||
!dev_priv->display.hdcp.master) {
mutex_unlock(_priv->display.hdcp.comp_mutex);
@@ -2235,6 +2243,9 @@ static int initialize_hdcp_port_data(struct
intel_connector *connector,
static bool is_hdcp2_supported(struct drm_i915_private *dev_priv)
{
+ if (intel_hdcp_gsc_cs_required(dev_priv))
+ return true;
+
if (!IS_ENABLED(CONFIG_INTEL_MEI_HDCP))
return false;
@@ -2256,10 +2267,14 @@ void intel_hdcp_component_init(struct drm_i915_private
*dev_priv)
dev_priv->display.hdcp.comp_added = true;
mutex_unlock(_priv->display.hdcp.comp_mutex);
- ret = component_add_typed(dev_priv->drm.dev, _hdcp_ops,
- I915_COMPONENT_HDCP);
+ if (intel_hdcp_gsc_cs_required(dev_priv))
+ ret = intel_hdcp_gsc_init(dev_priv);
+ else
+ ret = component_add_typed(dev_priv->drm.dev, _hdcp_ops,
+ I915_COMPONENT_HDCP);
+
if (ret < 0) {
- drm_dbg_kms(_priv->drm, "Failed at component add(%d)\n",
+ drm_dbg_kms(_priv->drm, "Failed at fw component add(%d)\n",
ret);
mutex_lock(_priv->display.hdcp.comp_mutex);
dev_priv->display.hdcp.comp_added = false;
@@ -2486,7 +2501,10 @@ void intel_hdcp_component_fini(struct drm_i915_private
*dev_priv)
dev_priv->display.hdcp.comp_added = false;
mutex_unlock(_priv->display.hdcp.comp_mutex);
- component_del(dev_priv->drm.dev, _hdcp_ops);
+ if (intel_hdcp_gsc_cs_required(dev_priv))
+ intel_hdcp_gsc_fini(dev_priv);
+ else
+ component_del(dev_priv->drm.dev, _hdcp_ops);
}
void intel_hdcp_cleanup(struct intel_connector *connector)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
index 8e3b5e6733d7..7eb1eeeb5a51 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
@@ -3,12 +3,617 @@
* Copyright 2023, Intel Corporation.
*/
+#include
+
#include "display/intel_hdcp_gsc.h"
#include "gem/i915_gem_region.h"
#include "gt/uc/intel_gsc_uc_heci_cmd_submit.h"
#include "i915_drv.h"
#include "i915_utils.h"
+bool intel_hdcp_gsc_cs_required(struct drm_i915_private *i915)
+{
+ return DISPLAY_VER(i915) >= 14;
+}
+
+static int
+gsc_hdcp_initiate_session(struct device *dev, struct hdcp_port_data *data,
+ struct hdcp2_ake_init
[Intel-gfx] [PATCH v10 5/6] drm/i915/mtl: Add function to send command to GSC CS
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 bit of response header around
20 times each try being 50ms apart hence adding that to current
gsc_msg_send function
Also we use the same function to take care of both sending and receiving
hence no separate function to get the response.
--v4
-Create common function to fill in gsc_mtl_header [Alan]
-define host session bitmask [Alan]
--v5
-use i915 directly instead of gt->i915 [Alan]
-No need to make fields NULL as we are already
using kzalloc [Alan]
--v8
-change mechanism to reuse the same memory for one hdcp session[Alan]
-fix header ordering
-add comments to explain flags and host session mask [Alan]
--v9
-remove gem obj from hdcp message as we can use
i915_vma_unpin_and_release [Alan]
-move hdcp message allocation and deallocation from hdcp2_enable and
hdcp2_disable to init and teardown of HDCP [Alan]
--v10
-remove unnecessary i915_vma_unpin [Alan]
Cc: Ankit Nautiyal
Cc: Daniele Ceraolo Spurio
Cc: Alan Pervin Teres
Cc: Uma Shankar
Cc: Anshuman Gupta
Signed-off-by: Suraj Kandpal
Reviewed-by: Alan Previn
---
drivers/gpu/drm/i915/Makefile | 1 +
.../gpu/drm/i915/display/intel_display_core.h | 5 +
drivers/gpu/drm/i915/display/intel_hdcp_gsc.c | 198 ++
drivers/gpu/drm/i915/display/intel_hdcp_gsc.h | 23 ++
.../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c | 15 ++
.../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h | 16 ++
6 files changed, 258 insertions(+)
create mode 100644 drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
create mode 100644 drivers/gpu/drm/i915/display/intel_hdcp_gsc.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 482928cffb1c..ba76bec715af 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -255,6 +255,7 @@ i915-y += \
display/intel_frontbuffer.o \
display/intel_global_state.o \
display/intel_hdcp.o \
+ display/intel_hdcp_gsc.o \
display/intel_hotplug.o \
display/intel_hti.o \
display/intel_lpe_audio.o \
diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h
b/drivers/gpu/drm/i915/display/intel_display_core.h
index 139100fe2383..20d2a79a5d05 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -382,6 +382,11 @@ struct intel_display {
struct i915_hdcp_master *master;
bool comp_added;
+ /*HDCP message struct for allocation of memory which can be
reused
+* when sending message to gsc cs
+* this is only populated post Meteorlake
+*/
+ struct intel_hdcp_gsc_message *hdcp_message;
/* Mutex to protect the above hdcp component related values. */
struct mutex comp_mutex;
} hdcp;
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
new file mode 100644
index ..8e3b5e6733d7
--- /dev/null
+++ b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
@@ -0,0 +1,198 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright 2023, Intel Corporation.
+ */
+
+#include "display/intel_hdcp_gsc.h"
+#include "gem/i915_gem_region.h"
+#include "gt/uc/intel_gsc_uc_heci_cmd_submit.h"
+#include "i915_drv.h"
+#include "i915_utils.h"
+
+/*This function helps allocate memory for the command that we will send to gsc
cs */
+static int intel_hdcp_gsc_initialize_message(struct drm_i915_private *i915,
+struct intel_hdcp_gsc_message
*hdcp_message)
+{
+ struct intel_gt *gt = i915->media_gt;
+ struct drm_i915_gem_object *obj = NULL;
+ struct i915_vma *vma = NULL;
+ void *cmd;
+ int err;
+
+ /* allocate object of one page for HDCP command memory and store it */
+ obj = i915_gem_object_create_shmem(i915, PAGE_SIZE);
+
+ if (IS_ERR(obj)) {
+ drm_err(>drm, "Failed to allocate HDCP streaming
command!\n");
+ return PTR_ERR(obj);
+ }
+
+ cmd = i915_gem_object_pin_map_unlocked(obj,
i915_coherent_map_type(i915, obj, true));
+ if (IS_ERR(cmd)) {
+ drm_err(>drm, "Failed to map gsc message page!\n");
+ err = PTR_ERR(cmd);
+ goto out_unpin;
+ }
+
+ vma = i915_vma_instance(obj, >ggtt->vm, NULL);
+ if (IS_ERR(vma)) {
+ err = PTR_ERR(vma);
+ goto out_unmap;
+ }
+
+ err = i915_vma_pin(vma, 0, 0, PIN_GLOBAL);
+ if (err)
+ goto out_unmap;
+
+ memset(cmd, 0, obj->base.size);
+
+ hdcp_message->hdcp_cmd = cmd;
+ hdcp_message->vma = vma;
+
+
[Intel-gfx] [PATCH v10 1/6] drm/i915/gsc: Create GSC request submission mechanism
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 scalability [Alan]
-Rename gsc address field [Alan]
Cc: Daniele Ceraolo Spurio
Cc: Alan Previn
Signed-off-by: Suraj Kandpal
Reviewed-by: Alan Previn
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 2 +
drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h | 1 +
.../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c | 94 +++
.../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h | 45 +
5 files changed, 143 insertions(+)
create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c
create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 918470a04591..482928cffb1c 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -195,6 +195,7 @@ i915-y += \
i915-y += \
gt/uc/intel_gsc_fw.o \
gt/uc/intel_gsc_uc.o \
+ gt/uc/intel_gsc_uc_heci_cmd_submit.o\
gt/uc/intel_guc.o \
gt/uc/intel_guc_ads.o \
gt/uc/intel_guc_capture.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index 2af1ae3831df..454179884801 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -439,6 +439,8 @@
#define GSC_FW_LOAD GSC_INSTR(1, 0, 2)
#define HECI1_FW_LIMIT_VALID (1 << 31)
+#define GSC_HECI_CMD_PKT GSC_INSTR(0, 0, 6)
+
/*
* Used to convert any address to canonical form.
* Starting from gen8, some commands (e.g. STATE_BASE_ADDRESS,
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
index 4b5dbb44afb4..146ac0128f69 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
@@ -12,4 +12,5 @@ struct intel_gsc_uc;
int intel_gsc_uc_fw_upload(struct intel_gsc_uc *gsc);
bool intel_gsc_uc_fw_init_done(struct intel_gsc_uc *gsc);
+
#endif
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c
new file mode 100644
index ..be2424af521d
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c
@@ -0,0 +1,94 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2023 Intel Corporation
+ */
+
+#include "gt/intel_engine_pm.h"
+#include "gt/intel_gpu_commands.h"
+#include "gt/intel_gt.h"
+#include "gt/intel_ring.h"
+#include "intel_gsc_uc_heci_cmd_submit.h"
+
+struct gsc_heci_pkt {
+ u64 addr_in;
+ u32 size_in;
+ u64 addr_out;
+ u32 size_out;
+};
+
+static int emit_gsc_heci_pkt(struct i915_request *rq, struct gsc_heci_pkt *pkt)
+{
+ u32 *cs;
+
+ cs = intel_ring_begin(rq, 8);
+ if (IS_ERR(cs))
+ return PTR_ERR(cs);
+
+ *cs++ = GSC_HECI_CMD_PKT;
+ *cs++ = lower_32_bits(pkt->addr_in);
+ *cs++ = upper_32_bits(pkt->addr_in);
+ *cs++ = pkt->size_in;
+ *cs++ = lower_32_bits(pkt->addr_out);
+ *cs++ = upper_32_bits(pkt->addr_out);
+ *cs++ = pkt->size_out;
+ *cs++ = 0;
+
+ intel_ring_advance(rq, cs);
+
+ return 0;
+}
+
+int intel_gsc_uc_heci_cmd_submit_packet(struct intel_gsc_uc *gsc, u64 addr_in,
+ u32 size_in, u64 addr_out,
+ u32 size_out)
+{
+ struct intel_context *ce = gsc->ce;
+ struct i915_request *rq;
+ struct gsc_heci_pkt pkt = {
+ .addr_in = addr_in,
+ .size_in = size_in,
+ .addr_out = addr_out,
+ .size_out = size_out
+ };
+ int err;
+
+ if (!ce)
+ return -ENODEV;
+
+ rq = i915_request_create(ce);
+ if (IS_ERR(rq))
+ return PTR_ERR(rq);
+
+ if (ce->engine->emit_init_breadcrumb) {
+ err = ce->engine->emit_init_breadcrumb(rq);
+ if (err)
+ goto out_rq;
+ }
+
+ err = emit_gsc_heci_pkt(rq, );
+
+ if (err)
+ goto out_rq;
+
+ err = ce->engine->emit_flush(rq, 0);
+
+out_rq:
+ i915_request_get(rq);
+
+ if (unlikely(err))
+ i915_request_set_error_once(rq, err);
+
+ i915_request_add(rq);
+
+ if (!err && i915_request_wait(rq, 0, msecs_to_jiffies(500)) < 0)
+ err = -ETIME;
+
+ i915_request_put(rq);
+
+ if (err)
+ drm_err(_uc_to_gt(gsc)->i915->drm,
+ "Request submission for GSC heci cmd failed (%d)\n",
+ err);
+
+ return err;
+}
diff --git
[Intel-gfx] [PATCH v10 3/6] i915/hdcp: HDCP2.x Refactoring to agnostic hdcp
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 structure name Accordingly.
%s/i915_hdcp_comp_master/i915_hdcp_master
%s/i915_hdcp_component_ops/i915_hdcp_ops
--v3
-Changing names to drop cp_fw to make naming more agnostic[Jani]
Cc: Tomas Winkler
Cc: Rodrigo Vivi
Cc: Uma Shankar
Cc: Ankit Nautiyal
Signed-off-by: Anshuman Gupta
Signed-off-by: Suraj Kandpal
Reviewed-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_display_core.h | 1 +
drivers/gpu/drm/i915/display/intel_hdcp.c | 4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h
b/drivers/gpu/drm/i915/display/intel_display_core.h
index 8e7a68339876..139100fe2383 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -15,6 +15,7 @@
#include
#include
+#include
#include "intel_cdclk.h"
#include "intel_display_limits.h"
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 262c76f21801..0d6aed1eb171 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1409,7 +1409,7 @@ static int hdcp2_authenticate_port(struct intel_connector
*connector)
return ret;
}
-static int hdcp2_close_mei_session(struct intel_connector *connector)
+static int hdcp2_close_session(struct intel_connector *connector)
{
struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
@@ -1433,7 +1433,7 @@ static int hdcp2_close_mei_session(struct intel_connector
*connector)
static int hdcp2_deauthenticate_port(struct intel_connector *connector)
{
- return hdcp2_close_mei_session(connector);
+ return hdcp2_close_session(connector);
}
/* Authentication flow starts from here */
--
2.25.1
[Intel-gfx] [PATCH v10 2/6] drm/i915/hdcp: Keep hdcp agonstic naming convention
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 Nautiyal
Signed-off-by: Anshuman Gupta
Signed-off-by: Suraj Kandpal
Reviewed-by: Ankit Nautiyal
Acked-by: Tomas Winkler
---
.../gpu/drm/i915/display/intel_display_core.h | 2 +-
.../drm/i915/display/intel_display_types.h| 2 +-
drivers/gpu/drm/i915/display/intel_hdcp.c | 81
drivers/misc/mei/hdcp/mei_hdcp.c | 61 ++--
...hdcp_interface.h => i915_hdcp_interface.h} | 92 +--
5 files changed, 118 insertions(+), 120 deletions(-)
rename include/drm/{i915_mei_hdcp_interface.h => i915_hdcp_interface.h} (73%)
diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h
b/drivers/gpu/drm/i915/display/intel_display_core.h
index fb8670aa2932..8e7a68339876 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -378,7 +378,7 @@ struct intel_display {
} gmbus;
struct {
- struct i915_hdcp_comp_master *master;
+ struct i915_hdcp_master *master;
bool comp_added;
/* Mutex to protect the above hdcp component related values. */
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 9ccae7a46020..7accd3a8877c 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -43,7 +43,7 @@
#include
#include
#include
-#include
+#include
#include
#include "i915_vma.h"
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 6406fd487ee5..262c76f21801 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1143,7 +1143,7 @@ hdcp2_prepare_ake_init(struct intel_connector *connector,
struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
struct hdcp_port_data *data = _port->hdcp_port_data;
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
- struct i915_hdcp_comp_master *comp;
+ struct i915_hdcp_master *comp;
int ret;
mutex_lock(_priv->display.hdcp.comp_mutex);
@@ -1154,7 +1154,7 @@ hdcp2_prepare_ake_init(struct intel_connector *connector,
return -EINVAL;
}
- ret = comp->ops->initiate_hdcp2_session(comp->mei_dev, data, ake_data);
+ ret = comp->ops->initiate_hdcp2_session(comp->hdcp_dev, data, ake_data);
if (ret)
drm_dbg_kms(_priv->drm, "Prepare_ake_init failed. %d\n",
ret);
@@ -1173,7 +1173,7 @@ hdcp2_verify_rx_cert_prepare_km(struct intel_connector
*connector,
struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
struct hdcp_port_data *data = _port->hdcp_port_data;
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
- struct i915_hdcp_comp_master *comp;
+ struct i915_hdcp_master *comp;
int ret;
mutex_lock(_priv->display.hdcp.comp_mutex);
@@ -1184,7 +1184,7 @@ hdcp2_verify_rx_cert_prepare_km(struct intel_connector
*connector,
return -EINVAL;
}
- ret = comp->ops->verify_receiver_cert_prepare_km(comp->mei_dev, data,
+ ret = comp->ops->verify_receiver_cert_prepare_km(comp->hdcp_dev, data,
rx_cert, paired,
ek_pub_km, msg_sz);
if (ret < 0)
@@ -1201,7 +1201,7 @@ static int hdcp2_verify_hprime(struct intel_connector
*connector,
struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
struct hdcp_port_data *data = _port->hdcp_port_data;
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
- struct i915_hdcp_comp_master *comp;
+ struct i915_hdcp_master *comp;
int ret;
mutex_lock(_priv->display.hdcp.comp_mutex);
@@ -1212,7 +1212,7 @@ static int hdcp2_verify_hprime(struct intel_connector
*connector,
return -EINVAL;
}
- ret = comp->ops->verify_hprime(comp->mei_dev, data, rx_hprime);
+ ret = comp->ops->verify_hprime(comp->hdcp_dev, data, rx_hprime);
if (ret < 0)
drm_dbg_kms(_priv->drm, "Verify hprime failed. %d\n", ret);
mutex_unlock(_priv->display.hdcp.comp_mutex);
@@ -1227,7 +1227,7 @@ hdcp2_store_pairing_info(struct intel_connector
*connector,
struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
struct hdcp_port_data *data = _port->hdcp_port_data;
struct drm_i915_private
[Intel-gfx] [PATCH v10 0/6] Enable HDCP2.x via GSC CS
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 make naming more agnostic[Jani] -Sort header[Jani] -remove static inline function from i915_hdcp_interface[Jani] -abstract DISPLAY_VER check[Jani] --v4 -Remove stale comment P2 [Jani] -Fix part where file rename looks like its removed in P2 and added in P3 [Jani] -Add bitmask definition for host session id[Alan] -Seprating gsc load and heci cmd submission into different funcs[Alan] -Create comman function to fill gsc_mtl_header[Alan] --v5 -No need to make hdcp_message field null as we use kzalloc [Alan] -use i915->drm instead of gt->i915->drm [Alan] --v6 -Make each patch build individually [Jani] -drop cp_fw stale commit subject [Jani] -fix the date on license [Jani] -revert back to orginal design where mei and gsc fill their own header --v7 -remove RB by Ankit --v8 -change design to allocate and deallocate hdcp_message only at enablement and disabling of hdcp [Alan] -fix few formatting issue [Ankit] -fix stale comments [Ankit] --v9 -move allocation dealloc of hdcp messgae to init and teardown [Alan] -remove obj from hdcp message , use i915_vma_unpin_and_release [Alan] -remove return statement from intel_hdcp_gsc_fini [Ankit] --v10 -remove unnecessary i915_vma_unpin [Alan] Anshuman Gupta (1): drm/i915/hdcp: Keep hdcp agonstic naming convention Suraj Kandpal (5): drm/i915/gsc: Create GSC request submission mechanism i915/hdcp: HDCP2.x Refactoring to agnostic hdcp drm/i915/hdcp: Refactor HDCP API structures drm/i915/mtl: Add function to send command to GSC CS drm/i915/mtl: Add HDCP GSC interface drivers/gpu/drm/i915/Makefile | 2 + .../gpu/drm/i915/display/intel_display_core.h | 8 +- .../drm/i915/display/intel_display_types.h| 2 +- drivers/gpu/drm/i915/display/intel_hdcp.c | 109 ++- drivers/gpu/drm/i915/display/intel_hdcp_gsc.c | 829 ++ drivers/gpu/drm/i915/display/intel_hdcp_gsc.h | 26 + drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 2 + drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h | 1 + .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c | 109 +++ .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h | 61 ++ drivers/misc/mei/hdcp/mei_hdcp.c | 105 ++- drivers/misc/mei/hdcp/mei_hdcp.h | 354 include/drm/i915_hdcp_interface.h | 539 include/drm/i915_mei_hdcp_interface.h | 184 14 files changed, 1692 insertions(+), 639 deletions(-) create mode 100644 drivers/gpu/drm/i915/display/intel_hdcp_gsc.c create mode 100644 drivers/gpu/drm/i915/display/intel_hdcp_gsc.h create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h create mode 100644 include/drm/i915_hdcp_interface.h delete mode 100644 include/drm/i915_mei_hdcp_interface.h -- 2.25.1
Re: [Intel-gfx] [PATCH v9 5/6] drm/i915/mtl: Add function to send command to GSC CS
> 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 command to
> GSC CS
>
> 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
> > 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 bit of response header around
> > 20 times each try being 50ms apart hence adding that to current
> > gsc_msg_send function Also we use the same function to take care of
> > both sending and receiving hence no separate function to get the
> > response.
> >
> >
> alan:snip..
>
> > +/*This function helps allocate memory for the command that we will
> > +send to gsc cs */ int intel_hdcp_gsc_hdcp2_init(struct
> > +drm_i915_private *i915) {
> > +
> alan: okay i see this is now being called from intel_hdcp_gsc_init
>
> > +void intel_hdcp_gsc_free_message(struct drm_i915_private *i915) {
> > + struct intel_hdcp_gsc_message *hdcp_message =
> > +
> > +i915->display.hdcp.hdcp_message;
> > + if (hdcp_message->vma)
> > + i915_vma_unpin(fetch_and_zero(_message->vma));
> alan: i believe you don't need this extra i915_vma_unpin. Also, take note you
> have a bug above ...
> first code does a "fetch_and_zero" and right after zero-ing out its used to
> call
> i915_vma_unpin_and_release on the line below. So.. "if (hdcp_message-
> >vma) -> i915_vma_unpin_and_release"
I see we can just skip this part and directly do an i915_vma_unpin_and_release
Regards,
Suraj Kandpal
> > +
> > + i915_vma_unpin_and_release(_message->vma,
> > +I915_VMA_RELEASE_MAP);
> > + kfree(hdcp_message);
> > +}
> > +
> >
>
> alan:snip..
> > --
> > 2.25.1
> >
Re: [Intel-gfx] [PATCH v9 5/6] drm/i915/mtl: Add function to send command to GSC CS
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
> 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 bit of response header around
> 20 times each try being 50ms apart hence adding that to current
> gsc_msg_send function
> Also we use the same function to take care of both sending and receiving
> hence no separate function to get the response.
>
>
alan:snip..
> +/*This function helps allocate memory for the command that we will send to
> gsc cs */
> +int intel_hdcp_gsc_hdcp2_init(struct drm_i915_private *i915)
> +{
> +
alan: okay i see this is now being called from intel_hdcp_gsc_init
> +void intel_hdcp_gsc_free_message(struct drm_i915_private *i915)
> +{
> + struct intel_hdcp_gsc_message *hdcp_message =
> + i915->display.hdcp.hdcp_message;
> + if (hdcp_message->vma)
> + i915_vma_unpin(fetch_and_zero(_message->vma));
alan: i believe you don't need this extra i915_vma_unpin. Also, take note you
have a bug above ...
first code does a "fetch_and_zero" and right after zero-ing out its used to
call i915_vma_unpin_and_release
on the line below. So.. "if (hdcp_message->vma) -> i915_vma_unpin_and_release"
> +
> + i915_vma_unpin_and_release(_message->vma, I915_VMA_RELEASE_MAP);
> + kfree(hdcp_message);
> +}
> +
>
alan:snip..
> --
> 2.25.1
>
