dect
/
linux-2.6
Archived
13
0
Fork 0

Merge branch 'staging/for_v3.7' into v4l_for_linus

* staging/for_v3.7: (2891 commits)
  em28xx: regression fix: use DRX-K sync firmware requests on em28xx
  drxk: allow loading firmware synchrousnously
  em28xx: Make all em28xx extensions to be initialized asynchronously
  [media] tda18271: properly report read errors in tda18271_get_id
  [media] tda18271: delay IR & RF calibration until init() if delay_cal is set
  [media] MAINTAINERS: add Michael Krufky as tda827x maintainer
  [media] MAINTAINERS: add Michael Krufky as tda8290 maintainer
  [media] MAINTAINERS: add Michael Krufky as cxusb maintainer
  [media] MAINTAINERS: add Michael Krufky as lg2160 maintainer
  [media] MAINTAINERS: add Michael Krufky as lgdt3305 maintainer
  [media] MAINTAINERS: add Michael Krufky as mxl111sf maintainer
  [media] MAINTAINERS: add Michael Krufky as mxl5007t maintainer
  [media] MAINTAINERS: add Michael Krufky as tda18271 maintainer
  [media] s5p-tv: Report only multi-plane capabilities in vidioc_querycap
  [media] s5p-mfc: Fix misplaced return statement in s5p_mfc_suspend()
  [media] exynos-gsc: Add missing static storage class specifiers
  [media] exynos-gsc: Remove <linux/version.h> header file inclusion
  [media] s5p-fimc: Fix incorrect condition in fimc_lite_reqbufs()
  [media] s5p-tv: Fix potential NULL pointer dereference error
  [media] s5k6aa: Fix possible NULL pointer dereference
  ...

Conflicts:
	drivers/media/platform/s5p-fimc/fimc-capture.c
	drivers/media/platform/s5p-fimc/fimc-lite.c
This commit is contained in:
Mauro Carvalho Chehab 2012-10-05 09:36:26 -03:00
commit bd0d104988
3775 changed files with 78434 additions and 45150 deletions

View File

@ -0,0 +1,5 @@
What: /proc/sys/vm/nr_pdflush_threads
Date: June 2012
Contact: Wanpeng Li <liwp@linux.vnet.ibm.com>
Description: Since pdflush is replaced by per-BDI flusher, the interface of old pdflush
exported in /proc/sys/vm/ should be removed.

View File

@ -210,3 +210,15 @@ Users:
firmware assigned instance number of the PCI
device that can help in understanding the firmware
intended order of the PCI device.
What: /sys/bus/pci/devices/.../d3cold_allowed
Date: July 2012
Contact: Huang Ying <ying.huang@intel.com>
Description:
d3cold_allowed is bit to control whether the corresponding PCI
device can be put into D3Cold state. If it is cleared, the
device will never be put into D3Cold state. If it is set, the
device may be put into D3Cold state if other requirements are
satisfied too. Reading this attribute will show the current
value of d3cold_allowed bit. Writing this attribute will set
the value of d3cold_allowed bit.

View File

@ -0,0 +1,44 @@
What: /sys/devices/platform/sh_mobile_lcdc_fb.[0-3]/graphics/fb[0-9]/ovl_alpha
Date: May 2012
Contact: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Description:
This file is only available on fb[0-9] devices corresponding
to overlay planes.
Stores the alpha blending value for the overlay. Values range
from 0 (transparent) to 255 (opaque). The value is ignored if
the mode is not set to Alpha Blending.
What: /sys/devices/platform/sh_mobile_lcdc_fb.[0-3]/graphics/fb[0-9]/ovl_mode
Date: May 2012
Contact: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Description:
This file is only available on fb[0-9] devices corresponding
to overlay planes.
Selects the composition mode for the overlay. Possible values
are
0 - Alpha Blending
1 - ROP3
What: /sys/devices/platform/sh_mobile_lcdc_fb.[0-3]/graphics/fb[0-9]/ovl_position
Date: May 2012
Contact: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Description:
This file is only available on fb[0-9] devices corresponding
to overlay planes.
Stores the x,y overlay position on the display in pixels. The
position format is `[0-9]+,[0-9]+'.
What: /sys/devices/platform/sh_mobile_lcdc_fb.[0-3]/graphics/fb[0-9]/ovl_rop3
Date: May 2012
Contact: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Description:
This file is only available on fb[0-9] devices corresponding
to overlay planes.
Stores the raster operation (ROP3) for the overlay. Values
range from 0 to 255. The value is ignored if the mode is not
set to ROP3.

View File

@ -5,4 +5,15 @@ Contact: "Ike Panhc <ike.pan@canonical.com>"
Description:
Control the power of camera module. 1 means on, 0 means off.
What: /sys/devices/platform/ideapad/fan_mode
Date: June 2012
KernelVersion: 3.6
Contact: "Maxim Mikityanskiy <maxtram95@gmail.com>"
Description:
Change fan mode
There are four available modes:
* 0 -> Super Silent Mode
* 1 -> Standard Mode
* 2 -> Dust Cleaning
* 4 -> Efficient Thermal Dissipation Mode

View File

@ -224,8 +224,8 @@ all your transactions.
</para>
<para>
Then at umount time , in your put_super() (2.4) or write_super() (2.5)
you can then call journal_destroy() to clean up your in-core journal object.
Then at umount time , in your put_super() you can then call journal_destroy()
to clean up your in-core journal object.
</para>
<para>

View File

@ -300,7 +300,7 @@ $(MEDIA_OBJ_DIR)/media-entities.tmpl: $(MEDIA_OBJ_DIR)/v4l2.xml
@( \
for ident in $(IOCTLS) ; do \
entity=`echo $$ident | tr _ -` ; \
id=`grep "<refname>$$ident" $(MEDIA_OBJ_DIR)/vidioc-*.xml | sed -r s,"^.*/(.*).xml.*","\1",` ; \
id=`grep "<refname>$$ident" $(MEDIA_OBJ_DIR)/vidioc-*.xml $(MEDIA_OBJ_DIR)/media-ioc-*.xml | sed -r s,"^.*/(.*).xml.*","\1",` ; \
echo "<!ENTITY $$entity \"<link" \
"linkend='$$id'><constant>$$ident</constant></link>\">" \
>>$@ ; \

View File

@ -1,12 +1,16 @@
<title>DVB Audio Device</title>
<para>The DVB audio device controls the MPEG2 audio decoder of the DVB hardware. It
can be accessed through <emphasis role="tt">/dev/dvb/adapter0/audio0</emphasis>. Data types and and
ioctl definitions can be accessed by including <emphasis role="tt">linux/dvb/video.h</emphasis> in your
ioctl definitions can be accessed by including <emphasis role="tt">linux/dvb/audio.h</emphasis> in your
application.
</para>
<para>Please note that some DVB cards don&#8217;t have their own MPEG decoder, which results in
the omission of the audio and video device.
</para>
<para>
These ioctls were also used by V4L2 to control MPEG decoders implemented in V4L2. The use
of these ioctls for that purpose has been made obsolete and proper V4L2 ioctls or controls
have been created to replace that functionality.</para>
<section id="audio_data_types">
<title>Audio Data Types</title>
@ -558,6 +562,8 @@ role="subsection"><title>AUDIO_SELECT_SOURCE</title>
role="subsection"><title>AUDIO_SET_MUTE</title>
<para>DESCRIPTION
</para>
<para>This ioctl is for DVB devices only. To control a V4L2 decoder use the V4L2
&VIDIOC-DECODER-CMD; with the <constant>V4L2_DEC_CMD_START_MUTE_AUDIO</constant> flag instead.</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl call asks the audio device to mute the stream that is currently being
@ -730,6 +736,8 @@ role="subsection"><title>AUDIO_SET_BYPASS_MODE</title>
role="subsection"><title>AUDIO_CHANNEL_SELECT</title>
<para>DESCRIPTION
</para>
<para>This ioctl is for DVB devices only. To control a V4L2 decoder use the V4L2
<constant>V4L2_CID_MPEG_AUDIO_DEC_PLAYBACK</constant> control instead.</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl call asks the Audio Device to select the requested channel if possible.</para>
@ -772,6 +780,109 @@ role="subsection"><title>AUDIO_CHANNEL_SELECT</title>
</row></tbody></tgroup></informaltable>
&return-value-dvb;
</section><section id="AUDIO_BILINGUAL_CHANNEL_SELECT"
role="subsection"><title>AUDIO_BILINGUAL_CHANNEL_SELECT</title>
<para>DESCRIPTION
</para>
<para>This ioctl is obsolete. Do not use in new drivers. It has been replaced by
the V4L2 <constant>V4L2_CID_MPEG_AUDIO_DEC_MULTILINGUAL_PLAYBACK</constant> control
for MPEG decoders controlled through V4L2.</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl call asks the Audio Device to select the requested channel for bilingual streams if possible.</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>SYNOPSIS
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(int fd, int request =
AUDIO_BILINGUAL_CHANNEL_SELECT, audio_channel_select_t);</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>PARAMETERS
</para>
<informaltable><tgroup cols="2"><tbody><row><entry
align="char">
<para>int fd</para>
</entry><entry
align="char">
<para>File descriptor returned by a previous call to open().</para>
</entry>
</row><row><entry
align="char">
<para>int request</para>
</entry><entry
align="char">
<para>Equals AUDIO_BILINGUAL_CHANNEL_SELECT for this
command.</para>
</entry>
</row><row><entry
align="char">
<para>audio_channel_select_t
ch</para>
</entry><entry
align="char">
<para>Select the output format of the audio (mono left/right,
stereo).</para>
</entry>
</row>
</tbody></tgroup></informaltable>
&return-value-dvb;
</section><section id="AUDIO_GET_PTS"
role="subsection"><title>AUDIO_GET_PTS</title>
<para>DESCRIPTION
</para>
<para>This ioctl is obsolete. Do not use in new drivers. If you need this functionality,
then please contact the linux-media mailing list (&v4l-ml;).</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl call asks the Audio Device to return the current PTS timestamp.</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>SYNOPSIS
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(int fd, int request =
AUDIO_GET_PTS, __u64 *pts);</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>PARAMETERS
</para>
<informaltable><tgroup cols="2"><tbody><row><entry
align="char">
<para>int fd</para>
</entry><entry
align="char">
<para>File descriptor returned by a previous call to open().</para>
</entry>
</row><row><entry
align="char">
<para>int request</para>
</entry><entry
align="char">
<para>Equals AUDIO_GET_PTS for this
command.</para>
</entry>
</row><row><entry
align="char">
<para>__u64 *pts
</para>
</entry><entry
align="char">
<para>Returns the 33-bit timestamp as defined in ITU T-REC-H.222.0 / ISO/IEC 13818-1.
</para>
<para>
The PTS should belong to the currently played
frame if possible, but may also be a value close to it
like the PTS of the last decoded frame or the last PTS
extracted by the PES parser.</para>
</entry>
</row></tbody></tgroup></informaltable>
&return-value-dvb;
</section><section id="AUDIO_GET_STATUS"
role="subsection"><title>AUDIO_GET_STATUS</title>
<para>DESCRIPTION

View File

@ -226,4 +226,357 @@ typedef struct ca_pid {
</entry>
</row></tbody></tgroup></informaltable>
</section>
<section id="CA_RESET"
role="subsection"><title>CA_RESET</title>
<para>DESCRIPTION
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl is undocumented. Documentation is welcome.</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>SYNOPSIS
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(fd, int request = CA_RESET);
</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>PARAMETERS
</para>
<informaltable><tgroup cols="2"><tbody><row><entry
align="char">
<para>int fd</para>
</entry><entry
align="char">
<para>File descriptor returned by a previous call to open().</para>
</entry>
</row><row><entry
align="char">
<para>int request</para>
</entry><entry
align="char">
<para>Equals CA_RESET for this command.</para>
</entry>
</row></tbody></tgroup></informaltable>
&return-value-dvb;
</section>
<section id="CA_GET_CAP"
role="subsection"><title>CA_GET_CAP</title>
<para>DESCRIPTION
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl is undocumented. Documentation is welcome.</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>SYNOPSIS
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(fd, int request = CA_GET_CAP,
ca_caps_t *);</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>PARAMETERS
</para>
<informaltable><tgroup cols="2"><tbody><row><entry
align="char">
<para>int fd</para>
</entry><entry
align="char">
<para>File descriptor returned by a previous call to open().</para>
</entry>
</row><row><entry
align="char">
<para>int request</para>
</entry><entry
align="char">
<para>Equals CA_GET_CAP for this command.</para>
</entry>
</row><row><entry
align="char">
<para>ca_caps_t *
</para>
</entry><entry
align="char">
<para>Undocumented.</para>
</entry>
</row></tbody></tgroup></informaltable>
&return-value-dvb;
</section>
<section id="CA_GET_SLOT_INFO"
role="subsection"><title>CA_GET_SLOT_INFO</title>
<para>DESCRIPTION
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl is undocumented. Documentation is welcome.</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>SYNOPSIS
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(fd, int request = CA_GET_SLOT_INFO,
ca_slot_info_t *);</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>PARAMETERS
</para>
<informaltable><tgroup cols="2"><tbody><row><entry
align="char">
<para>int fd</para>
</entry><entry
align="char">
<para>File descriptor returned by a previous call to open().</para>
</entry>
</row><row><entry
align="char">
<para>int request</para>
</entry><entry
align="char">
<para>Equals CA_GET_SLOT_INFO for this command.</para>
</entry>
</row><row><entry
align="char">
<para>ca_slot_info_t *
</para>
</entry><entry
align="char">
<para>Undocumented.</para>
</entry>
</row></tbody></tgroup></informaltable>
&return-value-dvb;
</section>
<section id="CA_GET_DESCR_INFO"
role="subsection"><title>CA_GET_DESCR_INFO</title>
<para>DESCRIPTION
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl is undocumented. Documentation is welcome.</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>SYNOPSIS
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(fd, int request = CA_GET_DESCR_INFO,
ca_descr_info_t *);</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>PARAMETERS
</para>
<informaltable><tgroup cols="2"><tbody><row><entry
align="char">
<para>int fd</para>
</entry><entry
align="char">
<para>File descriptor returned by a previous call to open().</para>
</entry>
</row><row><entry
align="char">
<para>int request</para>
</entry><entry
align="char">
<para>Equals CA_GET_DESCR_INFO for this command.</para>
</entry>
</row><row><entry
align="char">
<para>ca_descr_info_t *
</para>
</entry><entry
align="char">
<para>Undocumented.</para>
</entry>
</row></tbody></tgroup></informaltable>
&return-value-dvb;
</section>
<section id="CA_GET_MSG"
role="subsection"><title>CA_GET_MSG</title>
<para>DESCRIPTION
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl is undocumented. Documentation is welcome.</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>SYNOPSIS
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(fd, int request = CA_GET_MSG,
ca_msg_t *);</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>PARAMETERS
</para>
<informaltable><tgroup cols="2"><tbody><row><entry
align="char">
<para>int fd</para>
</entry><entry
align="char">
<para>File descriptor returned by a previous call to open().</para>
</entry>
</row><row><entry
align="char">
<para>int request</para>
</entry><entry
align="char">
<para>Equals CA_GET_MSG for this command.</para>
</entry>
</row><row><entry
align="char">
<para>ca_msg_t *
</para>
</entry><entry
align="char">
<para>Undocumented.</para>
</entry>
</row></tbody></tgroup></informaltable>
&return-value-dvb;
</section>
<section id="CA_SEND_MSG"
role="subsection"><title>CA_SEND_MSG</title>
<para>DESCRIPTION
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl is undocumented. Documentation is welcome.</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>SYNOPSIS
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(fd, int request = CA_SEND_MSG,
ca_msg_t *);</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>PARAMETERS
</para>
<informaltable><tgroup cols="2"><tbody><row><entry
align="char">
<para>int fd</para>
</entry><entry
align="char">
<para>File descriptor returned by a previous call to open().</para>
</entry>
</row><row><entry
align="char">
<para>int request</para>
</entry><entry
align="char">
<para>Equals CA_SEND_MSG for this command.</para>
</entry>
</row><row><entry
align="char">
<para>ca_msg_t *
</para>
</entry><entry
align="char">
<para>Undocumented.</para>
</entry>
</row></tbody></tgroup></informaltable>
&return-value-dvb;
</section>
<section id="CA_SET_DESCR"
role="subsection"><title>CA_SET_DESCR</title>
<para>DESCRIPTION
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl is undocumented. Documentation is welcome.</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>SYNOPSIS
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(fd, int request = CA_SET_DESCR,
ca_descr_t *);</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>PARAMETERS
</para>
<informaltable><tgroup cols="2"><tbody><row><entry
align="char">
<para>int fd</para>
</entry><entry
align="char">
<para>File descriptor returned by a previous call to open().</para>
</entry>
</row><row><entry
align="char">
<para>int request</para>
</entry><entry
align="char">
<para>Equals CA_SET_DESCR for this command.</para>
</entry>
</row><row><entry
align="char">
<para>ca_descr_t *
</para>
</entry><entry
align="char">
<para>Undocumented.</para>
</entry>
</row></tbody></tgroup></informaltable>
&return-value-dvb;
</section>
<section id="CA_SET_PID"
role="subsection"><title>CA_SET_PID</title>
<para>DESCRIPTION
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl is undocumented. Documentation is welcome.</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>SYNOPSIS
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(fd, int request = CA_SET_PID,
ca_pid_t *);</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>PARAMETERS
</para>
<informaltable><tgroup cols="2"><tbody><row><entry
align="char">
<para>int fd</para>
</entry><entry
align="char">
<para>File descriptor returned by a previous call to open().</para>
</entry>
</row><row><entry
align="char">
<para>int request</para>
</entry><entry
align="char">
<para>Equals CA_SET_PID for this command.</para>
</entry>
</row><row><entry
align="char">
<para>ca_pid_t *
</para>
</entry><entry
align="char">
<para>Undocumented.</para>
</entry>
</row></tbody></tgroup></informaltable>
&return-value-dvb;
</section>
</section>

View File

@ -899,4 +899,232 @@ typedef enum {
<para>Invalid stc number.</para>
</entry>
</row></tbody></tgroup></informaltable>
</section></section>
</section>
<section id="DMX_GET_PES_PIDS"
role="subsection"><title>DMX_GET_PES_PIDS</title>
<para>DESCRIPTION
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl is undocumented. Documentation is welcome.</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>SYNOPSIS
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(fd, int request = DMX_GET_PES_PIDS,
__u16[5]);</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>PARAMETERS
</para>
<informaltable><tgroup cols="2"><tbody><row><entry
align="char">
<para>int fd</para>
</entry><entry
align="char">
<para>File descriptor returned by a previous call to open().</para>
</entry>
</row><row><entry
align="char">
<para>int request</para>
</entry><entry
align="char">
<para>Equals DMX_GET_PES_PIDS for this command.</para>
</entry>
</row><row><entry
align="char">
<para>__u16[5]
</para>
</entry><entry
align="char">
<para>Undocumented.</para>
</entry>
</row></tbody></tgroup></informaltable>
&return-value-dvb;
</section>
<section id="DMX_GET_CAPS"
role="subsection"><title>DMX_GET_CAPS</title>
<para>DESCRIPTION
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl is undocumented. Documentation is welcome.</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>SYNOPSIS
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(fd, int request = DMX_GET_CAPS,
dmx_caps_t *);</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>PARAMETERS
</para>
<informaltable><tgroup cols="2"><tbody><row><entry
align="char">
<para>int fd</para>
</entry><entry
align="char">
<para>File descriptor returned by a previous call to open().</para>
</entry>
</row><row><entry
align="char">
<para>int request</para>
</entry><entry
align="char">
<para>Equals DMX_GET_CAPS for this command.</para>
</entry>
</row><row><entry
align="char">
<para>dmx_caps_t *
</para>
</entry><entry
align="char">
<para>Undocumented.</para>
</entry>
</row></tbody></tgroup></informaltable>
&return-value-dvb;
</section>
<section id="DMX_SET_SOURCE"
role="subsection"><title>DMX_SET_SOURCE</title>
<para>DESCRIPTION
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl is undocumented. Documentation is welcome.</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>SYNOPSIS
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(fd, int request = DMX_SET_SOURCE,
dmx_source_t *);</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>PARAMETERS
</para>
<informaltable><tgroup cols="2"><tbody><row><entry
align="char">
<para>int fd</para>
</entry><entry
align="char">
<para>File descriptor returned by a previous call to open().</para>
</entry>
</row><row><entry
align="char">
<para>int request</para>
</entry><entry
align="char">
<para>Equals DMX_SET_SOURCE for this command.</para>
</entry>
</row><row><entry
align="char">
<para>dmx_source_t *
</para>
</entry><entry
align="char">
<para>Undocumented.</para>
</entry>
</row></tbody></tgroup></informaltable>
&return-value-dvb;
</section>
<section id="DMX_ADD_PID"
role="subsection"><title>DMX_ADD_PID</title>
<para>DESCRIPTION
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl is undocumented. Documentation is welcome.</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>SYNOPSIS
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(fd, int request = DMX_ADD_PID,
__u16 *);</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>PARAMETERS
</para>
<informaltable><tgroup cols="2"><tbody><row><entry
align="char">
<para>int fd</para>
</entry><entry
align="char">
<para>File descriptor returned by a previous call to open().</para>
</entry>
</row><row><entry
align="char">
<para>int request</para>
</entry><entry
align="char">
<para>Equals DMX_ADD_PID for this command.</para>
</entry>
</row><row><entry
align="char">
<para>__u16 *
</para>
</entry><entry
align="char">
<para>Undocumented.</para>
</entry>
</row></tbody></tgroup></informaltable>
&return-value-dvb;
</section>
<section id="DMX_REMOVE_PID"
role="subsection"><title>DMX_REMOVE_PID</title>
<para>DESCRIPTION
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl is undocumented. Documentation is welcome.</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>SYNOPSIS
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(fd, int request = DMX_REMOVE_PID,
__u16 *);</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>PARAMETERS
</para>
<informaltable><tgroup cols="2"><tbody><row><entry
align="char">
<para>int fd</para>
</entry><entry
align="char">
<para>File descriptor returned by a previous call to open().</para>
</entry>
</row><row><entry
align="char">
<para>int request</para>
</entry><entry
align="char">
<para>Equals DMX_REMOVE_PID for this command.</para>
</entry>
</row><row><entry
align="char">
<para>__u16 *
</para>
</entry><entry
align="char">
<para>Undocumented.</para>
</entry>
</row></tbody></tgroup></informaltable>
&return-value-dvb;
</section>
</section>

View File

@ -28,7 +28,7 @@
<holder>Convergence GmbH</holder>
</copyright>
<copyright>
<year>2009-2011</year>
<year>2009-2012</year>
<holder>Mauro Carvalho Chehab</holder>
</copyright>
@ -84,7 +84,7 @@ Added ISDB-T test originally written by Patrick Boettcher
<title>LINUX DVB API</title>
<subtitle>Version 5.2</subtitle>
<subtitle>Version 5.8</subtitle>
<!-- ADD THE CHAPTERS HERE -->
<chapter id="dvb_introdution">
&sub-intro;

View File

@ -194,6 +194,7 @@ get/set up to 64 properties. The actual meaning of each property is described on
APSK_16,
APSK_32,
DQPSK,
QAM_4_NR,
} fe_modulation_t;
</programlisting>
</section>
@ -265,6 +266,7 @@ typedef enum fe_code_rate {
FEC_AUTO,
FEC_3_5,
FEC_9_10,
FEC_2_5,
} fe_code_rate_t;
</programlisting>
<para>which correspond to error correction rates of 1/2, 2/3, etc.,
@ -351,7 +353,7 @@ typedef enum fe_delivery_system {
SYS_ISDBC,
SYS_ATSC,
SYS_ATSCMH,
SYS_DMBTH,
SYS_DTMB,
SYS_CMMB,
SYS_DAB,
SYS_DVBT2,
@ -567,28 +569,33 @@ typedef enum fe_delivery_system {
<title><constant>DTV_ATSCMH_RS_FRAME_MODE</constant></title>
<para>RS frame mode.</para>
<para>Possible values are:</para>
<para id="atscmh-rs-frame-mode">
<programlisting>
typedef enum atscmh_rs_frame_mode {
ATSCMH_RSFRAME_PRI_ONLY = 0,
ATSCMH_RSFRAME_PRI_SEC = 1,
} atscmh_rs_frame_mode_t;
</programlisting>
</para>
</section>
<section id="DTV-ATSCMH-RS-FRAME-ENSEMBLE">
<title><constant>DTV_ATSCMH_RS_FRAME_ENSEMBLE</constant></title>
<para>RS frame ensemble.</para>
<para>Possible values are:</para>
<para id="atscmh-rs-frame-ensemble">
<programlisting>
typedef enum atscmh_rs_frame_ensemble {
ATSCMH_RSFRAME_ENS_PRI = 0,
ATSCMH_RSFRAME_ENS_SEC = 1,
} atscmh_rs_frame_ensemble_t;
</programlisting>
</para>
</section>
<section id="DTV-ATSCMH-RS-CODE-MODE-PRI">
<title><constant>DTV_ATSCMH_RS_CODE_MODE_PRI</constant></title>
<para>RS code mode (primary).</para>
<para>Possible values are:</para>
<para id="atscmh-rs-code-mode">
<programlisting>
typedef enum atscmh_rs_code_mode {
ATSCMH_RSCODE_211_187 = 0,
@ -596,6 +603,7 @@ typedef enum atscmh_rs_code_mode {
ATSCMH_RSCODE_235_187 = 2,
} atscmh_rs_code_mode_t;
</programlisting>
</para>
</section>
<section id="DTV-ATSCMH-RS-CODE-MODE-SEC">
<title><constant>DTV_ATSCMH_RS_CODE_MODE_SEC</constant></title>
@ -613,23 +621,27 @@ typedef enum atscmh_rs_code_mode {
<title><constant>DTV_ATSCMH_SCCC_BLOCK_MODE</constant></title>
<para>Series Concatenated Convolutional Code Block Mode.</para>
<para>Possible values are:</para>
<para id="atscmh-sccc-block-mode">
<programlisting>
typedef enum atscmh_sccc_block_mode {
ATSCMH_SCCC_BLK_SEP = 0,
ATSCMH_SCCC_BLK_COMB = 1,
} atscmh_sccc_block_mode_t;
</programlisting>
</para>
</section>
<section id="DTV-ATSCMH-SCCC-CODE-MODE-A">
<title><constant>DTV_ATSCMH_SCCC_CODE_MODE_A</constant></title>
<para>Series Concatenated Convolutional Code Rate.</para>
<para>Possible values are:</para>
<para id="atscmh-sccc-code-mode">
<programlisting>
typedef enum atscmh_sccc_code_mode {
ATSCMH_SCCC_CODE_HLF = 0,
ATSCMH_SCCC_CODE_QTR = 1,
} atscmh_sccc_code_mode_t;
</programlisting>
</para>
</section>
<section id="DTV-ATSCMH-SCCC-CODE-MODE-B">
<title><constant>DTV_ATSCMH_SCCC_CODE_MODE_B</constant></title>
@ -725,6 +737,9 @@ typedef enum fe_guard_interval {
GUARD_INTERVAL_1_128,
GUARD_INTERVAL_19_128,
GUARD_INTERVAL_19_256,
GUARD_INTERVAL_PN420,
GUARD_INTERVAL_PN595,
GUARD_INTERVAL_PN945,
} fe_guard_interval_t;
</programlisting>
@ -733,6 +748,7 @@ typedef enum fe_guard_interval {
try to find the correct guard interval (if capable) and will use TMCC to fill
in the missing parameters.</para>
<para>2) Intervals 1/128, 19/128 and 19/256 are used only for DVB-T2 at present</para>
<para>3) DTMB specifies PN420, PN595 and PN945.</para>
</section>
<section id="DTV-TRANSMISSION-MODE">
<title><constant>DTV_TRANSMISSION_MODE</constant></title>
@ -749,6 +765,8 @@ typedef enum fe_transmit_mode {
TRANSMISSION_MODE_1K,
TRANSMISSION_MODE_16K,
TRANSMISSION_MODE_32K,
TRANSMISSION_MODE_C1,
TRANSMISSION_MODE_C3780,
} fe_transmit_mode_t;
</programlisting>
<para>Notes:</para>
@ -760,6 +778,7 @@ typedef enum fe_transmit_mode {
use TMCC to fill in the missing parameters.</para>
<para>3) DVB-T specifies 2K and 8K as valid sizes.</para>
<para>4) DVB-T2 specifies 1K, 2K, 4K, 8K, 16K and 32K.</para>
<para>5) DTMB specifies C1 and C3780.</para>
</section>
<section id="DTV-HIERARCHY">
<title><constant>DTV_HIERARCHY</constant></title>
@ -774,17 +793,28 @@ typedef enum fe_hierarchy {
} fe_hierarchy_t;
</programlisting>
</section>
<section id="DTV-ISDBS-TS-ID">
<title><constant>DTV_ISDBS_TS_ID</constant></title>
<para>Currently unused.</para>
<section id="DTV-STREAM-ID">
<title><constant>DTV_STREAM_ID</constant></title>
<para>DVB-S2, DVB-T2 and ISDB-S support the transmission of several
streams on a single transport stream.
This property enables the DVB driver to handle substream filtering,
when supported by the hardware.
By default, substream filtering is disabled.
</para><para>
For DVB-S2 and DVB-T2, the valid substream id range is from 0 to 255.
</para><para>
For ISDB, the valid substream id range is from 1 to 65535.
</para><para>
To disable it, you should use the special macro NO_STREAM_ID_FILTER.
</para><para>
Note: any value outside the id range also disables filtering.
</para>
</section>
<section id="DTV-DVBT2-PLP-ID">
<title><constant>DTV_DVBT2_PLP_ID</constant></title>
<para>DVB-T2 supports Physical Layer Pipes (PLP) to allow transmission of
many data types via a single multiplex. The API will soon support this
at which point this section will be expanded.</para>
<section id="DTV-DVBT2-PLP-ID-LEGACY">
<title><constant>DTV_DVBT2_PLP_ID_LEGACY</constant></title>
<para>Obsolete, replaced with DTV_STREAM_ID.</para>
</section>
<section id="DTV_ENUM_DELSYS">
<section id="DTV-ENUM-DELSYS">
<title><constant>DTV_ENUM_DELSYS</constant></title>
<para>A Multi standard frontend needs to advertise the delivery systems provided.
Applications need to enumerate the provided delivery systems, before using
@ -796,6 +826,29 @@ typedef enum fe_hierarchy {
FE_GET_INFO. In the case of a legacy frontend, the result is just the same
as with FE_GET_INFO, but in a more structured format </para>
</section>
<section id="DTV-INTERLEAVING">
<title><constant>DTV_INTERLEAVING</constant></title>
<para id="fe-interleaving">Interleaving mode</para>
<programlisting>
enum fe_interleaving {
INTERLEAVING_NONE,
INTERLEAVING_AUTO,
INTERLEAVING_240,
INTERLEAVING_720,
};
</programlisting>
</section>
<section id="DTV-LNA">
<title><constant>DTV_LNA</constant></title>
<para>Low-noise amplifier.</para>
<para>Hardware might offer controllable LNA which can be set manually
using that parameter. Usually LNA could be found only from
terrestrial devices if at all.</para>
<para>Possible values: 0, 1, LNA_AUTO</para>
<para>0, LNA off</para>
<para>1, LNA on</para>
<para>use the special macro LNA_AUTO to set LNA auto</para>
</section>
</section>
<section id="frontend-property-terrestrial-systems">
<title>Properties used on terrestrial delivery systems</title>
@ -816,6 +869,7 @@ typedef enum fe_hierarchy {
<listitem><para><link linkend="DTV-GUARD-INTERVAL"><constant>DTV_GUARD_INTERVAL</constant></link></para></listitem>
<listitem><para><link linkend="DTV-TRANSMISSION-MODE"><constant>DTV_TRANSMISSION_MODE</constant></link></para></listitem>
<listitem><para><link linkend="DTV-HIERARCHY"><constant>DTV_HIERARCHY</constant></link></para></listitem>
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
</itemizedlist>
</section>
<section id="dvbt2-params">
@ -838,7 +892,8 @@ typedef enum fe_hierarchy {
<listitem><para><link linkend="DTV-GUARD-INTERVAL"><constant>DTV_GUARD_INTERVAL</constant></link></para></listitem>
<listitem><para><link linkend="DTV-TRANSMISSION-MODE"><constant>DTV_TRANSMISSION_MODE</constant></link></para></listitem>
<listitem><para><link linkend="DTV-HIERARCHY"><constant>DTV_HIERARCHY</constant></link></para></listitem>
<listitem><para><link linkend="DTV-DVBT2-PLP-ID"><constant>DTV_DVBT2_PLP_ID</constant></link></para></listitem>
<listitem><para><link linkend="DTV-STREAM-ID"><constant>DTV_STREAM_ID</constant></link></para></listitem>
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
</itemizedlist>
</section>
<section id="isdbt">
@ -925,13 +980,32 @@ typedef enum fe_hierarchy {
<listitem><para><link linkend="DTV-ATSCMH-PRC"><constant>DTV_ATSCMH_PRC</constant></link></para></listitem>
<listitem><para><link linkend="DTV-ATSCMH-RS-FRAME-MODE"><constant>DTV_ATSCMH_RS_FRAME_MODE</constant></link></para></listitem>
<listitem><para><link linkend="DTV-ATSCMH-RS-FRAME-ENSEMBLE"><constant>DTV_ATSCMH_RS_FRAME_ENSEMBLE</constant></link></para></listitem>
<listitem><para><link linkend="DTV-ATSCMH-CODE-MODE-PRI"><constant>DTV_ATSCMH_CODE_MODE_PRI</constant></link></para></listitem>
<listitem><para><link linkend="DTV-ATSCMH-CODE-MODE-SEC"><constant>DTV_ATSCMH_CODE_MODE_SEC</constant></link></para></listitem>
<listitem><para><link linkend="DTV-ATSCMH-RS-CODE-MODE-PRI"><constant>DTV_ATSCMH_RS_CODE_MODE_PRI</constant></link></para></listitem>
<listitem><para><link linkend="DTV-ATSCMH-RS-CODE-MODE-SEC"><constant>DTV_ATSCMH_RS_CODE_MODE_SEC</constant></link></para></listitem>
<listitem><para><link linkend="DTV-ATSCMH-SCCC-BLOCK-MODE"><constant>DTV_ATSCMH_SCCC_BLOCK_MODE</constant></link></para></listitem>
<listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE_MODE-A"><constant>DTV_ATSCMH_SCCC_CODE_MODE_A</constant></link></para></listitem>
<listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE_MODE-B"><constant>DTV_ATSCMH_SCCC_CODE_MODE_B</constant></link></para></listitem>
<listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE_MODE-C"><constant>DTV_ATSCMH_SCCC_CODE_MODE_C</constant></link></para></listitem>
<listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE_MODE-D"><constant>DTV_ATSCMH_SCCC_CODE_MODE_D</constant></link></para></listitem>
<listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE-MODE-A"><constant>DTV_ATSCMH_SCCC_CODE_MODE_A</constant></link></para></listitem>
<listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE-MODE-B"><constant>DTV_ATSCMH_SCCC_CODE_MODE_B</constant></link></para></listitem>
<listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE-MODE-C"><constant>DTV_ATSCMH_SCCC_CODE_MODE_C</constant></link></para></listitem>
<listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE-MODE-D"><constant>DTV_ATSCMH_SCCC_CODE_MODE_D</constant></link></para></listitem>
</itemizedlist>
</section>
<section id="dtmb-params">
<title>DTMB delivery system</title>
<para>The following parameters are valid for DTMB:</para>
<itemizedlist mark='opencircle'>
<listitem><para><link linkend="DTV-API-VERSION"><constant>DTV_API_VERSION</constant></link></para></listitem>
<listitem><para><link linkend="DTV-DELIVERY-SYSTEM"><constant>DTV_DELIVERY_SYSTEM</constant></link></para></listitem>
<listitem><para><link linkend="DTV-TUNE"><constant>DTV_TUNE</constant></link></para></listitem>
<listitem><para><link linkend="DTV-CLEAR"><constant>DTV_CLEAR</constant></link></para></listitem>
<listitem><para><link linkend="DTV-FREQUENCY"><constant>DTV_FREQUENCY</constant></link></para></listitem>
<listitem><para><link linkend="DTV-MODULATION"><constant>DTV_MODULATION</constant></link></para></listitem>
<listitem><para><link linkend="DTV-BANDWIDTH-HZ"><constant>DTV_BANDWIDTH_HZ</constant></link></para></listitem>
<listitem><para><link linkend="DTV-INVERSION"><constant>DTV_INVERSION</constant></link></para></listitem>
<listitem><para><link linkend="DTV-INNER-FEC"><constant>DTV_INNER_FEC</constant></link></para></listitem>
<listitem><para><link linkend="DTV-GUARD-INTERVAL"><constant>DTV_GUARD_INTERVAL</constant></link></para></listitem>
<listitem><para><link linkend="DTV-TRANSMISSION-MODE"><constant>DTV_TRANSMISSION_MODE</constant></link></para></listitem>
<listitem><para><link linkend="DTV-INTERLEAVING"><constant>DTV_INTERLEAVING</constant></link></para></listitem>
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
</itemizedlist>
</section>
</section>
@ -952,6 +1026,7 @@ typedef enum fe_hierarchy {
<listitem><para><link linkend="DTV-INVERSION"><constant>DTV_INVERSION</constant></link></para></listitem>
<listitem><para><link linkend="DTV-SYMBOL-RATE"><constant>DTV_SYMBOL_RATE</constant></link></para></listitem>
<listitem><para><link linkend="DTV-INNER-FEC"><constant>DTV_INNER_FEC</constant></link></para></listitem>
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
</itemizedlist>
</section>
<section id="dvbc-annex-b-params">
@ -966,6 +1041,7 @@ typedef enum fe_hierarchy {
<listitem><para><link linkend="DTV-FREQUENCY"><constant>DTV_FREQUENCY</constant></link></para></listitem>
<listitem><para><link linkend="DTV-MODULATION"><constant>DTV_MODULATION</constant></link></para></listitem>
<listitem><para><link linkend="DTV-INVERSION"><constant>DTV_INVERSION</constant></link></para></listitem>
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
</itemizedlist>
</section>
</section>
@ -999,6 +1075,7 @@ typedef enum fe_hierarchy {
<listitem><para><link linkend="DTV-MODULATION"><constant>DTV_MODULATION</constant></link></para></listitem>
<listitem><para><link linkend="DTV-PILOT"><constant>DTV_PILOT</constant></link></para></listitem>
<listitem><para><link linkend="DTV-ROLLOFF"><constant>DTV_ROLLOFF</constant></link></para></listitem>
<listitem><para><link linkend="DTV-STREAM-ID"><constant>DTV_STREAM_ID</constant></link></para></listitem>
</itemizedlist>
</section>
<section id="turbo-params">
@ -1021,7 +1098,7 @@ typedef enum fe_hierarchy {
<listitem><para><link linkend="DTV-SYMBOL-RATE"><constant>DTV_SYMBOL_RATE</constant></link></para></listitem>
<listitem><para><link linkend="DTV-INNER-FEC"><constant>DTV_INNER_FEC</constant></link></para></listitem>
<listitem><para><link linkend="DTV-VOLTAGE"><constant>DTV_VOLTAGE</constant></link></para></listitem>
<listitem><para><link linkend="DTV-ISDBS-TS-ID"><constant>DTV_ISDBS_TS_ID</constant></link></para></listitem>
<listitem><para><link linkend="DTV-STREAM-ID"><constant>DTV_STREAM_ID</constant></link></para></listitem>
</itemizedlist>
</section>
</section>

View File

@ -66,7 +66,7 @@ supported via the new <link linkend="FE_GET_SET_PROPERTY">FE_GET_PROPERTY/FE_GET
<para>The usage of this field is deprecated, as it doesn't report all supported standards, and
will provide an incomplete information for frontends that support multiple delivery systems.
Please use <link linkend="DTV_ENUM_DELSYS">DTV_ENUM_DELSYS</link> instead.</para>
Please use <link linkend="DTV-ENUM-DELSYS">DTV_ENUM_DELSYS</link> instead.</para>
</section>
<section id="fe-caps-t">
@ -101,6 +101,7 @@ a specific frontend type.</para>
FE_CAN_8VSB = 0x200000,
FE_CAN_16VSB = 0x400000,
FE_HAS_EXTENDED_CAPS = 0x800000,
FE_CAN_MULTISTREAM = 0x4000000,
FE_CAN_TURBO_FEC = 0x8000000,
FE_CAN_2G_MODULATION = 0x10000000,
FE_NEEDS_BENDING = 0x20000000,
@ -207,19 +208,45 @@ spec.</para>
<para>Several functions of the frontend device use the fe_status data type defined
by</para>
<programlisting>
typedef enum fe_status {
FE_HAS_SIGNAL = 0x01, /&#x22C6; found something above the noise level &#x22C6;/
FE_HAS_CARRIER = 0x02, /&#x22C6; found a DVB signal &#x22C6;/
FE_HAS_VITERBI = 0x04, /&#x22C6; FEC is stable &#x22C6;/
FE_HAS_SYNC = 0x08, /&#x22C6; found sync bytes &#x22C6;/
FE_HAS_LOCK = 0x10, /&#x22C6; everything's working... &#x22C6;/
FE_TIMEDOUT = 0x20, /&#x22C6; no lock within the last ~2 seconds &#x22C6;/
FE_REINIT = 0x40 /&#x22C6; frontend was reinitialized, &#x22C6;/
} fe_status_t; /&#x22C6; application is recommned to reset &#x22C6;/
typedef enum fe_status {
FE_HAS_SIGNAL = 0x01,
FE_HAS_CARRIER = 0x02,
FE_HAS_VITERBI = 0x04,
FE_HAS_SYNC = 0x08,
FE_HAS_LOCK = 0x10,
FE_TIMEDOUT = 0x20,
FE_REINIT = 0x40,
} fe_status_t;
</programlisting>
<para>to indicate the current state and/or state changes of the frontend hardware.
<para>to indicate the current state and/or state changes of the frontend hardware:
</para>
<informaltable><tgroup cols="2"><tbody>
<row>
<entry align="char">FE_HAS_SIGNAL</entry>
<entry align="char">The frontend has found something above the noise level</entry>
</row><row>
<entry align="char">FE_HAS_CARRIER</entry>
<entry align="char">The frontend has found a DVB signal</entry>
</row><row>
<entry align="char">FE_HAS_VITERBI</entry>
<entry align="char">The frontend FEC code is stable</entry>
</row><row>
<entry align="char">FE_HAS_SYNC</entry>
<entry align="char">Syncronization bytes was found</entry>
</row><row>
<entry align="char">FE_HAS_LOCK</entry>
<entry align="char">The DVB were locked and everything is working</entry>
</row><row>
<entry align="char">FE_TIMEDOUT</entry>
<entry align="char">no lock within the last about 2 seconds</entry>
</row><row>
<entry align="char">FE_REINIT</entry>
<entry align="char">The frontend was reinitialized, application is
recommended to reset DiSEqC, tone and parameters</entry>
</row>
</tbody></tgroup></informaltable>
</section>
<section id="dvb-frontend-parameters">
@ -238,7 +265,7 @@ and to add newer delivery systems.</para>
<constant>FE_GET_PROPERTY/FE_SET_PROPERTY</constant></link> instead, in
order to be able to support the newer System Delivery like DVB-S2, DVB-T2,
DVB-C2, ISDB, etc.</para>
<para>All kinds of parameters are combined as an union in the FrontendParameters structure:</para>
<para>All kinds of parameters are combined as an union in the FrontendParameters structure:
<programlisting>
struct dvb_frontend_parameters {
uint32_t frequency; /&#x22C6; (absolute) frequency in Hz for QAM/OFDM &#x22C6;/
@ -251,12 +278,13 @@ struct dvb_frontend_parameters {
struct dvb_vsb_parameters vsb;
} u;
};
</programlisting>
</programlisting></para>
<para>In the case of QPSK frontends the <constant>frequency</constant> field specifies the intermediate
frequency, i.e. the offset which is effectively added to the local oscillator frequency (LOF) of
the LNB. The intermediate frequency has to be specified in units of kHz. For QAM and
OFDM frontends the <constant>frequency</constant> specifies the absolute frequency and is given in Hz.
</para>
<section id="dvb-qpsk-parameters">
<title>QPSK parameters</title>
<para>For satellite QPSK frontends you have to use the <constant>dvb_qpsk_parameters</constant> structure:</para>
@ -321,8 +349,8 @@ itself.
<section id="fe-code-rate-t">
<title>frontend code rate</title>
<para>The possible values for the <constant>fec_inner</constant> field used on
<link refend="dvb-qpsk-parameters"><constant>struct dvb_qpsk_parameters</constant></link> and
<link refend="dvb-qam-parameters"><constant>struct dvb_qam_parameters</constant></link> are:
<link linkend="dvb-qpsk-parameters"><constant>struct dvb_qpsk_parameters</constant></link> and
<link linkend="dvb-qam-parameters"><constant>struct dvb_qam_parameters</constant></link> are:
</para>
<programlisting>
typedef enum fe_code_rate {
@ -347,9 +375,9 @@ detection.
<section id="fe-modulation-t">
<title>frontend modulation type for QAM, OFDM and VSB</title>
<para>For cable and terrestrial frontends, e. g. for
<link refend="dvb-qam-parameters"><constant>struct dvb_qpsk_parameters</constant></link>,
<link refend="dvb-ofdm-parameters"><constant>struct dvb_qam_parameters</constant></link> and
<link refend="dvb-vsb-parameters"><constant>struct dvb_qam_parameters</constant></link>,
<link linkend="dvb-qam-parameters"><constant>struct dvb_qpsk_parameters</constant></link>,
<link linkend="dvb-ofdm-parameters"><constant>struct dvb_qam_parameters</constant></link> and
<link linkend="dvb-vsb-parameters"><constant>struct dvb_qam_parameters</constant></link>,
it needs to specify the quadrature modulation mode which can be one of the following:
</para>
<programlisting>
@ -370,8 +398,8 @@ it needs to specify the quadrature modulation mode which can be one of the follo
} fe_modulation_t;
</programlisting>
</section>
<para>Finally, there are several more parameters for OFDM:
</para>
<section>
<title>More OFDM parameters</title>
<section id="fe-transmit-mode-t">
<title>Number of carriers per channel</title>
<programlisting>
@ -427,6 +455,7 @@ typedef enum fe_hierarchy {
} fe_hierarchy_t;
</programlisting>
</section>
</section>
</section>

View File

@ -205,7 +205,7 @@ a partial path like:</para>
additional include file <emphasis
role="tt">linux/dvb/version.h</emphasis> exists, which defines the
constant <emphasis role="tt">DVB_API_VERSION</emphasis>. This document
describes <emphasis role="tt">DVB_API_VERSION 5.4</emphasis>.
describes <emphasis role="tt">DVB_API_VERSION 5.8</emphasis>.
</para>
</section>

View File

@ -2,7 +2,7 @@
<para>The kernel demux API defines a driver-internal interface for registering low-level,
hardware specific driver to a hardware independent demux layer. It is only of interest for
DVB device driver writers. The header file for this API is named <emphasis role="tt">demux.h</emphasis> and located in
<emphasis role="tt">drivers/media/dvb/dvb-core</emphasis>.
<emphasis role="tt">drivers/media/dvb-core</emphasis>.
</para>
<para>Maintainer note: This section must be reviewed. It is probably out of date.
</para>

View File

@ -26,4 +26,131 @@ struct dvb_net_if {
<title>DVB net Function Calls</title>
<para>To be written&#x2026;
</para>
<section id="NET_ADD_IF"
role="subsection"><title>NET_ADD_IF</title>
<para>DESCRIPTION
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl is undocumented. Documentation is welcome.</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>SYNOPSIS
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(fd, int request = NET_ADD_IF,
struct dvb_net_if *if);</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>PARAMETERS
</para>
<informaltable><tgroup cols="2"><tbody><row><entry
align="char">
<para>int fd</para>
</entry><entry
align="char">
<para>File descriptor returned by a previous call to open().</para>
</entry>
</row><row><entry
align="char">
<para>int request</para>
</entry><entry
align="char">
<para>Equals NET_ADD_IF for this command.</para>
</entry>
</row><row><entry
align="char">
<para>struct dvb_net_if *if
</para>
</entry><entry
align="char">
<para>Undocumented.</para>
</entry>
</row></tbody></tgroup></informaltable>
&return-value-dvb;
</section>
<section id="NET_REMOVE_IF"
role="subsection"><title>NET_REMOVE_IF</title>
<para>DESCRIPTION
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl is undocumented. Documentation is welcome.</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>SYNOPSIS
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(fd, int request = NET_REMOVE_IF);
</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>PARAMETERS
</para>
<informaltable><tgroup cols="2"><tbody><row><entry
align="char">
<para>int fd</para>
</entry><entry
align="char">
<para>File descriptor returned by a previous call to open().</para>
</entry>
</row><row><entry
align="char">
<para>int request</para>
</entry><entry
align="char">
<para>Equals NET_REMOVE_IF for this command.</para>
</entry>
</row></tbody></tgroup></informaltable>
&return-value-dvb;
</section>
<section id="NET_GET_IF"
role="subsection"><title>NET_GET_IF</title>
<para>DESCRIPTION
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl is undocumented. Documentation is welcome.</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>SYNOPSIS
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(fd, int request = NET_GET_IF,
struct dvb_net_if *if);</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>PARAMETERS
</para>
<informaltable><tgroup cols="2"><tbody><row><entry
align="char">
<para>int fd</para>
</entry><entry
align="char">
<para>File descriptor returned by a previous call to open().</para>
</entry>
</row><row><entry
align="char">
<para>int request</para>
</entry><entry
align="char">
<para>Equals NET_GET_IF for this command.</para>
</entry>
</row><row><entry
align="char">
<para>struct dvb_net_if *if
</para>
</entry><entry
align="char">
<para>Undocumented.</para>
</entry>
</row></tbody></tgroup></informaltable>
&return-value-dvb;
</section>
</section>

View File

@ -15,6 +15,10 @@ the audio and video device as well as the video4linux device.
<para>The ioctls that deal with SPUs (sub picture units) and navigation packets are only
supported on some MPEG decoders made for DVD playback.
</para>
<para>
These ioctls were also used by V4L2 to control MPEG decoders implemented in V4L2. The use
of these ioctls for that purpose has been made obsolete and proper V4L2 ioctls or controls
have been created to replace that functionality.</para>
<section id="video_types">
<title>Video Data Types</title>
@ -55,7 +59,7 @@ typedef enum {
</section>
<section id="video-stream-source-t">
<title>video stream source</title>
<title>video_stream_source_t</title>
<para>The video stream source is set through the VIDEO_SELECT_SOURCE call and can take
the following values, depending on whether we are replaying from an internal (demuxer) or
external (user write) source.
@ -76,7 +80,7 @@ call.
</section>
<section id="video-play-state-t">
<title>video play state</title>
<title>video_play_state_t</title>
<para>The following values can be returned by the VIDEO_GET_STATUS call representing the
state of video playback.
</para>
@ -90,9 +94,9 @@ typedef enum {
</section>
<section id="video-command">
<title>struct video_command</title>
<para>The structure must be zeroed before use by the application
This ensures it can be extended safely in the future.</para>
<title>struct video-command</title>
<programlisting>
struct video_command {
__u32 cmd;
@ -121,7 +125,7 @@ struct video_command {
</section>
<section id="video-size-t">
<title>struct video_size-t</title>
<title>video_size_t</title>
<programlisting>
typedef struct {
int w;
@ -217,7 +221,7 @@ bits set according to the hardwares capabilities.
</section>
<section id="video-system">
<title>video system</title>
<title>video_system_t</title>
<para>A call to VIDEO_SET_SYSTEM sets the desired video system for TV output. The
following system types can be set:
</para>
@ -263,7 +267,7 @@ call expects the following format for that information:
</section>
<section id="video-spu">
<title>video SPU</title>
<title>struct video_spu</title>
<para>Calling VIDEO_SET_SPU deactivates or activates SPU decoding, according to the
following format:
</para>
@ -277,12 +281,12 @@ following format:
</section>
<section id="video-spu-palette">
<title>video SPU palette</title>
<title>struct video_spu_palette</title>
<para>The following structure is used to set the SPU palette by calling VIDEO_SPU_PALETTE:
</para>
<programlisting>
typedef
struct video_spu_palette{
struct video_spu_palette {
int length;
uint8_t &#x22C6;palette;
} video_spu_palette_t;
@ -290,13 +294,13 @@ following format:
</section>
<section id="video-navi-pack">
<title>video NAVI pack</title>
<title>struct video_navi_pack</title>
<para>In order to get the navigational data the following structure has to be passed to the ioctl
VIDEO_GET_NAVI:
</para>
<programlisting>
typedef
struct video_navi_pack{
struct video_navi_pack {
int length; /&#x22C6; 0 ... 1024 &#x22C6;/
uint8_t data[1024];
} video_navi_pack_t;
@ -305,7 +309,7 @@ VIDEO_GET_NAVI:
<section id="video-attributes-t">
<title>video attributes</title>
<title>video_attributes_t</title>
<para>The following attributes can be set by a call to VIDEO_SET_ATTRIBUTES:
</para>
<programlisting>
@ -541,6 +545,8 @@ VIDEO_GET_NAVI:
role="subsection"><title>VIDEO_STOP</title>
<para>DESCRIPTION
</para>
<para>This ioctl is for DVB devices only. To control a V4L2 decoder use the V4L2
&VIDIOC-DECODER-CMD; instead.</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl call asks the Video Device to stop playing the current stream.
@ -598,6 +604,8 @@ role="subsection"><title>VIDEO_STOP</title>
role="subsection"><title>VIDEO_PLAY</title>
<para>DESCRIPTION
</para>
<para>This ioctl is for DVB devices only. To control a V4L2 decoder use the V4L2
&VIDIOC-DECODER-CMD; instead.</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl call asks the Video Device to start playing a video stream from the
@ -634,6 +642,8 @@ role="subsection"><title>VIDEO_PLAY</title>
role="subsection"><title>VIDEO_FREEZE</title>
<para>DESCRIPTION
</para>
<para>This ioctl is for DVB devices only. To control a V4L2 decoder use the V4L2
&VIDIOC-DECODER-CMD; instead.</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl call suspends the live video stream being played. Decoding
@ -674,6 +684,8 @@ role="subsection"><title>VIDEO_FREEZE</title>
role="subsection"><title>VIDEO_CONTINUE</title>
<para>DESCRIPTION
</para>
<para>This ioctl is for DVB devices only. To control a V4L2 decoder use the V4L2
&VIDIOC-DECODER-CMD; instead.</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl call restarts decoding and playing processes of the video stream
@ -710,6 +722,9 @@ role="subsection"><title>VIDEO_CONTINUE</title>
role="subsection"><title>VIDEO_SELECT_SOURCE</title>
<para>DESCRIPTION
</para>
<para>This ioctl is for DVB devices only. This ioctl was also supported by the
V4L2 ivtv driver, but that has been replaced by the ivtv-specific
<constant>IVTV_IOC_PASSTHROUGH_MODE</constant> ioctl.</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl call informs the video device which source shall be used for the input
@ -845,10 +860,160 @@ role="subsection"><title>VIDEO_GET_STATUS</title>
</row></tbody></tgroup></informaltable>
&return-value-dvb;
</section><section id="VIDEO_GET_FRAME_COUNT"
role="subsection"><title>VIDEO_GET_FRAME_COUNT</title>
<para>DESCRIPTION
</para>
<para>This ioctl is obsolete. Do not use in new drivers. For V4L2 decoders this
ioctl has been replaced by the <constant>V4L2_CID_MPEG_VIDEO_DEC_FRAME</constant> control.</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl call asks the Video Device to return the number of displayed frames
since the decoder was started.</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>SYNOPSIS
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(int fd, int request =
VIDEO_GET_FRAME_COUNT, __u64 *pts);</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>PARAMETERS
</para>
<informaltable><tgroup cols="2"><tbody><row><entry
align="char">
<para>int fd</para>
</entry><entry
align="char">
<para>File descriptor returned by a previous call to open().</para>
</entry>
</row><row><entry
align="char">
<para>int request</para>
</entry><entry
align="char">
<para>Equals VIDEO_GET_FRAME_COUNT for this
command.</para>
</entry>
</row><row><entry
align="char">
<para>__u64 *pts
</para>
</entry><entry
align="char">
<para>Returns the number of frames displayed since the decoder was started.
</para>
</entry>
</row></tbody></tgroup></informaltable>
&return-value-dvb;
</section><section id="VIDEO_GET_PTS"
role="subsection"><title>VIDEO_GET_PTS</title>
<para>DESCRIPTION
</para>
<para>This ioctl is obsolete. Do not use in new drivers. For V4L2 decoders this
ioctl has been replaced by the <constant>V4L2_CID_MPEG_VIDEO_DEC_PTS</constant> control.</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl call asks the Video Device to return the current PTS timestamp.</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>SYNOPSIS
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(int fd, int request =
VIDEO_GET_PTS, __u64 *pts);</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>PARAMETERS
</para>
<informaltable><tgroup cols="2"><tbody><row><entry
align="char">
<para>int fd</para>
</entry><entry
align="char">
<para>File descriptor returned by a previous call to open().</para>
</entry>
</row><row><entry
align="char">
<para>int request</para>
</entry><entry
align="char">
<para>Equals VIDEO_GET_PTS for this
command.</para>
</entry>
</row><row><entry
align="char">
<para>__u64 *pts
</para>
</entry><entry
align="char">
<para>Returns the 33-bit timestamp as defined in ITU T-REC-H.222.0 / ISO/IEC 13818-1.
</para>
<para>
The PTS should belong to the currently played
frame if possible, but may also be a value close to it
like the PTS of the last decoded frame or the last PTS
extracted by the PES parser.</para>
</entry>
</row></tbody></tgroup></informaltable>
&return-value-dvb;
</section><section id="VIDEO_GET_FRAME_RATE"
role="subsection"><title>VIDEO_GET_FRAME_RATE</title>
<para>DESCRIPTION
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl call asks the Video Device to return the current framerate.</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>SYNOPSIS
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(int fd, int request =
VIDEO_GET_FRAME_RATE, unsigned int *rate);</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>PARAMETERS
</para>
<informaltable><tgroup cols="2"><tbody><row><entry
align="char">
<para>int fd</para>
</entry><entry
align="char">
<para>File descriptor returned by a previous call to open().</para>
</entry>
</row><row><entry
align="char">
<para>int request</para>
</entry><entry
align="char">
<para>Equals VIDEO_GET_FRAME_RATE for this
command.</para>
</entry>
</row><row><entry
align="char">
<para>unsigned int *rate
</para>
</entry><entry
align="char">
<para>Returns the framerate in number of frames per 1000 seconds.
</para>
</entry>
</row></tbody></tgroup></informaltable>
&return-value-dvb;
</section><section id="VIDEO_GET_EVENT"
role="subsection"><title>VIDEO_GET_EVENT</title>
<para>DESCRIPTION
</para>
<para>This ioctl is for DVB devices only. To get events from a V4L2 decoder use the V4L2
&VIDIOC-DQEVENT; ioctl instead.</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl call returns an event of type video_event if available. If an event is
@ -914,6 +1079,152 @@ role="subsection"><title>VIDEO_GET_EVENT</title>
</entry>
</row></tbody></tgroup></informaltable>
</section><section id="VIDEO_COMMAND"
role="subsection"><title>VIDEO_COMMAND</title>
<para>DESCRIPTION
</para>
<para>This ioctl is obsolete. Do not use in new drivers. For V4L2 decoders this
ioctl has been replaced by the &VIDIOC-DECODER-CMD; ioctl.</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl commands the decoder. The <constant>video_command</constant> struct
is a subset of the <constant>v4l2_decoder_cmd</constant> struct, so refer to the
&VIDIOC-DECODER-CMD; documentation for more information.</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>SYNOPSIS
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(int fd, int request =
VIDEO_COMMAND, struct video_command *cmd);</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>PARAMETERS
</para>
<informaltable><tgroup cols="2"><tbody><row><entry
align="char">
<para>int fd</para>
</entry><entry
align="char">
<para>File descriptor returned by a previous call to open().</para>
</entry>
</row><row><entry
align="char">
<para>int request</para>
</entry><entry
align="char">
<para>Equals VIDEO_COMMAND for this
command.</para>
</entry>
</row><row><entry
align="char">
<para>struct video_command *cmd
</para>
</entry><entry
align="char">
<para>Commands the decoder.
</para>
</entry>
</row></tbody></tgroup></informaltable>
&return-value-dvb;
</section><section id="VIDEO_TRY_COMMAND"
role="subsection"><title>VIDEO_TRY_COMMAND</title>
<para>DESCRIPTION
</para>
<para>This ioctl is obsolete. Do not use in new drivers. For V4L2 decoders this
ioctl has been replaced by the &VIDIOC-TRY-DECODER-CMD; ioctl.</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl tries a decoder command. The <constant>video_command</constant> struct
is a subset of the <constant>v4l2_decoder_cmd</constant> struct, so refer to the
&VIDIOC-TRY-DECODER-CMD; documentation for more information.</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>SYNOPSIS
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(int fd, int request =
VIDEO_TRY_COMMAND, struct video_command *cmd);</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>PARAMETERS
</para>
<informaltable><tgroup cols="2"><tbody><row><entry
align="char">
<para>int fd</para>
</entry><entry
align="char">
<para>File descriptor returned by a previous call to open().</para>
</entry>
</row><row><entry
align="char">
<para>int request</para>
</entry><entry
align="char">
<para>Equals VIDEO_TRY_COMMAND for this
command.</para>
</entry>
</row><row><entry
align="char">
<para>struct video_command *cmd
</para>
</entry><entry
align="char">
<para>Try a decoder command.
</para>
</entry>
</row></tbody></tgroup></informaltable>
&return-value-dvb;
</section><section id="VIDEO_GET_SIZE"
role="subsection"><title>VIDEO_GET_SIZE</title>
<para>DESCRIPTION
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl returns the size and aspect ratio.</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>SYNOPSIS
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(int fd, int request =
VIDEO_GET_SIZE, video_size_t *size);</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>PARAMETERS
</para>
<informaltable><tgroup cols="2"><tbody><row><entry
align="char">
<para>int fd</para>
</entry><entry
align="char">
<para>File descriptor returned by a previous call to open().</para>
</entry>
</row><row><entry
align="char">
<para>int request</para>
</entry><entry
align="char">
<para>Equals VIDEO_GET_SIZE for this
command.</para>
</entry>
</row><row><entry
align="char">
<para>video_size_t *size
</para>
</entry><entry
align="char">
<para>Returns the size and aspect ratio.
</para>
</entry>
</row></tbody></tgroup></informaltable>
&return-value-dvb;
</section><section id="VIDEO_SET_DISPLAY_FORMAT"
role="subsection"><title>VIDEO_SET_DISPLAY_FORMAT</title>
<para>DESCRIPTION

View File

@ -178,23 +178,23 @@ Signal - NTSC for Studio Applications"</title>
1125-Line High-Definition Production"</title>
</biblioentry>
<biblioentry id="en50067">
<abbrev>EN&nbsp;50067</abbrev>
<biblioentry id="iec62106">
<abbrev>IEC&nbsp;62106</abbrev>
<authorgroup>
<corpauthor>European Committee for Electrotechnical Standardization
(<ulink url="http://www.cenelec.eu">http://www.cenelec.eu</ulink>)</corpauthor>
<corpauthor>International Electrotechnical Commission
(<ulink url="http://www.iec.ch">http://www.iec.ch</ulink>)</corpauthor>
</authorgroup>
<title>Specification of the radio data system (RDS) for VHF/FM sound broadcasting
in the frequency range from 87,5 to 108,0 MHz</title>
</biblioentry>
<biblioentry id="nrsc4">
<abbrev>NRSC-4</abbrev>
<abbrev>NRSC-4-B</abbrev>
<authorgroup>
<corpauthor>National Radio Systems Committee
(<ulink url="http://www.nrscstandards.org">http://www.nrscstandards.org</ulink>)</corpauthor>
</authorgroup>
<title>NRSC-4: United States RBDS Standard</title>
<title>NRSC-4-B: United States RBDS Standard</title>
</biblioentry>
<biblioentry id="iso12232">
@ -226,4 +226,44 @@ in the frequency range from 87,5 to 108,0 MHz</title>
<title>VESA and Industry Standards and Guidelines for Computer Display Monitor Timing (DMT)</title>
</biblioentry>
<biblioentry id="vesaedid">
<abbrev>EDID</abbrev>
<authorgroup>
<corpauthor>Video Electronics Standards Association
(<ulink url="http://www.vesa.org">http://www.vesa.org</ulink>)</corpauthor>
</authorgroup>
<title>VESA Enhanced Extended Display Identification Data Standard</title>
<subtitle>Release A, Revision 2</subtitle>
</biblioentry>
<biblioentry id="hdcp">
<abbrev>HDCP</abbrev>
<authorgroup>
<corpauthor>Digital Content Protection LLC
(<ulink url="http://www.digital-cp.com">http://www.digital-cp.com</ulink>)</corpauthor>
</authorgroup>
<title>High-bandwidth Digital Content Protection System</title>
<subtitle>Revision 1.3</subtitle>
</biblioentry>
<biblioentry id="hdmi">
<abbrev>HDMI</abbrev>
<authorgroup>
<corpauthor>HDMI Licensing LLC
(<ulink url="http://www.hdmi.org">http://www.hdmi.org</ulink>)</corpauthor>
</authorgroup>
<title>High-Definition Multimedia Interface</title>
<subtitle>Specification Version 1.4a</subtitle>
</biblioentry>
<biblioentry id="dp">
<abbrev>DP</abbrev>
<authorgroup>
<corpauthor>Video Electronics Standards Association
(<ulink url="http://www.vesa.org">http://www.vesa.org</ulink>)</corpauthor>
</authorgroup>
<title>VESA DisplayPort Standard</title>
<subtitle>Version 1, Revision 2</subtitle>
</biblioentry>
</bibliography>

View File

@ -564,7 +564,7 @@ automatically.</para>
<para>To query and select the standard used by the current video
input or output applications call the &VIDIOC-G-STD; and
&VIDIOC-S-STD; ioctl, respectively. The <emphasis>received</emphasis>
standard can be sensed with the &VIDIOC-QUERYSTD; ioctl. Note parameter of all these ioctls is a pointer to a &v4l2-std-id; type (a standard set), <emphasis>not</emphasis> an index into the standard enumeration.<footnote>
standard can be sensed with the &VIDIOC-QUERYSTD; ioctl. Note that the parameter of all these ioctls is a pointer to a &v4l2-std-id; type (a standard set), <emphasis>not</emphasis> an index into the standard enumeration.<footnote>
<para>An alternative to the current scheme is to use pointers
to indices as arguments of <constant>VIDIOC_G_STD</constant> and
<constant>VIDIOC_S_STD</constant>, the &v4l2-input; and
@ -588,30 +588,28 @@ switch to a standard by &v4l2-std-id;.</para>
</footnote> Drivers must implement all video standard ioctls
when the device has one or more video inputs or outputs.</para>
<para>Special rules apply to USB cameras where the notion of video
standards makes little sense. More generally any capture device,
output devices accordingly, which is <itemizedlist>
<para>Special rules apply to devices such as USB cameras where the notion of video
standards makes little sense. More generally for any capture or output device
which is: <itemizedlist>
<listitem>
<para>incapable of capturing fields or frames at the nominal
rate of the video standard, or</para>
</listitem>
<listitem>
<para>where <link linkend="buffer">timestamps</link> refer
to the instant the field or frame was received by the driver, not the
capture time, or</para>
</listitem>
<listitem>
<para>where <link linkend="buffer">sequence numbers</link>
refer to the frames received by the driver, not the captured
frames.</para>
<para>that does not support the video standard formats at all.</para>
</listitem>
</itemizedlist> Here the driver shall set the
<structfield>std</structfield> field of &v4l2-input; and &v4l2-output;
to zero, the <constant>VIDIOC_G_STD</constant>,
to zero and the <constant>VIDIOC_G_STD</constant>,
<constant>VIDIOC_S_STD</constant>,
<constant>VIDIOC_QUERYSTD</constant> and
<constant>VIDIOC_ENUMSTD</constant> ioctls shall return the
&EINVAL;.<footnote>
&ENOTTY;.<footnote>
<para>See <xref linkend="buffer" /> for a rationale.</para>
<para>Applications can make use of the <xref linkend="input-capabilities" /> and
<xref linkend="output-capabilities"/> flags to determine whether the video standard ioctls
are available for the device.</para>
&ENOTTY;.
<para>See <xref linkend="buffer" /> for a rationale. Probably
even USB cameras follow some well known video standard. It might have
been better to explicitly indicate elsewhere if a device cannot live
@ -626,9 +624,9 @@ up to normal expectations, instead of this exception.</para>
&v4l2-standard; standard;
if (-1 == ioctl (fd, &VIDIOC-G-STD;, &amp;std_id)) {
/* Note when VIDIOC_ENUMSTD always returns EINVAL this
/* Note when VIDIOC_ENUMSTD always returns ENOTTY this
is no video device or it falls under the USB exception,
and VIDIOC_G_STD returning EINVAL is no error. */
and VIDIOC_G_STD returning ENOTTY is no error. */
perror ("VIDIOC_G_STD");
exit (EXIT_FAILURE);

View File

@ -1476,7 +1476,7 @@ follows.<informaltable>
</row>
<row>
<entry><constant>V4L2_BUF_TYPE_PRIVATE_BASE</constant></entry>
<entry><constant>V4L2_BUF_TYPE_PRIVATE</constant></entry>
<entry><constant>V4L2_BUF_TYPE_PRIVATE</constant> (but this is deprecated)</entry>
</row>
</tbody>
</tgroup>
@ -2468,21 +2468,9 @@ that used it. It was originally scheduled for removal in 2.6.35.
<structfield>reserved2</structfield> and removed
<constant>V4L2_BUF_FLAG_INPUT</constant>.</para>
</listitem>
</orderedlist>
</section>
<section>
<title>V4L2 in Linux 3.6</title>
<orderedlist>
<listitem>
<para>Added V4L2_CAP_VIDEO_M2M and V4L2_CAP_VIDEO_M2M_MPLANE capabilities.</para>
</listitem>
</orderedlist>
</section>
<section>
<title>V4L2 in Linux 3.6</title>
<orderedlist>
<listitem>
<para>Added support for frequency band enumerations: &VIDIOC-ENUM-FREQ-BANDS;.</para>
</listitem>
@ -2567,29 +2555,6 @@ and may change in the future.</para>
<para>Video Output Overlay (OSD) Interface, <xref
linkend="osd" />.</para>
</listitem>
<listitem>
<para><constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY</constant>,
&v4l2-buf-type;, <xref linkend="v4l2-buf-type" />.</para>
</listitem>
<listitem>
<para><constant>V4L2_CAP_VIDEO_OUTPUT_OVERLAY</constant>,
&VIDIOC-QUERYCAP; ioctl, <xref linkend="device-capabilities" />.</para>
</listitem>
<listitem>
<para>&VIDIOC-ENUM-FRAMESIZES; and
&VIDIOC-ENUM-FRAMEINTERVALS; ioctls.</para>
</listitem>
<listitem>
<para>&VIDIOC-G-ENC-INDEX; ioctl.</para>
</listitem>
<listitem>
<para>&VIDIOC-ENCODER-CMD; and &VIDIOC-TRY-ENCODER-CMD;
ioctls.</para>
</listitem>
<listitem>
<para>&VIDIOC-DECODER-CMD; and &VIDIOC-TRY-DECODER-CMD;
ioctls.</para>
</listitem>
<listitem>
<para>&VIDIOC-DBG-G-REGISTER; and &VIDIOC-DBG-S-REGISTER;
ioctls.</para>
@ -2614,10 +2579,6 @@ ioctls.</para>
<para>Sub-device selection API: &VIDIOC-SUBDEV-G-SELECTION;
and &VIDIOC-SUBDEV-S-SELECTION; ioctls.</para>
</listitem>
<listitem>
<para><link linkend="v4l2-auto-focus-area"><constant>
V4L2_CID_AUTO_FOCUS_AREA</constant></link> control.</para>
</listitem>
<listitem>
<para>Support for frequency band enumeration: &VIDIOC-ENUM-FREQ-BANDS; ioctl.</para>
</listitem>

View File

@ -3505,7 +3505,7 @@ This encodes up to 31 pre-defined programme types.</entry>
</row>
<row><entry spanname="descr">Sets the Programme Service name (PS_NAME) for transmission.
It is intended for static display on a receiver. It is the primary aid to listeners in programme service
identification and selection. In Annex E of <xref linkend="en50067" />, the RDS specification,
identification and selection. In Annex E of <xref linkend="iec62106" />, the RDS specification,
there is a full description of the correct character encoding for Programme Service name strings.
Also from RDS specification, PS is usually a single eight character text. However, it is also possible
to find receivers which can scroll strings sized as 8 x N characters. So, this control must be configured
@ -3519,7 +3519,7 @@ with steps of 8 characters. The result is it must always contain a string with s
what is being broadcasted. RDS Radio Text can be applied when broadcaster wishes to transmit longer PS names,
programme-related information or any other text. In these cases, RadioText should be used in addition to
<constant>V4L2_CID_RDS_TX_PS_NAME</constant>. The encoding for Radio Text strings is also fully described
in Annex E of <xref linkend="en50067" />. The length of Radio Text strings depends on which RDS Block is being
in Annex E of <xref linkend="iec62106" />. The length of Radio Text strings depends on which RDS Block is being
used to transmit it, either 32 (2A block) or 64 (2B block). However, it is also possible
to find receivers which can scroll strings sized as 32 x N or 64 x N characters. So, this control must be configured
with steps of 32 or 64 characters. The result is it must always contain a string with size multiple of 32 or 64. </entry>
@ -3650,7 +3650,7 @@ manually or automatically if set to zero. Unit, range and step are driver-specif
</table>
<para>For more details about RDS specification, refer to
<xref linkend="en50067" /> document, from CENELEC.</para>
<xref linkend="iec62106" /> document, from CENELEC.</para>
</section>
<section id="flash-controls">
@ -3717,232 +3717,231 @@ interface and may change in the future.</para>
use case involving camera or individually.
</para>
<table pgwide="1" frame="none" id="flash-control-id">
<title>Flash Control IDs</title>
<tgroup cols="4">
<colspec colname="c1" colwidth="1*" />
<colspec colname="c2" colwidth="6*" />
<colspec colname="c3" colwidth="2*" />
<colspec colname="c4" colwidth="6*" />
<spanspec namest="c1" nameend="c2" spanname="id" />
<spanspec namest="c2" nameend="c4" spanname="descr" />
<thead>
<row>
<entry spanname="id" align="left">ID</entry>
<entry align="left">Type</entry>
</row><row rowsep="1"><entry spanname="descr" align="left">Description</entry>
</row>
</thead>
<tbody valign="top">
<row><entry></entry></row>
<row>
<entry spanname="id"><constant>V4L2_CID_FLASH_CLASS</constant></entry>
<entry>class</entry>
</row>
<row>
<entry spanname="descr">The FLASH class descriptor.</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_FLASH_LED_MODE</constant></entry>
<entry>menu</entry>
</row>
<row id="v4l2-flash-led-mode">
<entry spanname="descr">Defines the mode of the flash LED,
the high-power white LED attached to the flash controller.
Setting this control may not be possible in presence of
some faults. See V4L2_CID_FLASH_FAULT.</entry>
</row>
<row>
<entrytbl spanname="descr" cols="2">
<tbody valign="top">
<row>
<entry><constant>V4L2_FLASH_LED_MODE_NONE</constant></entry>
<entry>Off.</entry>
</row>
<row>
<entry><constant>V4L2_FLASH_LED_MODE_FLASH</constant></entry>
<entry>Flash mode.</entry>
</row>
<row>
<entry><constant>V4L2_FLASH_LED_MODE_TORCH</constant></entry>
<entry>Torch mode. See V4L2_CID_FLASH_TORCH_INTENSITY.</entry>
</row>
</tbody>
</entrytbl>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_FLASH_STROBE_SOURCE</constant></entry>
<entry>menu</entry>
</row>
<row id="v4l2-flash-strobe-source"><entry
spanname="descr">Defines the source of the flash LED
strobe.</entry>
</row>
<row>
<entrytbl spanname="descr" cols="2">
<tbody valign="top">
<row>
<entry><constant>V4L2_FLASH_STROBE_SOURCE_SOFTWARE</constant></entry>
<entry>The flash strobe is triggered by using
the V4L2_CID_FLASH_STROBE control.</entry>
</row>
<row>
<entry><constant>V4L2_FLASH_STROBE_SOURCE_EXTERNAL</constant></entry>
<entry>The flash strobe is triggered by an
external source. Typically this is a sensor,
which makes it possible to synchronises the
flash strobe start to exposure start.</entry>
</row>
</tbody>
</entrytbl>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_FLASH_STROBE</constant></entry>
<entry>button</entry>
</row>
<row>
<entry spanname="descr">Strobe flash. Valid when
V4L2_CID_FLASH_LED_MODE is set to
V4L2_FLASH_LED_MODE_FLASH and V4L2_CID_FLASH_STROBE_SOURCE
is set to V4L2_FLASH_STROBE_SOURCE_SOFTWARE. Setting this
control may not be possible in presence of some faults.
See V4L2_CID_FLASH_FAULT.</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_FLASH_STROBE_STOP</constant></entry>
<entry>button</entry>
</row>
<row><entry spanname="descr">Stop flash strobe immediately.</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_FLASH_STROBE_STATUS</constant></entry>
<entry>boolean</entry>
</row>
<row>
<entry spanname="descr">Strobe status: whether the flash
is strobing at the moment or not. This is a read-only
control.</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_FLASH_TIMEOUT</constant></entry>
<entry>integer</entry>
</row>
<row>
<entry spanname="descr">Hardware timeout for flash. The
flash strobe is stopped after this period of time has
passed from the start of the strobe.</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_FLASH_INTENSITY</constant></entry>
<entry>integer</entry>
</row>
<row>
<entry spanname="descr">Intensity of the flash strobe when
the flash LED is in flash mode
(V4L2_FLASH_LED_MODE_FLASH). The unit should be milliamps
(mA) if possible.</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_FLASH_TORCH_INTENSITY</constant></entry>
<entry>integer</entry>
</row>
<row>
<entry spanname="descr">Intensity of the flash LED in
torch mode (V4L2_FLASH_LED_MODE_TORCH). The unit should be
milliamps (mA) if possible. Setting this control may not
be possible in presence of some faults. See
V4L2_CID_FLASH_FAULT.</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_FLASH_INDICATOR_INTENSITY</constant></entry>
<entry>integer</entry>
</row>
<row>
<entry spanname="descr">Intensity of the indicator LED.
The indicator LED may be fully independent of the flash
LED. The unit should be microamps (uA) if possible.</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_FLASH_FAULT</constant></entry>
<entry>bitmask</entry>
</row>
<row>
<entry spanname="descr">Faults related to the flash. The
faults tell about specific problems in the flash chip
itself or the LEDs attached to it. Faults may prevent
further use of some of the flash controls. In particular,
V4L2_CID_FLASH_LED_MODE is set to V4L2_FLASH_LED_MODE_NONE
if the fault affects the flash LED. Exactly which faults
have such an effect is chip dependent. Reading the faults
resets the control and returns the chip to a usable state
if possible.</entry>
</row>
<row>
<entrytbl spanname="descr" cols="2">
<tbody valign="top">
<row>
<entry><constant>V4L2_FLASH_FAULT_OVER_VOLTAGE</constant></entry>
<entry>Flash controller voltage to the flash LED
has exceeded the limit specific to the flash
controller.</entry>
</row>
<row>
<entry><constant>V4L2_FLASH_FAULT_TIMEOUT</constant></entry>
<entry>The flash strobe was still on when
the timeout set by the user ---
V4L2_CID_FLASH_TIMEOUT control --- has expired.
Not all flash controllers may set this in all
such conditions.</entry>
</row>
<row>
<entry><constant>V4L2_FLASH_FAULT_OVER_TEMPERATURE</constant></entry>
<entry>The flash controller has overheated.</entry>
</row>
<row>
<entry><constant>V4L2_FLASH_FAULT_SHORT_CIRCUIT</constant></entry>
<entry>The short circuit protection of the flash
controller has been triggered.</entry>
</row>
<row>
<entry><constant>V4L2_FLASH_FAULT_OVER_CURRENT</constant></entry>
<entry>Current in the LED power supply has exceeded the limit
specific to the flash controller.</entry>
</row>
<row>
<entry><constant>V4L2_FLASH_FAULT_INDICATOR</constant></entry>
<entry>The flash controller has detected a short or open
circuit condition on the indicator LED.</entry>
</row>
</tbody>
</entrytbl>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_FLASH_CHARGE</constant></entry>
<entry>boolean</entry>
</row>
<row><entry spanname="descr">Enable or disable charging of the xenon
flash capacitor.</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_FLASH_READY</constant></entry>
<entry>boolean</entry>
</row>
<row>
<entry spanname="descr">Is the flash ready to strobe?
Xenon flashes require their capacitors charged before
strobing. LED flashes often require a cooldown period
after strobe during which another strobe will not be
possible. This is a read-only control.</entry>
</row>
<row><entry></entry></row>
</tbody>
</tgroup>
</table>
</section>
</section>
<table pgwide="1" frame="none" id="flash-control-id">
<title>Flash Control IDs</title>
<tgroup cols="4">
<colspec colname="c1" colwidth="1*" />
<colspec colname="c2" colwidth="6*" />
<colspec colname="c3" colwidth="2*" />
<colspec colname="c4" colwidth="6*" />
<spanspec namest="c1" nameend="c2" spanname="id" />
<spanspec namest="c2" nameend="c4" spanname="descr" />
<thead>
<row>
<entry spanname="id" align="left">ID</entry>
<entry align="left">Type</entry>
</row><row rowsep="1"><entry spanname="descr" align="left">Description</entry>
</row>
</thead>
<tbody valign="top">
<row><entry></entry></row>
<row>
<entry spanname="id"><constant>V4L2_CID_FLASH_CLASS</constant></entry>
<entry>class</entry>
</row>
<row>
<entry spanname="descr">The FLASH class descriptor.</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_FLASH_LED_MODE</constant></entry>
<entry>menu</entry>
</row>
<row id="v4l2-flash-led-mode">
<entry spanname="descr">Defines the mode of the flash LED,
the high-power white LED attached to the flash controller.
Setting this control may not be possible in presence of
some faults. See V4L2_CID_FLASH_FAULT.</entry>
</row>
<row>
<entrytbl spanname="descr" cols="2">
<tbody valign="top">
<row>
<entry><constant>V4L2_FLASH_LED_MODE_NONE</constant></entry>
<entry>Off.</entry>
</row>
<row>
<entry><constant>V4L2_FLASH_LED_MODE_FLASH</constant></entry>
<entry>Flash mode.</entry>
</row>
<row>
<entry><constant>V4L2_FLASH_LED_MODE_TORCH</constant></entry>
<entry>Torch mode. See V4L2_CID_FLASH_TORCH_INTENSITY.</entry>
</row>
</tbody>
</entrytbl>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_FLASH_STROBE_SOURCE</constant></entry>
<entry>menu</entry>
</row>
<row id="v4l2-flash-strobe-source"><entry
spanname="descr">Defines the source of the flash LED
strobe.</entry>
</row>
<row>
<entrytbl spanname="descr" cols="2">
<tbody valign="top">
<row>
<entry><constant>V4L2_FLASH_STROBE_SOURCE_SOFTWARE</constant></entry>
<entry>The flash strobe is triggered by using
the V4L2_CID_FLASH_STROBE control.</entry>
</row>
<row>
<entry><constant>V4L2_FLASH_STROBE_SOURCE_EXTERNAL</constant></entry>
<entry>The flash strobe is triggered by an
external source. Typically this is a sensor,
which makes it possible to synchronises the
flash strobe start to exposure start.</entry>
</row>
</tbody>
</entrytbl>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_FLASH_STROBE</constant></entry>
<entry>button</entry>
</row>
<row>
<entry spanname="descr">Strobe flash. Valid when
V4L2_CID_FLASH_LED_MODE is set to
V4L2_FLASH_LED_MODE_FLASH and V4L2_CID_FLASH_STROBE_SOURCE
is set to V4L2_FLASH_STROBE_SOURCE_SOFTWARE. Setting this
control may not be possible in presence of some faults.
See V4L2_CID_FLASH_FAULT.</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_FLASH_STROBE_STOP</constant></entry>
<entry>button</entry>
</row>
<row><entry spanname="descr">Stop flash strobe immediately.</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_FLASH_STROBE_STATUS</constant></entry>
<entry>boolean</entry>
</row>
<row>
<entry spanname="descr">Strobe status: whether the flash
is strobing at the moment or not. This is a read-only
control.</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_FLASH_TIMEOUT</constant></entry>
<entry>integer</entry>
</row>
<row>
<entry spanname="descr">Hardware timeout for flash. The
flash strobe is stopped after this period of time has
passed from the start of the strobe.</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_FLASH_INTENSITY</constant></entry>
<entry>integer</entry>
</row>
<row>
<entry spanname="descr">Intensity of the flash strobe when
the flash LED is in flash mode
(V4L2_FLASH_LED_MODE_FLASH). The unit should be milliamps
(mA) if possible.</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_FLASH_TORCH_INTENSITY</constant></entry>
<entry>integer</entry>
</row>
<row>
<entry spanname="descr">Intensity of the flash LED in
torch mode (V4L2_FLASH_LED_MODE_TORCH). The unit should be
milliamps (mA) if possible. Setting this control may not
be possible in presence of some faults. See
V4L2_CID_FLASH_FAULT.</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_FLASH_INDICATOR_INTENSITY</constant></entry>
<entry>integer</entry>
</row>
<row>
<entry spanname="descr">Intensity of the indicator LED.
The indicator LED may be fully independent of the flash
LED. The unit should be microamps (uA) if possible.</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_FLASH_FAULT</constant></entry>
<entry>bitmask</entry>
</row>
<row>
<entry spanname="descr">Faults related to the flash. The
faults tell about specific problems in the flash chip
itself or the LEDs attached to it. Faults may prevent
further use of some of the flash controls. In particular,
V4L2_CID_FLASH_LED_MODE is set to V4L2_FLASH_LED_MODE_NONE
if the fault affects the flash LED. Exactly which faults
have such an effect is chip dependent. Reading the faults
resets the control and returns the chip to a usable state
if possible.</entry>
</row>
<row>
<entrytbl spanname="descr" cols="2">
<tbody valign="top">
<row>
<entry><constant>V4L2_FLASH_FAULT_OVER_VOLTAGE</constant></entry>
<entry>Flash controller voltage to the flash LED
has exceeded the limit specific to the flash
controller.</entry>
</row>
<row>
<entry><constant>V4L2_FLASH_FAULT_TIMEOUT</constant></entry>
<entry>The flash strobe was still on when
the timeout set by the user ---
V4L2_CID_FLASH_TIMEOUT control --- has expired.
Not all flash controllers may set this in all
such conditions.</entry>
</row>
<row>
<entry><constant>V4L2_FLASH_FAULT_OVER_TEMPERATURE</constant></entry>
<entry>The flash controller has overheated.</entry>
</row>
<row>
<entry><constant>V4L2_FLASH_FAULT_SHORT_CIRCUIT</constant></entry>
<entry>The short circuit protection of the flash
controller has been triggered.</entry>
</row>
<row>
<entry><constant>V4L2_FLASH_FAULT_OVER_CURRENT</constant></entry>
<entry>Current in the LED power supply has exceeded the limit
specific to the flash controller.</entry>
</row>
<row>
<entry><constant>V4L2_FLASH_FAULT_INDICATOR</constant></entry>
<entry>The flash controller has detected a short or open
circuit condition on the indicator LED.</entry>
</row>
</tbody>
</entrytbl>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_FLASH_CHARGE</constant></entry>
<entry>boolean</entry>
</row>
<row><entry spanname="descr">Enable or disable charging of the xenon
flash capacitor.</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_FLASH_READY</constant></entry>
<entry>boolean</entry>
</row>
<row>
<entry spanname="descr">Is the flash ready to strobe?
Xenon flashes require their capacitors charged before
strobing. LED flashes often require a cooldown period
after strobe during which another strobe will not be
possible. This is a read-only control.</entry>
</row>
<row><entry></entry></row>
</tbody>
</tgroup>
</table>
</section>
<section id="jpeg-controls">
@ -4274,4 +4273,165 @@ interface and may change in the future.</para>
</table>
</section>
<section id="dv-controls">
<title>Digital Video Control Reference</title>
<note>
<title>Experimental</title>
<para>This is an <link
linkend="experimental">experimental</link> interface and may
change in the future.</para>
</note>
<para>
The Digital Video control class is intended to control receivers
and transmitters for <ulink url="http://en.wikipedia.org/wiki/Vga">VGA</ulink>,
<ulink url="http://en.wikipedia.org/wiki/Digital_Visual_Interface">DVI</ulink>
(Digital Visual Interface), HDMI (<xref linkend="hdmi" />) and DisplayPort (<xref linkend="dp" />).
These controls are generally expected to be private to the receiver or transmitter
subdevice that implements them, so they are only exposed on the
<filename>/dev/v4l-subdev*</filename> device node.
</para>
<para>Note that these devices can have multiple input or output pads which are
hooked up to e.g. HDMI connectors. Even though the subdevice will receive or
transmit video from/to only one of those pads, the other pads can still be
active when it comes to EDID (Extended Display Identification Data,
<xref linkend="vesaedid" />) and HDCP (High-bandwidth Digital Content
Protection System, <xref linkend="hdcp" />) processing, allowing the device
to do the fairly slow EDID/HDCP handling in advance. This allows for quick
switching between connectors.</para>
<para>These pads appear in several of the controls in this section as
bitmasks, one bit for each pad. Bit 0 corresponds to pad 0, bit 1 to pad 1,
etc. The maximum value of the control is the set of valid pads.</para>
<table pgwide="1" frame="none" id="dv-control-id">
<title>Digital Video Control IDs</title>
<tgroup cols="4">
<colspec colname="c1" colwidth="1*" />
<colspec colname="c2" colwidth="6*" />
<colspec colname="c3" colwidth="2*" />
<colspec colname="c4" colwidth="6*" />
<spanspec namest="c1" nameend="c2" spanname="id" />
<spanspec namest="c2" nameend="c4" spanname="descr" />
<thead>
<row>
<entry spanname="id" align="left">ID</entry>
<entry align="left">Type</entry>
</row><row rowsep="1"><entry spanname="descr" align="left">Description</entry>
</row>
</thead>
<tbody valign="top">
<row><entry></entry></row>
<row>
<entry spanname="id"><constant>V4L2_CID_DV_CLASS</constant></entry>
<entry>class</entry>
</row>
<row>
<entry spanname="descr">The Digital Video class descriptor.</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_DV_TX_HOTPLUG</constant></entry>
<entry>bitmask</entry>
</row>
<row>
<entry spanname="descr">Many connectors have a hotplug pin which is high
if EDID information is available from the source. This control shows the
state of the hotplug pin as seen by the transmitter.
Each bit corresponds to an output pad on the transmitter. If an output pad
does not have an associated hotplug pin, then the bit for that pad will be 0.
This read-only control is applicable to DVI-D, HDMI and DisplayPort connectors.
</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_DV_TX_RXSENSE</constant></entry>
<entry>bitmask</entry>
</row>
<row>
<entry spanname="descr">Rx Sense is the detection of pull-ups on the TMDS
clock lines. This normally means that the sink has left/entered standby (i.e.
the transmitter can sense that the receiver is ready to receive video).
Each bit corresponds to an output pad on the transmitter. If an output pad
does not have an associated Rx Sense, then the bit for that pad will be 0.
This read-only control is applicable to DVI-D and HDMI devices.
</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_DV_TX_EDID_PRESENT</constant></entry>
<entry>bitmask</entry>
</row>
<row>
<entry spanname="descr">When the transmitter sees the hotplug signal from the
receiver it will attempt to read the EDID. If set, then the transmitter has read
at least the first block (= 128 bytes).
Each bit corresponds to an output pad on the transmitter. If an output pad
does not support EDIDs, then the bit for that pad will be 0.
This read-only control is applicable to VGA, DVI-A/D, HDMI and DisplayPort connectors.
</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_DV_TX_MODE</constant></entry>
<entry id="v4l2-dv-tx-mode">enum v4l2_dv_tx_mode</entry>
</row>
<row>
<entry spanname="descr">HDMI transmitters can transmit in DVI-D mode (just video)
or in HDMI mode (video + audio + auxiliary data). This control selects which mode
to use: V4L2_DV_TX_MODE_DVI_D or V4L2_DV_TX_MODE_HDMI.
This control is applicable to HDMI connectors.
</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_DV_TX_RGB_RANGE</constant></entry>
<entry id="v4l2-dv-rgb-range">enum v4l2_dv_rgb_range</entry>
</row>
<row>
<entry spanname="descr">Select the quantization range for RGB output. V4L2_DV_RANGE_AUTO
follows the RGB quantization range specified in the standard for the video interface
(ie. <xref linkend="cea861" /> for HDMI). V4L2_DV_RANGE_LIMITED and V4L2_DV_RANGE_FULL override the standard
to be compatible with sinks that have not implemented the standard correctly
(unfortunately quite common for HDMI and DVI-D). Full range allows all possible values to be
used whereas limited range sets the range to (16 &lt;&lt; (N-8)) - (235 &lt;&lt; (N-8))
where N is the number of bits per component.
This control is applicable to VGA, DVI-A/D, HDMI and DisplayPort connectors.
</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_DV_RX_POWER_PRESENT</constant></entry>
<entry>bitmask</entry>
</row>
<row>
<entry spanname="descr">Detects whether the receiver receives power from the source
(e.g. HDMI carries 5V on one of the pins). This is often used to power an eeprom
which contains EDID information, such that the source can read the EDID even if
the sink is in standby/power off.
Each bit corresponds to an input pad on the transmitter. If an input pad
cannot detect whether power is present, then the bit for that pad will be 0.
This read-only control is applicable to DVI-D, HDMI and DisplayPort connectors.
</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_DV_RX_RGB_RANGE</constant></entry>
<entry>enum v4l2_dv_rgb_range</entry>
</row>
<row>
<entry spanname="descr">Select the quantization range for RGB input. V4L2_DV_RANGE_AUTO
follows the RGB quantization range specified in the standard for the video interface
(ie. <xref linkend="cea861" /> for HDMI). V4L2_DV_RANGE_LIMITED and V4L2_DV_RANGE_FULL override the standard
to be compatible with sources that have not implemented the standard correctly
(unfortunately quite common for HDMI and DVI-D). Full range allows all possible values to be
used whereas limited range sets the range to (16 &lt;&lt; (N-8)) - (235 &lt;&lt; (N-8))
where N is the number of bits per component.
This control is applicable to VGA, DVI-A/D, HDMI and DisplayPort connectors.
</entry>
</row>
<row><entry></entry></row>
</tbody>
</tgroup>
</table>
</section>
</section>

View File

@ -1,13 +1,6 @@
<title>Video Output Overlay Interface</title>
<subtitle>Also known as On-Screen Display (OSD)</subtitle>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental">experimental</link>
interface and may change in the future.</para>
</note>
<para>Some video output devices can overlay a framebuffer image onto
the outgoing video signal. Applications can set up such an overlay
using this interface, which borrows structures and ioctls of the <link

View File

@ -6,7 +6,7 @@ information, on an inaudible audio subcarrier of a radio program. This
interface is aimed at devices capable of receiving and/or transmitting RDS
information.</para>
<para>For more information see the core RDS standard <xref linkend="en50067" />
<para>For more information see the core RDS standard <xref linkend="iec62106" />
and the RBDS standard <xref linkend="nrsc4" />.</para>
<para>Note that the RBDS standard as is used in the USA is almost identical

View File

@ -374,29 +374,29 @@
rectangle --- if it is supported by the hardware.</para>
<orderedlist>
<listitem>Sink pad format. The user configures the sink pad
<listitem><para>Sink pad format. The user configures the sink pad
format. This format defines the parameters of the image the
entity receives through the pad for further processing.</listitem>
entity receives through the pad for further processing.</para></listitem>
<listitem>Sink pad actual crop selection. The sink pad crop
defines the crop performed to the sink pad format.</listitem>
<listitem><para>Sink pad actual crop selection. The sink pad crop
defines the crop performed to the sink pad format.</para></listitem>
<listitem>Sink pad actual compose selection. The size of the
<listitem><para>Sink pad actual compose selection. The size of the
sink pad compose rectangle defines the scaling ratio compared
to the size of the sink pad crop rectangle. The location of
the compose rectangle specifies the location of the actual
sink compose rectangle in the sink compose bounds
rectangle.</listitem>
rectangle.</para></listitem>
<listitem>Source pad actual crop selection. Crop on the source
<listitem><para>Source pad actual crop selection. Crop on the source
pad defines crop performed to the image in the sink compose
bounds rectangle.</listitem>
bounds rectangle.</para></listitem>
<listitem>Source pad format. The source pad format defines the
<listitem><para>Source pad format. The source pad format defines the
output pixel format of the subdev, as well as the other
parameters with the exception of the image width and height.
Width and height are defined by the size of the source pad
actual crop selection.</listitem>
actual crop selection.</para></listitem>
</orderedlist>
<para>Accessing any of the above rectangles not supported by the

View File

@ -6,6 +6,15 @@
&cs-str;
<tbody valign="top">
<!-- Keep it ordered alphabetically -->
<row>
<entry>EAGAIN (aka EWOULDBLOCK)</entry>
<entry>The ioctl can't be handled because the device is in state where
it can't perform it. This could happen for example in case where
device is sleeping and ioctl is performed to query statistics.
It is also returned when the ioctl would need to wait
for an event, but the device was opened in non-blocking mode.
</entry>
</row>
<row>
<entry>EBADF</entry>
<entry>The file descriptor is not a valid.</entry>
@ -50,22 +59,12 @@
that this request would overcommit the usb bandwidth reserved
for periodic transfers (up to 80% of the USB bandwidth).</entry>
</row>
<row>
<entry>ENOSYS or EOPNOTSUPP</entry>
<entry>Function not available for this device (dvb API only. Will likely
be replaced anytime soon by ENOTTY).</entry>
</row>
<row>
<entry>EPERM</entry>
<entry>Permission denied. Can be returned if the device needs write
permission, or some special capabilities is needed
(e. g. root)</entry>
</row>
<row>
<entry>EWOULDBLOCK</entry>
<entry>Operation would block. Used when the ioctl would need to wait
for an event, but the device was opened in non-blocking mode.</entry>
</row>
</tbody>
</tgroup>
</table>

View File

@ -613,8 +613,8 @@ field is independent of the <structfield>timestamp</structfield> and
<entry>__u32</entry>
<entry><structfield>sequence</structfield></entry>
<entry></entry>
<entry>Set by the driver, counting the frames in the
sequence.</entry>
<entry>Set by the driver, counting the frames (not fields!) in
sequence. This field is set for both input and output devices.</entry>
</row>
<row>
<entry spanname="hspan"><para>In <link
@ -685,18 +685,14 @@ memory, set by the application. See <xref linkend="userp" /> for details.
<entry>__u32</entry>
<entry><structfield>reserved2</structfield></entry>
<entry></entry>
<entry>A place holder for future extensions and custom
(driver defined) buffer types
<constant>V4L2_BUF_TYPE_PRIVATE</constant> and higher. Applications
<entry>A place holder for future extensions. Applications
should set this to 0.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield></entry>
<entry></entry>
<entry>A place holder for future extensions and custom
(driver defined) buffer types
<constant>V4L2_BUF_TYPE_PRIVATE</constant> and higher. Applications
<entry>A place holder for future extensions. Applications
should set this to 0.</entry>
</row>
</tbody>
@ -827,14 +823,7 @@ should set this to 0.</entry>
<entry><constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY</constant></entry>
<entry>8</entry>
<entry>Buffer for video output overlay (OSD), see <xref
linkend="osd" />. Status: <link
linkend="experimental">Experimental</link>.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_TYPE_PRIVATE</constant></entry>
<entry>0x80</entry>
<entry>This and higher values are reserved for custom
(driver defined) buffer types.</entry>
linkend="osd" />.</entry>
</row>
</tbody>
</tgroup>

View File

@ -22,8 +22,7 @@
with 10 bits per colour compressed to 8 bits each, using DPCM
compression. DPCM, differential pulse-code modulation, is lossy.
Each colour component consumes 8 bits of memory. In other respects
this format is similar to <xref
linkend="pixfmt-srggb10">.</xref></para>
this format is similar to <xref linkend="pixfmt-srggb10" />.</para>
</refsect1>
</refentry>

View File

@ -0,0 +1,154 @@
<refentry id="V4L2-PIX-FMT-YVU420M">
<refmeta>
<refentrytitle>V4L2_PIX_FMT_YVU420M ('YM21')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname> <constant>V4L2_PIX_FMT_YVU420M</constant></refname>
<refpurpose>Variation of <constant>V4L2_PIX_FMT_YVU420</constant>
with planes non contiguous in memory. </refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is a multi-planar format, as opposed to a packed format.
The three components are separated into three sub-images or planes.
The Y plane is first. The Y plane has one byte per pixel. The Cr data
constitutes the second plane which is half the width and half
the height of the Y plane (and of the image). Each Cr belongs to four
pixels, a two-by-two square of the image. For example,
Cr<subscript>0</subscript> belongs to Y'<subscript>00</subscript>,
Y'<subscript>01</subscript>, Y'<subscript>10</subscript>, and
Y'<subscript>11</subscript>. The Cb data, just like the Cr plane, constitutes
the third plane. </para>
<para>If the Y plane has pad bytes after each row, then the Cr
and Cb planes have half as many pad bytes after their rows. In other
words, two Cx rows (including padding) is exactly as long as one Y row
(including padding).</para>
<para><constant>V4L2_PIX_FMT_YVU420M</constant> is intended to be
used only in drivers and applications that support the multi-planar API,
described in <xref linkend="planar-apis"/>. </para>
<example>
<title><constant>V4L2_PIX_FMT_YVU420M</constant> 4 &times; 4
pixel image</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="5" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start0&nbsp;+&nbsp;0:</entry>
<entry>Y'<subscript>00</subscript></entry>
<entry>Y'<subscript>01</subscript></entry>
<entry>Y'<subscript>02</subscript></entry>
<entry>Y'<subscript>03</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;4:</entry>
<entry>Y'<subscript>10</subscript></entry>
<entry>Y'<subscript>11</subscript></entry>
<entry>Y'<subscript>12</subscript></entry>
<entry>Y'<subscript>13</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;8:</entry>
<entry>Y'<subscript>20</subscript></entry>
<entry>Y'<subscript>21</subscript></entry>
<entry>Y'<subscript>22</subscript></entry>
<entry>Y'<subscript>23</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;12:</entry>
<entry>Y'<subscript>30</subscript></entry>
<entry>Y'<subscript>31</subscript></entry>
<entry>Y'<subscript>32</subscript></entry>
<entry>Y'<subscript>33</subscript></entry>
</row>
<row><entry></entry></row>
<row>
<entry>start1&nbsp;+&nbsp;0:</entry>
<entry>Cr<subscript>00</subscript></entry>
<entry>Cr<subscript>01</subscript></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;2:</entry>
<entry>Cr<subscript>10</subscript></entry>
<entry>Cr<subscript>11</subscript></entry>
</row>
<row><entry></entry></row>
<row>
<entry>start2&nbsp;+&nbsp;0:</entry>
<entry>Cb<subscript>00</subscript></entry>
<entry>Cb<subscript>01</subscript></entry>
</row>
<row>
<entry>start2&nbsp;+&nbsp;2:</entry>
<entry>Cb<subscript>10</subscript></entry>
<entry>Cb<subscript>11</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
<formalpara>
<title>Color Sample Location.</title>
<para>
<informaltable frame="none">
<tgroup cols="7" align="center">
<tbody valign="top">
<row>
<entry></entry>
<entry>0</entry><entry></entry><entry>1</entry><entry></entry>
<entry>2</entry><entry></entry><entry>3</entry>
</row>
<row>
<entry>0</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
<row>
<entry></entry>
<entry></entry><entry>C</entry><entry></entry><entry></entry>
<entry></entry><entry>C</entry><entry></entry>
</row>
<row>
<entry>1</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
<row>
<entry></entry>
</row>
<row>
<entry>2</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
<row>
<entry></entry>
<entry></entry><entry>C</entry><entry></entry><entry></entry>
<entry></entry><entry>C</entry><entry></entry>
</row>
<row>
<entry>3</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>

View File

@ -708,6 +708,7 @@ information.</para>
&sub-y41p;
&sub-yuv420;
&sub-yuv420m;
&sub-yvu420m;
&sub-yuv410;
&sub-yuv422p;
&sub-yuv411p;

View File

@ -40,6 +40,7 @@ cropping and composing rectangles have the same size.</para>
<section>
<title>Selection targets</title>
<para>
<figure id="sel-targets-capture">
<title>Cropping and composing targets</title>
<mediaobject>
@ -52,12 +53,12 @@ cropping and composing rectangles have the same size.</para>
</textobject>
</mediaobject>
</figure>
</para>
<para>See <xref linkend="v4l2-selection-targets" /> for more
information.</para>
</section>
See <xref linkend="v4l2-selection-targets" /> for more
information.
<section>
<title>Configuration</title>
@ -216,18 +217,17 @@ composing and cropping operations by setting the appropriate targets. The V4L2
API lacks any support for composing to and cropping from an image inside a
memory buffer. The application could configure a capture device to fill only a
part of an image by abusing V4L2 API. Cropping a smaller image from a larger
one is achieved by setting the field <structfield>
&v4l2-pix-format;::bytesperline </structfield>. Introducing an image offsets
could be done by modifying field <structfield> &v4l2-buffer;::m:userptr
</structfield> before calling <constant> VIDIOC_QBUF </constant>. Those
one is achieved by setting the field
&v4l2-pix-format;<structfield>::bytesperline</structfield>. Introducing an image offsets
could be done by modifying field &v4l2-buffer;<structfield>::m_userptr</structfield>
before calling <constant> VIDIOC_QBUF </constant>. Those
operations should be avoided because they are not portable (endianness), and do
not work for macroblock and Bayer formats and mmap buffers. The selection API
deals with configuration of buffer cropping/composing in a clear, intuitive and
portable way. Next, with the selection API the concepts of the padded target
and constraints flags are introduced. Finally, <structname> &v4l2-crop;
</structname> and <structname> &v4l2-cropcap; </structname> have no reserved
fields. Therefore there is no way to extend their functionality. The new
<structname> &v4l2-selection; </structname> provides a lot of place for future
and constraints flags are introduced. Finally, &v4l2-crop; and &v4l2-cropcap;
have no reserved fields. Therefore there is no way to extend their functionality.
The new &v4l2-selection; provides a lot of place for future
extensions. Driver developers are encouraged to implement only selection API.
The former cropping API would be simulated using the new one. </para>

View File

@ -145,9 +145,12 @@ applications. -->
<authorinitials>hv</authorinitials>
<revremark>Added VIDIOC_ENUM_FREQ_BANDS.
</revremark>
</revision>
<revision>
<revnumber>3.5</revnumber>
<date>2012-05-07</date>
<authorinitials>sa, sn</authorinitials>
<authorinitials>sa, sn, hv</authorinitials>
<revremark>Added V4L2_CTRL_TYPE_INTEGER_MENU and V4L2 subdev
selections API. Improved the description of V4L2_CID_COLORFX
control, added V4L2_CID_COLORFX_CBCR control.
@ -158,11 +161,8 @@ applications. -->
V4L2_CID_3A_LOCK, V4L2_CID_AUTO_FOCUS_START,
V4L2_CID_AUTO_FOCUS_STOP, V4L2_CID_AUTO_FOCUS_STATUS
and V4L2_CID_AUTO_FOCUS_RANGE.
</revremark>
<date>2012-05-01</date>
<authorinitials>hv</authorinitials>
<revremark>Added VIDIOC_ENUM_DV_TIMINGS, VIDIOC_QUERY_DV_TIMINGS and
VIDIOC_DV_TIMINGS_CAP.
Added VIDIOC_ENUM_DV_TIMINGS, VIDIOC_QUERY_DV_TIMINGS and
VIDIOC_DV_TIMINGS_CAP.
</revremark>
</revision>
@ -472,7 +472,7 @@ and discussions on the V4L mailing list.</revremark>
</partinfo>
<title>Video for Linux Two API Specification</title>
<subtitle>Revision 3.5</subtitle>
<subtitle>Revision 3.6</subtitle>
<chapter id="common">
&sub-common;
@ -581,6 +581,7 @@ and discussions on the V4L mailing list.</revremark>
&sub-subdev-enum-frame-size;
&sub-subdev-enum-mbus-code;
&sub-subdev-g-crop;
&sub-subdev-g-edid;
&sub-subdev-g-fmt;
&sub-subdev-g-frame-interval;
&sub-subdev-g-selection;

View File

@ -59,6 +59,9 @@ constant except when switching the video standard. Remember this
switch can occur implicit when switching the video input or
output.</para>
<para>This ioctl must be implemented for video capture or output devices that
support cropping and/or scaling and/or have non-square pixels, and for overlay devices.</para>
<table pgwide="1" frame="none" id="v4l2-cropcap">
<title>struct <structname>v4l2_cropcap</structname></title>
<tgroup cols="3">
@ -70,10 +73,10 @@ output.</para>
<entry>Type of the data stream, set by the application.
Only these types are valid here:
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>,
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant>,
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant>,
<constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>, and custom (driver
defined) types with code <constant>V4L2_BUF_TYPE_PRIVATE</constant>
and higher. See <xref linkend="v4l2-buf-type" />.</entry>
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant> and
<constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>. See <xref linkend="v4l2-buf-type" />.</entry>
</row>
<row>
<entry>struct <link linkend="v4l2-rect-crop">v4l2_rect</link></entry>
@ -156,8 +159,7 @@ on 22 Oct 2002 subject "Re:[V4L][patches!] Re:v4l2/kernel-2.5" -->
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The &v4l2-cropcap; <structfield>type</structfield> is
invalid. This is not permitted for video capture, output and overlay devices,
which must support <constant>VIDIOC_CROPCAP</constant>.</para>
invalid.</para>
</listitem>
</varlistentry>
</variablelist>

View File

@ -49,13 +49,6 @@
<refsect1>
<title>Description</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental">experimental</link>
interface and may change in the future.</para>
</note>
<para>These ioctls control an audio/video (usually MPEG-) decoder.
<constant>VIDIOC_DECODER_CMD</constant> sends a command to the
decoder, <constant>VIDIOC_TRY_DECODER_CMD</constant> can be used to

View File

@ -49,13 +49,6 @@
<refsect1>
<title>Description</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental">experimental</link>
interface and may change in the future.</para>
</note>
<para>These ioctls control an audio/video (usually MPEG-) encoder.
<constant>VIDIOC_ENCODER_CMD</constant> sends a command to the
encoder, <constant>VIDIOC_TRY_ENCODER_CMD</constant> can be used to

View File

@ -229,6 +229,12 @@ intended for the user.</entry>
is out of bounds.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>ENODATA</errorcode></term>
<listitem>
<para>Digital video presets are not supported for this input or output.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>

View File

@ -106,6 +106,12 @@ application.</entry>
is out of bounds.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>ENODATA</errorcode></term>
<listitem>
<para>Digital video presets are not supported for this input or output.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>

View File

@ -58,6 +58,9 @@ structure. Drivers fill the rest of the structure or return an
incrementing by one until <errorcode>EINVAL</errorcode> is
returned.</para>
<para>Note that after switching input or output the list of enumerated image
formats may be different.</para>
<table pgwide="1" frame="none" id="v4l2-fmtdesc">
<title>struct <structname>v4l2_fmtdesc</structname></title>
<tgroup cols="3">
@ -78,10 +81,8 @@ Only these types are valid here:
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>,
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant>,
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant>,
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant>,
<constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>, and custom (driver
defined) types with code <constant>V4L2_BUF_TYPE_PRIVATE</constant>
and higher. See <xref linkend="v4l2-buf-type" />.</entry>
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant> and
<constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>. See <xref linkend="v4l2-buf-type" />.</entry>
</row>
<row>
<entry>__u32</entry>

View File

@ -50,13 +50,6 @@ and pixel format and receives a frame width and height.</para>
<refsect1>
<title>Description</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental">experimental</link>
interface and may change in the future.</para>
</note>
<para>This ioctl allows applications to enumerate all frame sizes
(&ie; width and height in pixels) that the device supports for the
given pixel format.</para>

View File

@ -283,7 +283,7 @@ input/output interface to linux-media@vger.kernel.org on 19 Oct 2009.
<entry>This input supports setting DV presets by using VIDIOC_S_DV_PRESET.</entry>
</row>
<row>
<entry><constant>V4L2_IN_CAP_CUSTOM_TIMINGS</constant></entry>
<entry><constant>V4L2_IN_CAP_DV_TIMINGS</constant></entry>
<entry>0x00000002</entry>
<entry>This input supports setting video timings by using VIDIOC_S_DV_TIMINGS.</entry>
</row>

View File

@ -168,7 +168,7 @@ input/output interface to linux-media@vger.kernel.org on 19 Oct 2009.
<entry>This output supports setting DV presets by using VIDIOC_S_DV_PRESET.</entry>
</row>
<row>
<entry><constant>V4L2_OUT_CAP_CUSTOM_TIMINGS</constant></entry>
<entry><constant>V4L2_OUT_CAP_DV_TIMINGS</constant></entry>
<entry>0x00000002</entry>
<entry>This output supports setting video timings by using VIDIOC_S_DV_TIMINGS.</entry>
</row>

View File

@ -378,6 +378,12 @@ system)</para></footnote></para></entry>
is out of bounds.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>ENODATA</errorcode></term>
<listitem>
<para>Standard video timings are not supported for this input or output.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>

View File

@ -104,10 +104,8 @@ changed and <constant>VIDIOC_S_CROP</constant> returns the
<entry><structfield>type</structfield></entry>
<entry>Type of the data stream, set by the application.
Only these types are valid here: <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>,
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant>,
<constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>, and custom (driver
defined) types with code <constant>V4L2_BUF_TYPE_PRIVATE</constant>
and higher. See <xref linkend="v4l2-buf-type" />.</entry>
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant> and
<constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>. See <xref linkend="v4l2-buf-type" />.</entry>
</row>
<row>
<entry>&v4l2-rect;</entry>

View File

@ -77,6 +77,12 @@ If the preset is not supported, it returns an &EINVAL; </para>
<constant>VIDIOC_S_DV_PRESET</constant>,<constant>VIDIOC_S_DV_PRESET</constant> parameter was unsuitable.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>ENODATA</errorcode></term>
<listitem>
<para>Digital video presets are not supported for this input or output.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>EBUSY</errorcode></term>
<listitem>
@ -104,7 +110,4 @@ If the preset is not supported, it returns an &EINVAL; </para>
</tgroup>
</table>
</refsect1>
<refsect1>
&return-value;
</refsect1>
</refentry>

View File

@ -56,7 +56,9 @@ a pointer to the &v4l2-dv-timings; structure as argument. If the ioctl is not su
or the timing values are not correct, the driver returns &EINVAL;.</para>
<para>The <filename>linux/v4l2-dv-timings.h</filename> header can be used to get the
timings of the formats in the <xref linkend="cea861" /> and <xref linkend="vesadmt" />
standards.</para>
standards. If the current input or output does not support DV timings (e.g. if
&VIDIOC-ENUMINPUT; does not set the <constant>V4L2_IN_CAP_DV_TIMINGS</constant> flag), then
&ENODATA; is returned.</para>
</refsect1>
<refsect1>
@ -70,6 +72,12 @@ standards.</para>
<constant>VIDIOC_S_DV_TIMINGS</constant> parameter was unsuitable.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>ENODATA</errorcode></term>
<listitem>
<para>Digital video timings are not supported for this input or output.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>EBUSY</errorcode></term>
<listitem>
@ -320,7 +328,4 @@ detected or used depends on the hardware.
</tgroup>
</table>
</refsect1>
<refsect1>
&return-value;
</refsect1>
</refentry>

View File

@ -48,13 +48,6 @@
<refsect1>
<title>Description</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental">experimental</link>
interface and may change in the future.</para>
</note>
<para>The <constant>VIDIOC_G_ENC_INDEX</constant> ioctl provides
meta data about a compressed video stream the same or another
application currently reads from the driver, which is useful for

View File

@ -81,7 +81,7 @@ the application calls the <constant>VIDIOC_S_FMT</constant> ioctl
with a pointer to a <structname>v4l2_format</structname> structure
the driver checks
and adjusts the parameters against hardware abilities. Drivers
should not return an error code unless the input is ambiguous, this is
should not return an error code unless the <structfield>type</structfield> field is invalid, this is
a mechanism to fathom device capabilities and to approach parameters
acceptable for both the application and driver. On success the driver
may program the hardware, allocate resources and generally prepare for
@ -107,6 +107,10 @@ disabling I/O or possibly time consuming hardware preparations.
Although strongly recommended drivers are not required to implement
this ioctl.</para>
<para>The format as returned by <constant>VIDIOC_TRY_FMT</constant>
must be identical to what <constant>VIDIOC_S_FMT</constant> returns for
the same input or output.</para>
<table pgwide="1" frame="none" id="v4l2-format">
<title>struct <structname>v4l2_format</structname></title>
<tgroup cols="4">
@ -170,9 +174,7 @@ capture and output devices.</entry>
<entry></entry>
<entry>__u8</entry>
<entry><structfield>raw_data</structfield>[200]</entry>
<entry>Place holder for future extensions and custom
(driver defined) formats with <structfield>type</structfield>
<constant>V4L2_BUF_TYPE_PRIVATE</constant> and higher.</entry>
<entry>Place holder for future extensions.</entry>
</row>
</tbody>
</tgroup>
@ -187,8 +189,7 @@ capture and output devices.</entry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The &v4l2-format; <structfield>type</structfield>
field is invalid, the requested buffer type not supported, or the
format is not supported with this buffer type.</para>
field is invalid or the requested buffer type not supported.</para>
</listitem>
</varlistentry>
</variablelist>

View File

@ -108,9 +108,7 @@ devices.</para>
<entry></entry>
<entry>__u8</entry>
<entry><structfield>raw_data</structfield>[200]</entry>
<entry>A place holder for future extensions and custom
(driver defined) buffer types <constant>V4L2_BUF_TYPE_PRIVATE</constant> and
higher.</entry>
<entry>A place holder for future extensions.</entry>
</row>
</tbody>
</tgroup>

View File

@ -152,12 +152,10 @@ satisfactory parameters have been negotiated. If constraints flags have to be
violated at then ERANGE is returned. The error indicates that <emphasis> there
exist no rectangle </emphasis> that satisfies the constraints.</para>
</refsect1>
<para>Selection targets and flags are documented in <xref
linkend="v4l2-selections-common"/>.</para>
<section>
<para>
<figure id="sel-const-adjust">
<title>Size adjustments with constraint flags.</title>
<mediaobject>
@ -170,9 +168,9 @@ exist no rectangle </emphasis> that satisfies the constraints.</para>
</textobject>
</mediaobject>
</figure>
</section>
</para>
<refsect1>
<para>
<table pgwide="1" frame="none" id="v4l2-selection">
<title>struct <structname>v4l2_selection</structname></title>
<tgroup cols="3">
@ -208,6 +206,7 @@ exist no rectangle </emphasis> that satisfies the constraints.</para>
</tbody>
</tgroup>
</table>
</para>
</refsect1>
<refsect1>

View File

@ -72,7 +72,9 @@ flags, being a write-only ioctl it does not return the actual new standard as
the current input does not support the requested standard the driver
returns an &EINVAL;. When the standard set is ambiguous drivers may
return <errorcode>EINVAL</errorcode> or choose any of the requested
standards.</para>
standards. If the current input or output does not support standard video timings (e.g. if
&VIDIOC-ENUMINPUT; does not set the <constant>V4L2_IN_CAP_STD</constant> flag), then
&ENODATA; is returned.</para>
</refsect1>
<refsect1>
@ -85,6 +87,12 @@ standards.</para>
<para>The <constant>VIDIOC_S_STD</constant> parameter was unsuitable.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>ENODATA</errorcode></term>
<listitem>
<para>Standard video timings are not supported for this input or output.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>

View File

@ -354,6 +354,12 @@ radio tuners.</entry>
<entry>The &VIDIOC-ENUM-FREQ-BANDS; ioctl can be used to enumerate
the available frequency bands.</entry>
</row>
<row>
<entry><constant>V4L2_TUNER_CAP_HWSEEK_PROG_LIM</constant></entry>
<entry>0x0800</entry>
<entry>The range to search when using the hardware seek functionality
is programmable, see &VIDIOC-S-HW-FREQ-SEEK; for details.</entry>
</row>
</tbody>
</tgroup>
</table>

View File

@ -155,6 +155,8 @@ or no buffers have been allocated yet, or the
<structfield>userptr</structfield> or
<structfield>length</structfield> are invalid.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>EIO</errorcode></term>
<listitem>
<para><constant>VIDIOC_DQBUF</constant> failed due to an

View File

@ -65,5 +65,14 @@ returned.</para>
<refsect1>
&return-value;
<variablelist>
<varlistentry>
<term><errorcode>ENODATA</errorcode></term>
<listitem>
<para>Digital video presets are not supported for this input or output.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>

View File

@ -77,6 +77,12 @@ capabilities in order to give more precise feedback to the user.
&return-value;
<variablelist>
<varlistentry>
<term><errorcode>ENODATA</errorcode></term>
<listitem>
<para>Digital video timings are not supported for this input or output.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>ENOLINK</errorcode></term>
<listitem>

View File

@ -90,11 +90,13 @@ ambiguities.</entry>
<entry>__u8</entry>
<entry><structfield>bus_info</structfield>[32]</entry>
<entry>Location of the device in the system, a
NUL-terminated ASCII string. For example: "PCI Slot 4". This
NUL-terminated ASCII string. For example: "PCI:0000:05:06.0". This
information is intended for users, to distinguish multiple
identical devices. If no such information is available the field may
simply count the devices controlled by the driver, or contain the
empty string (<structfield>bus_info</structfield>[0] = 0).<!-- XXX pci_dev->slot_name example --></entry>
identical devices. If no such information is available the field must
simply count the devices controlled by the driver ("platform:vivi-000").
The bus_info must start with "PCI:" for PCI boards, "PCIe:" for PCI Express boards,
"usb-" for USB devices, "I2C:" for i2c devices, "ISA:" for ISA devices,
"parport" for parallel port devices and "platform:" for platform devices.</entry>
</row>
<row>
<entry>__u32</entry>

View File

@ -62,5 +62,13 @@ current video input or output.</para>
<refsect1>
&return-value;
<variablelist>
<varlistentry>
<term><errorcode>ENODATA</errorcode></term>
<listitem>
<para>Standard video timings are not supported for this input or output.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>

View File

@ -109,9 +109,8 @@ as the &v4l2-format; <structfield>type</structfield> field. See <xref
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[2]</entry>
<entry>A place holder for future extensions and custom
(driver defined) buffer types <constant>V4L2_BUF_TYPE_PRIVATE</constant> and
higher. This array should be zeroed by applications.</entry>
<entry>A place holder for future extensions. This array should
be zeroed by applications.</entry>
</row>
</tbody>
</tgroup>

View File

@ -75,6 +75,9 @@ seek is started.</para>
<para>This ioctl is supported if the <constant>V4L2_CAP_HW_FREQ_SEEK</constant> capability is set.</para>
<para>If this ioctl is called from a non-blocking filehandle, then &EAGAIN; is
returned and no seek takes place.</para>
<table pgwide="1" frame="none" id="v4l2-hw-freq-seek">
<title>struct <structname>v4l2_hw_freq_seek</structname></title>
<tgroup cols="3">
@ -157,6 +160,13 @@ one of the values in the <structfield>type</structfield>,
fields is wrong.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>EAGAIN</errorcode></term>
<listitem>
<para>Attempted to call <constant>VIDIOC_S_HW_FREQ_SEEK</constant>
with the filehandle in non-blocking mode.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>ENODATA</errorcode></term>
<listitem>

View File

@ -74,7 +74,12 @@ not transmitted yet. I/O returns to the same state as after calling
stream type. This is the same as &v4l2-requestbuffers;
<structfield>type</structfield>.</para>
<para>Note applications can be preempted for unknown periods right
<para>If <constant>VIDIOC_STREAMON</constant> is called when streaming
is already in progress, or if <constant>VIDIOC_STREAMOFF</constant> is called
when streaming is already stopped, then the ioctl does nothing and 0 is
returned.</para>
<para>Note that applications can be preempted for unknown periods right
before or after the <constant>VIDIOC_STREAMON</constant> or
<constant>VIDIOC_STREAMOFF</constant> calls, there is no notion of
starting or stopping "now". Buffer timestamps can be used to

View File

@ -0,0 +1,152 @@
<refentry id="vidioc-subdev-g-edid">
<refmeta>
<refentrytitle>ioctl VIDIOC_SUBDEV_G_EDID, VIDIOC_SUBDEV_S_EDID</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>VIDIOC_SUBDEV_G_EDID</refname>
<refname>VIDIOC_SUBDEV_S_EDID</refname>
<refpurpose>Get or set the EDID of a video receiver/transmitter</refpurpose>
</refnamediv>
<refsynopsisdiv>
<funcsynopsis>
<funcprototype>
<funcdef>int <function>ioctl</function></funcdef>
<paramdef>int <parameter>fd</parameter></paramdef>
<paramdef>int <parameter>request</parameter></paramdef>
<paramdef>struct v4l2_subdev_edid *<parameter>argp</parameter></paramdef>
</funcprototype>
</funcsynopsis>
<funcsynopsis>
<funcprototype>
<funcdef>int <function>ioctl</function></funcdef>
<paramdef>int <parameter>fd</parameter></paramdef>
<paramdef>int <parameter>request</parameter></paramdef>
<paramdef>const struct v4l2_subdev_edid *<parameter>argp</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>&fd;</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>VIDIOC_SUBDEV_G_EDID, VIDIOC_SUBDEV_S_EDID</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para></para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>These ioctls can be used to get or set an EDID associated with an input pad
from a receiver or an output pad of a transmitter subdevice.</para>
<para>To get the EDID data the application has to fill in the <structfield>pad</structfield>,
<structfield>start_block</structfield>, <structfield>blocks</structfield> and <structfield>edid</structfield>
fields and call <constant>VIDIOC_SUBDEV_G_EDID</constant>. The current EDID from block
<structfield>start_block</structfield> and of size <structfield>blocks</structfield>
will be placed in the memory <structfield>edid</structfield> points to. The <structfield>edid</structfield>
pointer must point to memory at least <structfield>blocks</structfield>&nbsp;*&nbsp;128 bytes
large (the size of one block is 128 bytes).</para>
<para>If there are fewer blocks than specified, then the driver will set <structfield>blocks</structfield>
to the actual number of blocks. If there are no EDID blocks available at all, then the error code
ENODATA is set.</para>
<para>If blocks have to be retrieved from the sink, then this call will block until they
have been read.</para>
<para>To set the EDID blocks of a receiver the application has to fill in the <structfield>pad</structfield>,
<structfield>blocks</structfield> and <structfield>edid</structfield> fields and set
<structfield>start_block</structfield> to 0. It is not possible to set part of an EDID,
it is always all or nothing. Setting the EDID data is only valid for receivers as it makes
no sense for a transmitter.</para>
<para>The driver assumes that the full EDID is passed in. If there are more EDID blocks than
the hardware can handle then the EDID is not written, but instead the error code E2BIG is set
and <structfield>blocks</structfield> is set to the maximum that the hardware supports.
If <structfield>start_block</structfield> is any
value other than 0 then the error code EINVAL is set.</para>
<para>To disable an EDID you set <structfield>blocks</structfield> to 0. Depending on the
hardware this will drive the hotplug pin low and/or block the source from reading the EDID
data in some way. In any case, the end result is the same: the EDID is no longer available.
</para>
<table pgwide="1" frame="none" id="v4l2-subdev-edid">
<title>struct <structname>v4l2_subdev_edid</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>pad</structfield></entry>
<entry>Pad for which to get/set the EDID blocks.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>start_block</structfield></entry>
<entry>Read the EDID from starting with this block. Must be 0 when setting
the EDID.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>blocks</structfield></entry>
<entry>The number of blocks to get or set. Must be less or equal to 256 (the
maximum number of blocks as defined by the standard). When you set the EDID and
<structfield>blocks</structfield> is 0, then the EDID is disabled or erased.</entry>
</row>
<row>
<entry>__u8&nbsp;*</entry>
<entry><structfield>edid</structfield></entry>
<entry>Pointer to memory that contains the EDID. The minimum size is
<structfield>blocks</structfield>&nbsp;*&nbsp;128.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[5]</entry>
<entry>Reserved for future extensions. Applications and drivers must
set the array to zero.</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
<refsect1>
&return-value;
<variablelist>
<varlistentry>
<term><errorcode>ENODATA</errorcode></term>
<listitem>
<para>The EDID data is not available.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>E2BIG</errorcode></term>
<listitem>
<para>The EDID data you provided is more than the hardware can handle.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>

View File

@ -69,23 +69,22 @@
more information on how each selection target affects the image
processing pipeline inside the subdevice.</para>
<section>
<refsect2>
<title>Types of selection targets</title>
<para>There are two types of selection targets: actual and bounds. The
actual targets are the targets which configure the hardware. The BOUNDS
target will return a rectangle that contain all possible actual
rectangles.</para>
</section>
</refsect2>
<section>
<refsect2>
<title>Discovering supported features</title>
<para>To discover which targets are supported, the user can
perform <constant>VIDIOC_SUBDEV_G_SELECTION</constant> on them.
Any unsupported target will return
<constant>EINVAL</constant>.</para>
</section>
<para>Selection targets and flags are documented in <xref
linkend="v4l2-selections-common"/>.</para>
@ -132,6 +131,7 @@
</tbody>
</tgroup>
</table>
</refsect2>
</refsect1>

View File

@ -29,7 +29,7 @@
<title>LINUX MEDIA INFRASTRUCTURE API</title>
<copyright>
<year>2009-2011</year>
<year>2009-2012</year>
<holder>LinuxTV Developers</holder>
</copyright>
@ -53,7 +53,7 @@ Foundation. A copy of the license is included in the chapter entitled
video and radio straming devices, including video cameras,
analog and digital TV receiver cards, AM/FM receiver cards,
streaming capture devices.</para>
<para>It is divided into three parts.</para>
<para>It is divided into four parts.</para>
<para>The first part covers radio, capture,
cameras and analog TV devices.</para>
<para>The second part covers the
@ -62,7 +62,8 @@ Foundation. A copy of the license is included in the chapter entitled
in fact it covers several different video standards including
DVB-T, DVB-S, DVB-C and ATSC. The API is currently being updated
to documment support also for DVB-S2, ISDB-T and ISDB-S.</para>
<para>The third part covers Remote Controller API</para>
<para>The third part covers the Remote Controller API.</para>
<para>The fourth part covers the Media Controller API.</para>
<para>For additional information and for the latest development code,
see: <ulink url="http://linuxtv.org">http://linuxtv.org</ulink>.</para>
<para>For discussing improvements, reporting troubles, sending new drivers, etc, please mail to: <ulink url="http://vger.kernel.org/vger-lists.html#linux-media">Linux Media Mailing List (LMML).</ulink>.</para>
@ -87,7 +88,7 @@ Foundation. A copy of the license is included in the chapter entitled
</author>
</authorgroup>
<copyright>
<year>2009-2011</year>
<year>2009-2012</year>
<holder>Mauro Carvalho Chehab</holder>
</copyright>

View File

@ -93,6 +93,7 @@ Linux IRQ number into the hardware.
Most drivers cannot use this mapping.
==== Legacy ====
irq_domain_add_simple()
irq_domain_add_legacy()
irq_domain_add_legacy_isa()
@ -115,3 +116,7 @@ The legacy map should only be used if fixed IRQ mappings must be
supported. For example, ISA controllers would use the legacy map for
mapping Linux IRQs 0-15 so that existing ISA drivers get the correct IRQ
numbers.
Most users of legacy mappings should use irq_domain_add_simple() which
will use a legacy domain only if an IRQ range is supplied by the
system and will otherwise use a linear domain mapping.

View File

@ -3,15 +3,21 @@
biodoc.txt
- Notes on the Generic Block Layer Rewrite in Linux 2.5
capability.txt
- Generic Block Device Capability (/sys/block/<disk>/capability)
- Generic Block Device Capability (/sys/block/<device>/capability)
cfq-iosched.txt
- CFQ IO scheduler tunables
data-integrity.txt
- Block data integrity
deadline-iosched.txt
- Deadline IO scheduler tunables
ioprio.txt
- Block io priorities (in CFQ scheduler)
queue-sysfs.txt
- Queue's sysfs entries
request.txt
- The members of struct request (in include/linux/blkdev.h)
stat.txt
- Block layer statistics in /sys/block/<dev>/stat
- Block layer statistics in /sys/block/<device>/stat
switching-sched.txt
- Switching I/O schedulers at runtime
writeback_cache_control.txt

View File

@ -1,3 +1,14 @@
CFQ (Complete Fairness Queueing)
===============================
The main aim of CFQ scheduler is to provide a fair allocation of the disk
I/O bandwidth for all the processes which requests an I/O operation.
CFQ maintains the per process queue for the processes which request I/O
operation(syncronous requests). In case of asynchronous requests, all the
requests from all the processes are batched together according to their
process's I/O priority.
CFQ ioscheduler tunables
========================
@ -25,6 +36,72 @@ there are multiple spindles behind single LUN (Host based hardware RAID
controller or for storage arrays), setting slice_idle=0 might end up in better
throughput and acceptable latencies.
back_seek_max
-------------
This specifies, given in Kbytes, the maximum "distance" for backward seeking.
The distance is the amount of space from the current head location to the
sectors that are backward in terms of distance.
This parameter allows the scheduler to anticipate requests in the "backward"
direction and consider them as being the "next" if they are within this
distance from the current head location.
back_seek_penalty
-----------------
This parameter is used to compute the cost of backward seeking. If the
backward distance of request is just 1/back_seek_penalty from a "front"
request, then the seeking cost of two requests is considered equivalent.
So scheduler will not bias toward one or the other request (otherwise scheduler
will bias toward front request). Default value of back_seek_penalty is 2.
fifo_expire_async
-----------------
This parameter is used to set the timeout of asynchronous requests. Default
value of this is 248ms.
fifo_expire_sync
----------------
This parameter is used to set the timeout of synchronous requests. Default
value of this is 124ms. In case to favor synchronous requests over asynchronous
one, this value should be decreased relative to fifo_expire_async.
slice_async
-----------
This parameter is same as of slice_sync but for asynchronous queue. The
default value is 40ms.
slice_async_rq
--------------
This parameter is used to limit the dispatching of asynchronous request to
device request queue in queue's slice time. The maximum number of request that
are allowed to be dispatched also depends upon the io priority. Default value
for this is 2.
slice_sync
----------
When a queue is selected for execution, the queues IO requests are only
executed for a certain amount of time(time_slice) before switching to another
queue. This parameter is used to calculate the time slice of synchronous
queue.
time_slice is computed using the below equation:-
time_slice = slice_sync + (slice_sync/5 * (4 - prio)). To increase the
time_slice of synchronous queue, increase the value of slice_sync. Default
value is 100ms.
quantum
-------
This specifies the number of request dispatched to the device queue. In a
queue's time slice, a request will not be dispatched if the number of request
in the device exceeds this parameter. This parameter is used for synchronous
request.
In case of storage with several disk, this setting can limit the parallel
processing of request. Therefore, increasing the value can imporve the
performace although this can cause the latency of some I/O to increase due
to more number of requests.
CFQ IOPS Mode for group scheduling
===================================
Basic CFQ design is to provide priority based time slices. Higher priority

View File

@ -9,20 +9,71 @@ These files are the ones found in the /sys/block/xxx/queue/ directory.
Files denoted with a RO postfix are readonly and the RW postfix means
read-write.
add_random (RW)
----------------
This file allows to trun off the disk entropy contribution. Default
value of this file is '1'(on).
discard_granularity (RO)
-----------------------
This shows the size of internal allocation of the device in bytes, if
reported by the device. A value of '0' means device does not support
the discard functionality.
discard_max_bytes (RO)
----------------------
Devices that support discard functionality may have internal limits on
the number of bytes that can be trimmed or unmapped in a single operation.
The discard_max_bytes parameter is set by the device driver to the maximum
number of bytes that can be discarded in a single operation. Discard
requests issued to the device must not exceed this limit. A discard_max_bytes
value of 0 means that the device does not support discard functionality.
discard_zeroes_data (RO)
------------------------
When read, this file will show if the discarded block are zeroed by the
device or not. If its value is '1' the blocks are zeroed otherwise not.
hw_sector_size (RO)
-------------------
This is the hardware sector size of the device, in bytes.
iostats (RW)
-------------
This file is used to control (on/off) the iostats accounting of the
disk.
logical_block_size (RO)
-----------------------
This is the logcal block size of the device, in bytes.
max_hw_sectors_kb (RO)
----------------------
This is the maximum number of kilobytes supported in a single data transfer.
max_integrity_segments (RO)
---------------------------
When read, this file shows the max limit of integrity segments as
set by block layer which a hardware controller can handle.
max_sectors_kb (RW)
-------------------
This is the maximum number of kilobytes that the block layer will allow
for a filesystem request. Must be smaller than or equal to the maximum
size allowed by the hardware.
max_segments (RO)
-----------------
Maximum number of segments of the device.
max_segment_size (RO)
---------------------
Maximum segment size of the device.
minimum_io_size (RO)
--------------------
This is the smallest preferred io size reported by the device.
nomerges (RW)
-------------
This enables the user to disable the lookup logic involved with IO
@ -38,11 +89,31 @@ read or write requests. Note that the total allocated number may be twice
this amount, since it applies only to reads or writes (not the accumulated
sum).
To avoid priority inversion through request starvation, a request
queue maintains a separate request pool per each cgroup when
CONFIG_BLK_CGROUP is enabled, and this parameter applies to each such
per-block-cgroup request pool. IOW, if there are N block cgroups,
each request queue may have upto N request pools, each independently
regulated by nr_requests.
optimal_io_size (RO)
--------------------
This is the optimal io size reported by the device.
physical_block_size (RO)
------------------------
This is the physical block size of device, in bytes.
read_ahead_kb (RW)
------------------
Maximum number of kilobytes to read-ahead for filesystems on this block
device.
rotational (RW)
---------------
This file is used to stat if the device is of rotational type or
non-rotational type.
rq_affinity (RW)
----------------
If this option is '1', the block layer will migrate request completions to the

View File

@ -0,0 +1,45 @@
HugeTLB Controller
-------------------
The HugeTLB controller allows to limit the HugeTLB usage per control group and
enforces the controller limit during page fault. Since HugeTLB doesn't
support page reclaim, enforcing the limit at page fault time implies that,
the application will get SIGBUS signal if it tries to access HugeTLB pages
beyond its limit. This requires the application to know beforehand how much
HugeTLB pages it would require for its use.
HugeTLB controller can be created by first mounting the cgroup filesystem.
# mount -t cgroup -o hugetlb none /sys/fs/cgroup
With the above step, the initial or the parent HugeTLB group becomes
visible at /sys/fs/cgroup. At bootup, this group includes all the tasks in
the system. /sys/fs/cgroup/tasks lists the tasks in this cgroup.
New groups can be created under the parent group /sys/fs/cgroup.
# cd /sys/fs/cgroup
# mkdir g1
# echo $$ > g1/tasks
The above steps create a new group g1 and move the current shell
process (bash) into it.
Brief summary of control files
hugetlb.<hugepagesize>.limit_in_bytes # set/show limit of "hugepagesize" hugetlb usage
hugetlb.<hugepagesize>.max_usage_in_bytes # show max "hugepagesize" hugetlb usage recorded
hugetlb.<hugepagesize>.usage_in_bytes # show current res_counter usage for "hugepagesize" hugetlb
hugetlb.<hugepagesize>.failcnt # show the number of allocation failure due to HugeTLB limit
For a system supporting two hugepage size (16M and 16G) the control
files include:
hugetlb.16GB.limit_in_bytes
hugetlb.16GB.max_usage_in_bytes
hugetlb.16GB.usage_in_bytes
hugetlb.16GB.failcnt
hugetlb.16MB.limit_in_bytes
hugetlb.16MB.max_usage_in_bytes
hugetlb.16MB.usage_in_bytes
hugetlb.16MB.failcnt

View File

@ -73,6 +73,8 @@ Brief summary of control files.
memory.kmem.tcp.limit_in_bytes # set/show hard limit for tcp buf memory
memory.kmem.tcp.usage_in_bytes # show current tcp buf memory allocation
memory.kmem.tcp.failcnt # show the number of tcp buf memory usage hits limits
memory.kmem.tcp.max_usage_in_bytes # show max tcp buf memory usage recorded
1. History
@ -187,12 +189,12 @@ the cgroup that brought it in -- this will happen on memory pressure).
But see section 8.2: when moving a task to another cgroup, its pages may
be recharged to the new cgroup, if move_charge_at_immigrate has been chosen.
Exception: If CONFIG_CGROUP_CGROUP_MEM_RES_CTLR_SWAP is not used.
Exception: If CONFIG_CGROUP_CGROUP_MEMCG_SWAP is not used.
When you do swapoff and make swapped-out pages of shmem(tmpfs) to
be backed into memory in force, charges for pages are accounted against the
caller of swapoff rather than the users of shmem.
2.4 Swap Extension (CONFIG_CGROUP_MEM_RES_CTLR_SWAP)
2.4 Swap Extension (CONFIG_MEMCG_SWAP)
Swap Extension allows you to record charge for swap. A swapped-in page is
charged back to original page allocator if possible.
@ -259,7 +261,7 @@ When oom event notifier is registered, event will be delivered.
per-zone-per-cgroup LRU (cgroup's private LRU) is just guarded by
zone->lru_lock, it has no lock of its own.
2.7 Kernel Memory Extension (CONFIG_CGROUP_MEM_RES_CTLR_KMEM)
2.7 Kernel Memory Extension (CONFIG_MEMCG_KMEM)
With the Kernel memory extension, the Memory Controller is able to limit
the amount of kernel memory used by the system. Kernel memory is fundamentally
@ -286,8 +288,8 @@ per cgroup, instead of globally.
a. Enable CONFIG_CGROUPS
b. Enable CONFIG_RESOURCE_COUNTERS
c. Enable CONFIG_CGROUP_MEM_RES_CTLR
d. Enable CONFIG_CGROUP_MEM_RES_CTLR_SWAP (to use swap extension)
c. Enable CONFIG_MEMCG
d. Enable CONFIG_MEMCG_SWAP (to use swap extension)
1. Prepare the cgroups (see cgroups.txt, Why are cgroups needed?)
# mount -t tmpfs none /sys/fs/cgroup

View File

@ -27,6 +27,10 @@ The target is named "raid" and it accepts the following parameters:
- rotating parity N (right-to-left) with data restart
raid6_nc RAID6 N continue
- rotating parity N (right-to-left) with data continuation
raid10 Various RAID10 inspired algorithms chosen by additional params
- RAID10: Striped Mirrors (aka 'Striping on top of mirrors')
- RAID1E: Integrated Adjacent Stripe Mirroring
- and other similar RAID10 variants
Reference: Chapter 4 of
http://www.snia.org/sites/default/files/SNIA_DDF_Technical_Position_v2.0.pdf
@ -59,6 +63,28 @@ The target is named "raid" and it accepts the following parameters:
logical size of the array. The bitmap records the device
synchronisation state for each region.
[raid10_copies <# copies>]
[raid10_format near]
These two options are used to alter the default layout of
a RAID10 configuration. The number of copies is can be
specified, but the default is 2. There are other variations
to how the copies are laid down - the default and only current
option is "near". Near copies are what most people think of
with respect to mirroring. If these options are left
unspecified, or 'raid10_copies 2' and/or 'raid10_format near'
are given, then the layouts for 2, 3 and 4 devices are:
2 drives 3 drives 4 drives
-------- ---------- --------------
A1 A1 A1 A1 A2 A1 A1 A2 A2
A2 A2 A2 A3 A3 A3 A3 A4 A4
A3 A3 A4 A4 A5 A5 A5 A6 A6
A4 A4 A5 A6 A6 A7 A7 A8 A8
.. .. .. .. .. .. .. .. ..
The 2-device layout is equivalent 2-way RAID1. The 4-device
layout is what a traditional RAID10 would look like. The
3-device layout is what might be called a 'RAID1E - Integrated
Adjacent Stripe Mirroring'.
<#raid_devs>: The number of devices composing the array.
Each device consists of two entries. The first is the device
containing the metadata (if any); the second is the one containing the

View File

@ -38,3 +38,23 @@ Example:
reg-names = "mux status", "mux mask";
mrvl,intc-nr-irqs = <2>;
};
* Marvell Orion Interrupt controller
Required properties
- compatible : Should be "marvell,orion-intc".
- #interrupt-cells: Specifies the number of cells needed to encode an
interrupt source. Supported value is <1>.
- interrupt-controller : Declare this node to be an interrupt controller.
- reg : Interrupt mask address. A list of 4 byte ranges, one per controller.
One entry in the list represents 32 interrupts.
Example:
intc: interrupt-controller {
compatible = "marvell,orion-intc", "marvell,intc";
interrupt-controller;
#interrupt-cells = <1>;
reg = <0xfed20204 0x04>,
<0xfed20214 0x04>;
};

View File

@ -0,0 +1,16 @@
* Marvell Orion SATA
Required Properties:
- compatibility : "marvell,orion-sata"
- reg : Address range of controller
- interrupts : Interrupt controller is using
- nr-ports : Number of SATA ports in use.
Example:
sata@80000 {
compatible = "marvell,orion-sata";
reg = <0x80000 0x5000>;
interrupts = <21>;
nr-ports = <2>;
}

View File

@ -27,3 +27,26 @@ Example:
interrupt-controller;
#interrupt-cells = <1>;
};
* Marvell Orion GPIO Controller
Required properties:
- compatible : Should be "marvell,orion-gpio"
- reg : Address and length of the register set for controller.
- gpio-controller : So we know this is a gpio controller.
- ngpio : How many gpios this controller has.
- interrupts : Up to 4 Interrupts for the controller.
Optional properties:
- mask-offset : For SMP Orions, offset for Nth CPU
Example:
gpio0: gpio@10100 {
compatible = "marvell,orion-gpio";
#gpio-cells = <2>;
gpio-controller;
reg = <0x10100 0x40>;
ngpio = <32>;
interrupts = <35>, <36>, <37>, <38>;
};

View File

@ -10,8 +10,8 @@ Required properties:
- compatible : Should be "fsl,<chip>-esdhc"
Optional properties:
- fsl,cd-internal : Indicate to use controller internal card detection
- fsl,wp-internal : Indicate to use controller internal write protection
- fsl,cd-controller : Indicate to use controller internal card detection
- fsl,wp-controller : Indicate to use controller internal write protection
Examples:
@ -19,8 +19,8 @@ esdhc@70004000 {
compatible = "fsl,imx51-esdhc";
reg = <0x70004000 0x4000>;
interrupts = <1>;
fsl,cd-internal;
fsl,wp-internal;
fsl,cd-controller;
fsl,wp-controller;
};
esdhc@70008000 {

View File

@ -9,9 +9,9 @@ Required properties:
- regulators: list of regulators provided by this controller, must have
property "regulator-compatible" to match their hardware counterparts:
sm[0-2], ldo[0-9] and ldo_rtc
- sm0-supply: The input supply for the SM0.
- sm1-supply: The input supply for the SM1.
- sm2-supply: The input supply for the SM2.
- vin-sm0-supply: The input supply for the SM0.
- vin-sm1-supply: The input supply for the SM1.
- vin-sm2-supply: The input supply for the SM2.
- vinldo01-supply: The input supply for the LDO1 and LDO2
- vinldo23-supply: The input supply for the LDO2 and LDO3
- vinldo4-supply: The input supply for the LDO4
@ -30,9 +30,9 @@ Example:
#gpio-cells = <2>;
gpio-controller;
sm0-supply = <&some_reg>;
sm1-supply = <&some_reg>;
sm2-supply = <&some_reg>;
vin-sm0-supply = <&some_reg>;
vin-sm1-supply = <&some_reg>;
vin-sm2-supply = <&some_reg>;
vinldo01-supply = <...>;
vinldo23-supply = <...>;
vinldo4-supply = <...>;

View File

@ -0,0 +1,14 @@
* Marvell Orion Watchdog Time
Required Properties:
- Compatibility : "marvell,orion-wdt"
- reg : Address of the timer registers
Example:
wdt@20300 {
compatible = "marvell,orion-wdt";
reg = <0x20300 0x28>;
status = "okay";
};

View File

@ -30,7 +30,7 @@ with the device via the bus. The connection between the DVB-API-functionality
is done via callbacks, assigned in a static device-description (struct
dvb_usb_device) each device-driver has to have.
For an example have a look in drivers/media/dvb/dvb-usb/vp7045*.
For an example have a look in drivers/media/usb/dvb-usb/vp7045*.
Objective is to migrate all the usb-devices (dibusb, cinergyT2, maybe the
ttusb; flexcop-usb already benefits from the generic flexcop-device) to use

View File

@ -116,7 +116,7 @@ sub tda10045 {
sub tda10046 {
my $sourcefile = "TT_PCI_2.19h_28_11_2006.zip";
my $url = "http://www.tt-download.com/download/updates/219/$sourcefile";
my $url = "http://technotrend.com.ua/download/software/219/$sourcefile";
my $hash = "6a7e1e2f2644b162ff0502367553c72d";
my $outfile = "dvb-fe-tda10046.fw";
my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1);

View File

@ -6,6 +6,15 @@ be removed from this file. The suggested deprecation period is 3 releases.
---------------------------
What: support for i.mx25 in mx2_camera.c
When: v3.8
Why: it's been broken for a year. Furthermore, i.MX25 video capture
HW doesn't have much in common with i.MX27. A separate driver
will be needed for it.
Who: Javier Martin<javier.martin@vista-silicon.com>
---------------------------
What: ddebug_query="query" boot cmdline param
When: v3.8
Why: obsoleted by dyndbg="query" and module.dyndbg="query"
@ -13,6 +22,14 @@ Who: Jim Cromie <jim.cromie@gmail.com>, Jason Baron <jbaron@redhat.com>
---------------------------
What: /proc/sys/vm/nr_pdflush_threads
When: 2012
Why: Since pdflush is deprecated, the interface exported in /proc/sys/vm/
should be removed.
Who: Wanpeng Li <liwp@linux.vnet.ibm.com>
---------------------------
What: CONFIG_APM_CPU_IDLE, and its ability to call APM BIOS in idle
When: 2012
Why: This optional sub-feature of APM is of dubious reliability,
@ -70,20 +87,6 @@ Who: Luis R. Rodriguez <lrodriguez@atheros.com>
---------------------------
What: IRQF_SAMPLE_RANDOM
Check: IRQF_SAMPLE_RANDOM
When: July 2009
Why: Many of IRQF_SAMPLE_RANDOM users are technically bogus as entropy
sources in the kernel's current entropy model. To resolve this, every
input point to the kernel's entropy pool needs to better document the
type of entropy source it actually is. This will be replaced with
additional add_*_randomness functions in drivers/char/random.c
Who: Robin Getz <rgetz@blackfin.uclinux.org> & Matt Mackall <mpm@selenic.com>
---------------------------
What: The ieee80211_regdom module parameter
When: March 2010 / desktop catchup
@ -585,7 +588,7 @@ Why: KVM tracepoints provide mostly equivalent information in a much more
----------------------------
What: at91-mci driver ("CONFIG_MMC_AT91")
When: 3.7
When: 3.8
Why: There are two mci drivers: at91-mci and atmel-mci. The PDC support
was added to atmel-mci as a first step to support more chips.
Then at91-mci was kept only for old IP versions (on at91rm9200 and
@ -632,3 +635,23 @@ Why: New drivers should use new V4L2_CAP_VIDEO_M2M capability flag
Who: Sylwester Nawrocki <s.nawrocki@samsung.com>
----------------------------
What: OMAP private DMA implementation
When: 2013
Why: We have a DMA engine implementation; all users should be updated
to use this rather than persisting with the old APIs. The old APIs
block merging the old DMA engine implementation into the DMA
engine driver.
Who: Russell King <linux@arm.linux.org.uk>,
Santosh Shilimkar <santosh.shilimkar@ti.com>
----------------------------
What: Remove deprecated DV timings capability defines V4L2_IN_CAP_CUSTOM_TIMINGS
and V4L2_OUT_CAP_CUSTOM_TIMINGS.
When: 3.9
Why: These defines have been replaced by V4L2_IN_CAP_TIMINGS and
V4L2_OUT_CAP_TIMINGS respectively.
Who: Hans Verkuil <hans.verkuil@cisco.com>
----------------------------

View File

@ -114,7 +114,6 @@ prototypes:
int (*drop_inode) (struct inode *);
void (*evict_inode) (struct inode *);
void (*put_super) (struct super_block *);
void (*write_super) (struct super_block *);
int (*sync_fs)(struct super_block *sb, int wait);
int (*freeze_fs) (struct super_block *);
int (*unfreeze_fs) (struct super_block *);
@ -136,10 +135,9 @@ write_inode:
drop_inode: !!!inode->i_lock!!!
evict_inode:
put_super: write
write_super: read
sync_fs: read
freeze_fs: read
unfreeze_fs: read
freeze_fs: write
unfreeze_fs: write
statfs: maybe(read) (see below)
remount_fs: write
umount_begin: no
@ -206,6 +204,8 @@ prototypes:
int (*launder_page)(struct page *);
int (*is_partially_uptodate)(struct page *, read_descriptor_t *, unsigned long);
int (*error_remove_page)(struct address_space *, struct page *);
int (*swap_activate)(struct file *);
int (*swap_deactivate)(struct file *);
locking rules:
All except set_page_dirty and freepage may block
@ -229,6 +229,8 @@ migratepage: yes (both)
launder_page: yes
is_partially_uptodate: yes
error_remove_page: yes
swap_activate: no
swap_deactivate: no
->write_begin(), ->write_end(), ->sync_page() and ->readpage()
may be called from the request handler (/dev/loop).
@ -330,6 +332,15 @@ cleaned, or an error value if not. Note that in order to prevent the page
getting mapped back in and redirtied, it needs to be kept locked
across the entire operation.
->swap_activate will be called with a non-zero argument on
files backing (non block device backed) swapfiles. A return value
of zero indicates success, in which case this file can be used for
backing swapspace. The swapspace operations will be proxied to the
address space operations.
->swap_deactivate() will be called in the sys_swapoff()
path after ->swap_activate() returned success.
----------------------- file_lock_operations ------------------------------
prototypes:
void (*fl_copy_lock)(struct file_lock *, struct file_lock *);
@ -346,7 +357,6 @@ prototypes:
int (*lm_compare_owner)(struct file_lock *, struct file_lock *);
void (*lm_notify)(struct file_lock *); /* unblock callback */
int (*lm_grant)(struct file_lock *, struct file_lock *, int);
void (*lm_release_private)(struct file_lock *);
void (*lm_break)(struct file_lock *); /* break_lease callback */
int (*lm_change)(struct file_lock **, int);
@ -355,7 +365,6 @@ locking rules:
lm_compare_owner: yes no
lm_notify: yes no
lm_grant: no no
lm_release_private: maybe no
lm_break: yes no
lm_change yes no

View File

@ -94,9 +94,8 @@ protected.
---
[mandatory]
BKL is also moved from around sb operations. ->write_super() Is now called
without BKL held. BKL should have been shifted into individual fs sb_op
functions. If you don't need it, remove it.
BKL is also moved from around sb operations. BKL should have been shifted into
individual fs sb_op functions. If you don't need it, remove it.
---
[informational]

View File

@ -137,6 +137,17 @@ errors=panic|continue|remount-ro
without doing anything or remount the partition in
read-only mode (default behavior).
discard -- If set, issues discard/TRIM commands to the block
device when blocks are freed. This is useful for SSD devices
and sparse/thinly-provisoned LUNs.
nfs -- This option maintains an index (cache) of directory
inodes by i_logstart which is used by the nfs-related code to
improve look-ups.
Enable this only if you want to export the FAT filesystem
over NFS
<bool>: 0,1,yes,no,true,false
TODO

View File

@ -216,7 +216,6 @@ struct super_operations {
void (*drop_inode) (struct inode *);
void (*delete_inode) (struct inode *);
void (*put_super) (struct super_block *);
void (*write_super) (struct super_block *);
int (*sync_fs)(struct super_block *sb, int wait);
int (*freeze_fs) (struct super_block *);
int (*unfreeze_fs) (struct super_block *);
@ -273,9 +272,6 @@ or bottom half).
put_super: called when the VFS wishes to free the superblock
(i.e. unmount). This is called with the superblock lock held
write_super: called when the VFS superblock needs to be written to
disc. This method is optional
sync_fs: called when VFS is writing out all dirty data associated with
a superblock. The second parameter indicates whether the method
should wait until the write out has been completed. Optional.
@ -592,6 +588,8 @@ struct address_space_operations {
int (*migratepage) (struct page *, struct page *);
int (*launder_page) (struct page *);
int (*error_remove_page) (struct mapping *mapping, struct page *page);
int (*swap_activate)(struct file *);
int (*swap_deactivate)(struct file *);
};
writepage: called by the VM to write a dirty page to backing store.
@ -760,6 +758,16 @@ struct address_space_operations {
Setting this implies you deal with pages going away under you,
unless you have them locked or reference counts increased.
swap_activate: Called when swapon is used on a file to allocate
space if necessary and pin the block lookup information in
memory. A return value of zero indicates success,
in which case this file can be used to back swapspace. The
swapspace operations will be proxied to this address space's
->swap_{out,in} methods.
swap_deactivate: Called during swapoff on files where swap_activate
was successful.
The File Object
===============

View File

@ -21,6 +21,7 @@ Supported adapters:
* Intel DH89xxCC (PCH)
* Intel Panther Point (PCH)
* Intel Lynx Point (PCH)
* Intel Lynx Point-LP (PCH)
Datasheets: Publicly available at the Intel website
On Intel Patsburg and later chipsets, both the normal host SMBus controller

View File

@ -88,6 +88,7 @@ Code Seq#(hex) Include File Comments
and kernel/power/user.c
'8' all SNP8023 advanced NIC card
<mailto:mcr@solidum.com>
';' 64-7F linux/vfio.h
'@' 00-0F linux/radeonfb.h conflict!
'@' 00-0F drivers/video/aty/aty128fb.c conflict!
'A' 00-1F linux/apm_bios.h conflict!
@ -177,7 +178,6 @@ Code Seq#(hex) Include File Comments
'V' C0 linux/ivtv.h conflict!
'V' C0 media/davinci/vpfe_capture.h conflict!
'V' C0 media/si4713.h conflict!
'V' C0-CF drivers/media/video/mxb.h conflict!
'W' 00-1F linux/watchdog.h conflict!
'W' 00-1F linux/wanrouter.h conflict!
'W' 00-3F sound/asound.h conflict!
@ -203,8 +203,6 @@ Code Seq#(hex) Include File Comments
'c' A0-AF arch/x86/include/asm/msr.h conflict!
'd' 00-FF linux/char/drm/drm/h conflict!
'd' 02-40 pcmcia/ds.h conflict!
'd' 10-3F drivers/media/video/dabusb.h conflict!
'd' C0-CF drivers/media/video/saa7191.h conflict!
'd' F0-FF linux/digi1.h
'e' all linux/digi1.h conflict!
'e' 00-1F drivers/net/irda/irtty-sir.h conflict!
@ -266,9 +264,7 @@ Code Seq#(hex) Include File Comments
'v' 00-1F linux/ext2_fs.h conflict!
'v' 00-1F linux/fs.h conflict!
'v' 00-0F linux/sonypi.h conflict!
'v' C0-DF media/pwc-ioctl.h conflict!
'v' C0-FF linux/meye.h conflict!
'v' D0-DF drivers/media/video/cpia2/cpia2dev.h conflict!
'w' all CERN SCI driver
'y' 00-1F packet based user level communications
<mailto:zapman@interlan.net>

View File

@ -262,9 +262,9 @@ MINIMUM_BATTERY_MINUTES=10
#
# Allowed dirty background ratio, in percent. Once DIRTY_RATIO has been
# exceeded, the kernel will wake pdflush which will then reduce the amount
# of dirty memory to dirty_background_ratio. Set this nice and low, so once
# some writeout has commenced, we do a lot of it.
# exceeded, the kernel will wake flusher threads which will then reduce the
# amount of dirty memory to dirty_background_ratio. Set this nice and low,
# so once some writeout has commenced, we do a lot of it.
#
#DIRTY_BACKGROUND_RATIO=5
@ -384,9 +384,9 @@ CPU_MAXFREQ=${CPU_MAXFREQ:-'slowest'}
#
# Allowed dirty background ratio, in percent. Once DIRTY_RATIO has been
# exceeded, the kernel will wake pdflush which will then reduce the amount
# of dirty memory to dirty_background_ratio. Set this nice and low, so once
# some writeout has commenced, we do a lot of it.
# exceeded, the kernel will wake flusher threads which will then reduce the
# amount of dirty memory to dirty_background_ratio. Set this nice and low,
# so once some writeout has commenced, we do a lot of it.
#
DIRTY_BACKGROUND_RATIO=${DIRTY_BACKGROUND_RATIO:-'5'}

View File

@ -51,8 +51,23 @@ Built-in netconsole starts immediately after the TCP stack is
initialized and attempts to bring up the supplied dev at the supplied
address.
The remote host can run either 'netcat -u -l -p <port>',
'nc -l -u <port>' or syslogd.
The remote host has several options to receive the kernel messages,
for example:
1) syslogd
2) netcat
On distributions using a BSD-based netcat version (e.g. Fedora,
openSUSE and Ubuntu) the listening port must be specified without
the -p switch:
'nc -u -l -p <port>' / 'nc -u -l <port>' or
'netcat -u -l -p <port>' / 'netcat -u -l <port>'
3) socat
'socat udp-recv:<port> -'
Dynamic reconfiguration:
========================

View File

@ -840,9 +840,9 @@ static unsigned long i2c_pin_configs[] = {
static struct pinctrl_map __initdata mapping[] = {
PIN_MAP_MUX_GROUP("foo-i2c.0", PINCTRL_STATE_DEFAULT, "pinctrl-foo", "i2c0", "i2c0"),
PIN_MAP_MUX_CONFIGS_GROUP("foo-i2c.0", PINCTRL_STATE_DEFAULT, "pinctrl-foo", "i2c0", i2c_grp_configs),
PIN_MAP_MUX_CONFIGS_PIN("foo-i2c.0", PINCTRL_STATE_DEFAULT, "pinctrl-foo", "i2c0scl", i2c_pin_configs),
PIN_MAP_MUX_CONFIGS_PIN("foo-i2c.0", PINCTRL_STATE_DEFAULT, "pinctrl-foo", "i2c0sda", i2c_pin_configs),
PIN_MAP_CONFIGS_GROUP("foo-i2c.0", PINCTRL_STATE_DEFAULT, "pinctrl-foo", "i2c0", i2c_grp_configs),
PIN_MAP_CONFIGS_PIN("foo-i2c.0", PINCTRL_STATE_DEFAULT, "pinctrl-foo", "i2c0scl", i2c_pin_configs),
PIN_MAP_CONFIGS_PIN("foo-i2c.0", PINCTRL_STATE_DEFAULT, "pinctrl-foo", "i2c0sda", i2c_pin_configs),
};
Finally, some devices expect the mapping table to contain certain specific

View File

@ -46,14 +46,13 @@ restrictions, it can call prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY, ...)
so that any otherwise allowed process (even those in external pid namespaces)
may attach.
These restrictions do not change how ptrace via PTRACE_TRACEME operates.
The sysctl settings are:
The sysctl settings (writable only with CAP_SYS_PTRACE) are:
0 - classic ptrace permissions: a process can PTRACE_ATTACH to any other
process running under the same uid, as long as it is dumpable (i.e.
did not transition uids, start privileged, or have called
prctl(PR_SET_DUMPABLE...) already).
prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is
unchanged.
1 - restricted ptrace: a process must have a predefined relationship
with the inferior it wants to call PTRACE_ATTACH on. By default,
@ -61,12 +60,13 @@ The sysctl settings are:
classic criteria is also met. To change the relationship, an
inferior can call prctl(PR_SET_PTRACER, debugger, ...) to declare
an allowed debugger PID to call PTRACE_ATTACH on the inferior.
Using PTRACE_TRACEME is unchanged.
2 - admin-only attach: only processes with CAP_SYS_PTRACE may use ptrace
with PTRACE_ATTACH.
with PTRACE_ATTACH, or through children calling PTRACE_TRACEME.
3 - no attach: no processes may use ptrace with PTRACE_ATTACH. Once set,
this sysctl cannot be changed to a lower value.
3 - no attach: no processes may use ptrace with PTRACE_ATTACH nor via
PTRACE_TRACEME. Once set, this sysctl value cannot be changed.
The original children-only logic was based on the restrictions in grsecurity.

View File

@ -53,6 +53,7 @@ ALC882/883/885/888/889
acer-aspire-8930g Acer Aspire 8330G/6935G
acer-aspire Acer Aspire others
inv-dmic Inverted internal mic workaround
no-primary-hp VAIO Z workaround (for fixed speaker DAC)
ALC861/660
==========
@ -273,6 +274,10 @@ STAC92HD83*
dell-s14 Dell laptop
dell-vostro-3500 Dell Vostro 3500 laptop
hp-dv7-4000 HP dv-7 4000
hp_cNB11_intquad HP CNB models with 4 speakers
hp-zephyr HP Zephyr
hp-led HP with broken BIOS for mute LED
hp-inv-led HP with broken BIOS for inverted mute LED
auto BIOS setup (default)
STAC9872

View File

@ -32,6 +32,8 @@ Currently, these files are in /proc/sys/fs:
- nr_open
- overflowuid
- overflowgid
- protected_hardlinks
- protected_symlinks
- suid_dumpable
- super-max
- super-nr
@ -157,6 +159,46 @@ The default is 65534.
==============================================================
protected_hardlinks:
A long-standing class of security issues is the hardlink-based
time-of-check-time-of-use race, most commonly seen in world-writable
directories like /tmp. The common method of exploitation of this flaw
is to cross privilege boundaries when following a given hardlink (i.e. a
root process follows a hardlink created by another user). Additionally,
on systems without separated partitions, this stops unauthorized users
from "pinning" vulnerable setuid/setgid files against being upgraded by
the administrator, or linking to special files.
When set to "0", hardlink creation behavior is unrestricted.
When set to "1" hardlinks cannot be created by users if they do not
already own the source file, or do not have read/write access to it.
This protection is based on the restrictions in Openwall and grsecurity.
==============================================================
protected_symlinks:
A long-standing class of security issues is the symlink-based
time-of-check-time-of-use race, most commonly seen in world-writable
directories like /tmp. The common method of exploitation of this flaw
is to cross privilege boundaries when following a given symlink (i.e. a
root process follows a symlink belonging to another user). For a likely
incomplete list of hundreds of examples across the years, please see:
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=/tmp
When set to "0", symlink following behavior is unrestricted.
When set to "1" symlinks are permitted to be followed only when outside
a sticky world-writable directory, or when the uid of the symlink and
follower match, or when the directory owner matches the symlink's owner.
This protection is based on the restrictions in Openwall and grsecurity.
==============================================================
suid_dumpable:
This value can be used to query and set the core dump mode for setuid

View File

@ -42,7 +42,6 @@ Currently, these files are in /proc/sys/vm:
- mmap_min_addr
- nr_hugepages
- nr_overcommit_hugepages
- nr_pdflush_threads
- nr_trim_pages (only if CONFIG_MMU=n)
- numa_zonelist_order
- oom_dump_tasks
@ -77,8 +76,8 @@ huge pages although processes will also directly compact memory as required.
dirty_background_bytes
Contains the amount of dirty memory at which the pdflush background writeback
daemon will start writeback.
Contains the amount of dirty memory at which the background kernel
flusher threads will start writeback.
Note: dirty_background_bytes is the counterpart of dirty_background_ratio. Only
one of them may be specified at a time. When one sysctl is written it is
@ -90,7 +89,7 @@ other appears as 0 when read.
dirty_background_ratio
Contains, as a percentage of total system memory, the number of pages at which
the pdflush background writeback daemon will start writing out dirty data.
the background kernel flusher threads will start writing out dirty data.
==============================================================
@ -113,9 +112,9 @@ retained.
dirty_expire_centisecs
This tunable is used to define when dirty data is old enough to be eligible
for writeout by the pdflush daemons. It is expressed in 100'ths of a second.
Data which has been dirty in-memory for longer than this interval will be
written out next time a pdflush daemon wakes up.
for writeout by the kernel flusher threads. It is expressed in 100'ths
of a second. Data which has been dirty in-memory for longer than this
interval will be written out next time a flusher thread wakes up.
==============================================================
@ -129,7 +128,7 @@ data.
dirty_writeback_centisecs
The pdflush writeback daemons will periodically wake up and write `old' data
The kernel flusher threads will periodically wake up and write `old' data
out to disk. This tunable expresses the interval between those wakeups, in
100'ths of a second.
@ -426,16 +425,6 @@ See Documentation/vm/hugetlbpage.txt
==============================================================
nr_pdflush_threads
The current number of pdflush threads. This value is read-only.
The value changes according to the number of dirty pages in the system.
When necessary, additional pdflush threads are created, one per second, up to
nr_pdflush_threads_max.
==============================================================
nr_trim_pages
This is available only on NOMMU kernels.
@ -502,9 +491,10 @@ oom_dump_tasks
Enables a system-wide task dump (excluding kernel threads) to be
produced when the kernel performs an OOM-killing and includes such
information as pid, uid, tgid, vm size, rss, cpu, oom_adj score, and
name. This is helpful to determine why the OOM killer was invoked
and to identify the rogue task that caused it.
information as pid, uid, tgid, vm size, rss, nr_ptes, swapents,
oom_score_adj score, and name. This is helpful to determine why the
OOM killer was invoked, to identify the rogue task that caused it,
and to determine why the OOM killer chose the task it did to kill.
If this is set to zero, this information is suppressed. On very
large systems with thousands of tasks it may not be feasible to dump
@ -574,16 +564,24 @@ of physical RAM. See above.
page-cluster
page-cluster controls the number of pages which are written to swap in
a single attempt. The swap I/O size.
page-cluster controls the number of pages up to which consecutive pages
are read in from swap in a single attempt. This is the swap counterpart
to page cache readahead.
The mentioned consecutivity is not in terms of virtual/physical addresses,
but consecutive on swap space - that means they were swapped out together.
It is a logarithmic value - setting it to zero means "1 page", setting
it to 1 means "2 pages", setting it to 2 means "4 pages", etc.
Zero disables swap readahead completely.
The default value is three (eight pages at a time). There may be some
small benefits in tuning this to a different value if your workload is
swap-intensive.
Lower values mean lower latencies for initial faults, but at the same time
extra faults and I/O delays for following faults if they would have been part of
that consecutive pages readahead would have brought in.
=============================================================
panic_on_oom

314
Documentation/vfio.txt Normal file
View File

@ -0,0 +1,314 @@
VFIO - "Virtual Function I/O"[1]
-------------------------------------------------------------------------------
Many modern system now provide DMA and interrupt remapping facilities
to help ensure I/O devices behave within the boundaries they've been
allotted. This includes x86 hardware with AMD-Vi and Intel VT-d,
POWER systems with Partitionable Endpoints (PEs) and embedded PowerPC
systems such as Freescale PAMU. The VFIO driver is an IOMMU/device
agnostic framework for exposing direct device access to userspace, in
a secure, IOMMU protected environment. In other words, this allows
safe[2], non-privileged, userspace drivers.
Why do we want that? Virtual machines often make use of direct device
access ("device assignment") when configured for the highest possible
I/O performance. From a device and host perspective, this simply
turns the VM into a userspace driver, with the benefits of
significantly reduced latency, higher bandwidth, and direct use of
bare-metal device drivers[3].
Some applications, particularly in the high performance computing
field, also benefit from low-overhead, direct device access from
userspace. Examples include network adapters (often non-TCP/IP based)
and compute accelerators. Prior to VFIO, these drivers had to either
go through the full development cycle to become proper upstream
driver, be maintained out of tree, or make use of the UIO framework,
which has no notion of IOMMU protection, limited interrupt support,
and requires root privileges to access things like PCI configuration
space.
The VFIO driver framework intends to unify these, replacing both the
KVM PCI specific device assignment code as well as provide a more
secure, more featureful userspace driver environment than UIO.
Groups, Devices, and IOMMUs
-------------------------------------------------------------------------------
Devices are the main target of any I/O driver. Devices typically
create a programming interface made up of I/O access, interrupts,
and DMA. Without going into the details of each of these, DMA is
by far the most critical aspect for maintaining a secure environment
as allowing a device read-write access to system memory imposes the
greatest risk to the overall system integrity.
To help mitigate this risk, many modern IOMMUs now incorporate
isolation properties into what was, in many cases, an interface only
meant for translation (ie. solving the addressing problems of devices
with limited address spaces). With this, devices can now be isolated
from each other and from arbitrary memory access, thus allowing
things like secure direct assignment of devices into virtual machines.
This isolation is not always at the granularity of a single device
though. Even when an IOMMU is capable of this, properties of devices,
interconnects, and IOMMU topologies can each reduce this isolation.
For instance, an individual device may be part of a larger multi-
function enclosure. While the IOMMU may be able to distinguish
between devices within the enclosure, the enclosure may not require
transactions between devices to reach the IOMMU. Examples of this
could be anything from a multi-function PCI device with backdoors
between functions to a non-PCI-ACS (Access Control Services) capable
bridge allowing redirection without reaching the IOMMU. Topology
can also play a factor in terms of hiding devices. A PCIe-to-PCI
bridge masks the devices behind it, making transaction appear as if
from the bridge itself. Obviously IOMMU design plays a major factor
as well.
Therefore, while for the most part an IOMMU may have device level
granularity, any system is susceptible to reduced granularity. The
IOMMU API therefore supports a notion of IOMMU groups. A group is
a set of devices which is isolatable from all other devices in the
system. Groups are therefore the unit of ownership used by VFIO.
While the group is the minimum granularity that must be used to
ensure secure user access, it's not necessarily the preferred
granularity. In IOMMUs which make use of page tables, it may be
possible to share a set of page tables between different groups,
reducing the overhead both to the platform (reduced TLB thrashing,
reduced duplicate page tables), and to the user (programming only
a single set of translations). For this reason, VFIO makes use of
a container class, which may hold one or more groups. A container
is created by simply opening the /dev/vfio/vfio character device.
On its own, the container provides little functionality, with all
but a couple version and extension query interfaces locked away.
The user needs to add a group into the container for the next level
of functionality. To do this, the user first needs to identify the
group associated with the desired device. This can be done using
the sysfs links described in the example below. By unbinding the
device from the host driver and binding it to a VFIO driver, a new
VFIO group will appear for the group as /dev/vfio/$GROUP, where
$GROUP is the IOMMU group number of which the device is a member.
If the IOMMU group contains multiple devices, each will need to
be bound to a VFIO driver before operations on the VFIO group
are allowed (it's also sufficient to only unbind the device from
host drivers if a VFIO driver is unavailable; this will make the
group available, but not that particular device). TBD - interface
for disabling driver probing/locking a device.
Once the group is ready, it may be added to the container by opening
the VFIO group character device (/dev/vfio/$GROUP) and using the
VFIO_GROUP_SET_CONTAINER ioctl, passing the file descriptor of the
previously opened container file. If desired and if the IOMMU driver
supports sharing the IOMMU context between groups, multiple groups may
be set to the same container. If a group fails to set to a container
with existing groups, a new empty container will need to be used
instead.
With a group (or groups) attached to a container, the remaining
ioctls become available, enabling access to the VFIO IOMMU interfaces.
Additionally, it now becomes possible to get file descriptors for each
device within a group using an ioctl on the VFIO group file descriptor.
The VFIO device API includes ioctls for describing the device, the I/O
regions and their read/write/mmap offsets on the device descriptor, as
well as mechanisms for describing and registering interrupt
notifications.
VFIO Usage Example
-------------------------------------------------------------------------------
Assume user wants to access PCI device 0000:06:0d.0
$ readlink /sys/bus/pci/devices/0000:06:0d.0/iommu_group
../../../../kernel/iommu_groups/26
This device is therefore in IOMMU group 26. This device is on the
pci bus, therefore the user will make use of vfio-pci to manage the
group:
# modprobe vfio-pci
Binding this device to the vfio-pci driver creates the VFIO group
character devices for this group:
$ lspci -n -s 0000:06:0d.0
06:0d.0 0401: 1102:0002 (rev 08)
# echo 0000:06:0d.0 > /sys/bus/pci/devices/0000:06:0d.0/driver/unbind
# echo 1102 0002 > /sys/bus/pci/drivers/vfio-pci/new_id
Now we need to look at what other devices are in the group to free
it for use by VFIO:
$ ls -l /sys/bus/pci/devices/0000:06:0d.0/iommu_group/devices
total 0
lrwxrwxrwx. 1 root root 0 Apr 23 16:13 0000:00:1e.0 ->
../../../../devices/pci0000:00/0000:00:1e.0
lrwxrwxrwx. 1 root root 0 Apr 23 16:13 0000:06:0d.0 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.0
lrwxrwxrwx. 1 root root 0 Apr 23 16:13 0000:06:0d.1 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.1
This device is behind a PCIe-to-PCI bridge[4], therefore we also
need to add device 0000:06:0d.1 to the group following the same
procedure as above. Device 0000:00:1e.0 is a bridge that does
not currently have a host driver, therefore it's not required to
bind this device to the vfio-pci driver (vfio-pci does not currently
support PCI bridges).
The final step is to provide the user with access to the group if
unprivileged operation is desired (note that /dev/vfio/vfio provides
no capabilities on its own and is therefore expected to be set to
mode 0666 by the system).
# chown user:user /dev/vfio/26
The user now has full access to all the devices and the iommu for this
group and can access them as follows:
int container, group, device, i;
struct vfio_group_status group_status =
{ .argsz = sizeof(group_status) };
struct vfio_iommu_x86_info iommu_info = { .argsz = sizeof(iommu_info) };
struct vfio_iommu_x86_dma_map dma_map = { .argsz = sizeof(dma_map) };
struct vfio_device_info device_info = { .argsz = sizeof(device_info) };
/* Create a new container */
container = open("/dev/vfio/vfio, O_RDWR);
if (ioctl(container, VFIO_GET_API_VERSION) != VFIO_API_VERSION)
/* Unknown API version */
if (!ioctl(container, VFIO_CHECK_EXTENSION, VFIO_X86_IOMMU))
/* Doesn't support the IOMMU driver we want. */
/* Open the group */
group = open("/dev/vfio/26", O_RDWR);
/* Test the group is viable and available */
ioctl(group, VFIO_GROUP_GET_STATUS, &group_status);
if (!(group_status.flags & VFIO_GROUP_FLAGS_VIABLE))
/* Group is not viable (ie, not all devices bound for vfio) */
/* Add the group to the container */
ioctl(group, VFIO_GROUP_SET_CONTAINER, &container);
/* Enable the IOMMU model we want */
ioctl(container, VFIO_SET_IOMMU, VFIO_X86_IOMMU)
/* Get addition IOMMU info */
ioctl(container, VFIO_IOMMU_GET_INFO, &iommu_info);
/* Allocate some space and setup a DMA mapping */
dma_map.vaddr = mmap(0, 1024 * 1024, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
dma_map.size = 1024 * 1024;
dma_map.iova = 0; /* 1MB starting at 0x0 from device view */
dma_map.flags = VFIO_DMA_MAP_FLAG_READ | VFIO_DMA_MAP_FLAG_WRITE;
ioctl(container, VFIO_IOMMU_MAP_DMA, &dma_map);
/* Get a file descriptor for the device */
device = ioctl(group, VFIO_GROUP_GET_DEVICE_FD, "0000:06:0d.0");
/* Test and setup the device */
ioctl(device, VFIO_DEVICE_GET_INFO, &device_info);
for (i = 0; i < device_info.num_regions; i++) {
struct vfio_region_info reg = { .argsz = sizeof(reg) };
reg.index = i;
ioctl(device, VFIO_DEVICE_GET_REGION_INFO, &reg);
/* Setup mappings... read/write offsets, mmaps
* For PCI devices, config space is a region */
}
for (i = 0; i < device_info.num_irqs; i++) {
struct vfio_irq_info irq = { .argsz = sizeof(irq) };
irq.index = i;
ioctl(device, VFIO_DEVICE_GET_IRQ_INFO, &reg);
/* Setup IRQs... eventfds, VFIO_DEVICE_SET_IRQS */
}
/* Gratuitous device reset and go... */
ioctl(device, VFIO_DEVICE_RESET);
VFIO User API
-------------------------------------------------------------------------------
Please see include/linux/vfio.h for complete API documentation.
VFIO bus driver API
-------------------------------------------------------------------------------
VFIO bus drivers, such as vfio-pci make use of only a few interfaces
into VFIO core. When devices are bound and unbound to the driver,
the driver should call vfio_add_group_dev() and vfio_del_group_dev()
respectively:
extern int vfio_add_group_dev(struct iommu_group *iommu_group,
struct device *dev,
const struct vfio_device_ops *ops,
void *device_data);
extern void *vfio_del_group_dev(struct device *dev);
vfio_add_group_dev() indicates to the core to begin tracking the
specified iommu_group and register the specified dev as owned by
a VFIO bus driver. The driver provides an ops structure for callbacks
similar to a file operations structure:
struct vfio_device_ops {
int (*open)(void *device_data);
void (*release)(void *device_data);
ssize_t (*read)(void *device_data, char __user *buf,
size_t count, loff_t *ppos);
ssize_t (*write)(void *device_data, const char __user *buf,
size_t size, loff_t *ppos);
long (*ioctl)(void *device_data, unsigned int cmd,
unsigned long arg);
int (*mmap)(void *device_data, struct vm_area_struct *vma);
};
Each function is passed the device_data that was originally registered
in the vfio_add_group_dev() call above. This allows the bus driver
an easy place to store its opaque, private data. The open/release
callbacks are issued when a new file descriptor is created for a
device (via VFIO_GROUP_GET_DEVICE_FD). The ioctl interface provides
a direct pass through for VFIO_DEVICE_* ioctls. The read/write/mmap
interfaces implement the device region access defined by the device's
own VFIO_DEVICE_GET_REGION_INFO ioctl.
-------------------------------------------------------------------------------
[1] VFIO was originally an acronym for "Virtual Function I/O" in its
initial implementation by Tom Lyon while as Cisco. We've since
outgrown the acronym, but it's catchy.
[2] "safe" also depends upon a device being "well behaved". It's
possible for multi-function devices to have backdoors between
functions and even for single function devices to have alternative
access to things like PCI config space through MMIO registers. To
guard against the former we can include additional precautions in the
IOMMU driver to group multi-function PCI devices together
(iommu=group_mf). The latter we can't prevent, but the IOMMU should
still provide isolation. For PCI, SR-IOV Virtual Functions are the
best indicator of "well behaved", as these are designed for
virtualization usage models.
[3] As always there are trade-offs to virtual machine device
assignment that are beyond the scope of VFIO. It's expected that
future IOMMU technologies will reduce some, but maybe not all, of
these trade-offs.
[4] In this case the device is below a PCI bridge, so transactions
from either function of the device are indistinguishable to the iommu:
-[0000:00]-+-1e.0-[06]--+-0d.0
\-0d.1
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 90)

View File

@ -35,3 +35,4 @@
34 -> TerraTec Cinergy T PCIe Dual [153b:117e]
35 -> TeVii S471 [d471:9022]
36 -> Hauppauge WinTV-HVR1255 [0070:2259]
37 -> Prof Revolution DVB-S2 8000 [8000:3034]

View File

@ -18,7 +18,7 @@ Table of Contents
1.0 Introduction
The file ../../drivers/media/video/c-qcam.c is a device driver for
The file ../../drivers/media/parport/c-qcam.c is a device driver for
the Logitech (nee Connectix) parallel port interface color CCD camera.
This is a fairly inexpensive device for capturing images. Logitech
does not currently provide information for developers, but many people

View File

@ -5,22 +5,22 @@
File partitioning
-----------------
V4L2 display device driver
drivers/media/video/davinci/vpbe_display.c
drivers/media/video/davinci/vpbe_display.h
drivers/media/platform/davinci/vpbe_display.c
drivers/media/platform/davinci/vpbe_display.h
VPBE display controller
drivers/media/video/davinci/vpbe.c
drivers/media/video/davinci/vpbe.h
drivers/media/platform/davinci/vpbe.c
drivers/media/platform/davinci/vpbe.h
VPBE venc sub device driver
drivers/media/video/davinci/vpbe_venc.c
drivers/media/video/davinci/vpbe_venc.h
drivers/media/video/davinci/vpbe_venc_regs.h
drivers/media/platform/davinci/vpbe_venc.c
drivers/media/platform/davinci/vpbe_venc.h
drivers/media/platform/davinci/vpbe_venc_regs.h
VPBE osd driver
drivers/media/video/davinci/vpbe_osd.c
drivers/media/video/davinci/vpbe_osd.h
drivers/media/video/davinci/vpbe_osd_regs.h
drivers/media/platform/davinci/vpbe_osd.c
drivers/media/platform/davinci/vpbe_osd.h
drivers/media/platform/davinci/vpbe_osd_regs.h
Functional partitioning
-----------------------

View File

@ -10,7 +10,7 @@ data from LCD controller (FIMD) through the SoC internal writeback data
path. There are multiple FIMC instances in the SoCs (up to 4), having
slightly different capabilities, like pixel alignment constraints, rotator
availability, LCD writeback support, etc. The driver is located at
drivers/media/video/s5p-fimc directory.
drivers/media/platform/s5p-fimc directory.
1. Supported SoCs
=================
@ -36,21 +36,21 @@ Not currently supported:
=====================
- media device driver
drivers/media/video/s5p-fimc/fimc-mdevice.[ch]
drivers/media/platform/s5p-fimc/fimc-mdevice.[ch]
- camera capture video device driver
drivers/media/video/s5p-fimc/fimc-capture.c
drivers/media/platform/s5p-fimc/fimc-capture.c
- MIPI-CSI2 receiver subdev
drivers/media/video/s5p-fimc/mipi-csis.[ch]
drivers/media/platform/s5p-fimc/mipi-csis.[ch]
- video post-processor (mem-to-mem)
drivers/media/video/s5p-fimc/fimc-core.c
drivers/media/platform/s5p-fimc/fimc-core.c
- common files
drivers/media/video/s5p-fimc/fimc-core.h
drivers/media/video/s5p-fimc/fimc-reg.h
drivers/media/video/s5p-fimc/regs-fimc.h
drivers/media/platform/s5p-fimc/fimc-core.h
drivers/media/platform/s5p-fimc/fimc-reg.h
drivers/media/platform/s5p-fimc/regs-fimc.h
4. User space interfaces
========================

View File

@ -12,7 +12,7 @@ Introduction
============
This file documents the Texas Instruments OMAP 3 Image Signal Processor (ISP)
driver located under drivers/media/video/omap3isp. The original driver was
driver located under drivers/media/platform/omap3isp. The original driver was
written by Texas Instruments but since that it has been rewritten (twice) at
Nokia.

View File

@ -594,7 +594,11 @@ handler and finally add the first handler to the second. For example:
v4l2_ctrl_new_std(&radio_ctrl_handler, &radio_ops, V4L2_CID_AUDIO_MUTE, ...);
v4l2_ctrl_new_std(&video_ctrl_handler, &video_ops, V4L2_CID_BRIGHTNESS, ...);
v4l2_ctrl_new_std(&video_ctrl_handler, &video_ops, V4L2_CID_CONTRAST, ...);
v4l2_ctrl_add_handler(&video_ctrl_handler, &radio_ctrl_handler);
v4l2_ctrl_add_handler(&video_ctrl_handler, &radio_ctrl_handler, NULL);
The last argument to v4l2_ctrl_add_handler() is a filter function that allows
you to filter which controls will be added. Set it to NULL if you want to add
all controls.
Or you can add specific controls to a handler:

View File

@ -583,11 +583,19 @@ You should also set these fields:
- name: set to something descriptive and unique.
- vfl_dir: set this to VFL_DIR_RX for capture devices (VFL_DIR_RX has value 0,
so this is normally already the default), set to VFL_DIR_TX for output
devices and VFL_DIR_M2M for mem2mem (codec) devices.
- fops: set to the v4l2_file_operations struct.
- ioctl_ops: if you use the v4l2_ioctl_ops to simplify ioctl maintenance
(highly recommended to use this and it might become compulsory in the
future!), then set this to your v4l2_ioctl_ops struct.
future!), then set this to your v4l2_ioctl_ops struct. The vfl_type and
vfl_dir fields are used to disable ops that do not match the type/dir
combination. E.g. VBI ops are disabled for non-VBI nodes, and output ops
are disabled for a capture device. This makes it possible to provide
just one v4l2_ioctl_ops struct for both vbi and video nodes.
- lock: leave to NULL if you want to do all the locking in the driver.
Otherwise you give it a pointer to a struct mutex_lock and before the
@ -1054,4 +1062,4 @@ The first event type in the class is reserved for future use, so the first
available event type is 'class base + 1'.
An example on how the V4L2 events may be used can be found in the OMAP
3 ISP driver (drivers/media/video/omap3isp).
3 ISP driver (drivers/media/platform/omap3isp).

View File

@ -349,7 +349,7 @@ again.
Developers who are interested in more information can go into the relevant
header files; there are a few low-level functions declared there which have
not been talked about here. Also worthwhile is the vivi driver
(drivers/media/video/vivi.c), which is maintained as an example of how V4L2
(drivers/media/platform/vivi.c), which is maintained as an example of how V4L2
drivers should be written. Vivi only uses the vmalloc() API, but it's good
enough to get started with. Note also that all of these calls are exported
GPL-only, so they will not be available to non-GPL kernel modules.

View File

@ -299,11 +299,17 @@ map_hugetlb.c.
*******************************************************************
/*
* hugepage-shm: see Documentation/vm/hugepage-shm.c
* map_hugetlb: see tools/testing/selftests/vm/map_hugetlb.c
*/
*******************************************************************
/*
* hugepage-mmap: see Documentation/vm/hugepage-mmap.c
* hugepage-shm: see tools/testing/selftests/vm/hugepage-shm.c
*/
*******************************************************************
/*
* hugepage-mmap: see tools/testing/selftests/vm/hugepage-mmap.c
*/

View File

@ -3,6 +3,7 @@ Kernel driver w1_therm
Supported chips:
* Maxim ds18*20 based temperature sensors.
* Maxim ds1825 based temperature sensors.
Author: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
@ -15,6 +16,7 @@ supported family codes:
W1_THERM_DS18S20 0x10
W1_THERM_DS1822 0x22
W1_THERM_DS18B20 0x28
W1_THERM_DS1825 0x3B
Support is provided through the sysfs w1_slave file. Each open and
read sequence will initiate a temperature conversion then provide two

Some files were not shown because too many files have changed in this diff Show More