Hans Verkuil | 2a1fcdf | 2008-11-29 21:36:58 -0300 | [diff] [blame] | 1 | Overview of the V4L2 driver framework |
| 2 | ===================================== |
| 3 | |
| 4 | This text documents the various structures provided by the V4L2 framework and |
| 5 | their relationships. |
| 6 | |
| 7 | |
| 8 | Introduction |
| 9 | ------------ |
| 10 | |
| 11 | The V4L2 drivers tend to be very complex due to the complexity of the |
| 12 | hardware: most devices have multiple ICs, export multiple device nodes in |
| 13 | /dev, and create also non-V4L2 devices such as DVB, ALSA, FB, I2C and input |
| 14 | (IR) devices. |
| 15 | |
| 16 | Especially the fact that V4L2 drivers have to setup supporting ICs to |
| 17 | do audio/video muxing/encoding/decoding makes it more complex than most. |
| 18 | Usually these ICs are connected to the main bridge driver through one or |
| 19 | more I2C busses, but other busses can also be used. Such devices are |
| 20 | called 'sub-devices'. |
| 21 | |
| 22 | For a long time the framework was limited to the video_device struct for |
| 23 | creating V4L device nodes and video_buf for handling the video buffers |
| 24 | (note that this document does not discuss the video_buf framework). |
| 25 | |
| 26 | This meant that all drivers had to do the setup of device instances and |
| 27 | connecting to sub-devices themselves. Some of this is quite complicated |
| 28 | to do right and many drivers never did do it correctly. |
| 29 | |
| 30 | There is also a lot of common code that could never be refactored due to |
| 31 | the lack of a framework. |
| 32 | |
| 33 | So this framework sets up the basic building blocks that all drivers |
| 34 | need and this same framework should make it much easier to refactor |
| 35 | common code into utility functions shared by all drivers. |
| 36 | |
| 37 | |
| 38 | Structure of a driver |
| 39 | --------------------- |
| 40 | |
| 41 | All drivers have the following structure: |
| 42 | |
| 43 | 1) A struct for each device instance containing the device state. |
| 44 | |
| 45 | 2) A way of initializing and commanding sub-devices (if any). |
| 46 | |
Hans Verkuil | f44026d | 2010-08-06 12:52:43 -0300 | [diff] [blame] | 47 | 3) Creating V4L2 device nodes (/dev/videoX, /dev/vbiX and /dev/radioX) |
| 48 | and keeping track of device-node specific data. |
Hans Verkuil | 2a1fcdf | 2008-11-29 21:36:58 -0300 | [diff] [blame] | 49 | |
Mauro Carvalho Chehab | 44061c0 | 2009-02-14 07:29:07 -0300 | [diff] [blame] | 50 | 4) Filehandle-specific structs containing per-filehandle data; |
| 51 | |
| 52 | 5) video buffer handling. |
Hans Verkuil | 2a1fcdf | 2008-11-29 21:36:58 -0300 | [diff] [blame] | 53 | |
| 54 | This is a rough schematic of how it all relates: |
| 55 | |
| 56 | device instances |
| 57 | | |
| 58 | +-sub-device instances |
| 59 | | |
| 60 | \-V4L2 device nodes |
| 61 | | |
| 62 | \-filehandle instances |
| 63 | |
| 64 | |
| 65 | Structure of the framework |
| 66 | -------------------------- |
| 67 | |
| 68 | The framework closely resembles the driver structure: it has a v4l2_device |
| 69 | struct for the device instance data, a v4l2_subdev struct to refer to |
| 70 | sub-device instances, the video_device struct stores V4L2 device node data |
| 71 | and in the future a v4l2_fh struct will keep track of filehandle instances |
| 72 | (this is not yet implemented). |
| 73 | |
| 74 | |
| 75 | struct v4l2_device |
| 76 | ------------------ |
| 77 | |
| 78 | Each device instance is represented by a struct v4l2_device (v4l2-device.h). |
| 79 | Very simple devices can just allocate this struct, but most of the time you |
| 80 | would embed this struct inside a larger struct. |
| 81 | |
| 82 | You must register the device instance: |
| 83 | |
| 84 | v4l2_device_register(struct device *dev, struct v4l2_device *v4l2_dev); |
| 85 | |
| 86 | Registration will initialize the v4l2_device struct and link dev->driver_data |
Hans Verkuil | 3a63e449 | 2009-02-14 11:54:23 -0300 | [diff] [blame] | 87 | to v4l2_dev. If v4l2_dev->name is empty then it will be set to a value derived |
| 88 | from dev (driver name followed by the bus_id, to be precise). If you set it |
| 89 | up before calling v4l2_device_register then it will be untouched. If dev is |
| 90 | NULL, then you *must* setup v4l2_dev->name before calling v4l2_device_register. |
Hans Verkuil | 2a1fcdf | 2008-11-29 21:36:58 -0300 | [diff] [blame] | 91 | |
Hans Verkuil | 102e781 | 2009-05-02 10:12:50 -0300 | [diff] [blame] | 92 | You can use v4l2_device_set_name() to set the name based on a driver name and |
| 93 | a driver-global atomic_t instance. This will generate names like ivtv0, ivtv1, |
| 94 | etc. If the name ends with a digit, then it will insert a dash: cx18-0, |
| 95 | cx18-1, etc. This function returns the instance number. |
| 96 | |
Hans Verkuil | a47ddf1 | 2008-12-19 10:20:22 -0300 | [diff] [blame] | 97 | The first 'dev' argument is normally the struct device pointer of a pci_dev, |
Janne Grunau | 073d696 | 2009-04-01 08:30:06 -0300 | [diff] [blame] | 98 | usb_interface or platform_device. It is rare for dev to be NULL, but it happens |
Hans Verkuil | 0057596 | 2009-03-13 10:03:04 -0300 | [diff] [blame] | 99 | with ISA devices or when one device creates multiple PCI devices, thus making |
| 100 | it impossible to associate v4l2_dev with a particular parent. |
Hans Verkuil | a47ddf1 | 2008-12-19 10:20:22 -0300 | [diff] [blame] | 101 | |
Hans Verkuil | 98ec633 | 2009-03-08 17:02:10 -0300 | [diff] [blame] | 102 | You can also supply a notify() callback that can be called by sub-devices to |
| 103 | notify you of events. Whether you need to set this depends on the sub-device. |
| 104 | Any notifications a sub-device supports must be defined in a header in |
| 105 | include/media/<subdevice>.h. |
| 106 | |
Hans Verkuil | 2a1fcdf | 2008-11-29 21:36:58 -0300 | [diff] [blame] | 107 | You unregister with: |
| 108 | |
| 109 | v4l2_device_unregister(struct v4l2_device *v4l2_dev); |
| 110 | |
| 111 | Unregistering will also automatically unregister all subdevs from the device. |
| 112 | |
Hans Verkuil | ae6cfaa | 2009-03-14 08:28:45 -0300 | [diff] [blame] | 113 | If you have a hotpluggable device (e.g. a USB device), then when a disconnect |
| 114 | happens the parent device becomes invalid. Since v4l2_device has a pointer to |
| 115 | that parent device it has to be cleared as well to mark that the parent is |
| 116 | gone. To do this call: |
| 117 | |
| 118 | v4l2_device_disconnect(struct v4l2_device *v4l2_dev); |
| 119 | |
| 120 | This does *not* unregister the subdevs, so you still need to call the |
| 121 | v4l2_device_unregister() function for that. If your driver is not hotpluggable, |
| 122 | then there is no need to call v4l2_device_disconnect(). |
| 123 | |
Hans Verkuil | 2a1fcdf | 2008-11-29 21:36:58 -0300 | [diff] [blame] | 124 | Sometimes you need to iterate over all devices registered by a specific |
| 125 | driver. This is usually the case if multiple device drivers use the same |
| 126 | hardware. E.g. the ivtvfb driver is a framebuffer driver that uses the ivtv |
| 127 | hardware. The same is true for alsa drivers for example. |
| 128 | |
| 129 | You can iterate over all registered devices as follows: |
| 130 | |
| 131 | static int callback(struct device *dev, void *p) |
| 132 | { |
| 133 | struct v4l2_device *v4l2_dev = dev_get_drvdata(dev); |
| 134 | |
| 135 | /* test if this device was inited */ |
| 136 | if (v4l2_dev == NULL) |
| 137 | return 0; |
| 138 | ... |
| 139 | return 0; |
| 140 | } |
| 141 | |
| 142 | int iterate(void *p) |
| 143 | { |
| 144 | struct device_driver *drv; |
| 145 | int err; |
| 146 | |
| 147 | /* Find driver 'ivtv' on the PCI bus. |
| 148 | pci_bus_type is a global. For USB busses use usb_bus_type. */ |
| 149 | drv = driver_find("ivtv", &pci_bus_type); |
| 150 | /* iterate over all ivtv device instances */ |
| 151 | err = driver_for_each_device(drv, NULL, p, callback); |
| 152 | put_driver(drv); |
| 153 | return err; |
| 154 | } |
| 155 | |
| 156 | Sometimes you need to keep a running counter of the device instance. This is |
| 157 | commonly used to map a device instance to an index of a module option array. |
| 158 | |
| 159 | The recommended approach is as follows: |
| 160 | |
| 161 | static atomic_t drv_instance = ATOMIC_INIT(0); |
| 162 | |
Hans Verkuil | 89aec3e | 2009-02-07 07:07:04 -0300 | [diff] [blame] | 163 | static int __devinit drv_probe(struct pci_dev *pdev, |
Hans Verkuil | 2a1fcdf | 2008-11-29 21:36:58 -0300 | [diff] [blame] | 164 | const struct pci_device_id *pci_id) |
| 165 | { |
| 166 | ... |
| 167 | state->instance = atomic_inc_return(&drv_instance) - 1; |
| 168 | } |
| 169 | |
| 170 | |
| 171 | struct v4l2_subdev |
| 172 | ------------------ |
| 173 | |
| 174 | Many drivers need to communicate with sub-devices. These devices can do all |
| 175 | sort of tasks, but most commonly they handle audio and/or video muxing, |
| 176 | encoding or decoding. For webcams common sub-devices are sensors and camera |
| 177 | controllers. |
| 178 | |
| 179 | Usually these are I2C devices, but not necessarily. In order to provide the |
| 180 | driver with a consistent interface to these sub-devices the v4l2_subdev struct |
| 181 | (v4l2-subdev.h) was created. |
| 182 | |
| 183 | Each sub-device driver must have a v4l2_subdev struct. This struct can be |
| 184 | stand-alone for simple sub-devices or it might be embedded in a larger struct |
| 185 | if more state information needs to be stored. Usually there is a low-level |
| 186 | device struct (e.g. i2c_client) that contains the device data as setup |
| 187 | by the kernel. It is recommended to store that pointer in the private |
| 188 | data of v4l2_subdev using v4l2_set_subdevdata(). That makes it easy to go |
| 189 | from a v4l2_subdev to the actual low-level bus-specific device data. |
| 190 | |
| 191 | You also need a way to go from the low-level struct to v4l2_subdev. For the |
| 192 | common i2c_client struct the i2c_set_clientdata() call is used to store a |
| 193 | v4l2_subdev pointer, for other busses you may have to use other methods. |
| 194 | |
Laurent Pinchart | 692d5522 | 2010-07-30 17:24:55 -0300 | [diff] [blame] | 195 | Bridges might also need to store per-subdev private data, such as a pointer to |
| 196 | bridge-specific per-subdev private data. The v4l2_subdev structure provides |
| 197 | host private data for that purpose that can be accessed with |
| 198 | v4l2_get_subdev_hostdata() and v4l2_set_subdev_hostdata(). |
| 199 | |
Hans Verkuil | 2a1fcdf | 2008-11-29 21:36:58 -0300 | [diff] [blame] | 200 | From the bridge driver perspective you load the sub-device module and somehow |
| 201 | obtain the v4l2_subdev pointer. For i2c devices this is easy: you call |
| 202 | i2c_get_clientdata(). For other busses something similar needs to be done. |
| 203 | Helper functions exists for sub-devices on an I2C bus that do most of this |
| 204 | tricky work for you. |
| 205 | |
| 206 | Each v4l2_subdev contains function pointers that sub-device drivers can |
| 207 | implement (or leave NULL if it is not applicable). Since sub-devices can do |
| 208 | so many different things and you do not want to end up with a huge ops struct |
| 209 | of which only a handful of ops are commonly implemented, the function pointers |
| 210 | are sorted according to category and each category has its own ops struct. |
| 211 | |
| 212 | The top-level ops struct contains pointers to the category ops structs, which |
| 213 | may be NULL if the subdev driver does not support anything from that category. |
| 214 | |
| 215 | It looks like this: |
| 216 | |
| 217 | struct v4l2_subdev_core_ops { |
Hans Verkuil | aecde8b5 | 2008-12-30 07:14:19 -0300 | [diff] [blame] | 218 | int (*g_chip_ident)(struct v4l2_subdev *sd, struct v4l2_dbg_chip_ident *chip); |
Hans Verkuil | 2a1fcdf | 2008-11-29 21:36:58 -0300 | [diff] [blame] | 219 | int (*log_status)(struct v4l2_subdev *sd); |
| 220 | int (*init)(struct v4l2_subdev *sd, u32 val); |
| 221 | ... |
| 222 | }; |
| 223 | |
| 224 | struct v4l2_subdev_tuner_ops { |
| 225 | ... |
| 226 | }; |
| 227 | |
| 228 | struct v4l2_subdev_audio_ops { |
| 229 | ... |
| 230 | }; |
| 231 | |
| 232 | struct v4l2_subdev_video_ops { |
| 233 | ... |
| 234 | }; |
| 235 | |
| 236 | struct v4l2_subdev_ops { |
| 237 | const struct v4l2_subdev_core_ops *core; |
| 238 | const struct v4l2_subdev_tuner_ops *tuner; |
| 239 | const struct v4l2_subdev_audio_ops *audio; |
| 240 | const struct v4l2_subdev_video_ops *video; |
| 241 | }; |
| 242 | |
| 243 | The core ops are common to all subdevs, the other categories are implemented |
| 244 | depending on the sub-device. E.g. a video device is unlikely to support the |
| 245 | audio ops and vice versa. |
| 246 | |
| 247 | This setup limits the number of function pointers while still making it easy |
| 248 | to add new ops and categories. |
| 249 | |
| 250 | A sub-device driver initializes the v4l2_subdev struct using: |
| 251 | |
Hans Verkuil | 89aec3e | 2009-02-07 07:07:04 -0300 | [diff] [blame] | 252 | v4l2_subdev_init(sd, &ops); |
Hans Verkuil | 2a1fcdf | 2008-11-29 21:36:58 -0300 | [diff] [blame] | 253 | |
| 254 | Afterwards you need to initialize subdev->name with a unique name and set the |
| 255 | module owner. This is done for you if you use the i2c helper functions. |
| 256 | |
| 257 | A device (bridge) driver needs to register the v4l2_subdev with the |
| 258 | v4l2_device: |
| 259 | |
Hans Verkuil | 89aec3e | 2009-02-07 07:07:04 -0300 | [diff] [blame] | 260 | int err = v4l2_device_register_subdev(v4l2_dev, sd); |
Hans Verkuil | 2a1fcdf | 2008-11-29 21:36:58 -0300 | [diff] [blame] | 261 | |
| 262 | This can fail if the subdev module disappeared before it could be registered. |
| 263 | After this function was called successfully the subdev->dev field points to |
| 264 | the v4l2_device. |
| 265 | |
| 266 | You can unregister a sub-device using: |
| 267 | |
Hans Verkuil | 89aec3e | 2009-02-07 07:07:04 -0300 | [diff] [blame] | 268 | v4l2_device_unregister_subdev(sd); |
Hans Verkuil | 2a1fcdf | 2008-11-29 21:36:58 -0300 | [diff] [blame] | 269 | |
Hans Verkuil | 89aec3e | 2009-02-07 07:07:04 -0300 | [diff] [blame] | 270 | Afterwards the subdev module can be unloaded and sd->dev == NULL. |
Hans Verkuil | 2a1fcdf | 2008-11-29 21:36:58 -0300 | [diff] [blame] | 271 | |
| 272 | You can call an ops function either directly: |
| 273 | |
Hans Verkuil | 89aec3e | 2009-02-07 07:07:04 -0300 | [diff] [blame] | 274 | err = sd->ops->core->g_chip_ident(sd, &chip); |
Hans Verkuil | 2a1fcdf | 2008-11-29 21:36:58 -0300 | [diff] [blame] | 275 | |
| 276 | but it is better and easier to use this macro: |
| 277 | |
Hans Verkuil | 89aec3e | 2009-02-07 07:07:04 -0300 | [diff] [blame] | 278 | err = v4l2_subdev_call(sd, core, g_chip_ident, &chip); |
Hans Verkuil | 2a1fcdf | 2008-11-29 21:36:58 -0300 | [diff] [blame] | 279 | |
| 280 | The macro will to the right NULL pointer checks and returns -ENODEV if subdev |
| 281 | is NULL, -ENOIOCTLCMD if either subdev->core or subdev->core->g_chip_ident is |
| 282 | NULL, or the actual result of the subdev->ops->core->g_chip_ident ops. |
| 283 | |
| 284 | It is also possible to call all or a subset of the sub-devices: |
| 285 | |
Hans Verkuil | 89aec3e | 2009-02-07 07:07:04 -0300 | [diff] [blame] | 286 | v4l2_device_call_all(v4l2_dev, 0, core, g_chip_ident, &chip); |
Hans Verkuil | 2a1fcdf | 2008-11-29 21:36:58 -0300 | [diff] [blame] | 287 | |
| 288 | Any subdev that does not support this ops is skipped and error results are |
| 289 | ignored. If you want to check for errors use this: |
| 290 | |
Hans Verkuil | 89aec3e | 2009-02-07 07:07:04 -0300 | [diff] [blame] | 291 | err = v4l2_device_call_until_err(v4l2_dev, 0, core, g_chip_ident, &chip); |
Hans Verkuil | 2a1fcdf | 2008-11-29 21:36:58 -0300 | [diff] [blame] | 292 | |
| 293 | Any error except -ENOIOCTLCMD will exit the loop with that error. If no |
| 294 | errors (except -ENOIOCTLCMD) occured, then 0 is returned. |
| 295 | |
| 296 | The second argument to both calls is a group ID. If 0, then all subdevs are |
| 297 | called. If non-zero, then only those whose group ID match that value will |
Hans Verkuil | b016760 | 2009-02-14 12:00:53 -0300 | [diff] [blame] | 298 | be called. Before a bridge driver registers a subdev it can set sd->grp_id |
Hans Verkuil | 2a1fcdf | 2008-11-29 21:36:58 -0300 | [diff] [blame] | 299 | to whatever value it wants (it's 0 by default). This value is owned by the |
| 300 | bridge driver and the sub-device driver will never modify or use it. |
| 301 | |
| 302 | The group ID gives the bridge driver more control how callbacks are called. |
| 303 | For example, there may be multiple audio chips on a board, each capable of |
| 304 | changing the volume. But usually only one will actually be used when the |
| 305 | user want to change the volume. You can set the group ID for that subdev to |
| 306 | e.g. AUDIO_CONTROLLER and specify that as the group ID value when calling |
| 307 | v4l2_device_call_all(). That ensures that it will only go to the subdev |
| 308 | that needs it. |
| 309 | |
Hans Verkuil | 98ec633 | 2009-03-08 17:02:10 -0300 | [diff] [blame] | 310 | If the sub-device needs to notify its v4l2_device parent of an event, then |
| 311 | it can call v4l2_subdev_notify(sd, notification, arg). This macro checks |
| 312 | whether there is a notify() callback defined and returns -ENODEV if not. |
| 313 | Otherwise the result of the notify() call is returned. |
| 314 | |
Hans Verkuil | 2a1fcdf | 2008-11-29 21:36:58 -0300 | [diff] [blame] | 315 | The advantage of using v4l2_subdev is that it is a generic struct and does |
| 316 | not contain any knowledge about the underlying hardware. So a driver might |
| 317 | contain several subdevs that use an I2C bus, but also a subdev that is |
| 318 | controlled through GPIO pins. This distinction is only relevant when setting |
| 319 | up the device, but once the subdev is registered it is completely transparent. |
| 320 | |
| 321 | |
| 322 | I2C sub-device drivers |
| 323 | ---------------------- |
| 324 | |
| 325 | Since these drivers are so common, special helper functions are available to |
| 326 | ease the use of these drivers (v4l2-common.h). |
| 327 | |
| 328 | The recommended method of adding v4l2_subdev support to an I2C driver is to |
| 329 | embed the v4l2_subdev struct into the state struct that is created for each |
| 330 | I2C device instance. Very simple devices have no state struct and in that case |
| 331 | you can just create a v4l2_subdev directly. |
| 332 | |
| 333 | A typical state struct would look like this (where 'chipname' is replaced by |
| 334 | the name of the chip): |
| 335 | |
| 336 | struct chipname_state { |
| 337 | struct v4l2_subdev sd; |
| 338 | ... /* additional state fields */ |
| 339 | }; |
| 340 | |
| 341 | Initialize the v4l2_subdev struct as follows: |
| 342 | |
| 343 | v4l2_i2c_subdev_init(&state->sd, client, subdev_ops); |
| 344 | |
| 345 | This function will fill in all the fields of v4l2_subdev and ensure that the |
| 346 | v4l2_subdev and i2c_client both point to one another. |
| 347 | |
| 348 | You should also add a helper inline function to go from a v4l2_subdev pointer |
| 349 | to a chipname_state struct: |
| 350 | |
| 351 | static inline struct chipname_state *to_state(struct v4l2_subdev *sd) |
| 352 | { |
| 353 | return container_of(sd, struct chipname_state, sd); |
| 354 | } |
| 355 | |
| 356 | Use this to go from the v4l2_subdev struct to the i2c_client struct: |
| 357 | |
| 358 | struct i2c_client *client = v4l2_get_subdevdata(sd); |
| 359 | |
| 360 | And this to go from an i2c_client to a v4l2_subdev struct: |
| 361 | |
| 362 | struct v4l2_subdev *sd = i2c_get_clientdata(client); |
| 363 | |
Hans Verkuil | 2a1fcdf | 2008-11-29 21:36:58 -0300 | [diff] [blame] | 364 | Make sure to call v4l2_device_unregister_subdev(sd) when the remove() callback |
| 365 | is called. This will unregister the sub-device from the bridge driver. It is |
| 366 | safe to call this even if the sub-device was never registered. |
| 367 | |
Hans Verkuil | f5360bd | 2009-01-15 06:09:05 -0300 | [diff] [blame] | 368 | You need to do this because when the bridge driver destroys the i2c adapter |
| 369 | the remove() callbacks are called of the i2c devices on that adapter. |
| 370 | After that the corresponding v4l2_subdev structures are invalid, so they |
| 371 | have to be unregistered first. Calling v4l2_device_unregister_subdev(sd) |
| 372 | from the remove() callback ensures that this is always done correctly. |
| 373 | |
Hans Verkuil | 2a1fcdf | 2008-11-29 21:36:58 -0300 | [diff] [blame] | 374 | |
| 375 | The bridge driver also has some helper functions it can use: |
| 376 | |
Hans Verkuil | e6574f2 | 2009-04-01 03:57:53 -0300 | [diff] [blame] | 377 | struct v4l2_subdev *sd = v4l2_i2c_new_subdev(v4l2_dev, adapter, |
Hans Verkuil | 53dacb1 | 2009-08-10 02:49:08 -0300 | [diff] [blame] | 378 | "module_foo", "chipid", 0x36, NULL); |
Hans Verkuil | 2a1fcdf | 2008-11-29 21:36:58 -0300 | [diff] [blame] | 379 | |
| 380 | This loads the given module (can be NULL if no module needs to be loaded) and |
| 381 | calls i2c_new_device() with the given i2c_adapter and chip/address arguments. |
Hans Verkuil | e6574f2 | 2009-04-01 03:57:53 -0300 | [diff] [blame] | 382 | If all goes well, then it registers the subdev with the v4l2_device. |
Hans Verkuil | 2a1fcdf | 2008-11-29 21:36:58 -0300 | [diff] [blame] | 383 | |
Hans Verkuil | 53dacb1 | 2009-08-10 02:49:08 -0300 | [diff] [blame] | 384 | You can also use the last argument of v4l2_i2c_new_subdev() to pass an array |
| 385 | of possible I2C addresses that it should probe. These probe addresses are |
| 386 | only used if the previous argument is 0. A non-zero argument means that you |
| 387 | know the exact i2c address so in that case no probing will take place. |
Hans Verkuil | 2a1fcdf | 2008-11-29 21:36:58 -0300 | [diff] [blame] | 388 | |
| 389 | Both functions return NULL if something went wrong. |
| 390 | |
Hans Verkuil | 53dacb1 | 2009-08-10 02:49:08 -0300 | [diff] [blame] | 391 | Note that the chipid you pass to v4l2_i2c_new_subdev() is usually |
Hans Verkuil | 2c79252 | 2009-03-12 18:34:19 -0300 | [diff] [blame] | 392 | the same as the module name. It allows you to specify a chip variant, e.g. |
| 393 | "saa7114" or "saa7115". In general though the i2c driver autodetects this. |
| 394 | The use of chipid is something that needs to be looked at more closely at a |
| 395 | later date. It differs between i2c drivers and as such can be confusing. |
| 396 | To see which chip variants are supported you can look in the i2c driver code |
| 397 | for the i2c_device_id table. This lists all the possibilities. |
| 398 | |
Hans Verkuil | 2c0b19a | 2009-06-09 17:29:29 -0300 | [diff] [blame] | 399 | There are two more helper functions: |
| 400 | |
| 401 | v4l2_i2c_new_subdev_cfg: this function adds new irq and platform_data |
| 402 | arguments and has both 'addr' and 'probed_addrs' arguments: if addr is not |
| 403 | 0 then that will be used (non-probing variant), otherwise the probed_addrs |
| 404 | are probed. |
| 405 | |
| 406 | For example: this will probe for address 0x10: |
| 407 | |
| 408 | struct v4l2_subdev *sd = v4l2_i2c_new_subdev_cfg(v4l2_dev, adapter, |
| 409 | "module_foo", "chipid", 0, NULL, 0, I2C_ADDRS(0x10)); |
| 410 | |
| 411 | v4l2_i2c_new_subdev_board uses an i2c_board_info struct which is passed |
| 412 | to the i2c driver and replaces the irq, platform_data and addr arguments. |
| 413 | |
| 414 | If the subdev supports the s_config core ops, then that op is called with |
| 415 | the irq and platform_data arguments after the subdev was setup. The older |
| 416 | v4l2_i2c_new_(probed_)subdev functions will call s_config as well, but with |
| 417 | irq set to 0 and platform_data set to NULL. |
| 418 | |
Hans Verkuil | 2a1fcdf | 2008-11-29 21:36:58 -0300 | [diff] [blame] | 419 | struct video_device |
| 420 | ------------------- |
| 421 | |
Hans Verkuil | a47ddf1 | 2008-12-19 10:20:22 -0300 | [diff] [blame] | 422 | The actual device nodes in the /dev directory are created using the |
| 423 | video_device struct (v4l2-dev.h). This struct can either be allocated |
| 424 | dynamically or embedded in a larger struct. |
| 425 | |
| 426 | To allocate it dynamically use: |
| 427 | |
| 428 | struct video_device *vdev = video_device_alloc(); |
| 429 | |
| 430 | if (vdev == NULL) |
| 431 | return -ENOMEM; |
| 432 | |
| 433 | vdev->release = video_device_release; |
| 434 | |
| 435 | If you embed it in a larger struct, then you must set the release() |
| 436 | callback to your own function: |
| 437 | |
| 438 | struct video_device *vdev = &my_vdev->vdev; |
| 439 | |
| 440 | vdev->release = my_vdev_release; |
| 441 | |
| 442 | The release callback must be set and it is called when the last user |
| 443 | of the video device exits. |
| 444 | |
| 445 | The default video_device_release() callback just calls kfree to free the |
| 446 | allocated memory. |
| 447 | |
| 448 | You should also set these fields: |
| 449 | |
Hans Verkuil | dfa9a5a | 2008-12-23 12:17:23 -0300 | [diff] [blame] | 450 | - v4l2_dev: set to the v4l2_device parent device. |
Hans Verkuil | a47ddf1 | 2008-12-19 10:20:22 -0300 | [diff] [blame] | 451 | - name: set to something descriptive and unique. |
Hans Verkuil | c7dd09d | 2008-12-23 13:42:25 -0300 | [diff] [blame] | 452 | - fops: set to the v4l2_file_operations struct. |
Hans Verkuil | a47ddf1 | 2008-12-19 10:20:22 -0300 | [diff] [blame] | 453 | - ioctl_ops: if you use the v4l2_ioctl_ops to simplify ioctl maintenance |
| 454 | (highly recommended to use this and it might become compulsory in the |
| 455 | future!), then set this to your v4l2_ioctl_ops struct. |
Hans Verkuil | ee6869a | 2010-09-26 08:47:38 -0300 | [diff] [blame] | 456 | - lock: leave to NULL if you want to do all the locking in the driver. |
| 457 | Otherwise you give it a pointer to a struct mutex_lock and before any |
| 458 | of the v4l2_file_operations is called this lock will be taken by the |
| 459 | core and released afterwards. |
Hans Verkuil | 0057596 | 2009-03-13 10:03:04 -0300 | [diff] [blame] | 460 | - parent: you only set this if v4l2_device was registered with NULL as |
| 461 | the parent device struct. This only happens in cases where one hardware |
| 462 | device has multiple PCI devices that all share the same v4l2_device core. |
| 463 | |
| 464 | The cx88 driver is an example of this: one core v4l2_device struct, but |
| 465 | it is used by both an raw video PCI device (cx8800) and a MPEG PCI device |
| 466 | (cx8802). Since the v4l2_device cannot be associated with a particular |
| 467 | PCI device it is setup without a parent device. But when the struct |
| 468 | video_device is setup you do know which parent PCI device to use. |
Hans Verkuil | a47ddf1 | 2008-12-19 10:20:22 -0300 | [diff] [blame] | 469 | |
Hans Verkuil | c7dd09d | 2008-12-23 13:42:25 -0300 | [diff] [blame] | 470 | If you use v4l2_ioctl_ops, then you should set either .unlocked_ioctl or |
| 471 | .ioctl to video_ioctl2 in your v4l2_file_operations struct. |
| 472 | |
| 473 | The v4l2_file_operations struct is a subset of file_operations. The main |
| 474 | difference is that the inode argument is omitted since it is never used. |
Hans Verkuil | a47ddf1 | 2008-12-19 10:20:22 -0300 | [diff] [blame] | 475 | |
Hans Verkuil | ee6869a | 2010-09-26 08:47:38 -0300 | [diff] [blame] | 476 | v4l2_file_operations and locking |
| 477 | -------------------------------- |
| 478 | |
| 479 | You can set a pointer to a mutex_lock in struct video_device. Usually this |
| 480 | will be either a top-level mutex or a mutex per device node. If you want |
| 481 | finer-grained locking then you have to set it to NULL and do you own locking. |
| 482 | |
| 483 | If a lock is specified then all file operations will be serialized on that |
| 484 | lock. If you use videobuf then you must pass the same lock to the videobuf |
| 485 | queue initialize function: if videobuf has to wait for a frame to arrive, then |
| 486 | it will temporarily unlock the lock and relock it afterwards. If your driver |
| 487 | also waits in the code, then you should do the same to allow other processes |
| 488 | to access the device node while the first process is waiting for something. |
| 489 | |
| 490 | The implementation of a hotplug disconnect should also take the lock before |
Hans Verkuil | 9c84d89 | 2010-10-11 12:36:37 -0300 | [diff] [blame^] | 491 | calling v4l2_device_disconnect. |
Hans Verkuil | a47ddf1 | 2008-12-19 10:20:22 -0300 | [diff] [blame] | 492 | |
| 493 | video_device registration |
| 494 | ------------------------- |
| 495 | |
| 496 | Next you register the video device: this will create the character device |
| 497 | for you. |
| 498 | |
| 499 | err = video_register_device(vdev, VFL_TYPE_GRABBER, -1); |
| 500 | if (err) { |
Hans Verkuil | 50a2a8b | 2008-12-22 09:13:11 -0300 | [diff] [blame] | 501 | video_device_release(vdev); /* or kfree(my_vdev); */ |
Hans Verkuil | a47ddf1 | 2008-12-19 10:20:22 -0300 | [diff] [blame] | 502 | return err; |
| 503 | } |
| 504 | |
| 505 | Which device is registered depends on the type argument. The following |
| 506 | types exist: |
| 507 | |
| 508 | VFL_TYPE_GRABBER: videoX for video input/output devices |
| 509 | VFL_TYPE_VBI: vbiX for vertical blank data (i.e. closed captions, teletext) |
| 510 | VFL_TYPE_RADIO: radioX for radio tuners |
Hans Verkuil | a47ddf1 | 2008-12-19 10:20:22 -0300 | [diff] [blame] | 511 | |
| 512 | The last argument gives you a certain amount of control over the device |
Hans Verkuil | 6b5270d | 2009-09-06 07:54:00 -0300 | [diff] [blame] | 513 | device node number used (i.e. the X in videoX). Normally you will pass -1 |
| 514 | to let the v4l2 framework pick the first free number. But sometimes users |
| 515 | want to select a specific node number. It is common that drivers allow |
| 516 | the user to select a specific device node number through a driver module |
| 517 | option. That number is then passed to this function and video_register_device |
| 518 | will attempt to select that device node number. If that number was already |
| 519 | in use, then the next free device node number will be selected and it |
| 520 | will send a warning to the kernel log. |
Hans Verkuil | a47ddf1 | 2008-12-19 10:20:22 -0300 | [diff] [blame] | 521 | |
Hans Verkuil | 6b5270d | 2009-09-06 07:54:00 -0300 | [diff] [blame] | 522 | Another use-case is if a driver creates many devices. In that case it can |
| 523 | be useful to place different video devices in separate ranges. For example, |
| 524 | video capture devices start at 0, video output devices start at 16. |
Hans Verkuil | 22e2212 | 2009-09-06 07:13:14 -0300 | [diff] [blame] | 525 | So you can use the last argument to specify a minimum device node number |
| 526 | and the v4l2 framework will try to pick the first free number that is equal |
Hans Verkuil | a47ddf1 | 2008-12-19 10:20:22 -0300 | [diff] [blame] | 527 | or higher to what you passed. If that fails, then it will just pick the |
| 528 | first free number. |
| 529 | |
Hans Verkuil | 6b5270d | 2009-09-06 07:54:00 -0300 | [diff] [blame] | 530 | Since in this case you do not care about a warning about not being able |
| 531 | to select the specified device node number, you can call the function |
| 532 | video_register_device_no_warn() instead. |
| 533 | |
Hans Verkuil | a47ddf1 | 2008-12-19 10:20:22 -0300 | [diff] [blame] | 534 | Whenever a device node is created some attributes are also created for you. |
| 535 | If you look in /sys/class/video4linux you see the devices. Go into e.g. |
| 536 | video0 and you will see 'name' and 'index' attributes. The 'name' attribute |
Hans Verkuil | 7ae0cd9 | 2009-06-19 11:32:56 -0300 | [diff] [blame] | 537 | is the 'name' field of the video_device struct. |
Hans Verkuil | a47ddf1 | 2008-12-19 10:20:22 -0300 | [diff] [blame] | 538 | |
Hans Verkuil | 7ae0cd9 | 2009-06-19 11:32:56 -0300 | [diff] [blame] | 539 | The 'index' attribute is the index of the device node: for each call to |
| 540 | video_register_device() the index is just increased by 1. The first video |
| 541 | device node you register always starts with index 0. |
Hans Verkuil | a47ddf1 | 2008-12-19 10:20:22 -0300 | [diff] [blame] | 542 | |
| 543 | Users can setup udev rules that utilize the index attribute to make fancy |
| 544 | device names (e.g. 'mpegX' for MPEG video capture device nodes). |
| 545 | |
| 546 | After the device was successfully registered, then you can use these fields: |
| 547 | |
| 548 | - vfl_type: the device type passed to video_register_device. |
| 549 | - minor: the assigned device minor number. |
Hans Verkuil | 22e2212 | 2009-09-06 07:13:14 -0300 | [diff] [blame] | 550 | - num: the device node number (i.e. the X in videoX). |
Hans Verkuil | 7ae0cd9 | 2009-06-19 11:32:56 -0300 | [diff] [blame] | 551 | - index: the device index number. |
Hans Verkuil | a47ddf1 | 2008-12-19 10:20:22 -0300 | [diff] [blame] | 552 | |
| 553 | If the registration failed, then you need to call video_device_release() |
| 554 | to free the allocated video_device struct, or free your own struct if the |
| 555 | video_device was embedded in it. The vdev->release() callback will never |
| 556 | be called if the registration failed, nor should you ever attempt to |
| 557 | unregister the device if the registration failed. |
| 558 | |
| 559 | |
| 560 | video_device cleanup |
| 561 | -------------------- |
| 562 | |
| 563 | When the video device nodes have to be removed, either during the unload |
| 564 | of the driver or because the USB device was disconnected, then you should |
| 565 | unregister them: |
| 566 | |
| 567 | video_unregister_device(vdev); |
| 568 | |
| 569 | This will remove the device nodes from sysfs (causing udev to remove them |
| 570 | from /dev). |
| 571 | |
Hans Verkuil | dd1ad94 | 2010-04-06 11:44:39 -0300 | [diff] [blame] | 572 | After video_unregister_device() returns no new opens can be done. However, |
| 573 | in the case of USB devices some application might still have one of these |
Hans Verkuil | d69f271 | 2010-09-26 08:16:56 -0300 | [diff] [blame] | 574 | device nodes open. So after the unregister all file operations (except |
| 575 | release, of course) will return an error as well. |
Hans Verkuil | a47ddf1 | 2008-12-19 10:20:22 -0300 | [diff] [blame] | 576 | |
| 577 | When the last user of the video device node exits, then the vdev->release() |
| 578 | callback is called and you can do the final cleanup there. |
| 579 | |
| 580 | |
| 581 | video_device helper functions |
| 582 | ----------------------------- |
| 583 | |
| 584 | There are a few useful helper functions: |
| 585 | |
Laurent Pinchart | eac8ea5 | 2009-11-27 13:56:50 -0300 | [diff] [blame] | 586 | - file/video_device private data |
| 587 | |
Hans Verkuil | a47ddf1 | 2008-12-19 10:20:22 -0300 | [diff] [blame] | 588 | You can set/get driver private data in the video_device struct using: |
| 589 | |
Hans Verkuil | 89aec3e | 2009-02-07 07:07:04 -0300 | [diff] [blame] | 590 | void *video_get_drvdata(struct video_device *vdev); |
| 591 | void video_set_drvdata(struct video_device *vdev, void *data); |
Hans Verkuil | a47ddf1 | 2008-12-19 10:20:22 -0300 | [diff] [blame] | 592 | |
| 593 | Note that you can safely call video_set_drvdata() before calling |
| 594 | video_register_device(). |
| 595 | |
| 596 | And this function: |
| 597 | |
| 598 | struct video_device *video_devdata(struct file *file); |
| 599 | |
| 600 | returns the video_device belonging to the file struct. |
| 601 | |
Laurent Pinchart | eac8ea5 | 2009-11-27 13:56:50 -0300 | [diff] [blame] | 602 | The video_drvdata function combines video_get_drvdata with video_devdata: |
Hans Verkuil | a47ddf1 | 2008-12-19 10:20:22 -0300 | [diff] [blame] | 603 | |
| 604 | void *video_drvdata(struct file *file); |
| 605 | |
| 606 | You can go from a video_device struct to the v4l2_device struct using: |
| 607 | |
Hans Verkuil | dfa9a5a | 2008-12-23 12:17:23 -0300 | [diff] [blame] | 608 | struct v4l2_device *v4l2_dev = vdev->v4l2_dev; |
Mauro Carvalho Chehab | 44061c0 | 2009-02-14 07:29:07 -0300 | [diff] [blame] | 609 | |
Laurent Pinchart | eac8ea5 | 2009-11-27 13:56:50 -0300 | [diff] [blame] | 610 | - Device node name |
| 611 | |
| 612 | The video_device node kernel name can be retrieved using |
| 613 | |
| 614 | const char *video_device_node_name(struct video_device *vdev); |
| 615 | |
| 616 | The name is used as a hint by userspace tools such as udev. The function |
| 617 | should be used where possible instead of accessing the video_device::num and |
| 618 | video_device::minor fields. |
| 619 | |
| 620 | |
Mauro Carvalho Chehab | 44061c0 | 2009-02-14 07:29:07 -0300 | [diff] [blame] | 621 | video buffer helper functions |
| 622 | ----------------------------- |
| 623 | |
Jonathan Corbet | 4b586a3 | 2010-02-22 17:47:46 -0300 | [diff] [blame] | 624 | The v4l2 core API provides a set of standard methods (called "videobuf") |
| 625 | for dealing with video buffers. Those methods allow a driver to implement |
| 626 | read(), mmap() and overlay() in a consistent way. There are currently |
| 627 | methods for using video buffers on devices that supports DMA with |
| 628 | scatter/gather method (videobuf-dma-sg), DMA with linear access |
| 629 | (videobuf-dma-contig), and vmalloced buffers, mostly used on USB drivers |
| 630 | (videobuf-vmalloc). |
Mauro Carvalho Chehab | 44061c0 | 2009-02-14 07:29:07 -0300 | [diff] [blame] | 631 | |
Jonathan Corbet | 4b586a3 | 2010-02-22 17:47:46 -0300 | [diff] [blame] | 632 | Please see Documentation/video4linux/videobuf for more information on how |
| 633 | to use the videobuf layer. |
Sakari Ailus | 6cd84b7 | 2010-03-20 18:28:48 -0300 | [diff] [blame] | 634 | |
| 635 | struct v4l2_fh |
| 636 | -------------- |
| 637 | |
| 638 | struct v4l2_fh provides a way to easily keep file handle specific data |
| 639 | that is used by the V4L2 framework. Using v4l2_fh is optional for |
| 640 | drivers. |
| 641 | |
| 642 | The users of v4l2_fh (in the V4L2 framework, not the driver) know |
| 643 | whether a driver uses v4l2_fh as its file->private_data pointer by |
| 644 | testing the V4L2_FL_USES_V4L2_FH bit in video_device->flags. |
| 645 | |
| 646 | Useful functions: |
| 647 | |
| 648 | - v4l2_fh_init() |
| 649 | |
| 650 | Initialise the file handle. This *MUST* be performed in the driver's |
| 651 | v4l2_file_operations->open() handler. |
| 652 | |
| 653 | - v4l2_fh_add() |
| 654 | |
| 655 | Add a v4l2_fh to video_device file handle list. May be called after |
| 656 | initialising the file handle. |
| 657 | |
| 658 | - v4l2_fh_del() |
| 659 | |
| 660 | Unassociate the file handle from video_device(). The file handle |
| 661 | exit function may now be called. |
| 662 | |
| 663 | - v4l2_fh_exit() |
| 664 | |
| 665 | Uninitialise the file handle. After uninitialisation the v4l2_fh |
| 666 | memory can be freed. |
| 667 | |
| 668 | struct v4l2_fh is allocated as a part of the driver's own file handle |
| 669 | structure and is set to file->private_data in the driver's open |
| 670 | function by the driver. Drivers can extract their own file handle |
| 671 | structure by using the container_of macro. Example: |
| 672 | |
| 673 | struct my_fh { |
| 674 | int blah; |
| 675 | struct v4l2_fh fh; |
| 676 | }; |
| 677 | |
| 678 | ... |
| 679 | |
| 680 | int my_open(struct file *file) |
| 681 | { |
| 682 | struct my_fh *my_fh; |
| 683 | struct video_device *vfd; |
| 684 | int ret; |
| 685 | |
| 686 | ... |
| 687 | |
| 688 | ret = v4l2_fh_init(&my_fh->fh, vfd); |
| 689 | if (ret) |
| 690 | return ret; |
| 691 | |
| 692 | v4l2_fh_add(&my_fh->fh); |
| 693 | |
| 694 | file->private_data = &my_fh->fh; |
| 695 | |
| 696 | ... |
| 697 | } |
| 698 | |
| 699 | int my_release(struct file *file) |
| 700 | { |
| 701 | struct v4l2_fh *fh = file->private_data; |
| 702 | struct my_fh *my_fh = container_of(fh, struct my_fh, fh); |
| 703 | |
| 704 | ... |
| 705 | } |
Sakari Ailus | dd96608 | 2010-03-27 10:58:24 -0300 | [diff] [blame] | 706 | |
| 707 | V4L2 events |
| 708 | ----------- |
| 709 | |
| 710 | The V4L2 events provide a generic way to pass events to user space. |
| 711 | The driver must use v4l2_fh to be able to support V4L2 events. |
| 712 | |
| 713 | Useful functions: |
| 714 | |
| 715 | - v4l2_event_alloc() |
| 716 | |
| 717 | To use events, the driver must allocate events for the file handle. By |
| 718 | calling the function more than once, the driver may assure that at least n |
| 719 | events in total have been allocated. The function may not be called in |
| 720 | atomic context. |
| 721 | |
| 722 | - v4l2_event_queue() |
| 723 | |
| 724 | Queue events to video device. The driver's only responsibility is to fill |
| 725 | in the type and the data fields. The other fields will be filled in by |
| 726 | V4L2. |
| 727 | |
| 728 | - v4l2_event_subscribe() |
| 729 | |
| 730 | The video_device->ioctl_ops->vidioc_subscribe_event must check the driver |
| 731 | is able to produce events with specified event id. Then it calls |
| 732 | v4l2_event_subscribe() to subscribe the event. |
| 733 | |
| 734 | - v4l2_event_unsubscribe() |
| 735 | |
| 736 | vidioc_unsubscribe_event in struct v4l2_ioctl_ops. A driver may use |
| 737 | v4l2_event_unsubscribe() directly unless it wants to be involved in |
| 738 | unsubscription process. |
| 739 | |
| 740 | The special type V4L2_EVENT_ALL may be used to unsubscribe all events. The |
| 741 | drivers may want to handle this in a special way. |
| 742 | |
| 743 | - v4l2_event_pending() |
| 744 | |
| 745 | Returns the number of pending events. Useful when implementing poll. |
| 746 | |
| 747 | Drivers do not initialise events directly. The events are initialised |
| 748 | through v4l2_fh_init() if video_device->ioctl_ops->vidioc_subscribe_event is |
| 749 | non-NULL. This *MUST* be performed in the driver's |
| 750 | v4l2_file_operations->open() handler. |
| 751 | |
| 752 | Events are delivered to user space through the poll system call. The driver |
| 753 | can use v4l2_fh->events->wait wait_queue_head_t as the argument for |
| 754 | poll_wait(). |
| 755 | |
| 756 | There are standard and private events. New standard events must use the |
| 757 | smallest available event type. The drivers must allocate their events from |
| 758 | their own class starting from class base. Class base is |
| 759 | V4L2_EVENT_PRIVATE_START + n * 1000 where n is the lowest available number. |
| 760 | The first event type in the class is reserved for future use, so the first |
| 761 | available event type is 'class base + 1'. |
| 762 | |
| 763 | An example on how the V4L2 events may be used can be found in the OMAP |
| 764 | 3 ISP driver available at <URL:http://gitorious.org/omap3camera> as of |
| 765 | writing this. |