Tvrtko Ursulin [Fri, 21 Jun 2019 07:08:01 +0000 (08:08 +0100)]
drm/i915: Convert i915_gem_flush_ggtt_writes to intel_gt
Having introduced struct intel_gt (named the anonymous structure in i915)
we can start using it to compartmentalize our code better. It makes more
sense logically to have the code internally like this and it will also
help with future split between gt and display in i915.
v2:
* Keep ggtt flush before fb obj flush. (Chris)
Having made start to better code compartmentalization by introducing
struct intel_gt, continue the theme elsewhere in code by making functions
take parameters take what logically makes most sense for them instead of
the global struct drm_i915_private.
Tvrtko Ursulin [Fri, 21 Jun 2019 07:07:57 +0000 (08:07 +0100)]
drm/i915: Compartmentalize i915_ggtt_init_hw
Having made start to better code compartmentalization by introducing
struct intel_gt, continue the theme elsewhere in code by making functions
take parameters take what logically makes most sense for them instead of
the global struct drm_i915_private.
Tvrtko Ursulin [Fri, 21 Jun 2019 07:07:56 +0000 (08:07 +0100)]
drm/i915: Compartmentalize i915_ggtt_probe_hw
Having made start to better code compartmentalization by introducing
struct intel_gt, continue the theme elsewhere in code by making functions
take parameters take what logically makes most sense for them instead of
the global struct drm_i915_private.
Tvrtko Ursulin [Fri, 21 Jun 2019 07:07:53 +0000 (08:07 +0100)]
drm/i915: Convert i915_gem_init_hw to intel_gt
More removal of implicit dev_priv from using old mmio accessors.
Actually the top level function remains but is split into a part which
writes to i915 and part which operates on intel_gt in order to initialize
the hardware.
GuC and engines are the only odd ones out remaining.
Tvrtko Ursulin [Fri, 21 Jun 2019 07:07:45 +0000 (08:07 +0100)]
drm/i915: Convert i915_gem_init_swizzling to intel_gt
Start using the newly introduced struct intel_gt to fuse together correct
logical init flow with uncore for more removal of implicit dev_priv in
mmio access.
Chris Wilson [Thu, 20 Jun 2019 18:37:05 +0000 (19:37 +0100)]
drm/i915/gtt: Defer address space cleanup to an RCU worker
Enable RCU protection of i915_address_space and its ppgtt superclasses,
and defer its cleanup into a worker executed after an RCU grace period.
In the future we will be able to use the RCU protection to reduce the
locking around VM lookups, but the immediate benefit is being able to
defer the release into a kworker (process context). This is required as
we may need to sleep to reap the WC pages stashed away inside the ppgtt.
Chris Wilson [Thu, 20 Jun 2019 10:24:32 +0000 (11:24 +0100)]
drm/i915/selftests: Use request managed wakerefs
Since commit 79ffac8599c4 ("drm/i915: Invert the GEM wakeref
hierarchy"), the request creation itself took responsibility for
managing the engine/GT wakerefs and so we can remove the redundant grabs
in our selftests.
Chris Wilson [Wed, 19 Jun 2019 20:35:04 +0000 (21:35 +0100)]
drm/i915: Rings are always flushed
Our intel_rings are always flushed as they are continually used to submit
commands to the GPU, and so do not need to be flushed on unpinning. This
avoids pulling in the flush_ggtt_writes locking into our context
unpin, which we want to allow from atomic context (for simplicity).
Chris Wilson [Thu, 20 Jun 2019 14:20:52 +0000 (15:20 +0100)]
drm/i915/execlists: Minimalistic timeslicing
If we have multiple contexts of equal priority pending execution,
activate a timer to demote the currently executing context in favour of
the next in the queue when that timeslice expires. This enforces
fairness between contexts (so long as they allow preemption -- forced
preemption, in the future, will kick those who do not obey) and allows
us to avoid userspace blocking forward progress with e.g. unbounded
MI_SEMAPHORE_WAIT.
For the starting point here, we use the jiffie as our timeslice so that
we should be reasonably efficient wrt frequent CPU wakeups.
Chris Wilson [Thu, 20 Jun 2019 14:20:51 +0000 (15:20 +0100)]
drm/i915/execlists: Preempt-to-busy
When using a global seqno, we required a precise stop-the-workd event to
handle preemption and unwind the global seqno counter. To accomplish
this, we would preempt to a special out-of-band context and wait for the
machine to report that it was idle. Given an idle machine, we could very
precisely see which requests had completed and which we needed to feed
back into the run queue.
However, now that we have scrapped the global seqno, we no longer need
to precisely unwind the global counter and only track requests by their
per-context seqno. This allows us to loosely unwind inflight requests
while scheduling a preemption, with the enormous caveat that the
requests we put back on the run queue are still _inflight_ (until the
preemption request is complete). This makes request tracking much more
messy, as at any point then we can see a completed request that we
believe is not currently scheduled for execution. We also have to be
careful not to rewind RING_TAIL past RING_HEAD on preempting to the
running context, and for this we use a semaphore to prevent completion
of the request before continuing.
To accomplish this feat, we change how we track requests scheduled to
the HW. Instead of appending our requests onto a single list as we
submit, we track each submission to ELSP as its own block. Then upon
receiving the CS preemption event, we promote the pending block to the
inflight block (discarding what was previously being tracked). As normal
CS completion events arrive, we then remove stale entries from the
inflight tracker.
v2: Be a tinge paranoid and ensure we flush the write into the HWS page
for the GPU semaphore to pick in a timely fashion.
drm/i915/gvt: decouple check_vgpu() from uncore_init()
With multiple uncore to initialize (GT vs Display), it makes little
sense to have the vgpu_check inside uncore_init(). We also have
a catch-22 scenario where the uncore is required to read the vgpu
capabilities while the vgpu capabilities are required to decide if
we need to initialize forcewake support. To remove this circular
dependency, we can perform the required MMIO access by mmapping just
the vgtif shared page in mmio space and use raw accessors.
We'd like to introduce a display uncore with no forcewake domains, so
let's avoid wasting memory and be ready to allocate only what we need.
Even without multiple uncore, we still don't need all the domains on all
gens.
v2: avoid hidden control flow, improve checks (Tvrtko), fix IVB special
case, add failure injection point
drm/i915: skip forcewake actions on forcewake-less uncore
We always call some of the setup/cleanup functions for forcewake, even
if the feature is not actually available. Skipping these operations if
forcewake is not available saves us some operations on older gens and
prepares us for having a forcewake-less display uncore.
v2: do not make suspend/resume functions forcewake-specific (Chris,
Tvrtko), use GEM_BUG_ON in internal forcewake-only functions (Tvrtko)
drm/i915: use vfuncs for reg_read/write_fw_domains
Instead of going through the if-else chain every time, let's save the
function in the uncore structure. Note that the new functions are
purposely not used from the reg read/write functions to keep the
inlining there.
While at it, use the new macro to call the old ones to clean the code a
bit.
v2: Rename macros for no-forcewake function assignment (Tvrtko)
Chris Wilson [Wed, 19 Jun 2019 17:01:35 +0000 (18:01 +0100)]
drm/i915: Keep rings pinned while the context is active
Remember to keep the rings pinned as well as the context image until the
GPU is no longer active.
v2: Introduce a ring->pin_count primarily to hide the
mock_ring that doesn't fit into the normal GGTT vma picture.
v3: Order is important in teardown, ringbuffer submission needs to drop
the pin count on the engine->kernel_context before it can gleefully free
its ring.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110946 Fixes: ce476c80b8bf ("drm/i915: Keep contexts pinned until after the next kernel context switch") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190619170135.15281-1-chris@chris-wilson.co.uk
Matt Roper [Tue, 18 Jun 2019 17:51:31 +0000 (10:51 -0700)]
drm/i915/ehl: Allow combo PHY A to drive a third external display
EHL has a mux on combo PHY A that allows it to be driven either by an
internal display (DDI-A or DSI DPHY) or by an external display (DDI-D).
This is a motherboard design decision that can not be changed on the
fly. Unfortunately there are no strap registers that allow us to detect
the board configuration directly, so let's use the VBT to try to figure
it out and program the mux accordingly.
For now if we run across a broken VBT that tries to claim that PHY A
is attached to both internal and external displays at the same time,
we'll resolve the conflict in favor of the internal display. To help
debug these kind of bad VBT's, let's also add a quick DRM_DEBUG message
during child device parsing so that it's easier to understand these
cases if they show up in bug reports.
v2:
- Confirmed that VBT's dvo port refers to the DDI and not the PHY.
Thus we can check more explicitly for (ddi_d && !(ddi_a || dsi)). If
a bad VBT contradicts itself, let internal display win. (Ville)
v3:
- Switch condition from !IS_ICELAKE to IS_ELKHARTLAKE. Although the
convention is usually to assume that future platforms will inherit
all current platform behavior, this feels more like a one-platform
quirk. (Ville)
- Update commit message to describe what we do if/when we encounter
broken VBT's, and note that the new debug print during child device
parsing is intentional.
Chris Wilson [Tue, 18 Jun 2019 07:41:31 +0000 (08:41 +0100)]
drm/i915: Flush the execution-callbacks on retiring
In the unlikely case the request completes while we regard it as not even
executing on the GPU (see the next patch!), we have to flush any pending
execution callbacks at retirement and ensure that we do not add any
more.
Chris Wilson [Wed, 19 Jun 2019 11:23:37 +0000 (12:23 +0100)]
drm/i915: Signal fence completion from i915_request_wait
With the upcoming change to automanaged i915_active, the intent is that
whenever we wait on the set of active fences, they are signaled and
collected. The requirement is that all successful returns from
i915_request_wait() signal the fence, so fixup the one remaining path
where we may return before the interrupt has been run.
Chris Wilson [Tue, 18 Jun 2019 07:41:30 +0000 (08:41 +0100)]
drm/i915: Stop passing I915_WAIT_LOCKED to i915_request_wait()
Since commit eb8d0f5af4ec ("drm/i915: Remove GPU reset dependence on
struct_mutex"), the I915_WAIT_LOCKED flags passed to i915_request_wait()
has been defunct. Now go ahead and remove it from all callers.
Chris Wilson [Tue, 18 Jun 2019 11:07:36 +0000 (12:07 +0100)]
drm/i915/execlists: Detect cross-contamination with GuC
The process_csb routine from execlists_submission is incompatible with
the GuC backend. Add a warning to detect if we accidentally end up in
the wrong spot.
Chris Wilson [Tue, 18 Jun 2019 07:41:35 +0000 (08:41 +0100)]
drm/i915: Make the semaphore saturation mask global
The idea behind keeping the saturation mask local to a context backfired
spectacularly. The premise with the local mask was that we would be more
proactive in attempting to use semaphores after each time the context
idled, and that all new contexts would attempt to use semaphores
ignoring the current state of the system. This turns out to be horribly
optimistic. If the system state is still oversaturated and the existing
workloads have all stopped using semaphores, the new workloads would
attempt to use semaphores and be deprioritised behind real work. The
new contexts would not switch off using semaphores until their initial
batch of low priority work had completed. Given sufficient backload load
of equal user priority, this would completely starve the new work of any
GPU time.
To compensate, remove the local tracking in favour of keeping it as
global state on the engine -- once the system is saturated and
semaphores are disabled, everyone stops attempting to use semaphores
until the system is idle again. One of the reason for preferring local
context tracking was that it worked with virtual engines, so for
switching to global state we could either do a complete check of all the
virtual siblings or simply disable semaphores for those requests. This
takes the simpler approach of disabling semaphores on virtual engines.
The downside is that the decision that the engine is saturated is a
local measure -- we are only checking whether or not this context was
scheduled in a timely fashion, it may be legitimately delayed due to user
priorities. We still have the same dilemma though, that we do not want
to employ the semaphore poll unless it will be used.
v2: Explain why we need to assume the worst wrt virtual engines.
To do frontbuffer tracking we are depending on Display WA #0884 to
exit PSR when there is a frontbuffer modification but according to
user reports a write to CURSURFLIVE do not cause PSR to exit in older
gens so lets force a PSR exit.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110799 Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Tested-by: Thomas Rohwer <trohwer85@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190617195154.30292-1-jose.souza@intel.com
Chris Wilson [Tue, 18 Jun 2019 16:19:51 +0000 (17:19 +0100)]
drm/i915: Don't dereference request if it may have been retired when printing
This has caught me out on countless occasions, when we retrieve a pointer
from the submission/execlists backend, it does not carry a reference to
the context or ring. Those are only pinned while the request is active,
so if we see the request is already completed, it may be in the process
of being retired and those pointers defunct.
Chris Wilson [Tue, 18 Jun 2019 07:41:29 +0000 (08:41 +0100)]
drm/i915: Skip shrinking already freed pages
Previously, we wanted to shrink the pages of freed objects before they
were finally RCU collected. However, by removing the struct_mutex
serialisation around the active reference, we need to acquire an extra
reference around the wait. Unfortunately this means that we have to skip
objects that are waiting RCU collection.
John Harrison [Tue, 18 Jun 2019 01:01:07 +0000 (18:01 -0700)]
drm/i915: Add whitelist workarounds for ICL
Updated whitelist table for ICL.
v2: Reduce changes to just those required for media driver until
the selftest can be updated to support the new features of the
other entries.
Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Robert M. Fosha <robert.m.fosha@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190618010108.27499-4-John.C.Harrison@Intel.com
John Harrison [Tue, 18 Jun 2019 01:01:06 +0000 (18:01 -0700)]
drm/i915: Support whitelist workarounds on all engines
Newer hardware requires setting up whitelists on engines other than
render. So, extend the whitelist code to support all engines.
Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Robert M. Fosha <robert.m.fosha@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190618010108.27499-3-John.C.Harrison@Intel.com
Ville Syrjälä [Wed, 12 Jun 2019 13:08:01 +0000 (16:08 +0300)]
drm/i915: Drop the _INCOMPLETE for has_infoframe
We have full infoframe readout now so we can replace the
PIPE_CONF_CHECK_BOOL_INCOMPLETE(has_infoframe) with the normal
PIPE_CONF_CHECK_BOOL(has_infoframe).
Ville Syrjälä [Wed, 12 Jun 2019 13:08:00 +0000 (16:08 +0300)]
drm/i915: Make pipe_config_err() vs. fastset less confusing
Rename pipe_config_err() to pipe_config_mismatch(), and also print
whether we're doing the fastset check or the sw vs. hw state readout
check. Should make the logs a bit less confusing when they're not
filled with what looks like a real error.
Also rename the 'adjust' variable to 'fastset' to make it clear what
it means.
Ville Syrjälä [Wed, 12 Jun 2019 13:07:59 +0000 (16:07 +0300)]
drm/i915: Constify intel_pipe_config_compare()
Now that intel_pipe_config_compare() no longer clobbers the passed
in state we can make both crtc states const. And while at we simplify
the calling convention, and clean up intel_compare_link_m_n() a bit.
Ville Syrjälä [Wed, 12 Jun 2019 17:24:23 +0000 (20:24 +0300)]
drm/i915: Don't clobber M/N values during fastset check
We're now calling intel_pipe_config_compare(..., true) uncoditionally
which means we're always going clobber the calculated M/N values with
the old values if the fuzzy M/N check passes. That causes problems
because the fuzzy check allows for a huge difference in the values.
I'm actually tempted to just make the M/N checks exact, but that might
prevent fastboot from kicking in when people want it. So for now let's
overwrite the computed values with the old values only if decide to skip
the modeset.
v2: Copy has_drrs along with M/N M2/N2 values
Cc: stable@vger.kernel.org Cc: Blubberbub@protonmail.com Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Tested-by: Blubberbub@protonmail.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110782
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110675 Fixes: d19f958db23c ("drm/i915: Enable fastset for non-boot modesets.") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190612172423.25231-1-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
Chris Wilson [Tue, 18 Jun 2019 12:58:58 +0000 (13:58 +0100)]
drm/i915: Use drm_gem_object.resv
Since commit 1ba627148ef5 ("drm: Add reservation_object to
drm_gem_object"), struct drm_gem_object grew its own builtin
reservation_object rendering our own private one bloat. Remove our
redundant reservation_object and point into obj->base.resv instead.
Chris Wilson [Tue, 18 Jun 2019 07:41:28 +0000 (08:41 +0100)]
drm/i915: Keep engine alive as we retire the context
Though we pin the context first before taking the pm wakeref, during
retire we need to unpin before dropping the pm wakeref (breaking the
"natural" onion). During the unpin, we may need to attach a cleanup
operation on to the engine wakeref, ergo we want to keep the engine
awake until after the unpin.
v2: Push the engine wakeref into the barrier so we keep the onion unwind
ordering in the request itself
Chris Wilson [Mon, 17 Jun 2019 10:09:17 +0000 (11:09 +0100)]
drm/i915/guc: Reduce verbosity on log overflows
If the user is clearing the log buffer too slowly, we overflow. As this
is an expected condition, and the driver tries to handle it, reduce the
error message down to a notice.
Michal mentioned that another cause would be incorrect reset handling,
so we don't want to lose the notification entirely.
Matt Roper [Sat, 15 Jun 2019 00:42:10 +0000 (17:42 -0700)]
drm/i915/ehl: Introduce Mule Creek Canyon PCH
Although EHL introduces a new PCH, the South Display part of the PCH
that we care about is nearly identical to ICP, just with some pins
remapped. Most notably, Port C is mapped to the pins that ICP uses for
TC Port 1.
Chris Wilson [Mon, 17 Jun 2019 14:04:26 +0000 (15:04 +0100)]
drm/i915/gtt: Serialise both updates to PDE and our shadow
Currently, we perform a locked update of the shadow entry when
allocating a page directory entry such that if two clients are
concurrently allocating neighbouring ranges we only insert one new entry
for the pair of them. However, we also need to serialise both clients
wrt to the actual entry in the HW table, or else we may allow one client
or even a third client to proceed ahead of the HW write. My handwave
before was that under the _pathological_ condition we would see the
scratch entry instead of the expected entry, causing a temporary
glitch. That starvation condition will eventually show up in practice, so
fix it.
The reason for the previous cheat was to avoid having to free the extra
allocation while under the spinlock. Now, we keep the extra entry
allocated until the end instead.
v2: Fix error paths for gen6
Fixes: 1d1b5490b91c ("drm/i915/gtt: Replace struct_mutex serialisation for allocation") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190617140426.7203-1-chris@chris-wilson.co.uk
Lucas De Marchi [Fri, 7 Jun 2019 09:12:30 +0000 (02:12 -0700)]
drm/i915/dmc: protect against loading wrong firmware
In intel_package_header version 2 there's a new field in the
fw_info table that must be 0, otherwise it's not the correct DMC
firmware. Add a check for version 2 or later.
Lucas De Marchi [Fri, 7 Jun 2019 09:12:27 +0000 (02:12 -0700)]
drm/i915/dmc: extract function to parse dmc_header
Complete the extraction of functions to parse specific parts of the
firmware. The return of the function parse_csr_fw() is now redundant
since it already sets the dmc_payload field. Changing it is left for
later to avoid noise in the commit.
Lucas De Marchi [Fri, 7 Jun 2019 09:12:26 +0000 (02:12 -0700)]
drm/i915/dmc: extract function to parse package_header
Like parse_csr_fw_css() this parses the package_header from firmware and
saves the relevant fields in the csr struct. In this function we also
lookup the fw_info we are interested in.
Lucas De Marchi [Fri, 7 Jun 2019 09:12:25 +0000 (02:12 -0700)]
drm/i915/dmc: extract function to parse css header
Let's start splitting the parse function, making all of them return the
number of bytes parsed - different versions of the firmware header may
require different sizes for the structures.
v2: rework remaining bytes calculation on new protection for amount of
bytes read
Lucas De Marchi [Fri, 7 Jun 2019 09:12:23 +0000 (02:12 -0700)]
drm/i915/dmc: extract fw_info and table walk from intel_package_header
Move fw_info out of struct intel_package_header to allow it to grow more
easily in future. To make a cleaner move, let's also extract a function to
search the header for the dmc_offset.
While reviewing this code I wondered why we continued the search even
after finding a suitable firmware. Add a comment to explain we will
continue to try to find a more specific firmware version, even if this
is not required by the spec.
Mika Kuoppala [Fri, 14 Jun 2019 16:43:45 +0000 (19:43 +0300)]
drm/i915/gtt: Generalize alloc_pd
Allocate all page directory variants with alloc_pd. As
the lvl3 and lvl4 variants differ in manipulation, we
need to check for existence of backing phys page before accessing
it.
Mika Kuoppala [Fri, 14 Jun 2019 16:43:42 +0000 (19:43 +0300)]
drm/i915/gtt: Use a common type for page directories
All page directories are identical in function, only the position in the
hierarchy differ. Use same base type for directory functionality.
v2: cleanup, size always 512, init to null
Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Matthew Auld <matthew.william.auld@gmail.com> Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190614164350.30415-2-mika.kuoppala@linux.intel.com
drm/i915: no need to check return value of debugfs_create functions
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190613145229.21389-1-jani.nikula@intel.com
Shashank Sharma [Wed, 12 Jun 2019 06:45:00 +0000 (12:15 +0530)]
drm/i915/icl: Add Multi-segmented gamma support
ICL introduces a new gamma correction mode in display engine, called
multi-segmented-gamma mode. This mode allows users to program the
darker region of the gamma curve with sueprfine precision. An
example use case for this is HDR curves (like PQ ST-2084).
If we plot a gamma correction curve from value range between 0.0 to 1.0,
ICL's multi-segment has 3 different sections:
- superfine segment: 9 values, ranges between 0 - 1/(128 * 256)
- fine segment: 257 values, ranges between 0 - 1/(128)
- corase segment: 257 values, ranges between 0 - 1
This patch:
- Changes gamma LUTs size for ICL/GEN11 to 262144 entries (8 * 128 * 256),
so that userspace can program with highest precision supported.
- Changes default gamma mode (non-legacy) to multi-segmented-gamma mode.
- Adds functions to program/detect multi-segment gamma.
V2: Addressed review comments from Ville
- separate function for superfine and fine segments.
- remove enum for segments.
- reuse last entry of the LUT as gc_max value.
- replace if() ....cond with switch...case in icl_load_luts.
- add an entry variable, instead of 'word'
V3: Addressed review comments from Ville
- extra newline
- s/entry/color/
- remove LUT size checks
- program ilk_lut_12p4_ldw value before ilk_lut_12p4_udw
- Change the comments in description of fine and coarse segments,
and try to make more sense.
- use 8 * 128 instead of 1024
- add 1 entry in LUT for GCMAX
V4: Addressed review comments from Ville
- Remove unused macro
- missing shift entry in blue
- pick correct entry for GCMAX
- Added Ville's R-B
Note: Tested and confirmed the programming sequence of odd/even
registers in the HW. The correct sequence should be:
ilk_lut_12p4_udw
ilk_lut_12p4_ldw
v5: Addressed Ville's review comments and renamed odd/even register
helpers to be more consistent with the values.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1560321900-18318-5-git-send-email-uma.shankar@intel.com
Uma Shankar [Wed, 12 Jun 2019 06:44:58 +0000 (12:14 +0530)]
drm/i915/icl: Add register definitions for Multi Segmented gamma
Add macros to define multi segmented gamma registers
V2: Addressed Ville's comments:
Add gen-lable before bit definition
Addressed Jani's comment
- Use REG_GENMASK() and REG_BIT()
V3: Addressed Ville's comments:
- Put comments at the end of line.
- Change the comment at start of ICL multisegmented gamma registers.
Added Ville's r-b
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1560321900-18318-3-git-send-email-uma.shankar@intel.com
Shashank Sharma [Wed, 12 Jun 2019 06:44:57 +0000 (12:14 +0530)]
drm/i915: Change gamma/degamma_lut_size data type to u32
Currently, data type of gamma_lut_size & degamma_lut_size elements
in intel_device_info is u16, which means it can accommodate maximum
64k values. In case of ICL multisegmented gamma, the size of gamma
LUT is 256K.
This patch changes the data type of both of these elements to u32.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Uma Shankar <uma.shankar@intel.com>
V4: Added Uma's r-b.
Jani Nikula [Thu, 13 Jun 2019 08:44:15 +0000 (11:44 +0300)]
drm/i915: move modesetting output/encoder code under display/
Add a new subdirectory for display code, and start off by moving
modesetting output/encoder code. Judging by the include changes, this is
a surprisingly clean operation.
v2:
- move intel_sdvo_regs.h too
- use tabs for Makefile file lists and sort them
Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190613084416.6794-2-jani.nikula@intel.com
Jani Nikula [Thu, 13 Jun 2019 10:08:18 +0000 (13:08 +0300)]
drm/i915: make intel_sdvo_regs.h self-contained
Ensure intel_sdvo_regs.h is self-contained and remains that way.
v2:
- include <linux/compiler.h> for __packed (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190613100818.24800-1-jani.nikula@intel.com
Chris Wilson [Fri, 14 Jun 2019 22:06:16 +0000 (23:06 +0100)]
drm/i915: Avoid tainting i915_gem_park() with wakeref.lock
While we need to flush the wakeref before parking, we do not need to
perform the i915_gem_park() itself underneath the wakeref lock, merely
the struct_mutex. If we rearrange the locks, we can avoid the unnecessary
tainting.
Chris Wilson [Fri, 14 Jun 2019 16:46:06 +0000 (17:46 +0100)]
drm/i915: Replace engine->timeline with a plain list
To continue the onslaught of removing the assumption of a global
execution ordering, another casualty is the engine->timeline. Without an
actual timeline to track, it is overkill and we can replace it with a
much less grand plain list. We still need a list of requests inflight,
for the simple purpose of finding inflight requests (for retiring,
resetting, preemption etc).
Chris Wilson [Fri, 14 Jun 2019 16:46:04 +0000 (17:46 +0100)]
drm/i915: Keep contexts pinned until after the next kernel context switch
We need to keep the context image pinned in memory until after the GPU
has finished writing into it. Since it continues to write as we signal
the final breadcrumb, we need to keep it pinned until the request after
it is complete. Currently we know the order in which requests execute on
each engine, and so to remove that presumption we need to identify a
request/context-switch we know must occur after our completion. Any
request queued after the signal must imply a context switch, for
simplicity we use a fresh request from the kernel context.
The sequence of operations for keeping the context pinned until saved is:
- On context activation, we preallocate a node for each physical engine
the context may operate on. This is to avoid allocations during
unpinning, which may be from inside FS_RECLAIM context (aka the
shrinker)
- On context deactivation on retirement of the last active request (which
is before we know the context has been saved), we add the
preallocated node onto a barrier list on each engine
- On engine idling, we emit a switch to kernel context. When this
switch completes, we know that all previous contexts must have been
saved, and so on retiring this request we can finally unpin all the
contexts that were marked as deactivated prior to the switch.
We can enhance this in future by flushing all the idle contexts on a
regular heartbeat pulse of a switch to kernel context, which will also
be used to check for hung engines.
Asserts aside, all the code working on this structure is in
intel_runtime_pm.c and uses the intel_ prefix, so move the
structure to intel_runtime_pm.h and adopt the same prefix.
Since all the asserts are now working on the runtime_pm structure,
bring them across as well.
v2: drop unneeded include (Chris), don't rename debugfs, rebase
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190613232156.34940-5-daniele.ceraolospurio@intel.com
Quite a few of the call points have already switched to the version
working directly on the runtime_pm structure, so let's switch over the
rest and kill the i915-based asserts.
drm/i915: prefer i915_runtime_pm in intel_runtime function
As a first step towards updating the code to work on the runtime_pm
structure instead of i915, rework all the internals to use and pass
around that.
v2: add comment for kdev (Jani), move rpm init after pdev init for
mock_device
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190613232156.34940-2-daniele.ceraolospurio@intel.com
Matt Roper [Wed, 12 Jun 2019 18:36:31 +0000 (11:36 -0700)]
drm/i915: Add Wa_1409120013:icl,ehl
This chicken bit should be set before enabling FBC to avoid screen
corruption when the plane size has odd vertical and horizontal
dimensions. It is safe to leave the bit set even when FBC is disabled.
v2:
- The bspec's name for this bit on these platforms ("Spare 14") is
pretty meaningless. Let's rename the bit definition to something
that more accurately reflects what the bit really does. (Clint)
v3:
- The chicken register was already defined (along with a few other
gen9-specific bits) farther down. Just add the new bit definition
there. (Clint)
projects / kernel.git / log