| Age | Commit message (Collapse) | Author |
|---|
|
On a Thinkpad x61s, I noticed some memory corruption when
plugging/unplugging the external VGA connection. The symptoms are that
4 bytes at the beginning of a page get overwritten by zeroes.
The address of the corruption varies when rebooting the machine, but
stays constant while it's running (so it's possible to repeatedly write
some data and then corrupt it again by plugging the cable).
Further investigation revealed that the corrupted address is
(dev_priv->status_page_dmah->busaddr & 0xffffffff), ie. the beginning of
the hardware status page of the i965 graphics card, cut to 32 bits.
So it seems that for some memory access, the hardware uses only 32 bit
addressing. If the hardware status page is located >4GB, this
corrupts unrelated memory.
Signed-off-by: Jan Niehusmann <jan@gondor.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
|
|
Starting with SandyBridge (though possible with earlier hacked BIOSes),
the BIOS may initialise the IGFX as secondary to a discrete GPU. Prior,
it would simply disable the integrated GPU. So we adjust our PCI class
mask to match any DISPLAY_CLASS device.
In such a configuration, the IGFX is not a primary VGA controller and
so should not take part in VGA arbitration, and the error return from
vga_client_register() is expected.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
|
|
We weren't setting up the vfunc table when initialising the old DRI
ringbuffer, leading to such OOPSes as:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<(null)>] (null)
PGD 10c441067 PUD 1185e5067 PMD 0
Oops: 0010 [#1] PREEMPT SMP
last sysfs file: /sys/class/dmi/id/chassis_asset_tag
CPU 3
Modules linked in: i915 drm_kms_helper drm fb fbdev i2c_algo_bit
cfbcopyarea video backlight output cfbimgblt cfbfillrect autofs4 ipv6
nfs lockd fscache nfs_acl auth_rpcgss sunrpc coretemp hwmon_vid mousedev
usbhid hid option usb_wwan snd_hda_codec_via asus_atk0110 atl1e
usbserial snd_hda_intel snd_hda_codec firmware_class snd_hwdep snd_pcm
snd_seq snd_timer snd_seq_device processor parport_pc thermal snd
thermal_sys parport 8250_pnp button rng_core rtc_cmos shpchp hwmon
rtc_core ehci_hcd pci_hotplug uhci_hcd soundcore tpm_tis i2c_i801
rtc_lib tpm serio_raw snd_page_alloc tpm_bios i2c_core usbcore psmouse
intel_agp sg pcspkr sr_mod evdev cdrom ext3 jbd mbcache dm_mod sd_mod
ata_piix libata scsi_mod unix
Jan 18 15:49:29 lithui kernel:
Pid: 3605, comm: Xorg Not tainted 2.6.36.2 #5 P5KPL-CM/System Product
Name
RIP: 0010:[<0000000000000000>] [<(null)>] (null)
RSP: 0018:ffff8801150d1d40 EFLAGS: 00010202
RAX: 000000000001ffff RBX: ffff88011a011b00 RCX: 000000000001a704
RDX: ffff880118566028 RSI: ffff880118566028 RDI: ffff880117876800
RBP: ffff8801150d1d48 R08: ffff8801195fe300 R09: 00000000c0086444
R10: 0000000000000001 R11: 0000000000003206 R12: ffff880117876800
R13: ffff880118566000 R14: ffff880117876820 R15: ffff8801150d1df8
FS: 00007f1038d456e0(0000) GS:ffff880001780000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 00000001187e7000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process Xorg (pid: 3605, threadinfo ffff8801150d0000, task
ffff88011b016e40)
Stack:
ffffffffa043b8e6 ffff8801150d1d98 ffffffffa041768b dead000000000000
<0> 0000000000000048 00007f1023f2a000 0000000000000044 0000000000000008
<0> ffff88010d26bd80 ffff880117876800 ffff8801150d1df8 ffff8801150d1ea8
Call Trace:
[<ffffffffa043b8e6>] ? intel_ring_advance+0x16/0x20 [i915]
[<ffffffffa041768b>] i915_irq_emit+0x15b/0x240 [i915]
[<ffffffffa03ea7b1>] drm_ioctl+0x1f1/0x460 [drm]
[<ffffffffa0417530>] ? i915_irq_emit+0x0/0x240 [i915]
[<ffffffff810dd8f1>] ? do_sync_read+0xd1/0x120
[<ffffffff81025b1f>] ? do_page_fault+0x1df/0x3d0
[<ffffffff810ed5c7>] do_vfs_ioctl+0x97/0x550
[<ffffffff8115c2ea>] ? security_file_permission+0x7a/0x90
[<ffffffff810edb19>] sys_ioctl+0x99/0xa0
[<ffffffff810024ab>] system_call_fastpath+0x16/0x1b
Code: Bad RIP value.
RIP [<(null)>] (null)
RSP <ffff8801150d1d40>
CR2: 0000000000000000
Reported-by: Herbert Xu <herbert@gondor.apana.org.au>
Tested-by: Herbert Xu <herbert@gondor.apana.org.au>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29153
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=23172
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
|
|
As has_gem is unconditionally set to true, the conditional immediately
following that assignment is superfluous.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
We need to track the state of the switch in drivers, so that after s/r
we don't resume the card we've explicitly switched off before. Also
don't allow a userspace open to occur if we've switched the gpu off.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
This adds a hook after the mux is switched for the driver to reprobe
the connected outputs.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
|
|
The IPS driver is designed to be able to run detached from i915 and
just not enable GPU turbo in that case, in order to avoid module
dependencies between the two drivers. This means that we don't know
what the load order between the two is going to be, and we had
previously only supported IPS after (optionally) i915, but not i915
after IPS. If the wrong order was chosen, you'd get no GPU turbo, and
something like half the possible graphics performance.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
|
|
The relative-to-general state default is useless as it means having to
rewrite the streaming kernels for each batch. Relative-to-surface is
more useful, as that stream usually needs to be rewritten for each
batch. And absolute addressing mode, vital if you start streaming
state, is also only available by adjusting the register...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Add frame buffer compression on Sandybridge. The method is similar to
Ironlake, except that two new registers of type GTTMMADR must be written
with the right fence info.
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Immediate merge for the conflicting introduction of HAS_COHERENT_RINGS.
Conflicts:
drivers/gpu/drm/i915/i915_dma.c
include/drm/i915_drm.h
|
|
Otherwise we can't really fix the abi-braindeadness of forcing
libva to manually wait for rendering when switching rings. Which
in turn makes implementing hw semaphores a pointless exercise
(at least for ironlake).
[Also added the relaxed fencing param to explain the jump in
numbering - relaxed fencing is in -next.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The bulk of the change is to convert the growing list of rings into an
array so that the relationship between the rings and the semaphore sync
registers can be easily computed.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This makes the various rings more consistent by removing the anomalous
handing of the rendering ring execbuffer dispatch.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
A glorified s/obj_priv/obj/ with a net reduction of over a 100 lines and
many characters!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
... and no need to perform a linear search for the index.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The GATT is a write-only set of registers, reading from them in the
manner of i915_gtt_to_phys() is supposed to be undefined. However a
simple solution exists as we allocate linear memory from the stolen
area, we can simply add the block offset to the base register. As a
side-effect we recover all the unused stolen GTT entries and so enlarge
our aperture.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
It isn't used for the hangcheck, which does its work right from the
timer trigger, but hangcheck can lead to error state recording, which
is run off of the workqueue.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
We only ever used the PRB0, neglecting the secondary ring buffers, and
now with the advent of multiple engines with separate ring buffers we
need to excise the anachronisms from our code (and be explicit about
which ring we mean where). This is doubly important in light of the
FORCEWAKE required to read ring buffer registers on SandyBridge.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If modeset init failed we attempted to unload the module, before we
finished setting it up and so triggered various oopses.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
After switching the MMIO registers to use pci_iomap, remember to dispose
of the mapping with pci_iounmap (for symmetry).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
So long as we adhere to the fence registers rules for alignment and no
overlaps (including with unfenced accesses to linear memory) and account
for the tiled access in our size allocation, we do not have to allocate
the full fenced region for the object. This allows us to fight the bloat
tiling imposed on pre-i965 chipsets and frees up RAM for real use. [Inside
the GTT we still suffer the additional alignment constraints, so it doesn't
magic allow us to render larger scenes without stalls -- we need the
expanded GTT and fence pipelining to overcome those...]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Eliminate the racy device unload by embedding a shrinker into each
device. Smaller, simpler code.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Play safe and use the common routines which take care of the cachability
of the memory when setting up the iomapping for the PCI registers.
Whilst they should be cacheable for the current generations, actually
honouring what the device requires is a better long term strategy.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This is the same value as before, but it just makes the code slightly
more readable to use the local variable than converting the aperture
size into bytes every time.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
At least the part that's currently enabled by the BIOS.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Preparing the ringbuffer for adding new commands can fail (a timeout
whilst waiting for the GPU to catch up and free some space). So check
for any potential error before overwriting HEAD with new commands, and
propagate that error back to the user where possible.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The ringbuffer keeps a pointer to the parent device, so we can use that
instead of passing around the pointer on the stack.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
So remove the redundant bit in the capabilities block and
s/IS_IRONLAKE/IS_GEN5/.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Based on an original patch by Zhenyu Wang, this initializes the BLT ring for
SandyBridge and enables support for user execbuffers.
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
... by always initialising the empty ringbuffer it is always then safe
to check whether it is active.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The time between start of the pixel clock and backlight enable is a basic
panel timing constraint. If the Panel Power On/Off registers are found
to be 0, assume we are booting without VBIOS initialization and set these
registers to something reasonable.
Change-Id: Ibed6cc10d46bf52fd92e0beb25ae3525b5eef99d
Signed-off-by: Bryan Freed <bfreed@chromium.org>
[ickle: rearranged into a separate function to distinguish its role from
simply parsing the VBIOS tables.]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Freeing the Hardware Status Page was writing to the HWS register in
order to disable the GPU writing to the HWS page. Unfortunately, we were
writing to the mmio register after unmapping the register space, hence
the oops.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This reverts commit 6939a5aca7cfada279a24c307e772f33104fca20.
Daniel Vetter supplied a set of fixes for all the module unload bugs he
could trigger on his machines, so let the fun recommence!
|
|
|
|
Conflicts:
drivers/gpu/drm/i915/intel_fb.c
drivers/gpu/drm/radeon/r600_blit_kms.c
drivers/gpu/drm/ttm/ttm_bo.c
|
|
The i915 driver has quite a few module unload bugs, the known ones at
least have fixes that are targeting 2.6.37. However, in order to
maintain a stable kernel, we should prevent this known random memory
corruption following driver unload. This should have very low impact on
normal users who are unlikely to need to unload the i915 driver.
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@kernel.org
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The _DSM method on the integrated graphics device can tell us which
connectors are muxable, so add support for making the call and parsing
out the connector info.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[ickle: fix compiler warnings for using uninitialized 'result' and
downgrade error message for non-switchable devices]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
A physically mapped hardware status page is allocated at driver load
time but was never freed. Call the existing code to free this page at
driver unload time on hardware which uses this kind.
Signed-off-by: Keith Packard <keithp@keithp.com>
[ickle: call before tearing down registers on KMS-only path, as pointed
out by Dave Airlie]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
|
|
lockdep spots that the fb_info->lock takes the dev->struct_mutex during
init (due to the device probing) and so we can not hold
dev->struct_mutex when unregistering the framebuffer. Simply reverse the
order of initialisation during cleanup and so do the intel_fbdev_fini()
before the intel_modeset_cleanup.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
|
|
The IPS driver needs to know the current power consumption of the GMCH
in order to make decisions about when to increase or decrease the CPU
and/or GPU power envelope. So fix up the divisions to save the results
so the numbers are actually correct (contrary to some earlier comments
and code, these functions do not modify the first argument and use it
for the result).
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
|
|
There is no equivalent to mutex_destroy() for spinlocks so just delete
the code.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Daniel Vetter pointed out that in this case is would be clearer and
cleaner to use a spinlock instead of a mutex to protect the per-file
request list manipulation. Make it so.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
It's the same code, essentially, so kill all copies safe one unified
version.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Avoid cause latencies in other clients by not taking the global struct
mutex and moving the per-client request manipulation a local per-client
mutex. For example, this allows a compositor to schedule a page-flip
(through X) whilst an OpenGL application is monopolising the GPU.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Suspending (especially hibernating) may take a finite amount of time,
during which a hotplug event may trigger and we will attempt to handle
it with inconsistent state. Disable hotplug polling around suspend and
resume.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30070
Reported-by: Rui Tiago Matos <tiagomatos@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Consolidate everything in intel-gtt.c and also kill the export
of intel_max_stolen.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Avoid confusion between i965g meaning broadwater and the gen4+ chipset
families.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
