Rodrigo Vivi [Fri, 26 Jun 2015 20:55:54 +0000 (13:55 -0700)]
drm/i915: Fix IPS related flicker
We cannot let IPS enabled with no plane on the pipe:
BSpec: "IPS cannot be enabled until after at least one plane has
been enabled for at least one vertical blank." and "IPS must be
disabled while there is still at least one plane enabled on the
same pipe as IPS." This restriction apply to HSW and BDW.
However a shortcut path on update primary plane function
to make primary plane invisible by setting DSPCTRL to 0
was leting IPS enabled while there was no
other plane enabled on the pipe causing flickerings that we were
believing that it was caused by that other restriction where
ips cannot be used when pixel rate is greater than 95% of cdclok.
v2: Don't mess with Atomic path as pointed out by Ville.
v3: Rebase after a long time and atomic path changes.
Accept Ville suggestion of not check !fb
v4: Re-factore on dinq
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=85583 Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Kenneth Graunke <kenneth@whitecape.org>
[danvet: Make it compile] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Damien Lespiau [Thu, 25 Jun 2015 15:15:06 +0000 (16:15 +0100)]
drm/i915/skl: Replace the HDMI DPLL divider computation algorithm
The HW validation team came back from further testing with a slightly
changed constraint on the deviation between the DCO frequency and the
central frequency. Instead of +-4%, it's now +1%/-6%.
Unfortunately, the previous algorithm didn't quite cope with these new
constraints, the reason being that it wasn't thorough enough looking at
the possible divider candidates.
The new algorithm looks at all dividers, which is definitely a hammer
approach (we could reduce further the set of dividers to good ones as a
follow up, at the cost of a bit more complicated code). But, at least,
we can now satisfy the +1%/+6% rule for all the "Well known" HDMI
frequencies of my test set (373 entries).
On that subject, the new code is quite extensively tested in
intel-gpu-tools (tools/skl_compute_wrpll).
v2: Fix cycling between central frequencies and dividers (Paulo)
Properly choose the minimal deviation between postive and negative
candidates (Paulo).
On the 373 test frequencies, v2 computes better dividers than v1 (ie
more even dividers and lower deviation on average):
v1: average deviation: 206.52
v2: average deviation: 194.47
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Michel Thierry [Wed, 10 Jun 2015 16:46:39 +0000 (17:46 +0100)]
drm/i915/gtt: Switch gen8_free_page_tables params
After Mika's ppgtt cleanup series, all the other free functions have
drm_device as the first parameter, except this one.
No functional changes.
Signed-off-by: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Michel Thierry [Fri, 26 Jun 2015 12:46:14 +0000 (13:46 +0100)]
drm/i915/lrc: Update PDPx registers with lri commands
A safer way to update the PDPx registers is sending lri commands, added
in the ring before the batchbuffer start. Otherwise, the ctx must be idle
before trying to change anything (but the ring-tail) in the ctx image. An
example where the ctx won't be idle is lite-restore.
This patch depends on 5b7e4c9ce ("drm/i915/gtt: Mark TLBS dirty for gen8+").
v2: Combine lri writes (and save 8 commands). (Mika)
v3: Rebase after ring/req changes, and removed references to deprecated patches.
Cc: Dave Gordon <david.s.gordon@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Mika Kuoppala [Thu, 25 Jun 2015 15:35:19 +0000 (18:35 +0300)]
drm/i915/gtt: Use nonatomic bitmap ops
There is no need for atomicity here. Convert all bitmap
operations to nonatomic variants.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Mika Kuoppala [Thu, 25 Jun 2015 15:35:17 +0000 (18:35 +0300)]
drm/i915/gtt: Move scratch_pd and scratch_pt into vm struct
Scratch page is part of struct i915_address_space. Move other
scratch entities into the same struct. This is a preparatory patch
for having only one instance of each scratch_pt/pd.
v2: make commit msg more readable
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> (v1)
[danvet: Bikeshed summary to avoid confusion with vmas.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Mika Kuoppala [Thu, 25 Jun 2015 15:35:16 +0000 (18:35 +0300)]
drm/i915/gtt: Cleanup page directory encoding
Write page directory entry without using superfluous
indirect function. Also remove unused device parameter
from the encode function.
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Mika Kuoppala [Thu, 25 Jun 2015 15:35:15 +0000 (18:35 +0300)]
drm/i915/gtt: Pin vma during virtual address allocation
Dynamic page table allocation might wake the shrinker
when memory is requested for page table structures.
As this happens when we try to allocate the virtual address
during binding, our vma might be among the targets for eviction.
We should do i915_vma_pin() and do pin early in there like Chris
suggests but this is interim solution.
Shield our vma from shrinker by incrementing pin count before
the virtual address is allocated.
The proper place to fix this would be in gem, inside of
i915_vma_pin(). But we don't have that yet so take the short
cut as a intermediate solution.
Testcase: igt/gem_ctx_thrash Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Mika Kuoppala [Thu, 25 Jun 2015 15:35:13 +0000 (18:35 +0300)]
drm/i915/gtt: Make scratch page i915_page_dma compatible
Lay out scratch page structure in similar manner than other
paging structures. This allows us to use the same tools for
setup and teardown.
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> (v2) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Mika Kuoppala [Thu, 25 Jun 2015 15:35:11 +0000 (18:35 +0300)]
drm/i915/gtt: Introduce kmap|kunmap for dma page
As there is flushing involved when we have done the cpu
write, make functions for mapping for cpu space. Make macros
to map any type of paging structure.
v2: Make it clear tha flushing kunmap is only for ppgtt (Ville)
v3: Flushing fixed (Ville, Michel). Removed superfluous semicolon
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Mika Kuoppala [Thu, 25 Jun 2015 15:35:10 +0000 (18:35 +0300)]
drm/i915/gtt: Introduce fill_page_dma()
When we setup page directories and tables, we point the entries
to a to the next level scratch structure. Make this generic
by introducing a fill_page_dma which maps and flushes. We also
need 32 bit variant for legacy gens.
v2: Fix flushes and handle valleyview (Ville)
v3: Now really fix flushes (Michel, Ville)
Reviewed-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Mika Kuoppala [Thu, 25 Jun 2015 15:35:09 +0000 (18:35 +0300)]
drm/i915/gtt: Remove superfluous free_pd with gen6/7
This has slipped in somewhere but it was harmless
as we check the page pointer before teardown.
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Mika Kuoppala [Thu, 25 Jun 2015 15:35:08 +0000 (18:35 +0300)]
drm/i915/gtt: Rename unmap_and_free_px to free_px
All the paging structures are now similar and mapped for
dma. The unmapping is taken care of by common accessors, so
don't overload the reader with such details.
v2: Be consistent with goto labels (Michel)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Mika Kuoppala [Thu, 25 Jun 2015 15:35:07 +0000 (18:35 +0300)]
drm/i915/gtt: Introduce struct i915_page_dma
All our paging structures have struct page and dma address
for that page.
Add struct for page/dma address pairs and use it to make
the setup and teardown for different paging structures
identical.
Include the page directory offset also in the struct for legacy
gens. Rename it to clearly point out that it is offset into the
ggtt.
v2: Add comment about ggtt_offset (Michel)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Mika Kuoppala [Thu, 25 Jun 2015 15:35:06 +0000 (18:35 +0300)]
drm/i915/gtt: Introduce i915_page_dir_dma_addr
The legacy mode mm switch and the execlist context assignment
needs dma address for the page directories.
Introduce a function that encapsulates the scratch_pd dma
fallback if no pd is found.
v2: Rebase, s/ring/req
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> (v1) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Mika Kuoppala [Thu, 25 Jun 2015 15:35:05 +0000 (18:35 +0300)]
drm/i915/gtt: Allow >= 4GB sizes for vm.
We can have exactly 4GB sized ppgtt with 32bit system.
size_t is inadequate for this.
v2: Convert a lot more places (Daniel)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Mika Kuoppala [Thu, 25 Jun 2015 15:35:04 +0000 (18:35 +0300)]
drm/i915/gtt: Check va range against vm size
Check the allocation area against the known end
of address space instead of against fixed value.
v2: Return ENODEV on internal bugs (Chris)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Wed, 24 Jun 2015 18:59:34 +0000 (21:59 +0300)]
drm/i915: Store frontbuffer_bits in the plane
Avoid some 'switch (plane->type)' by storing the fronbuffer_bits in
intel_plane.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: use singular frontbuffer_bits in intel_plane since a plan can
only ever have one bit. Discussed with Ville on irc.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Bob Paauwe [Tue, 23 Jun 2015 21:14:26 +0000 (14:14 -0700)]
drm/i915: Add the ddi get cdclk code for BXT (v3)
The registers and process differ from other platforms. If the hardware
was programmed incorrectly, this will return invalid cdclk values, which
should then cause reprogramming of the hardware.
v2(Matt): Return 19.2 MHz when DE PLL is disabled (Ville)
v3: Make less assumptions about the hardware state (Ville)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Bob Paauwe <bob.j.paauwe@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tvrtko Ursulin [Tue, 23 Jun 2015 11:57:43 +0000 (12:57 +0100)]
drm/i915: Return correct size for rotated views
Currently object size is returned for the rotated VMA size which can be
bigger than the rotated view itself. Since the binding code pads all
excess size with scratch pages the only minor issue with this is wasting
some GGTT space, but still feels nicer to fix and report the real size.
v2: Rebase for tracking size in bytes instead of pages.
Daniel Vetter [Thu, 18 Jun 2015 08:30:23 +0000 (10:30 +0200)]
drm/i915: Nuke lvds downclock support
With the new DRRS code it kinda sticks out, and we never managed to
get this to work well enough without causing issues. Time to wave
goodbye.
I've decided to keep the logic for programming the reduced clocks
intact, but everything else is gone. If anyone ever wants to resurrect
this we need to redo it all anyway on top of the frontbuffer tracking.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v3: GTT bit in scratch address should be mbz (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Dave Gordon <david.s.gordon@intel.com> Signed-off-by: Rafael Barbalho <rafael.barbalho@intel.com> Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 18 Jun 2015 08:30:27 +0000 (10:30 +0200)]
drm/i915/psr: Restrict single-shot updates to the PSR pipe
The frontbuffer code gives us accurate information about activity,
let's use it. Again this should avoid unecessary updates when multiple
screens are on.
Also realign function paramaters, I couldn't resist that bit of OCD.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Durgadoss R <durgadoss.r@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Daniel Vetter [Thu, 18 Jun 2015 08:30:26 +0000 (10:30 +0200)]
drm/i915/psr: Restrict buffer tracking to the PSR pipe
The current code tracks business across all pipes, but we're only
really interested in the one pipe DRRS is enabled on. Fairly tiny
optimization, but something I noticed while reading the code. But it
might matter a bit when e.g. showing a video or something only on the
external screen, while the panel is kept static.
Also regroup the code slightly: First compute new bitmasks, then take
appropriate actions.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Durgadoss R <durgadoss.r@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Daniel Vetter [Thu, 18 Jun 2015 08:30:25 +0000 (10:30 +0200)]
drm/i915/drrs: Restrict buffer tracking to the DRRS pipe
The current code tracks business across all pipes, but we're only
really interested in the one pipe DRRS is enabled on. Fairly tiny
optimization, but something I noticed while reading the code. But it
might matter a bit when e.g. showing a video or something only on the
external screen, while the panel is kept static.
Also regroup the code slightly: First compute new bitmasks, then take
appropriate actions.
Cc: Ramalingam C <ramalingam.c@intel.com> Cc: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Daniel Vetter [Thu, 18 Jun 2015 08:30:24 +0000 (10:30 +0200)]
drm/i915: s/update/compute/ for gmch dpll register functions
I was momentarily confused until I've double-checked that these
functions really only compute state and don't update the hardware
state. They once did that, but since Ander's rework of the dpll
computation flow that's no longer the case.
Rename them to avoid further confusion.
Note that the ilk code already follows the compute_dpll naming scheme
for computing the actual register value. DDI code goes with _calc_,
but that is close enough.
Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Daniel Vetter [Thu, 18 Jun 2015 08:30:22 +0000 (10:30 +0200)]
drm/i915: debugfs for frontbuffer tracking
Useful to figure out whether stuck bits are due to the frontbuffer
tracking code as opposed to individual consumers (who have their own
bitmask tracking).
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Daniel Vetter [Thu, 18 Jun 2015 08:30:21 +0000 (10:30 +0200)]
drm/i915: Filter out no-op frontbuffer tracking flushes
Paulo noticed that the fbc frontbuffer tracking flush callback
occasionally gets a call without any bit set. This can happen when we
have to filter flush calls due to e.g. gpu rendering. Filter these
out.
Reported-by: Paulo Zanoni <przanoni@gmail.com> Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Daniel Vetter [Thu, 18 Jun 2015 09:23:24 +0000 (11:23 +0200)]
drm/i915: Clear fb_tracking.busy_bits also for synchronous flips
The current/old frontbuffer might still have gpu frontbuffer rendering
pending. But once flipped it won't have the corresponding frontbuffer
bits any more and hence the request retire function won't ever clear
the corresponding busy bits. The async flip tracking (with the
flip_prepare and flip_complete functions) already does this, but
somehow I've forgotten to do this for synchronous flips.
Note that we don't track outstanding rendering of the new framebuffer
with busy_bits since all our plane update code waits for previous
rendering to complete before displaying a new buffer. Hence a new
buffer will never be busy.
v2: Drop the spurious inline Ville spotted.
v3: Don't touch flip_bits in the synchronsou frontbuffer_flip
function, noticed by Paulo.
v4: Remove one more inline that slipped through (Paulo).
Reported-by: Paulo Zanoni <przanoni@gmail.com> Cc: Paulo Zanoni <przanoni@gmail.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Testcase: igt/kms_frontbuffer_tracking/fbc-modesetfrombusy Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Arun Siluvery [Tue, 23 Jun 2015 14:50:44 +0000 (15:50 +0100)]
drm/i915: Bail out early if WA batch is not available for given Gen
To initialize WA batch, at the moment we first allocate batch and then check
whether we have any WA to be initialized for the given Gen; if we don't have
any WA then we WARN the user, destroy the batch and return but this is causing
another WARN in cleanup code complaining about sleeping in atomic context.
Till we understand this better and to keep things simpler, bail out early
if we don't have WA.
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Arun Siluvery [Tue, 23 Jun 2015 14:50:43 +0000 (15:50 +0100)]
drm/i915: Fix warnings reported by 0-day
Kernel 0-day framework reported warnings with WA batch patches, this patch
fixes those warnings and an additional warning reported in intel_lrc.c file.
Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:44:15 +0000 (17:44 +0100)]
drm/i915: Remove the now obsolete 'i915_gem_check_olr()'
As there is no OLR to check, the check_olr() function is now a no-op and can be
removed.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:44:14 +0000 (17:44 +0100)]
drm/i915: Update a bunch of LRC functions to take requests
A bunch of the low level LRC functions were passing around ringbuf and ctx
pairs. In a few cases, they took the r/c pair and a request as well. This is all
quite messy and unnecesary. The context_queue() call is especially bad since the
fake request code got removed - it takes a request and three extra things that
must be extracted from the request and then it checks them against what it finds
in the request. Removing all the derivable data makes the code much simpler all
round.
This patch updates those functions to just take the request structure.
Note that logical_ring_wait_for_space now takes a request structure but already
had a local request pointer that it uses to scan for something to wait on. To
avoid confusion the local variable has been renamed 'target' (it is searching
for a target request to do something with) and the parameter has been called req
(to guarantee anything accidentally missed gets a compiler error).
v2: Updated commit message re wait_for_space (Tomas Elf review comment).
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:44:13 +0000 (17:44 +0100)]
drm/i915: Remove 'faked' request from LRC submission
The LRC submission code requires a request for tracking purposes. It does not
actually require that request to 'complete' it simply uses it for keeping hold
of reference counts on contexts and such like.
Previously, the fall back path of polling for space in the ring would start by
submitting any outstanding work that was sat in the buffer. This submission was
not done as part of the request that that work was owned by because that would
lead to complications with the request being submitted twice. Instead, a null
request structure was passed in to the submit call and a fake one was created.
That fall back path has long since been obsoleted and has now been removed. Thus
there is never any need to fake up a request structure. This patch removes that
code. A couple of sanity check warnings are added as well, just in case.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Thomas Daniel <thomas.daniel@intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:44:12 +0000 (17:44 +0100)]
drm/i915: Move the request/file and request/pid association to creation time
In _i915_add_request(), the request is associated with a userland client.
Specifically it is linked to the 'file' structure and the current user process
is recorded. One problem here is that the current user process is not
necessarily the same as when the request was submitted to the driver. This is
especially true when the GPU scheduler arrives and decouples driver submission
from hardware submission. Note also that it is only in the case where the add
request comes from an execbuff call that there is a client to associate. Any
other add request call is kernel only so does not need to do it.
This patch moves the client association into a separate function. This is then
called from the execbuffer code path itself at a sensible time. It also removes
the now redundant 'file' pointer from the add request parameter list.
An extra cleanup of the client association is also added to the request clean up
code for the eventuality where the request is killed after association but
before being submitted (e.g. due to out of memory error somewhere). Once the
submission has happened, the request is on the request list and the regular
request list removal will clear the association. Note that this still needs to
happen at this point in time because the request might be kept floating around
much longer (due to someone holding a reference count) and the client should not
be worrying about this request after it has been retired.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:44:11 +0000 (17:44 +0100)]
drm/i915: Remove the now obsolete 'outstanding_lazy_request'
The outstanding_lazy_request is no longer used anywhere in the driver.
Everything that was looking at it now has a request explicitly passed in from on
high. Everything that was relying upon it behind the scenes is now explicitly
creating/passing/submitting its own private request. Thus the OLR can be
removed.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:44:10 +0000 (17:44 +0100)]
drm/i915: Remove the now obsolete intel_ring_get_request()
Much of the driver has now been converted to passing requests around instead of
rings/ringbufs/contexts. Thus the function for retreiving the request from a
ring (i.e. the OLR) is no longer used and can be removed.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:44:09 +0000 (17:44 +0100)]
drm/i915: Add *_ring_begin() to request allocation
Now that the *_ring_begin() functions no longer call the request allocation
code, it is finally safe for the request allocation code to call *_ring_begin().
This is important to guarantee that the space reserved for the subsequent
i915_add_request() call does actually get reserved.
v2: Renamed functions according to review feedback (Tomas Elf).
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:44:08 +0000 (17:44 +0100)]
drm/i915: Update intel_logical_ring_begin() to take a request structure
Now that everything above has been converted to use requests,
intel_logical_ring_begin() can be updated to take a request instead of a
ringbuf/context pair. This also means that it no longer needs to lazily allocate
a request if no-one happens to have done it earlier.
Note that this change makes the execlist signature the same as the legacy
version. Thus the two functions could be merged into a ring->begin() wrapper if
required.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:44:07 +0000 (17:44 +0100)]
drm/i915: Update intel_ring_begin() to take a request structure
Now that everything above has been converted to use requests, intel_ring_begin()
can be updated to take a request instead of a ring. This also means that it no
longer needs to lazily allocate a request if no-one happens to have done it
earlier.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:44:06 +0000 (17:44 +0100)]
drm/i915: Update cacheline_align() to take a request structure
Updated intel_ring_cacheline_align() to take a request instead of a ring.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:44:05 +0000 (17:44 +0100)]
drm/i915: Update ring->signal() to take a request structure
Updated the various ring->signal() implementations to take a request instead of
a ring. This removes their reliance on the OLR to obtain the seqno value that
should be used for the signal.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:44:04 +0000 (17:44 +0100)]
drm/i915: Update ring->sync_to() to take a request structure
Updated the ring->sync_to() implementations to take a request instead of a ring.
Also updated the tracer to include the request id.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com>
[danvet: Rebase since I didn't merge the patch which added ->uniq.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:44:03 +0000 (17:44 +0100)]
drm/i915: Update ring->emit_bb_start() to take a request structure
Updated the ring->emit_bb_start() implementation to take a request instead of a
ringbuf/context pair.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:44:02 +0000 (17:44 +0100)]
drm/i915: Update ring->dispatch_execbuffer() to take a request structure
Updated the various ring->dispatch_execbuffer() implementations to take a
request instead of a ring.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:44:01 +0000 (17:44 +0100)]
drm/i915: Update ring->emit_request() to take a request structure
Updated the ring->emit_request() implementation to take a request instead of a
ringbuf/request pair. Also removed its use of the OLR for obtaining the
request's seqno.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:44:00 +0000 (17:44 +0100)]
drm/i915: Update ring->add_request() to take a request structure
Updated the various ring->add_request() implementations to take a request
instead of a ring. This removes their reliance on the OLR to obtain the seqno
value that the request should be tagged with.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:43:59 +0000 (17:43 +0100)]
drm/i915: Update ring->emit_flush() to take a request structure
Updated the various ring->emit_flush() implementations to take a request instead
of a ringbuf/context pair.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:43:58 +0000 (17:43 +0100)]
drm/i915: Update some flush helpers to take request structures
Updated intel_emit_post_sync_nonzero_flush(), gen7_render_ring_cs_stall_wa() and
gen8_emit_pipe_control() to take requests instead of rings.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:43:57 +0000 (17:43 +0100)]
drm/i915: Update ring->flush() to take a requests structure
Updated the various ring->flush() functions to take a request instead of a ring.
Also updated the tracer to include the request id.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com>
[danvet: Rebase since I didn't merge the addition of req->uniq.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:43:56 +0000 (17:43 +0100)]
drm/i915: Update switch_mm() to take a request structure
Updated the switch_mm() code paths to take a request instead of a ring. This
includes the myriad *_mm_switch functions themselves and a bunch of PDP related
helper functions.
v2: Rebased to newer tree.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:43:55 +0000 (17:43 +0100)]
drm/i915: Update flush_all_caches() to take request structures
Updated the *_ring_flush_all_caches() functions to take requests instead of
rings or ringbuf/context pairs.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:43:54 +0000 (17:43 +0100)]
drm/i915: Update workarounds_emit() to take request structures
Updated the *_ring_workarounds_emit() functions to take requests instead of
ring/context pairs.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:43:53 +0000 (17:43 +0100)]
drm/i915: Update a bunch of execbuffer helpers to take request structures
Updated *_ring_invalidate_all_caches(), i915_reset_gen7_sol_offsets() and
i915_emit_box() to take request structures instead of ring or ringbuf/context
pairs.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:43:52 +0000 (17:43 +0100)]
drm/i915: Update mi_set_context() to take a request structure
Updated mi_set_context() to take a request structure instead of a ring and
context pair.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:43:51 +0000 (17:43 +0100)]
drm/i915: Update l3_remap to take a request structure
Converted i915_gem_l3_remap() to take a request structure instead of a ring.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:43:50 +0000 (17:43 +0100)]
drm/i915: Update [vma|object]_move_to_active() to take request structures
Now that everything above has been converted to use request structures, it is
possible to update the lower level move_to_active() functions to be request
based as well.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:43:49 +0000 (17:43 +0100)]
drm/i915: Update add_request() to take a request structure
Now that all callers of i915_add_request() have a request pointer to hand, it is
possible to update the add request function to take a request pointer rather
than pulling it out of the OLR.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:43:48 +0000 (17:43 +0100)]
drm/i915: Update queue_flip() to take a request structure
Updated the display page flip code to do explicit request creation and
submission rather than relying on the OLR and just hoping that the request
actually gets submitted at some random point.
The sequence is now to create a request, queue the work to the ring, assign the
known request to the flip queue work item then actually submit the work and post
the request.
Note that every single flip function used to finish with
'__intel_ring_advance(ring);'. However, immediately after they return there is
now an add request call which will do the advance anyway. Thus the many
duplicate advance calls have been removed.
v2: Updated commit message with comment about advance removal.
v3: The request can now be allocated by the _sync() code earlier on. Thus the
page flip path does not necessarily need to allocate a new request, it may be
able to re-use one.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:43:47 +0000 (17:43 +0100)]
drm/i915: Update overlay code to do explicit request management
The overlay update code path to do explicit request creation and submission
rather than relying on the OLR to do the right thing.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Thu, 18 Jun 2015 12:14:56 +0000 (13:14 +0100)]
drm/i915: Update i915_gem_object_sync() to take a request structure
The plan is to pass requests around as the basic submission tracking structure
rather than rings and contexts. This patch updates the i915_gem_object_sync()
code path.
v2: Much more complex patch to share a single request between the sync and the
page flip. The _sync() function now supports lazy allocation of the request
structure. That is, if one is passed in then that will be used. If one is not,
then a request will be allocated and passed back out. Note that the _sync() code
does not necessarily require a request. Thus one will only be created until
certain situations. The reason the lazy allocation must be done within the
_sync() code itself is because the decision to need one or not is not really
something that code above can second guess (except in the case where one is
definitely not required because no ring is passed in).
The call chains above _sync() now support passing a request through which most
callers passing in NULL and assuming that no request will be required (because
they also pass in NULL for the ring and therefore can't be generating any ring
code).
The exeception is intel_crtc_page_flip() which now supports having a request
returned from _sync(). If one is, then that request is shared by the page flip
(if the page flip is of a type to need a request). If _sync() does not generate
a request but the page flip does need one, then the page flip path will create
its own request.
v3: Updated comment description to be clearer about 'to_req' parameter (Tomas
Elf review request). Rebased onto newer tree that significantly changed the
synchronisation code.
v4: Updated comments from review feedback (Tomas Elf)
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:43:45 +0000 (17:43 +0100)]
drm/i915: Update render_state_init() to take a request structure
Updated the two render_state_init() functions to take a request pointer instead
of a ring. This removes their reliance on the OLR.
v2: Rebased to newer tree.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:43:44 +0000 (17:43 +0100)]
drm/i915: Update init_context() to take a request structure
Now that everything above has been converted to use requests, it is possible to
update init_context() to take a request pointer instead of a ring/context pair.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:43:43 +0000 (17:43 +0100)]
drm/i915: Update deferred context creation to do explicit request management
In execlist mode, context initialisation is deferred until first use of the
given context. This is because execlist mode has per ring context state and thus
many more context storage objects than legacy mode and many are never actually
used. Previously, the initialisation commands were written to the ring and
tagged with some random request structure via the OLR. This seemed to be causing
a null pointer deference bug under certain circumstances (BZ:88865).
This patch adds explicit request creation and submission to the deferred
initialisation code path. Thus removing any reliance on or randomness caused by
the OLR.
Note that it should be possible to move the deferred context creation until even
later - when the context is actually switched to rather than when it is merely
validated. This would allow the initialisation to be done within the request of
the work that is wanting to use the context. Hence, the extra request that is
created, used and retired just for the context init could be removed completely.
However, this is left for a follow up patch.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:43:42 +0000 (17:43 +0100)]
drm/i915: Update do_switch() to take a request structure
Updated do_switch() to take a request pointer instead of a ring/context pair.
v2: Removed some overzealous req-> dereferencing.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:43:41 +0000 (17:43 +0100)]
drm/i915: Update i915_switch_context() to take a request structure
Now that the request is guaranteed to specify the context, it is possible to
update the context switch code to use requests rather than ring and context
pairs. This patch updates i915_switch_context() accordingly.
Also removed the warning that the request's context must match the last context
switch's context. As the context switch now gets the context object from the
request structure, there is no longer any scope for the two to become out of
step.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:43:40 +0000 (17:43 +0100)]
drm/i915: Update ppgtt_init_ring() & context_enable() to take requests
The final step in removing the OLR from i915_gem_init_hw() is to pass the newly
allocated request structure in to each step rather than passing a ring
structure. This patch updates both i915_ppgtt_init_ring() and
i915_gem_context_enable() to take request pointers.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:43:39 +0000 (17:43 +0100)]
drm/i915: Add explicit request management to i915_gem_init_hw()
Now that a single per ring loop is being done for all the different
intialisation steps in i915_gem_init_hw(), it is possible to add proper request
management as well. The last remaining issue is that the context enable call
eventually ends up within *_render_state_init() and this does its own private
_i915_add_request() call.
This patch adds explicit request creation and submission to the top level loop
and removes the add_request() from deep within the sub-functions.
v2: Updated for removal of batch_obj from add_request call in previous patch.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:43:38 +0000 (17:43 +0100)]
drm/i915: Don't tag kernel batches as user batches
The render state initialisation code does an explicit i915_add_request() call to
commit the init commands. It was passing in the initialisation batch buffer to
add_request() as the batch object parameter. However, the batch object entry in
the request structure (which is all that parameter is used for) is meant for
keeping track of user generated batch buffers for blame tagging during GPU
hangs.
This patch clears the batch object parameter so that kernel generated batch
buffers are not tagged as being user generated.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:43:37 +0000 (17:43 +0100)]
drm/i915: Moved the for_each_ring loop outside of i915_gem_context_enable()
The start of day context initialisation code in i915_gem_context_enable() loops
over each ring and calls the legacy switch context or the execlist init context
code as appropriate.
This patch moves the ring looping out of that function in to the top level
caller i915_gem_init_hw(). This means the a single pass can be made over all
rings doing the PPGTT, L3 remap and context initialisation of each ring
altogether.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Thu, 18 Jun 2015 12:11:20 +0000 (13:11 +0100)]
drm/i915: Split i915_ppgtt_init_hw() in half - generic and per ring
The i915_gem_init_hw() function calls a bunch of smaller initialisation
functions. Multiple of which have generic sections and per ring sections. This
means multiple passes are done over the rings. Each pass writes data to the ring
which floats around in that ring's OLR until some random point in the future
when an add_request() is done by some random other piece of code.
This patch breaks i915_ppgtt_init_hw() in two with the per ring initialisation
now being done in i915_ppgtt_init_ring(). The ring looping is now done at the
top level in i915_gem_init_hw().
v2: Fix dumb loop variable re-use.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> (v1) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:43:35 +0000 (17:43 +0100)]
drm/i915: Update i915_gpu_idle() to manage its own request
Added explicit request creation and submission to the GPU idle code path.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:43:34 +0000 (17:43 +0100)]
drm/i915: Add flag to i915_add_request() to skip the cache flush
In order to explcitly track all GPU work (and completely remove the outstanding
lazy request), it is necessary to add extra i915_add_request() calls to various
places. Some of these do not need the implicit cache flush done as part of the
standard batch buffer submission process.
This patch adds a flag to _add_request() to specify whether the flush is
required or not.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:43:33 +0000 (17:43 +0100)]
drm/i915: Update execbuffer_move_to_active() to take a request structure
The plan is to pass requests around as the basic submission tracking structure
rather than rings and contexts. This patch updates the
execbuffer_move_to_active() code path.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:43:32 +0000 (17:43 +0100)]
drm/i915: Update move_to_gpu() to take a request structure
The plan is to pass requests around as the basic submission tracking structure
rather than rings and contexts. This patch updates the move_to_gpu() code paths.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:43:31 +0000 (17:43 +0100)]
drm/i915: Update the dispatch tracepoint to use params->request
Updated a couple of trace points to use the now cached request pointer rather
than extracting it from the ring.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:43:30 +0000 (17:43 +0100)]
drm/i915: Add request to execbuf params and add explicit cleanup
Rather than just having a local request variable in the execbuff code, the
request pointer is now stored in the execbuff params structure. Also added
explicit cleanup of the request (plus wiping the OLR to match) in the error
case. This means that the execbuff code is no longer dependent upon the OLR
keeping track of the request so as to not leak it when things do go wrong. Note
that in the success case, the i915_add_request() at the end of the submission
function will tidy up the request and clear the OLR.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:43:29 +0000 (17:43 +0100)]
drm/i915: Update alloc_request to return the allocated request
The alloc_request() function does not actually return the newly allocated
request. Instead, it must be pulled from ring->outstanding_lazy_request. This
patch fixes this so that code can create a request and start using it knowing
exactly which request it actually owns.
v2: Updated for new i915_gem_request_alloc() scheme.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Shrunk the parameter list of i915_gem_execbuffer_retire_commands() to a single
structure as everything it requires is available in the execbuff_params object.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:43:27 +0000 (17:43 +0100)]
drm/i915: Merged the many do_execbuf() parameters into a structure
The do_execbuf() function takes quite a few parameters. The actual set of
parameters is going to change with the conversion to passing requests around.
Further, it is due to grow massively with the arrival of the GPU scheduler.
This patch simplifies the prototype by passing a parameter structure instead.
Changing the parameter set in the future is then simply a matter of
adding/removing items to the structure.
Note that the structure does not contain absolutely everything that is passed
in. This is because the intention is to use this structure more extensively
later in this patch series and more especially in the GPU scheduler that is
coming soon. The latter requires hanging on to the structure as the final
hardware submission can be delayed until long after the execbuf IOCTL has
returned to user land. Thus it is unsafe to put anything in the structure that
is local to the IOCTL call itself - such as the 'args' parameter. All entries
must be copies of data or pointers to structures that are reference counted in
some way and guaranteed to exist for the duration of the batch buffer's life.
v2: Rebased to newer tree and updated for changes to the command parser.
Specifically, a code shuffle has required saving the batch start address in the
params structure.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:43:26 +0000 (17:43 +0100)]
drm/i915: Set context in request from creation even in legacy mode
In execlist mode, the context object pointer is written in to the request
structure (and reference counted) at the point of request creation. In legacy
mode, this only happens inside i915_add_request().
This patch updates the legacy code path to match the execlist version. This
allows all the intermediate code between request creation and request submission
to get at the context object given only a request structure. Thus negating the
need to pass context pointers here, there and everywhere.
v2: Moved the context reference so it does not need to be undone if the
get_seqno() fails.
v3: Fixed execlist mode always hitting a warning about invalid last_contexts
(which don't exist in execlist mode).
v4: Updated for new i915_gem_request_alloc() scheme.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:43:25 +0000 (17:43 +0100)]
drm/i915: Early alloc request in execbuff
Start of explicit request management in the execbuffer code path. This patch
adds a call to allocate a request structure before all the actual hardware work
is done. Thus guaranteeing that all that work is tagged by a known request. At
present, nothing further is done with the request, the rest comes later in the
series.
The only noticable change is that failure to get a request (e.g. due to lack of
memory) will be caught earlier in the sequence. It now occurs right at the start
before any un-undoable work has been done.
v2: Simplified the error handling path.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Fri, 29 May 2015 16:43:24 +0000 (17:43 +0100)]
drm/i915: i915_add_request must not fail
The i915_add_request() function is called to keep track of work that has been
written to the ring buffer. It adds epilogue commands to track progress (seqno
updates and such), moves the request structure onto the right list and other
such house keeping tasks. However, the work itself has already been written to
the ring and will get executed whether or not the add request call succeeds. So
no matter what goes wrong, there isn't a whole lot of point in failing the call.
At the moment, this is fine(ish). If the add request does bail early on and not
do the housekeeping, the request will still float around in the
ring->outstanding_lazy_request field and be picked up next time. It means
multiple pieces of work will be tagged as the same request and driver can't
actually wait for the first piece of work until something else has been
submitted. But it all sort of hangs together.
This patch series is all about removing the OLR and guaranteeing that each piece
of work gets its own personal request. That means that there is no more
'hoovering up of forgotten requests'. If the request does not get tracked then
it will be leaked. Thus the add request call _must_ not fail. The previous patch
should have already ensured that it _will_ not fail by removing the potential
for running out of ring space. This patch enforces the rule by actually removing
the early exit paths and the return code.
Note that if something does manage to fail and the epilogue commands don't get
written to the ring, the driver will still hang together. The request will be
added to the tracking lists. And as in the old case, any subsequent work will
generate a new seqno which will suffice for marking the old one as complete.
v2: Improved WARNings (Tomas Elf review request).
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Thu, 18 Jun 2015 12:10:09 +0000 (13:10 +0100)]
drm/i915: Reserve ring buffer space for i915_add_request() commands
It is a bad idea for i915_add_request() to fail. The work will already have been
send to the ring and will be processed, but there will not be any tracking or
management of that work.
The only way the add request call can fail is if it can't write its epilogue
commands to the ring (cache flushing, seqno updates, interrupt signalling). The
reasons for that are mostly down to running out of ring buffer space and the
problems associated with trying to get some more. This patch prevents that
situation from happening in the first place.
When a request is created, it marks sufficient space as reserved for the
epilogue commands. Thus guaranteeing that by the time the epilogue is written,
there will be plenty of space for it. Note that a ring_begin() call is required
to actually reserve the space (and do any potential waiting). However, that is
not currently done at request creation time. This is because the ring_begin()
code can allocate a request. Hence calling begin() from the request allocation
code would lead to infinite recursion! Later patches in this series remove the
need for begin() to do the allocate. At that point, it becomes safe for the
allocate to call begin() and really reserve the space.
Until then, there is a potential for insufficient space to be available at the
point of calling i915_add_request(). However, that would only be in the case
where the request was created and immediately submitted without ever calling
ring_begin() and adding any work to that request. Which should never happen. And
even if it does, and if that request happens to fall down the tiny window of
opportunity for failing due to being out of ring space then does it really
matter because the request wasn't doing anything in the first place?
v2: Updated the 'reserved space too small' warning to include the offending
sizes. Added a 'cancel' operation to clean up when a request is abandoned. Added
re-initialisation of tracking state after a buffer wrap to keep the sanity
checks accurate.
v3: Incremented the reserved size to accommodate Ironlake (after finally
managing to run on an ILK system). Also fixed missing wrap code in LRC mode.
v4: Added extra comment and removed duplicate WARN (feedback from Tomas).
For: VIZ-5115 CC: Tomas Elf <tomas.elf@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just always take ours, same as git merge -X ours, but done by hand
because I didn't trust git: It's confusing that it doesn't show any
conflicts in the merge diff at all.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
In Indirect context w/a batch buffer,
+WaFlushCoherentL3CacheLinesAtContextSwitch:bdw
v2: Add LRI commands to set/reset bit that invalidates coherent lines,
update WA to include programming restrictions and exclude CHV as
it is not required (Ville)
v3: Avoid unnecessary read when it can be done by reading register once (Chris).
Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Dave Gordon <david.s.gordon@intel.com> Signed-off-by: Rafael Barbalho <rafael.barbalho@intel.com> Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In Indirect and Per context w/a batch buffer,
+WaDisableCtxRestoreArbitration
Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Dave Gordon <david.s.gordon@intel.com> Signed-off-by: Rafael Barbalho <rafael.barbalho@intel.com> Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Arun Siluvery [Fri, 19 Jun 2015 17:37:11 +0000 (18:37 +0100)]
drm/i915/gen8: Re-order init pipe_control in lrc mode
Some of the WA applied using WA batch buffers perform writes to scratch page.
In the current flow WA are initialized before scratch obj is allocated.
This patch reorders intel_init_pipe_control() to have a valid scratch obj
before we initialize WA.
v2: Check for valid scratch page before initializing WA as some of them
perform writes to it.
Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Dave Gordon <david.s.gordon@intel.com> Signed-off-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Arun Siluvery [Fri, 19 Jun 2015 18:07:01 +0000 (19:07 +0100)]
drm/i915/gen8: Add infrastructure to initialize WA batch buffers
Some of the WA are to be applied during context save but before restore and
some at the end of context save/restore but before executing the instructions
in the ring, WA batch buffers are created for this purpose and these WA cannot
be applied using normal means. Each context has two registers to load the
offsets of these batch buffers. If they are non-zero, HW understands that it
need to execute these batches.
v1: In this version two separate ring_buffer objects were used to load WA
instructions for indirect and per context batch buffers and they were part
of every context.
v2: Chris suggested to include additional page in context and use it to load
these WA instead of creating separate objects. This will simplify lot of things
as we need not explicity pin/unpin them. Thomas Daniel further pointed that GuC
is planning to use a similar setup to share data between GuC and driver and
WA batch buffers can probably share that page. However after discussions with
Dave who is implementing GuC changes, he suggested to use an independent page
for the reasons - GuC area might grow and these WA are initialized only once and
are not changed afterwards so we can share them share across all contexts.
The page is updated with WA during render ring init. This has an advantage of
not adding more special cases to default_context.
We don't know upfront the number of WA we will applying using these batch buffers.
For this reason the size was fixed earlier but it is not a good idea. To fix this,
the functions that load instructions are modified to report the no of commands
inserted and the size is now calculated after the batch is updated. A macro is
introduced to add commands to these batch buffers which also checks for overflow
and returns error.
We have a full page dedicated for these WA so that should be sufficient for
good number of WA, anything more means we have major issues.
The list for Gen8 is small, same for Gen9 also, maybe few more gets added
going forward but not close to filling entire page. Chris suggested a two-pass
approach but we agreed to go with single page setup as it is a one-off routine
and simpler code wins.
One additional option is offset field which is helpful if we would like to
have multiple batches at different offsets within the page and select them
based on some criteria. This is not a requirement at this point but could
help in future (Dave).
Chris provided some helpful macros and suggestions which further simplified
the code, they will also help in reducing code duplication when WA for
other Gen are added. Add detailed comments explaining restrictions.
Use do {} while(0) for wa_ctx_emit() macro.
(Many thanks to Chris, Dave and Thomas for their reviews and inputs)
Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Dave Gordon <david.s.gordon@intel.com> Signed-off-by: Rafael Barbalho <rafael.barbalho@intel.com> Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Thu, 18 Jun 2015 10:42:08 +0000 (11:42 +0100)]
drm/i915: Report an error when i915.reset prevents a reset
If the user disables the GPU reset using the i915.reset parameter and
one occurs, report that we failed to reset the GPU. If we return early,
as we currently do, then we leave all state intact (with a hung GPU)
and clients block forever waiting for their requests to complete.
Testcase: igt/gem_eio Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Mark i915.reset as an unsafe modoption, as discussed with
Chris.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
projects / karo-tx-linux.git / log