similar to: [PATCH] gf116: remove copy1 engine

Hello, There's a long-standing bug on nouveau (this is a sample bug, but the issue has been around for a while: https://bugs.freedesktop.org/show_bug.cgi?id=85465) whereby we attempt to use the second PCOPY engine on GF116, and it is sometimes does nothing, despite mmio register 22500 saying that it's not disabled (0x22500 == 0 for this user). In the bug you can see a dump from

On Fri, Nov 21, 2014 at 1:16 AM, Andy Ritger <aritger at nvidia.com> wrote: > Hi Ilia, > > Actually 0x90b8 is different than copy engine. I'm not very familiar > with it, but 0x90b8 is an engine for performing LZO decompression as > part of performing the copy. It has a variety of limitations (e.g., > cannot handle blocklinear format), and was only in a few Fermi

Hi Ilia, Actually 0x90b8 is different than copy engine. I'm not very familiar with it, but 0x90b8 is an engine for performing LZO decompression as part of performing the copy. It has a variety of limitations (e.g., cannot handle blocklinear format), and was only in a few Fermi chips, as I understand it. It is probably easiest to just ignore it. You can distinguish this decompress engine

On Fri, Nov 21, 2014 at 01:39:55AM -0500, Ilia Mirkin wrote: > On Fri, Nov 21, 2014 at 1:16 AM, Andy Ritger <aritger at nvidia.com> wrote: > > Hi Ilia, > > > > Actually 0x90b8 is different than copy engine. I'm not very familiar > > with it, but 0x90b8 is an engine for performing LZO decompression as > > part of performing the copy. It has a variety of

On Mon, Nov 24, 2014 at 8:33 PM, Andy Ritger <aritger at nvidia.com> wrote: > On Fri, Nov 21, 2014 at 01:39:55AM -0500, Ilia Mirkin wrote: >> On Fri, Nov 21, 2014 at 1:16 AM, Andy Ritger <aritger at nvidia.com> wrote: >> > Hi Ilia, >> > >> > Actually 0x90b8 is different than copy engine. I'm not very familiar >> > with it, but 0x90b8 is

On 25/11/14 22:05, Andy Ritger wrote: > On Tue, Nov 25, 2014 at 10:57:44AM -0500, Ilia Mirkin wrote: >> On Mon, Nov 24, 2014 at 8:33 PM, Andy Ritger <aritger at nvidia.com> wrote: >>> On Fri, Nov 21, 2014 at 01:39:55AM -0500, Ilia Mirkin wrote: >>>> On Fri, Nov 21, 2014 at 1:16 AM, Andy Ritger <aritger at nvidia.com> wrote: >>>>> Hi Ilia,

https://bugs.freedesktop.org/show_bug.cgi?id=59168 Priority: medium Bug ID: 59168 Assignee: nouveau at lists.freedesktop.org Summary: [nvc3/Quadro2000M] graphic garbage/corruption/noise on resume QA Contact: xorg-team at lists.x.org Severity: major Classification: Unclassified OS: Linux (All)

On Tue, Nov 25, 2014 at 10:57:44AM -0500, Ilia Mirkin wrote: > On Mon, Nov 24, 2014 at 8:33 PM, Andy Ritger <aritger at nvidia.com> wrote: > > On Fri, Nov 21, 2014 at 01:39:55AM -0500, Ilia Mirkin wrote: > >> On Fri, Nov 21, 2014 at 1:16 AM, Andy Ritger <aritger at nvidia.com> wrote: > >> > Hi Ilia, > >> > > >> > Actually 0x90b8 is

https://bugs.freedesktop.org/show_bug.cgi?id=85465 Bug ID: 85465 Summary: X loses resources after suspend/resume Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee:

nv92 hardware has only 16 interrupt lines, while nv94 and later has 32. Accessing 0xe0c{0,4} registers on nv92 can lead to incorrect PDISP setup. This is a regression introduced with commit 9d0f5ec9ee0fd5dc5fc1cc2cf559286431e406e3 Author: Ben Skeggs <bskeggs at redhat.com> Date: Mon May 12 15:22:42 2014 +1000 gpio: split g92 class from nv50 Reported-by: estece on #nouveau Cc: stable

These chipsets include the VP2 engine which is composed of a bitstream processor (BSP) that decodes H.264 and a video processor (VP) which can do iDCT/mo-comp/etc for MPEG1/2, H.264, and VC-1. Both of these are driven by separate xtensa chips embedded in the hardware. This patch provides the mechanism to load the kernel for the xtensa chips and provide the necessary interactions to do the rest of

https://bugs.freedesktop.org/show_bug.cgi?id=51144 Bug #: 51144 Summary: significant pixel corruption in text Classification: Unclassified Product: xorg Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau

These chipsets include the VP2 engine which is composed of a bitstream processor (BSP) that decodes H.264 and a video processor (VP) which can do iDCT/mo-comp/etc for MPEG1/2, H.264, and VC-1. Both of these are driven by separate xtensa chips embedded in the hardware. This patch provides the mechanism to load the kernel for the xtensa chips and provide the necessary interactions to do the rest of

--- man/nouveau.man | 9 ++++++++- src/nv_driver.c | 8 ++++++-- 2 files changed, 14 insertions(+), 3 deletions(-) diff --git a/man/nouveau.man b/man/nouveau.man index 07d53c8..4878f24 100644 --- a/man/nouveau.man +++ b/man/nouveau.man @@ -63,7 +63,14 @@ GF100, GF104, GF106, GF108, GF110, GF114, GF116, GF117, GF119 GK104, GK106, GK107, GK110, GK208 .TP 22 .B GeForce GTX 750 -GM107 +GM107,

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- I decided to let the user still specify config=BLA=1 to override the hw disable in case we get something wrong or for double-checking stuff, but I suspect it won't really be used much. I'm not terribly fond of the message text, if you come up with something better, feel free to drop it in.

This is a recent R-devel. file.copy() is not vectorized if multiple destinations succeed: cat("foo1\n", file = "foo1") cat("foo2\n", file = "foo2") unlink(c("copy1", "copy2"), recursive = TRUE) file.copy(c("foo1", "foo2"), c("copy1", "copy2"), copy.date = TRUE) #> Error in

Hello all: I don't know what I'm doing bad, but --link-dest does not work for me: I have three directories, the original one, the first copy and the second copy I want to populate: $ ls -li total 12 1761433 drwxr-xr-x 2 envite envite 4096 dic 10 14:04 copy1 1761434 drwxr-xr-x 2 envite envite 4096 dic 11 01:18 copy2 1761432 drwxr-xr-x 2 envite envite 4096 dic 10 14:04 origin $ ls -li *

Signed-off-by: John Rowley <john.rowley08 at gmail.com> --- nvkm/engine/device/nve0.c | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/nvkm/engine/device/nve0.c b/nvkm/engine/device/nve0.c index 964c183..6e72f9c 100644 --- a/nvkm/engine/device/nve0.c +++ b/nvkm/engine/device/nve0.c @@ -208,6 +208,41 @@ nve0_identify(struct nouveau_device *device)

Only tested on nvf1, was advised to enable on all. Signed-off-by: John Rowley <john.rowley08 at gmail.com> --- nvkm/engine/device/nve0.c | 6 ------ 1 file changed, 6 deletions(-) diff --git a/nvkm/engine/device/nve0.c b/nvkm/engine/device/nve0.c index 6e72f9c..459099e 100644 --- a/nvkm/engine/device/nve0.c +++ b/nvkm/engine/device/nve0.c @@ -201,11 +201,9 @@ nve0_identify(struct

Full piglit run with this patch: http://people.freedesktop.org/~mslusarz/chan_owners.txt This patch covers only a small subset of all error messages, so: Not-yet-signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> Comments? Ideas? (This commit depends on this one: http://people.freedesktop.org/~mslusarz/0001-drm-nouveau-split-fifo-interrupt-handler.patch ) ---