summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915 (follow)
Commit message (Collapse)AuthorAgeFilesLines
* drm: add register and unregister functions for connectorsThomas Wood2014-06-199-14/+14
| | | | | | | | | | Introduce generic functions to register and unregister connectors. This provides a common place to add and remove associated user space interfaces. Signed-off-by: Thomas Wood <thomas.wood@intel.com> Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm: Remove DRM_ARRAY_SIZE() for ARRAY_SIZE()Damien Lespiau2014-06-102-2/+2
| | | | | | | | | | | | I cannot see a need to provide a DRM_ version of ARRAY_SIZE(), only used in a few places. I suspect its usage has been spread by copy & paste rather than anything else. Let's just remove it for plain ARRAY_SIZE(). Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* Merge tag 'drm-intel-fixes-2014-06-06' of ↵Dave Airlie2014-06-0618-180/+855
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm-intel into drm-next > Bunch of stuff for 3.16 still: > - Mipi dsi panel support for byt. Finally! From Shobhit&others. I've > squeezed this in since it's a regression compared to vbios and we've > been ridiculed about it a bit too often ... > - connection_mutex deadlock fix in get_connector (only affects i915). > - Core patches from Matt's primary plane from Matt Roper, I've pushed the > i915 stuff to 3.17. > - vlv power well sequencing fixes from Jesse. > - Fix for cursor size changes from Chris. > - agpbusy fixes from Ville. > - A few smaller things. > * tag 'drm-intel-fixes-2014-06-06' of git://anongit.freedesktop.org/drm-intel: (32 commits) drm/i915: BDW: Adding missing cursor offsets. drm: Fix getconnector connection_mutex locking drm/i915/bdw: Only use 2g GGTT for 32b platforms drm/i915: Nuke pipe A quirk on i830M drm/i915: fix display power sw state reporting drm/i915: Always apply cursor width changes drm/i915: tell the user if both KMS and UMS are disabled drm/plane-helper: Add drm_plane_helper_check_update() (v3) drm: Check CRTC compatibility in setplane drm/i915: use VBT to determine whether to enumerate the VGA port drm/i915: Don't WARN about ring idle bit on gen2 drm/i915: Silence the WARN if the user tries to GTT mmap an incoherent object drm/i915: Move the C3 LP write bit setup to gen3_init_clock_gating() for KMS drm/i915: Enable interrupt-based AGPBUSY# enable on 85x drm/i915: Flip the sense of AGPBUSY_DIS bit drm/i915: Set AGPBUSY# bit in init_clock_gating drm/i915/vlv: add pll assertion when disabling DPIO common well drm/i915/vlv: move DPIO common reset de-assert into __vlv_set_power_well drm/i915/vlv: re-order power wells so DPIO common comes after TX drm/i915/vlv: move CRI refclk enable into __vlv_set_power_well ...
| * drm/i915: BDW: Adding missing cursor offsets.Rodrigo Vivi2014-06-051-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BDW uses IVB cursor offsets. Whithout this patch it is not possible to use multiple outputs with cursor on BDW. The cursor gets completely crazy because update position uses the wrong cursor register for the second pipe. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Cc: stable@vger.kernel.org Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79621 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/bdw: Only use 2g GGTT for 32b platformsBen Widawsky2014-06-051-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Daniel requested in the bug that I use a 3GB fallback size. Since this is not in the spec as a valid size, I decided against it. We could potentially add a patch to bump it to 3GB on top of this one. This probably should be CC: stable - but I'll let the powers that be decide that one. Regression from a revert of the revert: commit 7907f45bf9f67a1c5e5d4ae05bab428d7c2f43b2 Author: Ben Widawsky <benjamin.widawsky@intel.com> Date: Wed Feb 19 22:05:46 2014 -0800 Revert "drm/i915/bdw: Limit GTT to 2GB" v2: Change ifdef to 32b, instead of ifndef update comment v3. Update comment to not wrap (Daniel). Update commit message v4: s/CONFIG_32/CONFIG_X86_32 (Jani). v5: s/CONFIG_x86_32BIT/CONFIG_x86_32, as meant in v4 s/32B/32b (chris) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76619 Cc: stable@vger.kernel.org Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Tested-by: "Yang, Guang A" <guang.a.yang@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Nuke pipe A quirk on i830MDaniel Vetter2014-06-051-3/+0
| | | | | | | | | | | | | | | | | | | | | | Apparently it does more harm than good. Thomas Richter reports that it helps his machine (Thinkpad X31) and there's another report from a Fujitsu S6010. Also, we've nuked it on i845G already to make Chris' machine happy. Cc: Thomas Richter <richter@rus.uni-stuttgart.de> References: http://mid.mail-archive.com/538C54E0.8090507@rus.uni-stuttgart.de Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: fix display power sw state reportingImre Deak2014-06-051-1/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Atm, we refcount both power domains and power wells and intel_display_power_enabled_sw() returns the power domain refcount. What the callers are really interested in though is the sw state of the underlying power wells. Due to this we will report incorrectly that a given power domain is off if its power wells were enabled via another power domain, for example POWER_DOMAIN_INIT which enables all power wells. As a fix return instead the state based on the refcount of all power wells included in the passed in power domain. References: https://bugs.freedesktop.org/show_bug.cgi?id=79505 References: https://bugs.freedesktop.org/show_bug.cgi?id=79038 Reported-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Always apply cursor width changesChris Wilson2014-06-053-58/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is possible for userspace to create a big object large enough for a 256x256, and then switch over to using it as a 64x64 cursor. This requires the cursor update routines to check for a change in width on every update, rather than just when the cursor is originally enabled. This also fixes an issue with 845g/865g which cannot change the base address of the cursor whilst it is active. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> [Antti:rebased, adjusted macro names and moved some lines, no functional changes] Reviewed-by: Antti Koskipaa <antti.koskipaa@linux.intel.com> Tested-by: Antti Koskipaa <antti.koskipaa@linux.intel.com> Cc: stable@vger.kernel.org Testcase: igt/kms_cursor_crc/cursor-size-change Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: tell the user if both KMS and UMS are disabledJani Nikula2014-06-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If both KMS is disabled (by i915.modeset=0 or nomodeset parameters) and UMS is disabled (by CONFIG_DRM_I915_UMS=n, the default), the user might not be aware his setup is not supported. Inform the users (and, by extension, the poor i915 developers having to read their dmesgs in bug reports) why their graphics experience might be lacking. A similar message was added on the UMS path in commit e147accbd19f55489dabdcc4dc3551cc3e3f2553 Author: Jani Nikula <jani.nikula@intel.com> Date: Thu Oct 10 15:25:37 2013 +0300 drm/i915: tell the user KMS is required for gen6+ but it won't be reached if CONFIG_DRM_I915_UMS=n since commit b30324adaf8d2e5950a602bde63030d15a61826f Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Nov 13 22:11:25 2013 +0100 drm/i915: Deprecated UMS support v2: Use DRM_DEBUG_DRIVER. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: use VBT to determine whether to enumerate the VGA portJesse Barnes2014-06-051-1/+1
| | | | | | | | | | | | | | | | | | Some platforms may not have it, and enumerating it is both confusing and time consuming due to the hotplug and DDC probing. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Don't WARN about ring idle bit on gen2Ville Syrjälä2014-06-051-1/+1
| | | | | | | | | | | | | | | | | | Gen2 doesn't have the ring idle/stop bits in the SCPD/MI_MODE register, so don't go spewing warnings about the state of those bits. 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: Silence the WARN if the user tries to GTT mmap an incoherent objectChris Wilson2014-06-051-1/+1
| | | | | | | | | | | | | | | | | | | | If the user tries to mmap through the GTT an object that is marked as snooped, we report an error rather than allow the GPU to hang the machine. The choice of EINVAL, however, was unfortunate as we turn that into a WARN rather than a quiet SIGBUS. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Move the C3 LP write bit setup to gen3_init_clock_gating() for KMSVille Syrjälä2014-06-052-1/+4
| | | | | | | | | | | | | | | | | | | | | | Move the MI_ARB_STATE MI_ARB_C3_LP_WRITE_ENABLE setup to gen3_init_clock_gating() from i915_gem_load() when KMS is enabled. Leave it in i915_gem_load() for the UMS case, but add an explcit check, just to make it easier to spot it when we eventually rip out UMS support. 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: Enable interrupt-based AGPBUSY# enable on 85xVille Syrjälä2014-06-052-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 85x also has a similar AGPBUSY# bit as gen3. Enable it to make sure vblank interrupts don't get dealyed during C3 state. There's also another bit which controls whether AGPBUSY# is asserted based on pending cacheable cycles and interrupts, or just based on pending commands in the ring and interrupts. Select the cacheable cycles mode since that seems to be the new way of doing things in 85x, and it does give slightly better C3 residency numbers with glxgears running. 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: Flip the sense of AGPBUSY_DIS bitVille Syrjälä2014-06-052-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | My Gen3 Bspec lists the AGPBUSY# bit in INSTPM as an enable bit rather than a disable bit. Our code has the opposite idea. Make the code match the spec. Might fix some gen3 C3 related interrupt delivery problems. Untested due to lack of hardware. v2: call it AGPBUSY_INT_EN to make it clearer it has to do with interrupts 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: Set AGPBUSY# bit in init_clock_gatingVille Syrjälä2014-06-052-7/+3
| | | | | | | | | | | | | | | | | | I don't see why we wouldn't want interrupts to wake up the CPU from C3 always, so just set the AGPBUSY# bit in gen3_init_clock_gating(). 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/vlv: add pll assertion when disabling DPIO common wellJesse Barnes2014-06-051-0/+4
| | | | | | | | | | | | | | | | When doing this, all PLLs should be disabled. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/vlv: move DPIO common reset de-assert into __vlv_set_power_wellJesse Barnes2014-06-052-22/+30
| | | | | | | | | | | | | | | | We need to do this anytime we power gate the DPIO common well. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/vlv: re-order power wells so DPIO common comes after TXJesse Barnes2014-06-051-6/+6
| | | | | | | | | | | | | | | | There may be a dependency here. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/vlv: move CRI refclk enable into __vlv_set_power_wellJesse Barnes2014-06-052-8/+11
| | | | | | | | | | | | | | | | | | This needs to be done before we power back on the CMN_BC well so the PHY can calibrate properly. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/vlv: drop power well enable in uncore_sanitizeJesse Barnes2014-06-051-18/+0
| | | | | | | | | | | | | | | | We do this at runtime and later on now. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/vlv: assert and de-assert sideband reset at boot and resume v3Jesse Barnes2014-06-053-4/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a bit like the CMN reset de-assert we do in DPIO_CTL, except that it resets the whole common lane section of the PHY. This is required on machines where the BIOS doesn't do this for us on boot or resume to properly re-calibrate and get the PHY ready to transmit data. Without this patch, such machines won't resume correctly much of the time, with the symptom being a 'port ready' timeout and/or a link training failure. Note that simply asserting reset at suspend and de-asserting at resume is not sufficient, nor is simply de-asserting at boot. Both of these cases have been tested and have still been found to have failures on some configurations. v2: extract simpler set_power_well function for use in reset_dpio (Imre) move to reset_dpio (Daniel & Ville) v3: don't reset if DPIO reset is already de-asserted (Imre) Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: dsi: fix pipe-off timeout due to port vs. pipe disable orderingImre Deak2014-06-051-5/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we disable first the port (by disabling DPI) and only then the display pipe the pipe-off flag will never be set, possibly leading to a hanged pipe state at the next modeset-enable. Note that according to the VLV2 display cluster HAS, we should disable the port before the pipe. This doesn't seem to match reality based on the above and it's also asymmetric with the enabling sequence, where we first enable the port and then the pipe. v2: - send the panel shutdown command before stopping the pipe, since this is the recommended sequence (Shobhit) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Detect if MIPI panel based on VBT and initialize only if presentShobhit Kumar2014-06-054-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It seems by default the VBT has MIPI configuration block as well. The Generic driver will assume always MIPI if MIPI configuration block is found. This is causing probelm when actually there is eDP. Fix this by looking into general definition block which will have device configurations. From here we can figure out what is the LFP type and initialize MIPI only if MIPI is found. v2: Addressed review comments by Damien - Moved PORT definitions to intel_bios.h and renamed as DVO_PORT_MIPIA - renamed is_mipi to has_mipi and moved definition as suggested - Check has_mipi inside parse_mipi and intel_dsi_init insted of outside v3: Make has_mipi as a bitfield as suggested Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> [danvet: fold in conditions to pack everything neatly below 80 chars.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/vlv: Modifying WA 'WaDisableL3Bank2xClockGate for vlvAkash Goel2014-06-051-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For disabling L3 clock gating we need to set bit 25 of MMIO register 940c. Earlier this was being done by just writing 1 into bit 25 and resetting all other bits. This patch modifies the routine to read-modify-write of the register, so that the values of other bits are not destroyed. v2: Modifying the comments and the patch commit message (Chris) Signed-off-by: Akash Goel <akash.goel@intel.com> Signed-off-by: Sourab Gupta <sourab.gupta@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> [danvet: Apply checkpatch fixup.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Add support for Generic MIPI panel driverShobhit Kumar2014-06-054-0/+597
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This driver makes use of the generic panel information from the VBT. Panel information is classified into two - panel configuration and panel power sequence which is unique to each panel. The generic driver uses the panel configuration and sequence parsed from VBT block #52 and #53 v2: Address review comments by Jani - Move all of the things in driver c file from header - Make all functions static - Make use of video/mipi_display.c instead of redefining - Null checks during sequence execution v3: Address review comments by Damien - Rename the panel driver file as intel_dsi_panel_vbt.c - Fix style changes as suggested - Correct comments for lp->hs and hs->lp count calculations - General updating comments to have more clarity - using max() instead of ternary operator - Fix names (ui_num, ui_den) while using UI in calculations - compute max of lp_to_hs switch and hs_to_lp switch while computing hs_lp_switch_count Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Extract gen8_gt_irq_resetDaniel Vetter2014-06-051-8/+10
| | | | | | | | | | | | | | | | Fallout from an intermediate patch revision that I deemed worth saving. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Improve irq handling after gpu resetsDaniel Vetter2014-06-051-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently we do a full re-init of all interrupts after a gpu hang. Which is pretty bad since we don't restore the interrupts we've enabled at runtime correctly. Even with that addressed it's rather horribly race. But on g4x and later we only reset the gt and not the entire gpu. Which means we only need to reset the GT interrupt bits. Which has the nice benefit that vblank waits, pipe CRC interrupts and everything else display related just keeps on working. The downside is that gt interrupt handling (i.e. ring->get/put_irq) is still racy. But as long as the gpu hang reliably wakes all waters and we have a short time where the refcount drops to 0 we'll recover. So not that bad really. v2: Ville noticed that GTIMR and PMIMR don't get cleared, only the subordinate per-ring registers. So let's rip out all the interrupt dancing. The FIXME comment is still required though since the ring irq handling happens at the per-ring interrupt mask registers, too. Testcase: igt/kms_flip/vblank-vs-hang Testcase: igt/kms_pipe_crc_basic/hang-* Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Inline ilk/gen8_irq_resetDaniel Vetter2014-06-051-12/+2
| | | | | | | | | | | | | | No point in having this indirection. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Disable gpu reset on i965g/gmDaniel Vetter2014-06-051-0/+3
| | | | | | | | | | | | | | | | | | Ville figured out that it needs a full display reset since apparently a lot more goes down than just the GT. Until that's address it's better to just diable gpu reset. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Fix up fifo underrun tracking, take NDaniel Vetter2014-06-051-25/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So apparently this is tricky. We need to consider: - We start out with all the hw enabling bits disabled, both the individual fifo underrun interrupts and the shared display error interrupts masked. Otherwise if the bios config is broken we'll blow up with a NULL deref in our interrupt handler since the crtc structures aren't set up yet at driver load time. - On gmch we need to mask fifo underruns on the sw side, so always need to set that in sanitize_crtc for those platforms. - On other platforms we try to set the sw tracking so that it reflects the real state. But since a few platforms have shared bits we must _not_ disable fifo underrun reporting. Otherwise we'll never enable the shared error interrupt. This is the state before out patch, but unfortunately this is not good enough. But after a suspend resume operation this is broken: 1. We don't enable the hw interrupts since the same code runs on resume as on driver load. 2. The fifo underrun state adjustments we do in sanitize_crtc doesn't fire on resume since (except for hilarious firmware) all pipes are off at that point. But they also don't hurt since the subsequent crtc enabling due to force_restore will enable fifo underruns. Which means when we enable fifo underrun reporting we notice that the per-crtc state is already correct and short-circuit everthing out. And the interrupt doesn't get enabled. A similar problem would happen if the bios doesn't light up anything when the driver loads. Which is exactly what happens when we reload the driver since our unload functions disables all outputs. Now we can't just rip out the short-circuit logic and unconditionally update the fifo underrun reporting interrupt masking: We have some checks for shared error interrupts to catch issues that happened when the shared error interrupt was disabled. The right fix is to push down this logic so that we can always update the hardware state, but only check for missed fifo underruns on a real enabled->disabled transition and ignore them when we're already disabled. On platforms with shared error interrupt the pipe CRC interrupts are grouped together with the fifo underrun reporting this fixes pipe CRC support after suspend and driver reloads. Testcase: igt/kms_pipe_crc_basic/suspend-* Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Add fifo underrun reporting state to debugfsDaniel Vetter2014-06-051-0/+4
| | | | | | | | | | | | | | | | | | On platforms with shared interrupt enable bits (which are shared even with the pipe CRC logic) there's some tricky corner cases. Add information to make debugging those easier. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | Merge commit '9e9a928eed8796a0a1aaed7e0b676db86ba84594' into drm-nextDave Airlie2014-06-0514-339/+454
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | Merge drm-fixes into drm-next. Both i915 and radeon need this done for later patches. Conflicts: drivers/gpu/drm/drm_crtc_helper.c drivers/gpu/drm/i915/i915_drv.h drivers/gpu/drm/i915/i915_gem.c drivers/gpu/drm/i915/i915_gem_execbuffer.c drivers/gpu/drm/i915/i915_gem_gtt.c
| * drm/i915: Prevent negative relocation deltas from wrappingChris Wilson2014-05-275-38/+103
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is pure evil. Userspace, I'm looking at you SNA, repacks batch buffers on the fly after generation as they are being passed to the kernel for execution. These batches also contain self-referenced relocations as a single buffer encompasses the state commands, kernels, vertices and sampler. During generation the buffers are placed at known offsets within the full batch, and then the relocation deltas (as passed to the kernel) are tweaked as the batch is repacked into a smaller buffer. This means that userspace is passing negative relocations deltas, which subsequently wrap to large values if the batch is at a low address. The GPU hangs when it then tries to use the large value as a base for its address offsets, rather than wrapping back to the real value (as one would hope). As the GPU uses positive offsets from the base, we can treat the relocation address as the minimum address read by the GPU. For the upper bound, we trust that userspace will not read beyond the end of the buffer. So, how do we fix negative relocations from wrapping? We can either check that every relocation looks valid when we write it, and then position each object such that we prevent the offset wraparound, or we just special-case the self-referential behaviour of SNA and force all batches to be above 256k. Daniel prefers the latter approach. This fixes a GPU hang when it tries to use an address (relocation + offset) greater than the GTT size. The issue would occur quite easily with full-ppgtt as each fd gets its own VM space, so low offsets would often be handed out. However, with the rearrangement of the low GTT due to capturing the BIOS framebuffer, it is already affecting kernels 3.15 onwards. I think only IVB+ is susceptible to this bug, but the workaround should only kick in rarely, so it seems sensible to always apply it. v3: Use a bias for batch buffers to prevent small negative delta relocations from wrapping. v4 from Daniel: - s/BIAS/BATCH_OFFSET_BIAS/ - Extract eb_vma_misplaced/i915_vma_misplaced since the conditions were growing rather cumbersome. - Add a comment to eb_get_batch explaining why we do this. - Apply the batch offset bias everywhere but mention that we've only observed it on gen7 gpus. - Drop PIN_OFFSET_FIX for now, that slipped in from a feature patch. v5: Add static to eb_get_batch, spotted by 0-day tester. Testcase: igt/gem_bad_reloc Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78533 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v3) Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Only copy back the modified fields to userspace from execbufferChris Wilson2014-05-271-22/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We only want to modifiy a single field in the userspace view of the execbuffer command buffer, so explicitly change that rather than copy everything back again. This serves two purposes: 1. The single fields are much cheaper to copy (constant size so the copy uses special case code) and much smaller than the whole array. 2. We modify the array for internal use that need to be masked from the user. Note: We need this backported since without it the next bugfix will blow up when userspace recycles batchbuffers and relocations. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Fix dynamic allocation of physical handlesChris Wilson2014-05-275-231/+136
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A single object may be referenced by multiple registers fundamentally breaking the static allotment of ids in the current design. When the object is used the second time, the physical address of the first assignment is relinquished and a second one granted. However, the hardware is still reading (and possibly writing) to the old physical address now returned to the system. Eventually hilarity will ensue, but in the short term, it just means that cursors are broken when using more than one pipe. v2: Fix up leak of pci handle when handling an error during attachment, and avoid a double kmap/kunmap. (Ville) Rebase against -fixes. v3: And fix the error handling added in v2 (Ville) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77351 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: stable@vger.kernel.org Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Increase WM memory latency values on SNBVille Syrjälä2014-05-151-0/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On SNB the BIOS provided WM memory latency values seem insufficient to handle high resolution displays. In this particular case the display mode was a 2560x1440@60Hz, which makes the pixel clock 241.5 MHz. It was empirically found that a memory latency value if 1.2 usec is enough to avoid underruns, whereas the BIOS provided value of 0.7 usec was clearly too low. Incidentally 1.2 usec is what the typical BIOS provided values are on IVB systems. Increase the WM memory latency values to at least 1.2 usec on SNB. Hopefully this won't have a significant effect on power consumption. v2: Increase the latency values regardless of the pixel clock Cc: Robert N <crshman@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70254 Tested-by: Robert Navarro <crshman@gmail.com> Tested-by: Vitaly Minko <vitaly.minko@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: restore backlight precision when converting from ACPIAaron Lu2014-05-151-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we set backlight on behalf of ACPI opregion, we will convert the backlight value in the 0-255 range defined in opregion to the actual hardware level. Commit 22505b82a2 (drm/i915: avoid brightness overflow when doing scale) is meant to fix the overflow problem when doing the conversion, but it also caused a problem that the converted hardware level doesn't quite represent the intended value: say user wants maximum backlight level(255 in opregion's range), then we will calculate the actual hardware level to be: level = freq / max * level, where freq is the hardware's max backlight level(937 on an user's box), and max and level are all 255. The converted value should be 937 but the above calculation will yield 765. To fix this issue, just use 64 bits to do the calculation to keep the precision and avoid overflow at the same time. Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=72491 Reported-by: Nico Schottelius <nico-bugzilla.kernel.org@schottelius.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: Use the first mode if there is no preferred mode in the EDIDChris Wilson2014-05-151-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This matches the algorithm used by earlier kernels when selecting the mode for the fbcon. And only if there is no modes at all, do we fall back to using the BIOS configuration. Seamless transition is still preserved (from the BIOS configuration to ours) so long as the BIOS has also chosen what we hope is the native configuration. Reported-by: Knut Petersen <Knut_Petersen@t-online.de> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78655 Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Knut Petersen <Knut_Petersen@t-online.de> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> [Jani: applied Chris' "Please imagine that I wrote this correctly."] Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915/dp: force eDP lane count to max available lanes on BDWJani Nikula2014-05-151-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are certain BDW high res eDP machines that regressed due to commit 38aecea0ccbb909d635619cba22f1891e589b434 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Mar 3 11:18:10 2014 +0100 drm/i915: reverse dp link param selection, prefer fast over wide again The commit lead to 2 lanes at 5.4 Gbps being used instead of 4 lanes at 2.7 Gbps on the affected machines. Link training succeeded for both, but the screen remained blank with the former config. Further investigation showed that 4 lanes at 5.4 Gbps worked also. The root cause for the blank screen using 2 lanes remains unknown, but apparently the driver for a certain other operating system by default uses the max available lanes. Follow suit on Broadwell eDP, for at least until we figure out what is going on. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76711 Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Tested-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915/vlv: reset VLV media force wake request registerJani Nikula2014-05-091-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Media force wake get hangs the machine when the system is booted without displays attached. The assumption is that (at least some versions of) the firmware has skipped some initialization in that case. Empirical evidence suggests we need to reset the media force wake request register in addition to the render one to avoid hangs. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75895 Reported-by: Imre Deak <imre.deak@intel.com> Reported-by: Darren Hart <dvhart@linux.intel.com> Tested-by: Darren Hart <dvhart@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915/SDVO: For sysfs link put directory and target in correct orderEgbert Eich2014-05-071-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When linking the i2c sysfs file into the connector's directory pass directory and link target in the right order. This code was introduced with: commit 931c1c26983b4f84e33b78579fc8d57e4a14c6b4 Author: Imre Deak <imre.deak@intel.com> Date: Tue Feb 11 17:12:51 2014 +0200 drm/i915: sdvo: add i2c sysfs symlink to the connector's directory This is the same what we do for DP connectors, so make things more consistent. Signed-off-by: Egbert Eich <eich@suse.de> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: use lane count and link rate from VBT as minimums for eDPJani Nikula2014-05-071-7/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | Most likely the minimums for both should be enough for enabling the native resolution on the eDP, and we'll end up using the predetermined optimal link config for the panel. v2: Add debug prints. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73539 Tested-by: Markus Blank-Burian <burian@muenster.de> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: clean up VBT eDP link param decodingJani Nikula2014-05-071-14/+38
| | | | | | | | | | | | | | Use defines, do not set anything if VBT has values unknown to us. Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: consider the source max DP lane count tooPaulo Zanoni2014-05-071-2/+18
| | | | | | | | | | | | | | | | | | | | Even if the panel claims it can support 4 lanes, there's the possibility that the HW can't, so consider this while selecting the max lane count. Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: don't try DP_LINK_BW_5_4 on HSW ULXPaulo Zanoni2014-04-302-1/+5
| | | | | | | | | | | | | | | | Because the docs say ULX doesn't support it on HSW. Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: Sanitize the enable_ppgtt module option onceDaniel Vetter2014-04-291-7/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Otherwise we'll end up spamming dmesg on every context creation on snb with vt-d enabled. This regression was introduced in commit 246cbfb5fb9a1ca0997fbb135464c1ff5bb9c549 Author: Ben Widawsky <benjamin.widawsky@intel.com> Date: Fri Dec 6 14:11:14 2013 -0800 drm/i915: Reorganize intel_enable_ppgtt As the i915.enable_ppgtt is read-only it cannot be changed after the module is loaded and so we can perform an early sanitization of the values. v2: - Add comment and pimp commit message (Chris) - Use the param consistently (Jani) v3: - Fix init sequence on pre-gen6 by moving the sanitize_ppgtt call to gtt_init. Fixes boot hangs on pre-gen6. - Add a debug output for the sanitize ppgtt mode. References: https://lkml.org/lkml/2014/4/17/599 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77916 Cc: Alessandro Suardi <alessandro.suardi@gmail.com> Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: Break encoder->crtc link separately in intel_sanitize_crtc()Egbert Eich2014-04-251-12/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Depending on the SDVO output_flags SDVO may have multiple connectors linking to the same encoder (in intel_connector->encoder->base). Only one of those connectors should be active (ie link to the encoder thru drm_connector->encoder). If intel_connector_break_all_links() is called from intel_sanitize_crtc() we may break the crtc connection of an encoder thru an inactive connector in which case intel_connector_break_all_links() will not be called again for the active connector if this happens to come later in the list due to: if (connector->encoder->base.crtc != &crtc->base) continue; in intel_sanitize_crtc(). This will however leave the drm_connector->encoder linkage for this active connector in place. Subsequently this will cause multiple warnings in intel_connector_check_state() to trigger and the driver will eventually die in drm_encoder_crtc_ok() (because of crtc == NULL). To avoid this remove intel_connector_break_all_links() and move its code to its two calling functions: intel_sanitize_crtc() and intel_sanitize_encoder(). This allows to implement the link breaking more flexibly matching the surrounding code: ie. in intel_sanitize_crtc() we can break the crtc link separatly after the links to the encoders have been broken which avoids above problem. This regression has been introduced in: commit 24929352481f085c5f85d4d4cbc919ddf106d381 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Jul 2 20:28:59 2012 +0200 drm/i915: read out the modeset hw state at load and resume time so goes back to the very beginning of the modeset rework. v2: This patch takes care of the concernes voiced by Chris Wilson and Daniel Vetter that only breaking links if the drm_connector is linked to an encoder may miss some links. v3: move all encoder handling to encoder loop as suggested by Daniel Vetter. Signed-off-by: Egbert Eich <eich@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | drm: add drm_fb_helper_restore_fbdev_mode_unlocked()Rob Clark2014-06-051-5/+1
| | | | | | | | | | | | | | | | | | All drm_fb_helper_restore_fbdev_mode() call sites, save one, do the same locking. Simplify this into drm_fb_helper_restore_fbdev_mode_unlocked(). Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | drm: convert crtc and connection_mutex to ww_mutex (v5)Rob Clark2014-06-059-41/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For atomic, it will be quite necessary to not need to care so much about locking order. And 'state' gives us a convenient place to stash a ww_ctx for any sort of update that needs to grab multiple crtc locks. Because we will want to eventually make locking even more fine grained (giving locks to planes, connectors, etc), split out drm_modeset_lock and drm_modeset_acquire_ctx to track acquired locks. Atomic will use this to keep track of which locks have been acquired in a transaction. v1: original v2: remove a few things not needed until atomic, for now v3: update for v3 of connection_mutex patch.. v4: squash in docbook v5: doc tweaks/fixes Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-23 06:07:00 +0100