aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
* drm/i915: Fix intel_pipe_to_cpu_transcoder for UMSDaniel Vetter2014-02-11
| | | | | | | | | | | | | | | | | | We don't have all the drm_crtc&co hanging around in that case. This regression has been introduced in commit 391f75e2bf13f105d9e4a120736ccdd8e3bc638b Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Wed Sep 25 19:55:26 2013 +0300 drm/i915: Fix pre-CTG vblank counter Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=69521 Cc: stable@vger.kernel.org (for 3.13 only) Cc: 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: Disable dp aux irq on g4xDaniel Vetter2014-02-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Apparently it's broken in the exact same way as the gmbus irq. For reference of the full story see commit c12aba5aa0e60b7947bc8b6ea25ef55c4acf81a4 Author: Jiri Kosina <jkosina@suse.cz> Date: Tue Mar 19 09:56:57 2013 +0100 drm/i915: stop using GMBUS IRQs on Gen4 chips The effect is that we have a storm of unclaimed interrupts on the legacy irq line. If that one is used by a different device then the kernel will complain and rather quickly kill the irq source. Which breaks any device trying to actually use the legacy irq line. This regression has been introduced commit 4aeebd7443e36b0a40032e518a9338f48bd27efc Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Oct 31 09:53:36 2013 +0100 drm/i915: dp aux irq support for g4x/vlv Note that disabling MSI works around the issue, but we can't do that since apparently then the hw will miss interrupts. At least if relevant comments in i915_irq.c are accurate. v2: Cross-reference dp aux and gmbus gen4 comments. v3: Consolidate harder into i915_drv.h as suggested by Chris. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reported-and-tested-by: Jiri Kosina <jkosina@suse.cz> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: demote opregion excessive timeout WARN_ONCE to DRM_INFO_ONCEJani Nikula2014-02-04
| | | | | | | | | | | | | | The WARN_ONCE is a bit too verbose, make it a DRM_INFO_ONCE. While at it, add a #define for MAX_DSLP and make the message a bit more informative. v2: use DRM_INFO_ONCE, add MAX_DSLP, pimp the message. Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> 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: add DRM_INFO_ONCE() to print a one-time DRM_INFO() messageJani Nikula2014-02-04
| | | | | | | | | Just like DRM_INFO(), but only do it once. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* MAINTAINERS: Update drm/i915 git repoDaniel Vetter2014-02-04
| | | | | | | | | | | Moved to a common location so that Jani also can push to it, to avoid moving it every time I go on vacation. Please update autobuilders and everything else pointing at the drm-intel.git repo, the old one won't be updated any more. Cc: Dave Airlie <airlied@gmail.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: vlv: fix DP PHY lockup due to invalid PP sequencer setupImre Deak2014-01-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Atm we setup the HW panel power sequencer logic both for eDP and DP ports. On eDP we then go on and start the power on sequence and commence with link training when it's ready. On DP we don't do the power on sequencing but do the link training immediately. At this point the DP PHY block gets stuck, since - supposedly - it is waiting for the power on sequence to finish. The actual register write that seems to hold off the PHY is PIPEX_PP_ON_DELAYS[Panel Control Port Select]. Writing here a non-0 value eventually sets PIPEX_PP_STATUS[Require Asset Status] to 1 and blocks the PHY until the panel power on is ready. Fix this by not doing any PP sequencing setup for DP ports. Thanks to Ville Syrjälä, Jesse Barnes and Todd Previte for the help in tracking this down. Note that on older gmch platforms (where we have lvds instead of edp) we've hacked around this by writing the magic ABCD unlock key to PP registers, which disables the hw sanity checks. For edp all platforms thus far had the pch split, with the edp port in the north display complex and the PP registers on the pch the hw sanity checks (expressed through the "Require Asset Status" bit) was never functional, hence never a real issue. This regression has been introduce in commit bf13e81b904a37d94d83dd6c3b53a147719a3ead Author: Jani Nikula <jani.nikula@intel.com> Date: Fri Sep 6 07:40:05 2013 +0300 drm/i915: add support for per-pipe power sequencing on vlv Signed-off-by: Imre Deak <imre.deak@intel.com> [danvet: Add note about the bigger story here.] Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Fix the offset issue for the stolen GEM objectsAkash Goel2014-01-28
| | | | | | | | | | | | | | | | | | | | The 'offset' field of the 'scatterlist' structure was wrongly programmed with the offset value from the base of stolen area, whereas this field indicates the offset from where the interested data starts within the first PAGE pointed to by 'scattterlist' structure. As a result when a new GEM object allocated from stolen area is mapped to GTT, it could lead to an overwrite of GTT entries as the page count calculation will go wrong, refer the function 'sg_page_count'. v2: Modified the commit message. (Chris) Signed-off-by: Akash Goel <akash.goel@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71908 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69104 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Decouple GPU error reporting from ring initialisationChris Wilson2014-01-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently we report through our error state only the rings that have been initialised (as detected by ring->obj). This check is done after the GPU reset and ring re-initialisation, which means that the software state may not be the same as when we captured the hardware error and we may not print out any of the vital information for debugging the hang. This (and the implied object leak) is a regression from commit 3d57e5bd1284f44e325f3a52d966259ed42f9e05 Author: Ben Widawsky <ben@bwidawsk.net> Date: Mon Oct 14 10:01:36 2013 -0700 drm/i915: Do a fuller init after reset Note that we are already starting to get bug reports with incomplete error states from 3.13, which also hampers debugging userspace driver issues. v2: Prevent a NULL dereference on 830gm/845g after a GPU reset where the scratch obj may be NULL. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> References: https://bugs.freedesktop.org/show_bug.cgi?id=74094 Cc: stable@vger.kernel.org # please don't delay since it's a vital support/debug feature for the intel gfx stack in general Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [danvet: Add a bit of fluff to make it clear we need this expedited in stable.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* i915: remove pm_qos request on errorStanislaw Gruszka2014-01-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Not removing pm qos request and free memory for it can cause crash, when some other driver use pm qos. For example, this oops: BUG: unable to handle kernel paging request at fffffffffffffff8 IP: [<ffffffff81307a6b>] plist_add+0x5b/0xd0 Call Trace: [<ffffffff810acf25>] pm_qos_update_target+0x125/0x1e0 [<ffffffff810ad071>] pm_qos_add_request+0x91/0x100 [<ffffffffa053ec14>] e1000_open+0xe4/0x5b0 [e1000e] was caused by earlier i915 probe failure: [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x00000010, masking [drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f001 head 00003004 tail 00000000 start 00003000 [drm:i915_driver_load] *ERROR* failed to init modeset i915: probe of 0000:00:02.0 failed with error -5 Bug report: http://bugzilla.redhat.com/show_bug.cgi?id=1057533 Reported-by: Giandomenico De Tullio <ghisha@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> [danvet: Drop unnecessary code movement.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Revert "drm/i915: Mask reserved bits in display/sprite address registers"Daniel Vetter2014-01-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 446f254566ea8911c9e19c7bc8a162fc0e53cf31. I've left the masking in the pageflip code since that seems to be some useful piece of preemptive robustness. Iirc I've merged this patch under the assumption that the BIOS leaves some random gunk in the lower bits and gets unhappy if we trample on them. We have quite a few case like this, so this made sense. Now I've just learned that there's actual hardware features bits in the low 12 bits, and the kernel needs to preserve them to allow a userspace blob to do its job. Given Dave Airlie's clear stance on userspace blob drivers I've quickly chatted with him and he doesn't seem too happy. So let's revert this. If there are indeed bits that we must preserve in this range then we can ressurrect this patch, but with proper documentation for those bits supplied. And we probably also need to think a bit about interactions with our driver. Cc: Armin Reese <armin.c.reese@intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Dave Airlie <airlied@linux.ie> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: VLV2 - Fix hotplug detect bitsTodd Previte2014-01-23
| | | | | | | | | | | | | | | | | | | | Add new definitions for hotplug live status bits for VLV2 since they're in reverse order from the gen4x ones. Changelog: - Restored gen4 bit definitions - Added new definitions for VLV2 - Added platform check for IS_VALLEYVIEW() in dp_detect to use the correct bit defintions - Replaced a lost trailing brace for the added switch() Signed-off-by: Todd Previte <tprevite@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73951 [danvet: Switch to _VLV postfix instead of prefix and regroupg comments again so that the g4x warning is right next to those defines. Also add a _G4X suffix for those special ones. Also cc stable.] Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Allow reading the TIMESTAMP register on Gen8.Kenneth Graunke2014-01-22
| | | | | | | Nothing's changed here; we just need to bump the generation check. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Repeat evictions whilst pageflip completions are outstandingChris Wilson2014-01-22
| | | | | | | | | | | | | | | | Since an old pageflip will keep its scanout buffer object pinned until it has executed its unpin task on the common workqueue, we can clog up our GGTT with stale pinned objects. As we cannot flush those workqueues without dropping our locks, we have to resort to falling back to userspace and telling them to repeat the operation in order to have a chance to run our workqueues and free up the required memory. If we fail, then we are forced to report ENOSPC back to userspace causing the operation to fail and best-case scenario is that it introduces temporary corruption. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Wait for completion of pending flips when starved of fencesChris Wilson2014-01-22
| | | | | | | | | | | | | | | | | | | | | | | | On older generations (gen2, gen3) the GPU requires fences for many operations, such as blits. The display hardware also requires fences for scanouts and this leads to a situation where an arbitrary number of fences may be pinned by old scanouts following a pageflip but before we have executed the unpin workqueue. This is unpredictable by userspace and leads to random EDEADLK when submitting an otherwise benign execbuffer. However, we can detect when we have an outstanding flip and so cause userspace to wait upon their completion before finally declaring that the system is starved of fences. This is really no worse than forcing the GPU to stall waiting for older execbuffer to retire and release their fences before we can reallocate them for the next execbuffer. v2: move the test for a pending fb unpin to a common routine for later reuse during eviction Reported-and-tested-by: dimon@gmx.net Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73696 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: don't disable DP port after a failed link trainingImre Deak2014-01-22
| | | | | | | | | | | | | | | | | | | | | Atm after a failed link training we disable the DP port. This can happen during a modeset-enable or a DP link re-establishment. The latter can be a problem and we shouldn't disable the DP port, see the previous patch for the reasoning. In the former case the right thing would be to disable the DP port, but also the rest of the pipe. As a stop-gap solution leave the DP port enabled in both cases. It is an improvement on its own (avoiding HW lock ups) and the proper solution for the first case requires a bigger change, so let's keep that on the TODO list. v2: - fix explanation of change impact (Chris) Suggested-by: Daniel Vetter <daniel@ffwll.ch> 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 disable the DP port if the link is lostImre Deak2014-01-22
| | | | | | | | | | | | | | | | | | | | | | | | Currently if the DP link is lost (either because of a hot unplug, or failed link status check) we disable the DP port, but leave the rest of the pipe running. This is incompatible with the modeset disabling sequence of some platforms/configurations. At least this is the case for DP ports on the CPU as opposed to PCH. Atm we'll also get a warning when we do a modeset disable after the above link lost event, since we expect the DP port to be enabled at this point (see the bugzilla ticket for the related dmesg). Note that with this patch we'll still end up disabling the port, thanks to the HPD uevent and subsequent modeset disable. See also the next patch fixing the other half of this issue. Solution suggested by Ville. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70570 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: Eliminate lots of WARNs when there's no backlight presentVille Syrjälä2014-01-22
| | | | | | | | | | | | | | | | My 855gm doesn't register the intel backlight but it still ends up calling the backlight code to enable/disable the backlight via the LVDS code. This leads to some WARNs due to backlight.max being 0. Let's have intel_panel_enable_backlight() and intel_panel_disable_backlight() check whether there's a backlight present or not. Also move the backlight.present check from asle_set_backlight() into intel_panel_set_backlight() for some extra symmetry. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: g4x/vlv: fix dp aux interrupt maskImre Deak2014-01-22
| | | | | | | | | | | | | | Fix typo possibly leading to timed out DP aux transactions on ports C,D. Introduced in: Commmit 4aeebd7443e36b0a40032e518a9338f48bd27efc Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Oct 31 09:53:36 2013 +0100 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72210 Signed off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/ppgtt: Defer request freeing on resetBen Widawsky2014-01-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need to defer the free request until the object/vma is capable of being freed - or else we have a problem when we try to destroy the context. The exact same issue is described and fixed here: commit e20780439b26ba95aeb29d3e27cd8cc32bc82a4c Author: Ben Widawsky <ben@bwidawsk.net> Date: Fri Dec 6 14:11:22 2013 -0800 drm/i915: Defer request freeing I had this fix previously, but decided not to keep it for some reason I can no longer remember. gem_reset_stats is a really good test at hitting the problem. For the inquisitive: [ 170.516392] ------------[ cut here ]------------ [ 170.517227] WARNING: CPU: 1 PID: 105 at drivers/gpu/drm/drm_mm.c:578 drm_mm_takedown+0x2e/0x30 [drm]() [ 170.518064] Memory manager not clean during takedown. [ 170.518941] CPU: 1 PID: 105 Comm: kworker/1:1 Not tainted 3.13.0-rc4-BEN+ #28 [ 170.519787] Hardware name: Hewlett-Packard HP EliteBook 8470p/179B, BIOS 68ICF Ver. F.02 04/27/2012 [ 170.520662] Call Trace: [ 170.521517] [<ffffffff814f0589>] dump_stack+0x4e/0x7a [ 170.522373] [<ffffffff81049e6d>] warn_slowpath_common+0x7d/0xa0 [ 170.523227] [<ffffffff81049edc>] warn_slowpath_fmt+0x4c/0x50 [ 170.524079] [<ffffffffa06c414e>] drm_mm_takedown+0x2e/0x30 [drm] [ 170.524934] [<ffffffffa07213f3>] gen6_ppgtt_cleanup+0x23/0x110 [i915] [ 170.525777] [<ffffffffa07837ed>] ppgtt_release.part.5+0x24/0x29 [i915] [ 170.526603] [<ffffffffa071aaa5>] i915_gem_context_free+0x195/0x1a0 [i915] [ 170.527423] [<ffffffffa071189d>] i915_gem_free_request+0x9d/0xb0 [i915] [ 170.528247] [<ffffffffa0718af9>] i915_gem_reset+0x1f9/0x3f0 [i915] [ 170.529065] [<ffffffffa0700cce>] i915_reset+0x4e/0x180 [i915] [ 170.529870] [<ffffffffa070829d>] i915_error_work_func+0xcd/0x120 [i915] [ 170.530666] [<ffffffff8106c13a>] process_one_work+0x1fa/0x6d0 [ 170.531453] [<ffffffff8106c0d8>] ? process_one_work+0x198/0x6d0 [ 170.532230] [<ffffffff8106c72b>] worker_thread+0x11b/0x3a0 [ 170.532996] [<ffffffff8106c610>] ? process_one_work+0x6d0/0x6d0 [ 170.533771] [<ffffffff810743ef>] kthread+0xff/0x120 [ 170.534548] [<ffffffff810742f0>] ? insert_kthread_work+0x80/0x80 [ 170.535322] [<ffffffff814f97ac>] ret_from_fork+0x7c/0xb0 [ 170.536089] [<ffffffff810742f0>] ? insert_kthread_work+0x80/0x80 [ 170.536847] ---[ end trace 3d4c12892e42d58f ]--- v2: Whitespace fix. (Chris) Note: This is a bug that only hits the ppgtt topic branch but I've figured that doing the request cleanup in this order is generally the right thing to do. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Add a code comment to clarify what's actually going on since the lifetime rules aroung ppgtt cleanup are ... fuzzy a best atm. Also add a note about why we need this.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* i915: send D1 opregion notificationKristen Carlson Accardi2014-01-22
| | | | | | | The opregion notification for runtime suspend is currently D1, not D3. Signed-off-by: Kristen Carlson Accardi <kristen@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/bdw: remove preliminary_hw_support flag from BDWJesse Barnes2014-01-22
| | | | | | | | | It ought to work ok in 3.14. We have some fun stuff coming after that, but all the basics are in place now and seem relatively stable. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Acked by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Tune down reset_stat output from ERROR to debugDaniel Vetter2014-01-22
| | | | | | | | | | | | | | | | This is user-triggerable and hence we should not allow it to spam dmesg. Also, it upsets the nice dmesg tracking piglit does. Note that this is just extra debugging information, mostly unwanted, in case of a hang and that there is a separate message to the user giving instructions on how to report a bug for a GPU hang. v2: Add note as suggests in Chris' reply. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72740 Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Make semaphore modparam ROBen Widawsky2014-01-22
| | | | | | | | | | | | | A couple patches in the upcoming rework of semaphores will break if semaphores are toggled by the user at various times. Since the code cleanups there seem to be an overall win, and toggling semaphores at runtime is not a terribly useful thing to do, simply make the module parameter read-only. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Fix disabled semaphoresBen Widawsky2014-01-22
| | | | | | | | | | | | | | | | | | | | | | | The ring will emit too many if semaphores are disabled since we do not add the correct number to num_dwords anymore. This was introduced: commit 52ed23253b68e1cf154b03d91bed619504cf955b Author: Ben Widawsky <benjamin.widawsky@intel.com> Date: Mon Dec 16 20:50:38 2013 -0800 drm/i915: Don't emit mbox updates without semaphores FWIW, the bug was fixed later in the series. /me hangs head in shame. Daniel: Also note that we should have merged the read-only semaphore modparam before this patch. Reported-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Clarify relocation errnosBen Widawsky2014-01-22
| | | | | | | | | | | | | While trying to find a random -EINVAL from a failing test, I noticed we had a few hard to follow return values. The first two hunks in this patch replace completely useless initialization of ret. The last several hunks help to distinguish between altering 'return ret' and 'return <ERROR>' Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Spelling s/auxilliary/auxiliary/Geert Uytterhoeven2014-01-22
| | | | | Signed-off-by: Geert Uytterhoeven <geert+renesas@linux-m68k.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge branch 'drm-vbl-timestamp' of git://gitorious.org/vsyrjala/linux into ↵Dave Airlie2014-01-21
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | drm-next Here's the vblank timestamp pull request you wanted. I addressed the few bugs that Mario pointed out and added the r-bs. As it has been a while since I made the changes, I gave it a quick spin on a few different i915 machines. Fortunately everything still seems to be fine. * 'drm-vbl-timestamp' of git://gitorious.org/vsyrjala/linux: drm/i915: Add a kludge for DSL incrementing too late and ISR not working drm/radeon: Move the early vblank IRQ fixup to radeon_get_crtc_scanoutpos() drm: Pass 'flags' from the caller to .get_scanout_position() drm: Fix vblank timestamping constants for interlaced modes drm/i915: Fix scanoutpos calculations for interlaced modes drm: Change {pixel,line,frame}dur_ns from s64 to int drm: Use crtc_clock in drm_calc_timestamping_constants() drm/radeon: Populate crtc_clock in radeon_atom_get_tv_timings() drm: Simplify the math in drm_calc_timestamping_constants() drm: Improve drm_calc_timestamping_constants() documentation drm/i915: Call drm_calc_timestamping_constants() earlier drm/i915: Kill hwmode save/restore drm: Pass the display mode to drm_calc_vbltimestamp_from_scanoutpos() drm: Pass the display mode to drm_calc_timestamping_constants()
| * drm/i915: Add a kludge for DSL incrementing too late and ISR not workingVille Syrjälä2014-01-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On pre-PCH platforms ISR doesn't seem to be an actual ISR, at least as far as display interrupts are concerned. Instead it sort of looks like some ISR bits just directly reflect the corresponding bit from PIPESTAT. The bit appears in the ISR only if the PIPESTAT interrupt is enabled. So in that sense it sort of looks a bit like the south interrupt scheme on PCH platforms. So it goes something a bit like this: PIPESTAT.status & PIPESTAT.enable -> ISR -> IMR -> IIR -> IER -> actual interrupt In any case that means the intel_pipe_in_vblank_locked() doesn't actually work for pre-PCH platforms. As a last resort, add a similar kludge as radeon has that fixes things up if we got called from the vblank interrupt, but the scanline counter value indicates that we're not quite there yet. We know that the scanline counter increments at hsync but is otherwise accurate, so we can limit the kludge to the line just prior to vblank start, instead of the relative distance that radeon uses. Reviewed-by: mario.kleiner.de@gmail.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
| * drm/radeon: Move the early vblank IRQ fixup to radeon_get_crtc_scanoutpos()Ville Syrjälä2014-01-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | i915 doesn't need this kludge for most platforms. Although we do appear to need something similar on certain platforms, but we can be more accurate when we apply the adjustment since we know exactly why the scanline counter doesn't always quite match the vblank status. Also the current code doesn't handle interlaced modes correctly, and we already deal with interlaced modes in i915 code. So let's just move the current code to radeon_get_crtc_scanoutpos() since that's why it was added. For i915 we'll add a more finely targeted variant. v2: Fix vpos vs. *vpos bug (Mario) Reviewed-by: mario.kleiner.de@gmail.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
| * drm: Pass 'flags' from the caller to .get_scanout_position()Ville Syrjälä2014-01-20
| | | | | | | | | | | | | | | | | | | | Preparation for moving the early vblank IRQ logic into radeon_get_crtc_scanoutpos(). v2: Fix radeon_drv.c compile warning (Mario) Reviewed-by: mario.kleiner.de@gmail.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
| * drm: Fix vblank timestamping constants for interlaced modesVille Syrjälä2014-01-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We're currently miscalculating the line and pixel durations for interlaced modes. crtc_htotal and crtc_vtotal are the full frame timings, and so is crtc_clock, so we can compute the line and pixel durations from those w/o any extra adjustments. But we actually want framedur_ns to be the field, not frame, duration, so we must divide it by two. This should make the scanout based vblank timestamp corrections work correctly with interlaced modes, at least for i915. It all depends whether we keep the field or frame timings in the display mode crtc_ timings. v2: Preserve halve->half typo fix that happened in the meantine Reviewed-by: mario.kleiner.de@gmail.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
| * drm/i915: Fix scanoutpos calculations for interlaced modesVille Syrjälä2014-01-20
| | | | | | | | | | | | | | | | | | | | | | | | The scanline counter counts lines in the current field, not the entire frame. But the crtc_ timings are the values for the entire frame. Divide the vertical timings by 2 to make them match the scanline counter. The rounding was carefully chosen to make it do the right thing wrt. the observed scanline counter and ISR vblank bit behaviour. Reviewed-by: mario.kleiner.de@gmail.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
| * drm: Change {pixel,line,frame}dur_ns from s64 to intVille Syrjälä2014-01-20
| | | | | | | | | | | | | | | | | | | | | | Using s64 for the timestamping constants is wasteful. Signed 32bit integers get us a range of over +-2 seconds. Presuming that no-one wants to a vrefresh rate less than 0.5, we can switch to using int for the timestamping constants. We save a few bytes in drm_crtc and avoid a bunch of 64bit math. Reviewed-by: mario.kleiner.de@gmail.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
| * drm: Use crtc_clock in drm_calc_timestamping_constants()Ville Syrjälä2014-01-20
| | | | | | | | | | | | | | | | | | | | | | | | | | drm_calc_timestamping_constants() computes the pixel/line/frame durations based on the crtc_ timing values. The corresponding pixel clock is in mode->crtc_clock, so we need to use that instead of mode->clock. This should fix drm_calc_timestamping_constants() for frame packing stereo modes. Reviewed-by: mario.kleiner.de@gmail.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
| * drm/radeon: Populate crtc_clock in radeon_atom_get_tv_timings()Ville Syrjälä2014-01-20
| | | | | | | | | | | | | | | | | | | | | | | | | | crtc_clock is now supposed to be the actual pixel clock corresponding to the other crtc_ timing values. Populate crtc_clock appropriately in radeon_atom_get_tv_timings(). This was the only obvious place where we frob with the crtc_ timigns directly instead of calling drm_mode_set_crtcinfo() which would also update crtc_clock. Reviewed-by: mario.kleiner.de@gmail.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
| * drm: Simplify the math in drm_calc_timestamping_constants()Ville Syrjälä2014-01-20
| | | | | | | | | | | | | | | | | | | | | | | | drm_calc_timestamping_constants() makes the math more complex than necessary. - multipying the dotclock by 1000 is pointless, just makes all the numbers bigger - div64_u64() is also pointless, div_u64 is enough - pixeldur_ns doesn't need any 64bit math Reviewed-by: mario.kleiner.de@gmail.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
| * drm: Improve drm_calc_timestamping_constants() documentationVille Syrjälä2014-01-20
| | | | | | | | | | | | | | | | Move the long blurp to into the body of the comment, leaving only a short summary line at the top. Reviewed-by: mario.kleiner.de@gmail.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
| * drm/i915: Call drm_calc_timestamping_constants() earlierVille Syrjälä2014-01-20
| | | | | | | | | | | | | | | | | | Update the pixel/line/frame duration information when we switch to the new pipe config. This will keep the timestamping constants in better sync with the real hardware state. Reviewed-by: mario.kleiner.de@gmail.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
| * drm/i915: Kill hwmode save/restoreVille Syrjälä2014-01-20
| | | | | | | | | | | | | | | | drm core no longer uses crtc->hwmode, and neither does i915, so we can totally ignore it in i915. Reviewed-by: mario.kleiner.de@gmail.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
| * drm: Pass the display mode to drm_calc_vbltimestamp_from_scanoutpos()Ville Syrjälä2014-01-20
| | | | | | | | | | | | | | | | | | Rather than using crtc->hwmode, just pass the relevant mode to drm_calc_vbltimestamp_from_scanoutpos(). This removes the last hwmode usage from core drm. Reviewed-by: mario.kleiner.de@gmail.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
| * drm: Pass the display mode to drm_calc_timestamping_constants()Ville Syrjälä2014-01-20
| | | | | | | | | | | | | | | | | | We don't really use hwmode anymore in i915, so eliminating its use from the core code seems prudent. Just pass the appropriate mode to drm_calc_timestamping_constants(). Reviewed-by: mario.kleiner.de@gmail.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
* | Merge branch 'topic/core-stuff' of ↵Dave Airlie2014-01-21
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-next Some straggling drm core patches * 'topic/core-stuff' of git://people.freedesktop.org/~danvet/drm-intel: drm/gem: Always initialize the gem object in object_init drm/edid: Populate picture aspect ratio for CEA modes drm/edid: parse the list of additional 3D modes drm/edid: split VIC display mode lookup into a separate function drm: Make the connector mode_valid() vfunc return a drm_mode_status enum
| * | drm/gem: Always initialize the gem object in object_initDaniel Vetter2014-01-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At least drm/i915 expects that the obj->dev pointer is set even in failure paths. Specifically when the shmem initialization fails we call i915_gem_object_free which needs to deref obj->base.dev to get at the slab pointer in the device private structure. And the shmem allocation can easily fail when userspace is hitting open file limits. Doing the structure init even when the shmem file allocation fails prevents this Oops. This is a regression from commit 89c8233f82d9c8af5b20e72e4a185a38a7d3c50b Author: David Herrmann <dh.herrmann@gmail.com> Date: Thu Jul 11 11:56:32 2013 +0200 drm/gem: simplify object initialization v2: Add regression note which Chris supplied. Testcase: igt/gem_fd_exhaustion Reported-and-Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> References: http://lists.freedesktop.org/archives/intel-gfx/2014-January/038433.html Cc: stable@vger.kernel.org Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Cc: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/edid: Populate picture aspect ratio for CEA modesVandana Kannan2014-01-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adding picture aspect ratio for CEA modes based on CEA-861D Table 3 or CEA-861E Table 4. This is useful for filling up the detail in AVI infoframe. v2: Ville's review comments incorporated Added picture aspect ratio as part of edid_cea_modes instead of DRM_MODE Signed-off-by: Vandana Kannan <vandana.kannan@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/edid: parse the list of additional 3D modesThomas Wood2014-01-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Parse 2D_VIC_order_X and 3D_Structure_X from the list at the end of the HDMI Vendor Specific Data Block. v2: Use an offset value depending on 3D_Multi_present and add detail_present. (Ville Syrjälä) v3: Make sure the list is parsed even if 3D_Structure_ALL/MASK is not present. (Ville Syrjälä) Fix one length check and remove another. (Ville Syrjälä) Signed-off-by: Thomas Wood <thomas.wood@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/edid: split VIC display mode lookup into a separate functionThomas Wood2014-01-20
| | | | | | | | | | | | | | | | | | Signed-off-by: Thomas Wood <thomas.wood@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm: Make the connector mode_valid() vfunc return a drm_mode_status enumDamien Lespiau2014-01-20
| |/ | | | | | | | | | | | | To make it clear what exactly mode_valid() should return. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | Merge branch 'vmwgfx-next' of git://people.freedesktop.org/~thomash/linux ↵Dave Airlie2014-01-21
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | into drm-next Just a single fix for sparse/smatch warnings introduced by the previous vmwgfx-next pull. * 'vmwgfx-next' of git://people.freedesktop.org/~thomash/linux: drm/vmwgfx: Fix recently introduced sparse / smatch warnings and errors
| * | drm/vmwgfx: Fix recently introduced sparse / smatch warnings and errorsThomas Hellstrom2014-01-21
| |/ | | | | | | | | | | Reported-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrant <jakob@vmware.com>
* | Merge branch 'drm-next-3.14' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie2014-01-20
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into drm-next New tree with the INFO ioctl merge fixed up. This also adds a couple of additional minor fixes. A few more changes for 3.14, mostly just bug fixes. Note that: drm/radeon: add query to fetch the max engine clock. will conflict with 3.13 final, but the fix is pretty obvious. * 'drm-next-3.14' of git://people.freedesktop.org/~agd5f/linux: (22 commits) drm/radeon: add UVD support for OLAND drm/radeon: fix minor typos in si_dpm.c drm/radeon: set the full cache bit for fences on r7xx+ drm/radeon: fix surface sync in fence on cayman (v2) drm/radeon/dpm: disable mclk switching on desktop RV770 drm/radeon: fix endian handling in radeon_atom_init_mc_reg_table drm/radeon: write gfx pg bases even when gfx pg is disabled drm/radeon: bail early from enable ss in certain cases drm/radeon: handle ss percentage divider properly drm/radeon: add query to fetch the max engine clock (v2) drm/radeon/dp: sleep after powering up the display drm/radeon/dp: use usleep_range rather than udelay drm/radeon/dp: bump i2c-over-aux retries to 7 drm/radeon: disable ss on DP for DCE3.x drm/radeon/cik: use hw defaults for TC_CFG registers drm/radeon: disable dpm on BTC drm/radeon/cik: use WAIT_REG_MEM special op for CP HDP flush drm/radeon/cik: use POLL_REG_MEM special op for sDMA HDP flush drm/radeon: consolidate sdma hdp flushing code for CIK drm/radeon: consolidate cp hdp flushing code for CIK ...
generated by cgit v1.2.2 (git 2.25.0) at 2025-08-27 14:51:14 -0400