On 7/14/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
After a very brief look on the relevant part of the patch: -> Needs to be adapted to CodingStyle all over.
I agree, this can be done if it was ever going to be included.
-> The use of AMD specific BUILDNUM etc are not used in-kernel
This can be cleaned up as well, or put behind some #ifdef to allow AMD to keep using their own system, I suppose.
-> The HAL in lib/cimarron needs to be justified - who are the oter users?
The HAL is used by the driver, obviously, but is included in lib/cimarron for any other module writers which want to access the graphics hardware from inside the kernel. When you're developing a user app and want to access the hardware, you link Cimarron into your code directly. I'm not sure what other kernel modules AMD expected to be written, but I'm guessing they just wanted to keep their HAL and write the framebuffer driver in terms of that instead of maintaining a user-space HAL and a duplicate kernel driver.
-> There seems to be a _lot_ of specific defines in lib/cimarron - I wonder if this is the way used in the rest of the kernel?
Which defines are you referring to? I know there are a few 'settings' which are modified by changing #defines in one of the .h files. I'm assuming that those would be moved to Kconfig values if this was ever in the kernel.
But anyway - the patch it not trivially ready for inclusion.
I agree. I just did the work to port it from 2.6.11 to 2.6.22 just to get it working in my tree. It all builds cleanly now, so any work would most likely be cosmetic to clean up the code base. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
