1. 29 Dec, 2008 11 commits
    • 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
      3f16ff60
    • Eric Miao's avatar
      [ARM] pxafb: cleanup of the color format manipulation code · 878f5783
      Eric Miao authored
      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: default avatarEric Miao <eric.miao@marvell.com>
      Signed-off-by: default avatarEric Miao <ycmiao@ycmiao-hp520.(none)>
      878f5783
    • Eric Miao's avatar
      [ARM] pxafb: add palette format support for LCCR4_PAL_FOR_3 · a0427509
      Eric Miao authored
      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: default avatarEric Miao <eric.miao@marvell.com>
      Signed-off-by: default avatarEric Miao <ycmiao@ycmiao-hp520.(none)>
      a0427509
    • Eric Miao's avatar
      [ARM] pxafb: add support for FBIOPAN_DISPLAY by dma braching · 6e354846
      Eric Miao authored
      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: default avatarEric Miao <eric.miao@marvell.com>
      Signed-off-by: default avatarEric Miao <ycmiao@ycmiao-hp520.(none)>
      6e354846
    • Eric Miao's avatar
      [ARM] pxafb: allow pxafb_set_par() to start from arbitrary yoffset · 7e4b19c9
      Eric Miao authored
      Note the var->yres_virtual is only re-calculated from the fix.smem_len
      when text mode acceleration is enabled (which is default), this is due
      to the issue as Russell suggested below:
      
      Previous experience of doing this with the X server and acornfb is that
      it causes all sorts of problems - it seems to force the X server into
      assuming that the framebuffer should be panned no matter what settings
      you ask it for.
      
      The recommended workaround (implemented in acornfb) is to only do these
      kinds of adjustments if text mode acceleration is enabled.  IIRC, the X
      server should be disabling text mode acceleration when it maps the
      framebuffer.  I seem to remember that there are X servers which forget
      to do that though.
      Signed-off-by: default avatarEric Miao <eric.miao@marvell.com>
      Signed-off-by: default avatarEric Miao <ycmiao@ycmiao-hp520.(none)>
      7e4b19c9
    • 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
    • Eric Miao's avatar
    • Eric Miao's avatar
      [ARM] sa1100_wdt: don't assume CLOCK_TICK_RATE to be a constant · 28a62385
      Eric Miao authored
      See description of commit:
      
         [ARM] rtc-sa1100: don't assume CLOCK_TICK_RATE to be a constant
      
      for additional information.
      Signed-off-by: default avatarEric Miao <eric.miao@marvell.com>
      28a62385
    • Eric Miao's avatar
      [ARM] rtc-sa1100: don't assume CLOCK_TICK_RATE to be a constant · 6769717d
      Eric Miao authored
      As Nicolas and Russell pointed out, CLOCK_TICK_RATE is no more
      a constant on PXA when multiple processors and platforms are
      selected, change TIMER_FREQ in rtc-sa1100.c into a variable.
      
      Since the code to decide the clock tick rate is re-used from
      timer.c, introduce a common get_clock_tick_rate() for this.
      Signed-off-by: default avatarEric Miao <eric.miao@marvell.com>
      Acked-by: default avatarNicolas Pitre <nico@marvell.com>
      6769717d
    • Eric Miao's avatar
  2. 17 Dec, 2008 15 commits
  3. 02 Dec, 2008 14 commits