pxafb.rst 4.6 KB

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