aboutsummaryrefslogtreecommitdiffstats
path: root/drivers
Commit message (Collapse)AuthorAge
* drm/i915: reset the GPU on context finiBen Widawsky2012-06-14
| | | | | | | It's the only way we know how to make the GPU actually forget about the default context. Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
* drm/i915/context: switch contexts with execbuf2Ben Widawsky2012-06-14
| | | | | | | | | | | 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>
* drm/i915/context: create & destroy ioctlsBen Widawsky2012-06-14
| | | | | | | | | | | | | | | | 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>
* drm/i915: switch to default context on idleBen Widawsky2012-06-14
| | | | | | | | | | | | | To keep things as sane as possible, switch to the default context before idling. This should help free context objects, as well as put things in a more well defined state before suspending. v2: remove seqno from context switch call (daniel) return error on failed context switch instead of WARN+continue (daniel) v3: move idling to i915_gpu idle (from i915_gem_idle) (Chris) Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
* drm/i915: add ccid to error stateBen Widawsky2012-06-14
| | | | Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
* drm/i915: use the default contextBen Widawsky2012-06-14
| | | | | | | | | | With the code to do HW context switches in place have the driver load the default context for the render ring when the driver loads. The default context will be an ever present context that is available to switch to at any time for the given ring. Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
* drm/i915: possibly invalidate TLB before context switchBen Widawsky2012-06-14
| | | | | | | | | | | | | | | | | | | From http://intellinuxgraphics.org/documentation/SNB/IHD_OS_Vol1_Part3.pdf [DevSNB] If Flush TLB invalidation Mode is enabled it's the driver's responsibility to invalidate the TLBs at least once after the previous context switch after any GTT mappings changed (including new GTT entries). This can be done by a pipelined PIPE_CONTROL with TLB inv bit set immediately before MI_SET_CONTEXT. On GEN7 the invalidation mode is explicitly set, but this appears to be lacking for GEN6. Since I don't know the history on this, I've decided to dynamically read the value at ring init time, and use that value throughout. v2: better comment (daniel) Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
* drm/i915: PIPE_CONTROL_TLB_INVALIDATEBen Widawsky2012-06-14
| | | | | | | | | | | This has showed up in several other patches. It's required for the next context workaround. I tested this one on its own and saw no differences in basic tests (performance or otherwise). This patch is relatively likely to cause regressions, hence why it's split out. Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
* drm/i915: Ivybridge MI_ARB_ON_OFF context w/aBen Widawsky2012-06-14
| | | | | | | | | | | | | The workaround itself applies to gen7 only (according to the docs) and as Eric Anholt points out shouldn't be required since we don't use HW scheduling features, and therefore arbitration. Though since it is a small, and simple addition, and we don't really understand the issue, just do it. FWIW, I eventually want to play with some of the arbitration stuff, and I'd hate to forget about this. Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
* drm/i915: ensure context objects are bound to the global gttDaniel Vetter2012-06-14
| | | | | | | This way round we don't introduce and ugly layering violations and use the interface as I planned to use it. Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: context switch implementationBen Widawsky2012-06-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implement the context switch code as well as the interfaces to do the context switch. This patch also doesn't match 1:1 with the RFC patches. The main difference is that from Daniel's responses the last context object is now stored instead of the last context. This aids in allows us to free the context data structure, and context object independently. There is room for optimization: this code will pin the context object until the next context is active. The optimal way to do it is to actually pin the object, move it to the active list, do the context switch, and then unpin it. This allows the eviction code to actually evict the context object if needed. The context switch code is missing workarounds, they will be implemented in future patches. v2: actually do obj->dirty=1 in switch (daniel) Modified comment around above Remove flags to context switch (daniel) Move mi_set_context code to i915_gem_context.c (daniel) Remove seqno , use lazy request instead (daniel) v3: use i915_gem_request_next_seqno instead of outstanding_lazy_request (Daniel) remove id's from trace events (Daniel) Put the context BO in the instruction domain (Daniel) Don't unref the BO is context switch fails (Chris) Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
* drm/i915: context basic create & destroyBen Widawsky2012-06-14
| | | | | | | | | | | | | | | | | | | | | | | Invent an abstraction for a hw context which is passed around through the core functions. The main bit a hw context holds is the buffer object which backs the context. The rest of the members are just helper functions. Specifically the ring member, which could likely go away if we decide to never implement whatever other hw context support exists. Of note here is the introduction of the 64k alignment constraint for the BO. If contexts become heavily used, we should consider tweaking this down to 4k. Until the contexts are merged and tested a bit though, I think 64k is a nice start (based on docs). Since we don't yet switch contexts, there is really not much complexity here. Creation/destruction works pretty much as one would expect. An idr is used to generate the context id numbers which are unique per file descriptor. v2: add DRM_DEBUG_DRIVERS to distinguish ENOMEM failures (ben) convert a BUG_ON to WARN_ON, default destruction is still fatal (ben) Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
* drm/i915: preliminary context supportBen Widawsky2012-06-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Very basic code for context setup/destruction in the driver. Adds the file i915_gem_context.c This file implements HW context support. On gen5+ a HW context consists of an opaque GPU object which is referenced at times of context saves and restores. With RC6 enabled, the context is also referenced as the GPU enters and exists from RC6 (GPU has it's own internal power context, except on gen5). Though something like a context does exist for the media ring, the code only supports contexts for the render ring. In software, there is a distinction between contexts created by the user, and the default HW context. The default HW context is used by GPU clients that do not request setup of their own hardware context. The default context's state is never restored to help prevent programming errors. This would happen if a client ran and piggy-backed off another clients GPU state. The default context only exists to give the GPU some offset to load as the current to invoke a save of the context we actually care about. In fact, the code could likely be constructed, albeit in a more complicated fashion, to never use the default context, though that limits the driver's ability to swap out, and/or destroy other contexts. All other contexts are created as a request by the GPU client. These contexts store GPU state, and thus allow GPU clients to not re-emit state (and potentially query certain state) at any time. The kernel driver makes certain that the appropriate commands are inserted. There are 4 entry points into the contexts, init, fini, open, close. The names are self-explanatory except that init can be called during reset, and also during pm thaw/resume. As we expect our context to be preserved across these events, we do not reinitialize in this case. As Adam Jackson pointed out, The cutoff of 1MB where a HW context is considered too big is arbitrary. The reason for this is even though context sizes are increasing with every generation, they have yet to eclipse even 32k. If we somehow read back way more than that, it probably means BIOS has done something strange, or we're running on a platform that wasn't designed for this. v2: rename load/unload to init/fini (daniel) remove ILK support for get_size() (indirectly daniel) add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel) added comments (Ben) Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
* drm/i915: CXT_SIZE register offsets addedBen Widawsky2012-06-14
| | | | | | | | | | | | | | | The GPUs can have different default context layouts, and the sizes could vary based on platform or BIOS. In order to back the context object with a properly sized BO, we must read this register in order to find out a sufficient size. Thankfully (sarcarm!), the register moves and changes meanings throughout generations. CTX and CXT differences are intentional as that is how it is in the documentation (prior to GEN6 it was CXT). Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
* drm/i915: ignore pipe select bit when checking for LVDS register initializationSeth Forshee2012-06-13
| | | | | | | | | | The Lenovo Thinkpad T410 has the LVDS_PIPEB_SELECT bit set in the LVDS register when booted with the lid closed, even though the LVDS hasn't really been initialized. Ignore this bit so that the VBT value will be used instead. Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Switch off FBC when disabling the primary plane when obscuredChris Wilson2012-06-13
| | | | | | | | | | | | | | | | As we switch on/off the primary plane if it is completely obscured by an overlapping video sprite, we also nee to make sure that we update the FBC configuration at the same time. v2: Not all crtcs are intel_crtcs, as spotted by Daniel. v3: Boot testing rules. References: https://bugs.freedesktop.org/show_bug.cgi?id=50238 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: kick any firmware framebuffers before claiming the gttDaniel Vetter2012-06-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Especially vesafb likes to map everything as uc- (yikes), and if that mapping hangs around still while we try to map the gtt as wc the kernel will downgrade our request to uc-, resulting in abyssal performance. Unfortunately we can't do this as early as readon does (i.e. as the first thing we do when initializing the hw) because our fb/mmio space region moves around on a per-gen basis. So I've had to move it below the gtt initialization, but that seems to work, too. The important thing is that we do this before we set up the gtt wc mapping. Now an altogether different question is why people compile their kernels with vesafb enabled, but I guess making things just work isn't bad per se ... v2: - s/radeondrmfb/inteldrmfb/ - fix up error handling v3: Kill #ifdef X86, this is Intel after all. Noticed by Ben Widawsky. v4: Jani Nikula complained about the pointless bool primary initialization. v5: Don't oops if we can't allocate, noticed by Chris Wilson. v6: Resolve conflicts with agp rework and fixup whitespace. Reported-and-tested-by: "Kilarski, Bernard R" <bernard.r.kilarski@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: call intel_enable_gttDaniel Vetter2012-06-12
| | | | | | | | When drm/i915 is in control of the gtt, we need to call the enable function at all the relevant places ourselves. Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* agp/intel-gtt: move gart base addres setupDaniel Vetter2012-06-12
| | | | | | | | | We need this thing much earlier, and it doesn't make sense in the hw enabling function intel_enable_gtt - this does not change over a suspend/resume cycle ... Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915 + agp/intel-gtt: prep work for direct setupDaniel Vetter2012-06-12
| | | | | | | | | | | | | | | To be able to directly set up the intel-gtt code from drm/i915 and avoid setting up the fake-agp driver we need to prepare a few things: - pass both the bridge and gpu pci_dev to the probe function and add code to handle the gpu pdev both being present (for drm/i915) and not present (fake agp). - add refcounting to the remove function so that unloading drm/i915 doesn't kill the fake agp driver v2: Fix up the cleanup and refcount, noticed by Jani Nikula. Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* agp/intel-gtt: don't require the agp bridge on setupDaniel Vetter2012-06-12
| | | | | | | | | | | We only need it to fake the agp interface and don't actually use it in the driver anywhere. Hence conditionalize that. This is just a prep patch to eventually disable the fake agp driver on gen6+. Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: stop using dev->agp->baseDaniel Vetter2012-06-12
| | | | | | | | | For that to work we need to export the base address of the gtt mmio window from intel-gtt. Also replace all other uses of dev->agp by values we already have at hand. Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* agp/intel-gtt: remove dead codeDaniel Vetter2012-06-12
| | | | | | | | This is a leftover from the conversion of the i81x fake agp driver over to the new intel-gtt code layoute. Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: allow pipe A for lvds on gen4Daniel Vetter2012-06-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Given the havoc the missing backlight pipe select code might have caused, let's try to re-enabled pipe A support for lvds on gen4 hw. Just to see what all blows up ... Note though that commit 4add75c43f39573edc884d46b7c2b7414f01171a Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sat Dec 4 17:49:46 2010 +0000 drm/i915: Allow LVDS to be on pipe A for Ironlake+ claims that this caused tons of spurious wakeups somehow. More details can be found in the old revert: commit 12e8ba25ef52f19e7a42e61aecb3c1fef83b2a82 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Sep 7 23:39:28 2010 +0100 Revert "drm/i915: Allow LVDS on pipe A on gen4+" Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16307 Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: properly enable the blc controller on the right pipeDaniel Vetter2012-06-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | On gen4+ we have a bitfield to specify from which pipe the backlight controller should take it's clock. For PCH split platforms we've already set these up, but only at initialization time. And without taking into account the 3rd pipe added with ivb. For gen4, we've completely ignored these. Although we do restrict lvds to the 2nd pipe, so this is only a problem on machines where we boot up with the lvds on the first pipe. So restructure the code to enable the backlight on the right pipe at modeset time. v2: For odd reasons panel_enable_backlight gets called twice in a modeset, so we can't WARN_ON in there if the backlight controller is switched on already. v3: backlight enable can also be called through dpms on, so the check in there is legit. Update the comment to reflect that. Tested-By: Kamal Mostafa <kamal@canonical.com> Bugzilla: https://bugs.launchpad.net/bugs/954661 Cc: Carsten Emde <C.Emde@osadl.org> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: clear up backlight #define confusion on gen4+Daniel Vetter2012-06-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | - Regroup definitions for BLC_PWM_CTL so that they're all together and and ordered according to the bitfields. - Add all missing definitions for BLC_PWM_CTL2. - Use the BLM_ (for backlight modulation) prefix consistently. - Note that combination mode (i.e. also taking the legacy backlight control value from pci config space into account) is gen4 only. - Move the new registers for PCH-split machines up, they're an almost match for the gen4 defitions. Prefix the special PCH-only bits with BLM_PCH_. Also add the pipe C select bit for ivb. - Rip out the second pair of PCH polarity definitions - they're only valid on early (pre-production) ilk silicon. - Adapt the existing code to use the new definitions. This has the nice benefit of killing a magic (1 << 30) left behind be Jesse Barnes. No functional changes in this patch. Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: pnv has a backlight polarity control bit, tooDaniel Vetter2012-06-12
| | | | | | | | | | We already correctly ignore bit0 on gen < 4, now we also know why ;-) I've decided that losing that single bit of precision isn't worth the trouble to sprinkle IS_PINEVIEW checks all over the backlight control code - that code is way too fragile imo. Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: ensure HDMI port is disabled inside set_infoframesDaniel Vetter2012-06-12
| | | | | | | | | | | | | | | This function is supposed to be used at mode set time, so prevent against future mistakes by adding a WARN(). Based on a patch by Paulo Zanoni, with the check extracted into a little assert_hdmi_port_disabled helper added to make things self documenting and move the assert stuff out of line. [fixed up spelling goof-up while applying.] Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Add wait render timeout get paramBen Widawsky2012-06-06
| | | | | | Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Inifite timeout for wait ioctlBen Widawsky2012-06-06
| | | | | | | | | | | | | | | | | | | Change the ns_timeout parameter of the wait ioctl to a signed value. Doing this allows the kernel to provide an infinite wait when a timeout of less than 0 is provided. This mimics select/poll. Initially the parameter was meant to match up with the GL spec 1:1, but after being made aware of how much 2^64 - 1 nanoseconds actually is, I do not think anyone will ever notice the loss of 1 bit. The infinite timeout on waiting is similar to the existing i915 userspace interface with the exception that struct_mutex is dropped while doing the wait in this ioctl. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: assert that the IBX port transcoder select w/a is implementedDaniel Vetter2012-06-06
| | | | | | | Let's be a bit more paranoid here. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: implement IBX hdmi transcoder select workaroundDaniel Vetter2012-06-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bspec Vol 3, Part 3, Section 3.8.1.1, bit 30: "[DevIBX] Writing to this bit only takes effect when port is enabled. Due to hardware issue it is required that this bit be cleared when port is disabled. To clear this bit software must temporarily enable this port on transcoder A." Unfortunately the public Bspec misses totally out on the same language for HDMIB. Internal Bspec also mentions that one of the bad side-effects is that DPx can fail to light up on transcoder A if HDMIx is disabled but using transcoder B. I've found this while reviewing Bsepc. We already implement the same workaround for the DP ports. Also replace a magic 1 with PIPE_B I've found while looking through the code. v2: Implement suggestions from Chris Wilson: - add pipe variable to cut down on code noise - write the reg value twice to w/a hw issues (Bspec is unclear on which bit actually require the write twice stuff, but better be paranoid about it) - untangle the if logic Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: add min freq control to debugfsJesse Barnes2012-06-04
| | | | | | | | | | | This makes for easier benchmarking and testing. One can set a fixed frequency by setting min and max to the same value. v2: fix whitespace & comment (Eugeni) Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Eugeni Dodonov <eugeni@dodonov.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: don't chnage the original mode in dp_mode_fixupDaniel Vetter2012-06-04
| | | | | | | | | | | | | | | | | | | | | | We should only frob adjusted_mode. This is in preparation of a massive patch by Laurent Pinchart to make the mode argument const. After the previous two prep patches the only thing left is to clean up things a bit. I've opted to pass in an adjust_mode param to dp_adjust_dithering because that way we can be sure to avoid duplicating this logic between mode_valid and mode_fixup - which was the cause behind a dp link bw calculation bug in the past. Also mark the mode argument of pch_panel_fitting const. v2: Split up the mode->clock => adjusted_mode->clock change, as suggested by Chris Wilson. Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: adjusted_mode->clock in the dp mode_fixupDaniel Vetter2012-06-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... instead of changing mode->clock, which we should leave as-is. After the previous patch we only touch that if it's a panel, and then adjusted mode->clock equals adjusted_mode->clock. Outside of intel_dp.c we only use ajusted_mode->clock in the mode_set functions. Within intel_dp.c we only use it to calculate the dp dithering and link bw parameters, so that's the only thing we need to fix up. As a temporary ugliness (until the cleanup in the next patch) we pass the adjusted_mode into dp_dither for both parameters (because that one still looks at mode->clock). Note that we do overwrite adjusted_mode->clock with the selected dp link clock, but that only happens after we've calculated everything we need based on the dotclock of the adjusted output configuration. Outside of intel_dp.c only intel_display.c uses adjusted_mode->clock, and that stays the same after this patch (still equals the selected dp link clock). intel_display.c also needs the actual dotclock (as target_clock), but that has been fixed up in the previous patch. v2: Adjust the debug message to also use adjusted_mode->clock. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: compute the target_clock for edp directlyDaniel Vetter2012-06-04
| | | | | | | | | | | | ... instead of abusing mode->clock by storing it in there - we shouldn't touch that one at all. This patch is the first prep step to constify the mode argument of the intel_dp_mode_fixup function. The next patch will stop us from modifying mode->clock. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: extract object active state flushing codeDaniel Vetter2012-06-02
| | | | | | | | | | | | | | | | | | | | | | | | Both busy_ioctl and the new wait_ioct need to do the same dance (or at least should). Some slight changes: - busy_ioctl now unconditionally checks for olr. Before emitting a require flush would have prevent the olr check and hence required a second call to the busy ioctl to really emit the request. - the timeout wait now also retires request. Not really required for abi-reasons, but makes a notch more sense imo. I've tested this by pimping the i-g-t test some more and also checking the polling behviour of the wait_rendering_timeout ioctl versus what busy_ioctl returns. v2: Too many people complained about unplug, new color is flush_active. v3: Kill the comment about the unplug moniker. v4: s/un-active/inactive/ Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: clarify IBX dp workaroundDaniel Vetter2012-06-01
| | | | | | | | | | | | | Instead of checking for !CPT, check for IBX to make it clearer that this is a IBX-specific workaround. No functional change because we smash the PPT PCH into the HAS_PCH_CPT check and atm DP isn't enabled on the haswell LPT PCH yet. See Bspec Vol 3, Part 3, Section 4.[3-5].1 about DP[BCD], bit 30 for details of this workaround. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge remote-tracking branch 'airlied/drm-prime-vmap' into drm-intel-next-queuedDaniel Vetter2012-06-01
|\ | | | | | | | | | | | | | | We need the latest dma-buf code from Dave Airlie so that we can pimp the backing storage handling code in drm/i915 with Chris Wilson's unbound tracking and stolen mem backed gem object code. Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * radeon: add radeon prime vmap support.Dave Airlie2012-05-31
| | | | | | | | | | | | This is the same as the nouveau code pretty much. Signed-off-by: Dave Airlie <airlied@redhat.com>
| * nouveau: add vmap support to nouveau prime supportDave Airlie2012-05-31
| | | | | | | | | | | | Tested sharing to udl. Signed-off-by: Dave Airlie <airlied@redhat.com>
| * udl: support vmapping imported dma-bufsDave Airlie2012-05-31
| | | | | | | | | | | | This allows udl to get a vmapping of an imported buffer for scanout. Signed-off-by: Dave Airlie <airlied@redhat.com>
| * i915: add dma-buf vmap support for exporting vmapped bufferDave Airlie2012-05-31
| | | | | | | | | | | | | | This is used to export a vmapping to the udl driver so that i915 and udl can share the udl scanout. Signed-off-by: Dave Airlie <airlied@redhat.com>
| * radeon: add stub dma-buf mmap functionalityDave Airlie2012-05-31
| | | | | | | | | | | | | | This just adds a stub until we have pieces in place to test a correct one. Signed-off-by: Dave Airlie <airlied@redhat.com>
| * nouveau: add stub dma-buf mmap functionality.Dave Airlie2012-05-31
| | | | | | | | | | | | | | This just adds a stub until we have some users in place to test this with. Signed-off-by: Dave Airlie <airlied@redhat.com>
| * i915: add stub dma-buf mmap callback.Dave Airlie2012-05-31
| | | | | | | | | | | | | | This just adds a stub for now, until we have some users in place to test this functionality properly. Signed-off-by: Dave Airlie <airlied@redhat.com>
| * Merge git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-clientLinus Torvalds2012-05-30
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull ceph updates from Sage Weil: "There are some updates and cleanups to the CRUSH placement code, a bug fix with incremental maps, several cleanups and fixes from Josh Durgin in the RBD block device code, a series of cleanups and bug fixes from Alex Elder in the messenger code, and some miscellaneous bounds checking and gfp cleanups/fixes." Fix up trivial conflicts in net/ceph/{messenger.c,osdmap.c} due to the networking people preferring "unsigned int" over just "unsigned". * git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client: (45 commits) libceph: fix pg_temp updates libceph: avoid unregistering osd request when not registered ceph: add auth buf in prepare_write_connect() ceph: rename prepare_connect_authorizer() ceph: return pointer from prepare_connect_authorizer() ceph: use info returned by get_authorizer ceph: have get_authorizer methods return pointers ceph: ensure auth ops are defined before use ceph: messenger: reduce args to create_authorizer ceph: define ceph_auth_handshake type ceph: messenger: check return from get_authorizer ceph: messenger: rework prepare_connect_authorizer() ceph: messenger: check prepare_write_connect() result ceph: don't set WRITE_PENDING too early ceph: drop msgr argument from prepare_write_connect() ceph: messenger: send banner in process_connect() ceph: messenger: reset connection kvec caller libceph: don't reset kvec in prepare_write_banner() ceph: ignore preferred_osd field ceph: fully initialize new layout ...
| | * rbd: rename __rbd_update_snaps to __rbd_refresh_headerJosh Durgin2012-05-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | This function rereads the entire header and handles any changes in it, not just changes in snapshots. Signed-off-by: Josh Durgin <josh.durgin@dreamhost.com> Reviewed-by: Alex Elder <elder@dreamhost.com> Reviewed-by: Yehuda Sadeh <yehuda@hq.newdream.net>
| | * rbd: fix snapshot size typeJosh Durgin2012-05-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Snapshot sizes should be the same type as regular image sizes. This only affects their displayed size in sysfs, not the reported size of an actual block device sizes. Signed-off-by: Josh Durgin <josh.durgin@dreamhost.com> Reviewed-by: Alex Elder <elder@dreamhost.com> Reviewed-by: Yehuda Sadeh <yehuda@hq.newdream.net>
| | * rbd: remove conditional snapid parametersJosh Durgin2012-05-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The snapid parameters passed to rbd_do_op() and rbd_req_sync_op() are now always either a valid snapid or an explicit CEPH_NOSNAP. [elder@dreamhost.com: Rephrased the description] Signed-off-by: Josh Durgin <josh.durgin@dreamhost.com> Reviewed-by: Alex Elder <elder@dreamhost.com> Reviewed-by: Yehuda Sadeh <yehuda@hq.newdream.net>