- 06 Jun, 2014 1 commit
-
-
git://anongit.freedesktop.org/drm-intelDave Airlie authored
> 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 ...
-
- 05 Jun, 2014 35 commits
-
-
Daniel Vetter authored
I've fumbled my own idea and enthusiastically wrapped all the getconnector code with the connection_mutex. But we only need it to chase the connector->encoder link. Even there it's not really needed since races with userspace won't matter, but better paranoid and consistent about this stuff. If we grap it everywhere connector probe callbacks can't grab it themselves, which means they'll deadlock. i915 does that for the load detect pipe. Furthermore i915 needs to do a ww dance since we also need to grab the mutex of the load detect crtc. This is a regression from commit 6e9f798d Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu May 29 23:54:47 2014 +0200 drm: Split connection_mutex out of mode_config.mutex (v3) Cc: Rob Clark <robdclark@gmail.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reported-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Rob Clark <robdclark@gmail.com> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
Rodrigo Vivi authored
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=79621Signed-off-by:
-
Daniel Vetter authored
I've fumbled my own idea and enthusiastically wrapped all the getconnector code with the connection_mutex. But we only need it to chase the connector->encoder link. Even there it's not really needed since races with userspace won't matter, but better paranoid and consistent about this stuff. If we grap it everywhere connector probe callbacks can't grab it themselves, which means they'll deadlock. i915 does that for the load detect pipe. Furthermore i915 needs to do a ww dance since we also need to grab the mutex of the load detect crtc. This is a regression from commit 6e9f798d Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu May 29 23:54:47 2014 +0200 drm: Split connection_mutex out of mode_config.mutex (v3) Cc: Rob Clark <robdclark@gmail.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reported-by:
-
Dave Airlie authored
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
-
Ben Widawsky authored
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 7907f45b 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:
"Yang, Guang A" <guang.a.yang@intel.com> Signed-off-by:
-
Daniel Vetter authored
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.deSigned-off-by:
-
Imre Deak authored
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=79038Reported-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:
-
Chris Wilson authored
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:
Antti Koskipaa <antti.koskipaa@linux.intel.com> Tested-by:
-
Jani Nikula authored
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 e147accb 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 b30324ad 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:
-
Matt Roper authored
Pull the parameter checking from drm_primary_helper_update() out into its own function; drivers that provide their own setplane() implementations rather than using the helper may still want to share this parameter checking logic. A few of the checks here were also updated based on suggestions by Ville Syrjälä. v3: - s/primary_helper/plane_helper/ --- this checking logic may be useful for other types of planes as well. - Fix visibility check (need to dereference visibility pointer) v2: - Pass src/dest/clip rects and min/max scaling down to helper to avoid duplication of effort between helper and drivers (suggested by Ville). - Allow caller to specify whether the primary plane should be updatable while the crtc is disabled. Cc: dri-devel@lists.freedesktop.org Reviewed-by:
Chon Ming Lee <chon.ming.lee@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Acked-by:
Dave Airlie <airlied@gmail.com> [danvet: Include header properly and fixup declaration mismatch to make this compile.] Signed-off-by:
-
Matt Roper authored
The DRM core setplane code should check that the plane is usable on the specified CRTC before calling into the driver. Prior to this patch, a plane's possible_crtcs field was purely informational for userspace and was never actually verified at the kernel level (aside from the primary plane helper). Cc: dri-devel@lists.freedesktop.org Reviewed-by:
-
Jesse Barnes authored
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:
-
Ville Syrjälä authored
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:
-
Chris Wilson authored
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:
-
Ville Syrjälä authored
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ä authored
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ä authored
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ä authored
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:
-
Jesse Barnes authored
When doing this, all PLLs should be disabled. Signed-off-by:
-
Jesse Barnes authored
We need to do this anytime we power gate the DPIO common well. Signed-off-by:
-
Jesse Barnes authored
There may be a dependency here. Signed-off-by:
-
Jesse Barnes authored
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 authored
We do this at runtime and later on now. Signed-off-by:
-
Jesse Barnes authored
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: -
Imre Deak authored
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:
Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by:
-
Shobhit Kumar authored
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: -
Akash Goel authored
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:
-
Shobhit Kumar authored
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: -
Daniel Vetter authored
Fallout from an intermediate patch revision that I deemed worth saving. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
No point in having this indirection. Reviewed-by:
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
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:
-
Rob Clark authored
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:
-
- 04 Jun, 2014 4 commits
-
-
Rob Clark authored
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:
-
Dave Airlie authored
This should avoid races between connector probing and HPD irqs in the future, currently mode_config.mutex blocks this possibility. Reviewed-by:
-
git://people.freedesktop.org/~airlied/linuxLinus Torvalds authored
Pull drm fixes from Dave Airlie: "All fairly small: radeon stability and a panic path fix. Mostly radeon fixes, suspend/resume fix, stability on the CIK chipsets, along with a locking check avoidance patch for panic times regression" * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: drm/radeon: use the CP DMA on CIK drm/radeon: sync page table updates drm/radeon: fix vm buffer size estimation drm/crtc-helper: skip locking checks in panicking path drm/radeon/dpm: resume fixes for some systems
-
git://anongit.freedesktop.org/drm-intelDave Airlie authored
Just flushing out my pile of random drm patches for the merge window, nothing big. And it all hung around in drm-intel trees for a while (only just rebased now). * tag 'topic/core-stuff-2014-06-02' of git://anongit.freedesktop.org/drm-intel: imx-drm: imx-tve: remove unused variable drm: Missed clflushopt in drm_clflush_virt_range drm/plane: Fix a couple of checkpatch warnings drm/plane: Fix sparse warnings drm/exynos: Fix double locks at PM resume drm/ast: Fix double lock at PM resume drm/dp-helper: Deprecate old i2c-over-dp_aux heleprs
-
