Writing Linux LCD drivers

 Abstract
1 LCD Module\Driver\Controller
2 Linux Frame Buffer Driver
2.1 Why Frame Buffer?
2.2 What is Frame Buffer Devices?
2.3 How to Write Frame Buffer Device Drivers?
3 Analysis of Linux Frame Buffer Driver Source Codes
3.1 fb.h
3.2 fbmem.c
4 Skeleton of LCD controller rivers
4.1 Allocate a system memory as video memory
4.2 Implement the fb_ops functions
Reference

Abstract
This material discusses how to write a Linux frame buffer LCD device driver.

1 LCD Module\Driver\Controller

Besides the datasheet of LCD devices, there are two quite good books (.pdf format) on LCD technology. Both of them are written in Chinese. One is “液晶显示技术”, and the other is “液晶显示器件”. The two books give almost all needed LCD knowledge, including introductions to hardware implementation of LCD devices and low level software programming used to operate LCD devices. This helps LCD circuits design and low level LCD programming.

2 Linux Frame Buffer Driver

2.1 Why Frame Buffer?
If GUIs (Graphic User Interface) such as MiniGUI, MicroWindows are used, LCD device drivers must be implemented as Linux frame buffer device drivers in addition to those low level operations which only deal with commands provided by LCD controllers.

2.2 What is Frame Buffer Devices?
The frame buffer device provides an abstraction for the graphics hardware. It represents the frame buffer of some video hardware and allows application software to access the graphics hardware through a well-defined interface, so the software doesn't need to know anything about the low-level (hardware register) stuff.
The device is accessed through special device nodes, usually located in the /dev directory, i.e. /dev/fb*.
More description about frame buffer device can be found in two txt files: linux /Documentation /fb /framebuffer.txt and linux /Documentation /fb /interal.txt

2.3 How to Write Frame Buffer Device Drivers?
There are few instructive materials about writing frame buffer device drivers. You may find “Linux Frame buffer Driver Writing HOWTO” at this web page http: //linux-fbdev.sourceforge.net /HOWTO /index.html, but the HOWTO is somewhat curt and not enough. So having a look into Linux source codes is necessary. The next section is an analysis of the related source codes.

3 Analysis of Linux Frame Buffer Driver Source Codes

Linux implements Frame Buffer Drivers mainly based on the groundwork of these two files:
1) linux/include/linux/fb.h
2) linux/drivers/video/fbmem.c
It’s time to have a close look at them.

3.1 fb.h
Almost all important structures are defined in this file. First let me describe what each means and how they are used one by one.


1) fb_var_screeninfo
It is used to describe the features of a video card you normally can set. With fb_var_screeninfo, you can define such things as depth and the resolution you want.

struct fb_var_screeninfo {
__u32 xres; /* visible resolution */
__u32 yres;
__u32 xres_virtual; /* virtual resolution */
__u32 yres_virtual;
__u32 xoffset; /* offset from virtual to visible */
__u32 yoffset; /* resolution */

__u32 bits_per_pixel; /* guess what */
__u32 grayscale; /* != 0 Graylevels instead of colors */

struct fb_bitfield red; /* bitfield in fb mem if true color, */
struct fb_bitfield green; /* else only length is significant */
struct fb_bitfield blue;
struct fb_bitfield transp; /* transparency */

__u32 nonstd; /* != 0 Non standard pixel format */

__u32 activate; /* see FB_ACTIVATE_* */

__u32 height; /* height of picture in mm */
__u32 width; /* width of picture in mm */

__u32 accel_flags; /* acceleration flags (hints) */

/* Timing: All values in pixclocks, except pixclock (of course) */
__u32 pixclock; /* pixel clock in ps (pico seconds) */
__u32 left_margin; /* time from sync to picture */
__u32 right_margin; /* time from picture to sync */
__u32 upper_margin; /* time from sync to picture */
__u32 lower_margin;
__u32 hsync_len; /* length of horizontal sync */
__u32 vsync_len; /* length of vertical sync */
__u32 sync; /* see FB_SYNC_* */
__u32 vmode; /* see FB_VMODE_* */
__u32 reserved[6]; /* Reserved for future compatibility */
};

2) fb_fix_screeninfon
It defines the properties of a card that are created when you set a mode and can't be changed otherwise. A good example is the start address of the framebuffer memory. This can depend on what mode is set. Now while using that mode, you don't want to have the memory position change on you. In this case, the video hardware tells you the memory location and you have no say about it.

struct fb_fix_screeninfo {
char id[16]; /* identification string eg "TT Builtin" */
unsigned long smem_start; /* Start of frame buffer mem */
/* (physical address) */
__u32 smem_len; /* Length of frame buffer mem */
__u32 type; /* see FB_TYPE_* */
__u32 type_aux; /* Interleave for interleaved Planes */
__u32 visual; /* see FB_VISUAL_* */
__u16 xpanstep; /* zero if no hardware panning */
__u16 ypanstep; /* zero if no hardware panning */
__u16 ywrapstep; /* zero if no hardware ywrap */
__u32 line_length; /* length of a line in bytes */
unsigned long mmio_start; /* Start of Memory Mapped I/O */
/* (physical address) */
__u32 mmio_len; /* Length of Memory Mapped I/O */
__u32 accel; /* Type of acceleration available */
__u16 reserved[3]; /* Reserved for future compatibility */
};

3) fb_cmap
Device independent colormap information. You can get and set the colormap using the FBIOGETCMAP and FBIOPUTCMAP ioctls.

struct fb_cmap {
__u32 start; /* First entry */
__u32 len; /* Number of entries */
__u16 *red; /* Red values */
__u16 *green;
__u16 *blue;
__u16 *transp; /* transparency, can be NULL */
};
4) fb_info
It defines the current state of the video card. fb_info is only visible from the kernel. Inside of fb_info, there exist a fb_ops which is a collection of needed functions to make driver work.

struct fb_info {
char modename[40]; /* default video mode */
kdev_t node;
int flags;
int open; /* Has this been open already ? */
#define FBINFO_FLAG_MODULE 1 /* Low-level driver is a module */
struct fb_var_screeninfo var; /* Current var */
struct fb_fix_screeninfo fix; /* Current fix */
struct fb_monspecs monspecs; /* Current Monitor specs */
struct fb_cmap cmap; /* Current cmap */
struct fb_ops *fbops;
char *screen_base; /* Virtual address */
struct display *disp; /* initial display variable */
struct vc_data *display_fg; /* Console visible on this display */
char fontname[40]; /* default font name */
devfs_handle_t devfs_handle; /* Devfs handle for new name */
devfs_handle_t devfs_lhandle; /* Devfs handle for compat. symlink */
int (*changevar)(int); /* tell console var has changed */
int (*switch_con)(int, struct fb_info*);
/* tell fb to switch consoles */
int (*updatevar)(int, struct fb_info*);
/* tell fb to update the vars */
void (*blank)(int, struct fb_info*); /* tell fb to (un)blank the screen */
/* arg = 0: unblank */
/* arg > 0: VESA level (arg-1) */
void *pseudo_palette; /* Fake palette of 16 colors and
the cursor's color for non
palette mode */
/* From here on everything is device dependent */
void *par;
};

5) struct fb_ops
User application program can use ioctl() system call to operate low LCD hardware. Methods defined in fb_ops structure are used to support these operations.

struct fb_ops {