Eric Lee / smarc-fsl-linux-kernel

29 Dec, 2008

2 commits

  • 198fc108e   [ARM] pxafb: add support for overlay1 and overlay2 as framebuffer devices ... Browse Code »

    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: Eric Miao
    Cc: Rodolfo Giometti
    Signed-off-by: Eric Miao

    Eric Miao
     
  • 77e196752   [ARM] pxafb: allow video memory size to be configurable ... Browse Code »

    The amount of video memory size is decided according to the following
    order:

    1. x x 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: Eric Miao
    Signed-off-by: Eric Miao

    Eric Miao
     

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds