- 05 4月, 2011 6 次提交
-
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 David Dillow 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Marcin Slusarz 提交于
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=35135 BUG: unable to handle kernel NULL pointer dereference at 000002d8 IP: [<f83694af>] nv04_dfp_restore+0x7f/0xd0 [nouveau] (...) Call Trace: [<f8372208>] nv04_display_destroy+0xa8/0x140 [nouveau] [<f830344a>] nouveau_unload+0x2a/0x160 [nouveau] [<f80d98fb>] drm_put_dev+0xbb/0x1b0 [drm] [<f8301025>] nouveau_pci_remove+0x15/0x20 [nouveau] [<c1292ad4>] pci_device_remove+0x44/0xf0 [<c13339d1>] __device_release_driver+0x51/0xb0 [<c133401f>] driver_detach+0x8f/0xa0 [<c13338a3>] bus_remove_driver+0x63/0xa0 [<c13340a9>] driver_unregister+0x49/0x80 [<c1182f84>] ? sysfs_remove_file+0x14/0x20 [<c1292bb2>] pci_unregister_driver+0x32/0x90 [<c109b1da>] ? __stop_machine+0x5a/0x70 [<f80d3f93>] drm_exit+0x83/0x90 [drm] [<f837875d>] nouveau_exit+0x1b/0x8be [nouveau] [<c1087b5b>] sys_delete_module+0x13b/0x1f0 [<c1104c3e>] ? do_munmap+0x1fe/0x280 [<c1104780>] ? arch_unmap_area_topdown+0x0/0x20 [<c15096f4>] syscall_call+0x7/0xb Reported-by: NFrancesco Marella <francesco.marella@gmail.com> Tested-by: NFrancesco Marella <francesco.marella@gmail.com> Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com> [ currojerez@riseup.net: No need to spam the logs in that case, an unbound LVDS encoder is not an error. ] Signed-off-by: NFrancisco Jerez <currojerez@riseup.net> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Emil Velikov 提交于
Perf tables v 1.2 and 1.3 (seen on Geforce FX/ 5) are not long enough to store the voltage label/id v2 - Remove comment from the code Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Roy Spliet 提交于
In line with envytools, verified on 4 or 5 BIOS'es. Signed-off-by: NBen Skeggs <bskeggs@redhat.com> Signed-off-by: NRoy Spliet <r.spliet@student.tudelft.nl>
-
- 23 3月, 2011 2 次提交
-
-
由 Matthew Garrett 提交于
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: NMatthew 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: NBen 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: NSedat Dilek <sedat.dilek@googlemail.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Matthew Garrett 提交于
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: NMatthew 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: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 14 3月, 2011 7 次提交
-
-
由 Marcin Slusarz 提交于
Commit 21e86c1c ("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: NMarcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
-
由 Ben Skeggs 提交于
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: 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>
-
由 Marcin Slusarz 提交于
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: NMarcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: NMaarten Maathuis <madman2003@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Appears to be fixed with commit: "drm/nv50-nvc0: make sure vma is definitely unmapped when destroying bo" Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 08 3月, 2011 2 次提交
-
-
由 Ben Skeggs 提交于
The per-vm mutex doesn't prevent this completely, a flush coming from the BAR VM could potentially happen at the same time as one for the channel VM. Not to mention that if/when we get per-client/channel VM, this will happen far more frequently. Signed-off-by: NBen Skeggs <bskeggs@redhat.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Ben Skeggs 提交于
TTM assumes an error condition from man->func->get_node() means that something went horribly wrong, and causes it to bail. The driver is supposed to return 0, and leave mm_node == NULL to signal that it couldn't allocate any memory. Signed-off-by: NBen Skeggs <bskeggs@redhat.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 04 3月, 2011 1 次提交
-
-
由 Ben Skeggs 提交于
The nv30/nv40 3d driver is about to start using DMA_FENCE from the 3D object which, it turns out, doesn't like its DMA object to not be aligned to a 4KiB boundary. Signed-off-by: NBen Skeggs <bskeggs@redhat.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 28 2月, 2011 1 次提交
-
-
由 Ben Skeggs 提交于
Somehow fixes a misrendering + hang at GDM startup on my NVA8... My first guess would have been stale TLB entries laying around that a new bo then accidentally inherits. That doesn't make a great deal of sense however, as when we mapped the pages for the new bo the TLBs would've gotten flushed anyway. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 25 2月, 2011 21 次提交
-
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
The immediate benefit of doing this is that on NV50 and up, the GPU virtual address of any buffer is now constant, regardless of what memtype they're placed in. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
This structure will also be used for GART in the near future. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
This adds a table of known nvc0 memtypes, and modifies the validity check to allow any non-compressed type. Support for Z compression will come at a later point. 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 提交于
Upcoming patches are going to enable full support for buffers that keep a constant GPU virtual address whenever they're validated for use by the GPU. In order for this to work properly while keeping support for large pages, we need to know if it's ever going to be possible for a buffer to end up in GART, and if so, disable large pages for the buffer's VMA. This is a new restriction that's not present in earlier kernel's, but should not break userspace as the current code never attempts to validate buffers into a memtype other than it was created with. 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 提交于
'mappable' isn't really used at all, nor is it necessary anymore as the bo code is capable of moving buffers to mappable vram as required. 'no_vm' isn't necessary anymore either, any places that don't want to be mapped into a GPU address space should allocate the VRAM directly instead. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Benjamin Franzke 提交于
Assign correct event when initializing nouveau_page_flip_state. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Marcin Slusarz 提交于
Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Marcin Slusarz 提交于
The code was supposed to print registers around 0x405018 (which is read earlier), not 0x405818. Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com> 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 提交于
The hw doesn't really appear to be designed to be used the way we have to use it due to DRI2's design. This leads us to having to keep the flipped fb support active at all times. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Also imports a couple of helper functions that'll be used to implement page flipping in the following commits.. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Just a cleanup, to avoid duplicating parts of nv50_crtc.c's code in the page flipping routines. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-