- 07 Dec, 2016 10 commits
-
-
Ville Syrjälä authored
Each DSPARB register can house bits for two separate pipes, hence we must protect the registers during reprogramming so that parallel FIFO reconfigurations happening simultaneosly on multiple pipes won't corrupt each others values. We'll use a new spinlock for this instead of the wm_mutex since we'll have to move the DSPARB programming to happen from the vblank evade critical section, and we can't use mutexes in there. v2: Document why we use a spinlock instead of a mutex (Maarten) Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1480947208-18468-1-git-send-email-ville.syrjala@linux.intel.comReviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Jani Nikula authored
Duplicating the PCI ID for IS_FOO checks is redundant for a bunch of platforms. Simplify. Reviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/4f79321aca2e003a627ba8b6809af3716b7c25c9.1480520526.git.jani.nikula@intel.com
-
Jani Nikula authored
Distinguish them better. Reviewed-by:
-
Jani Nikula authored
Consistency FTW. Reviewed-by:
-
Jani Nikula authored
Add more consistency to our naming. Pineview remains the outlier. Keep using code names for gen5+. v2: rebased Reviewed-by:
-
Jani Nikula authored
Move G33 and Pineview higher up in the list. Add a couple of blank lines for OCD while at it. Reviewed-by:
-
Jani Nikula authored
The platform flags in device info are (mostly) mutually exclusive. Replace the flags with an enum. Add the platform enum also for platforms that previously didn't have a flag, and give them codename logging in dmesg. Pineview remains an exception, the platform being G33 for that. v2: Sort enum by gen and date v3: rebase on geminilake enabling Signed-off-by:
-
Arkadiusz Hiler authored
The firmware interface file was initially partially autogenerated, but this is no longer the case. It was never updated automatically, and a lot manual changes were introduced since. >From now on any changes to the firmware interface will be managed by hand, which gives us flexibility when it comes to structure reuse (HuC/GuC) and naming conventions. Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Jeff Mcgee <jeff.mcgee@intel.com> Cc: Sagar A. Kamble <sagar.a.kamble@intel.com> Signed-off-by:
Arkadiusz Hiler <arkadiusz.hiler@intel.com> Reviewed-by:
Jeff McGee <jeff.mcgee@intel.com> Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1480953869-25267-1-git-send-email-arkadiusz.hiler@intel.com
-
Michel Thierry authored
As it already says in the comment block... Signed-off-by:
Michel Thierry <michel.thierry@intel.com> Reviewed-by:
Michał Winiarski <michal.winiarski@intel.com> Signed-off-by:
-
Michel Thierry authored
Instead of being hidden in sanitize_enable_ppgtt. It also seems to be the place to do so nowadays. Signed-off-by:
-
- 06 Dec, 2016 1 commit
-
-
Chris Wilson authored
On all platforms we now always read the contents of buffers via the GTT, i.e. using WC cpu access. Reads are slow, but they can be accelerated with an internal read buffer using sse4.1 (movntqda). This is our i915_memcpy_from_wc() routine which also checks for sse4.1 support and so we can fallback to using a regular slow memcpy if we need to. When compressing the pages, the reads are currently done inside zlib's fill_window() routine and so we must copy the page into a temporary which is then already inside the CPU cache and fast for zlib's compression. When not compressing the pages, we don't need a temporary and can just use the accelerated read from WC into the destination. v2: Use zstream locals to reduce diff and allocate the additional temporary storage only if sse4.1 is supported. v3: Use length=0 for the sse4.1 support check Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161206124051.17040-1-chris@chris-wilson.co.ukReviewed-by:
-
- 05 Dec, 2016 28 commits
-
-
Matthew Auld authored
Use BUILD_BUG_ON_INVALID(expr) in GEM_BUG_ON when building without DEBUG_GEM. This means the compiler can now check the validity of expr without generating any code, in turn preventing us from inadvertently breaking the build when DEBUG_GEM is not enabled. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161202184750.3843-1-matthew.auld@intel.comReviewed-by:
-
Chris Wilson authored
list.h provides a macro for updating the next element in a safe list-iter, so let's use it so that it is hopefully clearer to the reader about the unusual behaviour, and also easier to grep. Signed-off-by:
-
Chris Wilson authored
Only once the debugobject symbols are exported can we enable support for debugging swfences when i915 is built as a module. Requires commit 2617fdca3f68 ("lib/debugobjects: export for use in modules") Signed-off-by: -
Chris Wilson authored
As we use debugobjects to track the lifetime of fences within our atomic state, we ideally want to mark those objects as freed along with their containers. This merits us hookin into config->funcs->atomic_state_free for this purpose. This allows us to enable debugobjects for sw-fences without triggering known issues. Fixes: fc158405 ("drm/i915: Integrate i915_sw_fence with debugobjects") Signed-off-by:
-
Chris Wilson authored
We can replace a couple of tests with an assertion that the passed in node is already allocated (as matches the existing call convention) and by a small bit of refactoring we can bring the line lengths to under 80cols. Signed-off-by:
-
Chris Wilson authored
Soft-pinning depends upon being able to check for availabilty of an interval and evict overlapping object from a drm_mm range manager very quickly. Currently it uses a linear list, and so performance is dire and not suitable as a general replacement. Worse, the current code will oops if it tries to evict an active buffer. It also helps if the routine reports the correct error codes as expected by its callers and emits a tracepoint upon use. For posterity since the wrong patch was pushed (i.e. that missed these key points and had known bugs), this is the changelog that should have been on commit 506a8e87 ("drm/i915: Add soft-pinning API for execbuffer"): Userspace can pass in an offset that it presumes the object is located at. The kernel will then do its utmost to fit the object into that location. The assumption is that userspace is handling its own object locations (for example along with full-ppgtt) and that the kernel will rarely have to make space for the user's requests. This extends the DRM_IOCTL_I915_GEM_EXECBUFFER2 to do the following: * if the user supplies a virtual address via the execobject->offset *and* sets the EXEC_OBJECT_PINNED flag in execobject->flags, then that object is placed at that offset in the address space selected by the context specifier in execbuffer. * the location must be aligned to the GTT page size, 4096 bytes * as the object is placed exactly as specified, it may be used by this execbuffer call without relocations pointing to it It may fail to do so if: * EINVAL is returned if the object does not have a 4096 byte aligned address * the object conflicts with another pinned object (either pinned by hardware in that address space, e.g. scanouts in the aliasing ppgtt) or within the same batch. EBUSY is returned if the location is pinned by hardware EINVAL is returned if the location is already in use by the batch * EINVAL is returned if the object conflicts with its own alignment (as meets the hardware requirements) or if the placement of the object does not fit within the address space All other execbuffer errors apply. Presence of this execbuf extension may be queried by passing I915_PARAM_HAS_EXEC_SOFTPIN to DRM_IOCTL_I915_GETPARAM and checking for a reported value of 1 (or greater). v2: Combine the hole/adjusted-hole ENOSPC checks v3: More color, more splitting, more blurb. Fixes: 506a8e87 ("drm/i915: Add soft-pinning API for execbuffer") Signed-off-by:
-
Chris Wilson authored
We need to distinguish between full i915_vma structs and simple drm_mm_nodes when considering eviction (i.e. we must be careful not to treat a mere drm_mm_node as a much larger i915_vma causing memory corruption, if we are lucky). To do this, color these not-a-vma with -1 (I915_COLOR_UNEVICTABLE). v2...v200: New name for -1. Signed-off-by:
-
Hans de Goede authored
On my Cherrytrail CUBE iwork8 Air tablet PIPE-A would get stuck on loading i915 at boot 1 out of every 3 boots, resulting in a non functional LCD. Once the i915 driver has successfully loaded, the panel can be disabled / enabled without hitting this issue. The getting stuck is caused by vlv_init_display_clock_gating() clearing the DPOUNIT_CLOCK_GATE_DISABLE bit in DSPCLK_GATE_D when called from chv_pipe_power_well_ops.enable() on driver load, while a pipe is enabled driving the DSI LCD by the BIOS. Clearing this bit while DSI is in use is a known issue and intel_dsi_pre_enable() / intel_dsi_post_disable() already set / clear it as appropriate. This commit modifies vlv_init_display_clock_gating() to leave the DPOUNIT_CLOCK_GATE_DISABLE bit alone fixing the pipe getting stuck. Changes in v2: -Replace PIPE-A with "a pipe" or "the pipe" in the commit msg and comment Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97330 Cc: stable@vger.kernel.org Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
-
Ville Syrjälä authored
Rather than accessing crtc->config in vlv_compute_wm_level() let's pass in the crtc state explicitly. One step closer to atomic. Signed-off-by:
-
Ville Syrjälä authored
Add small helpers to make the intent of the staggered enable/disable sequence in vlv_program_watermarks() easier on the eyes. Signed-off-by:
-
Ville Syrjälä authored
We'll want to decouple the vlv/chv wm register reprogramming from any single pipe. So let's just write all the DDL registers in one go. We already write all the wm registers anyway since the bits are sprinkled all over the place and so writing them for just a single pipe would have been too messy anyway. Signed-off-by:
-
Ville Syrjälä authored
On VLV/CHV some of the watermark values are split across two registers: low order bits in one, and high order bits in another. So we may not be able to update a single watermark value atomically, and thus we must be careful that we don't temporarily introduce out of bounds values during the reprogramming. To prevent this we can simply zero out all the high order bits initially, then we update the low order bits, and finally we update the high order bits with the final value. Signed-off-by:
-
Ville Syrjälä authored
Before we attempt to turn any planes on or off we must first exit csxr. That's due to cxsr effectively making the plane enable bits read-only. Currently we achieve that with a vblank wait right after toggling the cxsr enable bit. We do the vblank wait even if cxsr was already off, which seems wasteful, so let's try to only do it when absolutely necessary. We could start tracking the cxsr state fully somewhere, but for now it seems easiest to just have intel_set_memory_cxsr() return the previous cxsr state. Signed-off-by:
-
Ville Syrjälä authored
Let's protect the cxsr state with the wm_mutex, since it might get poked from multiple places if there's a parallel plane update happening with a pipe getting enable/disabled. It's still pretty racy for the old platforms, but for vlv/chv it should work, I think. If not, we'll improve it later anyway. Signed-off-by:
-
Ville Syrjälä authored
Passing dev_priv instead of dev is the future. Let's make the vlv/chv wm functions respect that idea. Signed-off-by:
-
Ville Syrjälä authored
Add a small helper to do invert the vlv/chv values. Less fragile perhaps, and let's us clearly mark all overlarge wateramarks as disabled (by just making them all USHRT_MAX). Signed-off-by:
-
Ville Syrjälä authored
Store the vlv/chv watermark values in straight up arrays indexed by enum plane_id. Avoids a lot of useless checks for the plane type when we don't have to think which structure member we need to access. Signed-off-by:
-
Ville Syrjälä authored
The code for vlv and chv wm latency/function pointer setup is identical. Drop one of the copies. Signed-off-by:
-
Ville Syrjälä authored
Let's compute the maxfifo watermarks using max() instead of min(). Can't even recall why I did it the other way originally. Anyways using max() avoids having to initialize the watermarks to the max value first. Signed-off-by:
-
Ville Syrjälä authored
The watermark should never exceed the FIFO size, so we need to check against the current FIFO size instead of the theoretical maximum when we clamp the level 0 watermark. Signed-off-by:
-
Ville Syrjälä authored
ilk_disable_lp_wm() will tell us whether the LP1+ watermarks were disabled or not, and hence whether we need to for the vblank wait or not. Let's use that information to eliminate some useless vblank waits. Signed-off-by:
-
Ville Syrjälä authored
HSW+ all use the .initial_watermarks() hook, so there's no point in calling intel_update_watermarks() from HSW+ specific code. We'll still hang on to the .initial_watermarks NULL check since theoretically if the memory latencies are not populated we would not populate the function pointer either. Signed-off-by:
-
Dhinakaran Pandiyan authored
Not validating the mode rate against max. link rate results in not pruning invalid modes. For e.g, a HBR2 5.4 Gbps 2-lane configuration does not support 4k@60Hz. But, we do not reject this mode. So, make use of the helpers in intel_dp to validate mode data rate against max. link data rate of a configuration. v3: Renamed local variables again for consistency (Manasi) v2: Renamed mode data rate local variable to be more explanatory. Signed-off-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1479243546-17189-1-git-send-email-dhinakaran.pandiyan@intel.comSigned-off-by:
-
Dhinakaran Pandiyan authored
We store DP link rates as link clock frequencies in kHz, just like all other clock values. But, DP link rates in the DP Spec. are expressed in Gbps/lane, which seems to have led to some confusion. E.g., for HBR2 Max. data rate = 5.4 Gbps/lane x 4 lane x 8/10 x 1/8 = 2160000 kBps where, 8/10 is for channel encoding and 1/8 is for bit to Byte conversion Using link clock frequency, like we do Max. data rate = 540000 kHz * 4 lanes = 2160000 kSymbols/s Because, each symbol has 8 bit of data, this is 2160000 kBps and there is no need to account for channel encoding here. But, currently we do 540000 kHz * 4 lanes * (8/10) = 1728000 kBps Similarly, while computing the required link bandwidth for a mode, there is a mysterious 1/10 term. This should simply be pixel_clock kHz * (bpp/8) to give the final result in kBps v2: Changed to DIV_ROUND_UP() and comment changes (Ville) Signed-off-by:
-
Imre Deak authored
These char devices exposing the driver's I2C and DP-AUX adapters for user space tools are useful to debug display output related issues. Enable them with the rest of additional driver debug options. Suggested-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Daniel Vetter authored
Resync, and we need all the fancy new drm_mm stuff to implement more efficient evict algorithms for softpin. Signed-off-by:Daniel Vetter <daniel.vetter@intel.com>
-
Daniel Vetter authored
Signed-off-by:Daniel Vetter <daniel.vetter@ffwll.ch>
-
Dave Airlie authored
Linux 4.9-rc8 Daniel requested this so we could apply some follow on fixes cleanly to -next.
-
- 04 Dec, 2016 1 commit
-
-
Linus Torvalds authored
-
