1. 09 Mar, 2009 4 commits
  2. 10 Feb, 2009 2 commits
  3. 02 Feb, 2009 6 commits
  4. 21 Jan, 2009 8 commits
  5. 20 Jan, 2009 1 commit
  6. 18 Jan, 2009 3 commits
  7. 08 Jan, 2009 2 commits
    • Russell King's avatar
      [ARM] fix pxa · 21da67a2
      Russell King authored
      
      
      arch/arm/mach-pxa/pxa300.c:94: error: 'CKEN_MMC3' undeclared here (not in a function)
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      21da67a2
    • Russell King's avatar
      [ARM] fix AT91, davinci, h720x, ks8695, msm, mx2, mx3, netx, omap1, omap2, pxa, s3c · 80b02c17
      Russell King authored
      
      
      arch/arm/mach-at91/at91cap9.c:337: error: 'NR_AIC_IRQS' undeclared here (not in a function)
      arch/arm/mach-at91/at91rm9200.c:301: error: 'NR_AIC_IRQS' undeclared here (not in a function)
      arch/arm/mach-at91/at91sam9260.c:351: error: 'NR_AIC_IRQS' undeclared here (not in a function)
      arch/arm/mach-at91/at91sam9261.c:287: error: 'NR_AIC_IRQS' undeclared here (not in a function)
      arch/arm/mach-at91/at91sam9263.c:312: error: 'NR_AIC_IRQS' undeclared here (not in a function)
      arch/arm/mach-at91/at91sam9rl.c:304: error: 'NR_AIC_IRQS' undeclared here (not in a function)
      arch/arm/mach-h720x/h7202-eval.c:38: error: implicit declaration of function 'IRQ_CHAINED_GPIOB'
      arch/arm/mach-ks8695/devices.c:46: error: 'KS8695_IRQ_WAN_RX_STATUS' undeclared here (not in a function)
      arch/arm/mach-msm/devices.c:28: error: 'INT_UART1' undeclared here (not in a function)
      arch/arm/mach-mx2/devices.c:233: error: 'MXC_GPIO_IRQ_START' undeclared here (not in a function)
      arch/arm/mach-mx3/devices.c:128: error: 'MXC_GPIO_IRQ_START' undeclared here (not in a function)
      arch/arm/mach-omap1/mcbsp.c:140: error: 'INT_730_McBSP1RX' undeclared here (not in a function)
      arch/arm/mach-omap1/mcbsp.c:165: error: 'INT_McBSP1RX' undeclared here (not in a function)
      arch/arm/mach-omap1/mcbsp.c:200: error: 'INT_McBSP1RX' undeclared here (not in a function)
      arch/arm/mach-omap2/board-apollon.c:286: error: implicit declaration of function 'omap_set_gpio_direction'
      arch/arm/mach-omap2/mcbsp.c:154: error: 'INT_24XX_MCBSP1_IRQ_RX' undeclared here (not in a function)
      arch/arm/mach-omap2/mcbsp.c:181: error: 'INT_24XX_MCBSP1_IRQ_RX' undeclared here (not in a function)
      arch/arm/mach-pxa/e350.c:36: error: 'IRQ_BOARD_START' undeclared here (not in a function)
      arch/arm/plat-s3c/dev-i2c0.c:32: error: 'IRQ_IIC' undeclared here (not in a function)
      ...
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      80b02c17
  8. 30 Dec, 2008 1 commit
  9. 29 Dec, 2008 9 commits
    • Yong Yao's avatar
    • Yong Yao's avatar
      105ca239
    • 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: 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 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
      [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
  10. 17 Dec, 2008 4 commits