- 16 11月, 2011 2 次提交
-
-
由 Alex Deucher 提交于
Fixes i2c test failures when i2c_algo_bit.bit_test=1. The hw doesn't actually require a mask, so just set it to the default mask bits for r1xx-r4xx radeon ddc. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@kernel.org Cc: Jean Delvare <khali@linux-fr.org> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
Noticed by Egbert. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@kernel.org Cc: Egbert Eich <eich@suse.de> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 14 11月, 2011 2 次提交
-
-
由 Dave Airlie 提交于
I assumed all PCI buses had a bridge, but playing with qemu recently, I discovered vgaarb bug where it wasn't detecting both devices shared a bridge at the root level. Don't check for NULL, if two buses have a NULL bridge, assume they share the root bus. Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Thomas Gleixner 提交于
commit 27641c3f (drm/vblank: Add support for precise vblank timestamping) adds preempt_disable()/enable() around a spin locked section with the comments: * Disable preemption, so vblank_time_lock is held as short as * possible, even under a kernel with PREEMPT_RT patches. /* Disable preemption while holding vblank_time_lock. Do * it explicitely to guard against PREEMPT_RT kernel. Just that this has never been tested on a RT kernel which would have granted that nonsense with a might_sleep() warning because dev->vblank_time_lock is converted to a "sleeping" spinlock on RT. So this is activly wrong on RT and superflous on mainline. Remove it. Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Acked-by: NMario Kleiner <mario.kleiner@tuebingen.mpg.de> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 13 11月, 2011 1 次提交
-
-
由 Alex Deucher 提交于
I missed the combios path when I updated the atombios pm code. Reported by amarsh04 on IRC. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 11 11月, 2011 21 次提交
-
-
由 Alex Deucher 提交于
On newer chips the number of clock modes per power state varies. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
Avoid a lot of extra loops through the pm state array. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
The new power tables need to be handled differently when setting up the profiles. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
It's already called via the DPMS functions. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Inki Dae 提交于
Signed-off-by: NInki Dae <inki.dae@samsung.com> Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Randy Dunlap 提交于
Fix kconfig unmet dependency warning. BACKLIGHT_CLASS_DEVICE depends on BACKLIGHT_LCD_SUPPORT, so select the latter along with the former. warning: (DRM_RADEON_KMS && DRM_I915 && STUB_POULSBO && FB_BACKLIGHT && PANEL_SHARP_LS037V7DW01 && PANEL_ACX565AKM && USB_APPLEDISPLAY && FB_OLPC_DCON && ASUS_LAPTOP && SONY_LAPTOP && THINKPAD_ACPI && EEEPC_LAPTOP && ACPI_ASUS && ACPI_CMPC && SAMSUNG_Q10) selects BACKLIGHT_CLASS_DEVICE which has unmet direct dependencies (HAS_IOMEM && BACKLIGHT_LCD_SUPPORT) Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net> Cc: David Airlie <airlied@linux.ie> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
git://git.freedesktop.org/git/nouveau/linux-2.6由 Dave Airlie 提交于
* 'drm-nouveau-fixes' of git://git.freedesktop.org/git/nouveau/linux-2.6: drm/nouveau: Fix bandwidth calculation for DisplayPort drm/nouveau: by default use low bpp framebuffer on low memory cards drm/nv10: Change the BO size threshold determining the memory placement range. drm/nvc0: enable acceleration for nvc1 by default drm/nvc0/gr: fixup the mmio list register writes for 0xc1 drm/nvc1: hacky workaround to fix accel issues drm/nvc0/gr: fix some bugs in grctx generation drm/nvc0: enable acceleration on 0xc8 by default drm/nvc0/vram: skip disabled PBFB subunits drm/nv40/pm: fix issues on igp chipsets, which don't have memory drm/nouveau: testing the wrong variable drm/nvc0/vram: storage type 0xc3 is not compressed drm/nv50: fix stability issue on NV86. drm/nouveau: initialize chan->fence.lock before use drm/nv50/vram: fix incorrect detection of bank count on newer chipsets drm/nv50/gr: typo fix, how about we not reset fifo during graph init? drm/nv50/bios: fixup mpll programming from the init table parser drm/nouveau: fix oops if i2c bus not found in nouveau_i2c_identify() drm: make sure drm_vblank_init() has been called before touching vbl_lock
-
由 Ilija Hadzic 提交于
during the review of the fix for locks problems in drm_wait_vblank, a couple of false concerns were raised about how the drm_vblank_get and drm_vblank_put are used in this function; it turned out that the code is correct and that it cannot be simplified add a few comments to explain non-obvious flows in the code, to prevent "false alarms" in the future v2: incorporate comments received from Daniel Vetter Signed-off-by: NIlija Hadzic <ihadzic@research.bell-labs.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Dan Carpenter 提交于
radeon_benchmark_do_move() returns an int so "time" should be int too. Making it unsigned breaks the error handling. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Ilija Hadzic 提交于
drm_wait_vblank must be DRM_UNLOCKED because otherwise it will grab the drm_global_mutex and then go to sleep until the vblank event it is waiting for. That can wreck havoc in the windowing system because if one process issues this ioctl, it will block all other processes for the duration of all vblanks between the current and the one it is waiting for. In some cases it can block the entire windowing system. v2: incorporate comments received from Daniel Vetter and Michel Daenzer. v3/v4: after a lengty discussion with Daniel Vetter, it was concluded that the only thing not yet protected with locks and atomic ops is the write to dev->last_vblank_wait. It's only used in a debug file in proc, and the current code already employs no correct locking: the proc file only takes dev->struct_mutex, whereas drm_wait_vblank implicitly took the drm_global_mutex. Given all this, it's not worth bothering to try to fix the locks at this time. Signed-off-by: NIlija Hadzic <ihadzic@research.bell-labs.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Kyungmin Park 提交于
As Exynos DRM is merged at mainline. Also update the maintainer entry. Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Jesse Barnes 提交于
We restore the CRTC, encoder, and connector configurations, but if the mode set failed, the attached display may have been turned off, so we need to try set_config again to restore things to the way they were. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
Can happen when there is no DP panel attached, confusing users. Make it debug only. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@kernel.org Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Paul Bolle 提交于
slow-work got killed in commit 181a51f6. This means that since v2.6.36 there is no Kconfig symbol SLOW_WORK. Apparently selecting that symbol is a nop. Drop that select. Signed-off-by: NPaul Bolle <pebolle@tiscali.nl> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Marcin Slusarz 提交于
Nouveau, when configured with debugfs, creates debugfs files for every channel, so structure holding list of files needs to be protected from simultaneous changes by multiple threads. Without this patch it's possible to hit kernel oops in drm_debugfs_remove_files just by running a couple of xterms with looped glxinfo. Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
This hunk seems to have gotten lost when I rebased the patch. Reported-by: NSylvain Bertrand <sylvain.bertrand@gmail.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Michel Dänzer 提交于
This was only the case if the GPU reset was triggered from the CS ioctl, otherwise other processes could happily enter the CS ioctl and wreak havoc during the GPU reset. This is a little complicated because the GPU reset can be triggered from the CS ioctl, in which case we're already holding the mutex, or from other call paths, in which case we need to lock the mutex. AFAICT the mutex API doesn't allow recursive locking or finding out the mutex owner, so we need to handle this with helper functions which allow recursive locking from the same process. Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com> Reviewed-by: NJerome Glisse <jglisse@redhat.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Vinson Lee 提交于
Fixes Coverity buffer not null terminated defect. Signed-off-by: NVinson Lee <vlee@vmware.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Jakob Bornecrantz 提交于
Snooping code expects this to be the case. Signed-off-by: NJakob Bornecrantz <jakob@vmware.com> Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Jakob Bornecrantz 提交于
Signed-off-by: NJakob Bornecrantz <jakob@vmware.com> Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Jakob Bornecrantz 提交于
Signed-off-by: NJakob Bornecrantz <jakob@vmware.com> Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 10 11月, 2011 14 次提交
-
-
由 Adam Jackson 提交于
Ported from the equivalent fix in drm-intel-next: http://cgit.freedesktop.org/~keithp/linux/commit/?h=drm-intel-next&id=cd9dde44f47501394b9f0715b6a36a92aa74c0d0Signed-off-by: NAdam Jackson <ajax@redhat.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Marcin Slusarz 提交于
Framebuffer's BPP is not that important but can waste significant part of memory on low-VRAM cards. Lower it to 8bpp on < 32MB cards and to 16bpp on 64MB cards. It can still be overridden by video= option. Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Francisco Jerez 提交于
Fixes the framebuffer memory allocation failure seen on some low-memory cards, followed by X refusing to start. https://bugs.freedesktop.org/show_bug.cgi?id=42384Reported-by: NChris Paulson-Ellis <chris@edesix.com> Signed-off-by: NFrancisco Jerez <currojerez@riseup.net> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Most serious is for chips with only 1 TPC, we'd get stuck in an infinite loop. The fix here will slightly change the setup for all other chipsets too, but, it shouldn't matter too much, and this all needs figuring out and likely redone anyway. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Worked well enough for glxgears and gnome-shell at least, no reason to have this off anymore. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Dan Carpenter 提交于
memtimings is a valid pointer here, the intent was to test for kcalloc() failure. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Christoph Bumiller 提交于
Signed-off-by: NChristoph Bumiller <e0425955@student.tuwien.ac.at> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Maxim Levitsky 提交于
Confirmed to fix random hangs while running all Unegine demos on NV86. Signed-off-by: NMaxim Levitsky <maximlevitsky@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Marcin Slusarz 提交于
Fence lock needs to be initialized before any call to nouveau_channel_put because it calls nouveau_channel_idle->nouveau_fence_update which uses fence lock. BUG: spinlock bad magic on CPU#0, test/24134 lock: ffff88019f90dba8, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0 Pid: 24134, comm: test Not tainted 3.0.0-nv+ #800 Call Trace: spin_bug+0x9c/0xa3 do_raw_spin_lock+0x29/0x13c _raw_spin_lock+0x1e/0x22 nouveau_fence_update+0x2d/0xf1 nouveau_channel_idle+0x22/0xa0 nouveau_channel_put_unlocked+0x84/0x1bd nouveau_channel_put+0x20/0x24 nouveau_channel_alloc+0x4ec/0x585 nouveau_ioctl_fifo_alloc+0x50/0x130 drm_ioctl+0x289/0x361 do_vfs_ioctl+0x4dd/0x52c sys_ioctl+0x42/0x65 system_call_fastpath+0x16/0x1b It's easily triggerable from userspace. Additionally remove double initialization of chan->fence.pending. Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com> Cc: stable@kernel.org Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-