An error occurred fetching the project authors.
- 03 Oct, 2012 4 commits
-
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
These currently just call the existing ones in nouveau_drv.c, but will be extended in upcoming commits. This needed to be separated from the current code as there will be some header clashes until things are ported. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Future work will be headed in the way of separating the policy supplied by the nouveau drm module from the mechanisms provided by the driver core. There will be a couple of major classes (subdev, engine) of driver modules that have clearly defined tasks, and the further directory structure change is to reflect this. No code changes here whatsoever, aside from fixing up a couple of include file pathnames. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
- 26 Jul, 2012 1 commit
-
-
Ben Skeggs authored
These will be replaced in the near future, the code isn't yet stable enough for this merge window however. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
- 20 Jul, 2012 1 commit
-
-
Daniel Vetter authored
All leftover users either haven't set DRIVER_HAVE_DMA, in which case this will never be called, or use the drm_core implementation. Call that directly in the only callsite. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
- 24 May, 2012 3 commits
-
-
Ben Skeggs authored
Been tested on each major revision that's relevant here, but I'm sure there are still bugs waiting to be ironed out. This is a *very* invasive change. There's a couple of pieces left that I don't like much (eg. other engines using fifo_priv for the channel count), but that's an artefact of there being a master channel list still. This is changing, slowly. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
All the places this stuff is actually needed tends to be chipset-specific anyway, so we're able to just inline the register bashing instead. The parts of the common code that still directly touch PFIFO temporarily have conditionals, these will be removed in subsequent commits that will refactor the fifo modules into engine modules like graph/mpeg etc. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
- 23 May, 2012 1 commit
-
-
Dave Airlie authored
This adds prime->fd and fd->prime support to nouveau, it passes the SG object to TTM, and then populates the GART entries using it. v2: add stubbed kmap + use new function to fill out pages array for faulting + add reimport test. Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
- 13 Mar, 2012 2 commits
-
-
Jean Delvare authored
Module parameter descriptions don't take a trailing \n, otherwise it breaks formatting of modinfo's output. Also remove trailing space. Signed-off-by:
Jean Delvare <jdelvare@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Also, display detected memory type in logs - though, we don't even try to detect this yet. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
- 01 Feb, 2012 1 commit
-
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
- 21 Dec, 2011 7 commits
-
-
Ben Skeggs authored
The DCB table provided by the VBIOS on most MXM chips has a number of entries which either need to be disabled, or modified according to the MXM-SIS Output Device Descriptors. The x86 vbios code usually takes care of this for us, however, with the large number of laptops now with switchable graphics or optimus, a lot of the time nouveau is responsible for POSTing the card instead - leaving some fun situations like, plugging in a monitor and having nouveau decide 3 connectors actually just got plugged in.. No MXM-SIS fetching methods implemented yet. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Known to fix some serious issues with hibernate on a couple of systems. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Marcin Slusarz authored
Signed-off-by:
Marcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Maxim Levitsky authored
PDISP doesn't like it when disabled CRTCs are poked. Fixes external output not coming to life when it has cursor on. https://bugs.freedesktop.org/show_bug.cgi?id=41608Signed-off-by:
Maxim Levitsky <maximlevitsky@gmail.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Maxim Levitsky authored
Otherwice code that responsible for idling the card can't work. BIOS init tables are supposed to init the clocks to correct values, so that shouldn't cause any problems (we don't reclock by default anyway) Signed-off-by:
Maxim Levitsky <maximlevitsky@gmail.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Maxim Levitsky authored
Because doing polling while hardware is disabled is a bad idea... Signed-off-by:
Maxim Levitsky <maximlevitsky@gmail.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
- 30 Nov, 2011 1 commit
-
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
- 11 Nov, 2011 1 commit
-
-
Arjan van de Ven authored
From fdf1fdebaa00f81de18c227f32f8074c8b352d50 Mon Sep 17 00:00:00 2001 From: Arjan van de Ven <arjan@linux.intel.com> Date: Sun, 30 Oct 2011 19:06:07 -0700 Subject: [PATCH] drm: Make the per-driver file_operations struct const The DRM layer keeps a copy of struct file_operations inside its big driver struct... which prevents it from being consistent and static. For consistency (and the general security objective of having such things static), it's desirable to get this fixed. This patch splits out the file_operations field to its own struct, which is then "static const", and just stick a pointer to this into the driver struct, making it more consistent with how the rest of the kernel does this. Signed-off-by:
Arjan van de Ven <arjan@linux.intel.com> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
- 31 Oct, 2011 1 commit
-
-
Paul Gortmaker authored
So that we don't get build failures once the implicit module.h presence is removed. Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
- 20 Sep, 2011 1 commit
-
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
- 24 Jul, 2011 1 commit
-
-
Ben Skeggs authored
It may not be necessary to fail in certain cases (such as failing to idle) on module unload, whereas on suspend it's important to ensure a consistent state can be restored on resume. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
- 23 Jun, 2011 5 commits
-
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
The ability to use NVIDIA's fuc has been retained *temporarily* in order to better debug any issues that may be lingering in our initial attempt at writing this ucode. Once I'm fairly confident we're okay, it'll be removed. There's a number of things not implemented by this fuc currently, but most of it is sets of state that our context setup would not have used anyway. No doubt we'll find out what they're for at some point, and implement it if required. This has been tested on 0xc0/0xc4 thus far, and from what I could tell it worked as well as NVIDIA's. It's also been tested on 0xc1, but even with NVIDIA's fuc that chipset doesn't work correctly with nouveau yet. 0xc3/0xc8/0xce should in theory be supported too, but I don't have the hardware to check that. There's no doubt numerous bugs to squash yet, please report any! Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Until we know these should work properly, would much rather default to noaccel than risk giving people corruption/hangs out of the box.. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
- 16 May, 2011 4 commits
-
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
This needs a massive cleanup, but to catch bugs from the interface changes vs the engine code cleanup, this will be done later. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
There's lots of more-or-less independant engines present on NVIDIA GPUs these days, and we generally want to perform the same operations on them. Implementing new ones requires hooking into lots of different places, the aim of this work is to make this simpler and cleaner. NV84:NV98 PCRYPT moved over as a test. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
- 07 Feb, 2011 1 commit
-
-
Dave Airlie authored
This abstracts the pci/platform interface out a step further, we can go further but this is far enough for now to allow USB to be plugged in. The drivers now just call the init code directly for their device type. Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
- 26 Jan, 2011 1 commit
-
-
Torben Hohn authored
The -rt patches change the console_semaphore to console_mutex. As a result, a quite large chunk of the patches changes all acquire/release_console_sem() to acquire/release_console_mutex() This commit makes things use more neutral function names which dont make implications about the underlying lock. The only real change is the return value of console_trylock which is inverted from try_acquire_console_sem() This patch also paves the way to switching console_sem from a semaphore to a mutex. [akpm@linux-foundation.org: coding-style fixes] [akpm@linux-foundation.org: make console_trylock return 1 on success, per Geert] Signed-off-by:
Torben Hohn <torbenh@gmx.de> Cc: Thomas Gleixner <tglx@tglx.de> Cc: Greg KH <gregkh@suse.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- 05 Jan, 2011 1 commit
-
-
Dave Airlie authored
We need to track the state of the switch in drivers, so that after s/r we don't resume the card we've explicitly switched off before. Also don't allow a userspace open to occur if we've switched the gpu off. Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
- 08 Dec, 2010 2 commits
-
-
Ben Skeggs authored
As of this commit, it's guaranteed that if an object is in VRAM that its GPU virtual address will be constant. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Francisco Jerez authored
There have been reports of PFIFO cache errors during context take down (fdo bug 31637). They are caused by some GPU objects being taken out while the channel is still potentially processing commands. Make sure that all the previous rendering has landed before releasing a GPU object. Reported-by:
Grzesiek Sójka <pld@pfu.pl> Reported-by:
Patrice Mandin <patmandin@gmail.com> Signed-off-by:
Francisco Jerez <currojerez@riseup.net> Acked-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
- 03 Dec, 2010 1 commit
-
-
Ben Skeggs authored
Reviewed-by:
Francisco Jerez <currojerez@riseup.net> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-