aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/intel_lvds.c
AgeCommit message (Collapse)Author
2013-02-14drm/i915: rip out helper->disable noop functionsDaniel Vetter
Now that the driver is in control of whether it needs to disable everything at take-over or not, we can rip this all out. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-01-21Merge branch 'drm-kms-locking' of ↵Dave Airlie
git://people.freedesktop.org/~danvet/drm-intel into drm-next The aim of this locking rework is that ioctls which a compositor should be might call for every frame (set_cursor, page_flip, addfb, rmfb and getfb/create_handle) should not be able to block on kms background activities like output detection. And since each EDID read takes about 25ms (in the best case), that always means we'll drop at least one frame. The solution is to add per-crtc locking for these ioctls, and restrict background activities to only use the global lock. Change-the-world type of events (modeset, dpms, ...) need to grab all locks. Two tricky parts arose in the conversion: - A lot of current code assumes that a kms fb object can't disappear while holding the global lock, since the current code serializes fb destruction with it. Hence proper lifetime management using the already created refcounting for fbs need to be instantiated for all ioctls and interfaces/users. - The rmfb ioctl removes the to-be-deleted fb from all active users. But unconditionally taking the global kms lock to do so introduces an unacceptable potential stall point. And obviously changing the userspace abi isn't on the table, either. Hence this conversion opportunistically checks whether the rmfb ioctl holds the very last reference, which guarantees that the fb isn't in active use on any crtc or plane (thanks to the conversion to the new lifetime rules using proper refcounting). Only if this is not the case will the code go through the slowpath and grab all modeset locks. Sane compositors will never hit this path and so avoid the stall, but userspace relying on these semantics will also not break. All these cases are exercised by the newly added subtests for the i-g-t kms_flip, tested on a machine where a full detect cycle takes around 100 ms. It works, and no frames are dropped any more with these patches applied. kms_flip also contains a special case to exercise the above-describe rmfb slowpath. * 'drm-kms-locking' of git://people.freedesktop.org/~danvet/drm-intel: (335 commits) drm/fb_helper: check whether fbcon is bound drm/doc: updates for new framebuffer lifetime rules drm: don't hold crtc mutexes for connector ->detect callbacks drm: only grab the crtc lock for pageflips drm: optimize drm_framebuffer_remove drm/vmwgfx: add proper framebuffer refcounting drm/i915: dump refcount into framebuffer debugfs file drm: refcounting for crtc framebuffers drm: refcounting for sprite framebuffers drm: fb refcounting for dirtyfb_ioctl drm: don't take modeset locks in getfb ioctl drm: push modeset_lock_all into ->fb_create driver callbacks drm: nest modeset locks within fpriv->fbs_lock drm: reference framebuffers which are on the idr drm: revamp framebuffer cleanup interfaces drm: create drm_framebuffer_lookup drm: revamp locking around fb creation/destruction drm: only take the crtc lock for ->cursor_move drm: only take the crtc lock for ->cursor_set drm: add per-crtc locks ...
2013-01-20drm/i915: use drm_modeset_lock_allDaniel Vetter
Two exceptions: - debugfs files only read information which is not related to crtc, so can stay on the modeset_config lock. - Same holds for the edp vdd work in intel_dp.c. Add a corresponding WARN_ON and a comment next to the intel_dp struct fields for documentation. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-01-07Revert "drm/i915: no lvds quirk for Zotac ZDBOX SD ID12/ID13"Daniel Vetter
This reverts commit 9756fe38d10b2bf90c81dc4d2f17d5632e135364. The bogus lvds output is actually a lvds->hdmi bridge, which we don't really support. But unconditionally disabling it breaks some existing setups. Reported-by: John Tapsell <johnflux@gmail.com> References: http://permalink.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/17237 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-20drm/i915: Return the real error code from intel_set_mode()Chris Wilson
Note: This patch also adds a little helper intel_crtc_restore_mode for the common case where we do a full modeset but with the same parameters, e.g. to undo bios damage or update a property. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> [danvet: Added note.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-29drm/i915: enable intel_lvds->pre_pll_enable for ilk+, tooDaniel Vetter
Only two things needed adjustment: - pipe select for PCH_CPT - There's no dithering bit on ilk+ in the lvds ctl reg Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-29drm/i915: move intel_update_lvds to intel_lvds->pre_pll_enableDaniel Vetter
A few things needed to change: - HAS_PCH_SPLIT since ilk+ is not yet converted to this. - s/LVDS/intel_lvds->reg/ to prep for ilk conversion - replace the clock.p2 == 7 check with a is_dual_link check - s/adjusted_mode/intel_lvds->fixed_mode v2: Rebase on top of Jani Nikula's panel rework. I'm wondering whether we shouldn't add an attached_panel pointer to intel_encoder, to replace the encoder private ->attached_connector pointers, since that's essentially what we need. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-29drm/i915: add intel_lvds->regDaniel Vetter
To ditch at least some of the PCH_SPLIT ? PCH_LVDS : LVDS code ... v2: Rebase on top of Jani Nikula's panel rework. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-29drm/i915: track is_dual_link in intel_lvdsDaniel Vetter
Yeah, all users (both the clock selection special cases and the lvds pin pair stuff) are still in common code, but this will change. v2: Rebase on top of Jani Nikula's panel rework. v3: Incorporate review from Paulo Zanoni: - s/__is_dual_link_lvds/compute_is_dual_link_lvds - kill dev_priv->lvds_val - drop spurious whitespace change v4: Add a debug printk to display the dual-link status, as suggested by Paulo Zanoni in review. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v3) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-29drm/i915: move is_dual_link_lvds to intel_lvds.cDaniel Vetter
Just a prep patch to make this a property of intel_lvds. Makes more sense, removes clutter from intel_display.c and eventually I want to move all the encoder special cases wrt clock handling to encoders anyway. v2: Add an intel_ prefixe to is_dual_link_lvds since it's non-static now. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-29drm/i915: force restore on lid openDaniel Vetter
There seem to be indeed some awkwards machines around, mostly those without OpRegion support, where the firmware changes the display hw state behind our backs when closing the lid. This force-restore logic has been originally introduced in commit c1c7af60892070e4b82ad63bbfb95ae745056de0 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Thu Sep 10 15:28:03 2009 -0700 drm/i915: force mode set at lid open time but after the modeset-rework we've disabled it in the vain hope that it's no longer required: commit 3b7a89fce3e3dc96b549d6d829387b4439044d0d Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Sep 17 22:27:21 2012 +0200 drm/i915: fix OOPS in lid_notify Alas, no. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54677 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57434 Tested-by: Krzysztof Mazur <krzysiek@podlesie.net> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-22drm/i915: Report the origin of the LVDS fixed panel modeChris Wilson
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jani Nikula <jani.nikula@intel.com> [danvet: resolve conflict around the call to intel_crtc_mode_get. And add the missing NULL check Chris spotted while at it.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-22drm/i915: LVDS fallback to fixed-mode if EDID not presentChris Wilson
Use the recorded panel fixed-mode to populate the get_modes() request in the absence of an EDID. Fixes regression from commit 9cd300e038d492af4990b04e127e0bd2df64b1ca Author: Jani Nikula <jani.nikula@intel.com> Date: Fri Oct 19 14:51:52 2012 +0300 drm/i915: Move cached EDID to intel_connector Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Jani Nikula <jani.nikula@intel.com> [danvet: Drop the retval-changing hunk, as suggested by Jani in his review and acked by Chris.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-21drm/i915: drm_connector_property -> drm_object_propertyRob Clark
v2: Rebased. Signed-off-by: Rob Clark <rob@ti.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> (v1) [danvet: Pimp commit message a bit.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-20Merge branch 'for-airlied' of git://people.freedesktop.org/~danvet/drm-intel ↵Dave Airlie
into drm-next Daniel writes: Highlights of this -next round: - ivb fdi B/C fixes - hsw sprite/plane offset fixes from Damien - unified dp/hdmi encoder for hsw, finally external dp support on hsw (Paulo) - kill-agp and some other prep work in the gtt code from Ben - some fb handling fixes from Ville - massive pile of patches to align hsw VGA with the spec and make it actually work (Paulo) - pile of workarounds from Jesse, mostly for vlv, but also some other related platforms - start of a dev_priv reorg, that thing grew out of bounds and chaotic - small bits&pieces all over the place, down to better error handling for load-detect on gen2 (Chris, Jani, Mika, Zhenyu, ...) On top of the previous pile (just copypasta): - tons of hsw dp prep patches form Paulo - round scheduled work items and timers to nearest second (Chris) - some hw workarounds (Jesse&Damien) - vlv dp support and related fixups (Vijay et al.) - basic haswell dp support, not yet wired up for external ports (Paulo) - edp support (Paulo) - tons of refactorings to prepare for the above (Paulo) - panel rework, unifiying code between lvds and edp panels (Jani) - panel fitter scaling modes (Jani + Yuly Novikov) - panel power improvements, should now work without the BIOS setting it up - extracting some dp helpers from radeon/i915 and move them to drm_dp_helper.c - randome pile of workarounds (Damien, Ben, ...) - some cleanups for the register restore code for suspend/resume - secure batchbuffer support, should enable tear-free blits on gen6+ Chris) - random smaller fixlets and cleanups. * 'for-airlied' of git://people.freedesktop.org/~danvet/drm-intel: (231 commits) drm/i915: Restore physical HWS_PGA after resume drm/i915: Report amount of usable graphics memory in MiB drm/i915/i2c: Track users of GMBUS force-bit drm/i915: Allocate the proper size for contexts. drm/i915: Update load-detect failure paths for modeset-rework drm/i915: Clear unused fields of mode for framebuffer creation drm/i915: Always calculate 8xx WM values based on a 32-bpp framebuffer drm/i915: Fix sparse warnings in from AGP kill code drm/i915: Missed lock change with rps lock drm/i915: Move the remaining gtt code drm/i915: flush system agent TLBs on SNB drm/i915: Kill off now unused gen6+ AGP code drm/i915: Calculate correct stolen size for GEN7+ drm/i915: Stop using AGP layer for GEN6+ drm/i915: drop the double-OP_STOREDW usage in blt_ring_flush drm/i915: don't rewrite the GTT on resume v4 drm/i915: protect RPS/RC6 related accesses (including PCU) with a new mutex drm/i915: put ring frequency and turbo setup into a work queue v5 drm/i915: don't block resume on fb console resume v2 drm/i915: extract l3_parity substruct from dev_priv ...
2012-10-26drm/i915/lvds: move fitting mode from intel_lvds_connector to intel_panelJani Nikula
Prepare for supporting scaling mode configuration also in eDP. Includes a drive-by-removal of an outdated comment about fitting mode. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-22drm/i915: Move cached EDID to intel_connectorJani Nikula
Move the cached EDID from intel_dp and intel_lvds_connector to intel_connector. Unify cached EDID handling for LVDS and eDP, in preparation for adding more generic EDID caching later. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-22drm/i915: Move the fixed mode to intel_panelJani Nikula
Pave the way for sharing some logic between eDP and LVDS. Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk> CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-22drm/i915: Create generic intel_panel for LVDS and eDPJani Nikula
Create a generic struct intel_panel for sharing a data structure and code between eDP and LVDS panels. Add the new struct to intel_connector so that later on we can have generic EDID and mode reading functions with EDID caching that transparently fallback to fixed mode when EDID is not available. Add intel_panel as a dummy first, and move data (such as the mentioned fixed mode) to it in later patches. Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk> CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Fixup tiny conflict in intel_dp_destroy.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-22drm/i915/lvds: Move some connector specific info across from the encoderJani Nikula
As there is 1:1 mapping between encoder and connector for the LVDS, the goal is to simply reduce the amount of noise within the connector functions, i.e. we split the encoder/connector for LVDS as best we can and try to only operate on the LVDS connector from the connector funcs and the LVDS encoder form the encoder funcs. Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk> CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-22drm/i915: Backlight setup requires connector so pass it as parameterJani Nikula
Get rid of saved int_lvds_connector and int_edp_connector in drm_i915_private. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-22drm/i915/lvds: Move the acpi_lid_notifier from drm_i915_private to the connectorJani Nikula
Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk> CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-22drm/i915/lvds: Introduce intel_lvds_connectorJani Nikula
Introduce a local structure to move LVDS specific information away from the drm_i915_private and onto the LVDS connector. Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk> CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-22drm/i915/lvds: Rename intel_lvds to intel_lvds_encoderJani Nikula
In preparation for introducing intel_lvds_connector to move some of the LVDS specific storage away from drm_i915_private, first rename the encoder to avoid potential confusion. Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk> CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-22Merge branch 'drm-intel-fixes' of ↵Dave Airlie
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes Daniel writes: The big thing is the disabling of the hsw support by default, cc: stable. We've aimed for basic hsw support in 3.6, but due to a few bad happenstances we've screwed up and only 3.8 will have better modeset support than vesa. To avoid yet another round of fallout from such a gaffle on for the next platform we've added a module option to disable early hw support by default. That should also give us more flexibility in bring-up. Otherwise just small fixes: - 3 fixes from Egbert for sdvo corner cases - invert-brightness quirk entry from Egbert - revert a dp link training change, it regresses some setups - and shut up a spurious WARN in our gem fault handler. - regression fix for an oops on bit17 swizzling machines, introduce in 3.7 - another no-lvds quirk * 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel: drm/i915: Initialize obj->pages before use by i915_gem_object_do_bit17_swizzle() drm/i915: Add no-lvds quirk for Supermicro X7SPA-H drm/i915: Insert i915_preliminary_hw_support variable. drm/i915: shut up spurious WARN in the gtt fault handler Revert "drm/i915: Try harder to complete DP training pattern 1" DRM/i915: Restore sdvo_flags after dtd->mode->dtd Roundrtrip. DRM/i915: Don't clone SDVO LVDS with analog. DRM/i915: Add QUIRK_INVERT_BRIGHTNESS for NCR machines. DRM/i915: Don't delete DPLL Multiplier during DAC init.
2012-10-19drm/i915: Add no-lvds quirk for Supermicro X7SPA-HChris Wilson
Reported-and-tested-by: Francois Tigeot <ftigeot@wolfpond.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55375 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-03Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds
Pull drm merge (part 1) from Dave Airlie: "So first of all my tree and uapi stuff has a conflict mess, its my fault as the nouveau stuff didn't hit -next as were trying to rebase regressions out of it before we merged. Highlights: - SH mobile modesetting driver and associated helpers - some DRM core documentation - i915 modesetting rework, haswell hdmi, haswell and vlv fixes, write combined pte writing, ilk rc6 support, - nouveau: major driver rework into a hw core driver, makes features like SLI a lot saner to implement, - psb: add eDP/DP support for Cedarview - radeon: 2 layer page tables, async VM pte updates, better PLL selection for > 2 screens, better ACPI interactions The rest is general grab bag of fixes. So why part 1? well I have the exynos pull req which came in a bit late but was waiting for me to do something they shouldn't have and it looks fairly safe, and David Howells has some more header cleanups he'd like me to pull, that seem like a good idea, but I'd like to get this merge out of the way so -next dosen't get blocked." Tons of conflicts mostly due to silly include line changes, but mostly mindless. A few other small semantic conflicts too, noted from Dave's pre-merged branch. * 'drm-next' of git://people.freedesktop.org/~airlied/linux: (447 commits) drm/nv98/crypt: fix fuc build with latest envyas drm/nouveau/devinit: fixup various issues with subdev ctor/init ordering drm/nv41/vm: fix and enable use of "real" pciegart drm/nv44/vm: fix and enable use of "real" pciegart drm/nv04/dmaobj: fixup vm target handling in preparation for nv4x pcie drm/nouveau: store supported dma mask in vmmgr drm/nvc0/ibus: initial implementation of subdev drm/nouveau/therm: add support for fan-control modes drm/nouveau/hwmon: rename pwm0* to pmw1* to follow hwmon's rules drm/nouveau/therm: calculate the pwm divisor on nv50+ drm/nouveau/fan: rewrite the fan tachometer driver to get more precision, faster drm/nouveau/therm: move thermal-related functions to the therm subdev drm/nouveau/bios: parse the pwm divisor from the perf table drm/nouveau/therm: use the EXTDEV table to detect i2c monitoring devices drm/nouveau/therm: rework thermal table parsing drm/nouveau/gpio: expose the PWM/TOGGLE parameter found in the gpio vbios table drm/nouveau: fix pm initialization order drm/nouveau/bios: check that fixed tvdac gpio data is valid before using it drm/nouveau: log channel debug/error messages from client object rather than drm client drm/nouveau: have drm debugging macros build on top of core macros ...
2012-10-02UAPI: (Scripted) Convert #include "..." to #include <path/...> in drivers/gpu/David Howells
Convert #include "..." to #include <path/...> in drivers/gpu/. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Dave Airlie <airlied@redhat.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by: Dave Jones <davej@redhat.com>
2012-10-02UAPI: (Scripted) Remove redundant DRM UAPI header #inclusions from drivers/gpu/.David Howells
Remove redundant DRM UAPI header #inclusions from drivers/gpu/. Remove redundant #inclusions of core DRM UAPI headers (drm.h, drm_mode.h and drm_sarea.h). They are now #included via drmP.h and drm_crtc.h via a preceding patch. Without this patch and the patch to make include the UAPI headers from the core headers, after the UAPI split, the DRM C sources cannot find these UAPI headers because the DRM code relies on specific -I flags to make #include "..." work on headers in include/drm/ - but that does not work after the UAPI split without adding more -I flags. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Dave Airlie <airlied@redhat.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by: Dave Jones <davej@redhat.com>
2012-09-24Merge tag 'v3.6-rc7' into drm-intel-next-queuedDaniel Vetter
Manual backmerge of -rc7 to resolve a silent conflict leading to compile failure in drivers/gpu/drm/i915/intel_hdmi.c. This is due to the bugfix in -rc7: commit b98b60167279df3acac9422c3c9820d9ebbcf9fb Author: Wang Xingchao <xingchao.wang@intel.com> Date: Thu Sep 13 07:43:22 2012 +0800 drm/i915: HDMI - Clear Audio Enable bit for Hot Plug Since this code moved around a lot in -next git put that snippet at the wrong spot. I've tried to fix this by making the conflict explicit by merging a version for next with: commit 3cce574f0190dd149472059fb69267cf83d290f9 Author: Wang Xingchao <xingchao.wang@intel.com> Date: Thu Sep 13 11:19:00 2012 +0800 drm/i915: HDMI - Clear Audio Enable bit for Hot Plug unconditionally But that failed to solve the entire problem. To avoid pushing out further -nightly branch to our QA where this is broken, do the backmerge and manually add the stuff git adds to -next from the patch in -fixes. Note that this doesn't show up in git's merge diff (and hence is also not handled by git rerere), which adds to the reasons why I'd like to fix this with a verbose backmerge. The git merge diff only shows a bunch of trivial conflicts of the "code changed in lines next to each another" kind. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-18drm/i915: fix OOPS in lid_notifyDaniel Vetter
This goes back to commit c1c7af60892070e4b82ad63bbfb95ae745056de0 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Thu Sep 10 15:28:03 2009 -0700 drm/i915: force mode set at lid open time It was used to fix an issue on a i915GM based Thinkpad X41, which somehow clobbered the modeset state at lid close time. Since then massive amounts of things changed: Tons of fixes to the modeset sequence, OpRegion support, better integration with the acpi code. Especially OpRegion /should/ allow us to control the display hw cooperatively with the firmware, without the firmware clobbering the hw state behind our backs. So it's dubious whether we still need this. The second issue is that it's unclear who's responsibility it actually is to restore the mode - Chris Wilson suggests to just emit a hotplug event and let userspace figure things out. The real reason I've stumbled over this is that the new modeset code breaks drm_helper_resume_force_mode - it OOPSes derefing a NULL vfunc pointer. The reason this wasn't caught in testing earlier is that in commit c9354c85c1c7bac788ce57d3c17f2016c1c45b1d Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Mon Nov 2 09:29:55 2009 -0800 i915: fix intel graphics suspend breakage due to resume/lid event confusion logic was added to _not_ restore the modeset state after a resume. And since most machines are configured to auto-suspend on lid-close, this neatly papered over the issue. Summarizing, this shouldn't be required on any platform supporting OpRegion. And none of the really old machines I have here seem to require it either. Hence I'm inclined to just rip it out. But in case that there are really firmwares out there that clobber the hw state, replace it with a call to intel_modset_check_state. This will ensure that we catch any issues as soon as they happen. Cc: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06drm/i915: s/intel_encoder_disable/intel_encoder_noopDaniel Vetter
Because that's what it is. Unfortunately we can't rip this out because the fb helper has an incetious relationship with the crtc helper - it likes to call disable_unused_functions, among other things. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06drm/i915: use staged outuput config in lvds->mode_fixupDaniel Vetter
- Use the check_cloned helper from the previous patch. - Use encoder->new_crtc to check crtc properties. v2: Kill the double negation with s/!non_cloned/is_cloned, suggested by Jesse Barnes. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06drm/i915/lvds: implement get_hw_stateDaniel Vetter
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06drm/i915: rip out encoder->prepare/commitDaniel Vetter
With the new infrastructure we're doing this when enabling/disabling the entire display pipe. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06drm/i915: copy&paste drm_crtc_helper_set_modeDaniel Vetter
Together with the static helper functions drm_crtc_prepare_encoders and drm_encoder_disable (which will be simplified in the next patch, but for now are 1:1 copies). Again, no changes beside new names for these functions. Also call our new set_mode instead of the crtc helper one now in all the places we've done so far. v2: Call the function just intel_set_mode to better differentia it from intel_crtc_mode_set which really only does the ->mode_set step of the entire modeset sequence on one crtc. Whereas this function does the global change. Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06drm/i915/lvds: convert to encoder disable/enableDaniel Vetter
With the previous patch LVDS is also a simple case. Treat it accordingly. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-24i915: Quirk no_lvds on Gigabyte GA-D525TUD ITX motherboardCalvin Walton
This board is incorrectly detected as having an LVDS connector, resulting in the VGA output (the only available output on the board) showing the console only in the top-left 1024x768 pixels, and an extra LVDS connector appearing in X. It's a desktop Mini-ITX board using an Atom D525 CPU with an NM10 chipset. I've had this board for about a year, but this is the first time I noticed the issue because I've been running it headless for most of its life. Signed-off-by: Calvin Walton <calvin.walton@kepstin.ca>
2012-07-25drm/i915: simplify possible_clones computationDaniel Vetter
Intel hw only has one MUX for encoders, so outputs are either not cloneable or all in the same group of cloneable outputs. This neatly simplifies the code and allows us to ditch some ugly if cascades in the dp and hdmi init code (well, we need these if cascades for other stuff still, but that can be taken care of in follow-up patches). Note that this changes two things: - dvo can now be cloned with sdvo, but dvo is gen2 whereas sdvo is gen3+, so no problem. Note that the old code had a bug and didn't allow cloning crt with dvo (but only the other way round). - sdvo-lvds can now be cloned with sdvo-non-tv. Spec says this won't work, but the only reason I've found is that you can't use the panel-fitter (used for lvds upscaling) with anything else. But we don't use the panel fitter for sdvo-lvds. Imo this part of Bspec is a) rather confusing b) mostly as a guideline to implementors (i.e. explicitly stating what is already implicit from the spec, without always going into the details of why). So I think we can ignore this - worst case we'll get a bug report from a user with with sdvo-lvds and sdvo-tmds and have to add that special case back in. Because sdvo lvds is a bit special explain in comments why sdvo LVDS outputs can be cloned, but native LVDS and eDP can't be cloned - we use the panel fitter for the later, but not for sdvo. Note that this also uncoditionally initializes the panel_vdd work used by eDP. Trying to be clever doesn't buy us anything (but strange bugs) and this way we can kill the is_edp check. v2: Incorporate review from Paulo - Add in a missing space. - Pimp comment message to address his concerns. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-25drm/i915/lvds: ditch ->prepare special caseDaniel Vetter
LVDS is the first output where dpms on/off and prepare/commit don't perfectly match. Now the idea behind this special case seems to be that for simple resolution changes on the LVDS we don't need to stop the pipe, because (at least on newer chips) we can adjust the panel fitter on the fly. There are a few problems with the current code though: - We still stop and restart the pipe unconditionally, because the crtc helper code isn't flexible enough. - We show some ugly flickering, especially when changing crtcs (this the crtc helper would actually take into account, but we don't implement the encoder->get_crtc callback required to make this work properly). So it doesn't even work as advertised. I agree that it would be nice to do resolution changes on LVDS (and also eDP) whithout blacking the screen where the panel fitter allows to do that. But imo we should implement this as a special case a few layers up in the mode set code, akin to how we already detect simple framebuffer changes (and only update the required registers with ->mode_set_base). Until this is all in place, make our lives easier and just rip it out. Also note that this seems to fix actual bugs with enabling the lvds output, see: http://lists.freedesktop.org/archives/intel-gfx/2012-July/018614.html Cc: Takashi Iwai <tiwai@suse.de> Cc: Giacomo Comes <comes@naic.edu> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Takashi Iwai <tiwai@suse.de> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-19drm: Make the .mode_fixup() operations mode argument a const pointerLaurent Pinchart
The passed mode must not be modified by the operation, make it const. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-07-05drm/i915: introduce for_each_encoder_on_crtcDaniel Vetter
We already have this pattern at quite a few places, and moving part of the modeset helper stuff into the driver will add more. v2: Don't clobber the crtc struct name with the macro parameter ... v3: Convert two more places noticed by Paulo Zanoni. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-22drm/i915: no lvds quirk for Zotac ZDBOX SD ID12/ID13Sjoerd Simons
This box claims to have an LVDS interface but doesn't actually have one. Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-12drm/i915: allow pipe A for lvds on gen4Daniel Vetter
Given the havoc the missing backlight pipe select code might have caused, let's try to re-enabled pipe A support for lvds on gen4 hw. Just to see what all blows up ... Note though that commit 4add75c43f39573edc884d46b7c2b7414f01171a Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sat Dec 4 17:49:46 2010 +0000 drm/i915: Allow LVDS to be on pipe A for Ironlake+ claims that this caused tons of spurious wakeups somehow. More details can be found in the old revert: commit 12e8ba25ef52f19e7a42e61aecb3c1fef83b2a82 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Sep 7 23:39:28 2010 +0100 Revert "drm/i915: Allow LVDS on pipe A on gen4+" Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16307 Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-12drm/i915: properly enable the blc controller on the right pipeDaniel Vetter
On gen4+ we have a bitfield to specify from which pipe the backlight controller should take it's clock. For PCH split platforms we've already set these up, but only at initialization time. And without taking into account the 3rd pipe added with ivb. For gen4, we've completely ignored these. Although we do restrict lvds to the 2nd pipe, so this is only a problem on machines where we boot up with the lvds on the first pipe. So restructure the code to enable the backlight on the right pipe at modeset time. v2: For odd reasons panel_enable_backlight gets called twice in a modeset, so we can't WARN_ON in there if the backlight controller is switched on already. v3: backlight enable can also be called through dpms on, so the check in there is legit. Update the comment to reflect that. Tested-By: Kamal Mostafa <kamal@canonical.com> Bugzilla: https://bugs.launchpad.net/bugs/954661 Cc: Carsten Emde <C.Emde@osadl.org> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-12drm/i915: clear up backlight #define confusion on gen4+Daniel Vetter
- Regroup definitions for BLC_PWM_CTL so that they're all together and and ordered according to the bitfields. - Add all missing definitions for BLC_PWM_CTL2. - Use the BLM_ (for backlight modulation) prefix consistently. - Note that combination mode (i.e. also taking the legacy backlight control value from pci config space into account) is gen4 only. - Move the new registers for PCH-split machines up, they're an almost match for the gen4 defitions. Prefix the special PCH-only bits with BLM_PCH_. Also add the pipe C select bit for ivb. - Rip out the second pair of PCH polarity definitions - they're only valid on early (pre-production) ilk silicon. - Adapt the existing code to use the new definitions. This has the nice benefit of killing a magic (1 << 30) left behind be Jesse Barnes. No functional changes in this patch. Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-24drm/i915: no lvds quirk for HP t5740e Thin ClientJan-Benedict Glaw
This box has DisplayPort and VGA, but no LVDS. Product specs are at http://h10010.www1.hp.com/wwpc/us/en/sm/WF25a/12454-12454-321959-338927-3640406-4282707.html?dnr=1 and dmidecode output can be found at http://www.getslash.de/bug_attachments/dmidecode-t5740e.txt Signed-off-by: Jan-Benedict Glaw <jbglaw@getslash.de> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-07Merge tag 'v3.4-rc6' into drm-intel-nextDaniel Vetter
Conflicts: drivers/gpu/drm/i915/intel_display.c Ok, this is a fun story of git totally messing things up. There /shouldn't/ be any conflict in here, because the fixes in -rc6 do only touch functions that have not been changed in -next. The offending commits in drm-next are 14415745b2..1fa611065 which simply move a few functions from intel_display.c to intel_pm.c. The problem seems to be that git diff gets completely confused: $ git diff 14415745b2..1fa611065 is a nice mess in intel_display.c, and the diff leaks into totally unrelated functions, whereas $git diff --minimal 14415745b2..1fa611065 is exactly what we want. Unfortunately there seems to be no way to teach similar smarts to the merge diff and conflict generation code, because with the minimal diff there really shouldn't be any conflicts. For added hilarity, every time something in that area changes the + and - lines in the diff move around like crazy, again resulting in new conflicts. So I fear this mess will stay with us for a little longer (and might result in another backmerge down the road). Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-02fixing dmi match for hp t5745 and hp st5747 thin clientMarc Gariepy
Match the correct information which is DMI_PRODUCT_NAME instead of DMI_BOARD_NAME See dmidecode information on launchpad for both thin client: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/911920 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/911916 Signed-off-by: Marc Gariepy <mgariepy@ubuntu.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-04-16drm/i915: don't clobber the special upscaling lvds timingsDaniel Vetter
This regression has been introduced in commit ca9bfa7eed20ea34e862804e62aae10eb159edbb Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sat Jan 28 14:49:20 2012 +0100 drm/i915: fixup interlaced vertical timings confusion, part 1 Unfortunately that commit failed to take into account that the lvds code does some special adjustements to the crtc timings for upscaling an centering. Fix this by explicitly computing crtc timings in the lvds mode fixup function and setting a special flag in mode->private_flags if the crtc timings have been adjusted. v2: Add a comment to explain the new mode driver private flag, suggested by Eugeni Dodonov. v3: Kill the confusing and now redundant set_crtcinfo call in intel_fixed_panel_mode, noticed by Chris Wilson. Reported-and-Tested-by: Hans de Bruin <jmdebruin@xmsnet.nl> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43071 Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-27 21:16:04 +0000