Maarten requested a backmerge due his work depending on subtle semantic
changes introduced by:
7e2e69ed46 ("drm/i915: Fix i915_request fence wait semantics")
2cbb8d4d67 ("drm/i915: use new iterator in i915_gem_object_wait_reservation")
Both should probably have been merged to drm-intel-gt-next anyway.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Don't wait sync while migrating, but rather make the GPU blit await the
dependencies and add a moving fence to the object.
This also enables asynchronous VRAM management in that on eviction,
rather than waiting for the moving fence to expire before freeing VRAM,
it is freed immediately and the fence is stored with the VRAM manager and
handed out to newly allocated objects to await before clears and swapins,
or for kernel objects before setting up gpu vmas or mapping.
To collect dependencies before migrating, add a set of utilities that
coalesce these to a single dma_fence.
What is still missing for fully asynchronous operation is asynchronous vma
unbinding, which is still to be implemented.
This commit substantially reduces execution time in the gem_lmem_swapping
test.
v2:
- Make a couple of functions static.
v4:
- Fix some style issues (Matthew Auld)
- Audit and add more checks for ghost objects (Matthew Auld)
- Add more documentation for the i915_deps utility (Mattew Auld)
- Simplify the i915_deps_sync() function
v6:
- Re-check for fence signaled before returning -EBUSY (Matthew Auld)
- Use dma_resv_iter_is_exclusive() (Matthew Auld)
- Await all dma-resv fences before a migration blit (Matthew Auld)
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211122214554.371864-6-thomas.hellstrom@linux.intel.com
With async migration, the shrinker may end up wanting to release the
pages of an object while the migration blit is still running, since
the GT migration code doesn't set up VMAs and the shrinker is thus
oblivious to the fact that the GPU is still using the pages.
Add waiting for gpu in the shrinker_release_pages() op and an
argument to that function indicating whether the shrinker expects it
to not wait for gpu. In the latter case the shrinker_release_pages()
op will return -EBUSY if the object is not idle.
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211122214554.371864-5-thomas.hellstrom@linux.intel.com
There is an interesting refcounting loop:
struct intel_memory_region has a struct ttm_resource_manager,
ttm_resource_manager->move may hold a reference to i915_request,
i915_request may hold a reference to intel_context,
intel_context may hold a reference to drm_i915_gem_object,
drm_i915_gem_object may hold a reference to intel_memory_region.
Break this loop by dropping region reference counting.
In addition, Have regions with a manager moving fence make sure
that all region objects are released before freeing the region.
v6:
- Fix a code comment.
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211122214554.371864-4-thomas.hellstrom@linux.intel.com
For now, we will only allow async migration when TTM is used,
so the paths we care about are related to TTM.
The mmap path is handled by having the fence in ttm_bo->moving,
when pinning, the binding only becomes available after the moving
fence is signaled, and pinning a cpu map will only work after
the moving fence signals.
This should close all holes where userspace can read a buffer
before it's fully migrated.
v2:
- Fix a couple of SPARSE warnings
v3:
- Fix a NULL pointer dereference
v4:
- Ditch the moving fence waiting for i915_vma_pin_iomap() and
replace with a verification that the vma is already bound.
(Matthew Auld)
- Squash with a previous patch introducing moving fence waiting and
accessing interfaces (Matthew Auld)
- Rename to indicated that we also add support for sync waiting.
v5:
- Fix check for NULL and unreferencing i915_vma_verify_bind_complete()
(Matthew Auld)
- Fix compilation failure if !CONFIG_DRM_I915_DEBUG_GEM
- Fix include ordering. (Matthew Auld)
v7:
- Fix yet another compilation failure with clang if
!CONFIG_DRM_I915_DEBUG_GEM
Co-developed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211122214554.371864-2-thomas.hellstrom@linux.intel.com
Irrespective of the backend for request submissions, busyness for an
engine with an active context is calculated using:
busyness = total + (current_time - context_switch_in_time)
In execlists mode of operation, the context switch events are handled
by the CPU. Context switch in/out time and current_time are captured
in CPU time domain using ktime_get().
In GuC mode of submission, context switch events are handled by GuC and
the times in the above formula are captured in GT clock domain. This
information is shared with the CPU through shared memory. This results
in 2 caveats:
1) The time taken between start of a batch and the time that CPU is able
to see the context_switch_in_time in shared memory is dependent on GuC
and memory bandwidth constraints.
2) Determining current_time requires an MMIO read that can take anywhere
between a few us to a couple ms. A reference CPU time is captured soon
after reading the MMIO so that the caller can compare the cpu delta
between 2 busyness samples. The issue here is that the CPU delta and the
busyness delta can be skewed because of the time taken to read the
register.
These 2 factors affect the accuracy of the selftest -
live_engine_busy_stats. For (1) the selftest waits until busyness stats
are visible to the CPU. The effects of (2) are more prominent for the
current busyness sample period of 100 us. Increase the busyness sample
period from 100 us to 10 ms to overccome (2).
v2: Fix checkpatch issues
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211115221640.30793-1-umesh.nerlige.ramappa@intel.com
TileF(Tile4 in bspec) format is 4K tile organized into
64B subtiles with same basic shape as for legacy TileY
which will be supported by Display13.
v2: - Fixed wrong case condition(Jani Nikula)
- Increased I915_FORMAT_MOD_F_TILED up to 12(Imre Deak)
v3: - s/I915_TILING_F/TILING_4/g
- s/I915_FORMAT_MOD_F_TILED/I915_FORMAT_MOD_4_TILED/g
- Removed unneeded fencing code
v4: - Rebased, fixed merge conflict with new table-oriented
format modifier checking(Stan)
- Replaced the rest of "Tile F" mentions to "Tile 4"(Stan)
v5: - Still had to remove some Tile F mentionings
- Moved has_4tile from adlp to DG2(Ramalingam C)
- Check specifically for DG2, but not the Display13(Imre)
v6: - Moved Tile4 associating struct for modifier/display to
the beginning(Imre Deak)
- Removed unneeded case I915_FORMAT_MOD_4_TILED modifier
checks(Imre Deak)
- Fixed I915_FORMAT_MOD_4_TILED to be 9 instead of 12
(Imre Deak)
v7: - Fixed display_ver to { 13, 13 }(Imre Deak)
- Removed redundant newline(Imre Deak)
Reviewed-by: Imre Deak <imre.deak@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211122211420.31584-1-stanislav.lisovskiy@intel.com
drm-misc-next for 5.17:
UAPI Changes:
* Remove restrictions on DMA_BUF_SET_NAME ioctl
* connector: State of privacy screen
* sysfs: Send hotplug uevent
Cross-subsystem Changes:
* clk/bmc-2835: Fixes
* dma-buf: Add dma_resv selftest; Error-handling fixes; Add debugfs
helpers; Remove dma_resv_get_excl_unlocked(); Documentation fixes
* pwm: Introduce of_pwm_single_xlate()
Core Changes:
* Support for privacy screens
* Make drm_irq.c legacy
* Fix __stack_depot_* name conflict
* Documentation fixes
* Fixes and cleanups
* dp-helper: Reuse 8b/10b link-training delay helpers
* format-helper: Update interfaces
* fb-helper: Allocate shadow buffer of correct size
* gem: Link GEM SHMEM and CMA helpers into separate modules; Use
dma_resv iterator; Import DMA_BUF namespace into GEM-helper modules
* gem/shmem-helper: Interface cleanups
* scheduler: Grab fence in drm_sched_job_add_implicit_dependencies();
Lockdep fixes
* kms-helpers: Link several files from core into the KMS-helper module
Driver Changes:
* Use dma_resv_iter in several places
* Fixes and cleanups
* amdgpu: Use drm_kms_helper_connector_hotplug_event(); Get all fences
at once
* bridge: Switch to managed MIPI DSI helpers in several places; Register
and attach during probe in several places; Convert to YAML in several
places
* bridge/anx7625: Support MIPI DPI input; Support HDMI audio; Fixes
* bridge/dw-hdmi: Allow interlace on bridge
* bridge/ps8640: Enable PM; Support aux-bus
* bridge/tc358768: Enabled reference clock; Support pulse mode;
Modesetting fixes
* bridge/ti-sn65dsi86: Use regmap_bulk_write(); Implement PWM
* etnaviv: Get all fences at once
* gma500: GEM object cleanups; Remove generic drivers in probe function
* i915: Support VESA panel backlights
* ingenic: Fixes and cleanups
* kirin: Adjust probe order
* kmb: Enable framebuffer console
* lima: Kconfig fixes
* meson: Refactoring to supperot DRM_BRIDGE_ATTACH_NO_ENCODER
* msm: Fixes and cleanups
* msm/dsi: Adjust probe order
* omap: Fixes and cleanups
* nouveau: CRC fixes; Validate LUTs in atomic check; Set HDMI AVI RGB
quantization to FULL; Fixes and cleanups
* panel: Support Innolux G070Y2-T02, Vivax TPC-9150, JDI R63452,
Newhaven 1.8-128160EF, Wanchanglong W552964ABA, Novatek NT35950,
BOE BF060Y8M, Sony Tulip Truly NT35521; Use dev_err_probe() throughout
drivers; Fixes and cleanups
* panel/ili9881c: Orientation fixes
* radeon: Use dma_resv_wait_timeout()
* rockchip: Add timeout for DSP hold; Suspend/resume fixes; PLL clock
fixes; Implement mmap in GEM object functions
* simpledrm: Support FB_DAMAGE_CLIPS and virtual screen sizes
* sun4i: Use CMA helpers without vmap support
* tidss: Fixes and cleanups
* v3d: Cleanups
* vc4: Fix HDMI-CEC hang when display is off; Power on HDMI controller
while disabling; Support 4k@60 Hz modes; Fixes and cleanups
* video: Convert to sysfs_emit() in several places
* video/omapfb: Fix fall-through
* virtio: Overflow fixes
* xen: Implement mmap as GEM object functions
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/YZYZSypIrr+qcih3@linux-uq9g.fritz.box
Let's enable runtime pm autosuspend by default everywhere.
So, we can allow D3hot and bigger power savings on idle scenarios.
But at this time let's not touch the autosuspend_delay time,
what caused some regression on our previous attempt.
Also, the latest identified issue on GuC PM has been fixed by
commit 1a52faed31 ("drm/i915/guc: Take GT PM ref when deregistering
context")
v1: Enable runtime pm autosuspend by default for Gen12
and later versions.
v2: Enable runtime pm autosuspend by default for all
platforms(Syrjala Ville)
v3: Change commit message(Nikula Jani)
Signed-off-by: Tilak Tangudu <tilak.tangudu@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211116155238.3226516-1-tilak.tangudu@intel.com
We currently have to special case vma->obj being NULL because
of gen6 ppgtt and mock_engine. Fix gen6 ppgtt, so we may soon
be able to remove a few checks. As the object only exists as
a fake object pointing to ggtt, we have no backing storage,
so no real object is created. It just has to look real enough.
Also kill pin_mutex, it's not compatible with ww locking,
and we can use the vm lock instead.
v2:
- Drop IS_SHRINKABLE and shorten overly long line
v3:
- Checkpatch fix for alignment
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211117142024.1043017-2-matthew.auld@intel.com
In intel_context_do_pin_ww, when calling into the pre_pin hook(which is
passed the ww context) it could in theory return -EDEADLK(which is very
likely with debug kernels), once we start adding more ww locking in there,
like in the next patch. If so then we need to be mindful of having to
restart the do_pin at this point.
If this is the kernel_context, or some other early in-kernel context
where we have yet to setup the default_state, then we always inhibit the
context restore, and instead rely on the delayed active_release to set
the CONTEXT_VALID_BIT for us(if we even care), which should indicate
that we have context switched away, and that our newly saved context
state should now be valid. However, since we currently grab the active
reference before the potential ww dance, we can end up setting the
CONTEXT_VALID_BIT much too early, if we need to backoff, and then upon
re-trying the do_pin, we could potentially cause the hardware to
incorrectly load some garbage context state when later context switching
to that context, but at the very least this will trigger the
GEM_BUG_ON() in __engine_unpark. For now let's just move any ww dance
stuff prior to arming the active reference.
For normal user contexts this shouldn't be a concern, since we should
already have the default_state ready when initialising the lrc state,
and so there should be no concern with active_release somehow
prematurely setting the CONTEXT_VALID_BIT.
v2(Thomas):
- Also re-order the onion unwind
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211117142024.1043017-1-matthew.auld@intel.com
Turns out the DSB has trouble correctly loading the gamma LUT.
From a cursory look maybe like some entries do not load
properly, or they get loaded with some gibberish. Unfortunately
our current kms_color/etc. tests do not seem to catch this.
I had a brief look at the generated DSB batch and it looked
correct. Tried a few quick tricks like writing the index
register twice/etc. but didn't see any improvement.
Also tried switching to the 10bit gamma mode in case
there is yet another issue with the multi-segment mode, but
even the 10bit mode was showing issues.
Switching to mmio fixes all of it. I suppose one theory is that
maybe the DSB bangs on the LUT too quickly and it can't keep up
and instead some data either gets dropped or corrupted. To confirm
that someone should try to slow down the DSB's progress a bit.
Another thought was that maybe the LUT has crappy dual porting
and you get contention if you try to load it during active
scanout. But why then would the mmio path work, unless it's
just sufficiently slow?
Whatever the case, this is currently busted so let's disable
it until we get to the root of the problem.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3916
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211014181856.17581-2-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Let's adjust the vblank evasion to account for the case where
a push has already been sent. In that case the vblank exit will start
at vmin vblank start (as opposed to vmax vblank start when no push
has been sent).
This should minimize the effects of the tiny race between sampling
the frame counter vs. intel_vrr_send_push() during the previous frame.
This will also be required if we want to do mailbox style updates with
vrr since then we'd definitely do multiple commits per frame. Currently
mailbox updates are only used by the legacy cursor, but we don't do
vrr push for those.
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211117183103.27418-2-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Moving the vrr push to happen before sampling the frame counter
was wrong. If we are already in vblank when the push is sent
the vblank exit will start immediately which causes the sampled
frame counter to correspond to the next frame instead of the current
frame.
So put things back into the original order (except we should
keep the vrr push within the irq disable section to avoid
pointless irq related delays here).
We'll just have to accept the tiny race that exists between
sampling the frame counter vs. vrr push. And let's at least
document said race properly in a comment.
I suppose we could try to minimize the race by sampling the frame
counter just before sending the push, but that would require
changing drm_crtc_arm_vblank_event() to accept a caller provided
vblank counter value, so leave it be for now. Another thing we
could do is change the vblank evasion to account for the case
where a push was already sent. That would anyway be required
for mailbox style updates. Currently mailbox updates are only
used by the legacy cursor, but we don't do a vrr push for those.
Cc: Manasi Navare <manasi.d.navare@intel.com>
Fixes: 6f9976bd13 ("drm/i915: Do vrr push before sampling the frame counter")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211117183103.27418-1-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
In intel_dsi_get_config() double the pclk returned by foo_dsi_get_pclk()
for dual-link panels. This fixes the following WARN triggering:
i915 0000:00:02.0: [drm] *ERROR* [CRTC:51:pipe A] mismatch in pixel_rate (expected 235710, found 118056)
i915 0000:00:02.0: [drm] *ERROR* [CRTC:51:pipe A] mismatch in hw.pipe_mode.crtc_clock (expected 235710, found 118056)
i915 0000:00:02.0: [drm] *ERROR* [CRTC:51:pipe A] mismatch in hw.adjusted_mode.crtc_clock (expected 235710, found 118056)
i915 0000:00:02.0: [drm] *ERROR* [CRTC:51:pipe A] mismatch in port_clock (expected 235710, found 118056)
------------[ cut here ]------------
pipe state doesn't match!
WARNING: CPU: 3 PID: 136 at drivers/gpu/drm/i915/display/intel_display.c:9125 intel_display_finish_reset+0x1bd3/0x2050 [i915]
...
This has been tested on a Xiaomi Mi Pad 2 (with CHT x5-Z8500 SoC) tablet,
with a 1536x2048 dual-link DSI panel.
Note this fix was taken from icl_dsi.c which does the same in
its get_config().
Cc: Tsuchiya Yuto <kitakar@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211024155020.126328-1-hdegoede@redhat.com
Hooray! We've managed to hit enough bugs upstream that I've been able to
come up with a pretty solid explanation for how backlight controls are
actually supposed to be detected and used these days. As well, having the
rest of the PWM bits in VESA's backlight interface implemented seems to
have fixed all of the problematic brightness controls laptop panels that
we've hit so far.
So, let's actually document this instead of just calling the laptop panels
liars. As well, I would like to formally apologize to all of the laptop
panels I called liars. I'm sorry laptop panels, hopefully you can all
forgive me and we can move past this~
Signed-off-by: Lyude Paul <lyude@redhat.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211105183342.130810-6-lyude@redhat.com
