Skip to content
Snippets Groups Projects
  1. Jul 25, 2011
    • Rolf Eike Beer's avatar
      DRM: clean up and document parsing of video= parameter · 04fee895
      Rolf Eike Beer authored
      
      The video= parameter of the DRM drivers supports some additional flags that
      the normal fb drivers do not have. They also allow to limit these flags to
      specific outputs. Both things were previously undocumented.
      
      Also the parsing of the line had some oddities:
      -A lot of misplaced options were silently ignored or partly rejected instead
       of stopping the parsing immediately
      -The 'R' option is documented to follow the 'M' option if specified. It is not
       documented that 'M' is needed to specify 'R' (also this is the case for normal
       fb drivers). In fact the code is correct for normal fb drivers but wrong for
       DRM ones.
       The old code allowed 'R' only _before_ 'M' (since it parses backwards) and only
       if 'M' is given at all which is not needed for the DRM drivers.
      -the margins option ('m') was parsed but later ignored even if the later
       functions support it.
      -specifying multiple enable options at the same time did not lead to an error.
      -specifying something bogus for horizontal resolution (i.e. other things as
       digits) did not lead to an error but an invalid resolution was used.
      
      If any errors are encountered the position of the faulting string is now
      printed to the user and the complete mode is ignored. This gives much
      more consistent error behaviour.
      
      I also removed some useless assignments and changed the local flag variables
      to be bool.
      
      Signed-off-by: default avatarRolf Eike Beer <eike-kernel@sf-tec.de>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      04fee895
  2. Mar 31, 2011
  3. Mar 22, 2011
    • Heiko Schocher's avatar
      video, sm501: add edid and commandline support · e6a04980
      Heiko Schocher authored
      
      - add commandline options:
        sm501fb.mode:
          Specify resolution as "<xres>x<yres>[-<bpp>][@<refresh>]"
        sm501fb.bpp:
          Specify bit-per-pixel if not specified mode
      
      - Add support for encoding display mode information
        in the device tree using verbatim EDID block.
      
        If the "edid" entry in the "smi,sm501" node is present,
        the driver will build mode database using EDID data
        and allow setting the display modes from this database.
      
      Signed-off-by: default avatarHeiko Schocher <hs@denx.de>
      cc: linux-fbdev@vger.kernel.org
      cc: devicetree-discuss@ozlabs.org
      cc: Ben Dooks <ben@simtec.co.uk>
      cc: Vincent Sanders <vince@simtec.co.uk>
      cc: Samuel Ortiz <sameo@linux.intel.com>
      cc: linux-kernel@vger.kernel.org
      cc: Randy Dunlap <rdunlap@xenotime.net>
      cc: Paul Mundt <lethal@linux-sh.org>
      Signed-off-by: default avatarPaul Mundt <lethal@linux-sh.org>
      e6a04980
  4. Nov 17, 2010
  5. Nov 15, 2010
  6. Sep 23, 2010
  7. Aug 04, 2010
    • Justin P. Mattock's avatar
      Documentation: update broken web addresses. · 0ea6e611
      Justin P. Mattock authored
      
      Below you will find an updated version from the original series bunching all patches into one big patch
      updating broken web addresses that are located in Documentation/*
      Some of the addresses date as far far back as 1995 etc... so searching became a bit difficult,
      the best way to deal with these is to use web.archive.org to locate these addresses that are outdated.
      Now there are also some addresses pointing to .spec files some are located, but some(after searching
      on the companies site)where still no where to be found. In this case I just changed the address
      to the company site this way the users can contact the company and they can locate them for the users.
      
      Signed-off-by: default avatarJustin P. Mattock <justinmattock@gmail.com>
      Signed-off-by: default avatarThomas Weber <weber@corscience.de>
      Signed-off-by: default avatarMike Frysinger <vapier.adi@gmail.com>
      Cc: Paulo Marques <pmarques@grupopie.com>
      Cc: Randy Dunlap <rdunlap@xenotime.net>
      Cc: Michael Neuling <mikey@neuling.org>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      0ea6e611
  8. Apr 07, 2010
  9. Dec 16, 2009
  10. Nov 30, 2009
  11. Sep 23, 2009
    • Jean Delvare's avatar
      matroxfb: make CONFIG_FB_MATROX_MULTIHEAD=y mandatory · 0728bacb
      Jean Delvare authored
      
      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: 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>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      0728bacb
    • Ryan Mallon's avatar
      ep93xx video driver · 88017bda
      Ryan Mallon authored
      
      EP93xx video driver plus documentation.
      
      Signed-off-by: default avatarRyan Mallon <ryan@bluewatersys.com>
      Acked-by: default avatarH Hartley Sweeten <hsweeten@visionengravers.com>
      Cc: Daniele Venzano <linux@brownhat.org>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      88017bda
  12. Jun 16, 2009
  13. Jun 12, 2009
  14. Apr 07, 2009
  15. Apr 01, 2009
    • Krzysztof Helt's avatar
      fbdev: remove cyblafb driver · ddb53d48
      Krzysztof Helt authored
      
      A tridentfb driver has all the functionality of the cyblafb driver without
      the bugs of the latter.
      
      Changes to the tridentfb driver:
      
      - FBINFO_READS_FAST added to the tridentfb.  The cyblafb used a blitter
        for scrolling which is faster than color expansion on Cyberblade
        chipsets.  The blitter is slower on a discrete Blade3D core.  Use the
        blitter for scrolling in the tridentfb only for integrated Blade3D
        cores.  Now, scrolling speed is about equal for the tridentfb and the
        cyblafb.
      
      - a copyright notice addition is done on request of Jani Monoses (the
        first author of the tridentfb).
      
      Tested on AGP Blade3D card and PCChips
      M787CLR motherboard: VIA C3 cpu +
      VT8601 north  bridge (aka Cyberblade/i1).
      
      Signed-off-by: default avatarKrzysztof Helt <krzysztof.h1@wp.pl>
      Cc: "Jani Monoses" <jani@ubuntu.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ddb53d48
  16. Dec 29, 2008
    • Eric Miao's avatar
      [ARM] pxafb: add support for overlay1 and overlay2 as framebuffer devices · 198fc108
      Eric Miao authored
      
      PXA27x and later processors support overlay1 and overlay2 on-top of the
      base framebuffer (although under-neath the base is also possible). They
      support palette and no-palette RGB formats, as well as YUV formats (only
      available on overlay2). These overlays have dedicated DMA channels and
      behave in a similar way as a framebuffer.
      
      This heavily simplified and re-structured work is based on the original
      pxafb_overlay.c (which is pending for mainline merge for a long time).
      
      The major problems with this pxafb_overlay.c are (if you are interested
      in the history):
      
        1. heavily redundant (the control logics for overlay1 and overlay2 are
           actually identical except for some small operations,  which are now
           abstracted into a 'pxafb_layer_ops' structure)
      
        2. a lot of useless and un-tested code (two workarounds which are now
           fixed on mature silicons)
      
        3. cursorfb is actually useless, hardware cursor should not be used
           this way, and the code was actually un-tested for a long time.
      
      The code in this patch should be self-explanatory, I tried to add minimum
      comments. As said, this is basically simplified, there are several things
      still on the pending list:
      
        1. palette mode is un-supported and un-tested (although re-using the
           palette code of the base framebuffer is actually very easy now with
           previous clean-up patches)
      
        2. fb_pan_display for overlay(s) is un-supported
      
        3. the base framebuffer can actually be abstracted by 'pxafb_layer' as
           well, which will help further re-use of the code and keep a better
           and consistent structure. (This is the reason I named it 'pxafb_layer'
           instead of 'pxafb_overlay' or something alike)
      
      See Documentation/fb/pxafb.txt for additional usage information.
      
      Signed-off-by: default avatarEric Miao <eric.miao@marvell.com>
      Cc: Rodolfo Giometti <giometti@linux.it>
      Signed-off-by: default avatarEric Miao <ycmiao@ycmiao-hp520.(none)>
      198fc108
    • Eric Miao's avatar
      [ARM] pxafb: allow video memory size to be configurable · 77e19675
      Eric Miao authored
      
      The amount of video memory size is decided according to the following
      order:
      
      1. <xres> x <yres> x <bits_per_pixel> by default, which is the backward
         compatible way
      
      2. size specified in platform data
      
      3. size specified in module parameter 'options' string or specified in
         kernel boot command line (see updated Documentation/fb/pxafb.txt)
      
      And now since the memory is allocated from system memory, the pxafb_mmap
      can be removed and the default fb_mmap() should be working all right.
      
      Also, since we now have introduced the 'struct pxafb_dma_buff' for DMA
      descriptors and palettes, the allocation can be separated cleanly.
      
      NOTE: the LCD DMA actually supports chained transfer (i.e. page-based
      transfers), to simplify the logic and keep the performance (with less
      TLB misses when accessing from memory mapped user space), the memory
      is allocated by alloc_pages_*() to ensures it's physical contiguous.
      
      Signed-off-by: default avatarEric Miao <eric.miao@marvell.com>
      Signed-off-by: default avatarEric Miao <ycmiao@ycmiao-hp520.(none)>
      77e19675
  17. Oct 16, 2008
  18. Jul 24, 2008
  19. Apr 28, 2008
  20. Mar 19, 2008
  21. Feb 06, 2008
  22. Oct 19, 2007
  23. Oct 16, 2007
  24. Aug 11, 2007
  25. May 09, 2007
Loading