[PATCH 3/3] alpha, drm: Add Alpha support to Radeon DRM code

[Jay Estabrook]

Hi, Dave,

It is the explanation that is inaccurate; I was still thinking about mmap when
the new paradigm is to do the mapping when the VM faults.

I believe the code that requires this patch is: ttm/ttm_bo_vm.c: 
ttm_bo_vm_fault(),
specifically:

for (i = 0; i < TTM_BO_VM_NUM_PREFAULT; ++i) {
if (bo->mem.bus.is_iomem)
pfn = ((bo->mem.bus.base + bo->mem.bus.offset) >> PAGE_SHIFT) + 
page_offset;
else {

The "pfn" needs to reflect the correct system bus address to get to the VRAM
on the graphics card.

I will rework the commentary and resend.

Thanks for the feedback.

Jay


On 06/13/2011 07:35 PM, Dave Airlie wrote:
> On Fri, Jun 10, 2011 at 8:20 AM, Jay Estabrook  
> wrote:
>> Alpha needs to have the system bus address for the device's local
>> memory available, so that it can be returned to user-level, where
>> it may be used in an mmap(). So, we make bus.addr hold the ioremap()
>> return for kernel use, and then we can modify bus.base appropriately.
>>
> 
> I don't get this. why is mmap passing in an address? we don't do that anymore.
> 
> When you mmap the device node it passes back a hashed offset in the
> table, that the
> kernel then translates into a proper address and sets up the page tables.
> 
> So I really don't get what this patch is doing, either the
> explaination of what it is doing is wrong
> or it is wrong.
> 
> Dave.

r600g TXD opcode (was: ... translation from TGSI failed / missing vertex shader)

[Sven Arvidsson]

On Tue, 2011-06-14 at 19:09 +0200, David Lamparter wrote:
> On Sun, Jun 05, 2011 at 10:32:34PM -0700, bugzilla-daemon at freedesktop.org 
> wrote:
> > I'm attaching a patch that has an implementation. Unfortunately I can't 
> > seem to
> > get it to work entirely correctly. The piglit test looks almost correct but 
> > has
> > several artifacts in random places. If someone could point me in the right
> > direction (as I'm completely clueless), I would be happy to finish it. In 
> > case
> > it matters, piglit does not show any new failures from this patch.
> 
> Did you make any progress? This also affects EVE Online btw.

AFAIK, you need to use the web interface to comment on bugs. Otherwise
Mike will miss this (unless he follows dri-devel):
https://bugs.freedesktop.org/show_bug.cgi?id=37476

-- 
Cheers,
Sven Arvidsson
http://www.whiz.se
PGP Key ID 760BDD22

-- 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/20110614/d3875afd/attachment.pgp>

r600g TXD opcode (was: ... translation from TGSI failed / missing vertex shader)

[David Lamparter]

On Sun, Jun 05, 2011 at 10:32:34PM -0700, bugzilla-daemon at freedesktop.org 
wrote:
> I'm attaching a patch that has an implementation. Unfortunately I can't seem 
> to
> get it to work entirely correctly. The piglit test looks almost correct but 
> has
> several artifacts in random places. If someone could point me in the right
> direction (as I'm completely clueless), I would be happy to finish it. In case
> it matters, piglit does not show any new failures from this patch.

Did you make any progress? This also affects EVE Online btw.

-David

drm-radeon failures on R600: patches still don't work

[Yaroslav Fedevych]

On 12/06/11 14:21, Markus Trippelsdorf wrote:
> Hmm, maybe you're seeing a different problem. The issue that I saw was
> fixed by commit 428c6e3630 in the git tree (this is identical to the
> patch by Dave you're referring to above).
>
> Does a "git-revert fe6f0bd03d697835e76dd18d232ba476c65b8282" solve your
> problem?

As for spewing the log with "invalid textures", yes. I bisected it twice 
to exclude any pilot error.

As for other things... it's rather getting strange. Instead of garbled 
screen when starting X which was there before revert, and having ability 
to switch to a text VT to see the kernel message, the machine just... 
hangs. The cursor first freezes, then after a few seconds disappears, 
and that's it. After 30 seconds more, HDD stops spinning.

I thought there might be a kernel panic or something, but even if it is, 
the kernel cannot say anything. I fired up netconsole and tried to go 
with that, but to no avail. There was no message which could be a clear 
precursor to disaster.

I thought then that the kernel might manage to print at least something 
on the console. So as soon as I have seen the switch to graphics and the 
mouse cursor, I switched the VT immediately. After a while, the screen 
went black and that was it. It wasn't a particular service.

Even more curious thing is that even using Catalyst doesn't help: it 
invariably comes to this end. I have a pure text console boot, then it 
starts GDM, then there's a black screen with busy cursor spinning, I 
switch to the text console, after a few seconds I lose control over it, 
that is - the boot process freezes and the keyboard stops accepting 
input, then the switch to a black screen and that's it.

And the only reliable pre-requisite for this to happen is to launch X. 
In single-user, without X running, it would work for days, KMS or not.

I'm really not sure how to debug this. This behaviour started as soon as 
3.0.0-rc2 and is there as of today's git (3.0.0-rc3).

Also, I'm not sure that DRI is to blame, because the hangs occur on both 
open source and proprietary drivers.

As I have told before, netconsole does not show anything suspicious.

I cannot tell if SysRq would work because my laptop hasn't got a SysRq key.

I wonder if Gallium Mesa libs could, in a way, do these things. By the 
way, they work fine on 2.6.39...

The machine on which that happens is Thinkpad Edge 13, AMD model, BIOS 
v1.12, AMD RS780 (Radeon HD3200). What else do I need to supply? What 
debugging options to turn on?

I'm completely lost here and feel like a complete idiot.

Next I'm going to nuke my Gallium Mesa libraries and try to boot without 
them, but it's interesting anyway if anyone got similar symptoms.

[PATCH] drm/radeon/kms: be more pendatic about the g5 quirk

[Michel Dänzer]

On Die, 2011-06-14 at 11:22 -0400, Alex Deucher wrote: 
> I don't think Apple offered any other cards for
> this mac, so I doubt this will be an issue, but just
> to be on the safe side, check the pci ids as well.
> 
> Signed-off-by: Alex Deucher 
> Cc: Joachim Henke 
> Cc: Michel D?nzer 
> ---
>  drivers/gpu/drm/radeon/radeon_combios.c |9 ++---
>  1 files changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_combios.c 
> b/drivers/gpu/drm/radeon/radeon_combios.c
> index 797c8bc..e459467 100644
> --- a/drivers/gpu/drm/radeon/radeon_combios.c
> +++ b/drivers/gpu/drm/radeon/radeon_combios.c
> @@ -1553,9 +1553,12 @@ bool 
> radeon_get_legacy_connector_info_from_table(struct drm_device *dev)
>  (rdev->pdev->subsystem_device == 0x4a48)) {
>   /* Mac X800 */
>   rdev->mode_info.connector_table = CT_MAC_X800;
> - } else if (of_machine_is_compatible("PowerMac7,2") ||
> -of_machine_is_compatible("PowerMac7,3")) {
> - /* Mac G5 9600 */
> + } else if ((of_machine_is_compatible("PowerMac7,2") ||
> + of_machine_is_compatible("PowerMac7,3")) &&
> +(rdev->pdev->device == 0x4150) &&
> +(rdev->pdev->subsystem_vendor == 0x1002) &&
> +(rdev->pdev->subsystem_device == 0x4150)) {
> + /* Mac G5 tower 9600 */
>   rdev->mode_info.connector_table = CT_MAC_G5_9600;
>   } else
>  #endif /* CONFIG_PPC_PMAC */

Reviewed-by: Michel D?nzer 

Thanks!


-- 
Earthling Michel D?nzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer

[Bug 38270] Color Tiling unusable on NI

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

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

--- Comment #10 from Aidan Marks  2011-06-14 17:01:39 PDT 
---
pulling latest mesa/libdrm/ddx again still has the corruption with color tiling
on with r600c.  I tried r600g and the corruption is not seen.

-- 
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: fix dac detect stealing in-use encoder.

[Dave Airlie]

From: Dave Airlie 

On my RS690 the VGA and TV-out share the same DAC, so when xrandr
is called, tv-out steals the encoder and tries to load detect on it,
however this causes flicker on the VGA.

This blocks this by testing if the encoder is connected to anything
and if so whether its connected to the probing connector.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/radeon/radeon_encoders.c |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c 
b/drivers/gpu/drm/radeon/radeon_encoders.c
index 03f124d..eb07e74 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -1971,6 +1971,18 @@ radeon_atom_dac_detect(struct drm_encoder *encoder, 
struct drm_connector *connec
struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
struct radeon_connector *radeon_connector = 
to_radeon_connector(connector);
uint32_t bios_0_scratch;
+   struct drm_connector *test_connector;
+
+   /*
+* if we are passed a connector and it doesn't match what the encoder
+* is connected to do, don't do load detect as it might cause flicker.
+*/
+list_for_each_entry(test_connector, >mode_config.connector_list, 
head) {
+if ((test_connector->encoder == encoder) && (test_connector != 
connector)) {
+   DRM_DEBUG_KMS("load detect failed: encoder in use\n");
+   return connector_status_disconnected;
+   }
+   }

if (!atombios_dac_load_detect(encoder, connector)) {
DRM_DEBUG_KMS("detect returned false \n");
-- 
1.7.5.2

[PATCH 2/3] drm/radeon: workaround a hw bug on some radeon chipsets with all-0 EDIDs.

[Dave Airlie]

From: Dave Airlie 

Some RS690 chipsets seem to end up with floating connectors, either
a DVI connector isn't actually populated, or an add-in HDMI card
is available but not installed. In this case we seem to get a NULL byte
response for each byte of the i2c transaction, so we detect this
case and if we see it we don't do anymore DDC transactions on this
connector.

I've tested this on my RS690 without the HDMI card installed and
it seems to work fine.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_edid.c |   15 +++
 drivers/gpu/drm/radeon/radeon_connectors.c |7 +++
 include/drm/drm_crtc.h |2 ++
 3 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 3618d29..0929219 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -258,6 +258,17 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
unsigned char *buf,
return ret == 2 ? 0 : -1;
 }

+static bool drm_edid_is_zero(u8 *in_edid, int length)
+{
+   int i;
+   u32 *raw_edid = (u32 *)in_edid;
+
+   for (i = 0; i < length / 4; i++)
+   if (*(raw_edid + i) != 0)
+   return false;
+   return true;
+}
+
 static u8 *
 drm_do_get_edid(struct drm_connector *connector, struct i2c_adapter *adapter)
 {
@@ -273,6 +284,10 @@ drm_do_get_edid(struct drm_connector *connector, struct 
i2c_adapter *adapter)
goto out;
if (drm_edid_block_valid(block))
break;
+   if (i == 0 && drm_edid_is_zero(block, EDID_LENGTH)) {
+   connector->null_edid_counter++;
+   goto carp;
+   }
}
if (i == 4)
goto carp;
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 9c2929c..5c3393f 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -836,6 +836,13 @@ radeon_dvi_detect(struct drm_connector *connector, bool 
force)
if (!radeon_connector->edid) {
DRM_ERROR("%s: probed a monitor but no|invalid EDID\n",
drm_get_connector_name(connector));
+   /* rs690 seems to have a problem with connectors not 
existing and always
+* return a block of 0's. If we see this just stop 
polling on this output */
+   if ((rdev->family == CHIP_RS690) && 
radeon_connector->base.null_edid_counter) {
+   ret = connector_status_disconnected;
+   DRM_ERROR("%s: detected RS690 floating bus bug, 
stopping ddc detect\n", drm_get_connector_name(connector));
+   radeon_connector->ddc_bus = NULL;
+   }
} else {
radeon_connector->use_digital = 
!!(radeon_connector->edid->input & DRM_EDID_INPUT_DIGITAL);

diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 9573e0c..33d12f8 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -520,6 +520,8 @@ struct drm_connector {
uint32_t encoder_ids[DRM_CONNECTOR_MAX_ENCODER];
uint32_t force_encoder_id;
struct drm_encoder *encoder; /* currently active encoder */
+
+   int null_edid_counter; /* needed to workaround some HW bugs where we 
get all 0s */
 };

 /**
-- 
1.7.5.2

[PATCH 1/3] drm: make debug levels match in edid failure code.

[Dave Airlie]

From: Dave Airlie 

this puts the header and followup at the same loglevel as the
hex dump code.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_edid.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 0a9357c..3618d29 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -184,9 +184,9 @@ drm_edid_block_valid(u8 *raw_edid)

 bad:
if (raw_edid) {
-   DRM_ERROR("Raw EDID:\n");
+   printk(KERN_ERR "Raw EDID:\n");
print_hex_dump_bytes(KERN_ERR, DUMP_PREFIX_NONE, raw_edid, 
EDID_LENGTH);
-   printk("\n");
+   printk(KERN_ERR "\n");
}
return 0;
 }
-- 
1.7.5.2

[PATCH] drm/radeon/kms: signed fix for evergreen thermal

[Alex Deucher]

temperature is signed.

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

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index e1b3d99..b06f2db 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -88,7 +88,8 @@ u32 evergreen_page_flip(struct radeon_device *rdev, int 
crtc_id, u64 crtc_base)
 /* get temperature in millidegrees */
 int evergreen_get_temp(struct radeon_device *rdev)
 {
-   u32 temp, toffset, actual_temp = 0;
+   u32 temp, toffset;
+   int actual_temp = 0;

if (rdev->family == CHIP_JUNIPER) {
toffset = (RREG32(CG_THERMAL_CTRL) & TOFFSET_MASK) >>
-- 
1.7.1.1

[Bug 32511] glDrawPixels broken on savage

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

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

Tormod Volden  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #17 from Tormod Volden  2011-06-14 
14:32:43 PDT ---
Finally fixed in the Linux 3.0 kernel drm:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=66aa6962ff520804f9874e57ea97995153f499d8

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

Revert "drm/i915: Enable GMBUS for post-gen2 chipsets"

[Dave Airlie]

On Sat, Jun 11, 2011 at 10:58 PM, Jean Delvare  wrote:
> Hi Florian,
>
> On Sat, 11 Jun 2011 13:28:15 +0200, Florian Mickler wrote:
>> On Sat, 04 Jun 2011 19:34:56 -
>> Jean Delvare  wrote:
>>
>> > Revert commit 8f9a3f9b63b8cd3f03be9dc53533f90bd4120e5f. This fixes a
>> > hang when loading the eeprom driver (see bug #35572.) GMBUS will be
>> > re-enabled later, differently.
>> >
>> > Signed-off-by: Jean Delvare 
>> > Reported-by: Marek Otahal 
>> > Tested-by: Yermandu Patapitafious 
>> > Tested-by: Andrew Lutomirski 
>> > Acked-by: Chris Wilson 
>> > Cc: David Airlie 
>>
>> is this[1] resolved some other way in the meantime?
>>
>> Regards,
>> Flo
>>
>> [1]: https://bugzilla.kernel.org/show_bug.cgi?id=35572
>
> Not that I know of (and I don't see any other way at least for 2.6.39.)
> This is a shame, really, my revert patch should have been applied
> several days ago already.
>
> Keith, Chris, David, can you please get it rolling? This is a
> regression presumably affecting a lot of users, we should really fix it
> quickly, both in 2.6.39.x and 3.0-rc.

This patch really had no info other than the bug link to tell me wtf its doing,

I actually don't think reverting this is the correct fix, since it looks like
the code path thats screws with the mutex still happens on GEN2 machines
which unlucky for them.

Chris, also I don't see an ack anywhere on the list, only some
discussion in the bug,
I suspect the correct fix is to remove all the offending code instead
of just putting back the piece
of plaster that fell out of the wall.

Dave.

[Bug 38270] Color Tiling unusable on NI

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

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

--- Comment #9 from nizze86 at hotmail.com 2011-06-14 13:29:55 PDT ---
mesa from current git works fine wit color tiling enabled so it seems an old
bug still present in 7.10.2 for cypress/evergreen at least. Still a check for a
recent enough mesa might be a good idea before enabling by default?

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

nouveau Ignoring invalid EDID block 1 xrandr can't change resolution on monitor two (dualdisplay)

[zaverel]

Hello

I tweak drm_edid.c and now that work like before
but i 'm not sure that is safe.

New logs with the tweak

see you

-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: dmesg_log
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110614/445760d9/attachment-0002.txt>
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: xrandr_log
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110614/445760d9/attachment-0002.asc>
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: tweak_drm_edid.c.diff
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110614/445760d9/attachment-0003.txt>
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: Xorg.0.log
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110614/445760d9/attachment-0003.asc>

nouveau Ignoring invalid EDID block 1 xrandr can't change resolution on monitor two (dualdisplay)

[zaverel]

Hello ,

All is fine except i can't change resolution on my second monitor vga
(reported as DVI-I-2 )
(tv in fact) anymore
with my 9400gt.

Now , i'm on :

linux-2.6.39-gentoo-r1
xorg-server-1.10.2
xf86-video-nouveau-0.0.16_pre20110323
libdrm-2.4.25


whatever i valid with xrandr is not really do on my tv
although xrandr say it's good , my tv always report 1202x670 50hz

I tried with and without xorg.conf

My last kernel working is linux-2.6.36-gentoo-r6.

see you.



-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: Xorg.0.log
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110614/d40ff361/attachment-0002.asc>
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: dmesg_log
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110614/d40ff361/attachment-0001.txt>
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: lspci_log
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110614/d40ff361/attachment-0003.asc>
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: xrandr_log
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110614/d40ff361/attachment-0002.txt>

[PATCH] drm/radeon/kms: be more pedantic about the g5 quirk (v2)

[Alex Deucher]

I don't think Apple offered any other cards for
this mac, so I doubt this will be an issue, but just
to be on the safe side, check the pci ids as well.

v2: fix spelling in commit message

Reviewed-by: Michel D?nzer 
Signed-off-by: Alex Deucher 
Cc: Joachim Henke 
Cc: Michel D?nzer 
---
 drivers/gpu/drm/radeon/radeon_combios.c |9 ++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_combios.c 
b/drivers/gpu/drm/radeon/radeon_combios.c
index 797c8bc..e459467 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -1553,9 +1553,12 @@ bool radeon_get_legacy_connector_info_from_table(struct 
drm_device *dev)
   (rdev->pdev->subsystem_device == 0x4a48)) {
/* Mac X800 */
rdev->mode_info.connector_table = CT_MAC_X800;
-   } else if (of_machine_is_compatible("PowerMac7,2") ||
-  of_machine_is_compatible("PowerMac7,3")) {
-   /* Mac G5 9600 */
+   } else if ((of_machine_is_compatible("PowerMac7,2") ||
+   of_machine_is_compatible("PowerMac7,3")) &&
+  (rdev->pdev->device == 0x4150) &&
+  (rdev->pdev->subsystem_vendor == 0x1002) &&
+  (rdev->pdev->subsystem_device == 0x4150)) {
+   /* Mac G5 tower 9600 */
rdev->mode_info.connector_table = CT_MAC_G5_9600;
} else
 #endif /* CONFIG_PPC_PMAC */
-- 
1.7.1.1

[PATCH] drm/radeon/kms: be more pendatic about the g5 quirk

[Alex Deucher]

I don't think Apple offered any other cards for
this mac, so I doubt this will be an issue, but just
to be on the safe side, check the pci ids as well.

Signed-off-by: Alex Deucher 
Cc: Joachim Henke 
Cc: Michel D?nzer 
---
 drivers/gpu/drm/radeon/radeon_combios.c |9 ++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_combios.c 
b/drivers/gpu/drm/radeon/radeon_combios.c
index 797c8bc..e459467 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -1553,9 +1553,12 @@ bool radeon_get_legacy_connector_info_from_table(struct 
drm_device *dev)
   (rdev->pdev->subsystem_device == 0x4a48)) {
/* Mac X800 */
rdev->mode_info.connector_table = CT_MAC_X800;
-   } else if (of_machine_is_compatible("PowerMac7,2") ||
-  of_machine_is_compatible("PowerMac7,3")) {
-   /* Mac G5 9600 */
+   } else if ((of_machine_is_compatible("PowerMac7,2") ||
+   of_machine_is_compatible("PowerMac7,3")) &&
+  (rdev->pdev->device == 0x4150) &&
+  (rdev->pdev->subsystem_vendor == 0x1002) &&
+  (rdev->pdev->subsystem_device == 0x4150)) {
+   /* Mac G5 tower 9600 */
rdev->mode_info.connector_table = CT_MAC_G5_9600;
} else
 #endif /* CONFIG_PPC_PMAC */
-- 
1.7.1.1

[Bug 32402] Oops associated with radeon_unpin_work_func

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

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


Florian Mickler  changed:

   What|Removed |Added

 CC||florian at mickler.org




--- Comment #19 from Florian Mickler   2011-06-14 
11:21:05 ---
A patch referencing this bug report has been merged in v3.0-rc3:

commit 498c555f56a02ec1059bc150cde84411ba0ac010
Author: Dave Airlie 
Date:   Sun May 29 17:48:32 2011 +1000

drm/radeon: fix oops in ttm reserve when pageflipping (v2)

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

[Bug 38280] [bisected] regression : etqw tree/water wrong rendering

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

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

--- Comment #4 from Vadim  2011-06-14 10:44:29 PDT ---
Created an attachment (id=47965)
 View: https://bugs.freedesktop.org/attachment.cgi?id=47965
 Review: https://bugs.freedesktop.org/review?bug=38280=47965

patch

This patch should restore previous behaviour for r600 hw.

-- 
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] alpha, drm: Add Alpha support to Radeon DRM code

[Dave Airlie]

On Fri, Jun 10, 2011 at 8:20 AM, Jay Estabrook  
wrote:
>
> Alpha needs to have the system bus address for the device's local
> memory available, so that it can be returned to user-level, where
> it may be used in an mmap(). So, we make bus.addr hold the ioremap()
> return for kernel use, and then we can modify bus.base appropriately.
>

I don't get this. why is mmap passing in an address? we don't do that anymore.

When you mmap the device node it passes back a hashed offset in the
table, that the
kernel then translates into a proper address and sets up the page tables.

So I really don't get what this patch is doing, either the
explaination of what it is doing is wrong
or it is wrong.

Dave.

[Bug 36523] water reflections misrendered in sauerbraten with "shaders=high" setting

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

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

--- Comment #4 from Sven Arvidsson  2011-06-14 09:34:03 PDT ---
This seems to be fixed with current git master, can you confirm?

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

[PATCH] drm/radeon/kms: set dma_copy to NULL for r6xx+

[Dave Airlie]

On Tue, Jun 14, 2011 at 7:33 AM, Alex Deucher  wrote:
> No need to assign the same copy callback for both
> copy blit and dma.

This used to confuse the benchmark code if memory serves, if thats
fixed then I'm okay with this.

Dave.

[PATCH] drm/radeon/kms: fix mac g5 quirk

[Michel Dänzer]

On Die, 2011-06-14 at 02:48 -0400, Alex Deucher wrote: 
> 2011/6/14 Michel D?nzer :
> > On Mon, 2011-06-06 at 12:53 -0400, Alex Deucher wrote:
> >> Apple uses the same subsystem pci ids for lots of
> >> hardware much of which is wired up differently.  In
> >> this case, the G5 imac and the G5 tower.
> >>
> >> Only apply the quirk configuration to G5 towers.
> >>
> >> Reported-by: Joachim Henke 
> >> Signed-off-by: Alex Deucher 
> >> Cc: Joachim Henke 
> >> Cc: Michel D?nzer 
> >> ---
> >>  drivers/gpu/drm/radeon/radeon_combios.c |5 ++---
> >>  1 files changed, 2 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/radeon/radeon_combios.c 
> >> b/drivers/gpu/drm/radeon/radeon_combios.c
> >> index 5b991f7..19b10cf 100644
> >> --- a/drivers/gpu/drm/radeon/radeon_combios.c
> >> +++ b/drivers/gpu/drm/radeon/radeon_combios.c
> >> @@ -1548,9 +1548,8 @@ bool 
> >> radeon_get_legacy_connector_info_from_table(struct drm_device *dev)
> >>  (rdev->pdev->subsystem_device == 0x4a48)) {
> >>   /* Mac X800 */
> >>   rdev->mode_info.connector_table = CT_MAC_X800;
> >> - } else if ((rdev->pdev->device == 0x4150) &&
> >> -(rdev->pdev->subsystem_vendor == 0x1002) &&
> >> -(rdev->pdev->subsystem_device == 0x4150)) {
> >> + } else if (of_machine_is_compatible("PowerMac7,2") ||
> >> +of_machine_is_compatible("PowerMac7,3")) {
> >>   /* Mac G5 9600 */
> >>   rdev->mode_info.connector_table = CT_MAC_G5_9600;
> >>   } else
> >
> > I think this still needs to check the PCI IDs as well, or it would break
> > different cards in these machines?
> 
> I don't know which (if any) other cards apple offered for these
> machines.  I suppose it wouldn't hurt, but OTOH, if this card is all
> that was offered, it's probably not that big a deal as it would be
> unlikely that another card with a mac vbios would show up in one.
> Cards with an x86 vbios won't hit this path.

Ah right, I didn't think of that, and it looks like the X800 is already
covered as well. Still, as you say, it probably wouldn't hurt. :)


-- 
Earthling Michel D?nzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer

[PATCH] drm/radeon/kms: fix mac g5 quirk

[Michel Dänzer]

On Mon, 2011-06-06 at 12:53 -0400, Alex Deucher wrote: 
> Apple uses the same subsystem pci ids for lots of
> hardware much of which is wired up differently.  In
> this case, the G5 imac and the G5 tower.
> 
> Only apply the quirk configuration to G5 towers.
> 
> Reported-by: Joachim Henke 
> Signed-off-by: Alex Deucher 
> Cc: Joachim Henke 
> Cc: Michel D?nzer 
> ---
>  drivers/gpu/drm/radeon/radeon_combios.c |5 ++---
>  1 files changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_combios.c 
> b/drivers/gpu/drm/radeon/radeon_combios.c
> index 5b991f7..19b10cf 100644
> --- a/drivers/gpu/drm/radeon/radeon_combios.c
> +++ b/drivers/gpu/drm/radeon/radeon_combios.c
> @@ -1548,9 +1548,8 @@ bool radeon_get_legacy_connector_info_from_table(struct 
> drm_device *dev)
>  (rdev->pdev->subsystem_device == 0x4a48)) {
>   /* Mac X800 */
>   rdev->mode_info.connector_table = CT_MAC_X800;
> - } else if ((rdev->pdev->device == 0x4150) &&
> -(rdev->pdev->subsystem_vendor == 0x1002) &&
> -(rdev->pdev->subsystem_device == 0x4150)) {
> + } else if (of_machine_is_compatible("PowerMac7,2") ||
> +of_machine_is_compatible("PowerMac7,3")) {
>   /* Mac G5 9600 */
>   rdev->mode_info.connector_table = CT_MAC_G5_9600;
>   } else

I think this still needs to check the PCI IDs as well, or it would break
different cards in these machines?


-- 
Earthling Michel D?nzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer

[Bug 38280] [bisected] regression : etqw tree/water wrong rendering

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

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

--- Comment #3 from Andy Furniss  2011-06-14 
05:54:32 PDT ---
(In reply to comment #2)

> I wonder if this means that the same commit broke rendering in Doom3 on
> non-Evergreen hardware?

Yes. with current master on 4890 there is no distortion behind glass, there is
with 9346d895e7ff6c1f01b46513694542026ffba5cc reverted.

Also see the same regression as the OP in etqw.

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

[Bug 36917] Rendering glitches in ETQW

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

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

--- Comment #3 from Sven Arvidsson  2011-06-14 05:16:54 PDT ---
Rendering of trees (and water) is fixed on master, but broken on non-evergreen,
see bug 38280.

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

[Bug 38280] [bisected] regression : etqw tree/water wrong rendering

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

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

Sven Arvidsson  changed:

   What|Removed |Added

 CC||sa at whiz.se

--- Comment #2 from Sven Arvidsson  2011-06-14 05:15:19 PDT ---
Interesting, I get the opposite behaviour on my HD5670. 

Rendering of trees and water is fixed with commit 9346d89, otherwise broken in
the same way as in your screenshot.

I wonder if this means that the same commit broke rendering in Doom3 on
non-Evergreen hardware?

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

[Bug 36421] RV710: GPU lockup running portal2 in wine.

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

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

--- Comment #7 from Sven Arvidsson  2011-06-14 04:59:18 PDT ---
The hangs in Team Fortress 2 and Left 4 Dead has been fixed on git master now,
can you retest?

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

[git pull] drm fixes

[Dave Airlie]

Hi Linus,

nothing too interesting here, a couple of unusual ones for my tree, the 
x86/uv/x2apic change was due to change in the VGA ARB in my -rc1 pull, 
Ingo and Jesse agreed it should go via the same tree that broke it. I've 
picked up one i915 change due to Keith being away, the rest are fairly 
scattered with fix for savage DRI (drm core map change) that is a few 
kernels old now and a couple of alpha changes.

Dave.

The following changes since commit 06e86849cf4019945a106913adb9ff0abcc01770:

  Merge branch 'pm-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/suspend-2.6 (2011-06-08 
15:58:51 -0700)

are available in the git repository at:

  ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes

Alex Deucher (2):
  drm/radeon/kms: check modes against max pixel clock
  drm/radeon/kms: fix mac g5 quirk

Dave Airlie (1):
  x86/uv/x2apic: update for change in pci bridge handling.

Greg Dietsche (1):
  savage: remove unnecessary if statement

Ilija Hadzic (1):
  drm/radeon: fix GUI idle IH debug statements

Jay Estabrook (2):
  alpha/drm: Cleanup Alpha support in DRM generic code
  alpha, drm: Remove obsolete Alpha support in MGA DRM code

Jesper Juhl (1):
  drm/i915: Don't leak in i915_gem_shmem_pread_slow()

Marek Ol??k (1):
  drm/radeon/kms: do bounds checking for 3D_LOAD_VBPNTR and bump array limit

Sascha Hauer (1):
  drm: fix fbs in DRM_IOCTL_MODE_GETRESOURCES ioctl

Tormod Volden (1):
  drm: Compare only lower 32 bits of framebuffer map offsets

 arch/x86/kernel/apic/x2apic_uv_x.c |8 
 drivers/gpu/drm/drm_bufs.c |   17 +
 drivers/gpu/drm/drm_crtc.c |2 +-
 drivers/gpu/drm/drm_vm.c   |2 +-
 drivers/gpu/drm/i915/i915_gem.c|6 --
 drivers/gpu/drm/mga/mga_drv.h  |   19 ---
 drivers/gpu/drm/radeon/evergreen.c |2 +-
 drivers/gpu/drm/radeon/r100_track.h|8 +++-
 drivers/gpu/drm/radeon/r600.c  |2 +-
 drivers/gpu/drm/radeon/radeon.h|1 +
 drivers/gpu/drm/radeon/radeon_atombios.c   |4 
 drivers/gpu/drm/radeon/radeon_clocks.c |8 +---
 drivers/gpu/drm/radeon/radeon_combios.c|   10 +++---
 drivers/gpu/drm/radeon/radeon_connectors.c |   13 -
 drivers/gpu/drm/savage/savage_bci.c|3 ---
 drivers/pci/pci.c  |4 ++--
 16 files changed, 59 insertions(+), 50 deletions(-)

[Bug 38270] Color Tiling unusable on NI

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

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

--- Comment #8 from nizze86 at hotmail.com 2011-06-14 03:59:54 PDT ---
Created an attachment (id=47951)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=47951)
SuperTuxKart with color tiling, r600g hd5850

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

[Bug 38270] Color Tiling unusable on NI

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

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

--- Comment #7 from nizze86 at hotmail.com 2011-06-14 03:58:09 PDT ---
I get corruption with color tiling turned on too.
My system is up to date debian sid linux 2.6.39/ddx 6.14.2/mesa 7.10.2
with a 5850 using r600g. Attaching a screenshot of stk with color tiling
enabled.

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

[3.0.0-rc2+][nouveau] BUG: unable to handle kernel NULL pointer dereference nv50_vm_map_sg+0x37/0xb0

[Jan Seiffert]

2011/6/13 Rui Tiago Ca??o Matos :
> Looks suspiciously like
> https://bugzilla.redhat.com/show_bug.cgi?id=699551 which has been
> happening since at least 2.6.38.
>

Yes, the backtrace looks very similar, but i can not reproduce with
the reproducer image attached to the bugreport.
(Tried with Gwenview and eog).
I don't know how to reproduce at all, all i did was to scroll through
a PDF, but did so for hours before the crash...

> Rui
>

Greetings
Jan

[PATCH] drm/radeon/kms: fix mac g5 quirk

[Alex Deucher]

2011/6/14 Michel D?nzer :
> On Mon, 2011-06-06 at 12:53 -0400, Alex Deucher wrote:
>> Apple uses the same subsystem pci ids for lots of
>> hardware much of which is wired up differently. ?In
>> this case, the G5 imac and the G5 tower.
>>
>> Only apply the quirk configuration to G5 towers.
>>
>> Reported-by: Joachim Henke 
>> Signed-off-by: Alex Deucher 
>> Cc: Joachim Henke 
>> Cc: Michel D?nzer 
>> ---
>> ?drivers/gpu/drm/radeon/radeon_combios.c | ? ?5 ++---
>> ?1 files changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_combios.c 
>> b/drivers/gpu/drm/radeon/radeon_combios.c
>> index 5b991f7..19b10cf 100644
>> --- a/drivers/gpu/drm/radeon/radeon_combios.c
>> +++ b/drivers/gpu/drm/radeon/radeon_combios.c
>> @@ -1548,9 +1548,8 @@ bool 
>> radeon_get_legacy_connector_info_from_table(struct drm_device *dev)
>> ? ? ? ? ? ? ? ? ? ? ? ? ?(rdev->pdev->subsystem_device == 0x4a48)) {
>> ? ? ? ? ? ? ? ? ? ? ? /* Mac X800 */
>> ? ? ? ? ? ? ? ? ? ? ? rdev->mode_info.connector_table = CT_MAC_X800;
>> - ? ? ? ? ? ? } else if ((rdev->pdev->device == 0x4150) &&
>> - ? ? ? ? ? ? ? ? ? ? ? ?(rdev->pdev->subsystem_vendor == 0x1002) &&
>> - ? ? ? ? ? ? ? ? ? ? ? ?(rdev->pdev->subsystem_device == 0x4150)) {
>> + ? ? ? ? ? ? } else if (of_machine_is_compatible("PowerMac7,2") ||
>> + ? ? ? ? ? ? ? ? ? ? ? ?of_machine_is_compatible("PowerMac7,3")) {
>> ? ? ? ? ? ? ? ? ? ? ? /* Mac G5 9600 */
>> ? ? ? ? ? ? ? ? ? ? ? rdev->mode_info.connector_table = CT_MAC_G5_9600;
>> ? ? ? ? ? ? ? } else
>
> I think this still needs to check the PCI IDs as well, or it would break
> different cards in these machines?

I don't know which (if any) other cards apple offered for these
machines.  I suppose it wouldn't hurt, but OTOH, if this card is all
that was offered, it's probably not that big a deal as it would be
unlikely that another card with a mac vbios would show up in one.
Cards with an x86 vbios won't hit this path.

Alex

[PATCH 3/3] drm/radeon/kms: fix dac detect stealing in-use encoder.

[Alex Deucher]

On Tue, Jun 14, 2011 at 2:13 AM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> On my RS690 the VGA and TV-out share the same DAC, so when xrandr
> is called, tv-out steals the encoder and tries to load detect on it,
> however this causes flicker on the VGA.
>
> This blocks this by testing if the encoder is connected to anything
> and if so whether its connected to the probing connector.

Could we get into a case where we fail to run load detect on both
connectors due to this check?

Alex

[PATCH 2/3] drm/radeon: workaround a hw bug on some radeon chipsets with all-0 EDIDs.

[Alex Deucher]

On Tue, Jun 14, 2011 at 2:13 AM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> Some RS690 chipsets seem to end up with floating connectors, either
> a DVI connector isn't actually populated, or an add-in HDMI card
> is available but not installed. In this case we seem to get a NULL byte
> response for each byte of the i2c transaction, so we detect this
> case and if we see it we don't do anymore DDC transactions on this
> connector.
>
> I've tested this on my RS690 without the HDMI card installed and
> it seems to work fine.
>
> Signed-off-by: Dave Airlie 

Just one comment below, but other than that:

Reviewed-by: Alex Deucher 

> ---
> ?drivers/gpu/drm/drm_edid.c ? ? ? ? ? ? ? ? | ? 15 +++
> ?drivers/gpu/drm/radeon/radeon_connectors.c | ? ?7 +++
> ?include/drm/drm_crtc.h ? ? ? ? ? ? ? ? ? ? | ? ?2 ++
> ?3 files changed, 24 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 3618d29..0929219 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -258,6 +258,17 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
> unsigned char *buf,
> ? ? ? ?return ret == 2 ? 0 : -1;
> ?}
>
> +static bool drm_edid_is_zero(u8 *in_edid, int length)
> +{
> + ? ? ? int i;
> + ? ? ? u32 *raw_edid = (u32 *)in_edid;
> +
> + ? ? ? for (i = 0; i < length / 4; i++)
> + ? ? ? ? ? ? ? if (*(raw_edid + i) != 0)
> + ? ? ? ? ? ? ? ? ? ? ? return false;
> + ? ? ? return true;
> +}
> +
> ?static u8 *
> ?drm_do_get_edid(struct drm_connector *connector, struct i2c_adapter *adapter)
> ?{
> @@ -273,6 +284,10 @@ drm_do_get_edid(struct drm_connector *connector, struct 
> i2c_adapter *adapter)
> ? ? ? ? ? ? ? ? ? ? ? ?goto out;
> ? ? ? ? ? ? ? ?if (drm_edid_block_valid(block))
> ? ? ? ? ? ? ? ? ? ? ? ?break;
> + ? ? ? ? ? ? ? if (i == 0 && drm_edid_is_zero(block, EDID_LENGTH)) {
> + ? ? ? ? ? ? ? ? ? ? ? connector->null_edid_counter++;
> + ? ? ? ? ? ? ? ? ? ? ? goto carp;
> + ? ? ? ? ? ? ? }
> ? ? ? ?}
> ? ? ? ?if (i == 4)
> ? ? ? ? ? ? ? ?goto carp;
> diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
> b/drivers/gpu/drm/radeon/radeon_connectors.c
> index 9c2929c..5c3393f 100644
> --- a/drivers/gpu/drm/radeon/radeon_connectors.c
> +++ b/drivers/gpu/drm/radeon/radeon_connectors.c
> @@ -836,6 +836,13 @@ radeon_dvi_detect(struct drm_connector *connector, bool 
> force)
> ? ? ? ? ? ? ? ?if (!radeon_connector->edid) {
> ? ? ? ? ? ? ? ? ? ? ? ?DRM_ERROR("%s: probed a monitor but no|invalid EDID\n",
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?drm_get_connector_name(connector));
> + ? ? ? ? ? ? ? ? ? ? ? /* rs690 seems to have a problem with connectors not 
> existing and always
> + ? ? ? ? ? ? ? ? ? ? ? ?* return a block of 0's. If we see this just stop 
> polling on this output */
> + ? ? ? ? ? ? ? ? ? ? ? if ((rdev->family == CHIP_RS690) && 
> radeon_connector->base.null_edid_counter) {

You may want to extend this to RS740 as well since IIRC they were pin
compatible with RS690 and showed up in a lot of similar setups.

> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ret = connector_status_disconnected;
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? DRM_ERROR("%s: detected RS690 floating bus 
> bug, stopping ddc detect\n", drm_get_connector_name(connector));
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? radeon_connector->ddc_bus = NULL;
> + ? ? ? ? ? ? ? ? ? ? ? }
> ? ? ? ? ? ? ? ?} else {
> ? ? ? ? ? ? ? ? ? ? ? ?radeon_connector->use_digital = 
> !!(radeon_connector->edid->input & DRM_EDID_INPUT_DIGITAL);
>
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 9573e0c..33d12f8 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -520,6 +520,8 @@ struct drm_connector {
> ? ? ? ?uint32_t encoder_ids[DRM_CONNECTOR_MAX_ENCODER];
> ? ? ? ?uint32_t force_encoder_id;
> ? ? ? ?struct drm_encoder *encoder; /* currently active encoder */
> +
> + ? ? ? int null_edid_counter; /* needed to workaround some HW bugs where we 
> get all 0s */
> ?};
>
> ?/**
> --
> 1.7.5.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[PATCH 1/3] drm: make debug levels match in edid failure code.

[Alex Deucher]

On Tue, Jun 14, 2011 at 2:13 AM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> this puts the header and followup at the same loglevel as the
> hex dump code.
>
> Signed-off-by: Dave Airlie 

Reviewed-by: Alex Deucher 

> ---
> ?drivers/gpu/drm/drm_edid.c | ? ?4 ++--
> ?1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 0a9357c..3618d29 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -184,9 +184,9 @@ drm_edid_block_valid(u8 *raw_edid)
>
> ?bad:
> ? ? ? ?if (raw_edid) {
> - ? ? ? ? ? ? ? DRM_ERROR("Raw EDID:\n");
> + ? ? ? ? ? ? ? printk(KERN_ERR "Raw EDID:\n");
> ? ? ? ? ? ? ? ?print_hex_dump_bytes(KERN_ERR, DUMP_PREFIX_NONE, raw_edid, 
> EDID_LENGTH);
> - ? ? ? ? ? ? ? printk("\n");
> + ? ? ? ? ? ? ? printk(KERN_ERR "\n");
> ? ? ? ?}
> ? ? ? ?return 0;
> ?}
> --
> 1.7.5.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[Bug 38270] Color Tiling unusable on NI

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

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

--- Comment #6 from Aidan Marks  2011-06-14 01:28:20 PDT ---
(In reply to comment #4)
> What 3D driver are you using?  r600g or r600c?  Are you using a compositor or
> not?

vanilla kwin with r600c.

$ glxinfo |grep OpenGL
OpenGL vendor string: Advanced Micro Devices, Inc.
OpenGL renderer string: Mesa DRI R600 (BARTS 6738)  TCL DRI2
OpenGL version string: 2.1 Mesa 7.11-devel (git-a128355)
OpenGL shading language version string: 1.20
OpenGL extensions:

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

[Bug 38270] Color Tiling unusable on NI

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

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

--- Comment #5 from Aidan Marks  2011-06-14 01:26:38 PDT ---
Created an attachment (id=47925)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=47925)
dmesg

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

[Bug 38280] [bisected] regression : etqw tree/water wrong rendering

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

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

Pierre-Eric Pelloux-Prayer  changed:

   What|Removed |Added

  Component|Drivers/DRI/R600|Drivers/Gallium/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 38280] [bisected] regression : etqw tree/water wrong rendering

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

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

--- Comment #1 from Pierre-Eric Pelloux-Prayer  
2011-06-14 00:57:56 PDT ---
Created an attachment (id=47924)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=47924)
correct rendering for comparison

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

[Bug 38280] New: [bisected] regression : etqw tree/water wrong rendering

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

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

   Summary: [bisected] regression : etqw tree/water wrong
rendering
   Product: Mesa
   Version: git
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/R600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: pelloux at gmail.com


Created an attachment (id=47923)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=47923)
incorrect rendering

commit 9346d895e7ff6c1f01b46513694542026ffba5cc broke tree and water rendering
in etqw (Island map)
See attached screenshots.

I'm using r600g + HD4850

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

[PATCH] drm/radeon/kms: set dma_copy to NULL for r6xx+

[Alex Deucher]

On Mon, Jun 13, 2011 at 7:27 PM, Dave Airlie  wrote:
> On Tue, Jun 14, 2011 at 7:33 AM, Alex Deucher  
> wrote:
>> No need to assign the same copy callback for both
>> copy blit and dma.
>
> This used to confuse the benchmark code if memory serves, if thats
> fixed then I'm okay with this.
>

The benchmark code checks if the copy_dma function pointer is valid
before attempting to use it.

Alex

> Dave.
>

[Bug 37442] Radeon 9600 Mobile (RV350) freezes on glxgears - bisected

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

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





--- Comment #3 from Dave Airlie   2011-06-13 23:40:48 ---
for the KMS case not working I suspect the radeon module isn't getting loaded
early enough by the distro so ends up loading when X does and you get sw
rendering. You should fix that, I'll see if I can work out whats wrong with the
other case, though UMS is a bit lower on my priority lists.

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

[PATCH 1/3] drm: make debug levels match in edid failure code.

[Dave Airlie]

From: Dave Airlie airl...@linux.ie

this puts the header and followup at the same loglevel as the
hex dump code.

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

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 0a9357c..3618d29 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -184,9 +184,9 @@ drm_edid_block_valid(u8 *raw_edid)
 
 bad:
if (raw_edid) {
-   DRM_ERROR(Raw EDID:\n);
+   printk(KERN_ERR Raw EDID:\n);
print_hex_dump_bytes(KERN_ERR, DUMP_PREFIX_NONE, raw_edid, 
EDID_LENGTH);
-   printk(\n);
+   printk(KERN_ERR \n);
}
return 0;
 }
-- 
1.7.5.2

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

[PATCH 2/3] drm/radeon: workaround a hw bug on some radeon chipsets with all-0 EDIDs.

[Dave Airlie]

From: Dave Airlie airl...@linux.ie

Some RS690 chipsets seem to end up with floating connectors, either
a DVI connector isn't actually populated, or an add-in HDMI card
is available but not installed. In this case we seem to get a NULL byte
response for each byte of the i2c transaction, so we detect this
case and if we see it we don't do anymore DDC transactions on this
connector.

I've tested this on my RS690 without the HDMI card installed and
it seems to work fine.

Signed-off-by: Dave Airlie airl...@redhat.com
---
 drivers/gpu/drm/drm_edid.c |   15 +++
 drivers/gpu/drm/radeon/radeon_connectors.c |7 +++
 include/drm/drm_crtc.h |2 ++
 3 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 3618d29..0929219 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -258,6 +258,17 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
unsigned char *buf,
return ret == 2 ? 0 : -1;
 }
 
+static bool drm_edid_is_zero(u8 *in_edid, int length)
+{
+   int i;
+   u32 *raw_edid = (u32 *)in_edid;
+
+   for (i = 0; i  length / 4; i++)
+   if (*(raw_edid + i) != 0)
+   return false;
+   return true;
+}
+
 static u8 *
 drm_do_get_edid(struct drm_connector *connector, struct i2c_adapter *adapter)
 {
@@ -273,6 +284,10 @@ drm_do_get_edid(struct drm_connector *connector, struct 
i2c_adapter *adapter)
goto out;
if (drm_edid_block_valid(block))
break;
+   if (i == 0  drm_edid_is_zero(block, EDID_LENGTH)) {
+   connector-null_edid_counter++;
+   goto carp;
+   }
}
if (i == 4)
goto carp;
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 9c2929c..5c3393f 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -836,6 +836,13 @@ radeon_dvi_detect(struct drm_connector *connector, bool 
force)
if (!radeon_connector-edid) {
DRM_ERROR(%s: probed a monitor but no|invalid EDID\n,
drm_get_connector_name(connector));
+   /* rs690 seems to have a problem with connectors not 
existing and always
+* return a block of 0's. If we see this just stop 
polling on this output */
+   if ((rdev-family == CHIP_RS690)  
radeon_connector-base.null_edid_counter) {
+   ret = connector_status_disconnected;
+   DRM_ERROR(%s: detected RS690 floating bus bug, 
stopping ddc detect\n, drm_get_connector_name(connector));
+   radeon_connector-ddc_bus = NULL;
+   }
} else {
radeon_connector-use_digital = 
!!(radeon_connector-edid-input  DRM_EDID_INPUT_DIGITAL);
 
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 9573e0c..33d12f8 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -520,6 +520,8 @@ struct drm_connector {
uint32_t encoder_ids[DRM_CONNECTOR_MAX_ENCODER];
uint32_t force_encoder_id;
struct drm_encoder *encoder; /* currently active encoder */
+
+   int null_edid_counter; /* needed to workaround some HW bugs where we 
get all 0s */
 };
 
 /**
-- 
1.7.5.2

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

[PATCH 3/3] drm/radeon/kms: fix dac detect stealing in-use encoder.

[Dave Airlie]

From: Dave Airlie airl...@linux.ie

On my RS690 the VGA and TV-out share the same DAC, so when xrandr
is called, tv-out steals the encoder and tries to load detect on it,
however this causes flicker on the VGA.

This blocks this by testing if the encoder is connected to anything
and if so whether its connected to the probing connector.

Signed-off-by: Dave Airlie airl...@redhat.com
---
 drivers/gpu/drm/radeon/radeon_encoders.c |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c 
b/drivers/gpu/drm/radeon/radeon_encoders.c
index 03f124d..eb07e74 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -1971,6 +1971,18 @@ radeon_atom_dac_detect(struct drm_encoder *encoder, 
struct drm_connector *connec
struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
struct radeon_connector *radeon_connector = 
to_radeon_connector(connector);
uint32_t bios_0_scratch;
+   struct drm_connector *test_connector;
+
+   /*
+* if we are passed a connector and it doesn't match what the encoder
+* is connected to do, don't do load detect as it might cause flicker.
+*/
+list_for_each_entry(test_connector, dev-mode_config.connector_list, 
head) {
+if ((test_connector-encoder == encoder)  (test_connector != 
connector)) {
+   DRM_DEBUG_KMS(load detect failed: encoder in use\n);
+   return connector_status_disconnected;
+   }
+   }
 
if (!atombios_dac_load_detect(encoder, connector)) {
DRM_DEBUG_KMS(detect returned false \n);
-- 
1.7.5.2

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

Re: [PATCH 1/3] drm: make debug levels match in edid failure code.

[Alex Deucher]

On Tue, Jun 14, 2011 at 2:13 AM, Dave Airlie airl...@gmail.com wrote:
 From: Dave Airlie airl...@linux.ie

 this puts the header and followup at the same loglevel as the
 hex dump code.

 Signed-off-by: Dave Airlie airl...@redhat.com

Reviewed-by: Alex Deucher alexdeuc...@gmail.com

 ---
  drivers/gpu/drm/drm_edid.c |    4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)

 diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
 index 0a9357c..3618d29 100644
 --- a/drivers/gpu/drm/drm_edid.c
 +++ b/drivers/gpu/drm/drm_edid.c
 @@ -184,9 +184,9 @@ drm_edid_block_valid(u8 *raw_edid)

  bad:
        if (raw_edid) {
 -               DRM_ERROR(Raw EDID:\n);
 +               printk(KERN_ERR Raw EDID:\n);
                print_hex_dump_bytes(KERN_ERR, DUMP_PREFIX_NONE, raw_edid, 
 EDID_LENGTH);
 -               printk(\n);
 +               printk(KERN_ERR \n);
        }
        return 0;
  }
 --
 1.7.5.2

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

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

Re: [PATCH 2/3] drm/radeon: workaround a hw bug on some radeon chipsets with all-0 EDIDs.

[Alex Deucher]

On Tue, Jun 14, 2011 at 2:13 AM, Dave Airlie airl...@gmail.com wrote:
 From: Dave Airlie airl...@linux.ie

 Some RS690 chipsets seem to end up with floating connectors, either
 a DVI connector isn't actually populated, or an add-in HDMI card
 is available but not installed. In this case we seem to get a NULL byte
 response for each byte of the i2c transaction, so we detect this
 case and if we see it we don't do anymore DDC transactions on this
 connector.

 I've tested this on my RS690 without the HDMI card installed and
 it seems to work fine.

 Signed-off-by: Dave Airlie airl...@redhat.com

Just one comment below, but other than that:

Reviewed-by: Alex Deucher alexdeuc...@gmail.com

 ---
  drivers/gpu/drm/drm_edid.c                 |   15 +++
  drivers/gpu/drm/radeon/radeon_connectors.c |    7 +++
  include/drm/drm_crtc.h                     |    2 ++
  3 files changed, 24 insertions(+), 0 deletions(-)

 diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
 index 3618d29..0929219 100644
 --- a/drivers/gpu/drm/drm_edid.c
 +++ b/drivers/gpu/drm/drm_edid.c
 @@ -258,6 +258,17 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
 unsigned char *buf,
        return ret == 2 ? 0 : -1;
  }

 +static bool drm_edid_is_zero(u8 *in_edid, int length)
 +{
 +       int i;
 +       u32 *raw_edid = (u32 *)in_edid;
 +
 +       for (i = 0; i  length / 4; i++)
 +               if (*(raw_edid + i) != 0)
 +                       return false;
 +       return true;
 +}
 +
  static u8 *
  drm_do_get_edid(struct drm_connector *connector, struct i2c_adapter *adapter)
  {
 @@ -273,6 +284,10 @@ drm_do_get_edid(struct drm_connector *connector, struct 
 i2c_adapter *adapter)
                        goto out;
                if (drm_edid_block_valid(block))
                        break;
 +               if (i == 0  drm_edid_is_zero(block, EDID_LENGTH)) {
 +                       connector-null_edid_counter++;
 +                       goto carp;
 +               }
        }
        if (i == 4)
                goto carp;
 diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
 b/drivers/gpu/drm/radeon/radeon_connectors.c
 index 9c2929c..5c3393f 100644
 --- a/drivers/gpu/drm/radeon/radeon_connectors.c
 +++ b/drivers/gpu/drm/radeon/radeon_connectors.c
 @@ -836,6 +836,13 @@ radeon_dvi_detect(struct drm_connector *connector, bool 
 force)
                if (!radeon_connector-edid) {
                        DRM_ERROR(%s: probed a monitor but no|invalid EDID\n,
                                        drm_get_connector_name(connector));
 +                       /* rs690 seems to have a problem with connectors not 
 existing and always
 +                        * return a block of 0's. If we see this just stop 
 polling on this output */
 +                       if ((rdev-family == CHIP_RS690)  
 radeon_connector-base.null_edid_counter) {

You may want to extend this to RS740 as well since IIRC they were pin
compatible with RS690 and showed up in a lot of similar setups.

 +                               ret = connector_status_disconnected;
 +                               DRM_ERROR(%s: detected RS690 floating bus 
 bug, stopping ddc detect\n, drm_get_connector_name(connector));
 +                               radeon_connector-ddc_bus = NULL;
 +                       }
                } else {
                        radeon_connector-use_digital = 
 !!(radeon_connector-edid-input  DRM_EDID_INPUT_DIGITAL);

 diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
 index 9573e0c..33d12f8 100644
 --- a/include/drm/drm_crtc.h
 +++ b/include/drm/drm_crtc.h
 @@ -520,6 +520,8 @@ struct drm_connector {
        uint32_t encoder_ids[DRM_CONNECTOR_MAX_ENCODER];
        uint32_t force_encoder_id;
        struct drm_encoder *encoder; /* currently active encoder */
 +
 +       int null_edid_counter; /* needed to workaround some HW bugs where we 
 get all 0s */
  };

  /**
 --
 1.7.5.2

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

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

Re: [PATCH 3/3] drm/radeon/kms: fix dac detect stealing in-use encoder.

[Alex Deucher]

On Tue, Jun 14, 2011 at 2:13 AM, Dave Airlie airl...@gmail.com wrote:
 From: Dave Airlie airl...@linux.ie

 On my RS690 the VGA and TV-out share the same DAC, so when xrandr
 is called, tv-out steals the encoder and tries to load detect on it,
 however this causes flicker on the VGA.

 This blocks this by testing if the encoder is connected to anything
 and if so whether its connected to the probing connector.

Could we get into a case where we fail to run load detect on both
connectors due to this check?

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

Re: [PATCH] drm/radeon/kms: fix mac g5 quirk

[Michel Dänzer]

On Mon, 2011-06-06 at 12:53 -0400, Alex Deucher wrote: 
 Apple uses the same subsystem pci ids for lots of
 hardware much of which is wired up differently.  In
 this case, the G5 imac and the G5 tower.
 
 Only apply the quirk configuration to G5 towers.
 
 Reported-by: Joachim Henke j...@users.sourceforge.net
 Signed-off-by: Alex Deucher alexdeuc...@gmail.com
 Cc: Joachim Henke j...@users.sourceforge.net
 Cc: Michel Dänzer mic...@daenzer.net
 ---
  drivers/gpu/drm/radeon/radeon_combios.c |5 ++---
  1 files changed, 2 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/gpu/drm/radeon/radeon_combios.c 
 b/drivers/gpu/drm/radeon/radeon_combios.c
 index 5b991f7..19b10cf 100644
 --- a/drivers/gpu/drm/radeon/radeon_combios.c
 +++ b/drivers/gpu/drm/radeon/radeon_combios.c
 @@ -1548,9 +1548,8 @@ bool radeon_get_legacy_connector_info_from_table(struct 
 drm_device *dev)
  (rdev-pdev-subsystem_device == 0x4a48)) {
   /* Mac X800 */
   rdev-mode_info.connector_table = CT_MAC_X800;
 - } else if ((rdev-pdev-device == 0x4150) 
 -(rdev-pdev-subsystem_vendor == 0x1002) 
 -(rdev-pdev-subsystem_device == 0x4150)) {
 + } else if (of_machine_is_compatible(PowerMac7,2) ||
 +of_machine_is_compatible(PowerMac7,3)) {
   /* Mac G5 9600 */
   rdev-mode_info.connector_table = CT_MAC_G5_9600;
   } else

I think this still needs to check the PCI IDs as well, or it would break
different cards in these machines?


-- 
Earthling Michel Dänzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon/kms: fix mac g5 quirk

[Alex Deucher]

2011/6/14 Michel Dänzer mic...@daenzer.net:
 On Mon, 2011-06-06 at 12:53 -0400, Alex Deucher wrote:
 Apple uses the same subsystem pci ids for lots of
 hardware much of which is wired up differently.  In
 this case, the G5 imac and the G5 tower.

 Only apply the quirk configuration to G5 towers.

 Reported-by: Joachim Henke j...@users.sourceforge.net
 Signed-off-by: Alex Deucher alexdeuc...@gmail.com
 Cc: Joachim Henke j...@users.sourceforge.net
 Cc: Michel Dänzer mic...@daenzer.net
 ---
  drivers/gpu/drm/radeon/radeon_combios.c |    5 ++---
  1 files changed, 2 insertions(+), 3 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/radeon_combios.c 
 b/drivers/gpu/drm/radeon/radeon_combios.c
 index 5b991f7..19b10cf 100644
 --- a/drivers/gpu/drm/radeon/radeon_combios.c
 +++ b/drivers/gpu/drm/radeon/radeon_combios.c
 @@ -1548,9 +1548,8 @@ bool 
 radeon_get_legacy_connector_info_from_table(struct drm_device *dev)
                          (rdev-pdev-subsystem_device == 0x4a48)) {
                       /* Mac X800 */
                       rdev-mode_info.connector_table = CT_MAC_X800;
 -             } else if ((rdev-pdev-device == 0x4150) 
 -                        (rdev-pdev-subsystem_vendor == 0x1002) 
 -                        (rdev-pdev-subsystem_device == 0x4150)) {
 +             } else if (of_machine_is_compatible(PowerMac7,2) ||
 +                        of_machine_is_compatible(PowerMac7,3)) {
                       /* Mac G5 9600 */
                       rdev-mode_info.connector_table = CT_MAC_G5_9600;
               } else

 I think this still needs to check the PCI IDs as well, or it would break
 different cards in these machines?

I don't know which (if any) other cards apple offered for these
machines.  I suppose it wouldn't hurt, but OTOH, if this card is all
that was offered, it's probably not that big a deal as it would be
unlikely that another card with a mac vbios would show up in one.
Cards with an x86 vbios won't hit this path.

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

Re: [PATCH] drm/radeon/kms: fix mac g5 quirk

[Michel Dänzer]

On Die, 2011-06-14 at 02:48 -0400, Alex Deucher wrote: 
 2011/6/14 Michel Dänzer mic...@daenzer.net:
  On Mon, 2011-06-06 at 12:53 -0400, Alex Deucher wrote:
  Apple uses the same subsystem pci ids for lots of
  hardware much of which is wired up differently.  In
  this case, the G5 imac and the G5 tower.
 
  Only apply the quirk configuration to G5 towers.
 
  Reported-by: Joachim Henke j...@users.sourceforge.net
  Signed-off-by: Alex Deucher alexdeuc...@gmail.com
  Cc: Joachim Henke j...@users.sourceforge.net
  Cc: Michel Dänzer mic...@daenzer.net
  ---
   drivers/gpu/drm/radeon/radeon_combios.c |5 ++---
   1 files changed, 2 insertions(+), 3 deletions(-)
 
  diff --git a/drivers/gpu/drm/radeon/radeon_combios.c 
  b/drivers/gpu/drm/radeon/radeon_combios.c
  index 5b991f7..19b10cf 100644
  --- a/drivers/gpu/drm/radeon/radeon_combios.c
  +++ b/drivers/gpu/drm/radeon/radeon_combios.c
  @@ -1548,9 +1548,8 @@ bool 
  radeon_get_legacy_connector_info_from_table(struct drm_device *dev)
   (rdev-pdev-subsystem_device == 0x4a48)) {
/* Mac X800 */
rdev-mode_info.connector_table = CT_MAC_X800;
  - } else if ((rdev-pdev-device == 0x4150) 
  -(rdev-pdev-subsystem_vendor == 0x1002) 
  -(rdev-pdev-subsystem_device == 0x4150)) {
  + } else if (of_machine_is_compatible(PowerMac7,2) ||
  +of_machine_is_compatible(PowerMac7,3)) {
/* Mac G5 9600 */
rdev-mode_info.connector_table = CT_MAC_G5_9600;
} else
 
  I think this still needs to check the PCI IDs as well, or it would break
  different cards in these machines?
 
 I don't know which (if any) other cards apple offered for these
 machines.  I suppose it wouldn't hurt, but OTOH, if this card is all
 that was offered, it's probably not that big a deal as it would be
 unlikely that another card with a mac vbios would show up in one.
 Cards with an x86 vbios won't hit this path.

Ah right, I didn't think of that, and it looks like the X800 is already
covered as well. Still, as you say, it probably wouldn't hurt. :)


-- 
Earthling Michel Dänzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 38280] New: [bisected] regression : etqw tree/water wrong rendering

[bugzilla-daemon]

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

   Summary: [bisected] regression : etqw tree/water wrong
rendering
   Product: Mesa
   Version: git
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/R600
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: pell...@gmail.com


Created an attachment (id=47923)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=47923)
incorrect rendering

commit 9346d895e7ff6c1f01b46513694542026ffba5cc broke tree and water rendering
in etqw (Island map)
See attached screenshots.

I'm using r600g + HD4850

-- 
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 38280] [bisected] regression : etqw tree/water wrong rendering

[bugzilla-daemon]

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

--- Comment #1 from Pierre-Eric Pelloux-Prayer pell...@gmail.com 2011-06-14 
00:57:56 PDT ---
Created an attachment (id=47924)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=47924)
correct rendering for comparison

-- 
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 38280] [bisected] regression : etqw tree/water wrong rendering

[bugzilla-daemon]

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

Pierre-Eric Pelloux-Prayer pell...@gmail.com changed:

   What|Removed |Added

  Component|Drivers/DRI/R600|Drivers/Gallium/r600

-- 
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 38270] Color Tiling unusable on NI

[bugzilla-daemon]

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

--- Comment #5 from Aidan Marks ai...@cisco.com 2011-06-14 01:26:38 PDT ---
Created an attachment (id=47925)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=47925)
dmesg

-- 
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 38270] Color Tiling unusable on NI

[bugzilla-daemon]

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

--- Comment #6 from Aidan Marks ai...@cisco.com 2011-06-14 01:28:20 PDT ---
(In reply to comment #4)
 What 3D driver are you using?  r600g or r600c?  Are you using a compositor or
 not?

vanilla kwin with r600c.

$ glxinfo |grep OpenGL
OpenGL vendor string: Advanced Micro Devices, Inc.
OpenGL renderer string: Mesa DRI R600 (BARTS 6738)  TCL DRI2
OpenGL version string: 2.1 Mesa 7.11-devel (git-a128355)
OpenGL shading language version string: 1.20
OpenGL extensions:

-- 
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 38270] Color Tiling unusable on NI

[bugzilla-daemon]

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

--- Comment #7 from nizz...@hotmail.com 2011-06-14 03:58:09 PDT ---
I get corruption with color tiling turned on too.
My system is up to date debian sid linux 2.6.39/ddx 6.14.2/mesa 7.10.2
with a 5850 using r600g. Attaching a screenshot of stk with color tiling
enabled.

-- 
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 38270] Color Tiling unusable on NI

[bugzilla-daemon]

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

--- Comment #8 from nizz...@hotmail.com 2011-06-14 03:59:54 PDT ---
Created an attachment (id=47951)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=47951)
SuperTuxKart with color tiling, r600g hd5850

-- 
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 32402] Oops associated with radeon_unpin_work_func

[bugzilla-daemon]

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


Florian Mickler flor...@mickler.org changed:

   What|Removed |Added

 CC||flor...@mickler.org




--- Comment #19 from Florian Mickler flor...@mickler.org  2011-06-14 11:21:05 
---
A patch referencing this bug report has been merged in v3.0-rc3:

commit 498c555f56a02ec1059bc150cde84411ba0ac010
Author: Dave Airlie airl...@redhat.com
Date:   Sun May 29 17:48:32 2011 +1000

drm/radeon: fix oops in ttm reserve when pageflipping (v2)

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

[Bug 36421] RV710: GPU lockup running portal2 in wine.

[bugzilla-daemon]

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

--- Comment #7 from Sven Arvidsson s...@whiz.se 2011-06-14 04:59:18 PDT ---
The hangs in Team Fortress 2 and Left 4 Dead has been fixed on git master now,
can you retest?

-- 
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 38280] [bisected] regression : etqw tree/water wrong rendering

[bugzilla-daemon]

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

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

   What|Removed |Added

 CC||s...@whiz.se

--- Comment #2 from Sven Arvidsson s...@whiz.se 2011-06-14 05:15:19 PDT ---
Interesting, I get the opposite behaviour on my HD5670. 

Rendering of trees and water is fixed with commit 9346d89, otherwise broken in
the same way as in your screenshot.

I wonder if this means that the same commit broke rendering in Doom3 on
non-Evergreen hardware?

-- 
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 36917] Rendering glitches in ETQW

[bugzilla-daemon]

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

--- Comment #3 from Sven Arvidsson s...@whiz.se 2011-06-14 05:16:54 PDT ---
Rendering of trees (and water) is fixed on master, but broken on non-evergreen,
see bug 38280.

-- 
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 38280] [bisected] regression : etqw tree/water wrong rendering

[bugzilla-daemon]

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

--- Comment #3 from Andy Furniss li...@andyfurniss.entadsl.com 2011-06-14 
05:54:32 PDT ---
(In reply to comment #2)

 I wonder if this means that the same commit broke rendering in Doom3 on
 non-Evergreen hardware?

Yes. with current master on 4890 there is no distortion behind glass, there is
with 9346d895e7ff6c1f01b46513694542026ffba5cc reverted.

Also see the same regression as the OP in etqw.

-- 
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: be more pendatic about the g5 quirk

[Alex Deucher]

I don't think Apple offered any other cards for
this mac, so I doubt this will be an issue, but just
to be on the safe side, check the pci ids as well.

Signed-off-by: Alex Deucher alexdeuc...@gmail.com
Cc: Joachim Henke j...@users.sourceforge.net
Cc: Michel Dänzer mic...@daenzer.net
---
 drivers/gpu/drm/radeon/radeon_combios.c |9 ++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_combios.c 
b/drivers/gpu/drm/radeon/radeon_combios.c
index 797c8bc..e459467 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -1553,9 +1553,12 @@ bool radeon_get_legacy_connector_info_from_table(struct 
drm_device *dev)
   (rdev-pdev-subsystem_device == 0x4a48)) {
/* Mac X800 */
rdev-mode_info.connector_table = CT_MAC_X800;
-   } else if (of_machine_is_compatible(PowerMac7,2) ||
-  of_machine_is_compatible(PowerMac7,3)) {
-   /* Mac G5 9600 */
+   } else if ((of_machine_is_compatible(PowerMac7,2) ||
+   of_machine_is_compatible(PowerMac7,3)) 
+  (rdev-pdev-device == 0x4150) 
+  (rdev-pdev-subsystem_vendor == 0x1002) 
+  (rdev-pdev-subsystem_device == 0x4150)) {
+   /* Mac G5 tower 9600 */
rdev-mode_info.connector_table = CT_MAC_G5_9600;
} else
 #endif /* CONFIG_PPC_PMAC */
-- 
1.7.1.1

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

Re: [PATCH] drm/radeon/kms: be more pendatic about the g5 quirk

[Michel Dänzer]

On Die, 2011-06-14 at 11:22 -0400, Alex Deucher wrote: 
 I don't think Apple offered any other cards for
 this mac, so I doubt this will be an issue, but just
 to be on the safe side, check the pci ids as well.
 
 Signed-off-by: Alex Deucher alexdeuc...@gmail.com
 Cc: Joachim Henke j...@users.sourceforge.net
 Cc: Michel Dänzer mic...@daenzer.net
 ---
  drivers/gpu/drm/radeon/radeon_combios.c |9 ++---
  1 files changed, 6 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/gpu/drm/radeon/radeon_combios.c 
 b/drivers/gpu/drm/radeon/radeon_combios.c
 index 797c8bc..e459467 100644
 --- a/drivers/gpu/drm/radeon/radeon_combios.c
 +++ b/drivers/gpu/drm/radeon/radeon_combios.c
 @@ -1553,9 +1553,12 @@ bool 
 radeon_get_legacy_connector_info_from_table(struct drm_device *dev)
  (rdev-pdev-subsystem_device == 0x4a48)) {
   /* Mac X800 */
   rdev-mode_info.connector_table = CT_MAC_X800;
 - } else if (of_machine_is_compatible(PowerMac7,2) ||
 -of_machine_is_compatible(PowerMac7,3)) {
 - /* Mac G5 9600 */
 + } else if ((of_machine_is_compatible(PowerMac7,2) ||
 + of_machine_is_compatible(PowerMac7,3)) 
 +(rdev-pdev-device == 0x4150) 
 +(rdev-pdev-subsystem_vendor == 0x1002) 
 +(rdev-pdev-subsystem_device == 0x4150)) {
 + /* Mac G5 tower 9600 */
   rdev-mode_info.connector_table = CT_MAC_G5_9600;
   } else
  #endif /* CONFIG_PPC_PMAC */

Reviewed-by: Michel Dänzer mic...@daenzer.net

Thanks!


-- 
Earthling Michel Dänzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon/kms: be more pedantic about the g5 quirk (v2)

[Alex Deucher]

I don't think Apple offered any other cards for
this mac, so I doubt this will be an issue, but just
to be on the safe side, check the pci ids as well.

v2: fix spelling in commit message

Reviewed-by: Michel Dänzer mic...@daenzer.net
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
Cc: Joachim Henke j...@users.sourceforge.net
Cc: Michel Dänzer mic...@daenzer.net
---
 drivers/gpu/drm/radeon/radeon_combios.c |9 ++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_combios.c 
b/drivers/gpu/drm/radeon/radeon_combios.c
index 797c8bc..e459467 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -1553,9 +1553,12 @@ bool radeon_get_legacy_connector_info_from_table(struct 
drm_device *dev)
   (rdev-pdev-subsystem_device == 0x4a48)) {
/* Mac X800 */
rdev-mode_info.connector_table = CT_MAC_X800;
-   } else if (of_machine_is_compatible(PowerMac7,2) ||
-  of_machine_is_compatible(PowerMac7,3)) {
-   /* Mac G5 9600 */
+   } else if ((of_machine_is_compatible(PowerMac7,2) ||
+   of_machine_is_compatible(PowerMac7,3)) 
+  (rdev-pdev-device == 0x4150) 
+  (rdev-pdev-subsystem_vendor == 0x1002) 
+  (rdev-pdev-subsystem_device == 0x4150)) {
+   /* Mac G5 tower 9600 */
rdev-mode_info.connector_table = CT_MAC_G5_9600;
} else
 #endif /* CONFIG_PPC_PMAC */
-- 
1.7.1.1

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

Re: drm-radeon failures on R600: patches still don't work

[Yaroslav Fedevych]

On 12/06/11 14:21, Markus Trippelsdorf wrote:

Hmm, maybe you're seeing a different problem. The issue that I saw was
fixed by commit 428c6e3630 in the git tree (this is identical to the
patch by Dave you're referring to above).

Does a git-revert fe6f0bd03d697835e76dd18d232ba476c65b8282 solve your
problem?


As for spewing the log with invalid textures, yes. I bisected it twice 
to exclude any pilot error.


As for other things... it's rather getting strange. Instead of garbled 
screen when starting X which was there before revert, and having ability 
to switch to a text VT to see the kernel message, the machine just... 
hangs. The cursor first freezes, then after a few seconds disappears, 
and that's it. After 30 seconds more, HDD stops spinning.


I thought there might be a kernel panic or something, but even if it is, 
the kernel cannot say anything. I fired up netconsole and tried to go 
with that, but to no avail. There was no message which could be a clear 
precursor to disaster.


I thought then that the kernel might manage to print at least something 
on the console. So as soon as I have seen the switch to graphics and the 
mouse cursor, I switched the VT immediately. After a while, the screen 
went black and that was it. It wasn't a particular service.


Even more curious thing is that even using Catalyst doesn't help: it 
invariably comes to this end. I have a pure text console boot, then it 
starts GDM, then there's a black screen with busy cursor spinning, I 
switch to the text console, after a few seconds I lose control over it, 
that is - the boot process freezes and the keyboard stops accepting 
input, then the switch to a black screen and that's it.


And the only reliable pre-requisite for this to happen is to launch X. 
In single-user, without X running, it would work for days, KMS or not.


I'm really not sure how to debug this. This behaviour started as soon as 
3.0.0-rc2 and is there as of today's git (3.0.0-rc3).


Also, I'm not sure that DRI is to blame, because the hangs occur on both 
open source and proprietary drivers.


As I have told before, netconsole does not show anything suspicious.

I cannot tell if SysRq would work because my laptop hasn't got a SysRq key.

I wonder if Gallium Mesa libs could, in a way, do these things. By the 
way, they work fine on 2.6.39...


The machine on which that happens is Thinkpad Edge 13, AMD model, BIOS 
v1.12, AMD RS780 (Radeon HD3200). What else do I need to supply? What 
debugging options to turn on?


I'm completely lost here and feel like a complete idiot.

Next I'm going to nuke my Gallium Mesa libraries and try to boot without 
them, but it's interesting anyway if anyone got similar symptoms.

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

[Bug 36523] water reflections misrendered in sauerbraten with shaders=high setting

[bugzilla-daemon]

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

--- Comment #4 from Sven Arvidsson s...@whiz.se 2011-06-14 09:34:03 PDT ---
This seems to be fixed with current git master, can you confirm?

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

r600g TXD opcode (was: ... translation from TGSI failed / missing vertex shader)

[David Lamparter]

On Sun, Jun 05, 2011 at 10:32:34PM -0700, bugzilla-dae...@freedesktop.org wrote:
 I'm attaching a patch that has an implementation. Unfortunately I can't seem 
 to
 get it to work entirely correctly. The piglit test looks almost correct but 
 has
 several artifacts in random places. If someone could point me in the right
 direction (as I'm completely clueless), I would be happy to finish it. In case
 it matters, piglit does not show any new failures from this patch.

Did you make any progress? This also affects EVE Online btw.

-David

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

[Bug 38280] [bisected] regression : etqw tree/water wrong rendering

[bugzilla-daemon]

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

--- Comment #4 from Vadim pt...@yandex.ru 2011-06-14 10:44:29 PDT ---
Created an attachment (id=47965)
 View: https://bugs.freedesktop.org/attachment.cgi?id=47965
 Review: https://bugs.freedesktop.org/review?bug=38280attachment=47965

patch

This patch should restore previous behaviour for r600r700 hw.

-- 
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: r600g TXD opcode (was: ... translation from TGSI failed / missing vertex shader)

[Sven Arvidsson]

On Tue, 2011-06-14 at 19:09 +0200, David Lamparter wrote:
 On Sun, Jun 05, 2011 at 10:32:34PM -0700, bugzilla-dae...@freedesktop.org 
 wrote:
  I'm attaching a patch that has an implementation. Unfortunately I can't 
  seem to
  get it to work entirely correctly. The piglit test looks almost correct but 
  has
  several artifacts in random places. If someone could point me in the right
  direction (as I'm completely clueless), I would be happy to finish it. In 
  case
  it matters, piglit does not show any new failures from this patch.
 
 Did you make any progress? This also affects EVE Online btw.

AFAIK, you need to use the web interface to comment on bugs. Otherwise
Mike will miss this (unless he follows dri-devel):
https://bugs.freedesktop.org/show_bug.cgi?id=37476

-- 
Cheers,
Sven Arvidsson
http://www.whiz.se
PGP Key ID 760BDD22



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

[PATCH] drm/radeon/kms: signed fix for evergreen thermal

[Alex Deucher]

temperature is signed.

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

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index e1b3d99..b06f2db 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -88,7 +88,8 @@ u32 evergreen_page_flip(struct radeon_device *rdev, int 
crtc_id, u64 crtc_base)
 /* get temperature in millidegrees */
 int evergreen_get_temp(struct radeon_device *rdev)
 {
-   u32 temp, toffset, actual_temp = 0;
+   u32 temp, toffset;
+   int actual_temp = 0;
 
if (rdev-family == CHIP_JUNIPER) {
toffset = (RREG32(CG_THERMAL_CTRL)  TOFFSET_MASK) 
-- 
1.7.1.1

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

[Bug 38270] Color Tiling unusable on NI

[bugzilla-daemon]

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

--- Comment #9 from nizz...@hotmail.com 2011-06-14 13:29:55 PDT ---
mesa from current git works fine wit color tiling enabled so it seems an old
bug still present in 7.10.2 for cypress/evergreen at least. Still a check for a
recent enough mesa might be a good idea before enabling by default?

-- 
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 32511] glDrawPixels broken on savage

[bugzilla-daemon]

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

Tormod Volden bugzi11.fdo.tor...@xoxy.net changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #17 from Tormod Volden bugzi11.fdo.tor...@xoxy.net 2011-06-14 
14:32:43 PDT ---
Finally fixed in the Linux 3.0 kernel drm:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=66aa6962ff520804f9874e57ea97995153f499d8

-- 
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 38270] Color Tiling unusable on NI

[bugzilla-daemon]

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

--- Comment #10 from Aidan Marks ai...@cisco.com 2011-06-14 17:01:39 PDT ---
pulling latest mesa/libdrm/ddx again still has the corruption with color tiling
on with r600c.  I tried r600g and the corruption is not seen.

-- 
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 3/3] alpha, drm: Add Alpha support to Radeon DRM code

[Jay Estabrook]

Hi, Dave,

It is the explanation that is inaccurate; I was still thinking about mmap when
the new paradigm is to do the mapping when the VM faults.

I believe the code that requires this patch is: ttm/ttm_bo_vm.c: 
ttm_bo_vm_fault(),
specifically:

for (i = 0; i  TTM_BO_VM_NUM_PREFAULT; ++i) {
if (bo-mem.bus.is_iomem)
pfn = ((bo-mem.bus.base + bo-mem.bus.offset)  PAGE_SHIFT) + 
page_offset;
else {

The pfn needs to reflect the correct system bus address to get to the VRAM
on the graphics card.

I will rework the commentary and resend.

Thanks for the feedback.

Jay


On 06/13/2011 07:35 PM, Dave Airlie wrote:
 On Fri, Jun 10, 2011 at 8:20 AM, Jay Estabrook jay.estabr...@gmail.com 
 wrote:
 Alpha needs to have the system bus address for the device's local
 memory available, so that it can be returned to user-level, where
 it may be used in an mmap(). So, we make bus.addr hold the ioremap()
 return for kernel use, and then we can modify bus.base appropriately.

 
 I don't get this. why is mmap passing in an address? we don't do that anymore.
 
 When you mmap the device node it passes back a hashed offset in the
 table, that the
 kernel then translates into a proper address and sets up the page tables.
 
 So I really don't get what this patch is doing, either the
 explaination of what it is doing is wrong
 or it is wrong.
 
 Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel