aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915
Commit message (Collapse)AuthorAge
* Revert "drm/i915: write backlight harder"Daniel Vetter2013-03-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit cf0a6584aa6d382f802f2c3cacac23ccbccde0cd. Turns out that cargo-culting breaks systems. Note that we can't revert further, since commit 770c12312ad617172b1a65b911d3e6564fc5aca8 Author: Takashi Iwai <tiwai@suse.de> Date: Sat Aug 11 08:56:42 2012 +0200 drm/i915: Fix blank panel at reopening lid fixed a regression in 3.6-rc kernels for which we've never figured out the exact root cause. But some further inspection of the backlight code reveals that it's seriously lacking locking. And especially the asle backlight update is know to get fired (through some smm magic) when writing specific backlight control registers. So the possibility of suffering from races is rather real. Until those races are fixed I don't think it makes sense to try further hacks. Which sucks a bit, but sometimes that's how it is :( References: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg18788.html Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47941 Tested-by: Takashi Iwai <tiwai@suse.de> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Takashi Iwai <tiwai@suse.de> Cc: stable@vger.kernel.org (the reverted commit was cc: stable, too) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: don't disable the power well yetPaulo Zanoni2013-03-24
| | | | | | | | | | | | | | | | | | | | | | | We're still not 100% ready to disable the power well, so don't disable it for now. When we disable it we break the audio driver (because some of the audio registers are on the power well) and machines with eDP on port D (because it doesn't use TRANSCODER_EDP). Also, instead of just reverting the code, add a Kernel option to let us disable it if we want. This will allow us to keep developing and testing the feature while it's not enabled. This fixes problems caused by the following commit: commit d6dd9eb1d96d2b7345fe4664066c2b7ed86da898 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Jan 29 16:35:20 2013 -0200 drm/i915: dynamic Haswell display power well support References: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg18788.html Cc: Takashi Iwai <tiwai@suse.de> Cc: Mengdong Lin <mengdong.lin@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Revert "drm/i915: set TRANSCODER_EDP even earlier"Daniel Vetter2013-03-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit cc464b2a17c59adedbdc02cc54341d630354edc3. The reason is that Takashi Iwai reported a regression bisected to this commit: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg18788.html His machine has eDP on port D (usual desktop all-in-on setup), which intel_dp.c identifies as an eDP panel, but the hsw ddi code mishandles. Closer inspection of the code reveals that haswell_crtc_mode_set also checks intel_encoder_is_pch_edp when setting is_cpu_edp. On haswell that doesn't make much sense (since there's no edp on the pch), but what this function _really_ checks is whether that edp connector is on port A or port D. It's just that on ilk-ivb port D was on the pch ... So that explains why this seemingly innocent change killed eDP on port D. Furthermore it looks like everything else accidentally works, since we've never enabled eDP on port D support for hsw intentionally (e.g. we still register the HDMI output for port D in that case). But in retrospective I also don't like that this leaks highly platform specific details into common code, and the reason is that the drm vblank layer sucks. So instead I think we should: - move the cpu_transcoder into the dynamic pipe_config tracking (once that's merged). - fix up the drm vblank layer to finally deal with kms crtc objects instead of int pipes. v2: Pimp commit message with the better diagnosis as discussed with Paulo on irc. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Takashi Iwai <tiwai@suse.de> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: stop using GMBUS IRQs on Gen4 chipsJiri Kosina2013-03-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 28c70f162 ("drm/i915: use the gmbus irq for waits") switched to using GMBUS irqs instead of GPIO bit-banging for chipset generations 4 and above. It turns out though that on many systems this leads to spurious interrupts being generated, long after the register write to disable the IRQs has been issued. Typically this results in the spurious interrupt source getting disabled: [ 9.636345] irq 16: nobody cared (try booting with the "irqpoll" option) [ 9.637915] Pid: 4157, comm: ifup Tainted: GF 3.9.0-rc2-00341-g0863702 #422 [ 9.639484] Call Trace: [ 9.640731] <IRQ> [<ffffffff8109b40d>] __report_bad_irq+0x1d/0xc7 [ 9.640731] [<ffffffff8109b7db>] note_interrupt+0x15b/0x1e8 [ 9.640731] [<ffffffff810999f7>] handle_irq_event_percpu+0x1bf/0x214 [ 9.640731] [<ffffffff81099a88>] handle_irq_event+0x3c/0x5c [ 9.640731] [<ffffffff8109c139>] handle_fasteoi_irq+0x7a/0xb0 [ 9.640731] [<ffffffff8100400e>] handle_irq+0x1a/0x24 [ 9.640731] [<ffffffff81003d17>] do_IRQ+0x48/0xaf [ 9.640731] [<ffffffff8142f1ea>] common_interrupt+0x6a/0x6a [ 9.640731] <EOI> [<ffffffff8142f952>] ? system_call_fastpath+0x16/0x1b [ 9.640731] handlers: [ 9.640731] [<ffffffffa000d771>] usb_hcd_irq [usbcore] [ 9.640731] [<ffffffffa0306189>] yenta_interrupt [yenta_socket] [ 9.640731] Disabling IRQ #16 The really curious thing is now that irq 16 is _not_ the interrupt for the i915 driver when using MSI, but it _is_ the interrupt when not using MSI. So by all indications it seems like gmbus is able to generate a legacy (shared) interrupt in MSI mode on some configurations. I've tried to reproduce this and the differentiating thing seems to be that on unaffected systems no other device uses irq 16 (which seems to be the non-MSI intel gfx interrupt on all gm45). I have no idea how that even can happen. To avoid tempting this elephant into a rage, just disable gmbus interrupt support on gen 4. v2: Improve the commit message with exact details of what's going on. Also add a comment in the code to warn against this particular elephant in the room. v3: Move the comment explaing how gen4 blows up next to the definition of HAS_GMBUS_IRQ to keep the code-flow straight. Suggested by Chris Wilson. Signed-off-by: Jiri Kosina <jkosina@suse.cz> (v1) Acked-by: Chris Wilson <chris@chris-wilson.co.uk> References: https://lkml.org/lkml/2013/3/8/325 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Use the fixed pixel clock for eDP in intel_dp_set_m_n()Takashi Iwai2013-03-18
| | | | | | | | | | | | | | | | | | | | | | | The eDP output on HP Z1 is still broken when X is started even after fixing the infinite link-train loop. The regression was introduced in 3.6 kernel for cleaning up the mode clock handling code in intel_dp.c by the commit [71244653: drm/i915: adjusted_mode->clock in the dp mode_fix]. In the past, the clock of the reference mode was modified in intel_dp_mode_fixup() in the case of eDP fixed clock, and this clock was used for calculating in intel_dp_set_m_n(). This override was removed, thus the wrong mode clock is used for the calculation, resulting in a psychedelic smoking output in the end. This patch corrects the clock to be used in the place. v1->v2: Use intel_edp_target_clock() for checking eDP fixed clock instead of open code as in ironlake_set_m_n(). Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Revert "drm/i915: try to train DP even harder"Takashi Iwai2013-03-17
| | | | | | | | | | | | | | | This reverts commit 0d71068835e2610576d369d6d4cbf90e0f802a71. Not only that the commit introduces a bogus check (voltage_tries == 5 will never meet at the inserted code path), it brings the i915 driver into an endless dp-train loop on HP Z1 desktop machine with IVY+eDP. At least reverting this commit recovers the framebuffer (but X is still broken by other reasons...) Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: bounds check execbuffer relocation countKees Cook2013-03-13
| | | | | | | | | | | | | | | | 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 Cc: stable@vger.kernel.org Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: restrict kernel address leak in debugfsKees Cook2013-03-13
| | | | | | | | | | 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> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge branch 'drm-intel-fixes' of ↵Dave Airlie2013-03-06
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-next A bunch of fixes, nothing truely horrible: - Fix PCH irq handling race which resulted in missed gmbus/dp aux irqs and subsequent fallout (Paulo) - Fixup off-by-one in our hsw id table (Kenneth) - Fixup ilk rc6 support (disabled by default), regression introduced in 3.8 - g4x plane w/a from Egbert Eich - gen2/3/4 dpms suspend/standy fixes for VGA outputs from Patrik Jakobsson - Workaround dying ivb machines with less aggressive rc6 values (Stéphane Marchesin) * 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel: drm/i915: Turn off hsync and vsync on ADPA when disabling crt drm/i915: Fix incorrect definition of ADPA HSYNC and VSYNC bits drm/i915: also disable south interrupts when handling them drm/i915: enable irqs earlier when resuming drm/i915: Increase the RC6p threshold. DRM/i915: On G45 enable cursor plane briefly after enabling the display plane. drm/i915: Fix Haswell/CRW PCI IDs. drm/i915: Don't clobber crtc->fb when queue_flip fails drm/i915: wait_event_timeout's timeout is in jiffies drm/i915: Fix missing variable initilization
| * drm/i915: Turn off hsync and vsync on ADPA when disabling crtPatrik Jakobsson2013-03-06
| | | | | | | | | | | | | | | | | | | | | | According to PRM we need to disable hsync and vsync even though ADPA is disabled. The previous code did infact do the opposite so we fix it. Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56359 Tested-by: max <manikulin@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Fix incorrect definition of ADPA HSYNC and VSYNC bitsPatrik Jakobsson2013-03-06
| | | | | | | | | | | | | | | | | | | | Disable bits for ADPA HSYNC and VSYNC where mixed up resulting in suspend becoming standby and vice versa. Fixed by swapping their bit position. Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: also disable south interrupts when handling themPaulo Zanoni2013-03-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | From the docs: "IIR can queue up to two interrupt events. When the IIR is cleared, it will set itself again after one clock if a second event was stored." "Only the rising edge of the PCH Display interrupt will cause the North Display IIR (DEIIR) PCH Display Interrupt even bit to be set, so all PCH Display Interrupts, including back to back interrupts, must be cleared before a new PCH Display interrupt can cause DEIIR to be set". The current code works fine because we don't get many interrupts, but if we enable the PCH FIFO underrun interrupts we'll start getting so many interrupts that at some point new PCH interrupts won't cause DEIIR to be set. The initial implementation I tried was to turn the code that checks SDEIIR into a loop, but we can still get interrupts even after the loop is done (and before the irq handler finishes), so we have to either disable the interrupts or mask them. In the end I concluded that just disabling the PCH interrupts is enough, you don't even need the loop, so this is what this patch implements. I've tested it and it passes the 2 "PCH FIFO underrun interrupt storms" I can reproduce: the "ironlake_crtc_disable" case and the "wrong watermarks" case. In other words, here's how to reproduce the problem fixed by this patch: 1 - Enable PCH FIFO underrun interrupts (SERR_INT on SNB+) 2 - Boot the machine 3 - While booting we'll get tons of PCH FIFO underrun interrupts 4 - Plug a new monitor 5 - Run xrandr, notice it won't detect the new monitor 6 - Read SDEIIR and notice it's not 0 while DEIIR is 0 Q: Can't we just clear DEIIR before SDEIIR? A: It doesn't work. SDEIIR has to be completely cleared (including the interrupts stored on its back queue) before it can flip DEIIR's bit to 1 again, and even while you're clearing it you'll be getting more and more interrupts. Q: Why does it work by just disabling+enabling the south interrupts? A: Because when we re-enable them, if there's something on the SDEIIR register (maybe an interrupt stored on the queue), the re-enabling will make DEIIR's bit flip to 1, and since we'll already have interrupts enabled we'll get another interrupt, then run our irq handler again to process the "back" interrupts. v2: Even bigger commit message, added code comments. Note that this fixes missed dp aux irqs which have been reported for 3.9-rc1. This regression has been introduced by switching to irq-driven dp aux transactions with commit 9ee32fea5fe810ec06af3a15e4c65478de56d4f5 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sat Dec 1 13:53:48 2012 +0100 drm/i915: irq-drive the dp aux communication References: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg18588.html References: https://lkml.org/lkml/2013/2/26/769 Tested-by: Imre Deak <imre.deak@intel.com> Reported-by: Sedat Dilek <sedat.dilek@gmail.com> Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: Pimp commit message with references for the dp aux irq timeout regression this fixes.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: enable irqs earlier when resumingDaniel Vetter2013-03-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need it to restore the ilk rc6 context, since the gpu wait no requires interrupts. But in general having interrupts around should help in code sanity, since more and more stuff is interrupt driven. This regression has been introduced in commit 3e9605018ab3e333d51cc90fccfde2031886763b Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Nov 27 16:22:54 2012 +0000 drm/i915: Rearrange code to only have a single method for waiting upon the ring Like in the driver load code we need to make sure that hotplug interrupts don't cause havoc with our modeset state, hence block them with the existing infrastructure. Again we ignore races where we might loose hotplug interrupts ... Note that the driver load part of the regression has already been fixed in commit 52d7ecedac3f96fb562cb482c139015372728638 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sat Dec 1 21:03:22 2012 +0100 drm/i915: reorder setup sequence to have irqs for output setup v2: Add a note to the commit message about which patch fixed the driver load part of the regression. Stable kernels need to backport both patches. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=54691 Cc: stable@vger.kernel.org (for 3.8 only, plese backport 52d7ecedac3f96fb5 first) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reported-and-Tested-by: Ilya Tumaykin <itumaykin@gmail.com> Reviewed-by: Chris wilson <chris@chris-wilson.co.uk> (v1) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Increase the RC6p threshold.Stéphane Marchesin2013-03-05
| | | | | | | | | | | | | | | | | | | | 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>
| * DRM/i915: On G45 enable cursor plane briefly after enabling the display plane.Egbert Eich2013-03-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On G45 some low res modes (800x600 and 1024x768) produce a blank screen when the display plane is enabled with with cursor plane off. Experiments showed that this issue occurred when the following conditions were met: a. a previous mode had the cursor plane enabled (Xserver). b. this mode or the previous one was using self refresh. (Thus the problem was only seen with low res modes). The screens lit up as soon as the cursor plane got enabled. Therefore the blank screen occurred only in console mode, not when running an Xserver. It also seemed to be necessary to disable self refresh while briefly enabling the cursor plane. Signed-off-by: Egbert Eich <eich@suse.com> Bugzilla: https://bugs.freedesktop.org/attachment.cgi?bugid=61457 Acked-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: drop spurious whitespace change.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Fix Haswell/CRW PCI IDs.Kenneth Graunke2013-03-03
| | | | | | | | | | | | | | | | | | The second digit was off by one, which meant we accidentally treated GT(n) as GT(n-1). This also meant no support for GT1 at all. Cc: stable@kernel.org Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Don't clobber crtc->fb when queue_flip failsVille Syrjälä2013-03-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. Cc: stable@vger.kernel.org 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>
| * drm/i915: wait_event_timeout's timeout is in jiffiesPaulo Zanoni2013-03-03
| | | | | | | | | | | | | | | | | | | | | | So use msecs_to_jiffies(10) to make the timeout the same as in the "!has_aux_irq" case. This patch was initially written by Daniel Vetter and posted on pastebin a few weeks ago. I'm just bringing it to the mailing list. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Fix missing variable initilizationSyam Sidhardhan2013-03-03
| | | | | | | | | | | | | | Need to initialize the variable wait to false. Signed-off-by: Syam Sidhardhan <s.syam@samsung.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: convert to idr_alloc()Tejun Heo2013-02-27
| | | | | | | | | | | | | | | | | | | | Convert to the much saner new idr interface. Signed-off-by: Tejun Heo <tj@kernel.org> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: David Airlie <airlied@linux.ie> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | Merge branch 'for-linus' of ↵Linus Torvalds2013-02-26
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs Pull vfs pile (part one) from Al Viro: "Assorted stuff - cleaning namei.c up a bit, fixing ->d_name/->d_parent locking violations, etc. The most visible changes here are death of FS_REVAL_DOT (replaced with "has ->d_weak_revalidate()") and a new helper getting from struct file to inode. Some bits of preparation to xattr method interface changes. Misc patches by various people sent this cycle *and* ocfs2 fixes from several cycles ago that should've been upstream right then. PS: the next vfs pile will be xattr stuff." * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (46 commits) saner proc_get_inode() calling conventions proc: avoid extra pde_put() in proc_fill_super() fs: change return values from -EACCES to -EPERM fs/exec.c: make bprm_mm_init() static ocfs2/dlm: use GFP_ATOMIC inside a spin_lock ocfs2: fix possible use-after-free with AIO ocfs2: Fix oops in ocfs2_fast_symlink_readpage() code path get_empty_filp()/alloc_file() leave both ->f_pos and ->f_version zero target: writev() on single-element vector is pointless export kernel_write(), convert open-coded instances fs: encode_fh: return FILEID_INVALID if invalid fid_type kill f_vfsmnt vfs: kill FS_REVAL_DOT by adding a d_weak_revalidate dentry op nfsd: handle vfs_getattr errors in acl protocol switch vfs_getattr() to struct path default SET_PERSONALITY() in linux/elf.h ceph: prepopulate inodes only when request is aborted d_hash_and_lookup(): export, switch open-coded instances 9p: switch v9fs_set_create_acl() to inode+fid, do it before d_instantiate() 9p: split dropping the acls from v9fs_set_create_acl() ...
| * | new helper: file_inode(file)Al Viro2013-02-22
| | | | | | | | | | | | Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
* | | Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds2013-02-25
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull drm merge from Dave Airlie: "Highlights: - TI LCD controller KMS driver - TI OMAP KMS driver merged from staging - drop gma500 stub driver - the fbcon locking fixes - the vgacon dirty like zebra fix. - open firmware videomode and hdmi common code helpers - major locking rework for kms object handling - pageflip/cursor won't block on polling anymore! - fbcon helper and prime helper cleanups - i915: all over the map, haswell power well enhancements, valleyview macro horrors cleaned up, killing lots of legacy GTT code, - radeon: CS ioctl unification, deprecated UMS support, gpu reset rework, VM fixes - nouveau: reworked thermal code, external dp/tmds encoder support (anx9805), fences sleep instead of polling, - exynos: all over the driver fixes." Lovely conflict in radeon/evergreen_cs.c between commit de0babd60d8d ("drm/radeon: enforce use of radeon_get_ib_value when reading user cmd") and the new changes that modified that evergreen_dma_cs_parse() function. * 'drm-next' of git://people.freedesktop.org/~airlied/linux: (508 commits) drm/tilcdc: only build on arm drm/i915: Revert hdmi HDP pin checks drm/tegra: Add list of framebuffers to debugfs drm/tegra: Fix color expansion drm/tegra: Split DC_CMD_STATE_CONTROL register write drm/tegra: Implement page-flipping support drm/tegra: Implement VBLANK support drm/tegra: Implement .mode_set_base() drm/tegra: Add plane support drm/tegra: Remove bogus tegra_framebuffer structure drm: Add consistency check for page-flipping drm/radeon: Use generic HDMI infoframe helpers drm/tegra: Use generic HDMI infoframe helpers drm: Add EDID helper documentation drm: Add HDMI infoframe helpers video: Add generic HDMI infoframe helpers drm: Add some missing forward declarations drm: Move mode tables to drm_edid.c drm: Remove duplicate drm_mode_cea_vic() gma500: Fix n, m1 and m2 clock limits for sdvo and lvds ...
| * \ \ Merge branch 'drm/hdmi-for-3.9' of git://anongit.freedesktop.org/tegra/linux ↵Dave Airlie2013-02-23
| |\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into drm-next Thierry writes: "Remove a duplicate implementation of the CEA VIC lookup and move the CEA and other mode tables to drm_edid.c to make it more difficult to create duplicates of the tables. Add some helpers to pack CEA-861/HDMI AVI, audio and SPD infoframes into binary buffers that can easily be written into hardware registers. A new helper function makes it easy construct an AVI infoframe from a DRM display mode. Convert the Tegra and Radeon drivers to use the new HDMI helpers." * 'drm/hdmi-for-3.9' of git://anongit.freedesktop.org/tegra/linux: drm/radeon: Use generic HDMI infoframe helpers drm/tegra: Use generic HDMI infoframe helpers drm: Add EDID helper documentation drm: Add HDMI infoframe helpers video: Add generic HDMI infoframe helpers drm: Add some missing forward declarations drm: Move mode tables to drm_edid.c drm: Remove duplicate drm_mode_cea_vic()
| | * | | drm: Remove duplicate drm_mode_cea_vic()Thierry Reding2013-02-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The same function had already been merged with a different name. Remove the duplicate one but reuse some of its kerneldoc fragments for the existing implementation. Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
| * | | | Merge branch 'drm-intel-fixes' of ↵Dave Airlie2013-02-23
| |\ \ \ \ | | |/ / / | |/| | / | | | |/ | | |/| | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-next Two regressions fixes from snowboarding land * 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel: drm/i915: Revert hdmi HDP pin checks drm/i915: Handle untiled planes when computing their offsets
| | * | drm/i915: Revert hdmi HDP pin checksDaniel Vetter2013-02-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 8ec22b214d76773c9d89f4040505ce10f677ed9a Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri May 11 18:01:34 2012 +0100 drm/i915/hdmi: Query the live connector status bit for G4x and commit b0ea7d37a8f63eeec5ae80b4a6403cfba01da02f Author: Damien Lespiau <damien.lespiau@intel.com> Date: Thu Dec 13 16:09:00 2012 +0000 drm/i915/hdmi: Read the HPD status before trying to read the EDID They reliably cause HDMI to not be detected on some systems (like my ivb or the bug reporters gm45). To fix up the very slow unplug issues we might want to fire up a 2nd detect cycle a few hundred ms after each hotplug. But for now at least make displays work again. I somewhat suspect that this is confined to HDMI connectors, since all the machines I have with DP+ outputs work correctly. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52361 Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org.kernel.org # for 8ec22b21 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: Handle untiled planes when computing their offsetsChris Wilson2013-02-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We trim the fb to fit the CRTC by computing the offset of that CRTC to its nearest tile_row origin. This allows us to use framebuffers that are larger than the CRTC limits without additional work. However, we failed to compute the offset for a linear framebuffer correctly as we treated its x-advance in whole tiles (instead of the linear increment expected), leaving the CRTC misaligned with its contents. Fixes regression from commit c2c75131244507c93f812862fdbd4f3a37139401 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Jul 5 12:17:30 2012 +0200 drm/i915: adjust framebuffer base address on gen4+ v2: Adjust relative x-coordinate after linear alignment (vsyrjala) v3: Repaint with pokadots (vsyrjala) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61152 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | | Merge branch 'drm-intel-fixes' of ↵Dave Airlie2013-02-19
| |\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-next So here's my promised pile of fixes for 3.9. I've dropped the core prep patches for vt-switchless suspend/resume as discussed on irc. Highlights: - Fix dmar on g4x. Not really gfx related, but I'm fed up with getting blamed for dmar crapouts. - Disable wc ptes updates on ilk when dmar is enabled (Chris). So again, dmar, but this time gfx related :( - Reduced range support for hsw, using the pipe CSC (Ville). - Fixup pll limits for gen3/4 (Patrick Jakobsson). The sdvo patch is already confirmed to fix 2 bug reports, so added cc: stable on that one. - Regression fix for 8bit fb console (Ville). - Preserve lane reversal bits on DDI/FDI ports (Damien). - Page flip vs. gpu hang fixes (Ville). Unfortuntely not quite all of them, need to decide what to do with the currently still in-flight ones. - Panel fitter regression fix from Mika Kuoppala (was accidentally left on on some pipes with the new modset code since 3.7). This also improves the modeset sequence and might help a few other unrelated issues with lvds. - Write backlight regs even harder ... another installement in our eternal fight against the BIOS and backlights. - Fixup lid notifier vs. suspend/resume races (Zhang Rui). Prep work for new ACPI stuff, but closing the race itself seems worthwile on its own. - A few other small fixes and tiny cleanups all over. Lots of the patches are cc: stable since I've stalled on a few not-so-important fixes for 3.8 due to the grumpy noise Linus made. * 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel: (33 commits) intel/iommu: force writebuffer-flush quirk on Gen 4 Chipsets drm/i915: Disable WC PTE updates to w/a buggy IOMMU on ILK drm/i915: Implement pipe CSC based limited range RGB output drm/i915: inverted brightness quirk for Acer Aspire 4736Z drm/i915: Print the hw context status is debugfs drm/i915: Use HAS_L3_GPU_CACHE in i915_gem_l3_remap drm/i915: Fix PIPE_CONTROL DW/QW write through global GTT on IVB+ drm/i915: Set i9xx sdvo clock limits according to specifications drm/i915: Set i9xx lvds clock limits according to specifications drm/i915: Preserve the DDI link reversal configuration drm/i915: Preserve the FDI line reversal override bit on CPT drm/i915: add missing \n to UTS_RELEASE in the error_state drm: Use C8 instead of RGB332 when determining the format from depth/bpp drm: Fill depth/bits_per_pixel for C8 format drm/i915: don't clflush gem objects in stolen memory drm/i915: Don't wait for page flips if there was GPU reset drm/i915: Kill obj->pending_flip drm/i915: Fix a typo in a intel_modeset_stage_output_state() comment drm/i915: remove bogus mutex_unlock from error-path drm/i915: Print the pipe control page GTT address ...
| | * | drm/i915: Implement pipe CSC based limited range RGB outputVille Syrjälä2013-02-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | HSW no longer has the PIPECONF bit for limited range RGB output. Instead the pipe CSC unit must be used to perform that task. The CSC pre offset are set to 0, since the incoming data is full [0:255] range RGB, the coefficients are programmed to compress the data into [0:219] range, and then we use either the CSC_MODE black screen offset bit, or the CSC post offsets to shift the data to the correct [16:235] range. Also have to change the confiuration of all planes so that the data is sent through the pipe CSC unit. For simplicity send the plane data through the pipe CSC unit always, and in case full range output is requested, the pipe CSC unit is set up with an identity transform to pass the plane data through unchanged. I've been told by some hardware people that the use of the pipe CSC unit shouldn't result in any measurable increase in power consumption numbers. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: inverted brightness quirk for Acer Aspire 4736ZDaniel Vetter2013-02-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=53881 Cc: stable@vger.kernel.org Cc: Jani Nikula <jani.nikula@intel.com> Tested-by: Jani Monoses <jani@ubuntu.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: Print the hw context status is debugfsBen Widawsky2013-02-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Print out the HW context object information per ring. Even though the existing code only utilizes the render ring, it's simple enough to support future expansion. I had this in a patch somewhere in a rev of the original implementation, but I must have lost it. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> [danvet: s/context/default context/ bikeshed applied.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: Use HAS_L3_GPU_CACHE in i915_gem_l3_remapDaniel Vetter2013-02-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Yet another remnant ... this might explain why l3 remapping didn't really work on HSW. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57441 Spotted-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: stable@vger.kernel.org Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: Fix PIPE_CONTROL DW/QW write through global GTT on IVB+Ville Syrjälä2013-02-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bit controlling whether PIPE_CONTROL DW/QW write targets the global GTT or PPGTT moved moved from DW 2 bit 2 to DW 1 bit 24 on IVB. I verified on IVB that the fix is in fact effective. Without the fix none of the scratch writes actually landed in the pipe control page. With the fix the writes show up correctly. v2: move PIPE_CONTROL_GLOBAL_GTT_IVB setup to where other flags are set Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: Set i9xx sdvo clock limits according to specificationsPatrik Jakobsson2013-02-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: Set i9xx lvds clock limits according to specificationsPatrik Jakobsson2013-02-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: Preserve the DDI link reversal configurationDamien Lespiau2013-02-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Similarly to: commit 6a0d1df3d3a0d2370541164eb0595fe35dcd6de3 Author: Damien Lespiau <damien.lespiau@intel.com> Date: Tue Dec 11 15:18:28 2012 +0000 drm/i915: Preserve the FDI line reversal override bit on CPT DDI port support lane reversal to easy the PCB layouting work. Let's preserve the bit configured by the BIOS (until we find how to correctly retrieve the information from the VBT, but this does sound more fragile then just relying on the BIOS that has, hopefully, been validated already. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: Preserve the FDI line reversal override bit on CPTDamien Lespiau2013-02-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The FDI link has supported link reversal to make the PCB layout engineer's life easier for quite a while and we have always presered this bit as we programmed FDI_RX_CTL with a read/modify/write sequence. We're trying to take a bit more control over what the BIOS leaves in various register and with the introduction of DDI, started to program FDI_RX_CTL fully. There's a fused bit to indicate DMI link reversal and FDI defaults to mirroring that configuration. We have a bit to override that behaviour that we need to preserve from the BIOS. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: add missing \n to UTS_RELEASE in the error_stateJani Nikula2013-02-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Amending commit 4518f611ba21ba165ea3714055938a8984a44ff9 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Jan 23 16:16:35 2013 +0100 drm/i915: dump UTS_RELEASE into the error_state CC: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: don't clflush gem objects in stolen memoryImre Deak2013-02-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As explained by Chris Wilson gem objects in stolen memory are always coherent with the GPU so we don't need to ever flush the CPU caches for these. This fixes a breakage - at least with the compact sg patches applied - during the resume/restore gtt mappings path, when we tried to clflush an FB object in stolen memory, but since stolen objects don't have backing pages we passed an invalid page pointer to drm_clflush_page(). Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: Don't wait for page flips if there was GPU resetVille Syrjälä2013-02-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a GPU reset occurs while a page flip has been submitted to the ring, the flip will never complete once the ring has been reset. The GPU reset can be detected by sampling the reset_counter before the flip is submitted, and then while waiting for the flip, the sampled counter is compared with the current reset_counter value. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> [danvet: Move the reset_counter assignment to an earlier place in common code as discussed on the mailing list.] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60140 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: Kill obj->pending_flipVille Syrjälä2013-02-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The pending flip mask no longer set anywhere, so trying to wait for while it's non-zero is a no-op. Remove it completely. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: Fix a typo in a intel_modeset_stage_output_state() commentDamien Lespiau2013-02-19
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: remove bogus mutex_unlock from error-pathDaniel Vetter2013-02-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This has been lost in the locking rework for intel_alloc_context_page: commit 2c34b850ee1e9f86b41706149d0954eee58757a3 Author: Ben Widawsky <ben@bwidawsk.net> Date: Sat Mar 19 18:14:26 2011 -0700 drm/i915: fix ilk rc6 teardown locking Cc: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: Print the pipe control page GTT addressVille Syrjälä2013-02-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We already print the HWS addresses during init, so do the same for the pipe control page. Reduces guesswork when looking at hex addresses later. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: clean up panel fitter handling in lvdsMika Kuoppala2013-02-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the previous patch "drm/i915: disable shared panel fitter for pipe" we now disable the panel fitter at the right spot in the modeset sequence in the crtc functions on all platforms. Hence the disabling in intel_disable_lvds is no longer required and potentially harmful (since the plane is still enabled at this point). Similarly on the enabling side we enable the panel fitter in the lvds callback only once the plane is enabled. Which is too late. Hence move this into a new intel_pre_enable_lvds callback. Finally we can ditch lvds_encoder->pfit_dirty - this was required to work around the crtc helper semantics, but with the new i915 modeset infrastructure we should enable/disable the pfit only when enabling or disabling the entire output pipeline. So separate state tracking for the pfit is no longer required. Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> [danvet: Bikeshed the commit message a bit to stress that now we enable/disable the pfit on i9xx platforms at the right point of time compared to the old code.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: disable shared panel fitter for pipeMika Kuoppala2013-02-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 Cc: stable@vger.kernel.org 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>
| | * | drm/i915: detect wrong MCH watermark valuesDaniel Vetter2013-02-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some early bios versions seem to ship with the wrong tuning values for the MCH, possible resulting in pipe underruns under load. Especially on DP outputs this can lead to black screen, since DP really doesn't like an occasional whack from an underrun. Unfortunately the registers seem to be locked after boot, so the only thing we can do is politely point out issues and suggest a BIOS upgrade. Arthur Runyan pointed us at this issue while discussion DP bugs - thus far no confirmation from a bug report yet that it helps. But at least some of my machines here have wrong values, so this might be useful in understanding bug reports. v2: After a bit more discussion with Art and Ben we've decided to only the check the watermark values, since the OREF ones could be be a notch more aggressive on certain machines. Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Runyan, Arthur J <arthur.j.runyan@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915/ctx: Remove bad invariantBen Widawsky2013-02-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's not that the assertion is incorrect, but rather that we can call do_destroy early in loading, and we will falsely BUG(). Since contexts have been in for a while now, and in the internal APIs are pretty stable, it should be fairly safe to remove this. v2: Remove unused dev_priv, and dev Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: Extract ring init from hw_initBen Widawsky2013-02-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ring initialization will differ a bit in upcoming generations, and this split will prepare the code for what's needed. This patch also fixes a bug introduced in: commit 99433931950f33039d9e1a52b4ed9af3f1b58e84 Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> Date: Tue Jan 22 14:12:17 2013 +0200 drm/i915: use gem_set_seqno() on hardware init After doing the extraction, the bad error handling became obvious. I acknowledge that this should be two patches, but it's a pretty small/trivial patch. If requested, I can certainly do the fix as a distinct patch. v2: Should be cleanup blt, not init blt on failure (Chris) v3: Forgot to git add on v2 Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-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>
generated by cgit v1.2.2 (git 2.25.0) at 2025-08-07 15:07:22 -0400