summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2011-03-24Merge branch 'drm-core-next' of ↵Linus Torvalds15-145/+246
git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6 * 'drm-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: drm/vblank: update recently added vbl interface to be more future proof. drm radeon: Return -EINVAL on wrong pm sysfs access drm/radeon/kms: fix hardcoded EDID handling Revert "drm/i915: Don't save/restore hardware status page address register" drm/i915: Avoid unmapping pages from a NULL address space drm/i915: Fix use after free within tracepoint drm/i915: Restore missing command flush before interrupt on BLT ring drm/i915: Disable pagefaults along execbuffer relocation fast path drm/i915: Fix computation of pitch for dumb bo creator drm/i915: report correct render clock frequencies on SNB drm/i915/dp: Correct the order of deletion for ghost eDP devices drm/i915: Fix tiling corruption from pipelined fencing drm/i915: Re-enable self-refresh drm/i915: Prevent racy removal of request from client list drm/i915: skip redundant operations whilst enabling pipes and planes drm/i915: Remove surplus POSTING_READs before wait_for_vblank drm/radeon/kms: prefer legacy pll algo for tv-out drm: check for modesetting on modeset ioctls drm/kernel: vblank wait on crtc > 1 drm: Fix use-after-free in drm_gem_vm_close()
2011-03-24Merge git://git.kernel.org/pub/scm/linux/kernel/git/lethal/fbdev-2.6Linus Torvalds1-1/+1
* git://git.kernel.org/pub/scm/linux/kernel/git/lethal/fbdev-2.6: (140 commits) MAINTAINERS: de-orphan fbdev. MAINTAINERS: Add file pattern for fb dt bindings. video: Move sm501fb devicetree binding documentation to a better place. fbcon: fix situation where fbcon gets deinitialised and can't reinit. video, sm501: add OF binding to support SM501 video, sm501: add edid and commandline support video, sm501: add I/O functions for use on powerpc video: Fix EDID macros H_SYNC_WIDTH and H_SYNC_OFFSET fbcon: Bugfix soft cursor detection in Tile Blitting video: add missing framebuffer_release in error path video: metronomefb: add __devexit_p around reference to metronomefb_remove video: hecubafb: add __devexit_p around reference to hecubafb_remove drivers:video:aty:radeon_base Fix typo occationally to occasionally atmel_lcdfb: add fb_blank function atmel_lcdfb: implement inverted contrast pwm video: s3c-fb: return proper error if clk_get fails uvesafb,vesafb: create WC or WB PAT-entries video: ffb: fix ffb_probe error path radeonfb: Let hwmon driver probe the "monid" I2C bus fbdev: sh_mobile_lcdc: checking NULL instead of IS_ERR() ...
2011-03-24drm/vblank: update recently added vbl interface to be more future proof.Dave Airlie1-1/+1
This makes the interface a bit cleaner by leaving a single gap in the vblank bit space instead of creating two gaps. Suggestions from Michel on mailing list/irc. Reviewed-by: Michel Dänzer <michel@daenzer.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-03-24drm radeon: Return -EINVAL on wrong pm sysfs accessThomas Renninger1-3/+5
Throw an error if someone tries to fill this with wrong data, instead of simply ignoring the input. Now you get: echo hello >/sys/../power_method -bash: echo: write error: Invalid argument Signed-off-by: Thomas Renninger <trenn@suse.de> CC: Alexander.Deucher@amd.com CC: dri-devel@lists.freedesktop.org Reviewed-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-03-24drm/radeon/kms: fix hardcoded EDID handlingAlex Deucher3-7/+45
On some servers there is a hardcoded EDID provided in the vbios so that the driver will always see a display connected even if something like a KVM prevents traditional means like DDC or load detection from working properly. Also most server boards with DVI are not actually DVI, but DVO connected to a virtual KVM service processor. If we fail to detect a monitor via DDC or load detection and a hardcoded EDID is available, use it. Additionally, when using the hardcoded EDID, use a copy of it rather than the actual one stored in the driver as the detect() and get_modes() functions may free it if DDC is successful. This fixes the virtual KVM on several internal servers. Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Cc: stable@kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-03-24Merge remote branch 'intel/drm-intel-fixes' of ../drm-next into drm-core-nextDave Airlie8-127/+131
* 'intel/drm-intel-fixes' of ../drm-next: Revert "drm/i915: Don't save/restore hardware status page address register" drm/i915: Avoid unmapping pages from a NULL address space drm/i915: Fix use after free within tracepoint drm/i915: Restore missing command flush before interrupt on BLT ring drm/i915: Disable pagefaults along execbuffer relocation fast path drm/i915: Fix computation of pitch for dumb bo creator drm/i915: report correct render clock frequencies on SNB drm/i915/dp: Correct the order of deletion for ghost eDP devices drm/i915: Fix tiling corruption from pipelined fencing drm/i915: Re-enable self-refresh drm/i915: Prevent racy removal of request from client list drm/i915: skip redundant operations whilst enabling pipes and planes drm/i915: Remove surplus POSTING_READs before wait_for_vblank
2011-03-24Revert "drm/i915: Don't save/restore hardware status page address register"Chris Wilson2-0/+7
This reverts commit a7a75c8f70d6f6a2f16c9f627f938bbee2d32718. There are two different variations on how Intel hardware addresses the "Hardware Status Page". One as a location in physical memory and the other as an offset into the virtual memory of the GPU, used in more recent chipsets. (The HWS itself is a cacheable region of memory which the GPU can write to without requiring CPU synchronisation, used for updating various details of hardware state, such as the position of the GPU head in the ringbuffer, the last breadcrumb seqno, etc). These two types of addresses were updated in different locations of code - one inline with the ringbuffer initialisation, and the other during device initialisation. (The HWS page is logically associated with the rings, and there is one HWS page per ring.) During resume, only the ringbuffers were being re-initialised along with the virtual HWS page, leaving the older physical address HWS untouched. This then caused a hang on the older gen3/4 (915GM, 945GM, 965GM) the first time we tried to synchronise the GPU as the breadcrumbs were never being updated. Reported-and-tested-by: Linus Torvalds <torvalds@linux-foundation.org> Reported-by: Jan Niehusmann <jan@gondor.com> Reported-and-tested-by: Justin P. Mattock <justinmattock@gmail.com> Reported-and-tested-by: Michael "brot" Groh <brot@minad.de> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2011-03-23Revert "drm/i915: Don't save/restore hardware status page address register"Chris Wilson2-0/+7
This reverts commit a7a75c8f70d6f6a2f16c9f627f938bbee2d32718. There are two different variations on how Intel hardware addresses the "Hardware Status Page". One as a location in physical memory and the other as an offset into the virtual memory of the GPU, used in more recent chipsets. (The HWS itself is a cacheable region of memory which the GPU can write to without requiring CPU synchronisation, used for updating various details of hardware state, such as the position of the GPU head in the ringbuffer, the last breadcrumb seqno, etc). These two types of addresses were updated in different locations of code - one inline with the ringbuffer initialisation, and the other during device initialisation. (The HWS page is logically associated with the rings, and there is one HWS page per ring.) During resume, only the ringbuffers were being re-initialised along with the virtual HWS page, leaving the older physical address HWS untouched. This then caused a hang on the older gen3/4 (915GM, 945GM, 965GM) the first time we tried to synchronise the GPU as the breadcrumbs were never being updated. Reported-and-tested-by: Linus Torvalds <torvalds@linux-foundation.org> Reported-by: Jan Niehusmann <jan@gondor.com> Reported-by: Justin P. Mattock <justinmattock@gmail.com> Reported-and-tested-by: Michael "brot" Groh <brot@minad.de> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-03-23drm/i915: Avoid unmapping pages from a NULL address spaceChris Wilson1-3/+4
Found by gem_stress. As we perform retirement from a workqueue, it is possible for us to free and unbind objects after the last close on the device, and so after the address space has been torn down and reset to NULL: BUG: unable to handle kernel NULL pointer dereference at 00000054 IP: [<c1295a20>] mutex_lock+0xf/0x27 *pde = 00000000 Oops: 0002 [#1] SMP last sysfs file: /sys/module/vt/parameters/default_utf8 Pid: 5, comm: kworker/u:0 Not tainted 2.6.38+ #214 EIP: 0060:[<c1295a20>] EFLAGS: 00010206 CPU: 1 EIP is at mutex_lock+0xf/0x27 EAX: 00000054 EBX: 00000054 ECX: 00000000 EDX: 00012fff ESI: 00000028 EDI: 00000000 EBP: f706fe20 ESP: f706fe18 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 Process kworker/u:0 (pid: 5, ti=f706e000 task=f7060d00 task.ti=f706e000) Stack: f5aa3c60 00000000 f706fe74 c107e7df 00000246 dea55380 00000054 f5aa3c60 f706fe44 00000061 f70b4000 c13fff84 00000008 f706fe54 00000000 00000000 00012f00 00012fff 00000028 c109e575 f6b36700 00100000 00000000 f706fe90 Call Trace: [<c107e7df>] unmap_mapping_range+0x7d/0x1e6 [<c109e575>] ? mntput_no_expire+0x52/0xb6 [<c11c12f6>] i915_gem_release_mmap+0x49/0x58 [<c11c3449>] i915_gem_object_unbind+0x4c/0x125 [<c11c353f>] i915_gem_free_object_tail+0x1d/0xdb [<c11c55a2>] i915_gem_free_object+0x3d/0x41 [<c11a6be2>] ? drm_gem_object_free+0x0/0x27 [<c11a6c07>] drm_gem_object_free+0x25/0x27 [<c113c3ca>] kref_put+0x39/0x42 [<c11c0a59>] drm_gem_object_unreference+0x16/0x18 [<c11c0b15>] i915_gem_object_move_to_inactive+0xba/0xbe [<c11c0c87>] i915_gem_retire_requests_ring+0x16e/0x1a5 [<c11c3645>] i915_gem_retire_requests+0x48/0x63 [<c11c36ac>] i915_gem_retire_work_handler+0x4c/0x117 [<c10385d1>] process_one_work+0x140/0x21b [<c103734c>] ? __need_more_worker+0x13/0x2a [<c10373b1>] ? need_to_create_worker+0x1c/0x35 [<c11c3660>] ? i915_gem_retire_work_handler+0x0/0x117 [<c1038faf>] worker_thread+0xd4/0x14b [<c1038edb>] ? worker_thread+0x0/0x14b [<c103be1b>] kthread+0x68/0x6d [<c103bdb3>] ? kthread+0x0/0x6d [<c12970f6>] kernel_thread_helper+0x6/0x10 Code: 00 e8 98 fe ff ff 5d c3 55 89 e5 3e 8d 74 26 00 ba 01 00 00 00 e8 84 fe ff ff 5d c3 55 89 e5 53 8d 64 24 fc 3e 8d 74 26 00 89 c3 <f0> ff 08 79 05 e8 ab ff ff ff 89 e0 25 00 e0 ff ff 89 43 10 58 EIP: [<c1295a20>] mutex_lock+0xf/0x27 SS:ESP 0068:f706fe18 CR2: 0000000000000054 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Keith Packard <keithp@keithp.com>
2011-03-23drm/i915: Fix use after free within tracepointChris Wilson1-2/+2
Detected by scripts/coccinelle/free/kfree.cocci. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Keith Packard <keithp@keithp.com>
2011-03-23drm/i915: Restore missing command flush before interrupt on BLT ringChris Wilson2-61/+55
We always skipped flushing the BLT ring if the request flush did not include the RENDER domain. However, this neglects that we try to flush the COMMAND domain after every batch and before the breadcrumb interrupt (to make sure the batch is indeed completed prior to the interrupt firing and so insuring CPU coherency). As a result of the missing flush, incoherency did indeed creep in, most notable when using lots of command buffers and so potentially rewritting an active command buffer (i.e. the GPU was still executing from it even though the following interrupt had already fired and the request/buffer retired). As all ring->flush routines now have the same preconditions, de-duplicate and move those checks up into i915_gem_flush_ring(). Fixes gem_linear_blit. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35284 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Tested-by: mengmeng.meng@intel.com
2011-03-23drm/i915: Disable pagefaults along execbuffer relocation fast pathChris Wilson1-4/+17
Along the fast path for relocation handling, we attempt to copy directly from the user data structures whilst holding our mutex. This causes lockdep to warn about circular lock dependencies if we need to pagefault the user pages. [Since when handling a page fault on a mmapped bo, we need to acquire the struct mutex whilst already holding the mm semaphore, it is then verboten to acquire the mm semaphore when already holding the struct mutex. The likelihood of the user passing in the relocations contained in a GTT mmaped bo is low, but conceivable for extreme pathology.] In order to force the mm to return EFAULT rather than handle the pagefault, we therefore need to disable pagefaults across the relocation fast path. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2011-03-23drm/i915: Fix computation of pitch for dumb bo creatorChris Wilson1-1/+1
Cc: Dave Airlie <airlied@linux.ie> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2011-03-23drm/i915: report correct render clock frequencies on SNBJesse Barnes2-5/+5
Fix up the debug file to report the right frequencies. On SNB, we program the PCU with a frequency ratio, which is multiplied by 100MHz on the CPU side. But GFX only runs at half that, so report it as such to avoid confusion. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Keith Packard <keithp@keithp.com>
2011-03-23drm/i915/dp: Correct the order of deletion for ghost eDP devicesTakashi Iwai1-2/+2
The order of the calls does matter indeed. Swapping the call order of intel_dp_destroy() and intel_dp_encoder_destroy() fixes the problem. This is because i2c_del_adapter unregisters the device which parent is intel_connector, and connectors are removed in intel_dp_destroy(). Thus intel_dp_encoder_destroy() must be called before intel_dp_destroy(). Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=24822 Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Keith Packard <keithp@keithp.com>
2011-03-23drm/i915: Fix tiling corruption from pipelined fencingChris Wilson1-27/+17
... even though it was disabled. A mistake in the handling of fence reuse caused us to skip the vital delay of waiting for the object to finish rendering before changing the register. This resulted in us changing the fence register whilst the bo was active and so causing the blits to complete using the wrong stride or even the wrong tiling. (Visually the effect is that small blocks of the screen look like they have been interlaced). The fix is to wait for the GPU to finish using the memory region pointed to by the fence before changing it. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34584 Cc: Andy Whitcroft <apw@canonical.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> [Note for 2.6.38-stable, we need to reintroduce the interruptible passing] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Dave Airlie <airlied@linux.ie>
2011-03-23drm/i915: Re-enable self-refreshYuanhan Liu1-4/+1
A broken implementation of is_pot() prevented the detection of when a singular pipe was enabled. Eric Anholt pointed out the existence of is_power_of_2() so use that instead of our broken code! Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35402 Signed-off-by: Yuanhan Liu <yuanhan.liu@intel.com> Tested-by: xunx.fang@intel.com Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2011-03-23drm/i915: Prevent racy removal of request from client listHerton Ronaldo Krzesinski1-2/+4
When i915_gem_retire_requests_ring calls i915_gem_request_remove_from_client, the client_list for that request may already be removed in i915_gem_release. So we may call twice list_del(&request->client_list), resulting in an oops like this report: [126167.230394] BUG: unable to handle kernel paging request at 00100104 [126167.230699] IP: [<f8c2ce44>] i915_gem_retire_requests_ring+0xd4/0x240 [i915] [126167.231042] *pdpt = 00000000314c1001 *pde = 0000000000000000 [126167.231314] Oops: 0002 [#1] SMP [126167.231471] last sysfs file: /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT1/current_now [126167.231901] Modules linked in: snd_seq_dummy nls_utf8 isofs btrfs zlib_deflate libcrc32c ufs qnx4 hfsplus hfs minix ntfs vfat msdos fat jfs xfs exportfs reiserfs cryptd aes_i586 aes_generic binfmt_misc vboxnetadp vboxnetflt vboxdrv parport_pc ppdev snd_hda_codec_hdmi snd_hda_codec_conexant snd_hda_intel snd_hda_codec snd_hwdep arc4 snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq uvcvideo videodev snd_timer snd_seq_device joydev iwlagn iwlcore mac80211 snd cfg80211 soundcore i915 drm_kms_helper snd_page_alloc psmouse drm serio_raw i2c_algo_bit video lp parport usbhid hid sky2 sdhci_pci ahci sdhci libahci [126167.232018] [126167.232018] Pid: 1101, comm: Xorg Not tainted 2.6.38-6-generic-pae #34-Ubuntu Gateway MC7833U / [126167.232018] EIP: 0060:[<f8c2ce44>] EFLAGS: 00213246 CPU: 0 [126167.232018] EIP is at i915_gem_retire_requests_ring+0xd4/0x240 [i915] [126167.232018] EAX: 00200200 EBX: f1ac25b0 ECX: 00000040 EDX: 00100100 [126167.232018] ESI: f1a2801c EDI: e87fc060 EBP: ef4d7dd8 ESP: ef4d7db0 [126167.232018] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [126167.232018] Process Xorg (pid: 1101, ti=ef4d6000 task=f1ba6500 task.ti=ef4d6000) [126167.232018] Stack: [126167.232018] f1a28000 f1a2809c f1a28094 0058bd97 f1aa2400 f1a2801c 0058bd7b 0058bd85 [126167.232018] f1a2801c f1a28000 ef4d7e38 f8c2e995 ef4d7e30 ef4d7e60 c14d1ebc f6b3a040 [126167.232018] f1522cc0 000000db 00000000 f1ba6500 ffffffa1 00000000 00000001 f1a29214 [126167.232018] Call Trace: Unfortunately the call trace reported was cut, but looking at debug symbols the crash is at __list_del, when probably list_del is called twice on the same request->client_list, as the dereferenced value is LIST_POISON1 + 4, and by looking more at the debug symbols before list_del call it should have being called by i915_gem_request_remove_from_client And as I can see in the code, it seems we indeed have the possibility to remove a request->client_list twice, which would cause the above, because we do list_del(&request->client_list) on both i915_gem_request_remove_from_client and i915_gem_release As Chris Wilson pointed out, it's indeed the case: "(...) I had thought that the actual insertion/deletion was serialised under the struct mutex and the intention of the spinlock was to protect the unlocked list traversal during throttling. However, I missed that i915_gem_release() is also called without struct mutex and so we do need the double check for i915_gem_request_remove_from_client()." This change does the required check to avoid the duplicate remove of request->client_list. Bugzilla: http://bugs.launchpad.net/bugs/733780 Cc: stable@kernel.org # 2.6.38 Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2011-03-23drm/i915: skip redundant operations whilst enabling pipes and planesChris Wilson1-8/+16
If the pipe or plane is already enabled, then we do not need to enable it again and can skip the delay. Similarly if it is already disabled when we want to disable it, we can also skip it. This fixes a regression from b24e717988, which caused the LVDS output on one PineView machine to become corrupt after changing orientation several times. References: https://bugs.freedesktop.org/show_bug.cgi?id=34601 Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Keith Packard <keithp@keithp.com> Tested-by: mengmeng.meng@intel.com
2011-03-23drm/i915: Remove surplus POSTING_READs before wait_for_vblankChris Wilson1-8/+0
... as wait_for_vblank (and friends) will do a flush of the MMIO writes anyway. References: https://bugs.freedesktop.org/show_bug.cgi?id=34601 Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Keith Packard <keithp@keithp.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2011-03-23drm/radeon/kms: prefer legacy pll algo for tv-outAlex Deucher1-1/+5
ntsc seems to work fine with either algo, some pal TVs seem pickier. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=30832 Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Cc: stable@kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-03-22nouveau: change the backlight parent device to the connector, not the PCI devMatthew Garrett4-20/+27
We may eventually end up with per-connector backlights, especially with ddcci devices. Make sure that the parent node for the backlight device is the connector rather than the PCI device. Signed-off-by: Matthew Garrett <mjg@redhat.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: David Airlie <airlied@linux.ie> Cc: Alex Deucher <alexdeucher@gmail.com> Acked-by: Ben Skeggs <bskeggs@redhat.com> Cc: Zhang Rui <rui.zhang@intel.com> Cc: Len Brown <lenb@kernel.org> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Sedat Dilek <sedat.dilek@googlemail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-03-22radeon: expose backlight class device for legacy LVDS encoderMichel Dänzer4-6/+273
Allows e.g. power management daemons to control the backlight level. Inspired by the corresponding code in radeonfb. [mjg@redhat.com: updated to add backlight type and make the connector the parent device] Signed-off-by: Michel Dänzer <michel@daenzer.net> Signed-off-by: Matthew Garrett <mjg@redhat.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: David Airlie <airlied@linux.ie> Acked-by: Alex Deucher <alexdeucher@gmail.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Zhang Rui <rui.zhang@intel.com> Cc: Len Brown <lenb@kernel.org> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Sedat Dilek <sedat.dilek@googlemail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-03-22backlight: add backlight typeMatthew Garrett1-0/+2
There may be multiple ways of controlling the backlight on a given machine. Allow drivers to expose the type of interface they are providing, making it possible for userspace to make appropriate policy decisions. Signed-off-by: Matthew Garrett <mjg@redhat.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: David Airlie <airlied@linux.ie> Cc: Alex Deucher <alexdeucher@gmail.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Zhang Rui <rui.zhang@intel.com> Cc: Len Brown <lenb@kernel.org> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-03-22drivers:video:aty:radeon_base Fix typo occationally to occasionallyJustin P. Mattock1-1/+1
The below patch fixes a typo occationally to occasionally. Signed-off-by: Justin P. Mattock <justinmattock@gmail.com> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2011-03-21drm: check for modesetting on modeset ioctlsDave Airlie1-0/+51
Noticed this while working on some other things, helps if we check for modeset enabled on modesetting ioctls. Cc: stable@kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-03-21drm/kernel: vblank wait on crtc > 1Ilija Hadzic2-5/+13
Below is a patch against drm-next branch of 2.6.38-rc8+ kernel that adds the capability to wait on vblank events for CRTCs that are greater than 1 and thus cannot be represented with primary/secondary flags in the legacy interface. It was discussed on the dri-devel list in these two threads: http://lists.freedesktop.org/archives/dri-devel/2011-March/009009.html http://lists.freedesktop.org/archives/dri-devel/2011-March/009025.html This patch extends the interface to drm_wait_vblank ioctl so that crtc>1 can be represented. It also adds a new capability to drm_getcap ioctl so that the user space can check whether the new interface to drm_wait_vblank is supported (and fall back to the legacy interface if not) Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com> Reviewed-by: Mario Kleiner <mario.kleiner at tuebingen.mpg.de> Acked-by: Mario Kleiner <mario.kleiner at tuebingen.mpg.de> Reviewed-by: Alex Deucher <alexdeucher@gmail.com> Tested-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-03-21drm: Fix use-after-free in drm_gem_vm_close()Chris Wilson1-2/+3
As we may release the last reference, we need to store the device in a local variable in order to unlock afterwards. [ 60.140768] BUG: unable to handle kernel paging request at 6b6b6b9f [ 60.140973] IP: [<c1536d11>] __mutex_unlock_slowpath+0x5a/0x111 [ 60.141014] *pdpt = 0000000024a54001 *pde = 0000000000000000 [ 60.141014] Oops: 0002 [#1] PREEMPT SMP [ 60.141014] last sysfs file: /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/PNP0C0A:00/power_supply/BAT0/voltage_now [ 60.141014] Modules linked in: uvcvideo ath9k pegasus ath9k_common ath9k_hw hid_egalax ath3k joydev asus_laptop sparse_keymap battery input_polldev [ 60.141014] [ 60.141014] Pid: 771, comm: meego-ux-daemon Not tainted 2.6.37.2-7.1 #1 EXOPC EXOPG06411/EXOPG06411 [ 60.141014] EIP: 0060:[<c1536d11>] EFLAGS: 00010046 CPU: 0 [ 60.141014] EIP is at __mutex_unlock_slowpath+0x5a/0x111 [ 60.141014] EAX: 00000100 EBX: 6b6b6b9b ECX: e9b4a1b0 EDX: e4a4e580 [ 60.141014] ESI: db162558 EDI: 00000246 EBP: e480be50 ESP: e480be44 [ 60.141014] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 [ 60.141014] Process meego-ux-daemon (pid: 771, ti=e480a000 task=e9b4a1b0 task.ti=e480a000) [ 60.141014] Stack: [ 60.141014] e4a4e580 db162558 f5a2f838 e480be58 c1536dd0 e480be68 c125ab1b db162558 [ 60.141014] db1624e0 e480be78 c10ba071 db162558 f760241c e480be94 c10bb0bc 000155fe [ 60.141014] f760241c f5a2f838 f5a2f8c8 00000000 e480bea4 c1037c24 00000000 f5a2f838 [ 60.141014] Call Trace: [ 60.141014] [<c1536dd0>] ? mutex_unlock+0x8/0xa [ 60.141014] [<c125ab1b>] ? drm_gem_vm_close+0x39/0x3d [ 60.141014] [<c10ba071>] ? remove_vma+0x2d/0x58 [ 60.141014] [<c10bb0bc>] ? exit_mmap+0x126/0x13f [ 60.141014] [<c1037c24>] ? mmput+0x37/0x9a [ 60.141014] [<c10d450d>] ? exec_mmap+0x178/0x19c [ 60.141014] [<c1537f85>] ? _raw_spin_unlock+0x1d/0x36 [ 60.141014] [<c10d4eb0>] ? flush_old_exec+0x42/0x75 [ 60.141014] [<c1104442>] ? load_elf_binary+0x32a/0x922 [ 60.141014] [<c10d3f76>] ? search_binary_handler+0x200/0x2ea [ 60.141014] [<c10d3ecf>] ? search_binary_handler+0x159/0x2ea [ 60.141014] [<c1104118>] ? load_elf_binary+0x0/0x922 [ 60.141014] [<c10d56b2>] ? do_execve+0x1ff/0x2e6 [ 60.141014] [<c100970e>] ? sys_execve+0x2d/0x55 [ 60.141014] [<c1002a5a>] ? ptregs_execve+0x12/0x18 [ 60.141014] [<c10029dc>] ? sysenter_do_call+0x12/0x3c [ 60.141014] [<c1530000>] ? init_centaur+0x9c/0x1ba [ 60.141014] Code: c1 00 75 0f ba 38 01 00 00 b8 8c 3a 6c c1 e8 cc 2e b0 ff 9c 58 8d 74 26 00 89 c7 fa 90 8d 74 26 00 e8 d2 b4 b2 ff b8 00 01 00 00 <f0> 66 0f c1 43 04 38 e0 74 07 f3 90 8a 43 04 eb f5 83 3d 64 ef [ 60.141014] EIP: [<c1536d11>] __mutex_unlock_slowpath+0x5a/0x111 SS:ESP 0068:e480be44 [ 60.141014] CR2: 000000006b6b6b9f Reported-by: Rusty Lynch <rusty.lynch@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-03-18Merge branch 'for-linus' of ↵Linus Torvalds13-26/+24
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (47 commits) doc: CONFIG_UNEVICTABLE_LRU doesn't exist anymore Update cpuset info & webiste for cgroups dcdbas: force SMI to happen when expected arch/arm/Kconfig: remove one to many l's in the word. asm-generic/user.h: Fix spelling in comment drm: fix printk typo 'sracth' Remove one to many n's in a word Documentation/filesystems/romfs.txt: fixing link to genromfs drivers:scsi Change printk typo initate -> initiate serial, pch uart: Remove duplicate inclusion of linux/pci.h header fs/eventpoll.c: fix spelling mm: Fix out-of-date comments which refers non-existent functions drm: Fix printk typo 'failled' coh901318.c: Change initate to initiate. mbox-db5500.c Change initate to initiate. edac: correct i82975x error-info reported edac: correct i82975x mci initialisation edac: correct commented info fs: update comments to point correct document target: remove duplicate include of target/target_core_device.h from drivers/target/target_core_hba.c ... Trivial conflict in fs/eventpoll.c (spelling vs addition)
2011-03-17drm/radeon: fixup refcounts in radeon dumb create ioctl.Dave Airlie1-3/+5
This was using old gem refcounting methods, fix it to be the same as the normal create ioctl. Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-03-17drm: radeon: *_cs_packet_parse_vline() cleanupPaul Bolle3-42/+23
Simplify the way the return value is set a number of times (mostly on error). Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-03-17radeon: merge list_del()/list_add_tail() to list_move_tail()Nicolas Kaiser1-4/+2
Merge list_del() + list_add_tail() to list_move_tail(). Signed-off-by: Nicolas Kaiser <nikai@nikai.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-03-16Merge commit '5359533801e3dd3abca5b7d3d985b0b33fd9fe8b' into drm-core-nextDave Airlie24-47/+110
This commit changed an internal radeon structure, that meant a new driver in -next had to be fixed up, merge in the commit and fix up the driver. Also fixes a trivial nouveau merge. Conflicts: drivers/gpu/drm/nouveau/nouveau_mem.c
2011-03-16drm: Retry i2c transfer of EDID block after failureChris Wilson1-16/+24
Usually EDID retrieval is fine. However, sometimes, especially when the machine is loaded, it fails, but succeeds after a few retries. Based on a patch by Michael Buesch. Reported-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-03-16drm/radeon/kms: fix typo in atom overscan setupAlex Deucher1-2/+2
Typo in the aspect scale setup. Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Cc: stable@kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-03-16drm: Hold the mode mutex whilst probing for sysfs statusChris Wilson1-0/+7
As detect will use hw registers and may modify structures, it needs to be serialised by use of the dev->mode_config.mutex. Make it so. Otherwise, we may cause random crashes as the sysfs file is queried whilst a concurrent hotplug poll is being run. For example: [ 1189.189626] BUG: unable to handle kernel NULL pointer dereference at 00000100 [ 1189.189821] IP: [<e0c22019>] intel_tv_detect_type+0xa2/0x203 [i915] [ 1189.190020] *pde = 00000000 [ 1189.190104] Oops: 0000 [#1] SMP [ 1189.190209] last sysfs file: /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-SVIDEO-1/status [ 1189.190412] Modules linked in: mperf cpufreq_conservative cpufreq_userspace cpufreq_powersave cpufreq_stats decnet uinput fuse loop joydev snd_hd a_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm i915 snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq drm_kms_helper snd_timer uvcvideo d rm snd_seq_device eeepc_laptop tpm_tis usbhid videodev i2c_algo_bit v4l1_compat snd sparse_keymap i2c_core hid serio_raw tpm psmouse evdev tpm_bios rfkill shpchp ac processor rng_c ore battery video power_supply soundcore pci_hotplug button output snd_page_alloc usb_storage uas ext3 jbd mbcache sd_mod crc_t10dif ata_generic ahci libahci ata_piix libata uhci_h cd ehci_hcd scsi_mod usbcore thermal atl2 thermal_sys nls_base [last unloaded: scsi_wait_scan] [ 1189.192007] [ 1189.192007] Pid: 1464, comm: upowerd Not tainted 2.6.37-2-686 #1 ASUSTeK Computer INC. 701/701 [ 1189.192007] EIP: 0060:[<e0c22019>] EFLAGS: 00010246 CPU: 0 [ 1189.192007] EIP is at intel_tv_detect_type+0xa2/0x203 [i915] [ 1189.192007] EAX: 00000000 EBX: dca74000 ECX: e0f68004 EDX: 00068004 [ 1189.192007] ESI: dd110c00 EDI: 400c0c37 EBP: dca7429c ESP: de365e2c [ 1189.192007] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 1189.192007] Process upowerd (pid: 1464, ti=de364000 task=dcc8acb0 task.ti=de364000) [ 1189.192007] Stack: Mar 15 03:43:23 hostname kernel: [ 1189.192007] e0c2cda4 70000000 400c0c30 00000000 dd111000 de365e54 de365f24 dd110c00 [ 1189.192007] e0c22203 01000000 00000003 00000000 00000000 00000000 00000000 4353544e [ 1189.192007] 30383420 00000069 00000000 00000000 00000000 00000000 00000000 00000000 [ 1189.192007] Call Trace: Mar 15 03:43:23 hostname kernel: [ 1189.192007] [<e0c22203>] ? intel_tv_detect+0x89/0x12d [i915] [ 1189.192007] [<e0a9dcef>] ? status_show+0x0/0x2f [drm] [ 1189.192007] [<e0a9dd03>] ? status_show+0x14/0x2f [drm] [Digression: what is upowerd doing reading those power hungry files?] Reported-by: Paul Menzel <paulepanter@users.sourceforge.net> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-03-15Merge remote branch 'nouveau/drm-nouveau-next' of ../drm-nouveau-next into ↵Dave Airlie12-92/+257
drm-core-next * 'nouveau/drm-nouveau-next' of ../drm-nouveau-next: drm/nouveau: fix __nouveau_fence_wait performance drm/nv40: attempt to reserve just enough vram for all 32 channels drm/nv50: check for vm traps on every gr irq drm/nv50: decode vm faults some more drm/nouveau: add nouveau_enum_find() util function drm/nouveau: properly handle pushbuffer check failures drm/nvc0: remove vm hack forcing large/small pages to not share a PDE
2011-03-14drm/nouveau: fix __nouveau_fence_wait performanceMarcin Slusarz1-3/+12
Commit 21e86c1c8a844bf978f8fc431a59c9f5a578812d ("drm/nouveau: remove cpu_writers lock") turned on lazy waits. Unfortunately __nouveau_fence_wait was not optimized for this case and on HZ=100 kernel wasted up to 10 ms per call. Depending on application, it led to 10-30% FPS regression. Fix it. Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: Francisco Jerez <currojerez@riseup.net>
2011-03-14drm/nv40: attempt to reserve just enough vram for all 32 channelsBen Skeggs2-10/+27
This also makes the fact we're giving 512MiB of GART space to all PCIE boards explicit, although the vast majority (if not all) of them will now have a ramin_rsvd_vram larger than 2MiB anyway. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2011-03-14drm/nv50: check for vm traps on every gr irqBen Skeggs5-6/+5
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2011-03-14drm/nv50: decode vm faults some moreBen Skeggs1-6/+142
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2011-03-14drm/nouveau: add nouveau_enum_find() util functionBen Skeggs3-53/+66
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2011-03-14drm/nouveau: properly handle pushbuffer check failuresMarcin Slusarz1-2/+4
When "buffer in list" check does not pass, don't free validation lists - they were not initialized yet. Fixes this oops: [drm] nouveau 0000:02:00.0: push 105 buffer not in list BUG: unable to handle kernel NULL pointer dereference at 000000000000057c IP: [<ffffffff81236aa4>] do_raw_spin_lock+0x14/0x13c PGD 1ac6cb067 PUD 1aaa52067 PMD 0 CPU 0 Modules linked in: nouveau ttm drm_kms_helper snd_hda_codec_realtek snd_hda_intel snd_hda_codec Pid: 6265, comm: OilRush_x86 Not tainted 2.6.38-rc6-nv+ #632 System manufacturer System Product Name/P6T SE RIP: 0010:[<ffffffff81236aa4>] [<ffffffff81236aa4>] do_raw_spin_lock+0x14/0x13c (...) Process OilRush_x86 (pid: 6265, threadinfo ffff8801a6aee000, task ffff8801a26c0000) 0000000000000000 ffff8801ac74c618 0000000000000000 0000000000000578 0000000000000000 ffff8801ac74c618 0000000000000000 ffff8801bd9d0000 [<ffffffff81417f78>] _raw_spin_lock+0x1e/0x22 [<ffffffffa00a2746>] nouveau_bo_fence+0x2e/0x60 [nouveau] [<ffffffffa00a540b>] validate_fini_list+0x35/0xeb [nouveau] [<ffffffffa00a54d3>] validate_fini+0x12/0x31 [nouveau] [<ffffffffa00a6386>] nouveau_gem_ioctl_pushbuf+0xe94/0xf6b [nouveau] [<ffffffff8141ac56>] ? sub_preempt_count+0x9e/0xb2 [<ffffffff81417e94>] ? _raw_spin_unlock_irqrestore+0x30/0x4d [<ffffffff8105dea2>] ? __wake_up+0x3f/0x48 [<ffffffff812aebb4>] drm_ioctl+0x289/0x361 [<ffffffff8141ac56>] ? sub_preempt_count+0x9e/0xb2 [<ffffffffa00a54f2>] ? nouveau_gem_ioctl_pushbuf+0x0/0xf6b [nouveau] [<ffffffff8141ac56>] ? sub_preempt_count+0x9e/0xb2 [<ffffffffa010caa2>] nouveau_compat_ioctl+0x16/0x1c [nouveau] [<ffffffff81142c0d>] compat_sys_ioctl+0x1c8/0x12d7 [<ffffffff814179ca>] ? trace_hardirqs_off_thunk+0x3a/0x6c [<ffffffff81058099>] sysenter_dispatch+0x7/0x30 [<ffffffff8141798e>] ? trace_hardirqs_on_thunk+0x3a/0x3c RIP [<ffffffff81236aa4>] do_raw_spin_lock+0x14/0x13c RSP <ffff8801a6aefb88> ---[ end trace 0014d5d93e6147e1 ]--- Additionally, don't call validate_fini twice in case of validation failure. Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: Maarten Maathuis <madman2003@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2011-03-14drm/nvc0: remove vm hack forcing large/small pages to not share a PDEBen Skeggs1-12/+1
Appears to be fixed with commit: "drm/nv50-nvc0: make sure vma is definitely unmapped when destroying bo" Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2011-03-14drm/i915: disable opregion lid detection for now.Dave Airlie1-0/+6
At least on my HP 2540p this is wrong at bootup, fine at any other time once a lid event has occured. This is due to _REG vs _INI ordering in the ACPI tables. Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-03-14Merge remote branch 'intel/drm-intel-next' of ../drm-next into drm-core-nextDave Airlie67-2234/+3481
* 'intel/drm-intel-next' of ../drm-next: (755 commits) drm/i915: Only wait on a pending flip if we intend to write to the buffer drm/i915/dp: Sanity check eDP existence drm/i915: Rebind the buffer if its alignment constraints changes with tiling drm/i915: Disable GPU semaphores by default drm/i915: Do not overflow the MMADDR write FIFO Revert "drm/i915: fix corruptions on i8xx due to relaxed fencing" drm/i915: Don't save/restore hardware status page address register drm/i915: don't store the reg value for HWS_PGA drm/i915: fix memory corruption with GM965 and >4GB RAM Linux 2.6.38-rc7 Revert "TPM: Long default timeout fix" drm/i915: Re-enable GPU semaphores for SandyBridge mobile drm/i915: Replace vblank PM QoS with "Interrupt-Based AGPBUSY#" Revert "drm/i915: Use PM QoS to prevent C-State starvation of gen3 GPU" drm/i915: Allow relocation deltas outside of target bo drm/i915: Silence an innocuous compiler warning for an unused variable fs/block_dev.c: fix new kernel-doc warning ACPI: Fix build for CONFIG_NET unset mm: <asm-generic/pgtable.h> must include <linux/mm_types.h> x86: Use u32 instead of long to set reset vector back to 0 ... Conflicts: drivers/gpu/drm/i915/i915_gem.c
2011-03-14drm/radeon: fix problem with changing active VRAM size. (v2)Dave Airlie11-17/+28
So we used to use lpfn directly to restrict VRAM when we couldn't access the unmappable area, however this was removed in 93225b0d7bc030f4a93165347a65893685822d70 as it also restricted the gtt placements. However it was only later noticed that this broke on some hw. This removes the active_vram_size, and just explicitly sets it when it changes, TTM/drm_mm will always use the real_vram_size, and the active vram size will change the TTM size used for lpfn setting. We should re-work the fpfn/lpfn to per-placement at some point I suspect, but that is too late for this kernel. Hopefully this addresses: https://bugs.freedesktop.org/show_bug.cgi?id=35254 v2: fix reported useful VRAM size to userspace to be correct. Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-03-13drm/radeon: fix page flipping hangs on r300/r400Dave Airlie2-18/+2
We've been getting reports of complete system lockups with rv3xx hw on AGP and PCIE when running gnome-shell or kwin with compositing. It appears the hw really doesn't like setting these registers while stuff is running, this moves the setting of the registers into the modeset since they aren't required to be changed anywhere else. fixes: https://bugs.freedesktop.org/show_bug.cgi?id=35183 Reported-and-tested-by: Álmos <aaalmosss@gmail.com Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-03-11drm/radeon: add pageflip hooks for fusionDave Airlie1-0/+3
Looks like these got passed over with both being merged at the same time but not quite meeting in the middle. should fix: https://bugs.freedesktop.org/show_bug.cgi?id=34137 along with Michael's phoronix article. Reported-by: Chi-Thanh Christopher Nguyen Article-written-by: Michael Larabel @ phoronix Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-03-10drm/i915: Revive combination mode for backlight controlTakashi Iwai2-0/+46
This reverts commit 951f3512dba5bd44cda3e5ee22b4b522e4bb09fb drm/i915: Do not handle backlight combination mode specially since this commit introduced other regressions due to untouched LBPC register, e.g. the backlight dimmed after resume. In addition to the revert, this patch includes a fix for the original issue (weird backlight levels) by removing the wrong bit shift for computing the current backlight level. Also, including typo fixes (lpbc -> lbpc). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34524 Acked-by: Indan Zupancic <indan@nul.nu> Reviewed-by: Keith Packard <keithp@keithp.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: <stable@kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-10-31 12:47:30 +0000