1. 03 Sep, 2009 1 commit
    • Jean Delvare's avatar
      I would like to get rid of option CONFIG_FB_MATROX_MULTIHEAD and just · e05b4fd2
      Jean Delvare authored
      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: default avatarJean Delvare <khali@linux-fr.org>
      Acked-by: default avatarPetr Vandrovec <vandrove@vc.cvut.cz>
      Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      e05b4fd2
  2. 22 Aug, 2009 1 commit
    • Florian Tobias Schandinat's avatar
      At the moment about half of the framebuffer drivers can return an error · 713370f1
      Florian Tobias Schandinat authored
      code in fb_set_par. Until now it would be silently ignored by fbmem.c
      and fbcon.c. This patch fixes fbmem.c to return the error code and
      restore var on error.
      
      But it is not clear in which video mode the device is when fb_set_par
      fails.  It would be good and reasonable if it were in the old state but
      there is no guarantee that this is true for all existing drivers. 
      Additionally print a message if a failing fb_set_par is detected in
      fbmem.c or fbcon.c.
      
      Although most errors should be caught by the previous fb_check_var some
      errors can't as they are dynamic (memory allocations, ...) and can only be
      detected while performing the operations which is forbidden in
      fb_check_var.
      
      This patch shouldn't have a negative impact on normal operation as all
      drivers return 0 on success.  The impact in case of error depends heavily
      on the driver and caller but it's expected to be better than before.
      Signed-off-by: default avatarFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      713370f1
  3. 20 Aug, 2009 2 commits
  4. 06 Aug, 2009 1 commit
  5. 03 Aug, 2009 2 commits
  6. 31 Jul, 2009 1 commit
  7. 09 Sep, 2009 7 commits
  8. 05 Sep, 2009 1 commit
  9. 03 Sep, 2009 1 commit
    • Florian Tobias Schandinat's avatar
      This patch is a completly rewritten 2D engine. The engine is no longer in · 366244e4
      Florian Tobias Schandinat authored
      a default state but reinitialized every time to allow usage for both
      framebuffers regardless of their settings.
      
      The whole engine handling is concentrated in a big function which takes 16
      parameters.  Although the number of parameters is worryingly it is good to
      have a single funtion to deal with this stuff as it allows to easily
      support different engines and avoids some code duplication.
      
      On the way support for the new 2D engine in VX800 was added.  As the with
      less code duplication but it is probably better to duplicate the code as
      this way is easier to walk if VIA ever decides to release a new engine
      which changes anything the driver touches.
      
      The engine support for VX800 gives a notable boost in speed.  There are no
      known regressions but as this patch changes paths I do neither have the
      hardware nor documentation to check and has the possibility to put the
      system in a critical state heavy testing is appreciated.
      Signed-off-by: default avatarFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      Cc: Scott Fang <ScottFang@viatech.com.cn>
      Cc: Joseph Chan <JosephChan@via.com.tw>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      366244e4
  10. 27 Aug, 2009 3 commits
  11. 22 Aug, 2009 1 commit
  12. 20 Aug, 2009 4 commits
  13. 15 Aug, 2009 1 commit
  14. 06 Aug, 2009 2 commits
  15. 31 Jul, 2009 2 commits
  16. 25 Jul, 2009 1 commit
  17. 24 Aug, 2009 1 commit
  18. 31 Jul, 2009 1 commit
  19. 25 Jul, 2009 1 commit
  20. 31 Jul, 2009 1 commit
  21. 24 Jul, 2009 2 commits
  22. 24 Aug, 2009 1 commit
  23. 13 Jul, 2009 1 commit
  24. 29 Jun, 2009 1 commit