Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6 into sh-fixes-for-linus
This commit is contained in:
Paul Mundt
Коммит
8181d3ef26
|
|
@ -57,6 +57,7 @@ modules.builtin
|
|||
include/config
|
||||
include/linux/version.h
|
||||
include/generated
|
||||
arch/*/include/generated
|
||||
|
||||
# stgit generated dirs
|
||||
patches-*
|
||||
|
|
|
|||
1
.mailmap
1
.mailmap
|
|
@ -32,6 +32,7 @@ Brian Avery <b.avery@hp.com>
|
|||
Brian King <brking@us.ibm.com>
|
||||
Christoph Hellwig <hch@lst.de>
|
||||
Corey Minyard <minyard@acm.org>
|
||||
Damian Hobson-Garcia <dhobsong@igel.co.jp>
|
||||
David Brownell <david-b@pacbell.net>
|
||||
David Woodhouse <dwmw2@shinybook.infradead.org>
|
||||
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
|
||||
|
|
|
|||
8
CREDITS
8
CREDITS
|
|
@ -2943,6 +2943,10 @@ S: Kasarmikatu 11 A4
|
|||
S: 70110 Kuopio
|
||||
S: Finland
|
||||
|
||||
N: Tobias Ringström
|
||||
E: tori@unhappy.mine.nu
|
||||
D: Davicom DM9102(A)/DM9132/DM9801 fast ethernet driver
|
||||
|
||||
N: Luca Risolia
|
||||
E: luca.risolia@studio.unibo.it
|
||||
P: 1024D/FCE635A4 88E8 F32F 7244 68BA 3958 5D40 99DA 5D2A FCE6 35A4
|
||||
|
|
@ -3913,6 +3917,10 @@ S: Flandernstrasse 101
|
|||
S: D-73732 Esslingen
|
||||
S: Germany
|
||||
|
||||
N: Roman Zippel
|
||||
E: zippel@linux-m68k.org
|
||||
D: AFFS and HFS filesystems, m68k maintainer, new kernel configuration in 2.5
|
||||
|
||||
N: Leonard N. Zubkoff
|
||||
W: http://www.dandelion.com/Linux/
|
||||
D: BusLogic SCSI driver
|
||||
|
|
|
|||
|
|
@ -192,10 +192,6 @@ kernel-docs.txt
|
|||
- listing of various WWW + books that document kernel internals.
|
||||
kernel-parameters.txt
|
||||
- summary listing of command line / boot prompt args for the kernel.
|
||||
keys-request-key.txt
|
||||
- description of the kernel key request service.
|
||||
keys.txt
|
||||
- description of the kernel key retention service.
|
||||
kobject.txt
|
||||
- info of the kobject infrastructure of the Linux kernel.
|
||||
kprobes.txt
|
||||
|
|
@ -294,6 +290,8 @@ scheduler/
|
|||
- directory with info on the scheduler.
|
||||
scsi/
|
||||
- directory with info on Linux scsi support.
|
||||
security/
|
||||
- directory that contains security-related info
|
||||
serial/
|
||||
- directory with info on the low level serial API.
|
||||
serial-console.txt
|
||||
|
|
|
|||
|
|
@ -1,11 +1,10 @@
|
|||
What: /sys/o2cb symlink
|
||||
Date: Dec 2005
|
||||
KernelVersion: 2.6.16
|
||||
Date: May 2011
|
||||
KernelVersion: 2.6.40
|
||||
Contact: ocfs2-devel@oss.oracle.com
|
||||
Description: This is a symlink: /sys/o2cb to /sys/fs/o2cb. The symlink will
|
||||
be removed when new versions of ocfs2-tools which know to look
|
||||
Description: This is a symlink: /sys/o2cb to /sys/fs/o2cb. The symlink is
|
||||
removed when new versions of ocfs2-tools which know to look
|
||||
in /sys/fs/o2cb are sufficiently prevalent. Don't code new
|
||||
software to look here, it should try /sys/fs/o2cb instead.
|
||||
See Documentation/ABI/stable/o2cb for more information on usage.
|
||||
Users: ocfs2-tools. It's sufficient to mail proposed changes to
|
||||
ocfs2-devel@oss.oracle.com.
|
||||
|
|
@ -142,3 +142,67 @@ Description:
|
|||
with the previous I/O request are enabled. When set to 2,
|
||||
all merge tries are disabled. The default value is 0 -
|
||||
which enables all types of merge tries.
|
||||
|
||||
What: /sys/block/<disk>/discard_alignment
|
||||
Date: May 2011
|
||||
Contact: Martin K. Petersen <martin.petersen@oracle.com>
|
||||
Description:
|
||||
Devices that support discard functionality may
|
||||
internally allocate space in units that are bigger than
|
||||
the exported logical block size. The discard_alignment
|
||||
parameter indicates how many bytes the beginning of the
|
||||
device is offset from the internal allocation unit's
|
||||
natural alignment.
|
||||
|
||||
What: /sys/block/<disk>/<partition>/discard_alignment
|
||||
Date: May 2011
|
||||
Contact: Martin K. Petersen <martin.petersen@oracle.com>
|
||||
Description:
|
||||
Devices that support discard functionality may
|
||||
internally allocate space in units that are bigger than
|
||||
the exported logical block size. The discard_alignment
|
||||
parameter indicates how many bytes the beginning of the
|
||||
partition is offset from the internal allocation unit's
|
||||
natural alignment.
|
||||
|
||||
What: /sys/block/<disk>/queue/discard_granularity
|
||||
Date: May 2011
|
||||
Contact: Martin K. Petersen <martin.petersen@oracle.com>
|
||||
Description:
|
||||
Devices that support discard functionality may
|
||||
internally allocate space using units that are bigger
|
||||
than the logical block size. The discard_granularity
|
||||
parameter indicates the size of the internal allocation
|
||||
unit in bytes if reported by the device. Otherwise the
|
||||
discard_granularity will be set to match the device's
|
||||
physical block size. A discard_granularity of 0 means
|
||||
that the device does not support discard functionality.
|
||||
|
||||
What: /sys/block/<disk>/queue/discard_max_bytes
|
||||
Date: May 2011
|
||||
Contact: Martin K. Petersen <martin.petersen@oracle.com>
|
||||
Description:
|
||||
Devices that support discard functionality may have
|
||||
internal limits on the number of bytes that can be
|
||||
trimmed or unmapped in a single operation. Some storage
|
||||
protocols also have inherent limits on the number of
|
||||
blocks that can be described in a single command. The
|
||||
discard_max_bytes parameter is set by the device driver
|
||||
to the maximum number of bytes that can be discarded in
|
||||
a single operation. Discard requests issued to the
|
||||
device must not exceed this limit. A discard_max_bytes
|
||||
value of 0 means that the device does not support
|
||||
discard functionality.
|
||||
|
||||
What: /sys/block/<disk>/queue/discard_zeroes_data
|
||||
Date: May 2011
|
||||
Contact: Martin K. Petersen <martin.petersen@oracle.com>
|
||||
Description:
|
||||
Devices that support discard functionality may return
|
||||
stale or random data when a previously discarded block
|
||||
is read back. This can cause problems if the filesystem
|
||||
expects discarded blocks to be explicitly cleared. If a
|
||||
device reports that it deterministically returns zeroes
|
||||
when a discarded area is read the discard_zeroes_data
|
||||
parameter will be set to one. Otherwise it will be 0 and
|
||||
the result of reading a discarded area is undefined.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,11 @@
|
|||
What: /sys/kernel/mm/cleancache/
|
||||
Date: April 2011
|
||||
Contact: Dan Magenheimer <dan.magenheimer@oracle.com>
|
||||
Description:
|
||||
/sys/kernel/mm/cleancache/ contains a number of files which
|
||||
record a count of various cleancache operations
|
||||
(sum across all filesystems):
|
||||
succ_gets
|
||||
failed_gets
|
||||
puts
|
||||
flushes
|
||||
|
|
@ -0,0 +1,98 @@
|
|||
What: /sys/class/ptp/
|
||||
Date: September 2010
|
||||
Contact: Richard Cochran <richardcochran@gmail.com>
|
||||
Description:
|
||||
This directory contains files and directories
|
||||
providing a standardized interface to the ancillary
|
||||
features of PTP hardware clocks.
|
||||
|
||||
What: /sys/class/ptp/ptpN/
|
||||
Date: September 2010
|
||||
Contact: Richard Cochran <richardcochran@gmail.com>
|
||||
Description:
|
||||
This directory contains the attributes of the Nth PTP
|
||||
hardware clock registered into the PTP class driver
|
||||
subsystem.
|
||||
|
||||
What: /sys/class/ptp/ptpN/clock_name
|
||||
Date: September 2010
|
||||
Contact: Richard Cochran <richardcochran@gmail.com>
|
||||
Description:
|
||||
This file contains the name of the PTP hardware clock
|
||||
as a human readable string.
|
||||
|
||||
What: /sys/class/ptp/ptpN/max_adjustment
|
||||
Date: September 2010
|
||||
Contact: Richard Cochran <richardcochran@gmail.com>
|
||||
Description:
|
||||
This file contains the PTP hardware clock's maximum
|
||||
frequency adjustment value (a positive integer) in
|
||||
parts per billion.
|
||||
|
||||
What: /sys/class/ptp/ptpN/n_alarms
|
||||
Date: September 2010
|
||||
Contact: Richard Cochran <richardcochran@gmail.com>
|
||||
Description:
|
||||
This file contains the number of periodic or one shot
|
||||
alarms offer by the PTP hardware clock.
|
||||
|
||||
What: /sys/class/ptp/ptpN/n_external_timestamps
|
||||
Date: September 2010
|
||||
Contact: Richard Cochran <richardcochran@gmail.com>
|
||||
Description:
|
||||
This file contains the number of external timestamp
|
||||
channels offered by the PTP hardware clock.
|
||||
|
||||
What: /sys/class/ptp/ptpN/n_periodic_outputs
|
||||
Date: September 2010
|
||||
Contact: Richard Cochran <richardcochran@gmail.com>
|
||||
Description:
|
||||
This file contains the number of programmable periodic
|
||||
output channels offered by the PTP hardware clock.
|
||||
|
||||
What: /sys/class/ptp/ptpN/pps_avaiable
|
||||
Date: September 2010
|
||||
Contact: Richard Cochran <richardcochran@gmail.com>
|
||||
Description:
|
||||
This file indicates whether the PTP hardware clock
|
||||
supports a Pulse Per Second to the host CPU. Reading
|
||||
"1" means that the PPS is supported, while "0" means
|
||||
not supported.
|
||||
|
||||
What: /sys/class/ptp/ptpN/extts_enable
|
||||
Date: September 2010
|
||||
Contact: Richard Cochran <richardcochran@gmail.com>
|
||||
Description:
|
||||
This write-only file enables or disables external
|
||||
timestamps. To enable external timestamps, write the
|
||||
channel index followed by a "1" into the file.
|
||||
To disable external timestamps, write the channel
|
||||
index followed by a "0" into the file.
|
||||
|
||||
What: /sys/class/ptp/ptpN/fifo
|
||||
Date: September 2010
|
||||
Contact: Richard Cochran <richardcochran@gmail.com>
|
||||
Description:
|
||||
This file provides timestamps on external events, in
|
||||
the form of three integers: channel index, seconds,
|
||||
and nanoseconds.
|
||||
|
||||
What: /sys/class/ptp/ptpN/period
|
||||
Date: September 2010
|
||||
Contact: Richard Cochran <richardcochran@gmail.com>
|
||||
Description:
|
||||
This write-only file enables or disables periodic
|
||||
outputs. To enable a periodic output, write five
|
||||
integers into the file: channel index, start time
|
||||
seconds, start time nanoseconds, period seconds, and
|
||||
period nanoseconds. To disable a periodic output, set
|
||||
all the seconds and nanoseconds values to zero.
|
||||
|
||||
What: /sys/class/ptp/ptpN/pps_enable
|
||||
Date: September 2010
|
||||
Contact: Richard Cochran <richardcochran@gmail.com>
|
||||
Description:
|
||||
This write-only file enables or disables delivery of
|
||||
PPS events to the Linux PPS subsystem. To enable PPS
|
||||
events, write a "1" into the file. To disable events,
|
||||
write a "0" into the file.
|
||||
|
|
@ -73,7 +73,7 @@ installmandocs: mandocs
|
|||
###
|
||||
#External programs used
|
||||
KERNELDOC = $(srctree)/scripts/kernel-doc
|
||||
DOCPROC = $(objtree)/scripts/basic/docproc
|
||||
DOCPROC = $(objtree)/scripts/docproc
|
||||
|
||||
XMLTOFLAGS = -m $(srctree)/Documentation/DocBook/stylesheet.xsl
|
||||
XMLTOFLAGS += --skip-validation
|
||||
|
|
|
|||
|
|
@ -141,13 +141,15 @@ struct dtv_properties {
|
|||
</row></tbody></tgroup></informaltable>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Property types</title>
|
||||
<para>
|
||||
On <link linkend="FE_GET_PROPERTY">FE_GET_PROPERTY</link>/<link linkend="FE_SET_PROPERTY">FE_SET_PROPERTY</link>,
|
||||
the actual action is determined by the dtv_property cmd/data pairs. With one single ioctl, is possible to
|
||||
get/set up to 64 properties. The actual meaning of each property is described on the next sections.
|
||||
</para>
|
||||
|
||||
<para>The Available frontend property types are:</para>
|
||||
<para>The available frontend property types are:</para>
|
||||
<programlisting>
|
||||
#define DTV_UNDEFINED 0
|
||||
#define DTV_TUNE 1
|
||||
|
|
@ -193,6 +195,7 @@ get/set up to 64 properties. The actual meaning of each property is described on
|
|||
#define DTV_ISDBT_LAYER_ENABLED 41
|
||||
#define DTV_ISDBS_TS_ID 42
|
||||
</programlisting>
|
||||
</section>
|
||||
|
||||
<section id="fe_property_common">
|
||||
<title>Parameters that are common to all Digital TV standards</title>
|
||||
|
|
|
|||
|
|
@ -293,6 +293,7 @@
|
|||
<!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-srggb12 SYSTEM "v4l/pixfmt-srggb12.xml">
|
||||
<!ENTITY sub-srggb8 SYSTEM "v4l/pixfmt-srggb8.xml">
|
||||
<!ENTITY sub-y10 SYSTEM "v4l/pixfmt-y10.xml">
|
||||
<!ENTITY sub-y12 SYSTEM "v4l/pixfmt-y12.xml">
|
||||
|
|
@ -373,9 +374,9 @@
|
|||
<!ENTITY sub-media-indices SYSTEM "media-indices.tmpl">
|
||||
|
||||
<!ENTITY sub-media-controller SYSTEM "v4l/media-controller.xml">
|
||||
<!ENTITY sub-media-open SYSTEM "v4l/media-func-open.xml">
|
||||
<!ENTITY sub-media-close SYSTEM "v4l/media-func-close.xml">
|
||||
<!ENTITY sub-media-ioctl SYSTEM "v4l/media-func-ioctl.xml">
|
||||
<!ENTITY sub-media-func-open SYSTEM "v4l/media-func-open.xml">
|
||||
<!ENTITY sub-media-func-close SYSTEM "v4l/media-func-close.xml">
|
||||
<!ENTITY sub-media-func-ioctl SYSTEM "v4l/media-func-ioctl.xml">
|
||||
<!ENTITY sub-media-ioc-device-info SYSTEM "v4l/media-ioc-device-info.xml">
|
||||
<!ENTITY sub-media-ioc-enum-entities SYSTEM "v4l/media-ioc-enum-entities.xml">
|
||||
<!ENTITY sub-media-ioc-enum-links SYSTEM "v4l/media-ioc-enum-links.xml">
|
||||
|
|
|
|||
|
|
@ -189,8 +189,7 @@ static void __iomem *baseaddr;
|
|||
<title>Partition defines</title>
|
||||
<para>
|
||||
If you want to divide your device into partitions, then
|
||||
enable the configuration switch CONFIG_MTD_PARTITIONS and define
|
||||
a partitioning scheme suitable to your board.
|
||||
define a partitioning scheme suitable to your board.
|
||||
</para>
|
||||
<programlisting>
|
||||
#define NUM_PARTITIONS 2
|
||||
|
|
|
|||
|
|
@ -78,9 +78,9 @@
|
|||
<appendix id="media-user-func">
|
||||
<title>Function Reference</title>
|
||||
<!-- Keep this alphabetically sorted. -->
|
||||
&sub-media-open;
|
||||
&sub-media-close;
|
||||
&sub-media-ioctl;
|
||||
&sub-media-func-open;
|
||||
&sub-media-func-close;
|
||||
&sub-media-func-ioctl;
|
||||
<!-- All ioctls go here. -->
|
||||
&sub-media-ioc-device-info;
|
||||
&sub-media-ioc-enum-entities;
|
||||
|
|
|
|||
|
|
@ -673,6 +673,7 @@ access the palette, this must be done with ioctls of the Linux framebuffer API.<
|
|||
&sub-srggb8;
|
||||
&sub-sbggr16;
|
||||
&sub-srggb10;
|
||||
&sub-srggb12;
|
||||
</section>
|
||||
|
||||
<section id="yuv-formats">
|
||||
|
|
|
|||
|
|
@ -2531,13 +2531,13 @@
|
|||
<constant>_JPEG</constant> prefix the format code is made of
|
||||
the following information.
|
||||
<itemizedlist>
|
||||
<listitem>The number of bus samples per entropy encoded byte.</listitem>
|
||||
<listitem>The bus width.</listitem>
|
||||
<listitem><para>The number of bus samples per entropy encoded byte.</para></listitem>
|
||||
<listitem><para>The bus width.</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
<para>For instance, for a JPEG baseline process and an 8-bit bus width
|
||||
the format will be named <constant>V4L2_MBUS_FMT_JPEG_1X8</constant>.
|
||||
</para>
|
||||
<para>For instance, for a JPEG baseline process and an 8-bit bus width
|
||||
the format will be named <constant>V4L2_MBUS_FMT_JPEG_1X8</constant>.
|
||||
</para>
|
||||
|
||||
<para>The following table lists existing JPEG compressed formats.</para>
|
||||
|
|
|
|||
|
|
@ -4,10 +4,11 @@ ChangeLog:
|
|||
|
||||
SMP IRQ affinity
|
||||
|
||||
/proc/irq/IRQ#/smp_affinity specifies which target CPUs are permitted
|
||||
for a given IRQ source. It's a bitmask of allowed CPUs. It's not allowed
|
||||
to turn off all CPUs, and if an IRQ controller does not support IRQ
|
||||
affinity then the value will not change from the default 0xffffffff.
|
||||
/proc/irq/IRQ#/smp_affinity and /proc/irq/IRQ#/smp_affinity_list specify
|
||||
which target CPUs are permitted for a given IRQ source. It's a bitmask
|
||||
(smp_affinity) or cpu list (smp_affinity_list) of allowed CPUs. It's not
|
||||
allowed to turn off all CPUs, and if an IRQ controller does not support
|
||||
IRQ affinity then the value will not change from the default of all cpus.
|
||||
|
||||
/proc/irq/default_smp_affinity specifies default affinity mask that applies
|
||||
to all non-active IRQs. Once IRQ is allocated/activated its affinity bitmask
|
||||
|
|
@ -54,3 +55,11 @@ round-trip min/avg/max = 0.1/0.5/585.4 ms
|
|||
This time around IRQ44 was delivered only to the last four processors.
|
||||
i.e counters for the CPU0-3 did not change.
|
||||
|
||||
Here is an example of limiting that same irq (44) to cpus 1024 to 1031:
|
||||
|
||||
[root@moon 44]# echo 1024-1031 > smp_affinity
|
||||
[root@moon 44]# cat smp_affinity
|
||||
1024-1031
|
||||
|
||||
Note that to do this with a bitmask would require 32 bitmasks of zero
|
||||
to follow the pertinent one.
|
||||
|
|
|
|||
|
|
@ -99,18 +99,11 @@ o "qp" indicates that RCU still expects a quiescent state from
|
|||
|
||||
o "dt" is the current value of the dyntick counter that is incremented
|
||||
when entering or leaving dynticks idle state, either by the
|
||||
scheduler or by irq. The number after the "/" is the interrupt
|
||||
nesting depth when in dyntick-idle state, or one greater than
|
||||
the interrupt-nesting depth otherwise.
|
||||
|
||||
This field is displayed only for CONFIG_NO_HZ kernels.
|
||||
|
||||
o "dn" is the current value of the dyntick counter that is incremented
|
||||
when entering or leaving dynticks idle state via NMI. If both
|
||||
the "dt" and "dn" values are even, then this CPU is in dynticks
|
||||
idle mode and may be ignored by RCU. If either of these two
|
||||
counters is odd, then RCU must be alert to the possibility of
|
||||
an RCU read-side critical section running on this CPU.
|
||||
scheduler or by irq. This number is even if the CPU is in
|
||||
dyntick idle mode and odd otherwise. The number after the first
|
||||
"/" is the interrupt nesting depth when in dyntick-idle state,
|
||||
or one greater than the interrupt-nesting depth otherwise.
|
||||
The number after the second "/" is the NMI nesting depth.
|
||||
|
||||
This field is displayed only for CONFIG_NO_HZ kernels.
|
||||
|
||||
|
|
|
|||
|
|
@ -177,6 +177,8 @@ static int get_family_id(int sd)
|
|||
rc = send_cmd(sd, GENL_ID_CTRL, getpid(), CTRL_CMD_GETFAMILY,
|
||||
CTRL_ATTR_FAMILY_NAME, (void *)name,
|
||||
strlen(TASKSTATS_GENL_NAME)+1);
|
||||
if (rc < 0)
|
||||
return 0; /* sendto() failure? */
|
||||
|
||||
rep_len = recv(sd, &ans, sizeof(ans), 0);
|
||||
if (ans.n.nlmsg_type == NLMSG_ERROR ||
|
||||
|
|
@ -191,30 +193,37 @@ static int get_family_id(int sd)
|
|||
return id;
|
||||
}
|
||||
|
||||
#define average_ms(t, c) (t / 1000000ULL / (c ? c : 1))
|
||||
|
||||
static void print_delayacct(struct taskstats *t)
|
||||
{
|
||||
printf("\n\nCPU %15s%15s%15s%15s\n"
|
||||
" %15llu%15llu%15llu%15llu\n"
|
||||
"IO %15s%15s\n"
|
||||
" %15llu%15llu\n"
|
||||
"SWAP %15s%15s\n"
|
||||
" %15llu%15llu\n"
|
||||
"RECLAIM %12s%15s\n"
|
||||
" %15llu%15llu\n",
|
||||
"count", "real total", "virtual total", "delay total",
|
||||
printf("\n\nCPU %15s%15s%15s%15s%15s\n"
|
||||
" %15llu%15llu%15llu%15llu%15.3fms\n"
|
||||
"IO %15s%15s%15s\n"
|
||||
" %15llu%15llu%15llums\n"
|
||||
"SWAP %15s%15s%15s\n"
|
||||
" %15llu%15llu%15llums\n"
|
||||
"RECLAIM %12s%15s%15s\n"
|
||||
" %15llu%15llu%15llums\n",
|
||||
"count", "real total", "virtual total",
|
||||
"delay total", "delay average",
|
||||
(unsigned long long)t->cpu_count,
|
||||
(unsigned long long)t->cpu_run_real_total,
|
||||
(unsigned long long)t->cpu_run_virtual_total,
|
||||
(unsigned long long)t->cpu_delay_total,
|
||||
"count", "delay total",
|
||||
average_ms((double)t->cpu_delay_total, t->cpu_count),
|
||||
"count", "delay total", "delay average",
|
||||
(unsigned long long)t->blkio_count,
|
||||
(unsigned long long)t->blkio_delay_total,
|
||||
"count", "delay total",
|
||||
average_ms(t->blkio_delay_total, t->blkio_count),
|
||||
"count", "delay total", "delay average",
|
||||
(unsigned long long)t->swapin_count,
|
||||
(unsigned long long)t->swapin_delay_total,
|
||||
"count", "delay total",
|
||||
average_ms(t->swapin_delay_total, t->swapin_count),
|
||||
"count", "delay total", "delay average",
|
||||
(unsigned long long)t->freepages_count,
|
||||
(unsigned long long)t->freepages_delay_total);
|
||||
(unsigned long long)t->freepages_delay_total,
|
||||
average_ms(t->freepages_delay_total, t->freepages_count));
|
||||
}
|
||||
|
||||
static void task_context_switch_counts(struct taskstats *t)
|
||||
|
|
@ -433,8 +442,6 @@ int main(int argc, char *argv[])
|
|||
}
|
||||
|
||||
do {
|
||||
int i;
|
||||
|
||||
rep_len = recv(nl_sd, &msg, sizeof(msg), 0);
|
||||
PRINTF("received %d bytes\n", rep_len);
|
||||
|
||||
|
|
@ -459,7 +466,6 @@ int main(int argc, char *argv[])
|
|||
|
||||
na = (struct nlattr *) GENLMSG_DATA(&msg);
|
||||
len = 0;
|
||||
i = 0;
|
||||
while (len < rep_len) {
|
||||
len += NLA_ALIGN(na->nla_len);
|
||||
switch (na->nla_type) {
|
||||
|
|
|
|||
|
|
@ -66,3 +66,8 @@ Note: We can use a kernel with multiple custom ACPI method running,
|
|||
But each individual write to debugfs can implement a SINGLE
|
||||
method override. i.e. if we want to insert/override multiple
|
||||
ACPI methods, we need to redo step c) ~ g) for multiple times.
|
||||
|
||||
Note: Be aware that root can mis-use this driver to modify arbitrary
|
||||
memory and gain additional rights, if root's privileges got
|
||||
restricted (for example if root is not allowed to load additional
|
||||
modules after boot).
|
||||
|
|
|
|||
|
|
@ -65,13 +65,19 @@ looks at the connected hardware is beyond the scope of this document.
|
|||
The boot loader must ultimately be able to provide a MACH_TYPE_xxx
|
||||
value to the kernel. (see linux/arch/arm/tools/mach-types).
|
||||
|
||||
|
||||
4. Setup the kernel tagged list
|
||||
-------------------------------
|
||||
4. Setup boot data
|
||||
------------------
|
||||
|
||||
Existing boot loaders: OPTIONAL, HIGHLY RECOMMENDED
|
||||
New boot loaders: MANDATORY
|
||||
|
||||
The boot loader must provide either a tagged list or a dtb image for
|
||||
passing configuration data to the kernel. The physical address of the
|
||||
boot data is passed to the kernel in register r2.
|
||||
|
||||
4a. Setup the kernel tagged list
|
||||
--------------------------------
|
||||
|
||||
The boot loader must create and initialise the kernel tagged list.
|
||||
A valid tagged list starts with ATAG_CORE and ends with ATAG_NONE.
|
||||
The ATAG_CORE tag may or may not be empty. An empty ATAG_CORE tag
|
||||
|
|
@ -101,6 +107,24 @@ The tagged list must be placed in a region of memory where neither
|
|||
the kernel decompressor nor initrd 'bootp' program will overwrite
|
||||
it. The recommended placement is in the first 16KiB of RAM.
|
||||
|
||||
4b. Setup the device tree
|
||||
-------------------------
|
||||
|
||||
The boot loader must load a device tree image (dtb) into system ram
|
||||
at a 64bit aligned address and initialize it with the boot data. The
|
||||
dtb format is documented in Documentation/devicetree/booting-without-of.txt.
|
||||
The kernel will look for the dtb magic value of 0xd00dfeed at the dtb
|
||||
physical address to determine if a dtb has been passed instead of a
|
||||
tagged list.
|
||||
|
||||
The boot loader must pass at a minimum the size and location of the
|
||||
system memory, and the root filesystem location. The dtb must be
|
||||
placed in a region of memory where the kernel decompressor will not
|
||||
overwrite it. The recommended placement is in the first 16KiB of RAM
|
||||
with the caveat that it may not be located at physical address 0 since
|
||||
the kernel interprets a value of 0 in r2 to mean neither a tagged list
|
||||
nor a dtb were passed.
|
||||
|
||||
5. Calling the kernel image
|
||||
---------------------------
|
||||
|
||||
|
|
@ -125,7 +149,8 @@ In either case, the following conditions must be met:
|
|||
- CPU register settings
|
||||
r0 = 0,
|
||||
r1 = machine type number discovered in (3) above.
|
||||
r2 = physical address of tagged list in system RAM.
|
||||
r2 = physical address of tagged list in system RAM, or
|
||||
physical address of device tree block (dtb) in system RAM
|
||||
|
||||
- CPU mode
|
||||
All forms of interrupts must be disabled (IRQs and FIQs)
|
||||
|
|
|
|||
|
|
@ -14,7 +14,6 @@ Introduction
|
|||
- S3C24XX: See Documentation/arm/Samsung-S3C24XX/Overview.txt for full list
|
||||
- S3C64XX: S3C6400 and S3C6410
|
||||
- S5P6440
|
||||
- S5P6442
|
||||
- S5PC100
|
||||
- S5PC110 / S5PV210
|
||||
|
||||
|
|
@ -36,7 +35,6 @@ Configuration
|
|||
unifying all the SoCs into one kernel.
|
||||
|
||||
s5p6440_defconfig - S5P6440 specific default configuration
|
||||
s5p6442_defconfig - S5P6442 specific default configuration
|
||||
s5pc100_defconfig - S5PC100 specific default configuration
|
||||
s5pc110_defconfig - S5PC110 specific default configuration
|
||||
s5pv210_defconfig - S5PV210 specific default configuration
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ Also, it should be made opaque such that any kind of cast to a normal
|
|||
C integer type will fail. Something like the following should
|
||||
suffice:
|
||||
|
||||
typedef struct { volatile int counter; } atomic_t;
|
||||
typedef struct { int counter; } atomic_t;
|
||||
|
||||
Historically, counter has been declared volatile. This is now discouraged.
|
||||
See Documentation/volatile-considered-harmful.txt for the complete rationale.
|
||||
|
|
|
|||
|
|
@ -169,3 +169,18 @@ is issued which positions the tape to a known position. Typically you
|
|||
must rewind the tape (by issuing "mt -f /dev/st0 rewind" for example)
|
||||
before i/o can proceed again to a tape drive which was reset.
|
||||
|
||||
There is a cciss_tape_cmds module parameter which can be used to make cciss
|
||||
allocate more commands for use by tape drives. Ordinarily only a few commands
|
||||
(6) are allocated for tape drives because tape drives are slow and
|
||||
infrequently used and the primary purpose of Smart Array controllers is to
|
||||
act as a RAID controller for disk drives, so the vast majority of commands
|
||||
are allocated for disk devices. However, if you have more than a few tape
|
||||
drives attached to a smart array, the default number of commands may not be
|
||||
enought (for example, if you have 8 tape drives, you could only rewind 6
|
||||
at one time with the default number of commands.) The cciss_tape_cmds module
|
||||
parameter allows more commands (up to 16 more) to be allocated for use by
|
||||
tape drives. For example:
|
||||
|
||||
insmod cciss.ko cciss_tape_cmds=16
|
||||
|
||||
Or, as a kernel boot parameter passed in via grub: cciss.cciss_tape_cmds=8
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ on all processors in the system. Don't let this scare you into
|
|||
thinking SMP cache/tlb flushing must be so inefficient, this is in
|
||||
fact an area where many optimizations are possible. For example,
|
||||
if it can be proven that a user address space has never executed
|
||||
on a cpu (see vma->cpu_vm_mask), one need not perform a flush
|
||||
on a cpu (see mm_cpumask()), one need not perform a flush
|
||||
for this address space on that cpu.
|
||||
|
||||
First, the TLB flushing interfaces, since they are the simplest. The
|
||||
|
|
|
|||
|
|
@ -236,7 +236,8 @@ containing the following files describing that cgroup:
|
|||
- cgroup.procs: list of tgids in the cgroup. This list is not
|
||||
guaranteed to be sorted or free of duplicate tgids, and userspace
|
||||
should sort/uniquify the list if this property is required.
|
||||
This is a read-only file, for now.
|
||||
Writing a thread group id into this file moves all threads in that
|
||||
group into this cgroup.
|
||||
- notify_on_release flag: run the release agent on exit?
|
||||
- release_agent: the path to use for release notifications (this file
|
||||
exists in the top cgroup only)
|
||||
|
|
@ -430,6 +431,12 @@ You can attach the current shell task by echoing 0:
|
|||
|
||||
# echo 0 > tasks
|
||||
|
||||
You can use the cgroup.procs file instead of the tasks file to move all
|
||||
threads in a threadgroup at once. Echoing the pid of any task in a
|
||||
threadgroup to cgroup.procs causes all tasks in that threadgroup to be
|
||||
be attached to the cgroup. Writing 0 to cgroup.procs moves all tasks
|
||||
in the writing task's threadgroup.
|
||||
|
||||
Note: Since every task is always a member of exactly one cgroup in each
|
||||
mounted hierarchy, to remove a task from its current cgroup you must
|
||||
move it into a new cgroup (possibly the root cgroup) by writing to the
|
||||
|
|
@ -575,7 +582,7 @@ rmdir() will fail with it. From this behavior, pre_destroy() can be
|
|||
called multiple times against a cgroup.
|
||||
|
||||
int can_attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
|
||||
struct task_struct *task, bool threadgroup)
|
||||
struct task_struct *task)
|
||||
(cgroup_mutex held by caller)
|
||||
|
||||
Called prior to moving a task into a cgroup; if the subsystem
|
||||
|
|
@ -584,9 +591,14 @@ task is passed, then a successful result indicates that *any*
|
|||
unspecified task can be moved into the cgroup. Note that this isn't
|
||||
called on a fork. If this method returns 0 (success) then this should
|
||||
remain valid while the caller holds cgroup_mutex and it is ensured that either
|
||||
attach() or cancel_attach() will be called in future. If threadgroup is
|
||||
true, then a successful result indicates that all threads in the given
|
||||
thread's threadgroup can be moved together.
|
||||
attach() or cancel_attach() will be called in future.
|
||||
|
||||
int can_attach_task(struct cgroup *cgrp, struct task_struct *tsk);
|
||||
(cgroup_mutex held by caller)
|
||||
|
||||
As can_attach, but for operations that must be run once per task to be
|
||||
attached (possibly many when using cgroup_attach_proc). Called after
|
||||
can_attach.
|
||||
|
||||
void cancel_attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
|
||||
struct task_struct *task, bool threadgroup)
|
||||
|
|
@ -598,15 +610,24 @@ function, so that the subsystem can implement a rollback. If not, not necessary.
|
|||
This will be called only about subsystems whose can_attach() operation have
|
||||
succeeded.
|
||||
|
||||
void pre_attach(struct cgroup *cgrp);
|
||||
(cgroup_mutex held by caller)
|
||||
|
||||
For any non-per-thread attachment work that needs to happen before
|
||||
attach_task. Needed by cpuset.
|
||||
|
||||
void attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
|
||||
struct cgroup *old_cgrp, struct task_struct *task,
|
||||
bool threadgroup)
|
||||
struct cgroup *old_cgrp, struct task_struct *task)
|
||||
(cgroup_mutex held by caller)
|
||||
|
||||
Called after the task has been attached to the cgroup, to allow any
|
||||
post-attachment activity that requires memory allocations or blocking.
|
||||
If threadgroup is true, the subsystem should take care of all threads
|
||||
in the specified thread's threadgroup. Currently does not support any
|
||||
|
||||
void attach_task(struct cgroup *cgrp, struct task_struct *tsk);
|
||||
(cgroup_mutex held by caller)
|
||||
|
||||
As attach, but for operations that must be run once per task to be attached,
|
||||
like can_attach_task. Called before attach. Currently does not support any
|
||||
subsystem that might need the old_cgrp for every thread in the group.
|
||||
|
||||
void fork(struct cgroup_subsy *ss, struct task_struct *task)
|
||||
|
|
@ -630,7 +651,7 @@ always handled well.
|
|||
void post_clone(struct cgroup_subsys *ss, struct cgroup *cgrp)
|
||||
(cgroup_mutex held by caller)
|
||||
|
||||
Called at the end of cgroup_clone() to do any parameter
|
||||
Called during cgroup_create() to do any parameter
|
||||
initialization which might be required before a task could attach. For
|
||||
example in cpusets, no task may attach before 'cpus' and 'mems' are set
|
||||
up.
|
||||
|
|
|
|||
|
|
@ -74,3 +74,57 @@ Example:
|
|||
interrupt-parent = <&mpic>;
|
||||
phy-handle = <&phy0>
|
||||
};
|
||||
|
||||
* Gianfar PTP clock nodes
|
||||
|
||||
General Properties:
|
||||
|
||||
- compatible Should be "fsl,etsec-ptp"
|
||||
- reg Offset and length of the register set for the device
|
||||
- interrupts There should be at least two interrupts. Some devices
|
||||
have as many as four PTP related interrupts.
|
||||
|
||||
Clock Properties:
|
||||
|
||||
- fsl,tclk-period Timer reference clock period in nanoseconds.
|
||||
- fsl,tmr-prsc Prescaler, divides the output clock.
|
||||
- fsl,tmr-add Frequency compensation value.
|
||||
- fsl,tmr-fiper1 Fixed interval period pulse generator.
|
||||
- fsl,tmr-fiper2 Fixed interval period pulse generator.
|
||||
- fsl,max-adj Maximum frequency adjustment in parts per billion.
|
||||
|
||||
These properties set the operational parameters for the PTP
|
||||
clock. You must choose these carefully for the clock to work right.
|
||||
Here is how to figure good values:
|
||||
|
||||
TimerOsc = system clock MHz
|
||||
tclk_period = desired clock period nanoseconds
|
||||
NominalFreq = 1000 / tclk_period MHz
|
||||
FreqDivRatio = TimerOsc / NominalFreq (must be greater that 1.0)
|
||||
tmr_add = ceil(2^32 / FreqDivRatio)
|
||||
OutputClock = NominalFreq / tmr_prsc MHz
|
||||
PulseWidth = 1 / OutputClock microseconds
|
||||
FiperFreq1 = desired frequency in Hz
|
||||
FiperDiv1 = 1000000 * OutputClock / FiperFreq1
|
||||
tmr_fiper1 = tmr_prsc * tclk_period * FiperDiv1 - tclk_period
|
||||
max_adj = 1000000000 * (FreqDivRatio - 1.0) - 1
|
||||
|
||||
The calculation for tmr_fiper2 is the same as for tmr_fiper1. The
|
||||
driver expects that tmr_fiper1 will be correctly set to produce a 1
|
||||
Pulse Per Second (PPS) signal, since this will be offered to the PPS
|
||||
subsystem to synchronize the Linux clock.
|
||||
|
||||
Example:
|
||||
|
||||
ptp_clock@24E00 {
|
||||
compatible = "fsl,etsec-ptp";
|
||||
reg = <0x24E00 0xB0>;
|
||||
interrupts = <12 0x8 13 0x8>;
|
||||
interrupt-parent = < &ipic >;
|
||||
fsl,tclk-period = <10>;
|
||||
fsl,tmr-prsc = <100>;
|
||||
fsl,tmr-add = <0x999999A4>;
|
||||
fsl,tmr-fiper1 = <0x3B9AC9F6>;
|
||||
fsl,tmr-fiper2 = <0x00018696>;
|
||||
fsl,max-adj = <659999998>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -12,8 +12,9 @@ Table of Contents
|
|||
=================
|
||||
|
||||
I - Introduction
|
||||
1) Entry point for arch/powerpc
|
||||
2) Entry point for arch/x86
|
||||
1) Entry point for arch/arm
|
||||
2) Entry point for arch/powerpc
|
||||
3) Entry point for arch/x86
|
||||
|
||||
II - The DT block format
|
||||
1) Header
|
||||
|
|
@ -148,7 +149,46 @@ upgrades without significantly impacting the kernel code or cluttering
|
|||
it with special cases.
|
||||
|
||||
|
||||
1) Entry point for arch/powerpc
|
||||
1) Entry point for arch/arm
|
||||
---------------------------
|
||||
|
||||
There is one single entry point to the kernel, at the start
|
||||
of the kernel image. That entry point supports two calling
|
||||
conventions. A summary of the interface is described here. A full
|
||||
description of the boot requirements is documented in
|
||||
Documentation/arm/Booting
|
||||
|
||||
a) ATAGS interface. Minimal information is passed from firmware
|
||||
to the kernel with a tagged list of predefined parameters.
|
||||
|
||||
r0 : 0
|
||||
|
||||
r1 : Machine type number
|
||||
|
||||
r2 : Physical address of tagged list in system RAM
|
||||
|
||||
b) Entry with a flattened device-tree block. Firmware loads the
|
||||
physical address of the flattened device tree block (dtb) into r2,
|
||||
r1 is not used, but it is considered good practise to use a valid
|
||||
machine number as described in Documentation/arm/Booting.
|
||||
|
||||
r0 : 0
|
||||
|
||||
r1 : Valid machine type number. When using a device tree,
|
||||
a single machine type number will often be assigned to
|
||||
represent a class or family of SoCs.
|
||||
|
||||
r2 : physical pointer to the device-tree block
|
||||
(defined in chapter II) in RAM. Device tree can be located
|
||||
anywhere in system RAM, but it should be aligned on a 64 bit
|
||||
boundary.
|
||||
|
||||
The kernel will differentiate between ATAGS and device tree booting by
|
||||
reading the memory pointed to by r2 and looking for either the flattened
|
||||
device tree block magic value (0xd00dfeed) or the ATAG_CORE value at
|
||||
offset 0x4 from r2 (0x54410001).
|
||||
|
||||
2) Entry point for arch/powerpc
|
||||
-------------------------------
|
||||
|
||||
There is one single entry point to the kernel, at the start
|
||||
|
|
@ -226,7 +266,7 @@ it with special cases.
|
|||
cannot support both configurations with Book E and configurations
|
||||
with classic Powerpc architectures.
|
||||
|
||||
2) Entry point for arch/x86
|
||||
3) Entry point for arch/x86
|
||||
-------------------------------
|
||||
|
||||
There is one single 32bit entry point to the kernel at code32_start,
|
||||
|
|
|
|||
|
|
@ -1 +1,96 @@
|
|||
See Documentation/crypto/async-tx-api.txt
|
||||
DMA Engine API Guide
|
||||
====================
|
||||
|
||||
Vinod Koul <vinod dot koul at intel.com>
|
||||
|
||||
NOTE: For DMA Engine usage in async_tx please see:
|
||||
Documentation/crypto/async-tx-api.txt
|
||||
|
||||
|
||||
Below is a guide to device driver writers on how to use the Slave-DMA API of the
|
||||
DMA Engine. This is applicable only for slave DMA usage only.
|
||||
|
||||
The slave DMA usage consists of following steps
|
||||
1. Allocate a DMA slave channel
|
||||
2. Set slave and controller specific parameters
|
||||
3. Get a descriptor for transaction
|
||||
4. Submit the transaction and wait for callback notification
|
||||
|
||||
1. Allocate a DMA slave channel
|
||||
Channel allocation is slightly different in the slave DMA context, client
|
||||
drivers typically need a channel from a particular DMA controller only and even
|
||||
in some cases a specific channel is desired. To request a channel
|
||||
dma_request_channel() API is used.
|
||||
|
||||
Interface:
|
||||
struct dma_chan *dma_request_channel(dma_cap_mask_t mask,
|
||||
dma_filter_fn filter_fn,
|
||||
void *filter_param);
|
||||
where dma_filter_fn is defined as:
|
||||
typedef bool (*dma_filter_fn)(struct dma_chan *chan, void *filter_param);
|
||||
|
||||
When the optional 'filter_fn' parameter is set to NULL dma_request_channel
|
||||
simply returns the first channel that satisfies the capability mask. Otherwise,
|
||||
when the mask parameter is insufficient for specifying the necessary channel,
|
||||
the filter_fn routine can be used to disposition the available channels in the
|
||||
system. The filter_fn routine is called once for each free channel in the
|
||||
system. Upon seeing a suitable channel filter_fn returns DMA_ACK which flags
|
||||
that channel to be the return value from dma_request_channel. A channel
|
||||
allocated via this interface is exclusive to the caller, until
|
||||
dma_release_channel() is called.
|
||||
|
||||
2. Set slave and controller specific parameters
|
||||
Next step is always to pass some specific information to the DMA driver. Most of
|
||||
the generic information which a slave DMA can use is in struct dma_slave_config.
|
||||
It allows the clients to specify DMA direction, DMA addresses, bus widths, DMA
|
||||
burst lengths etc. If some DMA controllers have more parameters to be sent then
|
||||
they should try to embed struct dma_slave_config in their controller specific
|
||||
structure. That gives flexibility to client to pass more parameters, if
|
||||
required.
|
||||
|
||||
Interface:
|
||||
int dmaengine_slave_config(struct dma_chan *chan,
|
||||
struct dma_slave_config *config)
|
||||
|
||||
3. Get a descriptor for transaction
|
||||
For slave usage the various modes of slave transfers supported by the
|
||||
DMA-engine are:
|
||||
slave_sg - DMA a list of scatter gather buffers from/to a peripheral
|
||||
dma_cyclic - Perform a cyclic DMA operation from/to a peripheral till the
|
||||
operation is explicitly stopped.
|
||||
The non NULL return of this transfer API represents a "descriptor" for the given
|
||||
transaction.
|
||||
|
||||
Interface:
|
||||
struct dma_async_tx_descriptor *(*chan->device->device_prep_dma_sg)(
|
||||
struct dma_chan *chan,
|
||||
struct scatterlist *dst_sg, unsigned int dst_nents,
|
||||
struct scatterlist *src_sg, unsigned int src_nents,
|
||||
unsigned long flags);
|
||||
struct dma_async_tx_descriptor *(*chan->device->device_prep_dma_cyclic)(
|
||||
struct dma_chan *chan, dma_addr_t buf_addr, size_t buf_len,
|
||||
size_t period_len, enum dma_data_direction direction);
|
||||
|
||||
4. Submit the transaction and wait for callback notification
|
||||
To schedule the transaction to be scheduled by dma device, the "descriptor"
|
||||
returned in above (3) needs to be submitted.
|
||||
To tell the dma driver that a transaction is ready to be serviced, the
|
||||
descriptor->submit() callback needs to be invoked. This chains the descriptor to
|
||||
the pending queue.
|
||||
The transactions in the pending queue can be activated by calling the
|
||||
issue_pending API. If channel is idle then the first transaction in queue is
|
||||
started and subsequent ones queued up.
|
||||
On completion of the DMA operation the next in queue is submitted and a tasklet
|
||||
triggered. The tasklet would then call the client driver completion callback
|
||||
routine for notification, if set.
|
||||
Interface:
|
||||
void dma_async_issue_pending(struct dma_chan *chan);
|
||||
|
||||
==============================================================================
|
||||
|
||||
Additional usage notes for dma driver writers
|
||||
1/ Although DMA engine specifies that completion callback routines cannot submit
|
||||
any new operations, but typically for slave DMA subsequent transaction may not
|
||||
be available for submit prior to callback routine being called. This requirement
|
||||
is not a requirement for DMA-slave devices. But they should take care to drop
|
||||
the spin-lock they might be holding before calling the callback routine
|
||||
|
|
|
|||
|
|
@ -6,6 +6,42 @@ be removed from this file.
|
|||
|
||||
---------------------------
|
||||
|
||||
What: x86 floppy disable_hlt
|
||||
When: 2012
|
||||
Why: ancient workaround of dubious utility clutters the
|
||||
code used by everybody else.
|
||||
Who: Len Brown <len.brown@intel.com>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: CONFIG_APM_CPU_IDLE, and its ability to call APM BIOS in idle
|
||||
When: 2012
|
||||
Why: This optional sub-feature of APM is of dubious reliability,
|
||||
and ancient APM laptops are likely better served by calling HLT.
|
||||
Deleting CONFIG_APM_CPU_IDLE allows x86 to stop exporting
|
||||
the pm_idle function pointer to modules.
|
||||
Who: Len Brown <len.brown@intel.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: x86_32 "no-hlt" cmdline param
|
||||
When: 2012
|
||||
Why: remove a branch from idle path, simplify code used by everybody.
|
||||
This option disabled the use of HLT in idle and machine_halt()
|
||||
for hardware that was flakey 15-years ago. Today we have
|
||||
"idle=poll" that removed HLT from idle, and so if such a machine
|
||||
is still running the upstream kernel, "idle=poll" is likely sufficient.
|
||||
Who: Len Brown <len.brown@intel.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: x86 "idle=mwait" cmdline param
|
||||
When: 2012
|
||||
Why: simplify x86 idle code
|
||||
Who: Len Brown <len.brown@intel.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: PRISM54
|
||||
When: 2.6.34
|
||||
|
||||
|
|
@ -262,16 +298,6 @@ Who: Michael Buesch <mb@bu3sch.de>
|
|||
|
||||
---------------------------
|
||||
|
||||
What: /sys/o2cb symlink
|
||||
When: January 2010
|
||||
Why: /sys/fs/o2cb is the proper location for this information - /sys/o2cb
|
||||
exists as a symlink for backwards compatibility for old versions of
|
||||
ocfs2-tools. 2 years should be sufficient time to phase in new versions
|
||||
which know to look in /sys/fs/o2cb.
|
||||
Who: ocfs2-devel@oss.oracle.com
|
||||
|
||||
---------------------------
|
||||
|
||||
What: Ability for non root users to shm_get hugetlb pages based on mlock
|
||||
resource limits
|
||||
When: 2.6.31
|
||||
|
|
|
|||
|
|
@ -25,6 +25,8 @@ Other applications are described in the following papers:
|
|||
http://xcpu.org/papers/cellfs-talk.pdf
|
||||
* PROSE I/O: Using 9p to enable Application Partitions
|
||||
http://plan9.escet.urjc.es/iwp9/cready/PROSE_iwp9_2006.pdf
|
||||
* VirtFS: A Virtualization Aware File System pass-through
|
||||
http://goo.gl/3WPDg
|
||||
|
||||
USAGE
|
||||
=====
|
||||
|
|
@ -130,31 +132,20 @@ OPTIONS
|
|||
RESOURCES
|
||||
=========
|
||||
|
||||
Our current recommendation is to use Inferno (http://www.vitanuova.com/nferno/index.html)
|
||||
as the 9p server. You can start a 9p server under Inferno by issuing the
|
||||
following command:
|
||||
; styxlisten -A tcp!*!564 export '#U*'
|
||||
Protocol specifications are maintained on github:
|
||||
http://ericvh.github.com/9p-rfc/
|
||||
|
||||
The -A specifies an unauthenticated export. The 564 is the port # (you may
|
||||
have to choose a higher port number if running as a normal user). The '#U*'
|
||||
specifies exporting the root of the Linux name space. You may specify a
|
||||
subset of the namespace by extending the path: '#U*'/tmp would just export
|
||||
/tmp. For more information, see the Inferno manual pages covering styxlisten
|
||||
and export.
|
||||
9p client and server implementations are listed on
|
||||
http://9p.cat-v.org/implementations
|
||||
|
||||
A Linux version of the 9p server is now maintained under the npfs project
|
||||
on sourceforge (http://sourceforge.net/projects/npfs). The currently
|
||||
maintained version is the single-threaded version of the server (named spfs)
|
||||
available from the same SVN repository.
|
||||
A 9p2000.L server is being developed by LLNL and can be found
|
||||
at http://code.google.com/p/diod/
|
||||
|
||||
There are user and developer mailing lists available through the v9fs project
|
||||
on sourceforge (http://sourceforge.net/projects/v9fs).
|
||||
|
||||
A stand-alone version of the module (which should build for any 2.6 kernel)
|
||||
is available via (http://github.com/ericvh/9p-sac/tree/master)
|
||||
|
||||
News and other information is maintained on SWiK (http://swik.net/v9fs)
|
||||
and the Wiki (http://sf.net/apps/mediawiki/v9fs/index.php).
|
||||
News and other information is maintained on a Wiki.
|
||||
(http://sf.net/apps/mediawiki/v9fs/index.php).
|
||||
|
||||
Bug reports may be issued through the kernel.org bugzilla
|
||||
(http://bugzilla.kernel.org)
|
||||
|
|
|
|||
|
|
@ -104,7 +104,7 @@ of the locking scheme for directory operations.
|
|||
prototypes:
|
||||
struct inode *(*alloc_inode)(struct super_block *sb);
|
||||
void (*destroy_inode)(struct inode *);
|
||||
void (*dirty_inode) (struct inode *);
|
||||
void (*dirty_inode) (struct inode *, int flags);
|
||||
int (*write_inode) (struct inode *, struct writeback_control *wbc);
|
||||
int (*drop_inode) (struct inode *);
|
||||
void (*evict_inode) (struct inode *);
|
||||
|
|
@ -126,7 +126,7 @@ locking rules:
|
|||
s_umount
|
||||
alloc_inode:
|
||||
destroy_inode:
|
||||
dirty_inode: (must not sleep)
|
||||
dirty_inode:
|
||||
write_inode:
|
||||
drop_inode: !!!inode->i_lock!!!
|
||||
evict_inode:
|
||||
|
|
|
|||
|
|
@ -464,9 +464,8 @@ static int __init configfs_example_init(void)
|
|||
return 0;
|
||||
|
||||
out_unregister:
|
||||
for (; i >= 0; i--) {
|
||||
for (i--; i >= 0; i--)
|
||||
configfs_unregister_subsystem(example_subsys[i]);
|
||||
}
|
||||
|
||||
return ret;
|
||||
}
|
||||
|
|
@ -475,9 +474,8 @@ static void __exit configfs_example_exit(void)
|
|||
{
|
||||
int i;
|
||||
|
||||
for (i = 0; example_subsys[i]; i++) {
|
||||
for (i = 0; example_subsys[i]; i++)
|
||||
configfs_unregister_subsystem(example_subsys[i]);
|
||||
}
|
||||
}
|
||||
|
||||
module_init(configfs_example_init);
|
||||
|
|
|
|||
|
|
@ -427,9 +427,8 @@ static int __init configfs_example_init(void)
|
|||
return 0;
|
||||
|
||||
out_unregister:
|
||||
for (; i >= 0; i--) {
|
||||
for (i--; i >= 0; i--)
|
||||
configfs_unregister_subsystem(example_subsys[i]);
|
||||
}
|
||||
|
||||
return ret;
|
||||
}
|
||||
|
|
@ -438,9 +437,8 @@ static void __exit configfs_example_exit(void)
|
|||
{
|
||||
int i;
|
||||
|
||||
for (i = 0; example_subsys[i]; i++) {
|
||||
for (i = 0; example_subsys[i]; i++)
|
||||
configfs_unregister_subsystem(example_subsys[i]);
|
||||
}
|
||||
}
|
||||
|
||||
module_init(configfs_example_init);
|
||||
|
|
|
|||
|
|
@ -226,10 +226,6 @@ acl Enables POSIX Access Control Lists support.
|
|||
noacl This option disables POSIX Access Control List
|
||||
support.
|
||||
|
||||
reservation
|
||||
|
||||
noreservation
|
||||
|
||||
bsddf (*) Make 'df' act like BSD.
|
||||
minixdf Make 'df' act like Minix.
|
||||
|
||||
|
|
|
|||
|
|
@ -47,8 +47,8 @@ request-key will find the first matching line and corresponding program. In
|
|||
this case, /some/other/program will handle all uid lookups and
|
||||
/usr/sbin/nfs.idmap will handle gid, user, and group lookups.
|
||||
|
||||
See <file:Documentation/keys-request-keys.txt> for more information about the
|
||||
request-key function.
|
||||
See <file:Documentation/security/keys-request-keys.txt> for more information
|
||||
about the request-key function.
|
||||
|
||||
|
||||
=========
|
||||
|
|
|
|||
|
|
@ -46,9 +46,15 @@ errors=panic Panic and halt the machine if an error occurs.
|
|||
intr (*) Allow signals to interrupt cluster operations.
|
||||
nointr Do not allow signals to interrupt cluster
|
||||
operations.
|
||||
noatime Do not update access time.
|
||||
relatime(*) Update atime if the previous atime is older than
|
||||
mtime or ctime
|
||||
strictatime Always update atime, but the minimum update interval
|
||||
is specified by atime_quantum.
|
||||
atime_quantum=60(*) OCFS2 will not update atime unless this number
|
||||
of seconds has passed since the last update.
|
||||
Set to zero to always update atime.
|
||||
Set to zero to always update atime. This option need
|
||||
work with strictatime.
|
||||
data=ordered (*) All data are forced directly out to the main file
|
||||
system prior to its metadata being committed to the
|
||||
journal.
|
||||
|
|
|
|||
|
|
@ -574,6 +574,12 @@ The contents of each smp_affinity file is the same by default:
|
|||
> cat /proc/irq/0/smp_affinity
|
||||
ffffffff
|
||||
|
||||
There is an alternate interface, smp_affinity_list which allows specifying
|
||||
a cpu range instead of a bitmask:
|
||||
|
||||
> cat /proc/irq/0/smp_affinity_list
|
||||
1024-1031
|
||||
|
||||
The default_smp_affinity mask applies to all non-active IRQs, which are the
|
||||
IRQs which have not yet been allocated/activated, and hence which lack a
|
||||
/proc/irq/[0-9]* directory.
|
||||
|
|
@ -583,12 +589,13 @@ reports itself as being attached. This hardware locality information does not
|
|||
include information about any possible driver locality preference.
|
||||
|
||||
prof_cpu_mask specifies which CPUs are to be profiled by the system wide
|
||||
profiler. Default value is ffffffff (all cpus).
|
||||
profiler. Default value is ffffffff (all cpus if there are only 32 of them).
|
||||
|
||||
The way IRQs are routed is handled by the IO-APIC, and it's Round Robin
|
||||
between all the CPUs which are allowed to handle it. As usual the kernel has
|
||||
more info than you and does a better job than you, so the defaults are the
|
||||
best choice for almost everyone.
|
||||
best choice for almost everyone. [Note this applies only to those IO-APIC's
|
||||
that support "Round Robin" interrupt distribution.]
|
||||
|
||||
There are three more important subdirectories in /proc: net, scsi, and sys.
|
||||
The general rule is that the contents, or even the existence of these
|
||||
|
|
|
|||
|
|
@ -115,28 +115,8 @@ ubi.mtd=0 root=ubi0:rootfs rootfstype=ubifs
|
|||
Module Parameters for Debugging
|
||||
===============================
|
||||
|
||||
When UBIFS has been compiled with debugging enabled, there are 3 module
|
||||
When UBIFS has been compiled with debugging enabled, there are 2 module
|
||||
parameters that are available to control aspects of testing and debugging.
|
||||
The parameters are unsigned integers where each bit controls an option.
|
||||
The parameters are:
|
||||
|
||||
debug_msgs Selects which debug messages to display, as follows:
|
||||
|
||||
Message Type Flag value
|
||||
|
||||
General messages 1
|
||||
Journal messages 2
|
||||
Mount messages 4
|
||||
Commit messages 8
|
||||
LEB search messages 16
|
||||
Budgeting messages 32
|
||||
Garbage collection messages 64
|
||||
Tree Node Cache (TNC) messages 128
|
||||
LEB properties (lprops) messages 256
|
||||
Input/output messages 512
|
||||
Log messages 1024
|
||||
Scan messages 2048
|
||||
Recovery messages 4096
|
||||
|
||||
debug_chks Selects extra checks that UBIFS can do while running:
|
||||
|
||||
|
|
@ -154,11 +134,9 @@ debug_tsts Selects a mode of testing, as follows:
|
|||
|
||||
Test mode Flag value
|
||||
|
||||
Force in-the-gaps method 2
|
||||
Failure mode for recovery testing 4
|
||||
|
||||
For example, set debug_msgs to 5 to display General messages and Mount
|
||||
messages.
|
||||
For example, set debug_chks to 3 to enable general and TNC checks.
|
||||
|
||||
|
||||
References
|
||||
|
|
|
|||
|
|
@ -211,7 +211,7 @@ struct super_operations {
|
|||
struct inode *(*alloc_inode)(struct super_block *sb);
|
||||
void (*destroy_inode)(struct inode *);
|
||||
|
||||
void (*dirty_inode) (struct inode *);
|
||||
void (*dirty_inode) (struct inode *, int flags);
|
||||
int (*write_inode) (struct inode *, int);
|
||||
void (*drop_inode) (struct inode *);
|
||||
void (*delete_inode) (struct inode *);
|
||||
|
|
|
|||
|
|
@ -39,6 +39,12 @@ When mounting an XFS filesystem, the following options are accepted.
|
|||
drive level write caching to be enabled, for devices that
|
||||
support write barriers.
|
||||
|
||||
discard
|
||||
Issue command to let the block device reclaim space freed by the
|
||||
filesystem. This is useful for SSD devices, thinly provisioned
|
||||
LUNs and virtual machine images, but may have a performance
|
||||
impact. This option is incompatible with the nodelaylog option.
|
||||
|
||||
dmapi
|
||||
Enable the DMAPI (Data Management API) event callouts.
|
||||
Use with the "mtpt" option.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,42 @@
|
|||
Kernel driver emc6w201
|
||||
======================
|
||||
|
||||
Supported chips:
|
||||
* SMSC EMC6W201
|
||||
Prefix: 'emc6w201'
|
||||
Addresses scanned: I2C 0x2c, 0x2d, 0x2e
|
||||
Datasheet: Not public
|
||||
|
||||
Author: Jean Delvare <khali@linux-fr.org>
|
||||
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
From the datasheet:
|
||||
|
||||
"The EMC6W201 is an environmental monitoring device with automatic fan
|
||||
control capability and enhanced system acoustics for noise suppression.
|
||||
This ACPI compliant device provides hardware monitoring for up to six
|
||||
voltages (including its own VCC) and five external thermal sensors,
|
||||
measures the speed of up to five fans, and controls the speed of
|
||||
multiple DC fans using three Pulse Width Modulator (PWM) outputs. Note
|
||||
that it is possible to control more than three fans by connecting two
|
||||
fans to one PWM output. The EMC6W201 will be available in a 36-pin
|
||||
QFN package."
|
||||
|
||||
The device is functionally close to the EMC6D100 series, but is
|
||||
register-incompatible.
|
||||
|
||||
The driver currently only supports the monitoring of the voltages,
|
||||
temperatures and fan speeds. Limits can be changed. Alarms are not
|
||||
supported, and neither is fan speed control.
|
||||
|
||||
|
||||
Known Systems With EMC6W201
|
||||
---------------------------
|
||||
|
||||
The EMC6W201 is a rare device, only found on a few systems, made in
|
||||
2005 and 2006. Known systems with this device:
|
||||
* Dell Precision 670 workstation
|
||||
* Gigabyte 2CEWH mainboard
|
||||
|
|
@ -6,6 +6,10 @@ Supported chips:
|
|||
Prefix: 'f71808e'
|
||||
Addresses scanned: none, address read from Super I/O config space
|
||||
Datasheet: Not public
|
||||
* Fintek F71808A
|
||||
Prefix: 'f71808a'
|
||||
Addresses scanned: none, address read from Super I/O config space
|
||||
Datasheet: Not public
|
||||
* Fintek F71858FG
|
||||
Prefix: 'f71858fg'
|
||||
Addresses scanned: none, address read from Super I/O config space
|
||||
|
|
|
|||
|
|
@ -0,0 +1,37 @@
|
|||
Kernel driver fam15h_power
|
||||
==========================
|
||||
|
||||
Supported chips:
|
||||
* AMD Family 15h Processors
|
||||
|
||||
Prefix: 'fam15h_power'
|
||||
Addresses scanned: PCI space
|
||||
Datasheets:
|
||||
BIOS and Kernel Developer's Guide (BKDG) For AMD Family 15h Processors
|
||||
(not yet published)
|
||||
|
||||
Author: Andreas Herrmann <andreas.herrmann3@amd.com>
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
This driver permits reading of registers providing power information
|
||||
of AMD Family 15h processors.
|
||||
|
||||
For AMD Family 15h processors the following power values can be
|
||||
calculated using different processor northbridge function registers:
|
||||
|
||||
* BasePwrWatts: Specifies in watts the maximum amount of power
|
||||
consumed by the processor for NB and logic external to the core.
|
||||
* ProcessorPwrWatts: Specifies in watts the maximum amount of power
|
||||
the processor can support.
|
||||
* CurrPwrWatts: Specifies in watts the current amount of power being
|
||||
consumed by the processor.
|
||||
|
||||
This driver provides ProcessorPwrWatts and CurrPwrWatts:
|
||||
* power1_crit (ProcessorPwrWatts)
|
||||
* power1_input (CurrPwrWatts)
|
||||
|
||||
On multi-node processors the calculated value is for the entire
|
||||
package and not for a single node. Thus the driver creates sysfs
|
||||
attributes only for internal node0 of a multi-node processor.
|
||||
|
|
@ -11,6 +11,7 @@ Supported chips:
|
|||
Socket S1G2: Athlon (X2), Sempron (X2), Turion X2 (Ultra)
|
||||
* AMD Family 12h processors: "Llano"
|
||||
* AMD Family 14h processors: "Brazos" (C/E/G-Series)
|
||||
* AMD Family 15h processors: "Bulldozer"
|
||||
|
||||
Prefix: 'k10temp'
|
||||
Addresses scanned: PCI space
|
||||
|
|
@ -40,7 +41,7 @@ Description
|
|||
-----------
|
||||
|
||||
This driver permits reading of the internal temperature sensor of AMD
|
||||
Family 10h/11h/12h/14h processors.
|
||||
Family 10h/11h/12h/14h/15h processors.
|
||||
|
||||
All these processors have a sensor, but on those for Socket F or AM2+,
|
||||
the sensor may return inconsistent values (erratum 319). The driver
|
||||
|
|
|
|||
|
|
@ -2,9 +2,13 @@ Kernel driver max6650
|
|||
=====================
|
||||
|
||||
Supported chips:
|
||||
* Maxim 6650 / 6651
|
||||
* Maxim MAX6650
|
||||
Prefix: 'max6650'
|
||||
Addresses scanned: I2C 0x1b, 0x1f, 0x48, 0x4b
|
||||
Addresses scanned: none
|
||||
Datasheet: http://pdfserv.maxim-ic.com/en/ds/MAX6650-MAX6651.pdf
|
||||
* Maxim MAX6651
|
||||
Prefix: 'max6651'
|
||||
Addresses scanned: none
|
||||
Datasheet: http://pdfserv.maxim-ic.com/en/ds/MAX6650-MAX6651.pdf
|
||||
|
||||
Authors:
|
||||
|
|
@ -15,10 +19,10 @@ Authors:
|
|||
Description
|
||||
-----------
|
||||
|
||||
This driver implements support for the Maxim 6650/6651
|
||||
This driver implements support for the Maxim MAX6650 and MAX6651.
|
||||
|
||||
The 2 devices are very similar, but the Maxim 6550 has a reduced feature
|
||||
set, e.g. only one fan-input, instead of 4 for the 6651.
|
||||
The 2 devices are very similar, but the MAX6550 has a reduced feature
|
||||
set, e.g. only one fan-input, instead of 4 for the MAX6651.
|
||||
|
||||
The driver is not able to distinguish between the 2 devices.
|
||||
|
||||
|
|
@ -36,6 +40,13 @@ fan1_div rw sets the speed range the inputs can handle. Legal
|
|||
values are 1, 2, 4, and 8. Use lower values for
|
||||
faster fans.
|
||||
|
||||
Usage notes
|
||||
-----------
|
||||
|
||||
This driver does not auto-detect devices. You will have to instantiate the
|
||||
devices explicitly. Please see Documentation/i2c/instantiating-devices for
|
||||
details.
|
||||
|
||||
Module parameters
|
||||
-----------------
|
||||
|
||||
|
|
|
|||
|
|
@ -19,6 +19,7 @@ Supported adapters:
|
|||
* Intel 6 Series (PCH)
|
||||
* Intel Patsburg (PCH)
|
||||
* Intel DH89xxCC (PCH)
|
||||
* Intel Panther Point (PCH)
|
||||
Datasheets: Publicly available at the Intel website
|
||||
|
||||
On Intel Patsburg and later chipsets, both the normal host SMBus controller
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ static struct i2c_driver foo_driver = {
|
|||
.name = "foo",
|
||||
},
|
||||
|
||||
.id_table = foo_ids,
|
||||
.id_table = foo_idtable,
|
||||
.probe = foo_probe,
|
||||
.remove = foo_remove,
|
||||
/* if device autodetection is needed: */
|
||||
|
|
|
|||
|
|
@ -34,7 +34,8 @@ Contents
|
|||
Currently the Linux Elantech touchpad driver is aware of two different
|
||||
hardware versions unimaginatively called version 1 and version 2. Version 1
|
||||
is found in "older" laptops and uses 4 bytes per packet. Version 2 seems to
|
||||
be introduced with the EeePC and uses 6 bytes per packet.
|
||||
be introduced with the EeePC and uses 6 bytes per packet, and provides
|
||||
additional features such as position of two fingers, and width of the touch.
|
||||
|
||||
The driver tries to support both hardware versions and should be compatible
|
||||
with the Xorg Synaptics touchpad driver and its graphical configuration
|
||||
|
|
@ -94,18 +95,44 @@ Currently the Linux Elantech touchpad driver provides two extra knobs under
|
|||
can check these bits and reject any packet that appears corrupted. Using
|
||||
this knob you can bypass that check.
|
||||
|
||||
It is not known yet whether hardware version 2 provides the same parity
|
||||
bits. Hence checking is disabled by default. Currently even turning it on
|
||||
will do nothing.
|
||||
|
||||
Hardware version 2 does not provide the same parity bits. Only some basic
|
||||
data consistency checking can be done. For now checking is disabled by
|
||||
default. Currently even turning it on will do nothing.
|
||||
|
||||
/////////////////////////////////////////////////////////////////////////////
|
||||
|
||||
3. Differentiating hardware versions
|
||||
=================================
|
||||
|
||||
3. Hardware version 1
|
||||
To detect the hardware version, read the version number as param[0].param[1].param[2]
|
||||
|
||||
4 bytes version: (after the arrow is the name given in the Dell-provided driver)
|
||||
02.00.22 => EF013
|
||||
02.06.00 => EF019
|
||||
In the wild, there appear to be more versions, such as 00.01.64, 01.00.21,
|
||||
02.00.00, 02.00.04, 02.00.06.
|
||||
|
||||
6 bytes:
|
||||
02.00.30 => EF113
|
||||
02.08.00 => EF023
|
||||
02.08.XX => EF123
|
||||
02.0B.00 => EF215
|
||||
04.01.XX => Scroll_EF051
|
||||
04.02.XX => EF051
|
||||
In the wild, there appear to be more versions, such as 04.03.01, 04.04.11. There
|
||||
appears to be almost no difference, except for EF113, which does not report
|
||||
pressure/width and has different data consistency checks.
|
||||
|
||||
Probably all the versions with param[0] <= 01 can be considered as
|
||||
4 bytes/firmware 1. The versions < 02.08.00, with the exception of 02.00.30, as
|
||||
4 bytes/firmware 2. Everything >= 02.08.00 can be considered as 6 bytes.
|
||||
|
||||
/////////////////////////////////////////////////////////////////////////////
|
||||
|
||||
4. Hardware version 1
|
||||
==================
|
||||
|
||||
3.1 Registers
|
||||
4.1 Registers
|
||||
~~~~~~~~~
|
||||
|
||||
By echoing a hexadecimal value to a register it contents can be altered.
|
||||
|
|
@ -168,7 +195,7 @@ For example:
|
|||
smart edge activation area width?
|
||||
|
||||
|
||||
3.2 Native relative mode 4 byte packet format
|
||||
4.2 Native relative mode 4 byte packet format
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
byte 0:
|
||||
|
|
@ -226,9 +253,13 @@ byte 3:
|
|||
positive = down
|
||||
|
||||
|
||||
3.3 Native absolute mode 4 byte packet format
|
||||
4.3 Native absolute mode 4 byte packet format
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
EF013 and EF019 have a special behaviour (due to a bug in the firmware?), and
|
||||
when 1 finger is touching, the first 2 position reports must be discarded.
|
||||
This counting is reset whenever a different number of fingers is reported.
|
||||
|
||||
byte 0:
|
||||
firmware version 1.x:
|
||||
|
||||
|
|
@ -279,11 +310,11 @@ byte 3:
|
|||
/////////////////////////////////////////////////////////////////////////////
|
||||
|
||||
|
||||
4. Hardware version 2
|
||||
5. Hardware version 2
|
||||
==================
|
||||
|
||||
|
||||
4.1 Registers
|
||||
5.1 Registers
|
||||
~~~~~~~~~
|
||||
|
||||
By echoing a hexadecimal value to a register it contents can be altered.
|
||||
|
|
@ -316,16 +347,41 @@ For example:
|
|||
0x7f = never i.e. tap again to release)
|
||||
|
||||
|
||||
4.2 Native absolute mode 6 byte packet format
|
||||
5.2 Native absolute mode 6 byte packet format
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
5.2.1 Parity checking and packet re-synchronization
|
||||
There is no parity checking, however some consistency checks can be performed.
|
||||
|
||||
4.2.1 One finger touch
|
||||
For instance for EF113:
|
||||
SA1= packet[0];
|
||||
A1 = packet[1];
|
||||
B1 = packet[2];
|
||||
SB1= packet[3];
|
||||
C1 = packet[4];
|
||||
D1 = packet[5];
|
||||
if( (((SA1 & 0x3C) != 0x3C) && ((SA1 & 0xC0) != 0x80)) || // check Byte 1
|
||||
(((SA1 & 0x0C) != 0x0C) && ((SA1 & 0xC0) == 0x80)) || // check Byte 1 (one finger pressed)
|
||||
(((SA1 & 0xC0) != 0x80) && (( A1 & 0xF0) != 0x00)) || // check Byte 2
|
||||
(((SB1 & 0x3E) != 0x38) && ((SA1 & 0xC0) != 0x80)) || // check Byte 4
|
||||
(((SB1 & 0x0E) != 0x08) && ((SA1 & 0xC0) == 0x80)) || // check Byte 4 (one finger pressed)
|
||||
(((SA1 & 0xC0) != 0x80) && (( C1 & 0xF0) != 0x00)) ) // check Byte 5
|
||||
// error detected
|
||||
|
||||
For all the other ones, there are just a few constant bits:
|
||||
if( ((packet[0] & 0x0C) != 0x04) ||
|
||||
((packet[3] & 0x0f) != 0x02) )
|
||||
// error detected
|
||||
|
||||
|
||||
In case an error is detected, all the packets are shifted by one (and packet[0] is discarded).
|
||||
|
||||
5.2.1 One/Three finger touch
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
byte 0:
|
||||
|
||||
bit 7 6 5 4 3 2 1 0
|
||||
n1 n0 . . . . R L
|
||||
n1 n0 w3 w2 . . R L
|
||||
|
||||
L, R = 1 when Left, Right mouse button pressed
|
||||
n1..n0 = numbers of fingers on touchpad
|
||||
|
|
@ -333,24 +389,40 @@ byte 0:
|
|||
byte 1:
|
||||
|
||||
bit 7 6 5 4 3 2 1 0
|
||||
. . . . . x10 x9 x8
|
||||
p7 p6 p5 p4 . x10 x9 x8
|
||||
|
||||
byte 2:
|
||||
|
||||
bit 7 6 5 4 3 2 1 0
|
||||
x7 x6 x5 x4 x4 x2 x1 x0
|
||||
x7 x6 x5 x4 x3 x2 x1 x0
|
||||
|
||||
x10..x0 = absolute x value (horizontal)
|
||||
|
||||
byte 3:
|
||||
|
||||
bit 7 6 5 4 3 2 1 0
|
||||
. . . . . . . .
|
||||
n4 vf w1 w0 . . . b2
|
||||
|
||||
n4 = set if more than 3 fingers (only in 3 fingers mode)
|
||||
vf = a kind of flag ? (only on EF123, 0 when finger is over one
|
||||
of the buttons, 1 otherwise)
|
||||
w3..w0 = width of the finger touch (not EF113)
|
||||
b2 (on EF113 only, 0 otherwise), b2.R.L indicates one button pressed:
|
||||
0 = none
|
||||
1 = Left
|
||||
2 = Right
|
||||
3 = Middle (Left and Right)
|
||||
4 = Forward
|
||||
5 = Back
|
||||
6 = Another one
|
||||
7 = Another one
|
||||
|
||||
byte 4:
|
||||
|
||||
bit 7 6 5 4 3 2 1 0
|
||||
. . . . . . y9 y8
|
||||
p3 p1 p2 p0 . . y9 y8
|
||||
|
||||
p7..p0 = pressure (not EF113)
|
||||
|
||||
byte 5:
|
||||
|
||||
|
|
@ -363,6 +435,11 @@ byte 5:
|
|||
4.2.2 Two finger touch
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
Note that the two pairs of coordinates are not exactly the coordinates of the
|
||||
two fingers, but only the pair of the lower-left and upper-right coordinates.
|
||||
So the actual fingers might be situated on the other diagonal of the square
|
||||
defined by these two points.
|
||||
|
||||
byte 0:
|
||||
|
||||
bit 7 6 5 4 3 2 1 0
|
||||
|
|
@ -376,14 +453,14 @@ byte 1:
|
|||
bit 7 6 5 4 3 2 1 0
|
||||
ax7 ax6 ax5 ax4 ax3 ax2 ax1 ax0
|
||||
|
||||
ax8..ax0 = first finger absolute x value
|
||||
ax8..ax0 = lower-left finger absolute x value
|
||||
|
||||
byte 2:
|
||||
|
||||
bit 7 6 5 4 3 2 1 0
|
||||
ay7 ay6 ay5 ay4 ay3 ay2 ay1 ay0
|
||||
|
||||
ay8..ay0 = first finger absolute y value
|
||||
ay8..ay0 = lower-left finger absolute y value
|
||||
|
||||
byte 3:
|
||||
|
||||
|
|
@ -395,11 +472,11 @@ byte 4:
|
|||
bit 7 6 5 4 3 2 1 0
|
||||
bx7 bx6 bx5 bx4 bx3 bx2 bx1 bx0
|
||||
|
||||
bx8..bx0 = second finger absolute x value
|
||||
bx8..bx0 = upper-right finger absolute x value
|
||||
|
||||
byte 5:
|
||||
|
||||
bit 7 6 5 4 3 2 1 0
|
||||
by7 by8 by5 by4 by3 by2 by1 by0
|
||||
|
||||
by8..by0 = second finger absolute y value
|
||||
by8..by0 = upper-right finger absolute y value
|
||||
|
|
|
|||
|
|
@ -9,6 +9,9 @@ peripherals with two wires. The outputs are phase-shifted by 90 degrees
|
|||
and by triggering on falling and rising edges, the turn direction can
|
||||
be determined.
|
||||
|
||||
Some encoders have both outputs low in stable states, whereas others also have
|
||||
a stable state with both outputs high (half-period mode).
|
||||
|
||||
The phase diagram of these two outputs look like this:
|
||||
|
||||
_____ _____ _____
|
||||
|
|
@ -26,6 +29,8 @@ The phase diagram of these two outputs look like this:
|
|||
|<-------->|
|
||||
one step
|
||||
|
||||
|<-->|
|
||||
one step (half-period mode)
|
||||
|
||||
For more information, please see
|
||||
http://en.wikipedia.org/wiki/Rotary_encoder
|
||||
|
|
@ -34,6 +39,13 @@ For more information, please see
|
|||
1. Events / state machine
|
||||
-------------------------
|
||||
|
||||
In half-period mode, state a) and c) above are used to determine the
|
||||
rotational direction based on the last stable state. Events are reported in
|
||||
states b) and d) given that the new stable state is different from the last
|
||||
(i.e. the rotation was not reversed half-way).
|
||||
|
||||
Otherwise, the following apply:
|
||||
|
||||
a) Rising edge on channel A, channel B in low state
|
||||
This state is used to recognize a clockwise turn
|
||||
|
||||
|
|
@ -96,6 +108,7 @@ static struct rotary_encoder_platform_data my_rotary_encoder_info = {
|
|||
.gpio_b = GPIO_ROTARY_B,
|
||||
.inverted_a = 0,
|
||||
.inverted_b = 0,
|
||||
.half_period = false,
|
||||
};
|
||||
|
||||
static struct platform_device rotary_encoder_device = {
|
||||
|
|
|
|||
|
|
@ -304,6 +304,7 @@ Code Seq#(hex) Include File Comments
|
|||
0xB0 all RATIO devices in development:
|
||||
<mailto:vgo@ratio.de>
|
||||
0xB1 00-1F PPPoX <mailto:mostrows@styx.uwaterloo.ca>
|
||||
0xB3 00 linux/mmc/ioctl.h
|
||||
0xC0 00-0F linux/usb/iowarrior.h
|
||||
0xCB 00-1F CBM serial IEC bus in development:
|
||||
<mailto:michael.klein@puffin.lb.shuttle.de>
|
||||
|
|
|
|||
|
|
@ -201,3 +201,16 @@ KBUILD_ENABLE_EXTRA_GCC_CHECKS
|
|||
--------------------------------------------------
|
||||
If enabled over the make command line with "W=1", it turns on additional
|
||||
gcc -W... options for more extensive build-time checking.
|
||||
|
||||
KBUILD_BUILD_TIMESTAMP
|
||||
--------------------------------------------------
|
||||
Setting this to a date string overrides the timestamp used in the
|
||||
UTS_VERSION definition (uname -v in the running kernel). The value has to
|
||||
be a string that can be passed to date -d. The default value
|
||||
is the output of the date command at one point during build.
|
||||
|
||||
KBUILD_BUILD_USER, KBUILD_BUILD_HOST
|
||||
--------------------------------------------------
|
||||
These two variables allow to override the user@host string displayed during
|
||||
boot and in /proc/version. The default value is the output of the commands
|
||||
whoami and host, respectively.
|
||||
|
|
|
|||
|
|
@ -113,6 +113,13 @@ applicable everywhere (see syntax).
|
|||
That will limit the usefulness but on the other hand avoid
|
||||
the illegal configurations all over.
|
||||
|
||||
- limiting menu display: "visible if" <expr>
|
||||
This attribute is only applicable to menu blocks, if the condition is
|
||||
false, the menu block is not displayed to the user (the symbols
|
||||
contained there can still be selected by other symbols, though). It is
|
||||
similar to a conditional "prompt" attribude for individual menu
|
||||
entries. Default value of "visible" is true.
|
||||
|
||||
- numerical ranges: "range" <symbol> <symbol> ["if" <expr>]
|
||||
This allows to limit the range of possible input values for int
|
||||
and hex symbols. The user can only input a value which is larger than
|
||||
|
|
@ -303,7 +310,8 @@ menu:
|
|||
"endmenu"
|
||||
|
||||
This defines a menu block, see "Menu structure" above for more
|
||||
information. The only possible options are dependencies.
|
||||
information. The only possible options are dependencies and "visible"
|
||||
attributes.
|
||||
|
||||
if:
|
||||
|
||||
|
|
@ -381,3 +389,25 @@ config FOO
|
|||
|
||||
limits FOO to module (=m) or disabled (=n).
|
||||
|
||||
Kconfig symbol existence
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
The following two methods produce the same kconfig symbol dependencies
|
||||
but differ greatly in kconfig symbol existence (production) in the
|
||||
generated config file.
|
||||
|
||||
case 1:
|
||||
|
||||
config FOO
|
||||
tristate "about foo"
|
||||
depends on BAR
|
||||
|
||||
vs. case 2:
|
||||
|
||||
if BAR
|
||||
config FOO
|
||||
tristate "about foo"
|
||||
endif
|
||||
|
||||
In case 1, the symbol FOO will always exist in the config file (given
|
||||
no other dependencies). In case 2, the symbol FOO will only exist in
|
||||
the config file if BAR is enabled.
|
||||
|
|
|
|||
|
|
@ -48,11 +48,6 @@ KCONFIG_OVERWRITECONFIG
|
|||
If you set KCONFIG_OVERWRITECONFIG in the environment, Kconfig will not
|
||||
break symlinks when .config is a symlink to somewhere else.
|
||||
|
||||
KCONFIG_NOTIMESTAMP
|
||||
--------------------------------------------------
|
||||
If this environment variable exists and is non-null, the timestamp line
|
||||
in generated .config files is omitted.
|
||||
|
||||
______________________________________________________________________
|
||||
Environment variables for '{allyes/allmod/allno/rand}config'
|
||||
|
||||
|
|
|
|||
|
|
@ -40,11 +40,13 @@ This document describes the Linux kernel Makefiles.
|
|||
--- 6.6 Commands useful for building a boot image
|
||||
--- 6.7 Custom kbuild commands
|
||||
--- 6.8 Preprocessing linker scripts
|
||||
--- 6.9 Generic header files
|
||||
|
||||
=== 7 Kbuild syntax for exported headers
|
||||
--- 7.1 header-y
|
||||
--- 7.2 objhdr-y
|
||||
--- 7.3 destination-y
|
||||
--- 7.4 generic-y
|
||||
|
||||
=== 8 Kbuild Variables
|
||||
=== 9 Makefile language
|
||||
|
|
@ -499,6 +501,18 @@ more details, with real examples.
|
|||
gcc >= 3.00. For gcc < 3.00, -malign-functions=4 is used.
|
||||
Note: cc-option-align uses KBUILD_CFLAGS for $(CC) options
|
||||
|
||||
cc-disable-warning
|
||||
cc-disable-warning checks if gcc supports a given warning and returns
|
||||
the commandline switch to disable it. This special function is needed,
|
||||
because gcc 4.4 and later accept any unknown -Wno-* option and only
|
||||
warn about it if there is another warning in the source file.
|
||||
|
||||
Example:
|
||||
KBUILD_CFLAGS += $(call cc-disable-warning, unused-but-set-variable)
|
||||
|
||||
In the above example, -Wno-unused-but-set-variable will be added to
|
||||
KBUILD_CFLAGS only if gcc really accepts it.
|
||||
|
||||
cc-version
|
||||
cc-version returns a numerical version of the $(CC) compiler version.
|
||||
The format is <major><minor> where both are two digits. So for example
|
||||
|
|
@ -955,6 +969,11 @@ When kbuild executes, the following steps are followed (roughly):
|
|||
used when linking modules. This is often a linker script.
|
||||
From commandline LDFLAGS_MODULE shall be used (see kbuild.txt).
|
||||
|
||||
KBUILD_ARFLAGS Options for $(AR) when creating archives
|
||||
|
||||
$(KBUILD_ARFLAGS) set by the top level Makefile to "D" (deterministic
|
||||
mode) if this option is supported by $(AR).
|
||||
|
||||
--- 6.2 Add prerequisites to archprepare:
|
||||
|
||||
The archprepare: rule is used to list prerequisites that need to be
|
||||
|
|
@ -1209,6 +1228,14 @@ When kbuild executes, the following steps are followed (roughly):
|
|||
The kbuild infrastructure for *lds file are used in several
|
||||
architecture-specific files.
|
||||
|
||||
--- 6.9 Generic header files
|
||||
|
||||
The directory include/asm-generic contains the header files
|
||||
that may be shared between individual architectures.
|
||||
The recommended approach how to use a generic header file is
|
||||
to list the file in the Kbuild file.
|
||||
See "7.4 generic-y" for further info on syntax etc.
|
||||
|
||||
=== 7 Kbuild syntax for exported headers
|
||||
|
||||
The kernel include a set of headers that is exported to userspace.
|
||||
|
|
@ -1265,6 +1292,32 @@ See subsequent chapter for the syntax of the Kbuild file.
|
|||
In the example above all exported headers in the Kbuild file
|
||||
will be located in the directory "include/linux" when exported.
|
||||
|
||||
--- 7.4 generic-y
|
||||
|
||||
If an architecture uses a verbatim copy of a header from
|
||||
include/asm-generic then this is listed in the file
|
||||
arch/$(ARCH)/include/asm/Kbuild like this:
|
||||
|
||||
Example:
|
||||
#arch/x86/include/asm/Kbuild
|
||||
generic-y += termios.h
|
||||
generic-y += rtc.h
|
||||
|
||||
During the prepare phase of the build a wrapper include
|
||||
file is generated in the directory:
|
||||
|
||||
arch/$(ARCH)/include/generated/asm
|
||||
|
||||
When a header is exported where the architecture uses
|
||||
the generic header a similar wrapper is generated as part
|
||||
of the set of exported headers in the directory:
|
||||
|
||||
usr/include/asm
|
||||
|
||||
The generated wrapper will in both cases look like the following:
|
||||
|
||||
Example: termios.h
|
||||
#include <asm-generic/termios.h>
|
||||
|
||||
=== 8 Kbuild Variables
|
||||
|
||||
|
|
|
|||
|
|
@ -1777,9 +1777,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
|||
|
||||
nosoftlockup [KNL] Disable the soft-lockup detector.
|
||||
|
||||
noswapaccount [KNL] Disable accounting of swap in memory resource
|
||||
controller. (See Documentation/cgroups/memory.txt)
|
||||
|
||||
nosync [HW,M68K] Disables sync negotiation for all devices.
|
||||
|
||||
notsc [BUGS=X86-32] Disable Time Stamp Counter
|
||||
|
|
|
|||
|
|
@ -1,184 +0,0 @@
|
|||
Acer Laptop WMI Extras Driver
|
||||
http://code.google.com/p/aceracpi
|
||||
Version 0.3
|
||||
4th April 2009
|
||||
|
||||
Copyright 2007-2009 Carlos Corbacho <carlos@strangeworlds.co.uk>
|
||||
|
||||
acer-wmi is a driver to allow you to control various parts of your Acer laptop
|
||||
hardware under Linux which are exposed via ACPI-WMI.
|
||||
|
||||
This driver completely replaces the old out-of-tree acer_acpi, which I am
|
||||
currently maintaining for bug fixes only on pre-2.6.25 kernels. All development
|
||||
work is now focused solely on acer-wmi.
|
||||
|
||||
Disclaimer
|
||||
**********
|
||||
|
||||
Acer and Wistron have provided nothing towards the development acer_acpi or
|
||||
acer-wmi. All information we have has been through the efforts of the developers
|
||||
and the users to discover as much as possible about the hardware.
|
||||
|
||||
As such, I do warn that this could break your hardware - this is extremely
|
||||
unlikely of course, but please bear this in mind.
|
||||
|
||||
Background
|
||||
**********
|
||||
|
||||
acer-wmi is derived from acer_acpi, originally developed by Mark
|
||||
Smith in 2005, then taken over by Carlos Corbacho in 2007, in order to activate
|
||||
the wireless LAN card under a 64-bit version of Linux, as acerhk[1] (the
|
||||
previous solution to the problem) relied on making 32 bit BIOS calls which are
|
||||
not possible in kernel space from a 64 bit OS.
|
||||
|
||||
[1] acerhk: http://www.cakey.de/acerhk/
|
||||
|
||||
Supported Hardware
|
||||
******************
|
||||
|
||||
NOTE: The Acer Aspire One is not supported hardware. It cannot work with
|
||||
acer-wmi until Acer fix their ACPI-WMI implementation on them, so has been
|
||||
blacklisted until that happens.
|
||||
|
||||
Please see the website for the current list of known working hardware:
|
||||
|
||||
http://code.google.com/p/aceracpi/wiki/SupportedHardware
|
||||
|
||||
If your laptop is not listed, or listed as unknown, and works with acer-wmi,
|
||||
please contact me with a copy of the DSDT.
|
||||
|
||||
If your Acer laptop doesn't work with acer-wmi, I would also like to see the
|
||||
DSDT.
|
||||
|
||||
To send me the DSDT, as root/sudo:
|
||||
|
||||
cat /sys/firmware/acpi/tables/DSDT > dsdt
|
||||
|
||||
And send me the resulting 'dsdt' file.
|
||||
|
||||
Usage
|
||||
*****
|
||||
|
||||
On Acer laptops, acer-wmi should already be autoloaded based on DMI matching.
|
||||
For non-Acer laptops, until WMI based autoloading support is added, you will
|
||||
need to manually load acer-wmi.
|
||||
|
||||
acer-wmi creates /sys/devices/platform/acer-wmi, and fills it with various
|
||||
files whose usage is detailed below, which enables you to control some of the
|
||||
following (varies between models):
|
||||
|
||||
* the wireless LAN card radio
|
||||
* inbuilt Bluetooth adapter
|
||||
* inbuilt 3G card
|
||||
* mail LED of your laptop
|
||||
* brightness of the LCD panel
|
||||
|
||||
Wireless
|
||||
********
|
||||
|
||||
With regards to wireless, all acer-wmi does is enable the radio on the card. It
|
||||
is not responsible for the wireless LED - once the radio is enabled, this is
|
||||
down to the wireless driver for your card. So the behaviour of the wireless LED,
|
||||
once you enable the radio, will depend on your hardware and driver combination.
|
||||
|
||||
e.g. With the BCM4318 on the Acer Aspire 5020 series:
|
||||
|
||||
ndiswrapper: Light blinks on when transmitting
|
||||
b43: Solid light, blinks off when transmitting
|
||||
|
||||
Wireless radio control is unconditionally enabled - all Acer laptops that support
|
||||
acer-wmi come with built-in wireless. However, should you feel so inclined to
|
||||
ever wish to remove the card, or swap it out at some point, please get in touch
|
||||
with me, as we may well be able to gain some data on wireless card detection.
|
||||
|
||||
The wireless radio is exposed through rfkill.
|
||||
|
||||
Bluetooth
|
||||
*********
|
||||
|
||||
For bluetooth, this is an internal USB dongle, so once enabled, you will get
|
||||
a USB device connection event, and a new USB device appears. When you disable
|
||||
bluetooth, you get the reverse - a USB device disconnect event, followed by the
|
||||
device disappearing again.
|
||||
|
||||
Bluetooth is autodetected by acer-wmi, so if you do not have a bluetooth module
|
||||
installed in your laptop, this file won't exist (please be aware that it is
|
||||
quite common for Acer not to fit bluetooth to their laptops - so just because
|
||||
you have a bluetooth button on the laptop, doesn't mean that bluetooth is
|
||||
installed).
|
||||
|
||||
For the adventurously minded - if you want to buy an internal bluetooth
|
||||
module off the internet that is compatible with your laptop and fit it, then
|
||||
it will work just fine with acer-wmi.
|
||||
|
||||
Bluetooth is exposed through rfkill.
|
||||
|
||||
3G
|
||||
**
|
||||
|
||||
3G is currently not autodetected, so the 'threeg' file is always created under
|
||||
sysfs. So far, no-one in possession of an Acer laptop with 3G built-in appears to
|
||||
have tried Linux, or reported back, so we don't have any information on this.
|
||||
|
||||
If you have an Acer laptop that does have a 3G card in, please contact me so we
|
||||
can properly detect these, and find out a bit more about them.
|
||||
|
||||
To read the status of the 3G card (0=off, 1=on):
|
||||
cat /sys/devices/platform/acer-wmi/threeg
|
||||
|
||||
To enable the 3G card:
|
||||
echo 1 > /sys/devices/platform/acer-wmi/threeg
|
||||
|
||||
To disable the 3G card:
|
||||
echo 0 > /sys/devices/platform/acer-wmi/threeg
|
||||
|
||||
To set the state of the 3G card when loading acer-wmi, pass:
|
||||
threeg=X (where X is 0 or 1)
|
||||
|
||||
Mail LED
|
||||
********
|
||||
|
||||
This can be found in most older Acer laptops supported by acer-wmi, and many
|
||||
newer ones - it is built into the 'mail' button, and blinks when active.
|
||||
|
||||
On newer (WMID) laptops though, we have no way of detecting the mail LED. If
|
||||
your laptop identifies itself in dmesg as a WMID model, then please try loading
|
||||
acer_acpi with:
|
||||
|
||||
force_series=2490
|
||||
|
||||
This will use a known alternative method of reading/ writing the mail LED. If
|
||||
it works, please report back to me with the DMI data from your laptop so this
|
||||
can be added to acer-wmi.
|
||||
|
||||
The LED is exposed through the LED subsystem, and can be found in:
|
||||
|
||||
/sys/devices/platform/acer-wmi/leds/acer-wmi::mail/
|
||||
|
||||
The mail LED is autodetected, so if you don't have one, the LED device won't
|
||||
be registered.
|
||||
|
||||
Backlight
|
||||
*********
|
||||
|
||||
The backlight brightness control is available on all acer-wmi supported
|
||||
hardware. The maximum brightness level is usually 15, but on some newer laptops
|
||||
it's 10 (this is again autodetected).
|
||||
|
||||
The backlight is exposed through the backlight subsystem, and can be found in:
|
||||
|
||||
/sys/devices/platform/acer-wmi/backlight/acer-wmi/
|
||||
|
||||
Credits
|
||||
*******
|
||||
|
||||
Olaf Tauber, who did the real hard work when he developed acerhk
|
||||
http://www.cakey.de/acerhk/
|
||||
All the authors of laptop ACPI modules in the kernel, whose work
|
||||
was an inspiration in the early days of acer_acpi
|
||||
Mathieu Segaud, who solved the problem with having to modprobe the driver
|
||||
twice in acer_acpi 0.2.
|
||||
Jim Ramsay, who added support for the WMID interface
|
||||
Mark Smith, who started the original acer_acpi
|
||||
|
||||
And the many people who have used both acer_acpi and acer-wmi.
|
||||
|
|
@ -12,8 +12,9 @@ Because things like lock contention can severely impact performance.
|
|||
- HOW
|
||||
|
||||
Lockdep already has hooks in the lock functions and maps lock instances to
|
||||
lock classes. We build on that. The graph below shows the relation between
|
||||
the lock functions and the various hooks therein.
|
||||
lock classes. We build on that (see Documentation/lockdep-design.txt).
|
||||
The graph below shows the relation between the lock functions and the various
|
||||
hooks therein.
|
||||
|
||||
__acquire
|
||||
|
|
||||
|
|
@ -128,6 +129,37 @@ points are the points we're contending with.
|
|||
|
||||
The integer part of the time values is in us.
|
||||
|
||||
Dealing with nested locks, subclasses may appear:
|
||||
|
||||
32...............................................................................................................................................................................................
|
||||
33
|
||||
34 &rq->lock: 13128 13128 0.43 190.53 103881.26 97454 3453404 0.00 401.11 13224683.11
|
||||
35 ---------
|
||||
36 &rq->lock 645 [<ffffffff8103bfc4>] task_rq_lock+0x43/0x75
|
||||
37 &rq->lock 297 [<ffffffff8104ba65>] try_to_wake_up+0x127/0x25a
|
||||
38 &rq->lock 360 [<ffffffff8103c4c5>] select_task_rq_fair+0x1f0/0x74a
|
||||
39 &rq->lock 428 [<ffffffff81045f98>] scheduler_tick+0x46/0x1fb
|
||||
40 ---------
|
||||
41 &rq->lock 77 [<ffffffff8103bfc4>] task_rq_lock+0x43/0x75
|
||||
42 &rq->lock 174 [<ffffffff8104ba65>] try_to_wake_up+0x127/0x25a
|
||||
43 &rq->lock 4715 [<ffffffff8103ed4b>] double_rq_lock+0x42/0x54
|
||||
44 &rq->lock 893 [<ffffffff81340524>] schedule+0x157/0x7b8
|
||||
45
|
||||
46...............................................................................................................................................................................................
|
||||
47
|
||||
48 &rq->lock/1: 11526 11488 0.33 388.73 136294.31 21461 38404 0.00 37.93 109388.53
|
||||
49 -----------
|
||||
50 &rq->lock/1 11526 [<ffffffff8103ed58>] double_rq_lock+0x4f/0x54
|
||||
51 -----------
|
||||
52 &rq->lock/1 5645 [<ffffffff8103ed4b>] double_rq_lock+0x42/0x54
|
||||
53 &rq->lock/1 1224 [<ffffffff81340524>] schedule+0x157/0x7b8
|
||||
54 &rq->lock/1 4336 [<ffffffff8103ed58>] double_rq_lock+0x4f/0x54
|
||||
55 &rq->lock/1 181 [<ffffffff8104ba65>] try_to_wake_up+0x127/0x25a
|
||||
|
||||
Line 48 shows statistics for the second subclass (/1) of &rq->lock class
|
||||
(subclass starts from 0), since in this case, as line 50 suggests,
|
||||
double_rq_lock actually acquires a nested lock of two spinlocks.
|
||||
|
||||
View the top contending locks:
|
||||
|
||||
# grep : /proc/lock_stat | head
|
||||
|
|
@ -136,7 +168,7 @@ View the top contending locks:
|
|||
dcache_lock: 1037 1161 0.38 45.32 774.51 6611 243371 0.15 306.48 77387.24
|
||||
&inode->i_mutex: 161 286 18446744073709 62882.54 1244614.55 3653 20598 18446744073709 62318.60 1693822.74
|
||||
&zone->lru_lock: 94 94 0.53 7.33 92.10 4366 32690 0.29 59.81 16350.06
|
||||
&inode->i_data.i_mmap_lock: 79 79 0.40 3.77 53.03 11779 87755 0.28 116.93 29898.44
|
||||
&inode->i_data.i_mmap_mutex: 79 79 0.40 3.77 53.03 11779 87755 0.28 116.93 29898.44
|
||||
&q->__queue_lock: 48 50 0.52 31.62 86.31 774 13131 0.17 113.08 12277.52
|
||||
&rq->rq_lock_key: 43 47 0.74 68.50 170.63 3706 33929 0.22 107.99 17460.62
|
||||
&rq->rq_lock_key#2: 39 46 0.75 6.68 49.03 2979 32292 0.17 125.17 17137.63
|
||||
|
|
|
|||
|
|
@ -2,3 +2,5 @@
|
|||
- this file
|
||||
mmc-dev-attrs.txt
|
||||
- info on SD and MMC device attributes
|
||||
mmc-dev-parts.txt
|
||||
- info on SD and MMC device partitions
|
||||
|
|
|
|||
|
|
@ -1,3 +1,13 @@
|
|||
SD and MMC Block Device Attributes
|
||||
==================================
|
||||
|
||||
These attributes are defined for the block devices associated with the
|
||||
SD or MMC device.
|
||||
|
||||
The following attributes are read/write.
|
||||
|
||||
force_ro Enforce read-only access even if write protect switch is off.
|
||||
|
||||
SD and MMC Device Attributes
|
||||
============================
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,27 @@
|
|||
SD and MMC Device Partitions
|
||||
============================
|
||||
|
||||
Device partitions are additional logical block devices present on the
|
||||
SD/MMC device.
|
||||
|
||||
As of this writing, MMC boot partitions as supported and exposed as
|
||||
/dev/mmcblkXboot0 and /dev/mmcblkXboot1, where X is the index of the
|
||||
parent /dev/mmcblkX.
|
||||
|
||||
MMC Boot Partitions
|
||||
===================
|
||||
|
||||
Read and write access is provided to the two MMC boot partitions. Due to
|
||||
the sensitive nature of the boot partition contents, which often store
|
||||
a bootloader or bootloader configuration tables crucial to booting the
|
||||
platform, write access is disabled by default to reduce the chance of
|
||||
accidental bricking.
|
||||
|
||||
To enable write access to /dev/mmcblkXbootY, disable the forced read-only
|
||||
access with:
|
||||
|
||||
echo 0 > /sys/block/mmcblkXbootY/force_ro
|
||||
|
||||
To re-enable read-only access:
|
||||
|
||||
echo 1 > /sys/block/mmcblkXbootY/force_ro
|
||||
|
|
@ -770,8 +770,17 @@ resend_igmp
|
|||
a failover event. One membership report is issued immediately after
|
||||
the failover, subsequent packets are sent in each 200ms interval.
|
||||
|
||||
The valid range is 0 - 255; the default value is 1. This option
|
||||
was added for bonding version 3.7.0.
|
||||
The valid range is 0 - 255; the default value is 1. A value of 0
|
||||
prevents the IGMP membership report from being issued in response
|
||||
to the failover event.
|
||||
|
||||
This option is useful for bonding modes balance-rr (0), active-backup
|
||||
(1), balance-tlb (5) and balance-alb (6), in which a failover can
|
||||
switch the IGMP traffic from one slave to another. Therefore a fresh
|
||||
IGMP report must be issued to cause the switch to forward the incoming
|
||||
IGMP traffic over the newly selected slave.
|
||||
|
||||
This option was added for bonding version 3.7.0.
|
||||
|
||||
3. Configuring Bonding Devices
|
||||
==============================
|
||||
|
|
|
|||
|
|
@ -139,8 +139,8 @@ the key will be discarded and recreated when the data it holds has expired.
|
|||
dns_query() returns a copy of the value attached to the key, or an error if
|
||||
that is indicated instead.
|
||||
|
||||
See <file:Documentation/keys-request-key.txt> for further information about
|
||||
request-key function.
|
||||
See <file:Documentation/security/keys-request-key.txt> for further
|
||||
information about request-key function.
|
||||
|
||||
|
||||
=========
|
||||
|
|
|
|||
|
|
@ -53,11 +53,11 @@ static struct regulator_init_data regulator1_data = {
|
|||
|
||||
Regulator-1 supplies power to Regulator-2. This relationship must be registered
|
||||
with the core so that Regulator-1 is also enabled when Consumer A enables its
|
||||
supply (Regulator-2). The supply regulator is set by the supply_regulator_dev
|
||||
supply (Regulator-2). The supply regulator is set by the supply_regulator
|
||||
field below:-
|
||||
|
||||
static struct regulator_init_data regulator2_data = {
|
||||
.supply_regulator_dev = &platform_regulator1_device.dev,
|
||||
.supply_regulator = "regulator_name",
|
||||
.constraints = {
|
||||
.min_uV = 1800000,
|
||||
.max_uV = 2000000,
|
||||
|
|
|
|||
|
|
@ -0,0 +1,89 @@
|
|||
|
||||
* PTP hardware clock infrastructure for Linux
|
||||
|
||||
This patch set introduces support for IEEE 1588 PTP clocks in
|
||||
Linux. Together with the SO_TIMESTAMPING socket options, this
|
||||
presents a standardized method for developing PTP user space
|
||||
programs, synchronizing Linux with external clocks, and using the
|
||||
ancillary features of PTP hardware clocks.
|
||||
|
||||
A new class driver exports a kernel interface for specific clock
|
||||
drivers and a user space interface. The infrastructure supports a
|
||||
complete set of PTP hardware clock functionality.
|
||||
|
||||
+ Basic clock operations
|
||||
- Set time
|
||||
- Get time
|
||||
- Shift the clock by a given offset atomically
|
||||
- Adjust clock frequency
|
||||
|
||||
+ Ancillary clock features
|
||||
- One short or periodic alarms, with signal delivery to user program
|
||||
- Time stamp external events
|
||||
- Period output signals configurable from user space
|
||||
- Synchronization of the Linux system time via the PPS subsystem
|
||||
|
||||
** PTP hardware clock kernel API
|
||||
|
||||
A PTP clock driver registers itself with the class driver. The
|
||||
class driver handles all of the dealings with user space. The
|
||||
author of a clock driver need only implement the details of
|
||||
programming the clock hardware. The clock driver notifies the class
|
||||
driver of asynchronous events (alarms and external time stamps) via
|
||||
a simple message passing interface.
|
||||
|
||||
The class driver supports multiple PTP clock drivers. In normal use
|
||||
cases, only one PTP clock is needed. However, for testing and
|
||||
development, it can be useful to have more than one clock in a
|
||||
single system, in order to allow performance comparisons.
|
||||
|
||||
** PTP hardware clock user space API
|
||||
|
||||
The class driver also creates a character device for each
|
||||
registered clock. User space can use an open file descriptor from
|
||||
the character device as a POSIX clock id and may call
|
||||
clock_gettime, clock_settime, and clock_adjtime. These calls
|
||||
implement the basic clock operations.
|
||||
|
||||
User space programs may control the clock using standardized
|
||||
ioctls. A program may query, enable, configure, and disable the
|
||||
ancillary clock features. User space can receive time stamped
|
||||
events via blocking read() and poll(). One shot and periodic
|
||||
signals may be configured via the POSIX timer_settime() system
|
||||
call.
|
||||
|
||||
** Writing clock drivers
|
||||
|
||||
Clock drivers include include/linux/ptp_clock_kernel.h and register
|
||||
themselves by presenting a 'struct ptp_clock_info' to the
|
||||
registration method. Clock drivers must implement all of the
|
||||
functions in the interface. If a clock does not offer a particular
|
||||
ancillary feature, then the driver should just return -EOPNOTSUPP
|
||||
from those functions.
|
||||
|
||||
Drivers must ensure that all of the methods in interface are
|
||||
reentrant. Since most hardware implementations treat the time value
|
||||
as a 64 bit integer accessed as two 32 bit registers, drivers
|
||||
should use spin_lock_irqsave/spin_unlock_irqrestore to protect
|
||||
against concurrent access. This locking cannot be accomplished in
|
||||
class driver, since the lock may also be needed by the clock
|
||||
driver's interrupt service routine.
|
||||
|
||||
** Supported hardware
|
||||
|
||||
+ Freescale eTSEC gianfar
|
||||
- 2 Time stamp external triggers, programmable polarity (opt. interrupt)
|
||||
- 2 Alarm registers (optional interrupt)
|
||||
- 3 Periodic signals (optional interrupt)
|
||||
|
||||
+ National DP83640
|
||||
- 6 GPIOs programmable as inputs or outputs
|
||||
- 6 GPIOs with dedicated functions (LED/JTAG/clock) can also be
|
||||
used as general inputs or outputs
|
||||
- GPIO inputs can time stamp external triggers
|
||||
- GPIO outputs can produce periodic signals
|
||||
- 1 interrupt pin
|
||||
|
||||
+ Intel IXP465
|
||||
- Auxiliary Slave/Master Mode Snapshot (optional interrupt)
|
||||
- Target Time (optional interrupt)
|
||||
|
|
@ -0,0 +1,381 @@
|
|||
/*
|
||||
* PTP 1588 clock support - User space test program
|
||||
*
|
||||
* Copyright (C) 2010 OMICRON electronics GmbH
|
||||
*
|
||||
* This program is free software; you can redistribute it and/or modify
|
||||
* it under the terms of the GNU General Public License as published by
|
||||
* the Free Software Foundation; either version 2 of the License, or
|
||||
* (at your option) any later version.
|
||||
*
|
||||
* This program is distributed in the hope that it will be useful,
|
||||
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
* GNU General Public License for more details.
|
||||
*
|
||||
* You should have received a copy of the GNU General Public License
|
||||
* along with this program; if not, write to the Free Software
|
||||
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
|
||||
*/
|
||||
#include <errno.h>
|
||||
#include <fcntl.h>
|
||||
#include <math.h>
|
||||
#include <signal.h>
|
||||
#include <stdio.h>
|
||||
#include <stdlib.h>
|
||||
#include <string.h>
|
||||
#include <sys/ioctl.h>
|
||||
#include <sys/mman.h>
|
||||
#include <sys/stat.h>
|
||||
#include <sys/time.h>
|
||||
#include <sys/timex.h>
|
||||
#include <sys/types.h>
|
||||
#include <time.h>
|
||||
#include <unistd.h>
|
||||
|
||||
#include <linux/ptp_clock.h>
|
||||
|
||||
#define DEVICE "/dev/ptp0"
|
||||
|
||||
#ifndef ADJ_SETOFFSET
|
||||
#define ADJ_SETOFFSET 0x0100
|
||||
#endif
|
||||
|
||||
#ifndef CLOCK_INVALID
|
||||
#define CLOCK_INVALID -1
|
||||
#endif
|
||||
|
||||
/* When glibc offers the syscall, this will go away. */
|
||||
#include <sys/syscall.h>
|
||||
static int clock_adjtime(clockid_t id, struct timex *tx)
|
||||
{
|
||||
return syscall(__NR_clock_adjtime, id, tx);
|
||||
}
|
||||
|
||||
static clockid_t get_clockid(int fd)
|
||||
{
|
||||
#define CLOCKFD 3
|
||||
#define FD_TO_CLOCKID(fd) ((~(clockid_t) (fd) << 3) | CLOCKFD)
|
||||
|
||||
return FD_TO_CLOCKID(fd);
|
||||
}
|
||||
|
||||
static void handle_alarm(int s)
|
||||
{
|
||||
printf("received signal %d\n", s);
|
||||
}
|
||||
|
||||
static int install_handler(int signum, void (*handler)(int))
|
||||
{
|
||||
struct sigaction action;
|
||||
sigset_t mask;
|
||||
|
||||
/* Unblock the signal. */
|
||||
sigemptyset(&mask);
|
||||
sigaddset(&mask, signum);
|
||||
sigprocmask(SIG_UNBLOCK, &mask, NULL);
|
||||
|
||||
/* Install the signal handler. */
|
||||
action.sa_handler = handler;
|
||||
action.sa_flags = 0;
|
||||
sigemptyset(&action.sa_mask);
|
||||
sigaction(signum, &action, NULL);
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
static long ppb_to_scaled_ppm(int ppb)
|
||||
{
|
||||
/*
|
||||
* The 'freq' field in the 'struct timex' is in parts per
|
||||
* million, but with a 16 bit binary fractional field.
|
||||
* Instead of calculating either one of
|
||||
*
|
||||
* scaled_ppm = (ppb / 1000) << 16 [1]
|
||||
* scaled_ppm = (ppb << 16) / 1000 [2]
|
||||
*
|
||||
* we simply use double precision math, in order to avoid the
|
||||
* truncation in [1] and the possible overflow in [2].
|
||||
*/
|
||||
return (long) (ppb * 65.536);
|
||||
}
|
||||
|
||||
static void usage(char *progname)
|
||||
{
|
||||
fprintf(stderr,
|
||||
"usage: %s [options]\n"
|
||||
" -a val request a one-shot alarm after 'val' seconds\n"
|
||||
" -A val request a periodic alarm every 'val' seconds\n"
|
||||
" -c query the ptp clock's capabilities\n"
|
||||
" -d name device to open\n"
|
||||
" -e val read 'val' external time stamp events\n"
|
||||
" -f val adjust the ptp clock frequency by 'val' ppb\n"
|
||||
" -g get the ptp clock time\n"
|
||||
" -h prints this message\n"
|
||||
" -p val enable output with a period of 'val' nanoseconds\n"
|
||||
" -P val enable or disable (val=1|0) the system clock PPS\n"
|
||||
" -s set the ptp clock time from the system time\n"
|
||||
" -S set the system time from the ptp clock time\n"
|
||||
" -t val shift the ptp clock time by 'val' seconds\n",
|
||||
progname);
|
||||
}
|
||||
|
||||
int main(int argc, char *argv[])
|
||||
{
|
||||
struct ptp_clock_caps caps;
|
||||
struct ptp_extts_event event;
|
||||
struct ptp_extts_request extts_request;
|
||||
struct ptp_perout_request perout_request;
|
||||
struct timespec ts;
|
||||
struct timex tx;
|
||||
|
||||
static timer_t timerid;
|
||||
struct itimerspec timeout;
|
||||
struct sigevent sigevent;
|
||||
|
||||
char *progname;
|
||||
int c, cnt, fd;
|
||||
|
||||
char *device = DEVICE;
|
||||
clockid_t clkid;
|
||||
int adjfreq = 0x7fffffff;
|
||||
int adjtime = 0;
|
||||
int capabilities = 0;
|
||||
int extts = 0;
|
||||
int gettime = 0;
|
||||
int oneshot = 0;
|
||||
int periodic = 0;
|
||||
int perout = -1;
|
||||
int pps = -1;
|
||||
int settime = 0;
|
||||
|
||||
progname = strrchr(argv[0], '/');
|
||||
progname = progname ? 1+progname : argv[0];
|
||||
while (EOF != (c = getopt(argc, argv, "a:A:cd:e:f:ghp:P:sSt:v"))) {
|
||||
switch (c) {
|
||||
case 'a':
|
||||
oneshot = atoi(optarg);
|
||||
break;
|
||||
case 'A':
|
||||
periodic = atoi(optarg);
|
||||
break;
|
||||
case 'c':
|
||||
capabilities = 1;
|
||||
break;
|
||||
case 'd':
|
||||
device = optarg;
|
||||
break;
|
||||
case 'e':
|
||||
extts = atoi(optarg);
|
||||
break;
|
||||
case 'f':
|
||||
adjfreq = atoi(optarg);
|
||||
break;
|
||||
case 'g':
|
||||
gettime = 1;
|
||||
break;
|
||||
case 'p':
|
||||
perout = atoi(optarg);
|
||||
break;
|
||||
case 'P':
|
||||
pps = atoi(optarg);
|
||||
break;
|
||||
case 's':
|
||||
settime = 1;
|
||||
break;
|
||||
case 'S':
|
||||
settime = 2;
|
||||
break;
|
||||
case 't':
|
||||
adjtime = atoi(optarg);
|
||||
break;
|
||||
case 'h':
|
||||
usage(progname);
|
||||
return 0;
|
||||
case '?':
|
||||
default:
|
||||
usage(progname);
|
||||
return -1;
|
||||
}
|
||||
}
|
||||
|
||||
fd = open(device, O_RDWR);
|
||||
if (fd < 0) {
|
||||
fprintf(stderr, "opening %s: %s\n", device, strerror(errno));
|
||||
return -1;
|
||||
}
|
||||
|
||||
clkid = get_clockid(fd);
|
||||
if (CLOCK_INVALID == clkid) {
|
||||
fprintf(stderr, "failed to read clock id\n");
|
||||
return -1;
|
||||
}
|
||||
|
||||
if (capabilities) {
|
||||
if (ioctl(fd, PTP_CLOCK_GETCAPS, &caps)) {
|
||||
perror("PTP_CLOCK_GETCAPS");
|
||||
} else {
|
||||
printf("capabilities:\n"
|
||||
" %d maximum frequency adjustment (ppb)\n"
|
||||
" %d programmable alarms\n"
|
||||
" %d external time stamp channels\n"
|
||||
" %d programmable periodic signals\n"
|
||||
" %d pulse per second\n",
|
||||
caps.max_adj,
|
||||
caps.n_alarm,
|
||||
caps.n_ext_ts,
|
||||
caps.n_per_out,
|
||||
caps.pps);
|
||||
}
|
||||
}
|
||||
|
||||
if (0x7fffffff != adjfreq) {
|
||||
memset(&tx, 0, sizeof(tx));
|
||||
tx.modes = ADJ_FREQUENCY;
|
||||
tx.freq = ppb_to_scaled_ppm(adjfreq);
|
||||
if (clock_adjtime(clkid, &tx)) {
|
||||
perror("clock_adjtime");
|
||||
} else {
|
||||
puts("frequency adjustment okay");
|
||||
}
|
||||
}
|
||||
|
||||
if (adjtime) {
|
||||
memset(&tx, 0, sizeof(tx));
|
||||
tx.modes = ADJ_SETOFFSET;
|
||||
tx.time.tv_sec = adjtime;
|
||||
tx.time.tv_usec = 0;
|
||||
if (clock_adjtime(clkid, &tx) < 0) {
|
||||
perror("clock_adjtime");
|
||||
} else {
|
||||
puts("time shift okay");
|
||||
}
|
||||
}
|
||||
|
||||
if (gettime) {
|
||||
if (clock_gettime(clkid, &ts)) {
|
||||
perror("clock_gettime");
|
||||
} else {
|
||||
printf("clock time: %ld.%09ld or %s",
|
||||
ts.tv_sec, ts.tv_nsec, ctime(&ts.tv_sec));
|
||||
}
|
||||
}
|
||||
|
||||
if (settime == 1) {
|
||||
clock_gettime(CLOCK_REALTIME, &ts);
|
||||
if (clock_settime(clkid, &ts)) {
|
||||
perror("clock_settime");
|
||||
} else {
|
||||
puts("set time okay");
|
||||
}
|
||||
}
|
||||
|
||||
if (settime == 2) {
|
||||
clock_gettime(clkid, &ts);
|
||||
if (clock_settime(CLOCK_REALTIME, &ts)) {
|
||||
perror("clock_settime");
|
||||
} else {
|
||||
puts("set time okay");
|
||||
}
|
||||
}
|
||||
|
||||
if (extts) {
|
||||
memset(&extts_request, 0, sizeof(extts_request));
|
||||
extts_request.index = 0;
|
||||
extts_request.flags = PTP_ENABLE_FEATURE;
|
||||
if (ioctl(fd, PTP_EXTTS_REQUEST, &extts_request)) {
|
||||
perror("PTP_EXTTS_REQUEST");
|
||||
extts = 0;
|
||||
} else {
|
||||
puts("external time stamp request okay");
|
||||
}
|
||||
for (; extts; extts--) {
|
||||
cnt = read(fd, &event, sizeof(event));
|
||||
if (cnt != sizeof(event)) {
|
||||
perror("read");
|
||||
break;
|
||||
}
|
||||
printf("event index %u at %lld.%09u\n", event.index,
|
||||
event.t.sec, event.t.nsec);
|
||||
fflush(stdout);
|
||||
}
|
||||
/* Disable the feature again. */
|
||||
extts_request.flags = 0;
|
||||
if (ioctl(fd, PTP_EXTTS_REQUEST, &extts_request)) {
|
||||
perror("PTP_EXTTS_REQUEST");
|
||||
}
|
||||
}
|
||||
|
||||
if (oneshot) {
|
||||
install_handler(SIGALRM, handle_alarm);
|
||||
/* Create a timer. */
|
||||
sigevent.sigev_notify = SIGEV_SIGNAL;
|
||||
sigevent.sigev_signo = SIGALRM;
|
||||
if (timer_create(clkid, &sigevent, &timerid)) {
|
||||
perror("timer_create");
|
||||
return -1;
|
||||
}
|
||||
/* Start the timer. */
|
||||
memset(&timeout, 0, sizeof(timeout));
|
||||
timeout.it_value.tv_sec = oneshot;
|
||||
if (timer_settime(timerid, 0, &timeout, NULL)) {
|
||||
perror("timer_settime");
|
||||
return -1;
|
||||
}
|
||||
pause();
|
||||
timer_delete(timerid);
|
||||
}
|
||||
|
||||
if (periodic) {
|
||||
install_handler(SIGALRM, handle_alarm);
|
||||
/* Create a timer. */
|
||||
sigevent.sigev_notify = SIGEV_SIGNAL;
|
||||
sigevent.sigev_signo = SIGALRM;
|
||||
if (timer_create(clkid, &sigevent, &timerid)) {
|
||||
perror("timer_create");
|
||||
return -1;
|
||||
}
|
||||
/* Start the timer. */
|
||||
memset(&timeout, 0, sizeof(timeout));
|
||||
timeout.it_interval.tv_sec = periodic;
|
||||
timeout.it_value.tv_sec = periodic;
|
||||
if (timer_settime(timerid, 0, &timeout, NULL)) {
|
||||
perror("timer_settime");
|
||||
return -1;
|
||||
}
|
||||
while (1) {
|
||||
pause();
|
||||
}
|
||||
timer_delete(timerid);
|
||||
}
|
||||
|
||||
if (perout >= 0) {
|
||||
if (clock_gettime(clkid, &ts)) {
|
||||
perror("clock_gettime");
|
||||
return -1;
|
||||
}
|
||||
memset(&perout_request, 0, sizeof(perout_request));
|
||||
perout_request.index = 0;
|
||||
perout_request.start.sec = ts.tv_sec + 2;
|
||||
perout_request.start.nsec = 0;
|
||||
perout_request.period.sec = 0;
|
||||
perout_request.period.nsec = perout;
|
||||
if (ioctl(fd, PTP_PEROUT_REQUEST, &perout_request)) {
|
||||
perror("PTP_PEROUT_REQUEST");
|
||||
} else {
|
||||
puts("periodic output request okay");
|
||||
}
|
||||
}
|
||||
|
||||
if (pps != -1) {
|
||||
int enable = pps ? 1 : 0;
|
||||
if (ioctl(fd, PTP_ENABLE_PPS, enable)) {
|
||||
perror("PTP_ENABLE_PPS");
|
||||
} else {
|
||||
puts("pps for system time request okay");
|
||||
}
|
||||
}
|
||||
|
||||
close(fd);
|
||||
return 0;
|
||||
}
|
||||
|
|
@ -0,0 +1,33 @@
|
|||
# PTP 1588 clock support - User space test program
|
||||
#
|
||||
# Copyright (C) 2010 OMICRON electronics GmbH
|
||||
#
|
||||
# This program is free software; you can redistribute it and/or modify
|
||||
# it under the terms of the GNU General Public License as published by
|
||||
# the Free Software Foundation; either version 2 of the License, or
|
||||
# (at your option) any later version.
|
||||
#
|
||||
# This program is distributed in the hope that it will be useful,
|
||||
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
# GNU General Public License for more details.
|
||||
#
|
||||
# You should have received a copy of the GNU General Public License
|
||||
# along with this program; if not, write to the Free Software
|
||||
# Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
|
||||
|
||||
CC = $(CROSS_COMPILE)gcc
|
||||
INC = -I$(KBUILD_OUTPUT)/usr/include
|
||||
CFLAGS = -Wall $(INC)
|
||||
LDLIBS = -lrt
|
||||
PROGS = testptp
|
||||
|
||||
all: $(PROGS)
|
||||
|
||||
testptp: testptp.o
|
||||
|
||||
clean:
|
||||
rm -f testptp.o
|
||||
|
||||
distclean: clean
|
||||
rm -f $(PROGS)
|
||||
|
|
@ -1,3 +1,17 @@
|
|||
Release Date : Wed. May 11, 2011 17:00:00 PST 2010 -
|
||||
(emaild-id:megaraidlinux@lsi.com)
|
||||
Adam Radford
|
||||
Current Version : 00.00.05.38-rc1
|
||||
Old Version : 00.00.05.34-rc1
|
||||
1. Remove MSI-X black list, use MFI_REG_STATE.ready.msiEnable.
|
||||
2. Remove un-used function megasas_return_cmd_for_smid().
|
||||
3. Check MFI_REG_STATE.fault.resetAdapter in megasas_reset_fusion().
|
||||
4. Disable interrupts/free_irq() in megasas_shutdown().
|
||||
5. Fix bug where AENs could be lost in probe() and resume().
|
||||
6. Convert 6,10,12 byte CDB's to 16 byte CDB for large LBA's for FastPath
|
||||
IO.
|
||||
7. Add 1078 OCR support.
|
||||
-------------------------------------------------------------------------------
|
||||
Release Date : Thu. Feb 24, 2011 17:00:00 PST 2010 -
|
||||
(emaild-id:megaraidlinux@lsi.com)
|
||||
Adam Radford
|
||||
|
|
|
|||
|
|
@ -0,0 +1,18 @@
|
|||
00-INDEX
|
||||
- this file.
|
||||
SELinux.txt
|
||||
- how to get started with the SELinux security enhancement.
|
||||
Smack.txt
|
||||
- documentation on the Smack Linux Security Module.
|
||||
apparmor.txt
|
||||
- documentation on the AppArmor security extension.
|
||||
credentials.txt
|
||||
- documentation about credentials in Linux.
|
||||
keys-request-key.txt
|
||||
- description of the kernel key request service.
|
||||
keys-trusted-encrypted.txt
|
||||
- info on the Trusted and Encrypted keys in the kernel key ring service.
|
||||
keys.txt
|
||||
- description of the kernel key retention service.
|
||||
tomoyo.txt
|
||||
- documentation on the TOMOYO Linux Security Module.
|
||||
|
|
@ -216,7 +216,7 @@ The Linux kernel supports the following types of credentials:
|
|||
When a process accesses a key, if not already present, it will normally be
|
||||
cached on one of these keyrings for future accesses to find.
|
||||
|
||||
For more information on using keys, see Documentation/keys.txt.
|
||||
For more information on using keys, see Documentation/security/keys.txt.
|
||||
|
||||
(5) LSM
|
||||
|
||||
|
|
@ -3,8 +3,8 @@
|
|||
===================
|
||||
|
||||
The key request service is part of the key retention service (refer to
|
||||
Documentation/keys.txt). This document explains more fully how the requesting
|
||||
algorithm works.
|
||||
Documentation/security/keys.txt). This document explains more fully how
|
||||
the requesting algorithm works.
|
||||
|
||||
The process starts by either the kernel requesting a service by calling
|
||||
request_key*():
|
||||
|
|
@ -434,7 +434,7 @@ The main syscalls are:
|
|||
/sbin/request-key will be invoked in an attempt to obtain a key. The
|
||||
callout_info string will be passed as an argument to the program.
|
||||
|
||||
See also Documentation/keys-request-key.txt.
|
||||
See also Documentation/security/keys-request-key.txt.
|
||||
|
||||
|
||||
The keyctl syscall functions are:
|
||||
|
|
@ -864,7 +864,7 @@ payload contents" for more information.
|
|||
If successful, the key will have been attached to the default keyring for
|
||||
implicitly obtained request-key keys, as set by KEYCTL_SET_REQKEY_KEYRING.
|
||||
|
||||
See also Documentation/keys-request-key.txt.
|
||||
See also Documentation/security/keys-request-key.txt.
|
||||
|
||||
|
||||
(*) To search for a key, passing auxiliary data to the upcaller, call:
|
||||
|
|
@ -161,7 +161,8 @@ core_pattern is used to specify a core dumpfile pattern name.
|
|||
%s signal number
|
||||
%t UNIX time of dump
|
||||
%h hostname
|
||||
%e executable filename
|
||||
%e executable filename (may be shortened)
|
||||
%E executable path
|
||||
%<OTHER> both are dropped
|
||||
. If the first character of the pattern is a '|', the kernel will treat
|
||||
the rest of the pattern as a command to run. The core dump will be
|
||||
|
|
|
|||
|
|
@ -1182,6 +1182,16 @@
|
|||
forge.net/> and explains these in detail, as well as
|
||||
some other issues.
|
||||
|
||||
There is also a related point-to-point only "ucast" transport.
|
||||
This is useful when your network does not support multicast, and
|
||||
all network connections are simple point to point links.
|
||||
|
||||
The full set of command line options for this transport are
|
||||
|
||||
|
||||
ethn=ucast,ethernet address,remote address,listen port,remote port
|
||||
|
||||
|
||||
|
||||
|
||||
66..66.. TTUUNN//TTAAPP wwiitthh tthhee uummll__nneett hheellppeerr
|
||||
|
|
|
|||
|
|
@ -0,0 +1,278 @@
|
|||
MOTIVATION
|
||||
|
||||
Cleancache is a new optional feature provided by the VFS layer that
|
||||
potentially dramatically increases page cache effectiveness for
|
||||
many workloads in many environments at a negligible cost.
|
||||
|
||||
Cleancache can be thought of as a page-granularity victim cache for clean
|
||||
pages that the kernel's pageframe replacement algorithm (PFRA) would like
|
||||
to keep around, but can't since there isn't enough memory. So when the
|
||||
PFRA "evicts" a page, it first attempts to use cleancache code to
|
||||
put the data contained in that page into "transcendent memory", memory
|
||||
that is not directly accessible or addressable by the kernel and is
|
||||
of unknown and possibly time-varying size.
|
||||
|
||||
Later, when a cleancache-enabled filesystem wishes to access a page
|
||||
in a file on disk, it first checks cleancache to see if it already
|
||||
contains it; if it does, the page of data is copied into the kernel
|
||||
and a disk access is avoided.
|
||||
|
||||
Transcendent memory "drivers" for cleancache are currently implemented
|
||||
in Xen (using hypervisor memory) and zcache (using in-kernel compressed
|
||||
memory) and other implementations are in development.
|
||||
|
||||
FAQs are included below.
|
||||
|
||||
IMPLEMENTATION OVERVIEW
|
||||
|
||||
A cleancache "backend" that provides transcendent memory registers itself
|
||||
to the kernel's cleancache "frontend" by calling cleancache_register_ops,
|
||||
passing a pointer to a cleancache_ops structure with funcs set appropriately.
|
||||
Note that cleancache_register_ops returns the previous settings so that
|
||||
chaining can be performed if desired. The functions provided must conform to
|
||||
certain semantics as follows:
|
||||
|
||||
Most important, cleancache is "ephemeral". Pages which are copied into
|
||||
cleancache have an indefinite lifetime which is completely unknowable
|
||||
by the kernel and so may or may not still be in cleancache at any later time.
|
||||
Thus, as its name implies, cleancache is not suitable for dirty pages.
|
||||
Cleancache has complete discretion over what pages to preserve and what
|
||||
pages to discard and when.
|
||||
|
||||
Mounting a cleancache-enabled filesystem should call "init_fs" to obtain a
|
||||
pool id which, if positive, must be saved in the filesystem's superblock;
|
||||
a negative return value indicates failure. A "put_page" will copy a
|
||||
(presumably about-to-be-evicted) page into cleancache and associate it with
|
||||
the pool id, a file key, and a page index into the file. (The combination
|
||||
of a pool id, a file key, and an index is sometimes called a "handle".)
|
||||
A "get_page" will copy the page, if found, from cleancache into kernel memory.
|
||||
A "flush_page" will ensure the page no longer is present in cleancache;
|
||||
a "flush_inode" will flush all pages associated with the specified file;
|
||||
and, when a filesystem is unmounted, a "flush_fs" will flush all pages in
|
||||
all files specified by the given pool id and also surrender the pool id.
|
||||
|
||||
An "init_shared_fs", like init_fs, obtains a pool id but tells cleancache
|
||||
to treat the pool as shared using a 128-bit UUID as a key. On systems
|
||||
that may run multiple kernels (such as hard partitioned or virtualized
|
||||
systems) that may share a clustered filesystem, and where cleancache
|
||||
may be shared among those kernels, calls to init_shared_fs that specify the
|
||||
same UUID will receive the same pool id, thus allowing the pages to
|
||||
be shared. Note that any security requirements must be imposed outside
|
||||
of the kernel (e.g. by "tools" that control cleancache). Or a
|
||||
cleancache implementation can simply disable shared_init by always
|
||||
returning a negative value.
|
||||
|
||||
If a get_page is successful on a non-shared pool, the page is flushed (thus
|
||||
making cleancache an "exclusive" cache). On a shared pool, the page
|
||||
is NOT flushed on a successful get_page so that it remains accessible to
|
||||
other sharers. The kernel is responsible for ensuring coherency between
|
||||
cleancache (shared or not), the page cache, and the filesystem, using
|
||||
cleancache flush operations as required.
|
||||
|
||||
Note that cleancache must enforce put-put-get coherency and get-get
|
||||
coherency. For the former, if two puts are made to the same handle but
|
||||
with different data, say AAA by the first put and BBB by the second, a
|
||||
subsequent get can never return the stale data (AAA). For get-get coherency,
|
||||
if a get for a given handle fails, subsequent gets for that handle will
|
||||
never succeed unless preceded by a successful put with that handle.
|
||||
|
||||
Last, cleancache provides no SMP serialization guarantees; if two
|
||||
different Linux threads are simultaneously putting and flushing a page
|
||||
with the same handle, the results are indeterminate. Callers must
|
||||
lock the page to ensure serial behavior.
|
||||
|
||||
CLEANCACHE PERFORMANCE METRICS
|
||||
|
||||
Cleancache monitoring is done by sysfs files in the
|
||||
/sys/kernel/mm/cleancache directory. The effectiveness of cleancache
|
||||
can be measured (across all filesystems) with:
|
||||
|
||||
succ_gets - number of gets that were successful
|
||||
failed_gets - number of gets that failed
|
||||
puts - number of puts attempted (all "succeed")
|
||||
flushes - number of flushes attempted
|
||||
|
||||
A backend implementatation may provide additional metrics.
|
||||
|
||||
FAQ
|
||||
|
||||
1) Where's the value? (Andrew Morton)
|
||||
|
||||
Cleancache provides a significant performance benefit to many workloads
|
||||
in many environments with negligible overhead by improving the
|
||||
effectiveness of the pagecache. Clean pagecache pages are
|
||||
saved in transcendent memory (RAM that is otherwise not directly
|
||||
addressable to the kernel); fetching those pages later avoids "refaults"
|
||||
and thus disk reads.
|
||||
|
||||
Cleancache (and its sister code "frontswap") provide interfaces for
|
||||
this transcendent memory (aka "tmem"), which conceptually lies between
|
||||
fast kernel-directly-addressable RAM and slower DMA/asynchronous devices.
|
||||
Disallowing direct kernel or userland reads/writes to tmem
|
||||
is ideal when data is transformed to a different form and size (such
|
||||
as with compression) or secretly moved (as might be useful for write-
|
||||
balancing for some RAM-like devices). Evicted page-cache pages (and
|
||||
swap pages) are a great use for this kind of slower-than-RAM-but-much-
|
||||
faster-than-disk transcendent memory, and the cleancache (and frontswap)
|
||||
"page-object-oriented" specification provides a nice way to read and
|
||||
write -- and indirectly "name" -- the pages.
|
||||
|
||||
In the virtual case, the whole point of virtualization is to statistically
|
||||
multiplex physical resources across the varying demands of multiple
|
||||
virtual machines. This is really hard to do with RAM and efforts to
|
||||
do it well with no kernel change have essentially failed (except in some
|
||||
well-publicized special-case workloads). Cleancache -- and frontswap --
|
||||
with a fairly small impact on the kernel, provide a huge amount
|
||||
of flexibility for more dynamic, flexible RAM multiplexing.
|
||||
Specifically, the Xen Transcendent Memory backend allows otherwise
|
||||
"fallow" hypervisor-owned RAM to not only be "time-shared" between multiple
|
||||
virtual machines, but the pages can be compressed and deduplicated to
|
||||
optimize RAM utilization. And when guest OS's are induced to surrender
|
||||
underutilized RAM (e.g. with "self-ballooning"), page cache pages
|
||||
are the first to go, and cleancache allows those pages to be
|
||||
saved and reclaimed if overall host system memory conditions allow.
|
||||
|
||||
And the identical interface used for cleancache can be used in
|
||||
physical systems as well. The zcache driver acts as a memory-hungry
|
||||
device that stores pages of data in a compressed state. And
|
||||
the proposed "RAMster" driver shares RAM across multiple physical
|
||||
systems.
|
||||
|
||||
2) Why does cleancache have its sticky fingers so deep inside the
|
||||
filesystems and VFS? (Andrew Morton and Christoph Hellwig)
|
||||
|
||||
The core hooks for cleancache in VFS are in most cases a single line
|
||||
and the minimum set are placed precisely where needed to maintain
|
||||
coherency (via cleancache_flush operations) between cleancache,
|
||||
the page cache, and disk. All hooks compile into nothingness if
|
||||
cleancache is config'ed off and turn into a function-pointer-
|
||||
compare-to-NULL if config'ed on but no backend claims the ops
|
||||
functions, or to a compare-struct-element-to-negative if a
|
||||
backend claims the ops functions but a filesystem doesn't enable
|
||||
cleancache.
|
||||
|
||||
Some filesystems are built entirely on top of VFS and the hooks
|
||||
in VFS are sufficient, so don't require an "init_fs" hook; the
|
||||
initial implementation of cleancache didn't provide this hook.
|
||||
But for some filesystems (such as btrfs), the VFS hooks are
|
||||
incomplete and one or more hooks in fs-specific code are required.
|
||||
And for some other filesystems, such as tmpfs, cleancache may
|
||||
be counterproductive. So it seemed prudent to require a filesystem
|
||||
to "opt in" to use cleancache, which requires adding a hook in
|
||||
each filesystem. Not all filesystems are supported by cleancache
|
||||
only because they haven't been tested. The existing set should
|
||||
be sufficient to validate the concept, the opt-in approach means
|
||||
that untested filesystems are not affected, and the hooks in the
|
||||
existing filesystems should make it very easy to add more
|
||||
filesystems in the future.
|
||||
|
||||
The total impact of the hooks to existing fs and mm files is only
|
||||
about 40 lines added (not counting comments and blank lines).
|
||||
|
||||
3) Why not make cleancache asynchronous and batched so it can
|
||||
more easily interface with real devices with DMA instead
|
||||
of copying each individual page? (Minchan Kim)
|
||||
|
||||
The one-page-at-a-time copy semantics simplifies the implementation
|
||||
on both the frontend and backend and also allows the backend to
|
||||
do fancy things on-the-fly like page compression and
|
||||
page deduplication. And since the data is "gone" (copied into/out
|
||||
of the pageframe) before the cleancache get/put call returns,
|
||||
a great deal of race conditions and potential coherency issues
|
||||
are avoided. While the interface seems odd for a "real device"
|
||||
or for real kernel-addressable RAM, it makes perfect sense for
|
||||
transcendent memory.
|
||||
|
||||
4) Why is non-shared cleancache "exclusive"? And where is the
|
||||
page "flushed" after a "get"? (Minchan Kim)
|
||||
|
||||
The main reason is to free up space in transcendent memory and
|
||||
to avoid unnecessary cleancache_flush calls. If you want inclusive,
|
||||
the page can be "put" immediately following the "get". If
|
||||
put-after-get for inclusive becomes common, the interface could
|
||||
be easily extended to add a "get_no_flush" call.
|
||||
|
||||
The flush is done by the cleancache backend implementation.
|
||||
|
||||
5) What's the performance impact?
|
||||
|
||||
Performance analysis has been presented at OLS'09 and LCA'10.
|
||||
Briefly, performance gains can be significant on most workloads,
|
||||
especially when memory pressure is high (e.g. when RAM is
|
||||
overcommitted in a virtual workload); and because the hooks are
|
||||
invoked primarily in place of or in addition to a disk read/write,
|
||||
overhead is negligible even in worst case workloads. Basically
|
||||
cleancache replaces I/O with memory-copy-CPU-overhead; on older
|
||||
single-core systems with slow memory-copy speeds, cleancache
|
||||
has little value, but in newer multicore machines, especially
|
||||
consolidated/virtualized machines, it has great value.
|
||||
|
||||
6) How do I add cleancache support for filesystem X? (Boaz Harrash)
|
||||
|
||||
Filesystems that are well-behaved and conform to certain
|
||||
restrictions can utilize cleancache simply by making a call to
|
||||
cleancache_init_fs at mount time. Unusual, misbehaving, or
|
||||
poorly layered filesystems must either add additional hooks
|
||||
and/or undergo extensive additional testing... or should just
|
||||
not enable the optional cleancache.
|
||||
|
||||
Some points for a filesystem to consider:
|
||||
|
||||
- The FS should be block-device-based (e.g. a ram-based FS such
|
||||
as tmpfs should not enable cleancache)
|
||||
- To ensure coherency/correctness, the FS must ensure that all
|
||||
file removal or truncation operations either go through VFS or
|
||||
add hooks to do the equivalent cleancache "flush" operations
|
||||
- To ensure coherency/correctness, either inode numbers must
|
||||
be unique across the lifetime of the on-disk file OR the
|
||||
FS must provide an "encode_fh" function.
|
||||
- The FS must call the VFS superblock alloc and deactivate routines
|
||||
or add hooks to do the equivalent cleancache calls done there.
|
||||
- To maximize performance, all pages fetched from the FS should
|
||||
go through the do_mpag_readpage routine or the FS should add
|
||||
hooks to do the equivalent (cf. btrfs)
|
||||
- Currently, the FS blocksize must be the same as PAGESIZE. This
|
||||
is not an architectural restriction, but no backends currently
|
||||
support anything different.
|
||||
- A clustered FS should invoke the "shared_init_fs" cleancache
|
||||
hook to get best performance for some backends.
|
||||
|
||||
7) Why not use the KVA of the inode as the key? (Christoph Hellwig)
|
||||
|
||||
If cleancache would use the inode virtual address instead of
|
||||
inode/filehandle, the pool id could be eliminated. But, this
|
||||
won't work because cleancache retains pagecache data pages
|
||||
persistently even when the inode has been pruned from the
|
||||
inode unused list, and only flushes the data page if the file
|
||||
gets removed/truncated. So if cleancache used the inode kva,
|
||||
there would be potential coherency issues if/when the inode
|
||||
kva is reused for a different file. Alternately, if cleancache
|
||||
flushed the pages when the inode kva was freed, much of the value
|
||||
of cleancache would be lost because the cache of pages in cleanache
|
||||
is potentially much larger than the kernel pagecache and is most
|
||||
useful if the pages survive inode cache removal.
|
||||
|
||||
8) Why is a global variable required?
|
||||
|
||||
The cleancache_enabled flag is checked in all of the frequently-used
|
||||
cleancache hooks. The alternative is a function call to check a static
|
||||
variable. Since cleancache is enabled dynamically at runtime, systems
|
||||
that don't enable cleancache would suffer thousands (possibly
|
||||
tens-of-thousands) of unnecessary function calls per second. So the
|
||||
global variable allows cleancache to be enabled by default at compile
|
||||
time, but have insignificant performance impact when cleancache remains
|
||||
disabled at runtime.
|
||||
|
||||
9) Does cleanache work with KVM?
|
||||
|
||||
The memory model of KVM is sufficiently different that a cleancache
|
||||
backend may have less value for KVM. This remains to be tested,
|
||||
especially in an overcommitted system.
|
||||
|
||||
10) Does cleancache work in userspace? It sounds useful for
|
||||
memory hungry caches like web browsers. (Jamie Lokier)
|
||||
|
||||
No plans yet, though we agree it sounds useful, at least for
|
||||
apps that bypass the page cache (e.g. O_DIRECT).
|
||||
|
||||
Last updated: Dan Magenheimer, April 13 2011
|
||||
|
|
@ -66,7 +66,7 @@ in some cases it is not really needed. Eg, vm_start is modified by
|
|||
expand_stack(), it is hard to come up with a destructive scenario without
|
||||
having the vmlist protection in this case.
|
||||
|
||||
The page_table_lock nests with the inode i_mmap_lock and the kmem cache
|
||||
The page_table_lock nests with the inode i_mmap_mutex and the kmem cache
|
||||
c_spinlock spinlocks. This is okay, since the kmem code asks for pages after
|
||||
dropping c_spinlock. The page_table_lock also nests with pagecache_lock and
|
||||
pagemap_lru_lock spinlocks, and no code asks for memory with these locks
|
||||
|
|
|
|||
116
MAINTAINERS
116
MAINTAINERS
|
|
@ -223,10 +223,8 @@ S: Maintained
|
|||
F: drivers/platform/x86/acerhdf.c
|
||||
|
||||
ACER WMI LAPTOP EXTRAS
|
||||
M: Carlos Corbacho <carlos@strangeworlds.co.uk>
|
||||
L: aceracpi@googlegroups.com (subscribers-only)
|
||||
M: Joey Lee <jlee@novell.com>
|
||||
L: platform-driver-x86@vger.kernel.org
|
||||
W: http://code.google.com/p/aceracpi
|
||||
S: Maintained
|
||||
F: drivers/platform/x86/acer-wmi.c
|
||||
|
||||
|
|
@ -271,10 +269,8 @@ S: Supported
|
|||
F: drivers/acpi/video.c
|
||||
|
||||
ACPI WMI DRIVER
|
||||
M: Carlos Corbacho <carlos@strangeworlds.co.uk>
|
||||
L: platform-driver-x86@vger.kernel.org
|
||||
W: http://www.lesswatts.org/projects/acpi/
|
||||
S: Maintained
|
||||
S: Orphan
|
||||
F: drivers/platform/x86/wmi.c
|
||||
|
||||
AD1889 ALSA SOUND DRIVER
|
||||
|
|
@ -287,35 +283,35 @@ F: sound/pci/ad1889.*
|
|||
|
||||
AD525X ANALOG DEVICES DIGITAL POTENTIOMETERS DRIVER
|
||||
M: Michael Hennerich <michael.hennerich@analog.com>
|
||||
L: device-driver-devel@blackfin.uclinux.org
|
||||
L: device-drivers-devel@blackfin.uclinux.org
|
||||
W: http://wiki.analog.com/AD5254
|
||||
S: Supported
|
||||
F: drivers/misc/ad525x_dpot.c
|
||||
|
||||
AD5398 CURRENT REGULATOR DRIVER (AD5398/AD5821)
|
||||
M: Michael Hennerich <michael.hennerich@analog.com>
|
||||
L: device-driver-devel@blackfin.uclinux.org
|
||||
L: device-drivers-devel@blackfin.uclinux.org
|
||||
W: http://wiki.analog.com/AD5398
|
||||
S: Supported
|
||||
F: drivers/regulator/ad5398.c
|
||||
|
||||
AD714X CAPACITANCE TOUCH SENSOR DRIVER (AD7142/3/7/8/7A)
|
||||
M: Michael Hennerich <michael.hennerich@analog.com>
|
||||
L: device-driver-devel@blackfin.uclinux.org
|
||||
L: device-drivers-devel@blackfin.uclinux.org
|
||||
W: http://wiki.analog.com/AD7142
|
||||
S: Supported
|
||||
F: drivers/input/misc/ad714x.c
|
||||
|
||||
AD7877 TOUCHSCREEN DRIVER
|
||||
M: Michael Hennerich <michael.hennerich@analog.com>
|
||||
L: device-driver-devel@blackfin.uclinux.org
|
||||
L: device-drivers-devel@blackfin.uclinux.org
|
||||
W: http://wiki.analog.com/AD7877
|
||||
S: Supported
|
||||
F: drivers/input/touchscreen/ad7877.c
|
||||
|
||||
AD7879 TOUCHSCREEN DRIVER (AD7879/AD7889)
|
||||
M: Michael Hennerich <michael.hennerich@analog.com>
|
||||
L: device-driver-devel@blackfin.uclinux.org
|
||||
L: device-drivers-devel@blackfin.uclinux.org
|
||||
W: http://wiki.analog.com/AD7879
|
||||
S: Supported
|
||||
F: drivers/input/touchscreen/ad7879.c
|
||||
|
|
@ -341,7 +337,7 @@ F: drivers/net/wireless/adm8211.*
|
|||
|
||||
ADP5520 BACKLIGHT DRIVER WITH IO EXPANDER (ADP5520/ADP5501)
|
||||
M: Michael Hennerich <michael.hennerich@analog.com>
|
||||
L: device-driver-devel@blackfin.uclinux.org
|
||||
L: device-drivers-devel@blackfin.uclinux.org
|
||||
W: http://wiki.analog.com/ADP5520
|
||||
S: Supported
|
||||
F: drivers/mfd/adp5520.c
|
||||
|
|
@ -352,7 +348,7 @@ F: drivers/input/keyboard/adp5520-keys.c
|
|||
|
||||
ADP5588 QWERTY KEYPAD AND IO EXPANDER DRIVER (ADP5588/ADP5587)
|
||||
M: Michael Hennerich <michael.hennerich@analog.com>
|
||||
L: device-driver-devel@blackfin.uclinux.org
|
||||
L: device-drivers-devel@blackfin.uclinux.org
|
||||
W: http://wiki.analog.com/ADP5588
|
||||
S: Supported
|
||||
F: drivers/input/keyboard/adp5588-keys.c
|
||||
|
|
@ -360,7 +356,7 @@ F: drivers/gpio/adp5588-gpio.c
|
|||
|
||||
ADP8860 BACKLIGHT DRIVER (ADP8860/ADP8861/ADP8863)
|
||||
M: Michael Hennerich <michael.hennerich@analog.com>
|
||||
L: device-driver-devel@blackfin.uclinux.org
|
||||
L: device-drivers-devel@blackfin.uclinux.org
|
||||
W: http://wiki.analog.com/ADP8860
|
||||
S: Supported
|
||||
F: drivers/video/backlight/adp8860_bl.c
|
||||
|
|
@ -387,7 +383,7 @@ F: drivers/hwmon/adt7475.c
|
|||
|
||||
ADXL34X THREE-AXIS DIGITAL ACCELEROMETER DRIVER (ADXL345/ADXL346)
|
||||
M: Michael Hennerich <michael.hennerich@analog.com>
|
||||
L: device-driver-devel@blackfin.uclinux.org
|
||||
L: device-drivers-devel@blackfin.uclinux.org
|
||||
W: http://wiki.analog.com/ADXL345
|
||||
S: Supported
|
||||
F: drivers/input/misc/adxl34x.c
|
||||
|
|
@ -483,6 +479,13 @@ F: drivers/tty/serial/altera_jtaguart.c
|
|||
F: include/linux/altera_uart.h
|
||||
F: include/linux/altera_jtaguart.h
|
||||
|
||||
AMD FAM15H PROCESSOR POWER MONITORING DRIVER
|
||||
M: Andreas Herrmann <andreas.herrmann3@amd.com>
|
||||
L: lm-sensors@lm-sensors.org
|
||||
S: Maintained
|
||||
F: Documentation/hwmon/fam15h_power
|
||||
F: drivers/hwmon/fam15h_power.c
|
||||
|
||||
AMD GEODE CS5536 USB DEVICE CONTROLLER DRIVER
|
||||
M: Thomas Dahlmann <dahlmann.thomas@arcor.de>
|
||||
L: linux-geode@lists.infradead.org (moderated for non-subscribers)
|
||||
|
|
@ -526,7 +529,7 @@ S: Maintained
|
|||
F: drivers/infiniband/hw/amso1100/
|
||||
|
||||
ANALOG DEVICES INC ASOC CODEC DRIVERS
|
||||
L: device-driver-devel@blackfin.uclinux.org
|
||||
L: device-drivers-devel@blackfin.uclinux.org
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
W: http://wiki.analog.com/
|
||||
S: Supported
|
||||
|
|
@ -924,6 +927,8 @@ F: drivers/mmc/host/msm_sdcc.h
|
|||
F: drivers/tty/serial/msm_serial.h
|
||||
F: drivers/tty/serial/msm_serial.c
|
||||
F: drivers/platform/msm/
|
||||
F: drivers/*/pm8???-*
|
||||
F: include/linux/mfd/pm8xxx/
|
||||
T: git git://codeaurora.org/quic/kernel/davidb/linux-msm.git
|
||||
S: Maintained
|
||||
|
||||
|
|
@ -2034,9 +2039,8 @@ F: net/ax25/ax25_timer.c
|
|||
F: net/ax25/sysctl_net_ax25.c
|
||||
|
||||
DAVICOM FAST ETHERNET (DMFE) NETWORK DRIVER
|
||||
M: Tobias Ringstrom <tori@unhappy.mine.nu>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
S: Orphan
|
||||
F: Documentation/networking/dmfe.txt
|
||||
F: drivers/net/tulip/dmfe.c
|
||||
|
||||
|
|
@ -2170,6 +2174,8 @@ M: Dan Williams <dan.j.williams@intel.com>
|
|||
S: Supported
|
||||
F: drivers/dma/
|
||||
F: include/linux/dma*
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/djbw/async_tx.git
|
||||
T: git git://git.infradead.org/users/vkoul/slave-dma.git (slave-dma)
|
||||
|
||||
DME1737 HARDWARE MONITOR DRIVER
|
||||
M: Juerg Haefliger <juergh@gmail.com>
|
||||
|
|
@ -2245,10 +2251,10 @@ F: drivers/gpu/drm/
|
|||
F: include/drm/
|
||||
|
||||
INTEL DRM DRIVERS (excluding Poulsbo, Moorestown and derivative chipsets)
|
||||
M: Chris Wilson <chris@chris-wilson.co.uk>
|
||||
M: Keith Packard <keithp@keithp.com>
|
||||
L: intel-gfx@lists.freedesktop.org (subscribers-only)
|
||||
L: dri-devel@lists.freedesktop.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6.git
|
||||
S: Supported
|
||||
F: drivers/gpu/drm/i915
|
||||
F: include/drm/i915*
|
||||
|
|
@ -2296,7 +2302,7 @@ F: net/bridge/netfilter/ebt*.c
|
|||
ECRYPT FILE SYSTEM
|
||||
M: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
|
||||
M: Dustin Kirkland <kirkland@canonical.com>
|
||||
L: ecryptfs-devel@lists.launchpad.net
|
||||
L: ecryptfs@vger.kernel.org
|
||||
W: https://launchpad.net/ecryptfs
|
||||
S: Supported
|
||||
F: Documentation/filesystems/ecryptfs.txt
|
||||
|
|
@ -2576,6 +2582,13 @@ S: Maintained
|
|||
F: drivers/hwmon/f75375s.c
|
||||
F: include/linux/f75375s.h
|
||||
|
||||
FIREWIRE AUDIO DRIVERS
|
||||
M: Clemens Ladisch <clemens@ladisch.de>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
T: git git://git.alsa-project.org/alsa-kernel.git
|
||||
S: Maintained
|
||||
F: sound/firewire/
|
||||
|
||||
FIREWIRE SUBSYSTEM
|
||||
M: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
||||
L: linux1394-devel@lists.sourceforge.net
|
||||
|
|
@ -3016,9 +3029,8 @@ S: Maintained
|
|||
F: drivers/net/wireless/hostap/
|
||||
|
||||
HP COMPAQ TC1100 TABLET WMI EXTRAS DRIVER
|
||||
M: Carlos Corbacho <carlos@strangeworlds.co.uk>
|
||||
L: platform-driver-x86@vger.kernel.org
|
||||
S: Odd Fixes
|
||||
S: Orphan
|
||||
F: drivers/platform/x86/tc1100-wmi.c
|
||||
|
||||
HP100: Driver for HP 10/100 Mbit/s Voice Grade Network Adapter Series
|
||||
|
|
@ -3566,9 +3578,16 @@ M: Andrew Morton <akpm@linux-foundation.org>
|
|||
M: Jan Kara <jack@suse.cz>
|
||||
L: linux-ext4@vger.kernel.org
|
||||
S: Maintained
|
||||
F: fs/jbd*/
|
||||
F: include/linux/ext*jbd*.h
|
||||
F: include/linux/jbd*.h
|
||||
F: fs/jbd/
|
||||
F: include/linux/ext3_jbd.h
|
||||
F: include/linux/jbd.h
|
||||
|
||||
JOURNALLING LAYER FOR BLOCK DEVICES (JBD2)
|
||||
M: "Theodore Ts'o" <tytso@mit.edu>
|
||||
L: linux-ext4@vger.kernel.org
|
||||
S: Maintained
|
||||
F: fs/jbd2/
|
||||
F: include/linux/jbd2.h
|
||||
|
||||
JSM Neo PCI based serial card
|
||||
M: Breno Leitao <leitao@linux.vnet.ibm.com>
|
||||
|
|
@ -3591,10 +3610,9 @@ F: Documentation/hwmon/k8temp
|
|||
F: drivers/hwmon/k8temp.c
|
||||
|
||||
KCONFIG
|
||||
M: Roman Zippel <zippel@linux-m68k.org>
|
||||
M: Michal Marek <mmarek@suse.cz>
|
||||
L: linux-kbuild@vger.kernel.org
|
||||
Q: http://patchwork.kernel.org/project/linux-kbuild/list/
|
||||
S: Maintained
|
||||
S: Odd Fixes
|
||||
F: Documentation/kbuild/kconfig-language.txt
|
||||
F: scripts/kconfig/
|
||||
|
||||
|
|
@ -3705,7 +3723,7 @@ KEYS/KEYRINGS:
|
|||
M: David Howells <dhowells@redhat.com>
|
||||
L: keyrings@linux-nfs.org
|
||||
S: Maintained
|
||||
F: Documentation/keys.txt
|
||||
F: Documentation/security/keys.txt
|
||||
F: include/linux/key.h
|
||||
F: include/linux/key-type.h
|
||||
F: include/keys/
|
||||
|
|
@ -3717,7 +3735,7 @@ M: Mimi Zohar <zohar@us.ibm.com>
|
|||
L: linux-security-module@vger.kernel.org
|
||||
L: keyrings@linux-nfs.org
|
||||
S: Supported
|
||||
F: Documentation/keys-trusted-encrypted.txt
|
||||
F: Documentation/security/keys-trusted-encrypted.txt
|
||||
F: include/keys/trusted-type.h
|
||||
F: security/keys/trusted.c
|
||||
F: security/keys/trusted.h
|
||||
|
|
@ -3728,7 +3746,7 @@ M: David Safford <safford@watson.ibm.com>
|
|||
L: linux-security-module@vger.kernel.org
|
||||
L: keyrings@linux-nfs.org
|
||||
S: Supported
|
||||
F: Documentation/keys-trusted-encrypted.txt
|
||||
F: Documentation/security/keys-trusted-encrypted.txt
|
||||
F: include/keys/encrypted-type.h
|
||||
F: security/keys/encrypted.c
|
||||
F: security/keys/encrypted.h
|
||||
|
|
@ -3898,7 +3916,6 @@ F: drivers/*/*/*pasemi*
|
|||
LINUX SECURITY MODULE (LSM) FRAMEWORK
|
||||
M: Chris Wright <chrisw@sous-sol.org>
|
||||
L: linux-security-module@vger.kernel.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/chrisw/lsm-2.6.git
|
||||
S: Supported
|
||||
|
||||
LIS3LV02D ACCELEROMETER DRIVER
|
||||
|
|
@ -4134,6 +4151,7 @@ M: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
|
|||
L: linux-mm@kvack.org
|
||||
S: Maintained
|
||||
F: mm/memcontrol.c
|
||||
F: mm/page_cgroup.c
|
||||
|
||||
MEMORY TECHNOLOGY DEVICES (MTD)
|
||||
M: David Woodhouse <dwmw2@infradead.org>
|
||||
|
|
@ -5430,6 +5448,13 @@ L: linux-serial@vger.kernel.org
|
|||
S: Maintained
|
||||
F: drivers/tty/serial
|
||||
|
||||
SYNOPSYS DESIGNWARE DMAC DRIVER
|
||||
M: Viresh Kumar <viresh.kumar@st.com>
|
||||
S: Maintained
|
||||
F: include/linux/dw_dmac.h
|
||||
F: drivers/dma/dw_dmac_regs.h
|
||||
F: drivers/dma/dw_dmac.c
|
||||
|
||||
TIMEKEEPING, NTP
|
||||
M: John Stultz <johnstul@us.ibm.com>
|
||||
M: Thomas Gleixner <tglx@linutronix.de>
|
||||
|
|
@ -5494,7 +5519,7 @@ F: drivers/scsi/sg.c
|
|||
F: include/scsi/sg.h
|
||||
|
||||
SCSI SUBSYSTEM
|
||||
M: "James E.J. Bottomley" <James.Bottomley@suse.de>
|
||||
M: "James E.J. Bottomley" <JBottomley@parallels.com>
|
||||
L: linux-scsi@vger.kernel.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6.git
|
||||
|
|
@ -5592,10 +5617,11 @@ M: James Morris <jmorris@namei.org>
|
|||
M: Eric Paris <eparis@parisplace.org>
|
||||
L: selinux@tycho.nsa.gov (subscribers-only, general discussion)
|
||||
W: http://selinuxproject.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6.git
|
||||
T: git git://git.infradead.org/users/eparis/selinux.git
|
||||
S: Supported
|
||||
F: include/linux/selinux*
|
||||
F: security/selinux/
|
||||
F: scripts/selinux/
|
||||
|
||||
APPARMOR SECURITY MODULE
|
||||
M: John Johansen <john.johansen@canonical.com>
|
||||
|
|
@ -5986,7 +6012,7 @@ F: Documentation/filesystems/spufs.txt
|
|||
F: arch/powerpc/platforms/cell/spufs/
|
||||
|
||||
SQUASHFS FILE SYSTEM
|
||||
M: Phillip Lougher <phillip@lougher.demon.co.uk>
|
||||
M: Phillip Lougher <phillip@squashfs.org.uk>
|
||||
L: squashfs-devel@lists.sourceforge.net (subscribers-only)
|
||||
W: http://squashfs.org.uk
|
||||
S: Maintained
|
||||
|
|
@ -6062,6 +6088,17 @@ F: Documentation/filesystems/sysv-fs.txt
|
|||
F: fs/sysv/
|
||||
F: include/linux/sysv_fs.h
|
||||
|
||||
TARGET SUBSYSTEM
|
||||
M: Nicholas A. Bellinger <nab@linux-iscsi.org>
|
||||
L: linux-scsi@vger.kernel.org
|
||||
L: http://groups.google.com/group/linux-iscsi-target-dev
|
||||
W: http://www.linux-iscsi.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/nab/lio-core-2.6.git master
|
||||
S: Supported
|
||||
F: drivers/target/
|
||||
F: include/target/
|
||||
F: Documentation/target/
|
||||
|
||||
TASKSTATS STATISTICS INTERFACE
|
||||
M: Balbir Singh <balbir@linux.vnet.ibm.com>
|
||||
S: Maintained
|
||||
|
|
@ -6795,6 +6832,13 @@ L: lm-sensors@lm-sensors.org
|
|||
S: Maintained
|
||||
F: drivers/hwmon/vt8231.c
|
||||
|
||||
VUB300 USB to SDIO/SD/MMC bridge chip
|
||||
M: Tony Olech <tony.olech@elandigitalsystems.com>
|
||||
L: linux-mmc@vger.kernel.org
|
||||
L: linux-usb@vger.kernel.org
|
||||
S: Supported
|
||||
F: drivers/mmc/host/vub300.c
|
||||
|
||||
W1 DALLAS'S 1-WIRE BUS
|
||||
M: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
|
||||
S: Maintained
|
||||
|
|
|
|||
77
Makefile
77
Makefile
|
|
@ -1,8 +1,8 @@
|
|||
VERSION = 2
|
||||
PATCHLEVEL = 6
|
||||
SUBLEVEL = 39
|
||||
EXTRAVERSION =
|
||||
NAME = Flesh-Eating Bats with Fangs
|
||||
VERSION = 3
|
||||
PATCHLEVEL = 0
|
||||
SUBLEVEL = 0
|
||||
EXTRAVERSION = -rc1
|
||||
NAME = Sneaky Weasel
|
||||
|
||||
# *DOCUMENTATION*
|
||||
# To see a list of typical targets execute "make help"
|
||||
|
|
@ -103,7 +103,7 @@ ifeq ("$(origin O)", "command line")
|
|||
endif
|
||||
|
||||
ifeq ("$(origin W)", "command line")
|
||||
export KBUILD_ENABLE_EXTRA_GCC_CHECKS := 1
|
||||
export KBUILD_ENABLE_EXTRA_GCC_CHECKS := $(W)
|
||||
endif
|
||||
|
||||
# That's our default target when none is given on the command line
|
||||
|
|
@ -220,6 +220,14 @@ ifeq ($(ARCH),sh64)
|
|||
SRCARCH := sh
|
||||
endif
|
||||
|
||||
# Additional ARCH settings for tile
|
||||
ifeq ($(ARCH),tilepro)
|
||||
SRCARCH := tile
|
||||
endif
|
||||
ifeq ($(ARCH),tilegx)
|
||||
SRCARCH := tile
|
||||
endif
|
||||
|
||||
# Where to locate arch specific headers
|
||||
hdr-arch := $(SRCARCH)
|
||||
|
||||
|
|
@ -349,7 +357,8 @@ CFLAGS_GCOV = -fprofile-arcs -ftest-coverage
|
|||
|
||||
# Use LINUXINCLUDE when you must reference the include/ directory.
|
||||
# Needed to be compatible with the O= option
|
||||
LINUXINCLUDE := -I$(srctree)/arch/$(hdr-arch)/include -Iinclude \
|
||||
LINUXINCLUDE := -I$(srctree)/arch/$(hdr-arch)/include \
|
||||
-Iarch/$(hdr-arch)/include/generated -Iinclude \
|
||||
$(if $(KBUILD_SRC), -I$(srctree)/include) \
|
||||
-include include/generated/autoconf.h
|
||||
|
||||
|
|
@ -382,6 +391,7 @@ export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE CFLAGS_GCOV
|
|||
export KBUILD_AFLAGS AFLAGS_KERNEL AFLAGS_MODULE
|
||||
export KBUILD_AFLAGS_MODULE KBUILD_CFLAGS_MODULE KBUILD_LDFLAGS_MODULE
|
||||
export KBUILD_AFLAGS_KERNEL KBUILD_CFLAGS_KERNEL
|
||||
export KBUILD_ARFLAGS
|
||||
|
||||
# When compiling out-of-tree modules, put MODVERDIR in the module
|
||||
# tree rather than in the kernel tree. The kernel tree might
|
||||
|
|
@ -416,6 +426,12 @@ ifneq ($(KBUILD_SRC),)
|
|||
$(srctree) $(objtree) $(VERSION) $(PATCHLEVEL)
|
||||
endif
|
||||
|
||||
# Support for using generic headers in asm-generic
|
||||
PHONY += asm-generic
|
||||
asm-generic:
|
||||
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.asm-generic \
|
||||
obj=arch/$(SRCARCH)/include/generated/asm
|
||||
|
||||
# To make sure we do not include .config for any of the *config targets
|
||||
# catch them early, and hand them over to scripts/kconfig/Makefile
|
||||
# It is allowed to specify more targets when calling make, including
|
||||
|
|
@ -559,6 +575,10 @@ ifndef CONFIG_CC_STACKPROTECTOR
|
|||
KBUILD_CFLAGS += $(call cc-option, -fno-stack-protector)
|
||||
endif
|
||||
|
||||
# This warning generated too much noise in a regular build.
|
||||
# Use make W=1 to enable this warning (see scripts/Makefile.build)
|
||||
KBUILD_CFLAGS += $(call cc-disable-warning, unused-but-set-variable)
|
||||
|
||||
ifdef CONFIG_FRAME_POINTER
|
||||
KBUILD_CFLAGS += -fno-omit-frame-pointer -fno-optimize-sibling-calls
|
||||
else
|
||||
|
|
@ -604,7 +624,7 @@ CHECKFLAGS += $(NOSTDINC_FLAGS)
|
|||
KBUILD_CFLAGS += $(call cc-option,-Wdeclaration-after-statement,)
|
||||
|
||||
# disable pointer signed / unsigned warnings in gcc 4.0
|
||||
KBUILD_CFLAGS += $(call cc-option,-Wno-pointer-sign,)
|
||||
KBUILD_CFLAGS += $(call cc-disable-warning, pointer-sign)
|
||||
|
||||
# disable invalid "can't wrap" optimizations for signed / pointers
|
||||
KBUILD_CFLAGS += $(call cc-option,-fno-strict-overflow)
|
||||
|
|
@ -612,6 +632,9 @@ KBUILD_CFLAGS += $(call cc-option,-fno-strict-overflow)
|
|||
# conserve stack if available
|
||||
KBUILD_CFLAGS += $(call cc-option,-fconserve-stack)
|
||||
|
||||
# use the deterministic mode of AR if available
|
||||
KBUILD_ARFLAGS := $(call ar-option,D)
|
||||
|
||||
# check for 'asm goto'
|
||||
ifeq ($(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-goto.sh $(CC)), y)
|
||||
KBUILD_CFLAGS += -DCC_HAVE_ASM_GOTO
|
||||
|
|
@ -797,15 +820,17 @@ ifdef CONFIG_KALLSYMS
|
|||
# o The correct .tmp_kallsyms2.o is linked into the final vmlinux.
|
||||
# o Verify that the System.map from vmlinux matches the map from
|
||||
# .tmp_vmlinux2, just in case we did not generate kallsyms correctly.
|
||||
# o If CONFIG_KALLSYMS_EXTRA_PASS is set, do an extra pass using
|
||||
# o If 'make KALLSYMS_EXTRA_PASS=1" was used, do an extra pass using
|
||||
# .tmp_vmlinux3 and .tmp_kallsyms3.o. This is only meant as a
|
||||
# temporary bypass to allow the kernel to be built while the
|
||||
# maintainers work out what went wrong with kallsyms.
|
||||
|
||||
ifdef CONFIG_KALLSYMS_EXTRA_PASS
|
||||
last_kallsyms := 3
|
||||
else
|
||||
last_kallsyms := 2
|
||||
|
||||
ifdef KALLSYMS_EXTRA_PASS
|
||||
ifneq ($(KALLSYMS_EXTRA_PASS),0)
|
||||
last_kallsyms := 3
|
||||
endif
|
||||
endif
|
||||
|
||||
kallsyms.o := .tmp_kallsyms$(last_kallsyms).o
|
||||
|
|
@ -816,7 +841,8 @@ define verify_kallsyms
|
|||
$(cmd_sysmap) .tmp_vmlinux$(last_kallsyms) .tmp_System.map
|
||||
$(Q)cmp -s System.map .tmp_System.map || \
|
||||
(echo Inconsistent kallsyms data; \
|
||||
echo Try setting CONFIG_KALLSYMS_EXTRA_PASS; \
|
||||
echo This is a bug - please report about it; \
|
||||
echo Try "make KALLSYMS_EXTRA_PASS=1" as a workaround; \
|
||||
rm .tmp_kallsyms* ; /bin/false )
|
||||
endef
|
||||
|
||||
|
|
@ -947,7 +973,7 @@ ifneq ($(KBUILD_SRC),)
|
|||
endif
|
||||
|
||||
# prepare2 creates a makefile if using a separate output directory
|
||||
prepare2: prepare3 outputmakefile
|
||||
prepare2: prepare3 outputmakefile asm-generic
|
||||
|
||||
prepare1: prepare2 include/linux/version.h include/generated/utsrelease.h \
|
||||
include/config/auto.conf
|
||||
|
|
@ -991,7 +1017,8 @@ include/generated/utsrelease.h: include/config/kernel.release FORCE
|
|||
|
||||
PHONY += headerdep
|
||||
headerdep:
|
||||
$(Q)find include/ -name '*.h' | xargs --max-args 1 scripts/headerdep.pl
|
||||
$(Q)find $(srctree)/include/ -name '*.h' | xargs --max-args 1 \
|
||||
$(srctree)/scripts/headerdep.pl -I$(srctree)/include
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
|
|
@ -1021,7 +1048,7 @@ hdr-inst := -rR -f $(srctree)/scripts/Makefile.headersinst obj
|
|||
hdr-dst = $(if $(KBUILD_HEADERS), dst=include/asm-$(hdr-arch), dst=include/asm)
|
||||
|
||||
PHONY += __headers
|
||||
__headers: include/linux/version.h scripts_basic FORCE
|
||||
__headers: include/linux/version.h scripts_basic asm-generic FORCE
|
||||
$(Q)$(MAKE) $(build)=scripts build_unifdef
|
||||
|
||||
PHONY += headers_install_all
|
||||
|
|
@ -1136,7 +1163,8 @@ CLEAN_FILES += vmlinux System.map \
|
|||
.tmp_kallsyms* .tmp_version .tmp_vmlinux* .tmp_System.map
|
||||
|
||||
# Directories & files removed with 'make mrproper'
|
||||
MRPROPER_DIRS += include/config usr/include include/generated
|
||||
MRPROPER_DIRS += include/config usr/include include/generated \
|
||||
arch/*/include/generated
|
||||
MRPROPER_FILES += .config .config.old .version .old_version \
|
||||
include/linux/version.h \
|
||||
Module.symvers tags TAGS cscope* GPATH GTAGS GRTAGS GSYMS
|
||||
|
|
@ -1267,7 +1295,11 @@ help:
|
|||
@echo ' make O=dir [targets] Locate all output files in "dir", including .config'
|
||||
@echo ' make C=1 [targets] Check all c source with $$CHECK (sparse by default)'
|
||||
@echo ' make C=2 [targets] Force check of all c source with $$CHECK'
|
||||
@echo ' make W=1 [targets] Enable extra gcc checks'
|
||||
@echo ' make W=n [targets] Enable extra gcc checks, n=1,2,3 where'
|
||||
@echo ' 1: warnings which may be relevant and do not occur too often'
|
||||
@echo ' 2: warnings which occur quite often but may still be relevant'
|
||||
@echo ' 3: more obscure warnings, can most likely be ignored'
|
||||
@echo ' Multiple levels can be combined with W=12 or W=123'
|
||||
@echo ' make RECORDMCOUNT_WARN=1 [targets] Warn about ignored mcount sections'
|
||||
@echo ''
|
||||
@echo 'Execute "make" or "make all" to build all targets marked with [*] '
|
||||
|
|
@ -1291,6 +1323,7 @@ $(help-board-dirs): help-%:
|
|||
# Documentation targets
|
||||
# ---------------------------------------------------------------------------
|
||||
%docs: scripts_basic FORCE
|
||||
$(Q)$(MAKE) $(build)=scripts build_docproc
|
||||
$(Q)$(MAKE) $(build)=Documentation/DocBook $@
|
||||
|
||||
else # KBUILD_EXTMOD
|
||||
|
|
@ -1375,7 +1408,7 @@ endif # KBUILD_EXTMOD
|
|||
clean: $(clean-dirs)
|
||||
$(call cmd,rmdirs)
|
||||
$(call cmd,rmfiles)
|
||||
@find $(or $(KBUILD_EXTMOD), .) $(RCS_FIND_IGNORE) \
|
||||
@find $(if $(KBUILD_EXTMOD), $(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' \
|
||||
|
|
@ -1393,13 +1426,15 @@ tags TAGS cscope gtags: FORCE
|
|||
# Scripts to check various things for consistency
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
PHONY += includecheck versioncheck coccicheck namespacecheck export_report
|
||||
|
||||
includecheck:
|
||||
find * $(RCS_FIND_IGNORE) \
|
||||
find $(srctree)/* $(RCS_FIND_IGNORE) \
|
||||
-name '*.[hcS]' -type f -print | sort \
|
||||
| xargs $(PERL) -w $(srctree)/scripts/checkincludes.pl
|
||||
|
||||
versioncheck:
|
||||
find * $(RCS_FIND_IGNORE) \
|
||||
find $(srctree)/* $(RCS_FIND_IGNORE) \
|
||||
-name '*.[hcS]' -type f -print | sort \
|
||||
| xargs $(PERL) -w $(srctree)/scripts/checkversion.pl
|
||||
|
||||
|
|
|
|||
|
|
@ -175,4 +175,7 @@ config HAVE_ARCH_JUMP_LABEL
|
|||
config HAVE_ARCH_MUTEX_CPU_RELAX
|
||||
bool
|
||||
|
||||
config HAVE_RCU_TABLE_FREE
|
||||
bool
|
||||
|
||||
source "kernel/gcov/Kconfig"
|
||||
|
|
|
|||
|
|
@ -12,6 +12,7 @@ config ALPHA
|
|||
select GENERIC_IRQ_PROBE
|
||||
select AUTO_IRQ_AFFINITY if SMP
|
||||
select GENERIC_IRQ_SHOW
|
||||
select ARCH_WANT_OPTIONAL_GPIOLIB
|
||||
help
|
||||
The Alpha is a 64-bit general-purpose processor designed and
|
||||
marketed by the Digital Equipment Corporation of blessed memory,
|
||||
|
|
@ -40,10 +41,6 @@ config ARCH_HAS_ILOG2_U64
|
|||
bool
|
||||
default n
|
||||
|
||||
config GENERIC_FIND_NEXT_BIT
|
||||
bool
|
||||
default y
|
||||
|
||||
config GENERIC_CALIBRATE_DELAY
|
||||
bool
|
||||
default y
|
||||
|
|
@ -51,6 +48,9 @@ config GENERIC_CALIBRATE_DELAY
|
|||
config GENERIC_CMOS_UPDATE
|
||||
def_bool y
|
||||
|
||||
config GENERIC_GPIO
|
||||
def_bool y
|
||||
|
||||
config ZONE_DMA
|
||||
bool
|
||||
default y
|
||||
|
|
|
|||
|
|
@ -0,0 +1,55 @@
|
|||
/*
|
||||
* Generic GPIO API implementation for Alpha.
|
||||
*
|
||||
* A stright copy of that for PowerPC which was:
|
||||
*
|
||||
* Copyright (c) 2007-2008 MontaVista Software, Inc.
|
||||
*
|
||||
* Author: Anton Vorontsov <avorontsov@ru.mvista.com>
|
||||
*
|
||||
* This program is free software; you can redistribute it and/or modify
|
||||
* it under the terms of the GNU General Public License as published by
|
||||
* the Free Software Foundation; either version 2 of the License, or
|
||||
* (at your option) any later version.
|
||||
*/
|
||||
|
||||
#ifndef _ASM_ALPHA_GPIO_H
|
||||
#define _ASM_ALPHA_GPIO_H
|
||||
|
||||
#include <linux/errno.h>
|
||||
#include <asm-generic/gpio.h>
|
||||
|
||||
#ifdef CONFIG_GPIOLIB
|
||||
|
||||
/*
|
||||
* We don't (yet) implement inlined/rapid versions for on-chip gpios.
|
||||
* Just call gpiolib.
|
||||
*/
|
||||
static inline int gpio_get_value(unsigned int gpio)
|
||||
{
|
||||
return __gpio_get_value(gpio);
|
||||
}
|
||||
|
||||
static inline void gpio_set_value(unsigned int gpio, int value)
|
||||
{
|
||||
__gpio_set_value(gpio, value);
|
||||
}
|
||||
|
||||
static inline int gpio_cansleep(unsigned int gpio)
|
||||
{
|
||||
return __gpio_cansleep(gpio);
|
||||
}
|
||||
|
||||
static inline int gpio_to_irq(unsigned int gpio)
|
||||
{
|
||||
return __gpio_to_irq(gpio);
|
||||
}
|
||||
|
||||
static inline int irq_to_gpio(unsigned int irq)
|
||||
{
|
||||
return -EINVAL;
|
||||
}
|
||||
|
||||
#endif /* CONFIG_GPIOLIB */
|
||||
|
||||
#endif /* _ASM_ALPHA_GPIO_H */
|
||||
|
|
@ -39,8 +39,6 @@ struct cpuinfo_alpha {
|
|||
|
||||
extern struct cpuinfo_alpha cpu_data[NR_CPUS];
|
||||
|
||||
#define PROC_CHANGE_PENALTY 20
|
||||
|
||||
#define hard_smp_processor_id() __hard_smp_processor_id()
|
||||
#define raw_smp_processor_id() (current_thread_info()->cpu)
|
||||
|
||||
|
|
|
|||
|
|
@ -456,10 +456,11 @@
|
|||
#define __NR_open_by_handle_at 498
|
||||
#define __NR_clock_adjtime 499
|
||||
#define __NR_syncfs 500
|
||||
#define __NR_setns 501
|
||||
|
||||
#ifdef __KERNEL__
|
||||
|
||||
#define NR_SYSCALLS 501
|
||||
#define NR_SYSCALLS 502
|
||||
|
||||
#define __ARCH_WANT_IPC_PARSE_VERSION
|
||||
#define __ARCH_WANT_OLD_READDIR
|
||||
|
|
|
|||
|
|
@ -121,7 +121,7 @@ common_shutdown_1(void *generic_ptr)
|
|||
/* Wait for the secondaries to halt. */
|
||||
set_cpu_present(boot_cpuid, false);
|
||||
set_cpu_possible(boot_cpuid, false);
|
||||
while (cpus_weight(cpu_present_map))
|
||||
while (cpumask_weight(cpu_present_mask))
|
||||
barrier();
|
||||
#endif
|
||||
|
||||
|
|
|
|||
|
|
@ -1257,7 +1257,7 @@ show_cpuinfo(struct seq_file *f, void *slot)
|
|||
#ifdef CONFIG_SMP
|
||||
seq_printf(f, "cpus active\t\t: %u\n"
|
||||
"cpu active mask\t\t: %016lx\n",
|
||||
num_online_cpus(), cpus_addr(cpu_possible_map)[0]);
|
||||
num_online_cpus(), cpumask_bits(cpu_possible_mask)[0]);
|
||||
#endif
|
||||
|
||||
show_cache_size (f, "L1 Icache", alpha_l1i_cacheshape);
|
||||
|
|
|
|||
|
|
@ -451,7 +451,7 @@ setup_smp(void)
|
|||
}
|
||||
|
||||
printk(KERN_INFO "SMP: %d CPUs probed -- cpu_present_map = %lx\n",
|
||||
smp_num_probed, cpu_present_map.bits[0]);
|
||||
smp_num_probed, cpumask_bits(cpu_present_mask)[0]);
|
||||
}
|
||||
|
||||
/*
|
||||
|
|
@ -629,8 +629,9 @@ smp_send_reschedule(int cpu)
|
|||
void
|
||||
smp_send_stop(void)
|
||||
{
|
||||
cpumask_t to_whom = cpu_possible_map;
|
||||
cpu_clear(smp_processor_id(), to_whom);
|
||||
cpumask_t to_whom;
|
||||
cpumask_copy(&to_whom, cpu_possible_mask);
|
||||
cpumask_clear_cpu(smp_processor_id(), &to_whom);
|
||||
#ifdef DEBUG_IPI_MSG
|
||||
if (hard_smp_processor_id() != boot_cpu_id)
|
||||
printk(KERN_WARNING "smp_send_stop: Not on boot cpu.\n");
|
||||
|
|
|
|||
|
|
@ -140,7 +140,7 @@ cpu_set_irq_affinity(unsigned int irq, cpumask_t affinity)
|
|||
|
||||
for (cpu = 0; cpu < 4; cpu++) {
|
||||
unsigned long aff = cpu_irq_affinity[cpu];
|
||||
if (cpu_isset(cpu, affinity))
|
||||
if (cpumask_test_cpu(cpu, &affinity))
|
||||
aff |= 1UL << irq;
|
||||
else
|
||||
aff &= ~(1UL << irq);
|
||||
|
|
|
|||
|
|
@ -65,10 +65,11 @@ titan_update_irq_hw(unsigned long mask)
|
|||
register int bcpu = boot_cpuid;
|
||||
|
||||
#ifdef CONFIG_SMP
|
||||
cpumask_t cpm = cpu_present_map;
|
||||
cpumask_t cpm;
|
||||
volatile unsigned long *dim0, *dim1, *dim2, *dim3;
|
||||
unsigned long mask0, mask1, mask2, mask3, dummy;
|
||||
|
||||
cpumask_copy(&cpm, cpu_present_mask);
|
||||
mask &= ~isa_enable;
|
||||
mask0 = mask & titan_cpu_irq_affinity[0];
|
||||
mask1 = mask & titan_cpu_irq_affinity[1];
|
||||
|
|
@ -84,10 +85,10 @@ titan_update_irq_hw(unsigned long mask)
|
|||
dim1 = &cchip->dim1.csr;
|
||||
dim2 = &cchip->dim2.csr;
|
||||
dim3 = &cchip->dim3.csr;
|
||||
if (!cpu_isset(0, cpm)) dim0 = &dummy;
|
||||
if (!cpu_isset(1, cpm)) dim1 = &dummy;
|
||||
if (!cpu_isset(2, cpm)) dim2 = &dummy;
|
||||
if (!cpu_isset(3, cpm)) dim3 = &dummy;
|
||||
if (!cpumask_test_cpu(0, &cpm)) dim0 = &dummy;
|
||||
if (!cpumask_test_cpu(1, &cpm)) dim1 = &dummy;
|
||||
if (!cpumask_test_cpu(2, &cpm)) dim2 = &dummy;
|
||||
if (!cpumask_test_cpu(3, &cpm)) dim3 = &dummy;
|
||||
|
||||
*dim0 = mask0;
|
||||
*dim1 = mask1;
|
||||
|
|
@ -137,7 +138,7 @@ titan_cpu_set_irq_affinity(unsigned int irq, cpumask_t affinity)
|
|||
int cpu;
|
||||
|
||||
for (cpu = 0; cpu < 4; cpu++) {
|
||||
if (cpu_isset(cpu, affinity))
|
||||
if (cpumask_test_cpu(cpu, &affinity))
|
||||
titan_cpu_irq_affinity[cpu] |= 1UL << irq;
|
||||
else
|
||||
titan_cpu_irq_affinity[cpu] &= ~(1UL << irq);
|
||||
|
|
|
|||
|
|
@ -519,6 +519,7 @@ sys_call_table:
|
|||
.quad sys_open_by_handle_at
|
||||
.quad sys_clock_adjtime
|
||||
.quad sys_syncfs /* 500 */
|
||||
.quad sys_setns
|
||||
|
||||
.size sys_call_table, . - sys_call_table
|
||||
.type sys_call_table, @object
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ SECTIONS
|
|||
__init_begin = ALIGN(PAGE_SIZE);
|
||||
INIT_TEXT_SECTION(PAGE_SIZE)
|
||||
INIT_DATA_SECTION(16)
|
||||
PERCPU(L1_CACHE_BYTES, PAGE_SIZE)
|
||||
PERCPU_SECTION(L1_CACHE_BYTES)
|
||||
/* Align to THREAD_SIZE rather than PAGE_SIZE here so any padding page
|
||||
needed for the THREAD_SIZE aligned init_task gets freed after init */
|
||||
. = ALIGN(THREAD_SIZE);
|
||||
|
|
|
|||
|
|
@ -32,8 +32,6 @@
|
|||
#include <asm/console.h>
|
||||
#include <asm/tlb.h>
|
||||
|
||||
DEFINE_PER_CPU(struct mmu_gather, mmu_gathers);
|
||||
|
||||
extern void die_if_kernel(char *,struct pt_regs *,long);
|
||||
|
||||
static struct pcb_struct original_pcb;
|
||||
|
|
|
|||
|
|
@ -313,6 +313,7 @@ void __init paging_init(void)
|
|||
zones_size[ZONE_DMA] = dma_local_pfn;
|
||||
zones_size[ZONE_NORMAL] = (end_pfn - start_pfn) - dma_local_pfn;
|
||||
}
|
||||
node_set_state(nid, N_NORMAL_MEMORY);
|
||||
free_area_init_node(nid, zones_size, start_pfn, NULL);
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -294,6 +294,8 @@ config ARCH_AT91
|
|||
bool "Atmel AT91"
|
||||
select ARCH_REQUIRE_GPIOLIB
|
||||
select HAVE_CLK
|
||||
select CLKDEV_LOOKUP
|
||||
select ARM_PATCH_PHYS_VIRT if MMU
|
||||
help
|
||||
This enables support for systems based on the Atmel AT91RM9200,
|
||||
AT91SAM9 and AT91CAP9 processors.
|
||||
|
|
@ -730,16 +732,6 @@ config ARCH_S5P64X0
|
|||
Samsung S5P64X0 CPU based systems, such as the Samsung SMDK6440,
|
||||
SMDK6450.
|
||||
|
||||
config ARCH_S5P6442
|
||||
bool "Samsung S5P6442"
|
||||
select CPU_V6
|
||||
select GENERIC_GPIO
|
||||
select HAVE_CLK
|
||||
select ARCH_USES_GETTIMEOFFSET
|
||||
select HAVE_S3C2410_WATCHDOG if WATCHDOG
|
||||
help
|
||||
Samsung S5P6442 CPU based systems
|
||||
|
||||
config ARCH_S5PC100
|
||||
bool "Samsung S5PC100"
|
||||
select GENERIC_GPIO
|
||||
|
|
@ -991,8 +983,6 @@ endif
|
|||
|
||||
source "arch/arm/mach-s5p64x0/Kconfig"
|
||||
|
||||
source "arch/arm/mach-s5p6442/Kconfig"
|
||||
|
||||
source "arch/arm/mach-s5pc100/Kconfig"
|
||||
|
||||
source "arch/arm/mach-s5pv210/Kconfig"
|
||||
|
|
@ -1399,7 +1389,6 @@ config NR_CPUS
|
|||
config HOTPLUG_CPU
|
||||
bool "Support for hot-pluggable CPUs (EXPERIMENTAL)"
|
||||
depends on SMP && HOTPLUG && EXPERIMENTAL
|
||||
depends on !ARCH_MSM
|
||||
help
|
||||
Say Y here to experiment with turning CPUs off and on. CPUs
|
||||
can be controlled through /sys/devices/system/cpu.
|
||||
|
|
@ -1420,7 +1409,7 @@ source kernel/Kconfig.preempt
|
|||
config HZ
|
||||
int
|
||||
default 200 if ARCH_EBSA110 || ARCH_S3C2410 || ARCH_S5P64X0 || \
|
||||
ARCH_S5P6442 || ARCH_S5PV210 || ARCH_EXYNOS4
|
||||
ARCH_S5PV210 || ARCH_EXYNOS4
|
||||
default OMAP_32K_TIMER_HZ if ARCH_OMAP && OMAP_32K_TIMER
|
||||
default AT91_TIMER_HZ if ARCH_AT91
|
||||
default SHMOBILE_TIMER_HZ if ARCH_SHMOBILE
|
||||
|
|
@ -1516,6 +1505,9 @@ config ARCH_SPARSEMEM_DEFAULT
|
|||
config ARCH_SELECT_MEMORY_MODEL
|
||||
def_bool ARCH_SPARSEMEM_ENABLE
|
||||
|
||||
config HAVE_ARCH_PFN_VALID
|
||||
def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM
|
||||
|
||||
config HIGHMEM
|
||||
bool "High Memory Support"
|
||||
depends on MMU
|
||||
|
|
@ -1683,6 +1675,13 @@ endmenu
|
|||
|
||||
menu "Boot options"
|
||||
|
||||
config USE_OF
|
||||
bool "Flattened Device Tree support"
|
||||
select OF
|
||||
select OF_EARLY_FLATTREE
|
||||
help
|
||||
Include support for flattened device tree machine descriptions.
|
||||
|
||||
# Compressed boot loader in ROM. Yes, we really want to ask about
|
||||
# TEXT and BSS so we preserve their values in the config files.
|
||||
config ZBOOT_ROM_TEXT
|
||||
|
|
@ -2021,7 +2020,7 @@ menu "Power management options"
|
|||
source "kernel/power/Kconfig"
|
||||
|
||||
config ARCH_SUSPEND_POSSIBLE
|
||||
depends on !ARCH_S5P64X0 && !ARCH_S5P6442 && !ARCH_S5PC100
|
||||
depends on !ARCH_S5P64X0 && !ARCH_S5PC100
|
||||
depends on CPU_ARM920T || CPU_ARM926T || CPU_SA1100 || \
|
||||
CPU_V6 || CPU_V6K || CPU_V7 || CPU_XSC3 || CPU_XSCALE
|
||||
def_bool y
|
||||
|
|
|
|||
|
|
@ -63,13 +63,6 @@ config DEBUG_USER
|
|||
8 - SIGSEGV faults
|
||||
16 - SIGBUS faults
|
||||
|
||||
config DEBUG_STACK_USAGE
|
||||
bool "Enable stack utilization instrumentation"
|
||||
depends on DEBUG_KERNEL
|
||||
help
|
||||
Enables the display of the minimum amount of free stack which each
|
||||
task has ever had available in the sysrq-T output.
|
||||
|
||||
# These options are only for real kernel hackers who want to get their hands dirty.
|
||||
config DEBUG_LL
|
||||
bool "Kernel low-level debugging functions"
|
||||
|
|
|
|||
|
|
@ -176,7 +176,6 @@ machine-$(CONFIG_ARCH_S3C2410) := s3c2410 s3c2400 s3c2412 s3c2416 s3c2440 s3c24
|
|||
machine-$(CONFIG_ARCH_S3C24A0) := s3c24a0
|
||||
machine-$(CONFIG_ARCH_S3C64XX) := s3c64xx
|
||||
machine-$(CONFIG_ARCH_S5P64X0) := s5p64x0
|
||||
machine-$(CONFIG_ARCH_S5P6442) := s5p6442
|
||||
machine-$(CONFIG_ARCH_S5PC100) := s5pc100
|
||||
machine-$(CONFIG_ARCH_S5PV210) := s5pv210
|
||||
machine-$(CONFIG_ARCH_EXYNOS4) := exynos4
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ config ARM_VIC
|
|||
config ARM_VIC_NR
|
||||
int
|
||||
default 4 if ARCH_S5PV210
|
||||
default 3 if ARCH_S5P6442 || ARCH_S5PC100
|
||||
default 3 if ARCH_S5PC100
|
||||
default 2
|
||||
depends on ARM_VIC
|
||||
help
|
||||
|
|
|
|||
Некоторые файлы не были показаны из-за слишком большого количества измененных файлов Показать больше
Загрузка…
Ссылка в новой задаче