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