驱动开发 linux camera调试：serdes camera调试

serdes是串行器和解串器的简写，顾名思义是一种将并行数据转换成串行数据发送，将接收的串行数据转换成并行数据的”器件“。

camera常用的接口是MIPI高速接口，MIPI的传输距离受限，传输距离过大容易导致信号质量不佳，影响图像数据的传输，所以经常会使用到serdes，以增加传输距离，在车载领域更加常见。

这篇文章简单介绍一下在RK3588上面serdes camera的调试。

（1）RK3588 serdes camera应用框图

①sensor自带ISP

②sensor不带ISP

（2）基于V4L2 camera驱动实现

1）I2C设备驱动

2）驱动初始化代码

3）驱动数据流控制

4）dts配置

（3）多路camera输入应用

1）驱动接口

2）多路camera对接USBHAL

（4）热拔插功能

1）VICAP异常复位机制

2）驱动实现

①申请中断

②中断处理函数

③轮询方式实现

④ioctl接口实现

（5）总结

（1）RK3588 serdes camera应用框图

基于RK3588平台，带serdes的camera应用的框图如下所示：

相比于不带serdes的场景，会在senso和主控之间增加串行器和解串器的连接，以增加传输距离，串行器和解串器之间一般是用线缆连接，其中的传输协议一般是各个厂商自有的，比如美信提出的GMSL/GMSL2协议，传输带宽可以达到6G。

如上场景也可以分为两种情况：

①sensor自带ISP

有的模组厂会在sensor端自带ISP，sensor的图像直接经过模组的ISP处理，输出YUV422的图像进行传输，可以省下来在RK3588主控端ISP 3A算法处理的时间。这种场景情况下，在配置的时候不需要将图像经过ISP处理，直接连接到VICAP存储到DDR即可。

②sensor不带ISP

模组没有带ISP，直接输出RAWRGB的图像，RK3588主控端vicap收下之后，需要将数据给到ISP进行3A算法处理，有分回读模式和直通模式，具体可以看前面的文章。

（2）基于V4L2 camera驱动实现

前面的文章有介绍到RK3588的camera都是基于V4L2框架和media-framework系统设计实现的，将各级链路的数据流虚拟化成子设备节点，如下所示，将节点称为entity，每个entity都带有pad端口，pad端口可以想象成是数据流的进出口，entity之间的pad连接，我们使用link来描述。

#------------# #------------#

| __|__ __|__ |

| | pad |<-------->| pad | |

| |__|__| |__|__| |

| | | |

| entity | | entity |

#------------# #------------#

在不带serdes的设计的时候，是将camera sensor虚拟化成一个子设备，如果增加了serdes的话，该如何设计框架。我觉得有两种思路：

继续引进pipeline的概念，将ser和des都分别虚拟化成两个子设备节点，利用V4L2-pipeline框架进行配置连接，这种设计兼容性会好点，但是工作量比较大可将问题简单化，将sensor，serdes进行捆绑化设计，将三者捆绑成一个V4L2子设备驱动，并在同一个驱动初始化sensor和serdes。

后面主要讲一下第二种方式的做法，第一种方式只是本人的一种想法，并没有实践，仅供感兴趣的同学参考。

1）I2C设备驱动

无论是否带serdes，sensor和serdes都是i2c设备，简而言之，我的做法就是将sensor、serdes三者当成一个设备看待，只注册一个i2c设备，驱动通过i2c地址进行区分，分别控制三者，对三者的寄存器进行配置。下面以THCV241+THCV244 serdes为例进行介绍，在这个例子中，因为模组带固件，上电就直接跑内部固件配置寄存器，因此不需要主控这边进行控制。

这里有一个疑问，注册i2c设备的时候，dts需要配置i2c地址，和设备驱动的信息，这里应该配置解串器还是串行器？我个人建议是按照解串器进行配置，解串器与主控直接相连，串行器并没有与主控直接连接，甚至i2c控制都是通过解串器使用线缆进行转发。

2）驱动初始化代码

类似camera的配置，主要需要注意在配置的时候需要注意控制的时序，serdes的控制时序原厂一般会给参考，严格按照时序进行控制，其余与通常的camera没有较大的差别。需要注意的是配置ser和des的i2c地址不同，因此i2c读写的函数需要注意一下。如下所示是THCV244和THCV241的初始化控制流程

static int thcv244_thcv241_init(struct thcv244 *thcv244)

{

struct device *dev = &thcv244->client->dev;

int ret;

ret = thcv244_write_array(thcv244->client, thcv244_global_init_table);

ret |= thine_write_reg(thcv244->client, THCV241_ADDR, 0x00fe,

2, THCV244_REG_VALUE_08BIT, 0x11);

ret |= thine_write_reg(thcv244->client, THCV244_ADDR, 0x0032,

2, THCV244_REG_VALUE_08BIT, 0x00);

ret |= thcv241_write_array(thcv244->client, thcv241_init_table);

ret |= thcv244_write_array(thcv244->client, thcv244_1080p30_init_table);

ret |= thine_write_reg(thcv244->client, THCV244_ADDR, 0x0032,

2, THCV244_REG_VALUE_08BIT, 0x00);

ret |= thine_write_reg(thcv244->client, THCV241_ADDR, 0xfe,

1, THCV244_REG_VALUE_08BIT, 0x21);

ret |= thine_write_reg(thcv244->client, THCV241_ADDR, 0x3e,

1, THCV244_REG_VALUE_08BIT, 0x00);

msleep(200);

ret |= thine_write_reg(thcv244->client, THCV241_ADDR, 0x3e,

1, THCV244_REG_VALUE_08BIT, 0x10);

ret |= thine_write_reg(thcv244->client, THCV244_ADDR, 0x1600,

2, THCV244_REG_VALUE_08BIT, 0x00);

if (ret)

dev_err(dev, "fail to init thcv244 and thcv 241!\n");

return ret;

}

如下是i2c的读写函数，根据传递的i2c地址进行控制：

static int thine_write_reg(struct i2c_client *client, u16 client_addr, u16 reg,

u32 reg_len, u32 val_len, u32 val)

{

u32 buf_i, val_i;

u8 buf[6];

u8 *val_p;

__be32 val_be;

if (val_len > 4)

return -EINVAL;

if (reg_len == 2) {

buf[0] = reg >> 8;

buf[1] = reg & 0xff;

} else {

buf[0] = reg & 0xff;

}

val_be = cpu_to_be32(val);

val_p = (u8 *)&val_be;

if (reg_len == 2) {

buf_i = 2;

val_i = 4 - val_len;

} else {

buf_i = 1;

val_i = 4 - val_len;

}

while (val_i < 4)

buf[buf_i++] = val_p[val_i++];

client->addr = client_addr;

if (i2c_master_send(client, buf, val_len + reg_len) != val_len + reg_len) {

dev_err(&client->dev,

"%s, i2c_master_send err, client->addr = 0x%x, reg = 0x%x, val = 0x%x\n",

__func__, client->addr, reg, val);

return -EIO;

}

dev_dbg(&client->dev,

"%s, i2c_master_send ok, client->addr = 0x%x, reg = 0x%x, val = 0x%x\n",

__func__, client->addr, reg, val);

return 0;

}

3）驱动数据流控制

标准驱动需要对数据流的开关进行控制，主要控制解串器的MIPI输出数据流即可，因为解串器才是与主控直接相连，串行器的输出初始化的时候直接打开就好，控不控制影响不大。

其实这里有一个问题，就是解串器输出的MIPI使用的是连续时钟模式还是非连续时钟模式，相关的概念大家可以自行百度，这里不再赘述。

连续时钟，对pipeline的数据流控制有时序要求：必须先打开RK3588主控端的MIPI RX，再打开解串器的MIPI TX。

非连续时钟，对时序控制要求不严格，先开RX 或者先开TX影响不大。后续其他文章会提到为何需要这样要求。

控制数据流的接口：

static int thcv244_s_stream(struct v4l2_subdev *sd, int on)

{

struct thcv244 *thcv244 = to_thcv244(sd);

struct i2c_client *client = thcv244->client;

int ret = 0;

dev_info(&client->dev, "%s: on: %d, %dx%d@%d\n", __func__, on,

thcv244->cur_mode->width,

thcv244->cur_mode->height,

DIV_ROUND_CLOSEST(thcv244->cur_mode->max_fps.denominator,

thcv244->cur_mode->max_fps.numerator));

mutex_lock(&thcv244->mutex);

on = !!on;

if (on == thcv244->streaming)

goto unlock_and_return;

if (on) {

ret = pm_runtime_get_sync(&client->dev);

if (ret < 0) {

pm_runtime_put_noidle(&client->dev);

goto unlock_and_return;

}

ret = __thcv244_start_stream(thcv244);

if (ret) {

v4l2_err(sd, "start stream failed while write regs\n");

pm_runtime_put(&client->dev);

goto unlock_and_return;

}

} else {

__thcv244_stop_stream(thcv244);

pm_runtime_put(&client->dev);

}

thcv244->streaming = on;

unlock_and_return:

mutex_unlock(&thcv244->mutex);

return ret;

}

4）dts配置

dts配置参考camera的即可。THCV244配置如下：

&i2c8 {

status = "okay";

pinctrl-names = "default";

pinctrl-0 = <&i2c8m2_xfer>;

thcv244: thcv244@b {

compatible = "thine,thcv244";

status = "okay";

reg = <0xb>;

// clocks = <&cru CLK_MIPI_CAMARAOUT_M1>;

// clock-names = "xvclk";

// power-domains = <&power RK3588_PD_VI>;

// pinctrl-names = "default";

// pinctrl-0 = <&mipim0_camera1_clk>;

// rockchip,grf = <&sys_grf>;

/*power-gpios = <&gpio3 RK_PC6 GPIO_ACTIVE_HIGH>;*/

// reset-gpios = <&gpio3 RK_PA0 GPIO_ACTIVE_HIGH>;

rockchip,camera-module-index = <0>;

rockchip,camera-module-facing = "back";

rockchip,camera-module-name = "thcv244";

rockchip,camera-module-lens-name = "thcv244";

port {

thcv244_out: endpoint {

remote-endpoint = <&mipi_dcphy0_in>;

data-lanes = <1 2 3 4>;

};

（3）多路camera输入应用

这里指的多路camera是串行器支持多个摄像头输出，解串器使用一个mipi接口输出多路摄像头的数据，其中使用了mipi虚拟通道输出多路。主要注意驱动相关接口的设计：

1）驱动接口

如下代码所示，g_mbus_config配置为多路MIPI虚拟通道即可：V4L2_MBUS_CSI2_CHANNELS

static int thcv244_g_mbus_config(struct v4l2_subdev *sd, unsigned int pad,

struct v4l2_mbus_config *config)

{

struct thcv244 *thcv244 = to_thcv244(sd);

u32 lane_num = thcv244->bus_cfg.bus.mipi_csi2.num_data_lanes;

config->type = V4L2_MBUS_CSI2_DPHY;

config->flags = 1 << (lane_num - 1) |

V4L2_MBUS_CSI2_CHANNELS |

V4L2_MBUS_CSI2_CONTINUOUS_CLOCK;

return 0;

}

2）多路camera对接USBHAL

对接应用层的时候，可以分别从4路video取数据流，实现多路camera。

也可以使用RK的USBcameraHAL，然后apk上层去打开4路camera出图，对应配置如下：

&rkcif {

status = "okay";

rockchip,android-usb-camerahal-enable;

};

（4）热拔插功能

serdes的应用场景经常会用到热拔插的功能，尤其是车载的应用，需要保证热拔插之后，图像能够恢复正常。RK3588的vicap驱动引进了异常复位机制，可以利用这个机制来实现热拔插的功能。

1）VICAP异常复位机制

当前vicap驱动存在复位机制，该机制用于当vicap出现异常情况时，对vicap进行cru复位操作。早期的驱动代码版本是通过dts进行配置，添加rockchip,cif-monitor参数，若dts不设置该参数，则默认不使能复位机制。

&rkcif_mipi_lvds {

status = "okay";

/* parameters for do cif reset detecting:

* index0: monitor mode,

0 for idle,

1 for continue,

2 for trigger,

3 for hotplug (for nextchip)

* index1: the frame id to start timer,

min is 2

* index2: frame num of monitoring cycle

* index3: err time for keep monitoring

after finding out err (ms)

* index4: csi2 err reference val for resetting

rockchip,cif-monitor = <3 2 1 1000 5>;

port {

cif_mipi0_in: endpoint {

remote-endpoint = <&mipi0_csi2_output>;

};

这里仅介绍一下热拔插的机制，热拔插需要配置index为3，用于解决拔插图像割裂的问题，同时该模式具有continue模式的功能，即实时连续监测vicap是否mipi出错及断流，当发生出错及断流时进行vicap复位。

最新的RK3588 VICAP驱动代码，是通过config进行配置上述的参数，而不再是dts配置：

config ROCKCHIP_CIF_USE_MONITOR

bool "rkcif use monitor"

depends on VIDEO_ROCKCHIP_CIF

default n

help

Support for CIF to monitor capture error.

config ROCKCHIP_CIF_MONITOR_MODE

hex "rkcif monitor mode"

default 0x1