linux/Documentation/fb/pxafb.txt
<<
>>
Prefs
   1Driver for PXA25x LCD controller
   2================================
   3
   4The driver supports the following options, either via
   5options=<OPTIONS> when modular or video=pxafb:<OPTIONS> when built in.
   6
   7For example:
   8        modprobe pxafb options=vmem:2M,mode:640x480-8,passive
   9or on the kernel command line
  10        video=pxafb:vmem:2M,mode:640x480-8,passive
  11
  12vmem: VIDEO_MEM_SIZE
  13        Amount of video memory to allocate (can be suffixed with K or M
  14        for kilobytes or megabytes)
  15
  16mode:XRESxYRES[-BPP]
  17        XRES == LCCR1_PPL + 1
  18        YRES == LLCR2_LPP + 1
  19                The resolution of the display in pixels
  20        BPP == The bit depth. Valid values are 1, 2, 4, 8 and 16.
  21
  22pixclock:PIXCLOCK
  23        Pixel clock in picoseconds
  24
  25left:LEFT == LCCR1_BLW + 1
  26right:RIGHT == LCCR1_ELW + 1
  27hsynclen:HSYNC == LCCR1_HSW + 1
  28upper:UPPER == LCCR2_BFW
  29lower:LOWER == LCCR2_EFR
  30vsynclen:VSYNC == LCCR2_VSW + 1
  31        Display margins and sync times
  32
  33color | mono => LCCR0_CMS
  34        umm...
  35
  36active | passive => LCCR0_PAS
  37        Active (TFT) or Passive (STN) display
  38
  39single | dual => LCCR0_SDS
  40        Single or dual panel passive display
  41
  424pix | 8pix => LCCR0_DPD
  43        4 or 8 pixel monochrome single panel data
  44
  45hsync:HSYNC
  46vsync:VSYNC
  47        Horizontal and vertical sync. 0 => active low, 1 => active
  48        high.
  49
  50dpc:DPC
  51        Double pixel clock. 1=>true, 0=>false
  52
  53outputen:POLARITY
  54        Output Enable Polarity. 0 => active low, 1 => active high
  55
  56pixclockpol:POLARITY
  57        pixel clock polarity
  58        0 => falling edge, 1 => rising edge
  59
  60
  61Overlay Support for PXA27x and later LCD controllers
  62====================================================
  63
  64  PXA27x and later processors support overlay1 and overlay2 on-top of the
  65  base framebuffer (although under-neath the base is also possible). They
  66  support palette and no-palette RGB formats, as well as YUV formats (only
  67  available on overlay2). These overlays have dedicated DMA channels and
  68  behave in a similar way as a framebuffer.
  69
  70  However, there are some differences between these overlay framebuffers
  71  and normal framebuffers, as listed below:
  72
  73  1. overlay can start at a 32-bit word aligned position within the base
  74     framebuffer, which means they have a start (x, y). This information
  75     is encoded into var->nonstd (no, var->xoffset and var->yoffset are
  76     not for such purpose).
  77
  78  2. overlay framebuffer is allocated dynamically according to specified
  79     'struct fb_var_screeninfo', the amount is decided by:
  80
  81        var->xres_virtual * var->yres_virtual * bpp
  82
  83     bpp = 16 -- for RGB565 or RGBT555
  84         = 24 -- for YUV444 packed
  85         = 24 -- for YUV444 planar
  86         = 16 -- for YUV422 planar (1 pixel = 1 Y + 1/2 Cb + 1/2 Cr)
  87         = 12 -- for YUV420 planar (1 pixel = 1 Y + 1/4 Cb + 1/4 Cr)
  88
  89     NOTE:
  90
  91     a. overlay does not support panning in x-direction, thus
  92        var->xres_virtual will always be equal to var->xres
  93
  94     b. line length of overlay(s) must be on a 32-bit word boundary,
  95        for YUV planar modes, it is a requirement for the component
  96        with minimum bits per pixel,  e.g. for YUV420, Cr component
  97        for one pixel is actually 2-bits, it means the line length
  98        should be a multiple of 16-pixels
  99
 100     c. starting horizontal position (XPOS) should start on a 32-bit
 101        word boundary, otherwise the fb_check_var() will just fail.
 102
 103     d. the rectangle of the overlay should be within the base plane,
 104        otherwise fail
 105
 106     Applications should follow the sequence below to operate an overlay
 107     framebuffer:
 108
 109         a. open("/dev/fb[1-2]", ...)
 110         b. ioctl(fd, FBIOGET_VSCREENINFO, ...)
 111         c. modify 'var' with desired parameters:
 112            1) var->xres and var->yres
 113            2) larger var->yres_virtual if more memory is required,
 114               usually for double-buffering
 115            3) var->nonstd for starting (x, y) and color format
 116            4) var->{red, green, blue, transp} if RGB mode is to be used
 117         d. ioctl(fd, FBIOPUT_VSCREENINFO, ...)
 118         e. ioctl(fd, FBIOGET_FSCREENINFO, ...)
 119         f. mmap
 120         g. ...
 121
 122  3. for YUV planar formats, these are actually not supported within the
 123     framebuffer framework, application has to take care of the offsets
 124     and lengths of each component within the framebuffer.
 125
 126  4. var->nonstd is used to pass starting (x, y) position and color format,
 127     the detailed bit fields are shown below:
 128
 129    31                23  20         10          0
 130     +-----------------+---+----------+----------+
 131     |  ... unused ... |FOR|   XPOS   |   YPOS   |
 132     +-----------------+---+----------+----------+
 133
 134     FOR  - color format, as defined by OVERLAY_FORMAT_* in pxafb.h
 135            0 - RGB
 136            1 - YUV444 PACKED
 137            2 - YUV444 PLANAR
 138            3 - YUV422 PLANAR
 139            4 - YUR420 PLANAR
 140
 141     XPOS - starting horizontal position
 142     YPOS - starting vertical position
 143
lxr.linux.no kindly hosted by Redpill Linpro AS, provider of Linux consulting and operations services since 1995.