On Fri, Aug 30, 2013 at 11:58 AM, Ben Skeggs wrote:
> On Fri, Aug 30, 2013 at 11:10 AM, Ilia Mirkin wrote:
>> On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs wrote:
>>> On Thu, Aug 29, 2013 at 3:00 PM, Ilia Mirkin
>>> wrote:
>>>> On Thu, Aug 29, 2013 at 12
On Fri, Aug 30, 2013 at 11:10 AM, Ilia Mirkin wrote:
> On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs wrote:
>> On Thu, Aug 29, 2013 at 3:00 PM, Ilia Mirkin wrote:
>>> On Thu, Aug 29, 2013 at 12:45 AM, Ben Skeggs wrote:
>>>> On Thu, Aug 29, 2013 at 12:20 PM, Ilia Mir
On Sun, Aug 11, 2013 at 7:35 PM, Benjamin Herrenschmidt
wrote:
> On Sun, 2013-08-11 at 11:02 +0200, Maarten Lankhorst wrote:
>
>> > diff --git a/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c
>> > b/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c
>> > index 5c7433d..c314a5f 100644
>> > ---
On Thu, Aug 29, 2013 at 3:00 PM, Ilia Mirkin wrote:
> On Thu, Aug 29, 2013 at 12:45 AM, Ben Skeggs wrote:
>> On Thu, Aug 29, 2013 at 12:20 PM, Ilia Mirkin
>> wrote:
>>> On Wed, Aug 28, 2013 at 8:07 PM, Ben Skeggs wrote:
>>>> On Wed, Aug 28, 2013 a
On Thu, Aug 29, 2013 at 12:20 PM, Ilia Mirkin wrote:
> On Wed, Aug 28, 2013 at 8:07 PM, Ben Skeggs wrote:
>> On Wed, Aug 28, 2013 at 11:54 PM, Ilia Mirkin
>> wrote:
>>> On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach wrote:
>>>> Am Mittwoch, den 28.08.
On Wed, Aug 28, 2013 at 11:54 PM, Ilia Mirkin wrote:
> On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach wrote:
>> Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
>>> On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach wrote:
>>> > MSIs were only problemati
On Thu, Aug 29, 2013 at 12:20 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Wed, Aug 28, 2013 at 8:07 PM, Ben Skeggs skeg...@gmail.com wrote:
On Wed, Aug 28, 2013 at 11:54 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach d...@lynxeye.de wrote:
Am
On Thu, Aug 29, 2013 at 3:00 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Thu, Aug 29, 2013 at 12:45 AM, Ben Skeggs skeg...@gmail.com wrote:
On Thu, Aug 29, 2013 at 12:20 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Wed, Aug 28, 2013 at 8:07 PM, Ben Skeggs skeg...@gmail.com wrote:
On Wed
On Sun, Aug 11, 2013 at 7:35 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Sun, 2013-08-11 at 11:02 +0200, Maarten Lankhorst wrote:
diff --git a/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c
b/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c
index 5c7433d..c314a5f 100644
On Fri, Aug 30, 2013 at 11:10 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs skeg...@gmail.com wrote:
On Thu, Aug 29, 2013 at 3:00 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Thu, Aug 29, 2013 at 12:45 AM, Ben Skeggs skeg...@gmail.com wrote:
On Thu
On Fri, Aug 30, 2013 at 11:58 AM, Ben Skeggs skeg...@gmail.com wrote:
On Fri, Aug 30, 2013 at 11:10 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs skeg...@gmail.com wrote:
On Thu, Aug 29, 2013 at 3:00 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Thu
On Fri, Aug 30, 2013 at 12:01 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Thu, Aug 29, 2013 at 9:58 PM, Ben Skeggs skeg...@gmail.com wrote:
On Fri, Aug 30, 2013 at 11:10 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs skeg...@gmail.com wrote:
On Thu
On Wed, Aug 28, 2013 at 5:50 PM, Thierry Reding
wrote:
> On Wed, Aug 28, 2013 at 02:00:44AM +0200, Lucas Stach wrote:
>> This is the first set of patches to make Nouveau work
>> on Tegra.
>
> Perhaps you should clarify that this patch series allows discrete GPUs
> to be used via Tegra's PCIe
On Wed, Aug 28, 2013 at 6:12 AM, Peter Hurley
wrote:
> This series was originally motivated by a deadlock, introduced in
> commit 1d7c71a3e2f77336df536855b0efd2dc5bdeb41b
> 'drm/nouveau/disp: port vblank handling to event interface',
> due to inverted lock order between
On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach wrote:
> This flag allows userspace to give the kernel a hint that it should use
> a non-snooped resource. To guarantee coherency at all times mappings
> into userspace are done write combined, so userspace should avoid
> reading back from those
On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach wrote:
> MSIs were only problematic on some old, broken chipsets. But now that we
> already see systems where PCI legacy interrupts are somewhat flaky, it's
> really time to move to MSIs.
>
> Signed-off-by: Lucas Stach
> ---
>
On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach d...@lynxeye.de wrote:
MSIs were only problematic on some old, broken chipsets. But now that we
already see systems where PCI legacy interrupts are somewhat flaky, it's
really time to move to MSIs.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach d...@lynxeye.de wrote:
This flag allows userspace to give the kernel a hint that it should use
a non-snooped resource. To guarantee coherency at all times mappings
into userspace are done write combined, so userspace should avoid
reading back from
On Wed, Aug 28, 2013 at 6:12 AM, Peter Hurley pe...@hurleysoftware.com wrote:
This series was originally motivated by a deadlock, introduced in
commit 1d7c71a3e2f77336df536855b0efd2dc5bdeb41b
'drm/nouveau/disp: port vblank handling to event interface',
due to inverted lock order between
On Wed, Aug 28, 2013 at 5:50 PM, Thierry Reding
thierry.red...@gmail.com wrote:
On Wed, Aug 28, 2013 at 02:00:44AM +0200, Lucas Stach wrote:
This is the first set of patches to make Nouveau work
on Tegra.
Perhaps you should clarify that this patch series allows discrete GPUs
to be used via
On Wed, Aug 28, 2013 at 11:54 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach d...@lynxeye.de wrote:
Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach d...@lynxeye.de wrote:
MSIs were only
On Thu, Aug 22, 2013 at 10:10 AM, Ilia Mirkin wrote:
> The code expects non-VRAM mem nodes to have a pages list. If that's not
> set, it will do a null deref down the line. Warn on that condition and
> return an error.
>
> See https://bugs.freedesktop.org/show_bug.cgi?id=64774
>
> Reported-by:
On Thu, Aug 22, 2013 at 10:10 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
The code expects non-VRAM mem nodes to have a pages list. If that's not
set, it will do a null deref down the line. Warn on that condition and
return an error.
See https://bugs.freedesktop.org/show_bug.cgi?id=64774
On Mon, Aug 19, 2013 at 4:59 PM, Pali Roh?r wrote:
> On Friday 16 August 2013 14:57:07 Pali Roh?r wrote:
>> In commit 77145f1cbdf8d28b46ff8070ca749bad821e0774 was
>> introduced error which cause that reclocking on nv40 not
>> working anymore. There is missing assigment of return value
>> from
On Mon, Aug 19, 2013 at 4:59 PM, Pali Rohár pali.ro...@gmail.com wrote:
On Friday 16 August 2013 14:57:07 Pali Rohár wrote:
In commit 77145f1cbdf8d28b46ff8070ca749bad821e0774 was
introduced error which cause that reclocking on nv40 not
working anymore. There is missing assigment of return
On Thu, Aug 8, 2013 at 1:16 AM, Maarten Lankhorst
wrote:
> Allocating type=0 marks the memory as free. This allows the ltcg memory to be
> allocated twice. Add a BUG_ON in core/mm.c to prevent this ever happening
> again.
> Additionally some registers were not initialized in init, this causes
On Thu, Aug 8, 2013 at 1:24 AM, Maarten Lankhorst
wrote:
> It's my megabyte, I want to use it! At this point in init
> vbios is copied over already, so there's no reason it cannot
> used to hold other data now.
I believe there's areas in here where the SBIOS/VBIOS can communicate
to the driver on
On Thu, Aug 8, 2013 at 1:24 AM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
It's my megabyte, I want to use it! At this point in init
vbios is copied over already, so there's no reason it cannot
used to hold other data now.
I believe there's areas in here where the SBIOS/VBIOS can
On Thu, Aug 8, 2013 at 1:16 AM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
Allocating type=0 marks the memory as free. This allows the ltcg memory to be
allocated twice. Add a BUG_ON in core/mm.c to prevent this ever happening
again.
Additionally some registers were not
On Tue, Jul 30, 2013 at 4:10 PM, Maarten Lankhorst
wrote:
> Op 30-07-13 04:42, Ben Skeggs schreef:
>> On Tue, Jul 23, 2013 at 11:43 PM, Maarten Lankhorst
>> wrote:
>>> Sort of fixes mmiotrace for me again, I could sear I sent a similar patch
>>> before
>&g
On Tue, Jul 23, 2013 at 11:43 PM, Maarten Lankhorst
wrote:
> Sort of fixes mmiotrace for me again, I could sear I sent a similar patch
> before
> the rework to event interface, so I guess it got reintroduced.
I don't know how/why you think this fixes anything. The interrupt
handler can't
On Tue, Jul 30, 2013 at 4:10 PM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
Op 30-07-13 04:42, Ben Skeggs schreef:
On Tue, Jul 23, 2013 at 11:43 PM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
Sort of fixes mmiotrace for me again, I could sear I sent a similar patch
On Tue, Jul 23, 2013 at 11:43 PM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
Sort of fixes mmiotrace for me again, I could sear I sent a similar patch
before
the rework to event interface, so I guess it got reintroduced.
I don't know how/why you think this fixes anything. The
On Fri, Jul 12, 2013 at 10:45 PM, Maarten Lankhorst
wrote:
> I have no idea what this bogus restriction on placement is, but it breaks
> decoding 1080p
> VDPAU at boot speed. With this patch applied I only need to bump the vdec
> clock to
> get real-time 1080p decoding. It prevents a lot of
On Fri, Jul 12, 2013 at 10:45 PM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
I have no idea what this bogus restriction on placement is, but it breaks
decoding 1080p
VDPAU at boot speed. With this patch applied I only need to bump the vdec
clock to
get real-time 1080p
On Mon, Jun 17, 2013 at 11:09 PM, Maarten Lankhorst
wrote:
> Most graphics cards nowadays have a multiple of this limit as their vram, so
> limiting GART doesn't seem to make much sense.
Pushed, thanks :)
>
> Signed-off-by: Maarten >Lnkhorst
> ---
> diff --git
On Mon, Jun 17, 2013 at 11:09 PM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
Most graphics cards nowadays have a multiple of this limit as their vram, so
limiting GART doesn't seem to make much sense.
Pushed, thanks :)
Signed-off-by: Maarten Lnkhorst
On Tue, Jun 11, 2013 at 10:17 PM, Maarten Lankhorst
wrote:
> Appears to fix the regression from "drm/nvc0/vm: handle bar tlb flushes
> internally".
> nvidia always seems to do this flush after writing values.
Thanks, patch applied.
>
> Signed-off-by: Maarten Lankhorst
> ---
> diff --git
On Wed, Jun 5, 2013 at 5:16 PM, Ilia Mirkin wrote:
> On Wed, Jun 5, 2013 at 3:05 AM, Maarten Lankhorst
> wrote:
>> Hey,
>>
>> Op 04-06-13 20:38, Ilia Mirkin schreef:
>>> On Mon, Jun 3, 2013 at 5:02 AM, Ilia Mirkin wrote:
These chipsets include the VP2 engine which is composed of a
On Tue, Jun 11, 2013 at 10:17 PM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
Appears to fix the regression from drm/nvc0/vm: handle bar tlb flushes
internally.
nvidia always seems to do this flush after writing values.
Thanks, patch applied.
Signed-off-by: Maarten Lankhorst
On Wed, Jun 5, 2013 at 5:16 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Wed, Jun 5, 2013 at 3:05 AM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
Hey,
Op 04-06-13 20:38, Ilia Mirkin schreef:
On Mon, Jun 3, 2013 at 5:02 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
These
On Fri, May 31, 2013 at 11:05 PM, Konrad Rzeszutek Wilk <
konrad.wilk at oracle.com> wrote:
> On Tue, May 28, 2013 at 08:55:29PM +0200, Sven Joachim wrote:
> > On 2013-05-26 23:09 +0200, Maarten Maathuis wrote:
> >
> > > My NV96 does not resume from suspend to ram (the screen stays black,
> magic
On Fri, May 31, 2013 at 11:05 PM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
On Tue, May 28, 2013 at 08:55:29PM +0200, Sven Joachim wrote:
On 2013-05-26 23:09 +0200, Maarten Maathuis wrote:
My NV96 does not resume from suspend to ram (the screen stays black,
magic
sysrq keys
On Mon, 2013-05-20 at 19:14 +0200, Alexander Stein wrote:
> Code refactoring in commit 8e9e3d2deacc460fbb8a4691140318f6e85e6891
> (drm/nv84/disp: move hdmi control into core) disabled HDMI audio on my
> nv84 by removing too much old code without adding it in the new one.
> This patch adds the
On Mon, 2013-05-20 at 19:14 +0200, Alexander Stein wrote:
Code refactoring in commit 8e9e3d2deacc460fbb8a4691140318f6e85e6891
(drm/nv84/disp: move hdmi control into core) disabled HDMI audio on my
nv84 by removing too much old code without adding it in the new one.
This patch adds the missing
On Mon, Apr 8, 2013 at 10:04 PM, Maarten Lankhorst <
maarten.lankhorst at canonical.com> wrote:
> Seems to make suspend slightly more reliable on my system.
>
NACK.
"Seems to", and "slightly" don't make a very good argument for this.
Likely all you've done is change the timing of certain things
On Mon, Apr 8, 2013 at 10:04 PM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
Seems to make suspend slightly more reliable on my system.
NACK.
Seems to, and slightly don't make a very good argument for this.
Likely all you've done is change the timing of certain things happening.
On Fri, Mar 29, 2013 at 7:33 AM, Peter Hurley
wrote:
> On Thu, 2013-03-28 at 16:16 +0100, Maarten Lankhorst wrote:
>> Signed-off-by: Maarten Lankhorst
>> ---
>> Oops, fixed to apply this time..
>>
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
>>
On Fri, Mar 29, 2013 at 7:33 AM, Peter Hurley pe...@hurleysoftware.com wrote:
On Thu, 2013-03-28 at 16:16 +0100, Maarten Lankhorst wrote:
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
Oops, fixed to apply this time..
diff --git
On Fri, 2013-03-22 at 14:54 -0500, Calvin Owens wrote:
> On 03/21/13 02:56, Calvin Owens wrote:
> > On 03/21/13 02:24, Calvin Owens wrote:
> >> On 03/21/13 01:59, Ben Skeggs wrote:
> >>> On Thu, 2013-03-21 at 01:34 -0500, Calvin Owens wrote:
> >>>> DRM
On Thu, 2013-03-21 at 01:34 -0500, Calvin Owens wrote:
> DRM hasn't worked on my desktop machine (GeForce 9800) with Nouveau for
> a little while (v3.9-rc1 didn't), but worked as of commit e204378 on
> Linus' tree for one boot, and subsequently always fails.
>
> After running that version, v3.6,
On Tue, 2013-02-26 at 20:02 -0800, Greg KH wrote:
> On Tue, Feb 26, 2013 at 09:35:14AM -0800, Greg KH wrote:
> > On Mon, Feb 25, 2013 at 07:45:45PM -0800, Greg KH wrote:
> > > On Mon, Feb 25, 2013 at 02:32:43PM -0800, Greg KH wrote:
> > > > On Mon, Feb 25, 2013 at 04:06:02PM +1000, Dave Airlie
On Tue, 2013-02-26 at 20:02 -0800, Greg KH wrote:
On Tue, Feb 26, 2013 at 09:35:14AM -0800, Greg KH wrote:
On Mon, Feb 25, 2013 at 07:45:45PM -0800, Greg KH wrote:
On Mon, Feb 25, 2013 at 02:32:43PM -0800, Greg KH wrote:
On Mon, Feb 25, 2013 at 04:06:02PM +1000, Dave Airlie wrote:
On Mon, Feb 04, 2013 at 10:59:28PM +0100, Maarten Lankhorst wrote:
> Op 04-02-13 22:30, Marcin Slusarz schreef:
> > 1) Lockdep thinks all nouveau subdevs belong to the same class and can be
> > locked in arbitrary order, which is not true (at least in general case).
> > Tell it to distinguish
On Mon, Feb 04, 2013 at 10:59:28PM +0100, Maarten Lankhorst wrote:
Op 04-02-13 22:30, Marcin Slusarz schreef:
1) Lockdep thinks all nouveau subdevs belong to the same class and can be
locked in arbitrary order, which is not true (at least in general case).
Tell it to distinguish subdevs by
On Sat, 2013-01-26 at 11:53 +0100, Antonio Ospite wrote:
> Hi,
>
> I am experiencing a bug with nouveau with linux-3.8-rc5, my video
> adapter is the one integrated on the MSI M3N78-VM motherboard (hence
> x86_64):
>
> 02:00.0 VGA compatible controller: NVIDIA Corporation C77 [GeForce 8200] (rev
On Sat, 2013-01-26 at 11:53 +0100, Antonio Ospite wrote:
Hi,
I am experiencing a bug with nouveau with linux-3.8-rc5, my video
adapter is the one integrated on the MSI M3N78-VM motherboard (hence
x86_64):
02:00.0 VGA compatible controller: NVIDIA Corporation C77 [GeForce 8200] (rev
a2)
On Fri, 2013-01-11 at 16:04 +0100, Maarten Lankhorst wrote:
> When a specific engine is needed that's not GR, struct nve0_fifo should be
> used,
> and the engine member should be used to select the engine.
>
> This will fail on kernels before 3.8, since no support for such engines has
> been
On Fri, 2013-01-11 at 16:04 +0100, Maarten Lankhorst wrote:
When a specific engine is needed that's not GR, struct nve0_fifo should be
used,
and the engine member should be used to select the engine.
This will fail on kernels before 3.8, since no support for such engines has
been added
On Tue, 2012-11-27 at 09:04 +0530, Sachin Kamat wrote:
> ping
>
> On 20 November 2012 11:23, Sachin Kamat wrote:
> > nouveau_ttm.h was included twice.
I've queued it in my tree, thanks!
Ben.
> >
> > Signed-off-by: Sachin Kamat
> > ---
> > drivers/gpu/drm/nouveau/nouveau_drm.c |2 --
> >
On Tue, 2012-11-27 at 09:04 +0530, Sachin Kamat wrote:
ping
On 20 November 2012 11:23, Sachin Kamat sachin.ka...@linaro.org wrote:
nouveau_ttm.h was included twice.
I've queued it in my tree, thanks!
Ben.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
On Tue, 2012-10-30 at 09:03 +0100, Mathieu Chouquet-Stringer wrote:
> On Tue, Oct 30, 2012 at 03:12:59PM +1000, Ben Skeggs wrote:
> > Not sure what's up with the hang yet, however, I noticed the issue [1]
> > which is likely causing the error messages from nouveau's i2c code.
>
On Mon, 2012-10-29 at 23:16 +0100, Antonio Ospite wrote:
> Hi,
>
> I am experiencing a bug with nouveau with linux-3.7-rc3 (and since rc1),
> my video adapter is the one integrated on the MSI M3N78-VM motherboard
> (hence x86_64):
>
> 02:00.0 VGA compatible controller: NVIDIA Corporation C77
On Tue, 2012-10-30 at 00:32 +0100, Mathieu Chouquet-Stringer wrote:
> Hi again,
>
> On Tue, Oct 30, 2012 at 09:15:59AM +1000, Ben Skeggs wrote:
> > Are you able to go back to the current master, and get me a
> > log/screenshot with "nouveau.debug=trace" appe
nks,
Ben.
>
> Note my uefi settings weren't modified during the whole thing.
>
> I've bisected the issue and git found that commit 4196fa is the one
> causing trouble (looking at the diff, it's pretty big):
>
> Author: Ben Skeggs
> Date: Tue Jul 10 14:36:38 2012 +1000
&g
On Tue, 2012-10-30 at 00:32 +0100, Mathieu Chouquet-Stringer wrote:
Hi again,
On Tue, Oct 30, 2012 at 09:15:59AM +1000, Ben Skeggs wrote:
Are you able to go back to the current master, and get me a
log/screenshot with nouveau.debug=trace appended to your kernel
options?
Hmmm I
On Mon, 2012-10-29 at 23:16 +0100, Antonio Ospite wrote:
Hi,
I am experiencing a bug with nouveau with linux-3.7-rc3 (and since rc1),
my video adapter is the one integrated on the MSI M3N78-VM motherboard
(hence x86_64):
02:00.0 VGA compatible controller: NVIDIA Corporation C77 [GeForce
On Sun, 2012-10-21 at 00:19 +0200, Marcin Slusarz wrote:
> On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote:
> > On 20.10.2012, Marcin Slusarz wrote:
> >
> > > Try this one.
> >
> > It works, now I can boot again. However, nouveau seems to be dead now.
> > The dmesg output with your
On Sun, 2012-10-21 at 00:19 +0200, Marcin Slusarz wrote:
On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote:
On 20.10.2012, Marcin Slusarz wrote:
Try this one.
It works, now I can boot again. However, nouveau seems to be dead now.
The dmesg output with your patch on top
On Fri, Sep 14, 2012 at 01:29:55PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> We noticed a plymouth bug on Fedora 18, and I then
> noticed this stupid thinko, fixing it fixed the problem
> with plymouth.
>
> Signed-off-by: Dave Airlie
Signed-off-by: Ben Skeggs
>
On Fri, Sep 14, 2012 at 01:29:55PM +1000, Dave Airlie wrote:
From: Dave Airlie airl...@redhat.com
We noticed a plymouth bug on Fedora 18, and I then
noticed this stupid thinko, fixing it fixed the problem
with plymouth.
Signed-off-by: Dave Airlie airl...@redhat.com
Signed-off-by: Ben
On Mon, Aug 27, 2012 at 04:24:02PM -0400, Adam Jackson wrote:
> On 8/23/12 7:50 PM, Dave Airlie wrote:
> >Hi guys (but mainly ajax)
> >
> >I have a bunch of EDID and quirk stuff outstanding,
> >
> >I've made a bundle on patchwork for it
> >https://patchwork.kernel.org/bundle/airlied/edid-review/
>
On Mon, Aug 27, 2012 at 04:24:02PM -0400, Adam Jackson wrote:
On 8/23/12 7:50 PM, Dave Airlie wrote:
Hi guys (but mainly ajax)
I have a bunch of EDID and quirk stuff outstanding,
I've made a bundle on patchwork for it
https://patchwork.kernel.org/bundle/airlied/edid-review/
On Wed, Aug 08, 2012 at 08:00:21AM +0200, Sven Joachim wrote:
> On 2012-08-08 07:37 +0200, Ben Skeggs wrote:
>
> > On Mon, Aug 06, 2012 at 11:38:04PM +0300, Maxim Levitsky wrote:
> >> On Sat, 2012-08-04 at 17:41 +0300, Maxim Levitsky wrote:
> >> > On Mon, 2012-07
On Mon, Aug 06, 2012 at 11:38:04PM +0300, Maxim Levitsky wrote:
> On Sat, 2012-08-04 at 17:41 +0300, Maxim Levitsky wrote:
> > On Mon, 2012-07-23 at 18:25 +0300, Aioanei Rares wrote:
> > > On Thu, Jul 5, 2012 at 11:24 PM, Martin Nyhus
> > > wrote:
> > > >
> > > > On Mon, 11 Jun 2012 23:18:42
On Mon, Aug 06, 2012 at 11:38:04PM +0300, Maxim Levitsky wrote:
On Sat, 2012-08-04 at 17:41 +0300, Maxim Levitsky wrote:
On Mon, 2012-07-23 at 18:25 +0300, Aioanei Rares wrote:
On Thu, Jul 5, 2012 at 11:24 PM, Martin Nyhus martin.ny...@gmx.com
wrote:
On Mon, 11 Jun 2012
On Wed, Aug 08, 2012 at 08:00:21AM +0200, Sven Joachim wrote:
On 2012-08-08 07:37 +0200, Ben Skeggs wrote:
On Mon, Aug 06, 2012 at 11:38:04PM +0300, Maxim Levitsky wrote:
On Sat, 2012-08-04 at 17:41 +0300, Maxim Levitsky wrote:
On Mon, 2012-07-23 at 18:25 +0300, Aioanei Rares wrote
On Sat, Aug 04, 2012 at 08:00:45AM +0200, Henrik Rydberg wrote:
> The nva3 copy engine exhibits random memory corruption in at least one
> case, the GeForce 320M (nv50, 0xaf) in the MacBookAir3,1. This patch
> omits creating the engine for the specific chipset, falling back to
> M2MF, which kills
On Sat, Aug 04, 2012 at 08:00:45AM +0200, Henrik Rydberg wrote:
The nva3 copy engine exhibits random memory corruption in at least one
case, the GeForce 320M (nv50, 0xaf) in the MacBookAir3,1. This patch
omits creating the engine for the specific chipset, falling back to
M2MF, which kills the
tion in at least one
> case, the GeForce 320M (nv50, 0xaf) in the MacBookAir3,1. This patch
> omits creating the engine for the specific chipset, falling back to
> M2MF, which kills the symptoms.
> ---
Signed-off-by: Ben Skeggs
> drivers/gpu/drm/nouveau/nouveau_state.c | 1 -
) in the MacBookAir3,1. This patch
omits creating the engine for the specific chipset, falling back to
M2MF, which kills the symptoms.
---
Signed-off-by: Ben Skeggs bske...@redhat.com
drivers/gpu/drm/nouveau/nouveau_state.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau
From: Ben Skeggs <bske...@redhat.com>
nv_two_heads() was never meant to be used outside of pre-nv50 code. The
code checks for >= NV_10 for 2 CRTCs, then downgrades a few specific
chipsets to 1 CRTC based on (pci_device & 0x0ff0).
The breakage example seen is on GTX 560Ti, with a pc
From: Ben Skeggs bske...@redhat.com
nv_two_heads() was never meant to be used outside of pre-nv50 code. The
code checks for = NV_10 for 2 CRTCs, then downgrades a few specific
chipsets to 1 CRTC based on (pci_device 0x0ff0).
The breakage example seen is on GTX 560Ti, with a pciid of 0x1200
On Fri, May 18, 2012 at 03:32:02PM +0100, Dave Airlie wrote:
> From: Dave Airlie
>
> This seems to be wrong to me, spotted while thinking about dma-buf.
>
> Signed-off-by: Dave Airlie
Reviewed-by: Ben Skeggs
Cc: stable at vger.kernel.org
> ---
> drivers/gpu/drm/nouvea
On Fri, May 18, 2012 at 03:32:02PM +0100, Dave Airlie wrote:
From: Dave Airlie airl...@redhat.com
This seems to be wrong to me, spotted while thinking about dma-buf.
Signed-off-by: Dave Airlie airl...@redhat.com
Reviewed-by: Ben Skeggs bske...@redhat.com
Cc: sta...@vger.kernel.org
On Thu, May 17, 2012 at 10:30 AM, Ben Skeggs wrote:
> Am Mittwoch, den 16.05.2012, 12:17 -0600 schrieb Tim Gardner:
>> commit b99da31ed8521eb78d5d6930f3128f8ecdb75fae causes the backlight in
>> my Dell XPS M1710 to stop working. Symptoms are dim display and won't
>> resp
On Thu, May 17, 2012 at 10:30 AM, Ben Skeggs bske...@redhat.com wrote:
Am Mittwoch, den 16.05.2012, 12:17 -0600 schrieb Tim Gardner:
commit b99da31ed8521eb78d5d6930f3128f8ecdb75fae causes the backlight in
my Dell XPS M1710 to stop working. Symptoms are dim display and won't
respond to key
Am Mittwoch, den 16.05.2012, 12:17 -0600 schrieb Tim Gardner:
commit b99da31ed8521eb78d5d6930f3128f8ecdb75fae causes the backlight in
my Dell XPS M1710 to stop working. Symptoms are dim display and won't
respond to key brightness events. I bisected and confirmed that
reverting this single
On Wed, 2012-05-02 at 21:31 +1000, Ben Skeggs wrote:
> On Wed, 2012-05-02 at 09:54 +0200, Jean Delvare wrote:
> > Hi Luca, Maarten,
> >
> > On Monday 30 April 2012 01:01:30 pm Luca Tettamanti wrote:
> > > On Mon, Apr 30, 2012 at 11:07 AM, Maarten Maathuis > &
On Wed, 2012-05-02 at 21:31 +1000, Ben Skeggs wrote:
On Wed, 2012-05-02 at 09:54 +0200, Jean Delvare wrote:
Hi Luca, Maarten,
On Monday 30 April 2012 01:01:30 pm Luca Tettamanti wrote:
On Mon, Apr 30, 2012 at 11:07 AM, Maarten Maathuis madman2...@gmail.com
wrote:
On Mon, Apr 30
gt; > >> remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.087659]
> > >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> > >> remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.107147]
> > >> [drm:d
too low...
As I read the code, it is actually using a 6 us delay. This is fast
but reasonable, especially when the code handles clock stretching
Ben Skeggs (Cc'd) rewrote the I2C handling code in the nouveau
driver completely in kernel 3.3:
commit f553b79c03f0dbd52f6f03abe8233a2bef8cbd0d
On Sun, 2012-04-29 at 20:12 +0200, Alexander Stein wrote:
> NVIDIA Corporation C77 [GeForce 8300] (rev a2) has chipset 0xaa which
> supports HDMI Audio.
This was fixed in nouveau git already a few days ago:
On Sun, 2012-04-29 at 20:12 +0200, Alexander Stein wrote:
NVIDIA Corporation C77 [GeForce 8300] (rev a2) has chipset 0xaa which
supports HDMI Audio.
This was fixed in nouveau git already a few days ago:
On Wed, 2012-04-25 at 12:56 +1000, Ben Skeggs wrote:
> On Tue, 2012-04-24 at 21:35 -0400, Nick Bowler wrote:
> > On 2012-04-23 21:03 -0400, Nick Bowler wrote:
> > > On 2012-04-22 22:45 -0400, Konrad Rzeszutek Wilk wrote:
> > > > On Sun, Apr 22, 2012 at 08:05
On Wed, 2012-04-25 at 23:20 +0200, Marcin Slusarz wrote:
> Overall idea:
> Detect lockups by watching for timeouts (vm flush / fence), return -EIOs,
> handle them at ioctl level, reset the GPU and repeat last ioctl.
>
> GPU reset is done by doing suspend / resume cycle with few tweaks:
> -
On Wed, 2012-04-25 at 23:20 +0200, Marcin Slusarz wrote:
Overall idea:
Detect lockups by watching for timeouts (vm flush / fence), return -EIOs,
handle them at ioctl level, reset the GPU and repeat last ioctl.
GPU reset is done by doing suspend / resume cycle with few tweaks:
- CPU-only bo
On Wed, 2012-04-25 at 12:56 +1000, Ben Skeggs wrote:
On Tue, 2012-04-24 at 21:35 -0400, Nick Bowler wrote:
On 2012-04-23 21:03 -0400, Nick Bowler wrote:
On 2012-04-22 22:45 -0400, Konrad Rzeszutek Wilk wrote:
On Sun, Apr 22, 2012 at 08:05:54PM -0400, Nick Bowler wrote:
Following up
On Tue, 2012-04-24 at 21:31 +0200, Marcin Slusarz wrote:
> On Mon, Apr 23, 2012 at 06:56:44PM +0200, Martin Peres wrote:
> > Le 23/04/2012 18:32, Marcin Slusarz a ?crit :
> > >
> > > Just run piglit. Even "quick" tests can cause ~5 lockups (it eventually
> > > messes
> > > up DDX channel, but
On Mon, 2012-04-23 at 00:18 +0200, Marcin Slusarz wrote:
> Wait loop can be interrupted by signal, so if signals are raised
> periodically (e.g. SIGALRM) this loop may never finish. Use
> emission time as a base for fence timeout.
Ah, thanks for tackling this issue. It's been long on my list of
401 - 500 of 635 matches
Mail list logo
