from :https://www.cnblogs.com/rongpmcu/p/7662738.html

Preface

camera The driving framework involves more knowledge points , especially camera There are a lot of interfaces , Some are directly connected to soc Of camif On the mouth , Some are through usb Interface exported , Such as usb camera. I will mainly discuss the former here , That is to say, with soc Directly connected . I think it's all about usb Of , It's not clear in one or two words ! If there is a mistake , Welcome to correct , thank you !!!

Environmental statement

The basic knowledge involved :
Character device driver
Device model
Platform device drivers
v4l2 frame
i2c Drive frame

The term involved :
camera : It means the whole camera, Including its own hardware connection and support i2c The control of the i2c equipment
sensor : It means support i2c The control of the i2c equipment , It belongs to camera Part of , It's also reflected in the kernel implementation
camera host: It means to be associated with camera Connected , Generally embedded in soc The controller inside

The folder involved :
drivers/media/platform/soc_camera/  Main storage camera host drive , General purpose camera The driver is also stored here
drivers/media/i2c/soc_camera/  Main storage sensor drive

Analyze the kernel version used :

VERSION = 3
PATCHLEVEL = 15
SUBLEVEL = 0
EXTRAVERSION =
NAME = Shuffling Zombie Juror

camera The drivers include general purpose camera The driver 、camera host Drive and sensor The driver , Let's analyze them one by one

Here's a picture , come from :http://blog.csdn.net/kickxxx/article/details/8484498( The picture and the words behind it were found after I wrote this blog , I think understanding camera Driving can help , So it's excerpted ^_^)

Soc camera sub-system Corresponding drivers/media/video/ Under the soc_camera.c soc_camera_platform.c

Soc camera host yes host Server-side implementation , It's implemented by platform vendors , Up to soc_camera_host_ops Interface , Down Camera host Hardware and operating through platform specific interfaces Soc camera device

Soc camera device It's platform camera device( It's also subdev), By the driver developer v4l2_subdev_call Called subdev Interface , At the same time, for soc camera host Implement platform specific operation interface ; Down camera sensor perhaps video AD chip .

Camera host hardware It's platform hardware related , Different platforms have different host Hardware , such as imx51 Of ipu, samsung s5pv210 Of fimc Controller, etc .

soc_camera_host,soc_camera_device,v4l2_device,v4l2_subdev Relations are as follows :
In theory, there can be multiple soc_camera_host, Physically soc_camera_host It's systematic camera Processing module driver
One soc_camera_host Can correspond to multiple soc_camera_device, Physically soc_camera_device It's a camera Interface , Every soc_camera_host Corresponding to one v4l2_dev
Every soc_camera_device, The system will create device nodes for them /dev/videoX.
Every soc_camera_device There are many. v4l2_subdev, Physically v4l2_subdev It can be sensor,video AD chip
v4l2_subdev Can pass i2c Hang on to v4l2_device, It can also be done through soc_camera_link Provided add_device To increase , It depends on sensor and video AD The chip is attached to MCU camera How to interface .

Universal camera drive

Corresponding documents drivers/media/platform/soc_camera/soc_camera.c

static struct platform_driver __refdata soc_camera_pdrv = {
.probe = soc_camera_pdrv_probe,
.remove = soc_camera_pdrv_remove,
.driver = {
.name = "soc-camera-pdrv",
.owner = THIS_MODULE,
},
}; module_platform_driver(soc_camera_pdrv);

You can see it here , We're going to make that drive probe Get called , You have to register a platform device first , And the name is soc-camera-pdrv. Universal camera The driver of the system is to define a set of data structure , And then I'll tell you , If you want to use universal camera drive , Then fill in according to the data structure , And then use soc-camera-pdrv Just register your name on the platform bus . There are two ways to register platform devices , One is through the device tree , It's the latest mechanism , adopt dts File to describe the hardware information , So that the kernel will not be hard coded and used to describe the hardware information code . The hardware information corresponding to this is camera sensor Hardware information and camera Hardware wiring information . The other is the way it used to be , Directly use the code to describe the information in the board related startup file and register the platform device .soc_camera_pdrv There is no support for the device tree , Explain that this kind of equipment is added in the following way , This can also be confirmed by the following command output :

I use orders (grep -rns soc-camera-pdrv arch/arm*/) Search for , You can get the following results :

arch/arm/mach-shmobile/board-lager.c:394: platform_device_register_data(&platform_bus, "soc-camera-pdrv", 1,
arch/arm/mach-shmobile/board-bockw.c:606: platform_device_register_data(&platform_bus, "soc-camera-pdrv", 0,
arch/arm/mach-shmobile/board-bockw.c:609: platform_device_register_data(&platform_bus, "soc-camera-pdrv", 1,
arch/arm/mach-shmobile/board-mackerel.c:1224: .name = "soc-camera-pdrv",
arch/arm/mach-shmobile/board-armadillo800eva.c:910: .name = "soc-camera-pdrv",
arch/arm/mach-shmobile/board-marzen.c:299: .name = "soc-camera-pdrv", \
arch/arm/mach-at91/board-sam9m10g45ek.c:241: .name = "soc-camera-pdrv",
arch/arm/mach-omap1/board-ams-delta.c:435: .name = "soc-camera-pdrv",
arch/arm/mach-pxa/ezx.c:788: .name = "soc-camera-pdrv",
arch/arm/mach-pxa/ezx.c:1062: .name = "soc-camera-pdrv",
arch/arm/mach-pxa/em-x270.c:1034: .name = "soc-camera-pdrv",
arch/arm/mach-pxa/palmz72.c:339: .name = "soc-camera-pdrv",
arch/arm/mach-pxa/pcm990-baseboard.c:507: .name = "soc-camera-pdrv",
arch/arm/mach-pxa/pcm990-baseboard.c:513: .name = "soc-camera-pdrv",
arch/arm/mach-pxa/mioa701.c:682:MIO_SIMPLE_DEV(mioa701_camera, "soc-camera-pdrv",&iclink);
arch/arm/mach-imx/mach-imx27_visstrim_m10.c:572: platform_device_register_resndata(NULL, "soc-camera-pdrv", 0, NULL, 0,
arch/arm/mach-imx/mach-mx31_3ds.c:248: .name = "soc-camera-pdrv",
arch/arm/mach-imx/mach-mx31_3ds.c:412: REGULATOR_SUPPLY("cmos_2v8", "soc-camera-pdrv.0"),
arch/arm/mach-imx/mach-mx31_3ds.c:444: REGULATOR_SUPPLY("cmos_vcore", "soc-camera-pdrv.0"),
arch/arm/mach-imx/mach-mx35_3ds.c:305: .name = "soc-camera-pdrv",
arch/arm/mach-imx/mach-mx35_3ds.c:324: REGULATOR_SUPPLY("cmos_vio", "soc-camera-pdrv.0"),
arch/arm/mach-imx/mach-mx27_3ds.c:272: REGULATOR_SUPPLY("cmos_2v8", "soc-camera-pdrv.0"),
arch/arm/mach-imx/mach-mx27_3ds.c:302: REGULATOR_SUPPLY("cmos_vcore", "soc-camera-pdrv.0"),
arch/arm/mach-imx/mach-mx27_3ds.c:410: .name = "soc-camera-pdrv",
arch/arm/mach-imx/mx31moboard-smartbot.c:91: .name = "soc-camera-pdrv",
arch/arm/mach-imx/mx31moboard-marxbot.c:181: .name = "soc-camera-pdrv",
arch/arm/mach-imx/mach-pcm037.c:329: .name = "soc-camera-pdrv",
arch/arm/mach-imx/mach-pcm037.c:337: .name = "soc-camera-pdrv",

I'll take a slightly simpler one mach Let's do the following analysis ,at91 platform (arch/arm/mach-at91/board-sam9m10g45ek.c), I intercepted the relevant code :

 * soc-camera OV2640
*/
#if defined(CONFIG_SOC_CAMERA_OV2640) || \
defined(CONFIG_SOC_CAMERA_OV2640_MODULE)
static unsigned long isi_camera_query_bus_param(struct soc_camera_link *link)
{
/* ISI board for ek using default 8-bits connection */
return SOCAM_DATAWIDTH_8;
} static int i2c_camera_power(struct device *dev, int on)
{
/* enable or disable the camera */
pr_debug("%s: %s the camera\n", __func__, on ? "ENABLE" : "DISABLE");
at91_set_gpio_output(AT91_PIN_PD13, !on); if (!on)
goto out; /* If enabled, give a reset impulse */
at91_set_gpio_output(AT91_PIN_PD12, 0);
msleep(20);
at91_set_gpio_output(AT91_PIN_PD12, 1);
msleep(100); out:
return 0;
} static struct i2c_board_info i2c_camera = {
I2C_BOARD_INFO("ov2640", 0x30),
}; static struct soc_camera_link iclink_ov2640 = {
.bus_id = 0,
.board_info = &i2c_camera,
.i2c_adapter_id = 0,
.power = i2c_camera_power,
.query_bus_param = isi_camera_query_bus_param,
}; static struct platform_device isi_ov2640 = {
.name = "soc-camera-pdrv",
.id = 0,
.dev = {
.platform_data = &iclink_ov2640,
},
};
#endif

The most important structure is soc_camera_link, It's all camera This kind of equipment needs to use the structure .bus_id It's used to describe which one it's connected to soc camera host On the bus , I'll talk about this later .board_info Used to describe the i2c Device information , For example, its model name , its i2c Address , I believe I have studied i2c People who drive are familiar with .i2c_adapter_id Used to describe the i2c Which one is attached to the device i2c On the bus .sensor It is generally controlled by i2c To achieve , That's why there are i2c Description of the device , Because the corresponding i2c Drive to drive it .power Generally refer to sensor Turn on and turn off the power module of , It's usually through a single gpio Controlled .query_bus_param Let's leave this member alone , Look at it when you use it .

All in all , Through the above information and the platform device registration behind , will soc-camera-pdrv Platform devices are added to the platform bus . That is to say, as long as the code is compiled into the kernel and called , that soc_camera_pdrv_probe It will be carried out . Let's continue to analyze the above soc_camera_pdrv_probe Well !

soc_camera_pdrv_probe The implementation of is very short , To illustrate , Post it, too :

static int soc_camera_pdrv_probe(struct platform_device *pdev)
{
struct soc_camera_desc *sdesc = pdev->dev.platform_data;
struct soc_camera_subdev_desc *ssdd = &sdesc->subdev_desc;
struct soc_camera_device *icd;
int ret; if (!sdesc)
return -EINVAL; icd = devm_kzalloc(&pdev->dev, sizeof(*icd), GFP_KERNEL);
if (!icd)
return -ENOMEM; /*
* In the asynchronous case ssdd->num_regulators == 0 yet, so, the below
* regulator allocation is a dummy. They are actually requested by the
* subdevice driver, using soc_camera_power_init(). Also note, that in
* that case regulators are attached to the I2C device and not to the
* camera platform device.
*/
ret = devm_regulator_bulk_get(&pdev->dev, ssdd->sd_pdata.num_regulators,
ssdd->sd_pdata.regulators);
if (ret < 0)
return ret; icd->iface = sdesc->host_desc.bus_id;
icd->sdesc = sdesc;
icd->pdev = &pdev->dev;
platform_set_drvdata(pdev, icd); icd->user_width = DEFAULT_WIDTH;
icd->user_height = DEFAULT_HEIGHT; return soc_camera_device_register(icd);
}

Here we'll start with the second important data structure soc_camera_device, What it represents in the kernel is a camera sensor equipment . One point needs to be explained in advance , We talked about data structures earlier soc_camera_link, When the driver is used , Split it into two structures , I think it's also for the sake of clearer code ! The corresponding structure is as follows :

struct soc_camera_desc {
struct soc_camera_subdev_desc subdev_desc;
struct soc_camera_host_desc host_desc;
};

therefore ,soc_camera_pdrv_probe Inside icd->iface = sdesc->host_desc.bus_id That's what I said above bus_id, It's used to describe which one it's connected to soc camera host on-line .soc_camera_pdrv_probe Mainly to create objects  soc_camera_device, It represents a camera sensor equipment . Of course, there can be multiple such devices at the same time , The driver is responsible for creating . And will platform All kinds of data from the device are put into soc_camera_device Inside , The final call soc_camera_device_register Will be camera sensor register .

soc_camera_device_register The code of will not be pasted , It actually does one thing , Will represent camera sensor The object of soc_camera_device Put it in the global linked list devices in , The others are parameter checking and so on .

Okay , Come here , In our system devices There is already one in the global list to represent camera sensor I've got a new device , It is here quietly waiting for the arrival of the driver responsible for it , We should be able to imagine , It's in charge of camera host Slightly . By the way , If we just need to write one sensor drive , So over here , Even if it's half done , The rest is to finish us camera sensor Corresponding to i2c Device drivers ( Reference resources drivers/media/i2c/soc_camera/, There are some of them that have been implemented i2c sensor drive ), as for camera host drive , Generally corresponding to soc Of sdk It will come true .

unfinished , To be continued !
2015 year 6 month


     Two years after graduation, I was doing embedded application development , Mainly SCM and arm linux Application development on , Then I did it for two years arm linux Drive development ,15 I've been doing it since 2000 pc End and embedded end development , Including server system tailoring 、 The underlying framework implements 、 Hardware acceleration, etc . Like technology sharing 、 communication ! Contact information : 907882971@qq.com、rongpmcu@gmail.com

camera Driving framework analysis ( On )【 turn 】 More articles about

  1. camera Driving framework analysis ( On )

    Preface camera The driving framework involves more knowledge points , especially camera There are a lot of interfaces , Some are directly connected to soc Of camif On the mouth , Some are through usb Interface exported , Such as usb camera. I will mainly discuss the former here , ...

  2. camera Driving framework analysis ( in )

    camera host The driver Let's start the analysis camera host Well , If you just want to know camera sensor How to write the driver , I don't want to know how to call the internal process , How to design an architecture , You can skip that part , Go straight to see it i ...

  3. camera Driving framework analysis ( Next )

    sensor The driver v4l2_i2c_new_subdev_board First use client = i2c_new_device(adapter, info); establish info Corresponding i2c_client object ( representative ...

  4. Linux USB Driving framework analysis (2)【 turn 】

    from :http://blog.chinaunix.net/uid-23046336-id-3243543.html   I saw http://blog.chinaunix.net/uid-11848011 ...

  5. Linux USB Driving framework analysis 【 turn 】

    from :http://blog.chinaunix.net/uid-11848011-id-96188.html First contact with OS Related device driver writing , I think it's quite interesting , In order not to forget what I have seen , Notes and summaries ...

  6. linux Drive Foundation Series --linux spi Driving framework analysis

    Preface It's mainly about Linux Next spi The driver framework has an overall control , So some details are ignored , At the same time, it involves some driving basis , For example, platform driven . The principle of the equipment model is not explained in detail . If there are any mistakes , Please point out , thank you ! spi ...

  7. linux Drive Foundation Series --linux spi Driving framework analysis ( To continue )

    Preface This article is right linux Drive Foundation Series --linux spi A supplement to driving framework analysis , Mainly added the latest linux The device tree in the kernel . spi Device tree information As mentioned in the previous article , Controller device and s ...

  8. Linux Next USB Driving framework analysis 【 turn 】

    from :http://blog.csdn.net/brucexu1978/article/details/17583407 Copyright notice : This article is an original blog article , No reprint without the permission of the blogger . http://www.c ...

  9. Linux USB Driving framework analysis 【 turn 】

    from :http://blog.csdn.net/jeffade/article/details/7701431 Linux USB Driving framework analysis ( One ) First contact and OS Related device driver writing , I think it's quite interesting ...

Random recommendation

  1. About eclispe Save settings for automatic code formatting

    Recently in project development , All developers are required to , The code must be formatted and (Ctrl+Shift+F), But sometimes I forget to format , Today, after watching a kind of preservation eclipse You can set the format code automatically 1. Please be here eclipse Settings ...

  2. About non blocking connect Some of the details of

    We use it man connection Command to see manual , as follows :   EINPROGRESS The socket is nonblocking and the connection cannot be com ...

  3. systemd.service Chinese Manual

    Copyright notice The translator of this article is a firm supporter of the concept of open source , So this article is not software , But in the spirit of open source . There is no guarantee : The translator does not guarantee the accuracy of the translation , We will not bear any loss caused by using this document . free use : Anyone can do it by himself ...

  4. JVMj Mechanism

  5. Vue---- Directory structure

    Directory structure : (1):build:---------------------------------------------------------------------------------: preservation ...

  6. See you for a long time : original Chrome Browser support Import from grammar

    The following three conditions need to be met : 1. The high version of the Chrome , All in all, the newer the better ……, For other browsers, please refer to :https://caniuse.com/#search=import 2. It must be in a server environment to run , for example a ...

  7. CSV File read and write

    from :http://www.cnblogs.com/Clin/archive/2013/03/14/2959022.html public class CSVFileHelper { /// < ...

  8. Mongodb Replica set + Cluster environment deployment

    This is described in detail mongodb The principle of replica set and partition of , I won't repeat it here . Here's the record Mongodb Replica set + The process of deployment in a partitioned cluster environment : MongoDB Sharding Cluster, Three roles are needed : Shard S ...

  9. Datatable Omit the contents of the display column , When the mouse is on the content , The suspension shows all the contents

    The first way is to see it online , It didn't work , Post it for reference <!DOCTYPE html> <html lang="en"> <head> <meta ...

  10. C++ The function of virtual inheritance

    C++ Virtual inheritance can prevent the ambiguity caused by multiple inheritance . Virtual inheritance , That is to add... Before the inherited class virtual keyword , The inherited class is called the virtual base class , As in the following code base class . Virtual inheritance can prevent ambiguity in multiple inheritance . clas ...