On Mon, 2010-12-20 at 12:26 +0300, Dan Carpenter wrote:
> ARRAY_SIZE() was intended here, sizeof() is too large.
Thanks, I've queued this patch.
Ben.
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/gpu/drm/nouveau/nv50_vram.c
> b/drivers/gpu/drm/nouveau/nv50_vram.c
> index 47489ed..5
On Mon, 2010-12-20 at 09:48 +0300, Dan Carpenter wrote:
> Hi Ben,
>
> This is a new Smatch warning in linux-next. It comes from: a11c3198c
> "drm/nv50: import new vm code"
Thanks, fix queued in my tree. Will get to Dave eventually :)
Ben.
>
> drivers/gpu/drm/nouveau/nv50_vm.c +104 nv50_vm_map(
On Thu, 2010-12-09 at 08:21 +0100, Thomas Hellstrom wrote:
> On 12/09/2010 03:26 AM, skeggsb at gmail.com wrote:
> > From: Ben Skeggs
> >
> > Drivers using their own implementation of io_mem_reserve/io_mem_free are
> > likely to store the tracking information for the ma
On Thu, 2010-12-09 at 08:21 +0100, Thomas Hellstrom wrote:
> On 12/09/2010 03:26 AM, skeg...@gmail.com wrote:
> > From: Ben Skeggs
> >
> > Drivers using their own implementation of io_mem_reserve/io_mem_free are
> > likely to store the tracking information for the ma
tested it.)
> >
> > Please get an ack from the maintainer of that driver and the drm
> > maintainer so that I can apply it to the next .36 queue.
Acked-by: Ben Skeggs
> >
>
> Can you ack this for 2.6.36, please?
>
> I suspect that 2.6.35 needs it as well
tested it.)
> >
> > Please get an ack from the maintainer of that driver and the drm
> > maintainer so that I can apply it to the next .36 queue.
Acked-by: Ben Skeggs
> >
>
> Can you ack this for 2.6.36, please?
>
> I suspect that 2.6.35 needs it as well
On Tue, 2010-11-16 at 17:19 -0500, Andrew Lutomirski wrote:
> On Wed, Nov 10, 2010 at 6:04 PM, Andy Lutomirski wrote:
> > Nouveau takes down my system quite reliably when any hotplug event occurs.
> > The bug happens because the IRQ handler didn't acknowledge the hotplug
> > state until the bottom
On Tue, 2010-11-16 at 17:19 -0500, Andrew Lutomirski wrote:
> On Wed, Nov 10, 2010 at 6:04 PM, Andy Lutomirski wrote:
> > Nouveau takes down my system quite reliably when any hotplug event occurs.
> > The bug happens because the IRQ handler didn't acknowledge the hotplug
> > state until the bottom
On Thu, 2010-11-11 at 17:50 +0100, Thomas Hellstrom wrote:
> On 11/11/2010 04:27 PM, Jerome Glisse wrote:
> > On Thu, Nov 11, 2010 at 3:41 AM, Thomas Hellstrom
> > wrote:
> >
> >> The following patch is really intended for the next merge window.
> >>
> >> RFC:
> >> 1) Are there any implementa
On Thu, 2010-11-11 at 17:50 +0100, Thomas Hellstrom wrote:
> On 11/11/2010 04:27 PM, Jerome Glisse wrote:
> > On Thu, Nov 11, 2010 at 3:41 AM, Thomas Hellstrom
> > wrote:
> >
> >> The following patch is really intended for the next merge window.
> >>
> >> RFC:
> >> 1) Are there any implementa
On Wed, 2010-11-10 at 18:01 -0500, Andrew Lutomirski wrote:
> On Wed, Nov 10, 2010 at 5:55 PM, Maarten Maathuis
> wrote:
> > On Wed, Nov 10, 2010 at 11:51 PM, Andrew Lutomirski wrote:
> >> On Wed, Nov 10, 2010 at 5:35 PM, Ben Skeggs wrote:
> >>> On Wed,
On Wed, 2010-11-10 at 17:51 -0500, Andrew Lutomirski wrote:
> On Wed, Nov 10, 2010 at 5:35 PM, Ben Skeggs wrote:
> > On Wed, 2010-11-10 at 17:25 -0500, Andrew Lutomirski wrote:
> >> On Wed, Nov 10, 2010 at 5:10 PM, Ben Skeggs wrote:
> >> > On Wed, 2010-11-10 at 16:3
On Wed, 2010-11-10 at 17:25 -0500, Andrew Lutomirski wrote:
> On Wed, Nov 10, 2010 at 5:10 PM, Ben Skeggs wrote:
> > On Wed, 2010-11-10 at 16:32 -0500, Andy Lutomirski wrote:
> >> The old code generated an interrupt storm bad enough to completely
> >> take down my
On Wed, 2010-11-10 at 16:32 -0500, Andy Lutomirski wrote:
> The old code generated an interrupt storm bad enough to completely
> take down my system.
>
> This only fixes the bits that are defined nouveau_regs.h. Newer hardware
> uses another register that isn't described, and I don't have that ha
On Wed, 2010-11-10 at 18:01 -0500, Andrew Lutomirski wrote:
> On Wed, Nov 10, 2010 at 5:55 PM, Maarten Maathuis
> wrote:
> > On Wed, Nov 10, 2010 at 11:51 PM, Andrew Lutomirski wrote:
> >> On Wed, Nov 10, 2010 at 5:35 PM, Ben Skeggs wrote:
> >>> On Wed,
On Wed, 2010-11-10 at 17:51 -0500, Andrew Lutomirski wrote:
> On Wed, Nov 10, 2010 at 5:35 PM, Ben Skeggs wrote:
> > On Wed, 2010-11-10 at 17:25 -0500, Andrew Lutomirski wrote:
> >> On Wed, Nov 10, 2010 at 5:10 PM, Ben Skeggs wrote:
> >> > On Wed, 2010-11-10 at 16:3
On Wed, 2010-11-10 at 17:25 -0500, Andrew Lutomirski wrote:
> On Wed, Nov 10, 2010 at 5:10 PM, Ben Skeggs wrote:
> > On Wed, 2010-11-10 at 16:32 -0500, Andy Lutomirski wrote:
> >> The old code generated an interrupt storm bad enough to completely
> >> take down my
On Wed, 2010-11-10 at 16:32 -0500, Andy Lutomirski wrote:
> The old code generated an interrupt storm bad enough to completely
> take down my system.
>
> This only fixes the bits that are defined nouveau_regs.h. Newer hardware
> uses another register that isn't described, and I don't have that ha
xpensive 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:03 AM, Ben Sk
xpensive 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:03 AM, Ben Sk
From: Ben Skeggs
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 mapping.
Signe
From: Ben Skeggs
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 deletions(-)
diff --git a
From: Ben Skeggs
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 mapping.
Signe
From: Ben Skeggs
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 deletions(-)
diff --git a
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_au
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_au
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 ope
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 ope
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 del
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 del
From: Ben Skeggs
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/nouveau/nouveau_connector.c
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 2
From: Ben Skeggs
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/nouveau/nouveau_connector.c
On Wed, 2010-09-22 at 22:56 -0700, Andrew Morton wrote:
> On Wed, 22 Sep 2010 23:10:10 +0200 Alessandro Guido
> 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 2.6.36-rc5-49-gc79bd
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!
> [ 2869.
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!
> [ 2869.
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
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
From: Ben Skeggs
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 ++-
drivers/gpu/drm/nouveau
From: Ben Skeggs
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 ++-
drivers/gpu/drm/nouveau
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 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
From: Ben Skeggs
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 |6 +-
drivers/gpu/drm/nouveau
From: Ben Skeggs
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/nouveau/nouveau_bo.c |
From: Ben Skeggs
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 buffer corruption issues.
radeon
From: Ben Skeggs
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 |6 +-
drivers/gpu/drm/nouveau
From: Ben Skeggs
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/nouveau/nouveau_bo.c |
From: Ben Skeggs
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 buffer corruption issues.
radeon
From: Ben Skeggs
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 they wish, whilst still al
From: Ben Skeggs
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 they wish, whilst still al
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: Alloc
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: Alloc
From: Ben Skeggs
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(-)
diff --git a/drivers/gp
From: Ben Skeggs
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(-)
diff --git a/drivers/gp
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 e7e6
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 e7e6
to `acpi_lid_open'
>
> Signed-off-by: Randy Dunlap
Acked-by: Ben Skeggs
> Cc: David Airlie
> Cc: dri-devel at lists.freedesktop.org
> ---
> drivers/gpu/drm/nouveau/nouveau_connector.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> --
to `acpi_lid_open'
>
> Signed-off-by: Randy Dunlap
Acked-by: Ben Skeggs
> Cc: David Airlie
> Cc: dri-devel@lists.freedesktop.org
> ---
> drivers/gpu/drm/nouveau/nouveau_connector.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> --- linux-next-2010052
601 - 658 of 658 matches
Mail list logo
