Re: [Dri-devel] [PATCH] Convert r128 driver in linux kernel 2.6 to use userland firmware loading
On Sat, Apr 17, 2004 at 08:16:36PM +0100, Alan Cox wrote: On Sad, 2004-04-17 at 19:40, Ryan Underwood wrote: Of course, if the legal advice you refer to was specifically aimed at the firmware scenario, where you have a blob of who-knows-what that does not execute on the host embedded into a driver binary, then I'm not one to argue with that. It was specifically in response to the question about firmware, and whether it would be better if firmware was seperated. I don't know of any direct case law on embedding firmware and at what point it isn't mere aggregation So your advisor is saying that such a work is undistributable under the GPL, or are they saying that it is not distributable at all? I'm also curious if they would draw the same conclusion if you had some form of interpretable bytecode that is embedded into the binary. It doesn't run on any CPU, but nevertheless is classified software by most definitions since it executes in a virtual machine. You might say then that the bytecode is not the preferred form of modification according to the GPL, but if I wrote an interpreter and no other tools to go with it, it has no other form in which it can be modified. This is borderline pedantry, but boundary cases must be considered if we are to make wise decisions. I don't think any of this really addresses the DFSG though. Some Debian folks are removing firmware which is freely distributable and not being combined/aggregated with GPL drivers, on the basis that it is software and thus must be DFSG-free according to the social contract. One requirement to be DFSG-free is that source must be made available, so these firmware don't satisfy it and are removed. My opinion is that this only makes sense when the target is known to be a general purpose computer and the firmware image is known to contain a program that is executed by its CPU. Otherwise, it could simply be a configuration list that is parsed by the device, or a memory initialization image, or a dispatch table, or something similar, and rejecting such things on the basis that they are *suspected* to be software without source seems to be counterproductive. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] [PATCH] Convert r128 driver in linux kernel 2.6 to use userland firmware loading
On Sul, 2004-04-18 at 07:52, Ryan Underwood wrote: So your advisor is saying that such a work is undistributable under the GPL, or are they saying that it is not distributable at all? They are saying that in their reading of the law it would be better if the firmware was kept seperate. Lawyers do not define the interpretation of law, especially in the absence of specific caselaw. Otherwise, it could simply be a configuration list that is parsed by the device, or a memory initialization image, or a dispatch table, or something similar, and rejecting such things on the basis that they are *suspected* to be software without source seems to be counterproductive There is no difference between the two, but this is getting very off-topic --- 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_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] Convert r128 driver in linux kernel 2.6 to use userland firmware loading
On Sun, Apr 18, 2004 at 09:20:00AM +0100, Alan Cox wrote: Otherwise, it could simply be a configuration list that is parsed by the device, or a memory initialization image, or a dispatch table, or something similar, and rejecting such things on the basis that they are *suspected* to be software without source seems to be counterproductive There is no difference between the two, but this is getting very off-topic Its on-topic because the OP's work was generated specifically from the discussion on the Debian lists that I referenced. I still don't see where the boundary is drawn between data (which requires no source to be DFSG-free) and embedded executable code (which requires source to be DFSG-free). It seems that the interpretation is arbitrary depending on what 'feels' right in a particular case. I've no contest with people doing work to make things more flexible, but in this case the OP's work is being done because the unidentified matter is to be removed from the distribution, due to its suspected code-without-source nature. Why not do this work simply as a precursor to the event where someone identifies this binary blob as code-without-source in the future, and defer the actual removal to that future date if it ever arrives? -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] [PATCH] Convert r128 driver in linux kernel 2.6 to use userland firmware loading
On Sad, 2004-04-17 at 06:44, Ryan Underwood wrote: 3) Neither of these is ok, must go into non-free because binary-only firmware doesnt meet DFSG (no source) regardless of its license. Either whole driver must go into non-free, or a crippled driver is provided in main and a userspace loader in non-free to add the missing functionality. This is the answer I was given by lawyers. The analogy they use is an interesting but sensible one. If I add a chapter to a book it is clearly a derivative work, if I bundle the one work with a second pamphlet containing the chapter I wrote then it is not. 3 is a rather zealous approach, but seemed to be the approach that the do-ers on this issue are taking. I sympathize with the idealists on I don't think its zealots so much as appropriate legal practice. In the Linux case we now have a good hotplug firmware loading interface and drivers can practically ask for specific firmware. It also reduces the unswappable kernel size --- 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_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] Convert r128 driver in linux kernel 2.6 to use userland firmware loading
On Sat, 2004-04-17 at 07:44, Ryan Underwood wrote: On Sat, Apr 17, 2004 at 03:03:04AM +0200, Michel Dnzer wrote: It allows for the microcode to be updated without replacing the kernel, which is not a bad thing anyway. But changing the microcode would change the driver-chip interface anyway. So you'd have to update the driver too. Keeping the driver and the userspace loader in sync might be...erm.. painful. If a userspace approach to firmware loading is pursued, perhaps a better approach is like the modprobe approach. When the XFree86 driver for a piece of hardware initializes, it would do a kernel probe for the firmware for this device, corresponding to the particular version of the driver that is running. The kernel would call a firmware loading binary (like it calls /sbin/modprobe or whatever is in that /proc entry) telling it what driver is asking and what version of the driver. Based on that information, the userspace loader can decide which version of the microcode to load up. If that version is not available, exit with failure and the kernel should then return failure to the application, so it knows that the proper microcode that particular driver version was written against was unable to be found, and to disable features which would require a loaded microcode. I don't think such a complicated scheme is needed? Just encode the microcode version in the filename and try to load any supported version, from most to least preferred? I mostly agree with your other points. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- 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_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] Convert r128 driver in linux kernel 2.6 to use userland firmware loading
On Sat, Apr 17, 2004 at 09:36:24AM +0100, Alan Cox wrote: This is the answer I was given by lawyers. The analogy they use is an interesting but sensible one. If I add a chapter to a book it is clearly a derivative work, if I bundle the one work with a second pamphlet containing the chapter I wrote then it is not. It seems digging up some case law on the matter would be better than using analogies. Firmware could already be considered to be the pamphlet that is bundled with the book (the driver) because the firmware is not part of the driver in terms of functionality; it happens to be bundled with the driver because that is the most convenient way to get it into the hardware. Execution of the driver code never reaches the firmware and could not because it is not encoded in the instruction set of the host that the driver is running on. Of course, if the legal advice you refer to was specifically aimed at the firmware scenario, where you have a blob of who-knows-what that does not execute on the host embedded into a driver binary, then I'm not one to argue with that. I don't think its zealots so much as appropriate legal practice. In the Linux case we now have a good hotplug firmware loading interface and drivers can practically ask for specific firmware. It also reduces the unswappable kernel size Sure. I won't argue with people that are making the existing systems more flexible. My beef is mainly that a lot of people are considering sourceless firmware to be outside the DFSG, which amounts to an inconvenience to users for a dubious political gain. But that is off-topic for dri-devel probably. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] [PATCH] Convert r128 driver in linux kernel 2.6 to use userland firmware loading
On Sat, Apr 17, 2004 at 03:33:16PM +0200, Michel Dänzer wrote: I don't think such a complicated scheme is needed? Just encode the microcode version in the filename and try to load any supported version, from most to least preferred? I think that's what I meant. Point being, have the kernel call out to a userspace loader on the driver's behalf, instead of the user running a loader like Nathaniel's in an init script or something. I was also reminding folks of the importance of versioning of the driver vs the firmware, because one of his comments seemed to imply that you could upgrade the microcode to a new version without changes to the driver. This is not always true because the command interface may change from revision to revision of the microcode. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] [PATCH] Convert r128 driver in linux kernel 2.6 to use userland firmware loading
--- Michel Dänzer [EMAIL PROTECTED] wrote: On Fri, 2004-04-16 at 23:02, Nathanael Nerode wrote: Michel Dänzer wrote: On Thu, 2004-04-15 at 22:00, Nathanael Nerode wrote: This is a diff for drivers/char/drm to make r128 use userland-loadable firmware. Sigh, is this really necessary? :\ It allows for the microcode to be updated without replacing the kernel, which is not a bad thing anyway. I'm not sure it ever has changed or will change... we both know the background of this; IMHO it's an inconvenience for users for little or no gain of freedom. I know the firmware is not all that large but every page counts. Freeing it from the mod will reduce it's memory foot print. Though your right there is little or no gain of freedom. __ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25¢ http://photos.yahoo.com/ph/print_splash --- 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_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] Convert r128 driver in linux kernel 2.6 to use userland firmware loading
On Sad, 2004-04-17 at 19:40, Ryan Underwood wrote: Of course, if the legal advice you refer to was specifically aimed at the firmware scenario, where you have a blob of who-knows-what that does not execute on the host embedded into a driver binary, then I'm not one to argue with that. It was specifically in response to the question about firmware, and whether it would be better if firmware was seperated. I don't know of any direct case law on embedding firmware and at what point it isn't mere aggregation --- 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_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] Convert r128 driver in linux kernel 2.6 to use userland firmware loading
On Sat, 2004-04-17 at 20:46, Ryan Underwood wrote: On Sat, Apr 17, 2004 at 03:33:16PM +0200, Michel Dnzer wrote: I don't think such a complicated scheme is needed? Just encode the microcode version in the filename and try to load any supported version, from most to least preferred? I think that's what I meant. Point being, have the kernel call out to a userspace loader on the driver's behalf, instead of the user running a loader like Nathaniel's in an init script or something. My understanding is that the firmware loader interface he uses works similar to your description, via hotplug events. I was also reminding folks of the importance of versioning of the driver vs the firmware, because one of his comments seemed to imply that you could upgrade the microcode to a new version without changes to the driver. This is not always true because the command interface may change from revision to revision of the microcode. Indeed, the microcode should definitely be versioned. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- 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_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] Convert r128 driver in linux kernel 2.6 to use userland firmware loading
Michel Dnzer wrote: On Thu, 2004-04-15 at 22:00, Nathanael Nerode wrote: This is a diff for drivers/char/drm to make r128 use userland-loadable firmware. Sigh, is this really necessary? :\ It allows for the microcode to be updated without replacing the kernel, which is not a bad thing anyway. Anyway, I'll offer some technical comments. Thanks. :-) 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. 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. Does this work with 2.4 kernels? No, because the firmware loading interface isn't present. This patch puts Linux specific code in a file that is shared with the BSDs. 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. :-P 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 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. Oh good. :-) 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. That's what I hoped -- that it was safe to sleep while holding the hardware lock, when doing a complete device reset. :-) --- 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_id70alloc_id638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] Convert r128 driver in linux kernel 2.6 to use userland firmware loading
Keith Whitwell wrote: Nathanael Nerode wrote: snip My changes are GPL licensed (of course). The r128 module is BSD licensed (though I thought it was supposed to be dual BSD/GPL) - are you willing to reconsider? Yes, I'll be happy to BSD license this; it's not as if it's really very much material, so I don't really care very much what it's licensed under. I hereby license my changes under this license: Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. If not it will be hard to integrate your changes, regardless of their technical merit. OK, now we can worry about the (lack of) technical merit. ;-) --- 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_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] Convert r128 driver in linux kernel 2.6 to use userland firmware loading
On Fri, 2004-04-16 at 23:02, Nathanael Nerode wrote: Michel Dnzer wrote: On Thu, 2004-04-15 at 22:00, Nathanael Nerode wrote: This is a diff for drivers/char/drm to make r128 use userland-loadable firmware. Sigh, is this really necessary? :\ It allows for the microcode to be updated without replacing the kernel, which is not a bad thing anyway. I'm not sure it ever has changed or will change... we both know the background of this; IMHO it's an inconvenience for users for little or no gain of freedom. 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. 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? Yes, the return code of r128_do_init_cce() is used directly as the return code of the ioctl in r128_cce_init(). 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/ ? Yes, that's the new standalone DRM module. 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. Sounds viable, but maybe it could be done simpler in drm_os_*.h? (r128 and radeon could possibly share the code?) 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.) I think Kconfig is 2.6 only. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- 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_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] Convert r128 driver in linux kernel 2.6 to use userland firmware loading
On Sat, Apr 17, 2004 at 03:03:04AM +0200, Michel Dänzer wrote: It allows for the microcode to be updated without replacing the kernel, which is not a bad thing anyway. But changing the microcode would change the driver-chip interface anyway. So you'd have to update the driver too. Keeping the driver and the userspace loader in sync might be...erm.. painful. If a userspace approach to firmware loading is pursued, perhaps a better approach is like the modprobe approach. When the XFree86 driver for a piece of hardware initializes, it would do a kernel probe for the firmware for this device, corresponding to the particular version of the driver that is running. The kernel would call a firmware loading binary (like it calls /sbin/modprobe or whatever is in that /proc entry) telling it what driver is asking and what version of the driver. Based on that information, the userspace loader can decide which version of the microcode to load up. If that version is not available, exit with failure and the kernel should then return failure to the application, so it knows that the proper microcode that particular driver version was written against was unable to be found, and to disable features which would require a loaded microcode. I'm not sure it ever has changed or will change... we both know the background of this; IMHO it's an inconvenience for users for little or no gain of freedom. Well, microcode without source has been a big topic on debian-devel recently. There seems to be 3 interpretations under DFSG: 1) Binary only firmware under a license which doesn't require redistribution of source code is ok (i.e. a BSD license), but GPL licensed stuff is no good because no way to satisfy GPL. 2) Binary only firmware as well as GPL licensed stuff is ok. Here we are arguing intent on the part of whoever released the binary only code under GPL, and saying that they would be laughed out of court if it ever came to them suing a distributor for breach of GPL. 3) Neither of these is ok, must go into non-free because binary-only firmware doesnt meet DFSG (no source) regardless of its license. Either whole driver must go into non-free, or a crippled driver is provided in main and a userspace loader in non-free to add the missing functionality. 3 is a rather zealous approach, but seemed to be the approach that the do-ers on this issue are taking. I sympathize with the idealists on this issue, but I can't help but feel that this is impractical in the short run. I would love if Matrox gave me some microcode programming info for their WARP engine in G-series (could implement a TL pipeline stage for instance), but I think inconveniencing users in this way is the wrong way to put pressure on the vendor to be more open (if that is the goal). These things are not general purpose computers, and I think the DFSG should only apply to software that is run on a general purpose computer. You could say that a video card or a random USB microcontroller may or may not be a Von Neumann machine. But it is probably not even close to Turing complete. Of course we don't know that without the specifications. But I don't see the point of applying DFSG to things that are not, or not known to be, general purpose computers. As long as the microcode is legally redistributable, I dont have a problem with it. (Granted, some of the microcode included with the Linux kernel seems not to be freely redistributable, and that is obviously a problem that some have been overlooking.) -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
[Dri-devel] [PATCH] Convert r128 driver in linux kernel 2.6 to use userland firmware loading
This is a diff for drivers/char/drm to make r128 use userland-loadable
firmware. 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.
Following that (in the form of a diff) is the short program I used to create
a microcode file which could be shipped as the file
/usr/lib/hotplug/r128_cce_microcode
(I left it in this form to avoid problems with attaching binaries.)
Similar (nearly identical) changes could be made to the radeon driver in
the same directory, and I'll be happy to make them if needed.
This could probably be improved by someone with a better sense of
the right way to deal with the stupid endianness issues; I went with the
simplistic pick an endianness choice.
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.) After spending something like 6 hours trawling
through the code backwards and forwards, I decided it *probably* wasn't,
but I wasn't sure.
There's also a faint possibility of deadlock if the userland process which
is supposed to load the firmware waits for the DRM module in order to use
the screen; this shouldn't happen because it's a background daemon (hotplug),
and the standard script only calls cat [file] sysfs/[phony file].
If either of these is a problem, the firmware may have to be loaded
and cached in memory at module load time in the module load routine, and only
disposed of at module unload. I couldn't actually find those routines, which
is one reason I didn't do that. ;-) The other is that it seems like it's a
waste of memory to do anything other than retrieving it when it's needed and
disposing of it afterwards.
Of course, given my lack of DRM experience, there could be any number of
other gotchas. :-P
My changes are GPL licensed (of course).
(Incidentally, what *is* this microcode? It looks like it's actually
two separate sets of code interleaved.)
Please email me with comments/requests, as I'm not subscribed.
--- r128_cce.c 2003-09-28 00:44:12.0 -0400
+++ r128_cce.c.new 2004-04-12 19:32:39.0 -0400
@@ -3,6 +3,7 @@
*
* Copyright 2000 Precision Insight, Inc., Cedar Park, Texas.
* Copyright 2000 VA Linux Systems, Inc., Sunnyvale, California.
+ * Portions copyright 2003 Nathanael Nerode.
* All Rights Reserved.
*
* Permission is hereby granted, free of charge, to any person obtaining a
@@ -28,6 +29,7 @@
*Gareth Hughes [EMAIL PROTECTED]
*/
+#include linux/firmware.h
#include r128.h
#include drmP.h
#include drm.h
@@ -36,51 +38,6 @@
#define R128_FIFO_DEBUG0
-/* CCE microcode (from ATI) */
-static u32 r128_cce_microcode[] = {
- 0, 276838400, 0, 268449792, 2, 142, 2, 145, 0, 1076765731, 0,
- 1617039951, 0, 774592877, 0, 1987540286, 0, 2307490946U, 0,
- 599558925, 0, 589505315, 0, 596487092, 0, 589505315, 1,
- 11544576, 1, 206848, 1, 311296, 1, 198656, 2, 912273422, 11,
- 262144, 0, 0, 1, 33559837, 1, 7438, 1, 14809, 1, 6615, 12, 28,
- 1, 6614, 12, 28, 2, 23, 11, 18874368, 0, 16790922, 1, 409600, 9,
- 30, 1, 147854772, 16, 420483072, 3, 8192, 0, 10240, 1, 198656,
- 1, 15630, 1, 51200, 10, 34858, 9, 42, 1, 33559823, 2, 10276, 1,
- 15717, 1, 15718, 2, 43, 1, 15936948, 1, 570480831, 1, 14715071,
- 12, 322123831, 1, 33953125, 12, 55, 1, 33559908, 1, 15718, 2,
- 46, 4, 2099258, 1, 526336, 1, 442623, 4, 4194365, 1, 509952, 1,
- 459007, 3, 0, 12, 92, 2, 46, 12, 176, 1, 15734, 1, 206848, 1,
- 18432, 1, 133120, 1, 100670734, 1, 149504, 1, 165888, 1,
- 15975928, 1, 1048576, 6, 3145806, 1, 15715, 16, 2150645232U, 2,
- 268449859, 2, 10307, 12, 176, 1, 15734, 1, 15735, 1, 15630, 1,
- 15631, 1, 5253120, 6, 3145810, 16, 2150645232U, 1, 15864, 2, 82,
- 1, 343310, 1, 1064207, 2, 3145813, 1, 15728, 1, 7817, 1, 15729,
- 3, 15730, 12, 92, 2, 98, 1, 16168, 1, 16167, 1, 16002, 1, 16008,
- 1, 15974, 1, 15975, 1, 15990, 1, 15976, 1, 15977, 1, 15980, 0,
- 15981, 1, 10240, 1, 5253120, 1, 15720, 1, 198656, 6, 110, 1,
- 180224, 1, 103824738, 2, 112, 2, 3145839, 0, 536885440, 1,
- 114880, 14, 125, 12, 206975, 1, 33559995, 12, 198784, 0,
- 33570236, 1, 15803, 0, 15804, 3, 294912, 1, 294912, 3, 442370,
- 1, 11544576, 0, 811612160, 1, 12593152, 1, 11536384, 1,
- 14024704, 7, 310382726, 0, 10240, 1, 14796, 1, 14797, 1, 14793,
- 1, 14794, 0, 14795, 1, 268679168, 1, 9437184, 1, 268449792, 1,
- 198656, 1, 9452827, 1, 1075854602, 1, 1075854603, 1, 557056, 1,
- 114880, 14, 159, 12, 198784, 1, 1109409213, 12, 198783, 1,
- 1107312059, 12, 198784, 1, 1109409212, 2, 162, 1, 1075854781, 1,
-
Re: [Dri-devel] [PATCH] Convert r128 driver in linux kernel 2.6 to use userland firmware loading
Nathanael Nerode wrote: This is a diff for drivers/char/drm to make r128 use userland-loadable firmware. 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. Following that (in the form of a diff) is the short program I used to create a microcode file which could be shipped as the file /usr/lib/hotplug/r128_cce_microcode (I left it in this form to avoid problems with attaching binaries.) Similar (nearly identical) changes could be made to the radeon driver in the same directory, and I'll be happy to make them if needed. This could probably be improved by someone with a better sense of the right way to deal with the stupid endianness issues; I went with the simplistic pick an endianness choice. 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.) After spending something like 6 hours trawling through the code backwards and forwards, I decided it *probably* wasn't, but I wasn't sure. There's also a faint possibility of deadlock if the userland process which is supposed to load the firmware waits for the DRM module in order to use the screen; this shouldn't happen because it's a background daemon (hotplug), and the standard script only calls cat [file] sysfs/[phony file]. If either of these is a problem, the firmware may have to be loaded and cached in memory at module load time in the module load routine, and only disposed of at module unload. I couldn't actually find those routines, which is one reason I didn't do that. ;-) The other is that it seems like it's a waste of memory to do anything other than retrieving it when it's needed and disposing of it afterwards. Of course, given my lack of DRM experience, there could be any number of other gotchas. :-P My changes are GPL licensed (of course). The r128 module is BSD licensed (though I thought it was supposed to be dual BSD/GPL) - are you willing to reconsider? If not it will be hard to integrate your changes, regardless of their technical merit. Keith --- 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_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] Convert r128 driver in linux kernel 2.6 to use userland firmware loading
On Thu, 15 Apr 2004, Nathanael Nerode wrote: This is a diff for drivers/char/drm to make r128 use userland-loadable firmware. 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. how does this work when the r128 driver is built into the kernel? if no root exists will it fail? these microcode updates are provided by ATI to fix issues with 3D operations in the original microcodes (or at least thats how I understand them :-) Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- 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_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] Convert r128 driver in linux kernel 2.6 to use userland firmware loading
On Thu, 2004-04-15 at 22:00, Nathanael Nerode wrote: This is a diff for drivers/char/drm to make r128 use userland-loadable firmware. Sigh, is this really necessary? :\ Anyway, I'll offer some technical comments. 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? This patch puts Linux specific code in a file that is shared with the BSDs. This could probably be improved by someone with a better sense of 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. Linux provides convenience macros like be32_to_cpu(); not sure about the BSDs; their DRM code seems to define le32_to_cpu() for Linux compatibility, so little endian might be the easier choice. 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. (Incidentally, what *is* this microcode? It looks like it's actually two separate sets of code interleaved.) My understanding is that it contains instructions for the so-called Concurrent Command Engine (CCE) how to translate command packets into register values. This forms the basis of how the DRM emits commands to the hardware. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- 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_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
