aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915
Commit message (Collapse)AuthorAge
* drm/i915: fixup interlaced bits clearing in PIPECONF on PCH_SPLIT (v2)Keith Packard2012-02-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | An identical patch has been merged for i9xx_crtc_mode_set: Commit 59df7b1771c150163e522f33c638096ab0efbf42 Author: Christian Schmidt <schmidt@digadd.de> Date: Mon Dec 19 20:03:33 2011 +0100 drm/intel: Fix initialization if startup happens in interlaced mode [v2] But that one neglected to fix up the ironlake+ path. This should fix the issue reported by Alfonso Fiore where booting with only a HDMI cable connected to his TV failed to display anything. The issue is that the bios set up things for 1080i and used the pannel fitter to scale up the lower progressive resolutions. We failed to clear the interlace bit in the PIPEACONF register, resulting in havoc. v2: Be more paranoid and just unconditionally clear the field before setting new values. Cc: Peter Ross <pross@xvid.org> Cc: Alfonso Fiore <alfonso.fiore@gmail.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: no lvds quirk for AOpen MP45Daniel Vetter2012-02-08
| | | | | | | | | | | According to a bug report, it doesn't have one. Cc: stable@kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44263 Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: Force explicit bpp selection for intel_dp_link_requiredKeith Packard2012-02-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is never correct to use intel_crtc->bpp in intel_dp_link_required, so instead pass an explicit bpp in to this function. This patch only supports 18bpp and 24bpp modes, which means that 10bpc modes will be computed incorrectly. Fixing that will require more extensive changes, and so must be addressed separately from this bugfix. intel_dp_link_required is called from intel_dp_mode_valid and intel_dp_mode_fixup. * intel_dp_mode_valid is called to list supported modes; in this case, the current crtc values cannot be relevant as the modes in question may never be selected. Thus, using intel_crtc->bpp is never right. * intel_dp_mode_fixup is called during mode setting, but it is run well before ironlake_crtc_mode_set is called to set intel_crtc->bpp, so using intel_crtc-bpp in this path can only ever get a stale value. Cc: Lubos Kolouch <lubos.kolouch@gmail.com> Cc: Adam Jackson <ajax@redhat.com> Cc: stable@vger.kernel.org Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42263 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44881 Tested-by: Dave Airlie <airlied@redhat.com> Tested-by: camalot@picnicpark.org (Dell Latitude 6510) Tested-by: Roland Dreier <roland@digitalvampire.org> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: fixup interlaced bits clearing in PIPECONF on PCH_SPLITDaniel Vetter2012-01-28
| | | | | | | | | | | | | | | | | | | | | | | | An identical patch has been merged for i9xx_crtc_mode_set: Commit 59df7b1771c150163e522f33c638096ab0efbf42 Author: Christian Schmidt <schmidt@digadd.de> Date: Mon Dec 19 20:03:33 2011 +0100 drm/intel: Fix initialization if startup happens in interlaced mode [v2] But that one neglected to fix up the ironlake+ path. This should fix the issue reported by Alfonso Fiore where booting with only a HDMI cable connected to his TV failed to display anything. The issue is that the bios set up things for 1080i and used the pannel fitter to scale up the lower progressive resolutions. We failed to clear the interlace bit in the PIPEACONF register, resulting in havoc. Cc: Peter Ross <pross@xvid.org> Tested-by: Alfonso Fiore <alfonso.fiore@gmail.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915:: Disable FBC on SandyBridgeChris Wilson2012-01-28
| | | | | | | | | Enabling FBC is causing the BLT ring to run between 10-100x slower than normal and frequently lockup. The interim solution is disable FBC once more until we know why. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: fixup forcewake spinlock fallout in drpc debugfs functionDaniel Vetter2012-01-25
| | | | | | | | | | | | | | My forcewake spinlock patches have a functional conflict with Ben Widawsky's gen6 drpc support for debugfs. Result was a benign warning about trying to read an non-atomic variabla with atomic_read. Note that the entire check is racy anyway and purely informational. Also update it to reflect the forcewake voodoo changes, the kernel can now also hold onto a forcewake reference for longer times. Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: debugfs: show semaphore registers also on gen7Daniel Vetter2012-01-24
| | | | | | | | | | Corresponding changes to improve our error_state are pending some other patches to clean up things first. Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: allow userspace forcewake references also on gen7Daniel Vetter2012-01-24
| | | | | | | | | | We need this to correctly access registers in the gt power well from userspace. Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: Re-enable gen7 RC6 and GPU turbo after resume.Eric Anholt2012-01-24
| | | | | | | | | Signed-off-by: Eric Anholt <eric@anholt.net> Cc: stable@vger.kernel.org Reviewed-by: Keith Packard <keithp@keithp.com> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: Correct debugfs printout for RC1e.Eric Anholt2012-01-24
| | | | | | | | | | | We had two things in a row claiming to be RC6. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Keith Packard <keithp@keithp.com>
* Revert "drm/i915: Work around gen7 BLT ring synchronization issues."Keith Packard2012-01-20
| | | | | | | | | This reverts commit 42ff6572e5a4a7414330a4ca91f0335da67deca9. New forcewake voodoo makes this no longer necessary. Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: rip out the HWSTAM missed irq workaroundDaniel Vetter2012-01-19
| | | | | | | | | | | | | With the new ducttape of much finer quality, this seems to be no longer necessary. Tested on my ivb and snb machine with the usual suspects of testcases. (v2 by keithp -- limited change to IVB only for now) Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: paper over missed irq issues with force wake voodooDaniel Vetter2012-01-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Two things seem to do the trick on my ivb machine here: - prevent the gt from powering down while waiting for seqno notification interrupts by grabbing the force_wake in get_irq (and dropping it in put_irq again). - ordering writes from the ring's CS by reading a CS register, ACTHD seems to work. Only the blt&bsd ring on ivb seem to be massively affected by this, but for paranoia do this dance also on the render ring and on snb (i.e. all gpus with forcewake). Tested with Eric's glCopyPixels loop which without this patch scores a missed irq every few seconds. This patch needs my forcewake rework to use a spinlock instead of dev->struct_mutex. After crawling through docs a lot I've found the following nugget: Internal doc "SNB GT PM Programming Guide", Section 4.3.1: "GT does not generate interrupts while in RC6 (by design)" So it looks like rc6 and irq generation are indeed related. v2: Improve the comment per Eugeni Dodonov's suggestion. v3: Add the documentation snipped. Also restrict the w/a to ivb only for -fixes, as suggested by Keith Packard. Cc: stable@kernel.org Cc: Eric Anholt <eric@anholt.net> Cc: Kenneth Graunke <kenneth@whitecape.org> Cc: Eugeni Dodonov <eugeni.dodonov@intel.com> Tested-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: Hold gt_lock across forcewake register readsKeith Packard2012-01-19
| | | | | | | | | | | Along with the previous patch to make the reset operation protected by the gt_lock as well, this ensures that all register read operations will occur with the forcewake hardware enabled. As an added bonus, this makes read operations more efficient by taking the spinlock only once per read instead of twice. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Hold gt_lock during resetKeith Packard2012-01-19
| | | | | | | | This ensures that no register reads occur while the forcewake state of the hardware is indeterminate during the reset operation. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Move reset forcewake processing to gen6_do_resetKeith Packard2012-01-19
| | | | | | | No reason to have half of the reset split from the other half. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: protect force_wake_(get|put) with the gt_lockDaniel Vetter2012-01-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The problem this patch solves is that the forcewake accounting necessary for register reads is protected by dev->struct_mutex. But the hangcheck and error_capture code need to access registers without grabbing this mutex because we hold it while waiting for the gpu. So a new lock is required. Because currently the error_state capture is called from the error irq handler and the hangcheck code runs from a timer, it needs to be an irqsafe spinlock (note that the registers used by the irq handler (neglecting the error handling part) only uses registers that don't need the forcewake dance). We could tune this down to a normal spinlock when we rework the error_state capture and hangcheck code to run from a workqueue. But we don't have any read in a fastpath that needs forcewake, so I've decided to not care much about overhead. This prevents tests/gem_hangcheck_forcewake from i-g-t from killing my snb on recent kernels - something must have slightly changed the timings. On previous kernels it only trigger a WARN about the broken locking. v2: Drop the previous patch for the register writes. v3: Improve the commit message per Chris Wilson's suggestions. Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: convert force_wake_get to func pointer in the gpu reset codeDaniel Vetter2012-01-13
| | | | | | | | | | | | | | | This was forgotten in the original multi-threaded forcewake conversion: commit 8d715f0024f64ad1b1be85d8c081cf577944c847 Author: Keith Packard <keithp at keithp.com> Date: Fri Nov 18 20:39:01 2011 -0800 drm/i915: add multi-threaded forcewake support Signed-Off-by: Daniel Vetter <daniel.vetter at ffwll.ch> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: sprite init failure on pre-SNB is not a failureJesse Barnes2012-01-13
| | | | | | | | | | | | | | We can call the plane init function unconditionally, but don't need to complain if it fails, since that will only happen if we're out of memory (and other things will fail) or if we're on the wrong platform (which is ok). And remove the DRM_ERRORs from the sprite code itself to avoid dmesg spam. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: VBT Parser cleanup for eDP blockRohit Jain2012-01-13
| | | | | | | | | | | | | Support for parsing parameters for S3D support and T3 optimization support is implemented. The order for the bdb_edp struct was also made similar to that indicated in spec. Signed-off-by: Rohit Jain <rohit.jain@intel.com> Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com> Reviewed-by: Vijay A. Purushothaman <vijay.a.purushothaman@intel.com> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Acked-by: Jesse Barnes <jesse.barnes@intel.com> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: mask transcoder select bits before setting them on LVDSJesse Barnes2012-01-13
| | | | | | | | | | | The transcoder port may changed from mode set to mode set, so make sure to mask out the selection bits before setting the right ones or we'll get black screens when going from transcoder B to A. Tested-by: Vincent Vanackere <vincent.vanackere@gmail.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
* Merge branch 'drm-intel-next-fixes' into drm-intel-fixesKeith Packard2012-01-12
|\
| * drm/i915: Add Clientron E830 to the ignore LVDS listJoel Sass2012-01-12
| | | | | | | | | | | | Signed-off-by: Joel Sass <jsass@disklessworkstations.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Keith Packard <keithp@keithp.com>
| * CHROMIUM: i915: Add DMI override to skip CRT initialization on ZGBDuncan Laurie2012-01-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the method used to override LVDS in intel_lvds and appears to be an effective way to ensure that the driver does not enable VGA hotplug. This is the same patch from 2.6.32 kernel in R12 but ported to 2.6.38, will send upstream next. Signed-off-by: Duncan Laurie <dlaurie@chromium.org> BUG=chrome-os-partner:117 TEST=Check PORT_HOTPLUG_EN to see if hotplug interrupt is disabled. Run the following command as root, specifically looking at bit 9: mmio_read32 $[$(pci_read32 0 2 0 0x10) + 0x61110] = 0x00000000 Change-Id: Id8240f9fb31d058d8d79ee72f7b4615c43893f5a Reviewed-on: http://gerrit.chromium.org/gerrit/1390 Reviewed-by: Olof Johansson <olofj@chromium.org> Tested-by: Duncan Laurie <dlaurie@chromium.org> Signed-off-by: Keith Packard <keithp@keithp.com>
| * drm/i915: handle 3rd pipeEugeni Dodonov2012-01-09
| | | | | | | | | | | | | | | | | | We don't need to check 3rd pipe specifically, as it shares PLL with some other one. Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com>
| * drm/i915: simplify pipe checkingEugeni Dodonov2012-01-09
| | | | | | | | | | | | | | | | | | | | This is also handled by i915_reg.h, so just reuse this trick to reduce universe entropy. Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Cyril Brulebois <kibi@debian.org> Signed-off-by: Keith Packard <keithp@keithp.com>
| * drm/i915: Print debugfs object list sizes in KiB instead of bytes.Eric Anholt2012-01-09
| | | | | | | | | | | | | | | | They're all in increments of pages, so this just makes it easier on the eyes. Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Keith Packard <keithp@keithp.com>
| * drm/i915/sdvo: always set positive sync polarityPaulo Zanoni2012-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a revert of 81a14b46846fea0741902e8d8dfcc6c6c78154c8. We already set the mode polarity using the SDVO commands with struct intel_sdvo_dtd. We have at least 3 bugs that get fixed with this patch. The documentation, despite not clear, can also be interpreted in a way that suggests this patch is needed. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=15766 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42174 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43333 Cc: stable@kernel.org Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Keith Packard <keithp@keithp.com>
| * drm/i915: Removing TV Out modes.Rodrigo Vivi2012-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | These modes are no longer needed or are not according to TV timing standards. Intel PRM Vol 3 - Display Registers Updated - Section 5 TV-Out Programming / 5.2.1 Television Standards / 5.2.1.1 Timing tables Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com>
| * drm/i915: Fix TV Out refresh rate.Rodrigo Vivi2012-01-06
| | | | | | | | | | | | | | | | | | TV Out refresh rate was half of the specification for almost all modes. Due to this reason pixel clock was so low for some modes causing flickering screen. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com>
* | Merge branch 'drm-core-next' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds2012-01-10
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 'drm-core-next' of git://people.freedesktop.org/~airlied/linux: (307 commits) drm/nouveau/pm: fix build with HWMON off gma500: silence gcc warnings in mid_get_vbt_data() drm/ttm: fix condition (and vs or) drm/radeon: double lock typo in radeon_vm_bo_rmv() drm/radeon: use after free in radeon_vm_bo_add() drm/sis|via: don't return stack garbage from free_mem ioctl drm/radeon/kms: remove pointless CS flags priority struct drm/radeon/kms: check if vm is supported in VA ioctl drm: introduce drm_can_sleep and use in intel/radeon drivers. (v2) radeon: Fix disabling PCI bus mastering on big endian hosts. ttm: fix agp since ttm tt rework agp: Fix multi-line warning message whitespace drm/ttm/dma: Fix accounting error when calling ttm_mem_global_free_page and don't try to free freed pages. drm/ttm/dma: Only call set_pages_array_wb when the page is not in WB pool. drm/radeon/kms: sync across multiple rings when doing bo moves v3 drm/radeon/kms: Add support for multi-ring sync in CS ioctl (v2) drm/radeon: GPU virtual memory support v22 drm: make DRM_UNLOCKED ioctls with their own mutex drm: no need to hold global mutex for static data drm/radeon/benchmark: common modes sweep ignores 640x480@32 ... Fix up trivial conflicts in radeon/evergreen.c and vmwgfx/vmwgfx_kms.c
| * drm: introduce drm_can_sleep and use in intel/radeon drivers. (v2)Dave Airlie2012-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So we have a few places where the drm drivers would like to sleep to be nice to the system, mainly in the modesetting paths, but we also have two cases were atomic modesetting must take place, panic writing and kernel debugger. So provide a central inline to determine if a sleep or delay should be used and use this in the intel and radeon drivers. v2: drop intel_drv.h MSLEEP macro, nobody uses it. Based on patch from Michel Dänzer <michel.daenzer@amd.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43941 Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * drm: add support for private planesRob Clark2012-01-05
| | | | | | | | | | | | | | | | | | | | | | In cases where the scanout hw is sufficiently similar between "overlay" and traditional crtc layers, it might be convenient to allow the driver to create internal drm_plane helper objects used by the drm_crtc implementation, rather than duplicate code between the plane and crtc. A private plane is not exposed to userspace. Signed-off-by: Rob Clark <rob@ti.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * drm/i915: only set the intel_crtc DPMS mode to on if the mode set succeededJesse Barnes2012-01-03
| | | | | | | | | | | | | | If it failed, leave it in the "off" state. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com>
| * drm/i915: don't disable a PCH DPLL that's in useJesse Barnes2012-01-03
| | | | | | | | | | | | | | If a PCH pipe PLL is being used by transcoder C, don't disable it. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com>
| * drm/i915: don't bail out of intel_wait_ring_buffer too earlyDaniel Vetter2012-01-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the pre-gem days with non-existing hangcheck and gpu reset code, this timeout of 3 seconds was pretty important to avoid stuck processes. But now we have the hangcheck code in gem that goes to great length to ensure that the gpu is really dead before declaring it wedged. So there's no need for this timeout anymore. Actually it's even harmful because we can bail out too early (e.g. with xscreensaver slip) when running giant batchbuffers. And our code isn't robust enough to properly unroll any state-changes, we pretty much rely on the gpu reset code cleaning up the mess (like cache tracking, fencing state, active list/request tracking, ...). With this change intel_begin_ring can only fail when the gpu is wedged, and it will return -EAGAIN (like wait_request in case the gpu reset is still outstanding). v2: Chris Wilson noted that on resume timers aren't running and hence we won't ever get kicked out of this loop by the hangcheck code. Use an insanely large timeout instead for the HAS_GEM case to prevent resume bugs from totally hanging the machine. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Keith Packard <keithp@keithp.com>
| * drm/i915: kicking rings stuck on semaphores considered harmfulDaniel Vetter2012-01-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If our semaphore logic gets confused and we have a ring stuck waiting for one, there's a decent chance it'll just execute garbage when being kicked. Also, kicking the ring obscures the place where the error first occured, making error_state decoding much harder. So drop this an let gpu reset handle this mess in a clean fashion. In contrast, kicking rings stuck on MI_WAIT is rather harmless, at worst there'll be a bit of screen-flickering. There's also old broken userspace out there which needs this as a work-around. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Chris Wilson <chris@hchris-wilson.co.uk> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Keith Packard <keithp@keithp.com>
| * drm/i915: Add support for resetting the SO write pointers on gen7.Eric Anholt2012-01-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These registers are automatically incremented by the hardware during transform feedback to track where the next streamed vertex output should go. Unlike the previous generation, which had a packet for setting the corresponding registers to a defined value, gen7 only has MI_LOAD_REGISTER_IMM to do so. That's a secure packet (since it loads an arbitrary register), so we need to do it from the kernel, and it needs to be settable atomically with the batchbuffer execution so that two clients doing transform feedback don't stomp on each others' state. Instead of building a more complicated interface involcing setting the registers to a specific value, just set them to 0 when asked and userland can tweak its pointers accordingly. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Keith Packard <keithp@keithp.com>
| * drm/i915: Make the fallback IRQ wait not sleep.Eric Anholt2012-01-03
| | | | | | | | | | | | | | | | | | | | | | | | | | The waits we do here are generally so short that sleeping is a bad idea unless we have an IRQ to wake us up. Improves regression test performance from 18 minutes to 3.5 minutes on gen7, which is now consistent with the previous generation. Signed-off-by: Eric Anholt <eric@anholt.net> Tested-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Acked-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Keith Packard <keithp@keithp.com>
| * drm/i915: Work around gen7 BLT ring synchronization issues.Eric Anholt2012-01-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previous to this commit, testing easily reproduced a failure where the seqno would apparently arrive after the IRQ associated with it, with test programs as simple as: for (;;) { glCopyPixels(0, 0, 1, 1); glFinish(); } Various workarounds we've seen for previous generations didn't work to fix this issue, so until new information comes in, replace the IRQ waits on the BLT ring with polling. Signed-off-by: Eric Anholt <eric@anholt.net> Tested-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Acked-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Keith Packard <keithp@keithp.com>
| * drm/i915: Do the fallback non-IRQ wait in ring throttle, too.Eric Anholt2012-01-03
| | | | | | | | | | | | | | | | | | | | | | As a workaround for IRQ synchronization issues in the gen7 BLT ring, we want to turn the two wait functions into polling loops. Signed-off-by: Eric Anholt <eric@anholt.net> Tested-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Acked-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Keith Packard <keithp@keithp.com>
| * drm/i915: Set two chicken bits implicated in missed IRQs on Ivybridge.Eric Anholt2012-01-03
| | | | | | | | | | | | | | They don't fix our problems alone, but we're told to set them. Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Keith Packard <keithp@keithp.com>
| * drm/i915: add color key support v4Jesse Barnes2012-01-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add new ioctls for getting and setting the current destination color key. This allows for simple overlay display control by matching a color key value in the primary plane before blending the overlay on top. v2: remove unnecessary mutex acquire/release around reg accesses v3: add support for full color key management v4: fix copy & paste bug in snb_get_colorkey don't bother checking min/max values against docs as the docs are likely wrong (how could we handle 10bpc surface formats?) Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * drm/i915: track sprite coverage and disable primary plane if possibleJesse Barnes2012-01-03
| | | | | | | | | | | | | | | | | | | | | | | | To save power when the sprite is full screen, we can disable the primary plane on the same pipe. Track the sprite status and enable/disable the primary opportunistically. v2: remove primary plane enable/disable hooks; they're identical Reviewed-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com>
| * drm/i915: add SNB and IVB video sprite support v6Jesse Barnes2012-01-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The video sprites support various video surface formats natively and can handle scaling as well. So add support for them using the new DRM core sprite support functions. v2: use drm specific fourcc header and defines v3: address Daniel's comments: - don't take struct mutex around register access (only needed for regs in the GT power well) - don't hold struct mutex across vblank waits - fix up update_plane API (pass obj instead of GTT offset) - add interlaced defines for sprite regs - drop unnecessary 'reg' variables - comment double buffered reg flushing Also fix w/h confusion when writing the scaling reg. v4: more fixes, address more comments from Daniel, and include Hai's fix - prevent divide by zero in scaling calculation (Hai Lan) - update to Ville's new DRM_FORMAT_* types - fix sprite watermark handling (calc based on CRTC size, separate from normal display wm) - remove private refcounts now that the fb cleanups handles things v5: add linear surface support v6: remove color key clearing & setting from update_plane For this version, I tested DPMS since it came up in the last review; DPMS off/on works ok when a video player is working under X, but for power saving we'll probably want to do something smarter. I'll leave that for a separate patch on top. Likewise with the refcounting/fb layer handling, which are really separate cleanups. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com>
| * drm/i915: Clean up multi-threaded forcewake patchKeith Packard2012-01-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We learned that the ECOBUS register was inside the GT power well, and so *did* need force wake to be read, so it gets removed from the list of 'doesn't need force wake' registers. That means the code reading ECOBUS after forcing the mt_force_wake function to be called needs to use I915_READ_NOTRACE; it doesn't need to do more force wake fun as it's already done it manually. This also adds a comment explaining why the MT forcewake testing code only needs to call mt_forcewake_get/put and not disable RC6 manually -- the ECOBUS read will return 0 if the device is in RC6 and isn't using MT forcewake, causing the test to work correctly. Signed-off-by: Keith Packard <keithp@keithp.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
| * drm/i915: drpc debugfs update for gen6Ben Widawsky2012-01-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Many of the old fields from Ironlake have gone away. Strip all those fields, and try to update to fields people care about. RC information isn't exactly ideal anymore. All we can guarantee when we read the register is that we're not using forcewake, ie. the software isn't forcing the hardware to stay awake. The downside is that in doing this we may wait a while and that causes an unnaturally idle state on the GPU. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42578 Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com>
| * drm/i915: Update GEN6_RP_CONTROL definitionsBen Widawsky2012-01-03
| | | | | | | | | | | | | | | | | | | | | | | | This matches the modern specs more accurately. This will be used by the following patch to fix the way we display RC status. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Keith Packard <keithp@keithp.com>
| * drm/i915: Force sync command ordering (Gen6+)Ben Widawsky2012-01-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The docs say this is required for Gen7, and since the bit was added for Gen6, we are also setting it there pit pf paranoia. Particularly as Chris points out, if PIPE_CONTROL counts as a 3d state packet. This was found through doc inspection by Ken and applies to Gen6+; Reported-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Keith Packard <keithp@keithp.com>
| * drm/i915: relative_constants_mode race fixBen Widawsky2012-01-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | dev_priv keeps track of the current addressing mode that gets set at execbuffer time. Unfortunately the existing code was doing this before acquiring struct_mutex which leaves a race with another thread also doing an execbuffer. If that wasn't bad enough, relocate_slow drops struct_mutex which opens a much more likely error where another thread comes in and modifies the state while relocate_slow is being slow. The solution here is to just defer setting this state until we absolutely need it, and we know we'll have struct_mutex for the remainder of our code path. v2: Keith noticed a bug in the original patch. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Keith Packard <keithp@keithp.com>
generated by cgit v1.2.2 (git 2.25.0) at 2025-08-05 07:11:14 -0400