07 Mar, 2012
1 commit
-
Signed-off-by: Masanari Iida
Acked-by: Randy Dunlap
Signed-off-by: Jiri Kosina
23 Sep, 2009
1 commit
-
I would like to get rid of option CONFIG_FB_MATROX_MULTIHEAD and just
always enable it. There are many reasons for doing this:* CONFIG_FB_MATROX_MULTIHEAD=y is what all x86 distributions do, so it
definitely works or we would know by now.* Building the matroxfb driver with CONFIG_FB_MATROX_MULTIHEAD not set
results in the following build warning:drivers/video/matrox/matroxfb_crtc2.c: In function 'matroxfb_dh_open':
drivers/video/matrox/matroxfb_crtc2.c:265: warning: the address of 'matroxfb_global_mxinfo' will always evaluate as 'true'
drivers/video/matrox/matroxfb_crtc2.c: In function 'matroxfb_dh_release':
drivers/video/matrox/matroxfb_crtc2.c:285: warning: the address of 'matroxfb_global_mxinfo' will always evaluate as 'true'This is nothing to be worried about, the driver will work fine, but build
warnings are still annoying.* The trick to get multihead support without CONFIG_FB_MATROX_MULTIHEAD,
which is described in the config help text, no longer works: you can't
load the same kernel module more than once.* I fail to see how CONFIG_FB_MATROX_MULTIHEAD=y would make the code
significantly slower, contrary to what the help text says. A few extra
parameters on the stack here and there can't really slow things down in
comaprison to the rest of the code, and register access.* The driver built without CONFIG_FB_MATROX_MULTIHEAD is larger than the
driver build with CONFIG_FB_MATROX_MULTIHEAD=y by 8%.* One less configuration option makes things simpler. We add options
all the time, being able to remove one for once is nice. It improves
testing coverage. And I don't think the Matrox adapters are still
popular enough to warrant overdetailed configuration settings.* We should be able to unobfuscate the driver code quite a bit after
this change (patches follow.)Signed-off-by: Jean Delvare
Acked-by: Petr Vandrovec
Cc: Krzysztof Helt
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
17 Apr, 2005
1 commit
-
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.Let it rip!
