Re: [Intel-gfx] [RFC v3 1/3] drm/doc/rfc: VM_BIND feature design document
On 02/06/2022 00:18, Matthew Brost wrote: On Wed, Jun 01, 2022 at 05:25:49PM +0300, Lionel Landwerlin wrote: On 17/05/2022 21:32, Niranjana Vishwanathapura wrote: +VM_BIND/UNBIND ioctl will immediately start binding/unbinding the mapping in an +async worker. The binding and unbinding will work like a special GPU engine. +The binding and unbinding operations are serialized and will wait on specified +input fences before the operation and will signal the output fences upon the +completion of the operation. Due to serialization, completion of an operation +will also indicate that all previous operations are also complete. I guess we should avoid saying "will immediately start binding/unbinding" if there are fences involved. And the fact that it's happening in an async worker seem to imply it's not immediate. I have a question on the behavior of the bind operation when no input fence is provided. Let say I do : VM_BIND (out_fence=fence1) VM_BIND (out_fence=fence2) VM_BIND (out_fence=fence3) In what order are the fences going to be signaled? In the order of VM_BIND ioctls? Or out of order? Because you wrote "serialized I assume it's : in order One thing I didn't realize is that because we only get one "VM_BIND" engine, there is a disconnect from the Vulkan specification. In Vulkan VM_BIND operations are serialized but per engine. So you could have something like this : VM_BIND (engine=rcs0, in_fence=fence1, out_fence=fence2) VM_BIND (engine=ccs0, in_fence=fence3, out_fence=fence4) Question - let's say this done after the above operations: EXEC (engine=ccs0, in_fence=NULL, out_fence=NULL) Is the exec ordered with respected to bind (i.e. would fence3 & 4 be signaled before the exec starts)? Matt Hi Matt, From the vulkan point of view, everything is serialized within an engine (we map that to a VkQueue). So with : EXEC (engine=ccs0, in_fence=NULL, out_fence=NULL) VM_BIND (engine=ccs0, in_fence=fence3, out_fence=fence4) EXEC completes first then VM_BIND executes. To be even clearer : EXEC (engine=ccs0, in_fence=fence2, out_fence=NULL) VM_BIND (engine=ccs0, in_fence=fence3, out_fence=fence4) EXEC will wait until fence2 is signaled. Once fence2 is signaled, EXEC proceeds, finishes and only after it is done, VM_BIND executes. It would kind of like having the VM_BIND operation be another batch executed from the ringbuffer buffer. -Lionel fence1 is not signaled fence3 is signaled So the second VM_BIND will proceed before the first VM_BIND. I guess we can deal with that scenario in userspace by doing the wait ourselves in one thread per engines. But then it makes the VM_BIND input fences useless. Daniel : what do you think? Should be rework this or just deal with wait fences in userspace? Sorry I noticed this late. -Lionel
Re: [Intel-gfx] [RFC v3 3/3] drm/doc/rfc: VM_BIND uapi definition
On Wed, Jun 01, 2022 at 11:27:17AM +0200, Daniel Vetter wrote:
On Wed, 1 Jun 2022 at 11:03, Dave Airlie wrote:
On Tue, 24 May 2022 at 05:20, Niranjana Vishwanathapura
wrote:
>
> On Thu, May 19, 2022 at 04:07:30PM -0700, Zanoni, Paulo R wrote:
> >On Tue, 2022-05-17 at 11:32 -0700, Niranjana Vishwanathapura wrote:
> >> VM_BIND and related uapi definitions
> >>
> >> v2: Ensure proper kernel-doc formatting with cross references.
> >> Also add new uapi and documentation as per review comments
> >> from Daniel.
> >>
> >> Signed-off-by: Niranjana Vishwanathapura
> >> ---
> >> Documentation/gpu/rfc/i915_vm_bind.h | 399 +++
> >> 1 file changed, 399 insertions(+)
> >> create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h
> >>
> >> diff --git a/Documentation/gpu/rfc/i915_vm_bind.h
b/Documentation/gpu/rfc/i915_vm_bind.h
> >> new file mode 100644
> >> index ..589c0a009107
> >> --- /dev/null
> >> +++ b/Documentation/gpu/rfc/i915_vm_bind.h
> >> @@ -0,0 +1,399 @@
> >> +/* SPDX-License-Identifier: MIT */
> >> +/*
> >> + * Copyright © 2022 Intel Corporation
> >> + */
> >> +
> >> +/**
> >> + * DOC: I915_PARAM_HAS_VM_BIND
> >> + *
> >> + * VM_BIND feature availability.
> >> + * See typedef drm_i915_getparam_t param.
> >> + */
> >> +#define I915_PARAM_HAS_VM_BIND 57
> >> +
> >> +/**
> >> + * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
> >> + *
> >> + * Flag to opt-in for VM_BIND mode of binding during VM creation.
> >> + * See struct drm_i915_gem_vm_control flags.
> >> + *
> >> + * A VM in VM_BIND mode will not support the older execbuff mode of
binding.
> >> + * In VM_BIND mode, execbuff ioctl will not accept any execlist (ie., the
> >> + * _i915_gem_execbuffer2.buffer_count must be 0).
> >> + * Also, _i915_gem_execbuffer2.batch_start_offset and
> >> + * _i915_gem_execbuffer2.batch_len must be 0.
> >> + * DRM_I915_GEM_EXECBUFFER_EXT_BATCH_ADDRESSES extension must be provided
> >> + * to pass in the batch buffer addresses.
> >> + *
> >> + * Additionally, I915_EXEC_NO_RELOC, I915_EXEC_HANDLE_LUT and
> >> + * I915_EXEC_BATCH_FIRST of _i915_gem_execbuffer2.flags must be 0
> >> + * (not used) in VM_BIND mode. I915_EXEC_USE_EXTENSIONS flag must always
be
> >> + * set (See struct drm_i915_gem_execbuffer_ext_batch_addresses).
> >> + * The buffers_ptr, buffer_count, batch_start_offset and batch_len fields
> >> + * of struct drm_i915_gem_execbuffer2 are also not used and must be 0.
> >> + */
> >
> >From that description, it seems we have:
> >
> >struct drm_i915_gem_execbuffer2 {
> >__u64 buffers_ptr; -> must be 0 (new)
> >__u32 buffer_count; -> must be 0 (new)
> >__u32 batch_start_offset; -> must be 0 (new)
> >__u32 batch_len;-> must be 0 (new)
> >__u32 DR1; -> must be 0 (old)
> >__u32 DR4; -> must be 0 (old)
> >__u32 num_cliprects; (fences) -> must be 0 since using extensions
> >__u64 cliprects_ptr; (fences, extensions) -> contains an actual
pointer!
> >__u64 flags;-> some flags must be 0 (new)
> >__u64 rsvd1; (context info) -> repurposed field (old)
> >__u64 rsvd2;-> unused
> >};
> >
> >Based on that, why can't we just get drm_i915_gem_execbuffer3 instead
> >of adding even more complexity to an already abused interface? While
> >the Vulkan-like extension thing is really nice, I don't think what
> >we're doing here is extending the ioctl usage, we're completely
> >changing how the base struct should be interpreted based on how the VM
> >was created (which is an entirely different ioctl).
> >
> >From Rusty Russel's API Design grading, drm_i915_gem_execbuffer2 is
> >already at -6 without these changes. I think after vm_bind we'll need
> >to create a -11 entry just to deal with this ioctl.
> >
>
> The only change here is removing the execlist support for VM_BIND
> mode (other than natual extensions).
> Adding a new execbuffer3 was considered, but I think we need to be careful
> with that as that goes beyond the VM_BIND support, including any future
> requirements (as we don't want an execbuffer4 after VM_BIND).
Why not? it's not like adding extensions here is really that different
than adding new ioctls.
I definitely think this deserves an execbuffer3 without even
considering future requirements. Just to burn down the old
requirements and pointless fields.
Make execbuffer3 be vm bind only, no relocs, no legacy bits, leave the
older sw on execbuf2 for ever.
I guess another point in favour of execbuf3 would be that it's less
midlayer. If we share the entry point then there's quite a few vfuncs
needed to cleanly split out the vm_bind paths from the legacy
reloc/softping paths.
If we invert this and do execbuf3, then there's the existing ioctl
vfunc, and then we share code (where it even makes sense, probably
request setup/submit need to be
Re: [Intel-gfx] [RFC v3 1/3] drm/doc/rfc: VM_BIND feature design document
Regards, Oak > -Original Message- > From: dri-devel On Behalf Of > Niranjana Vishwanathapura > Sent: May 17, 2022 2:32 PM > To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Vetter, > Daniel > Cc: Brost, Matthew ; Hellstrom, Thomas > ; ja...@jlekstrand.net; Wilson, Chris P > ; christian.koe...@amd.com > Subject: [RFC v3 1/3] drm/doc/rfc: VM_BIND feature design document > > VM_BIND design document with description of intended use cases. > > v2: Add more documentation and format as per review comments > from Daniel. > > Signed-off-by: Niranjana Vishwanathapura > > --- > Documentation/driver-api/dma-buf.rst | 2 + > Documentation/gpu/rfc/i915_vm_bind.rst | 304 > + > Documentation/gpu/rfc/index.rst| 4 + > 3 files changed, 310 insertions(+) > create mode 100644 Documentation/gpu/rfc/i915_vm_bind.rst > > diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver- > api/dma-buf.rst > index 36a76cbe9095..64cb924ec5bb 100644 > --- a/Documentation/driver-api/dma-buf.rst > +++ b/Documentation/driver-api/dma-buf.rst > @@ -200,6 +200,8 @@ DMA Fence uABI/Sync File > .. kernel-doc:: include/linux/sync_file.h > :internal: > > +.. _indefinite_dma_fences: > + > Indefinite DMA Fences > ~ > > diff --git a/Documentation/gpu/rfc/i915_vm_bind.rst > b/Documentation/gpu/rfc/i915_vm_bind.rst > new file mode 100644 > index ..f1be560d313c > --- /dev/null > +++ b/Documentation/gpu/rfc/i915_vm_bind.rst > @@ -0,0 +1,304 @@ > +== > +I915 VM_BIND feature design and use cases > +== > + > +VM_BIND feature > + > +DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM > buffer > +objects (BOs) or sections of a BOs at specified GPU virtual addresses on a > +specified address space (VM). These mappings (also referred to as persistent > +mappings) will be persistent across multiple GPU submissions (execbuff calls) > +issued by the UMD, without user having to provide a list of all required > +mappings during each submission (as required by older execbuff mode). > + > +VM_BIND/UNBIND ioctls will support 'in' and 'out' fences to allow userpace > +to specify how the binding/unbinding should sync with other operations > +like the GPU job submission. These fences will be timeline 'drm_syncobj's > +for non-Compute contexts (See struct > drm_i915_vm_bind_ext_timeline_fences). > +For Compute contexts, they will be user/memory fences (See struct > +drm_i915_vm_bind_ext_user_fence). > + > +VM_BIND feature is advertised to user via I915_PARAM_HAS_VM_BIND. > +User has to opt-in for VM_BIND mode of binding for an address space (VM) > +during VM creation time via I915_VM_CREATE_FLAGS_USE_VM_BIND > extension. > + > +VM_BIND/UNBIND ioctl will immediately start binding/unbinding the mapping in > an > +async worker. The binding and unbinding will work like a special GPU engine. > +The binding and unbinding operations are serialized and will wait on > specified > +input fences before the operation and will signal the output fences upon the > +completion of the operation. Due to serialization, completion of an operation > +will also indicate that all previous operations are also complete. Hi, Is user required to wait for the out fence be signaled before submit a gpu job using the vm_bind address? Or is user required to order the gpu job to make gpu job run after vm_bind out fence signaled? I think there could be different behavior on a non-faultable platform and a faultable platform, such as on a non-faultable Platform, gpu job is required to be order after vm_bind out fence signaling; and on a faultable platform, there is no such Restriction since vm bind can be finished in the fault handler? Should we document such thing? Regards, Oak > + > +VM_BIND features include: > + > +* Multiple Virtual Address (VA) mappings can map to the same physical pages > + of an object (aliasing). > +* VA mapping can map to a partial section of the BO (partial binding). > +* Support capture of persistent mappings in the dump upon GPU error. > +* TLB is flushed upon unbind completion. Batching of TLB flushes in some > + use cases will be helpful. > +* Asynchronous vm_bind and vm_unbind support with 'in' and 'out' fences. > +* Support for userptr gem objects (no special uapi is required for this). > + > +Execbuff ioctl in VM_BIND mode > +--- > +The execbuff ioctl handling in VM_BIND mode differs significantly from the > +older method. A VM in VM_BIND mode will not support older execbuff mode of > +binding. In VM_BIND mode, execbuff ioctl will not accept any execlist. Hence, > +no support for implicit sync. It is expected that the below work will be able > +to support requirements of object dependency setting in all use cases: > + > +"dma-buf: Add an API for exporting sync files" >
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Add extra registers to GPU error dump
== Series Details ==
Series: drm/i915: Add extra registers to GPU error dump
URL : https://patchwork.freedesktop.org/series/104630/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11717_full -> Patchwork_104630v1_full
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_104630v1_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_104630v1_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (10 -> 13)
--
Additional (3): shard-rkl shard-dg1 shard-tglu
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_104630v1_full:
### IGT changes ###
Warnings
* igt@kms_fbcon_fbt@fbc-suspend:
- shard-apl: [FAIL][1] ([i915#4767]) -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11717/shard-apl4/igt@kms_fbcon_...@fbc-suspend.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104630v1/shard-apl6/igt@kms_fbcon_...@fbc-suspend.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_ccs@pipe-a-crc-sprite-planes-basic-4_tiled_dg2_rc_ccs:
- {shard-dg1}:NOTRUN -> [SKIP][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104630v1/shard-dg1-19/igt@kms_ccs@pipe-a-crc-sprite-planes-basic-4_tiled_dg2_rc_ccs.html
* igt@kms_color@pipe-b-invalid-gamma-lut-sizes:
- {shard-dg1}:NOTRUN -> [WARN][4]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104630v1/shard-dg1-19/igt@kms_co...@pipe-b-invalid-gamma-lut-sizes.html
* igt@kms_flip@flip-vs-dpms-off-vs-modeset-interruptible@c-hdmi-a1:
- {shard-dg1}:NOTRUN -> [FAIL][5] +4 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104630v1/shard-dg1-19/igt@kms_flip@flip-vs-dpms-off-vs-modeset-interrupti...@c-hdmi-a1.html
* igt@kms_flip@wf_vblank-ts-check@a-edp1:
- {shard-rkl}:NOTRUN -> [FAIL][6] +1 similar issue
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104630v1/shard-rkl-6/igt@kms_flip@wf_vblank-ts-ch...@a-edp1.html
*
igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-5@pipe-a-edp-1:
- {shard-rkl}:NOTRUN -> [SKIP][7] +3 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104630v1/shard-rkl-6/igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-...@pipe-a-edp-1.html
* igt@kms_vblank@pipe-c-ts-continuation-suspend:
- {shard-tglu}: NOTRUN -> [DMESG-WARN][8]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104630v1/shard-tglu-5/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html
Known issues
Here are the changes found in Patchwork_104630v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@feature_discovery@psr2:
- shard-iclb: [PASS][9] -> [SKIP][10] ([i915#658])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11717/shard-iclb2/igt@feature_discov...@psr2.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104630v1/shard-iclb4/igt@feature_discov...@psr2.html
* igt@gem_eio@kms:
- shard-tglb: [PASS][11] -> [FAIL][12] ([i915#5784]) +1 similar
issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11717/shard-tglb7/igt@gem_...@kms.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104630v1/shard-tglb5/igt@gem_...@kms.html
* igt@gem_exec_fair@basic-pace@bcs0:
- shard-iclb: [PASS][13] -> [FAIL][14] ([i915#2842]) +1 similar
issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11717/shard-iclb8/igt@gem_exec_fair@basic-p...@bcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104630v1/shard-iclb5/igt@gem_exec_fair@basic-p...@bcs0.html
* igt@gem_exec_fair@basic-pace@vcs1:
- shard-kbl: [PASS][15] -> [SKIP][16] ([fdo#109271])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11717/shard-kbl6/igt@gem_exec_fair@basic-p...@vcs1.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104630v1/shard-kbl6/igt@gem_exec_fair@basic-p...@vcs1.html
* igt@gem_exec_fair@basic-pace@vecs0:
- shard-kbl: [PASS][17] -> [FAIL][18] ([i915#2842]) +1 similar
issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11717/shard-kbl6/igt@gem_exec_fair@basic-p...@vecs0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104630v1/shard-kbl6/igt@gem_exec_fair@basic-p...@vecs0.html
* igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: NOTRUN -> [FAIL][19] ([i915#2849])
[19]:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Parse more eDP link rate stuff from VBT
== Series Details ==
Series: drm/i915: Parse more eDP link rate stuff from VBT
URL : https://patchwork.freedesktop.org/series/104615/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11717_full -> Patchwork_104615v1_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/index.html
Participating hosts (10 -> 10)
--
Additional (3): shard-rkl shard-dg1 shard-tglu
Missing(3): pig-skl-6260u pig-kbl-iris pig-glk-j5005
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_104615v1_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@runner@aborted:
- {shard-rkl}:NOTRUN -> ([FAIL][1], [FAIL][2], [FAIL][3],
[FAIL][4], [FAIL][5], [FAIL][6], [FAIL][7], [FAIL][8], [FAIL][9], [FAIL][10],
[FAIL][11], [FAIL][12], [FAIL][13], [FAIL][14], [FAIL][15], [FAIL][16],
[FAIL][17], [FAIL][18], [FAIL][19], [FAIL][20], [FAIL][21]) ([i915#5602])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/shard-rkl-5/igt@run...@aborted.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/shard-rkl-1/igt@run...@aborted.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/shard-rkl-5/igt@run...@aborted.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/shard-rkl-2/igt@run...@aborted.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/shard-rkl-1/igt@run...@aborted.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/shard-rkl-1/igt@run...@aborted.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/shard-rkl-1/igt@run...@aborted.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/shard-rkl-5/igt@run...@aborted.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/shard-rkl-2/igt@run...@aborted.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/shard-rkl-2/igt@run...@aborted.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/shard-rkl-1/igt@run...@aborted.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/shard-rkl-5/igt@run...@aborted.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/shard-rkl-1/igt@run...@aborted.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/shard-rkl-1/igt@run...@aborted.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/shard-rkl-5/igt@run...@aborted.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/shard-rkl-5/igt@run...@aborted.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/shard-rkl-6/igt@run...@aborted.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/shard-rkl-6/igt@run...@aborted.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/shard-rkl-6/igt@run...@aborted.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/shard-rkl-6/igt@run...@aborted.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/shard-rkl-6/igt@run...@aborted.html
Known issues
Here are the changes found in Patchwork_104615v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_mmap_gtt@coherency:
- shard-snb: [PASS][22] -> [SKIP][23] ([fdo#109271]) +2 similar
issues
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11717/shard-snb7/igt@gem_mmap_...@coherency.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/shard-snb6/igt@gem_mmap_...@coherency.html
* igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-upscaling:
- shard-glk: [PASS][24] -> [FAIL][25] ([i915#4911])
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11717/shard-glk6/igt@kms_flip_scaled_...@flip-32bpp-ytileccs-to-64bpp-ytile-upscaling.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/shard-glk8/igt@kms_flip_scaled_...@flip-32bpp-ytileccs-to-64bpp-ytile-upscaling.html
* igt@kms_vblank@pipe-b-accuracy-idle:
- shard-glk: [PASS][26] -> [FAIL][27] ([i915#43])
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11717/shard-glk4/igt@kms_vbl...@pipe-b-accuracy-idle.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/shard-glk1/igt@kms_vbl...@pipe-b-accuracy-idle.html
Possible fixes
* igt@gem_exec_flush@basic-wb-rw-before-default:
- shard-snb: [SKIP][28] ([fdo#109271]) -> [PASS][29] +1 similar
issue
[28]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add extra registers to GPU error dump
== Series Details ==
Series: drm/i915: Add extra registers to GPU error dump
URL : https://patchwork.freedesktop.org/series/104630/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11717 -> Patchwork_104630v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104630v1/index.html
Participating hosts (42 -> 42)
--
Additional (5): fi-kbl-soraka fi-rkl-11600 fi-bdw-5557u bat-adlm-1 bat-dg2-9
Missing(5): fi-hsw-4200u bat-dg1-5 fi-cfl-guc bat-adlp-4 fi-bdw-samus
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_104630v1:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@gt_lrc:
- {bat-adlm-1}: NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104630v1/bat-adlm-1/igt@i915_selftest@live@gt_lrc.html
Known issues
Here are the changes found in Patchwork_104630v1 that come from known issues:
### IGT changes ###
Issues hit
* 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_104630v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
- fi-rkl-11600: NOTRUN -> [SKIP][3] ([i915#2190])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104630v1/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3
similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104630v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
- fi-rkl-11600: NOTRUN -> [SKIP][5] ([i915#4613]) +3 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104630v1/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html
* igt@gem_lmem_swapping@verify-random:
- fi-bdw-5557u: NOTRUN -> [SKIP][6] ([fdo#109271]) +14 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104630v1/fi-bdw-5557u/igt@gem_lmem_swapp...@verify-random.html
* igt@gem_tiled_pread_basic:
- fi-rkl-11600: NOTRUN -> [SKIP][7] ([i915#3282])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104630v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html
* igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600: NOTRUN -> [SKIP][8] ([i915#3012])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104630v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_selftest@live@gem_contexts:
- fi-bdw-5557u: NOTRUN -> [INCOMPLETE][9] ([i915#5502])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104630v1/fi-bdw-5557u/igt@i915_selftest@live@gem_contexts.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][10] ([i915#1886])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104630v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@requests:
- fi-blb-e6850: [PASS][11] -> [DMESG-FAIL][12] ([i915#4528])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11717/fi-blb-e6850/igt@i915_selftest@l...@requests.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104630v1/fi-blb-e6850/igt@i915_selftest@l...@requests.html
* igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600: NOTRUN -> [INCOMPLETE][13] ([i915#5982])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104630v1/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-bsw-nick:NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104630v1/fi-bsw-nick/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@dp-edid-read:
- fi-bdw-5557u: NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827]) +7
similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104630v1/fi-bdw-5557u/igt@kms_chamel...@dp-edid-read.html
* igt@kms_chamelium@hdmi-edid-read:
- fi-rkl-11600: NOTRUN -> [SKIP][16] ([fdo#111827]) +7 similar issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104630v1/fi-rkl-11600/igt@kms_chamel...@hdmi-edid-read.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-soraka: NOTRUN -> [SKIP][17] ([fdo#109271] / [fdo#111827]) +7
similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104630v1/fi-kbl-soraka/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-kbl-soraka: NOTRUN -> [SKIP][18] ([fdo#109271]) +9 similar issues
[18]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Add extra registers to GPU error dump
== Series Details == Series: drm/i915: Add extra registers to GPU error dump URL : https://patchwork.freedesktop.org/series/104630/ 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] [RFC v3 1/3] drm/doc/rfc: VM_BIND feature design document
On Wed, Jun 01, 2022 at 05:25:49PM +0300, Lionel Landwerlin wrote: > On 17/05/2022 21:32, Niranjana Vishwanathapura wrote: > > +VM_BIND/UNBIND ioctl will immediately start binding/unbinding the mapping > > in an > > +async worker. The binding and unbinding will work like a special GPU > > engine. > > +The binding and unbinding operations are serialized and will wait on > > specified > > +input fences before the operation and will signal the output fences upon > > the > > +completion of the operation. Due to serialization, completion of an > > operation > > +will also indicate that all previous operations are also complete. > > I guess we should avoid saying "will immediately start binding/unbinding" if > there are fences involved. > > And the fact that it's happening in an async worker seem to imply it's not > immediate. > > > I have a question on the behavior of the bind operation when no input fence > is provided. Let say I do : > > VM_BIND (out_fence=fence1) > > VM_BIND (out_fence=fence2) > > VM_BIND (out_fence=fence3) > > > In what order are the fences going to be signaled? > > In the order of VM_BIND ioctls? Or out of order? > > Because you wrote "serialized I assume it's : in order > > > One thing I didn't realize is that because we only get one "VM_BIND" engine, > there is a disconnect from the Vulkan specification. > > In Vulkan VM_BIND operations are serialized but per engine. > > So you could have something like this : > > VM_BIND (engine=rcs0, in_fence=fence1, out_fence=fence2) > > VM_BIND (engine=ccs0, in_fence=fence3, out_fence=fence4) > Question - let's say this done after the above operations: EXEC (engine=ccs0, in_fence=NULL, out_fence=NULL) Is the exec ordered with respected to bind (i.e. would fence3 & 4 be signaled before the exec starts)? Matt > > fence1 is not signaled > > fence3 is signaled > > So the second VM_BIND will proceed before the first VM_BIND. > > > I guess we can deal with that scenario in userspace by doing the wait > ourselves in one thread per engines. > > But then it makes the VM_BIND input fences useless. > > > Daniel : what do you think? Should be rework this or just deal with wait > fences in userspace? > > > Sorry I noticed this late. > > > -Lionel > >
[Intel-gfx] [PATCH] drm/i915: Add extra registers to GPU error dump
From: Stuart Summers
Our internal teams have identified a few additional engine registers
that are worth inspecting in error state dumps during development &
debug. Let's capture and print them as part of our error dump.
For simplicity we'll just dump these registers on gen11 and beyond.
Most of these registers have existed since earlier platforms (e.g., gen6
or gen7) but were initially introduced only for a subset of the
platforms' engines; gen11 seems to be where they became available on all
engines.
Signed-off-by: Stuart Summers
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_engine_regs.h | 5 +
drivers/gpu/drm/i915/i915_gpu_error.c | 19 +++
drivers/gpu/drm/i915/i915_gpu_error.h | 7 +++
3 files changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
index 44de10cf7837..889f0df3940b 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
@@ -8,6 +8,7 @@
#include "i915_reg_defs.h"
+#define RING_EXCC(base)_MMIO((base) + 0x28)
#define RING_TAIL(base)_MMIO((base) + 0x30)
#define TAIL_ADDR0x0018
#define RING_HEAD(base)_MMIO((base) + 0x34)
@@ -133,6 +134,8 @@
(REG_FIELD_PREP(BLIT_CCTL_DST_MOCS_MASK, (dst) << 1) | \
REG_FIELD_PREP(BLIT_CCTL_SRC_MOCS_MASK, (src) << 1))
+#define RING_CSCMDOP(base) _MMIO((base) + 0x20c)
+
/*
* CMD_CCTL read/write fields take a MOCS value and _not_ a table index.
* The lsb of each can be considered a separate enabling bit for encryption.
@@ -149,6 +152,7 @@
REG_FIELD_PREP(CMD_CCTL_READ_OVERRIDE_MASK, (read) << 1))
#define RING_PREDICATE_RESULT(base)_MMIO((base) + 0x3b8) /* gen12+
*/
+
#define MI_PREDICATE_RESULT_2(base)_MMIO((base) + 0x3bc)
#define LOWER_SLICE_ENABLED (1 << 0)
#define LOWER_SLICE_DISABLED (0 << 0)
@@ -172,6 +176,7 @@
#define CTX_CTRL_ENGINE_CTX_SAVE_INHIBIT REG_BIT(2)
#define CTX_CTRL_INHIBIT_SYN_CTX_SWITCH REG_BIT(3)
#define GEN12_CTX_CTRL_OAR_CONTEXT_ENABLE REG_BIT(8)
+#define RING_CTX_SR_CTL(base) _MMIO((base) + 0x244)
#define RING_SEMA_WAIT_POLL(base) _MMIO((base) + 0x24c)
#define GEN8_RING_PDP_UDW(base, n) _MMIO((base) + 0x270 + (n) * 8
+ 4)
#define GEN8_RING_PDP_LDW(base, n) _MMIO((base) + 0x270 + (n) * 8)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 0512c66fa4f3..bff8a111424a 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -581,6 +581,15 @@ static void error_print_engine(struct
drm_i915_error_state_buf *m,
err_printf(m, " RC PSMI: 0x%08x\n", ee->rc_psmi);
err_printf(m, " FAULT_REG: 0x%08x\n", ee->fault_reg);
}
+ if (GRAPHICS_VER(m->i915) >= 11) {
+ err_printf(m, " NOPID: 0x%08x\n", ee->nopid);
+ err_printf(m, " EXCC: 0x%08x\n", ee->excc);
+ err_printf(m, " CMD_CCTL: 0x%08x\n", ee->cmd_cctl);
+ err_printf(m, " CSCMDOP: 0x%08x\n", ee->cscmdop);
+ err_printf(m, " CTX_SR_CTL: 0x%08x\n", ee->ctx_sr_ctl);
+ err_printf(m, " DMA_FADDR_HI: 0x%08x\n", ee->dma_faddr_hi);
+ err_printf(m, " DMA_FADDR_LO: 0x%08x\n", ee->dma_faddr_lo);
+ }
if (HAS_PPGTT(m->i915)) {
err_printf(m, " GFX_MODE: 0x%08x\n", ee->vm_info.gfx_mode);
@@ -1224,6 +1233,16 @@ static void engine_record_registers(struct
intel_engine_coredump *ee)
ee->ipehr = ENGINE_READ(engine, IPEHR);
}
+ if (GRAPHICS_VER(i915) >= 11) {
+ ee->cmd_cctl = ENGINE_READ(engine, RING_CMD_CCTL);
+ ee->cscmdop = ENGINE_READ(engine, RING_CSCMDOP);
+ ee->ctx_sr_ctl = ENGINE_READ(engine, RING_CTX_SR_CTL);
+ ee->dma_faddr_hi = ENGINE_READ(engine, RING_DMA_FADD_UDW);
+ ee->dma_faddr_lo = ENGINE_READ(engine, RING_DMA_FADD);
+ ee->nopid = ENGINE_READ(engine, RING_NOPID);
+ ee->excc = ENGINE_READ(engine, RING_EXCC);
+ }
+
intel_engine_get_instdone(engine, >instdone);
ee->instpm = ENGINE_READ(engine, RING_INSTPM);
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h
b/drivers/gpu/drm/i915/i915_gpu_error.h
index a611abacd9c2..55a143b92d10 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.h
+++ b/drivers/gpu/drm/i915/i915_gpu_error.h
@@ -84,6 +84,13 @@ struct intel_engine_coredump {
u32 fault_reg;
u64 faddr;
u32 rc_psmi; /* sleep state */
+ u32 nopid;
+ u32 excc;
+ u32 cmd_cctl;
+ u32 cscmdop;
[Intel-gfx] ✓ Fi.CI.IGT: success for i915: SSEU handling updates
== Series Details ==
Series: i915: SSEU handling updates
URL : https://patchwork.freedesktop.org/series/104611/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11717_full -> Patchwork_104611v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (10 -> 13)
--
Additional (3): shard-rkl shard-dg1 shard-tglu
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_104611v1_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_flip@wf_vblank-ts-check@a-edp1:
- {shard-rkl}:NOTRUN -> [FAIL][1] +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104611v1/shard-rkl-6/igt@kms_flip@wf_vblank-ts-ch...@a-edp1.html
*
igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-5@pipe-a-edp-1:
- {shard-rkl}:NOTRUN -> [SKIP][2] +3 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104611v1/shard-rkl-6/igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-...@pipe-a-edp-1.html
* igt@kms_vblank@pipe-c-ts-continuation-suspend:
- {shard-tglu}: NOTRUN -> [DMESG-WARN][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104611v1/shard-tglu-3/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html
* igt@perf_pmu@module-unload:
- {shard-tglu}: NOTRUN -> [FAIL][4]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104611v1/shard-tglu-5/igt@perf_...@module-unload.html
Known issues
Here are the changes found in Patchwork_104611v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@drm_buddy@all@buddy_alloc_smoke:
- shard-skl: [PASS][5] -> [INCOMPLETE][6] ([i915#5800])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11717/shard-skl2/igt@drm_buddy@all@buddy_alloc_smoke.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104611v1/shard-skl7/igt@drm_buddy@all@buddy_alloc_smoke.html
* igt@feature_discovery@psr2:
- shard-iclb: [PASS][7] -> [SKIP][8] ([i915#658])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11717/shard-iclb2/igt@feature_discov...@psr2.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104611v1/shard-iclb5/igt@feature_discov...@psr2.html
* igt@gem_eio@kms:
- shard-tglb: [PASS][9] -> [FAIL][10] ([i915#5784]) +1 similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11717/shard-tglb7/igt@gem_...@kms.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104611v1/shard-tglb1/igt@gem_...@kms.html
* igt@gem_eio@unwedge-stress:
- shard-iclb: [PASS][11] -> [TIMEOUT][12] ([i915#3070])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11717/shard-iclb7/igt@gem_...@unwedge-stress.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104611v1/shard-iclb8/igt@gem_...@unwedge-stress.html
* igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-kbl: NOTRUN -> [FAIL][13] ([i915#2842])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104611v1/shard-kbl7/igt@gem_exec_fair@basic-none-s...@rcs0.html
* igt@gem_exec_fair@basic-none@vecs0:
- shard-kbl: [PASS][14] -> [FAIL][15] ([i915#2842]) +3 similar
issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11717/shard-kbl3/igt@gem_exec_fair@basic-n...@vecs0.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104611v1/shard-kbl1/igt@gem_exec_fair@basic-n...@vecs0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][16] -> [FAIL][17] ([i915#2842])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11717/shard-tglb5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104611v1/shard-tglb6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_exec_fair@basic-pace@bcs0:
- shard-iclb: [PASS][18] -> [FAIL][19] ([i915#2842]) +1 similar
issue
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11717/shard-iclb8/igt@gem_exec_fair@basic-p...@bcs0.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104611v1/shard-iclb5/igt@gem_exec_fair@basic-p...@bcs0.html
* igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: NOTRUN -> [FAIL][20] ([i915#2842])
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104611v1/shard-iclb2/igt@gem_exec_fair@basic-throt...@rcs0.html
* igt@gem_exec_params@no-bsd:
- shard-iclb: NOTRUN -> [SKIP][21] ([fdo#109283])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104611v1/shard-iclb2/igt@gem_exec_par...@no-bsd.html
* igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][22] -> [SKIP][23]
Re: [Intel-gfx] [RFC v3 1/3] drm/doc/rfc: VM_BIND feature design document
On Wed, Jun 01, 2022 at 05:25:49PM +0300, Lionel Landwerlin wrote: > On 17/05/2022 21:32, Niranjana Vishwanathapura wrote: > > +VM_BIND/UNBIND ioctl will immediately start binding/unbinding the mapping > > in an > > +async worker. The binding and unbinding will work like a special GPU > > engine. > > +The binding and unbinding operations are serialized and will wait on > > specified > > +input fences before the operation and will signal the output fences upon > > the > > +completion of the operation. Due to serialization, completion of an > > operation > > +will also indicate that all previous operations are also complete. > > I guess we should avoid saying "will immediately start binding/unbinding" if > there are fences involved. > > And the fact that it's happening in an async worker seem to imply it's not > immediate. > > > I have a question on the behavior of the bind operation when no input fence > is provided. Let say I do : > > VM_BIND (out_fence=fence1) > > VM_BIND (out_fence=fence2) > > VM_BIND (out_fence=fence3) > > > In what order are the fences going to be signaled? > > In the order of VM_BIND ioctls? Or out of order? > > Because you wrote "serialized I assume it's : in order > > > One thing I didn't realize is that because we only get one "VM_BIND" engine, > there is a disconnect from the Vulkan specification. > > In Vulkan VM_BIND operations are serialized but per engine. > > So you could have something like this : > > VM_BIND (engine=rcs0, in_fence=fence1, out_fence=fence2) > > VM_BIND (engine=ccs0, in_fence=fence3, out_fence=fence4) > > > fence1 is not signaled > > fence3 is signaled > > So the second VM_BIND will proceed before the first VM_BIND. > > > I guess we can deal with that scenario in userspace by doing the wait > ourselves in one thread per engines. > > But then it makes the VM_BIND input fences useless. > > > Daniel : what do you think? Should be rework this or just deal with wait > fences in userspace? > My opinion is rework this but make the ordering via an engine param optional. e.g. A VM can be configured so all binds are ordered within the VM e.g. A VM can be configured so all binds accept an engine argument (in the case of the i915 likely this is a gem context handle) and binds ordered with respect to that engine. This gives UMDs options as the later likely consumes more KMD resources so if a different UMD can live with binds being ordered within the VM they can use a mode consuming less resources. Matt > > Sorry I noticed this late. > > > -Lionel > >
Re: [Intel-gfx] [RFC PATCH v2 1/1] drm/i915: Replace shmem memory region and object backend with TTM
>-Original Message-
>From: Adrian Larumbe
>Sent: Friday, May 27, 2022 12:08 PM
>To: Ruhl, Michael J
>Cc: dan...@ffwll.ch; intel-gfx@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [RFC PATCH v2 1/1] drm/i915: Replace shmem memory
>region and object backend with TTM
>
>On 17.05.2022 21:39, Ruhl, Michael J wrote:
>> >-Original Message-
>> >From: Intel-gfx On Behalf Of
>> >Adrian Larumbe
>> >Sent: Tuesday, May 17, 2022 4:45 PM
>> >To: dan...@ffwll.ch; intel-gfx@lists.freedesktop.org
>> >Cc: adrian.laru...@collabora.com
>> >Subject: [Intel-gfx] [RFC PATCH v2 1/1] drm/i915: Replace shmem memory
>> >region and object backend with TTM
>> >
>> >Remove shmem region and object backend code as they are now
>> >unnecessary.
>> >In the case of objects placed in SMEM and backed by kernel shmem files,
>the
>> >file pointer has to be retrieved from the ttm_tt structure, so change this
>> >as well. This means accessing an shmem-backed BO's file pointer requires
>> >getting its pages beforehand, unlike in the old shmem backend.
>> >
>> >Expand TTM BO creation by handling devices with no LLC so that their
>> >caching and coherency properties are set accordingly.
>> >
>> >Adapt phys backend to put pages of original shmem object in a 'TTM way',
>> >also making sure its pages are put when a TTM shmem object has no struct
>> >page.
>> >
>> >Signed-off-by: Adrian Larumbe
>> >---
>> > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 12 +-
>> > drivers/gpu/drm/i915/gem/i915_gem_mman.c | 32 +-
>> > drivers/gpu/drm/i915/gem/i915_gem_object.h | 4 +-
>> > drivers/gpu/drm/i915/gem/i915_gem_phys.c | 32 +-
>> > drivers/gpu/drm/i915/gem/i915_gem_shmem.c| 390 +--
>> > drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 267 -
>> > drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 3 +
>> > drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 9 +-
>> > drivers/gpu/drm/i915/gt/shmem_utils.c| 64 ++-
>> > drivers/gpu/drm/i915/intel_memory_region.c | 7 +-
>> > 10 files changed, 398 insertions(+), 422 deletions(-)
>> >
>> >diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>> >b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>> >index f5062d0c6333..de04ce4210b3 100644
>> >--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>> >+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>> >@@ -12,6 +12,7 @@
>> > #include
>> >
>> > #include "gem/i915_gem_dmabuf.h"
>> >+#include "gem/i915_gem_ttm.h"
>> > #include "i915_drv.h"
>> > #include "i915_gem_object.h"
>> > #include "i915_scatterlist.h"
>> >@@ -94,22 +95,25 @@ static int i915_gem_dmabuf_mmap(struct dma_buf
>> >*dma_buf, struct vm_area_struct *
>> > {
>> >struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
>> >struct drm_i915_private *i915 = to_i915(obj->base.dev);
>> >+ struct file *filp = i915_gem_ttm_get_filep(obj);
>> >int ret;
>> >
>> >+ GEM_BUG_ON(obj->base.import_attach != NULL);
>> >+
>> >if (obj->base.size < vma->vm_end - vma->vm_start)
>> >return -EINVAL;
>> >
>> >if (HAS_LMEM(i915))
>> >return drm_gem_prime_mmap(>base, vma);
>>
>> Since all of the devices that will have device memory will be true for
>HAS_LMEM,
>> won't your code path always go to drm_gem_prime_mmap()?
>
>This makes me wonder, how was mapping of a dmabuf BO working before, in
>the case
>of DG2 and DG1, when an object is smem-bound, and therefore backed by
>shmem?
LMEM is a new thing. DG2 and DG1 have it available, but the initial patch
sets did not support access via dma-buf.
With the TTM being used for the LMEM objects, I think that the drm_gem code
was able to be used.
>
>I guess in this case it might be more sensible to control for the case that
>it's
>an lmem-only object on a discrete platform as follows:
>
>static int i915_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct
>vm_area_struct *vma)
>{
> struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
> struct drm_i915_private *i915 = to_i915(obj->base.dev);
> struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
> struct file *filp = i915_gem_ttm_get_filep(obj);
> int ret;
>
> if (obj->base.size < vma->vm_end - vma->vm_start)
> return -EINVAL;
>
> if (IS_DGFX(i915) && i915_ttm_cpu_maps_iomem(bo->resource))
> return drm_gem_prime_mmap(>base, vma);
HAS_LMEM is roughly IS_DGFX...
As for the second part, (_maps_iomem), hmm...
If I am following this correctly drm_gem_prime_mmap() will call i915_gem_mmap,
so I think that just the call (without the iomem check) is correct.
This is a newer mmap code path than the older integrated cards had, so I think
that
the context is HAS_LMEM (new and discrete), otherwise the old path.
> if (IS_ERR(filp))
> return PTR_ERR(filp);
>
> ret = call_mmap(filp, vma);
> if (ret)
> return ret;
>
> vma_set_file(vma, filp);
>
> return 0;
>}
>
>> >- if (!obj->base.filp)
>> >+ if (!filp)
>> >
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Parse more eDP link rate stuff from VBT
== Series Details == Series: drm/i915: Parse more eDP link rate stuff from VBT URL : https://patchwork.freedesktop.org/series/104615/ State : success == Summary == CI Bug Log - changes from CI_DRM_11717 -> Patchwork_104615v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/index.html Participating hosts (42 -> 42) -- Additional (4): fi-kbl-soraka fi-rkl-11600 fi-icl-u2 bat-dg2-9 Missing(4): fi-bdw-samus bat-jsl-2 fi-apl-guc fi-hsw-4200u Known issues Here are the changes found in Patchwork_104615v1 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@gem: - fi-blb-e6850: [PASS][1] -> [DMESG-FAIL][2] ([i915#4528]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11717/fi-blb-e6850/igt@i915_selftest@l...@gem.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/fi-blb-e6850/igt@i915_selftest@l...@gem.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-bsw-nick:NOTRUN -> [SKIP][3] ([fdo#109271] / [fdo#111827]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/fi-bsw-nick/igt@kms_chamel...@common-hpd-after-suspend.html - fi-pnv-d510:NOTRUN -> [SKIP][4] ([fdo#109271]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/fi-pnv-d510/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-bsw-nick:NOTRUN -> [SKIP][5] ([fdo#109271]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/fi-bsw-nick/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html * igt@runner@aborted: - fi-hsw-4770:NOTRUN -> [FAIL][6] ([i915#5594] / [i915#5917]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/fi-hsw-4770/igt@run...@aborted.html - fi-skl-6700k2: NOTRUN -> [FAIL][7] ([i915#5602] / [i915#5917]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/fi-skl-6700k2/igt@run...@aborted.html - fi-cfl-8109u: NOTRUN -> [FAIL][8] ([i915#5602] / [i915#5917]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/fi-cfl-8109u/igt@run...@aborted.html - bat-adlp-4: NOTRUN -> [FAIL][9] ([i915#5457]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/bat-adlp-4/igt@run...@aborted.html - fi-kbl-8809g: NOTRUN -> [FAIL][10] ([i915#5602] / [i915#5917]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/fi-kbl-8809g/igt@run...@aborted.html - fi-kbl-guc: NOTRUN -> [FAIL][11] ([i915#5602] / [i915#5917]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/fi-kbl-guc/igt@run...@aborted.html - fi-tgl-u2: NOTRUN -> [FAIL][12] ([i915#3690]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/fi-tgl-u2/igt@run...@aborted.html - fi-bxt-dsi: NOTRUN -> [FAIL][13] ([i915#5917]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/fi-bxt-dsi/igt@run...@aborted.html - fi-blb-e6850: NOTRUN -> [FAIL][14] ([fdo#109271] / [i915#2403] / [i915#4312]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/fi-blb-e6850/igt@run...@aborted.html - fi-skl-6600u: NOTRUN -> [FAIL][15] ([i915#5917]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/fi-skl-6600u/igt@run...@aborted.html - fi-glk-dsi: NOTRUN -> [FAIL][16] ([i915#5917]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/fi-glk-dsi/igt@run...@aborted.html - fi-icl-u2: NOTRUN -> [FAIL][17] ([i915#3690]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/fi-icl-u2/igt@run...@aborted.html - fi-rkl-guc: NOTRUN -> [FAIL][18] ([i915#5602]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/fi-rkl-guc/igt@run...@aborted.html - fi-skl-guc: NOTRUN -> [FAIL][19] ([i915#5602] / [i915#5917]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/fi-skl-guc/igt@run...@aborted.html - fi-kbl-soraka: NOTRUN -> [FAIL][20] ([i915#5602] / [i915#5917]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/fi-kbl-soraka/igt@run...@aborted.html - fi-kbl-7567u: NOTRUN -> [FAIL][21] ([i915#5602] / [i915#5917]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/fi-kbl-7567u/igt@run...@aborted.html - fi-cfl-8700k: NOTRUN -> [FAIL][22] ([i915#5917]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/fi-cfl-8700k/igt@run...@aborted.html - fi-rkl-11600: NOTRUN -> [FAIL][23] ([i915#5602]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104615v1/fi-rkl-11600/igt@run...@aborted.html - fi-hsw-g3258: NOTRUN ->
[Intel-gfx] ✓ Fi.CI.BAT: success for i915: SSEU handling updates
== Series Details ==
Series: i915: SSEU handling updates
URL : https://patchwork.freedesktop.org/series/104611/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11717 -> Patchwork_104611v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104611v1/index.html
Participating hosts (42 -> 43)
--
Additional (3): fi-kbl-soraka fi-bdw-5557u bat-dg2-9
Missing(2): fi-bdw-samus fi-hsw-4200u
Known issues
Here are the changes found in Patchwork_104611v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@read_all_entries:
- fi-kbl-soraka: NOTRUN -> [DMESG-WARN][1] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104611v1/fi-kbl-soraka/igt@debugfs_test@read_all_entries.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_104611v1/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_104611v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@gem_lmem_swapping@verify-random:
- fi-bdw-5557u: NOTRUN -> [SKIP][4] ([fdo#109271]) +14 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104611v1/fi-bdw-5557u/igt@gem_lmem_swapp...@verify-random.html
* igt@i915_selftest@live@gem:
- fi-pnv-d510:NOTRUN -> [DMESG-FAIL][5] ([i915#4528])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104611v1/fi-pnv-d510/igt@i915_selftest@l...@gem.html
* igt@i915_selftest@live@gt_engines:
- bat-dg1-5: [PASS][6] -> [INCOMPLETE][7] ([i915#4418])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11717/bat-dg1-5/igt@i915_selftest@live@gt_engines.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104611v1/bat-dg1-5/igt@i915_selftest@live@gt_engines.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][8] ([i915#1886])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104611v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@hangcheck:
- fi-bdw-5557u: NOTRUN -> [INCOMPLETE][9] ([i915#3921])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104611v1/fi-bdw-5557u/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@requests:
- fi-blb-e6850: [PASS][10] -> [DMESG-FAIL][11] ([i915#4528])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11717/fi-blb-e6850/igt@i915_selftest@l...@requests.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104611v1/fi-blb-e6850/igt@i915_selftest@l...@requests.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-bsw-nick:NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104611v1/fi-bsw-nick/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@dp-edid-read:
- fi-bdw-5557u: NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827]) +7
similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104611v1/fi-bdw-5557u/igt@kms_chamel...@dp-edid-read.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-soraka: NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +7
similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104611v1/fi-kbl-soraka/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-kbl-soraka: NOTRUN -> [SKIP][15] ([fdo#109271]) +9 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104611v1/fi-kbl-soraka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-soraka: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#533])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104611v1/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-bsw-nick:NOTRUN -> [SKIP][17] ([fdo#109271])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104611v1/fi-bsw-nick/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
* igt@runner@aborted:
- fi-blb-e6850: NOTRUN -> [FAIL][18] ([fdo#109271] / [i915#2403] /
[i915#4312])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104611v1/fi-blb-e6850/igt@run...@aborted.html
Possible fixes
* igt@i915_selftest@live@gt_pm:
- {fi-jsl-1}: [DMESG-FAIL][19] ([i915#1886]) -> [PASS][20]
[19]:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for i915: SSEU handling updates
== Series Details ==
Series: i915: SSEU handling updates
URL : https://patchwork.freedesktop.org/series/104611/
State : warning
== Summary ==
Error: dim checkpatch failed
92101c27eef9 drm/i915/xehp: Use separate sseu init function
7489d9903596 drm/i915/xehp: Drop GETPARAM lookups of I915_PARAM_[SUB]SLICE_MASK
7e1560b69810 drm/i915/sseu: Simplify gen11+ SSEU handling
529ade4a9e43 drm/i915/sseu: Don't try to store EU mask internally in UAPI format
7823e3f4a149 drm/i915/sseu: Disassociate internal subslice mask representation
from uapi
-:523: ERROR:POINTER_LOCATION: "foo* bar" should be "foo *bar"
#523: FILE: drivers/gpu/drm/i915/gt/intel_sseu.c:844:
+void intel_sseu_print_ss_info(const char* type,
-:612: WARNING:NEW_TYPEDEFS: do not add new typedefs
#612: FILE: drivers/gpu/drm/i915/gt/intel_sseu.h:59:
+typedef union {
-:720: ERROR:POINTER_LOCATION: "foo* bar" should be "foo *bar"
#720: FILE: drivers/gpu/drm/i915/gt/intel_sseu.h:178:
+void intel_sseu_print_ss_info(const char* type,
total: 2 errors, 1 warnings, 0 checks, 830 lines checked
acc8c6a07c85 drm/i915/pvc: Add SSEU changes
[Intel-gfx] [PATCH 2/3] drm/i915: Update eDP fast link training link rate parsing
From: Ville Syrjälä
We're not parsing the 5.4 Gbps value for the old eDP fast link
training link rate, nor are we parsing the new fast link training
link rate field. Remedy both.
Note that we're not even using this information for anything
currently, so should perhaps just nuke it all unless someone
is planning on implementing fast link training finally...
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c | 32 ---
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 1 +
2 files changed, 21 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index c42b9e7d0dce..d701854dc429 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -1367,18 +1367,26 @@ parse_edp(struct drm_i915_private *i915,
panel->vbt.edp.pps = *edp_pps;
- switch (edp_link_params->rate) {
- case EDP_RATE_1_62:
- panel->vbt.edp.rate = DP_LINK_BW_1_62;
- break;
- case EDP_RATE_2_7:
- panel->vbt.edp.rate = DP_LINK_BW_2_7;
- break;
- default:
- drm_dbg_kms(>drm,
- "VBT has unknown eDP link rate value %u\n",
-edp_link_params->rate);
- break;
+ if (i915->vbt.version >= 224) {
+ panel->vbt.edp.rate =
+ edp->edp_fast_link_training_rate[panel_type] * 2;
+ } else {
+ switch (edp_link_params->rate) {
+ case EDP_RATE_1_62:
+ panel->vbt.edp.rate = DP_LINK_BW_1_62;
+ break;
+ case EDP_RATE_2_7:
+ panel->vbt.edp.rate = DP_LINK_BW_2_7;
+ break;
+ case EDP_RATE_5_4:
+ panel->vbt.edp.rate = DP_LINK_BW_5_4;
+ break;
+ default:
+ drm_dbg_kms(>drm,
+ "VBT has unknown eDP link rate value %u\n",
+ edp_link_params->rate);
+ break;
+ }
}
switch (edp_link_params->lanes) {
diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
index 14f1e1cc92c5..58aee0a040cf 100644
--- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
@@ -638,6 +638,7 @@ struct bdb_sdvo_panel_dtds {
#define EDP_30BPP 2
#define EDP_RATE_1_62 0
#define EDP_RATE_2_7 1
+#define EDP_RATE_5_4 2
#define EDP_LANE_1 0
#define EDP_LANE_2 1
#define EDP_LANE_4 3
--
2.35.1
[Intel-gfx] [PATCH 3/3] drm/i915: Parse max link rate from the eDP BDB block
From: Ville Syrjälä
The eDP BDB block has gained yet another max link rate field.
Let's parse it and consult it during the source rate filtering.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c | 4
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 23 +--
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 1 +
4 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index d701854dc429..b35afd39413d 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -1461,6 +1461,10 @@ parse_edp(struct drm_i915_private *i915,
panel->vbt.edp.drrs_msa_timing_delay =
(edp->sdrrs_msa_timing_delay >> (panel_type * 2)) & 3;
+
+ if (i915->vbt.version >= 244)
+ panel->vbt.edp.max_link_rate =
+ edp->edp_max_port_link_rate[panel_type] * 2;
}
static void
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 9b44358e8d9e..8b0949b6dc75 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -300,6 +300,7 @@ struct intel_vbt_panel_data {
enum drrs_type drrs_type;
struct {
+ int max_link_rate;
int rate;
int lanes;
int preemphasis;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 03af93ef9e93..2b84d6fcba4a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -408,6 +408,26 @@ static int ehl_max_source_rate(struct intel_dp *intel_dp)
return 81;
}
+static int vbt_max_link_rate(struct intel_dp *intel_dp)
+{
+ struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
+ struct intel_connector *connector = intel_dp->attached_connector;
+ int max_rate;
+
+ max_rate = intel_bios_dp_max_link_rate(encoder);
+
+ if (intel_dp_is_edp(intel_dp)) {
+ int edp_max_rate = connector->panel.vbt.edp.max_link_rate;
+
+ if (max_rate && edp_max_rate)
+ max_rate = min(max_rate, edp_max_rate);
+ else if (edp_max_rate)
+ max_rate = edp_max_rate;
+ }
+
+ return max_rate;
+}
+
static void
intel_dp_set_source_rates(struct intel_dp *intel_dp)
{
@@ -429,7 +449,6 @@ intel_dp_set_source_rates(struct intel_dp *intel_dp)
162000, 27
};
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
- struct intel_encoder *encoder = _port->base;
struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
const int *source_rates;
int size, max_rate = 0, vbt_max_rate;
@@ -465,7 +484,7 @@ intel_dp_set_source_rates(struct intel_dp *intel_dp)
size = ARRAY_SIZE(g4x_rates);
}
- vbt_max_rate = intel_bios_dp_max_link_rate(encoder);
+ vbt_max_rate = vbt_max_link_rate(intel_dp);
if (max_rate && vbt_max_rate)
max_rate = min(max_rate, vbt_max_rate);
else if (vbt_max_rate)
diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
index 58aee0a040cf..f8e5097222f2 100644
--- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
@@ -697,6 +697,7 @@ struct bdb_edp {
u16 apical_enable; /* 203 */
struct edp_apical_params apical_params[16]; /* 203 */
u16 edp_fast_link_training_rate[16];/* 224 */
+ u16 edp_max_port_link_rate[16]; /* 244 */
} __packed;
/*
--
2.35.1
[Intel-gfx] [PATCH 1/3] drm/i915: Initialize eDP source rates after per-panel VBT parsing
From: Ville Syrjälä
We'll need to know the VBT panel_type before we can determine the
maximum link rate for eDP. To that end move
intel_dp_set_source_rates() & co. to be called after the per-panel
VBT parsing has been done.
I'm not immediately spotting anything that would consult the link
rate arrays before this, so seems safe enough.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index b8e2d3cd4d68..03af93ef9e93 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2852,9 +2852,6 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
intel_dp_set_sink_rates(intel_dp);
intel_dp_set_max_sink_lane_count(intel_dp);
- intel_dp_set_common_rates(intel_dp);
- intel_dp_reset_max_link_params(intel_dp);
-
/* Read the eDP DSC DPCD registers */
if (DISPLAY_VER(dev_priv) >= 10)
intel_dp_get_dsc_sink_cap(intel_dp);
@@ -5342,11 +5339,8 @@ intel_dp_init_connector(struct intel_digital_port
*dig_port,
type = DRM_MODE_CONNECTOR_DisplayPort;
}
- intel_dp_set_source_rates(intel_dp);
intel_dp_set_default_sink_rates(intel_dp);
intel_dp_set_default_max_sink_lane_count(intel_dp);
- intel_dp_set_common_rates(intel_dp);
- intel_dp_reset_max_link_params(intel_dp);
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
intel_dp->pps.active_pipe = vlv_active_pipe(intel_dp);
@@ -5384,6 +5378,10 @@ intel_dp_init_connector(struct intel_digital_port
*dig_port,
goto fail;
}
+ intel_dp_set_source_rates(intel_dp);
+ intel_dp_set_common_rates(intel_dp);
+ intel_dp_reset_max_link_params(intel_dp);
+
intel_dp_add_properties(intel_dp, connector);
if (is_hdcp_supported(dev_priv, port) && !intel_dp_is_edp(intel_dp)) {
--
2.35.1
[Intel-gfx] [PATCH 0/3] drm/i915: Parse more eDP link rate stuff from VBT
From: Ville Syrjälä VBT has gained a couple of new ways to specify fast link training and maximum link rates. Parse all of it. Ville Syrjälä (3): drm/i915: Initialize eDP source rates after per-panel VBT parsing drm/i915: Update eDP fast link training link rate parsing drm/i915: Parse max link rate from the eDP BDB block drivers/gpu/drm/i915/display/intel_bios.c | 36 --- .../drm/i915/display/intel_display_types.h| 1 + drivers/gpu/drm/i915/display/intel_dp.c | 33 - drivers/gpu/drm/i915/display/intel_vbt_defs.h | 2 ++ 4 files changed, 52 insertions(+), 20 deletions(-) -- 2.35.1
[Intel-gfx] [PATCH v5 3/6] drm/i915/sseu: Simplify gen11+ SSEU handling
Although gen11 and gen12 architectures supported the concept of multiple
slices, in practice all the platforms that were actually designed only
had a single slice (i.e., note the parameters to 'intel_sseu_set_info'
that we pass for each platform). We can simplify the code slightly by
dropping the multi-slice logic from gen11+ platforms.
v2:
- Promote drm_dbg to drm_WARN_ON if the slice fuse register reports
unexpected fusing. (Tvrtko)
Cc: Tvrtko Ursulin
Signed-off-by: Matt Roper
Acked-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_sseu.c | 76 +---
1 file changed, 36 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c
b/drivers/gpu/drm/i915/gt/intel_sseu.c
index b5fd479a7b85..7e5222ad2f98 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -119,52 +119,37 @@ static u16 compute_eu_total(const struct sseu_dev_info
*sseu)
return total;
}
-static u32 get_ss_stride_mask(struct sseu_dev_info *sseu, u8 s, u32 ss_en)
-{
- u32 ss_mask;
-
- ss_mask = ss_en >> (s * sseu->max_subslices);
- ss_mask &= GENMASK(sseu->max_subslices - 1, 0);
-
- return ss_mask;
-}
-
-static void gen11_compute_sseu_info(struct sseu_dev_info *sseu, u8 s_en,
+static void gen11_compute_sseu_info(struct sseu_dev_info *sseu,
u32 g_ss_en, u32 c_ss_en, u16 eu_en)
{
- int s, ss;
+ u32 valid_ss_mask = GENMASK(sseu->max_subslices - 1, 0);
+ int ss;
/* g_ss_en/c_ss_en represent entire subslice mask across all slices */
GEM_BUG_ON(sseu->max_slices * sseu->max_subslices >
sizeof(g_ss_en) * BITS_PER_BYTE);
- for (s = 0; s < sseu->max_slices; s++) {
- if ((s_en & BIT(s)) == 0)
- continue;
+ sseu->slice_mask |= BIT(0);
- sseu->slice_mask |= BIT(s);
-
- /*
-* XeHP introduces the concept of compute vs geometry DSS. To
-* reduce variation between GENs around subslice usage, store a
-* mask for both the geometry and compute enabled masks since
-* userspace will need to be able to query these masks
-* independently. Also compute a total enabled subslice count
-* for the purposes of selecting subslices to use in a
-* particular GEM context.
-*/
- intel_sseu_set_subslices(sseu, s, sseu->compute_subslice_mask,
-get_ss_stride_mask(sseu, s, c_ss_en));
- intel_sseu_set_subslices(sseu, s, sseu->geometry_subslice_mask,
-get_ss_stride_mask(sseu, s, g_ss_en));
- intel_sseu_set_subslices(sseu, s, sseu->subslice_mask,
-get_ss_stride_mask(sseu, s,
- g_ss_en | c_ss_en));
+ /*
+* XeHP introduces the concept of compute vs geometry DSS. To reduce
+* variation between GENs around subslice usage, store a mask for both
+* the geometry and compute enabled masks since userspace will need to
+* be able to query these masks independently. Also compute a total
+* enabled subslice count for the purposes of selecting subslices to
+* use in a particular GEM context.
+*/
+ intel_sseu_set_subslices(sseu, 0, sseu->compute_subslice_mask,
+c_ss_en & valid_ss_mask);
+ intel_sseu_set_subslices(sseu, 0, sseu->geometry_subslice_mask,
+g_ss_en & valid_ss_mask);
+ intel_sseu_set_subslices(sseu, 0, sseu->subslice_mask,
+(g_ss_en | c_ss_en) & valid_ss_mask);
+
+ for (ss = 0; ss < sseu->max_subslices; ss++)
+ if (intel_sseu_has_subslice(sseu, 0, ss))
+ sseu_set_eus(sseu, 0, ss, eu_en);
- for (ss = 0; ss < sseu->max_subslices; ss++)
- if (intel_sseu_has_subslice(sseu, s, ss))
- sseu_set_eus(sseu, s, ss, eu_en);
- }
sseu->eu_per_subslice = hweight16(eu_en);
sseu->eu_total = compute_eu_total(sseu);
}
@@ -196,7 +181,7 @@ static void xehp_sseu_info_init(struct intel_gt *gt)
if (eu_en_fuse & BIT(eu))
eu_en |= BIT(eu * 2) | BIT(eu * 2 + 1);
- gen11_compute_sseu_info(sseu, 0x1, g_dss_en, c_dss_en, eu_en);
+ gen11_compute_sseu_info(sseu, g_dss_en, c_dss_en, eu_en);
}
static void gen12_sseu_info_init(struct intel_gt *gt)
@@ -216,8 +201,13 @@ static void gen12_sseu_info_init(struct intel_gt *gt)
*/
intel_sseu_set_info(sseu, 1, 6, 16);
+ /*
+* Although gen12 architecture supported multiple slices, TGL, RKL,
+* DG1, and ADL only had a single slice.
+
[Intel-gfx] [PATCH v5 2/6] drm/i915/xehp: Drop GETPARAM lookups of I915_PARAM_[SUB]SLICE_MASK
Slice/subslice/EU information should be obtained via the topology queries provided by the I915_QUERY interface; let's turn off support for the old GETPARAM lookups on Xe_HP and beyond where we can't return meaningful values. The slice mask lookup is meaningless since Xe_HP doesn't support traditional slices (and we make no attempt to return the various new units like gslices, cslices, mslices, etc.) here. The subslice mask lookup is even more problematic; given the distinct masks for geometry vs compute purposes, the combined mask returned here is likely not what userspace would want to act upon anyway. The value is also limited to 32-bits by the nature of the GETPARAM ioctl which is sufficient for the initial Xe_HP platforms, but is unable to convey the larger masks that will be needed on other upcoming platforms. Finally, the value returned here becomes even less meaningful when used on multi-tile platforms where each tile will have its own masks. Signed-off-by: Matt Roper Acked-by: Tvrtko Ursulin Acked-by: Lionel Landwerlin # mesa --- drivers/gpu/drm/i915/i915_getparam.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_getparam.c b/drivers/gpu/drm/i915/i915_getparam.c index c12a0adefda5..ac9767c56619 100644 --- a/drivers/gpu/drm/i915/i915_getparam.c +++ b/drivers/gpu/drm/i915/i915_getparam.c @@ -148,11 +148,19 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data, value = intel_engines_has_context_isolation(i915); break; case I915_PARAM_SLICE_MASK: + /* Not supported from Xe_HP onward; use topology queries */ + if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) + return -EINVAL; + value = sseu->slice_mask; if (!value) return -ENODEV; break; case I915_PARAM_SUBSLICE_MASK: + /* Not supported from Xe_HP onward; use topology queries */ + if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) + return -EINVAL; + /* Only copy bits from the first slice */ memcpy(, sseu->subslice_mask, min(sseu->ss_stride, (u8)sizeof(value))); -- 2.35.3
[Intel-gfx] [PATCH v5 5/6] drm/i915/sseu: Disassociate internal subslice mask representation from uapi
As with EU masks, it's easier to store subslice/DSS masks internally in
a format that's more natural for the driver to work with, and then only
covert into the u8[] uapi form when the query ioctl is invoked. Since
the hardware design changed significantly with Xe_HP, we'll use a union
to choose between the old "hsw-style" subslice masks or the newer xehp
mask. HSW-style masks will be stored in an array of u8's, indexed by
slice (there's never more than 6 subslices per slice on older
platforms). For Xe_HP and beyond where slices no longer exist, we only
need a single bitmask. However we already know that this mask is
eventually going to grow too large for a simple u64 to hold, so we'll
represent it in a manner that can be operated on by the utilities in
linux/bitmap.h.
v2:
- Fix typo: BIT(s) -> BIT(ss) in gen9_sseu_device_status()
v3:
- Eliminate sseu->ss_stride and just calculate the stride while
specifically handling uapi. (Tvrtko)
- Use BITMAP_BITS() macro to refer to size of masks rather than
passing I915_MAX_SS_FUSE_BITS directly. (Tvrtko)
- Report compute/geometry DSS masks separately when dumping Xe_HP SSEU
info. (Tvrtko)
- Restore dropped range checks to intel_sseu_has_subslice(). (Tvrtko)
v4:
- Make the bitmap size macro check the size of the .xehp field rather
than the containing union. (Tvrtko)
- Don't add GEM_BUG_ON() intel_sseu_has_subslice()'s check for whether
slice or subslice ID exceed sseu->max_[sub]slices; various loops
in the driver are expected to exceed these, so we should just
silently return 'false.'
v5:
- Move XEHP_BITMAP_BITS() to the header so that we can also replace a
usage of I915_MAX_SS_FUSE_BITS in one of the inline functions.
(Bala)
- Change the local variable in intel_slicemask_from_xehp_dssmask() from
u16 to 'unsigned long' to make it a bit more future-proof.
Cc: Tvrtko Ursulin
Cc: Balasubramani Vivekanandan
Signed-off-by: Matt Roper
Acked-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 5 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 4 +-
drivers/gpu/drm/i915/gt/intel_gt.c | 12 +-
drivers/gpu/drm/i915/gt/intel_sseu.c | 261 +++
drivers/gpu/drm/i915/gt/intel_sseu.h | 79 --
drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c | 30 +--
drivers/gpu/drm/i915/gt/intel_workarounds.c | 24 +-
drivers/gpu/drm/i915/i915_getparam.c | 3 +-
drivers/gpu/drm/i915/i915_query.c| 13 +-
9 files changed, 243 insertions(+), 188 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index ab4c5ab28e4d..a3bb73f5d53b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1875,6 +1875,7 @@ i915_gem_user_to_context_sseu(struct intel_gt *gt,
{
const struct sseu_dev_info *device = >info.sseu;
struct drm_i915_private *i915 = gt->i915;
+ unsigned int dev_subslice_mask = intel_sseu_get_hsw_subslices(device,
0);
/* No zeros in any field. */
if (!user->slice_mask || !user->subslice_mask ||
@@ -1901,7 +1902,7 @@ i915_gem_user_to_context_sseu(struct intel_gt *gt,
if (user->slice_mask & ~device->slice_mask)
return -EINVAL;
- if (user->subslice_mask & ~device->subslice_mask[0])
+ if (user->subslice_mask & ~dev_subslice_mask)
return -EINVAL;
if (user->max_eus_per_subslice > device->max_eus_per_subslice)
@@ -1915,7 +1916,7 @@ i915_gem_user_to_context_sseu(struct intel_gt *gt,
/* Part specific restrictions. */
if (GRAPHICS_VER(i915) == 11) {
unsigned int hw_s = hweight8(device->slice_mask);
- unsigned int hw_ss_per_s = hweight8(device->subslice_mask[0]);
+ unsigned int hw_ss_per_s = hweight8(dev_subslice_mask);
unsigned int req_s = hweight8(context->slice_mask);
unsigned int req_ss = hweight8(context->subslice_mask);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 1adbf34c3632..f0acf8518a51 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -674,8 +674,8 @@ static void engine_mask_apply_compute_fuses(struct intel_gt
*gt)
if (GRAPHICS_VER_FULL(i915) < IP_VER(12, 50))
return;
- ccs_mask =
intel_slicemask_from_dssmask(intel_sseu_get_compute_subslices(>sseu),
- ss_per_ccs);
+ ccs_mask =
intel_slicemask_from_xehp_dssmask(info->sseu.compute_subslice_mask,
+ss_per_ccs);
/*
* If all DSS in a quadrant are fused off, the corresponding CCS
* engine is not available for use.
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index
[Intel-gfx] [PATCH v5 1/6] drm/i915/xehp: Use separate sseu init function
Xe_HP has enough fundamental differences from previous platforms that it
makes sense to use a separate SSEU init function to keep things
straightforward and easy to understand. We'll also add a has_xehp_dss
flag to the SSEU structure that will be used by other upcoming changes.
v2:
- Add has_xehp_dss flag
Signed-off-by: Matt Roper
Acked-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_sseu.c | 86
drivers/gpu/drm/i915/gt/intel_sseu.h | 5 ++
2 files changed, 54 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c
b/drivers/gpu/drm/i915/gt/intel_sseu.c
index fdd25691beda..b5fd479a7b85 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -169,13 +169,43 @@ static void gen11_compute_sseu_info(struct sseu_dev_info
*sseu, u8 s_en,
sseu->eu_total = compute_eu_total(sseu);
}
-static void gen12_sseu_info_init(struct intel_gt *gt)
+static void xehp_sseu_info_init(struct intel_gt *gt)
{
struct sseu_dev_info *sseu = >info.sseu;
struct intel_uncore *uncore = gt->uncore;
u32 g_dss_en, c_dss_en = 0;
u16 eu_en = 0;
u8 eu_en_fuse;
+ int eu;
+
+ /*
+* The concept of slice has been removed in Xe_HP. To be compatible
+* with prior generations, assume a single slice across the entire
+* device. Then calculate out the DSS for each workload type within
+* that software slice.
+*/
+ intel_sseu_set_info(sseu, 1, 32, 16);
+ sseu->has_xehp_dss = 1;
+
+ g_dss_en = intel_uncore_read(uncore, GEN12_GT_GEOMETRY_DSS_ENABLE);
+ c_dss_en = intel_uncore_read(uncore, GEN12_GT_COMPUTE_DSS_ENABLE);
+
+ eu_en_fuse = intel_uncore_read(uncore, XEHP_EU_ENABLE) &
XEHP_EU_ENA_MASK;
+
+ for (eu = 0; eu < sseu->max_eus_per_subslice / 2; eu++)
+ if (eu_en_fuse & BIT(eu))
+ eu_en |= BIT(eu * 2) | BIT(eu * 2 + 1);
+
+ gen11_compute_sseu_info(sseu, 0x1, g_dss_en, c_dss_en, eu_en);
+}
+
+static void gen12_sseu_info_init(struct intel_gt *gt)
+{
+ struct sseu_dev_info *sseu = >info.sseu;
+ struct intel_uncore *uncore = gt->uncore;
+ u32 g_dss_en;
+ u16 eu_en = 0;
+ u8 eu_en_fuse;
u8 s_en;
int eu;
@@ -183,43 +213,23 @@ static void gen12_sseu_info_init(struct intel_gt *gt)
* Gen12 has Dual-Subslices, which behave similarly to 2 gen11 SS.
* Instead of splitting these, provide userspace with an array
* of DSS to more closely represent the hardware resource.
-*
-* In addition, the concept of slice has been removed in Xe_HP.
-* To be compatible with prior generations, assume a single slice
-* across the entire device. Then calculate out the DSS for each
-* workload type within that software slice.
*/
- if (IS_DG2(gt->i915) || IS_XEHPSDV(gt->i915))
- intel_sseu_set_info(sseu, 1, 32, 16);
- else
- intel_sseu_set_info(sseu, 1, 6, 16);
+ intel_sseu_set_info(sseu, 1, 6, 16);
- /*
-* As mentioned above, Xe_HP does not have the concept of a slice.
-* Enable one for software backwards compatibility.
-*/
- if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 50))
- s_en = 0x1;
- else
- s_en = intel_uncore_read(uncore, GEN11_GT_SLICE_ENABLE) &
- GEN11_GT_S_ENA_MASK;
+ s_en = intel_uncore_read(uncore, GEN11_GT_SLICE_ENABLE) &
+ GEN11_GT_S_ENA_MASK;
g_dss_en = intel_uncore_read(uncore, GEN12_GT_GEOMETRY_DSS_ENABLE);
- if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 50))
- c_dss_en = intel_uncore_read(uncore,
GEN12_GT_COMPUTE_DSS_ENABLE);
/* one bit per pair of EUs */
- if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 50))
- eu_en_fuse = intel_uncore_read(uncore, XEHP_EU_ENABLE) &
XEHP_EU_ENA_MASK;
- else
- eu_en_fuse = ~(intel_uncore_read(uncore, GEN11_EU_DISABLE) &
- GEN11_EU_DIS_MASK);
+ eu_en_fuse = ~(intel_uncore_read(uncore, GEN11_EU_DISABLE) &
+ GEN11_EU_DIS_MASK);
for (eu = 0; eu < sseu->max_eus_per_subslice / 2; eu++)
if (eu_en_fuse & BIT(eu))
eu_en |= BIT(eu * 2) | BIT(eu * 2 + 1);
- gen11_compute_sseu_info(sseu, s_en, g_dss_en, c_dss_en, eu_en);
+ gen11_compute_sseu_info(sseu, s_en, g_dss_en, 0, eu_en);
/* TGL only supports slice-level power gating */
sseu->has_slice_pg = 1;
@@ -574,18 +584,20 @@ void intel_sseu_info_init(struct intel_gt *gt)
{
struct drm_i915_private *i915 = gt->i915;
- if (IS_HASWELL(i915))
- hsw_sseu_info_init(gt);
- else if (IS_CHERRYVIEW(i915))
- cherryview_sseu_info_init(gt);
- else if (IS_BROADWELL(i915))
-
[Intel-gfx] [PATCH v5 4/6] drm/i915/sseu: Don't try to store EU mask internally in UAPI format
Storing the EU mask internally in the same format the I915_QUERY
topology queries use makes the final copy_to_user() a bit simpler, but
makes the rest of the driver's SSEU more complicated and harder to
follow. Let's switch to an internal representation that's more natural:
Xe_HP platforms will be a simple array of u16 masks, whereas pre-Xe_HP
platforms will be a two-dimensional array, indexed by [slice][subslice].
We'll convert to the uapi format only when the query uapi is called.
v2:
- Drop has_common_ss_eumask. We waste some space repeating identical
EU masks for every single DSS, but the code is simpler without it.
(Tvrtko)
v3:
- Mask down EUs passed to sseu_set_eus at the callsite rather than
inside the function. (Tvrtko)
- Eliminate sseu->eu_stride and calculate it when needed. (Tvrtko)
Cc: Tvrtko Ursulin
Signed-off-by: Matt Roper
Acked-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_sseu.c | 88 ++--
drivers/gpu/drm/i915/gt/intel_sseu.h | 10 +++-
drivers/gpu/drm/i915/i915_query.c| 13 ++--
3 files changed, 73 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c
b/drivers/gpu/drm/i915/gt/intel_sseu.c
index 7e5222ad2f98..285cfd758bdc 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -19,8 +19,6 @@ void intel_sseu_set_info(struct sseu_dev_info *sseu, u8
max_slices,
sseu->ss_stride = GEN_SSEU_STRIDE(sseu->max_subslices);
GEM_BUG_ON(sseu->ss_stride > GEN_MAX_SUBSLICE_STRIDE);
- sseu->eu_stride = GEN_SSEU_STRIDE(sseu->max_eus_per_subslice);
- GEM_BUG_ON(sseu->eu_stride > GEN_MAX_EU_STRIDE);
}
unsigned int
@@ -78,47 +76,77 @@ intel_sseu_subslices_per_slice(const struct sseu_dev_info
*sseu, u8 slice)
return hweight32(intel_sseu_get_subslices(sseu, slice));
}
-static int sseu_eu_idx(const struct sseu_dev_info *sseu, int slice,
- int subslice)
-{
- int slice_stride = sseu->max_subslices * sseu->eu_stride;
-
- return slice * slice_stride + subslice * sseu->eu_stride;
-}
-
static u16 sseu_get_eus(const struct sseu_dev_info *sseu, int slice,
int subslice)
{
- int i, offset = sseu_eu_idx(sseu, slice, subslice);
- u16 eu_mask = 0;
-
- for (i = 0; i < sseu->eu_stride; i++)
- eu_mask |=
- ((u16)sseu->eu_mask[offset + i]) << (i * BITS_PER_BYTE);
-
- return eu_mask;
+ if (sseu->has_xehp_dss) {
+ WARN_ON(slice > 0);
+ return sseu->eu_mask.xehp[subslice];
+ } else {
+ return sseu->eu_mask.hsw[slice][subslice];
+ }
}
static void sseu_set_eus(struct sseu_dev_info *sseu, int slice, int subslice,
u16 eu_mask)
{
- int i, offset = sseu_eu_idx(sseu, slice, subslice);
-
- for (i = 0; i < sseu->eu_stride; i++)
- sseu->eu_mask[offset + i] =
- (eu_mask >> (BITS_PER_BYTE * i)) & 0xff;
+ GEM_WARN_ON(eu_mask && __fls(eu_mask) >= sseu->max_eus_per_subslice);
+ if (sseu->has_xehp_dss) {
+ GEM_WARN_ON(slice > 0);
+ sseu->eu_mask.xehp[subslice] = eu_mask;
+ } else {
+ sseu->eu_mask.hsw[slice][subslice] = eu_mask;
+ }
}
static u16 compute_eu_total(const struct sseu_dev_info *sseu)
{
- u16 i, total = 0;
+ int s, ss, total = 0;
- for (i = 0; i < ARRAY_SIZE(sseu->eu_mask); i++)
- total += hweight8(sseu->eu_mask[i]);
+ for (s = 0; s < sseu->max_slices; s++)
+ for (ss = 0; ss < sseu->max_subslices; ss++)
+ if (sseu->has_xehp_dss)
+ total += hweight16(sseu->eu_mask.xehp[ss]);
+ else
+ total += hweight16(sseu->eu_mask.hsw[s][ss]);
return total;
}
+/**
+ * intel_sseu_copy_eumask_to_user - Copy EU mask into a userspace buffer
+ * @to: Pointer to userspace buffer to copy to
+ * @sseu: SSEU structure containing EU mask to copy
+ *
+ * Copies the EU mask to a userspace buffer in the format expected by
+ * the query ioctl's topology queries.
+ *
+ * Returns the result of the copy_to_user() operation.
+ */
+int intel_sseu_copy_eumask_to_user(void __user *to,
+ const struct sseu_dev_info *sseu)
+{
+ u8 eu_mask[GEN_SS_MASK_SIZE * GEN_MAX_EU_STRIDE] = {};
+ int eu_stride = GEN_SSEU_STRIDE(sseu->max_eus_per_subslice);
+ int len = sseu->max_slices * sseu->max_subslices * eu_stride;
+ int s, ss, i;
+
+ for (s = 0; s < sseu->max_slices; s++) {
+ for (ss = 0; ss < sseu->max_subslices; ss++) {
+ int uapi_offset =
+ s * sseu->max_subslices * eu_stride +
+ ss * eu_stride;
+ u16 mask = sseu_get_eus(sseu, s, ss);
+
+
[Intel-gfx] [PATCH v5 0/6] i915: SSEU handling updates
This series reworks i915's internal handling of slice/subslice/EU (SSEU) data to represent platforms like Xe_HP in a more natural manner and to prepare for future platforms where the masks will need to grow in size. One key idea of this series is that although we have a fixed ABI to convey SSEU data to userspace (i.e., multiple u8[] arrays with data stored at different strides), we don't need to use this cumbersome format for the driver's own internal storage. As long as we can convert into the uapi form properly when responding to the I915_QUERY ioctl, it's preferable to use an internal storage format that's easier for the driver to work with. Another key point here is that we're reaching the point where subslice (DSS) masks will soon not fit within simple u32/u64 integer values. Xe_HP SDV and DG2 platforms today have subslice (DSS) masks that are 32 bits, which maxes out the current storage of a u32. With PVC the masks are represented by a pair of 32-bit registers, requiring a bump up to at least 64-bits of storage internally. We could switch to u64 for that in the short term, but since we already know that upcoming architectures intend to provide DSS fuse bits via three or more registers it's best to switch to a representation that's more future-proof but still easy to work with in the driver code. To accomodate this, we start storing our subslice mask for Xe_HP and beyond in a new typedef that can be processed by the linux/bitmap.h operations. Finally, since no userspace for Xe_HP or beyond is using the legacy I915_GETPARAM ioctl lookups for I915_PARAM_SLICE_MASK and I915_PARAM_SUBSLICE_MASK (since they've migrated to the more flexible I915_QUERY ioctl that can return more than a simple u32 value), we take the opportunity to officially drop support for those GETPARAM lookups on modern platforms. Maintaining support for these GETPARAM lookups don't make sense for a number of reasons: * Traditional slices no longer exist, and newer ideas like gslices, cslices,
[Intel-gfx] [PATCH v5 6/6] drm/i915/pvc: Add SSEU changes
PVC splits the mask of enabled DSS over two registers. It also changes
the meaning of the EU fuse register such that each bit represents a
single EU rather than a pair of EUs.
Signed-off-by: Matt Roper
Acked-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
drivers/gpu/drm/i915/gt/intel_sseu.c | 31 ++--
drivers/gpu/drm/i915/gt/intel_sseu.h | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_pci.c | 3 ++-
drivers/gpu/drm/i915/intel_device_info.h | 1 +
6 files changed, 31 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 58e9b464d564..6aa1ceaa8d27 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -561,6 +561,7 @@
#define GEN11_GT_VEBOX_DISABLE_MASK (0x0f <<
GEN11_GT_VEBOX_DISABLE_SHIFT)
#define GEN12_GT_COMPUTE_DSS_ENABLE_MMIO(0x9144)
+#define XEHPC_GT_COMPUTE_DSS_ENABLE_EXT_MMIO(0x9148)
#define GEN6_UCGCTL1 _MMIO(0x9400)
#define GEN6_GAMUNIT_CLOCK_GATE_DISABLE (1 << 22)
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c
b/drivers/gpu/drm/i915/gt/intel_sseu.c
index 38069330d828..5cc1896a6cb9 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -210,27 +210,44 @@ static void xehp_sseu_info_init(struct intel_gt *gt)
struct intel_uncore *uncore = gt->uncore;
u16 eu_en = 0;
u8 eu_en_fuse;
+ int num_compute_regs, num_geometry_regs;
int eu;
+ if (IS_PONTEVECCHIO(gt->i915)) {
+ num_geometry_regs = 0;
+ num_compute_regs = 2;
+ } else {
+ num_geometry_regs = 1;
+ num_compute_regs = 1;
+ }
+
/*
* The concept of slice has been removed in Xe_HP. To be compatible
* with prior generations, assume a single slice across the entire
* device. Then calculate out the DSS for each workload type within
* that software slice.
*/
- intel_sseu_set_info(sseu, 1, 32, 16);
+ intel_sseu_set_info(sseu, 1,
+ 32 * max(num_geometry_regs, num_compute_regs),
+ 16);
sseu->has_xehp_dss = 1;
- xehp_load_dss_mask(uncore, >geometry_subslice_mask, 1,
+ xehp_load_dss_mask(uncore, >geometry_subslice_mask,
+ num_geometry_regs,
GEN12_GT_GEOMETRY_DSS_ENABLE);
- xehp_load_dss_mask(uncore, >compute_subslice_mask, 1,
- GEN12_GT_COMPUTE_DSS_ENABLE);
+ xehp_load_dss_mask(uncore, >compute_subslice_mask,
+ num_compute_regs,
+ GEN12_GT_COMPUTE_DSS_ENABLE,
+ XEHPC_GT_COMPUTE_DSS_ENABLE_EXT);
eu_en_fuse = intel_uncore_read(uncore, XEHP_EU_ENABLE) &
XEHP_EU_ENA_MASK;
- for (eu = 0; eu < sseu->max_eus_per_subslice / 2; eu++)
- if (eu_en_fuse & BIT(eu))
- eu_en |= BIT(eu * 2) | BIT(eu * 2 + 1);
+ if (HAS_ONE_EU_PER_FUSE_BIT(gt->i915))
+ eu_en = eu_en_fuse;
+ else
+ for (eu = 0; eu < sseu->max_eus_per_subslice / 2; eu++)
+ if (eu_en_fuse & BIT(eu))
+ eu_en |= BIT(eu * 2) | BIT(eu * 2 + 1);
xehp_compute_sseu_info(sseu, eu_en);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.h
b/drivers/gpu/drm/i915/gt/intel_sseu.h
index 61abcab5a76b..b86f23f5b3a1 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.h
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.h
@@ -33,7 +33,7 @@ struct drm_printer;
* Maximum number of 32-bit registers used by hardware to express the
* enabled/disabled subslices.
*/
-#define I915_MAX_SS_FUSE_REGS 1
+#define I915_MAX_SS_FUSE_REGS 2
#define I915_MAX_SS_FUSE_BITS (I915_MAX_SS_FUSE_REGS * 32)
/* Maximum number of EUs that can exist within a subslice or DSS. */
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bc1a7ff19463..c3854b8a014f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1359,6 +1359,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
#define HAS_3D_PIPELINE(i915) (INTEL_INFO(i915)->has_3d_pipeline)
+#define HAS_ONE_EU_PER_FUSE_BIT(i915)
(INTEL_INFO(i915)->has_one_eu_per_fuse_bit)
+
/* i915_gem.c */
void i915_gem_init_early(struct drm_i915_private *dev_priv);
void i915_gem_cleanup_early(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 61386d1bb07b..047a6e326031 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1089,7 +1089,8 @@ static const struct intel_device_info ats_m_info = {
XE_HP_FEATURES, \
Re: [Intel-gfx] [PATCH v5 5/6] drm/i915/sseu: Disassociate internal subslice mask representation from uapi
On Wed, Jun 01, 2022 at 01:48:56PM +0530, Balasubramani Vivekanandan wrote:
> On 23.05.2022 13:45, Matt Roper wrote:
> > As with EU masks, it's easier to store subslice/DSS masks internally in
> > a format that's more natural for the driver to work with, and then only
> > covert into the u8[] uapi form when the query ioctl is invoked. Since
> > the hardware design changed significantly with Xe_HP, we'll use a union
> > to choose between the old "hsw-style" subslice masks or the newer xehp
> > mask. HSW-style masks will be stored in an array of u8's, indexed by
> > slice (there's never more than 6 subslices per slice on older
> > platforms). For Xe_HP and beyond where slices no longer exist, we only
> > need a single bitmask. However we already know that this mask is
> > eventually going to grow too large for a simple u64 to hold, so we'll
> > represent it in a manner that can be operated on by the utilities in
> > linux/bitmap.h.
> >
> > v2:
> > - Fix typo: BIT(s) -> BIT(ss) in gen9_sseu_device_status()
> >
> > v3:
> > - Eliminate sseu->ss_stride and just calculate the stride while
> >specifically handling uapi. (Tvrtko)
> > - Use BITMAP_BITS() macro to refer to size of masks rather than
> >passing I915_MAX_SS_FUSE_BITS directly. (Tvrtko)
> > - Report compute/geometry DSS masks separately when dumping Xe_HP SSEU
> >info. (Tvrtko)
> > - Restore dropped range checks to intel_sseu_has_subslice(). (Tvrtko)
> >
> > v4:
> > - Make the bitmap size macro check the size of the .xehp field rather
> >than the containing union. (Tvrtko)
> > - Don't add GEM_BUG_ON() intel_sseu_has_subslice()'s check for whether
> >slice or subslice ID exceed sseu->max_[sub]slices; various loops
> >in the driver are expected to exceed these, so we should just
> >silently return 'false.'
> >
> > Cc: Tvrtko Ursulin
> > Signed-off-by: Matt Roper
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_context.c | 5 +-
> > drivers/gpu/drm/i915/gt/intel_engine_cs.c| 4 +-
> > drivers/gpu/drm/i915/gt/intel_gt.c | 12 +-
> > drivers/gpu/drm/i915/gt/intel_sseu.c | 261 +++
> > drivers/gpu/drm/i915/gt/intel_sseu.h | 76 --
> > drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c | 30 +--
> > drivers/gpu/drm/i915/gt/intel_workarounds.c | 24 +-
> > drivers/gpu/drm/i915/i915_getparam.c | 3 +-
> > drivers/gpu/drm/i915/i915_query.c| 13 +-
> > 9 files changed, 241 insertions(+), 187 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index ab4c5ab28e4d..a3bb73f5d53b 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -1875,6 +1875,7 @@ i915_gem_user_to_context_sseu(struct intel_gt *gt,
> > {
> > const struct sseu_dev_info *device = >info.sseu;
> > struct drm_i915_private *i915 = gt->i915;
> > + unsigned int dev_subslice_mask = intel_sseu_get_hsw_subslices(device,
> > 0);
> >
> > /* No zeros in any field. */
> > if (!user->slice_mask || !user->subslice_mask ||
> > @@ -1901,7 +1902,7 @@ i915_gem_user_to_context_sseu(struct intel_gt *gt,
> > if (user->slice_mask & ~device->slice_mask)
> > return -EINVAL;
> >
> > - if (user->subslice_mask & ~device->subslice_mask[0])
> > + if (user->subslice_mask & ~dev_subslice_mask)
> > return -EINVAL;
> >
> > if (user->max_eus_per_subslice > device->max_eus_per_subslice)
> > @@ -1915,7 +1916,7 @@ i915_gem_user_to_context_sseu(struct intel_gt *gt,
> > /* Part specific restrictions. */
> > if (GRAPHICS_VER(i915) == 11) {
> > unsigned int hw_s = hweight8(device->slice_mask);
> > - unsigned int hw_ss_per_s = hweight8(device->subslice_mask[0]);
> > + unsigned int hw_ss_per_s = hweight8(dev_subslice_mask);
> > unsigned int req_s = hweight8(context->slice_mask);
> > unsigned int req_ss = hweight8(context->subslice_mask);
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > index 1adbf34c3632..f0acf8518a51 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > @@ -674,8 +674,8 @@ static void engine_mask_apply_compute_fuses(struct
> > intel_gt *gt)
> > if (GRAPHICS_VER_FULL(i915) < IP_VER(12, 50))
> > return;
> >
> > - ccs_mask =
> > intel_slicemask_from_dssmask(intel_sseu_get_compute_subslices(>sseu),
> > - ss_per_ccs);
> > + ccs_mask =
> > intel_slicemask_from_xehp_dssmask(info->sseu.compute_subslice_mask,
> > +ss_per_ccs);
> > /*
> > * If all DSS in a quadrant are fused off, the corresponding CCS
> > * engine is not available for use.
> > diff --git
Re: [Intel-gfx] [RFC v3 1/3] drm/doc/rfc: VM_BIND feature design document
On 17/05/2022 21:32, Niranjana Vishwanathapura wrote: +VM_BIND/UNBIND ioctl will immediately start binding/unbinding the mapping in an +async worker. The binding and unbinding will work like a special GPU engine. +The binding and unbinding operations are serialized and will wait on specified +input fences before the operation and will signal the output fences upon the +completion of the operation. Due to serialization, completion of an operation +will also indicate that all previous operations are also complete. I guess we should avoid saying "will immediately start binding/unbinding" if there are fences involved. And the fact that it's happening in an async worker seem to imply it's not immediate. I have a question on the behavior of the bind operation when no input fence is provided. Let say I do : VM_BIND (out_fence=fence1) VM_BIND (out_fence=fence2) VM_BIND (out_fence=fence3) In what order are the fences going to be signaled? In the order of VM_BIND ioctls? Or out of order? Because you wrote "serialized I assume it's : in order One thing I didn't realize is that because we only get one "VM_BIND" engine, there is a disconnect from the Vulkan specification. In Vulkan VM_BIND operations are serialized but per engine. So you could have something like this : VM_BIND (engine=rcs0, in_fence=fence1, out_fence=fence2) VM_BIND (engine=ccs0, in_fence=fence3, out_fence=fence4) fence1 is not signaled fence3 is signaled So the second VM_BIND will proceed before the first VM_BIND. I guess we can deal with that scenario in userspace by doing the wait ourselves in one thread per engines. But then it makes the VM_BIND input fences useless. Daniel : what do you think? Should be rework this or just deal with wait fences in userspace? Sorry I noticed this late. -Lionel
Re: [Intel-gfx] [PATCH 02/10] drm/i915/uapi: add probed_cpu_visible_size
Acked-by: Nirmoy Das
On 5/25/2022 8:43 PM, Matthew Auld wrote:
Userspace wants to know the size of CPU visible portion of device
local-memory, and on small BAR devices the probed_size is no longer
enough. In Vulkan, for example, it would like to know the size in bytes
for CPU visible VkMemoryHeap. We already track the io_size for each
region, so it's just case of plumbing that through to the region query.
Testcase: igt@i915_query@query-regions-sanity-check
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: Akeem G Abodunrin
---
drivers/gpu/drm/i915/i915_query.c | 6 +++
include/uapi/drm/i915_drm.h | 74 +--
2 files changed, 47 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_query.c
b/drivers/gpu/drm/i915/i915_query.c
index 7584cec53d5d..9aa0b28aa6ee 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -496,6 +496,12 @@ static int query_memregion_info(struct drm_i915_private
*i915,
info.region.memory_class = mr->type;
info.region.memory_instance = mr->instance;
info.probed_size = mr->total;
+
+ if (mr->type == INTEL_MEMORY_LOCAL)
+ info.probed_cpu_visible_size = mr->io_size;
+ else
+ info.probed_cpu_visible_size = mr->total;
+
info.unallocated_size = mr->avail;
if (__copy_to_user(info_ptr, , sizeof(info)))
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index de49b68b4fc8..9df419a45244 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -3207,36 +3207,6 @@ struct drm_i915_gem_memory_class_instance {
* struct drm_i915_memory_region_info - Describes one region as known to the
* driver.
*
- * Note that we reserve some stuff here for potential future work. As an
example
- * we might want expose the capabilities for a given region, which could
include
- * things like if the region is CPU mappable/accessible, what are the supported
- * mapping types etc.
- *
- * Note that to extend struct drm_i915_memory_region_info and struct
- * drm_i915_query_memory_regions in the future the plan is to do the following:
- *
- * .. code-block:: C
- *
- * struct drm_i915_memory_region_info {
- * struct drm_i915_gem_memory_class_instance region;
- * union {
- * __u32 rsvd0;
- * __u32 new_thing1;
- * };
- * ...
- * union {
- * __u64 rsvd1[8];
- * struct {
- * __u64 new_thing2;
- * __u64 new_thing3;
- * ...
- * };
- * };
- * };
- *
- * With this things should remain source compatible between versions for
- * userspace, even as we add new fields.
- *
* Note this is using both struct drm_i915_query_item and struct
drm_i915_query.
* For this new query we are adding the new query id
DRM_I915_QUERY_MEMORY_REGIONS
* at _i915_query_item.query_id.
@@ -3248,14 +3218,52 @@ struct drm_i915_memory_region_info {
/** @rsvd0: MBZ */
__u32 rsvd0;
- /** @probed_size: Memory probed by the driver (-1 = unknown) */
+ /**
+* @probed_size: Memory probed by the driver (-1 = unknown)
+*
+* Note that it should not be possible to ever encounter a zero value
+* here, also note that no current region type will ever return -1 here.
+* Although for future region types, this might be a possibility. The
+* same applies to the other size fields.
+*/
__u64 probed_size;
/** @unallocated_size: Estimate of memory remaining (-1 = unknown) */
__u64 unallocated_size;
- /** @rsvd1: MBZ */
- __u64 rsvd1[8];
+ union {
+ /** @rsvd1: MBZ */
+ __u64 rsvd1[8];
+ struct {
+ /**
+* @probed_cpu_visible_size: Memory probed by the driver
+* that is CPU accessible. (-1 = unknown).
+*
+* This will be always be <= @probed_size, and the
+* remainder (if there is any) will not be CPU
+* accessible.
+*
+* On systems without small BAR, the @probed_size will
+* always equal the @probed_cpu_visible_size, since all
+* of it will be CPU accessible.
+*
+* Note this is only tracked for
+* I915_MEMORY_CLASS_DEVICE regions (for other types the
+* value here will always equal the
Re: [Intel-gfx] [PATCH 07/10] drm/i915/error: skip non-mappable pages
Reviewed-by: Nirmoy Das
On 5/25/2022 8:43 PM, Matthew Auld wrote:
Skip capturing any lmem pages that can't be copied using the CPU. This
in now only best effort on platforms that have small BAR.
Testcase: igt@gem-exec-capture@capture-invisible
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: Akeem G Abodunrin
---
drivers/gpu/drm/i915/i915_gpu_error.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 0512c66fa4f3..77df899123c2 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1116,11 +1116,15 @@ i915_vma_coredump_create(const struct intel_gt *gt,
dma_addr_t dma;
for_each_sgt_daddr(dma, iter, vma_res->bi.pages) {
+ dma_addr_t offset = dma - mem->region.start;
void __iomem *s;
- s = io_mapping_map_wc(>iomap,
- dma - mem->region.start,
- PAGE_SIZE);
+ if (offset + PAGE_SIZE > mem->io_size) {
+ ret = -EINVAL;
+ break;
+ }
+
+ s = io_mapping_map_wc(>iomap, offset, PAGE_SIZE);
ret = compress_page(compress,
(void __force *)s, dst,
true);
Re: [Intel-gfx] [PATCH 06/10] drm/i915/uapi: add NEEDS_CPU_ACCESS hint
LGTM Reviewed-by: Nirmoy Das
On 5/25/2022 8:43 PM, Matthew Auld wrote:
If set, force the allocation to be placed in the mappable portion of
I915_MEMORY_CLASS_DEVICE. One big restriction here is that system memory
(i.e I915_MEMORY_CLASS_SYSTEM) must be given as a potential placement for the
object, that way we can always spill the object into system memory if we
can't make space.
Testcase: igt@gem-create@create-ext-cpu-access-sanity-check
Testcase: igt@gem-create@create-ext-cpu-access-big
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: Akeem G Abodunrin
---
drivers/gpu/drm/i915/gem/i915_gem_create.c | 26 ++---
include/uapi/drm/i915_drm.h| 61 +++---
2 files changed, 71 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index d094cae0ddf1..33673fe7ee0a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -241,6 +241,7 @@ struct create_ext {
struct drm_i915_private *i915;
struct intel_memory_region *placements[INTEL_REGION_UNKNOWN];
unsigned int n_placements;
+ unsigned int placement_mask;
unsigned long flags;
};
@@ -337,6 +338,7 @@ static int set_placements(struct drm_i915_gem_create_ext_memory_regions *args,
for (i = 0; i < args->num_regions; i++)
ext_data->placements[i] = placements[i];
+ ext_data->placement_mask = mask;
return 0;
out_dump:
@@ -411,7 +413,7 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void
*data,
struct drm_i915_gem_object *obj;
int ret;
- if (args->flags)
+ if (args->flags & ~I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS)
return -EINVAL;
ret = i915_user_extensions(u64_to_user_ptr(args->extensions),
@@ -427,13 +429,21 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void
*data,
ext_data.n_placements = 1;
}
- /*
-* TODO: add a userspace hint to force CPU_ACCESS for the object, which
-* can override this.
-*/
- if (ext_data.n_placements > 1 ||
- ext_data.placements[0]->type != INTEL_MEMORY_SYSTEM)
- ext_data.flags |= I915_BO_ALLOC_GPU_ONLY;
+ if (args->flags & I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS) {
+ if (ext_data.n_placements == 1)
+ return -EINVAL;
+
+ /*
+* We always need to be able to spill to system memory, if we
+* can't place in the mappable part of LMEM.
+*/
+ if (!(ext_data.placement_mask & BIT(INTEL_REGION_SMEM)))
+ return -EINVAL;
+ } else {
+ if (ext_data.n_placements > 1 ||
+ ext_data.placements[0]->type != INTEL_MEMORY_SYSTEM)
+ ext_data.flags |= I915_BO_ALLOC_GPU_ONLY;
+ }
obj = __i915_gem_object_create_user_ext(i915, args->size,
ext_data.placements,
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index e30f31a440b3..5b0a10e6a1b8 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -3366,11 +3366,11 @@ struct drm_i915_query_memory_regions {
* struct drm_i915_gem_create_ext - Existing gem_create behaviour, with added
* extension support using struct i915_user_extension.
*
- * Note that in the future we want to have our buffer flags here, at least for
- * the stuff that is immutable. Previously we would have two ioctls, one to
- * create the object with gem_create, and another to apply various parameters,
- * however this creates some ambiguity for the params which are considered
- * immutable. Also in general we're phasing out the various SET/GET ioctls.
+ * Note that new buffer flags should be added here, at least for the stuff that
+ * is immutable. Previously we would have two ioctls, one to create the object
+ * with gem_create, and another to apply various parameters, however this
+ * creates some ambiguity for the params which are considered immutable. Also
in
+ * general we're phasing out the various SET/GET ioctls.
*/
struct drm_i915_gem_create_ext {
/**
@@ -3378,7 +3378,6 @@ struct drm_i915_gem_create_ext {
*
* The (page-aligned) allocated size for the object will be returned.
*
-*
* DG2 64K min page size implications:
*
* On discrete platforms, starting from DG2, we have to contend with GTT
@@ -3390,7 +3389,9 @@ struct drm_i915_gem_create_ext {
*
* Note that the returned size here will always reflect any required
* rounding up done by the kernel, i.e 4K will now become 64K on devices
-* such as DG2.
+* such as DG2. The
Re: [Intel-gfx] [RFC V3 0/2] Attach and Set vrr_enabled property
On Tue-31-05-2022 07:26 pm, Daniel Vetter wrote: On Tue, May 17, 2022 at 12:56:34PM +0530, Bhanuprakash Modem wrote: This series will add a support to set the vrr_enabled property for crtc based on the platform support and the request from userspace. And userspace can also query to get the status of "vrr_enabled". Test-with: 20220422075223.2792586-2-bhanuprakash.mo...@intel.com Bhanuprakash Modem (2): drm/vrr: Attach vrr_enabled property to the drm crtc drm/i915/vrr: Set drm crtc vrr_enabled property I'm rather confused by this patch set > - This seems to move the property from connector to crtc without any justification. For uapi that we want to have standardized (anything around kms really) that's no good, unless there's really a mandatory semantic reason pls stick to existing uapi. Thanks for the reply. No, we are not moving any property from connector to crtc. "vrr_capable" belongs to connector & "vrr_enabled" belongs to crtc. I am trying to manipulate this "vrr_enabled" property. - If the driver interface doesn't fit (maybe the helper should be on the crtc and adjust the property for all connector) pls roll that change out to all drivers. - This is uapi, so needs igt tests and userspace. For igts we should make sure they're generic so that they apply across all drivers which already support this property, and not just create new intel-only testcases. Yeah, IGT patches are already in ML: https://patchwork.freedesktop.org/series/100539/ - Finally the property is set up, but not wired through. Or at least I'm not seeing how this can even work. So no idea what exactly you're aiming for here and what kind of comments you want, but this doesn't look like it's on the right path at all. This "vrr_enabled" prop was userspace write only & driver read only prop which would be used by the userspace to request to enable the VRR on that CRTC. Now I would like to modify this prop to be used as a bidirectional property. So, that userspace can request to enable the VRR and also to get the status of VRR on that CRTC. Manasi is already replied to the Patch [1/2] in this series. - Bhanu Cheers, Daniel drivers/gpu/drm/drm_crtc.c | 26 drivers/gpu/drm/drm_mode_config.c| 2 +- drivers/gpu/drm/i915/display/intel_vrr.c | 8 include/drm/drm_crtc.h | 3 +++ 4 files changed, 38 insertions(+), 1 deletion(-) -- 2.35.1
Re: [Intel-gfx] [RFC V3 1/2] drm/vrr: Attach vrr_enabled property to the drm crtc
On Tue-31-05-2022 10:42 pm, Navare, Manasi wrote:
On Tue, May 17, 2022 at 12:56:35PM +0530, Bhanuprakash Modem wrote:
Modern display hardware is capable of supporting variable refresh rates.
This patch introduces helpers to attach and set "vrr_enabled" property
on the crtc to allow userspace to query VRR enabled status on that crtc.
Atomic drivers should attach this property to crtcs those are capable of
driving variable refresh rates using
drm_mode_crtc_attach_vrr_enabled_property().
We are not attaching the prop anymore, please remove this from the
commit message.
Thanks for the reply,
I'll update this in next rev.
The value should be updated based on driver and hardware capability
by using drm_mode_crtc_set_vrr_enabled_property().
V2: Use property flag as atomic
V3: Drop helper to attach vrr_enabled prop, since it is already
attached (Manasi)
Cc: Ville Syrjälä
Cc: Nicholas Kazlauskas
Cc: Manasi Navare
Cc: Harry Wentland
Signed-off-by: Bhanuprakash Modem
---
drivers/gpu/drm/drm_crtc.c| 26 ++
drivers/gpu/drm/drm_mode_config.c | 2 +-
include/drm/drm_crtc.h| 3 +++
3 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 26a77a735905..8bb8b4bf4199 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -239,6 +239,9 @@ struct dma_fence *drm_crtc_create_fence(struct drm_crtc
*crtc)
*Driver's default scaling filter
*Nearest Neighbor:
*Nearest Neighbor scaling filter
+ * VRR_ENABLED:
+ * Atomic property for setting the VRR state of the CRTC.
+ * To enable the VRR on CRTC, user-space must set this property to 1.
This prop was primarily a userspace Write only and driver read only
property which would be used only by the userspace to request VRR on
that CRTC,
Are we now modifying this to be used as a bidirectional property to also
indicate the status of VRR on that CRTC which will be updated by the
driver?
Precisely YES.
We need to add this accordingly and update the DRM documentation and
also get acks from other vendors since AMD and other folks mght be using
this as a write only prop.
Sure, I'll update the documentation.
@Harry/@Nicholas, can you please comment on this approach?
I would like to modify "vrr_enabled" prop to be used as a bidirectional
property. So, that userspace can request to enable the VRR and also to
get the status of VRR on that CRTC.
IGT to validate the same:
https://patchwork.freedesktop.org/series/100539/
Example:
* If userspace has accidentally set the "vrr_enabled" prop to true
without checking connector's "vrr_capable" prop, driver should reset
this "vrr_enabled" property to false.
* Userspace can read "vrr_enabled" prop anytime to get the current
status of VRR on that crtc.
- Bhanu
Manasi
*/
__printf(6, 0)
@@ -883,3 +886,26 @@ int drm_crtc_create_scaling_filter_property(struct
drm_crtc *crtc,
return 0;
}
EXPORT_SYMBOL(drm_crtc_create_scaling_filter_property);
+
+/**
+ * drm_mode_crtc_set_vrr_enabled_property - sets the vrr enabled property for
+ * a crtc.
+ * @crtc: drm CRTC
+ * @vrr_enabled: True to enable the VRR on CRTC
+ *
+ * Should be used by atomic drivers to update the VRR enabled status on a CRTC
+ */
+void drm_mode_crtc_set_vrr_enabled_property(struct drm_crtc *crtc,
+ bool vrr_enabled)
+{
+ struct drm_device *dev = crtc->dev;
+ struct drm_mode_config *config = >mode_config;
+
+ if (!config->prop_vrr_enabled)
+ return;
+
+ drm_object_property_set_value(>base,
+ config->prop_vrr_enabled,
+ vrr_enabled);
+}
+EXPORT_SYMBOL(drm_mode_crtc_set_vrr_enabled_property);
diff --git a/drivers/gpu/drm/drm_mode_config.c
b/drivers/gpu/drm/drm_mode_config.c
index 37b4b9f0e468..b7cde73d5586 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -323,7 +323,7 @@ static int drm_mode_create_standard_properties(struct
drm_device *dev)
return -ENOMEM;
dev->mode_config.prop_mode_id = prop;
- prop = drm_property_create_bool(dev, 0,
+ prop = drm_property_create_bool(dev, DRM_MODE_PROP_ATOMIC,
"VRR_ENABLED");
if (!prop)
return -ENOMEM;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index a70baea0636c..906787398f40 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1333,4 +1333,7 @@ static inline struct drm_crtc *drm_crtc_find(struct
drm_device *dev,
int drm_crtc_create_scaling_filter_property(struct drm_crtc *crtc,
unsigned int supported_filters);
+void drm_mode_crtc_set_vrr_enabled_property(struct drm_crtc *crtc,
+ bool vrr_enabled);
+
#endif /*
Re: [Intel-gfx] [RFC V3 2/2] drm/i915/vrr: Set drm crtc vrr_enabled property
On Tue-31-05-2022 10:44 pm, Navare, Manasi wrote:
On Tue, May 17, 2022 at 12:56:36PM +0530, Bhanuprakash Modem wrote:
This function sets the vrr_enabled property for crtc based
on the platform support and the request from userspace.
V2: Check for platform support before updating the prop.
V3: Don't attach vrr_enabled prop, as it is alreay attached.
Cc: Ville Syrjälä
Cc: Manasi Navare
Signed-off-by: Bhanuprakash Modem
---
drivers/gpu/drm/i915/display/intel_vrr.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c
b/drivers/gpu/drm/i915/display/intel_vrr.c
index 396f2f994fa0..7263b35550de 100644
--- a/drivers/gpu/drm/i915/display/intel_vrr.c
+++ b/drivers/gpu/drm/i915/display/intel_vrr.c
@@ -160,6 +160,10 @@ void intel_vrr_enable(struct intel_encoder *encoder,
enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
u32 trans_vrr_ctl;
+ if (HAS_VRR(dev_priv))
+ drm_mode_crtc_set_vrr_enabled_property(crtc_state->uapi.crtc,
+ crtc_state->vrr.enable);
But here if userspace has accidently set the CRTC vrr enabled prop to
true without cheking VRR capabile prop, this will be true and here the
driver will still not
reset it. If that is the purpose of adding this then we should infact
set this to false if !HAS_VRR
Yes, my intention is same as you mentioned. But this looks correct to
me, because:
1) HAS_VRR() is a check to make sure that the driver supports VRR. If
there is no VRR support on the driver, then there is no point to
set/clear this prop.
2) crtc_state->vrr.enable is true If vrr_capable is set to true, else false.
So we can interpret above check as below
enable_VRR() {
IF Driver supports VRR:
IF VRR_CAPABLE:
Set VRR_ENABLED;
ELSE:
Clear VRR_ENABLED;
ELSE:
Do nothing;
}
- Bhanu
Manasi
+
if (!crtc_state->vrr.enable)
return;
@@ -211,6 +215,10 @@ void intel_vrr_disable(const struct intel_crtc_state *old_crtc_state)
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum transcoder cpu_transcoder = old_crtc_state->cpu_transcoder;
+ if (HAS_VRR(dev_priv))
+
drm_mode_crtc_set_vrr_enabled_property(old_crtc_state->uapi.crtc,
+ false);
+
if (!old_crtc_state->vrr.enable)
return;
--
2.35.1
Re: [Intel-gfx] [RESEND] drm/i915/display: stop using BUG()
On Tue, 31 May 2022, Andrzej Hajda wrote:
> On 31.05.2022 18:25, Jani Nikula wrote:
>> Avoid bringing the entire machine down even if there's a bug that
>> shouldn't happen, but won't corrupt the system either. Log them loudly
>> and limp on.
>>
>> Signed-off-by: Jani Nikula
>
> All BUG() cases seems to be converted.
>
> Reviewed-by: Andrzej Hajda
Thanks for the reviews, pushed to drm-intel-next.
BR,
Jani.
>
> Regards
> Andrzej
>
>> ---
>> drivers/gpu/drm/i915/display/intel_ddi.c | 11 ++-
>> drivers/gpu/drm/i915/display/intel_display.c | 19 +++
>> .../drm/i915/display/intel_display_types.h| 15 +--
>> 3 files changed, 26 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
>> b/drivers/gpu/drm/i915/display/intel_ddi.c
>> index 333871cf3a2c..915e8e3e8f38 100644
>> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
>> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
>> @@ -455,6 +455,9 @@ intel_ddi_transcoder_func_reg_val_get(struct
>> intel_encoder *encoder,
>> temp |= TRANS_DDI_SELECT_PORT(port);
>>
>> switch (crtc_state->pipe_bpp) {
>> +default:
>> +MISSING_CASE(crtc_state->pipe_bpp);
>> +fallthrough;
>> case 18:
>> temp |= TRANS_DDI_BPC_6;
>> break;
>> @@ -467,8 +470,6 @@ intel_ddi_transcoder_func_reg_val_get(struct
>> intel_encoder *encoder,
>> case 36:
>> temp |= TRANS_DDI_BPC_12;
>> break;
>> -default:
>> -BUG();
>> }
>>
>> if (crtc_state->hw.adjusted_mode.flags & DRM_MODE_FLAG_PVSYNC)
>> @@ -478,6 +479,9 @@ intel_ddi_transcoder_func_reg_val_get(struct
>> intel_encoder *encoder,
>>
>> if (cpu_transcoder == TRANSCODER_EDP) {
>> switch (pipe) {
>> +default:
>> +MISSING_CASE(pipe);
>> +fallthrough;
>> case PIPE_A:
>> /* On Haswell, can only use the always-on power well for
>> * eDP when not using the panel fitter, and when not
>> @@ -494,9 +498,6 @@ intel_ddi_transcoder_func_reg_val_get(struct
>> intel_encoder *encoder,
>> case PIPE_C:
>> temp |= TRANS_DDI_EDP_INPUT_C_ONOFF;
>> break;
>> -default:
>> -BUG();
>> -break;
>> }
>> }
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
>> b/drivers/gpu/drm/i915/display/intel_display.c
>> index 806d50b302ab..e6a84d97718f 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display.c
>> +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> @@ -500,6 +500,9 @@ void vlv_wait_port_ready(struct drm_i915_private
>> *dev_priv,
>> i915_reg_t dpll_reg;
>>
>> switch (dig_port->base.port) {
>> +default:
>> +MISSING_CASE(dig_port->base.port);
>> +fallthrough;
>> case PORT_B:
>> port_mask = DPLL_PORTB_READY_MASK;
>> dpll_reg = DPLL(0);
>> @@ -513,8 +516,6 @@ void vlv_wait_port_ready(struct drm_i915_private
>> *dev_priv,
>> port_mask = DPLL_PORTD_READY_MASK;
>> dpll_reg = DPIO_PHY_STATUS;
>> break;
>> -default:
>> -BUG();
>> }
>>
>> if (intel_de_wait_for_register(dev_priv, dpll_reg,
>> @@ -3157,6 +3158,10 @@ static void i9xx_set_pipeconf(const struct
>> intel_crtc_state *crtc_state)
>> PIPECONF_DITHER_TYPE_SP;
>>
>> switch (crtc_state->pipe_bpp) {
>> +default:
>> +/* Case prevented by intel_choose_pipe_bpp_dither. */
>> +MISSING_CASE(crtc_state->pipe_bpp);
>> +fallthrough;
>> case 18:
>> pipeconf |= PIPECONF_BPC_6;
>> break;
>> @@ -3166,9 +3171,6 @@ static void i9xx_set_pipeconf(const struct
>> intel_crtc_state *crtc_state)
>> case 30:
>> pipeconf |= PIPECONF_BPC_10;
>> break;
>> -default:
>> -/* Case prevented by intel_choose_pipe_bpp_dither. */
>> -BUG();
>> }
>> }
>>
>> @@ -3464,6 +3466,10 @@ static void ilk_set_pipeconf(const struct
>> intel_crtc_state *crtc_state)
>> val = 0;
>>
>> switch (crtc_state->pipe_bpp) {
>> +default:
>> +/* Case prevented by intel_choose_pipe_bpp_dither. */
>> +MISSING_CASE(crtc_state->pipe_bpp);
>> +fallthrough;
>> case 18:
>> val |= PIPECONF_BPC_6;
>> break;
>> @@ -3476,9 +3482,6 @@ static void ilk_set_pipeconf(const struct
>> intel_crtc_state *crtc_state)
>> case 36:
>> val |= PIPECONF_BPC_12;
>> break;
>> -default:
>> -/* Case prevented by intel_choose_pipe_bpp_dither. */
Re: [Intel-gfx] [PATCH] drm/edid: ignore the CEA modes not defined in CEA-861-D
Thanks, Andrzej.
Sounds good. It is better to make drm_display_mode_from_vic_index() return a
mode with valid VIC.
So it ends up with that all probed modes have valid VICs for HDMI 1.4 and 2.0
respectively.
Regards
William
-Original Message-
From: Hajda, Andrzej
Sent: Tuesday, May 31, 2022 11:00 PM
To: Tseng, William ; intel-gfx@lists.freedesktop.org
Cc: Wayne Lin
Subject: Re: [Intel-gfx] [PATCH] drm/edid: ignore the CEA modes not defined in
CEA-861-D
On 31.05.2022 12:13, William Tseng wrote:
> This is a workaround for HDMI 1.4 sink which has a CEA mode with
> higher vic than what is defined in CEA-861-D.
>
> As an example, a HDMI 1.4 sink has the video format 2560x1080p to be
> displayed and the video format is indicated by both SVD (with vic 90
> and pictuure aspect ratio 64:27) and DTD. When connecting to such
> sink, source can't output the video format in SVD because an error is
> returned by drm_hdmi_avi_infoframe_from_display_mode(), which can't
> fill the infoframe with pictuure aspect ratio 64:27 and the vic, which
> is originally 90 and is changed to 0 by drm_mode_cea_vic().
>
> To work around it, this patch ignores such CEA modes in do_cea_modes()
> so the modes won't be processed in drm_hdmi_avi_infoframe_from_display_mode().
> And only the video format in DTD can be dispalyed.
>
> Cc: Ville Syrjälä
> Cc: Wayne Lin
> Cc: Lee Shawn C
> Signed-off-by: William Tseng
> ---
> drivers/gpu/drm/drm_edid.c | 39 +-
> 1 file changed, 26 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index bc43e1b32092..a93f68878bfd 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3982,6 +3982,19 @@ drm_display_mode_from_cea_vic(struct drm_device *dev,
> }
> EXPORT_SYMBOL(drm_display_mode_from_cea_vic);
>
> +static bool is_hdmi2_sink(const struct drm_connector *connector) {
> + /*
> + * FIXME: sil-sii8620 doesn't have a connector around when
> + * we need one, so we have to be prepared for a NULL connector.
> + */
> + if (!connector)
> + return true;
> +
> + return connector->display_info.hdmi.scdc.supported ||
> + connector->display_info.color_formats &
> DRM_COLOR_FORMAT_YCBCR420;
> +}
> +
> static int
> do_cea_modes(struct drm_connector *connector, const u8 *db, u8 len)
> {
> @@ -3993,6 +4006,19 @@ do_cea_modes(struct drm_connector *connector,
> const u8 *db, u8 len)
>
> mode = drm_display_mode_from_vic_index(connector, db, len, i);
> if (mode) {
> + u8 vic = svd_to_vic(db[i]);
> +
> + if (!drm_valid_cea_vic(vic))
> + continue;
It duplicates check from drm_display_mode_from_vic_index
> +
> + /*
> + * 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.
> + */
> + if (!is_hdmi2_sink(connector) && vic > 64)
> + continue;
So maybe adding this check to drm_display_mode_from_vic_index would be enough?
Regards
Andrzej
> +
> /*
>* YCBCR420 capability block contains a bitmap which
>* gives the index of CEA modes from CEA VDB, which @@
> -5846,19
> +5872,6 @@ void drm_set_preferred_mode(struct drm_connector *connector,
> }
> EXPORT_SYMBOL(drm_set_preferred_mode);
>
> -static bool is_hdmi2_sink(const struct drm_connector *connector) -{
> - /*
> - * FIXME: sil-sii8620 doesn't have a connector around when
> - * we need one, so we have to be prepared for a NULL connector.
> - */
> - if (!connector)
> - return true;
> -
> - return connector->display_info.hdmi.scdc.supported ||
> - connector->display_info.color_formats &
> DRM_COLOR_FORMAT_YCBCR420;
> -}
> -
> static u8 drm_mode_hdmi_vic(const struct drm_connector *connector,
> const struct drm_display_mode *mode)
> {
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display: stop using BUG() (rev4)
== Series Details == Series: drm/i915/display: stop using BUG() (rev4) URL : https://patchwork.freedesktop.org/series/104559/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11715_full -> Patchwork_104559v4_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_104559v4_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_104559v4_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (13 -> 13) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_104559v4_full: ### IGT changes ### Possible regressions * igt@i915_pm_rpm@gem-mmap-type@gtt-smem0: - shard-iclb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11715/shard-iclb3/igt@i915_pm_rpm@gem-mmap-t...@gtt-smem0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104559v4/shard-iclb4/igt@i915_pm_rpm@gem-mmap-t...@gtt-smem0.html * igt@i915_selftest@live@memory_region: - shard-skl: [PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11715/shard-skl4/igt@i915_selftest@live@memory_region.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104559v4/shard-skl1/igt@i915_selftest@live@memory_region.html * igt@kms_plane_scaling@planes-downscale-factor-0-5@pipe-a-edp-1: - shard-iclb: [PASS][5] -> [SKIP][6] +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11715/shard-iclb6/igt@kms_plane_scaling@planes-downscale-factor-...@pipe-a-edp-1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104559v4/shard-iclb2/igt@kms_plane_scaling@planes-downscale-factor-...@pipe-a-edp-1.html Known issues Here are the changes found in Patchwork_104559v4_full that come from known issues: ### CI changes ### Possible fixes * boot: - shard-glk: ([PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27], [FAIL][28], [PASS][29], [PASS][30], [PASS][31]) ([i915#4392]) -> ([PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50], [PASS][51], [PASS][52], [PASS][53], [PASS][54], [PASS][55], [PASS][56]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11715/shard-glk1/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11715/shard-glk1/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11715/shard-glk1/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11715/shard-glk2/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11715/shard-glk2/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11715/shard-glk2/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11715/shard-glk3/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11715/shard-glk3/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11715/shard-glk3/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11715/shard-glk4/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11715/shard-glk4/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11715/shard-glk5/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11715/shard-glk5/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11715/shard-glk5/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11715/shard-glk6/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11715/shard-glk6/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11715/shard-glk6/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11715/shard-glk7/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11715/shard-glk7/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11715/shard-glk7/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11715/shard-glk8/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11715/shard-glk8/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11715/shard-glk8/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11715/shard-glk9/boot.html [31]:
Re: [Intel-gfx] [RFC v3 3/3] drm/doc/rfc: VM_BIND uapi definition
On Wed, 1 Jun 2022 at 11:03, Dave Airlie wrote:
>
> On Tue, 24 May 2022 at 05:20, Niranjana Vishwanathapura
> wrote:
> >
> > On Thu, May 19, 2022 at 04:07:30PM -0700, Zanoni, Paulo R wrote:
> > >On Tue, 2022-05-17 at 11:32 -0700, Niranjana Vishwanathapura wrote:
> > >> VM_BIND and related uapi definitions
> > >>
> > >> v2: Ensure proper kernel-doc formatting with cross references.
> > >> Also add new uapi and documentation as per review comments
> > >> from Daniel.
> > >>
> > >> Signed-off-by: Niranjana Vishwanathapura
> > >>
> > >> ---
> > >> Documentation/gpu/rfc/i915_vm_bind.h | 399 +++
> > >> 1 file changed, 399 insertions(+)
> > >> create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h
> > >>
> > >> diff --git a/Documentation/gpu/rfc/i915_vm_bind.h
> > >> b/Documentation/gpu/rfc/i915_vm_bind.h
> > >> new file mode 100644
> > >> index ..589c0a009107
> > >> --- /dev/null
> > >> +++ b/Documentation/gpu/rfc/i915_vm_bind.h
> > >> @@ -0,0 +1,399 @@
> > >> +/* SPDX-License-Identifier: MIT */
> > >> +/*
> > >> + * Copyright © 2022 Intel Corporation
> > >> + */
> > >> +
> > >> +/**
> > >> + * DOC: I915_PARAM_HAS_VM_BIND
> > >> + *
> > >> + * VM_BIND feature availability.
> > >> + * See typedef drm_i915_getparam_t param.
> > >> + */
> > >> +#define I915_PARAM_HAS_VM_BIND 57
> > >> +
> > >> +/**
> > >> + * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
> > >> + *
> > >> + * Flag to opt-in for VM_BIND mode of binding during VM creation.
> > >> + * See struct drm_i915_gem_vm_control flags.
> > >> + *
> > >> + * A VM in VM_BIND mode will not support the older execbuff mode of
> > >> binding.
> > >> + * In VM_BIND mode, execbuff ioctl will not accept any execlist (ie.,
> > >> the
> > >> + * _i915_gem_execbuffer2.buffer_count must be 0).
> > >> + * Also, _i915_gem_execbuffer2.batch_start_offset and
> > >> + * _i915_gem_execbuffer2.batch_len must be 0.
> > >> + * DRM_I915_GEM_EXECBUFFER_EXT_BATCH_ADDRESSES extension must be
> > >> provided
> > >> + * to pass in the batch buffer addresses.
> > >> + *
> > >> + * Additionally, I915_EXEC_NO_RELOC, I915_EXEC_HANDLE_LUT and
> > >> + * I915_EXEC_BATCH_FIRST of _i915_gem_execbuffer2.flags must be 0
> > >> + * (not used) in VM_BIND mode. I915_EXEC_USE_EXTENSIONS flag must
> > >> always be
> > >> + * set (See struct drm_i915_gem_execbuffer_ext_batch_addresses).
> > >> + * The buffers_ptr, buffer_count, batch_start_offset and batch_len
> > >> fields
> > >> + * of struct drm_i915_gem_execbuffer2 are also not used and must be 0.
> > >> + */
> > >
> > >From that description, it seems we have:
> > >
> > >struct drm_i915_gem_execbuffer2 {
> > >__u64 buffers_ptr; -> must be 0 (new)
> > >__u32 buffer_count; -> must be 0 (new)
> > >__u32 batch_start_offset; -> must be 0 (new)
> > >__u32 batch_len;-> must be 0 (new)
> > >__u32 DR1; -> must be 0 (old)
> > >__u32 DR4; -> must be 0 (old)
> > >__u32 num_cliprects; (fences) -> must be 0 since using extensions
> > >__u64 cliprects_ptr; (fences, extensions) -> contains an actual
> > > pointer!
> > >__u64 flags;-> some flags must be 0 (new)
> > >__u64 rsvd1; (context info) -> repurposed field (old)
> > >__u64 rsvd2;-> unused
> > >};
> > >
> > >Based on that, why can't we just get drm_i915_gem_execbuffer3 instead
> > >of adding even more complexity to an already abused interface? While
> > >the Vulkan-like extension thing is really nice, I don't think what
> > >we're doing here is extending the ioctl usage, we're completely
> > >changing how the base struct should be interpreted based on how the VM
> > >was created (which is an entirely different ioctl).
> > >
> > >From Rusty Russel's API Design grading, drm_i915_gem_execbuffer2 is
> > >already at -6 without these changes. I think after vm_bind we'll need
> > >to create a -11 entry just to deal with this ioctl.
> > >
> >
> > The only change here is removing the execlist support for VM_BIND
> > mode (other than natual extensions).
> > Adding a new execbuffer3 was considered, but I think we need to be careful
> > with that as that goes beyond the VM_BIND support, including any future
> > requirements (as we don't want an execbuffer4 after VM_BIND).
>
> Why not? it's not like adding extensions here is really that different
> than adding new ioctls.
>
> I definitely think this deserves an execbuffer3 without even
> considering future requirements. Just to burn down the old
> requirements and pointless fields.
>
> Make execbuffer3 be vm bind only, no relocs, no legacy bits, leave the
> older sw on execbuf2 for ever.
I guess another point in favour of execbuf3 would be that it's less
midlayer. If we share the entry point then there's quite a few vfuncs
needed to cleanly split out the vm_bind paths from the legacy
Re: [Intel-gfx] [RFC v3 3/3] drm/doc/rfc: VM_BIND uapi definition
On Tue, 24 May 2022 at 05:20, Niranjana Vishwanathapura
wrote:
>
> On Thu, May 19, 2022 at 04:07:30PM -0700, Zanoni, Paulo R wrote:
> >On Tue, 2022-05-17 at 11:32 -0700, Niranjana Vishwanathapura wrote:
> >> VM_BIND and related uapi definitions
> >>
> >> v2: Ensure proper kernel-doc formatting with cross references.
> >> Also add new uapi and documentation as per review comments
> >> from Daniel.
> >>
> >> Signed-off-by: Niranjana Vishwanathapura
> >>
> >> ---
> >> Documentation/gpu/rfc/i915_vm_bind.h | 399 +++
> >> 1 file changed, 399 insertions(+)
> >> create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h
> >>
> >> diff --git a/Documentation/gpu/rfc/i915_vm_bind.h
> >> b/Documentation/gpu/rfc/i915_vm_bind.h
> >> new file mode 100644
> >> index ..589c0a009107
> >> --- /dev/null
> >> +++ b/Documentation/gpu/rfc/i915_vm_bind.h
> >> @@ -0,0 +1,399 @@
> >> +/* SPDX-License-Identifier: MIT */
> >> +/*
> >> + * Copyright © 2022 Intel Corporation
> >> + */
> >> +
> >> +/**
> >> + * DOC: I915_PARAM_HAS_VM_BIND
> >> + *
> >> + * VM_BIND feature availability.
> >> + * See typedef drm_i915_getparam_t param.
> >> + */
> >> +#define I915_PARAM_HAS_VM_BIND 57
> >> +
> >> +/**
> >> + * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
> >> + *
> >> + * Flag to opt-in for VM_BIND mode of binding during VM creation.
> >> + * See struct drm_i915_gem_vm_control flags.
> >> + *
> >> + * A VM in VM_BIND mode will not support the older execbuff mode of
> >> binding.
> >> + * In VM_BIND mode, execbuff ioctl will not accept any execlist (ie., the
> >> + * _i915_gem_execbuffer2.buffer_count must be 0).
> >> + * Also, _i915_gem_execbuffer2.batch_start_offset and
> >> + * _i915_gem_execbuffer2.batch_len must be 0.
> >> + * DRM_I915_GEM_EXECBUFFER_EXT_BATCH_ADDRESSES extension must be provided
> >> + * to pass in the batch buffer addresses.
> >> + *
> >> + * Additionally, I915_EXEC_NO_RELOC, I915_EXEC_HANDLE_LUT and
> >> + * I915_EXEC_BATCH_FIRST of _i915_gem_execbuffer2.flags must be 0
> >> + * (not used) in VM_BIND mode. I915_EXEC_USE_EXTENSIONS flag must always
> >> be
> >> + * set (See struct drm_i915_gem_execbuffer_ext_batch_addresses).
> >> + * The buffers_ptr, buffer_count, batch_start_offset and batch_len fields
> >> + * of struct drm_i915_gem_execbuffer2 are also not used and must be 0.
> >> + */
> >
> >From that description, it seems we have:
> >
> >struct drm_i915_gem_execbuffer2 {
> >__u64 buffers_ptr; -> must be 0 (new)
> >__u32 buffer_count; -> must be 0 (new)
> >__u32 batch_start_offset; -> must be 0 (new)
> >__u32 batch_len;-> must be 0 (new)
> >__u32 DR1; -> must be 0 (old)
> >__u32 DR4; -> must be 0 (old)
> >__u32 num_cliprects; (fences) -> must be 0 since using extensions
> >__u64 cliprects_ptr; (fences, extensions) -> contains an actual
> > pointer!
> >__u64 flags;-> some flags must be 0 (new)
> >__u64 rsvd1; (context info) -> repurposed field (old)
> >__u64 rsvd2;-> unused
> >};
> >
> >Based on that, why can't we just get drm_i915_gem_execbuffer3 instead
> >of adding even more complexity to an already abused interface? While
> >the Vulkan-like extension thing is really nice, I don't think what
> >we're doing here is extending the ioctl usage, we're completely
> >changing how the base struct should be interpreted based on how the VM
> >was created (which is an entirely different ioctl).
> >
> >From Rusty Russel's API Design grading, drm_i915_gem_execbuffer2 is
> >already at -6 without these changes. I think after vm_bind we'll need
> >to create a -11 entry just to deal with this ioctl.
> >
>
> The only change here is removing the execlist support for VM_BIND
> mode (other than natual extensions).
> Adding a new execbuffer3 was considered, but I think we need to be careful
> with that as that goes beyond the VM_BIND support, including any future
> requirements (as we don't want an execbuffer4 after VM_BIND).
Why not? it's not like adding extensions here is really that different
than adding new ioctls.
I definitely think this deserves an execbuffer3 without even
considering future requirements. Just to burn down the old
requirements and pointless fields.
Make execbuffer3 be vm bind only, no relocs, no legacy bits, leave the
older sw on execbuf2 for ever.
Dave.
[Intel-gfx] ✗ Fi.CI.BUILD: failure for i915 writeback enablement
== Series Details == Series: i915 writeback enablement URL : https://patchwork.freedesktop.org/series/104591/ State : failure == Summary == Error: make failed CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh DESCEND objtool CHK include/generated/compile.h CC [M] drivers/gpu/drm/i915/display/intel_wd.o drivers/gpu/drm/i915/display/intel_wd.c:66:6: error: no previous prototype for ‘print_connectors’ [-Werror=missing-prototypes] void print_connectors(struct drm_i915_private *dev_priv) ^~~~ drivers/gpu/drm/i915/display/intel_wd.c:414:6: error: no previous prototype for ‘intel_wd_writeback_complete’ [-Werror=missing-prototypes] void intel_wd_writeback_complete(struct intel_wd *intel_wd, ^~~ drivers/gpu/drm/i915/display/intel_wd.c:422:5: error: no previous prototype for ‘intel_wd_setup_transcoder’ [-Werror=missing-prototypes] int intel_wd_setup_transcoder(struct intel_wd *intel_wd, ^ drivers/gpu/drm/i915/display/intel_wd.c:587:5: error: no previous prototype for ‘intel_wd_capture’ [-Werror=missing-prototypes] int intel_wd_capture(struct intel_wd *intel_wd, ^~~~ cc1: all warnings being treated as errors scripts/Makefile.build:288: recipe for target 'drivers/gpu/drm/i915/display/intel_wd.o' failed make[4]: *** [drivers/gpu/drm/i915/display/intel_wd.o] Error 1 scripts/Makefile.build:550: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:550: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:550: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1834: recipe for target 'drivers' failed make: *** [drivers] Error 2
Re: [Intel-gfx] [PATCH v10 0/4] Separate panel orientation property creating and value setting
On Tue, May 31, 2022 at 6:56 PM Hans de Goede wrote: > > Hi, > > On 5/30/22 13:34, Hsin-Yi Wang wrote: > > On Mon, May 30, 2022 at 4:53 PM Hans de Goede wrote: > >> > >> Hi, > >> > >> On 5/30/22 10:19, Hsin-Yi Wang wrote: > >>> Some drivers, eg. mtk_drm and msm_drm, rely on the panel to set the > >>> orientation. Panel calls drm_connector_set_panel_orientation() to create > >>> orientation property and sets the value. However, connector properties > >>> can't be created after drm_dev_register() is called. The goal is to > >>> separate the orientation property creation, so drm drivers can create it > >>> earlier before drm_dev_register(). > >> > >> Sorry for jumping in pretty late in the discussion (based on the v10 > >> I seem to have missed this before). > >> > >> This sounds to me like the real issue here is that drm_dev_register() > >> is getting called too early? > >> > > Right. > > > >> To me it seems sensible to delay calling drm_dev_register() and > >> thus allowing userspace to start detecting available displays + > >> features until after the panel has been probed. > >> > > > > Most panels set this value very late, in .get_modes callback (since it > > is when the connector is known), though the value was known during > > panel probe. > > Hmm I would expect the main drm/kms driver to register the drm_connector > object after probing the panel, right ? > > So maybe this is a problem with the panel API? How about adding > separate callback to the panel API to get the orientation, which the > main drm/kms driver can then call before registering the connector ? > > And then have the main drm/kms driver call > drm_connector_set_panel_orientation() with the returned orientation > on the connecter before registering it. > > The new get_orientation callback for the panel should of course > be optional (IOW amy be NULL), so we probably want a small > helper for drivers using panel (sub)drivers to take care of > the process of getting the panel orientation from the panel > (if supported) and then setting it on the connector. > Hi Hans, Thanks for the suggestion. I've sent a new version for this: https://patchwork.kernel.org/project/dri-devel/patch/20220601081823.1038797-2-hsi...@chromium.org/ Panel can implement the optional callback to return the orientation property, while drm/kms driver will call a drm API to get the value then they can call drm_connector_set_panel_orientation(). Panel .get_mode will still call drm_connector_set_panel_orientation() but now it will be a no-op as the value was set by drm/kms driver previously. This is similar to the small patch below: https://patchwork.kernel.org/project/linux-mediatek/patch/20220530113033.124072-1-hsi...@chromium.org/ But it's now using the panel API. > > > I think we can also let drm check if they have remote panel nodes: If > > there is a panel and the panel sets the orientation, let the drm read > > this value and set the property. Does this workflow sound reasonable? > > > > The corresponding patch to implement this: > > https://patchwork.kernel.org/project/linux-mediatek/patch/20220530113033.124072-1-hsi...@chromium.org/ > > That is a suprisingly small patch (which is good). I guess that > my suggestion to add a new panel driver callback to get > the orientation would be a bit bigget then this. Still I think > that that would be a bit cleaner, as it would also solve this > for cases where the orientation comes from the panel itself > (through say some EDID extenstion) rather then from devicetree. > > Still I think either way should be acceptable upstream. > > Opinions from other drm devs on the above are very much welcome! > > Your small patch nicely avoids the probe ordering problem, > so it is much better then this patch series. > > Regards, > > Hans > > > > > > > Thanks > > > >> I see a devicetree patch in this series, so I guess that the panel > >> is described in devicetree. Especially in the case of devicetree > >> I would expect the kernel to have enough info to do the right > >> thing and make sure the panel is probed before calling > >> drm_dev_register() ? > >> > >> Regards, > >> > >> Hans > >> > >> > >> > >> > >>> > >>> After this series, drm_connector_set_panel_orientation() works like > >>> before. It won't affect existing callers of > >>> drm_connector_set_panel_orientation(). The only difference is that > >>> some drm drivers can call drm_connector_init_panel_orientation_property() > >>> earlier. > >>> > >>> Hsin-Yi Wang (4): > >>> gpu: drm: separate panel orientation property creating and value > >>> setting > >>> drm/mediatek: init panel orientation property > >>> drm/msm: init panel orientation property > >>> arm64: dts: mt8183: Add panel rotation > >>> > >>> .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 1 + > >>> drivers/gpu/drm/drm_connector.c | 58 ++- > >>> drivers/gpu/drm/mediatek/mtk_dsi.c| 7 +++ > >>> drivers/gpu/drm/msm/dsi/dsi_manager.c | 4 ++ >
[Intel-gfx] [RFC PATCH 2/2] drm/i915: Enabling WD Transcoder
Adding support for writeback transcoder to start capturing frames using
interrupt mechanism.
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/display/intel_acpi.c | 1 +
drivers/gpu/drm/i915/display/intel_display.c | 369 +++--
drivers/gpu/drm/i915/display/intel_display.h | 17 +
.../drm/i915/display/intel_display_types.h| 29 +
drivers/gpu/drm/i915/display/intel_dpll.c | 6 +
drivers/gpu/drm/i915/display/intel_opregion.c | 3 +
.../gpu/drm/i915/display/intel_wb_connector.h | 20 +
drivers/gpu/drm/i915/display/intel_wd.c | 748 ++
drivers/gpu/drm/i915/display/intel_wd.h | 84 ++
drivers/gpu/drm/i915/i915_drv.h | 4 +
drivers/gpu/drm/i915/i915_irq.c | 8 +-
drivers/gpu/drm/i915/i915_pci.c | 7 +-
drivers/gpu/drm/i915/i915_reg.h | 137
14 files changed, 1386 insertions(+), 48 deletions(-)
create mode 100644 drivers/gpu/drm/i915/display/intel_wb_connector.h
create mode 100644 drivers/gpu/drm/i915/display/intel_wd.c
create mode 100644 drivers/gpu/drm/i915/display/intel_wd.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index d2b18f03a33c..8f1ef2bbb851 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -298,6 +298,7 @@ i915-y += \
display/intel_tv.o \
display/intel_vdsc.o \
display/intel_vrr.o \
+ display/intel_wd.o \
display/vlv_dsi.o \
display/vlv_dsi_pll.o
diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c
b/drivers/gpu/drm/i915/display/intel_acpi.c
index e78430001f07..ae08db164f73 100644
--- a/drivers/gpu/drm/i915/display/intel_acpi.c
+++ b/drivers/gpu/drm/i915/display/intel_acpi.c
@@ -247,6 +247,7 @@ static u32 acpi_display_type(struct intel_connector
*connector)
case DRM_MODE_CONNECTOR_LVDS:
case DRM_MODE_CONNECTOR_eDP:
case DRM_MODE_CONNECTOR_DSI:
+ case DRM_MODE_CONNECTOR_WRITEBACK:
display_type = ACPI_DISPLAY_TYPE_INTERNAL_DIGITAL;
break;
case DRM_MODE_CONNECTOR_Unknown:
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index e71b69425309..bebc8caa9596 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -113,6 +113,7 @@
#include "intel_sprite.h"
#include "intel_tc.h"
#include "intel_vga.h"
+#include "intel_wd.h"
#include "i9xx_plane.h"
#include "skl_scaler.h"
#include "skl_universal_plane.h"
@@ -1551,6 +1552,141 @@ static void intel_encoders_update_complete(struct
intel_atomic_state *state)
}
}
+static void intel_queue_writeback_job(struct intel_atomic_state *state,
+ struct intel_crtc *intel_crtc, struct intel_crtc_state
*crtc_state)
+{
+ struct drm_connector_state *new_conn_state;
+ struct drm_connector *connector;
+ struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
+ struct intel_wd *intel_wd;
+ //struct intel_encoder *encoder;
+ int i;
+
+ //for_each_intel_encoder_with_wd(_priv->drm, encoder) {
+ // intel_wd = enc_to_intel_wd(encoder);
+
+ // if (intel_wd->wd_crtc != intel_crtc)
+ // return;
+
+ //}
+
+ for_each_new_connector_in_state(>base, connector, new_conn_state,
+ i) {
+ intel_wd =
conn_to_intel_wd(drm_connector_to_writeback(connector));
+
+ if (intel_wd->wd_crtc != intel_crtc)
+ return;
+
+ if (!new_conn_state->writeback_job)
+ continue;
+
+ drm_writeback_queue_job(_wd->wb_conn, new_conn_state);
+ drm_dbg_kms(_priv->drm, "queueing writeback job\n");
+ }
+}
+
+static void intel_wd_encoder_funcs(struct intel_atomic_state *state,
+ struct intel_crtc *intel_crtc, struct intel_crtc_state
*crtc_state)
+{
+ struct drm_connector_state *new_conn_state;
+ struct drm_connector *connector;
+ struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
+ struct intel_wd *intel_wd;
+ //struct intel_encoder *encoder;
+ int i;
+
+ //for_each_intel_encoder_with_wd(_priv->drm, encoder) {
+ // intel_wd = enc_to_intel_wd(encoder);
+
+ // if (intel_wd->wd_crtc != intel_crtc)
+ // return;
+
+ //}
+
+ for_each_new_connector_in_state(>base, connector, new_conn_state,
+ i) {
+ //struct intel_connector *intel_connector;
+ intel_wd =
conn_to_intel_wd(drm_connector_to_writeback(connector));
+ if (intel_wd->wd_crtc != intel_crtc)
+ return;
+ //intel_connector = to_intel_connector(connector);
+
[Intel-gfx] [RFC PATCH 1/2] drm/i915: Define WD trancoder for i915
Adding WD Types, WD transcoder to enum list and WD Transcoder offsets
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i915/display/intel_display.h | 6 ++
drivers/gpu/drm/i915/display/intel_display_types.h | 1 +
drivers/gpu/drm/i915/i915_reg.h| 2 ++
3 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index 187910d94ec6..62dc26b3bf76 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -119,6 +119,8 @@ enum transcoder {
TRANSCODER_DSI_1,
TRANSCODER_DSI_A = TRANSCODER_DSI_0,/* legacy DSI */
TRANSCODER_DSI_C = TRANSCODER_DSI_1,/* legacy DSI */
+ TRANSCODER_WD_0,
+ TRANSCODER_WD_1,
I915_MAX_TRANSCODERS
};
@@ -140,6 +142,10 @@ static inline const char *transcoder_name(enum transcoder
transcoder)
return "DSI A";
case TRANSCODER_DSI_C:
return "DSI C";
+ case TRANSCODER_WD_0:
+ return "WD 0";
+ case TRANSCODER_WD_1:
+ return "WD 1";
default:
return "";
}
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index a27d66fd4383..eeadf5c160ac 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -78,6 +78,7 @@ enum intel_output_type {
INTEL_OUTPUT_DSI = 9,
INTEL_OUTPUT_DDI = 10,
INTEL_OUTPUT_DP_MST = 11,
+ INTEL_OUTPUT_WD = 12,
};
enum hdmi_force_audio {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0a5064e32284..cfd0a0c13703 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2053,6 +2053,8 @@
#define TRANSCODER_EDP_OFFSET 0x6f000
#define TRANSCODER_DSI0_OFFSET 0x6b000
#define TRANSCODER_DSI1_OFFSET 0x6b800
+#define TRANSCODER_WD0_OFFSET 0x6e000
+#define TRANSCODER_WD1_OFFSET 0x6e800
#define HTOTAL(trans) _MMIO_TRANS2(trans, _HTOTAL_A)
#define HBLANK(trans) _MMIO_TRANS2(trans, _HBLANK_A)
--
2.35.1
[Intel-gfx] [RFC PATCH 0/2] i915 writeback enablement
With this we try to enable writeback feature keeping with the drm_core drm_writeback framework but to do this we have to create a drm_encoder and drm_connector which is not present in intel_connector and intel_encoder which causes all our iterators to bug out as they assume any drm_encoder and drm_connector will naturally be embedded in the intel_ counterpart structures but this cannot be acheived from drm_writeback_connector as the drm_encoder and drm_connector fields in the structure are pointers which does not allow us to embed them in our intel_ structures.I have tried to change some iterators and show what further changes may look like but this will happen any and every place for_each_intel_encoder or for_each_intel_connector_ is going to be used.I would like suggestions on if moving forward with this approach would be useful or if the private i915 framework mentioned below sounds more practical. We previously tried to change the drm_connector and drm_encoder fields into pointer in the drm_writeback_connector structure but faced a huge backlash from community. Other than this approach we have another solution which won't be as much of a work and will require minimal changes is where we take the whole drm_writeback framework that is being used pull it into i915 making it private and change the encoder and connector fields to pointers. The approach has been floated in below series [1] https://patchwork.freedesktop.org/series/103417/ Suraj Kandpal (2): drm/i915: Define WD trancoder for i915 drm/i915: Enabling WD Transcoder drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/display/intel_acpi.c | 1 + drivers/gpu/drm/i915/display/intel_display.c | 369 +++-- drivers/gpu/drm/i915/display/intel_display.h | 23 + .../drm/i915/display/intel_display_types.h| 30 + drivers/gpu/drm/i915/display/intel_dpll.c | 6 + drivers/gpu/drm/i915/display/intel_opregion.c | 3 + .../gpu/drm/i915/display/intel_wb_connector.h | 20 + drivers/gpu/drm/i915/display/intel_wd.c | 748 ++ drivers/gpu/drm/i915/display/intel_wd.h | 84 ++ drivers/gpu/drm/i915/i915_drv.h | 4 + drivers/gpu/drm/i915/i915_irq.c | 8 +- drivers/gpu/drm/i915/i915_pci.c | 7 +- drivers/gpu/drm/i915/i915_reg.h | 139 14 files changed, 1395 insertions(+), 48 deletions(-) create mode 100644 drivers/gpu/drm/i915/display/intel_wb_connector.h create mode 100644 drivers/gpu/drm/i915/display/intel_wd.c create mode 100644 drivers/gpu/drm/i915/display/intel_wd.h -- 2.35.1
Re: [Intel-gfx] [PATCH v5 5/6] drm/i915/sseu: Disassociate internal subslice mask representation from uapi
On 23.05.2022 13:45, Matt Roper wrote:
> As with EU masks, it's easier to store subslice/DSS masks internally in
> a format that's more natural for the driver to work with, and then only
> covert into the u8[] uapi form when the query ioctl is invoked. Since
> the hardware design changed significantly with Xe_HP, we'll use a union
> to choose between the old "hsw-style" subslice masks or the newer xehp
> mask. HSW-style masks will be stored in an array of u8's, indexed by
> slice (there's never more than 6 subslices per slice on older
> platforms). For Xe_HP and beyond where slices no longer exist, we only
> need a single bitmask. However we already know that this mask is
> eventually going to grow too large for a simple u64 to hold, so we'll
> represent it in a manner that can be operated on by the utilities in
> linux/bitmap.h.
>
> v2:
> - Fix typo: BIT(s) -> BIT(ss) in gen9_sseu_device_status()
>
> v3:
> - Eliminate sseu->ss_stride and just calculate the stride while
>specifically handling uapi. (Tvrtko)
> - Use BITMAP_BITS() macro to refer to size of masks rather than
>passing I915_MAX_SS_FUSE_BITS directly. (Tvrtko)
> - Report compute/geometry DSS masks separately when dumping Xe_HP SSEU
>info. (Tvrtko)
> - Restore dropped range checks to intel_sseu_has_subslice(). (Tvrtko)
>
> v4:
> - Make the bitmap size macro check the size of the .xehp field rather
>than the containing union. (Tvrtko)
> - Don't add GEM_BUG_ON() intel_sseu_has_subslice()'s check for whether
>slice or subslice ID exceed sseu->max_[sub]slices; various loops
>in the driver are expected to exceed these, so we should just
>silently return 'false.'
>
> Cc: Tvrtko Ursulin
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 5 +-
> drivers/gpu/drm/i915/gt/intel_engine_cs.c| 4 +-
> drivers/gpu/drm/i915/gt/intel_gt.c | 12 +-
> drivers/gpu/drm/i915/gt/intel_sseu.c | 261 +++
> drivers/gpu/drm/i915/gt/intel_sseu.h | 76 --
> drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c | 30 +--
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 24 +-
> drivers/gpu/drm/i915/i915_getparam.c | 3 +-
> drivers/gpu/drm/i915/i915_query.c| 13 +-
> 9 files changed, 241 insertions(+), 187 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index ab4c5ab28e4d..a3bb73f5d53b 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -1875,6 +1875,7 @@ i915_gem_user_to_context_sseu(struct intel_gt *gt,
> {
> const struct sseu_dev_info *device = >info.sseu;
> struct drm_i915_private *i915 = gt->i915;
> + unsigned int dev_subslice_mask = intel_sseu_get_hsw_subslices(device,
> 0);
>
> /* No zeros in any field. */
> if (!user->slice_mask || !user->subslice_mask ||
> @@ -1901,7 +1902,7 @@ i915_gem_user_to_context_sseu(struct intel_gt *gt,
> if (user->slice_mask & ~device->slice_mask)
> return -EINVAL;
>
> - if (user->subslice_mask & ~device->subslice_mask[0])
> + if (user->subslice_mask & ~dev_subslice_mask)
> return -EINVAL;
>
> if (user->max_eus_per_subslice > device->max_eus_per_subslice)
> @@ -1915,7 +1916,7 @@ i915_gem_user_to_context_sseu(struct intel_gt *gt,
> /* Part specific restrictions. */
> if (GRAPHICS_VER(i915) == 11) {
> unsigned int hw_s = hweight8(device->slice_mask);
> - unsigned int hw_ss_per_s = hweight8(device->subslice_mask[0]);
> + unsigned int hw_ss_per_s = hweight8(dev_subslice_mask);
> unsigned int req_s = hweight8(context->slice_mask);
> unsigned int req_ss = hweight8(context->subslice_mask);
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 1adbf34c3632..f0acf8518a51 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -674,8 +674,8 @@ static void engine_mask_apply_compute_fuses(struct
> intel_gt *gt)
> if (GRAPHICS_VER_FULL(i915) < IP_VER(12, 50))
> return;
>
> - ccs_mask =
> intel_slicemask_from_dssmask(intel_sseu_get_compute_subslices(>sseu),
> - ss_per_ccs);
> + ccs_mask =
> intel_slicemask_from_xehp_dssmask(info->sseu.compute_subslice_mask,
> + ss_per_ccs);
> /*
>* If all DSS in a quadrant are fused off, the corresponding CCS
>* engine is not available for use.
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> b/drivers/gpu/drm/i915/gt/intel_gt.c
> index 034182f85501..2921f510642f 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -133,13 +133,6 @@ static const struct
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: stop using BUG() (rev4)
== Series Details == Series: drm/i915/display: stop using BUG() (rev4) URL : https://patchwork.freedesktop.org/series/104559/ State : success == Summary == CI Bug Log - changes from CI_DRM_11715 -> Patchwork_104559v4 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104559v4/index.html Participating hosts (45 -> 43) -- Additional (2): fi-tgl-u2 bat-dg1-5 Missing(4): fi-kbl-soraka bat-dg2-8 bat-adlm-1 fi-icl-u2 Known issues Here are the changes found in Patchwork_104559v4 that come from known issues: ### IGT changes ### Issues hit * igt@fbdev@nullptr: - bat-dg1-5: NOTRUN -> [SKIP][1] ([i915#2582]) +4 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104559v4/bat-dg1-5/igt@fb...@nullptr.html * igt@gem_huc_copy@huc-copy: - fi-tgl-u2: NOTRUN -> [SKIP][2] ([i915#2190]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104559v4/fi-tgl-u2/igt@gem_huc_c...@huc-copy.html * igt@gem_mmap@basic: - bat-dg1-5: NOTRUN -> [SKIP][3] ([i915#4083]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104559v4/bat-dg1-5/igt@gem_m...@basic.html * igt@gem_tiled_blits@basic: - bat-dg1-5: NOTRUN -> [SKIP][4] ([i915#4077]) +2 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104559v4/bat-dg1-5/igt@gem_tiled_bl...@basic.html * igt@gem_tiled_pread_basic: - bat-dg1-5: NOTRUN -> [SKIP][5] ([i915#4079]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104559v4/bat-dg1-5/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - bat-dg1-5: NOTRUN -> [SKIP][6] ([i915#1155]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104559v4/bat-dg1-5/igt@i915_pm_backli...@basic-brightness.html * igt@i915_selftest@live@hangcheck: - bat-dg1-5: NOTRUN -> [DMESG-FAIL][7] ([i915#4494] / [i915#4957]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104559v4/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html - fi-snb-2600:[PASS][8] -> [INCOMPLETE][9] ([i915#3921]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11715/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104559v4/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html * igt@i915_suspend@basic-s2idle-without-i915: - bat-dg1-6: NOTRUN -> [INCOMPLETE][10] ([i915#6011]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104559v4/bat-dg1-6/igt@i915_susp...@basic-s2idle-without-i915.html - bat-dg1-5: NOTRUN -> [INCOMPLETE][11] ([i915#6011]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104559v4/bat-dg1-5/igt@i915_susp...@basic-s2idle-without-i915.html * igt@i915_suspend@basic-s3-without-i915: - fi-rkl-11600: [PASS][12] -> [INCOMPLETE][13] ([i915#5982]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11715/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104559v4/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html - bat-adlp-4: NOTRUN -> [SKIP][14] ([i915#5903]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104559v4/bat-adlp-4/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_addfb_basic@basic-x-tiled-legacy: - bat-dg1-5: NOTRUN -> [SKIP][15] ([i915#4212]) +7 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104559v4/bat-dg1-5/igt@kms_addfb_ba...@basic-x-tiled-legacy.html * igt@kms_addfb_basic@basic-y-tiled-legacy: - bat-dg1-5: NOTRUN -> [SKIP][16] ([i915#4215]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104559v4/bat-dg1-5/igt@kms_addfb_ba...@basic-y-tiled-legacy.html * igt@kms_busy@basic: - bat-dg1-5: NOTRUN -> [SKIP][17] ([i915#4303]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104559v4/bat-dg1-5/igt@kms_b...@basic.html * igt@kms_chamelium@common-hpd-after-suspend: - bat-adlp-4: NOTRUN -> [SKIP][18] ([fdo#111827]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104559v4/bat-adlp-4/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_chamelium@dp-crc-fast: - bat-dg1-5: NOTRUN -> [SKIP][19] ([fdo#111827]) +7 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104559v4/bat-dg1-5/igt@kms_chamel...@dp-crc-fast.html * igt@kms_chamelium@hdmi-edid-read: - fi-tgl-u2: NOTRUN -> [SKIP][20] ([fdo#109284] / [fdo#111827]) +7 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104559v4/fi-tgl-u2/igt@kms_chamel...@hdmi-edid-read.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: -
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Support Async Flip on Linear buffers (rev2)
== Series Details ==
Series: drm/i915: Support Async Flip on Linear buffers (rev2)
URL : https://patchwork.freedesktop.org/series/103137/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11715_full -> Patchwork_103137v2_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (13 -> 13)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_103137v2_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
*
igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-5@pipe-a-edp-1:
- {shard-rkl}:NOTRUN -> [SKIP][1] +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103137v2/shard-rkl-6/igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-...@pipe-a-edp-1.html
Known issues
Here are the changes found in Patchwork_103137v2_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_balancer@parallel-contexts:
- shard-iclb: [PASS][2] -> [SKIP][3] ([i915#4525]) +2 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11715/shard-iclb2/igt@gem_exec_balan...@parallel-contexts.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103137v2/shard-iclb7/igt@gem_exec_balan...@parallel-contexts.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: [PASS][4] -> [FAIL][5] ([i915#2842])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11715/shard-iclb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103137v2/shard-iclb6/igt@gem_exec_fair@basic-none-sh...@rcs0.html
* igt@gem_exec_fair@basic-none@vcs1:
- shard-kbl: [PASS][6] -> [FAIL][7] ([i915#2842]) +2 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11715/shard-kbl4/igt@gem_exec_fair@basic-n...@vcs1.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103137v2/shard-kbl1/igt@gem_exec_fair@basic-n...@vcs1.html
* igt@gem_exec_flush@basic-batch-kernel-default-wb:
- shard-snb: [PASS][8] -> [SKIP][9] ([fdo#109271]) +3 similar
issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11715/shard-snb5/igt@gem_exec_fl...@basic-batch-kernel-default-wb.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103137v2/shard-snb6/igt@gem_exec_fl...@basic-batch-kernel-default-wb.html
* igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][10] -> [SKIP][11] ([i915#2190])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11715/shard-tglb5/igt@gem_huc_c...@huc-copy.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103137v2/shard-tglb7/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@smem-oom:
- shard-skl: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4613]) +3
similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103137v2/shard-skl3/igt@gem_lmem_swapp...@smem-oom.html
* igt@gem_lmem_swapping@verify:
- shard-glk: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#4613])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103137v2/shard-glk7/igt@gem_lmem_swapp...@verify.html
* igt@gem_lmem_swapping@verify-ccs:
- shard-kbl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#4613]) +1
similar issue
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103137v2/shard-kbl4/igt@gem_lmem_swapp...@verify-ccs.html
- shard-apl: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#4613])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103137v2/shard-apl8/igt@gem_lmem_swapp...@verify-ccs.html
* igt@gem_vm_create@isolation:
- shard-skl: [PASS][16] -> [DMESG-WARN][17] ([i915#1982])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11715/shard-skl3/igt@gem_vm_cre...@isolation.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103137v2/shard-skl7/igt@gem_vm_cre...@isolation.html
* igt@gen9_exec_parse@allowed-single:
- shard-glk: [PASS][18] -> [DMESG-WARN][19] ([i915#5566] /
[i915#716])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11715/shard-glk8/igt@gen9_exec_pa...@allowed-single.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103137v2/shard-glk7/igt@gen9_exec_pa...@allowed-single.html
* igt@i915_suspend@debugfs-reader:
- shard-apl: [PASS][20] -> [DMESG-WARN][21] ([i915#180]) +1
similar issue
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11715/shard-apl4/igt@i915_susp...@debugfs-reader.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103137v2/shard-apl2/igt@i915_susp...@debugfs-reader.html
*
Re: [Intel-gfx] [PATCH v2 2/6] drm/i915/xehp: Drop GETPARAM lookups of I915_PARAM_[SUB]SLICE_MASK
On 17/05/2022 06:20, Matt Roper wrote: Slice/subslice/EU information should be obtained via the topology queries provided by the I915_QUERY interface; let's turn off support for the old GETPARAM lookups on Xe_HP and beyond where we can't return meaningful values. The slice mask lookup is meaningless since Xe_HP doesn't support traditional slices (and we make no attempt to return the various new units like gslices, cslices, mslices, etc.) here. The subslice mask lookup is even more problematic; given the distinct masks for geometry vs compute purposes, the combined mask returned here is likely not what userspace would want to act upon anyway. The value is also limited to 32-bits by the nature of the GETPARAM ioctl which is sufficient for the initial Xe_HP platforms, but is unable to convey the larger masks that will be needed on other upcoming platforms. Finally, the value returned here becomes even less meaningful when used on multi-tile platforms where each tile will have its own masks. Signed-off-by: Matt Roper Sounds fair. We've been relying on the topology query in Mesa since it's available and it's a requirement for Gfx10+. FYI, we're also not using I915_PARAM_EU_TOTAL on Gfx10+ for the same reason. Acked-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_getparam.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_getparam.c b/drivers/gpu/drm/i915/i915_getparam.c index c12a0adefda5..ac9767c56619 100644 --- a/drivers/gpu/drm/i915/i915_getparam.c +++ b/drivers/gpu/drm/i915/i915_getparam.c @@ -148,11 +148,19 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data, value = intel_engines_has_context_isolation(i915); break; case I915_PARAM_SLICE_MASK: + /* Not supported from Xe_HP onward; use topology queries */ + if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) + return -EINVAL; + value = sseu->slice_mask; if (!value) return -ENODEV; break; case I915_PARAM_SUBSLICE_MASK: + /* Not supported from Xe_HP onward; use topology queries */ + if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) + return -EINVAL; + /* Only copy bits from the first slice */ memcpy(, sseu->subslice_mask, min(sseu->ss_stride, (u8)sizeof(value)));
