[Patch VIA UniChrome DRM][1/5 Ver1] Add support for ACPI suspend/resume
Hello All:
This is patch 1 of the 5 patches. It's based on 2.6.32-rc3 and for the
support of ACPI suspend/resume.
To support suspend / resume, some information located in video memory need to
be saved because
3D sync mechanism will use these information after resume. 6 files has been
modified for this patch.
Sign-off by Bruce c. Chang
diff -Nur linux-2.6.32-rc3-old/drivers/gpu/drm/via/via_dma.c
linux-2.6.32-rc3-new/drivers/gpu/drm/via/via_dma.c
--- linux-2.6.32-rc3-old/drivers/gpu/drm/via/via_dma.c 2009-10-05
08:12:30.0 +0800
+++ linux-2.6.32-rc3-new/drivers/gpu/drm/via/via_dma.c 2009-10-08
10:11:59.0 +0800
@@ -68,6 +68,8 @@
*vb++ = (w2); \
dev_priv->dma_low += 8;
+static void via_cmdbuf_flush(struct drm_via_private *dev_priv,
+ uint32_t cmd_type);
static void via_cmdbuf_start(drm_via_private_t * dev_priv);
static void via_cmdbuf_pause(drm_via_private_t * dev_priv);
static void via_cmdbuf_reset(drm_via_private_t * dev_priv);
@@ -155,6 +157,11 @@
int via_dma_cleanup(struct drm_device * dev)
{
+ struct drm_via_video_save_head *pnode;
+
+ for (pnode = via_video_save_head; pnode; pnode =
+ (struct drm_via_video_save_head *)pnode->next)
+ memcpy(pnode->psystemmem, pnode->pvideomem, pnode->size);
if (dev->dev_private) {
drm_via_private_t *dev_priv =
(drm_via_private_t *) dev->dev_private;
@@ -175,6 +182,7 @@
drm_via_private_t * dev_priv,
drm_via_dma_init_t * init)
{
+ struct drm_via_video_save_head *pnode;
if (!dev_priv || !dev_priv->mmio) {
DRM_ERROR("via_dma_init called before via_map_init\n");
return -EFAULT;
@@ -195,6 +203,9 @@
return -EINVAL;
}
+ for (pnode = via_video_save_head; pnode; pnode = pnode->next)
+ memcpy(pnode->pvideomem, pnode->psystemmem, pnode->size);
+
dev_priv->ring.map.offset = dev->agp->base + init->offset;
dev_priv->ring.map.size = init->size;
dev_priv->ring.map.type = 0;
@@ -737,6 +748,155 @@
return ret;
}
+/*The following functions are for ACPI*/
+
+static void initialize3Dengine(drm_via_private_t *dev_priv)
+{
+ int i = 0;
+
+ VIA_WRITE(0x43C, 0x0001);
+
+ for (i = 0; i <= 0x7D; i++)
+ VIA_WRITE(0x440, (unsigned long) i << 24);
+
+ VIA_WRITE(0x43C, 0x0002);
+
+ for (i = 0; i <= 0x94; i++)
+ VIA_WRITE(0x440, (unsigned long) i << 24);
+
+ VIA_WRITE(0x440, 0x8240);
+ VIA_WRITE(0x43C, 0x0102);
+
+ for (i = 0; i <= 0x94; i++)
+ VIA_WRITE(0x440, (unsigned long) i << 24);
+
+ VIA_WRITE(0x440, 0x8240);
+ VIA_WRITE(0x43C, 0xfe02);
+
+ for (i = 0; i <= 0x03; i++)
+ VIA_WRITE(0x440, (unsigned long) i << 24);
+
+ VIA_WRITE(0x43C, 0x0003);
+
+ for (i = 0; i <= 0xff; i++)
+ VIA_WRITE(0x440, 0);
+
+ VIA_WRITE(0x43C, 0x0010);
+ VIA_WRITE(0x440, 0x00333004);
+ VIA_WRITE(0x440, 0x1002);
+ VIA_WRITE(0x440, 0x6000);
+ VIA_WRITE(0x440, 0x6100);
+ VIA_WRITE(0x440, 0x6200);
+ VIA_WRITE(0x440, 0x6300);
+ VIA_WRITE(0x440, 0x6400);
+
+ VIA_WRITE(0x43C, 0x00fe);
+ VIA_WRITE(0x440, 0x40008c0f);
+ VIA_WRITE(0x440, 0x4400);
+ VIA_WRITE(0x440, 0x45080C04);
+ VIA_WRITE(0x440, 0x46800408);
+ VIA_WRITE(0x440, 0x5000);
+ VIA_WRITE(0x440, 0x5100);
+ VIA_WRITE(0x440, 0x5200);
+ VIA_WRITE(0x440, 0x5300);
+
+
+ VIA_WRITE(0x43C, 0x00fe);
+ VIA_WRITE(0x440, 0x0801);
+ VIA_WRITE(0x440, 0x0A000183);
+ VIA_WRITE(0x440, 0x0B00019F);
+ VIA_WRITE(0x440, 0x0C00018B);
+ VIA_WRITE(0x440, 0x0D00019B);
+ VIA_WRITE(0x440, 0x0E00);
+ VIA_WRITE(0x440, 0x0F00);
+ VIA_WRITE(0x440, 0x1000);
+ VIA_WRITE(0x440, 0x1100);
+ VIA_WRITE(0x440, 0x2000);
+}
+/* For acpi case, when system resume from suspend or hibernate,
+ * need to re-initialize dma info into HW
+ */
+int via_drm_resume(struct drm_device *drm_dev)
+{
+ struct pci_dev *pci = drm_dev->pdev;
+ drm_via_private_t *dev_priv =
+ (drm_via_private_t *) drm_dev->dev_private;
+ struct drm_via_video_save_head *pnode = 0;
+
+ pci_set_power_state(pci, PCI_D0);
+ pci_restore_state(pci);
+ if (pci_enable_device(pci))
+ return -1;
+ /*pci_set_master(pci);*/
+ if (!dev_priv->initialize)
+ return 0;
+ /* when resume, initialize 3d registers */
+ initialize3Dengine(dev_priv);
+
+ /* here we need to restore some video memory content */
+ for (pnode = via_video_save_head; pnode; pnode = pnode->next)
+ memcpy(pnode->
Re: [resend] i915: high power consumption after suspend/resume
On Mon, Oct 5, 2009 at 12:21 PM, Jesse Barnes wrote: > On Sat, 3 Oct 2009 12:50:01 -0400 > Andrew Lutomirski wrote: > >> [resend b/c the intel-gfx list doesn't allow non-member posting] >> >> Hi- >> >> First, thanks for all the great work on i915's power saving features >> -- power consumption on my laptop (Lenovo X200s) is now almost as low >> on Linux as on Windows. >> >> After a suspend/resume cycle, though, my power consumption usually >> goes up by over a watt. I think this is due to i915, because of an >> experiment I did: >> >> 1. Boot with modesetting off into single user mode. >> 2. Suspend and resume >> 3. Reload i915 with modesetting on. Power consumption is low. >> 4. Suspend and resume. Power consumption is high. >> 5. Unbind and rebind i915. Power consumption is high. >> 6. Suspend. System hangs (seperate bug, I guess). >> >> I get similar results if I boot single user with modesetting on: power >> consumption is low, becomes high after suspend/resume, and goes low >> again after rebinding i915. >> >> This is on 2.6.32-rc1 + a little (i.e. 84d88d5d4e from Linus' tree >> plus an ext4 fix). I'm having trouble reproducing any of this on >> 2.6.31. > > I probably need to save/restore some more of the power saving state > across suspend/resume... Can you file a bug for this at > bugs.freedesktop.org so it doesn't get lost? Submitted as https://bugs.freedesktop.org/show_bug.cgi?id=24386 Thanks, Andy -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Patch VIA UniChrome DRM][2/5 Ver1] Add support for video command flush and interface for V4L kernel module
Hello All:
This is patch 2 of the 5 patches. It's based on 2.6.32-rc3+patch1 and for
the support of
video command flush(using double buffer to improve performance) and interfaces
for
communication with v4l kernel module.
5 files has been modified for this patch.
Sign-off by Bruce C. Chang
diff -Nur linux-2.6.32-rc3-old/drivers/gpu/drm/via/via_dma.c
linux-2.6.32-rc3-new/drivers/gpu/drm/via/via_dma.c
--- linux-2.6.32-rc3-old/drivers/gpu/drm/via/via_dma.c 2009-10-08
10:14:16.0 +0800
+++ linux-2.6.32-rc3-new/drivers/gpu/drm/via/via_dma.c 2009-10-08
10:14:29.0 +0800
@@ -68,6 +68,13 @@
*vb++ = (w2); \
dev_priv->dma_low += 8;
+#define VIA_OUT_VIDEO_AGP_BUFFER(cmd1, cmd2)\
+ do {\
+ *cur_virtual++ = cmd1; \
+ *cur_virtual++ = cmd2; \
+ cmdbuf_info.cmd_size += 8; \
+ } while (0);
+
static void via_cmdbuf_flush(struct drm_via_private *dev_priv,
uint32_t cmd_type);
static void via_cmdbuf_start(drm_via_private_t * dev_priv);
@@ -158,6 +165,7 @@
int via_dma_cleanup(struct drm_device * dev)
{
struct drm_via_video_save_head *pnode;
+ int i;
for (pnode = via_video_save_head; pnode; pnode =
(struct drm_via_video_save_head *)pnode->next)
@@ -167,12 +175,23 @@
(drm_via_private_t *) dev->dev_private;
if (dev_priv->ring.virtual_start) {
- via_cmdbuf_reset(dev_priv);
+ if (dev_priv->cr_status == CR_FOR_RINGBUFFER)
+ via_cmdbuf_flush(dev_priv, HC_HAGPBpID_STOP);
+
+ via_wait_idle(dev_priv);
drm_core_ioremapfree(&dev_priv->ring.map, dev);
dev_priv->ring.virtual_start = NULL;
}
+ for (i = 0; i < 3; i++) {
+ if (dev_priv->video_agp_address_map[i].handle &&
+dev_priv->video_agp_address_map[i].size)
+ drm_core_ioremapfree(dev_priv->
+ video_agp_address_map+i, dev);
+ /*Fix for suspend reuse video buf*/
+ dev_priv->video_agp_address_map[i].handle = NULL;
+ }
}
return 0;
@@ -235,6 +254,7 @@
via_cmdbuf_start(dev_priv);
+ dev_priv->cr_status = CR_FOR_RINGBUFFER;
return 0;
}
@@ -343,12 +363,42 @@
static int via_cmdbuffer(struct drm_device *dev, void *data, struct drm_file
*file_priv)
{
drm_via_cmdbuffer_t *cmdbuf = data;
- int ret;
+ drm_via_private_t *dev_priv = dev->dev_private;
+ int ret = 0, count;
LOCK_TEST_WITH_RETURN(dev, file_priv);
DRM_DEBUG("buf %p size %lu\n", cmdbuf->buf, cmdbuf->size);
+ if (dev_priv->cr_status == CR_FOR_VIDEO) {
+ /* Because our driver will hook CR stop cmd behind video cmd,
+ * all we need to do here is to wait for CR idle,
+ * and initialize ring buffer.
+ */
+ count = 1000;
+ while (count-- && (VIA_READ(VIA_REG_STATUS) &
+ VIA_CMD_RGTR_BUSY))
+ cpu_relax();
+ /* Seldom happen */
+ if (count < 0) {
+ DRM_INFO("The CR can't be idle from video agp cmd \
+ dispatch when it is needed by ring buffer \n");
+ return -1;
+ }
+ /* CR has been idle so that we need to initialize ring buffer */
+ dev_priv->dma_ptr = dev_priv->ring.virtual_start;
+ dev_priv->dma_low = 0;
+ dev_priv->dma_high = 0x100;
+ dev_priv->dma_wrap = 0x100;
+ dev_priv->dma_offset = 0x0;
+ dev_priv->last_pause_ptr = NULL;
+ dev_priv->hw_addr_ptr = dev_priv->mmio->handle + 0x418;
+
+ via_cmdbuf_start(dev_priv);
+
+ dev_priv->cr_status = CR_FOR_RINGBUFFER;
+
+ }
ret = via_dispatch_cmdbuffer(dev, cmdbuf);
if (ret) {
return ret;
@@ -357,6 +407,135 @@
return 0;
}
+/* Dispatch command of video : using double buffer mechanism */
+int via_cmdbuffer_video_agp(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
+{
+ drm_via_private_t *dev_priv = dev->dev_private;
+ struct drm_via_video_agp_cmd cmdbuf_info;
+ int count;
+ u32 start_addr, start_addr_lo;
+ u32 end_addr, end_addr_lo;
+ u32 pause_addr, pause_addr_hi, pause_addr_lo;
+ u32 *cur_virtual;
+ u32 command;
+ int i = 0;
+ struct drm_local_map map;
+
+ LOCK_TEST_WITH_RETURN(dev, file_priv);
+
+ /* Check whether CR services for ring buffer or for video engine. */
[Patch VIA UniChrome DRM][3/5 Ver1] Enhance DRM robustness
Hello All:
This is patch 3 of the 5 patches. It's based on 2.6.32-rc3+patch1+patch2.
It enhance the DRM robustness,
such as memory check before release or content comparison.
3 files has been modified for this patch.
Sign-off by Bruce C. Chang
diff -Nur linux-2.6.32-rc3-old/drivers/gpu/drm/via/via_dmablit.c
linux-2.6.32-rc3-new/drivers/gpu/drm/via/via_dmablit.c
--- linux-2.6.32-rc3-old/drivers/gpu/drm/via/via_dmablit.c 2009-10-05
08:12:30.0 +0800
+++ linux-2.6.32-rc3-new/drivers/gpu/drm/via/via_dmablit.c 2009-10-08
10:18:08.0 +0800
@@ -195,8 +195,10 @@
default:
vsg->state = dr_via_sg_init;
}
- vfree(vsg->bounce_buffer);
- vsg->bounce_buffer = NULL;
+ if (vsg->bounce_buffer) {
+ vfree(vsg->bounce_buffer);
+ vsg->bounce_buffer = NULL;
+ }
vsg->free_on_sequence = 0;
}
diff -Nur linux-2.6.32-rc3-old/drivers/gpu/drm/via/via_irq.c
linux-2.6.32-rc3-new/drivers/gpu/drm/via/via_irq.c
--- linux-2.6.32-rc3-old/drivers/gpu/drm/via/via_irq.c 2009-10-05
08:12:30.0 +0800
+++ linux-2.6.32-rc3-new/drivers/gpu/drm/via/via_irq.c 2009-10-08
10:18:08.0 +0800
@@ -357,6 +357,8 @@
drm_via_irq_t *cur_irq = dev_priv->via_irqs;
int force_sequence;
+ if (!dev->pdev->irq)
+ return -EINVAL;
if (irqwait->request.irq >= dev_priv->num_irqs) {
DRM_ERROR("Trying to wait on unknown irq %d\n",
irqwait->request.irq);
diff -Nur linux-2.6.32-rc3-old/drivers/gpu/drm/via/via_mm.c
linux-2.6.32-rc3-new/drivers/gpu/drm/via/via_mm.c
--- linux-2.6.32-rc3-old/drivers/gpu/drm/via/via_mm.c 2009-10-08
10:17:39.0 +0800
+++ linux-2.6.32-rc3-new/drivers/gpu/drm/via/via_mm.c 2009-10-08
10:18:08.0 +0800
@@ -91,6 +91,17 @@
int via_final_context(struct drm_device *dev, int context)
{
drm_via_private_t *dev_priv = (drm_via_private_t *) dev->dev_private;
+ struct drm_ctx_list *pos, *n;
+ bool context_valid = 0;
+
+ list_for_each_entry_safe(pos, n, &dev->ctxlist, head)
+ if (pos->handle == context) {
+ context_valid = 1;
+ break;
+ }
+
+ if (!context_valid)
+ return 0;
via_release_futex(dev_priv, context);
@@ -98,7 +109,8 @@
/* Last context, perform cleanup */
if (dev->ctx_count == 1 && dev->dev_private) {
DRM_DEBUG("Last Context\n");
- drm_irq_uninstall(dev);
+ if (dev->pdev->irq)
+ drm_irq_uninstall(dev);
via_cleanup_futex(dev_priv);
via_do_cleanup_map(dev);
}
Thanks and Best regards
=
Bruce C. Chang(張祖明)
VIA Technologies, Inc.
Address: 1F, 531, Chung-Cheng Road, Hsin-Tien, 231 Taipei
Tel: +886-2-22185452 Ext 7323
Mobile: +886-968343824
Fax: +886-2-22186282
Skype: Bruce.C.Chang
Email: brucech...@via.com.tw
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Patch VIA UniChrome DRM][4/5 Ver1] Fix the bug of via_verify.c function
Hello All:
This is patch 4 of the 5 patches. It's based on
2.6.32-rc3+patch1+patch2+patch3. It fixes the bug of via_verify.c function.
3 files has been modified for this patch.
Sign-off by Bruce C. Chang
diff -Nur linux-2.6.32-rc3-old/drivers/gpu/drm/via/via_3d_reg.h
linux-2.6.32-rc3-new/drivers/gpu/drm/via/via_3d_reg.h
--- linux-2.6.32-rc3-old/drivers/gpu/drm/via/via_3d_reg.h 2009-10-05
08:12:30.0 +0800
+++ linux-2.6.32-rc3-new/drivers/gpu/drm/via/via_3d_reg.h 2009-10-08
10:19:12.0 +0800
@@ -1647,4 +1647,7 @@
#define VIA_VIDEO_HEADER6 0xFE05
#define VIA_VIDEO_HEADER7 0xFE06
#define VIA_VIDEOMASK 0x
+#define HALCYON_HEADER3 0xF400
+#define HALCYON_HEADER4 0xF600
+#define HALCYON_HEADER_MASK 0xFE00
#endif
diff -Nur linux-2.6.32-rc3-old/drivers/gpu/drm/via/via_verifier.c
linux-2.6.32-rc3-new/drivers/gpu/drm/via/via_verifier.c
--- linux-2.6.32-rc3-old/drivers/gpu/drm/via/via_verifier.c 2009-10-05
08:12:30.0 +0800
+++ linux-2.6.32-rc3-new/drivers/gpu/drm/via/via_verifier.c 2009-10-08
10:19:12.0 +0800
@@ -41,6 +41,8 @@
state_header1,
state_vheader5,
state_vheader6,
+ state_header3,
+ state_header4,
state_error
} verifier_state_t;
@@ -227,7 +229,10 @@
{0xf2, check_for_header2_err},
{0xf0, check_for_header1_err},
{0xcc, check_for_dummy},
- {0x00, check_number_texunits}
+ {0x00, check_number_texunits},
+ {0x01, no_check},
+ {0x02, no_check},
+ {0x03, no_check}
};
static hazard_t table1[256];
@@ -768,11 +773,12 @@
DRM_ERROR("Invalid VIDEO DMA command. "
"Attempt to access 3D- or command burst area.\n");
return 1;
- } else if ((address > 0xCFF) && (address < 0x1300)) {
+ } else if ((address > 0xDFF) && (address < 0x1200)) {
DRM_ERROR("Invalid VIDEO DMA command. "
"Attempt to access PCI DMA area.\n");
return 1;
- } else if (address > 0x13FF) {
+ } else if (((address > 0x13FF) && (address < 0x2200)) ||
+ (address > 0x33ff)) {
DRM_ERROR("Invalid VIDEO DMA command. "
"Attempt to access VGA registers.\n");
return 1;
@@ -791,10 +797,11 @@
return 1;
}
while (dwords--) {
- if (*buf++) {
+ if (*buf && !is_dummy_cmd(*buf)) {
DRM_ERROR("Illegal video command tail.\n");
return 1;
}
+ buf++;
}
*buffer = buf;
return 0;
@@ -1001,6 +1008,14 @@
case state_vheader6:
state = via_check_vheader6(&buf, buf_end);
break;
+ case state_header3:
+ case state_header4:
+ buf++;
+ while (buf < buf_end && !is_agp_header(*buf))
+ buf++;
+ state = state_command;
+ break;
+
case state_command:
if ((HALCYON_HEADER2 == (cmd = *buf)) &&
supported_3d)
@@ -1016,7 +1031,12 @@
else if ((cmd == HALCYON_HEADER2) && !supported_3d) {
DRM_ERROR("Accelerated 3D is not supported on
this chipset yet.\n");
state = state_error;
- } else {
+ } else if ((cmd & HALCYON_HEADER_MASK) ==
+ HALCYON_HEADER3)
+ state = state_header3;
+ else if ((cmd & HALCYON_HEADER_MASK) == HALCYON_HEADER4)
+ state = state_header4;
+ else {
DRM_ERROR
("Invalid / Unimplemented DMA HEADER
command. 0x%x\n",
cmd);
diff -Nur linux-2.6.32-rc3-old/drivers/gpu/drm/via/via_verifier.h
linux-2.6.32-rc3-new/drivers/gpu/drm/via/via_verifier.h
--- linux-2.6.32-rc3-old/drivers/gpu/drm/via/via_verifier.h 2009-10-05
08:12:30.0 +0800
+++ linux-2.6.32-rc3-new/drivers/gpu/drm/via/via_verifier.h 2009-10-08
10:19:12.0 +0800
@@ -25,7 +25,8 @@
#ifndef _VIA_VERIFIER_H_
#define _VIA_VERIFIER_H_
-
+#include "via_3d_reg.h"
+#define INV_DUMMY_MASK 0xFF00
typedef enum {
no_sequence = 0,
z_address,
@@ -59,4 +60,38 @@
extern int via_parse_command_stream(struct drm_device *dev, const uint32_t
*buf,
unsigned int size);
+static inline int is_agp_header(unsigned int data)
+{
+ if (data == HALCYON_HEADER2)
+ return 1;
+ else if ((data & VIA_VIDEOMASK) == VIA
[Patch VIA UniChrome DRM][5/5 Ver1] Add verify for video command flush
Hello All: This is patch 5 of the 5 patches. It's based on 2.6.32-rc3+patch1+patch2+patch3+patch4. It adds verification for video command flush. 1 file has been modified for this patch. Sign-off by Bruce C. Chang diff -Nur linux-2.6.32-rc3-old/drivers/gpu/drm/via/via_dma.c linux-2.6.32-rc3-new/drivers/gpu/drm/via/via_dma.c --- linux-2.6.32-rc3-old/drivers/gpu/drm/via/via_dma.c 2009-10-08 10:19:59.0 +0800 +++ linux-2.6.32-rc3-new/drivers/gpu/drm/via/via_dma.c 2009-10-08 10:20:08.0 +0800 @@ -419,7 +419,7 @@ u32 pause_addr, pause_addr_hi, pause_addr_lo; u32 *cur_virtual; u32 command; - int i = 0; + int i = 0, ret; struct drm_local_map map; LOCK_TEST_WITH_RETURN(dev, file_priv); @@ -499,6 +499,10 @@ } } + ret = via_verify_command_stream((uint32_t *) map.handle, + cmdbuf_info.cmd_size, dev, 1); + if (ret) + return ret; cur_virtual = map.handle + cmdbuf_info.cmd_size; VIA_OUT_VIDEO_AGP_BUFFER(HC_HEADER2 | ((VIA_REG_TRANSET >> 2) << 12) | Thanks and Best regards = Bruce C. Chang(張祖明) VIA Technologies, Inc. Address: 1F, 531, Chung-Cheng Road, Hsin-Tien, 231 Taipei Tel: +886-2-22185452 Ext 7323 Mobile: +886-968343824 Fax: +886-2-22186282 Skype: Bruce.C.Chang Email: brucech...@via.com.tw -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24380] OpenGL fullscreen with KMS multihead
http://bugs.freedesktop.org/show_bug.cgi?id=24380 --- Comment #1 from Michel Dänzer 2009-10-08 01:25:39 PST --- This is likely mostly due to the apps or - at least in the case of etracer - SDL not using the RandR extension but older functionality for switching to/from fullscreen. See e.g. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=450689 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/2] drm/radeon/kms: Fix apparent typo in legacy CRTC memory bandwidth calculation.
From: Michel Dänzer While investigating the cause of CRTC FIFO underruns, I noticed that when converting the memory bandwidth calculation from the userspac X driver code, an instance of '8.0' was apparently accidentally converted to '80'. Signed-off-by: Michel Dänzer --- drivers/gpu/drm/radeon/r100.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c index 374ecac..33198dd 100644 --- a/drivers/gpu/drm/radeon/r100.c +++ b/drivers/gpu/drm/radeon/r100.c @@ -2350,7 +2350,7 @@ void r100_bandwidth_update(struct radeon_device *rdev) /* Find the total latency for the display data. */ - disp_latency_overhead.full = rfixed_const(80); + disp_latency_overhead.full = rfixed_const(8); disp_latency_overhead.full = rfixed_div(disp_latency_overhead, sclk_ff); mc_latency_mclk.full += disp_latency_overhead.full + cur_latency_mclk.full; mc_latency_sclk.full += disp_latency_overhead.full + cur_latency_sclk.full; -- 1.6.4.3 -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/2] drm/radeon/kms: Update memory bandwidth requirements in mode_set_base hook.
From: Michel Dänzer
The hook may change the number of bytes per pixel being scanned out, which
affects the CRTC memory bandwidth requirements. E.g. booting in 8bpp and then
running X in 32bpp would result in the bandwidth requirements being
underestimated for the latter and consequently in CRTC FIFO underruns causing
visible artifacts with 3D intensive workloads.
ATOM changes only compile-tested.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/radeon/atombios_crtc.c |5 -
drivers/gpu/drm/radeon/radeon_legacy_crtc.c |7 ---
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 14fa970..38a87cc 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -563,6 +563,10 @@ int atombios_crtc_set_base(struct drm_crtc *crtc, int x,
int y,
radeon_fb = to_radeon_framebuffer(old_fb);
radeon_gem_object_unpin(radeon_fb->obj);
}
+
+ /* Bytes per pixel may have changed */
+ radeon_bandwidth_update(rdev);
+
return 0;
}
@@ -701,7 +705,6 @@ int atombios_crtc_mode_set(struct drm_crtc *crtc,
}
atombios_overscan_setup(crtc, mode, adjusted_mode);
atombios_scaler_setup(crtc);
- radeon_bandwidth_update(rdev);
return 0;
}
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
index 36410f8..ec2df73 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
@@ -532,6 +532,10 @@ int radeon_crtc_set_base(struct drm_crtc *crtc, int x, int
y,
radeon_fb = to_radeon_framebuffer(old_fb);
radeon_gem_object_unpin(radeon_fb->obj);
}
+
+ /* Bytes per pixel may have changed */
+ radeon_bandwidth_update(rdev);
+
return 0;
}
@@ -1015,14 +1019,11 @@ static int radeon_crtc_mode_set(struct drm_crtc *crtc,
int x, int y, struct drm_framebuffer *old_fb)
{
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
- struct drm_device *dev = crtc->dev;
- struct radeon_device *rdev = dev->dev_private;
/* TODO TV */
radeon_crtc_set_base(crtc, x, y, old_fb);
radeon_set_crtc_timing(crtc, adjusted_mode);
radeon_set_pll(crtc, adjusted_mode);
- radeon_bandwidth_update(rdev);
if (radeon_crtc->crtc_id == 0) {
radeon_legacy_rmx_mode_set(crtc, mode, adjusted_mode);
} else {
--
1.6.4.3
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Patch VIA UniChrome DRM][2/5 Ver1] Add support for video command flush and interface for V4L kernel module
brucech...@via.com.tw wrote:
Bruce, Others.
The v4l interfaces look ok to me.
However, the double-buffer flush mechanism does not.
If I understand the code correctly, the user-space application prepares
command buffers directly in AGP, and asks the
drm module to submit them. We can't allow this for security reasons.
The user-space application could for example fill the buffer with
commands to texture from arbitrary system memory, getting hold of other
user's private data.
The whole ring-buffer stuff and the command verifier was once
implemented to fix that security problem.
I mentioned this in the last email I posted as a comment to the big
patch, and detailed the unichrome drm module security policy.
So this patch is a NAK from my side.
/Thomas
> Hello All:
> This is patch 2 of the 5 patches. It's based on 2.6.32-rc3+patch1 and for
> the support of
> video command flush(using double buffer to improve performance) and
> interfaces for
> communication with v4l kernel module.
>
> 5 files has been modified for this patch.
>
> Sign-off by Bruce C. Chang
> diff -Nur linux-2.6.32-rc3-old/drivers/gpu/drm/via/via_dma.c
> linux-2.6.32-rc3-new/drivers/gpu/drm/via/via_dma.c
> --- linux-2.6.32-rc3-old/drivers/gpu/drm/via/via_dma.c2009-10-08
> 10:14:16.0 +0800
> +++ linux-2.6.32-rc3-new/drivers/gpu/drm/via/via_dma.c2009-10-08
> 10:14:29.0 +0800
> @@ -68,6 +68,13 @@
> *vb++ = (w2); \
> dev_priv->dma_low += 8;
>
> +#define VIA_OUT_VIDEO_AGP_BUFFER(cmd1, cmd2)\
> + do {\
> + *cur_virtual++ = cmd1; \
> + *cur_virtual++ = cmd2; \
> + cmdbuf_info.cmd_size += 8; \
> + } while (0);
> +
> static void via_cmdbuf_flush(struct drm_via_private *dev_priv,
> uint32_t cmd_type);
> static void via_cmdbuf_start(drm_via_private_t * dev_priv);
> @@ -158,6 +165,7 @@
> int via_dma_cleanup(struct drm_device * dev)
> {
> struct drm_via_video_save_head *pnode;
> + int i;
>
> for (pnode = via_video_save_head; pnode; pnode =
> (struct drm_via_video_save_head *)pnode->next)
> @@ -167,12 +175,23 @@
> (drm_via_private_t *) dev->dev_private;
>
> if (dev_priv->ring.virtual_start) {
> - via_cmdbuf_reset(dev_priv);
> + if (dev_priv->cr_status == CR_FOR_RINGBUFFER)
> + via_cmdbuf_flush(dev_priv, HC_HAGPBpID_STOP);
> +
> + via_wait_idle(dev_priv);
>
> drm_core_ioremapfree(&dev_priv->ring.map, dev);
> dev_priv->ring.virtual_start = NULL;
> }
>
> + for (i = 0; i < 3; i++) {
> + if (dev_priv->video_agp_address_map[i].handle &&
> + dev_priv->video_agp_address_map[i].size)
> + drm_core_ioremapfree(dev_priv->
> + video_agp_address_map+i, dev);
> + /*Fix for suspend reuse video buf*/
> + dev_priv->video_agp_address_map[i].handle = NULL;
> + }
> }
>
> return 0;
> @@ -235,6 +254,7 @@
>
> via_cmdbuf_start(dev_priv);
>
> + dev_priv->cr_status = CR_FOR_RINGBUFFER;
> return 0;
> }
>
> @@ -343,12 +363,42 @@
> static int via_cmdbuffer(struct drm_device *dev, void *data, struct drm_file
> *file_priv)
> {
> drm_via_cmdbuffer_t *cmdbuf = data;
> - int ret;
> + drm_via_private_t *dev_priv = dev->dev_private;
> + int ret = 0, count;
>
> LOCK_TEST_WITH_RETURN(dev, file_priv);
>
> DRM_DEBUG("buf %p size %lu\n", cmdbuf->buf, cmdbuf->size);
>
> + if (dev_priv->cr_status == CR_FOR_VIDEO) {
> + /* Because our driver will hook CR stop cmd behind video cmd,
> + * all we need to do here is to wait for CR idle,
> + * and initialize ring buffer.
> + */
> + count = 1000;
> + while (count-- && (VIA_READ(VIA_REG_STATUS) &
> + VIA_CMD_RGTR_BUSY))
> + cpu_relax();
> + /* Seldom happen */
> + if (count < 0) {
> + DRM_INFO("The CR can't be idle from video agp cmd \
> + dispatch when it is needed by ring buffer \n");
> + return -1;
> + }
> + /* CR has been idle so that we need to initialize ring buffer */
> + dev_priv->dma_ptr = dev_priv->ring.virtual_start;
> + dev_priv->dma_low = 0;
> + dev_priv->dma_high = 0x100;
> + dev_priv->dma_wrap = 0x100;
> + dev_priv->dma_offset = 0x0;
> + dev_priv->last_pause_ptr = NULL;
> + dev_priv->hw_addr_ptr = dev_priv->mmio->handle + 0x418;
> +
> + via_cmdbuf_start(dev
RE: [Patch VIA UniChrome DRM][2/5 Ver1] Add support for video command flush and interface for V4L kernel module
Hello Thomas: > If I understand the code correctly, the user-space application prepares > command buffers directly in AGP, and asks the > drm module to submit them. We can't allow this for security reasons. The > user-space application could for example fill the buffer with > commands to texture from arbitrary system memory, getting hold of other > user's private data. > The whole ring-buffer stuff and the command verifier was once > implemented to fix that security problem. Thank you very much for your comment. What if we do a security check in these buffer before submit? Let me check if there is any way to work around for this security issue. Thanks and Best Regards = Bruce C. Chang(張祖明) VIA Technologies, Inc. Address: 1F, 531, Chung-Cheng Road, Hsin-Tien, 231 Taipei Tel: +886-2-22185452 Ext 7323 Mobile: +886-968343824 Fax: +886-2-22186282 Skype: Bruce.C.Chang Email: brucech...@via.com.tw -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Patch VIA UniChrome DRM][2/5 Ver1] Add support for video command flush and interface for V4L kernel module
On Thu, 2009-10-08 at 02:35 -0700, brucech...@via.com.tw wrote: > Hello Thomas: > > > If I understand the code correctly, the user-space application prepares > > command buffers directly in AGP, and asks the > > drm module to submit them. We can't allow this for security reasons. The > > user-space application could for example fill the buffer with > > commands to texture from arbitrary system memory, getting hold of other > > user's private data. > > The whole ring-buffer stuff and the command verifier was once > > implemented to fix that security problem. > Thank you very much for your comment. What if we do a security > check in these buffer before submit? Let me check if there is any way > to work around for this security issue. Who would do that security check? Userspace? That doesn't work as userspace is not trusted. The kernel? Ok, but now it's reading commands out of a presumably write-combined AGP buffer, which is slow. You'd have been better off passing the commands to the kernel in regular memory, which is presumably exactly what the existing mechanism does. Keith -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Patch VIA UniChrome DRM][2/5 Ver1] Add support for video command flush and interface for V4L kernel module
Dear Bruce, On Thu, Oct 08, 2009 at 05:35:51PM +0800, brucech...@via.com.tw wrote: > > If I understand the code correctly, the user-space application prepares > > command buffers directly in AGP, and asks the > > drm module to submit them. We can't allow this for security reasons. The > > user-space application could for example fill the buffer with > > commands to texture from arbitrary system memory, getting hold of other > > user's private data. > > The whole ring-buffer stuff and the command verifier was once > > implemented to fix that security problem. > > Thank you very much for your comment. What if we do a security check in these > buffer before submit? Let me check if there is any way to work around for > this security issue. Bruce, let me clarify: The fundamental assumiptions are: * the operating system kernel enforces security / permisssion between processes * DRM is used by an application which is running by one particular user * thus, the kernel needs to make security checks to ensure that whatever the application does will not violate the security constraints, i.e. * DRM api can not allow arbitrary memory read/write to physical addresses So if you want to add a security check to those buffers, the check has to be inside the kernel. Only the kernel can be trusted, not the userspace application that talks to the DRM API/ABI. Regards, -- - Harald Welte http://linux.via.com.tw/ VIA Free and Open Source Software Liaison -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Patch VIA UniChrome DRM][2/5 Ver1] Add support for video command flush and interface for V4L kernel module
Hello Keith: Thank you very much for your suggestion. Allow me to discuss with our engineers. Regards = Bruce C. Chang(張祖明) VIA Technologies, Inc. Address: 1F, 531, Chung-Cheng Road, Hsin-Tien, 231 Taipei Tel: +886-2-22185452 Ext 7323 Mobile: +886-968343824 Fax: +886-2-22186282 Skype: Bruce.C.Chang Email: brucech...@via.com.tw -Original Message- From: Keith Whitwell [mailto:kei...@vmware.com] Sent: Thursday, October 08, 2009 6:11 PM To: Bruce Chang Cc: tho...@shipmail.org; Joseph Chan; dri-devel@lists.sourceforge.net; Harald Welte; Benjamin Chen Subject: RE: [Patch VIA UniChrome DRM][2/5 Ver1] Add support for video command flush and interface for V4L kernel module On Thu, 2009-10-08 at 02:35 -0700, brucech...@via.com.tw wrote: > Hello Thomas: > > > If I understand the code correctly, the user-space application > > prepares > > command buffers directly in AGP, and asks the > > drm module to submit them. We can't allow this for security reasons. The > > user-space application could for example fill the buffer with > > commands to texture from arbitrary system memory, getting hold of other > > user's private data. > > The whole ring-buffer stuff and the command verifier was once > > implemented to fix that security problem. > Thank you very much for your comment. What if we do a security > check in these buffer before submit? Let me check if there is any way > to work around for this security issue. Who would do that security check? Userspace? That doesn't work as userspace is not trusted. The kernel? Ok, but now it's reading commands out of a presumably write-combined AGP buffer, which is slow. You'd have been better off passing the commands to the kernel in regular memory, which is presumably exactly what the existing mechanism does. Keith -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Patch VIA UniChrome DRM][2/5 Ver1] Add support for video command flush and interface for V4L kernel module
Hello Harald: Thank you very much for your education. We should go with better way. Regards = Bruce C. Chang(張祖明) VIA Technologies, Inc. Address: 1F, 531, Chung-Cheng Road, Hsin-Tien, 231 Taipei Tel: +886-2-22185452 Ext 7323 Mobile: +886-968343824 Fax: +886-2-22186282 Skype: Bruce.C.Chang Email: brucech...@via.com.tw -Original Message- From: Harald Welte [mailto:haraldwe...@viatech.com] Sent: Thursday, October 08, 2009 5:56 PM To: Bruce Chang Cc: tho...@shipmail.org; dri-devel@lists.sourceforge.net; airl...@gmail.com; Benjamin Chen; Joseph Chan Subject: Re: [Patch VIA UniChrome DRM][2/5 Ver1] Add support for video command flush and interface for V4L kernel module Dear Bruce, On Thu, Oct 08, 2009 at 05:35:51PM +0800, brucech...@via.com.tw wrote: > > If I understand the code correctly, the user-space application > > prepares > > command buffers directly in AGP, and asks the > > drm module to submit them. We can't allow this for security reasons. The > > user-space application could for example fill the buffer with > > commands to texture from arbitrary system memory, getting hold of other > > user's private data. > > The whole ring-buffer stuff and the command verifier was once > > implemented to fix that security problem. > > Thank you very much for your comment. What if we do a security check > in these buffer before submit? Let me check if there is any way to > work around for this security issue. Bruce, let me clarify: The fundamental assumiptions are: * the operating system kernel enforces security / permisssion between processes * DRM is used by an application which is running by one particular user * thus, the kernel needs to make security checks to ensure that whatever the application does will not violate the security constraints, i.e. * DRM api can not allow arbitrary memory read/write to physical addresses So if you want to add a security check to those buffers, the check has to be inside the kernel. Only the kernel can be trusted, not the userspace application that talks to the DRM API/ABI. Regards, -- - Harald Welte http://linux.via.com.tw/ VIA Free and Open Source Software Liaison -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24380] OpenGL fullscreen with KMS multihead
http://bugs.freedesktop.org/show_bug.cgi?id=24380 --- Comment #2 from Florian Scandella 2009-10-08 03:30:57 PST --- you know of any well behaving apps to test this? i tried glxgears -fullscreen, but this just expands the window to both heads and leaves the gnome-panel on top. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24150] tv out issues with radeon kms drm-next
http://bugs.freedesktop.org/show_bug.cgi?id=24150 --- Comment #7 from Andy Furniss 2009-10-08 04:28:03 PST --- (In reply to comment #0) > Issue 2. > > After starting X the TV display is almost correct cloning 1024x768 monitor. > > There are however two half bright green lines at the bottom and I can see from > banding artifacts on Xorg -retro background that either the scale type is > different or it is being scaled to a slightly smaller height. > > The green lines do not occur with modeset=0 and the background does not > artifact (Though it will when scaling from other than 1024x768) > > I noticed that a slightly different modeline is used between kms and ums for > the TV. The ums is 59.9Hz vs 60Hz for kms. I've found through testing that the difference here is that kms is using NTSC and ums is using PAL. Researching it seems that my old PAL CRT does offer NTSC support. Testing shows that the frequency of the modeline as shown by xrandr in either case does not change anything - it's 59.94 using kms or 50 using ums. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24380] OpenGL fullscreen with KMS multihead
http://bugs.freedesktop.org/show_bug.cgi?id=24380 --- Comment #3 from Florian Scandella 2009-10-08 04:38:34 PST --- hmm .. i got etracer running ok with: SDL_VIDEO_X11_XRANDR=1 SDL_VIDEO_FULLSCREEN_HEAD=0 etracer but it crashes after exit (not restoring mode) the black screen was due to the 800x600 resolution not working (xrandr shows 60Hz, monitor got 30Hz, this also happens if i switch resolution with xrandr) i'm surprised console switching works that good. no matter how bad x was messed up (even a crashed opengl app, mouse hanging and all), fbcon was always working and setting the right mode.i had some bad experiences in the past with switching from x to console :) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Patch VIA UniChrome DRM][4/5 Ver1] Fix the bug of via_verify.c function
Bruce, See inline comments below.
I'll ACK this patch when we've made sure the HEADER3 and HEADER4 are not
violating the security policy.
brucech...@via.com.tw wrote:
> Hello All:
> This is patch 4 of the 5 patches. It's based on
> 2.6.32-rc3+patch1+patch2+patch3. It fixes the bug of via_verify.c function.
>
> 3 files has been modified for this patch.
>
> Sign-off by Bruce C. Chang
> diff -Nur linux-2.6.32-rc3-old/drivers/gpu/drm/via/via_3d_reg.h
> linux-2.6.32-rc3-new/drivers/gpu/drm/via/via_3d_reg.h
> --- linux-2.6.32-rc3-old/drivers/gpu/drm/via/via_3d_reg.h 2009-10-05
> 08:12:30.0 +0800
> +++ linux-2.6.32-rc3-new/drivers/gpu/drm/via/via_3d_reg.h 2009-10-08
> 10:19:12.0 +0800
> @@ -1647,4 +1647,7 @@
> #define VIA_VIDEO_HEADER6 0xFE05
> #define VIA_VIDEO_HEADER7 0xFE06
> #define VIA_VIDEOMASK 0x
> +#define HALCYON_HEADER3 0xF400
> +#define HALCYON_HEADER4 0xF600
> +#define HALCYON_HEADER_MASK 0xFE00
>
You make the HEADER3 and HEADER4 commands bypass the verifier. Could you
please briefly describe what these commands do, or point us to some
usable documentation?
> #endif
> diff -Nur linux-2.6.32-rc3-old/drivers/gpu/drm/via/via_verifier.c
> linux-2.6.32-rc3-new/drivers/gpu/drm/via/via_verifier.c
> --- linux-2.6.32-rc3-old/drivers/gpu/drm/via/via_verifier.c 2009-10-05
> 08:12:30.0 +0800
> +++ linux-2.6.32-rc3-new/drivers/gpu/drm/via/via_verifier.c 2009-10-08
> 10:19:12.0 +0800
> @@ -41,6 +41,8 @@
> state_header1,
> state_vheader5,
> state_vheader6,
> + state_header3,
> + state_header4,
> state_error
> } verifier_state_t;
>
> @@ -227,7 +229,10 @@
> {0xf2, check_for_header2_err},
> {0xf0, check_for_header1_err},
> {0xcc, check_for_dummy},
> - {0x00, check_number_texunits}
> + {0x00, check_number_texunits},
> + {0x01, no_check},
> + {0x02, no_check},
> + {0x03, no_check}
> };
>
>
The above is for YUV -> RGB conversion, right?
> @@ -791,10 +797,11 @@
> return 1;
> }
> while (dwords--) {
> - if (*buf++) {
> + if (*buf && !is_dummy_cmd(*buf)) {
> DRM_ERROR("Illegal video command tail.\n");
> return 1;
> }
> + buf++;
> }
> *buffer = buf;
> return 0;
>
Why can't the user-space applications just add 0 to pad the video
command tails?
Even if the hardware accepts dummy commands, the test above adds time to
the verification process.
/Thomas
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Patch VIA UniChrome DRM][2/5 Ver1] Add support for video command flush and interface for V4L kernel module
brucech...@via.com.tw wrote: > Hello Thomas: > > >> If I understand the code correctly, the user-space application prepares >> command buffers directly in AGP, and asks the >> drm module to submit them. We can't allow this for security reasons. The >> user-space application could for example fill the buffer with >> commands to texture from arbitrary system memory, getting hold of other >> user's private data. >> The whole ring-buffer stuff and the command verifier was once >> implemented to fix that security problem. >> > Thank you very much for your comment. What if we do a security check in > these buffer before submit? Let me check if there is any way to work around > for this security issue. > Bruce, I was wrong in that your patch 5/5 actually adds security checks to the buffers. However, there are two problems with that patch 1) It does security check on AGP memory, and as Keith pointed out, that's dead slow. 2) User-space could alter the contents of the AGP buffers just after the security check has been done, but before command submission. So I suggest you alter the user-space components to use the ring-buffer submission. It is a little more CPU-consuming, but I guess you have to live with it. /Thomas > Thanks and Best Regards > = > Bruce C. Chang(張祖明) > VIA Technologies, Inc. > Address: 1F, 531, Chung-Cheng Road, Hsin-Tien, 231 Taipei > Tel: +886-2-22185452 Ext 7323 > Mobile: +886-968343824 > Fax: +886-2-22186282 > Skype: Bruce.C.Chang > Email: brucech...@via.com.tw > -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Patch VIA UniChrome DRM][5/5 Ver1] Add verify for video command flush
Bruce, As mentioned in previous mail, this has two problems, 1) Running via_verify_command_stream on an AGP buffer is dead slow. 2) User-space could sneak in and modify the buffer after the security check. /Thomas. brucech...@via.com.tw wrote: > Hello All: > This is patch 5 of the 5 patches. It's based on > 2.6.32-rc3+patch1+patch2+patch3+patch4. It adds verification for video > command flush. > > 1 file has been modified for this patch. > > Sign-off by Bruce C. Chang > diff -Nur linux-2.6.32-rc3-old/drivers/gpu/drm/via/via_dma.c > linux-2.6.32-rc3-new/drivers/gpu/drm/via/via_dma.c > --- linux-2.6.32-rc3-old/drivers/gpu/drm/via/via_dma.c2009-10-08 > 10:19:59.0 +0800 > +++ linux-2.6.32-rc3-new/drivers/gpu/drm/via/via_dma.c2009-10-08 > 10:20:08.0 +0800 > @@ -419,7 +419,7 @@ > u32 pause_addr, pause_addr_hi, pause_addr_lo; > u32 *cur_virtual; > u32 command; > - int i = 0; > + int i = 0, ret; > struct drm_local_map map; > > LOCK_TEST_WITH_RETURN(dev, file_priv); > @@ -499,6 +499,10 @@ > } > } > > + ret = via_verify_command_stream((uint32_t *) map.handle, > + cmdbuf_info.cmd_size, dev, 1); > + if (ret) > + return ret; > cur_virtual = map.handle + cmdbuf_info.cmd_size; > > VIA_OUT_VIDEO_AGP_BUFFER(HC_HEADER2 | ((VIA_REG_TRANSET >> 2) << 12) | > > Thanks and Best regards > = > Bruce C. Chang(張祖明) > VIA Technologies, Inc. > Address: 1F, 531, Chung-Cheng Road, Hsin-Tien, 231 Taipei > Tel: +886-2-22185452 Ext 7323 > Mobile: +886-968343824 > Fax: +886-2-22186282 > Skype: Bruce.C.Chang > Email: brucech...@via.com.tw > -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Patch VIA UniChrome DRM][3/5 Ver1] Enhance DRM robustness
Bruce,
This looks OK, except for one modification below. Could you comment on
that one?
brucech...@via.com.tw wrote:
> diff -Nur linux-2.6.32-rc3-old/drivers/gpu/drm/via/via_mm.c
> linux-2.6.32-rc3-new/drivers/gpu/drm/via/via_mm.c
> --- linux-2.6.32-rc3-old/drivers/gpu/drm/via/via_mm.c 2009-10-08
> 10:17:39.0 +0800
> +++ linux-2.6.32-rc3-new/drivers/gpu/drm/via/via_mm.c 2009-10-08
> 10:18:08.0 +0800
> @@ -91,6 +91,17 @@
> int via_final_context(struct drm_device *dev, int context)
> {
> drm_via_private_t *dev_priv = (drm_via_private_t *) dev->dev_private;
> + struct drm_ctx_list *pos, *n;
> + bool context_valid = 0;
> +
> + list_for_each_entry_safe(pos, n, &dev->ctxlist, head)
> + if (pos->handle == context) {
> + context_valid = 1;
> + break;
> + }
> +
> + if (!context_valid)
> + return 0;
>
> via_release_futex(dev_priv, context);
>
When is this function called with an invalid context? Could you describe
what error you are seeing.
Thanks,
Thomas
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Patch VIA UniChrome DRM][1/5 Ver1] Add support for ACPI suspend/resume
Bruce,
brucech...@via.com.tw wrote:
> Hello All:
> This is patch 1 of the 5 patches. It's based on 2.6.32-rc3 and for the
> support of ACPI suspend/resume.
> To support suspend / resume, some information located in video memory need to
> be saved because
> 3D sync mechanism will use these information after resume. 6 files has been
> modified for this patch.
>
> Sign-off by Bruce c. Chang
>
With the non-modesetting drm model, this is the task of the X server,
mainly because there might be an fbdev driver like viafb that owns the
device at suspend time. If the drm driver were to do the same, there
would be a clash.
For example, the openChrome X driver handles (or at least should handle)
this in the leavevt / entervt functions that are called before suspend
and after resume like so:
leavevt {
dri_lock();
copy_all_dri_vram_to_system_using_pci_dma();
}
entervt {
copy_saved_dri_vram_back();
init_3d_engine();
dri_unlock();
}
It might be that one should add functionality to take down agp and
restore agp command submission as well.
Could you describe why you don't use this scheme?
Also, could you describe in what situations INIT_JUDGE is needed?
Thanks,
Thomas
> diff -Nur linux-2.6.32-rc3-old/drivers/gpu/drm/via/via_dma.c
> linux-2.6.32-rc3-new/drivers/gpu/drm/via/via_dma.c
> --- linux-2.6.32-rc3-old/drivers/gpu/drm/via/via_dma.c2009-10-05
> 08:12:30.0 +0800
> +++ linux-2.6.32-rc3-new/drivers/gpu/drm/via/via_dma.c2009-10-08
> 10:11:59.0 +0800
> @@ -68,6 +68,8 @@
> *vb++ = (w2); \
> dev_priv->dma_low += 8;
>
> +static void via_cmdbuf_flush(struct drm_via_private *dev_priv,
> + uint32_t cmd_type);
> static void via_cmdbuf_start(drm_via_private_t * dev_priv);
> static void via_cmdbuf_pause(drm_via_private_t * dev_priv);
> static void via_cmdbuf_reset(drm_via_private_t * dev_priv);
> @@ -155,6 +157,11 @@
>
> int via_dma_cleanup(struct drm_device * dev)
> {
> + struct drm_via_video_save_head *pnode;
> +
> + for (pnode = via_video_save_head; pnode; pnode =
> + (struct drm_via_video_save_head *)pnode->next)
> + memcpy(pnode->psystemmem, pnode->pvideomem, pnode->size);
> if (dev->dev_private) {
> drm_via_private_t *dev_priv =
> (drm_via_private_t *) dev->dev_private;
> @@ -175,6 +182,7 @@
> drm_via_private_t * dev_priv,
> drm_via_dma_init_t * init)
> {
> + struct drm_via_video_save_head *pnode;
> if (!dev_priv || !dev_priv->mmio) {
> DRM_ERROR("via_dma_init called before via_map_init\n");
> return -EFAULT;
> @@ -195,6 +203,9 @@
> return -EINVAL;
> }
>
> + for (pnode = via_video_save_head; pnode; pnode = pnode->next)
> + memcpy(pnode->pvideomem, pnode->psystemmem, pnode->size);
> +
> dev_priv->ring.map.offset = dev->agp->base + init->offset;
> dev_priv->ring.map.size = init->size;
> dev_priv->ring.map.type = 0;
> @@ -737,6 +748,155 @@
> return ret;
> }
>
> +/*The following functions are for ACPI*/
> +
> +static void initialize3Dengine(drm_via_private_t *dev_priv)
> +{
> + int i = 0;
> +
> + VIA_WRITE(0x43C, 0x0001);
> +
> + for (i = 0; i <= 0x7D; i++)
> + VIA_WRITE(0x440, (unsigned long) i << 24);
> +
> + VIA_WRITE(0x43C, 0x0002);
> +
> + for (i = 0; i <= 0x94; i++)
> + VIA_WRITE(0x440, (unsigned long) i << 24);
> +
> + VIA_WRITE(0x440, 0x8240);
> + VIA_WRITE(0x43C, 0x0102);
> +
> + for (i = 0; i <= 0x94; i++)
> + VIA_WRITE(0x440, (unsigned long) i << 24);
> +
> + VIA_WRITE(0x440, 0x8240);
> + VIA_WRITE(0x43C, 0xfe02);
> +
> + for (i = 0; i <= 0x03; i++)
> + VIA_WRITE(0x440, (unsigned long) i << 24);
> +
> + VIA_WRITE(0x43C, 0x0003);
> +
> + for (i = 0; i <= 0xff; i++)
> + VIA_WRITE(0x440, 0);
> +
> + VIA_WRITE(0x43C, 0x0010);
> + VIA_WRITE(0x440, 0x00333004);
> + VIA_WRITE(0x440, 0x1002);
> + VIA_WRITE(0x440, 0x6000);
> + VIA_WRITE(0x440, 0x6100);
> + VIA_WRITE(0x440, 0x6200);
> + VIA_WRITE(0x440, 0x6300);
> + VIA_WRITE(0x440, 0x6400);
> +
> + VIA_WRITE(0x43C, 0x00fe);
> + VIA_WRITE(0x440, 0x40008c0f);
> + VIA_WRITE(0x440, 0x4400);
> + VIA_WRITE(0x440, 0x45080C04);
> + VIA_WRITE(0x440, 0x46800408);
> + VIA_WRITE(0x440, 0x5000);
> + VIA_WRITE(0x440, 0x5100);
> + VIA_WRITE(0x440, 0x5200);
> + VIA_WRITE(0x440, 0x5300);
> +
> +
> + VIA_WRITE(0x43C, 0x00fe);
> + VIA_WRITE(0x440, 0x0801);
> + VIA_WRITE(0x440, 0x0A000183);
> + VIA_WRITE(0x440, 0x0B00019F);
> + VIA_WRITE(0x440, 0x0C00018B);
> + VIA_WRITE(0x440, 0x0D00019B);
> + VIA_WRITE(0x440, 0x0E00);
> + VIA_WRITE(0x440, 0x0F
[Bug 24150] tv out issues with radeon kms drm-next
http://bugs.freedesktop.org/show_bug.cgi?id=24150 --- Comment #8 from Alex Deucher 2009-10-08 07:40:05 PST --- (In reply to comment #7) > > I've found through testing that the difference here is that kms is using NTSC > and ums is using PAL. Researching it seems that my old PAL CRT does offer NTSC > support. > > Testing shows that the frequency of the modeline as shown by xrandr in either > case does not change anything - it's 59.94 using kms or 50 using ums. > The modelines reported by xrandr for tv-out are irrelevant. There just there to provide access to different scaled modes. The driver programs the tv-out hw directly with the native timing of either NTSC or PAL. You can use xrandr to select the tv standard (NTSC or PAL) however. e.g., xrandr --output DIN --set "tv standard" "pal" You may have to double check the property names with kms (xrandr --verbose). -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24397] New: Regression : System hard hangs on starting X Server
http://bugs.freedesktop.org/show_bug.cgi?id=24397 Summary: Regression : System hard hangs on starting X Server Product: Mesa Version: git Platform: x86 (IA32) OS/Version: All Status: NEW Severity: critical Priority: high Component: Drivers/DRI/r300 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: hysv...@gmail.com Created an attachment (id=30160) --> (http://bugs.freedesktop.org/attachment.cgi?id=30160) lspci Asic : Radeon RV630 Details of the X-stack: -- mesa/drm : 7th October -2009 mesa/mesa : 7.6 xorg/xserver : 1.6.0 xorg/xf86-video-ati: 7th October -2009 Observation : -- 1) system hard hangs on startx 2) The issue is not observed on 6th October build -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24397] Regression : System hard hangs on starting X Server
http://bugs.freedesktop.org/show_bug.cgi?id=24397 --- Comment #1 from samit vats 2009-10-08 07:44:36 PST --- Created an attachment (id=30161) --> (http://bugs.freedesktop.org/attachment.cgi?id=30161) xorg.conf -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24397] Regression : System hard hangs on starting X Server
http://bugs.freedesktop.org/show_bug.cgi?id=24397 --- Comment #2 from samit vats 2009-10-08 07:45:26 PST --- Created an attachment (id=30162) --> (http://bugs.freedesktop.org/attachment.cgi?id=30162) Xorg.log -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24397] Regression : System hard hangs on starting X Server
http://bugs.freedesktop.org/show_bug.cgi?id=24397 Alex Deucher changed: What|Removed |Added Attachment #30162|application/octet-stream|text/plain mime type|| Attachment #30162|0 |1 is patch|| -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24397] Regression : System hard hangs on starting X Server
http://bugs.freedesktop.org/show_bug.cgi?id=24397 --- Comment #3 from Alex Deucher 2009-10-08 08:47:25 PST --- Any chance you could bisect this? I can reproduce this on any of my r6xx cards. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13880] repeated freezes after bios update - Toshiba Satellite L300
http://bugzilla.kernel.org/show_bug.cgi?id=13880 --- Comment #22 from Thoralf Dassler 2009-10-08 15:56:51 --- Update: Toshiba have released another BIOS update. Now the video driver works again as it did before the previous BIOS update. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23693] KMS has been broken on ATI RV250 Lf (Radeon M9)
http://bugs.freedesktop.org/show_bug.cgi?id=23693 --- Comment #7 from Johannes Obermayr 2009-10-08 09:40:36 PST --- KMS on console (init 3) has worked again since authorBen Skeggs 2009-10-06 04:27:25 (GMT) committer Ben Skeggs 2009-10-06 04:27:25 (GMT) commit57e80de6515003f46762c6d0359ba957b179aeb8 Merge branch 'drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6 into nouveau Thanks... But if I try starting something with X (kdm/kde4, SaX2, ...) I can only see a very bad screen (see http://www.freeimagehosting.net/uploads/de9994204f.jpg). Mostly there are no lines but - I think - millions of points (pixels) distributed over complete screen which firstly change and then seem to stay... I have latest git installed: mesa/drm mesa/mesa nouveau/linux-2.6 (only kernel modules and kernel 2.6.31) xorg/driver/xf86-video-ati -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23693] KMS has been broken on ATI RV250 Lf (Radeon M9)
http://bugs.freedesktop.org/show_bug.cgi?id=23693 --- Comment #8 from Alex Deucher 2009-10-08 09:45:56 PST --- Does disabling AGP or changin the AGP mode help? E.g., modprobe radeon modeset=1 agpmode=-1 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/i915: overlay: kill one more unnecessary uninterruptible sleep
On Sun, 2009-10-04 at 15:00 +0200, Daniel Vetter wrote:
> I've simply overlooked one case in the conversion to interruptible
> sleeps. Rectify this.
>
> Also delete a leftover debug printk.
OK, I'm confused about what this patch is about. I thought you were
going to check if the patch series I applied was the right one or not,
given that it was older than your comment "please pull my tree instead
of the patch series I sent out" on IRC.
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_overlay.c | 17 +++--
> 1 files changed, 7 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_overlay.c
> b/drivers/gpu/drm/i915/intel_overlay.c
> index 972d715..f1bf0b0 100644
> --- a/drivers/gpu/drm/i915/intel_overlay.c
> +++ b/drivers/gpu/drm/i915/intel_overlay.c
> @@ -286,16 +286,15 @@ static int intel_overlay_wait_flip(struct intel_overlay
> *overlay)
> RING_LOCALS;
>
> if (overlay->last_flip_req != 0) {
> - ret = i915_do_wait_request(dev, overlay->last_flip_req, 0);
> - if (ret != 0)
> - return ret;
> -
> - overlay->last_flip_req = 0;
> + ret = i915_do_wait_request(dev, overlay->last_flip_req, 1);
> + if (ret == 0) {
> + overlay->last_flip_req = 0;
>
> - tmp = I915_READ(ISR);
> + tmp = I915_READ(ISR);
>
> - if (!(tmp & I915_OVERLAY_PLANE_FLIP_PENDING_INTERRUPT))
> - return 0;
> + if (!(tmp & I915_OVERLAY_PLANE_FLIP_PENDING_INTERRUPT))
> + return 0;
> + }
> }
>
> /* synchronous slowpath */
> @@ -439,8 +438,6 @@ int intel_overlay_recover_from_interrupt(struct
> intel_overlay *overlay,
> return ret;
>
> case SWITCH_OFF_STAGE_2:
> - printk("switch off 2\n");
> -
> BUG_ON(!overlay->vid_bo);
> obj = overlay->vid_bo->obj;
>
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24400] New: [KMS] Radeon kernel oops (null pointer dereference) radeon_atom_encoder_mode_set
http://bugs.freedesktop.org/show_bug.cgi?id=24400 Summary: [KMS] Radeon kernel oops (null pointer dereference) radeon_atom_encoder_mode_set Product: DRI Version: XOrg CVS Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: tdro...@gmx.de Created an attachment (id=30172) --> (http://bugs.freedesktop.org/attachment.cgi?id=30172) /var/log/messages drm-next modeset=1 My system is a Pentium4 (32bit) with a Radeon x850pro (AGP). I tried the drm-next kernel (build date Wed Sep 16 09:14:34 CEST 2009), but with radeon kms enabled I get an kernel oops: drm-next (modeset=1) --> "/var/log/messages drm-next modeset=1" attachment With kernel 2.6.31 (same config) it works: 2.6.31 (modeset=1) --> "/var/log/messages 2.6.31 modeset=1" attachment I also tried booting the drm-next kernel with radeon.modeset=0, unload the radeon module and load it with modeset=1. The result is also a working environment but many artifacts: drm-next (modeset=0) --> "/var/log/messages drm-next modeset=0" attachment Error: BUG: unable to handle kernel NULL pointer dereference at (null) IP: [] radeon_atom_encoder_mode_set+0x26a/0x950 [radeon] *pde = Oops: [#1] PREEMPT SMP last sysfs file: /sys/devices/platform/radeon_cp.0/firmware/radeon_cp.0/loading -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24400] [KMS] Radeon kernel oops (null pointer dereference) radeon_atom_encoder_mode_set
http://bugs.freedesktop.org/show_bug.cgi?id=24400 --- Comment #1 from Droste 2009-10-08 11:02:30 PST --- Created an attachment (id=30173) --> (http://bugs.freedesktop.org/attachment.cgi?id=30173) /var/log/messages drm-next modeset=0 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24400] [KMS] Radeon kernel oops (null pointer dereference) radeon_atom_encoder_mode_set
http://bugs.freedesktop.org/show_bug.cgi?id=24400 --- Comment #2 from Droste 2009-10-08 11:03:10 PST --- Created an attachment (id=30174) --> (http://bugs.freedesktop.org/attachment.cgi?id=30174) /var/log/messages 2.6.31 modeset=1 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24131] radeon_bo_legacy.c:207: legacy_is_pending: Assertion `bo_legacy->is_pending <= bo->cref' failed
http://bugs.freedesktop.org/show_bug.cgi?id=24131 Tormod Volden changed: What|Removed |Added CC||bugzi07.fdo.tor...@xoxy.net --- Comment #7 from Tormod Volden 2009-10-08 14:16:43 PST --- Does anyone know a way of reproducing this other than installing KDE? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24131] radeon_bo_legacy.c:207: legacy_is_pending: Assertion `bo_legacy->is_pending <= bo->cref' failed
http://bugs.freedesktop.org/show_bug.cgi?id=24131 --- Comment #8 from Martin Garbolinski 2009-10-08 14:37:33 PST --- On my radeon x1200 (rs690) the desktop loads but when opening any application window (for example system settings) Xorg crashes and I'm back at kdm login. >From this point on changing to terminal ctrl+alt+f1 doesn't work as by doing that I'm left with kdm bitmap and some graphical garbage is produced at the top of the screen. When compositing is disabled everything is ok, also strangely when booting up the kernel with radeon.modeset=1 and using KMS compositing in kde works as it should and the bug is gone. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24408] New: No mouse events in Clutter-based applications.
http://bugs.freedesktop.org/show_bug.cgi?id=24408 Summary: No mouse events in Clutter-based applications. Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: sca...@gmail.com Clutter-based applications do not receive mouse events. "glReadPixels" is used by Clutter to identify the currently clicked Actor for whatever reason. It seems the implementation of glReadPixels for r600 is wrong somewhere. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23693] KMS has been broken on ATI RV250 Lf (Radeon M9)
http://bugs.freedesktop.org/show_bug.cgi?id=23693 Johannes Obermayr changed: What|Removed |Added Attachment #29706|0 |1 is obsolete|| Attachment #29848|0 |1 is obsolete|| --- Comment #9 from Johannes Obermayr 2009-10-08 15:26:21 PST --- Created an attachment (id=30190) --> (http://bugs.freedesktop.org/attachment.cgi?id=30190) Gluon's crash I have done further tests after my email to mailinglist. I de-/reinstalled firmware and now I can see KDE - but only with artefacts... (all AGP modes) I think they mostly/mainly happen with some sorts of red and green pixels. If firmware is not installed the above failure occurs. Kubrick works. Gluon crashes on closing (attached). I am not a programmer/developer and so I describe/attach all details of my realizations... -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24150] tv out issues with radeon kms drm-next
http://bugs.freedesktop.org/show_bug.cgi?id=24150 --- Comment #9 from Andy Furniss 2009-10-08 15:45:09 PST --- (In reply to comment #8) > The modelines reported by xrandr for tv-out are irrelevant. There just there > to provide access to different scaled modes. The driver programs the tv-out > hw > directly with the native timing of either NTSC or PAL. You can use xrandr to > select the tv standard (NTSC or PAL) however. e.g., > xrandr --output DIN --set "tv standard" "pal" > You may have to double check the property names with kms (xrandr --verbose). > xrandr --verbose with kms doesn't list the tv_standard, it does with ums. I tried changing ums and got errors the first time as I do if I try with kms - X Error of failed request: BadName (named color or font does not exist) Major opcode of failed request: 145 (RANDR) Minor opcode of failed request: 11 () Serial number of failed request: 27 Current serial number in output stream: 27 but one time with ums it did accept the command, but just trashed the tv output. Will try updating xrandr and xserver later and see if that helps. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drivers/drm: Make ati_pcigart and drm_sman only when needed and drm_debugfs only when DEBUG_FS=Y
Signed-off-by: Matt Parnell --- drivers/gpu/drm/Makefile | 18 ++ 1 files changed, 10 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index d22e64b..71efdad 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -8,12 +8,14 @@ drm-y :=drm_auth.o drm_bufs.o drm_cache.o \ drm_context.o drm_dma.o drm_drawable.o \ drm_drv.o drm_fops.o drm_gem.o drm_ioctl.o drm_irq.o \ drm_lock.o drm_memory.o drm_proc.o drm_stub.o drm_vm.o \ - drm_agpsupport.o drm_scatter.o ati_pcigart.o drm_pci.o \ - drm_sysfs.o drm_hashtab.o drm_sman.o drm_mm.o \ + drm_agpsupport.o drm_scatter.o drm_pci.o \ + drm_sysfs.o drm_hashtab.o drm_mm.o \ drm_crtc.o drm_modes.o drm_edid.o \ - drm_info.o drm_debugfs.o drm_encoder_slave.o + drm_info.o drm_encoder_slave.o + drm-$(CONFIG_COMPAT) += drm_ioc32.o +obj-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_kms_helper-y := drm_fb_helper.o drm_crtc_helper.o @@ -22,14 +24,14 @@ obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o obj-$(CONFIG_DRM) += drm.o obj-$(CONFIG_DRM_TTM) += ttm/ obj-$(CONFIG_DRM_TDFX) += tdfx/ -obj-$(CONFIG_DRM_R128) += r128/ -obj-$(CONFIG_DRM_RADEON)+= radeon/ +obj-$(CONFIG_DRM_R128) += ati_pcigart.o r128/ +obj-$(CONFIG_DRM_RADEON)+= ati_pcigart.o radeon/ obj-$(CONFIG_DRM_MGA) += mga/ obj-$(CONFIG_DRM_I810) += i810/ obj-$(CONFIG_DRM_I830) += i830/ obj-$(CONFIG_DRM_I915) += i915/ -obj-$(CONFIG_DRM_SIS) += sis/ +obj-$(CONFIG_DRM_SIS) += drm_sman.o sis/ obj-$(CONFIG_DRM_SAVAGE)+= savage/ -obj-$(CONFIG_DRM_VIA) +=via/ -obj-$(CONFIG_DRM_NOUVEAU) +=nouveau/ +obj-$(CONFIG_DRM_VIA) += drm_sman.o via/ +obj-$(CONFIG_DRM_NOUVEAU) += nouveau/ obj-y += i2c/ -- 1.6.4.4 -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24150] tv out issues with radeon kms drm-next
http://bugs.freedesktop.org/show_bug.cgi?id=24150 --- Comment #10 from Andy Furniss 2009-10-08 17:32:17 PST --- (In reply to comment #9) > > Will try updating xrandr and xserver later and see if that helps. > That doesn't help, I also tried a fedora live cd and it's not listed and gives the same error with that. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Patch VIA UniChrome DRM][4/5 Ver1] Fix the bug of via_verify.c function
Hello Thomas:
Thank you very much for your helpful comments. Since our engineers are in
China holiday, I would like to collect all of your helpful comments and consult
with them after they come back.
Thanks and Best Regards
=
Bruce C. Chang(張祖明)
VIA Technologies, Inc.
Address: 1F, 531, Chung-Cheng Road, Hsin-Tien, 231 Taipei
Tel: +886-2-22185452 Ext 7323
Mobile: +886-968343824
Fax: +886-2-22186282
Skype: Bruce.C.Chang
Email: brucech...@via.com.tw
-Original Message-
From: Thomas Hellstrom [mailto:tho...@shipmail.org]
Sent: Thursday, October 08, 2009 9:11 PM
To: Bruce Chang
Cc: dri-devel@lists.sourceforge.net; airl...@gmail.com; Harald Welte; Benjamin
Chen; Joseph Chan
Subject: Re: [Patch VIA UniChrome DRM][4/5 Ver1] Fix the bug of via_verify.c
function
Bruce, See inline comments below.
I'll ACK this patch when we've made sure the HEADER3 and HEADER4 are not
violating the security policy.
brucech...@via.com.tw wrote:
> Hello All:
> This is patch 4 of the 5 patches. It's based on
> 2.6.32-rc3+patch1+patch2+patch3. It fixes the bug of via_verify.c
> function.
>
> 3 files has been modified for this patch.
>
> Sign-off by Bruce C. Chang
> diff -Nur linux-2.6.32-rc3-old/drivers/gpu/drm/via/via_3d_reg.h
> linux-2.6.32-rc3-new/drivers/gpu/drm/via/via_3d_reg.h
> --- linux-2.6.32-rc3-old/drivers/gpu/drm/via/via_3d_reg.h 2009-10-05
> 08:12:30.0 +0800
> +++ linux-2.6.32-rc3-new/drivers/gpu/drm/via/via_3d_reg.h 2009-10-08
> 10:19:12.0 +0800
> @@ -1647,4 +1647,7 @@
> #define VIA_VIDEO_HEADER6 0xFE05
> #define VIA_VIDEO_HEADER7 0xFE06
> #define VIA_VIDEOMASK 0x
> +#define HALCYON_HEADER3 0xF400
> +#define HALCYON_HEADER4 0xF600
> +#define HALCYON_HEADER_MASK 0xFE00
>
You make the HEADER3 and HEADER4 commands bypass the verifier. Could you
please briefly describe what these commands do, or point us to some
usable documentation?
> #endif
> diff -Nur linux-2.6.32-rc3-old/drivers/gpu/drm/via/via_verifier.c
> linux-2.6.32-rc3-new/drivers/gpu/drm/via/via_verifier.c
> --- linux-2.6.32-rc3-old/drivers/gpu/drm/via/via_verifier.c 2009-10-05
> 08:12:30.0 +0800
> +++ linux-2.6.32-rc3-new/drivers/gpu/drm/via/via_verifier.c 2009-10-08
> 10:19:12.0 +0800
> @@ -41,6 +41,8 @@
> state_header1,
> state_vheader5,
> state_vheader6,
> + state_header3,
> + state_header4,
> state_error
> } verifier_state_t;
>
> @@ -227,7 +229,10 @@
> {0xf2, check_for_header2_err},
> {0xf0, check_for_header1_err},
> {0xcc, check_for_dummy},
> - {0x00, check_number_texunits}
> + {0x00, check_number_texunits},
> + {0x01, no_check},
> + {0x02, no_check},
> + {0x03, no_check}
> };
>
>
The above is for YUV -> RGB conversion, right?
> @@ -791,10 +797,11 @@
> return 1;
> }
> while (dwords--) {
> - if (*buf++) {
> + if (*buf && !is_dummy_cmd(*buf)) {
> DRM_ERROR("Illegal video command tail.\n");
> return 1;
> }
> + buf++;
> }
> *buffer = buf;
> return 0;
>
Why can't the user-space applications just add 0 to pad the video
command tails?
Even if the hardware accepts dummy commands, the test above adds time to
the verification process.
/Thomas
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23670] [bisected i915 i965] glean case pixelFormats failed
http://bugs.freedesktop.org/show_bug.cgi?id=23670 Shuang He changed: What|Removed |Added Keywords|NEEDINFO| -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24397] Regression :[R6xx]: System hard hangs on starting X Server
http://bugs.freedesktop.org/show_bug.cgi?id=24397 samit vats changed: What|Removed |Added Summary|Regression : System hard|Regression :[R6xx]: System |hangs on starting X Server |hard hangs on starting X ||Server -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23670] [bisected i915 i965] 3~5 OGLC cases fail
http://bugs.freedesktop.org/show_bug.cgi?id=23670 Gordon Jin changed: What|Removed |Added AssignedTo|dri-|e...@anholt.net |de...@lists.sourceforge.net | Summary|[bisected i915 i965] glean |[bisected i915 i965] 3~5 |case pixelFormats failed|OGLC cases fail --- Comment #18 from Gordon Jin 2009-10-08 23:19:22 PST --- change the title since the glean case pass now. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
