chance of license issues. Even if the code is built-in
it should not need built-in firmware.
The quickest fix is probably something like this:
config DRM_RADEON_FIRMWARE
tristate
default m if STANDALONE
default y
config DRM_RADEON
depends DRM_RADEON_FIRMWARE
That should prevent somebody from building the radeon driver into the
kernel unless they manually indicate that they have the extra firmware.
Long-term, the driver should support modular firmware even when it's
built-in to the kernel.
Cheers,
Kyle Moffett
chance of license issues. Even if the code is built-in
it should not need built-in firmware.
The quickest fix is probably something like this:
config DRM_RADEON_FIRMWARE
tristate
default m if STANDALONE
default y
config DRM_RADEON
depends DRM_RADEON_FIRMWARE
That should prevent somebody from building the radeon driver into the
kernel unless they manually indicate that they have the extra firmware.
Long-term, the driver should support modular firmware even when it's
built-in to the kernel.
Cheers,
Kyle Moffett
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
t do this.
I actually recall a patch previously that made request_firmware() fail instantly
before userspace is loaded, which would get rid of the hang, but presumably
not actually make the driver work when built-in.
The solution is to allow the driver to "attach" to the device but if
t
t do this.
I actually recall a patch previously that made request_firmware() fail instantly
before userspace is loaded, which would get rid of the hang, but presumably
not actually make the driver work when built-in.
The solution is to allow the driver to "attach" to the device but if
the firmware is
not available at that time then retrying the request_firmware() later, ideally
triggered from some userspace action.
Cheers,
Kyle Moffett
