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: NJean Delvare <khali@linux-fr.org>
Acked-by: NPetr Vandrovec <vandrove@vc.cvut.cz>
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>