[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Allow user to set cache at BO creation (rev10)
== Series Details ==
Series: drm/i915: Allow user to set cache at BO creation (rev10)
URL : https://patchwork.freedesktop.org/series/116870/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13165 -> Patchwork_116870v10
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116870v10/index.html
Participating hosts (37 -> 37)
--
Additional (1): bat-rpls-2
Missing(1): fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_116870v10:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@requests:
- {bat-mtlp-6}: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13165/bat-mtlp-6/igt@i915_selftest@l...@requests.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116870v10/bat-mtlp-6/igt@i915_selftest@l...@requests.html
Known issues
Here are the changes found in Patchwork_116870v10 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@basic-hwmon:
- bat-rpls-2: NOTRUN -> [SKIP][3] ([i915#7456])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116870v10/bat-rpls-2/igt@debugfs_t...@basic-hwmon.html
* igt@fbdev@read:
- bat-rpls-2: NOTRUN -> [SKIP][4] ([i915#2582]) +4 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116870v10/bat-rpls-2/igt@fb...@read.html
* igt@gem_lmem_swapping@verify-random:
- bat-rpls-2: NOTRUN -> [SKIP][5] ([i915#4613]) +3 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116870v10/bat-rpls-2/igt@gem_lmem_swapp...@verify-random.html
* igt@gem_tiled_pread_basic:
- bat-rpls-2: NOTRUN -> [SKIP][6] ([i915#3282])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116870v10/bat-rpls-2/igt@gem_tiled_pread_basic.html
* igt@i915_pm_backlight@basic-brightness:
- bat-rpls-2: NOTRUN -> [SKIP][7] ([i915#7561])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116870v10/bat-rpls-2/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_pm_rps@basic-api:
- bat-rpls-2: NOTRUN -> [SKIP][8] ([i915#6621])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116870v10/bat-rpls-2/igt@i915_pm_...@basic-api.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka: [PASS][9] -> [DMESG-FAIL][10] ([i915#5334] /
[i915#7872])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13165/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116870v10/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@gt_pm:
- bat-rpls-2: NOTRUN -> [DMESG-FAIL][11] ([i915#4258] / [i915#7913])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116870v10/bat-rpls-2/igt@i915_selftest@live@gt_pm.html
* igt@i915_suspend@basic-s2idle-without-i915:
- bat-rpls-2: NOTRUN -> [ABORT][12] ([i915#6687])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116870v10/bat-rpls-2/igt@i915_susp...@basic-s2idle-without-i915.html
- fi-rkl-11600: [PASS][13] -> [FAIL][14] ([fdo#103375])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13165/fi-rkl-11600/igt@i915_susp...@basic-s2idle-without-i915.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116870v10/fi-rkl-11600/igt@i915_susp...@basic-s2idle-without-i915.html
* igt@kms_busy@basic:
- bat-rpls-2: NOTRUN -> [SKIP][15] ([i915#1845]) +14 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116870v10/bat-rpls-2/igt@kms_b...@basic.html
* igt@kms_chamelium_edid@hdmi-edid-read:
- bat-rpls-2: NOTRUN -> [SKIP][16] ([i915#7828]) +7 similar issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116870v10/bat-rpls-2/igt@kms_chamelium_e...@hdmi-edid-read.html
* igt@kms_flip@basic-flip-vs-dpms:
- bat-rpls-2: NOTRUN -> [SKIP][17] ([i915#3637]) +3 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116870v10/bat-rpls-2/igt@kms_f...@basic-flip-vs-dpms.html
* igt@kms_force_connector_basic@force-load-detect:
- bat-rpls-2: NOTRUN -> [SKIP][18] ([fdo#109285])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116870v10/bat-rpls-2/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_frontbuffer_tracking@basic:
- bat-rpls-2: NOTRUN -> [SKIP][19] ([i915#1849])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116870v10/bat-rpls-2/igt@kms_frontbuffer_track...@basic.html
* igt@kms_pipe_crc_basic@nonblocking-crc-
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Allow user to set cache at BO creation (rev10)
== Series Details == Series: drm/i915: Allow user to set cache at BO creation (rev10) URL : https://patchwork.freedesktop.org/series/116870/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] [PATCH v10 2/2] drm/i915: Allow user to set cache at BO creation
From: Fei Yang
To comply with the design that buffer objects shall have immutable
cache setting through out their life cycle, {set, get}_caching ioctl's
are no longer supported from MTL onward. With that change caching
policy can only be set at object creation time. The current code
applies a default (platform dependent) cache setting for all objects.
However this is not optimal for performance tuning. The patch extends
the existing gem_create uAPI to let user set PAT index for the object
at creation time.
The new extension is platform independent, so UMD's can switch to using
this extension for older platforms as well, while {set, get}_caching are
still supported on these legacy paltforms for compatibility reason.
Test igt@gem_create@create_ext_set_pat posted at
https://patchwork.freedesktop.org/series/117695/
Tested with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22878
Signed-off-by: Fei Yang
Cc: Chris Wilson
Cc: Matt Roper
Cc: Andi Shyti
Reviewed-by: Andi Shyti
Acked-by: Jordan Justen
Tested-by: Jordan Justen
---
drivers/gpu/drm/i915/gem/i915_gem_create.c | 36 +++
drivers/gpu/drm/i915/gem/i915_gem_object.c | 6
include/uapi/drm/i915_drm.h| 42 ++
tools/include/uapi/drm/i915_drm.h | 42 ++
4 files changed, 126 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index bfe1dbda4cb7..644a936248ad 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -245,6 +245,7 @@ struct create_ext {
unsigned int n_placements;
unsigned int placement_mask;
unsigned long flags;
+ unsigned int pat_index;
};
static void repr_placements(char *buf, size_t size,
@@ -394,11 +395,39 @@ static int ext_set_protected(struct i915_user_extension
__user *base, void *data
return 0;
}
+static int ext_set_pat(struct i915_user_extension __user *base, void *data)
+{
+ struct create_ext *ext_data = data;
+ struct drm_i915_private *i915 = ext_data->i915;
+ struct drm_i915_gem_create_ext_set_pat ext;
+ unsigned int max_pat_index;
+
+ BUILD_BUG_ON(sizeof(struct drm_i915_gem_create_ext_set_pat) !=
+offsetofend(struct drm_i915_gem_create_ext_set_pat, rsvd));
+
+ if (copy_from_user(&ext, base, sizeof(ext)))
+ return -EFAULT;
+
+ max_pat_index = INTEL_INFO(i915)->max_pat_index;
+
+ if (ext.pat_index > max_pat_index) {
+ drm_dbg(&i915->drm, "PAT index is invalid: %u\n",
+ ext.pat_index);
+ return -EINVAL;
+ }
+
+ ext_data->pat_index = ext.pat_index;
+
+ return 0;
+}
+
static const i915_user_extension_fn create_extensions[] = {
[I915_GEM_CREATE_EXT_MEMORY_REGIONS] = ext_set_placements,
[I915_GEM_CREATE_EXT_PROTECTED_CONTENT] = ext_set_protected,
+ [I915_GEM_CREATE_EXT_SET_PAT] = ext_set_pat,
};
+#define PAT_INDEX_NOT_SET 0x
/**
* i915_gem_create_ext_ioctl - Creates a new mm object and returns a handle to
it.
* @dev: drm device pointer
@@ -418,6 +447,7 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void
*data,
if (args->flags & ~I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS)
return -EINVAL;
+ ext_data.pat_index = PAT_INDEX_NOT_SET;
ret = i915_user_extensions(u64_to_user_ptr(args->extensions),
create_extensions,
ARRAY_SIZE(create_extensions),
@@ -454,5 +484,11 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void
*data,
if (IS_ERR(obj))
return PTR_ERR(obj);
+ if (ext_data.pat_index != PAT_INDEX_NOT_SET) {
+ i915_gem_object_set_pat_index(obj, ext_data.pat_index);
+ /* Mark pat_index is set by UMD */
+ obj->pat_set_by_user = true;
+ }
+
return i915_gem_publish(obj, file, &args->size, &args->handle);
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 46a19b099ec8..97ac6fb37958 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -208,6 +208,12 @@ bool i915_gem_object_can_bypass_llc(struct
drm_i915_gem_object *obj)
if (!(obj->flags & I915_BO_ALLOC_USER))
return false;
+ /*
+* Always flush cache for UMD objects at creation time.
+*/
+ if (obj->pat_set_by_user)
+ return true;
+
/*
* EHL and JSL add the 'Bypass LLC' MOCS entry, which should make it
* possible for userspace to bypass the GTT caching bits set by the
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index ba40855dbc93..4f3fd650e5e1 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
[Intel-gfx] [PATCH v10 0/2] drm/i915: Allow user to set cache at BO creation
From: Fei Yang
This series introduce a new extension for GEM_CREATE,
1. end support for set caching ioctl [PATCH 1/2]
2. add set_pat extension for gem_create [PATCH 2/2]
v2: drop one patch that was merged separately
commit 341ad0e8e254 ("drm/i915/mtl: Add PTE encode function")
v3: rebased on https://patchwork.freedesktop.org/series/117082/
v4: fix missing unlock introduced in v3, and
solve a rebase conflict
v5: replace obj->cache_level with pat_set_by_user,
fix i915_cache_level_str() for legacy platforms.
v6: rebased on https://patchwork.freedesktop.org/series/117480/
v7: rebased on https://patchwork.freedesktop.org/series/117528/
v8: dropped the two dependent patches that has been merged
separately. Add IGT link and Tested-by (MESA).
v9: addressing comments (Andi)
v10: acked-by and tested-by MESA
Fei Yang (2):
drm/i915/mtl: end support for set caching ioctl
drm/i915: Allow user to set cache at BO creation
drivers/gpu/drm/i915/gem/i915_gem_create.c | 36 +++
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 3 ++
drivers/gpu/drm/i915/gem/i915_gem_object.c | 6
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 9 -
include/uapi/drm/i915_drm.h| 42 ++
tools/include/uapi/drm/i915_drm.h | 42 ++
6 files changed, 137 insertions(+), 1 deletion(-)
--
2.25.1
[Intel-gfx] [PATCH v10 1/2] drm/i915/mtl: end support for set caching ioctl
From: Fei Yang
The design is to keep Buffer Object's caching policy immutable through
out its life cycle. This patch ends the support for set caching ioctl
from MTL onward. While doing that we also set BO's to be 1-way coherent
at creation time because GPU is no longer automatically snooping CPU
cache. For userspace components needing to fine tune the caching policy
for BO's, a follow up patch will extend the GEM_CREATE uAPI to allow
them specify caching mode at BO creation time.
Signed-off-by: Fei Yang
Reviewed-by: Andi Shyti
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 3 +++
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 9 -
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index 05107a6efe45..dfaaa8b66ac3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -350,6 +350,9 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, void
*data,
if (IS_DGFX(i915))
return -ENODEV;
+ if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70))
+ return -EOPNOTSUPP;
+
switch (args->caching) {
case I915_CACHING_NONE:
level = I915_CACHE_NONE;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index 37d1efcd3ca6..cad4a6017f4b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -601,7 +601,14 @@ static int shmem_object_init(struct intel_memory_region
*mem,
obj->write_domain = I915_GEM_DOMAIN_CPU;
obj->read_domains = I915_GEM_DOMAIN_CPU;
- if (HAS_LLC(i915))
+ /*
+* MTL doesn't snoop CPU cache by default for GPU access (namely
+* 1-way coherency). However some UMD's are currently depending on
+* that. Make 1-way coherent the default setting for MTL. A follow
+* up patch will extend the GEM_CREATE uAPI to allow UMD's specify
+* caching mode at BO creation time
+*/
+ if (HAS_LLC(i915) || (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70)))
/* On some devices, we can have the GPU use the LLC (the CPU
* cache) for about a 10% performance improvement
* compared to uncached. Graphics requests other than
--
2.25.1
Re: [Intel-gfx] [PATCH v5 1/7] drm/i915/pmu: Change bitmask of enabled events to u32
On Thu, 18 May 2023 02:07:55 -0700, Tvrtko Ursulin wrote:
>
> On 17/05/2023 17:25, Dixit, Ashutosh wrote:
> > On Wed, 17 May 2023 01:26:15 -0700, Tvrtko Ursulin wrote:
> >>
> >>
> >> On 17/05/2023 07:55, Umesh Nerlige Ramappa wrote:
> >>> On Tue, May 16, 2023 at 05:25:50PM -0700, Dixit, Ashutosh wrote:
> On Tue, 16 May 2023 16:35:28 -0700, Umesh Nerlige Ramappa wrote:
> >
>
> Hi Umesh/Tvrtko,
>
> Mostly repeating comments/questions made on the previous patch below.
> >>
> >> First of all thanks for improving this, my v1 obviously wasn't good enough.
> >>
>
> > From: Tvrtko Ursulin
> >
> > Having it as u64 was a confusing (but harmless) mistake.
> >
> > Also add some asserts to make sure the internal field does not overflow
> > in the future.
> >
> > v2: Fix WARN_ON firing for INTERRUPT event (Umesh)
> >
> > Signed-off-by: Tvrtko Ursulin
> > Signed-off-by: Umesh Nerlige Ramappa
> > Cc: Ashutosh Dixit
> > ---
> > drivers/gpu/drm/i915/i915_pmu.c | 26 ++
> > 1 file changed, 18 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_pmu.c
> > b/drivers/gpu/drm/i915/i915_pmu.c
> > index 7ece883a7d95..96543dce2db1 100644
> > --- a/drivers/gpu/drm/i915/i915_pmu.c
> > +++ b/drivers/gpu/drm/i915/i915_pmu.c
> > @@ -50,7 +50,7 @@ static u8 engine_event_instance(struct perf_event
> > *event)
> > return (event->attr.config >> I915_PMU_SAMPLE_BITS) & 0xff;
> > }
> >
> > -static bool is_engine_config(u64 config)
> > +static bool is_engine_config(const u64 config)
> > {
> > return config < __I915_PMU_OTHER(0);
> > }
> > @@ -88,9 +88,20 @@ static unsigned int config_bit(const u64 config)
> > return other_bit(config);
> > }
> >
> > -static u64 config_mask(u64 config)
> > +static u32 config_mask(const u64 config)
> > {
> > - return BIT_ULL(config_bit(config));
> > + unsigned int bit = config_bit(config);
>
> Give that config_bit() can return -1 (I understand it is avoided in
> moving
> the code to config_mask from config_bit), maybe the code below should
> also
> have that check?
> >>>
> >>> config_mask is only called to check frequency related events in the code,
> >>> so I don't see it returing -1 here.
> >>
> >> Yeah that should be fine since -1 would make the below asserts fire
> >> anyway. (If it would get called from a different path in the future.)
> >>
>
> int bit = config_bit(config);
>
> if (bit != -1)
> {
> ...
> }
>
> Though as mentioned below the 'if (__builtin_constant_p())' would have to
> go. Maybe the code could even have stayed in config_bit with the check.
>
> > +
> > + if (__builtin_constant_p(config))
> > + BUILD_BUG_ON(bit >
> > + BITS_PER_TYPE(typeof_member(struct i915_pmu,
> > + enable)) - 1);
>
> Given that config comes from the event (it is event->attr.config), can
> this
> ever be a builtin constant?
> >>>
> >>> Not sure about earlier code where these checks were inside config_bit(),
> >>> but with changes I made, I don't see this being a builtin
> >>> constant. However, nothing prevents a caller from just passing a
> >>> builtin_constant to this in future.
> >>
> >> Are you sure? I would have thought it would always be a compile time
> >> constant now that the check is in config_mask. Aahhh.. with the multi-tile
> >> changes maybe it can't unroll the loops and calculate the masks at compile
> >> time. Maybe it is a bit too much and we should drop the
> >> __builtin_constant_p branch? Probably..
> >
> > Ah yes, with the code move to config_mask, they really all are compile time
> > constants (provided compiler can unroll the loops) so at least that is the
> > justfication for leaving the __builtin_constant_p in. So I'd probably just
> > leave it as is (though it is a bit too much).
> >
> >> But I guess it is safe to use GEM_WARN_ON_ONCE instead of WARN_ON_ONCE
> >> since there are no external callers (nothing coming from event) now. That
> >> way at least production builds don't have to have the check.
> >
> > Hmm, there's a GEM_WARN_ON but no GEM_WARN_ON_ONCE. So leave that as is too
> > I guess.
> >
> > So I'm ok with the code staying as is. Enough bike-shed on this already.
>
> Latest series looks fine to me and thanks for your patience. Hope you would
> agree changing that one thing to u32 made more sense than changing the
> other to u64 so bike shed wasn't for nothing.
Hi Tvrtko, yes definitely, no issues :)
Thanks for your patience too.
--
Ashutosh
Re: [Intel-gfx] [PATCH v3 03/28] drm/i915/gvt: Verify hugepages are contiguous in physical address space
On Thu, May 18, 2023 at 11:04:46AM -0700, Sean Christopherson wrote: > On Thu, May 18, 2023, Yan Zhao wrote: > > On Wed, May 17, 2023 at 07:50:26AM -0700, Sean Christopherson wrote: > > > On Tue, May 16, 2023, Yan Zhao wrote: > > > > hi Sean > > > > > > > > Do you think it's necessary to double check that struct page pointers > > > > are also contiguous? > > > > > > No, the virtual address space should be irrelevant. The only way it > > > would be > > > problematic is if something in dma_map_page() expected to be able to > > > access the > > > entire chunk of memory by getting the virtual address of only the first > > > page, > > > but I can't imagine that code is reading or writing memory, let alone > > > doing so > > > across a huge range of memory. > > Yes, I do find arm_iommu version of dma_map_page() access the memory by > > getting > > virtual address of pages passed in, but it's implemented as page by page, > > not only > > from the first page. > > > > dma_map_page > > dma_map_page_attrs > > ops->map_page > > arm_iommu_map_page > > Heh, thankfully this is ARM specific, which presumably doesn't collide with > KVMGT. Actually, this is fine with KVMGT (owning to page by page access), isn't it? :) > > > __dma_page_cpu_to_dev > >dma_cache_maint_page > > > > Just a little worried about the condition of PFNs are contiguous > > while they belong to different backends, e.g. one from system memory and > > one from MMIO. > > But I don't know how to avoid this without complicated checks. > > And this condition might not happen in practice. > > IMO, assuming that contiguous pfns are vritually contiguous is wrong, i.e. > would > be a bug in the other code. The above dma_cache_maint_page() get's this > right, > and even has a well written comment to boot. Right.
Re: [Intel-gfx] [RESEND PATCH] drm/i915: constify pointers to hwmon_channel_info
Hi Krzysztof, On Thu, May 11, 2023 at 07:54:46PM +0200, Krzysztof Kozlowski wrote: > Statically allocated array of pointers to hwmon_channel_info can be made > const for safety. > > Acked-by: Jani Nikula > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Andi Shyti Andi
Re: [Intel-gfx] [PATCH] drm/i915/mtl: Fix expected reg value for Thunderbolt PLL disabling
Thank you for the patch and review. Merged the patch. - Radhakrishna(RK) Sripada > -Original Message- > From: Intel-gfx On Behalf Of Imre > Deak > Sent: Friday, May 12, 2023 7:12 AM > To: Kahola, Mika > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH] drm/i915/mtl: Fix expected reg value for > Thunderbolt PLL disabling > > On Fri, May 12, 2023 at 03:00:03PM +0300, Mika Kahola wrote: > > While disabling Thunderbolt PLL, we request PLL to be stopped and > > wait for ACK bit to be cleared. The expected value should be '0' > > instead of '~XELPDP_TBT_CLOCK_ACK' or otherwise we incorrectly > > receive dmesg warn "PHY PLL not unlocked in 10us". > > > > Signed-off-by: Mika Kahola > > Reviewed-by: Imre Deak > > > --- > > drivers/gpu/drm/i915/display/intel_cx0_phy.c | 4 +--- > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c > b/drivers/gpu/drm/i915/display/intel_cx0_phy.c > > index d94127e7448b..c64cf6778627 100644 > > --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c > > +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c > > @@ -2861,9 +2861,7 @@ static void intel_mtl_tbt_pll_disable(struct > intel_encoder *encoder) > > > > /* 3. Poll on PORT_CLOCK_CTL TBT CLOCK Ack == "0". */ > > if (__intel_de_wait_for_register(i915, > XELPDP_PORT_CLOCK_CTL(encoder->port), > > -XELPDP_TBT_CLOCK_ACK, > > -~XELPDP_TBT_CLOCK_ACK, > > -10, 0, NULL)) > > +XELPDP_TBT_CLOCK_ACK, 0, 10, 0, > NULL)) > > drm_warn(&i915->drm, "[ENCODER:%d:%s][%c] PHY PLL not > unlocked after 10us.\n", > > encoder->base.base.id, encoder->base.name, > phy_name(phy)); > > > > -- > > 2.34.1 > >
Re: [Intel-gfx] [PATCH v4 1/2] drm/i915/mtl: Add MTL performance tuning changes
Thank you for the reviews. Pushed the patches.
- Radhakrishna Sripada
> -Original Message-
> From: Sousa, Gustavo
> Sent: Wednesday, May 17, 2023 12:27 PM
> To: Sripada, Radhakrishna ; intel-
> g...@lists.freedesktop.org
> Cc: Justen, Jordan L ; Sripada, Radhakrishna
> ; Kalvala, Haridhar
> ; Roper, Matthew D
>
> Subject: Re: [PATCH v4 1/2] drm/i915/mtl: Add MTL performance tuning
> changes
>
> Quoting Radhakrishna Sripada (2023-05-16 21:40:45-03:00)
> >MTL reuses the tuning parameters for DG2. Extend the dg2
> >performance tuning parameters to MTL.
> >
> >v2: Add DRAW_WATERMARK tuning parameter.
> >v3: Limit DRAW_WATERMARK tuning to non A0 step.
> >v4: Reorder platform checks.
> >Restrict Blend fill caching optimization to Render GT.
> >
> >Bspec: 68331
> >Cc: Haridhar Kalvala
> >Cc: Matt Roper
> >Cc: Gustavo Sousa
> >Signed-off-by: Radhakrishna Sripada
> >---
> > drivers/gpu/drm/i915/gt/intel_workarounds.c | 15 ++-
> > 1 file changed, 14 insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> >index 786349e95487..b6d3185cf868 100644
> >--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> >+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> >@@ -817,6 +817,12 @@ static void mtl_ctx_workarounds_init(struct
> intel_engine_cs *engine,
> > {
> > struct drm_i915_private *i915 = engine->i915;
> >
> >+dg2_ctx_gt_tuning_init(engine, wal);
> >+
> >+if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_B0, STEP_FOREVER) ||
> >+IS_MTL_GRAPHICS_STEP(i915, P, STEP_B0, STEP_FOREVER))
> >+wa_add(wal, DRAW_WATERMARK, VERT_WM_VAL, 0x3FF, 0, false);
> >+
>
> I would put those (dg2_ctx_gt_tuning_init() call and DRAW_WATERMARK
> programming) in a separate mtl_ctx_gt_tuning_init() function. That would
> be more consistent with having tuning for context save/restore registers
> in separate functions and makes it easy to see this particular programming of
> DRAW_WATERMARK is a recommended tuning instead of a workaround.
>
> With that,
>
> Reviewed-by: Gustavo Sousa
>
> --
> Gustavo Sousa
>
> > if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_A0, STEP_B0) ||
> > IS_MTL_GRAPHICS_STEP(i915, P, STEP_A0, STEP_B0)) {
> > /* Wa_14014947963 */
> >@@ -1748,6 +1754,13 @@ xelpmp_gt_workarounds_init(struct intel_gt *gt,
> struct i915_wa_list *wal)
> > */
> > static void gt_tuning_settings(struct intel_gt *gt, struct i915_wa_list
> > *wal)
> > {
> >+if (IS_METEORLAKE(gt->i915)) {
> >+if (gt->type != GT_MEDIA)
> >+wa_mcr_write_or(wal, XEHP_L3SCQREG7,
> BLEND_FILL_CACHING_OPT_DIS);
> >+
> >+wa_mcr_write_or(wal, XEHP_SQCM, EN_32B_ACCESS);
> >+}
> >+
> > if (IS_PONTEVECCHIO(gt->i915)) {
> > wa_mcr_write(wal, XEHPC_L3SCRUB,
> > SCRUB_CL_DWNGRADE_SHARED |
> SCRUB_RATE_4B_PER_CLK);
> >@@ -2944,7 +2957,7 @@ static void
> > add_render_compute_tuning_settings(struct drm_i915_private *i915,
> >struct i915_wa_list *wal)
> > {
> >-if (IS_DG2(i915))
> >+if (IS_METEORLAKE(i915) || IS_DG2(i915))
> > wa_mcr_write_clr_set(wal, RT_CTRL, STACKID_CTRL,
> STACKID_CTRL_512);
> >
> > /*
> >--
> >2.34.1
> >
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for C20 Computed HDMI TMDS pixel clocks (rev3)
On Thu, 2023-05-18 at 19:31 +, Patchwork wrote:
> Patch Details
> Series: C20 Computed HDMI TMDS pixel clocks (rev3)
> URL: https://patchwork.freedesktop.org/series/117399/
> State:failure
> Details:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117399v3/index.html
> CI Bug Log - changes from CI_DRM_13164 -> Patchwork_117399v3
> Summary
> FAILURE
>
> Serious unknown changes coming with Patchwork_117399v3 absolutely need to be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_117399v3, 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_117399v3/index.html
>
> Participating hosts (39 -> 36)
> Missing (3): fi-kbl-soraka fi-snb-2520m fi-bsw-n3050
>
> Possible new issues
> Here are the unknown changes that may have been introduced in
> Patchwork_117399v3:
>
> IGT changes
> Possible regressions
> igt@kms_pipe_crc_basic@read-crc@pipe-c-edp-1:
> bat-adlp-6: PASS -> ABORT
Changes in this patch series not relevant to ADLP (v3) or ADLS (v2) platforms.
Series can
only cause regressions on MTL platform with C20 HDMI output.
-Clint
> Suppressed
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
>
> igt@i915_selftest@live@migrate:
> {bat-mtlp-8}: PASS -> DMESG-FAIL
> Known issues
> Here are the changes found in Patchwork_117399v3 that come from known issues:
>
> IGT changes
> Issues hit
> igt@i915_selftest@live@gt_engines:
>
> bat-atsm-1: PASS -> FAIL (i915#6268)
> igt@i915_selftest@live@gt_pm:
>
> bat-rpls-2: NOTRUN -> DMESG-FAIL (i915#4258 / i915#7913)
> igt@i915_selftest@live@requests:
>
> bat-rpls-2: NOTRUN -> ABORT (i915#7913 / i915#7982)
> Possible fixes
> igt@i915_selftest@live@gt_heartbeat:
>
> fi-glk-j4005: DMESG-FAIL (i915#5334) -> PASS
> igt@i915_selftest@live@gt_lrc:
>
> bat-rpls-2: INCOMPLETE (i915#4983 / i915#7913) -> PASS
> igt@i915_selftest@live@gt_mocs:
>
> {bat-mtlp-8}: DMESG-FAIL -> PASS
> igt@i915_suspend@basic-s3-without-i915:
>
> bat-adls-5: FAIL (fdo#103375) -> PASS +3 similar issues
> igt@kms_pipe_crc_basic@nonblocking-crc@pipe-c-dp-1:
>
> bat-dg2-8: FAIL (i915#7932) -> PASS
> igt@kms_pipe_crc_basic@read-crc@pipe-b-edp-1:
>
> bat-adlp-6: ABORT -> PASS
> Warnings
> igt@i915_selftest@live@requests:
>
> bat-rpls-1: ABORT (i915#7911 / i915#7920 / i915#7982) -> ABORT (i915#7911 /
> i915#7920)
> igt@kms_setmode@basic-clone-single-crtc:
>
> bat-rplp-1: SKIP (i915#3555 / i915#4579) -> ABORT (i915#4579 / i915#8260)
> {name}: This element is suppressed. This means it is ignored when computing
> the status of the difference (SUCCESS, WARNING, or FAILURE).
>
> Build changes
> Linux: CI_DRM_13164 -> Patchwork_117399v3
> CI-20190529: 20190529
> CI_DRM_13164: 30793067f161dfcbaca1b0249d919c9fc306754e @
> git://anongit.freedesktop.org/gfx-ci/linux
> IGT_7296: f58eaf30c30c1cc9f00c8b5c596ee5c94d054198 @
> https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
> Patchwork_117399v3: 30793067f161dfcbaca1b0249d919c9fc306754e @
> git://anongit.freedesktop.org/gfx-ci/linux
>
> Linux commits
> e2b63090a956 drm/i915/hdmi: C20 computed PLL frequencies
> 273769d73c7b drm/i915: Add 16bit register/mask operators
[Intel-gfx] ✗ Fi.CI.IGT: failure for HDCP Cleanup
== Series Details ==
Series: HDCP Cleanup
URL : https://patchwork.freedesktop.org/series/117938/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13162_full -> Patchwork_117938v1_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_117938v1_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_117938v1_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (7 -> 8)
--
Additional (1): shard-rkl0
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_117938v1_full:
### IGT changes ###
Possible regressions
* igt@kms_flip@flip-vs-suspend-interruptible@b-dp1:
- shard-apl: [PASS][1] -> [ABORT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13162/shard-apl2/igt@kms_flip@flip-vs-suspend-interrupti...@b-dp1.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117938v1/shard-apl1/igt@kms_flip@flip-vs-suspend-interrupti...@b-dp1.html
Known issues
Here are the changes found in Patchwork_117938v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-apl: [PASS][3] -> [FAIL][4] ([i915#2842])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13162/shard-apl6/igt@gem_exec_fair@basic-none-s...@rcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117938v1/shard-apl3/igt@gem_exec_fair@basic-none-s...@rcs0.html
* igt@gem_pread@exhaustion:
- shard-glk: NOTRUN -> [WARN][5] ([i915#2658])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117938v1/shard-glk6/igt@gem_pr...@exhaustion.html
* igt@kms_ccs@pipe-a-bad-aux-stride-y_tiled_gen12_rc_ccs_cc:
- shard-glk: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#3886]) +2
similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117938v1/shard-glk6/igt@kms_ccs@pipe-a-bad-aux-stride-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_chamelium_color@ctm-blue-to-red:
- shard-glk: NOTRUN -> [SKIP][7] ([fdo#109271]) +41 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117938v1/shard-glk6/igt@kms_chamelium_co...@ctm-blue-to-red.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-apl: [PASS][8] -> [FAIL][9] ([i915#2346])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13162/shard-apl4/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117938v1/shard-apl6/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
* igt@kms_flip@2x-flip-vs-dpms:
- shard-snb: NOTRUN -> [SKIP][10] ([fdo#109271]) +17 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117938v1/shard-snb7/igt@kms_f...@2x-flip-vs-dpms.html
* igt@kms_plane_alpha_blend@alpha-basic@pipe-c-hdmi-a-1:
- shard-glk: NOTRUN -> [FAIL][11] ([i915#7862]) +1 similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117938v1/shard-glk6/igt@kms_plane_alpha_blend@alpha-ba...@pipe-c-hdmi-a-1.html
*
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-5@pipe-b-vga-1:
- shard-snb: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4579]) +13
similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117938v1/shard-snb6/igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-...@pipe-b-vga-1.html
*
igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-25@pipe-c-hdmi-a-1:
- shard-glk: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#4579]) +3
similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117938v1/shard-glk6/igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0...@pipe-c-hdmi-a-1.html
* igt@kms_psr2_sf@cursor-plane-move-continuous-sf:
- shard-glk: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#658])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117938v1/shard-glk6/igt@kms_psr2...@cursor-plane-move-continuous-sf.html
Possible fixes
* igt@gem_barrier_race@remote-request@rcs0:
- shard-glk: [ABORT][15] ([i915#7461] / [i915#8211]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13162/shard-glk3/igt@gem_barrier_race@remote-requ...@rcs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117938v1/shard-glk6/igt@gem_barrier_race@remote-requ...@rcs0.html
* igt@gem_exec_endless@dispatch@vecs0:
- {shard-tglu}: [TIMEOUT][17] ([i915#3778]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13162/shard-tglu-4
Re: [Intel-gfx] [PATCH v5 09/10] vfio/pci: Extend VFIO_DEVICE_GET_PCI_HOT_RESET_INFO for vfio device cdev
On Thu, 18 May 2023 13:21:57 +
"Liu, Yi L" wrote:
> > From: Alex Williamson
> > Sent: Thursday, May 18, 2023 6:02 AM
> >
> > On Sat, 13 May 2023 06:21:35 -0700
> > Yi Liu wrote:
> >
> > > This makes VFIO_DEVICE_GET_PCI_HOT_RESET_INFO ioctl to use the
> > > iommufd_ctx
> >
> > s/makes/allows/?
> >
> > s/to//
> >
> > > of the cdev device to check the ownership of the other affected devices.
> > >
> > > This returns devid for each of the affected devices. If it is bound to the
> > > iommufd_ctx of the cdev device, _INFO reports a valid devid > 0; If it is
> > > not opened by the calling user, but it belongs to the same iommu_group of
> > > a device that is bound to the iommufd_ctx of the cdev device, reports
> > > devid
> > > value of 0; If the device is un-owned device, configured within a
> > > different
> > > iommufd, or opened outside of the vfio device cdev API, the _INFO ioctl
> > > shall
> > > report devid value of -1.
> > >
> > > devid >=0 doesn't block hot-reset as the affected devices are considered
> > > to
> > > be owned, while devid == -1 will block the use of
> > > VFIO_DEVICE_PCI_HOT_RESET
> > > outside of proof-of-ownership calling conventions (ie. via legacy group
> > > accessed devices).
> > >
> > > This adds flag VFIO_PCI_HOT_RESET_FLAG_DEV_ID to tell the user devid is
> > > returned in case of calling user get device fd from other software stack
> >
> > "other software stack"? I think this is trying to say something like:
> >
> > When VFIO_DEVICE_GET_PCI_HOT_RESET_INFO is called on an IOMMUFD
> > managed device, the new flag VFIO_PCI_HOT_RESET_FLAG_DEV_ID is
> > reported to indicate the values returned are IOMMUFD devids rather
> > than group IDs as used when accessing vfio devices through the
> > conventional vfio group interface. Additionally the flag
> > VFIO_PCI_HOT_RESET_FLAG_DEV_ID_OWNED will be reported in this mode if
> > all of the devices affected by the hot-reset are owned by either
> > virtue of being directly bound to the same iommufd context as the
> > calling device, or implicitly owned via a shared IOMMU group.
>
> Yes. it is.
>
> > > and adds flag VFIO_PCI_HOT_RESET_FLAG_DEV_ID_OWNED to tell user if all
> > > the affected devices are owned, so user can know it without looping all
> > > the returned devids.
> > >
> > > Suggested-by: Jason Gunthorpe
> > > Suggested-by: Alex Williamson
> > > Signed-off-by: Yi Liu
> > > ---
> > > drivers/vfio/pci/vfio_pci_core.c | 52 ++--
> > > include/uapi/linux/vfio.h| 46 +++-
> > > 2 files changed, 95 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/vfio/pci/vfio_pci_core.c
> > > b/drivers/vfio/pci/vfio_pci_core.c
> > > index 4df2def35bdd..57586be770af 100644
> > > --- a/drivers/vfio/pci/vfio_pci_core.c
> > > +++ b/drivers/vfio/pci/vfio_pci_core.c
> > > @@ -27,6 +27,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #if IS_ENABLED(CONFIG_EEH)
> > > #include
> > > #endif
> > > @@ -36,6 +37,10 @@
> > > #define DRIVER_AUTHOR "Alex Williamson "
> > > #define DRIVER_DESC "core driver for VFIO based PCI devices"
> > >
> > > +#ifdef CONFIG_IOMMUFD
> > > +MODULE_IMPORT_NS(IOMMUFD);
> > > +#endif
> > > +
> > > static bool nointxmask;
> > > static bool disable_vga;
> > > static bool disable_idle_d3;
> > > @@ -776,6 +781,9 @@ struct vfio_pci_fill_info {
> > > int max;
> > > int cur;
> > > struct vfio_pci_dependent_device *devices;
> > > + struct vfio_device *vdev;
> > > + bool devid:1;
> > > + bool dev_owned:1;
> > > };
> > >
> > > static int vfio_pci_fill_devs(struct pci_dev *pdev, void *data)
> > > @@ -790,7 +798,37 @@ static int vfio_pci_fill_devs(struct pci_dev *pdev,
> > > void *data)
> > > if (!iommu_group)
> > > return -EPERM; /* Cannot reset non-isolated devices */
> > >
> > > - fill->devices[fill->cur].group_id = iommu_group_id(iommu_group);
> > > + if (fill->devid) {
> > > + struct iommufd_ctx *iommufd =
> > > vfio_iommufd_physical_ictx(fill->vdev);
> > > + struct vfio_device_set *dev_set = fill->vdev->dev_set;
> > > + struct vfio_device *vdev;
> > > +
> > > + /*
> > > + * Report devid for the affected devices:
> > > + * - valid devid > 0 for the devices that are bound with
> > > + * the iommufd of the calling device.
> > > + * - devid == 0 for the devices that have not been opened
> > > + * but have same group with one of the devices bound to
> > > + * the iommufd of the calling device.
> > > + * - devid == -1 for others, and clear dev_owned flag.
> > > + */
> > > + vdev = vfio_find_device_in_devset(dev_set, &pdev->dev);
> > > + if (vdev && iommufd == vfio_iommufd_physical_ictx(vdev)) {
> > > + int ret;
> > > +
> > > + ret = vfio_iommufd_physical_devid(vdev);
> > > + if (WARN_ON
Re: [Intel-gfx] [PATCH v5 09/10] vfio/pci: Extend VFIO_DEVICE_GET_PCI_HOT_RESET_INFO for vfio device cdev
On Thu, 18 May 2023 13:31:47 +
"Liu, Yi L" wrote:
> > From: Liu, Yi L
> > Sent: Thursday, May 18, 2023 9:22 PM
> >
> > > From: Alex Williamson
> > > Sent: Thursday, May 18, 2023 6:02 AM
> > >
> > > On Sat, 13 May 2023 06:21:35 -0700
> > > Yi Liu wrote:
>
> > >
> > > static int vfio_hot_reset_devid(struct vfio_device *vdev,
> > > struct iommufd_ctx *iommufd_ctx)
> > > {
> > > struct iommu_group *group;
> > > int devid;
> > >
> > > if (!vdev)
> > > return VFIO_PCI_DEVID_NOT_OWNED;
> > >
> > > if (vfio_iommufd_physical_ictx(vdev) == iommufd_ctx)
> > > return vfio_iommufd_physical_devid(vdev);
>
> Do we need to check the return of this helper? It returns -EINVAL
> when iommufd_access and iommufd_device are both null. Though
> not possible in this path. Is a WARN_ON needed or not?
I also came to the conclusion that it wasn't possible while reviewing
the code. I wouldn't got to extreme measures to introduce paranoia
checks for impossible conditions. Thanks,
Alex
> > >
> > > group = iommu_group_get(vdev->dev);
> > > if (!group)
> > > return VFIO_PCI_DEVID_NOT_OWNED;
> > >
> > > if (iommufd_ctx_has_group(iommufd_ctx, group))
> > > devid = VFIO_PCI_DEVID_OWNED;
> > >
> > > iommu_group_put(group);
> > >
> > > return devid;
> > > }
Re: [Intel-gfx] [PATCH v5 06/10] vfio-iommufd: Add helper to retrieve iommufd_ctx and devid for vfio_device
On Thu, 18 May 2023 13:25:59 +
"Liu, Yi L" wrote:
> > From: Alex Williamson
> > Sent: Thursday, May 18, 2023 2:15 AM
> >
> > On Sat, 13 May 2023 06:21:32 -0700
> > Yi Liu wrote:
> >
> > > This is needed by the vfio-pci driver to report affected devices in the
> > > hot reset for a given device.
> > >
> > > Signed-off-by: Yi Liu
> > > ---
> > > drivers/iommu/iommufd/device.c | 24
> > > drivers/vfio/iommufd.c | 20
> > > include/linux/iommufd.h| 6 ++
> > > include/linux/vfio.h | 14 ++
> > > 4 files changed, 64 insertions(+)
> > >
> > > diff --git a/drivers/iommu/iommufd/device.c
> > > b/drivers/iommu/iommufd/device.c
> > > index 4f9b2142274c..81466b97023f 100644
> > > --- a/drivers/iommu/iommufd/device.c
> > > +++ b/drivers/iommu/iommufd/device.c
> > > @@ -116,6 +116,18 @@ void iommufd_device_unbind(struct iommufd_device
> > > *idev)
> > > }
> > > EXPORT_SYMBOL_NS_GPL(iommufd_device_unbind, IOMMUFD);
> > >
> > > +struct iommufd_ctx *iommufd_device_to_ictx(struct iommufd_device *idev)
> > > +{
> > > + return idev->ictx;
> > > +}
> > > +EXPORT_SYMBOL_NS_GPL(iommufd_device_to_ictx, IOMMUFD);
> > > +
> > > +u32 iommufd_device_to_id(struct iommufd_device *idev)
> > > +{
> > > + return idev->obj.id;
> > > +}
> > > +EXPORT_SYMBOL_NS_GPL(iommufd_device_to_id, IOMMUFD);
> > > +
> > > static int iommufd_device_setup_msi(struct iommufd_device *idev,
> > > struct iommufd_hw_pagetable *hwpt,
> > > phys_addr_t sw_msi_start)
> > > @@ -463,6 +475,18 @@ void iommufd_access_destroy(struct iommufd_access
> > *access)
> > > }
> > > EXPORT_SYMBOL_NS_GPL(iommufd_access_destroy, IOMMUFD);
> > >
> > > +struct iommufd_ctx *iommufd_access_to_ictx(struct iommufd_access *access)
> > > +{
> > > + return access->ictx;
> > > +}
> > > +EXPORT_SYMBOL_NS_GPL(iommufd_access_to_ictx, IOMMUFD);
> > > +
> > > +u32 iommufd_access_to_id(struct iommufd_access *access)
> > > +{
> > > + return access->obj.id;
> > > +}
> > > +EXPORT_SYMBOL_NS_GPL(iommufd_access_to_id, IOMMUFD);
> > > +
> > > int iommufd_access_attach(struct iommufd_access *access, u32 ioas_id)
> > > {
> > > struct iommufd_ioas *new_ioas;
> > > diff --git a/drivers/vfio/iommufd.c b/drivers/vfio/iommufd.c
> > > index c1379e826052..a18e920be164 100644
> > > --- a/drivers/vfio/iommufd.c
> > > +++ b/drivers/vfio/iommufd.c
> > > @@ -105,6 +105,26 @@ void vfio_iommufd_unbind(struct vfio_device *vdev)
> > > vdev->ops->unbind_iommufd(vdev);
> > > }
> > >
> > > +struct iommufd_ctx *vfio_iommufd_physical_ictx(struct vfio_device *vdev)
> > > +{
> > > + if (vdev->iommufd_device)
> > > + return iommufd_device_to_ictx(vdev->iommufd_device);
> > > + if (vdev->noiommu_access)
> > > + return iommufd_access_to_ictx(vdev->noiommu_access);
> > > + return NULL;
> > > +}
> > > +EXPORT_SYMBOL_GPL(vfio_iommufd_physical_ictx);
> > > +
> > > +int vfio_iommufd_physical_devid(struct vfio_device *vdev)
> > > +{
> > > + if (vdev->iommufd_device)
> > > + return iommufd_device_to_id(vdev->iommufd_device);
> > > + if (vdev->noiommu_access)
> > > + return iommufd_access_to_id(vdev->noiommu_access);
> > > + return -EINVAL;
> > > +}
> > > +EXPORT_SYMBOL_GPL(vfio_iommufd_physical_devid);
> >
> > I think these exemplify that it would be better if both emulated and
> > noiommu use the same iommufd_access pointer. Thanks,
>
> Sure. Then I shall rename this helper. vfio_iommufd_device_devid()
> What about your opinion?
Yes, it really didn't even occur to me that "physical" in the name was
meant to suggest this shouldn't be used for emulated mdev devices. It
should work for all devices and using a shared iommufd access pointer
between noiommu and emulated should simplify that somewhat. Thanks,
Alex
Re: [Intel-gfx] [PATCH v5 07/10] vfio: Add helper to search vfio_device in a dev_set
On Thu, 18 May 2023 12:31:07 +
"Liu, Yi L" wrote:
> > From: Alex Williamson
> > Sent: Thursday, May 18, 2023 3:13 AM
> >
> > On Sat, 13 May 2023 06:21:33 -0700
> > Yi Liu wrote:
> >
> > > There are drivers that need to search vfio_device within a given dev_set.
> > > e.g. vfio-pci. So add a helper.
> > >
> > > Signed-off-by: Yi Liu
> > > ---
> > > drivers/vfio/pci/vfio_pci_core.c | 8 +++-
> > > drivers/vfio/vfio_main.c | 15 +++
> > > include/linux/vfio.h | 3 +++
> > > 3 files changed, 21 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/vfio/pci/vfio_pci_core.c
> > > b/drivers/vfio/pci/vfio_pci_core.c
> > > index 39e7823088e7..4df2def35bdd 100644
> > > --- a/drivers/vfio/pci/vfio_pci_core.c
> > > +++ b/drivers/vfio/pci/vfio_pci_core.c
> > > @@ -2335,12 +2335,10 @@ static bool vfio_dev_in_groups(struct
> > vfio_pci_core_device *vdev,
> > > static int vfio_pci_is_device_in_set(struct pci_dev *pdev, void *data)
> > > {
> > > struct vfio_device_set *dev_set = data;
> > > - struct vfio_device *cur;
> > >
> > > - list_for_each_entry(cur, &dev_set->device_list, dev_set_list)
> > > - if (cur->dev == &pdev->dev)
> > > - return 0;
> > > - return -EBUSY;
> > > + lockdep_assert_held(&dev_set->lock);
> > > +
> > > + return vfio_find_device_in_devset(dev_set, &pdev->dev) ? 0 : -EBUSY;
> >
> > Maybe an opportunity to revisit why this returns -EBUSY rather than
> > something reasonable like -ENODEV. It looks like we picked up the
> > -EBUSY in a882c16a2b7e where I think it was trying to preserve the
> > return of vfio_pci_try_zap_and_vma_lock_cb() but the return value here
> > is not even propagated so this looks like an chance to have it make
> > sense again. Thanks,
>
> From the name of this function, yes, -ENODEV is better. is it
> Ok to modify it to be -ENODEV in this patch or a separate one?
This patch is fine so long as it's noted in the commit log. Thanks,
Alex
> > > }
> > >
> > > /*
> > > diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
> > > index f0ca33b2e1df..ab4f3a794f78 100644
> > > --- a/drivers/vfio/vfio_main.c
> > > +++ b/drivers/vfio/vfio_main.c
> > > @@ -141,6 +141,21 @@ unsigned int vfio_device_set_open_count(struct
> > vfio_device_set *dev_set)
> > > }
> > > EXPORT_SYMBOL_GPL(vfio_device_set_open_count);
> > >
> > > +struct vfio_device *
> > > +vfio_find_device_in_devset(struct vfio_device_set *dev_set,
> > > +struct device *dev)
> > > +{
> > > + struct vfio_device *cur;
> > > +
> > > + lockdep_assert_held(&dev_set->lock);
> > > +
> > > + list_for_each_entry(cur, &dev_set->device_list, dev_set_list)
> > > + if (cur->dev == dev)
> > > + return cur;
> > > + return NULL;
> > > +}
> > > +EXPORT_SYMBOL_GPL(vfio_find_device_in_devset);
> > > +
> > > /*
> > > * Device objects - create, release, get, put, search
> > > */
> > > diff --git a/include/linux/vfio.h b/include/linux/vfio.h
> > > index fcbe084b18c8..4c17395ed4d2 100644
> > > --- a/include/linux/vfio.h
> > > +++ b/include/linux/vfio.h
> > > @@ -259,6 +259,9 @@ void vfio_unregister_group_dev(struct vfio_device
> > > *device);
> > >
> > > int vfio_assign_device_set(struct vfio_device *device, void *set_id);
> > > unsigned int vfio_device_set_open_count(struct vfio_device_set *dev_set);
> > > +struct vfio_device *
> > > +vfio_find_device_in_devset(struct vfio_device_set *dev_set,
> > > +struct device *dev);
> > >
> > > int vfio_mig_get_next_state(struct vfio_device *device,
> > > enum vfio_device_mig_state cur_fsm,
>
Re: [Intel-gfx] [PATCH v5 01/10] vfio-iommufd: Create iommufd_access for noiommu devices
On Thu, 18 May 2023 12:23:29 + "Liu, Yi L" wrote: > > From: Jason Gunthorpe > > Sent: Thursday, May 18, 2023 2:21 AM > > > > On Wed, May 17, 2023 at 11:26:09AM -0600, Alex Williamson wrote: > > > > > It's not clear to me why we need a separate iommufd_access for > > > noiommu. > > > > The point was to allocate an ID for the device so we can use that ID > > with the other interfaces in all cases. > > I guess Alex's question is why adding a new pointer named noiommu_access > while there is already the iommufd_access pointer named iommufd_access. Yes, precisely. Sorry that was confusing, we need the access for noiommu but it's not clear why that access needs to be stored in a separate pointer when we can already differentiate noiommu devices otherwise. Thanks, Alex
[Intel-gfx] ✗ Fi.CI.BAT: failure for C20 Computed HDMI TMDS pixel clocks (rev3)
== Series Details ==
Series: C20 Computed HDMI TMDS pixel clocks (rev3)
URL : https://patchwork.freedesktop.org/series/117399/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13164 -> Patchwork_117399v3
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_117399v3 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_117399v3, 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_117399v3/index.html
Participating hosts (39 -> 36)
--
Missing(3): fi-kbl-soraka fi-snb-2520m fi-bsw-n3050
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_117399v3:
### IGT changes ###
Possible regressions
* igt@kms_pipe_crc_basic@read-crc@pipe-c-edp-1:
- bat-adlp-6: [PASS][1] -> [ABORT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13164/bat-adlp-6/igt@kms_pipe_crc_basic@read-...@pipe-c-edp-1.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117399v3/bat-adlp-6/igt@kms_pipe_crc_basic@read-...@pipe-c-edp-1.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@migrate:
- {bat-mtlp-8}: [PASS][3] -> [DMESG-FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13164/bat-mtlp-8/igt@i915_selftest@l...@migrate.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117399v3/bat-mtlp-8/igt@i915_selftest@l...@migrate.html
Known issues
Here are the changes found in Patchwork_117399v3 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@gt_engines:
- bat-atsm-1: [PASS][5] -> [FAIL][6] ([i915#6268])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13164/bat-atsm-1/igt@i915_selftest@live@gt_engines.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117399v3/bat-atsm-1/igt@i915_selftest@live@gt_engines.html
* igt@i915_selftest@live@gt_pm:
- bat-rpls-2: NOTRUN -> [DMESG-FAIL][7] ([i915#4258] / [i915#7913])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117399v3/bat-rpls-2/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@requests:
- bat-rpls-2: NOTRUN -> [ABORT][8] ([i915#7913] / [i915#7982])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117399v3/bat-rpls-2/igt@i915_selftest@l...@requests.html
Possible fixes
* igt@i915_selftest@live@gt_heartbeat:
- fi-glk-j4005: [DMESG-FAIL][9] ([i915#5334]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13164/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117399v3/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@gt_lrc:
- bat-rpls-2: [INCOMPLETE][11] ([i915#4983] / [i915#7913]) ->
[PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13164/bat-rpls-2/igt@i915_selftest@live@gt_lrc.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117399v3/bat-rpls-2/igt@i915_selftest@live@gt_lrc.html
* igt@i915_selftest@live@gt_mocs:
- {bat-mtlp-8}: [DMESG-FAIL][13] -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13164/bat-mtlp-8/igt@i915_selftest@live@gt_mocs.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117399v3/bat-mtlp-8/igt@i915_selftest@live@gt_mocs.html
* igt@i915_suspend@basic-s3-without-i915:
- bat-adls-5: [FAIL][15] ([fdo#103375]) -> [PASS][16] +3 similar
issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13164/bat-adls-5/igt@i915_susp...@basic-s3-without-i915.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117399v3/bat-adls-5/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_pipe_crc_basic@nonblocking-crc@pipe-c-dp-1:
- bat-dg2-8: [FAIL][17] ([i915#7932]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13164/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-c-dp-1.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117399v3/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-c-dp-1.html
* igt@kms_pipe_crc_basic@read-crc@pipe-b-edp-1:
- bat-adlp-6: [ABORT][19] -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13164/bat-adlp-6/igt@kms_pipe_crc_basic@read-...@pipe-b-edp-1.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117399v3/bat-adlp-6/igt@kms_pipe_crc_basic@read-...@pipe-b-edp-1.html
Warnings
* igt@
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for C20 Computed HDMI TMDS pixel clocks (rev3)
== Series Details == Series: C20 Computed HDMI TMDS pixel clocks (rev3) URL : https://patchwork.freedesktop.org/series/117399/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for C20 Computed HDMI TMDS pixel clocks (rev3)
== Series Details == Series: C20 Computed HDMI TMDS pixel clocks (rev3) URL : https://patchwork.freedesktop.org/series/117399/ State : warning == Summary == Error: dim checkpatch failed eb47be209dd5 drm/i915: Add 16bit register/mask operators -:29: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__n' - possible side-effects? #29: FILE: drivers/gpu/drm/i915/i915_reg_defs.h:155: +#define REG_BIT16(__n) \ + ((u16)(BIT(__n) +\ + BUILD_BUG_ON_ZERO(__is_constexpr(__n) && \ +((__n) < 0 || (__n) > 15 -:44: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__high' - possible side-effects? #44: FILE: drivers/gpu/drm/i915/i915_reg_defs.h:170: +#define REG_GENMASK16(__high, __low) \ + ((u16)(GENMASK(__high, __low) + \ + BUILD_BUG_ON_ZERO(__is_constexpr(__high) && \ +__is_constexpr(__low) && \ +((__low) < 0 || (__high) > 15 || (__low) > (__high) -:44: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__low' - possible side-effects? #44: FILE: drivers/gpu/drm/i915/i915_reg_defs.h:170: +#define REG_GENMASK16(__high, __low) \ + ((u16)(GENMASK(__high, __low) + \ + BUILD_BUG_ON_ZERO(__is_constexpr(__high) && \ +__is_constexpr(__low) && \ +((__low) < 0 || (__high) > 15 || (__low) > (__high) -:61: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__mask' - possible side-effects? #61: FILE: drivers/gpu/drm/i915/i915_reg_defs.h:187: +#define REG_FIELD_PREP16(__mask, __val) \ + ((u16)typeof(__mask))(__val) << __bf_shf(__mask)) & (__mask)) + \ + BUILD_BUG_ON_ZERO(!__is_constexpr(__mask)) + \ + BUILD_BUG_ON_ZERO((__mask) == 0 || (__mask) > U16_MAX) + \ + BUILD_BUG_ON_ZERO(!IS_POWER_OF_2((__mask) + (1ULL << __bf_shf(__mask + \ + BUILD_BUG_ON_ZERO(__builtin_choose_expr(__is_constexpr(__val), (~((__mask) >> __bf_shf(__mask)) & (__val)), 0 -:61: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__val' - possible side-effects? #61: FILE: drivers/gpu/drm/i915/i915_reg_defs.h:187: +#define REG_FIELD_PREP16(__mask, __val) \ + ((u16)typeof(__mask))(__val) << __bf_shf(__mask)) & (__mask)) + \ + BUILD_BUG_ON_ZERO(!__is_constexpr(__mask)) + \ + BUILD_BUG_ON_ZERO((__mask) == 0 || (__mask) > U16_MAX) + \ + BUILD_BUG_ON_ZERO(!IS_POWER_OF_2((__mask) + (1ULL << __bf_shf(__mask + \ + BUILD_BUG_ON_ZERO(__builtin_choose_expr(__is_constexpr(__val), (~((__mask) >> __bf_shf(__mask)) & (__val)), 0 -:66: WARNING:LONG_LINE: line length of 128 exceeds 100 columns #66: FILE: drivers/gpu/drm/i915/i915_reg_defs.h:192: + BUILD_BUG_ON_ZERO(__builtin_choose_expr(__is_constexpr(__val), (~((__mask) >> __bf_shf(__mask)) & (__val)), 0 total: 0 errors, 1 warnings, 5 checks, 54 lines checked c95baea0d04b drm/i915/hdmi: C20 computed PLL frequencies -:59: WARNING:LONG_LINE: line length of 101 exceeds 100 columns #59: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:1932: + mpll_div_multiplier = min_t(u8, div64_u64((vco_freq * 16 + (datarate >> 1)), datarate), 255); total: 0 errors, 1 warnings, 0 checks, 177 lines checked
[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [CI,DO_NOT_MERGE,1/3] drm/i915/mtl: do not enable render power-gating on MTL (rev2)
== Series Details == Series: series starting with [CI,DO_NOT_MERGE,1/3] drm/i915/mtl: do not enable render power-gating on MTL (rev2) URL : https://patchwork.freedesktop.org/series/117912/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/117912/revisions/2/mbox/ not applied Applying: drm/i915/mtl: do not enable render power-gating on MTL Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/gt/intel_rc6.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/gt/intel_rc6.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/gt/intel_rc6.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/mtl: do not enable render power-gating on MTL 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". Build failed, no error log produced
Re: [Intel-gfx] [PATCH v3 03/28] drm/i915/gvt: Verify hugepages are contiguous in physical address space
On Thu, May 18, 2023, Yan Zhao wrote: > On Wed, May 17, 2023 at 07:50:26AM -0700, Sean Christopherson wrote: > > On Tue, May 16, 2023, Yan Zhao wrote: > > > hi Sean > > > > > > Do you think it's necessary to double check that struct page pointers > > > are also contiguous? > > > > No, the virtual address space should be irrelevant. The only way it would > > be > > problematic is if something in dma_map_page() expected to be able to access > > the > > entire chunk of memory by getting the virtual address of only the first > > page, > > but I can't imagine that code is reading or writing memory, let alone doing > > so > > across a huge range of memory. > Yes, I do find arm_iommu version of dma_map_page() access the memory by > getting > virtual address of pages passed in, but it's implemented as page by page, not > only > from the first page. > > dma_map_page > dma_map_page_attrs > ops->map_page > arm_iommu_map_page Heh, thankfully this is ARM specific, which presumably doesn't collide with KVMGT. > __dma_page_cpu_to_dev >dma_cache_maint_page > > Just a little worried about the condition of PFNs are contiguous > while they belong to different backends, e.g. one from system memory and > one from MMIO. > But I don't know how to avoid this without complicated checks. > And this condition might not happen in practice. IMO, assuming that contiguous pfns are vritually contiguous is wrong, i.e. would be a bug in the other code. The above dma_cache_maint_page() get's this right, and even has a well written comment to boot.
Re: [Intel-gfx] [PATCH v2] drm/i915/mtl: do not enable render power-gating on MTL
On 18.05.2023 18:11, Rodrigo Vivi wrote: On Thu, May 18, 2023 at 05:33:55PM +0200, Andrzej Hajda wrote: On 18.05.2023 17:09, Rodrigo Vivi wrote: On Thu, May 18, 2023 at 04:50:52PM +0200, Andrzej Hajda wrote: Multiple CI tests fails with forcewake ack timeouts if render power gating is enabled. BSpec 52698 states it should be 0 for MTL, but apparently this info is outdated. Anyway since the patch makes MTL pass basic tests added FIXME tag informing this is temporary workaround. v2: added FIXME tag Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4983 No change in the patch is needed, but do we have another (can be internal) ticket with the work to get this properly fix without wasting power? Yes there are jiras and related hsdes. In fact this tag is not fully correct, as the issue is about MTL and RPL. I wanted to use "References:" tag but "dim checkpatch" complains, so I have ended with Closes. Regarding your "No change in the patch is needed", do you prefer to merge v1 or v2? please go ahead with the v2 Pushed to drm-intel-gt-next Thx Andrzej [1]: Regards Andrzej Signed-off-by: Andrzej Hajda Reviewed-by: Nirmoy Das Reviewed-by: Rodrigo Vivi Reviewed-by: Andi Shyti --- Changes in v2: - added FIXME tag - Link to v1: https://lore.kernel.org/r/20230517-mtl_disable_render_pg-v1-1-6495eebbf...@intel.com --- drivers/gpu/drm/i915/gt/intel_rc6.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.c b/drivers/gpu/drm/i915/gt/intel_rc6.c index 908a3d0f2343f4..58bb1c55294c93 100644 --- a/drivers/gpu/drm/i915/gt/intel_rc6.c +++ b/drivers/gpu/drm/i915/gt/intel_rc6.c @@ -117,8 +117,14 @@ static void gen11_rc6_enable(struct intel_rc6 *rc6) GEN6_RC_CTL_RC6_ENABLE | GEN6_RC_CTL_EI_MODE(1); - /* Wa_16011777198 - Render powergating must remain disabled */ - if (IS_DG2_GRAPHICS_STEP(gt->i915, G10, STEP_A0, STEP_C0) || + /* +* Wa_16011777198 and BSpec 52698 - Render powergating must be off. +* FIXME BSpec is outdated, disabling powergating for MTL is just +* temporary wa and should be removed after fixing real cause +* of forcewake timeouts. +*/ + if (IS_METEORLAKE(gt->i915) || + IS_DG2_GRAPHICS_STEP(gt->i915, G10, STEP_A0, STEP_C0) || IS_DG2_GRAPHICS_STEP(gt->i915, G11, STEP_A0, STEP_B0)) pg_enable = GEN9_MEDIA_PG_ENABLE | --- base-commit: 641646b29337c97681e0edb67ad2e08aef3fb850 change-id: 20230517-mtl_disable_render_pg-b9f9f1567f9e Best regards, -- Andrzej Hajda
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/mtl: do not enable render power-gating on MTL (rev3)
== Series Details ==
Series: drm/i915/mtl: do not enable render power-gating on MTL (rev3)
URL : https://patchwork.freedesktop.org/series/117883/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13163 -> Patchwork_117883v3
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_117883v3 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_117883v3, 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_117883v3/index.html
Participating hosts (37 -> 37)
--
Additional (1): bat-adlp-6
Missing(1): fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_117883v3:
### IGT changes ###
Possible regressions
* igt@kms_pipe_crc_basic@read-crc@pipe-b-edp-1:
- bat-adlp-6: NOTRUN -> [ABORT][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117883v3/bat-adlp-6/igt@kms_pipe_crc_basic@read-...@pipe-b-edp-1.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@gt_mocs:
- {bat-mtlp-8}: [PASS][2] -> [DMESG-FAIL][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13163/bat-mtlp-8/igt@i915_selftest@live@gt_mocs.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117883v3/bat-mtlp-8/igt@i915_selftest@live@gt_mocs.html
Known issues
Here are the changes found in Patchwork_117883v3 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@basic-hwmon:
- bat-adlp-6: NOTRUN -> [SKIP][4] ([i915#7456])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117883v3/bat-adlp-6/igt@debugfs_t...@basic-hwmon.html
* igt@gem_tiled_pread_basic:
- bat-adlp-6: NOTRUN -> [SKIP][5] ([i915#3282])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117883v3/bat-adlp-6/igt@gem_tiled_pread_basic.html
* igt@i915_selftest@live@gt_engines:
- bat-atsm-1: [PASS][6] -> [FAIL][7] ([i915#6268])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13163/bat-atsm-1/igt@i915_selftest@live@gt_engines.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117883v3/bat-atsm-1/igt@i915_selftest@live@gt_engines.html
* igt@i915_selftest@live@hangcheck:
- bat-adls-5: [PASS][8] -> [DMESG-WARN][9] ([i915#5591])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13163/bat-adls-5/igt@i915_selftest@l...@hangcheck.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117883v3/bat-adls-5/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@slpc:
- bat-rpls-2: [PASS][10] -> [DMESG-WARN][11] ([i915#6367])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13163/bat-rpls-2/igt@i915_selftest@l...@slpc.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117883v3/bat-rpls-2/igt@i915_selftest@l...@slpc.html
* igt@kms_chamelium_hpd@dp-hpd-fast:
- bat-adlp-6: NOTRUN -> [SKIP][12] ([i915#7828]) +7 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117883v3/bat-adlp-6/igt@kms_chamelium_...@dp-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-adlp-6: NOTRUN -> [SKIP][13] ([i915#4103]) +1 similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117883v3/bat-adlp-6/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@kms_force_connector_basic@force-load-detect:
- bat-adlp-6: NOTRUN -> [SKIP][14] ([fdo#109285])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117883v3/bat-adlp-6/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-c-dp-1:
- bat-dg2-8: [PASS][15] -> [FAIL][16] ([i915#7932]) +1 similar
issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13163/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-c-dp-1.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117883v3/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-c-dp-1.html
* igt@kms_pipe_crc_basic@read-crc:
- bat-dg2-11: NOTRUN -> [SKIP][17] ([i915#1845] / [i915#5354]) +1
similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117883v3/bat-dg2-11/igt@kms_pipe_crc_ba...@read-crc.html
* igt@kms_psr@primary_mmap_gtt:
- bat-rplp-1: NOTRUN -> [SKIP][18] ([i915#1072])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117883v3/bat-rplp-1/igt@kms_psr@primary_mmap_gtt.html
*
Re: [Intel-gfx] [PATCH v2] drm/i915/mtl: do not enable render power-gating on MTL
On Thu, May 18, 2023 at 05:33:55PM +0200, Andrzej Hajda wrote: > > > On 18.05.2023 17:09, Rodrigo Vivi wrote: > > On Thu, May 18, 2023 at 04:50:52PM +0200, Andrzej Hajda wrote: > > > Multiple CI tests fails with forcewake ack timeouts if render > > > power gating is enabled. > > > BSpec 52698 states it should be 0 for MTL, but apparently > > > this info is outdated. Anyway since the patch makes MTL pass basic > > > tests added FIXME tag informing this is temporary workaround. > > > > > > v2: added FIXME tag > > > > > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4983 > > No change in the patch is needed, but do we have another > > (can be internal) ticket with the work to get this properly > > fix without wasting power? > > Yes there are jiras and related hsdes. In fact this tag is not fully > correct, as the issue is about MTL and RPL. I wanted to use "References:" > tag but "dim checkpatch" complains, so I have ended with Closes. > Regarding your "No change in the patch is needed", do you prefer to merge v1 > or v2? please go ahead with the v2 > > [1]: > Regards > Andrzej > > > > > > Signed-off-by: Andrzej Hajda > > > Reviewed-by: Nirmoy Das > > > Reviewed-by: Rodrigo Vivi > > > Reviewed-by: Andi Shyti > > > --- > > > Changes in v2: > > > - added FIXME tag > > > - Link to v1: > > > https://lore.kernel.org/r/20230517-mtl_disable_render_pg-v1-1-6495eebbf...@intel.com > > > --- > > > drivers/gpu/drm/i915/gt/intel_rc6.c | 10 -- > > > 1 file changed, 8 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.c > > > b/drivers/gpu/drm/i915/gt/intel_rc6.c > > > index 908a3d0f2343f4..58bb1c55294c93 100644 > > > --- a/drivers/gpu/drm/i915/gt/intel_rc6.c > > > +++ b/drivers/gpu/drm/i915/gt/intel_rc6.c > > > @@ -117,8 +117,14 @@ static void gen11_rc6_enable(struct intel_rc6 *rc6) > > > GEN6_RC_CTL_RC6_ENABLE | > > > GEN6_RC_CTL_EI_MODE(1); > > > - /* Wa_16011777198 - Render powergating must remain disabled */ > > > - if (IS_DG2_GRAPHICS_STEP(gt->i915, G10, STEP_A0, STEP_C0) || > > > + /* > > > + * Wa_16011777198 and BSpec 52698 - Render powergating must be off. > > > + * FIXME BSpec is outdated, disabling powergating for MTL is just > > > + * temporary wa and should be removed after fixing real cause > > > + * of forcewake timeouts. > > > + */ > > > + if (IS_METEORLAKE(gt->i915) || > > > + IS_DG2_GRAPHICS_STEP(gt->i915, G10, STEP_A0, STEP_C0) || > > > IS_DG2_GRAPHICS_STEP(gt->i915, G11, STEP_A0, STEP_B0)) > > > pg_enable = > > > GEN9_MEDIA_PG_ENABLE | > > > > > > --- > > > base-commit: 641646b29337c97681e0edb67ad2e08aef3fb850 > > > change-id: 20230517-mtl_disable_render_pg-b9f9f1567f9e > > > > > > Best regards, > > > -- > > > Andrzej Hajda > > > >
[Intel-gfx] ✓ Fi.CI.IGT: success for i915: Move display identification/probing under display/
== Series Details ==
Series: i915: Move display identification/probing under display/
URL : https://patchwork.freedesktop.org/series/117931/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13162_full -> Patchwork_117931v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 8)
--
Additional (1): shard-rkl0
Known issues
Here are the changes found in Patchwork_117931v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_barrier_race@remote-request@rcs0:
- shard-apl: [PASS][1] -> [ABORT][2] ([i915#7461] / [i915#8190])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13162/shard-apl2/igt@gem_barrier_race@remote-requ...@rcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117931v1/shard-apl3/igt@gem_barrier_race@remote-requ...@rcs0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][3] -> [FAIL][4] ([i915#2842])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13162/shard-glk5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117931v1/shard-glk6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_pread@exhaustion:
- shard-glk: NOTRUN -> [WARN][5] ([i915#2658])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117931v1/shard-glk4/igt@gem_pr...@exhaustion.html
* igt@gen9_exec_parse@allowed-single:
- shard-apl: [PASS][6] -> [ABORT][7] ([i915#5566])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13162/shard-apl4/igt@gen9_exec_pa...@allowed-single.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117931v1/shard-apl7/igt@gen9_exec_pa...@allowed-single.html
* igt@kms_ccs@pipe-a-bad-aux-stride-y_tiled_gen12_rc_ccs_cc:
- shard-glk: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#3886]) +2
similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117931v1/shard-glk4/igt@kms_ccs@pipe-a-bad-aux-stride-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_chamelium_color@ctm-blue-to-red:
- shard-glk: NOTRUN -> [SKIP][9] ([fdo#109271]) +41 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117931v1/shard-glk4/igt@kms_chamelium_co...@ctm-blue-to-red.html
* igt@kms_flip@2x-flip-vs-dpms:
- shard-snb: NOTRUN -> [SKIP][10] ([fdo#109271]) +13 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117931v1/shard-snb7/igt@kms_f...@2x-flip-vs-dpms.html
* igt@kms_plane_alpha_blend@alpha-basic@pipe-c-hdmi-a-1:
- shard-glk: NOTRUN -> [FAIL][11] ([i915#7862]) +1 similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117931v1/shard-glk4/igt@kms_plane_alpha_blend@alpha-ba...@pipe-c-hdmi-a-1.html
*
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-5@pipe-b-vga-1:
- shard-snb: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4579]) +9
similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117931v1/shard-snb4/igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-...@pipe-b-vga-1.html
*
igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-25@pipe-c-hdmi-a-1:
- shard-glk: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#4579]) +3
similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117931v1/shard-glk4/igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0...@pipe-c-hdmi-a-1.html
* igt@kms_psr2_sf@cursor-plane-move-continuous-sf:
- shard-glk: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#658])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117931v1/shard-glk4/igt@kms_psr2...@cursor-plane-move-continuous-sf.html
Possible fixes
* igt@gem_barrier_race@remote-request@rcs0:
- shard-glk: [ABORT][15] ([i915#7461] / [i915#8211]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13162/shard-glk3/igt@gem_barrier_race@remote-requ...@rcs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117931v1/shard-glk4/igt@gem_barrier_race@remote-requ...@rcs0.html
* igt@gem_exec_endless@dispatch@vecs0:
- {shard-tglu}: [TIMEOUT][17] ([i915#3778]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13162/shard-tglu-4/igt@gem_exec_endless@dispa...@vecs0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117931v1/shard-tglu-6/igt@gem_exec_endless@dispa...@vecs0.html
* igt@gem_lmem_swapping@smem-oom@lmem0:
- {shard-dg1}:[TIMEOUT][19] ([i915#5493]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13162/shard-dg1-18/igt@gem_lmem_swapping@smem-...@lmem0.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117931v1/shard-dg1-16/igt@gem_lmem_swapping@smem-...@lmem0.htm
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: avoid flush_scheduled_work() usage (rev5)
== Series Details == Series: drm/i915: avoid flush_scheduled_work() usage (rev5) URL : https://patchwork.freedesktop.org/series/114608/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13163 -> Patchwork_114608v5 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_114608v5 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_114608v5, 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_114608v5/index.html Participating hosts (37 -> 37) -- Additional (2): fi-kbl-soraka bat-adlp-6 Missing(2): fi-snb-2520m bat-mtlp-6 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_114608v5: ### IGT changes ### Possible regressions * igt@kms_pipe_crc_basic@read-crc@pipe-b-edp-1: - bat-adlp-6: NOTRUN -> [ABORT][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114608v5/bat-adlp-6/igt@kms_pipe_crc_basic@read-...@pipe-b-edp-1.html Known issues Here are the changes found in Patchwork_114608v5 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - bat-adlp-6: NOTRUN -> [SKIP][2] ([i915#7456]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114608v5/bat-adlp-6/igt@debugfs_t...@basic-hwmon.html * 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_114608v5/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_114608v5/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html * igt@gem_tiled_pread_basic: - bat-adlp-6: NOTRUN -> [SKIP][5] ([i915#3282]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114608v5/bat-adlp-6/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness@edp-1: - bat-rplp-1: NOTRUN -> [ABORT][6] ([i915#7077]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114608v5/bat-rplp-1/igt@i915_pm_backlight@basic-brightn...@edp-1.html * igt@i915_selftest@live@gt_heartbeat: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][7] ([i915#5334] / [i915#7872]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114608v5/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][8] ([i915#1886] / [i915#7913]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114608v5/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@i915_selftest@live@hangcheck: - bat-adls-5: [PASS][9] -> [DMESG-WARN][10] ([i915#5591]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13163/bat-adls-5/igt@i915_selftest@l...@hangcheck.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114608v5/bat-adls-5/igt@i915_selftest@l...@hangcheck.html * igt@i915_selftest@live@reset: - bat-rpls-2: [PASS][11] -> [ABORT][12] ([i915#4983] / [i915#7461] / [i915#7913] / [i915#7981] / [i915#8347]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13163/bat-rpls-2/igt@i915_selftest@l...@reset.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114608v5/bat-rpls-2/igt@i915_selftest@l...@reset.html * igt@kms_chamelium_frames@hdmi-crc-fast: - fi-kbl-soraka: NOTRUN -> [SKIP][13] ([fdo#109271]) +14 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114608v5/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html * igt@kms_chamelium_hpd@dp-hpd-fast: - bat-adlp-6: NOTRUN -> [SKIP][14] ([i915#7828]) +7 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114608v5/bat-adlp-6/igt@kms_chamelium_...@dp-hpd-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - bat-adlp-6: NOTRUN -> [SKIP][15] ([i915#4103]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114608v5/bat-adlp-6/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_force_connector_basic@force-load-detect: - bat-adlp-6: NOTRUN -> [SKIP][16] ([fdo#109285]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114608v5/bat-adlp-6/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-c-dp-1: - bat-dg2-8: [PASS][17] -> [FAIL][18] ([i915#7932]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_131
Re: [Intel-gfx] [PATCH v2] drm/i915/mtl: do not enable render power-gating on MTL
On 18.05.2023 17:09, Rodrigo Vivi wrote: On Thu, May 18, 2023 at 04:50:52PM +0200, Andrzej Hajda wrote: Multiple CI tests fails with forcewake ack timeouts if render power gating is enabled. BSpec 52698 states it should be 0 for MTL, but apparently this info is outdated. Anyway since the patch makes MTL pass basic tests added FIXME tag informing this is temporary workaround. v2: added FIXME tag Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4983 No change in the patch is needed, but do we have another (can be internal) ticket with the work to get this properly fix without wasting power? Yes there are jiras and related hsdes. In fact this tag is not fully correct, as the issue is about MTL and RPL. I wanted to use "References:" tag but "dim checkpatch" complains, so I have ended with Closes. Regarding your "No change in the patch is needed", do you prefer to merge v1 or v2? [1]: Regards Andrzej Signed-off-by: Andrzej Hajda Reviewed-by: Nirmoy Das Reviewed-by: Rodrigo Vivi Reviewed-by: Andi Shyti --- Changes in v2: - added FIXME tag - Link to v1: https://lore.kernel.org/r/20230517-mtl_disable_render_pg-v1-1-6495eebbf...@intel.com --- drivers/gpu/drm/i915/gt/intel_rc6.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.c b/drivers/gpu/drm/i915/gt/intel_rc6.c index 908a3d0f2343f4..58bb1c55294c93 100644 --- a/drivers/gpu/drm/i915/gt/intel_rc6.c +++ b/drivers/gpu/drm/i915/gt/intel_rc6.c @@ -117,8 +117,14 @@ static void gen11_rc6_enable(struct intel_rc6 *rc6) GEN6_RC_CTL_RC6_ENABLE | GEN6_RC_CTL_EI_MODE(1); - /* Wa_16011777198 - Render powergating must remain disabled */ - if (IS_DG2_GRAPHICS_STEP(gt->i915, G10, STEP_A0, STEP_C0) || + /* +* Wa_16011777198 and BSpec 52698 - Render powergating must be off. +* FIXME BSpec is outdated, disabling powergating for MTL is just +* temporary wa and should be removed after fixing real cause +* of forcewake timeouts. +*/ + if (IS_METEORLAKE(gt->i915) || + IS_DG2_GRAPHICS_STEP(gt->i915, G10, STEP_A0, STEP_C0) || IS_DG2_GRAPHICS_STEP(gt->i915, G11, STEP_A0, STEP_B0)) pg_enable = GEN9_MEDIA_PG_ENABLE | --- base-commit: 641646b29337c97681e0edb67ad2e08aef3fb850 change-id: 20230517-mtl_disable_render_pg-b9f9f1567f9e Best regards, -- Andrzej Hajda
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: avoid flush_scheduled_work() usage (rev5)
== Series Details == Series: drm/i915: avoid flush_scheduled_work() usage (rev5) URL : https://patchwork.freedesktop.org/series/114608/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH v2] drm/i915/mtl: do not enable render power-gating on MTL
On Thu, May 18, 2023 at 04:50:52PM +0200, Andrzej Hajda wrote: > Multiple CI tests fails with forcewake ack timeouts if render > power gating is enabled. > BSpec 52698 states it should be 0 for MTL, but apparently > this info is outdated. Anyway since the patch makes MTL pass basic > tests added FIXME tag informing this is temporary workaround. > > v2: added FIXME tag > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4983 No change in the patch is needed, but do we have another (can be internal) ticket with the work to get this properly fix without wasting power? > Signed-off-by: Andrzej Hajda > Reviewed-by: Nirmoy Das > Reviewed-by: Rodrigo Vivi > Reviewed-by: Andi Shyti > --- > Changes in v2: > - added FIXME tag > - Link to v1: > https://lore.kernel.org/r/20230517-mtl_disable_render_pg-v1-1-6495eebbf...@intel.com > --- > drivers/gpu/drm/i915/gt/intel_rc6.c | 10 -- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.c > b/drivers/gpu/drm/i915/gt/intel_rc6.c > index 908a3d0f2343f4..58bb1c55294c93 100644 > --- a/drivers/gpu/drm/i915/gt/intel_rc6.c > +++ b/drivers/gpu/drm/i915/gt/intel_rc6.c > @@ -117,8 +117,14 @@ static void gen11_rc6_enable(struct intel_rc6 *rc6) > GEN6_RC_CTL_RC6_ENABLE | > GEN6_RC_CTL_EI_MODE(1); > > - /* Wa_16011777198 - Render powergating must remain disabled */ > - if (IS_DG2_GRAPHICS_STEP(gt->i915, G10, STEP_A0, STEP_C0) || > + /* > + * Wa_16011777198 and BSpec 52698 - Render powergating must be off. > + * FIXME BSpec is outdated, disabling powergating for MTL is just > + * temporary wa and should be removed after fixing real cause > + * of forcewake timeouts. > + */ > + if (IS_METEORLAKE(gt->i915) || > + IS_DG2_GRAPHICS_STEP(gt->i915, G10, STEP_A0, STEP_C0) || > IS_DG2_GRAPHICS_STEP(gt->i915, G11, STEP_A0, STEP_B0)) > pg_enable = > GEN9_MEDIA_PG_ENABLE | > > --- > base-commit: 641646b29337c97681e0edb67ad2e08aef3fb850 > change-id: 20230517-mtl_disable_render_pg-b9f9f1567f9e > > Best regards, > -- > Andrzej Hajda >
Re: [Intel-gfx] [PATCH 1/6] drm/i915/regs: split out intel_color_regs.h
Quoting Jani Nikula (2023-05-17 09:38:16-03:00) >Declutter i915_regs.h. > >Signed-off-by: Jani Nikula I don't think I'm experienced enough to tell these are all the defines necessary to be moved, but with respect to the code move, it looks good to me. Thus, Acked-by: Gustavo Sousa >--- > drivers/gpu/drm/i915/display/hsw_ips.c| 1 + > drivers/gpu/drm/i915/display/intel_color.c| 1 + > .../gpu/drm/i915/display/intel_color_regs.h | 272 ++ > drivers/gpu/drm/i915/display/intel_display.c | 1 + > drivers/gpu/drm/i915/display/intel_overlay.c | 1 + > drivers/gpu/drm/i915/i915_reg.h | 260 - > drivers/gpu/drm/i915/intel_gvt_mmio_table.c | 1 + > 7 files changed, 277 insertions(+), 260 deletions(-) > create mode 100644 drivers/gpu/drm/i915/display/intel_color_regs.h > >diff --git a/drivers/gpu/drm/i915/display/hsw_ips.c >b/drivers/gpu/drm/i915/display/hsw_ips.c >index 8eca0de065b6..7dc38ac02092 100644 >--- a/drivers/gpu/drm/i915/display/hsw_ips.c >+++ b/drivers/gpu/drm/i915/display/hsw_ips.c >@@ -6,6 +6,7 @@ > #include "hsw_ips.h" > #include "i915_drv.h" > #include "i915_reg.h" >+#include "intel_color_regs.h" > #include "intel_de.h" > #include "intel_display_types.h" > #include "intel_pcode.h" >diff --git a/drivers/gpu/drm/i915/display/intel_color.c >b/drivers/gpu/drm/i915/display/intel_color.c >index 07f1afe1d406..f458b136e6a8 100644 >--- a/drivers/gpu/drm/i915/display/intel_color.c >+++ b/drivers/gpu/drm/i915/display/intel_color.c >@@ -24,6 +24,7 @@ > > #include "i915_reg.h" > #include "intel_color.h" >+#include "intel_color_regs.h" > #include "intel_de.h" > #include "intel_display_types.h" > #include "intel_dsb.h" >diff --git a/drivers/gpu/drm/i915/display/intel_color_regs.h >b/drivers/gpu/drm/i915/display/intel_color_regs.h >new file mode 100644 >index ..30e6f66a724d >--- /dev/null >+++ b/drivers/gpu/drm/i915/display/intel_color_regs.h >@@ -0,0 +1,272 @@ >+/* SPDX-License-Identifier: MIT */ >+/* >+ * Copyright © 2023 Intel Corporation >+ */ >+ >+#ifndef __INTEL_COLOR_REGS_H__ >+#define __INTEL_COLOR_REGS_H__ >+ >+#include "intel_display_reg_defs.h" >+ >+/* legacy palette */ >+#define _LGC_PALETTE_A 0x4a000 >+#define _LGC_PALETTE_B 0x4a800 >+/* see PALETTE_* for the bits */ >+#define LGC_PALETTE(pipe, i) _MMIO(_PIPE(pipe, _LGC_PALETTE_A, >_LGC_PALETTE_B) + (i) * 4) >+ >+/* ilk/snb precision palette */ >+#define _PREC_PALETTE_A 0x4b000 >+#define _PREC_PALETTE_B 0x4c000 >+/* 10bit mode */ >+#define PREC_PALETTE_10_RED_MASKREG_GENMASK(29, 20) >+#define PREC_PALETTE_10_GREEN_MASKREG_GENMASK(19, 10) >+#define PREC_PALETTE_10_BLUE_MASKREG_GENMASK(9, 0) >+/* 12.4 interpolated mode ldw */ >+#define PREC_PALETTE_12P4_RED_LDW_MASKREG_GENMASK(29, 24) >+#define PREC_PALETTE_12P4_GREEN_LDW_MASKREG_GENMASK(19, 14) >+#define PREC_PALETTE_12P4_BLUE_LDW_MASKREG_GENMASK(9, 4) >+/* 12.4 interpolated mode udw */ >+#define PREC_PALETTE_12P4_RED_UDW_MASKREG_GENMASK(29, 20) >+#define PREC_PALETTE_12P4_GREEN_UDW_MASKREG_GENMASK(19, 10) >+#define PREC_PALETTE_12P4_BLUE_UDW_MASKREG_GENMASK(9, 0) >+#define PREC_PALETTE(pipe, i) _MMIO(_PIPE(pipe, _PREC_PALETTE_A, >_PREC_PALETTE_B) + (i) * 4) >+ >+#define _PREC_PIPEAGCMAX 0x4d000 >+#define _PREC_PIPEBGCMAX 0x4d010 >+#define PREC_PIPEGCMAX(pipe, i)_MMIO(_PIPE(pipe, _PIPEAGCMAX, >_PIPEBGCMAX) + (i) * 4) /* u1.16 */ >+ >+#define _GAMMA_MODE_A0x4a480 >+#define _GAMMA_MODE_B0x4ac80 >+#define GAMMA_MODE(pipe) _MMIO_PIPE(pipe, _GAMMA_MODE_A, _GAMMA_MODE_B) >+#define PRE_CSC_GAMMA_ENABLEREG_BIT(31) /* icl+ */ >+#define POST_CSC_GAMMA_ENABLEREG_BIT(30) /* icl+ */ >+#define PALETTE_ANTICOL_DISABLEREG_BIT(15) /* skl+ */ >+#define GAMMA_MODE_MODE_MASKREG_GENMASK(1, 0) >+#define GAMMA_MODE_MODE_8BIT >REG_FIELD_PREP(GAMMA_MODE_MODE_MASK, 0) >+#define GAMMA_MODE_MODE_10BIT >REG_FIELD_PREP(GAMMA_MODE_MODE_MASK, 1) >+#define GAMMA_MODE_MODE_12BIT >REG_FIELD_PREP(GAMMA_MODE_MODE_MASK, 2) >+#define GAMMA_MODE_MODE_SPLIT >REG_FIELD_PREP(GAMMA_MODE_MODE_MASK, 3) /* ivb-bdw */ >+#define GAMMA_MODE_MODE_12BIT_MULTI_SEG >REG_FIELD_PREP(GAMMA_MODE_MODE_MASK, 3) /* icl-tgl */ >+ >+/* pipe CSC */ >+#define _PIPE_A_CSC_COEFF_RY_GY0x49010 >+#define _PIPE_A_CSC_COEFF_BY0x49014 >+#define _PIPE_A_CSC_COEFF_RU_GU0x49018 >+#define _PIPE_A_CSC_COEFF_BU0x4901c >+#define _PIPE_A_CSC_COEFF_RV_GV0x49020 >+#define _PIPE_A_CSC_COEFF_BV0x49024 >+ >+#define _PIPE_A_CSC_MODE0x49028 >+#define ICL_CSC_ENABLE(1 << 31) /* icl+ */ >+#define ICL_OUTPUT_C
[Intel-gfx] [PATCH v2] drm/i915/mtl: do not enable render power-gating on MTL
Multiple CI tests fails with forcewake ack timeouts if render power gating is enabled. BSpec 52698 states it should be 0 for MTL, but apparently this info is outdated. Anyway since the patch makes MTL pass basic tests added FIXME tag informing this is temporary workaround. v2: added FIXME tag Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4983 Signed-off-by: Andrzej Hajda Reviewed-by: Nirmoy Das Reviewed-by: Rodrigo Vivi Reviewed-by: Andi Shyti --- Changes in v2: - added FIXME tag - Link to v1: https://lore.kernel.org/r/20230517-mtl_disable_render_pg-v1-1-6495eebbf...@intel.com --- drivers/gpu/drm/i915/gt/intel_rc6.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.c b/drivers/gpu/drm/i915/gt/intel_rc6.c index 908a3d0f2343f4..58bb1c55294c93 100644 --- a/drivers/gpu/drm/i915/gt/intel_rc6.c +++ b/drivers/gpu/drm/i915/gt/intel_rc6.c @@ -117,8 +117,14 @@ static void gen11_rc6_enable(struct intel_rc6 *rc6) GEN6_RC_CTL_RC6_ENABLE | GEN6_RC_CTL_EI_MODE(1); - /* Wa_16011777198 - Render powergating must remain disabled */ - if (IS_DG2_GRAPHICS_STEP(gt->i915, G10, STEP_A0, STEP_C0) || + /* +* Wa_16011777198 and BSpec 52698 - Render powergating must be off. +* FIXME BSpec is outdated, disabling powergating for MTL is just +* temporary wa and should be removed after fixing real cause +* of forcewake timeouts. +*/ + if (IS_METEORLAKE(gt->i915) || + IS_DG2_GRAPHICS_STEP(gt->i915, G10, STEP_A0, STEP_C0) || IS_DG2_GRAPHICS_STEP(gt->i915, G11, STEP_A0, STEP_B0)) pg_enable = GEN9_MEDIA_PG_ENABLE | --- base-commit: 641646b29337c97681e0edb67ad2e08aef3fb850 change-id: 20230517-mtl_disable_render_pg-b9f9f1567f9e Best regards, -- Andrzej Hajda
[Intel-gfx] [PATCH v4] drm/i915: avoid flush_scheduled_work() usage
Like commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue() using a
macro") says, flush_scheduled_work() is dangerous and will be forbidden.
i915 became the last flush_scheduled_work() user, but developers cannot
find time for auditing which work items does this flush_scheduled_work()
need to wait.
Therefore, for now let's start with blind/mechanical conversion within
the whole drivers/gpu/drm/i915/ directory, based on an assumption that
i915 does not need to wait for work items outside of this directory.
Link: https://lkml.kernel.org/r/87sfeita1p@intel.com
Signed-off-by: Tetsuo Handa
Cc: Tvrtko Ursulin
Cc: Jani Nikula
Cc: Ville Syrjälä
---
Changes in v4:
Refreshed using drm-tip.git.
Changes in v3:
Refreshed using drm-tip.git, for commit 40053823baad ("drm/i915/display:
move modeset probe/remove functions to intel_display_driver.c") moved
flush_scheduled_work() from intel_display.c to intel_display_driver.c .
Please check the comment from Daniel Vetter at
https://lkml.kernel.org/r/ZDuntOkUeh0Eve8a@phenom.ffwll.local .
Changes in v2:
Add missing alloc_workqueue() failure check.
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
.../drm/i915/display/intel_display_driver.c| 2 +-
drivers/gpu/drm/i915/display/intel_dmc.c | 2 +-
drivers/gpu/drm/i915/display/intel_dp.c| 2 +-
.../drm/i915/display/intel_dp_link_training.c | 2 +-
drivers/gpu/drm/i915/display/intel_drrs.c | 2 +-
drivers/gpu/drm/i915/display/intel_fbc.c | 2 +-
drivers/gpu/drm/i915/display/intel_fbdev.c | 2 +-
drivers/gpu/drm/i915/display/intel_hdcp.c | 18 +-
drivers/gpu/drm/i915/display/intel_hotplug.c | 12 ++--
drivers/gpu/drm/i915/display/intel_opregion.c | 2 +-
drivers/gpu/drm/i915/display/intel_pps.c | 2 +-
drivers/gpu/drm/i915/display/intel_psr.c | 6 +++---
.../drm/i915/gt/intel_execlists_submission.c | 4 ++--
drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c | 8
drivers/gpu/drm/i915/gt/intel_gt_irq.c | 2 +-
drivers/gpu/drm/i915/gt/intel_gt_requests.c| 10 +-
drivers/gpu/drm/i915/gt/intel_reset.c | 2 +-
drivers/gpu/drm/i915/gt/intel_rps.c| 14 +++---
drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h| 1 +
drivers/gpu/drm/i915/i915_module.c | 7 +++
drivers/gpu/drm/i915/i915_request.c| 2 +-
drivers/gpu/drm/i915/intel_wakeref.c | 4 +++-
drivers/gpu/drm/i915/selftests/i915_sw_fence.c | 4 +++-
25 files changed, 64 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 09320e14d75c..5f1ba9c908cb 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7145,7 +7145,7 @@ intel_atomic_commit_ready(struct i915_sw_fence *fence,
&to_i915(state->base.dev)->display.atomic_helper;
if (llist_add(&state->freed, &helper->free_list))
- schedule_work(&helper->free_work);
+ queue_work(i915_wq, &helper->free_work);
break;
}
}
diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c
b/drivers/gpu/drm/i915/display/intel_display_driver.c
index 60ce10fc7205..a20a9cfaab0e 100644
--- a/drivers/gpu/drm/i915/display/intel_display_driver.c
+++ b/drivers/gpu/drm/i915/display/intel_display_driver.c
@@ -435,7 +435,7 @@ void intel_display_driver_remove_noirq(struct
drm_i915_private *i915)
intel_unregister_dsm_handler();
/* flush any delayed tasks or pending work */
- flush_scheduled_work();
+ flush_workqueue(i915_wq);
intel_hdcp_component_fini(i915);
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 8a88de67ff0a..57d015006784 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -1057,7 +1057,7 @@ void intel_dmc_init(struct drm_i915_private *i915)
i915->display.dmc.dmc = dmc;
drm_dbg_kms(&i915->drm, "Loading %s\n", dmc->fw_path);
- schedule_work(&dmc->work);
+ queue_work(i915_wq, &dmc->work);
return;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 4bec8cd7979f..4782bdfc7c61 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5251,7 +5251,7 @@ static void intel_dp_oob_hotplug_event(struct
drm_connector *connector)
spin_lock_irq(&i915->irq_lock);
i915->display.hotplug.event_bits |= BIT(encoder->hpd_pin);
spin_unlock_irq(&i915->irq_lock);
- queue_delayed_work(system_wq, &i915->display.hotplug.hotplug_work, 0);
+ queue_delayed_work(i915_wq, &i91
Re: [Intel-gfx] [PATCH] drm/i915/mtl: do not enable render power-gating on MTL
Hi Andrzej and Rodrigo, > > On 5/17/2023 5:25 PM, Vivi, Rodrigo wrote: > > > On Wed, 2023-05-17 at 17:12 +0200, Das, Nirmoy wrote: > > > > On 5/17/2023 3:59 PM, Andrzej Hajda wrote: > > > > > Multiple CI tests fails with forcewake ack timeouts > > > > > if render power gating is enabled. > > > > > BSpec 52698 clearly states it should be 0 for MTL. > > > > > > > > > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4983 > > > > > Signed-off-by: Andrzej Hajda > > > > > --- > > > > > drivers/gpu/drm/i915/gt/intel_rc6.c | 5 +++-- > > > > > 1 file changed, 3 insertions(+), 2 deletions(-) > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.c > > > > > b/drivers/gpu/drm/i915/gt/intel_rc6.c > > > > > index 908a3d0f2343f4..ebb2373dd73640 100644 > > > > > --- a/drivers/gpu/drm/i915/gt/intel_rc6.c > > > > > +++ b/drivers/gpu/drm/i915/gt/intel_rc6.c > > > > > @@ -117,8 +117,9 @@ static void gen11_rc6_enable(struct intel_rc6 > > > > > *rc6) > > > > > GEN6_RC_CTL_RC6_ENABLE | > > > > > GEN6_RC_CTL_EI_MODE(1); > > > > > - /* Wa_16011777198 - Render powergating must remain disabled > > > > > */ > > > > > - if (IS_DG2_GRAPHICS_STEP(gt->i915, G10, STEP_A0, STEP_C0) > > > > > || > > > > > + /* Wa_16011777198 and BSpec 52698 - Render powergating must > > > > > be off */ > > > > Nice catch! > > > Indeed! What a mess in the workaround database. > > > It is telling us that no_impact on MTL SKUs while we clearly needs > > > that. I tried to reopen that and get that fixed in the hsds. > > > > > > > > > > instead of bspec you could add Wa_1401266. > > > not actually. > > > 16011777198 is the right lineage number for 1401266. > > > Besides, 1401266 is for DG2 anyway. > > > > > > Let's keep the way Adrzej put with the BSPec reference besides the > > > lineage. > > > > Makes sense, didn't realize 1401266 is much older. > > > > Thanks! > > > > > > > > > > > > > > + if (IS_METEORLAKE(gt->i915) || > > > > > + IS_DG2_GRAPHICS_STEP(gt->i915, G10, STEP_A0, STEP_C0) > > > > > || > > > > > IS_DG2_GRAPHICS_STEP(gt->i915, G11, STEP_A0, STEP_B0)) > > > > > pg_enable = > > > > > GEN9_MEDIA_PG_ENABLE | > > > > > > > > > > --- > > > > > base-commit: 01d3dd92d1b71421f6ee85e1bea829e0a917d979 > > > > > change-id: 20230517-mtl_disable_render_pg-b9f9f1567f9e > > > > ^ unwanted artifacts ? Otherwise this looks good to me. > > > > > > > > Reviewed-by: Nirmoy Das > > > with the artifacts removed: > > > Reviewed-by: Rodrigo Vivi > > Folks, please do not merge this patch. > At least not as it is right now... > > We need to root cause this. The hw bug related to this workaround > was really fixed and this workaround should not be needed in MTL. > > We need to find the root cause instead of masking it here. > Or at least merge as temporary FIXME/XXX and then work to > get the root cause... I'm OK with merging this with the FIXME tag. Reviewed-by: Andi Shyti Andi
Re: [Intel-gfx] [PATCH v5 09/10] vfio/pci: Extend VFIO_DEVICE_GET_PCI_HOT_RESET_INFO for vfio device cdev
> From: Alex Williamson
> Sent: Thursday, May 18, 2023 6:02 AM
>
> On Sat, 13 May 2023 06:21:35 -0700
> Yi Liu wrote:
>
> > This makes VFIO_DEVICE_GET_PCI_HOT_RESET_INFO ioctl to use the iommufd_ctx
>
> s/makes/allows/?
>
> s/to//
>
> > of the cdev device to check the ownership of the other affected devices.
> >
> > This returns devid for each of the affected devices. If it is bound to the
> > iommufd_ctx of the cdev device, _INFO reports a valid devid > 0; If it is
> > not opened by the calling user, but it belongs to the same iommu_group of
> > a device that is bound to the iommufd_ctx of the cdev device, reports devid
> > value of 0; If the device is un-owned device, configured within a different
> > iommufd, or opened outside of the vfio device cdev API, the _INFO ioctl
> > shall
> > report devid value of -1.
> >
> > devid >=0 doesn't block hot-reset as the affected devices are considered to
> > be owned, while devid == -1 will block the use of VFIO_DEVICE_PCI_HOT_RESET
> > outside of proof-of-ownership calling conventions (ie. via legacy group
> > accessed devices).
> >
> > This adds flag VFIO_PCI_HOT_RESET_FLAG_DEV_ID to tell the user devid is
> > returned in case of calling user get device fd from other software stack
>
> "other software stack"? I think this is trying to say something like:
>
> When VFIO_DEVICE_GET_PCI_HOT_RESET_INFO is called on an IOMMUFD
> managed device, the new flag VFIO_PCI_HOT_RESET_FLAG_DEV_ID is
> reported to indicate the values returned are IOMMUFD devids rather
> than group IDs as used when accessing vfio devices through the
> conventional vfio group interface. Additionally the flag
> VFIO_PCI_HOT_RESET_FLAG_DEV_ID_OWNED will be reported in this mode if
> all of the devices affected by the hot-reset are owned by either
> virtue of being directly bound to the same iommufd context as the
> calling device, or implicitly owned via a shared IOMMU group.
Yes. it is.
> > and adds flag VFIO_PCI_HOT_RESET_FLAG_DEV_ID_OWNED to tell user if all
> > the affected devices are owned, so user can know it without looping all
> > the returned devids.
> >
> > Suggested-by: Jason Gunthorpe
> > Suggested-by: Alex Williamson
> > Signed-off-by: Yi Liu
> > ---
> > drivers/vfio/pci/vfio_pci_core.c | 52 ++--
> > include/uapi/linux/vfio.h| 46 +++-
> > 2 files changed, 95 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/vfio/pci/vfio_pci_core.c
> > b/drivers/vfio/pci/vfio_pci_core.c
> > index 4df2def35bdd..57586be770af 100644
> > --- a/drivers/vfio/pci/vfio_pci_core.c
> > +++ b/drivers/vfio/pci/vfio_pci_core.c
> > @@ -27,6 +27,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #if IS_ENABLED(CONFIG_EEH)
> > #include
> > #endif
> > @@ -36,6 +37,10 @@
> > #define DRIVER_AUTHOR "Alex Williamson "
> > #define DRIVER_DESC "core driver for VFIO based PCI devices"
> >
> > +#ifdef CONFIG_IOMMUFD
> > +MODULE_IMPORT_NS(IOMMUFD);
> > +#endif
> > +
> > static bool nointxmask;
> > static bool disable_vga;
> > static bool disable_idle_d3;
> > @@ -776,6 +781,9 @@ struct vfio_pci_fill_info {
> > int max;
> > int cur;
> > struct vfio_pci_dependent_device *devices;
> > + struct vfio_device *vdev;
> > + bool devid:1;
> > + bool dev_owned:1;
> > };
> >
> > static int vfio_pci_fill_devs(struct pci_dev *pdev, void *data)
> > @@ -790,7 +798,37 @@ static int vfio_pci_fill_devs(struct pci_dev *pdev,
> > void *data)
> > if (!iommu_group)
> > return -EPERM; /* Cannot reset non-isolated devices */
> >
> > - fill->devices[fill->cur].group_id = iommu_group_id(iommu_group);
> > + if (fill->devid) {
> > + struct iommufd_ctx *iommufd =
> > vfio_iommufd_physical_ictx(fill->vdev);
> > + struct vfio_device_set *dev_set = fill->vdev->dev_set;
> > + struct vfio_device *vdev;
> > +
> > + /*
> > +* Report devid for the affected devices:
> > +* - valid devid > 0 for the devices that are bound with
> > +* the iommufd of the calling device.
> > +* - devid == 0 for the devices that have not been opened
> > +* but have same group with one of the devices bound to
> > +* the iommufd of the calling device.
> > +* - devid == -1 for others, and clear dev_owned flag.
> > +*/
> > + vdev = vfio_find_device_in_devset(dev_set, &pdev->dev);
> > + if (vdev && iommufd == vfio_iommufd_physical_ictx(vdev)) {
> > + int ret;
> > +
> > + ret = vfio_iommufd_physical_devid(vdev);
> > + if (WARN_ON(ret < 0))
> > + return ret;
> > + fill->devices[fill->cur].devid = ret;
>
> Nit, @devid seems like a better variable name here rather than @ret.
>
> > + } else if (vdev && iommufd_ctx_has_group(iommufd, iommu_group))
> > {
>
Re: [Intel-gfx] [PATCH v5 09/10] vfio/pci: Extend VFIO_DEVICE_GET_PCI_HOT_RESET_INFO for vfio device cdev
> From: Liu, Yi L
> Sent: Thursday, May 18, 2023 9:22 PM
>
> > From: Alex Williamson
> > Sent: Thursday, May 18, 2023 6:02 AM
> >
> > On Sat, 13 May 2023 06:21:35 -0700
> > Yi Liu wrote:
> >
> > static int vfio_hot_reset_devid(struct vfio_device *vdev,
> > struct iommufd_ctx *iommufd_ctx)
> > {
> > struct iommu_group *group;
> > int devid;
> >
> > if (!vdev)
> > return VFIO_PCI_DEVID_NOT_OWNED;
> >
> > if (vfio_iommufd_physical_ictx(vdev) == iommufd_ctx)
> > return vfio_iommufd_physical_devid(vdev);
Do we need to check the return of this helper? It returns -EINVAL
when iommufd_access and iommufd_device are both null. Though
not possible in this path. Is a WARN_ON needed or not?
Regards,
Yi Liu
> >
> > group = iommu_group_get(vdev->dev);
> > if (!group)
> > return VFIO_PCI_DEVID_NOT_OWNED;
> >
> > if (iommufd_ctx_has_group(iommufd_ctx, group))
> > devid = VFIO_PCI_DEVID_OWNED;
> >
> > iommu_group_put(group);
> >
> > return devid;
> > }
Re: [Intel-gfx] [v2, 11/12] drm/fbdev-generic: Implement dedicated fbdev I/O helpers
Hi
Am 18.05.23 um 14:46 schrieb Sui Jingfeng:
Hi,
On 2023/5/17 15:07, Thomas Zimmermann wrote:
Hi
Am 17.05.23 um 03:58 schrieb Sui Jingfeng:
Hi, Thomas
After apply your patch set, the kernel with
arch/loongarch/configs/loongson3_defconfig
can not finish compile anymore. gcc complains:
AR drivers/gpu/built-in.a
AR drivers/built-in.a
AR built-in.a
AR vmlinux.a
LD vmlinux.o
OBJCOPY modules.builtin.modinfo
GEN modules.builtin
GEN .vmlinux.objs
MODPOST Module.symvers
ERROR: modpost: "fb_sys_write" [drivers/gpu/drm/drm_kms_helper.ko]
undefined!
ERROR: modpost: "sys_imageblit" [drivers/gpu/drm/drm_kms_helper.ko]
undefined!
ERROR: modpost: "sys_fillrect" [drivers/gpu/drm/drm_kms_helper.ko]
undefined!
ERROR: modpost: "sys_copyarea" [drivers/gpu/drm/drm_kms_helper.ko]
undefined!
ERROR: modpost: "fb_sys_read" [drivers/gpu/drm/drm_kms_helper.ko]
undefined!
make[1]: *** [scripts/Makefile.modpost:136: Module.symvers] Error 1
make: *** [Makefile:1978: modpost] Error 2
Thanks for reporting this problem. I found that it's caused by a typo
in the very first patch 1/7, where these helpers are not selected
correctly. Will be fixed in the next round.
Yeah, this is just a typo.
Should replace 'FB_SYS_HELPER' with 'FB_SYS_HELPERS' on the first patch
of this series.
Best regards
Thomas
On 2023/5/15 17:40, Thomas Zimmermann wrote:
Implement dedicated fbdev helpers for framebuffer I/O instead
of using DRM's helpers. Fbdev-generic was the only caller of the
DRM helpers, so remove them from the helper module.
v2:
* use FB_SYS_HELPERS_DEFERRED option
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/Kconfig | 6 +-
drivers/gpu/drm/drm_fb_helper.c | 107
drivers/gpu/drm/drm_fbdev_generic.c | 47 ++--
include/drm/drm_fb_helper.h | 41 ---
4 files changed, 43 insertions(+), 158 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 77fb10ddd8a2..92a782827b7b 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -95,6 +95,7 @@ config DRM_KUNIT_TEST
config DRM_KMS_HELPER
tristate
depends on DRM
+ select FB_SYS_HELPERS_DEFERRED if DRM_FBDEV_EMULATION
Here, select FB_SYS_HELPERS helps resolve the above issue mentioned.
But select FB_SYS_HELPERS here is more better, I think. Because it show
the nature that
DRM_KMS_HELPER is depend on FB_SYS_HELPERS, I think you may want isolate
those dependency with DRM_FBDEV_EMULATION guard.
at least, you should guarantee that drm itself could built and run
standalone.
Indeed, it would be better to select this from DRM_FBDEV_EMULATION.
Thanks for the remark. I'll update this in the next version.
Best regards
Thomas
Fbdev emulation is a client of drm, not reverse.
By the way, does Denial happy about this,
maybe, he want the fbdev emulation 100% made in drm?
help
CRTC helpers for KMS drivers.
@@ -135,11 +136,6 @@ config DRM_FBDEV_EMULATION
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
- select FB_DEFERRED_IO
- select FB_SYS_FOPS
- select FB_SYS_FILLRECT
- select FB_SYS_COPYAREA
- select FB_SYS_IMAGEBLIT
select FRAMEBUFFER_CONSOLE if !EXPERT
select FRAMEBUFFER_CONSOLE_DETECT_PRIMARY if FRAMEBUFFER_CONSOLE
default y
diff --git a/drivers/gpu/drm/drm_fb_helper.c
b/drivers/gpu/drm/drm_fb_helper.c
index 8724e08c518b..ba0a808f14ee 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -729,113 +729,6 @@ void drm_fb_helper_deferred_io(struct fb_info
*info, struct list_head *pagerefli
}
EXPORT_SYMBOL(drm_fb_helper_deferred_io);
-/**
- * drm_fb_helper_sys_read - Implements struct &fb_ops.fb_read for
system memory
- * @info: fb_info struct pointer
- * @buf: userspace buffer to read from framebuffer memory
- * @count: number of bytes to read from framebuffer memory
- * @ppos: read offset within framebuffer memory
- *
- * Returns:
- * The number of bytes read on success, or an error code otherwise.
- */
-ssize_t drm_fb_helper_sys_read(struct fb_info *info, char __user *buf,
- size_t count, loff_t *ppos)
-{
- return fb_sys_read(info, buf, count, ppos);
-}
-EXPORT_SYMBOL(drm_fb_helper_sys_read);
-
-/**
- * drm_fb_helper_sys_write - Implements struct &fb_ops.fb_write for
system memory
- * @info: fb_info struct pointer
- * @buf: userspace buffer to write to framebuffer memory
- * @count: number of bytes to write to framebuffer memory
- * @ppos: write offset within framebuffer memory
- *
- * Returns:
- * The number of bytes written on success, or an error code otherwise.
- */
-ssize_t drm_fb_helper_sys_write(struct fb_info *info, const char
__user *buf,
- size_t count, loff_t *ppos)
-{
- struct drm_fb_helper *helper = info->par;
- loff_t pos = *ppos;
- ssize_t ret;
- struct drm_re
Re: [Intel-gfx] [PATCH v5 06/10] vfio-iommufd: Add helper to retrieve iommufd_ctx and devid for vfio_device
> From: Alex Williamson
> Sent: Thursday, May 18, 2023 2:15 AM
>
> On Sat, 13 May 2023 06:21:32 -0700
> Yi Liu wrote:
>
> > This is needed by the vfio-pci driver to report affected devices in the
> > hot reset for a given device.
> >
> > Signed-off-by: Yi Liu
> > ---
> > drivers/iommu/iommufd/device.c | 24
> > drivers/vfio/iommufd.c | 20
> > include/linux/iommufd.h| 6 ++
> > include/linux/vfio.h | 14 ++
> > 4 files changed, 64 insertions(+)
> >
> > diff --git a/drivers/iommu/iommufd/device.c b/drivers/iommu/iommufd/device.c
> > index 4f9b2142274c..81466b97023f 100644
> > --- a/drivers/iommu/iommufd/device.c
> > +++ b/drivers/iommu/iommufd/device.c
> > @@ -116,6 +116,18 @@ void iommufd_device_unbind(struct iommufd_device *idev)
> > }
> > EXPORT_SYMBOL_NS_GPL(iommufd_device_unbind, IOMMUFD);
> >
> > +struct iommufd_ctx *iommufd_device_to_ictx(struct iommufd_device *idev)
> > +{
> > + return idev->ictx;
> > +}
> > +EXPORT_SYMBOL_NS_GPL(iommufd_device_to_ictx, IOMMUFD);
> > +
> > +u32 iommufd_device_to_id(struct iommufd_device *idev)
> > +{
> > + return idev->obj.id;
> > +}
> > +EXPORT_SYMBOL_NS_GPL(iommufd_device_to_id, IOMMUFD);
> > +
> > static int iommufd_device_setup_msi(struct iommufd_device *idev,
> > struct iommufd_hw_pagetable *hwpt,
> > phys_addr_t sw_msi_start)
> > @@ -463,6 +475,18 @@ void iommufd_access_destroy(struct iommufd_access
> *access)
> > }
> > EXPORT_SYMBOL_NS_GPL(iommufd_access_destroy, IOMMUFD);
> >
> > +struct iommufd_ctx *iommufd_access_to_ictx(struct iommufd_access *access)
> > +{
> > + return access->ictx;
> > +}
> > +EXPORT_SYMBOL_NS_GPL(iommufd_access_to_ictx, IOMMUFD);
> > +
> > +u32 iommufd_access_to_id(struct iommufd_access *access)
> > +{
> > + return access->obj.id;
> > +}
> > +EXPORT_SYMBOL_NS_GPL(iommufd_access_to_id, IOMMUFD);
> > +
> > int iommufd_access_attach(struct iommufd_access *access, u32 ioas_id)
> > {
> > struct iommufd_ioas *new_ioas;
> > diff --git a/drivers/vfio/iommufd.c b/drivers/vfio/iommufd.c
> > index c1379e826052..a18e920be164 100644
> > --- a/drivers/vfio/iommufd.c
> > +++ b/drivers/vfio/iommufd.c
> > @@ -105,6 +105,26 @@ void vfio_iommufd_unbind(struct vfio_device *vdev)
> > vdev->ops->unbind_iommufd(vdev);
> > }
> >
> > +struct iommufd_ctx *vfio_iommufd_physical_ictx(struct vfio_device *vdev)
> > +{
> > + if (vdev->iommufd_device)
> > + return iommufd_device_to_ictx(vdev->iommufd_device);
> > + if (vdev->noiommu_access)
> > + return iommufd_access_to_ictx(vdev->noiommu_access);
> > + return NULL;
> > +}
> > +EXPORT_SYMBOL_GPL(vfio_iommufd_physical_ictx);
> > +
> > +int vfio_iommufd_physical_devid(struct vfio_device *vdev)
> > +{
> > + if (vdev->iommufd_device)
> > + return iommufd_device_to_id(vdev->iommufd_device);
> > + if (vdev->noiommu_access)
> > + return iommufd_access_to_id(vdev->noiommu_access);
> > + return -EINVAL;
> > +}
> > +EXPORT_SYMBOL_GPL(vfio_iommufd_physical_devid);
>
> I think these exemplify that it would be better if both emulated and
> noiommu use the same iommufd_access pointer. Thanks,
Sure. Then I shall rename this helper. vfio_iommufd_device_devid()
What about your opinion?
Regards,
Yi Liu
Re: [Intel-gfx] [PATCH 12/13] drm/i915/dp: Get optimal link config to have best compressed bpp
Thanks Stan and Ville for the review comments.
I agree can have some documentation about the values used, instead of
magic numbers.
Also, Ville's approach for dsc_{sink,source}_{min,max}_bpp() seems good,
and that can be used as helpers in MST case too.
Will add the changes in the next version of the patch.
Thanks & Regards,
Ankit
On 5/16/2023 5:10 PM, Ville Syrjälä wrote:
On Tue, May 16, 2023 at 01:43:44PM +0300, Lisovskiy, Stanislav wrote:
On Fri, May 12, 2023 at 11:54:16AM +0530, Ankit Nautiyal wrote:
Currently, we take the max lane, rate and pipe bpp, to get the maximum
compressed bpp possible. We then set the output bpp to this value.
This patch provides support to have max bpp, min rate and min lanes,
that can support the min compressed bpp.
v2:
-Avoid ending up with compressed bpp, same as pipe bpp. (Stan)
-Fix the checks for limits->max/min_bpp while iterating over list of
valid DSC bpcs. (Stan)
v3:
-Refactor the code to have pipe bpp/compressed bpp computation and slice
count calculation separately for different cases.
v4:
-Separate the pipe_bpp calculation for eDP and DP.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 305 +++-
1 file changed, 245 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 39e2bf3d738d..578320220c9a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1642,6 +1642,209 @@ static bool intel_dp_dsc_supports_format(struct
intel_dp *intel_dp,
return drm_dp_dsc_sink_supports_format(intel_dp->dsc_dpcd,
sink_dsc_format);
}
+static bool is_dsc_bw_sufficient(int link_rate, int lane_count, int compressed_bpp,
+const struct drm_display_mode *adjusted_mode)
+{
+ int mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
compressed_bpp);
+ int link_avail = intel_dp_max_data_rate(link_rate, lane_count);
+
+ return mode_rate <= link_avail;
+}
+
+static int dsc_compute_link_config(struct intel_dp *intel_dp,
+ struct intel_crtc_state *pipe_config,
+ struct link_config_limits *limits,
+ int pipe_bpp,
+ u16 compressed_bpp,
+ int timeslots)
+{
+ const struct drm_display_mode *adjusted_mode =
+ &pipe_config->hw.adjusted_mode;
+ int link_rate, lane_count;
+ int dsc_max_bpp;
+ struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
+ int i;
+
+ for (i = 0; i < intel_dp->num_common_rates; i++) {
+ link_rate = intel_dp_common_rate(intel_dp, i);
+ if (link_rate < limits->min_rate || link_rate >
limits->max_rate)
+ continue;
+
+ for (lane_count = limits->min_lane_count;
+lane_count <= limits->max_lane_count;
+lane_count <<= 1) {
+ dsc_max_bpp =
intel_dp_dsc_get_max_compressed_bpp(dev_priv,
+
link_rate,
+
lane_count,
+
adjusted_mode->crtc_clock,
+
adjusted_mode->crtc_hdisplay,
+
pipe_config->bigjoiner_pipes,
+
pipe_config->output_format,
+
pipe_bpp, timeslots);
+ /*
+* According to DSC 1.2a Section 4.1.1 Table 4.1 the
maximum
+* supported PPS value can be 63.9375 and with the
further
+* mention that bpp should be programmed double the
target bpp
+* restricting our target bpp to be 31.9375 at max
+*/
+ if (pipe_config->output_format ==
INTEL_OUTPUT_FORMAT_YCBCR420)
+ dsc_max_bpp = min_t(u16, dsc_max_bpp, 31);
+
+ if (compressed_bpp > dsc_max_bpp)
+ continue;
+
+ if (!is_dsc_bw_sufficient(link_rate, lane_count,
+ compressed_bpp,
adjusted_mode))
+ continue;
+
+ pipe_config->lane_count = lane_count;
+ pipe_config->port_clock = link_rate;
+
+ return 0;
+ }
+ }
+
+ return -EINVAL;
+}
+
+static
+u16 intel_dp_dsc_max_sink_compressed_bppx16(struct intel_dp *i
Re: [Intel-gfx] [PATCH 04/13] drm/i915/dp: Update Bigjoiner interface bits for computing compressed bpp
On 5/15/2023 7:21 PM, Ville Syrjälä wrote:
On Fri, May 12, 2023 at 11:54:08AM +0530, Ankit Nautiyal wrote:
In Bigjoiner check for DSC, bigjoiner interface bits for DP for
DISPLAY > 13 is 36 (Bspec: 49259).
v2: Corrected Display ver to 13.
v3: Follow convention for conditional statement. (Ville)
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 24de25551a49..bca80c0793e9 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -783,8 +783,9 @@ u16 intel_dp_dsc_get_max_compressed_bpp(struct
drm_i915_private *i915,
bits_per_pixel = min(bits_per_pixel, max_bpp_small_joiner_ram);
if (bigjoiner) {
+ int bigjoiner_interface_bits = DISPLAY_VER(i915) > 13 ? 36 : 24;
'x >= 14' is the usual convention.
with that
Reviewed-by: Ville Syrjälä
Thanks Ville for the reviews.
Will fix the check in next version of the patch.
Regards,
Ankit
u32 max_bpp_bigjoiner =
- i915->display.cdclk.max_cdclk_freq * 48 /
+ i915->display.cdclk.max_cdclk_freq * 2 *
bigjoiner_interface_bits /
intel_dp_mode_to_fec_clock(mode_clock);
bits_per_pixel = min(bits_per_pixel, max_bpp_bigjoiner);
--
2.25.1
Re: [Intel-gfx] [PATCH 05/13] drm/i915/intel_cdclk: Add vdsc with bigjoiner constraints on min_cdlck
Thanks Ville and Stan for the comments.
I agree with the changes in _plane_min_cdclk and
intel_pixel_rate_to_cdclk regarding PPC.
But I am a little confused for about the pixel clock.
Please find my comments inline:
On 5/16/2023 3:41 PM, Lisovskiy, Stanislav wrote:
On Mon, May 15, 2023 at 05:44:51PM +0300, Ville Syrjälä wrote:
On Fri, May 12, 2023 at 11:54:09AM +0530, Ankit Nautiyal wrote:
As per Bsepc:49259, Bigjoiner BW check puts restriction on the
compressed bpp for a given CDCLK, pixelclock in cases where
Bigjoiner + DSC are used.
Currently compressed bpp is computed first, and it is ensured that
the bpp will work at least with the max CDCLK freq.
Since the CDCLK is computed later, lets account for Bigjoiner BW
check while calculating Min CDCLK.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 49 ++
1 file changed, 42 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 6bed75f1541a..3532640c5027 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -2520,6 +2520,46 @@ static int intel_planes_min_cdclk(const struct
intel_crtc_state *crtc_state)
return min_cdclk;
}
+static int intel_vdsc_min_cdclk(const struct intel_crtc_state *crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+ struct drm_i915_private *i915 = to_i915(crtc->base.dev);
+ int min_cdclk = 0;
+
+ /*
+* When we decide to use only one VDSC engine, since
+* each VDSC operates with 1 ppc throughput, pixel clock
+* cannot be higher than the VDSC clock (cdclk)
+*/
+ if (!crtc_state->dsc.dsc_split)
+ min_cdclk = max(min_cdclk, (int)crtc_state->pixel_rate);
+
+ if (crtc_state->bigjoiner_pipes) {
+ /*
+* According to Bigjoiner bw check:
+* compressed_bpp <= PPC * CDCLK * Big joiner Interface bits /
Pixel clock
+*
+* We have already computed compressed_bpp, so now compute the
min CDCLK that
+* is required to support this compressed_bpp.
+*
+* => CDCLK >= compressed_bpp * Pixel clock / (PPC * Bigjoiner
Interface bits)
+*
+* Since Num of pipes joined = 2, and PPC = 2 with bigjoiner
+* => CDCLK >= compressed_bpp * pixel_rate / Bigjoiner
Interface bits
+*
+* #TODO Bspec mentions to account for FEC overhead while using
pixel clock.
+* Check if we need to use FEC overhead in the above
calculations.
+*/
+ int bigjoiner_interface_bits = DISPLAY_VER(i915) > 13 ? 36 : 24;
+ int min_cdclk_bj = crtc_state->dsc.compressed_bpp *
crtc_state->pixel_rate /
+ bigjoiner_interface_bits;
pixel_rate is the downscale adjusted thing, so it doesn't seem
like the correct thing to use here.
Hmm. Assuming that the single VDSC engine really throttles the entire
pipe to 1 PPC then we should probably account for the 1 vs. 2 PPC
difference in *_plane_min_cdclk() and intel_pixel_rate_to_cdclk()
directly. Currently all of those assume 2 PPC.
Hmm alright, I do see in plane_min_cdclk and intel_pixel_rate_to_cdclk
we assume 2 PPC.
So I can add a check for the dsc_split and use 1 PPC/2PPC in the two
functions as a separate patch perhaps.
Main thing is to properly align that one you propose above with that check,
where we decide how many VDSC engines to use:
/*
* VDSC engine operates at 1 Pixel per clock, so if peak pixel rate
* is greater than the maximum Cdclock and if slice count is even
* then we need to use 2 VDSC instances.
*/
if (adjusted_mode->crtc_clock > dev_priv->max_cdclk_freq) {
if (pipe_config->dsc.slice_count > 1) {
pipe_config->dsc.dsc_split = true;
} else {
drm_dbg_kms(&dev_priv->drm,
"Cannot split stream to use 2 VDSC
instances\n");
return -EINVAL;
}
}
Otherwise I agree that we should do that check preferrably in *_plane_min_cdclk
and use plane data rate which is adjusted after scaling is applied(I think we
even have correspondent function there)
It is strange that scaling wasn't mentioned in BSpec formula.
I would also say that we should account for number of slices(i.e VDSC engines)
now only in Bigjoiner case, but always, as I understand that number can be
different not only for Bigjoiner cases.
Stan
Hmm does it mean:
if (!crtc_state->dsc.dsc_split) {
if (bigjoiner)
min_cdclk = compressed_bpp * Pixel clock / (PPC * Bigjoiner
Interface bits);
else
Re: [Intel-gfx] [v2, 11/12] drm/fbdev-generic: Implement dedicated fbdev I/O helpers
Hi,
On 2023/5/17 15:07, Thomas Zimmermann wrote:
Hi
Am 17.05.23 um 03:58 schrieb Sui Jingfeng:
Hi, Thomas
After apply your patch set, the kernel with
arch/loongarch/configs/loongson3_defconfig
can not finish compile anymore. gcc complains:
AR drivers/gpu/built-in.a
AR drivers/built-in.a
AR built-in.a
AR vmlinux.a
LD vmlinux.o
OBJCOPY modules.builtin.modinfo
GEN modules.builtin
GEN .vmlinux.objs
MODPOST Module.symvers
ERROR: modpost: "fb_sys_write" [drivers/gpu/drm/drm_kms_helper.ko]
undefined!
ERROR: modpost: "sys_imageblit" [drivers/gpu/drm/drm_kms_helper.ko]
undefined!
ERROR: modpost: "sys_fillrect" [drivers/gpu/drm/drm_kms_helper.ko]
undefined!
ERROR: modpost: "sys_copyarea" [drivers/gpu/drm/drm_kms_helper.ko]
undefined!
ERROR: modpost: "fb_sys_read" [drivers/gpu/drm/drm_kms_helper.ko]
undefined!
make[1]: *** [scripts/Makefile.modpost:136: Module.symvers] Error 1
make: *** [Makefile:1978: modpost] Error 2
Thanks for reporting this problem. I found that it's caused by a typo
in the very first patch 1/7, where these helpers are not selected
correctly. Will be fixed in the next round.
Yeah, this is just a typo.
Should replace 'FB_SYS_HELPER' with 'FB_SYS_HELPERS' on the first patch
of this series.
Best regards
Thomas
On 2023/5/15 17:40, Thomas Zimmermann wrote:
Implement dedicated fbdev helpers for framebuffer I/O instead
of using DRM's helpers. Fbdev-generic was the only caller of the
DRM helpers, so remove them from the helper module.
v2:
* use FB_SYS_HELPERS_DEFERRED option
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/Kconfig | 6 +-
drivers/gpu/drm/drm_fb_helper.c | 107
drivers/gpu/drm/drm_fbdev_generic.c | 47 ++--
include/drm/drm_fb_helper.h | 41 ---
4 files changed, 43 insertions(+), 158 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 77fb10ddd8a2..92a782827b7b 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -95,6 +95,7 @@ config DRM_KUNIT_TEST
config DRM_KMS_HELPER
tristate
depends on DRM
+ select FB_SYS_HELPERS_DEFERRED if DRM_FBDEV_EMULATION
Here, select FB_SYS_HELPERS helps resolve the above issue mentioned.
But select FB_SYS_HELPERS here is more better, I think. Because it show
the nature that
DRM_KMS_HELPER is depend on FB_SYS_HELPERS, I think you may want isolate
those dependency with DRM_FBDEV_EMULATION guard.
at least, you should guarantee that drm itself could built and run
standalone.
Fbdev emulation is a client of drm, not reverse.
By the way, does Denial happy about this,
maybe, he want the fbdev emulation 100% made in drm?
help
CRTC helpers for KMS drivers.
@@ -135,11 +136,6 @@ config DRM_FBDEV_EMULATION
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
- select FB_DEFERRED_IO
- select FB_SYS_FOPS
- select FB_SYS_FILLRECT
- select FB_SYS_COPYAREA
- select FB_SYS_IMAGEBLIT
select FRAMEBUFFER_CONSOLE if !EXPERT
select FRAMEBUFFER_CONSOLE_DETECT_PRIMARY if FRAMEBUFFER_CONSOLE
default y
diff --git a/drivers/gpu/drm/drm_fb_helper.c
b/drivers/gpu/drm/drm_fb_helper.c
index 8724e08c518b..ba0a808f14ee 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -729,113 +729,6 @@ void drm_fb_helper_deferred_io(struct fb_info
*info, struct list_head *pagerefli
}
EXPORT_SYMBOL(drm_fb_helper_deferred_io);
-/**
- * drm_fb_helper_sys_read - Implements struct &fb_ops.fb_read for
system memory
- * @info: fb_info struct pointer
- * @buf: userspace buffer to read from framebuffer memory
- * @count: number of bytes to read from framebuffer memory
- * @ppos: read offset within framebuffer memory
- *
- * Returns:
- * The number of bytes read on success, or an error code otherwise.
- */
-ssize_t drm_fb_helper_sys_read(struct fb_info *info, char __user *buf,
- size_t count, loff_t *ppos)
-{
- return fb_sys_read(info, buf, count, ppos);
-}
-EXPORT_SYMBOL(drm_fb_helper_sys_read);
-
-/**
- * drm_fb_helper_sys_write - Implements struct &fb_ops.fb_write for
system memory
- * @info: fb_info struct pointer
- * @buf: userspace buffer to write to framebuffer memory
- * @count: number of bytes to write to framebuffer memory
- * @ppos: write offset within framebuffer memory
- *
- * Returns:
- * The number of bytes written on success, or an error code otherwise.
- */
-ssize_t drm_fb_helper_sys_write(struct fb_info *info, const char
__user *buf,
- size_t count, loff_t *ppos)
-{
- struct drm_fb_helper *helper = info->par;
- loff_t pos = *ppos;
- ssize_t ret;
- struct drm_rect damage_area;
-
- ret = fb_sys_write(info, buf, count, ppos);
- if (ret <= 0)
- return ret;
-
- if (helper->funcs->fb_dirty) {
- drm_fb_helper_memory_range_to_clip(info, pos, ret
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v5,1/2] drm/i915/mtl: Add MTL performance tuning changes
== Series Details ==
Series: series starting with [v5,1/2] drm/i915/mtl: Add MTL performance tuning
changes
URL : https://patchwork.freedesktop.org/series/117923/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13161_full -> Patchwork_117923v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Known issues
Here are the changes found in Patchwork_117923v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk: [PASS][1] -> [FAIL][2] ([i915#2842])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13161/shard-glk8/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117923v1/shard-glk1/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_ppgtt@blt-vs-render-ctxn:
- shard-snb: [PASS][3] -> [FAIL][4] ([i915#8295])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13161/shard-snb4/igt@gem_pp...@blt-vs-render-ctxn.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117923v1/shard-snb6/igt@gem_pp...@blt-vs-render-ctxn.html
* igt@gem_softpin@noreloc-s3:
- shard-apl: [PASS][5] -> [ABORT][6] ([i915#8213])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13161/shard-apl3/igt@gem_soft...@noreloc-s3.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117923v1/shard-apl3/igt@gem_soft...@noreloc-s3.html
* igt@gen9_exec_parse@allowed-single:
- shard-apl: [PASS][7] -> [ABORT][8] ([i915#5566])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13161/shard-apl1/igt@gen9_exec_pa...@allowed-single.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117923v1/shard-apl3/igt@gen9_exec_pa...@allowed-single.html
* igt@i915_selftest@live@gt_heartbeat:
- shard-apl: [PASS][9] -> [DMESG-FAIL][10] ([i915#5334])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13161/shard-apl6/igt@i915_selftest@live@gt_heartbeat.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117923v1/shard-apl6/igt@i915_selftest@live@gt_heartbeat.html
* igt@kms_dither@fb-8bpc-vs-panel-6bpc@pipe-a-hdmi-a-1:
- shard-glk: NOTRUN -> [SKIP][11] ([fdo#109271])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117923v1/shard-glk7/igt@kms_dither@fb-8bpc-vs-panel-6...@pipe-a-hdmi-a-1.html
* igt@kms_flip@plain-flip-fb-recreate@b-hdmi-a2:
- shard-glk: [PASS][12] -> [FAIL][13] ([i915#2122])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13161/shard-glk8/igt@kms_flip@plain-flip-fb-recre...@b-hdmi-a2.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117923v1/shard-glk7/igt@kms_flip@plain-flip-fb-recre...@b-hdmi-a2.html
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-shrfb-draw-mmap-cpu:
- shard-apl: NOTRUN -> [SKIP][14] ([fdo#109271]) +6 similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117923v1/shard-apl1/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-shrfb-draw-mmap-cpu.html
*
igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-25@pipe-c-dp-1:
- shard-apl: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#4579])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117923v1/shard-apl1/igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0...@pipe-c-dp-1.html
Possible fixes
* igt@gem_ctx_exec@basic-nohangcheck:
- {shard-rkl}:[FAIL][16] ([i915#6268]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13161/shard-rkl-4/igt@gem_ctx_e...@basic-nohangcheck.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117923v1/shard-rkl-1/igt@gem_ctx_e...@basic-nohangcheck.html
* igt@gem_exec_fair@basic-none@bcs0:
- {shard-rkl}:[FAIL][18] ([i915#2842]) -> [PASS][19] +1 similar
issue
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13161/shard-rkl-1/igt@gem_exec_fair@basic-n...@bcs0.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117923v1/shard-rkl-3/igt@gem_exec_fair@basic-n...@bcs0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [FAIL][20] ([i915#2842]) -> [PASS][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13161/shard-glk2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117923v1/shard-glk5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
- {shard-tglu}: [FAIL][22] ([i915#2842]) -> [PASS][23]
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13161/shard-tglu-3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117923v1/shard-tglu-3/igt@gem_exec_fair@basic-pace-sh...@rcs0.ht
Re: [Intel-gfx] [PATCH v5 08/10] iommufd: Add iommufd_ctx_has_group()
> From: Alex Williamson
> Sent: Thursday, May 18, 2023 3:40 AM
>
> On Sat, 13 May 2023 06:21:34 -0700
> Yi Liu wrote:
>
> > to check if any device within the given iommu_group has been bound with
>
> Nit, I find these commit logs where the subject line is intended to
> flow into the commit log to form a complete sentence difficult to read.
> I expect complete thoughts within the commit log itself and the subject
> should be a separate summary of the log. Repeating the subject within
> the commit log is ok.
Sure. I'll go through the commit messages.
>
> > the iommufd_ctx. This helpful for the checking on device ownership for
>
> s/This/This is/
>
> > the devices which have been bound but cannot be bound to any other iommufd
>
> s/have been/have not been/?
>
> > as the iommu_group has been bound.
> >
> > Signed-off-by: Yi Liu
> > ---
> > drivers/iommu/iommufd/device.c | 29 +
> > include/linux/iommufd.h| 8
> > 2 files changed, 37 insertions(+)
> >
> > diff --git a/drivers/iommu/iommufd/device.c b/drivers/iommu/iommufd/device.c
> > index 81466b97023f..5e5f7912807b 100644
> > --- a/drivers/iommu/iommufd/device.c
> > +++ b/drivers/iommu/iommufd/device.c
> > @@ -98,6 +98,35 @@ struct iommufd_device *iommufd_device_bind(struct
> iommufd_ctx *ictx,
> > }
> > EXPORT_SYMBOL_NS_GPL(iommufd_device_bind, IOMMUFD);
> >
> > +/**
> > + * iommufd_ctx_has_group - True if the struct device is bound to this ictx
>
> What struct device? Isn't this "True if any device within the group is
> bound to the ictx"?
Yes, yes. a poor copy from a prior version..
>
> > + * @ictx: iommufd file descriptor
> > + * @group: Pointer to a physical iommu_group struct
> > + *
> > + * True if a iommufd_device_bind() is present for any device within the
> > + * group.
>
> How can a function be present for a device? Maybe "True if any device
> within the group has been bound to this ictx, ex. via
> iommufd_device_bind(), therefore implying ictx ownership of the group."
> Thanks,
Yes, this is the meaning of it. will fix it.
Regards,
Yi Liu
>
> > + */
> > +bool iommufd_ctx_has_group(struct iommufd_ctx *ictx, struct iommu_group
> > *group)
> > +{
> > + struct iommufd_object *obj;
> > + unsigned long index;
> > +
> > + if (!ictx || !group)
> > + return false;
> > +
> > + xa_lock(&ictx->objects);
> > + xa_for_each(&ictx->objects, index, obj) {
> > + if (obj->type == IOMMUFD_OBJ_DEVICE &&
> > + container_of(obj, struct iommufd_device, obj)->group ==
> > group) {
> > + xa_unlock(&ictx->objects);
> > + return true;
> > + }
> > + }
> > + xa_unlock(&ictx->objects);
> > + return false;
> > +}
> > +EXPORT_SYMBOL_NS_GPL(iommufd_ctx_has_group, IOMMUFD);
> > +
> > /**
> > * iommufd_device_unbind - Undo iommufd_device_bind()
> > * @idev: Device returned by iommufd_device_bind()
> > diff --git a/include/linux/iommufd.h b/include/linux/iommufd.h
> > index 68cd65274e28..e49c16cd6831 100644
> > --- a/include/linux/iommufd.h
> > +++ b/include/linux/iommufd.h
> > @@ -16,6 +16,7 @@ struct page;
> > struct iommufd_ctx;
> > struct iommufd_access;
> > struct file;
> > +struct iommu_group;
> >
> > struct iommufd_device *iommufd_device_bind(struct iommufd_ctx *ictx,
> >struct device *dev, u32 *id);
> > @@ -56,6 +57,7 @@ void iommufd_ctx_get(struct iommufd_ctx *ictx);
> > #if IS_ENABLED(CONFIG_IOMMUFD)
> > struct iommufd_ctx *iommufd_ctx_from_file(struct file *file);
> > void iommufd_ctx_put(struct iommufd_ctx *ictx);
> > +bool iommufd_ctx_has_group(struct iommufd_ctx *ictx, struct iommu_group
> > *group);
> >
> > int iommufd_access_pin_pages(struct iommufd_access *access, unsigned long
> > iova,
> > unsigned long length, struct page **out_pages,
> > @@ -77,6 +79,12 @@ static inline void iommufd_ctx_put(struct iommufd_ctx
> > *ictx)
> > {
> > }
> >
> > +static inline bool iommufd_ctx_has_group(struct iommufd_ctx *ictx,
> > +struct iommu_group *group)
> > +{
> > + return false;
> > +}
> > +
> > static inline int iommufd_access_pin_pages(struct iommufd_access *access,
> >unsigned long iova,
> >unsigned long length,
Re: [Intel-gfx] [PATCH v5 07/10] vfio: Add helper to search vfio_device in a dev_set
> From: Alex Williamson
> Sent: Thursday, May 18, 2023 3:13 AM
>
> On Sat, 13 May 2023 06:21:33 -0700
> Yi Liu wrote:
>
> > There are drivers that need to search vfio_device within a given dev_set.
> > e.g. vfio-pci. So add a helper.
> >
> > Signed-off-by: Yi Liu
> > ---
> > drivers/vfio/pci/vfio_pci_core.c | 8 +++-
> > drivers/vfio/vfio_main.c | 15 +++
> > include/linux/vfio.h | 3 +++
> > 3 files changed, 21 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/vfio/pci/vfio_pci_core.c
> > b/drivers/vfio/pci/vfio_pci_core.c
> > index 39e7823088e7..4df2def35bdd 100644
> > --- a/drivers/vfio/pci/vfio_pci_core.c
> > +++ b/drivers/vfio/pci/vfio_pci_core.c
> > @@ -2335,12 +2335,10 @@ static bool vfio_dev_in_groups(struct
> vfio_pci_core_device *vdev,
> > static int vfio_pci_is_device_in_set(struct pci_dev *pdev, void *data)
> > {
> > struct vfio_device_set *dev_set = data;
> > - struct vfio_device *cur;
> >
> > - list_for_each_entry(cur, &dev_set->device_list, dev_set_list)
> > - if (cur->dev == &pdev->dev)
> > - return 0;
> > - return -EBUSY;
> > + lockdep_assert_held(&dev_set->lock);
> > +
> > + return vfio_find_device_in_devset(dev_set, &pdev->dev) ? 0 : -EBUSY;
>
> Maybe an opportunity to revisit why this returns -EBUSY rather than
> something reasonable like -ENODEV. It looks like we picked up the
> -EBUSY in a882c16a2b7e where I think it was trying to preserve the
> return of vfio_pci_try_zap_and_vma_lock_cb() but the return value here
> is not even propagated so this looks like an chance to have it make
> sense again. Thanks,
>From the name of this function, yes, -ENODEV is better. is it
Ok to modify it to be -ENODEV in this patch or a separate one?
Regards,
Yi Liu
>
> > }
> >
> > /*
> > diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
> > index f0ca33b2e1df..ab4f3a794f78 100644
> > --- a/drivers/vfio/vfio_main.c
> > +++ b/drivers/vfio/vfio_main.c
> > @@ -141,6 +141,21 @@ unsigned int vfio_device_set_open_count(struct
> vfio_device_set *dev_set)
> > }
> > EXPORT_SYMBOL_GPL(vfio_device_set_open_count);
> >
> > +struct vfio_device *
> > +vfio_find_device_in_devset(struct vfio_device_set *dev_set,
> > + struct device *dev)
> > +{
> > + struct vfio_device *cur;
> > +
> > + lockdep_assert_held(&dev_set->lock);
> > +
> > + list_for_each_entry(cur, &dev_set->device_list, dev_set_list)
> > + if (cur->dev == dev)
> > + return cur;
> > + return NULL;
> > +}
> > +EXPORT_SYMBOL_GPL(vfio_find_device_in_devset);
> > +
> > /*
> > * Device objects - create, release, get, put, search
> > */
> > diff --git a/include/linux/vfio.h b/include/linux/vfio.h
> > index fcbe084b18c8..4c17395ed4d2 100644
> > --- a/include/linux/vfio.h
> > +++ b/include/linux/vfio.h
> > @@ -259,6 +259,9 @@ void vfio_unregister_group_dev(struct vfio_device
> > *device);
> >
> > int vfio_assign_device_set(struct vfio_device *device, void *set_id);
> > unsigned int vfio_device_set_open_count(struct vfio_device_set *dev_set);
> > +struct vfio_device *
> > +vfio_find_device_in_devset(struct vfio_device_set *dev_set,
> > + struct device *dev);
> >
> > int vfio_mig_get_next_state(struct vfio_device *device,
> > enum vfio_device_mig_state cur_fsm,
Re: [Intel-gfx] [PATCH v5 01/10] vfio-iommufd: Create iommufd_access for noiommu devices
> From: Jason Gunthorpe > Sent: Thursday, May 18, 2023 2:21 AM > > On Wed, May 17, 2023 at 11:26:09AM -0600, Alex Williamson wrote: > > > It's not clear to me why we need a separate iommufd_access for > > noiommu. > > The point was to allocate an ID for the device so we can use that ID > with the other interfaces in all cases. I guess Alex's question is why adding a new pointer named noiommu_access while there is already the iommufd_access pointer named iommufd_access. Maybe we shall reuse the iommufd_access pointer? Regards, Yi Liu
Re: [Intel-gfx] [PATCH 5/5] drm/i915/display: Handle GMD_ID identification in display code
On 18.05.2023 05:18, Matt Roper wrote:
For platforms with GMD_ID support (i.e., everything MTL and beyond),
identification of the display IP present should be based on the contents
of the GMD_ID register rather than a PCI devid match.
Note that since GMD_ID readout requires access to the PCI BAR, a slight
change to the driver init sequence is needed --- pci_enable_device() is
now called before i915_driver_create().
Signed-off-by: Matt Roper
---
.../drm/i915/display/intel_display_device.c | 64 +--
.../drm/i915/display/intel_display_device.h | 5 +-
drivers/gpu/drm/i915/i915_driver.c| 10 +--
drivers/gpu/drm/i915/intel_device_info.c | 13 ++--
4 files changed, 78 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_device.c
b/drivers/gpu/drm/i915/display/intel_display_device.c
index 78fa522aaf0b..813a2a494082 100644
--- a/drivers/gpu/drm/i915/display/intel_display_device.c
+++ b/drivers/gpu/drm/i915/display/intel_display_device.c
@@ -6,7 +6,10 @@
#include
#include
#include
+#include
+#include "i915_drv.h"
+#include "i915_reg.h"
#include "intel_display_device.h"
#include "intel_display_power.h"
#include "intel_display_reg_defs.h"
@@ -674,18 +677,69 @@ static const struct pci_device_id intel_display_ids[] = {
INTEL_RPLP_IDS(&xe_lpd_display),
INTEL_DG2_IDS(&xe_hpd_display),
- /* FIXME: Replace this with a GMD_ID lookup */
- INTEL_MTL_IDS(&xe_lpdp_display),
+ /*
+* Do not add any GMD_ID-based platforms to this list. They will
+* be probed automatically based on the IP version reported by
+* the hardware.
+*/
};
+struct {
+ u16 ver;
+ u16 rel;
+ const struct intel_display_device_info *display;
+} gmdid_display_map[] = {
+ { 14, 0, &xe_lpdp_display },
+};
+
+static const struct intel_display_device_info *
+probe_gmdid_display(struct drm_i915_private *i915, u16 *ver, u16 *rel, u16
*step)
+{
+ struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
+ void __iomem *addr;
+ u32 val;
+ int i;
+
+ addr = pci_iomap_range(pdev, 0, i915_mmio_reg_offset(GMD_ID_DISPLAY),
sizeof(u32));
+ if (!addr) {
+ drm_err(&i915->drm, "Cannot map MMIO BAR to read display
GMD_ID\n");
+ return NULL;
+ }
+
+ val = ioread32(addr);
+ pci_iounmap(pdev, addr);
+
+ if (val == 0)
+ /* Platform doesn't have display */
+ return NULL;
+
+ *ver = REG_FIELD_GET(GMD_ID_ARCH_MASK, val);
+ *rel = REG_FIELD_GET(GMD_ID_RELEASE_MASK, val);
+ *step = REG_FIELD_GET(GMD_ID_STEP, val);
+
+ for (i = 0; i < ARRAY_SIZE(gmdid_display_map); i++)
+ if (*ver == gmdid_display_map[i].ver &&
+ *rel == gmdid_display_map[i].rel)
+ return gmdid_display_map[i].display;
+
+ drm_err(&i915->drm, "Unrecognized display IP version %d.%02d; disabling
display.\n",
+ *ver, *rel);
+ return NULL;
+}
+
const struct intel_display_device_info *
-intel_display_device_probe(u16 pci_devid)
+intel_display_device_probe(struct drm_i915_private *i915, bool has_gmdid,
+ u16 *gmdid_ver, u16 *gmdid_rel, u16 *gmdid_step)
{
+ struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
int i;
+ if (has_gmdid)
+ return probe_gmdid_display(i915, gmdid_ver, gmdid_rel,
gmdid_step);
+
for (i = 0; i < ARRAY_SIZE(intel_display_ids); i++) {
- if (intel_display_ids[i].device == pci_devid)
- return (struct intel_display_device_info
*)intel_display_ids[i].driver_data;
+ if (intel_display_ids[i].device == pdev->device)
+ return (const struct intel_display_device_info
*)intel_display_ids[i].driver_data;
}
return NULL;
diff --git a/drivers/gpu/drm/i915/display/intel_display_device.h
b/drivers/gpu/drm/i915/display/intel_display_device.h
index 0a60ebfaff80..9a344ee36d8c 100644
--- a/drivers/gpu/drm/i915/display/intel_display_device.h
+++ b/drivers/gpu/drm/i915/display/intel_display_device.h
@@ -80,7 +80,10 @@ struct intel_display_device_info {
} color;
};
+struct drm_i915_private;
+
const struct intel_display_device_info *
-intel_display_device_probe(u16 pci_devid);
+intel_display_device_probe(struct drm_i915_private *i915, bool has_gmdid,
+ u16 *ver, u16 *rel, u16 *step);
#endif
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index 522733a89946..d02c602e9a0b 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -754,14 +754,16 @@ int i915_driver_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
struct drm_i915_private *i915;
int ret;
- i915 = i915_driver_create(pdev, ent);
- if (IS_ERR(i915))
-
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/mtl: do not enable render power-gating on MTL (rev2)
== Series Details ==
Series: drm/i915/mtl: do not enable render power-gating on MTL (rev2)
URL : https://patchwork.freedesktop.org/series/117883/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13160_full -> Patchwork_117883v2_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Known issues
Here are the changes found in Patchwork_117883v2_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-apl: [PASS][1] -> [FAIL][2] ([i915#2346]) +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13160/shard-apl6/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117883v2/shard-apl2/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible@a-dp1:
- shard-apl: [PASS][3] -> [FAIL][4] ([i915#79])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13160/shard-apl4/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-dp1.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117883v2/shard-apl6/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-dp1.html
Possible fixes
* igt@gem_barrier_race@remote-request@rcs0:
- {shard-dg1}:[ABORT][5] ([i915#7461] / [i915#8234]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13160/shard-dg1-17/igt@gem_barrier_race@remote-requ...@rcs0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117883v2/shard-dg1-16/igt@gem_barrier_race@remote-requ...@rcs0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- {shard-tglu}: [FAIL][7] ([i915#2842]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13160/shard-tglu-6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117883v2/shard-tglu-9/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_exec_fair@basic-pace@rcs0:
- {shard-rkl}:[FAIL][9] ([i915#2842]) -> [PASS][10] +3 similar
issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13160/shard-rkl-7/igt@gem_exec_fair@basic-p...@rcs0.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117883v2/shard-rkl-4/igt@gem_exec_fair@basic-p...@rcs0.html
* igt@i915_module_load@reload-with-fault-injection:
- {shard-dg1}:[DMESG-WARN][11] ([i915#4391]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13160/shard-dg1-17/igt@i915_module_l...@reload-with-fault-injection.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117883v2/shard-dg1-16/igt@i915_module_l...@reload-with-fault-injection.html
* igt@i915_pm_lpsp@kms-lpsp@kms-lpsp-hdmi-a:
- {shard-rkl}:[SKIP][13] ([i915#1937] / [i915#4579]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13160/shard-rkl-2/igt@i915_pm_lpsp@kms-l...@kms-lpsp-hdmi-a.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117883v2/shard-rkl-7/igt@i915_pm_lpsp@kms-l...@kms-lpsp-hdmi-a.html
* igt@i915_pm_rc6_residency@rc6-idle@vcs0:
- {shard-dg1}:[FAIL][15] ([i915#3591]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13160/shard-dg1-14/igt@i915_pm_rc6_residency@rc6-i...@vcs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117883v2/shard-dg1-15/igt@i915_pm_rc6_residency@rc6-i...@vcs0.html
* igt@i915_pm_rpm@dpms-mode-unset-lpsp:
- {shard-rkl}:[SKIP][17] ([i915#1397]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13160/shard-rkl-1/igt@i915_pm_...@dpms-mode-unset-lpsp.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117883v2/shard-rkl-7/igt@i915_pm_...@dpms-mode-unset-lpsp.html
* igt@i915_pm_rps@reset:
- {shard-tglu}: [INCOMPLETE][19] ([i915#8320]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13160/shard-tglu-5/igt@i915_pm_...@reset.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117883v2/shard-tglu-8/igt@i915_pm_...@reset.html
* igt@kms_cursor_legacy@forked-bo@pipe-b:
- {shard-rkl}:[INCOMPLETE][21] ([i915#8011]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13160/shard-rkl-7/igt@kms_cursor_legacy@forked...@pipe-b.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117883v2/shard-rkl-6/igt@kms_cursor_legacy@forked...@pipe-b.html
* igt@kms_flip@2x-plain-flip-fb-recreate-interruptible@bc-hdmi-a1-hdmi-a2:
- shard-glk: [FAIL][23] ([i915#2122]) -> [PASS][24] +1 similar
issue
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13160/shard-glk8/igt@kms_
[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/6] drm/i915/display: Add support for global histogram
== Series Details == Series: series starting with [1/6] drm/i915/display: Add support for global histogram URL : https://patchwork.freedesktop.org/series/117948/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/117948/revisions/1/mbox/ not applied Applying: drm/i915/display: Add support for global histogram error: sha1 information is lacking or useless (drivers/gpu/drm/i915/Makefile). error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 drm/i915/display: Add support for global histogram 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". Build failed, no error log produced
Re: [Intel-gfx] [PATCH 4/5] drm/i915/display: Make display responsible for probing its own IP
On 18.05.2023 05:18, Matt Roper wrote:
Rather than selecting the display IP and feature flags at the same time
the general PCI probing happens, move this step into the display code
itself so that it can be more easily re-used outside of i915 (i.e., by
the Xe driver).
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/Makefile | 2 +
.../drm/i915/display/intel_display_device.c | 692 ++
.../drm/i915/display/intel_display_device.h | 3 +
drivers/gpu/drm/i915/i915_pci.c | 650
drivers/gpu/drm/i915/i915_reg.h | 33 -
drivers/gpu/drm/i915/intel_device_info.c | 13 +-
6 files changed, 707 insertions(+), 686 deletions(-)
create mode 100644 drivers/gpu/drm/i915/display/intel_display_device.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index dd9ca69f4998..06374fc072d3 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -25,6 +25,7 @@ subdir-ccflags-$(CONFIG_DRM_I915_WERROR) += -Werror
# Fine grained warnings disable
CFLAGS_i915_pci.o = $(call cc-disable-warning, override-init)
+CFLAGS_display/intel_display_device.o = $(call cc-disable-warning,
override-init)
CFLAGS_display/intel_fbdev.o = $(call cc-disable-warning, override-init)
subdir-ccflags-y += -I$(srctree)/$(src)
@@ -308,6 +309,7 @@ i915-y += \
display/intel_cx0_phy.o \
display/intel_ddi.o \
display/intel_ddi_buf_trans.o \
+ display/intel_display_device.o \
display/intel_display_trace.o \
display/intel_dkl_phy.o \
display/intel_dp.o \
diff --git a/drivers/gpu/drm/i915/display/intel_display_device.c
b/drivers/gpu/drm/i915/display/intel_display_device.c
new file mode 100644
index ..78fa522aaf0b
--- /dev/null
+++ b/drivers/gpu/drm/i915/display/intel_display_device.c
@@ -0,0 +1,692 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2023 Intel Corporation
+ */
+
+#include
+#include
+#include
+
+#include "intel_display_device.h"
+#include "intel_display_power.h"
+#include "intel_display_reg_defs.h"
+#include "intel_fbc.h"
+
+#define PIPE_A_OFFSET 0x7
+#define PIPE_B_OFFSET 0x71000
+#define PIPE_C_OFFSET 0x72000
+#define PIPE_D_OFFSET 0x73000
+#define CHV_PIPE_C_OFFSET 0x74000
+/*
+ * There's actually no pipe EDP. Some pipe registers have
+ * simply shifted from the pipe to the transcoder, while
+ * keeping their original offset. Thus we need PIPE_EDP_OFFSET
+ * to access such registers in transcoder EDP.
+ */
+#define PIPE_EDP_OFFSET0x7f000
+
+/* ICL DSI 0 and 1 */
+#define PIPE_DSI0_OFFSET 0x7b000
+#define PIPE_DSI1_OFFSET 0x7b800
+
+#define TRANSCODER_A_OFFSET 0x6
+#define TRANSCODER_B_OFFSET 0x61000
+#define TRANSCODER_C_OFFSET 0x62000
+#define CHV_TRANSCODER_C_OFFSET 0x63000
+#define TRANSCODER_D_OFFSET 0x63000
+#define TRANSCODER_EDP_OFFSET 0x6f000
+#define TRANSCODER_DSI0_OFFSET 0x6b000
+#define TRANSCODER_DSI1_OFFSET 0x6b800
+
+#define CURSOR_A_OFFSET 0x70080
+#define CURSOR_B_OFFSET 0x700c0
+#define CHV_CURSOR_C_OFFSET 0x700e0
+#define IVB_CURSOR_B_OFFSET 0x71080
+#define IVB_CURSOR_C_OFFSET 0x72080
+#define TGL_CURSOR_D_OFFSET 0x73080
+
+#define I845_PIPE_OFFSETS \
+ .pipe_offsets = { \
+ [TRANSCODER_A] = PIPE_A_OFFSET, \
+ }, \
+ .trans_offsets = { \
+ [TRANSCODER_A] = TRANSCODER_A_OFFSET, \
+ }
+
+#define I9XX_PIPE_OFFSETS \
+ .pipe_offsets = { \
+ [TRANSCODER_A] = PIPE_A_OFFSET, \
+ [TRANSCODER_B] = PIPE_B_OFFSET, \
+ }, \
+ .trans_offsets = { \
+ [TRANSCODER_A] = TRANSCODER_A_OFFSET, \
+ [TRANSCODER_B] = TRANSCODER_B_OFFSET, \
+ }
+
+#define IVB_PIPE_OFFSETS \
+ .pipe_offsets = { \
+ [TRANSCODER_A] = PIPE_A_OFFSET, \
+ [TRANSCODER_B] = PIPE_B_OFFSET, \
+ [TRANSCODER_C] = PIPE_C_OFFSET, \
+ }, \
+ .trans_offsets = { \
+ [TRANSCODER_A] = TRANSCODER_A_OFFSET, \
+ [TRANSCODER_B] = TRANSCODER_B_OFFSET, \
+ [TRANSCODER_C] = TRANSCODER_C_OFFSET, \
+ }
+
+#define HSW_PIPE_OFFSETS \
+ .pipe_offsets = { \
+ [TRANSCODER_A] = PIPE_A_OFFSET, \
+ [TRANSCODER_B] = PIPE_B_OFFSET, \
+ [TRANSCODER_C] = PIPE_C_OFFSET, \
+ [TRANSCODER_EDP] = PIPE_EDP_OFFSET, \
+ }, \
+ .trans_offsets = { \
+ [TRANSCODER_A] = TRANSCODER_A_OFFSET, \
+ [TRANSCODER_B] = TRANSCODER_B_OFFSET, \
+ [TRANSCODER_C] = TRANSCODER_C_OFFSET, \
+ [TRANSCODER_EDP] = TRANSCODER_EDP_OFFSET, \
+ }
+
+#define CHV_PIPE_OFFSETS \
+ .pipe_offsets = { \
+ [TRANSCODER_A] = PIPE_A_OFFSET, \
+ [TRANSCODER_B] = PIPE_B_OFFSET, \
+ [TRANSCODER_C] = CHV_PIPE_C_OFFSET, \
+ },
[Intel-gfx] [PATCH 6/6] drm/i915/display: Enable global hist Selective fetch
This patch enables support for selective fetch in global histogram.
User can provide the selective fetch co-ordinates and only that region
will be used in generating the histogram.
Signed-off-by: Arun R Murthy
---
.../gpu/drm/i915/display/intel_global_hist.c | 65 +++
.../gpu/drm/i915/display/intel_global_hist.h | 14
2 files changed, 79 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_global_hist.c
b/drivers/gpu/drm/i915/display/intel_global_hist.c
index 874d80d1e41b..13ec68463eec 100644
--- a/drivers/gpu/drm/i915/display/intel_global_hist.c
+++ b/drivers/gpu/drm/i915/display/intel_global_hist.c
@@ -31,6 +31,48 @@
#include "intel_de.h"
#include "intel_global_hist.h"
+#define MIN_SEGMENTS 32
+#define MAX_SEGMENTS 128
+
+static int intel_global_hist_calc_seg_size(struct drm_i915_private *dev_priv,
+ enum pipe pipe)
+{
+ uint32_t tmp, source_height;
+ uint16_t seg_size = MIN_SEGMENTS;
+
+ /* Get the pipe source height from the pipesr register */
+ tmp = intel_de_read(dev_priv, PIPESRC(pipe));
+ source_height = REG_FIELD_GET(PIPESRC_HEIGHT_MASK, tmp) + 1;
+
+ while (seg_size <= source_height) {
+ if ((seg_size % source_height == 0) &&
+ ((source_height / seg_size) < MAX_SEGMENTS))
+ break;
+ seg_size++;
+ }
+
+ return seg_size;
+}
+
+int intel_global_hist_sf_update_seg(struct drm_i915_private *i915,
+ enum pipe pipe, struct drm_rect *clip)
+{
+ uint16_t seg_size;
+
+ seg_size = intel_global_hist_calc_seg_size(i915, pipe);
+ if (!seg_size)
+ return -EINVAL;
+
+ intel_de_rmw(i915, DPST_SF_SEG(pipe),
+DPST_SF_SEG_SIZE_MASK | DPST_SF_SEG_START_MASK |
+DPST_SF_SEG_END_MASK,
+DPST_SF_SEG_SIZE(seg_size) |
+DPST_SF_SEG_START((clip->y2/seg_size) * seg_size) |
+DPST_SF_SEG_END((clip->y1/seg_size) * seg_size));
+
+ return 0;
+}
+
static int intel_global_hist_get_data(struct drm_i915_private *i915,
enum pipe pipe)
{
@@ -258,6 +300,29 @@ int intel_global_hist_set_iet_lut(struct intel_crtc
*intel_crtc, u32 *data)
return 0;
}
+int intel_global_hist_sf_en(struct drm_i915_private *i915,
+ enum pipe pipe, struct drm_rect *clip)
+{
+ struct intel_crtc *intel_crtc = to_intel_crtc(
+ drm_crtc_from_index(&i915->drm, pipe));
+ struct intel_global_hist *global_hist = intel_crtc->global_hist;
+ uint32_t dpstsfctl;
+
+ /* If DPST is not enabled, enable it first */
+ if (!global_hist->enable)
+ intel_global_hist_enable(intel_crtc);
+
+ /* Program dpst selective fetch */
+ dpstsfctl = intel_de_read(i915, DPST_SF_CTL(pipe));
+ dpstsfctl |= DPST_SF_CTL_ENABLE;
+ intel_de_write(i915, DPST_SF_CTL(pipe), dpstsfctl);
+
+ /* Program the segment size */
+ intel_global_hist_sf_update_seg(i915, pipe, clip);
+
+ return 0;
+}
+
void intel_global_hist_deinit(struct intel_crtc *intel_crtc)
{
struct intel_global_hist *global_hist = intel_crtc->global_hist;
diff --git a/drivers/gpu/drm/i915/display/intel_global_hist.h
b/drivers/gpu/drm/i915/display/intel_global_hist.h
index c6621bf4ea61..827c61badf66 100644
--- a/drivers/gpu/drm/i915/display/intel_global_hist.h
+++ b/drivers/gpu/drm/i915/display/intel_global_hist.h
@@ -82,6 +82,20 @@
#define GLOBAL_HIST_GUARDBAND_PRECISION_FACTOR 1 // Precision factor for
threshold guardband.
#define GLOBAL_HIST_DEFAULT_GUARDBAND_DELAY 0x04
+#define _DPST_SF_CTL_A 0x490D0
+#define _DPST_SF_CTL_B 0x491D0
+#define DPST_SF_CTL(pipe) _MMIO_PIPE(pipe,
_DPST_SF_CTL_A, _DPST_SF_CTL_B)
+#define DPST_SF_CTL_ENABLE (1 << 31)
+#define _DPST_SF_SEG_A 0x490D4
+#define _DPST_SF_SEG_B 0x491D4
+#define DPST_SF_SEG(pipe) _MMIO_PIPE(pipe,
_DPST_SF_CTL_A, _DPST_SF_CTL_B)
+#define DPST_SF_SEG_START_MASK REG_GENMASK(30, 24)
+#define DPST_SF_SEG_START(val)
REG_FIELD_PREP(DPST_SF_SEG_START_MASK, val)
+#define DPST_SF_SEG_END_MASK REG_GENMASK(22, 16)
+#define DPST_SF_SEG_END(val)
REG_FIELD_PREP(DPST_SF_SEG_END_MASK, val)
+#define DPST_SF_SEG_SIZE_MASK REG_GENMASK(15, 0)
+#define DPST_SF_SEG_SIZE(val)
REG_FIELD_PREP(DPST_SF_SEG_SIZE_MASK, val)
+
enum intel_global_hist_status {
INTEL_GLOBAL_HIST_ENABLE,
INTEL_GLOBAL_HIST_DISABLE,
--
2.25.1
[Intel-gfx] [PATCH 4/6] drm/i915/display: Add crtc properties for global histogram
CRTC properties have been added for enable/disable histogram, reading
the histogram data and writing the IET data.
"GLOBAL_HIST_EN" is the crtc property to enable/disable the global
histogram and takes a value 0/1 accordingly.
"Global Histogram" is a crtc property to read the binary histogram data.
"Global IET" is a crtc property to write the IET binary LUT data.
Signed-off-by: Arun R Murthy
---
drivers/gpu/drm/i915/display/intel_atomic.c | 5 +
drivers/gpu/drm/i915/display/intel_crtc.c | 200 +-
drivers/gpu/drm/i915/display/intel_crtc.h | 5 +
drivers/gpu/drm/i915/display/intel_display.c | 13 ++
.../drm/i915/display/intel_display_types.h| 19 +-
.../gpu/drm/i915/display/intel_global_hist.c | 7 +
6 files changed, 246 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
b/drivers/gpu/drm/i915/display/intel_atomic.c
index 0e5d57c978fe..bed682854071 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -245,6 +245,8 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
__drm_atomic_helper_crtc_duplicate_state(crtc, &crtc_state->uapi);
+ if (crtc_state->global_iet)
+ drm_property_blob_get(crtc_state->global_iet);
/* copy color blobs */
if (crtc_state->hw.degamma_lut)
drm_property_blob_get(crtc_state->hw.degamma_lut);
@@ -266,6 +268,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
crtc_state->fb_bits = 0;
crtc_state->update_planes = 0;
crtc_state->dsb = NULL;
+ crtc_state->global_hist_en_changed = false;
return &crtc_state->uapi;
}
@@ -298,6 +301,8 @@ intel_crtc_destroy_state(struct drm_crtc *crtc,
drm_WARN_ON(crtc->dev, crtc_state->dsb);
+ if (crtc_state->global_iet)
+ drm_property_blob_put(crtc_state->global_iet);
__drm_atomic_helper_crtc_destroy_state(&crtc_state->uapi);
intel_crtc_free_hw_state(crtc_state);
kfree(crtc_state);
diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
b/drivers/gpu/drm/i915/display/intel_crtc.c
index 521dc676e2d0..501bcf732aba 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include "i915_irq.h"
#include "i915_vgpu.h"
@@ -26,6 +27,7 @@
#include "intel_display_types.h"
#include "intel_drrs.h"
#include "intel_dsi.h"
+#include "intel_global_hist.h"
#include "intel_pipe_crc.h"
#include "intel_psr.h"
#include "intel_sprite.h"
@@ -196,6 +198,7 @@ static struct intel_crtc *intel_crtc_alloc(void)
static void intel_crtc_free(struct intel_crtc *crtc)
{
intel_crtc_destroy_state(&crtc->base, crtc->base.state);
+ intel_global_hist_deinit(crtc);
kfree(crtc);
}
@@ -215,6 +218,99 @@ static int intel_crtc_late_register(struct drm_crtc *crtc)
return 0;
}
+int intel_crtc_get_property(struct drm_crtc *crtc,
+ const struct drm_crtc_state *state,
+ struct drm_property *property,
+ uint64_t *val)
+{
+ struct drm_i915_private *i915 = to_i915(crtc->dev);
+ struct intel_crtc_state *intel_crtc_state =
+ to_intel_crtc_state(state);
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+
+ if (property == intel_crtc->global_hist_en_property)
+ *val = intel_crtc_state->global_hist_en;
+ else if (property == intel_crtc->global_iet_property)
+ *val = (intel_crtc_state->global_iet) ?
+ intel_crtc_state->global_iet->base.id : 0;
+ else if (property == intel_crtc->global_hist_property)
+ *val = (intel_crtc_state->global_hist) ?
+ intel_crtc_state->global_hist->base.id : 0;
+ else {
+ drm_err(&i915->drm,
+ "Unknown property [PROP:%d:%s]\n",
+ property->base.id, property->name);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int
+intel_atomic_replace_property_blob_from_id(struct drm_device *dev,
+struct drm_property_blob **blob,
+uint64_t blob_id,
+ssize_t expected_size,
+ssize_t expected_elem_size,
+bool *replaced)
+{
+ struct drm_property_blob *new_blob = NULL;
+
+ if (blob_id != 0) {
+ new_blob = drm_property_lookup_blob(dev, blob_id);
+ if (new_blob == NULL)
+ return -EINVAL;
+
+ if (expected_size > 0 &&
+ new_blob->length != expected_size) {
+ drm_property_blob_put(new_blob);
+ retur
[Intel-gfx] [PATCH 5/6] drm/i915/display: crtc property for global hist selective fetch
User can provide the selective fetch co-ordinates for global histogram
using crtc blob property. This patch adds the crtc blob property.
The selective fetch can be done only on the y co-ordinate and cannot be
done on the x co-ordinate.
Signed-off-by: Arun R Murthy
---
drivers/gpu/drm/i915/display/intel_crtc.c | 45 +++
.../drm/i915/display/intel_display_types.h| 3 ++
2 files changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
b/drivers/gpu/drm/i915/display/intel_crtc.c
index 501bcf732aba..2a9dcf3b1a19 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc.c
@@ -236,6 +236,9 @@ int intel_crtc_get_property(struct drm_crtc *crtc,
else if (property == intel_crtc->global_hist_property)
*val = (intel_crtc_state->global_hist) ?
intel_crtc_state->global_hist->base.id : 0;
+ else if (property == intel_crtc->global_hist_sf_clips_property)
+ *val = (intel_crtc_state->global_hist_sf_clips) ?
+ intel_crtc_state->global_hist_sf_clips->base.id : 0;
else {
drm_err(&i915->drm,
"Unknown property [PROP:%d:%s]\n",
@@ -306,6 +309,18 @@ int intel_crtc_set_property(struct drm_crtc *crtc,
return 0;
}
+ if (property == intel_crtc->global_hist_sf_clips_property) {
+ intel_atomic_replace_property_blob_from_id(crtc->dev,
+ &intel_crtc_state->global_hist_sf_clips,
+ val,
+ -1,
+ sizeof(struct drm_rect),
+ &replaced);
+ if (replaced)
+ intel_crtc_state->global_hist_sf_clips_updates = true;
+ return 0;
+ }
+
drm_dbg_atomic(&i915->drm, "Unknown property [PROP:%d:%s]\n",
property->base.id, property->name);
return -EINVAL;
@@ -903,11 +918,41 @@ void intel_attach_global_hist_property(struct intel_crtc
*intel_crtc)
drm_object_attach_property(&crtc->base, prop, blob->base.id);
}
+/**
+ * intel_attach_global_hist_sf_seg_property() - selective fetch segment
property
+ * @intel_crtc: pointer to struct intel_crtc on which global histogram is
enabled
+ *
+ * "Global Histogram SF CLIPS" is the crtc porperty used to provide the
+ * co-ordinates of the damage clips.
+ */
+void intel_attach_global_hist_sf_seg_property(struct intel_crtc * intel_crtc)
+{
+ struct drm_crtc *crtc = &intel_crtc->base;
+ struct drm_device *dev = crtc->dev;
+ struct drm_property *prop;
+ struct drm_property_blob *blob;
+
+ prop = intel_crtc->global_hist_sf_clips_property;
+ if (prop == NULL) {
+ prop = drm_property_create(dev,
+ DRM_MODE_PROP_ATOMIC | DRM_MODE_PROP_BLOB,
+ "Global Histogram SF CLIPS", 0);
+ if (prop == NULL)
+ return;
+ intel_crtc->global_hist_sf_clips_property = prop;
+ }
+ blob = drm_property_create_blob(dev, sizeof(struct drm_rect *), NULL);
+ intel_crtc->config->global_hist_sf_clips = blob;
+
+ drm_object_attach_property(&crtc->base, prop, blob->base.id);
+}
+
int intel_crtc_add_property(struct intel_crtc *intel_crtc)
{
intel_attach_global_hist_en_property(intel_crtc);
intel_attach_global_hist_property(intel_crtc);
intel_attach_global_iet_property(intel_crtc);
+ intel_attach_global_hist_sf_seg_property(intel_crtc);
return 0;
}
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 15d28e2305da..703593d4a52f 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1371,8 +1371,10 @@ struct intel_crtc_state {
int global_hist_en;
struct drm_property_blob *global_iet;
struct drm_property_blob *global_hist;
+ struct drm_property_blob *global_hist_sf_clips;
bool global_iet_changed;
bool global_hist_en_changed;
+ bool global_hist_sf_clips_updates;
};
enum intel_pipe_crc_source {
@@ -1480,6 +1482,7 @@ struct intel_crtc {
struct drm_property *global_hist_en_property;
struct drm_property *global_iet_property;
struct drm_property *global_hist_property;
+ struct drm_property *global_hist_sf_clips_property;
#ifdef CONFIG_DEBUG_FS
struct intel_pipe_crc pipe_crc;
u32 cpu_fifo_underrun_count;
--
2.25.1
[Intel-gfx] [PATCH 3/6] drm/i915/display: global histogram restrictions
For global histogram the panel should be edp and should have pwm based
backlight controller. Flags are updated accordingly.
Reviewed-by: Uma Shankar
Signed-off-by: Arun R Murthy
---
drivers/gpu/drm/i915/display/intel_modeset_setup.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_modeset_setup.c
b/drivers/gpu/drm/i915/display/intel_modeset_setup.c
index cd21b0ddbabb..975d6bdb59f3 100644
--- a/drivers/gpu/drm/i915/display/intel_modeset_setup.c
+++ b/drivers/gpu/drm/i915/display/intel_modeset_setup.c
@@ -17,12 +17,14 @@
#include "intel_crtc_state_dump.h"
#include "intel_ddi.h"
#include "intel_de.h"
+#include "intel_dp.h"
#include "intel_display.h"
#include "intel_display_power.h"
#include "intel_display_types.h"
#include "intel_modeset_setup.h"
#include "intel_pch_display.h"
#include "intel_pm.h"
+#include "intel_global_hist.h"
static void intel_crtc_disable_noatomic(struct intel_crtc *crtc,
struct drm_modeset_acquire_ctx *ctx)
@@ -309,6 +311,7 @@ static void intel_sanitize_encoder(struct intel_encoder
*encoder)
struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
struct intel_crtc_state *crtc_state = crtc ?
to_intel_crtc_state(crtc->base.state) : NULL;
+ struct intel_panel *panel;
/*
* We need to check both for a crtc link (meaning that the encoder is
@@ -376,6 +379,15 @@ static void intel_sanitize_encoder(struct intel_encoder
*encoder)
if (HAS_DDI(i915))
intel_ddi_sanitize_encoder_pll_mapping(encoder);
+
+ /* validate the global hist struct elements */
+ if (intel_dp_is_port_edp(i915, encoder->port)) {
+ crtc->global_hist->has_edp = true;
+ panel = &connector->panel;
+ if (panel->backlight.present == true)
+ crtc->global_hist->has_pwm = true;
+ }
+
}
/* FIXME read out full plane state for all planes */
--
2.25.1
[Intel-gfx] [PATCH 1/6] drm/i915/display: Add support for global histogram
API are added to enable/disable histogram. Upon generation of histogram
interrupt its notified to the usespace. User can then use this histogram
and generate a LUT which is then fed back to the enahancement block.
Histogram is an image statistics based on the input pixel stream.
LUT is a look up table consisiting of pixel data.
Signed-off-by: Arun R Murthy
---
drivers/gpu/drm/i915/Makefile | 1 +
.../drm/i915/display/intel_display_types.h| 3 +
.../gpu/drm/i915/display/intel_global_hist.c | 295 ++
.../gpu/drm/i915/display/intel_global_hist.h | 117 +++
4 files changed, 416 insertions(+)
create mode 100644 drivers/gpu/drm/i915/display/intel_global_hist.c
create mode 100644 drivers/gpu/drm/i915/display/intel_global_hist.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 5ab909ec24e5..eac1e0d7bd30 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -295,6 +295,7 @@ i915-y += \
display/intel_dpll.o \
display/intel_dpll_mgr.o \
display/intel_dpt.o \
+ display/intel_global_hist.o \
display/intel_drrs.o \
display/intel_dsb.o \
display/intel_fb.o \
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index ac6951b3e5bd..9848fcf73b87 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1462,6 +1462,9 @@ struct intel_crtc {
/* for loading single buffered registers during vblank */
struct pm_qos_request vblank_pm_qos;
+ /* GLOBAL_HIST data */
+ struct intel_global_hist *global_hist;
+
#ifdef CONFIG_DEBUG_FS
struct intel_pipe_crc pipe_crc;
u32 cpu_fifo_underrun_count;
diff --git a/drivers/gpu/drm/i915/display/intel_global_hist.c
b/drivers/gpu/drm/i915/display/intel_global_hist.c
new file mode 100644
index ..ea5bcd195017
--- /dev/null
+++ b/drivers/gpu/drm/i915/display/intel_global_hist.c
@@ -0,0 +1,295 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ */
+
+#include
+#include
+#include "i915_reg.h"
+#include "i915_drv.h"
+#include "intel_display_types.h"
+#include "intel_de.h"
+#include "intel_global_hist.h"
+
+static int intel_global_hist_get_data(struct drm_i915_private *i915,
+ enum pipe pipe)
+{
+ struct intel_crtc *intel_crtc = to_intel_crtc(
+ drm_crtc_from_index(&i915->drm, pipe));
+ struct intel_global_hist *global_hist = intel_crtc->global_hist;
+ u32 dpstbin;
+ int ret = 0, i = 0;
+
+ /*
+* TODO: PSR to be exited while reading the Histogram data
+* Set DPST_CTL Bin Reg function select to TC
+* Set DPST_CTL Bin Register Index to 0
+*/
+ intel_de_rmw(i915, DPST_CTL(pipe),
+DPST_CTL_BIN_REG_FUNC_SEL | DPST_CTL_BIN_REG_MASK, 0);
+
+ for (i = 0; i < GLOBAL_HIST_BIN_COUNT; i++) {
+ dpstbin = intel_de_read(i915, DPST_BIN(pipe));
+ if (dpstbin & DPST_BIN_BUSY) {
+ /*
+* If DPST_BIN busy bit is set, then set the
+* DPST_CTL bin reg index to 0 and proceed
+* from begining
+*/
+ intel_de_rmw(i915, DPST_CTL(pipe),
+DPST_CTL_BIN_REG_MASK, 0);
+ i = 0;
+ }
+ global_hist->bindata[i] = dpstbin & DPST_BIN_DATA_MASK;
+ drm_dbg_atomic(&i915->drm, "Hist[%d]=%x\n",
+ i, global_hist->bindata[i]);
+ }
+
+ /* Clear histogram interrupt by setting histogram interrupt status bit*/
+ intel_de_rmw
[Intel-gfx] [PATCH 2/6] drm/i915/display: global histogram irq handler
With the enablement of global histogram, upon generation of histogram, an interrupt is triggered. This patch handles the irq. Reviewed-by: Uma Shankar Signed-off-by: Arun R Murthy --- drivers/gpu/drm/i915/i915_irq.c | 6 +- drivers/gpu/drm/i915/i915_reg.h | 5 +++-- 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index e28bfb5f7347..d72fb6d9282d 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -43,6 +43,7 @@ #include "display/intel_hotplug.h" #include "display/intel_lpe_audio.h" #include "display/intel_psr.h" +#include "display/intel_global_hist.h" #include "gt/intel_breadcrumbs.h" #include "gt/intel_gt.h" @@ -2765,6 +2766,9 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv, u32 master_ctl) ret = IRQ_HANDLED; intel_uncore_write(&dev_priv->uncore, GEN8_DE_PIPE_IIR(pipe), iir); + if (iir & GEN9_PIPE_GLOBAL_HIST_EVENT) + intel_global_hist_irq_handler(dev_priv, pipe); + if (iir & GEN8_PIPE_VBLANK) intel_handle_vblank(dev_priv, pipe); @@ -5043,7 +5047,7 @@ static void gen8_de_irq_postinstall(struct drm_i915_private *dev_priv) struct intel_uncore *uncore = &dev_priv->uncore; u32 de_pipe_masked = gen8_de_pipe_fault_mask(dev_priv) | - GEN8_PIPE_CDCLK_CRC_DONE; + GEN8_PIPE_CDCLK_CRC_DONE | GEN9_PIPE_GLOBAL_HIST_EVENT; u32 de_pipe_enables; u32 de_port_masked = gen8_de_port_aux_mask(dev_priv); u32 de_port_enables; diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 94d0c8d14d43..546207ac4859 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3887,7 +3887,7 @@ #define PIPE_HOTPLUG_INTERRUPT_ENABLE(1UL << 26) #define PIPE_VSYNC_INTERRUPT_ENABLE (1UL << 25) #define PIPE_DISPLAY_LINE_COMPARE_ENABLE (1UL << 24) -#define PIPE_DPST_EVENT_ENABLE (1UL << 23) +#define PIPE_GLOBAL_HIST_EVENT_ENABLE(1UL << 23) #define SPRITE0_FLIP_DONE_INT_EN_VLV (1UL << 22) #define PIPE_LEGACY_BLC_EVENT_ENABLE (1UL << 22) #define PIPE_ODD_FIELD_INTERRUPT_ENABLE (1UL << 21) @@ -3910,7 +3910,7 @@ #define PIPE_HOTPLUG_INTERRUPT_STATUS(1UL << 10) #define PIPE_VSYNC_INTERRUPT_STATUS (1UL << 9) #define PIPE_DISPLAY_LINE_COMPARE_STATUS (1UL << 8) -#define PIPE_DPST_EVENT_STATUS (1UL << 7) +#define PIPE_GLOBAL_HIST_EVENT_STATUS(1UL << 7) #define PIPE_A_PSR_STATUS_VLV(1UL << 6) #define PIPE_LEGACY_BLC_EVENT_STATUS (1UL << 6) #define PIPE_ODD_FIELD_INTERRUPT_STATUS (1UL << 5) @@ -5815,6 +5815,7 @@ #define GEN8_PIPE_VSYNC (1 << 1) #define GEN8_PIPE_VBLANK (1 << 0) #define GEN9_PIPE_CURSOR_FAULT(1 << 11) +#define GEN9_PIPE_GLOBAL_HIST_EVENT (1 << 12) #define GEN11_PIPE_PLANE7_FAULT (1 << 22) #define GEN11_PIPE_PLANE6_FAULT (1 << 21) #define GEN11_PIPE_PLANE5_FAULT (1 << 20) -- 2.25.1
Re: [Intel-gfx] [PATCH v3 03/28] drm/i915/gvt: Verify hugepages are contiguous in physical address space
On Wed, May 17, 2023 at 07:50:26AM -0700, Sean Christopherson wrote: > On Tue, May 16, 2023, Yan Zhao wrote: > > hi Sean > > > > Do you think it's necessary to double check that struct page pointers > > are also contiguous? > > No, the virtual address space should be irrelevant. The only way it would be > problematic is if something in dma_map_page() expected to be able to access > the > entire chunk of memory by getting the virtual address of only the first page, > but I can't imagine that code is reading or writing memory, let alone doing so > across a huge range of memory. Yes, I do find arm_iommu version of dma_map_page() access the memory by getting virtual address of pages passed in, but it's implemented as page by page, not only from the first page. dma_map_page dma_map_page_attrs ops->map_page arm_iommu_map_page __dma_page_cpu_to_dev dma_cache_maint_page Just a little worried about the condition of PFNs are contiguous while they belong to different backends, e.g. one from system memory and one from MMIO. But I don't know how to avoid this without complicated checks. And this condition might not happen in practice. > > > And do you like to also include a fix as below, which is to remove the > > warning in vfio_device_container_unpin_pages() when npage is 0? > > > > @ -169,7 +173,8 @@ static int gvt_pin_guest_page(struct intel_vgpu *vgpu, > > unsigned long gfn, > > *page = base_page; > > return 0; > > err: > > - gvt_unpin_guest_page(vgpu, gfn, npage * PAGE_SIZE); > > + if (npage) > > + gvt_unpin_guest_page(vgpu, gfn, npage * PAGE_SIZE); > > return ret; > > } > > Sure. Want to give your SoB? I'll write a changelog. > Thanks! It's just a small code piece. Whatever is convenient for you :)
Re: [Intel-gfx] [PATCH v5 1/7] drm/i915/pmu: Change bitmask of enabled events to u32
On 17/05/2023 17:25, Dixit, Ashutosh wrote:
On Wed, 17 May 2023 01:26:15 -0700, Tvrtko Ursulin wrote:
On 17/05/2023 07:55, Umesh Nerlige Ramappa wrote:
On Tue, May 16, 2023 at 05:25:50PM -0700, Dixit, Ashutosh wrote:
On Tue, 16 May 2023 16:35:28 -0700, Umesh Nerlige Ramappa wrote:
Hi Umesh/Tvrtko,
Mostly repeating comments/questions made on the previous patch below.
First of all thanks for improving this, my v1 obviously wasn't good enough.
From: Tvrtko Ursulin
Having it as u64 was a confusing (but harmless) mistake.
Also add some asserts to make sure the internal field does not overflow
in the future.
v2: Fix WARN_ON firing for INTERRUPT event (Umesh)
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Umesh Nerlige Ramappa
Cc: Ashutosh Dixit
---
drivers/gpu/drm/i915/i915_pmu.c | 26 ++
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c
b/drivers/gpu/drm/i915/i915_pmu.c
index 7ece883a7d95..96543dce2db1 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -50,7 +50,7 @@ static u8 engine_event_instance(struct perf_event
*event)
return (event->attr.config >> I915_PMU_SAMPLE_BITS) & 0xff;
}
-static bool is_engine_config(u64 config)
+static bool is_engine_config(const u64 config)
{
return config < __I915_PMU_OTHER(0);
}
@@ -88,9 +88,20 @@ static unsigned int config_bit(const u64 config)
return other_bit(config);
}
-static u64 config_mask(u64 config)
+static u32 config_mask(const u64 config)
{
- return BIT_ULL(config_bit(config));
+ unsigned int bit = config_bit(config);
Give that config_bit() can return -1 (I understand it is avoided in
moving
the code to config_mask from config_bit), maybe the code below should
also
have that check?
config_mask is only called to check frequency related events in the code,
so I don't see it returing -1 here.
Yeah that should be fine since -1 would make the below asserts fire
anyway. (If it would get called from a different path in the future.)
int bit = config_bit(config);
if (bit != -1)
{
...
}
Though as mentioned below the 'if (__builtin_constant_p())' would have to
go. Maybe the code could even have stayed in config_bit with the check.
+
+ if (__builtin_constant_p(config))
+ BUILD_BUG_ON(bit >
+ BITS_PER_TYPE(typeof_member(struct i915_pmu,
+ enable)) - 1);
Given that config comes from the event (it is event->attr.config), can
this
ever be a builtin constant?
Not sure about earlier code where these checks were inside config_bit(),
but with changes I made, I don't see this being a builtin
constant. However, nothing prevents a caller from just passing a
builtin_constant to this in future.
Are you sure? I would have thought it would always be a compile time
constant now that the check is in config_mask. Aahhh.. with the multi-tile
changes maybe it can't unroll the loops and calculate the masks at compile
time. Maybe it is a bit too much and we should drop the
__builtin_constant_p branch? Probably..
Ah yes, with the code move to config_mask, they really all are compile time
constants (provided compiler can unroll the loops) so at least that is the
justfication for leaving the __builtin_constant_p in. So I'd probably just
leave it as is (though it is a bit too much).
But I guess it is safe to use GEM_WARN_ON_ONCE instead of WARN_ON_ONCE
since there are no external callers (nothing coming from event) now. That
way at least production builds don't have to have the check.
Hmm, there's a GEM_WARN_ON but no GEM_WARN_ON_ONCE. So leave that as is too
I guess.
So I'm ok with the code staying as is. Enough bike-shed on this already.
Latest series looks fine to me and thanks for your patience. Hope you
would agree changing that one thing to u32 made more sense than changing
the other to u64 so bike shed wasn't for nothing.
Regards,
Tvrtko
Re: [Intel-gfx] [PATCH 3/5] drm/i915/display: Move display runtime info to display structure
On 18.05.2023 05:18, Matt Roper wrote:
Move the runtime info specific to display into display-specific
structures as has already been done with the constant display info.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_crtc.c | 2 +-
drivers/gpu/drm/i915/display/intel_cursor.c | 2 +-
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
drivers/gpu/drm/i915/display/intel_display.h | 8 +-
.../drm/i915/display/intel_display_device.h | 23 ++
drivers/gpu/drm/i915/display/intel_fbc.c | 6 +-
drivers/gpu/drm/i915/display/intel_hdcp.c | 2 +-
.../drm/i915/display/skl_universal_plane.c| 2 +-
drivers/gpu/drm/i915/i915_drv.h | 17 +-
drivers/gpu/drm/i915/i915_pci.c | 221 +++---
drivers/gpu/drm/i915/intel_device_info.c | 101
drivers/gpu/drm/i915/intel_device_info.h | 18 --
drivers/gpu/drm/i915/intel_step.c | 8 +-
13 files changed, 245 insertions(+), 167 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
b/drivers/gpu/drm/i915/display/intel_crtc.c
index 93c3226b98c9..182c6dd64f47 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc.c
@@ -306,7 +306,7 @@ int intel_crtc_init(struct drm_i915_private *dev_priv, enum
pipe pipe)
return PTR_ERR(crtc);
crtc->pipe = pipe;
- crtc->num_scalers = RUNTIME_INFO(dev_priv)->num_scalers[pipe];
+ crtc->num_scalers = DISPLAY_RUNTIME_INFO(dev_priv)->num_scalers[pipe];
if (DISPLAY_VER(dev_priv) >= 9)
primary = skl_universal_plane_create(dev_priv, pipe,
diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c
b/drivers/gpu/drm/i915/display/intel_cursor.c
index dd2def27add9..093fc881ddc1 100644
--- a/drivers/gpu/drm/i915/display/intel_cursor.c
+++ b/drivers/gpu/drm/i915/display/intel_cursor.c
@@ -814,7 +814,7 @@ intel_cursor_plane_create(struct drm_i915_private *dev_priv,
DRM_MODE_ROTATE_0 |
DRM_MODE_ROTATE_180);
- zpos = RUNTIME_INFO(dev_priv)->num_sprites[pipe] + 1;
+ zpos = DISPLAY_RUNTIME_INFO(dev_priv)->num_sprites[pipe] + 1;
drm_plane_create_zpos_immutable_property(&cursor->base, zpos);
if (DISPLAY_VER(dev_priv) >= 12)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 09320e14d75c..f1130e2c3542 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3366,7 +3366,7 @@ static u8 bigjoiner_pipes(struct drm_i915_private *i915)
else
pipes = 0;
- return pipes & RUNTIME_INFO(i915)->pipe_mask;
+ return pipes & DISPLAY_RUNTIME_INFO(i915)->pipe_mask;
}
static bool transcoder_ddi_func_is_enabled(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index aa3a21ccd7fe..c744c021af23 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -105,7 +105,7 @@ enum i9xx_plane_id {
};
#define plane_name(p) ((p) + 'A')
-#define sprite_name(p, s) ((p) * RUNTIME_INFO(dev_priv)->num_sprites[(p)] +
(s) + 'A')
+#define sprite_name(p, s) ((p) *
DISPLAY_RUNTIME_INFO(dev_priv)->num_sprites[(p)] + (s) + 'A')
#define for_each_plane_id_on_crtc(__crtc, __p) \
for ((__p) = PLANE_PRIMARY; (__p) < I915_MAX_PLANES; (__p)++) \
@@ -221,7 +221,7 @@ enum phy_fia {
#define for_each_pipe(__dev_priv, __p) \
for ((__p) = 0; (__p) < I915_MAX_PIPES; (__p)++) \
- for_each_if(RUNTIME_INFO(__dev_priv)->pipe_mask & BIT(__p))
+ for_each_if(DISPLAY_RUNTIME_INFO(__dev_priv)->pipe_mask &
BIT(__p))
#define for_each_pipe_masked(__dev_priv, __p, __mask) \
for_each_pipe(__dev_priv, __p) \
@@ -229,7 +229,7 @@ enum phy_fia {
#define for_each_cpu_transcoder(__dev_priv, __t) \
for ((__t) = 0; (__t) < I915_MAX_TRANSCODERS; (__t)++) \
- for_each_if (RUNTIME_INFO(__dev_priv)->cpu_transcoder_mask &
BIT(__t))
+ for_each_if (DISPLAY_RUNTIME_INFO(__dev_priv)->cpu_transcoder_mask
& BIT(__t))
#define for_each_cpu_transcoder_masked(__dev_priv, __t, __mask) \
for_each_cpu_transcoder(__dev_priv, __t) \
@@ -237,7 +237,7 @@ enum phy_fia {
#define for_each_sprite(__dev_priv, __p, __s)\
for ((__s) = 0; \
-(__s) < RUNTIME_INFO(__dev_priv)->num_sprites[(__p)];\
+(__s) < DISPLAY_RUNTIME_INFO(__dev_priv)->num_sprites[(__p)];
\
(__s)++)
#define for_each_port(__port) \
diff --git a/drivers/gpu/drm/i915/display/intel_display_device.h
b/drivers/gpu/drm/i915/display/intel_display_device.h
index c689d582db
Re: [Intel-gfx] [PATCH 5/5] drm/i915/display: Handle GMD_ID identification in display code
Hi Matt,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-tip/drm-tip]
url:
https://github.com/intel-lab-lkp/linux/commits/Matt-Roper/drm-i915-display-Move-display-device-info-to-header-under-display/20230518-112007
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
patch link:
https://lore.kernel.org/r/20230518031804.3133486-6-matthew.d.roper%40intel.com
patch subject: [Intel-gfx] [PATCH 5/5] drm/i915/display: Handle GMD_ID
identification in display code
config: i386-randconfig-a004
compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project
f28c006a5895fc0e329fe15fead81e37457cb1d1)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/intel-lab-lkp/linux/commit/fc14367208dfb37157d27e941b61827dc058c60b
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Matt-Roper/drm-i915-display-Move-display-device-info-to-header-under-display/20230518-112007
git checkout fc14367208dfb37157d27e941b61827dc058c60b
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=i386 olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=i386 SHELL=/bin/bash drivers/gpu/drm/i915/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202305181522.rsq94cmp-...@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/i915/i915_driver.c:758:6: warning: variable 'i915' is used
>> uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
if (ret)
^~~
drivers/gpu/drm/i915/i915_driver.c:849:19: note: uninitialized use occurs
here
i915_probe_error(i915, "Device initialization failed (%d)\n", ret);
^~~~
drivers/gpu/drm/i915/i915_utils.h:73:16: note: expanded from macro
'i915_probe_error'
__i915_printk(i915, i915_error_injected() ? KERN_DEBUG : KERN_ERR, \
^~~~
drivers/gpu/drm/i915/i915_driver.c:758:2: note: remove the 'if' if its
condition is always false
if (ret)
^~~~
drivers/gpu/drm/i915/i915_driver.c:754:31: note: initialize the variable
'i915' to silence this warning
struct drm_i915_private *i915;
^
= NULL
1 warning generated.
vim +758 drivers/gpu/drm/i915/i915_driver.c
55ac5a1614f998 drivers/gpu/drm/i915/i915_drv.cChris Wilson
2018-09-05 740
0673ad472b9849 drivers/gpu/drm/i915/i915_drv.cChris Wilson
2016-06-24 741 /**
b01558e56f8486 drivers/gpu/drm/i915/i915_drv.cJanusz Krzysztofik
2019-07-12 742 * i915_driver_probe - setup chip and create an initial config
d2ad3ae4ecf582 drivers/gpu/drm/i915/i915_drv.cJoonas Lahtinen
2016-11-10 743 * @pdev: PCI device
d2ad3ae4ecf582 drivers/gpu/drm/i915/i915_drv.cJoonas Lahtinen
2016-11-10 744 * @ent: matching PCI ID entry
0673ad472b9849 drivers/gpu/drm/i915/i915_drv.cChris Wilson
2016-06-24 745 *
b01558e56f8486 drivers/gpu/drm/i915/i915_drv.cJanusz Krzysztofik
2019-07-12 746 * The driver probe routine has to do several things:
86a1758d751de0 drivers/gpu/drm/i915/i915_driver.c Jani Nikula
2023-04-14 747 * - drive output discovery via intel_display_driver_probe()
0673ad472b9849 drivers/gpu/drm/i915/i915_drv.cChris Wilson
2016-06-24 748 * - initialize the memory manager
0673ad472b9849 drivers/gpu/drm/i915/i915_drv.cChris Wilson
2016-06-24 749 * - allocate initial config memory
0673ad472b9849 drivers/gpu/drm/i915/i915_drv.cChris Wilson
2016-06-24 750 * - setup the DRM framebuffer with the allocated memory
0673ad472b9849 drivers/gpu/drm/i915/i915_drv.cChris Wilson
2016-06-24 751 */
b01558e56f8486 drivers/gpu/drm/i915/i915_drv.cJanusz Krzysztofik
2019-07-12 752 int i915_driver_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
0673ad472b9849 drivers/gpu/drm/i915/i915_drv.cChris Wilson
2016-06-24 753 {
8eecfb3985e8c8 drivers/gpu/drm/i915/i915_drv.cJani Nikula
2020-02-11 754struct drm_i915_private *i915;
0673ad472b9849 drivers/gpu/drm/i915/i915_drv.cChris Wilson
2016-06-24 755int ret;
0673ad472b9849 drivers/gpu/drm/i915/i915_drv.cChris Wilson
2016-06-24 756
0673ad472b9849 drivers/gpu/drm/i915/i915_drv.cChris
[Intel-gfx] ✓ Fi.CI.BAT: success for HDCP Cleanup
== Series Details ==
Series: HDCP Cleanup
URL : https://patchwork.freedesktop.org/series/117938/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13162 -> Patchwork_117938v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117938v1/index.html
Participating hosts (38 -> 36)
--
Missing(2): fi-kbl-soraka fi-snb-2520m
Known issues
Here are the changes found in Patchwork_117938v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][1] -> [DMESG-WARN][2] ([i915#8423])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13162/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117938v1/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
- bat-adls-5: [PASS][3] -> [DMESG-WARN][4] ([i915#5591])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13162/bat-adls-5/igt@i915_selftest@l...@hangcheck.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117938v1/bat-adls-5/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@reset:
- bat-rpls-2: [PASS][5] -> [ABORT][6] ([i915#4983] / [i915#7461] /
[i915#7913] / [i915#8347])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13162/bat-rpls-2/igt@i915_selftest@l...@reset.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117938v1/bat-rpls-2/igt@i915_selftest@l...@reset.html
* igt@i915_selftest@live@slpc:
- bat-rpls-1: NOTRUN -> [DMESG-WARN][7] ([i915#6367])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117938v1/bat-rpls-1/igt@i915_selftest@l...@slpc.html
* igt@i915_suspend@basic-s3-without-i915:
- bat-rpls-1: NOTRUN -> [ABORT][8] ([i915#6687] / [i915#7978])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117938v1/bat-rpls-1/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-dg2-11: NOTRUN -> [SKIP][9] ([i915#7828])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117938v1/bat-dg2-11/igt@kms_chamelium_...@common-hpd-after-suspend.html
* igt@kms_pipe_crc_basic@nonblocking-crc@pipe-d-dp-1:
- bat-dg2-8: [PASS][10] -> [FAIL][11] ([i915#7932])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13162/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117938v1/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html
Possible fixes
* igt@i915_selftest@live@gt_lrc:
- bat-dg2-11: [INCOMPLETE][12] ([i915#7609] / [i915#7913]) ->
[PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13162/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117938v1/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html
* igt@i915_selftest@live@requests:
- {bat-mtlp-8}: [DMESG-FAIL][14] ([i915#7269]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13162/bat-mtlp-8/igt@i915_selftest@l...@requests.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117938v1/bat-mtlp-8/igt@i915_selftest@l...@requests.html
* igt@i915_selftest@live@reset:
- bat-rpls-1: [ABORT][16] ([i915#4983] / [i915#7461] / [i915#8347]
/ [i915#8384]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13162/bat-rpls-1/igt@i915_selftest@l...@reset.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117938v1/bat-rpls-1/igt@i915_selftest@l...@reset.html
* igt@i915_selftest@live@slpc:
- {bat-mtlp-6}: [DMESG-WARN][18] ([i915#6367]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13162/bat-mtlp-6/igt@i915_selftest@l...@slpc.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117938v1/bat-mtlp-6/igt@i915_selftest@l...@slpc.html
Warnings
* igt@kms_setmode@basic-clone-single-crtc:
- bat-rplp-1: [SKIP][20] ([i915#3555] / [i915#4579]) -> [ABORT][21]
([i915#4579] / [i915#8260])
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13162/bat-rplp-1/igt@kms_setm...@basic-clone-single-crtc.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117938v1/bat-rplp-1/igt@kms_setm...@basic-clone-single-crtc.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#4579]: https://gitlab.freedesktop.org/drm/intel/issues/4579
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5591]: https://gitlab.freedesktop.org/drm/intel/issu
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for HDCP Cleanup
== Series Details == Series: HDCP Cleanup URL : https://patchwork.freedesktop.org/series/117938/ State : warning == Summary == Error: dim checkpatch failed ca74af1c86b5 drm/i915/hdcp: Rename dev_priv to i915 af1ce8f61009 drm/i915/hdcp: Move away from master naming to arbiter -:229: CHECK:ALLOC_SIZEOF_STRUCT: Prefer kzalloc(sizeof(*data)...) over kzalloc(sizeof(struct i915_hdcp_arbiter)...) #229: FILE: drivers/gpu/drm/i915/display/intel_hdcp_gsc.c:703: + data = kzalloc(sizeof(struct i915_hdcp_arbiter), GFP_KERNEL); total: 0 errors, 0 warnings, 1 checks, 297 lines checked cb458f729465 drm/i915/hdcp: Rename comp_mutex to hdcp_mutex
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for HDCP Cleanup
== Series Details == Series: HDCP Cleanup URL : https://patchwork.freedesktop.org/series/117938/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gem: Use large rings for compute contexts (rev2)
== Series Details ==
Series: drm/i915/gem: Use large rings for compute contexts (rev2)
URL : https://patchwork.freedesktop.org/series/117814/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13160_full -> Patchwork_117814v2_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Known issues
Here are the changes found in Patchwork_117814v2_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gen9_exec_parse@allowed-single:
- shard-glk: [PASS][1] -> [ABORT][2] ([i915#5566])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13160/shard-glk5/igt@gen9_exec_pa...@allowed-single.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117814v2/shard-glk8/igt@gen9_exec_pa...@allowed-single.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-apl: [PASS][3] -> [FAIL][4] ([i915#2346])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13160/shard-apl6/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117814v2/shard-apl6/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
Possible fixes
* igt@gem_barrier_race@remote-request@rcs0:
- {shard-dg1}:[ABORT][5] ([i915#7461] / [i915#8234]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13160/shard-dg1-17/igt@gem_barrier_race@remote-requ...@rcs0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117814v2/shard-dg1-15/igt@gem_barrier_race@remote-requ...@rcs0.html
* igt@i915_module_load@reload-with-fault-injection:
- {shard-dg1}:[DMESG-WARN][7] ([i915#4391]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13160/shard-dg1-17/igt@i915_module_l...@reload-with-fault-injection.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117814v2/shard-dg1-15/igt@i915_module_l...@reload-with-fault-injection.html
* igt@i915_pm_rc6_residency@rc6-idle@vcs0:
- {shard-dg1}:[FAIL][9] ([i915#3591]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13160/shard-dg1-14/igt@i915_pm_rc6_residency@rc6-i...@vcs0.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117814v2/shard-dg1-17/igt@i915_pm_rc6_residency@rc6-i...@vcs0.html
* igt@i915_pm_rps@reset:
- {shard-tglu}: [INCOMPLETE][11] ([i915#8320]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13160/shard-tglu-5/igt@i915_pm_...@reset.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117814v2/shard-tglu-3/igt@i915_pm_...@reset.html
* igt@i915_suspend@basic-s3-without-i915:
- {shard-rkl}:[FAIL][13] ([fdo#103375]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13160/shard-rkl-6/igt@i915_susp...@basic-s3-without-i915.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117814v2/shard-rkl-1/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-glk: [FAIL][15] ([i915#2346]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13160/shard-glk4/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117814v2/shard-glk7/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
* igt@kms_cursor_legacy@forked-bo@pipe-b:
- {shard-rkl}:[INCOMPLETE][17] ([i915#8011]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13160/shard-rkl-7/igt@kms_cursor_legacy@forked...@pipe-b.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117814v2/shard-rkl-1/igt@kms_cursor_legacy@forked...@pipe-b.html
* igt@kms_flip@2x-plain-flip-fb-recreate-interruptible@bc-hdmi-a1-hdmi-a2:
- shard-glk: [FAIL][19] ([i915#2122]) -> [PASS][20] +1 similar
issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13160/shard-glk8/igt@kms_flip@2x-plain-flip-fb-recreate-interrupti...@bc-hdmi-a1-hdmi-a2.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117814v2/shard-glk8/igt@kms_flip@2x-plain-flip-fb-recreate-interrupti...@bc-hdmi-a1-hdmi-a2.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[fdo#109274]: https://bugs.freedesktop.org/show_bug.cgi?id=109274
[fdo#109280]: https://bugs.freedesktop.org/show_bug.cgi?id=109280
[fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
[fdo#109302]: https://bugs.freedesktop.org/show_bug.cgi?id=109302
[fdo#109309]: https://bugs.freedesktop.org/sho
