- 11 Jan, 2016 5 commits
-
-
Jani Nikula authored
Properly parse the new sequences added in MIPI sequence block v2. 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/cc1551bdfc4392d02413b78179f3a65c786c75ab.1450702954.git.jani.nikula@intel.com
-
Jani Nikula authored
Add parsing of the i2c element, defined in MIPI sequence block v2. Drop the status operation byte while at it, that does not exist. Reviewed-by:
-
Mika Kuoppala authored
If we go into suspend with unclaimed access detected, it would be nice to catch that access on a next suspend path. So instead of just notifying about it, arm the unclaimed mmio checks on suspend side. We want to keep the asymmetry on resume, as if it was on resume path, it was not driver that is responsible so no point in arming mmio debugs. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1452261080-6979-2-git-send-email-mika.kuoppala@intel.com
-
Mika Kuoppala authored
With commit 8ac3e1bb ("drm/i915: Add non claimed mmio checking for vlv/chv") we now have chv/vlv support in place for detecting unclaimed access. Also the perf hit of extra mmio read is now only suffered if mmio_debug is set. This allows us to stuff the macro for unclaimed reg detection inside a generic gen6 register access, as now all gens using these macros uses also unclaimed debugs, the one exception being snb. We gain more clean and generic macros and only downside is that snb will suffer one branch perf hit without upside. Note that the hsw write path debug register check now happens before fifo check, but this should not make any real difference. As vlv/chv use the generic gen6 access macros, the consequence is that they gain the mmio_debug feature. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Maarten Lankhorst authored
This fixes a spurious warning from an integer overflow on 64-bits systems. The function may return MAX_SCHEDULE_TIMEOUT which gets truncated to -1. Explicitly handling this by casting to lret fixes it. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reported-and-tested-by:
Joseph Yasi <joe.yasi@gmail.com> Tested-by:
Andreas Reis <andreas.reis@gmail.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Cc: drm-intel-fixes@lists.freedesktop.org Fixes: 3c28ff22 ("i915: wait for fence in prepare_plane_fb") Link: http://patchwork.freedesktop.org/patch/msgid/5666EEC8.2000403@linux.intel.com
-
- 10 Jan, 2016 1 commit
-
-
Daniel Vetter authored
Signed-off-by:
-
- 08 Jan, 2016 11 commits
-
-
Boyer, Wayne authored
Extend the same reasoning as in the patch listed below. It's not an error for the workaround list to be empty if no workarounds are needed. commit 02235808 Author: Francisco Jerez <currojerez@riseup.net> Date: Wed Oct 7 14:44:01 2015 +0300 drm/i915: Don't warn if the workaround list is empty. Signed-off-by:Wayne Boyer <wayne.boyer@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1452129330-3484-2-git-send-email-rodrigo.vivi@intel.com
-
Rodrigo Vivi authored
When adding IS_KABYLAKE definition I didn't included the DC states related because I was planing to include them with the patch that fixes DMC firmware loading, but I forgot them. Meanwhile this runtime pm code changed a lot for Skylake. Well, I didn't expect that this would crash the machine and I just noticed now that Sarah warned me our driver wasn't working. Thanks Sarah. Michel had found the main error first and his fix had better details on the history and got merged already: commit 16fbc291 Author: Michel Thierry <michel.thierry@intel.com> Date: Wed Jan 6 12:08:36 2016 +0000 drm/i915/kbl: Enable PW1 and Misc I/O power wells This one is a follow-up adding the other remaining missing pieces. v2: Rebased on top of Michel's patch as explained above. Cc: Sarah Sharp <sarah.a.sharp@intel.com> Signed-off-by:
Michel Thierry <michel.thierry@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1452214179-22361-1-git-send-email-rodrigo.vivi@intel.com
-
Jani Nikula authored
The dsi_rr_formula() function has been unused for almost two years, since commit 44d4c6ee Author: Shobhit Kumar <shobhit.kumar@intel.com> Date: Tue Dec 10 12:14:56 2013 +0530 drm/i915: Compute dsi_clk from pixel clock citing the reason as pixel clock based calculation being recommended in the MIPI host controller documentation. Remove the dead code, we can always bring it back if it's needed. Reviewed-by:
-
Jani Nikula authored
Hide away the platform differences in intel_dsi_get_pckl() within intel_dsi_pll.c. No functional changes. Reviewed-by:
-
Mika Kuoppala authored
Imre mentioned that chv might also have capability to track unclaimed mmio accesses. Ville added that both chv and vlv has this capability and he had already made this way back [1]. Mimic what Ville's patch does but adapt on top of less frequent mmio accesses by omitting checking always on reg writes. This patch is untested as of now. v2: overflow handling and posting omitted (Ville) References: [1] http://lists.freedesktop.org/archives/intel-gfx/2013-May/027599.html Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Mika Kuoppala authored
Remove char* assignments and add branching hint and also constify the parameters. This results in a 35 bytes shorter fast path, so author boldly assumes it helps without doing in-depth assembly analysis. v2: use WARN's branching (Chris), commit name (Joonas) Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Mika Kuoppala authored
We have done unclaimed register access check in normal (mmio_debug=0) mode once per write. This adds probability of finding the exact sequence where we did the bad access, but also adds burden to each write. As we have mmio_debug available for more fine grained analysis, give up accuracy of detecting correct spot at the first occurrence by doing the one shot detection and arming of mmio_debug in hangcheck and in modeset. This removes the write path performance burden. v2: Remove gratuitous DRM_DEBUG and return value, comments (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by:
-
Mika Kuoppala authored
If something, the usual suspect being bios, access hw behind our back, don't let it slide into situation where normal register access will detect this and spit out a warn on into dmesg. On some bdw bioses this happens during igt/bat run always and as there is not much we can do about it, its better just to detect and flush this explicitly on resume and only print a debug message. v2: use DRM_DEBUG_DRIVER (Chris) v3: s/access/mmio, s/prior/prior to, s/dev/dev_priv Testcase: igt/pm_rpm/basic-rte Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Paulo Zanoni <przanoni@gmail.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by:
-
Mika Kuoppala authored
Currently interrupt code is the only place checking for the unclaimed register access prior to actual register macros using the same functionality. Rename the function and make it return bool so that the possible error message context is clear in the caller side. The motivation is to allow usage of unclaimed detection on arbitrary places. v2: rebase, s/access/mmio, s/dev/dev_priv Reviewed-by:
-
Mika Kuoppala authored
Access the unclaimed reg detection register through one helper which also does cleanup. Note that we now access the register only if the platform has the actual non claimed access bit. This prevents reading the register with gens that doesn't have the register or the unclaimed bit, when debug_mmio > 0. Note that we post after clearing the bit. This makes sure that the next unclaimed write access would get detected also if it happened right after clearing, and not fold into the previous detection. v2: s/unclaimed_reg_access/check_for_unclaimed_mmio (Chris) debug log on unclaimed detection on uncore init (Joonas) v3: remove posting read (Ville) Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by: -
Mika Kuoppala authored
If head seems stuck and engine in question is rcs, inspect subunit state transitions from undone to done, before deciding that this really is a hang instead of limited progress. Only account the transitions of subunits from undone to done once, to prevent unstable subunit states to keep us falsely active. As this adds one extra steps to hangcheck heuristics, before hang is declared, it adds 1500ms to to detect hang for render ring to a total of 7500ms. We could sample the subunit states on first head stuck condition but decide not to do so only in order to mimic old behaviour. This way the check order of promotion from seqno > atchd > instdone is consistently done. v2: Deal with unstable done states (Arun) Clear instdone progress on head and seqno movement (Chris) Report raw and accumulated instdone's in in debugfs (Chris) Return HANGCHECK_ACTIVE on undone->done References: https://bugs.freedesktop.org/show_bug.cgi?id=93029 Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Dave Gordon <david.s.gordon@intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Arun Siluvery <arun.siluvery@linux.intel.com> Reviewed-by:
-
- 07 Jan, 2016 17 commits
-
-
Rodrigo Vivi authored
No functional changes. That state the obvious and just duplicate the place we need to change whenever the table is updated. So let's clean it. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Rodrigo Vivi authored
When reviewing DDI translation table I noticed few changes we haven't incorporated yet and it is always good to follow latest spec. Signed-off-by:
-
Rodrigo Vivi authored
When debuging an intermittent corrupted screen I suspected on DDI translation table and checked we are out of date with the spec. I'm not sure this will fix my bug yet, but it is always good to follow the spec. v2: Ville caught a switched i-boost value. Thanks! Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Lyude authored
This fixes reprobing of display connectors on resume. After some talking with danvet on IRC, I learned that calling drm_helper_hpd_irq_event() does actually trigger a full reprobe of each connector's status. It turns out this is the actual reason reprobing on resume hasn't been working (this was observed on a T440s): - We call hpd_init() - We check each connector for a couple of things before marking connector->polled with DRM_CONNECTOR_POLL_HPD, one of which is an active encoder. Of course, a disconnected port won't have an active encoder, so we don't add the flag to any of the connectors. - We call drm_helper_hpd_irq_event() - drm_helper_irq_event() checks each connector for the DRM_CONNECTOR_POLL_HPD flag. The only one that has it is eDP-1, so we skip reprobing each connector except that one. In addition, we also now avoid setting connector->polled to DRM_CONNECTOR_POLL_HPD for MST connectors, since their reprobing is handled by the mst helpers. This is probably what was originally intended to happen here. Changes since V1: * Use the explanation of the issue as the commit message instead * Change the title of the commit, since this does more then just stop a check for an encoder now * Add "Fixes" line for the patch that introduced this regression * Don't enable DRM_CONNECTOR_POLL_HPD for mst connectors Changes since V2: * Put patch changelog above Signed-off-by * Follow Daniel Vetter's suggestion for making the code here a bit more legible Fixes: 0e32b39c ("drm/i915: add DP 1.2 MST support (v0.7)") Cc: stable@vger.kernel.org Signed-off-by:
Lyude <cpaul@redhat.com> Link: http://patchwork.freedesktop.org/patch/msgid/1452181408-14777-1-git-send-email-cpaul@redhat.comSigned-off-by:
-
Ben Widawsky authored
This is a useful thing to have around as a function because the mechanism may change in the future. There is a net increase in LOC here, and it will continue to be the case on GEN8 and GEN9 - but future GENs may have an alternate mechanism for doing this. Signed-off-by:
Ben Widawsky <benjamin.widawsky@intel.com> Reviewed-by:
-
Ben Widawsky authored
There is no point in emitting a WARN since the backtrace will always be the same. Errors have actually become easier to spot given the large number of WARNs which exist today in modesetting paths. Signed-off-by:
-
Ben Widawsky authored
I think this patch is a worthwhile cleanup even if it might look only marginally useful. It gets more useful in upcoming patches and for handling of future GEN platforms. The only non-mechanical part of this is the removal of the extra & operation on the ring->next_context_status_buffer. This is safe because right above this, we already did a modulus operation. Signed-off-by:
-
Michel Thierry authored
My kbl stopped working because of this. Fixes regression from commit 2f693e28 Author: Damien Lespiau <damien.lespiau@intel.com> Date: Wed Nov 4 19:24:12 2015 +0200 drm/i915: Make turning on/off PW1 and Misc I/O part of the init/fini sequences Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Maarten Lankhorst authored
With sprites, cursors and primary planes taking the atomic state this is now unused. It's removed in a separate commit to allow a revert. Signed-off-by:
-
Maarten Lankhorst authored
Pass in the atomic states to allow for proper updates. This removes uses of intel_crtc->config and direct access to plane->state. This breaks the last bit of kgdboc, but that appears to be dead code. Signed-off-by:
-
Maarten Lankhorst authored
Cursor planes grab the state from plane->state instead of the state that was passed. The only updates are atomic now, so use the plane_state that's passed in. Signed-off-by:
-
Maarten Lankhorst authored
Update cursor_addr when disable_plane is called. This is required to make commit_cursor_plane take a crtc_state and a plane_state. Signed-off-by:
-
Maarten Lankhorst authored
This is duplicated with intel_check_cursor_plane, and with all non-atomic paths removed this should be dead code. Signed-off-by:
-
Maarten Lankhorst authored
Use update_plane and disable_plane directly. Signed-off-by:
-
Maarten Lankhorst authored
Don't use plane->state directly, use the pointer from commit_plane. Changes since v1: - Fix uses of plane->state->rotation and color key to use the passed state too. - Only pass crtc_state and plane_state to update_plane. Changes since v2: - Rebased. Changes since v3: - Small whitespace changes and only assign 1 variable per line. - Constify plane_state and crtc_state. (vsyrjala) Signed-off-by:
-
Matt Roper authored
In addition to calculating final watermarks, let's also pre-calculate a set of intermediate watermark values at atomic check time. These intermediate watermarks are a combination of the watermarks for the old state and the new state; they should satisfy the requirements of both states which means they can be programmed immediately when we commit the atomic state (without waiting for a vblank). Once the vblank does happen, we can then re-program watermarks to the more optimal final value. v2: Significant rebasing/rewriting. v3: - Move 'need_postvbl_update' flag to CRTC state (Daniel) - Don't forget to check intermediate watermark values for validity (Maarten) - Don't due async watermark optimization; just do it at the end of the atomic transaction, after waiting for vblanks. We do want it to be async eventually, but adding that now will cause more trouble for Maarten's in-progress work. (Maarten) - Don't allocate space in crtc_state for intermediate watermarks on platforms that don't need it (gen9+). - Move WaCxSRDisabledForSpriteScaling:ivb into intel_begin_crtc_commit now that ilk_update_wm is gone. v4: - Add a wm_mutex to cover updates to intel_crtc->active and the need_postvbl_update flag. Since we don't have async yet it isn't terribly important yet, but might as well add it now. - Change interface to program watermarks. Platforms will now expose .initial_watermarks() and .optimize_watermarks() functions to do watermark programming. These should lock wm_mutex, copy the appropriate state values into intel_crtc->active, and then call the internal program watermarks function. v5: - Skip intermediate watermark calculation/check during initial hardware readout since we don't trust the existing HW values (and don't have valid values of our own yet). - Don't try to call .optimize_watermarks() on platforms that don't have atomic watermarks yet. (Maarten) v6: - Rebase v7: - Further rebase v8: - A few minor indentation and line length fixes v9: - Yet another rebase since Maarten's patches reworked a bunch of the code (wm_pre, wm_post, etc.) that this was previously based on. v10: - Move wm_mutex to dev_priv to protect against racing commits against disjoint CRTC sets. (Maarten) - Drop unnecessary clearing of cstate->wm.need_postvbl_update (Maarten) Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1452108870-24204-1-git-send-email-matthew.d.roper@intel.comSigned-off-by:
-
Jani Nikula authored
We still keep getting [ 4.249930] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! This reverts commit 820da7ae Author: Jani Nikula <jani.nikula@intel.com> Date: Wed Nov 25 16:47:23 2015 +0200 Revert "drm/i915: shut up gen8+ SDE irq dmesg noise" which in itself is a revert, so this is just doing commit 97e5ed11 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Oct 23 10:56:12 2015 +0200 drm/i915: shut up gen8+ SDE irq dmesg noise all over again. I'll stop pretending I understand what's going on like I did when I thought I'd fixed this for good in commit 6a39d7c9 Author: Jani Nikula <jani.nikula@intel.com> Date: Wed Nov 25 16:47:22 2015 +0200 drm/i915: fix the SDE irq dmesg warnings properly Reported-by:
-
- 06 Jan, 2016 6 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:
Kenneth Graunke <kenneth@whitecape.org> Reviewed-by:
-
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 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:
-
