aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/intel_display.c
AgeCommit message (Collapse)Author
2014-06-18drm/i915: add unregister callback to connectorImre Deak
commit 4932e2c3c716067f3580e1a9687bed9d751549e3 upstream. Since commit d9255d57147e1dbcebdf6670409c2fa0ac3609e6 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date:   Thu Sep 26 20:05:59 2013 -0300 it became clear that we need to separate the unload sequence into two parts: 1. remove all interfaces through which new operations on some object (crtc, encoder, connector) can be started and make sure all pending operations are completed 2. do the actual tear down of the internal representation of the above objects The above commit achieved this separation for connectors by splitting out the sysfs removal part from the connector's destroy callback and doing this removal before calling drm_mode_config_cleanup() which does the actual tear-down of all the drm objects. Since we'll have to customize the interface removal part for different types of connectors in the upcoming patches, add a new unregister callback and move the interface removal part to it. No functional change. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-18drm/i915: quirk invert brightness for Acer Aspire 5336Jani Nikula
This is commit 0f540c3a7cfb91c9d7a19eb0c95c24 upstream. Since commit ee1452d7458451a7508e0663553ce88d63958157 Author: Jani Nikula <jani.nikula@intel.com> Date: Fri Sep 20 15:05:30 2013 +0300 drm/i915: assume all GM45 Acer laptops use inverted backlight PWM failed and was later reverted in commit be505f643925e257087247b996cd8ece787c12af Author: Alexander van Heukelum <heukelum@fastmail.fm> Date: Sat Dec 28 21:00:39 2013 +0100 Revert "drm/i915: assume all GM45 Acer laptops use inverted backlight PWM" fix the individual broken machine instead. Note to backporters: http://patchwork.freedesktop.org/patch/17837/ is the patch you want for 3.13 and older. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=54171 Reference: http://mid.gmane.org/DUB115-W7628C7C710EA51AA110CD4A5000@phx.gbl Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [danvet: Patch mangling for 3.14 plus adding the link to the original for 3.13.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-18drm/i915: Break encoder->crtc link separately in intel_sanitize_crtc()Egbert Eich
commit 7f1950fbb989e8fc5463b307e062b4529d51c862 upstream. Depending on the SDVO output_flags SDVO may have multiple connectors linking to the same encoder (in intel_connector->encoder->base). Only one of those connectors should be active (ie link to the encoder thru drm_connector->encoder). If intel_connector_break_all_links() is called from intel_sanitize_crtc() we may break the crtc connection of an encoder thru an inactive connector in which case intel_connector_break_all_links() will not be called again for the active connector if this happens to come later in the list due to: if (connector->encoder->base.crtc != &crtc->base) continue; in intel_sanitize_crtc(). This will however leave the drm_connector->encoder linkage for this active connector in place. Subsequently this will cause multiple warnings in intel_connector_check_state() to trigger and the driver will eventually die in drm_encoder_crtc_ok() (because of crtc == NULL). To avoid this remove intel_connector_break_all_links() and move its code to its two calling functions: intel_sanitize_crtc() and intel_sanitize_encoder(). This allows to implement the link breaking more flexibly matching the surrounding code: ie. in intel_sanitize_crtc() we can break the crtc link separatly after the links to the encoders have been broken which avoids above problem. This regression has been introduced in: commit 24929352481f085c5f85d4d4cbc919ddf106d381 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Jul 2 20:28:59 2012 +0200 drm/i915: read out the modeset hw state at load and resume time so goes back to the very beginning of the modeset rework. v2: This patch takes care of the concernes voiced by Chris Wilson and Daniel Vetter that only breaking links if the drm_connector is linked to an encoder may miss some links. v3: move all encoder handling to encoder loop as suggested by Daniel Vetter. Signed-off-by: Egbert Eich <eich@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-18drm/i915: Don't check gmch state on inherited configsDaniel Vetter
commit 9953599bc02dbc1d3330e6a0bfc6c50e9dffcac6 upstream. ... our current modeset code isn't good enough yet to handle this. The scenario is: 1. BIOS sets up a cloned config with lvds+external screen on the same pipe, e.g. pipe B. 2. We read out that state for pipe B and assign the gmch_pfit state to it. 3. The initial modeset switches the lvds to pipe A but due to lack of atomic modeset we don't recompute the config of pipe B. -> both pipes now claim (in the sw pipe config structure) to use the gmch_pfit, which just won't work. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74081 Tested-by: max <manikulin@gmail.com> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-18drm/i915: restore QUIRK_NO_PCH_PWM_ENABLEJani Nikula
This reverts the bisected regressing commit bc0bb9fd1c7810407ab810d204bbaecb255fddde Author: Jani Nikula <jani.nikula@intel.com> Date: Thu Nov 14 12:14:29 2013 +0200 drm/i915: remove QUIRK_NO_PCH_PWM_ENABLE restoring QUIRK_NO_PCH_PWM_ENABLE for a couple of Dell XPS models which broke in 3.14. There is no such revert upstream. We have root caused and fixed the issue upstream, without the quirk, with: commit 39fbc9c8f6765959b55e0b127dd5c57df5a47d67 Author: Jani Nikula <jani.nikula@intel.com> Date: Wed Apr 9 11:22:06 2014 +0300 drm/i915: check VBT for supported backlight type and commit c675949ec58ca50d5a3ae3c757892f1560f6e896 Author: Jani Nikula <jani.nikula@intel.com> Date: Wed Apr 9 11:31:37 2014 +0300 drm/i915: do not setup backlight if not available according to VBT While the commits are within the stable rules otherwise, and fix more machines than just the regressed Dell XPS models, we feel backporting them to stable may be too risky. The revert is limited to the broken machines, and the impact should be effectively the same as what the upstream commits do more generally. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76276 Reported-by: Romain Francoise <romain@orebokech.com> Acked-by: Daniel Vetter <daniel@ffwll.ch> Tested-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Tested-by: Romain Francoise <romain@orebokech.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-03drm/i915: fix assert_cursor on BDWPaulo Zanoni
We need to read the correct register, not a register that doesn't exist and will trigger "Unclaimed register" messages when we touch it. Also rearrange the checks in an attempt to prevent this error from happening again. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [Jani: dropped an extra empty line introduced.] Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-02-18Merge tag 'drm-intel-fixes-2014-02-14' of ↵Dave Airlie
ssh://git.freedesktop.org/git/drm-intel into drm-fixes 3 fixes plus 1 prep patch, all four cc: stable. Jani will take over from here and the plan is that he'll do 3.14-fixes for the entire release just to work things out a bit. * tag 'drm-intel-fixes-2014-02-14' of ssh://git.freedesktop.org/git/drm-intel: drm/i915/dp: add native aux defer retry limit drm/i915/dp: increase native aux defer retry timeout drm/i915: Prevent MI_DISPLAY_FLIP straddling two cachelines on IVB drm/i915: Add intel_ring_cachline_align()
2014-02-11drm/i915: Prevent MI_DISPLAY_FLIP straddling two cachelines on IVBVille Syrjälä
According to BSpec the entire MI_DISPLAY_FLIP packet must be contained in a single cacheline. Make sure that happens. v2: Use intel_ring_begin_cacheline_safe() v3: Use intel_ring_cacheline_align() (Chris) Cc: Bjoern C <lkml@call-home.ch> Cc: Alexandru DAMIAN <alexandru.damian@intel.com> Cc: Enrico Tagliavini <enrico.tagliavini@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74053 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-29Merge tag 'drm/for-3.14-rc1-20140123' of ↵Dave Airlie
git://anongit.freedesktop.org/tegra/linux into drm-next drm/tegra: Changes for v3.14-rc1 (update) These patches fix some issues caused by the DRM panel support from the previous pull request and add two more panels (for the Toshiba AC100 as well as the Seaboard and Ventana). * tag 'drm/for-3.14-rc1-20140123' of git://anongit.freedesktop.org/tegra/linux: drm/tegra: Obtain head number from DT drm/panel: update EDID BLOB in panel_simple_get_modes() gpu: host1x: Remove unnecessary include drm/tegra: Use proper data type drm/tegra: Clarify how panel modes override others drm/tegra: Fix possible CRTC mask for RGB outputs drm/i915: Use drm_encoder_crtc_ok() drm: Move drm_encoder_crtc_ok() to core drm: provide a helper for the encoder possible_crtcs mask drm/tegra: Don't check resource with devm_ioremap_resource() drm/panel: Add support for Chunghwa CLAA101WA01A panel drm/panel: Add support for Samsung LTN101NT05 panel
2014-01-24Revert "drm/i915: Mask reserved bits in display/sprite address registers"Daniel Vetter
This reverts commit 446f254566ea8911c9e19c7bc8a162fc0e53cf31. I've left the masking in the pageflip code since that seems to be some useful piece of preemptive robustness. Iirc I've merged this patch under the assumption that the BIOS leaves some random gunk in the lower bits and gets unhappy if we trample on them. We have quite a few case like this, so this made sense. Now I've just learned that there's actual hardware features bits in the low 12 bits, and the kernel needs to preserve them to allow a userspace blob to do its job. Given Dave Airlie's clear stance on userspace blob drivers I've quickly chatted with him and he doesn't seem too happy. So let's revert this. If there are indeed bits that we must preserve in this range then we can ressurrect this patch, but with proper documentation for those bits supplied. And we probably also need to think a bit about interactions with our driver. Cc: Armin Reese <armin.c.reese@intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Dave Airlie <airlied@linux.ie> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-22drm/i915: Wait for completion of pending flips when starved of fencesChris Wilson
On older generations (gen2, gen3) the GPU requires fences for many operations, such as blits. The display hardware also requires fences for scanouts and this leads to a situation where an arbitrary number of fences may be pinned by old scanouts following a pageflip but before we have executed the unpin workqueue. This is unpredictable by userspace and leads to random EDEADLK when submitting an otherwise benign execbuffer. However, we can detect when we have an outstanding flip and so cause userspace to wait upon their completion before finally declaring that the system is starved of fences. This is really no worse than forcing the GPU to stall waiting for older execbuffer to retire and release their fences before we can reallocate them for the next execbuffer. v2: move the test for a pending fb unpin to a common routine for later reuse during eviction Reported-and-tested-by: dimon@gmx.net Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73696 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-20drm/i915: Call drm_calc_timestamping_constants() earlierVille Syrjälä
Update the pixel/line/frame duration information when we switch to the new pipe config. This will keep the timestamping constants in better sync with the real hardware state. Reviewed-by: mario.kleiner.de@gmail.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2014-01-20drm/i915: Kill hwmode save/restoreVille Syrjälä
drm core no longer uses crtc->hwmode, and neither does i915, so we can totally ignore it in i915. Reviewed-by: mario.kleiner.de@gmail.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2014-01-20drm: Pass the display mode to drm_calc_timestamping_constants()Ville Syrjälä
We don't really use hwmode anymore in i915, so eliminating its use from the core code seems prudent. Just pass the appropriate mode to drm_calc_timestamping_constants(). Reviewed-by: mario.kleiner.de@gmail.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2014-01-16Merge commit origin/master into drm-intel-nextDaniel Vetter
Conflicts are getting out of hand, and now we have to shuffle even more in -next which was also shuffled in -fixes (the call for drm_mode_config_reset needs to move yet again). So do a proper backmerge. I wanted to wait with this for the 3.13 relaese, but alas let's just do this now. Conflicts: drivers/gpu/drm/i915/i915_reg.h drivers/gpu/drm/i915/intel_ddi.c drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i915/intel_pm.c Besides the conflict around the forcewake get/put (where we chaged the called function in -fixes and added a new parameter in -next) code all the current conflicts are of the adjacent lines changed type. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-14drm/i915: Use drm_encoder_crtc_ok()Thierry Reding
The intel_encoder_crtc_ok() is a duplicate of the drm_encoder_crtc_ok() function that used to be only available in the DRM CRTC helpers. It has recently been moved to the core, so the duplicate can now be dropped. Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-01-10drm/i915: 830M doesn't have an LVDS portVille Syrjälä
There's no LVDS port on 830M so don't go reading the LVDS control register. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-10drm/i915: No panel fitter on 830M or non-mobile gen2/3 platformsVille Syrjälä
PFIT_CONTROL doesn't exist on 830M, so avoid reading it in i9xx_get_pfit_config(). Also assume that only mobile gen2/3 chipsets have a panel fitter. This matches the documentation, but I didn't have real hardware to verify. Gen4 docmentation is a bit inconsistent, but experimenetation on my LPT machine suggests that the panel fitter is available on non-mobile gen4 platforms. At least on this machine panel fitter appears works just fine even on VGA output. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-10drm/i915: vlv: W/a for hotplug/manual VGA detectionImre Deak
VGA detection requires the reference clock to be on, so make sure this is the case. This fixes VGA hotplug/manual detection where all pipes are off and so we would normally disable all clocks. v2: - Instead of disabling PSR clock gating, force the reference clock on through the DPLL_A register. (Kin Chan S <kin.s.chan@intel.com>) v3: - Move enabling of the clock to intel_reset_dpio() and use the DPLL_B register instead, where we already have a similar tweak for the CRI clock. (Ville) Reported-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-10drm/i915: vlv: make CRI clock enabling explicit during resumeImre Deak
intel_init_dpio() isn't called during resume, so we won't set the CRI clock enable bit during that time. Move the enabling to intel_reset_dpio() instead. Note that the HW reset value for this bit is 1, so probably this patch won't make any difference. We should still make the setting explicit, since BIOS could change things under us. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-10drm/i915: only apply GAMMA_MODE IPS WA on HSWPaulo Zanoni
The WA is mentioned in HSW's GAMMA_MODE register documentation, but not on on BDW's documentation, so let's assume it is not needed there. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-10drm/i915: Introduce new intel_output_name()Damien Lespiau
That we can use for debugging purposes. v2: Use designated initializers for the 'names' array (Paulo Zanoni, Jani Nikula). Add a check in case the array has a hole (which can now remain unnoticed with designated initializers) (Jani Nikula) Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (for v1) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-10drm/i915: don't set modes for 2 connectors on the same encoderPaulo Zanoni
In some cases we have more than 1 connector associated to an encoder (e.g., SDVO, Haswell DP/HDMI) and we can only set a mode for one of these connectors. If we only allowed modesets for connected connectors we would never need this patch, but since we do allow modeset for disconnected connectors we may see user space trying to set modes on the two connectors attached to the same encoder, so we need to forbid that. This problem can be reproduced by running the following intel-gpu-tools test case: ./kms_setmode --run-subtest clone-exclusive-crtc Thanks to Daniel Vetter for providing a version of this patch on pastebin. Credits-to: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-10drm/i915: Drop I915_ prefix from HAS_FBCDaniel Vetter
My OCD just couldn't let this slide. Spotted while reviewing Ville's patch to only flip planes when we have FBC. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-10drm/i915: Don't swap planes on 830MVille Syrjälä
Looks like 830M doesn't quite like it when you try to move a plane from one pipe to another. It seems that the plane's old pipe has to be active even if the plane is already disabled, otherwise the relevant register just won't accept new values. The following commit: commit 1f1c2e2468f937cefd6bcb645c959c7b5d9821df Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Thu Nov 28 17:30:01 2013 +0200 drm/i915: Swap primary planes on gen2 for FBC caused a regression on 830M. It will attempt to swap the planes when the driver is loaded, but at that time only pipe A might be active, so plane A gets disabled, but plane B won't get enabled since pipe B is not active when we try to move the plane over to pipe A. There's no reason to swap planes on 830M since it doesn't support FBC. Change the logic a bit to limit the plane swapping to platforms which actually support FBC. This should avoid getting a black screen on 830M. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-10drm/i915: Don't grab crtc mutexes in intel_modeset_gem_init()Ville Syrjälä
When the pipe A force quirk is applied the code will attempt to grab a crtc mutex during intel_modeset_setup_hw_state(). If we're already holding all crtc mutexes this will obviously deadlock every time. So instead of using drm_modeset_lock_all() just grab the mode_config.mutex. This is enough to avoid the unlocked mutex warnings from certain lower level functions. The regression was introduced in: commit 027476642811f8559cbe00ef6cc54db230e48a20 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Mon Dec 2 11:08:06 2013 +0200 drm/i915: Take modeset locks around intel_modeset_setup_hw_state() Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: stable@vger.kernel.org [danvet: Add cc: stable since the offending commit has that, too.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-08drm/i915: fix wrong PLL debug messages.Paulo Zanoni
LPT does have PCH refclk, but it's different form the IBX/CPT/PPT one and doesn't use the same structs. It is wrong to have a message saying that "LPT does not has PCH refclk" (sic). While at it, signal that we only want this function on IBX/CPT/PPT by renaming it and adding a WARN. On HSW we also print "0 shared PLLs initialized", but we *do* have shared PLLs on HSW (LCPLL, WRPLL, SPLL) and we *do* initialize them. We just don't use "struct intel_shared_dpll". So remove the debug message. In the future we may want to rename all that "intel shared pll" code to "ibx shared pll", but I'll leave this to another patch. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-08drm/i915/bdw: don't try to check IPS state on BDW v2Jesse Barnes
According to Art, we don't have a way to read back the state reliably at runtime, through the control reg or the mailbox, at least not without risking disabling it again. So drop the readout and checking on BDW. v2: drop TODO comment (Paulo) move POSTING_READ of control reg under HSW branch in disable (Paulo) always report IPS as enabled on BDW (Paulo) References: https://bugs.freedesktop.org/show_bug.cgi?id=71906 Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-08drm/i915: fix fastboot pfit disable hack to update pipe w/hJesse Barnes
When fastbooting, we read out the pipe timings early on, and then in a panel fitted config, disable the fitter later. But we weren't updating the pipe src h/w, which meant the mouse cursor was clipped to the pfitted size rather than the native size set later. Fix that up so the cursor is visible in the new mode. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-08drm/i915: check modeset state after a pipe_set_base if using fastbootJesse Barnes
Otherwise we won't check the state until the next DPMS transition, which may never happen. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-07drm/i915: avoid unclaimed registers when capturing the error statePaulo Zanoni
We're iterating over the CPU transcoders, so check for the correct power domain. This fixes many "unclaimed register" error messages. This can be reproduced by the IGT test mentioned below, but we still get a FAIL when we run it. Testcase: igt/kms_lip/flip-vs-panning-vs-hang Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-06Revert "drm/i915: assume all GM45 Acer laptops use inverted backlight PWM"Alexander van Heukelum
My Acer 8510TZ stops displaying anything when X starts with Linus' current tree. I bisected it down to commit ee1452d74584. This patch reverts commit ee1452d74584. After the revert, everything works as before. Signed-off-by: Alexander van Heukelum <heukelum@fastmail.fm> Reported-by: Dylan Borg <borgdylan@hotmail.com> (for a Acer Extensa 5635Z) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-17drm/i915: Use the correct GMCH_CTRL register for Sandybridge+Chris Wilson
The GMCH_CTRL register (or MGCC in the spec) is at a different address on Sandybridge, and the address to which we currently write to is undefined. These stray writes appear to upset (hard hang) my Ivybridge machine whilst it is in UEFI mode. Note that the register is still marked as locked RO on Sandybridge, so vgaarb is still dysfunctional. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: stable@vger.kernel.org Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-17drm/i915: Move ILK/SNB/IVB over to the HSW WM codeVille Syrjälä
The new HSW watermark code can now handle ILK/SNB/IVB as well, so switch them over. Kill the old code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-17drm/i915/vlv: split DPIO init and resetJesse Barnes
We only need to init the reg offset for DPIO once, but we need to reset DPIO at resume time and at init time. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-17drm/i915/vlv: add early DPIO init v3Jesse Barnes
Just add an early init since we may need to access DPIO regs early on. The init call in modeset_init_hw is also needed for the resume case, when we need to reset DPIO to keep things happy. v2: split reset and reg init v3: split patches (Daniel) Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-13drm/i915: change CRTC assertion on LCPLL disablePaulo Zanoni
Currently, PC8 is enabled at modeset_global_resources, which is called after intel_modeset_update_state. Due to this, there's a small race condition on the case where we start enabling PC8, then do a modeset while PC8 is still being enabled. The racing condition triggers a WARN because intel_modeset_update_state will mark the CRTC as enabled, then the thread that's still enabling PC8 might look at the data structure and think that PC8 is being enabled while a pipe is enabled. Despite the WARN, this is not really a bug since we'll wait for the PC8-enabling thread to finish when we call modeset_global_resources. The spec says the CRTC cannot be enabled when we disable LCPLL, so we had a check for crtc->base.enabled. If we change to crtc->active we will still prevent disabling LCPLL while the CRTC is enabled, and we will also prevent the WARN above. This is a replacement for the previous patch named "drm/i915: get/put PC8 when we get/put a CRTC" Testcase: igt/pm_pc8/modeset-lpsp-stress-no-wait Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (cherry picked from commit 798183c54799fbe1e5a5bfabb3a8c0505ffd2149 from -next due to Dave's report.) Reported-by: Dave Jones <davej@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-12drm/i915: split intel_ddi_pll_mode_set in 2 piecesPaulo Zanoni
The first piece, intel_ddi_pll_select, finds a PLL and assigns it to the CRTC, but doesn't write any register. It can also fail in case it doesn't find a PLL. The second piece, intel_ddi_pll_enable, uses the information stored by intel_ddi_pll_select to actually enable the PLL by writing to its register. This function can't fail. We also have some refcount sanity checks here. The idea is that one day we'll remove all the functions that touch registers from haswell_crtc_mode_set to haswell_crtc_enable, so we'll call intel_ddi_pll_select at haswell_crtc_mode_set and then call intel_ddi_pll_enable at haswell_crtc_enable. Since I'm already touching this code, let's take care of this particular split today. v2: - Clock on the debug message is in KHz - Add missing POSTING_READ Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> [danvet: Bikeshed comments.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-11drm/i915: Decrease gen2 vco frequency minimum to 908 MHzVille Syrjälä
On my 855 machine the BIOS uses the following DPLL settings: DPLL 0x90016000 FP0 = 0x61207 FP1 = 0x21207 With the 66MHz SSC refclock, that puts the BIOS generated VCO frequency at ~908 MHz, which is lower than the 930 MHz limit we have currently. This also results in the pixel clock coming out significantly higher than the requested 65 MHz when we try to recompute it. Reduce the the VCO limit to 908 MHz. Combined with the earlier SSC reference clock accuracy fix, this results in the pixel clock coming out as 65.08 MHz which is quite close to the target. For some reason the BIOS uses 64.881 MHz, which isn't quite as close. This makes kms_flip wf_vblank-ts-check pass for the first time on this machine \o/ Cc: Bruno Prémont <bonbons@linux-vserver.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Bruno Prémont <bonbons@linux-vserver.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-11drm/i915: Fix 66 MHz LVDS SSC freq for gen2Ville Syrjälä
Store the SSC refclock frequency in kHz to get more accuracy. Currently we're pretending that 66 MHz is ~66000 kHz, when in fact it is actually ~66667 kHz. By storing the less rounded kHz value we get a much better accuracy for out pixel clock calculations. Cc: Bruno Prémont <bonbons@linux-vserver.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Bruno Prémont <bonbons@linux-vserver.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-11drm/i915: Increase gen2 vco frequency limit to 1512 MHzVille Syrjälä
Bruno Prémont has a 855 machine with a 1400x1050 LVDS screen. The VBT mode is as follows: 0:"1400x1050" 0 108000 1400 1416 1528 1688 1050 1051 1054 1066 0x8 0xa The BIOS uses the following DPLL settings: DPLL = 0x90020000 FP0 = 0x2140e FP1 = 0x21207 That puts the BIOS generated VCO frequency at 1512 MHz, which is higher than the 1400 MHz limit we have currently. Let's bump the VCO limit to 1512 MHz and see what happens. Cc: Bruno Prémont <bonbons@linux-vserver.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Bruno Prémont <bonbons@linux-vserver.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-11drm/i915: Change N divider minimum from 3 to 2 for gen2Ville Syrjälä
Bruno Prémont has a 855 machine with a 1400x1050 LVDS screen. The VBT mode is as follows: 0:"1400x1050" 0 108000 1400 1416 1528 1688 1050 1051 1054 1066 0x8 0xa The BIOS uses the following DPLL settings: DPLL = 0x90020000 FP0 = 0x2140e FP1 = 0x21207 We can't generate that pixel clock currently as we're limiting the N divider to at least 3, whereas the BIOS uses a value of 2. Let's reduce the N minimum to 2 and see what happens. Cc: Bruno Prémont <bonbons@linux-vserver.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Bruno Prémont <bonbons@linux-vserver.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-11drm/i915: Extract p2 divider correctly for gen2 LVDS dual channelVille Syrjälä
In order to determine the correct p2 divider for LVDS on gen2, we need to check the CLKB mode from the LVDS port register to determine if we're dealing with single or dual channel LVDS. Cc: Bruno Prémont <bonbons@linux-vserver.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Bruno Prémont <bonbons@linux-vserver.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-10drm/i915: add runtime PM support on HaswellPaulo Zanoni
The code to enable/disable PC8 already takes care of saving and restoring all the registers we need to save/restore, so do a put() call when we enable PC8 and a get() call when we disable it. Ideally, in order to make it easier to add runtime PM support to other platforms, we should move some things from the PC8 code to the runtime PM code, but let's do this later, since we can make Haswell work right now. V2: - Rebase Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> [danvet: Don't actually enable runtime pm since I didn't merge all patches.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-10drm/i915: do not assert DE_PCH_EVENT_IVB enabledPaulo Zanoni
The current code was checking if all bits of "val" were enabled and DE_PCH_EVENT_IVB was disabled. The new code doesn't care about the state of DE_PCH_EVENT_IVB: it just checks if everything else is 1. The goal is that future patches may completely disable interrupts, and the LCPLL-disabling code shouldn't care about the state of DE_PCH_EVENT_IVB. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> [danvet: I think the commit message is actually wrong in it's description of what the old test checked, but the new one seems sane. So meh.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-10drm/i915: WARN if !HAS_PC8 when enabling/disabling PC8Paulo Zanoni
We already have some checks and shouldn't be reaching these places on !HAS_PC8 platforms, but add a WARN, just in case. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-10drm/i915: Move VLV PHY CRI clock enable into intel_init_dpio()Ville Syrjälä
The CRI clock is related to the display PHY, so the setup belongs in intel_init_dpio(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-09Merge tag 'v3.13-rc3' into drm-intel-next-queuedDaniel Vetter
Linux 3.13-rc3 I need a backmerge for two reasons: - For merging the ppgtt patches from Ben I need to pull in the bdw support. - We now have duplicated calls to intel_uncore_forcewake_reset in the setup code to due 2 different patches merged into -next and 3.13. The conflict is silen so I need the merge to be able to apply Deepak's fixup patch. Conflicts: drivers/gpu/drm/i915/intel_display.c Trivial conflict, it doesn't even show up in the merge diff. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-06drm/i915: change CRTC assertion on LCPLL disablePaulo Zanoni
Currently, PC8 is enabled at modeset_global_resources, which is called after intel_modeset_update_state. Due to this, there's a small race condition on the case where we start enabling PC8, then do a modeset while PC8 is still being enabled. The racing condition triggers a WARN because intel_modeset_update_state will mark the CRTC as enabled, then the thread that's still enabling PC8 might look at the data structure and think that PC8 is being enabled while a pipe is enabled. Despite the WARN, this is not really a bug since we'll wait for the PC8-enabling thread to finish when we call modeset_global_resources. The spec says the CRTC cannot be enabled when we disable LCPLL, so we had a check for crtc->base.enabled. If we change to crtc->active we will still prevent disabling LCPLL while the CRTC is enabled, and we will also prevent the WARN above. This is a replacement for the previous patch named "drm/i915: get/put PC8 when we get/put a CRTC" Testcase: igt/pm_pc8/modeset-lpsp-stress-no-wait Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-04drm/i915: Swap primary planes on gen2 for FBCVille Syrjälä
Only plane A is FBC capable on gen2 (like gen3), but the panel fitter is hooked up to pipe B, so we want to prefer pipe B + plane A. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Add the code comment Chris requested in his review.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-26 17:05:55 +0000