Merge branch 'master' into upstream
This commit is contained in:
commit
2ade0c1d9d
|
@ -1,9 +0,0 @@
|
||||||
What: dv1394 (a.k.a. "OHCI-DV I/O support" for FireWire)
|
|
||||||
Contact: linux1394-devel@lists.sourceforge.net
|
|
||||||
Description:
|
|
||||||
New application development should use raw1394 + userspace libraries
|
|
||||||
instead, notably libiec61883 which is functionally equivalent.
|
|
||||||
|
|
||||||
Users:
|
|
||||||
ffmpeg/libavformat (used by a variety of media players)
|
|
||||||
dvgrab v1.x (replaced by dvgrab2 on top of raw1394 and resp. libraries)
|
|
22
Documentation/ABI/obsolete/proc-pid-oom_adj
Normal file
22
Documentation/ABI/obsolete/proc-pid-oom_adj
Normal file
|
@ -0,0 +1,22 @@
|
||||||
|
What: /proc/<pid>/oom_adj
|
||||||
|
When: August 2012
|
||||||
|
Why: /proc/<pid>/oom_adj allows userspace to influence the oom killer's
|
||||||
|
badness heuristic used to determine which task to kill when the kernel
|
||||||
|
is out of memory.
|
||||||
|
|
||||||
|
The badness heuristic has since been rewritten since the introduction of
|
||||||
|
this tunable such that its meaning is deprecated. The value was
|
||||||
|
implemented as a bitshift on a score generated by the badness()
|
||||||
|
function that did not have any precise units of measure. With the
|
||||||
|
rewrite, the score is given as a proportion of available memory to the
|
||||||
|
task allocating pages, so using a bitshift which grows the score
|
||||||
|
exponentially is, thus, impossible to tune with fine granularity.
|
||||||
|
|
||||||
|
A much more powerful interface, /proc/<pid>/oom_score_adj, was
|
||||||
|
introduced with the oom killer rewrite that allows users to increase or
|
||||||
|
decrease the badness() score linearly. This interface will replace
|
||||||
|
/proc/<pid>/oom_adj.
|
||||||
|
|
||||||
|
A warning will be emitted to the kernel log if an application uses this
|
||||||
|
deprecated interface. After it is printed once, future warnings will be
|
||||||
|
suppressed until the kernel is rebooted.
|
14
Documentation/ABI/removed/dv1394
Normal file
14
Documentation/ABI/removed/dv1394
Normal file
|
@ -0,0 +1,14 @@
|
||||||
|
What: dv1394 (a.k.a. "OHCI-DV I/O support" for FireWire)
|
||||||
|
Date: May 2010 (scheduled), finally removed in kernel v2.6.37
|
||||||
|
Contact: linux1394-devel@lists.sourceforge.net
|
||||||
|
Description:
|
||||||
|
/dev/dv1394/* were character device files, one for each FireWire
|
||||||
|
controller and for NTSC and PAL respectively, from which DV data
|
||||||
|
could be received by read() or transmitted by write(). A few
|
||||||
|
ioctl()s allowed limited control.
|
||||||
|
This special-purpose interface has been superseded by libraw1394 +
|
||||||
|
libiec61883 which are functionally equivalent, support HDV, and
|
||||||
|
transparently work on top of the newer firewire kernel drivers.
|
||||||
|
|
||||||
|
Users:
|
||||||
|
ffmpeg/libavformat (if configured for DV1394)
|
15
Documentation/ABI/removed/raw1394
Normal file
15
Documentation/ABI/removed/raw1394
Normal file
|
@ -0,0 +1,15 @@
|
||||||
|
What: raw1394 (a.k.a. "Raw IEEE1394 I/O support" for FireWire)
|
||||||
|
Date: May 2010 (scheduled), finally removed in kernel v2.6.37
|
||||||
|
Contact: linux1394-devel@lists.sourceforge.net
|
||||||
|
Description:
|
||||||
|
/dev/raw1394 was a character device file that allowed low-level
|
||||||
|
access to FireWire buses. Its major drawbacks were its inability
|
||||||
|
to implement sensible device security policies, and its low level
|
||||||
|
of abstraction that required userspace clients do duplicate much
|
||||||
|
of the kernel's ieee1394 core functionality.
|
||||||
|
Replaced by /dev/fw*, i.e. the <linux/firewire-cdev.h> ABI of
|
||||||
|
firewire-core.
|
||||||
|
|
||||||
|
Users:
|
||||||
|
libraw1394 (works with firewire-cdev too, transparent to library ABI
|
||||||
|
users)
|
|
@ -1,16 +0,0 @@
|
||||||
What: legacy isochronous ABI of raw1394 (1st generation iso ABI)
|
|
||||||
Date: June 2007 (scheduled), removed in kernel v2.6.23
|
|
||||||
Contact: linux1394-devel@lists.sourceforge.net
|
|
||||||
Description:
|
|
||||||
The two request types RAW1394_REQ_ISO_SEND, RAW1394_REQ_ISO_LISTEN have
|
|
||||||
been deprecated for quite some time. They are very inefficient as they
|
|
||||||
come with high interrupt load and several layers of callbacks for each
|
|
||||||
packet. Because of these deficiencies, the video1394 and dv1394 drivers
|
|
||||||
and the 3rd-generation isochronous ABI in raw1394 (rawiso) were created.
|
|
||||||
|
|
||||||
Users:
|
|
||||||
libraw1394 users via the long deprecated API raw1394_iso_write,
|
|
||||||
raw1394_start_iso_write, raw1394_start_iso_rcv, raw1394_stop_iso_rcv
|
|
||||||
|
|
||||||
libdc1394, which optionally uses these old libraw1394 calls
|
|
||||||
alternatively to the more efficient video1394 ABI
|
|
16
Documentation/ABI/removed/video1394
Normal file
16
Documentation/ABI/removed/video1394
Normal file
|
@ -0,0 +1,16 @@
|
||||||
|
What: video1394 (a.k.a. "OHCI-1394 Video support" for FireWire)
|
||||||
|
Date: May 2010 (scheduled), finally removed in kernel v2.6.37
|
||||||
|
Contact: linux1394-devel@lists.sourceforge.net
|
||||||
|
Description:
|
||||||
|
/dev/video1394/* were character device files, one for each FireWire
|
||||||
|
controller, which were used for isochronous I/O. It was added as an
|
||||||
|
alternative to raw1394's isochronous I/O functionality which had
|
||||||
|
performance issues in its first generation. Any video1394 user had
|
||||||
|
to use raw1394 + libraw1394 too because video1394 did not provide
|
||||||
|
asynchronous I/O for device discovery and configuration.
|
||||||
|
Replaced by /dev/fw*, i.e. the <linux/firewire-cdev.h> ABI of
|
||||||
|
firewire-core.
|
||||||
|
|
||||||
|
Users:
|
||||||
|
libdc1394 (works with firewire-cdev too, transparent to library ABI
|
||||||
|
users)
|
99
Documentation/ABI/testing/sysfs-block-zram
Normal file
99
Documentation/ABI/testing/sysfs-block-zram
Normal file
|
@ -0,0 +1,99 @@
|
||||||
|
What: /sys/block/zram<id>/disksize
|
||||||
|
Date: August 2010
|
||||||
|
Contact: Nitin Gupta <ngupta@vflare.org>
|
||||||
|
Description:
|
||||||
|
The disksize file is read-write and specifies the disk size
|
||||||
|
which represents the limit on the *uncompressed* worth of data
|
||||||
|
that can be stored in this disk.
|
||||||
|
|
||||||
|
What: /sys/block/zram<id>/initstate
|
||||||
|
Date: August 2010
|
||||||
|
Contact: Nitin Gupta <ngupta@vflare.org>
|
||||||
|
Description:
|
||||||
|
The disksize file is read-only and shows the initialization
|
||||||
|
state of the device.
|
||||||
|
|
||||||
|
What: /sys/block/zram<id>/reset
|
||||||
|
Date: August 2010
|
||||||
|
Contact: Nitin Gupta <ngupta@vflare.org>
|
||||||
|
Description:
|
||||||
|
The disksize file is write-only and allows resetting the
|
||||||
|
device. The reset operation frees all the memory assocaited
|
||||||
|
with this device.
|
||||||
|
|
||||||
|
What: /sys/block/zram<id>/num_reads
|
||||||
|
Date: August 2010
|
||||||
|
Contact: Nitin Gupta <ngupta@vflare.org>
|
||||||
|
Description:
|
||||||
|
The num_reads file is read-only and specifies the number of
|
||||||
|
reads (failed or successful) done on this device.
|
||||||
|
|
||||||
|
What: /sys/block/zram<id>/num_writes
|
||||||
|
Date: August 2010
|
||||||
|
Contact: Nitin Gupta <ngupta@vflare.org>
|
||||||
|
Description:
|
||||||
|
The num_writes file is read-only and specifies the number of
|
||||||
|
writes (failed or successful) done on this device.
|
||||||
|
|
||||||
|
What: /sys/block/zram<id>/invalid_io
|
||||||
|
Date: August 2010
|
||||||
|
Contact: Nitin Gupta <ngupta@vflare.org>
|
||||||
|
Description:
|
||||||
|
The invalid_io file is read-only and specifies the number of
|
||||||
|
non-page-size-aligned I/O requests issued to this device.
|
||||||
|
|
||||||
|
What: /sys/block/zram<id>/notify_free
|
||||||
|
Date: August 2010
|
||||||
|
Contact: Nitin Gupta <ngupta@vflare.org>
|
||||||
|
Description:
|
||||||
|
The notify_free file is read-only and specifies the number of
|
||||||
|
swap slot free notifications received by this device. These
|
||||||
|
notifications are send to a swap block device when a swap slot
|
||||||
|
is freed. This statistic is applicable only when this disk is
|
||||||
|
being used as a swap disk.
|
||||||
|
|
||||||
|
What: /sys/block/zram<id>/discard
|
||||||
|
Date: August 2010
|
||||||
|
Contact: Nitin Gupta <ngupta@vflare.org>
|
||||||
|
Description:
|
||||||
|
The discard file is read-only and specifies the number of
|
||||||
|
discard requests received by this device. These requests
|
||||||
|
provide information to block device regarding blocks which are
|
||||||
|
no longer used by filesystem.
|
||||||
|
|
||||||
|
What: /sys/block/zram<id>/zero_pages
|
||||||
|
Date: August 2010
|
||||||
|
Contact: Nitin Gupta <ngupta@vflare.org>
|
||||||
|
Description:
|
||||||
|
The zero_pages file is read-only and specifies number of zero
|
||||||
|
filled pages written to this disk. No memory is allocated for
|
||||||
|
such pages.
|
||||||
|
|
||||||
|
What: /sys/block/zram<id>/orig_data_size
|
||||||
|
Date: August 2010
|
||||||
|
Contact: Nitin Gupta <ngupta@vflare.org>
|
||||||
|
Description:
|
||||||
|
The orig_data_size file is read-only and specifies uncompressed
|
||||||
|
size of data stored in this disk. This excludes zero-filled
|
||||||
|
pages (zero_pages) since no memory is allocated for them.
|
||||||
|
Unit: bytes
|
||||||
|
|
||||||
|
What: /sys/block/zram<id>/compr_data_size
|
||||||
|
Date: August 2010
|
||||||
|
Contact: Nitin Gupta <ngupta@vflare.org>
|
||||||
|
Description:
|
||||||
|
The compr_data_size file is read-only and specifies compressed
|
||||||
|
size of data stored in this disk. So, compression ratio can be
|
||||||
|
calculated using orig_data_size and this statistic.
|
||||||
|
Unit: bytes
|
||||||
|
|
||||||
|
What: /sys/block/zram<id>/mem_used_total
|
||||||
|
Date: August 2010
|
||||||
|
Contact: Nitin Gupta <ngupta@vflare.org>
|
||||||
|
Description:
|
||||||
|
The mem_used_total file is read-only and specifies the amount
|
||||||
|
of memory, including allocator fragmentation and metadata
|
||||||
|
overhead, allocated for this disk. So, allocator space
|
||||||
|
efficiency can be calculated using compr_data_size and this
|
||||||
|
statistic.
|
||||||
|
Unit: bytes
|
83
Documentation/ABI/testing/sysfs-bus-rbd
Normal file
83
Documentation/ABI/testing/sysfs-bus-rbd
Normal file
|
@ -0,0 +1,83 @@
|
||||||
|
What: /sys/bus/rbd/
|
||||||
|
Date: November 2010
|
||||||
|
Contact: Yehuda Sadeh <yehuda@hq.newdream.net>,
|
||||||
|
Sage Weil <sage@newdream.net>
|
||||||
|
Description:
|
||||||
|
|
||||||
|
Being used for adding and removing rbd block devices.
|
||||||
|
|
||||||
|
Usage: <mon ip addr> <options> <pool name> <rbd image name> [snap name]
|
||||||
|
|
||||||
|
$ echo "192.168.0.1 name=admin rbd foo" > /sys/bus/rbd/add
|
||||||
|
|
||||||
|
The snapshot name can be "-" or omitted to map the image read/write. A <dev-id>
|
||||||
|
will be assigned for any registered block device. If snapshot is used, it will
|
||||||
|
be mapped read-only.
|
||||||
|
|
||||||
|
Removal of a device:
|
||||||
|
|
||||||
|
$ echo <dev-id> > /sys/bus/rbd/remove
|
||||||
|
|
||||||
|
Entries under /sys/bus/rbd/devices/<dev-id>/
|
||||||
|
--------------------------------------------
|
||||||
|
|
||||||
|
client_id
|
||||||
|
|
||||||
|
The ceph unique client id that was assigned for this specific session.
|
||||||
|
|
||||||
|
major
|
||||||
|
|
||||||
|
The block device major number.
|
||||||
|
|
||||||
|
name
|
||||||
|
|
||||||
|
The name of the rbd image.
|
||||||
|
|
||||||
|
pool
|
||||||
|
|
||||||
|
The pool where this rbd image resides. The pool-name pair is unique
|
||||||
|
per rados system.
|
||||||
|
|
||||||
|
size
|
||||||
|
|
||||||
|
The size (in bytes) of the mapped block device.
|
||||||
|
|
||||||
|
refresh
|
||||||
|
|
||||||
|
Writing to this file will reread the image header data and set
|
||||||
|
all relevant datastructures accordingly.
|
||||||
|
|
||||||
|
current_snap
|
||||||
|
|
||||||
|
The current snapshot for which the device is mapped.
|
||||||
|
|
||||||
|
create_snap
|
||||||
|
|
||||||
|
Create a snapshot:
|
||||||
|
|
||||||
|
$ echo <snap-name> > /sys/bus/rbd/devices/<dev-id>/snap_create
|
||||||
|
|
||||||
|
rollback_snap
|
||||||
|
|
||||||
|
Rolls back data to the specified snapshot. This goes over the entire
|
||||||
|
list of rados blocks and sends a rollback command to each.
|
||||||
|
|
||||||
|
$ echo <snap-name> > /sys/bus/rbd/devices/<dev-id>/snap_rollback
|
||||||
|
|
||||||
|
snap_*
|
||||||
|
|
||||||
|
A directory per each snapshot
|
||||||
|
|
||||||
|
|
||||||
|
Entries under /sys/bus/rbd/devices/<dev-id>/snap_<snap-name>
|
||||||
|
-------------------------------------------------------------
|
||||||
|
|
||||||
|
id
|
||||||
|
|
||||||
|
The rados internal snapshot id assigned for this snapshot
|
||||||
|
|
||||||
|
size
|
||||||
|
|
||||||
|
The size of the image when this snapshot was taken.
|
||||||
|
|
||||||
|
|
22
Documentation/ABI/testing/sysfs-devices-system-ibm-rtl
Normal file
22
Documentation/ABI/testing/sysfs-devices-system-ibm-rtl
Normal file
|
@ -0,0 +1,22 @@
|
||||||
|
What: state
|
||||||
|
Date: Sep 2010
|
||||||
|
KernelVersion: 2.6.37
|
||||||
|
Contact: Vernon Mauery <vernux@us.ibm.com>
|
||||||
|
Description: The state file allows a means by which to change in and
|
||||||
|
out of Premium Real-Time Mode (PRTM), as well as the
|
||||||
|
ability to query the current state.
|
||||||
|
0 => PRTM off
|
||||||
|
1 => PRTM enabled
|
||||||
|
Users: The ibm-prtm userspace daemon uses this interface.
|
||||||
|
|
||||||
|
|
||||||
|
What: version
|
||||||
|
Date: Sep 2010
|
||||||
|
KernelVersion: 2.6.37
|
||||||
|
Contact: Vernon Mauery <vernux@us.ibm.com>
|
||||||
|
Description: The version file provides a means by which to query
|
||||||
|
the RTL table version that lives in the Extended
|
||||||
|
BIOS Data Area (EBDA).
|
||||||
|
Users: The ibm-prtm userspace daemon uses this interface.
|
||||||
|
|
||||||
|
|
|
@ -47,6 +47,20 @@ Date: January 2007
|
||||||
KernelVersion: 2.6.20
|
KernelVersion: 2.6.20
|
||||||
Contact: "Corentin Chary" <corentincj@iksaif.net>
|
Contact: "Corentin Chary" <corentincj@iksaif.net>
|
||||||
Description:
|
Description:
|
||||||
Control the bluetooth device. 1 means on, 0 means off.
|
Control the wlan device. 1 means on, 0 means off.
|
||||||
This may control the led, the device or both.
|
This may control the led, the device or both.
|
||||||
Users: Lapsus
|
Users: Lapsus
|
||||||
|
|
||||||
|
What: /sys/devices/platform/asus_laptop/wimax
|
||||||
|
Date: October 2010
|
||||||
|
KernelVersion: 2.6.37
|
||||||
|
Contact: "Corentin Chary" <corentincj@iksaif.net>
|
||||||
|
Description:
|
||||||
|
Control the wimax device. 1 means on, 0 means off.
|
||||||
|
|
||||||
|
What: /sys/devices/platform/asus_laptop/wwan
|
||||||
|
Date: October 2010
|
||||||
|
KernelVersion: 2.6.37
|
||||||
|
Contact: "Corentin Chary" <corentincj@iksaif.net>
|
||||||
|
Description:
|
||||||
|
Control the wwan (3G) device. 1 means on, 0 means off.
|
||||||
|
|
10
Documentation/ABI/testing/sysfs-platform-eeepc-wmi
Normal file
10
Documentation/ABI/testing/sysfs-platform-eeepc-wmi
Normal file
|
@ -0,0 +1,10 @@
|
||||||
|
What: /sys/devices/platform/eeepc-wmi/cpufv
|
||||||
|
Date: Oct 2010
|
||||||
|
KernelVersion: 2.6.37
|
||||||
|
Contact: "Corentin Chary" <corentincj@iksaif.net>
|
||||||
|
Description:
|
||||||
|
Change CPU clock configuration (write-only).
|
||||||
|
There are three available clock configuration:
|
||||||
|
* 0 -> Super Performance Mode
|
||||||
|
* 1 -> High Performance Mode
|
||||||
|
* 2 -> Power Saving Mode
|
|
@ -51,7 +51,12 @@
|
||||||
<sect1><title>Delaying, scheduling, and timer routines</title>
|
<sect1><title>Delaying, scheduling, and timer routines</title>
|
||||||
!Iinclude/linux/sched.h
|
!Iinclude/linux/sched.h
|
||||||
!Ekernel/sched.c
|
!Ekernel/sched.c
|
||||||
|
!Iinclude/linux/completion.h
|
||||||
!Ekernel/timer.c
|
!Ekernel/timer.c
|
||||||
|
</sect1>
|
||||||
|
<sect1><title>Wait queues and Wake events</title>
|
||||||
|
!Iinclude/linux/wait.h
|
||||||
|
!Ekernel/wait.c
|
||||||
</sect1>
|
</sect1>
|
||||||
<sect1><title>High-resolution timers</title>
|
<sect1><title>High-resolution timers</title>
|
||||||
!Iinclude/linux/ktime.h
|
!Iinclude/linux/ktime.h
|
||||||
|
|
|
@ -93,6 +93,12 @@ X!Ilib/string.c
|
||||||
!Elib/crc32.c
|
!Elib/crc32.c
|
||||||
!Elib/crc-ccitt.c
|
!Elib/crc-ccitt.c
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
|
<sect1 id="idr"><title>idr/ida Functions</title>
|
||||||
|
!Pinclude/linux/idr.h idr sync
|
||||||
|
!Plib/idr.c IDA description
|
||||||
|
!Elib/idr.c
|
||||||
|
</sect1>
|
||||||
</chapter>
|
</chapter>
|
||||||
|
|
||||||
<chapter id="mm">
|
<chapter id="mm">
|
||||||
|
|
|
@ -710,7 +710,18 @@ Task Addr Pid Parent [*] cpu State Thread Command
|
||||||
<listitem><para>A simple shell</para></listitem>
|
<listitem><para>A simple shell</para></listitem>
|
||||||
<listitem><para>The kdb core command set</para></listitem>
|
<listitem><para>The kdb core command set</para></listitem>
|
||||||
<listitem><para>A registration API to register additional kdb shell commands.</para>
|
<listitem><para>A registration API to register additional kdb shell commands.</para>
|
||||||
<para>A good example of a self-contained kdb module is the "ftdump" command for dumping the ftrace buffer. See: kernel/trace/trace_kdb.c</para></listitem>
|
<itemizedlist>
|
||||||
|
<listitem><para>A good example of a self-contained kdb module
|
||||||
|
is the "ftdump" command for dumping the ftrace buffer. See:
|
||||||
|
kernel/trace/trace_kdb.c</para></listitem>
|
||||||
|
<listitem><para>For an example of how to dynamically register
|
||||||
|
a new kdb command you can build the kdb_hello.ko kernel module
|
||||||
|
from samples/kdb/kdb_hello.c. To build this example you can
|
||||||
|
set CONFIG_SAMPLES=y and CONFIG_SAMPLE_KDB=m in your kernel
|
||||||
|
config. Later run "modprobe kdb_hello" and the next time you
|
||||||
|
enter the kdb shell, you can run the "hello"
|
||||||
|
command.</para></listitem>
|
||||||
|
</itemizedlist></listitem>
|
||||||
<listitem><para>The implementation for kdb_printf() which
|
<listitem><para>The implementation for kdb_printf() which
|
||||||
emits messages directly to I/O drivers, bypassing the kernel
|
emits messages directly to I/O drivers, bypassing the kernel
|
||||||
log.</para></listitem>
|
log.</para></listitem>
|
||||||
|
|
|
@ -250,6 +250,9 @@
|
||||||
<!ENTITY sub-yuv422p SYSTEM "v4l/pixfmt-yuv422p.xml">
|
<!ENTITY sub-yuv422p SYSTEM "v4l/pixfmt-yuv422p.xml">
|
||||||
<!ENTITY sub-yuyv SYSTEM "v4l/pixfmt-yuyv.xml">
|
<!ENTITY sub-yuyv SYSTEM "v4l/pixfmt-yuyv.xml">
|
||||||
<!ENTITY sub-yvyu SYSTEM "v4l/pixfmt-yvyu.xml">
|
<!ENTITY sub-yvyu SYSTEM "v4l/pixfmt-yvyu.xml">
|
||||||
|
<!ENTITY sub-srggb10 SYSTEM "v4l/pixfmt-srggb10.xml">
|
||||||
|
<!ENTITY sub-srggb8 SYSTEM "v4l/pixfmt-srggb8.xml">
|
||||||
|
<!ENTITY sub-y10 SYSTEM "v4l/pixfmt-y10.xml">
|
||||||
<!ENTITY sub-pixfmt SYSTEM "v4l/pixfmt.xml">
|
<!ENTITY sub-pixfmt SYSTEM "v4l/pixfmt.xml">
|
||||||
<!ENTITY sub-cropcap SYSTEM "v4l/vidioc-cropcap.xml">
|
<!ENTITY sub-cropcap SYSTEM "v4l/vidioc-cropcap.xml">
|
||||||
<!ENTITY sub-dbg-g-register SYSTEM "v4l/vidioc-dbg-g-register.xml">
|
<!ENTITY sub-dbg-g-register SYSTEM "v4l/vidioc-dbg-g-register.xml">
|
||||||
|
@ -347,6 +350,9 @@
|
||||||
<!ENTITY yuv422p SYSTEM "v4l/pixfmt-yuv422p.xml">
|
<!ENTITY yuv422p SYSTEM "v4l/pixfmt-yuv422p.xml">
|
||||||
<!ENTITY yuyv SYSTEM "v4l/pixfmt-yuyv.xml">
|
<!ENTITY yuyv SYSTEM "v4l/pixfmt-yuyv.xml">
|
||||||
<!ENTITY yvyu SYSTEM "v4l/pixfmt-yvyu.xml">
|
<!ENTITY yvyu SYSTEM "v4l/pixfmt-yvyu.xml">
|
||||||
|
<!ENTITY srggb10 SYSTEM "v4l/pixfmt-srggb10.xml">
|
||||||
|
<!ENTITY srggb8 SYSTEM "v4l/pixfmt-srggb8.xml">
|
||||||
|
<!ENTITY y10 SYSTEM "v4l/pixfmt-y10.xml">
|
||||||
<!ENTITY cropcap SYSTEM "v4l/vidioc-cropcap.xml">
|
<!ENTITY cropcap SYSTEM "v4l/vidioc-cropcap.xml">
|
||||||
<!ENTITY dbg-g-register SYSTEM "v4l/vidioc-dbg-g-register.xml">
|
<!ENTITY dbg-g-register SYSTEM "v4l/vidioc-dbg-g-register.xml">
|
||||||
<!ENTITY encoder-cmd SYSTEM "v4l/vidioc-encoder-cmd.xml">
|
<!ENTITY encoder-cmd SYSTEM "v4l/vidioc-encoder-cmd.xml">
|
||||||
|
|
|
@ -79,10 +79,6 @@
|
||||||
</sect2>
|
</sect2>
|
||||||
</sect1>
|
</sect1>
|
||||||
</chapter>
|
</chapter>
|
||||||
<chapter id="clk">
|
|
||||||
<title>Clock Framework Extensions</title>
|
|
||||||
!Iinclude/linux/sh_clk.h
|
|
||||||
</chapter>
|
|
||||||
<chapter id="mach">
|
<chapter id="mach">
|
||||||
<title>Machine Specific Interfaces</title>
|
<title>Machine Specific Interfaces</title>
|
||||||
<sect1 id="dreamcast">
|
<sect1 id="dreamcast">
|
||||||
|
|
|
@ -16,7 +16,7 @@
|
||||||
</orgname>
|
</orgname>
|
||||||
|
|
||||||
<address>
|
<address>
|
||||||
<email>hjk@linutronix.de</email>
|
<email>hjk@hansjkoch.de</email>
|
||||||
</address>
|
</address>
|
||||||
</affiliation>
|
</affiliation>
|
||||||
</author>
|
</author>
|
||||||
|
@ -114,7 +114,7 @@ GPL version 2.
|
||||||
|
|
||||||
<para>If you know of any translations for this document, or you are
|
<para>If you know of any translations for this document, or you are
|
||||||
interested in translating it, please email me
|
interested in translating it, please email me
|
||||||
<email>hjk@linutronix.de</email>.
|
<email>hjk@hansjkoch.de</email>.
|
||||||
</para>
|
</para>
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
|
@ -171,7 +171,7 @@ interested in translating it, please email me
|
||||||
<title>Feedback</title>
|
<title>Feedback</title>
|
||||||
<para>Find something wrong with this document? (Or perhaps something
|
<para>Find something wrong with this document? (Or perhaps something
|
||||||
right?) I would love to hear from you. Please email me at
|
right?) I would love to hear from you. Please email me at
|
||||||
<email>hjk@linutronix.de</email>.</para>
|
<email>hjk@hansjkoch.de</email>.</para>
|
||||||
</sect1>
|
</sect1>
|
||||||
</chapter>
|
</chapter>
|
||||||
|
|
||||||
|
|
|
@ -21,11 +21,15 @@ API.</para>
|
||||||
<title>Opening and Closing Devices</title>
|
<title>Opening and Closing Devices</title>
|
||||||
|
|
||||||
<para>For compatibility reasons the character device file names
|
<para>For compatibility reasons the character device file names
|
||||||
recommended for V4L2 video capture, overlay, radio, teletext and raw
|
recommended for V4L2 video capture, overlay, radio and raw
|
||||||
vbi capture devices did not change from those used by V4L. They are
|
vbi capture devices did not change from those used by V4L. They are
|
||||||
listed in <xref linkend="devices" /> and below in <xref
|
listed in <xref linkend="devices" /> and below in <xref
|
||||||
linkend="v4l-dev" />.</para>
|
linkend="v4l-dev" />.</para>
|
||||||
|
|
||||||
|
<para>The teletext devices (minor range 192-223) have been removed in
|
||||||
|
V4L2 and no longer exist. There is no hardware available anymore for handling
|
||||||
|
pure teletext. Instead raw or sliced VBI is used.</para>
|
||||||
|
|
||||||
<para>The V4L <filename>videodev</filename> module automatically
|
<para>The V4L <filename>videodev</filename> module automatically
|
||||||
assigns minor numbers to drivers in load order, depending on the
|
assigns minor numbers to drivers in load order, depending on the
|
||||||
registered device type. We recommend that V4L2 drivers by default
|
registered device type. We recommend that V4L2 drivers by default
|
||||||
|
@ -65,13 +69,6 @@ not compatible with V4L or V4L2.</para> </footnote>,
|
||||||
<filename>/dev/radio63</filename></para></entry>
|
<filename>/dev/radio63</filename></para></entry>
|
||||||
<entry>64-127</entry>
|
<entry>64-127</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
|
||||||
<entry>Teletext decoder</entry>
|
|
||||||
<entry><para><filename>/dev/vtx</filename>,
|
|
||||||
<filename>/dev/vtx0</filename> to
|
|
||||||
<filename>/dev/vtx31</filename></para></entry>
|
|
||||||
<entry>192-223</entry>
|
|
||||||
</row>
|
|
||||||
<row>
|
<row>
|
||||||
<entry>Raw VBI capture</entry>
|
<entry>Raw VBI capture</entry>
|
||||||
<entry><para><filename>/dev/vbi</filename>,
|
<entry><para><filename>/dev/vbi</filename>,
|
||||||
|
@ -2345,6 +2342,17 @@ more information.</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</orderedlist>
|
</orderedlist>
|
||||||
</section>
|
</section>
|
||||||
|
<section>
|
||||||
|
<title>V4L2 in Linux 2.6.37</title>
|
||||||
|
<orderedlist>
|
||||||
|
<listitem>
|
||||||
|
<para>Remove the vtx (videotext/teletext) API. This API was no longer
|
||||||
|
used and no hardware exists to verify the API. Nor were any userspace applications found
|
||||||
|
that used it. It was originally scheduled for removal in 2.6.35.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</orderedlist>
|
||||||
|
</section>
|
||||||
|
|
||||||
<section id="other">
|
<section id="other">
|
||||||
<title>Relation of V4L2 to other Linux multimedia APIs</title>
|
<title>Relation of V4L2 to other Linux multimedia APIs</title>
|
||||||
|
|
|
@ -311,11 +311,18 @@ minimum value disables backlight compensation.</entry>
|
||||||
bits 8-15 Green color information, bits 16-23 Blue color
|
bits 8-15 Green color information, bits 16-23 Blue color
|
||||||
information and bits 24-31 must be zero.</entry>
|
information and bits 24-31 must be zero.</entry>
|
||||||
</row>
|
</row>
|
||||||
|
<row>
|
||||||
|
<entry><constant>V4L2_CID_ILLUMINATORS_1</constant>
|
||||||
|
<constant>V4L2_CID_ILLUMINATORS_2</constant></entry>
|
||||||
|
<entry>boolean</entry>
|
||||||
|
<entry>Switch on or off the illuminator 1 or 2 of the device
|
||||||
|
(usually a microscope).</entry>
|
||||||
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><constant>V4L2_CID_LASTP1</constant></entry>
|
<entry><constant>V4L2_CID_LASTP1</constant></entry>
|
||||||
<entry></entry>
|
<entry></entry>
|
||||||
<entry>End of the predefined control IDs (currently
|
<entry>End of the predefined control IDs (currently
|
||||||
<constant>V4L2_CID_BG_COLOR</constant> + 1).</entry>
|
<constant>V4L2_CID_ILLUMINATORS_2</constant> + 1).</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><constant>V4L2_CID_PRIVATE_BASE</constant></entry>
|
<entry><constant>V4L2_CID_PRIVATE_BASE</constant></entry>
|
||||||
|
@ -357,9 +364,6 @@ enumerate_menu (void)
|
||||||
querymenu.index++) {
|
querymenu.index++) {
|
||||||
if (0 == ioctl (fd, &VIDIOC-QUERYMENU;, &querymenu)) {
|
if (0 == ioctl (fd, &VIDIOC-QUERYMENU;, &querymenu)) {
|
||||||
printf (" %s\n", querymenu.name);
|
printf (" %s\n", querymenu.name);
|
||||||
} else {
|
|
||||||
perror ("VIDIOC_QUERYMENU");
|
|
||||||
exit (EXIT_FAILURE);
|
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
|
@ -3,15 +3,16 @@
|
||||||
<para>The Radio Data System transmits supplementary
|
<para>The Radio Data System transmits supplementary
|
||||||
information in binary format, for example the station name or travel
|
information in binary format, for example the station name or travel
|
||||||
information, on an inaudible audio subcarrier of a radio program. This
|
information, on an inaudible audio subcarrier of a radio program. This
|
||||||
interface is aimed at devices capable of receiving and decoding RDS
|
interface is aimed at devices capable of receiving and/or transmitting RDS
|
||||||
information.</para>
|
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="en50067" />
|
||||||
and the RBDS standard <xref linkend="nrsc4" />.</para>
|
and the RBDS standard <xref linkend="nrsc4" />.</para>
|
||||||
|
|
||||||
<para>Note that the RBDS standard as is used in the USA is almost identical
|
<para>Note that the RBDS standard as is used in the USA is almost identical
|
||||||
to the RDS standard. Any RDS decoder can also handle RBDS. Only some of the fields
|
to the RDS standard. Any RDS decoder/encoder can also handle RBDS. Only some of the
|
||||||
have slightly different meanings. See the RBDS standard for more information.</para>
|
fields have slightly different meanings. See the RBDS standard for more
|
||||||
|
information.</para>
|
||||||
|
|
||||||
<para>The RBDS standard also specifies support for MMBS (Modified Mobile Search).
|
<para>The RBDS standard also specifies support for MMBS (Modified Mobile Search).
|
||||||
This is a proprietary format which seems to be discontinued. The RDS interface does not
|
This is a proprietary format which seems to be discontinued. The RDS interface does not
|
||||||
|
@ -21,16 +22,25 @@ be needed, then please contact the linux-media mailing list: &v4l-ml;.</para>
|
||||||
<section>
|
<section>
|
||||||
<title>Querying Capabilities</title>
|
<title>Querying Capabilities</title>
|
||||||
|
|
||||||
<para>Devices supporting the RDS capturing API
|
<para>Devices supporting the RDS capturing API set
|
||||||
set the <constant>V4L2_CAP_RDS_CAPTURE</constant> flag in
|
the <constant>V4L2_CAP_RDS_CAPTURE</constant> flag in
|
||||||
the <structfield>capabilities</structfield> field of &v4l2-capability;
|
the <structfield>capabilities</structfield> field of &v4l2-capability;
|
||||||
returned by the &VIDIOC-QUERYCAP; ioctl.
|
returned by the &VIDIOC-QUERYCAP; ioctl. Any tuner that supports RDS
|
||||||
Any tuner that supports RDS will set the
|
will set the <constant>V4L2_TUNER_CAP_RDS</constant> flag in
|
||||||
<constant>V4L2_TUNER_CAP_RDS</constant> flag in the <structfield>capability</structfield>
|
the <structfield>capability</structfield> field of &v4l2-tuner;. If
|
||||||
field of &v4l2-tuner;.
|
the driver only passes RDS blocks without interpreting the data
|
||||||
Whether an RDS signal is present can be detected by looking at
|
the <constant>V4L2_TUNER_SUB_RDS_BLOCK_IO</constant> flag has to be
|
||||||
the <structfield>rxsubchans</structfield> field of &v4l2-tuner;: the
|
set, see <link linkend="reading-rds-data">Reading RDS data</link>.
|
||||||
<constant>V4L2_TUNER_SUB_RDS</constant> will be set if RDS data was detected.</para>
|
For future use the
|
||||||
|
flag <constant>V4L2_TUNER_SUB_RDS_CONTROLS</constant> has also been
|
||||||
|
defined. However, a driver for a radio tuner with this capability does
|
||||||
|
not yet exist, so if you are planning to write such a driver you
|
||||||
|
should discuss this on the linux-media mailing list: &v4l-ml;.</para>
|
||||||
|
|
||||||
|
<para> Whether an RDS signal is present can be detected by looking
|
||||||
|
at the <structfield>rxsubchans</structfield> field of &v4l2-tuner;:
|
||||||
|
the <constant>V4L2_TUNER_SUB_RDS</constant> will be set if RDS data
|
||||||
|
was detected.</para>
|
||||||
|
|
||||||
<para>Devices supporting the RDS output API
|
<para>Devices supporting the RDS output API
|
||||||
set the <constant>V4L2_CAP_RDS_OUTPUT</constant> flag in
|
set the <constant>V4L2_CAP_RDS_OUTPUT</constant> flag in
|
||||||
|
@ -40,16 +50,31 @@ Any modulator that supports RDS will set the
|
||||||
<constant>V4L2_TUNER_CAP_RDS</constant> flag in the <structfield>capability</structfield>
|
<constant>V4L2_TUNER_CAP_RDS</constant> flag in the <structfield>capability</structfield>
|
||||||
field of &v4l2-modulator;.
|
field of &v4l2-modulator;.
|
||||||
In order to enable the RDS transmission one must set the <constant>V4L2_TUNER_SUB_RDS</constant>
|
In order to enable the RDS transmission one must set the <constant>V4L2_TUNER_SUB_RDS</constant>
|
||||||
bit in the <structfield>txsubchans</structfield> field of &v4l2-modulator;.</para>
|
bit in the <structfield>txsubchans</structfield> field of &v4l2-modulator;.
|
||||||
|
If the driver only passes RDS blocks without interpreting the data
|
||||||
|
the <constant>V4L2_TUNER_SUB_RDS_BLOCK_IO</constant> flag has to be set. If the
|
||||||
|
tuner is capable of handling RDS entities like program identification codes and radio
|
||||||
|
text, the flag <constant>V4L2_TUNER_SUB_RDS_CONTROLS</constant> should be set,
|
||||||
|
see <link linkend="writing-rds-data">Writing RDS data</link> and
|
||||||
|
<link linkend="fm-tx-controls">FM Transmitter Control Reference</link>.</para>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section>
|
<section id="reading-rds-data">
|
||||||
<title>Reading RDS data</title>
|
<title>Reading RDS data</title>
|
||||||
|
|
||||||
<para>RDS data can be read from the radio device
|
<para>RDS data can be read from the radio device
|
||||||
with the &func-read; function. The data is packed in groups of three bytes,
|
with the &func-read; function. The data is packed in groups of three bytes.</para>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section id="writing-rds-data">
|
||||||
|
<title>Writing RDS data</title>
|
||||||
|
|
||||||
|
<para>RDS data can be written to the radio device
|
||||||
|
with the &func-write; function. The data is packed in groups of three bytes,
|
||||||
as follows:</para>
|
as follows:</para>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
<table frame="none" pgwide="1" id="v4l2-rds-data">
|
<table frame="none" pgwide="1" id="v4l2-rds-data">
|
||||||
<title>struct
|
<title>struct
|
||||||
<structname>v4l2_rds_data</structname></title>
|
<structname>v4l2_rds_data</structname></title>
|
||||||
|
@ -111,48 +136,57 @@ as follows:</para>
|
||||||
<tbody valign="top">
|
<tbody valign="top">
|
||||||
<row>
|
<row>
|
||||||
<entry>V4L2_RDS_BLOCK_MSK</entry>
|
<entry>V4L2_RDS_BLOCK_MSK</entry>
|
||||||
|
<entry> </entry>
|
||||||
<entry>7</entry>
|
<entry>7</entry>
|
||||||
<entry>Mask for bits 0-2 to get the block ID.</entry>
|
<entry>Mask for bits 0-2 to get the block ID.</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry>V4L2_RDS_BLOCK_A</entry>
|
<entry>V4L2_RDS_BLOCK_A</entry>
|
||||||
|
<entry> </entry>
|
||||||
<entry>0</entry>
|
<entry>0</entry>
|
||||||
<entry>Block A.</entry>
|
<entry>Block A.</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry>V4L2_RDS_BLOCK_B</entry>
|
<entry>V4L2_RDS_BLOCK_B</entry>
|
||||||
|
<entry> </entry>
|
||||||
<entry>1</entry>
|
<entry>1</entry>
|
||||||
<entry>Block B.</entry>
|
<entry>Block B.</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry>V4L2_RDS_BLOCK_C</entry>
|
<entry>V4L2_RDS_BLOCK_C</entry>
|
||||||
|
<entry> </entry>
|
||||||
<entry>2</entry>
|
<entry>2</entry>
|
||||||
<entry>Block C.</entry>
|
<entry>Block C.</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry>V4L2_RDS_BLOCK_D</entry>
|
<entry>V4L2_RDS_BLOCK_D</entry>
|
||||||
|
<entry> </entry>
|
||||||
<entry>3</entry>
|
<entry>3</entry>
|
||||||
<entry>Block D.</entry>
|
<entry>Block D.</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry>V4L2_RDS_BLOCK_C_ALT</entry>
|
<entry>V4L2_RDS_BLOCK_C_ALT</entry>
|
||||||
|
<entry> </entry>
|
||||||
<entry>4</entry>
|
<entry>4</entry>
|
||||||
<entry>Block C'.</entry>
|
<entry>Block C'.</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry>V4L2_RDS_BLOCK_INVALID</entry>
|
<entry>V4L2_RDS_BLOCK_INVALID</entry>
|
||||||
|
<entry>read-only</entry>
|
||||||
<entry>7</entry>
|
<entry>7</entry>
|
||||||
<entry>An invalid block.</entry>
|
<entry>An invalid block.</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry>V4L2_RDS_BLOCK_CORRECTED</entry>
|
<entry>V4L2_RDS_BLOCK_CORRECTED</entry>
|
||||||
|
<entry>read-only</entry>
|
||||||
<entry>0x40</entry>
|
<entry>0x40</entry>
|
||||||
<entry>A bit error was detected but corrected.</entry>
|
<entry>A bit error was detected but corrected.</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry>V4L2_RDS_BLOCK_ERROR</entry>
|
<entry>V4L2_RDS_BLOCK_ERROR</entry>
|
||||||
|
<entry>read-only</entry>
|
||||||
<entry>0x80</entry>
|
<entry>0x80</entry>
|
||||||
<entry>An incorrectable error occurred.</entry>
|
<entry>An uncorrectable error occurred.</entry>
|
||||||
</row>
|
</row>
|
||||||
</tbody>
|
</tbody>
|
||||||
</tgroup>
|
</tgroup>
|
||||||
|
|
|
@ -1,35 +1,32 @@
|
||||||
<title>Teletext Interface</title>
|
<title>Teletext Interface</title>
|
||||||
|
|
||||||
<para>This interface aims at devices receiving and demodulating
|
<para>This interface was aimed at devices receiving and demodulating
|
||||||
Teletext data [<xref linkend="ets300706" />, <xref linkend="itu653" />], evaluating the
|
Teletext data [<xref linkend="ets300706" />, <xref linkend="itu653" />], evaluating the
|
||||||
Teletext packages and storing formatted pages in cache memory. Such
|
Teletext packages and storing formatted pages in cache memory. Such
|
||||||
devices are usually implemented as microcontrollers with serial
|
devices are usually implemented as microcontrollers with serial
|
||||||
interface (I<superscript>2</superscript>C) and can be found on older
|
interface (I<superscript>2</superscript>C) and could be found on old
|
||||||
TV cards, dedicated Teletext decoding cards and home-brew devices
|
TV cards, dedicated Teletext decoding cards and home-brew devices
|
||||||
connected to the PC parallel port.</para>
|
connected to the PC parallel port.</para>
|
||||||
|
|
||||||
<para>The Teletext API was designed by Martin Buck. It is defined in
|
<para>The Teletext API was designed by Martin Buck. It was defined in
|
||||||
the kernel header file <filename>linux/videotext.h</filename>, the
|
the kernel header file <filename>linux/videotext.h</filename>, the
|
||||||
specification is available from <ulink url="ftp://ftp.gwdg.de/pub/linux/misc/videotext/">
|
specification is available from <ulink url="ftp://ftp.gwdg.de/pub/linux/misc/videotext/">
|
||||||
ftp://ftp.gwdg.de/pub/linux/misc/videotext/</ulink>. (Videotext is the name of
|
ftp://ftp.gwdg.de/pub/linux/misc/videotext/</ulink>. (Videotext is the name of
|
||||||
the German public television Teletext service.) Conventional character
|
the German public television Teletext service.)</para>
|
||||||
device file names are <filename>/dev/vtx</filename> and
|
|
||||||
<filename>/dev/vttuner</filename>, with device number 83, 0 and 83, 16
|
|
||||||
respectively. A similar interface exists for the Philips SAA5249
|
|
||||||
Teletext decoder [specification?] with character device file names
|
|
||||||
<filename>/dev/tlkN</filename>, device number 102, N.</para>
|
|
||||||
|
|
||||||
<para>Eventually the Teletext API was integrated into the V4L API
|
<para>Eventually the Teletext API was integrated into the V4L API
|
||||||
with character device file names <filename>/dev/vtx0</filename> to
|
with character device file names <filename>/dev/vtx0</filename> to
|
||||||
<filename>/dev/vtx31</filename>, device major number 81, minor numbers
|
<filename>/dev/vtx31</filename>, device major number 81, minor numbers
|
||||||
192 to 223. For reference the V4L Teletext API specification is
|
192 to 223.</para>
|
||||||
reproduced here in full: "Teletext interfaces talk the existing VTX
|
|
||||||
API." Teletext devices with major number 83 and 102 will be removed in
|
|
||||||
Linux 2.6.</para>
|
|
||||||
|
|
||||||
<para>There are no plans to replace the Teletext API or to integrate
|
<para>However, teletext decoders were quickly replaced by more
|
||||||
it into V4L2. Please write to the linux-media mailing list: &v4l-ml;
|
generic VBI demodulators and those dedicated teletext decoders no longer exist.
|
||||||
when the need arises.</para>
|
For many years the vtx devices were still around, even though nobody used
|
||||||
|
them. So the decision was made to finally remove support for the Teletext API in
|
||||||
|
kernel 2.6.37.</para>
|
||||||
|
|
||||||
|
<para>Modern devices all use the <link linkend="raw-vbi">raw</link> or
|
||||||
|
<link linkend="sliced">sliced</link> VBI API.</para>
|
||||||
|
|
||||||
<!--
|
<!--
|
||||||
Local Variables:
|
Local Variables:
|
||||||
|
|
|
@ -739,7 +739,7 @@ defined in error. Drivers may interpret them as in <xref
|
||||||
<entry>b<subscript>1</subscript></entry>
|
<entry>b<subscript>1</subscript></entry>
|
||||||
<entry>b<subscript>0</subscript></entry>
|
<entry>b<subscript>0</subscript></entry>
|
||||||
</row>
|
</row>
|
||||||
<row id="V4L2-PIX-FMT-BGR666">
|
<row><!-- id="V4L2-PIX-FMT-BGR666" -->
|
||||||
<entry><constant>V4L2_PIX_FMT_BGR666</constant></entry>
|
<entry><constant>V4L2_PIX_FMT_BGR666</constant></entry>
|
||||||
<entry>'BGRH'</entry>
|
<entry>'BGRH'</entry>
|
||||||
<entry></entry>
|
<entry></entry>
|
||||||
|
|
90
Documentation/DocBook/v4l/pixfmt-srggb10.xml
Normal file
90
Documentation/DocBook/v4l/pixfmt-srggb10.xml
Normal file
|
@ -0,0 +1,90 @@
|
||||||
|
<refentry>
|
||||||
|
<refmeta>
|
||||||
|
<refentrytitle>V4L2_PIX_FMT_SRGGB10 ('RG10'),
|
||||||
|
V4L2_PIX_FMT_SGRBG10 ('BA10'),
|
||||||
|
V4L2_PIX_FMT_SGBRG10 ('GB10'),
|
||||||
|
V4L2_PIX_FMT_SBGGR10 ('BG10'),
|
||||||
|
</refentrytitle>
|
||||||
|
&manvol;
|
||||||
|
</refmeta>
|
||||||
|
<refnamediv>
|
||||||
|
<refname id="V4L2-PIX-FMT-SRGGB10"><constant>V4L2_PIX_FMT_SRGGB10</constant></refname>
|
||||||
|
<refname id="V4L2-PIX-FMT-SGRBG10"><constant>V4L2_PIX_FMT_SGRBG10</constant></refname>
|
||||||
|
<refname id="V4L2-PIX-FMT-SGBRG10"><constant>V4L2_PIX_FMT_SGBRG10</constant></refname>
|
||||||
|
<refname id="V4L2-PIX-FMT-SBGGR10"><constant>V4L2_PIX_FMT_SBGGR10</constant></refname>
|
||||||
|
<refpurpose>10-bit Bayer formats expanded to 16 bits</refpurpose>
|
||||||
|
</refnamediv>
|
||||||
|
<refsect1>
|
||||||
|
<title>Description</title>
|
||||||
|
|
||||||
|
<para>The following four pixel formats are raw sRGB / Bayer formats with
|
||||||
|
10 bits per colour. Each colour component is stored in a 16-bit word, with 6
|
||||||
|
unused high bits filled with zeros. Each n-pixel row contains n/2 green samples
|
||||||
|
and n/2 blue or red samples, with alternating red and blue rows. Bytes are
|
||||||
|
stored in memory in little endian order. They are conventionally described
|
||||||
|
as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an example of one of these
|
||||||
|
formats</para>
|
||||||
|
|
||||||
|
<example>
|
||||||
|
<title><constant>V4L2_PIX_FMT_SBGGR10</constant> 4 × 4
|
||||||
|
pixel image</title>
|
||||||
|
|
||||||
|
<formalpara>
|
||||||
|
<title>Byte Order.</title>
|
||||||
|
<para>Each cell is one byte, high 6 bits in high bytes are 0.
|
||||||
|
<informaltable frame="none">
|
||||||
|
<tgroup cols="5" align="center">
|
||||||
|
<colspec align="left" colwidth="2*" />
|
||||||
|
<tbody valign="top">
|
||||||
|
<row>
|
||||||
|
<entry>start + 0:</entry>
|
||||||
|
<entry>B<subscript>00low</subscript></entry>
|
||||||
|
<entry>B<subscript>00high</subscript></entry>
|
||||||
|
<entry>G<subscript>01low</subscript></entry>
|
||||||
|
<entry>G<subscript>01high</subscript></entry>
|
||||||
|
<entry>B<subscript>02low</subscript></entry>
|
||||||
|
<entry>B<subscript>02high</subscript></entry>
|
||||||
|
<entry>G<subscript>03low</subscript></entry>
|
||||||
|
<entry>G<subscript>03high</subscript></entry>
|
||||||
|
</row>
|
||||||
|
<row>
|
||||||
|
<entry>start + 8:</entry>
|
||||||
|
<entry>G<subscript>10low</subscript></entry>
|
||||||
|
<entry>G<subscript>10high</subscript></entry>
|
||||||
|
<entry>R<subscript>11low</subscript></entry>
|
||||||
|
<entry>R<subscript>11high</subscript></entry>
|
||||||
|
<entry>G<subscript>12low</subscript></entry>
|
||||||
|
<entry>G<subscript>12high</subscript></entry>
|
||||||
|
<entry>R<subscript>13low</subscript></entry>
|
||||||
|
<entry>R<subscript>13high</subscript></entry>
|
||||||
|
</row>
|
||||||
|
<row>
|
||||||
|
<entry>start + 16:</entry>
|
||||||
|
<entry>B<subscript>20low</subscript></entry>
|
||||||
|
<entry>B<subscript>20high</subscript></entry>
|
||||||
|
<entry>G<subscript>21low</subscript></entry>
|
||||||
|
<entry>G<subscript>21high</subscript></entry>
|
||||||
|
<entry>B<subscript>22low</subscript></entry>
|
||||||
|
<entry>B<subscript>22high</subscript></entry>
|
||||||
|
<entry>G<subscript>23low</subscript></entry>
|
||||||
|
<entry>G<subscript>23high</subscript></entry>
|
||||||
|
</row>
|
||||||
|
<row>
|
||||||
|
<entry>start + 24:</entry>
|
||||||
|
<entry>G<subscript>30low</subscript></entry>
|
||||||
|
<entry>G<subscript>30high</subscript></entry>
|
||||||
|
<entry>R<subscript>31low</subscript></entry>
|
||||||
|
<entry>R<subscript>31high</subscript></entry>
|
||||||
|
<entry>G<subscript>32low</subscript></entry>
|
||||||
|
<entry>G<subscript>32high</subscript></entry>
|
||||||
|
<entry>R<subscript>33low</subscript></entry>
|
||||||
|
<entry>R<subscript>33high</subscript></entry>
|
||||||
|
</row>
|
||||||
|
</tbody>
|
||||||
|
</tgroup>
|
||||||
|
</informaltable>
|
||||||
|
</para>
|
||||||
|
</formalpara>
|
||||||
|
</example>
|
||||||
|
</refsect1>
|
||||||
|
</refentry>
|
67
Documentation/DocBook/v4l/pixfmt-srggb8.xml
Normal file
67
Documentation/DocBook/v4l/pixfmt-srggb8.xml
Normal file
|
@ -0,0 +1,67 @@
|
||||||
|
<refentry id="V4L2-PIX-FMT-SRGGB8">
|
||||||
|
<refmeta>
|
||||||
|
<refentrytitle>V4L2_PIX_FMT_SRGGB8 ('RGGB')</refentrytitle>
|
||||||
|
&manvol;
|
||||||
|
</refmeta>
|
||||||
|
<refnamediv>
|
||||||
|
<refname><constant>V4L2_PIX_FMT_SRGGB8</constant></refname>
|
||||||
|
<refpurpose>Bayer RGB format</refpurpose>
|
||||||
|
</refnamediv>
|
||||||
|
<refsect1>
|
||||||
|
<title>Description</title>
|
||||||
|
|
||||||
|
<para>This is commonly the native format of digital cameras,
|
||||||
|
reflecting the arrangement of sensors on the CCD device. Only one red,
|
||||||
|
green or blue value is given for each pixel. Missing components must
|
||||||
|
be interpolated from neighbouring pixels. From left to right the first
|
||||||
|
row consists of a red and green value, the second row of a green and
|
||||||
|
blue value. This scheme repeats to the right and down for every two
|
||||||
|
columns and rows.</para>
|
||||||
|
|
||||||
|
<example>
|
||||||
|
<title><constant>V4L2_PIX_FMT_SRGGB8</constant> 4 × 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>start + 0:</entry>
|
||||||
|
<entry>R<subscript>00</subscript></entry>
|
||||||
|
<entry>G<subscript>01</subscript></entry>
|
||||||
|
<entry>R<subscript>02</subscript></entry>
|
||||||
|
<entry>G<subscript>03</subscript></entry>
|
||||||
|
</row>
|
||||||
|
<row>
|
||||||
|
<entry>start + 4:</entry>
|
||||||
|
<entry>G<subscript>10</subscript></entry>
|
||||||
|
<entry>B<subscript>11</subscript></entry>
|
||||||
|
<entry>G<subscript>12</subscript></entry>
|
||||||
|
<entry>B<subscript>13</subscript></entry>
|
||||||
|
</row>
|
||||||
|
<row>
|
||||||
|
<entry>start + 8:</entry>
|
||||||
|
<entry>R<subscript>20</subscript></entry>
|
||||||
|
<entry>G<subscript>21</subscript></entry>
|
||||||
|
<entry>R<subscript>22</subscript></entry>
|
||||||
|
<entry>G<subscript>23</subscript></entry>
|
||||||
|
</row>
|
||||||
|
<row>
|
||||||
|
<entry>start + 12:</entry>
|
||||||
|
<entry>G<subscript>30</subscript></entry>
|
||||||
|
<entry>B<subscript>31</subscript></entry>
|
||||||
|
<entry>G<subscript>32</subscript></entry>
|
||||||
|
<entry>B<subscript>33</subscript></entry>
|
||||||
|
</row>
|
||||||
|
</tbody>
|
||||||
|
</tgroup>
|
||||||
|
</informaltable>
|
||||||
|
</para>
|
||||||
|
</formalpara>
|
||||||
|
</example>
|
||||||
|
</refsect1>
|
||||||
|
</refentry>
|
79
Documentation/DocBook/v4l/pixfmt-y10.xml
Normal file
79
Documentation/DocBook/v4l/pixfmt-y10.xml
Normal file
|
@ -0,0 +1,79 @@
|
||||||
|
<refentry id="V4L2-PIX-FMT-Y10">
|
||||||
|
<refmeta>
|
||||||
|
<refentrytitle>V4L2_PIX_FMT_Y10 ('Y10 ')</refentrytitle>
|
||||||
|
&manvol;
|
||||||
|
</refmeta>
|
||||||
|
<refnamediv>
|
||||||
|
<refname><constant>V4L2_PIX_FMT_Y10</constant></refname>
|
||||||
|
<refpurpose>Grey-scale image</refpurpose>
|
||||||
|
</refnamediv>
|
||||||
|
<refsect1>
|
||||||
|
<title>Description</title>
|
||||||
|
|
||||||
|
<para>This is a grey-scale image with a depth of 10 bits per pixel. Pixels
|
||||||
|
are stored in 16-bit words with unused high bits padded with 0. The least
|
||||||
|
significant byte is stored at lower memory addresses (little-endian).</para>
|
||||||
|
|
||||||
|
<example>
|
||||||
|
<title><constant>V4L2_PIX_FMT_Y10</constant> 4 × 4
|
||||||
|
pixel image</title>
|
||||||
|
|
||||||
|
<formalpara>
|
||||||
|
<title>Byte Order.</title>
|
||||||
|
<para>Each cell is one byte.
|
||||||
|
<informaltable frame="none">
|
||||||
|
<tgroup cols="9" align="center">
|
||||||
|
<colspec align="left" colwidth="2*" />
|
||||||
|
<tbody valign="top">
|
||||||
|
<row>
|
||||||
|
<entry>start + 0:</entry>
|
||||||
|
<entry>Y'<subscript>00low</subscript></entry>
|
||||||
|
<entry>Y'<subscript>00high</subscript></entry>
|
||||||
|
<entry>Y'<subscript>01low</subscript></entry>
|
||||||
|
<entry>Y'<subscript>01high</subscript></entry>
|
||||||
|
<entry>Y'<subscript>02low</subscript></entry>
|
||||||
|
<entry>Y'<subscript>02high</subscript></entry>
|
||||||
|
<entry>Y'<subscript>03low</subscript></entry>
|
||||||
|
<entry>Y'<subscript>03high</subscript></entry>
|
||||||
|
</row>
|
||||||
|
<row>
|
||||||
|
<entry>start + 8:</entry>
|
||||||
|
<entry>Y'<subscript>10low</subscript></entry>
|
||||||
|
<entry>Y'<subscript>10high</subscript></entry>
|
||||||
|
<entry>Y'<subscript>11low</subscript></entry>
|
||||||
|
<entry>Y'<subscript>11high</subscript></entry>
|
||||||
|
<entry>Y'<subscript>12low</subscript></entry>
|
||||||
|
<entry>Y'<subscript>12high</subscript></entry>
|
||||||
|
<entry>Y'<subscript>13low</subscript></entry>
|
||||||
|
<entry>Y'<subscript>13high</subscript></entry>
|
||||||
|
</row>
|
||||||
|
<row>
|
||||||
|
<entry>start + 16:</entry>
|
||||||
|
<entry>Y'<subscript>20low</subscript></entry>
|
||||||
|
<entry>Y'<subscript>20high</subscript></entry>
|
||||||
|
<entry>Y'<subscript>21low</subscript></entry>
|
||||||
|
<entry>Y'<subscript>21high</subscript></entry>
|
||||||
|
<entry>Y'<subscript>22low</subscript></entry>
|
||||||
|
<entry>Y'<subscript>22high</subscript></entry>
|
||||||
|
<entry>Y'<subscript>23low</subscript></entry>
|
||||||
|
<entry>Y'<subscript>23high</subscript></entry>
|
||||||
|
</row>
|
||||||
|
<row>
|
||||||
|
<entry>start + 24:</entry>
|
||||||
|
<entry>Y'<subscript>30low</subscript></entry>
|
||||||
|
<entry>Y'<subscript>30high</subscript></entry>
|
||||||
|
<entry>Y'<subscript>31low</subscript></entry>
|
||||||
|
<entry>Y'<subscript>31high</subscript></entry>
|
||||||
|
<entry>Y'<subscript>32low</subscript></entry>
|
||||||
|
<entry>Y'<subscript>32high</subscript></entry>
|
||||||
|
<entry>Y'<subscript>33low</subscript></entry>
|
||||||
|
<entry>Y'<subscript>33high</subscript></entry>
|
||||||
|
</row>
|
||||||
|
</tbody>
|
||||||
|
</tgroup>
|
||||||
|
</informaltable>
|
||||||
|
</para>
|
||||||
|
</formalpara>
|
||||||
|
</example>
|
||||||
|
</refsect1>
|
||||||
|
</refentry>
|
|
@ -566,7 +566,9 @@ access the palette, this must be done with ioctls of the Linux framebuffer API.<
|
||||||
&sub-sbggr8;
|
&sub-sbggr8;
|
||||||
&sub-sgbrg8;
|
&sub-sgbrg8;
|
||||||
&sub-sgrbg8;
|
&sub-sgrbg8;
|
||||||
|
&sub-srggb8;
|
||||||
&sub-sbggr16;
|
&sub-sbggr16;
|
||||||
|
&sub-srggb10;
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section id="yuv-formats">
|
<section id="yuv-formats">
|
||||||
|
@ -589,6 +591,7 @@ information.</para>
|
||||||
|
|
||||||
&sub-packed-yuv;
|
&sub-packed-yuv;
|
||||||
&sub-grey;
|
&sub-grey;
|
||||||
|
&sub-y10;
|
||||||
&sub-y16;
|
&sub-y16;
|
||||||
&sub-yuyv;
|
&sub-yuyv;
|
||||||
&sub-uyvy;
|
&sub-uyvy;
|
||||||
|
@ -685,6 +688,11 @@ http://www.ivtvdriver.org/</ulink></para><para>The format is documented in the
|
||||||
kernel sources in the file <filename>Documentation/video4linux/cx2341x/README.hm12</filename>
|
kernel sources in the file <filename>Documentation/video4linux/cx2341x/README.hm12</filename>
|
||||||
</para></entry>
|
</para></entry>
|
||||||
</row>
|
</row>
|
||||||
|
<row id="V4L2-PIX-FMT-CPIA1">
|
||||||
|
<entry><constant>V4L2_PIX_FMT_CPIA1</constant></entry>
|
||||||
|
<entry>'CPIA'</entry>
|
||||||
|
<entry>YUV format used by the gspca cpia1 driver.</entry>
|
||||||
|
</row>
|
||||||
<row id="V4L2-PIX-FMT-SPCA501">
|
<row id="V4L2-PIX-FMT-SPCA501">
|
||||||
<entry><constant>V4L2_PIX_FMT_SPCA501</constant></entry>
|
<entry><constant>V4L2_PIX_FMT_SPCA501</constant></entry>
|
||||||
<entry>'S501'</entry>
|
<entry>'S501'</entry>
|
||||||
|
@ -705,11 +713,6 @@ kernel sources in the file <filename>Documentation/video4linux/cx2341x/README.hm
|
||||||
<entry>'S561'</entry>
|
<entry>'S561'</entry>
|
||||||
<entry>Compressed GBRG Bayer format used by the gspca driver.</entry>
|
<entry>Compressed GBRG Bayer format used by the gspca driver.</entry>
|
||||||
</row>
|
</row>
|
||||||
<row id="V4L2-PIX-FMT-SGRBG10">
|
|
||||||
<entry><constant>V4L2_PIX_FMT_SGRBG10</constant></entry>
|
|
||||||
<entry>'DA10'</entry>
|
|
||||||
<entry>10 bit raw Bayer, expanded to 16 bits.</entry>
|
|
||||||
</row>
|
|
||||||
<row id="V4L2-PIX-FMT-SGRBG10DPCM8">
|
<row id="V4L2-PIX-FMT-SGRBG10DPCM8">
|
||||||
<entry><constant>V4L2_PIX_FMT_SGRBG10DPCM8</constant></entry>
|
<entry><constant>V4L2_PIX_FMT_SGRBG10DPCM8</constant></entry>
|
||||||
<entry>'DB10'</entry>
|
<entry>'DB10'</entry>
|
||||||
|
@ -770,6 +773,11 @@ kernel sources in the file <filename>Documentation/video4linux/cx2341x/README.hm
|
||||||
<entry>'S920'</entry>
|
<entry>'S920'</entry>
|
||||||
<entry>YUV 4:2:0 format of the gspca sn9c20x driver.</entry>
|
<entry>YUV 4:2:0 format of the gspca sn9c20x driver.</entry>
|
||||||
</row>
|
</row>
|
||||||
|
<row id="V4L2-PIX-FMT-SN9C2028">
|
||||||
|
<entry><constant>V4L2_PIX_FMT_SN9C2028</constant></entry>
|
||||||
|
<entry>'SONX'</entry>
|
||||||
|
<entry>Compressed GBRG bayer format of the gspca sn9c2028 driver.</entry>
|
||||||
|
</row>
|
||||||
<row id="V4L2-PIX-FMT-STV0680">
|
<row id="V4L2-PIX-FMT-STV0680">
|
||||||
<entry><constant>V4L2_PIX_FMT_STV0680</constant></entry>
|
<entry><constant>V4L2_PIX_FMT_STV0680</constant></entry>
|
||||||
<entry>'S680'</entry>
|
<entry>'S680'</entry>
|
||||||
|
@ -787,6 +795,20 @@ http://www.thedirks.org/winnov/</ulink></para></entry>
|
||||||
<entry>'TM60'</entry>
|
<entry>'TM60'</entry>
|
||||||
<entry><para>Used by Trident tm6000</para></entry>
|
<entry><para>Used by Trident tm6000</para></entry>
|
||||||
</row>
|
</row>
|
||||||
|
<row id="V4L2-PIX-FMT-CIT-YYVYUY">
|
||||||
|
<entry><constant>V4L2_PIX_FMT_CIT_YYVYUY</constant></entry>
|
||||||
|
<entry>'CITV'</entry>
|
||||||
|
<entry><para>Used by xirlink CIT, found at IBM webcams.</para>
|
||||||
|
<para>Uses one line of Y then 1 line of VYUY</para>
|
||||||
|
</entry>
|
||||||
|
</row>
|
||||||
|
<row id="V4L2-PIX-FMT-KONICA420">
|
||||||
|
<entry><constant>V4L2_PIX_FMT_KONICA420</constant></entry>
|
||||||
|
<entry>'KONI'</entry>
|
||||||
|
<entry><para>Used by Konica webcams.</para>
|
||||||
|
<para>YUV420 planar in blocks of 256 pixels.</para>
|
||||||
|
</entry>
|
||||||
|
</row>
|
||||||
<row id="V4L2-PIX-FMT-YYUV">
|
<row id="V4L2-PIX-FMT-YYUV">
|
||||||
<entry><constant>V4L2_PIX_FMT_YYUV</constant></entry>
|
<entry><constant>V4L2_PIX_FMT_YYUV</constant></entry>
|
||||||
<entry>'YYUV'</entry>
|
<entry>'YYUV'</entry>
|
||||||
|
|
|
@ -99,6 +99,7 @@ Remote Controller chapter.</contrib>
|
||||||
<year>2007</year>
|
<year>2007</year>
|
||||||
<year>2008</year>
|
<year>2008</year>
|
||||||
<year>2009</year>
|
<year>2009</year>
|
||||||
|
<year>2010</year>
|
||||||
<holder>Bill Dirks, Michael H. Schimek, Hans Verkuil, Martin
|
<holder>Bill Dirks, Michael H. Schimek, Hans Verkuil, Martin
|
||||||
Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab</holder>
|
Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab</holder>
|
||||||
</copyright>
|
</copyright>
|
||||||
|
@ -110,9 +111,16 @@ Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab</holder>
|
||||||
<!-- Put document revisions here, newest first. -->
|
<!-- Put document revisions here, newest first. -->
|
||||||
<!-- API revisions (changes and additions of defines, enums,
|
<!-- API revisions (changes and additions of defines, enums,
|
||||||
structs, ioctls) must be noted in more detail in the history chapter
|
structs, ioctls) must be noted in more detail in the history chapter
|
||||||
(compat.sgml), along with the possible impact on existing drivers and
|
(compat.xml), along with the possible impact on existing drivers and
|
||||||
applications. -->
|
applications. -->
|
||||||
|
|
||||||
|
<revision>
|
||||||
|
<revnumber>2.6.37</revnumber>
|
||||||
|
<date>2010-08-06</date>
|
||||||
|
<authorinitials>hv</authorinitials>
|
||||||
|
<revremark>Removed obsolete vtx (videotext) API.</revremark>
|
||||||
|
</revision>
|
||||||
|
|
||||||
<revision>
|
<revision>
|
||||||
<revnumber>2.6.33</revnumber>
|
<revnumber>2.6.33</revnumber>
|
||||||
<date>2009-12-03</date>
|
<date>2009-12-03</date>
|
||||||
|
|
|
@ -154,23 +154,13 @@ enum <link linkend="v4l2-buf-type">v4l2_buf_type</link> {
|
||||||
V4L2_BUF_TYPE_VBI_OUTPUT = 5,
|
V4L2_BUF_TYPE_VBI_OUTPUT = 5,
|
||||||
V4L2_BUF_TYPE_SLICED_VBI_CAPTURE = 6,
|
V4L2_BUF_TYPE_SLICED_VBI_CAPTURE = 6,
|
||||||
V4L2_BUF_TYPE_SLICED_VBI_OUTPUT = 7,
|
V4L2_BUF_TYPE_SLICED_VBI_OUTPUT = 7,
|
||||||
#if 1 /*KEEP*/
|
#if 1
|
||||||
/* Experimental */
|
/* Experimental */
|
||||||
V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY = 8,
|
V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY = 8,
|
||||||
#endif
|
#endif
|
||||||
V4L2_BUF_TYPE_PRIVATE = 0x80,
|
V4L2_BUF_TYPE_PRIVATE = 0x80,
|
||||||
};
|
};
|
||||||
|
|
||||||
enum <link linkend="v4l2-ctrl-type">v4l2_ctrl_type</link> {
|
|
||||||
V4L2_CTRL_TYPE_INTEGER = 1,
|
|
||||||
V4L2_CTRL_TYPE_BOOLEAN = 2,
|
|
||||||
V4L2_CTRL_TYPE_MENU = 3,
|
|
||||||
V4L2_CTRL_TYPE_BUTTON = 4,
|
|
||||||
V4L2_CTRL_TYPE_INTEGER64 = 5,
|
|
||||||
V4L2_CTRL_TYPE_CTRL_CLASS = 6,
|
|
||||||
V4L2_CTRL_TYPE_STRING = 7,
|
|
||||||
};
|
|
||||||
|
|
||||||
enum <link linkend="v4l2-tuner-type">v4l2_tuner_type</link> {
|
enum <link linkend="v4l2-tuner-type">v4l2_tuner_type</link> {
|
||||||
V4L2_TUNER_RADIO = 1,
|
V4L2_TUNER_RADIO = 1,
|
||||||
V4L2_TUNER_ANALOG_TV = 2,
|
V4L2_TUNER_ANALOG_TV = 2,
|
||||||
|
@ -288,6 +278,7 @@ struct <link linkend="v4l2-pix-format">v4l2_pix_format</link> {
|
||||||
#define <link linkend="V4L2-PIX-FMT-RGB565">V4L2_PIX_FMT_RGB565</link> v4l2_fourcc('R', 'G', 'B', 'P') /* 16 RGB-5-6-5 */
|
#define <link linkend="V4L2-PIX-FMT-RGB565">V4L2_PIX_FMT_RGB565</link> v4l2_fourcc('R', 'G', 'B', 'P') /* 16 RGB-5-6-5 */
|
||||||
#define <link linkend="V4L2-PIX-FMT-RGB555X">V4L2_PIX_FMT_RGB555X</link> v4l2_fourcc('R', 'G', 'B', 'Q') /* 16 RGB-5-5-5 BE */
|
#define <link linkend="V4L2-PIX-FMT-RGB555X">V4L2_PIX_FMT_RGB555X</link> v4l2_fourcc('R', 'G', 'B', 'Q') /* 16 RGB-5-5-5 BE */
|
||||||
#define <link linkend="V4L2-PIX-FMT-RGB565X">V4L2_PIX_FMT_RGB565X</link> v4l2_fourcc('R', 'G', 'B', 'R') /* 16 RGB-5-6-5 BE */
|
#define <link linkend="V4L2-PIX-FMT-RGB565X">V4L2_PIX_FMT_RGB565X</link> v4l2_fourcc('R', 'G', 'B', 'R') /* 16 RGB-5-6-5 BE */
|
||||||
|
#define <link linkend="V4L2-PIX-FMT-BGR666">V4L2_PIX_FMT_BGR666</link> v4l2_fourcc('B', 'G', 'R', 'H') /* 18 BGR-6-6-6 */
|
||||||
#define <link linkend="V4L2-PIX-FMT-BGR24">V4L2_PIX_FMT_BGR24</link> v4l2_fourcc('B', 'G', 'R', '3') /* 24 BGR-8-8-8 */
|
#define <link linkend="V4L2-PIX-FMT-BGR24">V4L2_PIX_FMT_BGR24</link> v4l2_fourcc('B', 'G', 'R', '3') /* 24 BGR-8-8-8 */
|
||||||
#define <link linkend="V4L2-PIX-FMT-RGB24">V4L2_PIX_FMT_RGB24</link> v4l2_fourcc('R', 'G', 'B', '3') /* 24 RGB-8-8-8 */
|
#define <link linkend="V4L2-PIX-FMT-RGB24">V4L2_PIX_FMT_RGB24</link> v4l2_fourcc('R', 'G', 'B', '3') /* 24 RGB-8-8-8 */
|
||||||
#define <link linkend="V4L2-PIX-FMT-BGR32">V4L2_PIX_FMT_BGR32</link> v4l2_fourcc('B', 'G', 'R', '4') /* 32 BGR-8-8-8-8 */
|
#define <link linkend="V4L2-PIX-FMT-BGR32">V4L2_PIX_FMT_BGR32</link> v4l2_fourcc('B', 'G', 'R', '4') /* 32 BGR-8-8-8-8 */
|
||||||
|
@ -295,6 +286,9 @@ struct <link linkend="v4l2-pix-format">v4l2_pix_format</link> {
|
||||||
|
|
||||||
/* Grey formats */
|
/* Grey formats */
|
||||||
#define <link linkend="V4L2-PIX-FMT-GREY">V4L2_PIX_FMT_GREY</link> v4l2_fourcc('G', 'R', 'E', 'Y') /* 8 Greyscale */
|
#define <link linkend="V4L2-PIX-FMT-GREY">V4L2_PIX_FMT_GREY</link> v4l2_fourcc('G', 'R', 'E', 'Y') /* 8 Greyscale */
|
||||||
|
#define <link linkend="V4L2-PIX-FMT-Y4">V4L2_PIX_FMT_Y4</link> v4l2_fourcc('Y', '0', '4', ' ') /* 4 Greyscale */
|
||||||
|
#define <link linkend="V4L2-PIX-FMT-Y6">V4L2_PIX_FMT_Y6</link> v4l2_fourcc('Y', '0', '6', ' ') /* 6 Greyscale */
|
||||||
|
#define <link linkend="V4L2-PIX-FMT-Y10">V4L2_PIX_FMT_Y10</link> v4l2_fourcc('Y', '1', '0', ' ') /* 10 Greyscale */
|
||||||
#define <link linkend="V4L2-PIX-FMT-Y16">V4L2_PIX_FMT_Y16</link> v4l2_fourcc('Y', '1', '6', ' ') /* 16 Greyscale */
|
#define <link linkend="V4L2-PIX-FMT-Y16">V4L2_PIX_FMT_Y16</link> v4l2_fourcc('Y', '1', '6', ' ') /* 16 Greyscale */
|
||||||
|
|
||||||
/* Palette formats */
|
/* Palette formats */
|
||||||
|
@ -330,7 +324,11 @@ struct <link linkend="v4l2-pix-format">v4l2_pix_format</link> {
|
||||||
#define <link linkend="V4L2-PIX-FMT-SBGGR8">V4L2_PIX_FMT_SBGGR8</link> v4l2_fourcc('B', 'A', '8', '1') /* 8 BGBG.. GRGR.. */
|
#define <link linkend="V4L2-PIX-FMT-SBGGR8">V4L2_PIX_FMT_SBGGR8</link> v4l2_fourcc('B', 'A', '8', '1') /* 8 BGBG.. GRGR.. */
|
||||||
#define <link linkend="V4L2-PIX-FMT-SGBRG8">V4L2_PIX_FMT_SGBRG8</link> v4l2_fourcc('G', 'B', 'R', 'G') /* 8 GBGB.. RGRG.. */
|
#define <link linkend="V4L2-PIX-FMT-SGBRG8">V4L2_PIX_FMT_SGBRG8</link> v4l2_fourcc('G', 'B', 'R', 'G') /* 8 GBGB.. RGRG.. */
|
||||||
#define <link linkend="V4L2-PIX-FMT-SGRBG8">V4L2_PIX_FMT_SGRBG8</link> v4l2_fourcc('G', 'R', 'B', 'G') /* 8 GRGR.. BGBG.. */
|
#define <link linkend="V4L2-PIX-FMT-SGRBG8">V4L2_PIX_FMT_SGRBG8</link> v4l2_fourcc('G', 'R', 'B', 'G') /* 8 GRGR.. BGBG.. */
|
||||||
#define <link linkend="V4L2-PIX-FMT-SGRBG10">V4L2_PIX_FMT_SGRBG10</link> v4l2_fourcc('B', 'A', '1', '0') /* 10bit raw bayer */
|
#define <link linkend="V4L2-PIX-FMT-SRGGB8">V4L2_PIX_FMT_SRGGB8</link> v4l2_fourcc('R', 'G', 'G', 'B') /* 8 RGRG.. GBGB.. */
|
||||||
|
#define <link linkend="V4L2-PIX-FMT-SBGGR10">V4L2_PIX_FMT_SBGGR10</link> v4l2_fourcc('B', 'G', '1', '0') /* 10 BGBG.. GRGR.. */
|
||||||
|
#define <link linkend="V4L2-PIX-FMT-SGBRG10">V4L2_PIX_FMT_SGBRG10</link> v4l2_fourcc('G', 'B', '1', '0') /* 10 GBGB.. RGRG.. */
|
||||||
|
#define <link linkend="V4L2-PIX-FMT-SGRBG10">V4L2_PIX_FMT_SGRBG10</link> v4l2_fourcc('B', 'A', '1', '0') /* 10 GRGR.. BGBG.. */
|
||||||
|
#define <link linkend="V4L2-PIX-FMT-SRGGB10">V4L2_PIX_FMT_SRGGB10</link> v4l2_fourcc('R', 'G', '1', '0') /* 10 RGRG.. GBGB.. */
|
||||||
/* 10bit raw bayer DPCM compressed to 8 bits */
|
/* 10bit raw bayer DPCM compressed to 8 bits */
|
||||||
#define <link linkend="V4L2-PIX-FMT-SGRBG10DPCM8">V4L2_PIX_FMT_SGRBG10DPCM8</link> v4l2_fourcc('B', 'D', '1', '0')
|
#define <link linkend="V4L2-PIX-FMT-SGRBG10DPCM8">V4L2_PIX_FMT_SGRBG10DPCM8</link> v4l2_fourcc('B', 'D', '1', '0')
|
||||||
/*
|
/*
|
||||||
|
@ -346,6 +344,7 @@ struct <link linkend="v4l2-pix-format">v4l2_pix_format</link> {
|
||||||
#define <link linkend="V4L2-PIX-FMT-MPEG">V4L2_PIX_FMT_MPEG</link> v4l2_fourcc('M', 'P', 'E', 'G') /* MPEG-1/2/4 */
|
#define <link linkend="V4L2-PIX-FMT-MPEG">V4L2_PIX_FMT_MPEG</link> v4l2_fourcc('M', 'P', 'E', 'G') /* MPEG-1/2/4 */
|
||||||
|
|
||||||
/* Vendor-specific formats */
|
/* Vendor-specific formats */
|
||||||
|
#define <link linkend="V4L2-PIX-FMT-CPIA1">V4L2_PIX_FMT_CPIA1</link> v4l2_fourcc('C', 'P', 'I', 'A') /* cpia1 YUV */
|
||||||
#define <link linkend="V4L2-PIX-FMT-WNVA">V4L2_PIX_FMT_WNVA</link> v4l2_fourcc('W', 'N', 'V', 'A') /* Winnov hw compress */
|
#define <link linkend="V4L2-PIX-FMT-WNVA">V4L2_PIX_FMT_WNVA</link> v4l2_fourcc('W', 'N', 'V', 'A') /* Winnov hw compress */
|
||||||
#define <link linkend="V4L2-PIX-FMT-SN9C10X">V4L2_PIX_FMT_SN9C10X</link> v4l2_fourcc('S', '9', '1', '0') /* SN9C10x compression */
|
#define <link linkend="V4L2-PIX-FMT-SN9C10X">V4L2_PIX_FMT_SN9C10X</link> v4l2_fourcc('S', '9', '1', '0') /* SN9C10x compression */
|
||||||
#define <link linkend="V4L2-PIX-FMT-SN9C20X-I420">V4L2_PIX_FMT_SN9C20X_I420</link> v4l2_fourcc('S', '9', '2', '0') /* SN9C20x YUV 4:2:0 */
|
#define <link linkend="V4L2-PIX-FMT-SN9C20X-I420">V4L2_PIX_FMT_SN9C20X_I420</link> v4l2_fourcc('S', '9', '2', '0') /* SN9C20x YUV 4:2:0 */
|
||||||
|
@ -358,12 +357,15 @@ struct <link linkend="v4l2-pix-format">v4l2_pix_format</link> {
|
||||||
#define <link linkend="V4L2-PIX-FMT-SPCA561">V4L2_PIX_FMT_SPCA561</link> v4l2_fourcc('S', '5', '6', '1') /* compressed GBRG bayer */
|
#define <link linkend="V4L2-PIX-FMT-SPCA561">V4L2_PIX_FMT_SPCA561</link> v4l2_fourcc('S', '5', '6', '1') /* compressed GBRG bayer */
|
||||||
#define <link linkend="V4L2-PIX-FMT-PAC207">V4L2_PIX_FMT_PAC207</link> v4l2_fourcc('P', '2', '0', '7') /* compressed BGGR bayer */
|
#define <link linkend="V4L2-PIX-FMT-PAC207">V4L2_PIX_FMT_PAC207</link> v4l2_fourcc('P', '2', '0', '7') /* compressed BGGR bayer */
|
||||||
#define <link linkend="V4L2-PIX-FMT-MR97310A">V4L2_PIX_FMT_MR97310A</link> v4l2_fourcc('M', '3', '1', '0') /* compressed BGGR bayer */
|
#define <link linkend="V4L2-PIX-FMT-MR97310A">V4L2_PIX_FMT_MR97310A</link> v4l2_fourcc('M', '3', '1', '0') /* compressed BGGR bayer */
|
||||||
|
#define <link linkend="V4L2-PIX-FMT-SN9C2028">V4L2_PIX_FMT_SN9C2028</link> v4l2_fourcc('S', 'O', 'N', 'X') /* compressed GBRG bayer */
|
||||||
#define <link linkend="V4L2-PIX-FMT-SQ905C">V4L2_PIX_FMT_SQ905C</link> v4l2_fourcc('9', '0', '5', 'C') /* compressed RGGB bayer */
|
#define <link linkend="V4L2-PIX-FMT-SQ905C">V4L2_PIX_FMT_SQ905C</link> v4l2_fourcc('9', '0', '5', 'C') /* compressed RGGB bayer */
|
||||||
#define <link linkend="V4L2-PIX-FMT-PJPG">V4L2_PIX_FMT_PJPG</link> v4l2_fourcc('P', 'J', 'P', 'G') /* Pixart 73xx JPEG */
|
#define <link linkend="V4L2-PIX-FMT-PJPG">V4L2_PIX_FMT_PJPG</link> v4l2_fourcc('P', 'J', 'P', 'G') /* Pixart 73xx JPEG */
|
||||||
#define <link linkend="V4L2-PIX-FMT-OV511">V4L2_PIX_FMT_OV511</link> v4l2_fourcc('O', '5', '1', '1') /* ov511 JPEG */
|
#define <link linkend="V4L2-PIX-FMT-OV511">V4L2_PIX_FMT_OV511</link> v4l2_fourcc('O', '5', '1', '1') /* ov511 JPEG */
|
||||||
#define <link linkend="V4L2-PIX-FMT-OV518">V4L2_PIX_FMT_OV518</link> v4l2_fourcc('O', '5', '1', '8') /* ov518 JPEG */
|
#define <link linkend="V4L2-PIX-FMT-OV518">V4L2_PIX_FMT_OV518</link> v4l2_fourcc('O', '5', '1', '8') /* ov518 JPEG */
|
||||||
#define <link linkend="V4L2-PIX-FMT-TM6000">V4L2_PIX_FMT_TM6000</link> v4l2_fourcc('T', 'M', '6', '0') /* tm5600/tm60x0 */
|
|
||||||
#define <link linkend="V4L2-PIX-FMT-STV0680">V4L2_PIX_FMT_STV0680</link> v4l2_fourcc('S', '6', '8', '0') /* stv0680 bayer */
|
#define <link linkend="V4L2-PIX-FMT-STV0680">V4L2_PIX_FMT_STV0680</link> v4l2_fourcc('S', '6', '8', '0') /* stv0680 bayer */
|
||||||
|
#define <link linkend="V4L2-PIX-FMT-TM6000">V4L2_PIX_FMT_TM6000</link> v4l2_fourcc('T', 'M', '6', '0') /* tm5600/tm60x0 */
|
||||||
|
#define <link linkend="V4L2-PIX-FMT-CIT-YYVYUY">V4L2_PIX_FMT_CIT_YYVYUY</link> v4l2_fourcc('C', 'I', 'T', 'V') /* one line of Y then 1 line of VYUY */
|
||||||
|
#define <link linkend="V4L2-PIX-FMT-KONICA420">V4L2_PIX_FMT_KONICA420</link> v4l2_fourcc('K', 'O', 'N', 'I') /* YUV420 planar in blocks of 256 pixels */
|
||||||
|
|
||||||
/*
|
/*
|
||||||
* F O R M A T E N U M E R A T I O N
|
* F O R M A T E N U M E R A T I O N
|
||||||
|
@ -380,7 +382,7 @@ struct <link linkend="v4l2-fmtdesc">v4l2_fmtdesc</link> {
|
||||||
#define V4L2_FMT_FLAG_COMPRESSED 0x0001
|
#define V4L2_FMT_FLAG_COMPRESSED 0x0001
|
||||||
#define V4L2_FMT_FLAG_EMULATED 0x0002
|
#define V4L2_FMT_FLAG_EMULATED 0x0002
|
||||||
|
|
||||||
#if 1 /*KEEP*/
|
#if 1
|
||||||
/* Experimental Frame Size and frame rate enumeration */
|
/* Experimental Frame Size and frame rate enumeration */
|
||||||
/*
|
/*
|
||||||
* F R A M E S I Z E E N U M E R A T I O N
|
* F R A M E S I Z E E N U M E R A T I O N
|
||||||
|
@ -544,6 +546,8 @@ struct <link linkend="v4l2-buffer">v4l2_buffer</link> {
|
||||||
#define V4L2_BUF_FLAG_KEYFRAME 0x0008 /* Image is a keyframe (I-frame) */
|
#define V4L2_BUF_FLAG_KEYFRAME 0x0008 /* Image is a keyframe (I-frame) */
|
||||||
#define V4L2_BUF_FLAG_PFRAME 0x0010 /* Image is a P-frame */
|
#define V4L2_BUF_FLAG_PFRAME 0x0010 /* Image is a P-frame */
|
||||||
#define V4L2_BUF_FLAG_BFRAME 0x0020 /* Image is a B-frame */
|
#define V4L2_BUF_FLAG_BFRAME 0x0020 /* Image is a B-frame */
|
||||||
|
/* Buffer is ready, but the data contained within is corrupted. */
|
||||||
|
#define V4L2_BUF_FLAG_ERROR 0x0040
|
||||||
#define V4L2_BUF_FLAG_TIMECODE 0x0100 /* timecode field is valid */
|
#define V4L2_BUF_FLAG_TIMECODE 0x0100 /* timecode field is valid */
|
||||||
#define V4L2_BUF_FLAG_INPUT 0x0200 /* input field is valid */
|
#define V4L2_BUF_FLAG_INPUT 0x0200 /* input field is valid */
|
||||||
|
|
||||||
|
@ -934,6 +938,16 @@ struct <link linkend="v4l2-ext-controls">v4l2_ext_controls</link> {
|
||||||
#define V4L2_CTRL_ID2CLASS(id) ((id) & 0x0fff0000UL)
|
#define V4L2_CTRL_ID2CLASS(id) ((id) & 0x0fff0000UL)
|
||||||
#define V4L2_CTRL_DRIVER_PRIV(id) (((id) & 0xffff) >= 0x1000)
|
#define V4L2_CTRL_DRIVER_PRIV(id) (((id) & 0xffff) >= 0x1000)
|
||||||
|
|
||||||
|
enum <link linkend="v4l2-ctrl-type">v4l2_ctrl_type</link> {
|
||||||
|
V4L2_CTRL_TYPE_INTEGER = 1,
|
||||||
|
V4L2_CTRL_TYPE_BOOLEAN = 2,
|
||||||
|
V4L2_CTRL_TYPE_MENU = 3,
|
||||||
|
V4L2_CTRL_TYPE_BUTTON = 4,
|
||||||
|
V4L2_CTRL_TYPE_INTEGER64 = 5,
|
||||||
|
V4L2_CTRL_TYPE_CTRL_CLASS = 6,
|
||||||
|
V4L2_CTRL_TYPE_STRING = 7,
|
||||||
|
};
|
||||||
|
|
||||||
/* Used in the VIDIOC_QUERYCTRL ioctl for querying controls */
|
/* Used in the VIDIOC_QUERYCTRL ioctl for querying controls */
|
||||||
struct <link linkend="v4l2-queryctrl">v4l2_queryctrl</link> {
|
struct <link linkend="v4l2-queryctrl">v4l2_queryctrl</link> {
|
||||||
__u32 id;
|
__u32 id;
|
||||||
|
@ -1018,21 +1032,27 @@ enum <link linkend="v4l2-colorfx">v4l2_colorfx</link> {
|
||||||
V4L2_COLORFX_NONE = 0,
|
V4L2_COLORFX_NONE = 0,
|
||||||
V4L2_COLORFX_BW = 1,
|
V4L2_COLORFX_BW = 1,
|
||||||
V4L2_COLORFX_SEPIA = 2,
|
V4L2_COLORFX_SEPIA = 2,
|
||||||
V4L2_COLORFX_NEGATIVE = 3,
|
V4L2_COLORFX_NEGATIVE = 3,
|
||||||
V4L2_COLORFX_EMBOSS = 4,
|
V4L2_COLORFX_EMBOSS = 4,
|
||||||
V4L2_COLORFX_SKETCH = 5,
|
V4L2_COLORFX_SKETCH = 5,
|
||||||
V4L2_COLORFX_SKY_BLUE = 6,
|
V4L2_COLORFX_SKY_BLUE = 6,
|
||||||
V4L2_COLORFX_GRASS_GREEN = 7,
|
V4L2_COLORFX_GRASS_GREEN = 7,
|
||||||
V4L2_COLORFX_SKIN_WHITEN = 8,
|
V4L2_COLORFX_SKIN_WHITEN = 8,
|
||||||
V4L2_COLORFX_VIVID = 9.
|
V4L2_COLORFX_VIVID = 9,
|
||||||
};
|
};
|
||||||
#define V4L2_CID_AUTOBRIGHTNESS (V4L2_CID_BASE+32)
|
#define V4L2_CID_AUTOBRIGHTNESS (V4L2_CID_BASE+32)
|
||||||
#define V4L2_CID_BAND_STOP_FILTER (V4L2_CID_BASE+33)
|
#define V4L2_CID_BAND_STOP_FILTER (V4L2_CID_BASE+33)
|
||||||
|
|
||||||
#define V4L2_CID_ROTATE (V4L2_CID_BASE+34)
|
#define V4L2_CID_ROTATE (V4L2_CID_BASE+34)
|
||||||
#define V4L2_CID_BG_COLOR (V4L2_CID_BASE+35)
|
#define V4L2_CID_BG_COLOR (V4L2_CID_BASE+35)
|
||||||
|
|
||||||
|
#define V4L2_CID_CHROMA_GAIN (V4L2_CID_BASE+36)
|
||||||
|
|
||||||
|
#define V4L2_CID_ILLUMINATORS_1 (V4L2_CID_BASE+37)
|
||||||
|
#define V4L2_CID_ILLUMINATORS_2 (V4L2_CID_BASE+38)
|
||||||
|
|
||||||
/* last CID + 1 */
|
/* last CID + 1 */
|
||||||
#define V4L2_CID_LASTP1 (V4L2_CID_BASE+36)
|
#define V4L2_CID_LASTP1 (V4L2_CID_BASE+39)
|
||||||
|
|
||||||
/* MPEG-class control IDs defined by V4L2 */
|
/* MPEG-class control IDs defined by V4L2 */
|
||||||
#define V4L2_CID_MPEG_BASE (V4L2_CTRL_CLASS_MPEG | 0x900)
|
#define V4L2_CID_MPEG_BASE (V4L2_CTRL_CLASS_MPEG | 0x900)
|
||||||
|
@ -1349,6 +1369,8 @@ struct <link linkend="v4l2-modulator">v4l2_modulator</link> {
|
||||||
#define V4L2_TUNER_CAP_SAP 0x0020
|
#define V4L2_TUNER_CAP_SAP 0x0020
|
||||||
#define V4L2_TUNER_CAP_LANG1 0x0040
|
#define V4L2_TUNER_CAP_LANG1 0x0040
|
||||||
#define V4L2_TUNER_CAP_RDS 0x0080
|
#define V4L2_TUNER_CAP_RDS 0x0080
|
||||||
|
#define V4L2_TUNER_CAP_RDS_BLOCK_IO 0x0100
|
||||||
|
#define V4L2_TUNER_CAP_RDS_CONTROLS 0x0200
|
||||||
|
|
||||||
/* Flags for the 'rxsubchans' field */
|
/* Flags for the 'rxsubchans' field */
|
||||||
#define V4L2_TUNER_SUB_MONO 0x0001
|
#define V4L2_TUNER_SUB_MONO 0x0001
|
||||||
|
@ -1378,7 +1400,8 @@ struct <link linkend="v4l2-hw-freq-seek">v4l2_hw_freq_seek</link> {
|
||||||
enum <link linkend="v4l2-tuner-type">v4l2_tuner_type</link> type;
|
enum <link linkend="v4l2-tuner-type">v4l2_tuner_type</link> type;
|
||||||
__u32 seek_upward;
|
__u32 seek_upward;
|
||||||
__u32 wrap_around;
|
__u32 wrap_around;
|
||||||
__u32 reserved[8];
|
__u32 spacing;
|
||||||
|
__u32 reserved[7];
|
||||||
};
|
};
|
||||||
|
|
||||||
/*
|
/*
|
||||||
|
@ -1433,7 +1456,7 @@ struct <link linkend="v4l2-audioout">v4l2_audioout</link> {
|
||||||
*
|
*
|
||||||
* NOTE: EXPERIMENTAL API
|
* NOTE: EXPERIMENTAL API
|
||||||
*/
|
*/
|
||||||
#if 1 /*KEEP*/
|
#if 1
|
||||||
#define V4L2_ENC_IDX_FRAME_I (0)
|
#define V4L2_ENC_IDX_FRAME_I (0)
|
||||||
#define V4L2_ENC_IDX_FRAME_P (1)
|
#define V4L2_ENC_IDX_FRAME_P (1)
|
||||||
#define V4L2_ENC_IDX_FRAME_B (2)
|
#define V4L2_ENC_IDX_FRAME_B (2)
|
||||||
|
@ -1625,6 +1648,38 @@ struct <link linkend="v4l2-streamparm">v4l2_streamparm</link> {
|
||||||
} parm;
|
} parm;
|
||||||
};
|
};
|
||||||
|
|
||||||
|
/*
|
||||||
|
* E V E N T S
|
||||||
|
*/
|
||||||
|
|
||||||
|
#define V4L2_EVENT_ALL 0
|
||||||
|
#define V4L2_EVENT_VSYNC 1
|
||||||
|
#define V4L2_EVENT_EOS 2
|
||||||
|
#define V4L2_EVENT_PRIVATE_START 0x08000000
|
||||||
|
|
||||||
|
/* Payload for V4L2_EVENT_VSYNC */
|
||||||
|
struct <link linkend="v4l2-event-vsync">v4l2_event_vsync</link> {
|
||||||
|
/* Can be V4L2_FIELD_ANY, _NONE, _TOP or _BOTTOM */
|
||||||
|
__u8 field;
|
||||||
|
} __attribute__ ((packed));
|
||||||
|
|
||||||
|
struct <link linkend="v4l2-event">v4l2_event</link> {
|
||||||
|
__u32 type;
|
||||||
|
union {
|
||||||
|
struct <link linkend="v4l2-event-vsync">v4l2_event_vsync</link> vsync;
|
||||||
|
__u8 data[64];
|
||||||
|
} u;
|
||||||
|
__u32 pending;
|
||||||
|
__u32 sequence;
|
||||||
|
struct timespec timestamp;
|
||||||
|
__u32 reserved[9];
|
||||||
|
};
|
||||||
|
|
||||||
|
struct <link linkend="v4l2-event-subscription">v4l2_event_subscription</link> {
|
||||||
|
__u32 type;
|
||||||
|
__u32 reserved[7];
|
||||||
|
};
|
||||||
|
|
||||||
/*
|
/*
|
||||||
* A D V A N C E D D E B U G G I N G
|
* A D V A N C E D D E B U G G I N G
|
||||||
*
|
*
|
||||||
|
@ -1720,7 +1775,7 @@ struct <link linkend="v4l2-dbg-chip-ident">v4l2_dbg_chip_ident</link> {
|
||||||
#define VIDIOC_G_EXT_CTRLS _IOWR('V', 71, struct <link linkend="v4l2-ext-controls">v4l2_ext_controls</link>)
|
#define VIDIOC_G_EXT_CTRLS _IOWR('V', 71, struct <link linkend="v4l2-ext-controls">v4l2_ext_controls</link>)
|
||||||
#define VIDIOC_S_EXT_CTRLS _IOWR('V', 72, struct <link linkend="v4l2-ext-controls">v4l2_ext_controls</link>)
|
#define VIDIOC_S_EXT_CTRLS _IOWR('V', 72, struct <link linkend="v4l2-ext-controls">v4l2_ext_controls</link>)
|
||||||
#define VIDIOC_TRY_EXT_CTRLS _IOWR('V', 73, struct <link linkend="v4l2-ext-controls">v4l2_ext_controls</link>)
|
#define VIDIOC_TRY_EXT_CTRLS _IOWR('V', 73, struct <link linkend="v4l2-ext-controls">v4l2_ext_controls</link>)
|
||||||
#if 1 /*KEEP*/
|
#if 1
|
||||||
#define VIDIOC_ENUM_FRAMESIZES _IOWR('V', 74, struct <link linkend="v4l2-frmsizeenum">v4l2_frmsizeenum</link>)
|
#define VIDIOC_ENUM_FRAMESIZES _IOWR('V', 74, struct <link linkend="v4l2-frmsizeenum">v4l2_frmsizeenum</link>)
|
||||||
#define VIDIOC_ENUM_FRAMEINTERVALS _IOWR('V', 75, struct <link linkend="v4l2-frmivalenum">v4l2_frmivalenum</link>)
|
#define VIDIOC_ENUM_FRAMEINTERVALS _IOWR('V', 75, struct <link linkend="v4l2-frmivalenum">v4l2_frmivalenum</link>)
|
||||||
#define VIDIOC_G_ENC_INDEX _IOR('V', 76, struct <link linkend="v4l2-enc-idx">v4l2_enc_idx</link>)
|
#define VIDIOC_G_ENC_INDEX _IOR('V', 76, struct <link linkend="v4l2-enc-idx">v4l2_enc_idx</link>)
|
||||||
|
@ -1728,7 +1783,7 @@ struct <link linkend="v4l2-dbg-chip-ident">v4l2_dbg_chip_ident</link> {
|
||||||
#define VIDIOC_TRY_ENCODER_CMD _IOWR('V', 78, struct <link linkend="v4l2-encoder-cmd">v4l2_encoder_cmd</link>)
|
#define VIDIOC_TRY_ENCODER_CMD _IOWR('V', 78, struct <link linkend="v4l2-encoder-cmd">v4l2_encoder_cmd</link>)
|
||||||
#endif
|
#endif
|
||||||
|
|
||||||
#if 1 /*KEEP*/
|
#if 1
|
||||||
/* Experimental, meant for debugging, testing and internal use.
|
/* Experimental, meant for debugging, testing and internal use.
|
||||||
Only implemented if CONFIG_VIDEO_ADV_DEBUG is defined.
|
Only implemented if CONFIG_VIDEO_ADV_DEBUG is defined.
|
||||||
You must be root to use these ioctls. Never use these in applications! */
|
You must be root to use these ioctls. Never use these in applications! */
|
||||||
|
@ -1747,6 +1802,9 @@ struct <link linkend="v4l2-dbg-chip-ident">v4l2_dbg_chip_ident</link> {
|
||||||
#define VIDIOC_QUERY_DV_PRESET _IOR('V', 86, struct <link linkend="v4l2-dv-preset">v4l2_dv_preset</link>)
|
#define VIDIOC_QUERY_DV_PRESET _IOR('V', 86, struct <link linkend="v4l2-dv-preset">v4l2_dv_preset</link>)
|
||||||
#define VIDIOC_S_DV_TIMINGS _IOWR('V', 87, struct <link linkend="v4l2-dv-timings">v4l2_dv_timings</link>)
|
#define VIDIOC_S_DV_TIMINGS _IOWR('V', 87, struct <link linkend="v4l2-dv-timings">v4l2_dv_timings</link>)
|
||||||
#define VIDIOC_G_DV_TIMINGS _IOWR('V', 88, struct <link linkend="v4l2-dv-timings">v4l2_dv_timings</link>)
|
#define VIDIOC_G_DV_TIMINGS _IOWR('V', 88, struct <link linkend="v4l2-dv-timings">v4l2_dv_timings</link>)
|
||||||
|
#define VIDIOC_DQEVENT _IOR('V', 89, struct <link linkend="v4l2-event">v4l2_event</link>)
|
||||||
|
#define VIDIOC_SUBSCRIBE_EVENT _IOW('V', 90, struct <link linkend="v4l2-event-subscription">v4l2_event_subscription</link>)
|
||||||
|
#define VIDIOC_UNSUBSCRIBE_EVENT _IOW('V', 91, struct <link linkend="v4l2-event-subscription">v4l2_event_subscription</link>)
|
||||||
|
|
||||||
/* Reminder: when adding new ioctls please add support for them to
|
/* Reminder: when adding new ioctls please add support for them to
|
||||||
drivers/media/video/v4l2-compat-ioctl32.c as well! */
|
drivers/media/video/v4l2-compat-ioctl32.c as well! */
|
||||||
|
|
|
@ -16,8 +16,7 @@
|
||||||
<funcdef>int <function>ioctl</function></funcdef>
|
<funcdef>int <function>ioctl</function></funcdef>
|
||||||
<paramdef>int <parameter>fd</parameter></paramdef>
|
<paramdef>int <parameter>fd</parameter></paramdef>
|
||||||
<paramdef>int <parameter>request</parameter></paramdef>
|
<paramdef>int <parameter>request</parameter></paramdef>
|
||||||
<paramdef>&v4l2-dv-preset;
|
<paramdef>struct v4l2_dv_preset *<parameter>argp</parameter></paramdef>
|
||||||
*<parameter>argp</parameter></paramdef>
|
|
||||||
</funcprototype>
|
</funcprototype>
|
||||||
</funcsynopsis>
|
</funcsynopsis>
|
||||||
</refsynopsisdiv>
|
</refsynopsisdiv>
|
||||||
|
|
|
@ -16,8 +16,7 @@
|
||||||
<funcdef>int <function>ioctl</function></funcdef>
|
<funcdef>int <function>ioctl</function></funcdef>
|
||||||
<paramdef>int <parameter>fd</parameter></paramdef>
|
<paramdef>int <parameter>fd</parameter></paramdef>
|
||||||
<paramdef>int <parameter>request</parameter></paramdef>
|
<paramdef>int <parameter>request</parameter></paramdef>
|
||||||
<paramdef>&v4l2-dv-timings;
|
<paramdef>struct v4l2_dv_timings *<parameter>argp</parameter></paramdef>
|
||||||
*<parameter>argp</parameter></paramdef>
|
|
||||||
</funcprototype>
|
</funcprototype>
|
||||||
</funcsynopsis>
|
</funcsynopsis>
|
||||||
</refsynopsisdiv>
|
</refsynopsisdiv>
|
||||||
|
|
|
@ -16,7 +16,7 @@ input</refpurpose>
|
||||||
<funcdef>int <function>ioctl</function></funcdef>
|
<funcdef>int <function>ioctl</function></funcdef>
|
||||||
<paramdef>int <parameter>fd</parameter></paramdef>
|
<paramdef>int <parameter>fd</parameter></paramdef>
|
||||||
<paramdef>int <parameter>request</parameter></paramdef>
|
<paramdef>int <parameter>request</parameter></paramdef>
|
||||||
<paramdef>&v4l2-dv-preset; *<parameter>argp</parameter></paramdef>
|
<paramdef>struct v4l2_dv_preset *<parameter>argp</parameter></paramdef>
|
||||||
</funcprototype>
|
</funcprototype>
|
||||||
</funcsynopsis>
|
</funcsynopsis>
|
||||||
</refsynopsisdiv>
|
</refsynopsisdiv>
|
||||||
|
|
|
@ -184,7 +184,7 @@ data.</entry>
|
||||||
<row>
|
<row>
|
||||||
<entry><constant>V4L2_CAP_RDS_CAPTURE</constant></entry>
|
<entry><constant>V4L2_CAP_RDS_CAPTURE</constant></entry>
|
||||||
<entry>0x00000100</entry>
|
<entry>0x00000100</entry>
|
||||||
<entry>The device supports the <link linkend="rds">RDS</link> interface.</entry>
|
<entry>The device supports the <link linkend="rds">RDS</link> capture interface.</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><constant>V4L2_CAP_VIDEO_OUTPUT_OVERLAY</constant></entry>
|
<entry><constant>V4L2_CAP_VIDEO_OUTPUT_OVERLAY</constant></entry>
|
||||||
|
@ -205,6 +205,11 @@ driver capabilities.</para></footnote></entry>
|
||||||
<entry>The device supports the &VIDIOC-S-HW-FREQ-SEEK; ioctl for
|
<entry>The device supports the &VIDIOC-S-HW-FREQ-SEEK; ioctl for
|
||||||
hardware frequency seeking.</entry>
|
hardware frequency seeking.</entry>
|
||||||
</row>
|
</row>
|
||||||
|
<row>
|
||||||
|
<entry><constant>V4L2_CAP_RDS_OUTPUT</constant></entry>
|
||||||
|
<entry>0x00000800</entry>
|
||||||
|
<entry>The device supports the <link linkend="rds">RDS</link> output interface.</entry>
|
||||||
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><constant>V4L2_CAP_TUNER</constant></entry>
|
<entry><constant>V4L2_CAP_TUNER</constant></entry>
|
||||||
<entry>0x00010000</entry>
|
<entry>0x00010000</entry>
|
||||||
|
|
|
@ -103,8 +103,12 @@ structure. The driver fills the rest of the structure or returns an
|
||||||
<structfield>index</structfield> is invalid. Menu items are enumerated
|
<structfield>index</structfield> is invalid. Menu items are enumerated
|
||||||
by calling <constant>VIDIOC_QUERYMENU</constant> with successive
|
by calling <constant>VIDIOC_QUERYMENU</constant> with successive
|
||||||
<structfield>index</structfield> values from &v4l2-queryctrl;
|
<structfield>index</structfield> values from &v4l2-queryctrl;
|
||||||
<structfield>minimum</structfield> (0) to
|
<structfield>minimum</structfield> to
|
||||||
<structfield>maximum</structfield>, inclusive.</para>
|
<structfield>maximum</structfield>, inclusive. Note that it is possible
|
||||||
|
for <constant>VIDIOC_QUERYMENU</constant> to return an &EINVAL; for some
|
||||||
|
indices between <structfield>minimum</structfield> and <structfield>maximum</structfield>.
|
||||||
|
In that case that particular menu item is not supported by this driver. Also note that
|
||||||
|
the <structfield>minimum</structfield> value is not necessarily 0.</para>
|
||||||
|
|
||||||
<para>See also the examples in <xref linkend="control" />.</para>
|
<para>See also the examples in <xref linkend="control" />.</para>
|
||||||
|
|
||||||
|
@ -139,7 +143,7 @@ string. This information is intended for the user.</entry>
|
||||||
<entry><structfield>minimum</structfield></entry>
|
<entry><structfield>minimum</structfield></entry>
|
||||||
<entry>Minimum value, inclusive. This field gives a lower
|
<entry>Minimum value, inclusive. This field gives a lower
|
||||||
bound for <constant>V4L2_CTRL_TYPE_INTEGER</constant> controls and the
|
bound for <constant>V4L2_CTRL_TYPE_INTEGER</constant> controls and the
|
||||||
lowest valid index (always 0) for <constant>V4L2_CTRL_TYPE_MENU</constant> controls.
|
lowest valid index for <constant>V4L2_CTRL_TYPE_MENU</constant> controls.
|
||||||
For <constant>V4L2_CTRL_TYPE_STRING</constant> controls the minimum value
|
For <constant>V4L2_CTRL_TYPE_STRING</constant> controls the minimum value
|
||||||
gives the minimum length of the string. This length <emphasis>does not include the terminating
|
gives the minimum length of the string. This length <emphasis>does not include the terminating
|
||||||
zero</emphasis>. It may not be valid for any other type of control, including
|
zero</emphasis>. It may not be valid for any other type of control, including
|
||||||
|
@ -279,7 +283,7 @@ values which are actually different on the hardware.</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><constant>V4L2_CTRL_TYPE_MENU</constant></entry>
|
<entry><constant>V4L2_CTRL_TYPE_MENU</constant></entry>
|
||||||
<entry>0</entry>
|
<entry>≥ 0</entry>
|
||||||
<entry>1</entry>
|
<entry>1</entry>
|
||||||
<entry>N-1</entry>
|
<entry>N-1</entry>
|
||||||
<entry>The control has a menu of N choices. The names of
|
<entry>The control has a menu of N choices. The names of
|
||||||
|
@ -405,8 +409,10 @@ writing a value will cause the device to carry out a given action
|
||||||
<term><errorcode>EINVAL</errorcode></term>
|
<term><errorcode>EINVAL</errorcode></term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>The &v4l2-queryctrl; <structfield>id</structfield>
|
<para>The &v4l2-queryctrl; <structfield>id</structfield>
|
||||||
is invalid. The &v4l2-querymenu; <structfield>id</structfield> or
|
is invalid. The &v4l2-querymenu; <structfield>id</structfield> is
|
||||||
<structfield>index</structfield> is invalid.</para>
|
invalid or <structfield>index</structfield> is out of range (less than
|
||||||
|
<structfield>minimum</structfield> or greater than <structfield>maximum</structfield>)
|
||||||
|
or this particular menu item is not supported by the driver.</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
<varlistentry>
|
<varlistentry>
|
||||||
|
|
|
@ -51,7 +51,8 @@
|
||||||
|
|
||||||
<para>Start a hardware frequency seek from the current frequency.
|
<para>Start a hardware frequency seek from the current frequency.
|
||||||
To do this applications initialize the <structfield>tuner</structfield>,
|
To do this applications initialize the <structfield>tuner</structfield>,
|
||||||
<structfield>type</structfield>, <structfield>seek_upward</structfield> and
|
<structfield>type</structfield>, <structfield>seek_upward</structfield>,
|
||||||
|
<structfield>spacing</structfield> and
|
||||||
<structfield>wrap_around</structfield> fields, and zero out the
|
<structfield>wrap_around</structfield> fields, and zero out the
|
||||||
<structfield>reserved</structfield> array of a &v4l2-hw-freq-seek; and
|
<structfield>reserved</structfield> array of a &v4l2-hw-freq-seek; and
|
||||||
call the <constant>VIDIOC_S_HW_FREQ_SEEK</constant> ioctl with a pointer
|
call the <constant>VIDIOC_S_HW_FREQ_SEEK</constant> ioctl with a pointer
|
||||||
|
@ -89,7 +90,12 @@ field and the &v4l2-tuner; <structfield>index</structfield> field.</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry>__u32</entry>
|
<entry>__u32</entry>
|
||||||
<entry><structfield>reserved</structfield>[8]</entry>
|
<entry><structfield>spacing</structfield></entry>
|
||||||
|
<entry>If non-zero, defines the hardware seek resolution in Hz. The driver selects the nearest value that is supported by the device. If spacing is zero a reasonable default value is used.</entry>
|
||||||
|
</row>
|
||||||
|
<row>
|
||||||
|
<entry>__u32</entry>
|
||||||
|
<entry><structfield>reserved</structfield>[7]</entry>
|
||||||
<entry>Reserved for future extensions. Drivers and
|
<entry>Reserved for future extensions. Drivers and
|
||||||
applications must set the array to zero.</entry>
|
applications must set the array to zero.</entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
|
@ -21,6 +21,7 @@
|
||||||
#include <sys/types.h>
|
#include <sys/types.h>
|
||||||
#include <sys/stat.h>
|
#include <sys/stat.h>
|
||||||
#include <sys/socket.h>
|
#include <sys/socket.h>
|
||||||
|
#include <sys/wait.h>
|
||||||
#include <signal.h>
|
#include <signal.h>
|
||||||
|
|
||||||
#include <linux/genetlink.h>
|
#include <linux/genetlink.h>
|
||||||
|
@ -266,11 +267,13 @@ int main(int argc, char *argv[])
|
||||||
int containerset = 0;
|
int containerset = 0;
|
||||||
char containerpath[1024];
|
char containerpath[1024];
|
||||||
int cfd = 0;
|
int cfd = 0;
|
||||||
|
int forking = 0;
|
||||||
|
sigset_t sigset;
|
||||||
|
|
||||||
struct msgtemplate msg;
|
struct msgtemplate msg;
|
||||||
|
|
||||||
while (1) {
|
while (!forking) {
|
||||||
c = getopt(argc, argv, "qdiw:r:m:t:p:vlC:");
|
c = getopt(argc, argv, "qdiw:r:m:t:p:vlC:c:");
|
||||||
if (c < 0)
|
if (c < 0)
|
||||||
break;
|
break;
|
||||||
|
|
||||||
|
@ -319,6 +322,28 @@ int main(int argc, char *argv[])
|
||||||
err(1, "Invalid pid\n");
|
err(1, "Invalid pid\n");
|
||||||
cmd_type = TASKSTATS_CMD_ATTR_PID;
|
cmd_type = TASKSTATS_CMD_ATTR_PID;
|
||||||
break;
|
break;
|
||||||
|
case 'c':
|
||||||
|
|
||||||
|
/* Block SIGCHLD for sigwait() later */
|
||||||
|
if (sigemptyset(&sigset) == -1)
|
||||||
|
err(1, "Failed to empty sigset");
|
||||||
|
if (sigaddset(&sigset, SIGCHLD))
|
||||||
|
err(1, "Failed to set sigchld in sigset");
|
||||||
|
sigprocmask(SIG_BLOCK, &sigset, NULL);
|
||||||
|
|
||||||
|
/* fork/exec a child */
|
||||||
|
tid = fork();
|
||||||
|
if (tid < 0)
|
||||||
|
err(1, "Fork failed\n");
|
||||||
|
if (tid == 0)
|
||||||
|
if (execvp(argv[optind - 1],
|
||||||
|
&argv[optind - 1]) < 0)
|
||||||
|
exit(-1);
|
||||||
|
|
||||||
|
/* Set the command type and avoid further processing */
|
||||||
|
cmd_type = TASKSTATS_CMD_ATTR_PID;
|
||||||
|
forking = 1;
|
||||||
|
break;
|
||||||
case 'v':
|
case 'v':
|
||||||
printf("debug on\n");
|
printf("debug on\n");
|
||||||
dbg = 1;
|
dbg = 1;
|
||||||
|
@ -370,6 +395,15 @@ int main(int argc, char *argv[])
|
||||||
goto err;
|
goto err;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
/*
|
||||||
|
* If we forked a child, wait for it to exit. Cannot use waitpid()
|
||||||
|
* as all the delicious data would be reaped as part of the wait
|
||||||
|
*/
|
||||||
|
if (tid && forking) {
|
||||||
|
int sig_received;
|
||||||
|
sigwait(&sigset, &sig_received);
|
||||||
|
}
|
||||||
|
|
||||||
if (tid) {
|
if (tid) {
|
||||||
rc = send_cmd(nl_sd, id, mypid, TASKSTATS_CMD_GET,
|
rc = send_cmd(nl_sd, id, mypid, TASKSTATS_CMD_GET,
|
||||||
cmd_type, &tid, sizeof(__u32));
|
cmd_type, &tid, sizeof(__u32));
|
||||||
|
|
|
@ -255,9 +255,10 @@ framebuffer parameters.
|
||||||
Kernel boot arguments
|
Kernel boot arguments
|
||||||
---------------------
|
---------------------
|
||||||
|
|
||||||
vram=<size>
|
vram=<size>[,<physaddr>]
|
||||||
- Amount of total VRAM to preallocate. For example, "10M". omapfb
|
- Amount of total VRAM to preallocate and optionally a physical start
|
||||||
allocates memory for framebuffers from VRAM.
|
memory address. For example, "10M". omapfb allocates memory for
|
||||||
|
framebuffers from VRAM.
|
||||||
|
|
||||||
omapfb.mode=<display>:<mode>[,...]
|
omapfb.mode=<display>:<mode>[,...]
|
||||||
- Default video mode for specified displays. For example,
|
- Default video mode for specified displays. For example,
|
||||||
|
|
|
@ -16,7 +16,7 @@ you can do so by typing:
|
||||||
As of the Linux 2.6.10 kernel, it is now possible to change the
|
As of the Linux 2.6.10 kernel, it is now possible to change the
|
||||||
IO scheduler for a given block device on the fly (thus making it possible,
|
IO scheduler for a given block device on the fly (thus making it possible,
|
||||||
for instance, to set the CFQ scheduler for the system default, but
|
for instance, to set the CFQ scheduler for the system default, but
|
||||||
set a specific device to use the anticipatory or noop schedulers - which
|
set a specific device to use the deadline or noop schedulers - which
|
||||||
can improve that device's throughput).
|
can improve that device's throughput).
|
||||||
|
|
||||||
To set a specific scheduler, simply do this:
|
To set a specific scheduler, simply do this:
|
||||||
|
@ -31,7 +31,7 @@ a "cat /sys/block/DEV/queue/scheduler" - the list of valid names
|
||||||
will be displayed, with the currently selected scheduler in brackets:
|
will be displayed, with the currently selected scheduler in brackets:
|
||||||
|
|
||||||
# cat /sys/block/hda/queue/scheduler
|
# cat /sys/block/hda/queue/scheduler
|
||||||
noop anticipatory deadline [cfq]
|
noop deadline [cfq]
|
||||||
# echo anticipatory > /sys/block/hda/queue/scheduler
|
# echo deadline > /sys/block/hda/queue/scheduler
|
||||||
# cat /sys/block/hda/queue/scheduler
|
# cat /sys/block/hda/queue/scheduler
|
||||||
noop [anticipatory] deadline cfq
|
noop [deadline] cfq
|
||||||
|
|
|
@ -18,7 +18,8 @@ CONTENTS:
|
||||||
1.2 Why are cgroups needed ?
|
1.2 Why are cgroups needed ?
|
||||||
1.3 How are cgroups implemented ?
|
1.3 How are cgroups implemented ?
|
||||||
1.4 What does notify_on_release do ?
|
1.4 What does notify_on_release do ?
|
||||||
1.5 How do I use cgroups ?
|
1.5 What does clone_children do ?
|
||||||
|
1.6 How do I use cgroups ?
|
||||||
2. Usage Examples and Syntax
|
2. Usage Examples and Syntax
|
||||||
2.1 Basic Usage
|
2.1 Basic Usage
|
||||||
2.2 Attaching processes
|
2.2 Attaching processes
|
||||||
|
@ -293,7 +294,16 @@ notify_on_release in the root cgroup at system boot is disabled
|
||||||
value of their parents notify_on_release setting. The default value of
|
value of their parents notify_on_release setting. The default value of
|
||||||
a cgroup hierarchy's release_agent path is empty.
|
a cgroup hierarchy's release_agent path is empty.
|
||||||
|
|
||||||
1.5 How do I use cgroups ?
|
1.5 What does clone_children do ?
|
||||||
|
---------------------------------
|
||||||
|
|
||||||
|
If the clone_children flag is enabled (1) in a cgroup, then all
|
||||||
|
cgroups created beneath will call the post_clone callbacks for each
|
||||||
|
subsystem of the newly created cgroup. Usually when this callback is
|
||||||
|
implemented for a subsystem, it copies the values of the parent
|
||||||
|
subsystem, this is the case for the cpuset.
|
||||||
|
|
||||||
|
1.6 How do I use cgroups ?
|
||||||
--------------------------
|
--------------------------
|
||||||
|
|
||||||
To start a new job that is to be contained within a cgroup, using
|
To start a new job that is to be contained within a cgroup, using
|
||||||
|
|
|
@ -24,6 +24,9 @@ of many distributions, e.g. :
|
||||||
You can get the latest version released from the Coccinelle homepage at
|
You can get the latest version released from the Coccinelle homepage at
|
||||||
http://coccinelle.lip6.fr/
|
http://coccinelle.lip6.fr/
|
||||||
|
|
||||||
|
Information and tips about Coccinelle are also provided on the wiki
|
||||||
|
pages at http://cocci.ekstranet.diku.dk/wiki/doku.php
|
||||||
|
|
||||||
Once you have it, run the following command:
|
Once you have it, run the following command:
|
||||||
|
|
||||||
./configure
|
./configure
|
||||||
|
@ -41,20 +44,22 @@ A Coccinelle-specific target is defined in the top level
|
||||||
Makefile. This target is named 'coccicheck' and calls the 'coccicheck'
|
Makefile. This target is named 'coccicheck' and calls the 'coccicheck'
|
||||||
front-end in the 'scripts' directory.
|
front-end in the 'scripts' directory.
|
||||||
|
|
||||||
Four modes are defined: report, patch, context, and org. The mode to
|
Four modes are defined: patch, report, context, and org. The mode to
|
||||||
use is specified by setting the MODE variable with 'MODE=<mode>'.
|
use is specified by setting the MODE variable with 'MODE=<mode>'.
|
||||||
|
|
||||||
|
'patch' proposes a fix, when possible.
|
||||||
|
|
||||||
'report' generates a list in the following format:
|
'report' generates a list in the following format:
|
||||||
file:line:column-column: message
|
file:line:column-column: message
|
||||||
|
|
||||||
'patch' proposes a fix, when possible.
|
|
||||||
|
|
||||||
'context' highlights lines of interest and their context in a
|
'context' highlights lines of interest and their context in a
|
||||||
diff-like style.Lines of interest are indicated with '-'.
|
diff-like style.Lines of interest are indicated with '-'.
|
||||||
|
|
||||||
'org' generates a report in the Org mode format of Emacs.
|
'org' generates a report in the Org mode format of Emacs.
|
||||||
|
|
||||||
Note that not all semantic patches implement all modes.
|
Note that not all semantic patches implement all modes. For easy use
|
||||||
|
of Coccinelle, the default mode is "chain" which tries the previous
|
||||||
|
modes in the order above until one succeeds.
|
||||||
|
|
||||||
To make a report for every semantic patch, run the following command:
|
To make a report for every semantic patch, run the following command:
|
||||||
|
|
||||||
|
@ -68,9 +73,9 @@ To produce patches, run:
|
||||||
|
|
||||||
|
|
||||||
The coccicheck target applies every semantic patch available in the
|
The coccicheck target applies every semantic patch available in the
|
||||||
subdirectories of 'scripts/coccinelle' to the entire Linux kernel.
|
sub-directories of 'scripts/coccinelle' to the entire Linux kernel.
|
||||||
|
|
||||||
For each semantic patch, a changelog message is proposed. It gives a
|
For each semantic patch, a commit message is proposed. It gives a
|
||||||
description of the problem being checked by the semantic patch, and
|
description of the problem being checked by the semantic patch, and
|
||||||
includes a reference to Coccinelle.
|
includes a reference to Coccinelle.
|
||||||
|
|
||||||
|
@ -93,12 +98,35 @@ or
|
||||||
make coccicheck COCCI=<my_SP.cocci> MODE=report
|
make coccicheck COCCI=<my_SP.cocci> MODE=report
|
||||||
|
|
||||||
|
|
||||||
|
Using Coccinelle on (modified) files
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
To apply Coccinelle on a file basis, instead of a directory basis, the
|
||||||
|
following command may be used:
|
||||||
|
|
||||||
|
make C=1 CHECK="scripts/coccicheck"
|
||||||
|
|
||||||
|
To check only newly edited code, use the value 2 for the C flag, i.e.
|
||||||
|
|
||||||
|
make C=2 CHECK="scripts/coccicheck"
|
||||||
|
|
||||||
|
This runs every semantic patch in scripts/coccinelle by default. The
|
||||||
|
COCCI variable may additionally be used to only apply a single
|
||||||
|
semantic patch as shown in the previous section.
|
||||||
|
|
||||||
|
The "chain" mode is the default. You can select another one with the
|
||||||
|
MODE variable explained above.
|
||||||
|
|
||||||
|
In this mode, there is no information about semantic patches
|
||||||
|
displayed, and no commit message proposed.
|
||||||
|
|
||||||
|
|
||||||
Proposing new semantic patches
|
Proposing new semantic patches
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
New semantic patches can be proposed and submitted by kernel
|
New semantic patches can be proposed and submitted by kernel
|
||||||
developers. For sake of clarity, they should be organized in the
|
developers. For sake of clarity, they should be organized in the
|
||||||
subdirectories of 'scripts/coccinelle/'.
|
sub-directories of 'scripts/coccinelle/'.
|
||||||
|
|
||||||
|
|
||||||
Detailed description of the 'report' mode
|
Detailed description of the 'report' mode
|
||||||
|
@ -111,7 +139,7 @@ Example:
|
||||||
|
|
||||||
Running
|
Running
|
||||||
|
|
||||||
make coccicheck MODE=report COCCI=scripts/coccinelle/err_cast.cocci
|
make coccicheck MODE=report COCCI=scripts/coccinelle/api/err_cast.cocci
|
||||||
|
|
||||||
will execute the following part of the SmPL script.
|
will execute the following part of the SmPL script.
|
||||||
|
|
||||||
|
@ -149,7 +177,7 @@ identified.
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
Running
|
Running
|
||||||
make coccicheck MODE=patch COCCI=scripts/coccinelle/err_cast.cocci
|
make coccicheck MODE=patch COCCI=scripts/coccinelle/api/err_cast.cocci
|
||||||
|
|
||||||
will execute the following part of the SmPL script.
|
will execute the following part of the SmPL script.
|
||||||
|
|
||||||
|
@ -193,7 +221,7 @@ NOTE: The diff-like output generated is NOT an applicable patch. The
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
Running
|
Running
|
||||||
make coccicheck MODE=context COCCI=scripts/coccinelle/err_cast.cocci
|
make coccicheck MODE=context COCCI=scripts/coccinelle/api/err_cast.cocci
|
||||||
|
|
||||||
will execute the following part of the SmPL script.
|
will execute the following part of the SmPL script.
|
||||||
|
|
||||||
|
@ -228,7 +256,7 @@ diff -u -p /home/user/linux/crypto/ctr.c /tmp/nothing
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
Running
|
Running
|
||||||
make coccicheck MODE=org COCCI=scripts/coccinelle/err_cast.cocci
|
make coccicheck MODE=org COCCI=scripts/coccinelle/api/err_cast.cocci
|
||||||
|
|
||||||
will execute the following part of the SmPL script.
|
will execute the following part of the SmPL script.
|
||||||
|
|
||||||
|
|
|
@ -154,7 +154,7 @@ The stages that a patch goes through are, generally:
|
||||||
inclusion, it should be accepted by a relevant subsystem maintainer -
|
inclusion, it should be accepted by a relevant subsystem maintainer -
|
||||||
though this acceptance is not a guarantee that the patch will make it
|
though this acceptance is not a guarantee that the patch will make it
|
||||||
all the way to the mainline. The patch will show up in the maintainer's
|
all the way to the mainline. The patch will show up in the maintainer's
|
||||||
subsystem tree and into the staging trees (described below). When the
|
subsystem tree and into the -next trees (described below). When the
|
||||||
process works, this step leads to more extensive review of the patch and
|
process works, this step leads to more extensive review of the patch and
|
||||||
the discovery of any problems resulting from the integration of this
|
the discovery of any problems resulting from the integration of this
|
||||||
patch with work being done by others.
|
patch with work being done by others.
|
||||||
|
@ -236,7 +236,7 @@ finding the right maintainer. Sending patches directly to Linus is not
|
||||||
normally the right way to go.
|
normally the right way to go.
|
||||||
|
|
||||||
|
|
||||||
2.4: STAGING TREES
|
2.4: NEXT TREES
|
||||||
|
|
||||||
The chain of subsystem trees guides the flow of patches into the kernel,
|
The chain of subsystem trees guides the flow of patches into the kernel,
|
||||||
but it also raises an interesting question: what if somebody wants to look
|
but it also raises an interesting question: what if somebody wants to look
|
||||||
|
@ -250,7 +250,7 @@ changes land in the mainline kernel. One could pull changes from all of
|
||||||
the interesting subsystem trees, but that would be a big and error-prone
|
the interesting subsystem trees, but that would be a big and error-prone
|
||||||
job.
|
job.
|
||||||
|
|
||||||
The answer comes in the form of staging trees, where subsystem trees are
|
The answer comes in the form of -next trees, where subsystem trees are
|
||||||
collected for testing and review. The older of these trees, maintained by
|
collected for testing and review. The older of these trees, maintained by
|
||||||
Andrew Morton, is called "-mm" (for memory management, which is how it got
|
Andrew Morton, is called "-mm" (for memory management, which is how it got
|
||||||
started). The -mm tree integrates patches from a long list of subsystem
|
started). The -mm tree integrates patches from a long list of subsystem
|
||||||
|
@ -275,7 +275,7 @@ directory at:
|
||||||
Use of the MMOTM tree is likely to be a frustrating experience, though;
|
Use of the MMOTM tree is likely to be a frustrating experience, though;
|
||||||
there is a definite chance that it will not even compile.
|
there is a definite chance that it will not even compile.
|
||||||
|
|
||||||
The other staging tree, started more recently, is linux-next, maintained by
|
The other -next tree, started more recently, is linux-next, maintained by
|
||||||
Stephen Rothwell. The linux-next tree is, by design, a snapshot of what
|
Stephen Rothwell. The linux-next tree is, by design, a snapshot of what
|
||||||
the mainline is expected to look like after the next merge window closes.
|
the mainline is expected to look like after the next merge window closes.
|
||||||
Linux-next trees are announced on the linux-kernel and linux-next mailing
|
Linux-next trees are announced on the linux-kernel and linux-next mailing
|
||||||
|
@ -303,12 +303,25 @@ volatility of linux-next tends to make it a difficult development target.
|
||||||
See http://lwn.net/Articles/289013/ for more information on this topic, and
|
See http://lwn.net/Articles/289013/ for more information on this topic, and
|
||||||
stay tuned; much is still in flux where linux-next is involved.
|
stay tuned; much is still in flux where linux-next is involved.
|
||||||
|
|
||||||
Besides the mmotm and linux-next trees, the kernel source tree now contains
|
2.4.1: STAGING TREES
|
||||||
the drivers/staging/ directory and many sub-directories for drivers or
|
|
||||||
filesystems that are on their way to being added to the kernel tree
|
|
||||||
proper, but they remain in drivers/staging/ while they still need more
|
|
||||||
work.
|
|
||||||
|
|
||||||
|
The kernel source tree now contains the drivers/staging/ directory, where
|
||||||
|
many sub-directories for drivers or filesystems that are on their way to
|
||||||
|
being added to the kernel tree live. They remain in drivers/staging while
|
||||||
|
they still need more work; once complete, they can be moved into the
|
||||||
|
kernel proper. This is a way to keep track of drivers that aren't
|
||||||
|
up to Linux kernel coding or quality standards, but people may want to use
|
||||||
|
them and track development.
|
||||||
|
|
||||||
|
Greg Kroah-Hartman currently (as of 2.6.36) maintains the staging tree.
|
||||||
|
Drivers that still need work are sent to him, with each driver having
|
||||||
|
its own subdirectory in drivers/staging/. Along with the driver source
|
||||||
|
files, a TODO file should be present in the directory as well. The TODO
|
||||||
|
file lists the pending work that the driver needs for acceptance into
|
||||||
|
the kernel proper, as well as a list of people that should be Cc'd for any
|
||||||
|
patches to the driver. Staging drivers that don't currently build should
|
||||||
|
have their config entries depend upon CONFIG_BROKEN. Once they can
|
||||||
|
be successfully built without outside patches, CONFIG_BROKEN can be removed.
|
||||||
|
|
||||||
2.5: TOOLS
|
2.5: TOOLS
|
||||||
|
|
||||||
|
|
|
@ -1496,9 +1496,6 @@ Your cooperation is appreciated.
|
||||||
64 = /dev/radio0 Radio device
|
64 = /dev/radio0 Radio device
|
||||||
...
|
...
|
||||||
127 = /dev/radio63 Radio device
|
127 = /dev/radio63 Radio device
|
||||||
192 = /dev/vtx0 Teletext device
|
|
||||||
...
|
|
||||||
223 = /dev/vtx31 Teletext device
|
|
||||||
224 = /dev/vbi0 Vertical blank interrupt
|
224 = /dev/vbi0 Vertical blank interrupt
|
||||||
...
|
...
|
||||||
255 = /dev/vbi31 Vertical blank interrupt
|
255 = /dev/vbi31 Vertical blank interrupt
|
||||||
|
@ -2520,6 +2517,12 @@ Your cooperation is appreciated.
|
||||||
8 = /dev/mmcblk1 Second SD/MMC card
|
8 = /dev/mmcblk1 Second SD/MMC card
|
||||||
...
|
...
|
||||||
|
|
||||||
|
The start of next SD/MMC card can be configured with
|
||||||
|
CONFIG_MMC_BLOCK_MINORS, or overridden at boot/modprobe
|
||||||
|
time using the mmcblk.perdev_minors option. That would
|
||||||
|
bump the offset between each card to be the configured
|
||||||
|
value instead of the default 8.
|
||||||
|
|
||||||
179 char CCube DVXChip-based PCI products
|
179 char CCube DVXChip-based PCI products
|
||||||
0 = /dev/dvxirq0 First DVX device
|
0 = /dev/dvxirq0 First DVX device
|
||||||
1 = /dev/dvxirq1 Second DVX device
|
1 = /dev/dvxirq1 Second DVX device
|
||||||
|
|
|
@ -1,129 +0,0 @@
|
||||||
|
|
||||||
Device Interfaces
|
|
||||||
|
|
||||||
Introduction
|
|
||||||
~~~~~~~~~~~~
|
|
||||||
|
|
||||||
Device interfaces are the logical interfaces of device classes that correlate
|
|
||||||
directly to userspace interfaces, like device nodes.
|
|
||||||
|
|
||||||
Each device class may have multiple interfaces through which you can
|
|
||||||
access the same device. An input device may support the mouse interface,
|
|
||||||
the 'evdev' interface, and the touchscreen interface. A SCSI disk would
|
|
||||||
support the disk interface, the SCSI generic interface, and possibly a raw
|
|
||||||
device interface.
|
|
||||||
|
|
||||||
Device interfaces are registered with the class they belong to. As devices
|
|
||||||
are added to the class, they are added to each interface registered with
|
|
||||||
the class. The interface is responsible for determining whether the device
|
|
||||||
supports the interface or not.
|
|
||||||
|
|
||||||
|
|
||||||
Programming Interface
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
struct device_interface {
|
|
||||||
char * name;
|
|
||||||
rwlock_t lock;
|
|
||||||
u32 devnum;
|
|
||||||
struct device_class * devclass;
|
|
||||||
|
|
||||||
struct list_head node;
|
|
||||||
struct driver_dir_entry dir;
|
|
||||||
|
|
||||||
int (*add_device)(struct device *);
|
|
||||||
int (*add_device)(struct intf_data *);
|
|
||||||
};
|
|
||||||
|
|
||||||
int interface_register(struct device_interface *);
|
|
||||||
void interface_unregister(struct device_interface *);
|
|
||||||
|
|
||||||
|
|
||||||
An interface must specify the device class it belongs to. It is added
|
|
||||||
to that class's list of interfaces on registration.
|
|
||||||
|
|
||||||
|
|
||||||
Interfaces can be added to a device class at any time. Whenever it is
|
|
||||||
added, each device in the class is passed to the interface's
|
|
||||||
add_device callback. When an interface is removed, each device is
|
|
||||||
removed from the interface.
|
|
||||||
|
|
||||||
|
|
||||||
Devices
|
|
||||||
~~~~~~~
|
|
||||||
Once a device is added to a device class, it is added to each
|
|
||||||
interface that is registered with the device class. The class
|
|
||||||
is expected to place a class-specific data structure in
|
|
||||||
struct device::class_data. The interface can use that (along with
|
|
||||||
other fields of struct device) to determine whether or not the driver
|
|
||||||
and/or device support that particular interface.
|
|
||||||
|
|
||||||
|
|
||||||
Data
|
|
||||||
~~~~
|
|
||||||
|
|
||||||
struct intf_data {
|
|
||||||
struct list_head node;
|
|
||||||
struct device_interface * intf;
|
|
||||||
struct device * dev;
|
|
||||||
u32 intf_num;
|
|
||||||
};
|
|
||||||
|
|
||||||
int interface_add_data(struct interface_data *);
|
|
||||||
|
|
||||||
The interface is responsible for allocating and initializing a struct
|
|
||||||
intf_data and calling interface_add_data() to add it to the device's list
|
|
||||||
of interfaces it belongs to. This list will be iterated over when the device
|
|
||||||
is removed from the class (instead of all possible interfaces for a class).
|
|
||||||
This structure should probably be embedded in whatever per-device data
|
|
||||||
structure the interface is allocating anyway.
|
|
||||||
|
|
||||||
Devices are enumerated within the interface. This happens in interface_add_data()
|
|
||||||
and the enumerated value is stored in the struct intf_data for that device.
|
|
||||||
|
|
||||||
sysfs
|
|
||||||
~~~~~
|
|
||||||
Each interface is given a directory in the directory of the device
|
|
||||||
class it belongs to:
|
|
||||||
|
|
||||||
Interfaces get a directory in the class's directory as well:
|
|
||||||
|
|
||||||
class/
|
|
||||||
`-- input
|
|
||||||
|-- devices
|
|
||||||
|-- drivers
|
|
||||||
|-- mouse
|
|
||||||
`-- evdev
|
|
||||||
|
|
||||||
When a device is added to the interface, a symlink is created that points
|
|
||||||
to the device's directory in the physical hierarchy:
|
|
||||||
|
|
||||||
class/
|
|
||||||
`-- input
|
|
||||||
|-- devices
|
|
||||||
| `-- 1 -> ../../../root/pci0/00:1f.0/usb_bus/00:1f.2-1:0/
|
|
||||||
|-- drivers
|
|
||||||
| `-- usb:usb_mouse -> ../../../bus/drivers/usb_mouse/
|
|
||||||
|-- mouse
|
|
||||||
| `-- 1 -> ../../../root/pci0/00:1f.0/usb_bus/00:1f.2-1:0/
|
|
||||||
`-- evdev
|
|
||||||
`-- 1 -> ../../../root/pci0/00:1f.0/usb_bus/00:1f.2-1:0/
|
|
||||||
|
|
||||||
|
|
||||||
Future Plans
|
|
||||||
~~~~~~~~~~~~
|
|
||||||
A device interface is correlated directly with a userspace interface
|
|
||||||
for a device, specifically a device node. For instance, a SCSI disk
|
|
||||||
exposes at least two interfaces to userspace: the standard SCSI disk
|
|
||||||
interface and the SCSI generic interface. It might also export a raw
|
|
||||||
device interface.
|
|
||||||
|
|
||||||
Many interfaces have a major number associated with them and each
|
|
||||||
device gets a minor number. Or, multiple interfaces might share one
|
|
||||||
major number, and each will receive a range of minor numbers (like in
|
|
||||||
the case of input devices).
|
|
||||||
|
|
||||||
These major and minor numbers could be stored in the interface
|
|
||||||
structure. Major and minor allocations could happen when the interface
|
|
||||||
is registered with the class, or via a helper function.
|
|
||||||
|
|
|
@ -26,7 +26,8 @@ use IO::Handle;
|
||||||
"dec3000s", "vp7041", "dibusb", "nxt2002", "nxt2004",
|
"dec3000s", "vp7041", "dibusb", "nxt2002", "nxt2004",
|
||||||
"or51211", "or51132_qam", "or51132_vsb", "bluebird",
|
"or51211", "or51132_qam", "or51132_vsb", "bluebird",
|
||||||
"opera1", "cx231xx", "cx18", "cx23885", "pvrusb2", "mpc718",
|
"opera1", "cx231xx", "cx18", "cx23885", "pvrusb2", "mpc718",
|
||||||
"af9015", "ngene", "az6027");
|
"af9015", "ngene", "az6027", "lme2510_lg", "lme2510c_s7395",
|
||||||
|
"lme2510c_s7395_old");
|
||||||
|
|
||||||
# Check args
|
# Check args
|
||||||
syntax() if (scalar(@ARGV) != 1);
|
syntax() if (scalar(@ARGV) != 1);
|
||||||
|
@ -584,6 +585,49 @@ sub az6027{
|
||||||
|
|
||||||
$firmware;
|
$firmware;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
sub lme2510_lg {
|
||||||
|
my $sourcefile = "LMEBDA_DVBS.sys";
|
||||||
|
my $hash = "fc6017ad01e79890a97ec53bea157ed2";
|
||||||
|
my $outfile = "dvb-usb-lme2510-lg.fw";
|
||||||
|
my $hasho = "caa065d5fdbd2c09ad57b399bbf55cad";
|
||||||
|
|
||||||
|
checkstandard();
|
||||||
|
|
||||||
|
verify($sourcefile, $hash);
|
||||||
|
extract($sourcefile, 4168, 3841, $outfile);
|
||||||
|
verify($outfile, $hasho);
|
||||||
|
$outfile;
|
||||||
|
}
|
||||||
|
|
||||||
|
sub lme2510c_s7395 {
|
||||||
|
my $sourcefile = "US2A0D.sys";
|
||||||
|
my $hash = "b0155a8083fb822a3bd47bc360e74601";
|
||||||
|
my $outfile = "dvb-usb-lme2510c-s7395.fw";
|
||||||
|
my $hasho = "3a3cf1aeebd17b6ddc04cebe131e94cf";
|
||||||
|
|
||||||
|
checkstandard();
|
||||||
|
|
||||||
|
verify($sourcefile, $hash);
|
||||||
|
extract($sourcefile, 37248, 3720, $outfile);
|
||||||
|
verify($outfile, $hasho);
|
||||||
|
$outfile;
|
||||||
|
}
|
||||||
|
|
||||||
|
sub lme2510c_s7395_old {
|
||||||
|
my $sourcefile = "LMEBDA_DVBS7395C.sys";
|
||||||
|
my $hash = "7572ae0eb9cdf91baabd7c0ba9e09b31";
|
||||||
|
my $outfile = "dvb-usb-lme2510c-s7395.fw";
|
||||||
|
my $hasho = "90430c5b435eb5c6f88fd44a9d950674";
|
||||||
|
|
||||||
|
checkstandard();
|
||||||
|
|
||||||
|
verify($sourcefile, $hash);
|
||||||
|
extract($sourcefile, 4208, 3881, $outfile);
|
||||||
|
verify($outfile, $hasho);
|
||||||
|
$outfile;
|
||||||
|
}
|
||||||
|
|
||||||
# ---------------------------------------------------------------
|
# ---------------------------------------------------------------
|
||||||
# Utilities
|
# Utilities
|
||||||
|
|
||||||
|
|
58
Documentation/dvb/lmedm04.txt
Normal file
58
Documentation/dvb/lmedm04.txt
Normal file
|
@ -0,0 +1,58 @@
|
||||||
|
To extract firmware for the DM04/QQBOX you need to copy the
|
||||||
|
following file(s) to this directory.
|
||||||
|
|
||||||
|
for DM04+/QQBOX LME2510C (Sharp 7395 Tuner)
|
||||||
|
-------------------------------------------
|
||||||
|
|
||||||
|
The Sharp 7395 driver can be found in windows/system32/driver
|
||||||
|
|
||||||
|
US2A0D.sys (dated 17 Mar 2009)
|
||||||
|
|
||||||
|
|
||||||
|
and run
|
||||||
|
./get_dvb_firmware lme2510c_s7395
|
||||||
|
|
||||||
|
will produce
|
||||||
|
dvb-usb-lme2510c-s7395.fw
|
||||||
|
|
||||||
|
An alternative but older firmware can be found on the driver
|
||||||
|
disk DVB-S_EN_3.5A in BDADriver/driver
|
||||||
|
|
||||||
|
LMEBDA_DVBS7395C.sys (dated 18 Jan 2008)
|
||||||
|
|
||||||
|
and run
|
||||||
|
./get_dvb_firmware lme2510c_s7395_old
|
||||||
|
|
||||||
|
will produce
|
||||||
|
dvb-usb-lme2510c-s7395.fw
|
||||||
|
|
||||||
|
--------------------------------------------------------------------
|
||||||
|
|
||||||
|
The LG firmware can be found on the driver
|
||||||
|
disk DM04+_5.1A[LG] in BDADriver/driver
|
||||||
|
|
||||||
|
for DM04 LME2510 (LG Tuner)
|
||||||
|
---------------------------
|
||||||
|
|
||||||
|
LMEBDA_DVBS.sys (dated 13 Nov 2007)
|
||||||
|
|
||||||
|
and run
|
||||||
|
./get_dvb_firmware lme2510_lg
|
||||||
|
|
||||||
|
will produce
|
||||||
|
dvb-usb-lme2510-lg.fw
|
||||||
|
|
||||||
|
|
||||||
|
Other LG firmware can be extracted manually from US280D.sys
|
||||||
|
only found in windows/system32/driver.
|
||||||
|
|
||||||
|
dd if=US280D.sys ibs=1 skip=42616 count=3668 of=dvb-usb-lme2510-lg.fw
|
||||||
|
|
||||||
|
for DM04 LME2510C (LG Tuner)
|
||||||
|
---------------------------
|
||||||
|
|
||||||
|
dd if=US280D.sys ibs=1 skip=35200 count=3850 of=dvb-usb-lme2510c-lg.fw
|
||||||
|
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
|
||||||
|
Copy the firmware file(s) to /lib/firmware
|
|
@ -196,7 +196,7 @@ csrow3.
|
||||||
The representation of the above is reflected in the directory tree
|
The representation of the above is reflected in the directory tree
|
||||||
in EDAC's sysfs interface. Starting in directory
|
in EDAC's sysfs interface. Starting in directory
|
||||||
/sys/devices/system/edac/mc each memory controller will be represented
|
/sys/devices/system/edac/mc each memory controller will be represented
|
||||||
by its own 'mcX' directory, where 'X" is the index of the MC.
|
by its own 'mcX' directory, where 'X' is the index of the MC.
|
||||||
|
|
||||||
|
|
||||||
..../edac/mc/
|
..../edac/mc/
|
||||||
|
@ -207,7 +207,7 @@ by its own 'mcX' directory, where 'X" is the index of the MC.
|
||||||
....
|
....
|
||||||
|
|
||||||
Under each 'mcX' directory each 'csrowX' is again represented by a
|
Under each 'mcX' directory each 'csrowX' is again represented by a
|
||||||
'csrowX', where 'X" is the csrow index:
|
'csrowX', where 'X' is the csrow index:
|
||||||
|
|
||||||
|
|
||||||
.../mc/mc0/
|
.../mc/mc0/
|
||||||
|
@ -232,7 +232,7 @@ EDAC control and attribute files.
|
||||||
|
|
||||||
|
|
||||||
In 'mcX' directories are EDAC control and attribute files for
|
In 'mcX' directories are EDAC control and attribute files for
|
||||||
this 'X" instance of the memory controllers:
|
this 'X' instance of the memory controllers:
|
||||||
|
|
||||||
|
|
||||||
Counter reset control file:
|
Counter reset control file:
|
||||||
|
@ -343,7 +343,7 @@ Sdram memory scrubbing rate:
|
||||||
'csrowX' DIRECTORIES
|
'csrowX' DIRECTORIES
|
||||||
|
|
||||||
In the 'csrowX' directories are EDAC control and attribute files for
|
In the 'csrowX' directories are EDAC control and attribute files for
|
||||||
this 'X" instance of csrow:
|
this 'X' instance of csrow:
|
||||||
|
|
||||||
|
|
||||||
Total Uncorrectable Errors count attribute file:
|
Total Uncorrectable Errors count attribute file:
|
||||||
|
|
|
@ -4,33 +4,41 @@ please mail me.
|
||||||
Geert Uytterhoeven <geert@linux-m68k.org>
|
Geert Uytterhoeven <geert@linux-m68k.org>
|
||||||
|
|
||||||
00-INDEX
|
00-INDEX
|
||||||
- this file
|
- this file.
|
||||||
arkfb.txt
|
arkfb.txt
|
||||||
- info on the fbdev driver for ARK Logic chips.
|
- info on the fbdev driver for ARK Logic chips.
|
||||||
aty128fb.txt
|
aty128fb.txt
|
||||||
- info on the ATI Rage128 frame buffer driver.
|
- info on the ATI Rage128 frame buffer driver.
|
||||||
cirrusfb.txt
|
cirrusfb.txt
|
||||||
- info on the driver for Cirrus Logic chipsets.
|
- info on the driver for Cirrus Logic chipsets.
|
||||||
|
cmap_xfbdev.txt
|
||||||
|
- an introduction to fbdev's cmap structures.
|
||||||
deferred_io.txt
|
deferred_io.txt
|
||||||
- an introduction to deferred IO.
|
- an introduction to deferred IO.
|
||||||
|
efifb.txt
|
||||||
|
- info on the EFI platform driver for Intel based Apple computers.
|
||||||
|
ep93xx-fb.txt
|
||||||
|
- info on the driver for EP93xx LCD controller.
|
||||||
fbcon.txt
|
fbcon.txt
|
||||||
- intro to and usage guide for the framebuffer console (fbcon).
|
- intro to and usage guide for the framebuffer console (fbcon).
|
||||||
framebuffer.txt
|
framebuffer.txt
|
||||||
- introduction to frame buffer devices.
|
- introduction to frame buffer devices.
|
||||||
imacfb.txt
|
gxfb.txt
|
||||||
- info on the generic EFI platform driver for Intel based Macs.
|
- info on the framebuffer driver for AMD Geode GX2 based processors.
|
||||||
intel810.txt
|
intel810.txt
|
||||||
- documentation for the Intel 810/815 framebuffer driver.
|
- documentation for the Intel 810/815 framebuffer driver.
|
||||||
intelfb.txt
|
intelfb.txt
|
||||||
- docs for Intel 830M/845G/852GM/855GM/865G/915G/945G fb driver.
|
- docs for Intel 830M/845G/852GM/855GM/865G/915G/945G fb driver.
|
||||||
internals.txt
|
internals.txt
|
||||||
- quick overview of frame buffer device internals.
|
- quick overview of frame buffer device internals.
|
||||||
|
lxfb.txt
|
||||||
|
- info on the framebuffer driver for AMD Geode LX based processors.
|
||||||
matroxfb.txt
|
matroxfb.txt
|
||||||
- info on the Matrox framebuffer driver for Alpha, Intel and PPC.
|
- info on the Matrox framebuffer driver for Alpha, Intel and PPC.
|
||||||
|
metronomefb.txt
|
||||||
|
- info on the driver for the Metronome display controller.
|
||||||
modedb.txt
|
modedb.txt
|
||||||
- info on the video mode database.
|
- info on the video mode database.
|
||||||
matroxfb.txt
|
|
||||||
- info on the Matrox frame buffer driver.
|
|
||||||
pvr2fb.txt
|
pvr2fb.txt
|
||||||
- info on the PowerVR 2 frame buffer driver.
|
- info on the PowerVR 2 frame buffer driver.
|
||||||
pxafb.txt
|
pxafb.txt
|
||||||
|
@ -39,13 +47,23 @@ s3fb.txt
|
||||||
- info on the fbdev driver for S3 Trio/Virge chips.
|
- info on the fbdev driver for S3 Trio/Virge chips.
|
||||||
sa1100fb.txt
|
sa1100fb.txt
|
||||||
- information about the driver for the SA-1100 LCD controller.
|
- information about the driver for the SA-1100 LCD controller.
|
||||||
|
sh7760fb.txt
|
||||||
|
- info on the SH7760/SH7763 integrated LCDC Framebuffer driver.
|
||||||
sisfb.txt
|
sisfb.txt
|
||||||
- info on the framebuffer device driver for various SiS chips.
|
- info on the framebuffer device driver for various SiS chips.
|
||||||
sstfb.txt
|
sstfb.txt
|
||||||
- info on the frame buffer driver for 3dfx' Voodoo Graphics boards.
|
- info on the frame buffer driver for 3dfx' Voodoo Graphics boards.
|
||||||
tgafb.txt
|
tgafb.txt
|
||||||
- info on the TGA (DECChip 21030) frame buffer driver
|
- info on the TGA (DECChip 21030) frame buffer driver.
|
||||||
|
tridentfb.txt
|
||||||
|
info on the framebuffer driver for some Trident chip based cards.
|
||||||
|
uvesafb.txt
|
||||||
|
- info on the userspace VESA (VBE2+ compliant) frame buffer device.
|
||||||
vesafb.txt
|
vesafb.txt
|
||||||
- info on the VESA frame buffer device
|
- info on the VESA frame buffer device.
|
||||||
|
viafb.modes
|
||||||
|
- list of modes for VIA Integration Graphic Chip.
|
||||||
|
viafb.txt
|
||||||
|
- info on the VIA Integration Graphic Chip console framebuffer driver.
|
||||||
vt8623fb.txt
|
vt8623fb.txt
|
||||||
- info on the fb driver for the graphics core in VIA VT8623 chipsets.
|
- info on the fb driver for the graphics core in VIA VT8623 chipsets.
|
||||||
|
|
|
@ -197,6 +197,54 @@ Notes:
|
||||||
example,
|
example,
|
||||||
# fbset -depth 16
|
# fbset -depth 16
|
||||||
|
|
||||||
|
|
||||||
|
[Configure viafb via /proc]
|
||||||
|
---------------------------
|
||||||
|
The following files exist in /proc/viafb
|
||||||
|
|
||||||
|
supported_output_devices
|
||||||
|
|
||||||
|
This read-only file contains a full ',' seperated list containing all
|
||||||
|
output devices that could be available on your platform. It is likely
|
||||||
|
that not all of those have a connector on your hardware but it should
|
||||||
|
provide a good starting point to figure out which of those names match
|
||||||
|
a real connector.
|
||||||
|
Example:
|
||||||
|
# cat /proc/viafb/supported_output_devices
|
||||||
|
|
||||||
|
iga1/output_devices
|
||||||
|
iga2/output_devices
|
||||||
|
|
||||||
|
These two files are readable and writable. iga1 and iga2 are the two
|
||||||
|
independent units that produce the screen image. Those images can be
|
||||||
|
forwarded to one or more output devices. Reading those files is a way
|
||||||
|
to query which output devices are currently used by an iga.
|
||||||
|
Example:
|
||||||
|
# cat /proc/viafb/iga1/output_devices
|
||||||
|
If there are no output devices printed the output of this iga is lost.
|
||||||
|
This can happen for example if only one (the other) iga is used.
|
||||||
|
Writing to these files allows adjusting the output devices during
|
||||||
|
runtime. One can add new devices, remove existing ones or switch
|
||||||
|
between igas. Essentially you can write a ',' seperated list of device
|
||||||
|
names (or a single one) in the same format as the output to those
|
||||||
|
files. You can add a '+' or '-' as a prefix allowing simple addition
|
||||||
|
and removal of devices. So a prefix '+' adds the devices from your list
|
||||||
|
to the already existing ones, '-' removes the listed devices from the
|
||||||
|
existing ones and if no prefix is given it replaces all existing ones
|
||||||
|
with the listed ones. If you remove devices they are expected to turn
|
||||||
|
off. If you add devices that are already part of the other iga they are
|
||||||
|
removed there and added to the new one.
|
||||||
|
Examples:
|
||||||
|
Add CRT as output device to iga1
|
||||||
|
# echo +CRT > /proc/viafb/iga1/output_devices
|
||||||
|
|
||||||
|
Remove (turn off) DVP1 and LVDS1 as output devices of iga2
|
||||||
|
# echo -DVP1,LVDS1 > /proc/viafb/iga2/output_devices
|
||||||
|
|
||||||
|
Replace all iga1 output devices by CRT
|
||||||
|
# echo CRT > /proc/viafb/iga1/output_devices
|
||||||
|
|
||||||
|
|
||||||
[Bootup with viafb]:
|
[Bootup with viafb]:
|
||||||
--------------------
|
--------------------
|
||||||
Add the following line to your grub.conf:
|
Add the following line to your grub.conf:
|
||||||
|
|
|
@ -98,7 +98,7 @@ Who: Pavel Machek <pavel@ucw.cz>
|
||||||
---------------------------
|
---------------------------
|
||||||
|
|
||||||
What: Video4Linux API 1 ioctls and from Video devices.
|
What: Video4Linux API 1 ioctls and from Video devices.
|
||||||
When: July 2009
|
When: kernel 2.6.38
|
||||||
Files: include/linux/videodev.h
|
Files: include/linux/videodev.h
|
||||||
Check: include/linux/videodev.h
|
Check: include/linux/videodev.h
|
||||||
Why: V4L1 AP1 was replaced by V4L2 API during migration from 2.4 to 2.6
|
Why: V4L1 AP1 was replaced by V4L2 API during migration from 2.4 to 2.6
|
||||||
|
@ -116,6 +116,21 @@ Who: Mauro Carvalho Chehab <mchehab@infradead.org>
|
||||||
|
|
||||||
---------------------------
|
---------------------------
|
||||||
|
|
||||||
|
What: Video4Linux obsolete drivers using V4L1 API
|
||||||
|
When: kernel 2.6.38
|
||||||
|
Files: drivers/staging/cpia/* drivers/staging/stradis/*
|
||||||
|
Check: drivers/staging/cpia/cpia.c drivers/staging/stradis/stradis.c
|
||||||
|
Why: There are some drivers still using V4L1 API, despite all efforts we've done
|
||||||
|
to migrate. Those drivers are for obsolete hardware that the old maintainer
|
||||||
|
didn't care (or not have the hardware anymore), and that no other developer
|
||||||
|
could find any hardware to buy. They probably have no practical usage today,
|
||||||
|
and people with such old hardware could probably keep using an older version
|
||||||
|
of the kernel. Those drivers will be moved to staging on 2.6.37 and, if nobody
|
||||||
|
care enough to port and test them with V4L2 API, they'll be removed on 2.6.38.
|
||||||
|
Who: Mauro Carvalho Chehab <mchehab@infradead.org>
|
||||||
|
|
||||||
|
---------------------------
|
||||||
|
|
||||||
What: sys_sysctl
|
What: sys_sysctl
|
||||||
When: September 2010
|
When: September 2010
|
||||||
Option: CONFIG_SYSCTL_SYSCALL
|
Option: CONFIG_SYSCTL_SYSCALL
|
||||||
|
@ -470,29 +485,6 @@ When: April 2011
|
||||||
Why: Superseded by xt_CT
|
Why: Superseded by xt_CT
|
||||||
Who: Netfilter developer team <netfilter-devel@vger.kernel.org>
|
Who: Netfilter developer team <netfilter-devel@vger.kernel.org>
|
||||||
|
|
||||||
---------------------------
|
|
||||||
|
|
||||||
What: video4linux /dev/vtx teletext API support
|
|
||||||
When: 2.6.35
|
|
||||||
Files: drivers/media/video/saa5246a.c drivers/media/video/saa5249.c
|
|
||||||
include/linux/videotext.h
|
|
||||||
Why: The vtx device nodes have been superseded by vbi device nodes
|
|
||||||
for many years. No applications exist that use the vtx support.
|
|
||||||
Of the two i2c drivers that actually support this API the saa5249
|
|
||||||
has been impossible to use for a year now and no known hardware
|
|
||||||
that supports this device exists. The saa5246a is theoretically
|
|
||||||
supported by the old mxb boards, but it never actually worked.
|
|
||||||
|
|
||||||
In summary: there is no hardware that can use this API and there
|
|
||||||
are no applications actually implementing this API.
|
|
||||||
|
|
||||||
The vtx support still reserves minors 192-223 and we would really
|
|
||||||
like to reuse those for upcoming new functionality. In the unlikely
|
|
||||||
event that new hardware appears that wants to use the functionality
|
|
||||||
provided by the vtx API, then that functionality should be build
|
|
||||||
around the sliced VBI API instead.
|
|
||||||
Who: Hans Verkuil <hverkuil@xs4all.nl>
|
|
||||||
|
|
||||||
----------------------------
|
----------------------------
|
||||||
|
|
||||||
What: IRQF_DISABLED
|
What: IRQF_DISABLED
|
||||||
|
@ -502,16 +494,6 @@ Who: Thomas Gleixner <tglx@linutronix.de>
|
||||||
|
|
||||||
----------------------------
|
----------------------------
|
||||||
|
|
||||||
What: old ieee1394 subsystem (CONFIG_IEEE1394)
|
|
||||||
When: 2.6.37
|
|
||||||
Files: drivers/ieee1394/ except init_ohci1394_dma.c
|
|
||||||
Why: superseded by drivers/firewire/ (CONFIG_FIREWIRE) which offers more
|
|
||||||
features, better performance, and better security, all with smaller
|
|
||||||
and more modern code base
|
|
||||||
Who: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
||||||
|
|
||||||
----------------------------
|
|
||||||
|
|
||||||
What: The acpi_sleep=s4_nonvs command line option
|
What: The acpi_sleep=s4_nonvs command line option
|
||||||
When: 2.6.37
|
When: 2.6.37
|
||||||
Files: arch/x86/kernel/acpi/sleep.c
|
Files: arch/x86/kernel/acpi/sleep.c
|
||||||
|
@ -536,6 +518,23 @@ Who: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
|
||||||
|
|
||||||
----------------------------
|
----------------------------
|
||||||
|
|
||||||
|
What: namespace cgroup (ns_cgroup)
|
||||||
|
When: 2.6.38
|
||||||
|
Why: The ns_cgroup leads to some problems:
|
||||||
|
* cgroup creation is out-of-control
|
||||||
|
* cgroup name can conflict when pids are looping
|
||||||
|
* it is not possible to have a single process handling
|
||||||
|
a lot of namespaces without falling in a exponential creation time
|
||||||
|
* we may want to create a namespace without creating a cgroup
|
||||||
|
|
||||||
|
The ns_cgroup is replaced by a compatibility flag 'clone_children',
|
||||||
|
where a newly created cgroup will copy the parent cgroup values.
|
||||||
|
The userspace has to manually create a cgroup and add a task to
|
||||||
|
the 'tasks' file.
|
||||||
|
Who: Daniel Lezcano <daniel.lezcano@free.fr>
|
||||||
|
|
||||||
|
----------------------------
|
||||||
|
|
||||||
What: iwlwifi disable_hw_scan module parameters
|
What: iwlwifi disable_hw_scan module parameters
|
||||||
When: 2.6.40
|
When: 2.6.40
|
||||||
Why: Hareware scan is the prefer method for iwlwifi devices for
|
Why: Hareware scan is the prefer method for iwlwifi devices for
|
||||||
|
@ -545,3 +544,23 @@ Why: Hareware scan is the prefer method for iwlwifi devices for
|
||||||
Who: Wey-Yi Guy <wey-yi.w.guy@intel.com>
|
Who: Wey-Yi Guy <wey-yi.w.guy@intel.com>
|
||||||
|
|
||||||
----------------------------
|
----------------------------
|
||||||
|
|
||||||
|
What: access to nfsd auth cache through sys_nfsservctl or '.' files
|
||||||
|
in the 'nfsd' filesystem.
|
||||||
|
When: 2.6.40
|
||||||
|
Why: This is a legacy interface which have been replaced by a more
|
||||||
|
dynamic cache. Continuing to maintain this interface is an
|
||||||
|
unnecessary burden.
|
||||||
|
Who: NeilBrown <neilb@suse.de>
|
||||||
|
|
||||||
|
----------------------------
|
||||||
|
|
||||||
|
What: i2c_adapter.id
|
||||||
|
When: June 2011
|
||||||
|
Why: This field is deprecated. I2C device drivers shouldn't change their
|
||||||
|
behavior based on the underlying I2C adapter. Instead, the I2C
|
||||||
|
adapter driver should instantiate the I2C devices and provide the
|
||||||
|
needed platform-specific information.
|
||||||
|
Who: Jean Delvare <khali@linux-fr.org>
|
||||||
|
|
||||||
|
----------------------------
|
||||||
|
|
|
@ -96,8 +96,6 @@ seq_file.txt
|
||||||
- how to use the seq_file API
|
- how to use the seq_file API
|
||||||
sharedsubtree.txt
|
sharedsubtree.txt
|
||||||
- a description of shared subtrees for namespaces.
|
- a description of shared subtrees for namespaces.
|
||||||
smbfs.txt
|
|
||||||
- info on using filesystems with the SMB protocol (Win 3.11 and NT).
|
|
||||||
spufs.txt
|
spufs.txt
|
||||||
- info and mount options for the SPU filesystem used on Cell.
|
- info and mount options for the SPU filesystem used on Cell.
|
||||||
sysfs-pci.txt
|
sysfs-pci.txt
|
||||||
|
|
|
@ -111,7 +111,7 @@ OPTIONS
|
||||||
This can be used to share devices/named pipes/sockets between
|
This can be used to share devices/named pipes/sockets between
|
||||||
hosts. This functionality will be expanded in later versions.
|
hosts. This functionality will be expanded in later versions.
|
||||||
|
|
||||||
access there are three access modes.
|
access there are four access modes.
|
||||||
user = if a user tries to access a file on v9fs
|
user = if a user tries to access a file on v9fs
|
||||||
filesystem for the first time, v9fs sends an
|
filesystem for the first time, v9fs sends an
|
||||||
attach command (Tattach) for that user.
|
attach command (Tattach) for that user.
|
||||||
|
@ -120,6 +120,8 @@ OPTIONS
|
||||||
the files on the mounted filesystem
|
the files on the mounted filesystem
|
||||||
any = v9fs does single attach and performs all
|
any = v9fs does single attach and performs all
|
||||||
operations as one user
|
operations as one user
|
||||||
|
client = ACL based access check on the 9p client
|
||||||
|
side for access validation
|
||||||
|
|
||||||
cachetag cache tag to use the specified persistent cache.
|
cachetag cache tag to use the specified persistent cache.
|
||||||
cache tags for existing cache sessions can be listed at
|
cache tags for existing cache sessions can be listed at
|
||||||
|
|
|
@ -322,7 +322,6 @@ fl_release_private: yes yes
|
||||||
prototypes:
|
prototypes:
|
||||||
int (*fl_compare_owner)(struct file_lock *, struct file_lock *);
|
int (*fl_compare_owner)(struct file_lock *, struct file_lock *);
|
||||||
void (*fl_notify)(struct file_lock *); /* unblock callback */
|
void (*fl_notify)(struct file_lock *); /* unblock callback */
|
||||||
void (*fl_copy_lock)(struct file_lock *, struct file_lock *);
|
|
||||||
void (*fl_release_private)(struct file_lock *);
|
void (*fl_release_private)(struct file_lock *);
|
||||||
void (*fl_break)(struct file_lock *); /* break_lease callback */
|
void (*fl_break)(struct file_lock *); /* break_lease callback */
|
||||||
|
|
||||||
|
@ -330,7 +329,6 @@ locking rules:
|
||||||
BKL may block
|
BKL may block
|
||||||
fl_compare_owner: yes no
|
fl_compare_owner: yes no
|
||||||
fl_notify: yes no
|
fl_notify: yes no
|
||||||
fl_copy_lock: yes no
|
|
||||||
fl_release_private: yes yes
|
fl_release_private: yes yes
|
||||||
fl_break: yes no
|
fl_break: yes no
|
||||||
|
|
||||||
|
@ -349,21 +347,36 @@ call this method upon the IO completion.
|
||||||
|
|
||||||
--------------------------- block_device_operations -----------------------
|
--------------------------- block_device_operations -----------------------
|
||||||
prototypes:
|
prototypes:
|
||||||
int (*open) (struct inode *, struct file *);
|
int (*open) (struct block_device *, fmode_t);
|
||||||
int (*release) (struct inode *, struct file *);
|
int (*release) (struct gendisk *, fmode_t);
|
||||||
int (*ioctl) (struct inode *, struct file *, unsigned, unsigned long);
|
int (*ioctl) (struct block_device *, fmode_t, unsigned, unsigned long);
|
||||||
|
int (*compat_ioctl) (struct block_device *, fmode_t, unsigned, unsigned long);
|
||||||
|
int (*direct_access) (struct block_device *, sector_t, void **, unsigned long *);
|
||||||
int (*media_changed) (struct gendisk *);
|
int (*media_changed) (struct gendisk *);
|
||||||
|
void (*unlock_native_capacity) (struct gendisk *);
|
||||||
int (*revalidate_disk) (struct gendisk *);
|
int (*revalidate_disk) (struct gendisk *);
|
||||||
|
int (*getgeo)(struct block_device *, struct hd_geometry *);
|
||||||
|
void (*swap_slot_free_notify) (struct block_device *, unsigned long);
|
||||||
|
|
||||||
locking rules:
|
locking rules:
|
||||||
BKL bd_sem
|
BKL bd_mutex
|
||||||
open: yes yes
|
open: no yes
|
||||||
release: yes yes
|
release: no yes
|
||||||
ioctl: yes no
|
ioctl: no no
|
||||||
|
compat_ioctl: no no
|
||||||
|
direct_access: no no
|
||||||
media_changed: no no
|
media_changed: no no
|
||||||
|
unlock_native_capacity: no no
|
||||||
revalidate_disk: no no
|
revalidate_disk: no no
|
||||||
|
getgeo: no no
|
||||||
|
swap_slot_free_notify: no no (see below)
|
||||||
|
|
||||||
|
media_changed, unlock_native_capacity and revalidate_disk are called only from
|
||||||
|
check_disk_change().
|
||||||
|
|
||||||
|
swap_slot_free_notify is called with swap_lock and sometimes the page lock
|
||||||
|
held.
|
||||||
|
|
||||||
The last two are called only from check_disk_change().
|
|
||||||
|
|
||||||
--------------------------- file_operations -------------------------------
|
--------------------------- file_operations -------------------------------
|
||||||
prototypes:
|
prototypes:
|
||||||
|
|
|
@ -89,7 +89,7 @@ static ssize_t childless_storeme_write(struct childless *childless,
|
||||||
char *p = (char *) page;
|
char *p = (char *) page;
|
||||||
|
|
||||||
tmp = simple_strtoul(p, &p, 10);
|
tmp = simple_strtoul(p, &p, 10);
|
||||||
if (!p || (*p && (*p != '\n')))
|
if ((*p != '\0') && (*p != '\n'))
|
||||||
return -EINVAL;
|
return -EINVAL;
|
||||||
|
|
||||||
if (tmp > INT_MAX)
|
if (tmp > INT_MAX)
|
||||||
|
|
|
@ -353,6 +353,20 @@ noauto_da_alloc replacing existing files via patterns such as
|
||||||
system crashes before the delayed allocation
|
system crashes before the delayed allocation
|
||||||
blocks are forced to disk.
|
blocks are forced to disk.
|
||||||
|
|
||||||
|
noinit_itable Do not initialize any uninitialized inode table
|
||||||
|
blocks in the background. This feature may be
|
||||||
|
used by installation CD's so that the install
|
||||||
|
process can complete as quickly as possible; the
|
||||||
|
inode table initialization process would then be
|
||||||
|
deferred until the next time the file system
|
||||||
|
is unmounted.
|
||||||
|
|
||||||
|
init_itable=n The lazy itable init code will wait n times the
|
||||||
|
number of milliseconds it took to zero out the
|
||||||
|
previous block group's inode table. This
|
||||||
|
minimizes the impact on the systme performance
|
||||||
|
while file system's inode table is being initialized.
|
||||||
|
|
||||||
discard Controls whether ext4 should issue discard/TRIM
|
discard Controls whether ext4 should issue discard/TRIM
|
||||||
nodiscard(*) commands to the underlying block device when
|
nodiscard(*) commands to the underlying block device when
|
||||||
blocks are freed. This is useful for SSD devices
|
blocks are freed. This is useful for SSD devices
|
||||||
|
|
|
@ -12,5 +12,9 @@ nfs-rdma.txt
|
||||||
- how to install and setup the Linux NFS/RDMA client and server software
|
- how to install and setup the Linux NFS/RDMA client and server software
|
||||||
nfsroot.txt
|
nfsroot.txt
|
||||||
- short guide on setting up a diskless box with NFS root filesystem.
|
- short guide on setting up a diskless box with NFS root filesystem.
|
||||||
|
pnfs.txt
|
||||||
|
- short explanation of some of the internals of the pnfs client code
|
||||||
rpc-cache.txt
|
rpc-cache.txt
|
||||||
- introduction to the caching mechanisms in the sunrpc layer.
|
- introduction to the caching mechanisms in the sunrpc layer.
|
||||||
|
idmapper.txt
|
||||||
|
- information for configuring request-keys to be used by idmapper
|
||||||
|
|
67
Documentation/filesystems/nfs/idmapper.txt
Normal file
67
Documentation/filesystems/nfs/idmapper.txt
Normal file
|
@ -0,0 +1,67 @@
|
||||||
|
|
||||||
|
=========
|
||||||
|
ID Mapper
|
||||||
|
=========
|
||||||
|
Id mapper is used by NFS to translate user and group ids into names, and to
|
||||||
|
translate user and group names into ids. Part of this translation involves
|
||||||
|
performing an upcall to userspace to request the information. Id mapper will
|
||||||
|
user request-key to perform this upcall and cache the result. The program
|
||||||
|
/usr/sbin/nfs.idmap should be called by request-key, and will perform the
|
||||||
|
translation and initialize a key with the resulting information.
|
||||||
|
|
||||||
|
NFS_USE_NEW_IDMAPPER must be selected when configuring the kernel to use this
|
||||||
|
feature.
|
||||||
|
|
||||||
|
===========
|
||||||
|
Configuring
|
||||||
|
===========
|
||||||
|
The file /etc/request-key.conf will need to be modified so /sbin/request-key can
|
||||||
|
direct the upcall. The following line should be added:
|
||||||
|
|
||||||
|
#OP TYPE DESCRIPTION CALLOUT INFO PROGRAM ARG1 ARG2 ARG3 ...
|
||||||
|
#====== ======= =============== =============== ===============================
|
||||||
|
create id_resolver * * /usr/sbin/nfs.idmap %k %d 600
|
||||||
|
|
||||||
|
This will direct all id_resolver requests to the program /usr/sbin/nfs.idmap.
|
||||||
|
The last parameter, 600, defines how many seconds into the future the key will
|
||||||
|
expire. This parameter is optional for /usr/sbin/nfs.idmap. When the timeout
|
||||||
|
is not specified, nfs.idmap will default to 600 seconds.
|
||||||
|
|
||||||
|
id mapper uses for key descriptions:
|
||||||
|
uid: Find the UID for the given user
|
||||||
|
gid: Find the GID for the given group
|
||||||
|
user: Find the user name for the given UID
|
||||||
|
group: Find the group name for the given GID
|
||||||
|
|
||||||
|
You can handle any of these individually, rather than using the generic upcall
|
||||||
|
program. If you would like to use your own program for a uid lookup then you
|
||||||
|
would edit your request-key.conf so it look similar to this:
|
||||||
|
|
||||||
|
#OP TYPE DESCRIPTION CALLOUT INFO PROGRAM ARG1 ARG2 ARG3 ...
|
||||||
|
#====== ======= =============== =============== ===============================
|
||||||
|
create id_resolver uid:* * /some/other/program %k %d 600
|
||||||
|
create id_resolver * * /usr/sbin/nfs.idmap %k %d 600
|
||||||
|
|
||||||
|
Notice that the new line was added above the line for the generic program.
|
||||||
|
request-key will find the first matching line and corresponding program. In
|
||||||
|
this case, /some/other/program will handle all uid lookups and
|
||||||
|
/usr/sbin/nfs.idmap will handle gid, user, and group lookups.
|
||||||
|
|
||||||
|
See <file:Documentation/keys-request-keys.txt> for more information about the
|
||||||
|
request-key function.
|
||||||
|
|
||||||
|
|
||||||
|
=========
|
||||||
|
nfs.idmap
|
||||||
|
=========
|
||||||
|
nfs.idmap is designed to be called by request-key, and should not be run "by
|
||||||
|
hand". This program takes two arguments, a serialized key and a key
|
||||||
|
description. The serialized key is first converted into a key_serial_t, and
|
||||||
|
then passed as an argument to keyctl_instantiate (both are part of keyutils.h).
|
||||||
|
|
||||||
|
The actual lookups are performed by functions found in nfsidmap.h. nfs.idmap
|
||||||
|
determines the correct function to call by looking at the first part of the
|
||||||
|
description string. For example, a uid lookup description will appear as
|
||||||
|
"uid:user@domain".
|
||||||
|
|
||||||
|
nfs.idmap will return 0 if the key was instantiated, and non-zero otherwise.
|
|
@ -159,6 +159,28 @@ ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>
|
||||||
Default: any
|
Default: any
|
||||||
|
|
||||||
|
|
||||||
|
nfsrootdebug
|
||||||
|
|
||||||
|
This parameter enables debugging messages to appear in the kernel
|
||||||
|
log at boot time so that administrators can verify that the correct
|
||||||
|
NFS mount options, server address, and root path are passed to the
|
||||||
|
NFS client.
|
||||||
|
|
||||||
|
|
||||||
|
rdinit=<executable file>
|
||||||
|
|
||||||
|
To specify which file contains the program that starts system
|
||||||
|
initialization, administrators can use this command line parameter.
|
||||||
|
The default value of this parameter is "/init". If the specified
|
||||||
|
file exists and the kernel can execute it, root filesystem related
|
||||||
|
kernel command line parameters, including `nfsroot=', are ignored.
|
||||||
|
|
||||||
|
A description of the process of mounting the root file system can be
|
||||||
|
found in:
|
||||||
|
|
||||||
|
Documentation/early-userspace/README
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
3.) Boot Loader
|
3.) Boot Loader
|
||||||
|
|
48
Documentation/filesystems/nfs/pnfs.txt
Normal file
48
Documentation/filesystems/nfs/pnfs.txt
Normal file
|
@ -0,0 +1,48 @@
|
||||||
|
Reference counting in pnfs:
|
||||||
|
==========================
|
||||||
|
|
||||||
|
The are several inter-related caches. We have layouts which can
|
||||||
|
reference multiple devices, each of which can reference multiple data servers.
|
||||||
|
Each data server can be referenced by multiple devices. Each device
|
||||||
|
can be referenced by multiple layouts. To keep all of this straight,
|
||||||
|
we need to reference count.
|
||||||
|
|
||||||
|
|
||||||
|
struct pnfs_layout_hdr
|
||||||
|
----------------------
|
||||||
|
The on-the-wire command LAYOUTGET corresponds to struct
|
||||||
|
pnfs_layout_segment, usually referred to by the variable name lseg.
|
||||||
|
Each nfs_inode may hold a pointer to a cache of of these layout
|
||||||
|
segments in nfsi->layout, of type struct pnfs_layout_hdr.
|
||||||
|
|
||||||
|
We reference the header for the inode pointing to it, across each
|
||||||
|
outstanding RPC call that references it (LAYOUTGET, LAYOUTRETURN,
|
||||||
|
LAYOUTCOMMIT), and for each lseg held within.
|
||||||
|
|
||||||
|
Each header is also (when non-empty) put on a list associated with
|
||||||
|
struct nfs_client (cl_layouts). Being put on this list does not bump
|
||||||
|
the reference count, as the layout is kept around by the lseg that
|
||||||
|
keeps it in the list.
|
||||||
|
|
||||||
|
deviceid_cache
|
||||||
|
--------------
|
||||||
|
lsegs reference device ids, which are resolved per nfs_client and
|
||||||
|
layout driver type. The device ids are held in a RCU cache (struct
|
||||||
|
nfs4_deviceid_cache). The cache itself is referenced across each
|
||||||
|
mount. The entries (struct nfs4_deviceid) themselves are held across
|
||||||
|
the lifetime of each lseg referencing them.
|
||||||
|
|
||||||
|
RCU is used because the deviceid is basically a write once, read many
|
||||||
|
data structure. The hlist size of 32 buckets needs better
|
||||||
|
justification, but seems reasonable given that we can have multiple
|
||||||
|
deviceid's per filesystem, and multiple filesystems per nfs_client.
|
||||||
|
|
||||||
|
The hash code is copied from the nfsd code base. A discussion of
|
||||||
|
hashing and variations of this algorithm can be found at:
|
||||||
|
http://groups.google.com/group/comp.lang.c/browse_thread/thread/9522965e2b8d3809
|
||||||
|
|
||||||
|
data server cache
|
||||||
|
-----------------
|
||||||
|
file driver devices refer to data servers, which are kept in a module
|
||||||
|
level cache. Its reference is held over the lifetime of the deviceid
|
||||||
|
pointing to it.
|
|
@ -136,6 +136,7 @@ Table 1-1: Process specific entries in /proc
|
||||||
statm Process memory status information
|
statm Process memory status information
|
||||||
status Process status in human readable form
|
status Process status in human readable form
|
||||||
wchan If CONFIG_KALLSYMS is set, a pre-decoded wchan
|
wchan If CONFIG_KALLSYMS is set, a pre-decoded wchan
|
||||||
|
pagemap Page table
|
||||||
stack Report full stack trace, enable via CONFIG_STACKTRACE
|
stack Report full stack trace, enable via CONFIG_STACKTRACE
|
||||||
smaps a extension based on maps, showing the memory consumption of
|
smaps a extension based on maps, showing the memory consumption of
|
||||||
each mapping
|
each mapping
|
||||||
|
@ -370,17 +371,24 @@ Shared_Dirty: 0 kB
|
||||||
Private_Clean: 0 kB
|
Private_Clean: 0 kB
|
||||||
Private_Dirty: 0 kB
|
Private_Dirty: 0 kB
|
||||||
Referenced: 892 kB
|
Referenced: 892 kB
|
||||||
|
Anonymous: 0 kB
|
||||||
Swap: 0 kB
|
Swap: 0 kB
|
||||||
KernelPageSize: 4 kB
|
KernelPageSize: 4 kB
|
||||||
MMUPageSize: 4 kB
|
MMUPageSize: 4 kB
|
||||||
|
|
||||||
The first of these lines shows the same information as is displayed for the
|
The first of these lines shows the same information as is displayed for the
|
||||||
mapping in /proc/PID/maps. The remaining lines show the size of the mapping,
|
mapping in /proc/PID/maps. The remaining lines show the size of the mapping
|
||||||
the amount of the mapping that is currently resident in RAM, the "proportional
|
(size), the amount of the mapping that is currently resident in RAM (RSS), the
|
||||||
set size” (divide each shared page by the number of processes sharing it), the
|
process' proportional share of this mapping (PSS), the number of clean and
|
||||||
number of clean and dirty shared pages in the mapping, and the number of clean
|
dirty private pages in the mapping. Note that even a page which is part of a
|
||||||
and dirty private pages in the mapping. The "Referenced" indicates the amount
|
MAP_SHARED mapping, but has only a single pte mapped, i.e. is currently used
|
||||||
of memory currently marked as referenced or accessed.
|
by only one process, is accounted as private and not as shared. "Referenced"
|
||||||
|
indicates the amount of memory currently marked as referenced or accessed.
|
||||||
|
"Anonymous" shows the amount of memory that does not belong to any file. Even
|
||||||
|
a mapping associated with a file may contain anonymous pages: when MAP_PRIVATE
|
||||||
|
and a page is modified, the file page is replaced by a private anonymous copy.
|
||||||
|
"Swap" shows how much would-be-anonymous memory is also used, but out on
|
||||||
|
swap.
|
||||||
|
|
||||||
This file is only present if the CONFIG_MMU kernel configuration option is
|
This file is only present if the CONFIG_MMU kernel configuration option is
|
||||||
enabled.
|
enabled.
|
||||||
|
@ -397,6 +405,9 @@ To clear the bits for the file mapped pages associated with the process
|
||||||
> echo 3 > /proc/PID/clear_refs
|
> echo 3 > /proc/PID/clear_refs
|
||||||
Any other value written to /proc/PID/clear_refs will have no effect.
|
Any other value written to /proc/PID/clear_refs will have no effect.
|
||||||
|
|
||||||
|
The /proc/pid/pagemap gives the PFN, which can be used to find the pageflags
|
||||||
|
using /proc/kpageflags and number of times a page is mapped using
|
||||||
|
/proc/kpagecount. For detailed explanation, see Documentation/vm/pagemap.txt.
|
||||||
|
|
||||||
1.2 Kernel data
|
1.2 Kernel data
|
||||||
---------------
|
---------------
|
||||||
|
|
|
@ -62,10 +62,10 @@ replicas continue to be exactly same.
|
||||||
# mount /dev/sd0 /tmp/a
|
# mount /dev/sd0 /tmp/a
|
||||||
|
|
||||||
#ls /tmp/a
|
#ls /tmp/a
|
||||||
t1 t2 t2
|
t1 t2 t3
|
||||||
|
|
||||||
#ls /mnt/a
|
#ls /mnt/a
|
||||||
t1 t2 t2
|
t1 t2 t3
|
||||||
|
|
||||||
Note that the mount has propagated to the mount at /mnt as well.
|
Note that the mount has propagated to the mount at /mnt as well.
|
||||||
|
|
||||||
|
|
|
@ -660,11 +660,10 @@ struct address_space_operations {
|
||||||
releasepage: releasepage is called on PagePrivate pages to indicate
|
releasepage: releasepage is called on PagePrivate pages to indicate
|
||||||
that the page should be freed if possible. ->releasepage
|
that the page should be freed if possible. ->releasepage
|
||||||
should remove any private data from the page and clear the
|
should remove any private data from the page and clear the
|
||||||
PagePrivate flag. It may also remove the page from the
|
PagePrivate flag. If releasepage() fails for some reason, it must
|
||||||
address_space. If this fails for some reason, it may indicate
|
indicate failure with a 0 return value.
|
||||||
failure with a 0 return value.
|
releasepage() is used in two distinct though related cases. The
|
||||||
This is used in two distinct though related cases. The first
|
first is when the VM finds a clean page with no active users and
|
||||||
is when the VM finds a clean page with no active users and
|
|
||||||
wants to make it a free page. If ->releasepage succeeds, the
|
wants to make it a free page. If ->releasepage succeeds, the
|
||||||
page will be removed from the address_space and become free.
|
page will be removed from the address_space and become free.
|
||||||
|
|
||||||
|
|
|
@ -794,17 +794,6 @@ designed.
|
||||||
|
|
||||||
Roadmap:
|
Roadmap:
|
||||||
|
|
||||||
2.6.37 Remove experimental tag from mount option
|
|
||||||
=> should be roughly 6 months after initial merge
|
|
||||||
=> enough time to:
|
|
||||||
=> gain confidence and fix problems reported by early
|
|
||||||
adopters (a.k.a. guinea pigs)
|
|
||||||
=> address worst performance regressions and undesired
|
|
||||||
behaviours
|
|
||||||
=> start tuning/optimising code for parallelism
|
|
||||||
=> start tuning/optimising algorithms consuming
|
|
||||||
excessive CPU time
|
|
||||||
|
|
||||||
2.6.39 Switch default mount option to use delayed logging
|
2.6.39 Switch default mount option to use delayed logging
|
||||||
=> should be roughly 12 months after initial merge
|
=> should be roughly 12 months after initial merge
|
||||||
=> enough time to shake out remaining problems before next round of
|
=> enough time to shake out remaining problems before next round of
|
||||||
|
|
|
@ -617,6 +617,16 @@ and have the following read/write attributes:
|
||||||
is configured as an output, this value may be written;
|
is configured as an output, this value may be written;
|
||||||
any nonzero value is treated as high.
|
any nonzero value is treated as high.
|
||||||
|
|
||||||
|
If the pin can be configured as interrupt-generating interrupt
|
||||||
|
and if it has been configured to generate interrupts (see the
|
||||||
|
description of "edge"), you can poll(2) on that file and
|
||||||
|
poll(2) will return whenever the interrupt was triggered. If
|
||||||
|
you use poll(2), set the events POLLPRI and POLLERR. If you
|
||||||
|
use select(2), set the file descriptor in exceptfds. After
|
||||||
|
poll(2) returns, either lseek(2) to the beginning of the sysfs
|
||||||
|
file and read the new value or close the file and re-open it
|
||||||
|
to read the value.
|
||||||
|
|
||||||
"edge" ... reads as either "none", "rising", "falling", or
|
"edge" ... reads as either "none", "rising", "falling", or
|
||||||
"both". Write these strings to select the signal edge(s)
|
"both". Write these strings to select the signal edge(s)
|
||||||
that will make poll(2) on the "value" file return.
|
that will make poll(2) on the "value" file return.
|
||||||
|
|
|
@ -22,6 +22,10 @@ Supported chips:
|
||||||
Prefix: 'it8720'
|
Prefix: 'it8720'
|
||||||
Addresses scanned: from Super I/O config space (8 I/O ports)
|
Addresses scanned: from Super I/O config space (8 I/O ports)
|
||||||
Datasheet: Not publicly available
|
Datasheet: Not publicly available
|
||||||
|
* IT8721F/IT8758E
|
||||||
|
Prefix: 'it8721'
|
||||||
|
Addresses scanned: from Super I/O config space (8 I/O ports)
|
||||||
|
Datasheet: Not publicly available
|
||||||
* SiS950 [clone of IT8705F]
|
* SiS950 [clone of IT8705F]
|
||||||
Prefix: 'it87'
|
Prefix: 'it87'
|
||||||
Addresses scanned: from Super I/O config space (8 I/O ports)
|
Addresses scanned: from Super I/O config space (8 I/O ports)
|
||||||
|
@ -67,7 +71,7 @@ Description
|
||||||
-----------
|
-----------
|
||||||
|
|
||||||
This driver implements support for the IT8705F, IT8712F, IT8716F,
|
This driver implements support for the IT8705F, IT8712F, IT8716F,
|
||||||
IT8718F, IT8720F, IT8726F and SiS950 chips.
|
IT8718F, IT8720F, IT8721F, IT8726F, IT8758E and SiS950 chips.
|
||||||
|
|
||||||
These chips are 'Super I/O chips', supporting floppy disks, infrared ports,
|
These chips are 'Super I/O chips', supporting floppy disks, infrared ports,
|
||||||
joysticks and other miscellaneous stuff. For hardware monitoring, they
|
joysticks and other miscellaneous stuff. For hardware monitoring, they
|
||||||
|
@ -86,14 +90,15 @@ the driver won't notice and report changes in the VID value. The two
|
||||||
upper VID bits share their pins with voltage inputs (in5 and in6) so you
|
upper VID bits share their pins with voltage inputs (in5 and in6) so you
|
||||||
can't have both on a given board.
|
can't have both on a given board.
|
||||||
|
|
||||||
The IT8716F, IT8718F, IT8720F and later IT8712F revisions have support for
|
The IT8716F, IT8718F, IT8720F, IT8721F/IT8758E and later IT8712F revisions
|
||||||
2 additional fans. The additional fans are supported by the driver.
|
have support for 2 additional fans. The additional fans are supported by the
|
||||||
|
driver.
|
||||||
|
|
||||||
The IT8716F, IT8718F and IT8720F, and late IT8712F and IT8705F also have
|
The IT8716F, IT8718F, IT8720F and IT8721F/IT8758E, and late IT8712F and
|
||||||
optional 16-bit tachometer counters for fans 1 to 3. This is better (no more
|
IT8705F also have optional 16-bit tachometer counters for fans 1 to 3. This
|
||||||
fan clock divider mess) but not compatible with the older chips and
|
is better (no more fan clock divider mess) but not compatible with the older
|
||||||
revisions. The 16-bit tachometer mode is enabled by the driver when one
|
chips and revisions. The 16-bit tachometer mode is enabled by the driver when
|
||||||
of the above chips is detected.
|
one of the above chips is detected.
|
||||||
|
|
||||||
The IT8726F is just bit enhanced IT8716F with additional hardware
|
The IT8726F is just bit enhanced IT8716F with additional hardware
|
||||||
for AMD power sequencing. Therefore the chip will appear as IT8716F
|
for AMD power sequencing. Therefore the chip will appear as IT8716F
|
||||||
|
@ -115,7 +120,12 @@ alarm is triggered if the voltage has crossed a programmable minimum or
|
||||||
maximum limit. Note that minimum in this case always means 'closest to
|
maximum limit. Note that minimum in this case always means 'closest to
|
||||||
zero'; this is important for negative voltage measurements. All voltage
|
zero'; this is important for negative voltage measurements. All voltage
|
||||||
inputs can measure voltages between 0 and 4.08 volts, with a resolution of
|
inputs can measure voltages between 0 and 4.08 volts, with a resolution of
|
||||||
0.016 volt. The battery voltage in8 does not have limit registers.
|
0.016 volt (except IT8721F/IT8758E: 0.012 volt.) The battery voltage in8 does
|
||||||
|
not have limit registers.
|
||||||
|
|
||||||
|
On the IT8721F/IT8758E, some voltage inputs are internal and scaled inside
|
||||||
|
the chip (in7, in8 and optionally in3). The driver handles this transparently
|
||||||
|
so user-space doesn't have to care.
|
||||||
|
|
||||||
The VID lines (IT8712F/IT8716F/IT8718F/IT8720F) encode the core voltage value:
|
The VID lines (IT8712F/IT8716F/IT8718F/IT8720F) encode the core voltage value:
|
||||||
the voltage level your processor should work with. This is hardcoded by
|
the voltage level your processor should work with. This is hardcoded by
|
||||||
|
|
|
@ -14,6 +14,10 @@ Supported chips:
|
||||||
Prefix: 'adt7463'
|
Prefix: 'adt7463'
|
||||||
Addresses scanned: I2C 0x2c, 0x2d, 0x2e
|
Addresses scanned: I2C 0x2c, 0x2d, 0x2e
|
||||||
Datasheet: http://www.onsemi.com/PowerSolutions/product.do?id=ADT7463
|
Datasheet: http://www.onsemi.com/PowerSolutions/product.do?id=ADT7463
|
||||||
|
* Analog Devices ADT7468
|
||||||
|
Prefix: 'adt7468'
|
||||||
|
Addresses scanned: I2C 0x2c, 0x2d, 0x2e
|
||||||
|
Datasheet: http://www.onsemi.com/PowerSolutions/product.do?id=ADT7468
|
||||||
* SMSC EMC6D100, SMSC EMC6D101
|
* SMSC EMC6D100, SMSC EMC6D101
|
||||||
Prefix: 'emc6d100'
|
Prefix: 'emc6d100'
|
||||||
Addresses scanned: I2C 0x2c, 0x2d, 0x2e
|
Addresses scanned: I2C 0x2c, 0x2d, 0x2e
|
||||||
|
@ -34,7 +38,7 @@ Description
|
||||||
-----------
|
-----------
|
||||||
|
|
||||||
This driver implements support for the National Semiconductor LM85 and
|
This driver implements support for the National Semiconductor LM85 and
|
||||||
compatible chips including the Analog Devices ADM1027, ADT7463 and
|
compatible chips including the Analog Devices ADM1027, ADT7463, ADT7468 and
|
||||||
SMSC EMC6D10x chips family.
|
SMSC EMC6D10x chips family.
|
||||||
|
|
||||||
The LM85 uses the 2-wire interface compatible with the SMBUS 2.0
|
The LM85 uses the 2-wire interface compatible with the SMBUS 2.0
|
||||||
|
@ -87,14 +91,22 @@ To smooth the response of fans to changes in temperature, the LM85 has an
|
||||||
optional filter for smoothing temperatures. The ADM1027 has the same
|
optional filter for smoothing temperatures. The ADM1027 has the same
|
||||||
config option but uses it to rate limit the changes to fan speed instead.
|
config option but uses it to rate limit the changes to fan speed instead.
|
||||||
|
|
||||||
The ADM1027 and ADT7463 have a 10-bit ADC and can therefore measure
|
The ADM1027, ADT7463 and ADT7468 have a 10-bit ADC and can therefore
|
||||||
temperatures with 0.25 degC resolution. They also provide an offset to the
|
measure temperatures with 0.25 degC resolution. They also provide an offset
|
||||||
temperature readings that is automatically applied during measurement.
|
to the temperature readings that is automatically applied during
|
||||||
This offset can be used to zero out any errors due to traces and placement.
|
measurement. This offset can be used to zero out any errors due to traces
|
||||||
The documentation says that the offset is in 0.25 degC steps, but in
|
and placement. The documentation says that the offset is in 0.25 degC
|
||||||
initial testing of the ADM1027 it was 1.00 degC steps. Analog Devices has
|
steps, but in initial testing of the ADM1027 it was 1.00 degC steps. Analog
|
||||||
confirmed this "bug". The ADT7463 is reported to work as described in the
|
Devices has confirmed this "bug". The ADT7463 is reported to work as
|
||||||
documentation. The current lm85 driver does not show the offset register.
|
described in the documentation. The current lm85 driver does not show the
|
||||||
|
offset register.
|
||||||
|
|
||||||
|
The ADT7468 has a high-frequency PWM mode, where all PWM outputs are
|
||||||
|
driven by a 22.5 kHz clock. This is a global mode, not per-PWM output,
|
||||||
|
which means that setting any PWM frequency above 11.3 kHz will switch
|
||||||
|
all 3 PWM outputs to a 22.5 kHz frequency. Conversely, setting any PWM
|
||||||
|
frequency below 11.3 kHz will switch all 3 PWM outputs to a frequency
|
||||||
|
between 10 and 100 Hz, which can then be tuned separately.
|
||||||
|
|
||||||
See the vendor datasheets for more information. There is application note
|
See the vendor datasheets for more information. There is application note
|
||||||
from National (AN-1260) with some additional information about the LM85.
|
from National (AN-1260) with some additional information about the LM85.
|
||||||
|
@ -125,17 +137,17 @@ datasheet for a complete description of the differences. Other than
|
||||||
identifying the chip, the driver behaves no differently with regard to
|
identifying the chip, the driver behaves no differently with regard to
|
||||||
these two chips. The LM85B is recommended for new designs.
|
these two chips. The LM85B is recommended for new designs.
|
||||||
|
|
||||||
The ADM1027 and ADT7463 chips have an optional SMBALERT output that can be
|
The ADM1027, ADT7463 and ADT7468 chips have an optional SMBALERT output
|
||||||
used to signal the chipset in case a limit is exceeded or the temperature
|
that can be used to signal the chipset in case a limit is exceeded or the
|
||||||
sensors fail. Individual sensor interrupts can be masked so they won't
|
temperature sensors fail. Individual sensor interrupts can be masked so
|
||||||
trigger SMBALERT. The SMBALERT output if configured replaces one of the other
|
they won't trigger SMBALERT. The SMBALERT output if configured replaces one
|
||||||
functions (PWM2 or IN0). This functionality is not implemented in current
|
of the other functions (PWM2 or IN0). This functionality is not implemented
|
||||||
driver.
|
in current driver.
|
||||||
|
|
||||||
The ADT7463 also has an optional THERM output/input which can be connected
|
The ADT7463 and ADT7468 also have an optional THERM output/input which can
|
||||||
to the processor PROC_HOT output. If available, the autofan control
|
be connected to the processor PROC_HOT output. If available, the autofan
|
||||||
dynamic Tmin feature can be enabled to keep the system temperature within
|
control dynamic Tmin feature can be enabled to keep the system temperature
|
||||||
spec (just?!) with the least possible fan noise.
|
within spec (just?!) with the least possible fan noise.
|
||||||
|
|
||||||
Configuration Notes
|
Configuration Notes
|
||||||
-------------------
|
-------------------
|
||||||
|
@ -201,8 +213,8 @@ the temperatures to compensate for systemic errors in the
|
||||||
measurements. These features are not currently supported by the lm85
|
measurements. These features are not currently supported by the lm85
|
||||||
driver.
|
driver.
|
||||||
|
|
||||||
In addition to the ADM1027 features, the ADT7463 also has Tmin control
|
In addition to the ADM1027 features, the ADT7463 and ADT7468 also have
|
||||||
and THERM asserted counts. Automatic Tmin control acts to adjust the
|
Tmin control and THERM asserted counts. Automatic Tmin control acts to
|
||||||
Tmin value to maintain the measured temperature sensor at a specified
|
adjust the Tmin value to maintain the measured temperature sensor at a
|
||||||
temperature. There isn't much documentation on this feature in the
|
specified temperature. There isn't much documentation on this feature in
|
||||||
ADT7463 data sheet. This is not supported by current driver.
|
the ADT7463 data sheet. This is not supported by current driver.
|
||||||
|
|
|
@ -63,8 +63,8 @@ Supported chips:
|
||||||
Datasheet: Publicly available at the Maxim website
|
Datasheet: Publicly available at the Maxim website
|
||||||
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2578
|
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2578
|
||||||
* Maxim MAX6659
|
* Maxim MAX6659
|
||||||
Prefix: 'max6657'
|
Prefix: 'max6659'
|
||||||
Addresses scanned: I2C 0x4c, 0x4d (unsupported 0x4e)
|
Addresses scanned: I2C 0x4c, 0x4d, 0x4e
|
||||||
Datasheet: Publicly available at the Maxim website
|
Datasheet: Publicly available at the Maxim website
|
||||||
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2578
|
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2578
|
||||||
* Maxim MAX6680
|
* Maxim MAX6680
|
||||||
|
@ -84,6 +84,21 @@ Supported chips:
|
||||||
Addresses scanned: I2C 0x4c
|
Addresses scanned: I2C 0x4c
|
||||||
Datasheet: Publicly available at the Maxim website
|
Datasheet: Publicly available at the Maxim website
|
||||||
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3500
|
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3500
|
||||||
|
* Maxim MAX6695
|
||||||
|
Prefix: 'max6695'
|
||||||
|
Addresses scanned: I2C 0x18
|
||||||
|
Datasheet: Publicly available at the Maxim website
|
||||||
|
http://www.maxim-ic.com/datasheet/index.mvp/id/4199
|
||||||
|
* Maxim MAX6696
|
||||||
|
Prefix: 'max6695'
|
||||||
|
Addresses scanned: I2C 0x18, 0x19, 0x1a, 0x29, 0x2a, 0x2b,
|
||||||
|
0x4c, 0x4d and 0x4e
|
||||||
|
Datasheet: Publicly available at the Maxim website
|
||||||
|
http://www.maxim-ic.com/datasheet/index.mvp/id/4199
|
||||||
|
* Winbond/Nuvoton W83L771W/G
|
||||||
|
Prefix: 'w83l771'
|
||||||
|
Addresses scanned: I2C 0x4c
|
||||||
|
Datasheet: No longer available
|
||||||
* Winbond/Nuvoton W83L771AWG/ASG
|
* Winbond/Nuvoton W83L771AWG/ASG
|
||||||
Prefix: 'w83l771'
|
Prefix: 'w83l771'
|
||||||
Addresses scanned: I2C 0x4c
|
Addresses scanned: I2C 0x4c
|
||||||
|
@ -101,10 +116,11 @@ well as the temperature of up to one external diode. It is compatible
|
||||||
with many other devices, many of which are supported by this driver.
|
with many other devices, many of which are supported by this driver.
|
||||||
|
|
||||||
Note that there is no easy way to differentiate between the MAX6657,
|
Note that there is no easy way to differentiate between the MAX6657,
|
||||||
MAX6658 and MAX6659 variants. The extra address and features of the
|
MAX6658 and MAX6659 variants. The extra features of the MAX6659 are only
|
||||||
MAX6659 are not supported by this driver. The MAX6680 and MAX6681 only
|
supported by this driver if the chip is located at address 0x4d or 0x4e,
|
||||||
differ in their pinout, therefore they obviously can't (and don't need to)
|
or if the chip type is explicitly selected as max6659.
|
||||||
be distinguished.
|
The MAX6680 and MAX6681 only differ in their pinout, therefore they obviously
|
||||||
|
can't (and don't need to) be distinguished.
|
||||||
|
|
||||||
The specificity of this family of chipsets over the ADM1021/LM84
|
The specificity of this family of chipsets over the ADM1021/LM84
|
||||||
family is that it features critical limits with hysteresis, and an
|
family is that it features critical limits with hysteresis, and an
|
||||||
|
@ -151,12 +167,22 @@ MAX6680 and MAX6681:
|
||||||
* Selectable address
|
* Selectable address
|
||||||
* Remote sensor type selection
|
* Remote sensor type selection
|
||||||
|
|
||||||
W83L771AWG/ASG
|
MAX6695 and MAX6696:
|
||||||
* The AWG and ASG variants only differ in package format.
|
* Better local resolution
|
||||||
|
* Selectable address (max6696)
|
||||||
|
* Second critical temperature limit
|
||||||
|
* Two remote sensors
|
||||||
|
|
||||||
|
W83L771W/G
|
||||||
|
* The G variant is lead-free, otherwise similar to the W.
|
||||||
* Filter and alert configuration register at 0xBF
|
* Filter and alert configuration register at 0xBF
|
||||||
* Diode ideality factor configuration (remote sensor) at 0xE3
|
|
||||||
* Moving average (depending on conversion rate)
|
* Moving average (depending on conversion rate)
|
||||||
|
|
||||||
|
W83L771AWG/ASG
|
||||||
|
* Successor of the W83L771W/G, same features.
|
||||||
|
* The AWG and ASG variants only differ in package format.
|
||||||
|
* Diode ideality factor configuration (remote sensor) at 0xE3
|
||||||
|
|
||||||
All temperature values are given in degrees Celsius. Resolution
|
All temperature values are given in degrees Celsius. Resolution
|
||||||
is 1.0 degree for the local temperature, 0.125 degree for the remote
|
is 1.0 degree for the local temperature, 0.125 degree for the remote
|
||||||
temperature, except for the MAX6657, MAX6658 and MAX6659 which have a
|
temperature, except for the MAX6657, MAX6658 and MAX6659 which have a
|
||||||
|
|
|
@ -11,7 +11,7 @@ Authors:
|
||||||
Mark M. Hoffman <mhoffman@lightlink.com>
|
Mark M. Hoffman <mhoffman@lightlink.com>
|
||||||
Ported to 2.6 by Eric J. Bowersox <ericb@aspsys.com>
|
Ported to 2.6 by Eric J. Bowersox <ericb@aspsys.com>
|
||||||
Adapted to 2.6.20 by Carsten Emde <ce@osadl.org>
|
Adapted to 2.6.20 by Carsten Emde <ce@osadl.org>
|
||||||
Modified for mainline integration by Hans J. Koch <hjk@linutronix.de>
|
Modified for mainline integration by Hans J. Koch <hjk@hansjkoch.de>
|
||||||
|
|
||||||
Module Parameters
|
Module Parameters
|
||||||
-----------------
|
-----------------
|
||||||
|
|
63
Documentation/hwmon/ltc4261
Normal file
63
Documentation/hwmon/ltc4261
Normal file
|
@ -0,0 +1,63 @@
|
||||||
|
Kernel driver ltc4261
|
||||||
|
=====================
|
||||||
|
|
||||||
|
Supported chips:
|
||||||
|
* Linear Technology LTC4261
|
||||||
|
Prefix: 'ltc4261'
|
||||||
|
Addresses scanned: -
|
||||||
|
Datasheet:
|
||||||
|
http://cds.linear.com/docs/Datasheet/42612fb.pdf
|
||||||
|
|
||||||
|
Author: Guenter Roeck <guenter.roeck@ericsson.com>
|
||||||
|
|
||||||
|
|
||||||
|
Description
|
||||||
|
-----------
|
||||||
|
|
||||||
|
The LTC4261/LTC4261-2 negative voltage Hot Swap controllers allow a board
|
||||||
|
to be safely inserted and removed from a live backplane.
|
||||||
|
|
||||||
|
|
||||||
|
Usage Notes
|
||||||
|
-----------
|
||||||
|
|
||||||
|
This driver does not probe for LTC4261 devices, since there is no register
|
||||||
|
which can be safely used to identify the chip. You will have to instantiate
|
||||||
|
the devices explicitly.
|
||||||
|
|
||||||
|
Example: the following will load the driver for an LTC4261 at address 0x10
|
||||||
|
on I2C bus #1:
|
||||||
|
$ modprobe ltc4261
|
||||||
|
$ echo ltc4261 0x10 > /sys/bus/i2c/devices/i2c-1/new_device
|
||||||
|
|
||||||
|
|
||||||
|
Sysfs entries
|
||||||
|
-------------
|
||||||
|
|
||||||
|
Voltage readings provided by this driver are reported as obtained from the ADC
|
||||||
|
registers. If a set of voltage divider resistors is installed, calculate the
|
||||||
|
real voltage by multiplying the reported value with (R1+R2)/R2, where R1 is the
|
||||||
|
value of the divider resistor against the measured voltage and R2 is the value
|
||||||
|
of the divider resistor against Ground.
|
||||||
|
|
||||||
|
Current reading provided by this driver is reported as obtained from the ADC
|
||||||
|
Current Sense register. The reported value assumes that a 1 mOhm sense resistor
|
||||||
|
is installed. If a different sense resistor is installed, calculate the real
|
||||||
|
current by dividing the reported value by the sense resistor value in mOhm.
|
||||||
|
|
||||||
|
The chip has two voltage sensors, but only one set of voltage alarm status bits.
|
||||||
|
In many many designs, those alarms are associated with the ADIN2 sensor, due to
|
||||||
|
the proximity of the ADIN2 pin to the OV pin. ADIN2 is, however, not available
|
||||||
|
on all chip variants. To ensure that the alarm condition is reported to the user,
|
||||||
|
report it with both voltage sensors.
|
||||||
|
|
||||||
|
in1_input ADIN2 voltage (mV)
|
||||||
|
in1_min_alarm ADIN/ADIN2 Undervoltage alarm
|
||||||
|
in1_max_alarm ADIN/ADIN2 Overvoltage alarm
|
||||||
|
|
||||||
|
in2_input ADIN voltage (mV)
|
||||||
|
in2_min_alarm ADIN/ADIN2 Undervoltage alarm
|
||||||
|
in2_max_alarm ADIN/ADIN2 Overvoltage alarm
|
||||||
|
|
||||||
|
curr1_input SENSE current (mA)
|
||||||
|
curr1_alarm SENSE overcurrent alarm
|
|
@ -8,7 +8,7 @@ Supported chips:
|
||||||
Datasheet: http://pdfserv.maxim-ic.com/en/ds/MAX6650-MAX6651.pdf
|
Datasheet: http://pdfserv.maxim-ic.com/en/ds/MAX6650-MAX6651.pdf
|
||||||
|
|
||||||
Authors:
|
Authors:
|
||||||
Hans J. Koch <hjk@linutronix.de>
|
Hans J. Koch <hjk@hansjkoch.de>
|
||||||
John Morris <john.morris@spirentcom.com>
|
John Morris <john.morris@spirentcom.com>
|
||||||
Claus Gindhart <claus.gindhart@kontron.com>
|
Claus Gindhart <claus.gindhart@kontron.com>
|
||||||
|
|
||||||
|
|
|
@ -4,7 +4,7 @@ Kernel driver pcf8591
|
||||||
Supported chips:
|
Supported chips:
|
||||||
* Philips/NXP PCF8591
|
* Philips/NXP PCF8591
|
||||||
Prefix: 'pcf8591'
|
Prefix: 'pcf8591'
|
||||||
Addresses scanned: I2C 0x48 - 0x4f
|
Addresses scanned: none
|
||||||
Datasheet: Publicly available at the NXP website
|
Datasheet: Publicly available at the NXP website
|
||||||
http://www.nxp.com/pip/PCF8591_6.html
|
http://www.nxp.com/pip/PCF8591_6.html
|
||||||
|
|
||||||
|
@ -58,18 +58,16 @@ Module parameters
|
||||||
Accessing PCF8591 via /sys interface
|
Accessing PCF8591 via /sys interface
|
||||||
-------------------------------------
|
-------------------------------------
|
||||||
|
|
||||||
! Be careful !
|
The PCF8591 is plainly impossible to detect! Thus the driver won't even
|
||||||
The PCF8591 is plainly impossible to detect! Stupid chip.
|
try. You have to explicitly instantiate the device at the relevant
|
||||||
So every chip with address in the interval [0x48..0x4f] is
|
address (in the interval [0x48..0x4f]) either through platform data, or
|
||||||
detected as PCF8591. If you have other chips in this address
|
using the sysfs interface. See Documentation/i2c/instantiating-devices
|
||||||
range, the workaround is to load this module after the one
|
for details.
|
||||||
for your others chips.
|
|
||||||
|
|
||||||
On detection (i.e. insmod, modprobe et al.), directories are being
|
Directories are being created for each instantiated PCF8591:
|
||||||
created for each detected PCF8591:
|
|
||||||
|
|
||||||
/sys/bus/i2c/devices/<0>-<1>/
|
/sys/bus/i2c/devices/<0>-<1>/
|
||||||
where <0> is the bus the chip was detected on (e. g. i2c-0)
|
where <0> is the bus the chip is connected to (e. g. i2c-0)
|
||||||
and <1> the chip address ([48..4f])
|
and <1> the chip address ([48..4f])
|
||||||
|
|
||||||
Inside these directories, there are such files:
|
Inside these directories, there are such files:
|
||||||
|
|
|
@ -309,6 +309,20 @@ temp[1-*]_crit_hyst
|
||||||
from the critical value.
|
from the critical value.
|
||||||
RW
|
RW
|
||||||
|
|
||||||
|
temp[1-*]_emergency
|
||||||
|
Temperature emergency max value, for chips supporting more than
|
||||||
|
two upper temperature limits. Must be equal or greater than
|
||||||
|
corresponding temp_crit values.
|
||||||
|
Unit: millidegree Celsius
|
||||||
|
RW
|
||||||
|
|
||||||
|
temp[1-*]_emergency_hyst
|
||||||
|
Temperature hysteresis value for emergency limit.
|
||||||
|
Unit: millidegree Celsius
|
||||||
|
Must be reported as an absolute temperature, NOT a delta
|
||||||
|
from the emergency value.
|
||||||
|
RW
|
||||||
|
|
||||||
temp[1-*]_lcrit Temperature critical min value, typically lower than
|
temp[1-*]_lcrit Temperature critical min value, typically lower than
|
||||||
corresponding temp_min values.
|
corresponding temp_min values.
|
||||||
Unit: millidegree Celsius
|
Unit: millidegree Celsius
|
||||||
|
@ -505,6 +519,7 @@ fan[1-*]_max_alarm
|
||||||
temp[1-*]_min_alarm
|
temp[1-*]_min_alarm
|
||||||
temp[1-*]_max_alarm
|
temp[1-*]_max_alarm
|
||||||
temp[1-*]_crit_alarm
|
temp[1-*]_crit_alarm
|
||||||
|
temp[1-*]_emergency_alarm
|
||||||
Limit alarm
|
Limit alarm
|
||||||
0: no alarm
|
0: no alarm
|
||||||
1: alarm
|
1: alarm
|
||||||
|
|
|
@ -15,10 +15,14 @@ Supported adapters:
|
||||||
* Intel 82801I (ICH9)
|
* Intel 82801I (ICH9)
|
||||||
* Intel EP80579 (Tolapai)
|
* Intel EP80579 (Tolapai)
|
||||||
* Intel 82801JI (ICH10)
|
* Intel 82801JI (ICH10)
|
||||||
* Intel 3400/5 Series (PCH)
|
* Intel 5/3400 Series (PCH)
|
||||||
* Intel Cougar Point (PCH)
|
* Intel Cougar Point (PCH)
|
||||||
|
* Intel Patsburg (PCH)
|
||||||
Datasheets: Publicly available at the Intel website
|
Datasheets: Publicly available at the Intel website
|
||||||
|
|
||||||
|
On Intel Patsburg and later chipsets, both the normal host SMBus controller
|
||||||
|
and the additional 'Integrated Device Function' controllers are supported.
|
||||||
|
|
||||||
Authors:
|
Authors:
|
||||||
Mark Studebaker <mdsxyz123@yahoo.com>
|
Mark Studebaker <mdsxyz123@yahoo.com>
|
||||||
Jean Delvare <khali@linux-fr.org>
|
Jean Delvare <khali@linux-fr.org>
|
||||||
|
|
|
@ -259,7 +259,7 @@ Code Seq#(hex) Include File Comments
|
||||||
't' 00-7F linux/if_ppp.h
|
't' 00-7F linux/if_ppp.h
|
||||||
't' 80-8F linux/isdn_ppp.h
|
't' 80-8F linux/isdn_ppp.h
|
||||||
't' 90 linux/toshiba.h
|
't' 90 linux/toshiba.h
|
||||||
'u' 00-1F linux/smb_fs.h
|
'u' 00-1F linux/smb_fs.h gone
|
||||||
'v' all linux/videodev.h conflict!
|
'v' all linux/videodev.h conflict!
|
||||||
'v' 00-1F linux/ext2_fs.h conflict!
|
'v' 00-1F linux/ext2_fs.h conflict!
|
||||||
'v' 00-1F linux/fs.h conflict!
|
'v' 00-1F linux/fs.h conflict!
|
||||||
|
@ -278,7 +278,6 @@ Code Seq#(hex) Include File Comments
|
||||||
<mailto:oe@port.de>
|
<mailto:oe@port.de>
|
||||||
'z' 10-4F drivers/s390/crypto/zcrypt_api.h conflict!
|
'z' 10-4F drivers/s390/crypto/zcrypt_api.h conflict!
|
||||||
0x80 00-1F linux/fb.h
|
0x80 00-1F linux/fb.h
|
||||||
0x81 00-1F linux/videotext.h
|
|
||||||
0x88 00-3F media/ovcamchip.h
|
0x88 00-3F media/ovcamchip.h
|
||||||
0x89 00-06 arch/x86/include/asm/sockios.h
|
0x89 00-06 arch/x86/include/asm/sockios.h
|
||||||
0x89 0B-DF linux/sockios.h
|
0x89 0B-DF linux/sockios.h
|
||||||
|
|
|
@ -322,7 +322,8 @@ mainmenu:
|
||||||
"mainmenu" <prompt>
|
"mainmenu" <prompt>
|
||||||
|
|
||||||
This sets the config program's title bar if the config program chooses
|
This sets the config program's title bar if the config program chooses
|
||||||
to use it.
|
to use it. It should be placed at the top of the configuration, before any
|
||||||
|
other statement.
|
||||||
|
|
||||||
|
|
||||||
Kconfig hints
|
Kconfig hints
|
||||||
|
|
|
@ -776,6 +776,13 @@ This will delete the directory debian, including all subdirectories.
|
||||||
Kbuild will assume the directories to be in the same relative path as the
|
Kbuild will assume the directories to be in the same relative path as the
|
||||||
Makefile if no absolute path is specified (path does not start with '/').
|
Makefile if no absolute path is specified (path does not start with '/').
|
||||||
|
|
||||||
|
To exclude certain files from make clean, use the $(no-clean-files) variable.
|
||||||
|
This is only a special case used in the top level Kbuild file:
|
||||||
|
|
||||||
|
Example:
|
||||||
|
#Kbuild
|
||||||
|
no-clean-files := $(bounds-file) $(offsets-file)
|
||||||
|
|
||||||
Usually kbuild descends down in subdirectories due to "obj-* := dir/",
|
Usually kbuild descends down in subdirectories due to "obj-* := dir/",
|
||||||
but in the architecture makefiles where the kbuild infrastructure
|
but in the architecture makefiles where the kbuild infrastructure
|
||||||
is not sufficient this sometimes needs to be explicit.
|
is not sufficient this sometimes needs to be explicit.
|
||||||
|
|
|
@ -1,215 +1,185 @@
|
||||||
|
Building External Modules
|
||||||
|
|
||||||
In this document you will find information about:
|
This document describes how to build an out-of-tree kernel module.
|
||||||
- how to build external modules
|
|
||||||
- how to make your module use the kbuild infrastructure
|
|
||||||
- how kbuild will install a kernel
|
|
||||||
- how to install modules in a non-standard location
|
|
||||||
|
|
||||||
=== Table of Contents
|
=== Table of Contents
|
||||||
|
|
||||||
=== 1 Introduction
|
=== 1 Introduction
|
||||||
=== 2 How to build external modules
|
=== 2 How to Build External Modules
|
||||||
--- 2.1 Building external modules
|
--- 2.1 Command Syntax
|
||||||
--- 2.2 Available targets
|
--- 2.2 Options
|
||||||
--- 2.3 Available options
|
--- 2.3 Targets
|
||||||
--- 2.4 Preparing the kernel tree for module build
|
--- 2.4 Building Separate Files
|
||||||
--- 2.5 Building separate files for a module
|
=== 3. Creating a Kbuild File for an External Module
|
||||||
=== 3. Example commands
|
--- 3.1 Shared Makefile
|
||||||
=== 4. Creating a kbuild file for an external module
|
--- 3.2 Separate Kbuild file and Makefile
|
||||||
=== 5. Include files
|
--- 3.3 Binary Blobs
|
||||||
--- 5.1 How to include files from the kernel include dir
|
--- 3.4 Building Multiple Modules
|
||||||
--- 5.2 External modules using an include/ dir
|
=== 4. Include Files
|
||||||
--- 5.3 External modules using several directories
|
--- 4.1 Kernel Includes
|
||||||
=== 6. Module installation
|
--- 4.2 Single Subdirectory
|
||||||
--- 6.1 INSTALL_MOD_PATH
|
--- 4.3 Several Subdirectories
|
||||||
--- 6.2 INSTALL_MOD_DIR
|
=== 5. Module Installation
|
||||||
=== 7. Module versioning & Module.symvers
|
--- 5.1 INSTALL_MOD_PATH
|
||||||
--- 7.1 Symbols from the kernel (vmlinux + modules)
|
--- 5.2 INSTALL_MOD_DIR
|
||||||
--- 7.2 Symbols and external modules
|
=== 6. Module Versioning
|
||||||
--- 7.3 Symbols from another external module
|
--- 6.1 Symbols From the Kernel (vmlinux + modules)
|
||||||
=== 8. Tips & Tricks
|
--- 6.2 Symbols and External Modules
|
||||||
--- 8.1 Testing for CONFIG_FOO_BAR
|
--- 6.3 Symbols From Another External Module
|
||||||
|
=== 7. Tips & Tricks
|
||||||
|
--- 7.1 Testing for CONFIG_FOO_BAR
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
=== 1. Introduction
|
=== 1. Introduction
|
||||||
|
|
||||||
kbuild includes functionality for building modules both
|
"kbuild" is the build system used by the Linux kernel. Modules must use
|
||||||
within the kernel source tree and outside the kernel source tree.
|
kbuild to stay compatible with changes in the build infrastructure and
|
||||||
The latter is usually referred to as external or "out-of-tree"
|
to pick up the right flags to "gcc." Functionality for building modules
|
||||||
modules and is used both during development and for modules that
|
both in-tree and out-of-tree is provided. The method for building
|
||||||
are not planned to be included in the kernel tree.
|
either is similar, and all modules are initially developed and built
|
||||||
|
out-of-tree.
|
||||||
|
|
||||||
What is covered within this file is mainly information to authors
|
Covered in this document is information aimed at developers interested
|
||||||
of modules. The author of an external module should supply
|
in building out-of-tree (or "external") modules. The author of an
|
||||||
a makefile that hides most of the complexity, so one only has to type
|
external module should supply a makefile that hides most of the
|
||||||
'make' to build the module. A complete example will be presented in
|
complexity, so one only has to type "make" to build the module. This is
|
||||||
chapter 4, "Creating a kbuild file for an external module".
|
easily accomplished, and a complete example will be presented in
|
||||||
|
section 3.
|
||||||
|
|
||||||
|
|
||||||
=== 2. How to build external modules
|
=== 2. How to Build External Modules
|
||||||
|
|
||||||
kbuild offers functionality to build external modules, with the
|
To build external modules, you must have a prebuilt kernel available
|
||||||
prerequisite that there is a pre-built kernel available with full source.
|
that contains the configuration and header files used in the build.
|
||||||
A subset of the targets available when building the kernel is available
|
Also, the kernel must have been built with modules enabled. If you are
|
||||||
when building an external module.
|
using a distribution kernel, there will be a package for the kernel you
|
||||||
|
are running provided by your distribution.
|
||||||
|
|
||||||
--- 2.1 Building external modules
|
An alternative is to use the "make" target "modules_prepare." This will
|
||||||
|
make sure the kernel contains the information required. The target
|
||||||
|
exists solely as a simple way to prepare a kernel source tree for
|
||||||
|
building external modules.
|
||||||
|
|
||||||
Use the following command to build an external module:
|
NOTE: "modules_prepare" will not build Module.symvers even if
|
||||||
|
CONFIG_MODVERSIONS is set; therefore, a full kernel build needs to be
|
||||||
|
executed to make module versioning work.
|
||||||
|
|
||||||
make -C <path-to-kernel> M=`pwd`
|
--- 2.1 Command Syntax
|
||||||
|
|
||||||
For the running kernel use:
|
The command to build an external module is:
|
||||||
|
|
||||||
make -C /lib/modules/`uname -r`/build M=`pwd`
|
$ make -C <path_to_kernel_src> M=$PWD
|
||||||
|
|
||||||
For the above command to succeed, the kernel must have been
|
The kbuild system knows that an external module is being built
|
||||||
built with modules enabled.
|
due to the "M=<dir>" option given in the command.
|
||||||
|
|
||||||
To install the modules that were just built:
|
To build against the running kernel use:
|
||||||
|
|
||||||
make -C <path-to-kernel> M=`pwd` modules_install
|
$ make -C /lib/modules/`uname -r`/build M=$PWD
|
||||||
|
|
||||||
More complex examples will be shown later, the above should
|
Then to install the module(s) just built, add the target
|
||||||
be enough to get you started.
|
"modules_install" to the command:
|
||||||
|
|
||||||
--- 2.2 Available targets
|
$ make -C /lib/modules/`uname -r`/build M=$PWD modules_install
|
||||||
|
|
||||||
$KDIR refers to the path to the kernel source top-level directory
|
--- 2.2 Options
|
||||||
|
|
||||||
make -C $KDIR M=`pwd`
|
($KDIR refers to the path of the kernel source directory.)
|
||||||
Will build the module(s) located in current directory.
|
|
||||||
All output files will be located in the same directory
|
|
||||||
as the module source.
|
|
||||||
No attempts are made to update the kernel source, and it is
|
|
||||||
a precondition that a successful make has been executed
|
|
||||||
for the kernel.
|
|
||||||
|
|
||||||
make -C $KDIR M=`pwd` modules
|
make -C $KDIR M=$PWD
|
||||||
The modules target is implied when no target is given.
|
|
||||||
Same functionality as if no target was specified.
|
|
||||||
See description above.
|
|
||||||
|
|
||||||
make -C $KDIR M=`pwd` modules_install
|
-C $KDIR
|
||||||
Install the external module(s).
|
The directory where the kernel source is located.
|
||||||
Installation default is in /lib/modules/<kernel-version>/extra,
|
"make" will actually change to the specified directory
|
||||||
but may be prefixed with INSTALL_MOD_PATH - see separate
|
when executing and will change back when finished.
|
||||||
chapter.
|
|
||||||
|
|
||||||
make -C $KDIR M=`pwd` clean
|
M=$PWD
|
||||||
Remove all generated files for the module - the kernel
|
Informs kbuild that an external module is being built.
|
||||||
source directory is not modified.
|
The value given to "M" is the absolute path of the
|
||||||
|
directory where the external module (kbuild file) is
|
||||||
|
located.
|
||||||
|
|
||||||
make -C $KDIR M=`pwd` help
|
--- 2.3 Targets
|
||||||
help will list the available target when building external
|
|
||||||
modules.
|
|
||||||
|
|
||||||
--- 2.3 Available options:
|
When building an external module, only a subset of the "make"
|
||||||
|
targets are available.
|
||||||
|
|
||||||
$KDIR refers to the path to the kernel source top-level directory
|
make -C $KDIR M=$PWD [target]
|
||||||
|
|
||||||
make -C $KDIR
|
The default will build the module(s) located in the current
|
||||||
Used to specify where to find the kernel source.
|
directory, so a target does not need to be specified. All
|
||||||
'$KDIR' represent the directory where the kernel source is.
|
output files will also be generated in this directory. No
|
||||||
Make will actually change directory to the specified directory
|
attempts are made to update the kernel source, and it is a
|
||||||
when executed but change back when finished.
|
precondition that a successful "make" has been executed for the
|
||||||
|
kernel.
|
||||||
|
|
||||||
make -C $KDIR M=`pwd`
|
modules
|
||||||
M= is used to tell kbuild that an external module is
|
The default target for external modules. It has the
|
||||||
being built.
|
same functionality as if no target was specified. See
|
||||||
The option given to M= is the directory where the external
|
description above.
|
||||||
module (kbuild file) is located.
|
|
||||||
When an external module is being built only a subset of the
|
|
||||||
usual targets are available.
|
|
||||||
|
|
||||||
make -C $KDIR SUBDIRS=`pwd`
|
modules_install
|
||||||
Same as M=. The SUBDIRS= syntax is kept for backwards
|
Install the external module(s). The default location is
|
||||||
compatibility.
|
/lib/modules/<kernel_release>/extra/, but a prefix may
|
||||||
|
be added with INSTALL_MOD_PATH (discussed in section 5).
|
||||||
|
|
||||||
--- 2.4 Preparing the kernel tree for module build
|
clean
|
||||||
|
Remove all generated files in the module directory only.
|
||||||
|
|
||||||
To make sure the kernel contains the information required to
|
help
|
||||||
build external modules the target 'modules_prepare' must be used.
|
List the available targets for external modules.
|
||||||
'modules_prepare' exists solely as a simple way to prepare
|
|
||||||
a kernel source tree for building external modules.
|
|
||||||
Note: modules_prepare will not build Module.symvers even if
|
|
||||||
CONFIG_MODVERSIONS is set. Therefore a full kernel build
|
|
||||||
needs to be executed to make module versioning work.
|
|
||||||
|
|
||||||
--- 2.5 Building separate files for a module
|
--- 2.4 Building Separate Files
|
||||||
It is possible to build single files which are part of a module.
|
|
||||||
This works equally well for the kernel, a module and even for
|
It is possible to build single files that are part of a module.
|
||||||
|
This works equally well for the kernel, a module, and even for
|
||||||
external modules.
|
external modules.
|
||||||
Examples (module foo.ko, consist of bar.o, baz.o):
|
|
||||||
make -C $KDIR M=`pwd` bar.lst
|
Example (The module foo.ko, consist of bar.o and baz.o):
|
||||||
make -C $KDIR M=`pwd` bar.o
|
make -C $KDIR M=$PWD bar.lst
|
||||||
make -C $KDIR M=`pwd` foo.ko
|
make -C $KDIR M=$PWD baz.o
|
||||||
make -C $KDIR M=`pwd` /
|
make -C $KDIR M=$PWD foo.ko
|
||||||
|
make -C $KDIR M=$PWD /
|
||||||
|
|
||||||
|
|
||||||
=== 3. Example commands
|
=== 3. Creating a Kbuild File for an External Module
|
||||||
|
|
||||||
This example shows the actual commands to be executed when building
|
In the last section we saw the command to build a module for the
|
||||||
an external module for the currently running kernel.
|
running kernel. The module is not actually built, however, because a
|
||||||
In the example below, the distribution is supposed to use the
|
build file is required. Contained in this file will be the name of
|
||||||
facility to locate output files for a kernel compile in a different
|
the module(s) being built, along with the list of requisite source
|
||||||
directory than the kernel source - but the examples will also work
|
files. The file may be as simple as a single line:
|
||||||
when the source and the output files are mixed in the same directory.
|
|
||||||
|
|
||||||
# Kernel source
|
obj-m := <module_name>.o
|
||||||
/lib/modules/<kernel-version>/source -> /usr/src/linux-<version>
|
|
||||||
|
|
||||||
# Output from kernel compile
|
The kbuild system will build <module_name>.o from <module_name>.c,
|
||||||
/lib/modules/<kernel-version>/build -> /usr/src/linux-<version>-up
|
and, after linking, will result in the kernel module <module_name>.ko.
|
||||||
|
The above line can be put in either a "Kbuild" file or a "Makefile."
|
||||||
|
When the module is built from multiple sources, an additional line is
|
||||||
|
needed listing the files:
|
||||||
|
|
||||||
Change to the directory where the kbuild file is located and execute
|
<module_name>-y := <src1>.o <src2>.o ...
|
||||||
the following commands to build the module:
|
|
||||||
|
|
||||||
cd /home/user/src/module
|
NOTE: Further documentation describing the syntax used by kbuild is
|
||||||
make -C /usr/src/`uname -r`/source \
|
located in Documentation/kbuild/makefiles.txt.
|
||||||
O=/lib/modules/`uname-r`/build \
|
|
||||||
M=`pwd`
|
|
||||||
|
|
||||||
Then, to install the module use the following command:
|
The examples below demonstrate how to create a build file for the
|
||||||
|
module 8123.ko, which is built from the following files:
|
||||||
|
|
||||||
make -C /usr/src/`uname -r`/source \
|
|
||||||
O=/lib/modules/`uname-r`/build \
|
|
||||||
M=`pwd` \
|
|
||||||
modules_install
|
|
||||||
|
|
||||||
If you look closely you will see that this is the same command as
|
|
||||||
listed before - with the directories spelled out.
|
|
||||||
|
|
||||||
The above are rather long commands, and the following chapter
|
|
||||||
lists a few tricks to make it all easier.
|
|
||||||
|
|
||||||
|
|
||||||
=== 4. Creating a kbuild file for an external module
|
|
||||||
|
|
||||||
kbuild is the build system for the kernel, and external modules
|
|
||||||
must use kbuild to stay compatible with changes in the build system
|
|
||||||
and to pick up the right flags to gcc etc.
|
|
||||||
|
|
||||||
The kbuild file used as input shall follow the syntax described
|
|
||||||
in Documentation/kbuild/makefiles.txt. This chapter will introduce a few
|
|
||||||
more tricks to be used when dealing with external modules.
|
|
||||||
|
|
||||||
In the following a Makefile will be created for a module with the
|
|
||||||
following files:
|
|
||||||
8123_if.c
|
8123_if.c
|
||||||
8123_if.h
|
8123_if.h
|
||||||
8123_pci.c
|
8123_pci.c
|
||||||
8123_bin.o_shipped <= Binary blob
|
8123_bin.o_shipped <= Binary blob
|
||||||
|
|
||||||
--- 4.1 Shared Makefile for module and kernel
|
--- 3.1 Shared Makefile
|
||||||
|
|
||||||
An external module always includes a wrapper Makefile supporting
|
An external module always includes a wrapper makefile that
|
||||||
building the module using 'make' with no arguments.
|
supports building the module using "make" with no arguments.
|
||||||
The Makefile provided will most likely include additional
|
This target is not used by kbuild; it is only for convenience.
|
||||||
functionality such as test targets etc. and this part shall
|
Additional functionality, such as test targets, can be included
|
||||||
be filtered away from kbuild since it may impact kbuild if
|
but should be filtered out from kbuild due to possible name
|
||||||
name clashes occurs.
|
clashes.
|
||||||
|
|
||||||
Example 1:
|
Example 1:
|
||||||
--> filename: Makefile
|
--> filename: Makefile
|
||||||
|
@ -219,11 +189,11 @@ following files:
|
||||||
8123-y := 8123_if.o 8123_pci.o 8123_bin.o
|
8123-y := 8123_if.o 8123_pci.o 8123_bin.o
|
||||||
|
|
||||||
else
|
else
|
||||||
# Normal Makefile
|
# normal makefile
|
||||||
|
KDIR ?= /lib/modules/`uname -r`/build
|
||||||
|
|
||||||
KERNELDIR := /lib/modules/`uname -r`/build
|
default:
|
||||||
all::
|
$(MAKE) -C $(KDIR) M=$$PWD
|
||||||
$(MAKE) -C $(KERNELDIR) M=`pwd` $@
|
|
||||||
|
|
||||||
# Module specific targets
|
# Module specific targets
|
||||||
genbin:
|
genbin:
|
||||||
|
@ -231,15 +201,20 @@ following files:
|
||||||
|
|
||||||
endif
|
endif
|
||||||
|
|
||||||
In example 1, the check for KERNELRELEASE is used to separate
|
The check for KERNELRELEASE is used to separate the two parts
|
||||||
the two parts of the Makefile. kbuild will only see the two
|
of the makefile. In the example, kbuild will only see the two
|
||||||
assignments whereas make will see everything except the two
|
assignments, whereas "make" will see everything except these
|
||||||
kbuild assignments.
|
two assignments. This is due to two passes made on the file:
|
||||||
|
the first pass is by the "make" instance run on the command
|
||||||
|
line; the second pass is by the kbuild system, which is
|
||||||
|
initiated by the parameterized "make" in the default target.
|
||||||
|
|
||||||
In recent versions of the kernel, kbuild will look for a file named
|
--- 3.2 Separate Kbuild File and Makefile
|
||||||
Kbuild and as second option look for a file named Makefile.
|
|
||||||
Utilising the Kbuild file makes us split up the Makefile in example 1
|
In newer versions of the kernel, kbuild will first look for a
|
||||||
into two files as shown in example 2:
|
file named "Kbuild," and only if that is not found, will it
|
||||||
|
then look for a makefile. Utilizing a "Kbuild" file allows us
|
||||||
|
to split up the makefile from example 1 into two files:
|
||||||
|
|
||||||
Example 2:
|
Example 2:
|
||||||
--> filename: Kbuild
|
--> filename: Kbuild
|
||||||
|
@ -247,20 +222,21 @@ following files:
|
||||||
8123-y := 8123_if.o 8123_pci.o 8123_bin.o
|
8123-y := 8123_if.o 8123_pci.o 8123_bin.o
|
||||||
|
|
||||||
--> filename: Makefile
|
--> filename: Makefile
|
||||||
KERNELDIR := /lib/modules/`uname -r`/build
|
KDIR ?= /lib/modules/`uname -r`/build
|
||||||
all::
|
|
||||||
$(MAKE) -C $(KERNELDIR) M=`pwd` $@
|
default:
|
||||||
|
$(MAKE) -C $(KDIR) M=$$PWD
|
||||||
|
|
||||||
# Module specific targets
|
# Module specific targets
|
||||||
genbin:
|
genbin:
|
||||||
echo "X" > 8123_bin.o_shipped
|
echo "X" > 8123_bin.o_shipped
|
||||||
|
|
||||||
|
The split in example 2 is questionable due to the simplicity of
|
||||||
|
each file; however, some external modules use makefiles
|
||||||
|
consisting of several hundred lines, and here it really pays
|
||||||
|
off to separate the kbuild part from the rest.
|
||||||
|
|
||||||
In example 2, we are down to two fairly simple files and for simple
|
The next example shows a backward compatible version.
|
||||||
files as used in this example the split is questionable. But some
|
|
||||||
external modules use Makefiles of several hundred lines and here it
|
|
||||||
really pays off to separate the kbuild part from the rest.
|
|
||||||
Example 3 shows a backward compatible version.
|
|
||||||
|
|
||||||
Example 3:
|
Example 3:
|
||||||
--> filename: Kbuild
|
--> filename: Kbuild
|
||||||
|
@ -269,13 +245,15 @@ following files:
|
||||||
|
|
||||||
--> filename: Makefile
|
--> filename: Makefile
|
||||||
ifneq ($(KERNELRELEASE),)
|
ifneq ($(KERNELRELEASE),)
|
||||||
|
# kbuild part of makefile
|
||||||
include Kbuild
|
include Kbuild
|
||||||
else
|
|
||||||
# Normal Makefile
|
|
||||||
|
|
||||||
KERNELDIR := /lib/modules/`uname -r`/build
|
else
|
||||||
all::
|
# normal makefile
|
||||||
$(MAKE) -C $(KERNELDIR) M=`pwd` $@
|
KDIR ?= /lib/modules/`uname -r`/build
|
||||||
|
|
||||||
|
default:
|
||||||
|
$(MAKE) -C $(KDIR) M=$$PWD
|
||||||
|
|
||||||
# Module specific targets
|
# Module specific targets
|
||||||
genbin:
|
genbin:
|
||||||
|
@ -283,260 +261,271 @@ following files:
|
||||||
|
|
||||||
endif
|
endif
|
||||||
|
|
||||||
The trick here is to include the Kbuild file from Makefile, so
|
Here the "Kbuild" file is included from the makefile. This
|
||||||
if an older version of kbuild picks up the Makefile, the Kbuild
|
allows an older version of kbuild, which only knows of
|
||||||
file will be included.
|
makefiles, to be used when the "make" and kbuild parts are
|
||||||
|
split into separate files.
|
||||||
|
|
||||||
--- 4.2 Binary blobs included in a module
|
--- 3.3 Binary Blobs
|
||||||
|
|
||||||
Some external modules needs to include a .o as a blob. kbuild
|
Some external modules need to include an object file as a blob.
|
||||||
has support for this, but requires the blob file to be named
|
kbuild has support for this, but requires the blob file to be
|
||||||
<filename>_shipped. In our example the blob is named
|
named <filename>_shipped. When the kbuild rules kick in, a copy
|
||||||
8123_bin.o_shipped and when the kbuild rules kick in the file
|
of <filename>_shipped is created with _shipped stripped off,
|
||||||
8123_bin.o is created as a simple copy off the 8213_bin.o_shipped file
|
giving us <filename>. This shortened filename can be used in
|
||||||
with the _shipped part stripped of the filename.
|
the assignment to the module.
|
||||||
This allows the 8123_bin.o filename to be used in the assignment to
|
|
||||||
the module.
|
Throughout this section, 8123_bin.o_shipped has been used to
|
||||||
|
build the kernel module 8123.ko; it has been included as
|
||||||
|
8123_bin.o.
|
||||||
|
|
||||||
Example 4:
|
|
||||||
obj-m := 8123.o
|
|
||||||
8123-y := 8123_if.o 8123_pci.o 8123_bin.o
|
8123-y := 8123_if.o 8123_pci.o 8123_bin.o
|
||||||
|
|
||||||
In example 4, there is no distinction between the ordinary .c/.h files
|
Although there is no distinction between the ordinary source
|
||||||
and the binary file. But kbuild will pick up different rules to create
|
files and the binary file, kbuild will pick up different rules
|
||||||
the .o file.
|
when creating the object file for the module.
|
||||||
|
|
||||||
|
--- 3.4 Building Multiple Modules
|
||||||
|
|
||||||
|
kbuild supports building multiple modules with a single build
|
||||||
|
file. For example, if you wanted to build two modules, foo.ko
|
||||||
|
and bar.ko, the kbuild lines would be:
|
||||||
|
|
||||||
|
obj-m := foo.o bar.o
|
||||||
|
foo-y := <foo_srcs>
|
||||||
|
bar-y := <bar_srcs>
|
||||||
|
|
||||||
|
It is that simple!
|
||||||
|
|
||||||
|
|
||||||
=== 5. Include files
|
=== 4. Include Files
|
||||||
|
|
||||||
Include files are a necessity when a .c file uses something from other .c
|
Within the kernel, header files are kept in standard locations
|
||||||
files (not strictly in the sense of C, but if good programming practice is
|
according to the following rule:
|
||||||
used). Any module that consists of more than one .c file will have a .h file
|
|
||||||
for one of the .c files.
|
|
||||||
|
|
||||||
- If the .h file only describes a module internal interface, then the .h file
|
* If the header file only describes the internal interface of a
|
||||||
shall be placed in the same directory as the .c files.
|
module, then the file is placed in the same directory as the
|
||||||
- If the .h files describe an interface used by other parts of the kernel
|
source files.
|
||||||
located in different directories, the .h files shall be located in
|
* If the header file describes an interface used by other parts
|
||||||
include/linux/ or other include/ directories as appropriate.
|
of the kernel that are located in different directories, then
|
||||||
|
the file is placed in include/linux/.
|
||||||
|
|
||||||
One exception for this rule is larger subsystems that have their own directory
|
NOTE: There are two notable exceptions to this rule: larger
|
||||||
under include/ such as include/scsi. Another exception is arch-specific
|
subsystems have their own directory under include/, such as
|
||||||
.h files which are located under include/asm-$(ARCH)/*.
|
include/scsi; and architecture specific headers are located
|
||||||
|
under arch/$(ARCH)/include/.
|
||||||
|
|
||||||
External modules have a tendency to locate include files in a separate include/
|
--- 4.1 Kernel Includes
|
||||||
directory and therefore need to deal with this in their kbuild file.
|
|
||||||
|
|
||||||
--- 5.1 How to include files from the kernel include dir
|
To include a header file located under include/linux/, simply
|
||||||
|
use:
|
||||||
|
|
||||||
When a module needs to include a file from include/linux/, then one
|
#include <linux/module.h>
|
||||||
just uses:
|
|
||||||
|
|
||||||
#include <linux/modules.h>
|
kbuild will add options to "gcc" so the relevant directories
|
||||||
|
are searched.
|
||||||
|
|
||||||
kbuild will make sure to add options to gcc so the relevant
|
--- 4.2 Single Subdirectory
|
||||||
directories are searched.
|
|
||||||
Likewise for .h files placed in the same directory as the .c file.
|
|
||||||
|
|
||||||
#include "8123_if.h"
|
External modules tend to place header files in a separate
|
||||||
|
include/ directory where their source is located, although this
|
||||||
|
is not the usual kernel style. To inform kbuild of the
|
||||||
|
directory, use either ccflags-y or CFLAGS_<filename>.o.
|
||||||
|
|
||||||
will do the job.
|
Using the example from section 3, if we moved 8123_if.h to a
|
||||||
|
subdirectory named include, the resulting kbuild file would
|
||||||
--- 5.2 External modules using an include/ dir
|
look like:
|
||||||
|
|
||||||
External modules often locate their .h files in a separate include/
|
|
||||||
directory although this is not usual kernel style. When an external
|
|
||||||
module uses an include/ dir then kbuild needs to be told so.
|
|
||||||
The trick here is to use either EXTRA_CFLAGS (take effect for all .c
|
|
||||||
files) or CFLAGS_$F.o (take effect only for a single file).
|
|
||||||
|
|
||||||
In our example, if we move 8123_if.h to a subdirectory named include/
|
|
||||||
the resulting Kbuild file would look like:
|
|
||||||
|
|
||||||
--> filename: Kbuild
|
--> filename: Kbuild
|
||||||
obj-m := 8123.o
|
obj-m := 8123.o
|
||||||
|
|
||||||
EXTRA_CFLAGS := -Iinclude
|
ccflags-y := -Iinclude
|
||||||
8123-y := 8123_if.o 8123_pci.o 8123_bin.o
|
8123-y := 8123_if.o 8123_pci.o 8123_bin.o
|
||||||
|
|
||||||
Note that in the assignment there is no space between -I and the path.
|
Note that in the assignment there is no space between -I and
|
||||||
This is a kbuild limitation: there must be no space present.
|
the path. This is a limitation of kbuild: there must be no
|
||||||
|
space present.
|
||||||
|
|
||||||
--- 5.3 External modules using several directories
|
--- 4.3 Several Subdirectories
|
||||||
|
|
||||||
If an external module does not follow the usual kernel style, but
|
|
||||||
decides to spread files over several directories, then kbuild can
|
|
||||||
handle this too.
|
|
||||||
|
|
||||||
|
kbuild can handle files that are spread over several directories.
|
||||||
Consider the following example:
|
Consider the following example:
|
||||||
|
|
||||||
|
|
.
|
||||||
+- src/complex_main.c
|
|__ src
|
||||||
| +- hal/hardwareif.c
|
| |__ complex_main.c
|
||||||
| +- hal/include/hardwareif.h
|
| |__ hal
|
||||||
+- include/complex.h
|
| |__ hardwareif.c
|
||||||
|
| |__ include
|
||||||
|
| |__ hardwareif.h
|
||||||
|
|__ include
|
||||||
|
|__ complex.h
|
||||||
|
|
||||||
To build a single module named complex.ko, we then need the following
|
To build the module complex.ko, we then need the following
|
||||||
kbuild file:
|
kbuild file:
|
||||||
|
|
||||||
Kbuild:
|
--> filename: Kbuild
|
||||||
obj-m := complex.o
|
obj-m := complex.o
|
||||||
complex-y := src/complex_main.o
|
complex-y := src/complex_main.o
|
||||||
complex-y += src/hal/hardwareif.o
|
complex-y += src/hal/hardwareif.o
|
||||||
|
|
||||||
EXTRA_CFLAGS := -I$(src)/include
|
ccflags-y := -I$(src)/include
|
||||||
EXTRA_CFLAGS += -I$(src)src/hal/include
|
ccflags-y += -I$(src)/src/hal/include
|
||||||
|
|
||||||
|
As you can see, kbuild knows how to handle object files located
|
||||||
|
in other directories. The trick is to specify the directory
|
||||||
|
relative to the kbuild file's location. That being said, this
|
||||||
|
is NOT recommended practice.
|
||||||
|
|
||||||
|
For the header files, kbuild must be explicitly told where to
|
||||||
|
look. When kbuild executes, the current directory is always the
|
||||||
|
root of the kernel tree (the argument to "-C") and therefore an
|
||||||
|
absolute path is needed. $(src) provides the absolute path by
|
||||||
|
pointing to the directory where the currently executing kbuild
|
||||||
|
file is located.
|
||||||
|
|
||||||
|
|
||||||
kbuild knows how to handle .o files located in another directory -
|
=== 5. Module Installation
|
||||||
although this is NOT recommended practice. The syntax is to specify
|
|
||||||
the directory relative to the directory where the Kbuild file is
|
|
||||||
located.
|
|
||||||
|
|
||||||
To find the .h files, we have to explicitly tell kbuild where to look
|
Modules which are included in the kernel are installed in the
|
||||||
for the .h files. When kbuild executes, the current directory is always
|
directory:
|
||||||
the root of the kernel tree (argument to -C) and therefore we have to
|
|
||||||
tell kbuild how to find the .h files using absolute paths.
|
|
||||||
$(src) will specify the absolute path to the directory where the
|
|
||||||
Kbuild file are located when being build as an external module.
|
|
||||||
Therefore -I$(src)/ is used to point out the directory of the Kbuild
|
|
||||||
file and any additional path are just appended.
|
|
||||||
|
|
||||||
=== 6. Module installation
|
/lib/modules/$(KERNELRELEASE)/kernel/
|
||||||
|
|
||||||
Modules which are included in the kernel are installed in the directory:
|
And external modules are installed in:
|
||||||
|
|
||||||
/lib/modules/$(KERNELRELEASE)/kernel
|
/lib/modules/$(KERNELRELEASE)/extra/
|
||||||
|
|
||||||
External modules are installed in the directory:
|
--- 5.1 INSTALL_MOD_PATH
|
||||||
|
|
||||||
/lib/modules/$(KERNELRELEASE)/extra
|
Above are the default directories but as always some level of
|
||||||
|
customization is possible. A prefix can be added to the
|
||||||
--- 6.1 INSTALL_MOD_PATH
|
installation path using the variable INSTALL_MOD_PATH:
|
||||||
|
|
||||||
Above are the default directories, but as always, some level of
|
|
||||||
customization is possible. One can prefix the path using the variable
|
|
||||||
INSTALL_MOD_PATH:
|
|
||||||
|
|
||||||
$ make INSTALL_MOD_PATH=/frodo modules_install
|
$ make INSTALL_MOD_PATH=/frodo modules_install
|
||||||
=> Install dir: /frodo/lib/modules/$(KERNELRELEASE)/kernel
|
=> Install dir: /frodo/lib/modules/$(KERNELRELEASE)/kernel/
|
||||||
|
|
||||||
INSTALL_MOD_PATH may be set as an ordinary shell variable or as in the
|
INSTALL_MOD_PATH may be set as an ordinary shell variable or,
|
||||||
example above, can be specified on the command line when calling make.
|
as shown above, can be specified on the command line when
|
||||||
INSTALL_MOD_PATH has effect both when installing modules included in
|
calling "make." This has effect when installing both in-tree
|
||||||
the kernel as well as when installing external modules.
|
and out-of-tree modules.
|
||||||
|
|
||||||
--- 6.2 INSTALL_MOD_DIR
|
--- 5.2 INSTALL_MOD_DIR
|
||||||
|
|
||||||
When installing external modules they are by default installed to a
|
External modules are by default installed to a directory under
|
||||||
directory under /lib/modules/$(KERNELRELEASE)/extra, but one may wish
|
/lib/modules/$(KERNELRELEASE)/extra/, but you may wish to
|
||||||
to locate modules for a specific functionality in a separate
|
locate modules for a specific functionality in a separate
|
||||||
directory. For this purpose, one can use INSTALL_MOD_DIR to specify an
|
directory. For this purpose, use INSTALL_MOD_DIR to specify an
|
||||||
alternative name to 'extra'.
|
alternative name to "extra."
|
||||||
|
|
||||||
$ make INSTALL_MOD_DIR=gandalf -C KERNELDIR \
|
$ make INSTALL_MOD_DIR=gandalf -C $KDIR \
|
||||||
M=`pwd` modules_install
|
M=$PWD modules_install
|
||||||
=> Install dir: /lib/modules/$(KERNELRELEASE)/gandalf
|
=> Install dir: /lib/modules/$(KERNELRELEASE)/gandalf/
|
||||||
|
|
||||||
|
|
||||||
=== 7. Module versioning & Module.symvers
|
=== 6. Module Versioning
|
||||||
|
|
||||||
Module versioning is enabled by the CONFIG_MODVERSIONS tag.
|
Module versioning is enabled by the CONFIG_MODVERSIONS tag, and is used
|
||||||
|
as a simple ABI consistency check. A CRC value of the full prototype
|
||||||
|
for an exported symbol is created. When a module is loaded/used, the
|
||||||
|
CRC values contained in the kernel are compared with similar values in
|
||||||
|
the module; if they are not equal, the kernel refuses to load the
|
||||||
|
module.
|
||||||
|
|
||||||
Module versioning is used as a simple ABI consistency check. The Module
|
Module.symvers contains a list of all exported symbols from a kernel
|
||||||
versioning creates a CRC value of the full prototype for an exported symbol and
|
build.
|
||||||
when a module is loaded/used then the CRC values contained in the kernel are
|
|
||||||
compared with similar values in the module. If they are not equal, then the
|
|
||||||
kernel refuses to load the module.
|
|
||||||
|
|
||||||
Module.symvers contains a list of all exported symbols from a kernel build.
|
--- 6.1 Symbols From the Kernel (vmlinux + modules)
|
||||||
|
|
||||||
--- 7.1 Symbols from the kernel (vmlinux + modules)
|
During a kernel build, a file named Module.symvers will be
|
||||||
|
generated. Module.symvers contains all exported symbols from
|
||||||
During a kernel build, a file named Module.symvers will be generated.
|
the kernel and compiled modules. For each symbol, the
|
||||||
Module.symvers contains all exported symbols from the kernel and
|
corresponding CRC value is also stored.
|
||||||
compiled modules. For each symbols, the corresponding CRC value
|
|
||||||
is stored too.
|
|
||||||
|
|
||||||
The syntax of the Module.symvers file is:
|
The syntax of the Module.symvers file is:
|
||||||
<CRC> <Symbol> <module>
|
<CRC> <Symbol> <module>
|
||||||
Sample:
|
|
||||||
0x2d036834 scsi_remove_host drivers/scsi/scsi_mod
|
0x2d036834 scsi_remove_host drivers/scsi/scsi_mod
|
||||||
|
|
||||||
For a kernel build without CONFIG_MODVERSIONS enabled, the crc
|
For a kernel build without CONFIG_MODVERSIONS enabled, the CRC
|
||||||
would read: 0x00000000
|
would read 0x00000000.
|
||||||
|
|
||||||
Module.symvers serves two purposes:
|
Module.symvers serves two purposes:
|
||||||
1) It lists all exported symbols both from vmlinux and all modules
|
1) It lists all exported symbols from vmlinux and all modules.
|
||||||
2) It lists the CRC if CONFIG_MODVERSIONS is enabled
|
2) It lists the CRC if CONFIG_MODVERSIONS is enabled.
|
||||||
|
|
||||||
--- 7.2 Symbols and external modules
|
--- 6.2 Symbols and External Modules
|
||||||
|
|
||||||
When building an external module, the build system needs access to
|
When building an external module, the build system needs access
|
||||||
the symbols from the kernel to check if all external symbols are
|
to the symbols from the kernel to check if all external symbols
|
||||||
defined. This is done in the MODPOST step and to obtain all
|
are defined. This is done in the MODPOST step. modpost obtains
|
||||||
symbols, modpost reads Module.symvers from the kernel.
|
the symbols by reading Module.symvers from the kernel source
|
||||||
If a Module.symvers file is present in the directory where
|
tree. If a Module.symvers file is present in the directory
|
||||||
the external module is being built, this file will be read too.
|
where the external module is being built, this file will be
|
||||||
During the MODPOST step, a new Module.symvers file will be written
|
read too. During the MODPOST step, a new Module.symvers file
|
||||||
containing all exported symbols that were not defined in the kernel.
|
will be written containing all exported symbols that were not
|
||||||
|
defined in the kernel.
|
||||||
|
|
||||||
--- 7.3 Symbols from another external module
|
--- 6.3 Symbols From Another External Module
|
||||||
|
|
||||||
Sometimes, an external module uses exported symbols from another
|
Sometimes, an external module uses exported symbols from
|
||||||
external module. Kbuild needs to have full knowledge on all symbols
|
another external module. kbuild needs to have full knowledge of
|
||||||
to avoid spitting out warnings about undefined symbols.
|
all symbols to avoid spitting out warnings about undefined
|
||||||
Three solutions exist to let kbuild know all symbols of more than
|
symbols. Three solutions exist for this situation.
|
||||||
one external module.
|
|
||||||
The method with a top-level kbuild file is recommended but may be
|
|
||||||
impractical in certain situations.
|
|
||||||
|
|
||||||
Use a top-level Kbuild file
|
NOTE: The method with a top-level kbuild file is recommended
|
||||||
If you have two modules: 'foo' and 'bar', and 'foo' needs
|
but may be impractical in certain situations.
|
||||||
symbols from 'bar', then one can use a common top-level kbuild
|
|
||||||
file so both modules are compiled in same build.
|
|
||||||
|
|
||||||
Consider following directory layout:
|
Use a top-level kbuild file
|
||||||
./foo/ <= contains the foo module
|
If you have two modules, foo.ko and bar.ko, where
|
||||||
./bar/ <= contains the bar module
|
foo.ko needs symbols from bar.ko, you can use a
|
||||||
The top-level Kbuild file would then look like:
|
common top-level kbuild file so both modules are
|
||||||
|
compiled in the same build. Consider the following
|
||||||
|
directory layout:
|
||||||
|
|
||||||
#./Kbuild: (this file may also be named Makefile)
|
./foo/ <= contains foo.ko
|
||||||
|
./bar/ <= contains bar.ko
|
||||||
|
|
||||||
|
The top-level kbuild file would then look like:
|
||||||
|
|
||||||
|
#./Kbuild (or ./Makefile):
|
||||||
obj-y := foo/ bar/
|
obj-y := foo/ bar/
|
||||||
|
|
||||||
Executing:
|
And executing
|
||||||
make -C $KDIR M=`pwd`
|
|
||||||
|
|
||||||
will then do the expected and compile both modules with full
|
$ make -C $KDIR M=$PWD
|
||||||
knowledge on symbols from both modules.
|
|
||||||
|
will then do the expected and compile both modules with
|
||||||
|
full knowledge of symbols from either module.
|
||||||
|
|
||||||
Use an extra Module.symvers file
|
Use an extra Module.symvers file
|
||||||
When an external module is built, a Module.symvers file is
|
When an external module is built, a Module.symvers file
|
||||||
generated containing all exported symbols which are not
|
is generated containing all exported symbols which are
|
||||||
defined in the kernel.
|
not defined in the kernel. To get access to symbols
|
||||||
To get access to symbols from module 'bar', one can copy the
|
from bar.ko, copy the Module.symvers file from the
|
||||||
Module.symvers file from the compilation of the 'bar' module
|
compilation of bar.ko to the directory where foo.ko is
|
||||||
to the directory where the 'foo' module is built.
|
built. During the module build, kbuild will read the
|
||||||
During the module build, kbuild will read the Module.symvers
|
Module.symvers file in the directory of the external
|
||||||
file in the directory of the external module and when the
|
module, and when the build is finished, a new
|
||||||
build is finished, a new Module.symvers file is created
|
Module.symvers file is created containing the sum of
|
||||||
containing the sum of all symbols defined and not part of the
|
all symbols defined and not part of the kernel.
|
||||||
kernel.
|
|
||||||
|
|
||||||
Use make variable KBUILD_EXTRA_SYMBOLS in the Makefile
|
Use "make" variable KBUILD_EXTRA_SYMBOLS
|
||||||
If it is impractical to copy Module.symvers from another
|
If it is impractical to copy Module.symvers from
|
||||||
module, you can assign a space separated list of files to
|
another module, you can assign a space separated list
|
||||||
KBUILD_EXTRA_SYMBOLS in your Makfile. These files will be
|
of files to KBUILD_EXTRA_SYMBOLS in your build file.
|
||||||
loaded by modpost during the initialisation of its symbol
|
These files will be loaded by modpost during the
|
||||||
tables.
|
initialization of its symbol tables.
|
||||||
|
|
||||||
=== 8. Tips & Tricks
|
|
||||||
|
|
||||||
--- 8.1 Testing for CONFIG_FOO_BAR
|
=== 7. Tips & Tricks
|
||||||
|
|
||||||
Modules often need to check for certain CONFIG_ options to decide if
|
--- 7.1 Testing for CONFIG_FOO_BAR
|
||||||
a specific feature shall be included in the module. When kbuild is used
|
|
||||||
this is done by referencing the CONFIG_ variable directly.
|
Modules often need to check for certain CONFIG_ options to
|
||||||
|
decide if a specific feature is included in the module. In
|
||||||
|
kbuild this is done by referencing the CONFIG_ variable
|
||||||
|
directly.
|
||||||
|
|
||||||
#fs/ext2/Makefile
|
#fs/ext2/Makefile
|
||||||
obj-$(CONFIG_EXT2_FS) += ext2.o
|
obj-$(CONFIG_EXT2_FS) += ext2.o
|
||||||
|
@ -544,9 +533,9 @@ Module.symvers contains a list of all exported symbols from a kernel build.
|
||||||
ext2-y := balloc.o bitmap.o dir.o
|
ext2-y := balloc.o bitmap.o dir.o
|
||||||
ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o
|
ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o
|
||||||
|
|
||||||
External modules have traditionally used grep to check for specific
|
External modules have traditionally used "grep" to check for
|
||||||
CONFIG_ settings directly in .config. This usage is broken.
|
specific CONFIG_ settings directly in .config. This usage is
|
||||||
As introduced before, external modules shall use kbuild when building
|
broken. As introduced before, external modules should use
|
||||||
and therefore can use the same methods as in-kernel modules when
|
kbuild for building and can therefore use the same methods as
|
||||||
testing for CONFIG_ definitions.
|
in-tree modules when testing for CONFIG_ definitions.
|
||||||
|
|
||||||
|
|
|
@ -706,7 +706,7 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
arch/x86/kernel/cpu/cpufreq/elanfreq.c.
|
arch/x86/kernel/cpu/cpufreq/elanfreq.c.
|
||||||
|
|
||||||
elevator= [IOSCHED]
|
elevator= [IOSCHED]
|
||||||
Format: {"anticipatory" | "cfq" | "deadline" | "noop"}
|
Format: {"cfq" | "deadline" | "noop"}
|
||||||
See Documentation/block/as-iosched.txt and
|
See Documentation/block/as-iosched.txt and
|
||||||
Documentation/block/deadline-iosched.txt for details.
|
Documentation/block/deadline-iosched.txt for details.
|
||||||
|
|
||||||
|
@ -1541,12 +1541,15 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
1 to enable accounting
|
1 to enable accounting
|
||||||
Default value is 0.
|
Default value is 0.
|
||||||
|
|
||||||
nfsaddrs= [NFS]
|
nfsaddrs= [NFS] Deprecated. Use ip= instead.
|
||||||
See Documentation/filesystems/nfs/nfsroot.txt.
|
See Documentation/filesystems/nfs/nfsroot.txt.
|
||||||
|
|
||||||
nfsroot= [NFS] nfs root filesystem for disk-less boxes.
|
nfsroot= [NFS] nfs root filesystem for disk-less boxes.
|
||||||
See Documentation/filesystems/nfs/nfsroot.txt.
|
See Documentation/filesystems/nfs/nfsroot.txt.
|
||||||
|
|
||||||
|
nfsrootdebug [NFS] enable nfsroot debugging messages.
|
||||||
|
See Documentation/filesystems/nfs/nfsroot.txt.
|
||||||
|
|
||||||
nfs.callback_tcpport=
|
nfs.callback_tcpport=
|
||||||
[NFS] set the TCP port on which the NFSv4 callback
|
[NFS] set the TCP port on which the NFSv4 callback
|
||||||
channel should listen.
|
channel should listen.
|
||||||
|
@ -2172,6 +2175,11 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
reset_devices [KNL] Force drivers to reset the underlying device
|
reset_devices [KNL] Force drivers to reset the underlying device
|
||||||
during initialization.
|
during initialization.
|
||||||
|
|
||||||
|
resource_alloc_from_bottom
|
||||||
|
Allocate new resources from the beginning of available
|
||||||
|
space, not the end. If you need to use this, please
|
||||||
|
report a bug.
|
||||||
|
|
||||||
resume= [SWSUSP]
|
resume= [SWSUSP]
|
||||||
Specify the partition device for software suspend
|
Specify the partition device for software suspend
|
||||||
|
|
||||||
|
@ -2377,6 +2385,11 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
improve throughput, but will also increase the
|
improve throughput, but will also increase the
|
||||||
amount of memory reserved for use by the client.
|
amount of memory reserved for use by the client.
|
||||||
|
|
||||||
|
swapaccount[=0|1]
|
||||||
|
[KNL] Enable accounting of swap in memory resource
|
||||||
|
controller if no parameter or 1 is given or disable
|
||||||
|
it if 0 is given (See Documentation/cgroups/memory.txt)
|
||||||
|
|
||||||
swiotlb= [IA-64] Number of I/O TLB slabs
|
swiotlb= [IA-64] Number of I/O TLB slabs
|
||||||
|
|
||||||
switches= [HW,M68k]
|
switches= [HW,M68k]
|
||||||
|
@ -2438,7 +2451,7 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
topology informations if the hardware supports these.
|
topology informations if the hardware supports these.
|
||||||
The scheduler will make use of these informations and
|
The scheduler will make use of these informations and
|
||||||
e.g. base its process migration decisions on it.
|
e.g. base its process migration decisions on it.
|
||||||
Default is off.
|
Default is on.
|
||||||
|
|
||||||
tp720= [HW,PS2]
|
tp720= [HW,PS2]
|
||||||
|
|
||||||
|
|
|
@ -60,15 +60,18 @@ Hardware accelerated blink of LEDs
|
||||||
|
|
||||||
Some LEDs can be programmed to blink without any CPU interaction. To
|
Some LEDs can be programmed to blink without any CPU interaction. To
|
||||||
support this feature, a LED driver can optionally implement the
|
support this feature, a LED driver can optionally implement the
|
||||||
blink_set() function (see <linux/leds.h>). If implemented, triggers can
|
blink_set() function (see <linux/leds.h>). To set an LED to blinking,
|
||||||
attempt to use it before falling back to software timers. The blink_set()
|
however, it is better to use use the API function led_blink_set(),
|
||||||
function should return 0 if the blink setting is supported, or -EINVAL
|
as it will check and implement software fallback if necessary.
|
||||||
otherwise, which means that LED blinking will be handled by software.
|
|
||||||
|
|
||||||
The blink_set() function should choose a user friendly blinking
|
To turn off blinking again, use the API function led_brightness_set()
|
||||||
value if it is called with *delay_on==0 && *delay_off==0 parameters. In
|
as that will not just set the LED brightness but also stop any software
|
||||||
this case the driver should give back the chosen value through delay_on
|
timers that may have been required for blinking.
|
||||||
and delay_off parameters to the leds subsystem.
|
|
||||||
|
The blink_set() function should choose a user friendly blinking value
|
||||||
|
if it is called with *delay_on==0 && *delay_off==0 parameters. In this
|
||||||
|
case the driver should give back the chosen value through delay_on and
|
||||||
|
delay_off parameters to the leds subsystem.
|
||||||
|
|
||||||
Setting the brightness to zero with brightness_set() callback function
|
Setting the brightness to zero with brightness_set() callback function
|
||||||
should completely turn off the LED and cancel the previously programmed
|
should completely turn off the LED and cancel the previously programmed
|
||||||
|
|
88
Documentation/leds/leds-lp5521.txt
Normal file
88
Documentation/leds/leds-lp5521.txt
Normal file
|
@ -0,0 +1,88 @@
|
||||||
|
Kernel driver for lp5521
|
||||||
|
========================
|
||||||
|
|
||||||
|
* National Semiconductor LP5521 led driver chip
|
||||||
|
* Datasheet: http://www.national.com/pf/LP/LP5521.html
|
||||||
|
|
||||||
|
Authors: Mathias Nyman, Yuri Zaporozhets, Samu Onkalo
|
||||||
|
Contact: Samu Onkalo (samu.p.onkalo-at-nokia.com)
|
||||||
|
|
||||||
|
Description
|
||||||
|
-----------
|
||||||
|
|
||||||
|
LP5521 can drive up to 3 channels. Leds can be controlled directly via
|
||||||
|
the led class control interface. Channels have generic names:
|
||||||
|
lp5521:channelx, where x is 0 .. 2
|
||||||
|
|
||||||
|
All three channels can be also controlled using the engine micro programs.
|
||||||
|
More details of the instructions can be found from the public data sheet.
|
||||||
|
|
||||||
|
Control interface for the engines:
|
||||||
|
x is 1 .. 3
|
||||||
|
enginex_mode : disabled, load, run
|
||||||
|
enginex_load : store program (visible only in engine load mode)
|
||||||
|
|
||||||
|
Example (start to blink the channel 2 led):
|
||||||
|
cd /sys/class/leds/lp5521:channel2/device
|
||||||
|
echo "load" > engine3_mode
|
||||||
|
echo "037f4d0003ff6000" > engine3_load
|
||||||
|
echo "run" > engine3_mode
|
||||||
|
|
||||||
|
stop the engine:
|
||||||
|
echo "disabled" > engine3_mode
|
||||||
|
|
||||||
|
sysfs contains a selftest entry.
|
||||||
|
The test communicates with the chip and checks that
|
||||||
|
the clock mode is automatically set to the requested one.
|
||||||
|
|
||||||
|
Each channel has its own led current settings.
|
||||||
|
/sys/class/leds/lp5521:channel0/led_current - RW
|
||||||
|
/sys/class/leds/lp5521:channel0/max_current - RO
|
||||||
|
Format: 10x mA i.e 10 means 1.0 mA
|
||||||
|
|
||||||
|
example platform data:
|
||||||
|
|
||||||
|
Note: chan_nr can have values between 0 and 2.
|
||||||
|
|
||||||
|
static struct lp5521_led_config lp5521_led_config[] = {
|
||||||
|
{
|
||||||
|
.chan_nr = 0,
|
||||||
|
.led_current = 50,
|
||||||
|
.max_current = 130,
|
||||||
|
}, {
|
||||||
|
.chan_nr = 1,
|
||||||
|
.led_current = 0,
|
||||||
|
.max_current = 130,
|
||||||
|
}, {
|
||||||
|
.chan_nr = 2,
|
||||||
|
.led_current = 0,
|
||||||
|
.max_current = 130,
|
||||||
|
}
|
||||||
|
};
|
||||||
|
|
||||||
|
static int lp5521_setup(void)
|
||||||
|
{
|
||||||
|
/* setup HW resources */
|
||||||
|
}
|
||||||
|
|
||||||
|
static void lp5521_release(void)
|
||||||
|
{
|
||||||
|
/* Release HW resources */
|
||||||
|
}
|
||||||
|
|
||||||
|
static void lp5521_enable(bool state)
|
||||||
|
{
|
||||||
|
/* Control of chip enable signal */
|
||||||
|
}
|
||||||
|
|
||||||
|
static struct lp5521_platform_data lp5521_platform_data = {
|
||||||
|
.led_config = lp5521_led_config,
|
||||||
|
.num_channels = ARRAY_SIZE(lp5521_led_config),
|
||||||
|
.clock_mode = LP5521_CLOCK_EXT,
|
||||||
|
.setup_resources = lp5521_setup,
|
||||||
|
.release_resources = lp5521_release,
|
||||||
|
.enable = lp5521_enable,
|
||||||
|
};
|
||||||
|
|
||||||
|
If the current is set to 0 in the platform data, that channel is
|
||||||
|
disabled and it is not visible in the sysfs.
|
83
Documentation/leds/leds-lp5523.txt
Normal file
83
Documentation/leds/leds-lp5523.txt
Normal file
|
@ -0,0 +1,83 @@
|
||||||
|
Kernel driver for lp5523
|
||||||
|
========================
|
||||||
|
|
||||||
|
* National Semiconductor LP5523 led driver chip
|
||||||
|
* Datasheet: http://www.national.com/pf/LP/LP5523.html
|
||||||
|
|
||||||
|
Authors: Mathias Nyman, Yuri Zaporozhets, Samu Onkalo
|
||||||
|
Contact: Samu Onkalo (samu.p.onkalo-at-nokia.com)
|
||||||
|
|
||||||
|
Description
|
||||||
|
-----------
|
||||||
|
LP5523 can drive up to 9 channels. Leds can be controlled directly via
|
||||||
|
the led class control interface. Channels have generic names:
|
||||||
|
lp5523:channelx where x is 0...8
|
||||||
|
|
||||||
|
The chip provides 3 engines. Each engine can control channels without
|
||||||
|
interaction from the main CPU. Details of the micro engine code can be found
|
||||||
|
from the public data sheet. Leds can be muxed to different channels.
|
||||||
|
|
||||||
|
Control interface for the engines:
|
||||||
|
x is 1 .. 3
|
||||||
|
enginex_mode : disabled, load, run
|
||||||
|
enginex_load : microcode load (visible only in load mode)
|
||||||
|
enginex_leds : led mux control (visible only in load mode)
|
||||||
|
|
||||||
|
cd /sys/class/leds/lp5523:channel2/device
|
||||||
|
echo "load" > engine3_mode
|
||||||
|
echo "9d80400004ff05ff437f0000" > engine3_load
|
||||||
|
echo "111111111" > engine3_leds
|
||||||
|
echo "run" > engine3_mode
|
||||||
|
|
||||||
|
sysfs contains a selftest entry. It measures each channel
|
||||||
|
voltage level and checks if it looks reasonable. If the level is too high,
|
||||||
|
the led is missing; if the level is too low, there is a short circuit.
|
||||||
|
|
||||||
|
Selftest uses always the current from the platform data.
|
||||||
|
|
||||||
|
Each channel contains led current settings.
|
||||||
|
/sys/class/leds/lp5523:channel2/led_current - RW
|
||||||
|
/sys/class/leds/lp5523:channel2/max_current - RO
|
||||||
|
Format: 10x mA i.e 10 means 1.0 mA
|
||||||
|
|
||||||
|
Example platform data:
|
||||||
|
|
||||||
|
Note - chan_nr can have values between 0 and 8.
|
||||||
|
|
||||||
|
static struct lp5523_led_config lp5523_led_config[] = {
|
||||||
|
{
|
||||||
|
.chan_nr = 0,
|
||||||
|
.led_current = 50,
|
||||||
|
.max_current = 130,
|
||||||
|
},
|
||||||
|
...
|
||||||
|
}, {
|
||||||
|
.chan_nr = 8,
|
||||||
|
.led_current = 50,
|
||||||
|
.max_current = 130,
|
||||||
|
}
|
||||||
|
};
|
||||||
|
|
||||||
|
static int lp5523_setup(void)
|
||||||
|
{
|
||||||
|
/* Setup HW resources */
|
||||||
|
}
|
||||||
|
|
||||||
|
static void lp5523_release(void)
|
||||||
|
{
|
||||||
|
/* Release HW resources */
|
||||||
|
}
|
||||||
|
|
||||||
|
static void lp5523_enable(bool state)
|
||||||
|
{
|
||||||
|
/* Control chip enable signal */
|
||||||
|
}
|
||||||
|
|
||||||
|
static struct lp5523_platform_data lp5523_platform_data = {
|
||||||
|
.led_config = lp5523_led_config,
|
||||||
|
.num_channels = ARRAY_SIZE(lp5523_led_config),
|
||||||
|
.clock_mode = LP5523_CLOCK_EXT,
|
||||||
|
.setup_resources = lp5523_setup,
|
||||||
|
.release_resources = lp5523_release,
|
||||||
|
.enable = lp5523_enable,
|
||||||
|
};
|
111
Documentation/misc-devices/apds990x.txt
Normal file
111
Documentation/misc-devices/apds990x.txt
Normal file
|
@ -0,0 +1,111 @@
|
||||||
|
Kernel driver apds990x
|
||||||
|
======================
|
||||||
|
|
||||||
|
Supported chips:
|
||||||
|
Avago APDS990X
|
||||||
|
|
||||||
|
Data sheet:
|
||||||
|
Not freely available
|
||||||
|
|
||||||
|
Author:
|
||||||
|
Samu Onkalo <samu.p.onkalo@nokia.com>
|
||||||
|
|
||||||
|
Description
|
||||||
|
-----------
|
||||||
|
|
||||||
|
APDS990x is a combined ambient light and proximity sensor. ALS and proximity
|
||||||
|
functionality are highly connected. ALS measurement path must be running
|
||||||
|
while the proximity functionality is enabled.
|
||||||
|
|
||||||
|
ALS produces raw measurement values for two channels: Clear channel
|
||||||
|
(infrared + visible light) and IR only. However, threshold comparisons happen
|
||||||
|
using clear channel only. Lux value and the threshold level on the HW
|
||||||
|
might vary quite much depending the spectrum of the light source.
|
||||||
|
|
||||||
|
Driver makes necessary conversions to both directions so that user handles
|
||||||
|
only lux values. Lux value is calculated using information from the both
|
||||||
|
channels. HW threshold level is calculated from the given lux value to match
|
||||||
|
with current type of the lightning. Sometimes inaccuracy of the estimations
|
||||||
|
lead to false interrupt, but that doesn't harm.
|
||||||
|
|
||||||
|
ALS contains 4 different gain steps. Driver automatically
|
||||||
|
selects suitable gain step. After each measurement, reliability of the results
|
||||||
|
is estimated and new measurement is trigged if necessary.
|
||||||
|
|
||||||
|
Platform data can provide tuned values to the conversion formulas if
|
||||||
|
values are known. Otherwise plain sensor default values are used.
|
||||||
|
|
||||||
|
Proximity side is little bit simpler. There is no need for complex conversions.
|
||||||
|
It produces directly usable values.
|
||||||
|
|
||||||
|
Driver controls chip operational state using pm_runtime framework.
|
||||||
|
Voltage regulators are controlled based on chip operational state.
|
||||||
|
|
||||||
|
SYSFS
|
||||||
|
-----
|
||||||
|
|
||||||
|
|
||||||
|
chip_id
|
||||||
|
RO - shows detected chip type and version
|
||||||
|
|
||||||
|
power_state
|
||||||
|
RW - enable / disable chip. Uses counting logic
|
||||||
|
1 enables the chip
|
||||||
|
0 disables the chip
|
||||||
|
lux0_input
|
||||||
|
RO - measured lux value
|
||||||
|
sysfs_notify called when threshold interrupt occurs
|
||||||
|
|
||||||
|
lux0_sensor_range
|
||||||
|
RO - lux0_input max value. Actually never reaches since sensor tends
|
||||||
|
to saturate much before that. Real max value varies depending
|
||||||
|
on the light spectrum etc.
|
||||||
|
|
||||||
|
lux0_rate
|
||||||
|
RW - measurement rate in Hz
|
||||||
|
|
||||||
|
lux0_rate_avail
|
||||||
|
RO - supported measurement rates
|
||||||
|
|
||||||
|
lux0_calibscale
|
||||||
|
RW - calibration value. Set to neutral value by default.
|
||||||
|
Output results are multiplied with calibscale / calibscale_default
|
||||||
|
value.
|
||||||
|
|
||||||
|
lux0_calibscale_default
|
||||||
|
RO - neutral calibration value
|
||||||
|
|
||||||
|
lux0_thresh_above_value
|
||||||
|
RW - HI level threshold value. All results above the value
|
||||||
|
trigs an interrupt. 65535 (i.e. sensor_range) disables the above
|
||||||
|
interrupt.
|
||||||
|
|
||||||
|
lux0_thresh_below_value
|
||||||
|
RW - LO level threshold value. All results below the value
|
||||||
|
trigs an interrupt. 0 disables the below interrupt.
|
||||||
|
|
||||||
|
prox0_raw
|
||||||
|
RO - measured proximity value
|
||||||
|
sysfs_notify called when threshold interrupt occurs
|
||||||
|
|
||||||
|
prox0_sensor_range
|
||||||
|
RO - prox0_raw max value (1023)
|
||||||
|
|
||||||
|
prox0_raw_en
|
||||||
|
RW - enable / disable proximity - uses counting logic
|
||||||
|
1 enables the proximity
|
||||||
|
0 disables the proximity
|
||||||
|
|
||||||
|
prox0_reporting_mode
|
||||||
|
RW - trigger / periodic. In "trigger" mode the driver tells two possible
|
||||||
|
values: 0 or prox0_sensor_range value. 0 means no proximity,
|
||||||
|
1023 means proximity. This causes minimal number of interrupts.
|
||||||
|
In "periodic" mode the driver reports all values above
|
||||||
|
prox0_thresh_above. This causes more interrupts, but it can give
|
||||||
|
_rough_ estimate about the distance.
|
||||||
|
|
||||||
|
prox0_reporting_mode_avail
|
||||||
|
RO - accepted values to prox0_reporting_mode (trigger, periodic)
|
||||||
|
|
||||||
|
prox0_thresh_above_value
|
||||||
|
RW - threshold level which trigs proximity events.
|
116
Documentation/misc-devices/bh1770glc.txt
Normal file
116
Documentation/misc-devices/bh1770glc.txt
Normal file
|
@ -0,0 +1,116 @@
|
||||||
|
Kernel driver bh1770glc
|
||||||
|
=======================
|
||||||
|
|
||||||
|
Supported chips:
|
||||||
|
ROHM BH1770GLC
|
||||||
|
OSRAM SFH7770
|
||||||
|
|
||||||
|
Data sheet:
|
||||||
|
Not freely available
|
||||||
|
|
||||||
|
Author:
|
||||||
|
Samu Onkalo <samu.p.onkalo@nokia.com>
|
||||||
|
|
||||||
|
Description
|
||||||
|
-----------
|
||||||
|
BH1770GLC and SFH7770 are combined ambient light and proximity sensors.
|
||||||
|
ALS and proximity parts operates on their own, but they shares common I2C
|
||||||
|
interface and interrupt logic. In principle they can run on their own,
|
||||||
|
but ALS side results are used to estimate reliability of the proximity sensor.
|
||||||
|
|
||||||
|
ALS produces 16 bit lux values. The chip contains interrupt logic to produce
|
||||||
|
low and high threshold interrupts.
|
||||||
|
|
||||||
|
Proximity part contains IR-led driver up to 3 IR leds. The chip measures
|
||||||
|
amount of reflected IR light and produces proximity result. Resolution is
|
||||||
|
8 bit. Driver supports only one channel. Driver uses ALS results to estimate
|
||||||
|
reliability of the proximity results. Thus ALS is always running while
|
||||||
|
proximity detection is needed.
|
||||||
|
|
||||||
|
Driver uses threshold interrupts to avoid need for polling the values.
|
||||||
|
Proximity low interrupt doesn't exists in the chip. This is simulated
|
||||||
|
by using a delayed work. As long as there is proximity threshold above
|
||||||
|
interrupts the delayed work is pushed forward. So, when proximity level goes
|
||||||
|
below the threshold value, there is no interrupt and the delayed work will
|
||||||
|
finally run. This is handled as no proximity indication.
|
||||||
|
|
||||||
|
Chip state is controlled via runtime pm framework when enabled in config.
|
||||||
|
|
||||||
|
Calibscale factor is used to hide differences between the chips. By default
|
||||||
|
value set to neutral state meaning factor of 1.00. To get proper values,
|
||||||
|
calibrated source of light is needed as a reference. Calibscale factor is set
|
||||||
|
so that measurement produces about the expected lux value.
|
||||||
|
|
||||||
|
SYSFS
|
||||||
|
-----
|
||||||
|
|
||||||
|
chip_id
|
||||||
|
RO - shows detected chip type and version
|
||||||
|
|
||||||
|
power_state
|
||||||
|
RW - enable / disable chip. Uses counting logic
|
||||||
|
1 enables the chip
|
||||||
|
0 disables the chip
|
||||||
|
|
||||||
|
lux0_input
|
||||||
|
RO - measured lux value
|
||||||
|
sysfs_notify called when threshold interrupt occurs
|
||||||
|
|
||||||
|
lux0_sensor_range
|
||||||
|
RO - lux0_input max value
|
||||||
|
|
||||||
|
lux0_rate
|
||||||
|
RW - measurement rate in Hz
|
||||||
|
|
||||||
|
lux0_rate_avail
|
||||||
|
RO - supported measurement rates
|
||||||
|
|
||||||
|
lux0_thresh_above_value
|
||||||
|
RW - HI level threshold value. All results above the value
|
||||||
|
trigs an interrupt. 65535 (i.e. sensor_range) disables the above
|
||||||
|
interrupt.
|
||||||
|
|
||||||
|
lux0_thresh_below_value
|
||||||
|
RW - LO level threshold value. All results below the value
|
||||||
|
trigs an interrupt. 0 disables the below interrupt.
|
||||||
|
|
||||||
|
lux0_calibscale
|
||||||
|
RW - calibration value. Set to neutral value by default.
|
||||||
|
Output results are multiplied with calibscale / calibscale_default
|
||||||
|
value.
|
||||||
|
|
||||||
|
lux0_calibscale_default
|
||||||
|
RO - neutral calibration value
|
||||||
|
|
||||||
|
prox0_raw
|
||||||
|
RO - measured proximity value
|
||||||
|
sysfs_notify called when threshold interrupt occurs
|
||||||
|
|
||||||
|
prox0_sensor_range
|
||||||
|
RO - prox0_raw max value
|
||||||
|
|
||||||
|
prox0_raw_en
|
||||||
|
RW - enable / disable proximity - uses counting logic
|
||||||
|
1 enables the proximity
|
||||||
|
0 disables the proximity
|
||||||
|
|
||||||
|
prox0_thresh_above_count
|
||||||
|
RW - number of proximity interrupts needed before triggering the event
|
||||||
|
|
||||||
|
prox0_rate_above
|
||||||
|
RW - Measurement rate (in Hz) when the level is above threshold
|
||||||
|
i.e. when proximity on has been reported.
|
||||||
|
|
||||||
|
prox0_rate_below
|
||||||
|
RW - Measurement rate (in Hz) when the level is below threshold
|
||||||
|
i.e. when proximity off has been reported.
|
||||||
|
|
||||||
|
prox0_rate_avail
|
||||||
|
RO - Supported proximity measurement rates in Hz
|
||||||
|
|
||||||
|
prox0_thresh_above0_value
|
||||||
|
RW - threshold level which trigs proximity events.
|
||||||
|
Filtered by persistence filter (prox0_thresh_above_count)
|
||||||
|
|
||||||
|
prox0_thresh_above1_value
|
||||||
|
RW - threshold level which trigs event immediately
|
|
@ -20,6 +20,15 @@ ip_no_pmtu_disc - BOOLEAN
|
||||||
min_pmtu - INTEGER
|
min_pmtu - INTEGER
|
||||||
default 562 - minimum discovered Path MTU
|
default 562 - minimum discovered Path MTU
|
||||||
|
|
||||||
|
route/max_size - INTEGER
|
||||||
|
Maximum number of routes allowed in the kernel. Increase
|
||||||
|
this when using large numbers of interfaces and/or routes.
|
||||||
|
|
||||||
|
neigh/default/gc_thresh3 - INTEGER
|
||||||
|
Maximum number of neighbor entries allowed. Increase this
|
||||||
|
when using large numbers of interfaces and when communicating
|
||||||
|
with large numbers of directly-connected peers.
|
||||||
|
|
||||||
mtu_expires - INTEGER
|
mtu_expires - INTEGER
|
||||||
Time, in seconds, that cached PMTU information is kept.
|
Time, in seconds, that cached PMTU information is kept.
|
||||||
|
|
||||||
|
@ -135,6 +144,7 @@ tcp_adv_win_scale - INTEGER
|
||||||
Count buffering overhead as bytes/2^tcp_adv_win_scale
|
Count buffering overhead as bytes/2^tcp_adv_win_scale
|
||||||
(if tcp_adv_win_scale > 0) or bytes-bytes/2^(-tcp_adv_win_scale),
|
(if tcp_adv_win_scale > 0) or bytes-bytes/2^(-tcp_adv_win_scale),
|
||||||
if it is <= 0.
|
if it is <= 0.
|
||||||
|
Possible values are [-31, 31], inclusive.
|
||||||
Default: 2
|
Default: 2
|
||||||
|
|
||||||
tcp_allowed_congestion_control - STRING
|
tcp_allowed_congestion_control - STRING
|
||||||
|
|
|
@ -177,18 +177,6 @@ Doing it all yourself
|
||||||
|
|
||||||
A convenience function to print out the PHY status neatly.
|
A convenience function to print out the PHY status neatly.
|
||||||
|
|
||||||
int phy_clear_interrupt(struct phy_device *phydev);
|
|
||||||
int phy_config_interrupt(struct phy_device *phydev, u32 interrupts);
|
|
||||||
|
|
||||||
Clear the PHY's interrupt, and configure which ones are allowed,
|
|
||||||
respectively. Currently only supports all on, or all off.
|
|
||||||
|
|
||||||
int phy_enable_interrupts(struct phy_device *phydev);
|
|
||||||
int phy_disable_interrupts(struct phy_device *phydev);
|
|
||||||
|
|
||||||
Functions which enable/disable PHY interrupts, clearing them
|
|
||||||
before and after, respectively.
|
|
||||||
|
|
||||||
int phy_start_interrupts(struct phy_device *phydev);
|
int phy_start_interrupts(struct phy_device *phydev);
|
||||||
int phy_stop_interrupts(struct phy_device *phydev);
|
int phy_stop_interrupts(struct phy_device *phydev);
|
||||||
|
|
||||||
|
@ -213,12 +201,6 @@ Doing it all yourself
|
||||||
Fills the phydev structure with up-to-date information about the current
|
Fills the phydev structure with up-to-date information about the current
|
||||||
settings in the PHY.
|
settings in the PHY.
|
||||||
|
|
||||||
void phy_sanitize_settings(struct phy_device *phydev)
|
|
||||||
|
|
||||||
Resolves differences between currently desired settings, and
|
|
||||||
supported settings for the given PHY device. Does not make
|
|
||||||
the changes in the hardware, though.
|
|
||||||
|
|
||||||
int phy_ethtool_sset(struct phy_device *phydev, struct ethtool_cmd *cmd);
|
int phy_ethtool_sset(struct phy_device *phydev, struct ethtool_cmd *cmd);
|
||||||
int phy_ethtool_gset(struct phy_device *phydev, struct ethtool_cmd *cmd);
|
int phy_ethtool_gset(struct phy_device *phydev, struct ethtool_cmd *cmd);
|
||||||
|
|
||||||
|
|
|
@ -37,6 +37,9 @@ Typical usage of the OPP library is as follows:
|
||||||
SoC framework -> modifies on required cases certain OPPs -> OPP layer
|
SoC framework -> modifies on required cases certain OPPs -> OPP layer
|
||||||
-> queries to search/retrieve information ->
|
-> queries to search/retrieve information ->
|
||||||
|
|
||||||
|
Architectures that provide a SoC framework for OPP should select ARCH_HAS_OPP
|
||||||
|
to make the OPP layer available.
|
||||||
|
|
||||||
OPP layer expects each domain to be represented by a unique device pointer. SoC
|
OPP layer expects each domain to be represented by a unique device pointer. SoC
|
||||||
framework registers a set of initial OPPs per device with the OPP layer. This
|
framework registers a set of initial OPPs per device with the OPP layer. This
|
||||||
list is expected to be an optimally small number typically around 5 per device.
|
list is expected to be an optimally small number typically around 5 per device.
|
||||||
|
|
|
@ -21,8 +21,8 @@ three rotations, respectively, to balance the tree), with slightly slower
|
||||||
To quote Linux Weekly News:
|
To quote Linux Weekly News:
|
||||||
|
|
||||||
There are a number of red-black trees in use in the kernel.
|
There are a number of red-black trees in use in the kernel.
|
||||||
The anticipatory, deadline, and CFQ I/O schedulers all employ
|
The deadline and CFQ I/O schedulers employ rbtrees to
|
||||||
rbtrees to track requests; the packet CD/DVD driver does the same.
|
track requests; the packet CD/DVD driver does the same.
|
||||||
The high-resolution timer code uses an rbtree to organize outstanding
|
The high-resolution timer code uses an rbtree to organize outstanding
|
||||||
timer requests. The ext3 filesystem tracks directory entries in a
|
timer requests. The ext3 filesystem tracks directory entries in a
|
||||||
red-black tree. Virtual memory areas (VMAs) are tracked with red-black
|
red-black tree. Virtual memory areas (VMAs) are tracked with red-black
|
||||||
|
|
|
@ -1,3 +1,50 @@
|
||||||
|
1 Release Date : Thur. May 03, 2010 09:12:45 PST 2009 -
|
||||||
|
(emaild-id:megaraidlinux@lsi.com)
|
||||||
|
Bo Yang
|
||||||
|
|
||||||
|
2 Current Version : 00.00.04.31-rc1
|
||||||
|
3 Older Version : 00.00.04.17.1-rc1
|
||||||
|
|
||||||
|
1. Add the Online Controller Reset (OCR) to the Driver.
|
||||||
|
OCR is the new feature for megaraid_sas driver which
|
||||||
|
will allow the fw to do the chip reset which will not
|
||||||
|
affact the OS behavious.
|
||||||
|
|
||||||
|
To add the OCR support, driver need to do:
|
||||||
|
a). reset the controller chips -- Xscale and Gen2 which
|
||||||
|
will change the function calls and add the reset function
|
||||||
|
related to this two chips.
|
||||||
|
|
||||||
|
b). during the reset, driver will store the pending cmds
|
||||||
|
which not returned by FW to driver's pending queue. Driver
|
||||||
|
will re-issue those pending cmds again to FW after the OCR
|
||||||
|
finished.
|
||||||
|
|
||||||
|
c). In driver's timeout routine, driver will report to
|
||||||
|
OS as reset. Also driver's queue routine will block the
|
||||||
|
cmds until the OCR finished.
|
||||||
|
|
||||||
|
d). in Driver's ISR routine, if driver get the FW state as
|
||||||
|
state change, FW in Failure status and FW support online controller
|
||||||
|
reset (OCR), driver will start to do the controller reset.
|
||||||
|
|
||||||
|
e). In driver's IOCTL routine, the application cmds will wait for the
|
||||||
|
OCR to finish, then issue the cmds to FW.
|
||||||
|
|
||||||
|
f). Before driver kill adapter, driver will do last chance of
|
||||||
|
OCR to see if driver can bring back the FW.
|
||||||
|
|
||||||
|
2. Add the support update flag to the driver to tell LSI megaraid_sas
|
||||||
|
application which driver will support the device update. So application
|
||||||
|
will not need to do the device update after application add/del the device
|
||||||
|
from the system.
|
||||||
|
3. In driver's timeout routine, driver will do three time reset if fw is in
|
||||||
|
failed state. Driver will kill adapter if can't bring back FW after the
|
||||||
|
this three times reset.
|
||||||
|
4. Add the input parameter max_sectors to 1MB support to our GEN2 controller.
|
||||||
|
customer can use the input paramenter max_sectors to add 1MB support to GEN2
|
||||||
|
controller.
|
||||||
|
|
||||||
1 Release Date : Thur. Oct 29, 2009 09:12:45 PST 2009 -
|
1 Release Date : Thur. Oct 29, 2009 09:12:45 PST 2009 -
|
||||||
(emaild-id:megaraidlinux@lsi.com)
|
(emaild-id:megaraidlinux@lsi.com)
|
||||||
Bo Yang
|
Bo Yang
|
||||||
|
|
|
@ -1,32 +0,0 @@
|
||||||
Clock framework on SuperH architecture
|
|
||||||
|
|
||||||
The framework on SH extends existing API by the function clk_set_rate_ex,
|
|
||||||
which prototype is as follows:
|
|
||||||
|
|
||||||
clk_set_rate_ex (struct clk *clk, unsigned long rate, int algo_id)
|
|
||||||
|
|
||||||
The algo_id parameter is used to specify algorithm used to recalculate clocks,
|
|
||||||
adjanced to clock, specified as first argument. It is assumed that algo_id==0
|
|
||||||
means no changes to adjanced clock
|
|
||||||
|
|
||||||
Internally, the clk_set_rate_ex forwards request to clk->ops->set_rate method,
|
|
||||||
if it is present in ops structure. The method should set the clock rate and adjust
|
|
||||||
all needed clocks according to the passed algo_id.
|
|
||||||
Exact values for algo_id are machine-dependent. For the sh7722, the following
|
|
||||||
values are defined:
|
|
||||||
|
|
||||||
NO_CHANGE = 0,
|
|
||||||
IUS_N1_N1, /* I:U = N:1, U:Sh = N:1 */
|
|
||||||
IUS_322, /* I:U:Sh = 3:2:2 */
|
|
||||||
IUS_522, /* I:U:Sh = 5:2:2 */
|
|
||||||
IUS_N11, /* I:U:Sh = N:1:1 */
|
|
||||||
SB_N1, /* Sh:B = N:1 */
|
|
||||||
SB3_N1, /* Sh:B3 = N:1 */
|
|
||||||
SB3_32, /* Sh:B3 = 3:2 */
|
|
||||||
SB3_43, /* Sh:B3 = 4:3 */
|
|
||||||
SB3_54, /* Sh:B3 = 5:4 */
|
|
||||||
BP_N1, /* B:P = N:1 */
|
|
||||||
IP_N1 /* I:P = N:1 */
|
|
||||||
|
|
||||||
Each of these constants means relation between clocks that can be set via the FRQCR
|
|
||||||
register
|
|
|
@ -300,6 +300,74 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
||||||
control correctly. If you have problems regarding this, try
|
control correctly. If you have problems regarding this, try
|
||||||
another ALSA compliant mixer (alsamixer works).
|
another ALSA compliant mixer (alsamixer works).
|
||||||
|
|
||||||
|
Module snd-azt1605
|
||||||
|
------------------
|
||||||
|
|
||||||
|
Module for Aztech Sound Galaxy soundcards based on the Aztech AZT1605
|
||||||
|
chipset.
|
||||||
|
|
||||||
|
port - port # for BASE (0x220,0x240,0x260,0x280)
|
||||||
|
wss_port - port # for WSS (0x530,0x604,0xe80,0xf40)
|
||||||
|
irq - IRQ # for WSS (7,9,10,11)
|
||||||
|
dma1 - DMA # for WSS playback (0,1,3)
|
||||||
|
dma2 - DMA # for WSS capture (0,1), -1 = disabled (default)
|
||||||
|
mpu_port - port # for MPU-401 UART (0x300,0x330), -1 = disabled (default)
|
||||||
|
mpu_irq - IRQ # for MPU-401 UART (3,5,7,9), -1 = disabled (default)
|
||||||
|
fm_port - port # for OPL3 (0x388), -1 = disabled (default)
|
||||||
|
|
||||||
|
This module supports multiple cards. It does not support autoprobe: port,
|
||||||
|
wss_port, irq and dma1 have to be specified. The other values are
|
||||||
|
optional.
|
||||||
|
|
||||||
|
"port" needs to match the BASE ADDRESS jumper on the card (0x220 or 0x240)
|
||||||
|
or the value stored in the card's EEPROM for cards that have an EEPROM and
|
||||||
|
their "CONFIG MODE" jumper set to "EEPROM SETTING". The other values can
|
||||||
|
be choosen freely from the options enumerated above.
|
||||||
|
|
||||||
|
If dma2 is specified and different from dma1, the card will operate in
|
||||||
|
full-duplex mode. When dma1=3, only dma2=0 is valid and the only way to
|
||||||
|
enable capture since only channels 0 and 1 are available for capture.
|
||||||
|
|
||||||
|
Generic settings are "port=0x220 wss_port=0x530 irq=10 dma1=1 dma2=0
|
||||||
|
mpu_port=0x330 mpu_irq=9 fm_port=0x388".
|
||||||
|
|
||||||
|
Whatever IRQ and DMA channels you pick, be sure to reserve them for
|
||||||
|
legacy ISA in your BIOS.
|
||||||
|
|
||||||
|
Module snd-azt2316
|
||||||
|
------------------
|
||||||
|
|
||||||
|
Module for Aztech Sound Galaxy soundcards based on the Aztech AZT2316
|
||||||
|
chipset.
|
||||||
|
|
||||||
|
port - port # for BASE (0x220,0x240,0x260,0x280)
|
||||||
|
wss_port - port # for WSS (0x530,0x604,0xe80,0xf40)
|
||||||
|
irq - IRQ # for WSS (7,9,10,11)
|
||||||
|
dma1 - DMA # for WSS playback (0,1,3)
|
||||||
|
dma2 - DMA # for WSS capture (0,1), -1 = disabled (default)
|
||||||
|
mpu_port - port # for MPU-401 UART (0x300,0x330), -1 = disabled (default)
|
||||||
|
mpu_irq - IRQ # for MPU-401 UART (5,7,9,10), -1 = disabled (default)
|
||||||
|
fm_port - port # for OPL3 (0x388), -1 = disabled (default)
|
||||||
|
|
||||||
|
This module supports multiple cards. It does not support autoprobe: port,
|
||||||
|
wss_port, irq and dma1 have to be specified. The other values are
|
||||||
|
optional.
|
||||||
|
|
||||||
|
"port" needs to match the BASE ADDRESS jumper on the card (0x220 or 0x240)
|
||||||
|
or the value stored in the card's EEPROM for cards that have an EEPROM and
|
||||||
|
their "CONFIG MODE" jumper set to "EEPROM SETTING". The other values can
|
||||||
|
be choosen freely from the options enumerated above.
|
||||||
|
|
||||||
|
If dma2 is specified and different from dma1, the card will operate in
|
||||||
|
full-duplex mode. When dma1=3, only dma2=0 is valid and the only way to
|
||||||
|
enable capture since only channels 0 and 1 are available for capture.
|
||||||
|
|
||||||
|
Generic settings are "port=0x220 wss_port=0x530 irq=10 dma1=1 dma2=0
|
||||||
|
mpu_port=0x330 mpu_irq=9 fm_port=0x388".
|
||||||
|
|
||||||
|
Whatever IRQ and DMA channels you pick, be sure to reserve them for
|
||||||
|
legacy ISA in your BIOS.
|
||||||
|
|
||||||
Module snd-aw2
|
Module snd-aw2
|
||||||
--------------
|
--------------
|
||||||
|
|
||||||
|
@ -1641,20 +1709,6 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
||||||
|
|
||||||
This card is also known as Audio Excel DSP 16 or Zoltrix AV302.
|
This card is also known as Audio Excel DSP 16 or Zoltrix AV302.
|
||||||
|
|
||||||
Module snd-sgalaxy
|
|
||||||
------------------
|
|
||||||
|
|
||||||
Module for Aztech Sound Galaxy sound card.
|
|
||||||
|
|
||||||
sbport - Port # for SB16 interface (0x220,0x240)
|
|
||||||
wssport - Port # for WSS interface (0x530,0xe80,0xf40,0x604)
|
|
||||||
irq - IRQ # (7,9,10,11)
|
|
||||||
dma1 - DMA #
|
|
||||||
|
|
||||||
This module supports multiple cards.
|
|
||||||
|
|
||||||
The power-management is supported.
|
|
||||||
|
|
||||||
Module snd-sscape
|
Module snd-sscape
|
||||||
-----------------
|
-----------------
|
||||||
|
|
||||||
|
|
|
@ -57,9 +57,11 @@ dead. However, this detection isn't perfect on some devices. In such
|
||||||
a case, you can change the default method via `position_fix` option.
|
a case, you can change the default method via `position_fix` option.
|
||||||
|
|
||||||
`position_fix=1` means to use LPIB method explicitly.
|
`position_fix=1` means to use LPIB method explicitly.
|
||||||
`position_fix=2` means to use the position-buffer. 0 is the default
|
`position_fix=2` means to use the position-buffer.
|
||||||
value, the automatic check and fallback to LPIB as described in the
|
`position_fix=3` means to use a combination of both methods, needed
|
||||||
above. If you get a problem of repeated sounds, this option might
|
for some VIA and ATI controllers. 0 is the default value for all other
|
||||||
|
controllers, the automatic check and fallback to LPIB as described in
|
||||||
|
the above. If you get a problem of repeated sounds, this option might
|
||||||
help.
|
help.
|
||||||
|
|
||||||
In addition to that, every controller is known to be broken regarding
|
In addition to that, every controller is known to be broken regarding
|
||||||
|
|
|
@ -28,6 +28,7 @@ show up in /proc/sys/kernel:
|
||||||
- core_uses_pid
|
- core_uses_pid
|
||||||
- ctrl-alt-del
|
- ctrl-alt-del
|
||||||
- dentry-state
|
- dentry-state
|
||||||
|
- dmesg_restrict
|
||||||
- domainname
|
- domainname
|
||||||
- hostname
|
- hostname
|
||||||
- hotplug
|
- hotplug
|
||||||
|
@ -213,6 +214,19 @@ to decide what to do with it.
|
||||||
|
|
||||||
==============================================================
|
==============================================================
|
||||||
|
|
||||||
|
dmesg_restrict:
|
||||||
|
|
||||||
|
This toggle indicates whether unprivileged users are prevented from using
|
||||||
|
dmesg(8) to view messages from the kernel's log buffer. When
|
||||||
|
dmesg_restrict is set to (0) there are no restrictions. When
|
||||||
|
dmesg_restrict is set set to (1), users must have CAP_SYS_ADMIN to use
|
||||||
|
dmesg(8).
|
||||||
|
|
||||||
|
The kernel config option CONFIG_SECURITY_DMESG_RESTRICT sets the default
|
||||||
|
value of dmesg_restrict.
|
||||||
|
|
||||||
|
==============================================================
|
||||||
|
|
||||||
domainname & hostname:
|
domainname & hostname:
|
||||||
|
|
||||||
These files can be used to set the NIS/YP domainname and the
|
These files can be used to set the NIS/YP domainname and the
|
||||||
|
|
|
@ -80,8 +80,10 @@ dirty_background_bytes
|
||||||
Contains the amount of dirty memory at which the pdflush background writeback
|
Contains the amount of dirty memory at which the pdflush background writeback
|
||||||
daemon will start writeback.
|
daemon will start writeback.
|
||||||
|
|
||||||
If dirty_background_bytes is written, dirty_background_ratio becomes a function
|
Note: dirty_background_bytes is the counterpart of dirty_background_ratio. Only
|
||||||
of its value (dirty_background_bytes / the amount of dirtyable system memory).
|
one of them may be specified at a time. When one sysctl is written it is
|
||||||
|
immediately taken into account to evaluate the dirty memory limits and the
|
||||||
|
other appears as 0 when read.
|
||||||
|
|
||||||
==============================================================
|
==============================================================
|
||||||
|
|
||||||
|
@ -97,8 +99,10 @@ dirty_bytes
|
||||||
Contains the amount of dirty memory at which a process generating disk writes
|
Contains the amount of dirty memory at which a process generating disk writes
|
||||||
will itself start writeback.
|
will itself start writeback.
|
||||||
|
|
||||||
If dirty_bytes is written, dirty_ratio becomes a function of its value
|
Note: dirty_bytes is the counterpart of dirty_ratio. Only one of them may be
|
||||||
(dirty_bytes / the amount of dirtyable system memory).
|
specified at a time. When one sysctl is written it is immediately taken into
|
||||||
|
account to evaluate the dirty memory limits and the other appears as 0 when
|
||||||
|
read.
|
||||||
|
|
||||||
Note: the minimum value allowed for dirty_bytes is two pages (in bytes); any
|
Note: the minimum value allowed for dirty_bytes is two pages (in bytes); any
|
||||||
value lower than this limit will be ignored and the old configuration will be
|
value lower than this limit will be ignored and the old configuration will be
|
||||||
|
|
|
@ -75,7 +75,7 @@ On all - write a character to /proc/sysrq-trigger. e.g.:
|
||||||
|
|
||||||
'f' - Will call oom_kill to kill a memory hog process.
|
'f' - Will call oom_kill to kill a memory hog process.
|
||||||
|
|
||||||
'g' - Used by kgdb on ppc and sh platforms.
|
'g' - Used by kgdb (kernel debugger)
|
||||||
|
|
||||||
'h' - Will display help (actually any other key than those listed
|
'h' - Will display help (actually any other key than those listed
|
||||||
here will display help. but 'h' is easy to remember :-)
|
here will display help. but 'h' is easy to remember :-)
|
||||||
|
@ -110,12 +110,15 @@ On all - write a character to /proc/sysrq-trigger. e.g.:
|
||||||
|
|
||||||
'u' - Will attempt to remount all mounted filesystems read-only.
|
'u' - Will attempt to remount all mounted filesystems read-only.
|
||||||
|
|
||||||
'v' - Dumps Voyager SMP processor info to your console.
|
'v' - Forcefully restores framebuffer console
|
||||||
|
'v' - Causes ETM buffer dump [ARM-specific]
|
||||||
|
|
||||||
'w' - Dumps tasks that are in uninterruptable (blocked) state.
|
'w' - Dumps tasks that are in uninterruptable (blocked) state.
|
||||||
|
|
||||||
'x' - Used by xmon interface on ppc/powerpc platforms.
|
'x' - Used by xmon interface on ppc/powerpc platforms.
|
||||||
|
|
||||||
|
'y' - Show global CPU Registers [SPARC-64 specific]
|
||||||
|
|
||||||
'z' - Dump the ftrace buffer
|
'z' - Dump the ftrace buffer
|
||||||
|
|
||||||
'0'-'9' - Sets the console log level, controlling which kernel messages
|
'0'-'9' - Sets the console log level, controlling which kernel messages
|
||||||
|
|
|
@ -97,6 +97,33 @@ hpet_open_close(int argc, const char **argv)
|
||||||
void
|
void
|
||||||
hpet_info(int argc, const char **argv)
|
hpet_info(int argc, const char **argv)
|
||||||
{
|
{
|
||||||
|
struct hpet_info info;
|
||||||
|
int fd;
|
||||||
|
|
||||||
|
if (argc != 1) {
|
||||||
|
fprintf(stderr, "hpet_info: device-name\n");
|
||||||
|
return;
|
||||||
|
}
|
||||||
|
|
||||||
|
fd = open(argv[0], O_RDONLY);
|
||||||
|
if (fd < 0) {
|
||||||
|
fprintf(stderr, "hpet_info: open of %s failed\n", argv[0]);
|
||||||
|
return;
|
||||||
|
}
|
||||||
|
|
||||||
|
if (ioctl(fd, HPET_INFO, &info) < 0) {
|
||||||
|
fprintf(stderr, "hpet_info: failed to get info\n");
|
||||||
|
goto out;
|
||||||
|
}
|
||||||
|
|
||||||
|
fprintf(stderr, "hpet_info: hi_irqfreq 0x%lx hi_flags 0x%lx ",
|
||||||
|
info.hi_ireqfreq, info.hi_flags);
|
||||||
|
fprintf(stderr, "hi_hpet %d hi_timer %d\n",
|
||||||
|
info.hi_hpet, info.hi_timer);
|
||||||
|
|
||||||
|
out:
|
||||||
|
close(fd);
|
||||||
|
return;
|
||||||
}
|
}
|
||||||
|
|
||||||
void
|
void
|
||||||
|
|
|
@ -46,7 +46,7 @@ use constant HIGH_KSWAPD_LATENCY => 20;
|
||||||
use constant HIGH_KSWAPD_REWAKEUP => 21;
|
use constant HIGH_KSWAPD_REWAKEUP => 21;
|
||||||
use constant HIGH_NR_SCANNED => 22;
|
use constant HIGH_NR_SCANNED => 22;
|
||||||
use constant HIGH_NR_TAKEN => 23;
|
use constant HIGH_NR_TAKEN => 23;
|
||||||
use constant HIGH_NR_RECLAIM => 24;
|
use constant HIGH_NR_RECLAIMED => 24;
|
||||||
use constant HIGH_NR_CONTIG_DIRTY => 25;
|
use constant HIGH_NR_CONTIG_DIRTY => 25;
|
||||||
|
|
||||||
my %perprocesspid;
|
my %perprocesspid;
|
||||||
|
@ -58,11 +58,13 @@ my $opt_read_procstat;
|
||||||
my $total_wakeup_kswapd;
|
my $total_wakeup_kswapd;
|
||||||
my ($total_direct_reclaim, $total_direct_nr_scanned);
|
my ($total_direct_reclaim, $total_direct_nr_scanned);
|
||||||
my ($total_direct_latency, $total_kswapd_latency);
|
my ($total_direct_latency, $total_kswapd_latency);
|
||||||
|
my ($total_direct_nr_reclaimed);
|
||||||
my ($total_direct_writepage_file_sync, $total_direct_writepage_file_async);
|
my ($total_direct_writepage_file_sync, $total_direct_writepage_file_async);
|
||||||
my ($total_direct_writepage_anon_sync, $total_direct_writepage_anon_async);
|
my ($total_direct_writepage_anon_sync, $total_direct_writepage_anon_async);
|
||||||
my ($total_kswapd_nr_scanned, $total_kswapd_wake);
|
my ($total_kswapd_nr_scanned, $total_kswapd_wake);
|
||||||
my ($total_kswapd_writepage_file_sync, $total_kswapd_writepage_file_async);
|
my ($total_kswapd_writepage_file_sync, $total_kswapd_writepage_file_async);
|
||||||
my ($total_kswapd_writepage_anon_sync, $total_kswapd_writepage_anon_async);
|
my ($total_kswapd_writepage_anon_sync, $total_kswapd_writepage_anon_async);
|
||||||
|
my ($total_kswapd_nr_reclaimed);
|
||||||
|
|
||||||
# Catch sigint and exit on request
|
# Catch sigint and exit on request
|
||||||
my $sigint_report = 0;
|
my $sigint_report = 0;
|
||||||
|
@ -104,7 +106,7 @@ my $regex_kswapd_wake_default = 'nid=([0-9]*) order=([0-9]*)';
|
||||||
my $regex_kswapd_sleep_default = 'nid=([0-9]*)';
|
my $regex_kswapd_sleep_default = 'nid=([0-9]*)';
|
||||||
my $regex_wakeup_kswapd_default = 'nid=([0-9]*) zid=([0-9]*) order=([0-9]*)';
|
my $regex_wakeup_kswapd_default = 'nid=([0-9]*) zid=([0-9]*) order=([0-9]*)';
|
||||||
my $regex_lru_isolate_default = 'isolate_mode=([0-9]*) order=([0-9]*) nr_requested=([0-9]*) nr_scanned=([0-9]*) nr_taken=([0-9]*) contig_taken=([0-9]*) contig_dirty=([0-9]*) contig_failed=([0-9]*)';
|
my $regex_lru_isolate_default = 'isolate_mode=([0-9]*) order=([0-9]*) nr_requested=([0-9]*) nr_scanned=([0-9]*) nr_taken=([0-9]*) contig_taken=([0-9]*) contig_dirty=([0-9]*) contig_failed=([0-9]*)';
|
||||||
my $regex_lru_shrink_inactive_default = 'lru=([A-Z_]*) nr_scanned=([0-9]*) nr_reclaimed=([0-9]*) priority=([0-9]*)';
|
my $regex_lru_shrink_inactive_default = 'nid=([0-9]*) zid=([0-9]*) nr_scanned=([0-9]*) nr_reclaimed=([0-9]*) priority=([0-9]*) flags=([A-Z_|]*)';
|
||||||
my $regex_lru_shrink_active_default = 'lru=([A-Z_]*) nr_scanned=([0-9]*) nr_rotated=([0-9]*) priority=([0-9]*)';
|
my $regex_lru_shrink_active_default = 'lru=([A-Z_]*) nr_scanned=([0-9]*) nr_rotated=([0-9]*) priority=([0-9]*)';
|
||||||
my $regex_writepage_default = 'page=([0-9a-f]*) pfn=([0-9]*) flags=([A-Z_|]*)';
|
my $regex_writepage_default = 'page=([0-9a-f]*) pfn=([0-9]*) flags=([A-Z_|]*)';
|
||||||
|
|
||||||
|
@ -203,8 +205,8 @@ $regex_lru_shrink_inactive = generate_traceevent_regex(
|
||||||
"vmscan/mm_vmscan_lru_shrink_inactive",
|
"vmscan/mm_vmscan_lru_shrink_inactive",
|
||||||
$regex_lru_shrink_inactive_default,
|
$regex_lru_shrink_inactive_default,
|
||||||
"nid", "zid",
|
"nid", "zid",
|
||||||
"lru",
|
"nr_scanned", "nr_reclaimed", "priority",
|
||||||
"nr_scanned", "nr_reclaimed", "priority");
|
"flags");
|
||||||
$regex_lru_shrink_active = generate_traceevent_regex(
|
$regex_lru_shrink_active = generate_traceevent_regex(
|
||||||
"vmscan/mm_vmscan_lru_shrink_active",
|
"vmscan/mm_vmscan_lru_shrink_active",
|
||||||
$regex_lru_shrink_active_default,
|
$regex_lru_shrink_active_default,
|
||||||
|
@ -375,6 +377,16 @@ EVENT_PROCESS:
|
||||||
my $nr_contig_dirty = $7;
|
my $nr_contig_dirty = $7;
|
||||||
$perprocesspid{$process_pid}->{HIGH_NR_SCANNED} += $nr_scanned;
|
$perprocesspid{$process_pid}->{HIGH_NR_SCANNED} += $nr_scanned;
|
||||||
$perprocesspid{$process_pid}->{HIGH_NR_CONTIG_DIRTY} += $nr_contig_dirty;
|
$perprocesspid{$process_pid}->{HIGH_NR_CONTIG_DIRTY} += $nr_contig_dirty;
|
||||||
|
} elsif ($tracepoint eq "mm_vmscan_lru_shrink_inactive") {
|
||||||
|
$details = $5;
|
||||||
|
if ($details !~ /$regex_lru_shrink_inactive/o) {
|
||||||
|
print "WARNING: Failed to parse mm_vmscan_lru_shrink_inactive as expected\n";
|
||||||
|
print " $details\n";
|
||||||
|
print " $regex_lru_shrink_inactive/o\n";
|
||||||
|
next;
|
||||||
|
}
|
||||||
|
my $nr_reclaimed = $4;
|
||||||
|
$perprocesspid{$process_pid}->{HIGH_NR_RECLAIMED} += $nr_reclaimed;
|
||||||
} elsif ($tracepoint eq "mm_vmscan_writepage") {
|
} elsif ($tracepoint eq "mm_vmscan_writepage") {
|
||||||
$details = $5;
|
$details = $5;
|
||||||
if ($details !~ /$regex_writepage/o) {
|
if ($details !~ /$regex_writepage/o) {
|
||||||
|
@ -464,8 +476,8 @@ sub dump_stats {
|
||||||
|
|
||||||
# Print out process activity
|
# Print out process activity
|
||||||
printf("\n");
|
printf("\n");
|
||||||
printf("%-" . $max_strlen . "s %8s %10s %8s %8s %8s %8s %8s\n", "Process", "Direct", "Wokeup", "Pages", "Pages", "Pages", "Time");
|
printf("%-" . $max_strlen . "s %8s %10s %8s %8s %8s %8s %8s %8s\n", "Process", "Direct", "Wokeup", "Pages", "Pages", "Pages", "Pages", "Time");
|
||||||
printf("%-" . $max_strlen . "s %8s %10s %8s %8s %8s %8s %8s\n", "details", "Rclms", "Kswapd", "Scanned", "Sync-IO", "ASync-IO", "Stalled");
|
printf("%-" . $max_strlen . "s %8s %10s %8s %8s %8s %8s %8s %8s\n", "details", "Rclms", "Kswapd", "Scanned", "Rclmed", "Sync-IO", "ASync-IO", "Stalled");
|
||||||
foreach $process_pid (keys %stats) {
|
foreach $process_pid (keys %stats) {
|
||||||
|
|
||||||
if (!$stats{$process_pid}->{MM_VMSCAN_DIRECT_RECLAIM_BEGIN}) {
|
if (!$stats{$process_pid}->{MM_VMSCAN_DIRECT_RECLAIM_BEGIN}) {
|
||||||
|
@ -475,6 +487,7 @@ sub dump_stats {
|
||||||
$total_direct_reclaim += $stats{$process_pid}->{MM_VMSCAN_DIRECT_RECLAIM_BEGIN};
|
$total_direct_reclaim += $stats{$process_pid}->{MM_VMSCAN_DIRECT_RECLAIM_BEGIN};
|
||||||
$total_wakeup_kswapd += $stats{$process_pid}->{MM_VMSCAN_WAKEUP_KSWAPD};
|
$total_wakeup_kswapd += $stats{$process_pid}->{MM_VMSCAN_WAKEUP_KSWAPD};
|
||||||
$total_direct_nr_scanned += $stats{$process_pid}->{HIGH_NR_SCANNED};
|
$total_direct_nr_scanned += $stats{$process_pid}->{HIGH_NR_SCANNED};
|
||||||
|
$total_direct_nr_reclaimed += $stats{$process_pid}->{HIGH_NR_RECLAIMED};
|
||||||
$total_direct_writepage_file_sync += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_SYNC};
|
$total_direct_writepage_file_sync += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_SYNC};
|
||||||
$total_direct_writepage_anon_sync += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_SYNC};
|
$total_direct_writepage_anon_sync += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_SYNC};
|
||||||
$total_direct_writepage_file_async += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_ASYNC};
|
$total_direct_writepage_file_async += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_ASYNC};
|
||||||
|
@ -489,11 +502,12 @@ sub dump_stats {
|
||||||
$index++;
|
$index++;
|
||||||
}
|
}
|
||||||
|
|
||||||
printf("%-" . $max_strlen . "s %8d %10d %8u %8u %8u %8.3f",
|
printf("%-" . $max_strlen . "s %8d %10d %8u %8u %8u %8u %8.3f",
|
||||||
$process_pid,
|
$process_pid,
|
||||||
$stats{$process_pid}->{MM_VMSCAN_DIRECT_RECLAIM_BEGIN},
|
$stats{$process_pid}->{MM_VMSCAN_DIRECT_RECLAIM_BEGIN},
|
||||||
$stats{$process_pid}->{MM_VMSCAN_WAKEUP_KSWAPD},
|
$stats{$process_pid}->{MM_VMSCAN_WAKEUP_KSWAPD},
|
||||||
$stats{$process_pid}->{HIGH_NR_SCANNED},
|
$stats{$process_pid}->{HIGH_NR_SCANNED},
|
||||||
|
$stats{$process_pid}->{HIGH_NR_RECLAIMED},
|
||||||
$stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_SYNC} + $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_SYNC},
|
$stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_SYNC} + $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_SYNC},
|
||||||
$stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_ASYNC} + $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_ASYNC},
|
$stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_ASYNC} + $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_ASYNC},
|
||||||
$this_reclaim_delay / 1000);
|
$this_reclaim_delay / 1000);
|
||||||
|
@ -529,8 +543,8 @@ sub dump_stats {
|
||||||
|
|
||||||
# Print out kswapd activity
|
# Print out kswapd activity
|
||||||
printf("\n");
|
printf("\n");
|
||||||
printf("%-" . $max_strlen . "s %8s %10s %8s %8s %8s %8s\n", "Kswapd", "Kswapd", "Order", "Pages", "Pages", "Pages");
|
printf("%-" . $max_strlen . "s %8s %10s %8s %8s %8s %8s\n", "Kswapd", "Kswapd", "Order", "Pages", "Pages", "Pages", "Pages");
|
||||||
printf("%-" . $max_strlen . "s %8s %10s %8s %8s %8s %8s\n", "Instance", "Wakeups", "Re-wakeup", "Scanned", "Sync-IO", "ASync-IO");
|
printf("%-" . $max_strlen . "s %8s %10s %8s %8s %8s %8s\n", "Instance", "Wakeups", "Re-wakeup", "Scanned", "Rclmed", "Sync-IO", "ASync-IO");
|
||||||
foreach $process_pid (keys %stats) {
|
foreach $process_pid (keys %stats) {
|
||||||
|
|
||||||
if (!$stats{$process_pid}->{MM_VMSCAN_KSWAPD_WAKE}) {
|
if (!$stats{$process_pid}->{MM_VMSCAN_KSWAPD_WAKE}) {
|
||||||
|
@ -539,16 +553,18 @@ sub dump_stats {
|
||||||
|
|
||||||
$total_kswapd_wake += $stats{$process_pid}->{MM_VMSCAN_KSWAPD_WAKE};
|
$total_kswapd_wake += $stats{$process_pid}->{MM_VMSCAN_KSWAPD_WAKE};
|
||||||
$total_kswapd_nr_scanned += $stats{$process_pid}->{HIGH_NR_SCANNED};
|
$total_kswapd_nr_scanned += $stats{$process_pid}->{HIGH_NR_SCANNED};
|
||||||
|
$total_kswapd_nr_reclaimed += $stats{$process_pid}->{HIGH_NR_RECLAIMED};
|
||||||
$total_kswapd_writepage_file_sync += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_SYNC};
|
$total_kswapd_writepage_file_sync += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_SYNC};
|
||||||
$total_kswapd_writepage_anon_sync += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_SYNC};
|
$total_kswapd_writepage_anon_sync += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_SYNC};
|
||||||
$total_kswapd_writepage_file_async += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_ASYNC};
|
$total_kswapd_writepage_file_async += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_ASYNC};
|
||||||
$total_kswapd_writepage_anon_async += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_ASYNC};
|
$total_kswapd_writepage_anon_async += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_ASYNC};
|
||||||
|
|
||||||
printf("%-" . $max_strlen . "s %8d %10d %8u %8i %8u",
|
printf("%-" . $max_strlen . "s %8d %10d %8u %8u %8i %8u",
|
||||||
$process_pid,
|
$process_pid,
|
||||||
$stats{$process_pid}->{MM_VMSCAN_KSWAPD_WAKE},
|
$stats{$process_pid}->{MM_VMSCAN_KSWAPD_WAKE},
|
||||||
$stats{$process_pid}->{HIGH_KSWAPD_REWAKEUP},
|
$stats{$process_pid}->{HIGH_KSWAPD_REWAKEUP},
|
||||||
$stats{$process_pid}->{HIGH_NR_SCANNED},
|
$stats{$process_pid}->{HIGH_NR_SCANNED},
|
||||||
|
$stats{$process_pid}->{HIGH_NR_RECLAIMED},
|
||||||
$stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_SYNC} + $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_SYNC},
|
$stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_SYNC} + $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_SYNC},
|
||||||
$stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_ASYNC} + $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_ASYNC});
|
$stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_ASYNC} + $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_ASYNC});
|
||||||
|
|
||||||
|
@ -579,6 +595,7 @@ sub dump_stats {
|
||||||
print "\nSummary\n";
|
print "\nSummary\n";
|
||||||
print "Direct reclaims: $total_direct_reclaim\n";
|
print "Direct reclaims: $total_direct_reclaim\n";
|
||||||
print "Direct reclaim pages scanned: $total_direct_nr_scanned\n";
|
print "Direct reclaim pages scanned: $total_direct_nr_scanned\n";
|
||||||
|
print "Direct reclaim pages reclaimed: $total_direct_nr_reclaimed\n";
|
||||||
print "Direct reclaim write file sync I/O: $total_direct_writepage_file_sync\n";
|
print "Direct reclaim write file sync I/O: $total_direct_writepage_file_sync\n";
|
||||||
print "Direct reclaim write anon sync I/O: $total_direct_writepage_anon_sync\n";
|
print "Direct reclaim write anon sync I/O: $total_direct_writepage_anon_sync\n";
|
||||||
print "Direct reclaim write file async I/O: $total_direct_writepage_file_async\n";
|
print "Direct reclaim write file async I/O: $total_direct_writepage_file_async\n";
|
||||||
|
@ -588,6 +605,7 @@ sub dump_stats {
|
||||||
print "\n";
|
print "\n";
|
||||||
print "Kswapd wakeups: $total_kswapd_wake\n";
|
print "Kswapd wakeups: $total_kswapd_wake\n";
|
||||||
print "Kswapd pages scanned: $total_kswapd_nr_scanned\n";
|
print "Kswapd pages scanned: $total_kswapd_nr_scanned\n";
|
||||||
|
print "Kswapd pages reclaimed: $total_kswapd_nr_reclaimed\n";
|
||||||
print "Kswapd reclaim write file sync I/O: $total_kswapd_writepage_file_sync\n";
|
print "Kswapd reclaim write file sync I/O: $total_kswapd_writepage_file_sync\n";
|
||||||
print "Kswapd reclaim write anon sync I/O: $total_kswapd_writepage_anon_sync\n";
|
print "Kswapd reclaim write anon sync I/O: $total_kswapd_writepage_anon_sync\n";
|
||||||
print "Kswapd reclaim write file async I/O: $total_kswapd_writepage_file_async\n";
|
print "Kswapd reclaim write file async I/O: $total_kswapd_writepage_file_async\n";
|
||||||
|
@ -612,6 +630,7 @@ sub aggregate_perprocesspid() {
|
||||||
$perprocess{$process}->{MM_VMSCAN_WAKEUP_KSWAPD} += $perprocesspid{$process_pid}->{MM_VMSCAN_WAKEUP_KSWAPD};
|
$perprocess{$process}->{MM_VMSCAN_WAKEUP_KSWAPD} += $perprocesspid{$process_pid}->{MM_VMSCAN_WAKEUP_KSWAPD};
|
||||||
$perprocess{$process}->{HIGH_KSWAPD_REWAKEUP} += $perprocesspid{$process_pid}->{HIGH_KSWAPD_REWAKEUP};
|
$perprocess{$process}->{HIGH_KSWAPD_REWAKEUP} += $perprocesspid{$process_pid}->{HIGH_KSWAPD_REWAKEUP};
|
||||||
$perprocess{$process}->{HIGH_NR_SCANNED} += $perprocesspid{$process_pid}->{HIGH_NR_SCANNED};
|
$perprocess{$process}->{HIGH_NR_SCANNED} += $perprocesspid{$process_pid}->{HIGH_NR_SCANNED};
|
||||||
|
$perprocess{$process}->{HIGH_NR_RECLAIMED} += $perprocesspid{$process_pid}->{HIGH_NR_RECLAIMED};
|
||||||
$perprocess{$process}->{MM_VMSCAN_WRITEPAGE_FILE_SYNC} += $perprocesspid{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_SYNC};
|
$perprocess{$process}->{MM_VMSCAN_WRITEPAGE_FILE_SYNC} += $perprocesspid{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_SYNC};
|
||||||
$perprocess{$process}->{MM_VMSCAN_WRITEPAGE_ANON_SYNC} += $perprocesspid{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_SYNC};
|
$perprocess{$process}->{MM_VMSCAN_WRITEPAGE_ANON_SYNC} += $perprocesspid{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_SYNC};
|
||||||
$perprocess{$process}->{MM_VMSCAN_WRITEPAGE_FILE_ASYNC} += $perprocesspid{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_ASYNC};
|
$perprocess{$process}->{MM_VMSCAN_WRITEPAGE_FILE_ASYNC} += $perprocesspid{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_ASYNC};
|
||||||
|
|
|
@ -83,3 +83,4 @@
|
||||||
82 -> WinFast DTV2000 H rev. J [107d:6f2b]
|
82 -> WinFast DTV2000 H rev. J [107d:6f2b]
|
||||||
83 -> Prof 7301 DVB-S/S2 [b034:3034]
|
83 -> Prof 7301 DVB-S/S2 [b034:3034]
|
||||||
84 -> Samsung SMT 7020 DVB-S [18ac:dc00,18ac:dccd]
|
84 -> Samsung SMT 7020 DVB-S [18ac:dc00,18ac:dccd]
|
||||||
|
85 -> Twinhan VP-1027 DVB-S [1822:0023]
|
||||||
|
|
|
@ -31,6 +31,7 @@
|
||||||
30 -> Videology 20K14XUSB USB2.0 (em2820/em2840)
|
30 -> Videology 20K14XUSB USB2.0 (em2820/em2840)
|
||||||
31 -> Usbgear VD204v9 (em2821)
|
31 -> Usbgear VD204v9 (em2821)
|
||||||
32 -> Supercomp USB 2.0 TV (em2821)
|
32 -> Supercomp USB 2.0 TV (em2821)
|
||||||
|
33 -> Elgato Video Capture (em2860) [0fd9:0033]
|
||||||
34 -> Terratec Cinergy A Hybrid XS (em2860) [0ccd:004f]
|
34 -> Terratec Cinergy A Hybrid XS (em2860) [0ccd:004f]
|
||||||
35 -> Typhoon DVD Maker (em2860)
|
35 -> Typhoon DVD Maker (em2860)
|
||||||
36 -> NetGMBH Cam (em2860)
|
36 -> NetGMBH Cam (em2860)
|
||||||
|
@ -45,7 +46,7 @@
|
||||||
45 -> Pinnacle PCTV DVB-T (em2870)
|
45 -> Pinnacle PCTV DVB-T (em2870)
|
||||||
46 -> Compro, VideoMate U3 (em2870) [185b:2870]
|
46 -> Compro, VideoMate U3 (em2870) [185b:2870]
|
||||||
47 -> KWorld DVB-T 305U (em2880) [eb1a:e305]
|
47 -> KWorld DVB-T 305U (em2880) [eb1a:e305]
|
||||||
48 -> KWorld DVB-T 310U (em2880) [eb1a:e310]
|
48 -> KWorld DVB-T 310U (em2880)
|
||||||
49 -> MSI DigiVox A/D (em2880) [eb1a:e310]
|
49 -> MSI DigiVox A/D (em2880) [eb1a:e310]
|
||||||
50 -> MSI DigiVox A/D II (em2880) [eb1a:e320]
|
50 -> MSI DigiVox A/D II (em2880) [eb1a:e320]
|
||||||
51 -> Terratec Hybrid XS Secam (em2880) [0ccd:004c]
|
51 -> Terratec Hybrid XS Secam (em2880) [0ccd:004c]
|
||||||
|
|
|
@ -126,7 +126,7 @@
|
||||||
125 -> Beholder BeholdTV 409 [0000:4090]
|
125 -> Beholder BeholdTV 409 [0000:4090]
|
||||||
126 -> Beholder BeholdTV 505 FM [5ace:5050]
|
126 -> Beholder BeholdTV 505 FM [5ace:5050]
|
||||||
127 -> Beholder BeholdTV 507 FM / BeholdTV 509 FM [5ace:5070,5ace:5090]
|
127 -> Beholder BeholdTV 507 FM / BeholdTV 509 FM [5ace:5070,5ace:5090]
|
||||||
128 -> Beholder BeholdTV Columbus TVFM [0000:5201]
|
128 -> Beholder BeholdTV Columbus TV/FM [0000:5201]
|
||||||
129 -> Beholder BeholdTV 607 FM [5ace:6070]
|
129 -> Beholder BeholdTV 607 FM [5ace:6070]
|
||||||
130 -> Beholder BeholdTV M6 [5ace:6190]
|
130 -> Beholder BeholdTV M6 [5ace:6190]
|
||||||
131 -> Twinhan Hybrid DTV-DVB 3056 PCI [1822:0022]
|
131 -> Twinhan Hybrid DTV-DVB 3056 PCI [1822:0022]
|
||||||
|
|
|
@ -19,7 +19,6 @@ function makedev () {
|
||||||
echo "*** new device names ***"
|
echo "*** new device names ***"
|
||||||
makedev video 0
|
makedev video 0
|
||||||
makedev radio 64
|
makedev radio 64
|
||||||
makedev vtx 192
|
|
||||||
makedev vbi 224
|
makedev vbi 224
|
||||||
|
|
||||||
#echo "*** old device names (for compatibility only) ***"
|
#echo "*** old device names (for compatibility only) ***"
|
||||||
|
|
|
@ -302,12 +302,14 @@ sonixj 0c45:60fb Surfer NoName
|
||||||
sonixj 0c45:60fc LG-LIC300
|
sonixj 0c45:60fc LG-LIC300
|
||||||
sonixj 0c45:60fe Microdia Audio
|
sonixj 0c45:60fe Microdia Audio
|
||||||
sonixj 0c45:6100 PC Camera (SN9C128)
|
sonixj 0c45:6100 PC Camera (SN9C128)
|
||||||
|
sonixj 0c45:6102 PC Camera (SN9C128)
|
||||||
sonixj 0c45:610a PC Camera (SN9C128)
|
sonixj 0c45:610a PC Camera (SN9C128)
|
||||||
sonixj 0c45:610b PC Camera (SN9C128)
|
sonixj 0c45:610b PC Camera (SN9C128)
|
||||||
sonixj 0c45:610c PC Camera (SN9C128)
|
sonixj 0c45:610c PC Camera (SN9C128)
|
||||||
sonixj 0c45:610e PC Camera (SN9C128)
|
sonixj 0c45:610e PC Camera (SN9C128)
|
||||||
sonixj 0c45:6128 Microdia/Sonix SNP325
|
sonixj 0c45:6128 Microdia/Sonix SNP325
|
||||||
sonixj 0c45:612a Avant Camera
|
sonixj 0c45:612a Avant Camera
|
||||||
|
sonixj 0c45:612b Speed-Link REFLECT2
|
||||||
sonixj 0c45:612c Typhoon Rasy Cam 1.3MPix
|
sonixj 0c45:612c Typhoon Rasy Cam 1.3MPix
|
||||||
sonixj 0c45:6130 Sonix Pccam
|
sonixj 0c45:6130 Sonix Pccam
|
||||||
sonixj 0c45:6138 Sn9c120 Mo4000
|
sonixj 0c45:6138 Sn9c120 Mo4000
|
||||||
|
|
|
@ -44,8 +44,8 @@ All drivers have the following structure:
|
||||||
|
|
||||||
2) A way of initializing and commanding sub-devices (if any).
|
2) A way of initializing and commanding sub-devices (if any).
|
||||||
|
|
||||||
3) Creating V4L2 device nodes (/dev/videoX, /dev/vbiX, /dev/radioX and
|
3) Creating V4L2 device nodes (/dev/videoX, /dev/vbiX and /dev/radioX)
|
||||||
/dev/vtxX) and keeping track of device-node specific data.
|
and keeping track of device-node specific data.
|
||||||
|
|
||||||
4) Filehandle-specific structs containing per-filehandle data;
|
4) Filehandle-specific structs containing per-filehandle data;
|
||||||
|
|
||||||
|
@ -192,6 +192,11 @@ You also need a way to go from the low-level struct to v4l2_subdev. For the
|
||||||
common i2c_client struct the i2c_set_clientdata() call is used to store a
|
common i2c_client struct the i2c_set_clientdata() call is used to store a
|
||||||
v4l2_subdev pointer, for other busses you may have to use other methods.
|
v4l2_subdev pointer, for other busses you may have to use other methods.
|
||||||
|
|
||||||
|
Bridges might also need to store per-subdev private data, such as a pointer to
|
||||||
|
bridge-specific per-subdev private data. The v4l2_subdev structure provides
|
||||||
|
host private data for that purpose that can be accessed with
|
||||||
|
v4l2_get_subdev_hostdata() and v4l2_set_subdev_hostdata().
|
||||||
|
|
||||||
From the bridge driver perspective you load the sub-device module and somehow
|
From the bridge driver perspective you load the sub-device module and somehow
|
||||||
obtain the v4l2_subdev pointer. For i2c devices this is easy: you call
|
obtain the v4l2_subdev pointer. For i2c devices this is easy: you call
|
||||||
i2c_get_clientdata(). For other busses something similar needs to be done.
|
i2c_get_clientdata(). For other busses something similar needs to be done.
|
||||||
|
@ -448,6 +453,10 @@ You should also set these fields:
|
||||||
- ioctl_ops: if you use the v4l2_ioctl_ops to simplify ioctl maintenance
|
- 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
|
(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.
|
||||||
|
- 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 any
|
||||||
|
of the v4l2_file_operations is called this lock will be taken by the
|
||||||
|
core and released afterwards.
|
||||||
- parent: you only set this if v4l2_device was registered with NULL as
|
- parent: you only set this if v4l2_device was registered with NULL as
|
||||||
the parent device struct. This only happens in cases where one hardware
|
the parent device struct. This only happens in cases where one hardware
|
||||||
device has multiple PCI devices that all share the same v4l2_device core.
|
device has multiple PCI devices that all share the same v4l2_device core.
|
||||||
|
@ -464,6 +473,22 @@ If you use v4l2_ioctl_ops, then you should set either .unlocked_ioctl or
|
||||||
The v4l2_file_operations struct is a subset of file_operations. The main
|
The v4l2_file_operations struct is a subset of file_operations. The main
|
||||||
difference is that the inode argument is omitted since it is never used.
|
difference is that the inode argument is omitted since it is never used.
|
||||||
|
|
||||||
|
v4l2_file_operations and locking
|
||||||
|
--------------------------------
|
||||||
|
|
||||||
|
You can set a pointer to a mutex_lock in struct video_device. Usually this
|
||||||
|
will be either a top-level mutex or a mutex per device node. If you want
|
||||||
|
finer-grained locking then you have to set it to NULL and do you own locking.
|
||||||
|
|
||||||
|
If a lock is specified then all file operations will be serialized on that
|
||||||
|
lock. If you use videobuf then you must pass the same lock to the videobuf
|
||||||
|
queue initialize function: if videobuf has to wait for a frame to arrive, then
|
||||||
|
it will temporarily unlock the lock and relock it afterwards. If your driver
|
||||||
|
also waits in the code, then you should do the same to allow other processes
|
||||||
|
to access the device node while the first process is waiting for something.
|
||||||
|
|
||||||
|
The implementation of a hotplug disconnect should also take the lock before
|
||||||
|
calling v4l2_device_disconnect.
|
||||||
|
|
||||||
video_device registration
|
video_device registration
|
||||||
-------------------------
|
-------------------------
|
||||||
|
@ -483,7 +508,6 @@ types exist:
|
||||||
VFL_TYPE_GRABBER: videoX for video input/output devices
|
VFL_TYPE_GRABBER: videoX for video input/output devices
|
||||||
VFL_TYPE_VBI: vbiX for vertical blank data (i.e. closed captions, teletext)
|
VFL_TYPE_VBI: vbiX for vertical blank data (i.e. closed captions, teletext)
|
||||||
VFL_TYPE_RADIO: radioX for radio tuners
|
VFL_TYPE_RADIO: radioX for radio tuners
|
||||||
VFL_TYPE_VTX: vtxX for teletext devices (deprecated, don't use)
|
|
||||||
|
|
||||||
The last argument gives you a certain amount of control over the device
|
The last argument gives you a certain amount of control over the device
|
||||||
device node number used (i.e. the X in videoX). Normally you will pass -1
|
device node number used (i.e. the X in videoX). Normally you will pass -1
|
||||||
|
@ -547,9 +571,8 @@ from /dev).
|
||||||
|
|
||||||
After video_unregister_device() returns no new opens can be done. However,
|
After video_unregister_device() returns no new opens can be done. However,
|
||||||
in the case of USB devices some application might still have one of these
|
in the case of USB devices some application might still have one of these
|
||||||
device nodes open. So after the unregister all file operations will return
|
device nodes open. So after the unregister all file operations (except
|
||||||
an error as well, except for the ioctl and unlocked_ioctl file operations:
|
release, of course) will return an error as well.
|
||||||
those will still be passed on since some buffer ioctls may still be needed.
|
|
||||||
|
|
||||||
When the last user of the video device node exits, then the vdev->release()
|
When the last user of the video device node exits, then the vdev->release()
|
||||||
callback is called and you can do the final cleanup there.
|
callback is called and you can do the final cleanup there.
|
||||||
|
|
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue