summaryrefslogtreecommitdiffstats
path: root/drivers/media
diff options
context:
space:
mode:
authorMauro Carvalho Chehab <mchehab@osg.samsung.com>2015-10-05 15:10:55 -0300
committerMauro Carvalho Chehab <mchehab@osg.samsung.com>2015-10-06 18:40:02 -0300
commit95abfdb942a44e165c54a4e890a9b91a1eeb8621 (patch)
treedf9d0cdd73e21b4934ca0bc656a158f2226b6f0b /drivers/media
parentbdbbf13e0434ab82d700693ff19182013aaa09dd (diff)
downloadlinux-stable-95abfdb942a44e165c54a4e890a9b91a1eeb8621.tar.gz
linux-stable-95abfdb942a44e165c54a4e890a9b91a1eeb8621.tar.bz2
linux-stable-95abfdb942a44e165c54a4e890a9b91a1eeb8621.zip
[media] DocBook: Move struct dmx_demux kABI doc to demux.h
The DocBook/media/dvb/kdapi.xml contains the description of the kABI for DVB. The problem is that, by being maintained on a separate file and not being updated for years, it got outdated. So, for example, some callback parameters were changed, but the DocBook were still using the old stuff. As a first step to fix it, let's move the documentation of struct dmx_demux into demux.h and fix the parameters used there. For now, don't document any other field nor touch the descriptions that got moved, letting this job to other patches. That makes easier to review the patch. PS.: Please notice that an additional patch will be needed in order to fix the return values (some uses non-existent return codes) and to the functions and callbacks mentioned at the descriptions. Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Diffstat (limited to 'drivers/media')
-rw-r--r--drivers/media/dvb-core/demux.h193
1 files changed, 190 insertions, 3 deletions
diff --git a/drivers/media/dvb-core/demux.h b/drivers/media/dvb-core/demux.h
index 833191bcd810..54c3df38bb1b 100644
--- a/drivers/media/dvb-core/demux.h
+++ b/drivers/media/dvb-core/demux.h
@@ -202,10 +202,197 @@ struct dmx_frontend {
#define DMX_FE_ENTRY(list) list_entry(list, struct dmx_frontend, connectivity_list)
+/**
+ * struct dmx_demux - Structure that contains the demux capabilities and
+ * callbacks.
+ *
+ * @capabilities: Bitfield of capability flags
+ *
+ * @frontend: Front-end connected to the demux
+ *
+ * @priv: Pointer to private data of the API client
+ *
+ * @open: This function reserves the demux for use by the caller and, if
+ * necessary, initializes the demux. When the demux is no longer needed,
+ * the function close() should be called. It should be possible for
+ * multiple clients to access the demux at the same time. Thus, the
+ * function implementation should increment the demux usage count when
+ * open() is called and decrement it when close() is called.
+ * The @demux function parameter contains a pointer to the demux API and
+ * instance data.
+ * It returns
+ * 0 on success;
+ * -EUSERS, if maximum usage count was reached;
+ * -EINVAL, on bad parameter.
+ *
+ * @close: This function reserves the demux for use by the caller and, if
+ * necessary, initializes the demux. When the demux is no longer needed,
+ * the function close() should be called. It should be possible for
+ * multiple clients to access the demux at the same time. Thus, the
+ * function implementation should increment the demux usage count when
+ * open() is called and decrement it when close() is called.
+ * The @demux function parameter contains a pointer to the demux API and
+ * instance data.
+ * It returns
+ * 0 on success;
+ * -ENODEV, if demux was not in use
+ * -EINVAL, on bad parameter.
+ *
+ * @write: This function provides the demux driver with a memory buffer
+ * containing TS packets. Instead of receiving TS packets from the DVB
+ * front-end, the demux driver software will read packets from memory.
+ * Any clients of this demux with active TS, PES or Section filters will
+ * receive filtered data via the Demux callback API (see 0). The function
+ * returns when all the data in the buffer has been consumed by the demux.
+ * Demux hardware typically cannot read TS from memory. If this is the
+ * case, memory-based filtering has to be implemented entirely in software.
+ * The @demux function parameter contains a pointer to the demux API and
+ * instance data.
+ * The @buf function parameter contains a pointer to the TS data in
+ * kernel-space memory.
+ * The @count function parameter contains the length of the TS data.
+ * It returns
+ * 0 on success;
+ * -ENOSYS, if the command is not implemented;
+ * -EINVAL, on bad parameter.
+ *
+ * @allocate_ts_feed: Allocates a new TS feed, which is used to filter the TS
+ * packets carrying a certain PID. The TS feed normally corresponds to a
+ * hardware PID filter on the demux chip.
+ * The @demux function parameter contains a pointer to the demux API and
+ * instance data.
+ * The @feed function parameter contains a pointer to the TS feed API and
+ * instance data.
+ * The @callback function parameter contains a pointer to the callback
+ * function for passing received TS packet.
+ * It returns
+ * 0 on success;
+ * -EBUSY, if no more TS feeds is available;
+ * -ENOSYS, if the command is not implemented;
+ * -EINVAL, on bad parameter.
+ *
+ * @release_ts_feed: Releases the resources allocated with allocate_ts_feed().
+ * Any filtering in progress on the TS feed should be stopped before
+ * calling this function.
+ * The @demux function parameter contains a pointer to the demux API and
+ * instance data.
+ * The @feed function parameter contains a pointer to the TS feed API and
+ * instance data.
+ * It returns
+ * 0 on success;
+ * -EINVAL on bad parameter.
+ *
+ * @allocate_section_feed: Allocates a new section feed, i.e. a demux resource
+ * for filtering and receiving sections. On platforms with hardware
+ * support for section filtering, a section feed is directly mapped to
+ * the demux HW. On other platforms, TS packets are first PID filtered in
+ * hardware and a hardware section filter then emulated in software. The
+ * caller obtains an API pointer of type dmx_section_feed_t as an out
+ * parameter. Using this API the caller can set filtering parameters and
+ * start receiving sections.
+ * The @demux function parameter contains a pointer to the demux API and
+ * instance data.
+ * The @feed function parameter contains a pointer to the TS feed API and
+ * instance data.
+ * The @callback function parameter contains a pointer to the callback
+ * function for passing received TS packet.
+ * It returns
+ * 0 on success;
+ * -EBUSY, if no more TS feeds is available;
+ * -ENOSYS, if the command is not implemented;
+ * -EINVAL, on bad parameter.
+ *
+ * @release_section_feed: Releases the resources allocated with
+ * allocate_section_feed(), including allocated filters. Any filtering in
+ * progress on the section feed should be stopped before calling this
+ * function.
+ * The @demux function parameter contains a pointer to the demux API and
+ * instance data.
+ * The @feed function parameter contains a pointer to the TS feed API and
+ * instance data.
+ * It returns
+ * 0 on success;
+ * -EINVAL, on bad parameter.
+ *
+ * @add_frontend: Registers a connectivity between a demux and a front-end,
+ * i.e., indicates that the demux can be connected via a call to
+ * connect_frontend() to use the given front-end as a TS source. The
+ * client of this function has to allocate dynamic or static memory for
+ * the frontend structure and initialize its fields before calling this
+ * function. This function is normally called during the driver
+ * initialization. The caller must not free the memory of the frontend
+ * struct before successfully calling remove_frontend().
+ * The @demux function parameter contains a pointer to the demux API and
+ * instance data.
+ * The @frontend function parameter contains a pointer to the front-end
+ * instance data.
+ * It returns
+ * 0 on success;
+ * -EEXIST, if a front-end with the same value of the id field
+ * already registered;
+ * -EINUSE, if the demux is in use;
+ * -ENOMEM, if no more front-ends can be added;
+ * -EINVAL, on bad parameter.
+ *
+ * @remove_frontend: Indicates that the given front-end, registered by a call
+ * to add_frontend(), can no longer be connected as a TS source by this
+ * demux. The function should be called when a front-end driver or a demux
+ * driver is removed from the system. If the front-end is in use, the
+ * function fails with the return value of -EBUSY. After successfully
+ * calling this function, the caller can free the memory of the frontend
+ * struct if it was dynamically allocated before the add_frontend()
+ * operation.
+ * The @demux function parameter contains a pointer to the demux API and
+ * instance data.
+ * The @frontend function parameter contains a pointer to the front-end
+ * instance data.
+ * It returns
+ * 0 on success;
+ * -EBUSY, if the front-end is in use, i.e. a call to
+ * connect_frontend() has not been followed by a call to
+ * disconnect_frontend();
+ * -EINVAL, on bad parameter.
+ *
+ * @get_frontends: Provides the APIs of the front-ends that have been
+ * registered for this demux. Any of the front-ends obtained with this
+ * call can be used as a parameter for connect_frontend(). The include
+ * file demux.h contains the macro DMX_FE_ENTRY() for converting an
+ * element of the generic type struct list_head* to the type
+ * dmx_frontend_t*. The caller must not free the memory of any of the
+ * elements obtained via this function call.
+ * The @demux function parameter contains a pointer to the demux API and
+ * instance data.
+ * It returns a struct list_head pointer to the list of front-end
+ * interfaces, or NULL in the case of an empty list.
+ *
+ * @connect_frontend: Connects the TS output of the front-end to the input of
+ * the demux. A demux can only be connected to a front-end registered to
+ * the demux with the function add_frontend(). It may or may not be
+ * possible to connect multiple demuxes to the same front-end, depending
+ * on the capabilities of the HW platform. When not used, the front-end
+ * should be released by calling disconnect_frontend().
+ * The @demux function parameter contains a pointer to the demux API and
+ * instance data.
+ * The @frontend function parameter contains a pointer to the front-end
+ * instance data.
+ * It returns
+ * 0 on success;
+ * -EBUSY, if the front-end is in use;
+ * -EINVAL, on bad parameter.
+ *
+ * @disconnect_frontend: Disconnects the demux and a front-end previously
+ * connected by a connect_frontend() call.
+ * The @demux function parameter contains a pointer to the demux API and
+ * instance data.
+ * It returns
+ * 0 on success;
+ * -EINVAL on bad parameter.
+ */
+
struct dmx_demux {
- u32 capabilities; /* Bitfield of capability flags */
- struct dmx_frontend* frontend; /* Front-end connected to the demux */
- void* priv; /* Pointer to private data of the API client */
+ u32 capabilities;
+ struct dmx_frontend* frontend;
+ void* priv;
int (*open) (struct dmx_demux* demux);
int (*close) (struct dmx_demux* demux);
int (*write) (struct dmx_demux* demux, const char __user *buf, size_t count);