LCD框架介绍

LCD架构介绍

.

 

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(buffer);

    private_module_t* m = reinterpret_cast(

            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

联系方式: [e-mail]