- 04 Jul, 2014 1 commit
-
-
Chris Wilson authored
Inlcude the pipe-size and cursor-size in debugfs. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
- 03 Jul, 2014 3 commits
-
-
Ben Widawsky authored
The GEN FBC unit provides the ability to set a low pass on frames it attempts to compress. If a frame is less than a certain amount compressibility (2:1, 4:1) it will not bother. This allows the driver to reduce the size it requests out of stolen memory. Unluckily, a few months ago, Ville actually began using this feature for framebuffers that are 16bpp (not sure why not 8bpp). In those cases, we are already using this mechanism for a different purpose, and so we can only achieve one further level of compression (2:1 -> 4:1) FBC GEN1, ie. pre-G45 is ignored. The cleverness of the patch is Art's. The bugs are mine. v2: Update message and including missing threshold case 3 (Spotted by Arthur). Cc: Art Runyan <arthur.j.runyan@intel.com> Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Ben Widawsky authored
Right now, there is no threshold (0 means fail, 1 means 1:1 compression limit). This is to split the function/non-functional change of the next patch. The next patch will start to attempt to reduce the amount of CFB space we need for dire situations. It will be contained within this function. Signed-off-by:
-
Ben Widawsky authored
We are already using the size to determine whether or not to free the object, so there is no functional change there. Almost everything else has changed to static allocations of the drm_mm_node too. Aside from bringing this inline with much of our other code, this makes error paths slightly simpler, which benefits the look of an upcoming patch. Signed-off-by:
-
- 02 Jul, 2014 2 commits
-
-
Fabian Frederick authored
use mm.h definition Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by:
Fabian Frederick <fabf@skynet.be> Signed-off-by:
-
Tom O'Rourke authored
Higher RC6 residency is observed using timeout mode instead of EI mode. This applies to Broadwell only. The difference is particularly noticeable with video playback. Signed-off-by:
Tom O'Rourke <Tom.O'Rourke@intel.com> Reviewed-by:
-
- 01 Jul, 2014 1 commit
-
-
Paulo Zanoni authored
It is possible that, by the time we run i915_drm_freeze(), delayed_resume_work was already queued but did not run yet. If it still didn't run after intel_runtime_pm_disable_interrupts(), by the time it runs it will try to change the interrupt registers with the interrupts already disabled, which will trigger a WARN. We can reliably reproduce this with the pm_rpm system-suspend test case. In order to avoid the problem, we have to flush the work before disabling the interrupts. We could also cancel the work instead of flushing it, but that would require us to put a runtime PM reference - and any other resource we may need in the future - in case the work was already queued, so I believe flushing the work is more future-proof, although less efficient. But I can also change this part if someone requests. Another thing I tried was to move the intel_suspend_gt_powersave() call to before intel_runtime_pm_disable_interrupts(), but since that function needs to be called after the interrupts are already disabled, due to dev_priv->rps.work, this strategy didn't work. Testcase: igt/pm_rpm/system-suspend Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80517Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
-
- 25 Jun, 2014 1 commit
-
-
Matt Roper authored
crtc->primary->fb may be NULL upon entry to intel_pipe_set_base() if the primary plane has previously been disabled via the universal plane interface. We need to check for NULL before trying to reference old_fb's obj. This fixes a regression introduced in commit a071fa00 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Jun 18 23:28:09 2014 +0200 drm/i915: Introduce accurate frontbuffer tracking Testcase: igt/kms_universal_plane Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
-
- 19 Jun, 2014 11 commits
-
-
Konrad Zapalowicz authored
This commit add check for return value of init_ring_common() in the init_render_ring(). Now, when failure is detected the error code is propagated to the caller instead of being ignored. Signed-off-by:
Konrad Zapalowicz <bergo.torino@gmail.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
So these are the guts of the new beast. This tracks when a frontbuffer gets invalidated (due to frontbuffer rendering) and hence should be constantly scaned out, and when it's flushed again and can be compressed/one-shot-upload. Rules for flushing are simple: The frontbuffer needs one more full upload starting from the next vblank. Which means that the flushing can _only_ be called once the frontbuffer update has been latched. But this poses a problem for pageflips: We can't just delay the flushing until the pageflip is latched, since that would pose the risk that we override frontbuffer rendering that has been scheduled in-between the pageflip ioctl and the actual latching. To handle this track asynchronous invalidations (and also pageflip) state per-ring and delay any in-between flushing until the rendering has completed. And also cancel any delayed flushing if we get a new invalidation request (whether delayed or not). Also call intel_mark_fb_busy in both cases in all cases to make sure that we keep the screen at the highest refresh rate both on flips, synchronous plane updates and for frontbuffer rendering. v2: Lots of improvements Suggestions from Chris: - Move invalidate/flush in flush_*_domain and set_to_*_domain. - Drop the flush in busy_ioctl since it's redundant. Was a leftover from an earlier concept to track flips/delayed flushes. - Don't forget about the initial modeset enable/final disable. Suggested by Chris. Track flips accurately, too. Since flips complete independently of rendering we need to track pending flips in a separate mask. Again if an invalidate happens we need to cancel the evenutal flush to avoid races. v3: Provide correct header declarations for flip functions. Currently not needed outside of intel_display.c, but part of the proper interface. v4: Add proper domain management to fbcon so that the fbcon buffer is also tracked correctly. v5: Fixup locking around the fbcon set_to_gtt_domain call. v6: More comments from Chris: - Split out fbcon changes. - Drop superflous checks for potential scanout before calling intel_fb functions - we can micro-optimize this later. - s/intel_fb_/intel_fb_obj_/ to make it clear that this deals in gem object. We already have precedence for fb_obj in the pin_and_fence functions. v7: Clarify the semantics of the flip flush handling by renaming things a bit: - Don't go through a gem object but take the relevant frontbuffer bits directly. These functions center on the plane, the actual object is irrelevant - even a flip to the same object as already active should cause a flush. - Add a new intel_frontbuffer_flip for synchronous plane updates. It currently just calls intel_frontbuffer_flush since the implemenation differs. This way we achieve a clear split between one-shot update events on one side and frontbuffer rendering with potentially a very long delay between the invalidate and flush. Chris and I also had some discussions about mark_busy and whether it is appropriate to call from flush. But mark busy is a state which should be derived from the 3 events (invalidate, flush, flip) we now have by the users, like psr does by tracking relevant information in psr.busy_frontbuffer_bits. DRRS (the only real use of mark_busy for frontbuffer) needs to have similar logic. With that the overall mark_busy in the core could be removed. v8: Only when retiring gpu buffers only flush frontbuffer bits we actually invalidated in a batch. Just for safety since before any additional usage/invalidate we should always retire current rendering. Suggested by Chris Wilson. v9: Actually use intel_frontbuffer_flip in all appropriate places. Spotted by Chris. v10: Address more comments from Chris: - Don't call _flip in set_base when the crtc is inactive, avoids redunancy in the modeset case with the initial enabling of all planes. - Add comments explaining that the initial/final plane enable/disable still has work left to do before it's fully generic. v11: Only invalidate for gtt/cpu access when writing. Spotted by Chris. v12: s/_flush/_flip/ in intel_overlay.c per Chris' comment. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Daniel Vetter authored
The downclocking checks a few more things, so not that simple to convert. Also, this should get unified with the drrs handling and also use the locking of that. Otoh the drrs locking is about as hapzardous as no locking, at least on first sight. For easier conversion ditch the upclocking on unload - we'll turn off everything anyway. Reviewed-by:
-
Jesse Barnes authored
We should be taking the right power well refs these days, so this shouldn't be necessary. It also gets in the way of re-using these routines for S0iX states, as those need all the power saving features enabled. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Jesse Barnes authored
We don't need to uninstall the full handler, simply disabling interrupts ought to be enough. Signed-off-by:
-
Daniel Vetter authored
X could end up putting the fbcon fb into other domains, e.g. for smooth take-overs. Also we want this for accurate frontbuffer tracking: The set_config is an implicit flush and will re-enable psr and similar features, so we need to bring the bo back into the gtt domain. v2: Add FIXME comment about fbcon locking fun in atomic context, requested by Chris. Reviewed-by:
-
Daniel Vetter authored
Can be useful to figure out imbalances and bugs in the frontbuffer tracking. Reviewed-by:
-
Daniel Vetter authored
So from just a quick look we seem to have enough information to accurately figure out whether a given gem bo is used as a frontbuffer and where exactly: We have obj->pin_count as a first check with no false negatives and only negligible false positives. And then we can just walk the modeset objects and figure out where exactly a buffer is used as scanout. Except that we can't due to locking order: If we already hold dev->struct_mutex we can't acquire any modeset locks, so could potential chase freed pointers and other evil stuff. So we need something else. For that introduce a new set of bits obj->frontbuffer_bits to track where a buffer object is used. That we can then chase without grabbing any modeset locks. Of course the consumers of this (DRRS, PSR, FBC, ...) still need to be able to do their magic both when called from modeset and from gem code. But that can be easily achieved by adding locks for these specific subsystems which always nest within either kms or gem locking. This patch just adds the relevant update code to all places. Note that if we ever support multi-planar scanout targets then we need one frontbuffer tracking bit per attachment point that we expose to userspace. v2: - Fix more oopsen. Oops. - WARN if we leak obj->frontbuffer_bits when freeing a gem buffer. Fix the bugs this brought to light. - s/update_frontbuffer_bits/update_fb_bits/. More consistent with the fb tracking functions (fb for gem object, frontbuffer for raw bits). And the function name was way too long. v3: Size obj->frontbuffer_bits correctly so that all pipes fit in. v4: Don't update fb bits in set_base on failure. Noticed by Chris. v5: s/i915_gem_update_fb_bits/i915_gem_track_fb/ Also remove a few local enum pipe variables which are now no longer needed to make the function arguments no drop over the 80 char limit. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Daniel Vetter authored
It doesn't make sense to never again schedule the work, since by the time we might want to re-enable psr the world might have changed and we can do it again. The only exception is when we shut down the pipe, but that's an entirely different thing and needs to be handled in psr_disable. Note that later patch will again split psr_exit into psr_invalidate and psr_flush. But the split is different and this simplification helps with the transition. v2: Improve the commit message a bit. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
-
Daniel Vetter authored
We have _enable/_disable interfaces now for the modeset sequence and intel_edp_psr_exit for workarounds. The callsites in intel_display.c are all redundant with the modeset sequence enable/disable calls in intel_ddi.c. The one in intel_sprite.c is real and needs to be switched to psr_exit. If this breaks anything then we need to augment the enable/disable functions accordingly. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
-
Daniel Vetter authored
It's not needed and further more will get in the way of a sane locking scheme - psr_exit _can't_ take modeset locks due to lock inversion, and at least once dp mst hits the connector list is no longer static. But since we track all state in dev_priv->psr there is no need at all. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
-
- 18 Jun, 2014 2 commits
-
-
Oscar Mateo authored
The original comment that introduced it said: commit 0009e46c Author: Ben Widawsky <ben@bwidawsk.net> Date: Fri Dec 6 14:11:02 2013 -0800 drm/i915: Track which ring a context ran on Previously we dropped the association of a context to a ring. It is however very important to know which ring a context ran on (we could have reused the other member, but I was nitpicky). This is very important when we switch address spaces, which unlike context objects, do change per ring. As an example, if we have: RCS BCS ctx A ctx A ctx B ctx B Without tracking the last ring B ran on, we wouldn't know to switch the address space on BCS in the last row. But this is not really true, because we are already checking to != from (with "from" being = ring->last_context) and that should be enough to make sure we switch to the right address space. We would have a problem if we switched the context object for every ring (since then we would fail to do it in some situations) but we only switch it for the render ring, so we don't care. Signed-off-by:
Oscar Mateo <oscar.mateo@intel.com> Reviewed-by:
-
Daniel Vetter authored
Jesse's SOix work required some patches from acpi-next, so pull it in through a topic barnch. Conflicts: drivers/gpu/drm/i915/i915_drv.c drivers/gpu/drm/i915/intel_pm.c Signed-off-by:
-
- 17 Jun, 2014 12 commits
-
-
Oscar Mateo authored
Otherwise, we might receive a new interrupt before we have time to ack the first one, eventually missing it. Without an atomic XCHG operation with mmio space, this patch merely reduces the window in which we can miss an interrupt (especially when you consider how heavyweight the I915_READ/I915_WRITE operations are). Notice that, before clearing a port-sourced interrupt in the IIR, the corresponding interrupt source status in the PORT_HOTPLUG_STAT must be cleared. Spotted by Bob Beckett <robert.beckett@intel.com>. v2: - Add warning to commit message and comments to the code as per Chris Wilson's request. - Imre Deak pointed out that the pipe underrun flag might not be signaled in IIR, so do not make valleyview_pipestat_irq_handler depend on it. v3: Improve the source code comment. Signed-off-by:
-
Oscar Mateo authored
Otherwise, we might receive a new interrupt before we have time to ack the first one, eventually missing it. The right order should be: 1 - Disable Master Interrupt Control. 2 - Find the category of interrupt that is pending. 3 - Find the source(s) of the interrupt and clear the Interrupt Identity bits (IIR) 4 - Process the interrupt(s) that had bits set in the IIRs. 5 - Re-enable Master Interrupt Control. Without an atomic XCHG operation with mmio space, the above merely reduces the window in which we can miss an interrupt (especially when you consider how heavyweight the I915_READ/I915_WRITE operations are). Spotted by Bob Beckett <robert.beckett@intel.com>. v2: Add warning to commit message and comments to the code as per Chris Wilson's request. v3: Improve the source code comment. Signed-off-by:
-
Oscar Mateo authored
Otherwise, we might receive a new interrupt before we have time to ack the first one, eventually missing it. Without an atomic XCHG operation with mmio space, this patch merely reduces the window in which we can miss an interrupt (especially when you consider how heavyweight the I915_READ/I915_WRITE operations are). Notice that, before clearing a port-sourced interrupt in the IIR, the corresponding interrupt source status in the PORT_HOTPLUG_STAT must be cleared. Spotted by Bob Beckett <robert.beckett@intel.com>. v2: - Reorder the IIR clearing to reduce the window even further. - Add warning to commit message and comments to the code as per Chris Wilson's request. - Imre Deak pointed out that the pipe underrun flag might not be signaled in IIR, so do not make valleyview_pipestat_irq_handler depend on it. v3: Improve the source code comment. Signed-off-by:
-
Oscar Mateo authored
Otherwise, we might receive a new interrupt before we have time to ack the first one, eventually missing it. According to BSPec, the right order should be: 1 - Disable Master Interrupt Control. 2 - Find the source(s) of the interrupt. 3 - Clear the Interrupt Identity bits (IIR). 4 - Process the interrupt(s) that had bits set in the IIRs. 5 - Re-enable Master Interrupt Control. Without an atomic XCHG operation with mmio space, the above merely reduces the window in which we can miss an interrupt (especially when you consider how heavyweight the I915_READ/I915_WRITE operations are). We maintain the "disable SDE interrupts when handling" hack since apparently it works. Spotted by Bob Beckett <robert.beckett@intel.com>. v2: Add warning to commit message and comments to the code as per Chris Wilson's request. v3: Improve the source comments. Signed-off-by:
-
Daniel Vetter authored
A WARN_ON is perfectly fine. The BUG in here seems to be the cause behind hard-hangs when I cat the i915_gem_pageflip debugfs file (which calls this from an irq spinlock). But only while running a full igt run after a while. I still need to root cause the underlying issue. I'll also start reject patches which add new BUG_ON but don't come with a really good justification for it. The general rule really should be to just WARN and hope the driver survives for long enough. v2: Make the WARN a bit more useful per Chris' suggestion. Reviewed-by:
-
Daniel Vetter authored
We could walk of a bad list otherwise when someone concurrently unbinds stuff for fun. I've suspected this as the root-cause behind seemingly inconsistent state, but alas it's not. Acked-by:
-
Brad Volkin authored
Beignet needs these in order to program the L3 cache config for OpenCL workloads, particularly when using SLM. Signed-off-by:
Brad Volkin <bradley.d.volkin@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Take the minimum of the object size and the vma size and prefault only that much. Avoids a SIGBUS when mmapping only a portion of the object. Prefaulting was introduced here: commit b90b91d8 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Jun 10 12:14:40 2014 +0100 drm/i915: Prefault the entire object on first page fault Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Testcase: igt/gem_mmap/short-mmap Signed-off-by:
-
Sourab Gupta authored
This patch enables the framework for using MMIO based flip calls, in contrast with the CS based flip calls which are being used currently. MMIO based flip calls can be enabled on architectures where Render and Blitter engines reside in different power wells. The decision to use MMIO flips can be made based on workloads to give 100% residency for Media power well. v2: The MMIO flips now use the interrupt driven mechanism for issuing the flips when target seqno is reached. (Incorporating Ville's idea) v3: Rebasing on latest code. Code restructuring after incorporating Damien's comments v4: Addressing Ville's review comments -general cleanup -updating only base addr instead of calling update_primary_plane -extending patch for gen5+ platforms v5: Addressed Ville's review comments -Making mmio flip vs cs flip selection based on module parameter -Adding check for DRIVER_MODESET feature in notify_ring before calling notify mmio flip. -Other changes mostly in function arguments v6: -Having a seperate function to check condition for using mmio flips (Ville) -propogating error code from i915_gem_check_olr (Ville) v7: -Adding __must_check with i915_gem_check_olr (Chris) -Renaming mmio_flip_data to mmio_flip (Chris) -Rebasing on latest nightly v8: -Rebasing on latest code -squash 3rd patch in series(mmio setbase vs page flip race) with this patch -Added new tiling mode update in intel_do_mmio_flip (Chris) v9: -check for obj->last_write_seqno being 0 instead of obj->ring being NULL in intel_postpone_flip, as this is a more restrictive condition (Chris) v10: -Applied Chris's suggestions for squashing patches 2,3 into this patch. These patches make the selection of CS vs MMIO flip at the page flip time, and make the module parameter for using mmio flips as tristate, the states being 'force CS flips', 'force mmio flips', 'driver discretion'. Changed the logic for driver discretion (Chris) v11: Minor code cleanup(better readability, fixing whitespace errors, using lockdep to check mutex locked status in postpone_flip, removal of __must_check in function definition) (Chris) Reviewed-by:Sourab Gupta <sourab.gupta@intel.com> Signed-off-by:
Akash Goel <akash.goel@intel.com> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> # snb, ivb [danvet: Fix up parameter alignement checkpatch spotted.] Signed-off-by:
-
Daniel Vetter authored
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
-
Daisy Sun authored
Staring from HSW, the resolution limit of FBC has increased to 4096*4096 Issue: VIZ-2813 Change-Id: I842f64e3cf2c0d18d29ef1bcfef3b9bb1f1764ac Signed-off-by:
Daisy Sun <daisy.sun@intel.com> Reviewed-by:
-
Akash Goel authored
This adds support for a write-enable bit in the entry of GTT. This is handled via a read-only flag in the GEM buffer object which is then used to see how to set the bit when writing the GTT entries. Currently by default the Batch buffer & Ring buffers are marked as read only. v2: Moved the pte override code for read-only bit to 'byt_pte_encode'. (Chris) Fixed the issue of leaving 'gt_old_ro' as unused. (Chris) v3: Removed the 'gt_old_ro' field, now setting RO bit only for Ring Buffers(Daniel). v4: Added a new 'flags' parameter to all the pte(gen6) encode & insert_entries functions, in lieu of overloading the cache_level enum (Daniel). v5: Removed the superfluous VLV check & changed the definition location of PTE_READ_ONLY flag (Imre) Reviewed-by:
-
- 16 Jun, 2014 6 commits
-
-
Matt Roper authored
Now that the primary plane can be disabled independently of the CRTC, the debugfs code needs to be updated to recognize when the primary plane is disabled and not try to return information about the primary plane's framebuffer. This change prevents a NULL dereference when reading i915_display_info with a disabled primary plane. v2: Replace a seq_printf() with seq_puts() (suggested by Damien) Signed-off-by:
-
Daniel Vetter authored
Spotted while crawling around in the area. Reviewed-by:
-
Paulo Zanoni authored
Any comment containing "current Intel hardware supports" quickly becomes obsolete, so remove it and let people discover the information by looking at the function implementation. Signed-off-by:
-
Paulo Zanoni authored
Two BSpec updates changed the recommended values for BDW eDP and DP DDI buffer translations. Now the signal levels also match the HSW signal levels, which simplify things a little bit. It seems some DP sinks don't work properly without voltage level 0 and pre-emphasis level 3, so this patch may fix some bugs on panels/monitors that happen on BDW but not on HSW. Signed-off-by:
-
Chris Wilson authored
Rewrite i915_gem_render_state.c for the purposes of clarity and compactness, in the process we can eliminate some dodgy math that did not handle 64bit addresses correctly. Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
-
Chris Wilson authored
An object can only have an active gtt mapping if it is currently bound into the global gtt. Therefore we can simply walk the list of all bound objects and check the flag upon those for an active gtt mapping. From commit 48018a57 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Dec 13 15:22:31 2013 -0200 drm/i915: release the GTT mmaps when going into D3 Also note that the WARN is inappropriate for this function as GPU activity is orthogonal to GTT mmap status. Rather it is the caller that relies upon this condition and so it should assert that the GPU is idle itself. References: https://bugs.freedesktop.org/show_bug.cgi?id=80081Signed-off-by:
-
- 13 Jun, 2014 1 commit
-
-
Christoph Jaeger authored
intel_dsi_init() bails out without freeing the memory 'intel_dsi' and 'intel_connector' point to. Simply bail out before allocating memory. Picked up by Coverity - CID 1222750. Signed-off-by:
Christoph Jaeger <christophjaeger@linux.com> Signed-off-by:
-
