- 11 Nov, 2015 2 commits
-
-
Ville Syrjälä authored
We set up fbdev last during load, so doing the fbdev cleanup should be first. We weren't supposed to drop the init power during driver unload, but since the fbdev teardown happened after intel_power_domains_fini() that could have happened due in one of two ways. First it could have happened during the modeset caused by normal fbdev cleanup. But in addition it could have happened already via the intel_fbdev_initial_config() since that is executed asynhronously, and the async_synchronize_full() was done during fbdev cleanup, after intel_power_domains_fini(). All of that got eliminated by commit 292b990e ("drm/i915: Update power domains on readout.") since we now drop the init power synchronously during driver load. So there is no real bug wrt. the init power anymore, but still it seems better to do the fbdev cleanup first, before we've potentially cleaned up something else important. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446815313-9490-3-git-send-email-ville.syrjala@linux.intel.comReviewed-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Ville Syrjälä authored
intel_runtime_pm_disable() takes an extra rpm reference which combined with the one we leak from intel_display_set_init_power() leaves the usage count at <original>+1 after the driver has been unloaded. The original ref is dropped explicitly in intel_runtime_pm_enable(). So the next time we load the driver we can no longer do runtime PM ever. This used to work, but commit 292b990e ("drm/i915: Update power domains on readout.") broke things by not dropping the init power domain during fbdev teardown. Based on the comment in intel_power_domains_fini(), the way it used to to work wasn't intentional. As in we weren't supposed to drop the init power during driver unload. And since we no longer do, we now leak an extra rpm reference. So fix things by throwing intel_runtime_pm_disable() to the bin, so that the only leaked reference comes from the init power domain. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Daniel Stone <daniels@collabora.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Fixes: 292b990e ("drm/i915: Update power domains on readout.") Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org>
-
- 10 Nov, 2015 27 commits
-
-
Ville Syrjälä authored
Set up the DDI->PLL mapping on SKL also for MST links. Might help make MST operational on SKL. v2: Rebased due to KBL Improve the patch subject, Jesse provided the new one Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: -
Ville Syrjälä authored
ironlake_set_pll_cpu_edp() only gets called just before ironlake_edp_pll_on(), so just pull the code into ironlake_edp_pll_on(). Also toss in a debug print into ironlake_edp_pll_off() to match the one we have in ironlake_edp_pll_on(). Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Use intel_dp->DP in the eDP PLL setup, instead of doing RMWs. To do this we need to move DP_AUDIO_OUTPUT_ENABLE setup to happen later, so that we don't enable audio accidentally while configuring the PLL. Note that actually we already enabled audio before the port due to the double port register write magic required by VLV/CHV from 7b713f50 ("drm/i915: Fix eDP link training when switching pipes on VLV/CHV") So that gets changed now to keep audio off as long as the port is off. Also intel_dp_link_down() must be made to update intel_dp->DP so that we don't re-enable the port by accident when turning off the PLL. This is safe now that we don't call intel_dp_link_down() during link retraining. v2: Add a note about the audio vs. port enable (Daniel) Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
Rewrite the eDP PLL state asserts to conform to our usual state assert style. Signed-off-by:
-
Ville Syrjälä authored
We don't care about ILK-A and the old w/a notes may just confuse people, so get rid of them. Signed-off-by:
-
Ville Syrjälä authored
The DP link frequency is 162MHz, not 160MHz. Rename the ILK eDP PLL defines to match. Signed-off-by:
-
Ville Syrjälä authored
We get underruns on the other pipe when enabling the CPU eDP PLL and port on ILK. Bspec knows about the PLL issue, and recommends doing a vblank wait just prior to enabling the PLL. That does seem to help, but unfortunately we get another underrun when actually enabling the CPU eDP port. Bspec doesn't mention that at all, and the same vblank wait trick doesn't appear to be effective there. Since I have no better clue how to deal with this, just hide the errors. Signed-off-by:
-
Ville Syrjälä authored
Doing the IBX transcoder B workaround causes underruns on pipe/transcoder A. Just hide them by disabling underrun reporting for pipe A around the workaround. It might be possible to avoid the underruns by moving the workaround to be applied only when enabling pipe A. But I was too lazy to try it right now, and the current method has been proven to work, so didn't want to change it too hastily. Note that this can re-enable underrun reporting on pipe A if was already disabled due to a previous actual underrun. But that's OK, we may just get a second underrun report if another real underron occurrs on pipe A. v2: Note that pipe A underruns can get re-enabled due to this (Jani) Signed-off-by:
-
Ville Syrjälä authored
ironlake_enaable_pch_transcoder() checks for CPT to see if it should enable the timing override chicken bit, but ironlake_disable_pch_transcoder() checks for !IBX to see if it should clear the same bit. Change ironlake_disable_pch_transcoder() to check for CPT as well to keep the two sides consistent. Signed-off-by:
-
Ville Syrjälä authored
Due to the shared error interrupt on IVB/HSW and CPT/PPT we may not always get an interrupt on a FIFO underrun. But we can always do an explicit check (like we do on GMCH platforms that have no underrun interrupt). v2: Drop stale kerneldoc for i9xx_check_fifo_underruns() (Daniel) Signed-off-by:
-
Ville Syrjälä authored
Some hardware (IVB/HSW and CPT/PPT) have a shared error interrupt for all the relevant underrun bits, so in order to keep the error interrupt enabled, we need to have underrun reporting enabled on all PCH transocders. Currently we leave the underrun reporting disabled when the pipe is off, which means we won't get any underrun interrupts when only a subset of the pipes are active. Fix the problem by re-enabling the underrun reporting after the pipe has been disabled. And to avoid the spurious underruns during pipe enable, disable the underrun reporting before embarking on the pipe enable sequence. So this way we have the error reporting disabled while running through the modeset sequence. v2: Re-enable PCH FIFO underrun reporting unconditionally on pre-HSW Signed-off-by:
-
Ville Syrjälä authored
As we did for ILK/SNB/IVB, move the PCH FIFO underrun enable to happen after the encoder enable on HSW+. And again, for symmetry, move the the disable to happen before encoder disable. I've left out the vblank wait before the enable here because I don't know if it's needed or not. Actually I don't know if this entire change is needed as I don't have a HSW/BDW with VGA output. Signed-off-by:
-
Ville Syrjälä authored
We get spurious PCH FIFO underruns if we enable the reporting too soon after enabling the crtc. Move it to be the last step, after the encoder enable. Additionally we need an extra vblank wait, otherwise we still get the underruns. Presumably the pipe/fdi isn't yet fully up and running otherwise. For symmetry, disable the PCH underrun reporting as the first thing, just before encoder disable, when shutting down the crtc. v2: Do the PCH underrun enable unconditionally (Jani, Daniel) Signed-off-by:
-
Ville Syrjälä authored
Rather than looking at crtc->mode (which is the user mode) dig up the sync polarity settings from the adjusted_mode when programming TRANS_DP_CTL on CPT/PPT. Signed-off-by:
-
Ville Syrjälä authored
No point in doing the crtc->pipe->crtc->config->cpu_transcoder dance when we can just do crtc->config->cpu_transcoder. Signed-off-by:
-
Paulo Zanoni authored
From our maintainer Daniel Vetter a few days ago: "Oh dear this is dead code. kdbg uses the fbcon, which always uses untiled, which means fbc will never be enabled. Also we have 0 users and 0 test coverage for kdbg on top of i915 (Jesse implemented it for fun years back). Imo just remove all this code." Adding to what Daniel said: for kgdboc's KMS support, intel_pipe_set_base_atomic() already manually disables FBC, so we won't do the in_dbg_master() check there. This is essentially a revert of: commit c924b934 Author: Jason Wessel <jason.wessel@windriver.com> Date: Thu Aug 5 09:22:32 2010 -0500 i915: when kgdb is active display compression should be off Besides, it is not clear what is the exact problem caused by FBC, and why other features such as PSR, DRRS, IPS and RPM are not also checking for in_dbg_master(). IMHO we should either remove the code as suggested by Daniel or we add some nice comments explaining why is FBC so special. v2: Rebase due to new patch order. Cc: Jason Wessel <jason.wessel@windriver.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Paulo Zanoni authored
Daniel was looking at this code and asked about whether fb->pitches[0] is correct, then he suggested we should a comment to make sure it is actually intentional. For more information on the CFB size calculation, please see the commit message of: commit c4ffd409 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Thu Oct 1 19:55:57 2015 -0300 drm/i915: fix CFB size calculation Requested-by:
-
Paulo Zanoni authored
If we run igt/kms_frontbuffer_tracking, this message will appear thousands of times, eating a significant part of our dmesg buffer. It's part of the expected FBC behavior, so let's just silence it. Signed-off-by:
-
Paulo Zanoni authored
Make sure we deactivate FBC at intel_fbc_init(), so we can remove the call from intel_display.c. Currently we only have the "enabled" software state, but later we'll have both "enabled" and "active", and we'll add assertions to them, so just calling intel_fbc_disable() from intel_modeset_init() won't work. It's better to make sure intel_fbc_init() already puts the hardware in the expected state, so we can put nice assertions in the other functions. v2: Keep/improve the comment (Chris). v3: Improve the commit message a little bit. Signed-off-by:
-
Paulo Zanoni authored
If FBC is disabled we will still call intel_fbc_invalidate(), and as a result we may call intel_fbc_deactivate(), which will try to touch registers. I'm pretty sure I saw this happen on a runtime suspended device, and I'm almost sure I was running igt/pm_rpm. It produced the "you touched registers while the device is suspended" WARNs. But this was some time ago and I can't remember exactly which conditions were necessary to reproduce the problem. v2: Rebase to new series order. Signed-off-by:
-
Paulo Zanoni authored
Don't try to list in comments the cases where we should enable or disable FBC: it varies a lot with the hardware generations and the code should be the documentation. Also notice that there's already a huge gap between the comments and what's in the code. Signed-off-by:
-
Paulo Zanoni authored
This change was part of the commit that makes intel_fbc_update() receive an intel_crtc as argument instead of dev_priv, but since it was polluting the diff with too many chunks I decided to move it to its own commit. It seems that our developers are favoring having this instead of the old combination drm_crtc *crtc + intel_crtc *intel_crtc, and on the mentioned commit we'll get rid of the drm_crtc variable, so let's do an intermediate commit with the rename, so on the next commit we'll have just struct intel_crtc *crtc. Signed-off-by:
-
Paulo Zanoni authored
We're going to kill intel_fbc_find_crtc(), that's why a big part of the logic moved from intel_fbc_find_crtc() to crtc_is_valid(). v2: - Rebase due to pipe_a_only change. - Split the multiline conditional (Chris). Signed-off-by:
-
Paulo Zanoni authored
We already check if the CRTC is visible, and it shouldn't be possible to have a visible CRTC without an FB. This was noticed by both Chris and Ville on different ocasions. Signed-off-by:
-
Paulo Zanoni authored
Make the code easier to read. Suggested-by:
-
Paulo Zanoni authored
Although the term "nuke" is part of the FBC spec, it's not very intuitive, so let's rename it to make it easier for people that are not familiar with the spec. Requested-by:
-
Paulo Zanoni authored
Newlines are not needed and they're not used by the other messages. I added the newline by mistake. Signed-off-by:
-
- 09 Nov, 2015 11 commits
-
-
Matt Roper authored
The bspec indicates that DDI A using four lanes is the only valid configuration for Broxton (Broxton doesn't have a DDI E to split these lanes with); the DDI_A_4_LANES bit of port A's DDI_BUF_CTL should always be set by the BIOS. However some BIOS versions seem to only be setting this bit if eDP is actually lit up at boot time; if the BIOS doesn't turn on the eDP panel because an external display is plugged in, then this bit is never properly initialized. The end result of this is that we wind up calculating a lower max data rate than we should and may wind up rejecting the native mode for panels that we should be able to drive. Let's workaround this BIOS bug by just turning the DDI_A_4_LANES bit on in our driver's internal state if we recognize that we're running on BXT where it should have been on anyway. Cc: Imre Deak <imre.deak@intel.com> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
Bob Paauwe <bob.j.paauwe@intel.com> Tested-by:
-
Ville Syrjälä authored
Currently there's no trace in dmesg when the gen2/3 dotclock checks reject the modeset. Add some to avoid further head scratching. While at it refactor the code a bit to look nicer. Signed-off-by:
Ander Conselvan de Oliveira <conselvan2@gmail.com>
-
Mika Kuoppala authored
VMA offsets are 64 bits. Plane surface offsets are in ggtt and the hardware register to set this is thus 32 bits. Be explicit about these and convert carefully to from vma to final size. This will make sparse happy by not creating 32bit pointers out of 64bit vma offsets. Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446204375-29831-1-git-send-email-mika.kuoppala@intel.comReviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
-
Mika Kuoppala authored
We have had one case where buggy csr/dmc firmware version influenced gt side and caused a hang. Add dmc firmware loading state and version to error state. v2: - Rebased on top of Damien's patches - included fw load state v3: include dmc info only if platform supports it (Chris) v4: move *csr to branch scope (Chris) v5: remove dependency to csr_state Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v4) Signed-off-by: -
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:
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:
-
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:
-
