Lines Matching refs:to
11 The V4L2 drivers tend to be very complex due to the complexity of the
16 Especially the fact that V4L2 drivers have to setup supporting ICs to
18 Usually these ICs are connected to the main bridge driver through one or
22 For a long time the framework was limited to the video_device struct for
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.
30 There is also a lot of common code that could never be refactored due to
34 need and this same framework should make it much easier to refactor
37 A good example to look at as a reference is the v4l2-pci-skeleton.c
39 a PCI capture card, and demonstrates how to use the V4L2 driver
73 struct for the device instance data, a v4l2_subdev struct to refer to
94 field is NULL, it will be linked to v4l2_dev.
96 Drivers that want integration with the media device framework need to set
97 dev->driver_data manually to point to the driver-specific device structure
100 also set the struct v4l2_device mdev field to point to a properly initialized
103 If v4l2_dev->name is empty then it will be set to a value derived from dev
104 (driver name followed by the bus_id, to be precise). If you set it up before
108 You can use v4l2_device_set_name() to set the name based on a driver name and
114 usb_interface or platform_device. It is rare for dev to be NULL, but it happens
116 it impossible to associate v4l2_dev with a particular parent.
118 You can also supply a notify() callback that can be called by sub-devices to
119 notify you of events. Whether you need to set this depends on the sub-device.
127 If the dev->driver_data field points to v4l2_dev, it will be reset to NULL.
131 happens the parent device becomes invalid. Since v4l2_device has a pointer to
132 that parent device it has to be cleared as well to mark that the parent is
137 This does *not* unregister the subdevs, so you still need to call the
139 then there is no need to call v4l2_device_disconnect().
141 Sometimes you need to iterate over all devices registered by a specific
173 Sometimes you need to keep a running counter of the device instance. This is
174 commonly used to map a device instance to an index of a module option array.
186 If you have multiple device nodes then it can be difficult to know when it is
187 safe to unregister v4l2_device for hotpluggable devices. For this purpose
202 Since the initial refcount is 1 you also need to call v4l2_device_put in the
209 Many drivers need to communicate with sub-devices. These devices can do all
214 Usually these are I2C devices, but not necessarily. In order to provide the
215 driver with a consistent interface to these sub-devices the v4l2_subdev struct
220 if more state information needs to be stored. Usually there is a low-level
222 by the kernel. It is recommended to store that pointer in the private
223 data of v4l2_subdev using v4l2_set_subdevdata(). That makes it easy to go
224 from a v4l2_subdev to the actual low-level bus-specific device data.
226 You also need a way to go from the low-level struct to v4l2_subdev. For the
227 common i2c_client struct the i2c_set_clientdata() call is used to store a
228 v4l2_subdev pointer, for other busses you may have to use other methods.
230 Bridges might also need to store per-subdev private data, such as a pointer to
237 i2c_get_clientdata(). For other busses something similar needs to be done.
243 so many different things and you do not want to end up with a huge ops struct
245 are sorted according to category and each category has its own ops struct.
247 The top-level ops struct contains pointers to the category ops structs, which
282 The core ops are common to all subdevs, the other categories are implemented
283 depending on the sub-device. E.g. a video device is unlikely to support the
287 to add new ops and categories.
293 Afterwards you need to initialize subdev->name with a unique name and set the
305 The pads array must have been previously initialized. There is no need to
309 A reference to the entity will be automatically acquired/released when the
312 Don't forget to cleanup the media entity before the sub-device is destroyed:
316 If the subdev driver intends to process video and integrate with the media
320 In that case, the subdev driver may set the link_validate field to provide
329 sink of the link. Subdev drivers are also free to use this function to
330 perform the checks mentioned above in addition to their own checks.
332 There are currently two ways to register subdevices with the V4L2 core. The
333 first (traditional) possibility is to have subdevices registered by bridge
335 about subdevices connected to it and knows exactly when to register them. This
338 to SoCs, which pass information about them to bridge drivers, usually in their
341 There are however also situations where subdevices have to be registered
342 asynchronously to bridge devices. An example of such a configuration is a Device
343 Tree based system where information about subdevices is made available to the
351 In the synchronous case a device (bridge) driver needs to register the
357 After this function was called successfully the subdev->dev field points to
373 but it is better and easier to use this macro:
377 The macro will to the right NULL pointer checks and returns -ENODEV if subdev
381 It is also possible to call all or a subset of the sub-devices:
386 ignored. If you want to check for errors use this:
393 The second argument to both calls is a group ID. If 0, then all subdevs are
396 to whatever value it wants (it's 0 by default). This value is owned by the
402 user want to change the volume. You can set the group ID for that subdev to
404 v4l2_device_call_all(). That ensures that it will only go to the subdev
407 If the sub-device needs to notify its v4l2_device parent of an event, then
420 bridge driver availability. The subdevice driver then has to verify whether all
423 the driver might decide to return -EPROBE_DEFER to request further reprobing
427 stored in a global list of subdevices, ready to be picked up by bridge drivers.
429 Bridge drivers in turn have to register a notifier object with an array of
432 notifier the driver has to call v4l2_async_notifier_unregister(). The former of
433 the two functions takes two arguments: a pointer to struct v4l2_device and a
434 pointer to struct v4l2_async_notifier. The latter contains a pointer to an array
435 of pointers to subdevice descriptors of type struct v4l2_async_subdev type. The
436 V4L2 core will then use these descriptors to match asynchronously registered
437 subdevices to them. If a match is detected the .bound() notifier callback is
449 Device nodes named v4l-subdevX can be created in /dev to access sub-devices
468 The controls ioctls are identical to the ones defined in V4L2. They
478 The events ioctls are identical to the ones defined in V4L2. They
483 Sub-device drivers that want to use events need to set the
485 v4l2_subdev::nevents to events queue depth before registering the
494 All ioctls not in the above list are passed directly to the sub-device
501 Since these drivers are so common, special helper functions are available to
504 The recommended method of adding v4l2_subdev support to an I2C driver is to
522 v4l2_subdev and i2c_client both point to one another.
524 You should also add a helper inline function to go from a v4l2_subdev pointer
525 to a chipname_state struct:
532 Use this to go from the v4l2_subdev struct to the i2c_client struct:
536 And this to go from an i2c_client to a v4l2_subdev struct:
540 Make sure to call v4l2_device_unregister_subdev(sd) when the remove() callback
542 safe to call this even if the sub-device was never registered.
544 You need to do this because when the bridge driver destroys the i2c adapter
547 have to be unregistered first. Calling v4l2_device_unregister_subdev(sd)
556 This loads the given module (can be NULL if no module needs to be loaded) and
560 You can also use the last argument of v4l2_i2c_new_subdev() to pass an array
567 Note that the chipid you pass to v4l2_i2c_new_subdev() is usually
568 the same as the module name. It allows you to specify a chip variant, e.g.
570 The use of chipid is something that needs to be looked at more closely at a
588 to the i2c driver and replaces the irq, platform_data and addr arguments.
593 irq set to 0 and platform_data set to NULL.
612 callback to your own function:
621 The default video_device_release() callback just calls kfree to free the
626 to do when it is released.
630 - v4l2_dev: must be set to the v4l2_device parent device.
632 - name: set to something descriptive and unique.
634 - vfl_dir: set this to VFL_DIR_RX for capture devices (VFL_DIR_RX has value 0,
635 so this is normally already the default), set to VFL_DIR_TX for output
638 - fops: set to the v4l2_file_operations struct.
640 - ioctl_ops: if you use the v4l2_ioctl_ops to simplify ioctl maintenance
641 (highly recommended to use this and it might become compulsory in the
642 future!), then set this to your v4l2_ioctl_ops struct. The vfl_type and
643 vfl_dir fields are used to disable ops that do not match the type/dir
645 are disabled for a capture device. This makes it possible to provide
648 - lock: leave to NULL if you want to do all the locking in the driver.
649 Otherwise you give it a pointer to a struct mutex_lock and before the
653 - queue: a pointer to the struct vb2_queue associated with this device node.
657 That way the vb2 queuing framework does not have to wait for other ioctls.
658 This queue pointer is also used by the vb2 helper functions to check for
659 queuing ownership (i.e. is the filehandle calling it allowed to do the
662 - prio: keeps track of the priorities. Used to implement VIDIOC_G/S_PRIORITY.
663 If left to NULL, then it will use the struct v4l2_prio_state in v4l2_device.
664 If you want to have a separate priority state per (group of) device node(s),
665 then you can point it to your own struct v4l2_prio_state.
675 video_device is initialized you *do* know which parent PCI device to use and
676 so you set dev_device to the correct PCI device.
678 If you use v4l2_ioctl_ops, then you should set .unlocked_ioctl to video_ioctl2
683 In some cases you want to tell the core that a function you had specified in
689 This tends to be needed if based on external factors (e.g. which card is
690 being used) you want to turns off certain features in v4l2_ioctl_ops without
691 having to make a new struct.
705 The pads array must have been previously initialized. There is no need to
708 A reference to the entity will be automatically acquired/released when the
715 lock field in struct video_device, which is a pointer to a mutex. If you set
716 this pointer, then that will be used by unlocked_ioctl to serialize all ioctls.
720 of video_device->lock to serialize all queuing ioctls (see the previous section
725 can take a long time, so you want to use a separate lock for the buffer queuing
732 If you use the old videobuf then you must pass the video_device lock to the
733 videobuf queue initialize function: if videobuf has to wait for a frame to
735 your driver also waits in the code, then you should do the same to allow other
736 processes to access the device node while the first process is waiting for
739 In the case of videobuf2 you will need to implement the wait_prepare and
740 wait_finish callbacks to unlock/lock if applicable. If you use the queue->lock
745 video_device->queue->lock, then you have to first lock video_device->queue->lock
774 to let the v4l2 framework pick the first free number. But sometimes users
775 want to select a specific node number. It is common that drivers allow
776 the user to select a specific device node number through a driver module
777 option. That number is then passed to this function and video_register_device
778 will attempt to select that device node number. If that number was already
780 will send a warning to the kernel log.
783 be useful to place different video devices in separate ranges. For example,
785 So you can use the last argument to specify a minimum device node number
786 and the v4l2 framework will try to pick the first free number that is equal
787 or higher to what you passed. If that fails, then it will just pick the
791 to select the specified device node number, you can call the function
798 can be used to enable core debugging. See the next section for more detailed
801 The 'index' attribute is the index of the device node: for each call to
805 Users can setup udev rules that utilize the index attribute to make fancy
810 - vfl_type: the device type passed to video_register_device.
815 If the registration failed, then you need to call video_device_release()
816 to free the allocated video_device struct, or free your own struct if the
818 be called if the registration failed, nor should you ever attempt to
825 device in /sys/class/video4linux/<devX>/ allows you to enable logging of
844 When the video device nodes have to be removed, either during the unload
850 This will remove the device nodes from sysfs (causing udev to remove them
861 Don't forget to cleanup the media entity associated with the video device if
888 returns the video_device belonging to the file struct.
894 You can go from a video_device struct to the v4l2_device struct using:
913 for dealing with video buffers. Those methods allow a driver to implement
921 to use the videobuf layer.
926 struct v4l2_fh provides a way to easily keep file handle specific data
928 since it is also used to implement priority handling (VIDIOC_G/S_PRIORITY).
936 structure and file->private_data is set to it in the driver's open
995 Add a v4l2_fh to video_device file handle list. Must be called once the
1013 This allocates a struct v4l2_fh, initializes it and adds it to the struct
1025 Several drivers need to do something when the first file handle is opened and
1026 when the last file handle closes. Two helper functions were added to check
1042 The V4L2 events provide a generic way to pass events to user space.
1043 The driver must use v4l2_fh to be able to support V4L2 events.
1045 Events are defined by a type and an optional ID. The ID may refer to a V4L2
1048 When the user subscribes to an event the driver will allocate a number of
1060 allows you to replace the payload of the old event with that of the new event,
1063 allocated. The merge() callback allows you to merge the oldest event payload
1068 up to that state.
1080 Queue events to video device. The driver's only responsibility is to fill
1089 is able to produce events with specified event id. Then it calls
1090 v4l2_event_subscribe() to subscribe the event.
1096 The ops argument allows the driver to specify a number of callbacks:
1097 * add: called when a new listener gets added (subscribing to the same
1098 event twice will only cause this callback to get called once)
1102 All 4 callbacks are optional, if you don't want to specify any callbacks
1109 v4l2_event_unsubscribe() directly unless it wants to be involved in
1112 The special type V4L2_EVENT_ALL may be used to unsubscribe all events. The
1113 drivers may want to handle this in a special way.
1119 Events are delivered to user space through the poll system call. The driver
1132 A subdev can directly send an event to the v4l2_device notify function with
1133 V4L2_DEVICE_NOTIFY_EVENT. This allows the bridge to map the subdev that sends
1134 the event to the video node(s) associated with the subdev that need to be
1141 signal to be supplied by the system. Often this clock is supplied by the
1145 connection of subdevices to the system might impose special requirements on the
1146 clock API usage. E.g. V4L2 has to support clock provider driver unregistration
1147 while a subdevice driver is holding a reference to the clock. For these reasons
1148 a V4L2 clock helper API has been developed and is provided to bridge and
1151 The API consists of two parts: two functions to register and unregister a V4L2
1152 clock source: v4l2_clk_register() and v4l2_clk_unregister() and calls to control
1153 a clock object, similar to the respective generic clock API calls:
1155 v4l2_clk_get_rate(), and v4l2_clk_set_rate(). Clock suppliers have to provide