summaryrefslogtreecommitdiffstats
path: root/Documentation/fb/pxafb.rst
diff options
context:
space:
mode:
authorDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-07 18:49:45 +0000
committerDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-07 18:49:45 +0000
commit2c3c1048746a4622d8c89a29670120dc8fab93c4 (patch)
tree848558de17fb3008cdf4d861b01ac7781903ce39 /Documentation/fb/pxafb.rst
parentInitial commit. (diff)
downloadlinux-2c3c1048746a4622d8c89a29670120dc8fab93c4.tar.xz
linux-2c3c1048746a4622d8c89a29670120dc8fab93c4.zip
Adding upstream version 6.1.76.upstream/6.1.76upstream
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'Documentation/fb/pxafb.rst')
-rw-r--r--Documentation/fb/pxafb.rst173
1 files changed, 173 insertions, 0 deletions
diff --git a/Documentation/fb/pxafb.rst b/Documentation/fb/pxafb.rst
new file mode 100644
index 000000000..90177f5e7
--- /dev/null
+++ b/Documentation/fb/pxafb.rst
@@ -0,0 +1,173 @@
+================================
+Driver for PXA25x LCD controller
+================================
+
+The driver supports the following options, either via
+options=<OPTIONS> when modular or video=pxafb:<OPTIONS> when built in.
+
+For example::
+
+ modprobe pxafb options=vmem:2M,mode:640x480-8,passive
+
+or on the kernel command line::
+
+ video=pxafb:vmem:2M,mode:640x480-8,passive
+
+vmem: VIDEO_MEM_SIZE
+
+ Amount of video memory to allocate (can be suffixed with K or M
+ for kilobytes or megabytes)
+
+mode:XRESxYRES[-BPP]
+
+ XRES == LCCR1_PPL + 1
+
+ YRES == LLCR2_LPP + 1
+
+ The resolution of the display in pixels
+
+ BPP == The bit depth. Valid values are 1, 2, 4, 8 and 16.
+
+pixclock:PIXCLOCK
+
+ Pixel clock in picoseconds
+
+left:LEFT == LCCR1_BLW + 1
+
+right:RIGHT == LCCR1_ELW + 1
+
+hsynclen:HSYNC == LCCR1_HSW + 1
+
+upper:UPPER == LCCR2_BFW
+
+lower:LOWER == LCCR2_EFR
+
+vsynclen:VSYNC == LCCR2_VSW + 1
+
+ Display margins and sync times
+
+color | mono => LCCR0_CMS
+
+ umm...
+
+active | passive => LCCR0_PAS
+
+ Active (TFT) or Passive (STN) display
+
+single | dual => LCCR0_SDS
+
+ Single or dual panel passive display
+
+4pix | 8pix => LCCR0_DPD
+
+ 4 or 8 pixel monochrome single panel data
+
+hsync:HSYNC, vsync:VSYNC
+
+ Horizontal and vertical sync. 0 => active low, 1 => active
+ high.
+
+dpc:DPC
+
+ Double pixel clock. 1=>true, 0=>false
+
+outputen:POLARITY
+
+ Output Enable Polarity. 0 => active low, 1 => active high
+
+pixclockpol:POLARITY
+
+ pixel clock polarity
+ 0 => falling edge, 1 => rising edge
+
+
+Overlay Support for PXA27x and later LCD controllers
+====================================================
+
+ 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.
+
+ However, there are some differences between these overlay framebuffers
+ and normal framebuffers, as listed below:
+
+ 1. overlay can start at a 32-bit word aligned position within the base
+ framebuffer, which means they have a start (x, y). This information
+ is encoded into var->nonstd (no, var->xoffset and var->yoffset are
+ not for such purpose).
+
+ 2. overlay framebuffer is allocated dynamically according to specified
+ 'struct fb_var_screeninfo', the amount is decided by::
+
+ var->xres_virtual * var->yres_virtual * bpp
+
+ bpp = 16 -- for RGB565 or RGBT555
+
+ bpp = 24 -- for YUV444 packed
+
+ bpp = 24 -- for YUV444 planar
+
+ bpp = 16 -- for YUV422 planar (1 pixel = 1 Y + 1/2 Cb + 1/2 Cr)
+
+ bpp = 12 -- for YUV420 planar (1 pixel = 1 Y + 1/4 Cb + 1/4 Cr)
+
+ NOTE:
+
+ a. overlay does not support panning in x-direction, thus
+ var->xres_virtual will always be equal to var->xres
+
+ b. line length of overlay(s) must be on a 32-bit word boundary,
+ for YUV planar modes, it is a requirement for the component
+ with minimum bits per pixel, e.g. for YUV420, Cr component
+ for one pixel is actually 2-bits, it means the line length
+ should be a multiple of 16-pixels
+
+ c. starting horizontal position (XPOS) should start on a 32-bit
+ word boundary, otherwise the fb_check_var() will just fail.
+
+ d. the rectangle of the overlay should be within the base plane,
+ otherwise fail
+
+ Applications should follow the sequence below to operate an overlay
+ framebuffer:
+
+ a. open("/dev/fb[1-2]", ...)
+ b. ioctl(fd, FBIOGET_VSCREENINFO, ...)
+ c. modify 'var' with desired parameters:
+
+ 1) var->xres and var->yres
+ 2) larger var->yres_virtual if more memory is required,
+ usually for double-buffering
+ 3) var->nonstd for starting (x, y) and color format
+ 4) var->{red, green, blue, transp} if RGB mode is to be used
+
+ d. ioctl(fd, FBIOPUT_VSCREENINFO, ...)
+ e. ioctl(fd, FBIOGET_FSCREENINFO, ...)
+ f. mmap
+ g. ...
+
+ 3. for YUV planar formats, these are actually not supported within the
+ framebuffer framework, application has to take care of the offsets
+ and lengths of each component within the framebuffer.
+
+ 4. var->nonstd is used to pass starting (x, y) position and color format,
+ the detailed bit fields are shown below::
+
+ 31 23 20 10 0
+ +-----------------+---+----------+----------+
+ | ... unused ... |FOR| XPOS | YPOS |
+ +-----------------+---+----------+----------+
+
+ FOR - color format, as defined by OVERLAY_FORMAT_* in pxafb.h
+
+ - 0 - RGB
+ - 1 - YUV444 PACKED
+ - 2 - YUV444 PLANAR
+ - 3 - YUV422 PLANAR
+ - 4 - YUR420 PLANAR
+
+ XPOS - starting horizontal position
+
+ YPOS - starting vertical position