summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2015-11-16drm/i915: Replace the aux ddc name switch statement with kasprintf()Ville Syrjälä
Use kasprintf() to generate the "DPDDC-<port>" name for the aux helper. To deal with errors properly make intel_dp_aux_init() return something, and adjust the caller to match. It seems we were also missing a intel_dp_mst_encoder_cleanup() call on edp (non-port A) init failures, so add that too. The whole error/cleanup ordering doesn't feel entirely sane to me, but I'll leave that part alone for now. v2: Use kasprintf() instead of a table, reorder patches (Chis) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447266856-30249-3-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2015-11-16drm/i915: Replace aux_ch_ctl_reg check with port checkVille Syrjälä
Instead of checking what aux_ch_ctl_reg is, we can simply check the port when determining the right timeout value to program. v2: Reorder patches to reduce churn (Chris) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1) Link: http://patchwork.freedesktop.org/patch/msgid/1447266856-30249-2-git-send-email-ville.syrjala@linux.intel.com
2015-11-13drm/i915/skl: Update DDI translation tables for SKLjim.bride@linux.intel.com
While comparing the B-Spec with the code I noticed that several values in these tables have been updated in the spec, so I changed the code to match.. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jim Bride <jim.bride@linux.intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446852654-883-1-git-send-email-jim.bride@linux.intel.com
2015-11-13drm/i915: Fix SKL i_boost levelAnder Conselvan de Oliveira
The i_boost level in the DDI translation tables are stored per level. However, skl_ddi_set_iboos() would choose an entry of that table based on the port argument. Cc: Jim Bride <jim.bride@linux.intel.com> Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Jim Bride <jim.bride@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447247754-802-1-git-send-email-ander.conselvan.de.oliveira@intel.com
2015-11-12drm/i915/skl: Removed assert for csr-fw-loading check during disabling dc6Animesh Manna
As during disabling dc6 no need to check for csr firmware loading status, so removed the assert call (Requested by Damien). Cc: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Tested-by: Daniel Stone <daniels@collabora.com> # SKL Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-14-git-send-email-imre.deak@intel.com
2015-11-12drm/i915/gen9: flush DMC fw loading work during system suspendImre Deak
Currently during system s/r we enable/disable DC6, so before we do so make sure that the firmware loading is complete. Note that whether we need to enable DC6 for S3/S4 is still open. At least the firmware program is lost during S3 and we need to reprogram it after resuming. Until this is clarified we keep the current behavior and enable/disable DC6. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Tested-by: Daniel Stone <daniels@collabora.com> # SKL Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-13-git-send-email-imre.deak@intel.com
2015-11-12drm/i915/gen9: Use flush_work to synchronize with dmc loaderAnimesh Manna
During driver unload to ensure we dont have any pending task, flush_work added to complete firmware loading task. v1: Initial version. v2: As per review comments from Daniel, Removed flush_work from skl_set_power_well. As we have taken power well refernece and rpm count during firmware loading by using display_power_domain_get/put - this will always ensure rpm will be blocked if firmware is not loaded. Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Sunil Kamath <sunil.kamath@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Tested-by: Daniel Stone <daniels@collabora.com> # SKL Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-12-git-send-email-imre.deak@intel.com
2015-11-12drm/i915: Use request_firmware and our own async workDaniel Vetter
Two benefits: - We can use FW_LOADER_USERSPACE_FALLBACK. - We can use flush_work to synchronize with the oustanding worker, which is a notch more obvious what it does than having a special completion. The next patch will properly synchronize against the async loader in the resume and unload code. Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Sunil Kamath <sunil.kamath@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Tested-by: Daniel Stone <daniels@collabora.com> # SKL Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-11-git-send-email-imre.deak@intel.com
2015-11-12drm/i915/gen9: extract parse_csr_fwDaniel Vetter
The loader function will get a bit more complicated soon, extract the parsing code to make the control flow clearer. While doing that just use dev_priv->csr.dmc_payload as the indicator for whether it all suceeded or not. v2-v3: - unchanged v4: - rebased on top of latest drm-intel-nightly Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Sunil Kamath <sunil.kamath@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> [imre: remove note about BE cast from commit message, it's not relevant any more] Signed-off-by: Imre Deak <imre.deak@intel.com> Tested-by: Daniel Stone <daniels@collabora.com> # SKL [Jani: fix checkpatch warn on multiple blank lines] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447341089-2735-1-git-send-email-imre.deak@intel.com
2015-11-12drm/i915/gen9: Use dev_priv in csr functionsDaniel Vetter
As all csr firmware related opertion are not using any any data structures of drm framework level, so better to use dev_priv instead of dev. it's a new style! :) Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Sunil Kamath <sunil.kamath@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Tested-by: Daniel Stone <daniels@collabora.com> # SKL Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-9-git-send-email-imre.deak@intel.com
2015-11-12drm/i915/gen9: Don't try to load garbage dmc firmware on resumeDaniel Vetter
We need to make sure we don't put garbage into the hw if dmc firmware loading failed mid-thru. Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Sunil Kamath <sunil.kamath@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Tested-by: Daniel Stone <daniels@collabora.com> # SKL Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-8-git-send-email-imre.deak@intel.com
2015-11-12drm/i915/gen9: Simplify csr loading failure printing.Daniel Vetter
If we really want to we can be more verbose here, but we really don't need an entire function for this. Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Sunil Kamath <sunil.kamath@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Tested-by: Daniel Stone <daniels@collabora.com> # SKL Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-7-git-send-email-imre.deak@intel.com
2015-11-12drm/i915/gen9: Align line continuations in intel_csr.c.Daniel Vetter
Standard is to align continuations of parameter lists and if conditions to the opening ( in i915 and drm code. Apply this across the entire file since it was sticking out a bit too much. Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Sunil Kamath <sunil.kamath@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> [imre: removed note about reg definitions from the commit message, it's not relevant any more] Signed-off-by: Imre Deak <imre.deak@intel.com> Tested-by: Daniel Stone <daniels@collabora.com> # SKL Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-6-git-send-email-imre.deak@intel.com
2015-11-12drm/i915/gen9: Remove csr.state, csr_lock and related code.Daniel Vetter
This removes two anti-patterns: - Locking shouldn't be used to synchronize with async work (of any form, whether callbacks, workers or other threads). This is what the mutex_lock/unlock seems to have been for in intel_csr_load_program. Instead ordering should be ensured with the generic wait_for_completion()/complete(). Or more specific functions provided by the core kernel like e.g. flush_work()/cancel_work_sync() in the case of synchronizing with a work item. - Don't invent own completion like the following code did with the (already removed) wait_for(csr_load_status_get()) pattern - it's really hard to get these right when you want them to be _really_ correct (and be fast) in all cases. Furthermore it's easier to read code using the well-known primitives than new ones using non-standard names. Before enabling/disabling DC6 check if the firmware is loaded successfully. This is guaranteed during runtime s/r, since otherwise we don't enable RPM, but not during system s/r. Note that it's still unclear whether we need to enable/disable DC6 during system s/r, until that's clarified, keep the current behavior and enable/disable DC6. Also after this patch there is a race during system s/r where the firmware may not be loaded yet, that's addressed in an upcoming patch. v2-v3: - unchanged v4: - rebased on latest drm-intel-nightly Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Sunil Kamath <sunil.kamath@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> [imre: added code and note about checking if the firmware loaded ok, before enabling/disabling it] Reviewed-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Tested-by: Daniel Stone <daniels@collabora.com> # SKL Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447341037-2623-1-git-send-email-imre.deak@intel.com
2015-11-12drm/i915/gen9: move assert_csr_loaded into intel_rpm.cDaniel Vetter
Avoids non-static functions since all the callers are in intel_rpm.c. Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Sunil Kamath <sunil.kamath@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> [imre: removed note about reg definitions from commit message, since it's not relevant any more] Signed-off-by: Imre Deak <imre.deak@intel.com> Tested-by: Daniel Stone <daniels@collabora.com> # SKL [Jani: make assert_csr_loaded static] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-4-git-send-email-imre.deak@intel.com
2015-11-12drm/i915: use correct power domain for csr loadingDaniel Vetter
Grabbing a runtime pm reference with intel_runtime_pm_get will only prevent device D3. But dmc firmware is required even earlier (namely for the skl power well 2). Hence we need to grab a rpm reference higher up in the hierarchy. For simplicity just grab the _INIT display power well. That's a bit too much, but since the firmware loading task should completely fairly quickly this won't be a real problem really. Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Sunil Kamath <sunil.kamath@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Tested-by: Daniel Stone <daniels@collabora.com> # SKL Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-3-git-send-email-imre.deak@intel.com
2015-11-12drm/i915/gen9: csr_init after runtime pm enableAnimesh Manna
Skl is fully dependent on dmc for going to low power state (dc5/dc6). This requires a trigger from rpm. To ensure the dmc firmware is available for runtime pm support rpm-reference-count is used by not releasing the rpm reference if firmware loading is not completed. So moved the intel_csr_ucode_init call after runtime pm enable. Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Sunil Kamath <sunil.kamath@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> [imre: moved the call right after power domain init to avoid race with the console modesetting] Signed-off-by: Imre Deak <imre.deak@intel.com> Tested-by: Daniel Stone <daniels@collabora.com> # SKL Reviewed-by: A.Sunil Kamath <sunil.kamath@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-2-git-send-email-imre.deak@intel.com
2015-11-12drm/i915: refactor stepping info retrievalJani Nikula
Have only one if ladder for platforms and only one range check for size. Makes it easier to handle new platforms. Remove the use of negative return values in char, which might underflow to be positive for some negative error codes. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1445344713-1407-3-git-send-email-jani.nikula@intel.com
2015-11-12drm/i915: constify bxt stepping infoJani Nikula
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1445344713-1407-2-git-send-email-jani.nikula@intel.com
2015-11-12drm/i915: fix indentation on skl stepping infoJani Nikula
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1445344713-1407-1-git-send-email-jani.nikula@intel.com
2015-11-12drm/i915: Remove redundant check in i915_gem_obj_to_vmaTvrtko Ursulin
No need to verify VMA belongs to GGTT since: 1. The function must return a normal VMA belonging to passed in VM. 2. There can only be one normal VMA for any VM. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1447329595-17495-1-git-send-email-tvrtko.ursulin@linux.intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-11-11drm/i915: Clean up LVDS register handling harderLukas Wunner
Minor fixup to d0669d007542 ("drm/i915: Clean up LVDS register handling") which intended to read lvds_reg just once at the beginning of intel_lvds_init() and use that throughout the rest of the function but accidentally missed one register readout. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Link: http://patchwork.freedesktop.org/patch/msgid/20151107141244.AB7616E242@gabe.freedesktop.org Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-11-11drm/i915: Move the fbdev async_schedule() into intel_fbdev.cVille Syrjälä
Reading the driver load/unload code leaves one confused as there's an async_schedule() in the load, but not async_synchronize_full() in sight. In fact it's hidden inside intel_fbdev.c. So let's move the async_schedule() into intel_fbdev.c as well so that it's next to the async_synchronize_full(), which should make the relationship easier to see. Plus this way we won't schedule a nop function call when fbdev is disabled. And we were passing a pointer to a static inline function to async_schedule(), which seems rather dubious to me. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446815313-9490-4-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2015-11-11drm/i915: Do fbdev fini first during unloadVille Syrjälä
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 292b990e86abc ("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.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2015-11-11drm/i915: Kill intel_runtime_pm_disable()Ville Syrjälä
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 292b990e86ab ("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: 292b990e86ab ("drm/i915: Update power domains on readout.") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446815313-9490-2-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2015-11-10drm/i915: Setup DDI clk for MST on SKLVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1439826380-18403-1-git-send-email-ville.syrjala@linux.intel.com References: https://bugs.freedesktop.org/show_bug.cgi?id=91791 Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2015-11-10drm/i915: Configure eDP PLL freq from ironlake_edp_pll_on()Ville Syrjälä
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446146763-31821-15-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-11-10drm/i915: Use intel_dp->DP in eDP PLL setupVille Syrjälä
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 7b713f50d78b6 ("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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447164977-32315-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2015-11-10drm/i915: Clean up eDP PLL state assertsVille Syrjälä
Rewrite the eDP PLL state asserts to conform to our usual state assert style. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446146763-31821-13-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-11-10drm/i915: Remove ILK-A eDP PLL workaround notesVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446146763-31821-12-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2015-11-10drm/i915: s/DP_PLL_FREQ_160MHZ/DP_PLL_FREQ_162MHZ/Ville Syrjälä
The DP link frequency is 162MHz, not 160MHz. Rename the ILK eDP PLL defines to match. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446146763-31821-11-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-11-10drm/i915: Hide underruns from eDP PLL and port enable on ILKVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446146763-31821-10-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2015-11-10drm/i915: Disable FIFO underrun reporting around IBX transcoder B workaroundVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v1) Link: http://patchwork.freedesktop.org/patch/msgid/1446225802-11180-1-git-send-email-ville.syrjala@linux.intel.com
2015-11-10drm/i915: Check for CPT and not !IBX in ironlake_disable_pch_transcoder()Ville Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446146763-31821-8-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2015-11-10drm/i915: Check for FIFO underruns after modeset on IVB/HSW and CPT/PPTVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1446225741-11070-1-git-send-email-ville.syrjala@linux.intel.com
2015-11-10drm/i915: Re-enable PCH FIO underrun reporting after pipe has been disabledVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v1) Link: http://patchwork.freedesktop.org/patch/msgid/1446225691-10928-1-git-send-email-ville.syrjala@linux.intel.com
2015-11-10drm/i915: Enable PCH FIFO underruns later on HSW+Ville Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446146763-31821-5-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2015-11-10drm/i915: Enable PCH FIFO underruns later on ILK/SNB/IVBVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v1) Link: http://patchwork.freedesktop.org/patch/msgid/1446225627-10809-1-git-send-email-ville.syrjala@linux.intel.com
2015-11-10drm/i915: Set sync polarity from adjusted mode for TRANS_DP_CTLVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446146763-31821-3-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2015-11-10drm/i915: Don't use intel_pipe_to_cpu_transcoder() when there's a pipe ↵Ville Syrjälä
config around No point in doing the crtc->pipe->crtc->config->cpu_transcoder dance when we can just do crtc->config->cpu_transcoder. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446146763-31821-2-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2015-11-10drm/i915: remove in_dbg_master check from intel_fbc.cPaulo Zanoni
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 c924b934d0cd14a4559611da91f28f59acebe32a 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: Jesse Barnes <jbarnes@virtuousgeek.org> Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-13-git-send-email-paulo.r.zanoni@intel.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2015-11-10drm/i915: clarify that checking the FB stride for CFB is intentionalPaulo Zanoni
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 c4ffd40908c30a33291227920e921f6b45b9e8f7 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: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-12-git-send-email-paulo.r.zanoni@intel.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2015-11-10drm/i915: remove too-frequent FBC debug messagePaulo Zanoni
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 <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-10-git-send-email-paulo.r.zanoni@intel.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2015-11-10drm/i915: refactor FBC deactivation at initPaulo Zanoni
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 <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-9-git-send-email-paulo.r.zanoni@intel.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2015-11-10drm/i915: don't disable_fbc() if FBC is already disabledPaulo Zanoni
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 <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-8-git-send-email-paulo.r.zanoni@intel.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2015-11-10drm/i915: fix the __intel_fbc_update() commentsPaulo Zanoni
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 <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-7-git-send-email-paulo.r.zanoni@intel.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2015-11-10drm/i915: use struct intel_crtc *crtc at __intel_fbc_update()Paulo Zanoni
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 <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-6-git-send-email-paulo.r.zanoni@intel.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2015-11-10drm/i915: extract crtc_is_valid() on the FBC codePaulo Zanoni
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 <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-5-git-send-email-paulo.r.zanoni@intel.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2015-11-10drm/i915: remove unnecessary check for crtc->primary->fbPaulo Zanoni
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 <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-4-git-send-email-paulo.r.zanoni@intel.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2015-11-10drm/i915: extract fbc_on_pipe_a_only()Paulo Zanoni
Make the code easier to read. Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-3-git-send-email-paulo.r.zanoni@intel.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-31 06:54:33 +0000