summaryrefslogtreecommitdiffstats
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2012-02-13vmwgfx: Make it possible to get fence from execbufJakob Bornecrantz3-10/+18
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-02-13vmwgfx: Clean up pending event references to struct drm_file objects on closeThomas Hellstrom4-2/+73
Pending events may have stale pointer references to struct drm_file objects after a file has been closed, but before the event is supposed to be attached to the drm file. Remove such events on file close. Tested with "modetest". Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-02-13vmwgfx: Rework fence event actionJakob Bornecrantz2-118/+104
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-02-13drm/modes: do not enforce an odd vtotal for interlaced modesDaniel Vetter1-2/+0
CEA actually specifies an interlaced mode with even vtotal and supplies a diagram showing how this is supposed to work. Note that interlaced modes with an even vtotal seem to be a fairly recent invention. All modelines lore I could dig up with googling says that vtotal for interlaced modes _needs_ to be odd. But the even modelines in CEA are not a spec-bug, there's a figure in CEA-861-E called "Figure 5 Special Interlaced Video Format Timing (Even Vtotal)" that explains how it's supposed to work. Furthermore intel Bspec explicitly mentions that both odd and even interlaced vtotal are supported (VTOTAL register in the south display engine of PCH split chips). Acked-by: Adam Jackson <ajax@redhat.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-02-09drm: do not set fb_info->pixmap fieldsSascha Hauer5-33/+5
The drm drivers set the fb_info->pixmap fields without setting fb_info->pixmap.addr. If this is not set the fb core will overwrite these all fb_info->pixmap fields anyway, so there is not much point in setting them in the first place. [airlied: dropped nvidiafb piece - not mine] Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-02-09drm: add convenience function to create an range propertySascha Hauer7-121/+53
Creating a range property is a common pattern, so create a convenience function for this and use it where appropriate. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-02-09drm: add convenience function to create an enum propertySascha Hauer4-109/+72
Creating an enum property is a common pattern, so create a convenience function for this and use it where appropriate. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-02-07Merge branch 'for-airlied' of git://people.freedesktop.org/~danvet/drm-intel ↵Dave Airlie13-518/+178
into drm-core-next * 'for-airlied' of git://people.freedesktop.org/~danvet/drm-intel: drm/i915: add a LLC feature flag in device description drm/i915: kill i915_mem.c drm/i915: Use kcalloc instead of kzalloc to allocate array drm/i915/dp: Check for AUXCH error before checking for success drm/i915/dp: Use auxch precharge value of 5 everywhere drm/i915/dp: Tweak auxch clock divider for PCH drm/i915: Remove a comment about PCH from the non-PCH path drm/i915: Fix assert_pch_hdmi_disabled to mention HDMI (not DP) drm/i915: Implement plane-disabled assertion for PCH too drivers: i915: Fix BLC PWM register setup drm/i915: Check that plane/pipe is disabled before removing the fb drm/i915: fix typo in function name drm/i915: split out pll divider code drm/i915: split 9xx refclk & sdvo tv code out agp/intel: Add pci id for hostbridge from has/qemu drm/i915: there is no pipe CxSR on ironlake drm/i915: Only look for matching clocks for LVDS downclock drm/i915: Silence _DSM errors
2012-02-03drm exynos: use drm_fb_helper_set_par directlySascha Hauer1-27/+1
info->fix.visual already is correctly set from drm_fb_helper_fill_fix. info->fix.line_length is also set from drm_fb_helper_fill_fix, so drm_fb_helper_set_par directly instead of a custom exynos_drm_fbdev_set_par. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Tested-by: Inki Dae <inki.dae@samsung.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-02-03drm crtc_helper: use list_for_each_entrySascha Hauer1-6/+6
list_for_each_entry_safe is for walking a list safe against removal of entries. Here, no entries are removed, so use list_for_each_entry. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-02-03drm crtc: Fix locking commentsSascha Hauer1-6/+15
Several comments above functions say that the caller must hold the mode_config lock, but the functions take the lock themselves. Fix the comments. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-02-03drm fb helper: remove unused variable crtc_idSascha Hauer1-1/+0
crtc_id is set but never used, so remove it from struct drm_fb_helper_crtc. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-02-03drm fb helper: remove unused variable conn_limitSascha Hauer1-1/+1
conn_limit is set but never used. Remove it from struct drm_fb_helper. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-02-03drm fb helper: use drm_helper_connector_dpms to do dpmsSascha Hauer1-70/+10
drm_fb_helper_on|off currently manually searches for encoders to turn on/off. Make this simpler by using the helper function. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-02-03drm: add proper return value for drm_mode_crtc_set_gamma_sizeSascha Hauer1-3/+3
drm_mode_crtc_set_gamma_size returns boolean true for success and false for failure. This is not very kernel conform, so change it to return 0 for success and a propert error code otherwise. Noone checks the return value, so no users have to be fixed. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-02-03drm drm_fb_helper: destroy modesSascha Hauer1-1/+4
drm_setup_crtcs allocated modes using drm_mode_duplicate. Free them in drm_fb_helper_crtc_free. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-02-03drm crtc: use drm_mode_destroy instead of kfree in drm_mode_removeSascha Hauer1-1/+1
Modes are created using drm_mode_create which does a drm_mode_object_get, so use drm_mode_destroy in drm_mode_remove which does a drm_mode_object_put. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-02-03drm/edid: drm modes have to be free with drm_mode_destroySascha Hauer1-1/+1
to add the missing drm_mode_object_put for that mode. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-02-03drm crtc: add forgotten idr cleanup functionsSascha Hauer1-0/+3
drm_mode_config_init initializes the idr with idr_init, so add the missing counterparts in drm_mode_config_cleanup. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-02-03drm/radeon/kms: add r1xx/r2xx CS support for tiled texturesAlex Deucher2-2/+22
Not likely this will be implemented anytime soon, but for completeness... Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-02-03drm/radeon/kms: add r1xx/r2xx support for CS_KEEP_TILING_FLAGSAlex Deucher2-27/+36
Previous patch only updates r3xx+. It's not likely anyone will use this on r1xx/r2xx, but add it for consistency. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-02-03drm: give up on edid retries when i2c bus is not respondingEugeni Dodonov1-0/+5
This allows to avoid talking to a non-responding bus repeatedly until we finally timeout after 15 attempts. We can do this by catching the -ENXIO error, provided by i2c_algo_bit:bit_doAddress call. Within the bit_doAddress we already try 3 times to get the edid data, so if the routine tells us that bus is not responding, it is mostly pointless to keep re-trying those attempts over and over again until we reach final number of retries. This change should fix https://bugs.freedesktop.org/show_bug.cgi?id=41059 and improve overall edid detection timing by 10-30% in most cases, and by a much larger margin in case of phantom outputs (up to 30x in one worst case). Timing results for i915-powered machines for 'time xrandr' command: Machine 1: from 0.840s to 0.290s Machine 2: from 0.315s to 0.280s Machine 3: from +/- 4s to 0.184s Timing results for HD5770 with 'time xrandr' command: Machine 4: from 3.210s to 1.060s Reviewed-by: Chris Wilson <chris@hchris-wilson.co.uk> Reviewed-by: Keith Packard <keithp@keithp.com> Tested-by: Sean Finney <seanius@seanius.net> Tested-by: Soren Hansen <soren@linux2go.dk> Tested-by: Hernando Torque <sirius@sonnenkinder.org> Tested-by: Mike Lothian <mike@fireburn.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41059 Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-02-03drm/radeon/kms/dce3+: add support for hw i2c using atomAlex Deucher3-1/+161
Starting with DCE3 hardware, atom contains a general purpose ProcessI2cChannelTransaction similar to ProcessAuxChannelTransaction. Add an implementation using the atom tables for DCE3+ hardware. This should be a little less CPU intensive than bit banging and may work better in certain cases. Enable it by setting the radeon hw_i2c module parameter to 1. E.g., radeon.hw_i2c=1 on the kernel command line in grub. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-02-03drm/radeon/kms: Use the standard VESA timeout for DDC channelsJean Delvare1-3/+1
The VESA specification suggests a 2.2 ms timeout on DDC channels. Use exactly that (as the i915 driver does) instead of hard-coding a jiffy count. Signed-off-by: Jean Delvare <jdelvare@suse.de> Reviewed-by: Keith Packard <keithp@keithp.com> Reviewed-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-02-03drm/kms: Make i2c buses fasterJean Delvare2-2/+2
A udelay value of 20 leads to an I2C bus running at only 25 kbps. I2C devices can typically operate faster than this, 50 kbps should be fine for all devices (and compliant devices can always stretch the clock if needed.) FWIW, the vast majority of framebuffer drivers set udelay to 10 already. So set it to 10 in DRM drivers too, this will make EDID block reads faster. We might even lower the udelay value later if no problem is reported. Signed-off-by: Jean Delvare <jdelvare@suse.de> Acked-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Cc: Keith Packard <keithp@keithp.com> Reviewed-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-02-03drm/radeon/kms: remove benchmarks shorter than one pageIlija Hadzic1-6/+6
copy_blit operation works only on integral number of pages so benchmarks shorter than one page size (4K) do not make sense v2: use RADEON_GPU_PAGE_SIZE instead of "magic" 1024 number and sweep sizes between 1 * <page_size> to 16K * <page_size> doubling the size in each iteration; we get the same coverage, as in the original benchmark, but guarantee integer multiples of page size v3: add whitespace between '*' operator per review received from zajec5@gmail.com Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-02-03drm/radeon/kms: common definitions for blit copy codeIlija Hadzic3-25/+46
R600/700 and Evergreen/NI blit code have a few redundant definitions in respective .c file. Move common definitions into a separate (new) .h file. Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-02-03drm: remove master fd restriction on mode setting gettersMandeep Singh Baines1-6/+6
Its useful to be able to call the mode setting getter ioctls. Not requiring master fd, enables writing a simple program which can query the state of the video system. Since these ioctls are only "getters" there is no security or synchronization issues which would require master fd. Opening an new fd is already protected by the file permissions on the device file. Signed-off-by: Mandeep Singh Baines <msb@chromium.org> Cc: Dave Airlie <airlied@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ilija Hadzic <ihadzic@research.bell-labs.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Stephane Marchesin <marcheu@chromium.org> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-02-02drm/radeon/kms/blit: fix blit copy for very large buffersIlija Hadzic1-10/+25
Evergreen and NI blit copy was broken if the buffer maps to a rectangle whose one dimension is 16384 (max dimension allowed by these chips). In the mainline kernel, the problem is exposed only when buffers are very large (1G), but it's still a problem. The problem could be exposed for smaller buffers if anyone modifies the algorithm for rectangle construction in r600_blit_create_rect() (the reason why someone would modify that algorithm is to tune the performance of buffer moves). The root cause was in i2f() function which only operated on range between 0 and 16383. Fix this by extending the range of i2f() function to 0 to 32767. While at it improve the function so that the range can be easily extended in the future (if it becomes necessary), cleanup lines over 80 characters, and replace in-line comments with one strategic comment that explains the crux of the function. Credits to michel@daenzer.net for pointing out the root cause of the bug. v2: Fix I2F_MAX_INPUT constant definition goof and warn only once if input argument is out of range. Edit the comment a little bit to avoid some linguistic confusion and make it look better in general. Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Michel Dänzer <michel@daenzer.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-02-02drm/radeon/kms: fix TRAVIS panel setupAlex Deucher1-3/+15
Different versions of the DP to LVDS bridge chip need different panel mode settings depending on the chip version used. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=41569 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-02-02drm/radeon: fix use after free in ATRM bios reading code.Dave Airlie1-1/+2
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=45503 Reported-and-Debugged-by: mlambda@gmail.com Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-02-01drm/radeon/kms: Fix device tree linkage of DP i2c buses tooJean Delvare1-0/+1
Properly set the parent device of DP i2c buses before registering them too. Signed-off-by: Jean Delvare <jdelvare@suse.de> Reviewed-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-02-01drm/radeon: Set DESKTOP_HEIGHT register to the framebuffer (not mode) height.Michel Dänzer1-2/+2
The value of this register is transferred to the V_COUNTER register at the beginning of vertical blank. V_COUNTER is the reference for VLINE waits and goes from VIEWPORT_Y_START to VIEWPORT_Y_START+VIEWPORT_HEIGHT during scanout, so if VIEWPORT_Y_START is not 0, V_COUNTER actually went backwards at the beginning of vertical blank, and VLINE waits excluding the whole scanout area could never finish (possibly only if VIEWPORT_Y_START is larger than the length of vertical blank in scanlines). Setting DESKTOP_HEIGHT to the framebuffer height should prevent this for any kind of VLINE wait. Fixes https://bugs.freedesktop.org/show_bug.cgi?id=45329 . CC: stable@vger.kernel.org Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-02-01drm/radeon/kms: disable output polling when suspendedSeth Forshee1-0/+4
Polling the outputs when the device is suspended can result in erroneous status updates. Disable output polling during suspend to prevent this from happening. Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-02-01drm/nv50/pm: signedness bug in nv50_pm_clocks_pre()Dan Carpenter1-2/+2
calc_mclk() returns zero on success and negative on failure but clk is a u32. v2: Martin Peres: - clk should be an int, not a u32 Signed-off-by: Martin Peres <martin.peres@labri.fr> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2012-02-01drm/nouveau/gem: fix fence_sync race / oopsBen Skeggs1-2/+21
Due to a race it was possible for a fence to be destroyed while another thread was trying to synchronise with it. If this happened in the fallback non-semaphore path, it lead to the following oops due to fence->channel being NULL. BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<fa9632ce>] nouveau_fence_update+0xe/0xe0 [nouveau] *pde = a649c067 SMP Modules linked in: fuse nouveau(O) ttm(O) drm_kms_helper(O) drm(O) mxm_wmi video wmi netconsole configfs lockd bnep bluetooth rfkill ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ip6table_filter ip6_tables snd_hda_codec_realtek snd_hda_intel snd_hda_cobinfmt_misc uinput ata_generic pata_acpi pata_aet2c_algo_bit i2c_core [last unloaded: wmi] Pid: 2255, comm: gnome-shell Tainted: G O 3.2.0-0.rc5.git0.1.fc17.i686 #1 System manufacturer System Product Name/M2A-VM EIP: 0060:[<fa9632ce>] EFLAGS: 00010296 CPU: 1 EIP is at nouveau_fence_update+0xe/0xe0 [nouveau] EAX: 00000000 EBX: ddfc6dd0 ECX: dd111580 EDX: 00000000 ESI: 00003e80 EDI: dd111580 EBP: dd121d00 ESP: dd121ce8 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Process gnome-shell (pid: 2255, ti=dd120000 task=dd111580 task.ti=dd120000) Stack: 7dc86c76 00000000 00003e80 ddfc6dd0 00003e80 dd111580 dd121d0c fa96371f 00000000 dd121d3c fa963773 dd111580 01000246 000ec53d 00000000 ddfc6dd0 00001f40 00000000 ddfc6dd0 00000010 dc7df840 dd121d6c fa9639a0 00000000 Call Trace: [<fa96371f>] __nouveau_fence_signalled+0x1f/0x30 [nouveau] [<fa963773>] __nouveau_fence_wait+0x43/0xd0 [nouveau] [<fa9639a0>] nouveau_fence_sync+0x1a0/0x1c0 [nouveau] [<fa964046>] validate_list+0x176/0x300 [nouveau] [<f7d9c9c0>] ? ttm_bo_mem_put+0x30/0x30 [ttm] [<fa964b8a>] nouveau_gem_ioctl_pushbuf+0x48a/0xfd0 [nouveau] [<c0406481>] ? die+0x31/0x80 [<f7c93d98>] drm_ioctl+0x388/0x490 [drm] [<c0406481>] ? die+0x31/0x80 [<fa964700>] ? nouveau_gem_ioctl_new+0x150/0x150 [nouveau] [<c0635c7b>] ? file_has_perm+0xcb/0xe0 [<f7c93a10>] ? drm_copy_field+0x80/0x80 [drm] [<c0564f56>] do_vfs_ioctl+0x86/0x5b0 [<c0406481>] ? die+0x31/0x80 [<c0635f22>] ? selinux_file_ioctl+0x62/0x130 [<c0554f30>] ? fget_light+0x30/0x340 [<c05654ef>] sys_ioctl+0x6f/0x80 [<c099e3a4>] syscall_call+0x7/0xb [<c0406481>] ? die+0x31/0x80 [<c0406481>] ? die+0x31/0x80 Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
2012-02-01drm/nouveau: fix typo on mxmdcb optionBen Skeggs1-1/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2012-02-01drm/nouveau/mxm: pretend to succeed, even if we can't shadow the MXM-SISBen Skeggs1-0/+9
There's at least one known case where our shadowing code is buggy, and we fail init. Until we can be confident we're doing all this correctly, lets succeed and risk crazy bios tables rather than failing for perfectly valid configs too. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2012-02-01drm/nouveau/disp: check that panel power gpio is enabled at init timeBen Skeggs2-2/+13
Reported-by: Yuriy Khomchik <homyur@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2012-01-30vmwgfx: Fix assignment in vmw_framebuffer_create_handleRyan Mallon1-1/+1
The assignment of handle in vmw_framebuffer_create_handle doesn't actually do anything useful and is incorrectly assigning an integer value to a pointer argument. It appears that this is a typo and should be dereferencing handle rather than assigning to it directly. This fixes a bug where an undefined handle value is potentially returned to user-space. Signed-off-by: Ryan Mallon <rmallon@gmail.com> Reviewed-by: Jakob Bornecrantz<jakob@vmware.com> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-01-30drm/radeon/kms: Fix device tree linkage of i2c busesJean Delvare1-0/+1
Properly set the parent device of i2c buses before registering them so that they will show at the right place in the device tree (rather than in /sys/devices directly.) Signed-off-by: Jean Delvare <jdelvare@suse.de> Cc: Dave Airlie <airlied@gmail.com> Reviewed-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-01-30drm: Pass the real error code back during GEM bo initialisationChris Wilson1-1/+1
In particular, I found I was hitting the max-file limit in the VFS, and the EFILE was being magically transformed into ENOMEM. Confusion reigns. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-01-30Revert "drm/i810: cleanup reclaim_buffers"Daniel Vetter3-13/+11
This reverts commit 87499ffdcb1c70f66988cd8febc4ead0ba2f9118. Where is that paper bag ... ah here. I've failed to take an odd interaction between my other cleanups and this reclaim_buffers patch into account and also failed to properly test it. Looks like there are more dragons and hidden trapdoors in the drm release path than actual lines of code. Until I get a clue, let's just revert this. Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-01-27gma500: Fix suspend/resume functionsRyan Mallon1-4/+4
Both the suspend and resume functions incorrectly set psbfb = to_psb_fb(NULL) outside of the loop over all of the framebuffers. Fix this by moving the assignment of psbfb inside the loop and removing the initialisation of fb. Signed-off-by: Ryan Mallon <rmallon@gmail.com> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-01-27drm/exynos: fixed pm feature for fimd module.Inki Dae1-50/+59
this patch separates fimd specific power on/off function from pm function and the pm interfaces will call that function for power on or off. and also removes unnecessary codes of resume function. Signed-off-by: Inki Dae <inki.dae@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
2012-01-27drm/exynos: fixed build dependency for DRM_EXYNOS_FIMDInki Dae1-1/+1
FB based FIMD and DRM based FIMD drivers use same hardware so with this patch, only one of them would be selected. Signed-off-by: Inki Dae <inki.dae@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
2012-01-27drm/exynos: fix build dependency for DRM_EXYNOS_HDMISeung-Woo Kim1-1/+1
DRM_EXYNOS_HDMI driver and VIDEO_SAMSUNG_S5P_TV driver should be not enabled at once because they use same HW blocks. So dependency for DRM_EXYNOS_HDMI is fixed to check VIDEO_SAMSUNG_S5P_TV=n. Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
2012-01-27drm/exynos: use release_mem_region instead of release_resourceSeung-Woo Kim1-4/+4
To make a api pair of request_mem_region and release_mem_region, release_mem_region is used instead of release_resource. Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
2012-01-26Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~keithp/linux ↵Dave Airlie14-199/+167
into drm-fixes * 'drm-intel-fixes' of git://people.freedesktop.org/~keithp/linux: (24 commits) drm/i915: fixup forcewake spinlock fallout in drpc debugfs function drm/i915: debugfs: show semaphore registers also on gen7 drm/i915: allow userspace forcewake references also on gen7 drm/i915: Re-enable gen7 RC6 and GPU turbo after resume. drm/i915: Correct debugfs printout for RC1e. Revert "drm/i915: Work around gen7 BLT ring synchronization issues." drm/i915: rip out the HWSTAM missed irq workaround drm/i915: paper over missed irq issues with force wake voodoo drm/i915: Hold gt_lock across forcewake register reads drm/i915: Hold gt_lock during reset drm/i915: Move reset forcewake processing to gen6_do_reset drm/i915: protect force_wake_(get|put) with the gt_lock drm/i915: convert force_wake_get to func pointer in the gpu reset code drm/i915: sprite init failure on pre-SNB is not a failure drm/i915: VBT Parser cleanup for eDP block drm/i915: mask transcoder select bits before setting them on LVDS drm/i915: Add Clientron E830 to the ignore LVDS list CHROMIUM: i915: Add DMI override to skip CRT initialization on ZGB drm/i915: handle 3rd pipe drm/i915: simplify pipe checking ...
2012-01-25drm/ttm: fix two regressions since move_notify changesBen Skeggs2-4/+17
Both changes in dc97b3409a790d2a21aac6e5cdb99558b5944119 cause serious regressions in the nouveau driver. move_notify() was originally able to presume that bo->mem is the old node, and new_mem is the new node. The above commit moves the call to move_notify() to after move() has been done, which means that now, sometimes, new_mem isn't the new node at all, bo->mem is, and new_mem points at a stale, possibly-just-been-killed-by-move node. This is clearly not a good situation. This patch reverts this change, and replaces it with a cleanup in the move() failure path instead. The second issue is that the call to move_notify() from cleanup_memtype_use() causes the TTM ghost objects to get passed into the driver. This is clearly bad as the driver knows nothing about these "fake" TTM BOs, and ends up accessing uninitialised memory. I worked around this in nouveau's move_notify() hook by ensuring the BO destructor was nouveau's. I don't particularly like this solution, and would rather TTM never pass the driver these objects. However, I don't clearly understand the reason why we're calling move_notify() here anyway and am happy to work around the problem in nouveau instead of breaking the behaviour expected by other drivers. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Cc: Jerome Glisse <j.glisse@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>