[Bug 32544] New: [r300g] LLVM support for software TLS implementation doesn't work

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=32544

   Summary: [r300g] LLVM support for software TLS implementation
doesn't work
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r300
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: drill87 at gmail.com


Hello. A month ago I started to use --enable-gallium-llvm while compiling mesa
git version and got a great performance increase - glxgears showed 800 fps vs
250 without LLVM.
  But in newer git versions (starting from the end of November or so) this
option stopped to help me - I've got 250 fps both with --enable-gallium-llvm
and without today.
  So is LLVM support (as I understood) for TLS implementation working in r300g?
Or the problem only on my side...

Kernel: 2.6.36 x86-64 (Archlinux 64)
Videocard: ATI Radeon X1270 (RS690)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Intel-gfx] [PATCH] drm: Aggressively disable vblanks

[Andrew Lutomirski]

On Mon, Dec 20, 2010 at 10:23 PM, Keith Packard  wrote:
> On Mon, 20 Dec 2010 14:00:54 -0500, Andy Lutomirski  wrote:
>
>> Enabling and disabling the vblank interrupt (on devices that
>> support it) is cheap. ?So disable it quickly after each
>> interrupt.
>
> So, the concern (and reason for the original design) was that you might
> lose count of vblank interrupts as vblanks are counted differently while
> off than while on. If vblank interrupts get enabled near the interrupt
> time, is it possible that you'll end up off by one somehow?

So the race is:

1. Vblank happens.
2. vblank_get runs, reads hardware counter, and enables the interrupt
(and maybe not quite in that order)
3. Interrupt fires and increments the counter.  Now the counter is one too high.

What if we read the hardware counter from the IRQ the first time that
it fires after being enabled?  That way, if the hardware and software
counters match (mod 2^23 or whatever the magic number is), we don't
increment the counter.

>
> Leaving them enabled for 'a while' was supposed to reduce the impact of
> this potential error.
>

Fair enough,

But five seconds is a *long* time, and anything short enough that the
interrupt actually gets turned off in normal use risks the same race.

--Andy

Freescale Linux BSP review

[Arnd Bergmann]

On Monday 20 December 2010 19:07:30 Jerome Glisse wrote:
> > I also do not think that it is at all kernel policy to disallow kernel
> > drivers which do not have opensource userspace components. In fact,
> > Linus Torvalds begs to differ on this matter. The fact of the matter
> > is that the driver lives now, Qualcomm have it in their upstream,
> > Freescale have it in their upstream, Linaro are going to fetch from
> > that. It doesn't need to go all the way to stable, because people can
> > compile their own kernels if they want (and Linaro is there provide
> > the source to do that with the best interoperability with the silicon
> > vendors' chips as possible).
> 
> I was just expressing my opinion on upstream, if i see this driver
> showing up on lkml i will reply with a nak and explain why (pretty
> much same argument as here). I don't have any authority on linux
> kernel but as far as i understand it, it's about reviewing what's gets
> in, so i hope my review opinion would matter (what ever the out come
> is).

There is a broad agreement on disallowing new kernel to userspace
interfaces in the upstream kernel unless there is an application
using it that is both open source and considered useful.

I don't think Linaro as a group takes a position or should take
a position on closed source user space at all -- we just don't
need to bother with it because we have enough work to do on free
components. However, we have a policy on kernel code and that is
as I mentioned before that we don't take code unless it's about to
go upstream. In this case, upstream doesn't take the driver, so
Linaro won't either.

Arnd

Freescale Linux BSP review

[Alan Cox]

> I also do not think that it is at all kernel policy to disallow kernel
> drivers which do not have opensource userspace components. In fact,

Wrong. The PVR graphics (as used by some Intel embedded for example) is
also not in the kernel for the same reason, ditto some sensor and GPS
devices which are useless without a magic proprietary library.

There are lots of reasons for refusing such code

- Legality questions
- Testability
- Security
- Risk of locking us to proprietary interfaces when we can't change the
  user one

and more

Alan

Freescale Linux BSP review

[Alan Cox]

> My point which people keep missing is that graphics stacks are a
> single entity, that span kernel and userspace, one cannot exist
> without the other, and there are interfaces that join them.

As a copyright holder on the kernel I'll also remind the people concerned
that the definition of a derivative work is a legal not a technical one
and if the kernel and user space cannot be used except together and one
half depends on GPL elements I hope your lawyers have reviewed it
carefully. I have never given anyone permission to link my GPL kernel
contributions with anything but GPL code, modular or otherwise, except
according to the derivative work rules laid down by the GPL (and indeed
by the boundaries placed on copyright law).

Alan

[Intel-gfx] [PATCH] drm: Aggressively disable vblanks

[Jesse Barnes]

On Mon, 20 Dec 2010 22:55:46 -0500
Andrew Lutomirski  wrote:

> On Mon, Dec 20, 2010 at 10:47 PM, Keith Packard  wrote:
> > On Mon, 20 Dec 2010 22:34:12 -0500, Andrew Lutomirski  
> > wrote:
> >
> >> But five seconds is a *long* time, and anything short enough that the
> >> interrupt actually gets turned off in normal use risks the same race.
> >
> > Right, so eliminating any race seems like the basic requirement. Can
> > that be done?
> 
> I'll give it a shot.
> 
> Do you know if there's an existing tool to call drm_wait_vblank from
> userspace for testing?  I know approximately nothing about libdrm or
> any userspace graphics stuff whatsoever.

Yeah, libdrm has a test program called vbltest; it should do what you
need.

-- 
Jesse Barnes, Intel Open Source Technology Center

[PATCH] vgaarb: use bridges to control VGA routing where possible. (v2)

[Jesse Barnes]

On Mon, 20 Dec 2010 10:10:09 +1000
Dave Airlie  wrote:

> - * @change_bridge: traverse ancestors and change bridges
> + * @change_bridge_flags: traverse ancestors and change bridges
> + * CHANGE_BRIDGE_ONLY / CHANGE_BRIDGE
>   */
>  int pci_set_vga_state(struct pci_dev *dev, bool decode,
> -   unsigned int command_bits, bool change_bridge)
> +   unsigned int command_bits, u32 flags)
>  {

Other than this nitpick, it looks sound to me; we'll need to actually
disable VGA decode in the shared bridge hierarchy case rather than just
using simple bridge routing.

Acked-by: Jesse Barnes 

-- 
Jesse Barnes, Intel Open Source Technology Center

[Intel-gfx] [PATCH] drm: Aggressively disable vblanks

[Keith Packard]

On Mon, 20 Dec 2010 22:34:12 -0500, Andrew Lutomirski  wrote:

> But five seconds is a *long* time, and anything short enough that the
> interrupt actually gets turned off in normal use risks the same race.

Right, so eliminating any race seems like the basic requirement. Can
that be done?

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20101220/5ca3b674/attachment.pgp>

[Intel-gfx] [PATCH] drm: Aggressively disable vblanks

[Keith Packard]

On Mon, 20 Dec 2010 14:00:54 -0500, Andy Lutomirski  wrote:

> Enabling and disabling the vblank interrupt (on devices that
> support it) is cheap.  So disable it quickly after each
> interrupt.

So, the concern (and reason for the original design) was that you might
lose count of vblank interrupts as vblanks are counted differently while
off than while on. If vblank interrupts get enabled near the interrupt
time, is it possible that you'll end up off by one somehow?

Leaving them enabled for 'a while' was supposed to reduce the impact of
this potential error.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20101220/105a9fb6/attachment.pgp>

[PATCH Resend] Don't expose mmio for fbdev emulation layer

[James Simmons]

For the fbdev api if the struct fb_var_screeninfo accel_flags field is set 
to FB_ACCELF_TEXT then userland applications can not mmap the mmio region.
Since it is a bad idea for DRM drivers to expose the mmio region via the 
fbdev layer we always set the accel_flags to prevent this. Please apply.

Signed-off-by: James Simmons 
---

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index d2849e4..aa37711 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -985,6 +985,8 @@ void drm_fb_helper_fill_fix(struct fb_info *info, uint32_t 
pitch,
info->fix.type = FB_TYPE_PACKED_PIXELS;
info->fix.visual = depth == 8 ? FB_VISUAL_PSEUDOCOLOR :
FB_VISUAL_TRUECOLOR;
+   info->fix.mmio_start = 0;
+   info->fix.mmio_len = 0;
info->fix.type_aux = 0;
info->fix.xpanstep = 1; /* doing it in hw */
info->fix.ypanstep = 1; /* doing it in hw */
@@ -1005,6 +1007,7 @@ void drm_fb_helper_fill_var(struct fb_info *info, struct 
drm_fb_helper *fb_helpe
info->var.xres_virtual = fb->width;
info->var.yres_virtual = fb->height;
info->var.bits_per_pixel = fb->bits_per_pixel;
+   info->var.accel_flags = FB_ACCELF_TEXT;
info->var.xoffset = 0;
info->var.yoffset = 0;
info->var.activate = FB_ACTIVATE_NOW;
diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index af2a1dd..ced3eef 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
@@ -68,7 +68,7 @@ static int intelfb_create(struct intel_fbdev *ifbdev,
struct drm_gem_object *fbo = NULL;
struct drm_i915_gem_object *obj_priv;
struct device *device = >pdev->dev;
-   int size, ret, mmio_bar = IS_GEN2(dev) ? 1 : 0;
+   int size, ret;

/* we don't do packed 24bpp */
if (sizes->surface_bpp == 24)
@@ -156,10 +156,6 @@ static int intelfb_create(struct intel_fbdev *ifbdev,
drm_fb_helper_fill_fix(info, fb->pitch, fb->depth);
drm_fb_helper_fill_var(info, >helper, sizes->fb_width, 
sizes->fb_height);

-   /* FIXME: we really shouldn't expose mmio space at all */
-   info->fix.mmio_start = pci_resource_start(dev->pdev, mmio_bar);
-   info->fix.mmio_len = pci_resource_len(dev->pdev, mmio_bar);
-
info->pixmap.size = 64*1024;
info->pixmap.buf_align = 8;
info->pixmap.access_align = 32;
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index ea861c9..9dbe1ef 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -348,10 +348,6 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev,
drm_fb_helper_fill_fix(info, fb->pitch, fb->depth);
drm_fb_helper_fill_var(info, >helper, sizes->fb_width, 
sizes->fb_height);

-   /* FIXME: we really shouldn't expose mmio space at all */
-   info->fix.mmio_start = pci_resource_start(pdev, 1);
-   info->fix.mmio_len = pci_resource_len(pdev, 1);
-
/* Set aperture base/size for vesafb takeover */
info->apertures = dev_priv->apertures;
if (!info->apertures) {
diff --git a/drivers/gpu/drm/radeon/radeon_fb.c 
b/drivers/gpu/drm/radeon/radeon_fb.c
index efa2118..f7b4762 100644
--- a/drivers/gpu/drm/radeon/radeon_fb.c
+++ b/drivers/gpu/drm/radeon/radeon_fb.c
@@ -247,8 +247,6 @@ static int radeonfb_create(struct radeon_fbdev *rfbdev,
info->apertures->ranges[0].base = rdev->ddev->mode_config.fb_base;
info->apertures->ranges[0].size = rdev->mc.real_vram_size;

-   info->fix.mmio_start = 0;
-   info->fix.mmio_len = 0;
info->pixmap.size = 64*1024;
info->pixmap.buf_align = 8;
info->pixmap.access_align = 32;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
index 41d9a5b..dd596f2 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
@@ -480,9 +480,6 @@ int vmw_fb_init(struct vmw_private *vmw_priv)
info->fix.smem_start = 0;
info->fix.smem_len = fb_size;

-   info->fix.mmio_start = 0;
-   info->fix.mmio_len = 0;
-
info->pseudo_palette = par->pseudo_palette;
info->screen_base = par->vmalloc;
info->screen_size = fb_size;

[BUG] commit 541cc966915b6756e54c20eebe60ae957afdb537 cause no screen

[Dave Airlie]

On Mon, Dec 20, 2010 at 4:13 PM, Wei Yongjun  wrote:
> After commit 541cc966915b6756e54c20eebe60ae957afdb537, I can see
> nothing in my screen, and the monitor is the same state as shutdown,
> but can ssh to my computer.
>
> Revert 541cc966915b6756e54c20eebe60ae957afdb537, every thing is OK.
>
> ? ?Revert "drm: Don't try and disable an encoder that was never enabled"
>
> ? ?This reverts commit 541cc966915b6756e54c20eebe60ae957afdb537.
>
> I am not in the maillist, so if any reply, pls cc me, thanks.

Hi,

Can you boot with drm.debug=4 with and without this patch and attach
both dmesgs?

I'll revert it ASAP since its a regression.

Thanks,
Dave.

>
> # lspci
> 00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM 
> Controller (rev 10)
> 00:02.0 VGA compatible controller: Intel Corporation 82G33/G31 Express 
> Integrated Graphics Controller (rev 10)
> 00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition 
> Audio Controller (rev 01)
> 00:1c.0 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 1 
> (rev 01)
> 00:1c.1 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 2 
> (rev 01)
> 00:1d.0 USB Controller: Intel Corporation N10/ICH7 Family USB UHCI Controller 
> #1 (rev 01)
> 00:1d.1 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI 
> Controller #2 (rev 01)
> 00:1d.2 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI 
> Controller #3 (rev 01)
> 00:1d.3 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI 
> Controller #4 (rev 01)
> 00:1d.7 USB Controller: Intel Corporation N10/ICH 7 Family USB2 EHCI 
> Controller (rev 01)
> 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1)
> 00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface 
> Bridge (rev 01)
> 00:1f.2 IDE interface: Intel Corporation N10/ICH7 Family SATA IDE Controller 
> (rev 01)
> 00:1f.3 SMBus: Intel Corporation N10/ICH 7 Family SMBus Controller (rev 01)
> 02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8056 PCI-E 
> Gigabit Ethernet Controller (rev 14)
> 03:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
> RTL-8139/8139C/8139C+ (rev 10)
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

Mesa build fails with "--disable-gallium-radeon"

[Stefan Dirsch]

Hi

Mesa build fails with "--disable-gallium-radeon" due to undefined
radeon_gem_get_kernel_name(). Attached is a patch.

Best regards,
Stefan

Public Key available
--
Stefan Dirsch (Res. & Dev.)   SUSE LINUX Products GmbH
Tel: 0911-740 53 0Maxfeldstra?e 5
FAX: 0911-740 53 479  D-90409 N?rnberg
http://www.suse.deGermany 
-
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N?rnberg)
-
-- next part --
A non-text attachment was scrubbed...
Name: disable-radeon_query_image.diff
Type: text/x-patch
Size: 806 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20101220/62e6eaeb/attachment.bin>

[Bug 32455] Crash with mame using OpenGL with newest Gallium on Radeon 4350

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=32455

--- Comment #6 from Chris  2010-12-20 18:20:17 PST ---
I get the same segfault and backtrace as ?yvind S?ther posted with the new
version too, looks just like his.  Thanks, does look like it's getting farther
though I think.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/radeon/kms: reorder display resume to avoid problems

[Rafał Miłecki]

2010/12/20 Alex Deucher :
> On resume, we were attemping to unblank the displays before the
> timing and plls had be reprogrammed which led to atom timeouts
> waiting for things that are not yet programmed. ?Re-program
> the mode first, then reset the dpms state.
>
> This fixes the infamous atombios timeouts on resume.

Congratulations and thanks a lot! :)

-- 
Rafa?

[Bug 32455] Crash with mame using OpenGL with newest Gallium on Radeon 4350

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=32455

--- Comment #5 from ?yvind S?ther  2010-12-20 16:11:27 
PST ---
line 179 offset += vertex_buffer->buffer_offset + r600_bo_offset(rbuffer->bo);
(latest git with the "r600g: properly unset vertex buffer"
abe9ffc25c8d65b48ae02cdc8445b212b9f61632 patch also SIGSEGVs.

$ gdb sdlmame
(stuff)
Program received signal SIGSEGV, Segmentation fault.
0x720ccb06 in r600_vertex_buffer_update (rctx=0x66bbc30) at
r600_state.c:179
179 r600_state.c: Ingen slik fil eller filkatalog.
in r600_state.c
(gdb) bt full
#0  0x720ccb06 in r600_vertex_buffer_update (rctx=0x66bbc30) at
r600_state.c:179
rstate = 0x71c93010
rbuffer = 0x0
vertex_buffer = 0x66bd048
i = 0
offset = 0
#1  0x720da40b in r600_set_vertex_buffers (ctx=0x66bbc30, count=1,
buffers=0x7fffc5c0) at r600_state_common.c:220
rctx = 0x66bbc30
vbo = 0x7fffc5c0
max_index = 4294967295
#2  0x721d6fa8 in st_draw_vbo (ctx=0x6bf0210, arrays=0x6c3f3a0,
prims=0x7fffc950, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001',
min_index=0,
max_index=3) at state_tracker/st_draw.c:701
st = 0x6c3bb60
pipe = 0x66bbc30
vp = 0x6e3f1c0
vpv = 0x6e467a0
vbuffer = {{stride = 8, max_index = 3, buffer_offset = 0, buffer =
0x0}, {stride = 115533480, max_index = 0, buffer_offset = 4,
buffer = 0x7fffc7a0}, {stride = 27394114, max_index = 0,
buffer_offset = 3, buffer = 0x7fff01b6c001}, {stride = 16, max_index = 0,
buffer_offset = 4294952736, buffer = 0x7227e76e}, {stride =
27394048, max_index = 117, buffer_offset = 4294952864, buffer = 0x6e2e6a8}, {
stride = 27394048, max_index = 0, buffer_offset = 4294952624,
buffer = 0x7fffc7a0}, {stride = 27394048, max_index = 32767,
buffer_offset = 4070635360, buffer = 0x7fff0299}, {stride =
4062687129, max_index = 32767, buffer_offset = 27394049,
buffer = 0x7fffc6e0}, {stride = 27394050, max_index = 113,
buffer_offset = 4294952864, buffer = 0x1a2}, {stride = 4294952864,
max_index = 4, buffer_offset = 27394050, buffer = 0x62f06d41900},
{stride = 4070634880, max_index = 32767, buffer_offset = 115533624,
buffer = 0x7fffc720}, {stride = 4062687972, max_index = 32767,
buffer_offset = 13, buffer = 0x30}, {stride = 13, max_index = 27394070,
buffer_offset = 64, buffer = 0x1a000d}, {stride = 4134719176,
max_index = 32767, buffer_offset = 27394049, buffer = 0x2c}, {
stride = 115533624, max_index = 4, buffer_offset = 4134719096,
buffer = 0x60}, {stride = 113435888, max_index = 4, buffer_offset = 80320,
buffer = 0x6c2e4f0}, {stride = 4134719072, max_index = 32767,
buffer_offset = 44, buffer = 0x1}, {stride = 115478608, max_index = 0,
buffer_offset = 1, buffer = 0x7644f9f0}, {stride = 4294952944,
max_index = 32767, buffer_offset = 113435888, buffer = 0x7fffc7f0}, {
stride = 114563328, max_index = 0, buffer_offset = 115536160,
buffer = 0x721ef3cd}, {stride = 4294952976, max_index = 32767,
buffer_offset = 115601856, buffer = 0x2c0020}, {stride =
4294952976, max_index = 32767, buffer_offset = 113435888, buffer = 0x6bf0210},
{
stride = 13, max_index = 2640323868, buffer_offset = 115535632,
buffer = 0x0}, {stride = 113435888, max_index = 0, buffer_offset = 4294953056,
buffer = 0x7227ef90}, {stride = 0, max_index = 0, buffer_offset
= 115601856, buffer = 0x6c04a58}, {stride = 113181200, max_index = 0,
buffer_offset = 113181200, buffer = 0x6bf0210}, {stride =
4063024604, max_index = 32767, buffer_offset = 113513056, buffer =
0x7fffc870}, {
stride = 4062903259, max_index = 32767, buffer_offset = 8, buffer =
0x6bf0210}, {stride = 0, max_index = 0, buffer_offset = 113496512,
buffer = 0x7fffc890}, {stride = 4062902571, max_index = 32767,
buffer_offset = 113455672, buffer = 0x6bf0210}, {stride = 4294953152,
max_index = 32767, buffer_offset = 4062008109, buffer =
0x84006bf0210}, {stride = 113181200, max_index = 0, buffer_offset = 16,
buffer = 0x6c3bb60}}
attr = 0  
velements = {{src_offset = 107697360, instance_divisor = 0,
vertex_buffer_index = 0, src_format = PIPE_FORMAT_R32G32_FLOAT}, {src_offset =
0,
instance_divisor = 0, vertex_buffer_index = 0, src_format =
PIPE_FORMAT_R32G32_FLOAT}, {src_offset = 0, instance_divisor = 0,
vertex_buffer_index = 0, src_format = PIPE_FORMAT_NONE},
{src_offset = 0, instance_divisor = 0, vertex_buffer_index = 0,
src_format = PIPE_FORMAT_NONE}, {src_offset = 0, instance_divisor =
0, vertex_buffer_index = 0, src_format = PIPE_FORMAT_NONE}, {src_offset = 0,
instance_divisor = 0, vertex_buffer_index = 0, src_format =
PIPE_FORMAT_NONE}, {src_offset = 0, instance_divisor = 0, 

[Bug 32535] Graphics corruption after resume from hibernate on Thinkpad SL510 (RV710 0x1002:0x9553)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=32535

--- Comment #5 from Robert Hooker (Sarvatt)  2010-12-20 
15:03:19 PST ---
Created an attachment (id=41322)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=41322)
kernel log with patch

It didn't help unfortunately

[   45.741351] radeon :01:00.0: GPU softreset 
[   45.741354] radeon :01:00.0:   R_008010_GRBM_STATUS=0x3028
[   45.741357] radeon :01:00.0:   R_008014_GRBM_STATUS2=0x0002
[   45.741359] radeon :01:00.0:   R_000E50_SRBM_STATUS=0x20C0
[   45.741373] radeon :01:00.0:   R_008020_GRBM_SOFT_RESET=0x7FEE

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH 1/2] drm/radeon/kms: fix evergreen asic reset

[Jerome Glisse]

On Mon, Dec 20, 2010 at 12:35 PM, Alex Deucher  wrote:
> Only reset the grbm blocks, srbm tends to lock the GPU
> if not done properly and in most cases is not necessary.
> Also, no need to call asic init after reset the grbm blocks.
>
> Signed-off-by: Alex Deucher 
> Cc: stable at kernel.org
> ---

Reviewed-by: Jerome Glisse 

> ?drivers/gpu/drm/radeon/evergreen.c | ? 15 ---
> ?1 files changed, 0 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen.c 
> b/drivers/gpu/drm/radeon/evergreen.c
> index 901f366..8b82749 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -2036,7 +2036,6 @@ bool evergreen_gpu_is_lockup(struct radeon_device *rdev)
> ?static int evergreen_gpu_soft_reset(struct radeon_device *rdev)
> ?{
> ? ? ? ?struct evergreen_mc_save save;
> - ? ? ? u32 srbm_reset = 0;
> ? ? ? ?u32 grbm_reset = 0;
>
> ? ? ? ?dev_info(rdev->dev, "GPU softreset \n");
> @@ -2075,16 +2074,6 @@ static int evergreen_gpu_soft_reset(struct 
> radeon_device *rdev)
> ? ? ? ?udelay(50);
> ? ? ? ?WREG32(GRBM_SOFT_RESET, 0);
> ? ? ? ?(void)RREG32(GRBM_SOFT_RESET);
> -
> - ? ? ? /* reset all the system blocks */
> - ? ? ? srbm_reset = SRBM_SOFT_RESET_ALL_MASK;
> -
> - ? ? ? dev_info(rdev->dev, " ?SRBM_SOFT_RESET=0x%08X\n", srbm_reset);
> - ? ? ? WREG32(SRBM_SOFT_RESET, srbm_reset);
> - ? ? ? (void)RREG32(SRBM_SOFT_RESET);
> - ? ? ? udelay(50);
> - ? ? ? WREG32(SRBM_SOFT_RESET, 0);
> - ? ? ? (void)RREG32(SRBM_SOFT_RESET);
> ? ? ? ?/* Wait a little for things to settle down */
> ? ? ? ?udelay(50);
> ? ? ? ?dev_info(rdev->dev, " ?GRBM_STATUS=0x%08X\n",
> @@ -2095,10 +2084,6 @@ static int evergreen_gpu_soft_reset(struct 
> radeon_device *rdev)
> ? ? ? ? ? ? ? ?RREG32(GRBM_STATUS_SE1));
> ? ? ? ?dev_info(rdev->dev, " ?SRBM_STATUS=0x%08X\n",
> ? ? ? ? ? ? ? ?RREG32(SRBM_STATUS));
> - ? ? ? /* After reset we need to reinit the asic as GPU often endup in an
> - ? ? ? ?* incoherent state.
> - ? ? ? ?*/
> - ? ? ? atom_asic_init(rdev->mode_info.atom_context);
> ? ? ? ?evergreen_mc_resume(rdev, );
> ? ? ? ?return 0;
> ?}
> --
> 1.7.2.3
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[BUG] commit 541cc966915b6756e54c20eebe60ae957afdb537 cause no screen

[Wei Yongjun]

After commit 541cc966915b6756e54c20eebe60ae957afdb537, I can see
nothing in my screen, and the monitor is the same state as shutdown,
but can ssh to my computer.

Revert 541cc966915b6756e54c20eebe60ae957afdb537, every thing is OK.

Revert "drm: Don't try and disable an encoder that was never enabled"

This reverts commit 541cc966915b6756e54c20eebe60ae957afdb537.

I am not in the maillist, so if any reply, pls cc me, thanks.

# lspci
00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM 
Controller (rev 10)
00:02.0 VGA compatible controller: Intel Corporation 82G33/G31 Express 
Integrated Graphics Controller (rev 10)
00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio 
Controller (rev 01)
00:1c.0 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 1 (rev 
01)
00:1c.1 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 2 (rev 
01)
00:1d.0 USB Controller: Intel Corporation N10/ICH7 Family USB UHCI Controller 
#1 (rev 01)
00:1d.1 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller 
#2 (rev 01)
00:1d.2 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller 
#3 (rev 01)
00:1d.3 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller 
#4 (rev 01)
00:1d.7 USB Controller: Intel Corporation N10/ICH 7 Family USB2 EHCI Controller 
(rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1)
00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface 
Bridge (rev 01)
00:1f.2 IDE interface: Intel Corporation N10/ICH7 Family SATA IDE Controller 
(rev 01)
00:1f.3 SMBus: Intel Corporation N10/ICH 7 Family SMBus Controller (rev 01)
02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8056 PCI-E 
Gigabit Ethernet Controller (rev 14)
03:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL-8139/8139C/8139C+ (rev 10)

[PATCH] drm: Aggressively disable vblanks

[Andy Lutomirski]

Enabling and disabling the vblank interrupt (on devices that
support it) is cheap.  So disable it quickly after each
interrupt.

To avoid constantly enabling and disabling vblank when
animations are running, after a predefined number (3) of
consecutive enabled vblanks that someone cared about, just
leave the interrupt on until an interrupt that no one cares
about.

The full heuristic is:

There's a per-CRTC counter called vblank_consecutive.  It
starts at zero and counts consecutive useful vblanks.  A
vblank is useful if the refcount is nonzero when the interrupt
comes in.

Whenever drm_vblank_get enables the interrupt, it stays on at
least until the next vblank (*).  If drm_vblank_put is called
and vblank_consecutive is less than a threshold (currently 3),
then the interrupt is disabled.  If a vblank interrupt happens
with refcount == 0, then the interrupt is disabled and
vblank_consecutive is reset to 0.  If vblank_get is called
with the interrupt disabled and no interrupts were missed,
then vblank_consecutive is incremented.

(*) I tried letting it turn off before the next interrupt, but
compiz on my laptop seems to call drm_wait_vblank twice with
relative waits of 0 (!) before actually waiting.

Signed-off-by: Andy Lutomirski 
---

Jesse, you asked for the deletion of the timer to be separate
from reducing the timeout, but that seemed silly because I'm ripping
out the entire old mechanism.  If you're worried about the added time
spent in the interrupt handler, I could move it to a tasklet.  That
being said, disable_vblank should be very fast (it's at most a couple
of register accesses in all in-tree drivers).

I've tested this on i915, where it works nicely and reduces my wakeups
with a second hand showing on the clock but an otherwise idle system.

This changes the requirements on enable_vblank, disable_vblank and
get_vblank_counter: they can now be called from an IRQ.  They already
had to work with IRQs off and a spinlock held, but now a driver has to
watch out for recursive calls from drm_handle_vblank.  The vbl_lock is
still held.

I've audited the in-tree drivers:

mga, r128: get_vblank_counter just reads an atomic_t.  enable_vblank
just pokes registers without a lock.  disable_vblank does nothing, so
turning off vblanks is pointless.

via: get_vblank_counter just returns a counter.  enable_vblank and
disable_vblank just poke registers without locks.  (This looks wrong:
get_vblank_count does the wrong thing and will confuse my heuristic,
but it should be any worse than it already is.  I can comment out
enable_vblank if anyone prefers that approach.)

vmwgfx: get_vblank_counter does nothing and the other hooks aren't
implemented.

radeon: Everything looks safe.

i915: Looks good and tested!

nouveau: Not implemented at all.  I'm not sure why either the old code
or my code doesn't try to call a null pointer, but it doesn't.  That
being said, sync-to-vblank doesn't work on nouveau for me (glxgears
gets over 600fps while claiming to be synced to vblank).

As a future improvement, all of the vblank-disabling code could be
skipped if there is no disable_vblank callback.

 drivers/gpu/drm/drm_irq.c |  103 +---
 include/drm/drmP.h|5 ++-
 2 files changed, 81 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 9d3a503..2f107c5 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -77,45 +77,59 @@ int drm_irq_by_busid(struct drm_device *dev, void *data,
return 0;
 }

-static void vblank_disable_fn(unsigned long arg)
+/* After VBLANK_CONSEC_THRESHOLD consecutive non-ignored vblank interrupts,
+ * vblanks will be left on. */
+#define VBLANK_CONSEC_THRESHOLD 3
+
+static void __vblank_disable_now(struct drm_device *dev, int crtc, int force)
+{
+   if (!dev->vblank_disable_allowed)
+   return;
+
+   if (atomic_read(>vblank_refcount[crtc]) == 0 && 
dev->vblank_enabled[crtc] &&
+   (dev->vblank_consecutive[crtc] < VBLANK_CONSEC_THRESHOLD || 
force))
+   {
+   DRM_DEBUG("disabling vblank on crtc %d\n", crtc);
+   dev->last_vblank[crtc] =
+   dev->driver->get_vblank_counter(dev, crtc);
+   dev->driver->disable_vblank(dev, crtc);
+   dev->vblank_enabled[crtc] = 0;
+   if (force)
+   dev->vblank_consecutive[crtc] = 0;
+   }
+}
+
+static void vblank_disable_now(struct drm_device *dev, int crtc, int force)
 {
-   struct drm_device *dev = (struct drm_device *)arg;
unsigned long irqflags;
-   int i;

if (!dev->vblank_disable_allowed)
return;

-   for (i = 0; i < dev->num_crtcs; i++) {
-   spin_lock_irqsave(>vbl_lock, irqflags);
-   if (atomic_read(>vblank_refcount[i]) == 0 &&
-   dev->vblank_enabled[i]) {
-   DRM_DEBUG("disabling vblank on crtc %d\n", 

[Bug 32535] Graphics corruption after resume from hibernate on Thinkpad SL510 (RV710 0x1002:0x9553)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=32535

--- Comment #4 from Alex Deucher  2010-12-20 13:47:01 PST 
---
Created an attachment (id=41318)
 View: https://bugs.freedesktop.org/attachment.cgi?id=41318
 Review: https://bugs.freedesktop.org/review?bug=32535=41318

possible fix

Does this kernel patch help?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 32535] Graphics corruption after resume from hibernate on Thinkpad SL510 (RV710 0x1002:0x9553)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=32535

--- Comment #3 from Robert Hooker (Sarvatt)  2010-12-20 
13:44:10 PST ---
(In reply to comment #1)
> Does a newer kernel (2.6.36 or 2.6.37) help?

He tried a git checkout from today with no luck, up to commit
55ec86f848a5f872fd43f5d7206464a0af419110

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 32535] Graphics corruption after resume from hibernate on Thinkpad SL510 (RV710 0x1002:0x9553)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=32535

--- Comment #2 from Robert Hooker (Sarvatt)  2010-12-20 
13:42:12 PST ---
Created an attachment (id=41317)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=41317)
kernel log showing the problem

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 32535] Graphics corruption after resume from hibernate on Thinkpad SL510 (RV710 0x1002:0x9553)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=32535

--- Comment #1 from Alex Deucher  2010-12-20 13:41:20 PST 
---
Does a newer kernel (2.6.36 or 2.6.37) help?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 32535] Graphics corruption after resume from hibernate on Thinkpad SL510 (RV710 0x1002:0x9553)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=32535

Alex Deucher  changed:

   What|Removed |Added

Product|xorg|DRI
  Component|Driver/Radeon   |DRM/Radeon
 AssignedTo|xorg-driver-ati at lists.x.org |dri-devel at 
lists.freedesktop
   ||.org
  QAContact|xorg-team at lists.x.org   |

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

Definition of R_0003C2_GENMO_WT seems wrong

[Alex Deucher]

On Sun, Dec 19, 2010 at 9:48 AM, Tijl Coosemans  wrote:
> Hi,
>
> In drivers/gpu/drm/radeon/r100d.h R_0003C2_GENMO_WT is defined as 0x3C0.
> I think this should be 0x3C2.
>
> Note that the attached patch is untested.


Good catch.  Dave please apply.

Alex

>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-kms-fix-typo-int-r100d.h.patch
Type: text/x-patch
Size: 1264 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20101220/903831ec/attachment.bin>

Freescale Linux BSP review

[Jerome Glisse]

On Mon, Dec 20, 2010 at 12:41 PM, Matt Sealey  wrote:
> On Mon, Dec 20, 2010 at 11:17 AM, Jerome Glisse  wrote:
>> On Mon, Dec 20, 2010 at 11:18 AM, Matt Sealey  wrote:
>>> On Mon, Dec 13, 2010 at 9:18 AM, Arnd Bergmann  wrote:
 On Monday 13 December 2010, Jammy Zhou wrote:
> On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij  linaro.org>wrote:
>
> > On 11 December 2010 22:41, Arnd Bergmann  wrote:
> >
> > * amd-gpu -- a single but huge driver for the GPU. As is normally the
> >> ? ? ? ? ? ? case with GPU drivers, we can expect long discussions
> >> ? ? ? ? ? ? before it will get considered for mainline
> >> ?4 patches
> >> ?98 files changed, 278321 insertions(+), 0 deletions(-)
> >>
> >
> > Just out of curiosity, following the discussion between Dave Airlie
> > and Codeaurora this summer re GPU driver shims.
> >
> > Is the AMD GPU exposing all functionality in its kernel driver or
> > is there some userspace blob somewhere with lots of e.g. GL
> > goodies?
> >
> All the functionality for the kernel driver of AMD GPU Z430/Z160 (now
> belongs to Qualcom) is exposed. But we need accompanied userspace library 
> to
> call these functionality (buffer management, command submission, ...).

 Who owns these components? If it's closed source, the only options we
 have are lobbying for complete release of the specs for a reimplementation
 or reverse-engineering the drivers, which may at least get easier with
 a user space driver than it would be with a kernel driver.

 Until there is a solution with an open source user space part, I would
 suggest that the driver better be dropped from the Freescale BSP and
 we should at least not waste time reviewing it.
>>>
>>> The concerns about host memory access via the GPU driver are valid but
>>> unnecessary. The GPU MMU directly intervenes on memory access and can
>>> only modify memory space allocated to the GPU resource - getting data
>>> into this memory requires some extreme manual intervention if not done
>>> by the kernel driver itself; this memory area is set internally by the
>>> platform device resource.. As such (on the i.MX515 at least) the top
>>> 64MB of memory reserved for the GPU is the only memory you need to
>>> worry about, and any "corruption" will be limited to invalid API usage
>>> which is also checked with assertions and other protection mechanisms.
>>> Any other "unsecured" memory location such as system RAM cannot be
>>> affected as the GPU MMU will not write or read any other memory than
>>> the defined resource. It is not an outside possibility that you may
>>> abuse the GPU to corrupt graphics RAM... but you can do that with any
>>> GPU even with security checks.
>>
>> Security check of radeon GPU are advance enough to even catch and
>> forbid overwriting other process video memory (this is more or less
>> true depending on the generation you are looking at).
>>
>>> Ownership of the code is dependent on who licensed it. I do not think
>>> Linaro need be so concerned over opensourcing or reimplementing
>>> drivers. The fact that the kernel driver is open source as it is, and
>>> this is by far the most important part. The userspace library is
>>> closed because it is proprietary; and I think it is well outside
>>> Linaro's remit to lobby for opensourcing of proprietary code simply to
>>> meet an esoteric and needless demand for source code access (as it
>>> stands, you can get source code access by signing the usual plethora
>>> of NDAs with the appropriate vendor, as Genesi has done). It is my
>>> understanding that Freescale/AMD and Qualcomm maintain seperate forks
>>> of the driver and do not cooperate on development, and in any case,
>>> Linaro does not include Qualcomm anyway, therefore it is also to my
>>> understanding that this discussion is also beyond Linaro's remit.
>>>
>>> Can't we all just be happy that we actually have 3D drivers?
>>
>> So here you are advocating that we should accept any open source code
>> inside the kernel just because it's open source and we love open
>> source ? This is not how i understand the linux kernel project, we
>> should not accept any open source driver that just add new api that we
>> can't audit, test or understand. From my point of view any driver &
>> new API should be introduced to support open source userspace. If GPU
>> manufacturer don't want to open source their stack that's their issue
>> but they should live with the pain of not having upstream kernel
>> either. I believe, here i am just reformulating Dave point.
>
> The code may need improvement but that's no reason to run around
> saying everything needs to be open sourced, and that the solution is
> in fact to reverse engineer the thing rather than accept it as the
> current solution. Given how long nouveau and later Radeon card support
> has taken in real life, even with full documentation from AMD, I
> 

[PATCH][next] drm/vmwgfx: Let SVGA_REG_NUM_DISPLAYS decide output connectivity

[Thomas Hellstrom]

Dave,

Please don't apply this patch. We're looking at another solution.

/Thomas


On 12/16/2010 03:22 PM, Thomas Hellstrom wrote:
> Makes the user able to determine the number of connected outputs from
> the VMware GUI.
>
> Signed-off-by: Thomas Hellstrom
> ---
>   drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c |   13 ++---
>   1 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
> index 29113c9..335c91c 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
> @@ -340,9 +340,16 @@ static enum drm_connector_status
>   vmw_ldu_connector_detect(struct drm_connector *connector,
>bool force)
>   {
> - if (vmw_connector_to_ldu(connector)->pref_active)
> - return connector_status_connected;
> - return connector_status_disconnected;
> + uint32_t num_displays;
> + struct drm_device *dev = connector->dev;
> + struct vmw_private *dev_priv = vmw_priv(dev);
> +
> + mutex_lock(_priv->hw_mutex);
> + num_displays = vmw_read(dev_priv, SVGA_REG_NUM_DISPLAYS);
> + mutex_unlock(_priv->hw_mutex);
> +
> + return ((vmw_connector_to_ldu(connector)->base.unit<  num_displays) ?
> + connector_status_connected : connector_status_disconnected);
>   }
>
>   static struct drm_display_mode vmw_ldu_connector_builtin[] = {
>

[Bug 30507] Caster (commercial game) crash.

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=30507

--- Comment #3 from roughl  2010-12-20 12:39:32 PST ---
Caster works for me.
Kernel 2.6.36.2
Mesa 7.10-devel 20101220
xf86-video-ati git-20101129
libdrm git-20101129
OS is x86_64
KMS with Radeon HD4850 (RV770 9442)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH 2/2] drm/radeon/kms/evergreen: reset the grbm blocks at resume and init

[Alex Deucher]

This fixes module reloading and resume as the gfx block seems to
be left in a bad state in some cases.

Signed-off-by: Alex Deucher 
Cc: stable at kernel.org
---
 drivers/gpu/drm/radeon/evergreen.c |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 8b82749..056b93c 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -2701,6 +2701,11 @@ int evergreen_resume(struct radeon_device *rdev)
 {
int r;

+   /* reset the asic, the gfx blocks are often in a bad state
+* after the driver is unloaded or after a resume
+*/
+   if (radeon_asic_reset(rdev))
+   dev_warn(rdev->dev, "GPU reset failed !\n");
/* Do not reset GPU before posting, on rv770 hw unlike on r500 hw,
 * posting will perform necessary task to bring back GPU into good
 * shape.
@@ -2861,6 +2866,11 @@ int evergreen_init(struct radeon_device *rdev)
r = radeon_atombios_init(rdev);
if (r)
return r;
+   /* reset the asic, the gfx blocks are often in a bad state
+* after the driver is unloaded or after a resume
+*/
+   if (radeon_asic_reset(rdev))
+   dev_warn(rdev->dev, "GPU reset failed !\n");
/* Post card if necessary */
if (!evergreen_card_posted(rdev)) {
if (!rdev->bios) {
-- 
1.7.2.3

[PATCH 1/2] drm/radeon/kms: fix evergreen asic reset

[Alex Deucher]

Only reset the grbm blocks, srbm tends to lock the GPU
if not done properly and in most cases is not necessary.
Also, no need to call asic init after reset the grbm blocks.

Signed-off-by: Alex Deucher 
Cc: stable at kernel.org
---
 drivers/gpu/drm/radeon/evergreen.c |   15 ---
 1 files changed, 0 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 901f366..8b82749 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -2036,7 +2036,6 @@ bool evergreen_gpu_is_lockup(struct radeon_device *rdev)
 static int evergreen_gpu_soft_reset(struct radeon_device *rdev)
 {
struct evergreen_mc_save save;
-   u32 srbm_reset = 0;
u32 grbm_reset = 0;

dev_info(rdev->dev, "GPU softreset \n");
@@ -2075,16 +2074,6 @@ static int evergreen_gpu_soft_reset(struct radeon_device 
*rdev)
udelay(50);
WREG32(GRBM_SOFT_RESET, 0);
(void)RREG32(GRBM_SOFT_RESET);
-
-   /* reset all the system blocks */
-   srbm_reset = SRBM_SOFT_RESET_ALL_MASK;
-
-   dev_info(rdev->dev, "  SRBM_SOFT_RESET=0x%08X\n", srbm_reset);
-   WREG32(SRBM_SOFT_RESET, srbm_reset);
-   (void)RREG32(SRBM_SOFT_RESET);
-   udelay(50);
-   WREG32(SRBM_SOFT_RESET, 0);
-   (void)RREG32(SRBM_SOFT_RESET);
/* Wait a little for things to settle down */
udelay(50);
dev_info(rdev->dev, "  GRBM_STATUS=0x%08X\n",
@@ -2095,10 +2084,6 @@ static int evergreen_gpu_soft_reset(struct radeon_device 
*rdev)
RREG32(GRBM_STATUS_SE1));
dev_info(rdev->dev, "  SRBM_STATUS=0x%08X\n",
RREG32(SRBM_STATUS));
-   /* After reset we need to reinit the asic as GPU often endup in an
-* incoherent state.
-*/
-   atom_asic_init(rdev->mode_info.atom_context);
evergreen_mc_resume(rdev, );
return 0;
 }
-- 
1.7.2.3

[Bug 32455] Crash with mame using OpenGL with newest Gallium on Radeon 4350

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=32455

--- Comment #4 from Jerome Glisse  2010-12-20 
12:34:33 PST ---
Pushed a fix upstream please confirm it fix the issue for you too

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[patch -next] nouveua: sizeof() vs ARRAY_SIZE()

[Dan Carpenter]

ARRAY_SIZE() was intended here, sizeof() is too large.

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..58e98ad 100644
--- a/drivers/gpu/drm/nouveau/nv50_vram.c
+++ b/drivers/gpu/drm/nouveau/nv50_vram.c
@@ -42,7 +42,7 @@ nv50_vram_flags_valid(struct drm_device *dev, u32 tile_flags)
 {
int type = (tile_flags & NOUVEAU_GEM_TILE_LAYOUT_MASK) >> 8;

-   if (likely(type < sizeof(types) && types[type]))
+   if (likely(type < ARRAY_SIZE(types) && types[type]))
return true;
return false;
 }

Freescale Linux BSP review

[Jerome Glisse]

On Mon, Dec 20, 2010 at 11:18 AM, Matt Sealey  wrote:
> On Mon, Dec 13, 2010 at 9:18 AM, Arnd Bergmann  wrote:
>> On Monday 13 December 2010, Jammy Zhou wrote:
>>> On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij >> linaro.org>wrote:
>>>
>>> > On 11 December 2010 22:41, Arnd Bergmann  wrote:
>>> >
>>> > * amd-gpu -- a single but huge driver for the GPU. As is normally the
>>> >> ? ? ? ? ? ? case with GPU drivers, we can expect long discussions
>>> >> ? ? ? ? ? ? before it will get considered for mainline
>>> >> ?4 patches
>>> >> ?98 files changed, 278321 insertions(+), 0 deletions(-)
>>> >>
>>> >
>>> > Just out of curiosity, following the discussion between Dave Airlie
>>> > and Codeaurora this summer re GPU driver shims.
>>> >
>>> > Is the AMD GPU exposing all functionality in its kernel driver or
>>> > is there some userspace blob somewhere with lots of e.g. GL
>>> > goodies?
>>> >
>>> All the functionality for the kernel driver of AMD GPU Z430/Z160 (now
>>> belongs to Qualcom) is exposed. But we need accompanied userspace library to
>>> call these functionality (buffer management, command submission, ...).
>>
>> Who owns these components? If it's closed source, the only options we
>> have are lobbying for complete release of the specs for a reimplementation
>> or reverse-engineering the drivers, which may at least get easier with
>> a user space driver than it would be with a kernel driver.
>>
>> Until there is a solution with an open source user space part, I would
>> suggest that the driver better be dropped from the Freescale BSP and
>> we should at least not waste time reviewing it.
>
> The concerns about host memory access via the GPU driver are valid but
> unnecessary. The GPU MMU directly intervenes on memory access and can
> only modify memory space allocated to the GPU resource - getting data
> into this memory requires some extreme manual intervention if not done
> by the kernel driver itself; this memory area is set internally by the
> platform device resource.. As such (on the i.MX515 at least) the top
> 64MB of memory reserved for the GPU is the only memory you need to
> worry about, and any "corruption" will be limited to invalid API usage
> which is also checked with assertions and other protection mechanisms.
> Any other "unsecured" memory location such as system RAM cannot be
> affected as the GPU MMU will not write or read any other memory than
> the defined resource. It is not an outside possibility that you may
> abuse the GPU to corrupt graphics RAM... but you can do that with any
> GPU even with security checks.

Security check of radeon GPU are advance enough to even catch and
forbid overwriting other process video memory (this is more or less
true depending on the generation you are looking at).

> Ownership of the code is dependent on who licensed it. I do not think
> Linaro need be so concerned over opensourcing or reimplementing
> drivers. The fact that the kernel driver is open source as it is, and
> this is by far the most important part. The userspace library is
> closed because it is proprietary; and I think it is well outside
> Linaro's remit to lobby for opensourcing of proprietary code simply to
> meet an esoteric and needless demand for source code access (as it
> stands, you can get source code access by signing the usual plethora
> of NDAs with the appropriate vendor, as Genesi has done). It is my
> understanding that Freescale/AMD and Qualcomm maintain seperate forks
> of the driver and do not cooperate on development, and in any case,
> Linaro does not include Qualcomm anyway, therefore it is also to my
> understanding that this discussion is also beyond Linaro's remit.
>
> Can't we all just be happy that we actually have 3D drivers?

So here you are advocating that we should accept any open source code
inside the kernel just because it's open source and we love open
source ? This is not how i understand the linux kernel project, we
should not accept any open source driver that just add new api that we
can't audit, test or understand. From my point of view any driver &
new API should be introduced to support open source userspace. If GPU
manufacturer don't want to open source their stack that's their issue
but they should live with the pain of not having upstream kernel
either. I believe, here i am just reformulating Dave point.

Cheers,
Jerome Glisse

[Bug 31037] [r300g] Unwanted checkerboard effect on sprites / textures

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=31037

--- Comment #11 from Marek Ol??k  2010-12-20 12:01:19 PST 
---
Most probably, yes.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 31037] [r300g] Unwanted checkerboard effect on sprites / textures

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=31037

Gerwin  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #10 from Gerwin  2010-12-20 11:51:36 
PST ---
Today I updated from xorg edgers ppa and the bug in Nexuiz is fixed! Maybe this
patch fixed it?
http://cgit.freedesktop.org/mesa/mesa/commit/?id=daffaca53e47faeaaefb98ca46fe4870133d9f02

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[stable] [00/66] 2.6.36.1-stable review

[Greg KH]

On Wed, Dec 08, 2010 at 03:17:20PM +1000, Ben Skeggs wrote:
> On Sat, 2010-11-20 at 11:15 -0500, Andrew Lutomirski wrote:
> > On Sat, Nov 20, 2010 at 10:52 AM, Greg KH  wrote:
> > > On Sat, Nov 20, 2010 at 09:24:05AM -0500, Andy Lutomirski wrote:
> > >> Greg KH wrote:
> > >>> This is the start of the stable review cycle for the 2.6.36.1 release.
> > >>> There are 66 patches in this series, all will be posted as a response
> > >>> to this one.  If anyone has any issues with these being applied, please
> > >>> let us know.  If anyone is a maintainer of the proper subsystem, and
> > >>> wants to add a Signed-off-by: line to the patch, please respond with it.
> > >>
> > >> Can you add ab838338a2a9e0cb8346eb0cab9977be13e8dce5?  (Somehow the cc:
> > >> stable got eaten, but 2.6.36 definitely needs this one.  2.6.35 probably
> > >> does as well but I haven't 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 

Now applied, thanks.

greg k-h

Freescale Linux BSP review

[Matt Sealey]

On Mon, Dec 20, 2010 at 11:17 AM, Jerome Glisse  wrote:
> On Mon, Dec 20, 2010 at 11:18 AM, Matt Sealey  wrote:
>> On Mon, Dec 13, 2010 at 9:18 AM, Arnd Bergmann  wrote:
>>> On Monday 13 December 2010, Jammy Zhou wrote:
 On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij >>> linaro.org>wrote:

 > On 11 December 2010 22:41, Arnd Bergmann  wrote:
 >
 > * amd-gpu -- a single but huge driver for the GPU. As is normally the
 >> ? ? ? ? ? ? case with GPU drivers, we can expect long discussions
 >> ? ? ? ? ? ? before it will get considered for mainline
 >> ?4 patches
 >> ?98 files changed, 278321 insertions(+), 0 deletions(-)
 >>
 >
 > Just out of curiosity, following the discussion between Dave Airlie
 > and Codeaurora this summer re GPU driver shims.
 >
 > Is the AMD GPU exposing all functionality in its kernel driver or
 > is there some userspace blob somewhere with lots of e.g. GL
 > goodies?
 >
 All the functionality for the kernel driver of AMD GPU Z430/Z160 (now
 belongs to Qualcom) is exposed. But we need accompanied userspace library 
 to
 call these functionality (buffer management, command submission, ...).
>>>
>>> Who owns these components? If it's closed source, the only options we
>>> have are lobbying for complete release of the specs for a reimplementation
>>> or reverse-engineering the drivers, which may at least get easier with
>>> a user space driver than it would be with a kernel driver.
>>>
>>> Until there is a solution with an open source user space part, I would
>>> suggest that the driver better be dropped from the Freescale BSP and
>>> we should at least not waste time reviewing it.
>>
>> The concerns about host memory access via the GPU driver are valid but
>> unnecessary. The GPU MMU directly intervenes on memory access and can
>> only modify memory space allocated to the GPU resource - getting data
>> into this memory requires some extreme manual intervention if not done
>> by the kernel driver itself; this memory area is set internally by the
>> platform device resource.. As such (on the i.MX515 at least) the top
>> 64MB of memory reserved for the GPU is the only memory you need to
>> worry about, and any "corruption" will be limited to invalid API usage
>> which is also checked with assertions and other protection mechanisms.
>> Any other "unsecured" memory location such as system RAM cannot be
>> affected as the GPU MMU will not write or read any other memory than
>> the defined resource. It is not an outside possibility that you may
>> abuse the GPU to corrupt graphics RAM... but you can do that with any
>> GPU even with security checks.
>
> Security check of radeon GPU are advance enough to even catch and
> forbid overwriting other process video memory (this is more or less
> true depending on the generation you are looking at).
>
>> Ownership of the code is dependent on who licensed it. I do not think
>> Linaro need be so concerned over opensourcing or reimplementing
>> drivers. The fact that the kernel driver is open source as it is, and
>> this is by far the most important part. The userspace library is
>> closed because it is proprietary; and I think it is well outside
>> Linaro's remit to lobby for opensourcing of proprietary code simply to
>> meet an esoteric and needless demand for source code access (as it
>> stands, you can get source code access by signing the usual plethora
>> of NDAs with the appropriate vendor, as Genesi has done). It is my
>> understanding that Freescale/AMD and Qualcomm maintain seperate forks
>> of the driver and do not cooperate on development, and in any case,
>> Linaro does not include Qualcomm anyway, therefore it is also to my
>> understanding that this discussion is also beyond Linaro's remit.
>>
>> Can't we all just be happy that we actually have 3D drivers?
>
> So here you are advocating that we should accept any open source code
> inside the kernel just because it's open source and we love open
> source ? This is not how i understand the linux kernel project, we
> should not accept any open source driver that just add new api that we
> can't audit, test or understand. From my point of view any driver &
> new API should be introduced to support open source userspace. If GPU
> manufacturer don't want to open source their stack that's their issue
> but they should live with the pain of not having upstream kernel
> either. I believe, here i am just reformulating Dave point.

The code may need improvement but that's no reason to run around
saying everything needs to be open sourced, and that the solution is
in fact to reverse engineer the thing rather than accept it as the
current solution. Given how long nouveau and later Radeon card support
has taken in real life, even with full documentation from AMD, I
seriously doubt Linaro are going to be the ones to somehow make the
world change for OpenSource embedded GPU graphics. Linaro doesn't
exist just to spend all 

[PATCH] drm/radeon/kms: reorder display resume to avoid problems

[Alex Deucher]

On resume, we were attemping to unblank the displays before the
timing and plls had be reprogrammed which led to atom timeouts
waiting for things that are not yet programmed.  Re-program
the mode first, then reset the dpms state.

This fixes the infamous atombios timeouts on resume.

Signed-off-by: Alex Deucher 
Cc: stable at kernel.org
---
 drivers/gpu/drm/radeon/atombios_crtc.c |3 ++-
 drivers/gpu/drm/radeon/radeon_device.c |9 -
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 6a4f090..b0ab185 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -253,7 +253,8 @@ void atombios_crtc_dpms(struct drm_crtc *crtc, int mode)
case DRM_MODE_DPMS_SUSPEND:
case DRM_MODE_DPMS_OFF:
drm_vblank_pre_modeset(dev, radeon_crtc->crtc_id);
-   atombios_blank_crtc(crtc, ATOM_ENABLE);
+   if (radeon_crtc->enabled)
+   atombios_blank_crtc(crtc, ATOM_ENABLE);
if (ASIC_IS_DCE3(rdev))
atombios_enable_crtc_memreq(crtc, ATOM_DISABLE);
atombios_enable_crtc(crtc, ATOM_DISABLE);
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index 5da80d5..fcf0acb 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -925,11 +925,6 @@ int radeon_resume_kms(struct drm_device *dev)
radeon_pm_resume(rdev);
radeon_restore_bios_scratch_regs(rdev);

-   /* turn on display hw */
-   list_for_each_entry(connector, >mode_config.connector_list, head) {
-   drm_helper_connector_dpms(connector, DRM_MODE_DPMS_ON);
-   }
-
radeon_fbdev_set_suspend(rdev, 0);
release_console_sem();

@@ -937,6 +932,10 @@ int radeon_resume_kms(struct drm_device *dev)
radeon_hpd_init(rdev);
/* blat the mode back in */
drm_helper_resume_force_mode(dev);
+   /* turn on display hw */
+   list_for_each_entry(connector, >mode_config.connector_list, head) {
+   drm_helper_connector_dpms(connector, DRM_MODE_DPMS_ON);
+   }
return 0;
 }

-- 
1.7.1.1

[PATCH] drm/radeon/kms/atom: clean up op_mask handler

[Alex Deucher]

Readability cleanup and fix debugging output, no
functional change.
Reported-by: Frank Huang 

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/atom.c |   14 +++---
 1 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
index 8e421f6..9b0773b 100644
--- a/drivers/gpu/drm/radeon/atom.c
+++ b/drivers/gpu/drm/radeon/atom.c
@@ -733,16 +733,16 @@ static void atom_op_jump(atom_exec_context *ctx, int 
*ptr, int arg)
 static void atom_op_mask(atom_exec_context *ctx, int *ptr, int arg)
 {
uint8_t attr = U8((*ptr)++);
-   uint32_t dst, src1, src2, saved;
+   uint32_t dst, mask, src, saved;
int dptr = *ptr;
SDEBUG("   dst: ");
dst = atom_get_dst(ctx, arg, attr, ptr, , 1);
-   SDEBUG("   src1: ");
-   src1 = atom_get_src_direct(ctx, ((attr >> 3) & 7), ptr);
-   SDEBUG("   src2: ");
-   src2 = atom_get_src(ctx, attr, ptr);
-   dst &= src1;
-   dst |= src2;
+   mask = atom_get_src_direct(ctx, ((attr >> 3) & 7), ptr);
+   SDEBUG("   mask: 0x%08x", mask);
+   SDEBUG("   src: ");
+   src = atom_get_src(ctx, attr, ptr);
+   dst &= mask;
+   dst |= src;
SDEBUG("   dst: ");
atom_put_dst(ctx, arg, attr, , dst, saved);
 }
-- 
1.7.1.1

[Bug 32511] glDrawPixels broken on savage

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=32511

--- Comment #4 from Tormod Volden  2010-12-20 
10:53:44 PST ---
Just in case someone looks at it, in the above backtrace I had disabled the
fast_draw_rgba_pixels so the drawing is done by savageWriteRGBASpan_565()
through the "slow" path. Normally, with the fast path, savageWriteRGBSpan_565()
is used, and the result is the same.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

i915 modeset defunct [was: mmotm 2010-12-16-14-56 uploaded]

[Jiri Slaby]

On 12/20/2010 10:49 AM, Jiri Slaby wrote:
> On 12/16/2010 11:56 PM, akpm at linux-foundation.org wrote:
>> The mm-of-the-moment snapshot 2010-12-16-14-56 has been uploaded to
> 
> Hi, there is a regression against 2010-12-02-16-34 in i915. When modeset
> is used, my G33 produces no signal to the monitor (black screen, power
> led blinks).
...
> any ideas?

Oh, looks like:
https://bugzilla.kernel.org/show_bug.cgi?id=25242

regards,
-- 
js

i915 modeset defunct [was: mmotm 2010-12-16-14-56 uploaded]

[Jiri Slaby]

On 12/16/2010 11:56 PM, akpm at linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2010-12-16-14-56 has been uploaded to

Hi, there is a regression against 2010-12-02-16-34 in i915. When modeset
is used, my G33 produces no signal to the monitor (black screen, power
led blinks).

00:00.0 Host bridge [0600]: Intel Corporation 82G33/G31/P35/P31 Express
DRAM Controller [8086:29c0] (rev 02)
Subsystem: Intel Corporation 82G33/G31/P35/P31 Express DRAM
Controller [8086:29c0]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
SERR- 
Kernel driver in use: agpgart-intel
00: 86 80 c0 29 06 00 90 20 02 00 00 06 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 c0 29
30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00
40: 01 90 d1 fe 01 00 00 00 01 40 d1 fe 00 00 00 00
50: 00 00 30 02 c9 03 00 00 00 00 00 00 00 00 00 00
60: 01 00 00 e0 00 00 00 00 01 80 d1 fe 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 10 11 11 00 00 33 33 00 5f 00 72 00 00 0a 38 00
a0: 60 00 c0 1c 00 00 80 af 00 00 60 af 00 00 60 af
b0: 00 b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 49 00 00 00 00 00 00 5b
e0: 09 00 0b 01 00 00 00 00 01 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 90 0f 03 00 00 00 00 00

00:02.0 VGA compatible controller [0300]: Intel Corporation 82G33/G31
Express Integrated Graphics Controller [8086:29c2] (rev 02) (prog-if 00
[VGA controller])
Subsystem: Intel Corporation 82G33/G31 Express Integrated
Graphics Controller [8086:29c2]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
SERR-  [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0300c  Data: 4161
Capabilities: [d0] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: i915
00: 86 80 c2 29 07 04 90 00 02 00 00 03 00 00 00 00
10: 00 00 b8 fe 01 ec 00 00 08 00 00 d0 00 00 a0 fe
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 c2 29
30: 00 00 00 00 90 00 00 00 00 00 00 00 05 01 00 00
40: 09 00 0b 01 00 00 00 00 01 00 00 00 00 00 00 00
50: 00 00 30 02 c9 03 00 00 00 00 00 00 00 00 80 af
60: 00 00 02 02 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 05 d0 01 00 0c 30 e0 fe 61 41 00 00 00 00 00 00
a0: 11 11 00 00 00 00 06 03 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 01 00 22 00 00 00 00 00 00 00 00 00 00 01 02 00
e0: 00 00 00 00 00 00 00 00 00 80 00 00 00 00 00 00
f0: 12 00 03 00 00 00 00 00 90 0f 03 00 e4 e0 5b af


any ideas?

thanks,
-- 
js

[Bug 32422] Large images displayed in Firefox appear corrupted

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=32422

--- Comment #9 from Da Fox  2010-12-20 10:35:54 
PST ---
(In reply to comment #8)
> (In reply to comment #7)
> > Even with the patch for bug 31708 applied, I see the same corruption in 
> > firefox [...]
> 
> That's with the latest version (v3) of the patch? (Jerome even submitted v4
> later, but I don't think the difference from v3 should be relevant for this
> problem; wouldn't hurt to try of course)

I have tried with the version present in 2.6.37-rc6, which according to the
changelog
(http://www.kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.37-rc6) is
v3. 

ps.
I only noticed that there were new posts on this bug after submitting my
comment on the other bug.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 32511] glDrawPixels broken on savage

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=32511

--- Comment #3 from Tormod Volden  2010-12-20 
10:34:19 PST ---
This is tested with latest 2.6.37 kernel, and libdrm 2.4.21.
LIBGL_ALWAYS_INDIRECT does not change anything, other than the xserver crashing
when drawpix exits. LIBGL_ALWAYS_SOFTWARE works fine. I have a Savage TwisterK
card, Dewey in the Ubuntu report has a SuperSavage IX/C.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 31708] kernel oops when loading large images with firefox

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=31708

--- Comment #14 from Da Fox  2010-12-20 10:25:03 
PST ---
(In reply to comment #12)
> (In reply to comment #11)
> > Created an attachment (id=40482)
 View: https://bugs.freedesktop.org/attachment.cgi?id=40482
 Review: https://bugs.freedesktop.org/review?bug=31708=40482

> > Forbid big bo allcoation
> > 
> > Attached wrong patch sorry here it's please test and report
> 
> This one works.  Image(s) are displayed as they should.

Hi, I'm the reporter of bug #32422. This patch appears to be already applied to
2.6.47-rc6. However the image at http://xkcd.com/802_large/ still display
corrupted for me.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

Freescale Linux BSP review

[Matt Sealey]

On Mon, Dec 13, 2010 at 9:18 AM, Arnd Bergmann  wrote:
> On Monday 13 December 2010, Jammy Zhou wrote:
>> On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij > linaro.org>wrote:
>>
>> > On 11 December 2010 22:41, Arnd Bergmann  wrote:
>> >
>> > * amd-gpu -- a single but huge driver for the GPU. As is normally the
>> >> ? ? ? ? ? ? case with GPU drivers, we can expect long discussions
>> >> ? ? ? ? ? ? before it will get considered for mainline
>> >> ?4 patches
>> >> ?98 files changed, 278321 insertions(+), 0 deletions(-)
>> >>
>> >
>> > Just out of curiosity, following the discussion between Dave Airlie
>> > and Codeaurora this summer re GPU driver shims.
>> >
>> > Is the AMD GPU exposing all functionality in its kernel driver or
>> > is there some userspace blob somewhere with lots of e.g. GL
>> > goodies?
>> >
>> All the functionality for the kernel driver of AMD GPU Z430/Z160 (now
>> belongs to Qualcom) is exposed. But we need accompanied userspace library to
>> call these functionality (buffer management, command submission, ...).
>
> Who owns these components? If it's closed source, the only options we
> have are lobbying for complete release of the specs for a reimplementation
> or reverse-engineering the drivers, which may at least get easier with
> a user space driver than it would be with a kernel driver.
>
> Until there is a solution with an open source user space part, I would
> suggest that the driver better be dropped from the Freescale BSP and
> we should at least not waste time reviewing it.

The concerns about host memory access via the GPU driver are valid but
unnecessary. The GPU MMU directly intervenes on memory access and can
only modify memory space allocated to the GPU resource - getting data
into this memory requires some extreme manual intervention if not done
by the kernel driver itself; this memory area is set internally by the
platform device resource.. As such (on the i.MX515 at least) the top
64MB of memory reserved for the GPU is the only memory you need to
worry about, and any "corruption" will be limited to invalid API usage
which is also checked with assertions and other protection mechanisms.
Any other "unsecured" memory location such as system RAM cannot be
affected as the GPU MMU will not write or read any other memory than
the defined resource. It is not an outside possibility that you may
abuse the GPU to corrupt graphics RAM... but you can do that with any
GPU even with security checks.

Ownership of the code is dependent on who licensed it. I do not think
Linaro need be so concerned over opensourcing or reimplementing
drivers. The fact that the kernel driver is open source as it is, and
this is by far the most important part. The userspace library is
closed because it is proprietary; and I think it is well outside
Linaro's remit to lobby for opensourcing of proprietary code simply to
meet an esoteric and needless demand for source code access (as it
stands, you can get source code access by signing the usual plethora
of NDAs with the appropriate vendor, as Genesi has done). It is my
understanding that Freescale/AMD and Qualcomm maintain seperate forks
of the driver and do not cooperate on development, and in any case,
Linaro does not include Qualcomm anyway, therefore it is also to my
understanding that this discussion is also beyond Linaro's remit.

Can't we all just be happy that we actually have 3D drivers?

-- 
Matt Sealey 
Product Development Analyst, Genesi USA, Inc.

[PATCH] vgaarb: use bridges to control VGA routing where possible. (v2)

[Dave Airlie]

From: Dave Airlie 

So in a lot of modern systems, a GPU will always be below a parent bridge that 
won't share with any other GPUs. This means VGA arbitration on those GPUs can 
be controlled by using the bridge routing instead of io/mem decodes.

The problem is locating which GPUs share which upstream bridges. This patch 
attempts to identify all the GPUs which can be controlled via bridges, and ones 
that can't. This patch endeavours to work out the bridge sharing semantics.

When disabling GPUs via a bridge, it doesn't do irq callbacks or touch the 
io/mem decodes for the gpu.

v2: fixup & vs && and spaces round | from review.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/vga/vgaarb.c |  113 --
 drivers/pci/pci.c|   25 ++-
 include/linux/pci.h  |7 ++-
 3 files changed, 118 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
index c380c65..aab5c59 100644
--- a/drivers/gpu/vga/vgaarb.c
+++ b/drivers/gpu/vga/vgaarb.c
@@ -61,7 +61,7 @@ struct vga_device {
unsigned int mem_lock_cnt;  /* legacy MEM lock count */
unsigned int io_norm_cnt;   /* normal IO count */
unsigned int mem_norm_cnt;  /* normal MEM count */
-
+   bool bridge_has_one_vga;
/* allow IRQ enable/disable hook */
void *cookie;
void (*irq_set_state)(void *cookie, bool enable);
@@ -165,6 +165,8 @@ static struct vga_device *__vga_tryget(struct vga_device 
*vgadev,
unsigned int wants, legacy_wants, match;
struct vga_device *conflict;
unsigned int pci_bits;
+   u32 flags = 0;
+
/* Account for "normal" resources to lock. If we decode the legacy,
 * counterpart, we need to request it as well
 */
@@ -237,16 +239,23 @@ static struct vga_device *__vga_tryget(struct vga_device 
*vgadev,
/* looks like he doesn't have a lock, we can steal
 * them from him
 */
-   vga_irq_set_state(conflict, false);

+   flags = 0;
pci_bits = 0;
-   if (lwants & (VGA_RSRC_LEGACY_MEM|VGA_RSRC_NORMAL_MEM))
-   pci_bits |= PCI_COMMAND_MEMORY;
-   if (lwants & (VGA_RSRC_LEGACY_IO|VGA_RSRC_NORMAL_IO))
-   pci_bits |= PCI_COMMAND_IO;

-   pci_set_vga_state(conflict->pdev, false, pci_bits,
- change_bridge);
+   if (!conflict->bridge_has_one_vga) {
+   vga_irq_set_state(conflict, false);
+   flags |= PCI_VGA_STATE_CHANGE_DECODES;
+   if (lwants & (VGA_RSRC_LEGACY_MEM|VGA_RSRC_NORMAL_MEM))
+   pci_bits |= PCI_COMMAND_MEMORY;
+   if (lwants & (VGA_RSRC_LEGACY_IO|VGA_RSRC_NORMAL_IO))
+   pci_bits |= PCI_COMMAND_IO;
+   }
+
+   if (change_bridge)
+   flags |= PCI_VGA_STATE_CHANGE_BRIDGE;
+
+   pci_set_vga_state(conflict->pdev, false, pci_bits, flags);
conflict->owns &= ~lwants;
/* If he also owned non-legacy, that is no longer the case */
if (lwants & VGA_RSRC_LEGACY_MEM)
@@ -261,14 +270,24 @@ enable_them:
 * also have in "decodes". We can lock resources we don't decode but
 * not own them.
 */
+   flags = 0;
pci_bits = 0;
-   if (wants & (VGA_RSRC_LEGACY_MEM|VGA_RSRC_NORMAL_MEM))
-   pci_bits |= PCI_COMMAND_MEMORY;
-   if (wants & (VGA_RSRC_LEGACY_IO|VGA_RSRC_NORMAL_IO))
-   pci_bits |= PCI_COMMAND_IO;
-   pci_set_vga_state(vgadev->pdev, true, pci_bits, !!(wants & 
VGA_RSRC_LEGACY_MASK));

-   vga_irq_set_state(vgadev, true);
+   if (!vgadev->bridge_has_one_vga) {
+   flags |= PCI_VGA_STATE_CHANGE_DECODES;
+   if (wants & (VGA_RSRC_LEGACY_MEM|VGA_RSRC_NORMAL_MEM))
+   pci_bits |= PCI_COMMAND_MEMORY;
+   if (wants & (VGA_RSRC_LEGACY_IO|VGA_RSRC_NORMAL_IO))
+   pci_bits |= PCI_COMMAND_IO;
+   }
+   if (!!(wants & VGA_RSRC_LEGACY_MASK))
+   flags |= PCI_VGA_STATE_CHANGE_BRIDGE;
+
+   pci_set_vga_state(vgadev->pdev, true, pci_bits, flags);
+
+   if (!vgadev->bridge_has_one_vga) {
+   vga_irq_set_state(vgadev, true);
+   }
vgadev->owns |= (wants & vgadev->decodes);
 lock_them:
vgadev->locks |= (rsrc & VGA_RSRC_LEGACY_MASK);
@@ -421,6 +440,62 @@ bail:
 }
 EXPORT_SYMBOL(vga_put);

+/* Rules for using a bridge to control a VGA descendant decoding:
+   if a bridge has only one VGA descendant then it can be used
+   to control the VGA routing for that device.
+   It should always use the bridge closest to the device to control it.
+   If a bridge has a direct VGA descendant, but also have a 

smatch: nouveau: bogus compare against zero

[Dan Carpenter]

Hi Ben,

This is a new Smatch warning in linux-next.  It comes from: a11c3198c
"drm/nv50: import new vm code"

drivers/gpu/drm/nouveau/nv50_vm.c +104 nv50_vm_map(13)
warn: bogus compare against zero: 'i'

94  u32 block, i;
95
96  phys  = nv50_vm_addr(vma, pgt, phys, mem->memtype, 0);
97  pte <<= 3;
98  cnt <<= 3;
99
   100  while (cnt) {
   101  u32 offset_h = upper_32_bits(phys);
   102  u32 offset_l = lower_32_bits(phys);
   103
   104  for (i = 7; i >= 0; i--) {
^^

i is unsigned so this test is always true.

   105  block = 1 << (i + 3);
   106  if (cnt >= block && !(pte & (block - 1)))
   107  break;
   108  }
   109  offset_l |= (i << 7);

regards,
dan carpenter

[Bug 32277] overflow in calculate_miptree_layout_r300

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=32277

Alban Browaeys  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #4 from Alban Browaeys  2010-12-20 07:06:40 
PST ---
User reported the issue as fixed. Can be closed. Thank you

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 24462] r600: spread spectrum: flickering screen (bisected)

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=24462





--- Comment #11 from Alex Deucher   2010-12-20 
06:57:15 ---
I've sent the patch to Dave.  It should show up in his next drm pull request.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

--
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
--
___
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug 32312] openvg "lion" demo freezes the system & lockup GPU with r600g

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=32312

--- Comment #5 from Sergey Kondakov  2010-12-20 
02:44:02 PST ---
Created an attachment (id=41285)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=41285)
broken "Te$t" text.jpg

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 32312] openvg "lion" demo freezes the system & lockup GPU with r600g

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=32312

--- Comment #4 from Sergey Kondakov  2010-12-20 
02:42:42 PST ---
Created an attachment (id=41284)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=41284)
broken sp.jpg

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 32312] openvg "lion" demo freezes the system & lockup GPU with r600g

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=32312

--- Comment #3 from Sergey Kondakov  2010-12-20 
02:42:19 PST ---
Created an attachment (id=41283)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=41283)
broken lion.jpg

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 32312] openvg "lion" demo freezes the system & lockup GPU with r600g

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=32312

--- Comment #2 from Sergey Kondakov  2010-12-20 
02:36:04 PST ---
with commit c451aade889c3c0733fabab691f2a33643e8a054 it doesn't freeze but
rendering is broken

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[BUG] commit 541cc966915b6756e54c20eebe60ae957afdb537 cause no screen

[Wei Yongjun]

After commit 541cc966915b6756e54c20eebe60ae957afdb537, I can see
nothing in my screen, and the monitor is the same state as shutdown,
but can ssh to my computer.

Revert 541cc966915b6756e54c20eebe60ae957afdb537, every thing is OK.

Revert drm: Don't try and disable an encoder that was never enabled

This reverts commit 541cc966915b6756e54c20eebe60ae957afdb537.

I am not in the maillist, so if any reply, pls cc me, thanks.

# lspci
00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM 
Controller (rev 10)
00:02.0 VGA compatible controller: Intel Corporation 82G33/G31 Express 
Integrated Graphics Controller (rev 10)
00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio 
Controller (rev 01)
00:1c.0 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 1 (rev 
01)
00:1c.1 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 2 (rev 
01)
00:1d.0 USB Controller: Intel Corporation N10/ICH7 Family USB UHCI Controller 
#1 (rev 01)
00:1d.1 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller 
#2 (rev 01)
00:1d.2 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller 
#3 (rev 01)
00:1d.3 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller 
#4 (rev 01)
00:1d.7 USB Controller: Intel Corporation N10/ICH 7 Family USB2 EHCI Controller 
(rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1)
00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface 
Bridge (rev 01)
00:1f.2 IDE interface: Intel Corporation N10/ICH7 Family SATA IDE Controller 
(rev 01)
00:1f.3 SMBus: Intel Corporation N10/ICH 7 Family SMBus Controller (rev 01)
02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8056 PCI-E 
Gigabit Ethernet Controller (rev 14)
03:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL-8139/8139C/8139C+ (rev 10)


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [BUG] commit 541cc966915b6756e54c20eebe60ae957afdb537 cause no screen

[Dave Airlie]

On Mon, Dec 20, 2010 at 4:13 PM, Wei Yongjun yj...@cn.fujitsu.com wrote:
 After commit 541cc966915b6756e54c20eebe60ae957afdb537, I can see
 nothing in my screen, and the monitor is the same state as shutdown,
 but can ssh to my computer.

 Revert 541cc966915b6756e54c20eebe60ae957afdb537, every thing is OK.

    Revert drm: Don't try and disable an encoder that was never enabled

    This reverts commit 541cc966915b6756e54c20eebe60ae957afdb537.

 I am not in the maillist, so if any reply, pls cc me, thanks.

Hi,

Can you boot with drm.debug=4 with and without this patch and attach
both dmesgs?

I'll revert it ASAP since its a regression.

Thanks,
Dave.


 # lspci
 00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM 
 Controller (rev 10)
 00:02.0 VGA compatible controller: Intel Corporation 82G33/G31 Express 
 Integrated Graphics Controller (rev 10)
 00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition 
 Audio Controller (rev 01)
 00:1c.0 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 1 
 (rev 01)
 00:1c.1 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 2 
 (rev 01)
 00:1d.0 USB Controller: Intel Corporation N10/ICH7 Family USB UHCI Controller 
 #1 (rev 01)
 00:1d.1 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI 
 Controller #2 (rev 01)
 00:1d.2 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI 
 Controller #3 (rev 01)
 00:1d.3 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI 
 Controller #4 (rev 01)
 00:1d.7 USB Controller: Intel Corporation N10/ICH 7 Family USB2 EHCI 
 Controller (rev 01)
 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1)
 00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface 
 Bridge (rev 01)
 00:1f.2 IDE interface: Intel Corporation N10/ICH7 Family SATA IDE Controller 
 (rev 01)
 00:1f.3 SMBus: Intel Corporation N10/ICH 7 Family SMBus Controller (rev 01)
 02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8056 PCI-E 
 Gigabit Ethernet Controller (rev 14)
 03:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
 RTL-8139/8139C/8139C+ (rev 10)


 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[patch -next] nouveua: sizeof() vs ARRAY_SIZE()

[Dan Carpenter]

ARRAY_SIZE() was intended here, sizeof() is too large.

Signed-off-by: Dan Carpenter erro...@gmail.com

diff --git a/drivers/gpu/drm/nouveau/nv50_vram.c 
b/drivers/gpu/drm/nouveau/nv50_vram.c
index 47489ed..58e98ad 100644
--- a/drivers/gpu/drm/nouveau/nv50_vram.c
+++ b/drivers/gpu/drm/nouveau/nv50_vram.c
@@ -42,7 +42,7 @@ nv50_vram_flags_valid(struct drm_device *dev, u32 tile_flags)
 {
int type = (tile_flags  NOUVEAU_GEM_TILE_LAYOUT_MASK)  8;
 
-   if (likely(type  sizeof(types)  types[type]))
+   if (likely(type  ARRAY_SIZE(types)  types[type]))
return true;
return false;
 }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

i915 modeset defunct [was: mmotm 2010-12-16-14-56 uploaded]

[Jiri Slaby]

On 12/16/2010 11:56 PM, a...@linux-foundation.org wrote:
 The mm-of-the-moment snapshot 2010-12-16-14-56 has been uploaded to

Hi, there is a regression against 2010-12-02-16-34 in i915. When modeset
is used, my G33 produces no signal to the monitor (black screen, power
led blinks).

00:00.0 Host bridge [0600]: Intel Corporation 82G33/G31/P35/P31 Express
DRAM Controller [8086:29c0] (rev 02)
Subsystem: Intel Corporation 82G33/G31/P35/P31 Express DRAM
Controller [8086:29c0]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort-
TAbort- MAbort+ SERR- PERR- INTx-
Latency: 0
Capabilities: [e0] Vendor Specific Information: Len=0b ?
Kernel driver in use: agpgart-intel
00: 86 80 c0 29 06 00 90 20 02 00 00 06 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 c0 29
30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00
40: 01 90 d1 fe 01 00 00 00 01 40 d1 fe 00 00 00 00
50: 00 00 30 02 c9 03 00 00 00 00 00 00 00 00 00 00
60: 01 00 00 e0 00 00 00 00 01 80 d1 fe 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 10 11 11 00 00 33 33 00 5f 00 72 00 00 0a 38 00
a0: 60 00 c0 1c 00 00 80 af 00 00 60 af 00 00 60 af
b0: 00 b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 49 00 00 00 00 00 00 5b
e0: 09 00 0b 01 00 00 00 00 01 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 90 0f 03 00 00 00 00 00

00:02.0 VGA compatible controller [0300]: Intel Corporation 82G33/G31
Express Integrated Graphics Controller [8086:29c2] (rev 02) (prog-if 00
[VGA controller])
Subsystem: Intel Corporation 82G33/G31 Express Integrated
Graphics Controller [8086:29c2]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort-
TAbort- MAbort- SERR- PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 42
Region 0: Memory at feb8 (32-bit, non-prefetchable) [size=512K]
Region 1: I/O ports at ec00 [size=8]
Region 2: Memory at d000 (32-bit, prefetchable) [size=256M]
Region 3: Memory at fea0 (32-bit, non-prefetchable) [size=1M]
Expansion ROM at unassigned [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0300c  Data: 4161
Capabilities: [d0] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: i915
00: 86 80 c2 29 07 04 90 00 02 00 00 03 00 00 00 00
10: 00 00 b8 fe 01 ec 00 00 08 00 00 d0 00 00 a0 fe
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 c2 29
30: 00 00 00 00 90 00 00 00 00 00 00 00 05 01 00 00
40: 09 00 0b 01 00 00 00 00 01 00 00 00 00 00 00 00
50: 00 00 30 02 c9 03 00 00 00 00 00 00 00 00 80 af
60: 00 00 02 02 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 05 d0 01 00 0c 30 e0 fe 61 41 00 00 00 00 00 00
a0: 11 11 00 00 00 00 06 03 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 01 00 22 00 00 00 00 00 00 00 00 00 00 01 02 00
e0: 00 00 00 00 00 00 00 00 00 80 00 00 00 00 00 00
f0: 12 00 03 00 00 00 00 00 90 0f 03 00 e4 e0 5b af


any ideas?

thanks,
-- 
js
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915 modeset defunct [was: mmotm 2010-12-16-14-56 uploaded]

[Jiri Slaby]

On 12/20/2010 10:49 AM, Jiri Slaby wrote:
 On 12/16/2010 11:56 PM, a...@linux-foundation.org wrote:
 The mm-of-the-moment snapshot 2010-12-16-14-56 has been uploaded to
 
 Hi, there is a regression against 2010-12-02-16-34 in i915. When modeset
 is used, my G33 produces no signal to the monitor (black screen, power
 led blinks).
...
 any ideas?

Oh, looks like:
https://bugzilla.kernel.org/show_bug.cgi?id=25242

regards,
-- 
js
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 32312] openvg lion demo freezes the system lockup GPU with r600g

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=32312

--- Comment #2 from Sergey Kondakov virtuous...@gmail.com 2010-12-20 02:36:04 
PST ---
with commit c451aade889c3c0733fabab691f2a33643e8a054 it doesn't freeze but
rendering is broken

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 32312] openvg lion demo freezes the system lockup GPU with r600g

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=32312

--- Comment #4 from Sergey Kondakov virtuous...@gmail.com 2010-12-20 02:42:42 
PST ---
Created an attachment (id=41284)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=41284)
broken sp.jpg

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 32312] openvg lion demo freezes the system lockup GPU with r600g

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=32312

--- Comment #5 from Sergey Kondakov virtuous...@gmail.com 2010-12-20 02:44:02 
PST ---
Created an attachment (id=41285)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=41285)
broken Te$t text.jpg

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH][next] drm/vmwgfx: Let SVGA_REG_NUM_DISPLAYS decide output connectivity

[Thomas Hellstrom]

Dave,

Please don't apply this patch. We're looking at another solution.

/Thomas


On 12/16/2010 03:22 PM, Thomas Hellstrom wrote:

Makes the user able to determine the number of connected outputs from
the VMware GUI.

Signed-off-by: Thomas Hellstromthellst...@vmware.com
---
  drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c |   13 ++---
  1 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
index 29113c9..335c91c 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
@@ -340,9 +340,16 @@ static enum drm_connector_status
vmw_ldu_connector_detect(struct drm_connector *connector,
 bool force)
  {
-   if (vmw_connector_to_ldu(connector)-pref_active)
-   return connector_status_connected;
-   return connector_status_disconnected;
+   uint32_t num_displays;
+   struct drm_device *dev = connector-dev;
+   struct vmw_private *dev_priv = vmw_priv(dev);
+
+   mutex_lock(dev_priv-hw_mutex);
+   num_displays = vmw_read(dev_priv, SVGA_REG_NUM_DISPLAYS);
+   mutex_unlock(dev_priv-hw_mutex);
+
+   return ((vmw_connector_to_ldu(connector)-base.unit  num_displays) ?
+   connector_status_connected : connector_status_disconnected);
  }

  static struct drm_display_mode vmw_ldu_connector_builtin[] = {
   


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 32277] overflow in calculate_miptree_layout_r300

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=32277

Alban Browaeys pra...@yahoo.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #4 from Alban Browaeys pra...@yahoo.com 2010-12-20 07:06:40 PST 
---
User reported the issue as fixed. Can be closed. Thank you

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon/kms: reorder display resume to avoid problems

[Alex Deucher]

On resume, we were attemping to unblank the displays before the
timing and plls had be reprogrammed which led to atom timeouts
waiting for things that are not yet programmed.  Re-program
the mode first, then reset the dpms state.

This fixes the infamous atombios timeouts on resume.

Signed-off-by: Alex Deucher alexdeuc...@gmail.com
Cc: sta...@kernel.org
---
 drivers/gpu/drm/radeon/atombios_crtc.c |3 ++-
 drivers/gpu/drm/radeon/radeon_device.c |9 -
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 6a4f090..b0ab185 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -253,7 +253,8 @@ void atombios_crtc_dpms(struct drm_crtc *crtc, int mode)
case DRM_MODE_DPMS_SUSPEND:
case DRM_MODE_DPMS_OFF:
drm_vblank_pre_modeset(dev, radeon_crtc-crtc_id);
-   atombios_blank_crtc(crtc, ATOM_ENABLE);
+   if (radeon_crtc-enabled)
+   atombios_blank_crtc(crtc, ATOM_ENABLE);
if (ASIC_IS_DCE3(rdev))
atombios_enable_crtc_memreq(crtc, ATOM_DISABLE);
atombios_enable_crtc(crtc, ATOM_DISABLE);
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index 5da80d5..fcf0acb 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -925,11 +925,6 @@ int radeon_resume_kms(struct drm_device *dev)
radeon_pm_resume(rdev);
radeon_restore_bios_scratch_regs(rdev);
 
-   /* turn on display hw */
-   list_for_each_entry(connector, dev-mode_config.connector_list, head) {
-   drm_helper_connector_dpms(connector, DRM_MODE_DPMS_ON);
-   }
-
radeon_fbdev_set_suspend(rdev, 0);
release_console_sem();
 
@@ -937,6 +932,10 @@ int radeon_resume_kms(struct drm_device *dev)
radeon_hpd_init(rdev);
/* blat the mode back in */
drm_helper_resume_force_mode(dev);
+   /* turn on display hw */
+   list_for_each_entry(connector, dev-mode_config.connector_list, head) {
+   drm_helper_connector_dpms(connector, DRM_MODE_DPMS_ON);
+   }
return 0;
 }
 
-- 
1.7.1.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon/kms: reorder display resume to avoid problems

[Rafał Miłecki]

2010/12/20 Alex Deucher alexdeuc...@gmail.com:
 On resume, we were attemping to unblank the displays before the
 timing and plls had be reprogrammed which led to atom timeouts
 waiting for things that are not yet programmed.  Re-program
 the mode first, then reset the dpms state.

 This fixes the infamous atombios timeouts on resume.

Congratulations and thanks a lot! :)

-- 
Rafał
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Mesa build fails with --disable-gallium-radeon

[Stefan Dirsch]

Hi

Mesa build fails with --disable-gallium-radeon due to undefined
radeon_gem_get_kernel_name(). Attached is a patch.

Best regards,
Stefan

Public Key available
--
Stefan Dirsch (Res.  Dev.)   SUSE LINUX Products GmbH
Tel: 0911-740 53 0Maxfeldstraße 5
FAX: 0911-740 53 479  D-90409 Nürnberg
http://www.suse.deGermany 
-
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
-
--- ./src/mesa/drivers/dri/radeon/radeon_screen.c.orig	2010-12-20 11:14:08.0 +
+++ ./src/mesa/drivers/dri/radeon/radeon_screen.c	2010-12-20 11:15:29.0 +
@@ -555,6 +555,7 @@ radeon_create_image(__DRIscreen *screen,
return image;
 }
 
+#if 0
 static GLboolean
 radeon_query_image(__DRIimage *image, int attrib, int *value)
 {
@@ -572,14 +573,15 @@ radeon_query_image(__DRIimage *image, in
   return GL_FALSE;
}
 }
+#endif
 
 static struct __DRIimageExtensionRec radeonImageExtension = {
 { __DRI_IMAGE, __DRI_IMAGE_VERSION },
radeon_create_image_from_name,
radeon_create_image_from_renderbuffer,
radeon_destroy_image,
radeon_create_image,
-   radeon_query_image
+   NULL
 };
 
 static int radeon_set_screen_flags(radeonScreenPtr screen, int device_id)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/radeon/kms: fix evergreen asic reset

[Alex Deucher]

Only reset the grbm blocks, srbm tends to lock the GPU
if not done properly and in most cases is not necessary.
Also, no need to call asic init after reset the grbm blocks.

Signed-off-by: Alex Deucher alexdeuc...@gmail.com
Cc: sta...@kernel.org
---
 drivers/gpu/drm/radeon/evergreen.c |   15 ---
 1 files changed, 0 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 901f366..8b82749 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -2036,7 +2036,6 @@ bool evergreen_gpu_is_lockup(struct radeon_device *rdev)
 static int evergreen_gpu_soft_reset(struct radeon_device *rdev)
 {
struct evergreen_mc_save save;
-   u32 srbm_reset = 0;
u32 grbm_reset = 0;
 
dev_info(rdev-dev, GPU softreset \n);
@@ -2075,16 +2074,6 @@ static int evergreen_gpu_soft_reset(struct radeon_device 
*rdev)
udelay(50);
WREG32(GRBM_SOFT_RESET, 0);
(void)RREG32(GRBM_SOFT_RESET);
-
-   /* reset all the system blocks */
-   srbm_reset = SRBM_SOFT_RESET_ALL_MASK;
-
-   dev_info(rdev-dev,   SRBM_SOFT_RESET=0x%08X\n, srbm_reset);
-   WREG32(SRBM_SOFT_RESET, srbm_reset);
-   (void)RREG32(SRBM_SOFT_RESET);
-   udelay(50);
-   WREG32(SRBM_SOFT_RESET, 0);
-   (void)RREG32(SRBM_SOFT_RESET);
/* Wait a little for things to settle down */
udelay(50);
dev_info(rdev-dev,   GRBM_STATUS=0x%08X\n,
@@ -2095,10 +2084,6 @@ static int evergreen_gpu_soft_reset(struct radeon_device 
*rdev)
RREG32(GRBM_STATUS_SE1));
dev_info(rdev-dev,   SRBM_STATUS=0x%08X\n,
RREG32(SRBM_STATUS));
-   /* After reset we need to reinit the asic as GPU often endup in an
-* incoherent state.
-*/
-   atom_asic_init(rdev-mode_info.atom_context);
evergreen_mc_resume(rdev, save);
return 0;
 }
-- 
1.7.2.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/radeon/kms/evergreen: reset the grbm blocks at resume and init

[Alex Deucher]

This fixes module reloading and resume as the gfx block seems to
be left in a bad state in some cases.

Signed-off-by: Alex Deucher alexdeuc...@gmail.com
Cc: sta...@kernel.org
---
 drivers/gpu/drm/radeon/evergreen.c |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 8b82749..056b93c 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -2701,6 +2701,11 @@ int evergreen_resume(struct radeon_device *rdev)
 {
int r;
 
+   /* reset the asic, the gfx blocks are often in a bad state
+* after the driver is unloaded or after a resume
+*/
+   if (radeon_asic_reset(rdev))
+   dev_warn(rdev-dev, GPU reset failed !\n);
/* Do not reset GPU before posting, on rv770 hw unlike on r500 hw,
 * posting will perform necessary task to bring back GPU into good
 * shape.
@@ -2861,6 +2866,11 @@ int evergreen_init(struct radeon_device *rdev)
r = radeon_atombios_init(rdev);
if (r)
return r;
+   /* reset the asic, the gfx blocks are often in a bad state
+* after the driver is unloaded or after a resume
+*/
+   if (radeon_asic_reset(rdev))
+   dev_warn(rdev-dev, GPU reset failed !\n);
/* Post card if necessary */
if (!evergreen_card_posted(rdev)) {
if (!rdev-bios) {
-- 
1.7.2.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Freescale Linux BSP review

[Matt Sealey]

On Mon, Dec 20, 2010 at 11:17 AM, Jerome Glisse j.gli...@gmail.com wrote:
 On Mon, Dec 20, 2010 at 11:18 AM, Matt Sealey m...@genesi-usa.com wrote:
 On Mon, Dec 13, 2010 at 9:18 AM, Arnd Bergmann a...@arndb.de wrote:
 On Monday 13 December 2010, Jammy Zhou wrote:
 On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij 
 linus.wall...@linaro.orgwrote:

  On 11 December 2010 22:41, Arnd Bergmann a...@arndb.de wrote:
 
  * amd-gpu -- a single but huge driver for the GPU. As is normally the
              case with GPU drivers, we can expect long discussions
              before it will get considered for mainline
   4 patches
   98 files changed, 278321 insertions(+), 0 deletions(-)
 
 
  Just out of curiosity, following the discussion between Dave Airlie
  and Codeaurora this summer re GPU driver shims.
 
  Is the AMD GPU exposing all functionality in its kernel driver or
  is there some userspace blob somewhere with lots of e.g. GL
  goodies?
 
 All the functionality for the kernel driver of AMD GPU Z430/Z160 (now
 belongs to Qualcom) is exposed. But we need accompanied userspace library 
 to
 call these functionality (buffer management, command submission, ...).

 Who owns these components? If it's closed source, the only options we
 have are lobbying for complete release of the specs for a reimplementation
 or reverse-engineering the drivers, which may at least get easier with
 a user space driver than it would be with a kernel driver.

 Until there is a solution with an open source user space part, I would
 suggest that the driver better be dropped from the Freescale BSP and
 we should at least not waste time reviewing it.

 The concerns about host memory access via the GPU driver are valid but
 unnecessary. The GPU MMU directly intervenes on memory access and can
 only modify memory space allocated to the GPU resource - getting data
 into this memory requires some extreme manual intervention if not done
 by the kernel driver itself; this memory area is set internally by the
 platform device resource.. As such (on the i.MX515 at least) the top
 64MB of memory reserved for the GPU is the only memory you need to
 worry about, and any corruption will be limited to invalid API usage
 which is also checked with assertions and other protection mechanisms.
 Any other unsecured memory location such as system RAM cannot be
 affected as the GPU MMU will not write or read any other memory than
 the defined resource. It is not an outside possibility that you may
 abuse the GPU to corrupt graphics RAM... but you can do that with any
 GPU even with security checks.

 Security check of radeon GPU are advance enough to even catch and
 forbid overwriting other process video memory (this is more or less
 true depending on the generation you are looking at).

 Ownership of the code is dependent on who licensed it. I do not think
 Linaro need be so concerned over opensourcing or reimplementing
 drivers. The fact that the kernel driver is open source as it is, and
 this is by far the most important part. The userspace library is
 closed because it is proprietary; and I think it is well outside
 Linaro's remit to lobby for opensourcing of proprietary code simply to
 meet an esoteric and needless demand for source code access (as it
 stands, you can get source code access by signing the usual plethora
 of NDAs with the appropriate vendor, as Genesi has done). It is my
 understanding that Freescale/AMD and Qualcomm maintain seperate forks
 of the driver and do not cooperate on development, and in any case,
 Linaro does not include Qualcomm anyway, therefore it is also to my
 understanding that this discussion is also beyond Linaro's remit.

 Can't we all just be happy that we actually have 3D drivers?

 So here you are advocating that we should accept any open source code
 inside the kernel just because it's open source and we love open
 source ? This is not how i understand the linux kernel project, we
 should not accept any open source driver that just add new api that we
 can't audit, test or understand. From my point of view any driver 
 new API should be introduced to support open source userspace. If GPU
 manufacturer don't want to open source their stack that's their issue
 but they should live with the pain of not having upstream kernel
 either. I believe, here i am just reformulating Dave point.

The code may need improvement but that's no reason to run around
saying everything needs to be open sourced, and that the solution is
in fact to reverse engineer the thing rather than accept it as the
current solution. Given how long nouveau and later Radeon card support
has taken in real life, even with full documentation from AMD, I
seriously doubt Linaro are going to be the ones to somehow make the
world change for OpenSource embedded GPU graphics. Linaro doesn't
exist just to spend all their time undermining the status quo for the
sake of it.

I also do not think that it is at all kernel policy to disallow kernel
drivers which do 

Re: Freescale Linux BSP review

[Jerome Glisse]

On Mon, Dec 20, 2010 at 12:41 PM, Matt Sealey m...@genesi-usa.com wrote:
 On Mon, Dec 20, 2010 at 11:17 AM, Jerome Glisse j.gli...@gmail.com wrote:
 On Mon, Dec 20, 2010 at 11:18 AM, Matt Sealey m...@genesi-usa.com wrote:
 On Mon, Dec 13, 2010 at 9:18 AM, Arnd Bergmann a...@arndb.de wrote:
 On Monday 13 December 2010, Jammy Zhou wrote:
 On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij 
 linus.wall...@linaro.orgwrote:

  On 11 December 2010 22:41, Arnd Bergmann a...@arndb.de wrote:
 
  * amd-gpu -- a single but huge driver for the GPU. As is normally the
              case with GPU drivers, we can expect long discussions
              before it will get considered for mainline
   4 patches
   98 files changed, 278321 insertions(+), 0 deletions(-)
 
 
  Just out of curiosity, following the discussion between Dave Airlie
  and Codeaurora this summer re GPU driver shims.
 
  Is the AMD GPU exposing all functionality in its kernel driver or
  is there some userspace blob somewhere with lots of e.g. GL
  goodies?
 
 All the functionality for the kernel driver of AMD GPU Z430/Z160 (now
 belongs to Qualcom) is exposed. But we need accompanied userspace library 
 to
 call these functionality (buffer management, command submission, ...).

 Who owns these components? If it's closed source, the only options we
 have are lobbying for complete release of the specs for a reimplementation
 or reverse-engineering the drivers, which may at least get easier with
 a user space driver than it would be with a kernel driver.

 Until there is a solution with an open source user space part, I would
 suggest that the driver better be dropped from the Freescale BSP and
 we should at least not waste time reviewing it.

 The concerns about host memory access via the GPU driver are valid but
 unnecessary. The GPU MMU directly intervenes on memory access and can
 only modify memory space allocated to the GPU resource - getting data
 into this memory requires some extreme manual intervention if not done
 by the kernel driver itself; this memory area is set internally by the
 platform device resource.. As such (on the i.MX515 at least) the top
 64MB of memory reserved for the GPU is the only memory you need to
 worry about, and any corruption will be limited to invalid API usage
 which is also checked with assertions and other protection mechanisms.
 Any other unsecured memory location such as system RAM cannot be
 affected as the GPU MMU will not write or read any other memory than
 the defined resource. It is not an outside possibility that you may
 abuse the GPU to corrupt graphics RAM... but you can do that with any
 GPU even with security checks.

 Security check of radeon GPU are advance enough to even catch and
 forbid overwriting other process video memory (this is more or less
 true depending on the generation you are looking at).

 Ownership of the code is dependent on who licensed it. I do not think
 Linaro need be so concerned over opensourcing or reimplementing
 drivers. The fact that the kernel driver is open source as it is, and
 this is by far the most important part. The userspace library is
 closed because it is proprietary; and I think it is well outside
 Linaro's remit to lobby for opensourcing of proprietary code simply to
 meet an esoteric and needless demand for source code access (as it
 stands, you can get source code access by signing the usual plethora
 of NDAs with the appropriate vendor, as Genesi has done). It is my
 understanding that Freescale/AMD and Qualcomm maintain seperate forks
 of the driver and do not cooperate on development, and in any case,
 Linaro does not include Qualcomm anyway, therefore it is also to my
 understanding that this discussion is also beyond Linaro's remit.

 Can't we all just be happy that we actually have 3D drivers?

 So here you are advocating that we should accept any open source code
 inside the kernel just because it's open source and we love open
 source ? This is not how i understand the linux kernel project, we
 should not accept any open source driver that just add new api that we
 can't audit, test or understand. From my point of view any driver 
 new API should be introduced to support open source userspace. If GPU
 manufacturer don't want to open source their stack that's their issue
 but they should live with the pain of not having upstream kernel
 either. I believe, here i am just reformulating Dave point.

 The code may need improvement but that's no reason to run around
 saying everything needs to be open sourced, and that the solution is
 in fact to reverse engineer the thing rather than accept it as the
 current solution. Given how long nouveau and later Radeon card support
 has taken in real life, even with full documentation from AMD, I
 seriously doubt Linaro are going to be the ones to somehow make the
 world change for OpenSource embedded GPU graphics. Linaro doesn't
 exist just to spend all their time undermining the status quo for the
 sake of it.

 I 

Re: Definition of R_0003C2_GENMO_WT seems wrong

[Alex Deucher]

On Sun, Dec 19, 2010 at 9:48 AM, Tijl Coosemans t...@coosemans.org wrote:
 Hi,

 In drivers/gpu/drm/radeon/r100d.h R_0003C2_GENMO_WT is defined as 0x3C0.
 I think this should be 0x3C2.

 Note that the attached patch is untested.


Good catch.  Dave please apply.

Alex


 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel


From 85320542390676c2274b975a495b75bc98d356a2 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Mon, 20 Dec 2010 13:07:09 -0500
Subject: [PATCH] drm/radeon/kms: fix typo int r100d.h

GENMO_WT is 0x3C2 not 0x3C0
Noticed-by: Tijl Coosemans t...@coosemans.org

Cc: Tijl Coosemans t...@coosemans.org
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
Cc: sta...@kernel.org
---
 drivers/gpu/drm/radeon/r100d.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r100d.h b/drivers/gpu/drm/radeon/r100d.h
index b121b6c..eab9176 100644
--- a/drivers/gpu/drm/radeon/r100d.h
+++ b/drivers/gpu/drm/radeon/r100d.h
@@ -551,7 +551,7 @@
 #define   S_000360_CUR2_LOCK(x)(((x)  0x1)  31)
 #define   G_000360_CUR2_LOCK(x)(((x)  31)  0x1)
 #define   C_000360_CUR2_LOCK   0x7FFF
-#define R_0003C2_GENMO_WT0x0003C0
+#define R_0003C2_GENMO_WT0x0003C2
 #define   S_0003C2_GENMO_MONO_ADDRESS_B(x) (((x)  0x1)  0)
 #define   G_0003C2_GENMO_MONO_ADDRESS_B(x) (((x)  0)  0x1)
 #define   C_0003C2_GENMO_MONO_ADDRESS_B0xFE
-- 
1.7.1.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 32511] glDrawPixels broken on savage

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=32511

--- Comment #3 from Tormod Volden bugzi09.fdo.tor...@xoxy.net 2010-12-20 
10:34:19 PST ---
This is tested with latest 2.6.37 kernel, and libdrm 2.4.21.
LIBGL_ALWAYS_INDIRECT does not change anything, other than the xserver crashing
when drawpix exits. LIBGL_ALWAYS_SOFTWARE works fine. I have a Savage TwisterK
card, Dewey in the Ubuntu report has a SuperSavage IX/C.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 32422] Large images displayed in Firefox appear corrupted

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=32422

--- Comment #9 from Da Fox da_...@mad.scientist.com 2010-12-20 10:35:54 PST 
---
(In reply to comment #8)
 (In reply to comment #7)
  Even with the patch for bug 31708 applied, I see the same corruption in 
  firefox [...]
 
 That's with the latest version (v3) of the patch? (Jerome even submitted v4
 later, but I don't think the difference from v3 should be relevant for this
 problem; wouldn't hurt to try of course)

I have tried with the version present in 2.6.37-rc6, which according to the
changelog
(http://www.kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.37-rc6) is
v3. 

ps.
I only noticed that there were new posts on this bug after submitting my
comment on the other bug.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: Aggressively disable vblanks

[Andy Lutomirski]

Enabling and disabling the vblank interrupt (on devices that
support it) is cheap.  So disable it quickly after each
interrupt.

To avoid constantly enabling and disabling vblank when
animations are running, after a predefined number (3) of
consecutive enabled vblanks that someone cared about, just
leave the interrupt on until an interrupt that no one cares
about.

The full heuristic is:

There's a per-CRTC counter called vblank_consecutive.  It
starts at zero and counts consecutive useful vblanks.  A
vblank is useful if the refcount is nonzero when the interrupt
comes in.

Whenever drm_vblank_get enables the interrupt, it stays on at
least until the next vblank (*).  If drm_vblank_put is called
and vblank_consecutive is less than a threshold (currently 3),
then the interrupt is disabled.  If a vblank interrupt happens
with refcount == 0, then the interrupt is disabled and
vblank_consecutive is reset to 0.  If vblank_get is called
with the interrupt disabled and no interrupts were missed,
then vblank_consecutive is incremented.

(*) I tried letting it turn off before the next interrupt, but
compiz on my laptop seems to call drm_wait_vblank twice with
relative waits of 0 (!) before actually waiting.

Signed-off-by: Andy Lutomirski l...@mit.edu
---

Jesse, you asked for the deletion of the timer to be separate
from reducing the timeout, but that seemed silly because I'm ripping
out the entire old mechanism.  If you're worried about the added time
spent in the interrupt handler, I could move it to a tasklet.  That
being said, disable_vblank should be very fast (it's at most a couple
of register accesses in all in-tree drivers).

I've tested this on i915, where it works nicely and reduces my wakeups
with a second hand showing on the clock but an otherwise idle system.

This changes the requirements on enable_vblank, disable_vblank and
get_vblank_counter: they can now be called from an IRQ.  They already
had to work with IRQs off and a spinlock held, but now a driver has to
watch out for recursive calls from drm_handle_vblank.  The vbl_lock is
still held.

I've audited the in-tree drivers:

mga, r128: get_vblank_counter just reads an atomic_t.  enable_vblank
just pokes registers without a lock.  disable_vblank does nothing, so
turning off vblanks is pointless.

via: get_vblank_counter just returns a counter.  enable_vblank and
disable_vblank just poke registers without locks.  (This looks wrong:
get_vblank_count does the wrong thing and will confuse my heuristic,
but it should be any worse than it already is.  I can comment out
enable_vblank if anyone prefers that approach.)

vmwgfx: get_vblank_counter does nothing and the other hooks aren't
implemented.

radeon: Everything looks safe.

i915: Looks good and tested!

nouveau: Not implemented at all.  I'm not sure why either the old code
or my code doesn't try to call a null pointer, but it doesn't.  That
being said, sync-to-vblank doesn't work on nouveau for me (glxgears
gets over 600fps while claiming to be synced to vblank).

As a future improvement, all of the vblank-disabling code could be
skipped if there is no disable_vblank callback.

 drivers/gpu/drm/drm_irq.c |  103 +---
 include/drm/drmP.h|5 ++-
 2 files changed, 81 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 9d3a503..2f107c5 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -77,45 +77,59 @@ int drm_irq_by_busid(struct drm_device *dev, void *data,
return 0;
 }
 
-static void vblank_disable_fn(unsigned long arg)
+/* After VBLANK_CONSEC_THRESHOLD consecutive non-ignored vblank interrupts,
+ * vblanks will be left on. */
+#define VBLANK_CONSEC_THRESHOLD 3
+
+static void __vblank_disable_now(struct drm_device *dev, int crtc, int force)
+{
+   if (!dev-vblank_disable_allowed)
+   return;
+
+   if (atomic_read(dev-vblank_refcount[crtc]) == 0  
dev-vblank_enabled[crtc] 
+   (dev-vblank_consecutive[crtc]  VBLANK_CONSEC_THRESHOLD || 
force))
+   {
+   DRM_DEBUG(disabling vblank on crtc %d\n, crtc);
+   dev-last_vblank[crtc] =
+   dev-driver-get_vblank_counter(dev, crtc);
+   dev-driver-disable_vblank(dev, crtc);
+   dev-vblank_enabled[crtc] = 0;
+   if (force)
+   dev-vblank_consecutive[crtc] = 0;
+   }
+}
+
+static void vblank_disable_now(struct drm_device *dev, int crtc, int force)
 {
-   struct drm_device *dev = (struct drm_device *)arg;
unsigned long irqflags;
-   int i;
 
if (!dev-vblank_disable_allowed)
return;
 
-   for (i = 0; i  dev-num_crtcs; i++) {
-   spin_lock_irqsave(dev-vbl_lock, irqflags);
-   if (atomic_read(dev-vblank_refcount[i]) == 0 
-   dev-vblank_enabled[i]) {
-   DRM_DEBUG(disabling vblank on crtc %d\n, 

Re: [PATCH 1/2] drm/radeon/kms: fix evergreen asic reset

[Jerome Glisse]

On Mon, Dec 20, 2010 at 12:35 PM, Alex Deucher alexdeuc...@gmail.com wrote:
 Only reset the grbm blocks, srbm tends to lock the GPU
 if not done properly and in most cases is not necessary.
 Also, no need to call asic init after reset the grbm blocks.

 Signed-off-by: Alex Deucher alexdeuc...@gmail.com
 Cc: sta...@kernel.org
 ---

Reviewed-by: Jerome Glisse jgli...@redhat.com

  drivers/gpu/drm/radeon/evergreen.c |   15 ---
  1 files changed, 0 insertions(+), 15 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/evergreen.c 
 b/drivers/gpu/drm/radeon/evergreen.c
 index 901f366..8b82749 100644
 --- a/drivers/gpu/drm/radeon/evergreen.c
 +++ b/drivers/gpu/drm/radeon/evergreen.c
 @@ -2036,7 +2036,6 @@ bool evergreen_gpu_is_lockup(struct radeon_device *rdev)
  static int evergreen_gpu_soft_reset(struct radeon_device *rdev)
  {
        struct evergreen_mc_save save;
 -       u32 srbm_reset = 0;
        u32 grbm_reset = 0;

        dev_info(rdev-dev, GPU softreset \n);
 @@ -2075,16 +2074,6 @@ static int evergreen_gpu_soft_reset(struct 
 radeon_device *rdev)
        udelay(50);
        WREG32(GRBM_SOFT_RESET, 0);
        (void)RREG32(GRBM_SOFT_RESET);
 -
 -       /* reset all the system blocks */
 -       srbm_reset = SRBM_SOFT_RESET_ALL_MASK;
 -
 -       dev_info(rdev-dev,   SRBM_SOFT_RESET=0x%08X\n, srbm_reset);
 -       WREG32(SRBM_SOFT_RESET, srbm_reset);
 -       (void)RREG32(SRBM_SOFT_RESET);
 -       udelay(50);
 -       WREG32(SRBM_SOFT_RESET, 0);
 -       (void)RREG32(SRBM_SOFT_RESET);
        /* Wait a little for things to settle down */
        udelay(50);
        dev_info(rdev-dev,   GRBM_STATUS=0x%08X\n,
 @@ -2095,10 +2084,6 @@ static int evergreen_gpu_soft_reset(struct 
 radeon_device *rdev)
                RREG32(GRBM_STATUS_SE1));
        dev_info(rdev-dev,   SRBM_STATUS=0x%08X\n,
                RREG32(SRBM_STATUS));
 -       /* After reset we need to reinit the asic as GPU often endup in an
 -        * incoherent state.
 -        */
 -       atom_asic_init(rdev-mode_info.atom_context);
        evergreen_mc_resume(rdev, save);
        return 0;
  }
 --
 1.7.2.3

 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 31037] [r300g] Unwanted checkerboard effect on sprites / textures

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=31037

Gerwin gerwin_kra...@hotmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #10 from Gerwin gerwin_kra...@hotmail.com 2010-12-20 11:51:36 PST 
---
Today I updated from xorg edgers ppa and the bug in Nexuiz is fixed! Maybe this
patch fixed it?
http://cgit.freedesktop.org/mesa/mesa/commit/?id=daffaca53e47faeaaefb98ca46fe4870133d9f02

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Freescale Linux BSP review

[Dave Airlie]

 The concerns about host memory access via the GPU driver are valid but
 unnecessary. The GPU MMU directly intervenes on memory access and can
 only modify memory space allocated to the GPU resource - getting data
 into this memory requires some extreme manual intervention if not done
 by the kernel driver itself; this memory area is set internally by the
 platform device resource.. As such (on the i.MX515 at least) the top
 64MB of memory reserved for the GPU is the only memory you need to
 worry about, and any corruption will be limited to invalid API usage
 which is also checked with assertions and other protection mechanisms.
 Any other unsecured memory location such as system RAM cannot be
 affected as the GPU MMU will not write or read any other memory than
 the defined resource. It is not an outside possibility that you may
 abuse the GPU to corrupt graphics RAM... but you can do that with any
 GPU even with security checks.

 Ownership of the code is dependent on who licensed it. I do not think
 Linaro need be so concerned over opensourcing or reimplementing
 drivers. The fact that the kernel driver is open source as it is, and
 this is by far the most important part. The userspace library is
 closed because it is proprietary; and I think it is well outside
 Linaro's remit to lobby for opensourcing of proprietary code simply to
 meet an esoteric and needless demand for source code access (as it
 stands, you can get source code access by signing the usual plethora
 of NDAs with the appropriate vendor, as Genesi has done). It is my
 understanding that Freescale/AMD and Qualcomm maintain seperate forks
 of the driver and do not cooperate on development, and in any case,
 Linaro does not include Qualcomm anyway, therefore it is also to my
 understanding that this discussion is also beyond Linaro's remit.

 Can't we all just be happy that we actually have 3D drivers?

Can't you just use Windows? why bother with open source at all if you
are willing to give up.

My point which people keep missing is that graphics stacks are a
single entity, that span kernel and userspace, one cannot exist
without the other, and there are interfaces that join them.

I will accept kernel code to initialise chips, set modes, do all that,
I won't accept new ioctl interfaces to userspace that cannot be
validated and have no use other than to serve the closed user blob.
The reason for this is the burden of maintaining the code/interfaces
falls onto the kernel community when we accept code. Now if we can no
longer validate that the interfaces work without running a binary blob
or we cannot change the interfaces without having to lobby some other
entity to change their blob then maintaining that code in the upstream
kernel is pointless.

I have no problem with closed 3D drivers I just want the manufacturers
to understand that if you want to go down that path you get to keep
both halves.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [stable] [00/66] 2.6.36.1-stable review

[Greg KH]

On Wed, Dec 08, 2010 at 03:17:20PM +1000, Ben Skeggs wrote:
 On Sat, 2010-11-20 at 11:15 -0500, Andrew Lutomirski wrote:
  On Sat, Nov 20, 2010 at 10:52 AM, Greg KH gre...@suse.de wrote:
   On Sat, Nov 20, 2010 at 09:24:05AM -0500, Andy Lutomirski wrote:
   Greg KH wrote:
   This is the start of the stable review cycle for the 2.6.36.1 release.
   There are 66 patches in this series, all will be posted as a response
   to this one.  If anyone has any issues with these being applied, please
   let us know.  If anyone is a maintainer of the proper subsystem, and
   wants to add a Signed-off-by: line to the patch, please respond with it.
  
   Can you add ab838338a2a9e0cb8346eb0cab9977be13e8dce5?  (Somehow the cc:
   stable got eaten, but 2.6.36 definitely needs this one.  2.6.35 probably
   does as well but I haven't 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 bske...@redhat.com

Now applied, thanks.

greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 31037] [r300g] Unwanted checkerboard effect on sprites / textures

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=31037

--- Comment #11 from Marek Olšák mar...@gmail.com 2010-12-20 12:01:19 PST ---
Most probably, yes.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Freescale Linux BSP review

[Alan Cox]

 My point which people keep missing is that graphics stacks are a
 single entity, that span kernel and userspace, one cannot exist
 without the other, and there are interfaces that join them.

As a copyright holder on the kernel I'll also remind the people concerned
that the definition of a derivative work is a legal not a technical one
and if the kernel and user space cannot be used except together and one
half depends on GPL elements I hope your lawyers have reviewed it
carefully. I have never given anyone permission to link my GPL kernel
contributions with anything but GPL code, modular or otherwise, except
according to the derivative work rules laid down by the GPL (and indeed
by the boundaries placed on copyright law).

Alan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Freescale Linux BSP review

[Alan Cox]

 I also do not think that it is at all kernel policy to disallow kernel
 drivers which do not have opensource userspace components. In fact,

Wrong. The PVR graphics (as used by some Intel embedded for example) is
also not in the kernel for the same reason, ditto some sensor and GPS
devices which are useless without a magic proprietary library.

There are lots of reasons for refusing such code

- Legality questions
- Testability
- Security
- Risk of locking us to proprietary interfaces when we can't change the
  user one

and more

Alan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 30507] Caster (commercial game) crash.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=30507

--- Comment #3 from roughl r0ug...@yahoo.de 2010-12-20 12:39:32 PST ---
Caster works for me.
Kernel 2.6.36.2
Mesa 7.10-devel 20101220
xf86-video-ati git-20101129
libdrm git-20101129
OS is x86_64
KMS with Radeon HD4850 (RV770 9442)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 32535] Graphics corruption after resume from hibernate on Thinkpad SL510 (RV710 0x1002:0x9553)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=32535

Alex Deucher ag...@yahoo.com changed:

   What|Removed |Added

Product|xorg|DRI
  Component|Driver/Radeon   |DRM/Radeon
 AssignedTo|xorg-driver-...@lists.x.org |dri-de...@lists.freedesktop
   ||.org
  QAContact|xorg-t...@lists.x.org   |

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 32535] Graphics corruption after resume from hibernate on Thinkpad SL510 (RV710 0x1002:0x9553)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=32535

--- Comment #1 from Alex Deucher ag...@yahoo.com 2010-12-20 13:41:20 PST ---
Does a newer kernel (2.6.36 or 2.6.37) help?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 32535] Graphics corruption after resume from hibernate on Thinkpad SL510 (RV710 0x1002:0x9553)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=32535

--- Comment #2 from Robert Hooker (Sarvatt) sarv...@gmail.com 2010-12-20 
13:42:12 PST ---
Created an attachment (id=41317)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=41317)
kernel log showing the problem

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 32535] Graphics corruption after resume from hibernate on Thinkpad SL510 (RV710 0x1002:0x9553)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=32535

--- Comment #4 from Alex Deucher ag...@yahoo.com 2010-12-20 13:47:01 PST ---
Created an attachment (id=41318)
 View: https://bugs.freedesktop.org/attachment.cgi?id=41318
 Review: https://bugs.freedesktop.org/review?bug=32535attachment=41318

possible fix

Does this kernel patch help?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 32535] Graphics corruption after resume from hibernate on Thinkpad SL510 (RV710 0x1002:0x9553)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=32535

--- Comment #5 from Robert Hooker (Sarvatt) sarv...@gmail.com 2010-12-20 
15:03:19 PST ---
Created an attachment (id=41322)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=41322)
kernel log with patch

It didn't help unfortunately

[   45.741351] radeon :01:00.0: GPU softreset 
[   45.741354] radeon :01:00.0:   R_008010_GRBM_STATUS=0x3028
[   45.741357] radeon :01:00.0:   R_008014_GRBM_STATUS2=0x0002
[   45.741359] radeon :01:00.0:   R_000E50_SRBM_STATUS=0x20C0
[   45.741373] radeon :01:00.0:   R_008020_GRBM_SOFT_RESET=0x7FEE

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 32455] Crash with mame using OpenGL with newest Gallium on Radeon 4350

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=32455

--- Comment #5 from Øyvind Sæther oyvi...@everdot.org 2010-12-20 16:11:27 PST 
---
line 179 offset += vertex_buffer-buffer_offset + r600_bo_offset(rbuffer-bo);
(latest git with the r600g: properly unset vertex buffer
abe9ffc25c8d65b48ae02cdc8445b212b9f61632 patch also SIGSEGVs.

$ gdb sdlmame
(stuff)
Program received signal SIGSEGV, Segmentation fault.
0x720ccb06 in r600_vertex_buffer_update (rctx=0x66bbc30) at
r600_state.c:179
179 r600_state.c: Ingen slik fil eller filkatalog.
in r600_state.c
(gdb) bt full
#0  0x720ccb06 in r600_vertex_buffer_update (rctx=0x66bbc30) at
r600_state.c:179
rstate = 0x71c93010
rbuffer = 0x0
vertex_buffer = 0x66bd048
i = 0
offset = 0
#1  0x720da40b in r600_set_vertex_buffers (ctx=0x66bbc30, count=1,
buffers=0x7fffc5c0) at r600_state_common.c:220
rctx = 0x66bbc30
vbo = 0x7fffc5c0
max_index = 4294967295
#2  0x721d6fa8 in st_draw_vbo (ctx=0x6bf0210, arrays=0x6c3f3a0,
prims=0x7fffc950, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001',
min_index=0,
max_index=3) at state_tracker/st_draw.c:701
st = 0x6c3bb60
pipe = 0x66bbc30
vp = 0x6e3f1c0
vpv = 0x6e467a0
vbuffer = {{stride = 8, max_index = 3, buffer_offset = 0, buffer =
0x0}, {stride = 115533480, max_index = 0, buffer_offset = 4,
buffer = 0x7fffc7a0}, {stride = 27394114, max_index = 0,
buffer_offset = 3, buffer = 0x7fff01b6c001}, {stride = 16, max_index = 0,
buffer_offset = 4294952736, buffer = 0x7227e76e}, {stride =
27394048, max_index = 117, buffer_offset = 4294952864, buffer = 0x6e2e6a8}, {
stride = 27394048, max_index = 0, buffer_offset = 4294952624,
buffer = 0x7fffc7a0}, {stride = 27394048, max_index = 32767,
buffer_offset = 4070635360, buffer = 0x7fff0299}, {stride =
4062687129, max_index = 32767, buffer_offset = 27394049,
buffer = 0x7fffc6e0}, {stride = 27394050, max_index = 113,
buffer_offset = 4294952864, buffer = 0x1a2}, {stride = 4294952864,
max_index = 4, buffer_offset = 27394050, buffer = 0x62f06d41900},
{stride = 4070634880, max_index = 32767, buffer_offset = 115533624,
buffer = 0x7fffc720}, {stride = 4062687972, max_index = 32767,
buffer_offset = 13, buffer = 0x30}, {stride = 13, max_index = 27394070,
buffer_offset = 64, buffer = 0x1a000d}, {stride = 4134719176,
max_index = 32767, buffer_offset = 27394049, buffer = 0x2c}, {
stride = 115533624, max_index = 4, buffer_offset = 4134719096,
buffer = 0x60}, {stride = 113435888, max_index = 4, buffer_offset = 80320,
buffer = 0x6c2e4f0}, {stride = 4134719072, max_index = 32767,
buffer_offset = 44, buffer = 0x1}, {stride = 115478608, max_index = 0,
buffer_offset = 1, buffer = 0x7644f9f0}, {stride = 4294952944,
max_index = 32767, buffer_offset = 113435888, buffer = 0x7fffc7f0}, {
stride = 114563328, max_index = 0, buffer_offset = 115536160,
buffer = 0x721ef3cd}, {stride = 4294952976, max_index = 32767,
buffer_offset = 115601856, buffer = 0x2c0020}, {stride =
4294952976, max_index = 32767, buffer_offset = 113435888, buffer = 0x6bf0210},
{
stride = 13, max_index = 2640323868, buffer_offset = 115535632,
buffer = 0x0}, {stride = 113435888, max_index = 0, buffer_offset = 4294953056,
buffer = 0x7227ef90}, {stride = 0, max_index = 0, buffer_offset
= 115601856, buffer = 0x6c04a58}, {stride = 113181200, max_index = 0,
buffer_offset = 113181200, buffer = 0x6bf0210}, {stride =
4063024604, max_index = 32767, buffer_offset = 113513056, buffer =
0x7fffc870}, {
stride = 4062903259, max_index = 32767, buffer_offset = 8, buffer =
0x6bf0210}, {stride = 0, max_index = 0, buffer_offset = 113496512,
buffer = 0x7fffc890}, {stride = 4062902571, max_index = 32767,
buffer_offset = 113455672, buffer = 0x6bf0210}, {stride = 4294953152,
max_index = 32767, buffer_offset = 4062008109, buffer =
0x84006bf0210}, {stride = 113181200, max_index = 0, buffer_offset = 16,
buffer = 0x6c3bb60}}
attr = 0  
velements = {{src_offset = 107697360, instance_divisor = 0,
vertex_buffer_index = 0, src_format = PIPE_FORMAT_R32G32_FLOAT}, {src_offset =
0,
instance_divisor = 0, vertex_buffer_index = 0, src_format =
PIPE_FORMAT_R32G32_FLOAT}, {src_offset = 0, instance_divisor = 0,
vertex_buffer_index = 0, src_format = PIPE_FORMAT_NONE},
{src_offset = 0, instance_divisor = 0, vertex_buffer_index = 0,
src_format = PIPE_FORMAT_NONE}, {src_offset = 0, instance_divisor =
0, vertex_buffer_index = 0, src_format = PIPE_FORMAT_NONE}, {src_offset = 0,
instance_divisor = 0, vertex_buffer_index = 0, src_format =
PIPE_FORMAT_NONE}, {src_offset = 0, instance_divisor = 

Re: smatch: nouveau: bogus compare against zero

[Ben Skeggs]

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(13)
   warn: bogus compare against zero: 'i'
 
 94  u32 block, i;
 95
 96  phys  = nv50_vm_addr(vma, pgt, phys, mem-memtype, 0);
 97  pte = 3;
 98  cnt = 3;
 99
100  while (cnt) {
101  u32 offset_h = upper_32_bits(phys);
102  u32 offset_l = lower_32_bits(phys);
103
104  for (i = 7; i = 0; i--) {
 ^^
 
   i is unsigned so this test is always true.
 
105  block = 1  (i + 3);
106  if (cnt = block  !(pte  (block - 1)))
107  break;
108  }
109  offset_l |= (i  7);
 
 regards,
 dan carpenter


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [patch -next] nouveua: sizeof() vs ARRAY_SIZE()

[Ben Skeggs]

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 erro...@gmail.com
 
 diff --git a/drivers/gpu/drm/nouveau/nv50_vram.c 
 b/drivers/gpu/drm/nouveau/nv50_vram.c
 index 47489ed..58e98ad 100644
 --- a/drivers/gpu/drm/nouveau/nv50_vram.c
 +++ b/drivers/gpu/drm/nouveau/nv50_vram.c
 @@ -42,7 +42,7 @@ nv50_vram_flags_valid(struct drm_device *dev, u32 
 tile_flags)
  {
   int type = (tile_flags  NOUVEAU_GEM_TILE_LAYOUT_MASK)  8;
  
 - if (likely(type  sizeof(types)  types[type]))
 + if (likely(type  ARRAY_SIZE(types)  types[type]))
   return true;
   return false;
  }


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/3] fbcon: fix situation where fbcon gets deinitialised and can't reinit.

[Dave Airlie]

From: Dave Airlie airl...@redhat.com

Situation as follow:
2 GPUs + vesafb + kms.

GPU 1 is primary, vesafb binds to it as fb0
radeon loads
GPU 0 loads as fb1
GPU 1 loads, vesafb gets kicked off which causes fb0 to unbind
console, which causes the dummy console to rebind.

this means fbcon_deinit gets called, which calls fbcon_exit
since the console isn't bound anymore and we set fbcon_has_exited.

GPU 1 creates a new fb0 which is primary and we want to be console.
fbcon_fb_registered gets called sets the primary up and calls set_con2fb_map,
however as fbcon_has_exited is set nothing further ever happens.

This patch bypasses the fbcon_has_exited and checks if the console is unbound,
if its unbound it calls the fbcon_takeover which calls the vt layer to
call the fbcon_startup method and everthing works.

Signed-off-by: Dave Airlie airl...@redhat.com
---
 drivers/video/console/fbcon.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index 7ccc967..6662687 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -823,10 +823,10 @@ static int set_con2fb_map(int unit, int newidx, int user)
if (oldidx == newidx)
return 0;
 
-   if (!info || fbcon_has_exited)
+   if (!info)
return -EINVAL;
 
-   if (!err  !search_for_mapped_con()) {
+   if (!search_for_mapped_con() || !con_is_bound(fb_con)) {
info_idx = newidx;
return fbcon_takeover(0);
}
-- 
1.7.1


--
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
--
___
Dri-devel mailing list
dri-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/3] vt: fix issue when fbcon wants to takeover a second time.

[Dave Airlie]

From: Dave Airlie airl...@redhat.com

With framebuffer handover and multiple GPUs, we get into a
position where the fbcon unbinds the vesafb framebuffer for GPU 1,
but we still have a radeon framebuffer bound from GPU 0, so
we don't unregister the console driver. Then when we tried to bind
the new radeon framebuffer for GPU1 we never get to the bind
call as we fail due to the console being registered already.

This changes the return value to -EBUSY when the driver is
already registered and continues to bind for -EBUSY.

Signed-off-by: Dave Airlie airl...@redhat.com
Cc: Alan Cox a...@lxorguk.ukuu.org.uk
Cc: Greg KH g...@suse.de
---
 drivers/tty/vt/vt.c |9 +++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index a8ec48e..d781496 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -3524,7 +3524,7 @@ int register_con_driver(const struct consw *csw, int 
first, int last)
 
/* already registered */
if (con_driver-con == csw)
-   retval = -EINVAL;
+   retval = -EBUSY;
}
 
if (retval)
@@ -3635,7 +3635,12 @@ int take_over_console(const struct consw *csw, int 
first, int last, int deflt)
int err;
 
err = register_con_driver(csw, first, last);
-
+   /* if we get an busy error we still want to bind the console driver
+* and return success, as we may have unbound the console driver
+* but not unregistered it.
+*/
+   if (err == -EBUSY)
+   err = 0;
if (!err)
bind_con_driver(csw, first, last, deflt);
 
-- 
1.7.1


--
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
--
___
Dri-devel mailing list
dri-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

vt/fbcon binding and handover fixes

[Dave Airlie]

I've been working on some issues with the fb handoff between vesafb and KMS
on my machine with a dual-gpu card. These 3 patches are the primary result
of this, to fix a number of issues where the VT layer and fbcon layers
got themselves into a place that they couldn't get out off, having the second
card complicates things nicely where we have an fbdev registered but fbcon
gets unbound to the dummy console and can't get back.

Also a fix to the overlap tests which had an off-by-one.

Dave.


--
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
--
___
Dri-devel mailing list
dri-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/3] fb: fix overlapping test off-by-one.

[Dave Airlie]

From: Dave Airlie airl...@redhat.com

On my system with a radeon x2, the first GPU was not overlapping vesa
but the test decided it was.

Signed-off-by: Dave Airlie airl...@redhat.com
---
 drivers/video/fbmem.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index 0e6aa3d..4ac1201 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1458,7 +1458,7 @@ static bool apertures_overlap(struct aperture *gen, 
struct aperture *hw)
if (gen-base == hw-base)
return true;
/* is the generic aperture base inside the hw base-hw base+size */
-   if (gen-base  hw-base  gen-base = hw-base + hw-size)
+   if (gen-base  hw-base  gen-base  hw-base + hw-size)
return true;
return false;
 }
-- 
1.7.1


--
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
--
___
Dri-devel mailing list
dri-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 32455] Crash with mame using OpenGL with newest Gallium on Radeon 4350

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=32455

--- Comment #6 from Chris bitbyte...@gmail.com 2010-12-20 18:20:17 PST ---
I get the same segfault and backtrace as Øyvind Sæther posted with the new
version too, looks just like his.  Thanks, does look like it's getting farther
though I think.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Freescale Linux BSP review

[Piotr Gluszenia Slawinski]

On Mon, 20 Dec 2010, Alan Cox wrote:


My point which people keep missing is that graphics stacks are a
single entity, that span kernel and userspace, one cannot exist
without the other, and there are interfaces that join them.


As a copyright holder on the kernel I'll also remind the people concerned
that the definition of a derivative work is a legal not a technical one
and if the kernel and user space cannot be used except together and one
half depends on GPL elements I hope your lawyers have reviewed it
carefully. I have never given anyone permission to link my GPL kernel
contributions with anything but GPL code, modular or otherwise, except
according to the derivative work rules laid down by the GPL (and indeed
by the boundaries placed on copyright law).


but it can be circumvented by writing GPL driver which will act as 'glue 
logic' inbetween userspace driver and which will work in kernel space?


technically then driver would be GPL, except it's closed parts which will 
be ran in userspace... or can you forbid usage of certain closed userspace 
components with kernel?


p.s. let's skip for now discussion who should write such driver, as i 
understand anyone can do it anyway.


--
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm: Aggressively disable vblanks

[Keith Packard]

On Mon, 20 Dec 2010 14:00:54 -0500, Andy Lutomirski l...@mit.edu wrote:

 Enabling and disabling the vblank interrupt (on devices that
 support it) is cheap.  So disable it quickly after each
 interrupt.

So, the concern (and reason for the original design) was that you might
lose count of vblank interrupts as vblanks are counted differently while
off than while on. If vblank interrupts get enabled near the interrupt
time, is it possible that you'll end up off by one somehow?

Leaving them enabled for 'a while' was supposed to reduce the impact of
this potential error.

-- 
keith.pack...@intel.com


pgp9DrqzaacH3.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm: Aggressively disable vblanks

[Andrew Lutomirski]

On Mon, Dec 20, 2010 at 10:23 PM, Keith Packard kei...@keithp.com wrote:
 On Mon, 20 Dec 2010 14:00:54 -0500, Andy Lutomirski l...@mit.edu wrote:

 Enabling and disabling the vblank interrupt (on devices that
 support it) is cheap.  So disable it quickly after each
 interrupt.

 So, the concern (and reason for the original design) was that you might
 lose count of vblank interrupts as vblanks are counted differently while
 off than while on. If vblank interrupts get enabled near the interrupt
 time, is it possible that you'll end up off by one somehow?

So the race is:

1. Vblank happens.
2. vblank_get runs, reads hardware counter, and enables the interrupt
(and maybe not quite in that order)
3. Interrupt fires and increments the counter.  Now the counter is one too high.

What if we read the hardware counter from the IRQ the first time that
it fires after being enabled?  That way, if the hardware and software
counters match (mod 2^23 or whatever the magic number is), we don't
increment the counter.


 Leaving them enabled for 'a while' was supposed to reduce the impact of
 this potential error.


Fair enough,

But five seconds is a *long* time, and anything short enough that the
interrupt actually gets turned off in normal use risks the same race.

--Andy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm: Aggressively disable vblanks

[Keith Packard]

On Mon, 20 Dec 2010 22:34:12 -0500, Andrew Lutomirski l...@mit.edu wrote:

 But five seconds is a *long* time, and anything short enough that the
 interrupt actually gets turned off in normal use risks the same race.

Right, so eliminating any race seems like the basic requirement. Can
that be done?

-- 
keith.pack...@intel.com


pgpsXEi7dtYOv.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel