summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915
AgeCommit message (Collapse)Author
2013-10-05drm/i915/dp: increase i2c-over-aux retry interval on AUX DEFERJani Nikula
commit 8d16f258217f2f583af1fd57c5144aa4bbe73e48 upstream. There is no clear cut rules or specs for the retry interval, as there are many factors that affect overall response time. Increase the interval, and even more so on branch devices which may have limited i2c bit rates. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reference: https://bugs.freedesktop.org/show_bug.cgi?id=60263 Tested-by: Nicolas Suzor <nic@suzor.com> Reviewed-by: Todd Previte <tprevite@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-09-07drm/i915: ivb: fix edp voltage swing reg valImre Deak
commit 77fa4cbd5fa389e28419bbe8ac491b5fdd54840d upstream. Fix the typo introduced in commit 1a2eb4604b85c5efb343da8a4dcf41288fcfca85 Author: Keith Packard <keithp@keithp.com> Date: Wed Nov 16 16:26:07 2011 -0800 drm/i915: Hook up Ivybridge eDP This fixes eDP link-training failures and cases where all voltage swing /pre-emphasis levels were tried and failed during clock recovery and - as a fallback - we go on to do channel equalization with the last voltage swing/pre-emphasis level which will succeed. Both issues can lead to a blank screen. v2: - improve commit message Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64880 Tested-by: Jeremy Moles <cubicool@gmail.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-29drm/i915: Invalidate TLBs for the rings after a resetChris Wilson
commit 884020bf3d2a3787a1cc6df902e98e0eec60330b upstream. After any "soft gfx reset" we must manually invalidate the TLBs associated with each ring. Empirically, it seems that a suspend/resume or D3-D0 cycle count as a "soft reset". The symptom is that the hardware would fail to note the new address for its status page, and so it would continue to write the shadow registers and breadcrumbs into the old physical address (now used by something completely different, scary). Whereas the driver would read the new status page and never see any progress, it would appear that the GPU hung immediately upon resume. Based on a patch by naresh kumar kachhi <naresh.kumar.kacchi@intel.com> Reported-by: Thiago Macieira <thiago@kde.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64725 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Thiago Macieira <thiago@kde.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-20drm/i915/lvds: ditch ->prepare special caseDaniel Vetter
commit 520c41cf2fa029d1e8b923ac2026f96664f17c4b upstream. 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 Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Takashi Iwai <tiwai@suse.de> Cc: Giacomo Comes <comes@naic.edu> Tested-by: Takashi Iwai <tiwai@suse.de> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Haitao Zhang <haitao.zhang@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlightKamal Mostafa
commit e85843bec6c2ea7c10ec61238396891cc2b753a9 upstream. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=47941 BugLink: https://bugs.launchpad.net/bugs/1163720 BugLink: https://bugs.launchpad.net/bugs/1162026 Some machines suffer from non-functional backlight controls if BLM_PCH_PWM_ENABLE is set, so provide a quirk to avoid doing so. Apply this quirk to Dell XPS 13 models. [ kamal: backport to 3.4 ] Tested-by: Eric Griffith <EGriffith92@gmail.com> Tested-by: Kent Baxley <kent.baxley@canonical.com> Signed-off-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-20drm/i915: prefer VBT modes for SVDO-LVDS over EDIDDaniel Vetter
commit c3456fb3e4712d0448592af3c5d644c9472cd3c1 upstream. In commit 53d3b4d7778daf15900867336c85d3f8dd70600c Author: Egbert Eich <eich@suse.de> Date: Tue Jun 4 17:13:21 2013 +0200 drm/i915/sdvo: Use &intel_sdvo->ddc instead of intel_sdvo->i2c for DDC Egbert Eich fixed a long-standing bug where we simply used a non-working i2c controller to read the EDID for SDVO-LVDS panels. Unfortunately some machines seem to not be able to cope with the mode provided in the EDID. Specifically they seem to not be able to cope with a 4x pixel mutliplier instead of a 2x one, which seems to have been worked around by slightly changing the panels native mode in the VBT so that the dotclock is just barely above 50MHz. Since it took forever to notice the breakage it's fairly safe to assume that at least for SDVO-LVDS panels the VBT contains fairly sane data. So just switch around the order and use VBT modes first. v2: Also add EDID modes just in case, and spell Egbert correctly. v3: Elaborate a bit more about what's going on on Chris' machine. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65524 Reported-and-tested-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Egbert Eich <eich@suse.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-13drm/i915: no lvds quirk for hp t5740Ben Mesman
commit 45a211d75137b1ac869a8a758a6667f15827a115 upstream. Last year, a patch was made for the "HP t5740e Thin Client" (see http://lists.freedesktop.org/archives/dri-devel/2012-May/023245.html). This device reports an lvds panel, but does not really have one. The predecessor of this device is the "hp t5740", which also does not have an lvds panel. This patch will add the same quirk for this device. Signed-off-by: Ben Mesman <ben@bnc.nl> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-13drm/i915/sdvo: Use &intel_sdvo->ddc instead of intel_sdvo->i2c for DDC.Egbert Eich
commit 53d3b4d7778daf15900867336c85d3f8dd70600c upstream. In intel_sdvo_get_lvds_modes() the wrong i2c adapter record is used for DDC. Thus the code will always have to rely on a LVDS panel mode supplied by VBT. In most cases this succeeds, so this didn't get detected for quite a while. This regression seems to have been introduced in commit f899fc64cda8569d0529452aafc0da31c042df2e Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Jul 20 15:44:45 2010 -0700 drm/i915: use GMBUS to manage i2c links Signed-off-by: Egbert Eich <eich@suse.de> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Add note about which commit likely introduced this issue.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-11drm/i915: Fall back to bit banging mode for DVO transmitter detectionDavid Müller
commit e4bfff54ed3f5de88f5358504c78c2cb037813aa upstream. As discussed in this thread http://lists.freedesktop.org/archives/dri-devel/2013-April/037411.html GMBUS based DVO transmitter detection seems to be unreliable which could result in an unusable DVO port. The attached patch fixes this by falling back to bit banging mode for the time DVO transmitter detection is in progress. Signed-off-by: David Müller <d.mueller@elsoft.ch> Tested-by: David Müller <d.mueller@elsoft.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-11drm/i915: Add no-lvds quirk for Fujitsu Esprimo Q900Christian Lamparter
commit 9e9dd0e889c76c786e8f2e164c825c3c06dea30c upstream. The "Mobile Sandy Bridge CPUs" in the Fujitsu Esprimo Q900 mini desktop PCs are probably misleading the LVDS detection code in intel_lvds_supported. Nothing is connected to the LVDS ports in these systems. Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-04-16drm/i915: Use the correct size of the GTT for placing the per-process entriesChris Wilson
commit 9a0f938bde74bf9e50bd75c8de9e38c1787398cd upstream. The current layout is to place the per-process tables at the end of the GTT. However, this is currently using a hardcoded maximum size for the GTT and not taking in account limitations imposed by the BIOS. Use the value for the total number of entries allocated in the table as provided by the configuration registers. Reported-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Matthew Garret <mjg@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-04-05drm/i915: Don't clobber crtc->fb when queue_flip failsVille Syrjälä
commit 4a35f83b2b7c6aae3fc0d1c4554fdc99dc33ad07 upstream. Restore crtc->fb to the old framebuffer if queue_flip fails. While at it, kill the pointless intel_fb temp variable. v2: Update crtc->fb before queue_flip and restore it back after a failure. Backported for 3.4-stable. Adjusted context only. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reported-and-Tested-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Lingzhu Xiang <lxiang@redhat.com> Reviewed-by: CAI Qian <caiqian@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-28i915: initialize CADL in opregionLekensteyn
commit d627b62ff8d4d36761adbcd90ff143d79c94ab22 upstream. This is rather a hack to fix brightness hotkeys on a Clevo laptop. CADL is not used anywhere in the driver code at the moment, but it could be used in BIOS as is the case with the Clevo laptop. The Clevo B7130 requires the CADL field to contain at least the ID of the LCD device. If this field is empty, the ACPI methods that are called on pressing brightness / display switching hotkeys will not trigger a notification. As a result, it appears as no hotkey has been pressed. Reference: https://bugs.freedesktop.org/show_bug.cgi?id=45452 Tested-by: Peter Wu <lekensteyn@gmail.com> Signed-off-by: Peter Wu <lekensteyn@gmail.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-28drm/i915: bounds check execbuffer relocation countKees Cook
commit 3118a4f652c7b12c752f3222af0447008f9b2368 upstream. It is possible to wrap the counter used to allocate the buffer for relocation copies. This could lead to heap writing overflows. CVE-2013-0913 v3: collapse test, improve comment v2: move check into validate_exec_list Signed-off-by: Kees Cook <keescook@chromium.org> Reported-by: Pinkie Pie Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-28drm/i915: restrict kernel address leak in debugfsKees Cook
commit 2563a4524febe8f4a98e717e02436d1aaf672aa2 upstream. Masks kernel address info-leak in object dumps with the %pK suffix, so they cannot be used to target kernel memory corruption attacks if the kptr_restrict sysctl is set. Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-20drm/i915: Increase the RC6p threshold.Stéphane Marchesin
commit 0920a48719f1ceefc909387a64f97563848c7854 upstream. This increases GEN6_RC6p_THRESHOLD from 100000 to 150000. For some reason this avoids the gen6_gt_check_fifodbg.isra warnings and associated GPU lockups, which makes my ivy bridge machine stable. Signed-off-by: Stéphane Marchesin <marcheu@chromium.org> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-20drm/i915: EBUSY status handling added to i915_gem_fault().Dmitry Rogozhkin
commit e79e0fe380847493266fba557217e2773c61bd1b upstream. Subsequent threads returning EBUSY from vm_insert_pfn() was not handled correctly. As a result concurrent access from new threads to mmapped data caused SIGBUS. Note that this fixes i-g-t/tests/gem_threaded_tiled_access. Tested-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-02-28drm/i915: Set i9xx sdvo clock limits according to specificationsPatrik Jakobsson
commit 4f7dfb6788dd022446847fbbfbe45e13bedb5be2 upstream. The Intel PRM says the M1 and M2 divisors must be in the range of 10-20 and 5-9. Since we do all calculations based on them being register values (which are subtracted by 2) we need to specify them accordingly. Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56359 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-02-28drm/i915: disable shared panel fitter for pipeMika Kuoppala
commit 24a1f16de97c4cf0029d9acd04be06db32208726 upstream. If encoder is switched off by BIOS, but the panel fitter is left on, we never try to turn off the panel fitter and leave it still attached to the pipe - which can cause blurry output elsewhere. Based on work by Chris Wilson <chris@chris-wilson.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58867 Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Tested-by: Andreas Sturmlechner <andreas.sturmlechner@gmail.com> [danvet: Remove the redundant HAS_PCH_SPLIT check and add a tiny comment.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-27drm/i915: Implement WaDisableHiZPlanesWhenMSAAEnabledDaniel Vetter
commit 4283908ef7f11a72c3b80dd4cf026f1a86429f82 upstream. Quoting from Bspec, 3D_CHICKEN1, bit 10 This bit needs to be set always to "1", Project: DevSNB " Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Abdallah Chatila <abdallah.chatila@ericsson.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-27drm/i915: Invalidate the relocation presumed_offsets along the slow pathChris Wilson
commit 262b6d363fcff16359c93bd58c297f961f6e6273 upstream. In the slow path, we are forced to copy the relocations prior to acquiring the struct mutex in order to handle pagefaults. We forgo copying the new offsets back into the relocation entries in order to prevent a recursive locking bug should we trigger a pagefault whilst holding the mutex for the reservations of the execbuffer. Therefore, we need to reset the presumed_offsets just in case the objects are rebound back into their old locations after relocating for this exexbuffer - if that were to happen we would assume the relocations were valid and leave the actual pointers to the kernels dangling, instant hang. Fixes regression from commit bcf50e2775bbc3101932d8e4ab8c7902aa4163b4 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sun Nov 21 22:07:12 2010 +0000 drm/i915: Handle pagefaults in execbuffer user relocations Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55984 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@fwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-01-17Revert "drm/i915: no lvds quirk for Zotac ZDBOX SD ID12/ID13"Daniel Vetter
commit 48e858340dae43189a4e55647f6eac736766f828 upstream. 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> Cc: Luis Henriques <luis.henriques@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-17drm/i915: Flush the pending flips on the CRTC before modificationChris Wilson
commit 5bb61643f6a70d48de9cfe91ad0fee0d618b6816 upstream. This was meant to be the purpose of the intel_crtc_wait_for_pending_flips() function which is called whilst preparing the CRTC for a modeset or before disabling. However, as Ville Syrjala pointed out, we set the pending flip notification on the old framebuffer that is no longer attached to the CRTC by the time we come to flush the pending operations. Instead, we can simply wait on the pending unpin work to be finished on this CRTC, knowning that the hardware has therefore finished modifying the registers, before proceeding with our direct access. Fixes i-g-t/flip_test on non-pch platforms. pch platforms simply schedule the flip immediately when the pipe is disabled, leading to other funny issues. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Added i-g-t note and cc: stable] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Julien Cristau <jcristau@debian.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-17drm/i915: call drm_handle_vblank before finish_page_flipDaniel Vetter
commit 74d44445afb9f50126eba052adeb89827cee88f3 upstream. ... since finish_page_flip needs the vblank timestamp generated in drm_handle_vblank. Somehow all the gmch platforms get it right, but all the pch platform irq handlers get is wrong. Hooray for copy& pasting! Currently this gets papered over by a gross hack in finish_page_flip. A second patch will remove that. Note that without this, the new timestamp sanity checks in flip_test occasionally get tripped up, hence the cc: stable tag. Reviewed-by: mario.kleiner@tuebingen.mpg.de Tested-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> [bwh: Backported to 3.2: no loop over pipes in ivybridge_irq_handler(), so make a similar change to that in ironlake_irq_handler()] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Julien Cristau <jcristau@debian.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-17drm/i915: Fix GT_MODE default valueBen Widawsky
commit f8f2ac9a76b0f80a6763ca316116a7bab8486997 upstream. I can't even find how I figured this might be needed anymore. But sure enough, the value I'm reading back on platforms doesn't match what the docs recommends. It seemed to fix Chris' GT1 in limited testing as well. Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> [bwh: Backported to 3.2: open-code _MASKED_BIT_{ENABLE,DISABLE}] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Julien Cristau <jcristau@debian.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-17drm/i915: prevent possible pin leak on error pathEugeni Dodonov
commit ab3951eb74e7c33a2f5b7b64d72e82f1eea61571 upstream. We should not hit this under any sane conditions, but still, this does not looks right. Reported-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com> CC: Chris Wilson <chris@chris-wilson.co.uk> CC: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Chris Wlison <chris@chris-wilson.co.uk> Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Julien Cristau <jcristau@debian.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-17drm/i915: Reduce a pin-leak BUG into a WARNChris Wilson
commit 7e81a42e341a4f15d76624b7c02ffb21b085b56f upstream. Pin-leaks persist and we get the perennial bug reports of machine lockups to the BUG_ON(pin_count==MAX). If we instead loudly report that the object cannot be pinned at that time it should prevent the driver from locking up, and hopefully restore a semblance of working whilst still leaving us a OOPS to debug. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Julien Cristau <jcristau@debian.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-17drm/i915: only enable sdvo hotplug irq if neededJani Nikula
commit fcbc50da7753b210b4442ca9abc4efbd4e481f6e upstream. Avoid constant wakeups caused by noisy irq lines when we don't even care about the irq. This should be particularly useful for i945g/gm where the hotplug has been disabled: commit 768b107e4b3be0acf6f58e914afe4f337c00932b Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri May 4 11:29:56 2012 +0200 drm/i915: disable sdvo hotplug on i945g/gm v2: While at it, remove the bogus hotplug_active read, and do not mask hotplug_active[0] before checking whether the irq is needed, per discussion with Daniel on IRC. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=38442 Tested-by: Dominik Köppl <dominik@devwork.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Julien Cristau <jcristau@debian.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-17drm/i915: SDVO hotplug have different interrupt status bits for i915/i965/g4xChris Wilson
commit 084b612ecf8e59973576b2f644e6949609c79375 upstream. Note that gen3 is the only platform where we've got the bit definitions right, hence the workaround of disabling sdvo hotplug support on i945g/gm is not due to misdiagnosis of broken hotplug irq handling ... Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: add some blurb about sdvo hotplug fail on i945g/gm I've wondered about while reviewing.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> [bwh: Backported to 3.2: - Adjust context - Handle all three cases in i915_driver_irq_postinstall() as there are not separate functions for gen3 and gen4+ - Carry on using IS_SDVOB() in intel_sdvo_init()] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Julien Cristau <jcristau@debian.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-17drm/i915: add some barriers when changing DIPsPaulo Zanoni
commit 9d9740f099f2eaf309c4c9cbc0d732507140db28 upstream. On IVB and older, we basically have two registers: the control and the data register. We write a few consecutitve times to the control register, and we need these writes to arrive exactly in the specified order. Also, when we're changing the data register, we need to guarantee that anything written to the control register already arrived (since changing the control register can change where the data register points to). Also, we need to make sure all the writes to the data register happen exactly in the specified order, and we also *can't* read the data register during this process, since reading and/or writing it will change the place it points to. So invoke the "better safe than sorry" rule and just be careful and put barriers everywhere :) On HSW we still have a control register that we write many times, but we have many data registers. Demanded-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> [bwh: Backported to 3.2: - There are only two write_infoframe functions to be modified - The other VIDEO_DIP_CTL writes are in entirely different functions] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Julien Cristau <jcristau@debian.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-17drm/i915: don't pwrite tiled objects through the gttDaniel Vetter
commit c07496fa61f4c5cb2addd1c57f6b22fcaeea2eeb upstream. ... we will botch up the bit17 swizzling. Furthermore tiled pwrite is a (now) unused slowpath, so no one really cares. This fixes the last swizzling issues I have with i-g-t on my bit17 swizzling i915G. No regression, it's been broken since the dawn of gem, but it's nice for regression tracking when really _all_ i-g-t tests work. Actually this is not true, Chris Wilson noticed while reviewing this patch that the commit commit d9e86c0ee60f323e890484628f351bf50fa9a15d Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Nov 10 16:40:20 2010 +0000 drm/i915: Pipelined fencing [infrastructure] contained a functional change that broke things. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> [jcristau: adjust context for 3.4] Signed-off-by: Julien Cristau <jcristau@debian.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-17drm/i915: Wait for all pending operations to the fb before disabling the pipeChris Wilson
commit 0f91128d88bbb8b0a8e7bb93df2c40680871d45a upstream. During modeset we have to disable the pipe to reconfigure its timings and maybe its size. Userspace may have queued up command buffers that depend upon the pipe running in a certain configuration and so the commands may become confused across the modeset. At the moment, we use a less than satisfactory kick-scanline-waits should the GPU hang during the modeset. It should be more reliable to wait for the pending operations to complete first, even though we still have a window for userspace to submit a broken command buffer during the modeset. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Julien Cristau <jcristau@debian.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-17drm/i915: Add wait_for in init_ring_commonSean Paul
commit f01db988ef6f6c70a6cc36ee71e4a98a68901229 upstream. I have seen a number of "blt ring initialization failed" messages where the ctl or start registers are not the correct value. Upon further inspection, if the code just waited a little bit, it would read the correct value. Adding the wait_for to these reads should eliminate the issue. Signed-off-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Julien Cristau <jcristau@debian.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-17drm/i915: Check VBIOS value for determining LVDS dual channel mode, tooTakashi Iwai
commit b03543857fd75876b96e10d4320b775e95041bb7 upstream. Currently i915 driver checks [PCH_]LVDS register bits to decide whether to set up the dual-link or the single-link mode. This relies implicitly on that BIOS initializes the register properly at boot. However, BIOS doesn't initialize it always. When the machine is booted with the closed lid, BIOS skips the LVDS reg initialization. This ends up in blank output on a machine with a dual-link LVDS when you open the lid after the boot. This patch adds a workaround for that problem by checking the initial LVDS register value in VBT. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=37742 Tested-By: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Julien Cristau <jcristau@debian.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-17drm/i915: hold forcewake around ring hw initDaniel Vetter
commit b7884eb45ec98c0d34c7f49005ae9d4b4b4e38f6 upstream. Empirical evidence suggests that we need to: On at least one ivb machine when running the hangman i-g-t test, the rings don't properly initialize properly - the RING_START registers seems to be stuck at all zeros. Holding forcewake around this register init sequences makes chip reset reliable again. Note that this is not the first such issue: commit f01db988ef6f6c70a6cc36ee71e4a98a68901229 Author: Sean Paul <seanpaul@chromium.org> Date: Fri Mar 16 12:43:22 2012 -0400 drm/i915: Add wait_for in init_ring_common added delay loops to make RING_START and RING_CTL initialization reliable on the blt ring at boot-up. So I guess it won't hurt if we do this unconditionally for all force_wake needing gpus. To avoid copy&pasting of the HAS_FORCE_WAKE check I've added a new intel_info bit for that. v2: Fixup missing commas in static struct and properly handling the error case in init_ring_common, both noticed by Jani Nikula. Reported-and-tested-by: Yang Guang <guang.a.yang@intel.com> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50522 Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> [bwh: Backported to 3.2: - drop changes to Haswell device information - NEEDS_FORCE_WAKE didn't refer to Valley View anyway] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> [jcristau: further context adjustments for 3.4] Signed-off-by: Julien Cristau <jcristau@debian.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-17drm/i915: move NEEDS_FORCE_WAKE to i915_drv.cJesse Barnes
commit b7d84096d3c45f4e397e913da4ce24ec9a32022e upstream. It's only used by the main read/write functions, so we can keep it with them. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Acked-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Julien Cristau <jcristau@debian.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-17drm/i915: fix up ivb plane 3 pageflipsDaniel Vetter
commit cb05d8dedefa3066bf5d74ef88c6ca6cf4bd1c87 upstream. Or at least plug another gapping hole. Apparrently hw desingers only moved the bit field, but did not bother ot re-enumerate the planes when adding support for a 3rd pipe. Discovered by i-g-t/flip_test. This may or may not fix the reference bugzilla, because that one smells like we have still larger fish to fry. v2: Fixup the impossible case to catch programming errors, noticed by Chris Wilson. References: https://bugs.freedesktop.org/show_bug.cgi?id=50069 Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Julien Cristau <jcristau@debian.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-17drm/i915: Unpin the flip target if we fail to queue the flipChris Wilson
commit 83d4092b0381e5dd6f312b2ec57121dcf0fcbade upstream. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Julien Cristau <jcristau@debian.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-17drm/i915: disable cpt phase pointer fdi rx workaroundDaniel Vetter
commit 539526b4137bc0e7a8806c38c8522f226814a0e6 upstream. We've originally added this in commit 291427f5fdadec6e4be2924172e83588880e1539 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Fri Jul 29 12:42:37 2011 -0700 drm/i915: apply phase pointer override on SNB+ too and then copy-pasted it over to ivb/ppt. The w/a was originally added for ilk/ibx in commit 5b2adf897146edeac6a1e438fb67b5a53dbbdf34 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Thu Oct 7 16:01:15 2010 -0700 drm/i915: add Ironlake clock gating workaround for FDI link training and fixed up a bit in commit 6f06ce184c765fd8d50669a8d12fdd566c920859 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Tue Jan 4 15:09:38 2011 -0800 drm/i915: set phase sync pointer override enable before setting phase sync pointer It turns out that this w/a isn't actually required on cpt/ppt and positively harmful on ivb/ppt when using fdi B/C links - it results in a black screen occasionally, with seemingfully everything working as it should. The only failure indication I've found in the hw is that eventually (but not right after the modeset completes) a pipe underrun is signalled. Big thanks to Arthur Runyan for all the ideas for registers to check and changes to test, otherwise I couldn't ever have tracked this down! Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: "Runyan, Arthur J" <arthur.j.runyan@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: CAI Qian <caiqian@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-17drm/i915: make the panel fitter work on pipes B and C on IVBPaulo Zanoni
commit 13888d78c664a1f61d7b09d282f5916993827a40 upstream. I actually found this problem on Haswell, but then discovered Ivy Bridge also has it by reading the spec. I don't have the hardware to test this. 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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-12-17drm/i915: do not default to 18 bpp for eDP if missing from VBTJani Nikula
commit 9a30a61f3516871c5c638fd7c025fbaa11ddf7fe upstream. commit 500a8cc466a24e2fbc4c86ef9c6467ae2ffdeb0c Author: Zhenyu Wang <zhenyuw@linux.intel.com> Date: Wed Jan 13 11:19:52 2010 +0800 drm/i915: parse eDP panel color depth from VBT block originally introduced parsing bpp for eDP from VBT, with a default of 18 bpp if the eDP BIOS data block is not present. Turns out that default seems to break the Macbook Pro with retina display, as noted in commit 4344b813f105a19f793f1fd93ad775b784648b95 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Aug 10 11:10:20 2012 +0200 drm/i915: ignore eDP bpc settings from vbt Since we can't ignore bpc settings from VBT completely after all, get rid of the default. Do not clamp eDP to 18 bpp by default if the eDP BDB is missing from VBT. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Tested-by: Henrik Rydberg <rydberg@euromail.se> [danvet: paste in the updated commit message from irc.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-12-17drm/i915: do not ignore eDP bpc settings from vbtJani Nikula
commit 2f4f649a69a9eb51f6e98130e19dd90a260a4145 upstream. There are laptops out there that need the eDP bpc from VBT. This is effectively a revert of commit 4344b813f105a19f793f1fd93ad775b784648b95 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Aug 10 11:10:20 2012 +0200 drm/i915: ignore eDP bpc settings from vbt but putting the VBT check after the EDID check to see them both in dmesg if this clamps more than the EDID. We have enough history with bpc clamping to warrant the extra debug info. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47641 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56401 Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-12-10drm/i915: Add no-lvds quirk for Supermicro X7SPA-HChris Wilson
commit c31407a3672aaebb4acddf90944a114fa5c8af7b upstream. 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> Signed-off-by: Peter Huewe <peterhuewe@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-12-10i915: Quirk no_lvds on Gigabyte GA-D525TUD ITX motherboardCalvin Walton
commit a51d4ed01e5bb39d2cf36a12f9976ab08872c192 upstream. 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> Signed-off-by: Peter Huewe <peterhuewe@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-26drm/i915: fix overlay on i830MDaniel Vetter
commit a9193983f4f292a82a00c72971c17ec0ee8c6c15 upstream. The overlay on the i830M has a peculiar failure mode: It works the first time around after boot-up, but consistenly hangs the second time it's used. Chris Wilson has dug out a nice errata: "1.5.12 Clock Gating Disable for Display Register Address Offset: 06200h–06203h "Bit 3 Ovrunit Clock Gating Disable. 0 = Clock gating controlled by unit enabling logic 1 = Disable clock gating function DevALM Errata ALM049: Overlay Clock Gating Must be Disabled: Overlay & L2 Cache clock gating must be disabled in order to prevent device hangs when turning off overlay.SW must turn off Ovrunit clock gating (6200h) and L2 Cache clock gating (C8h)." Now I've nowhere found that 0xc8 register and hence couldn't apply the l2 cache workaround. But I've remembered that part of the magic that the OVERLAY_ON/OFF commands are supposed to do is to rearrange cache allocations so that the overlay scaler has some scratch space. And while pondering how that could explain the hang the 2nd time we enable the overlay, I've remembered that the old ums overlay code did _not_ issue the OVERLAY_OFF cmd. And indeed, disabling the OFF cmd results in the overlay working flawlessly, so I guess we can workaround the lack of the above workaround by simply never disabling the overlay engine once it's enabled. Note that we have the first part of the above w/a already implemented in i830_init_clock_gating - leave that as-is to avoid surprises. v2: Add a comment in the code. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47827 Tested-by: Rhys <rhyspuk@gmail.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> [bwh: Backported to 3.2: - Adjust context - s/intel_ring_emit(ring, /OUT_RING(/] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-17drm/i915: clear the entire sdvo infoframe bufferDaniel Vetter
commit b6e0e543f75729f207b9c72b0162ae61170635b2 upstream. Like in the case of native hdmi, which is fixed already in commit adf00b26d18e1b3570451296e03bcb20e4798cdd Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Tue Sep 25 13:23:34 2012 -0300 drm/i915: make sure we write all the DIP data bytes we need to clear the entire sdvo buffer to avoid upsetting the display. Since infoframe buffer writing is now a bit more elaborate, extract it into it's own function. This will be useful if we ever get around to properly update the ELD for sdvo. Also #define proper names for the two buffer indexes with fixed usage. v2: Cite the right commit above, spotted by Paulo Zanoni. v3: I'm too stupid to paste the right commit. v4: Ben Hutchings noticed that I've failed to handle an underflow in my loop logic, breaking it for i >= length + 8. Since I've just lost C programmer license, use his solution. Also, make the frustrated 0-base buffer size a notch more clear. Reported-and-tested-by: Jürg Billeter <j@bitron.ch> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=25732 Cc: Paulo Zanoni <przanoni@gmail.com> Cc: Ben Hutchings <ben@decadent.org.uk> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-17drm/i915: fixup infoframe support for sdvoDaniel Vetter
commit 81014b9d0b55fb0b48f26cd2a943359750d532db upstream. At least the worst offenders: - SDVO specifies that the encoder should compute the ecc. Testing also shows that we must not send the ecc field, so copy the dip_infoframe struct to a temporay place and avoid the ecc field. This way the avi infoframe is exactly 17 bytes long, which agrees with what the spec mandates as a minimal storage capacity (with the ecc field it would be 18 bytes). - Only 17 when sending the avi infoframe. The SDVO spec explicitly says that sending more data than what the device announces results in undefined behaviour. - Add __attribute__((packed)) to the avi and spd infoframes, for otherwise they're wrongly aligned. Noticed because the avi infoframe ended up being 18 bytes large instead of 17. We haven't noticed this yet because we don't use the uint16_t fields yet (which are the only ones that would be wrongly aligned). This regression has been introduce by 3c17fe4b8f40a112a85758a9ab2aebf772bdd647 is the first bad commit commit 3c17fe4b8f40a112a85758a9ab2aebf772bdd647 Author: David Härdeman <david@hardeman.nu> Date: Fri Sep 24 21:44:32 2010 +0200 i915: enable AVI infoframe for intel_hdmi.c [v4] Patch tested on my g33 with a sdvo hdmi adaptor. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=25732 Tested-by: Peter Ross <pross@xvid.org> (G35 SDVO-HDMI) Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-31drm/i915: no lvds quirk for Zotac ZDBOX SD ID12/ID13Sjoerd Simons
commit 9756fe38d10b2bf90c81dc4d2f17d5632e135364 upstream. 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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-21drm/i915: use adjusted_mode instead of mode for checking the 6bpc force flagJani Nikula
commit 0c96c65b48fba3ffe9822a554cbc0cd610765cd5 upstream. The dithering introduced in commit 3b5c78a35cf7511c15e09a9b0ffab290a42d9bcf Author: Adam Jackson <ajax@redhat.com> Date: Tue Dec 13 15:41:00 2011 -0800 drm/i915/dp: Dither down to 6bpc if it makes the mode fit stores the INTEL_MODE_DP_FORCE_6BPC flag in the private_flags of the adjusted mode, while i9xx_crtc_mode_set() and ironlake_crtc_mode_set() use the original mode, without the flag, so it would never have any effect. However, the BPC was clamped by VBT settings, making things work by coincidence, until that part was removed in commit 4344b813f105a19f793f1fd93ad775b784648b95 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Aug 10 11:10:20 2012 +0200 Use adjusted_mode instead of mode when checking for INTEL_MODE_DP_FORCE_6BPC to make the flag have effect. v2: Don't forget to fix this in i9xx_crtc_mode_set() also, pointed out by Daniel both before and after sending the first patch. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47621 CC: Adam Jackson <ajax@redhat.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-02Revert: drm/i915: correctly order the ring init sequenceGreg Kroah-Hartman
This reverts commit 57ecc93ce680b1ace1f9e79d588dabe32353202c which really is commit 0d8957c8a90bbb5d34fab9a304459448a5131e06 upstream as it has been reported to cause problems in the 3.4.y kernel series. Reported-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com> Cc: Andreas Sturmlechner <andreas.sturmlechner@gmail.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Yang Guang <guang.a.yang@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.0.4) at 2026-08-04 18:31:44 +0000