Re: [Intel-gfx] [PATCH v2 0/2] drm/i915/gem: Really move i915_gem_context.link under ref protection
Please ignore this series, it has issues. I'll update it and resubmit. Thanks, Janusz On Thursday, 15 September 2022 18:52:08 CEST Janusz Krzysztofik wrote: > i915_perf assumes that it can use the i915_gem_context reference to > protect its i915->gem.contexts.list iteration. However, this requires > that we do not remove the context from the list until after we drop the > final reference and release the struct. If, as currently, we remove the > context from the list during context_close(), the link.next pointer may > be poisoned while we are holding the context reference and cause a GPF: > > [ 4070.573157] i915 :00:02.0: [drm:i915_perf_open_ioctl [i915]] filtering > on ctx_id=0x > 1f ctx_id_mask=0x1f > [ 4070.574881] general protection fault, probably for non-canonical address > 0xdead > 0100: [#1] PREEMPT SMP > [ 4070.574897] CPU: 1 PID: 284392 Comm: amd_performance Tainted: G > E 5.17.9 > #180 > [ 4070.574903] Hardware name: Intel Corporation NUC7i5BNK/NUC7i5BNB, BIOS > BNKBL357.86A.0052.2017.0918.1346 09/18/2017 > [ 4070.574907] RIP: 0010:oa_configure_all_contexts.isra.0+0x222/0x350 [i915] > [ 4070.574982] Code: 08 e8 32 6e 10 e1 4d 8b 6d 50 b8 ff ff ff ff 49 83 ed 50 > f0 41 0f c1 04 24 83 f8 01 0f 84 e3 00 00 00 85 c0 0f 8e fa 00 00 00 <49> 8b > 45 50 48 8d 70 b0 49 8d 45 50 48 39 44 24 10 0f 85 34 fe ff > [ 4070.574990] RSP: 0018:c90002077b78 EFLAGS: 00010202 > [ 4070.574995] RAX: 0002 RBX: 0002 RCX: > > [ 4070.575000] RDX: 0001 RSI: c90002077b20 RDI: > 88810ddc7c68 > [ 4070.575004] RBP: 0001 R08: 888103242648 R09: > fffc > [ 4070.575008] R10: 82c50bc0 R11: 00025c80 R12: > 888101bf1860 > [ 4070.575012] R13: dead00b0 R14: c90002077c04 R15: > 88810be5cabc > [ 4070.575016] FS: 7f1ed50c0780() GS:5ec8() > knlGS: > [ 4070.575021] CS: 0010 DS: ES: CR0: 80050033 > [ 4070.575025] CR2: 7f1ed5590280 CR3: 00010ef6f005 CR4: > 003706e0 > [ 4070.575029] Call Trace: > [ 4070.575033] > [ 4070.575037] lrc_configure_all_contexts+0x13e/0x150 [i915] > [ 4070.575103] gen8_enable_metric_set+0x4d/0x90 [i915] > [ 4070.575164] i915_perf_open_ioctl+0xbc0/0x1500 [i915] > [ 4070.575224] ? asm_common_interrupt+0x1e/0x40 > [ 4070.575232] ? i915_oa_init_reg_state+0x110/0x110 [i915] > [ 4070.575290] drm_ioctl_kernel+0x85/0x110 > [ 4070.575296] ? update_load_avg+0x5f/0x5e0 > [ 4070.575302] drm_ioctl+0x1d3/0x370 > [ 4070.575307] ? i915_oa_init_reg_state+0x110/0x110 [i915] > [ 4070.575382] ? gen8_gt_irq_handler+0x46/0x130 [i915] > [ 4070.575445] __x64_sys_ioctl+0x3c4/0x8d0 > [ 4070.575451] ? __do_softirq+0xaa/0x1d2 > [ 4070.575456] do_syscall_64+0x35/0x80 > [ 4070.575461] entry_SYSCALL_64_after_hwframe+0x44/0xae > [ 4070.575467] RIP: 0033:0x7f1ed5c10397 > [ 4070.575471] Code: 3c 1c e8 1c ff ff ff 85 c0 79 87 49 c7 c4 ff ff ff ff 5b > 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d > 01 f0 ff ff 73 01 c3 48 8b 0d a9 da 0d 00 f7 d8 64 89 01 48 > [ 4070.575478] RSP: 002b:7ffd65c8d7a8 EFLAGS: 0246 ORIG_RAX: > 0010 > [ 4070.575484] RAX: ffda RBX: 0006 RCX: > 7f1ed5c10397 > [ 4070.575488] RDX: 7ffd65c8d7c0 RSI: 40106476 RDI: > 0006 > [ 4070.575492] RBP: 5620972f9c60 R08: 000a R09: > 0005 > [ 4070.575496] R10: 000d R11: 0246 R12: > 000a > [ 4070.575500] R13: 000d R14: R15: > 7ffd65c8d7c0 > [ 4070.575505] > [ 4070.575507] Modules linked in: nls_ascii(E) nls_cp437(E) vfat(E) fat(E) > i915(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) crct10dif_pclmul(E) > crc32_pclmul(E) crc32c_intel(E) aesni_intel(E) crypto_simd(E) intel_gtt(E) > cryptd(E) ttm(E) rapl(E) intel_cstate(E) drm_kms_helper(E) cfbfillrect(E) > syscopyarea(E) cfbimgblt(E) intel_uncore(E) sysfillrect(E) mei_me(E) > sysimgblt(E) i2c_i801(E) fb_sys_fops(E) mei(E) intel_pch_thermal(E) > i2c_smbus(E) cfbcopyarea(E) video(E) button(E) efivarfs(E) autofs4(E) > [ 4070.575549] ---[ end trace ]--- > > However, there is a risk of triggering kernel warning on contexts list not > empty at driver release time if we deleagate that task to a worker for > i915_gem_context_release_work(), unless that work is flushed first. > Unfortunately, it is not flushed on driver release. Fix it. > > Chris Wilson (1): > drm/i915/gem: Really move i915_gem_context.link under ref protection > > Janusz Krzysztofik (1): > drm/i915/gem: Flush contexts on driver release > > drivers/gpu/drm/i915/gem/i915_gem_context.c | 8 > drivers/gpu/drm/i915/i915_gem.c | 3 ++- > 2 files changed, 6 insertions(+), 5 deletions(-) > >
Re: [Intel-gfx] [PATCH 1/1] drm/i915/guc: Delay disabling guc_id scheduling for better hysteresis
On Thu, 2022-09-15 at 09:48 +0100, Tvrtko Ursulin wrote:
> On 15/09/2022 03:12, Alan Previn wrote:
> > From: Matthew Brost
> >
> > Add a delay, configurable via debugfs (default 34ms), to disable
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> >
> > + u16 guc_ids_in_use;
>
> Any specific reason to use u16? It can usually just result in larger
> code generated and I don't see any space saving needed or achieved when
> it is sandwiched between two struct list_heads.
>
no specific reason - will switch to uint32.
> > + u64 sched_disable_delay_ms;
>
> 64-bits for the delay then sounds like overkill. Both should IMO just be
> unsigned ints.
>
avoiding some typecasting on related functions that reference this
but thats not a good excuse so will fix it.
> > + int sched_disable_gucid_threshold;
>
> unsigned int as well, so reader does not have to think about:
> return guc->submission_state.guc_ids_in_use >
> guc->submission_state.sched_disable_gucid_threshold;
>
> further down.
>
yes agreed - will fix.
> > +static void __delay_sched_disable(struct work_struct *wrk)
> > +{
> > + struct intel_context *ce =
> > + container_of(wrk, typeof(*ce),
> > guc_state.sched_disable_delay.work);
> > + struct intel_guc *guc = ce_to_guc(ce);
> > + unsigned long flags;
> > +
> > spin_lock_irqsave(&ce->guc_state.lock, flags);
> >
> > + if (bypass_sched_disable(guc, ce)) {
> > + spin_unlock_irqrestore(&ce->guc_state.lock, flags);
> > + intel_context_sched_disable_unpin(ce);
> > + } else {
> > + do_sched_disable(guc, ce, flags);
> > + }
>
> lock
> if
>unlock
>do sttuff
> else
>do_sched_disable - which unlocks inside
>
> Now move to next block..
>
> > +}
> > +
> > +static bool guc_id_pressure(struct intel_guc *guc, struct intel_context
> > *ce)
> > +{
> > /*
> > -* We have to check if the context has been disabled by another thread,
> > -* check if submssion has been disabled to seal a race with reset and
> > -* finally check if any more requests have been committed to the
> > -* context ensursing that a request doesn't slip through the
> > -* 'context_pending_disable' fence.
> > +* parent contexts are perma-pinned, if we are unpinning do schedule
> > +* disable immediately.
> > */
> > - if (unlikely(!context_enabled(ce) || submission_disabled(guc) ||
> > -context_has_committed_requests(ce))) {
> > - clr_context_enabled(ce);
> > + if (intel_context_is_parent(ce))
> > + return true;
> > +
> > + /*
> > +* If we are beyond the threshold for avail guc_ids, do schedule
> > disable immediately.
> > +*/
> > + return guc->submission_state.guc_ids_in_use >
> > + guc->submission_state.sched_disable_gucid_threshold;
> > +}
> > +
> > +static void guc_context_sched_disable(struct intel_context *ce)
> > +{
> > + struct intel_guc *guc = ce_to_guc(ce);
> > + u64 delay = guc->submission_state.sched_disable_delay_ms;
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(&ce->guc_state.lock, flags);
> > +
> > + if (bypass_sched_disable(guc, ce)) {
> > + spin_unlock_irqrestore(&ce->guc_state.lock, flags);
> > + intel_context_sched_disable_unpin(ce);
> > + } else if (!intel_context_is_closed(ce) && !guc_id_pressure(guc, ce) &&
> > + delay) {
> > spin_unlock_irqrestore(&ce->guc_state.lock, flags);
> > - goto unpin;
> > + mod_delayed_work(system_unbound_wq,
> > +&ce->guc_state.sched_disable_delay,
> > +msecs_to_jiffies(delay));
> > + } else {
> > + do_sched_disable(guc, ce, flags);
> > }
>
> lock
> if
>unlock
>do stuff
> else if
>unlock
>do stuff
> else
>do_sched_disable - which unlocks inside
>
> IMO it creates less readable code for the benefit of not repeating
> with_intel_runtime_pm -> __guc_context_sched_disable two times. Dunno..
> it's ugly but I have no suggestions. Hm does it have to send using the
> busy loop? It couldn't just queue the request and then wait for reply if
> disable message was emitted?
>
I agree that the above code lacks readability - will see if i can break it down
to smaller
functions with cleaner in-function lock/unlock pairs. I agree that a little
code duplication
is better than less readable code. It was inherited code i didn't want to
modify but I'll
go ahead and refactor this.
On the busy loop - im assuming you are refering to the actual ct sending. I'll
consult my
team if i am missing anything more but based on comments, I believe callers
must use that
function to guarantee reservation of space in the G2H CTB to always have space
to capture
responses for actions that MUST be acknowledged from GuC (acknowledged by
either replying
with a success or failure). This
Re: [Intel-gfx] [PATCH v2 1/4] drm/i915/gt: Cleanup partial engine discovery failures
On Friday, 16 September 2022 01:26:51 CEST Matt Roper wrote:
> From: Chris Wilson
>
> If we abort driver initialisation in the middle of gt/engine discovery,
> some engines will be fully setup and some not. Those incompletely setup
> engines only have 'engine->release == NULL' and so will leak any of the
> common objects allocated.
>
> v2:
> - Drop the destroy_pinned_context() helper for now. It's not really
>worth it with just a single callsite at the moment. (Janusz)
>
> Signed-off-by: Chris Wilson
> Cc: Janusz Krzysztofik
> Signed-off-by: Matt Roper
Reviewed-by: Janusz Krzysztofik
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 1f7188129cd1..2ddcad497fa3 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -1274,8 +1274,13 @@ int intel_engines_init(struct intel_gt *gt)
> return err;
>
> err = setup(engine);
> - if (err)
> + if (err) {
> + intel_engine_cleanup_common(engine);
> return err;
> + }
> +
> + /* The backend should now be responsible for cleanup */
> + GEM_BUG_ON(engine->release == NULL);
>
> err = engine_init_common(engine);
> if (err)
>
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Don't disable DDI/Transcoder when setting phy test pattern
== Series Details ==
Series: drm/i915/display: Don't disable DDI/Transcoder when setting phy test
pattern
URL : https://patchwork.freedesktop.org/series/108636/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12144 -> Patchwork_108636v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108636v1/index.html
Participating hosts (35 -> 39)
--
Additional (7): fi-bxt-dsi bat-dg2-8 bat-adlm-1 bat-dg2-9 bat-adlp-6
bat-adln-1 bat-rpls-1
Missing(3): fi-ctg-p8600 fi-rkl-11600 fi-hsw-4200u
Known issues
Here are the changes found in Patchwork_108636v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-bxt-dsi: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#2190])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108636v1/fi-bxt-dsi/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@random-engines:
- fi-icl-u2: NOTRUN -> [SKIP][2] ([i915#4613]) +3 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108636v1/fi-icl-u2/igt@gem_lmem_swapp...@random-engines.html
* igt@gem_lmem_swapping@verify-random:
- fi-bxt-dsi: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613]) +3
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108636v1/fi-bxt-dsi/igt@gem_lmem_swapp...@verify-random.html
* igt@gem_tiled_blits@basic:
- fi-bxt-dsi: NOTRUN -> [SKIP][4] ([fdo#109271]) +12 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108636v1/fi-bxt-dsi/igt@gem_tiled_bl...@basic.html
* igt@i915_selftest@live@requests:
- fi-pnv-d510:[PASS][5] -> [DMESG-FAIL][6] ([i915#4528])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/fi-pnv-d510/igt@i915_selftest@l...@requests.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108636v1/fi-pnv-d510/igt@i915_selftest@l...@requests.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-ivb-3770:NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108636v1/fi-ivb-3770/igt@kms_chamel...@common-hpd-after-suspend.html
- fi-bdw-5557u: NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108636v1/fi-bdw-5557u/igt@kms_chamel...@common-hpd-after-suspend.html
- fi-snb-2600:NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108636v1/fi-snb-2600/igt@kms_chamel...@common-hpd-after-suspend.html
- fi-icl-u2: NOTRUN -> [SKIP][10] ([fdo#111827])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108636v1/fi-icl-u2/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@hdmi-edid-read:
- fi-bxt-dsi: NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827]) +8
similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108636v1/fi-bxt-dsi/igt@kms_chamel...@hdmi-edid-read.html
* igt@kms_psr@cursor_plane_move:
- fi-tgl-u2: [PASS][12] -> [SKIP][13] ([i915#668]) +3 similar
issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/fi-tgl-u2/igt@kms_psr@cursor_plane_move.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108636v1/fi-tgl-u2/igt@kms_psr@cursor_plane_move.html
* igt@prime_vgem@basic-userptr:
- fi-icl-u2: NOTRUN -> [SKIP][14] ([fdo#109295] / [i915#3301])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108636v1/fi-icl-u2/igt@prime_v...@basic-userptr.html
Possible fixes
* igt@fbdev@read:
- {fi-tgl-mst}: [SKIP][15] ([i915#2582]) -> [PASS][16] +2 similar
issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/fi-tgl-mst/igt@fb...@read.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108636v1/fi-tgl-mst/igt@fb...@read.html
* igt@i915_pm_rpm@basic-rte:
- fi-icl-u2: [INCOMPLETE][17] ([i915#4185] / [i915#4890]) ->
[PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/fi-icl-u2/igt@i915_pm_...@basic-rte.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108636v1/fi-icl-u2/igt@i915_pm_...@basic-rte.html
* igt@i915_selftest@live@hangcheck:
- fi-ivb-3770:[INCOMPLETE][19] ([i915#3303] / [i915#5370]) ->
[PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/fi-ivb-3770/igt@i915_selftest@l...@hangcheck.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108636v1/fi-ivb-3770/igt@i915_selftest@l...@hangcheck.html
- fi-snb-2600:[INCOMPLETE][21] ([i915#3921]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[22]:
ht
Re: [Intel-gfx] [PATCH v2 4/4] drm/i915: Handle all GTs on driver (un)load paths
Hi Matt,
On Thu, Sep 15, 2022 at 04:26:54PM -0700, Matt Roper wrote:
> From: Tvrtko Ursulin
>
> This, along with the changes already landed in commit 1c66a12ab431
> ("drm/i915: Handle each GT on init/release and suspend/resume") makes
> engines from all GTs actually known to the driver.
>
> To accomplish this we need to sprinkle a lot of for_each_gt calls around
> but is otherwise pretty un-eventuful.
>
> v2:
> - Consolidate adjacent GT loops in a couple places. (Daniele)
>
> Cc: Daniele Ceraolo Spurio
> Signed-off-by: Tvrtko Ursulin
> Signed-off-by: Matt Roper
Reviewed-by: Andi Shyti
Andi
Re: [Intel-gfx] [PATCH] drm/i915/gvt: fix double-free bug in split_2MB_gtt_entry.
On Fri, Sep 16, 2022 at 02:39:21PM +0800, Zheng Hacker wrote: > >From 8d95c1399e3ff345500a575e21254a73b0c89144 Mon Sep 17 00:00:00 2001 > From: xmzyshypnc <1002992...@qq.com> > Date: Fri, 16 Sep 2022 14:37:48 +0800 > Subject: [PATCH] drm/i915/gvt: fix double-free bug in split_2MB_gtt_entry > > There is a double-free security bug in split_2MB_gtt_entry. > > Here is a calling chain : > ppgtt_populate_spt->ppgtt_populate_shadow_entry->split_2MB_gtt_entry. > If intel_gvt_dma_map_guest_page failed, it will call > ppgtt_invalidate_spt, which will finally call ppgtt_free_spt and > kfree(spt). But the caller does not notice that, and it will call > ppgtt_free_spt again in error path. > > Fix this by only freeing spt in ppgtt_invalidate_spt in good case. > > Signed-off-by: xmzyshypnc <1002992...@qq.com> > --- > drivers/gpu/drm/i915/gvt/gtt.c | 16 +--- > 1 file changed, 9 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c > index 9f14fded8c0c..31d2a8d56384 100644 > --- a/drivers/gpu/drm/i915/gvt/gtt.c > +++ b/drivers/gpu/drm/i915/gvt/gtt.c > @@ -959,7 +959,7 @@ static inline int ppgtt_put_spt(struct > intel_vgpu_ppgtt_spt *spt) > return atomic_dec_return(&spt->refcount); > } > > -static int ppgtt_invalidate_spt(struct intel_vgpu_ppgtt_spt *spt); > +static int ppgtt_invalidate_spt(struct intel_vgpu_ppgtt_spt *sptm, > int is_error); Your patch is whitespace damaged and linewrapped and can not be applied, and can only barely read :( Please fix up your email client to not do this so that the change can be properly reviewed and accepted if correct. thanks, greg k-h
[Intel-gfx] [PATCH] drm/i915: fix device info for devices without display
Commit 00c6cbfd4e8a ("drm/i915: move pipe_mask and cpu_transcoder_mask
to runtime info") moved the pipe_mask member from struct
intel_device_info to intel_runtime_info, but overlooked some of our
platforms initializing device info .display = {}. This is significant,
as pipe_mask is the single point of truth for a device having a display
or not; the platforms in question left pipe_mask to whatever was set for
the platforms they "inherit" from in the complex macro scheme we have.
Add new NO_DISPLAY macro initializing .__runtime.pipe_mask = 0, which
will cause the device info .display sub-struct to be zeroed in
intel_device_info_runtime_init(). A better solution (or simply audit of
proper use of HAS_DISPLAY() checks) is required before moving forward
with [1].
Also clear all the display related members in runtime info if there's no
display. The latter is a bit tedious, but it's for completeness at this
time, to ensure similar functionality as before.
[1]
https://lore.kernel.org/r/dfda1bf67f02ceb07c280b7a13216405fd1f7a34.1660137416.git.jani.nik...@intel.com
Fixes: 00c6cbfd4e8a ("drm/i915: move pipe_mask and cpu_transcoder_mask to
runtime info")
Cc: Lucas De Marchi
Cc: Maarten Lankhort
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_pci.c | 11 ++-
drivers/gpu/drm/i915/intel_device_info.c | 6 ++
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 77e7df21f539..cd4487a1d3be 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -41,6 +41,8 @@
.__runtime.media.ip.ver = (x), \
.__runtime.display.ip.ver = (x)
+#define NO_DISPLAY .__runtime.pipe_mask = 0
+
#define I845_PIPE_OFFSETS \
.display.pipe_offsets = { \
[TRANSCODER_A] = PIPE_A_OFFSET, \
@@ -519,9 +521,8 @@ static const struct intel_device_info ivb_m_gt2_info = {
static const struct intel_device_info ivb_q_info = {
GEN7_FEATURES,
PLATFORM(INTEL_IVYBRIDGE),
+ NO_DISPLAY,
.gt = 2,
- .__runtime.pipe_mask = 0, /* legal, last one wins */
- .__runtime.cpu_transcoder_mask = 0,
.has_l3_dpf = 1,
};
@@ -1039,7 +1040,7 @@ static const struct intel_device_info xehpsdv_info = {
XE_HPM_FEATURES,
DGFX_FEATURES,
PLATFORM(INTEL_XEHPSDV),
- .display = { },
+ NO_DISPLAY,
.has_64k_pages = 1,
.needs_compact_pt = 1,
.has_media_ratio_mode = 1,
@@ -1081,7 +1082,7 @@ static const struct intel_device_info dg2_info = {
static const struct intel_device_info ats_m_info = {
DG2_FEATURES,
- .display = { 0 },
+ NO_DISPLAY,
.require_force_probe = 1,
.tuning_thread_rr_after_dep = 1,
};
@@ -1103,7 +1104,7 @@ static const struct intel_device_info pvc_info = {
.__runtime.graphics.ip.rel = 60,
.__runtime.media.ip.rel = 60,
PLATFORM(INTEL_PONTEVECCHIO),
- .display = { 0 },
+ NO_DISPLAY,
.has_flat_ccs = 0,
.__runtime.platform_engine_mask =
BIT(BCS0) |
diff --git a/drivers/gpu/drm/i915/intel_device_info.c
b/drivers/gpu/drm/i915/intel_device_info.c
index 1434dc33cf49..20575eb77ea7 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -433,8 +433,14 @@ void intel_device_info_runtime_init(struct
drm_i915_private *dev_priv)
dev_priv->drm.driver_features &= ~(DRIVER_MODESET |
DRIVER_ATOMIC);
memset(&info->display, 0, sizeof(info->display));
+
+ runtime->cpu_transcoder_mask = 0;
memset(runtime->num_sprites, 0, sizeof(runtime->num_sprites));
memset(runtime->num_scalers, 0, sizeof(runtime->num_scalers));
+ runtime->fbc_mask = 0;
+ runtime->has_hdcp = false;
+ runtime->has_dmc = false;
+ runtime->has_dsc = false;
}
}
--
2.34.1
[Intel-gfx] [PATCH 1/2] drm/i915/pps: Add get_pps_idx() hook as part of pps_get_register() cleanup
Simplified pps_get_register() which use get_pps_idx() hook to derive the
pps instance and get_pps_idx() will be initialized at pps_init().
v1: Initial version. Got r-b from Jani.
Cc: Jani Nikula
Cc: Ville Syrjälä
Cc: Uma Shankar
Signed-off-by: Animesh Manna
---
.../gpu/drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_pps.c | 15 ++-
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 0da9b208d56e..b78b29951241 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1693,6 +1693,7 @@ struct intel_dp {
u8 (*preemph_max)(struct intel_dp *intel_dp);
u8 (*voltage_max)(struct intel_dp *intel_dp,
const struct intel_crtc_state *crtc_state);
+ int (*get_pps_idx)(struct intel_dp *intel_dp);
/* Displayport compliance testing */
struct intel_dp_compliance compliance;
diff --git a/drivers/gpu/drm/i915/display/intel_pps.c
b/drivers/gpu/drm/i915/display/intel_pps.c
index 21944f5bf3a8..b972fa6ec00d 100644
--- a/drivers/gpu/drm/i915/display/intel_pps.c
+++ b/drivers/gpu/drm/i915/display/intel_pps.c
@@ -364,12 +364,10 @@ static void intel_pps_get_registers(struct intel_dp
*intel_dp,
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
int pps_idx = 0;
- memset(regs, 0, sizeof(*regs));
+ if (intel_dp->get_pps_idx)
+ pps_idx = intel_dp->get_pps_idx(intel_dp);
- if (IS_GEMINILAKE(dev_priv) || IS_BROXTON(dev_priv))
- pps_idx = bxt_power_sequencer_idx(intel_dp);
- else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
- pps_idx = vlv_power_sequencer_pipe(intel_dp);
+ memset(regs, 0, sizeof(*regs));
regs->pp_ctrl = PP_CONTROL(pps_idx);
regs->pp_stat = PP_STATUS(pps_idx);
@@ -1432,6 +1430,13 @@ void intel_pps_init(struct intel_dp *intel_dp)
intel_dp->pps.initializing = true;
INIT_DELAYED_WORK(&intel_dp->pps.panel_vdd_work, edp_panel_vdd_work);
+ if (IS_GEMINILAKE(i915) || IS_BROXTON(i915))
+ intel_dp->get_pps_idx = bxt_power_sequencer_idx;
+ else if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
+ intel_dp->get_pps_idx = vlv_power_sequencer_pipe;
+ else
+ intel_dp->get_pps_idx = NULL;
+
pps_init_timestamps(intel_dp);
with_intel_pps_lock(intel_dp, wakeref) {
--
2.29.0
[Intel-gfx] [PATCH 2/2] drm/i915/pps: Enable 2nd pps for dual EDP scenario
>From display gen12 onwards to support dual EDP two instances of pps added.
Currently backlight controller and pps instance can be mapped together
for a specific panel. Extended support for gen12 for dual EDP usage.
v1: Iniital revision
v2: Called intel_bios_panel_init w/o PNPID before intel_pps_init. [Jani]
Cc: Jani Nikula
Cc: Ville Syrjälä
Cc: Uma Shankar
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_bios.c | 7 ---
drivers/gpu/drm/i915/display/intel_bios.h | 7 +++
drivers/gpu/drm/i915/display/intel_dp.c | 9 ++---
drivers/gpu/drm/i915/display/intel_pps.c | 2 +-
4 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index 28bdb936cd1f..5fd4c09dfa96 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -706,13 +706,6 @@ static int fallback_get_panel_type(struct drm_i915_private
*i915,
return 0;
}
-enum panel_type {
- PANEL_TYPE_OPREGION,
- PANEL_TYPE_VBT,
- PANEL_TYPE_PNPID,
- PANEL_TYPE_FALLBACK,
-};
-
static int get_panel_type(struct drm_i915_private *i915,
const struct intel_bios_encoder_data *devdata,
const struct edid *edid)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.h
b/drivers/gpu/drm/i915/display/intel_bios.h
index e375405a7828..da01b13260ae 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.h
+++ b/drivers/gpu/drm/i915/display/intel_bios.h
@@ -231,6 +231,13 @@ struct mipi_pps_data {
u16 panel_power_cycle_delay;
} __packed;
+enum panel_type {
+ PANEL_TYPE_OPREGION,
+ PANEL_TYPE_VBT,
+ PANEL_TYPE_PNPID,
+ PANEL_TYPE_FALLBACK,
+};
+
void intel_bios_init(struct drm_i915_private *dev_priv);
void intel_bios_init_panel(struct drm_i915_private *dev_priv,
struct intel_panel *panel,
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index c19e99ee06b6..6f7afa75ec4d 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5222,6 +5222,9 @@ static bool intel_edp_init_connector(struct intel_dp
*intel_dp,
return false;
}
+ intel_bios_init_panel(dev_priv, &intel_connector->panel,
+ encoder->devdata, NULL);
+
intel_pps_init(intel_dp);
/* Cache DPCD and EDID for edp. */
@@ -5255,9 +5258,9 @@ static bool intel_edp_init_connector(struct intel_dp
*intel_dp,
edid = ERR_PTR(-ENOENT);
}
intel_connector->edid = edid;
-
- intel_bios_init_panel(dev_priv, &intel_connector->panel,
- encoder->devdata, IS_ERR(edid) ? NULL : edid);
+ if (intel_connector->panel.vbt.panel_type == PANEL_TYPE_FALLBACK)
+ intel_bios_init_panel(dev_priv, &intel_connector->panel,
+ encoder->devdata, IS_ERR(edid) ? NULL :
edid);
intel_panel_add_edid_fixed_modes(intel_connector,
intel_connector->panel.vbt.drrs_type
!= DRRS_TYPE_NONE,
diff --git a/drivers/gpu/drm/i915/display/intel_pps.c
b/drivers/gpu/drm/i915/display/intel_pps.c
index b972fa6ec00d..4b8413382c5d 100644
--- a/drivers/gpu/drm/i915/display/intel_pps.c
+++ b/drivers/gpu/drm/i915/display/intel_pps.c
@@ -1430,7 +1430,7 @@ void intel_pps_init(struct intel_dp *intel_dp)
intel_dp->pps.initializing = true;
INIT_DELAYED_WORK(&intel_dp->pps.panel_vdd_work, edp_panel_vdd_work);
- if (IS_GEMINILAKE(i915) || IS_BROXTON(i915))
+ if (IS_GEMINILAKE(i915) || IS_BROXTON(i915) || DISPLAY_VER(i915) >= 12)
intel_dp->get_pps_idx = bxt_power_sequencer_idx;
else if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
intel_dp->get_pps_idx = vlv_power_sequencer_pipe;
--
2.29.0
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Split GAM and MSLICE steering
== Series Details == Series: drm/i915: Split GAM and MSLICE steering URL : https://patchwork.freedesktop.org/series/108627/ State : success == Summary == CI Bug Log - changes from CI_DRM_12144_full -> Patchwork_108627v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (11 -> 11) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_108627v1_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@unwedge-stress: - shard-iclb: [PASS][1] -> [TIMEOUT][2] ([i915#3070]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/shard-iclb7/igt@gem_...@unwedge-stress.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108627v1/shard-iclb5/igt@gem_...@unwedge-stress.html * igt@gem_exec_balancer@parallel-keep-in-fence: - shard-iclb: [PASS][3] -> [SKIP][4] ([i915#4525]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/shard-iclb1/igt@gem_exec_balan...@parallel-keep-in-fence.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108627v1/shard-iclb3/igt@gem_exec_balan...@parallel-keep-in-fence.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-tglb: [PASS][5] -> [FAIL][6] ([i915#2842]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/shard-tglb1/igt@gem_exec_fair@basic-f...@rcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108627v1/shard-tglb7/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-none@vcs1: - shard-iclb: NOTRUN -> [FAIL][7] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108627v1/shard-iclb1/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-none@vecs0: - shard-glk: [PASS][8] -> [FAIL][9] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/shard-glk2/igt@gem_exec_fair@basic-n...@vecs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108627v1/shard-glk3/igt@gem_exec_fair@basic-n...@vecs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-apl: [PASS][10] -> [FAIL][11] ([i915#2842]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/shard-apl4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108627v1/shard-apl8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][12] -> [SKIP][13] ([i915#2190]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/shard-tglb3/igt@gem_huc_c...@huc-copy.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108627v1/shard-tglb7/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@verify-random: - shard-apl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#4613]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108627v1/shard-apl7/igt@gem_lmem_swapp...@verify-random.html * igt@gem_pxp@reject-modify-context-protection-off-3: - shard-apl: NOTRUN -> [SKIP][15] ([fdo#109271]) +44 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108627v1/shard-apl7/igt@gem_...@reject-modify-context-protection-off-3.html * igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs: - shard-apl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#3886]) +2 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108627v1/shard-apl7/igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs.html * igt@kms_chamelium@dp-hpd-with-enabled-mode: - shard-apl: NOTRUN -> [SKIP][17] ([fdo#109271] / [fdo#111827]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108627v1/shard-apl7/igt@kms_chamel...@dp-hpd-with-enabled-mode.html * igt@kms_flip@2x-flip-vs-absolute-wf_vblank@ab-hdmi-a1-hdmi-a2: - shard-glk: [PASS][18] -> [FAIL][19] ([i915#2122]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/shard-glk9/igt@kms_flip@2x-flip-vs-absolute-wf_vbl...@ab-hdmi-a1-hdmi-a2.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108627v1/shard-glk9/igt@kms_flip@2x-flip-vs-absolute-wf_vbl...@ab-hdmi-a1-hdmi-a2.html * igt@kms_flip_scaled_crc@flip-32bpp-yftile-to-64bpp-yftile-downscaling@pipe-a-valid-mode: - shard-iclb: NOTRUN -> [SKIP][20] ([i915#2587] / [i915#2672]) +3 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108627v1/shard-iclb7/igt@kms_flip_scaled_crc@flip-32bpp-yftile-to-64bpp-yftile-downscal...@pipe-a-valid-mode.html * igt@kms_flip_scaled_crc@flip-64bpp-4tile-to-32bpp-4tiledg2rcccs-upscaling@pipe-a-default-mode: - shard-iclb: NOTRUN -> [SKIP][21] ([i915#2672]) +2 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108627v1/
[Intel-gfx] [PULL] drm-intel-gt-next
Hi Dave & Daniel,
Here goes the final drm-intel-gt-next towards 6.1.
For stable platforms we have fixes for throttle reasons decoding to sysfs, GuC
version update to 7.5, XeHP SDV GSC support and the usual pile of smaller fixes.
DG2 and DG1 runtime PM is now mostly fixed for LMEM access via mmap, but kernel
internal usages still need to be reviewed. There's also at least one LMEM code
NULL deref bug to resolve [1]. Finally a bunch of Meteorlake (MTL) enabling
patches.
Note that this PR includes patches going to mei subsystem, due to the tight
coupling of the MEI/GSC code. Those are Acked-by Greg.
Regards, Joonas
[1]
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12135/bat-dg2-11/igt@gem_lmem_swapping@ba...@lmem0.html
***
drm-intel-gt-next-2022-09-16:
Cross-subsystem Changes:
- MEI subsystem pieces for XeHP SDV GSC support
These are Acked-by Greg.
Driver Changes:
- Release mmaps on RPM suspend on discrete GPUs (Anshuman)
- Update GuC version to 7.5 on DG1, DG2 and ADL
- Revert "drm/i915/dg2: extend Wa_1409120013 to DG2" (Lucas)
- MTL enabling incl. standalone media (Matt R, Lucas)
- Explicitly clear BB_OFFSET for new contexts on Gen8+ (Chris)
- Fix throttling / perf limit reason decoding (Ashutosh)
- XeHP SDV GSC support (Vitaly, Alexander, Tomas)
- Fix issues with overrding firmware file paths (John)
- Invert if-else ladders to check latest version first (Lucas)
- Cancel GuC engine busyness worker synchronously (Umesh)
- Skip applying copy engine fuses outside PVC (Lucas)
- Eliminate Gen10 frequency read function (Lucas)
- Static code checker fixes (Gaosheng)
- Selftest improvements (Chris)
The following changes since commit 04f7eb3d4582a0a4da67c86e55fda7de2df86d91:
drm/i915: Set correct domains values at _i915_vma_move_to_active (2022-09-08
11:06:35 +0100)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-gt-next-2022-09-16
for you to fetch changes up to 8adc718881e0a70127f8843dd70e69a80de39352:
drm/i915/uc: Update to latest GuC and use new-format GuC/HuC names
(2022-09-15 18:43:33 -0700)
Cross-subsystem Changes:
- MEI subsystem pieces for XeHP SDV GSC support
These are Acked-by Greg.
Driver Changes:
- Release mmaps on RPM suspend on discrete GPUs (Anshuman)
- Update GuC version to 7.5 on DG1, DG2 and ADL
- Revert "drm/i915/dg2: extend Wa_1409120013 to DG2" (Lucas)
- MTL enabling incl. standalone media (Matt R, Lucas)
- Explicitly clear BB_OFFSET for new contexts on Gen8+ (Chris)
- Fix throttling / perf limit reason decoding (Ashutosh)
- XeHP SDV GSC support (Vitaly, Alexander, Tomas)
- Fix issues with overrding firmware file paths (John)
- Invert if-else ladders to check latest version first (Lucas)
- Cancel GuC engine busyness worker synchronously (Umesh)
- Skip applying copy engine fuses outside PVC (Lucas)
- Eliminate Gen10 frequency read function (Lucas)
- Static code checker fixes (Gaosheng)
- Selftest improvements (Chris)
Alexander Usyskin (5):
drm/i915/gsc: add slow_firmware flag to the gsc device definition
drm/i915/gsc: add GSC XeHP SDV platform definition
mei: gsc: wait for reset thread on stop
mei: extend timeouts on slow devices
mei: drop ready bits check after start
Anshuman Gupta (2):
drm/i915: Refactor userfault_wakeref to re-use
drm/i915/dgfx: Release mmap on rpm suspend
Ashutosh Dixit (1):
drm/i915/gt: Fix perf limit reasons bit positions
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
Gaosheng Cui (1):
drm/i915: remove unused i915_gem_lmem_obj_ops declaration
John Harrison (2):
drm/i915/uc: Fix issues with overriding firmware files
drm/i915/uc: Update to latest GuC and use new-format GuC/HuC names
Lucas De Marchi (7):
Revert "drm/i915/dg2: extend Wa_1409120013 to DG2"
drm/i915/gt: Use MEDIA_VER() when handling media fuses
drm/i915/gt: Extract function to apply media fuses
drm/i915: Skip applying copy engine fuses
drm/i915: Invert if/else ladder for frequency read
drm/i915/gt: Extract per-platform function for frequency read
drm/i915: Invert if/else ladder for stolen init
Matt Roper (14):
drm/i915: Move locking and unclaimed check into mmio_debug_{suspend,
resume}
drm/i915: Only hook up uncore->debug for primary uncore
drm/i915: Use managed allocations for extra uncore objects
drm/i915: Drop intel_gt_tile_cleanup()
drm/i915: Prepare more multi-GT initialization
drm/i915: Rename and expose common GT early init routine
drm/i915: Use a DRM-managed action to release the PCI bridge device
Re: [Intel-gfx] [PATCH 2/2] drm/i915/pps: Enable 2nd pps for dual EDP scenario
On Fri, Sep 16, 2022 at 02:01:02PM +0530, Animesh Manna wrote:
> >From display gen12 onwards to support dual EDP two instances of pps added.
> Currently backlight controller and pps instance can be mapped together
> for a specific panel. Extended support for gen12 for dual EDP usage.
>
> v1: Iniital revision
> v2: Called intel_bios_panel_init w/o PNPID before intel_pps_init. [Jani]
>
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Cc: Uma Shankar
> Signed-off-by: Animesh Manna
> ---
> drivers/gpu/drm/i915/display/intel_bios.c | 7 ---
> drivers/gpu/drm/i915/display/intel_bios.h | 7 +++
> drivers/gpu/drm/i915/display/intel_dp.c | 9 ++---
> drivers/gpu/drm/i915/display/intel_pps.c | 2 +-
> 4 files changed, 14 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index 28bdb936cd1f..5fd4c09dfa96 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -706,13 +706,6 @@ static int fallback_get_panel_type(struct
> drm_i915_private *i915,
> return 0;
> }
>
> -enum panel_type {
> - PANEL_TYPE_OPREGION,
> - PANEL_TYPE_VBT,
> - PANEL_TYPE_PNPID,
> - PANEL_TYPE_FALLBACK,
> -};
> -
> static int get_panel_type(struct drm_i915_private *i915,
> const struct intel_bios_encoder_data *devdata,
> const struct edid *edid)
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.h
> b/drivers/gpu/drm/i915/display/intel_bios.h
> index e375405a7828..da01b13260ae 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.h
> +++ b/drivers/gpu/drm/i915/display/intel_bios.h
> @@ -231,6 +231,13 @@ struct mipi_pps_data {
> u16 panel_power_cycle_delay;
> } __packed;
>
> +enum panel_type {
> + PANEL_TYPE_OPREGION,
> + PANEL_TYPE_VBT,
> + PANEL_TYPE_PNPID,
> + PANEL_TYPE_FALLBACK,
> +};
> +
> void intel_bios_init(struct drm_i915_private *dev_priv);
> void intel_bios_init_panel(struct drm_i915_private *dev_priv,
> struct intel_panel *panel,
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index c19e99ee06b6..6f7afa75ec4d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -5222,6 +5222,9 @@ static bool intel_edp_init_connector(struct intel_dp
> *intel_dp,
> return false;
> }
>
> + intel_bios_init_panel(dev_priv, &intel_connector->panel,
> + encoder->devdata, NULL);
We don't want to go for the fallback type here if we
the VBT wants us to use pnpid. Maybe we should just
remove the fallback type entirely? Or perhaps only
use it if the VBT panel type is entirely invalid?
> +
> intel_pps_init(intel_dp);
>
> /* Cache DPCD and EDID for edp. */
> @@ -5255,9 +5258,9 @@ static bool intel_edp_init_connector(struct intel_dp
> *intel_dp,
> edid = ERR_PTR(-ENOENT);
> }
> intel_connector->edid = edid;
> -
> - intel_bios_init_panel(dev_priv, &intel_connector->panel,
> - encoder->devdata, IS_ERR(edid) ? NULL : edid);
> + if (intel_connector->panel.vbt.panel_type == PANEL_TYPE_FALLBACK)
> + intel_bios_init_panel(dev_priv, &intel_connector->panel,
> + encoder->devdata, IS_ERR(edid) ? NULL :
> edid);
>
> intel_panel_add_edid_fixed_modes(intel_connector,
>intel_connector->panel.vbt.drrs_type
> != DRRS_TYPE_NONE,
> diff --git a/drivers/gpu/drm/i915/display/intel_pps.c
> b/drivers/gpu/drm/i915/display/intel_pps.c
> index b972fa6ec00d..4b8413382c5d 100644
> --- a/drivers/gpu/drm/i915/display/intel_pps.c
> +++ b/drivers/gpu/drm/i915/display/intel_pps.c
> @@ -1430,7 +1430,7 @@ void intel_pps_init(struct intel_dp *intel_dp)
> intel_dp->pps.initializing = true;
> INIT_DELAYED_WORK(&intel_dp->pps.panel_vdd_work, edp_panel_vdd_work);
>
> - if (IS_GEMINILAKE(i915) || IS_BROXTON(i915))
> + if (IS_GEMINILAKE(i915) || IS_BROXTON(i915) || DISPLAY_VER(i915) >= 12)
> intel_dp->get_pps_idx = bxt_power_sequencer_idx;
> else if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
> intel_dp->get_pps_idx = vlv_power_sequencer_pipe;
> --
> 2.29.0
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH 1/1] drm/i915/guc: Delay disabling guc_id scheduling for better hysteresis
On 16/09/2022 08:53, Teres Alexis, Alan Previn wrote:
On Thu, 2022-09-15 at 09:48 +0100, Tvrtko Ursulin wrote:
On 15/09/2022 03:12, Alan Previn wrote:
From: Matthew Brost
Add a delay, configurable via debugfs (default 34ms), to disable
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+ u16 guc_ids_in_use;
Any specific reason to use u16? It can usually just result in larger
code generated and I don't see any space saving needed or achieved when
it is sandwiched between two struct list_heads.
no specific reason - will switch to uint32.
Unsigned int would be best. Every time there is explicit width specified
it looks like there is special reason for the width - like interacting
with hardware or firmware protocol. At least I always see it like that.
+ u64 sched_disable_delay_ms;
64-bits for the delay then sounds like overkill. Both should IMO just be
unsigned ints.
avoiding some typecasting on related functions that reference this
but thats not a good excuse so will fix it.
Right, yes, clamp/cap/validate at debugfs entry points should do it.
+ int sched_disable_gucid_threshold;
unsigned int as well, so reader does not have to think about:
return guc->submission_state.guc_ids_in_use >
guc->submission_state.sched_disable_gucid_threshold;
further down.
yes agreed - will fix.
+static void __delay_sched_disable(struct work_struct *wrk)
+{
+ struct intel_context *ce =
+ container_of(wrk, typeof(*ce),
guc_state.sched_disable_delay.work);
+ struct intel_guc *guc = ce_to_guc(ce);
+ unsigned long flags;
+
spin_lock_irqsave(&ce->guc_state.lock, flags);
+ if (bypass_sched_disable(guc, ce)) {
+ spin_unlock_irqrestore(&ce->guc_state.lock, flags);
+ intel_context_sched_disable_unpin(ce);
+ } else {
+ do_sched_disable(guc, ce, flags);
+ }
lock
if
unlock
do sttuff
else
do_sched_disable - which unlocks inside
Now move to next block..
+}
+
+static bool guc_id_pressure(struct intel_guc *guc, struct intel_context *ce)
+{
/*
-* We have to check if the context has been disabled by another thread,
-* check if submssion has been disabled to seal a race with reset and
-* finally check if any more requests have been committed to the
-* context ensursing that a request doesn't slip through the
-* 'context_pending_disable' fence.
+* parent contexts are perma-pinned, if we are unpinning do schedule
+* disable immediately.
*/
- if (unlikely(!context_enabled(ce) || submission_disabled(guc) ||
-context_has_committed_requests(ce))) {
- clr_context_enabled(ce);
+ if (intel_context_is_parent(ce))
+ return true;
+
+ /*
+* If we are beyond the threshold for avail guc_ids, do schedule
disable immediately.
+*/
+ return guc->submission_state.guc_ids_in_use >
+ guc->submission_state.sched_disable_gucid_threshold;
+}
+
+static void guc_context_sched_disable(struct intel_context *ce)
+{
+ struct intel_guc *guc = ce_to_guc(ce);
+ u64 delay = guc->submission_state.sched_disable_delay_ms;
+ unsigned long flags;
+
+ spin_lock_irqsave(&ce->guc_state.lock, flags);
+
+ if (bypass_sched_disable(guc, ce)) {
+ spin_unlock_irqrestore(&ce->guc_state.lock, flags);
+ intel_context_sched_disable_unpin(ce);
+ } else if (!intel_context_is_closed(ce) && !guc_id_pressure(guc, ce) &&
+ delay) {
spin_unlock_irqrestore(&ce->guc_state.lock, flags);
- goto unpin;
+ mod_delayed_work(system_unbound_wq,
+&ce->guc_state.sched_disable_delay,
+msecs_to_jiffies(delay));
+ } else {
+ do_sched_disable(guc, ce, flags);
}
lock
if
unlock
do stuff
else if
unlock
do stuff
else
do_sched_disable - which unlocks inside
IMO it creates less readable code for the benefit of not repeating
with_intel_runtime_pm -> __guc_context_sched_disable two times. Dunno..
it's ugly but I have no suggestions. Hm does it have to send using the
busy loop? It couldn't just queue the request and then wait for reply if
disable message was emitted?
I agree that the above code lacks readability - will see if i can break it down
to smaller
functions with cleaner in-function lock/unlock pairs. I agree that a little
code duplication
is better than less readable code. It was inherited code i didn't want to
modify but I'll
go ahead and refactor this.
On the busy loop - im assuming you are refering to the actual ct sending. I'll
consult my
team if i am missing anything more but based on comments, I believe callers
must use that
function to guarantee reservation
Re: [Intel-gfx] [PATCH] drm/i915: Split GAM and MSLICE steering
On 16/09/2022 02:43, Matt Roper wrote:
Although the bspec lists several MMIO ranges as "MSLICE," it turns out
that a subset of these are of a "GAM" subclass that has unique rules and
doesn't followed regular mslice steering behavior.
* Xe_HP SDV: GAM ranges must always be steered to 0,0. These
registers share the regular steering control register (0xFDC) with
other steering types
* DG2: GAM ranges must always be steered to 1,0. GAM registers have a
dedicated steering control register (0xFE0) so we can set the value
once at startup and rely on implicit steering. Technically the
hardware default should already be set to 1,0 properly, but it never
hurts to ensure that in the driver.
Do you have any data on whether the "technically should" holds in
practice? What would be the consequences of some platform/machine
surprising us here?
Regards,
Tvrtko
Bspec: 66534
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 24 +++--
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
drivers/gpu/drm/i915/gt/intel_gt_types.h| 1 +
drivers/gpu/drm/i915/gt/intel_workarounds.c | 10 +
4 files changed, 34 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
index e79405a45312..a2047a68ea7a 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
@@ -40,6 +40,7 @@ static const char * const intel_steering_types[] = {
"L3BANK",
"MSLICE",
"LNCF",
+ "GAM",
"INSTANCE 0",
};
@@ -48,14 +49,23 @@ static const struct intel_mmio_range icl_l3bank_steering_table[] = {
{},
};
+/*
+ * Although the bspec lists more "MSLICE" ranges than shown here, some of those
+ * are of a "GAM" subclass that has special rules. Thus we use a separate
+ * GAM table farther down for those.
+ */
static const struct intel_mmio_range xehpsdv_mslice_steering_table[] = {
- { 0x004000, 0x004AFF },
- { 0x00C800, 0x00CFFF },
{ 0x00DD00, 0x00DDFF },
{ 0x00E900, 0x00 }, /* 0xEA00 - OxEFFF is unused */
{},
};
+static const struct intel_mmio_range xehpsdv_gam_steering_table[] = {
+ { 0x004000, 0x004AFF },
+ { 0x00C800, 0x00CFFF },
+ {},
+};
+
static const struct intel_mmio_range xehpsdv_lncf_steering_table[] = {
{ 0x00B000, 0x00B0FF },
{ 0x00D800, 0x00D8FF },
@@ -114,9 +124,15 @@ void intel_gt_mcr_init(struct intel_gt *gt)
} else if (IS_DG2(i915)) {
gt->steering_table[MSLICE] = xehpsdv_mslice_steering_table;
gt->steering_table[LNCF] = dg2_lncf_steering_table;
+ /*
+* No need to hook up the GAM table since it has a dedicated
+* steering control register on DG2 and can use implicit
+* steering.
+*/
} else if (IS_XEHPSDV(i915)) {
gt->steering_table[MSLICE] = xehpsdv_mslice_steering_table;
gt->steering_table[LNCF] = xehpsdv_lncf_steering_table;
+ gt->steering_table[GAM] = xehpsdv_gam_steering_table;
} else if (GRAPHICS_VER(i915) >= 11 &&
GRAPHICS_VER_FULL(i915) < IP_VER(12, 50)) {
gt->steering_table[L3BANK] = icl_l3bank_steering_table;
@@ -351,6 +367,10 @@ static void get_nonterminated_steering(struct intel_gt *gt,
*group = __ffs(gt->info.mslice_mask) << 1;
*instance = 0; /* unused */
break;
+ case GAM:
+ *group = IS_DG2(gt->i915) ? 1 : 0;
+ *instance = 0;
+ break;
case INSTANCE0:
/*
* There are a lot of MCR types for which instance (0, 0)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 2275ee47da95..2343b26e0e21 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -42,6 +42,7 @@
#define MCFG_MCR_SELECTOR _MMIO(0xfd0)
#define SF_MCR_SELECTOR _MMIO(0xfd8)
#define GEN8_MCR_SELECTOR _MMIO(0xfdc)
+#define GAM_MCR_SELECTOR _MMIO(0xfe0)
#define GEN8_MCR_SLICE(slice) (((slice) & 3) << 26)
#define GEN8_MCR_SLICE_MASK GEN8_MCR_SLICE(3)
#define GEN8_MCR_SUBSLICE(subslice) (((subslice) & 3) << 24)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index f19c2de77ff6..30003d68fd51 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -59,6 +59,7 @@ enum intel_steering_type {
L3BANK,
MSLICE,
LNCF,
+ GAM,
/*
* On some platforms there are multiple types of MCR registers that
diff --git a/driv
Re: [Intel-gfx] [PATCH 1/1] drm/i915/uc: Update to latest GuC and use new-format GuC/HuC names
On 15/09/2022 21:03, John Harrison wrote: On 9/15/2022 01:59, Tvrtko Ursulin wrote: Hi, On 15/09/2022 00:46, john.c.harri...@intel.com wrote: From: John Harrison Going forwards, the intention is for GuC firmware files to be named for their major version only and HuC firmware files to have no version number in the name at all. This patch adds those entries for all platforms that are officially GuC/HuC enabled. Also, update the expected GuC version numbers to the latest firmware release for those platforms. Signed-off-by: John Harrison --- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 10 +++--- 1 file changed, 7 insertions(+), 3 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 1169e2a09da24..b91ad4aede1f7 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c @@ -72,12 +72,14 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw, * security fixes, etc. to be enabled. */ #define INTEL_GUC_FIRMWARE_DEFS(fw_def, guc_maj, guc_mmp) \ - fw_def(DG2, 0, guc_mmp(dg2, 70, 4, 1)) \ + fw_def(DG2, 0, guc_maj(dg2, 70, 5)) \ Just glancing over out of curiosity. Part which confused me is that if only major is supposed to be used then what is the '5' in guc_maj(dg2, 70, 5) ? See the earlier patch that added support for version reduced filenames. The minor number is still specified because want to be able to warn the user if their firmware is out of date and causing them to miss features, security fixes, etc. The driver will still load any old firmware with the right name and work with it, but user's need to know that there are updates available. Got it. Release is deemed not important enough to warn about? no actually, it's different, I guess we never expect to bump only the release with a source level change - so in practice kernel could not warn that there is a newer release version since it would never know. In other words those ones would only be hitting linux-firmware, while minor changes would be kernel patches as well. I also couldn't find guc_maj with grep so I guess it's some sort of a magic concatenation macro or what? 'guc_maj' is a macro parameter as per the definition of the macro three lines above. According to where INTEL_GUC_FIRMWARE_DEFS is used, it becomes either a mechanism for creating just a 'MODULE_FIRMWARE' definition for the firmware file or a table entry giving all the version information as well as the filename. Doh thanks, macro magic was apparently impenetrable to me yesterday. Regards, Tvrtko
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: fix device info for devices without display
== Series Details == Series: drm/i915: fix device info for devices without display URL : https://patchwork.freedesktop.org/series/108642/ State : warning == Summary == Error: dim checkpatch failed 262478f3fe42 drm/i915: fix device info for devices without display -:24: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #24: [1] https://lore.kernel.org/r/dfda1bf67f02ceb07c280b7a13216405fd1f7a34.1660137416.git.jani.nik...@intel.com total: 0 errors, 1 warnings, 0 checks, 56 lines checked
[Intel-gfx] [PATCH v3 0/2] drm/i915/gem: Really move i915_gem_context.link under ref protection
i915_perf assumes that it can use the i915_gem_context reference to protect its i915->gem.contexts.list iteration. However, this requires that we do not remove the context from the list until after we drop the final reference and release the struct. If, as currently, we remove the context from the list during context_close(), the link.next pointer may be poisoned while we are holding the context reference and cause a GPF: [ 4070.573157] i915 :00:02.0: [drm:i915_perf_open_ioctl [i915]] filtering on ctx_id=0x 1f ctx_id_mask=0x1f [ 4070.574881] general protection fault, probably for non-canonical address 0xdead 0100: [#1] PREEMPT SMP [ 4070.574897] CPU: 1 PID: 284392 Comm: amd_performance Tainted: GE 5.17.9 #180 [ 4070.574903] Hardware name: Intel Corporation NUC7i5BNK/NUC7i5BNB, BIOS BNKBL357.86A.0052.2017.0918.1346 09/18/2017 [ 4070.574907] RIP: 0010:oa_configure_all_contexts.isra.0+0x222/0x350 [i915] [ 4070.574982] Code: 08 e8 32 6e 10 e1 4d 8b 6d 50 b8 ff ff ff ff 49 83 ed 50 f0 41 0f c1 04 24 83 f8 01 0f 84 e3 00 00 00 85 c0 0f 8e fa 00 00 00 <49> 8b 45 50 48 8d 70 b0 49 8d 45 50 48 39 44 24 10 0f 85 34 fe ff [ 4070.574990] RSP: 0018:c90002077b78 EFLAGS: 00010202 [ 4070.574995] RAX: 0002 RBX: 0002 RCX: [ 4070.575000] RDX: 0001 RSI: c90002077b20 RDI: 88810ddc7c68 [ 4070.575004] RBP: 0001 R08: 888103242648 R09: fffc [ 4070.575008] R10: 82c50bc0 R11: 00025c80 R12: 888101bf1860 [ 4070.575012] R13: dead00b0 R14: c90002077c04 R15: 88810be5cabc [ 4070.575016] FS: 7f1ed50c0780() GS:5ec8() knlGS: [ 4070.575021] CS: 0010 DS: ES: CR0: 80050033 [ 4070.575025] CR2: 7f1ed5590280 CR3: 00010ef6f005 CR4: 003706e0 [ 4070.575029] Call Trace: [ 4070.575033] [ 4070.575037] lrc_configure_all_contexts+0x13e/0x150 [i915] [ 4070.575103] gen8_enable_metric_set+0x4d/0x90 [i915] [ 4070.575164] i915_perf_open_ioctl+0xbc0/0x1500 [i915] [ 4070.575224] ? asm_common_interrupt+0x1e/0x40 [ 4070.575232] ? i915_oa_init_reg_state+0x110/0x110 [i915] [ 4070.575290] drm_ioctl_kernel+0x85/0x110 [ 4070.575296] ? update_load_avg+0x5f/0x5e0 [ 4070.575302] drm_ioctl+0x1d3/0x370 [ 4070.575307] ? i915_oa_init_reg_state+0x110/0x110 [i915] [ 4070.575382] ? gen8_gt_irq_handler+0x46/0x130 [i915] [ 4070.575445] __x64_sys_ioctl+0x3c4/0x8d0 [ 4070.575451] ? __do_softirq+0xaa/0x1d2 [ 4070.575456] do_syscall_64+0x35/0x80 [ 4070.575461] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 4070.575467] RIP: 0033:0x7f1ed5c10397 [ 4070.575471] Code: 3c 1c e8 1c ff ff ff 85 c0 79 87 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a9 da 0d 00 f7 d8 64 89 01 48 [ 4070.575478] RSP: 002b:7ffd65c8d7a8 EFLAGS: 0246 ORIG_RAX: 0010 [ 4070.575484] RAX: ffda RBX: 0006 RCX: 7f1ed5c10397 [ 4070.575488] RDX: 7ffd65c8d7c0 RSI: 40106476 RDI: 0006 [ 4070.575492] RBP: 5620972f9c60 R08: 000a R09: 0005 [ 4070.575496] R10: 000d R11: 0246 R12: 000a [ 4070.575500] R13: 000d R14: R15: 7ffd65c8d7c0 [ 4070.575505] [ 4070.575507] Modules linked in: nls_ascii(E) nls_cp437(E) vfat(E) fat(E) i915(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) crct10dif_pclmul(E) crc32_pclmul(E) crc32c_intel(E) aesni_intel(E) crypto_simd(E) intel_gtt(E) cryptd(E) ttm(E) rapl(E) intel_cstate(E) drm_kms_helper(E) cfbfillrect(E) syscopyarea(E) cfbimgblt(E) intel_uncore(E) sysfillrect(E) mei_me(E) sysimgblt(E) i2c_i801(E) fb_sys_fops(E) mei(E) intel_pch_thermal(E) i2c_smbus(E) cfbcopyarea(E) video(E) button(E) efivarfs(E) autofs4(E) [ 4070.575549] ---[ end trace ]--- However, there is a risk of triggering kernel warning on contexts list not empty at driver release time if we deleagate that task to a worker for i915_gem_context_release_work(), unless that work is flushed first. Unfortunately, it is not flushed on driver release. Fix it. Chris Wilson (1): drm/i915/gem: Really move i915_gem_context.link under ref protection Janusz Krzysztofik (1): drm/i915/gem: Flush contexts on driver release drivers/gpu/drm/i915/gem/i915_gem_context.c | 8 drivers/gpu/drm/i915/i915_gem.c | 3 ++- 2 files changed, 6 insertions(+), 5 deletions(-) -- 2.25.1
[Intel-gfx] [PATCH v3 1/2] drm/i915/gem: Flush contexts on driver release
Due to i915_perf assuming that it can use the i915_gem_context reference
to protect its i915->gem.contexts.list iteration, we need to defer removal
of the context from the list until last reference to the context is put.
However, there is a risk of triggering kernel warning on contexts list not
empty at driver release time if we deleagate that task to a worker for
i915_gem_context_release_work(), unless that work is flushed first.
Unfortunately, it is not flushed on driver release. Fix it.
Instead of additionally calling flush_workqueue(), either directly or via
a new dedicated wrapper around it, replace last call to
i915_gem_drain_freed_objects() with existing i915_gem_drain_workqueue()
that performs both tasks.
Fixes: 75eefd82581f ("drm/i915: Release i915_gem_context from a worker")
Suggested-by: Chris Wilson
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Andi Shyti
Cc: sta...@kernel.org # v5.16+
---
drivers/gpu/drm/i915/i915_gem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c8e14ed9c2a96..172c29a15f118 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1195,7 +1195,8 @@ void i915_gem_driver_release(struct drm_i915_private
*dev_priv)
intel_uc_cleanup_firmwares(&to_gt(dev_priv)->uc);
- i915_gem_drain_freed_objects(dev_priv);
+ /* Flush any outstanding work, including i915_gem_context.release_work.
*/
+ i915_gem_drain_workqueue(dev_priv);
drm_WARN_ON(&dev_priv->drm, !list_empty(&dev_priv->gem.contexts.list));
}
--
2.25.1
[Intel-gfx] [PATCH v3 2/2] drm/i915/gem: Really move i915_gem_context.link under ref protection
From: Chris Wilson
i915_perf assumes that it can use the i915_gem_context reference to
protect its i915->gem.contexts.list iteration. However, this requires
that we do not remove the context from the list until after we drop the
final reference and release the struct. If, as currently, we remove the
context from the list during context_close(), the link.next pointer may
be poisoned while we are holding the context reference and cause a GPF:
[ 4070.573157] i915 :00:02.0: [drm:i915_perf_open_ioctl [i915]] filtering
on ctx_id=0x1f ctx_id_mask=0x1f
[ 4070.574881] general protection fault, probably for non-canonical address
0xdead0100: [#1] PREEMPT SMP
[ 4070.574897] CPU: 1 PID: 284392 Comm: amd_performance Tainted: GE
5.17.9 #180
[ 4070.574903] Hardware name: Intel Corporation NUC7i5BNK/NUC7i5BNB, BIOS
BNKBL357.86A.0052.2017.0918.1346 09/18/2017
[ 4070.574907] RIP: 0010:oa_configure_all_contexts.isra.0+0x222/0x350 [i915]
[ 4070.574982] Code: 08 e8 32 6e 10 e1 4d 8b 6d 50 b8 ff ff ff ff 49 83 ed 50
f0 41 0f c1 04 24 83 f8 01 0f 84 e3 00 00 00 85 c0 0f 8e fa 00 00 00 <49> 8b 45
50 48 8d 70 b0 49 8d 45 50 48 39 44 24 10 0f 85 34 fe ff
[ 4070.574990] RSP: 0018:c90002077b78 EFLAGS: 00010202
[ 4070.574995] RAX: 0002 RBX: 0002 RCX:
[ 4070.575000] RDX: 0001 RSI: c90002077b20 RDI: 88810ddc7c68
[ 4070.575004] RBP: 0001 R08: 888103242648 R09: fffc
[ 4070.575008] R10: 82c50bc0 R11: 00025c80 R12: 888101bf1860
[ 4070.575012] R13: dead00b0 R14: c90002077c04 R15: 88810be5cabc
[ 4070.575016] FS: 7f1ed50c0780() GS:5ec8()
knlGS:
[ 4070.575021] CS: 0010 DS: ES: CR0: 80050033
[ 4070.575025] CR2: 7f1ed5590280 CR3: 00010ef6f005 CR4: 003706e0
[ 4070.575029] Call Trace:
[ 4070.575033]
[ 4070.575037] lrc_configure_all_contexts+0x13e/0x150 [i915]
[ 4070.575103] gen8_enable_metric_set+0x4d/0x90 [i915]
[ 4070.575164] i915_perf_open_ioctl+0xbc0/0x1500 [i915]
[ 4070.575224] ? asm_common_interrupt+0x1e/0x40
[ 4070.575232] ? i915_oa_init_reg_state+0x110/0x110 [i915]
[ 4070.575290] drm_ioctl_kernel+0x85/0x110
[ 4070.575296] ? update_load_avg+0x5f/0x5e0
[ 4070.575302] drm_ioctl+0x1d3/0x370
[ 4070.575307] ? i915_oa_init_reg_state+0x110/0x110 [i915]
[ 4070.575382] ? gen8_gt_irq_handler+0x46/0x130 [i915]
[ 4070.575445] __x64_sys_ioctl+0x3c4/0x8d0
[ 4070.575451] ? __do_softirq+0xaa/0x1d2
[ 4070.575456] do_syscall_64+0x35/0x80
[ 4070.575461] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 4070.575467] RIP: 0033:0x7f1ed5c10397
[ 4070.575471] Code: 3c 1c e8 1c ff ff ff 85 c0 79 87 49 c7 c4 ff ff ff ff 5b
5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01
f0 ff ff 73 01 c3 48 8b 0d a9 da 0d 00 f7 d8 64 89 01 48
[ 4070.575478] RSP: 002b:7ffd65c8d7a8 EFLAGS: 0246 ORIG_RAX:
0010
[ 4070.575484] RAX: ffda RBX: 0006 RCX: 7f1ed5c10397
[ 4070.575488] RDX: 7ffd65c8d7c0 RSI: 40106476 RDI: 0006
[ 4070.575492] RBP: 5620972f9c60 R08: 000a R09: 0005
[ 4070.575496] R10: 000d R11: 0246 R12: 000a
[ 4070.575500] R13: 000d R14: R15: 7ffd65c8d7c0
[ 4070.575505]
[ 4070.575507] Modules linked in: nls_ascii(E) nls_cp437(E) vfat(E) fat(E)
i915(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) crct10dif_pclmul(E)
crc32_pclmul(E) crc32c_intel(E) aesni_intel(E) crypto_simd(E) intel_gtt(E)
cryptd(E) ttm(E) rapl(E) intel_cstate(E) drm_kms_helper(E) cfbfillrect(E)
syscopyarea(E) cfbimgblt(E) intel_uncore(E) sysfillrect(E) mei_me(E)
sysimgblt(E) i2c_i801(E) fb_sys_fops(E) mei(E) intel_pch_thermal(E)
i2c_smbus(E) cfbcopyarea(E) video(E) button(E) efivarfs(E) autofs4(E)
[ 4070.575549] ---[ end trace ]---
v3: fix incorrect syntax of spin_lock() replacing spin_lock_irqsave()
v2: irqsave not required in a worker, neither conversion to irq safe
elsewhere (Tvrtko),
- perf: it's safe to call gen8_configure_context() even if context has
been closed, no need to check,
- drop unrelated cleanup (Andi, Tvrtko)
Reported-by: Mark Janes
Closes: https://gitlab.freedesktop.org/drm/intel/issues/6222
References: a4e7ccdac38e ("drm/i915: Move context management under GEM")
Fixes: f8246cf4d9a9 ("drm/i915/gem: Drop free_work for GEM contexts")
Signed-off-by: Chris Wilson
Reviewed-by: Andi Shyti
Signed-off-by: Andi Shyti
Signed-off-by: Janusz Krzysztofik
Cc: Tvrtko Ursulin
Cc: # v5.12+
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index dabdfe09f5e51..0bcde53c50c61 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gp
[Intel-gfx] ✗ Fi.CI.IGT: failure for Initial Meteorlake Support (rev10)
== Series Details == Series: Initial Meteorlake Support (rev10) URL : https://patchwork.freedesktop.org/series/106786/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12144_full -> Patchwork_106786v10_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_106786v10_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_106786v10_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (11 -> 11) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_106786v10_full: ### IGT changes ### Possible regressions * igt@i915_pm_dc@dc5-psr: - shard-iclb: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/shard-iclb3/igt@i915_pm...@dc5-psr.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106786v10/shard-iclb4/igt@i915_pm...@dc5-psr.html Known issues Here are the changes found in Patchwork_106786v10_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_exec@basic-nohangcheck: - shard-tglb: [PASS][3] -> [FAIL][4] ([i915#6268]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/shard-tglb8/igt@gem_ctx_e...@basic-nohangcheck.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106786v10/shard-tglb3/igt@gem_ctx_e...@basic-nohangcheck.html * igt@gem_eio@in-flight-contexts-10ms: - shard-tglb: [PASS][5] -> [TIMEOUT][6] ([i915#3063]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/shard-tglb2/igt@gem_...@in-flight-contexts-10ms.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106786v10/shard-tglb8/igt@gem_...@in-flight-contexts-10ms.html * igt@gem_exec_balancer@parallel-bb-first: - shard-iclb: [PASS][7] -> [SKIP][8] ([i915#4525]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/shard-iclb4/igt@gem_exec_balan...@parallel-bb-first.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106786v10/shard-iclb7/igt@gem_exec_balan...@parallel-bb-first.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-iclb: NOTRUN -> [FAIL][9] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106786v10/shard-iclb2/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][10] -> [SKIP][11] ([i915#2190]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/shard-tglb3/igt@gem_huc_c...@huc-copy.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106786v10/shard-tglb7/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@verify-random: - shard-apl: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4613]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106786v10/shard-apl2/igt@gem_lmem_swapp...@verify-random.html * igt@gem_pxp@reject-modify-context-protection-off-3: - shard-apl: NOTRUN -> [SKIP][13] ([fdo#109271]) +44 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106786v10/shard-apl2/igt@gem_...@reject-modify-context-protection-off-3.html * igt@gen9_exec_parse@allowed-single: - shard-glk: [PASS][14] -> [DMESG-WARN][15] ([i915#5566] / [i915#716]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/shard-glk9/igt@gen9_exec_pa...@allowed-single.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106786v10/shard-glk5/igt@gen9_exec_pa...@allowed-single.html * igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs: - shard-apl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#3886]) +2 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106786v10/shard-apl2/igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs.html * igt@kms_chamelium@dp-hpd-with-enabled-mode: - shard-apl: NOTRUN -> [SKIP][17] ([fdo#109271] / [fdo#111827]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106786v10/shard-apl2/igt@kms_chamel...@dp-hpd-with-enabled-mode.html * igt@kms_cursor_crc@cursor-suspend@pipe-a-dp-1: - shard-apl: [PASS][18] -> [DMESG-WARN][19] ([i915#180]) +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/shard-apl7/igt@kms_cursor_crc@cursor-susp...@pipe-a-dp-1.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106786v10/shard-apl1/igt@kms_cursor_crc@cursor-susp...@pipe-a-dp-1.html * igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions: - shard-glk: [PASS][20] -> [FAIL][21] ([i915#2346]) [20]: https://intel-gfx-ci.01.org/t
Re: [Intel-gfx] [PATCH 2/2] drm/i915/hotplug: refactor hotplug init slightly
On Fri, Sep 09, 2022 at 03:42:34PM +0300, Jani Nikula wrote:
> Rename intel_hpd_init_work() to the more generic intel_hpd_init_early(),
> and move the hotplug storm initialization there. This lets us move the
> HPD_STORM_DEFAULT_THRESHOLD macro to intel_hotplug.c too.
>
> Signed-off-by: Jani Nikula
Series is
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_hotplug.c | 22 +++-
> drivers/gpu/drm/i915/display/intel_hotplug.h | 2 +-
> drivers/gpu/drm/i915/i915_drv.h | 3 ---
> drivers/gpu/drm/i915/i915_irq.c | 11 +-
> 4 files changed, 19 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c
> b/drivers/gpu/drm/i915/display/intel_hotplug.c
> index 4faae25d76c0..352a1b53b63e 100644
> --- a/drivers/gpu/drm/i915/display/intel_hotplug.c
> +++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
> @@ -90,6 +90,9 @@ enum hpd_pin intel_hpd_pin_default(struct drm_i915_private
> *dev_priv,
> return HPD_PORT_A + port - PORT_A;
> }
>
> +/* Threshold == 5 for long IRQs, 50 for short */
> +#define HPD_STORM_DEFAULT_THRESHOLD 50
> +
> #define HPD_STORM_DETECT_PERIOD 1000
> #define HPD_STORM_REENABLE_DELAY (2 * 60 * 1000)
> #define HPD_RETRY_DELAY 1000
> @@ -711,14 +714,23 @@ void intel_hpd_poll_disable(struct drm_i915_private
> *dev_priv)
> schedule_work(&dev_priv->display.hotplug.poll_init_work);
> }
>
> -void intel_hpd_init_work(struct drm_i915_private *dev_priv)
> +void intel_hpd_init_early(struct drm_i915_private *i915)
> {
> - INIT_DELAYED_WORK(&dev_priv->display.hotplug.hotplug_work,
> + INIT_DELAYED_WORK(&i915->display.hotplug.hotplug_work,
> i915_hotplug_work_func);
> - INIT_WORK(&dev_priv->display.hotplug.dig_port_work,
> i915_digport_work_func);
> - INIT_WORK(&dev_priv->display.hotplug.poll_init_work,
> i915_hpd_poll_init_work);
> - INIT_DELAYED_WORK(&dev_priv->display.hotplug.reenable_work,
> + INIT_WORK(&i915->display.hotplug.dig_port_work, i915_digport_work_func);
> + INIT_WORK(&i915->display.hotplug.poll_init_work,
> i915_hpd_poll_init_work);
> + INIT_DELAYED_WORK(&i915->display.hotplug.reenable_work,
> intel_hpd_irq_storm_reenable_work);
> +
> + i915->display.hotplug.hpd_storm_threshold = HPD_STORM_DEFAULT_THRESHOLD;
> + /* If we have MST support, we want to avoid doing short HPD IRQ storm
> + * detection, as short HPD storms will occur as a natural part of
> + * sideband messaging with MST.
> + * On older platforms however, IRQ storms can occur with both long and
> + * short pulses, as seen on some G4x systems.
> + */
> + i915->display.hotplug.hpd_short_storm_enabled = !HAS_DP_MST(i915);
> }
>
> void intel_hpd_cancel_work(struct drm_i915_private *dev_priv)
> diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.h
> b/drivers/gpu/drm/i915/display/intel_hotplug.h
> index aa84e381d6c3..424ae5dbf5a0 100644
> --- a/drivers/gpu/drm/i915/display/intel_hotplug.h
> +++ b/drivers/gpu/drm/i915/display/intel_hotplug.h
> @@ -22,7 +22,7 @@ void intel_hpd_irq_handler(struct drm_i915_private
> *dev_priv,
> u32 pin_mask, u32 long_mask);
> void intel_hpd_trigger_irq(struct intel_digital_port *dig_port);
> void intel_hpd_init(struct drm_i915_private *dev_priv);
> -void intel_hpd_init_work(struct drm_i915_private *dev_priv);
> +void intel_hpd_init_early(struct drm_i915_private *i915);
> void intel_hpd_cancel_work(struct drm_i915_private *dev_priv);
> enum hpd_pin intel_hpd_pin_default(struct drm_i915_private *dev_priv,
> enum port port);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index be201ba5e9ab..c91cccb2b8c7 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -75,9 +75,6 @@ struct intel_limit;
> struct intel_overlay_error_state;
> struct vlv_s0ix_state;
>
> -/* Threshold == 5 for long IRQs, 50 for short */
> -#define HPD_STORM_DEFAULT_THRESHOLD 50
> -
> #define I915_GEM_GPU_DOMAINS \
> (I915_GEM_DOMAIN_RENDER | \
>I915_GEM_DOMAIN_SAMPLER | \
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 515648cd1233..8ffd81243a19 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -4399,7 +4399,7 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
>
> intel_hpd_init_pins(dev_priv);
>
> - intel_hpd_init_work(dev_priv);
> + intel_hpd_init_early(dev_priv);
>
> dev->vblank_disable_immediate = true;
>
> @@ -4413,15 +4413,6 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
> if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> dev_priv->display_irqs_enabled = false;
>
> - dev_priv->display.hotplug.hpd_storm_threshold =
> HPD_STORM_DE
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: fix device info for devices without display
== Series Details == Series: drm/i915: fix device info for devices without display URL : https://patchwork.freedesktop.org/series/108642/ State : success == Summary == CI Bug Log - changes from CI_DRM_12145 -> Patchwork_108642v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108642v1/index.html Participating hosts (44 -> 41) -- Additional (2): fi-apl-guc bat-dg1-5 Missing(5): fi-hsw-4200u fi-ctg-p8600 fi-hsw-4770 bat-dg2-11 fi-bdw-samus Known issues Here are the changes found in Patchwork_108642v1 that come from known issues: ### IGT changes ### Issues hit * igt@fbdev@nullptr: - bat-dg1-5: NOTRUN -> [SKIP][1] ([i915#2582]) +4 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108642v1/bat-dg1-5/igt@fb...@nullptr.html * igt@gem_exec_suspend@basic-s3@smem: - fi-skl-6600u: [PASS][2] -> [INCOMPLETE][3] ([i915#4939] / [i915#6598]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108642v1/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html * igt@gem_mmap@basic: - bat-dg1-5: NOTRUN -> [SKIP][4] ([i915#4083]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108642v1/bat-dg1-5/igt@gem_m...@basic.html * igt@gem_tiled_blits@basic: - bat-dg1-5: NOTRUN -> [SKIP][5] ([i915#4077]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108642v1/bat-dg1-5/igt@gem_tiled_bl...@basic.html * igt@gem_tiled_pread_basic: - bat-dg1-5: NOTRUN -> [SKIP][6] ([i915#4079]) +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108642v1/bat-dg1-5/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - bat-dg1-5: NOTRUN -> [SKIP][7] ([i915#1155]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108642v1/bat-dg1-5/igt@i915_pm_backli...@basic-brightness.html * igt@i915_pm_rps@basic-api: - bat-dg1-5: NOTRUN -> [SKIP][8] ([i915#6621]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108642v1/bat-dg1-5/igt@i915_pm_...@basic-api.html * igt@i915_selftest@live@gt_lrc: - fi-rkl-guc: [PASS][9] -> [INCOMPLETE][10] ([i915#4983]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108642v1/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html * igt@i915_selftest@live@hangcheck: - fi-hsw-g3258: [PASS][11] -> [INCOMPLETE][12] ([i915#3303] / [i915#4785]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108642v1/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html * igt@i915_selftest@live@requests: - fi-pnv-d510:[PASS][13] -> [DMESG-FAIL][14] ([i915#4528]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/fi-pnv-d510/igt@i915_selftest@l...@requests.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108642v1/fi-pnv-d510/igt@i915_selftest@l...@requests.html * igt@kms_addfb_basic@basic-x-tiled-legacy: - bat-dg1-5: NOTRUN -> [SKIP][15] ([i915#4212]) +7 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108642v1/bat-dg1-5/igt@kms_addfb_ba...@basic-x-tiled-legacy.html * igt@kms_addfb_basic@basic-y-tiled-legacy: - bat-dg1-5: NOTRUN -> [SKIP][16] ([i915#4215]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108642v1/bat-dg1-5/igt@kms_addfb_ba...@basic-y-tiled-legacy.html * igt@kms_busy@basic: - bat-dg1-5: NOTRUN -> [SKIP][17] ([i915#1845] / [i915#4303]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108642v1/bat-dg1-5/igt@kms_b...@basic.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-bsw-nick:NOTRUN -> [SKIP][18] ([fdo#109271] / [fdo#111827]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108642v1/fi-bsw-nick/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_chamelium@dp-crc-fast: - bat-dg1-5: NOTRUN -> [SKIP][19] ([fdo#111827]) +8 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108642v1/bat-dg1-5/igt@kms_chamel...@dp-crc-fast.html * igt@kms_force_connector_basic@force-load-detect: - bat-dg1-5: NOTRUN -> [SKIP][20] ([fdo#109285]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108642v1/bat-dg1-5/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_pipe_crc_basic@nonblocking-crc: - bat-dg1-5: NOTRUN -> [SKIP][21] ([i915#4078]) +14 similar issues [21]: https://inte
[Intel-gfx] [PATCH v2 0/4] Fix HFVSDB parsing
Fix issues in HFVSDB parsing for DSC support. Also minor refactoring in Logging. Split from original patch into a new series. https://patchwork.freedesktop.org/patch/495193/ v2: Minor styling fixes. Ankit Nautiyal (4): drm/edid: Fix minimum bpc supported with DSC1.2 for HDMI sink drm/edid: Split DSC parsing into separate function drm/edid: Refactor HFVSDB parsing for DSC1.2 drm/edid: Avoid multiple log lines for HFVSDB parsing drivers/gpu/drm/drm_edid.c | 153 + 1 file changed, 87 insertions(+), 66 deletions(-) -- 2.25.1
[Intel-gfx] [PATCH v2 2/4] drm/edid: Split DSC parsing into separate function
Move the DSC parsing logic into separate function.
v2: Rebase.
Signed-off-by: Ankit Nautiyal
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 128 -
1 file changed, 69 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index ebe02cf7cd95..92c9c2e28902 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -5752,6 +5752,73 @@ static void drm_parse_ycbcr420_deep_color_info(struct
drm_connector *connector,
hdmi->y420_dc_modes = dc_mask;
}
+static void drm_parse_dsc_info(struct drm_hdmi_dsc_cap *hdmi_dsc,
+ const u8 *hf_scds)
+{
+ u8 dsc_max_slices;
+ u8 dsc_max_frl_rate;
+
+ hdmi_dsc->v_1p2 = hf_scds[11] & DRM_EDID_DSC_1P2;
+
+ if (!hdmi_dsc->v_1p2)
+ return;
+
+ hdmi_dsc->native_420 = hf_scds[11] & DRM_EDID_DSC_NATIVE_420;
+ hdmi_dsc->all_bpp = hf_scds[11] & DRM_EDID_DSC_ALL_BPP;
+
+ if (hf_scds[11] & DRM_EDID_DSC_16BPC)
+ hdmi_dsc->bpc_supported = 16;
+ else if (hf_scds[11] & DRM_EDID_DSC_12BPC)
+ hdmi_dsc->bpc_supported = 12;
+ else if (hf_scds[11] & DRM_EDID_DSC_10BPC)
+ hdmi_dsc->bpc_supported = 10;
+ else
+ /* Supports min 8 BPC if DSC 1.2 is supported*/
+ hdmi_dsc->bpc_supported = 8;
+
+ dsc_max_frl_rate = (hf_scds[12] & DRM_EDID_DSC_MAX_FRL_RATE_MASK) >> 4;
+ drm_get_max_frl_rate(dsc_max_frl_rate, &hdmi_dsc->max_lanes,
+&hdmi_dsc->max_frl_rate_per_lane);
+ hdmi_dsc->total_chunk_kbytes = hf_scds[13] &
DRM_EDID_DSC_TOTAL_CHUNK_KBYTES;
+
+ dsc_max_slices = hf_scds[12] & DRM_EDID_DSC_MAX_SLICES;
+
+ switch (dsc_max_slices) {
+ case 1:
+ hdmi_dsc->max_slices = 1;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 2:
+ hdmi_dsc->max_slices = 2;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 3:
+ hdmi_dsc->max_slices = 4;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 4:
+ hdmi_dsc->max_slices = 8;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 5:
+ hdmi_dsc->max_slices = 8;
+ hdmi_dsc->clk_per_slice = 400;
+ break;
+ case 6:
+ hdmi_dsc->max_slices = 12;
+ hdmi_dsc->clk_per_slice = 400;
+ break;
+ case 7:
+ hdmi_dsc->max_slices = 16;
+ hdmi_dsc->clk_per_slice = 400;
+ break;
+ case 0:
+ default:
+ hdmi_dsc->max_slices = 0;
+ hdmi_dsc->clk_per_slice = 0;
+ }
+}
+
/* Sink Capability Data Structure */
static void drm_parse_hdmi_forum_scds(struct drm_connector *connector,
const u8 *hf_scds)
@@ -5798,71 +5865,14 @@ static void drm_parse_hdmi_forum_scds(struct
drm_connector *connector,
if (hf_scds[7]) {
u8 max_frl_rate;
- u8 dsc_max_frl_rate;
- u8 dsc_max_slices;
struct drm_hdmi_dsc_cap *hdmi_dsc = &hdmi->dsc_cap;
DRM_DEBUG_KMS("hdmi_21 sink detected. parsing edid\n");
max_frl_rate = (hf_scds[7] & DRM_EDID_MAX_FRL_RATE_MASK) >> 4;
drm_get_max_frl_rate(max_frl_rate, &hdmi->max_lanes,
&hdmi->max_frl_rate_per_lane);
- hdmi_dsc->v_1p2 = hf_scds[11] & DRM_EDID_DSC_1P2;
-
- if (hdmi_dsc->v_1p2) {
- hdmi_dsc->native_420 = hf_scds[11] &
DRM_EDID_DSC_NATIVE_420;
- hdmi_dsc->all_bpp = hf_scds[11] & DRM_EDID_DSC_ALL_BPP;
-
- if (hf_scds[11] & DRM_EDID_DSC_16BPC)
- hdmi_dsc->bpc_supported = 16;
- else if (hf_scds[11] & DRM_EDID_DSC_12BPC)
- hdmi_dsc->bpc_supported = 12;
- else if (hf_scds[11] & DRM_EDID_DSC_10BPC)
- hdmi_dsc->bpc_supported = 10;
- else
- /* Supports min 8 BPC if DSC 1.2 is supported*/
- hdmi_dsc->bpc_supported = 8;
-
- dsc_max_frl_rate = (hf_scds[12] &
DRM_EDID_DSC_MAX_FRL_RATE_MASK) >> 4;
- drm_get_max_frl_rate(dsc_max_frl_rate,
&hdmi_dsc->max_lanes,
-&hdmi_dsc->max_frl_rate_per_lane);
- hdmi_dsc->total_chunk_kbytes = hf_scds[13] &
DRM_EDID_DSC_TOTAL_CHUNK_KBYTES;
-
- dsc_max_slices = hf_scds[12] & DRM_EDID_DSC_MAX_SLICES;
- switch (dsc_max_slices) {
- case 1:
- hdmi_
[Intel-gfx] [PATCH v2 4/4] drm/edid: Avoid multiple log lines for HFVSDB parsing
Replace multiple log lines with a single log line at the end of
parsing HF-VSDB. Also use drm_dbg_kms instead of DRM_DBG_KMS, and
add log for DSC1.2 support.
v2: Fixed the formatting issues in the logging (Jani).
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_edid.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 27bdbdf6d345..1c61e3af79c6 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -5830,6 +5830,9 @@ static void drm_parse_hdmi_forum_scds(struct
drm_connector *connector,
struct drm_display_info *display = &connector->display_info;
struct drm_hdmi_info *hdmi = &display->hdmi;
struct drm_hdmi_dsc_cap *hdmi_dsc = &hdmi->dsc_cap;
+ int max_tmds_clock = 0;
+ u8 max_frl_rate = 0;
+ bool dsc_support = false;
display->has_hdmi_infoframe = true;
@@ -5849,14 +5852,13 @@ static void drm_parse_hdmi_forum_scds(struct
drm_connector *connector,
*/
if (hf_scds[5]) {
- /* max clock is 5000 KHz times block value */
- u32 max_tmds_clock = hf_scds[5] * 5000;
struct drm_scdc *scdc = &hdmi->scdc;
+ /* max clock is 5000 KHz times block value */
+ max_tmds_clock = hf_scds[5] * 5000;
+
if (max_tmds_clock > 34) {
display->max_tmds_clock = max_tmds_clock;
- DRM_DEBUG_KMS("HF-VSDB: max TMDS clock %d kHz\n",
- display->max_tmds_clock);
}
if (scdc->supported) {
@@ -5869,9 +5871,6 @@ static void drm_parse_hdmi_forum_scds(struct
drm_connector *connector,
}
if (hf_scds[7]) {
- u8 max_frl_rate;
-
- DRM_DEBUG_KMS("hdmi_21 sink detected. parsing edid\n");
max_frl_rate = (hf_scds[7] & DRM_EDID_MAX_FRL_RATE_MASK) >> 4;
drm_get_max_frl_rate(max_frl_rate, &hdmi->max_lanes,
&hdmi->max_frl_rate_per_lane);
@@ -5879,8 +5878,14 @@ static void drm_parse_hdmi_forum_scds(struct
drm_connector *connector,
drm_parse_ycbcr420_deep_color_info(connector, hf_scds);
- if (cea_db_payload_len(hf_scds) >= 11 && hf_scds[11])
+ if (cea_db_payload_len(hf_scds) >= 11 && hf_scds[11]) {
drm_parse_dsc_info(hdmi_dsc, hf_scds);
+ dsc_support = true;
+ }
+
+ drm_dbg_kms(connector->dev,
+ "HF-VSDB: max TMDS clock: %d KHz, HDMI 2.1 support: %s, DSC
1.2 support: %s\n",
+ max_tmds_clock, str_yes_no(max_frl_rate),
str_yes_no(dsc_support));
}
static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
--
2.25.1
[Intel-gfx] [PATCH v2 1/4] drm/edid: Fix minimum bpc supported with DSC1.2 for HDMI sink
HF-VSDB/SCDB has bits to advertise support for 16, 12 and 10 bpc.
If none of the bits are set, the minimum bpc supported with DSC is 8.
This patch corrects the min bpc supported to be 8, instead of 0.
Fixes: 76ee7b905678 ("drm/edid: Parse DSC1.2 cap fields from HFVSDB block")
Cc: Ankit Nautiyal
Cc: Uma Shankar
Cc: Jani Nikula
Cc: Maarten Lankhorst
v2: s/DSC1.2/DSC 1.2
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_edid.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 4005dab6147d..ebe02cf7cd95 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -5819,7 +5819,8 @@ static void drm_parse_hdmi_forum_scds(struct
drm_connector *connector,
else if (hf_scds[11] & DRM_EDID_DSC_10BPC)
hdmi_dsc->bpc_supported = 10;
else
- hdmi_dsc->bpc_supported = 0;
+ /* Supports min 8 BPC if DSC 1.2 is supported*/
+ hdmi_dsc->bpc_supported = 8;
dsc_max_frl_rate = (hf_scds[12] &
DRM_EDID_DSC_MAX_FRL_RATE_MASK) >> 4;
drm_get_max_frl_rate(dsc_max_frl_rate,
&hdmi_dsc->max_lanes,
--
2.25.1
[Intel-gfx] [PATCH v2 3/4] drm/edid: Refactor HFVSDB parsing for DSC1.2
DSC capabilities are given in bytes 11-13 of VSDB (i.e. bytes 8-10 of
SCDS). Since minimum length of Data block is 7, all bytes greater than 7
must be read only after checking the length of the data block.
This patch adds check for data block length before reading relavant DSC
bytes.
Signed-off-by: Ankit Nautiyal
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 93 --
1 file changed, 49 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 92c9c2e28902..27bdbdf6d345 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -5755,9 +5755,6 @@ static void drm_parse_ycbcr420_deep_color_info(struct
drm_connector *connector,
static void drm_parse_dsc_info(struct drm_hdmi_dsc_cap *hdmi_dsc,
const u8 *hf_scds)
{
- u8 dsc_max_slices;
- u8 dsc_max_frl_rate;
-
hdmi_dsc->v_1p2 = hf_scds[11] & DRM_EDID_DSC_1P2;
if (!hdmi_dsc->v_1p2)
@@ -5776,47 +5773,54 @@ static void drm_parse_dsc_info(struct drm_hdmi_dsc_cap
*hdmi_dsc,
/* Supports min 8 BPC if DSC 1.2 is supported*/
hdmi_dsc->bpc_supported = 8;
- dsc_max_frl_rate = (hf_scds[12] & DRM_EDID_DSC_MAX_FRL_RATE_MASK) >> 4;
- drm_get_max_frl_rate(dsc_max_frl_rate, &hdmi_dsc->max_lanes,
-&hdmi_dsc->max_frl_rate_per_lane);
- hdmi_dsc->total_chunk_kbytes = hf_scds[13] &
DRM_EDID_DSC_TOTAL_CHUNK_KBYTES;
+ if (cea_db_payload_len(hf_scds) >= 12 && hf_scds[12]) {
+ u8 dsc_max_slices;
+ u8 dsc_max_frl_rate;
- dsc_max_slices = hf_scds[12] & DRM_EDID_DSC_MAX_SLICES;
+ dsc_max_frl_rate = (hf_scds[12] &
DRM_EDID_DSC_MAX_FRL_RATE_MASK) >> 4;
+ drm_get_max_frl_rate(dsc_max_frl_rate, &hdmi_dsc->max_lanes,
+&hdmi_dsc->max_frl_rate_per_lane);
- switch (dsc_max_slices) {
- case 1:
- hdmi_dsc->max_slices = 1;
- hdmi_dsc->clk_per_slice = 340;
- break;
- case 2:
- hdmi_dsc->max_slices = 2;
- hdmi_dsc->clk_per_slice = 340;
- break;
- case 3:
- hdmi_dsc->max_slices = 4;
- hdmi_dsc->clk_per_slice = 340;
- break;
- case 4:
- hdmi_dsc->max_slices = 8;
- hdmi_dsc->clk_per_slice = 340;
- break;
- case 5:
- hdmi_dsc->max_slices = 8;
- hdmi_dsc->clk_per_slice = 400;
- break;
- case 6:
- hdmi_dsc->max_slices = 12;
- hdmi_dsc->clk_per_slice = 400;
- break;
- case 7:
- hdmi_dsc->max_slices = 16;
- hdmi_dsc->clk_per_slice = 400;
- break;
- case 0:
- default:
- hdmi_dsc->max_slices = 0;
- hdmi_dsc->clk_per_slice = 0;
+ dsc_max_slices = hf_scds[12] & DRM_EDID_DSC_MAX_SLICES;
+
+ switch (dsc_max_slices) {
+ case 1:
+ hdmi_dsc->max_slices = 1;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 2:
+ hdmi_dsc->max_slices = 2;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 3:
+ hdmi_dsc->max_slices = 4;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 4:
+ hdmi_dsc->max_slices = 8;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 5:
+ hdmi_dsc->max_slices = 8;
+ hdmi_dsc->clk_per_slice = 400;
+ break;
+ case 6:
+ hdmi_dsc->max_slices = 12;
+ hdmi_dsc->clk_per_slice = 400;
+ break;
+ case 7:
+ hdmi_dsc->max_slices = 16;
+ hdmi_dsc->clk_per_slice = 400;
+ break;
+ case 0:
+ default:
+ hdmi_dsc->max_slices = 0;
+ hdmi_dsc->clk_per_slice = 0;
+ }
}
+
+ if (cea_db_payload_len(hf_scds) >= 13 && hf_scds[13])
+ hdmi_dsc->total_chunk_kbytes = hf_scds[13] &
DRM_EDID_DSC_TOTAL_CHUNK_KBYTES;
}
/* Sink Capability Data Structure */
@@ -5825,6 +5829,7 @@ static void drm_parse_hdmi_forum_scds(struct
drm_connector *connector,
{
struct drm_display_info *display = &connector->display_info;
struct drm_hdmi_info *hdmi = &display->hdmi;
+ struct drm_hdmi_dsc_cap *hdmi_dsc = &hdmi->dsc_cap;
display->has_hdmi_infoframe = true;
@@ -5865,17 +5870,17 @@ static void dr
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/display: Don't rewrite link config when setting phy test pattern
== Series Details == Series: drm/display: Don't rewrite link config when setting phy test pattern URL : https://patchwork.freedesktop.org/series/108633/ State : success == Summary == CI Bug Log - changes from CI_DRM_12144_full -> Patchwork_108633v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (11 -> 11) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_108633v1_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_balancer@parallel-bb-first: - shard-iclb: [PASS][1] -> [SKIP][2] ([i915#4525]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/shard-iclb4/igt@gem_exec_balan...@parallel-bb-first.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108633v1/shard-iclb7/igt@gem_exec_balan...@parallel-bb-first.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][3] -> [FAIL][4] ([i915#2846]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/shard-glk7/igt@gem_exec_f...@basic-deadline.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108633v1/shard-glk2/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-tglb: [PASS][5] -> [FAIL][6] ([i915#2842]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/shard-tglb1/igt@gem_exec_fair@basic-f...@rcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108633v1/shard-tglb6/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-none@vcs1: - shard-iclb: NOTRUN -> [FAIL][7] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108633v1/shard-iclb4/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-none@vecs0: - shard-glk: [PASS][8] -> [FAIL][9] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/shard-glk2/igt@gem_exec_fair@basic-n...@vecs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108633v1/shard-glk6/igt@gem_exec_fair@basic-n...@vecs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-apl: [PASS][10] -> [FAIL][11] ([i915#2842]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/shard-apl4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108633v1/shard-apl3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_lmem_swapping@verify-random: - shard-apl: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4613]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108633v1/shard-apl7/igt@gem_lmem_swapp...@verify-random.html * igt@gem_pxp@reject-modify-context-protection-off-3: - shard-apl: NOTRUN -> [SKIP][13] ([fdo#109271]) +33 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108633v1/shard-apl7/igt@gem_...@reject-modify-context-protection-off-3.html * igt@i915_pm_dc@dc6-dpms: - shard-iclb: [PASS][14] -> [FAIL][15] ([i915#454]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/shard-iclb6/igt@i915_pm...@dc6-dpms.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108633v1/shard-iclb3/igt@i915_pm...@dc6-dpms.html * igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs: - shard-apl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#3886]) +2 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108633v1/shard-apl7/igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs.html * igt@kms_chamelium@dp-hpd-with-enabled-mode: - shard-apl: NOTRUN -> [SKIP][17] ([fdo#109271] / [fdo#111827]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108633v1/shard-apl7/igt@kms_chamel...@dp-hpd-with-enabled-mode.html * igt@kms_cursor_crc@cursor-suspend@pipe-c-dp-1: - shard-apl: [PASS][18] -> [DMESG-WARN][19] ([i915#180]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/shard-apl7/igt@kms_cursor_crc@cursor-susp...@pipe-c-dp-1.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108633v1/shard-apl2/igt@kms_cursor_crc@cursor-susp...@pipe-c-dp-1.html * igt@kms_flip_scaled_crc@flip-64bpp-4tile-to-32bpp-4tile-upscaling@pipe-a-default-mode: - shard-iclb: NOTRUN -> [SKIP][20] ([i915#2672]) +1 similar issue [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108633v1/shard-iclb2/igt@kms_flip_scaled_crc@flip-64bpp-4tile-to-32bpp-4tile-upscal...@pipe-a-default-mode.html * igt@kms_flip_scaled_crc@flip-64bpp-4tile-to-32bpp-4tiledg2rcccs-downscaling@pipe-a-valid-mode: - shard-iclb: NOTRUN -> [SKIP][21] ([i915#2587] / [i915#2672]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108633v1/shard-iclb4/igt@kms_flip_scaled_crc@flip-64bpp-
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/pps: Add get_pps_idx() hook as part of pps_get_register() cleanup
== Series Details ==
Series: series starting with [1/2] drm/i915/pps: Add get_pps_idx() hook as part
of pps_get_register() cleanup
URL : https://patchwork.freedesktop.org/series/108643/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12145 -> Patchwork_108643v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108643v1/index.html
Participating hosts (44 -> 41)
--
Additional (2): fi-apl-guc bat-dg1-5
Missing(5): fi-hsw-4200u fi-icl-u2 fi-ctg-p8600 bat-dg2-11 fi-bdw-samus
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_108643v1:
### 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:
- {fi-tgl-mst}: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/fi-tgl-mst/igt@i915_pm_...@module-reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108643v1/fi-tgl-mst/igt@i915_pm_...@module-reload.html
Known issues
Here are the changes found in Patchwork_108643v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@fbdev@nullptr:
- bat-dg1-5: NOTRUN -> [SKIP][3] ([i915#2582]) +4 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108643v1/bat-dg1-5/igt@fb...@nullptr.html
* igt@gem_mmap@basic:
- bat-dg1-5: NOTRUN -> [SKIP][4] ([i915#4083])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108643v1/bat-dg1-5/igt@gem_m...@basic.html
* igt@gem_tiled_blits@basic:
- bat-dg1-5: NOTRUN -> [SKIP][5] ([i915#4077]) +2 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108643v1/bat-dg1-5/igt@gem_tiled_bl...@basic.html
* igt@gem_tiled_pread_basic:
- bat-dg1-5: NOTRUN -> [SKIP][6] ([i915#4079]) +1 similar issue
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108643v1/bat-dg1-5/igt@gem_tiled_pread_basic.html
* igt@i915_pm_backlight@basic-brightness:
- bat-dg1-5: NOTRUN -> [SKIP][7] ([i915#1155])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108643v1/bat-dg1-5/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_pm_rps@basic-api:
- bat-dg1-5: NOTRUN -> [SKIP][8] ([i915#6621])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108643v1/bat-dg1-5/igt@i915_pm_...@basic-api.html
* igt@i915_selftest@live@gt_engines:
- bat-dg1-5: NOTRUN -> [INCOMPLETE][9] ([i915#4418])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108643v1/bat-dg1-5/igt@i915_selftest@live@gt_engines.html
* igt@i915_selftest@live@requests:
- fi-pnv-d510:[PASS][10] -> [DMESG-FAIL][11] ([i915#4528])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/fi-pnv-d510/igt@i915_selftest@l...@requests.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108643v1/fi-pnv-d510/igt@i915_selftest@l...@requests.html
* igt@kms_addfb_basic@basic-x-tiled-legacy:
- bat-dg1-5: NOTRUN -> [SKIP][12] ([i915#4212]) +7 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108643v1/bat-dg1-5/igt@kms_addfb_ba...@basic-x-tiled-legacy.html
* igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-dg1-5: NOTRUN -> [SKIP][13] ([i915#4215])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108643v1/bat-dg1-5/igt@kms_addfb_ba...@basic-y-tiled-legacy.html
* igt@kms_busy@basic:
- bat-dg1-5: NOTRUN -> [SKIP][14] ([i915#1845] / [i915#4303])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108643v1/bat-dg1-5/igt@kms_b...@basic.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-bsw-nick:NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108643v1/fi-bsw-nick/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@dp-crc-fast:
- bat-dg1-5: NOTRUN -> [SKIP][16] ([fdo#111827]) +7 similar issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108643v1/bat-dg1-5/igt@kms_chamel...@dp-crc-fast.html
*
igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size:
- fi-bsw-kefka: [PASS][17] -> [FAIL][18] ([i915#6298])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108643v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
* igt@kms_force_connector_basic@force-load-detect:
- bat-dg1-5: NO
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gem: Really move i915_gem_context.link under ref protection (rev4)
== Series Details ==
Series: drm/i915/gem: Really move i915_gem_context.link under ref protection
(rev4)
URL : https://patchwork.freedesktop.org/series/105975/
State : warning
== Summary ==
Error: dim checkpatch failed
92e95a1dfeb3 drm/i915/gem: Flush contexts on driver release
36b9001b483b drm/i915/gem: Really move i915_gem_context.link under ref
protection
-:67: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit a4e7ccdac38e ("drm/i915: Move
context management under GEM")'
#67:
References: a4e7ccdac38e ("drm/i915: Move context management under GEM")
total: 1 errors, 0 warnings, 0 checks, 20 lines checked
Re: [Intel-gfx] [RFC 1/1] drm/i915/dgfx: Handling of pin_map against rpm
> -Original Message-
> From: Tvrtko Ursulin
> Sent: Thursday, September 15, 2022 10:37 PM
> To: Gupta, Anshuman ; intel-
> g...@lists.freedesktop.org
> Cc: Auld, Matthew ; Vivi, Rodrigo
>
> Subject: Re: [Intel-gfx] [RFC 1/1] drm/i915/dgfx: Handling of pin_map against
> rpm
>
>
> On 15/09/2022 11:33, Anshuman Gupta wrote:
> > If i915 gem obj lies in lmem, then i915_gem_object_pin_map need to
> > grab a rpm wakeref to make sure gfx PCIe endpoint function stays in D0
> > state during any access to mapping returned by
> > i915_gem_object_pin_map().
> > Subsequently i915_gem_object_upin_map will put the wakref as well.
>
> Another thing to check are perma pinned contexts. Follow the flow from
> intel_engine_create_pinned_context to intel_engine_destroy_pinned_context.
> If you find out that kernel (&co) contexts are pinned for the duration of i915
> load/bind and that they use lmem objects, that would mean wakeref is held for
> the duration of i915 loaded state. Defeating the point and making the solution
> effectively equal to just disabling RPM.
That’s correct intel_ring_pin can pin_map the lmem object.
if (i915_vma_is_map_and_fenceable(vma)) {
addr = (void __force *)i915_vma_pin_iomap(vma);
} else {
int type = i915_coherent_map_type(vma->vm->i915, vma->obj,
false);
addr = i915_gem_object_pin_map(vma->obj, type);
}
If that is the case this RFC proposal will not work and in that case every
caller of i915_gem_object_pin_map need to grab the wakreref before
accessing the retuned address by pin_map. Any inputs from you side for any
other approach.
Thanks,
Anshuman Gupta.
>
> Regards,
>
> Tvrtko
>
> > Cc: Matthew Auld
> > Cc: Rodrigo Vivi
> > Cc: Andi Shyti
> > Signed-off-by: Anshuman Gupta
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_object.c | 2 ++
> > drivers/gpu/drm/i915/gem/i915_gem_object.h | 5 +
> > drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 14 ++
> > drivers/gpu/drm/i915/gem/i915_gem_pages.c| 8
> > 4 files changed, 29 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > index 85482a04d158..f291f990838d 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > @@ -95,6 +95,7 @@ void i915_gem_object_init(struct drm_i915_gem_object
> *obj,
> > mutex_init(&obj->mm.get_page.lock);
> > INIT_RADIX_TREE(&obj->mm.get_dma_page.radix, GFP_KERNEL |
> __GFP_NOWARN);
> > mutex_init(&obj->mm.get_dma_page.lock);
> > + mutex_init(&obj->wakeref_lock);
> > }
> >
> > /**
> > @@ -110,6 +111,7 @@ void __i915_gem_object_fini(struct
> drm_i915_gem_object *obj)
> > {
> > mutex_destroy(&obj->mm.get_page.lock);
> > mutex_destroy(&obj->mm.get_dma_page.lock);
> > + mutex_destroy(&obj->wakeref_lock);
> > dma_resv_fini(&obj->base._resv);
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> > b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> > index 7317d4102955..b31ac6e4c272 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> > @@ -501,6 +501,11 @@ static inline void i915_gem_object_flush_map(struct
> drm_i915_gem_object *obj)
> >*/
> > static inline void i915_gem_object_unpin_map(struct drm_i915_gem_object
> *obj)
> > {
> > + mutext_lock(obj->wakeref_lock);
> > + if (!--obj->wakeref_count)
> > + intel_runtime_pm_put(&to_i915(obj->base.dev)->runtime_pm,
> obj->wakeref);
> > + mutext_unlock(obj->wakeref_lock);
> > +
> > i915_gem_object_unpin_pages(obj);
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > index 9f6b14ec189a..34aff95a1984 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > @@ -657,6 +657,20 @@ struct drm_i915_gem_object {
> >
> > void *gvt_info;
> > };
> > +
> > + /**
> > +* wakeref to protect the i915 lmem iomem mappings.
> > +* We don't pin_map an object partially that makes easy
> > +* to track the wakeref cookie, if wakeref is already held
> > +* then we don't need to grab it again for other pin_map.
> > +* first pin_map will grab the wakeref and last unpin_map
> > +* will put the wakeref.
> > +*/
> > + intel_wakeref_t wakeref;
> > + unsigned int wakeref_count;
> > +
> > + /** protects the wakeref_count wakeref cookie against multiple
> pin_map and unpin_map */
> > + struct mutex wakeref_lock;
> > };
> >
> > static inline struct drm_i915_gem_object * diff --git
> > a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> > index 4df50b049cea..b638b5413280 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> > +++ b/driv
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gem: Really move i915_gem_context.link under ref protection (rev4)
== Series Details ==
Series: drm/i915/gem: Really move i915_gem_context.link under ref protection
(rev4)
URL : https://patchwork.freedesktop.org/series/105975/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12145 -> Patchwork_105975v4
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/index.html
Participating hosts (44 -> 40)
--
Additional (2): fi-apl-guc bat-dg1-5
Missing(6): fi-rkl-11600 fi-hsw-4200u fi-icl-u2 fi-ctg-p8600 bat-dg2-11
fi-bdw-samus
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_105975v4:
### 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_pm:
- {bat-adln-1}: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/bat-adln-1/igt@i915_selftest@live@gt_pm.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/bat-adln-1/igt@i915_selftest@live@gt_pm.html
Known issues
Here are the changes found in Patchwork_105975v4 that come from known issues:
### IGT changes ###
Issues hit
* igt@fbdev@nullptr:
- bat-dg1-5: NOTRUN -> [SKIP][3] ([i915#2582]) +4 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/bat-dg1-5/igt@fb...@nullptr.html
* igt@gem_mmap@basic:
- bat-dg1-5: NOTRUN -> [SKIP][4] ([i915#4083])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/bat-dg1-5/igt@gem_m...@basic.html
* igt@gem_tiled_blits@basic:
- bat-dg1-5: NOTRUN -> [SKIP][5] ([i915#4077]) +2 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/bat-dg1-5/igt@gem_tiled_bl...@basic.html
* igt@gem_tiled_pread_basic:
- bat-dg1-5: NOTRUN -> [SKIP][6] ([i915#4079]) +1 similar issue
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/bat-dg1-5/igt@gem_tiled_pread_basic.html
* igt@i915_pm_backlight@basic-brightness:
- bat-dg1-5: NOTRUN -> [SKIP][7] ([i915#1155])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/bat-dg1-5/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_pm_rps@basic-api:
- bat-dg1-5: NOTRUN -> [SKIP][8] ([i915#6621])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/bat-dg1-5/igt@i915_pm_...@basic-api.html
* igt@kms_addfb_basic@basic-x-tiled-legacy:
- bat-dg1-5: NOTRUN -> [SKIP][9] ([i915#4212]) +7 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/bat-dg1-5/igt@kms_addfb_ba...@basic-x-tiled-legacy.html
* igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-dg1-5: NOTRUN -> [SKIP][10] ([i915#4215])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/bat-dg1-5/igt@kms_addfb_ba...@basic-y-tiled-legacy.html
* igt@kms_busy@basic:
- bat-dg1-5: NOTRUN -> [SKIP][11] ([i915#1845] / [i915#4303])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/bat-dg1-5/igt@kms_b...@basic.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-bsw-nick:NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/fi-bsw-nick/igt@kms_chamel...@common-hpd-after-suspend.html
- fi-blb-e6850: NOTRUN -> [SKIP][13] ([fdo#109271])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/fi-blb-e6850/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@dp-crc-fast:
- bat-dg1-5: NOTRUN -> [SKIP][14] ([fdo#111827]) +8 similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/bat-dg1-5/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_force_connector_basic@force-load-detect:
- bat-dg1-5: NOTRUN -> [SKIP][15] ([fdo#109285])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/bat-dg1-5/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_pipe_crc_basic@nonblocking-crc:
- bat-dg1-5: NOTRUN -> [SKIP][16] ([i915#4078]) +14 similar issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/bat-dg1-5/igt@kms_pipe_crc_ba...@nonblocking-crc.html
* igt@kms_pipe_crc_basic@suspend-read-crc:
- fi-bsw-nick:NOTRUN -> [SKIP][17] ([fdo#109271])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/fi-bsw-nick/igt@kms_pipe_crc_ba...@suspend-read-crc.html
* igt@kms_psr@primary_page_flip:
- bat-dg1-5: NOTRUN -> [SKIP][18] ([i915#1072] / [i915#4078]) +3
similar issues
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/bat-dg1-5/igt@kms_psr@primary_pa
Re: [Intel-gfx] [RFC 1/1] drm/i915/dgfx: Handling of pin_map against rpm
On 16/09/2022 11:30, Gupta, Anshuman wrote:
-Original Message-
From: Tvrtko Ursulin
Sent: Thursday, September 15, 2022 10:37 PM
To: Gupta, Anshuman ; intel-
g...@lists.freedesktop.org
Cc: Auld, Matthew ; Vivi, Rodrigo
Subject: Re: [Intel-gfx] [RFC 1/1] drm/i915/dgfx: Handling of pin_map against
rpm
On 15/09/2022 11:33, Anshuman Gupta wrote:
If i915 gem obj lies in lmem, then i915_gem_object_pin_map need to
grab a rpm wakeref to make sure gfx PCIe endpoint function stays in D0
state during any access to mapping returned by
i915_gem_object_pin_map().
Subsequently i915_gem_object_upin_map will put the wakref as well.
Another thing to check are perma pinned contexts. Follow the flow from
intel_engine_create_pinned_context to intel_engine_destroy_pinned_context.
If you find out that kernel (&co) contexts are pinned for the duration of i915
load/bind and that they use lmem objects, that would mean wakeref is held for
the duration of i915 loaded state. Defeating the point and making the solution
effectively equal to just disabling RPM.
That’s correct intel_ring_pin can pin_map the lmem object.
if (i915_vma_is_map_and_fenceable(vma)) {
addr = (void __force *)i915_vma_pin_iomap(vma);
} else {
int type = i915_coherent_map_type(vma->vm->i915, vma->obj,
false);
addr = i915_gem_object_pin_map(vma->obj, type);
}
If that is the case this RFC proposal will not work and in that case
Right, or LRC state for perma pinned contexts is probably even more
clear cut.
every caller of i915_gem_object_pin_map need to grab the wakreref before
accessing the retuned address by pin_map. Any inputs from you side for any
other approach.
I didn't quite get what you meant here.
My point was that if my thinking that perma pinned contexts would hold
the wakeref permanently is correct, that would prevent the approach from
this patch to have a different effect from just disabling RPM. Would
unpinning the perma pinned contexts on GT park be feasible? It's not a 5
minute question and unfortunately I don't have enough time to go deep
into this problem space. Like Hopefully someone else can jump in.
Regards,
Tvrtko
Re: [Intel-gfx] [PATCH 2/2] drm/i915/pps: Enable 2nd pps for dual EDP scenario
> -Original Message-
> From: Ville Syrjälä
> Sent: Friday, September 16, 2022 2:28 PM
> To: Manna, Animesh
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani ;
> Shankar, Uma
> Subject: Re: [PATCH 2/2] drm/i915/pps: Enable 2nd pps for dual EDP scenario
>
> On Fri, Sep 16, 2022 at 02:01:02PM +0530, Animesh Manna wrote:
> > >From display gen12 onwards to support dual EDP two instances of pps added.
> > Currently backlight controller and pps instance can be mapped together
> > for a specific panel. Extended support for gen12 for dual EDP usage.
> >
> > v1: Iniital revision
> > v2: Called intel_bios_panel_init w/o PNPID before intel_pps_init.
> > [Jani]
> >
> > Cc: Jani Nikula
> > Cc: Ville Syrjälä
> > Cc: Uma Shankar
> > Signed-off-by: Animesh Manna
> > ---
> > drivers/gpu/drm/i915/display/intel_bios.c | 7 ---
> > drivers/gpu/drm/i915/display/intel_bios.h | 7 +++
> > drivers/gpu/drm/i915/display/intel_dp.c | 9 ++---
> > drivers/gpu/drm/i915/display/intel_pps.c | 2 +-
> > 4 files changed, 14 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> > b/drivers/gpu/drm/i915/display/intel_bios.c
> > index 28bdb936cd1f..5fd4c09dfa96 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bios.c
> > +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> > @@ -706,13 +706,6 @@ static int fallback_get_panel_type(struct
> drm_i915_private *i915,
> > return 0;
> > }
> >
> > -enum panel_type {
> > - PANEL_TYPE_OPREGION,
> > - PANEL_TYPE_VBT,
> > - PANEL_TYPE_PNPID,
> > - PANEL_TYPE_FALLBACK,
> > -};
> > -
> > static int get_panel_type(struct drm_i915_private *i915,
> > const struct intel_bios_encoder_data *devdata,
> > const struct edid *edid)
> > diff --git a/drivers/gpu/drm/i915/display/intel_bios.h
> > b/drivers/gpu/drm/i915/display/intel_bios.h
> > index e375405a7828..da01b13260ae 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bios.h
> > +++ b/drivers/gpu/drm/i915/display/intel_bios.h
> > @@ -231,6 +231,13 @@ struct mipi_pps_data {
> > u16 panel_power_cycle_delay;
> > } __packed;
> >
> > +enum panel_type {
> > + PANEL_TYPE_OPREGION,
> > + PANEL_TYPE_VBT,
> > + PANEL_TYPE_PNPID,
> > + PANEL_TYPE_FALLBACK,
> > +};
> > +
> > void intel_bios_init(struct drm_i915_private *dev_priv); void
> > intel_bios_init_panel(struct drm_i915_private *dev_priv,
> >struct intel_panel *panel,
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index c19e99ee06b6..6f7afa75ec4d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -5222,6 +5222,9 @@ static bool intel_edp_init_connector(struct intel_dp
> *intel_dp,
> > return false;
> > }
> >
> > + intel_bios_init_panel(dev_priv, &intel_connector->panel,
> > + encoder->devdata, NULL);
>
> We don't want to go for the fallback type here if we the VBT wants us to use
> pnpid. Maybe we should just remove the fallback type entirely? Or perhaps only
> use it if the VBT panel type is entirely invalid?
Ok, Can I add like below?
If (!PANEL_TYPE_FALLBACK)
intel_pps_init(intel_dp);
But to read EDID pps_init should be called before it. Or else I can enable both
the pps and later disable the unused one.
Regards,
Animesh
> > +
> > intel_pps_init(intel_dp);
> >
> > /* Cache DPCD and EDID for edp. */
> > @@ -5255,9 +5258,9 @@ static bool intel_edp_init_connector(struct intel_dp
> *intel_dp,
> > edid = ERR_PTR(-ENOENT);
> > }
> > intel_connector->edid = edid;
> > -
> > - intel_bios_init_panel(dev_priv, &intel_connector->panel,
> > - encoder->devdata, IS_ERR(edid) ? NULL : edid);
> > + if (intel_connector->panel.vbt.panel_type == PANEL_TYPE_FALLBACK)
> > + intel_bios_init_panel(dev_priv, &intel_connector->panel,
> > + encoder->devdata, IS_ERR(edid) ? NULL :
> edid);
> >
> > intel_panel_add_edid_fixed_modes(intel_connector,
> > intel_connector->panel.vbt.drrs_type
> != DRRS_TYPE_NONE, diff
> > --git a/drivers/gpu/drm/i915/display/intel_pps.c
> > b/drivers/gpu/drm/i915/display/intel_pps.c
> > index b972fa6ec00d..4b8413382c5d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_pps.c
> > +++ b/drivers/gpu/drm/i915/display/intel_pps.c
> > @@ -1430,7 +1430,7 @@ void intel_pps_init(struct intel_dp *intel_dp)
> > intel_dp->pps.initializing = true;
> > INIT_DELAYED_WORK(&intel_dp->pps.panel_vdd_work,
> > edp_panel_vdd_work);
> >
> > - if (IS_GEMINILAKE(i915) || IS_BROXTON(i915))
> > + if (IS_GEMINILAKE(i915) || IS_BROXTON(i915) || DISPLAY_VER(i915) >=
> > +12)
> > intel_dp->get_pps_idx = bxt_power_sequencer_idx;
> > else if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
> > intel_dp->get_pps_idx = vlv_powe
[Intel-gfx] [PATCH] drm/i915/psr: Do not re-activate PSR if there was a PSR aux error
If there is a PSR aux error sink is marked as not reliable
and PSR is permantently disabled.
Current code is activating PSR again even there was PSR aux error.
Fix this by skipping intel_psr_activate when PSR aux error is
detected.
Cc: Mika Kahola
Cc: José Roberto de Souza
Reported-by: Charlton Lin
Signed-off-by: Jouni Högander
---
drivers/gpu/drm/i915/display/intel_psr.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index 9def8d9fade6..42390203ad19 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -2153,8 +2153,10 @@ static void intel_psr_work(struct work_struct *work)
if (!intel_dp->psr.enabled)
goto unlock;
- if (READ_ONCE(intel_dp->psr.irq_aux_error))
+ if (READ_ONCE(intel_dp->psr.irq_aux_error)) {
intel_psr_handle_irq(intel_dp);
+ goto unlock;
+ }
/*
* We have to make sure PSR is ready for re-enable
--
2.34.1
[Intel-gfx] ✓ Fi.CI.BAT: success for Fix HFVSDB parsing (rev2)
== Series Details == Series: Fix HFVSDB parsing (rev2) URL : https://patchwork.freedesktop.org/series/107144/ State : success == Summary == CI Bug Log - changes from CI_DRM_12145 -> Patchwork_107144v2 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107144v2/index.html Participating hosts (44 -> 40) -- Additional (2): fi-apl-guc bat-dg1-5 Missing(6): fi-hsw-4200u fi-icl-u2 fi-kbl-guc fi-ctg-p8600 bat-dg2-11 fi-bdw-samus Known issues Here are the changes found in Patchwork_107144v2 that come from known issues: ### IGT changes ### Issues hit * igt@fbdev@nullptr: - bat-dg1-5: NOTRUN -> [SKIP][1] ([i915#2582]) +4 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107144v2/bat-dg1-5/igt@fb...@nullptr.html * igt@gem_mmap@basic: - bat-dg1-5: NOTRUN -> [SKIP][2] ([i915#4083]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107144v2/bat-dg1-5/igt@gem_m...@basic.html * igt@gem_tiled_blits@basic: - bat-dg1-5: NOTRUN -> [SKIP][3] ([i915#4077]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107144v2/bat-dg1-5/igt@gem_tiled_bl...@basic.html * igt@gem_tiled_pread_basic: - bat-dg1-5: NOTRUN -> [SKIP][4] ([i915#4079]) +1 similar issue [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107144v2/bat-dg1-5/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - bat-dg1-5: NOTRUN -> [SKIP][5] ([i915#1155]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107144v2/bat-dg1-5/igt@i915_pm_backli...@basic-brightness.html * igt@i915_pm_rps@basic-api: - bat-dg1-5: NOTRUN -> [SKIP][6] ([i915#6621]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107144v2/bat-dg1-5/igt@i915_pm_...@basic-api.html * igt@kms_addfb_basic@basic-x-tiled-legacy: - bat-dg1-5: NOTRUN -> [SKIP][7] ([i915#4212]) +7 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107144v2/bat-dg1-5/igt@kms_addfb_ba...@basic-x-tiled-legacy.html * igt@kms_addfb_basic@basic-y-tiled-legacy: - bat-dg1-5: NOTRUN -> [SKIP][8] ([i915#4215]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107144v2/bat-dg1-5/igt@kms_addfb_ba...@basic-y-tiled-legacy.html * igt@kms_busy@basic: - bat-dg1-5: NOTRUN -> [SKIP][9] ([i915#1845] / [i915#4303]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107144v2/bat-dg1-5/igt@kms_b...@basic.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-bsw-nick:NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107144v2/fi-bsw-nick/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_chamelium@dp-crc-fast: - bat-dg1-5: NOTRUN -> [SKIP][11] ([fdo#111827]) +8 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107144v2/bat-dg1-5/igt@kms_chamel...@dp-crc-fast.html * igt@kms_force_connector_basic@force-load-detect: - bat-dg1-5: NOTRUN -> [SKIP][12] ([fdo#109285]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107144v2/bat-dg1-5/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_pipe_crc_basic@nonblocking-crc: - bat-dg1-5: NOTRUN -> [SKIP][13] ([i915#4078]) +14 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107144v2/bat-dg1-5/igt@kms_pipe_crc_ba...@nonblocking-crc.html * igt@kms_pipe_crc_basic@suspend-read-crc: - fi-bsw-nick:NOTRUN -> [SKIP][14] ([fdo#109271]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107144v2/fi-bsw-nick/igt@kms_pipe_crc_ba...@suspend-read-crc.html * igt@kms_psr@primary_page_flip: - bat-dg1-5: NOTRUN -> [SKIP][15] ([i915#1072] / [i915#4078]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107144v2/bat-dg1-5/igt@kms_psr@primary_page_flip.html * igt@kms_setmode@basic-clone-single-crtc: - bat-dg1-5: NOTRUN -> [SKIP][16] ([i915#3555]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107144v2/bat-dg1-5/igt@kms_setm...@basic-clone-single-crtc.html * igt@prime_vgem@basic-fence-flip: - bat-dg1-5: NOTRUN -> [SKIP][17] ([i915#1845] / [i915#3708]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107144v2/bat-dg1-5/igt@prime_v...@basic-fence-flip.html * igt@prime_vgem@basic-fence-read: - bat-dg1-5: NOTRUN -> [SKIP][18] ([i915#3708]) +2 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107144v2/bat-dg1-5/igt@prime_v...@basic-fence-read.html * igt@prime_vgem@basic-gtt: - bat-dg1-5: NOTRUN -> [SKIP][19] ([i915#3708] / [i915#4077]) +1 similar issue [19]: https://
Re: [Intel-gfx] [PATCH 2/2] drm/i915/pps: Enable 2nd pps for dual EDP scenario
On Fri, 16 Sep 2022, "Manna, Animesh" wrote:
>> -Original Message-
>> From: Ville Syrjälä
>> Sent: Friday, September 16, 2022 2:28 PM
>> To: Manna, Animesh
>> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani ;
>> Shankar, Uma
>> Subject: Re: [PATCH 2/2] drm/i915/pps: Enable 2nd pps for dual EDP scenario
>>
>> On Fri, Sep 16, 2022 at 02:01:02PM +0530, Animesh Manna wrote:
>> > >From display gen12 onwards to support dual EDP two instances of pps added.
>> > Currently backlight controller and pps instance can be mapped together
>> > for a specific panel. Extended support for gen12 for dual EDP usage.
>> >
>> > v1: Iniital revision
>> > v2: Called intel_bios_panel_init w/o PNPID before intel_pps_init.
>> > [Jani]
>> >
>> > Cc: Jani Nikula
>> > Cc: Ville Syrjälä
>> > Cc: Uma Shankar
>> > Signed-off-by: Animesh Manna
>> > ---
>> > drivers/gpu/drm/i915/display/intel_bios.c | 7 ---
>> > drivers/gpu/drm/i915/display/intel_bios.h | 7 +++
>> > drivers/gpu/drm/i915/display/intel_dp.c | 9 ++---
>> > drivers/gpu/drm/i915/display/intel_pps.c | 2 +-
>> > 4 files changed, 14 insertions(+), 11 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
>> > b/drivers/gpu/drm/i915/display/intel_bios.c
>> > index 28bdb936cd1f..5fd4c09dfa96 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_bios.c
>> > +++ b/drivers/gpu/drm/i915/display/intel_bios.c
>> > @@ -706,13 +706,6 @@ static int fallback_get_panel_type(struct
>> drm_i915_private *i915,
>> > return 0;
>> > }
>> >
>> > -enum panel_type {
>> > - PANEL_TYPE_OPREGION,
>> > - PANEL_TYPE_VBT,
>> > - PANEL_TYPE_PNPID,
>> > - PANEL_TYPE_FALLBACK,
>> > -};
>> > -
>> > static int get_panel_type(struct drm_i915_private *i915,
>> > const struct intel_bios_encoder_data *devdata,
>> > const struct edid *edid)
>> > diff --git a/drivers/gpu/drm/i915/display/intel_bios.h
>> > b/drivers/gpu/drm/i915/display/intel_bios.h
>> > index e375405a7828..da01b13260ae 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_bios.h
>> > +++ b/drivers/gpu/drm/i915/display/intel_bios.h
>> > @@ -231,6 +231,13 @@ struct mipi_pps_data {
>> > u16 panel_power_cycle_delay;
>> > } __packed;
>> >
>> > +enum panel_type {
>> > + PANEL_TYPE_OPREGION,
>> > + PANEL_TYPE_VBT,
>> > + PANEL_TYPE_PNPID,
>> > + PANEL_TYPE_FALLBACK,
>> > +};
>> > +
I don't want enum panel_type exposed from intel_bios.c at all, there's
no reason for that.
>> > void intel_bios_init(struct drm_i915_private *dev_priv); void
>> > intel_bios_init_panel(struct drm_i915_private *dev_priv,
>> >struct intel_panel *panel,
>> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
>> > b/drivers/gpu/drm/i915/display/intel_dp.c
>> > index c19e99ee06b6..6f7afa75ec4d 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
>> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>> > @@ -5222,6 +5222,9 @@ static bool intel_edp_init_connector(struct intel_dp
>> *intel_dp,
>> > return false;
>> > }
>> >
>> > + intel_bios_init_panel(dev_priv, &intel_connector->panel,
>> > + encoder->devdata, NULL);
>>
>> We don't want to go for the fallback type here if we the VBT wants us to use
>> pnpid. Maybe we should just remove the fallback type entirely? Or perhaps
>> only
>> use it if the VBT panel type is entirely invalid?
>
> Ok, Can I add like below?
> If (!PANEL_TYPE_FALLBACK)
> intel_pps_init(intel_dp);
>
> But to read EDID pps_init should be called before it. Or else I can enable
> both the pps and later disable the unused one.
The first call should init everything if it can (panel type is *not*
pnpid). Fallback is fine in that case too.
If panel type indicates pnpid, intel_bios_init_panel() should set the
pps id to, say, -1, so intel_pps_init() or more specifically
bxt_power_sequencer_idx() can use some default or look at the hardware
or whatever.
intel_bios_init_panel() should probably also return a value on pnpid
indicating intel_edp_init_connector() should call
intel_bios_init_panel() again, this time with EDID. (Note: I kind of
like separating returning the value and setting the pps id to -1. I
don't want intel_edp_init_connector() to look at pps id, that's for pps,
and I don't want to pass flags all the way to bxt_power_sequencer_idx()
either.)
BR,
Jani.
>
> Regards,
> Animesh
>
>> > +
>> > intel_pps_init(intel_dp);
>> >
>> > /* Cache DPCD and EDID for edp. */
>> > @@ -5255,9 +5258,9 @@ static bool intel_edp_init_connector(struct intel_dp
>> *intel_dp,
>> > edid = ERR_PTR(-ENOENT);
>> > }
>> > intel_connector->edid = edid;
>> > -
>> > - intel_bios_init_panel(dev_priv, &intel_connector->panel,
>> > - encoder->devdata, IS_ERR(edid) ? NULL : edid);
>> > + if (intel_connector->panel.vbt.panel_type == PANEL_TYPE_FALLBACK)
>> > + intel_bios_init_panel(dev_priv, &intel_connector->panel,
>> > +
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: Don't disable DDI/Transcoder when setting phy test pattern
== Series Details == Series: drm/i915/display: Don't disable DDI/Transcoder when setting phy test pattern URL : https://patchwork.freedesktop.org/series/108636/ State : success == Summary == CI Bug Log - changes from CI_DRM_12144_full -> Patchwork_108636v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (11 -> 11) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_108636v1_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_balancer@parallel-bb-first: - shard-iclb: [PASS][1] -> [SKIP][2] ([i915#4525]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/shard-iclb4/igt@gem_exec_balan...@parallel-bb-first.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108636v1/shard-iclb8/igt@gem_exec_balan...@parallel-bb-first.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][3] -> [FAIL][4] ([i915#2846]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/shard-glk7/igt@gem_exec_f...@basic-deadline.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108636v1/shard-glk7/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-solo@rcs0: - shard-apl: [PASS][5] -> [FAIL][6] ([i915#2842]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/shard-apl6/igt@gem_exec_fair@basic-none-s...@rcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108636v1/shard-apl3/igt@gem_exec_fair@basic-none-s...@rcs0.html * igt@gem_lmem_swapping@verify-random: - shard-apl: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108636v1/shard-apl7/igt@gem_lmem_swapp...@verify-random.html * igt@gem_pxp@reject-modify-context-protection-off-3: - shard-apl: NOTRUN -> [SKIP][8] ([fdo#109271]) +33 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108636v1/shard-apl7/igt@gem_...@reject-modify-context-protection-off-3.html * igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs: - shard-apl: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#3886]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108636v1/shard-apl7/igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs.html * igt@kms_chamelium@dp-hpd-with-enabled-mode: - shard-apl: NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108636v1/shard-apl7/igt@kms_chamel...@dp-hpd-with-enabled-mode.html * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy: - shard-glk: [PASS][11] -> [FAIL][12] ([i915#72]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/shard-glk2/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108636v1/shard-glk6/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html * igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions-varying-size: - shard-iclb: [PASS][13] -> [FAIL][14] ([i915#2346]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/shard-iclb8/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108636v1/shard-iclb7/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html * igt@kms_fbcon_fbt@fbc-suspend: - shard-apl: [PASS][15] -> [FAIL][16] ([i915#4767]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/shard-apl4/igt@kms_fbcon_...@fbc-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108636v1/shard-apl1/igt@kms_fbcon_...@fbc-suspend.html * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ab-hdmi-a1-hdmi-a2: - shard-glk: [PASS][17] -> [FAIL][18] ([i915#2122]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/shard-glk9/igt@kms_flip@2x-flip-vs-expired-vblank-interrupti...@ab-hdmi-a1-hdmi-a2.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108636v1/shard-glk7/igt@kms_flip@2x-flip-vs-expired-vblank-interrupti...@ab-hdmi-a1-hdmi-a2.html * igt@kms_flip@2x-flip-vs-expired-vblank@bc-hdmi-a1-hdmi-a2: - shard-glk: [PASS][19] -> [FAIL][20] ([i915#79]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12144/shard-glk6/igt@kms_flip@2x-flip-vs-expired-vbl...@bc-hdmi-a1-hdmi-a2.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108636v1/shard-glk2/igt@kms_flip@2x-flip-vs-expired-vbl...@bc-hdmi-a1-hdmi-a2.html * igt@kms_flip_scaled_crc@flip-32bpp-4tile-to-64bpp-4tile-downscaling@pipe-a-valid-mode: - shard-iclb: NOTRUN -> [SKIP][21] ([i915#2587] / [i915#2672]) +6 similar iss
[Intel-gfx] [PATCH] drm/i915/display: remove ipc_enabled from struct drm_i915_private
The ipc_enabled member was supposed to be moved under the display wm
sub-struct, but due to a rebase fail only the new one was added and the
old one was left behind. Finish the job.
Fixes: 70296670f672 ("drm/i915/display: move IPC under display wm sub-struct")
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9f9372931fd2..bdc81db76dbd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -397,8 +397,6 @@ struct drm_i915_private {
*/
u8 snps_phy_failed_calibration;
- bool ipc_enabled;
-
struct i915_pmu pmu;
struct i915_drm_clients clients;
--
2.34.1
Re: [Intel-gfx] [PATCH] drm/i915/psr: Do not re-activate PSR if there was a PSR aux error
Looks good to me.
Reviewed-by: Gwan-gyeong Mun
On 9/16/22 2:08 PM, Jouni Högander wrote:
If there is a PSR aux error sink is marked as not reliable
and PSR is permantently disabled.
Current code is activating PSR again even there was PSR aux error.
Fix this by skipping intel_psr_activate when PSR aux error is
detected.
Cc: Mika Kahola
Cc: José Roberto de Souza
Reported-by: Charlton Lin
Signed-off-by: Jouni Högander
---
drivers/gpu/drm/i915/display/intel_psr.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index 9def8d9fade6..42390203ad19 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -2153,8 +2153,10 @@ static void intel_psr_work(struct work_struct *work)
if (!intel_dp->psr.enabled)
goto unlock;
- if (READ_ONCE(intel_dp->psr.irq_aux_error))
+ if (READ_ONCE(intel_dp->psr.irq_aux_error)) {
intel_psr_handle_irq(intel_dp);
+ goto unlock;
+ }
/*
* We have to make sure PSR is ready for re-enable
Re: [Intel-gfx] [PATCH] drm/i915/display: remove ipc_enabled from struct drm_i915_private
On Fri, Sep 16, 2022 at 02:38:50PM +0300, Jani Nikula wrote:
> The ipc_enabled member was supposed to be moved under the display wm
> sub-struct, but due to a rebase fail only the new one was added and the
> old one was left behind. Finish the job.
>
> Fixes: 70296670f672 ("drm/i915/display: move IPC under display wm sub-struct")
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 9f9372931fd2..bdc81db76dbd 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -397,8 +397,6 @@ struct drm_i915_private {
>*/
> u8 snps_phy_failed_calibration;
>
> - bool ipc_enabled;
> -
> struct i915_pmu pmu;
>
> struct i915_drm_clients clients;
> --
> 2.34.1
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH] drm/i915: fix device info for devices without display
Looks good to me
Reviewed-by: Gwan-gyeong Mun
On 9/16/22 11:26 AM, Jani Nikula wrote:
Commit 00c6cbfd4e8a ("drm/i915: move pipe_mask and cpu_transcoder_mask
to runtime info") moved the pipe_mask member from struct
intel_device_info to intel_runtime_info, but overlooked some of our
platforms initializing device info .display = {}. This is significant,
as pipe_mask is the single point of truth for a device having a display
or not; the platforms in question left pipe_mask to whatever was set for
the platforms they "inherit" from in the complex macro scheme we have.
Add new NO_DISPLAY macro initializing .__runtime.pipe_mask = 0, which
will cause the device info .display sub-struct to be zeroed in
intel_device_info_runtime_init(). A better solution (or simply audit of
proper use of HAS_DISPLAY() checks) is required before moving forward
with [1].
Also clear all the display related members in runtime info if there's no
display. The latter is a bit tedious, but it's for completeness at this
time, to ensure similar functionality as before.
[1]
https://lore.kernel.org/r/dfda1bf67f02ceb07c280b7a13216405fd1f7a34.1660137416.git.jani.nik...@intel.com
Fixes: 00c6cbfd4e8a ("drm/i915: move pipe_mask and cpu_transcoder_mask to runtime
info")
Cc: Lucas De Marchi
Cc: Maarten Lankhort
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_pci.c | 11 ++-
drivers/gpu/drm/i915/intel_device_info.c | 6 ++
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 77e7df21f539..cd4487a1d3be 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -41,6 +41,8 @@
.__runtime.media.ip.ver = (x), \
.__runtime.display.ip.ver = (x)
+#define NO_DISPLAY .__runtime.pipe_mask = 0
+
#define I845_PIPE_OFFSETS \
.display.pipe_offsets = { \
[TRANSCODER_A] = PIPE_A_OFFSET, \
@@ -519,9 +521,8 @@ static const struct intel_device_info ivb_m_gt2_info = {
static const struct intel_device_info ivb_q_info = {
GEN7_FEATURES,
PLATFORM(INTEL_IVYBRIDGE),
+ NO_DISPLAY,
.gt = 2,
- .__runtime.pipe_mask = 0, /* legal, last one wins */
- .__runtime.cpu_transcoder_mask = 0,
.has_l3_dpf = 1,
};
@@ -1039,7 +1040,7 @@ static const struct intel_device_info xehpsdv_info = {
XE_HPM_FEATURES,
DGFX_FEATURES,
PLATFORM(INTEL_XEHPSDV),
- .display = { },
+ NO_DISPLAY,
.has_64k_pages = 1,
.needs_compact_pt = 1,
.has_media_ratio_mode = 1,
@@ -1081,7 +1082,7 @@ static const struct intel_device_info dg2_info = {
static const struct intel_device_info ats_m_info = {
DG2_FEATURES,
- .display = { 0 },
+ NO_DISPLAY,
.require_force_probe = 1,
.tuning_thread_rr_after_dep = 1,
};
@@ -1103,7 +1104,7 @@ static const struct intel_device_info pvc_info = {
.__runtime.graphics.ip.rel = 60,
.__runtime.media.ip.rel = 60,
PLATFORM(INTEL_PONTEVECCHIO),
- .display = { 0 },
+ NO_DISPLAY,
.has_flat_ccs = 0,
.__runtime.platform_engine_mask =
BIT(BCS0) |
diff --git a/drivers/gpu/drm/i915/intel_device_info.c
b/drivers/gpu/drm/i915/intel_device_info.c
index 1434dc33cf49..20575eb77ea7 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -433,8 +433,14 @@ void intel_device_info_runtime_init(struct
drm_i915_private *dev_priv)
dev_priv->drm.driver_features &= ~(DRIVER_MODESET |
DRIVER_ATOMIC);
memset(&info->display, 0, sizeof(info->display));
+
+ runtime->cpu_transcoder_mask = 0;
memset(runtime->num_sprites, 0, sizeof(runtime->num_sprites));
memset(runtime->num_scalers, 0, sizeof(runtime->num_scalers));
+ runtime->fbc_mask = 0;
+ runtime->has_hdcp = false;
+ runtime->has_dmc = false;
+ runtime->has_dsc = false;
}
}
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/psr: Do not re-activate PSR if there was a PSR aux error
== Series Details ==
Series: drm/i915/psr: Do not re-activate PSR if there was a PSR aux error
URL : https://patchwork.freedesktop.org/series/108653/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12145 -> Patchwork_108653v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108653v1/index.html
Participating hosts (44 -> 42)
--
Additional (3): bat-jsl-1 fi-apl-guc bat-dg1-5
Missing(5): fi-rkl-11600 fi-hsw-4200u fi-ctg-p8600 bat-dg2-11
fi-bdw-samus
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_108653v1:
### 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:
- {fi-tgl-mst}: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/fi-tgl-mst/igt@i915_pm_...@module-reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108653v1/fi-tgl-mst/igt@i915_pm_...@module-reload.html
Known issues
Here are the changes found in Patchwork_108653v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@fbdev@nullptr:
- bat-dg1-5: NOTRUN -> [SKIP][3] ([i915#2582]) +4 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108653v1/bat-dg1-5/igt@fb...@nullptr.html
* igt@gem_mmap@basic:
- bat-dg1-5: NOTRUN -> [SKIP][4] ([i915#4083])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108653v1/bat-dg1-5/igt@gem_m...@basic.html
* igt@gem_tiled_blits@basic:
- bat-dg1-5: NOTRUN -> [SKIP][5] ([i915#4077]) +2 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108653v1/bat-dg1-5/igt@gem_tiled_bl...@basic.html
* igt@gem_tiled_pread_basic:
- bat-dg1-5: NOTRUN -> [SKIP][6] ([i915#4079]) +1 similar issue
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108653v1/bat-dg1-5/igt@gem_tiled_pread_basic.html
* igt@i915_pm_backlight@basic-brightness:
- bat-dg1-5: NOTRUN -> [SKIP][7] ([i915#1155])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108653v1/bat-dg1-5/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_pm_rps@basic-api:
- bat-dg1-5: NOTRUN -> [SKIP][8] ([i915#6621])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108653v1/bat-dg1-5/igt@i915_pm_...@basic-api.html
* igt@i915_selftest@live@hangcheck:
- fi-ivb-3770:[PASS][9] -> [INCOMPLETE][10] ([i915#3303] /
[i915#5370])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/fi-ivb-3770/igt@i915_selftest@l...@hangcheck.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108653v1/fi-ivb-3770/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@requests:
- fi-pnv-d510:[PASS][11] -> [DMESG-FAIL][12] ([i915#4528])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/fi-pnv-d510/igt@i915_selftest@l...@requests.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108653v1/fi-pnv-d510/igt@i915_selftest@l...@requests.html
* igt@kms_addfb_basic@basic-x-tiled-legacy:
- bat-dg1-5: NOTRUN -> [SKIP][13] ([i915#4212]) +7 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108653v1/bat-dg1-5/igt@kms_addfb_ba...@basic-x-tiled-legacy.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_108653v1/bat-dg1-5/igt@kms_addfb_ba...@basic-y-tiled-legacy.html
* igt@kms_busy@basic:
- bat-dg1-5: NOTRUN -> [SKIP][15] ([i915#1845] / [i915#4303])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108653v1/bat-dg1-5/igt@kms_b...@basic.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-bsw-nick:NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108653v1/fi-bsw-nick/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@dp-crc-fast:
- bat-dg1-5: NOTRUN -> [SKIP][17] ([fdo#111827]) +8 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108653v1/bat-dg1-5/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_force_connector_basic@force-load-detect:
- bat-dg1-5: NOTRUN -> [SKIP][18] ([fdo#109285])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108653v1/bat-dg1-5/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_pipe_crc_basic@nonblocking-crc:
- bat-dg1-5: NOTRUN -> [SKIP][19] ([i915#4078]) +14 similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108653v1/bat-dg1-5/igt@kms_pipe
Re: [Intel-gfx] [PATCH v1 1/4] drm/i915: Move dsm assignment to be after adjustment
On 16-09-2022 02:09, Lucas De Marchi wrote: > Reduce possible side effects of assigning the region and bailing out due > to errors. > > Signed-off-by: Lucas De Marchi > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c > b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c > index acc561c0f0aa..42f4769bb4ac 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c > @@ -418,14 +418,14 @@ static int i915_gem_init_stolen(struct > intel_memory_region *mem) > if (resource_size(&mem->region) == 0) > return 0; > > - i915->dsm = mem->region; > - > - if (i915_adjust_stolen(i915, &i915->dsm)) > + if (i915_adjust_stolen(i915, &mem->region)) > return 0; > > GEM_BUG_ON(i915->dsm.start == 0); > GEM_BUG_ON(i915->dsm.end <= i915->dsm.start); > > + i915->dsm = mem->region; assignment should be above the GEM_BUG_ON. but why don't you squash this into 3rd patch thanks, Aravind. > + > stolen_top = i915->dsm.end + 1; > reserved_base = stolen_top; > reserved_size = 0; >
Re: [Intel-gfx] [PATCH v1 2/4] drm/i915: Add missing mask when reading GEN12_DSMBASE
On 16-09-2022 02:09, Lucas De Marchi wrote:
> DSMBASE register is defined so BDSM bitfield contains the bits 63 to 20
> of the base address of stolen. For the supported platforms bits 0-19 are
> zero but that may not be true in future. Add the missing mask.
>
> Signed-off-by: Lucas De Marchi
Acked-by: Aravind Iddamsetty
Thanks,
Aravind.
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> index 42f4769bb4ac..c34065fe2ecc 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> @@ -814,7 +814,7 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private *i915,
> u16 type,
> return ERR_PTR(-ENXIO);
>
> /* Use DSM base address instead for stolen memory */
> - dsm_base = intel_uncore_read64(uncore, GEN12_DSMBASE);
> + dsm_base = intel_uncore_read64(uncore, GEN12_DSMBASE) & GEN12_BDSM_MASK;
> if (IS_DG1(uncore->i915)) {
> lmem_size = pci_resource_len(pdev, GEN12_LMEM_BAR);
> if (WARN_ON(lmem_size < dsm_base))
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 1a9bd829fc7e..0301874c76ba 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7953,6 +7953,7 @@ enum skl_power_gate {
>
> #define GEN12_GSMBASE_MMIO(0x108100)
> #define GEN12_DSMBASE_MMIO(0x1080C0)
> +#define GEN12_BDSM_MASKGENMASK(63, 20)
>
> #define XEHP_CLOCK_GATE_DIS _MMIO(0x101014)
> #define SGSI_SIDECLK_DIS REG_BIT(17)
>
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/display: remove ipc_enabled from struct drm_i915_private
== Series Details == Series: drm/i915/display: remove ipc_enabled from struct drm_i915_private URL : https://patchwork.freedesktop.org/series/108654/ 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 v3 1/2] drm/i915/gem: Flush contexts on driver release
Reviewed-by: Gwan-gyeong Mun
On 9/16/22 12:24 PM, Janusz Krzysztofik wrote:
Due to i915_perf assuming that it can use the i915_gem_context reference
to protect its i915->gem.contexts.list iteration, we need to defer removal
of the context from the list until last reference to the context is put.
However, there is a risk of triggering kernel warning on contexts list not
empty at driver release time if we deleagate that task to a worker for
i915_gem_context_release_work(), unless that work is flushed first.
Unfortunately, it is not flushed on driver release. Fix it.
Instead of additionally calling flush_workqueue(), either directly or via
a new dedicated wrapper around it, replace last call to
i915_gem_drain_freed_objects() with existing i915_gem_drain_workqueue()
that performs both tasks.
Fixes: 75eefd82581f ("drm/i915: Release i915_gem_context from a worker")
Suggested-by: Chris Wilson
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Andi Shyti
Cc: sta...@kernel.org # v5.16+
---
drivers/gpu/drm/i915/i915_gem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c8e14ed9c2a96..172c29a15f118 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1195,7 +1195,8 @@ void i915_gem_driver_release(struct drm_i915_private
*dev_priv)
intel_uc_cleanup_firmwares(&to_gt(dev_priv)->uc);
- i915_gem_drain_freed_objects(dev_priv);
+ /* Flush any outstanding work, including i915_gem_context.release_work.
*/
+ i915_gem_drain_workqueue(dev_priv);
drm_WARN_ON(&dev_priv->drm, !list_empty(&dev_priv->gem.contexts.list));
}
Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/gem: Really move i915_gem_context.link under ref protection
Reviewed-by: Gwan-gyeong Mun
On 9/16/22 12:24 PM, Janusz Krzysztofik wrote:
From: Chris Wilson
i915_perf assumes that it can use the i915_gem_context reference to
protect its i915->gem.contexts.list iteration. However, this requires
that we do not remove the context from the list until after we drop the
final reference and release the struct. If, as currently, we remove the
context from the list during context_close(), the link.next pointer may
be poisoned while we are holding the context reference and cause a GPF:
[ 4070.573157] i915 :00:02.0: [drm:i915_perf_open_ioctl [i915]] filtering
on ctx_id=0x1f ctx_id_mask=0x1f
[ 4070.574881] general protection fault, probably for non-canonical address
0xdead0100: [#1] PREEMPT SMP
[ 4070.574897] CPU: 1 PID: 284392 Comm: amd_performance Tainted: GE
5.17.9 #180
[ 4070.574903] Hardware name: Intel Corporation NUC7i5BNK/NUC7i5BNB, BIOS
BNKBL357.86A.0052.2017.0918.1346 09/18/2017
[ 4070.574907] RIP: 0010:oa_configure_all_contexts.isra.0+0x222/0x350 [i915]
[ 4070.574982] Code: 08 e8 32 6e 10 e1 4d 8b 6d 50 b8 ff ff ff ff 49 83 ed 50 f0 41
0f c1 04 24 83 f8 01 0f 84 e3 00 00 00 85 c0 0f 8e fa 00 00 00 <49> 8b 45 50 48
8d 70 b0 49 8d 45 50 48 39 44 24 10 0f 85 34 fe ff
[ 4070.574990] RSP: 0018:c90002077b78 EFLAGS: 00010202
[ 4070.574995] RAX: 0002 RBX: 0002 RCX:
[ 4070.575000] RDX: 0001 RSI: c90002077b20 RDI: 88810ddc7c68
[ 4070.575004] RBP: 0001 R08: 888103242648 R09: fffc
[ 4070.575008] R10: 82c50bc0 R11: 00025c80 R12: 888101bf1860
[ 4070.575012] R13: dead00b0 R14: c90002077c04 R15: 88810be5cabc
[ 4070.575016] FS: 7f1ed50c0780() GS:5ec8()
knlGS:
[ 4070.575021] CS: 0010 DS: ES: CR0: 80050033
[ 4070.575025] CR2: 7f1ed5590280 CR3: 00010ef6f005 CR4: 003706e0
[ 4070.575029] Call Trace:
[ 4070.575033]
[ 4070.575037] lrc_configure_all_contexts+0x13e/0x150 [i915]
[ 4070.575103] gen8_enable_metric_set+0x4d/0x90 [i915]
[ 4070.575164] i915_perf_open_ioctl+0xbc0/0x1500 [i915]
[ 4070.575224] ? asm_common_interrupt+0x1e/0x40
[ 4070.575232] ? i915_oa_init_reg_state+0x110/0x110 [i915]
[ 4070.575290] drm_ioctl_kernel+0x85/0x110
[ 4070.575296] ? update_load_avg+0x5f/0x5e0
[ 4070.575302] drm_ioctl+0x1d3/0x370
[ 4070.575307] ? i915_oa_init_reg_state+0x110/0x110 [i915]
[ 4070.575382] ? gen8_gt_irq_handler+0x46/0x130 [i915]
[ 4070.575445] __x64_sys_ioctl+0x3c4/0x8d0
[ 4070.575451] ? __do_softirq+0xaa/0x1d2
[ 4070.575456] do_syscall_64+0x35/0x80
[ 4070.575461] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 4070.575467] RIP: 0033:0x7f1ed5c10397
[ 4070.575471] Code: 3c 1c e8 1c ff ff ff 85 c0 79 87 49 c7 c4 ff ff ff ff 5b 5d 4c
89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff
ff 73 01 c3 48 8b 0d a9 da 0d 00 f7 d8 64 89 01 48
[ 4070.575478] RSP: 002b:7ffd65c8d7a8 EFLAGS: 0246 ORIG_RAX:
0010
[ 4070.575484] RAX: ffda RBX: 0006 RCX: 7f1ed5c10397
[ 4070.575488] RDX: 7ffd65c8d7c0 RSI: 40106476 RDI: 0006
[ 4070.575492] RBP: 5620972f9c60 R08: 000a R09: 0005
[ 4070.575496] R10: 000d R11: 0246 R12: 000a
[ 4070.575500] R13: 000d R14: R15: 7ffd65c8d7c0
[ 4070.575505]
[ 4070.575507] Modules linked in: nls_ascii(E) nls_cp437(E) vfat(E) fat(E)
i915(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) crct10dif_pclmul(E)
crc32_pclmul(E) crc32c_intel(E) aesni_intel(E) crypto_simd(E) intel_gtt(E)
cryptd(E) ttm(E) rapl(E) intel_cstate(E) drm_kms_helper(E) cfbfillrect(E)
syscopyarea(E) cfbimgblt(E) intel_uncore(E) sysfillrect(E) mei_me(E)
sysimgblt(E) i2c_i801(E) fb_sys_fops(E) mei(E) intel_pch_thermal(E)
i2c_smbus(E) cfbcopyarea(E) video(E) button(E) efivarfs(E) autofs4(E)
[ 4070.575549] ---[ end trace ]---
v3: fix incorrect syntax of spin_lock() replacing spin_lock_irqsave()
v2: irqsave not required in a worker, neither conversion to irq safe
elsewhere (Tvrtko),
- perf: it's safe to call gen8_configure_context() even if context has
been closed, no need to check,
- drop unrelated cleanup (Andi, Tvrtko)
Reported-by: Mark Janes
Closes: https://gitlab.freedesktop.org/drm/intel/issues/6222
References: a4e7ccdac38e ("drm/i915: Move context management under GEM")
Fixes: f8246cf4d9a9 ("drm/i915/gem: Drop free_work for GEM contexts")
Signed-off-by: Chris Wilson
Reviewed-by: Andi Shyti
Signed-off-by: Andi Shyti
Signed-off-by: Janusz Krzysztofik
Cc: Tvrtko Ursulin
Cc: # v5.12+
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index dabdfe09f5e51..0
[Intel-gfx] [PULL] drm-intel-next
Hi Dave & Daniel - The final feature pull for v6.1. drm-intel-next-2022-09-16-1: drm/i915 feature pull #2 for v6.1: Features and functionality: - More Meteorlake platform enabling (Radhakrishna, Imre, Madhumitha) - Allow seamless M/N changes on eDP panels that support it (Ville) - Switch DSC debugfs from output bpp to input bpc (Swati) Refactoring and cleanups: - Clocking and DPLL refactoring and cleanups to support seamless M/N (Ville) - Plenty of VBT definition and parsing updates and cleanups (Ville) - Extract SKL watermark code to a separate file, and clean up (Ville) - Clean up IPC interfaces and debugfs (Jani) - Continue moving display data under drm_i915_private display sub-struct (Jani) - Display quirk handling refactoring and abstractions (Jani) - Stop using implicit dev_priv in gmbus registers (Jani) - BUG_ON() removals and conversions to drm_WARN_ON() and BUILD_BUG_ON() (Jani) - Use drm_dp_phy_name() for logging (Jani) - Use REG_BIT() macros for CDCLK registers (Stan) - Move display and media IP versions to runtime info (Radhakrishna) Fixes: - Fix DP MST suspend to avoid use-after-free (Andrzej) - Fix HPD suspend to avoid use-after-free for fbdev (Andrzej) - Fix various PSR issues regarding selective update and damage clips (Jouni) - Fix runtime pm wakerefs for driver remove and release (Mitul Golani) - Fix conditions for filtering fixed modes for panels (Ville) - Fix TV encoder clock computation (Ville) - Fix dvo mode_valid hook return type (Nathan Huckleberry) Merges: - Backmerge drm-next to sync the DP MST atomic changes (Jani) BR, Jani. The following changes since commit 89b03aeaef16f8ab48c10c399f97c836bdbae838: drm/vkms: fix 32bit compilation error by replacing macros (2022-09-11 22:28:56 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2022-09-16-1 for you to fetch changes up to 21f0b7dabf9c358e75a539b5554c0375bf1abe0a: drm/i915: Fix return type of mode_valid function hook (2022-09-15 10:28:55 +0300) drm/i915 feature pull #2 for v6.1: Features and functionality: - More Meteorlake platform enabling (Radhakrishna, Imre, Madhumitha) - Allow seamless M/N changes on eDP panels that support it (Ville) - Switch DSC debugfs from output bpp to input bpc (Swati) Refactoring and cleanups: - Clocking and DPLL refactoring and cleanups to support seamless M/N (Ville) - Plenty of VBT definition and parsing updates and cleanups (Ville) - Extract SKL watermark code to a separate file, and clean up (Ville) - Clean up IPC interfaces and debugfs (Jani) - Continue moving display data under drm_i915_private display sub-struct (Jani) - Display quirk handling refactoring and abstractions (Jani) - Stop using implicit dev_priv in gmbus registers (Jani) - BUG_ON() removals and conversions to drm_WARN_ON() and BUILD_BUG_ON() (Jani) - Use drm_dp_phy_name() for logging (Jani) - Use REG_BIT() macros for CDCLK registers (Stan) - Move display and media IP versions to runtime info (Radhakrishna) Fixes: - Fix DP MST suspend to avoid use-after-free (Andrzej) - Fix HPD suspend to avoid use-after-free for fbdev (Andrzej) - Fix various PSR issues regarding selective update and damage clips (Jouni) - Fix runtime pm wakerefs for driver remove and release (Mitul Golani) - Fix conditions for filtering fixed modes for panels (Ville) - Fix TV encoder clock computation (Ville) - Fix dvo mode_valid hook return type (Nathan Huckleberry) Merges: - Backmerge drm-next to sync the DP MST atomic changes (Jani) Andrzej Hajda (3): drm/i915/hpd: suspend MST at the end of intel_modeset_driver_remove drm/i915/fbdev: suspend HPD before fbdev unregistration drm/i915/fbdev: do not create fbdev if HPD is suspended Ankit Nautiyal (1): drm/i915/vdsc: Set VDSC PIC_HEIGHT before using for DP DSC Imre Deak (2): drm/i915/mtl: Add display power wells drm/i915/mtl: Add DP AUX support on TypeC ports Jani Nikula (46): drm/i915: move and group hdcp under display.hdcp drm/i915: move and group max_bw and bw_obj under display.bw drm/i915: move opregion to display.opregion drm/i915: move and group cdclk under display.cdclk drm/i915: move backlight to display.backlight drm/i915: move mipi_mmio_base to display.dsi drm/i915: move vbt to display.vbt drm/i915: move fbc to display.fbc drm/i915: move and group power related members under display.power drm/i915: move and group fdi members under display.fdi drm/i915: move fb_tracking under display sub-struct drm/i915: move dbuf under display sub-struct drm/i915: move and group modeset_wq and flip_wq under display.wq drm/i915/quirks: abstract checking for display quirks drm/i915/quirks: abstract quirks further by making quirk ids an enum drm/i915: move quirks under display su
Re: [Intel-gfx] [PATCH v1 3/4] drm/i915: Split i915_gem_init_stolen()
On 16-09-2022 02:09, Lucas De Marchi wrote:
> Add some helpers: adjust_stolen(), request_smem_stolen_() and
> init_reserved_stolen() that are now called by i915_gem_init_stolen() to
> initialize each part of the Data Stolen Memory region. Main goal is to
> split the reserved part, also known as WOPCM, as its calculation changes
> often per platform.
>
> This also fixes a bug in graphics version < 5 (in theory, not tested,
> due to no machine available): it would bail out on stolen creation due
> to "Stolen reserved area outside stolen memory". Other than that, no
> change in behavior.
>
> Signed-off-by: Lucas De Marchi
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> index c34065fe2ecc..0e57a6d81534 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> @@ -77,22 +77,26 @@ void i915_gem_stolen_remove_node(struct drm_i915_private
> *i915,
> mutex_unlock(&i915->mm.stolen_lock);
> }
>
> -static int i915_adjust_stolen(struct drm_i915_private *i915,
> - struct resource *dsm)
> +static bool valid_stolen_size(struct resource *dsm)
> +{
> + return dsm->start != 0 && dsm->end > dsm->start;
> +}
> +
> +static int adjust_stolen(struct drm_i915_private *i915,
> + struct resource *dsm)
> {
> struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
> struct intel_uncore *uncore = ggtt->vm.gt->uncore;
> - struct resource *r;
>
> - if (dsm->start == 0 || dsm->end <= dsm->start)
> + if (!valid_stolen_size(dsm))
> return -EINVAL;
>
> /*
> + * Make sure we don't clobber the GTT if it's within stolen memory
> + *
>* TODO: We have yet too encounter the case where the GTT wasn't at the
>* end of stolen. With that assumption we could simplify this.
>*/
> -
> - /* Make sure we don't clobber the GTT if it's within stolen memory */
> if (GRAPHICS_VER(i915) <= 4 &&
> !IS_G33(i915) && !IS_PINEVIEW(i915) && !IS_G4X(i915)) {
> struct resource stolen[2] = {*dsm, *dsm};
> @@ -131,10 +135,20 @@ static int i915_adjust_stolen(struct drm_i915_private
> *i915,
> }
> }
>
> + if (!valid_stolen_size(dsm))
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static int request_smem_stolen(struct drm_i915_private *i915,
> +struct resource *dsm)
> +{
> + struct resource *r;
> +
> /*
> - * With stolen lmem, we don't need to check if the address range
> - * overlaps with the non-stolen system memory range, since lmem is local
> - * to the gpu.
> + * With stolen lmem, we don't need to request if the address range
replace /if/for
> + * since lmem is local to the gpu.
>*/
> if (HAS_LMEM(i915))
> return 0;
> @@ -392,39 +406,22 @@ static void icl_get_stolen_reserved(struct
> drm_i915_private *i915,
> }
> }
>
> -static int i915_gem_init_stolen(struct intel_memory_region *mem)
> +/*
> + * Initialize i915->dsm_reserved to contain the reserved space within the
> Data
> + * Stolen Memory. This is a range on the top of DSM that is reserved, not to
> + * be used by driver, so must be excluded from the region passed to the
> + * allocator later. In the spec this is also called as WOPCM.
> + *
> + * Our expectation is that the reserved space is at the top of the stolen
> + * region, as it has been the case for every platform, and *never* at the
> + * bottom, so the calculation here can be simplified.
> + */
> +static int init_reserved_stolen(struct drm_i915_private *i915)
> {
> - struct drm_i915_private *i915 = mem->i915;
> struct intel_uncore *uncore = &i915->uncore;
> resource_size_t reserved_base, stolen_top;
> - resource_size_t reserved_total, reserved_size;
> -
> - mutex_init(&i915->mm.stolen_lock);
> -
> - if (intel_vgpu_active(i915)) {
> - drm_notice(&i915->drm,
> -"%s, disabling use of stolen memory\n",
> -"iGVT-g active");
> - return 0;
> - }
> -
> - if (i915_vtd_active(i915) && GRAPHICS_VER(i915) < 8) {
> - drm_notice(&i915->drm,
> -"%s, disabling use of stolen memory\n",
> -"DMAR active");
> - return 0;
> - }
> -
> - if (resource_size(&mem->region) == 0)
> - return 0;
> -
> - if (i915_adjust_stolen(i915, &mem->region))
> - return 0;
> -
> - GEM_BUG_ON(i915->dsm.start == 0);
> - GEM_BUG_ON(i915->dsm.end <= i915->dsm.start);
> -
> - i915->dsm = mem->region;
> + resource_size_t reserved_size;
> + int ret = 0;
>
> stolen_top = i915->dsm.end + 1;
> reserved_base = stolen_top;
> @@ -453,19 +450,17 @@ static int i915_gem_init_stolen(struct
> intel_memory_region *mem)
> } else if (GRAP
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: remove ipc_enabled from struct drm_i915_private
== Series Details ==
Series: drm/i915/display: remove ipc_enabled from struct drm_i915_private
URL : https://patchwork.freedesktop.org/series/108654/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12145 -> Patchwork_108654v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108654v1/index.html
Participating hosts (44 -> 41)
--
Additional (2): fi-apl-guc bat-dg1-5
Missing(5): fi-rkl-11600 fi-hsw-4200u fi-ctg-p8600 bat-dg2-11
fi-bdw-samus
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_108654v1:
### 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:
- {fi-tgl-mst}: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/fi-tgl-mst/igt@i915_pm_...@module-reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108654v1/fi-tgl-mst/igt@i915_pm_...@module-reload.html
Known issues
Here are the changes found in Patchwork_108654v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@fbdev@nullptr:
- bat-dg1-5: NOTRUN -> [SKIP][3] ([i915#2582]) +4 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108654v1/bat-dg1-5/igt@fb...@nullptr.html
* igt@gem_mmap@basic:
- bat-dg1-5: NOTRUN -> [SKIP][4] ([i915#4083])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108654v1/bat-dg1-5/igt@gem_m...@basic.html
* igt@gem_tiled_blits@basic:
- bat-dg1-5: NOTRUN -> [SKIP][5] ([i915#4077]) +2 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108654v1/bat-dg1-5/igt@gem_tiled_bl...@basic.html
* igt@gem_tiled_pread_basic:
- bat-dg1-5: NOTRUN -> [SKIP][6] ([i915#4079]) +1 similar issue
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108654v1/bat-dg1-5/igt@gem_tiled_pread_basic.html
* igt@i915_pm_backlight@basic-brightness:
- bat-dg1-5: NOTRUN -> [SKIP][7] ([i915#1155])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108654v1/bat-dg1-5/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_pm_rps@basic-api:
- bat-dg1-5: NOTRUN -> [SKIP][8] ([i915#6621])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108654v1/bat-dg1-5/igt@i915_pm_...@basic-api.html
* igt@i915_selftest@live@requests:
- fi-blb-e6850: [PASS][9] -> [DMESG-FAIL][10] ([i915#4528])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/fi-blb-e6850/igt@i915_selftest@l...@requests.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108654v1/fi-blb-e6850/igt@i915_selftest@l...@requests.html
* igt@i915_suspend@basic-s3-without-i915:
- fi-bdw-5557u: [PASS][11] -> [INCOMPLETE][12] ([i915#146] /
[i915#6598] / [i915#6712])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/fi-bdw-5557u/igt@i915_susp...@basic-s3-without-i915.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108654v1/fi-bdw-5557u/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_addfb_basic@basic-x-tiled-legacy:
- bat-dg1-5: NOTRUN -> [SKIP][13] ([i915#4212]) +7 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108654v1/bat-dg1-5/igt@kms_addfb_ba...@basic-x-tiled-legacy.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_108654v1/bat-dg1-5/igt@kms_addfb_ba...@basic-y-tiled-legacy.html
* igt@kms_busy@basic:
- bat-dg1-5: NOTRUN -> [SKIP][15] ([i915#1845] / [i915#4303])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108654v1/bat-dg1-5/igt@kms_b...@basic.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-bsw-nick:NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108654v1/fi-bsw-nick/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@dp-crc-fast:
- bat-dg1-5: NOTRUN -> [SKIP][17] ([fdo#111827]) +8 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108654v1/bat-dg1-5/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka: [PASS][18] -> [FAIL][19] ([i915#6298])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108654v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-tran
Re: [Intel-gfx] [topic/core-for-CI] Revert "iommu/dma: Fix race condition during iova_domain initialization"
On 14.09.2022 17:54, Robin Murphy wrote:
On 2022-09-14 16:01, Lucas De Marchi wrote:
On Wed, Sep 14, 2022 at 02:40:45PM +0200, Karolina Drobnik wrote:
This reverts commit ac9a5d522bb80be50ea84965699e1c8257d745ce.
This change introduces a regression on Alder Lake that
completely blocks testing. To enable CI and avoid possible
circular locking warning, revert the patch.
We are already on rc5. Are iommu authors involved aware of this
issue? We could do this in our "for CI only" branch, but it's
equally important that this is fixed for 6.0
Cc'ing them.
The lockdep report doesn't make much sense to me - the deadlock cycle
it's reporting doesn't even involve the mutex added by that commit,
and otherwise the lock ordering between the IOMMU bus notifier(s) and
cpu_hotplug_lock has existed for ages. Has lockdep somehow got
multiple different and unrelated bus notifiers mixed up, maybe?
FWIW nobody else has reported anything, and that mutex addresses a
real-world concurrency issue, so I'm not convinced a revert is
appropriate without at least a much clearer justification.
I'll share more background on this regression. We've noticed that no
tests were run for Alder Lake platforms. This may happens when, for
example, there is a kernel taint or lockdep warning.
Links:
https://intel-gfx-ci.01.org/tree/drm-tip/bat-adlm-1.html
https://intel-gfx-ci.01.org/tree/drm-tip/bat-adlp-6.html
The CI logs (which can be found for example here[1], boot0 file)
revealed a lockdep warning. One of the recent changes in the area was
commit ac9a5d522bb8 ("iommu/dma: Fix race condition during iova_domain
initialization"), and I sent a revert patch to test it on CI[2]. This
proved to be effective, as the tests started running on Alder Lake
platform:
https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_108474v1/index.html?hosts=adlp
To be clear, that revert is just a way of unblocking CI testing, the
problem requires a specific fix.
Lucas, would it be possible to merge this revert to the topic branch to
unblock Alder Lake until this issue is fixed? I'm afraid that some
regressions could slip through the cracks if we don't do it soon enough.
Thanks,
Karolina
[1] -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/bat-adlm-1/igt@run...@aborted.html
[2] - https://patchwork.freedesktop.org/series/108474/
Robin.
thanks Lucas De Marchi
kernel log:
== WARNING:
possible circular locking dependency detected
6.0.0-rc5-CI_DRM_12132-g6c93e979e542+ #1 Not tainted
-- cpuhp/0/15
is trying to acquire lock: 8881013df278
(&(&priv->bus_notifier)->rwsem){}-{3:3}, at:
blocking_notifier_call_chain+0x20/0x50 but task is already
holding lock: 826490c0 (cpuhp_state-up){+.+.}-{0:0}, at:
cpuhp_thread_fun+0x48/0x1f0 which lock already depends on the
new loc the existing dependency chain (in reverse order) is: ->
#3 (cpuhp_state-up){+.+.}-{0:0}: lock_acquire+0xd3/0x310
cpuhp_thread_fun+0xa6/0x1f0 smpboot_thread_fn+0x1b5/0x260
kthread+0xed/0x120 ret_from_fork+0x1f/0x30 -> #2
(cpu_hotplug_lock){}-{0:0}: lock_acquire+0xd3/0x310
__cpuhp_state_add_instance+0x43/0x1c0
iova_domain_init_rcaches+0x199/0x1c0
iommu_setup_dma_ops+0x130/0x440 bus_iommu_probe+0x26a/0x2d0
bus_set_iommu+0x82/0xd0 intel_iommu_init+0xe33/0x1039
pci_iommu_init+0x9/0x31 do_one_initcall+0x53/0x2f0
kernel_init_freeable+0x18f/0x1e1 kernel_init+0x11/0x120
ret_from_fork+0x1f/0x30 -> #1
(&domain->iova_cookie->mutex){+.+.}-{3:3}:
lock_acquire+0xd3/0x310 __mutex_lock+0x97/0xf10
iommu_setup_dma_ops+0xd7/0x440 iommu_probe_device+0xa4/0x180
iommu_bus_notifier+0x2d/0x40 notifier_call_chain+0x31/0x90
blocking_notifier_call_chain+0x3a/0x50 device_add+0x3c1/0x900
pci_device_add+0x255/0x580 pci_scan_single_device+0xa6/0xd0
pci_scan_slot+0x7a/0x1b0 pci_scan_child_bus_extend+0x35/0x2a0
vmd_probe+0x5cd/0x970 pci_device_probe+0x95/0x110
really_probe+0xd6/0x350 __driver_probe_device+0x73/0x170
driver_probe_device+0x1a/0x90 __driver_attach+0xbc/0x190
bus_for_each_dev+0x72/0xc0 bus_add_driver+0x1bb/0x210
driver_register+0x66/0xc0 do_one_initcall+0x53/0x2f0
kernel_init_freeable+0x18f/0x1e1 kernel_init+0x11/0x120
ret_from_fork+0x1f/0x30 -> #0
(&(&priv->bus_notifier)->rwsem){}-{3:3}:
validate_chain+0xb3f/0x2000 __lock_acquire+0x5a4/0xb70
lock_acquire+0xd3/0x310 down_read+0x39/0x140
blocking_notifier_call_chain+0x20/0x50 device_add+0x3c1/0x900
platform_device_add+0x108/0x240 coretemp_cpu_online+0xe1/0x15e
[coretemp] cpuhp_invoke_callback+0x181/0x8a0
cpuhp_thread_fun+0x188/0x1f0 smpboot_thread_fn+0x1b5/0x260
kthread+0xed/0x120 ret_from_fork+0x1f/0x30 other info that might
help us debug thi Chain exists of &(&priv->bus_notifier)->rwsem
--> cpu_hotplug_lock --> cpuhp_state- Possible unsafe locking
scenari CPU0 CPU1
lock(cpuhp_state-up); lock(cpu_hotplug_lock);
lock(cpuhp_state-up); lock(&(&priv->bus_noti
Re: [Intel-gfx] [PATCH v3 02/37] drm/i915: display: fix kernel-doc markup warnings
Looks good to me. Reviewed-by: Gwan-gyeong Mun On 9/9/22 10:34 AM, Mauro Carvalho Chehab wrote: There are a couple of issues at i915 display kernel-doc markups: drivers/gpu/drm/i915/display/intel_display_debugfs.c:2238: warning: Function parameter or member 'intel_connector' not described in 'intel_connector_debugfs_add' drivers/gpu/drm/i915/display/intel_display_debugfs.c:2238: warning: Excess function parameter 'connector' description in 'intel_connector_debugfs_add' drivers/gpu/drm/i915/display/intel_display_power.c:700: warning: expecting prototype for intel_display_power_put_async(). Prototype was for __intel_display_power_put_async() instead drivers/gpu/drm/i915/display/intel_tc.c:807: warning: Function parameter or member 'work' not described in 'intel_tc_port_disconnect_phy_work' drivers/gpu/drm/i915/display/intel_tc.c:807: warning: Excess function parameter 'dig_port' description in 'intel_tc_port_disconnect_phy_work' Those are due to wrong parameter of function name. Address them. Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ drivers/gpu/drm/i915/display/intel_display_debugfs.c | 2 +- drivers/gpu/drm/i915/display/intel_display_power.c | 2 +- drivers/gpu/drm/i915/display/intel_tc.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c b/drivers/gpu/drm/i915/display/intel_display_debugfs.c index 5dc364e9db49..e8433aa50905 100644 --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c @@ -2232,7 +2232,7 @@ DEFINE_SHOW_ATTRIBUTE(i915_current_bpc); /** * intel_connector_debugfs_add - add i915 specific connector debugfs files - * @connector: pointer to a registered drm_connector + * @intel_connector: pointer to a registered drm_connector * * Cleanup will be done by drm_connector_unregister() through a call to * drm_debugfs_connector_remove(). diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c b/drivers/gpu/drm/i915/display/intel_display_power.c index 1af1705d730d..b080d65d4461 100644 --- a/drivers/gpu/drm/i915/display/intel_display_power.c +++ b/drivers/gpu/drm/i915/display/intel_display_power.c @@ -686,7 +686,7 @@ intel_display_power_put_async_work(struct work_struct *work) } /** - * intel_display_power_put_async - release a power domain reference asynchronously + * __intel_display_power_put_async - release a power domain reference asynchronously * @i915: i915 device instance * @domain: power domain to reference * @wakeref: wakeref acquired for the reference that is being released diff --git a/drivers/gpu/drm/i915/display/intel_tc.c b/drivers/gpu/drm/i915/display/intel_tc.c index e5af955b5600..10cda362537e 100644 --- a/drivers/gpu/drm/i915/display/intel_tc.c +++ b/drivers/gpu/drm/i915/display/intel_tc.c @@ -797,7 +797,7 @@ void intel_tc_port_lock(struct intel_digital_port *dig_port) /** * intel_tc_port_disconnect_phy_work: disconnect TypeC PHY from display port - * @dig_port: digital port + * @work: workqueue struct * * Disconnect the given digital port from its TypeC PHY (handing back the * control of the PHY to the TypeC subsystem). This will happen in a delayed
[Intel-gfx] [CI 2/2] drm/i915/hotplug: refactor hotplug init slightly
Rename intel_hpd_init_work() to the more generic intel_hpd_init_early(),
and move the hotplug storm initialization there. This lets us move the
HPD_STORM_DEFAULT_THRESHOLD macro to intel_hotplug.c too.
Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_hotplug.c | 22 +++-
drivers/gpu/drm/i915/display/intel_hotplug.h | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 3 ---
drivers/gpu/drm/i915/i915_irq.c | 11 +-
4 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c
b/drivers/gpu/drm/i915/display/intel_hotplug.c
index 4faae25d76c0..352a1b53b63e 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
@@ -90,6 +90,9 @@ enum hpd_pin intel_hpd_pin_default(struct drm_i915_private
*dev_priv,
return HPD_PORT_A + port - PORT_A;
}
+/* Threshold == 5 for long IRQs, 50 for short */
+#define HPD_STORM_DEFAULT_THRESHOLD50
+
#define HPD_STORM_DETECT_PERIOD1000
#define HPD_STORM_REENABLE_DELAY (2 * 60 * 1000)
#define HPD_RETRY_DELAY1000
@@ -711,14 +714,23 @@ void intel_hpd_poll_disable(struct drm_i915_private
*dev_priv)
schedule_work(&dev_priv->display.hotplug.poll_init_work);
}
-void intel_hpd_init_work(struct drm_i915_private *dev_priv)
+void intel_hpd_init_early(struct drm_i915_private *i915)
{
- INIT_DELAYED_WORK(&dev_priv->display.hotplug.hotplug_work,
+ INIT_DELAYED_WORK(&i915->display.hotplug.hotplug_work,
i915_hotplug_work_func);
- INIT_WORK(&dev_priv->display.hotplug.dig_port_work,
i915_digport_work_func);
- INIT_WORK(&dev_priv->display.hotplug.poll_init_work,
i915_hpd_poll_init_work);
- INIT_DELAYED_WORK(&dev_priv->display.hotplug.reenable_work,
+ INIT_WORK(&i915->display.hotplug.dig_port_work, i915_digport_work_func);
+ INIT_WORK(&i915->display.hotplug.poll_init_work,
i915_hpd_poll_init_work);
+ INIT_DELAYED_WORK(&i915->display.hotplug.reenable_work,
intel_hpd_irq_storm_reenable_work);
+
+ i915->display.hotplug.hpd_storm_threshold = HPD_STORM_DEFAULT_THRESHOLD;
+ /* If we have MST support, we want to avoid doing short HPD IRQ storm
+* detection, as short HPD storms will occur as a natural part of
+* sideband messaging with MST.
+* On older platforms however, IRQ storms can occur with both long and
+* short pulses, as seen on some G4x systems.
+*/
+ i915->display.hotplug.hpd_short_storm_enabled = !HAS_DP_MST(i915);
}
void intel_hpd_cancel_work(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.h
b/drivers/gpu/drm/i915/display/intel_hotplug.h
index aa84e381d6c3..424ae5dbf5a0 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.h
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.h
@@ -22,7 +22,7 @@ void intel_hpd_irq_handler(struct drm_i915_private *dev_priv,
u32 pin_mask, u32 long_mask);
void intel_hpd_trigger_irq(struct intel_digital_port *dig_port);
void intel_hpd_init(struct drm_i915_private *dev_priv);
-void intel_hpd_init_work(struct drm_i915_private *dev_priv);
+void intel_hpd_init_early(struct drm_i915_private *i915);
void intel_hpd_cancel_work(struct drm_i915_private *dev_priv);
enum hpd_pin intel_hpd_pin_default(struct drm_i915_private *dev_priv,
enum port port);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9f9372931fd2..731760b7c97d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -75,9 +75,6 @@ struct intel_limit;
struct intel_overlay_error_state;
struct vlv_s0ix_state;
-/* Threshold == 5 for long IRQs, 50 for short */
-#define HPD_STORM_DEFAULT_THRESHOLD 50
-
#define I915_GEM_GPU_DOMAINS \
(I915_GEM_DOMAIN_RENDER | \
I915_GEM_DOMAIN_SAMPLER | \
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 86a42d9e8041..de06f293e173 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -4399,7 +4399,7 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
intel_hpd_init_pins(dev_priv);
- intel_hpd_init_work(dev_priv);
+ intel_hpd_init_early(dev_priv);
dev->vblank_disable_immediate = true;
@@ -4413,15 +4413,6 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
dev_priv->display_irqs_enabled = false;
- dev_priv->display.hotplug.hpd_storm_threshold =
HPD_STORM_DEFAULT_THRESHOLD;
- /* If we have MST support, we want to avoid doing short HPD IRQ storm
-* detection, as short HPD storms will occur as a natural part of
-* sideband messaging with MST.
-* On
[Intel-gfx] [CI 1/2] drm/i915/hotplug: move hotplug storm debugfs to intel_hotplug.c
The debugfs should be where the implementation details are.
v2: Rebase
Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
---
.../drm/i915/display/intel_display_debugfs.c | 160 +
drivers/gpu/drm/i915/display/intel_hotplug.c | 166 ++
drivers/gpu/drm/i915/display/intel_hotplug.h | 1 +
3 files changed, 169 insertions(+), 158 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 7c7253a2541c..c5f47df0f362 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -22,6 +22,7 @@
#include "intel_fbdev.h"
#include "intel_hdcp.h"
#include "intel_hdmi.h"
+#include "intel_hotplug.h"
#include "intel_panel.h"
#include "intel_pm.h"
#include "intel_psr.h"
@@ -1566,162 +1567,6 @@ static const struct file_operations
i915_cur_wm_latency_fops = {
.write = cur_wm_latency_write
};
-static int i915_hpd_storm_ctl_show(struct seq_file *m, void *data)
-{
- struct drm_i915_private *dev_priv = m->private;
- struct intel_hotplug *hotplug = &dev_priv->display.hotplug;
-
- /* Synchronize with everything first in case there's been an HPD
-* storm, but we haven't finished handling it in the kernel yet
-*/
- intel_synchronize_irq(dev_priv);
- flush_work(&dev_priv->display.hotplug.dig_port_work);
- flush_delayed_work(&dev_priv->display.hotplug.hotplug_work);
-
- seq_printf(m, "Threshold: %d\n", hotplug->hpd_storm_threshold);
- seq_printf(m, "Detected: %s\n",
- str_yes_no(delayed_work_pending(&hotplug->reenable_work)));
-
- return 0;
-}
-
-static ssize_t i915_hpd_storm_ctl_write(struct file *file,
- const char __user *ubuf, size_t len,
- loff_t *offp)
-{
- struct seq_file *m = file->private_data;
- struct drm_i915_private *dev_priv = m->private;
- struct intel_hotplug *hotplug = &dev_priv->display.hotplug;
- unsigned int new_threshold;
- int i;
- char *newline;
- char tmp[16];
-
- if (len >= sizeof(tmp))
- return -EINVAL;
-
- if (copy_from_user(tmp, ubuf, len))
- return -EFAULT;
-
- tmp[len] = '\0';
-
- /* Strip newline, if any */
- newline = strchr(tmp, '\n');
- if (newline)
- *newline = '\0';
-
- if (strcmp(tmp, "reset") == 0)
- new_threshold = HPD_STORM_DEFAULT_THRESHOLD;
- else if (kstrtouint(tmp, 10, &new_threshold) != 0)
- return -EINVAL;
-
- if (new_threshold > 0)
- drm_dbg_kms(&dev_priv->drm,
- "Setting HPD storm detection threshold to %d\n",
- new_threshold);
- else
- drm_dbg_kms(&dev_priv->drm, "Disabling HPD storm detection\n");
-
- spin_lock_irq(&dev_priv->irq_lock);
- hotplug->hpd_storm_threshold = new_threshold;
- /* Reset the HPD storm stats so we don't accidentally trigger a storm */
- for_each_hpd_pin(i)
- hotplug->stats[i].count = 0;
- spin_unlock_irq(&dev_priv->irq_lock);
-
- /* Re-enable hpd immediately if we were in an irq storm */
- flush_delayed_work(&dev_priv->display.hotplug.reenable_work);
-
- return len;
-}
-
-static int i915_hpd_storm_ctl_open(struct inode *inode, struct file *file)
-{
- return single_open(file, i915_hpd_storm_ctl_show, inode->i_private);
-}
-
-static const struct file_operations i915_hpd_storm_ctl_fops = {
- .owner = THIS_MODULE,
- .open = i915_hpd_storm_ctl_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release = single_release,
- .write = i915_hpd_storm_ctl_write
-};
-
-static int i915_hpd_short_storm_ctl_show(struct seq_file *m, void *data)
-{
- struct drm_i915_private *dev_priv = m->private;
-
- seq_printf(m, "Enabled: %s\n",
-
str_yes_no(dev_priv->display.hotplug.hpd_short_storm_enabled));
-
- return 0;
-}
-
-static int
-i915_hpd_short_storm_ctl_open(struct inode *inode, struct file *file)
-{
- return single_open(file, i915_hpd_short_storm_ctl_show,
- inode->i_private);
-}
-
-static ssize_t i915_hpd_short_storm_ctl_write(struct file *file,
- const char __user *ubuf,
- size_t len, loff_t *offp)
-{
- struct seq_file *m = file->private_data;
- struct drm_i915_private *dev_priv = m->private;
- struct intel_hotplug *hotplug = &dev_priv->display.hotplug;
- char *newline;
- char tmp[16];
- int i;
- bool new_state;
-
- if (len >= sizeof(tmp))
- return -EINVAL;
-
- if (copy_from_user(tmp, ubuf, len))
- return -EFAULT;
-
- tmp[l
Re: [Intel-gfx] [PATCH] drm/i915/psr: Do not re-activate PSR if there was a PSR aux error
On Fri, 2022-09-16 at 14:08 +0300, Jouni Högander wrote:
> If there is a PSR aux error sink is marked as not reliable
> and PSR is permantently disabled.
>
> Current code is activating PSR again even there was PSR aux error.
> Fix this by skipping intel_psr_activate when PSR aux error is
> detected.
>
> Cc: Mika Kahola
> Cc: José Roberto de Souza
>
> Reported-by: Charlton Lin
> Signed-off-by: Jouni Högander
> ---
> drivers/gpu/drm/i915/display/intel_psr.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 9def8d9fade6..42390203ad19 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -2153,8 +2153,10 @@ static void intel_psr_work(struct work_struct *work)
> if (!intel_dp->psr.enabled)
> goto unlock;
>
> - if (READ_ONCE(intel_dp->psr.irq_aux_error))
> + if (READ_ONCE(intel_dp->psr.irq_aux_error)) {
> intel_psr_handle_irq(intel_dp);
> + goto unlock;
> + }
Already handled.
__psr_wait_for_idle_locked
if (!intel_dp->psr.enabled)
return false;
>
> /*
>* We have to make sure PSR is ready for re-enable
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: fix device info for devices without display
== Series Details == Series: drm/i915: fix device info for devices without display URL : https://patchwork.freedesktop.org/series/108642/ State : success == Summary == CI Bug Log - changes from CI_DRM_12145_full -> Patchwork_108642v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (11 -> 10) -- Missing(1): shard-rkl Known issues Here are the changes found in Patchwork_108642v1_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_fair@basic-flow@rcs0: - shard-tglb: [PASS][1] -> [FAIL][2] ([i915#2842]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/shard-tglb2/igt@gem_exec_fair@basic-f...@rcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108642v1/shard-tglb5/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-none@vcs0: - shard-glk: [PASS][3] -> [FAIL][4] ([i915#2842]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/shard-glk5/igt@gem_exec_fair@basic-n...@vcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108642v1/shard-glk6/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_pwrite@basic-exhaustion: - shard-iclb: NOTRUN -> [WARN][5] ([i915#2658]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108642v1/shard-iclb7/igt@gem_pwr...@basic-exhaustion.html * igt@gem_render_copy@y-tiled-ccs-to-yf-tiled-mc-ccs: - shard-iclb: NOTRUN -> [SKIP][6] ([i915#768]) +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108642v1/shard-iclb7/igt@gem_render_c...@y-tiled-ccs-to-yf-tiled-mc-ccs.html * igt@i915_suspend@sysfs-reader: - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([i915#180]) +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/shard-apl2/igt@i915_susp...@sysfs-reader.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108642v1/shard-apl2/igt@i915_susp...@sysfs-reader.html * igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-180-hflip: - shard-iclb: NOTRUN -> [SKIP][9] ([i915#5286]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108642v1/shard-iclb7/igt@kms_big...@4-tiled-max-hw-stride-64bpp-rotate-180-hflip.html * igt@kms_big_fb@x-tiled-16bpp-rotate-270: - shard-iclb: NOTRUN -> [SKIP][10] ([fdo#110725] / [fdo#111614]) +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108642v1/shard-iclb7/igt@kms_big...@x-tiled-16bpp-rotate-270.html * igt@kms_big_fb@yf-tiled-64bpp-rotate-180: - shard-iclb: NOTRUN -> [SKIP][11] ([fdo#110723]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108642v1/shard-iclb7/igt@kms_big...@yf-tiled-64bpp-rotate-180.html * igt@kms_ccs@pipe-c-crc-primary-rotation-180-y_tiled_gen12_mc_ccs: - shard-iclb: NOTRUN -> [SKIP][12] ([fdo#109278] / [i915#3886]) +1 similar issue [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108642v1/shard-iclb7/igt@kms_ccs@pipe-c-crc-primary-rotation-180-y_tiled_gen12_mc_ccs.html * igt@kms_ccs@pipe-c-random-ccs-data-y_tiled_gen12_rc_ccs: - shard-apl: NOTRUN -> [SKIP][13] ([fdo#109271]) +10 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108642v1/shard-apl6/igt@kms_ccs@pipe-c-random-ccs-data-y_tiled_gen12_rc_ccs.html * igt@kms_ccs@pipe-d-bad-aux-stride-y_tiled_gen12_mc_ccs: - shard-iclb: NOTRUN -> [SKIP][14] ([fdo#109278]) +6 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108642v1/shard-iclb7/igt@kms_ccs@pipe-d-bad-aux-stride-y_tiled_gen12_mc_ccs.html * igt@kms_chamelium@hdmi-audio-edid: - shard-apl: NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108642v1/shard-apl6/igt@kms_chamel...@hdmi-audio-edid.html * igt@kms_chamelium@vga-hpd-for-each-pipe: - shard-iclb: NOTRUN -> [SKIP][16] ([fdo#109284] / [fdo#111827]) +1 similar issue [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108642v1/shard-iclb7/igt@kms_chamel...@vga-hpd-for-each-pipe.html * igt@kms_content_protection@uevent: - shard-iclb: NOTRUN -> [SKIP][17] ([fdo#109300] / [fdo#111066]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108642v1/shard-iclb7/igt@kms_content_protect...@uevent.html * igt@kms_flip@2x-absolute-wf_vblank: - shard-iclb: NOTRUN -> [SKIP][18] ([fdo#109274]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108642v1/shard-iclb7/igt@kms_flip@2x-absolute-wf_vblank.html * igt@kms_flip_scaled_crc@flip-64bpp-linear-to-32bpp-linear-downscaling@pipe-a-default-mode: - shard-iclb: NOTRUN -> [SKIP][19] ([i915#3555]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm
Re: [Intel-gfx] [PATCH] drm/i915/psr: Do not re-activate PSR if there was a PSR aux error
On Fri, 2022-09-16 at 13:22 +, Souza, Jose wrote:
> On Fri, 2022-09-16 at 14:08 +0300, Jouni Högander wrote:
> > If there is a PSR aux error sink is marked as not reliable
> > and PSR is permantently disabled.
> >
> > Current code is activating PSR again even there was PSR aux error.
> > Fix this by skipping intel_psr_activate when PSR aux error is
> > detected.
> >
> > Cc: Mika Kahola
> > Cc: José Roberto de Souza
> >
> > Reported-by: Charlton Lin
> > Signed-off-by: Jouni Högander
> > ---
> > drivers/gpu/drm/i915/display/intel_psr.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index 9def8d9fade6..42390203ad19 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -2153,8 +2153,10 @@ static void intel_psr_work(struct
> > work_struct *work)
> > if (!intel_dp->psr.enabled)
> > goto unlock;
> >
> > - if (READ_ONCE(intel_dp->psr.irq_aux_error))
> > + if (READ_ONCE(intel_dp->psr.irq_aux_error)) {
> > intel_psr_handle_irq(intel_dp);
> > + goto unlock;
> > + }
>
> Already handled.
> __psr_wait_for_idle_locked
> if (!intel_dp->psr.enabled)
> return false;
Ah, yes that is correct. Thank you for pointing this out. So this patch
is not needed.
>
> >
> > /*
> > * We have to make sure PSR is ready for re-enable
>
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/2] drm/i915/hotplug: move hotplug storm debugfs to intel_hotplug.c
== Series Details == Series: series starting with [CI,1/2] drm/i915/hotplug: move hotplug storm debugfs to intel_hotplug.c URL : https://patchwork.freedesktop.org/series/108656/ 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 v3 01/37] drm/i915: fix kernel-doc trivial warnings on i915/*.[ch] files
On 9/9/22 10:34 AM, Mauro Carvalho Chehab wrote: There are several trivial warnings there, due to trivial things: - lack of function name at the kerneldoc markup; - renamed functions; - wrong parameter syntax. Fix such warnings: drivers/gpu/drm/i915/i915_active.h:66: warning: Function parameter or member 'active' not described in '__i915_active_fence_init' drivers/gpu/drm/i915/i915_active.h:66: warning: Function parameter or member 'fence' not described in '__i915_active_fence_init' drivers/gpu/drm/i915/i915_active.h:66: warning: Function parameter or member 'fn' not described in '__i915_active_fence_init' drivers/gpu/drm/i915/i915_active.h:89: warning: Function parameter or member 'active' not described in 'i915_active_fence_set' drivers/gpu/drm/i915/i915_active.h:89: warning: Function parameter or member 'rq' not described in 'i915_active_fence_set' drivers/gpu/drm/i915/i915_active.h:102: warning: Function parameter or member 'active' not described in 'i915_active_fence_get' drivers/gpu/drm/i915/i915_active.h:122: warning: Function parameter or member 'active' not described in 'i915_active_fence_isset' drivers/gpu/drm/i915/i915_gem.c:443: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Reads data from the object referenced by handle. drivers/gpu/drm/i915/i915_gem.c:532: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * This is the fast pwrite path, where we copy the data directly from the drivers/gpu/drm/i915/i915_gem.c:717: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Writes data to the object referenced by handle. drivers/gpu/drm/i915/i915_gem.c:802: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Called when user space has done writes to this buffer drivers/gpu/drm/i915/i915_pmu.h:22: warning: cannot understand function prototype: 'enum i915_pmu_tracked_events ' drivers/gpu/drm/i915/i915_pmu.h:33: warning: cannot understand function prototype: 'enum ' drivers/gpu/drm/i915/i915_pmu.h:42: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * How many different events we track in the global PMU mask. drivers/gpu/drm/i915/i915_request.h:177: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Request queue structure. drivers/gpu/drm/i915/i915_request.h:473: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Returns true if seq1 is later than seq2. drivers/gpu/drm/i915/i915_scatterlist.c:63: warning: Function parameter or member 'size' not described in 'i915_refct_sgt_init' drivers/gpu/drm/i915/i915_scatterlist.h:153: warning: Incorrect use of kernel-doc format: * release() - Free the memory of the struct i915_refct_sgt drivers/gpu/drm/i915/i915_scatterlist.h:157: warning: Function parameter or member 'release' not described in 'i915_refct_sgt_ops' drivers/gpu/drm/i915/i915_scatterlist.h:180: warning: Function parameter or member 'rsgt' not described in 'i915_refct_sgt_put' drivers/gpu/drm/i915/i915_scatterlist.h:191: warning: Function parameter or member 'rsgt' not described in 'i915_refct_sgt_get' drivers/gpu/drm/i915/i915_scatterlist.h:207: warning: Function parameter or member 'rsgt' not described in '__i915_refct_sgt_init' drivers/gpu/drm/i915/i915_utils.h:291: warning: Function parameter or member 'OP' not described in '__wait_for' drivers/gpu/drm/i915/i915_utils.h:291: warning: Function parameter or member 'COND' not described in '__wait_for' drivers/gpu/drm/i915/i915_utils.h:291: warning: Function parameter or member 'US' not described in '__wait_for' drivers/gpu/drm/i915/i915_utils.h:291: warning: Function parameter or member 'Wmin' not described in '__wait_for' drivers/gpu/drm/i915/i915_utils.h:291: warning: Function parameter or member 'Wmax' not described in '__wait_for' drivers/gpu/drm/i915/i915_vma_resource.h:88: warning: Incorrect use of kernel-doc format: * struct i915_vma_bindinfo - Information needed for async bind drivers/gpu/drm/i915/i915_vma_resource.h:123: warning: Function parameter or member 'bi' not described in 'i915_vma_resource' Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https:
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915/hotplug: move hotplug storm debugfs to intel_hotplug.c
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/hotplug: move hotplug storm
debugfs to intel_hotplug.c
URL : https://patchwork.freedesktop.org/series/108656/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12145 -> Patchwork_108656v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108656v1/index.html
Participating hosts (44 -> 41)
--
Additional (2): fi-apl-guc bat-dg1-5
Missing(5): fi-rkl-11600 fi-hsw-4200u fi-ctg-p8600 bat-dg2-11
fi-bdw-samus
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_108656v1:
### 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:
- {fi-tgl-mst}: [DMESG-WARN][1] ([i915#1982] / [i915#5122]) ->
[DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/fi-tgl-mst/igt@gem_exec_suspend@basic...@smem.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108656v1/fi-tgl-mst/igt@gem_exec_suspend@basic...@smem.html
Known issues
Here are the changes found in Patchwork_108656v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@fbdev@nullptr:
- bat-dg1-5: NOTRUN -> [SKIP][3] ([i915#2582]) +4 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108656v1/bat-dg1-5/igt@fb...@nullptr.html
* igt@gem_mmap@basic:
- bat-dg1-5: NOTRUN -> [SKIP][4] ([i915#4083])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108656v1/bat-dg1-5/igt@gem_m...@basic.html
* igt@gem_tiled_blits@basic:
- bat-dg1-5: NOTRUN -> [SKIP][5] ([i915#4077]) +2 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108656v1/bat-dg1-5/igt@gem_tiled_bl...@basic.html
* igt@gem_tiled_pread_basic:
- bat-dg1-5: NOTRUN -> [SKIP][6] ([i915#4079]) +1 similar issue
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108656v1/bat-dg1-5/igt@gem_tiled_pread_basic.html
* igt@i915_pm_backlight@basic-brightness:
- bat-dg1-5: NOTRUN -> [SKIP][7] ([i915#1155])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108656v1/bat-dg1-5/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_pm_rps@basic-api:
- bat-dg1-5: NOTRUN -> [SKIP][8] ([i915#6621])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108656v1/bat-dg1-5/igt@i915_pm_...@basic-api.html
* igt@i915_selftest@live@execlists:
- fi-bdw-gvtdvm: [PASS][9] -> [INCOMPLETE][10] ([i915#2940])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/fi-bdw-gvtdvm/igt@i915_selftest@l...@execlists.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108656v1/fi-bdw-gvtdvm/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@requests:
- fi-pnv-d510:[PASS][11] -> [DMESG-FAIL][12] ([i915#4528])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/fi-pnv-d510/igt@i915_selftest@l...@requests.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108656v1/fi-pnv-d510/igt@i915_selftest@l...@requests.html
- fi-blb-e6850: [PASS][13] -> [DMESG-FAIL][14] ([i915#4528])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/fi-blb-e6850/igt@i915_selftest@l...@requests.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108656v1/fi-blb-e6850/igt@i915_selftest@l...@requests.html
* igt@kms_addfb_basic@basic-x-tiled-legacy:
- bat-dg1-5: NOTRUN -> [SKIP][15] ([i915#4212]) +7 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108656v1/bat-dg1-5/igt@kms_addfb_ba...@basic-x-tiled-legacy.html
* igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-dg1-5: NOTRUN -> [SKIP][16] ([i915#4215])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108656v1/bat-dg1-5/igt@kms_addfb_ba...@basic-y-tiled-legacy.html
* igt@kms_busy@basic:
- bat-dg1-5: NOTRUN -> [SKIP][17] ([i915#1845] / [i915#4303])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108656v1/bat-dg1-5/igt@kms_b...@basic.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-bsw-nick:NOTRUN -> [SKIP][18] ([fdo#109271] / [fdo#111827])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108656v1/fi-bsw-nick/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@dp-crc-fast:
- bat-dg1-5: NOTRUN -> [SKIP][19] ([fdo#111827]) +8 similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108656v1/bat-dg1-5/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_force_connector_basic@force-load-detect:
- bat-dg1-5: NOTRUN -> [SKIP][20] ([
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/pps: Add get_pps_idx() hook as part of pps_get_register() cleanup
== Series Details == Series: series starting with [1/2] drm/i915/pps: Add get_pps_idx() hook as part of pps_get_register() cleanup URL : https://patchwork.freedesktop.org/series/108643/ State : success == Summary == CI Bug Log - changes from CI_DRM_12145_full -> Patchwork_108643v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (11 -> 11) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_108643v1_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_exec@basic-nohangcheck: - shard-tglb: [PASS][1] -> [FAIL][2] ([i915#6268]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/shard-tglb3/igt@gem_ctx_e...@basic-nohangcheck.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108643v1/shard-tglb2/igt@gem_ctx_e...@basic-nohangcheck.html * igt@gem_exec_endless@dispatch@vecs0: - shard-tglb: [PASS][3] -> [INCOMPLETE][4] ([i915#3778]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/shard-tglb3/igt@gem_exec_endless@dispa...@vecs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108643v1/shard-tglb2/igt@gem_exec_endless@dispa...@vecs0.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-tglb: [PASS][5] -> [FAIL][6] ([i915#2842]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/shard-tglb2/igt@gem_exec_fair@basic-f...@rcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108643v1/shard-tglb6/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-none@vcs0: - shard-glk: [PASS][7] -> [FAIL][8] ([i915#2842]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/shard-glk5/igt@gem_exec_fair@basic-n...@vcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108643v1/shard-glk8/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_lmem_swapping@parallel-random-engines: - shard-apl: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#4613]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108643v1/shard-apl3/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_pwrite@basic-exhaustion: - shard-iclb: NOTRUN -> [WARN][10] ([i915#2658]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108643v1/shard-iclb6/igt@gem_pwr...@basic-exhaustion.html * igt@gem_render_copy@y-tiled-ccs-to-yf-tiled-mc-ccs: - shard-iclb: NOTRUN -> [SKIP][11] ([i915#768]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108643v1/shard-iclb6/igt@gem_render_c...@y-tiled-ccs-to-yf-tiled-mc-ccs.html * igt@gen9_exec_parse@allowed-single: - shard-apl: [PASS][12] -> [DMESG-WARN][13] ([i915#5566] / [i915#716]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/shard-apl2/igt@gen9_exec_pa...@allowed-single.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108643v1/shard-apl6/igt@gen9_exec_pa...@allowed-single.html * igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-180-hflip: - shard-iclb: NOTRUN -> [SKIP][14] ([i915#5286]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108643v1/shard-iclb6/igt@kms_big...@4-tiled-max-hw-stride-64bpp-rotate-180-hflip.html * igt@kms_big_fb@x-tiled-16bpp-rotate-270: - shard-iclb: NOTRUN -> [SKIP][15] ([fdo#110725] / [fdo#111614]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108643v1/shard-iclb6/igt@kms_big...@x-tiled-16bpp-rotate-270.html * igt@kms_big_fb@yf-tiled-64bpp-rotate-180: - shard-iclb: NOTRUN -> [SKIP][16] ([fdo#110723]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108643v1/shard-iclb6/igt@kms_big...@yf-tiled-64bpp-rotate-180.html * igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc: - shard-apl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#3886]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108643v1/shard-apl3/igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc.html * igt@kms_ccs@pipe-c-crc-primary-rotation-180-y_tiled_gen12_mc_ccs: - shard-iclb: NOTRUN -> [SKIP][18] ([fdo#109278] / [i915#3886]) +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108643v1/shard-iclb6/igt@kms_ccs@pipe-c-crc-primary-rotation-180-y_tiled_gen12_mc_ccs.html * igt@kms_ccs@pipe-d-bad-aux-stride-y_tiled_gen12_mc_ccs: - shard-iclb: NOTRUN -> [SKIP][19] ([fdo#109278]) +6 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108643v1/shard-iclb6/igt@kms_ccs@pipe-d-bad-aux-stride-y_tiled_gen12_mc_ccs.html * igt@kms_chamelium@hdmi-audio-edid: - shard-apl: NOTRUN -> [SKIP][20] ([fdo#109271] / [fdo#111827]) +1 similar issue [20]: https://intel-gf
Re: [Intel-gfx] [PATCH] drm/i915: Split GAM and MSLICE steering
On Fri, Sep 16, 2022 at 10:02:32AM +0100, Tvrtko Ursulin wrote:
>
> On 16/09/2022 02:43, Matt Roper wrote:
> > Although the bspec lists several MMIO ranges as "MSLICE," it turns out
> > that a subset of these are of a "GAM" subclass that has unique rules and
> > doesn't followed regular mslice steering behavior.
> >
> > * Xe_HP SDV: GAM ranges must always be steered to 0,0. These
> > registers share the regular steering control register (0xFDC) with
> > other steering types
> >
> > * DG2: GAM ranges must always be steered to 1,0. GAM registers have a
> > dedicated steering control register (0xFE0) so we can set the value
> > once at startup and rely on implicit steering. Technically the
> > hardware default should already be set to 1,0 properly, but it never
> > hurts to ensure that in the driver.
>
> Do you have any data on whether the "technically should" holds in practice?
> What would be the consequences of some platform/machine surprising us here?
The bspec indicates the hardware default value is already the necessary
1,0 value; I'm mostly paranoid about some kind of boot firmware wiping
it to 0,0 by accident. I don't have any evidence that has ever actually
happened, but explicitly re-programming it to 1,0 in the patch here is a
defensive measure just to be safe.
If we didn't have this patch _and_ some firmware screwed up the GAM
steering target, then presumably we might read back garbage or 0 from
GAM registers in places where we should have received a real value.
Matt
>
> Regards,
>
> Tvrtko
>
> >
> > Bspec: 66534
> > Signed-off-by: Matt Roper
> > ---
> > drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 24 +++--
> > drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
> > drivers/gpu/drm/i915/gt/intel_gt_types.h| 1 +
> > drivers/gpu/drm/i915/gt/intel_workarounds.c | 10 +
> > 4 files changed, 34 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > index e79405a45312..a2047a68ea7a 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > @@ -40,6 +40,7 @@ static const char * const intel_steering_types[] = {
> > "L3BANK",
> > "MSLICE",
> > "LNCF",
> > + "GAM",
> > "INSTANCE 0",
> > };
> > @@ -48,14 +49,23 @@ static const struct intel_mmio_range
> > icl_l3bank_steering_table[] = {
> > {},
> > };
> > +/*
> > + * Although the bspec lists more "MSLICE" ranges than shown here, some of
> > those
> > + * are of a "GAM" subclass that has special rules. Thus we use a separate
> > + * GAM table farther down for those.
> > + */
> > static const struct intel_mmio_range xehpsdv_mslice_steering_table[] = {
> > - { 0x004000, 0x004AFF },
> > - { 0x00C800, 0x00CFFF },
> > { 0x00DD00, 0x00DDFF },
> > { 0x00E900, 0x00 }, /* 0xEA00 - OxEFFF is unused */
> > {},
> > };
> > +static const struct intel_mmio_range xehpsdv_gam_steering_table[] = {
> > + { 0x004000, 0x004AFF },
> > + { 0x00C800, 0x00CFFF },
> > + {},
> > +};
> > +
> > static const struct intel_mmio_range xehpsdv_lncf_steering_table[] = {
> > { 0x00B000, 0x00B0FF },
> > { 0x00D800, 0x00D8FF },
> > @@ -114,9 +124,15 @@ void intel_gt_mcr_init(struct intel_gt *gt)
> > } else if (IS_DG2(i915)) {
> > gt->steering_table[MSLICE] = xehpsdv_mslice_steering_table;
> > gt->steering_table[LNCF] = dg2_lncf_steering_table;
> > + /*
> > +* No need to hook up the GAM table since it has a dedicated
> > +* steering control register on DG2 and can use implicit
> > +* steering.
> > +*/
> > } else if (IS_XEHPSDV(i915)) {
> > gt->steering_table[MSLICE] = xehpsdv_mslice_steering_table;
> > gt->steering_table[LNCF] = xehpsdv_lncf_steering_table;
> > + gt->steering_table[GAM] = xehpsdv_gam_steering_table;
> > } else if (GRAPHICS_VER(i915) >= 11 &&
> >GRAPHICS_VER_FULL(i915) < IP_VER(12, 50)) {
> > gt->steering_table[L3BANK] = icl_l3bank_steering_table;
> > @@ -351,6 +367,10 @@ static void get_nonterminated_steering(struct intel_gt
> > *gt,
> > *group = __ffs(gt->info.mslice_mask) << 1;
> > *instance = 0; /* unused */
> > break;
> > + case GAM:
> > + *group = IS_DG2(gt->i915) ? 1 : 0;
> > + *instance = 0;
> > + break;
> > case INSTANCE0:
> > /*
> > * There are a lot of MCR types for which instance (0, 0)
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > index 2275ee47da95..2343b26e0e21 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > @@ -42,6 +42,7 @@
> > #define MCFG_MCR_SELECTOR _MMIO(0xfd0)
> > #define SF_MCR_SEL
[Intel-gfx] [PATCH 0/7] drm/i915: Add HWMON support
This series adds the HWMON support for DGFX Test-with: 20220914140721.3500129-1-riana.ta...@intel.com v2: - Reorganized series. Created first patch as infrastructure patch followed by feature patches. (Ashutosh) - Fixed review comments (Jani) - Fixed review comments (Ashutosh) v3: - Fixed review comments from Guenter - Exposed energy inferface as standard hwmon interface (Ashutosh) - For power interface added entries for critical power and maintained standard interface for all the entries except power1_max_interval - Extended support for XEHPSDV (Ashutosh) v4: - Fixed review comment from Guenter - Cleaned up unused code v5: - Fixed review comments (Jani) v6: - Fixed review comments (Ashutosh) - Updated date and kernel version in documentation Ashutosh Dixit (2): drm/i915/hwmon: Expose card reactive critical power drm/i915/hwmon: Expose power1_max_interval Dale B Stimson (4): drm/i915/hwmon: Add HWMON infrastructure drm/i915/hwmon: Power PL1 limit and TDP setting drm/i915/hwmon: Show device level energy usage drm/i915/hwmon: Extend power/energy for XEHPSDV Riana Tauro (1): drm/i915/hwmon: Add HWMON current voltage support .../ABI/testing/sysfs-driver-intel-i915-hwmon | 75 ++ drivers/gpu/drm/i915/Makefile | 3 + drivers/gpu/drm/i915/gt/intel_gt_regs.h | 8 + drivers/gpu/drm/i915/i915_driver.c| 5 + drivers/gpu/drm/i915/i915_drv.h | 2 + drivers/gpu/drm/i915/i915_hwmon.c | 761 ++ drivers/gpu/drm/i915/i915_hwmon.h | 21 + drivers/gpu/drm/i915/i915_reg.h | 14 + drivers/gpu/drm/i915/intel_mchbar_regs.h | 12 + 9 files changed, 901 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon create mode 100644 drivers/gpu/drm/i915/i915_hwmon.c create mode 100644 drivers/gpu/drm/i915/i915_hwmon.h -- 2.25.1
[Intel-gfx] [PATCH 2/7] drm/i915/hwmon: Add HWMON current voltage support
From: Riana Tauro
Use i915 HWMON subsystem to display current input voltage.
v2:
- Updated date and kernel version in feature description
- Fixed review comments (Ashutosh)
v3: Use macro HWMON_CHANNEL_INFO to define hwmon channel (Guenter)
v4:
- Fixed review comments (Ashutosh)
- Use hwm_ prefix for static functions (Ashutosh)
v5:
- Added unit of voltage as millivolts (Ashutosh)
- Updated date, kernel version in documentation
Cc: Guenter Roeck
Cc: Anshuman Gupta
Signed-off-by: Riana Tauro
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
Reviewed-by: Ashutosh Dixit
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 7 +++
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 ++
drivers/gpu/drm/i915/i915_hwmon.c | 53 +++
3 files changed, 63 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
new file mode 100644
index ..e2974f928e58
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -0,0 +1,7 @@
+What: /sys/devices/.../hwmon/hwmon/in0_input
+Date: September 2022
+KernelVersion: 6
+Contact: dri-de...@lists.freedesktop.org
+Description: RO. Current Voltage in millivolt.
+
+ Only supported for particular Intel i915 graphics platforms.
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 2275ee47da95..65336514554d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1510,6 +1510,9 @@
#define VLV_RENDER_C0_COUNT_MMIO(0x138118)
#define VLV_MEDIA_C0_COUNT _MMIO(0x13811c)
+#define GEN12_RPSTAT1 _MMIO(0x1381b4)
+#define GEN12_VOLTAGE_MASK REG_GENMASK(10, 0)
+
#define GEN11_GT_INTR_DW(x)_MMIO(0x190018 + ((x) * 4))
#define GEN11_CSME (31)
#define GEN11_GUNIT (28)
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index 103dd543a214..45745afa5c5b 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -11,8 +11,16 @@
#include "i915_hwmon.h"
#include "i915_reg.h"
#include "intel_mchbar_regs.h"
+#include "gt/intel_gt_regs.h"
+
+/*
+ * SF_* - scale factors for particular quantities according to hwmon spec.
+ * - voltage - millivolts
+ */
+#define SF_VOLTAGE 1000
struct hwm_reg {
+ i915_reg_t gt_perf_status;
};
struct hwm_drvdata {
@@ -29,14 +37,49 @@ struct i915_hwmon {
};
static const struct hwmon_channel_info *hwm_info[] = {
+ HWMON_CHANNEL_INFO(in, HWMON_I_INPUT),
NULL
};
+static umode_t
+hwm_in_is_visible(const struct hwm_drvdata *ddat, u32 attr)
+{
+ switch (attr) {
+ case hwmon_in_input:
+ return i915_mmio_reg_valid(ddat->hwmon->rg.gt_perf_status) ?
0444 : 0;
+ default:
+ return 0;
+ }
+}
+
+static int
+hwm_in_read(struct hwm_drvdata *ddat, u32 attr, long *val)
+{
+ struct i915_hwmon *hwmon = ddat->hwmon;
+ intel_wakeref_t wakeref;
+ u32 reg_value;
+
+ switch (attr) {
+ case hwmon_in_input:
+ with_intel_runtime_pm(ddat->uncore->rpm, wakeref)
+ reg_value = intel_uncore_read(ddat->uncore,
hwmon->rg.gt_perf_status);
+ /* HW register value in units of 2.5 millivolt */
+ *val = DIV_ROUND_CLOSEST(REG_FIELD_GET(GEN12_VOLTAGE_MASK,
reg_value) * 25, 10);
+ return 0;
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
static umode_t
hwm_is_visible(const void *drvdata, enum hwmon_sensor_types type,
u32 attr, int channel)
{
+ struct hwm_drvdata *ddat = (struct hwm_drvdata *)drvdata;
+
switch (type) {
+ case hwmon_in:
+ return hwm_in_is_visible(ddat, attr);
default:
return 0;
}
@@ -46,7 +89,11 @@ static int
hwm_read(struct device *dev, enum hwmon_sensor_types type, u32 attr,
int channel, long *val)
{
+ struct hwm_drvdata *ddat = dev_get_drvdata(dev);
+
switch (type) {
+ case hwmon_in:
+ return hwm_in_read(ddat, attr, val);
default:
return -EOPNOTSUPP;
}
@@ -76,6 +123,12 @@ static const struct hwmon_chip_info hwm_chip_info = {
static void
hwm_get_preregistration_info(struct drm_i915_private *i915)
{
+ struct i915_hwmon *hwmon = i915->hwmon;
+
+ if (IS_DG1(i915) || IS_DG2(i915))
+ hwmon->rg.gt_perf_status = GEN12_RPSTAT1;
+ else
+ hwmon->rg.gt_perf_status = INVALID_MMIO_REG;
}
void i915_hwmon_register(struct drm_i915_private *i915)
--
2.25.1
[Intel-gfx] [PATCH 3/7] drm/i915/hwmon: Power PL1 limit and TDP setting
From: Dale B Stimson
Use i915 HWMON to display/modify dGfx power PL1 limit and TDP setting.
v2:
- Fix review comments (Ashutosh)
- Do not restore power1_max upon module unload/load sequence
because on production systems modules are always loaded
and not unloaded/reloaded (Ashutosh)
- Fix review comments (Jani)
- Remove endianness conversion (Ashutosh)
v3: Add power1_rated_max (Ashutosh)
v4:
- Use macro HWMON_CHANNEL_INFO to define power channel (Guenter)
- Update the date and kernel version in Documentation (Badal)
v5: Use hwm_ prefix for static functions (Ashutosh)
v6:
- Fix review comments (Ashutosh)
- Update date, kernel version in documentation
Cc: Guenter Roeck
Signed-off-by: Dale B Stimson
Signed-off-by: Ashutosh Dixit
Signed-off-by: Riana Tauro
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 20 +++
drivers/gpu/drm/i915/i915_hwmon.c | 158 +-
drivers/gpu/drm/i915/i915_reg.h | 5 +
drivers/gpu/drm/i915/intel_mchbar_regs.h | 6 +
4 files changed, 187 insertions(+), 2 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index e2974f928e58..bc061238e35c 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -5,3 +5,23 @@ Contact: dri-de...@lists.freedesktop.org
Description: RO. Current Voltage in millivolt.
Only supported for particular Intel i915 graphics platforms.
+
+What: /sys/devices/.../hwmon/hwmon/power1_max
+Date: September 2022
+KernelVersion: 6
+Contact: dri-de...@lists.freedesktop.org
+Description: RW. Card reactive sustained (PL1/Tau) power limit in
microwatts.
+
+ The power controller will throttle the operating frequency
+ if the power averaged over a window (typically seconds)
+ exceeds this limit.
+
+ Only supported for particular Intel i915 graphics platforms.
+
+What: /sys/devices/.../hwmon/hwmon/power1_rated_max
+Date: September 2022
+KernelVersion: 6
+Contact: dri-de...@lists.freedesktop.org
+Description: RO. Card default power limit (default TDP setting).
+
+ Only supported for particular Intel i915 graphics platforms.
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index 45745afa5c5b..5183cf51a49b 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -16,11 +16,16 @@
/*
* SF_* - scale factors for particular quantities according to hwmon spec.
* - voltage - millivolts
+ * - power - microwatts
*/
#define SF_VOLTAGE 1000
+#define SF_POWER 100
struct hwm_reg {
i915_reg_t gt_perf_status;
+ i915_reg_t pkg_power_sku_unit;
+ i915_reg_t pkg_power_sku;
+ i915_reg_t pkg_rapl_limit;
};
struct hwm_drvdata {
@@ -34,10 +39,68 @@ struct i915_hwmon {
struct hwm_drvdata ddat;
struct mutex hwmon_lock;/* counter overflow logic and
rmw */
struct hwm_reg rg;
+ int scl_shift_power;
};
+static void
+hwm_locked_with_pm_intel_uncore_rmw(struct hwm_drvdata *ddat,
+ i915_reg_t reg, u32 clear, u32 set)
+{
+ struct i915_hwmon *hwmon = ddat->hwmon;
+ struct intel_uncore *uncore = ddat->uncore;
+ intel_wakeref_t wakeref;
+
+ mutex_lock(&hwmon->hwmon_lock);
+
+ with_intel_runtime_pm(uncore->rpm, wakeref)
+ intel_uncore_rmw(uncore, reg, clear, set);
+
+ mutex_unlock(&hwmon->hwmon_lock);
+}
+
+/*
+ * This function's return type of u64 allows for the case where the scaling
+ * of the field taken from the 32-bit register value might cause a result to
+ * exceed 32 bits.
+ */
+static u64
+hwm_field_read_and_scale(struct hwm_drvdata *ddat, i915_reg_t rgadr,
+u32 field_msk, int nshift, u32 scale_factor)
+{
+ struct intel_uncore *uncore = ddat->uncore;
+ intel_wakeref_t wakeref;
+ u32 reg_value;
+
+ with_intel_runtime_pm(uncore->rpm, wakeref)
+ reg_value = intel_uncore_read(uncore, rgadr);
+
+ reg_value = REG_FIELD_GET(field_msk, reg_value);
+
+ return mul_u64_u32_shr(reg_value, scale_factor, nshift);
+}
+
+static void
+hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
+ u32 field_msk, int nshift,
+ unsigned int scale_factor, long lval)
+{
+ u32 nval;
+ u32 bits_to_clear;
+ u32 bits_to_set;
+
+ /* Computation in 64-bits to avoid overflow. Round to nearest. */
+ nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
+
+ bits_to_clear = field_msk;
+ bits_to_set = FIELD_PREP(field_msk, nval);
+
+ hwm_locked_with_pm_i
[Intel-gfx] [PATCH 1/7] drm/i915/hwmon: Add HWMON infrastructure
From: Dale B Stimson
The i915 HWMON module will be used to expose voltage, power and energy
values for dGfx. Here we set up i915 hwmon infrastructure including i915
hwmon registration, basic data structures and functions.
v2:
- Create HWMON infra patch (Ashutosh)
- Fixed review comments (Jani)
- Remove "select HWMON" from i915/Kconfig (Jani)
v3: Use hwm_ prefix for static functions (Ashutosh)
v4: s/#ifdef CONFIG_HWMON/#if IS_REACHABLE(CONFIG_HWMON)/ since the former
doesn't work if hwmon is compiled as a module (Guenter)
v5: Fixed review comments (Jani)
Cc: Guenter Roeck
Signed-off-by: Dale B Stimson
Signed-off-by: Ashutosh Dixit
Signed-off-by: Riana Tauro
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
Reviewed-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/Makefile | 3 +
drivers/gpu/drm/i915/i915_driver.c | 5 ++
drivers/gpu/drm/i915/i915_drv.h| 2 +
drivers/gpu/drm/i915/i915_hwmon.c | 136 +
drivers/gpu/drm/i915/i915_hwmon.h | 20 +
5 files changed, 166 insertions(+)
create mode 100644 drivers/gpu/drm/i915/i915_hwmon.c
create mode 100644 drivers/gpu/drm/i915/i915_hwmon.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index a26edcdadc21..66a6023e61a6 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -209,6 +209,9 @@ i915-y += gt/uc/intel_uc.o \
# graphics system controller (GSC) support
i915-y += gt/intel_gsc.o
+# graphics hardware monitoring (HWMON) support
+i915-$(CONFIG_HWMON) += i915_hwmon.o
+
# modesetting core code
i915-y += \
display/hsw_ips.o \
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index c459eb362c47..75655adb7bd3 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -81,6 +81,7 @@
#include "i915_drm_client.h"
#include "i915_drv.h"
#include "i915_getparam.h"
+#include "i915_hwmon.h"
#include "i915_ioc32.h"
#include "i915_ioctl.h"
#include "i915_irq.h"
@@ -763,6 +764,8 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
for_each_gt(gt, dev_priv, i)
intel_gt_driver_register(gt);
+ i915_hwmon_register(dev_priv);
+
intel_display_driver_register(dev_priv);
intel_power_domains_enable(dev_priv);
@@ -795,6 +798,8 @@ static void i915_driver_unregister(struct drm_i915_private
*dev_priv)
for_each_gt(gt, dev_priv, i)
intel_gt_driver_unregister(gt);
+ i915_hwmon_unregister(dev_priv);
+
i915_perf_unregister(dev_priv);
i915_pmu_unregister(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9f9372931fd2..01a2caf42635 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -353,6 +353,8 @@ struct drm_i915_private {
struct i915_perf perf;
+ struct i915_hwmon *hwmon;
+
/* Abstract the submission mechanism (legacy ringbuffer or execlists)
away */
struct intel_gt gt0;
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
new file mode 100644
index ..103dd543a214
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -0,0 +1,136 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include
+#include
+#include
+
+#include "i915_drv.h"
+#include "i915_hwmon.h"
+#include "i915_reg.h"
+#include "intel_mchbar_regs.h"
+
+struct hwm_reg {
+};
+
+struct hwm_drvdata {
+ struct i915_hwmon *hwmon;
+ struct intel_uncore *uncore;
+ struct device *hwmon_dev;
+ char name[12];
+};
+
+struct i915_hwmon {
+ struct hwm_drvdata ddat;
+ struct mutex hwmon_lock;/* counter overflow logic and
rmw */
+ struct hwm_reg rg;
+};
+
+static const struct hwmon_channel_info *hwm_info[] = {
+ NULL
+};
+
+static umode_t
+hwm_is_visible(const void *drvdata, enum hwmon_sensor_types type,
+ u32 attr, int channel)
+{
+ switch (type) {
+ default:
+ return 0;
+ }
+}
+
+static int
+hwm_read(struct device *dev, enum hwmon_sensor_types type, u32 attr,
+int channel, long *val)
+{
+ switch (type) {
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
+static int
+hwm_write(struct device *dev, enum hwmon_sensor_types type, u32 attr,
+ int channel, long val)
+{
+ switch (type) {
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
+static const struct hwmon_ops hwm_ops = {
+ .is_visible = hwm_is_visible,
+ .read = hwm_read,
+ .write = hwm_write,
+};
+
+static const struct hwmon_chip_info hwm_chip_info = {
+ .ops = &hwm_ops,
+ .info = hwm_info,
+};
+
+static void
+hwm_get_preregistration_info(struct drm_i915_private *i915)
+{
+}
+
+void i915_hwmon_register(struct drm_i915_private *i915)
+{
+ struct device *dev = i915->d
[Intel-gfx] [PATCH 4/7] drm/i915/hwmon: Show device level energy usage
From: Dale B Stimson
Use i915 HWMON to display device level energy input.
v2:
- Updated the date and kernel version in feature description
v3:
- Cleaned up hwm_energy function and removed unused function
i915_hwmon_energy_status_get (Ashutosh)
- Updated date, kernel version in documentation
Signed-off-by: Dale B Stimson
Signed-off-by: Ashutosh Dixit
Signed-off-by: Riana Tauro
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
Reviewed-by: Ashutosh Dixit
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 8 ++
drivers/gpu/drm/i915/i915_hwmon.c | 107 +-
drivers/gpu/drm/i915/i915_hwmon.h | 1 +
drivers/gpu/drm/i915/intel_mchbar_regs.h | 2 +
4 files changed, 116 insertions(+), 2 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index bc061238e35c..94101f818a70 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -25,3 +25,11 @@ Contact: dri-de...@lists.freedesktop.org
Description: RO. Card default power limit (default TDP setting).
Only supported for particular Intel i915 graphics platforms.
+
+What: /sys/devices/.../hwmon/hwmon/energy1_input
+Date: September 2022
+KernelVersion: 6
+Contact: dri-de...@lists.freedesktop.org
+Description: RO. Energy input of device in microjoules.
+
+ Only supported for particular Intel i915 graphics platforms.
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index 5183cf51a49b..a42cfad78bef 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -17,21 +17,30 @@
* SF_* - scale factors for particular quantities according to hwmon spec.
* - voltage - millivolts
* - power - microwatts
+ * - energy - microjoules
*/
#define SF_VOLTAGE 1000
#define SF_POWER 100
+#define SF_ENERGY 100
struct hwm_reg {
i915_reg_t gt_perf_status;
i915_reg_t pkg_power_sku_unit;
i915_reg_t pkg_power_sku;
i915_reg_t pkg_rapl_limit;
+ i915_reg_t energy_status_all;
+};
+
+struct hwm_energy_info {
+ u32 reg_val_prev;
+ long accum_energy; /* Accumulated energy for
energy1_input */
};
struct hwm_drvdata {
struct i915_hwmon *hwmon;
struct intel_uncore *uncore;
struct device *hwmon_dev;
+ struct hwm_energy_info ei; /* Energy info for
energy1_input */
char name[12];
};
@@ -40,6 +49,7 @@ struct i915_hwmon {
struct mutex hwmon_lock;/* counter overflow logic and
rmw */
struct hwm_reg rg;
int scl_shift_power;
+ int scl_shift_energy;
};
static void
@@ -98,9 +108,60 @@ hwm_field_scale_and_write(struct hwm_drvdata *ddat,
i915_reg_t rgadr,
bits_to_clear, bits_to_set);
}
+/*
+ * hwm_energy - Obtain energy value
+ *
+ * The underlying energy hardware register is 32-bits and is subject to
+ * overflow. How long before overflow? For example, with an example
+ * scaling bit shift of 14 bits (see register *PACKAGE_POWER_SKU_UNIT) and
+ * a power draw of 1000 watts, the 32-bit counter will overflow in
+ * approximately 4.36 minutes.
+ *
+ * Examples:
+ *1 watt: (2^32 >> 14) /1 W / (60 * 60 * 24) secs/day -> 3 days
+ * 1000 watts: (2^32 >> 14) / 1000 W / 60 secs/min -> 4.36 minutes
+ *
+ * The function significantly increases overflow duration (from 4.36
+ * minutes) by accumulating the energy register into a 'long' as allowed by
+ * the hwmon API. Using x86_64 128 bit arithmetic (see mul_u64_u32_shr()),
+ * a 'long' of 63 bits, SF_ENERGY of 1e6 (~20 bits) and
+ * hwmon->scl_shift_energy of 14 bits we have 57 (63 - 20 + 14) bits before
+ * energy1_input overflows. This at 1000 W is an overflow duration of 278
years.
+ */
+static int
+hwm_energy(struct hwm_drvdata *ddat, long *energy)
+{
+ struct intel_uncore *uncore = ddat->uncore;
+ struct i915_hwmon *hwmon = ddat->hwmon;
+ struct hwm_energy_info *ei = &ddat->ei;
+ intel_wakeref_t wakeref;
+ i915_reg_t rgaddr;
+ u32 reg_val;
+
+ rgaddr = hwmon->rg.energy_status_all;
+
+ mutex_lock(&hwmon->hwmon_lock);
+
+ with_intel_runtime_pm(uncore->rpm, wakeref)
+ reg_val = intel_uncore_read(uncore, rgaddr);
+
+ if (reg_val >= ei->reg_val_prev)
+ ei->accum_energy += reg_val - ei->reg_val_prev;
+ else
+ ei->accum_energy += UINT_MAX - ei->reg_val_prev + reg_val;
+ ei->reg_val_prev = reg_val;
+
+ *energy = mul_u64_u32_shr(ei->accum_energy, SF_ENERGY,
+ hwmon->scl_shift_energy);
+ mutex_unlock(&hwmon->hwmon_lock);
+
+ return 0;
+}
+
static const struct hwmon_channel_info *
[Intel-gfx] [PATCH 5/7] drm/i915/hwmon: Expose card reactive critical power
From: Ashutosh Dixit
Expose the card reactive critical (I1) power. I1 is exposed as
power1_crit in microwatts (typically for client products) or as
curr1_crit in milliamperes (typically for server).
v2: Add curr1_crit functionality (Ashutosh)
v3:
- Use HWMON_CHANNEL_INFO to define power1_crit, curr1_crit (Badal)
v4: Use hwm_ prefix for static functions (Ashutosh)
v5: Updated date, kernel version in documentation
Cc: Sujaritha Sundaresan
Signed-off-by: Ashutosh Dixit
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 26 +
drivers/gpu/drm/i915/i915_hwmon.c | 95 ++-
drivers/gpu/drm/i915/i915_reg.h | 6 ++
3 files changed, 126 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index 94101f818a70..cc70596fff44 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -26,6 +26,32 @@ Description: RO. Card default power limit (default TDP
setting).
Only supported for particular Intel i915 graphics platforms.
+What: /sys/devices/.../hwmon/hwmon/power1_crit
+Date: September 2022
+KernelVersion: 6
+Contact: dri-de...@lists.freedesktop.org
+Description: RW. Card reactive critical (I1) power limit in microwatts.
+
+ Card reactive critical (I1) power limit in microwatts is exposed
+ for client products. The power controller will throttle the
+ operating frequency if the power averaged over a window exceeds
+ this limit.
+
+ Only supported for particular Intel i915 graphics platforms.
+
+What: /sys/devices/.../hwmon/hwmon/curr1_crit
+Date: September 2022
+KernelVersion: 6
+Contact: dri-de...@lists.freedesktop.org
+Description: RW. Card reactive critical (I1) power limit in milliamperes.
+
+ Card reactive critical (I1) power limit in milliamperes is
+ exposed for server products. The power controller will throttle
+ the operating frequency if the power averaged over a window
+ exceeds this limit.
+
+ Only supported for particular Intel i915 graphics platforms.
+
What: /sys/devices/.../hwmon/hwmon/energy1_input
Date: September 2022
KernelVersion: 6
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index a42cfad78bef..bd9ba312c474 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -11,16 +11,19 @@
#include "i915_hwmon.h"
#include "i915_reg.h"
#include "intel_mchbar_regs.h"
+#include "intel_pcode.h"
#include "gt/intel_gt_regs.h"
/*
* SF_* - scale factors for particular quantities according to hwmon spec.
* - voltage - millivolts
* - power - microwatts
+ * - curr - milliamperes
* - energy - microjoules
*/
#define SF_VOLTAGE 1000
#define SF_POWER 100
+#define SF_CURR1000
#define SF_ENERGY 100
struct hwm_reg {
@@ -160,11 +163,25 @@ hwm_energy(struct hwm_drvdata *ddat, long *energy)
static const struct hwmon_channel_info *hwm_info[] = {
HWMON_CHANNEL_INFO(in, HWMON_I_INPUT),
- HWMON_CHANNEL_INFO(power, HWMON_P_MAX | HWMON_P_RATED_MAX),
+ HWMON_CHANNEL_INFO(power, HWMON_P_MAX | HWMON_P_RATED_MAX |
HWMON_P_CRIT),
HWMON_CHANNEL_INFO(energy, HWMON_E_INPUT),
+ HWMON_CHANNEL_INFO(curr, HWMON_C_CRIT),
NULL
};
+/* I1 is exposed as power_crit or as curr_crit depending on bit 31 */
+static int hwm_pcode_read_i1(struct drm_i915_private *i915, u32 *uval)
+{
+ return snb_pcode_read_p(&i915->uncore, PCODE_POWER_SETUP,
+ POWER_SETUP_SUBCOMMAND_READ_I1, 0, uval);
+}
+
+static int hwm_pcode_write_i1(struct drm_i915_private *i915, u32 uval)
+{
+ return snb_pcode_write_p(&i915->uncore, PCODE_POWER_SETUP,
+ POWER_SETUP_SUBCOMMAND_WRITE_I1, 0, uval);
+}
+
static umode_t
hwm_in_is_visible(const struct hwm_drvdata *ddat, u32 attr)
{
@@ -198,13 +215,18 @@ hwm_in_read(struct hwm_drvdata *ddat, u32 attr, long *val)
static umode_t
hwm_power_is_visible(const struct hwm_drvdata *ddat, u32 attr, int chan)
{
+ struct drm_i915_private *i915 = ddat->uncore->i915;
struct i915_hwmon *hwmon = ddat->hwmon;
+ u32 uval;
switch (attr) {
case hwmon_power_max:
return i915_mmio_reg_valid(hwmon->rg.pkg_rapl_limit) ? 0664 : 0;
case hwmon_power_rated_max:
return i915_mmio_reg_valid(hwmon->rg.pkg_power_sku) ? 0444 : 0;
+ case hwmon_power_crit:
+ return (hwm_pcode_read_i1(i915, &uval) ||
+ !(uval & POWER_SETUP_I1_WATTS)) ? 0 : 0644;
default:
return
[Intel-gfx] [PATCH 6/7] drm/i915/hwmon: Expose power1_max_interval
From: Ashutosh Dixit
Expose power1_max_interval, that is the tau corresponding to PL1. Some bit
manipulation is needed because of the format of PKG_PWR_LIM_1_TIME in
GT0_PACKAGE_RAPL_LIMIT register (1.x * power(2,y)).
v2: Update date and kernel version in Documentation (Badal)
v3: Cleaned up hwm_power1_max_interval_store() (Badal)
Signed-off-by: Ashutosh Dixit
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 9 ++
drivers/gpu/drm/i915/i915_hwmon.c | 114 +-
drivers/gpu/drm/i915/i915_reg.h | 3 +
drivers/gpu/drm/i915/intel_mchbar_regs.h | 4 +
4 files changed, 129 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index cc70596fff44..7995a885c9d6 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -26,6 +26,15 @@ Description: RO. Card default power limit (default TDP
setting).
Only supported for particular Intel i915 graphics platforms.
+What: /sys/devices/.../hwmon/hwmon/power1_max_interval
+Date: September 2022
+KernelVersion: 6
+Contact: dri-de...@lists.freedesktop.org
+Description: RW. Sustained power limit interval (Tau in PL1/Tau) in
+ milliseconds over which sustained power is averaged.
+
+ Only supported for particular Intel i915 graphics platforms.
+
What: /sys/devices/.../hwmon/hwmon/power1_crit
Date: September 2022
KernelVersion: 6
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index bd9ba312c474..7d85a81bc39b 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -20,11 +20,13 @@
* - power - microwatts
* - curr - milliamperes
* - energy - microjoules
+ * - time - milliseconds
*/
#define SF_VOLTAGE 1000
#define SF_POWER 100
#define SF_CURR1000
#define SF_ENERGY 100
+#define SF_TIME1000
struct hwm_reg {
i915_reg_t gt_perf_status;
@@ -53,6 +55,7 @@ struct i915_hwmon {
struct hwm_reg rg;
int scl_shift_power;
int scl_shift_energy;
+ int scl_shift_time;
};
static void
@@ -161,6 +164,114 @@ hwm_energy(struct hwm_drvdata *ddat, long *energy)
return 0;
}
+static ssize_t
+hwm_power1_max_interval_show(struct device *dev, struct device_attribute *attr,
+char *buf)
+{
+ struct hwm_drvdata *ddat = dev_get_drvdata(dev);
+ struct i915_hwmon *hwmon = ddat->hwmon;
+ intel_wakeref_t wakeref;
+ u32 r, x, y, x_w = 2; /* 2 bits */
+ u64 tau4, out;
+
+ with_intel_runtime_pm(ddat->uncore->rpm, wakeref)
+ r = intel_uncore_read(ddat->uncore, hwmon->rg.pkg_rapl_limit);
+
+ x = REG_FIELD_GET(PKG_PWR_LIM_1_TIME_X, r);
+ y = REG_FIELD_GET(PKG_PWR_LIM_1_TIME_Y, r);
+ /*
+* tau = 1.x * power(2,y), x = bits(23:22), y = bits(21:17)
+* = (4 | x) << (y - 2)
+* where (y - 2) ensures a 1.x fixed point representation of 1.x
+* However because y can be < 2, we compute
+* tau4 = (4 | x) << y
+* but add 2 when doing the final right shift to account for units
+*/
+ tau4 = ((1 << x_w) | x) << y;
+ /* val in hwmon interface units (millisec) */
+ out = mul_u64_u32_shr(tau4, SF_TIME, hwmon->scl_shift_time + x_w);
+
+ return sysfs_emit(buf, "%llu\n", out);
+}
+
+static ssize_t
+hwm_power1_max_interval_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct hwm_drvdata *ddat = dev_get_drvdata(dev);
+ struct i915_hwmon *hwmon = ddat->hwmon;
+ long val, max_win, ret;
+ u32 x, y, rxy, x_w = 2; /* 2 bits */
+ u64 tau4, r;
+
+#define PKG_MAX_WIN_DEFAULT 0x12ull
+
+ ret = kstrtoul(buf, 0, &val);
+ if (ret)
+ return ret;
+
+ /*
+* val must be < max in hwmon interface units. The steps below are
+* explained in i915_power1_max_interval_show()
+*/
+ r = FIELD_PREP(PKG_MAX_WIN, PKG_MAX_WIN_DEFAULT);
+ x = REG_FIELD_GET(PKG_MAX_WIN_X, r);
+ y = REG_FIELD_GET(PKG_MAX_WIN_Y, r);
+ tau4 = ((1 << x_w) | x) << y;
+ max_win = mul_u64_u32_shr(tau4, SF_TIME, hwmon->scl_shift_time + x_w);
+
+ if (val > max_win)
+ return -EINVAL;
+
+ /* val in hw units */
+ val = DIV_ROUND_CLOSEST_ULL((u64)val << hwmon->scl_shift_time, SF_TIME);
+ /* Convert to 1.x * power(2,y) */
+ if (!val)
+ return -EINVAL;
+ y = ilog2(val);
+ /* x = (val - (1 << y)) >> (y - 2); */
+ x = (val - (1ul << y)) << x_w >> y;
+
+ rxy =
[Intel-gfx] [PATCH 7/7] drm/i915/hwmon: Extend power/energy for XEHPSDV
From: Dale B Stimson
Extend hwmon power/energy for XEHPSDV especially per gt level energy
usage.
v2: Update to latest HWMON spec (Ashutosh)
v3: Fixed review comments (Ashutosh)
Signed-off-by: Ashutosh Dixit
Signed-off-by: Dale B Stimson
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
Reviewed-by: Ashutosh Dixit
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 7 +-
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 5 +
drivers/gpu/drm/i915/i915_hwmon.c | 114 +-
3 files changed, 123 insertions(+), 3 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index 7995a885c9d6..851525d2117d 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -65,6 +65,11 @@ What:
/sys/devices/.../hwmon/hwmon/energy1_input
Date: September 2022
KernelVersion: 6
Contact: dri-de...@lists.freedesktop.org
-Description: RO. Energy input of device in microjoules.
+Description: RO. Energy input of device or gt in microjoules.
+
+ For i915 device level hwmon devices (name "i915") this
+ reflects energy input for the entire device. For gt level
+ hwmon devices (name "i915_gtN") this reflects energy input
+ for the gt.
Only supported for particular Intel i915 graphics platforms.
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 65336514554d..3c385395aaef 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1591,4 +1591,9 @@
*/
#define MTL_MEDIA_GSI_BASE 0x38
+#define GT0_PACKAGE_ENERGY_STATUS _MMIO(0x250004)
+#define GT0_PACKAGE_RAPL_LIMIT _MMIO(0x250008)
+#define GT0_PACKAGE_POWER_SKU_UNIT _MMIO(0x250068)
+#define GT0_PLATFORM_ENERGY_STATUS _MMIO(0x25006c)
+
#endif /* __INTEL_GT_REGS__ */
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index 7d85a81bc39b..4a4aec1c67ab 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -12,6 +12,7 @@
#include "i915_reg.h"
#include "intel_mchbar_regs.h"
#include "intel_pcode.h"
+#include "gt/intel_gt.h"
#include "gt/intel_gt_regs.h"
/*
@@ -34,6 +35,7 @@ struct hwm_reg {
i915_reg_t pkg_power_sku;
i915_reg_t pkg_rapl_limit;
i915_reg_t energy_status_all;
+ i915_reg_t energy_status_tile;
};
struct hwm_energy_info {
@@ -47,10 +49,12 @@ struct hwm_drvdata {
struct device *hwmon_dev;
struct hwm_energy_info ei; /* Energy info for
energy1_input */
char name[12];
+ int gt_n;
};
struct i915_hwmon {
struct hwm_drvdata ddat;
+ struct hwm_drvdata ddat_gt[I915_MAX_GT];
struct mutex hwmon_lock;/* counter overflow logic and
rmw */
struct hwm_reg rg;
int scl_shift_power;
@@ -144,7 +148,10 @@ hwm_energy(struct hwm_drvdata *ddat, long *energy)
i915_reg_t rgaddr;
u32 reg_val;
- rgaddr = hwmon->rg.energy_status_all;
+ if (ddat->gt_n >= 0)
+ rgaddr = hwmon->rg.energy_status_tile;
+ else
+ rgaddr = hwmon->rg.energy_status_all;
mutex_lock(&hwmon->hwmon_lock);
@@ -280,6 +287,11 @@ static const struct hwmon_channel_info *hwm_info[] = {
NULL
};
+static const struct hwmon_channel_info *hwm_gt_info[] = {
+ HWMON_CHANNEL_INFO(energy, HWMON_E_INPUT),
+ NULL
+};
+
/* I1 is exposed as power_crit or as curr_crit depending on bit 31 */
static int hwm_pcode_read_i1(struct drm_i915_private *i915, u32 *uval)
{
@@ -409,7 +421,10 @@ hwm_energy_is_visible(const struct hwm_drvdata *ddat, u32
attr)
switch (attr) {
case hwmon_energy_input:
- rgaddr = hwmon->rg.energy_status_all;
+ if (ddat->gt_n >= 0)
+ rgaddr = hwmon->rg.energy_status_tile;
+ else
+ rgaddr = hwmon->rg.energy_status_all;
return i915_mmio_reg_valid(rgaddr) ? 0444 : 0;
default:
return 0;
@@ -544,6 +559,44 @@ static const struct hwmon_chip_info hwm_chip_info = {
.info = hwm_info,
};
+static umode_t
+hwm_gt_is_visible(const void *drvdata, enum hwmon_sensor_types type,
+ u32 attr, int channel)
+{
+ struct hwm_drvdata *ddat = (struct hwm_drvdata *)drvdata;
+
+ switch (type) {
+ case hwmon_energy:
+ return hwm_energy_is_visible(ddat, attr);
+ default:
+ return 0;
+ }
+}
+
+static int
+hwm_gt_read(struct device *dev, enum hwmon_sensor_types type, u32 attr,
+ int channel, long *val)
+{
+ struct hwm_drvdata *ddat = dev_get_drvdata(de
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for Further multi-gt handling (rev2)
On Fri, Sep 16, 2022 at 06:38:28AM +, Patchwork wrote: > == Series Details == > > Series: Further multi-gt handling (rev2) > URL : https://patchwork.freedesktop.org/series/108577/ > State : success > > == Summary == > > CI Bug Log - changes from CI_DRM_12143_full -> Patchwork_108577v2_full > > > Summary > --- > > **SUCCESS** > > No regressions found. > Fixed up the issues reported by checkpatch (whitespace and an author != sob mismatch) and applied to drm-intel-gt-next. Thanks Andi, Janusz, and Daniele for the reviews. Matt > > > Participating hosts (10 -> 11) > -- > > Additional (1): shard-rkl > > Known issues > > > Here are the changes found in Patchwork_108577v2_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_eio@unwedge-stress: > - shard-iclb: [PASS][1] -> [TIMEOUT][2] ([i915#3070]) >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12143/shard-iclb3/igt@gem_...@unwedge-stress.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108577v2/shard-iclb4/igt@gem_...@unwedge-stress.html > > * igt@gem_exec_balancer@parallel-bb-first: > - shard-iclb: [PASS][3] -> [SKIP][4] ([i915#4525]) +1 similar > issue >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12143/shard-iclb2/igt@gem_exec_balan...@parallel-bb-first.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108577v2/shard-iclb6/igt@gem_exec_balan...@parallel-bb-first.html > > * igt@gem_exec_fair@basic-flow@rcs0: > - shard-tglb: [PASS][5] -> [FAIL][6] ([i915#2842]) +1 similar > issue >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12143/shard-tglb2/igt@gem_exec_fair@basic-f...@rcs0.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108577v2/shard-tglb2/igt@gem_exec_fair@basic-f...@rcs0.html > > * igt@gem_exec_fair@basic-none-solo@rcs0: > - shard-apl: [PASS][7] -> [FAIL][8] ([i915#2842]) >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12143/shard-apl4/igt@gem_exec_fair@basic-none-s...@rcs0.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108577v2/shard-apl3/igt@gem_exec_fair@basic-none-s...@rcs0.html > > * igt@gem_exec_fair@basic-none@vcs0: > - shard-glk: [PASS][9] -> [FAIL][10] ([i915#2842]) +1 similar > issue >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12143/shard-glk2/igt@gem_exec_fair@basic-n...@vcs0.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108577v2/shard-glk3/igt@gem_exec_fair@basic-n...@vcs0.html > > * igt@gem_exec_fair@basic-pace@vcs1: > - shard-iclb: NOTRUN -> [FAIL][11] ([i915#2842]) >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108577v2/shard-iclb4/igt@gem_exec_fair@basic-p...@vcs1.html > > * igt@gem_exec_fair@basic-throttle@rcs0: > - shard-iclb: [PASS][12] -> [FAIL][13] ([i915#2842]) >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12143/shard-iclb8/igt@gem_exec_fair@basic-throt...@rcs0.html >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108577v2/shard-iclb3/igt@gem_exec_fair@basic-throt...@rcs0.html > > * igt@gem_lmem_swapping@verify-random-ccs: > - shard-apl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#4613]) >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108577v2/shard-apl7/igt@gem_lmem_swapp...@verify-random-ccs.html > > * igt@gem_softpin@evict-single-offset: > - shard-apl: NOTRUN -> [FAIL][15] ([i915#4171]) >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108577v2/shard-apl2/igt@gem_soft...@evict-single-offset.html > > * igt@kms_big_fb@linear-max-hw-stride-64bpp-rotate-180: > - shard-iclb: [PASS][16] -> [DMESG-WARN][17] ([i915#402]) >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12143/shard-iclb6/igt@kms_big...@linear-max-hw-stride-64bpp-rotate-180.html >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108577v2/shard-iclb2/igt@kms_big...@linear-max-hw-stride-64bpp-rotate-180.html > > * igt@kms_ccs@pipe-c-bad-pixel-format-y_tiled_gen12_rc_ccs_cc: > - shard-apl: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#3886]) >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108577v2/shard-apl7/igt@kms_ccs@pipe-c-bad-pixel-format-y_tiled_gen12_rc_ccs_cc.html > > * igt@kms_chamelium@dp-audio-edid: > - shard-apl: NOTRUN -> [SKIP][19] ([fdo#109271] / [fdo#111827]) > +1 similar issue >[19]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108577v2/shard-apl7/igt@kms_chamel...@dp-audio-edid.html > > * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@bc-hdmi-a1-hdmi-a2: > - shard-glk: [PASS][20] -> [FAIL][21] ([i915#79]) >[20]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DR
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gem: Really move i915_gem_context.link under ref protection (rev4)
== Series Details == Series: drm/i915/gem: Really move i915_gem_context.link under ref protection (rev4) URL : https://patchwork.freedesktop.org/series/105975/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12145_full -> Patchwork_105975v4_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_105975v4_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_105975v4_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (11 -> 10) -- Missing(1): shard-rkl Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_105975v4_full: ### IGT changes ### Possible regressions * igt@i915_selftest@mock@requests: - shard-apl: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/shard-apl1/igt@i915_selftest@m...@requests.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/shard-apl1/igt@i915_selftest@m...@requests.html Known issues Here are the changes found in Patchwork_105975v4_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_exec@basic-nohangcheck: - shard-tglb: [PASS][3] -> [FAIL][4] ([i915#6268]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/shard-tglb3/igt@gem_ctx_e...@basic-nohangcheck.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/shard-tglb6/igt@gem_ctx_e...@basic-nohangcheck.html * igt@gem_exec_fair@basic-none-solo@rcs0: - shard-apl: [PASS][5] -> [FAIL][6] ([i915#2842]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/shard-apl3/igt@gem_exec_fair@basic-none-s...@rcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/shard-apl7/igt@gem_exec_fair@basic-none-s...@rcs0.html * igt@gem_exec_fair@basic-none@vcs0: - shard-glk: [PASS][7] -> [FAIL][8] ([i915#2842]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/shard-glk5/igt@gem_exec_fair@basic-n...@vcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/shard-glk1/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][9] -> [SKIP][10] ([i915#2190]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/shard-tglb8/igt@gem_huc_c...@huc-copy.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/shard-tglb6/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@parallel-random-engines: - shard-apl: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#4613]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/shard-apl6/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_pwrite@basic-exhaustion: - shard-iclb: NOTRUN -> [WARN][12] ([i915#2658]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/shard-iclb6/igt@gem_pwr...@basic-exhaustion.html * igt@gem_render_copy@y-tiled-ccs-to-yf-tiled-mc-ccs: - shard-iclb: NOTRUN -> [SKIP][13] ([i915#768]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/shard-iclb6/igt@gem_render_c...@y-tiled-ccs-to-yf-tiled-mc-ccs.html * igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-180-hflip: - shard-iclb: NOTRUN -> [SKIP][14] ([i915#5286]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/shard-iclb6/igt@kms_big...@4-tiled-max-hw-stride-64bpp-rotate-180-hflip.html * igt@kms_big_fb@x-tiled-16bpp-rotate-270: - shard-iclb: NOTRUN -> [SKIP][15] ([fdo#110725] / [fdo#111614]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/shard-iclb6/igt@kms_big...@x-tiled-16bpp-rotate-270.html * igt@kms_big_fb@yf-tiled-64bpp-rotate-180: - shard-iclb: NOTRUN -> [SKIP][16] ([fdo#110723]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/shard-iclb6/igt@kms_big...@yf-tiled-64bpp-rotate-180.html * igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc: - shard-apl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#3886]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/shard-apl6/igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc.html * igt@kms_ccs@pipe-c-crc-primary-rotation-180-y_tiled_gen12_mc_ccs: - shard-iclb: NOTRUN -> [SKIP][18] ([fdo#109278] / [i915#3886]) +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/shard-iclb6/igt@kms_ccs@pipe-c-crc-primary-rotation-180-y_tiled_gen12_mc_ccs.html * igt@kms_ccs@pipe-d-bad-au
Re: [Intel-gfx] [PATCH 16/19] drm/i915/perf: Apply Wa_18013179988
On Thu, 15 Sep 2022 22:16:30 -0700, Dixit, Ashutosh wrote: > > On Tue, 23 Aug 2022 13:41:52 -0700, Umesh Nerlige Ramappa wrote: > > > > Hi Umesh, > > > OA reports in the OA buffer contain an OA timestamp field that helps > > user calculate delta between 2 OA reports. The calculation relies on the > > CS timestamp frequency to convert the timestamp value to nanoseconds. > > The CS timestamp frequency is a function of the CTC_SHIFT value in > > RPM_CONFIG0. > > > > In DG2, OA unit assumes that the CTC_SHIFT is 3, instead of using the > > actual value from RPM_CONFIG0. At the user level, this results in an > > error in calculating delta between 2 OA reports since the OA timestamp > > is not shifted in the same manner as CS timestamp. > > > > To resolve this, return actual OA timestamp frequency to the user in > > i915_getparam_ioctl. > > Rather than exposing actual OA timestamp frequency to userspace (with the > corresponding uapi change, specially if it's only DG2 and not all future > products) questions about a couple of other options: > > Option 1. Can we set CTC_SHIFT in RPM_CONFIG0 to 3, so change GT freq to be > the > same as OA freq :-) > >The HSD seems to mention this: >Is setting CTC SHIFT to 0b11 on driver init an acceptable W/A? >Note: Changing the shift setting on live driver may break apps that are >currently running (including desktop manager). > > Option 2. Is it possible to correct the timestamps in OA report headers to > compensate for the difference between OA and GT frequencies (say > when > copying OA data to userspace)? > > Though not sure if this is preferable to having userspace do this. Also do we need input from userland on this patch? UMD's might need to assess the impact of having different GT and OA frequencies at their end since they consume OA data? Thanks. -- Ashutosh
Re: [Intel-gfx] [PATCH] drm/i915: fix device info for devices without display
On Fri, Sep 16, 2022 at 11:26:42AM +0300, Jani Nikula wrote:
Commit 00c6cbfd4e8a ("drm/i915: move pipe_mask and cpu_transcoder_mask
to runtime info") moved the pipe_mask member from struct
intel_device_info to intel_runtime_info, but overlooked some of our
platforms initializing device info .display = {}. This is significant,
as pipe_mask is the single point of truth for a device having a display
or not; the platforms in question left pipe_mask to whatever was set for
the platforms they "inherit" from in the complex macro scheme we have.
Add new NO_DISPLAY macro initializing .__runtime.pipe_mask = 0, which
will cause the device info .display sub-struct to be zeroed in
intel_device_info_runtime_init(). A better solution (or simply audit of
proper use of HAS_DISPLAY() checks) is required before moving forward
with [1].
Also clear all the display related members in runtime info if there's no
display. The latter is a bit tedious, but it's for completeness at this
time, to ensure similar functionality as before.
[1]
https://lore.kernel.org/r/dfda1bf67f02ceb07c280b7a13216405fd1f7a34.1660137416.git.jani.nik...@intel.com
Fixes: 00c6cbfd4e8a ("drm/i915: move pipe_mask and cpu_transcoder_mask to runtime
info")
Cc: Lucas De Marchi
Cc: Maarten Lankhort
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_pci.c | 11 ++-
drivers/gpu/drm/i915/intel_device_info.c | 6 ++
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 77e7df21f539..cd4487a1d3be 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -41,6 +41,8 @@
.__runtime.media.ip.ver = (x), \
.__runtime.display.ip.ver = (x)
+#define NO_DISPLAY .__runtime.pipe_mask = 0
+
#define I845_PIPE_OFFSETS \
.display.pipe_offsets = { \
[TRANSCODER_A] = PIPE_A_OFFSET, \
@@ -519,9 +521,8 @@ static const struct intel_device_info ivb_m_gt2_info = {
static const struct intel_device_info ivb_q_info = {
GEN7_FEATURES,
PLATFORM(INTEL_IVYBRIDGE),
+ NO_DISPLAY,
.gt = 2,
- .__runtime.pipe_mask = 0, /* legal, last one wins */
- .__runtime.cpu_transcoder_mask = 0,
.has_l3_dpf = 1,
};
@@ -1039,7 +1040,7 @@ static const struct intel_device_info xehpsdv_info = {
XE_HPM_FEATURES,
DGFX_FEATURES,
PLATFORM(INTEL_XEHPSDV),
- .display = { },
+ NO_DISPLAY,
.has_64k_pages = 1,
.needs_compact_pt = 1,
.has_media_ratio_mode = 1,
@@ -1081,7 +1082,7 @@ static const struct intel_device_info dg2_info = {
static const struct intel_device_info ats_m_info = {
DG2_FEATURES,
- .display = { 0 },
+ NO_DISPLAY,
.require_force_probe = 1,
.tuning_thread_rr_after_dep = 1,
};
@@ -1103,7 +1104,7 @@ static const struct intel_device_info pvc_info = {
.__runtime.graphics.ip.rel = 60,
.__runtime.media.ip.rel = 60,
PLATFORM(INTEL_PONTEVECCHIO),
- .display = { 0 },
+ NO_DISPLAY,
.has_flat_ccs = 0,
.__runtime.platform_engine_mask =
BIT(BCS0) |
diff --git a/drivers/gpu/drm/i915/intel_device_info.c
b/drivers/gpu/drm/i915/intel_device_info.c
index 1434dc33cf49..20575eb77ea7 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -433,8 +433,14 @@ void intel_device_info_runtime_init(struct
drm_i915_private *dev_priv)
dev_priv->drm.driver_features &= ~(DRIVER_MODESET |
DRIVER_ATOMIC);
memset(&info->display, 0, sizeof(info->display));
+
+ runtime->cpu_transcoder_mask = 0;
memset(runtime->num_sprites, 0, sizeof(runtime->num_sprites));
memset(runtime->num_scalers, 0, sizeof(runtime->num_scalers));
+ runtime->fbc_mask = 0;
+ runtime->has_hdcp = false;
+ runtime->has_dmc = false;
+ runtime->has_dsc = false;
why are these not inside __runtime.display?
Lucas De Marchi
Re: [Intel-gfx] [PATCH 1/1] drm/i915/guc: Delay disabling guc_id scheduling for better hysteresis
On 9/16/2022 1:58 AM, Tvrtko Ursulin wrote:
On 16/09/2022 08:53, Teres Alexis, Alan Previn wrote:
On Thu, 2022-09-15 at 09:48 +0100, Tvrtko Ursulin wrote:
On 15/09/2022 03:12, Alan Previn wrote:
From: Matthew Brost
Add a delay, configurable via debugfs (default 34ms), to disable
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+ u16 guc_ids_in_use;
Any specific reason to use u16? It can usually just result in larger
code generated and I don't see any space saving needed or achieved when
it is sandwiched between two struct list_heads.
no specific reason - will switch to uint32.
Unsigned int would be best. Every time there is explicit width
specified it looks like there is special reason for the width - like
interacting with hardware or firmware protocol. At least I always see
it like that.
+ u64 sched_disable_delay_ms;
64-bits for the delay then sounds like overkill. Both should IMO
just be
unsigned ints.
avoiding some typecasting on related functions that reference this
but thats not a good excuse so will fix it.
Right, yes, clamp/cap/validate at debugfs entry points should do it.
+ int sched_disable_gucid_threshold;
unsigned int as well, so reader does not have to think about:
return guc->submission_state.guc_ids_in_use >
guc->submission_state.sched_disable_gucid_threshold;
further down.
yes agreed - will fix.
+static void __delay_sched_disable(struct work_struct *wrk)
+{
+ struct intel_context *ce =
+ container_of(wrk, typeof(*ce),
guc_state.sched_disable_delay.work);
+ struct intel_guc *guc = ce_to_guc(ce);
+ unsigned long flags;
+
spin_lock_irqsave(&ce->guc_state.lock, flags);
+ if (bypass_sched_disable(guc, ce)) {
+ spin_unlock_irqrestore(&ce->guc_state.lock, flags);
+ intel_context_sched_disable_unpin(ce);
+ } else {
+ do_sched_disable(guc, ce, flags);
+ }
lock
if
unlock
do sttuff
else
do_sched_disable - which unlocks inside
Now move to next block..
+}
+
+static bool guc_id_pressure(struct intel_guc *guc, struct
intel_context *ce)
+{
/*
- * We have to check if the context has been disabled by
another thread,
- * check if submssion has been disabled to seal a race with
reset and
- * finally check if any more requests have been committed to the
- * context ensursing that a request doesn't slip through the
- * 'context_pending_disable' fence.
+ * parent contexts are perma-pinned, if we are unpinning do
schedule
+ * disable immediately.
*/
- if (unlikely(!context_enabled(ce) || submission_disabled(guc) ||
- context_has_committed_requests(ce))) {
- clr_context_enabled(ce);
+ if (intel_context_is_parent(ce))
+ return true;
+
+ /*
+ * If we are beyond the threshold for avail guc_ids, do
schedule disable immediately.
+ */
+ return guc->submission_state.guc_ids_in_use >
+ guc->submission_state.sched_disable_gucid_threshold;
+}
+
+static void guc_context_sched_disable(struct intel_context *ce)
+{
+ struct intel_guc *guc = ce_to_guc(ce);
+ u64 delay = guc->submission_state.sched_disable_delay_ms;
+ unsigned long flags;
+
+ spin_lock_irqsave(&ce->guc_state.lock, flags);
+
+ if (bypass_sched_disable(guc, ce)) {
+ spin_unlock_irqrestore(&ce->guc_state.lock, flags);
+ intel_context_sched_disable_unpin(ce);
+ } else if (!intel_context_is_closed(ce) &&
!guc_id_pressure(guc, ce) &&
+ delay) {
spin_unlock_irqrestore(&ce->guc_state.lock, flags);
- goto unpin;
+ mod_delayed_work(system_unbound_wq,
+ &ce->guc_state.sched_disable_delay,
+ msecs_to_jiffies(delay));
+ } else {
+ do_sched_disable(guc, ce, flags);
}
lock
if
unlock
do stuff
else if
unlock
do stuff
else
do_sched_disable - which unlocks inside
IMO it creates less readable code for the benefit of not repeating
with_intel_runtime_pm -> __guc_context_sched_disable two times. Dunno..
it's ugly but I have no suggestions. Hm does it have to send using the
busy loop? It couldn't just queue the request and then wait for
reply if
disable message was emitted?
I agree that the above code lacks readability - will see if i can
break it down to smaller
functions with cleaner in-function lock/unlock pairs. I agree that a
little code duplication
is better than less readable code. It was inherited code i didn't
want to modify but I'll
go ahead and refactor this.
On the busy loop - im assuming you are refering to the actual ct
sending. I'll consult my
team if i am missing anything more but based on comments, I believe
callers must use that
function to guarantee reservation of space in the G2H CTB to always
have space to capture
responses for actions that MUST be acknowledged from GuC
(acknowledged by either replying
with a success or failure). This is necessa
Re: [Intel-gfx] [PATCH 0/3] i915: freq caps and perf_limit_reasons changes for MTL
On Sat, Sep 10, 2022 at 07:38:41AM -0700, Ashutosh Dixit wrote: > Since https://patchwork.freedesktop.org/series/107908/ is now merged, > rebase this series on latest drm-tip and post a clean series. pushed to drm-intel-gt-next thansk for the patches > > Ashutosh Dixit (2): > drm/i915/mtl: PERF_LIMIT_REASONS changes for MTL > drm/i915/rps: Freq caps for MTL > > Tilak Tangudu (1): > drm/i915/debugfs: Add perf_limit_reasons in debugfs > > drivers/gpu/drm/i915/gt/intel_gt.c| 6 +++ > drivers/gpu/drm/i915/gt/intel_gt.h| 1 + > drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 31 + > drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 6 +-- > drivers/gpu/drm/i915/gt/intel_rps.c | 46 +++ > drivers/gpu/drm/i915/i915_reg.h | 11 + > 6 files changed, 89 insertions(+), 12 deletions(-) > > -- > 2.34.1 >
[Intel-gfx] ✓ Fi.CI.IGT: success for Fix HFVSDB parsing (rev2)
== Series Details == Series: Fix HFVSDB parsing (rev2) URL : https://patchwork.freedesktop.org/series/107144/ State : success == Summary == CI Bug Log - changes from CI_DRM_12145_full -> Patchwork_107144v2_full Summary --- **SUCCESS** No regressions found. Participating hosts (11 -> 11) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_107144v2_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@in-flight-contexts-1us: - shard-iclb: [PASS][1] -> [TIMEOUT][2] ([i915#3070]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/shard-iclb7/igt@gem_...@in-flight-contexts-1us.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107144v2/shard-iclb3/igt@gem_...@in-flight-contexts-1us.html * igt@gem_exec_balancer@parallel-bb-first: - shard-iclb: [PASS][3] -> [SKIP][4] ([i915#4525]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/shard-iclb2/igt@gem_exec_balan...@parallel-bb-first.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107144v2/shard-iclb5/igt@gem_exec_balan...@parallel-bb-first.html * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][5] -> [SKIP][6] ([i915#2190]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/shard-tglb8/igt@gem_huc_c...@huc-copy.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107144v2/shard-tglb7/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@parallel-random-engines: - shard-apl: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107144v2/shard-apl3/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_pwrite@basic-exhaustion: - shard-iclb: NOTRUN -> [WARN][8] ([i915#2658]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107144v2/shard-iclb1/igt@gem_pwr...@basic-exhaustion.html * igt@gem_render_copy@y-tiled-ccs-to-yf-tiled-mc-ccs: - shard-iclb: NOTRUN -> [SKIP][9] ([i915#768]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107144v2/shard-iclb1/igt@gem_render_c...@y-tiled-ccs-to-yf-tiled-mc-ccs.html * igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-180-hflip: - shard-iclb: NOTRUN -> [SKIP][10] ([i915#5286]) +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107144v2/shard-iclb1/igt@kms_big...@4-tiled-max-hw-stride-64bpp-rotate-180-hflip.html * igt@kms_big_fb@x-tiled-16bpp-rotate-270: - shard-iclb: NOTRUN -> [SKIP][11] ([fdo#110725] / [fdo#111614]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107144v2/shard-iclb1/igt@kms_big...@x-tiled-16bpp-rotate-270.html * igt@kms_big_fb@yf-tiled-64bpp-rotate-180: - shard-iclb: NOTRUN -> [SKIP][12] ([fdo#110723]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107144v2/shard-iclb1/igt@kms_big...@yf-tiled-64bpp-rotate-180.html * igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc: - shard-apl: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#3886]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107144v2/shard-apl3/igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc.html * igt@kms_ccs@pipe-c-crc-primary-rotation-180-y_tiled_gen12_mc_ccs: - shard-iclb: NOTRUN -> [SKIP][14] ([fdo#109278] / [i915#3886]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107144v2/shard-iclb1/igt@kms_ccs@pipe-c-crc-primary-rotation-180-y_tiled_gen12_mc_ccs.html * igt@kms_ccs@pipe-d-bad-aux-stride-y_tiled_gen12_mc_ccs: - shard-iclb: NOTRUN -> [SKIP][15] ([fdo#109278]) +6 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107144v2/shard-iclb1/igt@kms_ccs@pipe-d-bad-aux-stride-y_tiled_gen12_mc_ccs.html * igt@kms_chamelium@hdmi-audio-edid: - shard-apl: NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827]) +1 similar issue [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107144v2/shard-apl2/igt@kms_chamel...@hdmi-audio-edid.html * igt@kms_chamelium@vga-hpd-for-each-pipe: - shard-iclb: NOTRUN -> [SKIP][17] ([fdo#109284] / [fdo#111827]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107144v2/shard-iclb1/igt@kms_chamel...@vga-hpd-for-each-pipe.html * igt@kms_content_protection@uevent: - shard-iclb: NOTRUN -> [SKIP][18] ([fdo#109300] / [fdo#111066]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107144v2/shard-iclb1/igt@kms_content_protect...@uevent.html * igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions: - shard-glk: [PASS][19] -> [FAIL][20] ([i915#2346]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/shard-glk9/igt@kms_
Re: [Intel-gfx] [PATCH v1 3/4] drm/i915: Split i915_gem_init_stolen()
On Fri, Sep 16, 2022 at 05:50:33PM +0530, Iddamsetty, Aravind wrote:
On 16-09-2022 02:09, Lucas De Marchi wrote:
Add some helpers: adjust_stolen(), request_smem_stolen_() and
init_reserved_stolen() that are now called by i915_gem_init_stolen() to
initialize each part of the Data Stolen Memory region. Main goal is to
split the reserved part, also known as WOPCM, as its calculation changes
often per platform.
This also fixes a bug in graphics version < 5 (in theory, not tested,
due to no machine available): it would bail out on stolen creation due
to "Stolen reserved area outside stolen memory". Other than that, no
change in behavior.
Signed-off-by: Lucas De Marchi
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index c34065fe2ecc..0e57a6d81534 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -77,22 +77,26 @@ void i915_gem_stolen_remove_node(struct drm_i915_private
*i915,
mutex_unlock(&i915->mm.stolen_lock);
}
-static int i915_adjust_stolen(struct drm_i915_private *i915,
- struct resource *dsm)
+static bool valid_stolen_size(struct resource *dsm)
+{
+ return dsm->start != 0 && dsm->end > dsm->start;
+}
+
+static int adjust_stolen(struct drm_i915_private *i915,
+struct resource *dsm)
{
struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
struct intel_uncore *uncore = ggtt->vm.gt->uncore;
- struct resource *r;
- if (dsm->start == 0 || dsm->end <= dsm->start)
+ if (!valid_stolen_size(dsm))
return -EINVAL;
/*
+* Make sure we don't clobber the GTT if it's within stolen memory
+*
* TODO: We have yet too encounter the case where the GTT wasn't at the
* end of stolen. With that assumption we could simplify this.
*/
-
- /* Make sure we don't clobber the GTT if it's within stolen memory */
if (GRAPHICS_VER(i915) <= 4 &&
!IS_G33(i915) && !IS_PINEVIEW(i915) && !IS_G4X(i915)) {
struct resource stolen[2] = {*dsm, *dsm};
@@ -131,10 +135,20 @@ static int i915_adjust_stolen(struct drm_i915_private
*i915,
}
}
+ if (!valid_stolen_size(dsm))
+ return -EINVAL;
+
+ return 0;
+}
+
+static int request_smem_stolen(struct drm_i915_private *i915,
+ struct resource *dsm)
+{
+ struct resource *r;
+
/*
-* With stolen lmem, we don't need to check if the address range
-* overlaps with the non-stolen system memory range, since lmem is local
-* to the gpu.
+* With stolen lmem, we don't need to request if the address range
replace /if/for
+* since lmem is local to the gpu.
humn.. it seems I skip some words here.
With stolen lmem, we don't need to request system memory since the
stolen region is local to the gpu.
*/
if (HAS_LMEM(i915))
return 0;
@@ -392,39 +406,22 @@ static void icl_get_stolen_reserved(struct
drm_i915_private *i915,
}
}
-static int i915_gem_init_stolen(struct intel_memory_region *mem)
+/*
+ * Initialize i915->dsm_reserved to contain the reserved space within the Data
+ * Stolen Memory. This is a range on the top of DSM that is reserved, not to
+ * be used by driver, so must be excluded from the region passed to the
+ * allocator later. In the spec this is also called as WOPCM.
+ *
+ * Our expectation is that the reserved space is at the top of the stolen
+ * region, as it has been the case for every platform, and *never* at the
+ * bottom, so the calculation here can be simplified.
+ */
+static int init_reserved_stolen(struct drm_i915_private *i915)
{
- struct drm_i915_private *i915 = mem->i915;
struct intel_uncore *uncore = &i915->uncore;
resource_size_t reserved_base, stolen_top;
- resource_size_t reserved_total, reserved_size;
-
- mutex_init(&i915->mm.stolen_lock);
-
- if (intel_vgpu_active(i915)) {
- drm_notice(&i915->drm,
- "%s, disabling use of stolen memory\n",
- "iGVT-g active");
- return 0;
- }
-
- if (i915_vtd_active(i915) && GRAPHICS_VER(i915) < 8) {
- drm_notice(&i915->drm,
- "%s, disabling use of stolen memory\n",
- "DMAR active");
- return 0;
- }
-
- if (resource_size(&mem->region) == 0)
- return 0;
-
- if (i915_adjust_stolen(i915, &mem->region))
- return 0;
-
- GEM_BUG_ON(i915->dsm.start == 0);
- GEM_BUG_ON(i915->dsm.end <= i915->dsm.start);
-
- i915->dsm = mem->region;
+ resource_size_t reserved_size;
+ int ret = 0;
stolen_top = i915->dsm.end + 1;
reserved_base = stolen_top;
@@ -453,19 +450,17 @@ static int i9
[Intel-gfx] [PATCH 0/4] drm/atomic: Lockless blocking commits
From: Ville Syrjälä I've talked about making blocking commits lockless a few times in the past, so here's finally an attempt at it. The main benefit I see from this is that TEST_ONLY commits no longer getting blocked on the mutexes by parallel blocking commits. I have a small test here that spools up two threads, one does just TEST_ONLY commits in a loop, the other does either blocking or non-blocking page flips. Results came out as follows on a snb machine here: test-only-vs-non-blocking: -85319 TEST_ONLY commits in 200 usecs, 23 usecs / commit +87144 TEST_ONLY commits in 206 usecs, 22 usecs / commit test-only-vs-blocking: -219 TEST_ONLY commits in 2001768 usecs, 9140 usecs / commit +82442 TEST_ONLY commits in 211 usecs, 24 usecs / commit Now, I have no idea if anyone actually cares about lack of parallelism due to locked blocking commits or not. Hence Cc'd some compositor folks as well. I guess this is more of an RFC at this point. Also curious to see if CI goes up in smoke or not... Cc: Daniel Vetter Cc: Maarten Lankhorst Cc: Rob Clark Cc: Simon Ser Cc: Pekka Paalanen Cc: Jonas Ådahl Ville Syrjälä (4): drm/atomic: Treat a nonblocking commit following a blocking commit as blocking commit drm/i915: Don't reuse commit_work for the cleanup drm/atomic: Allow lockless blocking commits drm/i915: Make blocking commits lockless drivers/gpu/drm/drm_atomic.c | 32 +-- drivers/gpu/drm/drm_atomic_helper.c | 19 +++ drivers/gpu/drm/drm_atomic_uapi.c | 11 +-- drivers/gpu/drm/i915/display/intel_display.c | 15 +++-- .../drm/i915/display/intel_display_types.h| 1 + include/drm/drm_atomic.h | 8 + 6 files changed, 64 insertions(+), 22 deletions(-) -- 2.35.1
[Intel-gfx] [PATCH 1/4] drm/atomic: Treat a nonblocking commit following a blocking commit as blocking commit
From: Ville Syrjälä
Currently a nonblocking commit will actually block if it is
preceded by a blocking commit. It just happens block on the
mutex rather than on the completion. I shall call these as
not-actually-nonblocking commits.
I would like to make blocking commits execute locklessly,
just as nonblocking commits already do. The main benefit
would that parallel TEST_ONLY commits would not get blocked
on the mutexes until the parallel blocking commit is done.
To achieve that without a significant change in behaviour
for the not-actually-nonblocking commits let's treat them
exactly the same as blocking commit, ie. instead of
returning -EBUSY they will just block.
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Rob Clark
Cc: Simon Ser
Cc: Pekka Paalanen
Cc: Jonas Ådahl
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic_helper.c | 19 ---
include/drm/drm_atomic.h| 7 +++
2 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index ee5fea48b5cb..bff087674cb5 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2109,7 +2109,7 @@ static int stall_checks(struct drm_crtc *crtc, bool
nonblock)
* Userspace is not allowed to get ahead of the previous
* commit with nonblocking ones.
*/
- if (!completed && nonblock) {
+ if (!completed && nonblock && commit->nonblock) {
spin_unlock(&crtc->commit_lock);
drm_dbg_atomic(crtc->dev,
"[CRTC:%d:%s] busy with a
previous commit\n",
@@ -2152,7 +2152,7 @@ static void release_crtc_commit(struct completion
*completion)
drm_crtc_commit_put(commit);
}
-static void init_commit(struct drm_crtc_commit *commit, struct drm_crtc *crtc)
+static void init_commit(struct drm_crtc_commit *commit, struct drm_crtc *crtc,
bool nonblock)
{
init_completion(&commit->flip_done);
init_completion(&commit->hw_done);
@@ -2160,10 +2160,11 @@ static void init_commit(struct drm_crtc_commit *commit,
struct drm_crtc *crtc)
INIT_LIST_HEAD(&commit->commit_entry);
kref_init(&commit->ref);
commit->crtc = crtc;
+ commit->nonblock = nonblock;
}
static struct drm_crtc_commit *
-crtc_or_fake_commit(struct drm_atomic_state *state, struct drm_crtc *crtc)
+crtc_or_fake_commit(struct drm_atomic_state *state, struct drm_crtc *crtc,
bool nonblock)
{
if (crtc) {
struct drm_crtc_state *new_crtc_state;
@@ -2178,7 +2179,7 @@ crtc_or_fake_commit(struct drm_atomic_state *state,
struct drm_crtc *crtc)
if (!state->fake_commit)
return NULL;
- init_commit(state->fake_commit, NULL);
+ init_commit(state->fake_commit, NULL, nonblock);
}
return state->fake_commit;
@@ -2250,7 +2251,7 @@ int drm_atomic_helper_setup_commit(struct
drm_atomic_state *state,
if (!commit)
return -ENOMEM;
- init_commit(commit, crtc);
+ init_commit(commit, crtc, nonblock);
new_crtc_state->commit = commit;
@@ -2299,6 +2300,7 @@ int drm_atomic_helper_setup_commit(struct
drm_atomic_state *state,
* commit with nonblocking ones.
*/
if (nonblock && old_conn_state->commit &&
+ old_conn_state->commit->nonblock &&
!try_wait_for_completion(&old_conn_state->commit->flip_done)) {
drm_dbg_atomic(conn->dev,
"[CONNECTOR:%d:%s] busy with a previous
commit\n",
@@ -2308,7 +2310,8 @@ int drm_atomic_helper_setup_commit(struct
drm_atomic_state *state,
}
/* Always track connectors explicitly for e.g. link retraining.
*/
- commit = crtc_or_fake_commit(state, new_conn_state->crtc ?:
old_conn_state->crtc);
+ commit = crtc_or_fake_commit(state, new_conn_state->crtc ?:
old_conn_state->crtc,
+nonblock);
if (!commit)
return -ENOMEM;
@@ -2321,6 +2324,7 @@ int drm_atomic_helper_setup_commit(struct
drm_atomic_state *state,
* commit with nonblocking ones.
*/
if (nonblock && old_plane_state->commit &&
+ old_plane_state->commit->nonblock &&
!try_wait_for_completion(&old_plane_state->commit->flip_done)) {
drm_dbg_atomic(plane->dev,
"[PLANE:%d:%s] busy with a previous
commit\n",
@@ -2330,7 +2334,8 @@ int drm_atomic_helper_setup_commit(struct
drm_atomic_state *state,
[Intel-gfx] [PATCH 2/4] drm/i915: Don't reuse commit_work for the cleanup
From: Ville Syrjälä
Currently we reuse the commit_work for a later cleanup step.
Let's not do that so that atomic ioctl handler won't accidentally
wait for the cleanup work when it really wants to just wait on the
commit_tail() part. We'll just add another work struct for the
cleanup.
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Rob Clark
Cc: Simon Ser
Cc: Pekka Paalanen
Cc: Jonas Ådahl
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 6 +++---
drivers/gpu/drm/i915/display/intel_display_types.h | 1 +
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index dd008ba8afe3..cd617046e0ee 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7422,7 +7422,7 @@ static void intel_cleanup_dsbs(struct intel_atomic_state
*state)
static void intel_atomic_cleanup_work(struct work_struct *work)
{
struct intel_atomic_state *state =
- container_of(work, struct intel_atomic_state, base.commit_work);
+ container_of(work, struct intel_atomic_state, cleanup_work);
struct drm_i915_private *i915 = to_i915(state->base.dev);
intel_cleanup_dsbs(state);
@@ -7643,8 +7643,8 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
* schedule point (cond_resched()) here anyway to keep latencies
* down.
*/
- INIT_WORK(&state->base.commit_work, intel_atomic_cleanup_work);
- queue_work(system_highpri_wq, &state->base.commit_work);
+ INIT_WORK(&state->cleanup_work, intel_atomic_cleanup_work);
+ queue_work(system_highpri_wq, &state->cleanup_work);
}
static void intel_atomic_commit_work(struct work_struct *work)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 298d00a11f47..971e2b1e1b26 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -655,6 +655,7 @@ struct intel_atomic_state {
struct i915_sw_fence commit_ready;
+ struct work_struct cleanup_work;
struct llist_node freed;
};
--
2.35.1
[Intel-gfx] [PATCH 3/4] drm/atomic: Allow lockless blocking commits
From: Ville Syrjälä
The easiest way to execute blocking commits locklessly is to just
schedule them onto the workqueue excatly as we do for nonblocking
commits. And to preserve the blocking behaviour of the ioctl we
just flush the work before exiting the kernel.
We do need to reorder the state_put() vs drop_locks() of course
so we don't flush_work() while still holding the locks.
Note that a lot of the current users of drm_atomic_commit()
(eg. lot of the atomic helpers) have the ww_ctx stuff outside
the drm_atomic_state handling. With that structure we can't
actually pull the flush_work() past the drop_locks(). So in
order to make those places actually lockless we'll need
reverse the layers. That is left for a future excercise
and for now we just roll the flush_work() straight into
drm_atomic_commit(), leaving the non-flushing version for
just the atomic ioctl handler.
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Rob Clark
Cc: Simon Ser
Cc: Pekka Paalanen
Cc: Jonas Ådahl
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic.c | 32 +--
drivers/gpu/drm/drm_atomic_uapi.c | 11 ---
include/drm/drm_atomic.h | 1 +
3 files changed, 39 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index f197f59f6d99..6d728af4e8cf 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1411,7 +1411,7 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
EXPORT_SYMBOL(drm_atomic_check_only);
/**
- * drm_atomic_commit - commit configuration atomically
+ * drm_atomic_commit_noflush - commit configuration atomically, without
waiting for the commit
* @state: atomic configuration to check
*
* Note that this function can return -EDEADLK if the driver needed to acquire
@@ -1424,7 +1424,7 @@ EXPORT_SYMBOL(drm_atomic_check_only);
* Returns:
* 0 on success, negative error code on failure.
*/
-int drm_atomic_commit(struct drm_atomic_state *state)
+int drm_atomic_commit_noflush(struct drm_atomic_state *state)
{
struct drm_mode_config *config = &state->dev->mode_config;
struct drm_printer p = drm_info_printer(state->dev->dev);
@@ -1441,6 +1441,34 @@ int drm_atomic_commit(struct drm_atomic_state *state)
return config->funcs->atomic_commit(state->dev, state, false);
}
+EXPORT_SYMBOL(drm_atomic_commit_noflush);
+
+/**
+ * drm_atomic_commit - commit configuration atomically, waiting for the commit
to finish
+ * @state: atomic configuration to check
+ *
+ * Note that this function can return -EDEADLK if the driver needed to acquire
+ * more locks but encountered a deadlock. The caller must then do the usual w/w
+ * backoff dance and restart. All other errors are fatal.
+ *
+ * This function will take its own reference on @state.
+ * Callers should always release their reference with drm_atomic_state_put().
+ *
+ * Returns:
+ * 0 on success, negative error code on failure.
+ */
+int drm_atomic_commit(struct drm_atomic_state *state)
+{
+ int ret;
+
+ ret = drm_atomic_commit_noflush(state);
+ if (ret)
+ return ret;
+
+ flush_work(&state->commit_work);
+
+ return 0;
+}
EXPORT_SYMBOL(drm_atomic_commit);
/**
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 79730fa1dd8e..73ec26fe3393 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -1290,6 +1290,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
struct drm_atomic_state *state;
struct drm_modeset_acquire_ctx ctx;
struct drm_out_fence_state *fence_state;
+ bool flush = false;
int ret = 0;
unsigned int i, j, num_fences;
@@ -1423,7 +1424,8 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
} else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
ret = drm_atomic_nonblocking_commit(state);
} else {
- ret = drm_atomic_commit(state);
+ ret = drm_atomic_commit_noflush(state);
+ flush = ret == 0;
}
out:
@@ -1436,10 +1438,13 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
goto retry;
}
- drm_atomic_state_put(state);
-
drm_modeset_drop_locks(&ctx);
drm_modeset_acquire_fini(&ctx);
+ if (flush)
+ flush_work(&state->commit_work);
+
+ drm_atomic_state_put(state);
+
return ret;
}
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index 0924c322ddfb..d19ce8898bd4 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -740,6 +740,7 @@ drm_atomic_add_affected_planes(struct drm_atomic_state
*state,
struct drm_crtc *crtc);
int __must_check drm_atomic_check_only(struct drm_atomic_state *state);
+int __must_check drm_atomic_commit_noflush(struct drm_atomic_state *state);
int __must_check drm_atomic_commit(
[Intel-gfx] [PATCH 4/4] drm/i915: Make blocking commits lockless
From: Ville Syrjälä
Make blocking commits execute locklessly (just as nonblocking
commits do) by scheduling them onto the workqueues as well.
There will be a later flush_work() done by whoever called
the commit hook to make sure the blocking behaviour of the
ioctl/etc. is preserved.
I also wondered about just dropping the locks straight from the
driver, but I guess whoever called us might still depend on
having the locks so that seems like a terrible idea. Also calling
commit_tail() directly when not holding the locks would then
allow eg. two ioctls to execute full modesets in parallel,
which we don't want as we haven't fully evaluated all modeset
codepaths for concurrency issues. Currently we achieve serial
excution with a combination of an ordered workqueue (for
nonblocking commits) and reliance on the singular connection_mutex
(for blocking commits), and a flush_workqueue() to sync between
the two.
So by always scheduling everything onto the workqueues we
don't have to worry about racing between the lockless direct
commit_tail() calls, and we don't need some kind of new atomic
hook that would do said call for us after dropping the locks.
Also less codepaths in general seems like a beneficial thing.
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Rob Clark
Cc: Simon Ser
Cc: Pekka Paalanen
Cc: Jonas Ådahl
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index cd617046e0ee..18a5f14e7f41 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7771,15 +7771,10 @@ static int intel_atomic_commit(struct drm_device *dev,
INIT_WORK(&state->base.commit_work, intel_atomic_commit_work);
i915_sw_fence_commit(&state->commit_ready);
- if (nonblock && state->modeset) {
+ if (state->modeset)
queue_work(dev_priv->display.wq.modeset,
&state->base.commit_work);
- } else if (nonblock) {
+ else
queue_work(dev_priv->display.wq.flip, &state->base.commit_work);
- } else {
- if (state->modeset)
- flush_workqueue(dev_priv->display.wq.modeset);
- intel_atomic_commit_tail(state);
- }
return 0;
}
--
2.35.1
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/psr: Do not re-activate PSR if there was a PSR aux error
== Series Details == Series: drm/i915/psr: Do not re-activate PSR if there was a PSR aux error URL : https://patchwork.freedesktop.org/series/108653/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12145_full -> Patchwork_108653v1_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_108653v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_108653v1_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (11 -> 10) -- Missing(1): shard-rkl Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_108653v1_full: ### IGT changes ### Possible regressions * igt@kms_flip@plain-flip-fb-recreate-interruptible@d-edp1: - shard-tglb: [PASS][1] -> [INCOMPLETE][2] +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/shard-tglb2/igt@kms_flip@plain-flip-fb-recreate-interrupti...@d-edp1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108653v1/shard-tglb6/igt@kms_flip@plain-flip-fb-recreate-interrupti...@d-edp1.html Known issues Here are the changes found in Patchwork_108653v1_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@unwedge-stress: - shard-iclb: [PASS][3] -> [TIMEOUT][4] ([i915#3070]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/shard-iclb7/igt@gem_...@unwedge-stress.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108653v1/shard-iclb7/igt@gem_...@unwedge-stress.html * igt@gem_exec_balancer@parallel-bb-first: - shard-iclb: [PASS][5] -> [SKIP][6] ([i915#4525]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/shard-iclb2/igt@gem_exec_balan...@parallel-bb-first.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108653v1/shard-iclb8/igt@gem_exec_balan...@parallel-bb-first.html * igt@gem_lmem_swapping@parallel-random-engines: - shard-apl: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108653v1/shard-apl3/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_pwrite@basic-exhaustion: - shard-iclb: NOTRUN -> [WARN][8] ([i915#2658]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108653v1/shard-iclb4/igt@gem_pwr...@basic-exhaustion.html * igt@gem_render_copy@y-tiled-ccs-to-yf-tiled-mc-ccs: - shard-iclb: NOTRUN -> [SKIP][9] ([i915#768]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108653v1/shard-iclb4/igt@gem_render_c...@y-tiled-ccs-to-yf-tiled-mc-ccs.html * igt@i915_pm_dc@dc6-dpms: - shard-iclb: [PASS][10] -> [FAIL][11] ([i915#3989] / [i915#454]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/shard-iclb6/igt@i915_pm...@dc6-dpms.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108653v1/shard-iclb3/igt@i915_pm...@dc6-dpms.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: [PASS][12] -> [DMESG-WARN][13] ([i915#180]) +3 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/shard-apl7/igt@i915_susp...@fence-restore-tiled2untiled.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108653v1/shard-apl6/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-180-hflip: - shard-iclb: NOTRUN -> [SKIP][14] ([i915#5286]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108653v1/shard-iclb4/igt@kms_big...@4-tiled-max-hw-stride-64bpp-rotate-180-hflip.html * igt@kms_big_fb@x-tiled-16bpp-rotate-270: - shard-iclb: NOTRUN -> [SKIP][15] ([fdo#110725] / [fdo#111614]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108653v1/shard-iclb4/igt@kms_big...@x-tiled-16bpp-rotate-270.html * igt@kms_big_fb@yf-tiled-64bpp-rotate-180: - shard-iclb: NOTRUN -> [SKIP][16] ([fdo#110723]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108653v1/shard-iclb4/igt@kms_big...@yf-tiled-64bpp-rotate-180.html * igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc: - shard-apl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#3886]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108653v1/shard-apl3/igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc.html * igt@kms_ccs@pipe-c-crc-primary-rotation-180-y_tiled_gen12_mc_ccs: - shard-iclb: NOTRUN -> [SKIP][18] ([fdo#109278] / [i915#3886]) +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108653v
[Intel-gfx] [PATCH 2/3] drm/i915/fbc: Remove stale FIXME
From: Ville Syrjälä
Remove the old tales about 90/270 degree rotation
effectively preventing FBC. That hasn't been true since
we stopped demanding the fence is present in
commit 691f7ba58d52 ("drm/i915/display/fbc: Make fences
a nice-to-have for GEN9+")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index f38175304928..e97083ea1059 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -1009,7 +1009,8 @@ static bool intel_fbc_is_fence_ok(const struct
intel_plane_state *plane_state)
{
struct drm_i915_private *i915 = to_i915(plane_state->uapi.plane->dev);
- /* The use of a CPU fence is one of two ways to detect writes by the
+ /*
+* The use of a CPU fence is one of two ways to detect writes by the
* CPU to the scanout and trigger updates to the FBC.
*
* The other method is by software tracking (see
@@ -1019,12 +1020,6 @@ static bool intel_fbc_is_fence_ok(const struct
intel_plane_state *plane_state)
* Note that is possible for a tiled surface to be unmappable (and
* so have no fence associated with it) due to aperture constraints
* at the time of pinning.
-*
-* FIXME with 90/270 degree rotation we should use the fence on
-* the normal GTT view (the rotated view doesn't even have a
-* fence). Would need changes to the FBC fence Y offset as well.
-* For now this will effectively disable FBC with 90/270 degree
-* rotation.
*/
return DISPLAY_VER(i915) >= 9 ||
(plane_state->flags & PLANE_HAS_FENCE &&
--
2.35.1
[Intel-gfx] [PATCH 1/3] drm/i915: Nuke stale plane cdclk ratio FIXMEs
From: Ville Syrjälä
The plane ratio stuff got implemented in
commit bb6ae9e653dc ("drm/i915: Allow planes to
declare their minimum acceptable cdclk") so these
FIXMEs have no business being here.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index ed05070b7307..a12e86d92783 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -2464,10 +2464,6 @@ static int bdw_modeset_calc_cdclk(struct
intel_cdclk_state *cdclk_state)
if (min_cdclk < 0)
return min_cdclk;
- /*
-* FIXME should also account for plane ratio
-* once 64bpp pixel formats are supported.
-*/
cdclk = bdw_calc_cdclk(min_cdclk);
cdclk_state->logical.cdclk = cdclk;
@@ -2534,10 +2530,6 @@ static int skl_modeset_calc_cdclk(struct
intel_cdclk_state *cdclk_state)
vco = skl_dpll0_vco(cdclk_state);
- /*
-* FIXME should also account for plane ratio
-* once 64bpp pixel formats are supported.
-*/
cdclk = skl_calc_cdclk(min_cdclk, vco);
cdclk_state->logical.vco = vco;
--
2.35.1
[Intel-gfx] [PATCH 3/3] drm/i915: Mark FBC B gone if pipe B is gone
From: Ville Syrjälä
If pipe B is fused off we also shouldn't have FBC B.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_device_info.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_device_info.c
b/drivers/gpu/drm/i915/intel_device_info.c
index 1434dc33cf49..fbefebc023f1 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -394,6 +394,7 @@ void intel_device_info_runtime_init(struct drm_i915_private
*dev_priv)
if (dfsm & SKL_DFSM_PIPE_B_DISABLE) {
runtime->pipe_mask &= ~BIT(PIPE_B);
runtime->cpu_transcoder_mask &= ~BIT(TRANSCODER_B);
+ runtime->fbc_mask &= ~BIT(INTEL_FBC_B);
}
if (dfsm & SKL_DFSM_PIPE_C_DISABLE) {
runtime->pipe_mask &= ~BIT(PIPE_C);
--
2.35.1
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gem: Really move i915_gem_context.link under ref protection (rev4)
On Friday, 16 September 2022 17:12:30 CEST Patchwork wrote: > == Series Details == > > Series: drm/i915/gem: Really move i915_gem_context.link under ref protection > (rev4) > URL : https://patchwork.freedesktop.org/series/105975/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_12145_full -> Patchwork_105975v4_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_105975v4_full absolutely need > to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_105975v4_full, please notify your bug team to allow > them > to document this new failure mode, which will reduce false positives in CI. > > > > Participating hosts (11 -> 10) > -- > > Missing(1): shard-rkl > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_105975v4_full: > > ### IGT changes ### > > Possible regressions > > * igt@i915_selftest@mock@requests: > - shard-apl: [PASS][1] -> [INCOMPLETE][2] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/shard-apl1/igt@i915_selftest@m...@requests.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/shard-apl1/igt@i915_selftest@m...@requests.html Looks like https://gitlab.freedesktop.org/drm/intel/issues/6656, will be re-reported after CI filters are updated. Thanks, Janusz > > > Known issues > > > Here are the changes found in Patchwork_105975v4_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_ctx_exec@basic-nohangcheck: > - shard-tglb: [PASS][3] -> [FAIL][4] ([i915#6268]) >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/shard-tglb3/igt@gem_ctx_e...@basic-nohangcheck.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/shard-tglb6/igt@gem_ctx_e...@basic-nohangcheck.html > > * igt@gem_exec_fair@basic-none-solo@rcs0: > - shard-apl: [PASS][5] -> [FAIL][6] ([i915#2842]) >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/shard-apl3/igt@gem_exec_fair@basic-none-s...@rcs0.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/shard-apl7/igt@gem_exec_fair@basic-none-s...@rcs0.html > > * igt@gem_exec_fair@basic-none@vcs0: > - shard-glk: [PASS][7] -> [FAIL][8] ([i915#2842]) +1 similar > issue >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/shard-glk5/igt@gem_exec_fair@basic-n...@vcs0.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/shard-glk1/igt@gem_exec_fair@basic-n...@vcs0.html > > * igt@gem_huc_copy@huc-copy: > - shard-tglb: [PASS][9] -> [SKIP][10] ([i915#2190]) >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/shard-tglb8/igt@gem_huc_c...@huc-copy.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/shard-tglb6/igt@gem_huc_c...@huc-copy.html > > * igt@gem_lmem_swapping@parallel-random-engines: > - shard-apl: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#4613]) >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/shard-apl6/igt@gem_lmem_swapp...@parallel-random-engines.html > > * igt@gem_pwrite@basic-exhaustion: > - shard-iclb: NOTRUN -> [WARN][12] ([i915#2658]) >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/shard-iclb6/igt@gem_pwr...@basic-exhaustion.html > > * igt@gem_render_copy@y-tiled-ccs-to-yf-tiled-mc-ccs: > - shard-iclb: NOTRUN -> [SKIP][13] ([i915#768]) +1 similar issue >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/shard-iclb6/igt@gem_render_c...@y-tiled-ccs-to-yf-tiled-mc-ccs.html > > * igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-180-hflip: > - shard-iclb: NOTRUN -> [SKIP][14] ([i915#5286]) +1 similar issue >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/shard-iclb6/igt@kms_big...@4-tiled-max-hw-stride-64bpp-rotate-180-hflip.html > > * igt@kms_big_fb@x-tiled-16bpp-rotate-270: > - shard-iclb: NOTRUN -> [SKIP][15] ([fdo#110725] / [fdo#111614]) > +1 similar issue >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/shard-iclb6/igt@kms_big...@x-tiled-16bpp-rotate-270.html > > * igt@kms_big_fb@yf-tiled-64bpp-rotate-180: > - shard-iclb: NOTRUN -> [SKIP][16] ([fdo#110723]) >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/shard-iclb6/igt@kms_big...@yf-tiled-64bpp-rotate-180.html > > * igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc: > - shard-apl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#3886]) >[17]: > https://intel-gfx-ci.01.org/tree/drm-ti
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display: remove ipc_enabled from struct drm_i915_private
== Series Details == Series: drm/i915/display: remove ipc_enabled from struct drm_i915_private URL : https://patchwork.freedesktop.org/series/108654/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12145_full -> Patchwork_108654v1_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_108654v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_108654v1_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (11 -> 11) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_108654v1_full: ### IGT changes ### Possible regressions * igt@gem_exec_whisper@basic-queues-priority-all: - shard-iclb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/shard-iclb1/igt@gem_exec_whis...@basic-queues-priority-all.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108654v1/shard-iclb8/igt@gem_exec_whis...@basic-queues-priority-all.html * igt@kms_dsc@dsc-with-bpc-formats@pipe-d-edp-1-12bpc-yuyv: - shard-tglb: [PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/shard-tglb6/igt@kms_dsc@dsc-with-bpc-form...@pipe-d-edp-1-12bpc-yuyv.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108654v1/shard-tglb8/igt@kms_dsc@dsc-with-bpc-form...@pipe-d-edp-1-12bpc-yuyv.html Known issues Here are the changes found in Patchwork_108654v1_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@unwedge-stress: - shard-iclb: [PASS][5] -> [TIMEOUT][6] ([i915#3070]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/shard-iclb7/igt@gem_...@unwedge-stress.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108654v1/shard-iclb5/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-none@vcs0: - shard-glk: [PASS][7] -> [FAIL][8] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/shard-glk5/igt@gem_exec_fair@basic-n...@vcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108654v1/shard-glk2/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_pwrite@basic-exhaustion: - shard-iclb: NOTRUN -> [WARN][9] ([i915#2658]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108654v1/shard-iclb4/igt@gem_pwr...@basic-exhaustion.html * igt@gem_render_copy@y-tiled-ccs-to-yf-tiled-mc-ccs: - shard-iclb: NOTRUN -> [SKIP][10] ([i915#768]) +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108654v1/shard-iclb4/igt@gem_render_c...@y-tiled-ccs-to-yf-tiled-mc-ccs.html * igt@i915_suspend@sysfs-reader: - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([i915#180]) +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/shard-apl2/igt@i915_susp...@sysfs-reader.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108654v1/shard-apl2/igt@i915_susp...@sysfs-reader.html * igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-180-hflip: - shard-iclb: NOTRUN -> [SKIP][13] ([i915#5286]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108654v1/shard-iclb4/igt@kms_big...@4-tiled-max-hw-stride-64bpp-rotate-180-hflip.html * igt@kms_big_fb@x-tiled-16bpp-rotate-270: - shard-iclb: NOTRUN -> [SKIP][14] ([fdo#110725] / [fdo#111614]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108654v1/shard-iclb4/igt@kms_big...@x-tiled-16bpp-rotate-270.html * igt@kms_big_fb@yf-tiled-64bpp-rotate-180: - shard-iclb: NOTRUN -> [SKIP][15] ([fdo#110723]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108654v1/shard-iclb4/igt@kms_big...@yf-tiled-64bpp-rotate-180.html * igt@kms_ccs@pipe-c-crc-primary-rotation-180-y_tiled_gen12_mc_ccs: - shard-iclb: NOTRUN -> [SKIP][16] ([fdo#109278] / [i915#3886]) +1 similar issue [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108654v1/shard-iclb4/igt@kms_ccs@pipe-c-crc-primary-rotation-180-y_tiled_gen12_mc_ccs.html * igt@kms_ccs@pipe-c-random-ccs-data-y_tiled_gen12_rc_ccs: - shard-apl: NOTRUN -> [SKIP][17] ([fdo#109271]) +10 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108654v1/shard-apl8/igt@kms_ccs@pipe-c-random-ccs-data-y_tiled_gen12_rc_ccs.html * igt@kms_ccs@pipe-d-bad-aux-stride-y_tiled_gen12_mc_ccs: - shard-iclb: NOTRUN -> [SKIP][18] ([fdo#109278]) +6 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108654
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gem: Really move i915_gem_context.link under ref protection (rev4)
== Series Details == Series: drm/i915/gem: Really move i915_gem_context.link under ref protection (rev4) URL : https://patchwork.freedesktop.org/series/105975/ State : success == Summary == CI Bug Log - changes from CI_DRM_12145_full -> Patchwork_105975v4_full Summary --- **SUCCESS** No regressions found. Participating hosts (11 -> 10) -- Missing(1): shard-rkl Known issues Here are the changes found in Patchwork_105975v4_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_exec@basic-nohangcheck: - shard-tglb: [PASS][1] -> [FAIL][2] ([i915#6268]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/shard-tglb3/igt@gem_ctx_e...@basic-nohangcheck.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/shard-tglb6/igt@gem_ctx_e...@basic-nohangcheck.html * igt@gem_exec_fair@basic-none-solo@rcs0: - shard-apl: [PASS][3] -> [FAIL][4] ([i915#2842]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/shard-apl3/igt@gem_exec_fair@basic-none-s...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/shard-apl7/igt@gem_exec_fair@basic-none-s...@rcs0.html * igt@gem_exec_fair@basic-none@vcs0: - shard-glk: [PASS][5] -> [FAIL][6] ([i915#2842]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/shard-glk5/igt@gem_exec_fair@basic-n...@vcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/shard-glk1/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][7] -> [SKIP][8] ([i915#2190]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/shard-tglb8/igt@gem_huc_c...@huc-copy.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/shard-tglb6/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@parallel-random-engines: - shard-apl: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#4613]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/shard-apl6/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_pwrite@basic-exhaustion: - shard-iclb: NOTRUN -> [WARN][10] ([i915#2658]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/shard-iclb6/igt@gem_pwr...@basic-exhaustion.html * igt@gem_render_copy@y-tiled-ccs-to-yf-tiled-mc-ccs: - shard-iclb: NOTRUN -> [SKIP][11] ([i915#768]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/shard-iclb6/igt@gem_render_c...@y-tiled-ccs-to-yf-tiled-mc-ccs.html * igt@i915_selftest@mock@requests: - shard-apl: [PASS][12] -> [INCOMPLETE][13] ([i915#6656]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12145/shard-apl1/igt@i915_selftest@m...@requests.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/shard-apl1/igt@i915_selftest@m...@requests.html * igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-180-hflip: - shard-iclb: NOTRUN -> [SKIP][14] ([i915#5286]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/shard-iclb6/igt@kms_big...@4-tiled-max-hw-stride-64bpp-rotate-180-hflip.html * igt@kms_big_fb@x-tiled-16bpp-rotate-270: - shard-iclb: NOTRUN -> [SKIP][15] ([fdo#110725] / [fdo#111614]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/shard-iclb6/igt@kms_big...@x-tiled-16bpp-rotate-270.html * igt@kms_big_fb@yf-tiled-64bpp-rotate-180: - shard-iclb: NOTRUN -> [SKIP][16] ([fdo#110723]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/shard-iclb6/igt@kms_big...@yf-tiled-64bpp-rotate-180.html * igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc: - shard-apl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#3886]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/shard-apl6/igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc.html * igt@kms_ccs@pipe-c-crc-primary-rotation-180-y_tiled_gen12_mc_ccs: - shard-iclb: NOTRUN -> [SKIP][18] ([fdo#109278] / [i915#3886]) +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/shard-iclb6/igt@kms_ccs@pipe-c-crc-primary-rotation-180-y_tiled_gen12_mc_ccs.html * igt@kms_ccs@pipe-d-bad-aux-stride-y_tiled_gen12_mc_ccs: - shard-iclb: NOTRUN -> [SKIP][19] ([fdo#109278]) +6 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/shard-iclb6/igt@kms_ccs@pipe-d-bad-aux-stride-y_tiled_gen12_mc_ccs.html * igt@kms_chamelium@hdmi-audio-edid: - shard-apl: NOTRUN -> [SKIP][20] ([fdo#109271] / [fdo#111827]) +1 similar issue [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105975v4/shard-apl8/igt@kms_chamel...@hdmi-a
[Intel-gfx] [PATCH v2 0/3] drm/i915: Improvements to stolen memory setup
Better split, document, and make the code paths for integrated and discrete more similar. v2: - s/GENMASK/REG_GENMASK64/ where appropriate - Fix comment Signed-off-by: Lucas De Marchi --- Lucas De Marchi (3): drm/i915: Add missing mask when reading GEN12_DSMBASE drm/i915: Split i915_gem_init_stolen() drm/i915/dgfx: Make failure to setup stolen non-fatal drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 188 + drivers/gpu/drm/i915/i915_reg.h| 1 + 2 files changed, 109 insertions(+), 80 deletions(-) --- base-commit: 13d68eac4fd3384eeb113e183c4abe2e3afdf76c change-id: 20220915-stolen-7aa0e407368f Best regards, -- Lucas De Marchi
[Intel-gfx] [PATCH v2 3/3] drm/i915/dgfx: Make failure to setup stolen non-fatal
There is no reason to consider the setup of Data Stolen Memory fatal on
dgfx and non-fatal on integrated. Move the debug and error propagation
around so both have the same behavior: non-fatal. Before this change,
loading i915 on a system with TGL + DG2 would result in just TGL
succeeding the initialization (without stolen).
Now loading i915 on the same system with an injected failure in
i915_gem_init_stolen():
$ dmesg | grep stolen
i915 :00:02.0: [drm] Injected failure, disabling use of stolen
memory
i915 :00:02.0: [drm:init_stolen_smem [i915]] Skip stolen region:
failed to setup
i915 :03:00.0: [drm] Injected failure, disabling use of stolen
memory
i915 :03:00.0: [drm:init_stolen_lmem [i915]] Skip stolen region:
failed to setup
Both GPUs are still available:
$ sudo build/tools/lsgpu
card1Intel Dg2 (Gen12)
drm:/dev/dri/card1
└─renderD129
drm:/dev/dri/renderD129
card0Intel Tigerlake (Gen12)
drm:/dev/dri/card0
└─renderD128
drm:/dev/dri/renderD128
Signed-off-by: Lucas De Marchi
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index 6edf4e374f54..c5a4035c99cd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -494,26 +494,26 @@ static int i915_gem_init_stolen(struct
intel_memory_region *mem)
drm_notice(&i915->drm,
"%s, disabling use of stolen memory\n",
"iGVT-g active");
- return 0;
+ return -ENOSPC;
}
if (i915_vtd_active(i915) && GRAPHICS_VER(i915) < 8) {
drm_notice(&i915->drm,
"%s, disabling use of stolen memory\n",
"DMAR active");
- return 0;
+ return -ENOSPC;
}
if (adjust_stolen(i915, &mem->region))
- return 0;
+ return -ENOSPC;
if (request_smem_stolen(i915, &mem->region))
- return 0;
+ return -ENOSPC;
i915->dsm = mem->region;
if (init_reserved_stolen(i915))
- return 0;
+ return -ENOSPC;
/* Exclude the reserved region from driver use */
mem->region.end = i915->dsm_reserved.start - 1;
@@ -527,7 +527,7 @@ static int i915_gem_init_stolen(struct intel_memory_region
*mem)
(u64)i915->stolen_usable_size >> 10);
if (i915->stolen_usable_size == 0)
- return 0;
+ return -ENOSPC;
/* Basic memrange allocator for stolen space. */
drm_mm_init(&i915->mm.stolen, 0, i915->stolen_usable_size);
@@ -765,11 +765,17 @@ i915_gem_object_create_stolen(struct drm_i915_private
*i915,
static int init_stolen_smem(struct intel_memory_region *mem)
{
+ int err;
+
/*
* Initialise stolen early so that we may reserve preallocated
* objects for the BIOS to KMS transition.
*/
- return i915_gem_init_stolen(mem);
+ err = i915_gem_init_stolen(mem);
+ if (err)
+ drm_dbg(&mem->i915->drm, "Skip stolen region: failed to
setup\n");
+
+ return 0;
}
static int release_stolen_smem(struct intel_memory_region *mem)
@@ -786,21 +792,25 @@ static const struct intel_memory_region_ops
i915_region_stolen_smem_ops = {
static int init_stolen_lmem(struct intel_memory_region *mem)
{
+ struct drm_i915_private *i915 = mem->i915;
int err;
if (GEM_WARN_ON(resource_size(&mem->region) == 0))
- return -ENODEV;
+ return 0;
err = i915_gem_init_stolen(mem);
- if (err)
- return err;
+ if (err) {
+ drm_dbg(&mem->i915->drm, "Skip stolen region: failed to
setup\n");
+ return 0;
+ }
- if (mem->io_size && !io_mapping_init_wc(&mem->iomap,
- mem->io_start,
- mem->io_size)) {
- err = -EIO;
+ if (mem->io_size &&
+ !io_mapping_init_wc(&mem->iomap, mem->io_start, mem->io_size))
goto err_cleanup;
- }
+
+ drm_dbg(&i915->drm, "Stolen Local memory IO start: %pa\n",
+ &mem->io_start);
+ drm_dbg(&i915->drm, "Stolen Local DSM base: %pa\n", &mem->region.start);
return 0;
@@ -874,16 +884,6 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private *i915,
u16 type,
if (IS_ERR(mem))
return mem;
- /*
-* TODO: consider creating common helper to just print all the
-* interesting stuff from intel_memory_region, which we can use for all
-* our probed re
[Intel-gfx] [PATCH v2 1/3] drm/i915: Add missing mask when reading GEN12_DSMBASE
DSMBASE register is defined so BDSM bitfield contains the bits 63 to 20
of the base address of stolen. For the supported platforms bits 0-19 are
zero but that may not be true in future. Add the missing mask.
v2: Use REG_GENMASK64()
Acked-by: Aravind Iddamsetty
Reviewed-by: Caz Yokoyama
Signed-off-by: Lucas De Marchi
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index acc561c0f0aa..3665f9b035bb 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -814,7 +814,7 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private *i915,
u16 type,
return ERR_PTR(-ENXIO);
/* Use DSM base address instead for stolen memory */
- dsm_base = intel_uncore_read64(uncore, GEN12_DSMBASE);
+ dsm_base = intel_uncore_read64(uncore, GEN12_DSMBASE) & GEN12_BDSM_MASK;
if (IS_DG1(uncore->i915)) {
lmem_size = pci_resource_len(pdev, GEN12_LMEM_BAR);
if (WARN_ON(lmem_size < dsm_base))
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 1a9bd829fc7e..9584a50ed612 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7953,6 +7953,7 @@ enum skl_power_gate {
#define GEN12_GSMBASE _MMIO(0x108100)
#define GEN12_DSMBASE _MMIO(0x1080C0)
+#define GEN12_BDSM_MASK REG_GENMASK64(63, 20)
#define XEHP_CLOCK_GATE_DIS_MMIO(0x101014)
#define SGSI_SIDECLK_DIS REG_BIT(17)
--
b4 0.10.0-dev-bbe61
[Intel-gfx] [PATCH v2 2/3] drm/i915: Split i915_gem_init_stolen()
Add some helpers: adjust_stolen(), request_smem_stolen_() and
init_reserved_stolen() that are now called by i915_gem_init_stolen() to
initialize each part of the Data Stolen Memory region.
Main goal is to split the reserved part within the stolen, also known as
WOPCM, as its calculation changes often per platform and is a big source
of confusion when handling stolen memory.
Signed-off-by: Lucas De Marchi
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index 3665f9b035bb..6edf4e374f54 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -77,22 +77,26 @@ void i915_gem_stolen_remove_node(struct drm_i915_private
*i915,
mutex_unlock(&i915->mm.stolen_lock);
}
-static int i915_adjust_stolen(struct drm_i915_private *i915,
- struct resource *dsm)
+static bool valid_stolen_size(struct resource *dsm)
+{
+ return dsm->start != 0 && dsm->end > dsm->start;
+}
+
+static int adjust_stolen(struct drm_i915_private *i915,
+struct resource *dsm)
{
struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
struct intel_uncore *uncore = ggtt->vm.gt->uncore;
- struct resource *r;
- if (dsm->start == 0 || dsm->end <= dsm->start)
+ if (!valid_stolen_size(dsm))
return -EINVAL;
/*
+* Make sure we don't clobber the GTT if it's within stolen memory
+*
* TODO: We have yet too encounter the case where the GTT wasn't at the
* end of stolen. With that assumption we could simplify this.
*/
-
- /* Make sure we don't clobber the GTT if it's within stolen memory */
if (GRAPHICS_VER(i915) <= 4 &&
!IS_G33(i915) && !IS_PINEVIEW(i915) && !IS_G4X(i915)) {
struct resource stolen[2] = {*dsm, *dsm};
@@ -131,10 +135,20 @@ static int i915_adjust_stolen(struct drm_i915_private
*i915,
}
}
+ if (!valid_stolen_size(dsm))
+ return -EINVAL;
+
+ return 0;
+}
+
+static int request_smem_stolen(struct drm_i915_private *i915,
+ struct resource *dsm)
+{
+ struct resource *r;
+
/*
-* With stolen lmem, we don't need to check if the address range
-* overlaps with the non-stolen system memory range, since lmem is local
-* to the gpu.
+* With stolen lmem, we don't need to request system memory for the
+* address range since it's local to the gpu.
*/
if (HAS_LMEM(i915))
return 0;
@@ -392,39 +406,22 @@ static void icl_get_stolen_reserved(struct
drm_i915_private *i915,
}
}
-static int i915_gem_init_stolen(struct intel_memory_region *mem)
+/*
+ * Initialize i915->dsm_reserved to contain the reserved space within the Data
+ * Stolen Memory. This is a range on the top of DSM that is reserved, not to
+ * be used by driver, so must be excluded from the region passed to the
+ * allocator later. In the spec this is also called as WOPCM.
+ *
+ * Our expectation is that the reserved space is at the top of the stolen
+ * region, as it has been the case for every platform, and *never* at the
+ * bottom, so the calculation here can be simplified.
+ */
+static int init_reserved_stolen(struct drm_i915_private *i915)
{
- struct drm_i915_private *i915 = mem->i915;
struct intel_uncore *uncore = &i915->uncore;
resource_size_t reserved_base, stolen_top;
- resource_size_t reserved_total, reserved_size;
-
- mutex_init(&i915->mm.stolen_lock);
-
- if (intel_vgpu_active(i915)) {
- drm_notice(&i915->drm,
- "%s, disabling use of stolen memory\n",
- "iGVT-g active");
- return 0;
- }
-
- if (i915_vtd_active(i915) && GRAPHICS_VER(i915) < 8) {
- drm_notice(&i915->drm,
- "%s, disabling use of stolen memory\n",
- "DMAR active");
- return 0;
- }
-
- if (resource_size(&mem->region) == 0)
- return 0;
-
- i915->dsm = mem->region;
-
- if (i915_adjust_stolen(i915, &i915->dsm))
- return 0;
-
- GEM_BUG_ON(i915->dsm.start == 0);
- GEM_BUG_ON(i915->dsm.end <= i915->dsm.start);
+ resource_size_t reserved_size;
+ int ret = 0;
stolen_top = i915->dsm.end + 1;
reserved_base = stolen_top;
@@ -455,17 +452,16 @@ static int i915_gem_init_stolen(struct
intel_memory_region *mem)
&reserved_base, &reserved_size);
}
- /*
-* Our expectation is that the reserved space is at the top of the
-* stolen region and *never* at the bottom. If we see !reserved_base,
-* it likely means we failed to read the registers correctly.
-*/
+ /* No reserved stolen */
+
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Add HWMON support (rev6)
== Series Details == Series: drm/i915: Add HWMON support (rev6) URL : https://patchwork.freedesktop.org/series/104278/ 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: Add HWMON support (rev6)
== Series Details == Series: drm/i915: Add HWMON support (rev6) URL : https://patchwork.freedesktop.org/series/104278/ State : warning == Summary == Error: dim checkpatch failed 5f9791e75d29 drm/i915/hwmon: Add HWMON infrastructure Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' -:85: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #85: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 196 lines checked 55fd9940206e drm/i915/hwmon: Add HWMON current voltage support -:27: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #27: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 104 lines checked 39bb05f1a309 drm/i915/hwmon: Power PL1 limit and TDP setting 0f426062d76a drm/i915/hwmon: Show device level energy usage 87b285e45675 drm/i915/hwmon: Expose card reactive critical power b109c509a12b drm/i915/hwmon: Expose power1_max_interval 3ee00bdbe06d drm/i915/hwmon: Extend power/energy for XEHPSDV
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Add HWMON support (rev6)
== Series Details ==
Series: drm/i915: Add HWMON support (rev6)
URL : https://patchwork.freedesktop.org/series/104278/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12146 -> Patchwork_104278v6
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_104278v6 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_104278v6, 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_104278v6/index.html
Participating hosts (44 -> 39)
--
Additional (1): fi-kbl-guc
Missing(6): fi-rkl-11600 fi-hsw-4200u bat-dg2-8 fi-icl-u2 fi-ctg-p8600
fi-bdw-samus
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_104278v6:
### IGT changes ###
Possible regressions
* igt@debugfs_test@read_all_entries:
- fi-pnv-d510:[PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12146/fi-pnv-d510/igt@debugfs_test@read_all_entries.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v6/fi-pnv-d510/igt@debugfs_test@read_all_entries.html
Known issues
Here are the changes found in Patchwork_104278v6 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][3] -> [INCOMPLETE][4] ([i915#4785])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12146/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v6/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
* igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][5] ([fdo#109271] / [i915#4312] /
[i915#5594] / [i915#6246])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v6/fi-hsw-4770/igt@run...@aborted.html
- fi-kbl-guc: NOTRUN -> [FAIL][6] ([i915#6219])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v6/fi-kbl-guc/igt@run...@aborted.html
Possible fixes
* igt@i915_module_load@reload:
- {fi-tgl-mst}: [WARN][7] ([i915#6596]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12146/fi-tgl-mst/igt@i915_module_l...@reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v6/fi-tgl-mst/igt@i915_module_l...@reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka: [FAIL][9] ([i915#6298]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12146/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v6/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
Warnings
* igt@runner@aborted:
- fi-pnv-d510:[FAIL][11] ([fdo#109271] / [i915#2403] / [i915#4312])
-> [FAIL][12] ([i915#2403] / [i915#4312])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12146/fi-pnv-d510/igt@run...@aborted.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v6/fi-pnv-d510/igt@run...@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#2403]: https://gitlab.freedesktop.org/drm/intel/issues/2403
[i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785
[i915#5537]: https://gitlab.freedesktop.org/drm/intel/issues/5537
[i915#5594]: https://gitlab.freedesktop.org/drm/intel/issues/5594
[i915#5828]: https://gitlab.freedesktop.org/drm/intel/issues/5828
[i915#6219]: https://gitlab.freedesktop.org/drm/intel/issues/6219
[i915#6246]: https://gitlab.freedesktop.org/drm/intel/issues/6246
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
[i915#6596]: https://gitlab.freedesktop.org/drm/intel/issues/6596
Build changes
-
* IGT: IGT_6656 -> IGTPW_7782
* Linux: CI_DRM_12146 -> Patchwork_104278v6
CI-20190529: 20190529
CI_DRM_12146: afdeadb1830054a87b9e2d765caa2f197321ca0c @
git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_7782: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7782/index.html
IGT_6656: 24100c4e181c50e3678aeca9c641b8a43555ad73 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_104278v6: afdeadb1830054a87b9e2d765caa2f197321ca0c @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux co
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/atomic: Lockless blocking commits
== Series Details == Series: drm/atomic: Lockless blocking commits URL : https://patchwork.freedesktop.org/series/108669/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/b
Re: [Intel-gfx] [PATCH 14/19] drm/i915/perf: Add Wa_1608133521:dg2
On Thu, Sep 15, 2022 at 06:21:55PM -0700, Dixit, Ashutosh wrote:
On Tue, 23 Aug 2022 13:41:50 -0700, Umesh Nerlige Ramappa wrote:
DG2 introduces 64 bit counters and OA reports that have 64 bit values
for fields in the report header - report_id, timestamp, context_id and
gpu ticks. i915 uses report_id, timestamp and context_id to check for
valid reports.
In some DG2 variants, only the lower dwords for timestamp, report_id and
context_id are accessible. Add workaround for such reports.
Once again, if we are productizing A-step or it is going to be in CI
upstream, this is:
No, we are not. I am dropping A0 specific fixes from this series in the
next revision. Doing so will also simplify implementing Jani's comment
here to have a 'per variant const oa format array'.
Thanks,
Umesh
Reviewed-by: Ashutosh Dixit
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/i915_perf.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index a28f07923d8f..a858ce57e465 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -310,7 +310,7 @@ static u32 i915_oa_max_sample_rate = 10;
* be used as a mask to align the OA tail pointer. In some of the
* formats, R is used to denote reserved field.
*/
-static const struct i915_oa_format oa_formats[I915_OA_FORMAT_MAX] = {
+static struct i915_oa_format oa_formats[I915_OA_FORMAT_MAX] = {
[I915_OA_FORMAT_A13]= { 0, 64 },
[I915_OA_FORMAT_A29]= { 1, 128 },
[I915_OA_FORMAT_A13_B8_C8] = { 2, 128 },
@@ -4746,6 +4746,13 @@ static void oa_init_supported_formats(struct i915_perf
*perf)
/* Wa_16010703925:dg2 */
clear_bit(I915_OAR_FORMAT_A36u64_B8_C8, perf->format_mask);
}
+
+ if (IS_DG2_GRAPHICS_STEP(i915, G10, STEP_A0, STEP_B0) ||
+ IS_DG2_GRAPHICS_STEP(i915, G11, STEP_A0, STEP_FOREVER)) {
+ /* Wa_1608133521:dg2 */
+ oa_formats[I915_OAR_FORMAT_A36u64_B8_C8].header = HDR_32_BIT;
+ oa_formats[I915_OA_FORMAT_A38u64_R2u64_B8_C8].header =
HDR_32_BIT;
+ }
}
static void i915_perf_init_info(struct drm_i915_private *i915)
--
2.25.1
