Commit d18bfacf authored by Tony Luck's avatar Tony Luck
Browse files

Auto merge with /home/aegl/GIT/linus

parents a68db763 fd782a4a
......@@ -84,6 +84,14 @@ void (*port_disable) (struct ata_port *);
Called from ata_bus_probe() and ata_bus_reset() error paths,
as well as when unregistering from the SCSI module (rmmod, hot
This function should do whatever needs to be done to take the
port out of use. In most cases, ata_port_disable() can be used
as this hook.
Called from ata_bus_probe() on a failed probe.
Called from ata_bus_reset() on a failed bus reset.
Called from ata_scsi_release().
......@@ -98,6 +106,13 @@ void (*dev_config) (struct ata_port *, struct ata_device *);
found. Typically used to apply device-specific fixups prior to
issue of SET FEATURES - XFER MODE, and prior to operation.
Called by ata_device_add() after ata_dev_identify() determines
a device is present.
This entry may be specified as NULL in ata_port_operations.
......@@ -135,6 +150,8 @@ void (*tf_read) (struct ata_port *ap, struct ata_taskfile *tf);
registers / DMA buffers. ->tf_read() is called to read the
hardware registers / DMA buffers, to obtain the current set of
taskfile register values.
Most drivers for taskfile-based hardware (PIO or MMIO) use
ata_tf_load() and ata_tf_read() for these hooks.
......@@ -147,6 +164,8 @@ void (*exec_command)(struct ata_port *ap, struct ata_taskfile *tf);
causes an ATA command, previously loaded with
->tf_load(), to be initiated in hardware.
Most drivers for taskfile-based hardware use ata_exec_command()
for this hook.
......@@ -161,6 +180,10 @@ Allow low-level driver to filter ATA PACKET commands, returning a status
indicating whether or not it is OK to use DMA for the supplied PACKET
This hook may be specified as NULL, in which case libata will
assume that atapi dma can be supported.
......@@ -175,6 +198,14 @@ u8 (*check_err)(struct ata_port *ap);
Reads the Status/AltStatus/Error ATA shadow register from
hardware. On some hardware, reading the Status register has
the side effect of clearing the interrupt condition.
Most drivers for taskfile-based hardware use
ata_check_status() for this hook.
Note that because this is called from ata_device_add(), at
least a dummy function that clears device interrupts must be
provided for all drivers, even if the controller doesn't
actually have a taskfile status register.
......@@ -188,7 +219,13 @@ void (*dev_select)(struct ata_port *ap, unsigned int device);
Issues the low-level hardware command(s) that causes one of N
hardware devices to be considered 'selected' (active and
available for use) on the ATA bus. This generally has no
meaning on FIS-based devices.
meaning on FIS-based devices.
Most drivers for taskfile-based hardware use
ata_std_dev_select() for this hook. Controllers which do not
support second drives on a port (such as SATA contollers) will
use ata_noop_dev_select().
......@@ -204,6 +241,8 @@ void (*phy_reset) (struct ata_port *ap);
for device presence (PATA and SATA), typically a soft reset
(SRST) will be performed. Drivers typically use the helper
functions ata_bus_reset() or sata_phy_reset() for this hook.
Many SATA drivers use sata_phy_reset() or call it from within
their own phy_reset() functions.
......@@ -227,6 +266,25 @@ PCI IDE DMA Status register.
These hooks are typically either no-ops, or simply not implemented, in
FIS-based drivers.
Most legacy IDE drivers use ata_bmdma_setup() for the bmdma_setup()
hook. ata_bmdma_setup() will write the pointer to the PRD table to
the IDE PRD Table Address register, enable DMA in the DMA Command
register, and call exec_command() to begin the transfer.
Most legacy IDE drivers use ata_bmdma_start() for the bmdma_start()
hook. ata_bmdma_start() will write the ATA_DMA_START flag to the DMA
Command register.
Many legacy IDE drivers use ata_bmdma_stop() for the bmdma_stop()
hook. ata_bmdma_stop() clears the ATA_DMA_START flag in the DMA
command register.
Many legacy IDE drivers use ata_bmdma_status() as the bmdma_status() hook.
......@@ -250,6 +308,10 @@ int (*qc_issue) (struct ata_queued_cmd *qc);
helper function ata_qc_issue_prot() for taskfile protocol-based
dispatch. More advanced drivers implement their own ->qc_issue.
ata_qc_issue_prot() calls ->tf_load(), ->bmdma_setup(), and
->bmdma_start() as necessary to initiate a transfer.
......@@ -279,6 +341,21 @@ void (*irq_clear) (struct ata_port *);
before the interrupt handler is registered, to be sure hardware
is quiet.
The second argument, dev_instance, should be cast to a pointer
to struct ata_host_set.
Most legacy IDE drivers use ata_interrupt() for the
irq_handler hook, which scans all ports in the host_set,
determines which queued command was active (if any), and calls
Most legacy IDE drivers use ata_bmdma_irq_clear() for the
irq_clear() hook, which simply clears the interrupt and error
flags in the DMA status register.
......@@ -292,6 +369,7 @@ void (*scr_write) (struct ata_port *ap, unsigned int sc_reg,
Read and write standard SATA phy registers. Currently only used
if ->phy_reset hook called the sata_phy_reset() helper function.
......@@ -307,17 +385,29 @@ void (*host_stop) (struct ata_host_set *host_set);
->port_start() is called just after the data structures for each
port are initialized. Typically this is used to alloc per-port
DMA buffers / tables / rings, enable DMA engines, and similar
tasks. Some drivers also use this entry point as a chance to
allocate driver-private memory for ap->private_data.
Many drivers use ata_port_start() as this hook or call
it from their own port_start() hooks. ata_port_start()
allocates space for a legacy IDE PRD table and returns.
->port_stop() is called after ->host_stop(). It's sole function
is to release DMA/memory resources, now that they are no longer
actively being used.
actively being used. Many drivers also free driver-private
data from port at this time.
Many drivers use ata_port_stop() as this hook, which frees the
PRD table.
->host_stop() is called after all ->port_stop() calls
have completed. The hook must finalize hardware shutdown, release DMA
and other resources, etc.
This hook may be specified as NULL, in which case it is not called.
......@@ -13,13 +13,14 @@ Allocating Device Numbers
Major and minor numbers for block and character devices are allocated
by the Linux assigned name and number authority (currently better
known as H Peter Anvin). The site is This
by the Linux assigned name and number authority (currently this is
Torben Mathiasen). The site is This
also deals with allocating numbers for devices that are not going to
be submitted to the mainstream kernel.
See Documentation/devices.txt for more information on this.
If you don't use assigned numbers then when you device is submitted it will
get given an assigned number even if that is different from values you may
If you don't use assigned numbers then when your device is submitted it will
be given an assigned number even if that is different from values you may
have shipped to customers before.
Who To Submit Drivers To
......@@ -32,7 +33,8 @@ Linux 2.2:
If the code area has a general maintainer then please submit it to
the maintainer listed in MAINTAINERS in the kernel file. If the
maintainer does not respond or you cannot find the appropriate
maintainer then please contact Alan Cox <>
maintainer then please contact the 2.2 kernel maintainer:
Marc-Christian Petersen <>.
Linux 2.4:
The same rules apply as 2.2. The final contact point for Linux 2.4
......@@ -48,7 +50,7 @@ What Criteria Determine Acceptance
Licensing: The code must be released to us under the
GNU General Public License. We don't insist on any kind
of exclusively GPL licensing, and if you wish the driver
of exclusive GPL licensing, and if you wish the driver
to be useful to other communities such as BSD you may well
wish to release under multiple licenses.
......@@ -35,7 +35,7 @@ not in any lower subdirectory.
To create a patch for a single file, it is often sufficient to do:
SRCTREE= linux-2.4
SRCTREE= linux-2.6
MYFILE= drivers/net/mydriver.c
......@@ -48,17 +48,18 @@ To create a patch for multiple files, you should unpack a "vanilla",
or unmodified kernel source tree, and generate a diff against your
own source tree. For example:
MYSRC= /devel/linux-2.4
MYSRC= /devel/linux-2.6
tar xvfz linux-2.4.0-test11.tar.gz
mv linux linux-vanilla
diff -uprN -X dontdiff linux-vanilla $MYSRC > /tmp/patch
rm -f dontdiff
tar xvfz linux-2.6.12.tar.gz
mv linux-2.6.12 linux-2.6.12-vanilla
diff -uprN -X linux-2.6.12-vanilla/Documentation/dontdiff \
linux-2.6.12-vanilla $MYSRC > /tmp/patch
"dontdiff" is a list of files which are generated by the kernel during
the build process, and should be ignored in any diff(1)-generated
patch. dontdiff is maintained by Tigran Aivazian <>
patch. The "dontdiff" file is included in the kernel tree in
2.6.12 and later. For earlier kernel versions, you can get it
from <>.
Make sure your patch does not include any extra files which do not
belong in a patch submission. Make sure to review your patch -after-
......@@ -66,18 +67,20 @@ generated it with diff(1), to ensure accuracy.
If your changes produce a lot of deltas, you may want to look into
splitting them into individual patches which modify things in
logical stages, this will facilitate easier reviewing by other
logical stages. This will facilitate easier reviewing by other
kernel developers, very important if you want your patch accepted.
There are a number of scripts which can aid in this;
There are a number of scripts which can aid in this:
Randy Dunlap's patch scripts:
Andrew Morton's patch scripts:
2) Describe your changes.
......@@ -163,6 +166,8 @@ patches. Trivial patches must qualify for one of the following rules:
since people copy, as long as it's trivial)
Any fix by the author/maintainer of the file. (ie. patch monkey
in re-transmission mode)
URL: <>
......@@ -291,6 +296,17 @@ now, but you can do this to mark internal company procedures or just
point out some special detail about the sign-off.
12) More references for submitting patches
Andrew Morton, "The perfect patch" (tpp).
Jeff Garzik, "Linux kernel patch submission format."
......@@ -359,7 +375,5 @@ and 'extern __inline__'.
4) Don't over-design.
Don't try to anticipate nebulous future cases which may or may not
be useful: "Make it as simple as you can, and no simpler"
be useful: "Make it as simple as you can, and no simpler."
......@@ -622,6 +622,17 @@ running once the system is up.
ips= [HW,SCSI] Adaptec / IBM ServeRAID controller
See header of drivers/scsi/ips.c.
irqfixup [HW]
When an interrupt is not handled search all handlers
for it. Intended to get systems with badly broken
firmware running.
irqpoll [HW]
When an interrupt is not handled search all handlers
for it. Also check all handlers each timer
interrupt. Intended to get systems with badly broken
firmware running.
isapnp= [ISAPNP]
Format: <RDP>, <reset>, <pci_scan>, <verbosity>
......@@ -1030,6 +1041,10 @@ running once the system is up.
irqmask=0xMMMM [IA-32] Set a bit mask of IRQs allowed to be assigned
automatically to PCI devices. You can make the kernel
exclude IRQs of your ISA cards this way.
pirqaddr=0xAAAAA [IA-32] Specify the physical address
of the PIRQ table (normally generated
by the BIOS) if it is outside the
F0000h-100000h range.
lastbus=N [IA-32] Scan all buses till bus #N. Can be useful
if the kernel is unable to find your secondary buses
and you want to tell it explicitly which ones they are.
<TITLE>Video4Linux Kernel API Reference v0.1:19990430</TITLE>
<! Revision History: >
<! 4/30/1999 - Fred Gleason (>
<! Documented extensions for the Radio Data System (RDS) extensions >
<BODY bgcolor="#ffffff">
Video4Linux provides the following sets of device files. These live on the
character device formerly known as "/dev/bttv". /dev/bttv should be a
symlink to /dev/video0 for most people.
<TR><TH>Device Name</TH><TH>Minor Range</TH><TH>Function</TH>
<TR><TD>/dev/video</TD><TD>0-63</TD><TD>Video Capture Interface</TD>
<TR><TD>/dev/radio</TD><TD>64-127</TD><TD>AM/FM Radio Devices</TD>
<TR><TD>/dev/vtx</TD><TD>192-223</TD><TD>Teletext Interface Chips</TD>
<TR><TD>/dev/vbi</TD><TD>224-239</TD><TD>Raw VBI Data (Intercast/teletext)</TD>
Video4Linux programs open and scan the devices to find what they are looking
for. Capability queries define what each interface supports. The
described API is only defined for video capture cards. The relevant subset
applies to radio cards. Teletext interfaces talk the existing VTX API.
<H3>Capability Query Ioctl</H3>
The <B>VIDIOCGCAP</B> ioctl call is used to obtain the capability
information for a video device. The <b>struct video_capability</b> object
passed to the ioctl is completed and returned. It contains the following
<TR><TD><b>name[32]</b><TD>Canonical name for this interface</TD>
<TR><TD><b>type</b><TD>Type of interface</TD>
<TR><TD><b>channels</b><TD>Number of radio/tv channels if appropriate</TD>
<TR><TD><b>audios</b><TD>Number of audio devices if appropriate</TD>
<TR><TD><b>maxwidth</b><TD>Maximum capture width in pixels</TD>
<TR><TD><b>maxheight</b><TD>Maximum capture height in pixels</TD>
<TR><TD><b>minwidth</b><TD>Minimum capture width in pixels</TD>
<TR><TD><b>minheight</b><TD>Minimum capture height in pixels</TD>
The type field lists the capability flags for the device. These are
as follows
<TR><TD><b>VID_TYPE_CAPTURE</b><TD>Can capture to memory</TD>
<TR><TD><b>VID_TYPE_TUNER</b><TD>Has a tuner of some form</TD>
<TR><TD><b>VID_TYPE_TELETEXT</b><TD>Has teletext capability</TD>
<TR><TD><b>VID_TYPE_OVERLAY</b><TD>Can overlay its image onto the frame buffer</TD>
<TR><TD><b>VID_TYPE_CHROMAKEY</b><TD>Overlay is Chromakeyed</TD>
<TR><TD><b>VID_TYPE_CLIPPING</b><TD>Overlay clipping is supported</TD>
<TR><TD><b>VID_TYPE_FRAMERAM</b><TD>Overlay overwrites frame buffer memory</TD>
<TR><TD><b>VID_TYPE_SCALES</b><TD>The hardware supports image scaling</TD>
<TR><TD><b>VID_TYPE_MONOCHROME</b><TD>Image capture is grey scale only</TD>
<TR><TD><b>VID_TYPE_SUBCAPTURE</b><TD>Capture can be of only part of the image</TD>
The minimum and maximum sizes listed for a capture device do not imply all
that all height/width ratios or sizes within the range are possible. A
request to set a size will be honoured by the largest available capture
size whose capture is no large than the requested rectangle in either
direction. For example the quickcam has 3 fixed settings.
<H3>Frame Buffer</H3>
Capture cards that drop data directly onto the frame buffer must be told the
base address of the frame buffer, its size and organisation. This is a
privileged ioctl and one that eventually X itself should set.
The <b>VIDIOCSFBUF</b> ioctl sets the frame buffer parameters for a capture
card. If the card does not do direct writes to the frame buffer then this
ioctl will be unsupported. The <b>VIDIOCGFBUF</b> ioctl returns the
currently used parameters. The structure used in both cases is a
<b>struct video_buffer</b>.
<TR><TD><b>void *base</b></TD><TD>Base physical address of the buffer</TD>
<TR><TD><b>int height</b></TD><TD>Height of the frame buffer</TD>
<TR><TD><b>int width</b></TD><TD>Width of the frame buffer</TD>
<TR><TD><b>int depth</b></TD><TD>Depth of the frame buffer</TD>
<TR><TD><b>int bytesperline</b></TD><TD>Number of bytes of memory between the start of two adjacent lines</TD>
Note that these values reflect the physical layout of the frame buffer.
The visible area may be smaller. In fact under XFree86 this is commonly the
case. XFree86 DGA can provide the parameters required to set up this ioctl.
Setting the base address to NULL indicates there is no physical frame buffer
<H3>Capture Windows</H3>
The capture area is described by a <b>struct video_window</b>. This defines
a capture area and the clipping information if relevant. The
<b>VIDIOCGWIN</b> ioctl recovers the current settings and the
<b>VIDIOCSWIN</b> sets new values. A successful call to <b>VIDIOCSWIN</b>
indicates that a suitable set of parameters have been chosen. They do not
indicate that exactly what was requested was granted. The program should
call <b>VIDIOCGWIN</b> to check if the nearest match was suitable. The
<b>struct video_window</b> contains the following fields.
<TR><TD><b>x</b><TD>The X co-ordinate specified in X windows format.</TD>
<TR><TD><b>y</b><TD>The Y co-ordinate specified in X windows format.</TD>
<TR><TD><b>width</b><TD>The width of the image capture.</TD>
<TR><TD><b>height</b><TD>The height of the image capture.</TD>
<TR><TD><b>chromakey</b><TD>A host order RGB32 value for the chroma key.</TD>
<TR><TD><b>flags</b><TD>Additional capture flags.</TD>
<TR><TD><b>clips</b><TD>A list of clipping rectangles. <em>(Set only)</em></TD>
<TR><TD><b>clipcount</b><TD>The number of clipping rectangles. <em>(Set only)</em></TD>
Clipping rectangles are passed as an array. Each clip consists of the following
fields available to the user.
<TR><TD><b>x</b></TD><TD>X co-ordinate of rectangle to skip</TD>
<TR><TD><b>y</b></TD><TD>Y co-ordinate of rectangle to skip</TD>
<TR><TD><b>width</b></TD><TD>Width of rectangle to skip</TD>
<TR><TD><b>height</b></TD><TD>Height of rectangle to skip</TD>
Merely setting the window does not enable capturing. Overlay capturing
(i.e. PCI-PCI transfer to the frame buffer of the video card)
is activated by passing the <b>VIDIOCCAPTURE</b> ioctl a value of 1, and
disabled by passing it a value of 0.
Some capture devices can capture a subfield of the image they actually see.
This is indicated when VIDEO_TYPE_SUBCAPTURE is defined.
The video_capture describes the time and special subfields to capture.
The video_capture structure contains the following fields.
<TR><TD><b>x</b></TD><TD>X co-ordinate of source rectangle to grab</TD>
<TR><TD><b>y</b></TD><TD>Y co-ordinate of source rectangle to grab</TD>
<TR><TD><b>width</b></TD><TD>Width of source rectangle to grab</TD>
<TR><TD><b>height</b></TD><TD>Height of source rectangle to grab</TD>
<TR><TD><b>decimation</b></TD><TD>Decimation to apply</TD>
<TR><TD><b>flags</b></TD><TD>Flag settings for grabbing</TD>
The available flags are
<TR><TD><b>VIDEO_CAPTURE_ODD</b><TD>Capture only odd frames</TD>
<TR><TD><b>VIDEO_CAPTURE_EVEN</b><TD>Capture only even frames</TD>
<H3>Video Sources</H3>
Each video4linux video or audio device captures from one or more
source <b>channels</b>. Each channel can be queries with the
<b>VDIOCGCHAN</b> ioctl call. Before invoking this function the caller
must set the channel field to the channel that is being queried. On return
the <b>struct video_channel</b> is filled in with information about the
nature of the channel itself.
The <b>VIDIOCSCHAN</b> ioctl takes an integer argument and switches the
capture to this input. It is not defined whether parameters such as colour
settings or tuning are maintained across a channel switch. The caller should
maintain settings as desired for each channel. (This is reasonable as
different video inputs may have different properties).
The <b>struct video_channel</b> consists of the following
<TR><TD><b>channel</b></TD><TD>The channel number</TD>
<TR><TD><b>name</b></TD><TD>The input name - preferably reflecting the label
on the card input itself</TD>
<TR><TD><b>tuners</b></TD><TD>Number of tuners for this input</TD>
<TR><TD><b>flags</b></TD><TD>Properties the tuner has</TD>
<TR><TD><b>type</b></TD><TD>Input type (if known)</TD>
<TR><TD><b>norm</b><TD>The norm for this channel</TD>
The flags defined are
<TR><TD><b>VIDEO_VC_TUNER</b><TD>Channel has tuners.</TD>
<TR><TD><b>VIDEO_VC_AUDIO</b><TD>Channel has audio.</TD>
<TR><TD><b>VIDEO_VC_NORM</b><TD>Channel has norm setting.</TD>
The types defined are
<TR><TD><b>VIDEO_TYPE_TV</b><TD>The input is a TV input.</TD>
<TR><TD><b>VIDEO_TYPE_CAMERA</b><TD>The input is a camera.</TD>
<H3>Image Properties</H3>
The image properties of the picture can be queried with the <b>VIDIOCGPICT</b>
ioctl which fills in a <b>struct video_picture</b>. The <b>VIDIOCSPICT</b>
ioctl allows values to be changed. All values except for the palette type
are scaled between 0-65535.
The <b>struct video_picture</b> consists of the following fields
<TR><TD><b>brightness</b><TD>Picture brightness</TD>
<TR><TD><b>hue</b><TD>Picture hue (colour only)</TD>
<TR><TD><b>colour</b><TD>Picture colour (colour only)</TD>
<TR><TD><b>contrast</b><TD>Picture contrast</TD>
<TR><TD><b>whiteness</b><TD>The whiteness (greyscale only)</TD>
<TR><TD><b>depth</b><TD>The capture depth (may need to match the frame buffer depth)</TD>
<TR><TD><b>palette</b><TD>Reports the palette that should be used for this image</TD>
The following palettes are defined
<TR><TD><b>VIDEO_PALETTE_GREY</b><TD>Linear intensity grey scale (255 is brightest).</TD>
<TR><TD><b>VIDEO_PALETTE_HI240</b><TD>The BT848 8bit colour cube.</TD>
<TR><TD><b>VIDEO_PALETTE_RGB565</b><TD>RGB565 packed into 16 bit words.</TD>
<TR><TD><b>VIDEO_PALETTE_RGB555</b><TD>RGV555 packed into 16 bit words, top bit undefined.</TD>
<TR><TD><b>VIDEO_PALETTE_RGB24</b><TD>RGB888 packed into 24bit words.</TD>
<TR><TD><b>VIDEO_PALETTE_RGB32</b><TD>RGB888 packed into the low 3 bytes of 32bit words. The top 8bits are undefined.</TD>
<TR><TD><b>VIDEO_PALETTE_YUV422</b><TD>Video style YUV422 - 8bits packed 4bits Y 2bits U 2bits V</TD>
<TR><TD><b>VIDEO_PALETTE_YUYV</b><TD>Describe me</TD>
<TR><TD><b>VIDEO_PALETTE_UYVY</b><TD>Describe me</TD>
<TR><TD><b>VIDEO_PALETTE_YUV420</b><TD>YUV420 capture</TD>
<TR><TD><b>VIDEO_PALETTE_YUV411</b><TD>YUV411 capture</TD>
<TR><TD><b>VIDEO_PALETTE_RAW</b><TD>RAW capture (BT848)</TD>
<TR><TD><b>VIDEO_PALETTE_YUV422P</b><TD>YUV 4:2:2 Planar</TD>
<TR><TD><b>VIDEO_PALETTE_YUV411P</b><TD>YUV 4:1:1 Planar</TD>
Each video input channel can have one or more tuners associated with it. Many
devices will not have tuners. TV cards and radio cards will have one or more
tuners attached.
Tuners are described by a <b>struct video_tuner</b> which can be obtained by
the <b>VIDIOCGTUNER</b> ioctl. Fill in the tuner number in the structure
then pass the structure to the ioctl to have the data filled in. The
tuner can be switched using <b>VIDIOCSTUNER</b> which takes an integer argument
giving the tuner to use. A struct tuner has the following fields
<TR><TD><b>tuner</b><TD>Number of the tuner</TD>
<TR><TD><b>name</b><TD>Canonical name for this tuner (eg FM/AM/TV)</TD>
<TR><TD><b>rangelow</b><TD>Lowest tunable frequency</TD>
<TR><TD><b>rangehigh</b><TD>Highest tunable frequency</TD>
<TR><TD><b>flags</b><TD>Flags describing the tuner</TD>
<TR><TD><b>mode</b><TD>The video signal mode if relevant</TD>
<TR><TD><b>signal</b><TD>Signal strength if known - between 0-65535</TD>
The following flags exist
<TR><TD><b>VIDEO_TUNER_PAL</b><TD>PAL tuning is supported</TD>
<TR><TD><b>VIDEO_TUNER_NTSC</b><TD>NTSC tuning is supported</TD>
<TR><TD><b>VIDEO_TUNER_SECAM</b><TD>SECAM tuning is supported</TD>
<TR><TD><b>VIDEO_TUNER_LOW</b><TD>Frequency is in a lower range</TD>
<TR><TD><b>VIDEO_TUNER_NORM</b><TD>The norm for this tuner is settable</TD>
<TR><TD><b>VIDEO_TUNER_STEREO_ON</b><TD>The tuner is seeing stereo audio</TD>
<TR><TD><b>VIDEO_TUNER_RDS_ON</b><TD>The tuner is seeing a RDS datastream</TD>
<TR><TD><b>VIDEO_TUNER_MBS_ON</b><TD>The tuner is seeing a MBS datastream</TD>
The following modes are defined
<TR><TD><b>VIDEO_MODE_PAL</b><TD>The tuner is in PAL mode</TD>
<TR><TD><b>VIDEO_MODE_NTSC</b><TD>The tuner is in NTSC mode</TD>
<TR><TD><b>VIDEO_MODE_SECAM</b><TD>The tuner is in SECAM mode</TD>
<TR><TD><b>VIDEO_MODE_AUTO</b><TD>The tuner auto switches, or mode does not apply</TD>
Tuning frequencies are an unsigned 32bit value in 1/16th MHz or if the
<b>VIDEO_TUNER_LOW</b> flag is set they are in 1/16th KHz. The current
frequency is obtained as an unsigned long via the <b>VIDIOCGFREQ</b> ioctl and
set by the <b>VIDIOCSFREQ</b> ioctl.
TV and Radio devices have one or more audio inputs that may be selected.
The audio properties are queried by passing a <b>struct video_audio</b> to <b>VIDIOCGAUDIO</b> ioctl. The
<b>VIDIOCSAUDIO</b> ioctl sets audio properties.
The structure contains the following fields