The prep to remove the flushing list in
commit cc889e0f6c
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Jun 13 20:45:19 2012 +0200
drm/i915: disable flushing_list/gpu_write_list
causes quite some decent regressions. We can fix this by setting the
CS_STALL bit to ensure that the following seqno write happens only
after the cache flush has completed. But only do that when the caller
actually wants the flush (and not also when we invalidate caches
before starting the next batch).
I've looked through all our ancient scrolls about gen6+ pipe control
workarounds, and this seems to be indeed a legal combination: We're
allowed to set the CS_STALL bit when we flush the render cache (which
we do).
While yelling at this code, also pass back the return value from
intel_emit_post_sync_nonzero_flush properly.
v2: Instead of emitting more pipe controls, set the CS_STALL bit on
the write flush as suggested by Chris Wilson. It seems to work, too.
Cc: Eric Anholt <eric@anholt.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51436
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51429
Tested-by: Lu Hua <huax.lu@intel.com>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel writes:
New -next pull request. Highlights:
- Remaining vlv patches from Jesse et al.
- Some hw workarounds from Jesse
- hw context support from Ben
- full uncore sharing on ivb
- prep work to move the gtt code from intel-gtt.c to drm/i915 for gen6+
- some backlight code improvements
- leftovers for the timeout ioctl (we've forgotten the getparam)
- ibx transcoder workarounds
- some smaller fixlets and improvements
- the new version of the "dont rely on HPD exclusively for VGA" patch
Wrt regressions QA reported quite a few this time around.
- The piglit/kernel-test fallout all has patches that are just awaiting
review and merging into the next -next cycle.
- Which just leaves a bunch of bugs about new modelines that don't work.
It looks like these are all due to the new 16:9/16:10 modes in 3.5
(yeah, only in this manual testing cycle did the git branch used by QA
contain a backmerge of mainline with these patches). Although I haven't
yet confirmed this by letting our QA test the revert of that series.
- Wrt bugs in general I'm trying to fight down some of our long-standing
backlight issues (not regressions), but this seems to be a game of
"you move, you lose" ... :("
Dropped merge bits since this had an -rc4 merge in it to fix some ugly
conflicts.
This reverts commit f82cfb6bcd.
This breaks the backlight controls on my IVB asus zenbook with an eDP
panel.
I guess the right fix would be to read this bit and use either the pch
or the cpu register to frob the backlight values. But that is stuff
for -next.
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If we ever hit the default case in the switch statement we'll return
from the function without freeing the memory we just allocated to
'intel_plane' (but that has not been used).
This patch gets rid of the leak by freeing the memory just before we
return.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We shouldn't hit this path anyway, but make it use the IVB sprite format
definition to avoid confusion.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These are unintuitive. These are type bool and return -1 casted to true
on failure. Let's just make it return an int. The callers don't care,
but let's change this as a cleanup.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is the quick&dirty way Dave Airlie suggested to workaround the
midlayer drm agp brain-damange. Note that i915_probe is only called
when the driver has ksm enabled, so no need to check for that.
We also need to move the intel_agp_enabled check at the right place.
Note that the only thing this does is enforce the correct module load
order (by using a symbol from intel-agp.ko) to ensure that the fake
agp driver is ready before the drm core tries to set up the agp stuff.
v2: Add a comment to explain why gen3 needs all this legacy fake agp
stuff - we've shipped an XvMC library with a kms-enabled ddx that
requires it (but only on gen3).
v3: Make it clear that this is only a gen3 issue in the comment.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This single leftover use is due to a patch that went into 3.5 through
-fixes. With the fake agp stuff on demise, at least for gen6+ we can't
use this any more.
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The enable functions grabbed dev->struct_mutex themselves, whereas
the disable functions expected dev->struct_mutex to be held by the
caller. Move the locking out to the (currently only) callsite of
intel_enable_gt_powersave to make this more consistent.
Originally this was prep work for future patches, but I've chased down
a totally wrong alley. Still, I think this is a sensible
clarification.
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... instead of calling each one for each generation indiviudally.
Notice that we've already managed to be inconsistent, the resume path
is missing an IS_VLV check. As a nice benefit we can mark all the
platform specific enable/disable functions as static and hide them in
intel_pm.c
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I want to merge the "no more fake agp on gen6+" patches into
drm-intel-next (well, the last pieces). But a patch in 3.5-rc4 also
adds a new use of dev->agp. Hence the backmarge to sort this out, for
otherwise drm-intel-next merged into Linus' tree would conflict in the
relevant code, things would compile but nicely OOPS at driver load :(
Conflicts in this merge are just simple cases of "both branches
changed/added lines at the same place". The only tricky part is to
keep the order correct wrt the unwind code in case of errors in
intel_ringbuffer.c (and the MI_DISPLAY_FLIP #defines in i915_reg.h
together, obviously).
Conflicts:
drivers/gpu/drm/i915/i915_reg.h
drivers/gpu/drm/i915/intel_ringbuffer.c
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch fixes the problem on some HP desktop machines with eDP
which give blank screens after S3 resume.
It turned out that BLC_PWM_CPU_CTL must be written after
BLC_PWM_CPU_CTL2. Otherwise it doesn't take effect on these
SNB machines.
Tested with 3.5-rc3 kernel.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49233
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
After banging my head against this for the past few months, I still
don't see how this could possible race under the premise that once an
irq bit is masked in PM_IMR and reset in PM_IIR it won't show up again
until we unmask it in PM_IMR.
Still, we have reports of this being seen in the wild. Now Bspec has
this little bit of lovely language in the PMIIR register:
Public SNB Docs, Vol3Part2, 2.5.14 "PMIIR":
"For each bit, the IIR can store a second pending interrupt if two or
more of the same interrupt conditions occur before the first condition
is cleared. Upon clearing the interrupt, the IIR bit will momentarily
go low, then return high to indicate there is another interrupt
pending."
Now if we presume that PMIMR only prevent new interrupts from being
queued, we could easily end up masking an interrupt and clearing it,
but the 2nd pending interrupt setting the bit in PMIIR right away
again. Which leads, the next time the irq handler runs, to hitting the
WARN.
Also, no bad side effects of this have ever been reported. And we've
tracked down our issues with the gpu turbo getting stuck to bogus
interrupt generation limits in th RPLIMIT register.
So let's just rip out this WARN as bogus and call it a day. The only
shallow thing here is that this 2-deep irq queue in the hw makes you
wonder how racy the windows irq handler is ...
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42907
Cc: stable@vger.kernel.org
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With the code in place, we can bind the driver, should make bisect possible.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Enable the on-chip messaging between the display engine and the GT.
v2: use bit definitions for DPFLIPSTAT reg
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
And restructure the IRQ handling a little. We can use pipestat for most
things, and make sure we don't affect pipe events when enabling and
disabling vblank interupts.
We can leave vblank interrupts masked but enabled so we're not dependent
on the first client to toggle the disable timer. We can also mask all
render based interrupts, since the ring code will handle unmasking them
for us.
v2: roll in vblank masking, remove unneeded variable (Daniel)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since the offsets have all moved around.
v2: switch IS_DISPLAYREG and IS_VALLEYVIEW checks around since the latter is
cheaper (Daniel)
bail out early in IS_DISPLAYREG if the reg is in the new range (Daniel)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Fixup if cascading fail that broke HAS_FORCEWAKE machines.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter writes:
rc2 is out the door so I've figured I'll annoy you with the first -next
pull request for 3.6 already. Highlights:
- new wait_rendring_timeout interface (Ben)
- l3 cache remapping and error uevent support (Ben)
- even more infoframes work from Paulo
- gen4 hotplug rework from Chris
- prep work to make Laurent Pincharts original mode constification for
connector->mode_fixup possible
QA reported a few new bugs this time around, but no regressions afact. For
3.5 the only thing I'm aware of is the edp vdd dmesg spam Linus originally
reported - it looks like that might have been introduced in 3.5. But
somehow my brain is routinely offline when I work on that issue, so things
seem to take forever (and atm I'm at patch v4 for that little problem).
* tag 'drm-intel-next-2012-06-04' of git://people.freedesktop.org/~danvet/drm-intel: (39 commits)
drm/i915: add min freq control to debugfs
drm/i915: don't chnage the original mode in dp_mode_fixup
drm/i915: adjusted_mode->clock in the dp mode_fixup
drm/i915: compute the target_clock for edp directly
drm/i915: extract object active state flushing code
drm/i915: clarify IBX dp workaround
drm/i915: simplify sysfs setup code
drm/i915: initialize the parity work only once
drm/i915: ivybridge_handle_parity_error should be static
drm/i915: l3 parity sysfs interface
drm/i915: remap l3 on hw init
drm/i915: enable parity error interrupts
drm/i915: Dynamic Parity Detection handling
drm/i915: s/mdelay/msleep/ in the sdvo detect function
drm/i915: reuse the sdvo tv clock adjustment in ilk mode_set
drm/i915: there's no cxsr on ilk
drm/i915: add some barriers when changing DIPs
drm/i915: remove comment about HSW HDMI DIPs
drm/i915: don't set SDVO_BORDER_ENABLE when we're HDMI
drm/i915: don't write 0 to DIP control at HDMI init
...
ValleyView is similar to IbexPeak here, but with different register
offsets.
v2: use SDVOB instead ov VLV_HDMIB (Daniel)
drop unnecessary eDP check in DP_C init (Daniel)
eDP support will be coming later from Shobit.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Might be able to merge this back in at some point, but we're seeing bugs
with ADPA based detection, so keep it separate for now with explicit
hotplug trigger usage.
v2: drop superfluous debug message
v3: comment forced detection, need to debug (Eugeni)
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
VLV supports two dp panels, there are two set of panel power sequence
registers which needed to be programmed based on the configured
pipe. This patch add supports for the same
Acked-by: Acked-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Beeresh G <beeresh.g@intel.com>
Reviewed-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Reviewed-by: Jesse Barnes <jesse.barnes@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Drop the lone hunk and only keep the register definitions - I
loathe incomplete bandaids. Also add a comment that this is for vlv.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add some VLV limit structures and update the PLL code.
v2: resolve conflicts, Vijay to re-post with PLL valid checks and fixed limits
v3: re-add dpio write function
v4: squash in Vijay's fixes for the PLL limits and clean up the m/n finder
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is just the minimal patch to disable all this code so that we can
do decent amounts of QA before we rip it all out.
The complicating thing is that we need to flush the gpu caches after
the batchbuffer is emitted. Which is past the point of no return where
execbuffer can't fail any more (otherwise we risk submitting the same
batch multiple times).
Hence we need to add a flag to track whether any caches associated
with that ring are dirty. And emit the flush in add_request if that's
the case.
Note that this has a quite a few behaviour changes:
- Caches get flushed/invalidated unconditionally.
- Invalidation now happens after potential inter-ring sync.
I've bantered around a bit with Chris on irc whether this fixes
anything, and it might or might not. The only thing clear is that with
these changes it's much easier to reason about correctness.
Also rip out a lone get_next_request_seqno in the execbuffer
retire_commands function. I've dug around and I couldn't figure out
why that is still there, with the outstanding lazy request stuff it
shouldn't be necessary.
v2: Chris Wilson complained that I also invalidate the read caches
when flushing after a batchbuffer. Now optimized.
v3: Added some comments to explain the new flushing behaviour.
Cc: Eric Anholt <eric@anholt.net>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It seems to blow up my ilk in all kinds of strange ways. And now that
we're no longer resetting the entire modeset state, it shouldn't be
necessary any longer.
This essentially reverts
commit f817586ceb
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Apr 10 15:50:11 2012 +0200
drm/i915: re-init modeset hw state after gpu reset
safe for the introduction of modeset_init_hw, that one is nice to
prevent code duplication between driver load and resume.
v2: Add a comment to the code to warn future travellers of the dragon
dungeon ahead, suggested by Chris Wilson.
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The idr code already passes us the pointer associated with that id, so
no need to look it up again. Also, we'll kill the idr right away, so
there's no issue with leaving these dangling pointers behind - the
current code does the same.
v2: Also drop the file argument, spotted by Ben Widawsky.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is our customary "no such object" errno, not -EINVAL.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It doesn't hurt and it at least prevents us from OOPSing left and
right at quite a few places. This also allows us to simplify the code
a bit by folding the only line of context_open into the callsite.
We obviuosly also need to run the cleanup code unconditionally, too.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
commit 8e96d9c4d9
Author: Ben Widawsky <ben@bwidawsk.net>
Date: Mon Jun 4 14:42:56 2012 -0700
drm/i915: reset the GPU on context fini
broke module unload because it reset the gpu before we've stopped
touching it. Later on in the unload sequence the ringbuffer code
complained that the gpu would idle properly (because intel_gpu_reset
only resets the hw and not our sw state).
v2: Reorder things so that we reset the gpu _before_ we release the
backing storage of the default context.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51183
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The RCBP workaround still applies on these chips, and we need VDS as well.
v2: remove MB boot fetch that snuck in (Daniel)
add workaround tags to comments for easier internal tracking (Daniel)
v3: only apply RCPB and VDS on SNB and VLV, IVB doesn't need them (Eugeni)
References: https://bugs.freedesktop.org/show_bug.cgi?id=50251
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I've added a bit of logic such that running the hangman test on chips
without any hw reset support at all doesn't wedge the gpu because the
reset failed. This relied on checking for non-null stop_rings.
Unfortunately I've botched a rebase somewhere and stop_rings is still
cleared at the old place before the reset code.
Fix this up so that running the i-g-t tests on gen2/3 doesn't result
in a wedged gpu.
v2: Actually remove the lines instead of adding them twice ... my git
license should be revoked immediately.
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I'm seeing about a 5% FPS improvement across various benchmarks on my
IVB i3. Rumor has it that the higher end parts show even more benefit.
This derives from a patch originally given to me by Bernard. The docs
are confusing about the definition names (ie. medium really seems like
max), but it would seem it gives more cache to the GT at the expense of
uncore. This configuration makes the split most in favor of the GT. I've
not tried the other IDICOS values.
Cc: "Kilarski, Bernard R" <bernard.r.kilarski@intel.com>
Acked-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This got dropped as a result of the last round of comments. I didn't
test it on unsupported HW (which this is likely the case).
Note that this prevents hw context from blowing up on any pre-gen6 hw.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51142
[danvet: Added note and buglink.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Somehow this went unnoticed in the past reviews, but the condition would
never timeout properly.
This was initially introduced in the v2 of original SBI enabling patch.
Highly embarrassing.
Note that we now actually time out for the read, which resulted in gcc
complaining that we can now return unitialized garbage if that
happens. There's not much we can do here because there's not much
point in thread -EIO all the way down through these functions. Hence
simply shut up the compiler.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
[danvet: Added note and squashed uninitialized value shut-up into this
patch.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
They aren't going anywhere, and probing on DDC can cause the panel to
blank briefly, so read them up front and cache them for later queries.
v2: fix potential NULL derefs in intel_dp_get_edid_modes and
intel_dp_get_edid (Jani)
copy full EDID length, including extension blocks (Takashi)
free EDID on teardown (Takashi)
v3: malloc a new EDID buffer that's big enough for the memcpy (Chris)
v4: change handling of NULL EDIDs, just preserve the NULL behavior
across detects and mode list fetches rather than trying to re-fetch
the EDID (Chris)
v5: be glad that Chris is around to remind me to hit C-x C-s before
committing.
References: https://bugs.freedesktop.org/show_bug.cgi?id=46856
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This reverts commit 092945e11c.
This commit prevents a DP screen from properly training the link.
Oddly enough it works, once the machine has been warm-booted with an
older kernel.
According to DP docs this _should_ have been the right precharge time.
Also, the commit that originally introduces this was just general snb
DP enabling and didn't mention any specific reason for this special
value. Whatever, trust the reporter that this makes things worse and
let's just revert it.
v2: Less spelling fail.
Cc: Adam Jackson <ajax@redhat.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reported-by: "Wouter M. Koolen" <W.M.Koolen-Wijkstra@cwi.nl>
Buglink: https://lkml.org/lkml/2012/6/14/301
Cc: stable@vger.kernel.org (only for 3.4)
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This prevents the HDMI detect functions from poking at an eDP
connected panel, which can lead to trouble.
[danvet: Note that we have some other reports of DP vs. HDMI fighting,
but the general case is a much bigger fish to fry.]
References: https://bugs.freedesktop.org/show_bug.cgi?id=42278
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
VGA hotplug detection "works" by measuring the resistance across
certain pins. A lot of kvm switches fumble this and wire up cheap
resistors with the wrong resistance or don't bother at all.
To accomodate these, also try to detect a connected monitor by trying
to grab the edid. Contrary to !HAS_HOTPLUG platforms we don't bother
with an actual load-detection cycle when the output is life - that
would be actual work to implement because things moved around. This is
the big difference to Chris Wilson's original approach:
commit 9e612a008f
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu May 31 13:08:53 2012 +0100
drm/i915/crt: Do not rely upon the HPD presence pin
This blew up on Linus' machine because it errornously detected a vga
screen (without and edid and hence only the default modes), leading to
it's prompt removal:
commit 8f53369b75
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Fri Jun 8 14:53:06 2012 -0700
Revert "drm/i915/crt: Do not rely upon the HPD presence pin"
Some digging around in Bspec shows the reason why load detect doesn't work on
newer chips - the legacy VGA load detect bit isn't wired up any longer:
Public Snb Bspec, Vol3 Part1, 1.1.1 ST00 Input Status 0, bit4:
"RGB Comparator / Sense. This bit is here for compatibility and will
always return one. Monitor detection must be done be done through the
programming of registers in the MMIO space.
0 = Below threshold
1 = Above threshold"
v2: Add a comment in the code that load detect on hotplug capable
machines is broken and pimp the commit message with a quote of Bspec
to show why.
Reported-and-tested-by: Matthieu LAVIE <boiteamadmax@hotmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50501
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use the rsvd1 field in execbuf2 to specify the context ID associated
with the workload. This will allow the driver to do the proper context
switch when/if needed.
v2: Add checks for context switches on rings not supporting contexts.
Before the code would silently ignore such requests.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Add the interfaces to allow user space to create and destroy contexts.
Contexts are destroyed automatically if the file descriptor for the dri
device is closed.
Following convention as usual here causes checkpatch warnings.
v2: with is_initialized, no longer need to init at create
drop the context switch on create (daniel)
v3: Use interruptible lock (Chris)
return -ENODEV in !GEM case (Chris)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
