[PATCH 25/42] drivers/gpu/drm/radeon: Adjust confusing if indentation

[Julia Lawall]

From: Julia Lawall 

Outdent the code following the if.

The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)

// 
@r disable braces4@
position p1,p2;
statement S1,S2;
@@

(
if (...) { ... }
|
if (...) S1 at p1 S2 at p2
)

@script:python@
p1 << r.p1;
p2 << r.p2;
@@

if (p1[0].column == p2[0].column):
  cocci.print_main("branch",p1)
  cocci.print_secs("after",p2)
// 

Signed-off-by: Julia Lawall 

---
 drivers/gpu/drm/radeon/evergreen.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 957d506..1a2797c 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -136,7 +136,7 @@ bool evergreen_hpd_sense(struct radeon_device *rdev, enum 
radeon_hpd_id hpd)
case RADEON_HPD_6:
if (RREG32(DC_HPD6_INT_STATUS) & DC_HPDx_SENSE)
connected = true;
-   break;
+   break;
default:
break;
}

[Bug 29363] [r300g] Starcraft 2: "r300 VP: Compiler error"

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

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

--- Comment #6 from Tom Stellard  2010-08-05 22:22:27 
PDT ---
Created an attachment (id=37619)
 View: https://bugs.freedesktop.org/attachment.cgi?id=37619
 Review: https://bugs.freedesktop.org/review?bug=29363=37619

Implement vertex shader loops v2

This patch should be better.

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

GSoC: modprobe glint - monitor loses signal

[Matt Turner]

I'll preface this response by saying that the driver is working now,
in very large part due to help I've received from Adam Jackson, Dave
Airlie, Alex Deucher, and Jerome Glisse.

On Thu, Aug 5, 2010 at 5:47 PM, Adam Jackson  wrote:
> On Thu, 2010-08-05 at 12:16 -0400, Matt Turner wrote:
>> Hi,
>> I've hit a snag and I'm not really sure how to debug it.
>>
>> Both xf86-video-glint/src/pm3_dac.c:Permedia3Init and
>> kernel/drivers/video/pm3fb.c:pm3fb_write_mode set the mode in
>> virtually identical ways. I'm trying to do the same, but I think some
>> of what I'm passing in from drm_display_mode is wrong, specifically
>>
>> WREG32(PM3HTotal, ?glint_shift_bpp(bpp, mode->htotal - 1));
>> WREG32(PM3HsEnd, ? glint_shift_bpp(bpp, mode->hsync_end - mode->hdisplay));
>> WREG32(PM3HsStart, glint_shift_bpp(bpp, mode->hsync_start - mode->hdisplay));
>> WREG32(PM3HbEnd, ? glint_shift_bpp(bpp, mode->htotal - mode->hdisplay));
>> WREG32(PM3HgEnd, ? glint_shift_bpp(bpp, mode->htotal - mode->hdisplay));
>> WREG32(PM3ScreenStride, glint_shift_bpp(bpp, crtc->fb->width));
>> WREG32(PM3VTotal, ?glint_shift_bpp(bpp, mode->vtotal - 1));
>> WREG32(PM3VsEnd, ? glint_shift_bpp(bpp, mode->vsync_end - 1));
>> WREG32(PM3VsStart, glint_shift_bpp(bpp, mode->vsync_start - 1));
>> WREG32(PM3VbEnd, ? glint_shift_bpp(bpp, mode->vtotal - mode->vdisplay));
>>
>> I printed the values that xf86-video-glint passes through here, and of
>> course they don't match with anything my driver has. I imagine guess
>> it's because they're all resolution-dependent?
>
> They are. ?What does the X driver print, and what mode are you trying to
> set?

I'm setting 1024x768x24 (32 bpp).

Timings set by my driver are
PM3HTotal: 335
PM3HsEnd: 40
PM3HsStart: 6
PM3HbEnd: 80
PM3HgEnd: 80
PM3ScreenStride: 256
PM3VTotal: 805
PM3VsEnd: 8
PM3VsStart: 2
PM3VbEnd: 38

Timings set by xf86-video-glint are (for the same mode)
PM3HTotal: 327
PM3HsEnd: 28
PM3HsStart: 4
PM3HbEnd: 72
PM3HgEnd: 72
PM3ScreenStride: 256
PM3VTotal: 799
PM3VsEnd: 3
PM3VsStart: 0
PM3VbEnd: 32

So, clearly very close.

The final thing I did to make it work was to set the PM3VideoControl
register to turn on hsync and vsync. So, of course without this I'm
not getting any signals to the monitor. :)

> This though:
>
> ? ?WREG32(PM3VsStart, glint_shift_bpp(bpp, mode->vsync_start - 1));
>
> Versus in the X driver:
>
> ? ?temp2 = mode->CrtcVSyncStart - mode->CrtcVDisplay;
> ? ?...
> ? ?STOREREG(PMVsStart, temp2 - 1);

Yes, you were right about this. I've changed them to
 - PM3VsEnd = mode->vsync_end - mode->vdisplay - 1
 - PM3VsStart = mode->vsync_start - mode->vdisplay - 1

I also noticed that I was using glint_shift_bpp on the vsync timings,
which isn't correct.

> For a mode like 1920x1200R, the former is going to be 1202, but the
> latter is going to be (1203 - 1200) - 1 == 2. ?So assuming the X driver
> is right, the hardware is looking for the distance in clocks between the
> various sync steps, and not their absolute offset from the beginning of
> the line/frame.

Yep, this appears to be the case. It also appears, and I could be
wrong, not to be what the documentation states. :)

> - ajax

Thanks again to everyone who helped me. Now I'll write up some
documentation to finish off the GSoC requirements and hopefully will
fix up the driver to a state where it can live in the kernel.

Matt

[Bug 29363] [r300g] Starcraft 2: "r300 VP: Compiler error"

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

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

Tom Stellard  changed:

   What|Removed |Added

  Attachment #37618|0   |1
is obsolete||

--- Comment #5 from Tom Stellard  2010-08-05 22:10:43 
PDT ---
(From update of attachment 37618)
This patch has a mistake, another one is one the way.

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

[Bug 29363] [r300g] Starcraft 2: "r300 VP: Compiler error"

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

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

--- Comment #4 from Tom Stellard  2010-08-05 21:43:17 
PDT ---
Created an attachment (id=37618)
 View: https://bugs.freedesktop.org/attachment.cgi?id=37618
 Review: https://bugs.freedesktop.org/review?bug=29363=37618

Implement vertex shader loops

Can you test again with this patch and post the output of RADEON_DEBUG=vp.  A
screenshot would also be helpful.

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

[PATCH 3/3] drm/radeon/kms: add support for router objects

[Alex Deucher]

router objects are found on systems that use a mux to control
ddc line to connector routing or to control the actual clock and data
routing from the chip to the connectors.  This patch implements ddc line
routing.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/radeon_atombios.c   |   94 +++
 drivers/gpu/drm/radeon/radeon_connectors.c |   14 -
 drivers/gpu/drm/radeon/radeon_display.c|   12 
 drivers/gpu/drm/radeon/radeon_i2c.c|   29 +
 drivers/gpu/drm/radeon/radeon_mode.h   |   13 
 5 files changed, 147 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c 
b/drivers/gpu/drm/radeon/radeon_atombios.c
index 7851008..6d30868 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -48,7 +48,8 @@ radeon_add_atom_connector(struct drm_device *dev,
  struct radeon_i2c_bus_rec *i2c_bus,
  bool linkb, uint32_t igp_lane_info,
  uint16_t connector_object_id,
- struct radeon_hpd *hpd);
+ struct radeon_hpd *hpd,
+ struct radeon_router *router);

 /* from radeon_legacy_encoder.c */
 extern void
@@ -470,13 +471,15 @@ bool 
radeon_get_atom_connector_info_from_object_table(struct drm_device *dev)
u16 size, data_offset;
u8 frev, crev;
ATOM_CONNECTOR_OBJECT_TABLE *con_obj;
+   ATOM_OBJECT_TABLE *router_obj;
ATOM_DISPLAY_OBJECT_PATH_TABLE *path_obj;
ATOM_OBJECT_HEADER *obj_header;
-   int i, j, path_size, device_support;
+   int i, j, k, path_size, device_support;
int connector_type;
u16 igp_lane_info, conn_id, connector_object_id;
bool linkb;
struct radeon_i2c_bus_rec ddc_bus;
+   struct radeon_router router;
struct radeon_gpio_rec gpio;
struct radeon_hpd hpd;

@@ -486,6 +489,8 @@ bool 
radeon_get_atom_connector_info_from_object_table(struct drm_device *dev)
if (crev < 2)
return false;

+   router.valid = false;
+
obj_header = (ATOM_OBJECT_HEADER *) (ctx->bios + data_offset);
path_obj = (ATOM_DISPLAY_OBJECT_PATH_TABLE *)
(ctx->bios + data_offset +
@@ -493,6 +498,9 @@ bool 
radeon_get_atom_connector_info_from_object_table(struct drm_device *dev)
con_obj = (ATOM_CONNECTOR_OBJECT_TABLE *)
(ctx->bios + data_offset +
 le16_to_cpu(obj_header->usConnectorObjectTableOffset));
+   router_obj = (ATOM_OBJECT_TABLE *)
+   (ctx->bios + data_offset +
+le16_to_cpu(obj_header->usRouterObjectTableOffset));
device_support = le16_to_cpu(obj_header->usDeviceSupport);

path_size = 0;
@@ -579,33 +587,86 @@ bool 
radeon_get_atom_connector_info_from_object_table(struct drm_device *dev)
if (connector_type == DRM_MODE_CONNECTOR_Unknown)
continue;

-   for (j = 0; j < ((le16_to_cpu(path->usSize) - 8) / 2);
-j++) {
-   uint8_t enc_obj_id, enc_obj_num, enc_obj_type;
+   for (j = 0; j < ((le16_to_cpu(path->usSize) - 8) / 2); 
j++) {
+   uint8_t grph_obj_id, grph_obj_num, 
grph_obj_type;

-   enc_obj_id =
+   grph_obj_id =
(le16_to_cpu(path->usGraphicObjIds[j]) &
 OBJECT_ID_MASK) >> OBJECT_ID_SHIFT;
-   enc_obj_num =
+   grph_obj_num =
(le16_to_cpu(path->usGraphicObjIds[j]) &
 ENUM_ID_MASK) >> ENUM_ID_SHIFT;
-   enc_obj_type =
+   grph_obj_type =
(le16_to_cpu(path->usGraphicObjIds[j]) &
 OBJECT_TYPE_MASK) >> OBJECT_TYPE_SHIFT;

-   /* FIXME: add support for router objects */
-   if (enc_obj_type == GRAPH_OBJECT_TYPE_ENCODER) {
-   if (enc_obj_num == 2)
+   if (grph_obj_type == GRAPH_OBJECT_TYPE_ENCODER) 
{
+   if (grph_obj_num == 2)
linkb = true;
else
linkb = false;

radeon_add_atom_encoder(dev,
-   enc_obj_id,
+   grph_obj_id,
le16_to_cpu
  

[PATCH 2/3] drm/radeon/kms: rework combios i2c handling

[Alex Deucher]

Handle asic specific table to hw mappings in
combios_setup_i2c_bus() directly.  This allows us
to remove most of the combios quirks and clean up
the i2c bus setup.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/radeon_combios.c |  415 +--
 1 files changed, 168 insertions(+), 247 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_combios.c 
b/drivers/gpu/drm/radeon/radeon_combios.c
index 18c84cf..885dcfa 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -479,21 +479,67 @@ radeon_combios_get_hardcoded_edid(struct radeon_device 
*rdev)
return NULL;
 }

-/* standard i2c gpio lines */
-#define RADEON_I2C_MONID_ID 0
-#define RADEON_I2C_DVI_ID   1
-#define RADEON_I2C_VGA_ID   2
-#define RADEON_I2C_CRT2_ID  3
-#define RADEON_I2C_MM_ID4
-/* custom defined gpio lines */
-#define RADEON_I2C_LCD_ID   5 /* ddc for laptop panels */
-#define RADEON_I2C_GPIO_ID  6 /* rs4xx gpio ddc */
-#define RADEON_I2C_DVO_ID   7 /* i2c bus for dvo */
-
 static struct radeon_i2c_bus_rec combios_setup_i2c_bus(struct radeon_device 
*rdev,
-  int ddc_line)
+  enum radeon_combios_ddc 
ddc,
+  u32 clk_mask,
+  u32 data_mask)
 {
struct radeon_i2c_bus_rec i2c;
+   int ddc_line = 0;
+
+   /* ddc id= mask reg
+* DDC_NONE_DETECTED = none
+* DDC_DVI   = RADEON_GPIO_DVI_DDC
+* DDC_VGA   = RADEON_GPIO_VGA_DDC
+* DDC_LCD   = RADEON_GPIOPAD_MASK
+* DDC_GPIO  = RADEON_MDGPIO_MASK
+* r1xx/r2xx
+* DDC_MONID = RADEON_GPIO_MONID
+* DDC_CRT2  = RADEON_GPIO_CRT2_DDC
+* r3xx
+* DDC_MONID = RADEON_GPIO_MONID
+* DDC_CRT2  = RADEON_GPIO_DVI_DDC
+* rs3xx/rs4xx
+* DDC_MONID = RADEON_GPIOPAD_MASK
+* DDC_CRT2  = RADEON_GPIO_MONID
+*/
+   switch (ddc) {
+   case DDC_NONE_DETECTED:
+   default:
+   ddc_line = 0;
+   break;
+   case DDC_DVI:
+   ddc_line = RADEON_GPIO_DVI_DDC;
+   break;
+   case DDC_VGA:
+   ddc_line = RADEON_GPIO_VGA_DDC;
+   break;
+   case DDC_LCD:
+   ddc_line = RADEON_GPIOPAD_MASK;
+   break;
+   case DDC_GPIO:
+   ddc_line = RADEON_MDGPIO_MASK;
+   break;
+   case DDC_MONID:
+   if (rdev->family == CHIP_RS300 ||
+   rdev->family == CHIP_RS400 ||
+   rdev->family == CHIP_RS480)
+   ddc_line = RADEON_GPIOPAD_MASK;
+   else
+   ddc_line = RADEON_GPIO_MONID;
+   break;
+   case DDC_CRT2:
+   if (rdev->family == CHIP_RS300 ||
+   rdev->family == CHIP_RS400 ||
+   rdev->family == CHIP_RS480)
+   ddc_line = RADEON_GPIO_MONID;
+   else if (rdev->family >= CHIP_R300) {
+   ddc_line = RADEON_GPIO_DVI_DDC;
+   ddc = DDC_DVI;
+   } else
+   ddc_line = RADEON_GPIO_CRT2_DDC;
+   break;
+   }

if (ddc_line == RADEON_GPIOPAD_MASK) {
i2c.mask_clk_reg = RADEON_GPIOPAD_MASK;
@@ -514,15 +560,6 @@ static struct radeon_i2c_bus_rec 
combios_setup_i2c_bus(struct radeon_device *rde
i2c.y_clk_reg = RADEON_MDGPIO_Y;
i2c.y_data_reg = RADEON_MDGPIO_Y;
} else {
-   i2c.mask_clk_mask = RADEON_GPIO_EN_1;
-   i2c.mask_data_mask = RADEON_GPIO_EN_0;
-   i2c.a_clk_mask = RADEON_GPIO_A_1;
-   i2c.a_data_mask = RADEON_GPIO_A_0;
-   i2c.en_clk_mask = RADEON_GPIO_EN_1;
-   i2c.en_data_mask = RADEON_GPIO_EN_0;
-   i2c.y_clk_mask = RADEON_GPIO_Y_1;
-   i2c.y_data_mask = RADEON_GPIO_Y_0;
-
i2c.mask_clk_reg = ddc_line;
i2c.mask_data_reg = ddc_line;
i2c.a_clk_reg = ddc_line;
@@ -533,6 +570,26 @@ static struct radeon_i2c_bus_rec 
combios_setup_i2c_bus(struct radeon_device *rde
i2c.y_data_reg = ddc_line;
}

+   if (clk_mask && data_mask) {
+   i2c.mask_clk_mask = clk_mask;
+   i2c.mask_data_mask = data_mask;
+   i2c.a_clk_mask = clk_mask;
+   i2c.a_data_mask = data_mask;
+   i2c.en_clk_mask = clk_mask;
+   i2c.en_data_mask = data_mask;
+   i2c.y_clk_mask = clk_mask;
+   i2c.y_data_mask = data_mask;
+   } else {
+   i2c.mask_clk_mask = RADEON_GPIO_EN_1;
+   i2c.mask_data_mask = 

[PATCH 1/3] drm/radeon/kms: unify i2c handling

[Alex Deucher]

Previously we added i2c buses as needed when enumerating connectors
power management, etc.  This only exposed the actual buses used and
could have lead to the same buse getting created more than once if
one buses was used for more than one purpose.  This patch sets up
all i2c buses on the card in one place and users of the buses just
point back to the one instance.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/radeon.h|2 +
 drivers/gpu/drm/radeon/radeon_atombios.c   |   67 +++-
 drivers/gpu/drm/radeon/radeon_combios.c|   77 +---
 drivers/gpu/drm/radeon/radeon_connectors.c |   31 
 drivers/gpu/drm/radeon/radeon_display.c|5 ++
 drivers/gpu/drm/radeon/radeon_i2c.c|   53 +++
 drivers/gpu/drm/radeon/radeon_mode.h   |   11 
 7 files changed, 214 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 368fecf..fed3d07 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1100,6 +1100,8 @@ struct radeon_device {
struct notifier_block acpi_nb;
/* only one userspace can use Hyperz features at a time */
struct drm_file *hyperz_filp;
+   /* i2c buses */
+   struct radeon_i2c_chan *i2c_bus[RADEON_MAX_I2C_BUS];
 };

 int radeon_device_init(struct radeon_device *rdev,
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c 
b/drivers/gpu/drm/radeon/radeon_atombios.c
index 2b9a516..7851008 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -114,7 +114,8 @@ static inline struct radeon_i2c_bus_rec 
radeon_lookup_i2c_gpio(struct radeon_dev

i2c.i2c_id = gpio->sucI2cId.ucAccess;

-   i2c.valid = true;
+   if (i2c.mask_clk_reg)
+   i2c.valid = true;
break;
}
}
@@ -123,6 +124,66 @@ static inline struct radeon_i2c_bus_rec 
radeon_lookup_i2c_gpio(struct radeon_dev
return i2c;
 }

+void radeon_atombios_i2c_init(struct radeon_device *rdev)
+{
+   struct atom_context *ctx = rdev->mode_info.atom_context;
+   ATOM_GPIO_I2C_ASSIGMENT *gpio;
+   struct radeon_i2c_bus_rec i2c;
+   int index = GetIndexIntoMasterTable(DATA, GPIO_I2C_Info);
+   struct _ATOM_GPIO_I2C_INFO *i2c_info;
+   uint16_t data_offset, size;
+   int i, num_indices;
+   char stmp[32];
+
+   memset(, 0, sizeof(struct radeon_i2c_bus_rec));
+
+   if (atom_parse_data_header(ctx, index, , NULL, NULL, 
_offset)) {
+   i2c_info = (struct _ATOM_GPIO_I2C_INFO *)(ctx->bios + 
data_offset);
+
+   num_indices = (size - sizeof(ATOM_COMMON_TABLE_HEADER)) /
+   sizeof(ATOM_GPIO_I2C_ASSIGMENT);
+
+   for (i = 0; i < num_indices; i++) {
+   gpio = _info->asGPIO_Info[i];
+   i2c.valid = false;
+   i2c.mask_clk_reg = 
le16_to_cpu(gpio->usClkMaskRegisterIndex) * 4;
+   i2c.mask_data_reg = 
le16_to_cpu(gpio->usDataMaskRegisterIndex) * 4;
+   i2c.en_clk_reg = 
le16_to_cpu(gpio->usClkEnRegisterIndex) * 4;
+   i2c.en_data_reg = 
le16_to_cpu(gpio->usDataEnRegisterIndex) * 4;
+   i2c.y_clk_reg = le16_to_cpu(gpio->usClkY_RegisterIndex) 
* 4;
+   i2c.y_data_reg = 
le16_to_cpu(gpio->usDataY_RegisterIndex) * 4;
+   i2c.a_clk_reg = le16_to_cpu(gpio->usClkA_RegisterIndex) 
* 4;
+   i2c.a_data_reg = 
le16_to_cpu(gpio->usDataA_RegisterIndex) * 4;
+   i2c.mask_clk_mask = (1 << gpio->ucClkMaskShift);
+   i2c.mask_data_mask = (1 << gpio->ucDataMaskShift);
+   i2c.en_clk_mask = (1 << gpio->ucClkEnShift);
+   i2c.en_data_mask = (1 << gpio->ucDataEnShift);
+   i2c.y_clk_mask = (1 << gpio->ucClkY_Shift);
+   i2c.y_data_mask = (1 << gpio->ucDataY_Shift);
+   i2c.a_clk_mask = (1 << gpio->ucClkA_Shift);
+   i2c.a_data_mask = (1 << gpio->ucDataA_Shift);
+
+   if (gpio->sucI2cId.sbfAccess.bfHW_Capable)
+   i2c.hw_capable = true;
+   else
+   i2c.hw_capable = false;
+
+   if (gpio->sucI2cId.ucAccess == 0xa0)
+   i2c.mm_i2c = true;
+   else
+   i2c.mm_i2c = false;
+
+   i2c.i2c_id = gpio->sucI2cId.ucAccess;
+
+   if (i2c.mask_clk_reg) {
+   i2c.valid = true;
+   sprintf(stmp, "0x%x", 

[Bug 28955] [r300g]: refresh/update/damage issues using compiz.

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

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

--- Comment #9 from Marek Ol??k  2010-08-05 19:56:09 PDT 
---
Created an attachment (id=37614)
 View: https://bugs.freedesktop.org/attachment.cgi?id=37614
 Review: https://bugs.freedesktop.org/review?bug=28955=37614

possible workaround

Could both of you please try this patch? Don't be happy if it fixes the issue
for you, it's not a real fix and it hurts performance a lot.

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

[Bug 29244] [wine][r300g] Spore Creature Creator segfaults

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

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

Marek Ol??k  changed:

   What|Removed |Added

 CC||crumja at gmail.com

--- Comment #2 from Marek Ol??k  2010-08-05 19:15:45 PDT 
---
*** Bug 28477 has been marked as a duplicate of this 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 28477] [R300g] dxdiag directx tests fail on vmware workstation 7.1.0 w/ r500 card using gallium

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

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

Marek Ol??k  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from Marek Ol??k  2010-08-05 19:15:45 PDT 
---
Please follow bug 29244 instead.

*** This bug has been marked as a duplicate of bug 29244 ***

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

[Bug 28955] [r300g]: refresh/update/damage issues using compiz.

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

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

--- Comment #8 from Droste  2010-08-05 18:18:35 PDT ---
Created an attachment (id=37612)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=37612)
Example scrolling in firefox + kwin compositing and r300g

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

[Bug 27314] DP link training fails on 2560x1440 panels

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

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

--- Comment #18 from Travis Glenn Hansen  
2010-08-05 18:12:10 PDT ---
Created an attachment (id=37607)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=37607)
avivotool regs all (patched radeontool package)

[Bug 27314] DP link training fails on 2560x1440 panels

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

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

--- Comment #17 from Travis Glenn Hansen  
2010-08-05 18:10:05 PDT ---
Created an attachment (id=37606)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=37606)
avivotool regs all (vanilla radeontool package)

This is the output of my machine while running fglrx.
attachment 34810 *not* applied.  will upload output with that patch
momentarily.

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

[Bug 28955] [r300g]: refresh/update/damage issues using compiz.

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

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

--- Comment #7 from Droste  2010-08-05 18:08:53 PDT ---
I'm having the same issue with r300g on a rv570 and kwin (compositing enabled,
KDE SC 4.5rc2).

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

[Bug 27314] DP link training fails on 2560x1440 panels

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

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

--- Comment #16 from Alex Deucher  2010-08-05 17:55:57 PDT 
---
This is a problem in the link training algo.  The timing and ordering may need
to be tweaked to make some monitors happy.

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

GSoC: modprobe glint - monitor loses signal

[Adam Jackson]

On Thu, 2010-08-05 at 12:16 -0400, Matt Turner wrote:
> Hi,
> I've hit a snag and I'm not really sure how to debug it.
> 
> Both xf86-video-glint/src/pm3_dac.c:Permedia3Init and
> kernel/drivers/video/pm3fb.c:pm3fb_write_mode set the mode in
> virtually identical ways. I'm trying to do the same, but I think some
> of what I'm passing in from drm_display_mode is wrong, specifically
> 
> WREG32(PM3HTotal,  glint_shift_bpp(bpp, mode->htotal - 1));
> WREG32(PM3HsEnd,   glint_shift_bpp(bpp, mode->hsync_end - mode->hdisplay));
> WREG32(PM3HsStart, glint_shift_bpp(bpp, mode->hsync_start - mode->hdisplay));
> WREG32(PM3HbEnd,   glint_shift_bpp(bpp, mode->htotal - mode->hdisplay));
> WREG32(PM3HgEnd,   glint_shift_bpp(bpp, mode->htotal - mode->hdisplay));
> WREG32(PM3ScreenStride, glint_shift_bpp(bpp, crtc->fb->width));
> WREG32(PM3VTotal,  glint_shift_bpp(bpp, mode->vtotal - 1));
> WREG32(PM3VsEnd,   glint_shift_bpp(bpp, mode->vsync_end - 1));
> WREG32(PM3VsStart, glint_shift_bpp(bpp, mode->vsync_start - 1));
> WREG32(PM3VbEnd,   glint_shift_bpp(bpp, mode->vtotal - mode->vdisplay));
>
> I printed the values that xf86-video-glint passes through here, and of
> course they don't match with anything my driver has. I imagine guess
> it's because they're all resolution-dependent?

They are.  What does the X driver print, and what mode are you trying to
set?

This though:

WREG32(PM3VsStart, glint_shift_bpp(bpp, mode->vsync_start - 1));

Versus in the X driver:

temp2 = mode->CrtcVSyncStart - mode->CrtcVDisplay;
...
STOREREG(PMVsStart, temp2 - 1);

For a mode like 1920x1200R, the former is going to be 1202, but the
latter is going to be (1203 - 1200) - 1 == 2.  So assuming the X driver
is right, the hardware is looking for the distance in clocks between the
various sync steps, and not their absolute offset from the beginning of
the line/frame.

- ajax
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20100805/14d928ab/attachment.pgp>

[Bug 29226] on r600 3d applications are rendered in too bright colors

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

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

--- Comment #8 from Michal Suchanek  2010-08-05 
17:24:35 PDT ---
Created an attachment (id=37605)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=37605)
a simplified version of shadowtex

Attaching a simplified vesion of shadowtex which only uses the vertex program,
no textures.

This demo fails equally on r600 and r600g, no more crash.

For your convenience the scene is rotated so that the misrendered green ball is
in front.

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

[Bug 25280] r600: glPolygonStipple broken

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

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

Michal Suchanek  changed:

   What|Removed |Added

 CC||hramrach at centrum.cz

--- Comment #1 from Michal Suchanek  2010-08-05 
17:16:13 PDT ---
Also broken on r600g

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

[Bug 29066] [r300c, r300g] pipes triggers Assertion `boi->space_accounted' failed

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

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

Marek Ol??k  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||NOTOURBUG

--- Comment #15 from Marek Ol??k  2010-08-05 16:57:15 PDT 
---
According to the last feedback, this issue seems to be resolved by using the
driver from git instead of the PPA. Closing..

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

[Bug 28800] [r300c, r300g] Texture corruption with World of Warcraft

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

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

--- Comment #15 from Marek Ol??k  2010-08-05 16:44:32 PDT 
---
I have tried everything in r300g. Flushing and invalidating all caches,
flushing command stream after every draw operation and re-emitting all state,
nothing helps.

Chris, considering what you say, I think this is a kernel issue, not an r300g
issue.

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

[Bug 28993] [r300g] lightmap texture corruption in some games

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

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

--- Comment #7 from Marek Ol??k  2010-08-05 16:40:45 PDT 
---
Please follow bug 28800 instead of this one.

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

[Bug 28800] [r300c, r300g] Texture corruption with World of Warcraft

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

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

Marek Ol??k  changed:

   What|Removed |Added

 CC||aaalmosss at gmail.com

--- Comment #14 from Marek Ol??k  2010-08-05 16:39:34 PDT 
---
*** Bug 28993 has been marked as a duplicate of this 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 29067] WebGL in Firefox is very slow (pegs the cpu)

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

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

Sven Arvidsson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Sven Arvidsson  2010-08-05 16:07:41 PDT ---
Using git master (from yesterday?) this is no longer a problem!

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

[PATCH 05/15] drivers: gpu: drm: i915: Fix a typo.

[Andrea Gelmini]

"userpace" -> "userspace"

Signed-off-by: Andrea Gelmini 
---
 drivers/gpu/drm/i915/i915_irq.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index dba53d4..445a49a 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -620,7 +620,7 @@ static void i915_capture_error_state(struct drm_device *dev)
}

/* We need to copy these to an anonymous buffer as the simplest
-* method to avoid being overwritten by userpace.
+* method to avoid being overwritten by userspace.
 */
error->batchbuffer[0] = i915_error_object_create(dev, batchbuffer[0]);
error->batchbuffer[1] = i915_error_object_create(dev, batchbuffer[1]);
-- 
1.7.2.1.85.g2d089

2.6.35-rc6+: i915: Bisected regression

[Shuang He]

  On 2010-8-1 18:51, Thomas Meyer wrote:
> Am 01.08.2010 um 13:42 schrieb Stefan Richter:
>
>> Thomas Meyer wrote:
>>> This commit makes suspend to ram unreliable for me:
>>>
>>> commit d1b851fc0d105caa6b6e3e7c92d2987dfb52cbe0
>>> Author: Zou Nan hai
>>> Date:   Fri May 21 09:08:57 2010 +0800
>>>
>>> drm/i915: implement BSD ring buffer V2
>>>
>>> The BSD (bit stream decoder) ring is used for accessing the BSD engine
>>> which decodes video bitstream for H.264 and VC1 on G45+.  It is
>>> asynchronous with the render ring and has access to separate parts of
>>> the GPU from it, though the render cache is coherent between the two.
>>>
>>> Signed-off-by: Zou Nan hai
>>> Signed-off-by: Xiang Hai hao
>>> Signed-off-by: Eric Anholt
>>>
>>> git revert didn't work on 2.6.35-rc6 so I just changed the HAS_BSD thing to:
>>>
>>> #define HAS_BSD(dev)(0)
>>>
>>> with this change applied suspend to ram is back to the reliability of 
>>> 2.6.34.y
>>>
>>> with kind regards
>>> thomas
>> Added CCs.
>>
>> Thomas, on what hardware did you observe the regression?
> Is a Intel mobile express gm45 chipset.
>
>>   Is it suspend
>> or resume that is unreliable?
> suspend never finishes/hangs.
>
>>   What are the particular symptoms --- does
>> not suspend, crashes during suspend, crashes during resume...?
> Does not suspend, backlight is on.


Could you help report a bug for this issue by following 
http://intellinuxgraphics.org/how_to_report_bug.html

Thanks
 --Shuang

>> -- 
>> Stefan Richter
>> -=-==-=- =--- =
>> http://arcgraph.de/sr/
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

GSoC: modprobe glint - monitor loses signal

[Matt Turner]

Hi,
I've hit a snag and I'm not really sure how to debug it.

Both xf86-video-glint/src/pm3_dac.c:Permedia3Init and
kernel/drivers/video/pm3fb.c:pm3fb_write_mode set the mode in
virtually identical ways. I'm trying to do the same, but I think some
of what I'm passing in from drm_display_mode is wrong, specifically

WREG32(PM3HTotal,  glint_shift_bpp(bpp, mode->htotal - 1));
WREG32(PM3HsEnd,   glint_shift_bpp(bpp, mode->hsync_end - mode->hdisplay));
WREG32(PM3HsStart, glint_shift_bpp(bpp, mode->hsync_start - mode->hdisplay));
WREG32(PM3HbEnd,   glint_shift_bpp(bpp, mode->htotal - mode->hdisplay));
WREG32(PM3HgEnd,   glint_shift_bpp(bpp, mode->htotal - mode->hdisplay));
WREG32(PM3ScreenStride, glint_shift_bpp(bpp, crtc->fb->width));
WREG32(PM3VTotal,  glint_shift_bpp(bpp, mode->vtotal - 1));
WREG32(PM3VsEnd,   glint_shift_bpp(bpp, mode->vsync_end - 1));
WREG32(PM3VsStart, glint_shift_bpp(bpp, mode->vsync_start - 1));
WREG32(PM3VbEnd,   glint_shift_bpp(bpp, mode->vtotal - mode->vdisplay));

I printed the values that xf86-video-glint passes through here, and of
course they don't match with anything my driver has. I imagine guess
it's because they're all resolution-dependent?

Can anyone give me some advice?

Thanks,
Matt

GPU lockup+blackout on 2.6.35 with r600...

[Daniel J Blueman]

After around 10-30 mins of typical usage (ie cairo rendering to
surfaces + compiz) on my Dell Studio 15 (model 1557), my R600 radeon
locks up, giving a blank screen.

The only information I have is a backtrace [1]. 'radeontool regs'
doesn't give anything - what information, /sys files etc would be
useful here, and would it be useful to log a freedesktop.org bug
report at this stage, assuming I haven't found a reliable reproducer?

OS is Ubuntu 10.10 development release, mesa 7.8.2, libdrm2 2.4.21.

Thanks,
  Daniel

--- [1]

radeon :02:00.0: GPU lockup CP stall for more than 1000msec
[ cut here ]
WARNING: at /home/kernel-ppa/COD/linux/drivers/gpu/drm/radeon/radeon_fence.c:235
radeon_fence_wait+0x2b7/0x320 [radeon]()
Hardware name: Studio 1557
GPU lockup (waiting for 0x8C35 last fence id 0x8C33)
Modules linked in: binfmt_misc parport_pc ppdev kvm_intel kvm
microcode snd_hda_codec_atihdmi joydev ipt_REJECT xt_limit xt_tcpudp
ipt_addrtype xt_state snd_hda_codec_idt ip6table_filter ip6_tables
snd_hda_intel nf_nat_irc nf_conntrack_irc snd_hda_codec nf_nat_ftp
nf_nat snd_hwdep nf_conntrack_ipv4 snd_seq_midi arc4 snd_pcm
snd_rawmidi nf_defrag_ipv4 radeon nf_conntrack_ftp nf_conntrack
iptable_filter snd_seq_midi_event snd_seq ip_tables ttm iwlagn video
snd_timer uvcvideo x_tables snd_seq_device output drm_kms_helper lp
dell_laptop iwlcore drm videodev dcdbas dell_wmi v4l1_compat mac80211
i7core_edac parport v4l2_compat_ioctl32 snd psmouse edac_core
i2c_algo_bit soundcore cfg80211 snd_page_alloc serio_raw sdhci_pci
sdhci ahci libahci led_class r8169 mii btrfs zlib_deflate crc32c
libcrc32c
Pid: 1624, comm: Xorg Tainted: G  D 2.6.35-020635-generic #020635
Call Trace:
? radeon_fence_wait+0x2b7/0x320 [radeon]
warn_slowpath_common+0x90/0xc0
warn_slowpath_fmt+0x6e/0x70
? schedule_timeout+0x15a/0x2e0
? r600_irq_set+0x27d/0xc00 [radeon]
? radeon_ring_commit+0xa3/0xb0 [radeon]
? r100_gpu_cp_is_lockup+0xc2/0xd0 [radeon]
? r600_gpu_is_lockup+0x1cb/0x220 [radeon]
radeon_fence_wait+0x2b7/0x320 [radeon]
? autoremove_wake_function+0x0/0x40
radeon_sync_obj_wait+0x11/0x20 [radeon]
ttm_bo_wait+0x102/0x1b0 [ttm]
ttm_bo_move_accel_cleanup+0x19e/0x230 [ttm]
radeon_move_blit+0x124/0x170 [radeon]
radeon_bo_move+0xda/0x1a0 [radeon]
ttm_bo_handle_move_mem+0xec/0x370 [ttm]
ttm_bo_evict+0x1cc/0x270 [ttm]
? drm_mm_split_at_start+0x1d/0x80 [drm]
ttm_mem_evict_first+0xed/0x180 [ttm]
? ttm_bo_man_get_node+0xd5/0xe0 [ttm]
ttm_bo_mem_force_space+0xab/0x110 [ttm]
ttm_bo_mem_space+0x305/0x370 [ttm]
ttm_bo_move_buffer+0xcf/0x140 [ttm]
? drm_mm_split_at_start+0x1d/0x80 [drm]
ttm_bo_validate+0xd5/0x100 [ttm]
ttm_bo_init+0x1f2/0x240 [ttm]
radeon_bo_create+0x121/0x240 [radeon]
? radeon_ttm_bo_destroy+0x0/0x80 [radeon]
radeon_gem_object_create+0x89/0x100 [radeon]
? drm_gem_handle_create+0x8b/0xa0 [drm]
radeon_gem_create_ioctl+0x58/0xe0 [radeon]
drm_ioctl+0x283/0x460 [drm]
? radeon_gem_create_ioctl+0x0/0xe0 [radeon]
? do_readv_writev+0x16b/0x1e0
vfs_ioctl+0x3a/0xc0
do_vfs_ioctl+0x6d/0x1f0
sys_ioctl+0x87/0xa0
? sys_writev+0x55/0xb0
system_call_fastpath+0x16/0x1b
---[ end trace c0bc12025fa8386c ]---
radeon :02:00.0: GPU softreset
radeon :02:00.0:   R_008010_GRBM_STATUS=0xA0003028
radeon :02:00.0:   R_008014_GRBM_STATUS2=0x0002
radeon :02:00.0:   R_000E50_SRBM_STATUS=0x20C0
radeon :02:00.0:   R_008020_GRBM_SOFT_RESET=0x7FEE
radeon :02:00.0: R_008020_GRBM_SOFT_RESET=0x0001
radeon :02:00.0:   R_008010_GRBM_STATUS=0x3028
radeon :02:00.0:   R_008014_GRBM_STATUS2=0x0002
radeon :02:00.0:   R_000E50_SRBM_STATUS=0x20C0
radeon :02:00.0: GPU reset succeed
Clocks initialized !
ring test succeeded in 1 usecs
ib test succeeded in 1 usecs
-- 
Daniel J Blueman

[git pull] drm tree

[Dave Airlie]

Hi Linus,

drm merge window pull,
highlights (or at least major movers)
core: BKL removal
  some whitespace misc cleanup
  non-pci drm layer support
  misc memory leak fixes
  vblank tracepoints

Intel: ongoing eDP support
   misc ickle patches all over
   pageflip and vblank tracepoints

Radeon: r600/700 tiling support
r300/r500 hyper-z support
r600 thermal sensors support
r600 kernel blit state emission minimisation
ioport accessors for BIOS scripts
underscan support for HDMI TVs
rs690 family HDMI audio support

Nouveau: improved nv10->nv40 suspend/resume support
 sil164 i2c chip support
 improved nv50 DP support + hotplug support
 EDID from ACPI support

Along with lots of fixes all over the place.

Dave.

The following changes since commit 9fe6206f400646a2322096b56c59891d530e8d51:

  Linux 2.6.35 (2010-08-01 15:11:14 -0700)

are available in the git repository at:
  ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git 
drm-core-next

Adam Jackson (7):
  drm/i915/pch: Cosmetic fix to FDI link training
  drm/i915/dp: Rename has_edp to is_pch_edp to reflect its real meaning
  drm/i915/dp: Correctly report eDP in the core connector type
  drm/i915: Initialize LVDS and eDP outputs before anything else
  drm/i915/pch: Set transcoder sync polarity for DP based on actual mode
  drm/i915/hdmi: Set sync polarity based on actual mode
  drm/i915/sdvo: Set sync polarity based on actual mode

Albert Damen (1):
  drm/nouveau: set encoder for lvds

Alberto Milone (1):
  drm/radeon: Add support for the ATIF ACPI method to the radeon driver

Alex Deucher (28):
  drm/kms: add crtc disable function
  drm/radeon/kms/atom: add crtc disable function
  drm/radeon/kms: minor driver cleanups
  drm/radeon/kms/atom: bump atom loop timeout from 1 sec to 5 secs
  drm/radeon/kms: add support for internal thermal sensors (v3)
  drm/radeon/kms: Add crtc tiling setup support for r6xx/r7xx
  drm/radeon/kms: Add crtc tiling setup support for evergreen
  drm/radeon/kms: add tiling support to the cs checker for r6xx/r7xx
  drm/radeon/kms: fix CS alignment checking for tiling (v2)
  drm/radeon/kms/r6xx+: add query for tile config (v2)
  drm/radeon/kms: add ioport register access
  drm/radeon/kms: remove rs4xx gart limit
  drm/radeon/kms/r7xx: add workaround for hw issue with HDP flush
  drm/radeon: add comments to r6xx/r7xx blit state
  drm/radeon: remove duplicate state emit in r6xx/r7xx blit
  drm/radeon: group r6xx/r7xx sequential blit state
  drm/radeon: r6xx/r7xx move vport clipping to a single packet
  drm/radeon: reorder r6xx/r7xx blit state emit to make more regs sequential
  drm/radeon: group r6xx/r7xx newly sequential blit state
  drm/radeon: remove viewport transform from r6xx/r7xx blit emit
  drm/radeon/kms: make sure rio_mem is valid before unmapping it
  drm/radeon/kms: make sure HPD is set to NONE on analog-only connectors
  drm/radeon/kms: handle the case of no active displays properly in the 
bandwidth code
  drm/radeon/kms/igp: sideport is AMD only
  drm/radeon/kms: fix calculation of h/v scaling factors
  drm/radeon/kms: enable underscan option for digital connectors
  drm/radeon: add new pci ids
  drm/radeon/kms: only expose underscan on avivo chips

Arnd Bergmann (1):
  drm: kill BKL from common code

Ben Skeggs (46):
  drm: disable encoder rather than dpms off in drm_crtc_prepare_encoders()
  drm/nouveau: place notifiers in system memory by default
  drm/nouveau: move LVDS detection back to connector detect() time
  drm/nouveau: use drm_mm in preference to custom code doing the same thing
  drm/nouveau: remove left-over !DRIVER_MODESET paths
  drm/nouveau: missed some braces
  drm/nv50: fix memory detection for cards with >=4GiB VRAM
  drm/nouveau: tidy connector/encoder creation a little
  drm/nouveau: downgrade severity of most init table parser errors
  drm/nv50: fix DP->DVI if output has been programmed for native DP 
previously
  drm/nv50: DCB quirk for Dell M6300
  drm/nv50: supply encoder disable() hook for SOR outputs
  drm/nv50: when debugging on, log which crtc we connect an encoder to
  drm/nv50: send evo "update" command after each disconnect
  drm/nv50: rewrite display irq handler
  drm/nouveau: move DP script invocation to nouveau_dp.c
  drm/nv50: set DP display power state during DPMS
  drm/nouveau: add scaler-only modes for eDP too
  drm/nouveau: remove dev_priv->init_state and friends
  drm/nv50: implement DAC disconnect fix missed in earlier commit
  drm/nouveau: add instmem flush() hook
  drm/nv50: move tlb flushing to a helper function
  drm/nouveau: remove ability to use external firmware
  drm/nouveau: allocate fixed amount of PRAMIN per 

[Bug 29400] R300G : Regression, Transparency in KDE effects is corrupted

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

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

--- Comment #8 from maxijac at free.fr 2010-08-05 11:35:57 PDT ---
Created an attachment (id=37598)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=37598)
with swrast thumbnail OK

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

[Bug 29400] R300G : Regression, Transparency in KDE effects is corrupted

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

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

--- Comment #7 from maxijac at free.fr 2010-08-05 11:35:03 PDT ---
OK I confirm the thumbnail bug is not in kde but in r300g
I'll post a screenshot with swrast_dri.so.

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

GPU lockup+blackout on 2.6.35 with r600...

[Alex Deucher]

On Thu, Aug 5, 2010 at 9:50 AM, Jerome Glisse  wrote:
> On 08/05/2010 06:52 AM, Daniel J Blueman wrote:
>>
>> After around 10-30 mins of typical usage (ie cairo rendering to
>> surfaces + compiz) on my Dell Studio 15 (model 1557), my R600 radeon
>> locks up, giving a blank screen.
>>
>> The only information I have is a backtrace [1]. 'radeontool regs'
>> doesn't give anything - what information, /sys files etc would be
>> useful here, and would it be useful to log a freedesktop.org bug
>> report at this stage, assuming I haven't found a reliable reproducer?
>>
>> OS is Ubuntu 10.10 development release, mesa 7.8.2, libdrm2 2.4.21.
>>
>> Thanks,
>> ? Daniel
>>
>> --- [1]
>>
>> radeon :02:00.0: GPU lockup CP stall for more than 1000msec
>> [ cut here ]
>> WARNING: at
>> /home/kernel-ppa/COD/linux/drivers/gpu/drm/radeon/radeon_fence.c:235
>> radeon_fence_wait+0x2b7/0x320 [radeon]()
>> Hardware name: Studio 1557
>> GPU lockup (waiting for 0x8C35 last fence id 0x8C33)
>> Modules linked in: binfmt_misc parport_pc ppdev kvm_intel kvm
>> microcode snd_hda_codec_atihdmi joydev ipt_REJECT xt_limit xt_tcpudp
>> ipt_addrtype xt_state snd_hda_codec_idt ip6table_filter ip6_tables
>> snd_hda_intel nf_nat_irc nf_conntrack_irc snd_hda_codec nf_nat_ftp
>> nf_nat snd_hwdep nf_conntrack_ipv4 snd_seq_midi arc4 snd_pcm
>> snd_rawmidi nf_defrag_ipv4 radeon nf_conntrack_ftp nf_conntrack
>> iptable_filter snd_seq_midi_event snd_seq ip_tables ttm iwlagn video
>> snd_timer uvcvideo x_tables snd_seq_device output drm_kms_helper lp
>> dell_laptop iwlcore drm videodev dcdbas dell_wmi v4l1_compat mac80211
>> i7core_edac parport v4l2_compat_ioctl32 snd psmouse edac_core
>> i2c_algo_bit soundcore cfg80211 snd_page_alloc serio_raw sdhci_pci
>> sdhci ahci libahci led_class r8169 mii btrfs zlib_deflate crc32c
>> libcrc32c
>> Pid: 1624, comm: Xorg Tainted: G ? ? ?D ? ? 2.6.35-020635-generic #020635
>> Call Trace:
>> ? radeon_fence_wait+0x2b7/0x320 [radeon]
>> warn_slowpath_common+0x90/0xc0
>> warn_slowpath_fmt+0x6e/0x70
>> ? schedule_timeout+0x15a/0x2e0
>> ? r600_irq_set+0x27d/0xc00 [radeon]
>> ? radeon_ring_commit+0xa3/0xb0 [radeon]
>> ? r100_gpu_cp_is_lockup+0xc2/0xd0 [radeon]
>> ? r600_gpu_is_lockup+0x1cb/0x220 [radeon]
>> radeon_fence_wait+0x2b7/0x320 [radeon]
>> ? autoremove_wake_function+0x0/0x40
>> radeon_sync_obj_wait+0x11/0x20 [radeon]
>> ttm_bo_wait+0x102/0x1b0 [ttm]
>> ttm_bo_move_accel_cleanup+0x19e/0x230 [ttm]
>> radeon_move_blit+0x124/0x170 [radeon]
>> radeon_bo_move+0xda/0x1a0 [radeon]
>> ttm_bo_handle_move_mem+0xec/0x370 [ttm]
>> ttm_bo_evict+0x1cc/0x270 [ttm]
>> ? drm_mm_split_at_start+0x1d/0x80 [drm]
>> ttm_mem_evict_first+0xed/0x180 [ttm]
>> ? ttm_bo_man_get_node+0xd5/0xe0 [ttm]
>> ttm_bo_mem_force_space+0xab/0x110 [ttm]
>> ttm_bo_mem_space+0x305/0x370 [ttm]
>> ttm_bo_move_buffer+0xcf/0x140 [ttm]
>> ? drm_mm_split_at_start+0x1d/0x80 [drm]
>> ttm_bo_validate+0xd5/0x100 [ttm]
>> ttm_bo_init+0x1f2/0x240 [ttm]
>> radeon_bo_create+0x121/0x240 [radeon]
>> ? radeon_ttm_bo_destroy+0x0/0x80 [radeon]
>> radeon_gem_object_create+0x89/0x100 [radeon]
>> ? drm_gem_handle_create+0x8b/0xa0 [drm]
>> radeon_gem_create_ioctl+0x58/0xe0 [radeon]
>> drm_ioctl+0x283/0x460 [drm]
>> ? radeon_gem_create_ioctl+0x0/0xe0 [radeon]
>> ? do_readv_writev+0x16b/0x1e0
>> vfs_ioctl+0x3a/0xc0
>> do_vfs_ioctl+0x6d/0x1f0
>> sys_ioctl+0x87/0xa0
>> ? sys_writev+0x55/0xb0
>> system_call_fastpath+0x16/0x1b
>> ---[ end trace c0bc12025fa8386c ]---
>> radeon :02:00.0: GPU softreset
>> radeon :02:00.0: ? R_008010_GRBM_STATUS=0xA0003028
>> radeon :02:00.0: ? R_008014_GRBM_STATUS2=0x0002
>> radeon :02:00.0: ? R_000E50_SRBM_STATUS=0x20C0
>> radeon :02:00.0: ? R_008020_GRBM_SOFT_RESET=0x7FEE
>> radeon :02:00.0: R_008020_GRBM_SOFT_RESET=0x0001
>> radeon :02:00.0: ? R_008010_GRBM_STATUS=0x3028
>> radeon :02:00.0: ? R_008014_GRBM_STATUS2=0x0002
>> radeon :02:00.0: ? R_000E50_SRBM_STATUS=0x20C0
>> radeon :02:00.0: GPU reset succeed
>> Clocks initialized !
>> ring test succeeded in 1 usecs
>> ib test succeeded in 1 usecs
>
>
> SO it keep reseting ? According to log there is a GPU lockup but then
> a successfull GPU reset so GPU should resume fine (that's what log says)
> Best is to open a bug and attach full dmesg + lspci -vv and context
> in which the lockup happen
>

Perhaps the lockup timeout is too short or interrupts are being
delivered late or something?  There's a fdo or kernel bugzilla entry
where removing the lockup timeout fixed the issue.  Does something
like this:

--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -237,9 +237,11 @@ retry:
 * as signaled for now
 */
rdev->gpu_lockup = true;
+#if 0
r = radeon_gpu_reset(rdev);
if (r)
return r;
+#endif

[PATCH RESEND block#for-2.6.36] block_dev: always serialize exclusive open attempts

[Jens Axboe]

On 2010-08-05 11:17, Markus Trippelsdorf wrote:
> On Thu, Aug 05, 2010 at 11:02:43AM +0200, Jens Axboe wrote:
>> On 2010-08-04 17:59, Tejun Heo wrote:
>>> bd_prepare_to_claim() incorrectly allowed multiple attempts for
>>> exclusive open to progress in parallel if the attempting holders are
>>> identical.  This triggered BUG_ON() as reported in the following bug.
>>>
>>>   https://bugzilla.kernel.org/show_bug.cgi?id=16393
>>>
>>> __bd_abort_claiming() is used to finish claiming blocks and doesn't
>>> work if multiple openers are inside a claiming block.  Allowing
>>> multiple parallel open attempts to continue doesn't gain anything as
>>> those are serialized down in the call chain anyway.  Fix it by always
>>> allowing only single open attempt in a claiming block.
>>>
>>> This problem can easily be reproduced by adding a delay after
>>> bd_prepare_to_claim() and attempting to mount two partitions of a
>>> disk.
>>>
>>> stable: only applicable to v2.6.35
>>>
>>> Signed-off-by: Tejun Heo 
>>> Reported-by: Markus Trippelsdorf 
>>> Cc: stable at kernel.org
>>
>> Thanks Tejun, applied.
> 
> It's already in mainline:
> e75aa85892b2ee78c79edac720868cbef16e62eb

Irk, had not noticed yet, my for-2.6.36 branch isn't fully merged
up yet. Thanks for the heads-up.

-- 
Jens Axboe


Confidentiality Notice: This e-mail message, its contents and any attachments 
to it are confidential to the intended recipient, and may contain information 
that is privileged and/or exempt from disclosure under applicable law. If you 
are not the intended recipient, please immediately notify the sender and 
destroy the original e-mail message and any attachments (and any copies that 
may have been made) from your system or otherwise. Any unauthorized use, 
copying, disclosure or distribution of this information is strictly prohibited.

[PATCH RESEND block#for-2.6.36] block_dev: always serialize exclusive open attempts

[Markus Trippelsdorf]

On Thu, Aug 05, 2010 at 11:02:43AM +0200, Jens Axboe wrote:
> On 2010-08-04 17:59, Tejun Heo wrote:
> > bd_prepare_to_claim() incorrectly allowed multiple attempts for
> > exclusive open to progress in parallel if the attempting holders are
> > identical.  This triggered BUG_ON() as reported in the following bug.
> > 
> >   https://bugzilla.kernel.org/show_bug.cgi?id=16393
> > 
> > __bd_abort_claiming() is used to finish claiming blocks and doesn't
> > work if multiple openers are inside a claiming block.  Allowing
> > multiple parallel open attempts to continue doesn't gain anything as
> > those are serialized down in the call chain anyway.  Fix it by always
> > allowing only single open attempt in a claiming block.
> > 
> > This problem can easily be reproduced by adding a delay after
> > bd_prepare_to_claim() and attempting to mount two partitions of a
> > disk.
> > 
> > stable: only applicable to v2.6.35
> > 
> > Signed-off-by: Tejun Heo 
> > Reported-by: Markus Trippelsdorf 
> > Cc: stable at kernel.org
> 
> Thanks Tejun, applied.

It's already in mainline:
e75aa85892b2ee78c79edac720868cbef16e62eb

-- 
?A man who doesn't know he is in prison can never escape.?
William S. Burroughs

[PATCH RESEND block#for-2.6.36] block_dev: always serialize exclusive open attempts

[Jens Axboe]

On 2010-08-04 17:59, Tejun Heo wrote:
> bd_prepare_to_claim() incorrectly allowed multiple attempts for
> exclusive open to progress in parallel if the attempting holders are
> identical.  This triggered BUG_ON() as reported in the following bug.
> 
>   https://bugzilla.kernel.org/show_bug.cgi?id=16393
> 
> __bd_abort_claiming() is used to finish claiming blocks and doesn't
> work if multiple openers are inside a claiming block.  Allowing
> multiple parallel open attempts to continue doesn't gain anything as
> those are serialized down in the call chain anyway.  Fix it by always
> allowing only single open attempt in a claiming block.
> 
> This problem can easily be reproduced by adding a delay after
> bd_prepare_to_claim() and attempting to mount two partitions of a
> disk.
> 
> stable: only applicable to v2.6.35
> 
> Signed-off-by: Tejun Heo 
> Reported-by: Markus Trippelsdorf 
> Cc: stable at kernel.org

Thanks Tejun, applied.

-- 
Jens Axboe


Confidentiality Notice: This e-mail message, its contents and any attachments 
to it are confidential to the intended recipient, and may contain information 
that is privileged and/or exempt from disclosure under applicable law. If you 
are not the intended recipient, please immediately notify the sender and 
destroy the original e-mail message and any attachments (and any copies that 
may have been made) from your system or otherwise. Any unauthorized use, 
copying, disclosure or distribution of this information is strictly prohibited.

[Bug 29226] on r600 3d applications are rendered in too bright colors

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

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

--- Comment #7 from Michal Suchanek  2010-08-05 
10:12:16 PDT ---
Created an attachment (id=37597)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=37597)
shadowtex on intel

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

[Bug 29226] on r600 3d applications are rendered in too bright colors

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

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

--- Comment #6 from Michal Suchanek  2010-08-05 
10:11:42 PDT ---
Created an attachment (id=37596)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=37596)
shadowtex on r600

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

[Bug 29226] on r600 3d applications are rendered in too bright colors

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

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

--- Comment #5 from Michal Suchanek  2010-08-05 
10:11:07 PDT ---
As suggested by people on irc I found a demo that shows a similar issue.

The demo is shadowtex from current mesa git.

The green ball in the demo using the fixed function shader (default) on Intel
renders only slightly edgy ball but a ball with a flat spot on r600.

The demo currently crashes on r600g. 

Note that the demo is designed to showcase features that don't work at all on
Intel and a simpler demo with the shader only should be possible. Note that due
to the features present on r600 you may need to cycle through the different
composition modes with the 'o' key until most of the surface is shown in the
brighter color and the flat area is visible.

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

[Bug 29400] R300G : Regression, Transparency in KDE effects is corrupted

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

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

--- Comment #6 from maxijac at free.fr 2010-08-05 10:00:25 PDT ---
Created an attachment (id=37591)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=37591)
transparency ok

thumbnail at the center is missing, I don't know why. I'll have to find out if
it's related to KDE or r300g

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

[Bug 29400] R300G : Regression, Transparency in KDE effects is corrupted

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

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

--- Comment #5 from maxijac at free.fr 2010-08-05 09:57:56 PDT ---
Hi,

Thanks for your advices on bisecting, I did not even think of symlinking >.>
Anyways, it looks like there is some kind of bug, sometimes KDE says it can
enable effects and after when reverting to a working dri driver it never wants
to enable it again... I'll have to sort this out...

Anyways, the transparency problem is solved (on a kernel update ?)
And the other issue I reported, (the lag in the fade effect) also seems to be
gone... I don't understand how...

I' attach a screenshot of how it is now (partially fixed ? transparency is OK
but why don't I have the thumbnail of my window ?)

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

GPU lockup+blackout on 2.6.35 with r600...

[Jerome Glisse]

On 08/05/2010 06:52 AM, Daniel J Blueman wrote:
> After around 10-30 mins of typical usage (ie cairo rendering to
> surfaces + compiz) on my Dell Studio 15 (model 1557), my R600 radeon
> locks up, giving a blank screen.
>
> The only information I have is a backtrace [1]. 'radeontool regs'
> doesn't give anything - what information, /sys files etc would be
> useful here, and would it be useful to log a freedesktop.org bug
> report at this stage, assuming I haven't found a reliable reproducer?
>
> OS is Ubuntu 10.10 development release, mesa 7.8.2, libdrm2 2.4.21.
>
> Thanks,
>Daniel
>
> --- [1]
>
> radeon :02:00.0: GPU lockup CP stall for more than 1000msec
> [ cut here ]
> WARNING: at 
> /home/kernel-ppa/COD/linux/drivers/gpu/drm/radeon/radeon_fence.c:235
> radeon_fence_wait+0x2b7/0x320 [radeon]()
> Hardware name: Studio 1557
> GPU lockup (waiting for 0x8C35 last fence id 0x8C33)
> Modules linked in: binfmt_misc parport_pc ppdev kvm_intel kvm
> microcode snd_hda_codec_atihdmi joydev ipt_REJECT xt_limit xt_tcpudp
> ipt_addrtype xt_state snd_hda_codec_idt ip6table_filter ip6_tables
> snd_hda_intel nf_nat_irc nf_conntrack_irc snd_hda_codec nf_nat_ftp
> nf_nat snd_hwdep nf_conntrack_ipv4 snd_seq_midi arc4 snd_pcm
> snd_rawmidi nf_defrag_ipv4 radeon nf_conntrack_ftp nf_conntrack
> iptable_filter snd_seq_midi_event snd_seq ip_tables ttm iwlagn video
> snd_timer uvcvideo x_tables snd_seq_device output drm_kms_helper lp
> dell_laptop iwlcore drm videodev dcdbas dell_wmi v4l1_compat mac80211
> i7core_edac parport v4l2_compat_ioctl32 snd psmouse edac_core
> i2c_algo_bit soundcore cfg80211 snd_page_alloc serio_raw sdhci_pci
> sdhci ahci libahci led_class r8169 mii btrfs zlib_deflate crc32c
> libcrc32c
> Pid: 1624, comm: Xorg Tainted: G  D 2.6.35-020635-generic #020635
> Call Trace:
> ? radeon_fence_wait+0x2b7/0x320 [radeon]
> warn_slowpath_common+0x90/0xc0
> warn_slowpath_fmt+0x6e/0x70
> ? schedule_timeout+0x15a/0x2e0
> ? r600_irq_set+0x27d/0xc00 [radeon]
> ? radeon_ring_commit+0xa3/0xb0 [radeon]
> ? r100_gpu_cp_is_lockup+0xc2/0xd0 [radeon]
> ? r600_gpu_is_lockup+0x1cb/0x220 [radeon]
> radeon_fence_wait+0x2b7/0x320 [radeon]
> ? autoremove_wake_function+0x0/0x40
> radeon_sync_obj_wait+0x11/0x20 [radeon]
> ttm_bo_wait+0x102/0x1b0 [ttm]
> ttm_bo_move_accel_cleanup+0x19e/0x230 [ttm]
> radeon_move_blit+0x124/0x170 [radeon]
> radeon_bo_move+0xda/0x1a0 [radeon]
> ttm_bo_handle_move_mem+0xec/0x370 [ttm]
> ttm_bo_evict+0x1cc/0x270 [ttm]
> ? drm_mm_split_at_start+0x1d/0x80 [drm]
> ttm_mem_evict_first+0xed/0x180 [ttm]
> ? ttm_bo_man_get_node+0xd5/0xe0 [ttm]
> ttm_bo_mem_force_space+0xab/0x110 [ttm]
> ttm_bo_mem_space+0x305/0x370 [ttm]
> ttm_bo_move_buffer+0xcf/0x140 [ttm]
> ? drm_mm_split_at_start+0x1d/0x80 [drm]
> ttm_bo_validate+0xd5/0x100 [ttm]
> ttm_bo_init+0x1f2/0x240 [ttm]
> radeon_bo_create+0x121/0x240 [radeon]
> ? radeon_ttm_bo_destroy+0x0/0x80 [radeon]
> radeon_gem_object_create+0x89/0x100 [radeon]
> ? drm_gem_handle_create+0x8b/0xa0 [drm]
> radeon_gem_create_ioctl+0x58/0xe0 [radeon]
> drm_ioctl+0x283/0x460 [drm]
> ? radeon_gem_create_ioctl+0x0/0xe0 [radeon]
> ? do_readv_writev+0x16b/0x1e0
> vfs_ioctl+0x3a/0xc0
> do_vfs_ioctl+0x6d/0x1f0
> sys_ioctl+0x87/0xa0
> ? sys_writev+0x55/0xb0
> system_call_fastpath+0x16/0x1b
> ---[ end trace c0bc12025fa8386c ]---
> radeon :02:00.0: GPU softreset
> radeon :02:00.0:   R_008010_GRBM_STATUS=0xA0003028
> radeon :02:00.0:   R_008014_GRBM_STATUS2=0x0002
> radeon :02:00.0:   R_000E50_SRBM_STATUS=0x20C0
> radeon :02:00.0:   R_008020_GRBM_SOFT_RESET=0x7FEE
> radeon :02:00.0: R_008020_GRBM_SOFT_RESET=0x0001
> radeon :02:00.0:   R_008010_GRBM_STATUS=0x3028
> radeon :02:00.0:   R_008014_GRBM_STATUS2=0x0002
> radeon :02:00.0:   R_000E50_SRBM_STATUS=0x20C0
> radeon :02:00.0: GPU reset succeed
> Clocks initialized !
> ring test succeeded in 1 usecs
> ib test succeeded in 1 usecs


SO it keep reseting ? According to log there is a GPU lockup but then
a successfull GPU reset so GPU should resume fine (that's what log says)
Best is to open a bug and attach full dmesg + lspci -vv and context
in which the lockup happen

Cheers,
Jerome

[PATCH] drm: Use ENOENT consistently for the error return for an unmatched handle.

[Chris Wilson]

On Thu, 05 Aug 2010 08:46:31 +1000, Dave Airlie  wrote:
> Have you verified no userspace relies on this return value? since this
> technically an ABI change.
> 
> >From what I can see probably only libdrm tests care.

I haven't found any other instances of code checking return values, more
often the error code is simply reported. Even those tests show that we can
expect EINVAL, ENOENT or EBADF for an invalid buffer handle.

It's the reporting that I want clarified as the "invalid fd" is misleading
for bug reporters. (Doubly so when this gets confused with a genuine
EBADF!)
-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH] drm: Use ENOENT consistently for the error return for an unmatched handle.

[Dave Airlie]

On Wed, 2010-08-04 at 14:19 +0100, Chris Wilson wrote:
> This is consistent with trying to access a filename that not exist
> within a directory which is a good analogy here. The main reason for the
> change is that it is easy to confuse the error code of EBADF as an
> performing an ioctl on an invalid file descriptor (rather than an
> unknown object).

Have you verified no userspace relies on this return value? since this
technically an ABI change.

>From what I can see probably only libdrm tests care.

Dave.

[Bug 29226] on r600 3d applications are rendered in too bright colors

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

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

--- Comment #4 from Michal Suchanek  2010-08-05 
06:52:13 PDT ---
Created an attachment (id=37585)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=37585)
rendered on r600g

Apart from other glitches the color issue also appears on r600g

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

[patch v2] nouveau: unwind on load errors

[Francisco Jerez]

Marcin Slusarz  writes:

> On Fri, Jul 30, 2010 at 05:04:32PM +0200, Dan Carpenter wrote:
>> nuveau_load() just returned directly if there was an error instead of
>>
>   ^^ typo
>
>> releasing resources. 
>> 
>> 
>> Signed-off-by: Dan Carpenter 
>> ---
>> V2: updated to the nouveau git tree.
>
> Thanks.
> Reviewed-by: Marcin Slusarz 

Thanks, pushed to the nouveau kernel tree.

>
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c 
>> b/drivers/gpu/drm/nouveau/nouveau_state.c
>> index ee3729e..cf16bfb 100644
>> --- a/drivers/gpu/drm/nouveau/nouveau_state.c
>> +++ b/drivers/gpu/drm/nouveau/nouveau_state.c
>> @@ -739,8 +739,10 @@ int nouveau_load(struct drm_device *dev, unsigned long 
>> flags)
>>  int ret;
>>  
>>  dev_priv = kzalloc(sizeof(*dev_priv), GFP_KERNEL);
>> -if (!dev_priv)
>> -return -ENOMEM;
>> +if (!dev_priv) {
>> +ret = -ENOMEM;
>> +goto err_out;
>> +}
>>  dev->dev_private = dev_priv;
>>  dev_priv->dev = dev;
>>  
>> @@ -750,8 +752,10 @@ int nouveau_load(struct drm_device *dev, unsigned long 
>> flags)
>>   dev->pci_vendor, dev->pci_device, dev->pdev->class);
>>  
>>  dev_priv->wq = create_workqueue("nouveau");
>> -if (!dev_priv->wq)
>> -return -EINVAL;
>> +if (!dev_priv->wq) {
>> +ret = -EINVAL;
>> +goto err_priv;
>> +}
>>  
>>  /* resource 0 is mmio regs */
>>  /* resource 1 is linear FB */
>> @@ -764,7 +768,8 @@ int nouveau_load(struct drm_device *dev, unsigned long 
>> flags)
>>  if (!dev_priv->mmio) {
>>  NV_ERROR(dev, "Unable to initialize the mmio mapping. "
>>   "Please report your setup to " DRIVER_EMAIL "\n");
>> -return -EINVAL;
>> +ret = -EINVAL;
>> +goto err_wq;
>>  }
>>  NV_DEBUG(dev, "regs mapped ok at 0x%llx\n",
>>  (unsigned long long)mmio_start_offs);
>> @@ -812,7 +817,8 @@ int nouveau_load(struct drm_device *dev, unsigned long 
>> flags)
>>  break;
>>  default:
>>  NV_INFO(dev, "Unsupported chipset 0x%08x\n", reg0);
>> -return -EINVAL;
>> +ret = -EINVAL;
>> +goto err_mmio;
>>  }
>>  
>>  NV_INFO(dev, "Detected an NV%2x generation card (0x%08x)\n",
>> @@ -820,7 +826,7 @@ int nouveau_load(struct drm_device *dev, unsigned long 
>> flags)
>>  
>>  ret = nouveau_remove_conflicting_drivers(dev);
>>  if (ret)
>> -return ret;
>> +goto err_mmio;
>>  
>>  /* Map PRAMIN BAR, or on older cards, the aperture withing BAR0 */
>>  if (dev_priv->card_type >= NV_40) {
>> @@ -834,7 +840,8 @@ int nouveau_load(struct drm_device *dev, unsigned long 
>> flags)
>>  dev_priv->ramin_size);
>>  if (!dev_priv->ramin) {
>>  NV_ERROR(dev, "Failed to PRAMIN BAR");
>> -return -ENOMEM;
>> +ret = -ENOMEM;
>> +goto err_mmio;
>>  }
>>  } else {
>>  dev_priv->ramin_size = 1 * 1024 * 1024;
>> @@ -842,7 +849,8 @@ int nouveau_load(struct drm_device *dev, unsigned long 
>> flags)
>>dev_priv->ramin_size);
>>  if (!dev_priv->ramin) {
>>  NV_ERROR(dev, "Failed to map BAR0 PRAMIN.\n");
>> -return -ENOMEM;
>> +ret = -ENOMEM;
>> +goto err_mmio;
>>  }
>>  }
>>  
>> @@ -857,9 +865,21 @@ int nouveau_load(struct drm_device *dev, unsigned long 
>> flags)
>>  /* For kernel modesetting, init card now and bring up fbcon */
>>  ret = nouveau_card_init(dev);
>>  if (ret)
>> -return ret;
>> +goto err_ramin;
>>  
>>  return 0;
>> +
>> +err_ramin:
>> +iounmap(dev_priv->ramin);
>> +err_mmio:
>> +iounmap(dev_priv->mmio);
>> +err_wq:
>> +destroy_workqueue(dev_priv->wq);
>> +err_priv:
>> +kfree(dev_priv);
>> +dev->dev_private = NULL;
>> +err_out:
>> +return ret;
>>  }
>>  
>>  void nouveau_lastclose(struct drm_device *dev)
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 229 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20100805/56890b91/attachment.pgp>

Re: [PATCH] drm: Use ENOENT consistently for the error return for an unmatched handle.

[Chris Wilson]

On Thu, 05 Aug 2010 08:46:31 +1000, Dave Airlie airl...@redhat.com wrote:
 Have you verified no userspace relies on this return value? since this
 technically an ABI change.
 
 From what I can see probably only libdrm tests care.

I haven't found any other instances of code checking return values, more
often the error code is simply reported. Even those tests show that we can
expect EINVAL, ENOENT or EBADF for an invalid buffer handle.

It's the reporting that I want clarified as the invalid fd is misleading
for bug reporters. (Doubly so when this gets confused with a genuine
EBADF!)
-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[git pull] drm tree

[Dave Airlie]

Hi Linus,

drm merge window pull,
highlights (or at least major movers)
core: BKL removal
  some whitespace misc cleanup
  non-pci drm layer support
  misc memory leak fixes
  vblank tracepoints

Intel: ongoing eDP support
   misc ickle patches all over
   pageflip and vblank tracepoints
   
Radeon: r600/700 tiling support
r300/r500 hyper-z support
r600 thermal sensors support
r600 kernel blit state emission minimisation
ioport accessors for BIOS scripts
underscan support for HDMI TVs
rs690 family HDMI audio support

Nouveau: improved nv10-nv40 suspend/resume support
 sil164 i2c chip support
 improved nv50 DP support + hotplug support
 EDID from ACPI support

Along with lots of fixes all over the place.

Dave.

The following changes since commit 9fe6206f400646a2322096b56c59891d530e8d51:

  Linux 2.6.35 (2010-08-01 15:11:14 -0700)

are available in the git repository at:
  ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git 
drm-core-next

Adam Jackson (7):
  drm/i915/pch: Cosmetic fix to FDI link training
  drm/i915/dp: Rename has_edp to is_pch_edp to reflect its real meaning
  drm/i915/dp: Correctly report eDP in the core connector type
  drm/i915: Initialize LVDS and eDP outputs before anything else
  drm/i915/pch: Set transcoder sync polarity for DP based on actual mode
  drm/i915/hdmi: Set sync polarity based on actual mode
  drm/i915/sdvo: Set sync polarity based on actual mode

Albert Damen (1):
  drm/nouveau: set encoder for lvds

Alberto Milone (1):
  drm/radeon: Add support for the ATIF ACPI method to the radeon driver

Alex Deucher (28):
  drm/kms: add crtc disable function
  drm/radeon/kms/atom: add crtc disable function
  drm/radeon/kms: minor driver cleanups
  drm/radeon/kms/atom: bump atom loop timeout from 1 sec to 5 secs
  drm/radeon/kms: add support for internal thermal sensors (v3)
  drm/radeon/kms: Add crtc tiling setup support for r6xx/r7xx
  drm/radeon/kms: Add crtc tiling setup support for evergreen
  drm/radeon/kms: add tiling support to the cs checker for r6xx/r7xx
  drm/radeon/kms: fix CS alignment checking for tiling (v2)
  drm/radeon/kms/r6xx+: add query for tile config (v2)
  drm/radeon/kms: add ioport register access
  drm/radeon/kms: remove rs4xx gart limit
  drm/radeon/kms/r7xx: add workaround for hw issue with HDP flush
  drm/radeon: add comments to r6xx/r7xx blit state
  drm/radeon: remove duplicate state emit in r6xx/r7xx blit
  drm/radeon: group r6xx/r7xx sequential blit state
  drm/radeon: r6xx/r7xx move vport clipping to a single packet
  drm/radeon: reorder r6xx/r7xx blit state emit to make more regs sequential
  drm/radeon: group r6xx/r7xx newly sequential blit state
  drm/radeon: remove viewport transform from r6xx/r7xx blit emit
  drm/radeon/kms: make sure rio_mem is valid before unmapping it
  drm/radeon/kms: make sure HPD is set to NONE on analog-only connectors
  drm/radeon/kms: handle the case of no active displays properly in the 
bandwidth code
  drm/radeon/kms/igp: sideport is AMD only
  drm/radeon/kms: fix calculation of h/v scaling factors
  drm/radeon/kms: enable underscan option for digital connectors
  drm/radeon: add new pci ids
  drm/radeon/kms: only expose underscan on avivo chips

Arnd Bergmann (1):
  drm: kill BKL from common code

Ben Skeggs (46):
  drm: disable encoder rather than dpms off in drm_crtc_prepare_encoders()
  drm/nouveau: place notifiers in system memory by default
  drm/nouveau: move LVDS detection back to connector detect() time
  drm/nouveau: use drm_mm in preference to custom code doing the same thing
  drm/nouveau: remove left-over !DRIVER_MODESET paths
  drm/nouveau: missed some braces
  drm/nv50: fix memory detection for cards with =4GiB VRAM
  drm/nouveau: tidy connector/encoder creation a little
  drm/nouveau: downgrade severity of most init table parser errors
  drm/nv50: fix DP-DVI if output has been programmed for native DP 
previously
  drm/nv50: DCB quirk for Dell M6300
  drm/nv50: supply encoder disable() hook for SOR outputs
  drm/nv50: when debugging on, log which crtc we connect an encoder to
  drm/nv50: send evo update command after each disconnect
  drm/nv50: rewrite display irq handler
  drm/nouveau: move DP script invocation to nouveau_dp.c
  drm/nv50: set DP display power state during DPMS
  drm/nouveau: add scaler-only modes for eDP too
  drm/nouveau: remove dev_priv-init_state and friends
  drm/nv50: implement DAC disconnect fix missed in earlier commit
  drm/nouveau: add instmem flush() hook
  drm/nv50: move tlb flushing to a helper function
  drm/nouveau: remove ability to use external firmware
  drm/nouveau: allocate fixed amount of PRAMIN per 

GPU lockup+blackout on 2.6.35 with r600...

[Daniel J Blueman]

After around 10-30 mins of typical usage (ie cairo rendering to
surfaces + compiz) on my Dell Studio 15 (model 1557), my R600 radeon
locks up, giving a blank screen.

The only information I have is a backtrace [1]. 'radeontool regs'
doesn't give anything - what information, /sys files etc would be
useful here, and would it be useful to log a freedesktop.org bug
report at this stage, assuming I haven't found a reliable reproducer?

OS is Ubuntu 10.10 development release, mesa 7.8.2, libdrm2 2.4.21.

Thanks,
  Daniel

--- [1]

radeon :02:00.0: GPU lockup CP stall for more than 1000msec
[ cut here ]
WARNING: at /home/kernel-ppa/COD/linux/drivers/gpu/drm/radeon/radeon_fence.c:235
radeon_fence_wait+0x2b7/0x320 [radeon]()
Hardware name: Studio 1557
GPU lockup (waiting for 0x8C35 last fence id 0x8C33)
Modules linked in: binfmt_misc parport_pc ppdev kvm_intel kvm
microcode snd_hda_codec_atihdmi joydev ipt_REJECT xt_limit xt_tcpudp
ipt_addrtype xt_state snd_hda_codec_idt ip6table_filter ip6_tables
snd_hda_intel nf_nat_irc nf_conntrack_irc snd_hda_codec nf_nat_ftp
nf_nat snd_hwdep nf_conntrack_ipv4 snd_seq_midi arc4 snd_pcm
snd_rawmidi nf_defrag_ipv4 radeon nf_conntrack_ftp nf_conntrack
iptable_filter snd_seq_midi_event snd_seq ip_tables ttm iwlagn video
snd_timer uvcvideo x_tables snd_seq_device output drm_kms_helper lp
dell_laptop iwlcore drm videodev dcdbas dell_wmi v4l1_compat mac80211
i7core_edac parport v4l2_compat_ioctl32 snd psmouse edac_core
i2c_algo_bit soundcore cfg80211 snd_page_alloc serio_raw sdhci_pci
sdhci ahci libahci led_class r8169 mii btrfs zlib_deflate crc32c
libcrc32c
Pid: 1624, comm: Xorg Tainted: G  D 2.6.35-020635-generic #020635
Call Trace:
? radeon_fence_wait+0x2b7/0x320 [radeon]
warn_slowpath_common+0x90/0xc0
warn_slowpath_fmt+0x6e/0x70
? schedule_timeout+0x15a/0x2e0
? r600_irq_set+0x27d/0xc00 [radeon]
? radeon_ring_commit+0xa3/0xb0 [radeon]
? r100_gpu_cp_is_lockup+0xc2/0xd0 [radeon]
? r600_gpu_is_lockup+0x1cb/0x220 [radeon]
radeon_fence_wait+0x2b7/0x320 [radeon]
? autoremove_wake_function+0x0/0x40
radeon_sync_obj_wait+0x11/0x20 [radeon]
ttm_bo_wait+0x102/0x1b0 [ttm]
ttm_bo_move_accel_cleanup+0x19e/0x230 [ttm]
radeon_move_blit+0x124/0x170 [radeon]
radeon_bo_move+0xda/0x1a0 [radeon]
ttm_bo_handle_move_mem+0xec/0x370 [ttm]
ttm_bo_evict+0x1cc/0x270 [ttm]
? drm_mm_split_at_start+0x1d/0x80 [drm]
ttm_mem_evict_first+0xed/0x180 [ttm]
? ttm_bo_man_get_node+0xd5/0xe0 [ttm]
ttm_bo_mem_force_space+0xab/0x110 [ttm]
ttm_bo_mem_space+0x305/0x370 [ttm]
ttm_bo_move_buffer+0xcf/0x140 [ttm]
? drm_mm_split_at_start+0x1d/0x80 [drm]
ttm_bo_validate+0xd5/0x100 [ttm]
ttm_bo_init+0x1f2/0x240 [ttm]
radeon_bo_create+0x121/0x240 [radeon]
? radeon_ttm_bo_destroy+0x0/0x80 [radeon]
radeon_gem_object_create+0x89/0x100 [radeon]
? drm_gem_handle_create+0x8b/0xa0 [drm]
radeon_gem_create_ioctl+0x58/0xe0 [radeon]
drm_ioctl+0x283/0x460 [drm]
? radeon_gem_create_ioctl+0x0/0xe0 [radeon]
? do_readv_writev+0x16b/0x1e0
vfs_ioctl+0x3a/0xc0
do_vfs_ioctl+0x6d/0x1f0
sys_ioctl+0x87/0xa0
? sys_writev+0x55/0xb0
system_call_fastpath+0x16/0x1b
---[ end trace c0bc12025fa8386c ]---
radeon :02:00.0: GPU softreset
radeon :02:00.0:   R_008010_GRBM_STATUS=0xA0003028
radeon :02:00.0:   R_008014_GRBM_STATUS2=0x0002
radeon :02:00.0:   R_000E50_SRBM_STATUS=0x20C0
radeon :02:00.0:   R_008020_GRBM_SOFT_RESET=0x7FEE
radeon :02:00.0: R_008020_GRBM_SOFT_RESET=0x0001
radeon :02:00.0:   R_008010_GRBM_STATUS=0x3028
radeon :02:00.0:   R_008014_GRBM_STATUS2=0x0002
radeon :02:00.0:   R_000E50_SRBM_STATUS=0x20C0
radeon :02:00.0: GPU reset succeed
Clocks initialized !
ring test succeeded in 1 usecs
ib test succeeded in 1 usecs
-- 
Daniel J Blueman
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/ttm: restructure to allow driver to plug in alternate memory manager

[Ben Skeggs]

From: Ben Skeggs bske...@redhat.com

Nouveau will need this on GeForce 8 and up to account for the GPU
reordering physical VRAM for some memory types.

Signed-off-by: Ben Skeggs bske...@redhat.com
---
 drivers/gpu/drm/nouveau/nouveau_bo.c   |   12 ++-
 drivers/gpu/drm/nouveau/nouveau_channel.c  |6 +-
 drivers/gpu/drm/nouveau/nouveau_notifier.c |2 +-
 drivers/gpu/drm/nouveau/nouveau_sgdma.c|4 +-
 drivers/gpu/drm/nouveau/nv50_crtc.c|3 +-
 drivers/gpu/drm/nouveau/nv50_display.c |2 +-
 drivers/gpu/drm/nouveau/nv50_instmem.c |2 +-
 drivers/gpu/drm/radeon/radeon_object.c |6 +-
 drivers/gpu/drm/radeon/radeon_ttm.c|   16 ++--
 drivers/gpu/drm/ttm/Makefile   |3 +-
 drivers/gpu/drm/ttm/ttm_agp_backend.c  |3 +-
 drivers/gpu/drm/ttm/ttm_bo.c   |  100 ---
 drivers/gpu/drm/ttm/ttm_bo_manager.c   |  148 
 drivers/gpu/drm/ttm/ttm_bo_util.c  |3 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c |3 +-
 include/drm/ttm/ttm_bo_api.h   |3 +-
 include/drm/ttm/ttm_bo_driver.h|   21 -
 17 files changed, 225 insertions(+), 112 deletions(-)
 create mode 100644 drivers/gpu/drm/ttm/ttm_bo_manager.c

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 92290fa..f403737 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -390,6 +390,7 @@ nouveau_bo_init_mem_type(struct ttm_bo_device *bdev, 
uint32_t type,
man-default_caching = TTM_PL_FLAG_CACHED;
break;
case TTM_PL_VRAM:
+   man-func = ttm_bo_manager_func;
man-flags = TTM_MEMTYPE_FLAG_FIXED |
 TTM_MEMTYPE_FLAG_MAPPABLE;
man-available_caching = TTM_PL_FLAG_UNCACHED |
@@ -398,6 +399,7 @@ nouveau_bo_init_mem_type(struct ttm_bo_device *bdev, 
uint32_t type,
man-gpu_offset = dev_priv-vm_vram_base;
break;
case TTM_PL_TT:
+   man-func = ttm_bo_manager_func;
switch (dev_priv-gart_info.type) {
case NOUVEAU_GART_AGP:
man-flags = TTM_MEMTYPE_FLAG_MAPPABLE;
@@ -500,8 +502,8 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int 
evict, bool intr,
if (!chan || nvbo-tile_flags || nvbo-no_vm)
chan = dev_priv-channel;
 
-   src_offset = old_mem-mm_node-start  PAGE_SHIFT;
-   dst_offset = new_mem-mm_node-start  PAGE_SHIFT;
+   src_offset = old_mem-start  PAGE_SHIFT;
+   dst_offset = new_mem-start  PAGE_SHIFT;
if (chan != dev_priv-channel) {
if (old_mem-mem_type == TTM_PL_TT)
src_offset += dev_priv-vm_gart_base;
@@ -650,7 +652,7 @@ nouveau_bo_vm_bind(struct ttm_buffer_object *bo, struct 
ttm_mem_reg *new_mem,
return 0;
}
 
-   offset = new_mem-mm_node-start  PAGE_SHIFT;
+   offset = new_mem-start  PAGE_SHIFT;
 
if (dev_priv-card_type == NV_50) {
ret = nv50_mem_vm_bind_linear(dev,
@@ -764,14 +766,14 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev, 
struct ttm_mem_reg *mem)
case TTM_PL_TT:
 #if __OS_HAS_AGP
if (dev_priv-gart_info.type == NOUVEAU_GART_AGP) {
-   mem-bus.offset = mem-mm_node-start  PAGE_SHIFT;
+   mem-bus.offset = mem-start  PAGE_SHIFT;
mem-bus.base = dev_priv-gart_info.aper_base;
mem-bus.is_iomem = true;
}
 #endif
break;
case TTM_PL_VRAM:
-   mem-bus.offset = mem-mm_node-start  PAGE_SHIFT;
+   mem-bus.offset = mem-start  PAGE_SHIFT;
mem-bus.base = pci_resource_start(dev-pdev, 1);
mem-bus.is_iomem = true;
break;
diff --git a/drivers/gpu/drm/nouveau/nouveau_channel.c 
b/drivers/gpu/drm/nouveau/nouveau_channel.c
index 90fdcda..90d3450 100644
--- a/drivers/gpu/drm/nouveau/nouveau_channel.c
+++ b/drivers/gpu/drm/nouveau/nouveau_channel.c
@@ -48,14 +48,14 @@ nouveau_channel_pushbuf_ctxdma_init(struct nouveau_channel 
*chan)
  dev_priv-gart_info.aper_size,
  NV_DMA_ACCESS_RO, pushbuf,
  NULL);
-   chan-pushbuf_base = pb-bo.mem.mm_node-start  PAGE_SHIFT;
+   chan-pushbuf_base = pb-bo.mem.start  PAGE_SHIFT;
} else
if (dev_priv-card_type != NV_04) {
ret = nouveau_gpuobj_dma_new(chan, NV_CLASS_DMA_IN_MEMORY, 0,
 dev_priv-fb_available_size,
 NV_DMA_ACCESS_RO,
 NV_DMA_TARGET_VIDMEM, pushbuf);
-   

Re: GPU lockup+blackout on 2.6.35 with r600...

[Jerome Glisse]

On 08/05/2010 06:52 AM, Daniel J Blueman wrote:

After around 10-30 mins of typical usage (ie cairo rendering to
surfaces + compiz) on my Dell Studio 15 (model 1557), my R600 radeon
locks up, giving a blank screen.

The only information I have is a backtrace [1]. 'radeontool regs'
doesn't give anything - what information, /sys files etc would be
useful here, and would it be useful to log a freedesktop.org bug
report at this stage, assuming I haven't found a reliable reproducer?

OS is Ubuntu 10.10 development release, mesa 7.8.2, libdrm2 2.4.21.

Thanks,
   Daniel

--- [1]

radeon :02:00.0: GPU lockup CP stall for more than 1000msec
[ cut here ]
WARNING: at /home/kernel-ppa/COD/linux/drivers/gpu/drm/radeon/radeon_fence.c:235
radeon_fence_wait+0x2b7/0x320 [radeon]()
Hardware name: Studio 1557
GPU lockup (waiting for 0x8C35 last fence id 0x8C33)
Modules linked in: binfmt_misc parport_pc ppdev kvm_intel kvm
microcode snd_hda_codec_atihdmi joydev ipt_REJECT xt_limit xt_tcpudp
ipt_addrtype xt_state snd_hda_codec_idt ip6table_filter ip6_tables
snd_hda_intel nf_nat_irc nf_conntrack_irc snd_hda_codec nf_nat_ftp
nf_nat snd_hwdep nf_conntrack_ipv4 snd_seq_midi arc4 snd_pcm
snd_rawmidi nf_defrag_ipv4 radeon nf_conntrack_ftp nf_conntrack
iptable_filter snd_seq_midi_event snd_seq ip_tables ttm iwlagn video
snd_timer uvcvideo x_tables snd_seq_device output drm_kms_helper lp
dell_laptop iwlcore drm videodev dcdbas dell_wmi v4l1_compat mac80211
i7core_edac parport v4l2_compat_ioctl32 snd psmouse edac_core
i2c_algo_bit soundcore cfg80211 snd_page_alloc serio_raw sdhci_pci
sdhci ahci libahci led_class r8169 mii btrfs zlib_deflate crc32c
libcrc32c
Pid: 1624, comm: Xorg Tainted: G  D 2.6.35-020635-generic #020635
Call Trace:
? radeon_fence_wait+0x2b7/0x320 [radeon]
warn_slowpath_common+0x90/0xc0
warn_slowpath_fmt+0x6e/0x70
? schedule_timeout+0x15a/0x2e0
? r600_irq_set+0x27d/0xc00 [radeon]
? radeon_ring_commit+0xa3/0xb0 [radeon]
? r100_gpu_cp_is_lockup+0xc2/0xd0 [radeon]
? r600_gpu_is_lockup+0x1cb/0x220 [radeon]
radeon_fence_wait+0x2b7/0x320 [radeon]
? autoremove_wake_function+0x0/0x40
radeon_sync_obj_wait+0x11/0x20 [radeon]
ttm_bo_wait+0x102/0x1b0 [ttm]
ttm_bo_move_accel_cleanup+0x19e/0x230 [ttm]
radeon_move_blit+0x124/0x170 [radeon]
radeon_bo_move+0xda/0x1a0 [radeon]
ttm_bo_handle_move_mem+0xec/0x370 [ttm]
ttm_bo_evict+0x1cc/0x270 [ttm]
? drm_mm_split_at_start+0x1d/0x80 [drm]
ttm_mem_evict_first+0xed/0x180 [ttm]
? ttm_bo_man_get_node+0xd5/0xe0 [ttm]
ttm_bo_mem_force_space+0xab/0x110 [ttm]
ttm_bo_mem_space+0x305/0x370 [ttm]
ttm_bo_move_buffer+0xcf/0x140 [ttm]
? drm_mm_split_at_start+0x1d/0x80 [drm]
ttm_bo_validate+0xd5/0x100 [ttm]
ttm_bo_init+0x1f2/0x240 [ttm]
radeon_bo_create+0x121/0x240 [radeon]
? radeon_ttm_bo_destroy+0x0/0x80 [radeon]
radeon_gem_object_create+0x89/0x100 [radeon]
? drm_gem_handle_create+0x8b/0xa0 [drm]
radeon_gem_create_ioctl+0x58/0xe0 [radeon]
drm_ioctl+0x283/0x460 [drm]
? radeon_gem_create_ioctl+0x0/0xe0 [radeon]
? do_readv_writev+0x16b/0x1e0
vfs_ioctl+0x3a/0xc0
do_vfs_ioctl+0x6d/0x1f0
sys_ioctl+0x87/0xa0
? sys_writev+0x55/0xb0
system_call_fastpath+0x16/0x1b
---[ end trace c0bc12025fa8386c ]---
radeon :02:00.0: GPU softreset
radeon :02:00.0:   R_008010_GRBM_STATUS=0xA0003028
radeon :02:00.0:   R_008014_GRBM_STATUS2=0x0002
radeon :02:00.0:   R_000E50_SRBM_STATUS=0x20C0
radeon :02:00.0:   R_008020_GRBM_SOFT_RESET=0x7FEE
radeon :02:00.0: R_008020_GRBM_SOFT_RESET=0x0001
radeon :02:00.0:   R_008010_GRBM_STATUS=0x3028
radeon :02:00.0:   R_008014_GRBM_STATUS2=0x0002
radeon :02:00.0:   R_000E50_SRBM_STATUS=0x20C0
radeon :02:00.0: GPU reset succeed
Clocks initialized !
ring test succeeded in 1 usecs
ib test succeeded in 1 usecs



SO it keep reseting ? According to log there is a GPU lockup but then
a successfull GPU reset so GPU should resume fine (that's what log says)
Best is to open a bug and attach full dmesg + lspci -vv and context
in which the lockup happen

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

[Bug 29226] on r600 3d applications are rendered in too bright colors

[bugzilla-daemon]

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

--- Comment #4 from Michal Suchanek hramr...@centrum.cz 2010-08-05 06:52:13 
PDT ---
Created an attachment (id=37585)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=37585)
rendered on r600g

Apart from other glitches the color issue also appears on r600g

-- 
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 RESEND block#for-2.6.36] block_dev: always serialize exclusive open attempts

[Markus Trippelsdorf]

On Thu, Aug 05, 2010 at 11:02:43AM +0200, Jens Axboe wrote:
 On 2010-08-04 17:59, Tejun Heo wrote:
  bd_prepare_to_claim() incorrectly allowed multiple attempts for
  exclusive open to progress in parallel if the attempting holders are
  identical.  This triggered BUG_ON() as reported in the following bug.
  
https://bugzilla.kernel.org/show_bug.cgi?id=16393
  
  __bd_abort_claiming() is used to finish claiming blocks and doesn't
  work if multiple openers are inside a claiming block.  Allowing
  multiple parallel open attempts to continue doesn't gain anything as
  those are serialized down in the call chain anyway.  Fix it by always
  allowing only single open attempt in a claiming block.
  
  This problem can easily be reproduced by adding a delay after
  bd_prepare_to_claim() and attempting to mount two partitions of a
  disk.
  
  stable: only applicable to v2.6.35
  
  Signed-off-by: Tejun Heo t...@kernel.org
  Reported-by: Markus Trippelsdorf mar...@trippelsdorf.de
  Cc: sta...@kernel.org
 
 Thanks Tejun, applied.

It's already in mainline:
e75aa85892b2ee78c79edac720868cbef16e62eb

-- 
»A man who doesn't know he is in prison can never escape.«
William S. Burroughs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 29400] R300G : Regression, Transparency in KDE effects is corrupted

[bugzilla-daemon]

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

--- Comment #5 from maxi...@free.fr 2010-08-05 09:57:56 PDT ---
Hi,

Thanks for your advices on bisecting, I did not even think of symlinking .
Anyways, it looks like there is some kind of bug, sometimes KDE says it can
enable effects and after when reverting to a working dri driver it never wants
to enable it again... I'll have to sort this out...

Anyways, the transparency problem is solved (on a kernel update ?)
And the other issue I reported, (the lag in the fade effect) also seems to be
gone... I don't understand how...

I' attach a screenshot of how it is now (partially fixed ? transparency is OK
but why don't I have the thumbnail of my window ?)

-- 
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 29400] R300G : Regression, Transparency in KDE effects is corrupted

[bugzilla-daemon]

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

--- Comment #6 from maxi...@free.fr 2010-08-05 10:00:25 PDT ---
Created an attachment (id=37591)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=37591)
transparency ok

thumbnail at the center is missing, I don't know why. I'll have to find out if
it's related to KDE or r300g

-- 
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 29226] on r600 3d applications are rendered in too bright colors

[bugzilla-daemon]

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

--- Comment #5 from Michal Suchanek hramr...@centrum.cz 2010-08-05 10:11:07 
PDT ---
As suggested by people on irc I found a demo that shows a similar issue.

The demo is shadowtex from current mesa git.

The green ball in the demo using the fixed function shader (default) on Intel
renders only slightly edgy ball but a ball with a flat spot on r600.

The demo currently crashes on r600g. 

Note that the demo is designed to showcase features that don't work at all on
Intel and a simpler demo with the shader only should be possible. Note that due
to the features present on r600 you may need to cycle through the different
composition modes with the 'o' key until most of the surface is shown in the
brighter color and the flat area is visible.

-- 
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 29226] on r600 3d applications are rendered in too bright colors

[bugzilla-daemon]

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

--- Comment #7 from Michal Suchanek hramr...@centrum.cz 2010-08-05 10:12:16 
PDT ---
Created an attachment (id=37597)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=37597)
shadowtex on intel

-- 
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 29400] R300G : Regression, Transparency in KDE effects is corrupted

[bugzilla-daemon]

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

--- Comment #7 from maxi...@free.fr 2010-08-05 11:35:03 PDT ---
OK I confirm the thumbnail bug is not in kde but in r300g
I'll post a screenshot with swrast_dri.so.

-- 
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 29400] R300G : Regression, Transparency in KDE effects is corrupted

[bugzilla-daemon]

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

--- Comment #8 from maxi...@free.fr 2010-08-05 11:35:57 PDT ---
Created an attachment (id=37598)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=37598)
with swrast thumbnail OK

-- 
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 25/42] drivers/gpu/drm/radeon: Adjust confusing if indentation

[Julia Lawall]

From: Julia Lawall ju...@diku.dk

Outdent the code following the if.

The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)

// smpl
@r disable braces4@
position p1,p2;
statement S1,S2;
@@

(
if (...) { ... }
|
if (...) s...@p1 s...@p2
)

@script:python@
p1  r.p1;
p2  r.p2;
@@

if (p1[0].column == p2[0].column):
  cocci.print_main(branch,p1)
  cocci.print_secs(after,p2)
// /smpl

Signed-off-by: Julia Lawall ju...@diku.dk

---
 drivers/gpu/drm/radeon/evergreen.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 957d506..1a2797c 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -136,7 +136,7 @@ bool evergreen_hpd_sense(struct radeon_device *rdev, enum 
radeon_hpd_id hpd)
case RADEON_HPD_6:
if (RREG32(DC_HPD6_INT_STATUS)  DC_HPDx_SENSE)
connected = true;
-   break;
+   break;
default:
break;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: GSoC: modprobe glint - monitor loses signal

[Adam Jackson]

On Thu, 2010-08-05 at 12:16 -0400, Matt Turner wrote:
 Hi,
 I've hit a snag and I'm not really sure how to debug it.
 
 Both xf86-video-glint/src/pm3_dac.c:Permedia3Init and
 kernel/drivers/video/pm3fb.c:pm3fb_write_mode set the mode in
 virtually identical ways. I'm trying to do the same, but I think some
 of what I'm passing in from drm_display_mode is wrong, specifically
 
 WREG32(PM3HTotal,  glint_shift_bpp(bpp, mode-htotal - 1));
 WREG32(PM3HsEnd,   glint_shift_bpp(bpp, mode-hsync_end - mode-hdisplay));
 WREG32(PM3HsStart, glint_shift_bpp(bpp, mode-hsync_start - mode-hdisplay));
 WREG32(PM3HbEnd,   glint_shift_bpp(bpp, mode-htotal - mode-hdisplay));
 WREG32(PM3HgEnd,   glint_shift_bpp(bpp, mode-htotal - mode-hdisplay));
 WREG32(PM3ScreenStride, glint_shift_bpp(bpp, crtc-fb-width));
 WREG32(PM3VTotal,  glint_shift_bpp(bpp, mode-vtotal - 1));
 WREG32(PM3VsEnd,   glint_shift_bpp(bpp, mode-vsync_end - 1));
 WREG32(PM3VsStart, glint_shift_bpp(bpp, mode-vsync_start - 1));
 WREG32(PM3VbEnd,   glint_shift_bpp(bpp, mode-vtotal - mode-vdisplay));

 I printed the values that xf86-video-glint passes through here, and of
 course they don't match with anything my driver has. I imagine guess
 it's because they're all resolution-dependent?

They are.  What does the X driver print, and what mode are you trying to
set?

This though:

WREG32(PM3VsStart, glint_shift_bpp(bpp, mode-vsync_start - 1));

Versus in the X driver:

temp2 = mode-CrtcVSyncStart - mode-CrtcVDisplay;
...
STOREREG(PMVsStart, temp2 - 1);

For a mode like 1920x1200R, the former is going to be 1202, but the
latter is going to be (1203 - 1200) - 1 == 2.  So assuming the X driver
is right, the hardware is looking for the distance in clocks between the
various sync steps, and not their absolute offset from the beginning of
the line/frame.

- ajax


signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 29067] WebGL in Firefox is very slow (pegs the cpu)

[bugzilla-daemon]

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

Sven Arvidsson s...@whiz.se changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Sven Arvidsson s...@whiz.se 2010-08-05 16:07:41 PDT ---
Using git master (from yesterday?) this is no longer a 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 28993] [r300g] lightmap texture corruption in some games

[bugzilla-daemon]

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

Marek Olšák mar...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

--- Comment #6 from Marek Olšák mar...@gmail.com 2010-08-05 16:39:34 PDT ---


*** This bug has been marked as a duplicate of bug 28800 ***

-- 
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 28800] [r300c, r300g] Texture corruption with World of Warcraft

[bugzilla-daemon]

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

Marek Olšák mar...@gmail.com changed:

   What|Removed |Added

 CC||aaalmo...@gmail.com

--- Comment #14 from Marek Olšák mar...@gmail.com 2010-08-05 16:39:34 PDT ---
*** Bug 28993 has been marked as a duplicate of this 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

[Bug 29066] [r300c, r300g] pipes triggers Assertion `boi-space_accounted' failed

[bugzilla-daemon]

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

Marek Olšák mar...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||NOTOURBUG

--- Comment #15 from Marek Olšák mar...@gmail.com 2010-08-05 16:57:15 PDT ---
According to the last feedback, this issue seems to be resolved by using the
driver from git instead of the PPA. Closing..

-- 
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 27314] DP link training fails on 2560x1440 panels

[bugzilla-daemon]

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

--- Comment #16 from Alex Deucher ag...@yahoo.com 2010-08-05 17:55:57 PDT ---
This is a problem in the link training algo.  The timing and ordering may need
to be tweaked to make some monitors happy.

-- 
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 27314] DP link training fails on 2560x1440 panels

[bugzilla-daemon]

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

--- Comment #17 from Travis Glenn Hansen travisghan...@yahoo.com 2010-08-05 
18:10:05 PDT ---
Created an attachment (id=37606)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=37606)
avivotool regs all (vanilla radeontool package)

This is the output of my machine while running fglrx.
attachment 34810 *not* applied.  will upload output with that patch
momentarily.

-- 
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 28955] [r300g]: refresh/update/damage issues using compiz.

[bugzilla-daemon]

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

--- Comment #8 from Droste tdro...@gmx.de 2010-08-05 18:18:35 PDT ---
Created an attachment (id=37612)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=37612)
Example scrolling in firefox + kwin compositing and r300g

-- 
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 1/3] drm/radeon/kms: unify i2c handling

[Alex Deucher]

Previously we added i2c buses as needed when enumerating connectors
power management, etc.  This only exposed the actual buses used and
could have lead to the same buse getting created more than once if
one buses was used for more than one purpose.  This patch sets up
all i2c buses on the card in one place and users of the buses just
point back to the one instance.

Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
 drivers/gpu/drm/radeon/radeon.h|2 +
 drivers/gpu/drm/radeon/radeon_atombios.c   |   67 +++-
 drivers/gpu/drm/radeon/radeon_combios.c|   77 +---
 drivers/gpu/drm/radeon/radeon_connectors.c |   31 
 drivers/gpu/drm/radeon/radeon_display.c|5 ++
 drivers/gpu/drm/radeon/radeon_i2c.c|   53 +++
 drivers/gpu/drm/radeon/radeon_mode.h   |   11 
 7 files changed, 214 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 368fecf..fed3d07 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1100,6 +1100,8 @@ struct radeon_device {
struct notifier_block acpi_nb;
/* only one userspace can use Hyperz features at a time */
struct drm_file *hyperz_filp;
+   /* i2c buses */
+   struct radeon_i2c_chan *i2c_bus[RADEON_MAX_I2C_BUS];
 };
 
 int radeon_device_init(struct radeon_device *rdev,
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c 
b/drivers/gpu/drm/radeon/radeon_atombios.c
index 2b9a516..7851008 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -114,7 +114,8 @@ static inline struct radeon_i2c_bus_rec 
radeon_lookup_i2c_gpio(struct radeon_dev
 
i2c.i2c_id = gpio-sucI2cId.ucAccess;
 
-   i2c.valid = true;
+   if (i2c.mask_clk_reg)
+   i2c.valid = true;
break;
}
}
@@ -123,6 +124,66 @@ static inline struct radeon_i2c_bus_rec 
radeon_lookup_i2c_gpio(struct radeon_dev
return i2c;
 }
 
+void radeon_atombios_i2c_init(struct radeon_device *rdev)
+{
+   struct atom_context *ctx = rdev-mode_info.atom_context;
+   ATOM_GPIO_I2C_ASSIGMENT *gpio;
+   struct radeon_i2c_bus_rec i2c;
+   int index = GetIndexIntoMasterTable(DATA, GPIO_I2C_Info);
+   struct _ATOM_GPIO_I2C_INFO *i2c_info;
+   uint16_t data_offset, size;
+   int i, num_indices;
+   char stmp[32];
+
+   memset(i2c, 0, sizeof(struct radeon_i2c_bus_rec));
+
+   if (atom_parse_data_header(ctx, index, size, NULL, NULL, 
data_offset)) {
+   i2c_info = (struct _ATOM_GPIO_I2C_INFO *)(ctx-bios + 
data_offset);
+
+   num_indices = (size - sizeof(ATOM_COMMON_TABLE_HEADER)) /
+   sizeof(ATOM_GPIO_I2C_ASSIGMENT);
+
+   for (i = 0; i  num_indices; i++) {
+   gpio = i2c_info-asGPIO_Info[i];
+   i2c.valid = false;
+   i2c.mask_clk_reg = 
le16_to_cpu(gpio-usClkMaskRegisterIndex) * 4;
+   i2c.mask_data_reg = 
le16_to_cpu(gpio-usDataMaskRegisterIndex) * 4;
+   i2c.en_clk_reg = 
le16_to_cpu(gpio-usClkEnRegisterIndex) * 4;
+   i2c.en_data_reg = 
le16_to_cpu(gpio-usDataEnRegisterIndex) * 4;
+   i2c.y_clk_reg = le16_to_cpu(gpio-usClkY_RegisterIndex) 
* 4;
+   i2c.y_data_reg = 
le16_to_cpu(gpio-usDataY_RegisterIndex) * 4;
+   i2c.a_clk_reg = le16_to_cpu(gpio-usClkA_RegisterIndex) 
* 4;
+   i2c.a_data_reg = 
le16_to_cpu(gpio-usDataA_RegisterIndex) * 4;
+   i2c.mask_clk_mask = (1  gpio-ucClkMaskShift);
+   i2c.mask_data_mask = (1  gpio-ucDataMaskShift);
+   i2c.en_clk_mask = (1  gpio-ucClkEnShift);
+   i2c.en_data_mask = (1  gpio-ucDataEnShift);
+   i2c.y_clk_mask = (1  gpio-ucClkY_Shift);
+   i2c.y_data_mask = (1  gpio-ucDataY_Shift);
+   i2c.a_clk_mask = (1  gpio-ucClkA_Shift);
+   i2c.a_data_mask = (1  gpio-ucDataA_Shift);
+
+   if (gpio-sucI2cId.sbfAccess.bfHW_Capable)
+   i2c.hw_capable = true;
+   else
+   i2c.hw_capable = false;
+
+   if (gpio-sucI2cId.ucAccess == 0xa0)
+   i2c.mm_i2c = true;
+   else
+   i2c.mm_i2c = false;
+
+   i2c.i2c_id = gpio-sucI2cId.ucAccess;
+
+   if (i2c.mask_clk_reg) {
+   i2c.valid = true;
+   sprintf(stmp, 0x%x, 

[PATCH 2/3] drm/radeon/kms: rework combios i2c handling

[Alex Deucher]

Handle asic specific table to hw mappings in
combios_setup_i2c_bus() directly.  This allows us
to remove most of the combios quirks and clean up
the i2c bus setup.

Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
 drivers/gpu/drm/radeon/radeon_combios.c |  415 +--
 1 files changed, 168 insertions(+), 247 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_combios.c 
b/drivers/gpu/drm/radeon/radeon_combios.c
index 18c84cf..885dcfa 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -479,21 +479,67 @@ radeon_combios_get_hardcoded_edid(struct radeon_device 
*rdev)
return NULL;
 }
 
-/* standard i2c gpio lines */
-#define RADEON_I2C_MONID_ID 0
-#define RADEON_I2C_DVI_ID   1
-#define RADEON_I2C_VGA_ID   2
-#define RADEON_I2C_CRT2_ID  3
-#define RADEON_I2C_MM_ID4
-/* custom defined gpio lines */
-#define RADEON_I2C_LCD_ID   5 /* ddc for laptop panels */
-#define RADEON_I2C_GPIO_ID  6 /* rs4xx gpio ddc */
-#define RADEON_I2C_DVO_ID   7 /* i2c bus for dvo */
-
 static struct radeon_i2c_bus_rec combios_setup_i2c_bus(struct radeon_device 
*rdev,
-  int ddc_line)
+  enum radeon_combios_ddc 
ddc,
+  u32 clk_mask,
+  u32 data_mask)
 {
struct radeon_i2c_bus_rec i2c;
+   int ddc_line = 0;
+
+   /* ddc id= mask reg
+* DDC_NONE_DETECTED = none
+* DDC_DVI   = RADEON_GPIO_DVI_DDC
+* DDC_VGA   = RADEON_GPIO_VGA_DDC
+* DDC_LCD   = RADEON_GPIOPAD_MASK
+* DDC_GPIO  = RADEON_MDGPIO_MASK
+* r1xx/r2xx
+* DDC_MONID = RADEON_GPIO_MONID
+* DDC_CRT2  = RADEON_GPIO_CRT2_DDC
+* r3xx
+* DDC_MONID = RADEON_GPIO_MONID
+* DDC_CRT2  = RADEON_GPIO_DVI_DDC
+* rs3xx/rs4xx
+* DDC_MONID = RADEON_GPIOPAD_MASK
+* DDC_CRT2  = RADEON_GPIO_MONID
+*/
+   switch (ddc) {
+   case DDC_NONE_DETECTED:
+   default:
+   ddc_line = 0;
+   break;
+   case DDC_DVI:
+   ddc_line = RADEON_GPIO_DVI_DDC;
+   break;
+   case DDC_VGA:
+   ddc_line = RADEON_GPIO_VGA_DDC;
+   break;
+   case DDC_LCD:
+   ddc_line = RADEON_GPIOPAD_MASK;
+   break;
+   case DDC_GPIO:
+   ddc_line = RADEON_MDGPIO_MASK;
+   break;
+   case DDC_MONID:
+   if (rdev-family == CHIP_RS300 ||
+   rdev-family == CHIP_RS400 ||
+   rdev-family == CHIP_RS480)
+   ddc_line = RADEON_GPIOPAD_MASK;
+   else
+   ddc_line = RADEON_GPIO_MONID;
+   break;
+   case DDC_CRT2:
+   if (rdev-family == CHIP_RS300 ||
+   rdev-family == CHIP_RS400 ||
+   rdev-family == CHIP_RS480)
+   ddc_line = RADEON_GPIO_MONID;
+   else if (rdev-family = CHIP_R300) {
+   ddc_line = RADEON_GPIO_DVI_DDC;
+   ddc = DDC_DVI;
+   } else
+   ddc_line = RADEON_GPIO_CRT2_DDC;
+   break;
+   }
 
if (ddc_line == RADEON_GPIOPAD_MASK) {
i2c.mask_clk_reg = RADEON_GPIOPAD_MASK;
@@ -514,15 +560,6 @@ static struct radeon_i2c_bus_rec 
combios_setup_i2c_bus(struct radeon_device *rde
i2c.y_clk_reg = RADEON_MDGPIO_Y;
i2c.y_data_reg = RADEON_MDGPIO_Y;
} else {
-   i2c.mask_clk_mask = RADEON_GPIO_EN_1;
-   i2c.mask_data_mask = RADEON_GPIO_EN_0;
-   i2c.a_clk_mask = RADEON_GPIO_A_1;
-   i2c.a_data_mask = RADEON_GPIO_A_0;
-   i2c.en_clk_mask = RADEON_GPIO_EN_1;
-   i2c.en_data_mask = RADEON_GPIO_EN_0;
-   i2c.y_clk_mask = RADEON_GPIO_Y_1;
-   i2c.y_data_mask = RADEON_GPIO_Y_0;
-
i2c.mask_clk_reg = ddc_line;
i2c.mask_data_reg = ddc_line;
i2c.a_clk_reg = ddc_line;
@@ -533,6 +570,26 @@ static struct radeon_i2c_bus_rec 
combios_setup_i2c_bus(struct radeon_device *rde
i2c.y_data_reg = ddc_line;
}
 
+   if (clk_mask  data_mask) {
+   i2c.mask_clk_mask = clk_mask;
+   i2c.mask_data_mask = data_mask;
+   i2c.a_clk_mask = clk_mask;
+   i2c.a_data_mask = data_mask;
+   i2c.en_clk_mask = clk_mask;
+   i2c.en_data_mask = data_mask;
+   i2c.y_clk_mask = clk_mask;
+   i2c.y_data_mask = data_mask;
+   } else {
+   i2c.mask_clk_mask = RADEON_GPIO_EN_1;
+   

[PATCH 3/3] drm/radeon/kms: add support for router objects

[Alex Deucher]

router objects are found on systems that use a mux to control
ddc line to connector routing or to control the actual clock and data
routing from the chip to the connectors.  This patch implements ddc line
routing.

Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
 drivers/gpu/drm/radeon/radeon_atombios.c   |   94 +++
 drivers/gpu/drm/radeon/radeon_connectors.c |   14 -
 drivers/gpu/drm/radeon/radeon_display.c|   12 
 drivers/gpu/drm/radeon/radeon_i2c.c|   29 +
 drivers/gpu/drm/radeon/radeon_mode.h   |   13 
 5 files changed, 147 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c 
b/drivers/gpu/drm/radeon/radeon_atombios.c
index 7851008..6d30868 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -48,7 +48,8 @@ radeon_add_atom_connector(struct drm_device *dev,
  struct radeon_i2c_bus_rec *i2c_bus,
  bool linkb, uint32_t igp_lane_info,
  uint16_t connector_object_id,
- struct radeon_hpd *hpd);
+ struct radeon_hpd *hpd,
+ struct radeon_router *router);
 
 /* from radeon_legacy_encoder.c */
 extern void
@@ -470,13 +471,15 @@ bool 
radeon_get_atom_connector_info_from_object_table(struct drm_device *dev)
u16 size, data_offset;
u8 frev, crev;
ATOM_CONNECTOR_OBJECT_TABLE *con_obj;
+   ATOM_OBJECT_TABLE *router_obj;
ATOM_DISPLAY_OBJECT_PATH_TABLE *path_obj;
ATOM_OBJECT_HEADER *obj_header;
-   int i, j, path_size, device_support;
+   int i, j, k, path_size, device_support;
int connector_type;
u16 igp_lane_info, conn_id, connector_object_id;
bool linkb;
struct radeon_i2c_bus_rec ddc_bus;
+   struct radeon_router router;
struct radeon_gpio_rec gpio;
struct radeon_hpd hpd;
 
@@ -486,6 +489,8 @@ bool 
radeon_get_atom_connector_info_from_object_table(struct drm_device *dev)
if (crev  2)
return false;
 
+   router.valid = false;
+
obj_header = (ATOM_OBJECT_HEADER *) (ctx-bios + data_offset);
path_obj = (ATOM_DISPLAY_OBJECT_PATH_TABLE *)
(ctx-bios + data_offset +
@@ -493,6 +498,9 @@ bool 
radeon_get_atom_connector_info_from_object_table(struct drm_device *dev)
con_obj = (ATOM_CONNECTOR_OBJECT_TABLE *)
(ctx-bios + data_offset +
 le16_to_cpu(obj_header-usConnectorObjectTableOffset));
+   router_obj = (ATOM_OBJECT_TABLE *)
+   (ctx-bios + data_offset +
+le16_to_cpu(obj_header-usRouterObjectTableOffset));
device_support = le16_to_cpu(obj_header-usDeviceSupport);
 
path_size = 0;
@@ -579,33 +587,86 @@ bool 
radeon_get_atom_connector_info_from_object_table(struct drm_device *dev)
if (connector_type == DRM_MODE_CONNECTOR_Unknown)
continue;
 
-   for (j = 0; j  ((le16_to_cpu(path-usSize) - 8) / 2);
-j++) {
-   uint8_t enc_obj_id, enc_obj_num, enc_obj_type;
+   for (j = 0; j  ((le16_to_cpu(path-usSize) - 8) / 2); 
j++) {
+   uint8_t grph_obj_id, grph_obj_num, 
grph_obj_type;
 
-   enc_obj_id =
+   grph_obj_id =
(le16_to_cpu(path-usGraphicObjIds[j]) 
 OBJECT_ID_MASK)  OBJECT_ID_SHIFT;
-   enc_obj_num =
+   grph_obj_num =
(le16_to_cpu(path-usGraphicObjIds[j]) 
 ENUM_ID_MASK)  ENUM_ID_SHIFT;
-   enc_obj_type =
+   grph_obj_type =
(le16_to_cpu(path-usGraphicObjIds[j]) 
 OBJECT_TYPE_MASK)  OBJECT_TYPE_SHIFT;
 
-   /* FIXME: add support for router objects */
-   if (enc_obj_type == GRAPH_OBJECT_TYPE_ENCODER) {
-   if (enc_obj_num == 2)
+   if (grph_obj_type == GRAPH_OBJECT_TYPE_ENCODER) 
{
+   if (grph_obj_num == 2)
linkb = true;
else
linkb = false;
 
radeon_add_atom_encoder(dev,
-   enc_obj_id,
+   grph_obj_id,
le16_to_cpu
 

Re: GSoC: modprobe glint - monitor loses signal

[Matt Turner]

I'll preface this response by saying that the driver is working now,
in very large part due to help I've received from Adam Jackson, Dave
Airlie, Alex Deucher, and Jerome Glisse.

On Thu, Aug 5, 2010 at 5:47 PM, Adam Jackson a...@redhat.com wrote:
 On Thu, 2010-08-05 at 12:16 -0400, Matt Turner wrote:
 Hi,
 I've hit a snag and I'm not really sure how to debug it.

 Both xf86-video-glint/src/pm3_dac.c:Permedia3Init and
 kernel/drivers/video/pm3fb.c:pm3fb_write_mode set the mode in
 virtually identical ways. I'm trying to do the same, but I think some
 of what I'm passing in from drm_display_mode is wrong, specifically

 WREG32(PM3HTotal,  glint_shift_bpp(bpp, mode-htotal - 1));
 WREG32(PM3HsEnd,   glint_shift_bpp(bpp, mode-hsync_end - mode-hdisplay));
 WREG32(PM3HsStart, glint_shift_bpp(bpp, mode-hsync_start - mode-hdisplay));
 WREG32(PM3HbEnd,   glint_shift_bpp(bpp, mode-htotal - mode-hdisplay));
 WREG32(PM3HgEnd,   glint_shift_bpp(bpp, mode-htotal - mode-hdisplay));
 WREG32(PM3ScreenStride, glint_shift_bpp(bpp, crtc-fb-width));
 WREG32(PM3VTotal,  glint_shift_bpp(bpp, mode-vtotal - 1));
 WREG32(PM3VsEnd,   glint_shift_bpp(bpp, mode-vsync_end - 1));
 WREG32(PM3VsStart, glint_shift_bpp(bpp, mode-vsync_start - 1));
 WREG32(PM3VbEnd,   glint_shift_bpp(bpp, mode-vtotal - mode-vdisplay));

 I printed the values that xf86-video-glint passes through here, and of
 course they don't match with anything my driver has. I imagine guess
 it's because they're all resolution-dependent?

 They are.  What does the X driver print, and what mode are you trying to
 set?

I'm setting 1024x768x24 (32 bpp).

Timings set by my driver are
PM3HTotal: 335
PM3HsEnd: 40
PM3HsStart: 6
PM3HbEnd: 80
PM3HgEnd: 80
PM3ScreenStride: 256
PM3VTotal: 805
PM3VsEnd: 8
PM3VsStart: 2
PM3VbEnd: 38

Timings set by xf86-video-glint are (for the same mode)
PM3HTotal: 327
PM3HsEnd: 28
PM3HsStart: 4
PM3HbEnd: 72
PM3HgEnd: 72
PM3ScreenStride: 256
PM3VTotal: 799
PM3VsEnd: 3
PM3VsStart: 0
PM3VbEnd: 32

So, clearly very close.

The final thing I did to make it work was to set the PM3VideoControl
register to turn on hsync and vsync. So, of course without this I'm
not getting any signals to the monitor. :)

 This though:

    WREG32(PM3VsStart, glint_shift_bpp(bpp, mode-vsync_start - 1));

 Versus in the X driver:

    temp2 = mode-CrtcVSyncStart - mode-CrtcVDisplay;
    ...
    STOREREG(PMVsStart, temp2 - 1);

Yes, you were right about this. I've changed them to
 - PM3VsEnd = mode-vsync_end - mode-vdisplay - 1
 - PM3VsStart = mode-vsync_start - mode-vdisplay - 1

I also noticed that I was using glint_shift_bpp on the vsync timings,
which isn't correct.

 For a mode like 1920x1200R, the former is going to be 1202, but the
 latter is going to be (1203 - 1200) - 1 == 2.  So assuming the X driver
 is right, the hardware is looking for the distance in clocks between the
 various sync steps, and not their absolute offset from the beginning of
 the line/frame.

Yep, this appears to be the case. It also appears, and I could be
wrong, not to be what the documentation states. :)

 - ajax

Thanks again to everyone who helped me. Now I'll write up some
documentation to finish off the GSoC requirements and hopefully will
fix up the driver to a state where it can live in the kernel.

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

[Bug 28477] [R300g] dxdiag directx tests fail on vmware workstation 7.1.0 w/ r500 card using gallium

[bugzilla-daemon]

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

Marek Olšák mar...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from Marek Olšák mar...@gmail.com 2010-08-05 19:15:45 PDT ---
Please follow bug 29244 instead.

*** This bug has been marked as a duplicate of bug 29244 ***

-- 
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 29244] [wine][r300g] Spore Creature Creator segfaults

[bugzilla-daemon]

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

Marek Olšák mar...@gmail.com changed:

   What|Removed |Added

 CC||cru...@gmail.com

--- Comment #2 from Marek Olšák mar...@gmail.com 2010-08-05 19:15:45 PDT ---
*** Bug 28477 has been marked as a duplicate of this 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/radeon/kms: add additional quirk for Acer rv620 laptop

[Alex Deucher]

HPD pins are reversed

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

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

diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c 
b/drivers/gpu/drm/radeon/radeon_atombios.c
index 73e6e77..2b9a516 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -206,6 +206,7 @@ static bool radeon_atom_apply_quirks(struct drm_device *dev,
 uint16_t *line_mux,
 struct radeon_hpd *hpd)
 {
+   struct radeon_device *rdev = dev-dev_private;
 
/* Asus M2A-VM HDMI board lists the DVI port as HDMI */
if ((dev-pdev-device == 0x791e) 
@@ -308,13 +309,22 @@ static bool radeon_atom_apply_quirks(struct drm_device 
*dev,
}
}
 
-   /* Acer laptop reports DVI-D as DVI-I */
+   /* Acer laptop reports DVI-D as DVI-I and hpd pins reversed */
if ((dev-pdev-device == 0x95c4) 
(dev-pdev-subsystem_vendor == 0x1025) 
(dev-pdev-subsystem_device == 0x013c)) {
+   struct radeon_gpio_rec gpio;
+
if ((*connector_type == DRM_MODE_CONNECTOR_DVII) 
-   (supported_device == ATOM_DEVICE_DFP1_SUPPORT))
+   (supported_device == ATOM_DEVICE_DFP1_SUPPORT)) {
+   gpio = radeon_lookup_gpio(rdev, 6);
+   *hpd = radeon_atom_get_hpd_info_from_gpio(rdev, gpio);
*connector_type = DRM_MODE_CONNECTOR_DVID;
+   } else if ((*connector_type == DRM_MODE_CONNECTOR_HDMIA) 
+  (supported_device == ATOM_DEVICE_DFP1_SUPPORT)) {
+   gpio = radeon_lookup_gpio(rdev, 7);
+   *hpd = radeon_atom_get_hpd_info_from_gpio(rdev, gpio);
+   }
}
 
/* XFX Pine Group device rv730 reports no VGA DDC lines
-- 
1.7.1.1

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

[Bug 29363] [r300g] Starcraft 2: r300 VP: Compiler error

[bugzilla-daemon]

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

--- Comment #4 from Tom Stellard tstel...@gmail.com 2010-08-05 21:43:17 PDT 
---
Created an attachment (id=37618)
 View: https://bugs.freedesktop.org/attachment.cgi?id=37618
 Review: https://bugs.freedesktop.org/review?bug=29363attachment=37618

Implement vertex shader loops

Can you test again with this patch and post the output of RADEON_DEBUG=vp.  A
screenshot would also be helpful.

-- 
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 29363] [r300g] Starcraft 2: r300 VP: Compiler error

[bugzilla-daemon]

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

Tom Stellard tstel...@gmail.com changed:

   What|Removed |Added

  Attachment #37618|0   |1
is obsolete||

--- Comment #5 from Tom Stellard tstel...@gmail.com 2010-08-05 22:10:43 PDT 
---
(From update of attachment 37618)
This patch has a mistake, another one is one the way.

-- 
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 29363] [r300g] Starcraft 2: r300 VP: Compiler error

[bugzilla-daemon]

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

--- Comment #6 from Tom Stellard tstel...@gmail.com 2010-08-05 22:22:27 PDT 
---
Created an attachment (id=37619)
 View: https://bugs.freedesktop.org/attachment.cgi?id=37619
 Review: https://bugs.freedesktop.org/review?bug=29363attachment=37619

Implement vertex shader loops v2

This patch should be better.

-- 
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