Revision History
Date Issue Description Author
<04/15/2010> <0.1> LCD架构分析 Wylhistory
目录
1. 摘要 3
2. 介绍 3
3. 思路 3
4. 初始化 4
4.1 设备和驱动注册 4
4.2 PROBE函数的执行 6
5. 用户使用流程 8
5.1 上层软件使用流程 8
5.2 驱动处理逻辑 9
6. 总结 12
7. 未讨论 12
1. 摘要
分析一下在pxa310平台,LCD驱动的架构;
2. 介绍
每次换LCD的屏都会经历一个痛苦的过程,所以想理一下它的架构,以便在以后的集成过程中,能有一个简单的指导;
硬件平台:pxa310
软件平台:android 2.1
内核:2.6.29
3. 思路
对于驱动的集成,我的一个原始的思路是这样的,驱动包含两方面的内容,
A) 硬件管理;
B) 提供对上接口,也就是提供给应用层接口;
从硬件管理的角度来说,任何一个模块想要工作,比如wifi,蓝牙, LCD等都必须要和我们的CPU相连,以实现通讯,所以要让这些模块工作,从上面一句话里面可以得出的结论就是这样:
(模块正常工作)==(模块本身工作正常)+(模块控制器工作正常)+(接口工作正常);
也就是说,想让一个驱动工作,就必须要考虑这三方面的内容,对应于我们要讨论的LCD的驱动,也就意味着:
A) LCD屏本身需要正确的初始化,以进入正常工作的状态(这个目前的lcd屏都不提供反馈信号);
B) LCD controller本身要正确的初始化,以进入正常的工作状态(这个可以通过寄存器的打印验证);
C) 接口需要正确配置,以实现LCD controller和LCD屏之间的通讯,接口通常都包含命令接口和数据接口,我们的命令接口是SPI的(通过gpio口模拟SPI协议),所以需要对 SPI接口做相应的初始化,数据接口一般分为RGB接口和CPU接口,rgb一般是16根线,有时候需要扩展以适应屏的pin脚,而cpu通过是8根,我们这边也需要扩展,比如高位扩展比如我们这边传递5位的red,那么我们的m4——m0位接到对方的p7——p3,而对方的p0——p2就接到我们的m4 ——m2(这个可以通过示波器验证);
而从对上的接口来说,各个驱动通常都有统一的接口,比如:
Open,close,ioctl,write,read,mmap,当然不同的驱动有可能只选择某些来实现,对于 LCD驱动来说,最重要的当然是Open,ioctl,以及mmap,我们后面可以看看它的代码逻辑;
下面会从初始化和上层使用角度来具体分析:
4. 初始化
4.1 设备和驱动注册
图 4.1设备和驱动的注册
有的驱动设备的注册和驱动的注册是放在不同的地方的,不过LCD的驱动是放在同一个函数里面的,就在pxafb.c里面的pxafb_init里面;
按照惯例,是先注册设备,再注册驱动,我们可以看到,设备的注册最后到了函数pxa_register_device 里面,看看它的代码:
void pxa_register_device(struct platform_device *dev, void *data)
{
int ret;
dev->dev.platform_data = data;
ret = platform_device_register(dev);
if (ret)
dev_err(&dev->dev, "unable to register device: %d/n", ret);
}
这里最重要的就是上面蓝色这句话,也就是保存了传入的这个info参数到platform_data里面,后面可以看到,很多操作都是需要这个数据结构的参与的,甚至可以说,这个数据结构对于 LCD的驱动来说是至关重要的,那么不看看它,就不够人情了,如下:
struct pxafb_mach_info lin2008_lcdpar = {
.modes = lin2008_modes,
.num_modes = 1,
.lccr0 = LCCR0_Act ,
.lccr3 = LCCR3_STALL | LCCR3_OutEnH,
};
这里先看看这个lccr0的值,注释如下:
#define LCCR0_Act (LCCR0_PAS*1) /* Active display (TFT) */
简单说也就是定义这个屏的类型;
Lccr3的值定义如下:
#define LCCR3_STALL (1 << 28) /* Stall pixel clock if underrun occurs */
#define LCCR3_OutEnH (LCCR3_OEP*0) /* Output Enable active High */
翻译一下就是说,如果发生没有数据传输的情况,那么就停止像素时钟;
第二行,使能输出,并且是高有效;
这里我最关心的还是lin2008_modes,我们看看它的内容:
static struct pxafb_mode_info lin2008_modes[] = {
[0] = {
// .pixclock = 68296, // consider for 812*492*36 frame
// .pixclock = 48344, // consider for 812*492*60 frame
.pixclock = 40977, // consider for 504*807*60
// .pixclock = 68296, // consider for 504*807*36
.xres = 480,
.yres = 800,
.bpp = 16,
.hsync_len = 7,
.left_margin = 8,
.right_margin = 16,
.vsync_len = 1,
.upper_margin = 4,
.lower_margin = 3,
.sync = 0,
},
};
这里面的信息都很重要,一个个来说:
Pixclock:这里是指时钟频率的倒数,否则怎么算都不对的,而且这里没有计算行同步和帧同步,40997== (1<<12)/(480+8+16)×(800+4+3)×60;也就是说这个值等于x的分辨率加上前廊+后廊以后与y的分辨率加上上廊加下廊后的值的乘积;
OK,现在我们回到先前设备注册的地方,也就是函数 pxa_register_device里面的dev成员,如下:
struct platform_device pxa_device_fb = {
.name = "pxa2xx-fb",
.id = -1,
.dev = {
.dma_mask = &fb_dma_mask,
.coherent_dma_mask = 0xffffffff,
},
.num_resources = ARRAY_SIZE(pxafb_resources),
.resource = pxafb_resources,
};
这里面唯一需要关注的就是这个资源,如下:
static struct resource pxafb_resources[] = {
[0] = {
.start = 0x44000000,
.end = 0x4400ffff,
.flags = IORESOURCE_MEM,
},
[1] = {
.start = IRQ_LCD,
.end = IRQ_LCD,
.flags = IORESOURCE_IRQ,
},
};
也就是说与LCD controller相关的寄存器的地址范围就在0x44000000——0x4400ffff之间;
既然设备以及注册了,我们再看看驱动的注册,
platform_driver_register(&pxafb_driver),这里最重要的还是pxafb_driver,下面看看它的值:
static struct platform_driver pxafb_driver = {
.probe = pxafb_probe,
#ifdef CONFIG_PM
.suspend = pxafb_suspend,
.resume = pxafb_resume,
#endif
.driver = {
.name = "pxa2xx-fb",
},
};
4.2 Probe函数的执行
根据platform设备的配备原则,只要名字相同,就可以结婚了,正所谓“金风玉露一相逢,便调用probe函数”
于是这里的probe函数也就是 pxafb_probe开始被调用了,这个函数挺长的,总结一下,至少干了以下几件事:
1, 调用lcdchip_init 对LCD屏本身进行初始化;
2, 取出inf = dev->dev.platform_data,这是先前我们在设备注册的时候赋值的,它是原始数据的来源,后面的很多操作很它有关;
3, 一堆的参数检查,不讨论;
4, 构建framebuffer信息,对于pxa310的架构,有三个层,所以不同的层拥有不同的framebuffer信息,但是这些信息的初始都来自于先前的 platform_data,可以把这一步的动作理解为我前面总结的是为了提供对上接口,而做的准备,这里会对我们在应用层看到的var 信息和fix信息做填充;需要单独说明的是这两句代码:fbi->fb.fbops = &pxafb_ops;……; INIT_WORK(&fbi->task, pxafb_task);前一个设置函数操作集,后面一句话初始化一个work pxafb_task后面会用到;
5, 通过pxafb_map_video_memory函数分配 framebuffer空间,空间的长度为xres*yres*bpp/2(如果是android系统还会再乘以2,因为是双缓冲)+PAGESIZE, 这个pagesize,通常是用来存放DMA描述符的,如果要调整上层看到的framebuffer的大小,这里需要修改,当然返回给上层的 smem_len也必须要修改;
6, 设置中断处理函数,通常也就用在调试的时候;
7, 通过pxafb_set_par设置DMA描述符的地址,以及描述符里面的内容,如果有某个相关的寄存器有改变,那么就通过 pxafb_schedule_work(fbi, C_REENABLE)来启动在第4步里面设置的work也就是pxafb_task来运行,注意不是立即运行;
8, 通过register_framebuffer(&fbi->fb)来注册这个framebuffer信息,本质上就是让registered_fb【index】指向先前我们分配的这个framebuffer信息,以便在后面使用的时候可以取出来;
9, 调用set_ctrlr_state(fbi, C_ENABLE)再通过pxafb_enable_controller 来enable controller,这里会把先前在第7步里面赋好的值放入具体的寄存器;
好现在先看看第4步里面的pxafb_ops:
static struct fb_ops pxafb_ops = {
.owner = THIS_MODULE,
.fb_check_var = pxafb_check_var,
.fb_set_par = pxafb_set_par,
.fb_setcolreg = pxafb_setcolreg,
.fb_fillrect = cfb_fillrect,
.fb_copyarea = cfb_copyarea,
.fb_imageblit = cfb_imageblit,
.fb_blank = pxafb_blank,
.fb_mmap = pxafb_mmap,
.fb_pan_display = pxafb_pan_display,
#ifdef CONFIG_FB_PXA_MINILCD
.fb_ioctl = pxafb_minilcd_ioctl,
#else
.fb_ioctl = pxafb_ioctl,
#endif
};
再看看这个pxafb_task:
static void pxafb_task(struct work_struct *work)
{
struct pxafb_info *fbi =
container_of(work, struct pxafb_info, task);
u_int state = xchg(&fbi->task_state, -1);
set_ctrlr_state(fbi, state);
}
这里面先取得 fbi->task_state放到state里面,估计是为了实现互斥的访问,所以搞了一个xchg操作;然后通过 set_ctrlr_state来实现真正的LCD controller的寄存器的操作;
总结下来就是说,参数的原始设置在static struct pxafb_mode_info lin2008_modes里面,必须要正确填写,估计不同的屏这个地方都需要修改,然后就是controller的enable,这个是需要到 set_ctrlr_state的时候,才会被传递到寄存器的,那么有就是说,在这之前,必须要保证相关的值已经被正确的赋给了framebuffer info,需要注意的就是那个描述符的内容的填写,结构如下:
struct pxafb_dma_descriptor {
unsigned int fdadr;
unsigned int fsadr;
unsigned int fidr;
unsigned int ldcmd;
};
fdadr:下一个描述符的地址,注意这个是DMA的地址,在我们的平台上就是物理地址,通常可以让它指向这个结构本身的地址,这样就可以形成一个环,从而实现一直刷新;
fsadr:这个是数据的地址,也就是说应用层在这个地方开始写的数据,对于android平台,这个地址有可能是 framebuffer的起始地址,也有可能是起始地址+xres*yres*bpp/2;
fidr,这个值没怎么使用到,我们都填的是0;
ldcm,也就是这个数据的长度,如果要刷一屏的话,对于 800X480的分辨率16位色,那么就是800*480*2;
5. 用户使用流程
5.1 上层软件使用流程
代码如下:
static int fb_post(struct framebuffer_device_t* dev, buffer_handle_t buffer)
{
if (private_handle_t::validate(buffer) < 0)
return -EINVAL;
fb_context_t* ctx = (fb_context_t*)dev;
private_handle_t const* hnd = reinterpret_cast<private_handle_t const*>(buffer);
private_module_t* m = reinterpret_cast<private_module_t*>(
dev->common.module);
if (m->currentBuffer) {
m->base.unlock(&m->base, m->currentBuffer);
m->currentBuffer = 0;
}
if (hnd->flags & private_handle_t::PRIV_FLAGS_FRAMEBUFFER) {
m->base.lock(&m->base, buffer,
private_module_t::PRIV_USAGE_LOCKED_FOR_POST,
0, 0, m->info.xres, m->info.yres, NULL);
const size_t offset = hnd->base - m->framebuffer->base;
m->info.activate = FB_ACTIVATE_VBL;
m->info.yoffset = offset / m->finfo.line_length;
if (ioctl(m->framebuffer->fd, FBIOPUT_VSCREENINFO, &m->info) == -1) {
LOGE("FBIOPUT_VSCREENINFO failed");
m->base.unlock(&m->base, buffer);
return -errno;
}
m->currentBuffer = buffer;
} else {
// If we can't do the page_flip, just copy the buffer to the front
// FIXME: use copybit HAL instead of memcpy
void* fb_vaddr;
void* buffer_vaddr;
m->base.lock(&m->base, m->framebuffer,
GRALLOC_USAGE_SW_WRITE_RARELY,
0, 0, m->info.xres, m->info.yres,
&fb_vaddr);
m->base.lock(&m->base, buffer,
GRALLOC_USAGE_SW_READ_RARELY,
0, 0, m->info.xres, m->info.yres,
&buffer_vaddr);
memcpy(fb_vaddr, buffer_vaddr, m->finfo.line_length * m->info.yres);
m->base.unlock(&m->base, buffer);
m->base.unlock(&m->base, m->framebuffer);
}
return 0;
}
这个函数会在surfaceflinger层的postframebuffer到opengl层到 nativewindow层的queueBuffer里面会调用fb->post(fb, handle)触发这个函数的执行;
从驱动的角度来说,它最关心的还是FBIOPUT_VSCREENINFO这个ioctl,下面看看驱动对应的处理逻辑;
5.2 驱动处理逻辑
如下图所示:
上层的ioctl会触发这个fb_ioctl的执行,在里面首先从registerd_fb[fbidx]取出先前我们注册的framebuffer信息(对于fb0来说就是在probe函数里面通过 register_framebuffer来实现注册的);然后通过fb_set_var把这个信息传递下去,var代表了上层传下来的数据信息,这个函数也是相当的长,不过我还是贴出来了,去掉了一写错误处理:
int
fb_set_var(struct fb_info *info, struct fb_var_screeninfo *var)
{
int flags = info->flags;
int ret = 0;
……………………….
…………………….....
if ((var->activate & FB_ACTIVATE_FORCE) ||
memcmp(&info->var, var, sizeof(struct fb_var_screeninfo))) {
u32 activate = var->activate;
if (!info->fbops->fb_check_var) {
*var = info->var;
goto done;
}
ret = info->fbops->fb_check_var(var, info);
if (ret)
goto done;
if ((var->activate & FB_ACTIVATE_MASK) == FB_ACTIVATE_NOW) {
struct fb_videomode mode;
if (info->fbops->fb_get_caps) {
ret = fb_check_caps(info, var, activate);
if (ret)
goto done;
}
info->var = *var;
if (info->fbops->fb_set_par)
info->fbops->fb_set_par(info);
fb_pan_display(info, &info->var);
fb_set_cmap(&info->cmap, info);
fb_var_to_videomode(&mode, &info->var);
if (info->modelist.prev && info->modelist.next &&
!list_empty(&info->modelist))
ret = fb_add_videomode(&mode, &info->modelist);
if (!ret && (flags & FBINFO_MISC_USEREVENT)) {
struct fb_event event;
int evnt = (activate & FB_ACTIVATE_ALL) ?
FB_EVENT_MODE_CHANGE_ALL :
FB_EVENT_MODE_CHANGE;
info->flags &= ~FBINFO_MISC_USEREVENT;
event.info = info;
event.data = &mode;
fb_notifier_call_chain(evnt, &event);
}
}
}
done:
return ret;
}
A) 先通过 pxafb_check_var检查传入的参数的有效性;
B) 调用 info->fbops->fb_set_par(info)也就是pxafb_set_par计算新的DMA传输相关的参数,通过调用 pxafb_activate_var来把新的包括行同步,帧同步,前廊后廊,上廊下廊等也包括DMA描述符内容的更新保存在fbi->reg*成员里面,然后触发pxafb_task的调度,注意这时候还没有被执行;
C) fb_pan_display-> info->fbops->fb_pan_display(var, info),最后就调用到了pxafb_pan_display,这个函数最主要的作用就是pxafb_schedule_work(fbi, C_CHANGE_DMA_BASE);注意这个状态因为是后设置的,也就是说前面在fb_set_par的时候设置的状态将会被这个状态覆盖,那么最后在执行pxafb_task的时候取得的状态将会是这个C_CHANGE_DMA_BASE的状态;
等这个pxafb_task被调度执行的时候,将会走到C_CHANGE_DMA_BASE的分支,如下:
static void pxafb_task(struct work_struct *work)
{
struct pxafb_info *fbi =
container_of(work, struct pxafb_info, task);
u_int state = xchg(&fbi->task_state, -1);
set_ctrlr_state(fbi, state);
}
void set_ctrlr_state(struct pxafb_info *fbi, u_int state)
{
……
case C_CHANGE_DMA_BASE:
fbi->dmadesc_fbhigh_cpu->fsadr = fbi->screen_dma +
(fbi->fb.var.xres*fbi->fb.var.yoffset*/
fbi->fb.var.bits_per_pixel/8);
break;
……
}
可以看到基本上就是修改fsadr的地址,它的值,我们前面有看到就是实际的数据的起始地址,通过这样的方式,那么下一次DMA数据传递的时候,数据将会从这个地址取得,从而实现了android平台下的双缓冲机制;
6. 总结
A)对于分辨率的修改,也就是说,如果屏本身支持这个新的分辨率,那么只需要对 static struct pxafb_mode_info lin2008_modes这个结构体修改就可以了,它这里面的xres,yres是后面许多数据结构里面的值的根源,如果需要在只支持800X480的屏上模拟320X480的话,还需要修改前廊后廊以扩展到相应的pixelclock就应该可以了;
B)真正对于 controller的设置都是在set_ctrlr_state里面做的,而这些值的设置都是在pxafb_activate_var里面做的,也就是说,如果要欺骗controller也就是说为了实现实际的值和上层看到的值的差异性,我想可以在这里做hack;
C)对于屏不亮的问题,我想首先要考虑的是电压问题,如果电压正常,那么就考虑另外四根线,CLOCK,hsync,vsync,以及 de线,如果这个都正常,再看看数据线是否正常,这些都可以通过示波器看出来,当然正确的对屏本身的初始化是前提,而屏无法提供反馈信号,这也是调试 LCD驱动最痛苦的地方,因为你无法判断初始化是否已经正确;
D)可以通过打开中断来判断,每帧数据的发送情况,当然,里面的打印信息不是完全有效,但是可以提供一定的参考,而且如果它在一直打印,至少可以说明,数据在不断的刷新;
E)显示结果和应该的结果如果有差异,可以通过抓出framebuffer的内容转化层图片来比较;当然也可以通过cat一幅图片到 framebuffer来判断驱动是否已经工作,如果开始的时候cat工作,过了一定时间cat又不工作,说明在这个过程中某些硬件的配置已经被改变了,这个需要看看是不是别的模块和你的设置有冲突;
7. 未讨论
1, controller寄存器的详细设置没有分析,这个我觉得需要对照spec详细看;
2, lcd屏本身的初始化没有仔细看,这个我觉得和屏本身有关;
3, 其它;
备注:
作者:wylhistory
联系方式: wylhistory@gmail.com
原文地址:http://blog.chinaunix.net/u2/67984/showart_2237233.html