[Intel-gfx] [PULL] drm-misc-fixes
Hi Dave, Daniel, Here's this week drm-misc-fixes PR Maxime drm-misc-fixes-2023-01-05: Several fixes to fix the error path of dma_buf_export, add a missing structure declaration resulting in a compiler warning, fix the GEM handle refcounting in panfrost, fix a corrupted image with AFBC on meson, a memleak in virtio, improper plane width for imx, and a lockup in drm_sched_entity_kill() The following changes since commit 88603b6dc419445847923fcb7fe5080067a30f98: Linux 6.2-rc2 (2023-01-01 13:53:16 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2023-01-05 for you to fetch changes up to 6949cfa42e10f2fdd2699ed4e34d9d4f392b: drm/scheduler: Fix lockup in drm_sched_entity_kill() (2023-01-03 14:49:59 +0300) Several fixes to fix the error path of dma_buf_export, add a missing structure declaration resulting in a compiler warning, fix the GEM handle refcounting in panfrost, fix a corrupted image with AFBC on meson, a memleak in virtio, improper plane width for imx, and a lockup in drm_sched_entity_kill() Carlo Caione (1): drm/meson: Reduce the FIFO lines held when AFBC is not used Christian König (1): dma-buf: fix dma_buf_export init order v2 Dmitry Osipenko (1): drm/scheduler: Fix lockup in drm_sched_entity_kill() Ma Jun (1): drm/plane-helper: Add the missing declaration of drm_atomic_state Maxime Ripard (1): Merge drm/drm-fixes into drm-misc-fixes Philipp Zabel (1): drm/imx: ipuv3-plane: Fix overlay plane width Steven Price (1): drm/panfrost: Fix GEM handle creation ref-counting Xiu Jianfeng (1): drm/virtio: Fix memory leak in virtio_gpu_object_create() drivers/dma-buf/dma-buf-sysfs-stats.c| 7 +-- drivers/dma-buf/dma-buf-sysfs-stats.h| 4 +- drivers/dma-buf/dma-buf.c| 82 +++- drivers/gpu/drm/imx/ipuv3-plane.c| 14 +++--- drivers/gpu/drm/meson/meson_viu.c| 5 +- drivers/gpu/drm/panfrost/panfrost_drv.c | 27 +++ drivers/gpu/drm/panfrost/panfrost_gem.c | 16 +-- drivers/gpu/drm/panfrost/panfrost_gem.h | 5 +- drivers/gpu/drm/scheduler/sched_entity.c | 2 +- drivers/gpu/drm/scheduler/sched_main.c | 4 +- drivers/gpu/drm/virtio/virtgpu_object.c | 6 ++- include/drm/drm_plane_helper.h | 1 + 12 files changed, 80 insertions(+), 93 deletions(-) signature.asc Description: PGP signature
[Intel-gfx] [PATCH v3] drm/i915/psr: Implement Wa_14015648006
Add 4th pipe and extend TGL Wa_16013835468 to support ADLP, MTL and
DG2 and all TGL steppings.
BSpec: 54369, 55378, 66624
v3:
- commit message modified
v2:
- apply for PSR1 as well
- remove stepping information from comments
Cc: Matt Roper
Cc: José Roberto de Souza
Cc: Stanislav Lisovskiy
Signed-off-by: Mika Kahola
Signed-off-by: Jouni Högander
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_psr.c | 48 ++--
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files changed, 29 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index d0d774219cc5..507f810d4a4a 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1112,6 +1112,8 @@ static u32 wa_16013835468_bit_get(struct intel_dp
*intel_dp)
return LATENCY_REPORTING_REMOVED_PIPE_B;
case PIPE_C:
return LATENCY_REPORTING_REMOVED_PIPE_C;
+ case PIPE_D:
+ return LATENCY_REPORTING_REMOVED_PIPE_D;
default:
MISSING_CASE(intel_dp->psr.pipe);
return 0;
@@ -1163,6 +1165,23 @@ static void intel_psr_enable_source(struct intel_dp
*intel_dp,
intel_dp->psr.psr2_sel_fetch_enabled ?
IGNORE_PSR2_HW_TRACKING : 0);
+ /*
+* Wa_16013835468
+* Wa_14015648006
+*/
+ if (IS_MTL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0) ||
+ IS_DISPLAY_VER(dev_priv, 12, 13)) {
+ u16 vtotal, vblank;
+
+ vtotal = crtc_state->uapi.adjusted_mode.crtc_vtotal -
+ crtc_state->uapi.adjusted_mode.crtc_vdisplay;
+ vblank = crtc_state->uapi.adjusted_mode.crtc_vblank_end -
+ crtc_state->uapi.adjusted_mode.crtc_vblank_start;
+ if (vblank > vtotal)
+ intel_de_rmw(dev_priv, GEN8_CHICKEN_DCPR_1, 0,
+wa_16013835468_bit_get(intel_dp));
+ }
+
if (intel_dp->psr.psr2_enabled) {
if (DISPLAY_VER(dev_priv) == 9)
intel_de_rmw(dev_priv, CHICKEN_TRANS(cpu_transcoder), 0,
@@ -1196,20 +1215,6 @@ static void intel_psr_enable_source(struct intel_dp
*intel_dp,
else if (IS_ALDERLAKE_P(dev_priv))
intel_de_rmw(dev_priv, CLKGATE_DIS_MISC, 0,
CLKGATE_DIS_MISC_DMASC_GATING_DIS);
-
- /* Wa_16013835468:tgl[b0+], dg1 */
- if (IS_TGL_DISPLAY_STEP(dev_priv, STEP_B0, STEP_FOREVER) ||
- IS_DG1(dev_priv)) {
- u16 vtotal, vblank;
-
- vtotal = crtc_state->uapi.adjusted_mode.crtc_vtotal -
-crtc_state->uapi.adjusted_mode.crtc_vdisplay;
- vblank = crtc_state->uapi.adjusted_mode.crtc_vblank_end
-
-
crtc_state->uapi.adjusted_mode.crtc_vblank_start;
- if (vblank > vtotal)
- intel_de_rmw(dev_priv, GEN8_CHICKEN_DCPR_1, 0,
-wa_16013835468_bit_get(intel_dp));
- }
}
}
@@ -1362,6 +1367,15 @@ static void intel_psr_disable_locked(struct intel_dp
*intel_dp)
intel_de_rmw(dev_priv, CHICKEN_PAR1_1,
DIS_RAM_BYPASS_PSR2_MAN_TRACK, 0);
+ /*
+* Wa_16013835468
+* Wa_14015648006
+*/
+ if (IS_MTL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0) ||
+ IS_DISPLAY_VER(dev_priv, 12, 13))
+ intel_de_rmw(dev_priv, GEN8_CHICKEN_DCPR_1,
+wa_16013835468_bit_get(intel_dp), 0);
+
if (intel_dp->psr.psr2_enabled) {
/* Wa_16011168373:adl-p */
if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0))
@@ -1377,12 +1391,6 @@ static void intel_psr_disable_locked(struct intel_dp
*intel_dp)
else if (IS_ALDERLAKE_P(dev_priv))
intel_de_rmw(dev_priv, CLKGATE_DIS_MISC,
CLKGATE_DIS_MISC_DMASC_GATING_DIS, 0);
-
- /* Wa_16013835468:tgl[b0+], dg1 */
- if (IS_TGL_DISPLAY_STEP(dev_priv, STEP_B0, STEP_FOREVER) ||
- IS_DG1(dev_priv))
- intel_de_rmw(dev_priv, GEN8_CHICKEN_DCPR_1,
-wa_16013835468_bit_get(intel_dp), 0);
}
intel_snps_phy_update_psr_power_state(dev_priv, phy, false);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8b2cf980f323..b0b3b511e19f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5737,6 +5737,7 @@
#define RESET_PCH_HANDSHAKE_ENABLEREG_BIT(4)
#define GEN8_CHICKEN_DCPR_1
Re: [Intel-gfx] [PATCH 00/27] drm/i915/gvt: KVM: KVMGT fixes and page-track cleanups
On Wed, Jan 04, 2023 at 01:01:13AM +, Sean Christopherson wrote: > On Fri, Dec 23, 2022, Yan Zhao wrote: > > On Fri, Dec 23, 2022 at 12:57:12AM +, Sean Christopherson wrote: > > > Fix a variety of found-by-inspection bugs in KVMGT, and overhaul KVM's > > > page-track APIs to provide a leaner and cleaner interface. The motivation > > > for this series is to (significantly) reduce the number of KVM APIs that > > > KVMGT uses, with a long-term goal of making all kvm_host.h headers > > > KVM-internal. That said, I think the cleanup itself is worthwhile, > > > e.g. KVMGT really shouldn't be touching kvm->mmu_lock. > > > > > > Note! The KVMGT changes are compile tested only as I don't have the > > > necessary hardware (AFAIK). Testing, and lots of it, on the KVMGT side > > > of things is needed and any help on that front would be much appreciated. > > hi Sean, > > Thanks for the patch! > > Could you also provide the commit id that this series is based on? > > The commit ID is provided in the cover letter: > > base-commit: 9d75a3251adfbcf444681474511b58042a364863 > > Though you might have a hard time finding that commit as it's from an old > version of kvm/queue that's probably since been force pushed. > > > I applied them on top of latest master branch (6.1.0+, > > 8395ae05cb5a2e31d36106e8c85efa11cda849be) in repo > > https://github.com/torvalds/linux.git, yet met some conflicts and I > > fixed them manually. (patch 11 and patch 25). > > > > A rough test shows that below mutex_init is missing. > > But even with this fix, I still met guest hang during guest boots up. > > Will look into it and have a detailed review next week. > > Thanks again for the reviews and testing! I'll get a v2 out in the next week > or > so (catching up from holidays) and will be more explicit in documenting the > base > version. That's fine and it's a pleasure to me :)
Re: [Intel-gfx] [PATCH 26/27] KVM: x86/mmu: Add page-track API to query if a gfn is valid
On Tue, Jan 03, 2023 at 09:19:01PM +, Sean Christopherson wrote:
> On Wed, Dec 28, 2022, Yan Zhao wrote:
> > On Fri, Dec 23, 2022 at 12:57:38AM +, Sean Christopherson wrote:
> > > +bool kvm_page_track_is_valid_gfn(struct kvm *kvm, gfn_t gfn)
> > > +{
> > > + bool ret;
> > > + int idx;
> > > +
> > > + idx = srcu_read_lock(>srcu);
> > > + ret = kvm_is_visible_gfn(kvm, gfn);
> > > + srcu_read_unlock(>srcu, idx);
> > > +
> > > + return ret;
> > > +}
> > > +EXPORT_SYMBOL_GPL(kvm_page_track_is_valid_gfn);
> > This implementation is only to check whether a GFN is within a visible
> > kvm memslot. So, why this helper function is named kvm_page_track_xxx()?
> > Don't think it's anything related to page track, and not all of its callers
> > in KVMGT are for page tracking.
>
> KVMGT is the only user of kvm_page_track_is_valid_gfn(). kvm_is_visible_gfn()
> has other users, just not in x86. And long term, my goal is to allow building
> KVM x86 without any exports. Killing off KVM's "internal" (for vendor
> modules)
> exports for select Kconfigs is easy enough, add adding a dedicated page-track
> API
> solves the KVMGT angle.
Understand!
But personally, I don't like merging this API into page-track API as
it obviously has nothing to do with page-track stuffs, and KVMGT also calls it
for
non-page-track purpuse.
Re: [Intel-gfx] [PATCH 03/27] drm/i915/gvt: Incorporate KVM memslot info into check for 2MiB GTT entry
On Tue, Jan 03, 2023 at 09:13:54PM +, Sean Christopherson wrote:
> On Wed, Dec 28, 2022, Yan Zhao wrote:
> > On Fri, Dec 23, 2022 at 12:57:15AM +, Sean Christopherson wrote:
> > > Honor KVM's max allowed page size when determining whether or not a 2MiB
> > > GTT shadow page can be created for the guest. Querying KVM's max allowed
> > > size is somewhat odd as there's no strict requirement that KVM's memslots
> > > and VFIO's mappings are configured with the same gfn=>hva mapping, but
> > Without vIOMMU, VFIO's mapping is configured with the same as KVM's
> > memslots, i.e. with the same gfn==>HVA mapping
>
> But that's controlled by userspace, correct?
Yes, controlled by QEMU.
VFIO in kernel has no idea of whether vIOMMU is enabled or not.
KVMGT currently is known not working with vIOMMU with shadow mode on
(in this mode, VFIO maps gIOVA ==> HVA ==> HPA) .
>
> > > the check will be accurate if userspace wants to have a functional guest,
> > > and at the very least checking KVM's memslots guarantees that the entire
> > > 2MiB range has been exposed to the guest.
> >
> > I think just check the entrie 2MiB GFN range are all within KVM memslot is
> > enough.
>
> Strictly speaking, no. E.g. if a 2MiB region is covered with multiple
> memslots
> and the memslots have different properties.
>
> > If for some reason, KVM maps a 2MiB range in 4K sizes, KVMGT can still map
> > it in IOMMU size in 2MiB size as long as the PFNs are continous and the
> > whole range is all exposed to guest.
>
> I agree that practically speaking this will hold true, but if KVMGT wants to
> honor
> KVM's memslots then checking that KVM allows a hugepage is correct. Hrm, but
> on
> the flip side, KVMGT ignores read-only memslot flags, so KVMGT is already
> ignoring
> pieces of KVM's memslots.
KVMGT calls dma_map_page() with DMA_BIDIRECTIONAL after checking
gvt_pin_guest_page().
Though for a read-only memslot, DMA_TO_DEVICE should be used instead
(see dma_info_to_prot()),
as gvt_pin_guest_page() checks (IOMMU_READ | IOMMU_WRITE) permission for each
page,
it actually ensures that the pinned GFN is not in a read-only memslot.
So, it should be fine.
>
> I have no objection to KVMGT defining its ABI such that KVMGT is allowed to
> create
> 2MiB so long as (a) the GFN is contiguous according to VFIO, and (b) that the
> entire
> 2MiB range is exposed to the guest.
>
sorry. I may not put it clearly enough.
for a normal device pass-through via VFIO-PCI, VFIO maps IOMMU mappings in this
way:
(a) fault in PFNs in a GFN range within the same memslot (VFIO saves dma_list,
which is
the same as memslot list when vIOMMU is not on or not in shadow mode).
(b) map continuous PFNs into iommu driver (honour ro attribute and can > 2MiB
as long as
PFNs are continuous).
(c) IOMMU driver decides to map in 2MiB or in 4KiB according to its setting.
For KVMGT, gvt_dma_map_page() first calls gvt_pin_guest_page() which
(a) calls vfio_pin_pages() to check each GFN is within allowed dma_list with
(IOMMU_READ | IOMMU_WRITE) permission and fault-in page.
(b) checks PFNs are continuous in 2MiB,
Though checking kvm_page_track_max_mapping_level() is also fine, it makes DMA
mapping size unnecessarily smaller.
> That said, being fully permissive also seems wasteful, e.g. KVM would need to
> explicitly support straddling multiple memslots.
>
> As a middle ground, what about tweaking kvm_page_track_is_valid_gfn() to take
> a
> range, and then checking that the range is contained in a single memslot?
>
> E.g. something like:
>
> bool kvm_page_track_is_contiguous_gfn_range(struct kvm *kvm, gfn_t gfn,
> unsigned long nr_pages)
> {
> struct kvm_memory_slot *memslot;
> bool ret;
> int idx;
>
> idx = srcu_read_lock(>srcu);
> memslot = gfn_to_memslot(kvm, gfn);
> ret = kvm_is_visible_memslot(memslot) &&
> gfn + nr_pages <= memslot->base_gfn + memslot->npages;
> srcu_read_unlock(>srcu, idx);
>
> return ret;
> }
Yes, it's good.
But as explained above, gvt_dma_map_page() checks in an equivalent way.
Maybe checking kvm_page_track_is_contiguous_gfn_range() is also not
required?
>
> > Actually normal device passthrough with VFIO-PCI also maps GFNs in a
> > similar way, i.e. maps a guest visible range in as large size as
> > possible as long as the PFN is continous.
> > >
> > > Note, KVM may also restrict the mapping size for reasons that aren't
> > > relevant to KVMGT, e.g. for KVM's iTLB multi-hit workaround or if the gfn
> > Will iTLB multi-hit affect DMA?
>
> I highly doubt it, I can't imagine an IOMMU would have a dedicated instruction
> TLB :-)
I can double check it with IOMMU hardware experts.
But if DMA would tamper instruction TLB, it should have been reported
as an issue with normal VFIO pass-through?
> > AFAIK, IOMMU mappings currently never sets exec bit (and I'm told this bit
> > is
> > under discussion to be removed).
[Intel-gfx] linux-next: build warnings after merge of the drm-intel tree
Hi all,
After merging the drm-intel tree, today's linux-next build (htmldocs)
produced these warnings:
drivers/gpu/drm/i915/display/intel_dsb.c:201: warning: Excess function
parameter 'crtc_state' description in 'intel_dsb_reg_write'
drivers/gpu/drm/i915/display/intel_dsb.c:201: warning: Function parameter or
member 'dsb' not described in 'intel_dsb_reg_write'
Introduced by commit
b358c3b98813 ("drm/i915: Make DSB lower level")
--
Cheers,
Stephen Rothwell
pgp8PMBxu9SG9.pgp
Description: OpenPGP digital signature
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Expand force_probe to block probe of devices as well. (rev3)
== Series Details ==
Series: drm/i915: Expand force_probe to block probe of devices as well. (rev3)
URL : https://patchwork.freedesktop.org/series/112292/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12546_full -> Patchwork_112292v3_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112292v3/index.html
Participating hosts (13 -> 10)
--
Additional (1): shard-rkl0
Missing(4): pig-skl-6260u pig-kbl-iris shard-tglu-9 pig-glk-j5005
Known issues
Here are the changes found in Patchwork_112292v3_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk: [PASS][1] -> [FAIL][2] ([i915#2842])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-glk7/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112292v3/shard-glk2/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions:
- shard-glk: [PASS][3] -> [FAIL][4] ([i915#2346])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-glk6/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112292v3/shard-glk7/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html
* igt@kms_dither@fb-8bpc-vs-panel-6bpc@pipe-a-hdmi-a-1:
- shard-glk: NOTRUN -> [SKIP][5] ([fdo#109271])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112292v3/shard-glk9/igt@kms_dither@fb-8bpc-vs-panel-6...@pipe-a-hdmi-a-1.html
Possible fixes
* igt@drm_fdinfo@virtual-idle:
- {shard-rkl}:[FAIL][6] ([i915#7742]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-rkl-1/igt@drm_fdi...@virtual-idle.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112292v3/shard-rkl-6/igt@drm_fdi...@virtual-idle.html
* igt@gem_eio@suspend:
- {shard-rkl}:[FAIL][8] ([i915#7052]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-rkl-4/igt@gem_...@suspend.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112292v3/shard-rkl-2/igt@gem_...@suspend.html
* igt@gem_exec_fair@basic-pace@rcs0:
- {shard-rkl}:[FAIL][10] ([i915#2842]) -> [PASS][11] +2 similar
issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-rkl-3/igt@gem_exec_fair@basic-p...@rcs0.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112292v3/shard-rkl-5/igt@gem_exec_fair@basic-p...@rcs0.html
* igt@gem_exec_reloc@basic-cpu-gtt-noreloc:
- {shard-rkl}:[SKIP][12] ([i915#3281]) -> [PASS][13] +8 similar
issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-rkl-6/igt@gem_exec_re...@basic-cpu-gtt-noreloc.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112292v3/shard-rkl-5/igt@gem_exec_re...@basic-cpu-gtt-noreloc.html
* igt@gem_pwrite@basic-self:
- {shard-rkl}:[SKIP][14] ([i915#3282]) -> [PASS][15] +1 similar
issue
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-rkl-6/igt@gem_pwr...@basic-self.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112292v3/shard-rkl-5/igt@gem_pwr...@basic-self.html
* igt@gen9_exec_parse@allowed-single:
- {shard-rkl}:[SKIP][16] ([i915#2527]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-rkl-3/igt@gen9_exec_pa...@allowed-single.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112292v3/shard-rkl-5/igt@gen9_exec_pa...@allowed-single.html
* igt@i915_pm_rc6_residency@rc6-idle@rcs0:
- {shard-dg1}:[FAIL][18] ([i915#3591]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-dg1-16/igt@i915_pm_rc6_residency@rc6-i...@rcs0.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112292v3/shard-dg1-16/igt@i915_pm_rc6_residency@rc6-i...@rcs0.html
* igt@i915_selftest@live@gt_heartbeat:
- shard-glk: [DMESG-FAIL][20] ([i915#5334]) -> [PASS][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-glk5/igt@i915_selftest@live@gt_heartbeat.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112292v3/shard-glk6/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@gt_pm:
- {shard-rkl}:[DMESG-FAIL][22] ([i915#4258]) -> [PASS][23]
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-rkl-6/igt@i915_selftest@live@gt_pm.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112292v3/shard-rkl-6/igt@i915_selftest@live@gt_pm.html
* igt@kms_big_fb@y-tiled-64bpp-rotate-180:
- {shard-tglu}: [SKIP][24] ([i915#1845] /
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: assume some pixelrate for src smaller than 1
== Series Details ==
Series: drm/i915/display: assume some pixelrate for src smaller than 1
URL : https://patchwork.freedesktop.org/series/112396/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12546_full -> Patchwork_112396v1_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112396v1/index.html
Participating hosts (13 -> 9)
--
Missing(4): pig-skl-6260u pig-kbl-iris shard-tglu-9 pig-glk-j5005
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_112396v1_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_atomic_transition@plane-all-modeset-transition:
- {shard-rkl}:[SKIP][1] ([i915#1845] / [i915#4098]) -> [SKIP][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-rkl-3/igt@kms_atomic_transit...@plane-all-modeset-transition.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112396v1/shard-rkl-6/igt@kms_atomic_transit...@plane-all-modeset-transition.html
Known issues
Here are the changes found in Patchwork_112396v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk: [PASS][3] -> [FAIL][4] ([i915#2842])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-glk7/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112396v1/shard-glk8/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions:
- shard-glk: [PASS][5] -> [FAIL][6] ([i915#2346])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-glk6/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112396v1/shard-glk7/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html
* igt@kms_dither@fb-8bpc-vs-panel-6bpc@pipe-a-hdmi-a-1:
- shard-glk: NOTRUN -> [SKIP][7] ([fdo#109271])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112396v1/shard-glk6/igt@kms_dither@fb-8bpc-vs-panel-6...@pipe-a-hdmi-a-1.html
Possible fixes
* igt@drm_fdinfo@virtual-idle:
- {shard-rkl}:[FAIL][8] ([i915#7742]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-rkl-1/igt@drm_fdi...@virtual-idle.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112396v1/shard-rkl-5/igt@drm_fdi...@virtual-idle.html
* igt@gem_eio@suspend:
- {shard-rkl}:[FAIL][10] ([i915#7052]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-rkl-4/igt@gem_...@suspend.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112396v1/shard-rkl-2/igt@gem_...@suspend.html
* igt@gem_exec_fair@basic-none-rrul@rcs0:
- {shard-rkl}:[FAIL][12] ([i915#2842]) -> [PASS][13] +1 similar
issue
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-rkl-1/igt@gem_exec_fair@basic-none-r...@rcs0.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112396v1/shard-rkl-5/igt@gem_exec_fair@basic-none-r...@rcs0.html
* igt@gem_exec_fair@basic-none@rcs0:
- shard-glk: [FAIL][14] ([i915#2842]) -> [PASS][15] +1 similar
issue
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-glk2/igt@gem_exec_fair@basic-n...@rcs0.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112396v1/shard-glk5/igt@gem_exec_fair@basic-n...@rcs0.html
* igt@gem_exec_reloc@basic-gtt-wc-noreloc:
- {shard-rkl}:[SKIP][16] ([i915#3281]) -> [PASS][17] +8 similar
issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-rkl-1/igt@gem_exec_re...@basic-gtt-wc-noreloc.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112396v1/shard-rkl-5/igt@gem_exec_re...@basic-gtt-wc-noreloc.html
* igt@gem_mmap_gtt@coherency:
- {shard-rkl}:[SKIP][18] ([fdo#111656]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-rkl-1/igt@gem_mmap_...@coherency.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112396v1/shard-rkl-5/igt@gem_mmap_...@coherency.html
* igt@gem_partial_pwrite_pread@reads-display:
- {shard-rkl}:[SKIP][20] ([i915#3282]) -> [PASS][21] +2 similar
issues
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-rkl-1/igt@gem_partial_pwrite_pr...@reads-display.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112396v1/shard-rkl-5/igt@gem_partial_pwrite_pr...@reads-display.html
* igt@gen9_exec_parse@unaligned-access:
- {shard-rkl}:
Re: [Intel-gfx] [PATCH 09/27] drm/i915/gvt: Protect gfn hash table with dedicated mutex
On Tue, Jan 03, 2023 at 08:43:17PM +, Sean Christopherson wrote:
> On Wed, Dec 28, 2022, Yan Zhao wrote:
> > On Fri, Dec 23, 2022 at 12:57:21AM +, Sean Christopherson wrote:
> > > Add and use a new mutex, gfn_lock, to protect accesses to the hash table
> > > used to track which gfns are write-protected when shadowing the guest's
> > > GTT. This fixes a bug where kvmgt_page_track_write(), which doesn't hold
> > > kvm->mmu_lock, could race with intel_gvt_page_track_remove() and trigger
> > > a use-after-free.
> > >
> > > Fixing kvmgt_page_track_write() by taking kvm->mmu_lock is not an option
> > > as mmu_lock is a r/w spinlock, and intel_vgpu_page_track_handler() might
> > > sleep when acquiring vgpu->cache_lock deep down the callstack:
> > >
> > > intel_vgpu_page_track_handler()
> > > |
> > > |-> page_track->handler / ppgtt_write_protection_handler()
> > >|
> > >|-> ppgtt_handle_guest_write_page_table_bytes()
> > >|
> > >|-> ppgtt_handle_guest_write_page_table()
> > > |
> > > |-> ppgtt_handle_guest_entry_removal()
> > > |
> > > |-> ppgtt_invalidate_pte()
> > > |
> > > |-> intel_gvt_dma_unmap_guest_page()
> > > |
> > > |-> mutex_lock(>cache_lock);
> > >
> > This gfn_lock could lead to deadlock in below sequence.
> >
> > (1) kvm_write_track_add_gfn() to GFN 1
> > (2) kvmgt_page_track_write() for GFN 1
> > kvmgt_page_track_write()
> > |
> > |->mutex_lock(>vgpu_lock)
> > |->intel_vgpu_page_track_handler (as is kvmgt_gfn_is_write_protected)
> >|
> >|->page_track->handler() (ppgtt_write_protection_handler())
> > |
> > |->ppgtt_handle_guest_write_page_table_bytes()
> > |
> > |->ppgtt_handle_guest_write_page_table()
> > |
> > |->ppgtt_handle_guest_entry_add() --> new_present
> >|
> >|->ppgtt_populate_spt_by_guest_entry()
> > |
> > |->intel_vgpu_enable_page_track() --> for GFN 2
> > |
> > |->intel_gvt_page_track_add()
> > |
> > |->mutex_lock(>gfn_lock) ===>deadlock
>
> Or even more simply,
>
> kvmgt_page_track_write()
> |
> -> intel_vgpu_page_track_handler()
> |
> -> intel_gvt_page_track_remove()
>
yes.
> >
> > Below fix based on this patch is to reuse vgpu_lock to protect the hash
> > table
> > info->ptable.
> > Please check if it's good.
> >
> >
> > diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c
> > b/drivers/gpu/drm/i915/gvt/kvmgt.c
> > index b924ed079ad4..526bd973e784 100644
> > --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> > +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> > @@ -364,7 +364,7 @@ __kvmgt_protect_table_find(struct intel_vgpu *info,
> > gfn_t gfn)
> > {
> > struct kvmgt_pgfn *p, *res = NULL;
> >
> > - lockdep_assert_held(>gfn_lock);
> > + lockdep_assert_held(>vgpu_lock);
> >
> > hash_for_each_possible(info->ptable, p, hnode, gfn) {
> > if (gfn == p->gfn) {
> > @@ -388,7 +388,7 @@ static void kvmgt_protect_table_add(struct intel_vgpu
> > *info, gfn_t gfn)
> > {
> > struct kvmgt_pgfn *p;
> >
> > - lockdep_assert_held(>gfn_lock);
> > + lockdep_assert_held(>vgpu_lock);
>
> I'll just delete these assertions, the one in __kvmgt_protect_table_find()
> should
> cover everything and is ultimately the assert that matters.
>
> > @@ -1629,12 +1629,11 @@ static void kvmgt_page_track_remove_region(gfn_t
> > gfn, unsigned long nr_pages,
> > struct intel_vgpu *info =
> > container_of(node, struct intel_vgpu, track_node);
> >
> > - mutex_lock(>gfn_lock);
> > + lockdep_assert_held(>vgpu_lock);
>
> This path needs to manually take vgpu_lock as it's called from KVM. IIRC,
> this
> is the main reason I tried adding a new lock. That and I had a hell of a time
> figuring out whether or not vgpu_lock would actually be held.
Right. In the path of kvmgt_page_track_remove_region(),
mutex_lock(>vgpu_lock) and mutex_unlock(>vgpu_lock) are
required.
static void kvmgt_page_track_remove_region(gfn_t gfn, unsigned long nr_pages,
struct kvm_page_track_notifier_node
*node)
{
unsigned long i;
struct intel_vgpu *info =
container_of(node, struct intel_vgpu, track_node);
mutex_lock(>vgpu_lock);
for (i = 0; i < nr_pages; i++) {
if (kvmgt_gfn_is_write_protected(info, gfn + i))
kvmgt_protect_table_del(info, gfn + i);
}
mutex_unlock(>vgpu_lock);
}
The reason I previously could have lockdep_assert_held(>vgpu_lock) passed
is that I didn't get LOCKDEP configured, so it's basically a void.
(sorry, though I actually also called mutex_is_locked(>vcpu_lock)
[Intel-gfx] linux-next: duplicate patches in the drm tree
Hi all,
The following commits also exist in other trees in linux-next as different
commits (but the same patch):
9f1ecfc5dcb4 ("drm/scheduler: Fix lockup in drm_sched_entity_kill()")
4333472f8d7b ("drm/imx: ipuv3-plane: Fix overlay plane width")
They are also in the drm-misc-fixes tree.
--
Cheers,
Stephen Rothwell
pgp80tBgiJKnS.pgp
Description: OpenPGP digital signature
Re: [Intel-gfx] [PATCH 1/1] drm/i915: Implement workaround for CDCLK PLL disable/enable
> -Original Message-
> From: Lisovskiy, Stanislav
> Sent: Thursday, December 15, 2022 2:14 AM
> To: Srivatsa, Anusha
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> Subject: Re: [Intel-gfx] [PATCH 1/1] drm/i915: Implement workaround for
> CDCLK PLL disable/enable
>
> On Wed, Dec 14, 2022 at 09:15:07PM +0200, Srivatsa, Anusha wrote:
> >
> >
> > > -Original Message-
> > > From: Lisovskiy, Stanislav
> > > Sent: Wednesday, December 14, 2022 2:31 AM
> > > To: Srivatsa, Anusha
> > > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> > >
> > > Subject: Re: [Intel-gfx] [PATCH 1/1] drm/i915: Implement workaround
> > > for CDCLK PLL disable/enable
> > >
> > > On Tue, Nov 29, 2022 at 09:19:40PM +0200, Srivatsa, Anusha wrote:
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Intel-gfx On
> > > > > Behalf Of Stanislav Lisovskiy
> > > > > Sent: Thursday, November 24, 2022 2:36 AM
> > > > > To: intel-gfx@lists.freedesktop.org
> > > > > Cc: Nikula, Jani
> > > > > Subject: [Intel-gfx] [PATCH 1/1] drm/i915: Implement workaround
> > > > > for CDCLK PLL disable/enable
> > > > >
> > > > > It was reported that we might get a hung and loss of register
> > > > > access in some cases when CDCLK PLL is disabled and then
> > > > > enabled, while squashing is enabled.
> > > > > As a workaround it was proposed by HW team that SW should
> > > > > disable squashing when CDCLK PLL is being reenabled.
> > > > >
> > > > > Signed-off-by: Stanislav Lisovskiy
> > > > >
> > > > > ---
> > > > > drivers/gpu/drm/i915/display/intel_cdclk.c | 14 --
> > > > > 1 file changed, 12 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > > index 0c107a38f9d0..e338f288c9ac 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > > @@ -1801,6 +1801,13 @@ static bool
> > > > > cdclk_compute_crawl_and_squash_midpoint(struct
> drm_i915_private
> > > *i91
> > > > > return true;
> > > > > }
> > > > >
> > > > > +static bool pll_enable_wa_needed(struct drm_i915_private
> > > > > +*dev_priv)
> > > {
> > > > > + return ((IS_DG2(dev_priv) || IS_METEORLAKE(dev_priv))
> > > > > + && dev_priv->display.cdclk.hw.vco > 0
> > > > > + && HAS_CDCLK_SQUASH(dev_priv));
> > > > Redundant check. If it is MTL or DG2, then it will have
> > > HAS_CDCLK_SQUASH set to true always. Shouldn't vco be 0 instead of >
> 0.
> > > The commit message says the hang can be observed when moving from
> 0
> > > to
> > > > 0 vco.
> > > >
> > > > Anusha
> > >
> > > Idea was that we probably should bind more to the feature rather
> > > than platform, I agree checking both "IS_DG2" and if platform has
> > > squashing is redundant, because then we would have to add each new
> > > platform manually, so I would leave HAS_CDCLK_SQUASH and then at
> > > some point just cut off using some INTEL_GEN or other check all the
> > > new platforms where this is fixed in HW.
> > >
> > > Regarding vco, the icl_cdclk_pll_update func works as follows:
> > >
> > > if (i915->display.cdclk.hw.vco != 0 &&
> > > i915->display.cdclk.hw.vco != vco)
> > > icl_cdclk_pll_disable(i915);
> > >
> > > if (i915->display.cdclk.hw.vco != vco)
> > > icl_cdclk_pll_enable(i915, vco);
> > >
> > > 1) if vco changes from zero value(i915->display.cdclk.hw.vco) to
> > > non-zero value(vco), that means
> > >currently squashing is anyway disabled(if vco == 0, cdclk is set to
> "bypass"
> > > and squash waveform
> > >is 0), so the W/A is not needed.
> > >
> > > 2) if vco changes from non-zero value in i915->display.cdclk.hw.vco
> > > to zero value(vco), we are not
> > >going to call icl_cdclk_pll_enable anyway so W/A is also not needed.
> > >
> > > 3) if vco changes from some non-zero value in
> > > i915->display.cdclk.hw.vco to other non-zero value(vco),
> > >which can happen if CDCLK changes, then icl_cdclk_pll_disable(hw
> > > vco!=0 and vco!=0) and then
> > >icl_cdclk_pll_enable would be called(hw vco is still not equal to vco)
> > >So that disabling enabling in between is what we are interested
> > > and where we should make sure
> > >squashing is disabled.
> > >BTW I have another question - is this code even correct?
> > > Shouldn't we avoid disabling/enabling PLL if we have
> > >squashing/crawling? As I understood the whole point of having
> > > swuashing/crawling is avoiding swithing the PLL
> > >on and off.
> > >
> > Squashing works when we don't need to change the PLL ratio. We fix the
> PLL ratio to say 307 (this can change from platform to platform). Then
> squashing can be used to vary frequencies below this. So we set squasher
> to it will mean highest. We can use squasher to change frequency with
> squash waveform, max being and any value lower will take lower
> frequencies.
> >
Re: [Intel-gfx] [PULL] gvt-fixes
On 2023.01.04 06:34:28 -0500, Rodrigo Vivi wrote: > On Wed, Jan 04, 2023 at 04:05:13PM +0800, Zhenyu Wang wrote: > > > > Hi, > > > > Here's accumulated current gvt-fixes. Several of them handle > > for error or destroy path issues and one from Zhi to fix up > > left vgpu status tracking. > > > > thanks! > > --- > > The following changes since commit 6217e9f05a74df48c77ee68993d587cdfdb1feb7: > > I'm kind of confused on your baseline here. > > It is including a strange merge commit in the middle of the commits: > Zhenyu Wang ??? M?? Merge tag 'drm-intel-fixes-2022-12-30' into > gvt-fixes > commit c063c8c07864246ba3831b017cea8d3096e236a8 > > Please rebase on top of v6.2-rc2 so we have the same base here. > (and please remind to sign-off-by when pushing the commits) > oh, I tried to sycn up by back merge with vfio iommufd of gvt changes to apply Zhi's patch properly, so it should stand on that tag..but anyway I just refresh with rebase and fixed two invalid r-b tags. Please pull below one. thanks! --- The following changes since commit 88603b6dc419445847923fcb7fe5080067a30f98: Linux 6.2-rc2 (2023-01-01 13:53:16 -0800) are available in the Git repository at: https://github.com/intel/gvt-linux.git tags/gvt-fixes-2023-01-05 for you to fetch changes up to 4a61648af68f5ba4884f0e3b494ee1cabc4b6620: drm/i915/gvt: fix double free bug in split_2MB_gtt_entry (2023-01-04 23:21:19 +0800) gvt-fixes-2023-01-05 - Fix one missed unpin in error of intel_vgpu_shadow_mm_pin() - Fix two debugfs destroy oops issues for vgpu and gvt entries - Fix one potential double free issue in gtt shadow pt code - Fix to use atomic bit flag for vgpu status Dan Carpenter (1): drm/i915: unpin on error in intel_vgpu_shadow_mm_pin() Zheng Wang (1): drm/i915/gvt: fix double free bug in split_2MB_gtt_entry Zhenyu Wang (2): drm/i915/gvt: fix gvt debugfs destroy drm/i915/gvt: fix vgpu debugfs clean in remove Zhi Wang (1): drm/i915/gvt: use atomic operations to change the vGPU status drivers/gpu/drm/i915/gvt/debugfs.c | 36 +++- drivers/gpu/drm/i915/gvt/dmabuf.c| 3 ++- drivers/gpu/drm/i915/gvt/gtt.c | 21 +++-- drivers/gpu/drm/i915/gvt/gvt.h | 15 ++- drivers/gpu/drm/i915/gvt/interrupt.c | 2 +- drivers/gpu/drm/i915/gvt/kvmgt.c | 35 +-- drivers/gpu/drm/i915/gvt/scheduler.c | 4 +++- drivers/gpu/drm/i915/gvt/vgpu.c | 12 +--- 8 files changed, 80 insertions(+), 48 deletions(-) signature.asc Description: PGP signature
Re: [Intel-gfx] [PATCH v3 5/7] drm/i915/pxp: Trigger the global teardown for before suspending
On Wed, 2022-12-21 at 15:06 -0800, Alan Previn wrote:
> A driver bug was recently discovered where the security firmware was
> receiving internal HW signals indicating that session key expirations
> had occurred. Architecturally, the firmware was expecting a response
> from the GuC to acknowledge the event with the firmware side.
> However the OS was in a suspended state and GuC had been reset.
>
> Internal specifications actually required the driver to ensure
> that all active sessions be properly cleaned up in such cases where
> the system is suspended and the GuC potentially unable to respond.
>
> This patch adds the global teardown code in i915's suspend_prepare
> code path.
>
> Signed-off-by: Alan Previn
> ---
> drivers/gpu/drm/i915/pxp/intel_pxp.c | 60 +-
> --
> drivers/gpu/drm/i915/pxp/intel_pxp.h | 1 +
> drivers/gpu/drm/i915/pxp/intel_pxp_pm.c | 2 +-
> drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 9 ++-
> drivers/gpu/drm/i915/pxp/intel_pxp_session.h | 5 ++
> 5 files changed, 64 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> index cfc9af8b3d21..96a988efd237 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> @@ -270,6 +270,55 @@ static bool pxp_component_bound(struct intel_pxp
> *pxp)
> return bound;
> }
>
> +static int __pxp_global_teardown_locked(struct intel_pxp *pxp, bool
> terminate_for_cleanup)
> +{
> + if (terminate_for_cleanup) {
> + if (!pxp->arb_is_valid)
> + return 0;
> + /*
> + * To ensure synchronous and coherent session
> teardown completion
> + * in response to suspend or shutdown triggers, don't
> user a worker.
nit: typo user -> use
Reviewed-by: Juston Li
> + */
> + intel_pxp_mark_termination_in_progress(pxp);
> + intel_pxp_terminate(pxp, false);
> + } else {
> + if (pxp->arb_is_valid)
> + return 0;
> + /*
> + * If we are not in final termination, and the arb-
> session is currently
> + * inactive, we are doing a reset and restart due to
> some runtime event.
> + * Use the worker that was designed for this.
> + */
> + pxp_queue_termination(pxp);
> + }
> +
> + if (!wait_for_completion_timeout(>termination,
> msecs_to_jiffies(250)))
> + return -ETIMEDOUT;
> +
> + return 0;
> +}
> +
> +void intel_pxp_end(struct intel_pxp *pxp)
> +{
> + struct drm_i915_private *i915 = pxp->ctrl_gt->i915;
> + intel_wakeref_t wakeref;
> +
> + if (!intel_pxp_is_enabled(pxp))
> + return;
> +
> + wakeref = intel_runtime_pm_get(>runtime_pm);
> +
> + mutex_lock(>arb_mutex);
> +
> + if (__pxp_global_teardown_locked(pxp, true))
> + drm_dbg(>drm, "PXP end timed out\n");
> +
> + mutex_unlock(>arb_mutex);
> +
> + intel_pxp_fini_hw(pxp);
> + intel_runtime_pm_put(>runtime_pm, wakeref);
> +}
> +
> /*
> * the arb session is restarted from the irq work when we receive
> the
> * termination completion interrupt
> @@ -286,16 +335,9 @@ int intel_pxp_start(struct intel_pxp *pxp)
>
> mutex_lock(>arb_mutex);
>
> - if (pxp->arb_is_valid)
> - goto unlock;
> -
> - pxp_queue_termination(pxp);
> -
> - if (!wait_for_completion_timeout(>termination,
> - msecs_to_jiffies(250))) {
> - ret = -ETIMEDOUT;
> + ret = __pxp_global_teardown_locked(pxp, false);
> + if (ret)
> goto unlock;
> - }
>
> /* make sure the compiler doesn't optimize the double access
> */
> barrier();
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
> b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> index 9658d3005222..3ded0890cd27 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> @@ -27,6 +27,7 @@ void intel_pxp_mark_termination_in_progress(struct
> intel_pxp *pxp);
> void intel_pxp_tee_end_arb_fw_session(struct intel_pxp *pxp, u32
> arb_session_id);
>
> int intel_pxp_start(struct intel_pxp *pxp);
> +void intel_pxp_end(struct intel_pxp *pxp);
>
> int intel_pxp_key_check(struct intel_pxp *pxp,
> struct drm_i915_gem_object *obj,
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> index 892d39cc61c1..e427464aa131 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> @@ -16,7 +16,7 @@ void intel_pxp_suspend_prepare(struct intel_pxp
> *pxp)
> if (!intel_pxp_is_enabled(pxp))
> return;
>
> - pxp->arb_is_valid = false;
> + intel_pxp_end(pxp);
>
>
Re: [Intel-gfx] [PATCH v3 4/7] drm/i915/pxp: Invalidate all PXP fw sessions during teardown
On Wed, 2022-12-21 at 15:06 -0800, Alan Previn wrote:
> A gap was recently discovered where if an application did not
> invalidate all of the stream keys (intentionally or not), and the
> driver did a full PXP global teardown on the GT subsystem, we
> find that future session creation would fail on the security
> firmware's side of the equation. i915 is the entity that needs
> ensure the sessions' state across both iGT and security firmware
> are at a known clean point when performing a full global teardown.
>
> Architecturally speaking, i915 should inspect all active sessions
> and submit the invalidate-stream-key PXP command to the security
> firmware for each of them. However, for the upstream i915 driver
> we only support the arbitration session that can be created
> so that will be the only session we will cleanup.
>
> Signed-off-by: Alan Previn
Reviewed-by: Juston Li
> ---
> drivers/gpu/drm/i915/pxp/intel_pxp.h | 1 +
> .../drm/i915/pxp/intel_pxp_cmd_interface_42.h | 15
> .../i915/pxp/intel_pxp_cmd_interface_cmn.h | 3 ++
> drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 2 ++
> drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 35
> +++
> 5 files changed, 56 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
> b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> index 04440fada711..9658d3005222 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> @@ -24,6 +24,7 @@ void intel_pxp_init_hw(struct intel_pxp *pxp);
> void intel_pxp_fini_hw(struct intel_pxp *pxp);
>
> void intel_pxp_mark_termination_in_progress(struct intel_pxp *pxp);
> +void intel_pxp_tee_end_arb_fw_session(struct intel_pxp *pxp, u32
> arb_session_id);
>
> int intel_pxp_start(struct intel_pxp *pxp);
>
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_42.h
> b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_42.h
> index 739f9072fa5f..26f7d9f01bf3 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_42.h
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_42.h
> @@ -12,6 +12,9 @@
> /* PXP-Opcode for Init Session */
> #define PXP42_CMDID_INIT_SESSION 0x1e
>
> +/* PXP-Opcode for Invalidate Stream Key */
> +#define PXP42_CMDID_INVALIDATE_STREAM_KEY 0x0007
> +
> /* PXP-Input-Packet: Init Session (Arb-Session) */
> struct pxp42_create_arb_in {
> struct pxp_cmd_header header;
> @@ -25,4 +28,16 @@ struct pxp42_create_arb_out {
> struct pxp_cmd_header header;
> } __packed;
>
> +/* PXP-Input-Packet: Invalidate Stream Key */
> +struct pxp42_inv_stream_key_in {
> + struct pxp_cmd_header header;
> + u32 rsvd[3];
> +} __packed;
> +
> +/* PXP-Output-Packet: Invalidate Stream Key */
> +struct pxp42_inv_stream_key_out {
> + struct pxp_cmd_header header;
> + u32 rsvd;
> +} __packed;
> +
> #endif /* __INTEL_PXP_FW_INTERFACE_42_H__ */
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
> b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
> index c2f23394f9b8..69e34ec49e78 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
> @@ -27,6 +27,9 @@ struct pxp_cmd_header {
> union {
> u32 status; /* out */
> u32 stream_id; /* in */
> +#define PXP_CMDHDR_EXTDATA_SESSION_VALID GENMASK(0, 0)
> +#define PXP_CMDHDR_EXTDATA_APP_TYPE GENMASK(1, 1)
> +#define PXP_CMDHDR_EXTDATA_SESSION_ID GENMASK(17, 2)
> };
> /* Length of the message (excluding the header) */
> u32 buffer_len;
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
> index ae413580b81a..74ed7e16e481 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
> @@ -110,6 +110,8 @@ static int
> pxp_terminate_arb_session_and_global(struct intel_pxp *pxp)
>
> intel_uncore_write(gt->uncore, PXP_GLOBAL_TERMINATE, 1);
>
> + intel_pxp_tee_end_arb_fw_session(pxp, ARB_SESSION);
> +
> return ret;
> }
>
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> index bef6d7f8ac55..9e247f38f3bd 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> @@ -311,3 +311,38 @@ int intel_pxp_tee_cmd_create_arb_session(struct
> intel_pxp *pxp,
>
> return ret;
> }
> +
> +void intel_pxp_tee_end_arb_fw_session(struct intel_pxp *pxp, u32
> session_id)
> +{
> + struct drm_i915_private *i915 = pxp->ctrl_gt->i915;
> + struct pxp42_inv_stream_key_in msg_in = {0};
> + struct pxp42_inv_stream_key_out msg_out = {0};
> + int ret, trials = 0;
> +
> +try_again:
> + memset(_in, 0, sizeof(msg_in));
> + memset(_out, 0, sizeof(msg_out));
> + msg_in.header.api_version = PXP_APIVER(4, 2);
> +
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Consolidate TLB invalidation flow
On 04.01.2023 18:41, Matt Roper wrote:
On Wed, Jan 04, 2023 at 10:08:29AM +, Tvrtko Ursulin wrote:
On 03/01/2023 19:57, Matt Roper wrote:
On Mon, Dec 19, 2022 at 05:10:02PM +0100, Andrzej Hajda wrote:
On 19.12.2022 11:13, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
As the logic for selecting the register and corresponsing values grew, the
corresponding
code become a bit unsightly. Consolidate by storing the required values at
engine init time in the engine itself, and by doing so minimise the amount
of invariant platform and engine checks during each and every TLB
invalidation.
v2:
* Fail engine probe if TLB invlidations registers are unknown.
Signed-off-by: Tvrtko Ursulin
Cc: Andrzej Hajda
Cc: Matt Roper
Reviewed-by: Andrzej Hajda # v1
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 93 +
drivers/gpu/drm/i915/gt/intel_engine_types.h | 15 +++
drivers/gpu/drm/i915/gt/intel_gt.c | 135 +++
3 files changed, 128 insertions(+), 115 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 99c4b866addd..d47dadfc25c8 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1143,12 +1143,105 @@ static int init_status_page(struct intel_engine_cs
*engine)
return ret;
}
+static int intel_engine_init_tlb_invalidation(struct intel_engine_cs *engine)
+{
+ static const union intel_engine_tlb_inv_reg gen8_regs[] = {
+ [RENDER_CLASS].reg = GEN8_RTCR,
+ [VIDEO_DECODE_CLASS].reg= GEN8_M1TCR, /* , GEN8_M2TCR */
+ [VIDEO_ENHANCEMENT_CLASS].reg = GEN8_VTCR,
+ [COPY_ENGINE_CLASS].reg = GEN8_BTCR,
+ };
+ static const union intel_engine_tlb_inv_reg gen12_regs[] = {
+ [RENDER_CLASS].reg = GEN12_GFX_TLB_INV_CR,
+ [VIDEO_DECODE_CLASS].reg= GEN12_VD_TLB_INV_CR,
+ [VIDEO_ENHANCEMENT_CLASS].reg = GEN12_VE_TLB_INV_CR,
+ [COPY_ENGINE_CLASS].reg = GEN12_BLT_TLB_INV_CR,
+ [COMPUTE_CLASS].reg = GEN12_COMPCTX_TLB_INV_CR,
+ };
+ static const union intel_engine_tlb_inv_reg xehp_regs[] = {
+ [RENDER_CLASS].mcr_reg= XEHP_GFX_TLB_INV_CR,
+ [VIDEO_DECODE_CLASS].mcr_reg = XEHP_VD_TLB_INV_CR,
+ [VIDEO_ENHANCEMENT_CLASS].mcr_reg = XEHP_VE_TLB_INV_CR,
+ [COPY_ENGINE_CLASS].mcr_reg = XEHP_BLT_TLB_INV_CR,
+ [COMPUTE_CLASS].mcr_reg = XEHP_COMPCTX_TLB_INV_CR,
+ };
+ struct drm_i915_private *i915 = engine->i915;
+ const union intel_engine_tlb_inv_reg *regs;
+ union intel_engine_tlb_inv_reg reg;
+ unsigned int class = engine->class;
+ unsigned int num = 0;
+ u32 val;
+
+ /*
+* New platforms should not be added with catch-all-newer (>=)
+* condition so that any later platform added triggers the below warning
+* and in turn mandates a human cross-check of whether the invalidation
+* flows have compatible semantics.
+*
+* For instance with the 11.00 -> 12.00 transition three out of five
+* respective engine registers were moved to masked type. Then after the
+* 12.00 -> 12.50 transition multi cast handling is required too.
+*/
+
+ if (GRAPHICS_VER_FULL(i915) == IP_VER(12, 50)) {
This is bad...it only captures XEHPSDV and breaks the handling of DG2
(12.55), PVC (12.60), and MTL (12.70, 12.71, and 12.72). You're not
hitting the warning as expected since those are all now being captured
by the next case of the if/else ladder. With the way GMD_ID works, we
may also get new version numbers that silently show up in hardware too
at some point (e.g., 12.73, 12.74, etc.)
Great (on multiple counts) ...
+ regs = xehp_regs;
+ num = ARRAY_SIZE(xehp_regs);
+ } else if (GRAPHICS_VER(i915) == 12) {
You'd want to change this to
GRAPHICS_VER_FULL(i915) == IP_VER(12, 0)
to get the behavior you expected.
Okay, that, and then to be as safe as I intended, ie. warn on every new
platforms so developers *must* check registers are still compatible during
platform enablement, we would need a full ver range check something like:
if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50) &&
GRAPHICS_VER_FULL(i915) <= IP_VER(12, 55)) {
regs = xehp_regs;
num = ARRAY_SIZE(xehp_regs);
} else if (GRAPHICS_VER_FULL(i915) == IP_VER(12, 0)) {
regs = gen12_regs;
num = ARRAY_SIZE(gen12_regs);
What do you think about that?
What about just keeping the code the way it is now, but adding a new
error condition at the *top* of the ladder?
if (GRAPHICS_VER_FULL(i915) > IP_VER(12, 72)) {
[Intel-gfx] linux-next: duplicate patches in the drm-intel tree
Hi all,
The following commits already exist in Linus Torvald's tree as different
commits (but the same patches):
50490ce05b7a ("drm/i915: Remove __maybe_unused from mtl_info")
f087cfe6fcff ("drm/i915/dsi: add support for ICL+ native MIPI GPIO sequence")
a561933c5717 ("drm/i915/dsi: fix MIPI_BKLT_EN_1 native GPIO index")
--
Cheers,
Stephen Rothwell
pgpfeHjYXNdZF.pgp
Description: OpenPGP digital signature
Re: [Intel-gfx] [PATCH v2] drm/i915/display: Implement Wa_14015648006
On Wed, Jan 04, 2023 at 11:02:29AM +0200, Jouni Högander wrote:
> Add 4th pipe and extend TGL Wa_16013835468 to support ADLP, MTL and
> DG2 and all TGL steppings.
>
> BSpec: 54369, 55378, 66624
>
> v2:
> - apply for PSR1 as well
> - remove stepping information from comments
>
> Cc: Matt Roper
> Cc: José Roberto de Souza
> Cc: Stanislav Lisovskiy
>
> Signed-off-by: Mika Kahola
> Signed-off-by: Jouni Högander
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_psr.c | 48 ++--
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> 2 files changed, 29 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index d0d774219cc5..507f810d4a4a 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1112,6 +1112,8 @@ static u32 wa_16013835468_bit_get(struct intel_dp
> *intel_dp)
> return LATENCY_REPORTING_REMOVED_PIPE_B;
> case PIPE_C:
> return LATENCY_REPORTING_REMOVED_PIPE_C;
> + case PIPE_D:
> + return LATENCY_REPORTING_REMOVED_PIPE_D;
> default:
> MISSING_CASE(intel_dp->psr.pipe);
> return 0;
> @@ -1163,6 +1165,23 @@ static void intel_psr_enable_source(struct intel_dp
> *intel_dp,
>intel_dp->psr.psr2_sel_fetch_enabled ?
>IGNORE_PSR2_HW_TRACKING : 0);
>
> + /*
> + * Wa_16013835468
> + * Wa_14015648006
> + */
> + if (IS_MTL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0) ||
> + IS_DISPLAY_VER(dev_priv, 12, 13)) {
> + u16 vtotal, vblank;
> +
> + vtotal = crtc_state->uapi.adjusted_mode.crtc_vtotal -
> + crtc_state->uapi.adjusted_mode.crtc_vdisplay;
> + vblank = crtc_state->uapi.adjusted_mode.crtc_vblank_end -
> + crtc_state->uapi.adjusted_mode.crtc_vblank_start;
> + if (vblank > vtotal)
> + intel_de_rmw(dev_priv, GEN8_CHICKEN_DCPR_1, 0,
> + wa_16013835468_bit_get(intel_dp));
> + }
> +
> if (intel_dp->psr.psr2_enabled) {
> if (DISPLAY_VER(dev_priv) == 9)
> intel_de_rmw(dev_priv, CHICKEN_TRANS(cpu_transcoder), 0,
> @@ -1196,20 +1215,6 @@ static void intel_psr_enable_source(struct intel_dp
> *intel_dp,
> else if (IS_ALDERLAKE_P(dev_priv))
> intel_de_rmw(dev_priv, CLKGATE_DIS_MISC, 0,
>CLKGATE_DIS_MISC_DMASC_GATING_DIS);
> -
> - /* Wa_16013835468:tgl[b0+], dg1 */
> - if (IS_TGL_DISPLAY_STEP(dev_priv, STEP_B0, STEP_FOREVER) ||
> - IS_DG1(dev_priv)) {
> - u16 vtotal, vblank;
> -
> - vtotal = crtc_state->uapi.adjusted_mode.crtc_vtotal -
> - crtc_state->uapi.adjusted_mode.crtc_vdisplay;
> - vblank = crtc_state->uapi.adjusted_mode.crtc_vblank_end
> -
> -
> crtc_state->uapi.adjusted_mode.crtc_vblank_start;
> - if (vblank > vtotal)
> - intel_de_rmw(dev_priv, GEN8_CHICKEN_DCPR_1, 0,
> - wa_16013835468_bit_get(intel_dp));
> - }
> }
> }
>
> @@ -1362,6 +1367,15 @@ static void intel_psr_disable_locked(struct intel_dp
> *intel_dp)
> intel_de_rmw(dev_priv, CHICKEN_PAR1_1,
>DIS_RAM_BYPASS_PSR2_MAN_TRACK, 0);
>
> + /*
> + * Wa_16013835468
> + * Wa_14015648006
> + */
> + if (IS_MTL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0) ||
> + IS_DISPLAY_VER(dev_priv, 12, 13))
> + intel_de_rmw(dev_priv, GEN8_CHICKEN_DCPR_1,
> + wa_16013835468_bit_get(intel_dp), 0);
> +
> if (intel_dp->psr.psr2_enabled) {
> /* Wa_16011168373:adl-p */
> if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0))
> @@ -1377,12 +1391,6 @@ static void intel_psr_disable_locked(struct intel_dp
> *intel_dp)
> else if (IS_ALDERLAKE_P(dev_priv))
> intel_de_rmw(dev_priv, CLKGATE_DIS_MISC,
>CLKGATE_DIS_MISC_DMASC_GATING_DIS, 0);
> -
> - /* Wa_16013835468:tgl[b0+], dg1 */
> - if (IS_TGL_DISPLAY_STEP(dev_priv, STEP_B0, STEP_FOREVER) ||
> - IS_DG1(dev_priv))
> - intel_de_rmw(dev_priv, GEN8_CHICKEN_DCPR_1,
> - wa_16013835468_bit_get(intel_dp), 0);
> }
>
> intel_snps_phy_update_psr_power_state(dev_priv, phy, false);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 8b2cf980f323..b0b3b511e19f 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Expand force_probe to block probe of devices as well. (rev3)
== Series Details ==
Series: drm/i915: Expand force_probe to block probe of devices as well. (rev3)
URL : https://patchwork.freedesktop.org/series/112292/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12546 -> Patchwork_112292v3
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112292v3/index.html
Participating hosts (43 -> 41)
--
Missing(2): bat-atsm-1 fi-snb-2520m
Known issues
Here are the changes found in Patchwork_112292v3 that come from known issues:
### IGT changes ###
Possible fixes
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-adlp-6}: [DMESG-WARN][1] ([i915#2867]) -> [PASS][2] +2 similar
issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/bat-adlp-6/igt@gem_exec_suspend@basic...@smem.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112292v3/bat-adlp-6/igt@gem_exec_suspend@basic...@smem.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
[i915#7336]: https://gitlab.freedesktop.org/drm/intel/issues/7336
Build changes
-
* Linux: CI_DRM_12546 -> Patchwork_112292v3
CI-20190529: 20190529
CI_DRM_12546: 07a684fbd4d0f5e284e8a782e0298f772fc4164e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7107: 4f22b49ee353406c14ce8bb3151ebe3ce4e6e9be @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_112292v3: 07a684fbd4d0f5e284e8a782e0298f772fc4164e @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
7c84d6caf781 drm/i915: Expand force_probe to block probe of devices as well.
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112292v3/index.html
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: assume some pixelrate for src smaller than 1
== Series Details ==
Series: drm/i915/display: assume some pixelrate for src smaller than 1
URL : https://patchwork.freedesktop.org/series/112396/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12546 -> Patchwork_112396v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112396v1/index.html
Participating hosts (43 -> 42)
--
Additional (1): fi-kbl-soraka
Missing(2): fi-bsw-kefka fi-snb-2520m
Known issues
Here are the changes found in Patchwork_112396v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_gttfill@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271]) +7 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112396v1/fi-kbl-soraka/igt@gem_exec_gttf...@basic.html
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#2190])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112396v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613]) +3
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112396v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][4] ([i915#1886])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112396v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@guc_hang:
- fi-kbl-soraka: NOTRUN -> [INCOMPLETE][5] ([i915#7640])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112396v1/fi-kbl-soraka/igt@i915_selftest@live@guc_hang.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-soraka: NOTRUN -> [SKIP][6] ([fdo#109271] / [fdo#111827]) +7
similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112396v1/fi-kbl-soraka/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-n3050: [PASS][7] -> [FAIL][8] ([i915#6298]) +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112396v1/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
Possible fixes
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-adlp-6}: [DMESG-WARN][9] ([i915#2867]) -> [PASS][10] +2
similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/bat-adlp-6/igt@gem_exec_suspend@basic...@smem.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112396v1/bat-adlp-6/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@reset:
- {bat-rpls-1}: [DMESG-FAIL][11] ([i915#4983]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/bat-rpls-1/igt@i915_selftest@l...@reset.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112396v1/bat-rpls-1/igt@i915_selftest@l...@reset.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#7336]: https://gitlab.freedesktop.org/drm/intel/issues/7336
[i915#7359]: https://gitlab.freedesktop.org/drm/intel/issues/7359
[i915#7640]: https://gitlab.freedesktop.org/drm/intel/issues/7640
Build changes
-
* Linux: CI_DRM_12546 -> Patchwork_112396v1
CI-20190529: 20190529
CI_DRM_12546: 07a684fbd4d0f5e284e8a782e0298f772fc4164e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7107: 4f22b49ee353406c14ce8bb3151ebe3ce4e6e9be @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_112396v1: 07a684fbd4d0f5e284e8a782e0298f772fc4164e @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
afe40f0c6249 drm/i915/display: assume some pixelrate for src smaller than 1
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112396v1/index.html
Re: [Intel-gfx] [PATCH 1/4] drm/i915/gt: Remove platform comments from workarounds
On Wed, Jan 04, 2023 at 09:58:13AM +, Tvrtko Ursulin wrote:
>
> On 23/12/2022 18:28, Lucas De Marchi wrote:
> > On Fri, Dec 23, 2022 at 09:02:35AM +, Tvrtko Ursulin wrote:
> > >
> > > On 22/12/2022 15:55, Lucas De Marchi wrote:
> > > > On Thu, Dec 22, 2022 at 10:27:00AM +, Tvrtko Ursulin wrote:
> > > > >
> > > > > On 22/12/2022 08:25, Lucas De Marchi wrote:
> > > > > > The comments are redundant to the checks being done to apply the
> > > > > > workarounds and very often get outdated as workarounds need to be
> > > > > > extended to new platforms or steppings. Remove them altogether with
> > > > > > the following matches (platforms extracted from
> > > > > > intel_workarounds.c):
> > > > > >
> > > > > > find drivers/gpu/drm/i915/gt/ -name '*.c' | xargs sed -i -E \
> > > > > > 's/(Wa.*):(bdw|chv|bxt|glk|skl|kbl|cfl|cfl|whl|cml|aml|chv|cl|bw|ctg|elk|ilk|snb|dg|pvc|g4x|ilk|gen|glk|kbl|cml|glk|kbl|cml|hsw|icl|ehl|ivb|hsw|ivb|vlv|kbl|pvc|rkl|dg|adl|skl|skl|bxt|blk|cfl|cnl|glk|snb|tgl|vlv|xehpsdv).*/\1/'
> > > > > > find drivers/gpu/drm/i915/gt/ -name '*.c' | xargs sed -i -E \
> > > > > > 's/(Wa.*):(bdw|chv|bxt|glk|skl|kbl|cfl|cfl|whl|cml|aml|chv|cl|bw|ctg|elk|ilk|snb|dg|pvc|g4x|ilk|gen|glk|kbl|cml|glk|kbl|cml|hsw|icl|ehl|ivb|hsw|ivb|vlv|kbl|pvc|rkl|dg|adl|skl|skl|bxt|blk|cfl|cnl|glk|snb|tgl|vlv|xehpsdv).*\*\//\1
> > > > > >
> > > > > > Same things was executed in the gem directory, omitted
> > > > > > here for brevity.
> > > > >
> > > > > > There were a few false positives that included the workaround
> > > > > > description. Those were manually patched.
> > > > >
> > > > > sed -E 's/(Wa[a-zA-Z0-9_]+)[:,]([a-zA-Z0-9,-_\+\[]{2,})/\1/'
> > > >
> > > > then there are false negatives. We have Was in the form
> > > > "Wa_xxx:tgl,dg2, mtl". False positives we can fixup, false negatives
> > > > we simply don't see. After running that in gt/:
> > > >
> > > > $ git grep ": mtl" -- drivers/gpu/drm/i915/
> > > > drivers/gpu/drm/i915/gt/intel_gt_pm.c: /* Wa_14017073508: mtl */
> > > > drivers/gpu/drm/i915/gt/intel_gt_pm.c: /* Wa_14017073508: mtl */
> > > > drivers/gpu/drm/i915/gt/intel_gt_pm.c: /* Wa_14017073508: mtl */
> > > > drivers/gpu/drm/i915/gt/intel_gt_pm.c: /* Wa_14017073508: mtl */
> > > > drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c: * Wa_14017073508: mtl
> > > > drivers/gpu/drm/i915/i915_reg.h:/* Wa_14017210380: mtl */
> > > >
> > > > I was going with the platform names to avoid the false
> > > > negatives and because I was entertaining the idea of only doing this for
> > > > latest platforms where we do have the "Wa_[[:number:]]" form
> > > >
> > > > >
> > > > > Maybe..
> > > > >
> > > > > Matt recently said he has this worked planned, but more
> > > > > importantly - I gather then that the WA lookup tool
> > > > > definitely does not output these strings?
> > > >
> > > > Whatever it does it's true only at the time it's called. It
> > > > simply tells what
> > > > are the platforms and steppings the Wa applies to. We can change the
> > > > output to whatever we want, but that is not the point.
> > > > Those comments get stale and bring no real value as they match 1:1
> > > > what the code is supposed to be doing. Several times a patch has to
> > > > update just that comment to "extend a workaround" to a next platform.
> > > > This is not always done, so we get a comment that doesn't match what is
> > > > supposed to be there.
> > >
> > > Tl;dr; version - lets park this until January and discuss once
> > > everyone is back.
> >
> > I'll leave my comment here since I will be out until mid January.
> >
> > >
> > > Longer version. I've been trying to get us talking about this a
> > > couple times before and I'd really like to close with an explicit
> > > consensus, discussion points addressed instead of skipped and just
> > > moving ahead with patches.
> > >
> > > References:
> > > 3fcf71b9-337f-6186-7b00-27cbfd116...@linux.intel.com
> > > Y5j0b/bykbitc...@mdroper-desk1.amr.corp.intel.com
> > >
> > > So point I wanted to discuss is whether these comments are truly
> > > useless or maybe they can help during review. If the tool can
> > > actually output them then I am leaning towards that they can be.
> >
> > I consider "can the tool output xyz?" asking the wrong question.
> > "The tool", which is our own small python script querying a database can
> > output anything like that if we want to. The database has information of
> > what are the platforms/steppings for each the WA is known to be applied
> > *today*. And that can change and do change often, particularly for early
> > steppings and recent platforms.
> >
> > > Thought is, when a patch comes for review adding a new platform,
> > > stepping, whatever, to an existing if condition, if it contains the
> > > comments reviewer can more easily spot a hyphotetical logic
> > > inversion error or similar. It is also trivial to check that both
> > > condition and comment have been updated. (So lets not be rash and
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display: assume some pixelrate for src smaller than 1
== Series Details == Series: drm/i915/display: assume some pixelrate for src smaller than 1 URL : https://patchwork.freedesktop.org/series/112396/ State : warning == Summary == Error: dim checkpatch failed 2c7cc185eea1 drm/i915/display: assume some pixelrate for src smaller than 1 -:32: CHECK:SPACING: No space is necessary after a cast #32: FILE: drivers/gpu/drm/i915/display/intel_atomic_plane.c:159: + dst_wh = max(dst_w * dst_h, (unsigned) 1); -:32: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned' #32: FILE: drivers/gpu/drm/i915/display/intel_atomic_plane.c:159: + dst_wh = max(dst_w * dst_h, (unsigned) 1); total: 0 errors, 1 warnings, 1 checks, 20 lines checked
Re: [Intel-gfx] [RFC PATCH 00/20] Initial Xe driver submission
> > For one thing, setting that up would be a lot of up front infrastructure > > work. I'm not sure how to even pull that off when Xe is still > > out-of-tree and i915 development plunges on upstream as ever. > > > > For another, realistically, the overlap between supported platforms is > > going to end at some point, and eventually new platforms are only going > > to be supported with Xe. That's going to open up new possibilities for > > refactoring also the display code. I think it would be premature to lock > > in to a common directory structure or a common helper module at this > > point. > > > > I'm not saying no to the idea, and we've contemplated it before, but I > > think there are still too many moving parts to decide to go that way. > > FWIW, I actually have the same dilemma with the driver for new Mali GPUs > I'm working on. I initially started making it a sub-driver of the > existing panfrost driver (some HW blocks are similar, like the > IOMMU and a few other things, and some SW abstracts can be shared here > and there, like the GEM allocator logic). But I'm now considering > forking the driver (after Alyssa planted the seed :-)), not only > because I want to start from a clean sheet on the the uAPI front > (wouldn't be an issue in your case, because you're talking about > sharing helpers, not the driver frontend), but also because any refactor > to panfrost is a potential source of regression for existing users. So, > I tend to agree with Jani here, trying to share code before things have > settled down is likely to cause pain to both Xe and i915 > users+developers. ++ I pretend to have never written a kernel driver, so will not comment there. But Boris and I were previously bit trying to share code between our GL and VK drivers, before VK settled down, causing pain for both. I don't want a kernelside repeat of that (for either Mali or Intel). I tend to think that, if you're tempted to share a driver frontend without the backend, that's a sign that there's too much boilerplate for the frontend and maybe there needs to be more helpers somewhere. For Xe, that doesn't apply since the hw overlaps between the drivers, but for Mali, there really is more different than similar and there's an obvious, acute break between "old Mali" and "new Mali". The shared "instantiate a DRM driver boilerplate" is pretty trivial, and the MMU code is as simple as it gets...
Re: [Intel-gfx] [PATCH] drm/i915/fbc: Avoid full proxy f_ops for FBC debug attributes
On Tue, 3 Jan 2023, Deepak R Varma wrote:
> On Wed, Dec 28, 2022 at 06:18:12AM -0500, Rodrigo Vivi wrote:
> > On Tue, Dec 27, 2022 at 11:36:13PM +0530, Deepak R Varma wrote:
> > > On Tue, Dec 27, 2022 at 12:13:56PM -0500, Rodrigo Vivi wrote:
> > > > On Tue, Dec 27, 2022 at 01:30:53PM +0530, Deepak R Varma wrote:
> > > > > Using DEFINE_SIMPLE_ATTRIBUTE macro with the debugfs_create_file()
> > > > > function adds the overhead of introducing a proxy file operation
> > > > > functions to wrap the original read/write inside file removal
> > > > > protection
> > > > > functions. This adds significant overhead in terms of introducing and
> > > > > managing the proxy factory file operations structure and function
> > > > > wrapping at runtime.
> > > > > As a replacement, a combination of DEFINE_DEBUGFS_ATTRIBUTE macro
> > > > > paired
> > > > > with debugfs_create_file_unsafe() is suggested to be used instead.
> > > > > The
> > > > > DEFINE_DEBUGFS_ATTRIBUTE utilises debugfs_file_get() and
> > > > > debugfs_file_put() wrappers to protect the original read and write
> > > > > function calls for the debug attributes. There is no need for any
> > > > > runtime proxy file operations to be managed by the debugfs core.
> > > > >
> > > > > This Change is reported by the debugfs_simple_attr.cocci Coccinelle
> > > > > semantic patch.
> > > >
> > > > I just checked here with
> > > > $ make coccicheck M=drivers/gpu/drm/i915/ MODE=context
> > > > COCCI=./scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci
> > >
> > > Hello Rodrigo,
> > > Thank you so much for your review and feedback on the patch proposal.
> > >
> > > >
> > > > The part reported by the this script is the s/SIMPLE/DEBUGFS
> > > > but the change to the unsafe option is not.
> > >
> > > If you look at the original commit of this coccinelle file, it calls out
> > > the
> > > need for pairing debugfs_create_file_unsafe() as well. Please review this
> > >
> > > commitID: 5103068eaca2: ("debugfs, coccinelle: check for obsolete
> > > DEFINE_SIMPLE_ATTRIBUTE() usage")
> >
> > +Nicolai and Julia.
> >
> > It looks like coccinelle got right the
> > - DEFINE_SIMPLE_ATTRIBUTE(dsa_fops, dsa_get, dsa_set, dsa_fmt);
> > + DEFINE_DEBUGFS_ATTRIBUTE(dsa_fops, dsa_get, dsa_set, dsa_fmt);
> >
> > but it failed badly on
> > - debugfs_create_file(name, mode, parent, data, _fops)
> > + debugfs_create_file_unsafe(name, mode, parent, data, _fops)
> >
> > >
> > > Based on my review of the code, the functions debugfs_create_file() and
> > > debugfs_create_file_unsafe(), both internally call
> > > __debugfs_create_file().
> > > However, they pass debugfs_full_proxy_file_operations and
> > > debugfs_open_proxy_file_operations respectively to it. The former
> > > represents the
> > > full proxy factory, where as the later one is lightweight open proxy
> > > implementation of the file operations structure.
> > >
> > > >
> > > > This commit message is not explaining why the unsafe is the suggested
> > > > or who suggested it.
> > >
> > > If you find the response above accurate, I will include these details
> > > about
> > > the _unsafe() function in my commit message in v2.
> > >
> > > >
> > > > If you remove the unsafe part feel free to resend adding:
> > >
> > > Please confirm you still believe switching to _unsafe() is not necessary.
> >
> > Based on the coccinelle commit it looks like you are right, but cocinelle
> > just failed to detect the case. Let's see what Nicolai and Julia respond
> > before we move with any patch here.
>
> Hello Nicolai and Julia,
> Can you please review this proposed patch and the feedback comments from
> Rodrigo
> please?
I'm not an expert on this issue. If the semantic patch needs to change in
some way, I would be happy to take any improvements.
julia
>
> Thank you,
> ./drv
>
> >
> > >
> > > >
> > > > Reviewed-by: Rodrigo Vivi
> > > > (to both patches, this and the drrs one.
> > > >
> > > > Also, it looks like you could contribute with other 2 patches:
> > > > drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c:64:0-23: WARNING:
> > > > pxp_terminate_fops should be defined with DEFINE_DEBUGFS_ATTRIBUTE
> > > > drivers/gpu/drm/i915/gvt/debugfs.c:150:0-23: WARNING:
> > > > vgpu_scan_nonprivbb_fops should be defined with DEFINE_DEBUGFS_ATTRIBUTE
> > >
> > > Yes, these are on my list. Was waiting for a feedback on the first
> > > submission
> > > before I send more similar patches.
> > >
> > > Appreciate your time and the feedback.
> > >
> > >
> > > Regards,
> > > ./drv
> > >
> > > >
> > > > >
> > > > > Signed-off-by: Deepak R Varma
> > > > > ---
> > > > > drivers/gpu/drm/i915/display/intel_fbc.c | 12 ++--
> > > > > 1 file changed, 6 insertions(+), 6 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> > > > > b/drivers/gpu/drm/i915/display/intel_fbc.c
> > > > > index b5ee5ea0d010..4b481e2f908b 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> > > > > +++
[Intel-gfx] [PATCH] drm/i915: Expand force_probe to block probe of devices as well.
There are new cases where we want to block i915 probe, such
as when experimenting or developing the new Xe driver.
But also, with the new hybrid cards, users or developers might
want to use i915 only on integrated and fully block the probe
of the i915 for the discrete. Or vice versa.
There are even older development and validation reasons,
like when you use some distro where the modprobe.blacklist is
not present.
But in any case, let's introduce a more granular control, but without
introducing yet another parameter, but using the existent force_probe
one.
Just by adding a ! in the begin of the id in the force_probe, like
in this case where we would block the probe for Alder Lake:
$ insmod i915.ko force_probe='!46a6'
v2: Take care of '*' and '!*' cases as pointed out by
Gustavo and Jani.
v3: Information message improvements by Michal.
Documentation improvements by Jani.
Cc: Jani Nikula
Cc: Gustavo Sousa
Signed-off-by: Rodrigo Vivi
Reviewed-by: Jani Nikula #v2
Acked-by: Gustavo Sousa
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/Kconfig | 21 ---
drivers/gpu/drm/i915/i915_params.c | 2 +-
drivers/gpu/drm/i915/i915_pci.c| 33 +-
3 files changed, 47 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 3efce05d7b57..3dfc1f5ce4de 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -54,24 +54,39 @@ config DRM_I915
If "M" is selected, the module will be called i915.
config DRM_I915_FORCE_PROBE
- string "Force probe driver for selected new Intel hardware"
+ string "Force probe i915 for selected Intel hardware IDs"
depends on DRM_I915
help
This is the default value for the i915.force_probe module
parameter. Using the module parameter overrides this option.
- Force probe the driver for new Intel graphics devices that are
+ Force probe the i915 for Intel graphics devices that are
recognized but not properly supported by this kernel version. It is
recommended to upgrade to a kernel version with proper support as soon
as it is available.
+ It can also be used to block the probe of recognized and fully
+ supported devices.
+
Use "" to disable force probe. If in doubt, use this.
- Use "[,,...]" to force probe the driver for listed
+ Use "[,,...]" to force probe the i915 for listed
devices. For example, "4500" or "4500,4571".
Use "*" to force probe the driver for all known devices.
+ Use "!" right before the ID to block the probe of the device. For
+ example, "4500,!4571" forces the probe of 4500 and blocks the probe of
+ 4571.
+
+ Use "!*" to block the probe of the driver for all known devices.
+
+ Please be aware that '*' cannot be combined with IDs. For example,
+ "1234,!*" will result in the global block, even for "1234".
+
+ Also, the '!' case supersedes the regular case. For example,
+ "1234,!1234" and "!1234,1234" both block 1234.
+
config DRM_I915_CAPTURE_ERROR
bool "Enable capturing GPU state following a hang"
depends on DRM_I915
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 61578f2860cd..d634bd3f641a 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -122,7 +122,7 @@ i915_param_named_unsafe(enable_psr2_sel_fetch, bool, 0400,
"Default: 0");
i915_param_named_unsafe(force_probe, charp, 0400,
- "Force probe the driver for specified devices. "
+ "Force probe options for specified supported devices. "
"See CONFIG_DRM_I915_FORCE_PROBE for details.");
i915_param_named_unsafe(disable_power_well, int, 0400,
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 7fd74cc28c0a..1bcbca38ce5c 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1253,7 +1253,7 @@ static void i915_pci_remove(struct pci_dev *pdev)
}
/* is device_id present in comma separated list of ids */
-static bool force_probe(u16 device_id, const char *devices)
+static bool device_id_in_list(u16 device_id, const char *devices, bool
negative)
{
char *s, *p, *tok;
bool ret;
@@ -1262,7 +1262,9 @@ static bool force_probe(u16 device_id, const char
*devices)
return false;
/* match everything */
- if (strcmp(devices, "*") == 0)
+ if (negative && strcmp(devices, "!*") == 0)
+ return true;
+ if (!negative && strcmp(devices, "*") == 0)
return true;
s = kstrdup(devices, GFP_KERNEL);
@@ -1272,6 +1274,12 @@ static bool force_probe(u16 device_id, const char
*devices)
for (p = s, ret = false; (tok = strsep(, ",")) != NULL; ) {
u16 val;
+
Re: [Intel-gfx] [PATCH] drm/i915/fbc: Avoid full proxy f_ops for FBC debug attributes
On Wed, Jan 04, 2023 at 06:51:37PM +0100, Julia Lawall wrote:
>
>
> On Tue, 3 Jan 2023, Deepak R Varma wrote:
>
> > On Wed, Dec 28, 2022 at 06:18:12AM -0500, Rodrigo Vivi wrote:
> > > On Tue, Dec 27, 2022 at 11:36:13PM +0530, Deepak R Varma wrote:
> > > > On Tue, Dec 27, 2022 at 12:13:56PM -0500, Rodrigo Vivi wrote:
> > > > > On Tue, Dec 27, 2022 at 01:30:53PM +0530, Deepak R Varma wrote:
> > > > > > Using DEFINE_SIMPLE_ATTRIBUTE macro with the debugfs_create_file()
> > > > > > function adds the overhead of introducing a proxy file operation
> > > > > > functions to wrap the original read/write inside file removal
> > > > > > protection
> > > > > > functions. This adds significant overhead in terms of introducing
> > > > > > and
> > > > > > managing the proxy factory file operations structure and function
> > > > > > wrapping at runtime.
> > > > > > As a replacement, a combination of DEFINE_DEBUGFS_ATTRIBUTE macro
> > > > > > paired
> > > > > > with debugfs_create_file_unsafe() is suggested to be used instead.
> > > > > > The
> > > > > > DEFINE_DEBUGFS_ATTRIBUTE utilises debugfs_file_get() and
> > > > > > debugfs_file_put() wrappers to protect the original read and write
> > > > > > function calls for the debug attributes. There is no need for any
> > > > > > runtime proxy file operations to be managed by the debugfs core.
> > > > > >
> > > > > > This Change is reported by the debugfs_simple_attr.cocci Coccinelle
> > > > > > semantic patch.
> > > > >
> > > > > I just checked here with
> > > > > $ make coccicheck M=drivers/gpu/drm/i915/ MODE=context
> > > > > COCCI=./scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci
> > > >
> > > > Hello Rodrigo,
> > > > Thank you so much for your review and feedback on the patch proposal.
> > > >
> > > > >
> > > > > The part reported by the this script is the s/SIMPLE/DEBUGFS
> > > > > but the change to the unsafe option is not.
> > > >
> > > > If you look at the original commit of this coccinelle file, it calls
> > > > out the
> > > > need for pairing debugfs_create_file_unsafe() as well. Please review
> > > > this
> > > >
> > > > commitID: 5103068eaca2: ("debugfs, coccinelle: check for obsolete
> > > > DEFINE_SIMPLE_ATTRIBUTE() usage")
> > >
> > > +Nicolai and Julia.
> > >
> > > It looks like coccinelle got right the
> > > - DEFINE_SIMPLE_ATTRIBUTE(dsa_fops, dsa_get, dsa_set, dsa_fmt);
> > > + DEFINE_DEBUGFS_ATTRIBUTE(dsa_fops, dsa_get, dsa_set, dsa_fmt);
> > >
> > > but it failed badly on
> > > - debugfs_create_file(name, mode, parent, data, _fops)
> > > + debugfs_create_file_unsafe(name, mode, parent, data, _fops)
> > >
> > > >
> > > > Based on my review of the code, the functions debugfs_create_file() and
> > > > debugfs_create_file_unsafe(), both internally call
> > > > __debugfs_create_file().
> > > > However, they pass debugfs_full_proxy_file_operations and
> > > > debugfs_open_proxy_file_operations respectively to it. The former
> > > > represents the
> > > > full proxy factory, where as the later one is lightweight open proxy
> > > > implementation of the file operations structure.
> > > >
> > > > >
> > > > > This commit message is not explaining why the unsafe is the suggested
> > > > > or who suggested it.
> > > >
> > > > If you find the response above accurate, I will include these details
> > > > about
> > > > the _unsafe() function in my commit message in v2.
> > > >
> > > > >
> > > > > If you remove the unsafe part feel free to resend adding:
> > > >
> > > > Please confirm you still believe switching to _unsafe() is not
> > > > necessary.
> > >
> > > Based on the coccinelle commit it looks like you are right, but cocinelle
> > > just failed to detect the case. Let's see what Nicolai and Julia respond
> > > before we move with any patch here.
> >
> > Hello Nicolai and Julia,
> > Can you please review this proposed patch and the feedback comments from
> > Rodrigo
> > please?
>
> I'm not an expert on this issue. If the semantic patch needs to change in
> some way, I would be happy to take any improvements.
Hi Julia, thanks for helping here.
So, my question is why this
make coccicheck M=drivers/gpu/drm/i915/ MODE=context
COCCI=./scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci
didn't catch this chunck:
- debugfs_create_file("i915_fbc_false_color", 0644, parent,
- fbc, _fbc_debugfs_false_color_fops);
+ debugfs_create_file_unsafe("i915_fbc_false_color", 0644, parent,
+ fbc,
_fbc_debugfs_false_color_fops);
When I run it it only catches and replaces this:
- DEFINE_SIMPLE_ATTRIBUTE(dsa_fops, dsa_get, dsa_set, dsa_fmt);
+ DEFINE_DEBUGFS_ATTRIBUTE(dsa_fops, dsa_get, dsa_set, dsa_fmt);
But looking to the .cocci script or at least to its description,
I believe it should catch both cases.
But if it is not a bug in the cocci script, then I'd like to hear
from Nicolai why. And have this documented in the script.
Thanks,
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Consolidate TLB invalidation flow
On Wed, Jan 04, 2023 at 10:08:29AM +, Tvrtko Ursulin wrote:
>
> On 03/01/2023 19:57, Matt Roper wrote:
> > On Mon, Dec 19, 2022 at 05:10:02PM +0100, Andrzej Hajda wrote:
> > > On 19.12.2022 11:13, Tvrtko Ursulin wrote:
> > > > From: Tvrtko Ursulin
> > > >
> > > > As the logic for selecting the register and corresponsing values grew,
> > > > the
> > >
> > > corresponding
> > >
> > > > code become a bit unsightly. Consolidate by storing the required values
> > > > at
> > > > engine init time in the engine itself, and by doing so minimise the
> > > > amount
> > > > of invariant platform and engine checks during each and every TLB
> > > > invalidation.
> > > >
> > > > v2:
> > > >* Fail engine probe if TLB invlidations registers are unknown.
> > > >
> > > > Signed-off-by: Tvrtko Ursulin
> > > > Cc: Andrzej Hajda
> > > > Cc: Matt Roper
> > > > Reviewed-by: Andrzej Hajda # v1
> > > > ---
> > > >drivers/gpu/drm/i915/gt/intel_engine_cs.c| 93 +
> > > >drivers/gpu/drm/i915/gt/intel_engine_types.h | 15 +++
> > > >drivers/gpu/drm/i915/gt/intel_gt.c | 135
> > > > +++
> > > >3 files changed, 128 insertions(+), 115 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > > b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > > index 99c4b866addd..d47dadfc25c8 100644
> > > > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > > +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > > @@ -1143,12 +1143,105 @@ static int init_status_page(struct
> > > > intel_engine_cs *engine)
> > > > return ret;
> > > >}
> > > > +static int intel_engine_init_tlb_invalidation(struct intel_engine_cs
> > > > *engine)
> > > > +{
> > > > + static const union intel_engine_tlb_inv_reg gen8_regs[] = {
> > > > + [RENDER_CLASS].reg = GEN8_RTCR,
> > > > + [VIDEO_DECODE_CLASS].reg= GEN8_M1TCR, /* ,
> > > > GEN8_M2TCR */
> > > > + [VIDEO_ENHANCEMENT_CLASS].reg = GEN8_VTCR,
> > > > + [COPY_ENGINE_CLASS].reg = GEN8_BTCR,
> > > > + };
> > > > + static const union intel_engine_tlb_inv_reg gen12_regs[] = {
> > > > + [RENDER_CLASS].reg = GEN12_GFX_TLB_INV_CR,
> > > > + [VIDEO_DECODE_CLASS].reg= GEN12_VD_TLB_INV_CR,
> > > > + [VIDEO_ENHANCEMENT_CLASS].reg = GEN12_VE_TLB_INV_CR,
> > > > + [COPY_ENGINE_CLASS].reg = GEN12_BLT_TLB_INV_CR,
> > > > + [COMPUTE_CLASS].reg =
> > > > GEN12_COMPCTX_TLB_INV_CR,
> > > > + };
> > > > + static const union intel_engine_tlb_inv_reg xehp_regs[] = {
> > > > + [RENDER_CLASS].mcr_reg= XEHP_GFX_TLB_INV_CR,
> > > > + [VIDEO_DECODE_CLASS].mcr_reg = XEHP_VD_TLB_INV_CR,
> > > > + [VIDEO_ENHANCEMENT_CLASS].mcr_reg = XEHP_VE_TLB_INV_CR,
> > > > + [COPY_ENGINE_CLASS].mcr_reg = XEHP_BLT_TLB_INV_CR,
> > > > + [COMPUTE_CLASS].mcr_reg =
> > > > XEHP_COMPCTX_TLB_INV_CR,
> > > > + };
> > > > + struct drm_i915_private *i915 = engine->i915;
> > > > + const union intel_engine_tlb_inv_reg *regs;
> > > > + union intel_engine_tlb_inv_reg reg;
> > > > + unsigned int class = engine->class;
> > > > + unsigned int num = 0;
> > > > + u32 val;
> > > > +
> > > > + /*
> > > > +* New platforms should not be added with catch-all-newer (>=)
> > > > +* condition so that any later platform added triggers the
> > > > below warning
> > > > +* and in turn mandates a human cross-check of whether the
> > > > invalidation
> > > > +* flows have compatible semantics.
> > > > +*
> > > > +* For instance with the 11.00 -> 12.00 transition three out of
> > > > five
> > > > +* respective engine registers were moved to masked type. Then
> > > > after the
> > > > +* 12.00 -> 12.50 transition multi cast handling is required
> > > > too.
> > > > +*/
> > > > +
> > > > + if (GRAPHICS_VER_FULL(i915) == IP_VER(12, 50)) {
> >
> > This is bad...it only captures XEHPSDV and breaks the handling of DG2
> > (12.55), PVC (12.60), and MTL (12.70, 12.71, and 12.72). You're not
> > hitting the warning as expected since those are all now being captured
> > by the next case of the if/else ladder. With the way GMD_ID works, we
> > may also get new version numbers that silently show up in hardware too
> > at some point (e.g., 12.73, 12.74, etc.)
>
> Great (on multiple counts) ...
>
> >
> > > > + regs = xehp_regs;
> > > > + num = ARRAY_SIZE(xehp_regs);
> > > > + } else if (GRAPHICS_VER(i915) == 12) {
> >
> > You'd want to change this to
> >
> > GRAPHICS_VER_FULL(i915) == IP_VER(12, 0)
> >
> > to get the behavior you expected.
>
> Okay, that, and then to be as
Re: [Intel-gfx] [PATCH] drm/i915: Fix potential context UAFs
On Wed, Jan 4, 2023 at 1:34 AM Tvrtko Ursulin
wrote:
>
>
> On 03/01/2023 23:49, Rob Clark wrote:
> > From: Rob Clark
> >
> > gem_context_register() makes the context visible to userspace, and which
> > point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl.
> > So we need to ensure that nothing uses the ctx ptr after this. And we
> > need to ensure that adding the ctx to the xarray is the *last* thing
> > that gem_context_register() does with the ctx pointer.
>
> Any backtraces from oopses or notes on how it was found to record in the
> commit message?
It was a UAF bug that was reported to us
https://bugs.chromium.org/p/chromium/issues/detail?id=1401594 (but I
guess security bugs are not going to be visible)
>
> > Signed-off-by: Rob Clark
>
> Fixes: a4c1cdd34e2c ("drm/i915/gem: Delay context creation (v3)")
> References: 3aa9945a528e ("drm/i915: Separate GEM context construction and
> registration to userspace")
> Cc: # v5.15+
>
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_context.c | 24 +++--
> > 1 file changed, 18 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index 7f2831efc798..6250de9b9196 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -1688,6 +1688,10 @@ void i915_gem_init__contexts(struct drm_i915_private
> > *i915)
> > init_contexts(>gem.contexts);
> > }
> >
> > +/*
> > + * Note that this implicitly consumes the ctx reference, by placing
> > + * the ctx in the context_xa.
> > + */
> > static void gem_context_register(struct i915_gem_context *ctx,
> >struct drm_i915_file_private *fpriv,
> >u32 id)
> > @@ -1703,10 +1707,6 @@ static void gem_context_register(struct
> > i915_gem_context *ctx,
> > snprintf(ctx->name, sizeof(ctx->name), "%s[%d]",
> >current->comm, pid_nr(ctx->pid));
> >
> > - /* And finally expose ourselves to userspace via the idr */
> > - old = xa_store(>context_xa, id, ctx, GFP_KERNEL);
> > - WARN_ON(old);
> > -
> > spin_lock(>client->ctx_lock);
> > list_add_tail_rcu(>client_link, >client->ctx_list);
> > spin_unlock(>client->ctx_lock);
> > @@ -1714,6 +1714,10 @@ static void gem_context_register(struct
> > i915_gem_context *ctx,
> > spin_lock(>gem.contexts.lock);
> > list_add_tail(>link, >gem.contexts.list);
> > spin_unlock(>gem.contexts.lock);
> > +
> > + /* And finally expose ourselves to userspace via the idr */
> > + old = xa_store(>context_xa, id, ctx, GFP_KERNEL);
> > + WARN_ON(old);
>
> Have you seen that this hunk is needed or just moving it for a good measure?
> To be clear, it is probably best to move it even if the current placement
> cannot cause any problems, I am just double-checking if you had any concrete
> observations here while mulling over easier stable backports if we would omit
> it.
>
This was actually the originally reported issue, the
finalize_create_context_locked() part was something I found when the
original report prompted me to audit gem_context_register() call
paths.
> > }
> >
> > int i915_gem_context_open(struct drm_i915_private *i915,
> > @@ -2199,14 +2203,22 @@ finalize_create_context_locked(struct
> > drm_i915_file_private *file_priv,
> > if (IS_ERR(ctx))
> > return ctx;
> >
> > + /*
> > + * One for the xarray and one for the caller. We need to grab
> > + * the reference *prior* to making the ctx visble to userspace
> > + * in gem_context_register(), as at any point after that
> > + * userspace can try to race us with another thread destroying
> > + * the context under our feet.
> > + */
> > + i915_gem_context_get(ctx);
> > +
> > gem_context_register(ctx, file_priv, id);
> >
> > old = xa_erase(_priv->proto_context_xa, id);
> > GEM_BUG_ON(old != pc);
> > proto_context_close(file_priv->dev_priv, pc);
> >
> > - /* One for the xarray and one for the caller */
> > - return i915_gem_context_get(ctx);
> > + return ctx;
>
> Otherwise userspace can look up a context which hasn't had it's reference
> count increased yep. I can add the Fixes: and Stable: tags while merging if
> no complaints.
>
> Reviewed-by: Tvrtko Ursulin
Thanks
BR,
-R
>
> Regards,
>
> Tvrtko
>
> > }
> >
> > struct i915_gem_context *
[Intel-gfx] [PATCH v2] drm/i915/display: drop redundant display/ from #includes
Drop the redundant sub-directory from #includes under display/. Group and sort the results. v2: Rebase Reviewed-by: Arun R Murthy Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/display/intel_bios.c| 9 ++-- drivers/gpu/drm/i915/display/intel_display.c | 51 ++-- drivers/gpu/drm/i915/display/intel_psr.c | 3 +- 3 files changed, 30 insertions(+), 33 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_bios.c b/drivers/gpu/drm/i915/display/intel_bios.c index 55544d484318..78abe34c7a42 100644 --- a/drivers/gpu/drm/i915/display/intel_bios.c +++ b/drivers/gpu/drm/i915/display/intel_bios.c @@ -25,16 +25,15 @@ * */ -#include #include #include - -#include "display/intel_display.h" -#include "display/intel_display_types.h" -#include "display/intel_gmbus.h" +#include #include "i915_drv.h" #include "i915_reg.h" +#include "intel_display.h" +#include "intel_display_types.h" +#include "intel_gmbus.h" #define _INTEL_BIOS_PRIVATE #include "intel_vbt_defs.h" diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index e75b9b2a0e01..734e8e613f8e 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -24,15 +24,15 @@ * Eric Anholt */ -#include +#include #include #include #include #include -#include #include #include #include +#include #include #include @@ -45,28 +45,6 @@ #include #include -#include "display/intel_audio.h" -#include "display/intel_crt.h" -#include "display/intel_ddi.h" -#include "display/intel_display_debugfs.h" -#include "display/intel_display_power.h" -#include "display/intel_dp.h" -#include "display/intel_dp_mst.h" -#include "display/intel_dpll.h" -#include "display/intel_dpll_mgr.h" -#include "display/intel_drrs.h" -#include "display/intel_dsi.h" -#include "display/intel_dvo.h" -#include "display/intel_fb.h" -#include "display/intel_gmbus.h" -#include "display/intel_hdmi.h" -#include "display/intel_lvds.h" -#include "display/intel_sdvo.h" -#include "display/intel_snps_phy.h" -#include "display/intel_tv.h" -#include "display/intel_vdsc.h" -#include "display/intel_vrr.h" - #include "gem/i915_gem_lmem.h" #include "gem/i915_gem_object.h" @@ -76,31 +54,48 @@ #include "i915_drv.h" #include "i915_reg.h" #include "i915_utils.h" +#include "i9xx_plane.h" #include "icl_dsi.h" #include "intel_acpi.h" #include "intel_atomic.h" #include "intel_atomic_plane.h" +#include "intel_audio.h" #include "intel_bw.h" #include "intel_cdclk.h" #include "intel_color.h" +#include "intel_crt.h" #include "intel_crtc.h" #include "intel_crtc_state_dump.h" +#include "intel_ddi.h" #include "intel_de.h" +#include "intel_display_debugfs.h" +#include "intel_display_power.h" #include "intel_display_types.h" #include "intel_dmc.h" +#include "intel_dp.h" #include "intel_dp_link_training.h" +#include "intel_dp_mst.h" #include "intel_dpio_phy.h" +#include "intel_dpll.h" +#include "intel_dpll_mgr.h" #include "intel_dpt.h" +#include "intel_drrs.h" +#include "intel_dsi.h" +#include "intel_dvo.h" +#include "intel_fb.h" #include "intel_fbc.h" #include "intel_fbdev.h" #include "intel_fdi.h" #include "intel_fifo_underrun.h" #include "intel_frontbuffer.h" +#include "intel_gmbus.h" #include "intel_hdcp.h" +#include "intel_hdmi.h" #include "intel_hotplug.h" #include "intel_hti.h" -#include "intel_modeset_verify.h" +#include "intel_lvds.h" #include "intel_modeset_setup.h" +#include "intel_modeset_verify.h" #include "intel_overlay.h" #include "intel_panel.h" #include "intel_pch_display.h" @@ -112,10 +107,14 @@ #include "intel_pps.h" #include "intel_psr.h" #include "intel_quirks.h" +#include "intel_sdvo.h" +#include "intel_snps_phy.h" #include "intel_sprite.h" #include "intel_tc.h" +#include "intel_tv.h" +#include "intel_vdsc.h" #include "intel_vga.h" -#include "i9xx_plane.h" +#include "intel_vrr.h" #include "skl_scaler.h" #include "skl_universal_plane.h" #include "skl_watermark.h" diff --git a/drivers/gpu/drm/i915/display/intel_psr.c b/drivers/gpu/drm/i915/display/intel_psr.c index d0d774219cc5..c9c00f8fa1b2 100644 --- a/drivers/gpu/drm/i915/display/intel_psr.c +++ b/drivers/gpu/drm/i915/display/intel_psr.c @@ -24,14 +24,13 @@ #include #include -#include "display/intel_dp.h" - #include "i915_drv.h" #include "i915_reg.h" #include "intel_atomic.h" #include "intel_crtc.h" #include "intel_de.h" #include "intel_display_types.h" +#include "intel_dp.h" #include "intel_dp_aux.h" #include "intel_hdmi.h" #include "intel_psr.h" -- 2.34.1
Re: [Intel-gfx] [PATCHv7] drm/i915/dp: change aux_ctl reg read to polling read
> -Original Message- > From: Nikula, Jani > Sent: Wednesday, January 4, 2023 6:58 PM > To: Murthy, Arun R ; intel- > g...@lists.freedesktop.org; ville.syrj...@linux.intel.com; Deak, Imre > > Cc: Murthy, Arun R > Subject: Re: [PATCHv7] drm/i915/dp: change aux_ctl reg read to polling read > > On Wed, 21 Dec 2022, Arun R Murthy wrote: > > The busy timeout logic checks for the AUX BUSY, then waits for the > > timeout period and then after timeout reads the register for BUSY or > > Success. > > Instead replace interrupt with polling so as to read the AUX CTL > > register often before the timeout period. Looks like there might be > > some issue with interrupt-on-read. Hence changing the logic to polling > read. > > > > v2: replace interrupt with polling read > > v3: use usleep_rang instead of msleep, updated commit msg > > v4: use intel_wait_for_regiter internal function > > v5: use __intel_de_wait_for_register with 500us slow and 10ms fast > > timeout > > v6: check return value of __intel_de_wait_for_register > > v7: using default 2us for intel_de_wait_for_register > > > > Signed-off-by: Arun R Murthy > > Pushed to drm-intel-next, thanks for the patch. Thanks! > > How about replacing the other open coded try loop in intel_dp_aux_xfer() > with intel_de_wait_for_register() too? Sure will float a patch for that too. Thanks and Regards, Arun R Murthy > > BR, > Jani. > > > --- > > drivers/gpu/drm/i915/display/intel_dp_aux.c | 14 +- > > 1 file changed, 5 insertions(+), 9 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c > > b/drivers/gpu/drm/i915/display/intel_dp_aux.c > > index 91c93c93e5fc..5a176bfb10a2 100644 > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux.c > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c > > @@ -41,20 +41,16 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp) > > i915_reg_t ch_ctl = intel_dp->aux_ch_ctl_reg(intel_dp); > > const unsigned int timeout_ms = 10; > > u32 status; > > - bool done; > > - > > -#define C (((status = intel_de_read_notrace(i915, ch_ctl)) & > DP_AUX_CH_CTL_SEND_BUSY) == 0) > > - done = wait_event_timeout(i915->display.gmbus.wait_queue, C, > > - msecs_to_jiffies_timeout(timeout_ms)); > > + int ret; > > > > - /* just trace the final value */ > > - trace_i915_reg_rw(false, ch_ctl, status, sizeof(status), true); > > + ret = __intel_de_wait_for_register(i915, ch_ctl, > > + DP_AUX_CH_CTL_SEND_BUSY, 0, > > + 2, timeout_ms, ); > > > > - if (!done) > > + if (ret == -ETIMEDOUT) > > drm_err(>drm, > > "%s: did not complete or timeout within %ums > (status 0x%08x)\n", > > intel_dp->aux.name, timeout_ms, status); -#undef C > > > > return status; > > } > > -- > Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PULL] drm-misc-next
On Tue, Jan 03, 2023 at 11:51:46AM +0100, Thomas Zimmermann wrote: > Hi Dave and Daniel, > > here's the first PR for drm-misc-next for the upcomming version v6.3 > of the Linux kernel. Overall, it's fairly small; due to holidays, I > guess. Noteworthy changes are in connector TV-mode handling, KUnit tests > and MIPI helpers. > > Best regards > Thomas > > drm-misc-next-2023-01-03: > drm-misc-next for v6.3: > > UAPI Changes: > > * connector: Support analog-TV mode property > > * media: Add MEDIA_BUS_FMT_RGB565_1X24_CPADHI, >MEDIA_BUS_FMT_RGB666_1X18 and MEDIA_BUS_FMT_RGB666_1X24_CPADHI > > Cross-subsystem Changes: > > * dma-buf: Documentation fixes > > * i2c: Introduce i2c_client_get_device_id() helper > > Core Changes: > > * Improve support for analog TV output > > * bridge: Remove unused drm_bridge_chain functions > > * debugfs: Add per-device helpers and convert various DRM drivers > > * dp-mst: Various fixes > > * fbdev emulation: Always pick 32 bpp as default > > * KUnit: Add tests for managed helpers; Various cleanups > > * panel-orientation: Add quirks for Lenovo Yoga Tab 3 X90F and DynaBook K50 > > * TTM: Open-code ttm_bo_wait() and remove the helper > > Driver Changes: > > * Fix preferred depth and bpp values throughout DRM drivers > > * Remove #CONFIG_PM guards throughout DRM drivers > > * ast: Various fixes > > * bridge: Implement i2c's probe_new in various drivers; Fixes; ite-it6505: >Locking fixes, Cache EDID data; ite-it66121: Support IT6610 chip, >Cleanups; lontium-tl9611: Fix HDMI on DragonBoard 845c; parade-ps8640: >Use atomic bridge functions > > * gud: Convert to DRM shadow-plane helpers; Perform flushing synchronously >during atomic update > > * ili9486: Support 16-bit pixel data > > * imx: Split off IPUv3 driver; Various fixes > > * mipi-dbi: Convert to DRM shadow-plane helpers plus rsp driver changes; >Support separate I/O-voltage supply > > * mxsfb: Depend on ARCH_MXS or ARCH_MXC > > * omapdrm: Various fixes > > * panel: Use ktime_get_boottime() to measure power-down delay in various >drivers; Fix auto-suspend delay in various drivers; orisetech-ota5601a: >Add support > > * sprd: Cleanups > > * sun4i: Convert to new TV-mode property > > * tidss: Various fixes > > * v3d: Various fixes > > * vc4: Convert to new TV-mode property; Support Kunit tests; Cleanups; >dpi: Support RGB565 and RGB666 formats; dsi: Convert DSI driver to >bridge > > * virtio: Improve tracing > > * vkms: Support small cursors in IGT tests; Various fixes > The following changes since commit d47f9580839eb6fe568e38b2084d94887fbf5ce0: > > Backmerge tag 'v6.1-rc6' into drm-next (2022-11-24 11:05:43 +1000) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2023-01-03 Pulled to drm-next, thanks -Daniel > > for you to fetch changes up to 2591939e881cf728b6ac45971eeec2f58051c101: > > drm/virtio: Spiff out cmd queue/response traces (2023-01-02 17:51:27 +0300) > > > drm-misc-next for v6.3: > > UAPI Changes: > > * connector: Support analog-TV mode property > > * media: Add MEDIA_BUS_FMT_RGB565_1X24_CPADHI, >MEDIA_BUS_FMT_RGB666_1X18 and MEDIA_BUS_FMT_RGB666_1X24_CPADHI > > Cross-subsystem Changes: > > * dma-buf: Documentation fixes > > * i2c: Introduce i2c_client_get_device_id() helper > > Core Changes: > > * Improve support for analog TV output > > * bridge: Remove unused drm_bridge_chain functions > > * debugfs: Add per-device helpers and convert various DRM drivers > > * dp-mst: Various fixes > > * fbdev emulation: Always pick 32 bpp as default > > * KUnit: Add tests for managed helpers; Various cleanups > > * panel-orientation: Add quirks for Lenovo Yoga Tab 3 X90F and DynaBook K50 > > * TTM: Open-code ttm_bo_wait() and remove the helper > > Driver Changes: > > * Fix preferred depth and bpp values throughout DRM drivers > > * Remove #CONFIG_PM guards throughout DRM drivers > > * ast: Various fixes > > * bridge: Implement i2c's probe_new in various drivers; Fixes; ite-it6505: >Locking fixes, Cache EDID data; ite-it66121: Support IT6610 chip, >Cleanups; lontium-tl9611: Fix HDMI on DragonBoard 845c; parade-ps8640: >Use atomic bridge functions > > * gud: Convert to DRM shadow-plane helpers; Perform flushing synchronously >during atomic update > > * ili9486: Support 16-bit pixel data > > * imx: Split off IPUv3 driver; Various fixes > > * mipi-dbi: Convert to DRM shadow-plane helpers plus rsp driver changes;i >Support separate I/O-voltage supply > > * mxsfb: Depend on ARCH_MXS or ARCH_MXC > > * omapdrm: Various fixes > > * panel: Use ktime_get_boottime() to measure power-down delay in various >drivers; Fix auto-suspend delay in various drivers; orisetech-ota5601a: >Add support > > * sprd: Cleanups > > *
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Expand force_probe to block probe of devices as well. (rev2)
== Series Details ==
Series: drm/i915: Expand force_probe to block probe of devices as well. (rev2)
URL : https://patchwork.freedesktop.org/series/112292/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12541 -> Patchwork_112292v2
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_112292v2 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_112292v2, 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_112292v2/index.html
Participating hosts (42 -> 41)
--
Additional (1): fi-rkl-11600
Missing(2): bat-dg2-oem1 bat-atsm-1
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_112292v2:
### IGT changes ###
Possible regressions
* igt@debugfs_test@read_all_entries:
- fi-icl-u2: [PASS][1] -> [ABORT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12541/fi-icl-u2/igt@debugfs_test@read_all_entries.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112292v2/fi-icl-u2/igt@debugfs_test@read_all_entries.html
* igt@i915_selftest@live@hangcheck:
- bat-adlp-4: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12541/bat-adlp-4/igt@i915_selftest@l...@hangcheck.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112292v2/bat-adlp-4/igt@i915_selftest@l...@hangcheck.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-rpls-1}: [PASS][5] -> [DMESG-WARN][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12541/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112292v2/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html
Known issues
Here are the changes found in Patchwork_112292v2 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@basic-hwmon:
- fi-rkl-11600: NOTRUN -> [SKIP][7] ([i915#7456])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112292v2/fi-rkl-11600/igt@debugfs_t...@basic-hwmon.html
* igt@gem_huc_copy@huc-copy:
- fi-rkl-11600: NOTRUN -> [SKIP][8] ([i915#2190])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112292v2/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-rkl-11600: NOTRUN -> [SKIP][9] ([i915#4613]) +3 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112292v2/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html
* igt@gem_tiled_pread_basic:
- fi-rkl-11600: NOTRUN -> [SKIP][10] ([i915#3282])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112292v2/fi-rkl-11600/igt@gem_tiled_pread_basic.html
* igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600: NOTRUN -> [SKIP][11] ([i915#7561])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112292v2/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600: NOTRUN -> [INCOMPLETE][12] ([i915#4817])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112292v2/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_chamelium@common-hpd-after-suspend:
- bat-dg1-6: NOTRUN -> [SKIP][13] ([fdo#111827])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112292v2/bat-dg1-6/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@hdmi-edid-read:
- fi-rkl-11600: NOTRUN -> [SKIP][14] ([fdo#111827]) +7 similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112292v2/fi-rkl-11600/igt@kms_chamel...@hdmi-edid-read.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-rkl-11600: NOTRUN -> [SKIP][15] ([i915#4103])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112292v2/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka: [PASS][16] -> [FAIL][17] ([i915#6298])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12541/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112292v2/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-rkl-11600: NOTRUN -> [SKIP][18] ([fdo#109285] / [i915#4098])
[18]:
Re: [Intel-gfx] [PATCH v2] drm/i915: dell wyse 3040 shutdown fix
On Tue, 03 Jan 2023, Alexey Lukyachuk wrote:
> On Tue, 03 Jan 2023 12:14:02 +0200
> Jani Nikula wrote:
>
>> On Mon, 02 Jan 2023, Alexey Lukyachuk wrote:
>> > Regarding to your question about fdo gitlab, I went to do it.
>>
>> What's the URL for the issue?
>>
>> BR,
>> Jani.
>>
>
> I have not submited issue in bug tracker because I found solution in git.
> ("Before filing the bug, please try to reproduce your issue with the
> latest kernel. Use the latest drm-tip branch from
> http://cgit.freedesktop.org/drm-tip and build as instructed on
> our Build Guide.")
>
> Should I do it?
Shot in the dark first, does snd_intel_dspcfg.dsp_driver=1 module
parameter help on the affected kernels? Should be easy enough to test.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fix potential context UAFs
== Series Details == Series: drm/i915: Fix potential context UAFs URL : https://patchwork.freedesktop.org/series/112383/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12541 -> Patchwork_112383v1 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_112383v1 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_112383v1, 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_112383v1/index.html Participating hosts (42 -> 41) -- Additional (1): fi-rkl-11600 Missing(2): bat-dg2-oem1 bat-atsm-1 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_112383v1: ### IGT changes ### Possible regressions * igt@debugfs_test@read_all_entries: - fi-icl-u2: [PASS][1] -> [ABORT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12541/fi-icl-u2/igt@debugfs_test@read_all_entries.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v1/fi-icl-u2/igt@debugfs_test@read_all_entries.html Known issues Here are the changes found in Patchwork_112383v1 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - fi-rkl-11600: NOTRUN -> [SKIP][3] ([i915#7456]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v1/fi-rkl-11600/igt@debugfs_t...@basic-hwmon.html * igt@gem_huc_copy@huc-copy: - fi-rkl-11600: NOTRUN -> [SKIP][4] ([i915#2190]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v1/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-rkl-11600: NOTRUN -> [SKIP][5] ([i915#4613]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v1/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html * igt@gem_tiled_pread_basic: - fi-rkl-11600: NOTRUN -> [SKIP][6] ([i915#3282]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - fi-rkl-11600: NOTRUN -> [SKIP][7] ([i915#7561]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html * igt@i915_suspend@basic-s3-without-i915: - fi-rkl-11600: NOTRUN -> [INCOMPLETE][8] ([i915#4817]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v1/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_chamelium@common-hpd-after-suspend: - bat-dg1-6: NOTRUN -> [SKIP][9] ([fdo#111827]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v1/bat-dg1-6/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_chamelium@hdmi-edid-read: - fi-rkl-11600: NOTRUN -> [SKIP][10] ([fdo#111827]) +7 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v1/fi-rkl-11600/igt@kms_chamel...@hdmi-edid-read.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor: - fi-rkl-11600: NOTRUN -> [SKIP][11] ([i915#4103]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v1/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html * igt@kms_force_connector_basic@force-load-detect: - fi-rkl-11600: NOTRUN -> [SKIP][12] ([fdo#109285] / [i915#4098]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v1/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_psr@primary_page_flip: - fi-rkl-11600: NOTRUN -> [SKIP][13] ([i915#1072]) +3 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v1/fi-rkl-11600/igt@kms_psr@primary_page_flip.html * igt@kms_setmode@basic-clone-single-crtc: - fi-rkl-11600: NOTRUN -> [SKIP][14] ([i915#3555] / [i915#4098]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v1/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html * igt@prime_vgem@basic-read: - fi-rkl-11600: NOTRUN -> [SKIP][15] ([fdo#109295] / [i915#3291] / [i915#3708]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v1/fi-rkl-11600/igt@prime_v...@basic-read.html * igt@prime_vgem@basic-userptr: - fi-rkl-11600: NOTRUN -> [SKIP][16] ([fdo#109295] / [i915#3301] / [i915#3708]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v1/fi-rkl-11600/igt@prime_v...@basic-userptr.html * igt@runner@aborted: - fi-icl-u2: NOTRUN -> [FAIL][17] ([i915#4312]) [17]:
Re: [Intel-gfx] [PATCHv7] drm/i915/dp: change aux_ctl reg read to polling read
On Wed, 21 Dec 2022, Arun R Murthy wrote: > The busy timeout logic checks for the AUX BUSY, then waits for the > timeout period and then after timeout reads the register for BUSY or > Success. > Instead replace interrupt with polling so as to read the AUX CTL > register often before the timeout period. Looks like there might be some > issue with interrupt-on-read. Hence changing the logic to polling read. > > v2: replace interrupt with polling read > v3: use usleep_rang instead of msleep, updated commit msg > v4: use intel_wait_for_regiter internal function > v5: use __intel_de_wait_for_register with 500us slow and 10ms fast timeout > v6: check return value of __intel_de_wait_for_register > v7: using default 2us for intel_de_wait_for_register > > Signed-off-by: Arun R Murthy Pushed to drm-intel-next, thanks for the patch. How about replacing the other open coded try loop in intel_dp_aux_xfer() with intel_de_wait_for_register() too? BR, Jani. > --- > drivers/gpu/drm/i915/display/intel_dp_aux.c | 14 +- > 1 file changed, 5 insertions(+), 9 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c > b/drivers/gpu/drm/i915/display/intel_dp_aux.c > index 91c93c93e5fc..5a176bfb10a2 100644 > --- a/drivers/gpu/drm/i915/display/intel_dp_aux.c > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c > @@ -41,20 +41,16 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp) > i915_reg_t ch_ctl = intel_dp->aux_ch_ctl_reg(intel_dp); > const unsigned int timeout_ms = 10; > u32 status; > - bool done; > - > -#define C (((status = intel_de_read_notrace(i915, ch_ctl)) & > DP_AUX_CH_CTL_SEND_BUSY) == 0) > - done = wait_event_timeout(i915->display.gmbus.wait_queue, C, > - msecs_to_jiffies_timeout(timeout_ms)); > + int ret; > > - /* just trace the final value */ > - trace_i915_reg_rw(false, ch_ctl, status, sizeof(status), true); > + ret = __intel_de_wait_for_register(i915, ch_ctl, > +DP_AUX_CH_CTL_SEND_BUSY, 0, > +2, timeout_ms, ); > > - if (!done) > + if (ret == -ETIMEDOUT) > drm_err(>drm, > "%s: did not complete or timeout within %ums (status > 0x%08x)\n", > intel_dp->aux.name, timeout_ms, status); > -#undef C > > return status; > } -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH] drm/i915/display: assume some pixelrate for src smaller than 1
On Wed, 04 Jan 2023, Juha-Pekka Heikkila wrote:
> intel_adjusted_rate() didn't take into account src rectangle
> can be less than 1 in width or height.
>
> Signed-off-by: Juha-Pekka Heikkila
> ---
> drivers/gpu/drm/i915/display/intel_atomic_plane.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index 10e1fc9d0698..a9948e8d3543 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -144,7 +144,7 @@ unsigned int intel_adjusted_rate(const struct drm_rect
> *src,
>const struct drm_rect *dst,
>unsigned int rate)
> {
> - unsigned int src_w, src_h, dst_w, dst_h;
> + unsigned int src_w, src_h, dst_w, dst_h, dst_wh;
>
> src_w = drm_rect_width(src) >> 16;
> src_h = drm_rect_height(src) >> 16;
> @@ -155,8 +155,10 @@ unsigned int intel_adjusted_rate(const struct drm_rect
> *src,
> dst_w = min(src_w, dst_w);
> dst_h = min(src_h, dst_h);
>
> - return DIV_ROUND_UP_ULL(mul_u32_u32(rate, src_w * src_h),
> - dst_w * dst_h);
> + /* in case src contained only fractional part */
> + dst_wh = max(dst_w * dst_h, (unsigned) 1);
The options are to use 1U or max_t(), but please don't cast the
parameters of max().
Side note, the explicit "unsigned int" is always preferred over the
implicit "unsigned".
BR,
Jani.
> +
> + return DIV_ROUND_UP_ULL(mul_u32_u32(rate, src_w * src_h), dst_wh);
> }
>
> unsigned int intel_plane_pixel_rate(const struct intel_crtc_state
> *crtc_state,
--
Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Use "%zu" to format size_t (rev2)
== Series Details ==
Series: drm/i915: Use "%zu" to format size_t (rev2)
URL : https://patchwork.freedesktop.org/series/112317/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12536 -> Patchwork_112317v2
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_112317v2 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_112317v2, 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_112317v2/index.html
Participating hosts (45 -> 43)
--
Missing(2): bat-dg2-oem1 fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_112317v2:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@guc:
- fi-kbl-soraka: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12536/fi-kbl-soraka/igt@i915_selftest@l...@guc.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112317v2/fi-kbl-soraka/igt@i915_selftest@l...@guc.html
Known issues
Here are the changes found in Patchwork_112317v2 that come from known issues:
### IGT changes ###
Issues hit
*
igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size:
- fi-bsw-kefka: [PASS][3] -> [FAIL][4] ([i915#6298])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12536/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112317v2/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
Possible fixes
* igt@i915_module_load@load:
- fi-kbl-soraka: [DMESG-WARN][5] ([i915#1982]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12536/fi-kbl-soraka/igt@i915_module_l...@load.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112317v2/fi-kbl-soraka/igt@i915_module_l...@load.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-apl-guc: [DMESG-FAIL][7] ([i915#5334]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12536/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112317v2/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
- fi-kbl-soraka: [DMESG-FAIL][9] ([i915#5334]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12536/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112317v2/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
*
igt@kms_cursor_legacy@basic-flip-before-cursor@atomic-transitions-varying-size:
- {bat-adlp-9}: [FAIL][11] ([i915#4289]) -> [PASS][12] +1 similar
issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12536/bat-adlp-9/igt@kms_cursor_legacy@basic-flip-before-cur...@atomic-transitions-varying-size.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112317v2/bat-adlp-9/igt@kms_cursor_legacy@basic-flip-before-cur...@atomic-transitions-varying-size.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#132]: https://gitlab.freedesktop.org/drm/intel/issues/132
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#3003]: https://gitlab.freedesktop.org/drm/intel/issues/3003
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#4289]: https://gitlab.freedesktop.org/drm/intel/issues/4289
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4579]: https://gitlab.freedesktop.org/drm/intel/issues/4579
[i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
[i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687
[i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
[i915#7077]: https://gitlab.freedesktop.org/drm/intel/issues/7077
Build changes
-
* Linux: CI_DRM_12536 -> Patchwork_112317v2
CI-20190529: 20190529
CI_DRM_12536: 4c18d8b1c2a1f11e99f865f60fbce9fedd3376fc @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7105: 305e8d105abf033cb850d1fb118e5cbfb6c9cd40 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_112317v2: 4c18d8b1c2a1f11e99f865f60fbce9fedd3376fc @
[Intel-gfx] [PATCH] drm/i915/display: assume some pixelrate for src smaller than 1
intel_adjusted_rate() didn't take into account src rectangle
can be less than 1 in width or height.
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/i915/display/intel_atomic_plane.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index 10e1fc9d0698..a9948e8d3543 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -144,7 +144,7 @@ unsigned int intel_adjusted_rate(const struct drm_rect *src,
const struct drm_rect *dst,
unsigned int rate)
{
- unsigned int src_w, src_h, dst_w, dst_h;
+ unsigned int src_w, src_h, dst_w, dst_h, dst_wh;
src_w = drm_rect_width(src) >> 16;
src_h = drm_rect_height(src) >> 16;
@@ -155,8 +155,10 @@ unsigned int intel_adjusted_rate(const struct drm_rect
*src,
dst_w = min(src_w, dst_w);
dst_h = min(src_h, dst_h);
- return DIV_ROUND_UP_ULL(mul_u32_u32(rate, src_w * src_h),
- dst_w * dst_h);
+ /* in case src contained only fractional part */
+ dst_wh = max(dst_w * dst_h, (unsigned) 1);
+
+ return DIV_ROUND_UP_ULL(mul_u32_u32(rate, src_w * src_h), dst_wh);
}
unsigned int intel_plane_pixel_rate(const struct intel_crtc_state *crtc_state,
--
2.37.3
Re: [Intel-gfx] [PATCH] drm/i915: Expand force_probe to block probe of devices as well.
On Tue, Jan 03, 2023 at 02:47:01PM -0500, Rodrigo Vivi wrote:
> There are new cases where we want to block i915 probe, such
> as when experimenting or developing the new Xe driver.
>
> But also, with the new hibrid cards, users or developers might
> want to use i915 only on integrated and fully block the probe
> of the i915 for the discrete. Or vice versa.
>
> Oh, and there are even older development and validation reasons,
> like when you use some distro where the modprobe.blacklist is
> not present.
>
> But in any case, let's introduce a more granular control, but without
> introducing yet another parameter, but using the existent force_probe
> one.
>
> Just by adding a ! in the begin of the id in the force_probe, like
> in this case where we would block the probe for Alder Lake:
>
> $ insmod i915.ko force_probe='!46a6'
>
> v2: Take care of '*' and '!*' cases as pointed out by
> Gustavo and Jani.
>
> Cc: Jani Nikula
> Cc: Gustavo Sousa
> Signed-off-by: Rodrigo Vivi
Acked-by: Gustavo Sousa
> ---
> drivers/gpu/drm/i915/Kconfig | 15 +++---
> drivers/gpu/drm/i915/i915_params.c | 2 +-
> drivers/gpu/drm/i915/i915_pci.c| 33 +-
> 3 files changed, 41 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 3efce05d7b57..8eb3e60aeec9 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -54,24 +54,33 @@ config DRM_I915
> If "M" is selected, the module will be called i915.
>
> config DRM_I915_FORCE_PROBE
> - string "Force probe driver for selected new Intel hardware"
> + string "Force probe i915 for selected Intel hardware IDs"
> depends on DRM_I915
> help
> This is the default value for the i915.force_probe module
> parameter. Using the module parameter overrides this option.
>
> - Force probe the driver for new Intel graphics devices that are
> + Force probe the i915 for Intel graphics devices that are
> recognized but not properly supported by this kernel version. It is
> recommended to upgrade to a kernel version with proper support as soon
> as it is available.
>
> + It can also be used to block the probe of recognized and fully
> + supported devices.
> +
> Use "" to disable force probe. If in doubt, use this.
>
> - Use "[,,...]" to force probe the driver for listed
> + Use "[,,...]" to force probe the i915 for listed
> devices. For example, "4500" or "4500,4571".
>
> Use "*" to force probe the driver for all known devices.
>
> + Use "!" right before the ID to block the probe of the device. For
> + example, "4500,!4571" forces the probe of 4500 and blocks the probe of
> + 4571.
> +
> + Use "!*" to block the probe of the driver for all known devices.
> +
> config DRM_I915_CAPTURE_ERROR
> bool "Enable capturing GPU state following a hang"
> depends on DRM_I915
> diff --git a/drivers/gpu/drm/i915/i915_params.c
> b/drivers/gpu/drm/i915/i915_params.c
> index 61578f2860cd..d634bd3f641a 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -122,7 +122,7 @@ i915_param_named_unsafe(enable_psr2_sel_fetch, bool, 0400,
> "Default: 0");
>
> i915_param_named_unsafe(force_probe, charp, 0400,
> - "Force probe the driver for specified devices. "
> + "Force probe options for specified supported devices. "
> "See CONFIG_DRM_I915_FORCE_PROBE for details.");
>
> i915_param_named_unsafe(disable_power_well, int, 0400,
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 7fd74cc28c0a..bc1af7e8f398 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -1253,7 +1253,7 @@ static void i915_pci_remove(struct pci_dev *pdev)
> }
>
> /* is device_id present in comma separated list of ids */
> -static bool force_probe(u16 device_id, const char *devices)
> +static bool device_id_in_list(u16 device_id, const char *devices, bool
> negative)
> {
> char *s, *p, *tok;
> bool ret;
> @@ -1262,7 +1262,9 @@ static bool force_probe(u16 device_id, const char
> *devices)
> return false;
>
> /* match everything */
> - if (strcmp(devices, "*") == 0)
> + if (negative && strcmp(devices, "!*") == 0)
> + return true;
> + if (!negative && strcmp(devices, "*") == 0)
> return true;
>
> s = kstrdup(devices, GFP_KERNEL);
> @@ -1272,6 +1274,12 @@ static bool force_probe(u16 device_id, const char
> *devices)
> for (p = s, ret = false; (tok = strsep(, ",")) != NULL; ) {
> u16 val;
>
> + if (negative && tok[0] == '!')
> + tok++;
> + else if ((negative && tok[0] != '!') ||
> + (!negative && tok[0] == '!'))
> +
Re: [Intel-gfx] [PATCH 07/13] drm/i915/dsb: Improve the indexed reg write checks
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Friday, December 16, 2022 6:08 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 07/13] drm/i915/dsb: Improve the indexed reg
> write checks
>
> From: Ville Syrjälä
>
> Currently intel_dsb_indexed_reg_write() just assumes the previus
Typo - previous instruction.
> instructions is also an indexed register write, and thus only checks the
> register offset. Make the check more robust by actually checking the
> instruction opcode as well.
>
> Signed-off-by: Ville Syrjälä
With the above minor fix, LGTM.
Reviewed-by: Animesh Manna
> ---
> drivers/gpu/drm/i915/display/intel_dsb.c | 21 ++---
> 1 file changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
> b/drivers/gpu/drm/i915/display/intel_dsb.c
> index fb20d9ee84a4..fcc3f49c5445 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsb.c
> +++ b/drivers/gpu/drm/i915/display/intel_dsb.c
> @@ -102,6 +102,23 @@ static void intel_dsb_emit(struct intel_dsb *dsb, u32
> ldw, u32 udw)
> buf[dsb->free_pos++] = udw;
> }
>
> +static bool intel_dsb_prev_ins_is_write(struct intel_dsb *dsb,
> + u32 opcode, i915_reg_t reg)
> +{
> + const u32 *buf = dsb->cmd_buf;
> + u32 prev_opcode, prev_reg;
> +
> + prev_opcode = buf[dsb->ins_start_offset + 1] >>
> DSB_OPCODE_SHIFT;
> + prev_reg = buf[dsb->ins_start_offset + 1] & DSB_REG_VALUE_MASK;
> +
> + return prev_opcode == opcode && prev_reg ==
> i915_mmio_reg_offset(reg);
> +}
> +
> +static bool intel_dsb_prev_ins_is_indexed_write(struct intel_dsb *dsb,
> +i915_reg_t reg) {
> + return intel_dsb_prev_ins_is_write(dsb,
> DSB_OPCODE_INDEXED_WRITE,
> +reg); }
> +
> /**
> * intel_dsb_indexed_reg_write() -Write to the DSB context for auto
> * increment register.
> @@ -119,7 +136,6 @@ void intel_dsb_indexed_reg_write(struct intel_dsb
> *dsb,
>i915_reg_t reg, u32 val)
> {
> u32 *buf = dsb->cmd_buf;
> - u32 reg_val;
>
> if (!assert_dsb_has_room(dsb))
> return;
> @@ -140,8 +156,7 @@ void intel_dsb_indexed_reg_write(struct intel_dsb
> *dsb,
>* we are writing odd no of dwords, Zeros will be added in the end
> for
>* padding.
>*/
> - reg_val = buf[dsb->ins_start_offset + 1] & DSB_REG_VALUE_MASK;
> - if (reg_val != i915_mmio_reg_offset(reg)) {
> + if (!intel_dsb_prev_ins_is_indexed_write(dsb, reg)) {
> /* Every instruction should be 8 byte aligned. */
> dsb->free_pos = ALIGN(dsb->free_pos, 2);
>
> --
> 2.37.4
Re: [Intel-gfx] [PATCH 06/13] drm/i915/dsb: Extract intel_dsb_emit()
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Friday, December 16, 2022 6:08 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 06/13] drm/i915/dsb: Extract intel_dsb_emit()
>
> From: Ville Syrjälä
LGTM.
Reviewed-by: Animesh Manna
>
> Extract a small helper to emit a DSB intstruction. Should become useful
> if/when we need to start emitting other instructions besides register writes.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_dsb.c | 30
> 1 file changed, 20 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
> b/drivers/gpu/drm/i915/display/intel_dsb.c
> index 6fc7d087a7ca..fb20d9ee84a4 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsb.c
> +++ b/drivers/gpu/drm/i915/display/intel_dsb.c
> @@ -86,6 +86,22 @@ static bool is_dsb_busy(struct drm_i915_private *i915,
> enum pipe pipe,
> return intel_de_read(i915, DSB_CTRL(pipe, id)) & DSB_STATUS_BUSY;
> }
>
> +static void intel_dsb_emit(struct intel_dsb *dsb, u32 ldw, u32 udw) {
> + u32 *buf = dsb->cmd_buf;
> +
> + if (!assert_dsb_has_room(dsb))
> + return;
> +
> + /* Every instruction should be 8 byte aligned. */
> + dsb->free_pos = ALIGN(dsb->free_pos, 2);
> +
> + dsb->ins_start_offset = dsb->free_pos;
> +
> + buf[dsb->free_pos++] = ldw;
> + buf[dsb->free_pos++] = udw;
> +}
> +
> /**
> * intel_dsb_indexed_reg_write() -Write to the DSB context for auto
> * increment register.
> @@ -169,19 +185,13 @@ void intel_dsb_indexed_reg_write(struct intel_dsb
> *dsb, void intel_dsb_reg_write(struct intel_dsb *dsb,
>i915_reg_t reg, u32 val)
> {
> - u32 *buf = dsb->cmd_buf;
> -
> if (!assert_dsb_has_room(dsb))
> return;
>
> - /* Every instruction should be 8 byte aligned. */
> - dsb->free_pos = ALIGN(dsb->free_pos, 2);
> -
> - dsb->ins_start_offset = dsb->free_pos;
> - buf[dsb->free_pos++] = val;
> - buf[dsb->free_pos++] = (DSB_OPCODE_MMIO_WRITE <<
> DSB_OPCODE_SHIFT) |
> -(DSB_BYTE_EN << DSB_BYTE_EN_SHIFT) |
> -i915_mmio_reg_offset(reg);
> + intel_dsb_emit(dsb, val,
> +(DSB_OPCODE_MMIO_WRITE << DSB_OPCODE_SHIFT) |
> +(DSB_BYTE_EN << DSB_BYTE_EN_SHIFT) |
> +i915_mmio_reg_offset(reg));
> }
>
> /**
> --
> 2.37.4
Re: [Intel-gfx] [PATCH 05/13] drm/i915/dsb: Extract assert_dsb_has_room()
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Friday, December 16, 2022 6:08 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 05/13] drm/i915/dsb: Extract
> assert_dsb_has_room()
>
> From: Ville Syrjälä
>
> Pull the DSB command buffer size checks into a small helper so we don't
> have repeat the same thing multiple times.
>
> Signed-off-by: Ville Syrjälä
LGTM.
Reviewed-by: Animesh Manna
> ---
> drivers/gpu/drm/i915/display/intel_dsb.c | 22 --
> 1 file changed, 12 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
> b/drivers/gpu/drm/i915/display/intel_dsb.c
> index fbcbf9efd039..6fc7d087a7ca 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsb.c
> +++ b/drivers/gpu/drm/i915/display/intel_dsb.c
> @@ -70,6 +70,16 @@ struct intel_dsb {
> #define DSB_BYTE_EN_SHIFT20
> #define DSB_REG_VALUE_MASK 0xf
>
> +static bool assert_dsb_has_room(struct intel_dsb *dsb) {
> + struct intel_crtc *crtc = dsb->crtc;
> + struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> +
> + /* each instruction is 2 dwords */
> + return !drm_WARN(>drm, ALIGN(dsb->free_pos, 2) >
> DSB_BUF_SIZE / 4 - 2,
> + "DSB buffer overflow\n");
> +}
> +
> static bool is_dsb_busy(struct drm_i915_private *i915, enum pipe pipe,
> enum dsb_id id)
> {
> @@ -92,15 +102,11 @@ static bool is_dsb_busy(struct drm_i915_private
> *i915, enum pipe pipe, void intel_dsb_indexed_reg_write(struct intel_dsb
> *dsb,
>i915_reg_t reg, u32 val)
> {
> - struct intel_crtc *crtc = dsb->crtc;
> - struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> u32 *buf = dsb->cmd_buf;
> u32 reg_val;
>
> - if (drm_WARN_ON(_priv->drm, ALIGN(dsb->free_pos, 2) >
> DSB_BUF_SIZE / 4 - 2)) {
> - drm_dbg_kms(_priv->drm, "DSB buffer overflow\n");
> + if (!assert_dsb_has_room(dsb))
> return;
> - }
>
> /*
>* For example the buffer will look like below for 3 dwords for auto
> @@ -163,14 +169,10 @@ void intel_dsb_indexed_reg_write(struct intel_dsb
> *dsb, void intel_dsb_reg_write(struct intel_dsb *dsb,
>i915_reg_t reg, u32 val)
> {
> - struct intel_crtc *crtc = dsb->crtc;
> - struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> u32 *buf = dsb->cmd_buf;
>
> - if (drm_WARN_ON(_priv->drm, ALIGN(dsb->free_pos, 2) >
> DSB_BUF_SIZE / 4 - 2)) {
> - drm_dbg_kms(_priv->drm, "DSB buffer overflow\n");
> + if (!assert_dsb_has_room(dsb))
> return;
> - }
>
> /* Every instruction should be 8 byte aligned. */
> dsb->free_pos = ALIGN(dsb->free_pos, 2);
> --
> 2.37.4
Re: [Intel-gfx] [PULL] gvt-fixes
On Wed, Jan 04, 2023 at 04:05:13PM +0800, Zhenyu Wang wrote: > > Hi, > > Here's accumulated current gvt-fixes. Several of them handle > for error or destroy path issues and one from Zhi to fix up > left vgpu status tracking. > > thanks! > --- > The following changes since commit 6217e9f05a74df48c77ee68993d587cdfdb1feb7: I'm kind of confused on your baseline here. It is including a strange merge commit in the middle of the commits: Zhenyu Wang │ M─┐ Merge tag 'drm-intel-fixes-2022-12-30' into gvt-fixes commit c063c8c07864246ba3831b017cea8d3096e236a8 Please rebase on top of v6.2-rc2 so we have the same base here. (and please remind to sign-off-by when pushing the commits) > > drm/i915/dsi: fix MIPI_BKLT_EN_1 native GPIO index (2022-12-30 04:28:46 > -0500) > > are available in the Git repository at: > > https://github.com/intel/gvt-linux.git tags/gvt-fixes-2023-01-04 > > for you to fetch changes up to 601fd0f6b2a4c776a21ab8300fe0de0726937623: > > drm/i915/gvt: fix double free bug in split_2MB_gtt_entry (2023-01-04 > 15:20:09 +0800) > > > gvt-fixes-2023-01-04 > > - Fix one missed unpin in error of intel_vgpu_shadow_mm_pin() > - Fix two debugfs destroy oops issues for vgpu and gvt entries > - Fix one potential double free issue in gtt shadow pt code > - Fix to use atomic bit flag for vgpu status > > > Dan Carpenter (1): > drm/i915: unpin on error in intel_vgpu_shadow_mm_pin() > > Zheng Wang (1): > drm/i915/gvt: fix double free bug in split_2MB_gtt_entry > > Zhenyu Wang (3): > drm/i915/gvt: fix gvt debugfs destroy > drm/i915/gvt: fix vgpu debugfs clean in remove > Merge tag 'drm-intel-fixes-2022-12-30' into gvt-fixes > > Zhi Wang (1): > drm/i915/gvt: use atomic operations to change the vGPU status > > drivers/gpu/drm/i915/gvt/debugfs.c | 36 > +++- > drivers/gpu/drm/i915/gvt/dmabuf.c| 3 ++- > drivers/gpu/drm/i915/gvt/gtt.c | 21 +++-- > drivers/gpu/drm/i915/gvt/gvt.h | 15 ++- > drivers/gpu/drm/i915/gvt/interrupt.c | 2 +- > drivers/gpu/drm/i915/gvt/kvmgt.c | 35 +-- > drivers/gpu/drm/i915/gvt/scheduler.c | 4 +++- > drivers/gpu/drm/i915/gvt/vgpu.c | 12 +--- > 8 files changed, 80 insertions(+), 48 deletions(-)
Re: [Intel-gfx] [PATCH v5 5/7] drm/i915/hdcp: Fill wired_cmd_in structures at a single place
On Wed, Jan 04, 2023 at 10:14:54AM +, Tvrtko Ursulin wrote:
>
> On 04/01/2023 09:53, Jani Nikula wrote:
> > On Mon, 02 Jan 2023, Suraj Kandpal wrote:
> > > Need to fill wired cmd in structures at a single place as they remain
> > > same for both gsc and mei.
> >
> > I'm still opposed to adding this stuff to i915 and exporting the
> > symbols. Seems like it should be a separate component, because this is
> > not about i915.
> >
> > Cc: other maintainers, please chime in.
> >
> > > --v3
> > > -remove inline function from header [Jani]
> > >
> > > Cc: Ankit Nautiyal
> > > Signed-off-by: Suraj Kandpal
> > > ---
> > > drivers/gpu/drm/i915/Makefile | 1 +
> > > drivers/gpu/drm/i915/i915_hdcp_interface.c | 216 +
> > > drivers/misc/mei/hdcp/mei_hdcp.c | 153 ++-
> > > include/drm/i915_hdcp_interface.h | 39
> > > 4 files changed, 270 insertions(+), 139 deletions(-)
> > > create mode 100644 drivers/gpu/drm/i915/i915_hdcp_interface.c
> > >
> > > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> > > index 461d6b40656d..c6a9826af58d 100644
> > > --- a/drivers/gpu/drm/i915/Makefile
> > > +++ b/drivers/gpu/drm/i915/Makefile
> > > @@ -36,6 +36,7 @@ i915-y += i915_driver.o \
> > > i915_drm_client.o \
> > > i915_config.o \
> > > i915_getparam.o \
> > > + i915_hdcp_interface.o\
> > > i915_ioctl.o \
> > > i915_irq.o \
> > > i915_mitigations.o \
> > > diff --git a/drivers/gpu/drm/i915/i915_hdcp_interface.c
> > > b/drivers/gpu/drm/i915/i915_hdcp_interface.c
> > > new file mode 100644
> > > index ..e6b787c2fa50
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/i915/i915_hdcp_interface.c
> > > @@ -0,0 +1,216 @@
> > > +// SPDX-License-Identifier: MIT
> > > +/*
> > > + * Copyright 2022, Intel Corporation.
> > > + */
> > > +
> > > +#include
> > > +
> > > +void
> > > +i915_hdcp_fill_session_in(struct wired_cmd_initiate_hdcp2_session_in
> > > *session_init_in,
> > > + struct hdcp_port_data *data)
> > > +{
> > > + session_init_in->header.api_version = HDCP_API_VERSION;
> > > + session_init_in->header.command_id = WIRED_INITIATE_HDCP2_SESSION;
> > > + session_init_in->header.status = FW_HDCP_STATUS_SUCCESS;
> > > + session_init_in->header.buffer_len =
> > > + WIRED_CMD_BUF_LEN_INITIATE_HDCP2_SESSION_IN;
> > > +
> > > + session_init_in->port.integrated_port_type = data->port_type;
> > > + session_init_in->port.physical_port = (u8)data->hdcp_ddi;
> > > + session_init_in->port.attached_transcoder = (u8)data->hdcp_transcoder;
> > > + session_init_in->protocol = data->protocol;
> > > +}
> > > +EXPORT_SYMBOL(i915_hdcp_fill_session_in);
>
> I am not familiar enough with the problem space but this kind of trivial
> exported symbols definitely do not look like the best choice.
>
> Presumably there are two kernel modules dealing with this HDCP protocol in
> which case would creating a kernel module like intel_hdcp, which would
> establish the protocol definitions and API to use it. I915 and any other
> module would then depend on that module and use it.
>
> Presumably this is what Jani meant actually and that sounds like the exactly
> right direction to me. I just don't know enough about the scope of the
> protocol to propose anything more specific.
I'm also in favor of the separated module here. Eventually we will have to
use it in the new Xe driver as well.
>
> Regards,
>
> Tvrtko
>
> > > +
> > > +void
> > > +i915_hdcp_fill_rxcert_in(struct wired_cmd_verify_receiver_cert_in
> > > *verify_rxcert_in,
> > > + struct hdcp2_ake_send_cert *rx_cert,
> > > + struct hdcp_port_data *data)
> > > +{
> > > + verify_rxcert_in->header.api_version = HDCP_API_VERSION;
> > > + verify_rxcert_in->header.command_id = WIRED_VERIFY_RECEIVER_CERT;
> > > + verify_rxcert_in->header.status = FW_HDCP_STATUS_SUCCESS;
> > > + verify_rxcert_in->header.buffer_len =
> > > + WIRED_CMD_BUF_LEN_VERIFY_RECEIVER_CERT_IN;
> > > +
> > > + verify_rxcert_in->port.integrated_port_type = data->port_type;
> > > + verify_rxcert_in->port.physical_port = (u8)data->hdcp_ddi;
> > > + verify_rxcert_in->port.attached_transcoder = (u8)data->hdcp_transcoder;
> > > +
> > > + verify_rxcert_in->cert_rx = rx_cert->cert_rx;
> > > + memcpy(verify_rxcert_in->r_rx, _cert->r_rx, HDCP_2_2_RRX_LEN);
> > > + memcpy(verify_rxcert_in->rx_caps, rx_cert->rx_caps,
> > > HDCP_2_2_RXCAPS_LEN);
> > > +}
> > > +EXPORT_SYMBOL(i915_hdcp_fill_rxcert_in);
> > > +
> > > +void
> > > +i915_hdcp_fill_hprime_in(struct wired_cmd_ake_send_hprime_in
> > > *send_hprime_in,
> > > + struct hdcp2_ake_send_hprime *rx_hprime,
> > > + struct hdcp_port_data *data)
> > > +{
> > > + send_hprime_in->header.api_version = HDCP_API_VERSION;
> > > + send_hprime_in->header.command_id =
Re: [Intel-gfx] [PATCH 04/13] drm/i915/dsb: Fix DSB command buffer size checks
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Friday, December 16, 2022 6:08 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 04/13] drm/i915/dsb: Fix DSB command buffer
> size checks
>
> From: Ville Syrjälä
>
> free_pos is in dwords, DSB_BUF_SIZE in bytes. Directly comparing the two is
> nonsense. Fix it up, and make sure we also account for the 8byte alignment
> requirement for each instruction, and also assume that each instruction
> normally eats two dwords.
>
> Signed-off-by: Ville Syrjälä
LGTM.
Reviewed-by: Animesh Manna
> ---
> drivers/gpu/drm/i915/display/intel_dsb.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
> b/drivers/gpu/drm/i915/display/intel_dsb.c
> index 6abfd0fc541a..fbcbf9efd039 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsb.c
> +++ b/drivers/gpu/drm/i915/display/intel_dsb.c
> @@ -97,7 +97,7 @@ void intel_dsb_indexed_reg_write(struct intel_dsb
> *dsb,
> u32 *buf = dsb->cmd_buf;
> u32 reg_val;
>
> - if (drm_WARN_ON(_priv->drm, dsb->free_pos >=
> DSB_BUF_SIZE)) {
> + if (drm_WARN_ON(_priv->drm, ALIGN(dsb->free_pos, 2) >
> DSB_BUF_SIZE
> +/ 4 - 2)) {
> drm_dbg_kms(_priv->drm, "DSB buffer overflow\n");
> return;
> }
> @@ -167,7 +167,7 @@ void intel_dsb_reg_write(struct intel_dsb *dsb,
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> u32 *buf = dsb->cmd_buf;
>
> - if (drm_WARN_ON(_priv->drm, dsb->free_pos >=
> DSB_BUF_SIZE)) {
> + if (drm_WARN_ON(_priv->drm, ALIGN(dsb->free_pos, 2) >
> DSB_BUF_SIZE
> +/ 4 - 2)) {
> drm_dbg_kms(_priv->drm, "DSB buffer overflow\n");
> return;
> }
> --
> 2.37.4
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/edid: info & modes parsing and drm_edid refactors
== Series Details == Series: drm/edid: info & modes parsing and drm_edid refactors URL : https://patchwork.freedesktop.org/series/112392/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12541 -> Patchwork_112392v1 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_112392v1 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_112392v1, 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_112392v1/index.html Participating hosts (42 -> 42) -- Additional (1): fi-rkl-11600 Missing(1): bat-dg2-oem1 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_112392v1: ### IGT changes ### Possible regressions * igt@debugfs_test@read_all_entries: - fi-icl-u2: [PASS][1] -> [ABORT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12541/fi-icl-u2/igt@debugfs_test@read_all_entries.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112392v1/fi-icl-u2/igt@debugfs_test@read_all_entries.html Known issues Here are the changes found in Patchwork_112392v1 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - fi-rkl-11600: NOTRUN -> [SKIP][3] ([i915#7456]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112392v1/fi-rkl-11600/igt@debugfs_t...@basic-hwmon.html * igt@gem_huc_copy@huc-copy: - fi-rkl-11600: NOTRUN -> [SKIP][4] ([i915#2190]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112392v1/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-rkl-11600: NOTRUN -> [SKIP][5] ([i915#4613]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112392v1/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html * igt@gem_tiled_pread_basic: - fi-rkl-11600: NOTRUN -> [SKIP][6] ([i915#3282]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112392v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - fi-rkl-11600: NOTRUN -> [SKIP][7] ([i915#7561]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112392v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html * igt@i915_selftest@live@migrate: - bat-adlp-4: [PASS][8] -> [DMESG-FAIL][9] ([i915#7699]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12541/bat-adlp-4/igt@i915_selftest@l...@migrate.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112392v1/bat-adlp-4/igt@i915_selftest@l...@migrate.html * igt@i915_suspend@basic-s3-without-i915: - fi-rkl-11600: NOTRUN -> [INCOMPLETE][10] ([i915#4817]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112392v1/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_chamelium@common-hpd-after-suspend: - bat-dg1-6: NOTRUN -> [SKIP][11] ([fdo#111827]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112392v1/bat-dg1-6/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_chamelium@hdmi-edid-read: - fi-rkl-11600: NOTRUN -> [SKIP][12] ([fdo#111827]) +7 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112392v1/fi-rkl-11600/igt@kms_chamel...@hdmi-edid-read.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor: - fi-rkl-11600: NOTRUN -> [SKIP][13] ([i915#4103]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112392v1/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html * igt@kms_force_connector_basic@force-load-detect: - fi-rkl-11600: NOTRUN -> [SKIP][14] ([fdo#109285] / [i915#4098]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112392v1/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_psr@primary_page_flip: - fi-rkl-11600: NOTRUN -> [SKIP][15] ([i915#1072]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112392v1/fi-rkl-11600/igt@kms_psr@primary_page_flip.html * igt@kms_setmode@basic-clone-single-crtc: - fi-rkl-11600: NOTRUN -> [SKIP][16] ([i915#3555] / [i915#4098]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112392v1/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html * igt@prime_vgem@basic-read: - fi-rkl-11600: NOTRUN -> [SKIP][17] ([fdo#109295] / [i915#3291] / [i915#3708]) +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112392v1/fi-rkl-11600/igt@prime_v...@basic-read.html * igt@prime_vgem@basic-userptr: - fi-rkl-11600: NOTRUN -> [SKIP][18]
[Intel-gfx] [PATCH i-g-t v4] tests/i915/gem_ppgtt: verify GTT eviction with contended locks
We should still be able to GTT evict objects during execbuf (old
bindings can linger around), even if there is object lock contention. In
the worst case the execbuf should just wait on the contented locks.
Returning -ENOSPC smells like a regression from past behaviour, and
seems to break userspace.
v2:
- Add coverage for explicit softpin
- Add timeout for the spinner
v3:
- Improve the test description
v4: (Nirmoy)
- We only need one handle2
- Prefer NSEC_PER_SEC
References: https://gitlab.freedesktop.org/drm/intel/-/issues/7570
Signed-off-by: Matthew Auld
Cc: Andrzej Hajda
Cc: Nirmoy Das
Cc: Mani Milani
Reviewed-by: Nirmoy Das
---
tests/i915/gem_ppgtt.c | 133 +
1 file changed, 133 insertions(+)
diff --git a/tests/i915/gem_ppgtt.c b/tests/i915/gem_ppgtt.c
index 9673ce22..ca09f089 100644
--- a/tests/i915/gem_ppgtt.c
+++ b/tests/i915/gem_ppgtt.c
@@ -255,6 +255,131 @@ static void flink_and_close(void)
close(fd2);
}
+#define PAGE_SIZE 4096
+
+static uint32_t batch_create_size(int fd, uint64_t size)
+{
+ const uint32_t bbe = MI_BATCH_BUFFER_END;
+ uint32_t handle;
+
+ handle = gem_create(fd, size);
+ gem_write(fd, handle, 0, , sizeof(bbe));
+
+ return handle;
+}
+
+#define IGT_USE_ANY0x1
+#define IGT_USE_PINNED 0x2
+static void upload(int fd, uint32_t handle, uint32_t in_fence, uint32_t ctx_id,
+ unsigned int flags)
+{
+ struct drm_i915_gem_exec_object2 exec[2] = {};
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(),
+ .buffer_count = 1,
+ .rsvd1 = ctx_id,
+ };
+
+ if (in_fence) {
+ execbuf.rsvd2 = in_fence;
+ execbuf.flags = I915_EXEC_FENCE_IN;
+ }
+
+ exec[0].handle = handle;
+ exec[0].flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
+
+ if (flags & IGT_USE_PINNED)
+ exec[0].flags |= EXEC_OBJECT_PINNED; /* offset = 0 */
+
+ if (flags & IGT_USE_ANY) {
+ exec[0].flags |= EXEC_OBJECT_PAD_TO_SIZE;
+ exec[0].pad_to_size = gem_aperture_size(fd);
+ }
+
+ gem_execbuf(fd, );
+}
+
+static void shrink_vs_evict(unsigned int flags)
+{
+ const unsigned int nproc = sysconf(_SC_NPROCESSORS_ONLN) + 1;
+ const uint64_t timeout_5s = 5LL * NSEC_PER_SEC;
+ int fd = drm_open_driver(DRIVER_INTEL);
+ uint64_t ahnd = get_reloc_ahnd(fd, 0);
+ const intel_ctx_t *ctx_arr[nproc];
+ igt_spin_t *spinner;
+ uint32_t handle1;
+ int i;
+
+ /*
+* Try to simulate some nasty object lock contention during GTT
+* eviction. Create a BO and bind across several different VMs. Invoke
+* the shrinker on that shared BO, followed by triggering GTT eviction
+* across all VMs. Both require the object lock to make forward
+* progress when trying to unbind the BO, but the shrinker will be
+* blocked by the spinner (until killed). Once the spinner is killed
+* the shrinker should be able to unbind the object and drop the object
+* lock, and GTT eviction should eventually succeed. At no point should
+* we see -ENOSPC from the execbuf, even if we can't currently grab the
+* object lock.
+*/
+
+ igt_require(gem_uses_full_ppgtt(fd));
+
+ igt_drop_caches_set(fd, DROP_ALL);
+
+ handle1 = gem_create(fd, PAGE_SIZE);
+
+ spinner = igt_spin_new(fd,
+ .ahnd = ahnd,
+ .flags = IGT_SPIN_FENCE_OUT);
+ igt_spin_set_timeout(spinner, timeout_5s);
+
+ /*
+* Create several VMs to ensure we don't block on the same vm lock. The
+* goal of the test is to ensure that object lock contention doesn't
+* somehow result in -ENOSPC from execbuf, if we need to trigger GTT
+* eviction.
+*/
+ for (i = 0; i < nproc; i++) {
+ ctx_arr[i] = intel_ctx_create(fd, NULL);
+
+ upload(fd, handle1, spinner->execbuf.rsvd2 >> 32,
+ ctx_arr[i]->id, flags);
+ }
+
+ igt_fork(child, 1)
+ igt_drop_caches_set(fd, DROP_ALL);
+
+ sleep(2); /* Give the shrinker time to find handle1 */
+
+ igt_fork(child, nproc) {
+ uint32_t handle2;
+
+ /*
+* One of these forks will be stuck on the vm mutex, since the
+* shrinker is holding it (along with the object lock) while
+* trying to unbind the chosen vma, but is blocked by the
+* spinner. The rest should only block waiting to grab the
+* object lock for handle1, before then trying to GTT evict it
+* from their respective vm. In either case the contention of
+* the vm->mutex or object lock should never result in -ENOSPC
+* or some other
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/edid: info & modes parsing and drm_edid refactors
== Series Details == Series: drm/edid: info & modes parsing and drm_edid refactors URL : https://patchwork.freedesktop.org/series/112392/ 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 v5 5/7] drm/i915/hdcp: Fill wired_cmd_in structures at a single place
On 04/01/2023 09:53, Jani Nikula wrote:
On Mon, 02 Jan 2023, Suraj Kandpal wrote:
Need to fill wired cmd in structures at a single place as they remain
same for both gsc and mei.
I'm still opposed to adding this stuff to i915 and exporting the
symbols. Seems like it should be a separate component, because this is
not about i915.
Cc: other maintainers, please chime in.
--v3
-remove inline function from header [Jani]
Cc: Ankit Nautiyal
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_hdcp_interface.c | 216 +
drivers/misc/mei/hdcp/mei_hdcp.c | 153 ++-
include/drm/i915_hdcp_interface.h | 39
4 files changed, 270 insertions(+), 139 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_hdcp_interface.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 461d6b40656d..c6a9826af58d 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -36,6 +36,7 @@ i915-y += i915_driver.o \
i915_drm_client.o \
i915_config.o \
i915_getparam.o \
+ i915_hdcp_interface.o\
i915_ioctl.o \
i915_irq.o \
i915_mitigations.o \
diff --git a/drivers/gpu/drm/i915/i915_hdcp_interface.c
b/drivers/gpu/drm/i915/i915_hdcp_interface.c
new file mode 100644
index ..e6b787c2fa50
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_hdcp_interface.c
@@ -0,0 +1,216 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright 2022, Intel Corporation.
+ */
+
+#include
+
+void
+i915_hdcp_fill_session_in(struct wired_cmd_initiate_hdcp2_session_in
*session_init_in,
+ struct hdcp_port_data *data)
+{
+ session_init_in->header.api_version = HDCP_API_VERSION;
+ session_init_in->header.command_id = WIRED_INITIATE_HDCP2_SESSION;
+ session_init_in->header.status = FW_HDCP_STATUS_SUCCESS;
+ session_init_in->header.buffer_len =
+ WIRED_CMD_BUF_LEN_INITIATE_HDCP2_SESSION_IN;
+
+ session_init_in->port.integrated_port_type = data->port_type;
+ session_init_in->port.physical_port = (u8)data->hdcp_ddi;
+ session_init_in->port.attached_transcoder = (u8)data->hdcp_transcoder;
+ session_init_in->protocol = data->protocol;
+}
+EXPORT_SYMBOL(i915_hdcp_fill_session_in);
I am not familiar enough with the problem space but this kind of trivial
exported symbols definitely do not look like the best choice.
Presumably there are two kernel modules dealing with this HDCP protocol
in which case would creating a kernel module like intel_hdcp, which
would establish the protocol definitions and API to use it. I915 and any
other module would then depend on that module and use it.
Presumably this is what Jani meant actually and that sounds like the
exactly right direction to me. I just don't know enough about the scope
of the protocol to propose anything more specific.
Regards,
Tvrtko
+
+void
+i915_hdcp_fill_rxcert_in(struct wired_cmd_verify_receiver_cert_in
*verify_rxcert_in,
+struct hdcp2_ake_send_cert *rx_cert,
+struct hdcp_port_data *data)
+{
+ verify_rxcert_in->header.api_version = HDCP_API_VERSION;
+ verify_rxcert_in->header.command_id = WIRED_VERIFY_RECEIVER_CERT;
+ verify_rxcert_in->header.status = FW_HDCP_STATUS_SUCCESS;
+ verify_rxcert_in->header.buffer_len =
+ WIRED_CMD_BUF_LEN_VERIFY_RECEIVER_CERT_IN;
+
+ verify_rxcert_in->port.integrated_port_type = data->port_type;
+ verify_rxcert_in->port.physical_port = (u8)data->hdcp_ddi;
+ verify_rxcert_in->port.attached_transcoder = (u8)data->hdcp_transcoder;
+
+ verify_rxcert_in->cert_rx = rx_cert->cert_rx;
+ memcpy(verify_rxcert_in->r_rx, _cert->r_rx, HDCP_2_2_RRX_LEN);
+ memcpy(verify_rxcert_in->rx_caps, rx_cert->rx_caps,
HDCP_2_2_RXCAPS_LEN);
+}
+EXPORT_SYMBOL(i915_hdcp_fill_rxcert_in);
+
+void
+i915_hdcp_fill_hprime_in(struct wired_cmd_ake_send_hprime_in *send_hprime_in,
+struct hdcp2_ake_send_hprime *rx_hprime,
+struct hdcp_port_data *data)
+{
+ send_hprime_in->header.api_version = HDCP_API_VERSION;
+ send_hprime_in->header.command_id = WIRED_AKE_SEND_HPRIME;
+ send_hprime_in->header.status = FW_HDCP_STATUS_SUCCESS;
+ send_hprime_in->header.buffer_len =
WIRED_CMD_BUF_LEN_AKE_SEND_HPRIME_IN;
+
+ send_hprime_in->port.integrated_port_type = data->port_type;
+ send_hprime_in->port.physical_port = (u8)data->hdcp_ddi;
+ send_hprime_in->port.attached_transcoder = (u8)data->hdcp_transcoder;
+
+ memcpy(send_hprime_in->h_prime, rx_hprime->h_prime,
+ HDCP_2_2_H_PRIME_LEN);
+}
+EXPORT_SYMBOL(i915_hdcp_fill_hprime_in);
+
+void
+i915_hdcp_fill_pairing_info_in(struct wired_cmd_ake_send_pairing_info_in
Re: [Intel-gfx] [PATCH 1/2] drm/i915/display/core: use intel_de_rmw if possible
On Tue, 20 Dec 2022, Andrzej Hajda wrote:
> The helper makes the code more compact and readable.
>
> Signed-off-by: Andrzej Hajda
> ---
> Hi all,
>
> This is the last patchset converting different flavours
> of register updates to intel_de_rmw. There are probably
> still some remnants, which would require functional changes
> to allow conversion. They would need probably more individual
> approach.
>
> Jani, thank you for reviews.
>
> And the final diffstat for all patches:
> 26 files changed, 425 insertions(+), 952 deletions(-)
I think this is doing too much per patch. Please just chop it up a bit,
if only for the sake of the reviewer.
BR,
Jani.
>
> Regards
> Andrzej
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 22 +--
> .../drm/i915/display/intel_display_power.c| 49 ++
> .../i915/display/intel_display_power_well.c | 82 +++--
> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 165 ++
> .../drm/i915/display/intel_modeset_setup.c| 17 +-
> 5 files changed, 108 insertions(+), 227 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index e75b9b2a0e015a..c6c566a6572b8b 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -293,11 +293,11 @@ static void
> skl_wa_827(struct drm_i915_private *dev_priv, enum pipe pipe, bool enable)
> {
> if (enable)
> - intel_de_write(dev_priv, CLKGATE_DIS_PSL(pipe),
> -intel_de_read(dev_priv, CLKGATE_DIS_PSL(pipe)) |
> DUPS1_GATING_DIS | DUPS2_GATING_DIS);
> + intel_de_rmw(dev_priv, CLKGATE_DIS_PSL(pipe),
> + 0, DUPS1_GATING_DIS | DUPS2_GATING_DIS);
> else
> - intel_de_write(dev_priv, CLKGATE_DIS_PSL(pipe),
> -intel_de_read(dev_priv, CLKGATE_DIS_PSL(pipe)) &
> ~(DUPS1_GATING_DIS | DUPS2_GATING_DIS));
> + intel_de_rmw(dev_priv, CLKGATE_DIS_PSL(pipe),
> + DUPS1_GATING_DIS | DUPS2_GATING_DIS, 0);
> }
>
> /* Wa_2006604312:icl,ehl */
> @@ -306,11 +306,9 @@ icl_wa_scalerclkgating(struct drm_i915_private
> *dev_priv, enum pipe pipe,
> bool enable)
> {
> if (enable)
> - intel_de_write(dev_priv, CLKGATE_DIS_PSL(pipe),
> -intel_de_read(dev_priv, CLKGATE_DIS_PSL(pipe)) |
> DPFR_GATING_DIS);
> + intel_de_rmw(dev_priv, CLKGATE_DIS_PSL(pipe), 0,
> DPFR_GATING_DIS);
> else
> - intel_de_write(dev_priv, CLKGATE_DIS_PSL(pipe),
> -intel_de_read(dev_priv, CLKGATE_DIS_PSL(pipe)) &
> ~DPFR_GATING_DIS);
> + intel_de_rmw(dev_priv, CLKGATE_DIS_PSL(pipe), DPFR_GATING_DIS,
> 0);
> }
>
> /* Wa_1604331009:icl,jsl,ehl */
> @@ -1852,12 +1850,10 @@ static void hsw_set_frame_start_delay(const struct
> intel_crtc_state *crtc_state)
> enum transcoder transcoder = crtc_state->cpu_transcoder;
> i915_reg_t reg = DISPLAY_VER(dev_priv) >= 14 ?
> MTL_CHICKEN_TRANS(transcoder) :
>CHICKEN_TRANS(transcoder);
> - u32 val;
>
> - val = intel_de_read(dev_priv, reg);
> - val &= ~HSW_FRAME_START_DELAY_MASK;
> - val |= HSW_FRAME_START_DELAY(crtc_state->framestart_delay - 1);
> - intel_de_write(dev_priv, reg, val);
> + intel_de_rmw(dev_priv, reg,
> + HSW_FRAME_START_DELAY_MASK,
> + HSW_FRAME_START_DELAY(crtc_state->framestart_delay - 1));
> }
>
> static void icl_ddi_bigjoiner_pre_enable(struct intel_atomic_state *state,
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 1a23ecd4623a53..90d7a623d6e3cc 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -1260,9 +1260,7 @@ static void hsw_disable_lcpll(struct drm_i915_private
> *dev_priv,
> drm_err(_priv->drm, "D_COMP RCOMP still in progress\n");
>
> if (allow_power_down) {
> - val = intel_de_read(dev_priv, LCPLL_CTL);
> - val |= LCPLL_POWER_DOWN_ALLOW;
> - intel_de_write(dev_priv, LCPLL_CTL, val);
> + intel_de_rmw(dev_priv, LCPLL_CTL, 0, LCPLL_POWER_DOWN_ALLOW);
> intel_de_posting_read(dev_priv, LCPLL_CTL);
> }
> }
> @@ -1306,9 +1304,7 @@ static void hsw_restore_lcpll(struct drm_i915_private
> *dev_priv)
> drm_err(_priv->drm, "LCPLL not locked yet\n");
>
> if (val & LCPLL_CD_SOURCE_FCLK) {
> - val = intel_de_read(dev_priv, LCPLL_CTL);
> - val &= ~LCPLL_CD_SOURCE_FCLK;
> - intel_de_write(dev_priv, LCPLL_CTL, val);
> + intel_de_rmw(dev_priv, LCPLL_CTL, LCPLL_CD_SOURCE_FCLK, 0);
>
> if (wait_for_us((intel_de_read(dev_priv, LCPLL_CTL) &
>
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Consolidate TLB invalidation flow
On 03/01/2023 19:57, Matt Roper wrote:
On Mon, Dec 19, 2022 at 05:10:02PM +0100, Andrzej Hajda wrote:
On 19.12.2022 11:13, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
As the logic for selecting the register and corresponsing values grew, the
corresponding
code become a bit unsightly. Consolidate by storing the required values at
engine init time in the engine itself, and by doing so minimise the amount
of invariant platform and engine checks during each and every TLB
invalidation.
v2:
* Fail engine probe if TLB invlidations registers are unknown.
Signed-off-by: Tvrtko Ursulin
Cc: Andrzej Hajda
Cc: Matt Roper
Reviewed-by: Andrzej Hajda # v1
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 93 +
drivers/gpu/drm/i915/gt/intel_engine_types.h | 15 +++
drivers/gpu/drm/i915/gt/intel_gt.c | 135 +++
3 files changed, 128 insertions(+), 115 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 99c4b866addd..d47dadfc25c8 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1143,12 +1143,105 @@ static int init_status_page(struct intel_engine_cs
*engine)
return ret;
}
+static int intel_engine_init_tlb_invalidation(struct intel_engine_cs *engine)
+{
+ static const union intel_engine_tlb_inv_reg gen8_regs[] = {
+ [RENDER_CLASS].reg = GEN8_RTCR,
+ [VIDEO_DECODE_CLASS].reg= GEN8_M1TCR, /* , GEN8_M2TCR */
+ [VIDEO_ENHANCEMENT_CLASS].reg = GEN8_VTCR,
+ [COPY_ENGINE_CLASS].reg = GEN8_BTCR,
+ };
+ static const union intel_engine_tlb_inv_reg gen12_regs[] = {
+ [RENDER_CLASS].reg = GEN12_GFX_TLB_INV_CR,
+ [VIDEO_DECODE_CLASS].reg= GEN12_VD_TLB_INV_CR,
+ [VIDEO_ENHANCEMENT_CLASS].reg = GEN12_VE_TLB_INV_CR,
+ [COPY_ENGINE_CLASS].reg = GEN12_BLT_TLB_INV_CR,
+ [COMPUTE_CLASS].reg = GEN12_COMPCTX_TLB_INV_CR,
+ };
+ static const union intel_engine_tlb_inv_reg xehp_regs[] = {
+ [RENDER_CLASS].mcr_reg= XEHP_GFX_TLB_INV_CR,
+ [VIDEO_DECODE_CLASS].mcr_reg = XEHP_VD_TLB_INV_CR,
+ [VIDEO_ENHANCEMENT_CLASS].mcr_reg = XEHP_VE_TLB_INV_CR,
+ [COPY_ENGINE_CLASS].mcr_reg = XEHP_BLT_TLB_INV_CR,
+ [COMPUTE_CLASS].mcr_reg = XEHP_COMPCTX_TLB_INV_CR,
+ };
+ struct drm_i915_private *i915 = engine->i915;
+ const union intel_engine_tlb_inv_reg *regs;
+ union intel_engine_tlb_inv_reg reg;
+ unsigned int class = engine->class;
+ unsigned int num = 0;
+ u32 val;
+
+ /*
+* New platforms should not be added with catch-all-newer (>=)
+* condition so that any later platform added triggers the below warning
+* and in turn mandates a human cross-check of whether the invalidation
+* flows have compatible semantics.
+*
+* For instance with the 11.00 -> 12.00 transition three out of five
+* respective engine registers were moved to masked type. Then after the
+* 12.00 -> 12.50 transition multi cast handling is required too.
+*/
+
+ if (GRAPHICS_VER_FULL(i915) == IP_VER(12, 50)) {
This is bad...it only captures XEHPSDV and breaks the handling of DG2
(12.55), PVC (12.60), and MTL (12.70, 12.71, and 12.72). You're not
hitting the warning as expected since those are all now being captured
by the next case of the if/else ladder. With the way GMD_ID works, we
may also get new version numbers that silently show up in hardware too
at some point (e.g., 12.73, 12.74, etc.)
Great (on multiple counts) ...
+ regs = xehp_regs;
+ num = ARRAY_SIZE(xehp_regs);
+ } else if (GRAPHICS_VER(i915) == 12) {
You'd want to change this to
GRAPHICS_VER_FULL(i915) == IP_VER(12, 0)
to get the behavior you expected.
Okay, that, and then to be as safe as I intended, ie. warn on every new
platforms so developers *must* check registers are still compatible
during platform enablement, we would need a full ver range check
something like:
if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50) &&
GRAPHICS_VER_FULL(i915) <= IP_VER(12, 55)) {
regs = xehp_regs;
num = ARRAY_SIZE(xehp_regs);
} else if (GRAPHICS_VER_FULL(i915) == IP_VER(12, 0)) {
regs = gen12_regs;
num = ARRAY_SIZE(gen12_regs);
What do you think about that?
Or you are saying new GMD IDs may appear in the field without first
having passed the new platform enablemend process? That would be
horrible so I hope not.
Regards,
Tvrtko
+ regs = gen12_regs;
+ num = ARRAY_SIZE(gen12_regs);
+ } else if
[Intel-gfx] [PATCH v7 22/22] drm/i915/panel: move panel fixed EDID to struct intel_panel
It's a bit confusing to have two cached EDIDs in struct intel_connector
with slightly different purposes. Make the distinction a bit clearer by
moving the EDID cached for eDP and LVDS panels at connector init time to
struct intel_panel, and name it fixed_edid. That's what it is, a fixed
EDID for the panels.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/icl_dsi.c| 2 +-
.../gpu/drm/i915/display/intel_connector.c| 3 ---
.../drm/i915/display/intel_display_types.h| 6 --
drivers/gpu/drm/i915/display/intel_dp.c | 20 +--
drivers/gpu/drm/i915/display/intel_dvo.c | 2 +-
drivers/gpu/drm/i915/display/intel_lvds.c | 11 +-
drivers/gpu/drm/i915/display/intel_panel.c| 10 +-
drivers/gpu/drm/i915/display/intel_panel.h| 4 +++-
drivers/gpu/drm/i915/display/intel_sdvo.c | 2 +-
drivers/gpu/drm/i915/display/vlv_dsi.c| 2 +-
10 files changed, 35 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index ae14c794c4bc..d56d01f07bb7 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -2054,7 +2054,7 @@ void icl_dsi_init(struct drm_i915_private *dev_priv)
goto err;
}
- intel_panel_init(intel_connector);
+ intel_panel_init(intel_connector, NULL);
intel_backlight_setup(intel_connector, INVALID_PIPE);
diff --git a/drivers/gpu/drm/i915/display/intel_connector.c
b/drivers/gpu/drm/i915/display/intel_connector.c
index 4814d4e2f7f9..257afac34839 100644
--- a/drivers/gpu/drm/i915/display/intel_connector.c
+++ b/drivers/gpu/drm/i915/display/intel_connector.c
@@ -99,9 +99,6 @@ void intel_connector_destroy(struct drm_connector *connector)
intel_hdcp_cleanup(intel_connector);
- if (!IS_ERR_OR_NULL(intel_connector->edid))
- drm_edid_free(intel_connector->edid);
-
intel_panel_fini(intel_connector);
drm_connector_cleanup(connector);
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 34dc850340b8..6feb232bb1c2 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -351,6 +351,9 @@ struct intel_vbt_panel_data {
};
struct intel_panel {
+ /* Fixed EDID for eDP and LVDS. May hold ERR_PTR for invalid EDID. */
+ const struct drm_edid *fixed_edid;
+
struct list_head fixed_modes;
/* backlight */
@@ -591,8 +594,7 @@ struct intel_connector {
/* Panel info for eDP and LVDS */
struct intel_panel panel;
- /* Cached EDID for eDP and LVDS. May hold ERR_PTR for invalid EDID. */
- const struct drm_edid *edid;
+ /* Cached EDID for detect. */
const struct drm_edid *detect_edid;
/* Number of times hotplug detection was tried after an HPD interrupt */
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 67f2cb048ac1..3f4396b5f029 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4480,18 +4480,19 @@ bool intel_digital_port_connected(struct intel_encoder
*encoder)
static const struct drm_edid *
intel_dp_get_edid(struct intel_dp *intel_dp)
{
- struct intel_connector *intel_connector = intel_dp->attached_connector;
+ struct intel_connector *connector = intel_dp->attached_connector;
+ const struct drm_edid *fixed_edid = connector->panel.fixed_edid;
- /* use cached edid if we have one */
- if (intel_connector->edid) {
+ /* Use panel fixed edid if we have one */
+ if (fixed_edid) {
/* invalid edid */
- if (IS_ERR(intel_connector->edid))
+ if (IS_ERR(fixed_edid))
return NULL;
- return drm_edid_dup(intel_connector->edid);
- } else
- return drm_edid_read_ddc(_connector->base,
-_dp->aux.ddc);
+ return drm_edid_dup(fixed_edid);
+ }
+
+ return drm_edid_read_ddc(>base, _dp->aux.ddc);
}
static void
@@ -5316,7 +5317,6 @@ static bool intel_edp_init_connector(struct intel_dp
*intel_dp,
} else {
drm_edid = ERR_PTR(-ENOENT);
}
- intel_connector->edid = drm_edid;
intel_bios_init_panel_late(dev_priv, _connector->panel,
encoder->devdata,
IS_ERR(drm_edid) ? NULL : drm_edid);
@@ -5343,7 +5343,7 @@ static bool intel_edp_init_connector(struct intel_dp
*intel_dp,
goto out_vdd_off;
}
- intel_panel_init(intel_connector);
+ intel_panel_init(intel_connector, drm_edid);
intel_edp_backlight_setup(intel_dp, intel_connector);
diff --git
[Intel-gfx] [PATCH v7 21/22] drm/i915/opregion: convert intel_opregion_get_edid() to struct drm_edid
Simplify validation and use by converting to drm_edid.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dp.c | 10 ++-
drivers/gpu/drm/i915/display/intel_opregion.c | 29 +++
drivers/gpu/drm/i915/display/intel_opregion.h | 4 +--
3 files changed, 15 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index a64e97808813..67f2cb048ac1 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5299,18 +5299,12 @@ static bool intel_edp_init_connector(struct intel_dp
*intel_dp,
mutex_lock(_priv->drm.mode_config.mutex);
drm_edid = drm_edid_read_ddc(connector, _dp->aux.ddc);
if (!drm_edid) {
- const struct edid *edid;
-
/* Fallback to EDID from ACPI OpRegion, if any */
- /* FIXME: Make intel_opregion_get_edid() return drm_edid */
- edid = intel_opregion_get_edid(intel_connector);
- if (edid) {
- drm_edid = drm_edid_alloc(edid, (edid->extensions + 1)
* EDID_LENGTH);
+ drm_edid = intel_opregion_get_edid(intel_connector);
+ if (drm_edid)
drm_dbg_kms(_priv->drm,
"[CONNECTOR:%d:%s] Using OpRegion EDID\n",
connector->base.id, connector->name);
- kfree(edid);
- }
}
if (drm_edid) {
if (drm_edid_connector_update(connector, drm_edid) ||
diff --git a/drivers/gpu/drm/i915/display/intel_opregion.c
b/drivers/gpu/drm/i915/display/intel_opregion.c
index e0184745632c..b8dce0576512 100644
--- a/drivers/gpu/drm/i915/display/intel_opregion.c
+++ b/drivers/gpu/drm/i915/display/intel_opregion.c
@@ -1101,41 +1101,34 @@ intel_opregion_get_panel_type(struct drm_i915_private
*dev_priv)
* The EDID in the OpRegion, or NULL if there is none or it's invalid.
*
*/
-struct edid *intel_opregion_get_edid(struct intel_connector *intel_connector)
+const struct drm_edid *intel_opregion_get_edid(struct intel_connector
*intel_connector)
{
struct drm_connector *connector = _connector->base;
struct drm_i915_private *i915 = to_i915(connector->dev);
struct intel_opregion *opregion = >display.opregion;
- const void *in_edid;
- const struct edid *edid;
- struct edid *new_edid;
+ const struct drm_edid *drm_edid;
+ const void *edid;
int len;
if (!opregion->asle_ext)
return NULL;
- in_edid = opregion->asle_ext->bddc;
+ edid = opregion->asle_ext->bddc;
/* Validity corresponds to number of 128-byte blocks */
len = (opregion->asle_ext->phed & ASLE_PHED_EDID_VALID_MASK) * 128;
- if (!len || !memchr_inv(in_edid, 0, len))
+ if (!len || !memchr_inv(edid, 0, len))
return NULL;
- edid = in_edid;
+ drm_edid = drm_edid_alloc(edid, len);
- if (len < EDID_LENGTH * (1 + edid->extensions)) {
- drm_dbg_kms(>drm, "Invalid EDID in ACPI OpRegion (Mailbox
#5): too short\n");
- return NULL;
- }
- new_edid = drm_edid_duplicate(edid);
- if (!new_edid)
- return NULL;
- if (!drm_edid_is_valid(new_edid)) {
- kfree(new_edid);
+ if (!drm_edid_valid(drm_edid)) {
drm_dbg_kms(>drm, "Invalid EDID in ACPI OpRegion (Mailbox
#5)\n");
- return NULL;
+ drm_edid_free(drm_edid);
+ drm_edid = NULL;
}
- return new_edid;
+
+ return drm_edid;
}
bool intel_opregion_headless_sku(struct drm_i915_private *i915)
diff --git a/drivers/gpu/drm/i915/display/intel_opregion.h
b/drivers/gpu/drm/i915/display/intel_opregion.h
index 2f261f985400..d02e6696a050 100644
--- a/drivers/gpu/drm/i915/display/intel_opregion.h
+++ b/drivers/gpu/drm/i915/display/intel_opregion.h
@@ -74,7 +74,7 @@ int intel_opregion_notify_encoder(struct intel_encoder
*intel_encoder,
int intel_opregion_notify_adapter(struct drm_i915_private *dev_priv,
pci_power_t state);
int intel_opregion_get_panel_type(struct drm_i915_private *dev_priv);
-struct edid *intel_opregion_get_edid(struct intel_connector *connector);
+const struct drm_edid *intel_opregion_get_edid(struct intel_connector
*connector);
bool intel_opregion_headless_sku(struct drm_i915_private *i915);
@@ -123,7 +123,7 @@ static inline int intel_opregion_get_panel_type(struct
drm_i915_private *dev)
return -ENODEV;
}
-static inline struct edid *
+static inline const struct drm_edid *
intel_opregion_get_edid(struct intel_connector *connector)
{
return NULL;
--
2.34.1
[Intel-gfx] [PATCH v7 20/22] drm/i915/bios: convert intel_bios_init_panel() to drm_edid
Try to use struct drm_edid where possible, even if having to fall back
to looking into struct edid down low via drm_edid_raw().
v2: Rebase
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_bios.c | 23 ---
drivers/gpu/drm/i915/display/intel_bios.h | 4 ++--
drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
drivers/gpu/drm/i915/display/intel_lvds.c | 2 +-
4 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index 55544d484318..9badd77d656a 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -620,14 +620,14 @@ static void dump_pnp_id(struct drm_i915_private *i915,
static int opregion_get_panel_type(struct drm_i915_private *i915,
const struct intel_bios_encoder_data
*devdata,
- const struct edid *edid, bool use_fallback)
+ const struct drm_edid *drm_edid, bool
use_fallback)
{
return intel_opregion_get_panel_type(i915);
}
static int vbt_get_panel_type(struct drm_i915_private *i915,
const struct intel_bios_encoder_data *devdata,
- const struct edid *edid, bool use_fallback)
+ const struct drm_edid *drm_edid, bool
use_fallback)
{
const struct bdb_lvds_options *lvds_options;
@@ -652,12 +652,13 @@ static int vbt_get_panel_type(struct drm_i915_private
*i915,
static int pnpid_get_panel_type(struct drm_i915_private *i915,
const struct intel_bios_encoder_data *devdata,
- const struct edid *edid, bool use_fallback)
+ const struct drm_edid *drm_edid, bool
use_fallback)
{
const struct bdb_lvds_lfp_data *data;
const struct bdb_lvds_lfp_data_ptrs *ptrs;
const struct lvds_pnp_id *edid_id;
struct lvds_pnp_id edid_id_nodate;
+ const struct edid *edid = drm_edid_raw(drm_edid); /* FIXME */
int i, best = -1;
if (!edid)
@@ -701,7 +702,7 @@ static int pnpid_get_panel_type(struct drm_i915_private
*i915,
static int fallback_get_panel_type(struct drm_i915_private *i915,
const struct intel_bios_encoder_data
*devdata,
- const struct edid *edid, bool use_fallback)
+ const struct drm_edid *drm_edid, bool
use_fallback)
{
return use_fallback ? 0 : -1;
}
@@ -715,13 +716,13 @@ enum panel_type {
static int get_panel_type(struct drm_i915_private *i915,
const struct intel_bios_encoder_data *devdata,
- const struct edid *edid, bool use_fallback)
+ const struct drm_edid *drm_edid, bool use_fallback)
{
struct {
const char *name;
int (*get_panel_type)(struct drm_i915_private *i915,
const struct intel_bios_encoder_data
*devdata,
- const struct edid *edid, bool
use_fallback);
+ const struct drm_edid *drm_edid, bool
use_fallback);
int panel_type;
} panel_types[] = {
[PANEL_TYPE_OPREGION] = {
@@ -745,7 +746,7 @@ static int get_panel_type(struct drm_i915_private *i915,
for (i = 0; i < ARRAY_SIZE(panel_types); i++) {
panel_types[i].panel_type = panel_types[i].get_panel_type(i915,
devdata,
- edid,
use_fallback);
+
drm_edid, use_fallback);
drm_WARN_ON(>drm, panel_types[i].panel_type > 0xf &&
panel_types[i].panel_type != 0xff);
@@ -3187,7 +3188,7 @@ void intel_bios_init(struct drm_i915_private *i915)
static void intel_bios_init_panel(struct drm_i915_private *i915,
struct intel_panel *panel,
const struct intel_bios_encoder_data *devdata,
- const struct edid *edid,
+ const struct drm_edid *drm_edid,
bool use_fallback)
{
/* already have it? */
@@ -3197,7 +3198,7 @@ static void intel_bios_init_panel(struct drm_i915_private
*i915,
}
panel->vbt.panel_type = get_panel_type(i915, devdata,
- edid, use_fallback);
+ drm_edid, use_fallback);
if (panel->vbt.panel_type < 0) {
drm_WARN_ON(>drm, use_fallback);
return;
@@ -3228,9 +3229,9 @@ void intel_bios_init_panel_early(struct
[Intel-gfx] [PATCH v7 19/22] drm/i915/edid: convert DP, HDMI and LVDS to drm_edid
Convert all the connectors that use cached connector edid and
detect_edid to drm_edid.
Since drm_get_edid() calls drm_connector_update_edid_property() while
drm_edid_read*() do not, we need to call drm_edid_connector_update()
separately, in part due to the EDID caching behaviour in HDMI and
DP. Especially DP depends on the details parsed from EDID. (The big
behavioural change conflating EDID reading with parsing and property
update was done in commit 5186421cbfe2 ("drm: Introduce epoch counter to
drm_connector"))
v6: Rebase on drm_edid_connector_add_modes()
v5: Fix potential uninitialized var use (kernel test robot )
v4: Call drm_edid_connector_update() after reading HDMI/DP EDID
v3: Don't leak vga switcheroo EDID in LVDS init (Ville)
v2: Don't leak opregion fallback EDID (Ville)
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
.../gpu/drm/i915/display/intel_connector.c| 4 +-
.../drm/i915/display/intel_display_types.h| 4 +-
drivers/gpu/drm/i915/display/intel_dp.c | 83 +++
drivers/gpu/drm/i915/display/intel_hdmi.c | 28 ---
drivers/gpu/drm/i915/display/intel_lvds.c | 46 ++
5 files changed, 96 insertions(+), 69 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_connector.c
b/drivers/gpu/drm/i915/display/intel_connector.c
index 562da3b741e2..4814d4e2f7f9 100644
--- a/drivers/gpu/drm/i915/display/intel_connector.c
+++ b/drivers/gpu/drm/i915/display/intel_connector.c
@@ -95,12 +95,12 @@ void intel_connector_destroy(struct drm_connector
*connector)
{
struct intel_connector *intel_connector = to_intel_connector(connector);
- kfree(intel_connector->detect_edid);
+ drm_edid_free(intel_connector->detect_edid);
intel_hdcp_cleanup(intel_connector);
if (!IS_ERR_OR_NULL(intel_connector->edid))
- kfree(intel_connector->edid);
+ drm_edid_free(intel_connector->edid);
intel_panel_fini(intel_connector);
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 32e8b2fc3cc6..34dc850340b8 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -592,8 +592,8 @@ struct intel_connector {
struct intel_panel panel;
/* Cached EDID for eDP and LVDS. May hold ERR_PTR for invalid EDID. */
- struct edid *edid;
- struct edid *detect_edid;
+ const struct drm_edid *edid;
+ const struct drm_edid *detect_edid;
/* Number of times hotplug detection was tried after an HPD interrupt */
int hotplug_retries;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index bf80f296a8fd..6caa290ef6e6 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3651,12 +3651,11 @@ static u8 intel_dp_autotest_edid(struct intel_dp
*intel_dp)
intel_dp->aux.i2c_defer_count);
intel_dp->compliance.test_data.edid =
INTEL_DP_RESOLUTION_FAILSAFE;
} else {
- struct edid *block = intel_connector->detect_edid;
+ /* FIXME: Get rid of drm_edid_raw() */
+ const struct edid *block =
drm_edid_raw(intel_connector->detect_edid);
- /* We have to write the checksum
-* of the last block read
-*/
- block += intel_connector->detect_edid->extensions;
+ /* We have to write the checksum of the last block read */
+ block += block->extensions;
if (drm_dp_dpcd_writeb(_dp->aux, DP_TEST_EDID_CHECKSUM,
block->checksum) <= 0)
@@ -4478,7 +4477,7 @@ bool intel_digital_port_connected(struct intel_encoder
*encoder)
return is_connected;
}
-static struct edid *
+static const struct drm_edid *
intel_dp_get_edid(struct intel_dp *intel_dp)
{
struct intel_connector *intel_connector = intel_dp->attached_connector;
@@ -4489,18 +4488,22 @@ intel_dp_get_edid(struct intel_dp *intel_dp)
if (IS_ERR(intel_connector->edid))
return NULL;
- return drm_edid_duplicate(intel_connector->edid);
+ return drm_edid_dup(intel_connector->edid);
} else
- return drm_get_edid(_connector->base,
- _dp->aux.ddc);
+ return drm_edid_read_ddc(_connector->base,
+_dp->aux.ddc);
}
static void
intel_dp_update_dfp(struct intel_dp *intel_dp,
- const struct edid *edid)
+ const struct drm_edid *drm_edid)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
struct intel_connector *connector = intel_dp->attached_connector;
+ const struct edid *edid;
+
+ /* FIXME: Get rid of drm_edid_raw()
[Intel-gfx] [PATCH v7 18/22] drm/edid: remove redundant _drm_connector_update_edid_property()
Realize that drm_edid_connector_update() and
_drm_connector_update_edid_property() are now the same thing. Drop the
latter.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 21 +
1 file changed, 1 insertion(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index a64c0807e97f..ae50f533fea3 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -6810,24 +6810,6 @@ int drm_edid_connector_add_modes(struct drm_connector
*connector)
}
EXPORT_SYMBOL(drm_edid_connector_add_modes);
-static int _drm_connector_update_edid_property(struct drm_connector *connector,
- const struct drm_edid *drm_edid)
-{
- /*
-* Set the display info, using edid if available, otherwise resetting
-* the values to defaults. This duplicates the work done in
-* drm_add_edid_modes, but that function is not consistently called
-* before this one in all drivers and the computation is cheap enough
-* that it seems better to duplicate it rather than attempt to ensure
-* some arbitrary ordering of calls.
-*/
- update_display_info(connector, drm_edid);
-
- _drm_update_tile_info(connector, drm_edid);
-
- return _drm_edid_connector_property_update(connector, drm_edid);
-}
-
/**
* drm_connector_update_edid_property - update the edid property of a connector
* @connector: drm connector
@@ -6849,8 +6831,7 @@ int drm_connector_update_edid_property(struct
drm_connector *connector,
{
struct drm_edid drm_edid;
- return _drm_connector_update_edid_property(connector,
-
drm_edid_legacy_init(_edid, edid));
+ return drm_edid_connector_update(connector,
drm_edid_legacy_init(_edid, edid));
}
EXPORT_SYMBOL(drm_connector_update_edid_property);
--
2.34.1
[Intel-gfx] [PATCH v7 17/22] drm/edid: add separate drm_edid_connector_add_modes()
The original goal with drm_edid_connector_update() was to have a single
call for updating the connector and adding probed modes, in this order,
but that turned out to be problematic. Drivers that need to update the
connector in the .detect() callback would end up updating the probed
modes as well. Turns out the callback may be called so many times that
the probed mode list fills up without bounds, and this is amplified by
add_alternate_cea_modes() duplicating the CEA modes on every call,
actually running out of memory on some machines.
Kudos to Imre Deak for explaining this to me.
Go back to having separate drm_edid_connector_update() and
drm_edid_connector_add_modes() calls. The former may be called from
.detect(), .force(), or .get_modes(), but the latter only from
.get_modes().
Unlike drm_add_edid_modes(), have drm_edid_connector_add_modes() update
the probed modes from the EDID property instead of the passed in
EDID. This is mainly to enforce two things:
1) drm_edid_connector_update() must be called before
drm_edid_connector_add_modes().
Display info and quirks are needed for parsing the modes, and we
don't want to call update_display_info() again to ensure the info is
available, like drm_add_edid_modes() does.
2) The same EDID is used for both updating the connector and adding the
probed modes.
Fortunately, the change is easy, because no driver has actually adopted
drm_edid_connector_update(). Not even i915, and that's mainly because of
the problem described above.
Cc: Imre Deak
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 44 +++---
drivers/gpu/drm/drm_probe_helper.c | 4 ++-
include/drm/drm_edid.h | 2 ++
3 files changed, 39 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 95c383220afc..a64c0807e97f 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -6761,30 +6761,54 @@ static int _drm_edid_connector_property_update(struct
drm_connector *connector,
* @connector: Connector
* @drm_edid: EDID
*
- * Update the connector mode list, display info, ELD, HDR metadata, relevant
- * properties, etc. from the passed in EDID.
+ * Update the connector display info, ELD, HDR metadata, relevant properties,
+ * etc. from the passed in EDID.
*
* If EDID is NULL, reset the information.
*
- * Return: The number of modes added or 0 if we couldn't find any.
+ * Must be called before calling drm_edid_connector_add_modes().
+ *
+ * Return: 0 on success, negative error on errors.
*/
int drm_edid_connector_update(struct drm_connector *connector,
const struct drm_edid *drm_edid)
{
+ update_display_info(connector, drm_edid);
+
+ _drm_update_tile_info(connector, drm_edid);
+
+ return _drm_edid_connector_property_update(connector, drm_edid);
+}
+EXPORT_SYMBOL(drm_edid_connector_update);
+
+/**
+ * drm_edid_connector_add_modes - Update probed modes from the EDID property
+ * @connector: Connector
+ *
+ * Add the modes from the previously updated EDID property to the connector
+ * probed modes list.
+ *
+ * drm_edid_connector_update() must have been called before this to update the
+ * EDID property.
+ *
+ * Return: The number of modes added, or 0 if we couldn't find any.
+ */
+int drm_edid_connector_add_modes(struct drm_connector *connector)
+{
+ const struct drm_edid *drm_edid = NULL;
int count;
- update_display_info(connector, drm_edid);
+ if (connector->edid_blob_ptr)
+ drm_edid = drm_edid_alloc(connector->edid_blob_ptr->data,
+ connector->edid_blob_ptr->length);
count = _drm_edid_connector_add_modes(connector, drm_edid);
- _drm_update_tile_info(connector, drm_edid);
-
- /* Note: Ignore errors for now. */
- _drm_edid_connector_property_update(connector, drm_edid);
+ drm_edid_free(drm_edid);
return count;
}
-EXPORT_SYMBOL(drm_edid_connector_update);
+EXPORT_SYMBOL(drm_edid_connector_add_modes);
static int _drm_connector_update_edid_property(struct drm_connector *connector,
const struct drm_edid *drm_edid)
@@ -6839,7 +6863,7 @@ EXPORT_SYMBOL(drm_connector_update_edid_property);
* _display_info structure and ELD in @connector with any information which
* can be derived from the edid.
*
- * This function is deprecated. Use drm_edid_connector_update() instead.
+ * This function is deprecated. Use drm_edid_connector_add_modes() instead.
*
* Return: The number of modes added or 0 if we couldn't find any.
*/
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index 1ea053cef557..26844befc6f5 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -1139,7 +1139,9 @@ int drm_connector_helper_get_modes(struct drm_connector
[Intel-gfx] [PATCH v7 16/22] drm/edid: refactor _drm_edid_connector_update() and rename
By moving update_display_info() out of _drm_edid_connector_update() we
make the function purely about adding modes. Rename accordingly.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 5881df5bddb9..95c383220afc 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -6663,19 +6663,12 @@ static int add_displayid_detailed_modes(struct
drm_connector *connector,
return num_modes;
}
-static int _drm_edid_connector_update(struct drm_connector *connector,
- const struct drm_edid *drm_edid)
+static int _drm_edid_connector_add_modes(struct drm_connector *connector,
+const struct drm_edid *drm_edid)
{
const struct drm_display_info *info = >display_info;
int num_modes = 0;
- /*
-* CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks.
-* To avoid multiple parsing of same block, lets parse that map
-* from sink info, before parsing CEA modes.
-*/
- update_display_info(connector, drm_edid);
-
if (!drm_edid)
return 0;
@@ -6780,7 +6773,9 @@ int drm_edid_connector_update(struct drm_connector
*connector,
{
int count;
- count = _drm_edid_connector_update(connector, drm_edid);
+ update_display_info(connector, drm_edid);
+
+ count = _drm_edid_connector_add_modes(connector, drm_edid);
_drm_update_tile_info(connector, drm_edid);
@@ -6850,7 +6845,8 @@ EXPORT_SYMBOL(drm_connector_update_edid_property);
*/
int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid)
{
- struct drm_edid drm_edid;
+ struct drm_edid _drm_edid;
+ const struct drm_edid *drm_edid;
if (edid && !drm_edid_is_valid(edid)) {
drm_warn(connector->dev, "[CONNECTOR:%d:%s] EDID invalid.\n",
@@ -6858,8 +6854,11 @@ int drm_add_edid_modes(struct drm_connector *connector,
struct edid *edid)
edid = NULL;
}
- return _drm_edid_connector_update(connector,
- drm_edid_legacy_init(_edid,
edid));
+ drm_edid = drm_edid_legacy_init(&_drm_edid, edid);
+
+ update_display_info(connector, drm_edid);
+
+ return _drm_edid_connector_add_modes(connector, drm_edid);
}
EXPORT_SYMBOL(drm_add_edid_modes);
--
2.34.1
[Intel-gfx] [PATCH v7 14/22] drm/edid: merge ELD handling to update_display_info()
Simplify display info update by merging ELD handling as well as clearing
of the data in update_display_info().
The connector->eld really should be moved under display_info altogether,
but that's for another time.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 28 +---
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 6bc0432046c8..810a5fca398a 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -5489,8 +5489,6 @@ static void drm_edid_to_eld(struct drm_connector
*connector,
int total_sad_count = 0;
int mnl;
- clear_eld(connector);
-
if (!drm_edid)
return;
@@ -6465,9 +6463,15 @@ static void update_display_info(struct drm_connector
*connector,
const struct drm_edid *drm_edid)
{
struct drm_display_info *info = >display_info;
- const struct edid *edid = drm_edid->edid;
+ const struct edid *edid;
drm_reset_display_info(connector);
+ clear_eld(connector);
+
+ if (!drm_edid)
+ return;
+
+ edid = drm_edid->edid;
info->quirks = edid_get_quirks(drm_edid);
@@ -6550,6 +6554,9 @@ static void update_display_info(struct drm_connector
*connector,
if (info->quirks & EDID_QUIRK_CAP_DSC_15BPP)
info->max_dsc_bpp = 15;
+
+ /* Depends on info->cea_rev set by drm_parse_cea_ext() above */
+ drm_edid_to_eld(connector, drm_edid);
}
static struct drm_display_mode *drm_mode_displayid_detailed(struct drm_device
*dev,
@@ -6650,12 +6657,6 @@ static int _drm_edid_connector_update(struct
drm_connector *connector,
struct drm_display_info *info = >display_info;
int num_modes = 0;
- if (!drm_edid) {
- drm_reset_display_info(connector);
- clear_eld(connector);
- return 0;
- }
-
/*
* CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks.
* To avoid multiple parsing of same block, lets parse that map
@@ -6663,8 +6664,8 @@ static int _drm_edid_connector_update(struct
drm_connector *connector,
*/
update_display_info(connector, drm_edid);
- /* Depends on info->cea_rev set by update_display_info() above */
- drm_edid_to_eld(connector, drm_edid);
+ if (!drm_edid)
+ return 0;
/*
* EDID spec says modes should be preferred in this order:
@@ -6801,10 +6802,7 @@ static int _drm_connector_update_edid_property(struct
drm_connector *connector,
* that it seems better to duplicate it rather than attempt to ensure
* some arbitrary ordering of calls.
*/
- if (drm_edid)
- update_display_info(connector, drm_edid);
- else
- drm_reset_display_info(connector);
+ update_display_info(connector, drm_edid);
_drm_update_tile_info(connector, drm_edid);
--
2.34.1
[Intel-gfx] [PATCH v7 15/22] drm/edid: move EDID BPC quirk application to update_display_info()
The BPC quirks are closer to home in update_display_info().
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 810a5fca398a..5881df5bddb9 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -6555,6 +6555,18 @@ static void update_display_info(struct drm_connector
*connector,
if (info->quirks & EDID_QUIRK_CAP_DSC_15BPP)
info->max_dsc_bpp = 15;
+ if (info->quirks & EDID_QUIRK_FORCE_6BPC)
+ info->bpc = 6;
+
+ if (info->quirks & EDID_QUIRK_FORCE_8BPC)
+ info->bpc = 8;
+
+ if (info->quirks & EDID_QUIRK_FORCE_10BPC)
+ info->bpc = 10;
+
+ if (info->quirks & EDID_QUIRK_FORCE_12BPC)
+ info->bpc = 12;
+
/* Depends on info->cea_rev set by drm_parse_cea_ext() above */
drm_edid_to_eld(connector, drm_edid);
}
@@ -6654,7 +,7 @@ static int add_displayid_detailed_modes(struct
drm_connector *connector,
static int _drm_edid_connector_update(struct drm_connector *connector,
const struct drm_edid *drm_edid)
{
- struct drm_display_info *info = >display_info;
+ const struct drm_display_info *info = >display_info;
int num_modes = 0;
/*
@@ -6694,18 +6706,6 @@ static int _drm_edid_connector_update(struct
drm_connector *connector,
if (info->quirks & (EDID_QUIRK_PREFER_LARGE_60 |
EDID_QUIRK_PREFER_LARGE_75))
edid_fixup_preferred(connector);
- if (info->quirks & EDID_QUIRK_FORCE_6BPC)
- info->bpc = 6;
-
- if (info->quirks & EDID_QUIRK_FORCE_8BPC)
- info->bpc = 8;
-
- if (info->quirks & EDID_QUIRK_FORCE_10BPC)
- info->bpc = 10;
-
- if (info->quirks & EDID_QUIRK_FORCE_12BPC)
- info->bpc = 12;
-
return num_modes;
}
--
2.34.1
[Intel-gfx] [PATCH v7 13/22] drm/edid: stop passing quirks around
Now that quirks are stored in display info, we can just look them up
using the connector instead of having to pass them around.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 34 +++---
1 file changed, 15 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index fd8d056e38c1..6bc0432046c8 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -96,7 +96,6 @@ struct detailed_mode_closure {
struct drm_connector *connector;
const struct drm_edid *drm_edid;
bool preferred;
- u32 quirks;
int modes;
};
@@ -2887,9 +2886,9 @@ static u32 edid_get_quirks(const struct drm_edid
*drm_edid)
* Walk the mode list for connector, clearing the preferred status on existing
* modes and setting it anew for the right mode ala quirks.
*/
-static void edid_fixup_preferred(struct drm_connector *connector,
-u32 quirks)
+static void edid_fixup_preferred(struct drm_connector *connector)
{
+ const struct drm_display_info *info = >display_info;
struct drm_display_mode *t, *cur_mode, *preferred_mode;
int target_refresh = 0;
int cur_vrefresh, preferred_vrefresh;
@@ -2897,9 +2896,9 @@ static void edid_fixup_preferred(struct drm_connector
*connector,
if (list_empty(>probed_modes))
return;
- if (quirks & EDID_QUIRK_PREFER_LARGE_60)
+ if (info->quirks & EDID_QUIRK_PREFER_LARGE_60)
target_refresh = 60;
- if (quirks & EDID_QUIRK_PREFER_LARGE_75)
+ if (info->quirks & EDID_QUIRK_PREFER_LARGE_75)
target_refresh = 75;
preferred_mode = list_first_entry(>probed_modes,
@@ -3401,9 +3400,9 @@ drm_mode_do_interlace_quirk(struct drm_display_mode *mode,
*/
static struct drm_display_mode *drm_mode_detailed(struct drm_connector
*connector,
const struct drm_edid
*drm_edid,
- const struct detailed_timing
*timing,
- u32 quirks)
+ const struct detailed_timing
*timing)
{
+ const struct drm_display_info *info = >display_info;
struct drm_device *dev = connector->dev;
struct drm_display_mode *mode;
const struct detailed_pixel_timing *pt = >data.pixel_data;
@@ -3437,7 +3436,7 @@ static struct drm_display_mode *drm_mode_detailed(struct
drm_connector *connecto
return NULL;
}
- if (quirks & EDID_QUIRK_FORCE_REDUCED_BLANKING) {
+ if (info->quirks & EDID_QUIRK_FORCE_REDUCED_BLANKING) {
mode = drm_cvt_mode(dev, hactive, vactive, 60, true, false,
false);
if (!mode)
return NULL;
@@ -3449,7 +3448,7 @@ static struct drm_display_mode *drm_mode_detailed(struct
drm_connector *connecto
if (!mode)
return NULL;
- if (quirks & EDID_QUIRK_135_CLOCK_TOO_HIGH)
+ if (info->quirks & EDID_QUIRK_135_CLOCK_TOO_HIGH)
mode->clock = 1088 * 10;
else
mode->clock = le16_to_cpu(timing->pixel_clock) * 10;
@@ -3472,7 +3471,7 @@ static struct drm_display_mode *drm_mode_detailed(struct
drm_connector *connecto
drm_mode_do_interlace_quirk(mode, pt);
- if (quirks & EDID_QUIRK_DETAILED_SYNC_PP) {
+ if (info->quirks & EDID_QUIRK_DETAILED_SYNC_PP) {
mode->flags |= DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC;
} else {
mode->flags |= (pt->misc & DRM_EDID_PT_HSYNC_POSITIVE) ?
@@ -3485,12 +3484,12 @@ static struct drm_display_mode
*drm_mode_detailed(struct drm_connector *connecto
mode->width_mm = pt->width_mm_lo | (pt->width_height_mm_hi & 0xf0) << 4;
mode->height_mm = pt->height_mm_lo | (pt->width_height_mm_hi & 0xf) <<
8;
- if (quirks & EDID_QUIRK_DETAILED_IN_CM) {
+ if (info->quirks & EDID_QUIRK_DETAILED_IN_CM) {
mode->width_mm *= 10;
mode->height_mm *= 10;
}
- if (quirks & EDID_QUIRK_DETAILED_USE_MAXIMUM_SIZE) {
+ if (info->quirks & EDID_QUIRK_DETAILED_USE_MAXIMUM_SIZE) {
mode->width_mm = drm_edid->edid->width_cm * 10;
mode->height_mm = drm_edid->edid->height_cm * 10;
}
@@ -4003,8 +4002,7 @@ do_detailed_mode(const struct detailed_timing *timing,
void *c)
return;
newmode = drm_mode_detailed(closure->connector,
- closure->drm_edid, timing,
- closure->quirks);
+ closure->drm_edid, timing);
if (!newmode)
return;
@@ -4027,15 +4025,13 @@ do_detailed_mode(const struct detailed_timing *timing,
void *c)
* add_detailed_modes - Add modes from
[Intel-gfx] [PATCH v7 12/22] drm/edid: store quirks in display info
Although the quirks are internal to EDID parsing, it'll be helpful to
store them in display info to avoid having to pass them around.
This will also help separate adding probed modes (which needs the
quirks) from updating display info.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 42 ++---
include/drm/drm_connector.h | 5 +
2 files changed, 26 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 5cb1d36ce48a..fd8d056e38c1 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -6461,18 +6461,20 @@ static void drm_reset_display_info(struct drm_connector
*connector)
kfree(info->vics);
info->vics = NULL;
info->vics_len = 0;
+
+ info->quirks = 0;
}
-static u32 update_display_info(struct drm_connector *connector,
- const struct drm_edid *drm_edid)
+static void update_display_info(struct drm_connector *connector,
+ const struct drm_edid *drm_edid)
{
struct drm_display_info *info = >display_info;
const struct edid *edid = drm_edid->edid;
- u32 quirks = edid_get_quirks(drm_edid);
-
drm_reset_display_info(connector);
+ info->quirks = edid_get_quirks(drm_edid);
+
info->width_mm = edid->width_cm * 10;
info->height_mm = edid->height_cm * 10;
@@ -6543,17 +6545,15 @@ static u32 update_display_info(struct drm_connector
*connector,
drm_update_mso(connector, drm_edid);
out:
- if (quirks & EDID_QUIRK_NON_DESKTOP) {
+ if (info->quirks & EDID_QUIRK_NON_DESKTOP) {
drm_dbg_kms(connector->dev, "[CONNECTOR:%d:%s] Non-desktop
display%s\n",
connector->base.id, connector->name,
info->non_desktop ? " (redundant quirk)" : "");
info->non_desktop = true;
}
- if (quirks & EDID_QUIRK_CAP_DSC_15BPP)
+ if (info->quirks & EDID_QUIRK_CAP_DSC_15BPP)
info->max_dsc_bpp = 15;
-
- return quirks;
}
static struct drm_display_mode *drm_mode_displayid_detailed(struct drm_device
*dev,
@@ -6651,8 +6651,8 @@ static int add_displayid_detailed_modes(struct
drm_connector *connector,
static int _drm_edid_connector_update(struct drm_connector *connector,
const struct drm_edid *drm_edid)
{
+ struct drm_display_info *info = >display_info;
int num_modes = 0;
- u32 quirks;
if (!drm_edid) {
drm_reset_display_info(connector);
@@ -6665,7 +6665,7 @@ static int _drm_edid_connector_update(struct
drm_connector *connector,
* To avoid multiple parsing of same block, lets parse that map
* from sink info, before parsing CEA modes.
*/
- quirks = update_display_info(connector, drm_edid);
+ update_display_info(connector, drm_edid);
/* Depends on info->cea_rev set by update_display_info() above */
drm_edid_to_eld(connector, drm_edid);
@@ -6684,7 +6684,7 @@ static int _drm_edid_connector_update(struct
drm_connector *connector,
*
* XXX order for additional mode types in extension blocks?
*/
- num_modes += add_detailed_modes(connector, drm_edid, quirks);
+ num_modes += add_detailed_modes(connector, drm_edid, info->quirks);
num_modes += add_cvt_modes(connector, drm_edid);
num_modes += add_standard_modes(connector, drm_edid);
num_modes += add_established_modes(connector, drm_edid);
@@ -6694,20 +6694,20 @@ static int _drm_edid_connector_update(struct
drm_connector *connector,
if (drm_edid->edid->features & DRM_EDID_FEATURE_CONTINUOUS_FREQ)
num_modes += add_inferred_modes(connector, drm_edid);
- if (quirks & (EDID_QUIRK_PREFER_LARGE_60 | EDID_QUIRK_PREFER_LARGE_75))
- edid_fixup_preferred(connector, quirks);
+ if (info->quirks & (EDID_QUIRK_PREFER_LARGE_60 |
EDID_QUIRK_PREFER_LARGE_75))
+ edid_fixup_preferred(connector, info->quirks);
- if (quirks & EDID_QUIRK_FORCE_6BPC)
- connector->display_info.bpc = 6;
+ if (info->quirks & EDID_QUIRK_FORCE_6BPC)
+ info->bpc = 6;
- if (quirks & EDID_QUIRK_FORCE_8BPC)
- connector->display_info.bpc = 8;
+ if (info->quirks & EDID_QUIRK_FORCE_8BPC)
+ info->bpc = 8;
- if (quirks & EDID_QUIRK_FORCE_10BPC)
- connector->display_info.bpc = 10;
+ if (info->quirks & EDID_QUIRK_FORCE_10BPC)
+ info->bpc = 10;
- if (quirks & EDID_QUIRK_FORCE_12BPC)
- connector->display_info.bpc = 12;
+ if (info->quirks & EDID_QUIRK_FORCE_12BPC)
+ info->bpc = 12;
return num_modes;
}
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index
[Intel-gfx] [PATCH v7 11/22] drm/edid: split HDMI VSDB info and mode parsing
Separate the parsing of display info and modes from the HDMI VSDB. This
is prerequisite work for overall better separation of the two parsing
steps.
The info parsing is about figuring out whether the sink supports HDMI
infoframes. Since they were added in HDMI 1.4, assume the sink supports
HDMI infoframes if it uses HDMI 1.4 features in HDMI VSDB. For details,
see commit f1781e9bb2dd ("drm/edid: Allow HDMI infoframe without VIC or
S3D").
The logic is not exactly the same, but since it was somewhat heuristic
to begin with, assume this is close enough.
Add cea_db_raw_size() helper to get the size of the entire data block,
including tag and length. This is helpful for checking against specs
that define indexes from the start of the entire block, like here.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 39 +++---
1 file changed, 36 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 93067b8dd9f6..5cb1d36ce48a 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4717,7 +4717,6 @@ static int hdmi_vsdb_latency_length(const u8 *db)
static int
do_hdmi_vsdb_modes(struct drm_connector *connector, const u8 *db, u8 len)
{
- struct drm_display_info *info = >display_info;
int modes = 0, offset = 0, i, multi_present = 0, multi_len;
u8 vic_len, hdmi_3d_len = 0;
u16 mask;
@@ -4835,8 +4834,6 @@ do_hdmi_vsdb_modes(struct drm_connector *connector, const
u8 *db, u8 len)
}
out:
- if (modes > 0)
- info->has_hdmi_infoframe = true;
return modes;
}
@@ -4893,6 +4890,7 @@ static int cea_db_tag(const struct cea_db *db)
return db->tag_length >> 5;
}
+/* Data block payload length excluding the tag and length byte */
static int cea_db_payload_len(const void *_db)
{
/* FIXME: Transition to passing struct cea_db * everywhere. */
@@ -4901,6 +4899,12 @@ static int cea_db_payload_len(const void *_db)
return db->tag_length & 0x1f;
}
+/* Data block raw size including the tag and length byte */
+static int cea_db_raw_size(const void *db)
+{
+ return cea_db_payload_len(db) + 1;
+}
+
static const void *cea_db_data(const struct cea_db *db)
{
return db->data;
@@ -6159,6 +6163,32 @@ static void drm_parse_hdmi_deep_color_info(struct
drm_connector *connector,
}
}
+/*
+ * Try to infer whether the sink supports HDMI infoframes.
+ *
+ * HDMI infoframe support was first added in HDMI 1.4. Assume the sink supports
+ * infoframes if the HDMI VSDB contains HDMI 1.4 features.
+ */
+static bool hdmi_vsdb_infoframe_support(struct drm_connector *connector, const
u8 *db)
+{
+ int size = cea_db_raw_size(db);
+ int offset = 8;
+
+ if (offset < size)
+ offset += hdmi_vsdb_latency_length(db);
+
+ /* 3D_present */
+ if (offset < size && db[offset++] & BIT(7))
+ return true;
+
+ /* HDMI_VIC_LEN and HDMI_3D_LEN */
+ if (offset < size && db[offset])
+ return true;
+
+ return false;
+}
+
+/* HDMI Vendor-Specific Data Block (HDMI VSDB, H14b-VSDB) */
static void
drm_parse_hdmi_vsdb_video(struct drm_connector *connector, const u8 *db)
{
@@ -6172,6 +6202,9 @@ drm_parse_hdmi_vsdb_video(struct drm_connector
*connector, const u8 *db)
if (len >= 7)
info->max_tmds_clock = db[7] * 5000;
+ if (hdmi_vsdb_infoframe_support(connector, db))
+ info->has_hdmi_infoframe = true;
+
drm_dbg_kms(connector->dev, "[CONNECTOR:%d:%s] HDMI: DVI dual %d, max
TMDS clock %d kHz\n",
connector->base.id, connector->name,
info->dvi_dual, info->max_tmds_clock);
--
2.34.1
[Intel-gfx] [PATCH v7 10/22] drm/edid: add helper for HDMI VSDB audio latency field length
Add a helper for skipping the HDMI VSDB audio latency fields.
There's a functional change for HDMI VSDB blocks that do not respect the
spec: "I_Latency_Fields_Present shall be zero if Latency_Fields_Present
is zero". We assume this to hold when skipping the latency fields, and
ignore non-zero I_Latency_Fields_Present if Latency_Fields_Present is
zero.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 847076b29594..93067b8dd9f6 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4695,6 +4695,16 @@ static bool hdmi_vsdb_i_latency_present(const u8 *db)
return hdmi_vsdb_latency_present(db) && db[8] & BIT(6);
}
+static int hdmi_vsdb_latency_length(const u8 *db)
+{
+ if (hdmi_vsdb_i_latency_present(db))
+ return 4;
+ else if (hdmi_vsdb_latency_present(db))
+ return 2;
+ else
+ return 0;
+}
+
/*
* do_hdmi_vsdb_modes - Parse the HDMI Vendor Specific data block
* @connector: connector corresponding to the HDMI sink
@@ -4720,13 +4730,7 @@ do_hdmi_vsdb_modes(struct drm_connector *connector,
const u8 *db, u8 len)
if (!(db[8] & (1 << 5)))
goto out;
- /* Latency_Fields_Present */
- if (db[8] & (1 << 7))
- offset += 2;
-
- /* I_Latency_Fields_Present */
- if (db[8] & (1 << 6))
- offset += 2;
+ offset += hdmi_vsdb_latency_length(db);
/* the declared length is not long enough for the 2 first bytes
* of additional video format capabilities */
--
2.34.1
[Intel-gfx] [PATCH v7 09/22] drm/edid: fix and clarify HDMI VSDB audio latency parsing
Add helpers for Latency_Fields_Present and I_Latency_Fields_Present
bits, and fix the parsing:
- Respect specification regarding "I_Latency_Fields_Present shall be
zero if Latency_Fields_Present is zero".
- Don't claim latency fields are present if the data block isn't big
enough to hold them.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 27 +++
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 076ba125c38d..847076b29594 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4685,6 +4685,16 @@ static int add_3d_struct_modes(struct drm_connector
*connector, u16 structure,
return modes;
}
+static bool hdmi_vsdb_latency_present(const u8 *db)
+{
+ return db[8] & BIT(7);
+}
+
+static bool hdmi_vsdb_i_latency_present(const u8 *db)
+{
+ return hdmi_vsdb_latency_present(db) && db[8] & BIT(6);
+}
+
/*
* do_hdmi_vsdb_modes - Parse the HDMI Vendor Specific data block
* @connector: connector corresponding to the HDMI sink
@@ -5357,6 +5367,7 @@ drm_parse_hdr_metadata_block(struct drm_connector
*connector, const u8 *db)
}
}
+/* HDMI Vendor-Specific Data Block (HDMI VSDB, H14b-VSDB) */
static void
drm_parse_hdmi_vsdb_audio(struct drm_connector *connector, const u8 *db)
{
@@ -5364,18 +5375,18 @@ drm_parse_hdmi_vsdb_audio(struct drm_connector
*connector, const u8 *db)
if (len >= 6 && (db[6] & (1 << 7)))
connector->eld[DRM_ELD_SAD_COUNT_CONN_TYPE] |=
DRM_ELD_SUPPORTS_AI;
- if (len >= 8) {
- connector->latency_present[0] = db[8] >> 7;
- connector->latency_present[1] = (db[8] >> 6) & 1;
- }
- if (len >= 9)
+
+ if (len >= 10 && hdmi_vsdb_latency_present(db)) {
+ connector->latency_present[0] = true;
connector->video_latency[0] = db[9];
- if (len >= 10)
connector->audio_latency[0] = db[10];
- if (len >= 11)
+ }
+
+ if (len >= 12 && hdmi_vsdb_i_latency_present(db)) {
+ connector->latency_present[1] = true;
connector->video_latency[1] = db[11];
- if (len >= 12)
connector->audio_latency[1] = db[12];
+ }
drm_dbg_kms(connector->dev,
"[CONNECTOR:%d:%s] HDMI: latency present %d %d, video
latency %d %d, audio latency %d %d\n",
--
2.34.1
[Intel-gfx] [PATCH v7 08/22] drm/edid: split CTA Y420VDB info and mode parsing
Separate the parsing of display info and modes from the CTA
Y420VDB. This is prerequisite work for overall better separation of the
two parsing steps.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index ead7a4ce0422..076ba125c38d 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4497,10 +4497,8 @@ drm_display_mode_from_vic_index(struct drm_connector
*connector, int vic_index)
static int do_y420vdb_modes(struct drm_connector *connector,
const u8 *svds, u8 svds_len)
{
- int modes = 0, i;
struct drm_device *dev = connector->dev;
- struct drm_display_info *info = >display_info;
- struct drm_hdmi_info *hdmi = >hdmi;
+ int modes = 0, i;
for (i = 0; i < svds_len; i++) {
u8 vic = svd_to_vic(svds[i]);
@@ -4512,13 +4510,10 @@ static int do_y420vdb_modes(struct drm_connector
*connector,
newmode = drm_mode_duplicate(dev, cea_mode_for_vic(vic));
if (!newmode)
break;
- bitmap_set(hdmi->y420_vdb_modes, vic, 1);
drm_mode_probed_add(connector, newmode);
modes++;
}
- if (modes > 0)
- info->color_formats |= DRM_COLOR_FORMAT_YCBCR420;
return modes;
}
@@ -5876,6 +5871,26 @@ static bool cta_vdb_has_vic(const struct drm_connector
*connector, u8 vic)
return false;
}
+/* CTA-861-H YCbCr 4:2:0 Video Data Block (CTA Y420VDB) */
+static void parse_cta_y420vdb(struct drm_connector *connector,
+ const struct cea_db *db)
+{
+ struct drm_display_info *info = >display_info;
+ struct drm_hdmi_info *hdmi = >hdmi;
+ const u8 *svds = cea_db_data(db) + 1;
+ int i;
+
+ for (i = 0; i < cea_db_payload_len(db) - 1; i++) {
+ u8 vic = svd_to_vic(svds[i]);
+
+ if (!drm_valid_cea_vic(vic))
+ continue;
+
+ bitmap_set(hdmi->y420_vdb_modes, vic, 1);
+ info->color_formats |= DRM_COLOR_FORMAT_YCBCR420;
+ }
+}
+
static void drm_parse_vcdb(struct drm_connector *connector, const u8 *db)
{
struct drm_display_info *info = >display_info;
@@ -6216,6 +6231,8 @@ static void drm_parse_cea_ext(struct drm_connector
*connector,
drm_parse_microsoft_vsdb(connector, data);
else if (cea_db_is_y420cmdb(db))
parse_cta_y420cmdb(connector, db, _map);
+ else if (cea_db_is_y420vdb(db))
+ parse_cta_y420vdb(connector, db);
else if (cea_db_is_vcdb(db))
drm_parse_vcdb(connector, data);
else if (cea_db_is_hdmi_hdr_metadata_block(db))
--
2.34.1
[Intel-gfx] [PATCH v7 07/22] drm/edid: refactor CTA Y420CMDB parsing
Now that we have pre-parsed CTA VDB VICs stored in info->vics, leverage
that to simplify CTA Y420CMDB parsing. Move updating the y420_cmdb_modes
bitmap to the display info parsing stage, instead of updating it during
add modes. This allows us to drop the intermediate y420_cmdb_map from
display info, and replace it with a local variable.
This is prerequisite work for overall better separation of the two
parsing steps (updating display info and adding modes).
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 86 ++---
include/drm/drm_connector.h | 3 --
2 files changed, 43 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 4e9108e9fc96..ead7a4ce0422 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4522,24 +4522,6 @@ static int do_y420vdb_modes(struct drm_connector
*connector,
return modes;
}
-/*
- * drm_add_cmdb_modes - Add a YCBCR 420 mode into bitmap
- * @connector: connector corresponding to the HDMI sink
- * @vic: CEA vic for the video mode to be added in the map
- *
- * Makes an entry for a videomode in the YCBCR 420 bitmap
- */
-static void
-drm_add_cmdb_modes(struct drm_connector *connector, u8 vic)
-{
- struct drm_hdmi_info *hdmi = >display_info.hdmi;
-
- if (!drm_valid_cea_vic(vic))
- return;
-
- bitmap_set(hdmi->y420_cmdb_modes, vic, 1);
-}
-
/**
* drm_display_mode_from_cea_vic() - return a mode for CEA VIC
* @dev: DRM device
@@ -4572,7 +4554,6 @@ EXPORT_SYMBOL(drm_display_mode_from_cea_vic);
static int add_cta_vdb_modes(struct drm_connector *connector)
{
const struct drm_display_info *info = >display_info;
- const struct drm_hdmi_info *hdmi = >hdmi;
int i, modes = 0;
if (!info->vics)
@@ -4583,18 +4564,6 @@ static int add_cta_vdb_modes(struct drm_connector
*connector)
mode = drm_display_mode_from_vic_index(connector, i);
if (mode) {
- /*
-* YCBCR420 capability block contains a bitmap which
-* gives the index of CEA modes from CEA VDB, which
-* can support YCBCR 420 sampling output also (apart
-* from RGB/YCBCR444 etc).
-* For example, if the bit 0 in bitmap is set,
-* first mode in VDB can support YCBCR420 output too.
-* Add YCBCR420 modes only if sink is HDMI 2.0 capable.
-*/
- if (i < 64 && hdmi->y420_cmdb_map & (1ULL << i))
- drm_add_cmdb_modes(connector, info->vics[i]);
-
drm_mode_probed_add(connector, mode);
modes++;
}
@@ -5188,20 +5157,26 @@ static int edid_hfeeodb_extension_block_count(const
struct edid *edid)
return cta[4 + 2];
}
-static void drm_parse_y420cmdb_bitmap(struct drm_connector *connector,
- const u8 *db)
+/*
+ * CTA-861 YCbCr 4:2:0 Capability Map Data Block (CTA Y420CMDB)
+ *
+ * Y420CMDB contains a bitmap which gives the index of CTA modes from CTA VDB,
+ * which can support YCBCR 420 sampling output also (apart from RGB/YCBCR444
+ * etc). For example, if the bit 0 in bitmap is set, first mode in VDB can
+ * support YCBCR420 output too.
+ */
+static void parse_cta_y420cmdb(struct drm_connector *connector,
+ const struct cea_db *db, u64 *y420cmdb_map)
{
struct drm_display_info *info = >display_info;
- struct drm_hdmi_info *hdmi = >hdmi;
- u8 map_len = cea_db_payload_len(db) - 1;
- u8 count;
+ int i, map_len = cea_db_payload_len(db) - 1;
+ const u8 *data = cea_db_data(db) + 1;
u64 map = 0;
if (map_len == 0) {
/* All CEA modes support ycbcr420 sampling also.*/
- hdmi->y420_cmdb_map = U64_MAX;
- info->color_formats |= DRM_COLOR_FORMAT_YCBCR420;
- return;
+ map = U64_MAX;
+ goto out;
}
/*
@@ -5219,13 +5194,14 @@ static void drm_parse_y420cmdb_bitmap(struct
drm_connector *connector,
if (WARN_ON_ONCE(map_len > 8))
map_len = 8;
- for (count = 0; count < map_len; count++)
- map |= (u64)db[2 + count] << (8 * count);
+ for (i = 0; i < map_len; i++)
+ map |= (u64)data[i] << (8 * i);
+out:
if (map)
info->color_formats |= DRM_COLOR_FORMAT_YCBCR420;
- hdmi->y420_cmdb_map = map;
+ *y420cmdb_map = map;
}
static int add_cea_modes(struct drm_connector *connector,
@@ -5864,6 +5840,26 @@ static void parse_cta_vdb(struct drm_connector
*connector, const struct cea_db *
}
}
+/*
+ * Update y420_cmdb_modes based on previously parsed CTA VDB and Y420CMDB.
+ *
+
[Intel-gfx] [PATCH v7 06/22] drm/edid: rename struct drm_display_info *display to *info
Rename the local variable to info for consistency.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 3dfcd6450f10..4e9108e9fc96 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -6011,14 +6011,14 @@ static void drm_parse_dsc_info(struct drm_hdmi_dsc_cap
*hdmi_dsc,
static void drm_parse_hdmi_forum_scds(struct drm_connector *connector,
const u8 *hf_scds)
{
- struct drm_display_info *display = >display_info;
- struct drm_hdmi_info *hdmi = >hdmi;
+ struct drm_display_info *info = >display_info;
+ struct drm_hdmi_info *hdmi = >hdmi;
struct drm_hdmi_dsc_cap *hdmi_dsc = >dsc_cap;
int max_tmds_clock = 0;
u8 max_frl_rate = 0;
bool dsc_support = false;
- display->has_hdmi_infoframe = true;
+ info->has_hdmi_infoframe = true;
if (hf_scds[6] & 0x80) {
hdmi->scdc.supported = true;
@@ -6042,7 +6042,7 @@ static void drm_parse_hdmi_forum_scds(struct
drm_connector *connector,
max_tmds_clock = hf_scds[5] * 5000;
if (max_tmds_clock > 34) {
- display->max_tmds_clock = max_tmds_clock;
+ info->max_tmds_clock = max_tmds_clock;
}
if (scdc->supported) {
--
2.34.1
[Intel-gfx] [PATCH v7 05/22] drm/edid: use VIC in AVI infoframe if sink lists it in CTA VDB
Apparently there are HDMI 1.4 compatible displays out there that support
VICs from specs later than CTA-861-D, i.e. VIC > 64, although HDMI 1.4
references CTA-861-D only.
We try to avoid using VICs from the later specs in the AVI infoframes to
avoid upsetting sinks that conform to earlier specs.
However, it seems reasonable to do this when the sink claims it supports
the VIC. With the pre-parsed list of VICs handy, this is now trivial.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/6153
Cc: Ville Syrjälä
Cc: William Tseng
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7f0386175230..3dfcd6450f10 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -5864,6 +5864,22 @@ static void parse_cta_vdb(struct drm_connector
*connector, const struct cea_db *
}
}
+static bool cta_vdb_has_vic(const struct drm_connector *connector, u8 vic)
+{
+ const struct drm_display_info *info = >display_info;
+ int i;
+
+ if (!vic || !info->vics)
+ return false;
+
+ for (i = 0; i < info->vics_len; i++) {
+ if (info->vics[i] == vic)
+ return true;
+ }
+
+ return false;
+}
+
static void drm_parse_vcdb(struct drm_connector *connector, const u8 *db)
{
struct drm_display_info *info = >display_info;
@@ -6909,10 +6925,14 @@ static u8 drm_mode_cea_vic(const struct drm_connector
*connector,
*
* HDMI 1.4 (CTA-861-D) VIC range: [1..64]
* HDMI 2.0 (CTA-861-F) VIC range: [1..107]
+ *
+ * If the sink lists the VIC in CTA VDB, assume it's fine, regardless of HDMI
+ * version.
*/
static u8 vic_for_avi_infoframe(const struct drm_connector *connector, u8 vic)
{
- if (!is_hdmi2_sink(connector) && vic > 64)
+ if (!is_hdmi2_sink(connector) && vic > 64 &&
+ !cta_vdb_has_vic(connector, vic))
return 0;
return vic;
--
2.34.1
[Intel-gfx] [PATCH v7 04/22] drm/edid: Use the pre-parsed VICs
Now that we have all the VICs in info->vics, use them to simplify access
based on VIC index, i.e. on the order of VICs in the EDID, and avoid
passing CTA VDB pointers around.
This also fixes the highly unlikely scenarios of a) multiple HDMI VSDBs,
and b) HDMI VSDB 3D modes using VIC indexes that span across multiple
CTA VDBs, and the combination of the two.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 92 +-
1 file changed, 32 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 90846dc69061..7f0386175230 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4468,28 +4468,20 @@ static u8 svd_to_vic(u8 svd)
return svd;
}
+/*
+ * Return a display mode for the 0-based vic_index'th VIC across all CTA VDBs
in
+ * the EDID, or NULL on errors.
+ */
static struct drm_display_mode *
-drm_display_mode_from_vic_index(struct drm_connector *connector,
- const u8 *video_db, u8 video_len,
- u8 video_index)
+drm_display_mode_from_vic_index(struct drm_connector *connector, int vic_index)
{
+ const struct drm_display_info *info = >display_info;
struct drm_device *dev = connector->dev;
- struct drm_display_mode *newmode;
- u8 vic;
- if (video_db == NULL || video_index >= video_len)
+ if (!info->vics || vic_index >= info->vics_len ||
!info->vics[vic_index])
return NULL;
- /* CEA modes are numbered 1..127 */
- vic = svd_to_vic(video_db[video_index]);
- if (!drm_valid_cea_vic(vic))
- return NULL;
-
- newmode = drm_mode_duplicate(dev, cea_mode_for_vic(vic));
- if (!newmode)
- return NULL;
-
- return newmode;
+ return drm_display_mode_from_cea_vic(dev, info->vics[vic_index]);
}
/*
@@ -4538,9 +4530,8 @@ static int do_y420vdb_modes(struct drm_connector
*connector,
* Makes an entry for a videomode in the YCBCR 420 bitmap
*/
static void
-drm_add_cmdb_modes(struct drm_connector *connector, u8 svd)
+drm_add_cmdb_modes(struct drm_connector *connector, u8 vic)
{
- u8 vic = svd_to_vic(svd);
struct drm_hdmi_info *hdmi = >display_info.hdmi;
if (!drm_valid_cea_vic(vic))
@@ -4577,16 +4568,20 @@ drm_display_mode_from_cea_vic(struct drm_device *dev,
}
EXPORT_SYMBOL(drm_display_mode_from_cea_vic);
-static int
-do_cea_modes(struct drm_connector *connector, const u8 *db, u8 len)
+/* Add modes based on VICs parsed in parse_cta_vdb() */
+static int add_cta_vdb_modes(struct drm_connector *connector)
{
+ const struct drm_display_info *info = >display_info;
+ const struct drm_hdmi_info *hdmi = >hdmi;
int i, modes = 0;
- struct drm_hdmi_info *hdmi = >display_info.hdmi;
- for (i = 0; i < len; i++) {
+ if (!info->vics)
+ return 0;
+
+ for (i = 0; i < info->vics_len; i++) {
struct drm_display_mode *mode;
- mode = drm_display_mode_from_vic_index(connector, db, len, i);
+ mode = drm_display_mode_from_vic_index(connector, i);
if (mode) {
/*
* YCBCR420 capability block contains a bitmap which
@@ -4598,7 +4593,7 @@ do_cea_modes(struct drm_connector *connector, const u8
*db, u8 len)
* Add YCBCR420 modes only if sink is HDMI 2.0 capable.
*/
if (i < 64 && hdmi->y420_cmdb_map & (1ULL << i))
- drm_add_cmdb_modes(connector, db[i]);
+ drm_add_cmdb_modes(connector, info->vics[i]);
drm_mode_probed_add(connector, mode);
modes++;
@@ -4693,15 +4688,13 @@ static int add_hdmi_mode(struct drm_connector
*connector, u8 vic)
}
static int add_3d_struct_modes(struct drm_connector *connector, u16 structure,
- const u8 *video_db, u8 video_len, u8 video_index)
+ int vic_index)
{
struct drm_display_mode *newmode;
int modes = 0;
if (structure & (1 << 0)) {
- newmode = drm_display_mode_from_vic_index(connector, video_db,
- video_len,
- video_index);
+ newmode = drm_display_mode_from_vic_index(connector, vic_index);
if (newmode) {
newmode->flags |= DRM_MODE_FLAG_3D_FRAME_PACKING;
drm_mode_probed_add(connector, newmode);
@@ -4709,9 +4702,7 @@ static int add_3d_struct_modes(struct drm_connector
*connector, u16 structure,
}
}
if (structure & (1 << 6)) {
- newmode = drm_display_mode_from_vic_index(connector, video_db,
-
[Intel-gfx] [PATCH v7 03/22] drm/edid: parse VICs from CTA VDB early
A number of places need access to the VICs. Just parse them early for
easy access. Gracefully handle multiple CTA VDBs. It's unlikely to have
more than one, but the CTA-861 references "Video Data Block(s)", so err
on the safe side.
Start parsing them now, convert users in follow-up to have fewer moving
parts in one go.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_connector.c | 1 +
drivers/gpu/drm/drm_edid.c | 36 +
include/drm/drm_connector.h | 10 +
3 files changed, 47 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 8d92777e57dd..21b3df75ab8c 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -565,6 +565,7 @@ void drm_connector_cleanup(struct drm_connector *connector)
ida_free(>mode_config.connector_ida, connector->index);
kfree(connector->display_info.bus_formats);
+ kfree(connector->display_info.vics);
drm_mode_object_unregister(dev, >base);
kfree(connector->name);
connector->name = NULL;
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index b94adb9bbefb..90846dc69061 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -5862,6 +5862,36 @@ drm_default_rgb_quant_range(const struct
drm_display_mode *mode)
}
EXPORT_SYMBOL(drm_default_rgb_quant_range);
+/* CTA-861 Video Data Block (CTA VDB) */
+static void parse_cta_vdb(struct drm_connector *connector, const struct cea_db
*db)
+{
+ struct drm_display_info *info = >display_info;
+ int i, vic_index, len = cea_db_payload_len(db);
+ const u8 *svds = cea_db_data(db);
+ u8 *vics;
+
+ if (!len)
+ return;
+
+ /* Gracefully handle multiple VDBs, however unlikely that is */
+ vics = krealloc(info->vics, info->vics_len + len, GFP_KERNEL);
+ if (!vics)
+ return;
+
+ vic_index = info->vics_len;
+ info->vics_len += len;
+ info->vics = vics;
+
+ for (i = 0; i < len; i++) {
+ u8 vic = svd_to_vic(svds[i]);
+
+ if (!drm_valid_cea_vic(vic))
+ vic = 0;
+
+ info->vics[vic_index++] = vic;
+ }
+}
+
static void drm_parse_vcdb(struct drm_connector *connector, const u8 *db)
{
struct drm_display_info *info = >display_info;
@@ -6205,6 +6235,8 @@ static void drm_parse_cea_ext(struct drm_connector
*connector,
drm_parse_vcdb(connector, data);
else if (cea_db_is_hdmi_hdr_metadata_block(db))
drm_parse_hdr_metadata_block(connector, data);
+ else if (cea_db_tag(db) == CTA_DB_VIDEO)
+ parse_cta_vdb(connector, db);
}
cea_db_iter_end();
}
@@ -6372,6 +6404,10 @@ static void drm_reset_display_info(struct drm_connector
*connector)
info->mso_stream_count = 0;
info->mso_pixel_overlap = 0;
info->max_dsc_bpp = 0;
+
+ kfree(info->vics);
+ info->vics = NULL;
+ info->vics_len = 0;
}
static u32 update_display_info(struct drm_connector *connector,
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 9037f1317aee..d97ed06d5837 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -721,6 +721,16 @@ struct drm_display_info {
* monitor's default value is used instead.
*/
u32 max_dsc_bpp;
+
+ /**
+* @vics: Array of vics_len VICs. Internal to EDID parsing.
+*/
+ u8 *vics;
+
+ /**
+* @vics_len: Number of elements in vics. Internal to EDID parsing.
+*/
+ int vics_len;
};
int drm_display_info_set_bus_formats(struct drm_display_info *info,
--
2.34.1
[Intel-gfx] [PATCH v7 02/22] drm/edid: fix parsing of 3D modes from HDMI VSDB
Commit 537d9ed2f6c1 ("drm/edid: convert add_cea_modes() to use cea db
iter") inadvertently moved the do_hdmi_vsdb_modes() call within the db
iteration loop, always passing NULL as the CTA VDB to
do_hdmi_vsdb_modes(), skipping a lot of stereo modes.
Move the call back outside of the loop.
This does mean only one CTA VDB and HDMI VSDB combination will be
handled, but it's an unlikely scenario to have more than one of either
block, and it was not accounted for before the regression either.
Fixes: 537d9ed2f6c1 ("drm/edid: convert add_cea_modes() to use cea db iter")
Cc: # v6.0+
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 23f7146e6a9b..b94adb9bbefb 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -5249,13 +5249,12 @@ static int add_cea_modes(struct drm_connector
*connector,
{
const struct cea_db *db;
struct cea_db_iter iter;
+ const u8 *hdmi = NULL, *video = NULL;
+ u8 hdmi_len = 0, video_len = 0;
int modes = 0;
cea_db_iter_edid_begin(drm_edid, );
cea_db_iter_for_each(db, ) {
- const u8 *hdmi = NULL, *video = NULL;
- u8 hdmi_len = 0, video_len = 0;
-
if (cea_db_tag(db) == CTA_DB_VIDEO) {
video = cea_db_data(db);
video_len = cea_db_payload_len(db);
@@ -5271,18 +5270,17 @@ static int add_cea_modes(struct drm_connector
*connector,
modes += do_y420vdb_modes(connector, vdb420,
cea_db_payload_len(db) - 1);
}
-
- /*
-* We parse the HDMI VSDB after having added the cea modes as we
-* will be patching their flags when the sink supports stereo
-* 3D.
-*/
- if (hdmi)
- modes += do_hdmi_vsdb_modes(connector, hdmi, hdmi_len,
- video, video_len);
}
cea_db_iter_end();
+ /*
+* We parse the HDMI VSDB after having added the cea modes as we will be
+* patching their flags when the sink supports stereo 3D.
+*/
+ if (hdmi)
+ modes += do_hdmi_vsdb_modes(connector, hdmi, hdmi_len,
+ video, video_len);
+
return modes;
}
--
2.34.1
[Intel-gfx] [PATCH v7 01/22] drm/edid: fix AVI infoframe aspect ratio handling
We try to avoid sending VICs defined in the later specs in AVI
infoframes to sinks that conform to the earlier specs, to not upset
them, and use 0 for the VIC instead. However, we do this detection and
conversion to 0 too early, as we'll need the actual VIC to figure out
the aspect ratio.
In particular, for a mode with 64:27 aspect ratio, 0 for VIC fails the
AVI infoframe generation altogether with -EINVAL.
Separate the VIC lookup from the "filtering", and postpone the
filtering, to use the proper VIC for aspect ratio handling, and the 0
VIC for the infoframe video code as needed.
Reported-by: William Tseng
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6153
References:
https://lore.kernel.org/r/20220920062316.43162-1-william.ts...@intel.com
Cc:
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 3841aba17abd..23f7146e6a9b 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -6885,8 +6885,6 @@ static u8 drm_mode_hdmi_vic(const struct drm_connector
*connector,
static u8 drm_mode_cea_vic(const struct drm_connector *connector,
const struct drm_display_mode *mode)
{
- u8 vic;
-
/*
* HDMI spec says if a mode is found in HDMI 1.4b 4K modes
* we should send its VIC in vendor infoframes, else send the
@@ -6896,13 +6894,18 @@ static u8 drm_mode_cea_vic(const struct drm_connector
*connector,
if (drm_mode_hdmi_vic(connector, mode))
return 0;
- vic = drm_match_cea_mode(mode);
+ return drm_match_cea_mode(mode);
+}
- /*
-* HDMI 1.4 VIC range: 1 <= VIC <= 64 (CEA-861-D) but
-* HDMI 2.0 VIC range: 1 <= VIC <= 107 (CEA-861-F). So we
-* have to make sure we dont break HDMI 1.4 sinks.
-*/
+/*
+ * Avoid sending VICs defined in HDMI 2.0 in AVI infoframes to sinks that
+ * conform to HDMI 1.4.
+ *
+ * HDMI 1.4 (CTA-861-D) VIC range: [1..64]
+ * HDMI 2.0 (CTA-861-F) VIC range: [1..107]
+ */
+static u8 vic_for_avi_infoframe(const struct drm_connector *connector, u8 vic)
+{
if (!is_hdmi2_sink(connector) && vic > 64)
return 0;
@@ -6978,7 +6981,7 @@ drm_hdmi_avi_infoframe_from_display_mode(struct
hdmi_avi_infoframe *frame,
picture_aspect = HDMI_PICTURE_ASPECT_NONE;
}
- frame->video_code = vic;
+ frame->video_code = vic_for_avi_infoframe(connector, vic);
frame->picture_aspect = picture_aspect;
frame->active_aspect = HDMI_ACTIVE_ASPECT_PICTURE;
frame->scan_mode = HDMI_SCAN_MODE_UNDERSCAN;
--
2.34.1
[Intel-gfx] [PATCH v7 00/22] drm/edid: info & modes parsing and drm_edid refactors
Another step deeper into the EDID rabbit hole. v7 of [1], with a bunch of stuff added regarding display info and modes parsing. Primarily separating them to two distinct steps. To do that cleanly, we need a bunch of refactors. This should clean up any inconsistent states with add modes modifying the display info. And generally make the code neater. There are also a couple of bug fixes first. BR, Jani. [1] https://patchwork.freedesktop.org/series/112014/ Jani Nikula (22): drm/edid: fix AVI infoframe aspect ratio handling drm/edid: fix parsing of 3D modes from HDMI VSDB drm/edid: parse VICs from CTA VDB early drm/edid: Use the pre-parsed VICs drm/edid: use VIC in AVI infoframe if sink lists it in CTA VDB drm/edid: rename struct drm_display_info *display to *info drm/edid: refactor CTA Y420CMDB parsing drm/edid: split CTA Y420VDB info and mode parsing drm/edid: fix and clarify HDMI VSDB audio latency parsing drm/edid: add helper for HDMI VSDB audio latency field length drm/edid: split HDMI VSDB info and mode parsing drm/edid: store quirks in display info drm/edid: stop passing quirks around drm/edid: merge ELD handling to update_display_info() drm/edid: move EDID BPC quirk application to update_display_info() drm/edid: refactor _drm_edid_connector_update() and rename drm/edid: add separate drm_edid_connector_add_modes() drm/edid: remove redundant _drm_connector_update_edid_property() drm/i915/edid: convert DP, HDMI and LVDS to drm_edid drm/i915/bios: convert intel_bios_init_panel() to drm_edid drm/i915/opregion: convert intel_opregion_get_edid() to struct drm_edid drm/i915/panel: move panel fixed EDID to struct intel_panel drivers/gpu/drm/drm_connector.c | 1 + drivers/gpu/drm/drm_edid.c| 554 ++ drivers/gpu/drm/drm_probe_helper.c| 4 +- drivers/gpu/drm/i915/display/icl_dsi.c| 2 +- drivers/gpu/drm/i915/display/intel_bios.c | 23 +- drivers/gpu/drm/i915/display/intel_bios.h | 4 +- .../gpu/drm/i915/display/intel_connector.c| 5 +- .../drm/i915/display/intel_display_types.h| 8 +- drivers/gpu/drm/i915/display/intel_dp.c | 91 +-- drivers/gpu/drm/i915/display/intel_dvo.c | 2 +- drivers/gpu/drm/i915/display/intel_hdmi.c | 28 +- drivers/gpu/drm/i915/display/intel_lvds.c | 51 +- drivers/gpu/drm/i915/display/intel_opregion.c | 29 +- drivers/gpu/drm/i915/display/intel_opregion.h | 4 +- drivers/gpu/drm/i915/display/intel_panel.c| 10 +- drivers/gpu/drm/i915/display/intel_panel.h| 4 +- drivers/gpu/drm/i915/display/intel_sdvo.c | 2 +- drivers/gpu/drm/i915/display/vlv_dsi.c| 2 +- include/drm/drm_connector.h | 18 +- include/drm/drm_edid.h| 2 + 20 files changed, 488 insertions(+), 356 deletions(-) -- 2.34.1
Re: [Intel-gfx] [PATCH 1/4] drm/i915/gt: Remove platform comments from workarounds
On 23/12/2022 18:28, Lucas De Marchi wrote:
On Fri, Dec 23, 2022 at 09:02:35AM +, Tvrtko Ursulin wrote:
On 22/12/2022 15:55, Lucas De Marchi wrote:
On Thu, Dec 22, 2022 at 10:27:00AM +, Tvrtko Ursulin wrote:
On 22/12/2022 08:25, Lucas De Marchi wrote:
The comments are redundant to the checks being done to apply the
workarounds and very often get outdated as workarounds need to be
extended to new platforms or steppings. Remove them altogether with
the following matches (platforms extracted from intel_workarounds.c):
find drivers/gpu/drm/i915/gt/ -name '*.c' | xargs sed -i -E \
's/(Wa.*):(bdw|chv|bxt|glk|skl|kbl|cfl|cfl|whl|cml|aml|chv|cl|bw|ctg|elk|ilk|snb|dg|pvc|g4x|ilk|gen|glk|kbl|cml|glk|kbl|cml|hsw|icl|ehl|ivb|hsw|ivb|vlv|kbl|pvc|rkl|dg|adl|skl|skl|bxt|blk|cfl|cnl|glk|snb|tgl|vlv|xehpsdv).*/\1/'
find drivers/gpu/drm/i915/gt/ -name '*.c' | xargs sed -i -E \
's/(Wa.*):(bdw|chv|bxt|glk|skl|kbl|cfl|cfl|whl|cml|aml|chv|cl|bw|ctg|elk|ilk|snb|dg|pvc|g4x|ilk|gen|glk|kbl|cml|glk|kbl|cml|hsw|icl|ehl|ivb|hsw|ivb|vlv|kbl|pvc|rkl|dg|adl|skl|skl|bxt|blk|cfl|cnl|glk|snb|tgl|vlv|xehpsdv).*\*\//\1
Same things was executed in the gem directory, omitted here for
brevity.
There were a few false positives that included the workaround
description. Those were manually patched.
sed -E 's/(Wa[a-zA-Z0-9_]+)[:,]([a-zA-Z0-9,-_\+\[]{2,})/\1/'
then there are false negatives. We have Was in the form
"Wa_xxx:tgl,dg2, mtl". False positives we can fixup, false negatives
we simply don't see. After running that in gt/:
$ git grep ": mtl" -- drivers/gpu/drm/i915/
drivers/gpu/drm/i915/gt/intel_gt_pm.c: /* Wa_14017073508: mtl */
drivers/gpu/drm/i915/gt/intel_gt_pm.c: /* Wa_14017073508: mtl */
drivers/gpu/drm/i915/gt/intel_gt_pm.c: /* Wa_14017073508: mtl */
drivers/gpu/drm/i915/gt/intel_gt_pm.c: /* Wa_14017073508: mtl */
drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c: * Wa_14017073508: mtl
drivers/gpu/drm/i915/i915_reg.h:/* Wa_14017210380: mtl */
I was going with the platform names to avoid the false
negatives and because I was entertaining the idea of only doing this for
latest platforms where we do have the "Wa_[[:number:]]" form
Maybe..
Matt recently said he has this worked planned, but more importantly
- I gather then that the WA lookup tool definitely does not output
these strings?
Whatever it does it's true only at the time it's called. It simply
tells what
are the platforms and steppings the Wa applies to. We can change the
output to whatever we want, but that is not the point.
Those comments get stale and bring no real value as they match 1:1
what the code is supposed to be doing. Several times a patch has to
update just that comment to "extend a workaround" to a next platform.
This is not always done, so we get a comment that doesn't match what is
supposed to be there.
Tl;dr; version - lets park this until January and discuss once
everyone is back.
I'll leave my comment here since I will be out until mid January.
Longer version. I've been trying to get us talking about this a couple
times before and I'd really like to close with an explicit consensus,
discussion points addressed instead of skipped and just moving ahead
with patches.
References:
3fcf71b9-337f-6186-7b00-27cbfd116...@linux.intel.com
Y5j0b/bykbitc...@mdroper-desk1.amr.corp.intel.com
So point I wanted to discuss is whether these comments are truly
useless or maybe they can help during review. If the tool can actually
output them then I am leaning towards that they can be.
I consider "can the tool output xyz?" asking the wrong question.
"The tool", which is our own small python script querying a database can
output anything like that if we want to. The database has information of
what are the platforms/steppings for each the WA is known to be applied
*today*. And that can change and do change often, particularly for early
steppings and recent platforms.
Thought is, when a patch comes for review adding a new platform,
stepping, whatever, to an existing if condition, if it contains the
comments reviewer can more easily spot a hyphotetical logic inversion
error or similar. It is also trivial to check that both condition and
comment have been updated. (So lets not be rash and remove something
maybe useful just because it can go stale *only if* reviewers are not
giving sufficient attention that changes are made in tandem.)
I can argue to the other side too. We don't have comments in the kernel
like
/* Add 1 to i */
i += 1;
This is exactly what these comments are doing. And they are misleading
I'll file this under "Reductio ad absurdum", kind of. :)
and may introduce bugs rather than helping reviewing:
Wa_12345:tgl[a0,c0)
if (IS_TGL_GRAPHICS_STEP(STEP_A0, STEP_B0)
One might read the comment, skipping over the condition and thinking
"ok, we already extended this WA to B* steppings, which doesn't match
the code.
That would be reviewer error to assume B0 is the last B
Re: [Intel-gfx] [PATCH v5 7/7] drm/i915/mtl: Add HDCP GSC interface
On Mon, 02 Jan 2023, Suraj Kandpal wrote:
> MTL uses GSC command streamer i.e gsc cs to send HDCP/PXP commands
> to GSC f/w. It requires to keep hdcp display driver
> agnostic to content protection f/w (ME/GSC fw) in the form of
> i915_hdcp_fw_ops generic ops.
>
> Adding HDCP GSC CS interface by leveraging the i915_hdcp_fw_ops generic
> ops instead of I915_HDCP_COMPONENT as integral part of i915.
>
> Adding checks to see if GSC is loaded and proxy is setup
>
> --v3
> -abstract DISPLAY_VER check [Jani]
> -bring function declaration and definition in same patch[Jani]
>
> Cc: Tomas Winkler
> Cc: Rodrigo Vivi
> Cc: Uma Shankar
> Cc: Ankit Nautiyal
> Signed-off-by: Anshuman Gupta
> Signed-off-by: Suraj Kandpal
> ---
> drivers/gpu/drm/i915/display/intel_hdcp.c | 28 +-
> drivers/gpu/drm/i915/display/intel_hdcp_gsc.c | 513 +-
> drivers/gpu/drm/i915/display/intel_hdcp_gsc.h | 5 +-
> 3 files changed, 537 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index a0f978e56879..0fef4a4356ea 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -25,6 +25,8 @@
> #include "intel_hdcp.h"
> #include "intel_hdcp_regs.h"
> #include "intel_pcode.h"
> +#include "intel_connector.h"
> +#include "intel_hdcp_gsc.h"
>
> #define KEY_LOAD_TRIES 5
> #define HDCP2_LC_RETRY_CNT 3
> @@ -203,13 +205,20 @@ bool intel_hdcp2_capable(struct intel_connector
> *connector)
> struct intel_digital_port *dig_port =
> intel_attached_dig_port(connector);
> struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> struct intel_hdcp *hdcp = >hdcp;
> + struct intel_gt *gt = dev_priv->media_gt;
> + struct intel_gsc_uc *gsc = >uc.gsc;
> bool capable = false;
>
> /* I915 support for HDCP2.2 */
> if (!hdcp->hdcp2_supported)
> return false;
>
> - /* MEI interface is solid */
> + /* If MTL+ make sure gsc is loaded and proxy is setup */
> + if (DISPLAY_VER(dev_priv) >= 14)
> + if (!intel_uc_fw_is_running(>fw))
> + return false;
> +
> + /* MEI/GSC interface is solid depending on which is used */
> mutex_lock(_priv->display.hdcp.comp_mutex);
> if (!dev_priv->display.hdcp.comp_added ||
> !dev_priv->display.hdcp.master) {
> mutex_unlock(_priv->display.hdcp.comp_mutex);
> @@ -2235,7 +2244,7 @@ static int initialize_hdcp_port_data(struct
> intel_connector *connector,
>
> static bool is_hdcp2_supported(struct drm_i915_private *dev_priv)
> {
> - if (!IS_ENABLED(CONFIG_INTEL_MEI_HDCP))
> + if (intel_hdcp_gsc_cs_required(dev_priv) &&
> !IS_ENABLED(CONFIG_INTEL_MEI_HDCP))
> return false;
>
> return (DISPLAY_VER(dev_priv) >= 10 ||
> @@ -2256,10 +2265,14 @@ void intel_hdcp_component_init(struct
> drm_i915_private *dev_priv)
>
> dev_priv->display.hdcp.comp_added = true;
> mutex_unlock(_priv->display.hdcp.comp_mutex);
> - ret = component_add_typed(dev_priv->drm.dev, _hdcp_component_ops,
> - I915_COMPONENT_HDCP);
> +
> + if (intel_hdcp_gsc_cs_required(dev_priv))
> + ret = intel_hdcp_gsc_init(dev_priv);
> + else
> + ret = component_add_typed(dev_priv->drm.dev,
> _hdcp_component_ops,
> + I915_COMPONENT_HDCP);
> if (ret < 0) {
> - drm_dbg_kms(_priv->drm, "Failed at component add(%d)\n",
> + drm_dbg_kms(_priv->drm, "Failed at fw component add(%d)\n",
> ret);
> mutex_lock(_priv->display.hdcp.comp_mutex);
> dev_priv->display.hdcp.comp_added = false;
> @@ -2486,7 +2499,10 @@ void intel_hdcp_component_fini(struct drm_i915_private
> *dev_priv)
> dev_priv->display.hdcp.comp_added = false;
> mutex_unlock(_priv->display.hdcp.comp_mutex);
>
> - component_del(dev_priv->drm.dev, _hdcp_component_ops);
> + if (intel_hdcp_gsc_cs_required(dev_priv))
> + intel_hdcp_gsc_fini(dev_priv);
> + else
> + component_del(dev_priv->drm.dev, _hdcp_component_ops);
> }
>
> void intel_hdcp_cleanup(struct intel_connector *connector)
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
> b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
> index 04d449bc483b..c42aa8b547a4 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
> @@ -1,8 +1,10 @@
> // SPDX-License-Identifier: MIT
> /*
> - * Copyright 2021, Intel Corporation.
> + * Copyright 2022, Intel Corporation.
> */
>
> +#include
> +
> #include "display/intel_hdcp_gsc.h"
> #include "gem/i915_gem_region.h"
> #include "gt/uc/intel_gsc_uc_heci_cmd_submit.h"
> @@ -15,6 +17,512 @@ struct intel_hdcp_gsc_message {
> void *hdcp_cmd;
> };
>
>
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/display: Implement Wa_14015648006 (rev3)
== Series Details ==
Series: drm/i915/display: Implement Wa_14015648006 (rev3)
URL : https://patchwork.freedesktop.org/series/103518/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12541 -> Patchwork_103518v3
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_103518v3 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_103518v3, 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_103518v3/index.html
Participating hosts (42 -> 42)
--
Additional (2): fi-kbl-soraka fi-rkl-11600
Missing(2): bat-dg2-oem1 bat-atsm-1
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_103518v3:
### IGT changes ###
Possible regressions
* igt@debugfs_test@read_all_entries:
- fi-icl-u2: [PASS][1] -> [ABORT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12541/fi-icl-u2/igt@debugfs_test@read_all_entries.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103518v3/fi-icl-u2/igt@debugfs_test@read_all_entries.html
* igt@i915_selftest@live@guc:
- fi-kbl-soraka: NOTRUN -> [INCOMPLETE][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103518v3/fi-kbl-soraka/igt@i915_selftest@l...@guc.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_pm_rpm@basic-rte:
- {bat-adln-1}: [PASS][4] -> [DMESG-WARN][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12541/bat-adln-1/igt@i915_pm_...@basic-rte.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103518v3/bat-adln-1/igt@i915_pm_...@basic-rte.html
* igt@i915_selftest@live@hangcheck:
- {bat-rpls-1}: [PASS][6] -> [INCOMPLETE][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12541/bat-rpls-1/igt@i915_selftest@l...@hangcheck.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103518v3/bat-rpls-1/igt@i915_selftest@l...@hangcheck.html
Known issues
Here are the changes found in Patchwork_103518v3 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@basic-hwmon:
- fi-rkl-11600: NOTRUN -> [SKIP][8] ([i915#7456])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103518v3/fi-rkl-11600/igt@debugfs_t...@basic-hwmon.html
* igt@gem_exec_gttfill@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][9] ([fdo#109271]) +7 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103518v3/fi-kbl-soraka/igt@gem_exec_gttf...@basic.html
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#2190])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103518v3/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
- fi-rkl-11600: NOTRUN -> [SKIP][11] ([i915#2190])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103518v3/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4613]) +3
similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103518v3/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
- fi-rkl-11600: NOTRUN -> [SKIP][13] ([i915#4613]) +3 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103518v3/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html
* igt@gem_tiled_pread_basic:
- fi-rkl-11600: NOTRUN -> [SKIP][14] ([i915#3282])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103518v3/fi-rkl-11600/igt@gem_tiled_pread_basic.html
* igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600: NOTRUN -> [SKIP][15] ([i915#7561])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103518v3/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][16] ([i915#5334])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103518v3/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][17] ([i915#1886])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103518v3/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600: NOTRUN -> [INCOMPLETE][18] ([i915#4817])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103518v3/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_chamelium@common-hpd-after-suspend:
- bat-dg1-6:
Re: [Intel-gfx] [PATCH v5 5/7] drm/i915/hdcp: Fill wired_cmd_in structures at a single place
On Mon, 02 Jan 2023, Suraj Kandpal wrote:
> Need to fill wired cmd in structures at a single place as they remain
> same for both gsc and mei.
I'm still opposed to adding this stuff to i915 and exporting the
symbols. Seems like it should be a separate component, because this is
not about i915.
Cc: other maintainers, please chime in.
BR,
Jani.
>
> --v3
> -remove inline function from header [Jani]
>
> Cc: Ankit Nautiyal
> Signed-off-by: Suraj Kandpal
> ---
> drivers/gpu/drm/i915/Makefile | 1 +
> drivers/gpu/drm/i915/i915_hdcp_interface.c | 216 +
> drivers/misc/mei/hdcp/mei_hdcp.c | 153 ++-
> include/drm/i915_hdcp_interface.h | 39
> 4 files changed, 270 insertions(+), 139 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/i915_hdcp_interface.c
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 461d6b40656d..c6a9826af58d 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -36,6 +36,7 @@ i915-y += i915_driver.o \
> i915_drm_client.o \
> i915_config.o \
> i915_getparam.o \
> + i915_hdcp_interface.o\
> i915_ioctl.o \
> i915_irq.o \
> i915_mitigations.o \
> diff --git a/drivers/gpu/drm/i915/i915_hdcp_interface.c
> b/drivers/gpu/drm/i915/i915_hdcp_interface.c
> new file mode 100644
> index ..e6b787c2fa50
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/i915_hdcp_interface.c
> @@ -0,0 +1,216 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright 2022, Intel Corporation.
> + */
> +
> +#include
> +
> +void
> +i915_hdcp_fill_session_in(struct wired_cmd_initiate_hdcp2_session_in
> *session_init_in,
> + struct hdcp_port_data *data)
> +{
> + session_init_in->header.api_version = HDCP_API_VERSION;
> + session_init_in->header.command_id = WIRED_INITIATE_HDCP2_SESSION;
> + session_init_in->header.status = FW_HDCP_STATUS_SUCCESS;
> + session_init_in->header.buffer_len =
> + WIRED_CMD_BUF_LEN_INITIATE_HDCP2_SESSION_IN;
> +
> + session_init_in->port.integrated_port_type = data->port_type;
> + session_init_in->port.physical_port = (u8)data->hdcp_ddi;
> + session_init_in->port.attached_transcoder = (u8)data->hdcp_transcoder;
> + session_init_in->protocol = data->protocol;
> +}
> +EXPORT_SYMBOL(i915_hdcp_fill_session_in);
> +
> +void
> +i915_hdcp_fill_rxcert_in(struct wired_cmd_verify_receiver_cert_in
> *verify_rxcert_in,
> + struct hdcp2_ake_send_cert *rx_cert,
> + struct hdcp_port_data *data)
> +{
> + verify_rxcert_in->header.api_version = HDCP_API_VERSION;
> + verify_rxcert_in->header.command_id = WIRED_VERIFY_RECEIVER_CERT;
> + verify_rxcert_in->header.status = FW_HDCP_STATUS_SUCCESS;
> + verify_rxcert_in->header.buffer_len =
> + WIRED_CMD_BUF_LEN_VERIFY_RECEIVER_CERT_IN;
> +
> + verify_rxcert_in->port.integrated_port_type = data->port_type;
> + verify_rxcert_in->port.physical_port = (u8)data->hdcp_ddi;
> + verify_rxcert_in->port.attached_transcoder = (u8)data->hdcp_transcoder;
> +
> + verify_rxcert_in->cert_rx = rx_cert->cert_rx;
> + memcpy(verify_rxcert_in->r_rx, _cert->r_rx, HDCP_2_2_RRX_LEN);
> + memcpy(verify_rxcert_in->rx_caps, rx_cert->rx_caps,
> HDCP_2_2_RXCAPS_LEN);
> +}
> +EXPORT_SYMBOL(i915_hdcp_fill_rxcert_in);
> +
> +void
> +i915_hdcp_fill_hprime_in(struct wired_cmd_ake_send_hprime_in *send_hprime_in,
> + struct hdcp2_ake_send_hprime *rx_hprime,
> + struct hdcp_port_data *data)
> +{
> + send_hprime_in->header.api_version = HDCP_API_VERSION;
> + send_hprime_in->header.command_id = WIRED_AKE_SEND_HPRIME;
> + send_hprime_in->header.status = FW_HDCP_STATUS_SUCCESS;
> + send_hprime_in->header.buffer_len =
> WIRED_CMD_BUF_LEN_AKE_SEND_HPRIME_IN;
> +
> + send_hprime_in->port.integrated_port_type = data->port_type;
> + send_hprime_in->port.physical_port = (u8)data->hdcp_ddi;
> + send_hprime_in->port.attached_transcoder = (u8)data->hdcp_transcoder;
> +
> + memcpy(send_hprime_in->h_prime, rx_hprime->h_prime,
> +HDCP_2_2_H_PRIME_LEN);
> +}
> +EXPORT_SYMBOL(i915_hdcp_fill_hprime_in);
> +
> +void
> +i915_hdcp_fill_pairing_info_in(struct wired_cmd_ake_send_pairing_info_in
> *pairing_info_in,
> +struct hdcp2_ake_send_pairing_info *pairing_info,
> +struct hdcp_port_data *data)
> +{
> + pairing_info_in->header.api_version = HDCP_API_VERSION;
> + pairing_info_in->header.command_id = WIRED_AKE_SEND_PAIRING_INFO;
> + pairing_info_in->header.status = FW_HDCP_STATUS_SUCCESS;
> + pairing_info_in->header.buffer_len =
> + WIRED_CMD_BUF_LEN_SEND_PAIRING_INFO_IN;
> +
> + pairing_info_in->port.integrated_port_type = data->port_type;
>
Re: [Intel-gfx] [PATCH v5 2/7] drm/i915/hdcp: Keep cp fw agonstic naming convention
On Wed, 04 Jan 2023, Jani Nikula wrote:
> On Mon, 02 Jan 2023, Suraj Kandpal wrote:
>> From: Anshuman Gupta
>>
>> Change the include/drm/i915_mei_hdcp_interface.h to
>> include/drm/i915_hdcp_interface.h
>
> This breaks the build, because you rename struct members but don't
> rename the users. Every commit needs to be self-contained.
>
> Please always build each commit before submitting, for example:
>
> $ git rebase $baseline --exec="make -j$(nproc)"
>
> where $baseline is the baseline, e.g. drm-tip.
Also, please fix "cp fw agonstic" in the subject.
>
>
> BR,
> Jani.
>
>>
>> Cc: Tomas Winkler
>> Cc: Rodrigo Vivi
>> Cc: Uma Shankar
>> Cc: Ankit Nautiyal
>> Signed-off-by: Anshuman Gupta
>> Signed-off-by: Suraj Kandpal
>> Acked-by: Tomas Winkler
>> ---
>> .../drm/i915/display/intel_display_types.h| 2 +-
>> drivers/misc/mei/hdcp/mei_hdcp.c | 2 +-
>> ...hdcp_interface.h => i915_hdcp_interface.h} | 86 +--
>> 3 files changed, 45 insertions(+), 45 deletions(-)
>> rename include/drm/{i915_mei_hdcp_interface.h => i915_hdcp_interface.h}
>> (75%)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
>> b/drivers/gpu/drm/i915/display/intel_display_types.h
>> index 32e8b2fc3cc6..81d195ef5e57 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
>> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
>> @@ -43,7 +43,7 @@
>> #include
>> #include
>> #include
>> -#include
>> +#include
>> #include
>>
>> #include "i915_vma.h"
>> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
>> b/drivers/misc/mei/hdcp/mei_hdcp.c
>> index e889a8bd7ac8..cbad27511899 100644
>> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
>> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
>> @@ -23,7 +23,7 @@
>> #include
>> #include
>> #include
>> -#include
>> +#include
>>
>> #include "mei_hdcp.h"
>>
>> diff --git a/include/drm/i915_mei_hdcp_interface.h
>> b/include/drm/i915_hdcp_interface.h
>> similarity index 75%
>> rename from include/drm/i915_mei_hdcp_interface.h
>> rename to include/drm/i915_hdcp_interface.h
>> index f441cbcd95a4..d24f6726e50c 100644
>> --- a/include/drm/i915_mei_hdcp_interface.h
>> +++ b/include/drm/i915_hdcp_interface.h
>> @@ -6,8 +6,8 @@
>> * Ramalingam C
>> */
>>
>> -#ifndef _I915_MEI_HDCP_INTERFACE_H_
>> -#define _I915_MEI_HDCP_INTERFACE_H_
>> +#ifndef _I915_HDCP_INTERFACE_H_
>> +#define _I915_HDCP_INTERFACE_H_
>>
>> #include
>> #include
>> @@ -41,44 +41,44 @@ enum hdcp_wired_protocol {
>> HDCP_PROTOCOL_DP
>> };
>>
>> -enum mei_fw_ddi {
>> -MEI_DDI_INVALID_PORT = 0x0,
>> +enum hdcp_ddi {
>> +HDCP_DDI_INVALID_PORT = 0x0,
>>
>> -MEI_DDI_B = 1,
>> -MEI_DDI_C,
>> -MEI_DDI_D,
>> -MEI_DDI_E,
>> -MEI_DDI_F,
>> -MEI_DDI_A = 7,
>> -MEI_DDI_RANGE_END = MEI_DDI_A,
>> +HDCP_DDI_B = 1,
>> +HDCP_DDI_C,
>> +HDCP_DDI_D,
>> +HDCP_DDI_E,
>> +HDCP_DDI_F,
>> +HDCP_DDI_A = 7,
>> +HDCP_DDI_RANGE_END = HDCP_DDI_A,
>> };
>>
>> /**
>> - * enum mei_fw_tc - ME Firmware defined index for transcoders
>> - * @MEI_INVALID_TRANSCODER: Index for Invalid transcoder
>> - * @MEI_TRANSCODER_EDP: Index for EDP Transcoder
>> - * @MEI_TRANSCODER_DSI0: Index for DSI0 Transcoder
>> - * @MEI_TRANSCODER_DSI1: Index for DSI1 Transcoder
>> - * @MEI_TRANSCODER_A: Index for Transcoder A
>> - * @MEI_TRANSCODER_B: Index for Transcoder B
>> - * @MEI_TRANSCODER_C: Index for Transcoder C
>> - * @MEI_TRANSCODER_D: Index for Transcoder D
>> + * enum hdcp_tc - ME Firmware defined index for transcoders
>> + * @HDCP_INVALID_TRANSCODER: Index for Invalid transcoder
>> + * @HDCP_TRANSCODER_EDP: Index for EDP Transcoder
>> + * @HDCP_TRANSCODER_DSI0: Index for DSI0 Transcoder
>> + * @HDCP_TRANSCODER_DSI1: Index for DSI1 Transcoder
>> + * @HDCP_TRANSCODER_A: Index for Transcoder A
>> + * @HDCP_TRANSCODER_B: Index for Transcoder B
>> + * @HDCP_TRANSCODER_C: Index for Transcoder C
>> + * @HDCP_TRANSCODER_D: Index for Transcoder D
>> */
>> -enum mei_fw_tc {
>> -MEI_INVALID_TRANSCODER = 0x00,
>> -MEI_TRANSCODER_EDP,
>> -MEI_TRANSCODER_DSI0,
>> -MEI_TRANSCODER_DSI1,
>> -MEI_TRANSCODER_A = 0x10,
>> -MEI_TRANSCODER_B,
>> -MEI_TRANSCODER_C,
>> -MEI_TRANSCODER_D
>> +enum hdcp_transcoder {
>> +HDCP_INVALID_TRANSCODER = 0x00,
>> +HDCP_TRANSCODER_EDP,
>> +HDCP_TRANSCODER_DSI0,
>> +HDCP_TRANSCODER_DSI1,
>> +HDCP_TRANSCODER_A = 0x10,
>> +HDCP_TRANSCODER_B,
>> +HDCP_TRANSCODER_C,
>> +HDCP_TRANSCODER_D
>> };
>>
>> /**
>> * struct hdcp_port_data - intel specific HDCP port data
>> - * @fw_ddi: ddi index as per ME FW
>> - * @fw_tc: transcoder index as per ME FW
>> + * @hdcp_ddi: ddi index as per ME FW
>> + * @hdcp_transcoder: transcoder index as per ME FW
>> * @port_type: HDCP port type as per ME FW classification
>> * @protocol: HDCP adaptation as per ME FW
>> * @k: No of streams transmitted on a port. Only on DP MST this is != 1
>> @@ -90,8 +90,8 @@
Re: [Intel-gfx] [PATCH v5 2/7] drm/i915/hdcp: Keep cp fw agonstic naming convention
On Mon, 02 Jan 2023, Suraj Kandpal wrote:
> From: Anshuman Gupta
>
> Change the include/drm/i915_mei_hdcp_interface.h to
> include/drm/i915_hdcp_interface.h
This breaks the build, because you rename struct members but don't
rename the users. Every commit needs to be self-contained.
Please always build each commit before submitting, for example:
$ git rebase $baseline --exec="make -j$(nproc)"
where $baseline is the baseline, e.g. drm-tip.
BR,
Jani.
>
> Cc: Tomas Winkler
> Cc: Rodrigo Vivi
> Cc: Uma Shankar
> Cc: Ankit Nautiyal
> Signed-off-by: Anshuman Gupta
> Signed-off-by: Suraj Kandpal
> Acked-by: Tomas Winkler
> ---
> .../drm/i915/display/intel_display_types.h| 2 +-
> drivers/misc/mei/hdcp/mei_hdcp.c | 2 +-
> ...hdcp_interface.h => i915_hdcp_interface.h} | 86 +--
> 3 files changed, 45 insertions(+), 45 deletions(-)
> rename include/drm/{i915_mei_hdcp_interface.h => i915_hdcp_interface.h} (75%)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 32e8b2fc3cc6..81d195ef5e57 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -43,7 +43,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
>
> #include "i915_vma.h"
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index e889a8bd7ac8..cbad27511899 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -23,7 +23,7 @@
> #include
> #include
> #include
> -#include
> +#include
>
> #include "mei_hdcp.h"
>
> diff --git a/include/drm/i915_mei_hdcp_interface.h
> b/include/drm/i915_hdcp_interface.h
> similarity index 75%
> rename from include/drm/i915_mei_hdcp_interface.h
> rename to include/drm/i915_hdcp_interface.h
> index f441cbcd95a4..d24f6726e50c 100644
> --- a/include/drm/i915_mei_hdcp_interface.h
> +++ b/include/drm/i915_hdcp_interface.h
> @@ -6,8 +6,8 @@
> * Ramalingam C
> */
>
> -#ifndef _I915_MEI_HDCP_INTERFACE_H_
> -#define _I915_MEI_HDCP_INTERFACE_H_
> +#ifndef _I915_HDCP_INTERFACE_H_
> +#define _I915_HDCP_INTERFACE_H_
>
> #include
> #include
> @@ -41,44 +41,44 @@ enum hdcp_wired_protocol {
> HDCP_PROTOCOL_DP
> };
>
> -enum mei_fw_ddi {
> - MEI_DDI_INVALID_PORT = 0x0,
> +enum hdcp_ddi {
> + HDCP_DDI_INVALID_PORT = 0x0,
>
> - MEI_DDI_B = 1,
> - MEI_DDI_C,
> - MEI_DDI_D,
> - MEI_DDI_E,
> - MEI_DDI_F,
> - MEI_DDI_A = 7,
> - MEI_DDI_RANGE_END = MEI_DDI_A,
> + HDCP_DDI_B = 1,
> + HDCP_DDI_C,
> + HDCP_DDI_D,
> + HDCP_DDI_E,
> + HDCP_DDI_F,
> + HDCP_DDI_A = 7,
> + HDCP_DDI_RANGE_END = HDCP_DDI_A,
> };
>
> /**
> - * enum mei_fw_tc - ME Firmware defined index for transcoders
> - * @MEI_INVALID_TRANSCODER: Index for Invalid transcoder
> - * @MEI_TRANSCODER_EDP: Index for EDP Transcoder
> - * @MEI_TRANSCODER_DSI0: Index for DSI0 Transcoder
> - * @MEI_TRANSCODER_DSI1: Index for DSI1 Transcoder
> - * @MEI_TRANSCODER_A: Index for Transcoder A
> - * @MEI_TRANSCODER_B: Index for Transcoder B
> - * @MEI_TRANSCODER_C: Index for Transcoder C
> - * @MEI_TRANSCODER_D: Index for Transcoder D
> + * enum hdcp_tc - ME Firmware defined index for transcoders
> + * @HDCP_INVALID_TRANSCODER: Index for Invalid transcoder
> + * @HDCP_TRANSCODER_EDP: Index for EDP Transcoder
> + * @HDCP_TRANSCODER_DSI0: Index for DSI0 Transcoder
> + * @HDCP_TRANSCODER_DSI1: Index for DSI1 Transcoder
> + * @HDCP_TRANSCODER_A: Index for Transcoder A
> + * @HDCP_TRANSCODER_B: Index for Transcoder B
> + * @HDCP_TRANSCODER_C: Index for Transcoder C
> + * @HDCP_TRANSCODER_D: Index for Transcoder D
> */
> -enum mei_fw_tc {
> - MEI_INVALID_TRANSCODER = 0x00,
> - MEI_TRANSCODER_EDP,
> - MEI_TRANSCODER_DSI0,
> - MEI_TRANSCODER_DSI1,
> - MEI_TRANSCODER_A = 0x10,
> - MEI_TRANSCODER_B,
> - MEI_TRANSCODER_C,
> - MEI_TRANSCODER_D
> +enum hdcp_transcoder {
> + HDCP_INVALID_TRANSCODER = 0x00,
> + HDCP_TRANSCODER_EDP,
> + HDCP_TRANSCODER_DSI0,
> + HDCP_TRANSCODER_DSI1,
> + HDCP_TRANSCODER_A = 0x10,
> + HDCP_TRANSCODER_B,
> + HDCP_TRANSCODER_C,
> + HDCP_TRANSCODER_D
> };
>
> /**
> * struct hdcp_port_data - intel specific HDCP port data
> - * @fw_ddi: ddi index as per ME FW
> - * @fw_tc: transcoder index as per ME FW
> + * @hdcp_ddi: ddi index as per ME FW
> + * @hdcp_transcoder: transcoder index as per ME FW
> * @port_type: HDCP port type as per ME FW classification
> * @protocol: HDCP adaptation as per ME FW
> * @k: No of streams transmitted on a port. Only on DP MST this is != 1
> @@ -90,8 +90,8 @@ enum mei_fw_tc {
> *streams
> */
> struct hdcp_port_data {
> - enum mei_fw_ddi fw_ddi;
> - enum mei_fw_tc fw_tc;
> + enum hdcp_ddi hdcp_ddi;
> + enum hdcp_transcoder hdcp_transcoder;
> u8
Re: [Intel-gfx] [PATCH] drm/i915: Expand force_probe to block probe of devices as well.
On Tue, 03 Jan 2023, Rodrigo Vivi wrote:
> There are new cases where we want to block i915 probe, such
> as when experimenting or developing the new Xe driver.
>
> But also, with the new hibrid cards, users or developers might
*hybrid
> want to use i915 only on integrated and fully block the probe
> of the i915 for the discrete. Or vice versa.
>
> Oh, and there are even older development and validation reasons,
> like when you use some distro where the modprobe.blacklist is
> not present.
Maybe s/Oh, and t/T/
>
> But in any case, let's introduce a more granular control, but without
> introducing yet another parameter, but using the existent force_probe
> one.
>
> Just by adding a ! in the begin of the id in the force_probe, like
> in this case where we would block the probe for Alder Lake:
>
> $ insmod i915.ko force_probe='!46a6'
>
> v2: Take care of '*' and '!*' cases as pointed out by
> Gustavo and Jani.
>
> Cc: Jani Nikula
> Cc: Gustavo Sousa
> Signed-off-by: Rodrigo Vivi
Reviewed-by: Jani Nikula
That said, there's no way to do stuff like "1234,!*" to force 1234 but
block everything else. Can be added later as needed.
Also, "1234,!1234" and "!1234,1234" both block 1234. Sure, user error,
but just noting. Can be tweaked later as needed.
BR,
Jani.
> ---
> drivers/gpu/drm/i915/Kconfig | 15 +++---
> drivers/gpu/drm/i915/i915_params.c | 2 +-
> drivers/gpu/drm/i915/i915_pci.c| 33 +-
> 3 files changed, 41 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 3efce05d7b57..8eb3e60aeec9 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -54,24 +54,33 @@ config DRM_I915
> If "M" is selected, the module will be called i915.
>
> config DRM_I915_FORCE_PROBE
> - string "Force probe driver for selected new Intel hardware"
> + string "Force probe i915 for selected Intel hardware IDs"
> depends on DRM_I915
> help
> This is the default value for the i915.force_probe module
> parameter. Using the module parameter overrides this option.
>
> - Force probe the driver for new Intel graphics devices that are
> + Force probe the i915 for Intel graphics devices that are
> recognized but not properly supported by this kernel version. It is
> recommended to upgrade to a kernel version with proper support as soon
> as it is available.
>
> + It can also be used to block the probe of recognized and fully
> + supported devices.
> +
> Use "" to disable force probe. If in doubt, use this.
>
> - Use "[,,...]" to force probe the driver for listed
> + Use "[,,...]" to force probe the i915 for listed
> devices. For example, "4500" or "4500,4571".
>
> Use "*" to force probe the driver for all known devices.
>
> + Use "!" right before the ID to block the probe of the device. For
> + example, "4500,!4571" forces the probe of 4500 and blocks the probe of
> + 4571.
> +
> + Use "!*" to block the probe of the driver for all known devices.
> +
> config DRM_I915_CAPTURE_ERROR
> bool "Enable capturing GPU state following a hang"
> depends on DRM_I915
> diff --git a/drivers/gpu/drm/i915/i915_params.c
> b/drivers/gpu/drm/i915/i915_params.c
> index 61578f2860cd..d634bd3f641a 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -122,7 +122,7 @@ i915_param_named_unsafe(enable_psr2_sel_fetch, bool, 0400,
> "Default: 0");
>
> i915_param_named_unsafe(force_probe, charp, 0400,
> - "Force probe the driver for specified devices. "
> + "Force probe options for specified supported devices. "
> "See CONFIG_DRM_I915_FORCE_PROBE for details.");
>
> i915_param_named_unsafe(disable_power_well, int, 0400,
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 7fd74cc28c0a..bc1af7e8f398 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -1253,7 +1253,7 @@ static void i915_pci_remove(struct pci_dev *pdev)
> }
>
> /* is device_id present in comma separated list of ids */
> -static bool force_probe(u16 device_id, const char *devices)
> +static bool device_id_in_list(u16 device_id, const char *devices, bool
> negative)
> {
> char *s, *p, *tok;
> bool ret;
> @@ -1262,7 +1262,9 @@ static bool force_probe(u16 device_id, const char
> *devices)
> return false;
>
> /* match everything */
> - if (strcmp(devices, "*") == 0)
> + if (negative && strcmp(devices, "!*") == 0)
> + return true;
> + if (!negative && strcmp(devices, "*") == 0)
> return true;
>
> s = kstrdup(devices, GFP_KERNEL);
> @@ -1272,6 +1274,12 @@ static bool force_probe(u16 device_id, const char
> *devices)
> for (p = s, ret = false; (tok =
Re: [Intel-gfx] [PATCH] drm/i915: Fix potential context UAFs
On 03/01/2023 23:49, Rob Clark wrote:
From: Rob Clark
gem_context_register() makes the context visible to userspace, and which
point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl.
So we need to ensure that nothing uses the ctx ptr after this. And we
need to ensure that adding the ctx to the xarray is the *last* thing
that gem_context_register() does with the ctx pointer.
Any backtraces from oopses or notes on how it was found to record in the commit
message?
Signed-off-by: Rob Clark
Fixes: a4c1cdd34e2c ("drm/i915/gem: Delay context creation (v3)")
References: 3aa9945a528e ("drm/i915: Separate GEM context construction and
registration to userspace")
Cc: # v5.15+
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 24 +++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 7f2831efc798..6250de9b9196 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1688,6 +1688,10 @@ void i915_gem_init__contexts(struct drm_i915_private
*i915)
init_contexts(>gem.contexts);
}
+/*
+ * Note that this implicitly consumes the ctx reference, by placing
+ * the ctx in the context_xa.
+ */
static void gem_context_register(struct i915_gem_context *ctx,
struct drm_i915_file_private *fpriv,
u32 id)
@@ -1703,10 +1707,6 @@ static void gem_context_register(struct i915_gem_context
*ctx,
snprintf(ctx->name, sizeof(ctx->name), "%s[%d]",
current->comm, pid_nr(ctx->pid));
- /* And finally expose ourselves to userspace via the idr */
- old = xa_store(>context_xa, id, ctx, GFP_KERNEL);
- WARN_ON(old);
-
spin_lock(>client->ctx_lock);
list_add_tail_rcu(>client_link, >client->ctx_list);
spin_unlock(>client->ctx_lock);
@@ -1714,6 +1714,10 @@ static void gem_context_register(struct i915_gem_context
*ctx,
spin_lock(>gem.contexts.lock);
list_add_tail(>link, >gem.contexts.list);
spin_unlock(>gem.contexts.lock);
+
+ /* And finally expose ourselves to userspace via the idr */
+ old = xa_store(>context_xa, id, ctx, GFP_KERNEL);
+ WARN_ON(old);
Have you seen that this hunk is needed or just moving it for a good measure? To
be clear, it is probably best to move it even if the current placement cannot
cause any problems, I am just double-checking if you had any concrete
observations here while mulling over easier stable backports if we would omit
it.
}
int i915_gem_context_open(struct drm_i915_private *i915,
@@ -2199,14 +2203,22 @@ finalize_create_context_locked(struct
drm_i915_file_private *file_priv,
if (IS_ERR(ctx))
return ctx;
+ /*
+* One for the xarray and one for the caller. We need to grab
+* the reference *prior* to making the ctx visble to userspace
+* in gem_context_register(), as at any point after that
+* userspace can try to race us with another thread destroying
+* the context under our feet.
+*/
+ i915_gem_context_get(ctx);
+
gem_context_register(ctx, file_priv, id);
old = xa_erase(_priv->proto_context_xa, id);
GEM_BUG_ON(old != pc);
proto_context_close(file_priv->dev_priv, pc);
- /* One for the xarray and one for the caller */
- return i915_gem_context_get(ctx);
+ return ctx;
Otherwise userspace can look up a context which hasn't had it's reference count
increased yep. I can add the Fixes: and Stable: tags while merging if no
complaints.
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
}
struct i915_gem_context *
Re: [Intel-gfx] [PATCH v2] drm/i915/display: Implement Wa_14015648006
On Wed, 04 Jan 2023, Jouni Högander wrote:
> Add 4th pipe and extend TGL Wa_16013835468 to support ADLP, MTL and
> DG2 and all TGL steppings.
Please prefix the subject with "drm/i915/psr" instead of the overly
generic "display".
>
> BSpec: 54369, 55378, 66624
>
> v2:
> - apply for PSR1 as well
> - remove stepping information from comments
>
> Cc: Matt Roper
> Cc: José Roberto de Souza
> Cc: Stanislav Lisovskiy
>
Nitpick, while at it, please no blank lines between tags.
Both of the above can be fixed while applying if there's no other reason
to resend the patch.
BR,
Jani.
> Signed-off-by: Mika Kahola
> Signed-off-by: Jouni Högander
> ---
> drivers/gpu/drm/i915/display/intel_psr.c | 48 ++--
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> 2 files changed, 29 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index d0d774219cc5..507f810d4a4a 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1112,6 +1112,8 @@ static u32 wa_16013835468_bit_get(struct intel_dp
> *intel_dp)
> return LATENCY_REPORTING_REMOVED_PIPE_B;
> case PIPE_C:
> return LATENCY_REPORTING_REMOVED_PIPE_C;
> + case PIPE_D:
> + return LATENCY_REPORTING_REMOVED_PIPE_D;
> default:
> MISSING_CASE(intel_dp->psr.pipe);
> return 0;
> @@ -1163,6 +1165,23 @@ static void intel_psr_enable_source(struct intel_dp
> *intel_dp,
>intel_dp->psr.psr2_sel_fetch_enabled ?
>IGNORE_PSR2_HW_TRACKING : 0);
>
> + /*
> + * Wa_16013835468
> + * Wa_14015648006
> + */
> + if (IS_MTL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0) ||
> + IS_DISPLAY_VER(dev_priv, 12, 13)) {
> + u16 vtotal, vblank;
> +
> + vtotal = crtc_state->uapi.adjusted_mode.crtc_vtotal -
> + crtc_state->uapi.adjusted_mode.crtc_vdisplay;
> + vblank = crtc_state->uapi.adjusted_mode.crtc_vblank_end -
> + crtc_state->uapi.adjusted_mode.crtc_vblank_start;
> + if (vblank > vtotal)
> + intel_de_rmw(dev_priv, GEN8_CHICKEN_DCPR_1, 0,
> + wa_16013835468_bit_get(intel_dp));
> + }
> +
> if (intel_dp->psr.psr2_enabled) {
> if (DISPLAY_VER(dev_priv) == 9)
> intel_de_rmw(dev_priv, CHICKEN_TRANS(cpu_transcoder), 0,
> @@ -1196,20 +1215,6 @@ static void intel_psr_enable_source(struct intel_dp
> *intel_dp,
> else if (IS_ALDERLAKE_P(dev_priv))
> intel_de_rmw(dev_priv, CLKGATE_DIS_MISC, 0,
>CLKGATE_DIS_MISC_DMASC_GATING_DIS);
> -
> - /* Wa_16013835468:tgl[b0+], dg1 */
> - if (IS_TGL_DISPLAY_STEP(dev_priv, STEP_B0, STEP_FOREVER) ||
> - IS_DG1(dev_priv)) {
> - u16 vtotal, vblank;
> -
> - vtotal = crtc_state->uapi.adjusted_mode.crtc_vtotal -
> - crtc_state->uapi.adjusted_mode.crtc_vdisplay;
> - vblank = crtc_state->uapi.adjusted_mode.crtc_vblank_end
> -
> -
> crtc_state->uapi.adjusted_mode.crtc_vblank_start;
> - if (vblank > vtotal)
> - intel_de_rmw(dev_priv, GEN8_CHICKEN_DCPR_1, 0,
> - wa_16013835468_bit_get(intel_dp));
> - }
> }
> }
>
> @@ -1362,6 +1367,15 @@ static void intel_psr_disable_locked(struct intel_dp
> *intel_dp)
> intel_de_rmw(dev_priv, CHICKEN_PAR1_1,
>DIS_RAM_BYPASS_PSR2_MAN_TRACK, 0);
>
> + /*
> + * Wa_16013835468
> + * Wa_14015648006
> + */
> + if (IS_MTL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0) ||
> + IS_DISPLAY_VER(dev_priv, 12, 13))
> + intel_de_rmw(dev_priv, GEN8_CHICKEN_DCPR_1,
> + wa_16013835468_bit_get(intel_dp), 0);
> +
> if (intel_dp->psr.psr2_enabled) {
> /* Wa_16011168373:adl-p */
> if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0))
> @@ -1377,12 +1391,6 @@ static void intel_psr_disable_locked(struct intel_dp
> *intel_dp)
> else if (IS_ALDERLAKE_P(dev_priv))
> intel_de_rmw(dev_priv, CLKGATE_DIS_MISC,
>CLKGATE_DIS_MISC_DMASC_GATING_DIS, 0);
> -
> - /* Wa_16013835468:tgl[b0+], dg1 */
> - if (IS_TGL_DISPLAY_STEP(dev_priv, STEP_B0, STEP_FOREVER) ||
> - IS_DG1(dev_priv))
> - intel_de_rmw(dev_priv, GEN8_CHICKEN_DCPR_1,
> - wa_16013835468_bit_get(intel_dp), 0);
> }
>
> intel_snps_phy_update_psr_power_state(dev_priv,
Re: [Intel-gfx] [PATCH 03/13] drm/i915/dsb: Align DSB register writes to 8 bytes
> -Original Message- > From: Intel-gfx On Behalf Of Ville > Syrjala > Sent: Friday, December 16, 2022 6:08 AM > To: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH 03/13] drm/i915/dsb: Align DSB register writes to > 8 bytes > > From: Ville Syrjälä > > Every DSB instruction has to be 8byte aligned. Make sure that is the case for > the non-indexed register writes as well. > The way this could end up unaligned is we emitted an odd number of > indexed register writes beforehand. > > Signed-off-by: Ville Syrjälä LGTM. Reviewed-by: Animesh Manna > --- > drivers/gpu/drm/i915/display/intel_dsb.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c > b/drivers/gpu/drm/i915/display/intel_dsb.c > index 90a22af30aab..6abfd0fc541a 100644 > --- a/drivers/gpu/drm/i915/display/intel_dsb.c > +++ b/drivers/gpu/drm/i915/display/intel_dsb.c > @@ -172,6 +172,9 @@ void intel_dsb_reg_write(struct intel_dsb *dsb, > return; > } > > + /* Every instruction should be 8 byte aligned. */ > + dsb->free_pos = ALIGN(dsb->free_pos, 2); > + > dsb->ins_start_offset = dsb->free_pos; > buf[dsb->free_pos++] = val; > buf[dsb->free_pos++] = (DSB_OPCODE_MMIO_WRITE << > DSB_OPCODE_SHIFT) | > -- > 2.37.4
Re: [Intel-gfx] [PATCH] drm/i915/display: Implement Wa_14015648006
On Tue, 2023-01-03 at 16:40 -0800, Matt Roper wrote:
> On Wed, Dec 21, 2022 at 03:21:18PM +0200, Jouni Högander wrote:
> > Add 4th pipe and extend TGL Wa_16013835468 to support ADLP, MTL and
> > DG2 and all TGL steppings.
> >
> > BSpec: 54369, 55378, 66624
> >
> > Cc: Matt Roper
> > Cc: José Roberto de Souza
> > Cc: Stanislav Lisovskiy
> >
> > Signed-off-by: Mika Kahola
> > Signed-off-by: Jouni Högander
> > ---
> > drivers/gpu/drm/i915/display/intel_psr.c | 20 ++--
> > drivers/gpu/drm/i915/i915_reg.h | 1 +
> > 2 files changed, 15 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index 9820e5fdd087..0d01b8a7a75d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -1112,6 +1112,8 @@ static u32 wa_16013835468_bit_get(struct
> > intel_dp *intel_dp)
> > return LATENCY_REPORTING_REMOVED_PIPE_B;
> > case PIPE_C:
> > return LATENCY_REPORTING_REMOVED_PIPE_C;
> > + case PIPE_D:
> > + return LATENCY_REPORTING_REMOVED_PIPE_D;
> > default:
> > MISSING_CASE(intel_dp->psr.pipe);
> > return 0;
> > @@ -1197,9 +1199,12 @@ static void intel_psr_enable_source(struct
> > intel_dp *intel_dp,
> > intel_de_rmw(dev_priv, CLKGATE_DIS_MISC, 0,
> >
> > CLKGATE_DIS_MISC_DMASC_GATING_DIS);
> >
> > - /* Wa_16013835468:tgl[b0+], dg1 */
> > - if (IS_TGL_DISPLAY_STEP(dev_priv, STEP_B0,
> > STEP_FOREVER) ||
> > - IS_DG1(dev_priv)) {
> > + /*
> > + * Wa_16013835468:tgl[b0+], dg1,
> > + * Wa_14015648006:adlp[a0+], mtl[a0], dg2, tgl[a0+]
> > + */
> > + if (IS_MTL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0)
> > ||
> > + IS_DISPLAY_VER(dev_priv, 12, 13)) {
>
> There's another thread where we're discussing possibly dropping all
> of
> the platform/stepping information from workaround comments, but this
> is
> a great supporting example for why the detailed comments are causing
> more confusion than they're worth. The code condition includes RKL
> and
> ADL-S, whereas the comment does not mention them. In this case the
> code
> is correct and the comment is incomplete.
>
> If we move forward with Lucas' patch, this should just turn into
>
> /*
> * Wa_16013835468
> * Wa_14015648006
> */
>
> and let the code speak for itself about which platform(s) it covers.
>
>
> As for the workaround itself here, the existing implementation of
> Wa_16013835468 is in a 'if (intel_dp->psr.psr2_enabled)' but it looks
> like the description of the new Wa_14015648006 is also supposed to
> apply
> to PSR1 as well. Do we need to lift these out of that conditional
> block?
You are right. It should be applied for PSR1 as well.
Thank you for all your comments. Addressed all of them in new version.
Please check.
>
>
> Matt
>
> > u16 vtotal, vblank;
> >
> > vtotal = crtc_state-
> > >uapi.adjusted_mode.crtc_vtotal -
> > @@ -1378,9 +1383,12 @@ static void intel_psr_disable_locked(struct
> > intel_dp *intel_dp)
> > intel_de_rmw(dev_priv, CLKGATE_DIS_MISC,
> >
> > CLKGATE_DIS_MISC_DMASC_GATING_DIS, 0);
> >
> > - /* Wa_16013835468:tgl[b0+], dg1 */
> > - if (IS_TGL_DISPLAY_STEP(dev_priv, STEP_B0,
> > STEP_FOREVER) ||
> > - IS_DG1(dev_priv))
> > + /*
> > + * Wa_16013835468:tgl[b0+], dg1,
> > + * Wa_14015648006:adlp[a0+], mtl[a0], dg2, tgl[a0+]
> > + */
> > + if (IS_MTL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0)
> > ||
> > + IS_DISPLAY_VER(dev_priv, 12, 13))
> > intel_de_rmw(dev_priv, GEN8_CHICKEN_DCPR_1,
> >
> > wa_16013835468_bit_get(intel_dp), 0);
> > }
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index cef9418beec0..a70a1b6e6a15 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -5737,6 +5737,7 @@
> > #define RESET_PCH_HANDSHAKE_ENABLEREG_BIT(4)
> >
> > #define GEN8_CHICKEN_DCPR_1_MMIO(0x46430)
> > +#define LATENCY_REPORTING_REMOVED_PIPE_D REG_BIT(31)
> > #define SKL_SELECT_ALTERNATE_DC_EXIT REG_BIT(30)
> > #define LATENCY_REPORTING_REMOVED_PIPE_C REG_BIT(25)
> > #define LATENCY_REPORTING_REMOVED_PIPE_B REG_BIT(24)
> > --
> > 2.34.1
> >
>
[Intel-gfx] [PATCH v2] drm/i915/display: Implement Wa_14015648006
Add 4th pipe and extend TGL Wa_16013835468 to support ADLP, MTL and
DG2 and all TGL steppings.
BSpec: 54369, 55378, 66624
v2:
- apply for PSR1 as well
- remove stepping information from comments
Cc: Matt Roper
Cc: José Roberto de Souza
Cc: Stanislav Lisovskiy
Signed-off-by: Mika Kahola
Signed-off-by: Jouni Högander
---
drivers/gpu/drm/i915/display/intel_psr.c | 48 ++--
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files changed, 29 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index d0d774219cc5..507f810d4a4a 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1112,6 +1112,8 @@ static u32 wa_16013835468_bit_get(struct intel_dp
*intel_dp)
return LATENCY_REPORTING_REMOVED_PIPE_B;
case PIPE_C:
return LATENCY_REPORTING_REMOVED_PIPE_C;
+ case PIPE_D:
+ return LATENCY_REPORTING_REMOVED_PIPE_D;
default:
MISSING_CASE(intel_dp->psr.pipe);
return 0;
@@ -1163,6 +1165,23 @@ static void intel_psr_enable_source(struct intel_dp
*intel_dp,
intel_dp->psr.psr2_sel_fetch_enabled ?
IGNORE_PSR2_HW_TRACKING : 0);
+ /*
+* Wa_16013835468
+* Wa_14015648006
+*/
+ if (IS_MTL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0) ||
+ IS_DISPLAY_VER(dev_priv, 12, 13)) {
+ u16 vtotal, vblank;
+
+ vtotal = crtc_state->uapi.adjusted_mode.crtc_vtotal -
+ crtc_state->uapi.adjusted_mode.crtc_vdisplay;
+ vblank = crtc_state->uapi.adjusted_mode.crtc_vblank_end -
+ crtc_state->uapi.adjusted_mode.crtc_vblank_start;
+ if (vblank > vtotal)
+ intel_de_rmw(dev_priv, GEN8_CHICKEN_DCPR_1, 0,
+wa_16013835468_bit_get(intel_dp));
+ }
+
if (intel_dp->psr.psr2_enabled) {
if (DISPLAY_VER(dev_priv) == 9)
intel_de_rmw(dev_priv, CHICKEN_TRANS(cpu_transcoder), 0,
@@ -1196,20 +1215,6 @@ static void intel_psr_enable_source(struct intel_dp
*intel_dp,
else if (IS_ALDERLAKE_P(dev_priv))
intel_de_rmw(dev_priv, CLKGATE_DIS_MISC, 0,
CLKGATE_DIS_MISC_DMASC_GATING_DIS);
-
- /* Wa_16013835468:tgl[b0+], dg1 */
- if (IS_TGL_DISPLAY_STEP(dev_priv, STEP_B0, STEP_FOREVER) ||
- IS_DG1(dev_priv)) {
- u16 vtotal, vblank;
-
- vtotal = crtc_state->uapi.adjusted_mode.crtc_vtotal -
-crtc_state->uapi.adjusted_mode.crtc_vdisplay;
- vblank = crtc_state->uapi.adjusted_mode.crtc_vblank_end
-
-
crtc_state->uapi.adjusted_mode.crtc_vblank_start;
- if (vblank > vtotal)
- intel_de_rmw(dev_priv, GEN8_CHICKEN_DCPR_1, 0,
-wa_16013835468_bit_get(intel_dp));
- }
}
}
@@ -1362,6 +1367,15 @@ static void intel_psr_disable_locked(struct intel_dp
*intel_dp)
intel_de_rmw(dev_priv, CHICKEN_PAR1_1,
DIS_RAM_BYPASS_PSR2_MAN_TRACK, 0);
+ /*
+* Wa_16013835468
+* Wa_14015648006
+*/
+ if (IS_MTL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0) ||
+ IS_DISPLAY_VER(dev_priv, 12, 13))
+ intel_de_rmw(dev_priv, GEN8_CHICKEN_DCPR_1,
+wa_16013835468_bit_get(intel_dp), 0);
+
if (intel_dp->psr.psr2_enabled) {
/* Wa_16011168373:adl-p */
if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0))
@@ -1377,12 +1391,6 @@ static void intel_psr_disable_locked(struct intel_dp
*intel_dp)
else if (IS_ALDERLAKE_P(dev_priv))
intel_de_rmw(dev_priv, CLKGATE_DIS_MISC,
CLKGATE_DIS_MISC_DMASC_GATING_DIS, 0);
-
- /* Wa_16013835468:tgl[b0+], dg1 */
- if (IS_TGL_DISPLAY_STEP(dev_priv, STEP_B0, STEP_FOREVER) ||
- IS_DG1(dev_priv))
- intel_de_rmw(dev_priv, GEN8_CHICKEN_DCPR_1,
-wa_16013835468_bit_get(intel_dp), 0);
}
intel_snps_phy_update_psr_power_state(dev_priv, phy, false);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8b2cf980f323..b0b3b511e19f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5737,6 +5737,7 @@
#define RESET_PCH_HANDSHAKE_ENABLEREG_BIT(4)
#define GEN8_CHICKEN_DCPR_1_MMIO(0x46430)
+#define LATENCY_REPORTING_REMOVED_PIPE_D
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Consolidate TLB invalidation flow
On 03.01.2023 20:57, Matt Roper wrote:
On Mon, Dec 19, 2022 at 05:10:02PM +0100, Andrzej Hajda wrote:
On 19.12.2022 11:13, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
As the logic for selecting the register and corresponsing values grew, the
corresponding
code become a bit unsightly. Consolidate by storing the required values at
engine init time in the engine itself, and by doing so minimise the amount
of invariant platform and engine checks during each and every TLB
invalidation.
v2:
* Fail engine probe if TLB invlidations registers are unknown.
Signed-off-by: Tvrtko Ursulin
Cc: Andrzej Hajda
Cc: Matt Roper
Reviewed-by: Andrzej Hajda # v1
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 93 +
drivers/gpu/drm/i915/gt/intel_engine_types.h | 15 +++
drivers/gpu/drm/i915/gt/intel_gt.c | 135 +++
3 files changed, 128 insertions(+), 115 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 99c4b866addd..d47dadfc25c8 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1143,12 +1143,105 @@ static int init_status_page(struct intel_engine_cs
*engine)
return ret;
}
+static int intel_engine_init_tlb_invalidation(struct intel_engine_cs *engine)
+{
+ static const union intel_engine_tlb_inv_reg gen8_regs[] = {
+ [RENDER_CLASS].reg = GEN8_RTCR,
+ [VIDEO_DECODE_CLASS].reg= GEN8_M1TCR, /* , GEN8_M2TCR */
+ [VIDEO_ENHANCEMENT_CLASS].reg = GEN8_VTCR,
+ [COPY_ENGINE_CLASS].reg = GEN8_BTCR,
+ };
+ static const union intel_engine_tlb_inv_reg gen12_regs[] = {
+ [RENDER_CLASS].reg = GEN12_GFX_TLB_INV_CR,
+ [VIDEO_DECODE_CLASS].reg= GEN12_VD_TLB_INV_CR,
+ [VIDEO_ENHANCEMENT_CLASS].reg = GEN12_VE_TLB_INV_CR,
+ [COPY_ENGINE_CLASS].reg = GEN12_BLT_TLB_INV_CR,
+ [COMPUTE_CLASS].reg = GEN12_COMPCTX_TLB_INV_CR,
+ };
+ static const union intel_engine_tlb_inv_reg xehp_regs[] = {
+ [RENDER_CLASS].mcr_reg= XEHP_GFX_TLB_INV_CR,
+ [VIDEO_DECODE_CLASS].mcr_reg = XEHP_VD_TLB_INV_CR,
+ [VIDEO_ENHANCEMENT_CLASS].mcr_reg = XEHP_VE_TLB_INV_CR,
+ [COPY_ENGINE_CLASS].mcr_reg = XEHP_BLT_TLB_INV_CR,
+ [COMPUTE_CLASS].mcr_reg = XEHP_COMPCTX_TLB_INV_CR,
+ };
+ struct drm_i915_private *i915 = engine->i915;
+ const union intel_engine_tlb_inv_reg *regs;
+ union intel_engine_tlb_inv_reg reg;
+ unsigned int class = engine->class;
+ unsigned int num = 0;
+ u32 val;
+
+ /*
+* New platforms should not be added with catch-all-newer (>=)
+* condition so that any later platform added triggers the below warning
+* and in turn mandates a human cross-check of whether the invalidation
+* flows have compatible semantics.
+*
+* For instance with the 11.00 -> 12.00 transition three out of five
+* respective engine registers were moved to masked type. Then after the
+* 12.00 -> 12.50 transition multi cast handling is required too.
+*/
+
+ if (GRAPHICS_VER_FULL(i915) == IP_VER(12, 50)) {
This is bad...it only captures XEHPSDV and breaks the handling of DG2
(12.55), PVC (12.60), and MTL (12.70, 12.71, and 12.72). You're not
hitting the warning as expected since those are all now being captured
by the next case of the if/else ladder. With the way GMD_ID works, we
may also get new version numbers that silently show up in hardware too
at some point (e.g., 12.73, 12.74, etc.)
+ regs = xehp_regs;
+ num = ARRAY_SIZE(xehp_regs);
+ } else if (GRAPHICS_VER(i915) == 12) {
You'd want to change this to
GRAPHICS_VER_FULL(i915) == IP_VER(12, 0)
to get the behavior you expected.
According to dg1_info dg1 has IP_VER(12, 10), it will not fit into this
bucket.
Regards
Andrzej
Matt
+ regs = gen12_regs;
+ num = ARRAY_SIZE(gen12_regs);
+ } else if (GRAPHICS_VER(i915) >= 8 && GRAPHICS_VER(i915) <= 11) {
+ regs = gen8_regs;
+ num = ARRAY_SIZE(gen8_regs);
+ } else if (GRAPHICS_VER(i915) < 8) {
+ return 0;
+ } > +
+ if (drm_WARN_ONCE(>drm, !num,
+ "Platform does not implement TLB invalidation!"))
+ return -ENODEV;
+
+ if (drm_WARN_ON_ONCE(>drm,
+class >= num ||
+(!regs[class].reg.reg &&
+ !regs[class].mcr_reg.reg)))
+ return -ERANGE;
I hope the propagation of -ERANGE to device probe is OK.
Reviewed-by: Andrzej Hajda
Regards
Andrzej
+
+ reg =
Re: [Intel-gfx] [PATCH 02/13] drm/i915/dsb: Inline DSB_CTRL writes into intel_dsb_commit()
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Friday, December 16, 2022 6:08 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 02/13] drm/i915/dsb: Inline DSB_CTRL writes into
> intel_dsb_commit()
>
> From: Ville Syrjälä
>
> No point in having these wrappers for a simple DSB_CTRL write.
> Inline them into intel_dsb_commit().
>
> Signed-off-by: Ville Syrjälä
As per bspec before touching ctrl, head and tail register we should check for
dsb idleness.
But one check is sufficient and DSB will be active after programming tail
register.
The current changes LGTM.
Reviewed-by: Animesh Manna
> ---
> drivers/gpu/drm/i915/display/intel_dsb.c | 62 ++--
> 1 file changed, 14 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
> b/drivers/gpu/drm/i915/display/intel_dsb.c
> index ebebaf802dee..90a22af30aab 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsb.c
> +++ b/drivers/gpu/drm/i915/display/intel_dsb.c
> @@ -76,34 +76,6 @@ static bool is_dsb_busy(struct drm_i915_private *i915,
> enum pipe pipe,
> return intel_de_read(i915, DSB_CTRL(pipe, id)) & DSB_STATUS_BUSY;
> }
>
> -static bool intel_dsb_enable_engine(struct drm_i915_private *i915,
> - enum pipe pipe, enum dsb_id id)
> -{
> - if (is_dsb_busy(i915, pipe, id)) {
> - drm_dbg_kms(>drm, "DSB engine is busy.\n");
> - return false;
> - }
> -
> - intel_de_write(i915, DSB_CTRL(pipe, id), DSB_ENABLE);
> - intel_de_posting_read(i915, DSB_CTRL(pipe, id));
> -
> - return true;
> -}
> -
> -static bool intel_dsb_disable_engine(struct drm_i915_private *i915,
> - enum pipe pipe, enum dsb_id id)
> -{
> - if (is_dsb_busy(i915, pipe, id)) {
> - drm_dbg_kms(>drm, "DSB engine is busy.\n");
> - return false;
> - }
> -
> - intel_de_write(i915, DSB_CTRL(pipe, id), 0);
> - intel_de_posting_read(i915, DSB_CTRL(pipe, id));
> -
> - return true;
> -}
> -
> /**
> * intel_dsb_indexed_reg_write() -Write to the DSB context for auto
> * increment register.
> @@ -223,42 +195,36 @@ void intel_dsb_commit(struct intel_dsb *dsb)
> if (!(dsb && dsb->free_pos))
> return;
>
> - if (!intel_dsb_enable_engine(dev_priv, pipe, dsb->id))
> - goto reset;
> -
> - if (is_dsb_busy(dev_priv, pipe, dsb->id)) {
> - drm_err(_priv->drm,
> - "HEAD_PTR write failed - dsb engine is busy.\n");
> - goto reset;
> - }
> - intel_de_write(dev_priv, DSB_HEAD(pipe, dsb->id),
> -i915_ggtt_offset(dsb->vma));
> -
> tail = ALIGN(dsb->free_pos * 4, CACHELINE_BYTES);
> if (tail > dsb->free_pos * 4)
> memset(>cmd_buf[dsb->free_pos], 0,
> (tail - dsb->free_pos * 4));
>
> if (is_dsb_busy(dev_priv, pipe, dsb->id)) {
> - drm_err(_priv->drm,
> - "TAIL_PTR write failed - dsb engine is busy.\n");
> + drm_err(_priv->drm, "DSB engine is busy.\n");
> goto reset;
> }
> - drm_dbg_kms(_priv->drm,
> - "DSB execution started - head 0x%x, tail 0x%x\n",
> - i915_ggtt_offset(dsb->vma), tail);
> +
> + intel_de_write(dev_priv, DSB_CTRL(pipe, dsb->id),
> +DSB_ENABLE);
> + intel_de_write(dev_priv, DSB_HEAD(pipe, dsb->id),
> +i915_ggtt_offset(dsb->vma));
> intel_de_write(dev_priv, DSB_TAIL(pipe, dsb->id),
> i915_ggtt_offset(dsb->vma) + tail);
> - if (wait_for(!is_dsb_busy(dev_priv, pipe, dsb->id), 1)) {
> +
> + drm_dbg_kms(_priv->drm,
> + "DSB execution started - head 0x%x, tail 0x%x\n",
> + i915_ggtt_offset(dsb->vma),
> + i915_ggtt_offset(dsb->vma) + tail);
> +
> + if (wait_for(!is_dsb_busy(dev_priv, pipe, dsb->id), 1))
> drm_err(_priv->drm,
> "Timed out waiting for DSB workload
> completion.\n");
> - goto reset;
> - }
>
> reset:
> dsb->free_pos = 0;
> dsb->ins_start_offset = 0;
> - intel_dsb_disable_engine(dev_priv, pipe, dsb->id);
> + intel_de_write(dev_priv, DSB_CTRL(pipe, dsb->id), 0);
> }
>
> /**
> --
> 2.37.4
[Intel-gfx] [PULL] gvt-fixes
Hi, Here's accumulated current gvt-fixes. Several of them handle for error or destroy path issues and one from Zhi to fix up left vgpu status tracking. thanks! --- The following changes since commit 6217e9f05a74df48c77ee68993d587cdfdb1feb7: drm/i915/dsi: fix MIPI_BKLT_EN_1 native GPIO index (2022-12-30 04:28:46 -0500) are available in the Git repository at: https://github.com/intel/gvt-linux.git tags/gvt-fixes-2023-01-04 for you to fetch changes up to 601fd0f6b2a4c776a21ab8300fe0de0726937623: drm/i915/gvt: fix double free bug in split_2MB_gtt_entry (2023-01-04 15:20:09 +0800) gvt-fixes-2023-01-04 - Fix one missed unpin in error of intel_vgpu_shadow_mm_pin() - Fix two debugfs destroy oops issues for vgpu and gvt entries - Fix one potential double free issue in gtt shadow pt code - Fix to use atomic bit flag for vgpu status Dan Carpenter (1): drm/i915: unpin on error in intel_vgpu_shadow_mm_pin() Zheng Wang (1): drm/i915/gvt: fix double free bug in split_2MB_gtt_entry Zhenyu Wang (3): drm/i915/gvt: fix gvt debugfs destroy drm/i915/gvt: fix vgpu debugfs clean in remove Merge tag 'drm-intel-fixes-2022-12-30' into gvt-fixes Zhi Wang (1): drm/i915/gvt: use atomic operations to change the vGPU status drivers/gpu/drm/i915/gvt/debugfs.c | 36 +++- drivers/gpu/drm/i915/gvt/dmabuf.c| 3 ++- drivers/gpu/drm/i915/gvt/gtt.c | 21 +++-- drivers/gpu/drm/i915/gvt/gvt.h | 15 ++- drivers/gpu/drm/i915/gvt/interrupt.c | 2 +- drivers/gpu/drm/i915/gvt/kvmgt.c | 35 +-- drivers/gpu/drm/i915/gvt/scheduler.c | 4 +++- drivers/gpu/drm/i915/gvt/vgpu.c | 12 +--- 8 files changed, 80 insertions(+), 48 deletions(-) signature.asc Description: PGP signature
