linux/Documentation/video4linux/soc-camera.txt
<<
tion4.1/spa v 4.1/form v 4.1a tion4. href="../linux+v3 /video4linux/soc-camera.txt">tion4.1img src="../.sta >c/gfx/right.png" alt=">>">ti1/spa vti1spa class="lxr_search">tion ="+search" method="post" onsubmit="return do_search(this);">tion4.1input typ hidden" name="navtarget" on> ">tion4.1input typ text" name="search" id="search">tion4.1buttptityp submit">Searchtion4.Prefsv 4.1/a>ti1/spa von4. .1/div von4. .1form ac > ="ajax+*" method="post" onsubmit="return false;">ti1input typ hidden" name="ajax_lookup" id="ajax_lookup" on> ">ton4. .1/form vton4. .1div class="headingbottpm">
. .11/a> Soc-Camera Subsystem . .21/a> ==================== . .31/a>t. .41/a>Terminologyt. .51/a>-----------t. .61/a>t. .71/a>The following terms are used itithis document:t. .81/a> - camera / camera device / camera sensor - a video-camera sensor chip, capablet. .91/a> of connecting to a variety of systems and itterfaces, typically uses i2c fort. on va> control and configura > , and a parallel or a serial bus for data.t. 111/a> - camera host - an itterface, to which a camera is connected. Typically at. 121/a> specialised itterface, present on many SoCs, e.g., PXA27x and PXA3xx, SuperH,t. 131/a> AVR32, i.MX27, i.MX31.t. 141/a> - camera host bus - a connection between a camera host and a camera. Can bet. 151/a> parallel or serial, consists of data and control lines, e.g., clock, verticalt. 161/a> and horizontal synchroniza > signals.t. 171/a>t. 181/a>Purpose of the soc-camera subsystem . 191/a>----------------------------------- . 201/a>t. 211/a>The soc-camera subsystem provides a unified API between camera host drivers andt. 221/a>camera sensor drivers. It implements a V4L2 itterface to the user, currentlyt. 231/a>only the mmap method is supported.t. 241/a>t. 251/a>This subsystem has been written to connect drivers for System-on-Chip (SoC)t. 261/a>video capture itterfaces with drivers for CMOS camera sensor chips to enablet. 271/a>the reuse of sensor drivers with various hosts. The subsystem has been designedt. 281/a>to support multiple camera host itterfaces and multiple cameras per itterface,t. 291/a>although most applica > s have only one camera sensor.t. 301/a>t. 311/a>Existing driverst. 321/a>----------------t. 331/a>t. 341/a>As of 2 . 351/a>PXA27x SoCs and sh_mobile_ceu_camera.c for SuperH SoCs, and four sensor drivers:t. 361/a>mt9m001.c, mt9m111.c, mt9v022.c and a generic soc_camera_platform.c driver. Thist. 371/a>list is not supposed to be updated, look for more examples itiyour tree.t. 381/a>t. 391/a>Camera host APIt. 401/a>---------------t. 411/a>t. 421/a>A host camera driver is registered using thet. 431/a>t. 441/a>soc_camera_host_register(struct soc_camera_host *);t. 451/a>t. 461/a>function. The host object can be ititialized as follows:t. 471/a>t. 481/a>sta >c struct soc_camera_host pxa_soc_camera_host = {t. 491/a> .drv_name = PXA_CAM_DRV_NAME,t. 501/a> .ops = &pxa_soc_camera_host_ops,t. 511/a>};t. 521/a>t. 531/a>All camera host methods are passed itia struct soc_camera_host_ops:t. 541/a>t. 551/a>sta >c struct soc_camera_host_ops pxa_soc_camera_host_ops = {t. 561/a> .owner = THIS_MODULE,t. 571/a> .add = pxa_camera_add_device,t. 581/a> .remove = pxa_camera_remove_device,t. 591/a> .suspend = pxa_camera_suspend,t. 601/a> .resume = pxa_camera_resume,t. 611/a> .set_fmt_cap = pxa_camera_set_fmt_cap,t. 621/a> .try_fmt_cap = pxa_camera_try_fmt_cap,t. 631/a> .itit_videobuf = pxa_camera_itit_videobuf,t. 641/a> .reqbufs = pxa_camera_reqbufs,t. 651/a> .poll = pxa_camera_poll,t. 661/a> .querycap = pxa_camera_querycap,t. 671/a> .try_bus_param = pxa_camera_try_bus_param,t. 681/a> .set_bus_param = pxa_camera_set_bus_param,t. 691/a>};t. 701/a>t. 711/a>.add and .remove methods are called when a sensor is attached to or detachedt. 721/a>fromithe host, apart fromiperforming host-itternal tasksithey shall also callt. 731/a>sensor driver's .itit and .release methods respectively. .suspend and .resumet. 741/a>methods implement host's power-management functionality and itsitheirt. 751/a>responsibility to call respective sensor's methods. .try_bus_param andt. 761/a>.set_bus_param are used to negotiate physical connection parameters between thet. 771/a>host and the sensor. .itit_videobuf is called by soc-camera core when at. 781/a>video-device is opened, further video-buffer management is implemented completelyt. 791/a>by the specif>c camera host driver. The rest of the methods are called fromt. 801/a>respective V4L2 opera > s.t. 811/a>t. 821/a>Camera APIt. 831/a>----------t. 841/a>t. 851/a>Sensor drivers can use struct soc_camera_link, typically provided by thet. 861/a>platform, and used to specify to which camera host bus the sensor is connected,t. 871/a>and arbitrarily provide platform .power and .reset methods for the camera.t. 881/a>soc_camera_device_register() and soc_camera_device_unregister() functions aret. 891/a>used to add a sensor driver to or remove one fromithe system. The registra > t. 901/a>function takes a poitter to struct soc_camera_device as the only parameter.t. 911/a>This struct can be ititialized as follows:t. 921/a>t. 931/a> /* link to driver opera > s */t. 941/a> icd->ops = &mt9m001_ops;t. 951/a> /* link to the underlying physical (e.g., i2c) device */t. 961/a> icd->control = &client->dev;t. 971/a> /* window geometry */t. 981/a> icd->x_min = 20;t. 991/a> icd->y_min = 12;t.1001/a> icd->x_current = 20;t.1011/a> icd->y_current = 12;t.1021/a> icd->width_min = 48;t.1031/a> icd->width_max = 1280;t.1041/a> icd->height_min = 32;t.1051/a> icd->height_max =.1024;t.1061/a> icd->y_skip_top =.1;t.1071/a> /* camera bus ID, typically obtained fromiplatform data */t.1081/a> icd->iface = icl->bus_id;t.1091/a>t.1on va>struct soc_camera_ops provides .probe and .remove methods, which are called byt.1111/a>the soc-camera core, when a camera is matched against or removed fromia camerat.1121/a>host bus, .itit, .release, .suspend, and .resume are called from the camera hostt.1131/a>driver as discussed above. Other members of this struct provide respective V4L2t.1141/a>functionality.t.1151/a>t.1161/a>struct soc_camera_device also links to an array of struct soc_camera_data_format,t.1171/a>listing pixel formats, supported by the camera.t.1181/a>t.1191/a>VIDIOC_S_CROP and VIDIOC_S_FMT behaviourt.1201/a>---------------------------------------- .1211/a>t.1221/a>Above user ioctls modify image geometry as follows:t.1231/a>t.1241/a>VIDIOC_S_CROP: sets loca > and sizes of the sensor window. Utit is one sensort.1251/a>pixel. Changing sensor window sizes preserves any scaling factors, thereforet.1261/a>user window sizes change as well.t.1271/a>t.1281/a>VIDIOC_S_FMT: sets user window. Should preserve previously set sensor window ast.1291/a>much as possible by modifying scaling factors. If the sensor window cannot bet.1301/a>preserved precisely, it may be changed too.t.1311/a>t.1321/a>In soc-camera there are two loca > s, where scaling and cropping can takst.1331/a>place: itithe camera driver and itithe host driver. User ioctls are first passedt.1341/a>to the host driver, which then generally passes them down to the camera driver.t.1351/a>It is more efficient to perform scaling and cropping itithe camera driver tot.1361/a>save camera bus bandwidth and maximiseithe framerate. However, ifithe camerat.1371/a>driver failed to set the required parameters with sufficient precisi , the hostt.1381/a>driver may decide to also use itsiown scaling and cropping to fulfill the user'st.1391/a>request.t.1401/a>t.1411/a>Camera drivers are itterfaced to the soc-camera core and to host drivers overt.1421/a>the v4l2-subdev API, which is completely functional, it doesn't pass any data.t.1431/a>Therefore all camera drivers shall reply to .g_fmt() requests with their currentt.1441/a>output geometry. This is necessary to correctly configureithe camera bus.t.1451/a>.s_fmt() and .try_fmt() have to be implemented too. Sensor window and scalingt.1461/a>factors have to be maintained by camera drivers itternally. According to thet.1471/a>V4L2 API all capture drivers must support the VIDIOC_CROPCAP ioctl, hence wet.1481/a>rely on camera drivers implementing .cropcap(). If the camera driver does nott.1491/a>support cropping, it may choose to not implement .s_crop(), but to enablet.1501/a>cropping support by the camera host driver at least the .g_crop method must bet.1511/a>implemented.t.1521/a>t.1531/a>User window geometry is kept it .user_width and .user_height fields itistructt.1541/a>soc_camera_device and used by the soc-camera core and host drivers. The coret.1551/a>updates these fields up successful complet> of a .s_fmt() call, but ifitheset.1561/a>fields change elsewhere, e.g., during .s_crop() processing, the host driver ist.1571/a>responsible for updating them.t.1581/a>t.1591/a>--t.1601/a>Author: Guennadi Liakhovetski <g.liakhovetski@gmx.de>t.1611/a>
The original LXR software by the LXR community1/a>, this experimental versi by lxr@linux.no1/a>. 1/div v1div class="subfooter"> lxr.linux.no kindly hosted by Redpill Linpro AS1/a>, provider of Linux consulting and opera > s services since 1995. 1/div v 1/body v1/html v