summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* drm/i915: Move ring_begin to signal()Ben Widawsky2014-05-052-18/+25
| | | | | | | | | | | | | | | | | | | | Add_request has always contained both the semaphore mailbox updates as well as the breadcrumb writes. Since the semaphore signal is the one which actually knows about the number of dwords it needs to emit to the ring, we move the ring_begin to that function. This allows us to remove the hideously shared #define On a related not, gen8 will use a different number of dwords for semaphores, but not for add request. v2: Make number of dwords an explicit part of signalling (via function argument). (Chris) v3: very slight comment change Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Virtualize the ringbuffer signal funcBen Widawsky2014-05-052-21/+32
| | | | | | | | | | | | | | This abstraction again is in preparation for gen8. Gen8 will bring new semantics for doing this operation. While here, make the writes of MI_NOOPs explicit for non-existent rings. This should have been implicit before. NOTE: This is going to be removed in a few patches. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Move semaphore specific ring members to structBen Widawsky2014-05-055-80/+82
| | | | | | | | | | | | | This will be helpful in abstracting some of the code in preparation for gen8 semaphores. v2: Move mbox stuff to a separate struct v3: Rebased over VCS2 work Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1) Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: vlv: init only needed state during early power well enablingImre Deak2014-05-052-4/+11
| | | | | | | | | | | | | | | | | | During the initial power well enabling on the driver init/resume path we can avoid initialzing part of the HW/SW state that will be initialized anyway by the subsequent init/resume code. For some steps like HPD initialization this redundancy is not only an overhead but an actual problem, since they can't be run this early in the overall init sequence. Add a flag marking the init phase and skip reinitialzing state that is not strictly necessary based on that. This is also needed by the upcoming HPD init restructuring by Thierry and Daniel. Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Avoid NULL ctx->obj dereference in debugfs/i915_context_infoChris Wilson2014-05-051-0/+3
| | | | | | | | | | | | | | | | | | | In commit 691e6415c891b8b2b082a120b896b443531c4d45 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Apr 9 09:07:36 2014 +0100 drm/i915: Always use kref tracking for all contexts. we populated fake contexts on all platforms. These were identical to the full hardware context tracking structs, except for the ctx->obj used to store the hardware state. However, there remained one place where we assumed that if a context existed, it would have an object associated with it. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77717 Testcase: igt/drv_suspend/debugfs-reader Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Add intel_get_crtc_scanline()Ville Syrjälä2014-05-052-14/+43
| | | | | | | | | | | | | | | | | | | | | Add a new function intel_get_crtc_scanline() that returns the current scanline counter for the crtc. v2: Rebase after vblank timestamp changes. Use intel_ prefix instead of i915_ as is more customary for display related functions. Include DRM_SCANOUTPOS_INVBL in the return value even w/o adjustments, for a bit of extra consistency. v3: Change the implementation to be based on DSL on all gens, since that's enough for the needs of atomic updates, and it will avoid complicating the scanout position calculations for the vblank timestamps v4: Don't break scanline wraparound for interlaced modes Reviewed-by: Sourab Gupta <sourabgupta@gmail.com> Reviewed-by: Akash Goel <akash.goels@gmail.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Fix scanout position for realVille Syrjälä2014-05-051-79/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Seems I've been a bit dense with regards to the start of vblank vs. the scanline counter / pixel counter. After staring at the pixel counter on gen4 I came to the conclusion that the start of vblank interrupt and scanline counter increment happen at the same time. The scanline counter increment is documented to occur at start of hsync, which means that the start of vblank interrupt must also trigger there. Looking at the pixel counter value when the scanline wraps from vtotal-1 to 0 confirms that, as the pixel counter at that point reads hsync_start. This also clarifies why we see need the +1 adjustment to the scaline counter. The counter actually starts counting from vtotal-1 on the first active line. I also confirmed that the frame start interrupt happens ~1 line after the start of vblank, but the frame start occurs at hblank_start instead. We only use the frame start interrupt on gen2 where the start of vblank interrupt isn't available. The only important thing to note here is that frame start occurs after vblank start, so we don't have to play any additional tricks to fix up the scanline counter. The other thing to note is the fact that the pixel counter on gen3-4 starts counting from the start of horizontal active on the first active line. That means that when we get the start of vblank interrupt, the pixel counter reads (htotal*(vblank_start-1)+hsync_start). Since we consider vblank to start at (htotal*vblank_start) we need to add a constant (htotal-hsync_start) offset to the pixel counter, or else we risk misdetecting whether we're in vblank or not. I talked a bit with Art Runyan about these topics, and he confirmed my findings. And that the same rules should hold for platforms which don't have the pixel counter. That's good since without the pixel counter it's rather difficult to verify the timings to this accuracy. So the conclusion is that we can throw away all the ISR tricks I added, and just increment the scanline counter by one always. Reviewed-by: Sourab Gupta <sourabgupta@gmail.com> Reviewed-by: Akash Goel <akash.goels@gmail.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/bdw: Disable idle DOP clock gatingBen Widawsky2014-05-051-0/+4
| | | | | | | | | | | It seems we need this at least for the current platforms we have, but probably not later. In any event, it should cause too much harm as we do the same thing on several other platforms. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: Brad Volkin <bradley.d.volkin@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/bdw: enable eDRAM.Ben Widawsky2014-05-051-1/+1
| | | | | | | | | | | | | The same register exists for querying and programming eDRAM AKA eLLC. So we can simply use it. For now, use all the same defaults as we had for Haswell, since like Haswell, I have no further details. I do not actually have a part with eDRAM, so I cannot test this. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: Brad Volkin <bradley.d.volkin@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/bdw: Add WT caching abilityBen Widawsky2014-05-052-9/+19
| | | | | | | | | | | | | | | I don't have any insight on what parts can do what. The docs do seem to suggest WT caching works in at least the same manner as it does on Haswell. The addr = 0 is to shut up GCC: drivers/gpu/drm/i915/i915_gem_gtt.c:80:7: warning: 'addr' may be used uninitialized in this function [-Wmaybe-uninitialized] Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: Brad Volkin <bradley.d.volkin@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: bdw: fix RC6 enabled status reporting and disable runtime PMImre Deak2014-05-051-0/+4
| | | | | | | | | | | | On BDW we don't enable RC6 at the moment, but this isn't reflected in the (sanitized) i915.enable_rc6 option. So make enable_rc6 report correctly that RC6 is disabled, which will also effectively disable RPM on BDW (since RPM depends on RC6). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77565 Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Fix assert_plane warning during FDI link trainVille Syrjälä2014-05-051-3/+1
| | | | | | | | | | | | | | | | | | | assert_plane_enabled() is now triggering during FDI link train because we no longer enable planes that early. This problem got introduced in: commit a5c4d7bc187bd13bc11ac06bb4ea3a0d4001aa4d Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Fri Mar 7 18:32:13 2014 +0200 drm/i915: Disable/enable planes as the first/last thing during modeset on ILK+ Just drop the assert since we shouldn't need planes for link training. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [danvet: Squash in fixup for now unused plane local variable, reported by 0-day tester.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Revert "drm/i915: fix build warning on 32-bit (v2)"Jan Moskyto Matejka2014-05-051-1/+1
| | | | | | | | | | | | | | | | This reverts commit 60f2b4af1258c05e6b037af866be81abc24438f7. The same warning has been fixed in e5081a538a565284fec5f30a937d98e460d5e780 and these two commits got merged in 74e99a84de2d0980320612db8015ba606af42114 which caused another warning. Simply, the reverted commit casted the pointer difference to unsigned long and the other commit changed the output type from long to ptrdiff_t. The other commit fixes the original warning the better way so I'm reverting this commit now. Signed-off-by: Jan Moskyto Matejka <mq@suse.cz> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Fix deadlock during driver init on ILKVille Syrjälä2014-05-051-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have a struct_mutex deadlock during driver init on ILK [ 54.320273] ============================================= [ 54.320371] [ INFO: possible recursive locking detected ] [ 54.320471] 3.15.0-rc2-flip_race+ #2 Not tainted [ 54.320567] --------------------------------------------- [ 54.320665] modprobe/2178 is trying to acquire lock: [ 54.320762] (&dev->struct_mutex){+.+.+.}, at: [<ffffffffa0568b05>] intel_enable_gt_powersave+0xa5/0x9d0 [i915] [ 54.321111] [ 54.321111] but task is already holding lock: [ 54.321250] (&dev->struct_mutex){+.+.+.}, at: [<ffffffffa05b4c2e>] intel_modeset_init_hw+0x3e/0x60 [i915] [ 54.321583] [ 54.321583] other info that might help us debug this: [ 54.321724] Possible unsafe locking scenario: [ 54.321724] [ 54.321863] CPU0 [ 54.321954] ---- [ 54.322046] lock(&dev->struct_mutex); [ 54.322221] lock(&dev->struct_mutex); [ 54.322397] [ 54.322397] *** DEADLOCK *** [ 54.322397] [ 54.322638] May be due to missing lock nesting notation [ 54.322638] [ 54.322781] 4 locks held by modprobe/2178: [ 54.322875] #0: (&dev->mutex){......}, at: [<ffffffff813592eb>] __driver_attach+0x5b/0xb0 [ 54.323230] #1: (&dev->mutex){......}, at: [<ffffffff813592f9>] __driver_attach+0x69/0xb0 [ 54.323582] #2: (drm_global_mutex){+.+.+.}, at: [<ffffffffa04e1e0d>] drm_dev_register+0x2d/0x120 [drm] [ 54.323945] #3: (&dev->struct_mutex){+.+.+.}, at: [<ffffffffa05b4c2e>] intel_modeset_init_hw+0x3e/0x60 [i915] This regression got introduced in: commit 586d5270b60dc1f35cc3ca982d403765bad77965 Author: Imre Deak <imre.deak@intel.com> Date: Mon Apr 14 20:24:28 2014 +0300 drm/i915: move getting struct_mutex lower in the callstack during GPU reset Fix the problem by not taking struct_mutex around intel_enable_gt_powersave() in intel_modeset_init_hw() since intel_enable_gt_powersave() now grabs the mutex itself. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: remove extraneous VGA power domain put callsImre Deak2014-05-051-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In recent dmesg logs reported for unrelated issues I noticed some power domain WARNs caused by the following. The workaround commit ce352550327b394f3072a07c9cd9d27af9276f15 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Fri Sep 20 10:14:23 2013 +0300 drm/i915: Fix unclaimed register access due to delayed VGA memory disable and following fixup of it commit a14853206517b0c8102accbc77401805a0dbdb9e Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Mon Sep 16 17:38:34 2013 +0300 drm/i915: Move power well init earlier during driver load was partially reverted by commit 7f16e5c1416070dc590dd333a2d677700046a4ab Merge: 9d1cb91 5e01dc7 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Nov 4 16:28:47 2013 +0100 Merge tag 'v3.12' into drm-intel-next but kept the power domain put calls on the error path. I think for now we can keep things as-is (not reintroduce the w/a) and just fix the error path, since - nobody complained seeing this issue - according to Ville someone is reworking the VGA arbitration scheme at the moment and when that's ready we have to rethink this part anyway So fix this by just removing the put calls from the error path as well. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Integrate cmd parser kerneldocDaniel Vetter2014-05-052-1/+6
| | | | | | | | | | Ville noticed that we have this nice kerneldoc but it's not integrated anywhere. Fix this asap! Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Brad Volkin <bradley.d.volkin@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Do not call retire_requests from wait_for_renderingChris Wilson2014-05-052-49/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | A common issue we have is that retiring requests causes recursion through GTT manipulation or page table manipulation which we can only handle at very specific points. However, to maintain internal consistency (enforced through our sanity checks on write_domain at various points in the GEM object lifecycle) we do need to retire the object prior to marking it with a new write_domain, and also clear the write_domain for the implicit flush following a batch. Note that this then allows the unbound objects to still be on the active lists, and so care must be taken when removing objects from unbound lists (similar to the caveats we face processing the bound lists). v2: Fix i915_gem_shrink_all() to handle updated object lifetime rules, by refactoring it to call into __i915_gem_shrink(). v3: Missed an object-retire prior to changing cache domains in i915_gem_object_set_cache_leve() v4: Rebase Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Brad Volkin <bradley.d.volkin@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* lib: Export interval_treeChris Wilson2014-05-055-2/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | lib/interval_tree.c provides a simple interface for an interval-tree (an augmented red-black tree) but is only built when testing the generic macros for building interval-trees. For drivers with modest needs, export the simple interval-tree library as is. v2: Lots of help from Michel Lespinasse to only compile the code as required: - make INTERVAL_TREE a config option - make INTERVAL_TREE_TEST select the library functions and sanitize the filenames & Makefile - prepare interval_tree for being built as a module if required Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michel Lespinasse <walken@google.com> Cc: Rik van Riel <riel@redhat.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Michel Lespinasse <walken@google.com> [Acked for inclusion via drm/i915 by Andrew Morton.] [danvet: switch to _GPL as per the mailing list discussion.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: vlv: increase timeout when forcing on the GFX clockImre Deak2014-05-051-2/+2
| | | | | | | | I've seen latencies up to 15msec, so increase the timeout to 20msec. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: vlv: factor out vlv_force_gfx_clock and check for pending force-offImre Deak2014-05-053-14/+40
| | | | | | | | | | | | | | | | | This will be needed by the VLV runtime PM helpers too, so factor it out. Also add a safety check for the case where the previous force-off is still pending, since I'm not sure if Punit can handle a new setting while the previous one hasn't settled yet. v2: - unchanged v3: - add a note to the commit message about the safety check (Ville) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: vlv: setup RPS min/max frequencies once during init timeImre Deak2014-05-051-25/+41
| | | | | | | | | When enabling runtime PM on VLV, GT power save enabling becomes relatively frequent, so optimize it a bit. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: reinit GT power save during resumeImre Deak2014-05-051-0/+7
| | | | | | | | | | | | | | | | | | | | During runtime suspend there can be a last pending rps.work, so make sure it's canceled. Note that in the runtime suspend callback we can't get any RPS interrupts since it's called only after the GPU goes idle and we set the minimum RPS frequency. The next possibility for an RPS interrupt is only after getting an RPM ref (for example because of a new GPU command) and calling the RPM resume callback. v2: - patch introduced in v2 of the patchset v3: - Change the order of canceling the rps.work and disabling interrupts to avoid the race between interrupt disabling and the the rps.work. Race spotted by Ville. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: make runtime PM swizzling/ring_freq init platform independentImre Deak2014-05-052-4/+3
| | | | | | | | | | | | We need to re-init sizzling on all platforms so move it to the platform independent runtime resume callback. The ring frequency reinit is also needed everywhere except on VLV, but gen6_update_ring_freq() will be a noop on VLV, so we can move this function too to platform independent code. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: factor out gen6_update_ring_freqImre Deak2014-05-053-7/+15
| | | | | | | | | | | | | | | | This is needed by the next patch moving the call out from platform specific RPM callbacks to platform independent code. No functional change. v2: - patch introduce in v2 of the patchset v3: - simplify platform check condition (Ville) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: make runtime PM interrupt enable/disable platform independentImre Deak2014-05-052-11/+5
| | | | | | | | | | | | | | | We need to disable the interrupts for all platforms, so make the helpers for this platform independent and call them from them platform independent runtime suspend/resume callbacks. On HSW/BDW this will move interrupt disabling/re-enabling at the beginning/end of runtime suspend/resume respectively, but I don't see any reason why this would cause a problem there. In any case this seems to be the correct thing to do even on those platforms. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: disable runtime PM if RC6 is disabledImre Deak2014-05-052-1/+13
| | | | | | | | | | | | | | | | | | On VLV we depend on RC6 to save the GT render and media HW context before going to the D3 state via RPM, so as a preparation for the VLV RPM support (added in an upcoming patch) disable RPM if RC6 is disabled. There is probably a similar dependency on other platforms too, so for safety require RC6 for those too. For these platforms (SNB, HSW, BDW) this is then a possible fix. v2: - require RC6 for all RPM platforms, not just for VLV (Paulo, Daniel) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: sanitize enable_rc6 optionImre Deak2014-05-051-3/+27
| | | | | | | | | | | | | | | | | Atm, an invalid enable_rc6 module option will be silently ignored, so emit an info message about it. Doing an early sanitization we can also reuse intel_enable_rc6() in a follow-up patch to see if RC6 is actually enabled. Currently the caller would have to filter a non-zero return value based on the platform we are running on. For example on VLV with i915.enable_rc6 set to 2, RC6 won't be enabled but atm intel_enable_rc6() would still return 2 in this case. v2: - simplify the platform check condition (Ville) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: fix unbalanced GT powersave enable / disable callsImre Deak2014-05-051-1/+1
| | | | | | | | | | | Atm, we call intel_gt_powersave_enable() for GEN6 and GEN7 but disable it for everything starting from GEN6. This is a problem in case of BDW. Since I don't have a BDW to test if RC6 works properly, just keep it disabled for now and fix only the disable function. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: vlv: check port power domain instead of only D0 for eDP VDD onImre Deak2014-05-051-1/+5
| | | | | | | | | | | | Some platforms need additional power domains to be on in addition to the device D0 state to access the panel registers. Suggested by Daniel. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76987 Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: add missing error capturing of the PIPESTAT regImre Deak2014-05-053-4/+5
| | | | | | | | | | | | | | | | | | | | While checking the error capture path I noticed that we lacked the power domain-on check for PIPESTAT so fix this by moving that to where the rest of pipe registers are captured. The move also revealed that we actually don't include this register in the error report, so fix that too. v2: - patch introduced in v2 of the patchset v3: - add back !HAS_PCH_SPLIT check (Ville) [ Ignore my previous comment about the gen<=5 || vlv check, I realized that it's the same as !HAS_PCH_SPLIT. ] Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: gen2: move error capture of IER to its correct placeImre Deak2014-05-051-4/+4
| | | | | | | | | | While checking the error capture path I noticed that this register is read twice for GEN2, so fix this and also move the read where it's done for other platforms. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: get a runtime PM ref for the deferred GPU reset workImre Deak2014-05-051-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | Atm we can end up in the GPU reset deferred work in D3 state if the last runtime PM reference is dropped between detecting a hang/scheduling the work and executing the work. At least one such case I could trigger is the simulated reset via the i915_wedged debugfs entry. Fix this by getting an RPM reference around accessing the HW in the reset work. v2: - Instead of getting/putting the RPM reference in the reset work itself, get it already before scheduling the work. By this we also prevent going to D3 before the work gets to run, in addition to making sure that we run the work itself in D0. (Ville, Daniel) v3: - fix inverted logic fail when putting the RPM ref on behalf of a cancelled GPU reset work (Ville) v4: - Taking the RPM ref in the interrupt handler isn't really needed b/c it's already guaranteed that we hold an RPM ref until the end of the reset work in all cases we care about. So take the ref in the reset work (for cases like i915_wedged_set). (Daniel) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Validate VBT header before trusting itChris Wilson2014-05-051-18/+50
| | | | | | | | | | | Be we read and chase pointers from the VBT, it is prudent to make sure that those accesses are wholly contained within the MMIO region, or else we may cause a kernel panic during boot. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Validate BDB section before readingChris Wilson2014-05-051-1/+7
| | | | | | | | | | | Make sure that the whole BDB section is within the MMIO region prior to accessing it contents. That we don't read outside of the secion is left up to the individual section parsers. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: get a runtime PM ref for the deferred GT powersave enablingImre Deak2014-05-053-3/+38
| | | | | | | | | | | | | | | At least on VLV but probably on other platforms too we depend on RC6 being enabled for RPM, so disable RPM until the delayed RC6 enabling completes. v2: - explain the reason for the _noresume version of RPM get (Daniel) - use the simpler 'if (schedule_work()) rpm_get();' instead of 'if (!cancel_work_sync()) rpm_get(); schedule_work();' Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: move getting struct_mutex lower in the callstack during GPU resetImre Deak2014-05-052-4/+3
| | | | | | | | | | | | | | Getting struct_mutex around the whole intel_enable_gt_powersave() function is not necessary, since it's only needed for the ILK path therein. This will make intel_enable_gt_powersave() useable on the RPM resume path for >=GEN6 (added in an upcoming patch to reset the RPS state during RPM resume), where we can't (and need not) get this mutex. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: get a runtime PM ref for debugfs entries where neededImre Deak2014-05-052-0/+14
| | | | | | | | | | | | | | | These debugfs entries access registers that need the D0 power state so get an RPM ref for them. v2: - for all these entries we only need D0 state, so get only an RPM ref, not a power domain ref (Daniel, Paulo) - the dpio entry is not an issue any more as it got removed (Ville) - restore commit message from v1 (Paulo) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: remove the i915_dpio debugfs entryImre Deak2014-05-051-48/+0
| | | | | | | | | | | | | | There are igt tools that can read/write the DPIO registers, so having a debugfs entry for only some of those registers is somewhat arbitrary / redundant. Remove it. v2: - instead of fixing the entry by taking a power domain reference around the register accesses, remove the entry (Ville) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: fix the RC6 status debug printImre Deak2014-05-051-1/+7
| | | | | | | | The parsing was incorrect for ILK and VLV. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: vlv: add RC6 residency countersImre Deak2014-05-052-0/+8
| | | | | | Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: vlv: clear master interrupt flag when disabling interruptsImre Deak2014-05-051-0/+2
| | | | | | | | | | Not clearing this flag causes spurious interrupts at least in D3 state, so before enabling RPM we need to fix this. We were already setting this flag when enabling interrupts, only clearing it was missing. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: vlv: clean up GTLC wake control/status register macrosImre Deak2014-05-052-4/+11
| | | | | | | | | These will be needed by the upcoming VLV RPM helpers. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Use the coarse ping-pong mechanism based on drm fd to dispatch the ↵Zhao Yakui2014-05-053-1/+45
| | | | | | | | | | | | | | | | | | | | | | | | | BSD command on BDW GT3 The BDW GT3 has two independent BSD rings, which can be used to process the video commands. To be simpler, it is transparent to user-space driver/middle. Instead the kernel driver will decide which ring is to dispatch the BSD video command. As every BSD ring is powerful, it is enough to dispatch the BSD video command based on the drm fd. In such case it can play back video stream while encoding another video stream. The coarse ping-pong mechanism is used to determine which BSD ring is used to dispatch the BSD video command. V1->V2: Follow Daniel's comment and use the simple ping-pong mechanism. This is only to add the support of dual BSD rings on BDW GT3 machine. The further optimization will be considered in another patch set. V2->V3: Follow Daniel's comment to use the struct_mutext instead of atomic_t during determining which ring can be used to dispatch Video command. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915:Add the VCS2 switch in Intel_ring_setup_status_pageZhao Yakui2014-05-051-0/+5
| | | | | | | | | | | | The Gen7 doesn't have the second BSD ring. But it will complain the switch check warning message during compilation. So just add it to remove the switch check warning. V1->V2: Follow Daniel's comment to update the comment Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915:Handle the irq interrupt for the second BSD ringZhao Yakui2014-05-051-1/+4
| | | | | | Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915:Initialize the second BSD ring on BDW GT3 machineZhao Yakui2014-05-057-4/+95
| | | | | | | | | | | | | | Based on the hardware spec, the BDW GT3 machine has two independent BSD ring that can be used to dispatch the video commands. So just initialize it. V3->V4: Follow Imre's comment to do some minor updates. For example: more comments are added to describe the semaphore between ring. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> [danvet: Fix up checkpatch error.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Update the restrict check to filter out wrong Ring ID passed by ↵Zhao Yakui2014-05-052-1/+2
| | | | | | | | user-space Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Split the BDW device definition to prepare for dual BSD rings on ↵Zhao Yakui2014-05-052-7/+41
| | | | | | | | | | | | | | | BDW GT3 Based on the hardware spec, the BDW GT3 has the different configuration with the BDW GT1/GT2. So split the BDW device info definition. This is to do the preparation for adding the Dual BSD rings on BDW GT3 machine. V1->V2: Follow Daniel's comment to pay attention to the stolen check for BDW in kernel/early-quirks.c Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Catch dirt in unused execbuffer fieldsDaniel Vetter2014-05-051-0/+10
| | | | | | | | | | | We need to make sure that userspace keeps on following the contract, otherwise we won't be able to use the reserved fields at all. v2: Add DRM_DEBUG (Chris) Testcase: igt/gem_exec_params/*-dirt Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Catch abuse of I915_EXEC_CONSTANTS_*Daniel Vetter2014-05-051-4/+12
| | | | | | | | | | A bit tricky since 0 is also a valid constant ... v2: Add DRM_DEBUG (Chris) Testcase: igt/gem_exec_params/rel-constants-* Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
OpenPOWER on IntegriCloud