- 06 Jan, 2016 7 commits
-
-
Maarten Lankhorst authored
This prevents a unnecessary modeset on a dell XPS 13 (2016). N is always a power of 2, which means that for fuzzy matching we should compare for inequality on the n values, then do fuzzy matching on the m values. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Tested-by:
Kenneth Graunke <kenneth@whitecape.org> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/568D0E93.304@linux.intel.com
-
Matt Roper authored
Although we can do a good job of reading out hardware state, the graphics firmware may have programmed the watermarks in a creative way that doesn't match how i915 would have chosen to program them. We shouldn't trust the firmware's watermark programming, but should rather re-calculate how we think WM's should be programmed and then shove those values into the hardware. We can do this pretty easily by creating a dummy top-level state, running it through the check process to calculate all the values, and then just programming the watermarks for each CRTC. v2: Move watermark sanitization after our BIOS fb reconstruction; the watermark calculations that we do here need to look at pstate->fb, which isn't setup yet in intel_modeset_setup_hw_state(), even though we have an enabled & visible plane. v3: - Don't move 'active = optimal' watermark assignment; we just undo that change in the next patch anyway. (Ville) - Move atomic helper locking fix to separate patch. (Maarten) v4: - Grab connection_mutex before calling atomic helper to duplicate state. The connector loop inside the helper will throw a WARN if we don't hold something to protect the connector list (and the helper itself doesn't try to lock the list). - Make failure to calculate watermarks for inherited state a WARN() since it probably indicates a serious problem in either our state readout code or our watermark code for this platform. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Matt Roper authored
Our low-level watermark calculation functions don't get called when the CRTC is disabled or the relevant plane is invisible, so they should never see a zero htotal or zero bpp. However add some checks to ensure this is true so that we don't wind up dividing by zero if we make a mistake elsewhere in the driver (which the atomic watermark series has revealed we might be). References: http://lists.freedesktop.org/archives/intel-gfx/2015-October/077370.htmlSigned-off-by:
-
Matt Roper authored
When watermark calculation was moved up to the atomic check phase, the code was updated to calculate based on in-flight atomic state rather than already-committed state. However the hsw_compute_linetime_wm() didn't get updated and continued to pull values out of the currently-committed CRTC state. On platforms that call this function (HSW/BDW only), this will cause problems when we go to enable the CRTC since we'll pull the current mode (off) rather than the mode we're calculating for and wind up with a divide by zero error. This was an oversight in commit: commit a28170f3 Author: Matt Roper <matthew.d.roper@intel.com> Date: Thu Sep 24 15:53:16 2015 -0700 drm/i915: Calculate ILK-style watermarks during atomic check (v3) Signed-off-by: -
Matt Roper authored
Plane state objects contain two copies of src/dest coordinates: the original (requested by userspace) coordinates in the base drm_plane_state object, and a second, clipped copy (i.e., what we actually want to program to the hardware) in intel_plane_state. We've only been setting up the former set of values during boot time FB reconstruction, but we should really be initializing both. Note that the code here probably still needs some more work since we make a lot of assumptions about how the BIOS programmed the hardware that may not always be true, especially on gen9+; e.g., * Primary plane might not be positioned at 0,0 * Primary plane could have been rotated by the BIOS * Primary plane might be scaled * The BIOS fb might be a single "extended mode" FB that spans multiple displays. * ...etc... v2: Reword/expand commit message description of assumptions we make Signed-off-by:
-
Chris Wilson authored
Following a GPU reset, we may leave the context in a poorly defined state, and reloading from that context will leave the GPU flummoxed. For secondary contexts, this will lead to that context being banned - but currently it is also causing the default context to become banned, leading to turmoil in the shared state. This is a regression from commit 6702cf16 [v4.1] Author: Ben Widawsky <benjamin.widawsky@intel.com> Date: Mon Mar 16 16:00:58 2015 +0000 drm/i915: Initialize all contexts which quietly introduced the removal of the MI_RESTORE_INHIBIT on the default context. v2: Mark the global default context as uninitialized on GPU reset so that the context-local workarounds are reloaded upon re-enabling. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1448630935-27377-1-git-send-email-chris@chris-wilson.co.ukReviewed-by:
Mika Kuoppala <mika.kuoppala@intel.com> Cc: stable@vger.kernel.org [danvet: This seems to fix a gpu hand on after the first resume, resulting in any future suspend operation failing with -EIO because the gpu seems to be in a funky state. Somehow this patch fixes that.] Signed-off-by:
-
Daniel Vetter authored
They're causing massive amounts of dmesg noise and hence CI noise all over the place. Enabling them for a bit was good enough to refresh our task list of what's still needed to enable rpm by default. To make sure we're not forgetting to make this noisy again add a FIXME comment. Fixes: da5827c3 ("drm/i915: add assert_rpm_wakelock_held helper") Cc: Imre Deak <imre.deak@intel.com> Cc: drm-intel-fixes@lists.freedesktop.org Cc: Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Daniel Vetter <daniel.vetter@intel.com>
-
- 05 Jan, 2016 18 commits
-
-
Ankitprasad Sharma authored
i915_gem_object_get_dma_address function is used to retrieve the dma address of a particular page so as to map it in a given GTT entry for CPU access. This function would be used for stolen backed objects also for tasks like pwrite, clearing of the pages etc. So the obj->get_page.sg needs to be initialized for the stolen objects also. Signed-off-by:
Ankitprasad Sharma <ankitprasad.r.sharma@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450765253-32104-2-git-send-email-ankitprasad.r.sharma@intel.comReviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
-
Dave Gordon authored
This function was recently renamed & exposed, so now it gets documented Signed-off-by:
Dave Gordon <david.s.gordon@intel.com> Signed-off-by:
-
Jani Nikula authored
Untie the VBT based generic panel driver from the VBT parsing, so that the two don't have to be updated in lockstep. Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/01c71ac89a9db8bc7b8ae0fb05c50a5fae362dc4.1450702954.git.jani.nikula@intel.com
-
Jani Nikula authored
Untie the VBT based generic panel driver from the VBT parsing, so that the two don't have to be updated in lockstep. Reviewed-by:
-
Jani Nikula authored
Make everything a bit more readable and clear. Reviewed-by:
-
Jani Nikula authored
Make the whole thing easier to read. While at it, make the parsing more robust, and ensure we don't read past buffer being parsed. v2: improve commit message (Daniel) Reviewed-by:
-
Jani Nikula authored
Have get_blocksize() support the special case of MIPI sequence block v3+ which has a separate field for size. Provide and use abstractions for getting the blocksize given a pointer to the block "envelope", i.e. pointer to the block id, and given a pointer to the block payload data. Reviewed-by:
-
Jani Nikula authored
There's two blocks to parse, have one function per block. The existing one cuts neatly into two. Reviewed-by:
-
Jani Nikula authored
Just for OCD. Reviewed-by:
-
Alex Dai authored
Set ADS enabling flag during GuC init. Signed-off-by:
Alex Dai <yu.dai@intel.com> Reviewed-by:
-
Alex Dai authored
GuC needs to know which registers and how they will be saved and restored during event such as engine reset or power state changes. For now only the base address of reg state is initialized. The detail register table probably will be setup in future GuC TDR or Preemption patch series. Signed-off-by:
-
Alex Dai authored
GuC supports different scheduling policies for its four internal queues. Currently these have been set to the same default values as KMD_NORMAL queue. Particularly POLICY_MAX_NUM_WI is set to 15 to match GuC internal maximum submit queue numbers to avoid an out-of-space problem. This value indicates max number of work items allowed to be queued for one DPC process. A smaller value will let GuC schedule more frequently while a larger number may increase chances to optimize cmds (such as collapse cmds from same lrc) with risks that keeps CS idle. v1: tidy up code Signed-off-by:
-
Alex Dai authored
The GuC firmware uses this for various purposes. The ADS itself is a chunk of memory created by driver to share with GuC. Its members are usually addresses telling where GuC to access them, including things like scheduler policies, register list that will be saved and restored during reset etc. This is the first patch of a series to enable GuC ADS. For now, we only create the ADS obj whilst keep it disabled. v1: remove dead code checking return of kmap_atomic (Chris Wilson) v2: use kmap instead of the atomic version of it. Signed-off-by:
-
Dave Gordon authored
The GuC code needs to know the size of a logical context, so we expose get_lr_context_size(), renaming it intel_lr_context__size() to fit the naming conventions for nonstatic functions. For: VIZ-2021 Signed-off-by:
-
Alex Dai authored
Split GuC work queue space checking from submission and move it to ring_alloc_request_extras. The reason is that failure in later i915_add_request() won't be handled. In the case timeout happens, driver can return early in order to handle the error. v1: Move wq_reserve_space to ring_reserve_space v2: Move wq_reserve_space to alloc_request_extras (Chris Wilson) v3: The work queue head pointer is cached by driver now. So we can quickly return if space is available. s/reserve/check/g (Dave Gordon) v4: Update cached wq head after ring doorbell; check wq space before ring doorbell in case unexpected error happens; call wq space check only when GuC submission is enabled. (Dave Gordon) Signed-off-by: -
Chris Wilson authored
If the system has no available swap pages, we cannot make forward progress in the shrinker by releasing active pages, only by releasing purgeable pages which are immediately reaped. Take total_swap_pages into account when counting up available objects to be shrunk and subsequently shrinking them. By doing so, we avoid unbinding objects that cannot be shrunk and so wasting CPU cycles flushing those objects from the GPU to the system and then immediately back again (as they will more than likely be reused shortly after). Based on a patch by Akash Goel. v2: frontswap registers extra swap pages available for the system, so it is already include in the count of available swap pages. v3: Use get_nr_swap_pages() to query the currently available amount of swap space. This should also stop us from shrinking the GPU buffers if we ever run out of swap space. Though at that point, we would expect the oom-notifier to be running and failing miserably... Reported-by:
Akash Goel <akash.goel@intel.com> Signed-off-by:
Johannes Weiner <hannes@cmpxchg.org> Signed-off-by:
-
Chris Wilson authored
Some modules, like i915.ko, use swappable objects and may try to swap them out under memory pressure (via the shrinker). Before doing so, they want to check using get_nr_swap_pages() to see if any swap space is available as otherwise they will waste time purging the object from the device without recovering any memory for the system. This requires the nr_swap_pages counter to be exported to the modules. Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Acked-by:
-
Michał Winiarski authored
According to PRM, some parts of HW require the addresses to be in a canonical form, where bits [63:48] == [47]. Let's convert addresses to canonical form prior to relocating and return converted offsets to userspace. We also need to make sure that userspace is using addresses in canonical form in case of softpin. v2: Whitespace fixup, gen8_canonical_addr description (Chris, Ville) v3: Rebase on top of softpin, fix a hole in relocate_entry, s/expect/require (Chris) v4: Handle softpin in validate_exec_list (Chris) v5: Convert back to canonical form at copy_to_user time (Chris) v6: Don't use struct exec_object2 in place of exec_object v7: Use sign_extend64 for converting to canonical form (Joonas), reject non-canonical and non-page-aligned offset for softpin (Chris) v8: Convert back to non-canonical form in a function, split the test for EXEC_OBJECT_PINNED (Chris) v9: s/canonial/canonical, drop accidental double newline (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:Michał Winiarski <michal.winiarski@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1451409892-13708-1-git-send-email-michal.winiarski@intel.com Testcase: igt/gem_bad_reloc/negative-reloc-blt Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92699 Cc: drm-intel-fixes@lists.freedesktop.org Reviewed-by:
-
- 04 Jan, 2016 1 commit
-
-
Insu Yun authored
Since devm_kzalloc can be failed, it needs to be checked if not, NULL dereference could be happened. Signed-off-by:
Insu Yun <wuninsu@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/1451491169-35068-1-git-send-email-wuninsu@gmail.comSigned-off-by:
-
- 30 Dec, 2015 1 commit
-
-
Ben Widawsky authored
Signed-off-by:
Ben Widawsky <benjamin.widawsky@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1451427643-7266-1-git-send-email-benjamin.widawsky@intel.comSigned-off-by:
-
- 23 Dec, 2015 1 commit
-
-
Gary Wang authored
The total delay of HDMI hotplug detecting with 30ms is sometimes not enoughtfor HDMI live status up with specific HDMI monitors in BSW platform. After doing experiments for following monitors, it needs 80ms at least for those worst cases. Lenovo L246 1xwA (4 failed, necessary hot-plug delay: 58/40/60/40ms) Philips HH2AP (9 failed, necessary hot-plug delay: 80/50/50/60/46/40/58/58/39ms) BENQ ET-0035-N (6 failed, necessary hot-plug delay: 60/50/50/80/80/40ms) DELL U2713HM (2 failed, necessary hot-plug delay: 58/59ms) HP HP-LP2475w (5 failed, necessary hot-plug delay: 70/50/40/60/40ms) It looks like 70-80 ms is BSW platform needs in some bad cases of the monitors at this end (8 times delay at most). Keep less than 100ms for HDCP pulse HPD low (with at least 100ms) to respond a plug out. Reviewed-by:
Cooper Chiou <cooper.chiou@intel.com> Tested-by:
Gary Wang <gary.c.wang@intel.com> Cc: Gavin Hindman <gavin.hindman@intel.com> Cc: Sonika Jindal <sonika.jindal@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by:
Shobhit Kumar <shobhit.kumar@intel.com> Cc: drm-intel-fixes@lists.freedesktop.org Fixes: 237ed86c ("drm/i915: Check live status before reading edid") Signed-off-by:
-
- 22 Dec, 2015 8 commits
-
-
Maarten Lankhorst authored
When the crtc is configured but not active we currently clip to (0,0)x(0,0). This results in differences in calculations depending on dpms setting. When the crtc is enabled but not active run check_plane as if it were on, but afterwards set plane_state->visible = false for the checks. Signed-off-by:
Mika Kahola <mika.kahola@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447945645-32005-13-git-send-email-maarten.lankhorst@linux.intel.com
-
Maarten Lankhorst authored
On skylake when calculating plane visibility with the crtc in dpms off mode the real cdclk may be different from what it would be if the crtc was active. This may result in a WARN_ON(cdclk < crtc_clock) from skl_max_scale. The fix is to keep a atomic_cdclk that would be true if all crtc's were active. This is required to get the same calculations done correctly regardless of dpms mode. Signed-off-by:
-
Maarten Lankhorst authored
Parallel modesets are still not allowed, but this will allow updating a different crtc during a modeset if the clock is not changed. Additionally when all pipes are DPMS off the cdclk will be lowered to the minimum allowed. Changes since v1: - Add dev_priv->active_crtcs for tracking which crtcs are active. - Rename min_cdclk to min_pixclk and move to dev_priv. - Add a active_crtcs mask which is updated atomically. - Add intel_atomic_state->modeset which is set on modesets. - Commit new pixclk/active_crtcs right after state swap. Changes since v2: - Make the changes related to max_pixel_rate calculations more readable. Changes since v3: - Add cherryview and missing WARN_ON to readout. Signed-off-by:
-
Maarten Lankhorst authored
This fixes a warning when the crtc is turned off. In that case fb will be NULL, and crtc_clock will be 0. Because the crtc is no longer active this is not a bug, and shouldn't trigger the WARN_ON. Also remove handling a null crtc_state, with all transitional helpers gone this can no longer happen. Signed-off-by:
-
Jani Nikula authored
Add an overview and documentation for the VBT/BDB header structures. Acked-by:
-
Ville Syrjälä authored
Atomic changes broke check_digital_port_conflicts(). It needs to look at the global situation instead of just trying to find a conflict within the current atomic state. This bug made my HSW explode spectacularly after I had split the DDI encoders into separate DP and HDMI encoders. With the fix, things seem much more solid. I hope holding the connection_mutex is enough protection that we can actually walk the connectors even if they're not part of the current atomic state... v2: Regenerate the patch so that it actually applies (Jani) Cc: stable@vger.kernel.org Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Fixes: 5448a00d ("drm/i915: Don't use staged config in check_digital_port_conflicts()") Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Joonas Lahtinen authored
Using __stringify(x) instead of #x adds support for macros as a parameter and compile-time concatenation reduces the runtime overhead. Slightly increases the .text size but should not matter. v2: - Define I915_STATE_WARN_ON though I915_STATE_WARN (Bikeshed inspiration by Chris) v3: - More specific commit message v4: - Do not directly pass arbitary string as format, instead guard with "%s" (Dave) Cc: Rob Clark <robdclark@gmail.com> Cc: Dave Gordon <david.s.gordon@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v3) Acked-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450441647-23924-3-git-send-email-joonas.lahtinen@linux.intel.comSigned-off-by:
-
Joonas Lahtinen authored
Take advantage of WARN return value to simplify the flow. Cc: Rob Clark <robdclark@gmail.com> Reviewed-by:
-
- 21 Dec, 2015 4 commits
-
-
Lukas Wunner authored
Clean up after 0c82312f ("drm/i915: Pin the ifbdev for the info->system_base GGTT mmapping"): At each of the remaining "goto out" in intelfb_alloc(), fb can only be either an ERR_PTR or NULL, so the call to drm_framebuffer_unreference() is now obsolete. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Lukas Wunner <lukas@wunner.de> Link: http://patchwork.freedesktop.org/patch/msgid/56756c41.c306c20a.d0602.1830SMTPIN_ADDED_MISSING@mx.google.comReviewed-by:
-
Ville Syrjälä authored
Turns out CHV pipe C was glued on somewhat poorly, and there's something wrong with the cursor. If the cursor straddles the left screen edge, and is then moved away from the edge or disabled, the pipe will often underrun. If enough underruns are triggered quickly enough the pipe will fall over and die (it just scans out a solid color and reports a constant underrun). We need to turn the disp2d power well off and on again to recover the pipe. None of that is very nice for the user, so let's just refuse to place the cursor in the compromised position. The ddx appears to fall back to swcursor when the ioctl returns an error, so theoretically there's no loss of functionality for the user (discounting swcursor bugs). I suppose most cursors images actually have the hotspot not exactly at 0,0 so under typical conditions the fallback will in fact kick in as soon as the cursor touches the left edge of the screen. Any atomic compositor should anyway be prepared to fall back to GPU composition when things don't work out, so there should be no problem with those. Other things that I tried to solve this include flipping all display related clock gating knobs I could find, increasing the minimum gtt alignment all the way up to 512k. I also tried to see if there are more specific screen coordinates that hit the bug, but the findings were somewhat inconclusive. Sometimes the failures happen almost across the whole left edge, sometimes more at the very top and around the bottom half. I wasn't able to find any real pattern to these variations, so it seems our only choice is to just refuse to straddle the left screen edge at all. Cc: stable@vger.kernel.org Cc: Jason Plum <max@warheads.net> Testcase: igt/kms_chv_cursor_fail Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92826Signed-off-by:
-
Joonas Lahtinen authored
Move all the bool variables to the end as per the comment. Reviewed-by:
-
Joonas Lahtinen authored
Otherwise usage in the i915 debug macros yields problems due to i915_drv.h <-> i915_trace.h <-> intel_drv.h include loops. v2: - Document not-so-obvious need for linux/cache.h (Chris) Reviewed-by:
-
