- 19 Jun, 2014 4 commits
-
-
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:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
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:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-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:
Imre Deak <imre.deak@intel.com> 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:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-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:
Matt Roper <matthew.d.roper@intel.com> 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 <paulo.r.zanoni@intel.com> Reviewed-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 16 commits
-
-
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:
-
Rodrigo Vivi authored
Now we have the active/inactive state for exit and this actually changes the HW enable bit the status was a bit confusing for users. So let's provide more info. Reviewed-by:
Vijay Purushothaman <vijay.a.purushothaman@intel.com> Signed-off-by:
-
Rodrigo Vivi authored
The perfect solution for psr_exit is the hardware tracking the changes and doing the psr exit by itself. This scenario works for HSW and BDW with some environments like Gnome and Wayland. However there are many other scenarios that this isn't true. Mainly one right now is KDE users on HSW and BDW with PSR on. User would miss many screen updates. For instances any key typed could be seen only when mouse cursor is moved. So this patch introduces the ability of trigger PSR exit on kernel side on some common cases that. Most of the cases are coverred by psr_exit at set_domain. The remaining cases are coverred by triggering it at set_domain, busy_ioctl, sw_finish and mark_busy. The downside here might be reducing the residency time on the cases this already work very wall like Gnome environment. But so far let's get focused on fixinge issues sio PSR couild be used for everybody and we could even get it enabled by default. Later we can add some alternatives to choose the level of PSR efficiency over boot flag of even over crtc property. v2: remove exit from connector_dpms. Daniel pointed this is the wrong way and also this isn't needed for BDW and HSW anyway. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
-
Jesse Barnes authored
Early revs didn't have PPGTT support, so disable there. v2: add debug msg when disabling on early stepping v3: enable on other B3 packages as well (untested) (Ville) References: https://bugs.freedesktop.org/show_bug.cgi?id=79669 References: https://bugs.freedesktop.org/show_bug.cgi?id=79670Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Acked-by:
-
Ville Syrjälä authored
CHECK linux/drivers/gpu/drm/i915/i915_gem_execbuffer.c linux/drivers/gpu/drm/i915/i915_gem_execbuffer.c:1529:47: warning: incorrect type in initializer (different address spaces) linux/drivers/gpu/drm/i915/i915_gem_execbuffer.c:1529:47: expected struct drm_i915_gem_exec_object2 *user_exec_list linux/drivers/gpu/drm/i915/i915_gem_execbuffer.c:1529:47: got void [noderef] <asn:1>* linux/drivers/gpu/drm/i915/i915_gem_execbuffer.c:1533:61: warning: incorrect type in argument 1 (different address spaces) linux/drivers/gpu/drm/i915/i915_gem_execbuffer.c:1533:61: expected void [noderef] <asn:1>*dst linux/drivers/gpu/drm/i915/i915_gem_execbuffer.c:1533:61: got unsigned long long *<noident> Signed-off-by:
-
Ville Syrjälä authored
Knowing the device stepping may be crucial in analyzing problems. Since we always ask bug reporters for dmegs with drm.debug=0xe (or something) it would be nice if the PCI revision is already included in the dump. Avoids having to ask for lspci output as well. Signed-off-by:
-
Ville Syrjälä authored
obj->framebuffer_references isn't an atomic_t so the decrement needs to be protected by some lock. struct_mutex seems like the appropriate lock here, and we may already take it for the obj unref anyway. Signed-off-by:
-
Rodrigo Vivi authored
On the current structure HSW doesn't support PSR with sprites enabled but sprites can be enabled after PSR was enabled what would cause user to miss screen updates. v2: move it to update_plane. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Rodrigo Vivi authored
Broadwell has a PSR per transcoder, where DDIA supports link disable and link standby modes while other transcoders only support link standby. Reviewed-by:
-
Rodrigo Vivi authored
Reviewed-by:
-
Rodrigo Vivi authored
When link is in stand by and PSR exit is triggered by a primary or sprite plane flip this mode allows only one single updated frame to be send to display than get back to PSR immediately. Reviewed-by:
-
Rodrigo Vivi authored
Also do not cache aux info. That info could be related to another panel. Reviewed-by:
-
Rodrigo Vivi authored
Being more conservative by enabling PSR only on psr_enable function. Reviewed-by:
-
Rodrigo Vivi authored
Let's be more conservative and protect platforms that don't support PSR from unecessary interactions. Reviewed-by:
-
Matt Roper authored
The DRM core will translate calls to legacy cursor ioctls into universal cursor calls automatically, so there's no need to maintain the legacy cursor support. This greatly simplifies the transition since we don't have to handle reference counting differently depending on which cursor interface was called. The aim here is to transition to the universal plane interface with minimal code change. There's a lot of cleanup that can be done (e.g., using state stored in crtc->cursor->fb rather than intel_crtc) that is left to future patches. v4: - Drop drm_gem_object_unreference() that is no longer needed now that we receive the GEM obj directly rather than looking up the ID. v3: - Pass cursor obj to intel_crtc_cursor_set_obj() if cursor fb changes, even if 'visible' is false. intel_crtc_cursor_set_obj() will notice that the cursor isn't visible and disable it properly, but we still need to get intel_crtc->cursor_addr set properly so that we behave properly if the cursor becomes visible again in the future without changing the cursor buffer (noted by Chris Wilson and verified via i-g-t kms_cursor_crc). - s/drm_plane_init/drm_universal_plane_init/. Due to type compatibility between enum and bool, everything actually works correctly with the wrong init call, except for the type of plane that gets exposed to userspace (it shows up as type 'primary' rather than type 'cursor'). v2: - Remove duplicate dimension checks on cursor - Drop explicit cursor disable from crtc destroy (fb & plane destruction will take care of that now) - Use DRM plane helper to check update parameters Cc: intel-gfx@lists.freedesktop.org Signed-off-by:
-
Matt Roper authored
Refactor cursor buffer setting such that the code to actually update the cursor lives in a new function, intel_crtc_cursor_set_obj(), and takes a GEM object as a parameter. The existing legacy cursor ioctl handler, intel_crtc_cursor_set() will now perform the userspace handle lookup and then call this new function. This refactoring is in preparation for the universal plane cursor support where we'll want to update the cursor with an actual GEM buffer object (obtained via drm_framebuffer) rather than a userspace handle. v2: Drop obvious kerneldoc and replace with note about function's reference consumption Reviewed-by:
-
