1. 31 12月, 2008 34 次提交
  2. 30 12月, 2008 2 次提交
  3. 29 12月, 2008 4 次提交
    • E
      [ARM] pxafb: add support for overlay1 and overlay2 as framebuffer devices · 198fc108
      Eric Miao 提交于
      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: NEric Miao <eric.miao@marvell.com>
      Cc: Rodolfo Giometti <giometti@linux.it>
      Signed-off-by: NEric Miao <ycmiao@ycmiao-hp520.(none)>
      198fc108
    • E
      [ARM] pxafb: cleanup of the color format manipulation code · 878f5783
      Eric Miao 提交于
      1. introduce var_to_depth() to calculate the color depth including the
         transparency bit
      
      2. the conversion from 'fb_var_screeninfo' to LCCR3 BPP bits can be re-
         used by overlays (in OVLxC1), thus an individual pxafb_var_to_bpp()
         has been separated out.
      
      3. pxafb_setmode() should really set the color bitfields correctly at
         begining, introduce a pxafb_set_pixfmt() for this
      
      4. allow user apps to specify color formats within fb_var_screeninfo,
         and checking of this in pxafb_check_var() has been simplified as
         below:
      
         a) pxafb_var_to_bpp() should pass - which means a basically correct
            bits_per_pixel and color depth setting
         b) the RGBT bitfields are then forced into supported values by
            pxafb_set_pixfmt()
      Signed-off-by: NEric Miao <eric.miao@marvell.com>
      Signed-off-by: NEric Miao <ycmiao@ycmiao-hp520.(none)>
      878f5783
    • E
      [ARM] pxafb: add palette format support for LCCR4_PAL_FOR_3 · a0427509
      Eric Miao 提交于
      Add the palette format support for LCCR4_PAL_FOR_3, and fix the
      issue of LCCR4 being never assigned.
      
      Also remove the useless pxafb_set_truecolor().
      Signed-off-by: NEric Miao <eric.miao@marvell.com>
      Signed-off-by: NEric Miao <ycmiao@ycmiao-hp520.(none)>
      a0427509
    • E
      [ARM] pxafb: add support for FBIOPAN_DISPLAY by dma braching · 6e354846
      Eric Miao 提交于
      dma branching is enabled by extending the current setup_frame_dma()
      function to allow a 2nd set of frame/palette dma descriptors to be
      used.
      
      As a result, pxafb_dma_buff.dma_desc[], pxafb_dma_buff.pal_desc[]
      and pxafb_info.fdadr[] are doubled.
      
      This allows maximum re-use of the current dma setup code, although
      the pxafb_info.fdadr[xx] for FBRx register values looks a bit odd.
      Signed-off-by: NEric Miao <eric.miao@marvell.com>
      Signed-off-by: NEric Miao <ycmiao@ycmiao-hp520.(none)>
      6e354846