- 09 Dec, 2016 1 commit
-
-
Robert Bragg authored
This adds a 'Perf' section to i915.rst with the following sub sections: - Overview - Comparison with Core Perf - i915 Driver Entry Points - i915 Perf Stream - i915 Perf Observation Architecture Stream - All i915 Perf Internals v2: section headers in i915.rst (Daniel Vetter) missing symbol docs + other fixups (Matthew Auld) Signed-off-by:Robert Bragg <robert@sixbynine.org> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161207214033.3581-1-robert@sixbynine.org
-
- 08 Dec, 2016 5 commits
-
-
Imre Deak authored
According to the previous patch, it's possible atm that we call intel_do_sagv_disable() only once during the 1ms period and time out if that call fails. As opposed to this the spec says that we need to keep retrying this request for a 1ms duration, so let's do this similarly to the CDCLK change notification request. v4-5: - Rebased on the reply_mask, reply change. v6: - Remove w/s change. (Lyude) - Rebased on the timeout_base argument change. Cc: Lyude <cpaul@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Fixes: 656d1b89 ("drm/i915/skl: Add support for the SAGV, fix underrun hangs") Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by: Lyude <lyude@redhat.com> (v4) Link: http://patchwork.freedesktop.org/patch/msgid/1480955258-26311-2-git-send-email-imre.deak@intel.com
-
Imre Deak authored
commit 848496e5 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Wed Jul 13 16:32:03 2016 +0300 drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on SKL increased the timeout to match the spec, but we still see a timeout on at least one SKL. A CDCLK change request following the failed one will succeed nevertheless. I could reproduce this problem easily by running kms_pipe_crc_basic in a loop. In all failure cases _wait_for() was pre-empted for >3ms and so in the worst case - when the pre-emption happened right after calculating timeout__ in _wait_for() - we called skl_cdclk_wait_for_pcu_ready() only once which failed and so _wait_for() timed out. As opposed to this the spec says to keep retrying the request for at most a 3ms period. To fix this send the first request explicitly to guarantee that there is 3ms between the first and last request. Though this matches the spec, I noticed that in rare cases this can still time out if we sent only a few requests (in the worst case 2) _and_ PCODE is busy for some reason even after a previous request and a 3ms delay. To work around this retry the polling with pre-emption disabled to maximize the number of requests. Also increase the timeout to 10ms to account for interrupts that could reduce the number of requests. With this change I couldn't trigger the problem. v2: - Use 1ms poll period instead of 10us. (Chris) v3: - Poll with pre-emption disabled to increase the number of request attempts. (Ville, Chris) - Factor out a helper to poll, it's also needed by the next patch. v4: - Pass reply_mask, reply to skl_pcode_request(), instead of assuming the reply is generic. (Ville) v5: - List the request specific timeout values as code comment. (Ville) v6: - Try the poll first with preemption enabled. - Add code comment about first request being queued by PCODE. (Art) - Add timeout_base_ms argument. (Ville) v7: - Clarify code comment about first queued request. (Chris) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Art Runyan <arthur.j.runyan@intel.com> Cc: <stable@vger.kernel.org> # v4.2- : 3b2c1710 : drm/i915: Wait up to 3ms Cc: <stable@vger.kernel.org> # v4.2- Fixes: 5d96d8af ("drm/i915/skl: Deinit/init the display at suspend/resume") Reference: https://bugs.freedesktop.org/show_bug.cgi?id=97929 Testcase: igt/kms_pipe_crc_basic/suspend-read-crc-pipe-B Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1480955258-26311-1-git-send-email-imre.deak@intel.com
-
Tvrtko Ursulin authored
Now that it is available we don't have to open code a similar error message ourselves. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
-
Tvrtko Ursulin authored
Replace INTEL_ERR_OR_DBG_KMS macro with an intel_err_or_dbg_kms function to shrink the code and rodata strings. text data bss dec hex filename 1271480 41831 2016 1315327 1411ff i915.ko.0 1265160 41831 2016 1309007 13f94f i915.ko.2 Total of ~6 KiB saving across text and strings. v2: * Annotate the function for printf-style checking. * Rename to pipe_config_err. (Chris Wilson) Signed-off-by:
-
Joonas Lahtinen authored
Add WARN_ON to find_fw_domain to registers related to uninitialized hardware. v2: - Print the uninitialized domains and register (Chris) Cc: Imre Deak <imre.deak@intel.com> Cc: Wang Elaine <elaine.wang@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by:
-
- 07 Dec, 2016 19 commits
-
-
Jani Nikula authored
Pineview deserves to use its own platform enum (which was already added, unused, previously). IS_G33() no longer matches Pineview, and gets replaced by IS_G33() || IS_PINEVIEW() or equivalent. Pineview is no longer an outlier among platform definitions. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1481143689-19672-1-git-send-email-jani.nikula@intel.com
-
Mahesh Kumar authored
This patch Adds a function to extract intel_crtc_state from the atomic_state, if not available it returns NULL. v2 (from Paulo): - Fix white space problem detected by checkpatch. Signed-off-by:
Mahesh Kumar <mahesh1.kumar@intel.com> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Mahesh Kumar authored
This patch changes Watermak calculation to fixed point calculation. Problem with current calculation is during plane_blocks_per_line calculation we divide intermediate blocks with min_scanlines and takes floor of the result because of integer operation. hence we end-up assigning less blocks than required. Which leads to flickers. Changes since V1: - Add fixed point data type as per Paulo's review Changes since V2: - use fixed_point instead of fp_16_16 Changes since V3: - rebase Changes since V4 (from Paulo): - My original renaming suggestion was misunderstood, so implement it - Simplify fixed_16_16_to_u32 implementation - Fix indentation Reviewed-by:
-
Mahesh Kumar authored
Display Workarounds #1141 IPC (Isoch Priority Control) may cause underflows. KBL WA: When IPC is enabled, watermark latency values must be increased by 4us across all levels. This brings level 0 up to 6us. Changes since V1: - Add Workaround number in commit & code Changes since V2 (from Paulo): - Bikeshed the WA tag so it looks like the others Reviewed-by:
-
Mahesh Kumar authored
Display Workarounds #1135 If IPC is enabled in BXT, display underruns are observed. WA: The Line Time programmed in the WM_LINETIME register should be half of the actual calculated Line Time. Programmed Line Time = 1/2*Calculated Line Time Changes since V1: - Add Workaround number in commit & code Changes since V2 (from Paulo): - Bikeshed white space and make the WA tag look like the others Reviewed-by:
-
Mahesh Kumar authored
This patch adds variable to check for X_tiled & y_tiled planes, instead of always checking against framebuffer-modifiers. Changes: - Created separate patch as per Paulo's comment - Added x_tiled variable as well Changes since V2: - Incorporate Paulo's comments - Rebase Changes since V3 (from Paulo): - Bikeshed indentation Reviewed-by:
-
Hans de Goede authored
Set the CHV_GPIO_GPIOEN bit when updating GPIOs from chv_exec_gpio. Fixes: a0a6d4ff ("drm/i915/dsi: add support for gpio elements on CHV") Cc: stable@vger.kernel.org Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
-
Hans de Goede authored
Looking at the ADF code from the Android kernel sources for a cherrytrail tablet I noticed that it is calling the MIPI_SEQ_ASSERT_RESET sequence from the panel prepare hook. Until commit b1cb1bd2 ("drm/i915/dsi: update reset and power sequences in panel prepare/unprepare hooks") the mainline i915 code was doing the same. That commits effectively swaps the calling of MIPI_SEQ_ASSERT_RESET / MIPI_SEQ_DEASSERT_RESET. Looking at the naming of the sequences that is the right thing to do, but the problem is, that the old mainline code and the ADF code was actually calling the right sequence (tested on a cube iwork8 air tablet), and the swapping of the calling breaks things. This breakage was likely not noticed in testing because on cherrytrail, currently chv_exec_gpio ends up disabling the gpio pins rather then setting them (this is fixed in the next patch in this patch-set). This commit fixes the swapping by fixing MIPI_SEQ_ASSERT/DEASSERT_RESET's places in the enum defining them, so that their (new) names match their actual use. Changes in v2: -Add a comment to the enum explaining that the assert/reassert names are swapped in the spec Fixes: b1cb1bd2 ("drm/i915/dsi: update reset and power sequences...") Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Robert Bragg authored
Avoid using DRM_ERROR for conditions userspace can trigger with a bad config when opening a stream or from not reading data in a timely fashion (whereby the OA buffer fills up). These conditions are tested by i-g-t which treats error messages as failures if using the test runner. This wasn't an issue while the i915-perf igt tests were being run in isolation. One message relating to seeing a spurious zeroed report was changed to use DRM_NOTE instead of DRM_ERROR. Ideally this warning shouldn't be seen, but it's not a serious problem if it is. Considering that the tail margin mechanism is only a heuristic it's possible we might see this from time to time. Signed-off-by: Robert Bragg <robert@sixbynine.org: Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
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:
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:
-
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:
-
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:
-
- 05 Dec, 2016 14 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:
-
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:
-
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:
-
