全志paralle csi 调试
与 cvbs以及 mipi csi不同．T7自带的parallel csis示例程序 一打开，就会产生i2c报错，导致kernel crush．
开始调试吧．
一，熟悉硬件原理图，确认输入流程，需要使用哪些硬件．
1，2个独立的csi接口，１６位宽．
2，支持 8,10,12,16数字camera输入．
3，支持ddr sample mode
4，支持CCIR656/bt1120输入协议，mode PAL和NTSC.
5，最大拍照分辨率5M, 录像1080p，时钟148.5Mhz
T7平台上，N-CSI的输入，经过input Parser，video input post process and DMA.不经过ISP.
二，目前使用平台的car_reverse代码测试。
log中，总是有 chip 0x31/0x30 addr 0xff, value 0x0, i2c transfer err的错误.怀疑在是 csic的Camera，调用了subdev sensor，使用了i2c进行power,init等操作导致的．
目前准备重新从找找有哪些i2c操作.
先从 sensor开始.
首先,认真看vin_probe函数.
1,parse_modules_from_device_tree
好吧,不想看了,,,主要是从dts解析sensor信息,然后注册sd的操作.
关键是 注释掉 这一行之后，就没有 i2c报错了。。。
看了一下sensor的slave-id，是0x60与0x62。右移一位，就变成0x30与0x31了。注释掉sensor写寄存器的操作，继续往后。
2,car_reverse函数
首先开启一个 car_reverse->display_update_task =
kthread_create(display_update_thread, NULL, "sunxi-preview");
ret = spin_is_locked(&car_reverse->display_lock);
if (ret) {
goto disp_loop;
}
disp_loop:
set_current_state(TASK_INTERRUPTIBLE);
if (kthread_should_stop())
set_current_state(TASK_RUNNING);
car_reverse->thread_mask &= (~THREAD_RUN);
schedule();//当前进程如果不是running ,那么进行切换。
wake_up_process(car_reverse->display_update_task);
car_reverse->thread_mask |= THREAD_RUN;
spin_unlock(&car_reverse->thread_lock);等待唤醒.
那么,谁调用他的呢?
car_reverse_preview_start 调用 video_source_streamon_vin 注册了 buffer_done_callback
然后在 static irqreturn_t vin_isr(int irq, void *priv) 中,调用 vin_buffer_process ,也就是 buffer_done_callback
Pass::INIT_WORK(&car_reverse->status_detect, status_detect_func);这个函数的含义是?
好吧，反正今天最终没调通，目前看到的是没有触发DMA中断，明天继续
昨天失败了,今天准备自己写一个demo程序,只是参考全志的代码,不再完全搬运了.
一,分析源码.首先从car_reverse_probe函数开始.
1,分配了一个 静态变量,保存为 car_reverse pdev的drv_data
car_reverse = devm_kzalloc(
&pdev->dev, sizeof(struct car_reverse_private_data), GFP_KERNEL);
然后,关注一下car_reverse pdev的 PM操作.
car_reverse_pm_ops = {
.suspend {car_reverse->standby = 1;flush_workqueue(car_reverse->preview_workqueue);}
.resume{car_reverse->standby = 0;queue_work(car_reverse->preview_workqueue, &car_reverse->status_detect);}
2, 解析dts
of_get_value_by_name(pdev, "tvd_id", &priv->config.tvd_id, 0);
of_get_value_by_name(pdev, "screen_width", &priv->config.screen_width,
0);
of_get_value_by_name(pdev, "screen_height", &priv->config.screen_height,
0);
of_get_value_by_name(pdev, "rotation", &priv->config.rotation, 1);
of_get_value_by_name(pdev, "source", &priv->config.input_src, 1);
of_get_gpio_by_name(pdev, "reverse_pin", &priv->reverse_gpio);
3, 注册一个状态检测函数???
car_reverse->status = CAR_REVERSE_STOP;
INIT_WORK(&car_reverse->status_detect, status_detect_func);
car_reverse->preview_workqueue =
create_singlethread_workqueue("car-reverse-wq");
queue_work(car_reverse->preview_workqueue, &car_reverse->status_detect);
//通过status_detect_func 调用car_reverse_preview_start;car_reverse_preview_stop;
4, 创建 预览更新线程.
car_reverse->display_update_task =
kthread_create(display_update_thread, NULL, "sunxi-preview");
5, 注册中断
request_irq(reverse_pin_irqnum, reverse_irq_handle,IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,"car-reverse", pdev)
reverse_irq_handle {queue_work(car_reverse->preview_workqueue, &car_reverse->status_detect);}
也就是说,整个流程是通过 irq,调用 status_detect_func, 获取 gpio状态.根据gpio状态,选择调用car_reverse_preview_start/car_reverse_preview_stop, 这两个函数中,又会唤醒display_update_thread线程.
6 补充
static DECLARE_DELAYED_WORK(car_freework, car_do_freemem);//这个是干嘛的?
cancel_delayed_work(&car_freework);
USE_SUNXI_DI_MODULE//这个是 视屏后处理技术 deinterlace 去交错的意思.就是将隔行扫描,变成逐行扫描.
二,分析preview与v4l2函数.
1, buffer管理.(注册,分配,设置)
car_reverse->buffer_pool = alloc_buffer_pool(car_reverse->config.dev, SWAP_BUFFER_CNT_VIN, 1280 * 720 * 2);
INIT_LIST_HEAD(&car_reverse->pending_frame);
2, video_source_connect(&car_reverse->config);
这里面除了普通的注册之外,还调用了一个 vin_core_gbl 设备.
也就是vin_core中注册的v4l2设备.
struct vin_core *vinc = vin_core_gbl[id];
struct list_head *active = &vinc->vid_cap.vidq_active;
struct list_head *done = &vinc->vid_cap.vidq_done;
INIT_LIST_HEAD(active);
INIT_LIST_HEAD(done);
set_bit(VIN_BUSY, &vinc->vid_cap.state);
dramfreq_master_access(MASTER_CSI, true); //?????
tvd_fd = params->tvd_id; //静态变量,用于在 vin_core_gbl中找到相应的vin_core设备．
video_source_format_setting(params);
{format.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
video_source_format_setting(params);
vin_s_input_special(tvd_fd, 0);
vin_g_fmt_special(tvd_fd, &format);
params->locked = 1;
format.fmt.pix.width = 1280;
format.fmt.pix.height = 720;
params->system = format.fmt.raw_data[105];
params->interface = format.fmt.raw_data[104];
format_prew.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
format_prew.fmt.pix.pixelformat = params->format;
format_prew.fmt.pix.width  = format.fmt.pix.width;
format_prew.fmt.pix.height = format.fmt.pix.height;
vin_s_fmt_special(tvd_fd, Â &format_prew)
}
car_reverse->config.format = V4L2_PIX_FMT_YUYV;
__vin_sensor_setup_link sensor与csi进行link．
vin_pipeline_call(vinc, open, &cap->pipe, &cap->vdev.entity, true); //调用 vin_core的 open函数．
__vin_pipeline_open vin_pipeline_s_power //各sub_dev上电v4l2_subdev_call(sd, core, s_power, on);
妈蛋，函数太多了，除了sensor，以外，isp,csi,paraser,dma都在配置。
由于硬件输入的线都是硬件飞的，决定还是先从接口模块paraser开始排查吧。
csic_prs_pclk_en(csi->id, enable);
csic_prs_enable(csi->id);
csic_prs_mode(csi->id, PRS_NCSI);
csic_prs_ncsi_bt656_header_cfg(csi->id, &bt656_header);
csic_prs_ncsi_if_cfg(csi->id, &csi->ncsi_if);
csic_prs_ncsi_en(csi->id, 1);
csic_prs_input_fmt_cfg(csi->id, i, csi->csi_fmt->infmt);
csic_prs_output_size_cfg(csi->id, i, &csi->out_size);
csic_prs_capture_start(csi->id, csi->bus_info.ch_total_num, &mode);
发现这些函数，并没有返回状态，按理来说，这种硬件数据通路，应该会有状态位变化吧。。。
加一个show函数看看。
3. 添加debug节点。
调用show函数时，将csi_parse的所有相关寄存器打印。store函数，使能中断状态寄存器。
结果，发现初始时，csi2_parse的4个通道控制寄存器全部初始化为0。调用CSI测试函数后，这段算是正确的赋值了。
但是，插上外接信号源，拔出外接信号源。通道状态寄存器，以及中断状态寄存器，都没有发现任何变化。果断怀疑是硬件问题，联系硬件同事测量信号，发现有个sync信号没连好。
最终结果，parse_状态寄存器明显接受到信号了，但是预览仍然没有数据输出。需要进一步调试了，不知道下一步，是scaler，isp，还是DMA啥的？
回顾硬件通路，
csi_parser.2－＞isp.0(not_used)－＞vipp(scaler).0－＞dma.0
这条通路的选择，是在vind选择vinc的时候，在vinc０中创建的．不同的vinc对应不同的硬件通路，但具体应该怎么选择，以后再看吧．当前的问题时，先看这条硬件通路，卡在哪里了．
首先已经知道的是，csi_parser.2能够检测到数据，只是不清楚这个数据有没有传给isp．
由于配置了isp_not_used，那么现在的排查点，就是vipp(scaler).0有没有检测到数据，如果检测到数据了，再看DMA．没有接收到数据的话，就需要尝试换一下isp了．修改成csi_parser.2－＞isp.2－＞vipp(scaler).4－＞dma.4．
下面这段代码有些疑惑．
for (i = 0; i < vin_cap->vinc->total_rx_ch; i++)
csic_isp_input_select(vind->id, vin_cap->vinc->isp_sel, i,
vin_cap->vinc->csi_sel, i);
csic_vipp_input_select(vind->id, vin_cap->vinc->vipp_sel,
vin_cap->vinc->isp_sel, vin_cap->vinc->isp_tx_ch);
这个是啥？为啥只循环设置了isp的input，没有循环设置vipp的input???
dump出寄存器后，对照datasheet，发现配置的与选择的的相同，没看出问题所在．
最后的最后，自己重新写了一个CSI demo程序，打开/dev/video0，，然后居然就好了．．．．
对比了一下正常和异常时候的寄存器，没啥差异的．．．
再次回忆一下，输入的是 不标准的 bt656，数据线8根，信号参数如下．
Horizontal Blank pixel： 120 pixel
Horizontal Blank clock： 2*120 = 240 clocks.
Total Horizontal Clcok : 2560+240 = 2800 clocks
Vertical Blank lines : 30 lines
Total Vertical lines 720+30 = 750 lines.
Pixel clock : 2800*750*30 = 63M在配置驱动的时候，应该选择 bt656 1channel,图像格式MEDIA_BUS_FMT_UYVY8_2X8，mbus_confi V4L2_MBUS_BT656，pol，channel 1．NCSI0, parser２,isp0,vipp0,dma0．
对于硬件配置，一直感觉很好奇，按照当前的配置，sov与eov之间有2560个数据，这部分是配置成MEDIA_BUS_FMT_UYVY8_2X8格式后，会自动解析么？反正，最后结果是好的，后面继续总结一下本次调试中略过的细节吧．