On Wed, Apr 27, 2011 at 3:34 PM, Aurelien Jarno wrote:
> ... instead of comparing with DMA_ERROR_CODE, which will only work on
> powerpc/sparc/x86.
>
So you wrote a patch that breaks it everwhere?
You might want to actually boot this sort of thing before I do, or
read the interface for pci_dma_m
On Mit, 2011-04-27 at 16:10 +1000, christopher.halse.rog...@canonical.com wrote:
> From: Christopher James Halse Rogers
>
> This is the least-bad behaviour. It means that we signal the
> vblank event before it actually happens, but since we're disabling
> vblanks there's no guarantee that it wil
On Mit, 2011-04-27 at 16:10 +1000, christopher.halse.rog...@canonical.com wrote:
> From: Christopher James Halse Rogers
>
> Signed-off-by: Christopher James Halse Rogers
>
> ---
> drivers/gpu/drm/drm_irq.c | 39 ---
> 1 files changed, 16 insertions(+), 23
On Mit, 2011-04-27 at 16:10 +1000, christopher.halse.rog...@canonical.com wrote:
> From: Christopher James Halse Rogers
>
> After emitting all the waiting vblank events no-one should hold
> a vblank reference. Emit a warning if this is not the case.
>
> Signed-off-by: Christopher James Halse Ro
On Wed, 2011-04-27 at 10:36 +0200, Michel Dänzer wrote:
> On Mit, 2011-04-27 at 16:10 +1000, christopher.halse.rog...@canonical.com
> wrote:
> > From: Christopher James Halse Rogers
> >
> >
> > Signed-off-by: Christopher James Halse Rogers
> >
> > ---
> > drivers/gpu/drm/drm_irq.c | 39 +++
On Wed, 2011-04-27 at 10:32 +0200, Michel Dänzer wrote:
> On Mit, 2011-04-27 at 16:10 +1000, christopher.halse.rog...@canonical.com
> wrote:
> > From: Christopher James Halse Rogers
> >
> >
> > This is the least-bad behaviour. It means that we signal the
> > vblank event before it actually hap
On Mit, 2011-04-27 at 18:48 +1000, Christopher James Halse Rogers
wrote:
> On Wed, 2011-04-27 at 10:36 +0200, Michel Dänzer wrote:
> > On Mit, 2011-04-27 at 16:10 +1000, christopher.halse.rog...@canonical.com
> > wrote:
> > > From: Christopher James Halse Rogers
> > >
> > >
> > > Signed-off-by
On Mit, 2011-04-27 at 18:58 +1000, Christopher James Halse Rogers
wrote:
> On Wed, 2011-04-27 at 10:32 +0200, Michel Dänzer wrote:
> > On Mit, 2011-04-27 at 16:10 +1000, christopher.halse.rog...@canonical.com
> > wrote:
> > > From: Christopher James Halse Rogers
> > >
> > >
> > > This is the l
On Wed, 2011-04-27 at 11:08 +0200, Michel Dänzer wrote:
> On Mit, 2011-04-27 at 18:58 +1000, Christopher James Halse Rogers
> wrote:
> > On Wed, 2011-04-27 at 10:32 +0200, Michel Dänzer wrote:
> > > On Mit, 2011-04-27 at 16:10 +1000, christopher.halse.rog...@canonical.com
> > > wrote:
> > > > Fro
https://bugs.freedesktop.org/show_bug.cgi?id=36596
--- Comment #3 from Michel Dänzer 2011-04-27 03:28:43 PDT
---
(In reply to comment #3)
> With compiz, making a new window or resizing a window makes the framerate drop
> to 2 fps for about 5 or 6 seconds.
Does that involve wobbly windows or any
https://bugs.freedesktop.org/show_bug.cgi?id=36554
--- Comment #4 from Sven Arvidsson 2011-04-27 04:13:20 PDT ---
(In reply to comment #3)
> What kernel version do you have ? The game runs fine for me on Fedora 14,
> while
> on Fedora 15, I used to have Scott's issues.
2.6.38.2 at the moment, b
On 04/25/11 16:53, Jerome Glisse wrote:
> On Sun, Apr 24, 2011 at 5:24 AM, Anders Eriksson
> wrote:
> > On 03/18/11 09:55, Anders Eriksson wrote:
> >> On 03/16/11 21:09, Anders Eriksson wrote:
> >> > On 03/15/11 22:46, Alex Deucher wrote:
> >> > > Try booting with radeon.audio=0 on 2.6.38rc,
Hi Jesse,
I like it. It's a bit of a chicken-egg api design problem, but if a
proof-of-concept
implementation exists for an embedded chip plus something to check whether
it's good enough to implement Xv on ancient hw (intel overlay or for the qemu
kms driver, if that could do this), that should be
On Wed, Apr 27, 2011 at 8:19 AM, Daniel Vetter wrote:
> Hi Jesse,
>
> I like it. It's a bit of a chicken-egg api design problem, but if a
> proof-of-concept
> implementation exists for an embedded chip plus something to check whether
> it's good enough to implement Xv on ancient hw (intel overlay
On Wed, Apr 27, 2011 at 3:32 PM, Jerome Glisse wrote:
> On Wed, Apr 27, 2011 at 8:19 AM, Daniel Vetter wrote:
>> float scale_x, scale_y;
>
> No float in kernel. Would have to use fixed point.
Bleh, of course ;-) 32bit with a 16 bit shift should be good enough
for all scaling needs
-Daniel
--
Da
On Wed, 27 Apr 2011 16:27:55 +0200, Daniel Vetter wrote:
> On Wed, Apr 27, 2011 at 3:32 PM, Jerome Glisse wrote:
> > On Wed, Apr 27, 2011 at 8:19 AM, Daniel Vetter wrote:
> >> float scale_x, scale_y;
> >
> > No float in kernel. Would have to use fixed point.
>
> Bleh, of course ;-) 32bit with a
On Wed, Apr 27, 2011 at 4:34 PM, Chris Wilson wrote:
> Or just specify the source size. You already know the output size...
Hm, I've thought that x, y are fb offsets, not width/height of the
target ... Maybe we need that,
too?
-Daniel
--
Daniel Vetter
daniel.vet...@ffwll.ch - +41 (0) 79 364 57 4
On Wed, Apr 27, 2011 at 03:34:42PM +0100, Chris Wilson wrote:
> On Wed, 27 Apr 2011 16:27:55 +0200, Daniel Vetter wrote:
> > On Wed, Apr 27, 2011 at 3:32 PM, Jerome Glisse wrote:
> > > On Wed, Apr 27, 2011 at 8:19 AM, Daniel Vetter wrote:
> > >> float scale_x, scale_y;
> > >
> > > No float in ke
On Apr 27, 2011, at 10:58 AM, dri-devel-requ...@lists.freedesktop.org
wrote:
Message: 5
Date: Wed, 27 Apr 2011 10:38:14 +0200
From: Michel D?nzer
Subject: Re: [PATCH 2/3] drm: Warn if vblank state has become
inconsistent.
To: christopher.halse.rog...@canonical.com
Cc: dri-devel@lists.fr
https://bugs.freedesktop.org/show_bug.cgi?id=36527
--- Comment #12 from Sven Arvidsson 2011-04-27 09:27:07 PDT ---
Yes, this seems to have finally fixed it!
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are th
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_encoders.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c
b/drivers/gpu/drm/radeon/radeon_encoders.c
index ba39331..3372a22 100644
--- a/drivers/gpu/drm/radeon/rade
https://bugzilla.kernel.org/show_bug.cgi?id=34022
Summary: Kernel OOPS when switching off Radeon using
vgaswitcheroo
Product: Drivers
Version: 2.5
Kernel Version: 2.6.38
Platform: All
OS/Version: Linux
Tree: M
https://bugzilla.kernel.org/show_bug.cgi?id=34022
blazej.bu...@gmail.com changed:
What|Removed |Added
Summary|Kernel OOPS when switching |Kernel OOPS turning on
https://bugzilla.kernel.org/show_bug.cgi?id=33912
--- Comment #4 from Vish 2011-04-27 20:21:36 ---
Created an attachment (id=55621)
--> (https://bugzilla.kernel.org/attachment.cgi?id=55621)
dmesg
It froze again(Apr 27 20:42:06) with same gdb, did a
$ echo t > /proc/sysrq-trigger
And then
https://bugzilla.kernel.org/show_bug.cgi?id=33912
--- Comment #5 from Vish 2011-04-27 20:24:10 ---
Created an attachment (id=55631)
--> (https://bugzilla.kernel.org/attachment.cgi?id=55631)
kern.log
kern.log Contains today's freeze, Apr 27 20:42:06 , and the previous one Apr 25
01:45:20
-
https://bugzilla.kernel.org/show_bug.cgi?id=33912
--- Comment #6 from Vish 2011-04-27 20:25:14 ---
Created an attachment (id=55641)
--> (https://bugzilla.kernel.org/attachment.cgi?id=55641)
syslog
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are re
On Wed, 27 Apr 2011 14:19:05 +0200
Daniel Vetter wrote:
> Hi Jesse,
>
> I like it. It's a bit of a chicken-egg api design problem, but if a
> proof-of-concept
> implementation exists for an embedded chip plus something to check whether
> it's good enough to implement Xv on ancient hw (intel over
https://bugzilla.kernel.org/show_bug.cgi?id=34022
--- Comment #2 from blazej.bu...@gmail.com 2011-04-27 19:47:07 ---
Sorry for spaming.. Ok. Last try:
I'm using vgaswitcheroo on T500 (Radeon/i915) and after upgrading kernel to
2.6.38 OOPS started to occur. Previously (2.6.37) everything work
https://bugzilla.kernel.org/show_bug.cgi?id=34022
Rafael J. Wysocki changed:
What|Removed |Added
CC||flor...@mickler.org,
Nothing major, everyone must be on Easter holidays, the i915 one is
actually a fix for dual-gpu laptops where i915 caused radeon to do
something bad, the Kconfig one is because I see distros don't enable this
and its really needed for dual-gpu functionality to work at all.
Otherwise, just a co
We're often using a shared interrupt line for nouveau, so we have
to be prepared that it could be called at any point in time. If
we've suspended the device via vga switcheroo and get a stray
interrupt on the line from another device, we'll read back -1 from
the device and head down all sorts of s
On Wed, 2011-04-27 at 23:20 -0600, Alex Williamson wrote:
> We're often using a shared interrupt line for nouveau, so we have
> to be prepared that it could be called at any point in time. If
> we've suspended the device via vga switcheroo and get a stray
> interrupt on the line from another devic
On 19 April 2011 16:35, Brian wrote:
>>> Pushed, thanks.
>>
>> Can you know commit this one that fixes missing files in the generated
>> tarball
>> so that one can build mesa out of the tarball?
>> Thx
>
> I'll commit it soon. Thanks.
Hi
The following patch fix tarball creation again (removed fi
On Wed, Apr 27, 2011 at 11:12 PM, Jesse Barnes wrote:
> On Wed, 27 Apr 2011 14:19:05 +0200 Daniel Vetter wrote:
>> Imo the real problem with formats is stride restrictions and other hw
>> restrictions (tiling, ...).
>> ARM/v4l people seem to want that to be in the kernel so that they can
>> e.g.
On Mon, Apr 25, 2011 at 9:13 PM, Shane O'Connell wrote:
> Hi all,
> I'm having problems getting the HDMI output of my motherboard working
> with a Samsung TV. The motherboard is an MSI 785GM-P45 with an AMD
> 785G chipset with an onboard Radeon HD 4200. I can see the desktop on
> the TV, but the e
From: Christopher James Halse Rogers
This is the least-bad behaviour. It means that we signal the
vblank event before it actually happens, but since we're disabling
vblanks there's no guarantee that it will *ever* happen otherwise.
This prevents GL applications which use WaitMSC from hanging
in
From: Christopher James Halse Rogers
After emitting all the waiting vblank events no-one should hold
a vblank reference. Emit a warning if this is not the case.
Signed-off-by: Christopher James Halse Rogers
---
drivers/gpu/drm/drm_irq.c |1 +
1 files changed, 1 insertions(+), 0 deletions(
From: Christopher James Halse Rogers
Signed-off-by: Christopher James Halse Rogers
---
drivers/gpu/drm/drm_irq.c | 39 ---
1 files changed, 16 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 72407fa..
... instead of comparing with DMA_ERROR_CODE, which will only work on
powerpc/sparc/x86.
Signed-off-by: Aurelien Jarno
---
drivers/gpu/drm/nouveau/nouveau_sgdma.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
b/drivers/gpu/drm
... instead of comparing with DMA_ERROR_CODE, which will only work on
powerpc/sparc/x86.
Signed-off-by: Aurelien Jarno
---
drivers/gpu/drm/radeon/radeon_gart.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon
On Wed, Apr 27, 2011 at 3:34 PM, Aurelien Jarno wrote:
> ... instead of comparing with DMA_ERROR_CODE, which will only work on
> powerpc/sparc/x86.
>
So you wrote a patch that breaks it everwhere?
You might want to actually boot this sort of thing before I do, or
read the interface for pci_dma_m
On Mit, 2011-04-27 at 16:10 +1000, christopher.halse.rogers at canonical.com
wrote:
> From: Christopher James Halse Rogers canonical.com>
>
> This is the least-bad behaviour. It means that we signal the
> vblank event before it actually happens, but since we're disabling
> vblanks there's no gu
On Mit, 2011-04-27 at 16:10 +1000, christopher.halse.rogers at canonical.com
wrote:
> From: Christopher James Halse Rogers canonical.com>
>
> Signed-off-by: Christopher James Halse Rogers canonical.com>
> ---
> drivers/gpu/drm/drm_irq.c | 39 ---
> 1 files
On Mit, 2011-04-27 at 16:10 +1000, christopher.halse.rogers at canonical.com
wrote:
> From: Christopher James Halse Rogers canonical.com>
>
> After emitting all the waiting vblank events no-one should hold
> a vblank reference. Emit a warning if this is not the case.
>
> Signed-off-by: Christo
nct action from emitting the vblank event, which is why I left it
out. I'd be happy enough to have it as a part of drm_emit_vblank_event,
though.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110427/07e6dded/attachment.pgp>
an laser-like focus on the single monitor case, too. :/
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110427/4035b75e/attachment-0001.pgp>
On Mit, 2011-04-27 at 18:48 +1000, Christopher James Halse Rogers
wrote:
> On Wed, 2011-04-27 at 10:36 +0200, Michel D?nzer wrote:
> > On Mit, 2011-04-27 at 16:10 +1000, christopher.halse.rogers at
> > canonical.com wrote:
> > > From: Christopher James Halse Rogers > > canonical.com>
> > >
> >
On Mit, 2011-04-27 at 18:58 +1000, Christopher James Halse Rogers
wrote:
> On Wed, 2011-04-27 at 10:32 +0200, Michel D?nzer wrote:
> > On Mit, 2011-04-27 at 16:10 +1000, christopher.halse.rogers at
> > canonical.com wrote:
> > > From: Christopher James Halse Rogers > > canonical.com>
> > >
> >
e monitors back on will result in a vblank irq,
which will kick everything back into correct operation.
I've not managed to trigger this on my radeon system in the same way as
my intel systems, but I haven't stressed it as hard either.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110427/edd0bccc/attachment.pgp>
https://bugs.freedesktop.org/show_bug.cgi?id=36596
--- Comment #3 from Michel D?nzer 2011-04-27 03:28:43
PDT ---
(In reply to comment #3)
> With compiz, making a new window or resizing a window makes the framerate drop
> to 2 fps for about 5 or 6 seconds.
Does that involve wobbly windows or any
https://bugs.freedesktop.org/show_bug.cgi?id=36554
--- Comment #4 from Sven Arvidsson 2011-04-27 04:13:20 PDT ---
(In reply to comment #3)
> What kernel version do you have ? The game runs fine for me on Fedora 14,
> while
> on Fedora 15, I used to have Scott's issues.
2.6.38.2 at the moment, b
On 04/25/11 16:53, Jerome Glisse wrote:
> On Sun, Apr 24, 2011 at 5:24 AM, Anders Eriksson
> wrote:
> > On 03/18/11 09:55, Anders Eriksson wrote:
> >> On 03/16/11 21:09, Anders Eriksson wrote:
> >> > On 03/15/11 22:46, Alex Deucher wrote:
> >> > > Try booting with radeon.audio=0 on 2.6.38rc,
Hi Jesse,
I like it. It's a bit of a chicken-egg api design problem, but if a
proof-of-concept
implementation exists for an embedded chip plus something to check whether
it's good enough to implement Xv on ancient hw (intel overlay or for the qemu
kms driver, if that could do this), that should be
On Wed, Apr 27, 2011 at 8:19 AM, Daniel Vetter wrote:
> Hi Jesse,
>
> I like it. It's a bit of a chicken-egg api design problem, but if a
> proof-of-concept
> implementation exists for an embedded chip plus something to check whether
> it's good enough to implement Xv on ancient hw (intel overlay
On Wed, Apr 27, 2011 at 3:32 PM, Jerome Glisse wrote:
> On Wed, Apr 27, 2011 at 8:19 AM, Daniel Vetter wrote:
>> float scale_x, scale_y;
>
> No float in kernel. Would have to use fixed point.
Bleh, of course ;-) 32bit with a 16 bit shift should be good enough
for all scaling needs
-Daniel
--
Da
On Wed, 27 Apr 2011 16:27:55 +0200, Daniel Vetter wrote:
> On Wed, Apr 27, 2011 at 3:32 PM, Jerome Glisse wrote:
> > On Wed, Apr 27, 2011 at 8:19 AM, Daniel Vetter wrote:
> >> float scale_x, scale_y;
> >
> > No float in kernel. Would have to use fixed point.
>
> Bleh, of course ;-) 32bit with a
On Wed, Apr 27, 2011 at 4:34 PM, Chris Wilson
wrote:
> Or just specify the source size. You already know the output size...
Hm, I've thought that x, y are fb offsets, not width/height of the
target ... Maybe we need that,
too?
-Daniel
--
Daniel Vetter
daniel.vetter at ffwll.ch - +41 (0) 79 364
On Wed, Apr 27, 2011 at 03:34:42PM +0100, Chris Wilson wrote:
> On Wed, 27 Apr 2011 16:27:55 +0200, Daniel Vetter wrote:
> > On Wed, Apr 27, 2011 at 3:32 PM, Jerome Glisse
> > wrote:
> > > On Wed, Apr 27, 2011 at 8:19 AM, Daniel Vetter wrote:
> > >> float scale_x, scale_y;
> > >
> > > No float
On Apr 27, 2011, at 10:58 AM, dri-devel-request at lists.freedesktop.org
wrote:
> Message: 5
> Date: Wed, 27 Apr 2011 10:38:14 +0200
> From: Michel D?nzer
> Subject: Re: [PATCH 2/3] drm: Warn if vblank state has become
> inconsistent.
> To: christopher.halse.rogers at canonical.com
> Cc: d
https://bugs.freedesktop.org/show_bug.cgi?id=36527
--- Comment #12 from Sven Arvidsson 2011-04-27 09:27:07 PDT ---
Yes, this seems to have finally fixed it!
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are th
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_encoders.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c
b/drivers/gpu/drm/radeon/radeon_encoders.c
index ba39331..3372a22 100644
--- a/drivers/gpu/drm/radeon/rade
https://bugzilla.kernel.org/show_bug.cgi?id=34022
Summary: Kernel OOPS when switching off Radeon using
vgaswitcheroo
Product: Drivers
Version: 2.5
Kernel Version: 2.6.38
Platform: All
OS/Version: Linux
Tree: M
https://bugzilla.kernel.org/show_bug.cgi?id=34022
blazej.bucko at gmail.com changed:
What|Removed |Added
Summary|Kernel OOPS when switching |Kernel OOPS turning on
https://bugzilla.kernel.org/show_bug.cgi?id=33912
--- Comment #4 from Vish 2011-04-27 20:21:36 ---
Created an attachment (id=55621)
--> (https://bugzilla.kernel.org/attachment.cgi?id=55621)
dmesg
It froze again(Apr 27 20:42:06) with same gdb, did a
$ echo t > /proc/sysrq-trigger
And then
https://bugzilla.kernel.org/show_bug.cgi?id=33912
--- Comment #5 from Vish 2011-04-27 20:24:10 ---
Created an attachment (id=55631)
--> (https://bugzilla.kernel.org/attachment.cgi?id=55631)
kern.log
kern.log Contains today's freeze, Apr 27 20:42:06 , and the previous one Apr 25
01:45:20
-
https://bugzilla.kernel.org/show_bug.cgi?id=33912
--- Comment #6 from Vish 2011-04-27 20:25:14 ---
Created an attachment (id=55641)
--> (https://bugzilla.kernel.org/attachment.cgi?id=55641)
syslog
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are re
On Wed, 27 Apr 2011 14:19:05 +0200
Daniel Vetter wrote:
> Hi Jesse,
>
> I like it. It's a bit of a chicken-egg api design problem, but if a
> proof-of-concept
> implementation exists for an embedded chip plus something to check whether
> it's good enough to implement Xv on ancient hw (intel over
https://bugzilla.kernel.org/show_bug.cgi?id=34022
--- Comment #2 from blazej.bucko at gmail.com 2011-04-27 19:47:07 ---
Sorry for spaming.. Ok. Last try:
I'm using vgaswitcheroo on T500 (Radeon/i915) and after upgrading kernel to
2.6.38 OOPS started to occur. Previously (2.6.37) everything w
https://bugzilla.kernel.org/show_bug.cgi?id=34022
Rafael J. Wysocki changed:
What|Removed |Added
CC||florian at mickler.org,
We're often using a shared interrupt line for nouveau, so we have
to be prepared that it could be called at any point in time. If
we've suspended the device via vga switcheroo and get a stray
interrupt on the line from another device, we'll read back -1 from
the device and head down all sorts of s
On Wed, Apr 27, 2011 at 05:49:50PM +1000, Dave Airlie wrote:
> On Wed, Apr 27, 2011 at 3:34 PM, Aurelien Jarno
> wrote:
> > ... instead of comparing with DMA_ERROR_CODE, which will only work on
> > powerpc/sparc/x86.
> >
>
> So you wrote a patch that breaks it everwhere?
It seems I inverted the
... instead of comparing with DMA_ERROR_CODE, which will only work on
powerpc/sparc/x86.
Signed-off-by: Aurelien Jarno
---
drivers/gpu/drm/radeon/radeon_gart.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon
... instead of comparing with DMA_ERROR_CODE, which will only work on
powerpc/sparc/x86.
Signed-off-by: Aurelien Jarno
---
drivers/gpu/drm/nouveau/nouveau_sgdma.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
b/drivers/gpu/drm
73 matches
Mail list logo
