Merge branch 'drm-intel-fixes' into drm-intel-next
Conflicts: drivers/gpu/drm/i915/i915_gem.c drivers/gpu/drm/i915/intel_ringbuffer.c
This commit is contained in:
Коммит
c94f28c383
|
@ -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.
|
|
@ -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
|
|
@ -710,7 +710,18 @@ Task Addr Pid Parent [*] cpu State Thread Command
|
|||
<listitem><para>A simple shell</para></listitem>
|
||||
<listitem><para>The kdb core command set</para></listitem>
|
||||
<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
|
||||
emits messages directly to I/O drivers, bypassing the kernel
|
||||
log.</para></listitem>
|
||||
|
|
|
@ -250,6 +250,9 @@
|
|||
<!ENTITY sub-yuv422p SYSTEM "v4l/pixfmt-yuv422p.xml">
|
||||
<!ENTITY sub-yuyv SYSTEM "v4l/pixfmt-yuyv.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-cropcap SYSTEM "v4l/vidioc-cropcap.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 yuyv SYSTEM "v4l/pixfmt-yuyv.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 dbg-g-register SYSTEM "v4l/vidioc-dbg-g-register.xml">
|
||||
<!ENTITY encoder-cmd SYSTEM "v4l/vidioc-encoder-cmd.xml">
|
||||
|
|
|
@ -21,11 +21,15 @@ API.</para>
|
|||
<title>Opening and Closing Devices</title>
|
||||
|
||||
<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
|
||||
listed in <xref linkend="devices" /> and below in <xref
|
||||
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
|
||||
assigns minor numbers to drivers in load order, depending on the
|
||||
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>
|
||||
<entry>64-127</entry>
|
||||
</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>
|
||||
<entry>Raw VBI capture</entry>
|
||||
<entry><para><filename>/dev/vbi</filename>,
|
||||
|
@ -2345,6 +2342,17 @@ more information.</para>
|
|||
</listitem>
|
||||
</orderedlist>
|
||||
</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">
|
||||
<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
|
||||
information and bits 24-31 must be zero.</entry>
|
||||
</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>
|
||||
<entry><constant>V4L2_CID_LASTP1</constant></entry>
|
||||
<entry></entry>
|
||||
<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>
|
||||
<entry><constant>V4L2_CID_PRIVATE_BASE</constant></entry>
|
||||
|
@ -357,9 +364,6 @@ enumerate_menu (void)
|
|||
querymenu.index++) {
|
||||
if (0 == ioctl (fd, &VIDIOC-QUERYMENU;, &querymenu)) {
|
||||
printf (" %s\n", querymenu.name);
|
||||
} else {
|
||||
perror ("VIDIOC_QUERYMENU");
|
||||
exit (EXIT_FAILURE);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
|
@ -3,15 +3,16 @@
|
|||
<para>The Radio Data System transmits supplementary
|
||||
information in binary format, for example the station name or travel
|
||||
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>
|
||||
|
||||
<para>For more information see the core RDS standard <xref linkend="en50067" />
|
||||
and the RBDS standard <xref linkend="nrsc4" />.</para>
|
||||
|
||||
<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
|
||||
have slightly different meanings. See the RBDS standard for more information.</para>
|
||||
to the RDS standard. Any RDS decoder/encoder can also handle RBDS. Only some of the
|
||||
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).
|
||||
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>
|
||||
<title>Querying Capabilities</title>
|
||||
|
||||
<para>Devices supporting the RDS capturing API
|
||||
set the <constant>V4L2_CAP_RDS_CAPTURE</constant> flag in
|
||||
<para>Devices supporting the RDS capturing API set
|
||||
the <constant>V4L2_CAP_RDS_CAPTURE</constant> flag in
|
||||
the <structfield>capabilities</structfield> field of &v4l2-capability;
|
||||
returned by the &VIDIOC-QUERYCAP; ioctl.
|
||||
Any tuner that supports RDS will set the
|
||||
<constant>V4L2_TUNER_CAP_RDS</constant> flag in the <structfield>capability</structfield>
|
||||
field of &v4l2-tuner;.
|
||||
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>
|
||||
returned by the &VIDIOC-QUERYCAP; ioctl. Any tuner that supports RDS
|
||||
will set the <constant>V4L2_TUNER_CAP_RDS</constant> flag in
|
||||
the <structfield>capability</structfield> field of &v4l2-tuner;. 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, see <link linkend="reading-rds-data">Reading RDS data</link>.
|
||||
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
|
||||
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>
|
||||
field of &v4l2-modulator;.
|
||||
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 id="reading-rds-data">
|
||||
<title>Reading RDS data</title>
|
||||
|
||||
<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>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<table frame="none" pgwide="1" id="v4l2-rds-data">
|
||||
<title>struct
|
||||
<structname>v4l2_rds_data</structname></title>
|
||||
|
@ -111,48 +136,57 @@ as follows:</para>
|
|||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>V4L2_RDS_BLOCK_MSK</entry>
|
||||
<entry> </entry>
|
||||
<entry>7</entry>
|
||||
<entry>Mask for bits 0-2 to get the block ID.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>V4L2_RDS_BLOCK_A</entry>
|
||||
<entry> </entry>
|
||||
<entry>0</entry>
|
||||
<entry>Block A.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>V4L2_RDS_BLOCK_B</entry>
|
||||
<entry> </entry>
|
||||
<entry>1</entry>
|
||||
<entry>Block B.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>V4L2_RDS_BLOCK_C</entry>
|
||||
<entry> </entry>
|
||||
<entry>2</entry>
|
||||
<entry>Block C.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>V4L2_RDS_BLOCK_D</entry>
|
||||
<entry> </entry>
|
||||
<entry>3</entry>
|
||||
<entry>Block D.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>V4L2_RDS_BLOCK_C_ALT</entry>
|
||||
<entry> </entry>
|
||||
<entry>4</entry>
|
||||
<entry>Block C'.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>V4L2_RDS_BLOCK_INVALID</entry>
|
||||
<entry>read-only</entry>
|
||||
<entry>7</entry>
|
||||
<entry>An invalid block.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>V4L2_RDS_BLOCK_CORRECTED</entry>
|
||||
<entry>read-only</entry>
|
||||
<entry>0x40</entry>
|
||||
<entry>A bit error was detected but corrected.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>V4L2_RDS_BLOCK_ERROR</entry>
|
||||
<entry>read-only</entry>
|
||||
<entry>0x80</entry>
|
||||
<entry>An incorrectable error occurred.</entry>
|
||||
<entry>An uncorrectable error occurred.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
|
|
|
@ -1,35 +1,32 @@
|
|||
<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 packages and storing formatted pages in cache memory. Such
|
||||
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
|
||||
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
|
||||
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
|
||||
the German public television Teletext service.) Conventional character
|
||||
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>
|
||||
the German public television Teletext service.)</para>
|
||||
|
||||
<para>Eventually the Teletext API was integrated into the V4L API
|
||||
with character device file names <filename>/dev/vtx0</filename> to
|
||||
<filename>/dev/vtx31</filename>, device major number 81, minor numbers
|
||||
192 to 223. For reference the V4L Teletext API specification is
|
||||
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>
|
||||
192 to 223.</para>
|
||||
|
||||
<para>There are no plans to replace the Teletext API or to integrate
|
||||
it into V4L2. Please write to the linux-media mailing list: &v4l-ml;
|
||||
when the need arises.</para>
|
||||
<para>However, teletext decoders were quickly replaced by more
|
||||
generic VBI demodulators and those dedicated teletext decoders no longer exist.
|
||||
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:
|
||||
|
|
|
@ -739,7 +739,7 @@ defined in error. Drivers may interpret them as in <xref
|
|||
<entry>b<subscript>1</subscript></entry>
|
||||
<entry>b<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="V4L2-PIX-FMT-BGR666">
|
||||
<row><!-- id="V4L2-PIX-FMT-BGR666" -->
|
||||
<entry><constant>V4L2_PIX_FMT_BGR666</constant></entry>
|
||||
<entry>'BGRH'</entry>
|
||||
<entry></entry>
|
||||
|
|
|
@ -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>
|
|
@ -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>
|
|
@ -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-sgbrg8;
|
||||
&sub-sgrbg8;
|
||||
&sub-srggb8;
|
||||
&sub-sbggr16;
|
||||
&sub-srggb10;
|
||||
</section>
|
||||
|
||||
<section id="yuv-formats">
|
||||
|
@ -589,6 +591,7 @@ information.</para>
|
|||
|
||||
&sub-packed-yuv;
|
||||
&sub-grey;
|
||||
&sub-y10;
|
||||
&sub-y16;
|
||||
&sub-yuyv;
|
||||
&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>
|
||||
</para></entry>
|
||||
</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">
|
||||
<entry><constant>V4L2_PIX_FMT_SPCA501</constant></entry>
|
||||
<entry>'S501'</entry>
|
||||
|
@ -705,11 +713,6 @@ kernel sources in the file <filename>Documentation/video4linux/cx2341x/README.hm
|
|||
<entry>'S561'</entry>
|
||||
<entry>Compressed GBRG Bayer format used by the gspca driver.</entry>
|
||||
</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">
|
||||
<entry><constant>V4L2_PIX_FMT_SGRBG10DPCM8</constant></entry>
|
||||
<entry>'DB10'</entry>
|
||||
|
@ -770,6 +773,11 @@ kernel sources in the file <filename>Documentation/video4linux/cx2341x/README.hm
|
|||
<entry>'S920'</entry>
|
||||
<entry>YUV 4:2:0 format of the gspca sn9c20x driver.</entry>
|
||||
</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">
|
||||
<entry><constant>V4L2_PIX_FMT_STV0680</constant></entry>
|
||||
<entry>'S680'</entry>
|
||||
|
@ -787,6 +795,20 @@ http://www.thedirks.org/winnov/</ulink></para></entry>
|
|||
<entry>'TM60'</entry>
|
||||
<entry><para>Used by Trident tm6000</para></entry>
|
||||
</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">
|
||||
<entry><constant>V4L2_PIX_FMT_YYUV</constant></entry>
|
||||
<entry>'YYUV'</entry>
|
||||
|
|
|
@ -99,6 +99,7 @@ Remote Controller chapter.</contrib>
|
|||
<year>2007</year>
|
||||
<year>2008</year>
|
||||
<year>2009</year>
|
||||
<year>2010</year>
|
||||
<holder>Bill Dirks, Michael H. Schimek, Hans Verkuil, Martin
|
||||
Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab</holder>
|
||||
</copyright>
|
||||
|
@ -110,9 +111,16 @@ Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab</holder>
|
|||
<!-- Put document revisions here, newest first. -->
|
||||
<!-- API revisions (changes and additions of defines, enums,
|
||||
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. -->
|
||||
|
||||
<revision>
|
||||
<revnumber>2.6.37</revnumber>
|
||||
<date>2010-08-06</date>
|
||||
<authorinitials>hv</authorinitials>
|
||||
<revremark>Removed obsolete vtx (videotext) API.</revremark>
|
||||
</revision>
|
||||
|
||||
<revision>
|
||||
<revnumber>2.6.33</revnumber>
|
||||
<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_SLICED_VBI_CAPTURE = 6,
|
||||
V4L2_BUF_TYPE_SLICED_VBI_OUTPUT = 7,
|
||||
#if 1 /*KEEP*/
|
||||
#if 1
|
||||
/* Experimental */
|
||||
V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY = 8,
|
||||
#endif
|
||||
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> {
|
||||
V4L2_TUNER_RADIO = 1,
|
||||
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-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-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-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 */
|
||||
|
@ -295,6 +286,9 @@ struct <link linkend="v4l2-pix-format">v4l2_pix_format</link> {
|
|||
|
||||
/* 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-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 */
|
||||
|
||||
/* 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-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-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 */
|
||||
#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 */
|
||||
|
||||
/* 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-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 */
|
||||
|
@ -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-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-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-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-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-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
|
||||
|
@ -380,7 +382,7 @@ struct <link linkend="v4l2-fmtdesc">v4l2_fmtdesc</link> {
|
|||
#define V4L2_FMT_FLAG_COMPRESSED 0x0001
|
||||
#define V4L2_FMT_FLAG_EMULATED 0x0002
|
||||
|
||||
#if 1 /*KEEP*/
|
||||
#if 1
|
||||
/* 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
|
||||
|
@ -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_PFRAME 0x0010 /* Image is a P-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_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_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 */
|
||||
struct <link linkend="v4l2-queryctrl">v4l2_queryctrl</link> {
|
||||
__u32 id;
|
||||
|
@ -1018,21 +1032,27 @@ enum <link linkend="v4l2-colorfx">v4l2_colorfx</link> {
|
|||
V4L2_COLORFX_NONE = 0,
|
||||
V4L2_COLORFX_BW = 1,
|
||||
V4L2_COLORFX_SEPIA = 2,
|
||||
V4L2_COLORFX_NEGATIVE = 3,
|
||||
V4L2_COLORFX_EMBOSS = 4,
|
||||
V4L2_COLORFX_SKETCH = 5,
|
||||
V4L2_COLORFX_SKY_BLUE = 6,
|
||||
V4L2_COLORFX_NEGATIVE = 3,
|
||||
V4L2_COLORFX_EMBOSS = 4,
|
||||
V4L2_COLORFX_SKETCH = 5,
|
||||
V4L2_COLORFX_SKY_BLUE = 6,
|
||||
V4L2_COLORFX_GRASS_GREEN = 7,
|
||||
V4L2_COLORFX_SKIN_WHITEN = 8,
|
||||
V4L2_COLORFX_VIVID = 9.
|
||||
V4L2_COLORFX_VIVID = 9,
|
||||
};
|
||||
#define V4L2_CID_AUTOBRIGHTNESS (V4L2_CID_BASE+32)
|
||||
#define V4L2_CID_BAND_STOP_FILTER (V4L2_CID_BASE+33)
|
||||
|
||||
#define V4L2_CID_ROTATE (V4L2_CID_BASE+34)
|
||||
#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 */
|
||||
#define V4L2_CID_LASTP1 (V4L2_CID_BASE+36)
|
||||
#define V4L2_CID_LASTP1 (V4L2_CID_BASE+39)
|
||||
|
||||
/* MPEG-class control IDs defined by V4L2 */
|
||||
#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_LANG1 0x0040
|
||||
#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 */
|
||||
#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;
|
||||
__u32 seek_upward;
|
||||
__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
|
||||
*/
|
||||
#if 1 /*KEEP*/
|
||||
#if 1
|
||||
#define V4L2_ENC_IDX_FRAME_I (0)
|
||||
#define V4L2_ENC_IDX_FRAME_P (1)
|
||||
#define V4L2_ENC_IDX_FRAME_B (2)
|
||||
|
@ -1625,6 +1648,38 @@ struct <link linkend="v4l2-streamparm">v4l2_streamparm</link> {
|
|||
} 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
|
||||
*
|
||||
|
@ -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_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>)
|
||||
#if 1 /*KEEP*/
|
||||
#if 1
|
||||
#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_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>)
|
||||
#endif
|
||||
|
||||
#if 1 /*KEEP*/
|
||||
#if 1
|
||||
/* Experimental, meant for debugging, testing and internal use.
|
||||
Only implemented if CONFIG_VIDEO_ADV_DEBUG is defined.
|
||||
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_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_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
|
||||
drivers/media/video/v4l2-compat-ioctl32.c as well! */
|
||||
|
|
|
@ -16,8 +16,7 @@
|
|||
<funcdef>int <function>ioctl</function></funcdef>
|
||||
<paramdef>int <parameter>fd</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>
|
||||
</funcsynopsis>
|
||||
</refsynopsisdiv>
|
||||
|
|
|
@ -16,8 +16,7 @@
|
|||
<funcdef>int <function>ioctl</function></funcdef>
|
||||
<paramdef>int <parameter>fd</parameter></paramdef>
|
||||
<paramdef>int <parameter>request</parameter></paramdef>
|
||||
<paramdef>&v4l2-dv-timings;
|
||||
*<parameter>argp</parameter></paramdef>
|
||||
<paramdef>struct v4l2_dv_timings *<parameter>argp</parameter></paramdef>
|
||||
</funcprototype>
|
||||
</funcsynopsis>
|
||||
</refsynopsisdiv>
|
||||
|
|
|
@ -16,7 +16,7 @@ input</refpurpose>
|
|||
<funcdef>int <function>ioctl</function></funcdef>
|
||||
<paramdef>int <parameter>fd</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>
|
||||
</funcsynopsis>
|
||||
</refsynopsisdiv>
|
||||
|
|
|
@ -184,7 +184,7 @@ data.</entry>
|
|||
<row>
|
||||
<entry><constant>V4L2_CAP_RDS_CAPTURE</constant></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>
|
||||
<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
|
||||
hardware frequency seeking.</entry>
|
||||
</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>
|
||||
<entry><constant>V4L2_CAP_TUNER</constant></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
|
||||
by calling <constant>VIDIOC_QUERYMENU</constant> with successive
|
||||
<structfield>index</structfield> values from &v4l2-queryctrl;
|
||||
<structfield>minimum</structfield> (0) to
|
||||
<structfield>maximum</structfield>, inclusive.</para>
|
||||
<structfield>minimum</structfield> to
|
||||
<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>
|
||||
|
||||
|
@ -139,7 +143,7 @@ string. This information is intended for the user.</entry>
|
|||
<entry><structfield>minimum</structfield></entry>
|
||||
<entry>Minimum value, inclusive. This field gives a lower
|
||||
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
|
||||
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
|
||||
|
@ -279,7 +283,7 @@ values which are actually different on the hardware.</entry>
|
|||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CTRL_TYPE_MENU</constant></entry>
|
||||
<entry>0</entry>
|
||||
<entry>≥ 0</entry>
|
||||
<entry>1</entry>
|
||||
<entry>N-1</entry>
|
||||
<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>
|
||||
<listitem>
|
||||
<para>The &v4l2-queryctrl; <structfield>id</structfield>
|
||||
is invalid. The &v4l2-querymenu; <structfield>id</structfield> or
|
||||
<structfield>index</structfield> is invalid.</para>
|
||||
is invalid. The &v4l2-querymenu; <structfield>id</structfield> is
|
||||
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>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
|
|
|
@ -51,7 +51,8 @@
|
|||
|
||||
<para>Start a hardware frequency seek from the current frequency.
|
||||
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>reserved</structfield> array of a &v4l2-hw-freq-seek; and
|
||||
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>
|
||||
<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
|
||||
applications must set the array to zero.</entry>
|
||||
</row>
|
||||
|
|
|
@ -21,6 +21,7 @@
|
|||
#include <sys/types.h>
|
||||
#include <sys/stat.h>
|
||||
#include <sys/socket.h>
|
||||
#include <sys/wait.h>
|
||||
#include <signal.h>
|
||||
|
||||
#include <linux/genetlink.h>
|
||||
|
@ -266,11 +267,13 @@ int main(int argc, char *argv[])
|
|||
int containerset = 0;
|
||||
char containerpath[1024];
|
||||
int cfd = 0;
|
||||
int forking = 0;
|
||||
sigset_t sigset;
|
||||
|
||||
struct msgtemplate msg;
|
||||
|
||||
while (1) {
|
||||
c = getopt(argc, argv, "qdiw:r:m:t:p:vlC:");
|
||||
while (!forking) {
|
||||
c = getopt(argc, argv, "qdiw:r:m:t:p:vlC:c:");
|
||||
if (c < 0)
|
||||
break;
|
||||
|
||||
|
@ -319,6 +322,28 @@ int main(int argc, char *argv[])
|
|||
err(1, "Invalid pid\n");
|
||||
cmd_type = TASKSTATS_CMD_ATTR_PID;
|
||||
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':
|
||||
printf("debug on\n");
|
||||
dbg = 1;
|
||||
|
@ -370,6 +395,15 @@ int main(int argc, char *argv[])
|
|||
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) {
|
||||
rc = send_cmd(nl_sd, id, mypid, TASKSTATS_CMD_GET,
|
||||
cmd_type, &tid, sizeof(__u32));
|
||||
|
|
|
@ -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
|
||||
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
|
||||
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).
|
||||
|
||||
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:
|
||||
|
||||
# cat /sys/block/hda/queue/scheduler
|
||||
noop anticipatory deadline [cfq]
|
||||
# echo anticipatory > /sys/block/hda/queue/scheduler
|
||||
noop deadline [cfq]
|
||||
# echo deadline > /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.3 How are cgroups implemented ?
|
||||
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.1 Basic Usage
|
||||
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
|
||||
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
|
||||
|
|
|
@ -24,6 +24,9 @@ of many distributions, e.g. :
|
|||
You can get the latest version released from the Coccinelle homepage at
|
||||
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:
|
||||
|
||||
./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'
|
||||
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>'.
|
||||
|
||||
'patch' proposes a fix, when possible.
|
||||
|
||||
'report' generates a list in the following format:
|
||||
file:line:column-column: message
|
||||
|
||||
'patch' proposes a fix, when possible.
|
||||
|
||||
'context' highlights lines of interest and their context in a
|
||||
diff-like style.Lines of interest are indicated with '-'.
|
||||
|
||||
'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:
|
||||
|
||||
|
@ -68,9 +73,9 @@ To produce patches, run:
|
|||
|
||||
|
||||
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
|
||||
includes a reference to Coccinelle.
|
||||
|
||||
|
@ -93,12 +98,35 @@ or
|
|||
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
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
New semantic patches can be proposed and submitted by kernel
|
||||
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
|
||||
|
@ -111,7 +139,7 @@ Example:
|
|||
|
||||
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.
|
||||
|
||||
|
@ -149,7 +177,7 @@ identified.
|
|||
Example:
|
||||
|
||||
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.
|
||||
|
||||
|
@ -193,7 +221,7 @@ NOTE: The diff-like output generated is NOT an applicable patch. The
|
|||
Example:
|
||||
|
||||
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.
|
||||
|
||||
|
@ -228,7 +256,7 @@ diff -u -p /home/user/linux/crypto/ctr.c /tmp/nothing
|
|||
Example:
|
||||
|
||||
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.
|
||||
|
||||
|
|
|
@ -1496,9 +1496,6 @@ Your cooperation is appreciated.
|
|||
64 = /dev/radio0 Radio device
|
||||
...
|
||||
127 = /dev/radio63 Radio device
|
||||
192 = /dev/vtx0 Teletext device
|
||||
...
|
||||
223 = /dev/vtx31 Teletext device
|
||||
224 = /dev/vbi0 Vertical blank interrupt
|
||||
...
|
||||
255 = /dev/vbi31 Vertical blank interrupt
|
||||
|
@ -2520,6 +2517,12 @@ Your cooperation is appreciated.
|
|||
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
|
||||
0 = /dev/dvxirq0 First DVX device
|
||||
1 = /dev/dvxirq1 Second DVX device
|
||||
|
|
|
@ -26,7 +26,8 @@ use IO::Handle;
|
|||
"dec3000s", "vp7041", "dibusb", "nxt2002", "nxt2004",
|
||||
"or51211", "or51132_qam", "or51132_vsb", "bluebird",
|
||||
"opera1", "cx231xx", "cx18", "cx23885", "pvrusb2", "mpc718",
|
||||
"af9015", "ngene", "az6027");
|
||||
"af9015", "ngene", "az6027", "lme2510_lg", "lme2510c_s7395",
|
||||
"lme2510c_s7395_old");
|
||||
|
||||
# Check args
|
||||
syntax() if (scalar(@ARGV) != 1);
|
||||
|
@ -584,6 +585,49 @@ sub az6027{
|
|||
|
||||
$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
|
||||
|
||||
|
|
|
@ -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
|
|
@ -197,6 +197,54 @@ Notes:
|
|||
example,
|
||||
# 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]:
|
||||
--------------------
|
||||
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.
|
||||
When: July 2009
|
||||
When: kernel 2.6.38
|
||||
Files: 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
|
||||
|
@ -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
|
||||
When: September 2010
|
||||
Option: CONFIG_SYSCTL_SYSCALL
|
||||
|
@ -470,29 +485,6 @@ When: April 2011
|
|||
Why: Superseded by xt_CT
|
||||
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
|
||||
|
@ -526,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
|
||||
When: 2.6.40
|
||||
Why: Hareware scan is the prefer method for iwlwifi devices for
|
||||
|
|
|
@ -96,8 +96,6 @@ seq_file.txt
|
|||
- how to use the seq_file API
|
||||
sharedsubtree.txt
|
||||
- a description of shared subtrees for namespaces.
|
||||
smbfs.txt
|
||||
- info on using filesystems with the SMB protocol (Win 3.11 and NT).
|
||||
spufs.txt
|
||||
- info and mount options for the SPU filesystem used on Cell.
|
||||
sysfs-pci.txt
|
||||
|
|
|
@ -111,7 +111,7 @@ OPTIONS
|
|||
This can be used to share devices/named pipes/sockets between
|
||||
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
|
||||
filesystem for the first time, v9fs sends an
|
||||
attach command (Tattach) for that user.
|
||||
|
@ -120,6 +120,8 @@ OPTIONS
|
|||
the files on the mounted filesystem
|
||||
any = v9fs does single attach and performs all
|
||||
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.
|
||||
cache tags for existing cache sessions can be listed at
|
||||
|
|
|
@ -322,7 +322,6 @@ fl_release_private: yes yes
|
|||
prototypes:
|
||||
int (*fl_compare_owner)(struct file_lock *, struct file_lock *);
|
||||
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_break)(struct file_lock *); /* break_lease callback */
|
||||
|
||||
|
@ -330,7 +329,6 @@ locking rules:
|
|||
BKL may block
|
||||
fl_compare_owner: yes no
|
||||
fl_notify: yes no
|
||||
fl_copy_lock: yes no
|
||||
fl_release_private: yes yes
|
||||
fl_break: yes no
|
||||
|
||||
|
|
|
@ -353,6 +353,20 @@ noauto_da_alloc replacing existing files via patterns such as
|
|||
system crashes before the delayed allocation
|
||||
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
|
||||
nodiscard(*) commands to the underlying block device when
|
||||
blocks are freed. This is useful for SSD devices
|
||||
|
|
|
@ -136,6 +136,7 @@ Table 1-1: Process specific entries in /proc
|
|||
statm Process memory status information
|
||||
status Process status in human readable form
|
||||
wchan If CONFIG_KALLSYMS is set, a pre-decoded wchan
|
||||
pagemap Page table
|
||||
stack Report full stack trace, enable via CONFIG_STACKTRACE
|
||||
smaps a extension based on maps, showing the memory consumption of
|
||||
each mapping
|
||||
|
@ -370,6 +371,7 @@ Shared_Dirty: 0 kB
|
|||
Private_Clean: 0 kB
|
||||
Private_Dirty: 0 kB
|
||||
Referenced: 892 kB
|
||||
Anonymous: 0 kB
|
||||
Swap: 0 kB
|
||||
KernelPageSize: 4 kB
|
||||
MMUPageSize: 4 kB
|
||||
|
@ -378,9 +380,15 @@ 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
|
||||
(size), the amount of the mapping that is currently resident in RAM (RSS), the
|
||||
process' proportional share of this mapping (PSS), the number of clean and
|
||||
dirty shared pages in the mapping, and the number of clean and dirty private
|
||||
pages in the mapping. The "Referenced" indicates the amount of memory
|
||||
currently marked as referenced or accessed.
|
||||
dirty private pages in the mapping. Note that even a page which is part of a
|
||||
MAP_SHARED mapping, but has only a single pte mapped, i.e. is currently used
|
||||
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
|
||||
enabled.
|
||||
|
@ -397,6 +405,9 @@ To clear the bits for the file mapped pages associated with the process
|
|||
> echo 3 > /proc/PID/clear_refs
|
||||
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
|
||||
---------------
|
||||
|
|
|
@ -794,17 +794,6 @@ designed.
|
|||
|
||||
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
|
||||
=> should be roughly 12 months after initial merge
|
||||
=> enough time to shake out remaining problems before next round of
|
||||
|
|
|
@ -22,6 +22,10 @@ Supported chips:
|
|||
Prefix: 'it8720'
|
||||
Addresses scanned: from Super I/O config space (8 I/O ports)
|
||||
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]
|
||||
Prefix: 'it87'
|
||||
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,
|
||||
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,
|
||||
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
|
||||
can't have both on a given board.
|
||||
|
||||
The IT8716F, IT8718F, IT8720F and later IT8712F revisions have support for
|
||||
2 additional fans. The additional fans are supported by the driver.
|
||||
The IT8716F, IT8718F, IT8720F, IT8721F/IT8758E and later IT8712F revisions
|
||||
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
|
||||
optional 16-bit tachometer counters for fans 1 to 3. This is better (no more
|
||||
fan clock divider mess) but not compatible with the older chips and
|
||||
revisions. The 16-bit tachometer mode is enabled by the driver when one
|
||||
of the above chips is detected.
|
||||
The IT8716F, IT8718F, IT8720F and IT8721F/IT8758E, and late IT8712F and
|
||||
IT8705F also have optional 16-bit tachometer counters for fans 1 to 3. This
|
||||
is better (no more fan clock divider mess) but not compatible with the older
|
||||
chips and revisions. The 16-bit tachometer mode is enabled by the driver when
|
||||
one of the above chips is detected.
|
||||
|
||||
The IT8726F is just bit enhanced IT8716F with additional hardware
|
||||
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
|
||||
zero'; this is important for negative voltage measurements. All voltage
|
||||
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 voltage level your processor should work with. This is hardcoded by
|
||||
|
|
|
@ -14,6 +14,10 @@ Supported chips:
|
|||
Prefix: 'adt7463'
|
||||
Addresses scanned: I2C 0x2c, 0x2d, 0x2e
|
||||
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
|
||||
Prefix: 'emc6d100'
|
||||
Addresses scanned: I2C 0x2c, 0x2d, 0x2e
|
||||
|
@ -34,7 +38,7 @@ Description
|
|||
-----------
|
||||
|
||||
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.
|
||||
|
||||
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
|
||||
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
|
||||
temperatures with 0.25 degC resolution. They also provide an offset to the
|
||||
temperature readings that is automatically applied during measurement.
|
||||
This offset can be used to zero out any errors due to traces and placement.
|
||||
The documentation says that the offset is in 0.25 degC steps, but in
|
||||
initial testing of the ADM1027 it was 1.00 degC steps. Analog Devices has
|
||||
confirmed this "bug". The ADT7463 is reported to work as described in the
|
||||
documentation. The current lm85 driver does not show the offset register.
|
||||
The ADM1027, ADT7463 and ADT7468 have a 10-bit ADC and can therefore
|
||||
measure temperatures with 0.25 degC resolution. They also provide an offset
|
||||
to the temperature readings that is automatically applied during
|
||||
measurement. This offset can be used to zero out any errors due to traces
|
||||
and placement. The documentation says that the offset is in 0.25 degC
|
||||
steps, but in initial testing of the ADM1027 it was 1.00 degC steps. Analog
|
||||
Devices has confirmed this "bug". The ADT7463 is reported to work as
|
||||
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
|
||||
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
|
||||
these two chips. The LM85B is recommended for new designs.
|
||||
|
||||
The ADM1027 and ADT7463 chips have an optional SMBALERT output that can be
|
||||
used to signal the chipset in case a limit is exceeded or the temperature
|
||||
sensors fail. Individual sensor interrupts can be masked so they won't
|
||||
trigger SMBALERT. The SMBALERT output if configured replaces one of the other
|
||||
functions (PWM2 or IN0). This functionality is not implemented in current
|
||||
driver.
|
||||
The ADM1027, ADT7463 and ADT7468 chips have an optional SMBALERT output
|
||||
that can be used to signal the chipset in case a limit is exceeded or the
|
||||
temperature sensors fail. Individual sensor interrupts can be masked so
|
||||
they won't trigger SMBALERT. The SMBALERT output if configured replaces one
|
||||
of the other functions (PWM2 or IN0). This functionality is not implemented
|
||||
in current driver.
|
||||
|
||||
The ADT7463 also has an optional THERM output/input which can be connected
|
||||
to the processor PROC_HOT output. If available, the autofan control
|
||||
dynamic Tmin feature can be enabled to keep the system temperature within
|
||||
spec (just?!) with the least possible fan noise.
|
||||
The ADT7463 and ADT7468 also have an optional THERM output/input which can
|
||||
be connected to the processor PROC_HOT output. If available, the autofan
|
||||
control dynamic Tmin feature can be enabled to keep the system temperature
|
||||
within spec (just?!) with the least possible fan noise.
|
||||
|
||||
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
|
||||
driver.
|
||||
|
||||
In addition to the ADM1027 features, the ADT7463 also has Tmin control
|
||||
and THERM asserted counts. Automatic Tmin control acts to adjust the
|
||||
Tmin value to maintain the measured temperature sensor at a specified
|
||||
temperature. There isn't much documentation on this feature in the
|
||||
ADT7463 data sheet. This is not supported by current driver.
|
||||
In addition to the ADM1027 features, the ADT7463 and ADT7468 also have
|
||||
Tmin control and THERM asserted counts. Automatic Tmin control acts to
|
||||
adjust the Tmin value to maintain the measured temperature sensor at a
|
||||
specified temperature. There isn't much documentation on this feature in
|
||||
the ADT7463 data sheet. This is not supported by current driver.
|
||||
|
|
|
@ -63,8 +63,8 @@ Supported chips:
|
|||
Datasheet: Publicly available at the Maxim website
|
||||
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2578
|
||||
* Maxim MAX6659
|
||||
Prefix: 'max6657'
|
||||
Addresses scanned: I2C 0x4c, 0x4d (unsupported 0x4e)
|
||||
Prefix: 'max6659'
|
||||
Addresses scanned: I2C 0x4c, 0x4d, 0x4e
|
||||
Datasheet: Publicly available at the Maxim website
|
||||
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2578
|
||||
* Maxim MAX6680
|
||||
|
@ -84,6 +84,21 @@ Supported chips:
|
|||
Addresses scanned: I2C 0x4c
|
||||
Datasheet: Publicly available at the Maxim website
|
||||
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
|
||||
Prefix: 'w83l771'
|
||||
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.
|
||||
|
||||
Note that there is no easy way to differentiate between the MAX6657,
|
||||
MAX6658 and MAX6659 variants. The extra address and features of the
|
||||
MAX6659 are not supported by this driver. The MAX6680 and MAX6681 only
|
||||
differ in their pinout, therefore they obviously can't (and don't need to)
|
||||
be distinguished.
|
||||
MAX6658 and MAX6659 variants. The extra features of the MAX6659 are only
|
||||
supported by this driver if the chip is located at address 0x4d or 0x4e,
|
||||
or if the chip type is explicitly selected as max6659.
|
||||
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
|
||||
family is that it features critical limits with hysteresis, and an
|
||||
|
@ -151,12 +167,22 @@ MAX6680 and MAX6681:
|
|||
* Selectable address
|
||||
* Remote sensor type selection
|
||||
|
||||
W83L771AWG/ASG
|
||||
* The AWG and ASG variants only differ in package format.
|
||||
MAX6695 and MAX6696:
|
||||
* 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
|
||||
* Diode ideality factor configuration (remote sensor) at 0xE3
|
||||
* 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
|
||||
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
|
||||
|
|
|
@ -4,7 +4,7 @@ Kernel driver pcf8591
|
|||
Supported chips:
|
||||
* Philips/NXP PCF8591
|
||||
Prefix: 'pcf8591'
|
||||
Addresses scanned: I2C 0x48 - 0x4f
|
||||
Addresses scanned: none
|
||||
Datasheet: Publicly available at the NXP website
|
||||
http://www.nxp.com/pip/PCF8591_6.html
|
||||
|
||||
|
@ -58,18 +58,16 @@ Module parameters
|
|||
Accessing PCF8591 via /sys interface
|
||||
-------------------------------------
|
||||
|
||||
! Be careful !
|
||||
The PCF8591 is plainly impossible to detect! Stupid chip.
|
||||
So every chip with address in the interval [0x48..0x4f] is
|
||||
detected as PCF8591. If you have other chips in this address
|
||||
range, the workaround is to load this module after the one
|
||||
for your others chips.
|
||||
The PCF8591 is plainly impossible to detect! Thus the driver won't even
|
||||
try. You have to explicitly instantiate the device at the relevant
|
||||
address (in the interval [0x48..0x4f]) either through platform data, or
|
||||
using the sysfs interface. See Documentation/i2c/instantiating-devices
|
||||
for details.
|
||||
|
||||
On detection (i.e. insmod, modprobe et al.), directories are being
|
||||
created for each detected PCF8591:
|
||||
Directories are being created for each instantiated PCF8591:
|
||||
|
||||
/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])
|
||||
|
||||
Inside these directories, there are such files:
|
||||
|
|
|
@ -309,6 +309,20 @@ temp[1-*]_crit_hyst
|
|||
from the critical value.
|
||||
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
|
||||
corresponding temp_min values.
|
||||
Unit: millidegree Celsius
|
||||
|
@ -505,6 +519,7 @@ fan[1-*]_max_alarm
|
|||
temp[1-*]_min_alarm
|
||||
temp[1-*]_max_alarm
|
||||
temp[1-*]_crit_alarm
|
||||
temp[1-*]_emergency_alarm
|
||||
Limit alarm
|
||||
0: no alarm
|
||||
1: alarm
|
||||
|
|
|
@ -15,10 +15,14 @@ Supported adapters:
|
|||
* Intel 82801I (ICH9)
|
||||
* Intel EP80579 (Tolapai)
|
||||
* Intel 82801JI (ICH10)
|
||||
* Intel 3400/5 Series (PCH)
|
||||
* Intel 5/3400 Series (PCH)
|
||||
* Intel Cougar Point (PCH)
|
||||
* Intel Patsburg (PCH)
|
||||
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:
|
||||
Mark Studebaker <mdsxyz123@yahoo.com>
|
||||
Jean Delvare <khali@linux-fr.org>
|
||||
|
|
|
@ -259,7 +259,7 @@ Code Seq#(hex) Include File Comments
|
|||
't' 00-7F linux/if_ppp.h
|
||||
't' 80-8F linux/isdn_ppp.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' 00-1F linux/ext2_fs.h conflict!
|
||||
'v' 00-1F linux/fs.h conflict!
|
||||
|
@ -278,7 +278,6 @@ Code Seq#(hex) Include File Comments
|
|||
<mailto:oe@port.de>
|
||||
'z' 10-4F drivers/s390/crypto/zcrypt_api.h conflict!
|
||||
0x80 00-1F linux/fb.h
|
||||
0x81 00-1F linux/videotext.h
|
||||
0x88 00-3F media/ovcamchip.h
|
||||
0x89 00-06 arch/x86/include/asm/sockios.h
|
||||
0x89 0B-DF linux/sockios.h
|
||||
|
|
|
@ -322,7 +322,8 @@ mainmenu:
|
|||
"mainmenu" <prompt>
|
||||
|
||||
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
|
||||
|
|
|
@ -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
|
||||
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/",
|
||||
but in the architecture makefiles where the kbuild infrastructure
|
||||
is not sufficient this sometimes needs to be explicit.
|
||||
|
|
|
@ -1,215 +1,185 @@
|
|||
Building External Modules
|
||||
|
||||
In this document you will find information about:
|
||||
- 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
|
||||
This document describes how to build an out-of-tree kernel module.
|
||||
|
||||
=== Table of Contents
|
||||
|
||||
=== 1 Introduction
|
||||
=== 2 How to build external modules
|
||||
--- 2.1 Building external modules
|
||||
--- 2.2 Available targets
|
||||
--- 2.3 Available options
|
||||
--- 2.4 Preparing the kernel tree for module build
|
||||
--- 2.5 Building separate files for a module
|
||||
=== 3. Example commands
|
||||
=== 4. Creating a kbuild file for an external module
|
||||
=== 5. Include files
|
||||
--- 5.1 How to include files from the kernel include dir
|
||||
--- 5.2 External modules using an include/ dir
|
||||
--- 5.3 External modules using several directories
|
||||
=== 6. Module installation
|
||||
--- 6.1 INSTALL_MOD_PATH
|
||||
--- 6.2 INSTALL_MOD_DIR
|
||||
=== 7. Module versioning & Module.symvers
|
||||
--- 7.1 Symbols from the kernel (vmlinux + modules)
|
||||
--- 7.2 Symbols and external modules
|
||||
--- 7.3 Symbols from another external module
|
||||
=== 8. Tips & Tricks
|
||||
--- 8.1 Testing for CONFIG_FOO_BAR
|
||||
=== 2 How to Build External Modules
|
||||
--- 2.1 Command Syntax
|
||||
--- 2.2 Options
|
||||
--- 2.3 Targets
|
||||
--- 2.4 Building Separate Files
|
||||
=== 3. Creating a Kbuild File for an External Module
|
||||
--- 3.1 Shared Makefile
|
||||
--- 3.2 Separate Kbuild file and Makefile
|
||||
--- 3.3 Binary Blobs
|
||||
--- 3.4 Building Multiple Modules
|
||||
=== 4. Include Files
|
||||
--- 4.1 Kernel Includes
|
||||
--- 4.2 Single Subdirectory
|
||||
--- 4.3 Several Subdirectories
|
||||
=== 5. Module Installation
|
||||
--- 5.1 INSTALL_MOD_PATH
|
||||
--- 5.2 INSTALL_MOD_DIR
|
||||
=== 6. Module Versioning
|
||||
--- 6.1 Symbols From the Kernel (vmlinux + modules)
|
||||
--- 6.2 Symbols and External Modules
|
||||
--- 6.3 Symbols From Another External Module
|
||||
=== 7. Tips & Tricks
|
||||
--- 7.1 Testing for CONFIG_FOO_BAR
|
||||
|
||||
|
||||
|
||||
=== 1. Introduction
|
||||
|
||||
kbuild includes functionality for building modules both
|
||||
within the kernel source tree and outside the kernel source tree.
|
||||
The latter is usually referred to as external or "out-of-tree"
|
||||
modules and is used both during development and for modules that
|
||||
are not planned to be included in the kernel tree.
|
||||
"kbuild" is the build system used by the Linux kernel. Modules must use
|
||||
kbuild to stay compatible with changes in the build infrastructure and
|
||||
to pick up the right flags to "gcc." Functionality for building modules
|
||||
both in-tree and out-of-tree is provided. The method for building
|
||||
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
|
||||
of modules. The author of an external module should supply
|
||||
a makefile that hides most of the complexity, so one only has to type
|
||||
'make' to build the module. A complete example will be presented in
|
||||
chapter 4, "Creating a kbuild file for an external module".
|
||||
Covered in this document is information aimed at developers interested
|
||||
in building out-of-tree (or "external") modules. The author of an
|
||||
external module should supply a makefile that hides most of the
|
||||
complexity, so one only has to type "make" to build the module. This is
|
||||
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
|
||||
prerequisite that there is a pre-built kernel available with full source.
|
||||
A subset of the targets available when building the kernel is available
|
||||
when building an external module.
|
||||
To build external modules, you must have a prebuilt kernel available
|
||||
that contains the configuration and header files used in the build.
|
||||
Also, the kernel must have been built with modules enabled. If you are
|
||||
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
|
||||
built with modules enabled.
|
||||
The kbuild system knows that an external module is being built
|
||||
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
|
||||
be enough to get you started.
|
||||
Then to install the module(s) just built, add the target
|
||||
"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`
|
||||
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.
|
||||
($KDIR refers to the path of the kernel source directory.)
|
||||
|
||||
make -C $KDIR M=`pwd` modules
|
||||
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
|
||||
|
||||
make -C $KDIR M=`pwd` modules_install
|
||||
Install the external module(s).
|
||||
Installation default is in /lib/modules/<kernel-version>/extra,
|
||||
but may be prefixed with INSTALL_MOD_PATH - see separate
|
||||
chapter.
|
||||
-C $KDIR
|
||||
The directory where the kernel source is located.
|
||||
"make" will actually change to the specified directory
|
||||
when executing and will change back when finished.
|
||||
|
||||
make -C $KDIR M=`pwd` clean
|
||||
Remove all generated files for the module - the kernel
|
||||
source directory is not modified.
|
||||
M=$PWD
|
||||
Informs kbuild that an external module is being built.
|
||||
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
|
||||
help will list the available target when building external
|
||||
modules.
|
||||
--- 2.3 Targets
|
||||
|
||||
--- 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
|
||||
Used to specify where to find the kernel source.
|
||||
'$KDIR' represent the directory where the kernel source is.
|
||||
Make will actually change directory to the specified directory
|
||||
when executed but change back when finished.
|
||||
The default will build the module(s) located in the current
|
||||
directory, so a target does not need to be specified. All
|
||||
output files will also be generated in this directory. 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`
|
||||
M= is used to tell kbuild that an external module is
|
||||
being built.
|
||||
The option given to M= is the directory where the external
|
||||
module (kbuild file) is located.
|
||||
When an external module is being built only a subset of the
|
||||
usual targets are available.
|
||||
modules
|
||||
The default target for external modules. It has the
|
||||
same functionality as if no target was specified. See
|
||||
description above.
|
||||
|
||||
make -C $KDIR SUBDIRS=`pwd`
|
||||
Same as M=. The SUBDIRS= syntax is kept for backwards
|
||||
compatibility.
|
||||
modules_install
|
||||
Install the external module(s). The default location is
|
||||
/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
|
||||
build external modules the target 'modules_prepare' must be used.
|
||||
'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.
|
||||
help
|
||||
List the available targets for external modules.
|
||||
|
||||
--- 2.5 Building separate files for a module
|
||||
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
|
||||
--- 2.4 Building Separate Files
|
||||
|
||||
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.
|
||||
Examples (module foo.ko, consist of bar.o, baz.o):
|
||||
make -C $KDIR M=`pwd` bar.lst
|
||||
make -C $KDIR M=`pwd` bar.o
|
||||
make -C $KDIR M=`pwd` foo.ko
|
||||
make -C $KDIR M=`pwd` /
|
||||
|
||||
Example (The module foo.ko, consist of bar.o and baz.o):
|
||||
make -C $KDIR M=$PWD bar.lst
|
||||
make -C $KDIR M=$PWD baz.o
|
||||
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
|
||||
an external module for the currently running kernel.
|
||||
In the example below, the distribution is supposed to use the
|
||||
facility to locate output files for a kernel compile in a different
|
||||
directory than the kernel source - but the examples will also work
|
||||
when the source and the output files are mixed in the same directory.
|
||||
In the last section we saw the command to build a module for the
|
||||
running kernel. The module is not actually built, however, because a
|
||||
build file is required. Contained in this file will be the name of
|
||||
the module(s) being built, along with the list of requisite source
|
||||
files. The file may be as simple as a single line:
|
||||
|
||||
# Kernel source
|
||||
/lib/modules/<kernel-version>/source -> /usr/src/linux-<version>
|
||||
obj-m := <module_name>.o
|
||||
|
||||
# Output from kernel compile
|
||||
/lib/modules/<kernel-version>/build -> /usr/src/linux-<version>-up
|
||||
The kbuild system will build <module_name>.o from <module_name>.c,
|
||||
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
|
||||
the following commands to build the module:
|
||||
<module_name>-y := <src1>.o <src2>.o ...
|
||||
|
||||
cd /home/user/src/module
|
||||
make -C /usr/src/`uname -r`/source \
|
||||
O=/lib/modules/`uname-r`/build \
|
||||
M=`pwd`
|
||||
NOTE: Further documentation describing the syntax used by kbuild is
|
||||
located in Documentation/kbuild/makefiles.txt.
|
||||
|
||||
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.h
|
||||
8123_pci.c
|
||||
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
|
||||
building the module using 'make' with no arguments.
|
||||
The Makefile provided will most likely include additional
|
||||
functionality such as test targets etc. and this part shall
|
||||
be filtered away from kbuild since it may impact kbuild if
|
||||
name clashes occurs.
|
||||
An external module always includes a wrapper makefile that
|
||||
supports building the module using "make" with no arguments.
|
||||
This target is not used by kbuild; it is only for convenience.
|
||||
Additional functionality, such as test targets, can be included
|
||||
but should be filtered out from kbuild due to possible name
|
||||
clashes.
|
||||
|
||||
Example 1:
|
||||
--> filename: Makefile
|
||||
|
@ -219,11 +189,11 @@ following files:
|
|||
8123-y := 8123_if.o 8123_pci.o 8123_bin.o
|
||||
|
||||
else
|
||||
# Normal Makefile
|
||||
# normal makefile
|
||||
KDIR ?= /lib/modules/`uname -r`/build
|
||||
|
||||
KERNELDIR := /lib/modules/`uname -r`/build
|
||||
all::
|
||||
$(MAKE) -C $(KERNELDIR) M=`pwd` $@
|
||||
default:
|
||||
$(MAKE) -C $(KDIR) M=$$PWD
|
||||
|
||||
# Module specific targets
|
||||
genbin:
|
||||
|
@ -231,15 +201,20 @@ following files:
|
|||
|
||||
endif
|
||||
|
||||
In example 1, the check for KERNELRELEASE is used to separate
|
||||
the two parts of the Makefile. kbuild will only see the two
|
||||
assignments whereas make will see everything except the two
|
||||
kbuild assignments.
|
||||
The check for KERNELRELEASE is used to separate the two parts
|
||||
of the makefile. In the example, kbuild will only see the two
|
||||
assignments, whereas "make" will see everything except these
|
||||
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
|
||||
Kbuild and as second option look for a file named Makefile.
|
||||
Utilising the Kbuild file makes us split up the Makefile in example 1
|
||||
into two files as shown in example 2:
|
||||
--- 3.2 Separate Kbuild File and Makefile
|
||||
|
||||
In newer versions of the kernel, kbuild will first look for a
|
||||
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:
|
||||
--> filename: Kbuild
|
||||
|
@ -247,20 +222,21 @@ following files:
|
|||
8123-y := 8123_if.o 8123_pci.o 8123_bin.o
|
||||
|
||||
--> filename: Makefile
|
||||
KERNELDIR := /lib/modules/`uname -r`/build
|
||||
all::
|
||||
$(MAKE) -C $(KERNELDIR) M=`pwd` $@
|
||||
KDIR ?= /lib/modules/`uname -r`/build
|
||||
|
||||
default:
|
||||
$(MAKE) -C $(KDIR) M=$$PWD
|
||||
|
||||
# Module specific targets
|
||||
genbin:
|
||||
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
|
||||
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.
|
||||
The next example shows a backward compatible version.
|
||||
|
||||
Example 3:
|
||||
--> filename: Kbuild
|
||||
|
@ -269,13 +245,15 @@ following files:
|
|||
|
||||
--> filename: Makefile
|
||||
ifneq ($(KERNELRELEASE),)
|
||||
# kbuild part of makefile
|
||||
include Kbuild
|
||||
else
|
||||
# Normal Makefile
|
||||
|
||||
KERNELDIR := /lib/modules/`uname -r`/build
|
||||
all::
|
||||
$(MAKE) -C $(KERNELDIR) M=`pwd` $@
|
||||
else
|
||||
# normal makefile
|
||||
KDIR ?= /lib/modules/`uname -r`/build
|
||||
|
||||
default:
|
||||
$(MAKE) -C $(KDIR) M=$$PWD
|
||||
|
||||
# Module specific targets
|
||||
genbin:
|
||||
|
@ -283,260 +261,271 @@ following files:
|
|||
|
||||
endif
|
||||
|
||||
The trick here is to include the Kbuild file from Makefile, so
|
||||
if an older version of kbuild picks up the Makefile, the Kbuild
|
||||
file will be included.
|
||||
Here the "Kbuild" file is included from the makefile. This
|
||||
allows an older version of kbuild, which only knows of
|
||||
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
|
||||
has support for this, but requires the blob file to be named
|
||||
<filename>_shipped. In our example the blob is named
|
||||
8123_bin.o_shipped and when the kbuild rules kick in the file
|
||||
8123_bin.o is created as a simple copy off the 8213_bin.o_shipped file
|
||||
with the _shipped part stripped of the filename.
|
||||
This allows the 8123_bin.o filename to be used in the assignment to
|
||||
the module.
|
||||
Some external modules need to include an object file as a blob.
|
||||
kbuild has support for this, but requires the blob file to be
|
||||
named <filename>_shipped. When the kbuild rules kick in, a copy
|
||||
of <filename>_shipped is created with _shipped stripped off,
|
||||
giving us <filename>. This shortened filename can 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
|
||||
|
||||
In example 4, there is no distinction between the ordinary .c/.h files
|
||||
and the binary file. But kbuild will pick up different rules to create
|
||||
the .o file.
|
||||
Although there is no distinction between the ordinary source
|
||||
files and the binary file, kbuild will pick up different rules
|
||||
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
|
||||
files (not strictly in the sense of C, but if good programming practice is
|
||||
used). Any module that consists of more than one .c file will have a .h file
|
||||
for one of the .c files.
|
||||
Within the kernel, header files are kept in standard locations
|
||||
according to the following rule:
|
||||
|
||||
- If the .h file only describes a module internal interface, then the .h file
|
||||
shall be placed in the same directory as the .c files.
|
||||
- If the .h files describe an interface used by other parts of the kernel
|
||||
located in different directories, the .h files shall be located in
|
||||
include/linux/ or other include/ directories as appropriate.
|
||||
* If the header file only describes the internal interface of a
|
||||
module, then the file is placed in the same directory as the
|
||||
source files.
|
||||
* If the header file describes an interface used by other parts
|
||||
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
|
||||
under include/ such as include/scsi. Another exception is arch-specific
|
||||
.h files which are located under include/asm-$(ARCH)/*.
|
||||
NOTE: There are two notable exceptions to this rule: larger
|
||||
subsystems have their own directory under include/, such as
|
||||
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/
|
||||
directory and therefore need to deal with this in their kbuild file.
|
||||
--- 4.1 Kernel Includes
|
||||
|
||||
--- 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
|
||||
just uses:
|
||||
#include <linux/module.h>
|
||||
|
||||
#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
|
||||
directories are searched.
|
||||
Likewise for .h files placed in the same directory as the .c file.
|
||||
--- 4.2 Single Subdirectory
|
||||
|
||||
#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.
|
||||
|
||||
--- 5.2 External modules using an include/ dir
|
||||
|
||||
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:
|
||||
Using the example from section 3, if we moved 8123_if.h to a
|
||||
subdirectory named include, the resulting kbuild file would
|
||||
look like:
|
||||
|
||||
--> 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
|
||||
|
||||
Note that in the assignment there is no space between -I and the path.
|
||||
This is a kbuild limitation: there must be no space present.
|
||||
Note that in the assignment there is no space between -I and
|
||||
the path. This is a limitation of kbuild: there must be no
|
||||
space present.
|
||||
|
||||
--- 5.3 External modules using several directories
|
||||
|
||||
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.
|
||||
--- 4.3 Several Subdirectories
|
||||
|
||||
kbuild can handle files that are spread over several directories.
|
||||
Consider the following example:
|
||||
|
||||
|
|
||||
+- src/complex_main.c
|
||||
| +- hal/hardwareif.c
|
||||
| +- hal/include/hardwareif.h
|
||||
+- include/complex.h
|
||||
.
|
||||
|__ src
|
||||
| |__ complex_main.c
|
||||
| |__ hal
|
||||
| |__ 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:
|
||||
--> filename: Kbuild
|
||||
obj-m := complex.o
|
||||
complex-y := src/complex_main.o
|
||||
complex-y += src/hal/hardwareif.o
|
||||
|
||||
EXTRA_CFLAGS := -I$(src)/include
|
||||
EXTRA_CFLAGS += -I$(src)src/hal/include
|
||||
ccflags-y := -I$(src)/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 -
|
||||
although this is NOT recommended practice. The syntax is to specify
|
||||
the directory relative to the directory where the Kbuild file is
|
||||
located.
|
||||
=== 5. Module Installation
|
||||
|
||||
To find the .h files, we have to explicitly tell kbuild where to look
|
||||
for the .h files. When kbuild executes, the current directory is always
|
||||
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.
|
||||
Modules which are included in the kernel are installed in the
|
||||
directory:
|
||||
|
||||
=== 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
|
||||
|
||||
--- 6.1 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:
|
||||
Above are the default directories but as always some level of
|
||||
customization is possible. A prefix can be added to the
|
||||
installation path using the variable INSTALL_MOD_PATH:
|
||||
|
||||
$ 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
|
||||
example above, can be specified on the command line when calling make.
|
||||
INSTALL_MOD_PATH has effect both when installing modules included in
|
||||
the kernel as well as when installing external modules.
|
||||
INSTALL_MOD_PATH may be set as an ordinary shell variable or,
|
||||
as shown above, can be specified on the command line when
|
||||
calling "make." This has effect when installing both in-tree
|
||||
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
|
||||
directory under /lib/modules/$(KERNELRELEASE)/extra, but one may wish
|
||||
to locate modules for a specific functionality in a separate
|
||||
directory. For this purpose, one can use INSTALL_MOD_DIR to specify an
|
||||
alternative name to 'extra'.
|
||||
External modules are by default installed to a directory under
|
||||
/lib/modules/$(KERNELRELEASE)/extra/, but you may wish to
|
||||
locate modules for a specific functionality in a separate
|
||||
directory. For this purpose, use INSTALL_MOD_DIR to specify an
|
||||
alternative name to "extra."
|
||||
|
||||
$ make INSTALL_MOD_DIR=gandalf -C KERNELDIR \
|
||||
M=`pwd` modules_install
|
||||
=> Install dir: /lib/modules/$(KERNELRELEASE)/gandalf
|
||||
$ make INSTALL_MOD_DIR=gandalf -C $KDIR \
|
||||
M=$PWD modules_install
|
||||
=> 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
|
||||
versioning creates a CRC value of the full prototype for an exported symbol and
|
||||
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.
|
||||
|
||||
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 the kernel and
|
||||
compiled modules. For each symbols, the corresponding CRC value
|
||||
is stored too.
|
||||
During a kernel build, a file named Module.symvers will be
|
||||
generated. Module.symvers contains all exported symbols from
|
||||
the kernel and compiled modules. For each symbol, the
|
||||
corresponding CRC value is also stored.
|
||||
|
||||
The syntax of the Module.symvers file is:
|
||||
<CRC> <Symbol> <module>
|
||||
Sample:
|
||||
<CRC> <Symbol> <module>
|
||||
|
||||
0x2d036834 scsi_remove_host drivers/scsi/scsi_mod
|
||||
|
||||
For a kernel build without CONFIG_MODVERSIONS enabled, the crc
|
||||
would read: 0x00000000
|
||||
For a kernel build without CONFIG_MODVERSIONS enabled, the CRC
|
||||
would read 0x00000000.
|
||||
|
||||
Module.symvers serves two purposes:
|
||||
1) It lists all exported symbols both from vmlinux and all modules
|
||||
2) It lists the CRC if CONFIG_MODVERSIONS is enabled
|
||||
1) It lists all exported symbols from vmlinux and all modules.
|
||||
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
|
||||
the symbols from the kernel to check if all external symbols are
|
||||
defined. This is done in the MODPOST step and to obtain all
|
||||
symbols, modpost reads Module.symvers from the kernel.
|
||||
If a Module.symvers file is present in the directory where
|
||||
the external module is being built, this file will be read too.
|
||||
During the MODPOST step, a new Module.symvers file will be written
|
||||
containing all exported symbols that were not defined in the kernel.
|
||||
When building an external module, the build system needs access
|
||||
to the symbols from the kernel to check if all external symbols
|
||||
are defined. This is done in the MODPOST step. modpost obtains
|
||||
the symbols by reading Module.symvers from the kernel source
|
||||
tree. If a Module.symvers file is present in the directory
|
||||
where the external module is being built, this file will be
|
||||
read too. During the MODPOST step, a new Module.symvers file
|
||||
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
|
||||
external module. Kbuild needs to have full knowledge on all symbols
|
||||
to avoid spitting out warnings about undefined symbols.
|
||||
Three solutions exist to let kbuild know all symbols of more than
|
||||
one external module.
|
||||
The method with a top-level kbuild file is recommended but may be
|
||||
impractical in certain situations.
|
||||
Sometimes, an external module uses exported symbols from
|
||||
another external module. kbuild needs to have full knowledge of
|
||||
all symbols to avoid spitting out warnings about undefined
|
||||
symbols. Three solutions exist for this situation.
|
||||
|
||||
Use a top-level Kbuild file
|
||||
If you have two modules: 'foo' and 'bar', and 'foo' needs
|
||||
symbols from 'bar', then one can use a common top-level kbuild
|
||||
file so both modules are compiled in same build.
|
||||
NOTE: The method with a top-level kbuild file is recommended
|
||||
but may be impractical in certain situations.
|
||||
|
||||
Consider following directory layout:
|
||||
./foo/ <= contains the foo module
|
||||
./bar/ <= contains the bar module
|
||||
The top-level Kbuild file would then look like:
|
||||
Use a top-level kbuild file
|
||||
If you have two modules, foo.ko and bar.ko, where
|
||||
foo.ko needs symbols from bar.ko, you can use a
|
||||
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/
|
||||
|
||||
Executing:
|
||||
make -C $KDIR M=`pwd`
|
||||
And executing
|
||||
|
||||
will then do the expected and compile both modules with full
|
||||
knowledge on symbols from both modules.
|
||||
$ make -C $KDIR M=$PWD
|
||||
|
||||
will then do the expected and compile both modules with
|
||||
full knowledge of symbols from either module.
|
||||
|
||||
Use an extra Module.symvers file
|
||||
When an external module is built, a Module.symvers file is
|
||||
generated containing all exported symbols which are not
|
||||
defined in the kernel.
|
||||
To get access to symbols from module 'bar', one can copy the
|
||||
Module.symvers file from the compilation of the 'bar' module
|
||||
to the directory where the 'foo' module is built.
|
||||
During the module build, kbuild will read the Module.symvers
|
||||
file in the directory of the external module and when the
|
||||
build is finished, a new Module.symvers file is created
|
||||
containing the sum of all symbols defined and not part of the
|
||||
kernel.
|
||||
When an external module is built, a Module.symvers file
|
||||
is generated containing all exported symbols which are
|
||||
not defined in the kernel. To get access to symbols
|
||||
from bar.ko, copy the Module.symvers file from the
|
||||
compilation of bar.ko to the directory where foo.ko is
|
||||
built. During the module build, kbuild will read the
|
||||
Module.symvers file in the directory of the external
|
||||
module, and when the build is finished, a new
|
||||
Module.symvers file is created containing the sum of
|
||||
all symbols defined and not part of the kernel.
|
||||
|
||||
Use make variable KBUILD_EXTRA_SYMBOLS in the Makefile
|
||||
If it is impractical to copy Module.symvers from another
|
||||
module, you can assign a space separated list of files to
|
||||
KBUILD_EXTRA_SYMBOLS in your Makfile. These files will be
|
||||
loaded by modpost during the initialisation of its symbol
|
||||
tables.
|
||||
Use "make" variable KBUILD_EXTRA_SYMBOLS
|
||||
If it is impractical to copy Module.symvers from
|
||||
another module, you can assign a space separated list
|
||||
of files to KBUILD_EXTRA_SYMBOLS in your build file.
|
||||
These files will be loaded by modpost during the
|
||||
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
|
||||
a specific feature shall be included in the module. When kbuild is used
|
||||
this is done by referencing the CONFIG_ variable directly.
|
||||
--- 7.1 Testing for CONFIG_FOO_BAR
|
||||
|
||||
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
|
||||
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-$(CONFIG_EXT2_FS_XATTR) += xattr.o
|
||||
|
||||
External modules have traditionally used grep to check for specific
|
||||
CONFIG_ settings directly in .config. This usage is broken.
|
||||
As introduced before, external modules shall use kbuild when building
|
||||
and therefore can use the same methods as in-kernel modules when
|
||||
testing for CONFIG_ definitions.
|
||||
External modules have traditionally used "grep" to check for
|
||||
specific CONFIG_ settings directly in .config. This usage is
|
||||
broken. As introduced before, external modules should use
|
||||
kbuild for building and can therefore use the same methods as
|
||||
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.
|
||||
|
||||
elevator= [IOSCHED]
|
||||
Format: {"anticipatory" | "cfq" | "deadline" | "noop"}
|
||||
Format: {"cfq" | "deadline" | "noop"}
|
||||
See Documentation/block/as-iosched.txt and
|
||||
Documentation/block/deadline-iosched.txt for details.
|
||||
|
||||
|
@ -2175,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
|
||||
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]
|
||||
Specify the partition device for software suspend
|
||||
|
||||
|
|
|
@ -60,15 +60,18 @@ Hardware accelerated blink of LEDs
|
|||
|
||||
Some LEDs can be programmed to blink without any CPU interaction. To
|
||||
support this feature, a LED driver can optionally implement the
|
||||
blink_set() function (see <linux/leds.h>). If implemented, triggers can
|
||||
attempt to use it before falling back to software timers. The blink_set()
|
||||
function should return 0 if the blink setting is supported, or -EINVAL
|
||||
otherwise, which means that LED blinking will be handled by software.
|
||||
blink_set() function (see <linux/leds.h>). To set an LED to blinking,
|
||||
however, it is better to use use the API function led_blink_set(),
|
||||
as it will check and implement software fallback if necessary.
|
||||
|
||||
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.
|
||||
To turn off blinking again, use the API function led_brightness_set()
|
||||
as that will not just set the LED brightness but also stop any software
|
||||
timers that may have been required for blinking.
|
||||
|
||||
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
|
||||
should completely turn off the LED and cancel the previously programmed
|
||||
|
|
|
@ -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.
|
|
@ -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,
|
||||
};
|
|
@ -20,6 +20,15 @@ ip_no_pmtu_disc - BOOLEAN
|
|||
min_pmtu - INTEGER
|
||||
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
|
||||
Time, in seconds, that cached PMTU information is kept.
|
||||
|
||||
|
|
|
@ -177,18 +177,6 @@ Doing it all yourself
|
|||
|
||||
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_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
|
||||
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_gset(struct phy_device *phydev, struct ethtool_cmd *cmd);
|
||||
|
||||
|
|
|
@ -21,8 +21,8 @@ three rotations, respectively, to balance the tree), with slightly slower
|
|||
To quote Linux Weekly News:
|
||||
|
||||
There are a number of red-black trees in use in the kernel.
|
||||
The anticipatory, deadline, and CFQ I/O schedulers all employ
|
||||
rbtrees to track requests; the packet CD/DVD driver does the same.
|
||||
The deadline and CFQ I/O schedulers employ rbtrees to
|
||||
track requests; the packet CD/DVD driver does the same.
|
||||
The high-resolution timer code uses an rbtree to organize outstanding
|
||||
timer requests. The ext3 filesystem tracks directory entries in a
|
||||
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 -
|
||||
(emaild-id:megaraidlinux@lsi.com)
|
||||
Bo Yang
|
||||
|
|
|
@ -28,6 +28,7 @@ show up in /proc/sys/kernel:
|
|||
- core_uses_pid
|
||||
- ctrl-alt-del
|
||||
- dentry-state
|
||||
- dmesg_restrict
|
||||
- domainname
|
||||
- hostname
|
||||
- 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:
|
||||
|
||||
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
|
||||
daemon will start writeback.
|
||||
|
||||
If dirty_background_bytes is written, dirty_background_ratio becomes a function
|
||||
of its value (dirty_background_bytes / the amount of dirtyable system memory).
|
||||
Note: dirty_background_bytes is the counterpart of dirty_background_ratio. Only
|
||||
one of them may be specified at a time. When one sysctl is written it is
|
||||
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
|
||||
will itself start writeback.
|
||||
|
||||
If dirty_bytes is written, dirty_ratio becomes a function of its value
|
||||
(dirty_bytes / the amount of dirtyable system memory).
|
||||
Note: dirty_bytes is the counterpart of dirty_ratio. Only 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.
|
||||
|
||||
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
|
||||
|
|
|
@ -83,3 +83,4 @@
|
|||
82 -> WinFast DTV2000 H rev. J [107d:6f2b]
|
||||
83 -> Prof 7301 DVB-S/S2 [b034:3034]
|
||||
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)
|
||||
31 -> Usbgear VD204v9 (em2821)
|
||||
32 -> Supercomp USB 2.0 TV (em2821)
|
||||
33 -> Elgato Video Capture (em2860) [0fd9:0033]
|
||||
34 -> Terratec Cinergy A Hybrid XS (em2860) [0ccd:004f]
|
||||
35 -> Typhoon DVD Maker (em2860)
|
||||
36 -> NetGMBH Cam (em2860)
|
||||
|
@ -45,7 +46,7 @@
|
|||
45 -> Pinnacle PCTV DVB-T (em2870)
|
||||
46 -> Compro, VideoMate U3 (em2870) [185b:2870]
|
||||
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]
|
||||
50 -> MSI DigiVox A/D II (em2880) [eb1a:e320]
|
||||
51 -> Terratec Hybrid XS Secam (em2880) [0ccd:004c]
|
||||
|
|
|
@ -126,7 +126,7 @@
|
|||
125 -> Beholder BeholdTV 409 [0000:4090]
|
||||
126 -> Beholder BeholdTV 505 FM [5ace:5050]
|
||||
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]
|
||||
130 -> Beholder BeholdTV M6 [5ace:6190]
|
||||
131 -> Twinhan Hybrid DTV-DVB 3056 PCI [1822:0022]
|
||||
|
|
|
@ -19,7 +19,6 @@ function makedev () {
|
|||
echo "*** new device names ***"
|
||||
makedev video 0
|
||||
makedev radio 64
|
||||
makedev vtx 192
|
||||
makedev vbi 224
|
||||
|
||||
#echo "*** old device names (for compatibility only) ***"
|
||||
|
|
|
@ -302,12 +302,14 @@ sonixj 0c45:60fb Surfer NoName
|
|||
sonixj 0c45:60fc LG-LIC300
|
||||
sonixj 0c45:60fe Microdia Audio
|
||||
sonixj 0c45:6100 PC Camera (SN9C128)
|
||||
sonixj 0c45:6102 PC Camera (SN9C128)
|
||||
sonixj 0c45:610a PC Camera (SN9C128)
|
||||
sonixj 0c45:610b PC Camera (SN9C128)
|
||||
sonixj 0c45:610c PC Camera (SN9C128)
|
||||
sonixj 0c45:610e PC Camera (SN9C128)
|
||||
sonixj 0c45:6128 Microdia/Sonix SNP325
|
||||
sonixj 0c45:612a Avant Camera
|
||||
sonixj 0c45:612b Speed-Link REFLECT2
|
||||
sonixj 0c45:612c Typhoon Rasy Cam 1.3MPix
|
||||
sonixj 0c45:6130 Sonix Pccam
|
||||
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).
|
||||
|
||||
3) Creating V4L2 device nodes (/dev/videoX, /dev/vbiX, /dev/radioX and
|
||||
/dev/vtxX) and keeping track of device-node specific data.
|
||||
3) Creating V4L2 device nodes (/dev/videoX, /dev/vbiX and /dev/radioX)
|
||||
and keeping track of device-node specific 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
|
||||
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
|
||||
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.
|
||||
|
@ -448,6 +453,10 @@ You should also set these fields:
|
|||
- ioctl_ops: if you use the v4l2_ioctl_ops to simplify ioctl maintenance
|
||||
(highly recommended to use this and it might become compulsory in the
|
||||
future!), then set this to your v4l2_ioctl_ops struct.
|
||||
- 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
|
||||
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.
|
||||
|
@ -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
|
||||
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
|
||||
-------------------------
|
||||
|
@ -483,7 +508,6 @@ types exist:
|
|||
VFL_TYPE_GRABBER: videoX for video input/output devices
|
||||
VFL_TYPE_VBI: vbiX for vertical blank data (i.e. closed captions, teletext)
|
||||
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
|
||||
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,
|
||||
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
|
||||
an error as well, except for the ioctl and unlocked_ioctl file operations:
|
||||
those will still be passed on since some buffer ioctls may still be needed.
|
||||
device nodes open. So after the unregister all file operations (except
|
||||
release, of course) will return an error as well.
|
||||
|
||||
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.
|
||||
|
|
6
Kbuild
6
Kbuild
|
@ -53,7 +53,7 @@ targets += arch/$(SRCARCH)/kernel/asm-offsets.s
|
|||
# Default sed regexp - multiline due to syntax constraints
|
||||
define sed-y
|
||||
"/^->/{s:->#\(.*\):/* \1 */:; \
|
||||
s:^->\([^ ]*\) [\$$#]*\([-0-9]*\) \(.*\):#define \1 (\2) /* \3 */:; \
|
||||
s:^->\([^ ]*\) [\$$#]*\([-0-9]*\) \(.*\):#define \1 \2 /* \3 */:; \
|
||||
s:^->\([^ ]*\) [\$$#]*\([^ ]*\) \(.*\):#define \1 \2 /* \3 */:; \
|
||||
s:->::; p;}"
|
||||
endef
|
||||
|
@ -95,5 +95,5 @@ PHONY += missing-syscalls
|
|||
missing-syscalls: scripts/checksyscalls.sh FORCE
|
||||
$(call cmd,syscalls)
|
||||
|
||||
# Delete all targets during make clean
|
||||
clean-files := $(addprefix $(objtree)/,$(filter-out $(bounds-file) $(offsets-file),$(targets)))
|
||||
# Keep these two files during make clean
|
||||
no-clean-files := $(bounds-file) $(offsets-file)
|
||||
|
|
|
@ -0,0 +1,11 @@
|
|||
#
|
||||
# For a description of the syntax of this configuration file,
|
||||
# see Documentation/kbuild/kconfig-language.txt.
|
||||
#
|
||||
mainmenu "Linux/$ARCH $KERNELVERSION Kernel Configuration"
|
||||
|
||||
config SRCARCH
|
||||
string
|
||||
option env="SRCARCH"
|
||||
|
||||
source "arch/$SRCARCH/Kconfig"
|
53
MAINTAINERS
53
MAINTAINERS
|
@ -161,7 +161,7 @@ M: Greg Kroah-Hartman <gregkh@suse.de>
|
|||
L: linux-serial@vger.kernel.org
|
||||
W: http://serial.sourceforge.net
|
||||
S: Maintained
|
||||
T: quilt kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty-2.6.git
|
||||
F: drivers/serial/8250*
|
||||
F: include/linux/serial_8250.h
|
||||
|
||||
|
@ -432,7 +432,7 @@ AMS (Apple Motion Sensor) DRIVER
|
|||
M: Stelian Pop <stelian@popies.net>
|
||||
M: Michael Hanselmann <linux-kernel@hansmi.ch>
|
||||
S: Supported
|
||||
F: drivers/hwmon/ams/
|
||||
F: drivers/macintosh/ams/
|
||||
|
||||
AMSO1100 RNIC DRIVER
|
||||
M: Tom Tucker <tom@opengridcomputing.com>
|
||||
|
@ -1391,6 +1391,14 @@ L: netdev@vger.kernel.org
|
|||
S: Supported
|
||||
F: drivers/net/tg3.*
|
||||
|
||||
BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER
|
||||
M: Brett Rudley <brudley@broadcom.com>
|
||||
M: Henry Ptasinski <henryp@broadcom.com>
|
||||
M: Nohee Ko <noheek@broadcom.com>
|
||||
L: linux-wireless@vger.kernel.org
|
||||
S: Supported
|
||||
F: drivers/staging/brcm80211/
|
||||
|
||||
BROCADE BFA FC SCSI DRIVER
|
||||
M: Jing Huang <huangj@brocade.com>
|
||||
L: linux-scsi@vger.kernel.org
|
||||
|
@ -1605,7 +1613,7 @@ F: drivers/platform/x86/classmate-laptop.c
|
|||
COCCINELLE/Semantic Patches (SmPL)
|
||||
M: Julia Lawall <julia@diku.dk>
|
||||
M: Gilles Muller <Gilles.Muller@lip6.fr>
|
||||
M: Nicolas Palix <npalix@diku.dk>
|
||||
M: Nicolas Palix <npalix.work@gmail.com>
|
||||
L: cocci@diku.dk (moderated for non-subscribers)
|
||||
W: http://coccinelle.lip6.fr/
|
||||
S: Supported
|
||||
|
@ -1749,6 +1757,7 @@ L: linux-cris-kernel@axis.com
|
|||
W: http://developer.axis.com
|
||||
S: Maintained
|
||||
F: arch/cris/
|
||||
F: drivers/serial/crisv10.*
|
||||
|
||||
CRYPTO API
|
||||
M: Herbert Xu <herbert@gondor.apana.org.au>
|
||||
|
@ -3383,8 +3392,8 @@ F: Documentation/kdump/
|
|||
KERNEL AUTOMOUNTER (AUTOFS)
|
||||
M: "H. Peter Anvin" <hpa@zytor.com>
|
||||
L: autofs@linux.kernel.org
|
||||
S: Odd Fixes
|
||||
F: fs/autofs/
|
||||
S: Obsolete
|
||||
F: drivers/staging/autofs/
|
||||
|
||||
KERNEL AUTOMOUNTER v4 (AUTOFS4)
|
||||
M: Ian Kent <raven@themaw.net>
|
||||
|
@ -4448,7 +4457,7 @@ L: platform-driver-x86@vger.kernel.org
|
|||
S: Maintained
|
||||
F: drivers/platform/x86/panasonic-laptop.c
|
||||
|
||||
PANASONIC MN10300/AM33 PORT
|
||||
PANASONIC MN10300/AM33/AM34 PORT
|
||||
M: David Howells <dhowells@redhat.com>
|
||||
M: Koichi Yasutake <yasutake.koichi@jp.panasonic.com>
|
||||
L: linux-am33-list@redhat.com (moderated for non-subscribers)
|
||||
|
@ -5667,7 +5676,7 @@ S: Maintained
|
|||
|
||||
STAGING SUBSYSTEM
|
||||
M: Greg Kroah-Hartman <gregkh@suse.de>
|
||||
T: quilt kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-2.6.git
|
||||
L: devel@driverdev.osuosl.org
|
||||
S: Maintained
|
||||
F: drivers/staging/
|
||||
|
@ -5901,7 +5910,7 @@ S: Maintained
|
|||
TTY LAYER
|
||||
M: Greg Kroah-Hartman <gregkh@suse.de>
|
||||
S: Maintained
|
||||
T: quilt kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty-2.6.git
|
||||
F: drivers/char/tty_*
|
||||
F: drivers/serial/serial_core.c
|
||||
F: include/linux/serial_core.h
|
||||
|
@ -6224,7 +6233,7 @@ USB SUBSYSTEM
|
|||
M: Greg Kroah-Hartman <gregkh@suse.de>
|
||||
L: linux-usb@vger.kernel.org
|
||||
W: http://www.linux-usb.org
|
||||
T: quilt kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6.git
|
||||
S: Supported
|
||||
F: Documentation/usb/
|
||||
F: drivers/net/usb/
|
||||
|
@ -6457,6 +6466,12 @@ S: Maintained
|
|||
F: Documentation/hwmon/w83793
|
||||
F: drivers/hwmon/w83793.c
|
||||
|
||||
W83795 HARDWARE MONITORING DRIVER
|
||||
M: Jean Delvare <khali@linux-fr.org>
|
||||
L: lm-sensors@lm-sensors.org
|
||||
S: Maintained
|
||||
F: drivers/hwmon/w83795.c
|
||||
|
||||
W83L51xD SD/MMC CARD INTERFACE DRIVER
|
||||
M: Pierre Ossman <pierre@ossman.eu>
|
||||
S: Maintained
|
||||
|
@ -6581,11 +6596,25 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/mjg59/platform-drivers-x86.
|
|||
S: Maintained
|
||||
F: drivers/platform/x86
|
||||
|
||||
XEN PCI SUBSYSTEM
|
||||
M: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
L: xen-devel@lists.xensource.com (moderated for non-subscribers)
|
||||
S: Supported
|
||||
F: arch/x86/pci/*xen*
|
||||
F: drivers/pci/*xen*
|
||||
|
||||
XEN SWIOTLB SUBSYSTEM
|
||||
M: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
L: xen-devel@lists.xensource.com (moderated for non-subscribers)
|
||||
S: Supported
|
||||
F: arch/x86/xen/*swiotlb*
|
||||
F: drivers/xen/*swiotlb*
|
||||
|
||||
XEN HYPERVISOR INTERFACE
|
||||
M: Jeremy Fitzhardinge <jeremy@xensource.com>
|
||||
M: Chris Wright <chrisw@sous-sol.org>
|
||||
M: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
|
||||
M: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
L: xen-devel@lists.xensource.com (moderated for non-subscribers)
|
||||
L: virtualization@lists.osdl.org
|
||||
L: xen-devel@lists.xensource.com
|
||||
S: Supported
|
||||
F: arch/x86/xen/
|
||||
F: drivers/*/xen-*front.c
|
||||
|
|
40
Makefile
40
Makefile
|
@ -1,7 +1,7 @@
|
|||
VERSION = 2
|
||||
PATCHLEVEL = 6
|
||||
SUBLEVEL = 36
|
||||
EXTRAVERSION =
|
||||
SUBLEVEL = 37
|
||||
EXTRAVERSION = -rc1
|
||||
NAME = Flesh-Eating Bats with Fangs
|
||||
|
||||
# *DOCUMENTATION*
|
||||
|
@ -204,6 +204,9 @@ ifeq ($(ARCH),x86_64)
|
|||
endif
|
||||
|
||||
# Additional ARCH settings for sparc
|
||||
ifeq ($(ARCH),sparc32)
|
||||
SRCARCH := sparc
|
||||
endif
|
||||
ifeq ($(ARCH),sparc64)
|
||||
SRCARCH := sparc
|
||||
endif
|
||||
|
@ -1137,21 +1140,13 @@ MRPROPER_FILES += .config .config.old .version .old_version \
|
|||
#
|
||||
clean: rm-dirs := $(CLEAN_DIRS)
|
||||
clean: rm-files := $(CLEAN_FILES)
|
||||
clean-dirs := $(addprefix _clean_,$(srctree) $(vmlinux-alldirs) Documentation)
|
||||
clean-dirs := $(addprefix _clean_, . $(vmlinux-alldirs) Documentation)
|
||||
|
||||
PHONY += $(clean-dirs) clean archclean
|
||||
$(clean-dirs):
|
||||
$(Q)$(MAKE) $(clean)=$(patsubst _clean_%,%,$@)
|
||||
|
||||
clean: archclean $(clean-dirs)
|
||||
$(call cmd,rmdirs)
|
||||
$(call cmd,rmfiles)
|
||||
@find . $(RCS_FIND_IGNORE) \
|
||||
\( -name '*.[oas]' -o -name '*.ko' -o -name '.*.cmd' \
|
||||
-o -name '.*.d' -o -name '.*.tmp' -o -name '*.mod.c' \
|
||||
-o -name '*.symtypes' -o -name 'modules.order' \
|
||||
-o -name modules.builtin -o -name '.tmp_*.o.*' \
|
||||
-o -name '*.gcno' \) -type f -print | xargs rm -f
|
||||
clean: archclean
|
||||
|
||||
# mrproper - Delete all generated files, including .config
|
||||
#
|
||||
|
@ -1352,16 +1347,7 @@ $(clean-dirs):
|
|||
$(Q)$(MAKE) $(clean)=$(patsubst _clean_%,%,$@)
|
||||
|
||||
clean: rm-dirs := $(MODVERDIR)
|
||||
clean: rm-files := $(KBUILD_EXTMOD)/Module.symvers \
|
||||
$(KBUILD_EXTMOD)/modules.order \
|
||||
$(KBUILD_EXTMOD)/modules.builtin
|
||||
clean: $(clean-dirs)
|
||||
$(call cmd,rmdirs)
|
||||
$(call cmd,rmfiles)
|
||||
@find $(KBUILD_EXTMOD) $(RCS_FIND_IGNORE) \
|
||||
\( -name '*.[oas]' -o -name '*.ko' -o -name '.*.cmd' \
|
||||
-o -name '.*.d' -o -name '.*.tmp' -o -name '*.mod.c' \
|
||||
-o -name '*.gcno' \) -type f -print | xargs rm -f
|
||||
clean: rm-files := $(KBUILD_EXTMOD)/Module.symvers
|
||||
|
||||
help:
|
||||
@echo ' Building external modules.'
|
||||
|
@ -1378,6 +1364,16 @@ prepare: ;
|
|||
scripts: ;
|
||||
endif # KBUILD_EXTMOD
|
||||
|
||||
clean: $(clean-dirs)
|
||||
$(call cmd,rmdirs)
|
||||
$(call cmd,rmfiles)
|
||||
@find $(or $(KBUILD_EXTMOD), .) $(RCS_FIND_IGNORE) \
|
||||
\( -name '*.[oas]' -o -name '*.ko' -o -name '.*.cmd' \
|
||||
-o -name '.*.d' -o -name '.*.tmp' -o -name '*.mod.c' \
|
||||
-o -name '*.symtypes' -o -name 'modules.order' \
|
||||
-o -name modules.builtin -o -name '.tmp_*.o.*' \
|
||||
-o -name '*.gcno' \) -type f -print | xargs rm -f
|
||||
|
||||
# Generate tags for editors
|
||||
# ---------------------------------------------------------------------------
|
||||
quiet_cmd_tags = GEN $@
|
||||
|
|
1
README
1
README
|
@ -166,6 +166,7 @@ CONFIGURING the kernel:
|
|||
- Alternate configuration commands are:
|
||||
"make config" Plain text interface.
|
||||
"make menuconfig" Text based color menus, radiolists & dialogs.
|
||||
"make nconfig" Enhanced text based color menus.
|
||||
"make xconfig" X windows (Qt) based configuration tool.
|
||||
"make gconfig" X windows (Gtk) based configuration tool.
|
||||
"make oldconfig" Default all questions based on the contents of
|
||||
|
|
14
arch/Kconfig
14
arch/Kconfig
|
@ -42,6 +42,20 @@ config KPROBES
|
|||
for kernel debugging, non-intrusive instrumentation and testing.
|
||||
If in doubt, say "N".
|
||||
|
||||
config JUMP_LABEL
|
||||
bool "Optimize trace point call sites"
|
||||
depends on HAVE_ARCH_JUMP_LABEL
|
||||
help
|
||||
If it is detected that the compiler has support for "asm goto",
|
||||
the kernel will compile trace point locations with just a
|
||||
nop instruction. When trace points are enabled, the nop will
|
||||
be converted to a jump to the trace function. This technique
|
||||
lowers overhead and stress on the branch prediction of the
|
||||
processor.
|
||||
|
||||
On i386, options added to the compiler flags may increase
|
||||
the size of the kernel slightly.
|
||||
|
||||
config OPTPROBES
|
||||
def_bool y
|
||||
depends on KPROBES && HAVE_OPTPROBES
|
||||
|
|
|
@ -1,7 +1,3 @@
|
|||
#
|
||||
# For a description of the syntax of this configuration file,
|
||||
# see Documentation/kbuild/kconfig-language.txt.
|
||||
#
|
||||
config ALPHA
|
||||
bool
|
||||
default y
|
||||
|
|
|
@ -223,7 +223,7 @@ iommu_arena_free(struct pci_iommu_arena *arena, long ofs, long n)
|
|||
*/
|
||||
static int pci_dac_dma_supported(struct pci_dev *dev, u64 mask)
|
||||
{
|
||||
dma64_addr_t dac_offset = alpha_mv.pci_dac_offset;
|
||||
dma_addr_t dac_offset = alpha_mv.pci_dac_offset;
|
||||
int ok = 1;
|
||||
|
||||
/* If this is not set, the machine doesn't support DAC at all. */
|
||||
|
@ -756,7 +756,7 @@ static void alpha_pci_unmap_sg(struct device *dev, struct scatterlist *sg,
|
|||
spin_lock_irqsave(&arena->lock, flags);
|
||||
|
||||
for (end = sg + nents; sg < end; ++sg) {
|
||||
dma64_addr_t addr;
|
||||
dma_addr_t addr;
|
||||
size_t size;
|
||||
long npages, ofs;
|
||||
dma_addr_t tend;
|
||||
|
|
|
@ -269,7 +269,8 @@ void ptrace_disable(struct task_struct *child)
|
|||
user_disable_single_step(child);
|
||||
}
|
||||
|
||||
long arch_ptrace(struct task_struct *child, long request, long addr, long data)
|
||||
long arch_ptrace(struct task_struct *child, long request,
|
||||
unsigned long addr, unsigned long data)
|
||||
{
|
||||
unsigned long tmp;
|
||||
size_t copied;
|
||||
|
@ -292,7 +293,7 @@ long arch_ptrace(struct task_struct *child, long request, long addr, long data)
|
|||
case PTRACE_PEEKUSR:
|
||||
force_successful_syscall_return();
|
||||
ret = get_reg(child, addr);
|
||||
DBG(DBG_MEM, ("peek $%ld->%#lx\n", addr, ret));
|
||||
DBG(DBG_MEM, ("peek $%lu->%#lx\n", addr, ret));
|
||||
break;
|
||||
|
||||
/* When I and D space are separate, this will have to be fixed. */
|
||||
|
@ -302,7 +303,7 @@ long arch_ptrace(struct task_struct *child, long request, long addr, long data)
|
|||
break;
|
||||
|
||||
case PTRACE_POKEUSR: /* write the specified register */
|
||||
DBG(DBG_MEM, ("poke $%ld<-%#lx\n", addr, data));
|
||||
DBG(DBG_MEM, ("poke $%lu<-%#lx\n", addr, data));
|
||||
ret = put_reg(child, addr, data);
|
||||
break;
|
||||
default:
|
||||
|
|
|
@ -1,10 +1,3 @@
|
|||
#
|
||||
# For a description of the syntax of this configuration file,
|
||||
# see Documentation/kbuild/kconfig-language.txt.
|
||||
#
|
||||
|
||||
mainmenu "Linux Kernel Configuration"
|
||||
|
||||
config ARM
|
||||
bool
|
||||
default y
|
||||
|
@ -13,7 +6,7 @@ config ARM
|
|||
select HAVE_MEMBLOCK
|
||||
select RTC_LIB
|
||||
select SYS_SUPPORTS_APM_EMULATION
|
||||
select GENERIC_ATOMIC64 if (!CPU_32v6K)
|
||||
select GENERIC_ATOMIC64 if (!CPU_32v6K || !AEABI)
|
||||
select HAVE_OPROFILE if (HAVE_PERF_EVENTS)
|
||||
select HAVE_ARCH_KGDB
|
||||
select HAVE_KPROBES if (!XIP_KERNEL)
|
||||
|
@ -727,9 +720,11 @@ config ARCH_S5PC100
|
|||
config ARCH_S5PV210
|
||||
bool "Samsung S5PV210/S5PC110"
|
||||
select CPU_V7
|
||||
select ARCH_SPARSEMEM_ENABLE
|
||||
select GENERIC_GPIO
|
||||
select HAVE_CLK
|
||||
select ARM_L1_CACHE_SHIFT_6
|
||||
select ARCH_HAS_CPUFREQ
|
||||
select ARCH_USES_GETTIMEOFFSET
|
||||
select HAVE_S3C2410_I2C
|
||||
select HAVE_S3C_RTC
|
||||
|
@ -740,9 +735,13 @@ config ARCH_S5PV210
|
|||
config ARCH_S5PV310
|
||||
bool "Samsung S5PV310/S5PC210"
|
||||
select CPU_V7
|
||||
select ARCH_SPARSEMEM_ENABLE
|
||||
select GENERIC_GPIO
|
||||
select HAVE_CLK
|
||||
select GENERIC_CLOCKEVENTS
|
||||
select HAVE_S3C_RTC
|
||||
select HAVE_S3C2410_I2C
|
||||
select HAVE_S3C2410_WATCHDOG
|
||||
help
|
||||
Samsung S5PV310 series based systems
|
||||
|
||||
|
@ -1669,6 +1668,12 @@ if ARCH_HAS_CPUFREQ
|
|||
|
||||
source "drivers/cpufreq/Kconfig"
|
||||
|
||||
config CPU_FREQ_IMX
|
||||
tristate "CPUfreq driver for i.MX CPUs"
|
||||
depends on ARCH_MXC && CPU_FREQ
|
||||
help
|
||||
This enables the CPUfreq driver for i.MX CPUs.
|
||||
|
||||
config CPU_FREQ_SA1100
|
||||
bool
|
||||
|
||||
|
|
|
@ -251,15 +251,16 @@ void __init gic_dist_init(unsigned int gic_nr, void __iomem *base,
|
|||
writel(cpumask, base + GIC_DIST_TARGET + i * 4 / 4);
|
||||
|
||||
/*
|
||||
* Set priority on all interrupts.
|
||||
* Set priority on all global interrupts.
|
||||
*/
|
||||
for (i = 0; i < max_irq; i += 4)
|
||||
for (i = 32; i < max_irq; i += 4)
|
||||
writel(0xa0a0a0a0, base + GIC_DIST_PRI + i * 4 / 4);
|
||||
|
||||
/*
|
||||
* Disable all interrupts.
|
||||
* Disable all interrupts. Leave the PPI and SGIs alone
|
||||
* as these enables are banked registers.
|
||||
*/
|
||||
for (i = 0; i < max_irq; i += 32)
|
||||
for (i = 32; i < max_irq; i += 32)
|
||||
writel(0xffffffff, base + GIC_DIST_ENABLE_CLEAR + i * 4 / 32);
|
||||
|
||||
/*
|
||||
|
@ -277,11 +278,30 @@ void __init gic_dist_init(unsigned int gic_nr, void __iomem *base,
|
|||
|
||||
void __cpuinit gic_cpu_init(unsigned int gic_nr, void __iomem *base)
|
||||
{
|
||||
void __iomem *dist_base;
|
||||
int i;
|
||||
|
||||
if (gic_nr >= MAX_GIC_NR)
|
||||
BUG();
|
||||
|
||||
dist_base = gic_data[gic_nr].dist_base;
|
||||
BUG_ON(!dist_base);
|
||||
|
||||
gic_data[gic_nr].cpu_base = base;
|
||||
|
||||
/*
|
||||
* Deal with the banked PPI and SGI interrupts - disable all
|
||||
* PPI interrupts, ensure all SGI interrupts are enabled.
|
||||
*/
|
||||
writel(0xffff0000, dist_base + GIC_DIST_ENABLE_CLEAR);
|
||||
writel(0x0000ffff, dist_base + GIC_DIST_ENABLE_SET);
|
||||
|
||||
/*
|
||||
* Set priority on PPI and SGI interrupts
|
||||
*/
|
||||
for (i = 0; i < 32; i += 4)
|
||||
writel(0xa0a0a0a0, dist_base + GIC_DIST_PRI + i * 4 / 4);
|
||||
|
||||
writel(0xf0, base + GIC_CPU_PRIMASK);
|
||||
writel(1, base + GIC_CPU_CTRL);
|
||||
}
|
||||
|
|
|
@ -82,6 +82,7 @@ CONFIG_FEC=y
|
|||
CONFIG_INPUT_FF_MEMLESS=m
|
||||
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
|
||||
CONFIG_INPUT_EVDEV=y
|
||||
CONFIG_KEYBOARD_GPIO=y
|
||||
CONFIG_INPUT_EVBUG=m
|
||||
CONFIG_MOUSE_PS2=m
|
||||
CONFIG_MOUSE_PS2_ELANTECH=y
|
||||
|
|
|
@ -21,9 +21,6 @@
|
|||
#define __ASM_ARM_HARDWARE_L2X0_H
|
||||
|
||||
#define L2X0_CACHE_ID 0x000
|
||||
#define L2X0_CACHE_ID_PART_MASK (0xf << 6)
|
||||
#define L2X0_CACHE_ID_PART_L210 (1 << 6)
|
||||
#define L2X0_CACHE_ID_PART_L310 (3 << 6)
|
||||
#define L2X0_CACHE_TYPE 0x004
|
||||
#define L2X0_CTRL 0x100
|
||||
#define L2X0_AUX_CTRL 0x104
|
||||
|
@ -53,6 +50,16 @@
|
|||
#define L2X0_LINE_DATA 0xF10
|
||||
#define L2X0_LINE_TAG 0xF30
|
||||
#define L2X0_DEBUG_CTRL 0xF40
|
||||
#define L2X0_PREFETCH_CTRL 0xF60
|
||||
#define L2X0_POWER_CTRL 0xF80
|
||||
#define L2X0_DYNAMIC_CLK_GATING_EN (1 << 1)
|
||||
#define L2X0_STNDBY_MODE_EN (1 << 0)
|
||||
|
||||
/* Registers shifts and masks */
|
||||
#define L2X0_CACHE_ID_PART_MASK (0xf << 6)
|
||||
#define L2X0_CACHE_ID_PART_L210 (1 << 6)
|
||||
#define L2X0_CACHE_ID_PART_L310 (3 << 6)
|
||||
#define L2X0_AUX_CTRL_WAY_SIZE_MASK (0x3 << 17)
|
||||
|
||||
#ifndef __ASSEMBLY__
|
||||
extern void __init l2x0_init(void __iomem *base, __u32 aux_val, __u32 aux_mask);
|
||||
|
|
|
@ -75,7 +75,7 @@ extern unsigned long it8152_base_address;
|
|||
IT8152_PD_IRQ(1) USB (USBR)
|
||||
IT8152_PD_IRQ(0) Audio controller (ACR)
|
||||
*/
|
||||
#define IT8152_IRQ(x) (IRQ_BOARD_END + (x))
|
||||
#define IT8152_IRQ(x) (IRQ_BOARD_START + (x))
|
||||
|
||||
/* IRQ-sources in 3 groups - local devices, LPC (serial), and external PCI */
|
||||
#define IT8152_LD_IRQ_COUNT 9
|
||||
|
|
|
@ -70,7 +70,8 @@ extern int kgdb_fault_expected;
|
|||
#define _GP_REGS 16
|
||||
#define _FP_REGS 8
|
||||
#define _EXTRA_REGS 2
|
||||
#define DBG_MAX_REG_NUM (_GP_REGS + (_FP_REGS * 3) + _EXTRA_REGS)
|
||||
#define GDB_MAX_REGS (_GP_REGS + (_FP_REGS * 3) + _EXTRA_REGS)
|
||||
#define DBG_MAX_REG_NUM (_GP_REGS + _FP_REGS + _EXTRA_REGS)
|
||||
|
||||
#define KGDB_MAX_NO_CPUS 1
|
||||
#define BUFMAX 400
|
||||
|
@ -93,7 +94,7 @@ extern int kgdb_fault_expected;
|
|||
#define _SPT 13
|
||||
#define _LR 14
|
||||
#define _PC 15
|
||||
#define _CPSR (DBG_MAX_REG_NUM - 1)
|
||||
#define _CPSR (GDB_MAX_REGS - 1)
|
||||
|
||||
/*
|
||||
* So that we can denote the end of a frame for tracing,
|
||||
|
|
|
@ -1,13 +1,6 @@
|
|||
#ifndef _ASM_ARM_MEMBLOCK_H
|
||||
#define _ASM_ARM_MEMBLOCK_H
|
||||
|
||||
#ifdef CONFIG_MMU
|
||||
extern phys_addr_t lowmem_end_addr;
|
||||
#define MEMBLOCK_REAL_LIMIT lowmem_end_addr
|
||||
#else
|
||||
#define MEMBLOCK_REAL_LIMIT 0
|
||||
#endif
|
||||
|
||||
struct meminfo;
|
||||
struct machine_desc;
|
||||
|
||||
|
|
|
@ -25,6 +25,9 @@ struct outer_cache_fns {
|
|||
void (*inv_range)(unsigned long, unsigned long);
|
||||
void (*clean_range)(unsigned long, unsigned long);
|
||||
void (*flush_range)(unsigned long, unsigned long);
|
||||
void (*flush_all)(void);
|
||||
void (*inv_all)(void);
|
||||
void (*disable)(void);
|
||||
#ifdef CONFIG_OUTER_CACHE_SYNC
|
||||
void (*sync)(void);
|
||||
#endif
|
||||
|
@ -50,6 +53,24 @@ static inline void outer_flush_range(unsigned long start, unsigned long end)
|
|||
outer_cache.flush_range(start, end);
|
||||
}
|
||||
|
||||
static inline void outer_flush_all(void)
|
||||
{
|
||||
if (outer_cache.flush_all)
|
||||
outer_cache.flush_all();
|
||||
}
|
||||
|
||||
static inline void outer_inv_all(void)
|
||||
{
|
||||
if (outer_cache.inv_all)
|
||||
outer_cache.inv_all();
|
||||
}
|
||||
|
||||
static inline void outer_disable(void)
|
||||
{
|
||||
if (outer_cache.disable)
|
||||
outer_cache.disable();
|
||||
}
|
||||
|
||||
#else
|
||||
|
||||
static inline void outer_inv_range(unsigned long start, unsigned long end)
|
||||
|
@ -58,6 +79,9 @@ static inline void outer_clean_range(unsigned long start, unsigned long end)
|
|||
{ }
|
||||
static inline void outer_flush_range(unsigned long start, unsigned long end)
|
||||
{ }
|
||||
static inline void outer_flush_all(void) { }
|
||||
static inline void outer_inv_all(void) { }
|
||||
static inline void outer_disable(void) { }
|
||||
|
||||
#endif
|
||||
|
||||
|
|
|
@ -748,8 +748,7 @@ static int hw_breakpoint_pending(unsigned long addr, unsigned int fsr,
|
|||
breakpoint_handler(addr, regs);
|
||||
break;
|
||||
case ARM_ENTRY_ASYNC_WATCHPOINT:
|
||||
WARN_ON("Asynchronous watchpoint exception taken. "
|
||||
"Debugging results may be unreliable");
|
||||
WARN(1, "Asynchronous watchpoint exception taken. Debugging results may be unreliable\n");
|
||||
case ARM_ENTRY_SYNC_WATCHPOINT:
|
||||
watchpoint_handler(addr, regs);
|
||||
break;
|
||||
|
|
|
@ -79,7 +79,7 @@ sleeping_thread_to_gdb_regs(unsigned long *gdb_regs, struct task_struct *task)
|
|||
return;
|
||||
|
||||
/* Initialize to zero */
|
||||
for (regno = 0; regno < DBG_MAX_REG_NUM; regno++)
|
||||
for (regno = 0; regno < GDB_MAX_REGS; regno++)
|
||||
gdb_regs[regno] = 0;
|
||||
|
||||
/* Otherwise, we have only some registers from switch_to() */
|
||||
|
|
|
@ -78,7 +78,10 @@ void machine_kexec(struct kimage *image)
|
|||
local_fiq_disable();
|
||||
setup_mm_for_reboot(0); /* mode is not used, so just pass 0*/
|
||||
flush_cache_all();
|
||||
outer_flush_all();
|
||||
outer_disable();
|
||||
cpu_proc_fin();
|
||||
outer_inv_all();
|
||||
flush_cache_all();
|
||||
cpu_reset(reboot_code_buffer_phys);
|
||||
}
|
||||
|
|
|
@ -1749,7 +1749,7 @@ static inline int armv7_pmnc_has_overflowed(unsigned long pmnc)
|
|||
static inline int armv7_pmnc_counter_has_overflowed(unsigned long pmnc,
|
||||
enum armv7_counters counter)
|
||||
{
|
||||
int ret;
|
||||
int ret = 0;
|
||||
|
||||
if (counter == ARMV7_CYCLE_COUNTER)
|
||||
ret = pmnc & ARMV7_FLAG_C;
|
||||
|
|
|
@ -1075,13 +1075,15 @@ out:
|
|||
}
|
||||
#endif
|
||||
|
||||
long arch_ptrace(struct task_struct *child, long request, long addr, long data)
|
||||
long arch_ptrace(struct task_struct *child, long request,
|
||||
unsigned long addr, unsigned long data)
|
||||
{
|
||||
int ret;
|
||||
unsigned long __user *datap = (unsigned long __user *) data;
|
||||
|
||||
switch (request) {
|
||||
case PTRACE_PEEKUSR:
|
||||
ret = ptrace_read_user(child, addr, (unsigned long __user *)data);
|
||||
ret = ptrace_read_user(child, addr, datap);
|
||||
break;
|
||||
|
||||
case PTRACE_POKEUSR:
|
||||
|
@ -1089,34 +1091,34 @@ long arch_ptrace(struct task_struct *child, long request, long addr, long data)
|
|||
break;
|
||||
|
||||
case PTRACE_GETREGS:
|
||||
ret = ptrace_getregs(child, (void __user *)data);
|
||||
ret = ptrace_getregs(child, datap);
|
||||
break;
|
||||
|
||||
case PTRACE_SETREGS:
|
||||
ret = ptrace_setregs(child, (void __user *)data);
|
||||
ret = ptrace_setregs(child, datap);
|
||||
break;
|
||||
|
||||
case PTRACE_GETFPREGS:
|
||||
ret = ptrace_getfpregs(child, (void __user *)data);
|
||||
ret = ptrace_getfpregs(child, datap);
|
||||
break;
|
||||
|
||||
case PTRACE_SETFPREGS:
|
||||
ret = ptrace_setfpregs(child, (void __user *)data);
|
||||
ret = ptrace_setfpregs(child, datap);
|
||||
break;
|
||||
|
||||
#ifdef CONFIG_IWMMXT
|
||||
case PTRACE_GETWMMXREGS:
|
||||
ret = ptrace_getwmmxregs(child, (void __user *)data);
|
||||
ret = ptrace_getwmmxregs(child, datap);
|
||||
break;
|
||||
|
||||
case PTRACE_SETWMMXREGS:
|
||||
ret = ptrace_setwmmxregs(child, (void __user *)data);
|
||||
ret = ptrace_setwmmxregs(child, datap);
|
||||
break;
|
||||
#endif
|
||||
|
||||
case PTRACE_GET_THREAD_AREA:
|
||||
ret = put_user(task_thread_info(child)->tp_value,
|
||||
(unsigned long __user *) data);
|
||||
datap);
|
||||
break;
|
||||
|
||||
case PTRACE_SET_SYSCALL:
|
||||
|
@ -1126,21 +1128,21 @@ long arch_ptrace(struct task_struct *child, long request, long addr, long data)
|
|||
|
||||
#ifdef CONFIG_CRUNCH
|
||||
case PTRACE_GETCRUNCHREGS:
|
||||
ret = ptrace_getcrunchregs(child, (void __user *)data);
|
||||
ret = ptrace_getcrunchregs(child, datap);
|
||||
break;
|
||||
|
||||
case PTRACE_SETCRUNCHREGS:
|
||||
ret = ptrace_setcrunchregs(child, (void __user *)data);
|
||||
ret = ptrace_setcrunchregs(child, datap);
|
||||
break;
|
||||
#endif
|
||||
|
||||
#ifdef CONFIG_VFP
|
||||
case PTRACE_GETVFPREGS:
|
||||
ret = ptrace_getvfpregs(child, (void __user *)data);
|
||||
ret = ptrace_getvfpregs(child, datap);
|
||||
break;
|
||||
|
||||
case PTRACE_SETVFPREGS:
|
||||
ret = ptrace_setvfpregs(child, (void __user *)data);
|
||||
ret = ptrace_setvfpregs(child, datap);
|
||||
break;
|
||||
#endif
|
||||
|
||||
|
|
|
@ -28,7 +28,7 @@ int notrace unwind_frame(struct stackframe *frame)
|
|||
|
||||
/* only go to a higher address on the stack */
|
||||
low = frame->sp;
|
||||
high = ALIGN(low, THREAD_SIZE) + THREAD_SIZE;
|
||||
high = ALIGN(low, THREAD_SIZE);
|
||||
|
||||
/* check current frame pointer is within bounds */
|
||||
if (fp < (low + 12) || fp + 4 >= high)
|
||||
|
|
|
@ -53,10 +53,7 @@ static void dump_mem(const char *, const char *, unsigned long, unsigned long);
|
|||
void dump_backtrace_entry(unsigned long where, unsigned long from, unsigned long frame)
|
||||
{
|
||||
#ifdef CONFIG_KALLSYMS
|
||||
char sym1[KSYM_SYMBOL_LEN], sym2[KSYM_SYMBOL_LEN];
|
||||
sprint_symbol(sym1, where);
|
||||
sprint_symbol(sym2, from);
|
||||
printk("[<%08lx>] (%s) from [<%08lx>] (%s)\n", where, sym1, from, sym2);
|
||||
printk("[<%08lx>] (%pS) from [<%08lx>] (%pS)\n", where, (void *)where, from, (void *)from);
|
||||
#else
|
||||
printk("Function entered at [<%08lx>] from [<%08lx>]\n", where, from);
|
||||
#endif
|
||||
|
|
|
@ -279,7 +279,7 @@ int unwind_frame(struct stackframe *frame)
|
|||
|
||||
/* only go to a higher address on the stack */
|
||||
low = frame->sp;
|
||||
high = ALIGN(low, THREAD_SIZE) + THREAD_SIZE;
|
||||
high = ALIGN(low, THREAD_SIZE);
|
||||
|
||||
pr_debug("%s(pc = %08lx lr = %08lx sp = %08lx)\n", __func__,
|
||||
frame->pc, frame->lr, frame->sp);
|
||||
|
|
|
@ -113,6 +113,7 @@ SECTIONS
|
|||
*(.rodata.*)
|
||||
*(.glue_7)
|
||||
*(.glue_7t)
|
||||
. = ALIGN(4);
|
||||
*(.got) /* Global offset table */
|
||||
ARM_CPU_KEEP(PROC_INFO)
|
||||
}
|
||||
|
|
|
@ -1,5 +1,13 @@
|
|||
/*
|
||||
* arch/arm/mach-ep93xx/include/mach/dma.h
|
||||
/**
|
||||
* DOC: EP93xx DMA M2P memory to peripheral and peripheral to memory engine
|
||||
*
|
||||
* The EP93xx DMA M2P subsystem handles DMA transfers between memory and
|
||||
* peripherals. DMA M2P channels are available for audio, UARTs and IrDA.
|
||||
* See chapter 10 of the EP93xx users guide for full details on the DMA M2P
|
||||
* engine.
|
||||
*
|
||||
* See sound/soc/ep93xx/ep93xx-pcm.c for an example use of the DMA M2P code.
|
||||
*
|
||||
*/
|
||||
|
||||
#ifndef __ASM_ARCH_DMA_H
|
||||
|
@ -8,12 +16,34 @@
|
|||
#include <linux/list.h>
|
||||
#include <linux/types.h>
|
||||
|
||||
/**
|
||||
* struct ep93xx_dma_buffer - Information about a buffer to be transferred
|
||||
* using the DMA M2P engine
|
||||
*
|
||||
* @list: Entry in DMA buffer list
|
||||
* @bus_addr: Physical address of the buffer
|
||||
* @size: Size of the buffer in bytes
|
||||
*/
|
||||
struct ep93xx_dma_buffer {
|
||||
struct list_head list;
|
||||
u32 bus_addr;
|
||||
u16 size;
|
||||
};
|
||||
|
||||
/**
|
||||
* struct ep93xx_dma_m2p_client - Information about a DMA M2P client
|
||||
*
|
||||
* @name: Unique name for this client
|
||||
* @flags: Client flags
|
||||
* @cookie: User data to pass to callback functions
|
||||
* @buffer_started: Non NULL function to call when a transfer is started.
|
||||
* The arguments are the user data cookie and the DMA
|
||||
* buffer which is starting.
|
||||
* @buffer_finished: Non NULL function to call when a transfer is completed.
|
||||
* The arguments are the user data cookie, the DMA buffer
|
||||
* which has completed, and a boolean flag indicating if
|
||||
* the transfer had an error.
|
||||
*/
|
||||
struct ep93xx_dma_m2p_client {
|
||||
char *name;
|
||||
u8 flags;
|
||||
|
@ -24,10 +54,11 @@ struct ep93xx_dma_m2p_client {
|
|||
struct ep93xx_dma_buffer *buf,
|
||||
int bytes, int error);
|
||||
|
||||
/* Internal to the DMA code. */
|
||||
/* private: Internal use only */
|
||||
void *channel;
|
||||
};
|
||||
|
||||
/* DMA M2P ports */
|
||||
#define EP93XX_DMA_M2P_PORT_I2S1 0x00
|
||||
#define EP93XX_DMA_M2P_PORT_I2S2 0x01
|
||||
#define EP93XX_DMA_M2P_PORT_AAC1 0x02
|
||||
|
@ -39,18 +70,80 @@ struct ep93xx_dma_m2p_client {
|
|||
#define EP93XX_DMA_M2P_PORT_UART3 0x08
|
||||
#define EP93XX_DMA_M2P_PORT_IRDA 0x09
|
||||
#define EP93XX_DMA_M2P_PORT_MASK 0x0f
|
||||
#define EP93XX_DMA_M2P_TX 0x00
|
||||
#define EP93XX_DMA_M2P_RX 0x10
|
||||
#define EP93XX_DMA_M2P_ABORT_ON_ERROR 0x20
|
||||
#define EP93XX_DMA_M2P_IGNORE_ERROR 0x40
|
||||
#define EP93XX_DMA_M2P_ERROR_MASK 0x60
|
||||
|
||||
int ep93xx_dma_m2p_client_register(struct ep93xx_dma_m2p_client *m2p);
|
||||
/* DMA M2P client flags */
|
||||
#define EP93XX_DMA_M2P_TX 0x00 /* Memory to peripheral */
|
||||
#define EP93XX_DMA_M2P_RX 0x10 /* Peripheral to memory */
|
||||
|
||||
/*
|
||||
* DMA M2P client error handling flags. See the EP93xx users guide
|
||||
* documentation on the DMA M2P CONTROL register for more details
|
||||
*/
|
||||
#define EP93XX_DMA_M2P_ABORT_ON_ERROR 0x20 /* Abort on peripheral error */
|
||||
#define EP93XX_DMA_M2P_IGNORE_ERROR 0x40 /* Ignore peripheral errors */
|
||||
#define EP93XX_DMA_M2P_ERROR_MASK 0x60 /* Mask of error bits */
|
||||
|
||||
/**
|
||||
* ep93xx_dma_m2p_client_register - Register a client with the DMA M2P
|
||||
* subsystem
|
||||
*
|
||||
* @m2p: Client information to register
|
||||
* returns 0 on success
|
||||
*
|
||||
* The DMA M2P subsystem allocates a channel and an interrupt line for the DMA
|
||||
* client
|
||||
*/
|
||||
int ep93xx_dma_m2p_client_register(struct ep93xx_dma_m2p_client *m2p);
|
||||
|
||||
/**
|
||||
* ep93xx_dma_m2p_client_unregister - Unregister a client from the DMA M2P
|
||||
* subsystem
|
||||
*
|
||||
* @m2p: Client to unregister
|
||||
*
|
||||
* Any transfers currently in progress will be completed in hardware, but
|
||||
* ignored in software.
|
||||
*/
|
||||
void ep93xx_dma_m2p_client_unregister(struct ep93xx_dma_m2p_client *m2p);
|
||||
|
||||
/**
|
||||
* ep93xx_dma_m2p_submit - Submit a DMA M2P transfer
|
||||
*
|
||||
* @m2p: DMA Client to submit the transfer on
|
||||
* @buf: DMA Buffer to submit
|
||||
*
|
||||
* If the current or next transfer positions are free on the M2P client then
|
||||
* the transfer is started immediately. If not, the transfer is added to the
|
||||
* list of pending transfers. This function must not be called from the
|
||||
* buffer_finished callback for an M2P channel.
|
||||
*
|
||||
*/
|
||||
void ep93xx_dma_m2p_submit(struct ep93xx_dma_m2p_client *m2p,
|
||||
struct ep93xx_dma_buffer *buf);
|
||||
|
||||
/**
|
||||
* ep93xx_dma_m2p_submit_recursive - Put a DMA transfer on the pending list
|
||||
* for an M2P channel
|
||||
*
|
||||
* @m2p: DMA Client to submit the transfer on
|
||||
* @buf: DMA Buffer to submit
|
||||
*
|
||||
* This function must only be called from the buffer_finished callback for an
|
||||
* M2P channel. It is commonly used to add the next transfer in a chained list
|
||||
* of DMA transfers.
|
||||
*/
|
||||
void ep93xx_dma_m2p_submit_recursive(struct ep93xx_dma_m2p_client *m2p,
|
||||
struct ep93xx_dma_buffer *buf);
|
||||
|
||||
/**
|
||||
* ep93xx_dma_m2p_flush - Flush all pending transfers on a DMA M2P client
|
||||
*
|
||||
* @m2p: DMA client to flush transfers on
|
||||
*
|
||||
* Any transfers currently in progress will be completed in hardware, but
|
||||
* ignored in software.
|
||||
*
|
||||
*/
|
||||
void ep93xx_dma_m2p_flush(struct ep93xx_dma_m2p_client *m2p);
|
||||
|
||||
#endif /* __ASM_ARCH_DMA_H */
|
||||
|
|
|
@ -27,6 +27,8 @@
|
|||
|
||||
#define imx_has_dma_v1() (cpu_is_mx1() || cpu_is_mx21() || cpu_is_mx27())
|
||||
|
||||
#include <mach/dma.h>
|
||||
|
||||
#define IMX_DMA_CHANNELS 16
|
||||
|
||||
#define DMA_MODE_READ 0
|
||||
|
@ -96,12 +98,6 @@ int imx_dma_request(int channel, const char *name);
|
|||
|
||||
void imx_dma_free(int channel);
|
||||
|
||||
enum imx_dma_prio {
|
||||
DMA_PRIO_HIGH = 0,
|
||||
DMA_PRIO_MEDIUM = 1,
|
||||
DMA_PRIO_LOW = 2
|
||||
};
|
||||
|
||||
int imx_dma_request_by_prio(const char *name, enum imx_dma_prio prio);
|
||||
|
||||
#endif /* __MACH_DMA_V1_H__ */
|
||||
|
|
|
@ -23,16 +23,20 @@
|
|||
#include <linux/platform_device.h>
|
||||
#include <linux/gpio.h>
|
||||
#include <linux/input/matrix_keypad.h>
|
||||
#include <linux/irq.h>
|
||||
#include <asm/mach-types.h>
|
||||
#include <asm/mach/arch.h>
|
||||
#include <asm/mach/time.h>
|
||||
#include <mach/hardware.h>
|
||||
#include <mach/common.h>
|
||||
#include <mach/iomux-mx27.h>
|
||||
#include <mach/mmc.h>
|
||||
|
||||
#include "devices-imx27.h"
|
||||
#include "devices.h"
|
||||
|
||||
#define SD1_EN_GPIO (GPIO_PORTB + 25)
|
||||
|
||||
static const int mx27pdk_pins[] __initconst = {
|
||||
/* UART1 */
|
||||
PE12_PF_UART1_TXD,
|
||||
|
@ -58,6 +62,14 @@ static const int mx27pdk_pins[] __initconst = {
|
|||
PD15_AOUT_FEC_COL,
|
||||
PD16_AIN_FEC_TX_ER,
|
||||
PF23_AIN_FEC_TX_EN,
|
||||
/* SDHC1 */
|
||||
PE18_PF_SD1_D0,
|
||||
PE19_PF_SD1_D1,
|
||||
PE20_PF_SD1_D2,
|
||||
PE21_PF_SD1_D3,
|
||||
PE22_PF_SD1_CMD,
|
||||
PE23_PF_SD1_CLK,
|
||||
SD1_EN_GPIO | GPIO_GPIO | GPIO_OUT,
|
||||
};
|
||||
|
||||
static const struct imxuart_platform_data uart_pdata __initconst = {
|
||||
|
@ -85,13 +97,39 @@ static struct matrix_keymap_data mx27_3ds_keymap_data = {
|
|||
.keymap_size = ARRAY_SIZE(mx27_3ds_keymap),
|
||||
};
|
||||
|
||||
static int mx27_3ds_sdhc1_init(struct device *dev, irq_handler_t detect_irq,
|
||||
void *data)
|
||||
{
|
||||
return request_irq(IRQ_GPIOB(26), detect_irq, IRQF_TRIGGER_FALLING |
|
||||
IRQF_TRIGGER_RISING, "sdhc1-card-detect", data);
|
||||
}
|
||||
|
||||
static void mx27_3ds_sdhc1_exit(struct device *dev, void *data)
|
||||
{
|
||||
free_irq(IRQ_GPIOB(26), data);
|
||||
}
|
||||
|
||||
static struct imxmmc_platform_data sdhc1_pdata = {
|
||||
.init = mx27_3ds_sdhc1_init,
|
||||
.exit = mx27_3ds_sdhc1_exit,
|
||||
};
|
||||
|
||||
static void mx27_3ds_sdhc1_enable_level_translator(void)
|
||||
{
|
||||
/* Turn on TXB0108 OE pin */
|
||||
gpio_request(SD1_EN_GPIO, "sd1_enable");
|
||||
gpio_direction_output(SD1_EN_GPIO, 1);
|
||||
}
|
||||
|
||||
static void __init mx27pdk_init(void)
|
||||
{
|
||||
mxc_gpio_setup_multiple_pins(mx27pdk_pins, ARRAY_SIZE(mx27pdk_pins),
|
||||
"mx27pdk");
|
||||
mx27_3ds_sdhc1_enable_level_translator();
|
||||
imx27_add_imx_uart0(&uart_pdata);
|
||||
imx27_add_fec(NULL);
|
||||
mxc_register_device(&imx_kpp_device, &mx27_3ds_keymap_data);
|
||||
mxc_register_device(&mxc_sdhc_device0, &sdhc1_pdata);
|
||||
}
|
||||
|
||||
static void __init mx27pdk_timer_init(void)
|
||||
|
|
|
@ -197,7 +197,7 @@ unsigned long ixp2000_gettimeoffset (void)
|
|||
return offset / ticks_per_usec;
|
||||
}
|
||||
|
||||
static int ixp2000_timer_interrupt(int irq, void *dev_id)
|
||||
static irqreturn_t ixp2000_timer_interrupt(int irq, void *dev_id)
|
||||
{
|
||||
/* clear timer 1 */
|
||||
ixp2000_reg_wrb(IXP2000_T1_CLR, 1);
|
||||
|
|
|
@ -854,10 +854,9 @@ int __init kirkwood_find_tclk(void)
|
|||
|
||||
kirkwood_pcie_id(&dev, &rev);
|
||||
|
||||
if ((dev == MV88F6281_DEV_ID && (rev == MV88F6281_REV_A0 ||
|
||||
rev == MV88F6281_REV_A1)) ||
|
||||
(dev == MV88F6282_DEV_ID))
|
||||
return 200000000;
|
||||
if (dev == MV88F6281_DEV_ID || dev == MV88F6282_DEV_ID)
|
||||
if (((readl(SAMPLE_AT_RESET) >> 21) & 1) == 0)
|
||||
return 200000000;
|
||||
|
||||
return 166666667;
|
||||
}
|
||||
|
|
|
@ -225,5 +225,5 @@ MACHINE_START(D2NET_V2, "LaCie d2 Network v2")
|
|||
.init_machine = d2net_v2_init,
|
||||
.map_io = kirkwood_map_io,
|
||||
.init_irq = kirkwood_init_irq,
|
||||
.timer = &lacie_v2_timer,
|
||||
.timer = &kirkwood_timer,
|
||||
MACHINE_END
|
||||
|
|
|
@ -111,17 +111,3 @@ void __init lacie_v2_hdd_power_init(int hdd_num)
|
|||
pr_err("Failed to power up HDD%d\n", i + 1);
|
||||
}
|
||||
}
|
||||
|
||||
/*****************************************************************************
|
||||
* Timer
|
||||
****************************************************************************/
|
||||
|
||||
static void lacie_v2_timer_init(void)
|
||||
{
|
||||
kirkwood_tclk = 166666667;
|
||||
orion_time_init(IRQ_KIRKWOOD_BRIDGE, kirkwood_tclk);
|
||||
}
|
||||
|
||||
struct sys_timer lacie_v2_timer = {
|
||||
.init = lacie_v2_timer_init,
|
||||
};
|
||||
|
|
|
@ -13,6 +13,4 @@ void lacie_v2_register_flash(void);
|
|||
void lacie_v2_register_i2c_devices(void);
|
||||
void lacie_v2_hdd_power_init(int hdd_num);
|
||||
|
||||
extern struct sys_timer lacie_v2_timer;
|
||||
|
||||
#endif
|
||||
|
|
|
@ -59,7 +59,7 @@ void __init kirkwood_mpp_conf(unsigned int *mpp_list)
|
|||
}
|
||||
printk("\n");
|
||||
|
||||
while (*mpp_list) {
|
||||
for ( ; *mpp_list; mpp_list++) {
|
||||
unsigned int num = MPP_NUM(*mpp_list);
|
||||
unsigned int sel = MPP_SEL(*mpp_list);
|
||||
int shift, gpio_mode;
|
||||
|
@ -88,8 +88,6 @@ void __init kirkwood_mpp_conf(unsigned int *mpp_list)
|
|||
if (sel != 0)
|
||||
gpio_mode = 0;
|
||||
orion_gpio_set_valid(num, gpio_mode);
|
||||
|
||||
mpp_list++;
|
||||
}
|
||||
|
||||
printk(KERN_DEBUG " final MPP regs:");
|
||||
|
|
|
@ -262,7 +262,7 @@ MACHINE_START(NETSPACE_V2, "LaCie Network Space v2")
|
|||
.init_machine = netspace_v2_init,
|
||||
.map_io = kirkwood_map_io,
|
||||
.init_irq = kirkwood_init_irq,
|
||||
.timer = &lacie_v2_timer,
|
||||
.timer = &kirkwood_timer,
|
||||
MACHINE_END
|
||||
#endif
|
||||
|
||||
|
@ -272,7 +272,7 @@ MACHINE_START(INETSPACE_V2, "LaCie Internet Space v2")
|
|||
.init_machine = netspace_v2_init,
|
||||
.map_io = kirkwood_map_io,
|
||||
.init_irq = kirkwood_init_irq,
|
||||
.timer = &lacie_v2_timer,
|
||||
.timer = &kirkwood_timer,
|
||||
MACHINE_END
|
||||
#endif
|
||||
|
||||
|
@ -282,6 +282,6 @@ MACHINE_START(NETSPACE_MAX_V2, "LaCie Network Space Max v2")
|
|||
.init_machine = netspace_v2_init,
|
||||
.map_io = kirkwood_map_io,
|
||||
.init_irq = kirkwood_init_irq,
|
||||
.timer = &lacie_v2_timer,
|
||||
.timer = &kirkwood_timer,
|
||||
MACHINE_END
|
||||
#endif
|
||||
|
|
|
@ -403,7 +403,7 @@ MACHINE_START(NET2BIG_V2, "LaCie 2Big Network v2")
|
|||
.init_machine = netxbig_v2_init,
|
||||
.map_io = kirkwood_map_io,
|
||||
.init_irq = kirkwood_init_irq,
|
||||
.timer = &lacie_v2_timer,
|
||||
.timer = &kirkwood_timer,
|
||||
MACHINE_END
|
||||
#endif
|
||||
|
||||
|
@ -413,6 +413,6 @@ MACHINE_START(NET5BIG_V2, "LaCie 5Big Network v2")
|
|||
.init_machine = netxbig_v2_init,
|
||||
.map_io = kirkwood_map_io,
|
||||
.init_irq = kirkwood_init_irq,
|
||||
.timer = &lacie_v2_timer,
|
||||
.timer = &kirkwood_timer,
|
||||
MACHINE_END
|
||||
#endif
|
||||
|
|
|
@ -27,6 +27,10 @@
|
|||
#include "mpp.h"
|
||||
#include "tsx1x-common.h"
|
||||
|
||||
/* for the PCIe reset workaround */
|
||||
#include <plat/pcie.h>
|
||||
|
||||
|
||||
#define QNAP_TS41X_JUMPER_JP1 45
|
||||
|
||||
static struct i2c_board_info __initdata qnap_ts41x_i2c_rtc = {
|
||||
|
@ -140,8 +144,16 @@ static void __init qnap_ts41x_init(void)
|
|||
|
||||
static int __init ts41x_pci_init(void)
|
||||
{
|
||||
if (machine_is_ts41x())
|
||||
if (machine_is_ts41x()) {
|
||||
/*
|
||||
* Without this explicit reset, the PCIe SATA controller
|
||||
* (Marvell 88sx7042/sata_mv) is known to stop working
|
||||
* after a few minutes.
|
||||
*/
|
||||
orion_pcie_reset((void __iomem *)PCIE_VIRT_BASE);
|
||||
|
||||
kirkwood_pcie_init(KW_PCIE0);
|
||||
}
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
|
Некоторые файлы не были показаны из-за слишком большого количества измененных файлов Показать больше
Загрузка…
Ссылка в новой задаче