Re: [Intel-gfx] [PATCH 11/11] drm/i915: Create resized LUTs for ivb+ split gamma mode
On Thu, Nov 10, 2022 at 09:35:28AM +0530, Nautiyal, Ankit K wrote:
>
> On 11/4/2022 3:12 PM, Ville Syrjälä wrote:
> > On Fri, Nov 04, 2022 at 10:49:39AM +0530, Nautiyal, Ankit K wrote:
> >> Patch looks good to me.
> >>
> >> Minor suggestions inline:
> >>
> >> On 10/26/2022 5:09 PM, Ville Syrjala wrote:
> >>> From: Ville Syrjälä
> >>>
> >>> Currently when opeating in split gamma mode we do the
> >> nitpick: 'operating' typo.
> >>> "skip ever other sw LUT entry" trick in the low level
> >>> LUT programming/readout functions. That is very annoying
> >>> and a big hinderance to revamping the color management
> >>> uapi.
> >>>
> >>> Let's get rid of that problem by making half sized copies
> >>> of the software LUTs and plugging those into the internal
> >>> {pre,post}_csc_lut attachment points (instead of the sticking
> >>> the uapi provide sw LUTs there directly).
> >>>
> >>> With this the low level stuff will operate purely in terms
> >>> the hardware LUT sizes, and all uapi nonsense is contained
> >>> to the atomic check phase. The one thing we do lose is
> >>> intel_color_assert_luts() since we no longer have a way to
> >>> check that the uapi LUTs were correctly used when generating
> >>> the internal copies. But that seems like a price worth paying.
> >>>
> >>> Signed-off-by: Ville Syrjälä
> >>> ---
> >>>drivers/gpu/drm/i915/display/intel_color.c | 81 +-
> >>>1 file changed, 64 insertions(+), 17 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> >>> b/drivers/gpu/drm/i915/display/intel_color.c
> >>> index 33871bfacee7..d48904f90e3a 100644
> >>> --- a/drivers/gpu/drm/i915/display/intel_color.c
> >>> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> >>> @@ -597,6 +597,30 @@ create_linear_lut(struct drm_i915_private *i915, int
> >>> lut_size)
> >>> return blob;
> >>>}
> >>>
> >>> +static struct drm_property_blob *
> >>> +create_resized_lut(struct drm_i915_private *i915,
> >>> +const struct drm_property_blob *blob_in, int lut_out_size)
> >>> +{
> >>> + int i, lut_in_size = drm_color_lut_size(blob_in);
> >>> + struct drm_property_blob *blob_out;
> >>> + const struct drm_color_lut *lut_in;
> >>> + struct drm_color_lut *lut_out;
> >>> +
> >>> + blob_out = drm_property_create_blob(&i915->drm,
> >>> + sizeof(lut_out[0]) * lut_out_size,
> >>> + NULL);
> >>> + if (IS_ERR(blob_out))
> >>> + return blob_out;
> >>> +
> >>> + lut_in = blob_in->data;
> >>> + lut_out = blob_out->data;
> >>> +
> >>> + for (i = 0; i < lut_out_size; i++)
> >>> + lut_out[i] = lut_in[i * (lut_in_size - 1) / (lut_out_size - 1)];
> >>> +
> >>> + return blob_out;
> >>> +}
> >>> +
> >>>static void i9xx_load_lut_8(struct intel_crtc *crtc,
> >>> const struct drm_property_blob *blob)
> >>>{
> >>> @@ -723,19 +747,14 @@ static void ivb_load_lut_10(struct intel_crtc *crtc,
> >>> u32 prec_index)
> >>>{
> >>> struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> >>> - int hw_lut_size = ivb_lut_10_size(prec_index);
> >>> const struct drm_color_lut *lut = blob->data;
> >>> int i, lut_size = drm_color_lut_size(blob);
> >>> enum pipe pipe = crtc->pipe;
> >>>
> >>> - for (i = 0; i < hw_lut_size; i++) {
> >>> - /* We discard half the user entries in split gamma mode */
> >>> - const struct drm_color_lut *entry =
> >>> - &lut[i * (lut_size - 1) / (hw_lut_size - 1)];
> >>> -
> >>> + for (i = 0; i < lut_size; i++) {
> >>> intel_de_write_fw(i915, PREC_PAL_INDEX(pipe),
> >>> prec_index++);
> >>> intel_de_write_fw(i915, PREC_PAL_DATA(pipe),
> >>> - ilk_lut_10(entry));
> >>> + ilk_lut_10(&lut[i]));
> >>> }
> >>>
> >>> /*
> >>> @@ -751,7 +770,6 @@ static void bdw_load_lut_10(struct intel_crtc *crtc,
> >>> u32 prec_index)
> >>>{
> >>> struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> >>> - int hw_lut_size = ivb_lut_10_size(prec_index);
> >>> const struct drm_color_lut *lut = blob->data;
> >>> int i, lut_size = drm_color_lut_size(blob);
> >>> enum pipe pipe = crtc->pipe;
> >>> @@ -759,14 +777,9 @@ static void bdw_load_lut_10(struct intel_crtc *crtc,
> >>> intel_de_write_fw(i915, PREC_PAL_INDEX(pipe),
> >>> prec_index | PAL_PREC_AUTO_INCREMENT);
> >>>
> >>> - for (i = 0; i < hw_lut_size; i++) {
> >>> - /* We discard half the user entries in split gamma mode */
> >>> - const struct drm_color_lut *entry =
> >>> - &lut[i * (lut_size - 1) / (hw_lut_size - 1)];
> >>> -
> >>> + for (i = 0; i < lut_size; i++)
> >>> intel_de_write_fw(i915, PREC_PAL_DATA(pipe),
> >>>
Re: [Intel-gfx] [PATCH v2 11/11] iommufd: Allow iommufd to supply /dev/vfio/vfio
> From: Jason Gunthorpe > Sent: Tuesday, November 8, 2022 8:53 AM > > If the VFIO container is compiled out, give a kconfig option for iommufd > to provide the miscdev node with the same name and permissions as vfio > uses. > > The compatibility node supports the same ioctls as VFIO and automatically > enables the VFIO compatible pinned page accounting mode. > > Tested-by: Nicolin Chen > Signed-off-by: Jason Gunthorpe Reviewed-by: Kevin Tian
Re: [Intel-gfx] [PATCH v2 10/11] vfio: Make vfio_container optionally compiled
> From: Jason Gunthorpe
> Sent: Thursday, November 10, 2022 3:53 AM
>
> On Wed, Nov 09, 2022 at 10:18:09AM -0700, Alex Williamson wrote:
>
> > DPDK supports no-iommu mode.
>
> Er? Huh? How? I thought no-iommu was for applications that didn't do
> DMA? How is DPDK getting packets in/out without DMA? I guess it snoops
> in /proc/ or something to learn PFNs of mlock'd memory?
iirc dpdk started with UIO plus various tricks (root privilege, hugepage, etc.)
to lock and learn PFN's from pagemap. Then when migrating it to vfio the
no-iommu option was introduced to provide UIO compatibility.
>
> > I agree that it's very useful for testing, I'm certainly not suggesting
> > to give up, but I'm not sure where no-iommu lives when iommufd owns
> > /dev/vfio/vfio. Given the unsafe interrupts discussion, it doesn't
> > seem like the type of thing that would be a priority for iommufd.
>
> Ah, I think the bit below will do the job, I'm not sure without doing
> some testing (and I don't think I have the necessary Intel NIC for
> DPDK). The basic point is no-iommu literally means 'do not use iommufd
> at all, do not create an iommufd_device or an iommufd_access'. VFIO
> can easially do that on its own.
>
> The only slightly messy bit is that uAPI requires the SET_CONTAINER
> which we can just NOP in vfio_compat. With more checks it could have
> higher fidelity of error cases, but not sure it is worth it.
>
> When we talk about the device cdev flow then I suggest that no-iommu
> simply requires -1 for the iommufd during bind - ie no iommufd is
> used or accepted and that is how the userspace knows/confirms it is in
> no-iommu mode.
>
> > We're on a path where vfio accepts an iommufd as a container, and
> > ultimately iommufd becomes the container provider, supplanting the
> > IOMMU driver registration aspect of vfio. I absolutely want type1 and
> > spapr backends to get replaced by iommufd, but reluctance to support
> > aspects of vfio "legacy" behavior doesn't give me warm fuzzies about a
> > wholesale hand-off of the container to a different subsystem, for
> > example vs an iommufd shim spoofing type1 support.
>
> Well, I will agree to do everything required, just let's go through the
> process to understand the security situation and ensure we are still
> doing things the right way.
>
> > Unfortunately we no longer have a CONFIG_EXPERIMENTAL option to hide
> > behind for disabling VFIO_CONTAINER, so regardless of our intentions
> > that a transition is some time off, it may become an issue sooner than
> > we expect.
>
> We can add kconfig text discouraging that?
>
> diff --git a/drivers/iommu/iommufd/vfio_compat.c
> b/drivers/iommu/iommufd/vfio_compat.c
> index dbef3274803336..81f7594cfff8e0 100644
> --- a/drivers/iommu/iommufd/vfio_compat.c
> +++ b/drivers/iommu/iommufd/vfio_compat.c
> @@ -259,6 +259,14 @@ static int iommufd_vfio_set_iommu(struct
> iommufd_ctx *ictx, unsigned long type)
> struct iommufd_ioas *ioas = NULL;
> int rc = 0;
>
> + /*
> + * Emulation for NOIMMU is imperfect in that VFIO blocks almost all
> + * other ioctls. We let them keep working but they mostly fail since no
> + * IOAS should exist.
> + */
> + if (IS_ENABLED(CONFIG_VFIO_NOIOMMU) && type ==
> VFIO_NOIOMMU_IOMMU)
> + return 0;
> +
> if (type != VFIO_TYPE1_IOMMU && type != VFIO_TYPE1v2_IOMMU)
> return -EINVAL;
>
also need a check in iommufd_vfio_check_extension() so only
VFIO_NOIOMMU_IOMMU is supported in no-iommu mode.
> diff --git a/drivers/vfio/iommufd.c b/drivers/vfio/iommufd.c
> index 595c7b2146f88c..64a336ebc99b9f 100644
> --- a/drivers/vfio/iommufd.c
> +++ b/drivers/vfio/iommufd.c
> @@ -18,6 +18,10 @@ int vfio_iommufd_bind(struct vfio_device *vdev,
> struct iommufd_ctx *ictx)
>
> lockdep_assert_held(&vdev->dev_set->lock);
>
> + if (IS_ENABLED(CONFIG_VFIO_NO_IOMMU) &&
> + vdev->group->type == VFIO_NO_IOMMU)
> + return 0;
> +
> /*
>* If the driver doesn't provide this op then it means the device does
>* not do DMA at all. So nothing to do.
> @@ -53,6 +57,10 @@ void vfio_iommufd_unbind(struct vfio_device *vdev)
> {
> lockdep_assert_held(&vdev->dev_set->lock);
>
> + if (IS_ENABLED(CONFIG_VFIO_NO_IOMMU) &&
> + vdev->group->type == VFIO_NO_IOMMU)
> + return;
> +
> if (vdev->ops->unbind_iommufd)
> vdev->ops->unbind_iommufd(vdev);
> }
> diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
> index f3c48b8c45627d..08c5b05a129c2c 100644
> --- a/drivers/vfio/vfio_main.c
> +++ b/drivers/vfio/vfio_main.c
> @@ -749,10 +749,13 @@ static int vfio_group_ioctl_set_container(struct
> vfio_group *group,
> if (!IS_ERR(iommufd)) {
> u32 ioas_id;
>
> - ret = iommufd_vfio_compat_ioas_id(iommufd, &ioas_id);
> - if (ret) {
> - iommufd_ctx_put(group->iommufd);
> - goto out_u
Re: [Intel-gfx] [PATCH] drm/i915: Don't wait forever in drop_caches
On 11/9/2022 03:35, Tvrtko Ursulin wrote: On 08/11/2022 19:37, John Harrison wrote: On 11/8/2022 01:08, Tvrtko Ursulin wrote: On 07/11/2022 19:45, John Harrison wrote: On 11/7/2022 06:09, Tvrtko Ursulin wrote: On 04/11/2022 17:45, John Harrison wrote: On 11/4/2022 03:01, Tvrtko Ursulin wrote: On 03/11/2022 19:16, John Harrison wrote: On 11/3/2022 02:38, Tvrtko Ursulin wrote: On 03/11/2022 09:18, Tvrtko Ursulin wrote: On 03/11/2022 01:33, John Harrison wrote: On 11/2/2022 07:20, Tvrtko Ursulin wrote: On 02/11/2022 12:12, Jani Nikula wrote: On Tue, 01 Nov 2022, john.c.harri...@intel.com wrote: From: John Harrison At the end of each test, IGT does a drop caches call via sysfs with sysfs? Sorry, that was meant to say debugfs. I've also been working on some sysfs IGT issues and evidently got my wires crossed! special flags set. One of the possible paths waits for idle with an infinite timeout. That causes problems for debugging issues when CI catches a "can't go idle" test failure. Best case, the CI system times out (after 90s), attempts a bunch of state dump actions and then reboots the system to recover it. Worst case, the CI system can't do anything at all and then times out (after 1000s) and simply reboots. Sometimes a serial port log of dmesg might be available, sometimes not. So rather than making life hard for ourselves, change the timeout to be 10s rather than infinite. Also, trigger the standard wedge/reset/recover sequence so that testing can continue with a working system (if possible). Signed-off-by: John Harrison --- drivers/gpu/drm/i915/i915_debugfs.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index ae987e92251dd..9d916fbbfc27c 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -641,6 +641,9 @@ DEFINE_SIMPLE_ATTRIBUTE(i915_perf_noa_delay_fops, DROP_RESET_ACTIVE | \ DROP_RESET_SEQNO | \ DROP_RCU) + +#define DROP_IDLE_TIMEOUT (HZ * 10) I915_IDLE_ENGINES_TIMEOUT is defined in i915_drv.h. It's also only used here. So move here, dropping i915 prefix, next to the newly proposed one? Sure, can do that. I915_GEM_IDLE_TIMEOUT is defined in i915_gem.h. It's only used in gt/intel_gt.c. Move there and rename to GT_IDLE_TIMEOUT? I915_GT_SUSPEND_IDLE_TIMEOUT is defined and used only in intel_gt_pm.c. No action needed, maybe drop i915 prefix if wanted. These two are totally unrelated and in code not being touched by this change. I would rather not conflate changing random other things with fixing this specific issue. I915_IDLE_ENGINES_TIMEOUT is in ms, the rest are in jiffies. Add _MS suffix if wanted. My head spins. I follow and raise that the newly proposed DROP_IDLE_TIMEOUT applies to DROP_ACTIVE and not only DROP_IDLE. My original intention for the name was that is the 'drop caches timeout for intel_gt_wait_for_idle'. Which is quite the mouthful and hence abbreviated to DROP_IDLE_TIMEOUT. But yes, I realised later that name can be conflated with the DROP_IDLE flag. Will rename. Things get refactored, code moves around, bits get left behind, who knows. No reason to get too worked up. :) As long as people are taking a wider view when touching the code base, and are not afraid to send cleanups, things should be good. On the other hand, if every patch gets blocked in code review because someone points out some completely unrelated piece of code could be a bit better then nothing ever gets fixed. If you spot something that you think should be improved, isn't the general idea that you should post a patch yourself to improve it? There's two maintainers per branch and an order of magnitude or two more developers so it'd be nice if cleanups would just be incoming on self-initiative basis. ;) For the actual functional change at hand - it would be nice if code paths in question could handle SIGINT and then we could punt the decision on how long someone wants to wait purely to userspace. But it's probably hard and it's only debugfs so whatever. The code paths in question will already abort on a signal won't they? Both intel_gt_wait_for_idle() and intel_guc_wait_for_pending_msg(), which is where the uc_wait_for_idle eventually ends up, have an 'if(signal_pending) return -EINTR;' check. Beyond that, it sounds like what you are asking for is a change in the IGT libraries and/or CI framework to start sending signals after some specific timeout. That seems like a significantly more complex change (in terms of the number of entities affected and number of groups involved) and unnecessary. If you say so, I haven't looked at them all. But if the code path in question already aborts on signals then I am not sure what is the patch fixing? I assumed you are trying to avoid the write stuck in D forever, which then prevents dri
Re: [Intel-gfx] [PATCH v6 00/20] drm/i915/vm_bind: Add VM_BIND functionality
On Wed, Nov 09, 2022 at 04:16:25PM -0800, Zanoni, Paulo R wrote: On Mon, 2022-11-07 at 00:51 -0800, Niranjana Vishwanathapura wrote: 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). Multiple mappings can map to the same physical pages of an object (aliasing). These mappings (also referred to as persistent mappings) will be persistent across multiple GPU submissions (execbuf calls) issued by the UMD, without user having to provide a list of all required mappings during each submission (as required by older execbuf mode). This patch series support VM_BIND version 1, as described by the param I915_PARAM_VM_BIND_VERSION. Add new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only works in vm_bind mode. The vm_bind mode only works with this new execbuf3 ioctl. The new execbuf3 ioctl will not have any execlist support and all the legacy support like relocations etc., are removed. NOTEs: * It is based on below VM_BIND design+uapi rfc. Documentation/gpu/rfc/i915_vm_bind.rst Hi One difference for execbuf3 that I noticed that is not mentioned in the RFC document is that we now don't have a way to signal EXEC_OBJECT_WRITE. When looking at the Kernel code, some there are some pieces that check for this flag: - there's code that deals with frontbuffer rendering - there's code that deals with fences - there's code that prevents self-modifying batches - another that seems related to waiting for objects Are there any new rules regarding frontbuffer rendering when we use execbuf3? Any other behavior changes related to the other places that we should expect when using execbuf3? Paulo, Most of the EXEC_OBJECT_WRITE check in execbuf path is related to implicit dependency tracker which execbuf3 does not support. The frontbuffer related updated is the only exception and I don't remember the rationale to not require this on execbuf3. Matt, Tvrtko, Daniel, can you please comment here? Thanks, Niranjana Thanks, Paulo * The IGT RFC series is posted as, [PATCH i-g-t v5 0/12] vm_bind: Add VM_BIND validation support v2: Address various review comments v3: Address review comments and other fixes v4: Remove vm_unbind out fence uapi which is not supported yet, replace vm->vm_bind_mode check with i915_gem_vm_is_vm_bind_mode() v5: Render kernel-doc, use PIN_NOEVICT, limit vm_bind support to non-recoverable faults v6: Rebased, minor fixes, add reserved fields to drm_i915_gem_vm_bind, add new patch for async vm_unbind support Signed-off-by: Niranjana Vishwanathapura Niranjana Vishwanathapura (20): drm/i915/vm_bind: Expose vm lookup function drm/i915/vm_bind: Add __i915_sw_fence_await_reservation() drm/i915/vm_bind: Expose i915_gem_object_max_page_size() drm/i915/vm_bind: Add support to create persistent vma drm/i915/vm_bind: Implement bind and unbind of object drm/i915/vm_bind: Support for VM private BOs drm/i915/vm_bind: Add support to handle object evictions drm/i915/vm_bind: Support persistent vma activeness tracking drm/i915/vm_bind: Add out fence support drm/i915/vm_bind: Abstract out common execbuf functions drm/i915/vm_bind: Use common execbuf functions in execbuf path drm/i915/vm_bind: Implement I915_GEM_EXECBUFFER3 ioctl drm/i915/vm_bind: Update i915_vma_verify_bind_complete() drm/i915/vm_bind: Expose i915_request_await_bind() drm/i915/vm_bind: Handle persistent vmas in execbuf3 drm/i915/vm_bind: userptr dma-resv changes drm/i915/vm_bind: Limit vm_bind mode to non-recoverable contexts drm/i915/vm_bind: Add uapi for user to enable vm_bind_mode drm/i915/vm_bind: Render VM_BIND documentation drm/i915/vm_bind: Async vm_unbind support Documentation/gpu/i915.rst| 78 +- drivers/gpu/drm/i915/Makefile | 3 + drivers/gpu/drm/i915/gem/i915_gem_context.c | 43 +- drivers/gpu/drm/i915/gem/i915_gem_context.h | 17 + drivers/gpu/drm/i915/gem/i915_gem_create.c| 72 +- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 6 + .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 516 +-- .../gpu/drm/i915/gem/i915_gem_execbuffer3.c | 871 ++ .../drm/i915/gem/i915_gem_execbuffer_common.c | 666 + .../drm/i915/gem/i915_gem_execbuffer_common.h | 74 ++ drivers/gpu/drm/i915/gem/i915_gem_ioctls.h| 2 + drivers/gpu/drm/i915/gem/i915_gem_object.c| 3 + drivers/gpu/drm/i915/gem/i915_gem_object.h| 2 + .../gpu/drm/i915/gem/i915_gem_object_types.h | 6 + drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 19 + drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h | 30 + .../drm/i915/gem/i915_gem_vm_bind_object.c| 449 + drivers/gpu/drm/i915/gt/intel_gtt.c | 17 + drivers/gpu/drm/i915/gt/intel_gtt.h | 21 + drivers/gpu/drm/i915/i915_driver.c| 4 + drivers/gpu/drm/i915/i915_drv.h | 2 + drivers/gpu/drm/
[Intel-gfx] [PATCH] drm/i915/display: Add missing checks for cdclk crawling
cdclk_sanitize() function was written assuming vco was a signed integer. vco gets assigned to -1 (essentially ~0) for the case where PLL might be enabled and vco is not a frequency that will ever get used. In such a scenario the right thing to do is disable the PLL and re-enable it again with a valid frequency. However the vco is declared as a unsigned variable. With the above assumption, driver takes crawl path when not needed. Add explicit check to not crawl in the case of an invalid PLL. Cc: Matt Roper Suggested-by: Ville Syrjälä Signed-off-by: Anusha Srivatsa --- drivers/gpu/drm/i915/display/intel_cdclk.c | 2 ++ drivers/gpu/drm/i915/display/intel_cdclk.h | 1 + 2 files changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c b/drivers/gpu/drm/i915/display/intel_cdclk.c index 8a9031012d74..91112d266763 100644 --- a/drivers/gpu/drm/i915/display/intel_cdclk.c +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c @@ -1962,6 +1962,8 @@ static bool intel_cdclk_can_crawl(struct drm_i915_private *dev_priv, if (!HAS_CDCLK_CRAWL(dev_priv)) return false; + if (intel_pll_is_unknown(a->vco)) + return false; /* * The vco and cd2x divider will change independently * from each, so we disallow cd2x change when crawling. diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.h b/drivers/gpu/drm/i915/display/intel_cdclk.h index c674879a84a5..6eb83d806f11 100644 --- a/drivers/gpu/drm/i915/display/intel_cdclk.h +++ b/drivers/gpu/drm/i915/display/intel_cdclk.h @@ -80,6 +80,7 @@ intel_atomic_get_cdclk_state(struct intel_atomic_state *state); to_intel_cdclk_state(intel_atomic_get_old_global_obj_state(state, &to_i915(state->base.dev)->display.cdclk.obj)) #define intel_atomic_get_new_cdclk_state(state) \ to_intel_cdclk_state(intel_atomic_get_new_global_obj_state(state, &to_i915(state->base.dev)->display.cdclk.obj)) +#define intel_pll_is_unknown(vco) ((vco) == ~0) int intel_cdclk_init(struct drm_i915_private *dev_priv); -- 2.25.1
Re: [Intel-gfx] [PATCH v2 09/11] vfio: Move container related MODULE_ALIAS statements into container.c
> From: Jason Gunthorpe
> Sent: Tuesday, November 8, 2022 8:53 AM
>
> The miscdev is in container.c, so should these related MODULE_ALIAS
> statements. This is necessary for the next patch to be able to fully
> disable /dev/vfio/vfio.
>
> Fixes: cdc71fe4ecbf ("vfio: Move container code into
> drivers/vfio/container.c")
> Reported-by: "Liu, Yi L"
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
Re: [Intel-gfx] [PATCH v2 08/11] vfio-iommufd: Support iommufd for emulated VFIO devices
> From: Jason Gunthorpe > Sent: Tuesday, November 8, 2022 8:53 AM > > Emulated VFIO devices are calling vfio_register_emulated_iommu_dev() and > consist of all the mdev drivers. > > Like the physical drivers, support for iommufd is provided by the driver > supplying the correct standard ops. Provide ops from the core that > duplicate what vfio_register_emulated_iommu_dev() does. > > Emulated drivers are where it is more likely to see variation in the > iommfd support ops. For instance IDXD will probably need to setup both a > iommfd_device context linked to a PASID and an iommufd_access context to > support all their mdev operations. > > Tested-by: Nicolin Chen > Signed-off-by: Jason Gunthorpe this looks good to me overall. but I'll wait for next version to ack after the change for s390 is settled down and incorporated.
[Intel-gfx] [PATCH] drm/i915: Fix unhandled deadlock in grab_vma()
At present, the gpu thread crashes at times when grab_vma() attempts to
acquire a gem object lock when in a deadlock state.
Problems:
I identified the following 4 issues in the current code:
1. Since grab_vma() calls i915_gem_object_trylock(), which consequently
calls ww_mutex_trylock(), to acquire lock, it does not perform any
-EDEADLK handling; And -EALREADY handling is also unreliable,
according to the description of ww_mutex_trylock().
2. Since the return value of grab_vma() is a boolean showing
success/failure, it does not provide any extra information on the
failure reason, and therefore does not provide any mechanism to its
caller to take any action to fix a potential deadlock.
3. Current grab_vma() implementation produces inconsistent behaviour
depending on the refcount value, without informing the caller. If
refcount is already zero, grab_vma() neither acquires lock nor
increments the refcount, but still returns 'true' for success! This
means that grab_vma() returning true (for success) does not always
mean that the gem obj is actually safely accessible.
4. Currently, calling "i915_gem_object_lock(obj,ww)" is meant to be
followed by a consequent "i915_gem_object_unlock(obj)" ONLY if the
original 'ww' object pointer was NULL, or otherwise not be called and
leave the houskeeping to "i915_gem_ww_ctx_fini(ww)". There are a few
issues with this:
- This is not documented anywhere in the code (that I could find),
but only explained in an older commit message.
- This produces an inconsistent usage of the lock/unlock functions,
increasing the chance of mistakes and issues.
- This is not a clean design as it requires any new code that calls
these lock/unlock functions to know their internals, as well as the
internals of the functions calling the new code being added.
Fix:
To fix the issues above, this patch:
1. Changes grab_vma() to call i915_gem_object_lock() instead of
i915_gem_object_trylock(), to handle -EDEADLK and -EALREADY cases.
This should not cause any issue since the PIN_NONBLOCK flag is
checked beforehand in the 2 cases grab_vma() is called.
2. Changes grab_vma() to return the actual error code, instead of bool.
3. Changes grab_vma() to behave consistently when returning success, by
both incrementing the refcount and acquiring lock at all times.
4. Changes i915_gem_object_unlock() to pair with i915_gem_object_lock()
nicely in all cases and do the housekeeping without the need for the
caller to do anything other than simply calling lock and unlock.
5. Ensures the gem obj->obj_link is initialized and deleted from the ww
list such that it can be tested for emptiness using list_empty().
Signed-off-by: Mani Milani
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 2 +
drivers/gpu/drm/i915/gem/i915_gem_object.h | 10 -
drivers/gpu/drm/i915/i915_gem_evict.c | 48 --
drivers/gpu/drm/i915/i915_gem_ww.c | 8 ++--
4 files changed, 41 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 369006c5317f..69d013b393fb 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -78,6 +78,8 @@ void i915_gem_object_init(struct drm_i915_gem_object *obj,
INIT_LIST_HEAD(&obj->mm.link);
+ INIT_LIST_HEAD(&obj->obj_link);
+
INIT_LIST_HEAD(&obj->lut_list);
spin_lock_init(&obj->lut_lock);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 1723af9b0f6a..7e7a61bdf52c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -219,7 +219,7 @@ static inline bool i915_gem_object_trylock(struct
drm_i915_gem_object *obj,
return ww_mutex_trylock(&obj->base.resv->lock, &ww->ctx);
}
-static inline void i915_gem_object_unlock(struct drm_i915_gem_object *obj)
+static inline void __i915_gem_object_unlock(struct drm_i915_gem_object *obj)
{
if (obj->ops->adjust_lru)
obj->ops->adjust_lru(obj);
@@ -227,6 +227,14 @@ static inline void i915_gem_object_unlock(struct
drm_i915_gem_object *obj)
dma_resv_unlock(obj->base.resv);
}
+static inline void i915_gem_object_unlock(struct drm_i915_gem_object *obj)
+{
+ if (list_empty(&obj->obj_link))
+ __i915_gem_object_unlock(obj);
+ else
+ i915_gem_ww_unlock_single(obj);
+}
+
static inline void
i915_gem_object_set_readonly(struct drm_i915_gem_object *obj)
{
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c
b/drivers/gpu/drm/i915/i915_gem_evict.c
index f025ee4fa526..3eb514b4eddc 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -55,29 +55,33 @@ static int ggtt_flush(struct intel_gt *gt)
return intel_gt_wait_for_idle(gt, MAX_SCHEDULE_TIMEOUT);
Re: [Intel-gfx] [PATCH 11/11] drm/i915: Create resized LUTs for ivb+ split gamma mode
On 11/4/2022 3:12 PM, Ville Syrjälä wrote:
On Fri, Nov 04, 2022 at 10:49:39AM +0530, Nautiyal, Ankit K wrote:
Patch looks good to me.
Minor suggestions inline:
On 10/26/2022 5:09 PM, Ville Syrjala wrote:
From: Ville Syrjälä
Currently when opeating in split gamma mode we do the
nitpick: 'operating' typo.
"skip ever other sw LUT entry" trick in the low level
LUT programming/readout functions. That is very annoying
and a big hinderance to revamping the color management
uapi.
Let's get rid of that problem by making half sized copies
of the software LUTs and plugging those into the internal
{pre,post}_csc_lut attachment points (instead of the sticking
the uapi provide sw LUTs there directly).
With this the low level stuff will operate purely in terms
the hardware LUT sizes, and all uapi nonsense is contained
to the atomic check phase. The one thing we do lose is
intel_color_assert_luts() since we no longer have a way to
check that the uapi LUTs were correctly used when generating
the internal copies. But that seems like a price worth paying.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 81 +-
1 file changed, 64 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 33871bfacee7..d48904f90e3a 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -597,6 +597,30 @@ create_linear_lut(struct drm_i915_private *i915, int
lut_size)
return blob;
}
+static struct drm_property_blob *
+create_resized_lut(struct drm_i915_private *i915,
+ const struct drm_property_blob *blob_in, int lut_out_size)
+{
+ int i, lut_in_size = drm_color_lut_size(blob_in);
+ struct drm_property_blob *blob_out;
+ const struct drm_color_lut *lut_in;
+ struct drm_color_lut *lut_out;
+
+ blob_out = drm_property_create_blob(&i915->drm,
+ sizeof(lut_out[0]) * lut_out_size,
+ NULL);
+ if (IS_ERR(blob_out))
+ return blob_out;
+
+ lut_in = blob_in->data;
+ lut_out = blob_out->data;
+
+ for (i = 0; i < lut_out_size; i++)
+ lut_out[i] = lut_in[i * (lut_in_size - 1) / (lut_out_size - 1)];
+
+ return blob_out;
+}
+
static void i9xx_load_lut_8(struct intel_crtc *crtc,
const struct drm_property_blob *blob)
{
@@ -723,19 +747,14 @@ static void ivb_load_lut_10(struct intel_crtc *crtc,
u32 prec_index)
{
struct drm_i915_private *i915 = to_i915(crtc->base.dev);
- int hw_lut_size = ivb_lut_10_size(prec_index);
const struct drm_color_lut *lut = blob->data;
int i, lut_size = drm_color_lut_size(blob);
enum pipe pipe = crtc->pipe;
- for (i = 0; i < hw_lut_size; i++) {
- /* We discard half the user entries in split gamma mode */
- const struct drm_color_lut *entry =
- &lut[i * (lut_size - 1) / (hw_lut_size - 1)];
-
+ for (i = 0; i < lut_size; i++) {
intel_de_write_fw(i915, PREC_PAL_INDEX(pipe), prec_index++);
intel_de_write_fw(i915, PREC_PAL_DATA(pipe),
- ilk_lut_10(entry));
+ ilk_lut_10(&lut[i]));
}
/*
@@ -751,7 +770,6 @@ static void bdw_load_lut_10(struct intel_crtc *crtc,
u32 prec_index)
{
struct drm_i915_private *i915 = to_i915(crtc->base.dev);
- int hw_lut_size = ivb_lut_10_size(prec_index);
const struct drm_color_lut *lut = blob->data;
int i, lut_size = drm_color_lut_size(blob);
enum pipe pipe = crtc->pipe;
@@ -759,14 +777,9 @@ static void bdw_load_lut_10(struct intel_crtc *crtc,
intel_de_write_fw(i915, PREC_PAL_INDEX(pipe),
prec_index | PAL_PREC_AUTO_INCREMENT);
- for (i = 0; i < hw_lut_size; i++) {
- /* We discard half the user entries in split gamma mode */
- const struct drm_color_lut *entry =
- &lut[i * (lut_size - 1) / (hw_lut_size - 1)];
-
+ for (i = 0; i < lut_size; i++)
intel_de_write_fw(i915, PREC_PAL_DATA(pipe),
- ilk_lut_10(entry));
- }
+ ilk_lut_10(&lut[i]));
/*
* Reset the index, otherwise it prevents the legacy palette to be
@@ -1343,7 +1356,7 @@ void intel_color_assert_luts(const struct
intel_crtc_state *crtc_state)
crtc_state->pre_csc_lut !=
i915->display.color.glk_linear_degamma_lut);
drm_WARN_ON(&i915->drm,
crtc_state->post_csc_lut !=
crtc_state->hw.gamma_lut);
- } else {
+ } else if (crtc_state->gamma_mode != GAMMA_MO
Re: [Intel-gfx] [PATCH v2 07/11] vfio-iommufd: Support iommufd for physical VFIO devices
> From: Jason Gunthorpe
> Sent: Wednesday, November 9, 2022 1:52 AM
>
> On Tue, Nov 08, 2022 at 03:41:25PM +0800, Yi Liu wrote:
> > On 2022/11/8 14:10, Nicolin Chen wrote:
> > > On Mon, Nov 07, 2022 at 08:52:51PM -0400, Jason Gunthorpe wrote:
> > >
> > > > @@ -795,6 +800,10 @@ static int vfio_device_first_open(struct
> vfio_device *device)
> > > > ret = vfio_group_use_container(device->group);
> > > > if (ret)
> > > > goto err_module_put;
> > > > + } else if (device->group->iommufd) {
> > > > + ret = vfio_iommufd_bind(device, device->group->iommufd);
> > >
> > > Here we check device->group->iommufd...
> > >
> > > > + if (ret)
> > > > + goto err_module_put;
> > > > }
> > > > device->kvm = device->group->kvm;
> > > > @@ -812,6 +821,7 @@ static int vfio_device_first_open(struct
> vfio_device *device)
> > > > device->kvm = NULL;
> > > > if (device->group->container)
> > > > vfio_group_unuse_container(device->group);
> > > > + vfio_iommufd_unbind(device);
> > >
> > > ...yet, missing here, which could result in kernel oops.
> > >
> > > Should probably add something similar:
> > > + if (device->group->iommufd)
> > > + vfio_iommufd_unbind(device);
> > >
> > > Or should check !vdev->iommufd_device inside the ->unbind.
> >
> > this check was in prior version, but removed in this version. any
> > special reason? Jason?
>
> Oooh, this makes more sense - Kevin pointed out the check was wrong:
>
> > > +void vfio_iommufd_unbind(struct vfio_device *vdev)
> > > +{
> > > + lockdep_assert_held(&vdev->dev_set->lock);
> > > +
> > > + if (!vdev->iommufd_device)
> > > + return;
>
> > there is no iommufd_device in the emulated path...
>
> And he is right, so I dropped it. But really the check was just
> misspelled, it was supposed to be "device->group->iommufd" because the
> caller assumed it.
>
> Still, I think the right way to fix it is to lift the check as we
> don't touch group->iommufd in iommufd.c
>
yes this is the right fix.
Re: [Intel-gfx] [PATCH v2 07/11] vfio-iommufd: Support iommufd for physical VFIO devices
> From: Jason Gunthorpe
> Sent: Tuesday, November 8, 2022 8:53 AM
>
> +
> +int vfio_iommufd_bind(struct vfio_device *vdev, struct iommufd_ctx *ictx)
> +{
> + u32 ioas_id;
> + u32 device_id;
> + int ret;
> +
> + lockdep_assert_held(&vdev->dev_set->lock);
> +
> + /*
> + * If the driver doesn't provide this op then it means the device does
> + * not do DMA at all. So nothing to do.
> + */
> + if (!vdev->ops->bind_iommufd)
> + return 0;
> +
> + ret = vdev->ops->bind_iommufd(vdev, ictx, &device_id);
> + if (ret)
> + return ret;
> +
> + ret = iommufd_vfio_compat_ioas_id(ictx, &ioas_id);
> + if (ret)
> + goto err_unbind;
> + ret = vdev->ops->attach_ioas(vdev, &ioas_id);
> + if (ret)
> + goto err_unbind;
with our discussion in v1:
https://lore.kernel.org/all/y2mgjqz8fvm54...@nvidia.com/
I got the rationale on iommufd part which doesn't have the concept
of container hence not necessarily to impose restriction on when
an user can change a compat ioas.
But from vfio side I wonder whether we should cache the compat
ioas id when it's attached by the first device and then use it all the
way for other device attachments coming after. implying IOAS_SET
only affects containers which haven't been attached.
In concept a container should be only aliased to one compat ioas
in its lifetime.
[Intel-gfx] ✓ Fi.CI.IGT: success for Add selftest for slpc tile interaction (rev4)
== Series Details ==
Series: Add selftest for slpc tile interaction (rev4)
URL : https://patchwork.freedesktop.org/series/110248/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12363_full -> Patchwork_110248v4_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (9 -> 11)
--
Additional (2): shard-rkl shard-dg1
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_110248v4_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_spin_batch@user-each:
- {shard-rkl}:NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110248v4/shard-rkl-3/igt@gem_spin_ba...@user-each.html
* igt@kms_invalid_mode@zero-clock:
- {shard-rkl}:NOTRUN -> [SKIP][2] +4 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110248v4/shard-rkl-5/igt@kms_invalid_m...@zero-clock.html
Known issues
Here are the changes found in Patchwork_110248v4_full that come from known
issues:
### CI changes ###
Issues hit
* boot:
- shard-glk: ([PASS][3], [PASS][4], [PASS][5], [PASS][6],
[PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12],
[PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18],
[PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24],
[PASS][25], [PASS][26], [PASS][27]) -> ([PASS][28], [PASS][29], [PASS][30],
[PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36],
[PASS][37], [PASS][38], [PASS][39], [PASS][40], [FAIL][41], [PASS][42],
[PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48],
[PASS][49], [FAIL][50], [PASS][51], [PASS][52]) ([i915#4392])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12363/shard-glk5/boot.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12363/shard-glk3/boot.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12363/shard-glk3/boot.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12363/shard-glk1/boot.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12363/shard-glk1/boot.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12363/shard-glk1/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12363/shard-glk9/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12363/shard-glk2/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12363/shard-glk9/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12363/shard-glk9/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12363/shard-glk8/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12363/shard-glk8/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12363/shard-glk8/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12363/shard-glk7/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12363/shard-glk7/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12363/shard-glk7/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12363/shard-glk7/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12363/shard-glk6/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12363/shard-glk6/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12363/shard-glk6/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12363/shard-glk5/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12363/shard-glk2/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12363/shard-glk5/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12363/shard-glk2/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12363/shard-glk3/boot.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110248v4/shard-glk3/boot.html
[29]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110248v4/shard-glk3/boot.html
[30]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110248v4/shard-glk5/boot.html
[31]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110248v4/shard-glk5/boot.html
[32]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110248v4/shard-glk5/boot.html
[33]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110248v4/shard-glk6/boot.html
[34]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110248v4/shard-glk6/boot.html
[35]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110248v4/shard-glk6/boot.html
[36]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110248v4/shard-glk7/boot.html
[37]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110248v4/shard-glk7/
Re: [Intel-gfx] [PATCH v2 06/11] vfio-iommufd: Allow iommufd to be used in place of a container fd
> From: Jason Gunthorpe > Sent: Tuesday, November 8, 2022 8:53 AM > > This makes VFIO_GROUP_SET_CONTAINER accept both a vfio container FD > and an > iommufd. > > In iommufd mode an IOAS will exist after the SET_CONTAINER, but it will > not be attached to any groups. > > For VFIO this means that the VFIO_GROUP_GET_STATUS and > VFIO_GROUP_FLAGS_VIABLE works subtly differently. With the container FD > the iommu_group_claim_dma_owner() is done during SET_CONTAINER but > for > IOMMUFD this is done during VFIO_GROUP_GET_DEVICE_FD. Meaning that > VFIO_GROUP_FLAGS_VIABLE could be set but GET_DEVICE_FD will fail due to > viability. > > As GET_DEVICE_FD can fail for many reasons already this is not expected to > be a meaningful difference. > > Reorganize the tests for if the group has an assigned container or iommu > into a vfio_group_has_iommu() function and consolidate all the duplicated > WARN_ON's etc related to this. > > Call container functions only if a container is actually present on the > group. > > Tested-by: Nicolin Chen > Signed-off-by: Jason Gunthorpe Reviewed-by: Kevin Tian
Re: [Intel-gfx] [PATCH v2 05/11] vfio: Use IOMMU_CAP_ENFORCE_CACHE_COHERENCY for vfio_file_enforced_coherent()
> From: Jason Gunthorpe
> Sent: Tuesday, November 8, 2022 8:53 AM
>
> iommufd doesn't establish the iommu_domains until after the device FD is
> opened, even if the container has been set. This design is part of moving
> away from the group centric iommu APIs.
>
> This is fine, except that the normal sequence of establishing the kvm
> wbinvd won't work:
>
>group = open("/dev/vfio/XX")
>ioctl(group, VFIO_GROUP_SET_CONTAINER)
>ioctl(kvm, KVM_DEV_VFIO_GROUP_ADD)
>ioctl(group, VFIO_GROUP_GET_DEVICE_FD)
>
> As the domains don't start existing until GET_DEVICE_FD. Further,
> GET_DEVICE_FD requires that KVM_DEV_VFIO_GROUP_ADD already be
> done as that
> is what sets the group->kvm and thus device->kvm for the driver to use
> during open.
>
> Now that we have device centric cap ops and the new
> IOMMU_CAP_ENFORCE_CACHE_COHERENCY we know what the
> iommu_domain will be
> capable of without having to create it. Use this to compute
> vfio_file_enforced_coherent() and resolve the ordering problems.
>
> VFIO always tries to upgrade domains to enforce cache coherency, it never
> attaches a device that supports enforce cache coherency to a less capable
> domain, so the cap test is a sufficient proxy for the ultimate
> outcome. iommufd also ensures that devices that set the cap will be
> connected to enforcing domains.
>
> Tested-by: Nicolin Chen
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
Re: [Intel-gfx] [PATCH 04/10] vfio: Move storage of allow_unsafe_interrupts to vfio_main.c
> From: Jason Gunthorpe > Sent: Wednesday, November 9, 2022 9:11 PM > > > If all agree that VFIO_CONTAINER=n is a process to evolve, does it make > > more sense to remove this patch from this series i.e. let it buried in > > VFIO_CONTAINER=y for now? Then resolve it in a follow up patch if > > no consensus can be made quickly at this point. > > This is worse, it would make iommufd completely unusable in situations > where we need allow_unsafe_interrupts. If we belive that is important > we should keep this patch so existing systems on kernels with > VFIO_CONTAINER=y continue to work after libvirt/qemu are upgraded to > iommufd. > You are right. I kept a wrong thought that v2 has moved the option into vfio_main which is what I commented to hold before consensus was made. btw is it a good tradeoff by making vfio-compat as a module to carry this option? anyway it's not necessarily to be in iommufd core when VFIO=n.
Re: [Intel-gfx] [PATCH v2 00/11] Connect VFIO to IOMMUFD
> From: Jason Gunthorpe > Sent: Wednesday, November 9, 2022 8:48 PM > > On Wed, Nov 09, 2022 at 09:03:52AM +, Tian, Kevin wrote: > > every mail in this series is shown thrice in lore: > > > > https://lore.kernel.org/all/0-v2-65016290f146+33e- > vfio_iommufd_...@nvidia.com/ > > > > not sure what caused it but it's annoying to check the conversation there. > > It is sort of a lore issue, it only combines messages that are exactly > the same together. Several of the mailing lists on CC here mangle the > message in various ways, eg adding trailer or whatever. This causes > repeated messages in lore. > > The trick in lore is to replace "/all/" with a good list, like /kvm/ > or /linux-iommu/ that shows the original non-mangled version, and only > once. > this trick works. Thanks!
Re: [Intel-gfx] [PATCH v6 05/20] drm/i915/vm_bind: Implement bind and unbind of object
On Mon, 2022-11-07 at 00:51 -0800, Niranjana Vishwanathapura wrote:
> Add uapi and implement support for bind and unbind of an
> object at the specified GPU virtual addresses.
>
> The vm_bind mode is not supported in legacy execbuf2 ioctl.
> It will be supported only in the newer execbuf3 ioctl.
>
> v2: On older platforms ctx->vm is not set, check for it.
> In vm_bind call, add vma to vm_bind_list.
> Add more input validity checks.
> Update some documentation.
> v3: In vm_bind call, add vma to vm_bound_list as user can
> request a fence and pass to execbuf3 as input fence.
> Remove short term pinning with PIN_VALIDATE flag.
> v4: Replace vm->vm_bind_mode check with i915_gem_vm_is_vm_bind_mode().
> v5: Ensure all reserved fields are 0, use PIN_NOEVICT.
> v6: Add reserved fields to drm_i915_gem_vm_bind.
>
> Reviewed-by: Matthew Auld
> Signed-off-by: Niranjana Vishwanathapura
> Signed-off-by: Prathap Kumar Valsan
> Signed-off-by: Andi Shyti
> ---
> drivers/gpu/drm/i915/Makefile | 1 +
> drivers/gpu/drm/i915/gem/i915_gem_context.h | 15 +
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 5 +
> drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h | 26 ++
> .../drm/i915/gem/i915_gem_vm_bind_object.c| 324 ++
> drivers/gpu/drm/i915/gt/intel_gtt.c | 10 +
> drivers/gpu/drm/i915/gt/intel_gtt.h | 9 +
> drivers/gpu/drm/i915/i915_driver.c| 3 +
> drivers/gpu/drm/i915/i915_vma.c | 1 +
> drivers/gpu/drm/i915/i915_vma_types.h | 14 +
> include/uapi/drm/i915_drm.h | 99 ++
> 11 files changed, 507 insertions(+)
> create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
> create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 51704b54317c..b731f3ac80da 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -166,6 +166,7 @@ gem-y += \
> gem/i915_gem_ttm_move.o \
> gem/i915_gem_ttm_pm.o \
> gem/i915_gem_userptr.o \
> + gem/i915_gem_vm_bind_object.o \
> gem/i915_gem_wait.o \
> gem/i915_gemfs.o
> i915-y += \
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h
> b/drivers/gpu/drm/i915/gem/i915_gem_context.h
> index 899fa8f1e0fe..e8b41aa8f8c4 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
> @@ -139,6 +139,21 @@ int i915_gem_context_setparam_ioctl(struct drm_device
> *dev, void *data,
> int i915_gem_context_reset_stats_ioctl(struct drm_device *dev, void *data,
> struct drm_file *file);
>
>
>
>
> +/**
> + * i915_gem_vm_is_vm_bind_mode() - Check if address space is in vm_bind mode
> + * @vm: the address space
> + *
> + * Returns:
> + * true: @vm is in vm_bind mode; allows only vm_bind method of binding.
> + * false: @vm is not in vm_bind mode; allows only legacy execbuff method
> + *of binding.
> + */
> +static inline bool i915_gem_vm_is_vm_bind_mode(struct i915_address_space *vm)
> +{
> + /* No support to enable vm_bind mode yet */
> + return false;
> +}
> +
> struct i915_address_space *
> i915_gem_vm_lookup(struct drm_i915_file_private *file_priv, u32 id);
>
>
>
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 1160723c9d2d..c5bc9f6e887f 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -781,6 +781,11 @@ static int eb_select_context(struct i915_execbuffer *eb)
> if (unlikely(IS_ERR(ctx)))
> return PTR_ERR(ctx);
>
>
>
>
> + if (ctx->vm && i915_gem_vm_is_vm_bind_mode(ctx->vm)) {
> + i915_gem_context_put(ctx);
> + return -EOPNOTSUPP;
> + }
> +
> eb->gem_context = ctx;
> if (i915_gem_context_has_full_ppgtt(ctx))
> eb->invalid_flags |= EXEC_OBJECT_NEEDS_GTT;
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
> b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
> new file mode 100644
> index ..36262a6357b5
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
> @@ -0,0 +1,26 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright © 2022 Intel Corporation
> + */
> +
> +#ifndef __I915_GEM_VM_BIND_H
> +#define __I915_GEM_VM_BIND_H
> +
> +#include
> +
> +struct drm_device;
> +struct drm_file;
> +struct i915_address_space;
> +struct i915_vma;
> +
> +struct i915_vma *
> +i915_gem_vm_bind_lookup_vma(struct i915_address_space *vm, u64 va);
> +
> +int i915_gem_vm_bind_ioctl(struct drm_device *dev, void *data,
> +struct drm_file *file);
> +int i915_gem_vm_unbind_ioctl(struct drm_device *dev, void *data,
> + struct drm_file *file);
> +
> +void i915_gem_vm_unbind_all(struct i
Re: [Intel-gfx] [PATCH v6 20/20] drm/i915/vm_bind: Async vm_unbind support
On Wed, Nov 09, 2022 at 10:13:36PM +0100, Andi Shyti wrote:
Hi Niranjana,
...
-static void force_unbind(struct i915_vma *vma)
+static void force_unbind(struct i915_vma *vma, bool async)
{
if (!drm_mm_node_allocated(&vma->node))
return;
@@ -1725,7 +1727,21 @@ static void force_unbind(struct i915_vma *vma)
i915_vma_set_purged(vma);
atomic_and(~I915_VMA_PIN_MASK, &vma->flags);
- WARN_ON(__i915_vma_unbind(vma));
+ if (async) {
+ struct dma_fence *fence;
+
+ fence = __i915_vma_unbind_async(vma);
+ if (IS_ERR_OR_NULL(fence)) {
+ async = false;
+ } else {
+ dma_resv_add_fence(vma->obj->base.resv, fence,
+ DMA_RESV_USAGE_READ);
+ dma_fence_put(fence);
+ }
+ }
+
+ if (!async)
+ WARN_ON(__i915_vma_unbind(vma));
GEM_BUG_ON(drm_mm_node_allocated(&vma->node));
}
@@ -1785,7 +1801,7 @@ void i915_vma_destroy_locked(struct i915_vma *vma)
{
lockdep_assert_held(&vma->vm->mutex);
- force_unbind(vma);
+ force_unbind(vma, false);
How about:
#define force_unbind(v) __force_unbind(v, false)
#define force_unbind_async(v) __force_unbind(v, true)
The true/false parameters in a function is not immediately
understandable.
or
#define force_unbind_sync(v)force_unbind(v, false)
#define force_unbind_async(v) force_unbind(v, true)
but I prefer the first version.
Andi, I get the point. But currently, force_unbind() is staic
function with only couple of invocations. These defines seems
an overkill (would be good to define these in header files
if the function is not static). Hope we can keep it as is for now.
Niranjana
Andi
Re: [Intel-gfx] [PATCH v6 00/20] drm/i915/vm_bind: Add VM_BIND functionality
On Mon, 2022-11-07 at 00:51 -0800, Niranjana Vishwanathapura wrote: > 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). Multiple mappings can map > to the same physical pages of an object (aliasing). These mappings (also > referred to as persistent mappings) will be persistent across multiple > GPU submissions (execbuf calls) issued by the UMD, without user having > to provide a list of all required mappings during each submission (as > required by older execbuf mode). > > This patch series support VM_BIND version 1, as described by the param > I915_PARAM_VM_BIND_VERSION. > > Add new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only works in > vm_bind mode. The vm_bind mode only works with this new execbuf3 ioctl. > The new execbuf3 ioctl will not have any execlist support and all the > legacy support like relocations etc., are removed. > > NOTEs: > * It is based on below VM_BIND design+uapi rfc. > Documentation/gpu/rfc/i915_vm_bind.rst Hi One difference for execbuf3 that I noticed that is not mentioned in the RFC document is that we now don't have a way to signal EXEC_OBJECT_WRITE. When looking at the Kernel code, some there are some pieces that check for this flag: - there's code that deals with frontbuffer rendering - there's code that deals with fences - there's code that prevents self-modifying batches - another that seems related to waiting for objects Are there any new rules regarding frontbuffer rendering when we use execbuf3? Any other behavior changes related to the other places that we should expect when using execbuf3? Thanks, Paulo > > * The IGT RFC series is posted as, > [PATCH i-g-t v5 0/12] vm_bind: Add VM_BIND validation support > > v2: Address various review comments > v3: Address review comments and other fixes > v4: Remove vm_unbind out fence uapi which is not supported yet, > replace vm->vm_bind_mode check with i915_gem_vm_is_vm_bind_mode() > v5: Render kernel-doc, use PIN_NOEVICT, limit vm_bind support to > non-recoverable faults > v6: Rebased, minor fixes, add reserved fields to drm_i915_gem_vm_bind, > add new patch for async vm_unbind support > > Signed-off-by: Niranjana Vishwanathapura > > Niranjana Vishwanathapura (20): > drm/i915/vm_bind: Expose vm lookup function > drm/i915/vm_bind: Add __i915_sw_fence_await_reservation() > drm/i915/vm_bind: Expose i915_gem_object_max_page_size() > drm/i915/vm_bind: Add support to create persistent vma > drm/i915/vm_bind: Implement bind and unbind of object > drm/i915/vm_bind: Support for VM private BOs > drm/i915/vm_bind: Add support to handle object evictions > drm/i915/vm_bind: Support persistent vma activeness tracking > drm/i915/vm_bind: Add out fence support > drm/i915/vm_bind: Abstract out common execbuf functions > drm/i915/vm_bind: Use common execbuf functions in execbuf path > drm/i915/vm_bind: Implement I915_GEM_EXECBUFFER3 ioctl > drm/i915/vm_bind: Update i915_vma_verify_bind_complete() > drm/i915/vm_bind: Expose i915_request_await_bind() > drm/i915/vm_bind: Handle persistent vmas in execbuf3 > drm/i915/vm_bind: userptr dma-resv changes > drm/i915/vm_bind: Limit vm_bind mode to non-recoverable contexts > drm/i915/vm_bind: Add uapi for user to enable vm_bind_mode > drm/i915/vm_bind: Render VM_BIND documentation > drm/i915/vm_bind: Async vm_unbind support > > Documentation/gpu/i915.rst| 78 +- > drivers/gpu/drm/i915/Makefile | 3 + > drivers/gpu/drm/i915/gem/i915_gem_context.c | 43 +- > drivers/gpu/drm/i915/gem/i915_gem_context.h | 17 + > drivers/gpu/drm/i915/gem/i915_gem_create.c| 72 +- > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 6 + > .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 516 +-- > .../gpu/drm/i915/gem/i915_gem_execbuffer3.c | 871 ++ > .../drm/i915/gem/i915_gem_execbuffer_common.c | 666 + > .../drm/i915/gem/i915_gem_execbuffer_common.h | 74 ++ > drivers/gpu/drm/i915/gem/i915_gem_ioctls.h| 2 + > drivers/gpu/drm/i915/gem/i915_gem_object.c| 3 + > drivers/gpu/drm/i915/gem/i915_gem_object.h| 2 + > .../gpu/drm/i915/gem/i915_gem_object_types.h | 6 + > drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 19 + > drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h | 30 + > .../drm/i915/gem/i915_gem_vm_bind_object.c| 449 + > drivers/gpu/drm/i915/gt/intel_gtt.c | 17 + > drivers/gpu/drm/i915/gt/intel_gtt.h | 21 + > drivers/gpu/drm/i915/i915_driver.c| 4 + > drivers/gpu/drm/i915/i915_drv.h | 2 + > drivers/gpu/drm/i915/i915_gem_gtt.c | 39 + > drivers/gpu/drm/i915/i915_gem_gtt.h | 3 + > drivers/gpu/drm/i915/i915_getparam.c | 3 + > drivers/gpu/drm/i915/i915_sw_fence.c | 28 +- > drivers/gpu/drm/i915/i915_sw_
[Intel-gfx] linux-next: build failure after merge of the drm-misc tree
Hi all,
After merging the drm-misc tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/gpu/drm/nouveau/nouveau_drm.c: In function 'nouveau_drm_probe':
drivers/gpu/drm/nouveau/nouveau_drm.c:797:17: error: implicit declaration of
function 'drm_fbdev_generic_setup' [-Werror=implicit-function-declaration]
797 | drm_fbdev_generic_setup(drm_dev, 8);
| ^~~
Caused by commit
8ab59da26bc0 ("drm/fb-helper: Move generic fbdev emulation into separate
source file")
interacting with commit
4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers")
from the drm tree.
I have applied the following merge fix patch for today.
From: Stephen Rothwell
Date: Thu, 10 Nov 2022 11:05:52 +1100
Subject: [PATCH] drm-misc: fix up for "drm/fb-helper: Move generic fbdev
emulation into separate source file"
Signed-off-by: Stephen Rothwell
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index a19f18b251f3..80f154b6adab 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
#include
#include
--
2.35.1
--
Cheers,
Stephen Rothwell
pgpToRxZptixi.pgp
Description: OpenPGP digital signature
Re: [Intel-gfx] [PATCH 5/6] drm/i915: Extract VESA DSC bpp alignment to separate function
On Thu, Nov 03, 2022 at 03:21:46PM +0200, Stanislav Lisovskiy wrote:
> We might to use that function separately from intel_dp_dsc_compute_config
> for DP DSC over MST case, because allocating bandwidth in that
> case can be a bit more tricky. So in order to avoid code copy-pasta
> lets extract this to separate function and reuse it for both SST
> and MST cases.
>
> v2: Removed multiple blank lines
>
> Signed-off-by: Stanislav Lisovskiy
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 50 +
> drivers/gpu/drm/i915/display/intel_dp.h | 1 +
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 1 -
> 3 files changed, 32 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 70f4d6422795..8288a30dbd51 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -671,6 +671,36 @@ small_joiner_ram_size_bits(struct drm_i915_private *i915)
> return 6144 * 8;
> }
>
> +u32 intel_dp_dsc_nearest_vesa_bpp(struct drm_i915_private *i915, u32 bpp,
> u32 pipe_bpp)
It makes sense to pull this out into a separate function.
For the function name, we have never had vesa in any of the function
names even though most of these come from vesa spec. So I think we
should remove vesa IMO, just name it as intel_dp_dsc_nearest_valid_bpp
or something?
Manasi
> +{
> + u32 bits_per_pixel = bpp;
> + int i;
> +
> + /* Error out if the max bpp is less than smallest allowed valid bpp */
> + if (bits_per_pixel < valid_dsc_bpp[0]) {
> + drm_dbg_kms(&i915->drm, "Unsupported BPP %u, min %u\n",
> + bits_per_pixel, valid_dsc_bpp[0]);
> + return 0;
> + }
> +
> + /* From XE_LPD onwards we support from bpc upto uncompressed bpp-1 BPPs
> */
> + if (DISPLAY_VER(i915) >= 13) {
> + bits_per_pixel = min(bits_per_pixel, pipe_bpp - 1);
> + } else {
> + /* Find the nearest match in the array of known BPPs from VESA
> */
> + for (i = 0; i < ARRAY_SIZE(valid_dsc_bpp) - 1; i++) {
> + if (bits_per_pixel < valid_dsc_bpp[i + 1])
> + break;
> + }
> + drm_dbg_kms(&i915->drm, "Set dsc bpp from %d to VESA %d\n",
> + bits_per_pixel, valid_dsc_bpp[i]);
> +
> + bits_per_pixel = valid_dsc_bpp[i];
> + }
> +
> + return bits_per_pixel;
> +}
> +
> u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private *i915,
> u32 link_clock, u32 lane_count,
> u32 mode_clock, u32 mode_hdisplay,
> @@ -679,7 +709,6 @@ u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private
> *i915,
> u32 timeslots)
> {
> u32 bits_per_pixel, max_bpp_small_joiner_ram;
> - int i;
>
> /*
>* Available Link Bandwidth(Kbits/sec) = (NumberOfLanes)*
> @@ -712,24 +741,7 @@ u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private
> *i915,
> bits_per_pixel = min(bits_per_pixel, max_bpp_bigjoiner);
> }
>
> - /* Error out if the max bpp is less than smallest allowed valid bpp */
> - if (bits_per_pixel < valid_dsc_bpp[0]) {
> - drm_dbg_kms(&i915->drm, "Unsupported BPP %u, min %u\n",
> - bits_per_pixel, valid_dsc_bpp[0]);
> - return 0;
> - }
> -
> - /* From XE_LPD onwards we support from bpc upto uncompressed bpp-1 BPPs
> */
> - if (DISPLAY_VER(i915) >= 13) {
> - bits_per_pixel = min(bits_per_pixel, pipe_bpp - 1);
> - } else {
> - /* Find the nearest match in the array of known BPPs from VESA
> */
> - for (i = 0; i < ARRAY_SIZE(valid_dsc_bpp) - 1; i++) {
> - if (bits_per_pixel < valid_dsc_bpp[i + 1])
> - break;
> - }
> - bits_per_pixel = valid_dsc_bpp[i];
> - }
> + bits_per_pixel = intel_dp_dsc_nearest_vesa_bpp(i915, bits_per_pixel,
> pipe_bpp);
>
> /*
>* Compressed BPP in U6.4 format so multiply by 16, for Gen 11,
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index c6539a6915e9..0fe10d93b75c 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -120,6 +120,7 @@ static inline unsigned int intel_dp_unused_lane_mask(int
> lane_count)
> }
>
> u32 intel_dp_mode_to_fec_clock(u32 mode_clock);
> +u32 intel_dp_dsc_nearest_vesa_bpp(struct drm_i915_private *i915, u32 bpp,
> u32 pipe_bpp);
>
> void intel_ddi_update_pipe(struct intel_atomic_state *state,
> struct intel_encoder *encoder,
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 61b2bd504e80..8442eea27a57 100644
> --- a/driv
Re: [Intel-gfx] [PATCH] drm/i915/display: mode clock check related to max dotclk frequency
On Wed, Nov 09, 2022 at 12:36:44PM +0200, Jani Nikula wrote: > On Wed, 09 Nov 2022, Nischal Varide wrote: > > A check on mode->clock to see if is greater than i915->max_dotclk_freq > > or greater than 2 * (i915_max_dotclk_freq) in case of big-joiner and > > return an -EINVAL in both the cases > > The commit message should explain *why* the change is being done. > > > > > Signed-off-by: Nischal Varide > > --- > > drivers/gpu/drm/i915/display/intel_dp.c | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c > > b/drivers/gpu/drm/i915/display/intel_dp.c > > index 7400d6b4c587..813f4c369dda 100644 > > --- a/drivers/gpu/drm/i915/display/intel_dp.c > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c > > @@ -995,6 +995,10 @@ intel_dp_mode_valid(struct drm_connector *_connector, > > bigjoiner = true; > > max_dotclk *= 2; > > } > > + > > + if (mode->clock > max_dotclk) > > + return -EINVAL; > > + > > The return type of this function is enum drm_mode_status, which > indicates the reason for rejecting the mode. It's not a negative error > code. > > Near the top of the function we have "target_clock = mode->clock;" > making the above identical to the check we already have below. Apart > from the incorrect return code. > > What are you trying to do? > > BR, > Jani. Yes I agree with Jani here that since target_clock is mode->clock we already have that check in place and infact returing MODE_CLOCK_HIGH makes more sense than returning just a -EINVAL What is the purpose of this change? Manasi > > > > if (target_clock > max_dotclk) > > return MODE_CLOCK_HIGH; > > > > > -- > Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] linux-next: manual merge of the drm-misc tree with the drm tree
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/nouveau/nouveau_fbcon.c
between commit:
4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers")
from the drm tree and commits:
9877d8f6bc37 ("drm/fb_helper: Rename field fbdev to info in struct
drm_fb_helper")
7fd50bc39d12 ("drm/fb-helper: Rename drm_fb_helper_alloc_fbi() to use _info
postfix")
afb0ff78c13c ("drm/fb-helper: Rename drm_fb_helper_unregister_fbi() to use
_info postfix")
from the drm-misc tree.
I fixed it up (I just removed the file) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpeCA3ValoKE.pgp
Description: OpenPGP digital signature
Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: Do both crawl and squash when changing cdclk
> -Original Message-
> From: Ville Syrjälä
> Sent: Wednesday, November 9, 2022 3:30 AM
> To: Roper, Matthew D
> Cc: Srivatsa, Anusha ; intel-
> g...@lists.freedesktop.org; Vivekanandan, Balasubramani
>
> Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: Do both crawl and
> squash when changing cdclk
>
> On Tue, Nov 08, 2022 at 04:24:30PM -0800, Matt Roper wrote:
> > On Tue, Nov 08, 2022 at 03:56:23PM -0800, Srivatsa, Anusha wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: Roper, Matthew D
> > > > Sent: Tuesday, November 8, 2022 3:43 PM
> > > > To: Srivatsa, Anusha
> > > > Cc: intel-gfx@lists.freedesktop.org; Vivekanandan, Balasubramani
> > > >
> > > > Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: Do both
> > > > crawl and squash when changing cdclk
> > > >
> > > > On Fri, Nov 04, 2022 at 03:26:41PM -0700, Anusha Srivatsa wrote:
> > > > > From: Ville Syrjälä
> > > > >
> > > > > For MTL, changing cdclk from between certain frequencies has
> > > > > both squash and crawl. Use the current cdclk config and the
> > > > > new(desired) cdclk config to construtc a mid cdclk config.
> > > > > Set the cdclk twice:
> > > > > - Current cdclk -> mid cdclk
> > > > > - mid cdclk -> desired cdclk
> > > > >
> > > > > v2: Add check in intel_modeset_calc_cdclk() to avoid cdclk
> > > > > change via modeset for platforms that support squash_crawl
> > > > > sequences(Ville)
> > > > >
> > > > > v3: Add checks for:
> > > > > - scenario where only slow clock is used and cdclk is actually 0
> > > > > (bringing up display).
> > > > > - PLLs are on before looking up the waveform.
> > > > > - Squash and crawl capability checks.(Ville)
> > > > >
> > > > > v4: Rebase
> > > > > - Move checks to be more consistent (Ville)
> > > > > - Add comments (Bala)
> > > > > v5:
> > > > > - Further small changes. Move checks around.
> > > > > - Make if-else better looking (Ville)
> > > > >
> > > > > v6: MTl should not follow PUnit mailbox communication as the
> > > > > rest of
> > > > > gen11+ platforms.(Anusha)
> > > > >
> > > > > Cc: Clint Taylor
> > > > > Cc: Balasubramani Vivekanandan
> > > >
> > > > > Signed-off-by: Anusha Srivatsa
> > > > > Signed-off-by: Ville Syrjälä
> > > > > ---
> > > > > drivers/gpu/drm/i915/display/intel_cdclk.c | 161
> > > > > +
> > > > > 1 file changed, 133 insertions(+), 28 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > > index eada931cb1c8..d1e0763513be 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > > @@ -1716,37 +1716,74 @@ static void
> > > > > dg2_cdclk_squash_program(struct
> > > > drm_i915_private *i915,
> > > > > intel_de_write(i915, CDCLK_SQUASH_CTL, squash_ctl); }
> > > > >
> > > > > -static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
> > > > > - const struct intel_cdclk_config *cdclk_config,
> > > > > - enum pipe pipe)
> > > > > +static int cdclk_squash_divider(u16 waveform) {
> > > > > + return hweight16(waveform ?: 0x); }
> > > > > +
> > > > > +static bool cdclk_crawl_and_squash(struct drm_i915_private
> > > > > +*i915,
> > > >
> > > > Bikeshed: maybe name this "cdclk_compute_crawl_squash_midpoint"
> > > > to help clarify that we're just computing stuff here and not
> > > > actually programming the hardware in this function?
> > > >
> > > > That naming would also help clarify why we're returning false if
> > > > we crawl but don't squash or vice versa (i.e., there's no midpoint in
> those cases).
> > >
> > > Makes sense.
> > >
> > > > > +const struct intel_cdclk_config
> > > > *old_cdclk_config,
> > > > > +const struct intel_cdclk_config
> > > > *new_cdclk_config,
> > > > > +struct intel_cdclk_config
> *mid_cdclk_config)
> > > > {
> > > > > + u16 old_waveform, new_waveform, mid_waveform;
> > > > > + int size = 16;
> > > > > + int div = 2;
> > > > > +
> > > > > + /* Return if both Squash and Crawl are not present */
> > > > > + if (!HAS_CDCLK_CRAWL(i915) || !HAS_CDCLK_SQUASH(i915))
> > > > > + return false;
> > > > > +
> > > > > + old_waveform = cdclk_squash_waveform(i915,
> old_cdclk_config-
> > > > >cdclk);
> > > > > + new_waveform = cdclk_squash_waveform(i915,
> new_cdclk_config-
> > > > >cdclk);
> > > > > +
> > > > > + /* Return if Squash only or Crawl only is the desired action */
> > > > > + if (old_cdclk_config->vco <= 0 || new_cdclk_config->vco <= 0
> > > > > +||
> > > >
> > > > Isn't vco unsigned? "== 0" should be fine here I think.
> > >
> > > You mean the new_cdclk_config->vco right?
> >
> > Both of them I think. The vco field of intel_cdclk_config can't take
> > on negative values because it's defined as unsigned:
> >
> >
Re: [Intel-gfx] [PATCH v6 20/20] drm/i915/vm_bind: Async vm_unbind support
Hi Niranjana,
...
> -static void force_unbind(struct i915_vma *vma)
> +static void force_unbind(struct i915_vma *vma, bool async)
> {
> if (!drm_mm_node_allocated(&vma->node))
> return;
> @@ -1725,7 +1727,21 @@ static void force_unbind(struct i915_vma *vma)
> i915_vma_set_purged(vma);
>
> atomic_and(~I915_VMA_PIN_MASK, &vma->flags);
> - WARN_ON(__i915_vma_unbind(vma));
> + if (async) {
> + struct dma_fence *fence;
> +
> + fence = __i915_vma_unbind_async(vma);
> + if (IS_ERR_OR_NULL(fence)) {
> + async = false;
> + } else {
> + dma_resv_add_fence(vma->obj->base.resv, fence,
> +DMA_RESV_USAGE_READ);
> + dma_fence_put(fence);
> + }
> + }
> +
> + if (!async)
> + WARN_ON(__i915_vma_unbind(vma));
> GEM_BUG_ON(drm_mm_node_allocated(&vma->node));
> }
>
> @@ -1785,7 +1801,7 @@ void i915_vma_destroy_locked(struct i915_vma *vma)
> {
> lockdep_assert_held(&vma->vm->mutex);
>
> - force_unbind(vma);
> + force_unbind(vma, false);
How about:
#define force_unbind(v) __force_unbind(v, false)
#define force_unbind_async(v) __force_unbind(v, true)
The true/false parameters in a function is not immediately
understandable.
or
#define force_unbind_sync(v)force_unbind(v, false)
#define force_unbind_async(v) force_unbind(v, true)
but I prefer the first version.
Andi
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/mtl: Media GT and Render GT share common GGTT (rev3)
== Series Details ==
Series: drm/i915/mtl: Media GT and Render GT share common GGTT (rev3)
URL : https://patchwork.freedesktop.org/series/110321/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12363 -> Patchwork_110321v3
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_110321v3 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_110321v3, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v3/index.html
Participating hosts (40 -> 41)
--
Additional (3): bat-dg1-7 fi-rkl-11600 bat-adls-5
Missing(2): fi-ctg-p8600 fi-bdw-samus
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_110321v3:
### IGT changes ###
Possible regressions
* igt@i915_module_load@load:
- bat-dg1-6: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12363/bat-dg1-6/igt@i915_module_l...@load.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v3/bat-dg1-6/igt@i915_module_l...@load.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_parallel@engines@fds:
- {bat-dg2-9}:[PASS][3] -> [FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12363/bat-dg2-9/igt@gem_exec_parallel@engi...@fds.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v3/bat-dg2-9/igt@gem_exec_parallel@engi...@fds.html
* igt@i915_module_load@load:
- {bat-dg1-7}:NOTRUN -> [FAIL][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v3/bat-dg1-7/igt@i915_module_l...@load.html
* igt@i915_selftest@live@gt_timelines:
- {bat-dg2-9}:[PASS][6] -> [INCOMPLETE][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12363/bat-dg2-9/igt@i915_selftest@live@gt_timelines.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v3/bat-dg2-9/igt@i915_selftest@live@gt_timelines.html
- {bat-dg2-8}:[PASS][8] -> [INCOMPLETE][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12363/bat-dg2-8/igt@i915_selftest@live@gt_timelines.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v3/bat-dg2-8/igt@i915_selftest@live@gt_timelines.html
- {bat-dg2-11}: [PASS][10] -> [INCOMPLETE][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12363/bat-dg2-11/igt@i915_selftest@live@gt_timelines.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v3/bat-dg2-11/igt@i915_selftest@live@gt_timelines.html
* igt@i915_selftest@live@workarounds:
- {bat-dg2-11}: [PASS][12] -> [DMESG-FAIL][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12363/bat-dg2-11/igt@i915_selftest@l...@workarounds.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v3/bat-dg2-11/igt@i915_selftest@l...@workarounds.html
- {bat-dg2-9}:[PASS][14] -> [DMESG-FAIL][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12363/bat-dg2-9/igt@i915_selftest@l...@workarounds.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v3/bat-dg2-9/igt@i915_selftest@l...@workarounds.html
- {bat-dg2-8}:[PASS][16] -> [DMESG-FAIL][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12363/bat-dg2-8/igt@i915_selftest@l...@workarounds.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v3/bat-dg2-8/igt@i915_selftest@l...@workarounds.html
Known issues
Here are the changes found in Patchwork_110321v3 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-rkl-11600: NOTRUN -> [SKIP][18] ([i915#2190])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v3/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@parallel-random-engines:
- fi-rkl-11600: NOTRUN -> [SKIP][19] ([i915#4613]) +3 similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v3/fi-rkl-11600/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@gem_tiled_pread_basic:
- fi-rkl-11600: NOTRUN -> [SKIP][20] ([i915#3282])
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v3/fi-rkl-11600/igt@gem_tiled_pread_basic.html
* igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600: NOTRUN -> [SKIP][21] ([i915#3012])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v3/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600:
Re: [Intel-gfx] [PATCH v6 20/20] drm/i915/vm_bind: Async vm_unbind support
On Wed, Nov 09, 2022 at 05:52:54PM +, Matthew Auld wrote:
On Mon, 7 Nov 2022 at 08:53, Niranjana Vishwanathapura
wrote:
Asynchronously unbind the vma upon vm_unbind call.
Fall back to synchronous unbind if backend doesn't support
async unbind or if async unbind fails.
No need for vm_unbind out fence support as i915 will internally
handle all sequencing and user need not try to sequence any
operation with the unbind completion.
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/i915_vma.c | 51 ++---
drivers/gpu/drm/i915/i915_vma.h | 1 +
2 files changed, 48 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 08218e3a2f12..03c966fad87b 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -42,6 +42,8 @@
#include "i915_vma.h"
#include "i915_vma_resource.h"
+static struct dma_fence *__i915_vma_unbind_async(struct i915_vma *vma);
+
static inline void assert_vma_held_evict(const struct i915_vma *vma)
{
/*
@@ -1711,7 +1713,7 @@ void i915_vma_reopen(struct i915_vma *vma)
spin_unlock_irq(>->closed_lock);
}
-static void force_unbind(struct i915_vma *vma)
+static void force_unbind(struct i915_vma *vma, bool async)
{
if (!drm_mm_node_allocated(&vma->node))
return;
@@ -1725,7 +1727,21 @@ static void force_unbind(struct i915_vma *vma)
i915_vma_set_purged(vma);
atomic_and(~I915_VMA_PIN_MASK, &vma->flags);
- WARN_ON(__i915_vma_unbind(vma));
+ if (async) {
+ struct dma_fence *fence;
+
+ fence = __i915_vma_unbind_async(vma);
+ if (IS_ERR_OR_NULL(fence)) {
+ async = false;
+ } else {
+ dma_resv_add_fence(vma->obj->base.resv, fence,
+ DMA_RESV_USAGE_READ);
+ dma_fence_put(fence);
+ }
+ }
+
+ if (!async)
+ WARN_ON(__i915_vma_unbind(vma));
GEM_BUG_ON(drm_mm_node_allocated(&vma->node));
}
@@ -1785,7 +1801,7 @@ void i915_vma_destroy_locked(struct i915_vma *vma)
{
lockdep_assert_held(&vma->vm->mutex);
- force_unbind(vma);
+ force_unbind(vma, false);
list_del_init(&vma->vm_link);
release_references(vma, vma->vm->gt, false);
}
@@ -1796,7 +1812,34 @@ void i915_vma_destroy(struct i915_vma *vma)
bool vm_ddestroy;
mutex_lock(&vma->vm->mutex);
- force_unbind(vma);
+ force_unbind(vma, false);
+ list_del_init(&vma->vm_link);
+ vm_ddestroy = vma->vm_ddestroy;
+ vma->vm_ddestroy = false;
+
+ /* vma->vm may be freed when releasing vma->vm->mutex. */
+ gt = vma->vm->gt;
+ mutex_unlock(&vma->vm->mutex);
+ release_references(vma, gt, vm_ddestroy);
+}
+
+void i915_vma_destroy_async(struct i915_vma *vma)
Where are we calling this? I can't find it.
Ah, got missed out in this patch. It should be called from vm_unbind
path. Will fix it.
Thanks,
Niranjana
+{
+ bool vm_ddestroy, async = vma->obj->mm.rsgt;
+ struct intel_gt *gt;
+
+ if (dma_resv_reserve_fences(vma->obj->base.resv, 1))
+ async = false;
+
+ mutex_lock(&vma->vm->mutex);
+ /*
+* Ensure any asynchronous binding is complete while using
+* async unbind as we will be releasing the vma here.
+*/
+ if (async && i915_active_wait(&vma->active))
+ async = false;
+
+ force_unbind(vma, async);
list_del_init(&vma->vm_link);
vm_ddestroy = vma->vm_ddestroy;
vma->vm_ddestroy = false;
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index 737ef310d046..25f15965dab8 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -272,6 +272,7 @@ void i915_vma_reopen(struct i915_vma *vma);
void i915_vma_destroy_locked(struct i915_vma *vma);
void i915_vma_destroy(struct i915_vma *vma);
+void i915_vma_destroy_async(struct i915_vma *vma);
#define assert_vma_held(vma) dma_resv_assert_held((vma)->obj->base.resv)
--
2.21.0.rc0.32.g243a4c7e27
Re: [Intel-gfx] [PATCH 1/2] drm/i915/gt: Add GT oriented dmesg output
On 09.11.2022 18:46, John Harrison wrote:
> On 11/9/2022 03:05, Tvrtko Ursulin wrote:
>> On 08/11/2022 20:15, John Harrison wrote:
>>> On 11/8/2022 01:01, Tvrtko Ursulin wrote:
On 07/11/2022 19:14, John Harrison wrote:
> On 11/7/2022 08:17, Tvrtko Ursulin wrote:
>> On 07/11/2022 09:33, Tvrtko Ursulin wrote:
>>> On 05/11/2022 01:03, Ceraolo Spurio, Daniele wrote:
On 11/4/2022 10:25 AM, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> When trying to analyse bug reports from CI, customers, etc. it
> can be
> difficult to work out exactly what is happening on which GT in a
> multi-GT system. So add GT oriented debug/error message
> wrappers. If
> used instead of the drm_ equivalents, you get the same output
> but with
> a GT# prefix on it.
>
> Signed-off-by: John Harrison
The only downside to this is that we'll print "GT0: " even on
single-GT devices. We could introduce a gt->info.name and print
that, so we could have it different per-platform, but IMO it's
not worth the effort.
Reviewed-by: Daniele Ceraolo Spurio
I think it might be worth getting an ack from one of the
maintainers to make sure we're all aligned on transitioning to
these new logging macro for gt code.
>>>
>>> Idea is I think a very good one. First I would suggest
>>> standardising to lowercase GT in logs because:
>>>
>>> $ grep "GT%" i915/ -r
>>> $ grep "gt%" i915/ -r
>>> i915/gt/intel_gt_sysfs.c: gt->i915->sysfs_gt, "gt%d", gt->info.id))
>>> i915/gt/intel_gt_sysfs.c: "failed to initialize
>>> gt%d sysfs root\n", gt->info.id);
>>> i915/gt/intel_gt_sysfs_pm.c: "failed to
>>> create gt%u RC6 sysfs files (%pe)\n",
>>> i915/gt/intel_gt_sysfs_pm.c: "failed to create gt%u RC6p sysfs
>>> files (%pe)\n",
>>> i915/gt/intel_gt_sysfs_pm.c: "failed to
>>> create gt%u RPS sysfs files (%pe)",
>>> i915/gt/intel_gt_sysfs_pm.c: "failed to
>>> create gt%u punit_req_freq_mhz sysfs (%pe)",
>>> i915/gt/intel_gt_sysfs_pm.c: "failed to create gt%u throttle
>>> sysfs files (%pe)",
>>> i915/gt/intel_gt_sysfs_pm.c: "failed to create gt%u
>>> media_perf_power_attrs sysfs (%pe)\n",
>>> i915/gt/intel_gt_sysfs_pm.c: "failed to add
>>> gt%u rps defaults (%pe)\n",
>>> i915/i915_driver.c: drm_err(>->i915->drm, "gt%d:
>>> intel_pcode_init failed %d\n", id, ret);
>>> i915/i915_hwmon.c: snprintf(ddat_gt->name, sizeof(ddat_gt->name),
>>> "i915_gt%u", i);
>>>
>
> Just because there are 11 existing instances of one form doesn't
> mean that the 275 instances that are waiting to be converted should
> be done incorrectly. GT is an acronym and should be capitalised.
Okay just make it consistent then.
> Besides:
> grep -r "GT " i915 | grep '"'
> i915/vlv_suspend.c: drm_err(&i915->drm, "timeout
> disabling GT waking\n");
> i915/vlv_suspend.c: "timeout waiting for GT
> wells to go %s\n",
> i915/vlv_suspend.c: drm_dbg(&i915->drm, "GT register access
> while GT waking disabled\n");
> i915/i915_gpu_error.c: err_printf(m, "GT awake: %s\n",
> str_yes_no(gt->awake));
> i915/i915_debugfs.c: seq_printf(m, "GT awake? %s [%d], %llums\n",
> i915/selftests/i915_gem_evict.c: pr_err("Failed to idle GT (on
> %s)", engine->name);
> i915/intel_uncore.c: "GT thread status wait timed
> out\n");
> i915/gt/uc/selftest_guc_multi_lrc.c: drm_err(>->i915->drm, "GT
> failed to idle: %d\n", ret);
> i915/gt/uc/selftest_guc.c: drm_err(>->i915->drm, "GT failed to
> idle: %d\n", ret);
> i915/gt/uc/selftest_guc.c: drm_err(>->i915->drm, "GT failed to
> idle: %d\n", ret);
> i915/gt/intel_gt_mcr.c: * Some GT registers are designed as
> "multicast" or "replicated" registers:
> i915/gt/selftest_rps.c: pr_info("%s: rps counted %d
> C0 cycles [%lldns] in %lldns [%d cycles], using GT clock frequency
> of %uKHz\n",
> i915/gt/selftest_hangcheck.c: pr_err("[%s] GT is
> wedged!\n", engine->name);
> i915/gt/selftest_hangcheck.c: pr_err("GT is wedged!\n");
> i915/gt/intel_gt_clock_utils.c: "GT clock frequency
> changed, was %uHz, now %uHz!\n",
> i915/gt/selftest_engine_pm.c: pr_err("Unable to flush GT
> pm before test\n");
> i915/gt/selftest_engine_pm.c: pr_err("GT failed to idle\n");
> i915/i915_sysfs.c: "failed to register GT
> sysfs directory\n");
> i915/intel_uncore.h: * of the basic non-engine GT registers
> (referred to as "GSI" on
> i915/intel_uncor
Re: [Intel-gfx] [PATCH v2 10/11] vfio: Make vfio_container optionally compiled
On Wed, Nov 09, 2022 at 10:18:09AM -0700, Alex Williamson wrote:
> DPDK supports no-iommu mode.
Er? Huh? How? I thought no-iommu was for applications that didn't do
DMA? How is DPDK getting packets in/out without DMA? I guess it snoops
in /proc/ or something to learn PFNs of mlock'd memory?
> I agree that it's very useful for testing, I'm certainly not suggesting
> to give up, but I'm not sure where no-iommu lives when iommufd owns
> /dev/vfio/vfio. Given the unsafe interrupts discussion, it doesn't
> seem like the type of thing that would be a priority for iommufd.
Ah, I think the bit below will do the job, I'm not sure without doing
some testing (and I don't think I have the necessary Intel NIC for
DPDK). The basic point is no-iommu literally means 'do not use iommufd
at all, do not create an iommufd_device or an iommufd_access'. VFIO
can easially do that on its own.
The only slightly messy bit is that uAPI requires the SET_CONTAINER
which we can just NOP in vfio_compat. With more checks it could have
higher fidelity of error cases, but not sure it is worth it.
When we talk about the device cdev flow then I suggest that no-iommu
simply requires -1 for the iommufd during bind - ie no iommufd is
used or accepted and that is how the userspace knows/confirms it is in
no-iommu mode.
> We're on a path where vfio accepts an iommufd as a container, and
> ultimately iommufd becomes the container provider, supplanting the
> IOMMU driver registration aspect of vfio. I absolutely want type1 and
> spapr backends to get replaced by iommufd, but reluctance to support
> aspects of vfio "legacy" behavior doesn't give me warm fuzzies about a
> wholesale hand-off of the container to a different subsystem, for
> example vs an iommufd shim spoofing type1 support.
Well, I will agree to do everything required, just let's go through the
process to understand the security situation and ensure we are still
doing things the right way.
> Unfortunately we no longer have a CONFIG_EXPERIMENTAL option to hide
> behind for disabling VFIO_CONTAINER, so regardless of our intentions
> that a transition is some time off, it may become an issue sooner than
> we expect.
We can add kconfig text discouraging that?
diff --git a/drivers/iommu/iommufd/vfio_compat.c
b/drivers/iommu/iommufd/vfio_compat.c
index dbef3274803336..81f7594cfff8e0 100644
--- a/drivers/iommu/iommufd/vfio_compat.c
+++ b/drivers/iommu/iommufd/vfio_compat.c
@@ -259,6 +259,14 @@ static int iommufd_vfio_set_iommu(struct iommufd_ctx
*ictx, unsigned long type)
struct iommufd_ioas *ioas = NULL;
int rc = 0;
+ /*
+* Emulation for NOIMMU is imperfect in that VFIO blocks almost all
+* other ioctls. We let them keep working but they mostly fail since no
+* IOAS should exist.
+*/
+ if (IS_ENABLED(CONFIG_VFIO_NOIOMMU) && type == VFIO_NOIOMMU_IOMMU)
+ return 0;
+
if (type != VFIO_TYPE1_IOMMU && type != VFIO_TYPE1v2_IOMMU)
return -EINVAL;
diff --git a/drivers/vfio/iommufd.c b/drivers/vfio/iommufd.c
index 595c7b2146f88c..64a336ebc99b9f 100644
--- a/drivers/vfio/iommufd.c
+++ b/drivers/vfio/iommufd.c
@@ -18,6 +18,10 @@ int vfio_iommufd_bind(struct vfio_device *vdev, struct
iommufd_ctx *ictx)
lockdep_assert_held(&vdev->dev_set->lock);
+ if (IS_ENABLED(CONFIG_VFIO_NO_IOMMU) &&
+ vdev->group->type == VFIO_NO_IOMMU)
+ return 0;
+
/*
* If the driver doesn't provide this op then it means the device does
* not do DMA at all. So nothing to do.
@@ -53,6 +57,10 @@ void vfio_iommufd_unbind(struct vfio_device *vdev)
{
lockdep_assert_held(&vdev->dev_set->lock);
+ if (IS_ENABLED(CONFIG_VFIO_NO_IOMMU) &&
+ vdev->group->type == VFIO_NO_IOMMU)
+ return;
+
if (vdev->ops->unbind_iommufd)
vdev->ops->unbind_iommufd(vdev);
}
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index f3c48b8c45627d..08c5b05a129c2c 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -749,10 +749,13 @@ static int vfio_group_ioctl_set_container(struct
vfio_group *group,
if (!IS_ERR(iommufd)) {
u32 ioas_id;
- ret = iommufd_vfio_compat_ioas_id(iommufd, &ioas_id);
- if (ret) {
- iommufd_ctx_put(group->iommufd);
- goto out_unlock;
+ if (!IS_ENABLED(CONFIG_VFIO_NO_IOMMU) ||
+ group->type != VFIO_NO_IOMMU) {
+ ret = iommufd_vfio_compat_ioas_id(iommufd, &ioas_id);
+ if (ret) {
+ iommufd_ctx_put(group->iommufd);
+ goto out_unlock;
+ }
}
group->iommufd = iommufd;
[Intel-gfx] ✓ Fi.CI.BAT: success for Add selftest for slpc tile interaction (rev4)
== Series Details ==
Series: Add selftest for slpc tile interaction (rev4)
URL : https://patchwork.freedesktop.org/series/110248/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12363 -> Patchwork_110248v4
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110248v4/index.html
Participating hosts (40 -> 36)
--
Missing(4): fi-ctg-p8600 fi-hsw-4770 fi-cfl-guc fi-bdw-samus
Known issues
Here are the changes found in Patchwork_110248v4 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_gttfill@basic:
- fi-pnv-d510:[PASS][1] -> [FAIL][2] ([i915#7229])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12363/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110248v4/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-apl-guc: NOTRUN -> [SKIP][3] ([fdo#109271] / [fdo#111827])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110248v4/fi-apl-guc/igt@kms_chamel...@common-hpd-after-suspend.html
- fi-rkl-guc: NOTRUN -> [SKIP][4] ([fdo#111827])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110248v4/fi-rkl-guc/igt@kms_chamel...@common-hpd-after-suspend.html
Possible fixes
* igt@i915_selftest@live@gt_timelines:
- fi-apl-guc: [INCOMPLETE][5] -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12363/fi-apl-guc/igt@i915_selftest@live@gt_timelines.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110248v4/fi-apl-guc/igt@i915_selftest@live@gt_timelines.html
* igt@i915_selftest@live@hangcheck:
- fi-rkl-guc: [INCOMPLETE][7] ([i915#4983]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12363/fi-rkl-guc/igt@i915_selftest@l...@hangcheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110248v4/fi-rkl-guc/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@slpc:
- {bat-rplp-1}: [DMESG-FAIL][9] ([i915#6367]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12363/bat-rplp-1/igt@i915_selftest@l...@slpc.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110248v4/bat-rplp-1/igt@i915_selftest@l...@slpc.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6434]: https://gitlab.freedesktop.org/drm/intel/issues/6434
[i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
[i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229
[i915#7346]: https://gitlab.freedesktop.org/drm/intel/issues/7346
Build changes
-
* Linux: CI_DRM_12363 -> Patchwork_110248v4
CI-20190529: 20190529
CI_DRM_12363: 28f3fbf3ad9cc809521c7a308e29dfc27c445730 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7049: 790ed4ea5e08969979cfe5b25e428e4a0ba148c2 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_110248v4: 28f3fbf3ad9cc809521c7a308e29dfc27c445730 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
132a56588f64 drm/i915/guc/slpc: Add selftest for slpc tile-tile interaction
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110248v4/index.html
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fake dual eDP VBT fixes
== Series Details == Series: drm/i915: Fake dual eDP VBT fixes URL : https://patchwork.freedesktop.org/series/110693/ State : success == Summary == CI Bug Log - changes from CI_DRM_12360_full -> Patchwork_110693v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (11 -> 11) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_110693v1_full that come from known issues: ### CI changes ### Possible fixes * boot: - shard-apl: ([FAIL][1], [PASS][2], [PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25]) ([i915#4386]) -> ([PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-apl1/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-apl1/boot.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-apl1/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-apl1/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-apl2/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-apl2/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-apl2/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-apl2/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-apl3/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-apl3/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-apl3/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-apl3/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-apl3/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-apl6/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-apl6/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-apl6/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-apl6/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-apl7/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-apl7/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-apl7/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-apl7/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-apl8/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-apl8/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-apl8/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-apl8/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110693v1/shard-apl6/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110693v1/shard-apl7/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110693v1/shard-apl7/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110693v1/shard-apl7/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110693v1/shard-apl8/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110693v1/shard-apl8/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110693v1/shard-apl8/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110693v1/shard-apl8/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110693v1/shard-apl1/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110693v1/shard-apl1/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110693v1/shard-apl1/boot.html [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110693v1/shard-apl1/boot.html [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110693v1/shard-apl2/boot.html [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110693v1/shard-apl2/boot.html [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110693v1/shard-apl2/boot.html [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110693v1/shard-apl2/boot.html [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110693v1/shard-apl2/boot.html [43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110693v1/shard-apl3/bo
[Intel-gfx] ✗ Fi.CI.DOCS: warning for Add selftest for slpc tile interaction (rev4)
== Series Details == Series: Add selftest for slpc tile interaction (rev4) URL : https://patchwork.freedesktop.org/series/110248/ State : warning == Summary == Error: make htmldocs had i915 warnings ./drivers/gpu/drm/i915/i915_perf_types.h:319: warning: Function parameter or member 'lock' not described in 'i915_perf_stream'
[Intel-gfx] [PATCH 3/3] drm/i915: Fix 0 return value from DMA fence wait on i915 requests
According to the docs, dma_fence_wait_timeout() returns "0 if the wait
timed out," ... "Other error values may be returned on custom
implementations." While it is not quite clear if a custom implementation
is allowed to return "other error" instead of 0, it is rather clear that 0
return value should always mean that the wait timed out before the fence
got signaled.
i915 implementation of dma_fence_ops.wait() used with request fences,
which is a transparent wrapper around i915_request_wait_timeout(), returns
-ETIME if the wait has timed out -- that may be considered as acceptable.
However, it can return 0 in a rare case when the fence has been found
signaled right after no more wait time was left, and that's not compatible
with expectations of dma-fence and its users.
Since other users of i915_request_wait_timeout() may interpret 0 return
value as success, don't touch it, update the i915_fence_wait() wrapper
instead. Return 1 instead of 0, but keep -ETIME in case of timeout since
some i915 users of dma_fence_wait_timeout() may expect it.
Signed-off-by: Janusz Krzysztofik
---
drivers/gpu/drm/i915/i915_request.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index f949a9495758a..451456ab1ddef 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -102,7 +102,7 @@ static signed long i915_fence_wait(struct dma_fence *fence,
{
return i915_request_wait_timeout(to_request(fence),
interruptible | I915_WAIT_PRIORITY,
-timeout);
+timeout) ?: 1;
}
struct kmem_cache *i915_request_slab_cache(void)
--
2.25.1
[Intel-gfx] [PATCH 2/3] drm/i915: Fix unintended submission flush after retire times out
If wait on request DMA fence times out while we are retiring requests,
-ETIME is stored as remaining time. Then, flush_submission() called
thereafter proceeds with its work instead of returning immediately due to
the value of timeout passed to it not equal 0. That's probably not what
was intended.
Fix it by replacing -ETIME value of the argument with 0.
Fixes: 09137e945437 ("drm/i915/gem: Unpin idle contexts from kswapd reclaim")
Signed-off-by: Janusz Krzysztofik
---
drivers/gpu/drm/i915/gt/intel_gt_requests.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
index 6c3b8ac3055c3..309d5937d6910 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
@@ -204,7 +204,7 @@ out_active: spin_lock(&timelines->lock);
list_for_each_entry_safe(tl, tn, &free, link)
__intel_timeline_free(&tl->kref);
- if (flush_submission(gt, timeout)) /* Wait, there's more! */
+ if (flush_submission(gt, timeout > 0)) /* Wait, there's more! */
active_count++;
if (remaining_timeout)
--
2.25.1
[Intel-gfx] [PATCH 1/3] drm/i915: Fix timeout handling when retiring requests
I believe that intel_gt_retire_requests_timeout() should return either
-ETIME if all time designated by timeout argument has been consumed while
waiting for fences being signaled, or remaining time if there are requests
still not retired, or 0 otherwise. In the latter case, remaining time
should be passed back via remaining_timeout argument.
Remaining time is updated with return value of each consecutive call to
dma_fence_wait_timeout(). If an error code is returned instead of
remaining time, a few potentially unexpected side effects occur:
- we no longer wait for consecutive timelines' last request fences being
signaled before we try to retire requests from those timelines -- while
expected in case of -ETIME, that's probably not intended in case of
other errors that dma_fence_wait_timeout() can return,
- the error code (a negative value) is passed back as remaining time and
if no more requests happen to be left pending despite the error, a user
may pass that value forward as a remaining timeout -- that can
potentially trigger a WARN or BUG,
- potentially unexpected error code is returned to user when a
non-critical error that probably shouldn't stop the user from retrying
occurs while active requests are still pending.
Moreover, should dma_fence_wait_timeout() ever return 0 (which should mean
timeout expiration) while we are processing requests and there are still
pending requests when we are about to return, that 0 value is returned to
user like if all requests were successfully retired.
Ignore error codes from dma_fence_wait_timeout() other than -ETIME and
don't overwrite remaining time with those error codes. Also, convert 0
value returned by dma_fence_wait_timeout() to -ETIME.
Fixes: f33a8a51602c ("drm/i915: Merge wait_for_timelines with retire_request")
Signed-off-by: Janusz Krzysztofik
Cc: sta...@vger.kernel.org # v5.5+
---
drivers/gpu/drm/i915/gt/intel_gt_requests.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
index edb881d756309..6c3b8ac3055c3 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
@@ -156,11 +156,22 @@ long intel_gt_retire_requests_timeout(struct intel_gt
*gt, long timeout,
fence = i915_active_fence_get(&tl->last_request);
if (fence) {
+ signed long time_left;
+
mutex_unlock(&tl->mutex);
- timeout = dma_fence_wait_timeout(fence,
-true,
-timeout);
+ time_left = dma_fence_wait_timeout(fence,
+ true,
+ timeout);
+ /*
+* 0 or -ETIME: timeout expired
+* other errors: ignore, assume no time consumed
+*/
+ if (time_left == -ETIME || time_left == 0)
+ timeout = -ETIME;
+ else if (time_left > 0)
+ timeout = time_left;
+
dma_fence_put(fence);
/* Retirement is best effort */
--
2.25.1
[Intel-gfx] [PATCH 0/3] Fix timeout handling when retiring requests
Fixes for issues discovered via code review while working on https://gitlab.freedesktop.org/drm/intel/issues/7349. Janusz Krzysztofik (3): drm/i915: Fix timeout handling when retiring requests drm/i915: Fix unintended submission flush after retire times out drm/i915: Fix 0 return value from DMA fence wait on i915 requests drivers/gpu/drm/i915/gt/intel_gt_requests.c | 19 +++ drivers/gpu/drm/i915/i915_request.c | 2 +- 2 files changed, 16 insertions(+), 5 deletions(-) -- 2.25.1
Re: [Intel-gfx] [PATCH 04/10] vfio: Move storage of allow_unsafe_interrupts to vfio_main.c
On Tue, 8 Nov 2022 21:05:21 -0400 Jason Gunthorpe wrote: > On Tue, Nov 08, 2022 at 03:55:20PM -0700, Alex Williamson wrote: > > > > > So why exactly isn't this an issue for VDPA? Are we just burying our > > > > head in the sand that such platforms exists and can still be useful > > > > given the appropriate risk vs reward trade-off? > > > > > > Simply that nobody has asked for it, and might never ask for it. This > > > is all support for old platforms, and there just doesn't seem to be a > > > "real" use case for very new (and actually rare) NIC hardware stuck > > > into ancient platforms with this security problem. > > > > vIOMMU support for interrupt remapping is relatively new, the nesting > > case is important as well. > > This is where we got hit. In the end we fixed the qemu.. > > > > I'd be much more comfortable with this as a system wide iommufd flag > > > if we also tied it to do some demonstration of privilege - eg a > > > requirement to open iommufd with CAP_SYS_RAWIO for instance. > > > > Which is not compatible to existing use cases, which is also why we > > can't invent some way to allow some applications to run without CPU > > mitigations, while requiring it for others as a baseline. > > Isn't it? Didn't we learn that libvirt runs as root and will open and > pass the iommufd as root? We're jumping ahead to native iommufd support here, what happens when VFIO_CONTAINER=n and it's QEMU opening the fds, with only file access privileges? > > > That is the usual protocol for these kinds of insecurities.. > > > > Hmm, is it? > > I think so. At least you should have something to shut down an > insecure feature in kernel lockdown modes. CAP_SYS_RAWIO is a simple > way to do it. How are CPU vulnerabilities handled in lockdown mode, do apps require certain capabilities to run fast vs safe, or do we simply disallow unsafe globally in lockdown? I think we have a lot more leniency to ignore/disallow flags that enable global insecurities when any sort of lockdown is imposed. > > > I think right now we can leave this as-is and we can wait for some > > > more information to decide how best to proceed. > > > > It's certainly not acceptable in the latest proposal, iommufd consumes > > an option set by another module and when that module goes away, so does > > any claim of compatibility. The code becomes dead and the feature not > > present. The option doesn't belong on the vfio module. Do we need a > > vfio-iommufd module to host it? Thanks, > > I don't know, as I said in the other email, these little things need > work and discussion to resolve. We need to recheck the security stuff > against the 2022 kernel where things have changed. We don't need to do > it all right now. > > People who want allow_unsafe_interrupts to work will simply not set > VFIO_CONTAINER=n at this time. Same with P2P, vfio-no-iommu and any > other gaps we haven't discovered. > > vfio-iommufd seems like overkill, I think your first suggestion to put > in vfio.ko was more practical. Convenient perhaps, but architecturally the wrong place for it. > My only doubt is if we should make it system wide for everything - and > I'm just a bit uncomfortable with that from a security POV. But maybe > I don't quite know exactly what the risks are. There's a paper about these sorts of attacks here[1]. As I noted earlier, a non-malicious DMA targeting an address that would trigger an interrupt is extremely unlikely, and the resulting vulnerability is largely more of a denial of service, IIRC. It would certainly be strongly dis-recommended in any scenario where the userspace drivers are untrusted, such as a cloud hosting provider, but there are certainly other scenarios where either the guest or userspace drivers are also under the control of the hosting provider and this is not such a concern. Thanks, Alex [1]https://invisiblethingslab.com/resources/2011/Software%20Attacks%20on%20Intel%20VT-d.pdf
Re: [Intel-gfx] [PATCH 0/3] add guard padding around i915_vma
Hi Thomas, On Wed, Nov 09, 2022 at 07:03:03PM +0100, Thomas Hellström wrote: > Hi, Andi, > > This has been on the list before (three times I think) and at that > point it (the guard pages) was NAK'd by Daniel as yet another > complication, and a VT-d > scanout workaround was implemented and pushed using a different > approach, initially outlined by Daniel. > > Patch is 2ef6efa79fecd. Those suspend/resumes should now be fast. > > I then also discussed patch 1 separately with Dave Airlie and Daniel > and since both me and Dave liked it, Daniel OK'd it, but it never made > it upstream. > > Just a short heads up on the history. Thanks for letting me know, I missed this part of the history. Will check what happened in the previous mails and your improvement on the vt-d suspend/resume. Thanks, Andi
Re: [Intel-gfx] [PATCH 0/3] add guard padding around i915_vma
Hi, Andi, This has been on the list before (three times I think) and at that point it (the guard pages) was NAK'd by Daniel as yet another complication, and a VT-d scanout workaround was implemented and pushed using a different approach, initially outlined by Daniel. Patch is 2ef6efa79fecd. Those suspend/resumes should now be fast. I then also discussed patch 1 separately with Dave Airlie and Daniel and since both me and Dave liked it, Daniel OK'd it, but it never made it upstream. Just a short heads up on the history. /Thomas On Wed, 2022-11-09 at 18:40 +0100, Andi Shyti wrote: > Hi, > > This series adds guards around vma's but setting a pages at the > beginning and at the end that work as padding. > > The first user of the vma guard are scanout objects which don't > need anymore to add scratch to all the unused ggtt's and speeding > up up considerably the boot and resume by several hundreds of > milliseconds up to over a full second in slower machines. > > Andi > > Chris Wilson (3): > drm/i915: Wrap all access to i915_vma.node.start|size > drm/i915: Introduce guard pages to i915_vma > drm/i915: Refine VT-d scanout workaround > > drivers/gpu/drm/i915/display/intel_fbdev.c | 2 +- > drivers/gpu/drm/i915/gem/i915_gem_domain.c | 13 > .../gpu/drm/i915/gem/i915_gem_execbuffer.c | 33 ++- > drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +- > drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 2 +- > drivers/gpu/drm/i915/gem/i915_gem_tiling.c | 4 +- > .../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +- > .../i915/gem/selftests/i915_gem_client_blt.c | 23 > .../drm/i915/gem/selftests/i915_gem_context.c | 15 +++-- > .../drm/i915/gem/selftests/i915_gem_mman.c | 2 +- > .../drm/i915/gem/selftests/igt_gem_utils.c | 7 ++- > drivers/gpu/drm/i915/gt/gen7_renderclear.c | 2 +- > drivers/gpu/drm/i915/gt/intel_ggtt.c | 39 > drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 3 +- > drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +- > .../gpu/drm/i915/gt/intel_ring_submission.c | 2 +- > drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 8 +-- > drivers/gpu/drm/i915/gt/selftest_execlists.c | 18 +++--- > drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 15 ++--- > drivers/gpu/drm/i915/gt/selftest_lrc.c | 16 ++--- > .../drm/i915/gt/selftest_ring_submission.c | 2 +- > drivers/gpu/drm/i915/gt/selftest_rps.c | 12 ++-- > .../gpu/drm/i915/gt/selftest_workarounds.c | 8 +-- > drivers/gpu/drm/i915/i915_cmd_parser.c | 4 +- > drivers/gpu/drm/i915/i915_debugfs.c | 2 +- > drivers/gpu/drm/i915/i915_gem_gtt.h | 3 +- > drivers/gpu/drm/i915/i915_perf.c | 2 +- > drivers/gpu/drm/i915/i915_vma.c | 59 + > -- > drivers/gpu/drm/i915/i915_vma.h | 52 +++- > drivers/gpu/drm/i915/i915_vma_resource.c | 4 +- > drivers/gpu/drm/i915/i915_vma_resource.h | 17 -- > drivers/gpu/drm/i915/i915_vma_types.h | 3 +- > drivers/gpu/drm/i915/selftests/i915_request.c | 20 +++ > drivers/gpu/drm/i915/selftests/igt_spinner.c | 8 +-- > 34 files changed, 246 insertions(+), 160 deletions(-) >
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Partial abandonment of legacy DRM logging macros (rev3)
== Series Details == Series: drm/i915: Partial abandonment of legacy DRM logging macros (rev3) URL : https://patchwork.freedesktop.org/series/110660/ State : success == Summary == CI Bug Log - changes from CI_DRM_12360_full -> Patchwork_110660v3_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_110660v3_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_110660v3_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (11 -> 11) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_110660v3_full: ### IGT changes ### Warnings * igt@dmabuf@all@dma_fence_chain: - shard-skl: [INCOMPLETE][1] ([i915#6949]) -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-skl4/igt@dmabuf@all@dma_fence_chain.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110660v3/shard-skl7/igt@dmabuf@all@dma_fence_chain.html Known issues Here are the changes found in Patchwork_110660v3_full that come from known issues: ### CI changes ### Issues hit * boot: - shard-glk: ([PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27]) -> ([PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [FAIL][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50], [PASS][51], [PASS][52]) ([i915#4392]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-glk1/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-glk5/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-glk3/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-glk3/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-glk3/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-glk2/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-glk2/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-glk2/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-glk1/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-glk1/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-glk9/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-glk9/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-glk9/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-glk9/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-glk8/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-glk8/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-glk8/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-glk8/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-glk7/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-glk7/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-glk6/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-glk6/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-glk6/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-glk5/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/shard-glk5/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110660v3/shard-glk8/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110660v3/shard-glk7/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110660v3/shard-glk7/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110660v3/shard-glk7/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110660v3/shard-glk6/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110660v3/shard-glk6/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110660v3/shard-glk6/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110660v3/shard-glk5/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/
Re: [Intel-gfx] [PATCH v6 20/20] drm/i915/vm_bind: Async vm_unbind support
On Mon, 7 Nov 2022 at 08:53, Niranjana Vishwanathapura
wrote:
>
> Asynchronously unbind the vma upon vm_unbind call.
> Fall back to synchronous unbind if backend doesn't support
> async unbind or if async unbind fails.
>
> No need for vm_unbind out fence support as i915 will internally
> handle all sequencing and user need not try to sequence any
> operation with the unbind completion.
>
> Signed-off-by: Niranjana Vishwanathapura
> ---
> drivers/gpu/drm/i915/i915_vma.c | 51 ++---
> drivers/gpu/drm/i915/i915_vma.h | 1 +
> 2 files changed, 48 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
> index 08218e3a2f12..03c966fad87b 100644
> --- a/drivers/gpu/drm/i915/i915_vma.c
> +++ b/drivers/gpu/drm/i915/i915_vma.c
> @@ -42,6 +42,8 @@
> #include "i915_vma.h"
> #include "i915_vma_resource.h"
>
> +static struct dma_fence *__i915_vma_unbind_async(struct i915_vma *vma);
> +
> static inline void assert_vma_held_evict(const struct i915_vma *vma)
> {
> /*
> @@ -1711,7 +1713,7 @@ void i915_vma_reopen(struct i915_vma *vma)
> spin_unlock_irq(>->closed_lock);
> }
>
> -static void force_unbind(struct i915_vma *vma)
> +static void force_unbind(struct i915_vma *vma, bool async)
> {
> if (!drm_mm_node_allocated(&vma->node))
> return;
> @@ -1725,7 +1727,21 @@ static void force_unbind(struct i915_vma *vma)
> i915_vma_set_purged(vma);
>
> atomic_and(~I915_VMA_PIN_MASK, &vma->flags);
> - WARN_ON(__i915_vma_unbind(vma));
> + if (async) {
> + struct dma_fence *fence;
> +
> + fence = __i915_vma_unbind_async(vma);
> + if (IS_ERR_OR_NULL(fence)) {
> + async = false;
> + } else {
> + dma_resv_add_fence(vma->obj->base.resv, fence,
> + DMA_RESV_USAGE_READ);
> + dma_fence_put(fence);
> + }
> + }
> +
> + if (!async)
> + WARN_ON(__i915_vma_unbind(vma));
> GEM_BUG_ON(drm_mm_node_allocated(&vma->node));
> }
>
> @@ -1785,7 +1801,7 @@ void i915_vma_destroy_locked(struct i915_vma *vma)
> {
> lockdep_assert_held(&vma->vm->mutex);
>
> - force_unbind(vma);
> + force_unbind(vma, false);
> list_del_init(&vma->vm_link);
> release_references(vma, vma->vm->gt, false);
> }
> @@ -1796,7 +1812,34 @@ void i915_vma_destroy(struct i915_vma *vma)
> bool vm_ddestroy;
>
> mutex_lock(&vma->vm->mutex);
> - force_unbind(vma);
> + force_unbind(vma, false);
> + list_del_init(&vma->vm_link);
> + vm_ddestroy = vma->vm_ddestroy;
> + vma->vm_ddestroy = false;
> +
> + /* vma->vm may be freed when releasing vma->vm->mutex. */
> + gt = vma->vm->gt;
> + mutex_unlock(&vma->vm->mutex);
> + release_references(vma, gt, vm_ddestroy);
> +}
> +
> +void i915_vma_destroy_async(struct i915_vma *vma)
Where are we calling this? I can't find it.
> +{
> + bool vm_ddestroy, async = vma->obj->mm.rsgt;
> + struct intel_gt *gt;
> +
> + if (dma_resv_reserve_fences(vma->obj->base.resv, 1))
> + async = false;
> +
> + mutex_lock(&vma->vm->mutex);
> + /*
> +* Ensure any asynchronous binding is complete while using
> +* async unbind as we will be releasing the vma here.
> +*/
> + if (async && i915_active_wait(&vma->active))
> + async = false;
> +
> + force_unbind(vma, async);
> list_del_init(&vma->vm_link);
> vm_ddestroy = vma->vm_ddestroy;
> vma->vm_ddestroy = false;
> diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
> index 737ef310d046..25f15965dab8 100644
> --- a/drivers/gpu/drm/i915/i915_vma.h
> +++ b/drivers/gpu/drm/i915/i915_vma.h
> @@ -272,6 +272,7 @@ void i915_vma_reopen(struct i915_vma *vma);
>
> void i915_vma_destroy_locked(struct i915_vma *vma);
> void i915_vma_destroy(struct i915_vma *vma);
> +void i915_vma_destroy_async(struct i915_vma *vma);
>
> #define assert_vma_held(vma) dma_resv_assert_held((vma)->obj->base.resv)
>
> --
> 2.21.0.rc0.32.g243a4c7e27
>
Re: [Intel-gfx] [PATCH v2 0/4] drm/i915: header cleanups, cont'd
On Wed, Nov 09, 2022 at 05:35:18PM +0200, Jani Nikula wrote: The remaining patches from [1], rebased. I also realized this conflicts with what Lucas is doing so I'd like to get feedback. if you are talking about https://patchwork.freedesktop.org/series/109606/, then that series pretty much stalled on my request for comments on the suggestions I gave. I do think what we have in that patch series could be viewed as a small improvement and the redesign, if at all, could be done regardless. If we are redesigning it, I will need feedback on possible paths forward. My main motivation for that series, besides the space reduction was to make it easier to cover cases where register addresses moved from the traditional A, B, TC1, TC2, .. to TC1, TC2, A, B. The fact that it saves code and replaces most of the _PICK() uses come as a bonus. That PICK() macro creating an array and accessing it by index is very easy to blow up with out of bounds accesses AFAICS. I don't mind rebasing it on top of this series that is moving the definitions around. Lucas De Marchi [1] https://patchwork.freedesktop.org/series/110404/ Jani Nikula (4): drm/i915/reg: move masked field helpers to i915_reg_defs.h drm/i915/reg: move pick even and pick to reg defs drm/i915: split out intel_display_reg_defs.h drm/i915: stop including i915_irq.h from i915_trace.h drivers/gpu/drm/i915/display/g4x_dp.c | 1 + drivers/gpu/drm/i915/display/g4x_hdmi.c | 1 + drivers/gpu/drm/i915/display/i9xx_plane.c | 4 +- drivers/gpu/drm/i915/display/icl_dsi.c| 1 + drivers/gpu/drm/i915/display/icl_dsi_regs.h | 2 +- .../gpu/drm/i915/display/intel_audio_regs.h | 2 +- .../gpu/drm/i915/display/intel_backlight.c| 1 + .../drm/i915/display/intel_backlight_regs.h | 2 +- drivers/gpu/drm/i915/display/intel_cdclk.c| 1 + drivers/gpu/drm/i915/display/intel_color.c| 1 + .../gpu/drm/i915/display/intel_combo_phy.c| 1 + drivers/gpu/drm/i915/display/intel_crt.c | 2 + drivers/gpu/drm/i915/display/intel_cursor.c | 3 +- drivers/gpu/drm/i915/display/intel_ddi.c | 1 + drivers/gpu/drm/i915/display/intel_display.c | 1 + .../drm/i915/display/intel_display_debugfs.c | 2 + .../drm/i915/display/intel_display_reg_defs.h | 53 ++ drivers/gpu/drm/i915/display/intel_dp.c | 1 + drivers/gpu/drm/i915/display/intel_dp_aux.c | 1 + drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 1 + drivers/gpu/drm/i915/display/intel_dp_mst.c | 1 + drivers/gpu/drm/i915/display/intel_dpio_phy.c | 1 + drivers/gpu/drm/i915/display/intel_dpll.c | 1 + drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 1 + drivers/gpu/drm/i915/display/intel_drrs.c | 1 + drivers/gpu/drm/i915/display/intel_dsb.c | 1 + drivers/gpu/drm/i915/display/intel_dvo.c | 1 + drivers/gpu/drm/i915/display/intel_fdi.c | 1 + drivers/gpu/drm/i915/display/intel_gmbus.c| 2 + .../gpu/drm/i915/display/intel_hdcp_regs.h| 2 +- drivers/gpu/drm/i915/display/intel_hdmi.c | 1 + .../gpu/drm/i915/display/intel_lpe_audio.c| 2 + drivers/gpu/drm/i915/display/intel_lspcon.c | 1 + drivers/gpu/drm/i915/display/intel_lvds.c | 1 + .../gpu/drm/i915/display/intel_mg_phy_regs.h | 2 +- .../drm/i915/display/intel_modeset_setup.c| 1 + drivers/gpu/drm/i915/display/intel_panel.c| 1 + .../gpu/drm/i915/display/intel_pch_display.c | 1 + .../gpu/drm/i915/display/intel_pch_refclk.c | 1 + drivers/gpu/drm/i915/display/intel_pipe_crc.c | 2 + drivers/gpu/drm/i915/display/intel_pps.c | 1 + drivers/gpu/drm/i915/display/intel_psr.c | 1 + drivers/gpu/drm/i915/display/intel_sdvo.c | 1 + drivers/gpu/drm/i915/display/intel_snps_phy.c | 1 + .../drm/i915/display/intel_snps_phy_regs.h| 2 +- drivers/gpu/drm/i915/display/intel_sprite.c | 1 + drivers/gpu/drm/i915/display/intel_tv.c | 2 + drivers/gpu/drm/i915/display/intel_vdsc.c | 1 + drivers/gpu/drm/i915/display/intel_vga.c | 1 + drivers/gpu/drm/i915/display/intel_vrr.c | 1 + drivers/gpu/drm/i915/display/skl_scaler.c | 2 + .../drm/i915/display/skl_universal_plane.c| 2 + drivers/gpu/drm/i915/display/vlv_dsi.c| 1 + drivers/gpu/drm/i915/display/vlv_dsi_regs.h | 2 +- .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 1 + .../drm/i915/gem/selftests/i915_gem_mman.c| 1 + drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 + .../drm/i915/gt/intel_execlists_submission.c | 1 + drivers/gpu/drm/i915/gt/intel_gt.c| 1 + drivers/gpu/drm/i915/gt/intel_gt_pm.c | 1 + drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 + drivers/gpu/drm/i915/gt/intel_gtt.c | 1 + .../gpu/drm/i915/gt/intel_ring_submission.c | 2 + drivers/gpu/drm/i915/gt/intel_workarounds.c | 1 + .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 1 + drivers/gpu/drm/i915/gvt/cmd_parser.c | 1 + drivers/gpu/drm/i915/gvt/mmio_context.c | 1 + drivers/gpu/drm/i915/i915_gpu_error.c | 1 + drivers/gpu/
Re: [Intel-gfx] [PATCH 1/2] drm/i915/gt: Add GT oriented dmesg output
On 11/9/2022 03:05, Tvrtko Ursulin wrote:
On 08/11/2022 20:15, John Harrison wrote:
On 11/8/2022 01:01, Tvrtko Ursulin wrote:
On 07/11/2022 19:14, John Harrison wrote:
On 11/7/2022 08:17, Tvrtko Ursulin wrote:
On 07/11/2022 09:33, Tvrtko Ursulin wrote:
On 05/11/2022 01:03, Ceraolo Spurio, Daniele wrote:
On 11/4/2022 10:25 AM, john.c.harri...@intel.com wrote:
From: John Harrison
When trying to analyse bug reports from CI, customers, etc. it
can be
difficult to work out exactly what is happening on which GT in a
multi-GT system. So add GT oriented debug/error message
wrappers. If
used instead of the drm_ equivalents, you get the same output
but with
a GT# prefix on it.
Signed-off-by: John Harrison
The only downside to this is that we'll print "GT0: " even on
single-GT devices. We could introduce a gt->info.name and print
that, so we could have it different per-platform, but IMO it's
not worth the effort.
Reviewed-by: Daniele Ceraolo Spurio
I think it might be worth getting an ack from one of the
maintainers to make sure we're all aligned on transitioning to
these new logging macro for gt code.
Idea is I think a very good one. First I would suggest
standardising to lowercase GT in logs because:
$ grep "GT%" i915/ -r
$ grep "gt%" i915/ -r
i915/gt/intel_gt_sysfs.c: gt->i915->sysfs_gt, "gt%d", gt->info.id))
i915/gt/intel_gt_sysfs.c: "failed to initialize
gt%d sysfs root\n", gt->info.id);
i915/gt/intel_gt_sysfs_pm.c: "failed to
create gt%u RC6 sysfs files (%pe)\n",
i915/gt/intel_gt_sysfs_pm.c: "failed to create gt%u RC6p sysfs
files (%pe)\n",
i915/gt/intel_gt_sysfs_pm.c: "failed to
create gt%u RPS sysfs files (%pe)",
i915/gt/intel_gt_sysfs_pm.c: "failed to
create gt%u punit_req_freq_mhz sysfs (%pe)",
i915/gt/intel_gt_sysfs_pm.c: "failed to create gt%u throttle
sysfs files (%pe)",
i915/gt/intel_gt_sysfs_pm.c: "failed to create gt%u
media_perf_power_attrs sysfs (%pe)\n",
i915/gt/intel_gt_sysfs_pm.c: "failed to add
gt%u rps defaults (%pe)\n",
i915/i915_driver.c: drm_err(>->i915->drm, "gt%d:
intel_pcode_init failed %d\n", id, ret);
i915/i915_hwmon.c: snprintf(ddat_gt->name, sizeof(ddat_gt->name),
"i915_gt%u", i);
Just because there are 11 existing instances of one form doesn't
mean that the 275 instances that are waiting to be converted should
be done incorrectly. GT is an acronym and should be capitalised.
Okay just make it consistent then.
Besides:
grep -r "GT " i915 | grep '"'
i915/vlv_suspend.c: drm_err(&i915->drm, "timeout
disabling GT waking\n");
i915/vlv_suspend.c: "timeout waiting for GT
wells to go %s\n",
i915/vlv_suspend.c: drm_dbg(&i915->drm, "GT register access
while GT waking disabled\n");
i915/i915_gpu_error.c: err_printf(m, "GT awake: %s\n",
str_yes_no(gt->awake));
i915/i915_debugfs.c: seq_printf(m, "GT awake? %s [%d], %llums\n",
i915/selftests/i915_gem_evict.c: pr_err("Failed to idle GT (on
%s)", engine->name);
i915/intel_uncore.c: "GT thread status wait timed
out\n");
i915/gt/uc/selftest_guc_multi_lrc.c: drm_err(>->i915->drm, "GT
failed to idle: %d\n", ret);
i915/gt/uc/selftest_guc.c: drm_err(>->i915->drm, "GT failed to
idle: %d\n", ret);
i915/gt/uc/selftest_guc.c: drm_err(>->i915->drm, "GT failed to
idle: %d\n", ret);
i915/gt/intel_gt_mcr.c: * Some GT registers are designed as
"multicast" or "replicated" registers:
i915/gt/selftest_rps.c: pr_info("%s: rps counted %d
C0 cycles [%lldns] in %lldns [%d cycles], using GT clock frequency
of %uKHz\n",
i915/gt/selftest_hangcheck.c: pr_err("[%s] GT is
wedged!\n", engine->name);
i915/gt/selftest_hangcheck.c: pr_err("GT is wedged!\n");
i915/gt/intel_gt_clock_utils.c: "GT clock frequency
changed, was %uHz, now %uHz!\n",
i915/gt/selftest_engine_pm.c: pr_err("Unable to flush GT
pm before test\n");
i915/gt/selftest_engine_pm.c: pr_err("GT failed to idle\n");
i915/i915_sysfs.c: "failed to register GT
sysfs directory\n");
i915/intel_uncore.h: * of the basic non-engine GT registers
(referred to as "GSI" on
i915/intel_uncore.h: * newer platforms, or "GT block" on older
platforms)? If so, we'll
Then there is a question of naming. Are we okay with GT_XXX or,
do we want intel_gt_, or something completely different. I don't
have a strong opinion at the moment so I'll add some more folks
to Cc.
You mean GT_ERR("msg") vs intel_gt_err("msg")? Personally, I would
prefer just gt_err("msg") to keep it as close to the official drm_*
versions as possible. Print lines tend to be excessively long
already. Taking a 'gt' parameter instead of a '>->i915->drm'
parameter does help with that but it seems like calling the wrapper
intel_gt_* is shooting ourselves in the foot on that one. And
GT_ERR vs gt_err just comes down to the fact that it is a ma
[Intel-gfx] [PATCH 0/3] add guard padding around i915_vma
Hi, This series adds guards around vma's but setting a pages at the beginning and at the end that work as padding. The first user of the vma guard are scanout objects which don't need anymore to add scratch to all the unused ggtt's and speeding up up considerably the boot and resume by several hundreds of milliseconds up to over a full second in slower machines. Andi Chris Wilson (3): drm/i915: Wrap all access to i915_vma.node.start|size drm/i915: Introduce guard pages to i915_vma drm/i915: Refine VT-d scanout workaround drivers/gpu/drm/i915/display/intel_fbdev.c| 2 +- drivers/gpu/drm/i915/gem/i915_gem_domain.c| 13 .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 33 ++- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_tiling.c| 4 +- .../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +- .../i915/gem/selftests/i915_gem_client_blt.c | 23 .../drm/i915/gem/selftests/i915_gem_context.c | 15 +++-- .../drm/i915/gem/selftests/i915_gem_mman.c| 2 +- .../drm/i915/gem/selftests/igt_gem_utils.c| 7 ++- drivers/gpu/drm/i915/gt/gen7_renderclear.c| 2 +- drivers/gpu/drm/i915/gt/intel_ggtt.c | 39 drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 3 +- drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +- .../gpu/drm/i915/gt/intel_ring_submission.c | 2 +- drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 8 +-- drivers/gpu/drm/i915/gt/selftest_execlists.c | 18 +++--- drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 15 ++--- drivers/gpu/drm/i915/gt/selftest_lrc.c| 16 ++--- .../drm/i915/gt/selftest_ring_submission.c| 2 +- drivers/gpu/drm/i915/gt/selftest_rps.c| 12 ++-- .../gpu/drm/i915/gt/selftest_workarounds.c| 8 +-- drivers/gpu/drm/i915/i915_cmd_parser.c| 4 +- drivers/gpu/drm/i915/i915_debugfs.c | 2 +- drivers/gpu/drm/i915/i915_gem_gtt.h | 3 +- drivers/gpu/drm/i915/i915_perf.c | 2 +- drivers/gpu/drm/i915/i915_vma.c | 59 +-- drivers/gpu/drm/i915/i915_vma.h | 52 +++- drivers/gpu/drm/i915/i915_vma_resource.c | 4 +- drivers/gpu/drm/i915/i915_vma_resource.h | 17 -- drivers/gpu/drm/i915/i915_vma_types.h | 3 +- drivers/gpu/drm/i915/selftests/i915_request.c | 20 +++ drivers/gpu/drm/i915/selftests/igt_spinner.c | 8 +-- 34 files changed, 246 insertions(+), 160 deletions(-) -- 2.37.2
[Intel-gfx] [PATCH 2/3] drm/i915: Introduce guard pages to i915_vma
From: Chris Wilson Introduce the concept of padding the i915_vma with guard pages before and after. The major consequence is that all ordinary uses of i915_vma must use i915_vma_offset/i915_vma_size and not i915_vma.node.start/size directly, as the drm_mm_node will include the guard pages that surround our object. The biggest connundrum is how exactly to mix requesting a fixed address with guard pages, particularly through the existing uABI. The user does not know about guard pages, so such must be transparent to the user, and so the execobj.offset must be that of the object itself excluding the guard. So a PIN_OFFSET_FIXED must then be exclusive of the guard pages. The caveat is that some placements will be impossible with guard pages, as wrap arounds need to be avoided, and the vma itself will require a larger node. We must not report EINVAL but ENOSPC as these are unavailable locations within the GTT rather than conflicting user requirements. In the next patch, we start using guard pages for scanout objects. While these are limited to GGTT vma, on a few platforms these vma (or at least an alias of the vma) is shared with userspace, so we may leak the existence of such guards if we are not careful to ensure that the execobj.offset is transparent and excludes the guards. (On such platforms like ivb, without full-ppgtt, userspace has to use relocations so the presence of more untouchable regions within its GTT such be of no further issue.) Signed-off-by: Chris Wilson Signed-off-by: Tejas Upadhyay Signed-off-by: Tvrtko Ursulin Signed-off-by: Andi Shyti --- drivers/gpu/drm/i915/gt/intel_ggtt.c | 14 drivers/gpu/drm/i915/i915_gem_gtt.h | 3 ++- drivers/gpu/drm/i915/i915_vma.c | 27 ++-- drivers/gpu/drm/i915/i915_vma.h | 5 +++-- drivers/gpu/drm/i915/i915_vma_resource.c | 4 ++-- drivers/gpu/drm/i915/i915_vma_resource.h | 7 +- drivers/gpu/drm/i915/i915_vma_types.h| 3 ++- 7 files changed, 46 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c b/drivers/gpu/drm/i915/gt/intel_ggtt.c index 2518cebbf931c..0dd81b18716c3 100644 --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c @@ -287,8 +287,11 @@ static void gen8_ggtt_insert_entries(struct i915_address_space *vm, */ gte = (gen8_pte_t __iomem *)ggtt->gsm; - gte += vma_res->start / I915_GTT_PAGE_SIZE; - end = gte + vma_res->node_size / I915_GTT_PAGE_SIZE; + gte += (vma_res->start - vma_res->guard) / I915_GTT_PAGE_SIZE; + end = gte + vma_res->guard / I915_GTT_PAGE_SIZE; + while (gte < end) + gen8_set_pte(gte++, vm->scratch[0]->encode); + end += (vma_res->node_size + vma_res->guard) / I915_GTT_PAGE_SIZE; for_each_sgt_daddr(addr, iter, vma_res->bi.pages) gen8_set_pte(gte++, pte_encode | addr); @@ -338,9 +341,12 @@ static void gen6_ggtt_insert_entries(struct i915_address_space *vm, dma_addr_t addr; gte = (gen6_pte_t __iomem *)ggtt->gsm; - gte += vma_res->start / I915_GTT_PAGE_SIZE; - end = gte + vma_res->node_size / I915_GTT_PAGE_SIZE; + gte += (vma_res->start - vma_res->guard) / I915_GTT_PAGE_SIZE; + end = gte + vma_res->guard / I915_GTT_PAGE_SIZE; + while (gte < end) + iowrite32(vm->scratch[0]->encode, gte++); + end += (vma_res->node_size + vma_res->guard) / I915_GTT_PAGE_SIZE; for_each_sgt_daddr(addr, iter, vma_res->bi.pages) iowrite32(vm->pte_encode(addr, level, flags), gte++); GEM_BUG_ON(gte > end); diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h b/drivers/gpu/drm/i915/i915_gem_gtt.h index 8c2f57eb5ddaa..2434197830523 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.h +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h @@ -44,7 +44,8 @@ int i915_gem_gtt_insert(struct i915_address_space *vm, #define PIN_HIGH BIT_ULL(5) #define PIN_OFFSET_BIASBIT_ULL(6) #define PIN_OFFSET_FIXED BIT_ULL(7) -#define PIN_VALIDATE BIT_ULL(8) /* validate placement only, no need to call unpin() */ +#define PIN_OFFSET_GUARD BIT_ULL(8) +#define PIN_VALIDATE BIT_ULL(9) /* validate placement only, no need to call unpin() */ #define PIN_GLOBAL BIT_ULL(10) /* I915_VMA_GLOBAL_BIND */ #define PIN_USER BIT_ULL(11) /* I915_VMA_LOCAL_BIND */ diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c index 2be43885a2b5d..ff24a654565f6 100644 --- a/drivers/gpu/drm/i915/i915_vma.c +++ b/drivers/gpu/drm/i915/i915_vma.c @@ -417,7 +417,7 @@ i915_vma_resource_init_from_vma(struct i915_vma_resource *vma_res, obj->mm.rsgt, i915_gem_object_is_readonly(obj), i915_gem_object_is_lmem(obj), obj->mm.region, vma->ops, vma->private, __i915_vma_offset(vma), -
[Intel-gfx] [PATCH 1/3] drm/i915: Wrap all access to i915_vma.node.start|size
From: Chris Wilson
We already wrap i915_vma.node.start for use with the GGTT, as there we
can perform additional sanity checks that the node belongs to the GGTT
and fits within the 32b registers. In the next couple of patches, we
will introduce guard pages around the objects _inside_ the drm_mm_node
allocation. That is we will offset the vma->pages so that the first page
is at drm_mm_node.start + vma->guard (not 0 as is currently the case).
All users must then not use i915_vma.node.start directly, but compute
the guard offset, thus all users are converted to use a
i915_vma_offset() wrapper.
The notable exceptions are the selftests that are testing exact
behaviour of i915_vma_pin/i915_vma_insert.
Signed-off-by: Chris Wilson
Signed-off-by: Tejas Upadhyay
Co-developed-by: Thomas Hellström
Signed-off-by: Thomas Hellström
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/display/intel_fbdev.c| 2 +-
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 33 ++--
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_tiling.c| 4 +-
.../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +-
.../i915/gem/selftests/i915_gem_client_blt.c | 23 +
.../drm/i915/gem/selftests/i915_gem_context.c | 15 +++---
.../drm/i915/gem/selftests/i915_gem_mman.c| 2 +-
.../drm/i915/gem/selftests/igt_gem_utils.c| 7 +--
drivers/gpu/drm/i915/gt/gen7_renderclear.c| 2 +-
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 3 +-
drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +-
.../gpu/drm/i915/gt/intel_ring_submission.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 8 +--
drivers/gpu/drm/i915/gt/selftest_execlists.c | 18 +++
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 15 +++---
drivers/gpu/drm/i915/gt/selftest_lrc.c| 16 +++---
.../drm/i915/gt/selftest_ring_submission.c| 2 +-
drivers/gpu/drm/i915/gt/selftest_rps.c| 12 ++---
.../gpu/drm/i915/gt/selftest_workarounds.c| 8 +--
drivers/gpu/drm/i915/i915_cmd_parser.c| 4 +-
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_perf.c | 2 +-
drivers/gpu/drm/i915/i915_vma.c | 25 -
drivers/gpu/drm/i915/i915_vma.h | 51 +--
drivers/gpu/drm/i915/i915_vma_resource.h | 10 ++--
drivers/gpu/drm/i915/selftests/i915_request.c | 20
drivers/gpu/drm/i915/selftests/igt_spinner.c | 8 +--
29 files changed, 180 insertions(+), 122 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 5575d7abdc092..03ed4607a46d2 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -286,7 +286,7 @@ static int intelfb_create(struct drm_fb_helper *helper,
/* Our framebuffer is the entirety of fbdev's system memory */
info->fix.smem_start =
- (unsigned long)(ggtt->gmadr.start + vma->node.start);
+ (unsigned long)(ggtt->gmadr.start +
i915_ggtt_offset(vma));
info->fix.smem_len = vma->size;
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 1160723c9d2d9..5f09d33f1c836 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -378,22 +378,25 @@ eb_vma_misplaced(const struct drm_i915_gem_exec_object2
*entry,
const struct i915_vma *vma,
unsigned int flags)
{
- if (vma->node.size < entry->pad_to_size)
+ const u64 start = i915_vma_offset(vma);
+ const u64 size = i915_vma_size(vma);
+
+ if (size < entry->pad_to_size)
return true;
- if (entry->alignment && !IS_ALIGNED(vma->node.start, entry->alignment))
+ if (entry->alignment && !IS_ALIGNED(start, entry->alignment))
return true;
if (flags & EXEC_OBJECT_PINNED &&
- vma->node.start != entry->offset)
+ start != entry->offset)
return true;
if (flags & __EXEC_OBJECT_NEEDS_BIAS &&
- vma->node.start < BATCH_OFFSET_BIAS)
+ start < BATCH_OFFSET_BIAS)
return true;
if (!(flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS) &&
- (vma->node.start + vma->node.size + 4095) >> 32)
+ (start + size + 4095) >> 32)
return true;
if (flags & __EXEC_OBJECT_NEEDS_MAP &&
@@ -439,7 +442,7 @@ eb_pin_vma(struct i915_execbuffer *eb,
int err;
if (vma->node.size)
- pin_flags = vma->node.start;
+ pin_flags = __i915_vma_offset(vma);
else
pin_flags = entry->offset & PIN_OFFSET_MASK;
@@ -662,8 +665,8 @@ static int eb_reserve_vma(str
[Intel-gfx] [PATCH 3/3] drm/i915: Refine VT-d scanout workaround
From: Chris Wilson
VT-d may cause overfetch of the scanout PTE, both before and after the
vma (depending on the scanout orientation). bspec recommends that we
provide a tile-row in either directions, and suggests using 168 PTE,
warning that the accesses will wrap around the ends of the GGTT.
Currently, we fill the entire GGTT with scratch pages when using VT-d to
always ensure there are valid entries around every vma, including
scanout. However, writing every PTE is slow as on recent devices we
perform 8MiB of uncached writes, incurring an extra 100ms during resume.
If instead we focus on only putting guard pages around scanout, we can
avoid touching the whole GGTT. To avoid having to introduce extra nodes
around each scanout vma, we adjust the scanout drm_mm_node to be smaller
than the allocated space, and fixup the extra PTE during dma binding.
Signed-off-by: Chris Wilson
Signed-off-by: Tejas Upadhyay
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 13 +++
drivers/gpu/drm/i915/gt/intel_ggtt.c | 25 +-
drivers/gpu/drm/i915/i915_vma.c| 9
3 files changed, 23 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index d44a152ce6800..882b91519f92b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -17,6 +17,8 @@
#include "i915_gem_object.h"
#include "i915_vma.h"
+#define VTD_GUARD (168u * I915_GTT_PAGE_SIZE) /* 168 or tile-row PTE padding */
+
static bool gpu_write_needs_clflush(struct drm_i915_gem_object *obj)
{
struct drm_i915_private *i915 = to_i915(obj->base.dev);
@@ -424,6 +426,17 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
if (ret)
return ERR_PTR(ret);
+ /* VT-d may overfetch before/after the vma, so pad with scratch */
+ if (intel_scanout_needs_vtd_wa(i915)) {
+ unsigned int guard = VTD_GUARD;
+
+ if (i915_gem_object_is_tiled(obj))
+ guard = max(guard,
+ i915_gem_object_get_tile_row_size(obj));
+
+ flags |= PIN_OFFSET_GUARD | guard;
+ }
+
/*
* As the user may map the buffer once pinned in the display plane
* (e.g. libkms for the bootup splash), we have to ensure that we
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 0dd81b18716c3..b0acb645a6de6 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -367,27 +367,6 @@ static void nop_clear_range(struct i915_address_space *vm,
{
}
-static void gen8_ggtt_clear_range(struct i915_address_space *vm,
- u64 start, u64 length)
-{
- struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
- unsigned int first_entry = start / I915_GTT_PAGE_SIZE;
- unsigned int num_entries = length / I915_GTT_PAGE_SIZE;
- const gen8_pte_t scratch_pte = vm->scratch[0]->encode;
- gen8_pte_t __iomem *gtt_base =
- (gen8_pte_t __iomem *)ggtt->gsm + first_entry;
- const int max_entries = ggtt_total_entries(ggtt) - first_entry;
- int i;
-
- if (WARN(num_entries > max_entries,
-"First entry = %d; Num entries = %d (max=%d)\n",
-first_entry, num_entries, max_entries))
- num_entries = max_entries;
-
- for (i = 0; i < num_entries; i++)
- gen8_set_pte(>t_base[i], scratch_pte);
-}
-
static void bxt_vtd_ggtt_wa(struct i915_address_space *vm)
{
/*
@@ -959,8 +938,6 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
ggtt->vm.cleanup = gen6_gmch_remove;
ggtt->vm.insert_page = gen8_ggtt_insert_page;
ggtt->vm.clear_range = nop_clear_range;
- if (intel_scanout_needs_vtd_wa(i915))
- ggtt->vm.clear_range = gen8_ggtt_clear_range;
ggtt->vm.insert_entries = gen8_ggtt_insert_entries;
@@ -1121,7 +1098,7 @@ static int gen6_gmch_probe(struct i915_ggtt *ggtt)
ggtt->vm.alloc_scratch_dma = alloc_pt_dma;
ggtt->vm.clear_range = nop_clear_range;
- if (!HAS_FULL_PPGTT(i915) || intel_scanout_needs_vtd_wa(i915))
+ if (!HAS_FULL_PPGTT(i915))
ggtt->vm.clear_range = gen6_ggtt_clear_range;
ggtt->vm.insert_page = gen6_ggtt_insert_page;
ggtt->vm.insert_entries = gen6_ggtt_insert_entries;
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index ff24a654565f6..973abe56cbaa0 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -675,6 +675,10 @@ bool i915_vma_misplaced(const struct i915_vma *vma,
i915_vma_offset(vma) != (flags & PIN_OFFSET_MASK))
return true;
+ if (flags & PIN_OFFSET_GUARD &&
+ v
Re: [Intel-gfx] [PATCH v2 10/11] vfio: Make vfio_container optionally compiled
On Tue, 8 Nov 2022 20:54:58 -0400 Jason Gunthorpe wrote: > On Tue, Nov 08, 2022 at 03:28:31PM -0700, Alex Williamson wrote: > > > Perhaps this should have been obvious, but I'm realizing that > > vfio-noiommu mode is completely missing without VFIO_CONTAINER, which > > seems a barrier to deprecating VFIO_CONTAINER and perhaps makes it a > > Yes, it is the same as the allow_unsafe_interrupts - it is something > that currently goes missing if you turn off VFIO_CONTAINER. > > This seems straightforward enough to resolve in a followup, we mostly > just need someone with an existing no-iommu application to test > compatability against. Keeping it working with the device cdev will > also be a bit interesting. If you have or know about some application > I can try to make a patch. DPDK supports no-iommu mode. > > question whether IOMMUFD should really be taking over /dev/vfio/vfio. > > No-iommu mode has users. > > I view VFIO_CONTAINER=n as a process. An aspiration we can work > toward. > > At this point there are few places that might want to use it. Android > perhaps, for example. It is also useful for testing. One of the main > values is you can switch the options and feed the kernel into an > existing test environment and see what happens. This is how we are > able to quickly get s390 mdev testing, for instance. > > We are not going to get to a widely useful VFIO_CONTAINER=n if we > don't have a target that people can test against and evaluate what > compatability gaps may exist. > > So, everytime we find something like this - let's think about how can > we make iommufd compatibility handle it and not jump straight to > giving up :) > > I'm kind of thinking v6.4 might be a reasonable kernel target when we > might have closed off enough things. I agree that it's very useful for testing, I'm certainly not suggesting to give up, but I'm not sure where no-iommu lives when iommufd owns /dev/vfio/vfio. Given the unsafe interrupts discussion, it doesn't seem like the type of thing that would be a priority for iommufd. We're on a path where vfio accepts an iommufd as a container, and ultimately iommufd becomes the container provider, supplanting the IOMMU driver registration aspect of vfio. I absolutely want type1 and spapr backends to get replaced by iommufd, but reluctance to support aspects of vfio "legacy" behavior doesn't give me warm fuzzies about a wholesale hand-off of the container to a different subsystem, for example vs an iommufd shim spoofing type1 support. Unfortunately we no longer have a CONFIG_EXPERIMENTAL option to hide behind for disabling VFIO_CONTAINER, so regardless of our intentions that a transition is some time off, it may become an issue sooner than we expect. Thanks, Alex
Re: [Intel-gfx] [PATCH 0/3] add guard patting around i915_vma
Please ignore, this series is rebased on the wrong branch. Andi On Wed, Nov 09, 2022 at 05:49:10PM +0100, Andi Shyti wrote: > Hi, > > This patch series adds a padding around i915_vma's reducing > consequently the need to add scratch to the unused GGTT. > > This speeds up considerably the boot and resume by several > hundreds of milliseconds up to over a full second in slower > machines. > > Andi > > Chris Wilson (3): > drm/i915: Wrap all access to i915_vma.node.start|size > drm/i915: Introduce guard pages to i915_vma > drm/i915: Refine VT-d scanout workaround > > drivers/gpu/drm/i915/display/intel_dpt.c | 4 +- > drivers/gpu/drm/i915/display/intel_fbdev.c| 2 +- > drivers/gpu/drm/i915/gem/i915_gem_domain.c| 13 + > .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 37 ++-- > drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +- > drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 2 +- > drivers/gpu/drm/i915/gem/i915_gem_tiling.c| 4 +- > .../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +- > .../i915/gem/selftests/i915_gem_client_blt.c | 15 ++--- > .../drm/i915/gem/selftests/i915_gem_context.c | 19 -- > .../drm/i915/gem/selftests/i915_gem_mman.c| 2 +- > .../drm/i915/gem/selftests/igt_gem_utils.c| 7 ++- > drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 2 +- > drivers/gpu/drm/i915/gt/gen7_renderclear.c| 2 +- > drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 8 +-- > drivers/gpu/drm/i915/gt/intel_ggtt.c | 39 - > drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 3 +- > drivers/gpu/drm/i915/gt/intel_ppgtt.c | 7 ++- > drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +- > .../gpu/drm/i915/gt/intel_ring_submission.c | 2 +- > drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 12 ++-- > drivers/gpu/drm/i915/gt/selftest_execlists.c | 18 +++--- > drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 17 +++--- > drivers/gpu/drm/i915/gt/selftest_lrc.c| 16 ++--- > .../drm/i915/gt/selftest_ring_submission.c| 2 +- > drivers/gpu/drm/i915/gt/selftest_rps.c| 12 ++-- > .../gpu/drm/i915/gt/selftest_workarounds.c| 8 +-- > drivers/gpu/drm/i915/i915_cmd_parser.c| 4 +- > drivers/gpu/drm/i915/i915_debugfs.c | 3 +- > drivers/gpu/drm/i915/i915_gem_gtt.h | 1 + > drivers/gpu/drm/i915/i915_gpu_error.c | 4 +- > drivers/gpu/drm/i915/i915_perf.c | 2 +- > drivers/gpu/drm/i915/i915_vma.c | 58 ++- > drivers/gpu/drm/i915/i915_vma.h | 24 +++- > drivers/gpu/drm/i915/i915_vma_types.h | 3 +- > drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 12 +++- > drivers/gpu/drm/i915/selftests/i915_request.c | 20 +++ > drivers/gpu/drm/i915/selftests/igt_spinner.c | 11 ++-- > 38 files changed, 238 insertions(+), 163 deletions(-) > > -- > 2.37.2
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915/pps: Add get_pps_idx() hook as part of pps_get_register() cleanup
== Series Details ==
Series: series starting with [1/3] drm/i915/pps: Add get_pps_idx() hook as part
of pps_get_register() cleanup
URL : https://patchwork.freedesktop.org/series/110694/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12362 -> Patchwork_110694v1
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_110694v1 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_110694v1, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110694v1/index.html
Participating hosts (37 -> 38)
--
Additional (3): fi-hsw-4770 fi-rkl-11600 bat-dg1-6
Missing(2): fi-ctg-p8600 fi-bxt-dsi
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_110694v1:
### IGT changes ###
Possible regressions
* igt@kms_psr@primary_mmap_gtt:
- bat-adlp-4: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12362/bat-adlp-4/igt@kms_psr@primary_mmap_gtt.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110694v1/bat-adlp-4/igt@kms_psr@primary_mmap_gtt.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_pm_rpm@basic-pci-d3-state:
- {bat-rplp-1}: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12362/bat-rplp-1/igt@i915_pm_...@basic-pci-d3-state.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110694v1/bat-rplp-1/igt@i915_pm_...@basic-pci-d3-state.html
Known issues
Here are the changes found in Patchwork_110694v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-rkl-11600: NOTRUN -> [SKIP][5] ([i915#2190])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110694v1/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@parallel-random-engines:
- fi-rkl-11600: NOTRUN -> [SKIP][6] ([i915#4613]) +3 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110694v1/fi-rkl-11600/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@gem_mmap@basic:
- bat-dg1-6: NOTRUN -> [SKIP][7] ([i915#4083])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110694v1/bat-dg1-6/igt@gem_m...@basic.html
* igt@gem_render_tiled_blits@basic:
- bat-dg1-6: NOTRUN -> [SKIP][8] ([i915#4079]) +1 similar issue
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110694v1/bat-dg1-6/igt@gem_render_tiled_bl...@basic.html
* igt@gem_tiled_fence_blits@basic:
- bat-dg1-6: NOTRUN -> [SKIP][9] ([i915#4077]) +2 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110694v1/bat-dg1-6/igt@gem_tiled_fence_bl...@basic.html
* igt@gem_tiled_pread_basic:
- fi-rkl-11600: NOTRUN -> [SKIP][10] ([i915#3282])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110694v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html
* igt@i915_pm_backlight@basic-brightness:
- bat-dg1-6: NOTRUN -> [SKIP][11] ([i915#1155])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110694v1/bat-dg1-6/igt@i915_pm_backli...@basic-brightness.html
- fi-rkl-11600: NOTRUN -> [SKIP][12] ([i915#3012])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110694v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html
- fi-hsw-4770:NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#3012])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110694v1/fi-hsw-4770/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_pm_rps@basic-api:
- bat-dg1-6: NOTRUN -> [SKIP][14] ([i915#6621])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110694v1/bat-dg1-6/igt@i915_pm_...@basic-api.html
* igt@i915_selftest@live@gt_engines:
- bat-dg1-6: NOTRUN -> [INCOMPLETE][15] ([i915#4418])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110694v1/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
* igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600: NOTRUN -> [INCOMPLETE][16] ([i915#4817])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110694v1/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- fi-hsw-4770:NOTRUN -> [SKIP][17] ([fdo#109271]) +9 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110694v1/fi-hsw-4770/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html
* igt@kms_addfb_basic@basic-y-tiled-legac
Re: [Intel-gfx] [RFC 00/17] DRM scheduling cgroup controller
On 31/10/2022 20:20, Tejun Heo wrote: Hello, On Thu, Oct 27, 2022 at 03:32:00PM +0100, Tvrtko Ursulin wrote: Looking at what's available in cgroups world now, I have spotted the blkio.prio.class control. For my current use case (lower GPU scheduling of background/unfocused windows) that would also work. Even if starting with just two possible values - 'no-change' and 'idle' (to follow the IO controller naming). I wouldn't follow that example. That's only meaningful within the context of bfq and it probabaly shouldn't have been merged in the first place. How would you view that as a proposal? It would be a bit tougher "sell" to the DRM community, perhaps, given that many drivers do have scheduling priority, but the concept of scheduling class is not really there. Nevertheless a concept of normal-vs-background could be plausible in my mind. It could be easily implemented by using the priority controls available in many drivers. I don't feel great about that. * The semantics aren't clearly defined. While not immediately obvious in the interface, the task nice levels have definite mappings to weight values and thus clear meanings. I don't think it's a good idea to leave the interface semantics open to interpretation. Agreed it is not clearly defined, but it was the same with nice levels. As in it changed a lot over the years how exactly they behave (with a few scheduler rewrites) and they were constantly at least somewhat useful as a mean of external control. Nevertheless you will notice I have dropped everything priority based from the v2 of the RFC to simplify the conversation going forward. * Maybe GPUs are better but my experience with optional hardware features in the storage world has been that vendors diverge wildly and unexpectedly to the point many features are mostly useless. There are fewer GPU vendors and more software effort behind each, so maybe the situation is better but I think it'd be helpul to keep some skepticism. * Even when per-vendor or per-driver features are consistent enough to be useful, they often aren't thought through enough to be truly useful. e.g. nvme has priority features but they aren't really that useful because they can't do much without congestion control on the issuer side and once you have congestion control on the issuer side which is usually a lot more complex (e.g. dealing with work-conserving hierarchical weight distributions, priority inversions and so on), you can achieve most of what you need in terms of resource control from the issuer side anyway. GPUs will not be fully uniform either, especially in the terms of how well the controls work, which is why I am spelling out how this is only attempting to do "soft limits", everywhere in the documentation, cover letter and patch commit message. But at least concept of GPU time feels to me like a very universal one so should be something which we can base the control on. So, I'd much prefer to have a fuller solution on the kernel side which integrates per-vendor/driver features where they make sense. drm.budget_supported One of: 1) 'yes' - when all DRM clients in the group support the functionality. 2) 'no' - when at least one of the DRM clients does not support the functionality. 3) 'n/a' - when there are no DRM clients in the group. Yeah, I'm not sure about this. This isn't a per-cgroup property to begin with and I'm not sure 'no' meaning at least one device not supporting is intuitive. The distinction between 'no' and 'n/a' is kinda weird too. Please drop this. The idea actually is for this to be per-cgroup and potentially change dynamically. It implements the concept of "observability", how I have, perhaps clumsily, named it. This is because we can have a mix of DRM file descriptors in a cgroup, not all of which support the proposed functionality. So I wanted to have something by which the administrator can observe the status of the group. For instance seeing some clients do not support the feature could be signal that things have been misconfigured, or that appeal needs to be made for driver X to start supporting the feature. Seeing a "no" there in other words is a signal that budgeting may not really work as expected and needs to be investigated. I still don't see how this is per-cgroup given that it's indicating whether the driver supports some feature. Also, the eventual goal would be supporting the same control mechanisms across most (if not all) GPUs, right? I have dropped this from v2 as well, to focus the feedback on most important points. But in general the problem it wanted to address is that a single cgroup can contain multiple processes, each with zero to N open DRM file descriptors to any random GPU which happens to be installed in the system. And it can all change dynamically. It may be different vendors or different hardware generations, where some
Re: [Intel-gfx] [PATCH v2 00/11] Connect VFIO to IOMMUFD
On Tue, Nov 08, 2022 at 11:18:03PM +0800, Yi Liu wrote: > On 2022/11/8 17:19, Nicolin Chen wrote: > > On Mon, Nov 07, 2022 at 08:52:44PM -0400, Jason Gunthorpe wrote: > > > > > This is on github: > > > https://github.com/jgunthorpe/linux/commits/vfio_iommufd > > [...] > > > v2: > > > - Rebase to v6.1-rc3, v4 iommufd series > > > - Fixup comments and commit messages from list remarks > > > - Fix leaking of the iommufd for mdevs > > > - New patch to fix vfio modaliases when vfio container is disabled > > > - Add a dmesg once when the iommufd provided /dev/vfio/vfio is opened > > > to signal that iommufd is providing this > > > > I've redone my previous sanity tests. Except those reported bugs, > > things look fine. Once we fix those issues, GVT and other modules > > can run some more stressful tests, I think. > > our side is also starting test (gvt, nic passthrough) this version. need to > wait a while for the result. I've updated the branches with the two functional fixes discussed on the list plus all the doc updates. Thanks, Jason
[Intel-gfx] [PATCH 3/3] drm/i915: Refine VT-d scanout workaround
From: Chris Wilson
VT-d may cause overfetch of the scanout PTE, both before and after the
vma (depending on the scanout orientation). bspec recommends that we
provide a tile-row in either directions, and suggests using 168 PTE,
warning that the accesses will wrap around the ends of the GGTT.
Currently, we fill the entire GGTT with scratch pages when using VT-d to
always ensure there are valid entries around every vma, including
scanout. However, writing every PTE is slow as on recent devices we
perform 8MiB of uncached writes, incurring an extra 100ms during resume.
If instead we focus on only putting guard pages around scanout, we can
avoid touching the whole GGTT. To avoid having to introduce extra nodes
around each scanout vma, we adjust the scanout drm_mm_node to be smaller
than the allocated space, and fixup the extra PTE during dma binding.
Signed-off-by: Chris Wilson
Signed-off-by: Tejas Upadhyay
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 13 +++
drivers/gpu/drm/i915/gt/intel_ggtt.c | 25 +-
drivers/gpu/drm/i915/i915_vma.c| 9
3 files changed, 23 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index b684a62bf3b07..fcc77f120675f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -16,6 +16,8 @@
#include "i915_gem_lmem.h"
#include "i915_gem_mman.h"
+#define VTD_GUARD (168u * I915_GTT_PAGE_SIZE) /* 168 or tile-row PTE padding */
+
static bool gpu_write_needs_clflush(struct drm_i915_gem_object *obj)
{
return !(obj->cache_level == I915_CACHE_NONE ||
@@ -401,6 +403,17 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
if (ret)
return ERR_PTR(ret);
+ /* VT-d may overfetch before/after the vma, so pad with scratch */
+ if (intel_scanout_needs_vtd_wa(i915)) {
+ unsigned int guard = VTD_GUARD;
+
+ if (i915_gem_object_is_tiled(obj))
+ guard = max(guard,
+ i915_gem_object_get_tile_row_size(obj));
+
+ flags |= PIN_OFFSET_GUARD | guard;
+ }
+
/*
* As the user may map the buffer once pinned in the display plane
* (e.g. libkms for the bootup splash), we have to ensure that we
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 717135f5bf5a6..531aca161295c 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -347,27 +347,6 @@ static void nop_clear_range(struct i915_address_space *vm,
{
}
-static void gen8_ggtt_clear_range(struct i915_address_space *vm,
- u64 start, u64 length)
-{
- struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
- unsigned int first_entry = start / I915_GTT_PAGE_SIZE;
- unsigned int num_entries = length / I915_GTT_PAGE_SIZE;
- const gen8_pte_t scratch_pte = vm->scratch[0]->encode;
- gen8_pte_t __iomem *gtt_base =
- (gen8_pte_t __iomem *)ggtt->gsm + first_entry;
- const int max_entries = ggtt_total_entries(ggtt) - first_entry;
- int i;
-
- if (WARN(num_entries > max_entries,
-"First entry = %d; Num entries = %d (max=%d)\n",
-first_entry, num_entries, max_entries))
- num_entries = max_entries;
-
- for (i = 0; i < num_entries; i++)
- gen8_set_pte(>t_base[i], scratch_pte);
-}
-
static void bxt_vtd_ggtt_wa(struct i915_address_space *vm)
{
/*
@@ -953,8 +932,6 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
ggtt->vm.cleanup = gen6_gmch_remove;
ggtt->vm.insert_page = gen8_ggtt_insert_page;
ggtt->vm.clear_range = nop_clear_range;
- if (intel_scanout_needs_vtd_wa(i915))
- ggtt->vm.clear_range = gen8_ggtt_clear_range;
ggtt->vm.insert_entries = gen8_ggtt_insert_entries;
@@ -1102,7 +1079,7 @@ static int gen6_gmch_probe(struct i915_ggtt *ggtt)
ggtt->vm.alloc_pt_dma = alloc_pt_dma;
ggtt->vm.clear_range = nop_clear_range;
- if (!HAS_FULL_PPGTT(i915) || intel_scanout_needs_vtd_wa(i915))
+ if (!HAS_FULL_PPGTT(i915))
ggtt->vm.clear_range = gen6_ggtt_clear_range;
ggtt->vm.insert_page = gen6_ggtt_insert_page;
ggtt->vm.insert_entries = gen6_ggtt_insert_entries;
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index bf0f8d7e13405..f76c2d2fd3e75 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -562,6 +562,10 @@ bool i915_vma_misplaced(const struct i915_vma *vma,
i915_vma_offset(vma) != (flags & PIN_OFFSET_MASK))
return true;
+ if (flags & PIN_OFFSET_GUARD &&
+ vma->guard
[Intel-gfx] [PATCH 1/3] drm/i915: Wrap all access to i915_vma.node.start|size
From: Chris Wilson
We already wrap i915_vma.node.start for use with the GGTT, as there we
can perform additional sanity checks that the node belongs to the GGTT
and fits within the 32b registers. In the next couple of patches, we
will introduce guard pages around the objects _inside_ the drm_mm_node
allocation. That is we will offset the vma->pages so that the first page
is at drm_mm_node.start + vma->guard (not 0 as is currently the case).
All users must then not use i915_vma.node.start directly, but compute
the guard offset, thus all users are converted to use a
i915_vma_offset() wrapper.
The notable exceptions are the selftests that are testing exact
behaviour of i915_vma_pin/i915_vma_insert.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/display/intel_dpt.c | 4 +-
drivers/gpu/drm/i915/display/intel_fbdev.c| 2 +-
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 37 ++-
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_tiling.c| 4 +-
.../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +-
.../i915/gem/selftests/i915_gem_client_blt.c | 15
.../drm/i915/gem/selftests/i915_gem_context.c | 19 +++---
.../drm/i915/gem/selftests/i915_gem_mman.c| 2 +-
.../drm/i915/gem/selftests/igt_gem_utils.c| 7 ++--
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 2 +-
drivers/gpu/drm/i915/gt/gen7_renderclear.c| 2 +-
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 8 ++--
drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +-
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 3 +-
drivers/gpu/drm/i915/gt/intel_ppgtt.c | 7 +++-
drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +-
.../gpu/drm/i915/gt/intel_ring_submission.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 12 +++---
drivers/gpu/drm/i915/gt/selftest_execlists.c | 18 -
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 17 +
drivers/gpu/drm/i915/gt/selftest_lrc.c| 16
.../drm/i915/gt/selftest_ring_submission.c| 2 +-
drivers/gpu/drm/i915/gt/selftest_rps.c| 12 +++---
.../gpu/drm/i915/gt/selftest_workarounds.c| 8 ++--
drivers/gpu/drm/i915/i915_cmd_parser.c| 4 +-
drivers/gpu/drm/i915/i915_debugfs.c | 3 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 4 +-
drivers/gpu/drm/i915/i915_perf.c | 2 +-
drivers/gpu/drm/i915/i915_vma.c | 21 ++-
drivers/gpu/drm/i915/i915_vma.h | 23 ++--
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 12 +-
drivers/gpu/drm/i915/selftests/i915_request.c | 20 +-
drivers/gpu/drm/i915/selftests/igt_spinner.c | 11 --
35 files changed, 178 insertions(+), 131 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
b/drivers/gpu/drm/i915/display/intel_dpt.c
index de62bd77b15e6..eb32d7b0d25e9 100644
--- a/drivers/gpu/drm/i915/display/intel_dpt.c
+++ b/drivers/gpu/drm/i915/display/intel_dpt.c
@@ -64,7 +64,7 @@ static void dpt_insert_entries(struct i915_address_space *vm,
* not to allow the user to override access to a read only page.
*/
- i = vma->node.start / I915_GTT_PAGE_SIZE;
+ i = i915_vma_offset(vma) / I915_GTT_PAGE_SIZE;
for_each_sgt_daddr(addr, sgt_iter, vma->pages)
gen8_set_pte(&base[i++], pte_encode | addr);
}
@@ -104,7 +104,7 @@ static void dpt_bind_vma(struct i915_address_space *vm,
static void dpt_unbind_vma(struct i915_address_space *vm, struct i915_vma *vma)
{
- vm->clear_range(vm, vma->node.start, vma->size);
+ vm->clear_range(vm, i915_vma_offset(vma), vma->size);
}
static void dpt_cleanup(struct i915_address_space *vm)
diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index adc3a81be9f72..dcd57421749ea 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -261,7 +261,7 @@ static int intelfb_create(struct drm_fb_helper *helper,
/* Our framebuffer is the entirety of fbdev's system memory */
info->fix.smem_start =
- (unsigned long)(ggtt->gmadr.start + vma->node.start);
+ (unsigned long)(ggtt->gmadr.start +
i915_ggtt_offset(vma));
info->fix.smem_len = vma->node.size;
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 78ac4ec9f285c..075d4afdd8a85 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -363,22 +363,23 @@ eb_vma_misplaced(const struct drm_i915_gem_exec_object2
*entry,
const struct i915_vma *vma,
unsigned int flags)
{
- if (vma->node.size
[Intel-gfx] [PATCH 2/3] drm/i915: Introduce guard pages to i915_vma
From: Chris Wilson
Introduce the concept of padding the i915_vma with guard pages before
and after. The major consequence is that all ordinary uses of i915_vma
must use i915_vma_offset/i915_vma_size and not i915_vma.node.start/size
directly, as the drm_mm_node will include the guard pages that surround
our object.
The biggest connundrum is how exactly to mix requesting a fixed address
with guard pages, particularly through the existing uABI. The user does
not know about guard pages, so such must be transparent to the user, and
so the execobj.offset must be that of the object itself excluding the
guard. So a PIN_OFFSET_FIXED must then be exclusive of the guard pages.
The caveat is that some placements will be impossible with guard pages,
as wrap arounds need to be avoided, and the vma itself will require a
larger node. We must not report EINVAL but ENOSPC as these are unavailable
locations within the GTT rather than conflicting user requirements.
In the next patch, we start using guard pages for scanout objects. While
these are limited to GGTT vma, on a few platforms these vma (or at least
an alias of the vma) is shared with userspace, so we may leak the
existence of such guards if we are not careful to ensure that the
execobj.offset is transparent and excludes the guards. (On such platforms
like ivb, without full-ppgtt, userspace has to use relocations so the
presence of more untouchable regions within its GTT such be of no further
issue.)
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Reviewed-by: Matthew Auld
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 12 ++--
drivers/gpu/drm/i915/i915_gem_gtt.h | 1 +
drivers/gpu/drm/i915/i915_vma.c | 28 ++-
drivers/gpu/drm/i915/i915_vma.h | 5 +++--
drivers/gpu/drm/i915/i915_vma_types.h | 3 ++-
5 files changed, 39 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 6549b8e3adbfc..717135f5bf5a6 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -266,8 +266,12 @@ static void gen8_ggtt_insert_entries(struct
i915_address_space *vm,
gte = (gen8_pte_t __iomem *)ggtt->gsm;
gte += vma->node.start / I915_GTT_PAGE_SIZE;
- end = gte + vma->node.size / I915_GTT_PAGE_SIZE;
+ end = gte + vma->guard / I915_GTT_PAGE_SIZE;
+ while (gte < end)
+ gen8_set_pte(gte++, vm->scratch[0]->encode);
+
+ end += (vma->node.size - vma->guard) / I915_GTT_PAGE_SIZE;
for_each_sgt_daddr(addr, iter, vma->pages)
gen8_set_pte(gte++, pte_encode | addr);
GEM_BUG_ON(gte > end);
@@ -317,8 +321,12 @@ static void gen6_ggtt_insert_entries(struct
i915_address_space *vm,
gte = (gen6_pte_t __iomem *)ggtt->gsm;
gte += vma->node.start / I915_GTT_PAGE_SIZE;
- end = gte + vma->node.size / I915_GTT_PAGE_SIZE;
+ end = gte + vma->guard / I915_GTT_PAGE_SIZE;
+ while (gte < end)
+ gen8_set_pte(gte++, vm->scratch[0]->encode);
+
+ end += (vma->node.size - vma->guard) / I915_GTT_PAGE_SIZE;
for_each_sgt_daddr(addr, iter, vma->pages)
iowrite32(vm->pte_encode(addr, level, flags), gte++);
GEM_BUG_ON(gte > end);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index c9b0ee5e1d237..f3ae9afdee158 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -41,6 +41,7 @@ int i915_gem_gtt_insert(struct i915_address_space *vm,
#define PIN_HIGH BIT_ULL(5)
#define PIN_OFFSET_BIASBIT_ULL(6)
#define PIN_OFFSET_FIXED BIT_ULL(7)
+#define PIN_OFFSET_GUARD BIT_ULL(8)
#define PIN_GLOBAL BIT_ULL(10) /* I915_VMA_GLOBAL_BIND */
#define PIN_USER BIT_ULL(11) /* I915_VMA_LOCAL_BIND */
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 4b4a6dcdc676b..bf0f8d7e13405 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -633,7 +633,7 @@ bool i915_gem_valid_gtt_space(struct i915_vma *vma,
unsigned long color)
static int
i915_vma_insert(struct i915_vma *vma, u64 size, u64 alignment, u64 flags)
{
- unsigned long color;
+ unsigned long color, guard;
u64 start, end;
int ret;
@@ -641,7 +641,7 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64
alignment, u64 flags)
GEM_BUG_ON(drm_mm_node_allocated(&vma->node));
size = max(size, vma->size);
- alignment = max(alignment, vma->display_alignment);
+ alignment = max_t(typeof(alignment), alignment, vma->display_alignment);
if (flags & PIN_MAPPABLE) {
size = max_t(typeof(size), size, vma->fence_size);
alignment = max_t(typeof(alignment),
@@ -652,6 +652,9 @@ i915_vma_insert(struct i915_vma *vm
[Intel-gfx] [PATCH 0/3] add guard patting around i915_vma
Hi, This patch series adds a padding around i915_vma's reducing consequently the need to add scratch to the unused GGTT. This speeds up considerably the boot and resume by several hundreds of milliseconds up to over a full second in slower machines. Andi Chris Wilson (3): drm/i915: Wrap all access to i915_vma.node.start|size drm/i915: Introduce guard pages to i915_vma drm/i915: Refine VT-d scanout workaround drivers/gpu/drm/i915/display/intel_dpt.c | 4 +- drivers/gpu/drm/i915/display/intel_fbdev.c| 2 +- drivers/gpu/drm/i915/gem/i915_gem_domain.c| 13 + .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 37 ++-- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_tiling.c| 4 +- .../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +- .../i915/gem/selftests/i915_gem_client_blt.c | 15 ++--- .../drm/i915/gem/selftests/i915_gem_context.c | 19 -- .../drm/i915/gem/selftests/i915_gem_mman.c| 2 +- .../drm/i915/gem/selftests/igt_gem_utils.c| 7 ++- drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 2 +- drivers/gpu/drm/i915/gt/gen7_renderclear.c| 2 +- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 8 +-- drivers/gpu/drm/i915/gt/intel_ggtt.c | 39 - drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 3 +- drivers/gpu/drm/i915/gt/intel_ppgtt.c | 7 ++- drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +- .../gpu/drm/i915/gt/intel_ring_submission.c | 2 +- drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 12 ++-- drivers/gpu/drm/i915/gt/selftest_execlists.c | 18 +++--- drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 17 +++--- drivers/gpu/drm/i915/gt/selftest_lrc.c| 16 ++--- .../drm/i915/gt/selftest_ring_submission.c| 2 +- drivers/gpu/drm/i915/gt/selftest_rps.c| 12 ++-- .../gpu/drm/i915/gt/selftest_workarounds.c| 8 +-- drivers/gpu/drm/i915/i915_cmd_parser.c| 4 +- drivers/gpu/drm/i915/i915_debugfs.c | 3 +- drivers/gpu/drm/i915/i915_gem_gtt.h | 1 + drivers/gpu/drm/i915/i915_gpu_error.c | 4 +- drivers/gpu/drm/i915/i915_perf.c | 2 +- drivers/gpu/drm/i915/i915_vma.c | 58 ++- drivers/gpu/drm/i915/i915_vma.h | 24 +++- drivers/gpu/drm/i915/i915_vma_types.h | 3 +- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 12 +++- drivers/gpu/drm/i915/selftests/i915_request.c | 20 +++ drivers/gpu/drm/i915/selftests/igt_spinner.c | 11 ++-- 38 files changed, 238 insertions(+), 163 deletions(-) -- 2.37.2
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/3] drm/i915/pps: Add get_pps_idx() hook as part of pps_get_register() cleanup
== Series Details == Series: series starting with [1/3] drm/i915/pps: Add get_pps_idx() hook as part of pps_get_register() cleanup URL : https://patchwork.freedesktop.org/series/110694/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2
[Intel-gfx] [PULL] drm-misc-fixes
Hey Daniel & Dave, Another small pull request. Various small assorted fixes. drm-misc-fixes-2022-11-09: drm-misc-fixes for v6.1-rc5: - HDMI fixes to vc4. - Make panfrost's uapi header compile with C++. - Add rotation quirks for 2 panels. - Fix s/r in amdgpu_vram_mgr_new - Handle 1 gb boundary correctly in panfrost mmu code. The following changes since commit fc007fb815ab5395c3962c09b79a1630b0fbed9c: drm/imx: imx-tve: Fix return type of imx_tve_connector_mode_valid (2022-11-01 14:36:55 +0100) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2022-11-09 for you to fetch changes up to f352262f727215553879705bacbcb208979f3eff: drm/panfrost: Split io-pgtable requests properly (2022-11-09 14:17:39 +) drm-misc-fixes for v6.1-rc5: - HDMI fixes to vc4. - Make panfrost's uapi header compile with C++. - Add rotation quirks for 2 panels. - Fix s/r in amdgpu_vram_mgr_new - Handle 1 gb boundary correctly in panfrost mmu code. Hans de Goede (2): drm: panel-orientation-quirks: Add quirk for Nanote UMPC-01 drm: panel-orientation-quirks: Add quirk for Acer Switch V 10 (SW5-017) Ma Jun (1): drm/amdgpu: Fix the lpfn checking condition in drm buddy Robin Murphy (1): drm/panfrost: Split io-pgtable requests properly Steven Price (1): drm/panfrost: Remove type name from internal struct again Yuan Can (1): drm/vc4: Fix missing platform_unregister_drivers() call in vc4_drm_register() max...@cerno.tech (3): drm/vc4: hdmi: Take our lock to reset the link drm/vc4: hdmi: Fix outdated function name in comment drm/vc4: hdmi: Fix HSM clock too low on Pi4 drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 2 +- drivers/gpu/drm/drm_panel_orientation_quirks.c | 12 +++ drivers/gpu/drm/panfrost/panfrost_mmu.c | 11 +- drivers/gpu/drm/vc4/vc4_drv.c | 7 +++- drivers/gpu/drm/vc4/vc4_hdmi.c | 47 -- drivers/gpu/drm/vc4/vc4_hdmi.h | 1 + include/uapi/drm/panfrost_drm.h | 2 +- 7 files changed, 67 insertions(+), 15 deletions(-)
[Intel-gfx] [RFC 07/13] drm/cgroup: Add ability to query drm cgroup GPU time
From: Tvrtko Ursulin
Add a driver callback and core helper which allow querying the time spent
on GPUs for processes belonging to a group.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/drm_cgroup.c | 24
include/drm/drm_clients.h| 2 ++
include/drm/drm_drv.h| 28
3 files changed, 54 insertions(+)
diff --git a/drivers/gpu/drm/drm_cgroup.c b/drivers/gpu/drm/drm_cgroup.c
index 94e6f39b90c7..06810b4c3ff1 100644
--- a/drivers/gpu/drm/drm_cgroup.c
+++ b/drivers/gpu/drm/drm_cgroup.c
@@ -128,3 +128,27 @@ drm_clients_migrate(struct drm_file *file_priv,
atomic_inc(&clients->num);
list_add_tail_rcu(&file_priv->clink, &clients->file_list);
}
+
+u64 drm_pid_get_active_time_us(struct pid *pid)
+{
+ struct drm_pid_clients *clients;
+ u64 total = 0;
+
+ rcu_read_lock();
+ clients = xa_load(&drm_pid_clients, (unsigned long)pid);
+ if (clients) {
+ struct drm_file *fpriv;
+
+ list_for_each_entry_rcu(fpriv, &clients->file_list, clink) {
+ const struct drm_cgroup_ops *cg_ops =
+ fpriv->minor->dev->driver->cg_ops;
+
+ if (cg_ops && cg_ops->active_time_us)
+ total += cg_ops->active_time_us(fpriv);
+ }
+ }
+ rcu_read_unlock();
+
+ return total;
+}
+EXPORT_SYMBOL_GPL(drm_pid_get_active_time_us);
diff --git a/include/drm/drm_clients.h b/include/drm/drm_clients.h
index fbb8cffdf7a9..b9b8009c28a6 100644
--- a/include/drm/drm_clients.h
+++ b/include/drm/drm_clients.h
@@ -41,4 +41,6 @@ drm_clients_migrate(struct drm_file *file_priv,
}
#endif
+u64 drm_pid_get_active_time_us(struct pid *pid);
+
#endif
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index f6159acb8856..c09fe9bd517f 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -148,6 +148,24 @@ enum drm_driver_feature {
DRIVER_KMS_LEGACY_CONTEXT = BIT(31),
};
+/**
+ * struct drm_cgroup_ops
+ *
+ * This structure contains a number of callbacks that drivers can provide if
+ * they are able to support one or more of the functionalities implemented by
+ * the DRM cgroup controller.
+ */
+struct drm_cgroup_ops {
+ /**
+* @active_time_us:
+*
+* Optional callback for reporting the GPU time consumed by this client.
+*
+* Used by the DRM core when queried by the DRM cgroup controller.
+*/
+ u64 (*active_time_us) (struct drm_file *);
+};
+
/**
* struct drm_driver - DRM driver structure
*
@@ -459,6 +477,16 @@ struct drm_driver {
*/
const struct file_operations *fops;
+#ifdef CONFIG_CGROUP_DRM
+ /**
+* @cg_ops:
+*
+* Optional pointer to driver callbacks facilitating integration with
+* the DRM cgroup controller.
+*/
+ const struct drm_cgroup_ops *cg_ops;
+#endif
+
#ifdef CONFIG_DRM_LEGACY
/* Everything below here is for legacy driver, never use! */
/* private: */
--
2.34.1
[Intel-gfx] [RFC 12/13] drm/i915: Wire up with drm controller GPU time query
From: Tvrtko Ursulin
Implement the drm_cgroup_ops->active_time_us callback.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_driver.c | 10
drivers/gpu/drm/i915/i915_drm_client.c | 76 ++
drivers/gpu/drm/i915/i915_drm_client.h | 2 +
3 files changed, 78 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index c3d43f9b1e45..96a7da5258c4 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -1894,6 +1894,12 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_GEM_VM_DESTROY, i915_gem_vm_destroy_ioctl,
DRM_RENDER_ALLOW),
};
+#ifdef CONFIG_CGROUP_DRM
+static const struct drm_cgroup_ops i915_drm_cgroup_ops = {
+ .active_time_us = i915_drm_cgroup_get_active_time_us,
+};
+#endif
+
/*
* Interface history:
*
@@ -1922,6 +1928,10 @@ static const struct drm_driver i915_drm_driver = {
.lastclose = i915_driver_lastclose,
.postclose = i915_driver_postclose,
+#ifdef CONFIG_CGROUP_DRM
+ .cg_ops = &i915_drm_cgroup_ops,
+#endif
+
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_import = i915_gem_prime_import,
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
b/drivers/gpu/drm/i915/i915_drm_client.c
index b09d1d386574..c9754cb0277f 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -75,7 +75,7 @@ void i915_drm_clients_fini(struct i915_drm_clients *clients)
xa_destroy(&clients->xarray);
}
-#ifdef CONFIG_PROC_FS
+#if defined(CONFIG_PROC_FS) || defined(CONFIG_CGROUP_DRM)
static const char * const uabi_class_names[] = {
[I915_ENGINE_CLASS_RENDER] = "render",
[I915_ENGINE_CLASS_COPY] = "copy",
@@ -100,22 +100,78 @@ static u64 busy_add(struct i915_gem_context *ctx,
unsigned int class)
return total;
}
-static void
-show_client_class(struct seq_file *m,
- struct i915_drm_client *client,
- unsigned int class)
+static u64 get_class_active_ns(struct i915_drm_client *client,
+ unsigned int class,
+ unsigned int *capacity)
{
- const struct list_head *list = &client->ctx_list;
- u64 total = atomic64_read(&client->past_runtime[class]);
- const unsigned int capacity =
- client->clients->i915->engine_uabi_class_count[class];
struct i915_gem_context *ctx;
+ u64 total;
+
+ *capacity =
+ client->clients->i915->engine_uabi_class_count[class];
+ if (!*capacity)
+ return 0;
+
+ total = atomic64_read(&client->past_runtime[class]);
rcu_read_lock();
- list_for_each_entry_rcu(ctx, list, client_link)
+ list_for_each_entry_rcu(ctx, &client->ctx_list, client_link)
total += busy_add(ctx, class);
rcu_read_unlock();
+ return total;
+}
+#endif
+
+#ifdef CONFIG_CGROUP_DRM
+static bool supports_stats(struct drm_i915_private *i915)
+{
+ if (GRAPHICS_VER(i915) < 8)
+ return false;
+
+ /* temporary... */
+ if (intel_uc_uses_guc_submission(&to_gt(i915)->uc))
+ return false;
+
+ return true;
+}
+
+u64 i915_drm_cgroup_get_active_time_us(struct drm_file *file)
+{
+ struct drm_i915_file_private *fpriv = file->driver_priv;
+ struct i915_drm_client *client = fpriv->client;
+ unsigned int i;
+ u64 busy = 0;
+
+ if (!supports_stats(client->clients->i915))
+ return 0;
+
+ for (i = 0; i < ARRAY_SIZE(uabi_class_names); i++) {
+ unsigned int capacity;
+ u64 b;
+
+ b = get_class_active_ns(client, i, &capacity);
+ if (capacity) {
+ b = DIV_ROUND_UP_ULL(b, capacity * 1000);
+ busy += b;
+ }
+ }
+
+ return busy;
+}
+#endif
+
+#ifdef CONFIG_PROC_FS
+static void
+show_client_class(struct seq_file *m,
+ struct i915_drm_client *client,
+ unsigned int class)
+{
+ unsigned int capacity;
+ u64 total;
+
+ total = get_class_active_ns(client, class, &capacity);
+
if (capacity)
seq_printf(m, "drm-engine-%s:\t%llu ns\n",
uabi_class_names[class], total);
diff --git a/drivers/gpu/drm/i915/i915_drm_client.h
b/drivers/gpu/drm/i915/i915_drm_client.h
index 69496af996d9..c8439eaa89be 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.h
+++ b/drivers/gpu/drm/i915/i915_drm_client.h
@@ -65,4 +65,6 @@ void i915_drm_client_fdinfo(struct seq_file *m, struct file
*f);
void i915_drm_clients_fini(struct i915_drm_clients *clients);
+u64 i915_drm_cgroup_get_active_time_us(struct drm_file *file);
+
#endif /* !__I915_DRM_CLIENT_H__ */
--
2.34.1
[Intel-gfx] [RFC 06/13] drm/cgroup: Allow safe external access to file_priv
From: Tvrtko Ursulin
Entry points from the cgroup subsystem into the drm cgroup controller will
need to walk the file_priv structures associated with registered clients
and since those are not RCU protected lets add a hack for now to make this
safe.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/drm_cgroup.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/drm_cgroup.c b/drivers/gpu/drm/drm_cgroup.c
index 56aa8303974a..94e6f39b90c7 100644
--- a/drivers/gpu/drm/drm_cgroup.c
+++ b/drivers/gpu/drm/drm_cgroup.c
@@ -17,6 +17,13 @@ __del_clients(struct drm_pid_clients *clients,
if (atomic_dec_and_test(&clients->num)) {
xa_erase(&drm_pid_clients, pid);
kfree_rcu(clients, rcu);
+
+ /*
+* FIXME: file_priv is not RCU protected so we add this hack
+* to avoid any races with code which walks clients->file_list
+* and accesses file_priv.
+*/
+ synchronize_rcu();
}
}
--
2.34.1
[Intel-gfx] [RFC 13/13] drm/i915: Implement cgroup controller over budget throttling
From: Tvrtko Ursulin
When notified by the drm core we are over our allotted time budget, i915
instance will check if any of the GPU engines it is reponsible for is
fully saturated. If it is, and the client in question is using that
engine, it will throttle it.
For now throttling is done simplistically by lowering the scheduling
priority while client is throttled.
Signed-off-by: Tvrtko Ursulin
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 37 +++-
drivers/gpu/drm/i915/i915_driver.c| 1 +
drivers/gpu/drm/i915/i915_drm_client.c| 93 +++
drivers/gpu/drm/i915/i915_drm_client.h| 11 +++
4 files changed, 141 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 1160723c9d2d..280ed90d5001 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -6,6 +6,7 @@
#include
#include
+#include
#include
#include
@@ -3015,6 +3016,40 @@ static void retire_requests(struct intel_timeline *tl,
struct i915_request *end)
break;
}
+#ifdef CONFIG_CGROUP_DRM
+static unsigned int
+__get_class(struct drm_i915_file_private *fpriv, const struct i915_request *rq)
+{
+ unsigned int class;
+
+ class = rq->context->engine->uabi_class;
+
+ if (WARN_ON_ONCE(class >= ARRAY_SIZE(fpriv->client->throttle)))
+ class = 0;
+
+ return class;
+}
+
+static void copy_priority(struct i915_sched_attr *attr,
+ const struct i915_execbuffer *eb,
+ const struct i915_request *rq)
+{
+ struct drm_i915_file_private *file_priv = eb->file->driver_priv;
+
+ *attr = eb->gem_context->sched;
+ if (file_priv->client->throttle[__get_class(file_priv, rq)])
+ attr->priority -=
+ 1 + prandom_u32_max(-I915_CONTEXT_MIN_USER_PRIORITY / 2);
+}
+#else
+static void copy_priority(struct i915_sched_attr *attr,
+ const struct i915_execbuffer *eb,
+ const struct i915_request *rq)
+{
+ *attr = eb->gem_context->sched;
+}
+#endif
+
static int eb_request_add(struct i915_execbuffer *eb, struct i915_request *rq,
int err, bool last_parallel)
{
@@ -3031,7 +3066,7 @@ static int eb_request_add(struct i915_execbuffer *eb,
struct i915_request *rq,
/* Check that the context wasn't destroyed before submission */
if (likely(!intel_context_is_closed(eb->context))) {
- attr = eb->gem_context->sched;
+ copy_priority(&attr, eb, rq);
} else {
/* Serialise with context_close via the add_to_timeline */
i915_request_set_error_once(rq, -ENOENT);
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index 96a7da5258c4..d6c0501af3f4 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -1897,6 +1897,7 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
#ifdef CONFIG_CGROUP_DRM
static const struct drm_cgroup_ops i915_drm_cgroup_ops = {
.active_time_us = i915_drm_cgroup_get_active_time_us,
+ .signal_budget = i915_drm_cgroup_signal_budget,
};
#endif
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
b/drivers/gpu/drm/i915/i915_drm_client.c
index c9754cb0277f..81144c8e8d05 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -4,6 +4,7 @@
*/
#include
+#include
#include
#include
@@ -159,6 +160,98 @@ u64 i915_drm_cgroup_get_active_time_us(struct drm_file
*file)
return busy;
}
+
+int i915_drm_cgroup_signal_budget(struct drm_file *file, u64 usage, u64 budget)
+{
+ struct drm_i915_file_private *fpriv = file->driver_priv;
+ u64 class_usage[I915_LAST_UABI_ENGINE_CLASS + 1];
+ u64 class_last[I915_LAST_UABI_ENGINE_CLASS + 1];
+ struct drm_i915_private *i915 = fpriv->dev_priv;
+ struct i915_drm_client *client = fpriv->client;
+ struct intel_engine_cs *engine;
+ bool over = usage > budget;
+ unsigned int i;
+ ktime_t unused;
+ int ret = 0;
+ u64 t;
+
+ if (!supports_stats(i915))
+ return -EINVAL;
+
+ if (usage == 0 && budget == 0)
+ return 0;
+
+printk("i915_drm_cgroup_signal_budget client-id=%u over=%u (%llu/%llu) <%u>\n",
+ client->id, over, usage, budget, client->over_budget);
+
+ if (over) {
+ client->over_budget++;
+ if (!client->over_budget)
+ client->over_budget = 2;
+ } else {
+ client->over_budget = 0;
+ memset(client->class_last, 0, sizeof(client->class_last));
+ memset(client->throttle, 0, sizeof(client->throttle));
+ return 0;
+ }
+
+ memset(class_usage, 0, sizeof
[Intel-gfx] [RFC 09/13] drm/cgroup: Only track clients which are providing drm_cgroup_ops
From: Tvrtko Ursulin
To reduce the number of tracking going on, especially with drivers which
will not support any sort of control from the drm cgroup controller side,
lets express the funcionality as opt-in and use the presence of
drm_cgroup_ops as activation criteria.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/drm_cgroup.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/drm_cgroup.c b/drivers/gpu/drm/drm_cgroup.c
index e3854741c584..d3050c744e3e 100644
--- a/drivers/gpu/drm/drm_cgroup.c
+++ b/drivers/gpu/drm/drm_cgroup.c
@@ -35,6 +35,9 @@ void drm_clients_close(struct drm_file *file_priv)
lockdep_assert_held(&dev->filelist_mutex);
+ if (!dev->driver->cg_ops)
+ return;
+
pid = rcu_access_pointer(file_priv->pid);
clients = xa_load(&drm_pid_clients, (unsigned long)pid);
if (WARN_ON_ONCE(!clients))
@@ -66,6 +69,9 @@ int drm_clients_open(struct drm_file *file_priv)
lockdep_assert_held(&dev->filelist_mutex);
+ if (!dev->driver->cg_ops)
+ return 0;
+
pid = (unsigned long)rcu_access_pointer(file_priv->pid);
clients = xa_load(&drm_pid_clients, pid);
if (!clients) {
@@ -101,6 +107,9 @@ drm_clients_migrate(struct drm_file *file_priv,
lockdep_assert_held(&dev->filelist_mutex);
+ if (!dev->driver->cg_ops)
+ return;
+
existing_clients = xa_load(&drm_pid_clients, new);
clients = xa_load(&drm_pid_clients, old);
--
2.34.1
[Intel-gfx] [RFC 10/13] cgroup/drm: Client exit hook
From: Tvrtko Ursulin
We need the ability for DRM core to inform the cgroup controller when a
client has closed a DRM file descriptor. This will allow us not needing
to keep state relating to GPU time usage by tasks sets in the cgroup
controller itself.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/drm_cgroup.c | 8
include/linux/cgroup_drm.h | 4
kernel/cgroup/drm.c | 13 +
3 files changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/drm_cgroup.c b/drivers/gpu/drm/drm_cgroup.c
index d3050c744e3e..31a1bf3c8a43 100644
--- a/drivers/gpu/drm/drm_cgroup.c
+++ b/drivers/gpu/drm/drm_cgroup.c
@@ -5,6 +5,7 @@
#include
#include
+#include
static DEFINE_XARRAY(drm_pid_clients);
@@ -31,6 +32,7 @@ void drm_clients_close(struct drm_file *file_priv)
{
struct drm_device *dev = file_priv->minor->dev;
struct drm_pid_clients *clients;
+ struct task_struct *task;
struct pid *pid;
lockdep_assert_held(&dev->filelist_mutex);
@@ -43,6 +45,12 @@ void drm_clients_close(struct drm_file *file_priv)
if (WARN_ON_ONCE(!clients))
return;
+ task = get_pid_task(pid, PIDTYPE_PID);
+ if (task) {
+ drmcgroup_client_exited(task);
+ put_task_struct(task);
+ }
+
__del_clients(clients, file_priv, (unsigned long)pid);
}
diff --git a/include/linux/cgroup_drm.h b/include/linux/cgroup_drm.h
index bf8abc6b8ebf..2f755b896136 100644
--- a/include/linux/cgroup_drm.h
+++ b/include/linux/cgroup_drm.h
@@ -6,4 +6,8 @@
#ifndef _CGROUP_DRM_H
#define _CGROUP_DRM_H
+struct task_struct;
+
+void drmcgroup_client_exited(struct task_struct *task);
+
#endif /* _CGROUP_DRM_H */
diff --git a/kernel/cgroup/drm.c b/kernel/cgroup/drm.c
index b88c93661df3..e165d8f542cc 100644
--- a/kernel/cgroup/drm.c
+++ b/kernel/cgroup/drm.c
@@ -18,11 +18,24 @@ css_to_drmcs(struct cgroup_subsys_state *css)
return container_of(css, struct drm_cgroup_state, css);
}
+static inline struct drm_cgroup_state *get_task_drmcs(struct task_struct *task)
+{
+ return css_to_drmcs(task_get_css(task, drm_cgrp_id));
+}
+
static void drmcs_free(struct cgroup_subsys_state *css)
{
kfree(css_to_drmcs(css));
}
+void drmcgroup_client_exited(struct task_struct *task)
+{
+ struct drm_cgroup_state *drmcs = get_task_drmcs(task);
+
+ css_put(&drmcs->css);
+}
+EXPORT_SYMBOL_GPL(drmcgroup_client_exited);
+
static struct drm_cgroup_state root_drmcs = {
};
--
2.34.1
[Intel-gfx] [RFC 11/13] cgroup/drm: Introduce weight based drm cgroup control
From: Tvrtko Ursulin
Similar to CPU scheduling, implement a concept of weight in the drm cgroup
controller.
Uses the same range and default as the CPU controller - CGROUP_WEIGHT_MIN,
CGROUP_WEIGHT_DFL and CGROUP_WEIGHT_MAX.
Later each cgroup is assigned a time budget proportionaly based on the
relative weights of it's siblings. This time budget is in turn split by
the group's children and so on.
Children of the root cgroup will be exempt from split budgets and
therefore compete for the GPU time independently and without weight based
control.
This will be used to implement a soft, or best effort signal from drm
cgroup to drm core notifying about groups which are over their allotted
budget.
No guarantees that the limit can be enforced are provided or implied.
Signed-off-by: Tvrtko Ursulin
---
Documentation/admin-guide/cgroup-v2.rst | 37 ++
drivers/gpu/drm/Kconfig | 1 +
init/Kconfig| 1 +
kernel/cgroup/drm.c | 507 +++-
4 files changed, 545 insertions(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/cgroup-v2.rst
b/Documentation/admin-guide/cgroup-v2.rst
index dc254a3cb956..ab115fb4170e 100644
--- a/Documentation/admin-guide/cgroup-v2.rst
+++ b/Documentation/admin-guide/cgroup-v2.rst
@@ -2398,6 +2398,43 @@ HugeTLB Interface Files
hugetlb pages of in this cgroup. Only active in
use hugetlb pages are included. The per-node values are in bytes.
+DRM
+---
+
+The DRM controller allows configuring scheduling soft limits.
+
+DRM scheduling soft limits
+~~
+
+Because of the heterogenous hardware and driver DRM capabilities, soft limits
+are implemented as a loose co-operative (bi-directional) interface between the
+controller and DRM core.
+
+The controller configures the GPU time allowed per group and periodically scans
+the belonging tasks to detect the over budget condition, at which point it
+invokes a callback notifying the DRM core of the condition.
+
+DRM core provides an API to query per process GPU utilization and 2nd API to
+receive notification from the cgroup controller when the group enters or exits
+the over budget condition.
+
+Individual DRM drivers which implement the interface are expected to act on
this
+in the best-effort manner only. There are no guarantees that the soft limits
+will be respected.
+
+DRM scheduling soft limits interface files
+~~
+
+ drm.weight
+ Standard cgroup weight based control [1, 1] used to configure the
+ relative distributing of GPU time between the sibling groups.
+
+ drm.period_us (debugging aid during RFC only)
+ An integer representing the period with which the controller should look
+ at the GPU usage by the group and potentially send the over/under budget
+ signal.
+ Value of zero (defaul) disables the soft limit checking.
+
Misc
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index f30f99166531..e68a58237882 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -7,6 +7,7 @@
#
menuconfig DRM
tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI
support)"
+ default y if CGROUP_DRM=y
depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && HAS_DMA
select DRM_NOMODESET
select DRM_PANEL_ORIENTATION_QUIRKS
diff --git a/init/Kconfig b/init/Kconfig
index 70c08f340961..a39b005b9b8a 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1089,6 +1089,7 @@ config CGROUP_RDMA
config CGROUP_DRM
bool "DRM controller"
+ select DRM
help
Provides the DRM subsystem controller.
diff --git a/kernel/cgroup/drm.c b/kernel/cgroup/drm.c
index e165d8f542cc..c893c3738556 100644
--- a/kernel/cgroup/drm.c
+++ b/kernel/cgroup/drm.c
@@ -8,10 +8,38 @@
#include
#include
+#include
+
struct drm_cgroup_state {
struct cgroup_subsys_state css;
+
+ unsigned int weight;
+ unsigned int period_us;
+
+ bool scanning_suspended;
+ unsigned int suspended_period_us;
+
+ struct delayed_work scan_work;
+
+ /*
+* Below fields are owned and updated by the scan worker. Either the
+* worker accesses them, or worker needs to be suspended and synced
+* before they can be touched from the outside.
+*/
+ ktime_t prev_timestamp;
+
+ unsigned int sum_children_weights;
+
+ u64 per_s_budget_ns;
+ u64 prev_active_us;
+ u64 active_us;
+
+ bool over;
+ bool over_budget;
};
+static DEFINE_MUTEX(drmcg_mutex);
+
static inline struct drm_cgroup_state *
css_to_drmcs(struct cgroup_subsys_state *css)
{
@@ -23,20 +51,479 @@ static inline struct drm_cgroup_state
*get_task_drmcs(struct task_struct *task)
return css_to_drmcs(task_get_css(task, drm_cgrp_id));
}
+static u64 drmcs_get_active_time_us(struct drm_cgroup_state *drmcs)
+{
+ struct
[Intel-gfx] [RFC 08/13] drm/cgroup: Add over budget signalling callback
From: Tvrtko Ursulin
Add a new callback via which the drm cgroup controller is notifying the
drm core that a certain process is above its allotted GPU time.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/drm_cgroup.c | 21 +
include/drm/drm_clients.h| 1 +
include/drm/drm_drv.h| 8
3 files changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/drm_cgroup.c b/drivers/gpu/drm/drm_cgroup.c
index 06810b4c3ff1..e3854741c584 100644
--- a/drivers/gpu/drm/drm_cgroup.c
+++ b/drivers/gpu/drm/drm_cgroup.c
@@ -152,3 +152,24 @@ u64 drm_pid_get_active_time_us(struct pid *pid)
return total;
}
EXPORT_SYMBOL_GPL(drm_pid_get_active_time_us);
+
+void drm_pid_signal_budget(struct pid *pid, u64 usage, u64 budget)
+{
+ struct drm_pid_clients *clients;
+
+ rcu_read_lock();
+ clients = xa_load(&drm_pid_clients, (unsigned long)pid);
+ if (clients) {
+ struct drm_file *fpriv;
+
+ list_for_each_entry_rcu(fpriv, &clients->file_list, clink) {
+ const struct drm_cgroup_ops *cg_ops =
+ fpriv->minor->dev->driver->cg_ops;
+
+ if (cg_ops && cg_ops->signal_budget)
+ cg_ops->signal_budget(fpriv, usage, budget);
+ }
+ }
+ rcu_read_unlock();
+}
+EXPORT_SYMBOL_GPL(drm_pid_signal_budget);
diff --git a/include/drm/drm_clients.h b/include/drm/drm_clients.h
index b9b8009c28a6..356ee92792a6 100644
--- a/include/drm/drm_clients.h
+++ b/include/drm/drm_clients.h
@@ -42,5 +42,6 @@ drm_clients_migrate(struct drm_file *file_priv,
#endif
u64 drm_pid_get_active_time_us(struct pid *pid);
+void drm_pid_signal_budget(struct pid *pid, u64 usage, u64 budget);
#endif
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index c09fe9bd517f..c30afe97f922 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -164,6 +164,14 @@ struct drm_cgroup_ops {
* Used by the DRM core when queried by the DRM cgroup controller.
*/
u64 (*active_time_us) (struct drm_file *);
+
+ /**
+* @signal_budget:
+*
+* Optional callback used by the DRM core to forward over/under GPU time
+* messages sent by the DRM cgroup controller.
+*/
+ int (*signal_budget) (struct drm_file *, u64 used, u64 budget);
};
/**
--
2.34.1
[Intel-gfx] [RFC 04/13] cgroup: Add the DRM cgroup controller
From: Tvrtko Ursulin
Skeleton controller without any functionality.
Signed-off-by: Tvrtko Ursulin
---
include/linux/cgroup_drm.h| 9 ++
include/linux/cgroup_subsys.h | 4 +++
init/Kconfig | 7 +
kernel/cgroup/Makefile| 1 +
kernel/cgroup/drm.c | 54 +++
5 files changed, 75 insertions(+)
create mode 100644 include/linux/cgroup_drm.h
create mode 100644 kernel/cgroup/drm.c
diff --git a/include/linux/cgroup_drm.h b/include/linux/cgroup_drm.h
new file mode 100644
index ..bf8abc6b8ebf
--- /dev/null
+++ b/include/linux/cgroup_drm.h
@@ -0,0 +1,9 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#ifndef _CGROUP_DRM_H
+#define _CGROUP_DRM_H
+
+#endif /* _CGROUP_DRM_H */
diff --git a/include/linux/cgroup_subsys.h b/include/linux/cgroup_subsys.h
index 445235487230..49460494a010 100644
--- a/include/linux/cgroup_subsys.h
+++ b/include/linux/cgroup_subsys.h
@@ -65,6 +65,10 @@ SUBSYS(rdma)
SUBSYS(misc)
#endif
+#if IS_ENABLED(CONFIG_CGROUP_DRM)
+SUBSYS(drm)
+#endif
+
/*
* The following subsystems are not supported on the default hierarchy.
*/
diff --git a/init/Kconfig b/init/Kconfig
index abf65098f1b6..70c08f340961 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1087,6 +1087,13 @@ config CGROUP_RDMA
Attaching processes with active RDMA resources to the cgroup
hierarchy is allowed even if can cross the hierarchy's limit.
+config CGROUP_DRM
+ bool "DRM controller"
+ help
+ Provides the DRM subsystem controller.
+
+ ...
+
config CGROUP_FREEZER
bool "Freezer controller"
help
diff --git a/kernel/cgroup/Makefile b/kernel/cgroup/Makefile
index 12f8457ad1f9..849bd2917477 100644
--- a/kernel/cgroup/Makefile
+++ b/kernel/cgroup/Makefile
@@ -6,4 +6,5 @@ obj-$(CONFIG_CGROUP_PIDS) += pids.o
obj-$(CONFIG_CGROUP_RDMA) += rdma.o
obj-$(CONFIG_CPUSETS) += cpuset.o
obj-$(CONFIG_CGROUP_MISC) += misc.o
+obj-$(CONFIG_CGROUP_DRM) += drm.o
obj-$(CONFIG_CGROUP_DEBUG) += debug.o
diff --git a/kernel/cgroup/drm.c b/kernel/cgroup/drm.c
new file mode 100644
index ..b88c93661df3
--- /dev/null
+++ b/kernel/cgroup/drm.c
@@ -0,0 +1,54 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include
+#include
+#include
+#include
+
+struct drm_cgroup_state {
+ struct cgroup_subsys_state css;
+};
+
+static inline struct drm_cgroup_state *
+css_to_drmcs(struct cgroup_subsys_state *css)
+{
+ return container_of(css, struct drm_cgroup_state, css);
+}
+
+static void drmcs_free(struct cgroup_subsys_state *css)
+{
+ kfree(css_to_drmcs(css));
+}
+
+static struct drm_cgroup_state root_drmcs = {
+};
+
+static struct cgroup_subsys_state *
+drmcs_alloc(struct cgroup_subsys_state *parent_css)
+{
+ struct drm_cgroup_state *drmcs;
+
+ if (!parent_css)
+ return &root_drmcs.css;
+
+ drmcs = kzalloc(sizeof(*drmcs), GFP_KERNEL);
+ if (!drmcs)
+ return ERR_PTR(-ENOMEM);
+
+ return &drmcs->css;
+}
+
+struct cftype files[] = {
+ { } /* Zero entry terminates. */
+};
+
+struct cgroup_subsys drm_cgrp_subsys = {
+ .css_alloc = drmcs_alloc,
+ .css_free = drmcs_free,
+ .early_init = false,
+ .legacy_cftypes = files,
+ .dfl_cftypes= files,
+};
--
2.34.1
[Intel-gfx] [RFC 03/13] drm: Update file owner during use
From: Tvrtko Ursulin
With the typical model where the display server opends the file descriptor
and then hands it over to the client we were showing stale data in
debugfs.
Fix it by updating the drm_file->pid on ioctl access from a different
process.
The field is also made RCU protected to allow for lockless readers. Update
side is protected with dev->filelist_mutex.
Signed-off-by: Tvrtko Ursulin
Cc: "Christian König"
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 6 +++--
drivers/gpu/drm/drm_auth.c | 3 ++-
drivers/gpu/drm/drm_debugfs.c | 10 +
drivers/gpu/drm/drm_file.c | 30 +
drivers/gpu/drm/drm_ioctl.c | 3 +++
drivers/gpu/drm/nouveau/nouveau_drm.c | 5 -
drivers/gpu/drm/vmwgfx/vmwgfx_gem.c | 6 +++--
include/drm/drm_file.h | 13 +--
8 files changed, 64 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index 4b940f8bd72b..d732ffb1c0d8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -958,6 +958,7 @@ static int amdgpu_debugfs_gem_info_show(struct seq_file *m,
void *unused)
list_for_each_entry(file, &dev->filelist, lhead) {
struct task_struct *task;
struct drm_gem_object *gobj;
+ struct pid *pid;
int id;
/*
@@ -967,8 +968,9 @@ static int amdgpu_debugfs_gem_info_show(struct seq_file *m,
void *unused)
* Therefore, we need to protect this ->comm access using RCU.
*/
rcu_read_lock();
- task = pid_task(file->pid, PIDTYPE_TGID);
- seq_printf(m, "pid %8d command %s:\n", pid_nr(file->pid),
+ pid = rcu_dereference(file->pid);
+ task = pid_task(pid, PIDTYPE_TGID);
+ seq_printf(m, "pid %8d command %s:\n", pid_nr(pid),
task ? task->comm : "");
rcu_read_unlock();
diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index cf92a9ae8034..2ed2585ded37 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -235,7 +235,8 @@ static int drm_new_set_master(struct drm_device *dev,
struct drm_file *fpriv)
static int
drm_master_check_perm(struct drm_device *dev, struct drm_file *file_priv)
{
- if (file_priv->pid == task_pid(current) && file_priv->was_master)
+ if (file_priv->was_master &&
+ rcu_access_pointer(file_priv->pid) == task_pid(current))
return 0;
if (!capable(CAP_SYS_ADMIN))
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 42f657772025..cbcd79f01d50 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -90,15 +90,17 @@ static int drm_clients_info(struct seq_file *m, void *data)
*/
mutex_lock(&dev->filelist_mutex);
list_for_each_entry_reverse(priv, &dev->filelist, lhead) {
- struct task_struct *task;
bool is_current_master = drm_is_current_master(priv);
+ struct task_struct *task;
+ struct pid *pid;
- rcu_read_lock(); /* locks pid_task()->comm */
- task = pid_task(priv->pid, PIDTYPE_TGID);
+ rcu_read_lock(); /* Locks priv->pid and pid_task()->comm! */
+ pid = rcu_dereference(priv->pid);
+ task = pid_task(pid, PIDTYPE_PID);
uid = task ? __task_cred(task)->euid : GLOBAL_ROOT_UID;
seq_printf(m, "%20s %5d %3d %c%c %5d %10u\n",
task ? task->comm : "",
- pid_vnr(priv->pid),
+ pid_vnr(pid),
priv->minor->index,
is_current_master ? 'y' : 'n',
priv->authenticated ? 'y' : 'n',
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 5cde5014cea1..4f5cff5c0bea 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -502,6 +502,36 @@ int drm_release(struct inode *inode, struct file *filp)
}
EXPORT_SYMBOL(drm_release);
+void drm_file_update_pid(struct drm_file *filp)
+{
+ struct drm_device *dev;
+ struct pid *pid, *old;
+
+ /* Master nodes are not expected to be passed between processes. */
+ if (filp->was_master)
+ return;
+
+ pid = task_tgid(current);
+
+ /*
+* Quick unlocked check since the model is a single handover followed by
+* exclusive repeated use.
+*/
+ if (pid == rcu_access_pointer(filp->pid))
+ return;
+
+ dev = filp->minor->dev;
+ mutex_lock(&dev->filelist_mutex);
+ old = rcu_replace_pointer(filp->pid, pid, 1);
+ mutex_unlock(&dev->filelist_mutex);
+
+ if (pid !=
[Intel-gfx] [RFC 05/13] drm/cgroup: Track clients per owning process
From: Tvrtko Ursulin
To enable propagation of settings from the cgroup drm controller to drm we
need to start tracking which processes own which drm clients.
Implement that by tracking the struct pid pointer of the owning process in
a new XArray, pointing to a structure containing a list of associated
struct drm_file pointers.
Clients are added and removed under the filelist mutex and RCU list
operations are used below it to allow for lockless lookup.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/drm_cgroup.c | 123 +++
drivers/gpu/drm/drm_file.c | 21 --
include/drm/drm_clients.h| 44 +
include/drm/drm_file.h | 4 ++
5 files changed, 189 insertions(+), 4 deletions(-)
create mode 100644 drivers/gpu/drm/drm_cgroup.c
create mode 100644 include/drm/drm_clients.h
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index c44a54cadb61..4495dda2a720 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -59,6 +59,7 @@ drm-$(CONFIG_DRM_LEGACY) += \
drm_scatter.o \
drm_vm.o
drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
+drm-$(CONFIG_CGROUP_DRM) += drm_cgroup.o
drm-$(CONFIG_COMPAT) += drm_ioc32.o
drm-$(CONFIG_DRM_PANEL) += drm_panel.o
drm-$(CONFIG_OF) += drm_of.o
diff --git a/drivers/gpu/drm/drm_cgroup.c b/drivers/gpu/drm/drm_cgroup.c
new file mode 100644
index ..56aa8303974a
--- /dev/null
+++ b/drivers/gpu/drm/drm_cgroup.c
@@ -0,0 +1,123 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include
+#include
+
+static DEFINE_XARRAY(drm_pid_clients);
+
+static void
+__del_clients(struct drm_pid_clients *clients,
+ struct drm_file *file_priv,
+ unsigned long pid)
+{
+ list_del_rcu(&file_priv->clink);
+ if (atomic_dec_and_test(&clients->num)) {
+ xa_erase(&drm_pid_clients, pid);
+ kfree_rcu(clients, rcu);
+ }
+}
+
+void drm_clients_close(struct drm_file *file_priv)
+{
+ struct drm_device *dev = file_priv->minor->dev;
+ struct drm_pid_clients *clients;
+ struct pid *pid;
+
+ lockdep_assert_held(&dev->filelist_mutex);
+
+ pid = rcu_access_pointer(file_priv->pid);
+ clients = xa_load(&drm_pid_clients, (unsigned long)pid);
+ if (WARN_ON_ONCE(!clients))
+ return;
+
+ __del_clients(clients, file_priv, (unsigned long)pid);
+}
+
+static struct drm_pid_clients *__alloc_clients(void)
+{
+ struct drm_pid_clients *clients;
+
+ clients = kmalloc(sizeof(*clients), GFP_KERNEL);
+ if (clients) {
+ atomic_set(&clients->num, 0);
+ INIT_LIST_HEAD(&clients->file_list);
+ init_rcu_head(&clients->rcu);
+ }
+
+ return clients;
+}
+
+int drm_clients_open(struct drm_file *file_priv)
+{
+ struct drm_device *dev = file_priv->minor->dev;
+ struct drm_pid_clients *clients;
+ bool new_client = false;
+ unsigned long pid;
+
+ lockdep_assert_held(&dev->filelist_mutex);
+
+ pid = (unsigned long)rcu_access_pointer(file_priv->pid);
+ clients = xa_load(&drm_pid_clients, pid);
+ if (!clients) {
+ clients = __alloc_clients();
+ if (!clients)
+ return -ENOMEM;
+ new_client = true;
+ }
+ atomic_inc(&clients->num);
+ list_add_tail_rcu(&file_priv->clink, &clients->file_list);
+ if (new_client) {
+ void *xret;
+
+ xret = xa_store(&drm_pid_clients, pid, clients, GFP_KERNEL);
+ if (xa_err(xret)) {
+ list_del_init(&file_priv->clink);
+ kfree(clients);
+ return PTR_ERR(clients);
+ }
+ }
+
+ return 0;
+}
+
+void
+drm_clients_migrate(struct drm_file *file_priv,
+ unsigned long old,
+ unsigned long new)
+{
+ struct drm_device *dev = file_priv->minor->dev;
+ struct drm_pid_clients *existing_clients;
+ struct drm_pid_clients *clients;
+
+ lockdep_assert_held(&dev->filelist_mutex);
+
+ existing_clients = xa_load(&drm_pid_clients, new);
+ clients = xa_load(&drm_pid_clients, old);
+
+ if (WARN_ON_ONCE(!clients))
+ return;
+ else if (WARN_ON_ONCE(clients == existing_clients))
+ return;
+
+ __del_clients(clients, file_priv, old);
+
+ if (!existing_clients) {
+ void *xret;
+
+ clients = __alloc_clients();
+ if (WARN_ON(!clients))
+ return;
+
+ xret = xa_store(&drm_pid_clients, new, clients, GFP_KERNEL);
+ if (WARN_ON(xa_err(xret)))
+ return;
+ } else {
+ clients = existing_clients;
+ }
+
+ atomic_inc(&clients->num);
+ list_
[Intel-gfx] [RFC 01/13] drm: Replace DRM_DEBUG with drm_dbg_core in file and ioctl handling
From: Tvrtko Ursulin
Replace the deprecated macro with the per-device one.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/drm_file.c | 21 +++--
drivers/gpu/drm/drm_ioc32.c | 13 +++--
drivers/gpu/drm/drm_ioctl.c | 25 +
3 files changed, 31 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index a8b4d918e9a3..ba5041137b29 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -245,10 +245,10 @@ void drm_file_free(struct drm_file *file)
dev = file->minor->dev;
- DRM_DEBUG("comm=\"%s\", pid=%d, dev=0x%lx, open_count=%d\n",
- current->comm, task_pid_nr(current),
- (long)old_encode_dev(file->minor->kdev->devt),
- atomic_read(&dev->open_count));
+ drm_dbg_core(dev, "comm=\"%s\", pid=%d, dev=0x%lx, open_count=%d\n",
+current->comm, task_pid_nr(current),
+(long)old_encode_dev(file->minor->kdev->devt),
+atomic_read(&dev->open_count));
#ifdef CONFIG_DRM_LEGACY
if (drm_core_check_feature(dev, DRIVER_LEGACY) &&
@@ -340,8 +340,8 @@ static int drm_open_helper(struct file *filp, struct
drm_minor *minor)
dev->switch_power_state != DRM_SWITCH_POWER_DYNAMIC_OFF)
return -EINVAL;
- DRM_DEBUG("comm=\"%s\", pid=%d, minor=%d\n", current->comm,
- task_pid_nr(current), minor->index);
+ drm_dbg_core(dev, "comm=\"%s\", pid=%d, minor=%d\n",
+current->comm, task_pid_nr(current), minor->index);
priv = drm_file_alloc(minor);
if (IS_ERR(priv))
@@ -450,11 +450,12 @@ EXPORT_SYMBOL(drm_open);
void drm_lastclose(struct drm_device * dev)
{
- DRM_DEBUG("\n");
+ drm_dbg_core(dev, "\n");
- if (dev->driver->lastclose)
+ if (dev->driver->lastclose) {
dev->driver->lastclose(dev);
- DRM_DEBUG("driver lastclose completed\n");
+ drm_dbg_core(dev, "driver lastclose completed\n");
+ }
if (drm_core_check_feature(dev, DRIVER_LEGACY))
drm_legacy_dev_reinit(dev);
@@ -485,7 +486,7 @@ int drm_release(struct inode *inode, struct file *filp)
if (drm_dev_needs_global_mutex(dev))
mutex_lock(&drm_global_mutex);
- DRM_DEBUG("open_count = %d\n", atomic_read(&dev->open_count));
+ drm_dbg_core(dev, "open_count = %d\n", atomic_read(&dev->open_count));
drm_close_helper(filp);
diff --git a/drivers/gpu/drm/drm_ioc32.c b/drivers/gpu/drm/drm_ioc32.c
index 5d82891c3222..49a743f62b4a 100644
--- a/drivers/gpu/drm/drm_ioc32.c
+++ b/drivers/gpu/drm/drm_ioc32.c
@@ -972,6 +972,7 @@ long drm_compat_ioctl(struct file *filp, unsigned int cmd,
unsigned long arg)
{
unsigned int nr = DRM_IOCTL_NR(cmd);
struct drm_file *file_priv = filp->private_data;
+ struct drm_device *dev = file_priv->minor->dev;
drm_ioctl_compat_t *fn;
int ret;
@@ -986,14 +987,14 @@ long drm_compat_ioctl(struct file *filp, unsigned int
cmd, unsigned long arg)
if (!fn)
return drm_ioctl(filp, cmd, arg);
- DRM_DEBUG("comm=\"%s\", pid=%d, dev=0x%lx, auth=%d, %s\n",
- current->comm, task_pid_nr(current),
- (long)old_encode_dev(file_priv->minor->kdev->devt),
- file_priv->authenticated,
- drm_compat_ioctls[nr].name);
+ drm_dbg_core(dev, "comm=\"%s\", pid=%d, dev=0x%lx, auth=%d, %s\n",
+current->comm, task_pid_nr(current),
+(long)old_encode_dev(file_priv->minor->kdev->devt),
+file_priv->authenticated,
+drm_compat_ioctls[nr].name);
ret = (*fn)(filp, cmd, arg);
if (ret)
- DRM_DEBUG("ret = %d\n", ret);
+ drm_dbg_core(dev, "ret = %d\n", ret);
return ret;
}
EXPORT_SYMBOL(drm_compat_ioctl);
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index ca2a6e6101dc..7c9d66ee917d 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -440,7 +440,7 @@ static int drm_setversion(struct drm_device *dev, void
*data, struct drm_file *f
int drm_noop(struct drm_device *dev, void *data,
struct drm_file *file_priv)
{
- DRM_DEBUG("\n");
+ drm_dbg_core(dev, "\n");
return 0;
}
EXPORT_SYMBOL(drm_noop);
@@ -856,16 +856,16 @@ long drm_ioctl(struct file *filp,
out_size = 0;
ksize = max(max(in_size, out_size), drv_size);
- DRM_DEBUG("comm=\"%s\" pid=%d, dev=0x%lx, auth=%d, %s\n",
- current->comm, task_pid_nr(current),
- (long)old_encode_dev(file_priv->minor->kdev->devt),
- file_priv->authenticated, ioctl->name);
+ drm_dbg_core(dev, "comm=\"%s\" pid=%d, dev=0x%lx, auth=%d, %s\n",
+current->
[Intel-gfx] [RFC 02/13] drm: Track clients by tgid and not tid
From: Tvrtko Ursulin Thread group id (aka pid from userspace point of view) is a more interesting thing to show as an owner of a DRM fd, so track and show that instead of the thread id. In the next patch we will make the owner updated post file descriptor handover, which will also be tgid based to avoid ping-pong when multiple threads access the fd. Signed-off-by: Tvrtko Ursulin Cc: Zack Rusin Cc: linux-graphics-maintai...@vmware.com Cc: Alex Deucher Cc: "Christian König" --- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 2 +- drivers/gpu/drm/drm_debugfs.c | 4 ++-- drivers/gpu/drm/drm_file.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_gem.c | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c index 8ef31d687ef3..4b940f8bd72b 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c @@ -967,7 +967,7 @@ static int amdgpu_debugfs_gem_info_show(struct seq_file *m, void *unused) * Therefore, we need to protect this ->comm access using RCU. */ rcu_read_lock(); - task = pid_task(file->pid, PIDTYPE_PID); + task = pid_task(file->pid, PIDTYPE_TGID); seq_printf(m, "pid %8d command %s:\n", pid_nr(file->pid), task ? task->comm : ""); rcu_read_unlock(); diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c index ee445f4605ba..42f657772025 100644 --- a/drivers/gpu/drm/drm_debugfs.c +++ b/drivers/gpu/drm/drm_debugfs.c @@ -80,7 +80,7 @@ static int drm_clients_info(struct seq_file *m, void *data) seq_printf(m, "%20s %5s %3s master a %5s %10s\n", "command", - "pid", + "tgid", "dev", "uid", "magic"); @@ -94,7 +94,7 @@ static int drm_clients_info(struct seq_file *m, void *data) bool is_current_master = drm_is_current_master(priv); rcu_read_lock(); /* locks pid_task()->comm */ - task = pid_task(priv->pid, PIDTYPE_PID); + task = pid_task(priv->pid, PIDTYPE_TGID); uid = task ? __task_cred(task)->euid : GLOBAL_ROOT_UID; seq_printf(m, "%20s %5d %3d %c%c %5d %10u\n", task ? task->comm : "", diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c index ba5041137b29..5cde5014cea1 100644 --- a/drivers/gpu/drm/drm_file.c +++ b/drivers/gpu/drm/drm_file.c @@ -156,7 +156,7 @@ struct drm_file *drm_file_alloc(struct drm_minor *minor) if (!file) return ERR_PTR(-ENOMEM); - file->pid = get_pid(task_pid(current)); + file->pid = get_pid(task_tgid(current)); file->minor = minor; /* for compatibility root is always authenticated */ diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c b/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c index ce609e7d758f..f2985337aa53 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c @@ -260,7 +260,7 @@ static int vmw_debugfs_gem_info_show(struct seq_file *m, void *unused) * Therefore, we need to protect this ->comm access using RCU. */ rcu_read_lock(); - task = pid_task(file->pid, PIDTYPE_PID); + task = pid_task(file->pid, PIDTYPE_TGID); seq_printf(m, "pid %8d command %s:\n", pid_nr(file->pid), task ? task->comm : ""); rcu_read_unlock(); -- 2.34.1
[Intel-gfx] [RFC v2 00/13] DRM scheduling cgroup controller
From: Tvrtko Ursulin This series contains a proposal for a DRM scheduling cgroup controller which implements a weight based hierarchical GPU usage budget based controller similar in concept to some of the existing controllers. Motivation mostly comes from my earlier proposal where I identified that GPU scheduling lags significantly behind what is available for CPU and IO. Whereas back then I was proposing to somehow tie this with process nice, feedback mostly was that people wanted cgroups. So here it is - in the world of heterogenous computing pipelines I think it is time to do something about this gap. Code is not finished but should survive some light experimenting with. I am sharing it early since the topic has been controversial in the past. I hope to demonstrate there are gains to be had in real world usage(*), today, and that the concepts the proposal relies are well enough established and stable. *) Specifically under ChromeOS which uses cgroups to control CPU bandwith for VMs based on the window focused status. It can be demonstrated how GPU scheduling control can easily be integrated into that setup. There should be no conflict with this proposal and any efforts to implement memory usage based controller. Skeleton DRM cgroup controller is deliberatly purely a skeleton patch where any further functionality can be added with no real conflicts. [In fact, perhaps scheduling is even easier to deal with than memory accounting.] Structure of the series is as follows: 1-3) Improve client ownership tracking in DRM core. 4) Adds a skeleton DRM cgroup controller with no functionality. 5-10) Laying down some infrastructure to enable the controller. 11) The controller itself. 12-13) i915 support for the controller. The proposals defines a delegation of duties between the tree parties: cgroup controller, DRM core and individual drivers. Two way communication interfaces are then defined to enable the delegation to work. DRM scheduling soft limits ~~ Because of the heterogenous hardware and driver DRM capabilities, soft limits are implemented as a loose co-operative (bi-directional) interface between the controller and DRM core. The controller configures the GPU time allowed per group and periodically scans the belonging tasks to detect the over budget condition, at which point it invokes a callback notifying the DRM core of the condition. DRM core provides an API to query per process GPU utilization and 2nd API to receive notification from the cgroup controller when the group enters or exits the over budget condition. Individual DRM drivers which implement the interface are expected to act on this in the best-effort manner only. There are no guarantees that the soft limits will be respected. DRM scheduling soft limits interface files ~~ drm.weight Standard cgroup weight based control [1, 1] used to configure the relative distributing of GPU time between the sibling groups. drm.period_us (Most probably only a debugging aid during RFC phase.) An integer representing the period with which the controller should look at the GPU usage by the group and potentially send the over/under budget signal. Value of zero (defaul) disables the soft limit checking. This builds upon the per client GPU utilisation work which landed recently for a few drivers. My thinking is that in principle, an intersect of drivers which support both that and some sort of scheduling control, like priorities, could also in theory support this controller. Another really interesting angle for this controller is that it mimics the same control menthod used by the CPU scheduler. That is the proportional/weight based GPU time budgeting. Which makes it easy to configure and does not need a new mental model. However, as the introduction mentions, GPUs are much more heterogenous and therefore the controller uses very "soft" wording as to what it promises. The general statement is that it can define budgets, notify clients when they are over them, and let individual drivers implement best effort handling of those conditions. Delegation of duties in the implementation goes likes this: * DRM cgroup controller implements the control files and the scanning loop. * DRM core is required to track all DRM clients belonging to processes so it can answer when asked how much GPU time is a process using. * DRM core also provides a call back which the controller will call when a certain process is over budget. * Individual drivers need to implement two similar hooks, but which work for a single DRM client. Over budget callback and GPU utilisation query. What I have demonstrated in practice is that when wired to i915, in a really primitive way where the over-budget condition simply lowers the scheduling priority, the concept can be almost equally effective as the static priority control. I say almost
[Intel-gfx] [PATCH v2 3/4] drm/i915: split out intel_display_reg_defs.h
Split out the display register helper macros to a separate file. For now, include it from i915_reg.h, but note that there are already files that don't need i915_reg.h, such as intel_audio.c. Cc: Lucas De Marchi Reviewed-by: Ville Syrjälä Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/display/icl_dsi_regs.h | 2 +- .../gpu/drm/i915/display/intel_audio_regs.h | 2 +- .../drm/i915/display/intel_backlight_regs.h | 2 +- .../drm/i915/display/intel_display_reg_defs.h | 53 +++ .../gpu/drm/i915/display/intel_hdcp_regs.h| 2 +- .../gpu/drm/i915/display/intel_mg_phy_regs.h | 2 +- .../drm/i915/display/intel_snps_phy_regs.h| 2 +- drivers/gpu/drm/i915/display/vlv_dsi_regs.h | 2 +- drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 + drivers/gpu/drm/i915/i915_reg.h | 42 +-- drivers/gpu/drm/i915/i915_reg_defs.h | 2 - 11 files changed, 62 insertions(+), 50 deletions(-) create mode 100644 drivers/gpu/drm/i915/display/intel_display_reg_defs.h diff --git a/drivers/gpu/drm/i915/display/icl_dsi_regs.h b/drivers/gpu/drm/i915/display/icl_dsi_regs.h index f78f28b8dd94..d4845ac65acc 100644 --- a/drivers/gpu/drm/i915/display/icl_dsi_regs.h +++ b/drivers/gpu/drm/i915/display/icl_dsi_regs.h @@ -6,7 +6,7 @@ #ifndef __ICL_DSI_REGS_H__ #define __ICL_DSI_REGS_H__ -#include "i915_reg_defs.h" +#include "intel_display_reg_defs.h" /* Gen11 DSI */ #define _MMIO_DSI(tc, dsi0, dsi1) _MMIO_TRANS((tc) - TRANSCODER_DSI_0, \ diff --git a/drivers/gpu/drm/i915/display/intel_audio_regs.h b/drivers/gpu/drm/i915/display/intel_audio_regs.h index 4f432c2eb543..616e7b1275c4 100644 --- a/drivers/gpu/drm/i915/display/intel_audio_regs.h +++ b/drivers/gpu/drm/i915/display/intel_audio_regs.h @@ -6,7 +6,7 @@ #ifndef __INTEL_AUDIO_REGS_H__ #define __INTEL_AUDIO_REGS_H__ -#include "i915_reg_defs.h" +#include "intel_display_reg_defs.h" #define G4X_AUD_CNTL_ST_MMIO(0x620B4) #define G4X_ELD_VALIDREG_BIT(14) diff --git a/drivers/gpu/drm/i915/display/intel_backlight_regs.h b/drivers/gpu/drm/i915/display/intel_backlight_regs.h index 50c1210f6d5d..344eb8096bd2 100644 --- a/drivers/gpu/drm/i915/display/intel_backlight_regs.h +++ b/drivers/gpu/drm/i915/display/intel_backlight_regs.h @@ -6,7 +6,7 @@ #ifndef __INTEL_BACKLIGHT_REGS_H__ #define __INTEL_BACKLIGHT_REGS_H__ -#include "i915_reg_defs.h" +#include "intel_display_reg_defs.h" #define _VLV_BLC_PWM_CTL2_A (DISPLAY_MMIO_BASE(dev_priv) + 0x61250) #define _VLV_BLC_PWM_CTL2_B (DISPLAY_MMIO_BASE(dev_priv) + 0x61350) diff --git a/drivers/gpu/drm/i915/display/intel_display_reg_defs.h b/drivers/gpu/drm/i915/display/intel_display_reg_defs.h new file mode 100644 index ..02605418ff08 --- /dev/null +++ b/drivers/gpu/drm/i915/display/intel_display_reg_defs.h @@ -0,0 +1,53 @@ +/* SPDX-License-Identifier: MIT */ +/* + * Copyright © 2022 Intel Corporation + */ + +#ifndef __INTEL_DISPLAY_REG_DEFS_H__ +#define __INTEL_DISPLAY_REG_DEFS_H__ + +#include "i915_reg_defs.h" + +#define DISPLAY_MMIO_BASE(dev_priv) (INTEL_INFO(dev_priv)->display.mmio_offset) + +#define VLV_DISPLAY_BASE 0x18 + +/* + * Named helper wrappers around _PICK_EVEN() and _PICK(). + */ +#define _PIPE(pipe, a, b) _PICK_EVEN(pipe, a, b) +#define _PLANE(plane, a, b)_PICK_EVEN(plane, a, b) +#define _TRANS(tran, a, b) _PICK_EVEN(tran, a, b) +#define _PORT(port, a, b) _PICK_EVEN(port, a, b) +#define _PLL(pll, a, b)_PICK_EVEN(pll, a, b) +#define _PHY(phy, a, b)_PICK_EVEN(phy, a, b) + +#define _MMIO_PIPE(pipe, a, b) _MMIO(_PIPE(pipe, a, b)) +#define _MMIO_PLANE(plane, a, b) _MMIO(_PLANE(plane, a, b)) +#define _MMIO_TRANS(tran, a, b)_MMIO(_TRANS(tran, a, b)) +#define _MMIO_PORT(port, a, b) _MMIO(_PORT(port, a, b)) +#define _MMIO_PLL(pll, a, b) _MMIO(_PLL(pll, a, b)) +#define _MMIO_PHY(phy, a, b) _MMIO(_PHY(phy, a, b)) + +#define _PHY3(phy, ...)_PICK(phy, __VA_ARGS__) + +#define _MMIO_PIPE3(pipe, a, b, c) _MMIO(_PICK(pipe, a, b, c)) +#define _MMIO_PORT3(pipe, a, b, c) _MMIO(_PICK(pipe, a, b, c)) +#define _MMIO_PHY3(phy, a, b, c) _MMIO(_PHY3(phy, a, b, c)) +#define _MMIO_PLL3(pll, ...) _MMIO(_PICK(pll, __VA_ARGS__)) + +/* + * Device info offset array based helpers for groups of registers with unevenly + * spaced base offsets. + */ +#define _MMIO_PIPE2(pipe, reg) _MMIO(INTEL_INFO(dev_priv)->display.pipe_offsets[(pipe)] - \ + INTEL_INFO(dev_priv)->display.pipe_offsets[PIPE_A] + \ + DISPLAY_MMIO_BASE(dev_priv) + (reg)) +#define _MMIO_TRANS2(tran, reg) _MMIO(INTEL_INFO(dev_priv)->display.trans_offsets[(tran)] - \ + INTEL_I
[Intel-gfx] [PATCH v2 0/4] drm/i915: header cleanups, cont'd
The remaining patches from [1], rebased. I also realized this conflicts with what Lucas is doing so I'd like to get feedback. [1] https://patchwork.freedesktop.org/series/110404/ Jani Nikula (4): drm/i915/reg: move masked field helpers to i915_reg_defs.h drm/i915/reg: move pick even and pick to reg defs drm/i915: split out intel_display_reg_defs.h drm/i915: stop including i915_irq.h from i915_trace.h drivers/gpu/drm/i915/display/g4x_dp.c | 1 + drivers/gpu/drm/i915/display/g4x_hdmi.c | 1 + drivers/gpu/drm/i915/display/i9xx_plane.c | 4 +- drivers/gpu/drm/i915/display/icl_dsi.c| 1 + drivers/gpu/drm/i915/display/icl_dsi_regs.h | 2 +- .../gpu/drm/i915/display/intel_audio_regs.h | 2 +- .../gpu/drm/i915/display/intel_backlight.c| 1 + .../drm/i915/display/intel_backlight_regs.h | 2 +- drivers/gpu/drm/i915/display/intel_cdclk.c| 1 + drivers/gpu/drm/i915/display/intel_color.c| 1 + .../gpu/drm/i915/display/intel_combo_phy.c| 1 + drivers/gpu/drm/i915/display/intel_crt.c | 2 + drivers/gpu/drm/i915/display/intel_cursor.c | 3 +- drivers/gpu/drm/i915/display/intel_ddi.c | 1 + drivers/gpu/drm/i915/display/intel_display.c | 1 + .../drm/i915/display/intel_display_debugfs.c | 2 + .../drm/i915/display/intel_display_reg_defs.h | 53 ++ drivers/gpu/drm/i915/display/intel_dp.c | 1 + drivers/gpu/drm/i915/display/intel_dp_aux.c | 1 + drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 1 + drivers/gpu/drm/i915/display/intel_dp_mst.c | 1 + drivers/gpu/drm/i915/display/intel_dpio_phy.c | 1 + drivers/gpu/drm/i915/display/intel_dpll.c | 1 + drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 1 + drivers/gpu/drm/i915/display/intel_drrs.c | 1 + drivers/gpu/drm/i915/display/intel_dsb.c | 1 + drivers/gpu/drm/i915/display/intel_dvo.c | 1 + drivers/gpu/drm/i915/display/intel_fdi.c | 1 + drivers/gpu/drm/i915/display/intel_gmbus.c| 2 + .../gpu/drm/i915/display/intel_hdcp_regs.h| 2 +- drivers/gpu/drm/i915/display/intel_hdmi.c | 1 + .../gpu/drm/i915/display/intel_lpe_audio.c| 2 + drivers/gpu/drm/i915/display/intel_lspcon.c | 1 + drivers/gpu/drm/i915/display/intel_lvds.c | 1 + .../gpu/drm/i915/display/intel_mg_phy_regs.h | 2 +- .../drm/i915/display/intel_modeset_setup.c| 1 + drivers/gpu/drm/i915/display/intel_panel.c| 1 + .../gpu/drm/i915/display/intel_pch_display.c | 1 + .../gpu/drm/i915/display/intel_pch_refclk.c | 1 + drivers/gpu/drm/i915/display/intel_pipe_crc.c | 2 + drivers/gpu/drm/i915/display/intel_pps.c | 1 + drivers/gpu/drm/i915/display/intel_psr.c | 1 + drivers/gpu/drm/i915/display/intel_sdvo.c | 1 + drivers/gpu/drm/i915/display/intel_snps_phy.c | 1 + .../drm/i915/display/intel_snps_phy_regs.h| 2 +- drivers/gpu/drm/i915/display/intel_sprite.c | 1 + drivers/gpu/drm/i915/display/intel_tv.c | 2 + drivers/gpu/drm/i915/display/intel_vdsc.c | 1 + drivers/gpu/drm/i915/display/intel_vga.c | 1 + drivers/gpu/drm/i915/display/intel_vrr.c | 1 + drivers/gpu/drm/i915/display/skl_scaler.c | 2 + .../drm/i915/display/skl_universal_plane.c| 2 + drivers/gpu/drm/i915/display/vlv_dsi.c| 1 + drivers/gpu/drm/i915/display/vlv_dsi_regs.h | 2 +- .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 1 + .../drm/i915/gem/selftests/i915_gem_mman.c| 1 + drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 + .../drm/i915/gt/intel_execlists_submission.c | 1 + drivers/gpu/drm/i915/gt/intel_gt.c| 1 + drivers/gpu/drm/i915/gt/intel_gt_pm.c | 1 + drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 + drivers/gpu/drm/i915/gt/intel_gtt.c | 1 + .../gpu/drm/i915/gt/intel_ring_submission.c | 2 + drivers/gpu/drm/i915/gt/intel_workarounds.c | 1 + .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 1 + drivers/gpu/drm/i915/gvt/cmd_parser.c | 1 + drivers/gpu/drm/i915/gvt/mmio_context.c | 1 + drivers/gpu/drm/i915/i915_gpu_error.c | 1 + drivers/gpu/drm/i915/i915_perf.c | 1 + drivers/gpu/drm/i915/i915_reg.h | 70 +-- drivers/gpu/drm/i915/i915_reg_defs.h | 30 +++- drivers/gpu/drm/i915/i915_trace.h | 1 - drivers/gpu/drm/i915/intel_device_info.c | 3 +- drivers/gpu/drm/i915/intel_uncore.c | 1 + 74 files changed, 166 insertions(+), 82 deletions(-) create mode 100644 drivers/gpu/drm/i915/display/intel_display_reg_defs.h -- 2.34.1
[Intel-gfx] [PATCH v2 4/4] drm/i915: stop including i915_irq.h from i915_trace.h
Turns out many of the files that need i915_reg.h get it implicitly via
{display/intel_de.h, gt/intel_context.h} -> i915_trace.h -> i915_irq.h
-> i915_reg.h. Since i915_trace.h doesn't actually need i915_irq.h,
makes sense to drop it, but that requires adding quite a few new
includes all over the place.
Prefer including i915_reg.h where needed instead of adding another
implicit include, because eventually we'll want to split up i915_reg.h
and only include the specific registers at each place.
Also some places actually needed i915_irq.h too.
Cc: Lucas De Marchi
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/g4x_dp.c| 1 +
drivers/gpu/drm/i915/display/g4x_hdmi.c | 1 +
drivers/gpu/drm/i915/display/i9xx_plane.c| 4 +++-
drivers/gpu/drm/i915/display/icl_dsi.c | 1 +
drivers/gpu/drm/i915/display/intel_backlight.c | 1 +
drivers/gpu/drm/i915/display/intel_cdclk.c | 1 +
drivers/gpu/drm/i915/display/intel_color.c | 1 +
drivers/gpu/drm/i915/display/intel_combo_phy.c | 1 +
drivers/gpu/drm/i915/display/intel_crt.c | 2 ++
drivers/gpu/drm/i915/display/intel_cursor.c | 3 ++-
drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
drivers/gpu/drm/i915/display/intel_display.c | 1 +
drivers/gpu/drm/i915/display/intel_display_debugfs.c | 2 ++
drivers/gpu/drm/i915/display/intel_dp.c | 1 +
drivers/gpu/drm/i915/display/intel_dp_aux.c | 1 +
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 1 +
drivers/gpu/drm/i915/display/intel_dp_mst.c | 1 +
drivers/gpu/drm/i915/display/intel_dpio_phy.c| 1 +
drivers/gpu/drm/i915/display/intel_dpll.c| 1 +
drivers/gpu/drm/i915/display/intel_dpll_mgr.c| 1 +
drivers/gpu/drm/i915/display/intel_drrs.c| 1 +
drivers/gpu/drm/i915/display/intel_dsb.c | 1 +
drivers/gpu/drm/i915/display/intel_dvo.c | 1 +
drivers/gpu/drm/i915/display/intel_fdi.c | 1 +
drivers/gpu/drm/i915/display/intel_gmbus.c | 2 ++
drivers/gpu/drm/i915/display/intel_hdmi.c| 1 +
drivers/gpu/drm/i915/display/intel_lpe_audio.c | 2 ++
drivers/gpu/drm/i915/display/intel_lspcon.c | 1 +
drivers/gpu/drm/i915/display/intel_lvds.c| 1 +
drivers/gpu/drm/i915/display/intel_modeset_setup.c | 1 +
drivers/gpu/drm/i915/display/intel_panel.c | 1 +
drivers/gpu/drm/i915/display/intel_pch_display.c | 1 +
drivers/gpu/drm/i915/display/intel_pch_refclk.c | 1 +
drivers/gpu/drm/i915/display/intel_pipe_crc.c| 2 ++
drivers/gpu/drm/i915/display/intel_pps.c | 1 +
drivers/gpu/drm/i915/display/intel_psr.c | 1 +
drivers/gpu/drm/i915/display/intel_sdvo.c| 1 +
drivers/gpu/drm/i915/display/intel_snps_phy.c| 1 +
drivers/gpu/drm/i915/display/intel_sprite.c | 1 +
drivers/gpu/drm/i915/display/intel_tv.c | 2 ++
drivers/gpu/drm/i915/display/intel_vdsc.c| 1 +
drivers/gpu/drm/i915/display/intel_vga.c | 1 +
drivers/gpu/drm/i915/display/intel_vrr.c | 1 +
drivers/gpu/drm/i915/display/skl_scaler.c| 2 ++
drivers/gpu/drm/i915/display/skl_universal_plane.c | 2 ++
drivers/gpu/drm/i915/display/vlv_dsi.c | 1 +
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 1 +
drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 1 +
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 2 ++
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 1 +
drivers/gpu/drm/i915/gt/intel_gt.c | 1 +
drivers/gpu/drm/i915/gt/intel_gt_pm.c| 1 +
drivers/gpu/drm/i915/gt/intel_gtt.c | 1 +
drivers/gpu/drm/i915/gt/intel_ring_submission.c | 2 ++
drivers/gpu/drm/i915/gt/intel_workarounds.c | 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c| 1 +
drivers/gpu/drm/i915/gvt/cmd_parser.c| 1 +
drivers/gpu/drm/i915/gvt/mmio_context.c | 1 +
drivers/gpu/drm/i915/i915_gpu_error.c| 1 +
drivers/gpu/drm/i915/i915_perf.c | 1 +
drivers/gpu/drm/i915/i915_trace.h| 1 -
drivers/gpu/drm/i915/intel_device_info.c | 3 ++-
drivers/gpu/drm/i915/intel_uncore.c | 1 +
63 files changed, 76 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/g4x_dp.c
b/drivers/gpu/drm/i915/display/g4x_dp.c
index e3e3d27ffb53..3593938dcd87 100644
--- a/drivers/gpu/drm/i915/display/g4x_dp.c
+++ b/drivers/gpu/drm/i915/display/g4x_dp.c
@@ -8,6 +8,7 @@
#include
#include "g4x_dp.h"
+#include "i915_reg.h"
#include "intel_audio.h"
#include "intel_backlight.h"
#include "intel_connector.h"
diff --git a/drivers/gpu/drm/i915/display/g4x_hdmi.c
b/drivers/gpu/drm/i915/display/g4x_hdmi.c
index 8aadf96fa5e9..75ba24c9785f 100644
---
Re: [Intel-gfx] [PATCH v7 16/23] drm/probe-helper: Provide a TV get_modes helper
Hi Noralf,
On Mon, Nov 07, 2022 at 07:11:27PM +0100, Noralf Trønnes wrote:
>
>
> Den 07.11.2022 15.16, skrev Maxime Ripard:
> > From: Noralf Trønnes
> >
> > Most of the TV connectors will need a similar get_modes implementation
> > that will, depending on the drivers' capabilities, register the 480i and
> > 576i modes.
> >
> > That implementation will also need to set the preferred flag and order
> > the modes based on the driver and users preferrence.
> >
> > This is especially important to guarantee that a userspace stack such as
> > Xorg can start and pick up the preferred mode while maintaining a
> > working output.
> >
> > Signed-off-by: Noralf Trønnes
> > Signed-off-by: Maxime Ripard
> >
> > ---
> > Changes in v7:
> > - Used Noralf's implementation
> >
> > Changes in v6:
> > - New patch
> > ---
> > drivers/gpu/drm/drm_probe_helper.c | 97
> > ++
> > include/drm/drm_probe_helper.h | 1 +
> > 2 files changed, 98 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_probe_helper.c
> > b/drivers/gpu/drm/drm_probe_helper.c
> > index 2fc21df709bc..edb2e4c4530a 100644
> > --- a/drivers/gpu/drm/drm_probe_helper.c
> > +++ b/drivers/gpu/drm/drm_probe_helper.c
> > @@ -1147,3 +1147,100 @@ int drm_connector_helper_get_modes(struct
> > drm_connector *connector)
> > return count;
> > }
> > EXPORT_SYMBOL(drm_connector_helper_get_modes);
> > +
> > +static bool tv_mode_supported(struct drm_connector *connector,
> > + enum drm_connector_tv_mode mode)
> > +{
> > + struct drm_device *dev = connector->dev;
> > + struct drm_property *property = dev->mode_config.tv_mode_property;
> > +
> > + unsigned int i;
> > +
> > + for (i = 0; i < property->num_values; i++)
> > + if (property->values[i] == mode)
> > + return true;
> > +
> > + return false;
> > +}
>
> This function is not used in the new implementation.
>
> I hope you have tested this patch since I didn't even compile test my
> implementation (probably should have said so...)
You nailed it ;)
I had tested it (but missed the warning), and added unit tests to make
sure it was behaving properly, and it did. I'll send the unit tests in
my next version.
Thanks
Maxime
[Intel-gfx] [PATCH v2 2/4] drm/i915/reg: move pick even and pick to reg defs
This is a more logical place for generic helpers.
Cc: Lucas De Marchi
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_reg.h | 15 ---
drivers/gpu/drm/i915/i915_reg_defs.h | 15 +++
2 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0d54d69c2eb1..7c478514eaf1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -117,21 +117,6 @@
#define DISPLAY_MMIO_BASE(dev_priv)
(INTEL_INFO(dev_priv)->display.mmio_offset)
-/*
- * Given the first two numbers __a and __b of arbitrarily many evenly spaced
- * numbers, pick the 0-based __index'th value.
- *
- * Always prefer this over _PICK() if the numbers are evenly spaced.
- */
-#define _PICK_EVEN(__index, __a, __b) ((__a) + (__index) * ((__b) - (__a)))
-
-/*
- * Given the arbitrary numbers in varargs, pick the 0-based __index'th number.
- *
- * Always prefer _PICK_EVEN() over this if the numbers are evenly spaced.
- */
-#define _PICK(__index, ...) (((const u32 []){ __VA_ARGS__ })[__index])
-
/*
* Named helper wrappers around _PICK_EVEN() and _PICK().
*/
diff --git a/drivers/gpu/drm/i915/i915_reg_defs.h
b/drivers/gpu/drm/i915/i915_reg_defs.h
index e94558a336f1..aad447ba3e22 100644
--- a/drivers/gpu/drm/i915/i915_reg_defs.h
+++ b/drivers/gpu/drm/i915/i915_reg_defs.h
@@ -111,6 +111,21 @@
#define _MASKED_BIT_ENABLE(a) ({ typeof(a) _a = (a); _MASKED_FIELD(_a, _a); })
#define _MASKED_BIT_DISABLE(a) (_MASKED_FIELD((a), 0))
+/*
+ * Given the first two numbers __a and __b of arbitrarily many evenly spaced
+ * numbers, pick the 0-based __index'th value.
+ *
+ * Always prefer this over _PICK() if the numbers are evenly spaced.
+ */
+#define _PICK_EVEN(__index, __a, __b) ((__a) + (__index) * ((__b) - (__a)))
+
+/*
+ * Given the arbitrary numbers in varargs, pick the 0-based __index'th number.
+ *
+ * Always prefer _PICK_EVEN() over this if the numbers are evenly spaced.
+ */
+#define _PICK(__index, ...) (((const u32 []){ __VA_ARGS__ })[__index])
+
typedef struct {
u32 reg;
} i915_reg_t;
--
2.34.1
[Intel-gfx] [PATCH v2 1/4] drm/i915/reg: move masked field helpers to i915_reg_defs.h
This is a more logical place for generic helpers.
Cc: Lucas De Marchi
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_reg.h | 13 -
drivers/gpu/drm/i915/i915_reg_defs.h | 13 +
2 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index a37ed0c61f20..0d54d69c2eb1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -171,19 +171,6 @@
INTEL_INFO(dev_priv)->display.cursor_offsets[PIPE_A] + \
DISPLAY_MMIO_BASE(dev_priv) +
(reg))
-#define __MASKED_FIELD(mask, value) ((mask) << 16 | (value))
-#define _MASKED_FIELD(mask, value) ({ \
- if (__builtin_constant_p(mask))\
- BUILD_BUG_ON_MSG(((mask) & 0x), "Incorrect mask"); \
- if (__builtin_constant_p(value)) \
- BUILD_BUG_ON_MSG((value) & 0x, "Incorrect value"); \
- if (__builtin_constant_p(mask) && __builtin_constant_p(value)) \
- BUILD_BUG_ON_MSG((value) & ~(mask),\
-"Incorrect value for mask"); \
- __MASKED_FIELD(mask, value); })
-#define _MASKED_BIT_ENABLE(a) ({ typeof(a) _a = (a); _MASKED_FIELD(_a, _a); })
-#define _MASKED_BIT_DISABLE(a) (_MASKED_FIELD((a), 0))
-
#define GU_CNTL_MMIO(0x101010)
#define LMEM_INITREG_BIT(7)
diff --git a/drivers/gpu/drm/i915/i915_reg_defs.h
b/drivers/gpu/drm/i915/i915_reg_defs.h
index f1859046a9c4..e94558a336f1 100644
--- a/drivers/gpu/drm/i915/i915_reg_defs.h
+++ b/drivers/gpu/drm/i915/i915_reg_defs.h
@@ -98,6 +98,19 @@
*/
#define REG_FIELD_GET64(__mask, __val) ((u64)FIELD_GET(__mask, __val))
+#define __MASKED_FIELD(mask, value) ((mask) << 16 | (value))
+#define _MASKED_FIELD(mask, value) ({ \
+ if (__builtin_constant_p(mask))\
+ BUILD_BUG_ON_MSG(((mask) & 0x), "Incorrect mask"); \
+ if (__builtin_constant_p(value)) \
+ BUILD_BUG_ON_MSG((value) & 0x, "Incorrect value"); \
+ if (__builtin_constant_p(mask) && __builtin_constant_p(value)) \
+ BUILD_BUG_ON_MSG((value) & ~(mask),\
+"Incorrect value for mask"); \
+ __MASKED_FIELD(mask, value); })
+#define _MASKED_BIT_ENABLE(a) ({ typeof(a) _a = (a); _MASKED_FIELD(_a, _a); })
+#define _MASKED_BIT_DISABLE(a) (_MASKED_FIELD((a), 0))
+
typedef struct {
u32 reg;
} i915_reg_t;
--
2.34.1
Re: [Intel-gfx] [PATCH 3/6] drm/i915: Generalize the PPS vlv_pipe_check() stuff
On Wed, 09 Nov 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Restate the vlv_pipe_check() stuff in terms of PPS index
> (rather than pipe, which it is on VLV/CHV) so that we can
> reuse this same mechanim on other platforms as well.
>
> Cc: Animesh Manna
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_pps.c | 27 ++--
> 1 file changed, 11 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_pps.c
> b/drivers/gpu/drm/i915/display/intel_pps.c
> index 22f5e08d396b..84265096f751 100644
> --- a/drivers/gpu/drm/i915/display/intel_pps.c
> +++ b/drivers/gpu/drm/i915/display/intel_pps.c
> @@ -233,31 +233,26 @@ bxt_power_sequencer_idx(struct intel_dp *intel_dp)
> return backlight_controller;
> }
>
> -typedef bool (*vlv_pipe_check)(struct drm_i915_private *dev_priv,
> -enum pipe pipe);
> +typedef bool (*pps_check)(struct drm_i915_private *dev_priv, int pps_idx);
>
> -static bool vlv_pipe_has_pp_on(struct drm_i915_private *dev_priv,
> -enum pipe pipe)
> +static bool pps_has_pp_on(struct drm_i915_private *dev_priv, int pps_idx)
> {
> - return intel_de_read(dev_priv, PP_STATUS(pipe)) & PP_ON;
> + return intel_de_read(dev_priv, PP_STATUS(pps_idx)) & PP_ON;
> }
>
> -static bool vlv_pipe_has_vdd_on(struct drm_i915_private *dev_priv,
> - enum pipe pipe)
> +static bool pps_has_vdd_on(struct drm_i915_private *dev_priv, int pps_idx)
> {
> - return intel_de_read(dev_priv, PP_CONTROL(pipe)) & EDP_FORCE_VDD;
> + return intel_de_read(dev_priv, PP_CONTROL(pps_idx)) & EDP_FORCE_VDD;
> }
>
> -static bool vlv_pipe_any(struct drm_i915_private *dev_priv,
> - enum pipe pipe)
> +static bool pps_any(struct drm_i915_private *dev_priv, int pps_idx)
> {
> return true;
> }
>
> static enum pipe
> vlv_initial_pps_pipe(struct drm_i915_private *dev_priv,
> - enum port port,
> - vlv_pipe_check pipe_check)
> + enum port port, pps_check check)
> {
> enum pipe pipe;
>
> @@ -268,7 +263,7 @@ vlv_initial_pps_pipe(struct drm_i915_private *dev_priv,
> if (port_sel != PANEL_PORT_SELECT_VLV(port))
> continue;
>
> - if (!pipe_check(dev_priv, pipe))
> + if (!check(dev_priv, pipe))
> continue;
>
> return pipe;
> @@ -289,15 +284,15 @@ vlv_initial_power_sequencer_setup(struct intel_dp
> *intel_dp)
> /* try to find a pipe with this port selected */
> /* first pick one where the panel is on */
> intel_dp->pps.pps_pipe = vlv_initial_pps_pipe(dev_priv, port,
> - vlv_pipe_has_pp_on);
> + pps_has_pp_on);
> /* didn't find one? pick one where vdd is on */
> if (intel_dp->pps.pps_pipe == INVALID_PIPE)
> intel_dp->pps.pps_pipe = vlv_initial_pps_pipe(dev_priv, port,
> -
> vlv_pipe_has_vdd_on);
> + pps_has_vdd_on);
> /* didn't find one? pick one with just the correct port */
> if (intel_dp->pps.pps_pipe == INVALID_PIPE)
> intel_dp->pps.pps_pipe = vlv_initial_pps_pipe(dev_priv, port,
> - vlv_pipe_any);
> + pps_any);
>
> /* didn't find one? just let vlv_power_sequencer_pipe() pick one when
> needed */
> if (intel_dp->pps.pps_pipe == INVALID_PIPE) {
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 2/6] drm/i915: Do panel VBT init early if the VBT declares an explicit panel type
On Wed, 09 Nov 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Lots of ADL machines out there with bogus VBTs that declare
> two eDP child devices. In order for those to work we need to
> figure out which power sequencer to use before we try the EDID
> read. So let's do the panel VBT init early if we can, falling
> back to the post-EDID init otherwise.
>
> The post-EDID init panel_type=0xff approach of assuming the
> power sequencer should already be enabled doesn't really work
> with multiple eDP panels, and currently we just end up using
> the same power sequencer for both eDP ports, which at least
> confuses the wakeref tracking, and potentially also causes us
> to toggle the VDD for the panel when we should not.
So this doesn't actually fix any of that stuff yet because the PPS code
doesn't handle two PPS for ADL yet.
Other than that,
Reviewed-by: Jani Nikula
>
> Cc: Animesh Manna
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/icl_dsi.c| 2 +-
> drivers/gpu/drm/i915/display/intel_bios.c | 56 ++-
> drivers/gpu/drm/i915/display/intel_bios.h | 11 ++--
> .../drm/i915/display/intel_display_types.h| 2 +-
> drivers/gpu/drm/i915/display/intel_dp.c | 7 ++-
> drivers/gpu/drm/i915/display/intel_lvds.c | 4 +-
> drivers/gpu/drm/i915/display/intel_panel.c| 1 +
> drivers/gpu/drm/i915/display/intel_sdvo.c | 2 +-
> drivers/gpu/drm/i915/display/vlv_dsi.c| 2 +-
> 9 files changed, 61 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index e05e7cd6c412..b6b48d25f31e 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -2042,7 +2042,7 @@ void icl_dsi_init(struct drm_i915_private *dev_priv)
> /* attach connector to encoder */
> intel_connector_attach_encoder(intel_connector, encoder);
>
> - intel_bios_init_panel(dev_priv, &intel_connector->panel, NULL, NULL);
> + intel_bios_init_panel_late(dev_priv, &intel_connector->panel, NULL,
> NULL);
>
> mutex_lock(&dev_priv->drm.mode_config.mutex);
> intel_panel_add_vbt_lfp_fixed_mode(intel_connector);
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index c2987f2c2b2e..64f927f6479d 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -620,14 +620,14 @@ static void dump_pnp_id(struct drm_i915_private *i915,
>
> static int opregion_get_panel_type(struct drm_i915_private *i915,
> const struct intel_bios_encoder_data
> *devdata,
> -const struct edid *edid)
> +const struct edid *edid, bool use_fallback)
> {
> return intel_opregion_get_panel_type(i915);
> }
>
> static int vbt_get_panel_type(struct drm_i915_private *i915,
> const struct intel_bios_encoder_data *devdata,
> - const struct edid *edid)
> + const struct edid *edid, bool use_fallback)
> {
> const struct bdb_lvds_options *lvds_options;
>
> @@ -652,7 +652,7 @@ static int vbt_get_panel_type(struct drm_i915_private
> *i915,
>
> static int pnpid_get_panel_type(struct drm_i915_private *i915,
> const struct intel_bios_encoder_data *devdata,
> - const struct edid *edid)
> + const struct edid *edid, bool use_fallback)
> {
> const struct bdb_lvds_lfp_data *data;
> const struct bdb_lvds_lfp_data_ptrs *ptrs;
> @@ -701,9 +701,9 @@ static int pnpid_get_panel_type(struct drm_i915_private
> *i915,
>
> static int fallback_get_panel_type(struct drm_i915_private *i915,
> const struct intel_bios_encoder_data
> *devdata,
> -const struct edid *edid)
> +const struct edid *edid, bool use_fallback)
> {
> - return 0;
> + return use_fallback ? 0 : -1;
> }
>
> enum panel_type {
> @@ -715,13 +715,13 @@ enum panel_type {
>
> static int get_panel_type(struct drm_i915_private *i915,
> const struct intel_bios_encoder_data *devdata,
> - const struct edid *edid)
> + const struct edid *edid, bool use_fallback)
> {
> struct {
> const char *name;
> int (*get_panel_type)(struct drm_i915_private *i915,
> const struct intel_bios_encoder_data
> *devdata,
> - const struct edid *edid);
> + const struct edid *edid, bool
> use_fallback);
> int panel_type;
> } panel_types[] = {
> [PANEL_TYPE_OPREGION] = {
> @@ -744,7 +744,8 @@ st
Re: [Intel-gfx] [PATCH] drm/i915/gsc: Only initialize GSC in tile 0
> > > > > > It looks to me that we need to move the gsc out of the intel_gt instead of > > > workaround the initialization. > > > > The interrupts are handled by gt, so where this should go ? > > > > Ouch, I've seen it now. But still this patch brings me more doubts... > > is gsc really a per-gt thing? if not why the gsc irq is in the gt domain? > if yes why the one in the second tile not operational? > > if it is not a per-tile thing and only the irq is in a bad spot we could > still move it outside gt and make the irq to be redirected. > > well, if it is really a per tile thing but it is fused of, do we have hw > ways to detect that? > > if it is really a tile thing and we don't have better ways to identify > we might want to do with this patch, but add a bit more information on the > reasons and also double checking if by avoiding the initialization we are > sure that we are not going to reach any case of attempting to utilize the > un-initialized gsc. The GSC is present on all tiles but functional only on the first one. There is no way to detect if GSC is functional per-tile. Good point about double check, we have also interrupt handler. Should not fire without GSC running, but better to protect here too. We have code that skip initialization of one of the heads provided by GSC. I'll utilize the same path to disable here, so that should be safe and already broadly tested. Will publish new version soon. -- Alexander (Sasha) Usyskin CSE FW Dev - Host SW Intel Israel (74) Limited
Re: [Intel-gfx] [PATCH 1/6] drm/i915: Introduce intel_panel_init_alloc()
On Wed, 09 Nov 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Introduce a plaec where we can initialize connector->panel
*place
> after it's been allocated. We already have a intel_panel_init()
> so had to get creative with the name and came up with
> intel_panel_init_alloc().
A bit contrived, but no big deal.
Reviewed-by: Jani Nikula
>
> Cc: Animesh Manna
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_connector.c | 2 +-
> drivers/gpu/drm/i915/display/intel_panel.c | 7 +++
> drivers/gpu/drm/i915/display/intel_panel.h | 1 +
> 3 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_connector.c
> b/drivers/gpu/drm/i915/display/intel_connector.c
> index 6205ddd3ded0..562da3b741e2 100644
> --- a/drivers/gpu/drm/i915/display/intel_connector.c
> +++ b/drivers/gpu/drm/i915/display/intel_connector.c
> @@ -54,7 +54,7 @@ int intel_connector_init(struct intel_connector *connector)
> __drm_atomic_helper_connector_reset(&connector->base,
> &conn_state->base);
>
> - INIT_LIST_HEAD(&connector->panel.fixed_modes);
> + intel_panel_init_alloc(connector);
>
> return 0;
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
> b/drivers/gpu/drm/i915/display/intel_panel.c
> index 69ce77711b7c..8e683ab75594 100644
> --- a/drivers/gpu/drm/i915/display/intel_panel.c
> +++ b/drivers/gpu/drm/i915/display/intel_panel.c
> @@ -660,6 +660,13 @@ intel_panel_mode_valid(struct intel_connector *connector,
> return MODE_OK;
> }
>
> +void intel_panel_init_alloc(struct intel_connector *connector)
> +{
> + struct intel_panel *panel = &connector->panel;
> +
> + INIT_LIST_HEAD(&panel->fixed_modes);
> +}
> +
> int intel_panel_init(struct intel_connector *connector)
> {
> struct intel_panel *panel = &connector->panel;
> diff --git a/drivers/gpu/drm/i915/display/intel_panel.h
> b/drivers/gpu/drm/i915/display/intel_panel.h
> index 5c5b5b7f95b6..4b51e1c51da6 100644
> --- a/drivers/gpu/drm/i915/display/intel_panel.h
> +++ b/drivers/gpu/drm/i915/display/intel_panel.h
> @@ -18,6 +18,7 @@ struct intel_connector;
> struct intel_crtc_state;
> struct intel_encoder;
>
> +void intel_panel_init_alloc(struct intel_connector *connector);
> int intel_panel_init(struct intel_connector *connector);
> void intel_panel_fini(struct intel_connector *connector);
> enum drm_connector_status
--
Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] [PATCH 4/4] drm/i915/display: move restore state and ctx under display sub-struct
Move display suspend/resume and display reset modeset state and ctx
members under drm_i915_private display sub-struct.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 14 +++---
drivers/gpu/drm/i915/display/intel_display_core.h | 7 +++
drivers/gpu/drm/i915/i915_drv.h | 3 ---
3 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 63f25d6bf0bf..c50bdcdc9081 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -890,7 +890,7 @@ static bool gpu_reset_clobbers_display(struct
drm_i915_private *dev_priv)
void intel_display_prepare_reset(struct drm_i915_private *dev_priv)
{
- struct drm_modeset_acquire_ctx *ctx = &dev_priv->reset_ctx;
+ struct drm_modeset_acquire_ctx *ctx =
&dev_priv->display.restore.reset_ctx;
struct drm_atomic_state *state;
int ret;
@@ -946,13 +946,13 @@ void intel_display_prepare_reset(struct drm_i915_private
*dev_priv)
return;
}
- dev_priv->modeset_restore_state = state;
+ dev_priv->display.restore.modeset_state = state;
state->acquire_ctx = ctx;
}
void intel_display_finish_reset(struct drm_i915_private *i915)
{
- struct drm_modeset_acquire_ctx *ctx = &i915->reset_ctx;
+ struct drm_modeset_acquire_ctx *ctx = &i915->display.restore.reset_ctx;
struct drm_atomic_state *state;
int ret;
@@ -963,7 +963,7 @@ void intel_display_finish_reset(struct drm_i915_private
*i915)
if (!test_bit(I915_RESET_MODESET, &to_gt(i915)->reset.flags))
return;
- state = fetch_and_zero(&i915->modeset_restore_state);
+ state = fetch_and_zero(&i915->display.restore.modeset_state);
if (!state)
goto unlock;
@@ -2443,7 +2443,7 @@ int intel_display_suspend(struct drm_device *dev)
drm_err(&dev_priv->drm, "Suspending crtc's failed with %i\n",
ret);
else
- dev_priv->modeset_restore_state = state;
+ dev_priv->display.restore.modeset_state = state;
return ret;
}
@@ -8899,14 +8899,14 @@ void i830_disable_pipe(struct drm_i915_private
*dev_priv, enum pipe pipe)
void intel_display_resume(struct drm_device *dev)
{
struct drm_i915_private *i915 = to_i915(dev);
- struct drm_atomic_state *state = i915->modeset_restore_state;
+ struct drm_atomic_state *state = i915->display.restore.modeset_state;
struct drm_modeset_acquire_ctx ctx;
int ret;
if (!HAS_DISPLAY(i915))
return;
- i915->modeset_restore_state = NULL;
+ i915->display.restore.modeset_state = NULL;
if (state)
state->acquire_ctx = &ctx;
diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h
b/drivers/gpu/drm/i915/display/intel_display_core.h
index 7eb705a0fa19..57ddce3ba02b 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -14,6 +14,7 @@
#include
#include
+#include
#include "intel_cdclk.h"
#include "intel_display.h"
@@ -410,6 +411,12 @@ struct intel_display {
unsigned long mask;
} quirks;
+ struct {
+ /* restore state for suspend/resume and display reset */
+ struct drm_atomic_state *modeset_state;
+ struct drm_modeset_acquire_ctx reset_ctx;
+ } restore;
+
struct {
enum {
I915_SAGV_UNKNOWN = 0,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fdf330a29ec0..2f074d7e0d31 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -287,9 +287,6 @@ struct drm_i915_private {
unsigned long gem_quirks;
- struct drm_atomic_state *modeset_restore_state;
- struct drm_modeset_acquire_ctx reset_ctx;
-
struct i915_gem_mm mm;
bool mchbar_need_disable;
--
2.34.1
[Intel-gfx] [PATCH 2/4] drm/i915/display: move hti under display sub-struct
Move display hti/hdport related members under drm_i915_private display
sub-struct.
Prefer adding anonymous sub-structs even for single members that aren't
our own structs.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display_core.h | 10 ++
drivers/gpu/drm/i915/display/intel_hti.c | 10 +-
drivers/gpu/drm/i915/i915_drv.h | 8
3 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h
b/drivers/gpu/drm/i915/display/intel_display_core.h
index 337d8e08ba43..d851d401211f 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -370,6 +370,16 @@ struct intel_display {
struct mutex comp_mutex;
} hdcp;
+ struct {
+ /*
+* HTI (aka HDPORT) state read during initial hw readout. Most
+* platforms don't have HTI, so this will just stay 0. Those
+* that do will use this later to figure out which PLLs and PHYs
+* are unavailable for driver usage.
+*/
+ u32 state;
+ } hti;
+
struct {
struct i915_power_domains domains;
diff --git a/drivers/gpu/drm/i915/display/intel_hti.c
b/drivers/gpu/drm/i915/display/intel_hti.c
index e2b09e96f9a9..7d48f5646274 100644
--- a/drivers/gpu/drm/i915/display/intel_hti.c
+++ b/drivers/gpu/drm/i915/display/intel_hti.c
@@ -16,24 +16,24 @@ void intel_hti_init(struct drm_i915_private *i915)
* any display resources before we create our display outputs.
*/
if (INTEL_INFO(i915)->display.has_hti)
- i915->hti_state = intel_de_read(i915, HDPORT_STATE);
+ i915->display.hti.state = intel_de_read(i915, HDPORT_STATE);
}
bool intel_hti_uses_phy(struct drm_i915_private *i915, enum phy phy)
{
- return i915->hti_state & HDPORT_ENABLED &&
- i915->hti_state & HDPORT_DDI_USED(phy);
+ return i915->display.hti.state & HDPORT_ENABLED &&
+ i915->display.hti.state & HDPORT_DDI_USED(phy);
}
u32 intel_hti_dpll_mask(struct drm_i915_private *i915)
{
- if (!(i915->hti_state & HDPORT_ENABLED))
+ if (!(i915->display.hti.state & HDPORT_ENABLED))
return 0;
/*
* Note: This is subtle. The values must coincide with what's defined
* for the platform.
*/
- return REG_FIELD_GET(HDPORT_DPLL_USED_MASK, i915->hti_state);
+ return REG_FIELD_GET(HDPORT_DPLL_USED_MASK, i915->display.hti.state);
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 05b3300cc4ed..bb88aee2af25 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -300,14 +300,6 @@ struct drm_i915_private {
struct intel_l3_parity l3_parity;
- /*
-* HTI (aka HDPORT) state read during initial hw readout. Most
-* platforms don't have HTI, so this will just stay 0. Those that do
-* will use this later to figure out which PLLs and PHYs are unavailable
-* for driver usage.
-*/
- u32 hti_state;
-
/*
* edram size in MB.
* Cannot be determined by PCIID. You must always read a register.
--
2.34.1
[Intel-gfx] [PATCH 3/4] drm/i915/display: move global_obj_list under display sub-struct
Move display global state member under drm_i915_private display
sub-struct.
Prefer adding anonymous sub-structs even for single members that aren't
our own structs.
Remove a nearby stale comment while at it.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
drivers/gpu/drm/i915/display/intel_display_core.h | 4
drivers/gpu/drm/i915/display/intel_global_state.c | 4 ++--
drivers/gpu/drm/i915/display/intel_global_state.h | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 4
5 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 90219e7abc7c..63f25d6bf0bf 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -8571,7 +8571,7 @@ static void intel_mode_config_init(struct
drm_i915_private *i915)
struct drm_mode_config *mode_config = &i915->drm.mode_config;
drm_mode_config_init(&i915->drm);
- INIT_LIST_HEAD(&i915->global_obj_list);
+ INIT_LIST_HEAD(&i915->display.global.obj_list);
mode_config->min_width = 0;
mode_config->min_height = 0;
diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h
b/drivers/gpu/drm/i915/display/intel_display_core.h
index d851d401211f..7eb705a0fa19 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -344,6 +344,10 @@ struct intel_display {
u32 rx_config;
} fdi;
+ struct {
+ struct list_head obj_list;
+ } global;
+
struct {
/*
* Base address of where the gmbus and gpio blocks are located
diff --git a/drivers/gpu/drm/i915/display/intel_global_state.c
b/drivers/gpu/drm/i915/display/intel_global_state.c
index 7a19215ad844..02b593b1e2ea 100644
--- a/drivers/gpu/drm/i915/display/intel_global_state.c
+++ b/drivers/gpu/drm/i915/display/intel_global_state.c
@@ -45,14 +45,14 @@ void intel_atomic_global_obj_init(struct drm_i915_private
*dev_priv,
obj->state = state;
obj->funcs = funcs;
- list_add_tail(&obj->head, &dev_priv->global_obj_list);
+ list_add_tail(&obj->head, &dev_priv->display.global.obj_list);
}
void intel_atomic_global_obj_cleanup(struct drm_i915_private *dev_priv)
{
struct intel_global_obj *obj, *next;
- list_for_each_entry_safe(obj, next, &dev_priv->global_obj_list, head) {
+ list_for_each_entry_safe(obj, next, &dev_priv->display.global.obj_list,
head) {
list_del(&obj->head);
drm_WARN_ON(&dev_priv->drm, kref_read(&obj->state->ref) != 1);
diff --git a/drivers/gpu/drm/i915/display/intel_global_state.h
b/drivers/gpu/drm/i915/display/intel_global_state.h
index 1f16fa3073c9..f01ee0bb3e5a 100644
--- a/drivers/gpu/drm/i915/display/intel_global_state.h
+++ b/drivers/gpu/drm/i915/display/intel_global_state.h
@@ -27,7 +27,7 @@ struct intel_global_obj {
};
#define intel_for_each_global_obj(obj, dev_priv) \
- list_for_each_entry(obj, &(dev_priv)->global_obj_list, head)
+ list_for_each_entry(obj, &(dev_priv)->display.global.obj_list, head)
#define for_each_new_global_obj_in_state(__state, obj, new_obj_state, __i) \
for ((__i) = 0; \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bb88aee2af25..fdf330a29ec0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -292,10 +292,6 @@ struct drm_i915_private {
struct i915_gem_mm mm;
- /* Kernel Modesetting */
-
- struct list_head global_obj_list;
-
bool mchbar_need_disable;
struct intel_l3_parity l3_parity;
--
2.34.1
[Intel-gfx] [PATCH 1/4] drm/i915/hti: abstract hti handling
The HTI or HDPORT handling is sprinkled around. Centralize to one place.
Add a note about how subtle the mapping from HDPORT_STATE register to
dpll mask actually is.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/display/intel_ddi.c | 9 +
drivers/gpu/drm/i915/display/intel_display.c | 8 +---
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 11 +-
drivers/gpu/drm/i915/display/intel_hti.c | 39 +++
drivers/gpu/drm/i915/display/intel_hti.h | 18 +
drivers/gpu/drm/i915/display/intel_hti_regs.h | 16
drivers/gpu/drm/i915/i915_reg.h | 5 ---
8 files changed, 80 insertions(+), 27 deletions(-)
create mode 100644 drivers/gpu/drm/i915/display/intel_hti.c
create mode 100644 drivers/gpu/drm/i915/display/intel_hti.h
create mode 100644 drivers/gpu/drm/i915/display/intel_hti_regs.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 51704b54317c..cb8232bd315b 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -247,6 +247,7 @@ i915-y += \
display/intel_global_state.o \
display/intel_hdcp.o \
display/intel_hotplug.o \
+ display/intel_hti.o \
display/intel_lpe_audio.o \
display/intel_modeset_verify.o \
display/intel_modeset_setup.o \
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index e95bde5cf060..5be9573bf65c 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -56,6 +56,7 @@
#include "intel_hdcp.h"
#include "intel_hdmi.h"
#include "intel_hotplug.h"
+#include "intel_hti.h"
#include "intel_lspcon.h"
#include "intel_mg_phy_regs.h"
#include "intel_pps.h"
@@ -4113,12 +4114,6 @@ intel_ddi_max_lanes(struct intel_digital_port *dig_port)
return max_lanes;
}
-static bool hti_uses_phy(struct drm_i915_private *i915, enum phy phy)
-{
- return i915->hti_state & HDPORT_ENABLED &&
- i915->hti_state & HDPORT_DDI_USED(phy);
-}
-
static enum hpd_pin xelpd_hpd_pin(struct drm_i915_private *dev_priv,
enum port port)
{
@@ -4247,7 +4242,7 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
enum port port)
* driver. In that case we should skip initializing the corresponding
* outputs.
*/
- if (hti_uses_phy(dev_priv, phy)) {
+ if (intel_hti_uses_phy(dev_priv, phy)) {
drm_dbg_kms(&dev_priv->drm, "PORT %c / PHY %c reserved by
HTI\n",
port_name(port), phy_name(phy));
return;
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 0d3353c403af..90219e7abc7c 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -100,6 +100,7 @@
#include "intel_frontbuffer.h"
#include "intel_hdcp.h"
#include "intel_hotplug.h"
+#include "intel_hti.h"
#include "intel_modeset_verify.h"
#include "intel_modeset_setup.h"
#include "intel_overlay.h"
@@ -8735,12 +8736,7 @@ int intel_modeset_init_nogem(struct drm_i915_private
*i915)
if (i915->display.cdclk.max_cdclk_freq == 0)
intel_update_max_cdclk(i915);
- /*
-* If the platform has HTI, we need to find out whether it has reserved
-* any display resources before we create our display outputs.
-*/
- if (INTEL_INFO(i915)->display.has_hti)
- i915->hti_state = intel_de_read(i915, HDPORT_STATE);
+ intel_hti_init(i915);
/* Just disable it once at startup */
intel_vga_disable(i915);
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index 7c6c094a0a01..28f7dcb170c7 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -30,6 +30,7 @@
#include "intel_dpio_phy.h"
#include "intel_dpll.h"
#include "intel_dpll_mgr.h"
+#include "intel_hti.h"
#include "intel_mg_phy_regs.h"
#include "intel_pch_refclk.h"
#include "intel_tc.h"
@@ -3163,14 +3164,6 @@ static void icl_update_active_dpll(struct
intel_atomic_state *state,
icl_set_active_port_dpll(crtc_state, port_dpll_id);
}
-static u32 intel_get_hti_plls(struct drm_i915_private *i915)
-{
- if (!(i915->hti_state & HDPORT_ENABLED))
- return 0;
-
- return REG_FIELD_GET(HDPORT_DPLL_USED_MASK, i915->hti_state);
-}
-
static int icl_compute_combo_phy_dpll(struct intel_atomic_state *state,
struct intel_crtc *crtc)
{
@@ -3245,7 +3238,7 @@ static int icl_get_combo_phy_dpll(struct
intel_atomic_state *state,
}
/* Eliminate DPLLs from consideration if reserved by HTI */
- dpll_mask &= ~intel_get_hti_plls(dev_priv);
+ dpll_mask &= ~intel_ht
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fake dual eDP VBT fixes
== Series Details ==
Series: drm/i915: Fake dual eDP VBT fixes
URL : https://patchwork.freedesktop.org/series/110693/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12360 -> Patchwork_110693v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110693v1/index.html
Participating hosts (42 -> 39)
--
Additional (1): fi-tgl-dsi
Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-bdw-samus fi-apl-guc
Known issues
Here are the changes found in Patchwork_110693v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-hsw-4770:NOTRUN -> [SKIP][1] ([fdo#109271] / [fdo#111827])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110693v1/fi-hsw-4770/igt@kms_chamel...@common-hpd-after-suspend.html
- bat-adlp-4: NOTRUN -> [SKIP][2] ([fdo#111827])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110693v1/bat-adlp-4/igt@kms_chamel...@common-hpd-after-suspend.html
*
igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size:
- fi-bsw-kefka: [PASS][3] -> [FAIL][4] ([i915#6298])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110693v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
Possible fixes
* igt@gem_tiled_blits@basic:
- fi-pnv-d510:[SKIP][5] ([fdo#109271]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/fi-pnv-d510/igt@gem_tiled_bl...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110693v1/fi-pnv-d510/igt@gem_tiled_bl...@basic.html
* igt@i915_module_load@reload:
- {bat-rpls-2}: [DMESG-WARN][7] ([i915#6434]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/bat-rpls-2/igt@i915_module_l...@reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110693v1/bat-rpls-2/igt@i915_module_l...@reload.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[INCOMPLETE][9] ([i915#4785]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110693v1/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@migrate:
- {bat-adlp-6}: [INCOMPLETE][11] ([i915#7348]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/bat-adlp-6/igt@i915_selftest@l...@migrate.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110693v1/bat-adlp-6/igt@i915_selftest@l...@migrate.html
- bat-adlp-4: [INCOMPLETE][13] ([i915#7308] / [i915#7348]) ->
[PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/bat-adlp-4/igt@i915_selftest@l...@migrate.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110693v1/bat-adlp-4/igt@i915_selftest@l...@migrate.html
* igt@i915_selftest@live@reset:
- {bat-rpls-1}: [DMESG-FAIL][15] ([i915#4983]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/bat-rpls-1/igt@i915_selftest@l...@reset.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110693v1/bat-rpls-1/igt@i915_selftest@l...@reset.html
Warnings
* igt@gem_exec_gttfill@basic:
- fi-pnv-d510:[SKIP][17] ([fdo#109271]) -> [FAIL][18] ([i915#7229])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110693v1/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
[fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4785]: https://g
Re: [Intel-gfx] [PATCH v7 15/23] drm/modes: Introduce more named modes
Den 07.11.2022 15.16, skrev Maxime Ripard:
> Now that we can easily extend the named modes list, let's add a few more
> analog TV modes that were used in the wild, and some unit tests to make
> sure it works as intended.
>
> Signed-off-by: Maxime Ripard
>
> ---
> Changes in v6:
> - Renamed the tests to follow DRM test naming convention
>
> Changes in v5:
> - Switched to KUNIT_ASSERT_NOT_NULL
> ---
> drivers/gpu/drm/drm_modes.c | 2 +
> drivers/gpu/drm/tests/drm_client_modeset_test.c | 54
> +
> 2 files changed, 56 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index 49441cabdd9d..17c5b6108103 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -2272,7 +2272,9 @@ struct drm_named_mode {
>
> static const struct drm_named_mode drm_named_modes[] = {
> NAMED_MODE("NTSC", 13500, 720, 480, DRM_MODE_FLAG_INTERLACE,
> DRM_MODE_TV_MODE_NTSC),
> + NAMED_MODE("NTSC-J", 13500, 720, 480, DRM_MODE_FLAG_INTERLACE,
> DRM_MODE_TV_MODE_NTSC_J),
> NAMED_MODE("PAL", 13500, 720, 576, DRM_MODE_FLAG_INTERLACE,
> DRM_MODE_TV_MODE_PAL),
> + NAMED_MODE("PAL-M", 13500, 720, 480, DRM_MODE_FLAG_INTERLACE,
> DRM_MODE_TV_MODE_PAL_M),
> };
>
> static int drm_mode_parse_cmdline_named_mode(const char *name,
> diff --git a/drivers/gpu/drm/tests/drm_client_modeset_test.c
> b/drivers/gpu/drm/tests/drm_client_modeset_test.c
> index fdfe9e20702e..b3820d25beca 100644
> --- a/drivers/gpu/drm/tests/drm_client_modeset_test.c
> +++ b/drivers/gpu/drm/tests/drm_client_modeset_test.c
> @@ -133,6 +133,32 @@ static void drm_test_pick_cmdline_named_ntsc(struct
> kunit *test)
> KUNIT_EXPECT_TRUE(test, drm_mode_equal(drm_mode_analog_ntsc_480i(drm),
> mode));
> }
>
> +static void drm_test_pick_cmdline_named_ntsc_j(struct kunit *test)
> +{
> + struct drm_client_modeset_test_priv *priv = test->priv;
> + struct drm_device *drm = priv->drm;
> + struct drm_connector *connector = &priv->connector;
> + struct drm_cmdline_mode *cmdline_mode = &connector->cmdline_mode;
> + struct drm_display_mode *mode;
> + const char *cmdline = "NTSC-J";
> + int ret;
> +
> + KUNIT_ASSERT_TRUE(test,
> + drm_mode_parse_command_line_for_connector(cmdline,
> + connector,
> +
> cmdline_mode));
> +
> + mutex_lock(&drm->mode_config.mutex);
> + ret = drm_helper_probe_single_connector_modes(connector, 1920, 1080);
> + mutex_unlock(&drm->mode_config.mutex);
> + KUNIT_ASSERT_GT(test, ret, 0);
> +
> + mode = drm_connector_pick_cmdline_mode(connector);
> + KUNIT_ASSERT_NOT_NULL(test, mode);
> +
> + KUNIT_EXPECT_TRUE(test, drm_mode_equal(drm_mode_analog_ntsc_480i(drm),
> mode));
> +}
> +
> static void drm_test_pick_cmdline_named_pal(struct kunit *test)
> {
> struct drm_client_modeset_test_priv *priv = test->priv;
> @@ -159,10 +185,38 @@ static void drm_test_pick_cmdline_named_pal(struct
> kunit *test)
> KUNIT_EXPECT_TRUE(test, drm_mode_equal(drm_mode_analog_pal_576i(drm),
> mode));
> }
>
> +static void drm_test_pick_cmdline_named_pal_m(struct kunit *test)
> +{
> + struct drm_client_modeset_test_priv *priv = test->priv;
> + struct drm_device *drm = priv->drm;
> + struct drm_connector *connector = &priv->connector;
> + struct drm_cmdline_mode *cmdline_mode = &connector->cmdline_mode;
> + struct drm_display_mode *mode;
> + const char *cmdline = "PAL-M";
> + int ret;
> +
> + KUNIT_ASSERT_TRUE(test,
> + drm_mode_parse_command_line_for_connector(cmdline,
> + connector,
> +
> cmdline_mode));
> +
> + mutex_lock(&drm->mode_config.mutex);
> + ret = drm_helper_probe_single_connector_modes(connector, 1920, 1080);
> + mutex_unlock(&drm->mode_config.mutex);
> + KUNIT_ASSERT_GT(test, ret, 0);
> +
> + mode = drm_connector_pick_cmdline_mode(connector);
> + KUNIT_ASSERT_NOT_NULL(test, mode);
> +
> + KUNIT_EXPECT_TRUE(test, drm_mode_equal(drm_mode_analog_ntsc_480i(drm),
> mode));
> +}
> +
There are 4 named mode tests that are almost identical, should probably
use KUNIT_ARRAY_PARAM like in the parser tests.
This patchset has been going on for a long time now so it can be fixed
later if you don't want to do it now:
Reviewed-by: Noralf Trønnes
> static struct kunit_case drm_test_pick_cmdline_tests[] = {
> KUNIT_CASE(drm_test_pick_cmdline_res_1920_1080_60),
> KUNIT_CASE(drm_test_pick_cmdline_named_ntsc),
> + KUNIT_CASE(drm_test_pick_cmdline_named_ntsc_j),
> KUNIT_CASE(drm_test_pick_cmdline_named_pal),
> + KUNIT_CASE(drm_test_pick_cmdline_named_pal_m),
> {}
> };
>
>
Re: [Intel-gfx] [PATCH 2/3] drm/i915/pps: Enable 2nd pps for dual EDP scenario
On Wed, 09 Nov 2022, "Manna, Animesh" wrote:
>> -Original Message-
>> From: Nikula, Jani
>> Sent: Wednesday, November 9, 2022 5:12 PM
>> To: Manna, Animesh ; intel-
>> g...@lists.freedesktop.org
>> Cc: Manna, Animesh ; Ville Syrjälä
>> ; Shankar, Uma
>> Subject: Re: [PATCH 2/3] drm/i915/pps: Enable 2nd pps for dual EDP scenario
>>
>> On Wed, 09 Nov 2022, Animesh Manna wrote:
>> > From display gen12 onwards to support dual EDP two instances of pps added.
>> > Currently backlight controller and pps instance can be mapped together
>> > for a specific panel. Currently dual PPS support is broken. This patch
>> > fixes it and enables for display 12+.
>> >
>> > v1: Iniital revision.
>> > v2: Called intel_bios_panel_init w/o PNPID before intel_pps_init.
>> > [Jani]
>> > v3: Set pps_id to -1 for pnpid type of panel which will be used by
>> > bxt_power_sequencer_idx() to set 2nd pps instance as default for 2nd
>> > EDP panel. [Jani]
>> > v4: Early return for PANEL_TYPE_FALLBACK. [Jani]
>> > v5: Removed additional pps_id variable and reused backlight
>> > controller. [Jani]
>> >
>> > Cc: Jani Nikula
>> > Cc: Ville Syrjälä
>> > Cc: Uma Shankar
>> > Signed-off-by: Animesh Manna
>> > ---
>> > drivers/gpu/drm/i915/display/intel_bios.c | 9 -
>> > drivers/gpu/drm/i915/display/intel_bios.h | 2 +-
>> > drivers/gpu/drm/i915/display/intel_dp.c | 10 +++---
>> > drivers/gpu/drm/i915/display/intel_pps.c | 12 +++-
>> > 4 files changed, 27 insertions(+), 6 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
>> > b/drivers/gpu/drm/i915/display/intel_bios.c
>> > index c2987f2c2b2e..1c1eea061fbb 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_bios.c
>> > +++ b/drivers/gpu/drm/i915/display/intel_bios.c
>> > @@ -3183,7 +3183,7 @@ void intel_bios_init(struct drm_i915_private *i915)
>> > kfree(oprom_vbt);
>> > }
>> >
>> > -void intel_bios_init_panel(struct drm_i915_private *i915,
>> > +bool intel_bios_init_panel(struct drm_i915_private *i915,
>> >struct intel_panel *panel,
>> >const struct intel_bios_encoder_data *devdata,
>> >const struct edid *edid)
>> > @@ -3192,6 +3192,11 @@ void intel_bios_init_panel(struct
>> > drm_i915_private *i915,
>> >
>> > panel->vbt.panel_type = get_panel_type(i915, devdata, edid);
>> >
>> > + if (panel->vbt.panel_type == PANEL_TYPE_FALLBACK && !edid) {
>>
>> As Ville pointed out, "panel->vbt.panel_type == PANEL_TYPE_FALLBACK" is
>> comparing apples to oranges, and we hit this path only in the rare case that
>> panel_type == 3, regardless of where the panel type originated.
>
> Got it, tried returning some random negative number (for example -2) from
> fallback_get_panel_type() and checking the same here is fixing the WARN_ON.
>
>>
>> This is probably the reason patches 1&2 don't fix the original issue like it
>> should.
>>
>> I remind you that the issue is two eDP having their own pps software states
>> but
>> using the same pps hardware due to conflicting pps index (which is the same
>> as
>> panel->vbt.backlight.controller). This is what we need to solve here.
>
> In this patch we decide to use the specific pps based on port number. Once we
> identify it is PORT B always 2nd instance of PPS will be used. All pps
> register get instantiated with pps_idx 1
> if (backlight_controller == -1) {
> /*
> * Use 2nd PPS instance as default for 2nd EDP panel.
> */
> if (connector->encoder->port == PORT_A)
> return 0;
> else
> return 1;
> }
> Not sure what is toggling the VDD.
The 2nd eDP obviously!
BR,
Jani.
> Anyways I agree patch 3 is not
> needed. Thanks for review.
>
> Regards,
> Animesh
>
>>
>> We get the wakeref imbalance because of two eDP trampling on the same pps
>> hardware. Patch 3 does nothing to address that issue, it just tries to hide
>> the
>> problem.
>>
>>
>> BR,
>> Jani.
>>
>>
>> > + panel->vbt.backlight.controller = -1;
>> > + return true;
>> > + }
>> > +
>> > parse_panel_options(i915, panel);
>> > parse_generic_dtd(i915, panel);
>> > parse_lfp_data(i915, panel);
>> > @@ -3203,6 +3208,8 @@ void intel_bios_init_panel(struct drm_i915_private
>> *i915,
>> > parse_psr(i915, panel);
>> > parse_mipi_config(i915, panel);
>> > parse_mipi_sequence(i915, panel);
>> > +
>> > + return false;
>> > }
>> >
>> > /**
>> > diff --git a/drivers/gpu/drm/i915/display/intel_bios.h
>> > b/drivers/gpu/drm/i915/display/intel_bios.h
>> > index e375405a7828..f8ef0274f3ee 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_bios.h
>> > +++ b/drivers/gpu/drm/i915/display/intel_bios.h
>> > @@ -232,7 +232,7 @@ struct mipi_pps_data { } __packed;
>> >
>> > void intel_bios_init(struct drm_i915_private *dev_priv); -void
>> > intel_bios_init_panel(struct drm_i915_private *
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Fake dual eDP VBT fixes
== Series Details == Series: drm/i915: Fake dual eDP VBT fixes URL : https://patchwork.freedesktop.org/series/110693/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2
Re: [Intel-gfx] [PATCH 2/3] drm/i915/pps: Enable 2nd pps for dual EDP scenario
> -Original Message-
> From: Nikula, Jani
> Sent: Wednesday, November 9, 2022 5:12 PM
> To: Manna, Animesh ; intel-
> g...@lists.freedesktop.org
> Cc: Manna, Animesh ; Ville Syrjälä
> ; Shankar, Uma
> Subject: Re: [PATCH 2/3] drm/i915/pps: Enable 2nd pps for dual EDP scenario
>
> On Wed, 09 Nov 2022, Animesh Manna wrote:
> > From display gen12 onwards to support dual EDP two instances of pps added.
> > Currently backlight controller and pps instance can be mapped together
> > for a specific panel. Currently dual PPS support is broken. This patch
> > fixes it and enables for display 12+.
> >
> > v1: Iniital revision.
> > v2: Called intel_bios_panel_init w/o PNPID before intel_pps_init.
> > [Jani]
> > v3: Set pps_id to -1 for pnpid type of panel which will be used by
> > bxt_power_sequencer_idx() to set 2nd pps instance as default for 2nd
> > EDP panel. [Jani]
> > v4: Early return for PANEL_TYPE_FALLBACK. [Jani]
> > v5: Removed additional pps_id variable and reused backlight
> > controller. [Jani]
> >
> > Cc: Jani Nikula
> > Cc: Ville Syrjälä
> > Cc: Uma Shankar
> > Signed-off-by: Animesh Manna
> > ---
> > drivers/gpu/drm/i915/display/intel_bios.c | 9 -
> > drivers/gpu/drm/i915/display/intel_bios.h | 2 +-
> > drivers/gpu/drm/i915/display/intel_dp.c | 10 +++---
> > drivers/gpu/drm/i915/display/intel_pps.c | 12 +++-
> > 4 files changed, 27 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> > b/drivers/gpu/drm/i915/display/intel_bios.c
> > index c2987f2c2b2e..1c1eea061fbb 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bios.c
> > +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> > @@ -3183,7 +3183,7 @@ void intel_bios_init(struct drm_i915_private *i915)
> > kfree(oprom_vbt);
> > }
> >
> > -void intel_bios_init_panel(struct drm_i915_private *i915,
> > +bool intel_bios_init_panel(struct drm_i915_private *i915,
> >struct intel_panel *panel,
> >const struct intel_bios_encoder_data *devdata,
> >const struct edid *edid)
> > @@ -3192,6 +3192,11 @@ void intel_bios_init_panel(struct
> > drm_i915_private *i915,
> >
> > panel->vbt.panel_type = get_panel_type(i915, devdata, edid);
> >
> > + if (panel->vbt.panel_type == PANEL_TYPE_FALLBACK && !edid) {
>
> As Ville pointed out, "panel->vbt.panel_type == PANEL_TYPE_FALLBACK" is
> comparing apples to oranges, and we hit this path only in the rare case that
> panel_type == 3, regardless of where the panel type originated.
Got it, tried returning some random negative number (for example -2) from
fallback_get_panel_type() and checking the same here is fixing the WARN_ON.
>
> This is probably the reason patches 1&2 don't fix the original issue like it
> should.
>
> I remind you that the issue is two eDP having their own pps software states
> but
> using the same pps hardware due to conflicting pps index (which is the same as
> panel->vbt.backlight.controller). This is what we need to solve here.
In this patch we decide to use the specific pps based on port number. Once we
identify it is PORT B always 2nd instance of PPS will be used. All pps register
get instantiated with pps_idx 1
if (backlight_controller == -1) {
/*
* Use 2nd PPS instance as default for 2nd EDP panel.
*/
if (connector->encoder->port == PORT_A)
return 0;
else
return 1;
}
Not sure what is toggling the VDD. Anyways I agree patch 3 is not needed.
Thanks for review.
Regards,
Animesh
>
> We get the wakeref imbalance because of two eDP trampling on the same pps
> hardware. Patch 3 does nothing to address that issue, it just tries to hide
> the
> problem.
>
>
> BR,
> Jani.
>
>
> > + panel->vbt.backlight.controller = -1;
> > + return true;
> > + }
> > +
> > parse_panel_options(i915, panel);
> > parse_generic_dtd(i915, panel);
> > parse_lfp_data(i915, panel);
> > @@ -3203,6 +3208,8 @@ void intel_bios_init_panel(struct drm_i915_private
> *i915,
> > parse_psr(i915, panel);
> > parse_mipi_config(i915, panel);
> > parse_mipi_sequence(i915, panel);
> > +
> > + return false;
> > }
> >
> > /**
> > diff --git a/drivers/gpu/drm/i915/display/intel_bios.h
> > b/drivers/gpu/drm/i915/display/intel_bios.h
> > index e375405a7828..f8ef0274f3ee 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bios.h
> > +++ b/drivers/gpu/drm/i915/display/intel_bios.h
> > @@ -232,7 +232,7 @@ struct mipi_pps_data { } __packed;
> >
> > void intel_bios_init(struct drm_i915_private *dev_priv); -void
> > intel_bios_init_panel(struct drm_i915_private *dev_priv,
> > +bool intel_bios_init_panel(struct drm_i915_private *dev_priv,
> >struct intel_panel *panel,
> >const struct intel_bios_encoder_data *devdata,
> >
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Partial abandonment of legacy DRM logging macros (rev3)
== Series Details ==
Series: drm/i915: Partial abandonment of legacy DRM logging macros (rev3)
URL : https://patchwork.freedesktop.org/series/110660/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12360 -> Patchwork_110660v3
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110660v3/index.html
Participating hosts (42 -> 40)
--
Additional (1): fi-tgl-dsi
Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-bdw-samus
Known issues
Here are the changes found in Patchwork_110660v3 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_render_tiled_blits@basic:
- fi-apl-guc: [PASS][1] -> [INCOMPLETE][2] ([i915#7056])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/fi-apl-guc/igt@gem_render_tiled_bl...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110660v3/fi-apl-guc/igt@gem_render_tiled_bl...@basic.html
* igt@i915_selftest@live@gt_engines:
- bat-dg1-6: [PASS][3] -> [INCOMPLETE][4] ([i915#4418])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110660v3/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-hsw-4770:NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110660v3/fi-hsw-4770/igt@kms_chamel...@common-hpd-after-suspend.html
- bat-adlp-4: NOTRUN -> [SKIP][6] ([fdo#111827])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110660v3/bat-adlp-4/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-adlp-4: NOTRUN -> [SKIP][7] ([i915#3546])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110660v3/bat-adlp-4/igt@kms_pipe_crc_ba...@suspend-read-crc.html
* igt@runner@aborted:
- bat-dg1-6: NOTRUN -> [FAIL][8] ([i915#4312])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110660v3/bat-dg1-6/igt@run...@aborted.html
Possible fixes
* igt@gem_tiled_blits@basic:
- fi-pnv-d510:[SKIP][9] ([fdo#109271]) -> [PASS][10] +1 similar
issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/fi-pnv-d510/igt@gem_tiled_bl...@basic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110660v3/fi-pnv-d510/igt@gem_tiled_bl...@basic.html
* igt@i915_module_load@reload:
- {bat-rpls-2}: [DMESG-WARN][11] ([i915#6434]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/bat-rpls-2/igt@i915_module_l...@reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110660v3/bat-rpls-2/igt@i915_module_l...@reload.html
* igt@i915_selftest@live@gt_pm:
- {bat-adln-1}: [DMESG-FAIL][13] ([i915#4258]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/bat-adln-1/igt@i915_selftest@live@gt_pm.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110660v3/bat-adln-1/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[INCOMPLETE][15] ([i915#4785]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110660v3/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@migrate:
- {bat-adlp-6}: [INCOMPLETE][17] ([i915#7348]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/bat-adlp-6/igt@i915_selftest@l...@migrate.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110660v3/bat-adlp-6/igt@i915_selftest@l...@migrate.html
- bat-adlp-4: [INCOMPLETE][19] ([i915#7308] / [i915#7348]) ->
[PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/bat-adlp-4/igt@i915_selftest@l...@migrate.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110660v3/bat-adlp-4/igt@i915_selftest@l...@migrate.html
* igt@i915_selftest@live@slpc:
- {bat-adln-1}: [DMESG-FAIL][21] ([i915#6997]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12360/bat-adln-1/igt@i915_selftest@l...@slpc.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110660v3/bat-adln-1/igt@i915_selftest@l...@slpc.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109295]
Re: [Intel-gfx] [PATCH v2] drm/i915/mtl: Media GT and Render GT share common GGTT
On Wed, 09 Nov 2022, Aravind Iddamsetty wrote:
> On XE_LPM+ platforms the media engines are carved out into a separate
> GT but have a common GGTMMADR address range which essentially makes
> the GGTT address space to be shared between media and render GT. As a
> result any updates in GGTT shall invalidate TLB of GTs sharing it and
> similarly any operation on GGTT requiring an action on a GT will have to
> involve all GTs sharing it. setup_private_pat was being done on a per
> GGTT based as that doesn't touch any GGTT structures moved it to per GT
> based.
>
> BSPEC: 63834
>
> v2:
> 1. Add details to commit msg
> 2. includes fix for failure to add item to ggtt->gt_list, as suggested
> by Lucas
> 3. as ggtt_flush() is used only for ggtt drop i915_is_ggtt check within
> it.
> 4. setup_private_pat moved out of intel_gt_tiles_init
>
> Cc: Matt Roper
> Signed-off-by: Aravind Iddamsetty
> ---
> drivers/gpu/drm/i915/gt/intel_ggtt.c | 47 ++---
> drivers/gpu/drm/i915/gt/intel_gt.c| 13 +-
> drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 ++
> drivers/gpu/drm/i915/gt/intel_gtt.h | 4 ++
> drivers/gpu/drm/i915/i915_driver.c| 22 +++---
> drivers/gpu/drm/i915/i915_gem_evict.c | 51 +--
> drivers/gpu/drm/i915/i915_vma.c | 5 ++-
> drivers/gpu/drm/i915/selftests/i915_gem.c | 2 +
> 8 files changed, 112 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> index 2518cebbf931..6ba7e9e8e2ca 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> @@ -8,6 +8,7 @@
> #include
> #include
>
> +#include
> #include
> #include
>
> @@ -196,10 +197,13 @@ void i915_ggtt_suspend_vm(struct i915_address_space *vm)
>
> void i915_ggtt_suspend(struct i915_ggtt *ggtt)
> {
> + struct intel_gt *gt;
> +
> i915_ggtt_suspend_vm(&ggtt->vm);
> ggtt->invalidate(ggtt);
>
> - intel_gt_check_and_clear_faults(ggtt->vm.gt);
> + list_for_each_entry(gt, &ggtt->gt_list, ggtt_link)
> + intel_gt_check_and_clear_faults(gt);
> }
>
> void gen6_ggtt_invalidate(struct i915_ggtt *ggtt)
> @@ -225,16 +229,21 @@ static void gen8_ggtt_invalidate(struct i915_ggtt *ggtt)
>
> static void guc_ggtt_invalidate(struct i915_ggtt *ggtt)
> {
> - struct intel_uncore *uncore = ggtt->vm.gt->uncore;
> struct drm_i915_private *i915 = ggtt->vm.i915;
>
> gen8_ggtt_invalidate(ggtt);
>
> - if (GRAPHICS_VER(i915) >= 12)
> - intel_uncore_write_fw(uncore, GEN12_GUC_TLB_INV_CR,
> - GEN12_GUC_TLB_INV_CR_INVALIDATE);
> - else
> - intel_uncore_write_fw(uncore, GEN8_GTCR, GEN8_GTCR_INVALIDATE);
> + if (GRAPHICS_VER(i915) >= 12) {
> + struct intel_gt *gt;
> +
> + list_for_each_entry(gt, &ggtt->gt_list, ggtt_link)
> + intel_uncore_write_fw(gt->uncore,
> + GEN12_GUC_TLB_INV_CR,
> + GEN12_GUC_TLB_INV_CR_INVALIDATE);
> + } else {
> + intel_uncore_write_fw(ggtt->vm.gt->uncore,
> + GEN8_GTCR, GEN8_GTCR_INVALIDATE);
> + }
> }
>
> u64 gen8_ggtt_pte_encode(dma_addr_t addr,
> @@ -986,8 +995,6 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
>
> ggtt->vm.pte_encode = gen8_ggtt_pte_encode;
>
> - setup_private_pat(ggtt->vm.gt);
> -
> return ggtt_probe_common(ggtt, size);
> }
>
> @@ -1186,7 +1193,7 @@ static int ggtt_probe_hw(struct i915_ggtt *ggtt, struct
> intel_gt *gt)
> (u64)ggtt->mappable_end >> 20);
> drm_dbg(&i915->drm, "DSM size = %lluM\n",
> (u64)resource_size(&intel_graphics_stolen_res) >> 20);
> -
> + INIT_LIST_HEAD(&ggtt->gt_list);
> return 0;
> }
>
> @@ -1208,6 +1215,19 @@ int i915_ggtt_probe_hw(struct drm_i915_private *i915)
> return 0;
> }
>
> +struct i915_ggtt *i915_ggtt_create(struct drm_i915_private *i915)
> +{
> + struct i915_ggtt *ggtt;
> +
> + ggtt = drmm_kzalloc(&i915->drm, sizeof(*ggtt), GFP_KERNEL);
> + if (!ggtt)
> + return ERR_PTR(-ENOMEM);
> +
> + INIT_LIST_HEAD(&ggtt->gt_list);
> +
> + return ggtt;
> +}
> +
> int i915_ggtt_enable_hw(struct drm_i915_private *i915)
> {
> if (GRAPHICS_VER(i915) < 6)
> @@ -1296,9 +1316,11 @@ bool i915_ggtt_resume_vm(struct i915_address_space *vm)
>
> void i915_ggtt_resume(struct i915_ggtt *ggtt)
> {
> + struct intel_gt *gt;
> bool flush;
>
> - intel_gt_check_and_clear_faults(ggtt->vm.gt);
> + list_for_each_entry(gt, &ggtt->gt_list, ggtt_link)
> + intel_gt_check_and_clear_faults(gt);
>
> flush = i915_ggtt_resume_vm(&ggtt->vm);
>
> @@ -1307,9 +1329,6 @@ void i915_ggtt_resume(struct i915_ggtt *ggtt)
> if (flush)
> wbinvd_on_all_c
[Intel-gfx] [PATCH v2] drm/i915/mtl: Media GT and Render GT share common GGTT
On XE_LPM+ platforms the media engines are carved out into a separate
GT but have a common GGTMMADR address range which essentially makes
the GGTT address space to be shared between media and render GT. As a
result any updates in GGTT shall invalidate TLB of GTs sharing it and
similarly any operation on GGTT requiring an action on a GT will have to
involve all GTs sharing it. setup_private_pat was being done on a per
GGTT based as that doesn't touch any GGTT structures moved it to per GT
based.
BSPEC: 63834
v2:
1. Add details to commit msg
2. includes fix for failure to add item to ggtt->gt_list, as suggested
by Lucas
3. as ggtt_flush() is used only for ggtt drop i915_is_ggtt check within
it.
4. setup_private_pat moved out of intel_gt_tiles_init
Cc: Matt Roper
Signed-off-by: Aravind Iddamsetty
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 47 ++---
drivers/gpu/drm/i915/gt/intel_gt.c| 13 +-
drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 ++
drivers/gpu/drm/i915/gt/intel_gtt.h | 4 ++
drivers/gpu/drm/i915/i915_driver.c| 22 +++---
drivers/gpu/drm/i915/i915_gem_evict.c | 51 +--
drivers/gpu/drm/i915/i915_vma.c | 5 ++-
drivers/gpu/drm/i915/selftests/i915_gem.c | 2 +
8 files changed, 112 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 2518cebbf931..6ba7e9e8e2ca 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -8,6 +8,7 @@
#include
#include
+#include
#include
#include
@@ -196,10 +197,13 @@ void i915_ggtt_suspend_vm(struct i915_address_space *vm)
void i915_ggtt_suspend(struct i915_ggtt *ggtt)
{
+ struct intel_gt *gt;
+
i915_ggtt_suspend_vm(&ggtt->vm);
ggtt->invalidate(ggtt);
- intel_gt_check_and_clear_faults(ggtt->vm.gt);
+ list_for_each_entry(gt, &ggtt->gt_list, ggtt_link)
+ intel_gt_check_and_clear_faults(gt);
}
void gen6_ggtt_invalidate(struct i915_ggtt *ggtt)
@@ -225,16 +229,21 @@ static void gen8_ggtt_invalidate(struct i915_ggtt *ggtt)
static void guc_ggtt_invalidate(struct i915_ggtt *ggtt)
{
- struct intel_uncore *uncore = ggtt->vm.gt->uncore;
struct drm_i915_private *i915 = ggtt->vm.i915;
gen8_ggtt_invalidate(ggtt);
- if (GRAPHICS_VER(i915) >= 12)
- intel_uncore_write_fw(uncore, GEN12_GUC_TLB_INV_CR,
- GEN12_GUC_TLB_INV_CR_INVALIDATE);
- else
- intel_uncore_write_fw(uncore, GEN8_GTCR, GEN8_GTCR_INVALIDATE);
+ if (GRAPHICS_VER(i915) >= 12) {
+ struct intel_gt *gt;
+
+ list_for_each_entry(gt, &ggtt->gt_list, ggtt_link)
+ intel_uncore_write_fw(gt->uncore,
+ GEN12_GUC_TLB_INV_CR,
+ GEN12_GUC_TLB_INV_CR_INVALIDATE);
+ } else {
+ intel_uncore_write_fw(ggtt->vm.gt->uncore,
+ GEN8_GTCR, GEN8_GTCR_INVALIDATE);
+ }
}
u64 gen8_ggtt_pte_encode(dma_addr_t addr,
@@ -986,8 +995,6 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
ggtt->vm.pte_encode = gen8_ggtt_pte_encode;
- setup_private_pat(ggtt->vm.gt);
-
return ggtt_probe_common(ggtt, size);
}
@@ -1186,7 +1193,7 @@ static int ggtt_probe_hw(struct i915_ggtt *ggtt, struct
intel_gt *gt)
(u64)ggtt->mappable_end >> 20);
drm_dbg(&i915->drm, "DSM size = %lluM\n",
(u64)resource_size(&intel_graphics_stolen_res) >> 20);
-
+ INIT_LIST_HEAD(&ggtt->gt_list);
return 0;
}
@@ -1208,6 +1215,19 @@ int i915_ggtt_probe_hw(struct drm_i915_private *i915)
return 0;
}
+struct i915_ggtt *i915_ggtt_create(struct drm_i915_private *i915)
+{
+ struct i915_ggtt *ggtt;
+
+ ggtt = drmm_kzalloc(&i915->drm, sizeof(*ggtt), GFP_KERNEL);
+ if (!ggtt)
+ return ERR_PTR(-ENOMEM);
+
+ INIT_LIST_HEAD(&ggtt->gt_list);
+
+ return ggtt;
+}
+
int i915_ggtt_enable_hw(struct drm_i915_private *i915)
{
if (GRAPHICS_VER(i915) < 6)
@@ -1296,9 +1316,11 @@ bool i915_ggtt_resume_vm(struct i915_address_space *vm)
void i915_ggtt_resume(struct i915_ggtt *ggtt)
{
+ struct intel_gt *gt;
bool flush;
- intel_gt_check_and_clear_faults(ggtt->vm.gt);
+ list_for_each_entry(gt, &ggtt->gt_list, ggtt_link)
+ intel_gt_check_and_clear_faults(gt);
flush = i915_ggtt_resume_vm(&ggtt->vm);
@@ -1307,9 +1329,6 @@ void i915_ggtt_resume(struct i915_ggtt *ggtt)
if (flush)
wbinvd_on_all_cpus();
- if (GRAPHICS_VER(ggtt->vm.i915) >= 8)
- setup_private_pat(ggtt->vm.gt);
-
intel_ggtt_restore_fences(ggtt);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Partial abandonment of legacy DRM logging macros (rev3)
== Series Details == Series: drm/i915: Partial abandonment of legacy DRM logging macros (rev3) URL : https://patchwork.freedesktop.org/series/110660/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2
Re: [Intel-gfx] [CI 0/1] drm/i915/rps: Query min/max freq from FW when displaying in sysfs
On Wed, 09 Nov 2022 01:30:32 -0800, Jani Nikula wrote: > > On Tue, 08 Nov 2022, Ashutosh Dixit wrote: > > CI ONLY, PLEASE DON'T REVIEW > > This is what intel-gfx-try...@lists.freedesktop.org is for? Sorry, will use trybot in the future. > > BR, > Jani. > > > > > > Test-with: 20221108215457.2494061-1-ashutosh.di...@intel.com > > > > Ashutosh Dixit (1): > > drm/i915/rps: Query min/max freq from FW when displaying in sysfs > > > > drivers/gpu/drm/i915/gt/intel_rps.c | 22 -- > > 1 file changed, 16 insertions(+), 6 deletions(-) > > -- > Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 04/10] vfio: Move storage of allow_unsafe_interrupts to vfio_main.c
On Wed, Nov 09, 2022 at 03:21:29AM +, Tian, Kevin wrote: > > From: Jason Gunthorpe > > Sent: Wednesday, November 9, 2022 9:05 AM > > > > On Tue, Nov 08, 2022 at 03:55:20PM -0700, Alex Williamson wrote: > > > > > > > So why exactly isn't this an issue for VDPA? Are we just burying our > > > > > head in the sand that such platforms exists and can still be useful > > > > > given the appropriate risk vs reward trade-off? > > > > > > > > Simply that nobody has asked for it, and might never ask for it. This > > > > is all support for old platforms, and there just doesn't seem to be a > > > > "real" use case for very new (and actually rare) NIC hardware stuck > > > > into ancient platforms with this security problem. > > > > > > vIOMMU support for interrupt remapping is relatively new, the nesting > > > case is important as well. > > > > This is where we got hit. In the end we fixed the qemu.. > > but the point is that old qemu could have a much longer lifespan than > old platforms then when running newer kernel which supports vdpa > on old qemu the same tradeoff consideration is then not vfio > specific... I think we are reaching into incredible hypotheticals here. We don't know of any real uses cases where a very new VDPA capable device would be assinged into a VM using an old qemu and the entire system is expected to work. What we are seeing is people using this stuff are making highly engineered systems and will meet the constraints. Today VDPA doesn't support allow_unsafe_interrupts, and I don't see a compelling reason to change that. The threshold for introducing a kernel security hole should be much higher than "someone could possibly do this". > If all agree that VFIO_CONTAINER=n is a process to evolve, does it make > more sense to remove this patch from this series i.e. let it buried in > VFIO_CONTAINER=y for now? Then resolve it in a follow up patch if > no consensus can be made quickly at this point. This is worse, it would make iommufd completely unusable in situations where we need allow_unsafe_interrupts. If we belive that is important we should keep this patch so existing systems on kernels with VFIO_CONTAINER=y continue to work after libvirt/qemu are upgraded to iommufd. Jason
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: mode clock check related to max dotclk frequency
== Series Details == Series: drm/i915/display: mode clock check related to max dotclk frequency URL : https://patchwork.freedesktop.org/series/110686/ State : success == Summary == CI Bug Log - changes from CI_DRM_12358_full -> Patchwork_110686v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (11 -> 11) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_110686v1_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_balancer@parallel-keep-submit-fence: - shard-iclb: [PASS][1] -> [SKIP][2] ([i915#4525]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12358/shard-iclb2/igt@gem_exec_balan...@parallel-keep-submit-fence.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110686v1/shard-iclb6/igt@gem_exec_balan...@parallel-keep-submit-fence.html * igt@gem_exec_fair@basic-deadline: - shard-apl: NOTRUN -> [FAIL][3] ([i915#2846]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110686v1/shard-apl8/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-glk: NOTRUN -> [FAIL][4] ([i915#2842]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110686v1/shard-glk2/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: [PASS][5] -> [FAIL][6] ([i915#2842]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12358/shard-glk7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110686v1/shard-glk1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_huc_copy@huc-copy: - shard-apl: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#2190]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110686v1/shard-apl6/igt@gem_huc_c...@huc-copy.html - shard-glk: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#2190]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110686v1/shard-glk2/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@heavy-multi: - shard-skl: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#4613]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110686v1/shard-skl9/igt@gem_lmem_swapp...@heavy-multi.html * igt@gem_lmem_swapping@heavy-verify-random-ccs: - shard-apl: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#4613]) +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110686v1/shard-apl8/igt@gem_lmem_swapp...@heavy-verify-random-ccs.html * igt@gem_lmem_swapping@random-engines: - shard-glk: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#4613]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110686v1/shard-glk2/igt@gem_lmem_swapp...@random-engines.html * igt@gem_workarounds@suspend-resume: - shard-apl: [PASS][12] -> [DMESG-WARN][13] ([i915#180]) +1 similar issue [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12358/shard-apl2/igt@gem_workarou...@suspend-resume.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110686v1/shard-apl2/igt@gem_workarou...@suspend-resume.html * igt@i915_pm_dc@dc6-dpms: - shard-iclb: [PASS][14] -> [FAIL][15] ([i915#3989] / [i915#454]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12358/shard-iclb5/igt@i915_pm...@dc6-dpms.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110686v1/shard-iclb3/igt@i915_pm...@dc6-dpms.html * igt@i915_pm_dc@dc6-psr: - shard-skl: [PASS][16] -> [FAIL][17] ([i915#3989] / [i915#454]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12358/shard-skl7/igt@i915_pm...@dc6-psr.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110686v1/shard-skl1/igt@i915_pm...@dc6-psr.html * igt@i915_pm_rc6_residency@rc6-idle@rcs0: - shard-tglb: NOTRUN -> [WARN][18] ([i915#2681]) +3 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110686v1/shard-tglb8/igt@i915_pm_rc6_residency@rc6-i...@rcs0.html * igt@i915_suspend@sysfs-reader: - shard-skl: [PASS][19] -> [INCOMPLETE][20] ([i915#4817] / [i915#7233]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12358/shard-skl1/igt@i915_susp...@sysfs-reader.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110686v1/shard-skl10/igt@i915_susp...@sysfs-reader.html * igt@kms_big_fb@4-tiled-max-hw-stride-32bpp-rotate-180-async-flip: - shard-apl: NOTRUN -> [SKIP][21] ([fdo#109271]) +55 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110686v1/shard-apl6/igt@kms_big...@4-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html * igt@kms_big_fb@x-tiled-32bpp-rotate-270: - shard-tglb: NOTRUN -> [SKIP][22] ([fdo#111
Re: [Intel-gfx] [PATCH v2 00/11] Connect VFIO to IOMMUFD
On Wed, Nov 09, 2022 at 09:03:52AM +, Tian, Kevin wrote: > every mail in this series is shown thrice in lore: > > https://lore.kernel.org/all/0-v2-65016290f146+33e-vfio_iommufd_...@nvidia.com/ > > not sure what caused it but it's annoying to check the conversation there. It is sort of a lore issue, it only combines messages that are exactly the same together. Several of the mailing lists on CC here mangle the message in various ways, eg adding trailer or whatever. This causes repeated messages in lore. The trick in lore is to replace "/all/" with a good list, like /kvm/ or /linux-iommu/ that shows the original non-mangled version, and only once. Jason
