summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* drm: Export routines for inserting preallocated nodes into the mm managerChris Wilson2012-12-182-16/+50
| | | | | | | | | | | | | | | | | Required by i915 in order to avoid the allocation in the middle of manipulating the drm_mm lists. Use a pair of stubs to preserve the existing EXPORT_SYMBOLs for backporting; to be removed later. Cc: Dave Airlie <airlied@redhat.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jani Nikula <jani.nikula@intel.com> [danvet: bikeshedded-away the atomic parameter, it's not yet used anywhere.] Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: don't disable disconnected outputsDaniel Vetter2012-12-181-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This piece of neat lore has been ported painstakingly and bug-for-bug compatible from the old crtc helper code. Imo it's utter nonsense. If you disconnected a cable and before you reconnect it, userspace (or the kernel) does an set_crtc call, this will result in that connector getting disabled. Which will result in a nice black screen when plugging in the cable again. There's absolutely no reason the kernel does such policy enforcements - if userspace tries to set up a mode on something disconnected we might fail loudly (since the dp link training fails), but silently adjusting the output configuration behind userspace's back is a recipe for disaster. Specifically I think that this could explain some of our MI_WAIT hangs around suspend, where userspace issues a scanline wait on a disable pipe. This mechanisims here could explain how that pipe got disabled without userspace noticing. Note that this fixes a NULL deref at BIOS takeover when the firmware sets up a disconnected output in a clone configuration with a connected output on the 2nd pipe: When doing the full modeset we don't have a mode for the 2nd pipe and OOPS. On the first pipe this doesn't matter, since at boot-up the fbdev helpers will set up the choosen configuration on that on first. Since this is now the umptenth bug around handling this imo brain-dead semantics correctly, I think it's time to kill it and see whether there's any userspace out there which relies on this. It also nicely demonstrates that we have a tiny window where DP hotplug can still kill the driver. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58396 Cc: stable@vger.kernel.org Tested-by: Peter Ujfalusi <peter.ujfalusi@gmail.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Implement workaround for broken CS tlb on i830/845Daniel Vetter2012-12-177-8/+100
| | | | | | | | | | | | | | | | | | | | | | | | | Now that Chris Wilson demonstrated that the key for stability on early gen 2 is to simple _never_ exchange the physical backing storage of batch buffers I've tried a stab at a kernel solution. Doesn't look too nefarious imho, now that I don't try to be too clever for my own good any more. v2: After discussing the various techniques, we've decided to always blit batches on the suspect devices, but allow userspace to opt out of the kernel workaround assume full responsibility for providing coherent batches. The principal reason is that avoiding the blit does improve performance in a few key microbenchmarks and also in cairo-trace replays. Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: - Drop the hunk which uses HAS_BROKEN_CS_TLB to implement the ring wrap w/a. Suggested by Chris Wilson. - Also add the ACTHD check from Chris Wilson for the error state dumping, so that we still catch batches when userspace opts out of the w/a.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Implement WaSetupGtModeTdRowDispatchDaniel Vetter2012-12-173-1/+10
| | | | | | | | | | | | I'm not really sure, since the w/a entry is as thin on details as ever, and Bspec doesn't say anything about it. But I've figured only dispatching to rows 0&1 instead of all four should be the right thing for GT1. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> [danvet: Add the missing snb server GT1 to the check, spotted by Chris Wilson.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Implement WaDisableHiZPlanesWhenMSAAEnabledDaniel Vetter2012-12-172-0/+5
| | | | | | | | | 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>
* drm/i915: Prefer CRTC 'active' rather than 'enabled' during WM computationsChris Wilson2012-12-171-7/+7
| | | | | | | | | Only the intel_crtc->active is accurate at the point where we wish to perform WM computations, so use it instead of crtc->enabled. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Clear self-refresh watermarks when disabledChris Wilson2012-12-171-6/+8
| | | | | | | | | | | If we elect to disable self-refresh as they require too many FIFO entries, clear the values prior to writing them into the registers. If they are too large they may occupy more bits than available and so corrupt neighbouring WM values. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Double the cursor self-refresh latency on ValleyviewChris Wilson2012-12-171-1/+7
| | | | | | | | | | | It operates at twice the declared latency, so double the latency value used for the cursor watermark calculation. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50248 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> CC: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Fixup cursor latency used for IVB lp3 watermarksChris Wilson2012-12-171-5/+112
| | | | | | | | | | | It operates at twice the declared latency, so adjust the computation to avoid potential flicker at low power. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50248 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> CC: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Fix missed needs_dmar settingZhenyu Wang2012-12-131-0/+4
| | | | | | | | | | From Ben's AGP dependence removal change, "needs_dmar" flag has not been properly setup for new chips using new GTT init function. This one adds missed setting of that flag to make sure we do pci mappings with IOMMU enabled. Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Fix shifted screen on top of LVDS on IVY laptopTakashi Iwai2012-12-111-0/+5
| | | | | | | | | | | | | | | | The commit [23670b322: drm/i915: CPT+ pch transcoder workaround] caused a regression on some HP laptops with IvyBridge. The whole laptop screen is shifted downward for a few pixels constantly. The problem appears only on LVDS while DP and VGA seem unaffected. Also, the problem disappears once when go and back from S3. (S4 resume still shows the same problem.) This patch revives the minimum part the commit above dropped. For fixing this regression, only the setup of CHICKEN2 bit in cpt_init_clock_gating() is needed. Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: disable cpt phase pointer fdi rx workaroundDaniel Vetter2012-12-101-29/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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! Cc: "Runyan, Arthur J" <arthur.j.runyan@intel.com> Cc: stable@vger.kernel.org Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: set the LPT FDI RX polarity reversal bit when neededPaulo Zanoni2012-12-104-0/+13
| | | | | | | | | | | | If we fail to set the bit when needed we get some nice FDI link training failures (AKA "black screen on VGA output"). While we don't really know how to properly choose whether we need to set the bit or not (VBT?), just read the initial value set by the BIOS and store it for later usage. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: add lpt_init_pch_refclkPaulo Zanoni2012-12-104-10/+185
| | | | | | | | | | | | | | | | | | | We need this code to init the PCH SSC refclk and the FDI registers. The BIOS does this too and that's why VGA worked before this patch, until you tried to suspend the machine... This patch implements the "Sequence to enable CLKOUT_DP for FDI usage and configure PCH FDI/IO" from our documentation. v2: - Squash Damien Lespiau's reset spelling fix on top. - Add a comment that we don't need to bother about the ULT special case Damien noticed, since ULT won't have VGA. - Add a comment to rip out the SDV codepaths once haswell ships for real. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v1) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: add support for mPHY destination on intel_sbi_{read, write}Paulo Zanoni2012-12-103-34/+40
| | | | | | | | | | This way we should be able to write mPHY registers using the Sideband Interface in the next commit. Also fixed some syntax oddities in the related code. 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>
* drm/i915: reject modes the LPT FDI receiver can't handlePaulo Zanoni2012-12-083-9/+20
| | | | | | | | More specifically, the LPT FDI RX only supports 8bpc and a maximum of 2 lanes, so anything above that won't work and should be rejected. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: fix hsw_fdi_link_train "retry" codePaulo Zanoni2012-12-081-16/+27
| | | | | | | | | | | | | | | | | | We were previously doing exactly what the "mode set sequence for CRT" document mandates, but whenever we failed to train the link in the first tentative, all the other subsequent retries always failed. In one of my monitors that has 47 modes, I was usually getting around 3 failures when running "testdisplay -a". After this patch, even if we fail in the first tentative, we can succeed in the next ones. So now when running "testdisplay -a" I see around 3 times the message "FDI link training done on step 1" and no failures. Notice that now the "retry" code looks a lot like the DP retry code. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Close race between processing unpin task and queueing the flipChris Wilson2012-12-064-11/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Before queuing the flip but crucially after attaching the unpin-work to the crtc, we continue to setup the unpin-work. However, should the hardware fire early, we see the connected unpin-work and queue the task. The task then promptly runs and unpins the fb before we finish taking the required references or even pinning it... Havoc. To close the race, we use the flip-pending atomic to indicate when the flip is finally setup and enqueued. So during the flip-done processing, we can check more accurately whether the flip was expected. v2: Add the appropriate mb() to ensure that the writes to the page-flip worker are complete prior to marking it active and emitting the MI_FLIP. On the read side, the mb should be enforced by the spinlocks. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org [danvet: Review the barriers a bit, we need a write barrier both before and after updating ->pending. Similarly we need a read barrier in the interrupt handler both before and after reading ->pending. With well-ordered irqs only one barrier in each place should be required, but since this patch explicitly sets out to combat spurious interrupts with is staged activation of the unpin work we need to go full-bore on the barriers, too. Discussed with Chris Wilson on irc and changes acked by him.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: fixup l3 parity sysfs access checkDaniel Vetter2012-12-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | When l3 parity support for Haswell was enabled in commit f27b92651d72e863c308ea5dca5615fc98e38ca6 Author: Ben Widawsky <benjamin.widawsky@intel.com> Date: Tue Jul 24 20:47:32 2012 -0700 drm/i915: Expand DPF support to Haswell no one noticed that the patch which introduced this macro commit e1ef7cc299839e68dae3f1843f62e52acda04538 Author: Ben Widawsky <benjamin.widawsky@intel.com> Date: Tue Jul 24 20:47:31 2012 -0700 drm/i915: Macro to determine DPF support missed one spot. Fix this. Cc: Ben Widawsky <benjamin.widawsky@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57441 Reviewed-by: Ben Widawsky <benjamin.widawsky@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Clear the existing watermarks for g4x when modifying the cursor srChris Wilson2012-12-041-4/+5
| | | | | | | | | | | | | In a couple of places we attempt to adjust the existing watermark registers to update them for the new cursor watermarks. This goes horribly wrong as instead of clearing the cursor bits prior to or'ing in the new values, we clear the rest of the register with the result that the watermark registers contain bogus values. References: https://bugs.freedesktop.org/show_bug.cgi?id=47034 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: do not access BLC_PWM_CTL2 on pre-gen4 hardwareJani Nikula2012-12-041-10/+11
| | | | | | | | | The BLC_PWM_CTL2 register does not exist before gen4. While at it, do a slight drive by cleanup of the code. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Don't allow ring tail to reach the same cacheline as headVille Syrjälä2012-12-033-3/+14
| | | | | | | | | | | | | | | | | | | | | | From BSpec: "If the Ring Buffer Head Pointer and the Tail Pointer are on the same cacheline, the Head Pointer must not be greater than the Tail Pointer." The easiest way to enforce this is to reduce the reported ring space. References: Gen2 BSpec "1. Programming Environment" / 1.4.4.6 "Ring Buffer Use" Gen3 BSpec "vol1c Memory Interface Functions" / 2.3.4.5 "Ring Buffer Use" Gen4+ BSpec "vol1c Memory Interface and Command Stream" / 5.3.4.5 "Ring Buffer Use" v2: Include the exact BSpec references in the description v3: s/64/I915_RING_FREE_SPACE, and add the BSpec information to the code Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Decouple the object from the unbound list before freeing pagesChris Wilson2012-12-031-1/+5
| | | | | | | | | | | As we may actually allocate in order to save the physical swizzling bits during the free, we have to be careful not to trigger the shrinker on the same object. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Added a small comment in the code to really drive the scariness of this patch home.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Set sync_seqno properly after seqno wrapMika Kuoppala2012-11-291-1/+5
| | | | | | | | | | | | | | | | | | | | i915_gem_handle_seqno_wrap() will zero all sync_seqnos but as the wrap can happen inside ring->sync_to(), pre wrap seqno was carried over and overwrote the zeroed sync_seqno. When wrap is handled, all outstanding requests will be retired and objects moved to inactive queue, causing their last_read_seqno to be zero. Use this to update the sync_seqno correctly. RING_SYNC registers after wrap will contain pre wrap values which are >= seqno. So injecting the semaphore wait into ring completes immediately. Original idea for using last_read_seqno from Chris Wilson. Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Include the last semaphore sync point in the error-stateChris Wilson2012-11-293-4/+9
| | | | | | | | | Should be useful to know what the driver thought the other ring's seqno was when it last used a semaphore. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Rearrange code to only have a single method for waiting upon the ringChris Wilson2012-11-295-61/+58
| | | | | | | | | | Replace the wait for the ring to be clear with the more common wait for the ring to be idle. The principle advantage is one less exported intel_ring_wait function, and the removal of a hardcoded value. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Simplify flushing activity on the ringChris Wilson2012-11-291-7/+3
| | | | | | | | | | | As we now always preallocate the seqno before writing to the ring, we can trivially test if we have any pending activity on the ring by inspecting the olr. This makes it then possible to flush operations that are not normally associated with a request, like power-management. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Preallocate next seqno before touching the ringChris Wilson2012-11-296-82/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Based on the work by Mika Kuoppala, we realised that we need to handle seqno wraparound prior to committing our changes to the ring. The most obvious point then is to grab the seqno inside intel_ring_begin(), and then to reuse that seqno for all ring operations until the next request. As intel_ring_begin() can fail, the callers must already be prepared to handle such failure and so we can safely add further checks. This patch looks like it should be split up into the interface changes and the tweaks to move seqno wrapping from the execbuffer into the core seqno increment. However, I found no easy way to break it into incremental steps without introducing further broken behaviour. v2: Mika found a silly mistake and a subtle error in the existing code; inside i915_gem_retire_requests() we were resetting the sync_seqno of the target ring based on the seqno from this ring - which are only related by the order of their allocation, not retirement. Hence we were applying the optimisation that the rings were synchronised too early, fortunately the only real casualty there is the handling of seqno wrapping. v3: Do not forget to reset the sync_seqno upon module reinitialisation, ala resume. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=863861 Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> [v2] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: force restore on lid openDaniel Vetter2012-11-294-6/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There seem to be indeed some awkwards machines around, mostly those without OpRegion support, where the firmware changes the display hw state behind our backs when closing the lid. This force-restore logic has been originally introduced in commit c1c7af60892070e4b82ad63bbfb95ae745056de0 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Thu Sep 10 15:28:03 2009 -0700 drm/i915: force mode set at lid open time but after the modeset-rework we've disabled it in the vain hope that it's no longer required: commit 3b7a89fce3e3dc96b549d6d829387b4439044d0d Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Sep 17 22:27:21 2012 +0200 drm/i915: fix OOPS in lid_notify Alas, no. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54677 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57434 Tested-by: Krzysztof Mazur <krzysiek@podlesie.net> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Wait upon the last request seqno, rather than a future seqnoChris Wilson2012-11-291-2/+21
| | | | | | | | | | | | | | | | | | | | | In commit 69c2fc891343cb5217c866d10709343cff190bdc Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Jul 20 12:41:03 2012 +0100 drm/i915: Remove the per-ring write list the explicit flush was removed from i915_ring_idle(). However, we continued to wait upon the next seqno which now did not correspond to any request (except for the unusual condition of a failure to queue a request after execbuffer) and so would wait indefinitely. This has an important side-effect that i915_gpu_idle() does not cause the seqno to be incremented. This is vital if we are to be able to idle the GPU to handle seqno wraparound, as in subsequent patches. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: fix possible NULL dereference of dev_privMika Kuoppala2012-11-291-1/+2
| | | | | | | | Dereference dev_priv only after we know it is valid. Found with smatch. Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Increase the response time for slow SDVO devicesChris Wilson2012-11-291-12/+19
| | | | | | | | | | | | | | | Some devices may respond very slowly and only flag that the reply is pending within the first 15us response window. Be kind to such devices and wait a further 15ms, before checking for the pending reply. This moves the existing special case delay of 30ms down from the detection routine into the common path and pretends to explain it... v2: Simplify the loop constructs as suggested by Jani Nikula. References: https://bugs.freedesktop.org/show_bug.cgi?id=36997 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: set the VIC of the mode on the AVI InfoFramePaulo Zanoni2012-11-291-0/+2
| | | | | | | | | | | | | | | | We currently set "0" as the VIC value of the AVI InfoFrames. According to the specs this should be fine and work for every mode, so to my point of view we can't consider the current behavior as a bug. The problem is that we recently received a bug report (Kernel bug #50371) from a user that has an AV receiver that gives a black screen for any mode with VIC set to 0. So in order to make at least some modes work for him, this patch sets the correct VIC number when sending AVI InfoFrames. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=50371 Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm: add drm_mode_cea_vicPaulo Zanoni2012-11-292-0/+20
| | | | | | | | | | | | This function returns the VIC of the mode. This value can be used when creating AVI InfoFrames. Cc: Thierry Reding <thierry.reding@avionic-design.de> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=50371 Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Thierry Reding <thierry.reding@avionic-design.de> Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Fix pte updates in ggtt clear rangeBen Widawsky2012-11-291-2/+4
| | | | | | | | | | | | | | | | | | | | | | | This bug was introduced by me: commit e76e9aebcdbfebae8f4cd147e3c0f800d36e97f3 Author: Ben Widawsky <ben@bwidawsk.net> Date: Sun Nov 4 09:21:27 2012 -0800 drm/i915: Stop using AGP layer for GEN6+ The existing code uses memset_io which follows memset semantics in only guaranteeing a write of individual bytes. Since a PTE entry is 4 bytes, this can only be correct if the scratch page address is 0. This caused unsightly errors when we clear the range at load time, though I'm not really sure what the heck is referencing that memory anyway. I caught this is because I believe we have some other bug where the display is doing reads of memory we feel should be cleared (or we are relying on scratch pages to be a specific value). Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: promote Haswell to full supportPaulo Zanoni2012-11-231-1/+1
| | | | | | | Since it should be working a little bit better now. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Report the origin of the LVDS fixed panel modeChris Wilson2012-11-221-2/+13
| | | | | | | | Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jani Nikula <jani.nikula@intel.com> [danvet: resolve conflict around the call to intel_crtc_mode_get. And add the missing NULL check Chris spotted while at it.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: LVDS fallback to fixed-mode if EDID not presentChris Wilson2012-11-221-6/+1
| | | | | | | | | | | | | | | | | | | | Use the recorded panel fixed-mode to populate the get_modes() request in the absence of an EDID. Fixes regression from commit 9cd300e038d492af4990b04e127e0bd2df64b1ca Author: Jani Nikula <jani.nikula@intel.com> Date: Fri Oct 19 14:51:52 2012 +0300 drm/i915: Move cached EDID to intel_connector Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Jani Nikula <jani.nikula@intel.com> [danvet: Drop the retval-changing hunk, as suggested by Jani in his review and acked by Chris.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/sdvo: kfree the intel_sdvo_connector, not drm_connector, on destroyJani Nikula2012-11-221-1/+1
| | | | | | | | | | | | Since the base fields in both struct intel_connector and struct intel_sdvo_connector are at the beginning of the enclosing struct, the pointers are essentially the same, but there is no requirement or guarantee that this is always the case. Kfree the enclosing intel_sdvo_connector pointer that was originally allocated, not the enclosed drm_connector, in case someone ever rearranges the structs. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: drm_connector_property -> drm_object_propertyRob Clark2012-11-217-25/+25
| | | | | | | | | v2: Rebased. Signed-off-by: Rob Clark <rob@ti.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> (v1) [danvet: Pimp commit message a bit.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: use drm_send_vblank_event() helperRob Clark2012-11-211-13/+2
| | | | | Signed-off-by: Rob Clark <rob@ti.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Use pci_resource functions for BARs.Ben Widawsky2012-11-211-6/+2
| | | | | | | | | | | | | | | | This was leftover crap from kill-agp. The current code is theoretically broken for 64b bars. (I resist removing theoretically because I am too lazy to test). We still need to ioremap things ourselves because we want to ioremap_wc the PTEs. v2: Forgot to kill the tmp variable in v1 CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Borrow our struct_mutex for the direct reclaimChris Wilson2012-11-211-3/+22
| | | | | | | | | | | | | | If we have hit oom whilst holding our struct_mutex, then currently we cannot reap our own GPU buffers which likely pin most of memory, making an outright OOM more likely. So if we are running in direct reclaim and already hold the mutex, attempt to free buffers knowing that the original function can not continue until we return. v2: Add a note explaining that the mutex may be stolen due to pre-emption, and that is bad. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Defer assignment of obj->gtt_space until after all possible mallocsChris Wilson2012-11-211-20/+19
| | | | | | | | | | | | | | | | | As we may invoke the shrinker whilst trying to allocate memory to hold the gtt_space for this object, we need to be careful not to mark the drm_mm_node as activated (by assigning it to this object) before we have finished our sequence of allocations. Note: We also need to move the binding of the object into the actual pagetables down a bit. The best way seems to be to move it out into the callsites. Reported-by: Imre Deak <imre.deak@gmail.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Added small note to commit message to summarize review discussion.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Apply the IBX transcoder A w/a for HDMI to SDVO as wellChris Wilson2012-11-211-1/+37
| | | | | | | | | | | | | | | | | | As the SDVO/HDMI registers are multiplex, it is safe to assume that the w/a required for HDMI on IbexPoint, namely that the SDVO register cannot both be disabled and have selected transcoder B, is also required for SDVO. At least the modeset state checker detects that the transcoder selection is left in the undefined state, and so it appears sensible to apply the w/a: [ 1814.480052] WARNING: at drivers/gpu/drm/i915/intel_display.c:1487 assert_pch_hdmi_disabled+0xad/0xb5() [ 1814.480053] Hardware name: Libretto W100 [ 1814.480054] IBX PCH hdmi port still using transcoder B Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57066 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: implement WaMbcDriverBootEnable on HaswellPaulo Zanoni2012-11-211-0/+7
| | | | | | | | Also document the WA name for the previous gens that implement it. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: fix intel_ddi_get_cdclk_freq for ULT machinesPaulo Zanoni2012-11-212-0/+4
| | | | | | | | For now, this code is just used by the eDP AUX channel frequency. 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>
* drm/i915: make the panel fitter work on pipes B and C on HaswellPaulo Zanoni2012-11-211-1/+2
| | | | | | | | | | This goes on a separate patch since it won't apply on the stable trees and there's nothing using panel fitter on HSW on the older Kernels. 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>
* drm/i915: make the panel fitter work on pipes B and C on IVBPaulo Zanoni2012-11-212-1/+7
| | | | | | | | | | | | 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. Cc: stable@vger.kernel.org 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>
* drm/i915: don't intel_crt_init if DDI A has 4 lanesPaulo Zanoni2012-11-212-1/+4
| | | | | | | | | | | | | | DDI A and E have 4 lanes to share, so if DDI A is using 4 lanes, there's nothing left for DDI E, which means there's no CRT port on the machine. The bit we're checking here is programmed at system boot and it cannot be changed afterwards, so we cannot change the amount of lanes reserved for each DDI port. 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>
OpenPOWER on IntegriCloud