Inducing others into the trap [LWN.net]

Inducing others into the trap

Posted Mar 2, 2010 13:56 UTC (Tue) by nix (subscriber, #2304)
In reply to: Inducing others into the trap by Janne
Parent article: Linux-2.6.33-libre released

... and if you download an upstream 2.6.33 kernel and try to compile it, you find that interrupts don't work on Radeon, because the firmware for it isn't in the tree. You can hunt it down in another tree (linux-firmware) and point the kernel at it, but the only info I've found about this is *in the git commit message adding the dependency*, and even that doesn't mention that the newly-required firmware was never added to the kernel tree at all, even in the firmware/ subdirectory.

... but maybe I missed the prominent message at release time... or maybe it's a simple mistake.

(Log in to post comments)

Inducing others into the trap

Posted Mar 3, 2010 12:30 UTC (Wed) by nix (subscriber, #2304) [Link]

r6xx, r7xx, those being the only ones that gained interrupt support this
time around and need firmware for it.

Commit d8f60cfc93452d0554f6a701aa8e3236cbee4636, which introduces
interrupt support, and the source code are the *only* places which
reference the new firmware files, and the source code actually constructs
the filename from pieces so grepping for it will fail. The firmware in
question, radeon/R600_rlc.bin and radeon/R700_rlc.bin, is *only* in the
linux-firmware tree. So the only way you'll notice this, unless you're an
obsessional follower of commit logs, is to spot the firmware loader
moaning about the absence of firmware, and then you have to figure out
that you have to get the linux-firmware tree, point the kernel at it via
CONFIG_EXTRA_FIRMWARE_DIR, and *explicitly name the firmware* in
CONFIG_EXTRA_FIRMWARE, or you'll have no interrupt handling. (At least you
get a warning message about this from Mesa apps.)

Oh yes, you can let the firmware loader get udev to load it off the
filesystem, assuming you've figured out what it's called and dropped it in
the right place. But that only works if the Radeon DRM isn't built in,
because if it is the firmware loader is asked for this stuff at
initialization time, long before udev is up. And if the DRM isn't built
in, X won't use it unless you explicitly load the module first: X can't
autoload it soon enough and tries to kick up UMS while KMS is still
initializing. That, at least, is considered a bug, but I *like* built-in
Radeon KMS and don't want to make it a module: I get a nice high-res
framebuffer console and everything.

Radeon KMS: lovely results, and a setup user experience like pushing forks
into your eyes. Welcome to the wonderful world of the firmware loader. I
much preferred it when the damn hardware worked *without* your having to
pay so much attention to the nasty non-free lumps that get uploaded to
it. I'm not planning to distribute my kernel binaries anyway: why am I
paying in configuration pain for the distributors who do?