- 01 Feb, 2019 2 commits
-
-
Tvrtko Ursulin authored
No functional or code size change - just notice we can compact the source by re-using a single helper for adding workarounds. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Tvrtko Ursulin authored
Top comment in intel_workarounds.c says common code should come first so lets respect that. Also, by moving the common code together opportunities to reduce duplication will become more obvious. Signed-off-by:
-
- 31 Jan, 2019 6 commits
-
-
Imre Deak authored
VBT may include incorrect information about the presence of port F. Work around this on SKUs where we know the port is not present. v2: - Fix IS_ICL_WITH_PORT_F, so it's useable from any context. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108915 Cc: Mika Kahola <mika.kahola@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181220155211.31456-1-imre.deak@intel.com
-
Imre Deak authored
We can't safely probe Type C ports, whether they are a legacy or a USB/Thunderbolt DP Alternate Type C port. This would require performing the TypeC connect sequence - as described by the specification - but that may have unwanted side-effects. These side-effects include at least - without completeness - timeouts during AUX power well enabling and subsequent PLL enabling errors. To safely identify these ports we really need VBT, which has the proper flag for this (ddi_vbt_port_info::supports_typec_usb, supports_tbt). Based on the above disable Type C ports if we can't load VBT for some reason. v2: - Notice that we disable TypeC ports completely and simplify accordingly (Jose). - Add code comment explaining why we disabled the ports. (Jani) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Jose Roberto de Souza <jose.souza@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190128114242.28666-1-imre.deak@intel.com
-
Ville Syrjälä authored
commit 5b0bd14d ("drm/i915/icl: keep track of unused pll while looping") inadvertently (I presume) changed the code to pick the last unused dpll rather than the first unused one like we did before. While there should most likely be no harm in changing the order let's change back just to avoid a change in the behaviour. At least it might reduce the confusion when staring at logs (took me a while to figure out why DPLL1 being picked over DPLL0 when the latter was most definitely available). Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190130181359.20693-1-ville.syrjala@linux.intel.comReviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Acked-by:
Lucas De Marchi <lucas.demarchi@intel.com>
-
Ville Syrjälä authored
The code managing the dbuf slices is borked and needs some real work to fix. In the meantime let's just stop using the second slice. v2: Drop the change to intel_enabled_dbuf_slices_num() (Mahesh) Cc: Mahesh Kumar <mahesh1.sh.kumar@gmail.com> Reviewed-by: Imre Deak <imre.deak@intel.com> #v1 Signed-off-by:
Mahesh Kumar <mahesh1.sh.kumar@gmail.com>
-
Matt Roper authored
Use of the new DRM_COLOR_LUT_NON_DECREASING test was a bit over-zealous; it doesn't actually need to be applied to the degamma on "bdw-style" platforms. Likewise, we overlooked the fact that CHV should have that test applied to the gamma LUT as well as the degamma LUT. Rather than adding more complicated platform checking to intel_color_check(), let's just store the appropriate set of LUT validation flags for each platform in the intel_device_info structure. v2: - Shuffle around LUT size tests so that the hardware-specific tests won't be applied to legacy gamma tables. (Ville) - Add a debug message so that it will be easier to understand why an atomic transaction involving incorrectly-sized LUT's got rejected by the driver. v3: - Switch size_t's to int's. (Ville) Fixes: 85e2d61e ("drm/i915: Validate userspace-provided color management LUT's (v4)") References: https://lists.freedesktop.org/archives/intel-gfx/2019-January/187634.html Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
-
Matt Roper authored
We don't yet allow userspace to control the CRTC background color, but we should manually program the color to black to ensure the BIOS didn't leave us with some other color. We should also set the pipe gamma and pipe CSC bits so that the background color goes through the same color management transformations that a plane with black pixels would. v2: Rename register to SKL_BOTTOM_COLOR to more closely follow bspec naming. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
- 30 Jan, 2019 10 commits
-
-
Rodrigo Vivi authored
Signed-off-by:Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Ville Syrjälä authored
IS_GLK||IS_BXT == IS_GEN9_LP Signed-off-by:
-
Ville Syrjälä authored
0*whatever==0 so this check is pointless. Remove it. Signed-off-by:
-
Ville Syrjälä authored
The spec doesn't use a definite article in front of SAGV. The rules regarding articles and initialisms are super fuzzy, but at least to my ears it sounds much more natural to not have the article. Perhaps because I tend to pronounce it as "sag-vee" instead of spelling out the letters one at a time. Actually I might still prefer to leave out the article if I did spell them out. Signed-off-by:
-
Ville Syrjälä authored
skl_needs_memory_bw_wa() doesn't look at the passed in state at all. Possibly it should, but for now let's make life simpler by just passing in dev_priv. Signed-off-by:
-
Ville Syrjälä authored
On icl+ bspec tells us to calculate a separate minimum ddb allocation from the blocks watermark. Both have to be checked against the actual ddb allocation, but since we do things the other way around we'll just calculat the minimum acceptable ddb allocation by taking the maximum of the two values. We'll also replace the memcmp() with a full trawl over the the watermarks so that it'll ignore the min_ddb_alloc because we can't directly read that out from the hw. I suppose we could reconstruct it from the other values, but I was too lazy to do that now. Signed-off-by:
-
Ville Syrjälä authored
Bspec says we have to reject the watermark if it's >= the ddb allocation. Fix the code to reject the == case as it should. For transition watermarks we can just use >=, for the rest we'll do +1 when calculating the minimum ddb allocation size. Signed-off-by:
-
Ville Syrjälä authored
The spec used to say "8bpp" which someone took to mean 8 bytes per pixel when in fact it was supposed to be 8 bits per pixel. The spec has been updated to make it more clear now. Fix the code to match. Signed-off-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by:
-
Ville Syrjälä authored
I thought we could remove all the early latency==0 checks and rely on skl_wm_method{1,2}() checking for it. But skl_compute_plane_wm() applies a bunch of workarounds to bump up the latency before calling those guys so clearly it won't end up doing the right thing. Also not sure if the calculations based on the method1/2 results are safe agaisnt overflows so it might not work all that well in any case. Let's put the early check back. Signed-off-by: -
Ville Syrjälä authored
On glk+ the level 0 lines watermark actually matters. Do not ignore it. And while at it let's change things so that we always program a consistnet 0 to the register when the lines watermarks is ignored by the hardware. Signed-off-by:
-
- 29 Jan, 2019 17 commits
-
-
Lucas De Marchi authored
Instead of looping again on the range of plls, just keep track of one unused one and use it later. Signed-off-by:
-
Lucas De Marchi authored
We should not pass DPLL_ID_ICL_DPLL0 or DPLL_ID_ICL_DPLL1 to this function because the path is only taken for non-combophy ports. Let the warning trigger if improper value is given. While at it, rename the function to match the register name we are trying to program. v2: fix typo in comment Signed-off-by:
-
Lucas De Marchi authored
Even if we don't have the correct clock and get a warning, we should not skip the return. v2: improve commit message (from Joonas) Fixes: 1fa11ee2 ("drm/i915/icl: start adding the TBT pll") Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: <stable@vger.kernel.org> # v4.19+ Signed-off-by:
Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190125222444.19926-3-lucas.demarchi@intel.com
-
Lucas De Marchi authored
Fix the TODO leftover in the code by changing the argument in MG_PLL macros. The MG_PLL ids used to access the register values can be converted from tc_port rather than port. All these registers can use the TC port to calculate the right offsets because they are only available for TC ports. The range (PORT_C onwards) may not be stable and change from platform to platform. So by using the TC id directly we avoid having to check for the platform in the "leaf functions" and thus passing dev_priv around. The helper functions were also renamed to use "tc" as prefix to make them more generic. v2: Improve commit message and fix checkpatch warning (from Paulo) Signed-off-by:
-
Chris Wilson authored
Missed breadcrumb detection is defunct due to the tight coupling with dma_fence signaling and the myriad ways we may signal fences from everywhere but from an interrupt, i.e. we frequently signal a fence before we even see its interrupt. This means that even if we miss an interrupt for a fence, it still is signaled before our breadcrumb hangcheck fires, so simplify the breadcrumb hangchecking by moving it into the GPU hangcheck and forgo fake interrupts. Signed-off-by:
-
Chris Wilson authored
A few years ago, see commit 688e6c72 ("drm/i915: Slaughter the thundering i915_wait_request herd"), the issue of handling multiple clients waiting in parallel was brought to our attention. The requirement was that every client should be woken immediately upon its request being signaled, without incurring any cpu overhead. To handle certain fragility of our hw meant that we could not do a simple check inside the irq handler (some generations required almost unbounded delays before we could be sure of seqno coherency) and so request completion checking required delegation. Before commit 688e6c72, the solution was simple. Every client waiting on a request would be woken on every interrupt and each would do a heavyweight check to see if their request was complete. Commit 688e6c72 introduced an rbtree so that only the earliest waiter on the global timeline would woken, and would wake the next and so on. (Along with various complications to handle requests being reordered along the global timeline, and also a requirement for kthread to provide a delegate for fence signaling that had no process context.) The global rbtree depends on knowing the execution timeline (and global seqno). Without knowing that order, we must instead check all contexts queued to the HW to see which may have advanced. We trim that list by only checking queued contexts that are being waited on, but still we keep a list of all active contexts and their active signalers that we inspect from inside the irq handler. By moving the waiters onto the fence signal list, we can combine the client wakeup with the dma_fence signaling (a dramatic reduction in complexity, but does require the HW being coherent, the seqno must be visible from the cpu before the interrupt is raised - we keep a timer backup just in case). Having previously fixed all the issues with irq-seqno serialisation (by inserting delays onto the GPU after each request instead of random delays on the CPU after each interrupt), we can rely on the seqno state to perfom direct wakeups from the interrupt handler. This allows us to preserve our single context switch behaviour of the current routine, with the only downside that we lose the RT priority sorting of wakeups. In general, direct wakeup latency of multiple clients is about the same (about 10% better in most cases) with a reduction in total CPU time spent in the waiter (about 20-50% depending on gen). Average herd behaviour is improved, but at the cost of not delegating wakeups on task_prio. v2: Capture fence signaling state for error state and add comments to warm even the most cold of hearts. v3: Check if the request is still active before busywaiting v4: Reduce the amount of pointer misdirection with list_for_each_safe and using a local i915_request variable inside the loops v5: Add a missing pluralisation to a purely informative selftest message. References: 688e6c72 ("drm/i915: Slaughter the thundering i915_wait_request herd") Signed-off-by:
-
Chris Wilson authored
The global seqno is defunct and so we have no meaningful indicator of forward progress for an engine. You need to listen to the request signaling tracepoints instead. Signed-off-by:
-
Ville Syrjälä authored
Let's switch the pipe into interlaced mode and switch off the TV encoder vertical filter if the pipe vdisplay matches the TV YSIZE exactly. While I didn't measure it I presume this might reduce the power consumption a little bit, and the pixel rate is halved as the pipe will now fetching in interlaced mode rather than in progressive mode (effectively the same difference as between IF-ID vs. PF-ID pfit modes on more modern hardware) so a bit easier on the memory bandwidth. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
intel_tv_mode_to_mode() assumes the pipe will be in progressive fetch mode, and thus when programming the pipe into interlaced mode we have to halve the calculated dotclock to get the correct field duration. This becomes more important when we start to program the pipe into interlaced mode on i965gm as we depend on the timestamps to get accurate frame counter values. Withot halving the clock our guesstimated frame counter would tick at twice the expected speed. Cc: Imre Deak <imre.deak@intel.com> Fixes: 690157f0 ("drm/i915/tv: Fix >1024 modes on gen3") Signed-off-by:
-
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:
Sam Ravnborg <sam@ravnborg.org> Acked-by:
-
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 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: -
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:
-
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 5 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
-
