aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm
Commit message (Collapse)AuthorAge
...
| | * | drm/i915: prefer wide & slow to fast & narrow in DP configsJesse Barnes2012-07-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | High frequency link configurations have the potential to cause trouble with long and/or cheap cables, so prefer slow and wide configurations instead. This patch has the potential to cause trouble for eDP configurations that lie about available lanes, so if we run into that we can make it conditional on eDP. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45801 Tested-by: peter@colberg.org Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: fix up ilk rc6 disabling confusionDaniel Vetter2012-07-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While creating the new enable/disable_gt_powersave functions in commit 8090c6b9daa04dda649ac0a2209601042abfb0a4 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sun Jun 24 16:42:32 2012 +0200 drm/i915: wrap up gt powersave enabling functions I've botched up the handling of ironlake_disable_rc6. Fix this up by calling it at the right place. Note though that ironlake_disable_rc6 does a bit more than just disabling rc6 - it also tears down all the allocated context objects. Hence we need to move intel_teardown_rc6 out and directly call it from intel_modeset_cleanup. Also properly mark ironlake_enable_rc6 as static and kill the un-used declaration in i915_drv.h. Note: In review a question popped out why disable_rc6 also tears down the backing object and why we should move that out - it's simply for consistency with gen6+ rps code, which does it that way. Cc: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: move force wake support into intel_pmEugeni Dodonov2012-07-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit moves force wake support routines into intel_pm modules, and exports the gen6_gt_check_fifodbg routine (used in I915_READ). Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Acked-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: enable RC6 workaround on HaswellEugeni Dodonov2012-07-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For Haswell, on some of the early hardware revisions, it is possible to run into issues when RC6 state is enabled and when pipes change state. v2: add comment saying that this is for early revisions only. v3: beautify as suggested by Daniel Vetter. Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Acked-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: introduce haswell_init_clock_gatingEugeni Dodonov2012-07-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is based on Ivy Bridge clock gating for now, but is subject to changes in the future. Note: Compared to the ivb clock gating this drops the the IDICOS medium uncore sharing tuned in commit 208482232de3590cee4757dfabe5d8cee8c6e626 Author: Ben Widawsky <ben@bwidawsk.net> Date: Fri May 4 18:58:59 2012 -0700 drm/i915: set IDICOS to medium uncore resources Eugeni wants to benchmark the effect of this first. Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> [danvet: added note] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: disable RC6 when disabling rpsEugeni Dodonov2012-07-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We weren't disabling RC6 bits when bringing down RPS. Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: enable RC6 by default on HaswellEugeni Dodonov2012-07-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It should be working so let's turn it on by default and catch any possible issues faster. Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: slightly improve gt enable/disable routinesEugeni Dodonov2012-07-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Just a cosmetic change to simplify the if statement. Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: add RPS configuration for HaswellEugeni Dodonov2012-07-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most of the RPS and RC6 enabling functionality is similar to what we had on Gen6/Gen7, so we preserve most of the registers. Note that Haswell only has RC6, so account for that as well. As suggested by Daniel Vetter, to reduce the amount of changes in the patch, we still write the RC6p/RC6pp thresholds, but those are ignored on Haswell. Note: Some discussion about the nature of the new tuning constants popped up in review - the answer is that we don't know why they've changed, but the guide from VPG with the magic numbers simply has different values now. v2: Squash fix for ?: vs | operation precende bug into this patch. Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Added note to commit message. Squashed fix.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: support Haswell force wakingEugeni Dodonov2012-07-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a different ACK register for force wake on Haswell, so account for that. Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: Implement w/a for sporadic read failures on waking from rc6Chris Wilson2012-07-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As a w/a to prevent reads sporadically returning 0, we need to wait for the GT thread to return to TC0 before proceeding to read the registers. v2: adapt for Haswell changes (Eugeni). v3: use wait_for_atomic_us for thread status polling. v3: *really* use wait_for_atomic for polling. References: https://bugs.freedesktop.org/show_bug.cgi?id=50243 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Acked-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: Group the GT routines together in both code and vtableChris Wilson2012-07-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tidy up the routines for interacting with the GT (in particular the forcewake dance) which are scattered throughout the code in a single structure. v2: use wait_for_atomic for polling. v3: *really* use wait_for_atomic for polling. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: linuxify create_hw_context()Ben Widawsky2012-06-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Daniel complained about this on initial review, but he graciously moved the patches forward. As promised, I am delivering the desired cleanup now. Hopefully I didn't screw the trivial patch up ;-) Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: fix PIPE_WM_LINETIME definitionPaulo Zanoni2012-06-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Looks like a copy/paste error. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: "Flush Me Harder" required on gen6+Daniel Vetter2012-06-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The prep to remove the flushing list in commit cc889e0f6ce6a63c62db17d702ecfed86d58083f 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>
| | * | drm/i915/sprite: Fix mem leak in intel_plane_init()Jesper Juhl2012-06-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * | drm/i915: correct IVB default sprite formatJesse Barnes2012-06-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * | drm/i915: mask tiled bit when updating IVB spritesJesse Barnes2012-06-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Or going from tiled to untiled may break. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: disable drm agp support for !gen3 with kms enabledDaniel Vetter2012-06-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * | drm/i915: don't use dev->agpDaniel Vetter2012-06-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * | drm/i915: make enable/disable_gt_powersave locking consistentDaniel Vetter2012-06-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * | drm/i915: wrap up gt powersave enabling functionsDaniel Vetter2012-06-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... 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>
| * | | drm/radeon: move r100_enable_bm to a more logic placeAlex Deucher2012-06-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It was stuck right in the middle of the gart functions. Move next to the bm_disable function and where it is used. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | | drm/radeon: clean up CS functions in r100.cAlex Deucher2012-06-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consolidate the CS functions to one section of the file. Previously they were spread all around. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | | Merge tag 'drm-intel-next-2012-06-21-merged' of ↵Dave Airlie2012-06-28
| |\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-core-next 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.
| | * | Merge tag 'v3.5-rc4' into drm-intel-next-queuedDaniel Vetter2012-06-25
| | |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * | | drm/i915: no lvds quirk for Zotac ZDBOX SD ID12/ID13Sjoerd Simons2012-06-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This box claims to have an LVDS interface but doesn't actually have one. Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | drm/i915: bind driver to ValleyView chipsetsJesse Barnes2012-06-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * | | drm/i915: enable display messages to GT on ValleyViewJesse Barnes2012-06-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * | | drm/i915: support page flipping on ValleyViewJesse Barnes2012-06-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * | | drm/i915: don't enable PPGTT on VLV yetJesse Barnes2012-06-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Needs some more work and testing. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | drm/i915: VLV VGA port only handles on & off, like PCH VGAJesse Barnes2012-06-20
| | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | drm/i915: access VLV regs through read/write switchJesse Barnes2012-06-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * | | drm/i915: add HDMI and DP port enumeration on ValleyViewJesse Barnes2012-06-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * | | drm/i915: add ValleyView specific CRT detect functionJesse Barnes2012-06-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * | | drm/i915: Enable DP panel power sequencing for ValleyViewShobhit Kumar2012-06-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * | | drm/i915: ValleyView mode setting limits and PLL functionsJesse Barnes2012-06-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * | | drm/i915: disable flushing_list/gpu_write_listDaniel Vetter2012-06-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * | | drm/i915: don't call modeset_init_hw in i915_resetDaniel Vetter2012-06-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 f817586cebf1b946d1f327f9a596048efd6b64e9 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>
| | * | | drm/i915: return -ENODEV if hw context are not supportedDaniel Vetter2012-06-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Otherwise userspace has no way to figure this out. Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | drm/i915: simplify context_idr_cleanupDaniel Vetter2012-06-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * | | drm/i915/context: shut up compilerDaniel Vetter2012-06-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It found some unused variables. Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | drm/i915: return -ENOENT if the context doesn't existDaniel Vetter2012-06-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * | | drm/i915: initialize the context idr unconditionallyDaniel Vetter2012-06-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * | | drm/i915: fix module unload after context mergeDaniel Vetter2012-06-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 8e96d9c4d9843f00ebeb4a9b33596d96602ea101 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>
| | * | | drm/i915: add L3 bank clock gating disable on VLVJesse Barnes2012-06-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prevents a possible hang: WaDisableL3Bank2xClockGate. v2: only apply to VLV, IVB doesn't need this anymore References: https://bugs.freedesktop.org/show_bug.cgi?id=50245 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>
| | * | | drm/i915: add TDL unit clock gating disable for VLVJesse Barnes2012-06-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Another required workaround for a potential hang: WaDisableTDLUnitClockGating. v2: only apply this to VLV, IVB doesn't need it anymore (Eugeni) References: https://bugs.freedesktop.org/show_bug.cgi?id=50245 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>
| | * | | drm/i915: load boot context at driver init timeJesse Barnes2012-06-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to the bspec for MBCTL: Driver must set bit in the following scenarios: - to realod teh h/w boot context every time it gets loaded through OS - after an FLR clears the register (BIOS won't run afterwards) References: https://bugs.freedesktop.org/show_bug.cgi?id=50237 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>
| | * | | drm/i915: disable RCBP and VDS unit clock gating on SNB and VLVJesse Barnes2012-06-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * | | drm/i915: fixup hangman rebase goof-upDaniel Vetter2012-06-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>