- 09 Nov, 2015 9 commits
-
-
Mika Kuoppala authored
We check these to determine firmware loading status. Include them to help to debug causes of firmware loading fails. v2: Move all CSR specific registers to i915_reg.h (Ville) v3: Rebase v4: Rebase (RPM ref) Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446220487-32691-1-git-send-email-mika.kuoppala@intel.com Tested-by: Daniel Stone <daniels@collabora.com> # SKL Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com>
-
Mika Kuoppala authored
For bxt CSR firmware exposes a count of dc5 entries. Expose it through debugs Signed-off-by:
-
Damien Lespiau authored
The CSR firmware expose two counters, handy to check if we are indeed entering DC5/DC6. v2: Rebase v3: Take RPM ref before reading (Imre) Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (v1) Signed-off-by:
-
Damien Lespiau authored
Create a new debufs file for it, we'll have a few more things to add there. v2: Fix checkpatch warning about static const array v3: use named initializers (Ville) v4: strip out csr_state as it will be removed in future (Ville, Imre) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> (v1) Signed-off-by:
-
Mika Kuoppala authored
There is known issue on GT interrupt delivery with DC6 and firmwares <1.21. There is a suspicion that this causes spurious gpu hangs on driver init and with some workloads, as upgrading the firmware to 1.21 makes these problems disappear. As of now the current version included in distribution firmware packages is very like to be 1.19. Play it safe and refuse to load a firmware version that may affect gpu side stability. With < 1.23 there is a palette and dmc ram corruption issue so blacklist anything below that. v2: Refuse to load fw instead of notifying the user v3: Rebase on header version changes v4: Refuse to load anything less than 1.23 v5: Give enough information for user for finding correct fw (Chris) v6: better url and formatting (Chris) v7: move error log for each fail path (Mika) bail out earlier in load path (Imre) v8: Fix the version check (Imre) Cc: Animesh Manna <animesh.manna@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Dave Gordon <david.s.gordon@intel.com> Cc: Arun Siluvery <arun.siluvery@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> References: https://01.org/linuxgraphics/downloads/skldmcver121 References: https://01.org/linuxgraphics/downloads/skylake-dmc-1.23 Testcase: igt/gem_exec_nop Signed-off-by: -
Damien Lespiau authored
That can be handy later on to tell which DMC firmware version the user has, by just looking at the dmesg. v2: use DRM_DEBUG_DRIVER (Chris) v3: use DRM_INFO (Marc Herbert) Cc: Marc Herbert <marc.herbert@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> (v1) Signed-off-by:
-
Tvrtko Ursulin authored
We had two failure modes here: 1. Deadlock in intelfb_alloc failure path where it calls drm_framebuffer_remove, which grabs the struct mutex and intelfb_create (caller of intelfb_alloc) was already holding it. 2. Deadlock in intelfb_create failure path where it calls drm_framebuffer_unreference, which grabs the struct mutex and intelfb_create was already holding it. [Daniel Vetter on why struct_mutex needs to be locked in the second half of intelfb_create: "The vma [for the fbdev] is pinned, the problem is that we re-lookup it a few times, which is racy. We should instead track the vma directly, but oh well we don't."] v2: * Reformat commit msg to 72 chars. (Lukas Wunner) * Add third failure mode. (Lukas Wunner) v5: * Rebase on drm-intel-nightly 2015y-09m-01d-09h-06m-08s UTC, rephrase commit message. (Jani Nicula) v6: * In intelfb_alloc, if __intel_framebuffer_create failed, fb will be an ERR_PTR, thus not null. So in the failure path we need to check for IS_ERR_OR_NULL to avoid calling drm_framebuffer_remove on the ERR_PTR. (Lukas Wunner) * Since this is init code a drm_framebuffer_unreference should be all we need. drm_framebuffer_remove is for framebuffers that userspace has created - and is getting somewhat defeatured. (Daniel Vetter) v7: * Clarify why struct_mutex needs to be locked in the second half of intelfb_create. (Daniel Vetter) Fixes: 60a5ca01 ("drm/i915: Add locking around framebuffer_references--") Reported-by:Lukas Wunner <lukas@wunner.de> Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> [Lukas: Create v3 + v4 + v5 + v6 + v7 based on Tvrtko's v2] Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/47d4e88c91b3bf0f7a280cabec54c8c8cf0cf6f2.1446892879.git.lukas@wunner.deSigned-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Lukas Wunner authored
In intelfb_alloc(), if the call to intel_pin_and_fence_fb_obj() fails, the bo is unrefed twice: By drm_framebuffer_remove() and once more by drm_gem_object_unreference(). Fix it. Reported-by:
-
Lukas Wunner authored
Currently when allocating a framebuffer fails, the gem object gets unrefed at the bottom of the call stack in __intel_framebuffer_create, not where it gets refed, which is in intel_framebuffer_create_for_mode (via i915_gem_alloc_object) and in intel_user_framebuffer_create (via drm_gem_object_lookup). This invites mistakes: __intel_framebuffer_create is also called from intelfb_alloc, and as discovered by Tvrtko Ursulin, a double unref was introduced there with a8bb6818 ("drm/i915: Fix error path leak in fbdev fb allocation"). As suggested by Ville Syrjälä, fix the double unref and improve code clarity by moving the unref away from __intel_framebuffer_create to where the gem object gets refed. Based on Tvrtko Ursulin's original v2. v3: On fb alloc failure, unref gem object where it gets refed, fix double unref in separate commit (Ville Syrjälä) v4: Lock struct_mutex on unref (Chris Wilson) v5: Rebase on drm-intel-nightly 2015y-09m-01d-09h-06m-08s UTC, rephrase commit message (Jani Nicula) Tested-by:
Pierre Moreau <pierre.morrow@free.fr> [MBP 5,3 2009 nvidia MCP79 + G96 pre-retina] Tested-by:
Paul Hordiienko <pvt.gord@gmail.com> [MBP 6,2 2010 intel ILK + nvidia GT216 pre-retina] Tested-by:
William Brown <william@blackhats.net.au> [MBP 8,2 2011 intel SNB + amd turks pre-retina] Tested-by:
Bruno Bierbaumer <bruno@bierbaumer.net> [MBP 11,3 2013 intel HSW + nvidia GK107 retina] Fixes: a8bb6818 ("drm/i915: Fix error path leak in fbdev fb allocation") Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
- 05 Nov, 2015 9 commits
-
-
Ander Conselvan de Oliveira authored
The function name implies it should get intel_dp, and it mostly used where there is an intel_dp in the context. Signed-off-by:
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by:
Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1445594525-7174-8-git-send-email-ander.conselvan.de.oliveira@intel.com
-
Ander Conselvan de Oliveira authored
In order to prepare for a link training with DDI, the state machine would call intel_ddi_prepare_link_retrain(). To remove the dependency to the hardware information, replace that direct call with a callback. Signed-off-by:
-
Ander Conselvan de Oliveira authored
No functional changes, just moving code around. v2: Rebase Signed-off-by:
-
Ander Conselvan de Oliveira authored
Move register write from intel_dp_update_link_train() into intel_dp_set_signal_levels(). This creates a better split between the i915 specific code and the generic link training part. Note that this causes an extra register write in intel_dp_reset_link_train(), since both intel_dp_set_signal_levels() and intel_dp_set_link_train() write to the DP register. Signed-off-by:
-
Ander Conselvan de Oliveira authored
Move the call to intel_dp_get_adjust_train() out of intel_dp_update_link_train() and call it instead from the clock recovery and channel equalization features. A follow up patch will remove the DP register write from that function, so that it handles only the DPCD write. Signed-off-by:
-
Ander Conselvan de Oliveira authored
Split the register write with the new link training pattern out of intel_dp_set_link_train(), so that the i915 specific code is in a separate function. Signed-off-by:
-
Ander Conselvan de Oliveira authored
It just makes the code more confusing, so just reference intel_dp_>DP directly. Note that this also fix a bug where the value of intel_dp->DP could be different than the last value written to the hw, due to an early return that would skip the 'intel_dp->DP = DP' line. v2: Don't preserve old DP value on failure. (Sivakumar) - Don't call drm_dp_clock_recovery_ok() twice. (Sivakumar) - Keep return type of clock recovery and channel equalization functions as void. (Ander) v3: Remove DP parameter from intel_dp_set_signal_levels(). (Sivakumar) Signed-off-by: -
Deepak S authored
Reviewed-by:
Deepak S <deepak.s@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446139321-2818-2-git-send-email-rodrigo.vivi@intel.comSigned-off-by:
-
Shobhit Kumar authored
SWF18 is set if the display has been initialized by the pre-os. It also gives what configuration is enabled on which pipe. In skl_sanitize_cdclk, the DPLL sanity check can pass even if GOP/VBIOS is not loaded as BIOS enables DPLL for integrated audio codec related programming. So fisrt check if SWF18 is set and then follow through with other DPLL and CDCLK verification. If not set then for sure we need to sanitize the cdclock. v2: Update the commit message for clarity (Siva) v3: Correct the mask to check for bits[23:0] instead of only bits[16:0]. Had missed checking for PIPE C altogether. Remaining are reserved (Siva) v4: Use ILK_SWF macro for SWF register definitions. Taken from Ville's patch http://lists.freedesktop.org/archives/intel-gfx/2015-November/079480.html Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:Shobhit Kumar <shobhit.kumar@intel.com> Reviewed-by:
-
- 04 Nov, 2015 2 commits
-
-
Matt Roper authored
BXT CRTC scaling uses the same gen9 codepaths as SKL; these codepaths store panel fitter information in pipe_config->pch_pfit. However since HAS_PCH_SPLIT() is false for BXT we never actually wind up filling in this structure (we wind up filling in pipe_config->gmch_pfit instead, which is ignored when we go to program the hardware). Make sure we always take the PCH code path on gen9+ platforms. v2: Use HAS_GMCH_DISPLAY() to more cleanly describe the platforms that actually want to use GMCH-style panel fitting. (Ville) Cc: Imre Deak <imre.deak@intel.com> Cc: Chandra Konduru <chandra.konduru@intel.com> Signed-off-by:Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
-
Paulo Zanoni authored
I wanted to add yet another check to intel_fbc_update() and realized I would need to create yet another enum no_fbc_reason case. So I remembered this patch series that Damien wrote a long time ago and nobody ever reviewed, so I decided to reimplement it since the code changed a lot since then. Credits-to: Damien Lespiau <damien.lespiau@intel.com> Cc: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1445964628-30226-2-git-send-email-paulo.r.zanoni@intel.comSigned-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
- 02 Nov, 2015 5 commits
-
-
Maarten Lankhorst authored
Make pinning and waiting a separate step, and wait for object idle without struct_mutex held. Changes since v1: - Do not wait when a reset is in progress. - Remove call to i915_gem_object_wait_rendering for intel_overlay_do_put_image (Chris Wilson) Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Maarten Lankhorst authored
struct_mutex is being locked for every plane in intel_prepare_plane_fb and intel_cleanup_plane_fb. Require the caller to hold the mutex, and only acquire the mutex for each helper call. This way the lock only needs to be acquired twice in ->atomic_commit(). Once for pinning new framebuffers at the start, the second time for unpinning old framebuffer. Changes since v1: - Use mutex_lock_interruptible instead of i915 variant, to prevent a deadlock when called from the reset code. Changes since v2: - Clarify struct_mutex is locked by the caller. Signed-off-by:
-
Maarten Lankhorst authored
Move it from intel_crtc_atomic_commit to prepare_plane_fb. Waiting is done before committing, otherwise it's too late to undo the changes. Signed-off-by:
-
Robert Fekete authored
Extends i915_display_info so that for each active crtc also print all planes associated with the pipe. This patch shows information about each plane wrt format, size, position, rotation, and scaling. This is very useful when debugging user space compositors that try to utilize several planes for a commit. V2: Fixed comments from Maarten, Ville, and Chris. Fixed printing of 16.16 fixpoint, better rotation bitmask management and some minor fixes V3: Corrected state->src_x & 0x00ff to state->src_x & 0xffff... Signed-off-by:
Robert Fekete <robert.fekete@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1445961512-25317-1-git-send-email-robert.fekete@linux.intel.comSigned-off-by:
-
Ioan-Adrian Ratiu authored
One branch of the if clause uses pr_info, the other pr_err; change the 'false' branch to also use pr_info. This minor oversight has gone unfixed since the initial vga_switcheroo implementation in 6a9ee8af. Signed-off-by:
Ioan-Adrian Ratiu <adi@adirat.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446246960-22620-1-git-send-email-adi@adirat.comSigned-off-by:
-
- 31 Oct, 2015 2 commits
-
-
Daniel Vetter authored
Another CI fail we have for no reason. Totally unjustified since nothing fails at all. Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1445590806-23886-1-git-send-email-daniel.vetter@ffwll.chAcked-by:
-
Daniel Vetter authored
DRM_ERROR an continue without any issues aren't allowed since that causes noise in the CI system. But we absolutely want to have the DRM_ERROR when we want to run with GuC. For simplicity just short-circuit all the loader code when it's not needed. v2: Mika&Chris complained that I shouldn't hit send on patches written before coffee kicks in. v3: Make it compile at least ... Cc: Alex Dai <yu.dai@intel.com> Cc: Dave Gordon <david.s.gordon@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
- 29 Oct, 2015 1 commit
-
-
Tim Gore authored
Since A1 chips use the same GPU as A0, they need all the same wa's in the i915 driver. Update some conditionals to do this. Signed-off-by:
Tim Gore <tim.gore@intel.com> Reviewed-by:
Arun Siluvery <arun.siluvery@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1445856538-5417-1-git-send-email-tim.gore@intel.comSigned-off-by:
-
- 28 Oct, 2015 6 commits
-
-
Deepak S authored
v2: (Rodrigo) Rebase after commit 3cb27f38 ("drm/i915: remove an extra level of indirection in PCI ID list") Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
Deepak S authored
v2: separate out device info into different GT (Damien) v3: Add is_kabylake to the KBL gt3 structuer (Damien) Sort the platforms in older -> newer order (Damien) v4: Split platform definition since is_skylake=1 on kabylake structure was Nacked. (Rodrigo) v5: (Rodrigo) Rebase after commit 3cb27f38 ("drm/i915: remove an extra level of indirection in PCI ID list") Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: -
Rodrigo Vivi authored
Kabylake is a Intel
® Processor containing Intel® HD Graphics following Skylake. It is Gen9p5, so it inherits everything from Skylake. Let's start by adding the platform separated from Skylake but reusing most of all features, functions etc. Later we rebase the PCI-ID patch without is_skylake=1 so we don't replace what original Author did there. Few IS_SKYLAKEs if statements are not being covered by this patch on purpose: - Workarounds: Kabylake is derivated from Skylake H0 so no W/As apply here. - GuC: A following patch removes Kabylake support with an explanation: No firmware available yet. - DMC/CSR: Done in a separated patch since we need to be carefull and load the version for revision 7 since Kabylake is Skylake H0. v2: relative cleaner commit message and added the missed IS_KABYLAKE to intel_i2c.c as pointed out by Jani. Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: -
Rodrigo Vivi authored
Kabylake will also be defined as gen9 and !is_skylake. So we need start by creating a proper Broxton definition, otherwise we will break broxton with the introduction of Kabylake. Signed-off-by:
-
Jani Nikula authored
Add the PCI IDs directly in the pciidlist array instead of defining an extra macro. The minor benefit from this is neater diffs when adding to the end of the list. v2: drop the "aka" comment (Ville) Reviewed-by:
-
Chris Wilson authored
Having flushed all requests from all queues, we know that all ringbuffers must now be empty. However, since we do not reclaim all space when retiring the request (to prevent HEADs colliding with rapid ringbuffer wraparound) the amount of available space on each ringbuffer upon reset is less than when we start. Do one more pass over all the ringbuffers to reset the available space Signed-off-by:
-
- 26 Oct, 2015 6 commits
-
-
Ville Syrjälä authored
v2: Rebase due to SKL_DPLLx usage Signed-off-by:
-
Ville Syrjälä authored
Include an early NEEDS_FORCEWAKE() check for vlv and chv. Hopefully that will avoid doing so many range checks in for many register accesses (at least for all display registers). Note that vlv already had the check in the write path since it shares the gen6+ code for that. Signed-off-by:
-
Ville Syrjälä authored
Change the fw domain handling in the vlv/chv register read/write functions to look more like the SKL code, ie. have a single __force_wake_get() get call instead of multiple ones. Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Change FORCEWAKE & co. reads for the error state to use I915_READ_FW(). Reading a FORCEWAKE register using a function that can frob forcewake just seems wrong. There is a check to skip grabbing the forcewake for accessing FORCEWAKE in intel_uncore.c, but there's no such check for FORCEWAKE_MT. So no idea what is currently happening with FORCEWAKE_MT reads. FORCEWAKE_VLV is fortunately outside the forcewake range anyway, so no actual issue with that one. So let's just make the rule that you can't access FORCEWAKE registers with the normal I915_READ() stuff, and we can drop the extra FORCEWAKE check from NEEDS_FORCEWAKE(). While at it use NEEDS_FORCEWAKE() on BDW, where it was skipped for whatever bikeshed reason that I've already forgotten. Signed-off-by:
-
Ville Syrjälä authored
There's no need for __raw_i915_read8() & co. to be macros, so make them inline functions. To avoid typo mistakes generate the inline functions using preprocessor templates. We have a few users of the raw register acces functions outside intel_uncore.c, so let's also move the functions into intel_drv.h. While doing that switch I915_READ_FW() & co. to use the __raw_i915_read() functions, and use the _FW macros everywhere outside intel_uncore.c where we want to read registers without grabbing forcewake and whatnot. The only exception is i915_check_vgpu() which itself gets called from intel_uncore.c, so using the __raw_i915_read stuff there seems appropriate. v2: Squash in the intel_uncore.c->i915_drv.h move Convert I915_READ_FW() to use __raw_i915_read(), and use I915_READ_FW() outside of intel_uncore.c (Chris) Signed-off-by:
-
