On Thu, 2004-04-15 at 22:00, Nathanael Nerode wrote:It allows for the microcode to be updated without replacing the kernel, which is not a bad thing anyway.
This is a diff for drivers/char/drm to make r128 use userland-loadable
firmware.
Sigh, is this really necessary? :\
Thanks. :-)Anyway, I'll offer some technical comments.
OK; I'm not surprised at that. I'm not entirely clear where the return code needs to be returned in order to fail properly, though. r128_do_init_cce returns an int; is it sufficient to propagate the error code out of there? That I can do.It's completely untested (since I don't *have* an r128, I don't see any way to test it), but I bet it'll work; the firmware loading interface seems remarkably easy to use.
Its return code should probably be checked and propagated though? The DRM doesn't work without the microcode.
Does this work with 2.4 kernels?No, because the firmware loading interface isn't present.
OK. Please suggest a way to abstract this out into a file which would contain the old system for the BSDs and 2.4 kernels, and the new system for 2.6 kernels (for instance; it could also be a configuration option, etc). I don't understand the way the files are organized well enough to come up with a good way myself. :-PThis patch puts Linux specific code in a file that is shared with the BSDs.
I was working from the versions in the Linux kernel source, since that's the only version I actually intended to change, and because I could figure out the tree. Should I be looking elsewhere? I couldn't figure out where the files were in the DRI CVS tree... *spends extra hour looking* OK, are they visible at http://dri.freedesktop.org/cgi-bin/cvsweb/dri/drm/ ?
Hmm. What's the Best Way to abstract away OS/kernel differences in this case? I had this thought:
* shared/r128_drv.h contains the prototype for the new (error-returning) r128_cce_load_firmware
* shared/r128_firmware.c contains the old, hard-coded firmware as an implementation of that
* linux/r128_firmware_loader.c contains the firmware loading version as an implementation of that
* bsd/r128/Makefile adds r128_firmware.c to SRCS
* linux/Makefile.kernel adds r128_firmware.o *or* r128_firmware_loader.o to r128-objs, depending on a kernel version check. Similarly for linux/Makefile.linux and R128SHARED. linux/Kconfig adds "select FW_LOADER" to the DRM_R128 section... depending on a kernel version check? (I dunno how to depend on that in a Kconfig file.) Perhaps it should depend on something else, but I don't grok the configuration madness.
Is there a Better Way?...
> of
Oh good. :-)the right way to deal with the stupid endianness issues; I went with the simplistic "pick an endianness" choice.
That's the only sane way.
That's what I hoped -- that it was safe to sleep while holding the hardware lock, when doing a complete device reset. :-)Please do tell me if there's a major problem with this that I can fix. The one which worries me the most is the possibility that the firmware loading is not done in user context, or that it's done when holding a lock which means that it mustn't sleep. (Request_firmware obviously sleeps, since it calls into userland.)
The hardware lock is probably held when the ioctl is called, but I don't think that's a problem. It's only called by the X server (or its equivalent) during initialisation.
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
