From: Jerome Glisse jgli...@redhat.com
This patch cleanup the fence code, it drops the timeout field of
fence as the time to complete each IB is unpredictable and shouldn't
be bound.
The fence cleanup lead to GPU lockup detection improvement, this
patch introduce a callback, allowing to do asic
2010/3/1 y:
From: Jerome Glisse jgli...@redhat.com
This patch cleanup the fence code, it drops the timeout field of
fence as the time to complete each IB is unpredictable and shouldn't
be bound.
The fence cleanup lead to GPU lockup detection improvement, this
patch introduce a callback,
On Tue, Mar 02, 2010 at 10:13:19AM +0100, Erik Andrén wrote:
2010/3/1 y:
From: Jerome Glisse jgli...@redhat.com
This patch cleanup the fence code, it drops the timeout field of
fence as the time to complete each IB is unpredictable and shouldn't
be bound.
The fence cleanup lead to
http://bugs.freedesktop.org/show_bug.cgi?id=25506
Paul de Vrieze pau...@gentoo.org changed:
What|Removed |Added
CC||pau...@gentoo.org
http://bugs.freedesktop.org/show_bug.cgi?id=26596
Paul de Vrieze pau...@gentoo.org changed:
What|Removed |Added
Status|NEW |RESOLVED
On Sat, Feb 27, 2010 at 14:57:36 +0530, Jaswinder Singh Rajput wrote:
Fixed following headers_check warnings:
CHECK include/drm (14 files)
include/drm/drm_mode.h:84: found __[us]{8,16,32,64} type without #include
linux/types.h
include/drm/i915_drm.h:119: found __[us]{8,16,32,64}
On Tue, 2010-03-02 at 00:32 +0200, Pauli Nieminen wrote:
bo allocation is still too expensive operation for dma buffers in
classic mesa. It takes quite a lot cpu time in bind memory (agp
system) and ttm_mem_global functions. Would it be possible to move
some parts those expensive operations
In somecase the atombios code might lead to infinite loop because
the GPU is in broken state, this patch track the jump history and
will abort atombios execution if we are stuck executing the same
jump for more than 1sec. Note that otherwise in some case we might
enter an infinite loop in the
This patch cleanup the fence code, it drops the timeout field of
fence as the time to complete each IB is unpredictable and shouldn't
be bound.
The fence cleanup lead to GPU lockup detection improvement, this
patch introduce a callback, allowing to do asic specific test for
lockup detection. In
W dniu 1 marca 2010 17:37 użytkownik Michel Dänzer mic...@daenzer.net napisał:
On Sat, 2010-02-27 at 10:33 +0100, Rafał Miłecki wrote:
W dniu 26 lutego 2010 20:01 użytkownik Ville Syrjälä syrj...@sci.fi
napisał:
Disabling the condition check doesn't make sense.
You could use a
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
drivers/gpu/drm/radeon/radeon_pm.c | 39 ++-
1 files changed, 29 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index d800b86..4f37b52 100644
We tried to implement interruptible waiting with timeout (it was broken
anyway) which was not a good idea as explained by Andrew. It's possible
to avoid using additional variable but actually it inroduces using more
complex in-kernel tools. So simply add one variable for condition.
Signed-off-by:
On Tue, 2 Mar 2010, Linus Torvalds wrote:
I disabled it in the merge, since I had to fix up that file anyway. But
please don't make me do these so-called evil merges where I end up
modifying the thing I merge.
Never mind. I've unpulled the whole effin' mess since it doesn't even
On Tue, 2 Mar 2010, Linus Torvalds wrote:
It's still code. And if the user didn't ask for it, it should damn well
not be there.
And I repeat: unless the feature cures cancer, it's not on by default.
Sometimes we split up _old_ features as config options, or do things that
are meant to be
On Mon, 1 Mar 2010, Dave Airlie wrote:
Same tree as yesterday with a warning + PPC build fix + fix for build on
x86 after PPC (I think I just validated Ingo).
Why is VGA_SWITCHEROO enabled by default?
We don't do things like that. New drivers and new features are _not_
enabled by
On Tue, 2 Mar 2010, Dave Airlie wrote:
because it does nothing on anything except the laptops in question and on
those it does nothing except add a control file in debugfs?
It's still code. And if the user didn't ask for it, it should damn well
not be there.
So how am I supposed to
Never mind. I've unpulled the whole effin' mess since it doesn't even
compile:
drivers/gpu/drm/nouveau/nouveau_acpi.c:191: error: redefinition of
‘nouveau_register_dsm_handler’
drivers/gpu/drm/nouveau/nouveau_drv.h:859: note: previous definition of
x86 after PPC (I think I just validated Ingo).
Why is VGA_SWITCHEROO enabled by default?
because it does nothing on anything except the laptops in question and on
those it does nothing except add a control file in debugfs?
So how am I supposed to indicate to distro vendors that something
On Wed, 3 Mar 2010, Dave Airlie wrote:
Did I mention that driver is in STAGING?
Staging is for _improving_ the quality of the drivers, not for making it
worse.
We still very much have quality standards. The staging tree is for things
to get in that don't quite _reach_ the standards we
On Wed, Mar 3, 2010 at 9:40 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Wed, 3 Mar 2010, Dave Airlie wrote:
Did I mention that driver is in STAGING?
Staging is for _improving_ the quality of the drivers, not for making it
worse.
We still very much have quality standards.
0/3/3 Dave Airlie airl...@linux.ie:
Never mind. I've unpulled the whole effin' mess since it doesn't even
compile:
drivers/gpu/drm/nouveau/nouveau_acpi.c:191: error: redefinition of
‘nouveau_register_dsm_handler’
drivers/gpu/drm/nouveau/nouveau_drv.h:859: note: previous
Fixes for default y + CONFIG_STAGING + CONFIG_DRM_NOUVEAU enabled.
Dave.
The following changes since commit 60b341b778cc2929df16c0a504c91621b3c6a4ad:
Linus Torvalds (1):
Linux 2.6.33
are available in the git repository at:
On Wed, 3 Mar 2010, Dave Airlie wrote:
So can we get linux-next builds to build with *your* Kconfig? This should
cut down the amount of crap you see considerably.
No.
Dave, _think_ about what you're saying.
The absolute last thing we want to do is to make it easier for crap to
flow
http://bugs.freedesktop.org/show_bug.cgi?id=26852
Summary: Build libkms against in-tree xf86drm.h
Product: DRI
Version: XOrg CVS
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
http://bugs.freedesktop.org/show_bug.cgi?id=26852
Sérgio M. B. ser...@sergiomb.no-ip.org changed:
What|Removed |Added
CC|
On Mon, Mar 1, 2010 at 7:18 PM, Michal Suchanek hramr...@centrum.cz wrote:
On 21 November 2009 05:27, Dave Airlie airl...@gmail.com wrote:
At the moment the problem with fbset is what to do with it in the
dual head case. Currently we create an fb console that is lowest
common size of the two
http://bugzilla.kernel.org/show_bug.cgi?id=14574
--- Comment #5 from Wil Reichert wil.reich...@gmail.com 2010-03-03 05:46:14
---
Created an attachment (id=25334)
-- (http://bugzilla.kernel.org/attachment.cgi?id=25334)
dmesg from 2.6.33 and dp connector
Just tried again with the same
http://bugzilla.kernel.org/show_bug.cgi?id=14574
--- Comment #6 from Wil Reichert wil.reich...@gmail.com 2010-03-03 05:47:40
---
Created an attachment (id=25335)
-- (http://bugzilla.kernel.org/attachment.cgi?id=25335)
dmesg from 2.6.33 and dvi connector
For reference, same boot w/ dvi
BugLink: https://bugs.launchpad.net/bugs/515246
Sony VGN-BX196VP and Dell Inspiron 700m report lid status as closed
when it is open. This leads to a no connectors reported error at startup.
Blacklisting them, to always return a connected status for the default
lvds connector.
Signed-off-by:
Thanks !
Regards,
Surbhi.
From 47edbf7437388b23562f12888c36af6b59f56eec Mon Sep 17 00:00:00 2001
From: Surbhi Palande surbhi.pala...@canonical.com
Date: Mon, 22 Feb 2010 22:39:28 +0200
Subject: [PATCH] drm/i915: blacklist lid status: Sony VGN-BX196VP, Dell
Inspiron 700m
BugLink:
30 matches
Mail list logo
