1
0
Fork 0
alistair23-linux/drivers/video/fbdev/pxafb.h

205 lines
4.3 KiB
C
Raw Normal View History

#ifndef __PXAFB_H__
#define __PXAFB_H__
/*
* linux/drivers/video/pxafb.h
* -- Intel PXA250/210 LCD Controller Frame Buffer Device
*
* Copyright (C) 1999 Eric A. Thomas.
* Copyright (C) 2004 Jean-Frederic Clere.
* Copyright (C) 2004 Ian Campbell.
* Copyright (C) 2004 Jeff Lackey.
* Based on sa1100fb.c Copyright (C) 1999 Eric A. Thomas
* which in turn is
* Based on acornfb.c Copyright (C) Russell King.
*
* 2001-08-03: Cliff Brake <cbrake@acclent.com>
* - ported SA1100 code to PXA
*
* This file is subject to the terms and conditions of the GNU General Public
* License. See the file COPYING in the main directory of this archive
* for more details.
*/
/* PXA LCD DMA descriptor */
struct pxafb_dma_descriptor {
unsigned int fdadr;
unsigned int fsadr;
unsigned int fidr;
unsigned int ldcmd;
};
enum {
PAL_NONE = -1,
PAL_BASE = 0,
PAL_OV1 = 1,
PAL_OV2 = 2,
PAL_MAX,
};
enum {
DMA_BASE = 0,
DMA_UPPER = 0,
DMA_LOWER = 1,
DMA_OV1 = 1,
DMA_OV2_Y = 2,
DMA_OV2_Cb = 3,
DMA_OV2_Cr = 4,
DMA_CURSOR = 5,
DMA_CMD = 6,
DMA_MAX,
};
/* maximum palette size - 256 entries, each 4 bytes long */
#define PALETTE_SIZE (256 * 4)
#define CMD_BUFF_SIZE (1024 * 50)
/* NOTE: the palette and frame dma descriptors are doubled to allow
* the 2nd set for branch settings (FBRx)
*/
struct pxafb_dma_buff {
unsigned char palette[PAL_MAX * PALETTE_SIZE];
uint16_t cmd_buff[CMD_BUFF_SIZE];
struct pxafb_dma_descriptor pal_desc[PAL_MAX * 2];
struct pxafb_dma_descriptor dma_desc[DMA_MAX * 2];
};
[ARM] pxafb: add support for overlay1 and overlay2 as framebuffer devices 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. This heavily simplified and re-structured work is based on the original pxafb_overlay.c (which is pending for mainline merge for a long time). The major problems with this pxafb_overlay.c are (if you are interested in the history): 1. heavily redundant (the control logics for overlay1 and overlay2 are actually identical except for some small operations, which are now abstracted into a 'pxafb_layer_ops' structure) 2. a lot of useless and un-tested code (two workarounds which are now fixed on mature silicons) 3. cursorfb is actually useless, hardware cursor should not be used this way, and the code was actually un-tested for a long time. The code in this patch should be self-explanatory, I tried to add minimum comments. As said, this is basically simplified, there are several things still on the pending list: 1. palette mode is un-supported and un-tested (although re-using the palette code of the base framebuffer is actually very easy now with previous clean-up patches) 2. fb_pan_display for overlay(s) is un-supported 3. the base framebuffer can actually be abstracted by 'pxafb_layer' as well, which will help further re-use of the code and keep a better and consistent structure. (This is the reason I named it 'pxafb_layer' instead of 'pxafb_overlay' or something alike) See Documentation/fb/pxafb.txt for additional usage information. Signed-off-by: Eric Miao <eric.miao@marvell.com> Cc: Rodolfo Giometti <giometti@linux.it> Signed-off-by: Eric Miao <ycmiao@ycmiao-hp520.(none)>
2008-12-23 02:49:43 -07:00
enum {
OVERLAY1,
OVERLAY2,
};
enum {
OVERLAY_FORMAT_RGB = 0,
OVERLAY_FORMAT_YUV444_PACKED,
OVERLAY_FORMAT_YUV444_PLANAR,
OVERLAY_FORMAT_YUV422_PLANAR,
OVERLAY_FORMAT_YUV420_PLANAR,
};
#define NONSTD_TO_XPOS(x) (((x) >> 0) & 0x3ff)
#define NONSTD_TO_YPOS(x) (((x) >> 10) & 0x3ff)
#define NONSTD_TO_PFOR(x) (((x) >> 20) & 0x7)
struct pxafb_layer;
struct pxafb_layer_ops {
void (*enable)(struct pxafb_layer *);
void (*disable)(struct pxafb_layer *);
void (*setup)(struct pxafb_layer *);
};
struct pxafb_layer {
struct fb_info fb;
int id;
int registered;
uint32_t usage;
[ARM] pxafb: add support for overlay1 and overlay2 as framebuffer devices 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. This heavily simplified and re-structured work is based on the original pxafb_overlay.c (which is pending for mainline merge for a long time). The major problems with this pxafb_overlay.c are (if you are interested in the history): 1. heavily redundant (the control logics for overlay1 and overlay2 are actually identical except for some small operations, which are now abstracted into a 'pxafb_layer_ops' structure) 2. a lot of useless and un-tested code (two workarounds which are now fixed on mature silicons) 3. cursorfb is actually useless, hardware cursor should not be used this way, and the code was actually un-tested for a long time. The code in this patch should be self-explanatory, I tried to add minimum comments. As said, this is basically simplified, there are several things still on the pending list: 1. palette mode is un-supported and un-tested (although re-using the palette code of the base framebuffer is actually very easy now with previous clean-up patches) 2. fb_pan_display for overlay(s) is un-supported 3. the base framebuffer can actually be abstracted by 'pxafb_layer' as well, which will help further re-use of the code and keep a better and consistent structure. (This is the reason I named it 'pxafb_layer' instead of 'pxafb_overlay' or something alike) See Documentation/fb/pxafb.txt for additional usage information. Signed-off-by: Eric Miao <eric.miao@marvell.com> Cc: Rodolfo Giometti <giometti@linux.it> Signed-off-by: Eric Miao <ycmiao@ycmiao-hp520.(none)>
2008-12-23 02:49:43 -07:00
uint32_t control[2];
struct pxafb_layer_ops *ops;
void __iomem *video_mem;
unsigned long video_mem_phys;
size_t video_mem_size;
struct completion branch_done;
struct pxafb_info *fbi;
};
struct pxafb_info {
struct fb_info fb;
struct device *dev;
struct clk *clk;
void __iomem *mmio_base;
struct pxafb_dma_buff *dma_buff;
size_t dma_buff_size;
dma_addr_t dma_buff_phys;
dma_addr_t fdadr[DMA_MAX * 2];
void __iomem *video_mem; /* virtual address of frame buffer */
unsigned long video_mem_phys; /* physical address of frame buffer */
size_t video_mem_size; /* size of the frame buffer */
u16 * palette_cpu; /* virtual address of palette memory */
u_int palette_size;
u_int lccr0;
u_int lccr3;
u_int lccr4;
u_int cmap_inverse:1,
cmap_static:1,
unused:30;
u_int reg_lccr0;
u_int reg_lccr1;
u_int reg_lccr2;
u_int reg_lccr3;
u_int reg_lccr4;
u_int reg_cmdcr;
unsigned long hsync_time;
volatile u_char state;
volatile u_char task_state;
struct mutex ctrlr_lock;
wait_queue_head_t ctrlr_wait;
struct work_struct task;
struct completion disable_done;
#ifdef CONFIG_FB_PXA_SMARTPANEL
uint16_t *smart_cmds;
size_t n_smart_cmds;
struct completion command_done;
struct completion refresh_done;
struct task_struct *smart_thread;
#endif
[ARM] pxafb: add support for overlay1 and overlay2 as framebuffer devices 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. This heavily simplified and re-structured work is based on the original pxafb_overlay.c (which is pending for mainline merge for a long time). The major problems with this pxafb_overlay.c are (if you are interested in the history): 1. heavily redundant (the control logics for overlay1 and overlay2 are actually identical except for some small operations, which are now abstracted into a 'pxafb_layer_ops' structure) 2. a lot of useless and un-tested code (two workarounds which are now fixed on mature silicons) 3. cursorfb is actually useless, hardware cursor should not be used this way, and the code was actually un-tested for a long time. The code in this patch should be self-explanatory, I tried to add minimum comments. As said, this is basically simplified, there are several things still on the pending list: 1. palette mode is un-supported and un-tested (although re-using the palette code of the base framebuffer is actually very easy now with previous clean-up patches) 2. fb_pan_display for overlay(s) is un-supported 3. the base framebuffer can actually be abstracted by 'pxafb_layer' as well, which will help further re-use of the code and keep a better and consistent structure. (This is the reason I named it 'pxafb_layer' instead of 'pxafb_overlay' or something alike) See Documentation/fb/pxafb.txt for additional usage information. Signed-off-by: Eric Miao <eric.miao@marvell.com> Cc: Rodolfo Giometti <giometti@linux.it> Signed-off-by: Eric Miao <ycmiao@ycmiao-hp520.(none)>
2008-12-23 02:49:43 -07:00
#ifdef CONFIG_FB_PXA_OVERLAY
struct pxafb_layer overlay[2];
#endif
#ifdef CONFIG_CPU_FREQ
struct notifier_block freq_transition;
#endif
struct regulator *lcd_supply;
bool lcd_supply_enabled;
void (*lcd_power)(int, struct fb_var_screeninfo *);
void (*backlight_power)(int);
struct pxafb_mach_info *inf;
};
#define TO_INF(ptr,member) container_of(ptr,struct pxafb_info,member)
/*
* These are the actions for set_ctrlr_state
*/
#define C_DISABLE (0)
#define C_ENABLE (1)
#define C_DISABLE_CLKCHANGE (2)
#define C_ENABLE_CLKCHANGE (3)
#define C_REENABLE (4)
#define C_DISABLE_PM (5)
#define C_ENABLE_PM (6)
#define C_STARTUP (7)
#define PXA_NAME "PXA"
/*
* Minimum X and Y resolutions
*/
#define MIN_XRES 64
#define MIN_YRES 64
/* maximum X and Y resolutions - note these are limits from the register
* bits length instead of the real ones
*/
#define MAX_XRES 1024
#define MAX_YRES 1024
#endif /* __PXAFB_H__ */