Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Media freq factor and per-gt enhancements/fixes (rev4)
Re-reported and few comments below.
-Original Message-
From: Dixit, Ashutosh
Sent: Friday, April 29, 2022 5:45 PM
To: intel-gfx@lists.freedesktop.org; Vudum, Lakshminarayana
Subject: Re: ✗ Fi.CI.IGT: failure for drm/i915: Media freq factor and per-gt
enhancements/fixes (rev4)
On Fri, 29 Apr 2022 16:38:35 -0700, Patchwork wrote:
>
> Possible regressions
>
> * igt@gem_eio@in-flight-suspend:
>
> * shard-skl: PASS -> INCOMPLETE
This failure in unrelated.
>
> * {igt@i915_pm_disag_freq@media-freq@gt0} (NEW):
>
> * shard-iclb: NOTRUN -> SKIP
>
> * shard-tglb: NOTRUN -> SKIP
These failures are expected, the test will skip on platforms which do not
support this feature.
Lakshmi: These tests are not in yet in CI bug log.
>
> * igt@kms_draw_crc@draw-method-xrgb2101010-mmap-gtt-xtiled:
>
> * shard-kbl: PASS -> FAIL
This failure in unrelated.
Lakshmi: Filed https://gitlab.freedesktop.org/drm/intel/-/issues/5870
igt@kms_draw_crc@draw-method-xrgb2101010-mmap-gtt-xtiled - fail - Failed
assertion: rc == 0
> New tests
>
> New tests have been introduced between CI_DRM_11583_full and
> Patchwork_102665v4_full:
>
> New IGT tests (1)
>
> * igt@i915_pm_disag_freq@media-freq@gt0:
>
> * Statuses : 7 skip(s)
> * Exec time: [0.0] s
These skips are the same as above and expected.
Thanks.
--
Ashutosh
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Media freq factor and per-gt enhancements/fixes (rev4)
On Fri, 29 Apr 2022 16:38:35 -0700, Patchwork wrote:
>
> Possible regressions
>
> * igt@gem_eio@in-flight-suspend:
>
> * shard-skl: PASS -> INCOMPLETE
This failure in unrelated.
>
> * {igt@i915_pm_disag_freq@media-freq@gt0} (NEW):
>
> * shard-iclb: NOTRUN -> SKIP
>
> * shard-tglb: NOTRUN -> SKIP
These failures are expected, the test will skip on platforms which do not
support this feature.
>
> * igt@kms_draw_crc@draw-method-xrgb2101010-mmap-gtt-xtiled:
>
> * shard-kbl: PASS -> FAIL
This failure in unrelated.
> New tests
>
> New tests have been introduced between CI_DRM_11583_full and
> Patchwork_102665v4_full:
>
> New IGT tests (1)
>
> * igt@i915_pm_disag_freq@media-freq@gt0:
>
> * Statuses : 7 skip(s)
> * Exec time: [0.0] s
These skips are the same as above and expected.
Thanks.
--
Ashutosh
Re: [Intel-gfx] [PATCH] drm/i915/dmc: Add MMIO range restrictions
> -Original Message-
> From: De Marchi, Lucas
> Sent: Friday, April 29, 2022 1:50 PM
> To: Srivatsa, Anusha
> Cc: intel-gfx@lists.freedesktop.org; sta...@vger.kernel.org
> Subject: Re: [PATCH] drm/i915/dmc: Add MMIO range restrictions
>
> On Fri, Apr 29, 2022 at 01:39:03PM -0700, Anusha Srivatsa wrote:
> >
> >
> >> -Original Message-
> >> From: De Marchi, Lucas
> >> Sent: Tuesday, April 26, 2022 10:42 PM
> >> To: Srivatsa, Anusha
> >> Cc: intel-gfx@lists.freedesktop.org; sta...@vger.kernel.org
> >> Subject: Re: [PATCH] drm/i915/dmc: Add MMIO range restrictions
> >>
> >> On Tue, Apr 26, 2022 at 05:35:09PM -0700, Anusha Srivatsa wrote:
> >> >Bspec has added some steps that check forDMC MMIO range before
> >> >programming them
> >> >
> >> >v2: Fix for CI
> >> >v3: move register defines to .h (Anusha)
> >> >- Check MMIO restrictions per pipe
> >> >- Add MMIO restricton for v1 dmc header as well (Lucas)
> >> >
> >> >BSpec: 49193
> >> >
> >> >Cc:
> >> >Cc: Lucas De Marchi
> >> >Signed-off-by: Anusha Srivatsa
> >> >---
> >> > drivers/gpu/drm/i915/display/intel_dmc.c | 48 ---
> >> > drivers/gpu/drm/i915/display/intel_dmc_regs.h | 31
> >> > 2 files changed, 72 insertions(+), 7 deletions(-)
> >> >
> >> >diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
> >> >b/drivers/gpu/drm/i915/display/intel_dmc.c
> >> >index 257cf662f9f4..ac7896835bfa 100644
> >> >--- a/drivers/gpu/drm/i915/display/intel_dmc.c
> >> >+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> >> >@@ -97,13 +97,6 @@ MODULE_FIRMWARE(SKL_DMC_PATH);
> >> > #define BXT_DMC_MAX_FW_SIZE 0x3000
> >> > MODULE_FIRMWARE(BXT_DMC_PATH);
> >> >
> >> >-#define DMC_DEFAULT_FW_OFFSET0x
> >> >-#define PACKAGE_MAX_FW_INFO_ENTRIES 20
> >> >-#define PACKAGE_V2_MAX_FW_INFO_ENTRIES 32
> >> >-#define DMC_V1_MAX_MMIO_COUNT8
> >> >-#define DMC_V3_MAX_MMIO_COUNT20
> >> >-#define DMC_V1_MMIO_START_RANGE 0x8
> >> >-
> >> > struct intel_css_header {
> >> > /* 0x09 for DMC */
> >> > u32 module_type;
> >> >@@ -374,6 +367,43 @@ static void dmc_set_fw_offset(struct intel_dmc
> >> *dmc,
> >> > }
> >> > }
> >> >
> >> >+static bool dmc_mmio_addr_sanity_check(struct intel_dmc *dmc, const
> >> u32 *mmioaddr,
> >> >+u32 mmio_count, int header_ver, u8
> >> dmc_id) {
> >> >+ struct drm_i915_private *i915 = container_of(dmc, typeof(*i915),
> >> dmc);
> >> >+ int i;
> >> >+
> >> >+ if (header_ver == 1) {
> >> >+ for (i = 0; i < mmio_count; i++) {
> >> >+ if (mmioaddr[i] < DMC_MMIO_START_RANGE ||
> >> mmioaddr[i] > DMC_MMIO_END_RANGE)
> >> >+ return false;
> >> >+ }
> >>
> >> return missing here
> >>
> >> >+ }
> >> >+
> >> >+ /* Main DMC MMIO check */
> >> >+ if (dmc_id == DMC_FW_MAIN) {
> >> >+ for (i = 0; i < mmio_count; i++) {
> >> >+ if (mmioaddr[i] < TGL_DMC_MMIO_START(dmc_id)
> >> || mmioaddr[i] > TGL_DMC_MMIO_END(dmc_id))
> >> >+ return false;
> >> >+ }
> >> >+ }
> >> >+
> >> >+ /* Pipe DMC MMIO check */
> >> >+ if (IS_DG2(i915) || IS_ALDERLAKE_P(i915)) {
> >> >+ for (i = 0; i < mmio_count; i++) {
> >> >+ if (mmioaddr[i] < ADLP_PIPE_MMIO_START &&
> >> mmioaddr[i] > ADLP_PIPE_MMIO_END)
> >> >+ return false;
> >> >+ }
> >>
> >> for DG2, main should use TGL_DMC_MMIO_START? and then fail here
> >> because of another missing return above?
> >>
> >> >+ } else if (IS_TIGERLAKE(i915) || IS_DG1(i915) ||
> >> IS_ALDERLAKE_S(i915)) {
> >> >+ for (i = 0; i < mmio_count; i++) {
> >> >+ if (mmioaddr[i] < TGL_DMC_MMIO_START(dmc_id)
> >> || mmioaddr[i] > TGL_DMC_MMIO_END(dmc_id))
> >> >+ return false;
> >>
> >> this is handling DMC_FW_MAIN twice.
> >>
> >>
> >> Maybe something like this:
> >>
> >>u32 start, end;
> >>
> >>if (header_ver == 1) {
> >>start = DMC_MMIO_START_RANGE;
> >>end = DMC_MMIO_END_RANGE;
> >>} else if (dmc_id == DMC_FW_MAIN || IS_TIGERLAKE(i915) ||
> >> IS_DG1(i915) || IS_ALDERLAKE_S(i915)) {
> >>start = TGL_DMC_MMIO_START(dmc_id);
> >>end = TGL_DMC_MMIO_END(dmc_id);
> >>} else if (IS_DG2(i915) || IS_ALDERLAKE_P(i915)) {
> >>start = ADLP_PIPE_MMIO_START;
> >>end = ADLP_PIPE_MMIO_END;
> >>} else {
> >>drm_warn(>drm, "Unknown mmio range for sanity
> check");
> >>return false;
> >>}
> >>
> >>for (i = 0; i < mmio_count; i++)
> >>if (mmioaddr[i] < start || mmioaddr[i] > end)
> >>return false;
> >>
> >>return true;
> >>
> >>
> >> ... untested, and may need tweaks depending on the answer to the
> >> question above on what range to use for ADL-P/DG2 on main DMC.
> >The above approach is definitely neater.
> >The main DMC offset is the same for all
Re: [Intel-gfx] [PATCH v2 0/7] Make the rest of the VFIO driver interface use vfio_device
On Fri, 29 Apr 2022 14:31:49 -0300 Jason Gunthorpe wrote: > On Thu, Apr 21, 2022 at 01:28:31PM -0300, Jason Gunthorpe wrote: > > Prior series have transformed other parts of VFIO from working on struct > > device or struct vfio_group into working directly on struct > > vfio_device. Based on that work we now have vfio_device's readily > > available in all the drivers. > > > > Update the rest of the driver facing API to use vfio_device as an input. > > > > The following are switched from struct device to struct vfio_device: > > vfio_register_notifier() > > vfio_unregister_notifier() > > vfio_pin_pages() > > vfio_unpin_pages() > > vfio_dma_rw() > > > > The following group APIs are obsoleted and removed by just using struct > > vfio_device with the above: > > vfio_group_pin_pages() > > vfio_group_unpin_pages() > > vfio_group_iommu_domain() > > vfio_group_get_external_user_from_dev() > > > > To retain the performance of the new device APIs relative to their group > > versions optimize how vfio_group_add_container_user() is used to avoid > > calling it when the driver must already guarantee the device is open and > > the container_users incrd. > > > > The remaining exported VFIO group interfaces are only used by kvm, and are > > addressed by a parallel series. > > > > This series is based on Christoph's gvt rework here: > > > > https://lore.kernel.org/all/5a8b9f48-2c32-8177-1c18-e3bd7bfde...@intel.com/ > > > > and so will need the PR merged first. > > Hi Alex, > > Since all the shared branch PRs are ready, do you have any remarks on > this series and the others before I rebase and repost them? Only the nit in the commit log: https://lore.kernel.org/all/20220429142820.6afe7bbe.alex.william...@redhat.com/ > This one has a few changes to the commit messages outstanding, but v2 > didn't have any code changes. > > Also, what order would like the different series in - they conflict > with each other a little bit. I suggest this: > > - mdev group removal (this one) > - Remove vfio_device_get_from_dev() > > https://lore.kernel.org/r/0-v1-7f2292e6b2ba+44839-vfio_get_from_dev_...@nvidia.com > - Remove group from kvm > > https://lore.kernel.org/r/0-v1-33906a626da1+16b0-vfio_kvm_no_group_...@nvidia.com I think you mean (v2): https://lore.kernel.org/all/0-v2-6a528653a750+1578a-vfio_kvm_no_group_...@nvidia.com/ Otherwise, thanks for sorting these out for me. > All of them seem to have got enough reviews now. > > I have one more series on this group topic and a few little patches still > > It would be great if you could merge the gvt and iommu series together > into your tree toward linux-next so I can post patches against a > stable commit ID so the build-bots can test them. Please check my vfio next branch and see if this matches what you're looking for: https://github.com/awilliam/linux-vfio/commits/next I'll look for any fallout from Stephen and build bots on Monday's linux-next compilation. Thanks, Alex
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for i915: Turn on compute engine support (rev4)
On Thu, Apr 28, 2022 at 06:18:41AM +, Patchwork wrote:
> == Series Details ==
>
> Series: i915: Turn on compute engine support (rev4)
> URL : https://patchwork.freedesktop.org/series/103011/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_11550_full -> Patchwork_103011v4_full
>
>
> Summary
> ---
>
> **WARNING**
>
> Minor unknown changes coming with Patchwork_103011v4_full need to be
> verified
> manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_103011v4_full, please notify your bug team to allow
> them
> to document this new failure mode, which will reduce false positives in CI.
>
>
>
> Participating hosts (10 -> 13)
> --
>
> Additional (3): shard-rkl shard-dg1 shard-tglu
>
> Possible new issues
> ---
>
> Here are the unknown changes that may have been introduced in
> Patchwork_103011v4_full:
>
> ### IGT changes ###
>
> Warnings
>
> * igt@gem_eio@kms:
> - shard-tglb: [FAIL][1] ([i915#232]) -> [FAIL][2]
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-tglb3/igt@gem_...@kms.html
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103011v4/shard-tglb1/igt@gem_...@kms.html
https://gitlab.freedesktop.org/drm/intel/-/issues/5784
Series applied to drm-intel-gt-next. Thanks for the reviews.
Matt
>
>
> Suppressed
>
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
>
> * igt@i915_pm_rpm@system-suspend-devices:
> - {shard-dg1}:NOTRUN -> [INCOMPLETE][3]
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103011v4/shard-dg1-19/igt@i915_pm_...@system-suspend-devices.html
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_103011v4_full that come from known
> issues:
>
> ### CI changes ###
>
> Possible fixes
>
> * boot:
> - shard-skl: ([PASS][4], [PASS][5], [PASS][6], [PASS][7],
> [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13],
> [PASS][14], [PASS][15], [FAIL][16], [PASS][17], [PASS][18], [PASS][19],
> [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25],
> [PASS][26], [PASS][27]) ([i915#5032]) -> ([PASS][28], [PASS][29], [PASS][30],
> [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36],
> [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42],
> [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48],
> [PASS][49], [PASS][50], [PASS][51])
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl9/boot.html
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl9/boot.html
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl8/boot.html
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl8/boot.html
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl7/boot.html
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl7/boot.html
>[10]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl6/boot.html
>[11]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl6/boot.html
>[12]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl6/boot.html
>[13]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/boot.html
>[14]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/boot.html
>[15]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/boot.html
>[16]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/boot.html
>[17]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl4/boot.html
>[18]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl4/boot.html
>[19]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl4/boot.html
>[20]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl3/boot.html
>[21]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl3/boot.html
>[22]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl2/boot.html
>[23]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl2/boot.html
>[24]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl1/boot.html
>[25]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl1/boot.html
>[26]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl10/boot.html
>[27]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl10/boot.html
>[28]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103011v4/shard-skl9/boot.html
>[29]:
>
Re: [Intel-gfx] [PATCH v2 0/4] i915: Turn on compute engine support
I did some light testing with our anvil (Vulkan) and iris (OpenGL) Mesa drivers after applying these patches on top of drm-tip tagged intel/CI_DRM_11574. All the unit tests that I tried passed. I also ran the gl_manhattan31 benchmark which used the compute engine for iris compute shader ops. Series: Reviewed-by: Jordan Justen Tested-by: Jordan Justen -Jordan On 2022-04-27 21:19:22, Matt Roper wrote: > Now that the necessary GuC-based hardware workarounds have landed, we're > finally ready to actually enable compute engines for use by userspace. > All of the "under-the-hood" heavy lifting already landed a while back in > other series so all that remains now is to add I915_ENGINE_CLASS_COMPUTE > to the uapi enum and add the CCS engines to the engine lists for the > Xe_HP SDV and DG2. > > Userspace (Mesa) is linked in the ABI patch. Existing IGT tests (e.g., > i915_hangman) provide test coverage for general engine behavior since compute > engines should follow the same general rules as other engines. We've also > recently added some additional subtests like > igt@gem_reset_stats@shared-reset-domain to cover the user-visible impacts of > the compute engines sharing the same hardware reset domain as the render > engine. > > v2: > - Update TLB invalidation register for compute engines and move it to a >separate patch since it isn't related to the new uapi. (Tvrtko, >Prathap) > - Move new kerneldoc for pre-existing engine classes to a separate >patch. (Andi) > - Drop the compute UMD merge request link for now because it also >included some additional multi-tile uapi that we're not ready to >upstream just yet. Even if they don't have a disentangled MR ready >for reference, we still have the Mesa MR as a key userspace consumer. >(Tvrtko) > > Cc: Lucas De Marchi > Cc: Tvrtko Ursulin > > Daniele Ceraolo Spurio (1): > drm/i915: Xe_HP SDV and DG2 have up to 4 CCS engines > > Matt Roper (3): > drm/i915/uapi: Add kerneldoc for engine class enum > drm/i915/xehp: Add register for compute engine's MMIO-based TLB > invalidation > drm/i915/xehp: Add compute engine ABI > > drivers/gpu/drm/i915/gt/intel_engine_user.c | 2 +- > drivers/gpu/drm/i915/gt/intel_gt.c | 1 + > drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 + > drivers/gpu/drm/i915/i915_drm_client.c | 1 + > drivers/gpu/drm/i915/i915_drm_client.h | 2 +- > drivers/gpu/drm/i915/i915_pci.c | 6 +- > include/uapi/drm/i915_drm.h | 62 +++-- > 7 files changed, 65 insertions(+), 10 deletions(-) > > -- > 2.35.1 >
Re: [Intel-gfx] [PATCH 1/3] drm/i915/display: Do not schedule DRRS work thread when it is not active
On Fri, 2022-04-29 at 19:00 +0300, Ville Syrjälä wrote:
> On Thu, Apr 28, 2022 at 02:10:56PM -0700, José Roberto de Souza wrote:
> > Frontbuffer updates were scheduling the execution of DRRS work thread
> > even if DRRS is not active.
> > There was no issues with it because intel_drrs_downclock_work() checks
> > if DRRS is active but there is no reason to keep scheduling this work
> > thread and wasting CPU time.
> >
> > Cc: Ville Syrjälä
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/display/intel_drrs.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c
> > b/drivers/gpu/drm/i915/display/intel_drrs.c
> > index 166caf293f7bc..04bc296761be0 100644
> > --- a/drivers/gpu/drm/i915/display/intel_drrs.c
> > +++ b/drivers/gpu/drm/i915/display/intel_drrs.c
> > @@ -236,6 +236,11 @@ static void intel_drrs_frontbuffer_update(struct
> > drm_i915_private *dev_priv,
> > else
> > crtc->drrs.busy_frontbuffer_bits &= ~frontbuffer_bits;
> >
> > + if (!intel_drrs_is_active(crtc)) {
> > + mutex_unlock(>drrs.mutex);
> > + continue;
> > + }
>
> Should be impossible due to crtc->drrs.frontbuffer_bits==0.
Yep, my bad this patch is not needed.
Can you review the remaining?
I have one more patch to this series that avoids DP link configuration change
during seamless mode change, when possible.
Planning to send new version with this patch any other changes that you request.
thanks
>
> > +
> > /* flush/invalidate means busy screen hence upclock */
> > intel_drrs_set_state(crtc, DRRS_REFRESH_RATE_HIGH);
> >
> > --
> > 2.36.0
>
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Media freq factor and per-gt enhancements/fixes (rev4)
== Series Details ==
Series: drm/i915: Media freq factor and per-gt enhancements/fixes (rev4)
URL : https://patchwork.freedesktop.org/series/102665/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11583 -> Patchwork_102665v4
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v4/index.html
Participating hosts (43 -> 45)
--
Additional (4): bat-rpls-1 fi-rkl-11600 fi-icl-u2 bat-dg1-5
Missing(2): fi-hsw-4770 fi-bsw-cyan
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_102665v4:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@gem_contexts:
- {bat-rpls-1}: NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v4/bat-rpls-1/igt@i915_selftest@live@gem_contexts.html
* igt@i915_selftest@live@mman:
- {bat-jsl-1}:[PASS][2] -> [INCOMPLETE][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11583/bat-jsl-1/igt@i915_selftest@l...@mman.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v4/bat-jsl-1/igt@i915_selftest@l...@mman.html
Known issues
Here are the changes found in Patchwork_102665v4 that come from known issues:
### IGT changes ###
Issues hit
* igt@fbdev@write:
- bat-dg1-5: NOTRUN -> [SKIP][4] ([i915#2582]) +4 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v4/bat-dg1-5/igt@fb...@write.html
* igt@gem_exec_suspend@basic-s0@smem:
- bat-dg1-6: NOTRUN -> [INCOMPLETE][5] ([i915#5827])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v4/bat-dg1-6/igt@gem_exec_suspend@basic...@smem.html
- bat-dg1-5: NOTRUN -> [INCOMPLETE][6] ([i915#5827])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v4/bat-dg1-5/igt@gem_exec_suspend@basic...@smem.html
* igt@gem_exec_suspend@basic-s3@smem:
- fi-bdw-5557u: NOTRUN -> [INCOMPLETE][7] ([i915#146])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v4/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
- fi-rkl-11600: NOTRUN -> [INCOMPLETE][8] ([i915#5127] / [i915#5857])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v4/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html
* igt@gem_huc_copy@huc-copy:
- fi-icl-u2: NOTRUN -> [SKIP][9] ([i915#2190])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v4/fi-icl-u2/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@parallel-random-engines:
- fi-icl-u2: NOTRUN -> [SKIP][10] ([i915#4613]) +3 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v4/fi-icl-u2/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@i915_module_load@reload:
- fi-bsw-kefka: [PASS][11] -> [DMESG-WARN][12] ([i915#1982])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11583/fi-bsw-kefka/igt@i915_module_l...@reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v4/fi-bsw-kefka/igt@i915_module_l...@reload.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-tgl-1115g4: NOTRUN -> [SKIP][13] ([fdo#111827])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v4/fi-tgl-1115g4/igt@kms_chamel...@common-hpd-after-suspend.html
- fi-kbl-soraka: NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v4/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html
- fi-snb-2600:NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v4/fi-snb-2600/igt@kms_chamel...@common-hpd-after-suspend.html
- fi-kbl-guc: NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v4/fi-kbl-guc/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: NOTRUN -> [SKIP][17] ([fdo#111827]) +8 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v4/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2: NOTRUN -> [SKIP][18] ([fdo#109278]) +2 similar issues
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v4/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-icl-u2: NOTRUN -> [SKIP][19] ([fdo#109285])
[19]:
Re: [Intel-gfx] [PATCH] drm/i915/dmc: Add MMIO range restrictions
On Fri, Apr 29, 2022 at 01:39:03PM -0700, Anusha Srivatsa wrote:
-Original Message-
From: De Marchi, Lucas
Sent: Tuesday, April 26, 2022 10:42 PM
To: Srivatsa, Anusha
Cc: intel-gfx@lists.freedesktop.org; sta...@vger.kernel.org
Subject: Re: [PATCH] drm/i915/dmc: Add MMIO range restrictions
On Tue, Apr 26, 2022 at 05:35:09PM -0700, Anusha Srivatsa wrote:
>Bspec has added some steps that check forDMC MMIO range before
>programming them
>
>v2: Fix for CI
>v3: move register defines to .h (Anusha)
>- Check MMIO restrictions per pipe
>- Add MMIO restricton for v1 dmc header as well (Lucas)
>
>BSpec: 49193
>
>Cc:
>Cc: Lucas De Marchi
>Signed-off-by: Anusha Srivatsa
>---
> drivers/gpu/drm/i915/display/intel_dmc.c | 48 ---
> drivers/gpu/drm/i915/display/intel_dmc_regs.h | 31
> 2 files changed, 72 insertions(+), 7 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
>b/drivers/gpu/drm/i915/display/intel_dmc.c
>index 257cf662f9f4..ac7896835bfa 100644
>--- a/drivers/gpu/drm/i915/display/intel_dmc.c
>+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
>@@ -97,13 +97,6 @@ MODULE_FIRMWARE(SKL_DMC_PATH);
> #define BXT_DMC_MAX_FW_SIZE0x3000
> MODULE_FIRMWARE(BXT_DMC_PATH);
>
>-#define DMC_DEFAULT_FW_OFFSET 0x
>-#define PACKAGE_MAX_FW_INFO_ENTRIES20
>-#define PACKAGE_V2_MAX_FW_INFO_ENTRIES 32
>-#define DMC_V1_MAX_MMIO_COUNT 8
>-#define DMC_V3_MAX_MMIO_COUNT 20
>-#define DMC_V1_MMIO_START_RANGE0x8
>-
> struct intel_css_header {
>/* 0x09 for DMC */
>u32 module_type;
>@@ -374,6 +367,43 @@ static void dmc_set_fw_offset(struct intel_dmc
*dmc,
>}
> }
>
>+static bool dmc_mmio_addr_sanity_check(struct intel_dmc *dmc, const
u32 *mmioaddr,
>+ u32 mmio_count, int header_ver, u8
dmc_id) {
>+ struct drm_i915_private *i915 = container_of(dmc, typeof(*i915),
dmc);
>+ int i;
>+
>+ if (header_ver == 1) {
>+ for (i = 0; i < mmio_count; i++) {
>+ if (mmioaddr[i] < DMC_MMIO_START_RANGE ||
mmioaddr[i] > DMC_MMIO_END_RANGE)
>+ return false;
>+ }
return missing here
>+ }
>+
>+ /* Main DMC MMIO check */
>+ if (dmc_id == DMC_FW_MAIN) {
>+ for (i = 0; i < mmio_count; i++) {
>+ if (mmioaddr[i] < TGL_DMC_MMIO_START(dmc_id)
|| mmioaddr[i] > TGL_DMC_MMIO_END(dmc_id))
>+ return false;
>+ }
>+ }
>+
>+ /* Pipe DMC MMIO check */
>+ if (IS_DG2(i915) || IS_ALDERLAKE_P(i915)) {
>+ for (i = 0; i < mmio_count; i++) {
>+ if (mmioaddr[i] < ADLP_PIPE_MMIO_START &&
mmioaddr[i] > ADLP_PIPE_MMIO_END)
>+ return false;
>+ }
for DG2, main should use TGL_DMC_MMIO_START? and then fail here
because of another missing return above?
>+ } else if (IS_TIGERLAKE(i915) || IS_DG1(i915) ||
IS_ALDERLAKE_S(i915)) {
>+ for (i = 0; i < mmio_count; i++) {
>+ if (mmioaddr[i] < TGL_DMC_MMIO_START(dmc_id)
|| mmioaddr[i] > TGL_DMC_MMIO_END(dmc_id))
>+ return false;
this is handling DMC_FW_MAIN twice.
Maybe something like this:
u32 start, end;
if (header_ver == 1) {
start = DMC_MMIO_START_RANGE;
end = DMC_MMIO_END_RANGE;
} else if (dmc_id == DMC_FW_MAIN || IS_TIGERLAKE(i915) ||
IS_DG1(i915) || IS_ALDERLAKE_S(i915)) {
start = TGL_DMC_MMIO_START(dmc_id);
end = TGL_DMC_MMIO_END(dmc_id);
} else if (IS_DG2(i915) || IS_ALDERLAKE_P(i915)) {
start = ADLP_PIPE_MMIO_START;
end = ADLP_PIPE_MMIO_END;
} else {
drm_warn(>drm, "Unknown mmio range for sanity
check");
return false;
}
for (i = 0; i < mmio_count; i++)
if (mmioaddr[i] < start || mmioaddr[i] > end)
return false;
return true;
... untested, and may need tweaks depending on the answer to the question
above on what range to use for ADL-P/DG2 on main DMC.
The above approach is definitely neater.
The main DMC offset is the same for all platforms.
>+ }
>+ }
>+
>+ return true;
>+}
>+
> static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
> const struct intel_dmc_header_base
*dmc_header,
> size_t rem_size, u8 dmc_id)
>@@ -443,6 +473,10 @@ static u32 parse_dmc_fw_header(struct intel_dmc
*dmc,
>return 0;
>}
>
>+ if (!dmc_mmio_addr_sanity_check(dmc, mmioaddr, mmio_count,
dmc_header->header_ver, dmc_id))
>+ drm_err(>drm, "DMC firmware has Wrong MMIO
Addresses\n");
>+ return 0;
you don't like DMC and decided to fail it for all platforms?
>+
>for (i = 0; i < mmio_count; i++) {
>dmc_info->mmioaddr[i] = _MMIO(mmioaddr[i]);
>
Re: [Intel-gfx] [PATCH] drm/i915/dmc: Add MMIO range restrictions
> -Original Message-
> From: De Marchi, Lucas
> Sent: Tuesday, April 26, 2022 10:42 PM
> To: Srivatsa, Anusha
> Cc: intel-gfx@lists.freedesktop.org; sta...@vger.kernel.org
> Subject: Re: [PATCH] drm/i915/dmc: Add MMIO range restrictions
>
> On Tue, Apr 26, 2022 at 05:35:09PM -0700, Anusha Srivatsa wrote:
> >Bspec has added some steps that check forDMC MMIO range before
> >programming them
> >
> >v2: Fix for CI
> >v3: move register defines to .h (Anusha)
> >- Check MMIO restrictions per pipe
> >- Add MMIO restricton for v1 dmc header as well (Lucas)
> >
> >BSpec: 49193
> >
> >Cc:
> >Cc: Lucas De Marchi
> >Signed-off-by: Anusha Srivatsa
> >---
> > drivers/gpu/drm/i915/display/intel_dmc.c | 48 ---
> > drivers/gpu/drm/i915/display/intel_dmc_regs.h | 31
> > 2 files changed, 72 insertions(+), 7 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
> >b/drivers/gpu/drm/i915/display/intel_dmc.c
> >index 257cf662f9f4..ac7896835bfa 100644
> >--- a/drivers/gpu/drm/i915/display/intel_dmc.c
> >+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> >@@ -97,13 +97,6 @@ MODULE_FIRMWARE(SKL_DMC_PATH);
> > #define BXT_DMC_MAX_FW_SIZE 0x3000
> > MODULE_FIRMWARE(BXT_DMC_PATH);
> >
> >-#define DMC_DEFAULT_FW_OFFSET 0x
> >-#define PACKAGE_MAX_FW_INFO_ENTRIES 20
> >-#define PACKAGE_V2_MAX_FW_INFO_ENTRIES 32
> >-#define DMC_V1_MAX_MMIO_COUNT 8
> >-#define DMC_V3_MAX_MMIO_COUNT 20
> >-#define DMC_V1_MMIO_START_RANGE 0x8
> >-
> > struct intel_css_header {
> > /* 0x09 for DMC */
> > u32 module_type;
> >@@ -374,6 +367,43 @@ static void dmc_set_fw_offset(struct intel_dmc
> *dmc,
> > }
> > }
> >
> >+static bool dmc_mmio_addr_sanity_check(struct intel_dmc *dmc, const
> u32 *mmioaddr,
> >+ u32 mmio_count, int header_ver, u8
> dmc_id) {
> >+struct drm_i915_private *i915 = container_of(dmc, typeof(*i915),
> dmc);
> >+int i;
> >+
> >+if (header_ver == 1) {
> >+for (i = 0; i < mmio_count; i++) {
> >+if (mmioaddr[i] < DMC_MMIO_START_RANGE ||
> mmioaddr[i] > DMC_MMIO_END_RANGE)
> >+return false;
> >+}
>
> return missing here
>
> >+}
> >+
> >+/* Main DMC MMIO check */
> >+if (dmc_id == DMC_FW_MAIN) {
> >+for (i = 0; i < mmio_count; i++) {
> >+if (mmioaddr[i] < TGL_DMC_MMIO_START(dmc_id)
> || mmioaddr[i] > TGL_DMC_MMIO_END(dmc_id))
> >+return false;
> >+}
> >+}
> >+
> >+/* Pipe DMC MMIO check */
> >+if (IS_DG2(i915) || IS_ALDERLAKE_P(i915)) {
> >+for (i = 0; i < mmio_count; i++) {
> >+if (mmioaddr[i] < ADLP_PIPE_MMIO_START &&
> mmioaddr[i] > ADLP_PIPE_MMIO_END)
> >+return false;
> >+}
>
> for DG2, main should use TGL_DMC_MMIO_START? and then fail here
> because of another missing return above?
>
> >+} else if (IS_TIGERLAKE(i915) || IS_DG1(i915) ||
> IS_ALDERLAKE_S(i915)) {
> >+for (i = 0; i < mmio_count; i++) {
> >+if (mmioaddr[i] < TGL_DMC_MMIO_START(dmc_id)
> || mmioaddr[i] > TGL_DMC_MMIO_END(dmc_id))
> >+return false;
>
> this is handling DMC_FW_MAIN twice.
>
>
> Maybe something like this:
>
> u32 start, end;
>
> if (header_ver == 1) {
> start = DMC_MMIO_START_RANGE;
> end = DMC_MMIO_END_RANGE;
> } else if (dmc_id == DMC_FW_MAIN || IS_TIGERLAKE(i915) ||
> IS_DG1(i915) || IS_ALDERLAKE_S(i915)) {
> start = TGL_DMC_MMIO_START(dmc_id);
> end = TGL_DMC_MMIO_END(dmc_id);
> } else if (IS_DG2(i915) || IS_ALDERLAKE_P(i915)) {
> start = ADLP_PIPE_MMIO_START;
> end = ADLP_PIPE_MMIO_END;
> } else {
> drm_warn(>drm, "Unknown mmio range for sanity
> check");
> return false;
> }
>
> for (i = 0; i < mmio_count; i++)
> if (mmioaddr[i] < start || mmioaddr[i] > end)
> return false;
>
> return true;
>
>
> ... untested, and may need tweaks depending on the answer to the question
> above on what range to use for ADL-P/DG2 on main DMC.
The above approach is definitely neater.
The main DMC offset is the same for all platforms.
> >+}
> >+}
> >+
> >+return true;
> >+}
> >+
> > static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
> >const struct intel_dmc_header_base
> *dmc_header,
> >size_t rem_size, u8 dmc_id)
> >@@ -443,6 +473,10 @@ static u32 parse_dmc_fw_header(struct intel_dmc
> *dmc,
> > return 0;
> > }
> >
> >+if (!dmc_mmio_addr_sanity_check(dmc, mmioaddr, mmio_count,
> dmc_header->header_ver, dmc_id))
> >+drm_err(>drm, "DMC firmware has Wrong MMIO
>
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Media freq factor and per-gt enhancements/fixes (rev4)
== Series Details == Series: drm/i915: Media freq factor and per-gt enhancements/fixes (rev4) URL : https://patchwork.freedesktop.org/series/102665/ 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 drm/i915: Media freq factor and per-gt enhancements/fixes (rev4)
== Series Details == Series: drm/i915: Media freq factor and per-gt enhancements/fixes (rev4) URL : https://patchwork.freedesktop.org/series/102665/ State : warning == Summary == Error: dim checkpatch failed 720f593ecbb4 drm/i915: Introduce has_media_ratio_mode 3c55d72952c7 drm/i915/gt: Add media freq factor to per-gt sysfs 7d95ec03bc5c drm/i915/pcode: Extend pcode functions for multiple gt's d4d085d5329c drm/i915/pcode: Add a couple of pcode helpers 87ee92d4c079 drm/i915/gt: Add media RP0/RPn to per-gt sysfs -:83: CHECK:CAMELCASE: Avoid CamelCase: #83: FILE: drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:719: +static DEVICE_ATTR_RO(media_RPn_freq_mhz); -:89: CHECK:CAMELCASE: Avoid CamelCase: #89: FILE: drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:725: + _attr_media_RPn_freq_mhz.attr, total: 0 errors, 0 warnings, 2 checks, 80 lines checked 8ab6df0311f7 drm/i915/gt: Fix memory leaks in per-gt sysfs e7bbfef93b31 drm/i915/gt: Expose per-gt RPS defaults in sysfs ffca9fefe5d0 drm/i915/gt: Expose default value for media_freq_factor in per-gt sysfs
Re: [Intel-gfx] [PATCH v2 7/7] vfio: Remove calls to vfio_group_add_container_user()
On Thu, 21 Apr 2022 13:28:38 -0300 Jason Gunthorpe wrote: > When the open_device() op is called the container_users is incremented and > held incremented until close_device(). Thus, so long as drivers call > functions within their open_device()/close_device() region they do not > need to worry about the container_users. > > These functions can all only be called between open_device() and > close_device(): > > vfio_pin_pages() > vfio_unpin_pages() > vfio_dma_rw() > vfio_register_notifier() > vfio_unregister_notifier() > > Eliminate the calls to vfio_group_add_container_user() and add > vfio_assert_device_open() to detect driver mis-use. A comment here explaining that decrementing open_count is pushed until after close_device to support this feature would help to explain the somewhat subtle change in vfio_group_get_device_fd(). Otherwise the series looks ok with fixes noted by previous reviews. Thanks, Alex
[Intel-gfx] [PATCH 3/8] drm/i915/pcode: Extend pcode functions for multiple gt's
Each gt contains an independent instance of pcode. Extend pcode functions
to interface with pcode on different gt's. To avoid creating dependency of
display functionality on intel_gt, pcode function interfaces are exposed in
terms of uncore rather than intel_gt. Callers have been converted to pass
in the appropritate (i915 or intel_gt) uncore to the pcode functions.
v2: Expose pcode functions in terms of uncore rather than gt (Jani/Rodrigo)
v3: Retain previous function names to eliminate needless #defines (Rodrigo)
Cc: Rodrigo Vivi
Cc: Jani Nikula
Cc: Andi Shyti
Signed-off-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/display/hsw_ips.c| 4 +-
drivers/gpu/drm/i915/display/intel_bw.c | 6 +-
drivers/gpu/drm/i915/display/intel_cdclk.c| 16 ++---
.../drm/i915/display/intel_display_power.c| 2 +-
.../i915/display/intel_display_power_well.c | 4 +-
drivers/gpu/drm/i915/display/intel_hdcp.c | 2 +-
drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 4 +-
drivers/gpu/drm/i915/gt/intel_llc.c | 3 +-
drivers/gpu/drm/i915/gt/intel_rc6.c | 4 +-
drivers/gpu/drm/i915/gt/intel_rps.c | 4 +-
drivers/gpu/drm/i915/gt/selftest_llc.c| 2 +-
drivers/gpu/drm/i915/gt/selftest_rps.c| 2 +-
drivers/gpu/drm/i915/i915_driver.c| 20 ++-
drivers/gpu/drm/i915/intel_dram.c | 2 +-
drivers/gpu/drm/i915/intel_pcode.c| 60 +--
drivers/gpu/drm/i915/intel_pcode.h| 14 ++---
drivers/gpu/drm/i915/intel_pm.c | 10 ++--
17 files changed, 86 insertions(+), 73 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/hsw_ips.c
b/drivers/gpu/drm/i915/display/hsw_ips.c
index 38014e0cc9ad..861dcd2eb890 100644
--- a/drivers/gpu/drm/i915/display/hsw_ips.c
+++ b/drivers/gpu/drm/i915/display/hsw_ips.c
@@ -28,7 +28,7 @@ static void hsw_ips_enable(const struct intel_crtc_state
*crtc_state)
if (IS_BROADWELL(i915)) {
drm_WARN_ON(>drm,
- snb_pcode_write(i915, DISPLAY_IPS_CONTROL,
+ snb_pcode_write(>uncore, DISPLAY_IPS_CONTROL,
IPS_ENABLE | IPS_PCODE_CONTROL));
/*
* Quoting Art Runyan: "its not safe to expect any particular
@@ -62,7 +62,7 @@ bool hsw_ips_disable(const struct intel_crtc_state
*crtc_state)
if (IS_BROADWELL(i915)) {
drm_WARN_ON(>drm,
- snb_pcode_write(i915, DISPLAY_IPS_CONTROL, 0));
+ snb_pcode_write(>uncore, DISPLAY_IPS_CONTROL,
0));
/*
* Wait for PCODE to finish disabling IPS. The BSpec specified
* 42ms timeout value leads to occasional timeouts so use 100ms
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index 37bd7b17f3d0..79269d2c476b 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -78,7 +78,7 @@ static int icl_pcode_read_qgv_point_info(struct
drm_i915_private *dev_priv,
u16 dclk;
int ret;
- ret = snb_pcode_read(dev_priv, ICL_PCODE_MEM_SUBSYSYSTEM_INFO |
+ ret = snb_pcode_read(_priv->uncore, ICL_PCODE_MEM_SUBSYSYSTEM_INFO |
ICL_PCODE_MEM_SS_READ_QGV_POINT_INFO(point),
, );
if (ret)
@@ -104,7 +104,7 @@ static int adls_pcode_read_psf_gv_point_info(struct
drm_i915_private *dev_priv,
int ret;
int i;
- ret = snb_pcode_read(dev_priv, ICL_PCODE_MEM_SUBSYSYSTEM_INFO |
+ ret = snb_pcode_read(_priv->uncore, ICL_PCODE_MEM_SUBSYSYSTEM_INFO |
ADL_PCODE_MEM_SS_READ_PSF_GV_INFO, , NULL);
if (ret)
return ret;
@@ -123,7 +123,7 @@ int icl_pcode_restrict_qgv_points(struct drm_i915_private
*dev_priv,
int ret;
/* bspec says to keep retrying for at least 1 ms */
- ret = skl_pcode_request(dev_priv, ICL_PCODE_SAGV_DE_MEM_SS_CONFIG,
+ ret = skl_pcode_request(_priv->uncore,
ICL_PCODE_SAGV_DE_MEM_SS_CONFIG,
points_mask,
ICL_PCODE_REP_QGV_MASK |
ADLS_PCODE_REP_PSF_MASK,
ICL_PCODE_REP_QGV_SAFE |
ADLS_PCODE_REP_PSF_SAFE,
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index b2017d8161b4..6e80162632dd 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -800,7 +800,7 @@ static void bdw_set_cdclk(struct drm_i915_private *dev_priv,
"trying to change cdclk frequency with cdclk not
enabled\n"))
return;
- ret = snb_pcode_write(dev_priv, BDW_PCODE_DISPLAY_FREQ_CHANGE_REQ, 0x0);
+ ret = snb_pcode_write(_priv->uncore,
BDW_PCODE_DISPLAY_FREQ_CHANGE_REQ, 0x0);
[Intel-gfx] [PATCH 6/8] drm/i915/gt: Fix memory leaks in per-gt sysfs
All kmalloc'd kobjects need a kobject_put() to free memory. For example in
previous code, kobj_gt_release() never gets called. The requirement of
kobject_put() now results in a slightly different code organization.
v2: s/gtn/gt/ (Andi)
Cc: Andi Shyti
Cc: Andrzej Hajda
Fixes: b770bcfae9ad ("drm/i915/gt: create per-tile sysfs interface")
Signed-off-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/gt/intel_gt.c | 1 +
drivers/gpu/drm/i915/gt/intel_gt_sysfs.c | 29 ++--
drivers/gpu/drm/i915/gt/intel_gt_sysfs.h | 6 +
drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 +++
drivers/gpu/drm/i915/i915_sysfs.c| 2 ++
5 files changed, 19 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 92394f13b42f..9aede288eb86 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -785,6 +785,7 @@ void intel_gt_driver_unregister(struct intel_gt *gt)
{
intel_wakeref_t wakeref;
+ intel_gt_sysfs_unregister(gt);
intel_rps_driver_unregister(>rps);
intel_gsc_fini(>gsc);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
index 8ec8bc660c8c..9e4ebf53379b 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
@@ -24,7 +24,7 @@ bool is_object_gt(struct kobject *kobj)
static struct intel_gt *kobj_to_gt(struct kobject *kobj)
{
- return container_of(kobj, struct kobj_gt, base)->gt;
+ return container_of(kobj, struct intel_gt, sysfs_gt);
}
struct intel_gt *intel_gt_sysfs_get_drvdata(struct device *dev,
@@ -72,9 +72,9 @@ static struct attribute *id_attrs[] = {
};
ATTRIBUTE_GROUPS(id);
+/* A kobject needs a release() method even if it does nothing */
static void kobj_gt_release(struct kobject *kobj)
{
- kfree(kobj);
}
static struct kobj_type kobj_gt_type = {
@@ -85,8 +85,6 @@ static struct kobj_type kobj_gt_type = {
void intel_gt_sysfs_register(struct intel_gt *gt)
{
- struct kobj_gt *kg;
-
/*
* We need to make things right with the
* ABI compatibility. The files were originally
@@ -98,25 +96,22 @@ void intel_gt_sysfs_register(struct intel_gt *gt)
if (gt_is_root(gt))
intel_gt_sysfs_pm_init(gt, gt_get_parent_obj(gt));
- kg = kzalloc(sizeof(*kg), GFP_KERNEL);
- if (!kg)
+ /* init and xfer ownership to sysfs tree */
+ if (kobject_init_and_add(>sysfs_gt, _gt_type,
+gt->i915->sysfs_gt, "gt%d", gt->info.id))
goto exit_fail;
- kobject_init(>base, _gt_type);
- kg->gt = gt;
-
- /* xfer ownership to sysfs tree */
- if (kobject_add(>base, gt->i915->sysfs_gt, "gt%d", gt->info.id))
- goto exit_kobj_put;
-
- intel_gt_sysfs_pm_init(gt, >base);
+ intel_gt_sysfs_pm_init(gt, >sysfs_gt);
return;
-exit_kobj_put:
- kobject_put(>base);
-
exit_fail:
+ kobject_put(>sysfs_gt);
drm_warn(>i915->drm,
"failed to initialize gt%d sysfs root\n", gt->info.id);
}
+
+void intel_gt_sysfs_unregister(struct intel_gt *gt)
+{
+ kobject_put(>sysfs_gt);
+}
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
index 9471b26752cf..a99aa7e8b01a 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
@@ -13,11 +13,6 @@
struct intel_gt;
-struct kobj_gt {
- struct kobject base;
- struct intel_gt *gt;
-};
-
bool is_object_gt(struct kobject *kobj);
struct drm_i915_private *kobj_to_i915(struct kobject *kobj);
@@ -28,6 +23,7 @@ intel_gt_create_kobj(struct intel_gt *gt,
const char *name);
void intel_gt_sysfs_register(struct intel_gt *gt);
+void intel_gt_sysfs_unregister(struct intel_gt *gt);
struct intel_gt *intel_gt_sysfs_get_drvdata(struct device *dev,
const char *name);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index b06611c1d4ad..edd7a3cf5f5f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -224,6 +224,9 @@ struct intel_gt {
} mocs;
struct intel_pxp pxp;
+
+ /* gt/gtN sysfs */
+ struct kobject sysfs_gt;
};
enum intel_gt_scratch_field {
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index 8521daba212a..3f06106cdcf5 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -259,4 +259,6 @@ void i915_teardown_sysfs(struct drm_i915_private *dev_priv)
device_remove_bin_file(kdev, _attrs_1);
device_remove_bin_file(kdev, _attrs);
+
+ kobject_put(dev_priv->sysfs_gt);
}
--
2.34.1
[Intel-gfx] [PATCH 8/8] drm/i915/gt: Expose default value for media_freq_factor in per-gt sysfs
Add the following sysfs file to gt/gtN/.defaults:
* media_freq_factor
Cc: Joonas Lahtinen
Signed-off-by: Ashutosh Dixit
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 18 ++
drivers/gpu/drm/i915/gt/intel_gt_types.h| 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 2 ++
3 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
index 5a191973322e..3a6e22d31d46 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
@@ -759,6 +759,18 @@ default_boost_freq_mhz_show(struct kobject *kobj, struct
kobj_attribute *attr, c
static struct kobj_attribute default_boost_freq_mhz =
__ATTR(rps_boost_freq_mhz, 0444, default_boost_freq_mhz_show, NULL);
+static ssize_t
+default_media_freq_factor_show(struct kobject *kobj, struct kobj_attribute
*attr, char *buf)
+{
+ struct intel_gt *gt = kobj_to_gt(kobj->parent);
+
+ return sysfs_emit(buf, "%d\n",
+
media_ratio_mode_to_factor(gt->rps_defaults.media_ratio_mode));
+}
+
+static struct kobj_attribute default_media_freq_factor =
+__ATTR(media_freq_factor, 0444, default_media_freq_factor_show, NULL);
+
static const struct attribute * const rps_defaults_attrs[] = {
_min_freq_mhz.attr,
_max_freq_mhz.attr,
@@ -819,6 +831,12 @@ void intel_gt_sysfs_pm_init(struct intel_gt *gt, struct
kobject *kobj)
drm_warn(>i915->drm,
"failed to create add gt%u
media_perf_power_attrs sysfs (%pe)\n",
gt->info.id, ERR_PTR(ret));
+
+ ret = sysfs_create_file(gt->sysfs_defaults,
_media_freq_factor.attr);
+ if (ret)
+ drm_warn(>i915->drm,
+"failed to add gt%u default_media_freq_factor
sysfs (%pe)\n",
+gt->info.id, ERR_PTR(ret));
}
ret = add_rps_defaults(gt);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index 8b696669b846..07d368ca78ca 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -66,6 +66,7 @@ struct intel_rps_defaults {
u32 min_freq;
u32 max_freq;
u32 boost_freq;
+ u32 media_ratio_mode;
};
enum intel_submission_method {
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
index cefd864c84eb..047c80838fcd 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
@@ -260,7 +260,9 @@ int intel_guc_slpc_init(struct intel_guc_slpc *slpc)
slpc->boost_freq = 0;
atomic_set(>num_waiters, 0);
slpc->num_boosts = 0;
+
slpc->media_ratio_mode = SLPC_MEDIA_RATIO_MODE_DYNAMIC_CONTROL;
+ slpc_to_gt(slpc)->rps_defaults.media_ratio_mode =
slpc->media_ratio_mode;
mutex_init(>lock);
INIT_WORK(>boost_work, slpc_boost_work);
--
2.34.1
[Intel-gfx] [PATCH 2/8] drm/i915/gt: Add media freq factor to per-gt sysfs
Expose new sysfs to program and retrieve media freq factor. Factor values
of 0 (dynamic), 0.5 and 1.0 are supported via a u8.8 fixed point
representation (corresponding to integer values of 0, 128 and 256
respectively).
Media freq factor is converted to media_ratio_mode for GuC. It is
programmed into GuC using H2G SLPC interface. It is retrieved from GuC
through a register read. A cached media_ratio_mode is maintained to
preserve set values across GuC resets.
This patch adds the following sysfs files to gt/gtN sysfs:
* media_freq_factor
* media_freq_factor.scale
Cc: Joonas Lahtinen
Signed-off-by: Dale B Stimson
Signed-off-by: Ashutosh Dixit
Reviewed-by: Andi Shyti
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 130 ++
.../drm/i915/gt/uc/abi/guc_actions_slpc_abi.h | 6 +
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 20 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h | 1 +
.../gpu/drm/i915/gt/uc/intel_guc_slpc_types.h | 3 +
6 files changed, 161 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index a39718a40cc3..8ba84c336925 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -732,6 +732,7 @@
#define GEN6_AGGRESSIVE_TURBO(0 << 15)
#define GEN9_SW_REQ_UNSLICE_RATIO_SHIFT 23
#define GEN9_IGNORE_SLICE_RATIO (0 << 0)
+#define GEN12_MEDIA_FREQ_RATIO REG_BIT(13)
#define GEN6_RC_VIDEO_FREQ _MMIO(0xa00c)
#define GEN6_RC_CTL_RC6pp_ENABLE (1 << 16)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
index 26cbfa6477d1..2b1cd6a01724 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
@@ -557,6 +557,128 @@ static const struct attribute *freq_attrs[] = {
NULL
};
+/*
+ * Scaling for multipliers (aka frequency factors).
+ * The format of the value in the register is u8.8.
+ *
+ * The presentation to userspace is inspired by the perf event framework.
+ * See:
+ * Documentation/ABI/testing/sysfs-bus-event_source-devices-events
+ * for description of:
+ * /sys/bus/event_source/devices//events/.scale
+ *
+ * Summary: Expose two sysfs files for each multiplier.
+ *
+ * 1. File contains a raw hardware value.
+ * 2. File .scale contains the multiplicative scale factor to be
+ *used by userspace to compute the actual value.
+ *
+ * So userspace knows that to get the frequency_factor it multiplies the
+ * provided value by the specified scale factor and vice-versa.
+ *
+ * That way there is no precision loss in the kernel interface and API
+ * is future proof should one day the hardware register change to u16.u16,
+ * on some platform. (Or any other fixed point representation.)
+ *
+ * Example:
+ * File contains the value 2.5, represented as u8.8 0x0280, which
+ * is comprised of:
+ * - an integer part of 2
+ * - a fractional part of 0x80 (representing 0x80 / 2^8 == 0x80 / 256).
+ * File .scale contains a string representation of floating point
+ * value 0.00390625 (which is (1 / 256)).
+ * Userspace computes the actual value:
+ * 0x0280 * 0.00390625 -> 2.5
+ * or converts an actual value to the value to be written into :
+ * 2.5 / 0.00390625 -> 0x0280
+ */
+
+#define U8_8_VAL_MASK 0x
+#define U8_8_SCALE_TO_VALUE "0.00390625"
+
+static ssize_t freq_factor_scale_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buff)
+{
+ return sysfs_emit(buff, "%s\n", U8_8_SCALE_TO_VALUE);
+}
+
+static u32 media_ratio_mode_to_factor(u32 mode)
+{
+ /* 0 -> 0, 1 -> 256, 2 -> 128 */
+ return !mode ? mode : 256 / mode;
+}
+
+static ssize_t media_freq_factor_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buff)
+{
+ struct intel_gt *gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
+ struct intel_guc_slpc *slpc = >uc.guc.slpc;
+ intel_wakeref_t wakeref;
+ u32 mode;
+
+ /*
+* Retrieve media_ratio_mode from GEN6_RPNSWREQ bit 13 set by
+* GuC. GEN6_RPNSWREQ:13 value 0 represents 1:2 and 1 represents 1:1
+*/
+ if (IS_XEHPSDV(gt->i915) &&
+ slpc->media_ratio_mode == SLPC_MEDIA_RATIO_MODE_DYNAMIC_CONTROL) {
+ /*
+* For XEHPSDV dynamic mode GEN6_RPNSWREQ:13 does not contain
+* the media_ratio_mode, just return the cached media ratio
+*/
+ mode = slpc->media_ratio_mode;
+ } else {
+ with_intel_runtime_pm(gt->uncore->rpm, wakeref)
+ mode = intel_uncore_read(gt->uncore, GEN6_RPNSWREQ);
+
[Intel-gfx] [PATCH 4/8] drm/i915/pcode: Add a couple of pcode helpers
From: Dale B Stimson
Some dGfx pcode commands take additional sub-commands and parameters. Add a
couple of helpers to help formatting these commands to improve code
readability.
v2: Fixed commit author (Rodrigo)
v3: Function rename and convert to new uncore interface for pcode functions
Remove unnecessary #define's (Andi)
v4: Another function rename
Cc: Andi Shyti
Cc: Rodrigo Vivi
Signed-off-by: Dale B Stimson
Signed-off-by: Ashutosh Dixit
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_reg.h| 3 +++
drivers/gpu/drm/i915/intel_pcode.c | 32 ++
drivers/gpu/drm/i915/intel_pcode.h | 6 ++
3 files changed, 41 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9ccb67eec1bd..5a4689171cc7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6689,6 +6689,9 @@
#define GEN6_PCODE_MAILBOX _MMIO(0x138124)
#define GEN6_PCODE_READY (1 << 31)
+#define GEN6_PCODE_MB_PARAM2 REG_GENMASK(23, 16)
+#define GEN6_PCODE_MB_PARAM1 REG_GENMASK(15, 8)
+#define GEN6_PCODE_MB_COMMANDREG_GENMASK(7, 0)
#define GEN6_PCODE_ERROR_MASK0xFF
#define GEN6_PCODE_SUCCESS 0x0
#define GEN6_PCODE_ILLEGAL_CMD 0x1
diff --git a/drivers/gpu/drm/i915/intel_pcode.c
b/drivers/gpu/drm/i915/intel_pcode.c
index 44c09b152b59..16f3e7ee1b6e 100644
--- a/drivers/gpu/drm/i915/intel_pcode.c
+++ b/drivers/gpu/drm/i915/intel_pcode.c
@@ -223,3 +223,35 @@ int intel_pcode_init(struct intel_uncore *uncore)
return ret;
}
+
+int snb_pcode_read_p(struct intel_uncore *uncore, u32 mbcmd, u32 p1, u32 p2,
u32 *val)
+{
+ intel_wakeref_t wakeref;
+ u32 mbox;
+ int err;
+
+ mbox = REG_FIELD_PREP(GEN6_PCODE_MB_COMMAND, mbcmd)
+ | REG_FIELD_PREP(GEN6_PCODE_MB_PARAM1, p1)
+ | REG_FIELD_PREP(GEN6_PCODE_MB_PARAM2, p2);
+
+ with_intel_runtime_pm(uncore->rpm, wakeref)
+ err = snb_pcode_read(uncore, mbox, val, NULL);
+
+ return err;
+}
+
+int snb_pcode_write_p(struct intel_uncore *uncore, u32 mbcmd, u32 p1, u32 p2,
u32 val)
+{
+ intel_wakeref_t wakeref;
+ u32 mbox;
+ int err;
+
+ mbox = REG_FIELD_PREP(GEN6_PCODE_MB_COMMAND, mbcmd)
+ | REG_FIELD_PREP(GEN6_PCODE_MB_PARAM1, p1)
+ | REG_FIELD_PREP(GEN6_PCODE_MB_PARAM2, p2);
+
+ with_intel_runtime_pm(uncore->rpm, wakeref)
+ err = snb_pcode_write(uncore, mbox, val);
+
+ return err;
+}
diff --git a/drivers/gpu/drm/i915/intel_pcode.h
b/drivers/gpu/drm/i915/intel_pcode.h
index 8f6241b114a5..8d2198e29422 100644
--- a/drivers/gpu/drm/i915/intel_pcode.h
+++ b/drivers/gpu/drm/i915/intel_pcode.h
@@ -21,4 +21,10 @@ int skl_pcode_request(struct intel_uncore *uncore, u32 mbox,
u32 request,
int intel_pcode_init(struct intel_uncore *uncore);
+/*
+ * Helpers for dGfx PCODE mailbox command formatting
+ */
+int snb_pcode_read_p(struct intel_uncore *uncore, u32 mbcmd, u32 p1, u32 p2,
u32 *val);
+int snb_pcode_write_p(struct intel_uncore *uncore, u32 mbcmd, u32 p1, u32 p2,
u32 val);
+
#endif /* _INTEL_PCODE_H */
--
2.34.1
[Intel-gfx] [PATCH 5/8] drm/i915/gt: Add media RP0/RPn to per-gt sysfs
From: Dale B Stimson
Retrieve RP0 and RPn freq for media IP from PCODE and display in per-gt
sysfs. This patch adds the following files to gt/gtN sysfs:
* media_RP0_freq_mhz
* media_RPn_freq_mhz
v2: Fixed commit author (Rodrigo)
v3: Convert to new uncore interface for pcode functions
v4: Adapt to intel_pcode.* function rename
Cc: Rodrigo Vivi
Cc: Joonas Lahtinen
Signed-off-by: Dale B Stimson
Signed-off-by: Ashutosh Dixit
Reviewed-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 47 +
drivers/gpu/drm/i915/i915_reg.h | 8
2 files changed, 55 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
index 2b1cd6a01724..ab91e9cf9deb 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
@@ -12,6 +12,7 @@
#include "i915_sysfs.h"
#include "intel_gt.h"
#include "intel_gt_regs.h"
+#include "intel_pcode.h"
#include "intel_gt_sysfs.h"
#include "intel_gt_sysfs_pm.h"
#include "intel_rc6.h"
@@ -669,13 +670,59 @@ static ssize_t media_freq_factor_store(struct device *dev,
return err ?: count;
}
+static ssize_t media_RP0_freq_mhz_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buff)
+{
+ struct intel_gt *gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
+ u32 val;
+ int err;
+
+ err = snb_pcode_read_p(gt->uncore, XEHPSDV_PCODE_FREQUENCY_CONFIG,
+ PCODE_MBOX_FC_SC_READ_FUSED_P0,
+ PCODE_MBOX_DOMAIN_MEDIAFF, );
+
+ if (err)
+ return err;
+
+ /* Fused media RP0 read from pcode is in units of 50 MHz */
+ val *= GT_FREQUENCY_MULTIPLIER;
+
+ return sysfs_emit(buff, "%u\n", val);
+}
+
+static ssize_t media_RPn_freq_mhz_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buff)
+{
+ struct intel_gt *gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
+ u32 val;
+ int err;
+
+ err = snb_pcode_read_p(gt->uncore, XEHPSDV_PCODE_FREQUENCY_CONFIG,
+ PCODE_MBOX_FC_SC_READ_FUSED_PN,
+ PCODE_MBOX_DOMAIN_MEDIAFF, );
+
+ if (err)
+ return err;
+
+ /* Fused media RPn read from pcode is in units of 50 MHz */
+ val *= GT_FREQUENCY_MULTIPLIER;
+
+ return sysfs_emit(buff, "%u\n", val);
+}
+
static DEVICE_ATTR_RW(media_freq_factor);
static struct device_attribute dev_attr_media_freq_factor_scale =
__ATTR(media_freq_factor.scale, 0444, freq_factor_scale_show, NULL);
+static DEVICE_ATTR_RO(media_RP0_freq_mhz);
+static DEVICE_ATTR_RO(media_RPn_freq_mhz);
static const struct attribute *media_perf_power_attrs[] = {
_attr_media_freq_factor.attr,
_attr_media_freq_factor_scale.attr,
+ _attr_media_RP0_freq_mhz.attr,
+ _attr_media_RPn_freq_mhz.attr,
NULL
};
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5a4689171cc7..90a9922faffc 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6758,6 +6758,14 @@
#define DG1_UNCORE_GET_INIT_STATUS 0x0
#define DG1_UNCORE_INIT_STATUS_COMPLETE0x1
#define GEN12_PCODE_READ_SAGV_BLOCK_TIME_US0x23
+#define XEHPSDV_PCODE_FREQUENCY_CONFIG 0x6e/* xehpsdv, pvc
*/
+/* XEHPSDV_PCODE_FREQUENCY_CONFIG sub-commands (param1) */
+#define PCODE_MBOX_FC_SC_READ_FUSED_P0 0x0
+#define PCODE_MBOX_FC_SC_READ_FUSED_PN 0x1
+/* PCODE_MBOX_DOMAIN_* - mailbox domain IDs */
+/* XEHPSDV_PCODE_FREQUENCY_CONFIG param2 */
+#define PCODE_MBOX_DOMAIN_NONE 0x0
+#define PCODE_MBOX_DOMAIN_MEDIAFF 0x3
#define GEN6_PCODE_DATA_MMIO(0x138128)
#define GEN6_PCODE_FREQ_IA_RATIO_SHIFT 8
#define GEN6_PCODE_FREQ_RING_RATIO_SHIFT 16
--
2.34.1
[Intel-gfx] [PATCH 1/8] drm/i915: Introduce has_media_ratio_mode
Media ratio mode (the ability for media IP to work at a different frequency
from the GT) is available for a subset of dGfx platforms supporting
GuC/SLPC. Introduce 'has_media_ratio_mode' flag in intel_device_info to
identify these platforms and set it for XEHPSDV and DG2/ATS-M.
Signed-off-by: Ashutosh Dixit
Reviewed-by: Rodrigo Vivi
Reviewed-by: Andi Shyti
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_pci.c | 2 ++
drivers/gpu/drm/i915/intel_device_info.h | 1 +
3 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 24111bf42ce0..96625eabb244 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1227,6 +1227,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
#define CCS_MASK(gt) \
ENGINE_INSTANCES_MASK(gt, CCS0, I915_MAX_CCS)
+#define HAS_MEDIA_RATIO_MODE(dev_priv)
(INTEL_INFO(dev_priv)->has_media_ratio_mode)
+
/*
* The Gen7 cmdparser copies the scanned buffer to the ggtt for execution
* All later gens can run the final buffer from the ppgtt
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index b60492826478..3ea1e11cc2a7 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1033,6 +1033,7 @@ static const struct intel_device_info xehpsdv_info = {
.display = { },
.has_64k_pages = 1,
.needs_compact_pt = 1,
+ .has_media_ratio_mode = 1,
.platform_engine_mask =
BIT(RCS0) | BIT(BCS0) |
BIT(VECS0) | BIT(VECS1) | BIT(VECS2) | BIT(VECS3) |
@@ -1053,6 +1054,7 @@ static const struct intel_device_info xehpsdv_info = {
.has_guc_deprivilege = 1, \
.has_heci_pxp = 1, \
.needs_compact_pt = 1, \
+ .has_media_ratio_mode = 1, \
.platform_engine_mask = \
BIT(RCS0) | BIT(BCS0) | \
BIT(VECS0) | BIT(VECS1) | \
diff --git a/drivers/gpu/drm/i915/intel_device_info.h
b/drivers/gpu/drm/i915/intel_device_info.h
index 20c351c8d5bd..2bd67b3457f1 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -153,6 +153,7 @@ enum intel_ppgtt_type {
func(has_llc); \
func(has_logical_ring_contexts); \
func(has_logical_ring_elsq); \
+ func(has_media_ratio_mode); \
func(has_mslices); \
func(has_pooled_eu); \
func(has_pxp); \
--
2.34.1
[Intel-gfx] [PATCH 7/8] drm/i915/gt: Expose per-gt RPS defaults in sysfs
Create a gt/gtN/.defaults directory (similar to
engine//.defaults) to expose default parameter values for each
gt in sysfs. Populate the .defaults directory with RPS parameter default
values in order to allow userspace to revert to default values when needed.
This patch adds the following sysfs files to gt/gtN/.defaults:
* default_min_freq_mhz
* default_max_freq_mhz
* default_boost_freq_mhz
Cc: Joonas Lahtinen
Signed-off-by: Ashutosh Dixit
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/gt/intel_gt_sysfs.c| 10 ++--
drivers/gpu/drm/i915/gt/intel_gt_sysfs.h| 6 +++
drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 51 +
drivers/gpu/drm/i915/gt/intel_gt_types.h| 10
drivers/gpu/drm/i915/gt/intel_rps.c | 3 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 17 +--
6 files changed, 87 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
index 9e4ebf53379b..d651ccd0ab20 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
@@ -22,11 +22,6 @@ bool is_object_gt(struct kobject *kobj)
return !strncmp(kobj->name, "gt", 2);
}
-static struct intel_gt *kobj_to_gt(struct kobject *kobj)
-{
- return container_of(kobj, struct intel_gt, sysfs_gt);
-}
-
struct intel_gt *intel_gt_sysfs_get_drvdata(struct device *dev,
const char *name)
{
@@ -101,6 +96,10 @@ void intel_gt_sysfs_register(struct intel_gt *gt)
gt->i915->sysfs_gt, "gt%d", gt->info.id))
goto exit_fail;
+ gt->sysfs_defaults = kobject_create_and_add(".defaults", >sysfs_gt);
+ if (!gt->sysfs_defaults)
+ goto exit_fail;
+
intel_gt_sysfs_pm_init(gt, >sysfs_gt);
return;
@@ -113,5 +112,6 @@ void intel_gt_sysfs_register(struct intel_gt *gt)
void intel_gt_sysfs_unregister(struct intel_gt *gt)
{
+ kobject_put(gt->sysfs_defaults);
kobject_put(>sysfs_gt);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
index a99aa7e8b01a..6232923a420d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
@@ -10,6 +10,7 @@
#include
#include "i915_gem.h" /* GEM_BUG_ON() */
+#include "intel_gt_types.h"
struct intel_gt;
@@ -22,6 +23,11 @@ intel_gt_create_kobj(struct intel_gt *gt,
struct kobject *dir,
const char *name);
+static inline struct intel_gt *kobj_to_gt(struct kobject *kobj)
+{
+ return container_of(kobj, struct intel_gt, sysfs_gt);
+}
+
void intel_gt_sysfs_register(struct intel_gt *gt);
void intel_gt_sysfs_unregister(struct intel_gt *gt);
struct intel_gt *intel_gt_sysfs_get_drvdata(struct device *dev,
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
index ab91e9cf9deb..5a191973322e 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
@@ -726,6 +726,51 @@ static const struct attribute *media_perf_power_attrs[] = {
NULL
};
+static ssize_t
+default_min_freq_mhz_show(struct kobject *kobj, struct kobj_attribute *attr,
char *buf)
+{
+ struct intel_gt *gt = kobj_to_gt(kobj->parent);
+
+ return sysfs_emit(buf, "%d\n", gt->rps_defaults.min_freq);
+}
+
+static struct kobj_attribute default_min_freq_mhz =
+__ATTR(rps_min_freq_mhz, 0444, default_min_freq_mhz_show, NULL);
+
+static ssize_t
+default_max_freq_mhz_show(struct kobject *kobj, struct kobj_attribute *attr,
char *buf)
+{
+ struct intel_gt *gt = kobj_to_gt(kobj->parent);
+
+ return sysfs_emit(buf, "%d\n", gt->rps_defaults.max_freq);
+}
+
+static struct kobj_attribute default_max_freq_mhz =
+__ATTR(rps_max_freq_mhz, 0444, default_max_freq_mhz_show, NULL);
+
+static ssize_t
+default_boost_freq_mhz_show(struct kobject *kobj, struct kobj_attribute *attr,
char *buf)
+{
+ struct intel_gt *gt = kobj_to_gt(kobj->parent);
+
+ return sysfs_emit(buf, "%d\n", gt->rps_defaults.boost_freq);
+}
+
+static struct kobj_attribute default_boost_freq_mhz =
+__ATTR(rps_boost_freq_mhz, 0444, default_boost_freq_mhz_show, NULL);
+
+static const struct attribute * const rps_defaults_attrs[] = {
+ _min_freq_mhz.attr,
+ _max_freq_mhz.attr,
+ _boost_freq_mhz.attr,
+ NULL
+};
+
+static int add_rps_defaults(struct intel_gt *gt)
+{
+ return sysfs_create_files(gt->sysfs_defaults, rps_defaults_attrs);
+}
+
static int intel_sysfs_rps_init(struct intel_gt *gt, struct kobject *kobj,
const struct attribute * const *attrs)
{
@@ -775,4 +820,10 @@ void intel_gt_sysfs_pm_init(struct intel_gt *gt, struct
kobject *kobj)
"failed to create add gt%u
media_perf_power_attrs sysfs (%pe)\n",
[Intel-gfx] [PATCH v4 0/8] drm/i915: Media freq factor and per-gt enhancements/fixes
Some recent Intel dGfx platforms allow media IP to work at a different frequency from the base GT. This patch series exposes sysfs controls for this functionality in the new per-gt sysfs. Some enhancements and fixes to previous per-gt functionality are also included to complete the new functionality: * Patches 1 and 2 implement basic sysfs controls for media freq * Patch 3 extends previous pcode functions for multiple gt's and patch 4 adds a couple of pcode helpers * Patch 5 uses the new pcode functions to retrieve media RP0/RPn freq * Patch 6 fixes memory leaks in the previous per-gt sysfs implementation and some code refactoring * Patch 7 creates a gt/gtN/.defaults directory to expose default RPS parameter values in the per-gt sysfs * Patch 8 adds the default value for media_freq_factor to gt/gtN/.defaults IGT tests for this new functionality have also been posted at: https://patchwork.freedesktop.org/series/103107/ Test-with: 20220426000337.9367-1-ashutosh.di...@intel.com v2: Fixed commit author on patches 5 and 6 (Rodrigo) Added new patch 4 v3: Expose pcode functions in terms of uncore rather than gt (Jani/Rodrigo) v4: Retain previous pcode function names to eliminate needless #defines (Rodrigo) Cc: Rodrigo Vivi Cc: Joonas Lahtinen Cc: Andi Shyti Ashutosh Dixit (6): drm/i915: Introduce has_media_ratio_mode drm/i915/gt: Add media freq factor to per-gt sysfs drm/i915/pcode: Extend pcode functions for multiple gt's drm/i915/gt: Fix memory leaks in per-gt sysfs drm/i915/gt: Expose per-gt RPS defaults in sysfs drm/i915/gt: Expose default value for media_freq_factor in per-gt sysfs Dale B Stimson (2): drm/i915/pcode: Add a couple of pcode helpers drm/i915/gt: Add media RP0/RPn to per-gt sysfs drivers/gpu/drm/i915/display/hsw_ips.c| 4 +- drivers/gpu/drm/i915/display/intel_bw.c | 6 +- drivers/gpu/drm/i915/display/intel_cdclk.c| 16 +- .../drm/i915/display/intel_display_power.c| 2 +- .../i915/display/intel_display_power_well.c | 4 +- drivers/gpu/drm/i915/display/intel_hdcp.c | 2 +- drivers/gpu/drm/i915/gt/intel_gt.c| 1 + drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 4 +- drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 + drivers/gpu/drm/i915/gt/intel_gt_sysfs.c | 35 ++- drivers/gpu/drm/i915/gt/intel_gt_sysfs.h | 12 +- drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 246 ++ drivers/gpu/drm/i915/gt/intel_gt_types.h | 14 + drivers/gpu/drm/i915/gt/intel_llc.c | 3 +- drivers/gpu/drm/i915/gt/intel_rc6.c | 4 +- drivers/gpu/drm/i915/gt/intel_rps.c | 7 +- drivers/gpu/drm/i915/gt/selftest_llc.c| 2 +- drivers/gpu/drm/i915/gt/selftest_rps.c| 2 +- .../drm/i915/gt/uc/abi/guc_actions_slpc_abi.h | 6 + drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 39 ++- drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h | 1 + .../gpu/drm/i915/gt/uc/intel_guc_slpc_types.h | 3 + drivers/gpu/drm/i915/i915_driver.c| 20 +- drivers/gpu/drm/i915/i915_drv.h | 2 + drivers/gpu/drm/i915/i915_pci.c | 2 + drivers/gpu/drm/i915/i915_reg.h | 11 + drivers/gpu/drm/i915/i915_sysfs.c | 2 + drivers/gpu/drm/i915/intel_device_info.h | 1 + drivers/gpu/drm/i915/intel_dram.c | 2 +- drivers/gpu/drm/i915/intel_pcode.c| 92 --- drivers/gpu/drm/i915/intel_pcode.h| 20 +- drivers/gpu/drm/i915/intel_pm.c | 10 +- 32 files changed, 473 insertions(+), 103 deletions(-) -- 2.34.1
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: ttm for stolen region (rev6)
== Series Details ==
Series: drm/i915: ttm for stolen region (rev6)
URL : https://patchwork.freedesktop.org/series/102540/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11582 -> Patchwork_102540v6
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_102540v6 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_102540v6, 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_102540v6/index.html
Participating hosts (43 -> 43)
--
Additional (2): bat-rpls-1 fi-rkl-11600
Missing(2): fi-bsw-cyan fi-icl-u2
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_102540v6:
### IGT changes ###
Possible regressions
* igt@runner@aborted:
- fi-cfl-8700k: NOTRUN -> [FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v6/fi-cfl-8700k/igt@run...@aborted.html
- fi-bdw-5557u: NOTRUN -> [FAIL][2]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v6/fi-bdw-5557u/igt@run...@aborted.html
- fi-bxt-dsi: NOTRUN -> [FAIL][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v6/fi-bxt-dsi/igt@run...@aborted.html
- fi-adl-ddr5:NOTRUN -> [FAIL][4]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v6/fi-adl-ddr5/igt@run...@aborted.html
- fi-cfl-guc: NOTRUN -> [FAIL][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v6/fi-cfl-guc/igt@run...@aborted.html
- fi-glk-j4005: NOTRUN -> [FAIL][6]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v6/fi-glk-j4005/igt@run...@aborted.html
Warnings
* igt@runner@aborted:
- fi-apl-guc: [FAIL][7] ([i915#4312]) -> [FAIL][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11582/fi-apl-guc/igt@run...@aborted.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v6/fi-apl-guc/igt@run...@aborted.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@runner@aborted:
- {bat-adln-1}: NOTRUN -> [FAIL][9]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v6/bat-adln-1/igt@run...@aborted.html
- {fi-jsl-1}: NOTRUN -> [FAIL][10]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v6/fi-jsl-1/igt@run...@aborted.html
- {fi-ehl-2}: NOTRUN -> [FAIL][11]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v6/fi-ehl-2/igt@run...@aborted.html
Known issues
Here are the changes found in Patchwork_102540v6 that come from known issues:
### IGT changes ###
Issues hit
* igt@runner@aborted:
- fi-rkl-11600: NOTRUN -> [FAIL][12] ([i915#5602])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v6/fi-rkl-11600/igt@run...@aborted.html
- fi-bsw-kefka: NOTRUN -> [FAIL][13] ([i915#3690])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v6/fi-bsw-kefka/igt@run...@aborted.html
- fi-cfl-8109u: NOTRUN -> [FAIL][14] ([i915#5602])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v6/fi-cfl-8109u/igt@run...@aborted.html
- fi-bsw-nick:NOTRUN -> [FAIL][15] ([i915#3690])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v6/fi-bsw-nick/igt@run...@aborted.html
- fi-kbl-soraka: NOTRUN -> [FAIL][16] ([i915#5602])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v6/fi-kbl-soraka/igt@run...@aborted.html
- fi-kbl-7500u: NOTRUN -> [FAIL][17] ([i915#5602])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v6/fi-kbl-7500u/igt@run...@aborted.html
- fi-kbl-guc: NOTRUN -> [FAIL][18] ([i915#5602])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v6/fi-kbl-guc/igt@run...@aborted.html
- fi-rkl-guc: NOTRUN -> [FAIL][19] ([i915#5602])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v6/fi-rkl-guc/igt@run...@aborted.html
- fi-kbl-7567u: NOTRUN -> [FAIL][20] ([i915#5602])
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v6/fi-kbl-7567u/igt@run...@aborted.html
- fi-skl-guc: NOTRUN -> [FAIL][21] ([i915#5602])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v6/fi-skl-guc/igt@run...@aborted.html
- fi-skl-6700k2: NOTRUN -> [FAIL][22] ([i915#5602])
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v6/fi-skl-6700k2/igt@run...@aborted.html
- fi-bsw-n3050: NOTRUN -> [FAIL][23] ([i915#3690])
[Intel-gfx] ✗ Fi.CI.IGT: failure for Handle predicate programming
== Series Details ==
Series: Handle predicate programming
URL : https://patchwork.freedesktop.org/series/103084/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11550_full -> Patchwork_103084v1_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_103084v1_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_103084v1_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (10 -> 12)
--
Additional (2): shard-rkl shard-tglu
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_103084v1_full:
### IGT changes ###
Possible regressions
* igt@i915_selftest@perf@region:
- shard-tglb: [PASS][1] -> [DMESG-WARN][2] +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-tglb7/igt@i915_selftest@p...@region.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103084v1/shard-tglb5/igt@i915_selftest@p...@region.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_ctx_shared@q-smoketest@rcs0:
- {shard-rkl}:NOTRUN -> [INCOMPLETE][3] +2 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103084v1/shard-rkl-5/igt@gem_ctx_shared@q-smoket...@rcs0.html
Known issues
Here are the changes found in Patchwork_103084v1_full that come from known
issues:
### CI changes ###
Issues hit
* boot:
- shard-apl: ([PASS][4], [PASS][5], [PASS][6], [PASS][7],
[PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13],
[PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19],
[PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25],
[PASS][26], [PASS][27], [PASS][28]) -> ([FAIL][29], [PASS][30], [PASS][31],
[PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37],
[PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43],
[PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49],
[PASS][50], [PASS][51], [PASS][52], [PASS][53]) ([i915#4386])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-apl3/boot.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-apl4/boot.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-apl4/boot.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-apl3/boot.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-apl4/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-apl4/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-apl6/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-apl6/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-apl6/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-apl3/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-apl7/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-apl3/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-apl2/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-apl2/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-apl7/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-apl2/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-apl7/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-apl7/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-apl8/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-apl8/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-apl2/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-apl8/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-apl1/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-apl1/boot.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-apl1/boot.html
[29]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103084v1/shard-apl1/boot.html
[30]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103084v1/shard-apl1/boot.html
[31]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103084v1/shard-apl1/boot.html
[32]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103084v1/shard-apl1/boot.html
[33]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: ttm for stolen region (rev6)
== Series Details == Series: drm/i915: ttm for stolen region (rev6) URL : https://patchwork.freedesktop.org/series/102540/ 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] [3/4] drm/i915/huc: Prepare for GSC-loaded HuC
Reviewed-by: Alan Previn
On Tue, 2022-04-26 at 17:26 -0700, Daniele Ceraolo Spurio wrote:
> HuC loading via GSC is performed via a PXP command sent through the mei
> modules, so we need both MEI_GSC and MEI_PXP to be available. Given that
> the GSC will do both the transfer and the authentication, the legacy HuC
> loading paths can be safely skipped.
> Also note that the GSC-loaded HuC survives GT reset.
>
> Signed-off-by: Daniele Ceraolo Spurio
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h | 1 +
> drivers/gpu/drm/i915/gt/uc/intel_huc.c | 76 +++---
> drivers/gpu/drm/i915/gt/uc/intel_huc.h | 6 ++
> drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 5 +-
> drivers/gpu/drm/i915/gt/uc/intel_uc.c | 11 +++-
> 5 files changed, 88 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h
> index 66027a42cda9e..2516705b9f365 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h
> @@ -96,6 +96,7 @@
>
> #define GUC_SHIM_CONTROL2_MMIO(0xc068)
> #define GUC_IS_PRIVILEGED (1<<29)
> +#define GSC_LOADS_HUC (1<<30)
>
> #define GUC_SEND_INTERRUPT _MMIO(0xc4c8)
> #define GUC_SEND_TRIGGER (1<<0)
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
> b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
> index 773020e69589a..76a7df7f136fc 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
> @@ -6,6 +6,7 @@
> #include
>
> #include "gt/intel_gt.h"
> +#include "intel_guc_reg.h"
> #include "intel_huc.h"
> #include "i915_drv.h"
>
> @@ -17,11 +18,15 @@
> * capabilities by adding HuC specific commands to batch buffers.
> *
> * The kernel driver is only responsible for loading the HuC firmware and
> - * triggering its security authentication, which is performed by the GuC. For
> - * The GuC to correctly perform the authentication, the HuC binary must be
> - * loaded before the GuC one. Loading the HuC is optional; however, not using
> - * the HuC might negatively impact power usage and/or performance of media
> - * workloads, depending on the use-cases.
> + * triggering its security authentication, which is performed by the GuC on
> + * older platforms and by the GSC on newer ones. For the GuC to correctly
> + * perform the authentication, the HuC binary must be loaded before the GuC
> one.
> + * Loading the HuC is optional; however, not using the HuC might negatively
> + * impact power usage and/or performance of media workloads, depending on the
> + * use-cases.
> + * HuC must be reloaded on events that cause the WOPCM to lose its contents
> + * (S3/S4, FLR); GuC-authenticated HuC must also be reloaded on GuC/GT reset,
> + * while GSC-managed HuC will survive that.
> *
> * See https://github.com/intel/media-driver for the latest details on HuC
> * functionality.
> @@ -54,11 +59,51 @@ void intel_huc_init_early(struct intel_huc *huc)
> }
> }
>
> +#define HUC_LOAD_MODE_STRING(x) (x ? "GSC" : "legacy")
> +static int check_huc_loading_mode(struct intel_huc *huc)
> +{
> + struct intel_gt *gt = huc_to_gt(huc);
> + bool fw_needs_gsc = intel_huc_is_loaded_by_gsc(huc);
> + bool hw_uses_gsc = false;
> +
> + /*
> + * The fuse for HuC load via GSC is only valid on platforms that have
> + * GuC deprivilege.
> + */
> + if (HAS_GUC_DEPRIVILEGE(gt->i915))
> + hw_uses_gsc = intel_uncore_read(gt->uncore, GUC_SHIM_CONTROL2) &
> + GSC_LOADS_HUC;
> +
> + if (fw_needs_gsc != hw_uses_gsc) {
> + drm_err(>i915->drm,
> + "mismatch between HuC FW (%s) and HW (%s) load modes\n",
> + HUC_LOAD_MODE_STRING(fw_needs_gsc),
> + HUC_LOAD_MODE_STRING(hw_uses_gsc));
> + return -ENOEXEC;
> + }
> +
> + /* make sure we can access the GSC via the mei driver if we need it */
> + if (!(IS_ENABLED(CONFIG_INTEL_MEI_PXP) &&
> IS_ENABLED(CONFIG_INTEL_MEI_GSC)) &&
> + fw_needs_gsc) {
> + drm_info(>i915->drm,
> + "Can't load HuC due to missing MEI modules\n");
> + return -EIO;
> + }
> +
> + drm_dbg(>i915->drm, "GSC loads huc=%s\n", str_yes_no(fw_needs_gsc));
> +
> + return 0;
> +}
> +
> int intel_huc_init(struct intel_huc *huc)
> {
> struct drm_i915_private *i915 = huc_to_gt(huc)->i915;
> int err;
>
> + err = check_huc_loading_mode(huc);
> + if (err)
> + goto out;
> +
> err = intel_uc_fw_init(>fw);
> if (err)
> goto out;
> @@ -108,17 +153,20 @@ int intel_huc_auth(struct intel_huc *huc)
> struct intel_guc *guc = >uc.guc;
> int ret;
>
> - GEM_BUG_ON(huc_is_authenticated(huc));
> -
> if (!intel_uc_fw_is_loaded(>fw))
> return
[Intel-gfx] ✗ Fi.CI.BAT: failure for lrc selftest fixes (rev5)
== Series Details == Series: lrc selftest fixes (rev5) URL : https://patchwork.freedesktop.org/series/101353/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11582 -> Patchwork_101353v5 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_101353v5 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_101353v5, 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_101353v5/index.html Participating hosts (43 -> 41) -- Additional (1): fi-rkl-11600 Missing(3): fi-bsw-cyan fi-hsw-4770 fi-icl-u2 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_101353v5: ### IGT changes ### Possible regressions * igt@i915_selftest@live@gt_lrc: - fi-bsw-n3050: [PASS][1] -> [DMESG-FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11582/fi-bsw-n3050/igt@i915_selftest@live@gt_lrc.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v5/fi-bsw-n3050/igt@i915_selftest@live@gt_lrc.html - fi-bsw-kefka: [PASS][3] -> [DMESG-FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11582/fi-bsw-kefka/igt@i915_selftest@live@gt_lrc.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v5/fi-bsw-kefka/igt@i915_selftest@live@gt_lrc.html - fi-bdw-gvtdvm: [PASS][5] -> [DMESG-FAIL][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11582/fi-bdw-gvtdvm/igt@i915_selftest@live@gt_lrc.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v5/fi-bdw-gvtdvm/igt@i915_selftest@live@gt_lrc.html - fi-bsw-nick:[PASS][7] -> [DMESG-FAIL][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11582/fi-bsw-nick/igt@i915_selftest@live@gt_lrc.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v5/fi-bsw-nick/igt@i915_selftest@live@gt_lrc.html - fi-bdw-5557u: [PASS][9] -> [DMESG-FAIL][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11582/fi-bdw-5557u/igt@i915_selftest@live@gt_lrc.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v5/fi-bdw-5557u/igt@i915_selftest@live@gt_lrc.html * igt@i915_selftest@live@memory_region: - fi-cfl-8109u: [PASS][11] -> [DMESG-WARN][12] +11 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11582/fi-cfl-8109u/igt@i915_selftest@live@memory_region.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v5/fi-cfl-8109u/igt@i915_selftest@live@memory_region.html Known issues Here are the changes found in Patchwork_101353v5 that come from known issues: ### IGT changes ### Issues hit * igt@gem_huc_copy@huc-copy: - fi-rkl-11600: NOTRUN -> [SKIP][13] ([i915#2190]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v5/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-rkl-11600: NOTRUN -> [SKIP][14] ([i915#4613]) +3 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v5/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html * igt@gem_tiled_pread_basic: - fi-rkl-11600: NOTRUN -> [SKIP][15] ([i915#3282]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v5/fi-rkl-11600/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - fi-rkl-11600: NOTRUN -> [SKIP][16] ([i915#3012]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v5/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html * igt@i915_pm_rpm@module-reload: - fi-cfl-8109u: [PASS][17] -> [DMESG-FAIL][18] ([i915#62]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11582/fi-cfl-8109u/igt@i915_pm_...@module-reload.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v5/fi-cfl-8109u/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live@hangcheck: - fi-bdw-5557u: NOTRUN -> [INCOMPLETE][19] ([i915#3921]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v5/fi-bdw-5557u/igt@i915_selftest@l...@hangcheck.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-snb-2600:NOTRUN -> [SKIP][20] ([fdo#109271] / [fdo#111827]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v5/fi-snb-2600/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_chamelium@dp-crc-fast: - fi-rkl-11600: NOTRUN -> [SKIP][21] ([fdo#111827]) +8 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v5/fi-rkl-11600/igt@kms_chamel...@dp-crc-fast.html *
Re: [Intel-gfx] [2/4] drm/i915/huc: Add fetch support for gsc-loaded HuC binary
minor nit: not sure if its worth mentioning in commit msg that "loaded_via_gsc"
is zero-init-ed as fw_def macros we havent added fw_defs for gsc-loaded-huc-bins
which explains why "loaded_via_gsc" not getting set anywhere in this series.
Reviewed-by: Alan Previn
On Tue, 2022-04-26 at 17:26 -0700, Daniele Ceraolo Spurio wrote:
> On newer platforms (starting DG2 G10 B-step and G11 A-step), ownership of
> HuC loading has been moved from the GuC to the GSC. As part of the
> change, the header format of the HuC binary has been updated and does not
> match the GuC anymore. The GSC will perform all the required checks on
> the binary size, so we only need to check that the version matches.
>
> Signed-off-by: Daniele Ceraolo Spurio
> ---
> drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 99
> drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 +
> drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h | 9 ++
> 3 files changed, 72 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> index cb5dd16421d0d..8d602d87a7295 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> @@ -301,45 +301,31 @@ static void __force_fw_fetch_failures(struct
> intel_uc_fw *uc_fw, int e)
> }
> }
>
> -/**
> - * intel_uc_fw_fetch - fetch uC firmware
> - * @uc_fw: uC firmware
> - *
> - * Fetch uC firmware into GEM obj.
> - *
> - * Return: 0 on success, a negative errno code on failure.
> - */
> -int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
> +static int check_gsc_manifest(const struct firmware *fw,
> + struct intel_uc_fw *uc_fw)
> {
> - struct drm_i915_private *i915 = __uc_fw_to_gt(uc_fw)->i915;
> - struct device *dev = i915->drm.dev;
> - struct drm_i915_gem_object *obj;
> - const struct firmware *fw = NULL;
> - struct uc_css_header *css;
> - size_t size;
> - int err;
> + u32 *dw = (u32 *)fw->data;
> + u32 version = dw[HUC_GSC_VERSION_DW];
>
> - GEM_BUG_ON(!i915->wopcm.size);
> - GEM_BUG_ON(!intel_uc_fw_is_enabled(uc_fw));
> -
> - err = i915_inject_probe_error(i915, -ENXIO);
> - if (err)
> - goto fail;
> + uc_fw->major_ver_found = FIELD_GET(HUC_GSC_MAJOR_VER_MASK, version);
> + uc_fw->minor_ver_found = FIELD_GET(HUC_GSC_MINOR_VER_MASK, version);
>
> - __force_fw_fetch_failures(uc_fw, -EINVAL);
> - __force_fw_fetch_failures(uc_fw, -ESTALE);
> + return 0;
> +}
>
> - err = request_firmware(, uc_fw->path, dev);
> - if (err)
> - goto fail;
> +static int check_ccs_header(struct drm_i915_private *i915,
> + const struct firmware *fw,
> + struct intel_uc_fw *uc_fw)
> +{
> + struct uc_css_header *css;
> + size_t size;
>
> /* Check the size of the blob before examining buffer contents */
> if (unlikely(fw->size < sizeof(struct uc_css_header))) {
> drm_warn(>drm, "%s firmware %s: invalid size: %zu <
> %zu\n",
>intel_uc_fw_type_repr(uc_fw->type), uc_fw->path,
>fw->size, sizeof(struct uc_css_header));
> - err = -ENODATA;
> - goto fail;
> + return -ENODATA;
> }
>
> css = (struct uc_css_header *)fw->data;
> @@ -352,8 +338,7 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
>"%s firmware %s: unexpected header size: %zu != %zu\n",
>intel_uc_fw_type_repr(uc_fw->type), uc_fw->path,
>fw->size, sizeof(struct uc_css_header));
> - err = -EPROTO;
> - goto fail;
> + return -EPROTO;
> }
>
> /* uCode size must calculated from other sizes */
> @@ -368,8 +353,7 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
> drm_warn(>drm, "%s firmware %s: invalid size: %zu <
> %zu\n",
>intel_uc_fw_type_repr(uc_fw->type), uc_fw->path,
>fw->size, size);
> - err = -ENOEXEC;
> - goto fail;
> + return -ENOEXEC;
> }
>
> /* Sanity check whether this fw is not larger than whole WOPCM memory */
> @@ -378,8 +362,7 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
> drm_warn(>drm, "%s firmware %s: invalid size: %zu >
> %zu\n",
>intel_uc_fw_type_repr(uc_fw->type), uc_fw->path,
>size, (size_t)i915->wopcm.size);
> - err = -E2BIG;
> - goto fail;
> + return -E2BIG;
> }
>
> /* Get version numbers from the CSS header */
> @@ -388,6 +371,49 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
> uc_fw->minor_ver_found = FIELD_GET(CSS_SW_VERSION_UC_MINOR,
> css->sw_version);
>
> + if (uc_fw->type == INTEL_UC_FW_TYPE_GUC)
>
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: move tons of power well initializers to rodata
== Series Details ==
Series: drm/i915: move tons of power well initializers to rodata
URL : https://patchwork.freedesktop.org/series/103340/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11582_full -> Patchwork_103340v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (13 -> 13)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_103340v1_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_parallel@basic@vcs0:
- {shard-rkl}:[PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11582/shard-rkl-2/igt@gem_exec_parallel@ba...@vcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103340v1/shard-rkl-5/igt@gem_exec_parallel@ba...@vcs0.html
* igt@i915_selftest@live@gem_contexts:
- {shard-rkl}:NOTRUN -> [INCOMPLETE][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103340v1/shard-rkl-5/igt@i915_selftest@live@gem_contexts.html
* igt@i915_suspend@sysfs-reader:
- {shard-dg1}:NOTRUN -> [INCOMPLETE][4] +1 similar issue
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103340v1/shard-dg1-17/igt@i915_susp...@sysfs-reader.html
Known issues
Here are the changes found in Patchwork_103340v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ccs@block-copy-compressed:
- shard-iclb: NOTRUN -> [SKIP][5] ([i915#5327])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103340v1/shard-iclb3/igt@gem_...@block-copy-compressed.html
* igt@gem_exec_fair@basic-none@vcs1:
- shard-kbl: [PASS][6] -> [FAIL][7] ([i915#2842])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11582/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs1.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103340v1/shard-kbl7/igt@gem_exec_fair@basic-n...@vcs1.html
* igt@gem_exec_fair@basic-pace@vecs0:
- shard-glk: [PASS][8] -> [FAIL][9] ([i915#2842])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11582/shard-glk8/igt@gem_exec_fair@basic-p...@vecs0.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103340v1/shard-glk7/igt@gem_exec_fair@basic-p...@vecs0.html
* igt@gem_exec_flush@basic-wb-rw-default:
- shard-snb: [PASS][10] -> [SKIP][11] ([fdo#109271]) +4 similar
issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11582/shard-snb7/igt@gem_exec_fl...@basic-wb-rw-default.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103340v1/shard-snb6/igt@gem_exec_fl...@basic-wb-rw-default.html
* igt@gem_exec_gttfill@basic:
- shard-skl: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#1888])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103340v1/shard-skl4/igt@gem_exec_gttf...@basic.html
* igt@gem_huc_copy@huc-copy:
- shard-iclb: NOTRUN -> [SKIP][13] ([i915#2190])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103340v1/shard-iclb5/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@heavy-random:
- shard-apl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#4613])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103340v1/shard-apl4/igt@gem_lmem_swapp...@heavy-random.html
* igt@gem_lmem_swapping@heavy-verify-random:
- shard-skl: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#4613]) +1
similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103340v1/shard-skl4/igt@gem_lmem_swapp...@heavy-verify-random.html
* igt@gem_lmem_swapping@parallel-random:
- shard-kbl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#4613])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103340v1/shard-kbl7/igt@gem_lmem_swapp...@parallel-random.html
* igt@gem_lmem_swapping@parallel-random-verify:
- shard-iclb: NOTRUN -> [SKIP][17] ([i915#4613])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103340v1/shard-iclb3/igt@gem_lmem_swapp...@parallel-random-verify.html
* igt@gem_lmem_swapping@random-engines:
- shard-glk: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#4613])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103340v1/shard-glk2/igt@gem_lmem_swapp...@random-engines.html
* igt@gem_pxp@verify-pxp-stale-ctx-execution:
- shard-iclb: NOTRUN -> [SKIP][19] ([i915#4270])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103340v1/shard-iclb5/igt@gem_...@verify-pxp-stale-ctx-execution.html
* igt@gem_userptr_blits@dmabuf-sync:
- shard-glk: NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#3323])
[20]:
[Intel-gfx] ✓ Fi.CI.BAT: success for Handle predicate programming
== Series Details ==
Series: Handle predicate programming
URL : https://patchwork.freedesktop.org/series/103084/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11550 -> Patchwork_103084v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103084v1/index.html
Participating hosts (43 -> 42)
--
Additional (2): bat-dg2-8 bat-dg1-6
Missing(3): fi-kbl-soraka fi-hsw-4770 fi-bsw-cyan
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_103084v1:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_pm_rpm@module-reload:
- {bat-rpls-2}: [DMESG-WARN][1] ([i915#4391]) -> [WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/bat-rpls-2/igt@i915_pm_...@module-reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103084v1/bat-rpls-2/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@client:
- {bat-dg2-8}:NOTRUN -> [DMESG-FAIL][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103084v1/bat-dg2-8/igt@i915_selftest@l...@client.html
Known issues
Here are the changes found in Patchwork_103084v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s0@smem:
- bat-dg1-6: NOTRUN -> [INCOMPLETE][4] ([i915#5827])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103084v1/bat-dg1-6/igt@gem_exec_suspend@basic...@smem.html
* igt@gem_exec_suspend@basic-s3@smem:
- fi-bdw-5557u: [PASS][5] -> [INCOMPLETE][6] ([i915#146])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103084v1/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
Possible fixes
* igt@i915_selftest@live@gt_heartbeat:
- fi-cfl-guc: [DMESG-FAIL][7] ([i915#5334]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-cfl-guc/igt@i915_selftest@live@gt_heartbeat.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103084v1/fi-cfl-guc/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@gt_lrc:
- {bat-dg2-9}:[INCOMPLETE][9] ([i915#5270]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/bat-dg2-9/igt@i915_selftest@live@gt_lrc.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103084v1/bat-dg2-9/igt@i915_selftest@live@gt_lrc.html
* igt@i915_selftest@live@sanitycheck:
- {bat-rpls-2}: [INCOMPLETE][11] ([i915#5401]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/bat-rpls-2/igt@i915_selftest@l...@sanitycheck.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103084v1/bat-rpls-2/igt@i915_selftest@l...@sanitycheck.html
* igt@kms_busy@basic@flip:
- {bat-adlp-6}: [DMESG-WARN][13] ([i915#3576]) -> [PASS][14] +1
similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/bat-adlp-6/igt@kms_busy@ba...@flip.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103084v1/bat-adlp-6/igt@kms_busy@ba...@flip.html
Warnings
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-kbl-7567u: [SKIP][15] ([fdo#109271] / [i915#5341]) -> [SKIP][16]
([fdo#109271])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-kbl-7567u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103084v1/fi-kbl-7567u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
- fi-pnv-d510:[SKIP][17] ([fdo#109271] / [i915#5341]) -> [SKIP][18]
([fdo#109271])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-pnv-d510/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103084v1/fi-pnv-d510/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
- fi-snb-2520m: [SKIP][19] ([fdo#109271] / [i915#5341]) -> [SKIP][20]
([fdo#109271])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-snb-2520m/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103084v1/fi-snb-2520m/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
- fi-bsw-kefka: [SKIP][21] ([fdo#109271] / [i915#5341]) -> [SKIP][22]
([fdo#109271])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-bsw-kefka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
[22]:
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Change semantics of context isolation reporting to UM (rev2)
== Series Details == Series: drm/i915: Change semantics of context isolation reporting to UM (rev2) URL : https://patchwork.freedesktop.org/series/103343/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11582 -> Patchwork_103343v2 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_103343v2 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_103343v2, 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_103343v2/index.html Participating hosts (43 -> 44) -- Additional (2): bat-rpls-1 fi-rkl-11600 Missing(1): fi-bsw-cyan Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_103343v2: ### IGT changes ### Possible regressions * igt@i915_selftest@live@gt_lrc: - fi-tgl-1115g4: [PASS][1] -> [DMESG-FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11582/fi-tgl-1115g4/igt@i915_selftest@live@gt_lrc.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103343v2/fi-tgl-1115g4/igt@i915_selftest@live@gt_lrc.html Known issues Here are the changes found in Patchwork_103343v2 that come from known issues: ### IGT changes ### Issues hit * igt@gem_huc_copy@huc-copy: - fi-rkl-11600: NOTRUN -> [SKIP][3] ([i915#2190]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103343v2/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-rkl-11600: NOTRUN -> [SKIP][4] ([i915#4613]) +3 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103343v2/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html * igt@gem_tiled_pread_basic: - fi-rkl-11600: NOTRUN -> [SKIP][5] ([i915#3282]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103343v2/fi-rkl-11600/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - fi-rkl-11600: NOTRUN -> [SKIP][6] ([i915#3012]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103343v2/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html * igt@i915_selftest@live@gt_lrc: - fi-rkl-guc: [PASS][7] -> [INCOMPLETE][8] ([i915#4983]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11582/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103343v2/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html * igt@i915_selftest@live@hangcheck: - fi-hsw-4770:[PASS][9] -> [INCOMPLETE][10] ([i915#4785]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11582/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103343v2/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html - fi-bdw-5557u: NOTRUN -> [INCOMPLETE][11] ([i915#3921]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103343v2/fi-bdw-5557u/igt@i915_selftest@l...@hangcheck.html * igt@i915_selftest@live@late_gt_pm: - fi-bsw-n3050: [PASS][12] -> [DMESG-FAIL][13] ([i915#3428]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11582/fi-bsw-n3050/igt@i915_selftest@live@late_gt_pm.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103343v2/fi-bsw-n3050/igt@i915_selftest@live@late_gt_pm.html * igt@kms_chamelium@dp-crc-fast: - fi-rkl-11600: NOTRUN -> [SKIP][14] ([fdo#111827]) +8 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103343v2/fi-rkl-11600/igt@kms_chamel...@dp-crc-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-rkl-11600: NOTRUN -> [SKIP][15] ([i915#4070] / [i915#4103]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103343v2/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_force_connector_basic@force-load-detect: - fi-rkl-11600: NOTRUN -> [SKIP][16] ([fdo#109285] / [i915#4098]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103343v2/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-rkl-11600: NOTRUN -> [SKIP][17] ([i915#4070] / [i915#533]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103343v2/fi-rkl-11600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html * igt@kms_psr@primary_mmap_gtt: - fi-rkl-11600: NOTRUN -> [SKIP][18] ([i915#1072]) +3 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103343v2/fi-rkl-11600/igt@kms_psr@primary_mmap_gtt.html * igt@kms_setmode@basic-clone-single-crtc: -
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for lrc selftest fixes (rev5)
== Series Details == Series: lrc selftest fixes (rev5) URL : https://patchwork.freedesktop.org/series/101353/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/gt/intel_engine_stats.h:28:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:28:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:28:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:33:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:33:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:51:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:51:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:51:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:57:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:57:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_reset.c:1391:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +./include/linux/find.h:40:31: warning: shift count is negative (-24) +./include/linux/find.h:40:31: warning: shift count is negative (-24) +./include/linux/find.h:40:31: warning: shift count is negative (-24) +./include/linux/find.h:40:31: warning: shift count is negative (-24) +./include/linux/find.h:40:31: warning: shift count is negative (-448) +./include/linux/find.h:40:31: warning: shift count is negative (-448) +./include/linux/spinlock.h:404:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:404:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:404:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:404:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:404:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:404:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:404:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:404:9: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block +./include/linux/spinlock.h:404:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block +./include/linux/spinlock.h:404:9: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block
Re: [Intel-gfx] [PATCH] drm/i915: move tons of power well initializers to rodata
On Fri, Apr 29, 2022 at 05:21:40PM +0300, Jani Nikula wrote:
> Using compound literals for initialization can be tricky. Lacking a
> const qualifier, they won't end up in rodata, which is probably not
> expected or intended. Add const to move a whopping 136 initializers to
> rodata.
>
> Compare:
>
> $ objdump --syms drivers/gpu/drm/i915/display/intel_display_power_map.o |
> grep "\.rodata.*__compound_literal"
> $ objdump --syms drivers/gpu/drm/i915/display/intel_display_power_map.o |
> grep "\.data.*__compound_literal"
>
> Before and after the change.
>
> Fixes: c32ffce42aa5 ("drm/i915: Convert the power well descriptor domain mask
> to an array of domains")
> Fixes: 4a845ff0c0d4 ("drm/i915: Simplify power well definitions by adding
> power well instances")
> Cc: Imre Deak
> Cc: Jouni Högander
> Signed-off-by: Jani Nikula
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_display_power_map.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power_map.c
> b/drivers/gpu/drm/i915/display/intel_display_power_map.c
> index af6f54a26a35..97b367f39f35 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power_map.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power_map.c
> @@ -21,7 +21,7 @@
>
> #define I915_PW_DOMAINS(...) \
> (const struct i915_power_domain_list) \
> - __LIST(__LIST_INLINE_ELEMS(enum intel_display_power_domain,
> __VA_ARGS__))
> + __LIST(__LIST_INLINE_ELEMS(const enum
> intel_display_power_domain, __VA_ARGS__))
>
> #define I915_DECL_PW_DOMAINS(__name, ...) \
> static const struct i915_power_domain_list __name =
> I915_PW_DOMAINS(__VA_ARGS__)
> @@ -32,7 +32,7 @@
>
> #define I915_PW_INSTANCES(...) \
> (const struct i915_power_well_instance_list) \
> - __LIST(__LIST_INLINE_ELEMS(struct i915_power_well_instance,
> __VA_ARGS__))
> + __LIST(__LIST_INLINE_ELEMS(const struct
> i915_power_well_instance, __VA_ARGS__))
>
> #define I915_PW(_name, _domain_list, ...) \
> { .name = _name, .domain_list = _domain_list, ## __VA_ARGS__ }
> --
> 2.30.2
>
[Intel-gfx] [PATCH v3 4/4] drm/i915/selftest: Clear the output buffers before GPU writes
From: Chris Wilson
When testing whether we can get the GPU to leak information about
non-privileged state, we first need to ensure that the output buffer is
set to a known value as the HW may opt to skip the write into memory for
a non-privileged read of a sensitive register. We chose POISON_INUSE (0x5a)
so that is both non-zero and distinct from the poison values used during
the test.
v2:
Use i915_gem_object_pin_map_unlocked
Reported-by: CQ Tang
Signed-off-by: Chris Wilson
Cc: CQ Tang
cc: Joonas Lahtinen
Signed-off-by: Ramalingam C
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 32 ++
1 file changed, 28 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 51e4b7092d4f..9c8e8321c633 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -1346,6 +1346,30 @@ static int compare_isolation(struct intel_engine_cs
*engine,
return err;
}
+static struct i915_vma *
+create_result_vma(struct i915_address_space *vm, unsigned long sz)
+{
+ struct i915_vma *vma;
+ void *ptr;
+
+ vma = create_user_vma(vm, sz);
+ if (IS_ERR(vma))
+ return vma;
+
+ /* Set the results to a known value distinct from the poison */
+ ptr = i915_gem_object_pin_map_unlocked(vma->obj, I915_MAP_WC);
+ if (IS_ERR(ptr)) {
+ i915_vma_put(vma);
+ return ERR_CAST(ptr);
+ }
+
+ memset(ptr, POISON_INUSE, vma->size);
+ i915_gem_object_flush_map(vma->obj);
+ i915_gem_object_unpin_map(vma->obj);
+
+ return vma;
+}
+
static int __lrc_isolation(struct intel_engine_cs *engine, u32 poison)
{
u32 *sema = memset32(engine->status_page.addr + 1000, 0, 1);
@@ -1364,13 +1388,13 @@ static int __lrc_isolation(struct intel_engine_cs
*engine, u32 poison)
goto err_A;
}
- ref[0] = create_user_vma(A->vm, SZ_64K);
+ ref[0] = create_result_vma(A->vm, SZ_64K);
if (IS_ERR(ref[0])) {
err = PTR_ERR(ref[0]);
goto err_B;
}
- ref[1] = create_user_vma(A->vm, SZ_64K);
+ ref[1] = create_result_vma(A->vm, SZ_64K);
if (IS_ERR(ref[1])) {
err = PTR_ERR(ref[1]);
goto err_ref0;
@@ -1392,13 +1416,13 @@ static int __lrc_isolation(struct intel_engine_cs
*engine, u32 poison)
}
i915_request_put(rq);
- result[0] = create_user_vma(A->vm, SZ_64K);
+ result[0] = create_result_vma(A->vm, SZ_64K);
if (IS_ERR(result[0])) {
err = PTR_ERR(result[0]);
goto err_ref1;
}
- result[1] = create_user_vma(A->vm, SZ_64K);
+ result[1] = create_result_vma(A->vm, SZ_64K);
if (IS_ERR(result[1])) {
err = PTR_ERR(result[1]);
goto err_result0;
--
2.20.1
[Intel-gfx] [PATCH v3 3/4] drm/i915/selftest: Always cancel semaphore on error
From: Chris Wilson
Ensure that we always signal the semaphore when timing out, so that if it
happens to be stuck waiting for the semaphore we will quickly recover
without having to wait for a reset.
Reported-by: CQ Tang
Signed-off-by: Chris Wilson
Cc: CQ Tang
cc: Joonas Lahtinen
Signed-off-by: Ramalingam C
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 684a63de156a..51e4b7092d4f 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -1411,18 +1411,17 @@ static int __lrc_isolation(struct intel_engine_cs
*engine, u32 poison)
}
err = poison_registers(B, poison, sema);
- if (err) {
- WRITE_ONCE(*sema, -1);
- i915_request_put(rq);
- goto err_result1;
- }
-
- if (i915_request_wait(rq, 0, HZ / 2) < 0) {
- i915_request_put(rq);
+ if (err == 0 && i915_request_wait(rq, 0, HZ / 2) < 0) {
+ pr_err("%s(%s): wait for results timed out\n",
+ __func__, engine->name);
err = -ETIME;
- goto err_result1;
}
+
+ /* Always cancel the semaphore wait, just in case the GPU gets stuck */
+ WRITE_ONCE(*sema, -1);
i915_request_put(rq);
+ if (err)
+ goto err_result1;
err = compare_isolation(engine, ref, result, A, poison);
--
2.20.1
[Intel-gfx] [PATCH v3 2/4] drm/i915/selftests: Check for incomplete LRI from the context image
From: Chris Wilson
In order to keep the context image parser simple, we assume that all
commands follow a similar format. A few, especially not MI commands on
the render engines, have fixed lengths not encoded in a length field.
This caused us to incorrectly skip over 3D state commands, and start
interpreting context data as instructions. Eventually, as Daniele
discovered, this would lead us to find addition LRI as part of the data
and mistakenly add invalid LRI commands to the context probes.
Stop parsing after we see the first !MI command, as we know we will have
seen all the context registers by that point. (Mostly true for all gen
so far, though the render context does have LRI after the first page
that we have been ignoring so far. It would be useful to extract those
as well so that we have the full list of user accessible registers.)
Similarly, emit a warning if we do try to emit an invalid zero-length
LRI.
Reported-by: Daniele Ceraolo Spurio
Signed-off-by: Chris Wilson
Cc: Daniele Ceraolo Spurio
Signed-off-by: Ramalingam C
Acked-by: Thomas Hellstrom
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 61 +++---
1 file changed, 54 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 33f22f17e358..684a63de156a 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -27,6 +27,9 @@
#define NUM_GPR 16
#define NUM_GPR_DW (NUM_GPR * 2) /* each GPR is 2 dwords */
+#define LRI_HEADER MI_INSTR(0x22, 0)
+#define LRI_LENGTH_MASK GENMASK(7, 0)
+
static struct i915_vma *create_scratch(struct intel_gt *gt)
{
return __vm_create_scratch_for_read_pinned(>ggtt->vm, PAGE_SIZE);
@@ -180,7 +183,7 @@ static int live_lrc_layout(void *arg)
continue;
}
- if ((lri & GENMASK(31, 23)) != MI_INSTR(0x22, 0)) {
+ if ((lri & GENMASK(31, 23)) != LRI_HEADER) {
pr_err("%s: Expected LRI command at dword %d,
found %08x\n",
engine->name, dw, lri);
err = -EINVAL;
@@ -945,18 +948,40 @@ store_context(struct intel_context *ce, struct i915_vma
*scratch)
hw = defaults;
hw += LRC_STATE_OFFSET / sizeof(*hw);
do {
- u32 len = hw[dw] & 0x7f;
+ u32 len = hw[dw] & LRI_LENGTH_MASK;
+
+ /*
+* Keep it simple, skip parsing complex commands
+*
+* At present, there are no more MI_LOAD_REGISTER_IMM
+* commands after the first 3D state command. Rather
+* than include a table (see i915_cmd_parser.c) of all
+* the possible commands and their instruction lengths
+* (or mask for variable length instructions), assume
+* we have gathered the complete list of registers and
+* bail out.
+*/
+ if ((hw[dw] >> INSTR_CLIENT_SHIFT) != INSTR_MI_CLIENT)
+ break;
if (hw[dw] == 0) {
dw++;
continue;
}
- if ((hw[dw] & GENMASK(31, 23)) != MI_INSTR(0x22, 0)) {
+ if ((hw[dw] & GENMASK(31, 23)) != LRI_HEADER) {
+ /* Assume all other MI commands match LRI length mask */
dw += len + 2;
continue;
}
+ if (!len) {
+ pr_err("%s: invalid LRI found in context image\n",
+ ce->engine->name);
+ igt_hexdump(defaults, PAGE_SIZE);
+ break;
+ }
+
dw++;
len = (len + 1) / 2;
while (len--) {
@@ -1108,18 +1133,29 @@ static struct i915_vma *load_context(struct
intel_context *ce, u32 poison)
hw = defaults;
hw += LRC_STATE_OFFSET / sizeof(*hw);
do {
- u32 len = hw[dw] & 0x7f;
+ u32 len = hw[dw] & LRI_LENGTH_MASK;
+
+ /* For simplicity, break parsing at the first complex command */
+ if ((hw[dw] >> INSTR_CLIENT_SHIFT) != INSTR_MI_CLIENT)
+ break;
if (hw[dw] == 0) {
dw++;
continue;
}
- if ((hw[dw] & GENMASK(31, 23)) != MI_INSTR(0x22, 0)) {
+ if ((hw[dw] & GENMASK(31, 23)) != LRI_HEADER) {
dw += len + 2;
continue;
}
+ if (!len) {
+ pr_err("%s: invalid LRI found in context image\n",
+ ce->engine->name);
+ igt_hexdump(defaults, PAGE_SIZE);
+
[Intel-gfx] [PATCH v3 1/4] drm/i915/gt: Explicitly clear BB_OFFSET for new contexts
From: Chris Wilson
Even though the initial protocontext we load onto HW has the register
cleared, by the time we save it into the default image, BB_OFFSET has
had the enable bit set. Reclear BB_OFFSET for each new context.
Testcase: igt/i915_selftests/gt_lrc
v2:
Extend it for gen8.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Signed-off-by: Ramalingam C
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/i915/gt/intel_engine_regs.h | 1 +
drivers/gpu/drm/i915/gt/intel_lrc.c | 19 +++
drivers/gpu/drm/i915/gt/selftest_lrc.c | 5 +
3 files changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
index 594a629cb28f..d4b02d36d2a6 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
@@ -109,6 +109,7 @@
#define RING_SBBSTATE(base)_MMIO((base) + 0x118) /* hsw+ */
#define RING_SBBADDR_UDW(base) _MMIO((base) + 0x11c) /* gen8+
*/
#define RING_BBADDR(base) _MMIO((base) + 0x140)
+#define RING_BB_OFFSET(base) _MMIO((base) + 0x158)
#define RING_BBADDR_UDW(base) _MMIO((base) + 0x168) /* gen8+
*/
#define CCID(base) _MMIO((base) + 0x180)
#define CCID_EN BIT(0)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 3f83a9038e13..5f6479dadea7 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -662,6 +662,20 @@ static int lrc_ring_mi_mode(const struct intel_engine_cs
*engine)
return -1;
}
+static int lrc_ring_bb_offset(const struct intel_engine_cs *engine)
+{
+ if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 50))
+ return 0x80;
+ else if (GRAPHICS_VER(engine->i915) >= 12)
+ return 0x70;
+ else if (GRAPHICS_VER(engine->i915) >= 9)
+ return 0x64;
+ else if (GRAPHICS_VER(engine->i915) >= 8)
+ return 0xc4;
+ else
+ return -1;
+}
+
static int lrc_ring_gpr0(const struct intel_engine_cs *engine)
{
if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 50))
@@ -768,6 +782,7 @@ static void init_common_regs(u32 * const regs,
bool inhibit)
{
u32 ctl;
+ int loc;
ctl = _MASKED_BIT_ENABLE(CTX_CTRL_INHIBIT_SYN_CTX_SWITCH);
ctl |= _MASKED_BIT_DISABLE(CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT);
@@ -779,6 +794,10 @@ static void init_common_regs(u32 * const regs,
regs[CTX_CONTEXT_CONTROL] = ctl;
regs[CTX_TIMESTAMP] = ce->stats.runtime.last;
+
+ loc = lrc_ring_bb_offset(engine);
+ if (loc != -1)
+ regs[loc + 1] = 0;
}
static void init_wa_bb_regs(u32 * const regs,
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 6ba52ef1acb8..33f22f17e358 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -323,6 +323,11 @@ static int live_lrc_fixed(void *arg)
lrc_ring_cmd_buf_cctl(engine),
"RING_CMD_BUF_CCTL"
},
+ {
+
i915_mmio_reg_offset(RING_BB_OFFSET(engine->mmio_base)),
+ lrc_ring_bb_offset(engine),
+ "RING_BB_OFFSET"
+ },
{ },
}, *t;
u32 *hw;
--
2.20.1
[Intel-gfx] [PATCH v3 0/4] lrc selftest fixes
Few bug fixes for lrc selftest. v3: Extending the first patch for gen8 Chris Wilson (4): drm/i915/gt: Explicitly clear BB_OFFSET for new contexts drm/i915/selftests: Check for incomplete LRI from the context image drm/i915/selftest: Always cancel semaphore on error drm/i915/selftest: Clear the output buffers before GPU writes drivers/gpu/drm/i915/gt/intel_engine_regs.h | 1 + drivers/gpu/drm/i915/gt/intel_lrc.c | 19 drivers/gpu/drm/i915/gt/selftest_lrc.c | 115 3 files changed, 115 insertions(+), 20 deletions(-) -- 2.20.1
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: remove unnecessary spin_lock_irq
== Series Details == Series: drm/i915: remove unnecessary spin_lock_irq URL : https://patchwork.freedesktop.org/series/103344/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11582 -> Patchwork_103344v1 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_103344v1 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_103344v1, 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_103344v1/index.html Participating hosts (43 -> 46) -- Additional (5): fi-rkl-11600 bat-adls-5 bat-dg1-6 bat-dg1-5 bat-rpls-1 Missing(2): fi-bsw-cyan fi-icl-u2 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_103344v1: ### IGT changes ### Possible regressions * igt@gem_exec_parallel@engines@fds: - fi-kbl-7500u: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11582/fi-kbl-7500u/igt@gem_exec_parallel@engi...@fds.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103344v1/fi-kbl-7500u/igt@gem_exec_parallel@engi...@fds.html - fi-cfl-8700k: [PASS][3] -> [DMESG-WARN][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11582/fi-cfl-8700k/igt@gem_exec_parallel@engi...@fds.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103344v1/fi-cfl-8700k/igt@gem_exec_parallel@engi...@fds.html - fi-skl-6700k2: [PASS][5] -> [DMESG-WARN][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11582/fi-skl-6700k2/igt@gem_exec_parallel@engi...@fds.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103344v1/fi-skl-6700k2/igt@gem_exec_parallel@engi...@fds.html * igt@i915_selftest@live@gt_contexts: - bat-dg1-5: NOTRUN -> [DMESG-FAIL][7] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103344v1/bat-dg1-5/igt@i915_selftest@live@gt_contexts.html * igt@i915_selftest@live@gt_lrc: - fi-bdw-gvtdvm: [PASS][8] -> [DMESG-WARN][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11582/fi-bdw-gvtdvm/igt@i915_selftest@live@gt_lrc.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103344v1/fi-bdw-gvtdvm/igt@i915_selftest@live@gt_lrc.html - fi-bsw-nick:[PASS][10] -> [DMESG-WARN][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11582/fi-bsw-nick/igt@i915_selftest@live@gt_lrc.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103344v1/fi-bsw-nick/igt@i915_selftest@live@gt_lrc.html - fi-kbl-7567u: [PASS][12] -> [DMESG-WARN][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11582/fi-kbl-7567u/igt@i915_selftest@live@gt_lrc.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103344v1/fi-kbl-7567u/igt@i915_selftest@live@gt_lrc.html * igt@i915_selftest@live@gt_mocs: - fi-bdw-gvtdvm: [PASS][14] -> [DMESG-FAIL][15] [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11582/fi-bdw-gvtdvm/igt@i915_selftest@live@gt_mocs.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103344v1/fi-bdw-gvtdvm/igt@i915_selftest@live@gt_mocs.html - fi-kbl-7567u: [PASS][16] -> [DMESG-FAIL][17] [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11582/fi-kbl-7567u/igt@i915_selftest@live@gt_mocs.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103344v1/fi-kbl-7567u/igt@i915_selftest@live@gt_mocs.html - fi-bsw-nick:[PASS][18] -> [DMESG-FAIL][19] [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11582/fi-bsw-nick/igt@i915_selftest@live@gt_mocs.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103344v1/fi-bsw-nick/igt@i915_selftest@live@gt_mocs.html * igt@i915_selftest@live@gt_timelines: - bat-dg1-5: NOTRUN -> [DMESG-WARN][20] [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103344v1/bat-dg1-5/igt@i915_selftest@live@gt_timelines.html * igt@kms_busy@basic@flip: - fi-adl-ddr5:[PASS][21] -> [DMESG-WARN][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11582/fi-adl-ddr5/igt@kms_busy@ba...@flip.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103344v1/fi-adl-ddr5/igt@kms_busy@ba...@flip.html - bat-dg1-6: NOTRUN -> [DMESG-WARN][23] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103344v1/bat-dg1-6/igt@kms_busy@ba...@flip.html - fi-bxt-dsi: [PASS][24] -> [DMESG-WARN][25] [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11582/fi-bxt-dsi/igt@kms_busy@ba...@flip.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103344v1/fi-bxt-dsi/igt@kms_busy@ba...@flip.html - fi-tgl-1115g4:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Change semantics of context isolation reporting to UM (rev2)
== Series Details == Series: drm/i915: Change semantics of context isolation reporting to UM (rev2) URL : https://patchwork.freedesktop.org/series/103343/ 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] ✗ Fi.CI.BAT: failure for Handle predicate programming
On 2022-04-25 at 16:44:14 +, Patchwork wrote:
> == Series Details ==
>
> Series: Handle predicate programming
> URL : https://patchwork.freedesktop.org/series/103084/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_11550 -> Patchwork_103084v1
>
>
> Summary
> ---
>
> **FAILURE**
>
> Serious unknown changes coming with Patchwork_103084v1 absolutely need to be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_103084v1, 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_103084v1/index.html
>
> Participating hosts (43 -> 42)
> --
>
> Additional (2): bat-dg2-8 bat-dg1-6
> Missing(3): fi-kbl-soraka fi-hsw-4770 fi-bsw-cyan
>
> Possible new issues
> ---
>
> Here are the unknown changes that may have been introduced in
> Patchwork_103084v1:
>
> ### IGT changes ###
>
> Possible regressions
>
> * igt@gem_exec_suspend@basic-s0@smem:
> - bat-dg1-6: NOTRUN -> [INCOMPLETE][1]
These Patches are touching lrc_isolation and lrc_layout tests alone. Hence
this failure is not related.
I will be proceeding to merge this patches.
Ram.
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103084v1/bat-dg1-6/igt@gem_exec_suspend@basic...@smem.html
>
>
> Suppressed
>
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
>
> * igt@i915_pm_rpm@module-reload:
> - {bat-rpls-2}: [DMESG-WARN][2] ([i915#4391]) -> [WARN][3]
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/bat-rpls-2/igt@i915_pm_...@module-reload.html
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103084v1/bat-rpls-2/igt@i915_pm_...@module-reload.html
>
> * igt@i915_selftest@live@client:
> - {bat-dg2-8}:NOTRUN -> [DMESG-FAIL][4]
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103084v1/bat-dg2-8/igt@i915_selftest@l...@client.html
>
> * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
> - {bat-dg2-8}:NOTRUN -> [SKIP][5]
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103084v1/bat-dg2-8/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_103084v1 that come from known
> issues:
>
> ### IGT changes ###
>
> Issues hit
>
> * igt@gem_exec_suspend@basic-s3@smem:
> - fi-bdw-5557u: [PASS][6] -> [INCOMPLETE][7] ([i915#146])
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103084v1/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
>
>
> Possible fixes
>
> * igt@i915_selftest@live@gt_heartbeat:
> - fi-cfl-guc: [DMESG-FAIL][8] ([i915#5334]) -> [PASS][9]
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-cfl-guc/igt@i915_selftest@live@gt_heartbeat.html
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103084v1/fi-cfl-guc/igt@i915_selftest@live@gt_heartbeat.html
>
> * igt@i915_selftest@live@gt_lrc:
> - {bat-dg2-9}:[INCOMPLETE][10] ([i915#5270]) -> [PASS][11]
>[10]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/bat-dg2-9/igt@i915_selftest@live@gt_lrc.html
>[11]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103084v1/bat-dg2-9/igt@i915_selftest@live@gt_lrc.html
>
> * igt@i915_selftest@live@sanitycheck:
> - {bat-rpls-2}: [INCOMPLETE][12] ([i915#5401]) -> [PASS][13]
>[12]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/bat-rpls-2/igt@i915_selftest@l...@sanitycheck.html
>[13]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103084v1/bat-rpls-2/igt@i915_selftest@l...@sanitycheck.html
>
> * igt@kms_busy@basic@flip:
> - {bat-adlp-6}: [DMESG-WARN][14] ([i915#3576]) -> [PASS][15] +1
> similar issue
>[14]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/bat-adlp-6/igt@kms_busy@ba...@flip.html
>[15]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103084v1/bat-adlp-6/igt@kms_busy@ba...@flip.html
>
>
> Warnings
>
> * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
> - fi-kbl-7567u: [SKIP][16] ([fdo#109271] / [i915#5341]) ->
> [SKIP][17] ([fdo#109271])
>[16]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-kbl-7567u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
>[17]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103084v1/fi-kbl-7567u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
>
[Intel-gfx] [PATCH] drm/i915: remove unnecessary spin_lock_irq
This code will not be called by interrupt handler,
so change it to spin_lock.
Signed-off-by: Zhenneng Li
---
drivers/gpu/drm/i915/i915_scheduler.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 762127dd56c5..6615102a1568 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -288,9 +288,9 @@ static void __i915_schedule(struct i915_sched_node *node,
void i915_schedule(struct i915_request *rq, const struct i915_sched_attr *attr)
{
- spin_lock_irq(_lock);
+ spin_lock(_lock);
__i915_schedule(>sched, attr);
- spin_unlock_irq(_lock);
+ spin_unlock(_lock);
}
void i915_sched_node_init(struct i915_sched_node *node)
--
2.25.1
[Intel-gfx] [PATCH] drm/i915: Change semantics of context isolation reporting to UM
I915_PARAM_HAS_CONTEXT_ISOLATION was already being used as a boolean by
both Iris and Vulkan , and stood for the guarantee that, when creating a
new context, all state set by it will not leak to any other context.
However the actual return value was a bitmask where every bit stood for an
initialised engine, and IGT test gem_ctx_isolation makes use of this mask
for deciding on the actual context engine isolation status.
However, we do not provide UAPI for IGT tests, so the value returned by the
PARAM ioctl has to reflect Mesa usage as a boolean.
This change only made sense after compute engine support was added to the
driver in commit 944823c9463916dd53f3 ("drm/i915/xehp: Define compute class
and engine") because no context isolation can be assumed on any device with
both RCS annd CCS engines.
Signed-off-by: Adrian Larumbe
---
drivers/gpu/drm/i915/gt/intel_engine_user.c | 13 -
drivers/gpu/drm/i915/gt/intel_engine_user.h | 1 +
drivers/gpu/drm/i915/i915_drm_client.h | 2 +-
drivers/gpu/drm/i915/i915_getparam.c| 2 +-
include/uapi/drm/i915_drm.h | 14 +++---
5 files changed, 18 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
b/drivers/gpu/drm/i915/gt/intel_engine_user.c
index 0f6cd96b459f..2d6bd36d6150 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -47,7 +47,7 @@ static const u8 uabi_classes[] = {
[COPY_ENGINE_CLASS] = I915_ENGINE_CLASS_COPY,
[VIDEO_DECODE_CLASS] = I915_ENGINE_CLASS_VIDEO,
[VIDEO_ENHANCEMENT_CLASS] = I915_ENGINE_CLASS_VIDEO_ENHANCE,
- /* TODO: Add COMPUTE_CLASS mapping once ABI is available */
+ [COMPUTE_CLASS] = I915_ENGINE_CLASS_COMPUTE,
};
static int engine_cmp(void *priv, const struct list_head *A,
@@ -306,3 +306,14 @@ unsigned int intel_engines_has_context_isolation(struct
drm_i915_private *i915)
return which;
}
+
+bool intel_cross_engine_isolated(struct drm_i915_private *i915)
+{
+ unsigned int which = intel_engines_has_context_isolation(i915);
+
+ if ((which & BIT(I915_ENGINE_CLASS_RENDER)) &&
+ (which & BIT(I915_ENGINE_CLASS_COMPUTE)))
+ return false;
+
+ return !!which;
+}
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.h
b/drivers/gpu/drm/i915/gt/intel_engine_user.h
index 3dc7e8ab9fbc..ff21349db4d4 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.h
@@ -15,6 +15,7 @@ struct intel_engine_cs *
intel_engine_lookup_user(struct drm_i915_private *i915, u8 class, u8 instance);
unsigned int intel_engines_has_context_isolation(struct drm_i915_private
*i915);
+bool intel_cross_engine_isolated(struct drm_i915_private *i915);
void intel_engine_add_user(struct intel_engine_cs *engine);
void intel_engines_driver_register(struct drm_i915_private *i915);
diff --git a/drivers/gpu/drm/i915/i915_drm_client.h
b/drivers/gpu/drm/i915/i915_drm_client.h
index 5f5b02b01ba0..f796c5e8e060 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.h
+++ b/drivers/gpu/drm/i915/i915_drm_client.h
@@ -13,7 +13,7 @@
#include "gt/intel_engine_types.h"
-#define I915_LAST_UABI_ENGINE_CLASS I915_ENGINE_CLASS_VIDEO_ENHANCE
+#define I915_LAST_UABI_ENGINE_CLASS I915_ENGINE_CLASS_COMPUTE
struct drm_i915_private;
diff --git a/drivers/gpu/drm/i915/i915_getparam.c
b/drivers/gpu/drm/i915/i915_getparam.c
index c12a0adefda5..3d5120d2d78a 100644
--- a/drivers/gpu/drm/i915/i915_getparam.c
+++ b/drivers/gpu/drm/i915/i915_getparam.c
@@ -145,7 +145,7 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data,
value = 1;
break;
case I915_PARAM_HAS_CONTEXT_ISOLATION:
- value = intel_engines_has_context_isolation(i915);
+ value = intel_cross_engine_isolated(i915);
break;
case I915_PARAM_SLICE_MASK:
value = sseu->slice_mask;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 35ca528803fd..84c0af77cc1f 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -166,6 +166,7 @@ enum drm_i915_gem_engine_class {
I915_ENGINE_CLASS_COPY = 1,
I915_ENGINE_CLASS_VIDEO = 2,
I915_ENGINE_CLASS_VIDEO_ENHANCE = 3,
+ I915_ENGINE_CLASS_COMPUTE = 4,
/* should be kept compact */
@@ -635,17 +636,8 @@ typedef struct drm_i915_irq_wait {
#define I915_PARAM_HAS_EXEC_FENCE_ARRAY 49
/*
- * Query whether every context (both per-file default and user created) is
- * isolated (insofar as HW supports). If this parameter is not true, then
- * freshly created contexts may inherit values from an existing context,
- * rather than default HW values. If true, it also ensures (insofar as HW
- * supports) that all state set by this context will not leak to any other
- * context.
- *
- * As not every engine across every gen
[Intel-gfx] [PATCH] drm/i915: Change semantics of context isolation reporting to UM
I915_PARAM_HAS_CONTEXT_ISOLATION was already being used as a boolean by
both Iris and Vulkan , and stood for the guarantee that, when creating a
new context, all state set by it will not leak to any other context.
However the actual return value was a bitmask where every bit stood for an
initialised engine, and IGT test gem_ctx_isolation makes use of this mask
for deciding on the actual context engine isolation status.
However, we do not provide UAPI for IGT tests, so the value returned by the
PARAM ioctl has to reflect Mesa usage as a boolean.
This change only made sense after compute engine support was added to the
driver in commit 944823c9463916dd53f3 ("drm/i915/xehp: Define compute class
and engine") because no context isolation can be assumed on any device with
both RCS annd CCS engines.
Signed-off-by: Adrian Larumbe
---
drivers/gpu/drm/i915/gt/intel_engine_user.c | 13 -
drivers/gpu/drm/i915/gt/intel_engine_user.h | 1 +
drivers/gpu/drm/i915/i915_drm_client.h | 2 +-
drivers/gpu/drm/i915/i915_getparam.c| 2 +-
include/uapi/drm/i915_drm.h | 14 +++---
5 files changed, 18 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
b/drivers/gpu/drm/i915/gt/intel_engine_user.c
index 0f6cd96b459f..2d6bd36d6150 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -47,7 +47,7 @@ static const u8 uabi_classes[] = {
[COPY_ENGINE_CLASS] = I915_ENGINE_CLASS_COPY,
[VIDEO_DECODE_CLASS] = I915_ENGINE_CLASS_VIDEO,
[VIDEO_ENHANCEMENT_CLASS] = I915_ENGINE_CLASS_VIDEO_ENHANCE,
- /* TODO: Add COMPUTE_CLASS mapping once ABI is available */
+ [COMPUTE_CLASS] = I915_ENGINE_CLASS_COMPUTE,
};
static int engine_cmp(void *priv, const struct list_head *A,
@@ -306,3 +306,14 @@ unsigned int intel_engines_has_context_isolation(struct
drm_i915_private *i915)
return which;
}
+
+bool intel_cross_engine_isolated(struct drm_i915_private *i915)
+{
+ unsigned int which = intel_engines_has_context_isolation(i915);
+
+ if ((which & BIT(I915_ENGINE_CLASS_RENDER)) &&
+ (which & BIT(I915_ENGINE_CLASS_COMPUTE)))
+ return false;
+
+ return !!which;
+}
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.h
b/drivers/gpu/drm/i915/gt/intel_engine_user.h
index 3dc7e8ab9fbc..ff21349db4d4 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.h
@@ -15,6 +15,7 @@ struct intel_engine_cs *
intel_engine_lookup_user(struct drm_i915_private *i915, u8 class, u8 instance);
unsigned int intel_engines_has_context_isolation(struct drm_i915_private
*i915);
+bool intel_cross_engine_isolated(struct drm_i915_private *i915);
void intel_engine_add_user(struct intel_engine_cs *engine);
void intel_engines_driver_register(struct drm_i915_private *i915);
diff --git a/drivers/gpu/drm/i915/i915_drm_client.h
b/drivers/gpu/drm/i915/i915_drm_client.h
index 5f5b02b01ba0..f796c5e8e060 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.h
+++ b/drivers/gpu/drm/i915/i915_drm_client.h
@@ -13,7 +13,7 @@
#include "gt/intel_engine_types.h"
-#define I915_LAST_UABI_ENGINE_CLASS I915_ENGINE_CLASS_VIDEO_ENHANCE
+#define I915_LAST_UABI_ENGINE_CLASS I915_ENGINE_CLASS_COMPUTE
struct drm_i915_private;
diff --git a/drivers/gpu/drm/i915/i915_getparam.c
b/drivers/gpu/drm/i915/i915_getparam.c
index c12a0adefda5..3d5120d2d78a 100644
--- a/drivers/gpu/drm/i915/i915_getparam.c
+++ b/drivers/gpu/drm/i915/i915_getparam.c
@@ -145,7 +145,7 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data,
value = 1;
break;
case I915_PARAM_HAS_CONTEXT_ISOLATION:
- value = intel_engines_has_context_isolation(i915);
+ value = intel_cross_engine_isolated(i915);
break;
case I915_PARAM_SLICE_MASK:
value = sseu->slice_mask;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 35ca528803fd..84c0af77cc1f 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -166,6 +166,7 @@ enum drm_i915_gem_engine_class {
I915_ENGINE_CLASS_COPY = 1,
I915_ENGINE_CLASS_VIDEO = 2,
I915_ENGINE_CLASS_VIDEO_ENHANCE = 3,
+ I915_ENGINE_CLASS_COMPUTE = 4,
/* should be kept compact */
@@ -635,17 +636,8 @@ typedef struct drm_i915_irq_wait {
#define I915_PARAM_HAS_EXEC_FENCE_ARRAY 49
/*
- * Query whether every context (both per-file default and user created) is
- * isolated (insofar as HW supports). If this parameter is not true, then
- * freshly created contexts may inherit values from an existing context,
- * rather than default HW values. If true, it also ensures (insofar as HW
- * supports) that all state set by this context will not leak to any other
- * context.
- *
- * As not every engine across every gen
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: move tons of power well initializers to rodata
== Series Details ==
Series: drm/i915: move tons of power well initializers to rodata
URL : https://patchwork.freedesktop.org/series/103340/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11582 -> Patchwork_103340v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103340v1/index.html
Participating hosts (43 -> 41)
--
Additional (2): bat-rpls-1 fi-rkl-11600
Missing(4): fi-kbl-soraka fi-bsw-cyan fi-icl-u2 fi-apl-guc
Known issues
Here are the changes found in Patchwork_103340v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-rkl-11600: NOTRUN -> [SKIP][1] ([i915#2190])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103340v1/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-rkl-11600: NOTRUN -> [SKIP][2] ([i915#4613]) +3 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103340v1/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html
* igt@gem_tiled_pread_basic:
- fi-rkl-11600: NOTRUN -> [SKIP][3] ([i915#3282])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103340v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html
* igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600: NOTRUN -> [SKIP][4] ([i915#3012])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103340v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-g3258: [PASS][5] -> [INCOMPLETE][6] ([i915#3303] /
[i915#4785])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11582/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103340v1/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
- fi-bdw-5557u: NOTRUN -> [INCOMPLETE][7] ([i915#3921])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103340v1/fi-bdw-5557u/igt@i915_selftest@l...@hangcheck.html
* igt@kms_chamelium@dp-crc-fast:
- fi-rkl-11600: NOTRUN -> [SKIP][8] ([fdo#111827]) +8 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103340v1/fi-rkl-11600/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-rkl-11600: NOTRUN -> [SKIP][9] ([i915#4070] / [i915#4103]) +1
similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103340v1/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-rkl-11600: NOTRUN -> [SKIP][10] ([fdo#109285] / [i915#4098])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103340v1/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-rkl-11600: NOTRUN -> [SKIP][11] ([i915#4070] / [i915#533])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103340v1/fi-rkl-11600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
* igt@kms_psr@primary_mmap_gtt:
- fi-rkl-11600: NOTRUN -> [SKIP][12] ([i915#1072]) +3 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103340v1/fi-rkl-11600/igt@kms_psr@primary_mmap_gtt.html
* igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600: NOTRUN -> [SKIP][13] ([i915#3555] / [i915#4098])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103340v1/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html
* igt@prime_vgem@basic-userptr:
- fi-rkl-11600: NOTRUN -> [SKIP][14] ([i915#3301] / [i915#3708])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103340v1/fi-rkl-11600/igt@prime_v...@basic-userptr.html
* igt@prime_vgem@basic-write:
- fi-rkl-11600: NOTRUN -> [SKIP][15] ([i915#3291] / [i915#3708]) +2
similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103340v1/fi-rkl-11600/igt@prime_v...@basic-write.html
* igt@runner@aborted:
- fi-hsw-g3258: NOTRUN -> [FAIL][16] ([fdo#109271] / [i915#4312])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103340v1/fi-hsw-g3258/igt@run...@aborted.html
Possible fixes
* igt@i915_selftest@live@mman:
- fi-bdw-5557u: [INCOMPLETE][17] ([i915#5704]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11582/fi-bdw-5557u/igt@i915_selftest@l...@mman.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103340v1/fi-bdw-5557u/igt@i915_selftest@l...@mman.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
Re: [Intel-gfx] [PATCH 1/3] drm/i915/display: Do not schedule DRRS work thread when it is not active
On Thu, Apr 28, 2022 at 02:10:56PM -0700, José Roberto de Souza wrote:
> Frontbuffer updates were scheduling the execution of DRRS work thread
> even if DRRS is not active.
> There was no issues with it because intel_drrs_downclock_work() checks
> if DRRS is active but there is no reason to keep scheduling this work
> thread and wasting CPU time.
>
> Cc: Ville Syrjälä
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/display/intel_drrs.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c
> b/drivers/gpu/drm/i915/display/intel_drrs.c
> index 166caf293f7bc..04bc296761be0 100644
> --- a/drivers/gpu/drm/i915/display/intel_drrs.c
> +++ b/drivers/gpu/drm/i915/display/intel_drrs.c
> @@ -236,6 +236,11 @@ static void intel_drrs_frontbuffer_update(struct
> drm_i915_private *dev_priv,
> else
> crtc->drrs.busy_frontbuffer_bits &= ~frontbuffer_bits;
>
> + if (!intel_drrs_is_active(crtc)) {
> + mutex_unlock(>drrs.mutex);
> + continue;
> + }
Should be impossible due to crtc->drrs.frontbuffer_bits==0.
> +
> /* flush/invalidate means busy screen hence upclock */
> intel_drrs_set_state(crtc, DRRS_REFRESH_RATE_HIGH);
>
> --
> 2.36.0
--
Ville Syrjälä
Intel
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fix assert in i915_ggtt_pin
== Series Details ==
Series: drm/i915: Fix assert in i915_ggtt_pin
URL : https://patchwork.freedesktop.org/series/103339/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11582 -> Patchwork_103339v1
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_103339v1 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_103339v1, 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_103339v1/index.html
Participating hosts (43 -> 43)
--
Additional (1): bat-rpls-1
Missing(1): fi-bsw-cyan
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_103339v1:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@memory_region:
- fi-cfl-8109u: [PASS][1] -> [DMESG-WARN][2] +11 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11582/fi-cfl-8109u/igt@i915_selftest@live@memory_region.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103339v1/fi-cfl-8109u/igt@i915_selftest@live@memory_region.html
Known issues
Here are the changes found in Patchwork_103339v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@module-reload:
- fi-cfl-8109u: [PASS][3] -> [DMESG-FAIL][4] ([i915#62])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11582/fi-cfl-8109u/igt@i915_pm_...@module-reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103339v1/fi-cfl-8109u/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@hangcheck:
- fi-bdw-5557u: NOTRUN -> [INCOMPLETE][5] ([i915#3921])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103339v1/fi-bdw-5557u/igt@i915_selftest@l...@hangcheck.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-snb-2600:NOTRUN -> [SKIP][6] ([fdo#109271] / [fdo#111827])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103339v1/fi-snb-2600/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:
- fi-cfl-8109u: [PASS][7] -> [DMESG-WARN][8] ([i915#62]) +15 similar
issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11582/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103339v1/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
Possible fixes
* igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[INCOMPLETE][9] ([i915#3921]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11582/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103339v1/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@mman:
- fi-bdw-5557u: [INCOMPLETE][11] ([i915#5704]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11582/fi-bdw-5557u/igt@i915_selftest@l...@mman.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103339v1/fi-bdw-5557u/igt@i915_selftest@l...@mman.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3576
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
[i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5270]: https://gitlab.freedesktop.org/drm/intel/issues/5270
[i915#5338]: https://gitlab.freedesktop.org/drm/intel/issues/5338
[i915#5356]: https://gitlab.freedesktop.org/drm/intel/issues/5356
[i915#5704]: https://gitlab.freedesktop.org/drm/intel/issues/5704
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
Build changes
-
* Linux: CI_DRM_11582 -> Patchwork_103339v1
CI-20190529: 20190529
CI_DRM_11582:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: move tons of power well initializers to rodata
== Series Details == Series: drm/i915: move tons of power well initializers to rodata URL : https://patchwork.freedesktop.org/series/103340/ State : warning == Summary == Error: dim checkpatch failed 82d7c7816f0f drm/i915: move tons of power well initializers to rodata -:16: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #16: $ objdump --syms drivers/gpu/drm/i915/display/intel_display_power_map.o | grep "\.rodata.*__compound_literal" total: 0 errors, 1 warnings, 0 checks, 16 lines checked
Re: [Intel-gfx] [PATCH 1/2] module: add a function to add module references
On Fri, Apr 29, 2022 at 11:23:51AM +0100, Mauro Carvalho Chehab wrote: Em Fri, 29 Apr 2022 12:10:07 +0200 Greg KH escreveu: On Fri, Apr 29, 2022 at 10:15:03AM +0100, Mauro Carvalho Chehab wrote: > HI Greg, > > Em Fri, 29 Apr 2022 10:30:33 +0200 > Greg KH escreveu: > > > On Fri, Apr 29, 2022 at 09:07:57AM +0100, Mauro Carvalho Chehab wrote: > > > Hi Daniel, > > > > > > Em Fri, 29 Apr 2022 09:54:10 +0200 > > > Daniel Vetter escreveu: > > > > > > > On Fri, Apr 29, 2022 at 07:31:15AM +0100, Mauro Carvalho Chehab wrote: > > > > > Sometimes, device drivers are bound using indirect references, > > > > > which is not visible when looking at /proc/modules or lsmod. > > > > > > > > > > Add a function to allow setting up module references for such > > > > > cases. > > > > > > > > > > Reviewed-by: Dan Williams > > > > > Signed-off-by: Mauro Carvalho Chehab > > > > > > > > This sounds like duct tape at the wrong level. We should have a > > > > device_link connecting these devices, and maybe device_link internally > > > > needs to make sure the respective driver modules stay around for long > > > > enough too. But open-coding this all over the place into every driver that > > > > has some kind of cross-driver dependency sounds terrible. > > > > > > > > Or maybe the bug is that the snd driver keeps accessing the hw/component > > > > side when that is just plain gone. Iirc there's still fundamental issues > > > > there on the sound side of things, which have been attempted to paper over > > > > by timeouts and stuff like that in the past instead of enforcing a hard > > > > link between the snd and i915 side. > > > > > > I agree with you that the device link between snd-hda and the DRM driver > > > should properly handle unbinding on both directions. This is something > > > that require further discussions with ALSA and DRM people, and we should > > > keep working on it. > > > > > > Yet, the binding between those drivers do exist, but, despite other > > > similar inter-driver bindings being properly reported by lsmod, this one > > > is invisible for userspace. > > > > > > What this series does is to make such binding visible. As simple as that. > > > > It also increases the reference count, and creates a user/kernel api > > with the symlinks, right? Will the reference count increase prevent the > > modules from now being unloadable? > > > > This feels like a very "weak" link between modules that should not be > > needed if reference counting is implemented properly (so that things are > > cleaned up in the correct order.) > > The refcount increment exists even without this patch, as > hda_component_master_bind() at sound/hda/hdac_component.c uses > try_module_get() when it creates the device link. Ok, then why shouldn't try_module_get() be creating this link instead of having to manually do it this way again? You don't want to have to go around and add this call to all users of that function, right? Works for me, but this is not a too trivial change, as the new try_module_get() function will require two parameters, instead of one: - the module to be referenced; - the module which will reference it. On trivial cases, one will be THIS_MODULE, but, in the specific case of snd_hda, the binding is done via an ancillary routine under snd_hda_core, but the actual binding happens at snd_hda_intel. Ok, we could add a __try_module_get() (or whatever other name that would properly express what it does) with two parameters, and then define try_module_get() as: #define try_module_get(mod) __try_module_get(mod, THIS_MODULE) agree that this should be done at this level rather than open coding it at every driver. Main improvement being fixed here regardless of the snd-hda-intel issue is to properly annotate what is holding a module. Right now we have 1) symbol module dependencies; 2) kernel references; 3) userspace references. With (2) and (3) being unknown to the user from lsmod pov. Handling this any time try_module_get() is called would make (2) visible to lsmod. Paired with fixes to the (unreleased) kmod 30[1], this allows `modprobe -r --remove-holders ` to also try removing the holders before removing the module itself. thanks Lucas De Marchi [1] https://lore.kernel.org/linux-modules/20220329090912.geymr6xk7taq4...@ldmartin-desk2.jf.intel.com/T/#t Would that work for you? Regards, Mauro
Re: [Intel-gfx] [PATCH 3/9] drm/i915/pcode: Extend pcode functions for multiple gt's
On Fri, 29 Apr 2022 05:58:21 -0700, Rodrigo Vivi wrote: > > > @@ -1251,7 +1251,7 @@ static int i915_drm_resume(struct drm_device *dev) > > > > disable_rpm_wakeref_asserts(_priv->runtime_pm); > > > > - ret = intel_pcode_init(dev_priv); > > + ret = intel_gt_pcode_init(dev_priv); > > I didn't like we have this indirection i915 -> gt -> i915... > At the same time I understand you don't want to duplicate the for_each with > the error msg and all in here. > > So, what about having in this file a > static int __init_pcode(dev_priv) > ?! Sure, will fix. > > diff --git a/drivers/gpu/drm/i915/intel_pcode.c > > b/drivers/gpu/drm/i915/intel_pcode.c > > index ac727546868e..66020b2e461f 100644 > > --- a/drivers/gpu/drm/i915/intel_pcode.c > > +++ b/drivers/gpu/drm/i915/intel_pcode.c > > @@ -52,14 +52,12 @@ static int gen7_check_mailbox_status(u32 mbox) > > } > > } > > > > -static int __snb_pcode_rw(struct drm_i915_private *i915, u32 mbox, > > +static int intel_pcode_rw(struct intel_uncore *uncore, u32 mbox, > > I'm not sure if I like the idea of the renaming here... > I mean, it looks nicer indeed, but at the same time the "intel_" > make it looks it is exported one. Sure, will fix. > > --- a/drivers/gpu/drm/i915/intel_pcode.h > > +++ b/drivers/gpu/drm/i915/intel_pcode.h > > @@ -8,17 +8,32 @@ > > > > #include > > > > +struct intel_uncore; > > struct drm_i915_private; > > > > -int snb_pcode_read(struct drm_i915_private *i915, u32 mbox, u32 *val, u32 > > *val1); > > -int snb_pcode_write_timeout(struct drm_i915_private *i915, u32 mbox, u32 > > val, > > - int fast_timeout_us, int slow_timeout_ms); > > -#define snb_pcode_write(i915, mbox, val) \ > > +int intel_pcode_read(struct intel_uncore *uncore, u32 mbox, u32 *val, u32 > > *val1); > > + > > +int intel_pcode_write_timeout(struct intel_uncore *uncore, u32 mbox, u32 > > val, > > + int fast_timeout_us, int slow_timeout_ms); > > + > > +#define intel_pcode_write(uncore, mbox, val) \ > > + intel_pcode_write_timeout(uncore, mbox, val, 500, 0) > > + > > +int intel_pcode_request(struct intel_uncore *uncore, u32 mbox, u32 request, > > + u32 reply_mask, u32 reply, int timeout_base_ms); > > + > > +#define snb_pcode_read(i915, mbox, val, val1) \ > > + intel_pcode_read(&(i915)->uncore, mbox, val, val1) > > + > > +#define snb_pcode_write_timeout(i915, mbox, val, fast_timeout_us, > > slow_timeout_ms) \ > > + intel_pcode_write_timeout(&(i915)->uncore, mbox, val, fast_timeout_us, > > slow_timeout_ms) > > + > > +#define snb_pcode_write(i915, mbox, val) \ > > snb_pcode_write_timeout(i915, mbox, val, 500, 0) > > > > -int skl_pcode_request(struct drm_i915_private *i915, u32 mbox, u32 request, > > - u32 reply_mask, u32 reply, int timeout_base_ms); > > +#define skl_pcode_request(i915, mbox, request, reply_mask, reply, > > timeout_base_ms) \ > > + intel_pcode_request(&(i915)->uncore, mbox, request, reply_mask, reply, > > timeout_base_ms) > > and for the exported one, since we are renaming it, shouldn't we rename > all the users instead of creating these defines? Ok, in that case we might as well retain the original function names (snb_/skl_ etc. and just change the first argument to uncore)? So will do that in the next rev unless we think we want to rename everything to intel_? Thanks. -- Ashutosh
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: remove superfluous string helper include (rev3)
== Series Details == Series: drm/i915: remove superfluous string helper include (rev3) URL : https://patchwork.freedesktop.org/series/103086/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11581 -> Patchwork_103086v3 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_103086v3 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_103086v3, 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_103086v3/index.html Participating hosts (44 -> 44) -- Additional (3): fi-icl-u2 bat-dg2-9 bat-dg1-5 Missing(3): fi-rkl-11600 fi-bsw-cyan bat-adlp-4 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_103086v3: ### IGT changes ### Possible regressions * igt@i915_suspend@system-suspend-without-i915: - bat-dg1-5: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v3/bat-dg1-5/igt@i915_susp...@system-suspend-without-i915.html Known issues Here are the changes found in Patchwork_103086v3 that come from known issues: ### IGT changes ### Issues hit * igt@fbdev@write: - bat-dg1-5: NOTRUN -> [SKIP][2] ([i915#2582]) +4 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v3/bat-dg1-5/igt@fb...@write.html * igt@gem_huc_copy@huc-copy: - fi-icl-u2: NOTRUN -> [SKIP][3] ([i915#2190]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v3/fi-icl-u2/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@parallel-random-engines: - fi-icl-u2: NOTRUN -> [SKIP][4] ([i915#4613]) +3 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v3/fi-icl-u2/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_mmap@basic: - bat-dg1-5: NOTRUN -> [SKIP][5] ([i915#4083]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v3/bat-dg1-5/igt@gem_m...@basic.html * igt@gem_tiled_fence_blits@basic: - bat-dg1-5: NOTRUN -> [SKIP][6] ([i915#4077]) +2 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v3/bat-dg1-5/igt@gem_tiled_fence_bl...@basic.html * igt@gem_tiled_pread_basic: - bat-dg1-5: NOTRUN -> [SKIP][7] ([i915#4079]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v3/bat-dg1-5/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - bat-dg1-5: NOTRUN -> [SKIP][8] ([i915#1155]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v3/bat-dg1-5/igt@i915_pm_backli...@basic-brightness.html * igt@i915_selftest@live@gem_contexts: - fi-bdw-5557u: [PASS][9] -> [INCOMPLETE][10] ([i915#5502] / [i915#5801]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11581/fi-bdw-5557u/igt@i915_selftest@live@gem_contexts.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v3/fi-bdw-5557u/igt@i915_selftest@live@gem_contexts.html * igt@i915_selftest@live@hangcheck: - bat-dg1-5: NOTRUN -> [DMESG-FAIL][11] ([i915#4494] / [i915#4957]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v3/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html - fi-snb-2600:[PASS][12] -> [INCOMPLETE][13] ([i915#3921]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11581/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v3/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html * igt@kms_addfb_basic@basic-y-tiled-legacy: - bat-dg1-5: NOTRUN -> [SKIP][14] ([i915#4215]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v3/bat-dg1-5/igt@kms_addfb_ba...@basic-y-tiled-legacy.html * igt@kms_addfb_basic@tile-pitch-mismatch: - bat-dg1-5: NOTRUN -> [SKIP][15] ([i915#4212]) +7 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v3/bat-dg1-5/igt@kms_addfb_ba...@tile-pitch-mismatch.html * igt@kms_busy@basic: - bat-dg1-5: NOTRUN -> [SKIP][16] ([i915#4303]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v3/bat-dg1-5/igt@kms_b...@basic.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-icl-u2: NOTRUN -> [SKIP][17] ([fdo#111827]) +8 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v3/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html - bat-dg1-5: NOTRUN -> [SKIP][18] ([fdo#111827]) +7 similar issues [18]:
Re: [Intel-gfx] [V2 3/3] drm/amd/display: Move connector debugfs to drm
> -Original Message- > From: Intel-gfx On Behalf Of > Bhanuprakash Modem > Sent: Monday, April 11, 2022 3:21 PM > To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; amd- > g...@lists.freedesktop.org; jani.nik...@linux.intel.com; > ville.syrj...@linux.intel.com; harry.wentl...@amd.com; Sharma, Swati2 > > Cc: Rodrigo Siqueira > Subject: [Intel-gfx] [V2 3/3] drm/amd/display: Move connector debugfs to > drm > > As drm_connector already have the display_info, instead of creating > "output_bpc" debugfs in vendor specific driver, move the logic to the drm > layer. > > This patch will also move "Current" bpc to the crtc debugfs from connector > debugfs, since we are getting this info from crtc_state. > > Cc: Harry Wentland > Cc: Rodrigo Siqueira > Signed-off-by: Bhanuprakash Modem > Reported-by: kernel test robot > --- Reviewed-by: Arun R Murthy Thanks and Regards, Arun R Murthy
Re: [Intel-gfx] [V2 1/3] drm/debug: Expose connector's max supported bpc via debugfs
> +static int output_bpc_show(struct seq_file *m, void *data) {
Can we have a meaningful name instead of 'm' ?
Upon changing this parameter name, you can have my
Reviewed-By: Arun R Murthy
Thanks and Regards,
Arun R Murthy
[Intel-gfx] [PATCH] drm/i915: move tons of power well initializers to rodata
Using compound literals for initialization can be tricky. Lacking a
const qualifier, they won't end up in rodata, which is probably not
expected or intended. Add const to move a whopping 136 initializers to
rodata.
Compare:
$ objdump --syms drivers/gpu/drm/i915/display/intel_display_power_map.o | grep
"\.rodata.*__compound_literal"
$ objdump --syms drivers/gpu/drm/i915/display/intel_display_power_map.o | grep
"\.data.*__compound_literal"
Before and after the change.
Fixes: c32ffce42aa5 ("drm/i915: Convert the power well descriptor domain mask
to an array of domains")
Fixes: 4a845ff0c0d4 ("drm/i915: Simplify power well definitions by adding power
well instances")
Cc: Imre Deak
Cc: Jouni Högander
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display_power_map.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power_map.c
b/drivers/gpu/drm/i915/display/intel_display_power_map.c
index af6f54a26a35..97b367f39f35 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power_map.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power_map.c
@@ -21,7 +21,7 @@
#define I915_PW_DOMAINS(...) \
(const struct i915_power_domain_list) \
- __LIST(__LIST_INLINE_ELEMS(enum intel_display_power_domain,
__VA_ARGS__))
+ __LIST(__LIST_INLINE_ELEMS(const enum
intel_display_power_domain, __VA_ARGS__))
#define I915_DECL_PW_DOMAINS(__name, ...) \
static const struct i915_power_domain_list __name =
I915_PW_DOMAINS(__VA_ARGS__)
@@ -32,7 +32,7 @@
#define I915_PW_INSTANCES(...) \
(const struct i915_power_well_instance_list) \
- __LIST(__LIST_INLINE_ELEMS(struct i915_power_well_instance,
__VA_ARGS__))
+ __LIST(__LIST_INLINE_ELEMS(const struct
i915_power_well_instance, __VA_ARGS__))
#define I915_PW(_name, _domain_list, ...) \
{ .name = _name, .domain_list = _domain_list, ## __VA_ARGS__ }
--
2.30.2
[Intel-gfx] [CI] drm/i915: Fix assert in i915_ggtt_pin
From: Tvrtko Ursulin
Use lockdep_assert_not_held to simplify and correct the code. Otherwise
false positive are hit if lock state is uknown like after a previous
taint.
Signed-off-by: Tvrtko Ursulin
Reported-by: Ville Syrjälä
Reviewed-by: Ville Syrjälä
---
It's not pretty but it fired again and it's distracting so it will have to
do for now.
---
drivers/gpu/drm/i915/i915_vma.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 162e8d83691b..e782ebfcc0ca 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1565,9 +1565,7 @@ int i915_ggtt_pin(struct i915_vma *vma, struct
i915_gem_ww_ctx *ww,
if (ww)
return __i915_ggtt_pin(vma, ww, align, flags);
-#ifdef CONFIG_LOCKDEP
- WARN_ON(dma_resv_held(vma->obj->base.resv));
-#endif
+ lockdep_assert_not_held(>obj->base.resv->lock.base);
for_i915_gem_ww(&_ww, err, true) {
err = i915_gem_object_lock(vma->obj, &_ww);
--
2.32.0
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Enable THP on Icelake and beyond
== Series Details == Series: series starting with [1/2] drm/i915: Enable THP on Icelake and beyond URL : https://patchwork.freedesktop.org/series/103330/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11580 -> Patchwork_103330v1 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_103330v1 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_103330v1, 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_103330v1/index.html Participating hosts (44 -> 43) -- Additional (3): fi-kbl-soraka fi-hsw-4770 fi-icl-u2 Missing(4): fi-bsw-cyan fi-pnv-d510 bat-dg1-6 bat-dg1-5 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_103330v1: ### IGT changes ### Possible regressions * igt@i915_selftest@live@mman: - fi-icl-u2: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103330v1/fi-icl-u2/igt@i915_selftest@l...@mman.html Known issues Here are the changes found in Patchwork_103330v1 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@read_all_entries: - fi-kbl-soraka: NOTRUN -> [DMESG-WARN][2] ([i915#1982]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103330v1/fi-kbl-soraka/igt@debugfs_test@read_all_entries.html * igt@gem_exec_fence@basic-busy@bcs0: - fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271]) +9 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103330v1/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html * igt@gem_huc_copy@huc-copy: - fi-hsw-4770:NOTRUN -> [SKIP][4] ([fdo#109271]) +9 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103330v1/fi-hsw-4770/igt@gem_huc_c...@huc-copy.html - fi-kbl-soraka: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103330v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html - fi-icl-u2: NOTRUN -> [SKIP][6] ([i915#2190]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103330v1/fi-icl-u2/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-kbl-soraka: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103330v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html * igt@gem_lmem_swapping@parallel-random-engines: - fi-icl-u2: NOTRUN -> [SKIP][8] ([i915#4613]) +3 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103330v1/fi-icl-u2/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_lmem_swapping@random-engines: - fi-cfl-8109u: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#4613]) +3 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103330v1/fi-cfl-8109u/igt@gem_lmem_swapp...@random-engines.html * igt@i915_pm_backlight@basic-brightness: - fi-hsw-4770:NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#3012]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103330v1/fi-hsw-4770/igt@i915_pm_backli...@basic-brightness.html * igt@i915_selftest@live@gem: - fi-blb-e6850: [PASS][11] -> [DMESG-FAIL][12] ([i915#4528]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11580/fi-blb-e6850/igt@i915_selftest@l...@gem.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103330v1/fi-blb-e6850/igt@i915_selftest@l...@gem.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][13] ([i915#1886]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103330v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@i915_selftest@live@hangcheck: - fi-hsw-g3258: [PASS][14] -> [INCOMPLETE][15] ([i915#3303] / [i915#4785]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11580/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103330v1/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html - fi-bdw-5557u: NOTRUN -> [INCOMPLETE][16] ([i915#3921]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103330v1/fi-bdw-5557u/igt@i915_selftest@l...@hangcheck.html - fi-ivb-3770:[PASS][17] -> [INCOMPLETE][18] ([i915#3303] / [i915#5370]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11580/fi-ivb-3770/igt@i915_selftest@l...@hangcheck.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103330v1/fi-ivb-3770/igt@i915_selftest@l...@hangcheck.html *
Re: [Intel-gfx] [PATCH 3/3] drm/i915/gt: Clear SET_PREDICATE_RESULT prior to executing the ring
On Mon, 25 Apr 2022 at 16:22, Ramalingam C wrote: > > From: Chris Wilson > > Userspace may leave predication enabled upon return from the batch > buffer, which has the consequent of preventing all operation from the > ring from being executed, including all the synchronisation, coherency > control, arbitration and user signaling. This is more than just a local > gpu hang in one client, as the user has the ability to prevent the > kernel from applying critical workarounds and can cause a full GT reset. > > We could simply execute MI_SET_PREDICATE upon return from the user > batch, but this has the repercussion of modifying the user's context > state. Instead, we opt to execute a fixup batch which by mixing > predicated operations can determine the state of the > SET_PREDICATE_RESULT register and restore it prior to the next userspace > batch. This allows us to protect the kernel's ring without changing the > uABI. > > Suggested-by: Zbigniew Kempczynski > Signed-off-by: Chris Wilson > Cc: Zbigniew Kempczynski > Cc: Thomas Hellstrom > Signed-off-by: Ramalingam C Reviewed-by: Matthew Auld
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915: Enable THP on Icelake and beyond
== Series Details == Series: series starting with [1/2] drm/i915: Enable THP on Icelake and beyond URL : https://patchwork.freedesktop.org/series/103330/ 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 3/9] drm/i915/pcode: Extend pcode functions for multiple gt's
On Thu, Apr 28, 2022 at 05:39:37PM -0700, Ashutosh Dixit wrote:
> Each gt contains an independent instance of pcode. Extend pcode functions
> to interface with pcode on different gt's. To avoid creating dependency of
> display functionality on intel_gt, new pcode function interfaces are
> exposed in terms of uncore rather than intel_gt. Previous struct
> drm_i915_private based pcode interfaces are preserved.
>
> v2: Expose pcode functions in terms of uncore rather than gt (Jani/Rodrigo)
thank you for that! it looks better with the uncore.
sorry for not thinking about this earlier.
but some comments below...
>
> Cc: Rodrigo Vivi
> Cc: Jani Nikula
> Cc: Andi Shyti
> Signed-off-by: Ashutosh Dixit
> ---
> drivers/gpu/drm/i915/gt/intel_gt.c | 17 +++
> drivers/gpu/drm/i915/gt/intel_gt.h | 2 +
> drivers/gpu/drm/i915/i915_driver.c | 4 +-
> drivers/gpu/drm/i915/intel_pcode.c | 76 +++---
> drivers/gpu/drm/i915/intel_pcode.h | 29 +---
> 5 files changed, 80 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> b/drivers/gpu/drm/i915/gt/intel_gt.c
> index 92394f13b42f..07cfe66dd0e8 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -28,6 +28,7 @@
> #include "intel_rps.h"
> #include "intel_gt_sysfs.h"
> #include "intel_uncore.h"
> +#include "intel_pcode.h"
> #include "shmem_utils.h"
>
> static void __intel_gt_init_early(struct intel_gt *gt)
> @@ -1240,3 +1241,19 @@ void intel_gt_invalidate_tlbs(struct intel_gt *gt)
> intel_uncore_forcewake_put_delayed(uncore, FORCEWAKE_ALL);
> mutex_unlock(>tlb_invalidate_lock);
> }
> +
> +int intel_gt_pcode_init(struct drm_i915_private *i915)
> +{
> + struct intel_gt *gt;
> + int id, ret;
> +
> + for_each_gt(gt, i915, id) {
> + ret = intel_pcode_init(gt->uncore);
> + if (ret) {
> + drm_err(>i915->drm, "gt %d: intel_pcode_init failed
> %d\n", id, ret);
> + return ret;
> + }
> + }
> +
> + return 0;
> +}
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
> b/drivers/gpu/drm/i915/gt/intel_gt.h
> index 44c6cb63ccbc..241d833fdb1e 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.h
> @@ -125,6 +125,8 @@ void intel_gt_watchdog_work(struct work_struct *work);
>
> void intel_gt_invalidate_tlbs(struct intel_gt *gt);
>
> +int intel_gt_pcode_init(struct drm_i915_private *i915);
> +
> struct resource intel_pci_resource(struct pci_dev *pdev, int bar);
>
> #endif /* __INTEL_GT_H__ */
> diff --git a/drivers/gpu/drm/i915/i915_driver.c
> b/drivers/gpu/drm/i915/i915_driver.c
> index 90b0ce5051af..518d6e357017 100644
> --- a/drivers/gpu/drm/i915/i915_driver.c
> +++ b/drivers/gpu/drm/i915/i915_driver.c
> @@ -629,7 +629,7 @@ static int i915_driver_hw_probe(struct drm_i915_private
> *dev_priv)
>
> intel_opregion_setup(dev_priv);
>
> - ret = intel_pcode_init(dev_priv);
> + ret = intel_gt_pcode_init(dev_priv);
> if (ret)
> goto err_msi;
>
> @@ -1251,7 +1251,7 @@ static int i915_drm_resume(struct drm_device *dev)
>
> disable_rpm_wakeref_asserts(_priv->runtime_pm);
>
> - ret = intel_pcode_init(dev_priv);
> + ret = intel_gt_pcode_init(dev_priv);
I didn't like we have this indirection i915 -> gt -> i915...
At the same time I understand you don't want to duplicate the for_each with
the error msg and all in here.
So, what about having in this file a
static int __init_pcode(dev_priv)
?!
> if (ret)
> return ret;
>
> diff --git a/drivers/gpu/drm/i915/intel_pcode.c
> b/drivers/gpu/drm/i915/intel_pcode.c
> index ac727546868e..66020b2e461f 100644
> --- a/drivers/gpu/drm/i915/intel_pcode.c
> +++ b/drivers/gpu/drm/i915/intel_pcode.c
> @@ -52,14 +52,12 @@ static int gen7_check_mailbox_status(u32 mbox)
> }
> }
>
> -static int __snb_pcode_rw(struct drm_i915_private *i915, u32 mbox,
> +static int intel_pcode_rw(struct intel_uncore *uncore, u32 mbox,
I'm not sure if I like the idea of the renaming here...
I mean, it looks nicer indeed, but at the same time the "intel_"
make it looks it is exported one.
> u32 *val, u32 *val1,
> int fast_timeout_us, int slow_timeout_ms,
> bool is_read)
> {
> - struct intel_uncore *uncore = >uncore;
> -
> - lockdep_assert_held(>sb_lock);
> + lockdep_assert_held(>i915->sb_lock);
>
> /*
>* GEN6_PCODE_* are outside of the forcewake domain, we can use
> @@ -88,22 +86,22 @@ static int __snb_pcode_rw(struct drm_i915_private *i915,
> u32 mbox,
> if (is_read && val1)
> *val1 = intel_uncore_read_fw(uncore, GEN6_PCODE_DATA1);
>
> - if (GRAPHICS_VER(i915) > 6)
> + if (GRAPHICS_VER(uncore->i915) > 6)
> return gen7_check_mailbox_status(mbox);
> else
> return
Re: [Intel-gfx] [PATCH 9/9] drm/i915/gt: Expose default value for media_freq_factor in per-gt sysfs
On Thu, Apr 28, 2022 at 05:39:43PM -0700, Ashutosh Dixit wrote:
> Add the following sysfs file to gt/gtN/.defaults:
> * media_freq_factor
>
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Signed-off-by: Ashutosh Dixit
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 18 ++
> drivers/gpu/drm/i915/gt/intel_gt_types.h| 1 +
> drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 2 ++
> 3 files changed, 21 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
> b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
> index bbf49613ecd0..3c84731e0eca 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
> @@ -759,6 +759,18 @@ default_boost_freq_mhz_show(struct kobject *kobj, struct
> kobj_attribute *attr, c
> static struct kobj_attribute default_boost_freq_mhz =
> __ATTR(rps_boost_freq_mhz, 0444, default_boost_freq_mhz_show, NULL);
>
> +static ssize_t
> +default_media_freq_factor_show(struct kobject *kobj, struct kobj_attribute
> *attr, char *buf)
> +{
> + struct intel_gt *gt = kobj_to_gt(kobj->parent);
> +
> + return sysfs_emit(buf, "%d\n",
> +
> media_ratio_mode_to_factor(gt->rps_defaults.media_ratio_mode));
> +}
> +
> +static struct kobj_attribute default_media_freq_factor =
> +__ATTR(media_freq_factor, 0444, default_media_freq_factor_show, NULL);
> +
> static const struct attribute * const rps_defaults_attrs[] = {
> _min_freq_mhz.attr,
> _max_freq_mhz.attr,
> @@ -819,6 +831,12 @@ void intel_gt_sysfs_pm_init(struct intel_gt *gt, struct
> kobject *kobj)
> drm_warn(>i915->drm,
>"failed to create add gt%u
> media_perf_power_attrs sysfs (%pe)\n",
>gt->info.id, ERR_PTR(ret));
> +
> + ret = sysfs_create_file(gt->sysfs_defaults,
> _media_freq_factor.attr);
> + if (ret)
> + drm_warn(>i915->drm,
> + "failed to add gt%u default_media_freq_factor
> sysfs (%pe)\n",
> + gt->info.id, ERR_PTR(ret));
> }
>
> ret = add_rps_defaults(gt);
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> index 8b696669b846..07d368ca78ca 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> @@ -66,6 +66,7 @@ struct intel_rps_defaults {
> u32 min_freq;
> u32 max_freq;
> u32 boost_freq;
> + u32 media_ratio_mode;
> };
>
> enum intel_submission_method {
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
> index cefd864c84eb..047c80838fcd 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
> @@ -260,7 +260,9 @@ int intel_guc_slpc_init(struct intel_guc_slpc *slpc)
> slpc->boost_freq = 0;
> atomic_set(>num_waiters, 0);
> slpc->num_boosts = 0;
> +
> slpc->media_ratio_mode = SLPC_MEDIA_RATIO_MODE_DYNAMIC_CONTROL;
> + slpc_to_gt(slpc)->rps_defaults.media_ratio_mode =
> slpc->media_ratio_mode;
>
> mutex_init(>lock);
> INIT_WORK(>boost_work, slpc_boost_work);
> --
> 2.34.1
>
Re: [Intel-gfx] [PATCH 8/9] drm/i915/gt: Expose per-gt RPS defaults in sysfs
On Thu, Apr 28, 2022 at 05:39:42PM -0700, Ashutosh Dixit wrote:
> Create a gt/gtN/.defaults directory (similar to
> engine//.defaults) to expose default parameter values for each
> gt in sysfs. Populate the .defaults directory with RPS parameter default
> values in order to allow userspace to revert to default values when needed.
>
> This patch adds the following sysfs files to gt/gtN/.defaults:
> * default_min_freq_mhz
> * default_max_freq_mhz
> * default_boost_freq_mhz
>
> Cc: Rodrigo Vivi
> Cc: Andi Shyti
> Cc: Joonas Lahtinen
> Signed-off-by: Ashutosh Dixit
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/gt/intel_gt_sysfs.c| 10 ++--
> drivers/gpu/drm/i915/gt/intel_gt_sysfs.h| 6 +++
> drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 51 +
> drivers/gpu/drm/i915/gt/intel_gt_types.h| 10
> drivers/gpu/drm/i915/gt/intel_rps.c | 3 ++
> drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 17 +--
> 6 files changed, 87 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
> b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
> index 9e4ebf53379b..d651ccd0ab20 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
> @@ -22,11 +22,6 @@ bool is_object_gt(struct kobject *kobj)
> return !strncmp(kobj->name, "gt", 2);
> }
>
> -static struct intel_gt *kobj_to_gt(struct kobject *kobj)
> -{
> - return container_of(kobj, struct intel_gt, sysfs_gt);
> -}
> -
> struct intel_gt *intel_gt_sysfs_get_drvdata(struct device *dev,
> const char *name)
> {
> @@ -101,6 +96,10 @@ void intel_gt_sysfs_register(struct intel_gt *gt)
>gt->i915->sysfs_gt, "gt%d", gt->info.id))
> goto exit_fail;
>
> + gt->sysfs_defaults = kobject_create_and_add(".defaults", >sysfs_gt);
> + if (!gt->sysfs_defaults)
> + goto exit_fail;
> +
> intel_gt_sysfs_pm_init(gt, >sysfs_gt);
>
> return;
> @@ -113,5 +112,6 @@ void intel_gt_sysfs_register(struct intel_gt *gt)
>
> void intel_gt_sysfs_unregister(struct intel_gt *gt)
> {
> + kobject_put(gt->sysfs_defaults);
> kobject_put(>sysfs_gt);
> }
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
> index a99aa7e8b01a..6232923a420d 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
> @@ -10,6 +10,7 @@
> #include
>
> #include "i915_gem.h" /* GEM_BUG_ON() */
> +#include "intel_gt_types.h"
>
> struct intel_gt;
>
> @@ -22,6 +23,11 @@ intel_gt_create_kobj(struct intel_gt *gt,
>struct kobject *dir,
>const char *name);
>
> +static inline struct intel_gt *kobj_to_gt(struct kobject *kobj)
> +{
> + return container_of(kobj, struct intel_gt, sysfs_gt);
> +}
> +
> void intel_gt_sysfs_register(struct intel_gt *gt);
> void intel_gt_sysfs_unregister(struct intel_gt *gt);
> struct intel_gt *intel_gt_sysfs_get_drvdata(struct device *dev,
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
> b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
> index 1ec791239a65..bbf49613ecd0 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
> @@ -726,6 +726,51 @@ static const struct attribute *media_perf_power_attrs[]
> = {
> NULL
> };
>
> +static ssize_t
> +default_min_freq_mhz_show(struct kobject *kobj, struct kobj_attribute *attr,
> char *buf)
> +{
> + struct intel_gt *gt = kobj_to_gt(kobj->parent);
> +
> + return sysfs_emit(buf, "%d\n", gt->rps_defaults.min_freq);
> +}
> +
> +static struct kobj_attribute default_min_freq_mhz =
> +__ATTR(rps_min_freq_mhz, 0444, default_min_freq_mhz_show, NULL);
> +
> +static ssize_t
> +default_max_freq_mhz_show(struct kobject *kobj, struct kobj_attribute *attr,
> char *buf)
> +{
> + struct intel_gt *gt = kobj_to_gt(kobj->parent);
> +
> + return sysfs_emit(buf, "%d\n", gt->rps_defaults.max_freq);
> +}
> +
> +static struct kobj_attribute default_max_freq_mhz =
> +__ATTR(rps_max_freq_mhz, 0444, default_max_freq_mhz_show, NULL);
> +
> +static ssize_t
> +default_boost_freq_mhz_show(struct kobject *kobj, struct kobj_attribute
> *attr, char *buf)
> +{
> + struct intel_gt *gt = kobj_to_gt(kobj->parent);
> +
> + return sysfs_emit(buf, "%d\n", gt->rps_defaults.boost_freq);
> +}
> +
> +static struct kobj_attribute default_boost_freq_mhz =
> +__ATTR(rps_boost_freq_mhz, 0444, default_boost_freq_mhz_show, NULL);
> +
> +static const struct attribute * const rps_defaults_attrs[] = {
> + _min_freq_mhz.attr,
> + _max_freq_mhz.attr,
> + _boost_freq_mhz.attr,
> + NULL
> +};
> +
> +static int add_rps_defaults(struct intel_gt *gt)
> +{
> + return sysfs_create_files(gt->sysfs_defaults, rps_defaults_attrs);
> +}
> +
> static int intel_sysfs_rps_init(struct intel_gt *gt,
Re: [Intel-gfx] [PATCH 2/3] drm/i915/selftests: Skip poisoning SET_PREDICATE_RESULT on dg2
On Mon, 25 Apr 2022 at 16:22, Ramalingam C wrote: > > From: Chris Wilson > > When predication is enabled all commands baring a few (such as MI_BB_END) > are nop'ed. If we accidentally enable predication while poisoning the > context, not only is the rest of the poisoning skipped (thus disabling > the test), but the closing instructions of the poison request are > nop'ed. Not only do we then not signal the waiting context, but we even > prevent re-enabling arbitration and the GPU will not perform a context > switch at the end of the request. > > Cc: Joonas Lahtinen > Suggested-by: CQ Tang > Signed-off-by: Chris Wilson > Signed-off-by: Ramalingam C Reviewed-by: Matthew Auld
Re: [Intel-gfx] [PATCH 1/3] drm/i915/xehpsdv/dg1/tgl: Fix issue with LRI relative addressing
On Mon, 25 Apr 2022 at 16:22, Ramalingam C wrote: > > From: Akeem G Abodunrin > > When bit 19 of MI_LOAD_REGISTER_IMM instruction opcode is set on tgl+ > devices, HW does not care about certain register address offsets, but > instead check the following for valid address ranges on specific engines: > RCS && CCS: BITS(0 - 10) > BCS: BITS(0 - 11) > VECS && VCS: BITS(0 - 13) > Also, tgl+ now support relative addressing for BCS engine - So, this > patch fixes issue with live_gt_lrc selftest that is failing where there is > mismatch between LRC register layout generated during init and HW > default register offsets. > > Signed-off-by: Akeem G Abodunrin > cc: Prathap Kumar Valsan > Signed-off-by: Ramalingam C Reviewed-by: Matthew Auld
Re: [Intel-gfx] [PATCH 1/2] drm/edid: fix kernel-doc parameter name mismatches
On Tue, 26 Apr 2022, Jani Nikula wrote: > Fix the below drm/edid kernel-doc warnings: > > drivers/gpu/drm/drm_edid.c:1589: warning: Function parameter or member > '_edid' not described in 'drm_edid_header_is_valid' > drivers/gpu/drm/drm_edid.c:1589: warning: Excess function parameter > 'raw_edid' description in 'drm_edid_header_is_valid' > drivers/gpu/drm/drm_edid.c:1737: warning: Function parameter or member > '_block' not described in 'drm_edid_block_valid' > drivers/gpu/drm/drm_edid.c:1737: warning: Excess function parameter > 'raw_edid' description in 'drm_edid_block_valid' > drivers/gpu/drm/drm_edid.c:2136: warning: Function parameter or member > 'read_block' not described in 'drm_do_get_edid' > drivers/gpu/drm/drm_edid.c:2136: warning: Function parameter or member > 'context' not described in 'drm_do_get_edid' > drivers/gpu/drm/drm_edid.c:2136: warning: Excess function parameter > 'get_edid_block' description in 'drm_do_get_edid' > drivers/gpu/drm/drm_edid.c:2136: warning: Excess function parameter 'data' > description in 'drm_do_get_edid' > > Reported-by: Stephen Rothwell > References: https://lore.kernel.org/r/20220406154431.56741...@canb.auug.org.au > References: https://lore.kernel.org/r/20220420162431.2b28d...@canb.auug.org.au > Signed-off-by: Jani Nikula Pushed both to drm-misc-next with Simon's irc r-b. Thanks for the report & review. BR, Jani. > --- > drivers/gpu/drm/drm_edid.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c > index 7a8482b75071..6446f5d3944b 100644 > --- a/drivers/gpu/drm/drm_edid.c > +++ b/drivers/gpu/drm/drm_edid.c > @@ -1610,7 +1610,7 @@ static void edid_header_fix(void *edid) > > /** > * drm_edid_header_is_valid - sanity check the header of the base EDID block > - * @raw_edid: pointer to raw base EDID block > + * @_edid: pointer to raw base EDID block > * > * Sanity check the header of the base EDID block. > * > @@ -1827,7 +1827,7 @@ static void edid_block_dump(const char *level, const > void *block, int block_num) > > /** > * drm_edid_block_valid - Sanity check the EDID block (base or extension) > - * @raw_edid: pointer to raw EDID block > + * @_block: pointer to raw EDID block > * @block_num: type of block to validate (0 for base, extension otherwise) > * @print_bad_edid: if true, dump bad EDID blocks to the console > * @edid_corrupt: if true, the header or checksum is invalid > @@ -2112,8 +2112,8 @@ static enum edid_block_status edid_block_read(void > *block, unsigned int block_nu > /** > * drm_do_get_edid - get EDID data using a custom EDID block read function > * @connector: connector we're probing > - * @get_edid_block: EDID block read function > - * @data: private data passed to the block read function > + * @read_block: EDID block read function > + * @context: private data passed to the block read function > * > * When the I2C adapter connected to the DDC bus is hidden behind a device > that > * exposes a different interface to read EDID blocks this function can be > used -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PULL] gvt-next-2022-04-29
On Thu, 28 Apr 2022, "Wang, Zhi A" wrote: > Hi folks: > > Here is the pull of gvt-next which fixes the compilation error and warnings > for the the GVT-g refactor patches: > > - Fix a compiling warning of non-static function only having one caller. > - Fix a potential NULL pointer reference in the code re-factor. > - Fix a compiling error when CONFIG_DRM_I915_DEBUG_RUNTIME_PM=n > > I also tried to apply this pull on the latest drm-inte-next and it succeeded > without error and warnings. Thanks again, pulled to drm-intel-next. BR, Jani. > > The following changes since commit 5e9ae5c47052e28a31fb4f55a6e735c28d4c3948: > > drm/i915/gvt: Add missing symbol export. (2022-04-26 04:18:43 -0400) > > are available in the Git repository at: > > https://github.com/intel/gvt-linux tags/gvt-next-2022-04-29 > > for you to fetch changes up to 419f8299ddad6070a6c95aaedf78e50265871f36: > > i915/gvt: Fix NULL pointer dereference in init_mmio_block_handlers > (2022-04-28 17:06:02 -0400) > > > gvt-next-2022-04-29 > > Introduce fixes from previous pull. > - Fix a compiling warning of non-static funtion only having one caller. > - Fix a potential NULL pointer reference in the code re-factor. > - Fix a compiling error when CONFIG_DRM_I915_DEBUG_RUNTIME_PM=n > > > Wan Jiabing (1): > i915/gvt: Fix NULL pointer dereference in init_mmio_block_handlers > > Zhi Wang (2): > drm/i915/gvt: Make intel_gvt_match_device() static > drm/i915/gvt: Fix the compiling error when > CONFIG_DRM_I915_DEBUG_RUNTIME_PM=n > > drivers/gpu/drm/i915/gvt/handlers.c | 4 ++-- > drivers/gpu/drm/i915/intel_gvt.c| 2 ++ > 2 files changed, 4 insertions(+), 2 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 1/2] module: add a function to add module references
On Fri, Apr 29, 2022 at 11:23:51AM +0100, Mauro Carvalho Chehab wrote: > Em Fri, 29 Apr 2022 12:10:07 +0200 > Greg KH escreveu: > > > On Fri, Apr 29, 2022 at 10:15:03AM +0100, Mauro Carvalho Chehab wrote: > > > HI Greg, > > > > > > Em Fri, 29 Apr 2022 10:30:33 +0200 > > > Greg KH escreveu: > > > > > > > On Fri, Apr 29, 2022 at 09:07:57AM +0100, Mauro Carvalho Chehab wrote: > > > > > Hi Daniel, > > > > > > > > > > Em Fri, 29 Apr 2022 09:54:10 +0200 > > > > > Daniel Vetter escreveu: > > > > > > > > > > > On Fri, Apr 29, 2022 at 07:31:15AM +0100, Mauro Carvalho Chehab > > > > > > wrote: > > > > > > > Sometimes, device drivers are bound using indirect references, > > > > > > > which is not visible when looking at /proc/modules or lsmod. > > > > > > > > > > > > > > Add a function to allow setting up module references for such > > > > > > > cases. > > > > > > > > > > > > > > Reviewed-by: Dan Williams > > > > > > > Signed-off-by: Mauro Carvalho Chehab > > > > > > > > > > > > This sounds like duct tape at the wrong level. We should have a > > > > > > device_link connecting these devices, and maybe device_link > > > > > > internally > > > > > > needs to make sure the respective driver modules stay around for > > > > > > long > > > > > > enough too. But open-coding this all over the place into every > > > > > > driver that > > > > > > has some kind of cross-driver dependency sounds terrible. > > > > > > > > > > > > Or maybe the bug is that the snd driver keeps accessing the > > > > > > hw/component > > > > > > side when that is just plain gone. Iirc there's still fundamental > > > > > > issues > > > > > > there on the sound side of things, which have been attempted to > > > > > > paper over > > > > > > by timeouts and stuff like that in the past instead of enforcing a > > > > > > hard > > > > > > link between the snd and i915 side. > > > > > > > > > > I agree with you that the device link between snd-hda and the DRM > > > > > driver > > > > > should properly handle unbinding on both directions. This is something > > > > > that require further discussions with ALSA and DRM people, and we > > > > > should > > > > > keep working on it. > > > > > > > > > > Yet, the binding between those drivers do exist, but, despite other > > > > > similar inter-driver bindings being properly reported by lsmod, this > > > > > one > > > > > is invisible for userspace. > > > > > > > > > > What this series does is to make such binding visible. As simple as > > > > > that. > > > > > > > > It also increases the reference count, and creates a user/kernel api > > > > with the symlinks, right? Will the reference count increase prevent the > > > > modules from now being unloadable? > > > > > > > > This feels like a very "weak" link between modules that should not be > > > > needed if reference counting is implemented properly (so that things are > > > > cleaned up in the correct order.) > > > > > > The refcount increment exists even without this patch, as > > > hda_component_master_bind() at sound/hda/hdac_component.c uses > > > try_module_get() when it creates the device link. > > > > Ok, then why shouldn't try_module_get() be creating this link instead of > > having to manually do it this way again? You don't want to have to go > > around and add this call to all users of that function, right? > > Works for me, but this is not a too trivial change, as the new > try_module_get() function will require two parameters, instead of one: > > - the module to be referenced; > - the module which will reference it. > > On trivial cases, one will be THIS_MODULE, but, in the specific case > of snd_hda, the binding is done via an ancillary routine under > snd_hda_core, but the actual binding happens at snd_hda_intel. For calls that want to increment a module reference on behalf of a different code segment than is calling it, create a new function so we can audit-the-heck out of those code paths as odds are, they are unsafe. For the normal code path, just turn try_module_get() into a macro that includes THIS_MODULE as part of it like we do for the driver register functions (see usb_register_driver() in include/linux/usb.h as an example of how to do that.) > Ok, we could add a __try_module_get() (or whatever other name that > would properly express what it does) with two parameters, and then > define try_module_get() as: > > #define try_module_get(mod) __try_module_get(mod, THIS_MODULE) Yes, that's the way forward. thanks, greg k-h
Re: [Intel-gfx] [PATCH 1/2] module: add a function to add module references
Em Fri, 29 Apr 2022 12:10:07 +0200 Greg KH escreveu: > On Fri, Apr 29, 2022 at 10:15:03AM +0100, Mauro Carvalho Chehab wrote: > > HI Greg, > > > > Em Fri, 29 Apr 2022 10:30:33 +0200 > > Greg KH escreveu: > > > > > On Fri, Apr 29, 2022 at 09:07:57AM +0100, Mauro Carvalho Chehab wrote: > > > > Hi Daniel, > > > > > > > > Em Fri, 29 Apr 2022 09:54:10 +0200 > > > > Daniel Vetter escreveu: > > > > > > > > > On Fri, Apr 29, 2022 at 07:31:15AM +0100, Mauro Carvalho Chehab > > > > > wrote: > > > > > > Sometimes, device drivers are bound using indirect references, > > > > > > which is not visible when looking at /proc/modules or lsmod. > > > > > > > > > > > > Add a function to allow setting up module references for such > > > > > > cases. > > > > > > > > > > > > Reviewed-by: Dan Williams > > > > > > Signed-off-by: Mauro Carvalho Chehab > > > > > > > > > > This sounds like duct tape at the wrong level. We should have a > > > > > device_link connecting these devices, and maybe device_link internally > > > > > needs to make sure the respective driver modules stay around for long > > > > > enough too. But open-coding this all over the place into every driver > > > > > that > > > > > has some kind of cross-driver dependency sounds terrible. > > > > > > > > > > Or maybe the bug is that the snd driver keeps accessing the > > > > > hw/component > > > > > side when that is just plain gone. Iirc there's still fundamental > > > > > issues > > > > > there on the sound side of things, which have been attempted to paper > > > > > over > > > > > by timeouts and stuff like that in the past instead of enforcing a > > > > > hard > > > > > link between the snd and i915 side. > > > > > > > > I agree with you that the device link between snd-hda and the DRM driver > > > > should properly handle unbinding on both directions. This is something > > > > that require further discussions with ALSA and DRM people, and we should > > > > keep working on it. > > > > > > > > Yet, the binding between those drivers do exist, but, despite other > > > > similar inter-driver bindings being properly reported by lsmod, this one > > > > is invisible for userspace. > > > > > > > > What this series does is to make such binding visible. As simple as > > > > that. > > > > > > It also increases the reference count, and creates a user/kernel api > > > with the symlinks, right? Will the reference count increase prevent the > > > modules from now being unloadable? > > > > > > This feels like a very "weak" link between modules that should not be > > > needed if reference counting is implemented properly (so that things are > > > cleaned up in the correct order.) > > > > The refcount increment exists even without this patch, as > > hda_component_master_bind() at sound/hda/hdac_component.c uses > > try_module_get() when it creates the device link. > > Ok, then why shouldn't try_module_get() be creating this link instead of > having to manually do it this way again? You don't want to have to go > around and add this call to all users of that function, right? Works for me, but this is not a too trivial change, as the new try_module_get() function will require two parameters, instead of one: - the module to be referenced; - the module which will reference it. On trivial cases, one will be THIS_MODULE, but, in the specific case of snd_hda, the binding is done via an ancillary routine under snd_hda_core, but the actual binding happens at snd_hda_intel. Ok, we could add a __try_module_get() (or whatever other name that would properly express what it does) with two parameters, and then define try_module_get() as: #define try_module_get(mod) __try_module_get(mod, THIS_MODULE) Would that work for you? Regards, Mauro
Re: [Intel-gfx] [PATCH 1/2] module: add a function to add module references
On Fri, Apr 29, 2022 at 10:15:03AM +0100, Mauro Carvalho Chehab wrote: > HI Greg, > > Em Fri, 29 Apr 2022 10:30:33 +0200 > Greg KH escreveu: > > > On Fri, Apr 29, 2022 at 09:07:57AM +0100, Mauro Carvalho Chehab wrote: > > > Hi Daniel, > > > > > > Em Fri, 29 Apr 2022 09:54:10 +0200 > > > Daniel Vetter escreveu: > > > > > > > On Fri, Apr 29, 2022 at 07:31:15AM +0100, Mauro Carvalho Chehab wrote: > > > > > Sometimes, device drivers are bound using indirect references, > > > > > which is not visible when looking at /proc/modules or lsmod. > > > > > > > > > > Add a function to allow setting up module references for such > > > > > cases. > > > > > > > > > > Reviewed-by: Dan Williams > > > > > Signed-off-by: Mauro Carvalho Chehab > > > > > > > > This sounds like duct tape at the wrong level. We should have a > > > > device_link connecting these devices, and maybe device_link internally > > > > needs to make sure the respective driver modules stay around for long > > > > enough too. But open-coding this all over the place into every driver > > > > that > > > > has some kind of cross-driver dependency sounds terrible. > > > > > > > > Or maybe the bug is that the snd driver keeps accessing the hw/component > > > > side when that is just plain gone. Iirc there's still fundamental issues > > > > there on the sound side of things, which have been attempted to paper > > > > over > > > > by timeouts and stuff like that in the past instead of enforcing a hard > > > > link between the snd and i915 side. > > > > > > I agree with you that the device link between snd-hda and the DRM driver > > > should properly handle unbinding on both directions. This is something > > > that require further discussions with ALSA and DRM people, and we should > > > keep working on it. > > > > > > Yet, the binding between those drivers do exist, but, despite other > > > similar inter-driver bindings being properly reported by lsmod, this one > > > is invisible for userspace. > > > > > > What this series does is to make such binding visible. As simple as that. > > > > > > > It also increases the reference count, and creates a user/kernel api > > with the symlinks, right? Will the reference count increase prevent the > > modules from now being unloadable? > > > > This feels like a very "weak" link between modules that should not be > > needed if reference counting is implemented properly (so that things are > > cleaned up in the correct order.) > > The refcount increment exists even without this patch, as > hda_component_master_bind() at sound/hda/hdac_component.c uses > try_module_get() when it creates the device link. Ok, then why shouldn't try_module_get() be creating this link instead of having to manually do it this way again? You don't want to have to go around and add this call to all users of that function, right? thanks, greg k-h
[Intel-gfx] [PATCH 2/2] drm/i915: Only setup private tmpfs mount when needed and fix logging
From: Tvrtko Ursulin
If i915 does not want to use huge pages there is a) no point in setting up
the private mount and b) should former fail, it is misleading to log THP
support is disabled in the caller, which does not even know if callee
tried to enable it.
Fix both by restructuring the flow in i915_gemfs_init and at the same time
note the failure to set it up in all cases.
Signed-off-by: Tvrtko Ursulin
Cc: Joonas Lahtinen
Cc: Matthew Auld
Cc: Eero Tamminen
---
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 11 +-
drivers/gpu/drm/i915/gem/i915_gemfs.c | 45 ++-
drivers/gpu/drm/i915/gem/i915_gemfs.h | 3 +-
3 files changed, 23 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index c2a3e388fcb4..955844f19193 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -671,17 +671,10 @@ i915_gem_object_create_shmem_from_data(struct
drm_i915_private *dev_priv,
static int init_shmem(struct intel_memory_region *mem)
{
- int err;
-
- err = i915_gemfs_init(mem->i915);
- if (err) {
- DRM_NOTE("Unable to create a private tmpfs mount, hugepage
support will be disabled(%d).\n",
-err);
- }
-
+ i915_gemfs_init(mem->i915);
intel_memory_region_set_name(mem, "system");
- return 0; /* Don't error, we can simply fallback to the kernel mnt */
+ return 0; /* We have fallback to the kernel mnt if gemfs init failed. */
}
static int release_shmem(struct intel_memory_region *mem)
diff --git a/drivers/gpu/drm/i915/gem/i915_gemfs.c
b/drivers/gpu/drm/i915/gem/i915_gemfs.c
index c5a6bbc842fc..46b9a17d6abc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gemfs.c
+++ b/drivers/gpu/drm/i915/gem/i915_gemfs.c
@@ -11,16 +11,11 @@
#include "i915_gemfs.h"
#include "i915_utils.h"
-int i915_gemfs_init(struct drm_i915_private *i915)
+void i915_gemfs_init(struct drm_i915_private *i915)
{
char huge_opt[] = "huge=within_size"; /* r/w */
struct file_system_type *type;
struct vfsmount *gemfs;
- char *opts;
-
- type = get_fs_type("tmpfs");
- if (!type)
- return -ENODEV;
/*
* By creating our own shmemfs mountpoint, we can pass in
@@ -34,29 +29,29 @@ int i915_gemfs_init(struct drm_i915_private *i915)
* regressions such a slow reads issue on Broadwell and Skylake.
*/
- opts = NULL;
- if (GRAPHICS_VER(i915) >= 11 || i915_vtd_active(i915)) {
- if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE)) {
- opts = huge_opt;
- drm_info(>drm,
-"Transparent Hugepage mode '%s'\n",
-opts);
- } else {
- drm_notice(>drm,
- "Transparent Hugepage support is recommended
for optimal performance%s\n",
- GRAPHICS_VER(i915) >= 11 ?
- " on this platform!" :
- " when IOMMU is enabled!");
- }
- }
+ if (GRAPHICS_VER(i915) < 11 && !i915_vtd_active(i915))
+ return;
+
+ if (!IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE))
+ goto err;
- gemfs = vfs_kern_mount(type, SB_KERNMOUNT, type->name, opts);
+ type = get_fs_type("tmpfs");
+ if (!type)
+ goto err;
+
+ gemfs = vfs_kern_mount(type, SB_KERNMOUNT, type->name, huge_opt);
if (IS_ERR(gemfs))
- return PTR_ERR(gemfs);
+ goto err;
i915->mm.gemfs = gemfs;
-
- return 0;
+ drm_info(>drm, "Using Transparent Hugepages\n");
+ return;
+
+err:
+ drm_notice(>drm,
+ "Transparent Hugepage support is recommended for optimal
performance%s\n",
+ GRAPHICS_VER(i915) >= 11 ? " on this platform!" :
+ " when IOMMU is enabled!");
}
void i915_gemfs_fini(struct drm_i915_private *i915)
diff --git a/drivers/gpu/drm/i915/gem/i915_gemfs.h
b/drivers/gpu/drm/i915/gem/i915_gemfs.h
index 2a1e59af3e4a..5d835e44c4f6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gemfs.h
+++ b/drivers/gpu/drm/i915/gem/i915_gemfs.h
@@ -9,8 +9,7 @@
struct drm_i915_private;
-int i915_gemfs_init(struct drm_i915_private *i915);
-
+void i915_gemfs_init(struct drm_i915_private *i915);
void i915_gemfs_fini(struct drm_i915_private *i915);
#endif
--
2.32.0
[Intel-gfx] [PATCH 1/2] drm/i915: Enable THP on Icelake and beyond
From: Tvrtko Ursulin
We have a statement from HW designers that the GPU read regression when
using 2M pages was fixed from Icelake onwards, which was also confirmed
by bencharking Eero did last year:
"""
When IOMMU is disabled, enabling THP causes following perf changes on
TGL-H (GT1):
10-15% SynMark Batch[0-3]
5-10% MemBW GPU texture, SynMark ShMapVsm
3-5% SynMark TerrainFly* + Geom* + Fill* + CSCloth + Batch4
1-3% GpuTest Triangle, SynMark TexMem* + DeferredAA + Batch[5-7]
+ few others
-7% MemBW GPU blend
In the above 3D benchmark names, * means all the variants of tests with
the same prefix. For example "SynMark TexMem*", means both TexMem128 &
TexMem512 tests in the synthetic (Intel internal) SynMark test suite.
In the (public, but proprietary) GfxBench & GLB(enchmark) test suites,
there are both onscreen and offscreen variants of each test. Unless
explicitly stated otherwise, numbers are for both variants.
All tests are run with FullHD monitor. All tests are fullscreen except
for GLB and GpuTest ones, which are run in 1/2 screen window (GpuTest
triangle is run both in fullscreen and 1/2 screen window).
"""
Since the only regression is MemBW GPU blend, against many more gains,
it sounds it is time to enable THP on Gen11+.
Signed-off-by: Tvrtko Ursulin
References: https://gitlab.freedesktop.org/drm/intel/-/issues/430
Cc: Joonas Lahtinen
Cc: Matthew Auld
Cc: Eero Tamminen
---
drivers/gpu/drm/i915/gem/i915_gemfs.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gemfs.c
b/drivers/gpu/drm/i915/gem/i915_gemfs.c
index ee87874e59dc..c5a6bbc842fc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gemfs.c
+++ b/drivers/gpu/drm/i915/gem/i915_gemfs.c
@@ -28,12 +28,14 @@ int i915_gemfs_init(struct drm_i915_private *i915)
*
* One example, although it is probably better with a per-file
* control, is selecting huge page allocations ("huge=within_size").
-* However, we only do so to offset the overhead of iommu lookups
-* due to bandwidth issues (slow reads) on Broadwell+.
+* However, we only do so on platforms which benefit from it, or to
+* offset the overhead of iommu lookups, where with latter it is a net
+* win even on platforms which would otherwise see some performance
+* regressions such a slow reads issue on Broadwell and Skylake.
*/
opts = NULL;
- if (i915_vtd_active(i915)) {
+ if (GRAPHICS_VER(i915) >= 11 || i915_vtd_active(i915)) {
if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE)) {
opts = huge_opt;
drm_info(>drm,
@@ -41,7 +43,10 @@ int i915_gemfs_init(struct drm_i915_private *i915)
opts);
} else {
drm_notice(>drm,
- "Transparent Hugepage support is recommended
for optimal performance when IOMMU is enabled!\n");
+ "Transparent Hugepage support is recommended
for optimal performance%s\n",
+ GRAPHICS_VER(i915) >= 11 ?
+ " on this platform!" :
+ " when IOMMU is enabled!");
}
}
--
2.32.0
Re: [Intel-gfx] [PATCH 1/2] module: add a function to add module references
HI Greg, Em Fri, 29 Apr 2022 10:30:33 +0200 Greg KH escreveu: > On Fri, Apr 29, 2022 at 09:07:57AM +0100, Mauro Carvalho Chehab wrote: > > Hi Daniel, > > > > Em Fri, 29 Apr 2022 09:54:10 +0200 > > Daniel Vetter escreveu: > > > > > On Fri, Apr 29, 2022 at 07:31:15AM +0100, Mauro Carvalho Chehab wrote: > > > > Sometimes, device drivers are bound using indirect references, > > > > which is not visible when looking at /proc/modules or lsmod. > > > > > > > > Add a function to allow setting up module references for such > > > > cases. > > > > > > > > Reviewed-by: Dan Williams > > > > Signed-off-by: Mauro Carvalho Chehab > > > > > > This sounds like duct tape at the wrong level. We should have a > > > device_link connecting these devices, and maybe device_link internally > > > needs to make sure the respective driver modules stay around for long > > > enough too. But open-coding this all over the place into every driver that > > > has some kind of cross-driver dependency sounds terrible. > > > > > > Or maybe the bug is that the snd driver keeps accessing the hw/component > > > side when that is just plain gone. Iirc there's still fundamental issues > > > there on the sound side of things, which have been attempted to paper over > > > by timeouts and stuff like that in the past instead of enforcing a hard > > > link between the snd and i915 side. > > > > I agree with you that the device link between snd-hda and the DRM driver > > should properly handle unbinding on both directions. This is something > > that require further discussions with ALSA and DRM people, and we should > > keep working on it. > > > > Yet, the binding between those drivers do exist, but, despite other > > similar inter-driver bindings being properly reported by lsmod, this one > > is invisible for userspace. > > > > What this series does is to make such binding visible. As simple as that. > > It also increases the reference count, and creates a user/kernel api > with the symlinks, right? Will the reference count increase prevent the > modules from now being unloadable? > > This feels like a very "weak" link between modules that should not be > needed if reference counting is implemented properly (so that things are > cleaned up in the correct order.) The refcount increment exists even without this patch, as hda_component_master_bind() at sound/hda/hdac_component.c uses try_module_get() when it creates the device link. This series won't change anything with that regards. The only difference is that it will now properly report userspace that snd-hda will be using something inside the DRM driver (basically, it uses the DRM driver to power-control the HDA hardware on modern CPU/GPUs). - Btw, this is not the only case where userspace invisible bindings between two driver happen within the Kernel. On media, DVB drivers attach the frontend/tuner drivers using I2C bus on a way where lsmod doesn't current report any dependencies. See, for instance, PCTV 290e driver (partial) dependency chain: $ lsmod Module Size Used by rc_pinnacle_pctv_hd16384 0 em28xx_rc 20480 0 tda18271 53248 1 cxd2820r 45056 1 em28xx_dvb 36864 0 dvb_core 155648 2 cxd2820r,em28xx_dvb em28xx106496 2 em28xx_rc,em28xx_dvb tveeprom 28672 1 em28xx videobuf2_vmalloc 20480 1 uvcvideo videobuf2_memops 20480 1 videobuf2_vmalloc videobuf2_common 69632 4 videobuf2_vmalloc,videobuf2_v4l2,uvcvideo,videobuf2_memops videodev 266240 4 videobuf2_v4l2,uvcvideo,videobuf2_common,em28xx mc 65536 6 videodev,videobuf2_v4l2,uvcvideo,dvb_core,videobuf2_common,em28xx In the above example, tda18271 is an I2C tuner driver which talks to the hardware via the I2C bus registered by the em28xx driver. It is loaded during em28xx probing time. Again, lsmod doesn't show such dependencies. One can't remove the tuner driver without first removing the em28xx driver, which is the one that increments its refcount. - Back to the snd-hda issue, the problem is not with refcount. It is, instead, to provide a way for userspace to know what's the correct order to remove/unbind modules. Regards, Mauro
Re: [Intel-gfx] [PATCH 0/1] Replace shmem memory region and object backend with TTM
On 27/04/2022 12:34, Adrian Larumbe wrote: This patch is an attempt at eliminating the old shmem memory region and GEM object backend, in favour of a TTM-based one that is able to manage objects placed on both system and local memory. Known issues: Many GPU hungs in machines of GEN <= 5. My assumption is this has something to do with a caching issues, but everywhere across the TTM backend code I've tried to handle object creation and getting its pages with the same set of caching and coherency properties as in the old shmem backend. Object passed to shmem_create_from_object somehow not being flushed after being written into at lrc_init_state. Seems thatwith the new backend and when pinning an intel_context, either i915_gem_object_pin_map is not creating a kernel mapping with the right caching properties or else flushing it afterwards doesn't do anything. This leads to a GPU hung because the engine's default state that is read with shmem_read doesn't reflect what had been written into it previously by vmap'ing the object's pages. The only workaround I could find was manually setting the shmem file's pages dirty and putting them back, but this looks hacky and wasteful for big BO's Aside, sounds like RFC would be the appropriate classification for the series. But anyway, the thing I need to mention - how is THP support in the TTM backend? If not there it is something we absolutely need to have in order to avoid serious perf regressions. It's the i915_gemfs_init call your patch removes. Even though you do leave the unused file dangling. Regards, Tvrtko Besides all this, I haven't yet implemented the pread callback for TTM object backend, as it seems CI's BAT test list doesn't include it. Adrian Larumbe (1): drm/i915: Replace shmem memory region and object backend with TTM drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 12 +- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 32 +- drivers/gpu/drm/i915/gem/i915_gem_object.h | 2 +- drivers/gpu/drm/i915/gem/i915_gem_phys.c | 5 +- drivers/gpu/drm/i915/gem/i915_gem_shmem.c| 397 +-- drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 212 +- drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 3 + drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 11 +- drivers/gpu/drm/i915/gt/shmem_utils.c| 64 ++- drivers/gpu/drm/i915/intel_memory_region.c | 7 +- 10 files changed, 333 insertions(+), 412 deletions(-)
Re: [Intel-gfx] [PATCH 1/1] drm/i915/guc: Convert ct buffer to iosys_map
On 28.04.2022 19:43, Siva Mullati wrote:
>
> On 14/04/22 17:41, Balasubramani Vivekanandan wrote:
> > On 04.04.2022 15:01, Mullati Siva wrote:
> >> From: Siva Mullati
> >>
> >> Convert CT commands and descriptors to use iosys_map rather
> >> than plain pointer and save it in the intel_guc_ct_buffer struct.
> >> This will help with ct_write and ct_read for cmd send and receive
> >> after the initialization by abstracting the IO vs system memory.
> >>
> >> Signed-off-by: Siva Mullati
> >> ---
> >> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 200 +-
> >> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 9 +-
> >> 2 files changed, 127 insertions(+), 82 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> >> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> >> index f01325cd1b62..64568dc90b05 100644
> >> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> >> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> >> @@ -44,6 +44,11 @@ static inline struct drm_device *ct_to_drm(struct
> >> intel_guc_ct *ct)
> >> #define CT_PROBE_ERROR(_ct, _fmt, ...) \
> >>i915_probe_error(ct_to_i915(ct), "CT: " _fmt, ##__VA_ARGS__)
> >>
> >> +#define ct_desc_read(desc_map_, field_) \
> >> + iosys_map_rd_field(desc_map_, 0, struct guc_ct_buffer_desc, field_)
> >> +#define ct_desc_write(desc_map_, field_, val_) \
> >> + iosys_map_wr_field(desc_map_, 0, struct guc_ct_buffer_desc, field_,
> >> val_)
> >> +
> > Did you try to make the change Lucas mentioned in his comment on rev0,
> > to pass `struct guc_ct_buffer_desc *` as first argument to the above
> > macros? Was it not feasible?
> It is not feasible.
> >> /**
> >> * DOC: CTB Blob
> >> *
> >> @@ -76,6 +81,11 @@ static inline struct drm_device *ct_to_drm(struct
> >> intel_guc_ct *ct)
> >> #define CTB_G2H_BUFFER_SIZE (4 * CTB_H2G_BUFFER_SIZE)
> >> #define G2H_ROOM_BUFFER_SIZE (CTB_G2H_BUFFER_SIZE / 4)
> >>
> >> +#define CTB_SEND_DESC_OFFSET 0u
> >> +#define CTB_RECV_DESC_OFFSET (CTB_DESC_SIZE)
> >> +#define CTB_SEND_CMDS_OFFSET (2 * CTB_DESC_SIZE)
> >> +#define CTB_RECV_CMDS_OFFSET (2 * CTB_DESC_SIZE +
> >> CTB_H2G_BUFFER_SIZE)
> >> +
> >> struct ct_request {
> >>struct list_head link;
> >>u32 fence;
> >> @@ -113,9 +123,9 @@ void intel_guc_ct_init_early(struct intel_guc_ct *ct)
> >>init_waitqueue_head(>wq);
> >> }
> >>
> >> -static void guc_ct_buffer_desc_init(struct guc_ct_buffer_desc *desc)
> >> +static void guc_ct_buffer_desc_init(struct iosys_map *desc)
> >> {
> >> - memset(desc, 0, sizeof(*desc));
> >> + iosys_map_memset(desc, 0, 0, sizeof(struct guc_ct_buffer_desc));
> >> }
> >>
> >> static void guc_ct_buffer_reset(struct intel_guc_ct_buffer *ctb)
> >> @@ -128,17 +138,18 @@ static void guc_ct_buffer_reset(struct
> >> intel_guc_ct_buffer *ctb)
> >>space = CIRC_SPACE(ctb->tail, ctb->head, ctb->size) - ctb->resv_space;
> >>atomic_set(>space, space);
> >>
> >> - guc_ct_buffer_desc_init(ctb->desc);
> >> + guc_ct_buffer_desc_init(>desc_map);
> >> }
> >>
> >> static void guc_ct_buffer_init(struct intel_guc_ct_buffer *ctb,
> >> - struct guc_ct_buffer_desc *desc,
> >> - u32 *cmds, u32 size_in_bytes, u32 resv_space)
> >> + struct iosys_map *desc,
> >> + struct iosys_map *cmds,
> >> + u32 size_in_bytes, u32 resv_space)
> >> {
> >>GEM_BUG_ON(size_in_bytes % 4);
> >>
> >> - ctb->desc = desc;
> >> - ctb->cmds = cmds;
> >> + ctb->desc_map = *desc;
> >> + ctb->cmds_map = *cmds;
> >>ctb->size = size_in_bytes / 4;
> >>ctb->resv_space = resv_space / 4;
> >>
> >> @@ -218,12 +229,13 @@ static int ct_register_buffer(struct intel_guc_ct
> >> *ct, bool send,
> >> int intel_guc_ct_init(struct intel_guc_ct *ct)
> >> {
> >>struct intel_guc *guc = ct_to_guc(ct);
> >> - struct guc_ct_buffer_desc *desc;
> >> + struct iosys_map blob_map;
> >> + struct iosys_map desc_map;
> >> + struct iosys_map cmds_map;
> >>u32 blob_size;
> >>u32 cmds_size;
> >>u32 resv_space;
> >>void *blob;
> >> - u32 *cmds;
> >>int err;
> >>
> >>err = i915_inject_probe_error(guc_to_gt(guc)->i915, -ENXIO);
> >> @@ -242,27 +254,35 @@ int intel_guc_ct_init(struct intel_guc_ct *ct)
> >>
> >>CT_DEBUG(ct, "base=%#x size=%u\n", intel_guc_ggtt_offset(guc, ct->vma),
> >> blob_size);
> >>
> >> - /* store pointers to desc and cmds for send ctb */
> >> - desc = blob;
> >> - cmds = blob + 2 * CTB_DESC_SIZE;
> >> + if (i915_gem_object_is_lmem(ct->vma->obj))
> >> + iosys_map_set_vaddr_iomem(_map,
> >> +(void __iomem *)blob);
> >> + else
> >> + iosys_map_set_vaddr(_map, blob);
> >> +
> >> + /* store sysmap to desc_map and cmds_map for send ctb */
> >> + desc_map = IOSYS_MAP_INIT_OFFSET(_map, CTB_SEND_DESC_OFFSET);
> >> + cmds_map = IOSYS_MAP_INIT_OFFSET(_map,
[Intel-gfx] ✓ Fi.CI.IGT: success for Let userspace know when snd-hda-intel needs i915
== Series Details ==
Series: Let userspace know when snd-hda-intel needs i915
URL : https://patchwork.freedesktop.org/series/103315/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11550_full -> Patchwork_103315v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (10 -> 13)
--
Additional (3): shard-rkl shard-dg1 shard-tglu
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_103315v1_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_suspend@basic-s0@smem:
- {shard-dg1}:NOTRUN -> [INCOMPLETE][1] +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-dg1-12/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@mock@hugepages:
- {shard-rkl}:NOTRUN -> [INCOMPLETE][2]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-rkl-5/igt@i915_selftest@m...@hugepages.html
* {igt@kms_concurrent@pipe-d@hdmi-a-3}:
- {shard-dg1}:NOTRUN -> [CRASH][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-dg1-18/igt@kms_concurrent@pip...@hdmi-a-3.html
New tests
-
New tests have been introduced between CI_DRM_11550_full and
Patchwork_103315v1_full:
### New IGT tests (4) ###
* igt@kms_sequence@get-busy@hdmi-a-3-pipe-a:
- Statuses : 1 pass(s)
- Exec time: [2.43] s
* igt@kms_sequence@get-busy@hdmi-a-3-pipe-b:
- Statuses : 1 pass(s)
- Exec time: [2.38] s
* igt@kms_sequence@get-busy@hdmi-a-3-pipe-c:
- Statuses : 1 pass(s)
- Exec time: [2.38] s
* igt@kms_sequence@get-busy@hdmi-a-3-pipe-d:
- Statuses : 1 pass(s)
- Exec time: [2.39] s
Known issues
Here are the changes found in Patchwork_103315v1_full that come from known
issues:
### CI changes ###
Possible fixes
* boot:
- shard-skl: ([PASS][4], [PASS][5], [PASS][6], [PASS][7],
[PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13],
[PASS][14], [PASS][15], [FAIL][16], [PASS][17], [PASS][18], [PASS][19],
[PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25],
[PASS][26], [PASS][27]) ([i915#5032]) -> ([PASS][28], [PASS][29], [PASS][30],
[PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36],
[PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42],
[PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48],
[PASS][49], [PASS][50], [PASS][51])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl9/boot.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl9/boot.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl8/boot.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl8/boot.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl7/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl7/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl6/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl6/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl6/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl4/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl4/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl4/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl3/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl3/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl2/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl2/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl1/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl1/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl10/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl10/boot.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-skl1/boot.html
[29]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-skl10/boot.html
[30]:
Re: [Intel-gfx] [PATCH 1/2] module: add a function to add module references
On Fri, Apr 29, 2022 at 09:07:57AM +0100, Mauro Carvalho Chehab wrote: > Hi Daniel, > > Em Fri, 29 Apr 2022 09:54:10 +0200 > Daniel Vetter escreveu: > > > On Fri, Apr 29, 2022 at 07:31:15AM +0100, Mauro Carvalho Chehab wrote: > > > Sometimes, device drivers are bound using indirect references, > > > which is not visible when looking at /proc/modules or lsmod. > > > > > > Add a function to allow setting up module references for such > > > cases. > > > > > > Reviewed-by: Dan Williams > > > Signed-off-by: Mauro Carvalho Chehab > > > > This sounds like duct tape at the wrong level. We should have a > > device_link connecting these devices, and maybe device_link internally > > needs to make sure the respective driver modules stay around for long > > enough too. But open-coding this all over the place into every driver that > > has some kind of cross-driver dependency sounds terrible. > > > > Or maybe the bug is that the snd driver keeps accessing the hw/component > > side when that is just plain gone. Iirc there's still fundamental issues > > there on the sound side of things, which have been attempted to paper over > > by timeouts and stuff like that in the past instead of enforcing a hard > > link between the snd and i915 side. > > I agree with you that the device link between snd-hda and the DRM driver > should properly handle unbinding on both directions. This is something > that require further discussions with ALSA and DRM people, and we should > keep working on it. > > Yet, the binding between those drivers do exist, but, despite other > similar inter-driver bindings being properly reported by lsmod, this one > is invisible for userspace. > > What this series does is to make such binding visible. As simple as that. It also increases the reference count, and creates a user/kernel api with the symlinks, right? Will the reference count increase prevent the modules from now being unloadable? This feels like a very "weak" link between modules that should not be needed if reference counting is implemented properly (so that things are cleaned up in the correct order.) Please don't paper over the real issue with this hack. thanks, greg k-h
Re: [Intel-gfx] [PATCH 1/2] module: add a function to add module references
Hi Daniel,
Em Fri, 29 Apr 2022 09:54:10 +0200
Daniel Vetter escreveu:
> On Fri, Apr 29, 2022 at 07:31:15AM +0100, Mauro Carvalho Chehab wrote:
> > Sometimes, device drivers are bound using indirect references,
> > which is not visible when looking at /proc/modules or lsmod.
> >
> > Add a function to allow setting up module references for such
> > cases.
> >
> > Reviewed-by: Dan Williams
> > Signed-off-by: Mauro Carvalho Chehab
>
> This sounds like duct tape at the wrong level. We should have a
> device_link connecting these devices, and maybe device_link internally
> needs to make sure the respective driver modules stay around for long
> enough too. But open-coding this all over the place into every driver that
> has some kind of cross-driver dependency sounds terrible.
>
> Or maybe the bug is that the snd driver keeps accessing the hw/component
> side when that is just plain gone. Iirc there's still fundamental issues
> there on the sound side of things, which have been attempted to paper over
> by timeouts and stuff like that in the past instead of enforcing a hard
> link between the snd and i915 side.
I agree with you that the device link between snd-hda and the DRM driver
should properly handle unbinding on both directions. This is something
that require further discussions with ALSA and DRM people, and we should
keep working on it.
Yet, the binding between those drivers do exist, but, despite other
similar inter-driver bindings being properly reported by lsmod, this one
is invisible for userspace.
What this series does is to make such binding visible. As simple as that.
>
> Adding Greg for device model questions like this.
> -Daniel
>
> > ---
> >
> > See [PATCH 0/2] at:
> > https://lore.kernel.org/all/cover.1651212016.git.mche...@kernel.org/
> >
> > include/linux/module.h | 7 +++
> > kernel/module/main.c | 31 +++
> > 2 files changed, 38 insertions(+)
> >
> > diff --git a/include/linux/module.h b/include/linux/module.h
> > index 46d4d5f2516e..be74f807e41d 100644
> > --- a/include/linux/module.h
> > +++ b/include/linux/module.h
> > @@ -596,6 +596,8 @@ static inline bool within_module(unsigned long addr,
> > const struct module *mod)
> > /* Search for module by name: must be in a RCU-sched critical section. */
> > struct module *find_module(const char *name);
> >
> > +int module_add_named_dependency(const char *name, struct module *this);
> > +
> > /* Returns 0 and fills in value, defined and namebuf, or -ERANGE if
> > symnum out of range. */
> > int module_get_kallsym(unsigned int symnum, unsigned long *value, char
> > *type,
> > @@ -772,6 +774,11 @@ static inline int lookup_module_symbol_attrs(unsigned
> > long addr, unsigned long *
> > return -ERANGE;
> > }
> >
> > +static inline int module_add_named_dependency(const char *name, struct
> > module *this)
> > +{
> > + return 0;
> > +}
> > +
> > static inline int module_get_kallsym(unsigned int symnum, unsigned long
> > *value,
> > char *type, char *name,
> > char *module_name, int *exported)
> > diff --git a/kernel/module/main.c b/kernel/module/main.c
> > index 05a42d8fcd7a..dbd577ccc38c 100644
> > --- a/kernel/module/main.c
> > +++ b/kernel/module/main.c
> > @@ -631,6 +631,37 @@ static int ref_module(struct module *a, struct module
> > *b)
> > return 0;
> > }
> >
> > +int module_add_named_dependency(const char *name, struct module *this)
> > +{
> > + struct module *mod;
> > + int ret;
> > +
> > + if (!name || !this || !this->name) {
> > + return -EINVAL;
> > + }
> > +
> > + mutex_lock(_mutex);
> > + mod = find_module(name);
> > + if (!mod) {
> > + ret = -EINVAL;
> > + goto ret;
> > + }
> > +
> > + ret = ref_module(this, mod);
> > + if (ret)
> > + goto ret;
> > +
> > +#ifdef CONFIG_MODULE_UNLOAD
> > + ret = sysfs_create_link(mod->holders_dir,
> > + >mkobj.kobj, this->name);
> > +#endif
> > +
> > +ret:
> > + mutex_unlock(_mutex);
> > + return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(module_add_named_dependency);
> > +
> > /* Clear the unload stuff of the module. */
> > static void module_unload_free(struct module *mod)
> > {
> > --
> > 2.35.1
> >
>
Re: [Intel-gfx] [PATCH 1/2] module: add a function to add module references
On Fri, Apr 29, 2022 at 07:31:15AM +0100, Mauro Carvalho Chehab wrote:
> Sometimes, device drivers are bound using indirect references,
> which is not visible when looking at /proc/modules or lsmod.
>
> Add a function to allow setting up module references for such
> cases.
>
> Reviewed-by: Dan Williams
> Signed-off-by: Mauro Carvalho Chehab
This sounds like duct tape at the wrong level. We should have a
device_link connecting these devices, and maybe device_link internally
needs to make sure the respective driver modules stay around for long
enough too. But open-coding this all over the place into every driver that
has some kind of cross-driver dependency sounds terrible.
Or maybe the bug is that the snd driver keeps accessing the hw/component
side when that is just plain gone. Iirc there's still fundamental issues
there on the sound side of things, which have been attempted to paper over
by timeouts and stuff like that in the past instead of enforcing a hard
link between the snd and i915 side.
Adding Greg for device model questions like this.
-Daniel
> ---
>
> See [PATCH 0/2] at:
> https://lore.kernel.org/all/cover.1651212016.git.mche...@kernel.org/
>
> include/linux/module.h | 7 +++
> kernel/module/main.c | 31 +++
> 2 files changed, 38 insertions(+)
>
> diff --git a/include/linux/module.h b/include/linux/module.h
> index 46d4d5f2516e..be74f807e41d 100644
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -596,6 +596,8 @@ static inline bool within_module(unsigned long addr,
> const struct module *mod)
> /* Search for module by name: must be in a RCU-sched critical section. */
> struct module *find_module(const char *name);
>
> +int module_add_named_dependency(const char *name, struct module *this);
> +
> /* Returns 0 and fills in value, defined and namebuf, or -ERANGE if
> symnum out of range. */
> int module_get_kallsym(unsigned int symnum, unsigned long *value, char *type,
> @@ -772,6 +774,11 @@ static inline int lookup_module_symbol_attrs(unsigned
> long addr, unsigned long *
> return -ERANGE;
> }
>
> +static inline int module_add_named_dependency(const char *name, struct
> module *this)
> +{
> + return 0;
> +}
> +
> static inline int module_get_kallsym(unsigned int symnum, unsigned long
> *value,
> char *type, char *name,
> char *module_name, int *exported)
> diff --git a/kernel/module/main.c b/kernel/module/main.c
> index 05a42d8fcd7a..dbd577ccc38c 100644
> --- a/kernel/module/main.c
> +++ b/kernel/module/main.c
> @@ -631,6 +631,37 @@ static int ref_module(struct module *a, struct module *b)
> return 0;
> }
>
> +int module_add_named_dependency(const char *name, struct module *this)
> +{
> + struct module *mod;
> + int ret;
> +
> + if (!name || !this || !this->name) {
> + return -EINVAL;
> + }
> +
> + mutex_lock(_mutex);
> + mod = find_module(name);
> + if (!mod) {
> + ret = -EINVAL;
> + goto ret;
> + }
> +
> + ret = ref_module(this, mod);
> + if (ret)
> + goto ret;
> +
> +#ifdef CONFIG_MODULE_UNLOAD
> + ret = sysfs_create_link(mod->holders_dir,
> + >mkobj.kobj, this->name);
> +#endif
> +
> +ret:
> + mutex_unlock(_mutex);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(module_add_named_dependency);
> +
> /* Clear the unload stuff of the module. */
> static void module_unload_free(struct module *mod)
> {
> --
> 2.35.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[Intel-gfx] ✓ Fi.CI.BAT: success for Let userspace know when snd-hda-intel needs i915
== Series Details ==
Series: Let userspace know when snd-hda-intel needs i915
URL : https://patchwork.freedesktop.org/series/103315/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11550 -> Patchwork_103315v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/index.html
Participating hosts (43 -> 43)
--
Additional (2): bat-dg1-6 bat-adlp-4
Missing(2): fi-kbl-soraka fi-bsw-cyan
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_103315v1:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@gt_heartbeat:
- {fi-tgl-dsi}: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-tgl-dsi/igt@i915_selftest@live@gt_heartbeat.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/fi-tgl-dsi/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@vma:
- {bat-rpls-1}: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/bat-rpls-1/igt@i915_selftest@l...@vma.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/bat-rpls-1/igt@i915_selftest@l...@vma.html
Known issues
Here are the changes found in Patchwork_103315v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s0@smem:
- bat-dg1-6: NOTRUN -> [INCOMPLETE][5] ([i915#5827])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/bat-dg1-6/igt@gem_exec_suspend@basic...@smem.html
* igt@gem_lmem_swapping@basic:
- bat-adlp-4: NOTRUN -> [SKIP][6] ([i915#4613]) +3 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/bat-adlp-4/igt@gem_lmem_swapp...@basic.html
* igt@gem_tiled_pread_basic:
- bat-adlp-4: NOTRUN -> [SKIP][7] ([i915#3282])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/bat-adlp-4/igt@gem_tiled_pread_basic.html
* igt@i915_pm_rpm@module-reload:
- bat-adlp-4: NOTRUN -> [DMESG-WARN][8] ([i915#3576]) +3 similar
issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/bat-adlp-4/igt@i915_pm_...@module-reload.html
* igt@kms_chamelium@dp-crc-fast:
- bat-adlp-4: NOTRUN -> [SKIP][9] ([fdo#111827]) +8 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/bat-adlp-4/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-adlp-4: NOTRUN -> [SKIP][10] ([i915#4103]) +1 similar issue
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/bat-adlp-4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@kms_force_connector_basic@prune-stale-modes:
- bat-adlp-4: NOTRUN -> [SKIP][11] ([i915#4093]) +3 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/bat-adlp-4/igt@kms_force_connector_ba...@prune-stale-modes.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:
- fi-cfl-8109u: [PASS][12] -> [DMESG-WARN][13] ([i915#62]) +11
similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
* igt@kms_setmode@basic-clone-single-crtc:
- bat-adlp-4: NOTRUN -> [SKIP][14] ([i915#3555])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/bat-adlp-4/igt@kms_setm...@basic-clone-single-crtc.html
* igt@prime_vgem@basic-fence-read:
- bat-adlp-4: NOTRUN -> [SKIP][15] ([i915#3291] / [i915#3708]) +2
similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/bat-adlp-4/igt@prime_v...@basic-fence-read.html
* igt@prime_vgem@basic-userptr:
- bat-adlp-4: NOTRUN -> [SKIP][16] ([i915#3301] / [i915#3708])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/bat-adlp-4/igt@prime_v...@basic-userptr.html
Possible fixes
* igt@i915_module_load@reload:
- {bat-rpls-2}: [DMESG-WARN][17] ([i915#5537]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/bat-rpls-2/igt@i915_module_l...@reload.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/bat-rpls-2/igt@i915_module_l...@reload.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-cfl-guc: [DMESG-FAIL][19] ([i915#5334]) -> [PASS][20]
[19]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Let userspace know when snd-hda-intel needs i915
== Series Details == Series: Let userspace know when snd-hda-intel needs i915 URL : https://patchwork.freedesktop.org/series/103315/ 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 Let userspace know when snd-hda-intel needs i915
== Series Details ==
Series: Let userspace know when snd-hda-intel needs i915
URL : https://patchwork.freedesktop.org/series/103315/
State : warning
== Summary ==
Error: dim checkpatch failed
4f9130351583 module: add a function to add module references
-:53: WARNING:BRACES: braces {} are not necessary for single statement blocks
#53: FILE: kernel/module.c:838:
+ if (!name || !this || !this->name) {
+ return -EINVAL;
+ }
total: 0 errors, 1 warnings, 0 checks, 56 lines checked
488163eb8175 ALSA: hda - identify when audio is provided by a video driver
[Intel-gfx] [PATCH 2/2] ALSA: hda - identify when audio is provided by a video driver
On some devices, the hda driver needs to hook into a video driver,
in order to be able to properly access the audio hardware and/or
the power management function.
That's the case of several snd_hda_intel devices that depends on
i915 driver.
Currently, this dependency is hidden from /proc/modules and
from lsmod, making harder to identify the need to unbind the
audio driver before being able to unbind the i915 driver.
Add a reference for it at the module dependency, in order to
allow userspace to identify it, and print a message on such
cases.
Signed-off-by: Mauro Carvalho Chehab
---
See [PATCH 0/2] at:
https://lore.kernel.org/all/cover.1651212016.git.mche...@kernel.org/
sound/hda/hdac_component.c | 8
1 file changed, 8 insertions(+)
diff --git a/sound/hda/hdac_component.c b/sound/hda/hdac_component.c
index bb37e7e0bd79..103c6be8be1e 100644
--- a/sound/hda/hdac_component.c
+++ b/sound/hda/hdac_component.c
@@ -211,6 +211,14 @@ static int hdac_component_master_bind(struct device *dev)
}
complete_all(>master_bind_complete);
+
+ if (acomp->ops->owner && acomp->ops->owner->name) {
+ dev_info(dev, "audio component provided by %s driver\n",
+acomp->ops->owner->name);
+ module_add_named_dependency(acomp->ops->owner->name,
+ dev->driver->owner);
+ }
+
return 0;
module_put:
--
2.35.1
[Intel-gfx] [PATCH 1/2] module: add a function to add module references
Sometimes, device drivers are bound using indirect references,
which is not visible when looking at /proc/modules or lsmod.
Add a function to allow setting up module references for such
cases.
Reviewed-by: Dan Williams
Signed-off-by: Mauro Carvalho Chehab
---
See [PATCH 0/2] at:
https://lore.kernel.org/all/cover.1651212016.git.mche...@kernel.org/
include/linux/module.h | 7 +++
kernel/module/main.c | 31 +++
2 files changed, 38 insertions(+)
diff --git a/include/linux/module.h b/include/linux/module.h
index 46d4d5f2516e..be74f807e41d 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -596,6 +596,8 @@ static inline bool within_module(unsigned long addr, const
struct module *mod)
/* Search for module by name: must be in a RCU-sched critical section. */
struct module *find_module(const char *name);
+int module_add_named_dependency(const char *name, struct module *this);
+
/* Returns 0 and fills in value, defined and namebuf, or -ERANGE if
symnum out of range. */
int module_get_kallsym(unsigned int symnum, unsigned long *value, char *type,
@@ -772,6 +774,11 @@ static inline int lookup_module_symbol_attrs(unsigned long
addr, unsigned long *
return -ERANGE;
}
+static inline int module_add_named_dependency(const char *name, struct module
*this)
+{
+ return 0;
+}
+
static inline int module_get_kallsym(unsigned int symnum, unsigned long *value,
char *type, char *name,
char *module_name, int *exported)
diff --git a/kernel/module/main.c b/kernel/module/main.c
index 05a42d8fcd7a..dbd577ccc38c 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -631,6 +631,37 @@ static int ref_module(struct module *a, struct module *b)
return 0;
}
+int module_add_named_dependency(const char *name, struct module *this)
+{
+ struct module *mod;
+ int ret;
+
+ if (!name || !this || !this->name) {
+ return -EINVAL;
+ }
+
+ mutex_lock(_mutex);
+ mod = find_module(name);
+ if (!mod) {
+ ret = -EINVAL;
+ goto ret;
+ }
+
+ ret = ref_module(this, mod);
+ if (ret)
+ goto ret;
+
+#ifdef CONFIG_MODULE_UNLOAD
+ ret = sysfs_create_link(mod->holders_dir,
+ >mkobj.kobj, this->name);
+#endif
+
+ret:
+ mutex_unlock(_mutex);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(module_add_named_dependency);
+
/* Clear the unload stuff of the module. */
static void module_unload_free(struct module *mod)
{
--
2.35.1
[Intel-gfx] [PATCH 0/2] Let userspace know when snd-hda-intel needs i915
Currently, kernel/module annotates module dependencies when request_symbol is used, but it doesn't cover more complex inter-driver dependencies that are subsystem and/or driver-specific. In the case of hdmi sound, depending on the CPU/GPU, sometimes the snd_hda_driver can talk directly with the hardware, but sometimes, it uses the i915 driver. When the snd_hda_driver uses i915, it should first be unbind/rmmod, as otherwise trying to unbind/rmmod the i915 driver cause driver issues, as as reported by CI tools with different GPU models: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_6415/fi-tgl-1115g4/igt@core_hotunp...@unbind-rebind.html https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11495/bat-adlm-1/igt@i915_module_l...@reload.html In the past, just a few CPUs were doing such bindings, but this issue now applies to all "modern" Intel CPUs that have onboard graphics, as well as to the newer discrete GPUs. With the discrete GPU case, the HDA controller is physically separate and requires i915 to power on the hardware for all hardware access. In this case, the issue is hit basicly 100% of the time. With on-board graphics, i915 driver is needed only when the display codec is accessed. If i915 is unbind during runtime suspend, while snd-hda-intel is still bound, nothing bad happens, but unbinding i915 on other situations may also cause issues. So, add support at kernel/modules to allow snd-hda drivers to properly annotate when a dependency on a DRM driver dependencies exists, and add a call to such new function at the snd-hda driver when it successfully binds into the DRM driver. This would allow userspace tools to check and properly remove the audio driver before trying to remove or unbind the GPU driver. It should be noticed that this series conveys the hidden module dependencies. Other changes are needed in order to allow removing or unbinding the i915 driver while keeping the snd-hda-intel driver loaded/bound. With that regards, there are some discussions on how to improve this at alsa-devel a while back: https://mailman.alsa-project.org/pipermail/alsa-devel/2021-September/190099.html So, future improvements on both in i915 and the audio drivers could be made. E.g. with discrete GPUs, it's the only codec of the card, so it seems feasible to detach the ALSA card if i915 is bound (using infra made for VGA switcheroo), but, until these improvements are done and land in upstream, audio drivers needs to be unbound if i915 driver goes unbind. Yet, even if such fixes got merged, this series is still needed, as it makes such dependencies more explicit and easier to debug. PS.: This series was generated against next-20220428. Luis/Takashi/Daniel/David, If OK for you, I would prefer to have such patches applied via the drm-tip tree once reviewed, in order to make easier to use them by some patches I'm preparing to improve the CI tests that use i915 unbind logic. Mauro Carvalho Chehab (2): module: add a function to add module references ALSA: hda - identify when audio is provided by a video driver include/linux/module.h | 7 +++ kernel/module/main.c | 31 +++ sound/hda/hdac_component.c | 8 3 files changed, 46 insertions(+) -- 2.35.1
