- 29 Jan, 2019 8 commits
-
-
Ville Syrjälä authored
drm_color_lut_check() doens't modify the passed in blob so let's make it const. Also s/uint32_t/u32/ while at it. v2: Reduce line wraps (Sam) Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190129170609.5718-1-ville.syrjala@linux.intel.comReviewed-by:
Sam Ravnborg <sam@ravnborg.org> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chris Wilson authored
In order to avoid preempting ourselves, we currently refuse to schedule the tasklet if we reschedule an inflight context. However, this glosses over a few issues such as what happens after a CS completion event and we then preempt the newly executing context with itself, or if something else causes a tasklet_schedule triggering the same evaluation to preempt the active context with itself. However, when we avoid preempting ELSP[0], we still retain the preemption value as it may match a second preemption request within the same time period that we need to resolve after the next CS event. However, since we only store the maximum preemption priority seen, it may not match the subsequent event and so we should double check whether or not we actually do need to trigger a preempt-to-idle by comparing the top priorities from each queue. Later, this gives us a hook for finer control over deciding whether the preempt-to-idle is justified. The sequence of events where we end up preempting for no avail is: 1. Queue requests/contexts A, B 2. Priority boost A; no preemption as it is executing, but keep hint 3. After CS switch, B is less than hint, force preempt-to-idle 4. Resubmit B after idling v2: We can simplify a bunch of tests based on the knowledge that PI will ensure that earlier requests along the same context will have the highest priority. v3: Demonstrate the stale preemption hint with a selftest References: a2bf92e8 ("drm/i915/execlists: Avoid kicking priority on the current context") Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190129185452.20989-4-chris@chris-wilson.co.uk
-
Chris Wilson authored
After noticing that we trigger preemption events for currently executing requests, as well as requests that complete before the preemption and attempting to suppress those preemption events, it is wise to not consider the queue_priority to be authoritative. As we only track the maximum priority seen between dequeue passes, if the maximum priority request is no longer available for dequeuing (it completed or is even executing on another engine), we have no knowledge of the previous queue_priority as it would require us to keep a full history of enqueued requests -- but we already have that history in the priolists! Rename the queue_priority to queue_priority_hint so that we do not confuse it as being exactly the maximum priority in the queue, but merely an indication that we have seen a new maximum priority value and as such we should check whether it should preempt the currently running request. v2: s/preempt_priority_hint/queue_priority_hint/ as preempt implies it being only used for the singular task of preemption and not the wider question of waking up due to a change in the queue. Signed-off-by:
-
Chris Wilson authored
To allow requests to forgo a common execution timeline, one question we need to be able to answer is "is this request running?". To track whether a request has started on HW, we can emit a breadcrumb at the beginning of the request and check its timeline's HWSP to see if the breadcrumb has advanced past the start of this request. (This is in contrast to the global timeline where we need only ask if we are on the global timeline and if the timeline has advanced past the end of the previous request.) There is still confusion from a preempted request, which has already started but relinquished the HW to a high priority request. For the common case, this discrepancy should be negligible. However, for identification of hung requests, knowing which one was running at the time of the hang will be much more important. Signed-off-by:
-
Chris Wilson authored
In bringup on simulated HW even rudimentary tests are slow, and so many may fail that we want to be able to filter out the noise to focus on the specific problem. Even just the tests groups provided for igt is not specific enough, and we would like to isolate one particular subtest (and probably subsubtests!). For simplicity, allow the user to provide a command line parameter such as i915.st_filter=i915_timeline_mock_selftests/igt_sync to restrict ourselves to only running on subtest. The exact name to use is given during a normal run, highlighted as an error if it failed, debug otherwise. The test group is optional, and then all subtests are compared for an exact match with the filter (most subtests have unique names). The filter can be negated, e.g. i915.st_filter=!igt_sync and then all tests but those that match will be run. More than one match can be supplied separated by a comma, e.g. i915.st_filter=igt_vma_create,igt_vma_pin1 to only run those specified, or i915.st_filter=!igt_vma_create,!igt_vma_pin1 to run all but those named. Mixing a blacklist and whitelist will only execute those subtests matching the whitelist so long as they are previously excluded in the blacklist. Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190129185452.20989-1-chris@chris-wilson.co.uk
-
Rodrigo Vivi authored
A backmerge to unblock gen8+ semaphores. Signed-off-by:Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Ville Syrjälä authored
We're incorrectly masking off the R/V channel enable bit from KEYMSK. Fix it up. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Fixes: b2081525 ("drm/i915: Add plane alpha blending support, v2.") Signed-off-by:
Matt Roper <matthew.d.roper@intel.com>
-
Hans de Goede authored
We really want to have fastboot enabled by default to avoid an ugly modeset during boot. Rather then enabling it everywhere, lets start with enabling it on Skylake and newer. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
-
- 28 Jan, 2019 15 commits
-
-
Chris Wilson authored
Now that we pin timelines around use, we have a clearly defined lifetime and convenient points at which we can track only the active timelines. This allows us to reduce the list iteration to only consider those active timelines and not all. Signed-off-by:
-
Chris Wilson authored
Now that we have allocated ourselves a cacheline to store a breadcrumb, we can emit a write from the GPU into the timeline's HWSP of the per-context seqno as we complete each request. This drops the mirroring of the per-engine HWSP and allows each context to operate independently. We do not need to unwind the per-context timeline, and so requests are always consistent with the timeline breadcrumb, greatly simplifying the completion checks as we no longer need to be concerned about the global_seqno changing mid check. One complication though is that we have to be wary that the request may outlive the HWSP and so avoid touching the potentially danging pointer after we have retired the fence. We also have to guard our access of the HWSP with RCU, the release of the obj->mm.pages should already be RCU-safe. At this point, we are emitting both per-context and global seqno and still using the single per-engine execution timeline for resolving interrupts. v2: s/fake_complete/mark_complete/ Signed-off-by:
-
Chris Wilson authored
If we restrict ourselves to only using a cacheline for each timeline's HWSP (we could go smaller, but want to avoid needless polluting cachelines on different engines between different contexts), then we can suballocate a single 4k page into 64 different timeline HWSP. By treating each fresh allocation as a slab of 64 entries, we can keep it around for the next 64 allocation attempts until we need to refresh the slab cache. John Harrison noted the issue of fragmentation leading to the same worst case performance of one page per timeline as before, which can be mitigated by adopting a freelist. v2: Keep all partially allocated HWSP on a freelist This is still without migration, so it is possible for the system to end up with each timeline in its own page, but we ensure that no new allocation would needless allocate a fresh page! v3: Throw a selftest at the allocator to try and catch invalid cacheline reuse. Signed-off-by:
-
Chris Wilson authored
Allocate a page for use as a status page by a group of timelines, as we only need a dword of storage for each (rounded up to the cacheline for safety) we can pack multiple timelines into the same page. Each timeline will then be able to track its own HW seqno. v2: Reuse the common per-engine HWSP for the solitary ringbuffer timeline, so that we do not have to emit (using per-gen specialised vfuncs) the breadcrumb into the distinct timeline HWSP and instead can keep on using the common MI_STORE_DWORD_INDEX. However, to maintain the sleight-of-hand for the global/per-context seqno switchover, we will store both temporarily (and so use a custom offset for the shared timeline HWSP until the switch over). v3: Keep things simple and allocate a page for each timeline, page sharing comes next. v4: I was caught repeating the same MI_STORE_DWORD_IMM over and over again in selftests. v5: And caught red handed copying create timeline + check. Signed-off-by:
-
Chris Wilson authored
Previously we only accommodated having a vma pinned by a small number of users, with the maximum being pinned for use by the display engine. As such, we used a small bitfield only large enough to allow the vma to be pinned twice (for back/front buffers) in each scanout plane. Keeping the maximum permissible pin_count small allows us to quickly catch a potential leak. However, as we want to split a 4096B page into 64 different cachelines and pin each cacheline for use by a different timeline, we will exceed the current maximum permissible vma->pin_count and so time has come to enlarge it. Whilst we are here, try to pull together the similar bits: Address/layout specification: - bias, mappable, zone_4g: address limit specifiers - fixed: address override, limits still apply though - high: not strictly an address limit, but an address direction to search Search controls: - nonblock, nonfault, noevict v2: Rewrite the guideline comment on bit consumption. Signed-off-by:
John Harrison <john.C.Harrison@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190128181812.22804-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
Supplement the per-engine HWSP with a per-timeline HWSP. That is a per-request pointer through which we can check a local seqno, abstracting away the presumption of a global seqno. In this first step, we point each request back into the engine's HWSP so everything continues to work with the global timeline. v2: s/i915_request_hwsp/hwsp_seqno/ to emphasis that this is the current HW value and that we are accessing it via i915_request merely as a convenience. Signed-off-by:
-
Chris Wilson authored
Currently, the list of timelines is serialised by the struct_mutex, but to alleviate difficulties with using that mutex in future, move the list management under its own dedicated mutex. Signed-off-by:
-
Chris Wilson authored
Currently we only allocate an object and vma if we are using a GGTT virtual HWSP, and a plain struct page for a physical HWSP. For convenience later on with global timelines, it will be useful to always have the status page being tracked by a struct i915_vma. Make it so. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190128102356.15037-4-chris@chris-wilson.co.uk
-
Chris Wilson authored
Remove the struct_mutex requirement for looking up the vma for an object. v2: Highlight how the race for duplicate vma creation is resolved on reacquiring the lock with a short comment. Signed-off-by:
-
Chris Wilson authored
A starting point to counter the pervasive struct_mutex. For the goal of avoiding (or at least blocking under them!) global locks during user request submission, a simple but important step is being able to manage each clients GTT separately. For which, we want to replace using the struct_mutex as the guard for all things GTT/VM and switch instead to a specific mutex inside i915_address_space. Signed-off-by:
-
Chris Wilson authored
Our goal is to remove struct_mutex and replace it with fine grained locking. One of the thorny issues is our eviction logic for reclaiming space for an execbuffer (or GTT mmaping, among a few other examples). While eviction itself is easy to move under a per-VM mutex, performing the activity tracking is less agreeable. One solution is not to do any MRU tracking and do a simple coarse evaluation during eviction of active/inactive, with a loose temporal ordering of last insertion/evaluation. That keeps all the locking constrained to when we are manipulating the VM itself, neatly avoiding the tricky handling of possible recursive locking during execbuf and elsewhere. Note that discarding the MRU (currently implemented as a pair of lists, to avoid scanning the active list for a NONBLOCKING search) is unlikely to impact upon our efficiency to reclaim VM space (where we think a LRU model is best) as our current strategy is to use random idle replacement first before doing a search, and over time the use of softpinned 48b per-ppGTT is growing (thereby eliminating any need to perform any eviction searches, in theory at least) with the remaining users being found on much older devices (gen2-gen6). v2: Changelog and commentary rewritten to elaborate on the duality of a single list being both an inactive and active list. v3: Consolidate bool parameters into a single set of flags; don't comment on the duality of a single variable being a multiplicity of bits. Signed-off-by:
-
Ville Syrjälä authored
Certain SNB machines (eg. ASUS K53SV) seem to have a broken BIOS which misprograms the hardware badly when encountering a suitably high resolution display. The programmed pipe timings are somewhat bonkers and the DPLL is totally misprogrammed (P divider == 0). That will result in atomic commit timeouts as apparently the pipe is sufficiently stuck to not signal vblank interrupts. IIRC something like this was also observed on some other SNB machine years ago (might have been a Dell XPS 8300) but a BIOS update cured it. Sadly looks like this was never fixed for the ASUS K53SV as the latest BIOS (K53SV.320 11/11/2011) is still broken. The quickest way to deal with this seems to be to shut down the pipe+ports+DPLL. Unfortunately doing this during the normal sanitization phase isn't quite soon enough as we already spew several WARNs about the bogus hardware state. But it's better than hanging the boot for a few dozen seconds. Since this is limited to a few old machines it doesn't seem entirely worthwile to try and rework the readout+sanitization code to handle it more gracefully. v2: Fix potential NULL deref (kbuild test robot) Constify has_bogus_dpll_config() Cc: stable@vger.kernel.org # v4.20+ Cc: Daniel Kamil Kozar <dkk089@gmail.com> Reported-by:Daniel Kamil Kozar <dkk089@gmail.com> Tested-by:
Mika Kahola <mika.kahola@intel.com>
-
Ville Syrjälä authored
Just like the frame counter, the pixel counter also reads zero all the time when the TV encoder is used. Fortunately the scanline counter still works sufficiently well so let's use that to correct the vblank timestamps. Otherwise the timestamps may en up out of whack, and since we use them to guesstimate the vblank counter value that may end up incorrect as well. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com>
-
Ville Syrjälä authored
Ever since commit 204474a6 ("drm/i915: Pass down rc in intel_encoder->compute_config()") we're supposed to return an errno from .compute_config(). I failed to notice that when pushing the TV encoder fixes which were written before said commmit. Fix up the return value for the error case. Cc: Imre Deak <imre.deak@intel.com> Fixes: 690157f0 ("drm/i915/tv: Fix >1024 modes on gen3") Signed-off-by:
-
Chris Wilson authored
During igt, we ask to reset the device if any requests are still outstanding at the end of a test, as this quickly kills off any erroneous hanging request streams that may escape a test. However, since it may take the device a few milliseconds to flush itself after the end of a normal test, *cough* guc *cough*, we may accidentally tell the device to reset itself after it idles. If we wait a moment, our usual I915_IDLE_ENGINES_TIMEOUT of 200ms (seems a bit high, but still better than umpteen hangchecks!), we can differentiate better between a stuck engine and a healthy one, and so avoid prematurely forcing the reset and any extra complications that may entail. Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190128010245.20148-1-chris@chris-wilson.co.uk
-
- 26 Jan, 2019 1 commit
-
-
Nathan Chancellor authored
This warning is disabled by default in scripts/Makefile.extrawarn when W= is not provided but this Makefile adds -Wall after this warning is disabled so it shows up in the build when it shouldn't: In file included from drivers/gpu/drm/i915/intel_breadcrumbs.c:895: drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c:350:34: error: variable 'wq' is uninitialized when used within its own initialization [-Werror,-Wuninitialized] DECLARE_WAIT_QUEUE_HEAD_ONSTACK(wq); ^~ ./include/linux/wait.h:74:63: note: expanded from macro 'DECLARE_WAIT_QUEUE_HEAD_ONSTACK' struct wait_queue_head name = __WAIT_QUEUE_HEAD_INIT_ONSTACK(name) ~~~~ ^~~~ ./include/linux/wait.h:72:33: note: expanded from macro '__WAIT_QUEUE_HEAD_INIT_ONSTACK' ({ init_waitqueue_head(&name); name; }) ^~~~ 1 error generated. Explicitly disable the warning like commit 46e20680 ("drm/i915: Disable some extra clang warnings"). Link: https://github.com/ClangBuiltLinux/linux/issues/220Suggested-by:Nathan Chancellor <natechancellor@gmail.com> Reviewed-by:
Nick Desaulniers <nick.desaulniers@gmail.com> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
-
- 25 Jan, 2019 16 commits
-
-
P Raviraj Sitaram authored
framebuffer for NV12 requires the pitch to the multiplier of 4, instead of the width. This patch corrects it. For instance, a 480p video, whose width and pitch are 854 and 896 respectively, is excluded for NV12 plane so far. Changes since v1: - Removed check for NV12 buffer dimensions since additional checks are done for viewport size in intel_sprite.c Signed-off-by:Dongseong Hwang <dongseong.hwang@intel.com> Signed-off-by:
P Raviraj Sitaram <raviraj.p.sitaram@intel.com> Cc: Chandra Konduru <chandra.konduru@intel.com> Cc: Vidya Srinivas <vidya.srinivas@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by:
-
Ville Syrjälä authored
Rename some of the state variables in intel_plane_atomic_check_with_state() to make it less confusing. Signed-off-by:
Uma Shankar <uma.shankar@intel.com>
-
Ville Syrjälä authored
Since gen3 can't handle >1024 wide sources with vertical scaling let's not advertize such modes in the mode list. Less tempetation to the user to try out things that won't work. v2: s/IS_GEN3(dev_priv/IS_GEN(dev_priv, 3)/ Signed-off-by:
-
Ville Syrjälä authored
On gen3 we must disable the TV encoder vertical filter for >1024 pixel wide sources. Once that's done all we can is try to center the image on the screen. Naturally the TV mode vertical resolution must be equal or larger than the user mode vertical resolution or else we'd have to cut off part of the user mode. And while we may not be able to respect the user's choice of top and bottom borders exactly (or we'd have to reject he mode most likely), we can try to maintain the relative sizes of the top and bottom border with respect to each orher. Additionally we must configure the pipe as interlaced if the TV mode is interlaced. v2: Make +intel_tv_connector_duplicate_state() static and drop the badly copy pasted kerneldoc s/IS_GEN3(dev_priv/IS_GEN(dev_priv, 3)/ Signed-off-by: -
Ville Syrjälä authored
To make vblank timestamps work better with the TV encoder let's scale the pipe timings such that the relationship between the TV active and TV blanking periods is mirrored in the corresponding pipe timings. Note that in reality the pipe runs at a faster speed during the TV vblank, and correspondigly there are periods when the pipe is enitrely stopped. We pretend that this isn't the case and as such we incur some error in the vblank timestamps during the TV vblank. Further explanation of the issues in a big comment in the code. This makes the vblank timestamps good enough to make i965gm (which doesn't have a working frame counter with the TV encoder) report correct frame numbers. Previously you could get all kinds of nonsense which resulted in eg. glxgears reporting that it's running at twice the actual framerate in most cases. v2: s/IS_GEN4(dev_priv)/IS_GEN(dev_priv, 4)/ in the comment for consistency Signed-off-by: -
Ville Syrjälä authored
Add the missing 1080p TV modes. On gen4 all of them work just fine, whereas on gen3 only the 30Hz mode actually works correctly. v2: s/IS_GEN3(dev_priv)/IS_GEN(dev_priv, 3)/ Signed-off-by:
-
Ville Syrjälä authored
Remove the silly reported_modes[] array. I suppse once upon a time this actually had something to do with modes we reported to userspace. Now it is just the placeholder for the mode we use for load detection. We don't need it even for that, and instead we can just rely on the fallback mode in intel_get_load_detect_pipe(). Signed-off-by:
-
Ville Syrjälä authored
The current code insists on picking a new TV mode when switching between component and non-component cables. That's super annoying. Let's just keep the current TV mode unless the new cable type actually disagrees with it. Signed-off-by:
-
Ville Syrjälä authored
No point in storing the mode names in the array. drm_mode_set_name() will give us the same names without wasting space for these string constants. Signed-off-by:
-
Ville Syrjälä authored
Rewrite the preferred mode selection to just check whether the TV modes is HD or SD. For SD TV modes we favor 480 line modes, for 720p we prefer 720 line modes, and for 1080i/p we prefer 1080 line modes. Signed-off-by:
-
Ville Syrjälä authored
Just assign the margin values directly to xpos/ypos instead of first initializing to zero and then adding the values. Signed-off-by:
-
Ville Syrjälä authored
'component_only' is a bool. Initialize it like a bool. Signed-off-by:
-
Ville Syrjälä authored
Store the oversampling factor as a number in the TV modes. We shall want to arithmetic with this which is easier if it's a number we can use directly. Signed-off-by:
-
Ville Syrjälä authored
The oversample clock is always supposed to be either 108 MHz or 148.5 MHz. Make it so. Signed-off-by:
-
Ville Syrjälä authored
Fix the calculation of the vertical active period for interlaced TV modes. Signed-off-by:
-
Ville Syrjälä authored
On i965gm the hardware frame counter does not work when the TV encoder is active. So let's not try to consult the hardware frame counter in that case. Instead we'll fall back to the timestamp based guesstimation method used on gen2. Note that the pipe timings generated by the TV encoder are also rather peculiar. Apparently the pipe wants to run at a much higher speed (related to the oversample clock somehow it seems) but during the vertical active period the TV encoder stalls the pipe every few lines to keep its speed in check. But once the vertical blanking period is reached the pipe gets to run at full speed. This means our vblank timestamp estimates are suspect. Fixing all that would require quite a bit more work. This simple fix at least avoids the nasty vblank timeouts that are happening currently. Curiously the frame counter works just fine on i945gm and gm45. I don't really understand what kind of mishap occurred with the hardware design on i965gm. Sadly I wasn't able to find any chicken bits etc. that would fix the frame counter :( v2: Move the zero vs. non-zero hw counter value handling into i915_get_vblank_counter() (Daniel) Use the per-crtc maximum exclusively, leaving the per-device maximum at zero v3: max_vblank_count not populated yet in intel_enable_pipe() use intel_crtc_max_vblank_count() instead Cc: stable@vger.kernel.org Cc: Daniel Vetter <daniel@ffwll.ch> Fixes: 51e31d49 ("drm/i915: Use generic vblank wait") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93782Signed-off-by:
-
