Documentation/fb/pxafb.rst

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