On Wed, 2010-11-10 at 17:51 -0500, Andrew Lutomirski wrote:
On Wed, Nov 10, 2010 at 5:35 PM, Ben Skeggs bske...@redhat.com wrote:
On Wed, 2010-11-10 at 17:25 -0500, Andrew Lutomirski wrote:
On Wed, Nov 10, 2010 at 5:10 PM, Ben Skeggs bske...@redhat.com wrote:
On Wed, 2010-11-10 at 16:32
ensive relative to
> function pointer calls.
Thomas,
Thanks for that :) It looks good to me, and appears to work as it
should.
Ben.
>
> Patch is only compile-tested
>
> /Thomas
>
>
> On 11/04/2010 02:08 PM, Thomas Hellstrom wrote:
> > On 11/04/2010 01:0
pointer calls.
Thomas,
Thanks for that :) It looks good to me, and appears to work as it
should.
Ben.
Patch is only compile-tested
/Thomas
On 11/04/2010 02:08 PM, Thomas Hellstrom wrote:
On 11/04/2010 01:03 AM, Ben Skeggs wrote:
From: Ben Skeggsbske...@redhat.com
If the driver
From: Ben Skeggs <bske...@redhat.com>
If the driver kmaps an object userspace is expecting to be mapped, the
unmap would have called down into the drivers io_unreserve() function
and potentially unmapped the pages from its BARs (for example) and they'd
no longer be accessible for the use
From: Ben Skeggs <bske...@redhat.com>
Nouveau will start to use ttm_mem_io_reserve to allocate BAR VM space
for VRAM mappings, and without this call GPU address space gets leaked.
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/ttm/ttm_bo.c |1 +
1 files changed, 1 insertions(+), 0 del
From: Ben Skeggs bske...@redhat.com
Nouveau will start to use ttm_mem_io_reserve to allocate BAR VM space
for VRAM mappings, and without this call GPU address space gets leaked.
Signed-off-by: Ben Skeggs bske...@redhat.com
---
drivers/gpu/drm/ttm/ttm_bo.c |1 +
1 files changed, 1 insertions
From: Ben Skeggs bske...@redhat.com
If the driver kmaps an object userspace is expecting to be mapped, the
unmap would have called down into the drivers io_unreserve() function
and potentially unmapped the pages from its BARs (for example) and they'd
no longer be accessible for the userspace
On Sun, 2010-09-19 at 15:56 +0800, Zhenyu Wang wrote:
> On 2010.09.19 08:38:07 +0100, Chris Wilson wrote:
> >
> > This should be cc'ed for Adam Jackson's attention as well.
>
> yep, I think I cc-ed ajax in git-send-mail command line...I'll amend the
> commit.
>
> > > +bool
On Sun, 2010-09-19 at 15:56 +0800, Zhenyu Wang wrote:
On 2010.09.19 08:38:07 +0100, Chris Wilson wrote:
This should be cc'ed for Adam Jackson's attention as well.
yep, I think I cc-ed ajax in git-send-mail command line...I'll amend the
commit.
+bool drm_detect_monitor_audio(struct
On Thu, 2010-10-14 at 08:14 +1000, Dave Airlie wrote:
> On Wed, 2010-10-13 at 17:57 -0400, Jerome Glisse wrote:
> > So we are facing a deadlock with the radeon cs ioctl. When a buffer is given
> > a name (with flink) we could endup with 2 handle pointing to the same
> > object (flink object and
On Thu, 2010-10-14 at 08:14 +1000, Dave Airlie wrote:
On Wed, 2010-10-13 at 17:57 -0400, Jerome Glisse wrote:
So we are facing a deadlock with the radeon cs ioctl. When a buffer is given
a name (with flink) we could endup with 2 handle pointing to the same
object (flink object and open it
uveau git
(git.freedesktop.org/git/nouveau/linux-2.6), I'll push it.
Thanks,
Ben.
>
> Signed-off-by: Jiri Slaby
> Cc: Ben Skeggs
> Cc: Marcin Slusarz
> ---
> drivers/gpu/drm/nouveau/nouveau_irq.c | 23 +--
> 1 files changed, 13 insertions(+), 10 deletion
(git.freedesktop.org/git/nouveau/linux-2.6), I'll push it.
Thanks,
Ben.
Signed-off-by: Jiri Slaby jsl...@suse.cz
Cc: Ben Skeggs bske...@redhat.com
Cc: Marcin Slusarz marcin.slus...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_irq.c | 23 +--
1 files changed, 13 insertions
From: Ben Skeggs <bske...@redhat.com>
nouveau_bios_fp_mode() zeroes the mode struct before filling in relevant
entries. This nukes the mode id initialised by drm_mode_create(), and
causes warnings from idr when we try to remove the mode.
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/n
On Wed, 2010-09-22 at 22:56 -0700, Andrew Morton wrote:
> On Wed, 22 Sep 2010 23:10:10 +0200 Alessandro Guido alessandroguido.name> wrote:
>
> > I have this traces in my logs (full dmesg attached).
> >
> > idr_remove called for id=0 which is not allocated.
> > Pid: 1136, comm: Xorg Not tainted
On Wed, 2010-09-22 at 22:56 -0700, Andrew Morton wrote:
On Wed, 22 Sep 2010 23:10:10 +0200 Alessandro Guido
a...@alessandroguido.name wrote:
I have this traces in my logs (full dmesg attached).
idr_remove called for id=0 which is not allocated.
Pid: 1136, comm: Xorg Not tainted
On Fri, 2010-09-17 at 19:43 +0200, Marcin Slusarz wrote:
> Hi
> Since upgrade from 2.6.35 to 2.6.36-rc3 (nouveau tree) I'm hitting this bug a
> couple of times a day:
>
> [ 2869.618504] [ cut here ]
> [ 2869.618532] kernel BUG at drivers/gpu/drm/ttm/ttm_bo.c:153!
> [
On Fri, 2010-09-17 at 19:43 +0200, Marcin Slusarz wrote:
Hi
Since upgrade from 2.6.35 to 2.6.36-rc3 (nouveau tree) I'm hitting this bug a
couple of times a day:
[ 2869.618504] [ cut here ]
[ 2869.618532] kernel BUG at drivers/gpu/drm/ttm/ttm_bo.c:153!
[
On Mon, 2010-08-23 at 17:35 +0200, Stephane Casset wrote:
> Hi,
Hi,
>
> Since 2.6.36-rc1 I have an oops when loading the nouveau driver.
> The system woks ok expect for the nouveau driver and the console gets
> corrupted :(
>
> I attach relevant informations in attached files :
> o dmesg
On Mon, 2010-08-23 at 17:35 +0200, Stephane Casset wrote:
Hi,
Hi,
Since 2.6.36-rc1 I have an oops when loading the nouveau driver.
The system woks ok expect for the nouveau driver and the console gets
corrupted :(
I attach relevant informations in attached files :
o dmesg output for
From: Ben Skeggs <bske...@redhat.com>
Nouveau will need this on GeForce 8 and up to account for the GPU
reordering physical VRAM for some memory types.
v2: rebase to include nvc0_instmem.c changes
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 12 ++-
drive
On Fri, 2010-08-13 at 23:59 +0200, Luca Tettamanti wrote:
> On Fri, Aug 13, 2010 at 11:39 PM, Dan Carpenter wrote:
> > Smatch thinks there is a buffer overflow in nvc0_instmem_suspend() and
> > I've looked at it, but I don't understand the code.
> >
> > drivers/gpu/drm/nouveau/nvc0_instmem.c +152
On Fri, 2010-08-13 at 23:59 +0200, Luca Tettamanti wrote:
On Fri, Aug 13, 2010 at 11:39 PM, Dan Carpenter erro...@gmail.com wrote:
Smatch thinks there is a buffer overflow in nvc0_instmem_suspend() and
I've looked at it, but I don't understand the code.
From: Ben Skeggs <bske...@redhat.com>
Nouveau will need this on GeForce 8 and up to account for the GPU
reordering physical VRAM for some memory types.
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 12 ++-
drivers/gpu/drm/nouveau/nouveau_channel.c
From: Ben Skeggs <bske...@redhat.com>
Existing core code/drivers call drm_mm_put_block on ttm_mem_reg.mm_node
directly. Future patches will modify TTM behaviour in such a way that
ttm_mem_reg.mm_node doesn't necessarily belong to drm_mm.
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/n
From: Ben Skeggs <bske...@redhat.com>
In order to properly deal with GPU reordering of blocks in physical VRAM,
Nouveau needs to be able to have better control over VRAM allocations.
Currently nouveau is extremely wasteful and forces massive amounts of
padding/alignment to avoid
From: Ben Skeggs bske...@redhat.com
Nouveau will need this on GeForce 8 and up to account for the GPU
reordering physical VRAM for some memory types.
Signed-off-by: Ben Skeggs bske...@redhat.com
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 12 ++-
drivers/gpu/drm/nouveau/nouveau_channel.c
From: Ben Skeggs <bske...@redhat.com>
There's no convenient/reliable way for drivers to both obey the dithering
mode property, and to be able to attempt to provide a good default in all
cases.
This commit adds an "auto" method to the property which drivers can default
to if t
On Sun, 2010-07-11 at 01:24 +0200, Marcin Slusarz wrote:
> Hi
>
> Patch "drm/nouveau: use drm_mm in preference to custom code doing the same
> thing"
> in nouveau tree introduced new deadlock possibility, for which lockdep
> complains loudly:
>
> [ 1541.070202] [drm] nouveau :02:00.0:
On Sun, 2010-07-11 at 01:24 +0200, Marcin Slusarz wrote:
Hi
Patch drm/nouveau: use drm_mm in preference to custom code doing the same
thing
in nouveau tree introduced new deadlock possibility, for which lockdep
complains loudly:
[ 1541.070202] [drm] nouveau :02:00.0: Allocating
From: Ben Skeggs <bske...@redhat.com>
Original behaviour will be preserved for drivers that don't implement
disable() hooks for an encoder.
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/drm_crtc_helper.c | 22 ++
1 files changed, 14 insertions(+), 8 deletions(-)
From: Ben Skeggs bske...@redhat.com
Original behaviour will be preserved for drivers that don't implement
disable() hooks for an encoder.
Signed-off-by: Ben Skeggs bske...@redhat.com
---
drivers/gpu/drm/drm_crtc_helper.c | 22 ++
1 files changed, 14 insertions(+), 8
On Tue, 2010-05-25 at 11:52 +0200, Dan Carpenter wrote:
> dcb->i2c[] has DCB_MAX_NUM_I2C_ENTRIES entries.
>
> Signed-off-by: Dan Carpenter
Thanks, picked this up in the nouveau tree.
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c
> b/drivers/gpu/drm/nouveau/nouveau_bios.c
> index
On Tue, 2010-05-25 at 11:52 +0200, Dan Carpenter wrote:
dcb-i2c[] has DCB_MAX_NUM_I2C_ENTRIES entries.
Signed-off-by: Dan Carpenter erro...@gmail.com
Thanks, picked this up in the nouveau tree.
diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c
b/drivers/gpu/drm/nouveau/nouveau_bios.c
to `acpi_lid_open'
Signed-off-by: Randy Dunlap randy.dun...@oracle.com
Acked-by: Ben Skeggs bske...@redhat.com
Cc: David Airlie airl...@linux.ie
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/nouveau/nouveau_connector.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- linux
601 - 635 of 635 matches
Mail list logo
