AMD R600/700 DRM Interrupts Support Pushed

[agd5f]

At the moment, the irq code depends on functionality that isn't available in UMS, so you'd need to implement that first anyway. So for irqs you either have to implement KMS, or you have to implement the functionality required for irq support. Either way there a fair amount of work involved. The effort would be better spent on KMS support since that brings additional features.

[Zajec]

And how far is actually the audio over HDMI in the IP-review?

The Novell implementation says they have R700 support done.

http://www.x.org/wiki/radeonhd%3Afeature

This is implemented by Christian who has done great work RE it from fglrx. It generally works but we have some issue with RV770 and ... RV730 AFAIR. There exists probability this issue with these chipsets will be fixed by Alex's patches.

See archive of radeonhd mailinglist from late November and early December for details.

[monraaf]

Note for Ubuntu users who don't want to compile their own kernel, there's a deb of the drm-next kernel here:

http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-next/current/

It doesn't include the required firmware for interrupts however, so you have to download and install the firmware yourself.

Firmware can be found here:

http://www.mail-archive.com/[email protected]/msg45004.html

After installing the kernel deb you have to copy the firmware to:

/lib/firmware/2.6.32-996-generic/radeon

[pingufunkybeat]

OK, I'm probably doing something really stupid here, but I'm getting a kernel oops after failing to load R700_rlc.bin with the latest drm-radeon-testing.

I downloaded the firmware and copied it to both /lib/firmware/radeon and /lib/firmware/2.6.32-rc8/radeon. It never finds it.

The other firmware is compiled into the kernel, so I might be putting it into a wrong location (I have no previous reference). What am I doing wrong?

[bridgman]

Are there any clues about location in the dmesg output ? Is your kernel version really 2.6.32-rc8 ?

[pingufunkybeat]

dmesg will only report the info from the last boot. At the moment, I'm booting a previous kernel, which doesn't have the interrupt code.

But when I try to boot drm-radeon-testing, I get stuck at the firmware, before kernel loads, so I can't check dmesg. The bootup message is not useful, it just said it failed to find radeon/R700_rlc.bin, not where it should be.

I'm using the latest drm-radeon-testing git. make menuconfig reports 2.6.32-rc8, and there is a 2.6.32-rc8 directory under /lib/modules. I'd never installed 2.6.32-rc8 before, so it must be it.

[agd5f]

If you are using an initrd, you'll need to add the ucode to that as well.

[pingufunkybeat]

Nope, I compile everything I need (and only what I need) into the kernel. The few modules are under /lib/modules/kernel-version and work fine. The other firmware is compiled into the kernel. Is it possible to compile this into the drm-radeon-testing kernel?

Am I just too impatient? I'm guessing that the IRQ firmware will be added to the linux tree like the other firmware sooner or later.

[thalience]

Nope, I compile everything I need (and only what I need) into the kernel. The few modules are under /lib/modules/kernel-version and work fine. The other firmware is compiled into the kernel. Is it possible to compile this into the drm-radeon-testing kernel?

Am I just too impatient? I'm guessing that the IRQ firmware will be added to the linux tree like the other firmware sooner or later.

When the radeon module is compiled in, it requests the firmware before udev is active (at least in debian's initrds), so the firmware cannot be loaded unless it too, is compiled in.

Spent way too long trying to figure this out yesterday. The trick is to add "radeon/R[67]00_rlc.bin" to CONFIG_EXTRA_FIRMWARE (and probably set CONFIG_EXTRA_FIRMWARE_DIR to /lib/firmware). This will cause the new firmware to be compiled in.

CONFIG_EXTRA_FIRMWARE is under Device Drivers -> Generic driver options, btw.

I'm not sure why, but I don't seem to be getting sync-to-vblank behavior with GL apps (glxgears still reports way more than 60fps). GL apps no-longer complain about a lack of interrupts, however.

[pingufunkybeat]

wow.

I never would have come up with that one!

Now it works. I'm sure many people will find this useful!