diff options
Diffstat (limited to 'include/media')
| -rw-r--r-- | include/media/lirc_dev.h | 2 | ||||
| -rw-r--r-- | include/media/media-device.h | 255 | ||||
| -rw-r--r-- | include/media/media-entity.h | 83 | ||||
| -rw-r--r-- | include/media/rc-core.h | 45 | ||||
| -rw-r--r-- | include/media/rc-map.h | 17 | ||||
| -rw-r--r-- | include/media/tuner-types.h | 8 | ||||
| -rw-r--r-- | include/media/tveeprom.h | 18 | ||||
| -rw-r--r-- | include/media/v4l2-mc.h | 13 | ||||
| -rw-r--r-- | include/media/v4l2-subdev.h | 4 | ||||
| -rw-r--r-- | include/media/videobuf2-core.h | 28 |
10 files changed, 166 insertions, 307 deletions
diff --git a/include/media/lirc_dev.h b/include/media/lirc_dev.h index 0ab59a5..cec7d35 100644 --- a/include/media/lirc_dev.h +++ b/include/media/lirc_dev.h @@ -140,7 +140,7 @@ static inline unsigned int lirc_buffer_write(struct lirc_buffer *buf, * second. * * @features: lirc compatible hardware features, like LIRC_MODE_RAW, - * LIRC_CAN_*, as defined at include/media/lirc.h. + * LIRC_CAN\_\*, as defined at include/media/lirc.h. * * @chunk_size: Size of each FIFO buffer. * diff --git a/include/media/media-device.h b/include/media/media-device.h index f743ae2..2819524 100644 --- a/include/media/media-device.h +++ b/include/media/media-device.h @@ -29,237 +29,6 @@ #include <media/media-devnode.h> #include <media/media-entity.h> -/** - * DOC: Media Controller - * - * The media controller userspace API is documented in DocBook format in - * Documentation/DocBook/media/v4l/media-controller.xml. This document focus - * on the kernel-side implementation of the media framework. - * - * * Abstract media device model: - * - * Discovering a device internal topology, and configuring it at runtime, is one - * of the goals of the media framework. To achieve this, hardware devices are - * modelled as an oriented graph of building blocks called entities connected - * through pads. - * - * An entity is a basic media hardware building block. It can correspond to - * a large variety of logical blocks such as physical hardware devices - * (CMOS sensor for instance), logical hardware devices (a building block - * in a System-on-Chip image processing pipeline), DMA channels or physical - * connectors. - * - * A pad is a connection endpoint through which an entity can interact with - * other entities. Data (not restricted to video) produced by an entity - * flows from the entity's output to one or more entity inputs. Pads should - * not be confused with physical pins at chip boundaries. - * - * A link is a point-to-point oriented connection between two pads, either - * on the same entity or on different entities. Data flows from a source - * pad to a sink pad. - * - * - * * Media device: - * - * A media device is represented by a struct &media_device instance, defined in - * include/media/media-device.h. Allocation of the structure is handled by the - * media device driver, usually by embedding the &media_device instance in a - * larger driver-specific structure. - * - * Drivers register media device instances by calling - * __media_device_register() via the macro media_device_register() - * and unregistered by calling - * media_device_unregister(). - * - * * Entities, pads and links: - * - * - Entities - * - * Entities are represented by a struct &media_entity instance, defined in - * include/media/media-entity.h. The structure is usually embedded into a - * higher-level structure, such as a v4l2_subdev or video_device instance, - * although drivers can allocate entities directly. - * - * Drivers initialize entity pads by calling - * media_entity_pads_init(). - * - * Drivers register entities with a media device by calling - * media_device_register_entity() - * and unregistred by calling - * media_device_unregister_entity(). - * - * - Interfaces - * - * Interfaces are represented by a struct &media_interface instance, defined in - * include/media/media-entity.h. Currently, only one type of interface is - * defined: a device node. Such interfaces are represented by a struct - * &media_intf_devnode. - * - * Drivers initialize and create device node interfaces by calling - * media_devnode_create() - * and remove them by calling: - * media_devnode_remove(). - * - * - Pads - * - * Pads are represented by a struct &media_pad instance, defined in - * include/media/media-entity.h. Each entity stores its pads in a pads array - * managed by the entity driver. Drivers usually embed the array in a - * driver-specific structure. - * - * Pads are identified by their entity and their 0-based index in the pads - * array. - * Both information are stored in the &media_pad structure, making the - * &media_pad pointer the canonical way to store and pass link references. - * - * Pads have flags that describe the pad capabilities and state. - * - * %MEDIA_PAD_FL_SINK indicates that the pad supports sinking data. - * %MEDIA_PAD_FL_SOURCE indicates that the pad supports sourcing data. - * - * NOTE: One and only one of %MEDIA_PAD_FL_SINK and %MEDIA_PAD_FL_SOURCE must - * be set for each pad. - * - * - Links - * - * Links are represented by a struct &media_link instance, defined in - * include/media/media-entity.h. There are two types of links: - * - * 1. pad to pad links: - * - * Associate two entities via their PADs. Each entity has a list that points - * to all links originating at or targeting any of its pads. - * A given link is thus stored twice, once in the source entity and once in - * the target entity. - * - * Drivers create pad to pad links by calling: - * media_create_pad_link() and remove with media_entity_remove_links(). - * - * 2. interface to entity links: - * - * Associate one interface to a Link. - * - * Drivers create interface to entity links by calling: - * media_create_intf_link() and remove with media_remove_intf_links(). - * - * NOTE: - * - * Links can only be created after having both ends already created. - * - * Links have flags that describe the link capabilities and state. The - * valid values are described at media_create_pad_link() and - * media_create_intf_link(). - * - * Graph traversal: - * - * The media framework provides APIs to iterate over entities in a graph. - * - * To iterate over all entities belonging to a media device, drivers can use - * the media_device_for_each_entity macro, defined in - * include/media/media-device.h. - * - * struct media_entity *entity; - * - * media_device_for_each_entity(entity, mdev) { - * // entity will point to each entity in turn - * ... - * } - * - * Drivers might also need to iterate over all entities in a graph that can be - * reached only through enabled links starting at a given entity. The media - * framework provides a depth-first graph traversal API for that purpose. - * - * Note that graphs with cycles (whether directed or undirected) are *NOT* - * supported by the graph traversal API. To prevent infinite loops, the graph - * traversal code limits the maximum depth to MEDIA_ENTITY_ENUM_MAX_DEPTH, - * currently defined as 16. - * - * Drivers initiate a graph traversal by calling - * media_entity_graph_walk_start() - * - * The graph structure, provided by the caller, is initialized to start graph - * traversal at the given entity. - * - * Drivers can then retrieve the next entity by calling - * media_entity_graph_walk_next() - * - * When the graph traversal is complete the function will return NULL. - * - * Graph traversal can be interrupted at any moment. No cleanup function call - * is required and the graph structure can be freed normally. - * - * Helper functions can be used to find a link between two given pads, or a pad - * connected to another pad through an enabled link - * media_entity_find_link() and media_entity_remote_pad() - * - * Use count and power handling: - * - * Due to the wide differences between drivers regarding power management - * needs, the media controller does not implement power management. However, - * the &media_entity structure includes a use_count field that media drivers - * can use to track the number of users of every entity for power management - * needs. - * - * The &media_entity.@use_count field is owned by media drivers and must not be - * touched by entity drivers. Access to the field must be protected by the - * &media_device.@graph_mutex lock. - * - * Links setup: - * - * Link properties can be modified at runtime by calling - * media_entity_setup_link() - * - * Pipelines and media streams: - * - * When starting streaming, drivers must notify all entities in the pipeline to - * prevent link states from being modified during streaming by calling - * media_entity_pipeline_start(). - * - * The function will mark all entities connected to the given entity through - * enabled links, either directly or indirectly, as streaming. - * - * The &media_pipeline instance pointed to by the pipe argument will be stored - * in every entity in the pipeline. Drivers should embed the &media_pipeline - * structure in higher-level pipeline structures and can then access the - * pipeline through the &media_entity pipe field. - * - * Calls to media_entity_pipeline_start() can be nested. The pipeline pointer - * must be identical for all nested calls to the function. - * - * media_entity_pipeline_start() may return an error. In that case, it will - * clean up any of the changes it did by itself. - * - * When stopping the stream, drivers must notify the entities with - * media_entity_pipeline_stop(). - * - * If multiple calls to media_entity_pipeline_start() have been made the same - * number of media_entity_pipeline_stop() calls are required to stop streaming. - * The &media_entity pipe field is reset to NULL on the last nested stop call. - * - * Link configuration will fail with -%EBUSY by default if either end of the - * link is a streaming entity. Links that can be modified while streaming must - * be marked with the %MEDIA_LNK_FL_DYNAMIC flag. - * - * If other operations need to be disallowed on streaming entities (such as - * changing entities configuration parameters) drivers can explicitly check the - * media_entity stream_count field to find out if an entity is streaming. This - * operation must be done with the media_device graph_mutex held. - * - * Link validation: - * - * Link validation is performed by media_entity_pipeline_start() for any - * entity which has sink pads in the pipeline. The - * &media_entity.@link_validate() callback is used for that purpose. In - * @link_validate() callback, entity driver should check that the properties of - * the source pad of the connected entity and its own sink pad match. It is up - * to the type of the entity (and in the end, the properties of the hardware) - * what matching actually means. - * - * Subsystems should facilitate link validation by providing subsystem specific - * helper functions to provide easy access for commonly needed information, and - * in the end provide a way to use driver-specific callbacks. - */ - struct ida; struct device; @@ -473,13 +242,11 @@ void media_device_cleanup(struct media_device *mdev); * without breaking binary compatibility. The version major must be * incremented when binary compatibility is broken. * - * Notes: + * .. note:: * - * Upon successful registration a character device named media[0-9]+ is created. - * The device major and minor numbers are dynamic. The model name is exported as - * a sysfs attribute. + * #) Upon successful registration a character device named media[0-9]+ is created. The device major and minor numbers are dynamic. The model name is exported as a sysfs attribute. * - * Unregistering a media device that hasn't been registered is *NOT* safe. + * #) Unregistering a media device that hasn't been registered is **NOT** safe. * * Return: returns zero on success or a negative error code. */ @@ -527,14 +294,16 @@ void media_device_unregister(struct media_device *mdev); * This can be used to report the default audio and video devices or the * default camera sensor. * - * NOTE: Drivers should set the entity function before calling this function. - * Please notice that the values %MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN and - * %MEDIA_ENT_F_UNKNOWN should not be used by the drivers. + * .. note:: + * + * Drivers should set the entity function before calling this function. + * Please notice that the values %MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN and + * %MEDIA_ENT_F_UNKNOWN should not be used by the drivers. */ int __must_check media_device_register_entity(struct media_device *mdev, struct media_entity *entity); -/* +/** * media_device_unregister_entity() - unregisters a media entity. * * @entity: pointer to struct &media_entity to be unregistered @@ -548,8 +317,10 @@ int __must_check media_device_register_entity(struct media_device *mdev, * When a media device is unregistered, all its entities are unregistered * automatically. No manual entities unregistration is then required. * - * Note: the media_entity instance itself must be freed explicitly by - * the driver if required. + * .. note:: + * + * The media_entity instance itself must be freed explicitly by + * the driver if required. */ void media_device_unregister_entity(struct media_entity *entity); diff --git a/include/media/media-entity.h b/include/media/media-entity.h index cbb266f..8387771 100644 --- a/include/media/media-entity.h +++ b/include/media/media-entity.h @@ -104,7 +104,7 @@ struct media_entity_graph { int top; }; -/* +/** * struct media_pipeline - Media pipeline related information * * @streaming_count: Streaming start count - streaming stop count @@ -180,7 +180,7 @@ struct media_pad { * view. The media_entity_pipeline_start() function * validates all links by calling this operation. Optional. * - * Note: Those these callbacks are called with struct media_device.@graph_mutex + * .. note:: Those these callbacks are called with struct media_device.@graph_mutex * mutex held. */ struct media_entity_operations { @@ -602,19 +602,20 @@ static inline void media_entity_cleanup(struct media_entity *entity) {}; * @flags: Link flags, as defined in include/uapi/linux/media.h. * * Valid values for flags: - * A %MEDIA_LNK_FL_ENABLED flag indicates that the link is enabled and can be - * used to transfer media data. When two or more links target a sink pad, - * only one of them can be enabled at a time. * - * A %MEDIA_LNK_FL_IMMUTABLE flag indicates that the link enabled state can't - * be modified at runtime. If %MEDIA_LNK_FL_IMMUTABLE is set, then - * %MEDIA_LNK_FL_ENABLED must also be set since an immutable link is - * always enabled. + * - A %MEDIA_LNK_FL_ENABLED flag indicates that the link is enabled and can + * be used to transfer media data. When two or more links target a sink pad, + * only one of them can be enabled at a time. + * + * - A %MEDIA_LNK_FL_IMMUTABLE flag indicates that the link enabled state can't + * be modified at runtime. If %MEDIA_LNK_FL_IMMUTABLE is set, then + * %MEDIA_LNK_FL_ENABLED must also be set since an immutable link is + * always enabled. * - * NOTE: + * .. note:: * - * Before calling this function, media_entity_pads_init() and - * media_device_register_entity() should be called previously for both ends. + * Before calling this function, media_entity_pads_init() and + * media_device_register_entity() should be called previously for both ends. */ __must_check int media_create_pad_link(struct media_entity *source, u16 source_pad, struct media_entity *sink, @@ -641,6 +642,7 @@ __must_check int media_create_pad_link(struct media_entity *source, * and @sink are NULL. * * Valid values for flags: + * * A %MEDIA_LNK_FL_ENABLED flag indicates that the link is enabled and can be * used to transfer media data. If multiple links are created and this * flag is passed as an argument, only the first created link will have @@ -677,8 +679,10 @@ void __media_entity_remove_links(struct media_entity *entity); * * @entity: pointer to &media_entity * - * Note: this is called automatically when an entity is unregistered via - * media_device_register_entity(). + * .. note:: + * + * This is called automatically when an entity is unregistered via + * media_device_register_entity(). */ void media_entity_remove_links(struct media_entity *entity); @@ -728,9 +732,11 @@ int __media_entity_setup_link(struct media_link *link, u32 flags); * being enabled, the link_setup operation must return -EBUSY and can't * implicitly disable the first enabled link. * - * NOTE: the valid values of the flags for the link is the same as described - * on media_create_pad_link(), for pad to pad links or the same as described - * on media_create_intf_link(), for interface to entity links. + * .. note:: + * + * The valid values of the flags for the link is the same as described + * on media_create_pad_link(), for pad to pad links or the same as described + * on media_create_intf_link(), for interface to entity links. */ int media_entity_setup_link(struct media_link *link, u32 flags); @@ -844,7 +850,7 @@ __must_check int media_entity_pipeline_start(struct media_entity *entity, * @entity: Starting entity * @pipe: Media pipeline to be assigned to all entities in the pipeline. * - * Note: This is the non-locking version of media_entity_pipeline_start() + * ..note:: This is the non-locking version of media_entity_pipeline_start() */ __must_check int __media_entity_pipeline_start(struct media_entity *entity, struct media_pipeline *pipe); @@ -868,7 +874,7 @@ void media_entity_pipeline_stop(struct media_entity *entity); * * @entity: Starting entity * - * Note: This is the non-locking version of media_entity_pipeline_stop() + * .. note:: This is the non-locking version of media_entity_pipeline_stop() */ void __media_entity_pipeline_stop(struct media_entity *entity); @@ -909,20 +915,21 @@ struct media_link * * * * Valid values for flags: - * The %MEDIA_LNK_FL_ENABLED flag indicates that the interface is connected to - * the entity hardware. That's the default value for interfaces. An - * interface may be disabled if the hardware is busy due to the usage - * of some other interface that it is currently controlling the hardware. - * A typical example is an hybrid TV device that handle only one type of - * stream on a given time. So, when the digital TV is streaming, - * the V4L2 interfaces won't be enabled, as such device is not able to - * also stream analog TV or radio. * - * Note: + * - The %MEDIA_LNK_FL_ENABLED flag indicates that the interface is connected to + * the entity hardware. That's the default value for interfaces. An + * interface may be disabled if the hardware is busy due to the usage + * of some other interface that it is currently controlling the hardware. + * A typical example is an hybrid TV device that handle only one type of + * stream on a given time. So, when the digital TV is streaming, + * the V4L2 interfaces won't be enabled, as such device is not able to + * also stream analog TV or radio. + * + * .. note:: * - * Before calling this function, media_devnode_create() should be called for - * the interface and media_device_register_entity() should be called for the - * interface that will be part of the link. + * Before calling this function, media_devnode_create() should be called for + * the interface and media_device_register_entity() should be called for the + * interface that will be part of the link. */ __must_check media_create_intf_link(struct media_entity *entity, struct media_interface *intf, @@ -932,7 +939,7 @@ __must_check media_create_intf_link(struct media_entity *entity, * * @link: pointer to &media_link. * - * Note: this is an unlocked version of media_remove_intf_link() + * .. note:: This is an unlocked version of media_remove_intf_link() */ void __media_remove_intf_link(struct media_link *link); @@ -941,7 +948,7 @@ void __media_remove_intf_link(struct media_link *link); * * @link: pointer to &media_link. * - * Note: prefer to use this one, instead of __media_remove_intf_link() + * .. note:: Prefer to use this one, instead of __media_remove_intf_link() */ void media_remove_intf_link(struct media_link *link); @@ -950,7 +957,7 @@ void media_remove_intf_link(struct media_link *link); * * @intf: pointer to &media_interface * - * Note: this is an unlocked version of media_remove_intf_links(). + * .. note:: This is an unlocked version of media_remove_intf_links(). */ void __media_remove_intf_links(struct media_interface *intf); @@ -959,12 +966,12 @@ void __media_remove_intf_links(struct media_interface *intf); * * @intf: pointer to &media_interface * - * Notes: + * ..note:: * - * this is called automatically when an entity is unregistered via - * media_device_register_entity() and by media_devnode_remove(). + * - This is called automatically when an entity is unregistered via + * media_device_register_entity() and by media_devnode_remove(). * - * Prefer to use this one, instead of __media_remove_intf_links(). + * - Prefer to use this one, instead of __media_remove_intf_links(). */ void media_remove_intf_links(struct media_interface *intf); diff --git a/include/media/rc-core.h b/include/media/rc-core.h index 324232c..10908e3 100644 --- a/include/media/rc-core.h +++ b/include/media/rc-core.h @@ -29,9 +29,16 @@ do { \ printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__); \ } while (0) +/** + * enum rc_driver_type - type of the RC output + * + * @RC_DRIVER_SCANCODE: Driver or hardware generates a scancode + * @RC_DRIVER_IR_RAW: Driver or hardware generates pulse/space sequences. + * It needs a Infra-Red pulse/space decoder + */ enum rc_driver_type { - RC_DRIVER_SCANCODE = 0, /* Driver or hardware generates a scancode */ - RC_DRIVER_IR_RAW, /* Needs a Infra-Red pulse/space decoder */ + RC_DRIVER_SCANCODE = 0, + RC_DRIVER_IR_RAW, }; /** @@ -188,12 +195,46 @@ struct rc_dev { * Remote Controller, at sys/class/rc. */ +/** + * rc_allocate_device - Allocates a RC device + * + * returns a pointer to struct rc_dev. + */ struct rc_dev *rc_allocate_device(void); + +/** + * rc_free_device - Frees a RC device + * + * @dev: pointer to struct rc_dev. + */ void rc_free_device(struct rc_dev *dev); + +/** + * rc_register_device - Registers a RC device + * + * @dev: pointer to struct rc_dev. + */ int rc_register_device(struct rc_dev *dev); + +/** + * rc_unregister_device - Unregisters a RC device + * + * @dev: pointer to struct rc_dev. + */ void rc_unregister_device(struct rc_dev *dev); +/** + * rc_open - Opens a RC device + * + * @rdev: pointer to struct rc_dev. + */ int rc_open(struct rc_dev *rdev); + +/** + * rc_open - Closes a RC device + * + * @rdev: pointer to struct rc_dev. + */ void rc_close(struct rc_dev *rdev); void rc_repeat(struct rc_dev *dev); diff --git a/include/media/rc-map.h b/include/media/rc-map.h index a459129..daa75fc 100644 --- a/include/media/rc-map.h +++ b/include/media/rc-map.h @@ -98,10 +98,25 @@ struct rc_map_list { /* Routines from rc-map.c */ +/** + * rc_map_register() - Registers a Remote Controler scancode map + * + * @map: pointer to struct rc_map_list + */ int rc_map_register(struct rc_map_list *map); + +/** + * rc_map_unregister() - Unregisters a Remote Controler scancode map + * + * @map: pointer to struct rc_map_list + */ void rc_map_unregister(struct rc_map_list *map); + +/** + * rc_map_get - gets an RC map from its name + * @name: name of the RC scancode map + */ struct rc_map *rc_map_get(const char *name); -void rc_map_init(void); /* Names of the several keytables defined in-kernel */ diff --git a/include/media/tuner-types.h b/include/media/tuner-types.h index 094e112..aed5390 100644 --- a/include/media/tuner-types.h +++ b/include/media/tuner-types.h @@ -35,8 +35,12 @@ enum param_type { * those ranges, as they're defined inside the driver. This is used by * analog tuners that are compatible with the "Philips way" to setup the * tuners. On those devices, the tuner set is done via 4 bytes: - * divider byte1 (DB1), divider byte 2 (DB2), Control byte (CB) and - * band switch byte (BB). + * + * #) divider byte1 (DB1) + * #) divider byte 2 (DB2) + * #) Control byte (CB) + * #) band switch byte (BB) + * * Some tuners also have an additional optional Auxiliary byte (AB). */ struct tuner_range { diff --git a/include/media/tveeprom.h b/include/media/tveeprom.h index 8be8987..c56501ee 100644 --- a/include/media/tveeprom.h +++ b/include/media/tveeprom.h @@ -27,31 +27,43 @@ enum tveeprom_audio_processor { * struct tveeprom - Contains the fields parsed from Hauppauge eeproms * * @has_radio: 1 if the device has radio; 0 otherwise. + * * @has_ir: If has_ir == 0, then it is unknown what the IR * capabilities are. Otherwise: - * bit 0) 1 (= IR capabilities are known); - * bit 1) IR receiver present; - * bit 2) IR transmitter (blaster) present. + * bit 0) 1 (= IR capabilities are known); + * bit 1) IR receiver present; + * bit 2) IR transmitter (blaster) present. + * * @has_MAC_address: 0: no MAC, 1: MAC present, 2: unknown. * @tuner_type: type of the tuner (TUNER_*, as defined at * include/media/tuner.h). + * * @tuner_formats: Supported analog TV standards (V4L2_STD_*). * @tuner_hauppauge_model: Hauppauge's code for the device model number. * @tuner2_type: type of the second tuner (TUNER_*, as defined * at include/media/tuner.h). + * * @tuner2_formats: Tuner 2 supported analog TV standards * (V4L2_STD_*). + * * @tuner2_hauppauge_model: tuner 2 Hauppauge's code for the device model * number. + * * @audio_processor: analog audio decoder, as defined by enum * tveeprom_audio_processor. + * * @decoder_processor: Hauppauge's code for the decoder chipset. * Unused by the drivers, as they probe the * decoder based on the PCI or USB ID. + * * @model: Hauppauge's model number + * * @revision: Card revision number + * * @serial_number: Card's serial number + * * @rev_str: Card revision converted to number + * * @MAC_address: MAC address for the network interface */ struct tveeprom { diff --git a/include/media/v4l2-mc.h b/include/media/v4l2-mc.h index 7a8d603..28c3f9d 100644 --- a/include/media/v4l2-mc.h +++ b/include/media/v4l2-mc.h @@ -114,11 +114,14 @@ struct usb_device; * Add links between the entities commonly found on PC customer's hardware at * the V4L2 side: camera sensors, audio and video PLL-IF decoders, tuners, * analog TV decoder and I/O entities (video, VBI and Software Defined Radio). - * NOTE: webcams are modelled on a very simple way: the sensor is - * connected directly to the I/O entity. All dirty details, like - * scaler and crop HW are hidden. While such mapping is enough for v4l2 - * interface centric PC-consumer's hardware, V4L2 subdev centric camera - * hardware should not use this routine, as it will not build the right graph. + * + * .. note:: + * + * Webcams are modelled on a very simple way: the sensor is + * connected directly to the I/O entity. All dirty details, like + * scaler and crop HW are hidden. While such mapping is enough for v4l2 + * interface centric PC-consumer's hardware, V4L2 subdev centric camera + * hardware should not use this routine, as it will not build the right graph. */ int v4l2_mc_create_media_graph(struct media_device *mdev); diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h index c672efc..1f672c0 100644 --- a/include/media/v4l2-subdev.h +++ b/include/media/v4l2-subdev.h @@ -204,7 +204,7 @@ struct v4l2_subdev_core_ops { * * @g_frequency: callback for VIDIOC_G_FREQUENCY ioctl handler code. * freq->type must be filled in. Normally done by video_ioctl2 - * or the bridge driver. + * or the bridge driver. * * @enum_freq_bands: callback for VIDIOC_ENUM_FREQ_BANDS ioctl handler code. * @@ -212,7 +212,7 @@ struct v4l2_subdev_core_ops { * * @s_tuner: callback for VIDIOC_S_TUNER ioctl handler code. vt->type must be * filled in. Normally done by video_ioctl2 or the - * bridge driver. + * bridge driver. * * @g_modulator: callback for VIDIOC_G_MODULATOR ioctl handler code. * diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h index bea81c9e..c346bea 100644 --- a/include/media/videobuf2-core.h +++ b/include/media/videobuf2-core.h @@ -85,11 +85,17 @@ struct vb2_threadio_data; * @mmap: setup a userspace mapping for a given memory buffer under * the provided virtual memory region. * - * Required ops for USERPTR types: get_userptr, put_userptr. - * Required ops for MMAP types: alloc, put, num_users, mmap. - * Required ops for read/write access types: alloc, put, num_users, vaddr. - * Required ops for DMABUF types: attach_dmabuf, detach_dmabuf, map_dmabuf, - * unmap_dmabuf. + * Those operations are used by the videobuf2 core to implement the memory + * handling/memory allocators for each type of supported streaming I/O method. + * + * .. note:: + * #) Required ops for USERPTR types: get_userptr, put_userptr. + * + * #) Required ops for MMAP types: alloc, put, num_users, mmap. + * + * #) Required ops for read/write access types: alloc, put, num_users, vaddr. + * + * #) Required ops for DMABUF types: attach_dmabuf, detach_dmabuf, map_dmabuf, unmap_dmabuf. */ struct vb2_mem_ops { void *(*alloc)(struct device *dev, const struct dma_attrs *attrs, @@ -278,19 +284,19 @@ struct vb2_buffer { * second time with the actually allocated number of * buffers to verify if that is OK. * The driver should return the required number of buffers - * in *num_buffers, the required number of planes per - * buffer in *num_planes, the size of each plane should be + * in \*num_buffers, the required number of planes per + * buffer in \*num_planes, the size of each plane should be * set in the sizes[] array and optional per-plane * allocator specific device in the alloc_devs[] array. * When called from VIDIOC_REQBUFS, *num_planes == 0, the * driver has to use the currently configured format to - * determine the plane sizes and *num_buffers is the total + * determine the plane sizes and \*num_buffers is the total * number of buffers that are being allocated. When called - * from VIDIOC_CREATE_BUFS, *num_planes != 0 and it + * from VIDIOC_CREATE_BUFS, \*num_planes != 0 and it * describes the requested number of planes and sizes[] * contains the requested plane sizes. If either - * *num_planes or the requested sizes are invalid callback - * must return -EINVAL. In this case *num_buffers are + * \*num_planes or the requested sizes are invalid callback + * must return -EINVAL. In this case \*num_buffers are * being allocated additionally to q->num_buffers. * @wait_prepare: release any locks taken while calling vb2 functions; * it is called before an ioctl needs to wait for a new |