From cf49066152c5b46c0b90f44593beda27997ca58b Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Fri, 21 Aug 2015 11:50:17 -0300 Subject: [media] replace all occurrences of MEDIA_ENT_T_DEVNODE_V4L Now that interfaces and entities are distinct, it makes no sense of keeping something named as MEDIA_ENT_T_DEVNODE. This change was done with this script: for i in $(git grep -l MEDIA_ENT_T|grep -v uapi/linux/media.h); do sed s,MEDIA_ENT_T_DEVNODE_V4L,MEDIA_ENT_T_V4L2_VIDEO, <$i >a && mv a $i; done Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation/DocBook') diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml index 5872f8bbf774..910243d4edb8 100644 --- a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml +++ b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml @@ -183,7 +183,7 @@ Unknown device node - MEDIA_ENT_T_DEVNODE_V4L + MEDIA_ENT_T_V4L2_VIDEO V4L video, radio or vbi device node -- cgit v1.2.3 From fef486a07d69cbcae81bf65a6817ff7383104a24 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Fri, 21 Aug 2015 11:54:40 -0300 Subject: [media] replace all occurrences of MEDIA_ENT_T_DEVNODE_DVB Now that interfaces and entities are distinct, it makes no sense of keeping something named as MEDIA_ENT_T_DEVNODE_DVB_foo. Made via this script: for i in $(git grep -l MEDIA_ENT_T|grep -v uapi/linux/media.h); do sed s,MEDIA_ENT_T_DEVNODE_DVB_,MEDIA_ENT_T_DVB_, <$i >a && mv a $i; done for i in $(git grep -l MEDIA_ENT_T|grep -v uapi/linux/media.h); do sed s,MEDIA_ENT_T_DVB_DVR,MEDIA_ENT_T_DVB_TSOUT, <$i >a && mv a $i; done for i in $(git grep -l MEDIA_ENT_T|grep -v uapi/linux/media.h); do sed s,MEDIA_ENT_T_DVB_FE,MEDIA_ENT_T_DVB_DEMOD, <$i >a && mv a $i; done for i in $(git grep -l MEDIA_ENT_T|grep -v uapi/linux/media.h); do sed s,MEDIA_ENT_T_DVB_NET,MEDIA_ENT_T_DVB_DEMOD_NET_DECAP, <$i >a && mv a $i; done Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation/DocBook') diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml index 910243d4edb8..32a783635649 100644 --- a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml +++ b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml @@ -195,23 +195,23 @@ ALSA card - MEDIA_ENT_T_DEVNODE_DVB_FE + MEDIA_ENT_T_DVB_DEMOD DVB frontend devnode - MEDIA_ENT_T_DEVNODE_DVB_DEMUX + MEDIA_ENT_T_DVB_DEMUX DVB demux devnode - MEDIA_ENT_T_DEVNODE_DVB_DVR + MEDIA_ENT_T_DVB_TSOUT DVB DVR devnode - MEDIA_ENT_T_DEVNODE_DVB_CA + MEDIA_ENT_T_DVB_CA DVB CAM devnode - MEDIA_ENT_T_DEVNODE_DVB_NET + MEDIA_ENT_T_DVB_DEMOD_NET_DECAP DVB network devnode -- cgit v1.2.3 From 4ae1723af80ce5a23fa5bc6db1534265af0d6107 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Thu, 7 May 2015 22:12:40 -0300 Subject: [media] DocBook: update descriptions for the media controller entities Cleanup the media controller entities description: - remove MEDIA_ENT_T_DEVNODE and MEDIA_ENT_T_V4L2_SUBDEV entity types, as they don't mean anything; - add MEDIA_ENT_T_UNKNOWN with a proper description; - remove ALSA and FB entity types. Those should not be used, as the types are deprecated. We'll soon be adidng ALSA, but with a different entity namespace; - improve the description of some entities. Signed-off-by: Mauro Carvalho Chehab --- .../DocBook/media/v4l/media-ioc-enum-entities.xml | 47 ++++++++++------------ 1 file changed, 22 insertions(+), 25 deletions(-) (limited to 'Documentation/DocBook') diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml index 32a783635649..13d0b5891fb7 100644 --- a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml +++ b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml @@ -179,70 +179,67 @@ - MEDIA_ENT_T_DEVNODE - Unknown device node + MEDIA_ENT_T_UNKNOWN and MEDIA_ENT_T_V4L2_SUBDEV_UNKNOWN + Unknown entity. That generally indicates that + a driver didn't initialize properly the entity, with is a Kernel bug MEDIA_ENT_T_V4L2_VIDEO - V4L video, radio or vbi device node + V4L video streaming input or output entity - MEDIA_ENT_T_DEVNODE_FB - Frame buffer device node + MEDIA_ENT_T_V4L2_VBI + V4L VBI streaming input or output entity - MEDIA_ENT_T_DEVNODE_ALSA - ALSA card + MEDIA_ENT_T_V4L2_SWRADIO + V4L Software Digital Radio (SDR) streaming input or output entity MEDIA_ENT_T_DVB_DEMOD - DVB frontend devnode + DVB demodulator entity MEDIA_ENT_T_DVB_DEMUX - DVB demux devnode + DVB demux entity. Can be implemented in hardware or in Kernelspace MEDIA_ENT_T_DVB_TSOUT - DVB DVR devnode + DVB Transport Stream output entity MEDIA_ENT_T_DVB_CA - DVB CAM devnode + DVB Conditional Access module (CAM) entity MEDIA_ENT_T_DVB_DEMOD_NET_DECAP - DVB network devnode - - - MEDIA_ENT_T_V4L2_SUBDEV - Unknown V4L sub-device + DVB network ULE/MLE de-encapsulation entity. Can be implemented in hardware or in Kernelspace MEDIA_ENT_T_V4L2_SUBDEV_SENSOR - Video sensor + Camera image sensor entity MEDIA_ENT_T_V4L2_SUBDEV_FLASH - Flash controller + Flash controller entity MEDIA_ENT_T_V4L2_SUBDEV_LENS - Lens controller + Lens controller entity MEDIA_ENT_T_V4L2_SUBDEV_DECODER - Video decoder, the basic function of the video decoder is to - accept analogue video from a wide variety of sources such as + Analog video decoder, the basic function of the video decoder + is to accept analogue video from a wide variety of sources such as broadcast, DVD players, cameras and video cassette recorders, in - either NTSC, PAL or HD format and still occasionally SECAM, separate - it into its component parts, luminance and chrominance, and output - it in some digital video standard, with appropriate embedded timing + either NTSC, PAL, SECAM or HD format, separating the stream + into its component parts, luminance and chrominance, and output + it in some digital video standard, with appropriate timing signals. MEDIA_ENT_T_V4L2_SUBDEV_TUNER - TV and/or radio tuner + Digital TV, analog TV, radio and/or software radio tuner -- cgit v1.2.3 From bd3ed12be1e1262adcb733bcf63e5da4d8772774 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Sun, 6 Sep 2015 12:30:43 -0300 Subject: [media] DocBook: update entities documentation Due to the rename, the documentation became outdated. Update it to reflect what's there at media.h. Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- .../DocBook/media/v4l/media-ioc-enum-entities.xml | 64 ++++++++++++++-------- 1 file changed, 40 insertions(+), 24 deletions(-) (limited to 'Documentation/DocBook') diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml index 13d0b5891fb7..27f8817e7abe 100644 --- a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml +++ b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml @@ -179,56 +179,72 @@ - MEDIA_ENT_T_UNKNOWN and MEDIA_ENT_T_V4L2_SUBDEV_UNKNOWN + MEDIA_ENT_F_UNKNOWN and MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN Unknown entity. That generally indicates that a driver didn't initialize properly the entity, with is a Kernel bug - MEDIA_ENT_T_V4L2_VIDEO - V4L video streaming input or output entity + MEDIA_ENT_F_IO_V4L + Data streaming input and/or output entity. - MEDIA_ENT_T_V4L2_VBI + MEDIA_ENT_F_IO_VBI V4L VBI streaming input or output entity - MEDIA_ENT_T_V4L2_SWRADIO + MEDIA_ENT_F_IO_SWRADIO V4L Software Digital Radio (SDR) streaming input or output entity - MEDIA_ENT_T_DVB_DEMOD - DVB demodulator entity + MEDIA_ENT_F_IO_DTV + DVB Digital TV streaming input or output entity - MEDIA_ENT_T_DVB_DEMUX - DVB demux entity. Can be implemented in hardware or in Kernelspace + MEDIA_ENT_F_DTV_DEMOD + Digital TV demodulator entity. - MEDIA_ENT_T_DVB_TSOUT - DVB Transport Stream output entity + MEDIA_ENT_F_MPEG_TS_DEMUX + MPEG Transport stream demux entity. Could be implemented on hardware or in Kernelspace by the Linux DVB subsystem. - MEDIA_ENT_T_DVB_CA - DVB Conditional Access module (CAM) entity + MEDIA_ENT_F_DTV_CA + Digital TV Conditional Access module (CAM) entity - MEDIA_ENT_T_DVB_DEMOD_NET_DECAP - DVB network ULE/MLE de-encapsulation entity. Can be implemented in hardware or in Kernelspace + MEDIA_ENT_F_DTV_NET_DECAP + Digital TV network ULE/MLE desencapsulation entity. Could be implemented on hardware or in Kernelspace - MEDIA_ENT_T_V4L2_SUBDEV_SENSOR - Camera image sensor entity + MEDIA_ENT_F_CONN_RF + Connector for a Radio Frequency (RF) signal. - MEDIA_ENT_T_V4L2_SUBDEV_FLASH - Flash controller entity + MEDIA_ENT_F_CONN_SVIDEO + Connector for a S-Video signal. - MEDIA_ENT_T_V4L2_SUBDEV_LENS - Lens controller entity + MEDIA_ENT_F_CONN_COMPOSITE + Connector for a RGB composite signal. - MEDIA_ENT_T_V4L2_SUBDEV_DECODER + MEDIA_ENT_F_CONN_TEST + Connector for a test generator. + + + MEDIA_ENT_F_CAM_SENSOR + Camera video sensor entity. + + + MEDIA_ENT_F_FLASH + Flash controller entity. + + + MEDIA_ENT_F_LENS + Lens controller entity. + + + MEDIA_ENT_F_ATV_DECODER Analog video decoder, the basic function of the video decoder is to accept analogue video from a wide variety of sources such as broadcast, DVD players, cameras and video cassette recorders, in @@ -238,8 +254,8 @@ signals. - MEDIA_ENT_T_V4L2_SUBDEV_TUNER - Digital TV, analog TV, radio and/or software radio tuner + MEDIA_ENT_F_TUNER + Digital TV, analog TV, radio and/or software radio tuner. -- cgit v1.2.3 From 8ed8c88c460fa6ce71deb9847f78a5bff4dfcb0e Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Fri, 11 Dec 2015 08:02:19 -0200 Subject: [media] media-entity.h: get rid of revision and group_id fields Both revision and group_id fields were never used and were always initialized to zero. Remove them. Suggested-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml | 13 ++----------- Documentation/media-framework.txt | 12 +++++------- drivers/media/media-device.c | 4 ++-- include/media/media-entity.h | 4 ---- 4 files changed, 9 insertions(+), 24 deletions(-) (limited to 'Documentation/DocBook') diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml index 27f8817e7abe..9f7614a01234 100644 --- a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml +++ b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml @@ -59,15 +59,6 @@ Entity IDs can be non-contiguous. Applications must not try to enumerate entities by calling MEDIA_IOC_ENUM_ENTITIES with increasing id's until they get an error. - Two or more entities that share a common non-zero - group_id value are considered as logically - grouped. Groups are used to report - - ALSA, VBI and video nodes that carry the same media - stream - lens and flash controllers associated with a sensor - - struct <structname>media_entity_desc</structname> @@ -106,7 +97,7 @@ revision - Entity revision in a driver/hardware specific format. + Entity revision. Always zero (obsolete) __u32 @@ -120,7 +111,7 @@ group_id - Entity group ID + Entity group ID. Always zero (obsolete) __u16 diff --git a/Documentation/media-framework.txt b/Documentation/media-framework.txt index 7fbfe4bd1f47..ef3663af1db3 100644 --- a/Documentation/media-framework.txt +++ b/Documentation/media-framework.txt @@ -110,10 +110,10 @@ If no pads are needed, drivers could directly fill entity->num_pads with 0 and entity->pads with NULL or to call the above function that will do the same. -The media_entity name, type, flags, revision and group_id fields should be -initialized before calling media_device_register_entity(). Entities embedded -in higher-level standard structures can have some of those fields set by the -higher-level framework. +The media_entity name, type and flags fields should be initialized before +calling media_device_register_entity(). Entities embedded in higher-level +standard structures can have some of those fields set by the higher-level +framework. As the number of pads is known in advance, the pads array is not allocated dynamically but is managed by the entity driver. Most drivers will embed the @@ -164,9 +164,7 @@ Entities have flags that describe the entity capabilities and state. Logical entity groups can be defined by setting the group ID of all member entities to the same non-zero value. An entity group serves no purpose in the -kernel, but is reported to userspace during entities enumeration. The group_id -field belongs to the media device driver and must not by touched by entity -drivers. +kernel, but is reported to userspace during entities enumeration. Media device drivers should define groups if several entities are logically bound together. Example usages include reporting diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c index b8cd7733a31c..537160bb461e 100644 --- a/drivers/media/media-device.c +++ b/drivers/media/media-device.c @@ -109,9 +109,9 @@ static long media_device_enum_entities(struct media_device *mdev, if (ent->name) strlcpy(u_ent.name, ent->name, sizeof(u_ent.name)); u_ent.type = ent->function; - u_ent.revision = ent->revision; + u_ent.revision = 0; /* Unused */ u_ent.flags = ent->flags; - u_ent.group_id = ent->group_id; + u_ent.group_id = 0; /* Unused */ u_ent.pads = ent->num_pads; u_ent.links = ent->num_links - ent->num_backlinks; memcpy(&u_ent.raw, &ent->info, sizeof(ent->info)); diff --git a/include/media/media-entity.h b/include/media/media-entity.h index 32fef503d950..031536723d8c 100644 --- a/include/media/media-entity.h +++ b/include/media/media-entity.h @@ -153,9 +153,7 @@ struct media_entity_operations { * @name: Entity name. * @function: Entity main function, as defined in uapi/media.h * (MEDIA_ENT_F_*) - * @revision: Entity revision - OBSOLETE - should be removed soon. * @flags: Entity flags, as defined in uapi/media.h (MEDIA_ENT_FL_*) - * @group_id: Entity group ID - OBSOLETE - should be removed soon. * @num_pads: Number of sink and source pads. * @num_links: Total number of links, forward and back, enabled and disabled. * @num_backlinks: Number of backlinks @@ -180,9 +178,7 @@ struct media_entity { struct media_gobj graph_obj; /* must be first field in struct */ const char *name; u32 function; - u32 revision; unsigned long flags; - u32 group_id; u16 num_pads; u16 num_links; -- cgit v1.2.3 From cc2dd94a051c8a467c66a258391cb980c3fb3312 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Fri, 11 Dec 2015 08:21:39 -0200 Subject: [media] DocBook: Move media-framework.txt contents to media-device.h Instead of using a text file, let's put it together with the struct documentation for the Media Controller. Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/device-drivers.tmpl | 1 + Documentation/media-framework.txt | 373 ----------------------------- include/media/media-device.h | 378 ++++++++++++++++++++++++++++++ 3 files changed, 379 insertions(+), 373 deletions(-) delete mode 100644 Documentation/media-framework.txt (limited to 'Documentation/DocBook') diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl index 7b3fcc5effcd..cdd8b24db68d 100644 --- a/Documentation/DocBook/device-drivers.tmpl +++ b/Documentation/DocBook/device-drivers.tmpl @@ -263,6 +263,7 @@ X!Isound/sound_firmware.c !Iinclude/media/lirc_dev.h Media Controller devices +!Pinclude/media/media-device.h Media Controller !Iinclude/media/media-device.h !Iinclude/media/media-devnode.h !Iinclude/media/media-entity.h diff --git a/Documentation/media-framework.txt b/Documentation/media-framework.txt deleted file mode 100644 index ef3663af1db3..000000000000 --- a/Documentation/media-framework.txt +++ /dev/null @@ -1,373 +0,0 @@ -Linux kernel media framework -============================ - -This document describes the Linux kernel media framework, its data structures, -functions and their usage. - - -Introduction ------------- - -The media controller API is documented in DocBook format in -Documentation/DocBook/media/v4l/media-controller.xml. This document will 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(struct media_device *mdev); - -The caller is responsible for initializing the media_device structure before -registration. The following fields must be set: - - - dev must point to the parent device (usually a pci_dev, usb_interface or - platform_device instance). - - - model must be filled with the device model name as a NUL-terminated UTF-8 - string. The device/model revision must not be stored in this field. - -The following fields are optional: - - - serial is a unique serial number stored as a NUL-terminated ASCII string. - The field is big enough to store a GUID in text form. If the hardware - doesn't provide a unique serial number this field must be left empty. - - - bus_info represents the location of the device in the system as a - NUL-terminated ASCII string. For PCI/PCIe devices bus_info must be set to - "PCI:" (or "PCIe:") followed by the value of pci_name(). For USB devices, - the usb_make_path() function must be used. This field is used by - applications to distinguish between otherwise identical devices that don't - provide a serial number. - - - hw_revision is the hardware device revision in a driver-specific format. - When possible the revision should be formatted with the KERNEL_VERSION - macro. - - - driver_version is formatted with the KERNEL_VERSION macro. The version - minor must be incremented when new features are added to the userspace API - without breaking binary compatibility. The version major must be - incremented when binary compatibility is broken. - -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. - -Drivers unregister media device instances by calling - - media_device_unregister(struct media_device *mdev); - -Unregistering a media device that hasn't been registered is *NOT* safe. - - -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(struct media_entity *entity, u16 num_pads, - struct media_pad *pads); - -If no pads are needed, drivers could directly fill entity->num_pads -with 0 and entity->pads with NULL or to call the above function that -will do the same. - -The media_entity name, type and flags fields should be initialized before -calling media_device_register_entity(). Entities embedded in higher-level -standard structures can have some of those fields set by the higher-level -framework. - -As the number of pads is known in advance, the pads array is not allocated -dynamically but is managed by the entity driver. Most drivers will embed the -pads array in a driver-specific structure, avoiding dynamic allocation. - -Drivers must set the direction of every pad in the pads array before calling -media_entity_pads_init. The function will initialize the other pads fields. - -Unlike the number of pads, the total number of links isn't always known in -advance by the entity driver. As an initial estimate, media_entity_pads_init -pre-allocates a number of links equal to the number of pads. The links array -will be reallocated if it grows beyond the initial estimate. - -Drivers register entities with a media device by calling - - media_device_register_entity(struct media_device *mdev, - struct media_entity *entity); - -Entities are identified by a unique positive integer ID. Drivers can provide an -ID by filling the media_entity id field prior to registration, or request the -media controller framework to assign an ID automatically. Drivers that provide -IDs manually must ensure that all IDs are unique. IDs are not guaranteed to be -contiguous even when they are all assigned automatically by the framework. - -Drivers unregister entities by calling - - media_device_unregister_entity(struct media_entity *entity); - -Unregistering an entity will not change the IDs of the other entities, and the -ID will never be reused for a newly registered entity. - -When a media device is unregistered, all its entities are unregistered -automatically. No manual entities unregistration is then required. - -Drivers free resources associated with an entity by calling - - media_entity_cleanup(struct media_entity *entity); - -This function must be called during the cleanup phase after unregistering the -entity. Note that the media_entity instance itself must be freed explicitly by -the driver if required. - -Entities have flags that describe the entity capabilities and state. - - MEDIA_ENT_FL_DEFAULT indicates the default entity for a given type. - This can be used to report the default audio and video devices or the - default camera sensor. - -Logical entity groups can be defined by setting the group ID of all member -entities to the same non-zero value. An entity group serves no purpose in the -kernel, but is reported to userspace during entities enumeration. - -Media device drivers should define groups if several entities are logically -bound together. Example usages include reporting - - - ALSA, VBI and video nodes that carry the same media stream - - lens and flash controllers associated with a sensor - -- 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. - -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. Each entity stores all links originating at or -targeting any of its pads in a links array. A given link is thus stored -twice, once in the source entity and once in the target entity. The array is -pre-allocated and grows dynamically as needed. - -Drivers create links by calling - - media_create_pad_link(struct media_entity *source, u16 source_pad, - struct media_entity *sink, u16 sink_pad, - u32 flags); - -An entry in the link array of each entity is allocated and stores pointers -to source and sink pads. - -Links have flags that describe the link capabilities and state. - - MEDIA_LNK_FL_ENABLED 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. - MEDIA_LNK_FL_IMMUTABLE 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. - - -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(struct media_entity_graph *graph, - struct media_entity *entity); - -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(struct media_entity_graph *graph); - -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(struct media_pad *source, - struct media_pad *sink); - - media_entity_remote_pad(struct media_pad *pad); - -Refer to the kerneldoc documentation for more information. - - -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 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(struct media_link *link, u32 flags); - -The flags argument contains the requested new link flags. - -The only configurable property is the ENABLED link flag to enable/disable a -link. Links marked with the IMMUTABLE link flag can not be enabled or disabled. - -When a link is enabled or disabled, the media framework calls the -link_setup operation for the two entities at the source and sink of the link, -in that order. If the second link_setup call fails, another link_setup call is -made on the first entity to restore the original link flags. - -Media device drivers can be notified of link setup operations by setting the -media_device::link_notify pointer to a callback function. If provided, the -notification callback will be called before enabling and after disabling -links. - -Entity drivers must implement the link_setup operation if any of their links -is non-immutable. The operation must either configure the hardware or store -the configuration information to be applied later. - -Link configuration must not have any side effect on other links. If an enabled -link at a sink pad prevents another link at the same pad from being enabled, -the link_setup operation must return -EBUSY and can't implicitly disable the -first enabled 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(struct media_entity *entity, - struct media_pipeline *pipe); - -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(struct media_entity *entity); - -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. diff --git a/include/media/media-device.h b/include/media/media-device.h index 87ff299e1265..6728528df9e2 100644 --- a/include/media/media-device.h +++ b/include/media/media-device.h @@ -30,6 +30,384 @@ #include #include +/** + * DOC: Media Controller + * + * Linux kernel media framework + * ============================ + * + * This document describes the Linux kernel media framework, its data structures, + * functions and their usage. + * + * + * Introduction + * ------------ + * + * The media controller API is documented in DocBook format in + * Documentation/DocBook/media/v4l/media-controller.xml. This document will 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(struct media_device *mdev); + * + * The caller is responsible for initializing the media_device structure before + * registration. The following fields must be set: + * + * - dev must point to the parent device (usually a pci_dev, usb_interface or + * platform_device instance). + * + * - model must be filled with the device model name as a NUL-terminated UTF-8 + * string. The device/model revision must not be stored in this field. + * + * The following fields are optional: + * + * - serial is a unique serial number stored as a NUL-terminated ASCII string. + * The field is big enough to store a GUID in text form. If the hardware + * doesn't provide a unique serial number this field must be left empty. + * + * - bus_info represents the location of the device in the system as a + * NUL-terminated ASCII string. For PCI/PCIe devices bus_info must be set to + * "PCI:" (or "PCIe:") followed by the value of pci_name(). For USB devices, + * the usb_make_path() function must be used. This field is used by + * applications to distinguish between otherwise identical devices that don't + * provide a serial number. + * + * - hw_revision is the hardware device revision in a driver-specific format. + * When possible the revision should be formatted with the KERNEL_VERSION + * macro. + * + * - driver_version is formatted with the KERNEL_VERSION macro. The version + * minor must be incremented when new features are added to the userspace API + * without breaking binary compatibility. The version major must be + * incremented when binary compatibility is broken. + * + * 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. + * + * Drivers unregister media device instances by calling + * + * media_device_unregister(struct media_device *mdev); + * + * Unregistering a media device that hasn't been registered is *NOT* safe. + * + * + * 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(struct media_entity *entity, u16 num_pads, + * struct media_pad *pads); + * + * If no pads are needed, drivers could directly fill entity->num_pads + * with 0 and entity->pads with NULL or to call the above function that + * will do the same. + * + * The media_entity name, type and flags fields should be initialized before + * calling media_device_register_entity(). Entities embedded in higher-level + * standard structures can have some of those fields set by the higher-level + * framework. + * + * As the number of pads is known in advance, the pads array is not allocated + * dynamically but is managed by the entity driver. Most drivers will embed the + * pads array in a driver-specific structure, avoiding dynamic allocation. + * + * Drivers must set the direction of every pad in the pads array before calling + * media_entity_pads_init. The function will initialize the other pads fields. + * + * Unlike the number of pads, the total number of links isn't always known in + * advance by the entity driver. As an initial estimate, media_entity_pads_init + * pre-allocates a number of links equal to the number of pads. The links array + * will be reallocated if it grows beyond the initial estimate. + * + * Drivers register entities with a media device by calling + * + * media_device_register_entity(struct media_device *mdev, + * struct media_entity *entity); + * + * Entities are identified by a unique positive integer ID. Drivers can provide an + * ID by filling the media_entity id field prior to registration, or request the + * media controller framework to assign an ID automatically. Drivers that provide + * IDs manually must ensure that all IDs are unique. IDs are not guaranteed to be + * contiguous even when they are all assigned automatically by the framework. + * + * Drivers unregister entities by calling + * + * media_device_unregister_entity(struct media_entity *entity); + * + * Unregistering an entity will not change the IDs of the other entities, and the + * ID will never be reused for a newly registered entity. + * + * When a media device is unregistered, all its entities are unregistered + * automatically. No manual entities unregistration is then required. + * + * Drivers free resources associated with an entity by calling + * + * media_entity_cleanup(struct media_entity *entity); + * + * This function must be called during the cleanup phase after unregistering the + * entity. Note that the media_entity instance itself must be freed explicitly by + * the driver if required. + * + * Entities have flags that describe the entity capabilities and state. + * + * MEDIA_ENT_FL_DEFAULT indicates the default entity for a given type. + * This can be used to report the default audio and video devices or the + * default camera sensor. + * + * Logical entity groups can be defined by setting the group ID of all member + * entities to the same non-zero value. An entity group serves no purpose in the + * kernel, but is reported to userspace during entities enumeration. + * + * Media device drivers should define groups if several entities are logically + * bound together. Example usages include reporting + * + * - ALSA, VBI and video nodes that carry the same media stream + * - lens and flash controllers associated with a sensor + * + * - 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. + * + * 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. Each entity stores all links originating at or + * targeting any of its pads in a links array. A given link is thus stored + * twice, once in the source entity and once in the target entity. The array is + * pre-allocated and grows dynamically as needed. + * + * Drivers create links by calling + * + * media_create_pad_link(struct media_entity *source, u16 source_pad, + * struct media_entity *sink, u16 sink_pad, + * u32 flags); + * + * An entry in the link array of each entity is allocated and stores pointers + * to source and sink pads. + * + * Links have flags that describe the link capabilities and state. + * + * MEDIA_LNK_FL_ENABLED 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. + * MEDIA_LNK_FL_IMMUTABLE 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. + * + * + * 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(struct media_entity_graph *graph, + * struct media_entity *entity); + * + * 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(struct media_entity_graph *graph); + * + * 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(struct media_pad *source, + * struct media_pad *sink); + * + * media_entity_remote_pad(struct media_pad *pad); + * + * Refer to the kerneldoc documentation for more information. + * + * + * 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 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(struct media_link *link, u32 flags); + * + * The flags argument contains the requested new link flags. + * + * The only configurable property is the ENABLED link flag to enable/disable a + * link. Links marked with the IMMUTABLE link flag can not be enabled or disabled. + * + * When a link is enabled or disabled, the media framework calls the + * link_setup operation for the two entities at the source and sink of the link, + * in that order. If the second link_setup call fails, another link_setup call is + * made on the first entity to restore the original link flags. + * + * Media device drivers can be notified of link setup operations by setting the + * media_device::link_notify pointer to a callback function. If provided, the + * notification callback will be called before enabling and after disabling + * links. + * + * Entity drivers must implement the link_setup operation if any of their links + * is non-immutable. The operation must either configure the hardware or store + * the configuration information to be applied later. + * + * Link configuration must not have any side effect on other links. If an enabled + * link at a sink pad prevents another link at the same pad from being enabled, + * the link_setup operation must return -EBUSY and can't implicitly disable the + * first enabled 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(struct media_entity *entity, + * struct media_pipeline *pipe); + * + * 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(struct media_entity *entity); + * + * 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 device; /** -- cgit v1.2.3 From b7870d692d7b0718f7153aed9e7a32f0119b525d Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Sat, 12 Dec 2015 08:59:14 -0200 Subject: [media] DocBook: MC: add the concept of interfaces The Media Controller next generation patches added a new graph element type: interfaces. It also allows links between interfaces and entities. Update the docbook to reflect that. Signed-off-by: Mauro Carvalho Chehab --- .../DocBook/media/v4l/media-controller.xml | 40 ++++++++++++++-------- 1 file changed, 26 insertions(+), 14 deletions(-) (limited to 'Documentation/DocBook') diff --git a/Documentation/DocBook/media/v4l/media-controller.xml b/Documentation/DocBook/media/v4l/media-controller.xml index 873ac3a621f0..def4a27aadef 100644 --- a/Documentation/DocBook/media/v4l/media-controller.xml +++ b/Documentation/DocBook/media/v4l/media-controller.xml @@ -58,20 +58,32 @@ Media device model Discovering a device internal topology, and configuring it at runtime, is one of the goals of the media controller API. 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 or software 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. + devices and Linux Kernel interfaces are modelled as graph objects on + an oriented graph. The object types that constitute the graph are: + + An entity + is a basic media hardware or software 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. + An interface + is a graph representation of a Linux Kernel userspace API interface, + like a device node or a sysfs file that controls one or more entities + in the graph. + A pad + is a data 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 data 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. + An interface link + is a point-to-point bidirectional control connection between a Linux + Kernel interface and an entity.m + -- cgit v1.2.3 From 5fec921f49891e1343d60df3f6f40ceb52acdd42 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Sat, 12 Dec 2015 09:56:07 -0200 Subject: [media] DocBook: move data types to a separate section As MEDIA_IOC_G_TOPOLOGY shares the data types already declared for entities, pads and links, we should move those to a separate part of the document, and use cross-references where needed. So, move the following tables to a separate section at the DocBook: media-entity-type media-entity-flag media-pad-flag media-link-flag Signed-off-by: Mauro Carvalho Chehab --- .../DocBook/media/v4l/media-controller.xml | 3 + .../DocBook/media/v4l/media-ioc-enum-entities.xml | 104 ------------- .../DocBook/media/v4l/media-ioc-enum-links.xml | 56 ------- Documentation/DocBook/media/v4l/media-types.xml | 166 +++++++++++++++++++++ 4 files changed, 169 insertions(+), 160 deletions(-) create mode 100644 Documentation/DocBook/media/v4l/media-types.xml (limited to 'Documentation/DocBook') diff --git a/Documentation/DocBook/media/v4l/media-controller.xml b/Documentation/DocBook/media/v4l/media-controller.xml index def4a27aadef..63d48decaa6f 100644 --- a/Documentation/DocBook/media/v4l/media-controller.xml +++ b/Documentation/DocBook/media/v4l/media-controller.xml @@ -85,6 +85,9 @@ Kernel interface and an entity.m + + + &sub-media-types; diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml index 9f7614a01234..0c4f96bfc2de 100644 --- a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml +++ b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml @@ -162,110 +162,6 @@
- - - Media entity types - - - - - - MEDIA_ENT_F_UNKNOWN and MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN - Unknown entity. That generally indicates that - a driver didn't initialize properly the entity, with is a Kernel bug - - - MEDIA_ENT_F_IO_V4L - Data streaming input and/or output entity. - - - MEDIA_ENT_F_IO_VBI - V4L VBI streaming input or output entity - - - MEDIA_ENT_F_IO_SWRADIO - V4L Software Digital Radio (SDR) streaming input or output entity - - - MEDIA_ENT_F_IO_DTV - DVB Digital TV streaming input or output entity - - - MEDIA_ENT_F_DTV_DEMOD - Digital TV demodulator entity. - - - MEDIA_ENT_F_MPEG_TS_DEMUX - MPEG Transport stream demux entity. Could be implemented on hardware or in Kernelspace by the Linux DVB subsystem. - - - MEDIA_ENT_F_DTV_CA - Digital TV Conditional Access module (CAM) entity - - - MEDIA_ENT_F_DTV_NET_DECAP - Digital TV network ULE/MLE desencapsulation entity. Could be implemented on hardware or in Kernelspace - - - MEDIA_ENT_F_CONN_RF - Connector for a Radio Frequency (RF) signal. - - - MEDIA_ENT_F_CONN_SVIDEO - Connector for a S-Video signal. - - - MEDIA_ENT_F_CONN_COMPOSITE - Connector for a RGB composite signal. - - - MEDIA_ENT_F_CONN_TEST - Connector for a test generator. - - - MEDIA_ENT_F_CAM_SENSOR - Camera video sensor entity. - - - MEDIA_ENT_F_FLASH - Flash controller entity. - - - MEDIA_ENT_F_LENS - Lens controller entity. - - - MEDIA_ENT_F_ATV_DECODER - Analog video decoder, the basic function of the video decoder - is to accept analogue video from a wide variety of sources such as - broadcast, DVD players, cameras and video cassette recorders, in - either NTSC, PAL, SECAM or HD format, separating the stream - into its component parts, luminance and chrominance, and output - it in some digital video standard, with appropriate timing - signals. - - - MEDIA_ENT_F_TUNER - Digital TV, analog TV, radio and/or software radio tuner. - - - -
- - - Media entity flags - - - - - - MEDIA_ENT_FL_DEFAULT - Default entity for its type. Used to discover the default - audio, VBI and video devices, the default camera sensor, ... - - - -
diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml b/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml index 74fb394ec667..2bbeea9f3e18 100644 --- a/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml +++ b/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml @@ -118,35 +118,6 @@ - - Media pad flags - - - - - - MEDIA_PAD_FL_SINK - Input pad, relative to the entity. Input pads sink data and - are targets of links. - - - MEDIA_PAD_FL_SOURCE - Output pad, relative to the entity. Output pads source data - and are origins of links. - - - MEDIA_PAD_FL_MUST_CONNECT - If this flag is set and the pad is linked to any other - pad, then at least one of those links must be enabled for the - entity to be able to stream. There could be temporary reasons - (e.g. device configuration dependent) for the pad to need - enabled links even when this flag isn't set; the absence of the - flag doesn't imply there is none. - - - -
- struct <structname>media_link_desc</structname> @@ -171,33 +142,6 @@ - - Media link flags - - - - - - MEDIA_LNK_FL_ENABLED - 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. - - - MEDIA_LNK_FL_IMMUTABLE - The link enabled state can't be modified at runtime. An - immutable link is always enabled. - - - MEDIA_LNK_FL_DYNAMIC - The link enabled state can be modified during streaming. This - flag is set by drivers and is read-only for applications. - - - - - One and only one of MEDIA_PAD_FL_SINK and - MEDIA_PAD_FL_SOURCE must be set for every pad. diff --git a/Documentation/DocBook/media/v4l/media-types.xml b/Documentation/DocBook/media/v4l/media-types.xml new file mode 100644 index 000000000000..0c5c9c034586 --- /dev/null +++ b/Documentation/DocBook/media/v4l/media-types.xml @@ -0,0 +1,166 @@ +
+Types and flags used to represent the media graph elements + + + Media entity types + + + + + + MEDIA_ENT_F_UNKNOWN and MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN + Unknown entity. That generally indicates that + a driver didn't initialize properly the entity, with is a Kernel bug + + + MEDIA_ENT_F_IO_V4L + Data streaming input and/or output entity. + + + MEDIA_ENT_F_IO_VBI + V4L VBI streaming input or output entity + + + MEDIA_ENT_F_IO_SWRADIO + V4L Software Digital Radio (SDR) streaming input or output entity + + + MEDIA_ENT_F_IO_DTV + DVB Digital TV streaming input or output entity + + + MEDIA_ENT_F_DTV_DEMOD + Digital TV demodulator entity. + + + MEDIA_ENT_F_MPEG_TS_DEMUX + MPEG Transport stream demux entity. Could be implemented on hardware or in Kernelspace by the Linux DVB subsystem. + + + MEDIA_ENT_F_DTV_CA + Digital TV Conditional Access module (CAM) entity + + + MEDIA_ENT_F_DTV_NET_DECAP + Digital TV network ULE/MLE desencapsulation entity. Could be implemented on hardware or in Kernelspace + + + MEDIA_ENT_F_CONN_RF + Connector for a Radio Frequency (RF) signal. + + + MEDIA_ENT_F_CONN_SVIDEO + Connector for a S-Video signal. + + + MEDIA_ENT_F_CONN_COMPOSITE + Connector for a RGB composite signal. + + + MEDIA_ENT_F_CONN_TEST + Connector for a test generator. + + + MEDIA_ENT_F_CAM_SENSOR + Camera video sensor entity. + + + MEDIA_ENT_F_FLASH + Flash controller entity. + + + MEDIA_ENT_F_LENS + Lens controller entity. + + + MEDIA_ENT_F_ATV_DECODER + Analog video decoder, the basic function of the video decoder + is to accept analogue video from a wide variety of sources such as + broadcast, DVD players, cameras and video cassette recorders, in + either NTSC, PAL, SECAM or HD format, separating the stream + into its component parts, luminance and chrominance, and output + it in some digital video standard, with appropriate timing + signals. + + + MEDIA_ENT_F_TUNER + Digital TV, analog TV, radio and/or software radio tuner. + + + +
+ + + Media entity flags + + + + + + MEDIA_ENT_FL_DEFAULT + Default entity for its type. Used to discover the default + audio, VBI and video devices, the default camera sensor, ... + + + +
+ + + Media pad flags + + + + + + MEDIA_PAD_FL_SINK + Input pad, relative to the entity. Input pads sink data and + are targets of links. + + + MEDIA_PAD_FL_SOURCE + Output pad, relative to the entity. Output pads source data + and are origins of links. + + + MEDIA_PAD_FL_MUST_CONNECT + If this flag is set and the pad is linked to any other + pad, then at least one of those links must be enabled for the + entity to be able to stream. There could be temporary reasons + (e.g. device configuration dependent) for the pad to need + enabled links even when this flag isn't set; the absence of the + flag doesn't imply there is none. + + + +
+ + One and only one of MEDIA_PAD_FL_SINK and + MEDIA_PAD_FL_SOURCE must be set for every pad. + + + Media link flags + + + + + + MEDIA_LNK_FL_ENABLED + 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. + + + MEDIA_LNK_FL_IMMUTABLE + The link enabled state can't be modified at runtime. An + immutable link is always enabled. + + + MEDIA_LNK_FL_DYNAMIC + The link enabled state can be modified during streaming. This + flag is set by drivers and is read-only for applications. + + + + + +
-- cgit v1.2.3 From eb7d970aa0ab9964fe3200df4daf76c37d35f076 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Sat, 12 Dec 2015 10:29:30 -0200 Subject: [media] Docbook: media-types.xml: update the existing tables There were some changes on the media types that were not reflected on the types tables. Update them to reflect the upstream changes. Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/media-types.xml | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) (limited to 'Documentation/DocBook') diff --git a/Documentation/DocBook/media/v4l/media-types.xml b/Documentation/DocBook/media/v4l/media-types.xml index 0c5c9c034586..4a6038301e06 100644 --- a/Documentation/DocBook/media/v4l/media-types.xml +++ b/Documentation/DocBook/media/v4l/media-types.xml @@ -33,7 +33,7 @@ Digital TV demodulator entity. - MEDIA_ENT_F_MPEG_TS_DEMUX + MEDIA_ENT_F_TS_DEMUX MPEG Transport stream demux entity. Could be implemented on hardware or in Kernelspace by the Linux DVB subsystem. @@ -101,6 +101,10 @@ Default entity for its type. Used to discover the default audio, VBI and video devices, the default camera sensor, ... + + MEDIA_ENT_FL_CONNECTOR + The entity represents a data conector + @@ -159,6 +163,15 @@ The link enabled state can be modified during streaming. This flag is set by drivers and is read-only for applications. + + MEDIA_LNK_FL_LINK_TYPE + This is a bitmask that defines the type of the link. + Currently, two types of links are supported: + MEDIA_LNK_FL_DATA_LINK + if the link is between two pads + MEDIA_LNK_FL_INTERFACE_LINK + if the link is between an interface and an entity + -- cgit v1.2.3 From dc7339bf119111d5c08156980ea742fc4120ce19 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Sat, 12 Dec 2015 10:54:45 -0200 Subject: [media] DocBook: add a table for Media Controller interfaces Document the media controller interfaces at the media uAPI docbook. Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/media-types.xml | 61 +++++++++++++++++++++++++ 1 file changed, 61 insertions(+) (limited to 'Documentation/DocBook') diff --git a/Documentation/DocBook/media/v4l/media-types.xml b/Documentation/DocBook/media/v4l/media-types.xml index 4a6038301e06..1af384250910 100644 --- a/Documentation/DocBook/media/v4l/media-types.xml +++ b/Documentation/DocBook/media/v4l/media-types.xml @@ -109,6 +109,67 @@ + + Media interface types + + + + + + + MEDIA_INTF_T_DVB_FE + Device node interface for the Digital TV frontend + typically, /dev/dvb/adapter?/frontend? + + + MEDIA_INTF_T_DVB_DEMUX + Device node interface for the Digital TV demux + typically, /dev/dvb/adapter?/demux? + + + MEDIA_INTF_T_DVB_DVR + Device node interface for the Digital TV DVR + typically, /dev/dvb/adapter?/dvr? + + + MEDIA_INTF_T_DVB_CA + Device node interface for the Digital TV Conditional Access + typically, /dev/dvb/adapter?/ca? + + + MEDIA_INTF_T_DVB_FE + Device node interface for the Digital TV network control + typically, /dev/dvb/adapter?/net? + + + MEDIA_INTF_T_V4L_VIDEO + Device node interface for video (V4L) + typically, /dev/video? + + + MEDIA_INTF_T_V4L_VBI + Device node interface for VBI (V4L) + typically, /dev/vbi? + + + MEDIA_INTF_T_V4L_RADIO + Device node interface for radio (V4L) + typically, /dev/vbi? + + + MEDIA_INTF_T_V4L_SUBDEV + Device node interface for a V4L subdevice + typically, /dev/v4l-subdev? + + + MEDIA_INTF_T_V4L_SWRADIO + Device node interface for Software Defined Radio (V4L) + typically, /dev/swradio? + + + +
+ Media pad flags -- cgit v1.2.3 From 677cb4bfc23e7fd8f49d2d10af64f171942fab84 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Sat, 12 Dec 2015 10:56:13 -0200 Subject: [media] DocBook: Document MEDIA_IOC_G_TOPOLOGY Add description for this new media controller ioctl. Signed-off-by: Mauro Carvalho Chehab --- .../DocBook/media/v4l/media-controller.xml | 1 + .../DocBook/media/v4l/media-ioc-g-topology.xml | 391 +++++++++++++++++++++ 2 files changed, 392 insertions(+) create mode 100644 Documentation/DocBook/media/v4l/media-ioc-g-topology.xml (limited to 'Documentation/DocBook') diff --git a/Documentation/DocBook/media/v4l/media-controller.xml b/Documentation/DocBook/media/v4l/media-controller.xml index 63d48decaa6f..5f2fc07a93d7 100644 --- a/Documentation/DocBook/media/v4l/media-controller.xml +++ b/Documentation/DocBook/media/v4l/media-controller.xml @@ -98,6 +98,7 @@ &sub-media-func-ioctl; &sub-media-ioc-device-info; + &sub-media-ioc-g-topology; &sub-media-ioc-enum-entities; &sub-media-ioc-enum-links; &sub-media-ioc-setup-link; diff --git a/Documentation/DocBook/media/v4l/media-ioc-g-topology.xml b/Documentation/DocBook/media/v4l/media-ioc-g-topology.xml new file mode 100644 index 000000000000..e0d49fa329f0 --- /dev/null +++ b/Documentation/DocBook/media/v4l/media-ioc-g-topology.xml @@ -0,0 +1,391 @@ + + + ioctl MEDIA_IOC_G_TOPOLOGY + &manvol; + + + + MEDIA_IOC_G_TOPOLOGY + Enumerate the graph topology and graph element properties + + + + + + int ioctl + int fd + int request + struct media_v2_topology *argp + + + + + + Arguments + + + + fd + + File descriptor returned by + open(). + + + + request + + MEDIA_IOC_G_TOPOLOGY + + + + argp + + + + + + + + + Description + The typical usage of this ioctl is to call it twice. + On the first call, the structure defined at &media-v2-topology; should + be zeroed. At return, if no errors happen, this ioctl will return the + topology_version and the total number of entities, + interfaces, pads and links. + Before the second call, the userspace should allocate arrays to + store the graph elements that are desired, putting the pointers to them + at the ptr_entities, ptr_interfaces, ptr_links and/or ptr_pads, keeping + the other values untouched. + If the topology_version remains the same, the + ioctl should fill the desired arrays with the media graph elements. + +
+ struct <structname>media_v2_topology</structname> + + + + + + + + + __u64 + topology_version + + + Version of the media graph topology. When the graph is + created, this field starts with zero. Every time a graph + element is added or removed, this field is + incremented. + + + __u64 + num_entities + + + Number of entities in the graph + + + __u64 + ptr_entities + + + A pointer to a memory area where the entities array + will be stored, converted to a 64-bits integer. + It can be zero. if zero, the ioctl won't store the + entities. It will just update + num_entities + + + __u64 + num_interfaces + + + Number of interfaces in the graph + + + __u64 + ptr_interfaces + + + A pointer to a memory area where the interfaces array + will be stored, converted to a 64-bits integer. + It can be zero. if zero, the ioctl won't store the + interfaces. It will just update + num_interfaces + + + __u64 + num_pads + + + Total number of pads in the graph + + + __u64 + ptr_pads + + + A pointer to a memory area where the pads array + will be stored, converted to a 64-bits integer. + It can be zero. if zero, the ioctl won't store the + pads. It will just update + num_pads + + + __u64 + num_links + + + Total number of data and interface links in the graph + + + __u64 + ptr_links + + + A pointer to a memory area where the links array + will be stored, converted to a 64-bits integer. + It can be zero. if zero, the ioctl won't store the + links. It will just update + num_links + + + +
+ + + struct <structname>media_v2_entity</structname> + + + + + + + + + __u32 + id + + + Unique ID for the entity. + + + char + name[64] + + + Entity name as an UTF-8 NULL-terminated string. + + + __u32 + function + + + Entity main function, see for details. + + + __u32 + reserved[12] + Reserved for future extensions. Drivers and applications must + set this array to zero. + + + +
+ + + struct <structname>media_v2_interface</structname> + + + + + + + + + __u32 + id + + + Unique ID for the interface. + + + __u32 + intf_type + + + Interface type, see for details. + + + __u32 + flags + + + Interface flags. Currently unused. + + + __u32 + reserved[9] + + + Reserved for future extensions. Drivers and applications must + set this array to zero. + + + struct media_v2_intf_devnode + devnode + + + Used only for device node interfaces. See for details.. + + + +
+ + + struct <structname>media_v2_interface</structname> + + + + + + + + + __u32 + major + + + Device node major number. + + + __u32 + minor + + + Device node minor number. + + + +
+ + + struct <structname>media_v2_pad</structname> + + + + + + + + + __u32 + id + + + Unique ID for the pad. + + + __u32 + entity_id + + + Unique ID for the entity where this pad belongs. + + + __u32 + flags + + + Pad flags, see for more details. + + + __u32 + reserved[9] + + + Reserved for future extensions. Drivers and applications must + set this array to zero. + + + +
+ + + struct <structname>media_v2_pad</structname> + + + + + + + + + __u32 + id + + + Unique ID for the pad. + + + __u32 + source_id + + + + On pad to pad links: unique ID for the source pad. + On interface to entity links: unique ID for the interface. + + + + __u32 + sink_id + + + + On pad to pad links: unique ID for the sink pad. + On interface to entity links: unique ID for the entity. + + + + __u32 + flags + + + Link flags, see for more details. + + + __u32 + reserved[5] + + + Reserved for future extensions. Drivers and applications must + set this array to zero. + + + + + + + + + &return-value; + + + + ENOSPC + + This is returned when either one or more of the num_entities, + num_interfaces, num_links or num_pads are non-zero and are smaller + than the actual number of elements inside the graph. This may happen + if the topology_version changed when compared + to the last time this ioctl was called. Userspace should usually + free the area for the pointers, zero the struct elements and call + this ioctl again. + + + + + -- cgit v1.2.3 From be0270ec89e6b9b49de7e533dd1f3a89ad34d205 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Mon, 28 Dec 2015 12:03:47 -0200 Subject: [media] Postpone the addition of MEDIA_IOC_G_TOPOLOGY There are a few discussions left with regards to this ioctl: 1) the name of the new structs will contain _v2_ on it? 2) what's the best alternative to avoid compat32 issues? Due to that, let's postpone the addition of this new ioctl to the next Kernel version, to give people more time to discuss it. Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/media-ioc-g-topology.xml | 3 +++ drivers/media/media-device.c | 7 ++++++- include/uapi/linux/media.h | 6 +++++- 3 files changed, 14 insertions(+), 2 deletions(-) (limited to 'Documentation/DocBook') diff --git a/Documentation/DocBook/media/v4l/media-ioc-g-topology.xml b/Documentation/DocBook/media/v4l/media-ioc-g-topology.xml index e0d49fa329f0..63152ab9efba 100644 --- a/Documentation/DocBook/media/v4l/media-ioc-g-topology.xml +++ b/Documentation/DocBook/media/v4l/media-ioc-g-topology.xml @@ -48,6 +48,9 @@ Description + + NOTE: This new ioctl is programmed to be added on Kernel 4.6. Its definition/arguments may change until its final version. + The typical usage of this ioctl is to call it twice. On the first call, the structure defined at &media-v2-topology; should be zeroed. At return, if no errors happen, this ioctl will return the diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c index 4d1c13de494b..7dae0ac0f3ae 100644 --- a/drivers/media/media-device.c +++ b/drivers/media/media-device.c @@ -234,6 +234,7 @@ static long media_device_setup_link(struct media_device *mdev, return ret; } +#if 0 /* Let's postpone it to Kernel 4.6 */ static long __media_device_get_topology(struct media_device *mdev, struct media_v2_topology *topo) { @@ -389,6 +390,7 @@ static long media_device_get_topology(struct media_device *mdev, return 0; } +#endif static long media_device_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) @@ -422,13 +424,14 @@ static long media_device_ioctl(struct file *filp, unsigned int cmd, mutex_unlock(&dev->graph_mutex); break; +#if 0 /* Let's postpone it to Kernel 4.6 */ case MEDIA_IOC_G_TOPOLOGY: mutex_lock(&dev->graph_mutex); ret = media_device_get_topology(dev, (struct media_v2_topology __user *)arg); mutex_unlock(&dev->graph_mutex); break; - +#endif default: ret = -ENOIOCTLCMD; } @@ -477,7 +480,9 @@ static long media_device_compat_ioctl(struct file *filp, unsigned int cmd, case MEDIA_IOC_DEVICE_INFO: case MEDIA_IOC_ENUM_ENTITIES: case MEDIA_IOC_SETUP_LINK: +#if 0 /* Let's postpone it to Kernel 4.6 */ case MEDIA_IOC_G_TOPOLOGY: +#endif return media_device_ioctl(filp, cmd, arg); case MEDIA_IOC_ENUM_LINKS32: diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h index 5dbb208e5451..1e3c8cb43bd7 100644 --- a/include/uapi/linux/media.h +++ b/include/uapi/linux/media.h @@ -286,7 +286,7 @@ struct media_links_enum { * later, before the adding this API upstream. */ - +#if 0 /* Let's postpone it to Kernel 4.6 */ struct media_v2_entity { __u32 id; char name[64]; /* FIXME: move to a property? (RFC says so) */ @@ -351,6 +351,7 @@ static inline void __user *media_get_uptr(__u64 arg) { return (void __user *)(uintptr_t)arg; } +#endif /* ioctls */ @@ -358,6 +359,9 @@ static inline void __user *media_get_uptr(__u64 arg) #define MEDIA_IOC_ENUM_ENTITIES _IOWR('|', 0x01, struct media_entity_desc) #define MEDIA_IOC_ENUM_LINKS _IOWR('|', 0x02, struct media_links_enum) #define MEDIA_IOC_SETUP_LINK _IOWR('|', 0x03, struct media_link_desc) + +#if 0 /* Let's postpone it to Kernel 4.6 */ #define MEDIA_IOC_G_TOPOLOGY _IOWR('|', 0x04, struct media_v2_topology) +#endif #endif /* __LINUX_MEDIA_H */ -- cgit v1.2.3