16 Mar, 2011

1 commit

  • PXAFB overlay memory management is something messy:
    - it allocates memory dynamically on open/release, and it results
    in memory allocation failure after ~1h of uptime (system does not have
    115k of physically contiguous memory)
    - in release callback it tries to free memory even if it was not
    allocated.

    Also driver touches FDADR1 on main plane reconfiguration, and it can cause
    problems if overlay1 is enabled.

    This patch attempts to fix those issues.

    Patch is based on Russell King's work.

    Signed-off-by: Vasily Khoruzhick
    Signed-off-by: Eric Miao

    Vasily Khoruzhick
     

29 Dec, 2008

4 commits

  • 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
     
  • Signed-off-by: Eric Miao
    Signed-off-by: Eric Miao

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

    Eric Miao
     
  • 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
     

02 Dec, 2008

1 commit


25 Jul, 2008

1 commit


30 Apr, 2008

5 commits

  • Signed-off-by: Daniel Mack
    Signed-off-by: Eric Miao
    Cc: "Antonino A. Daplas"
    Cc: Russell King
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Eric Miao
     
  • the new_regs stuff has been removed, and all the setup (modification to those
    fbi->reg_*) is protected with IRQ disabled

    * disable IRQ is too heavy here, provided that no IRQ context will
    touch the fbi->reg_* and the only possible contending place is
    in the CPUFREQ_POSTCHANGE (task context), a mutex will be better,
    leave this for future improvement

    Signed-off-by: eric miao
    Cc: "Antonino A. Daplas"
    Cc: Russell King
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Eric Miao
     
  • Signed-off-by: eric miao
    Cc: "Antonino A. Daplas"
    Cc: Russell King
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Eric Miao
     
  • Use structure and array for palette buffer and dma descriptors to:

    1. better organize code for future expansion like overlays
    2. separate palette and dma descriptors from frame buffer

    Signed-off-by: eric miao
    Cc: "Antonino A. Daplas"
    Cc: Russell King
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    eric miao
     
  • This is part of the effort moving peripheral registers outside of pxa-regs.h,
    and using ioremap() make it possible the same IP can be re-used on different
    processors with different registers space

    As a result, the fixed mapping in pxa_map_io() is removed.

    The regs-lcd.h can actually moved to where closer to pxafb.c but some of its
    bit definitions are directly used by various platform code, though this is not
    a good style.

    Signed-off-by: eric miao
    Cc: "Antonino A. Daplas"
    Cc: Russell King
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    eric miao
     

17 Oct, 2007

1 commit

  • This patch adds support for the other three palette formats possible with
    the PXA LCD controller. This is required on boards where an LCD is connected
    with all its 18 bits. With this patch, it's possible to use an 8-bit mode
    with 18-bit palette entries. This used to be possible in 2.4 kernels but
    disappeared in 2.6. With current kernels, you can only get wrong colours
    out of an LCD connected this way.

    Users can choose the palette format by doing something like this
    in their board definition:

    static struct pxafb_mach_info my_fb_info = {
    [...]
    .lccr3 = LCCR3_OutEnH | LCCR3_PixFlEdg | LCCR3_PDFOR_3,
    .lccr4 = LCCR4_PAL_FOR_2,
    [...]
    };

    Signed-off-by: Hans J. Koch
    Signed-off-by: Antonino Daplas
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Hans J. Koch
     

13 Oct, 2007

1 commit


02 Oct, 2006

1 commit

  • Add the ability to have pxafb use only certain fixed video modes
    (selected on a per platform basis). This is useful on production
    hardware such as the Zaurus cxx00 models where the valid modes are
    known in advance and any other modes could result in hardware damage.

    Following this, add support for the cxx00 QVGA mode. Mode information
    is passed to the lcd_power call to allowing the panel drivers to
    configure the display hardware accordingly (corgi_lcd already contains
    the functionality for the cxx00 panel).

    This mirrors the setup already used by w100fb.

    Signed-off-by: Richard Purdie
    Signed-off-by: Russell King

    Richard Purdie
     

29 Sep, 2005

1 commit


10 Sep, 2005

1 commit

  • To solve touchscreen interference problems devices like the Sharp Zaurus
    SL-C3000 need to know the length of the horitzontal sync pulses. This patch
    adds a hook to pxafb so the touchscreen driver can function correctly.

    Signed-Off-By: Richard Purdie
    Signed-off-by: Antonino Daplas
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Richard Purdie
     

17 Apr, 2005

1 commit

  • 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