Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
Inducing others into the trap
Posted Mar 3, 2010 12:30 UTC (Wed) by nix (subscriber, #2304)
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?
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds