Merge branches 'roccat', 'upstream' and 'wiimote' into for-linus
This commit is contained in:
Jiri Kosina
commit
a91f423e59
|
|
@ -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>
|
||||
|
|
|
|||
16
CREDITS
16
CREDITS
|
|
@ -518,6 +518,14 @@ N: Zach Brown
|
|||
E: zab@zabbo.net
|
||||
D: maestro pci sound
|
||||
|
||||
M: David Brownell
|
||||
D: Kernel engineer, mentor, and friend. Maintained USB EHCI and
|
||||
D: gadget layers, SPI subsystem, GPIO subsystem, and more than a few
|
||||
D: device drivers. His encouragement also helped many engineers get
|
||||
D: started working on the Linux kernel. David passed away in early
|
||||
D: 2011, and will be greatly missed.
|
||||
W: https://lkml.org/lkml/2011/4/5/36
|
||||
|
||||
N: Gary Brubaker
|
||||
E: xavyer@ix.netcom.com
|
||||
D: USB Serial Empeg Empeg-car Mark I/II Driver
|
||||
|
|
@ -2943,6 +2951,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 +3925,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,56 @@
|
|||
What: /sys/class/backlight/<backlight>/<ambient light zone>_max
|
||||
What: /sys/class/backlight/<backlight>/l1_daylight_max
|
||||
What: /sys/class/backlight/<backlight>/l2_bright_max
|
||||
What: /sys/class/backlight/<backlight>/l3_office_max
|
||||
What: /sys/class/backlight/<backlight>/l4_indoor_max
|
||||
What: /sys/class/backlight/<backlight>/l5_dark_max
|
||||
Date: Mai 2011
|
||||
KernelVersion: 2.6.40
|
||||
Contact: device-drivers-devel@blackfin.uclinux.org
|
||||
Description:
|
||||
Control the maximum brightness for <ambient light zone>
|
||||
on this <backlight>. Values are between 0 and 127. This file
|
||||
will also show the brightness level stored for this
|
||||
<ambient light zone>.
|
||||
|
||||
What: /sys/class/backlight/<backlight>/<ambient light zone>_dim
|
||||
What: /sys/class/backlight/<backlight>/l2_bright_dim
|
||||
What: /sys/class/backlight/<backlight>/l3_office_dim
|
||||
What: /sys/class/backlight/<backlight>/l4_indoor_dim
|
||||
What: /sys/class/backlight/<backlight>/l5_dark_dim
|
||||
Date: Mai 2011
|
||||
KernelVersion: 2.6.40
|
||||
Contact: device-drivers-devel@blackfin.uclinux.org
|
||||
Description:
|
||||
Control the dim brightness for <ambient light zone>
|
||||
on this <backlight>. Values are between 0 and 127, typically
|
||||
set to 0. Full off when the backlight is disabled.
|
||||
This file will also show the dim brightness level stored for
|
||||
this <ambient light zone>.
|
||||
|
||||
What: /sys/class/backlight/<backlight>/ambient_light_level
|
||||
Date: Mai 2011
|
||||
KernelVersion: 2.6.40
|
||||
Contact: device-drivers-devel@blackfin.uclinux.org
|
||||
Description:
|
||||
Get conversion value of the light sensor.
|
||||
This value is updated every 80 ms (when the light sensor
|
||||
is enabled). Returns integer between 0 (dark) and
|
||||
8000 (max ambient brightness)
|
||||
|
||||
What: /sys/class/backlight/<backlight>/ambient_light_zone
|
||||
Date: Mai 2011
|
||||
KernelVersion: 2.6.40
|
||||
Contact: device-drivers-devel@blackfin.uclinux.org
|
||||
Description:
|
||||
Get/Set current ambient light zone. Reading returns
|
||||
integer between 1..5 (1 = daylight, 2 = bright, ..., 5 = dark).
|
||||
Writing a value between 1..5 forces the backlight controller
|
||||
to enter the corresponding ambient light zone.
|
||||
Writing 0 returns to normal/automatic ambient light level
|
||||
operation. The ambient light sensing feature on these devices
|
||||
is an extension to the API documented in
|
||||
Documentation/ABI/stable/sysfs-class-backlight.
|
||||
It can be enabled by writing the value stored in
|
||||
/sys/class/backlight/<backlight>/max_brightness to
|
||||
/sys/class/backlight/<backlight>/brightness.
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
What: /sys/bus/hid/drivers/wiimote/<dev>/led1
|
||||
What: /sys/bus/hid/drivers/wiimote/<dev>/led2
|
||||
What: /sys/bus/hid/drivers/wiimote/<dev>/led3
|
||||
What: /sys/bus/hid/drivers/wiimote/<dev>/led4
|
||||
Date: July 2011
|
||||
KernelVersion: 3.1
|
||||
Contact: David Herrmann <dh.herrmann@googlemail.com>
|
||||
Description: Make it possible to set/get current led state. Reading from it
|
||||
returns 0 if led is off and 1 if it is on. Writing 0 to it
|
||||
disables the led, writing 1 enables it.
|
||||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ information will not be available.
|
|||
To extract cgroup statistics a utility very similar to getdelays.c
|
||||
has been developed, the sample output of the utility is shown below
|
||||
|
||||
~/balbir/cgroupstats # ./getdelays -C "/cgroup/a"
|
||||
~/balbir/cgroupstats # ./getdelays -C "/sys/fs/cgroup/a"
|
||||
sleeping 1, blocked 0, running 1, stopped 0, uninterruptible 0
|
||||
~/balbir/cgroupstats # ./getdelays -C "/cgroup"
|
||||
~/balbir/cgroupstats # ./getdelays -C "/sys/fs/cgroup"
|
||||
sleeping 155, blocked 0, running 1, stopped 0, uninterruptible 2
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -28,16 +28,19 @@ cgroups. Here is what you can do.
|
|||
- Enable group scheduling in CFQ
|
||||
CONFIG_CFQ_GROUP_IOSCHED=y
|
||||
|
||||
- Compile and boot into kernel and mount IO controller (blkio).
|
||||
- Compile and boot into kernel and mount IO controller (blkio); see
|
||||
cgroups.txt, Why are cgroups needed?.
|
||||
|
||||
mount -t cgroup -o blkio none /cgroup
|
||||
mount -t tmpfs cgroup_root /sys/fs/cgroup
|
||||
mkdir /sys/fs/cgroup/blkio
|
||||
mount -t cgroup -o blkio none /sys/fs/cgroup/blkio
|
||||
|
||||
- Create two cgroups
|
||||
mkdir -p /cgroup/test1/ /cgroup/test2
|
||||
mkdir -p /sys/fs/cgroup/blkio/test1/ /sys/fs/cgroup/blkio/test2
|
||||
|
||||
- Set weights of group test1 and test2
|
||||
echo 1000 > /cgroup/test1/blkio.weight
|
||||
echo 500 > /cgroup/test2/blkio.weight
|
||||
echo 1000 > /sys/fs/cgroup/blkio/test1/blkio.weight
|
||||
echo 500 > /sys/fs/cgroup/blkio/test2/blkio.weight
|
||||
|
||||
- Create two same size files (say 512MB each) on same disk (file1, file2) and
|
||||
launch two dd threads in different cgroup to read those files.
|
||||
|
|
@ -46,12 +49,12 @@ cgroups. Here is what you can do.
|
|||
echo 3 > /proc/sys/vm/drop_caches
|
||||
|
||||
dd if=/mnt/sdb/zerofile1 of=/dev/null &
|
||||
echo $! > /cgroup/test1/tasks
|
||||
cat /cgroup/test1/tasks
|
||||
echo $! > /sys/fs/cgroup/blkio/test1/tasks
|
||||
cat /sys/fs/cgroup/blkio/test1/tasks
|
||||
|
||||
dd if=/mnt/sdb/zerofile2 of=/dev/null &
|
||||
echo $! > /cgroup/test2/tasks
|
||||
cat /cgroup/test2/tasks
|
||||
echo $! > /sys/fs/cgroup/blkio/test2/tasks
|
||||
cat /sys/fs/cgroup/blkio/test2/tasks
|
||||
|
||||
- At macro level, first dd should finish first. To get more precise data, keep
|
||||
on looking at (with the help of script), at blkio.disk_time and
|
||||
|
|
@ -68,13 +71,13 @@ Throttling/Upper Limit policy
|
|||
- Enable throttling in block layer
|
||||
CONFIG_BLK_DEV_THROTTLING=y
|
||||
|
||||
- Mount blkio controller
|
||||
mount -t cgroup -o blkio none /cgroup/blkio
|
||||
- Mount blkio controller (see cgroups.txt, Why are cgroups needed?)
|
||||
mount -t cgroup -o blkio none /sys/fs/cgroup/blkio
|
||||
|
||||
- Specify a bandwidth rate on particular device for root group. The format
|
||||
for policy is "<major>:<minor> <byes_per_second>".
|
||||
|
||||
echo "8:16 1048576" > /cgroup/blkio/blkio.read_bps_device
|
||||
echo "8:16 1048576" > /sys/fs/cgroup/blkio/blkio.read_bps_device
|
||||
|
||||
Above will put a limit of 1MB/second on reads happening for root group
|
||||
on device having major/minor number 8:16.
|
||||
|
|
@ -108,7 +111,7 @@ Hierarchical Cgroups
|
|||
CFQ and throttling will practically treat all groups at same level.
|
||||
|
||||
pivot
|
||||
/ | \ \
|
||||
/ / \ \
|
||||
root test1 test2 test3
|
||||
|
||||
Down the line we can implement hierarchical accounting/control support
|
||||
|
|
@ -149,7 +152,7 @@ Proportional weight policy files
|
|||
|
||||
Following is the format.
|
||||
|
||||
#echo dev_maj:dev_minor weight > /path/to/cgroup/blkio.weight_device
|
||||
# echo dev_maj:dev_minor weight > blkio.weight_device
|
||||
Configure weight=300 on /dev/sdb (8:16) in this cgroup
|
||||
# echo 8:16 300 > blkio.weight_device
|
||||
# cat blkio.weight_device
|
||||
|
|
|
|||
|
|
@ -138,11 +138,11 @@ With the ability to classify tasks differently for different resources
|
|||
the admin can easily set up a script which receives exec notifications
|
||||
and depending on who is launching the browser he can
|
||||
|
||||
# echo browser_pid > /mnt/<restype>/<userclass>/tasks
|
||||
# echo browser_pid > /sys/fs/cgroup/<restype>/<userclass>/tasks
|
||||
|
||||
With only a single hierarchy, he now would potentially have to create
|
||||
a separate cgroup for every browser launched and associate it with
|
||||
approp network and other resource class. This may lead to
|
||||
appropriate network and other resource class. This may lead to
|
||||
proliferation of such cgroups.
|
||||
|
||||
Also lets say that the administrator would like to give enhanced network
|
||||
|
|
@ -153,9 +153,9 @@ apps enhanced CPU power,
|
|||
With ability to write pids directly to resource classes, it's just a
|
||||
matter of :
|
||||
|
||||
# echo pid > /mnt/network/<new_class>/tasks
|
||||
# echo pid > /sys/fs/cgroup/network/<new_class>/tasks
|
||||
(after some time)
|
||||
# echo pid > /mnt/network/<orig_class>/tasks
|
||||
# echo pid > /sys/fs/cgroup/network/<orig_class>/tasks
|
||||
|
||||
Without this ability, he would have to split the cgroup into
|
||||
multiple separate ones and then associate the new cgroups with 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)
|
||||
|
|
@ -309,21 +310,24 @@ subsystem, this is the case for the cpuset.
|
|||
To start a new job that is to be contained within a cgroup, using
|
||||
the "cpuset" cgroup subsystem, the steps are something like:
|
||||
|
||||
1) mkdir /dev/cgroup
|
||||
2) mount -t cgroup -ocpuset cpuset /dev/cgroup
|
||||
3) Create the new cgroup by doing mkdir's and write's (or echo's) in
|
||||
the /dev/cgroup virtual file system.
|
||||
4) Start a task that will be the "founding father" of the new job.
|
||||
5) Attach that task to the new cgroup by writing its pid to the
|
||||
/dev/cgroup tasks file for that cgroup.
|
||||
6) fork, exec or clone the job tasks from this founding father task.
|
||||
1) mount -t tmpfs cgroup_root /sys/fs/cgroup
|
||||
2) mkdir /sys/fs/cgroup/cpuset
|
||||
3) mount -t cgroup -ocpuset cpuset /sys/fs/cgroup/cpuset
|
||||
4) Create the new cgroup by doing mkdir's and write's (or echo's) in
|
||||
the /sys/fs/cgroup virtual file system.
|
||||
5) Start a task that will be the "founding father" of the new job.
|
||||
6) Attach that task to the new cgroup by writing its pid to the
|
||||
/sys/fs/cgroup/cpuset/tasks file for that cgroup.
|
||||
7) fork, exec or clone the job tasks from this founding father task.
|
||||
|
||||
For example, the following sequence of commands will setup a cgroup
|
||||
named "Charlie", containing just CPUs 2 and 3, and Memory Node 1,
|
||||
and then start a subshell 'sh' in that cgroup:
|
||||
|
||||
mount -t cgroup cpuset -ocpuset /dev/cgroup
|
||||
cd /dev/cgroup
|
||||
mount -t tmpfs cgroup_root /sys/fs/cgroup
|
||||
mkdir /sys/fs/cgroup/cpuset
|
||||
mount -t cgroup cpuset -ocpuset /sys/fs/cgroup/cpuset
|
||||
cd /sys/fs/cgroup/cpuset
|
||||
mkdir Charlie
|
||||
cd Charlie
|
||||
/bin/echo 2-3 > cpuset.cpus
|
||||
|
|
@ -344,7 +348,7 @@ Creating, modifying, using the cgroups can be done through the cgroup
|
|||
virtual filesystem.
|
||||
|
||||
To mount a cgroup hierarchy with all available subsystems, type:
|
||||
# mount -t cgroup xxx /dev/cgroup
|
||||
# mount -t cgroup xxx /sys/fs/cgroup
|
||||
|
||||
The "xxx" is not interpreted by the cgroup code, but will appear in
|
||||
/proc/mounts so may be any useful identifying string that you like.
|
||||
|
|
@ -353,23 +357,32 @@ Note: Some subsystems do not work without some user input first. For instance,
|
|||
if cpusets are enabled the user will have to populate the cpus and mems files
|
||||
for each new cgroup created before that group can be used.
|
||||
|
||||
As explained in section `1.2 Why are cgroups needed?' you should create
|
||||
different hierarchies of cgroups for each single resource or group of
|
||||
resources you want to control. Therefore, you should mount a tmpfs on
|
||||
/sys/fs/cgroup and create directories for each cgroup resource or resource
|
||||
group.
|
||||
|
||||
# mount -t tmpfs cgroup_root /sys/fs/cgroup
|
||||
# mkdir /sys/fs/cgroup/rg1
|
||||
|
||||
To mount a cgroup hierarchy with just the cpuset and memory
|
||||
subsystems, type:
|
||||
# mount -t cgroup -o cpuset,memory hier1 /dev/cgroup
|
||||
# mount -t cgroup -o cpuset,memory hier1 /sys/fs/cgroup/rg1
|
||||
|
||||
To change the set of subsystems bound to a mounted hierarchy, just
|
||||
remount with different options:
|
||||
# mount -o remount,cpuset,blkio hier1 /dev/cgroup
|
||||
# mount -o remount,cpuset,blkio hier1 /sys/fs/cgroup/rg1
|
||||
|
||||
Now memory is removed from the hierarchy and blkio is added.
|
||||
|
||||
Note this will add blkio to the hierarchy but won't remove memory or
|
||||
cpuset, because the new options are appended to the old ones:
|
||||
# mount -o remount,blkio /dev/cgroup
|
||||
# mount -o remount,blkio /sys/fs/cgroup/rg1
|
||||
|
||||
To Specify a hierarchy's release_agent:
|
||||
# mount -t cgroup -o cpuset,release_agent="/sbin/cpuset_release_agent" \
|
||||
xxx /dev/cgroup
|
||||
xxx /sys/fs/cgroup/rg1
|
||||
|
||||
Note that specifying 'release_agent' more than once will return failure.
|
||||
|
||||
|
|
@ -378,17 +391,17 @@ when the hierarchy consists of a single (root) cgroup. Supporting
|
|||
the ability to arbitrarily bind/unbind subsystems from an existing
|
||||
cgroup hierarchy is intended to be implemented in the future.
|
||||
|
||||
Then under /dev/cgroup you can find a tree that corresponds to the
|
||||
tree of the cgroups in the system. For instance, /dev/cgroup
|
||||
Then under /sys/fs/cgroup/rg1 you can find a tree that corresponds to the
|
||||
tree of the cgroups in the system. For instance, /sys/fs/cgroup/rg1
|
||||
is the cgroup that holds the whole system.
|
||||
|
||||
If you want to change the value of release_agent:
|
||||
# echo "/sbin/new_release_agent" > /dev/cgroup/release_agent
|
||||
# echo "/sbin/new_release_agent" > /sys/fs/cgroup/rg1/release_agent
|
||||
|
||||
It can also be changed via remount.
|
||||
|
||||
If you want to create a new cgroup under /dev/cgroup:
|
||||
# cd /dev/cgroup
|
||||
If you want to create a new cgroup under /sys/fs/cgroup/rg1:
|
||||
# cd /sys/fs/cgroup/rg1
|
||||
# mkdir my_cgroup
|
||||
|
||||
Now you want to do something with this cgroup.
|
||||
|
|
@ -430,6 +443,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 +594,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 +603,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 +622,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 +663,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.
|
||||
|
|
|
|||
|
|
@ -10,26 +10,25 @@ directly present in its group.
|
|||
|
||||
Accounting groups can be created by first mounting the cgroup filesystem.
|
||||
|
||||
# mkdir /cgroups
|
||||
# mount -t cgroup -ocpuacct none /cgroups
|
||||
# mount -t cgroup -ocpuacct none /sys/fs/cgroup
|
||||
|
||||
With the above step, the initial or the parent accounting group
|
||||
becomes visible at /cgroups. At bootup, this group includes all the
|
||||
tasks in the system. /cgroups/tasks lists the tasks in this cgroup.
|
||||
/cgroups/cpuacct.usage gives the CPU time (in nanoseconds) obtained by
|
||||
this group which is essentially the CPU time obtained by all the tasks
|
||||
With the above step, the initial or the parent accounting group becomes
|
||||
visible at /sys/fs/cgroup. At bootup, this group includes all the tasks in
|
||||
the system. /sys/fs/cgroup/tasks lists the tasks in this cgroup.
|
||||
/sys/fs/cgroup/cpuacct.usage gives the CPU time (in nanoseconds) obtained
|
||||
by this group which is essentially the CPU time obtained by all the tasks
|
||||
in the system.
|
||||
|
||||
New accounting groups can be created under the parent group /cgroups.
|
||||
New accounting groups can be created under the parent group /sys/fs/cgroup.
|
||||
|
||||
# cd /cgroups
|
||||
# cd /sys/fs/cgroup
|
||||
# mkdir g1
|
||||
# echo $$ > g1
|
||||
|
||||
The above steps create a new group g1 and move the current shell
|
||||
process (bash) into it. CPU time consumed by this bash and its children
|
||||
can be obtained from g1/cpuacct.usage and the same is accumulated in
|
||||
/cgroups/cpuacct.usage also.
|
||||
/sys/fs/cgroup/cpuacct.usage also.
|
||||
|
||||
cpuacct.stat file lists a few statistics which further divide the
|
||||
CPU time obtained by the cgroup into user and system times. Currently
|
||||
|
|
|
|||
|
|
@ -661,21 +661,21 @@ than stress the kernel.
|
|||
|
||||
To start a new job that is to be contained within a cpuset, the steps are:
|
||||
|
||||
1) mkdir /dev/cpuset
|
||||
2) mount -t cgroup -ocpuset cpuset /dev/cpuset
|
||||
1) mkdir /sys/fs/cgroup/cpuset
|
||||
2) mount -t cgroup -ocpuset cpuset /sys/fs/cgroup/cpuset
|
||||
3) Create the new cpuset by doing mkdir's and write's (or echo's) in
|
||||
the /dev/cpuset virtual file system.
|
||||
the /sys/fs/cgroup/cpuset virtual file system.
|
||||
4) Start a task that will be the "founding father" of the new job.
|
||||
5) Attach that task to the new cpuset by writing its pid to the
|
||||
/dev/cpuset tasks file for that cpuset.
|
||||
/sys/fs/cgroup/cpuset tasks file for that cpuset.
|
||||
6) fork, exec or clone the job tasks from this founding father task.
|
||||
|
||||
For example, the following sequence of commands will setup a cpuset
|
||||
named "Charlie", containing just CPUs 2 and 3, and Memory Node 1,
|
||||
and then start a subshell 'sh' in that cpuset:
|
||||
|
||||
mount -t cgroup -ocpuset cpuset /dev/cpuset
|
||||
cd /dev/cpuset
|
||||
mount -t cgroup -ocpuset cpuset /sys/fs/cgroup/cpuset
|
||||
cd /sys/fs/cgroup/cpuset
|
||||
mkdir Charlie
|
||||
cd Charlie
|
||||
/bin/echo 2-3 > cpuset.cpus
|
||||
|
|
@ -710,14 +710,14 @@ Creating, modifying, using the cpusets can be done through the cpuset
|
|||
virtual filesystem.
|
||||
|
||||
To mount it, type:
|
||||
# mount -t cgroup -o cpuset cpuset /dev/cpuset
|
||||
# mount -t cgroup -o cpuset cpuset /sys/fs/cgroup/cpuset
|
||||
|
||||
Then under /dev/cpuset you can find a tree that corresponds to the
|
||||
tree of the cpusets in the system. For instance, /dev/cpuset
|
||||
Then under /sys/fs/cgroup/cpuset you can find a tree that corresponds to the
|
||||
tree of the cpusets in the system. For instance, /sys/fs/cgroup/cpuset
|
||||
is the cpuset that holds the whole system.
|
||||
|
||||
If you want to create a new cpuset under /dev/cpuset:
|
||||
# cd /dev/cpuset
|
||||
If you want to create a new cpuset under /sys/fs/cgroup/cpuset:
|
||||
# cd /sys/fs/cgroup/cpuset
|
||||
# mkdir my_cpuset
|
||||
|
||||
Now you want to do something with this cpuset.
|
||||
|
|
@ -765,12 +765,12 @@ wrapper around the cgroup filesystem.
|
|||
|
||||
The command
|
||||
|
||||
mount -t cpuset X /dev/cpuset
|
||||
mount -t cpuset X /sys/fs/cgroup/cpuset
|
||||
|
||||
is equivalent to
|
||||
|
||||
mount -t cgroup -ocpuset,noprefix X /dev/cpuset
|
||||
echo "/sbin/cpuset_release_agent" > /dev/cpuset/release_agent
|
||||
mount -t cgroup -ocpuset,noprefix X /sys/fs/cgroup/cpuset
|
||||
echo "/sbin/cpuset_release_agent" > /sys/fs/cgroup/cpuset/release_agent
|
||||
|
||||
2.2 Adding/removing cpus
|
||||
------------------------
|
||||
|
|
|
|||
|
|
@ -22,16 +22,16 @@ removed from the child(ren).
|
|||
An entry is added using devices.allow, and removed using
|
||||
devices.deny. For instance
|
||||
|
||||
echo 'c 1:3 mr' > /cgroups/1/devices.allow
|
||||
echo 'c 1:3 mr' > /sys/fs/cgroup/1/devices.allow
|
||||
|
||||
allows cgroup 1 to read and mknod the device usually known as
|
||||
/dev/null. Doing
|
||||
|
||||
echo a > /cgroups/1/devices.deny
|
||||
echo a > /sys/fs/cgroup/1/devices.deny
|
||||
|
||||
will remove the default 'a *:* rwm' entry. Doing
|
||||
|
||||
echo a > /cgroups/1/devices.allow
|
||||
echo a > /sys/fs/cgroup/1/devices.allow
|
||||
|
||||
will add the 'a *:* rwm' entry to the whitelist.
|
||||
|
||||
|
|
|
|||
|
|
@ -59,28 +59,28 @@ is non-freezable.
|
|||
|
||||
* Examples of usage :
|
||||
|
||||
# mkdir /containers
|
||||
# mount -t cgroup -ofreezer freezer /containers
|
||||
# mkdir /containers/0
|
||||
# echo $some_pid > /containers/0/tasks
|
||||
# mkdir /sys/fs/cgroup/freezer
|
||||
# mount -t cgroup -ofreezer freezer /sys/fs/cgroup/freezer
|
||||
# mkdir /sys/fs/cgroup/freezer/0
|
||||
# echo $some_pid > /sys/fs/cgroup/freezer/0/tasks
|
||||
|
||||
to get status of the freezer subsystem :
|
||||
|
||||
# cat /containers/0/freezer.state
|
||||
# cat /sys/fs/cgroup/freezer/0/freezer.state
|
||||
THAWED
|
||||
|
||||
to freeze all tasks in the container :
|
||||
|
||||
# echo FROZEN > /containers/0/freezer.state
|
||||
# cat /containers/0/freezer.state
|
||||
# echo FROZEN > /sys/fs/cgroup/freezer/0/freezer.state
|
||||
# cat /sys/fs/cgroup/freezer/0/freezer.state
|
||||
FREEZING
|
||||
# cat /containers/0/freezer.state
|
||||
# cat /sys/fs/cgroup/freezer/0/freezer.state
|
||||
FROZEN
|
||||
|
||||
to unfreeze all tasks in the container :
|
||||
|
||||
# echo THAWED > /containers/0/freezer.state
|
||||
# cat /containers/0/freezer.state
|
||||
# echo THAWED > /sys/fs/cgroup/freezer/0/freezer.state
|
||||
# cat /sys/fs/cgroup/freezer/0/freezer.state
|
||||
THAWED
|
||||
|
||||
This is the basic mechanism which should do the right thing for user space task
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
Memory Resource Controller
|
||||
|
||||
NOTE: The Memory Resource Controller has been generically been referred
|
||||
to as the memory controller in this document. Do not confuse memory
|
||||
controller used here with the memory controller that is used in hardware.
|
||||
NOTE: The Memory Resource Controller has generically been referred to as the
|
||||
memory controller in this document. Do not confuse memory controller
|
||||
used here with the memory controller that is used in hardware.
|
||||
|
||||
(For editors)
|
||||
In this document:
|
||||
|
|
@ -70,6 +70,7 @@ Brief summary of control files.
|
|||
(See sysctl's vm.swappiness)
|
||||
memory.move_charge_at_immigrate # set/show controls of moving charges
|
||||
memory.oom_control # set/show oom controls.
|
||||
memory.numa_stat # show the number of memory usage per numa node
|
||||
|
||||
1. History
|
||||
|
||||
|
|
@ -181,7 +182,7 @@ behind this approach is that a cgroup that aggressively uses a shared
|
|||
page will eventually get charged for it (once it is uncharged from
|
||||
the cgroup that brought it in -- this will happen on memory pressure).
|
||||
|
||||
Exception: If CONFIG_CGROUP_CGROUP_MEM_RES_CTLR_SWAP is not used..
|
||||
Exception: If CONFIG_CGROUP_CGROUP_MEM_RES_CTLR_SWAP is not used.
|
||||
When you do swapoff and make swapped-out pages of shmem(tmpfs) to
|
||||
be backed into memory in force, charges for pages are accounted against the
|
||||
caller of swapoff rather than the users of shmem.
|
||||
|
|
@ -213,7 +214,7 @@ affecting global LRU, memory+swap limit is better than just limiting swap from
|
|||
OS point of view.
|
||||
|
||||
* What happens when a cgroup hits memory.memsw.limit_in_bytes
|
||||
When a cgroup his memory.memsw.limit_in_bytes, it's useless to do swap-out
|
||||
When a cgroup hits memory.memsw.limit_in_bytes, it's useless to do swap-out
|
||||
in this cgroup. Then, swap-out will not be done by cgroup routine and file
|
||||
caches are dropped. But as mentioned above, global LRU can do swapout memory
|
||||
from it for sanity of the system's memory management state. You can't forbid
|
||||
|
|
@ -263,16 +264,17 @@ b. Enable CONFIG_RESOURCE_COUNTERS
|
|||
c. Enable CONFIG_CGROUP_MEM_RES_CTLR
|
||||
d. Enable CONFIG_CGROUP_MEM_RES_CTLR_SWAP (to use swap extension)
|
||||
|
||||
1. Prepare the cgroups
|
||||
# mkdir -p /cgroups
|
||||
# mount -t cgroup none /cgroups -o memory
|
||||
1. Prepare the cgroups (see cgroups.txt, Why are cgroups needed?)
|
||||
# mount -t tmpfs none /sys/fs/cgroup
|
||||
# mkdir /sys/fs/cgroup/memory
|
||||
# mount -t cgroup none /sys/fs/cgroup/memory -o memory
|
||||
|
||||
2. Make the new group and move bash into it
|
||||
# mkdir /cgroups/0
|
||||
# echo $$ > /cgroups/0/tasks
|
||||
# mkdir /sys/fs/cgroup/memory/0
|
||||
# echo $$ > /sys/fs/cgroup/memory/0/tasks
|
||||
|
||||
Since now we're in the 0 cgroup, we can alter the memory limit:
|
||||
# echo 4M > /cgroups/0/memory.limit_in_bytes
|
||||
# echo 4M > /sys/fs/cgroup/memory/0/memory.limit_in_bytes
|
||||
|
||||
NOTE: We can use a suffix (k, K, m, M, g or G) to indicate values in kilo,
|
||||
mega or gigabytes. (Here, Kilo, Mega, Giga are Kibibytes, Mebibytes, Gibibytes.)
|
||||
|
|
@ -280,11 +282,11 @@ mega or gigabytes. (Here, Kilo, Mega, Giga are Kibibytes, Mebibytes, Gibibytes.)
|
|||
NOTE: We can write "-1" to reset the *.limit_in_bytes(unlimited).
|
||||
NOTE: We cannot set limits on the root cgroup any more.
|
||||
|
||||
# cat /cgroups/0/memory.limit_in_bytes
|
||||
# cat /sys/fs/cgroup/memory/0/memory.limit_in_bytes
|
||||
4194304
|
||||
|
||||
We can check the usage:
|
||||
# cat /cgroups/0/memory.usage_in_bytes
|
||||
# cat /sys/fs/cgroup/memory/0/memory.usage_in_bytes
|
||||
1216512
|
||||
|
||||
A successful write to this file does not guarantee a successful set of
|
||||
|
|
@ -464,6 +466,24 @@ value for efficient access. (Of course, when necessary, it's synchronized.)
|
|||
If you want to know more exact memory usage, you should use RSS+CACHE(+SWAP)
|
||||
value in memory.stat(see 5.2).
|
||||
|
||||
5.6 numa_stat
|
||||
|
||||
This is similar to numa_maps but operates on a per-memcg basis. This is
|
||||
useful for providing visibility into the numa locality information within
|
||||
an memcg since the pages are allowed to be allocated from any physical
|
||||
node. One of the usecases is evaluating application performance by
|
||||
combining this information with the application's cpu allocation.
|
||||
|
||||
We export "total", "file", "anon" and "unevictable" pages per-node for
|
||||
each memcg. The ouput format of memory.numa_stat is:
|
||||
|
||||
total=<total pages> N0=<node 0 pages> N1=<node 1 pages> ...
|
||||
file=<total file pages> N0=<node 0 pages> N1=<node 1 pages> ...
|
||||
anon=<total anon pages> N0=<node 0 pages> N1=<node 1 pages> ...
|
||||
unevictable=<total anon pages> N0=<node 0 pages> N1=<node 1 pages> ...
|
||||
|
||||
And we have total = file + anon + unevictable.
|
||||
|
||||
6. Hierarchy support
|
||||
|
||||
The memory controller supports a deep hierarchy and hierarchical accounting.
|
||||
|
|
@ -471,13 +491,13 @@ The hierarchy is created by creating the appropriate cgroups in the
|
|||
cgroup filesystem. Consider for example, the following cgroup filesystem
|
||||
hierarchy
|
||||
|
||||
root
|
||||
root
|
||||
/ | \
|
||||
/ | \
|
||||
a b c
|
||||
| \
|
||||
| \
|
||||
d e
|
||||
/ | \
|
||||
a b c
|
||||
| \
|
||||
| \
|
||||
d e
|
||||
|
||||
In the diagram above, with hierarchical accounting enabled, all memory
|
||||
usage of e, is accounted to its ancestors up until the root (i.e, c and root),
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -455,23 +481,6 @@ Who: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
|
|||
|
||||
----------------------------
|
||||
|
||||
What: namespace cgroup (ns_cgroup)
|
||||
When: 2.6.38
|
||||
Why: The ns_cgroup leads to some problems:
|
||||
* cgroup creation is out-of-control
|
||||
* cgroup name can conflict when pids are looping
|
||||
* it is not possible to have a single process handling
|
||||
a lot of namespaces without falling in a exponential creation time
|
||||
* we may want to create a namespace without creating a cgroup
|
||||
|
||||
The ns_cgroup is replaced by a compatibility flag 'clone_children',
|
||||
where a newly created cgroup will copy the parent cgroup values.
|
||||
The userspace has to manually create a cgroup and add a task to
|
||||
the 'tasks' file.
|
||||
Who: Daniel Lezcano <daniel.lezcano@free.fr>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: iwlwifi disable_hw_scan module parameters
|
||||
When: 2.6.40
|
||||
Why: Hareware scan is the prefer method for iwlwifi devices for
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -836,6 +843,7 @@ Provides counts of softirq handlers serviced since boot time, for each cpu.
|
|||
TASKLET: 0 0 0 290
|
||||
SCHED: 27035 26983 26971 26746
|
||||
HRTIMER: 0 0 0 0
|
||||
RCU: 1678 1769 2178 2250
|
||||
|
||||
|
||||
1.3 IDE devices in /proc/ide
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -999,7 +999,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
|||
With this option on every unmap_single operation will
|
||||
result in a hardware IOTLB flush operation as opposed
|
||||
to batching them for performance.
|
||||
|
||||
sp_off [Default Off]
|
||||
By default, super page will be supported if Intel IOMMU
|
||||
has the capability. With this option, super page will
|
||||
not be supported.
|
||||
intremap= [X86-64, Intel-IOMMU]
|
||||
Format: { on (default) | off | nosid }
|
||||
on enable Interrupt Remapping (default)
|
||||
|
|
@ -1777,9 +1780,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
|
||||
|
|
@ -2598,6 +2598,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
|||
unlock ejectable media);
|
||||
m = MAX_SECTORS_64 (don't transfer more
|
||||
than 64 sectors = 32 KB at a time);
|
||||
n = INITIAL_READ10 (force a retry of the
|
||||
initial READ(10) command);
|
||||
o = CAPACITY_OK (accept the capacity
|
||||
reported by the device);
|
||||
r = IGNORE_RESIDUE (the device reports
|
||||
|
|
|
|||
|
|
@ -11,7 +11,9 @@ with the difference that the orphan objects are not freed but only
|
|||
reported via /sys/kernel/debug/kmemleak. A similar method is used by the
|
||||
Valgrind tool (memcheck --leak-check) to detect the memory leaks in
|
||||
user-space applications.
|
||||
Kmemleak is supported on x86, arm, powerpc, sparc, sh, microblaze and tile.
|
||||
|
||||
Please check DEBUG_KMEMLEAK dependencies in lib/Kconfig.debug for supported
|
||||
architectures.
|
||||
|
||||
Usage
|
||||
-----
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -555,7 +555,7 @@ also have
|
|||
sync_min
|
||||
sync_max
|
||||
The two values, given as numbers of sectors, indicate a range
|
||||
withing the array where 'check'/'repair' will operate. Must be
|
||||
within the array where 'check'/'repair' will operate. Must be
|
||||
a multiple of chunk_size. When it reaches "sync_max" it will
|
||||
pause, rather than complete.
|
||||
You can use 'select' or 'poll' on "sync_completed" to wait for
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
||||
=========
|
||||
|
|
|
|||
|
|
@ -520,59 +520,20 @@ Support for power domains is provided through the pwr_domain field of struct
|
|||
device. This field is a pointer to an object of type struct dev_power_domain,
|
||||
defined in include/linux/pm.h, providing a set of power management callbacks
|
||||
analogous to the subsystem-level and device driver callbacks that are executed
|
||||
for the given device during all power transitions, in addition to the respective
|
||||
subsystem-level callbacks. Specifically, the power domain "suspend" callbacks
|
||||
(i.e. ->runtime_suspend(), ->suspend(), ->freeze(), ->poweroff(), etc.) are
|
||||
executed after the analogous subsystem-level callbacks, while the power domain
|
||||
"resume" callbacks (i.e. ->runtime_resume(), ->resume(), ->thaw(), ->restore,
|
||||
etc.) are executed before the analogous subsystem-level callbacks. Error codes
|
||||
returned by the "suspend" and "resume" power domain callbacks are ignored.
|
||||
for the given device during all power transitions, instead of the respective
|
||||
subsystem-level callbacks. Specifically, if a device's pm_domain pointer is
|
||||
not NULL, the ->suspend() callback from the object pointed to by it will be
|
||||
executed instead of its subsystem's (e.g. bus type's) ->suspend() callback and
|
||||
anlogously for all of the remaining callbacks. In other words, power management
|
||||
domain callbacks, if defined for the given device, always take precedence over
|
||||
the callbacks provided by the device's subsystem (e.g. bus type).
|
||||
|
||||
Power domain ->runtime_idle() callback is executed before the subsystem-level
|
||||
->runtime_idle() callback and the result returned by it is not ignored. Namely,
|
||||
if it returns error code, the subsystem-level ->runtime_idle() callback will not
|
||||
be called and the helper function rpm_idle() executing it will return error
|
||||
code. This mechanism is intended to help platforms where saving device state
|
||||
is a time consuming operation and should only be carried out if all devices
|
||||
in the power domain are idle, before turning off the shared power resource(s).
|
||||
Namely, the power domain ->runtime_idle() callback may return error code until
|
||||
the pm_runtime_idle() helper (or its asychronous version) has been called for
|
||||
all devices in the power domain (it is recommended that the returned error code
|
||||
be -EBUSY in those cases), preventing the subsystem-level ->runtime_idle()
|
||||
callback from being run prematurely.
|
||||
|
||||
The support for device power domains is only relevant to platforms needing to
|
||||
use the same subsystem-level (e.g. platform bus type) and device driver power
|
||||
management callbacks in many different power domain configurations and wanting
|
||||
to avoid incorporating the support for power domains into the subsystem-level
|
||||
callbacks. The other platforms need not implement it or take it into account
|
||||
in any way.
|
||||
|
||||
|
||||
System Devices
|
||||
--------------
|
||||
System devices (sysdevs) follow a slightly different API, which can be found in
|
||||
|
||||
include/linux/sysdev.h
|
||||
drivers/base/sys.c
|
||||
|
||||
System devices will be suspended with interrupts disabled, and after all other
|
||||
devices have been suspended. On resume, they will be resumed before any other
|
||||
devices, and also with interrupts disabled. These things occur in special
|
||||
"sysdev_driver" phases, which affect only system devices.
|
||||
|
||||
Thus, after the suspend_noirq (or freeze_noirq or poweroff_noirq) phase, when
|
||||
the non-boot CPUs are all offline and IRQs are disabled on the remaining online
|
||||
CPU, then a sysdev_driver.suspend phase is carried out, and the system enters a
|
||||
sleep state (or a system image is created). During resume (or after the image
|
||||
has been created or loaded) a sysdev_driver.resume phase is carried out, IRQs
|
||||
are enabled on the only online CPU, the non-boot CPUs are enabled, and the
|
||||
resume_noirq (or thaw_noirq or restore_noirq) phase begins.
|
||||
|
||||
Code to actually enter and exit the system-wide low power state sometimes
|
||||
involves hardware details that are only known to the boot firmware, and
|
||||
may leave a CPU running software (from SRAM or flash memory) that monitors
|
||||
the system and manages its wakeup sequence.
|
||||
The support for device power management domains is only relevant to platforms
|
||||
needing to use the same device driver power management callbacks in many
|
||||
different power domain configurations and wanting to avoid incorporating the
|
||||
support for power domains into subsystem-level callbacks, for example by
|
||||
modifying the platform bus type. Other platforms need not implement it or take
|
||||
it into account in any way.
|
||||
|
||||
|
||||
Device Low Power (suspend) States
|
||||
|
|
|
|||
|
|
@ -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,
|
||||
|
|
|
|||
|
|
@ -566,11 +566,6 @@ to do this is:
|
|||
pm_runtime_set_active(dev);
|
||||
pm_runtime_enable(dev);
|
||||
|
||||
The PM core always increments the run-time usage counter before calling the
|
||||
->prepare() callback and decrements it after calling the ->complete() callback.
|
||||
Hence disabling run-time PM temporarily like this will not cause any run-time
|
||||
suspend callbacks to be lost.
|
||||
|
||||
7. Generic subsystem callbacks
|
||||
|
||||
Subsystems may wish to conserve code space by using the set of generic power
|
||||
|
|
|
|||
|
|
@ -9,7 +9,121 @@ If variable is of Type, use printk format specifier:
|
|||
size_t %zu or %zx
|
||||
ssize_t %zd or %zx
|
||||
|
||||
Raw pointer value SHOULD be printed with %p.
|
||||
Raw pointer value SHOULD be printed with %p. The kernel supports
|
||||
the following extended format specifiers for pointer types:
|
||||
|
||||
Symbols/Function Pointers:
|
||||
|
||||
%pF versatile_init+0x0/0x110
|
||||
%pf versatile_init
|
||||
%pS versatile_init+0x0/0x110
|
||||
%ps versatile_init
|
||||
%pB prev_fn_of_versatile_init+0x88/0x88
|
||||
|
||||
For printing symbols and function pointers. The 'S' and 's' specifiers
|
||||
result in the symbol name with ('S') or without ('s') offsets. Where
|
||||
this is used on a kernel without KALLSYMS - the symbol address is
|
||||
printed instead.
|
||||
|
||||
The 'B' specifier results in the symbol name with offsets and should be
|
||||
used when printing stack backtraces. The specifier takes into
|
||||
consideration the effect of compiler optimisations which may occur
|
||||
when tail-call's are used and marked with the noreturn GCC attribute.
|
||||
|
||||
On ia64, ppc64 and parisc64 architectures function pointers are
|
||||
actually function descriptors which must first be resolved. The 'F' and
|
||||
'f' specifiers perform this resolution and then provide the same
|
||||
functionality as the 'S' and 's' specifiers.
|
||||
|
||||
Kernel Pointers:
|
||||
|
||||
%pK 0x01234567 or 0x0123456789abcdef
|
||||
|
||||
For printing kernel pointers which should be hidden from unprivileged
|
||||
users. The behaviour of %pK depends on the kptr_restrict sysctl - see
|
||||
Documentation/sysctl/kernel.txt for more details.
|
||||
|
||||
Struct Resources:
|
||||
|
||||
%pr [mem 0x60000000-0x6fffffff flags 0x2200] or
|
||||
[mem 0x0000000060000000-0x000000006fffffff flags 0x2200]
|
||||
%pR [mem 0x60000000-0x6fffffff pref] or
|
||||
[mem 0x0000000060000000-0x000000006fffffff pref]
|
||||
|
||||
For printing struct resources. The 'R' and 'r' specifiers result in a
|
||||
printed resource with ('R') or without ('r') a decoded flags member.
|
||||
|
||||
MAC/FDDI addresses:
|
||||
|
||||
%pM 00:01:02:03:04:05
|
||||
%pMF 00-01-02-03-04-05
|
||||
%pm 000102030405
|
||||
|
||||
For printing 6-byte MAC/FDDI addresses in hex notation. The 'M' and 'm'
|
||||
specifiers result in a printed address with ('M') or without ('m') byte
|
||||
separators. The default byte separator is the colon (':').
|
||||
|
||||
Where FDDI addresses are concerned the 'F' specifier can be used after
|
||||
the 'M' specifier to use dash ('-') separators instead of the default
|
||||
separator.
|
||||
|
||||
IPv4 addresses:
|
||||
|
||||
%pI4 1.2.3.4
|
||||
%pi4 001.002.003.004
|
||||
%p[Ii][hnbl]
|
||||
|
||||
For printing IPv4 dot-separated decimal addresses. The 'I4' and 'i4'
|
||||
specifiers result in a printed address with ('i4') or without ('I4')
|
||||
leading zeros.
|
||||
|
||||
The additional 'h', 'n', 'b', and 'l' specifiers are used to specify
|
||||
host, network, big or little endian order addresses respectively. Where
|
||||
no specifier is provided the default network/big endian order is used.
|
||||
|
||||
IPv6 addresses:
|
||||
|
||||
%pI6 0001:0002:0003:0004:0005:0006:0007:0008
|
||||
%pi6 00010002000300040005000600070008
|
||||
%pI6c 1:2:3:4:5:6:7:8
|
||||
|
||||
For printing IPv6 network-order 16-bit hex addresses. The 'I6' and 'i6'
|
||||
specifiers result in a printed address with ('I6') or without ('i6')
|
||||
colon-separators. Leading zeros are always used.
|
||||
|
||||
The additional 'c' specifier can be used with the 'I' specifier to
|
||||
print a compressed IPv6 address as described by
|
||||
http://tools.ietf.org/html/rfc5952
|
||||
|
||||
UUID/GUID addresses:
|
||||
|
||||
%pUb 00010203-0405-0607-0809-0a0b0c0d0e0f
|
||||
%pUB 00010203-0405-0607-0809-0A0B0C0D0E0F
|
||||
%pUl 03020100-0504-0706-0809-0a0b0c0e0e0f
|
||||
%pUL 03020100-0504-0706-0809-0A0B0C0E0E0F
|
||||
|
||||
For printing 16-byte UUID/GUIDs addresses. The additional 'l', 'L',
|
||||
'b' and 'B' specifiers are used to specify a little endian order in
|
||||
lower ('l') or upper case ('L') hex characters - and big endian order
|
||||
in lower ('b') or upper case ('B') hex characters.
|
||||
|
||||
Where no additional specifiers are used the default little endian
|
||||
order with lower case hex characters will be printed.
|
||||
|
||||
struct va_format:
|
||||
|
||||
%pV
|
||||
|
||||
For printing struct va_format structures. These contain a format string
|
||||
and va_list as follows:
|
||||
|
||||
struct va_format {
|
||||
const char *fmt;
|
||||
va_list *va;
|
||||
};
|
||||
|
||||
Do not use this feature without some mechanism to verify the
|
||||
correctness of the format string and va_list arguments.
|
||||
|
||||
u64 SHOULD be printed with %llu/%llx, (unsigned long long):
|
||||
|
||||
|
|
@ -32,4 +146,5 @@ Reminder: sizeof() result is of type size_t.
|
|||
Thank you for your cooperation and attention.
|
||||
|
||||
|
||||
By Randy Dunlap <rdunlap@xenotime.net>
|
||||
By Randy Dunlap <rdunlap@xenotime.net> and
|
||||
Andrew Murray <amurray@mpc-data.co.uk>
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
@ -223,9 +223,10 @@ When CONFIG_FAIR_GROUP_SCHED is defined, a "cpu.shares" file is created for each
|
|||
group created using the pseudo filesystem. See example steps below to create
|
||||
task groups and modify their CPU share using the "cgroups" pseudo filesystem.
|
||||
|
||||
# mkdir /dev/cpuctl
|
||||
# mount -t cgroup -ocpu none /dev/cpuctl
|
||||
# cd /dev/cpuctl
|
||||
# mount -t tmpfs cgroup_root /sys/fs/cgroup
|
||||
# mkdir /sys/fs/cgroup/cpu
|
||||
# mount -t cgroup -ocpu none /sys/fs/cgroup/cpu
|
||||
# cd /sys/fs/cgroup/cpu
|
||||
|
||||
# mkdir multimedia # create "multimedia" group of tasks
|
||||
# mkdir browser # create "browser" group of tasks
|
||||
|
|
|
|||
|
|
@ -129,9 +129,8 @@ priority!
|
|||
Enabling CONFIG_RT_GROUP_SCHED lets you explicitly allocate real
|
||||
CPU bandwidth to task groups.
|
||||
|
||||
This uses the /cgroup virtual file system and
|
||||
"/cgroup/<cgroup>/cpu.rt_runtime_us" to control the CPU time reserved for each
|
||||
control group.
|
||||
This uses the cgroup virtual file system and "<cgroup>/cpu.rt_runtime_us"
|
||||
to control the CPU time reserved for each control group.
|
||||
|
||||
For more information on working with control groups, you should read
|
||||
Documentation/cgroups/cgroups.txt as well.
|
||||
|
|
@ -150,7 +149,7 @@ For now, this can be simplified to just the following (but see Future plans):
|
|||
===============
|
||||
|
||||
There is work in progress to make the scheduling period for each group
|
||||
("/cgroup/<cgroup>/cpu.rt_period_us") configurable as well.
|
||||
("<cgroup>/cpu.rt_period_us") configurable as well.
|
||||
|
||||
The constraint on the period is that a subgroup must have a smaller or
|
||||
equal period to its parent. But realistically its not very useful _yet_
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
# This creates the demonstration utility "lguest" which runs a Linux guest.
|
||||
# Missing headers? Add "-I../../include -I../../arch/x86/include"
|
||||
# Missing headers? Add "-I../../../include -I../../../arch/x86/include"
|
||||
CFLAGS:=-m32 -Wall -Wmissing-declarations -Wmissing-prototypes -O3 -U_FORTIFY_SOURCE
|
||||
|
||||
all: lguest
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@
|
|||
#include <linux/virtio_rng.h>
|
||||
#include <linux/virtio_ring.h>
|
||||
#include <asm/bootparam.h>
|
||||
#include "../../include/linux/lguest_launcher.h"
|
||||
#include "../../../include/linux/lguest_launcher.h"
|
||||
/*L:110
|
||||
* We can ignore the 42 include files we need for this program, but I do want
|
||||
* to draw attention to the use of kernel-style types.
|
||||
|
|
@ -135,9 +135,6 @@ struct device {
|
|||
/* Is it operational */
|
||||
bool running;
|
||||
|
||||
/* Does Guest want an intrrupt on empty? */
|
||||
bool irq_on_empty;
|
||||
|
||||
/* Device-specific data. */
|
||||
void *priv;
|
||||
};
|
||||
|
|
@ -637,10 +634,7 @@ static void trigger_irq(struct virtqueue *vq)
|
|||
|
||||
/* If they don't want an interrupt, don't send one... */
|
||||
if (vq->vring.avail->flags & VRING_AVAIL_F_NO_INTERRUPT) {
|
||||
/* ... unless they've asked us to force one on empty. */
|
||||
if (!vq->dev->irq_on_empty
|
||||
|| lg_last_avail(vq) != vq->vring.avail->idx)
|
||||
return;
|
||||
return;
|
||||
}
|
||||
|
||||
/* Send the Guest an interrupt tell them we used something up. */
|
||||
|
|
@ -1057,15 +1051,6 @@ static void create_thread(struct virtqueue *vq)
|
|||
close(vq->eventfd);
|
||||
}
|
||||
|
||||
static bool accepted_feature(struct device *dev, unsigned int bit)
|
||||
{
|
||||
const u8 *features = get_feature_bits(dev) + dev->feature_len;
|
||||
|
||||
if (dev->feature_len < bit / CHAR_BIT)
|
||||
return false;
|
||||
return features[bit / CHAR_BIT] & (1 << (bit % CHAR_BIT));
|
||||
}
|
||||
|
||||
static void start_device(struct device *dev)
|
||||
{
|
||||
unsigned int i;
|
||||
|
|
@ -1079,8 +1064,6 @@ static void start_device(struct device *dev)
|
|||
verbose(" %02x", get_feature_bits(dev)
|
||||
[dev->feature_len+i]);
|
||||
|
||||
dev->irq_on_empty = accepted_feature(dev, VIRTIO_F_NOTIFY_ON_EMPTY);
|
||||
|
||||
for (vq = dev->vq; vq; vq = vq->next) {
|
||||
if (vq->service)
|
||||
create_thread(vq);
|
||||
|
|
@ -1564,7 +1547,6 @@ static void setup_tun_net(char *arg)
|
|||
/* Set up the tun device. */
|
||||
configure_device(ipfd, tapif, ip);
|
||||
|
||||
add_feature(dev, VIRTIO_F_NOTIFY_ON_EMPTY);
|
||||
/* Expect Guest to handle everything except UFO */
|
||||
add_feature(dev, VIRTIO_NET_F_CSUM);
|
||||
add_feature(dev, VIRTIO_NET_F_GUEST_CSUM);
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -129,12 +129,12 @@ Limit injection to pages owned by memgroup. Specified by inode number
|
|||
of the memcg.
|
||||
|
||||
Example:
|
||||
mkdir /cgroup/hwpoison
|
||||
mkdir /sys/fs/cgroup/mem/hwpoison
|
||||
|
||||
usemem -m 100 -s 1000 &
|
||||
echo `jobs -p` > /cgroup/hwpoison/tasks
|
||||
echo `jobs -p` > /sys/fs/cgroup/mem/hwpoison/tasks
|
||||
|
||||
memcg_ino=$(ls -id /cgroup/hwpoison | cut -f1 -d' ')
|
||||
memcg_ino=$(ls -id /sys/fs/cgroup/mem/hwpoison | cut -f1 -d' ')
|
||||
echo $memcg_ino > /debug/hwpoison/corrupt-filter-memcg
|
||||
|
||||
page-types -p `pidof init` --hwpoison # shall do nothing
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
166
MAINTAINERS
166
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
|
||||
|
||||
|
|
@ -1734,7 +1739,7 @@ S: Supported
|
|||
F: drivers/net/enic/
|
||||
|
||||
CIRRUS LOGIC EP93XX ETHERNET DRIVER
|
||||
M: Lennert Buytenhek <kernel@wantstofly.org>
|
||||
M: Hartley Sweeten <hsweeten@visionengravers.com>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/net/arm/ep93xx_eth.c
|
||||
|
|
@ -1884,7 +1889,6 @@ L: cpufreq@vger.kernel.org
|
|||
W: http://www.codemonkey.org.uk/projects/cpufreq/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreq.git
|
||||
S: Maintained
|
||||
F: arch/x86/kernel/cpu/cpufreq/
|
||||
F: drivers/cpufreq/
|
||||
F: include/linux/cpufreq.h
|
||||
|
||||
|
|
@ -2034,9 +2038,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 +2173,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 +2250,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*
|
||||
|
|
@ -2286,8 +2291,7 @@ F: drivers/scsi/eata_pio.*
|
|||
|
||||
EBTABLES
|
||||
M: Bart De Schuymer <bart.de.schuymer@pandora.be>
|
||||
L: ebtables-user@lists.sourceforge.net
|
||||
L: ebtables-devel@lists.sourceforge.net
|
||||
L: netfilter-devel@vger.kernel.org
|
||||
W: http://ebtables.sourceforge.net/
|
||||
S: Maintained
|
||||
F: include/linux/netfilter_bridge/ebt_*.h
|
||||
|
|
@ -2296,7 +2300,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 +2580,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 +3027,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 +3576,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 +3608,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 +3721,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 +3733,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 +3744,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
|
||||
|
|
@ -3802,6 +3818,12 @@ S: Maintained
|
|||
F: drivers/leds/
|
||||
F: include/linux/leds.h
|
||||
|
||||
LEGACY EEPROM DRIVER
|
||||
M: Jean Delvare <khali@linux-fr.org>
|
||||
S: Maintained
|
||||
F: Documentation/misc-devices/eeprom
|
||||
F: drivers/misc/eeprom/eeprom.c
|
||||
|
||||
LEGO USB Tower driver
|
||||
M: Juergen Stuber <starblue@users.sourceforge.net>
|
||||
L: legousb-devel@lists.sourceforge.net
|
||||
|
|
@ -3898,7 +3920,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
|
||||
|
|
@ -4128,12 +4149,13 @@ F: include/linux/mm.h
|
|||
F: mm/
|
||||
|
||||
MEMORY RESOURCE CONTROLLER
|
||||
M: Balbir Singh <balbir@linux.vnet.ibm.com>
|
||||
M: Balbir Singh <bsingharora@gmail.com>
|
||||
M: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
|
||||
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>
|
||||
|
|
@ -4234,8 +4256,7 @@ F: drivers/mmc/
|
|||
F: include/linux/mmc/
|
||||
|
||||
MULTIMEDIA CARD (MMC) ETC. OVER SPI
|
||||
M: David Brownell <dbrownell@users.sourceforge.net>
|
||||
S: Odd Fixes
|
||||
S: Orphan
|
||||
F: drivers/mmc/host/mmc_spi.c
|
||||
F: include/linux/spi/mmc_spi.h
|
||||
|
||||
|
|
@ -4585,7 +4606,6 @@ F: drivers/media/video/omap3isp/*
|
|||
|
||||
OMAP USB SUPPORT
|
||||
M: Felipe Balbi <balbi@ti.com>
|
||||
M: David Brownell <dbrownell@users.sourceforge.net>
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: linux-omap@vger.kernel.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
|
||||
|
|
@ -4874,7 +4894,7 @@ F: mm/percpu*.c
|
|||
F: arch/*/include/asm/percpu.h
|
||||
|
||||
PER-TASK DELAY ACCOUNTING
|
||||
M: Balbir Singh <balbir@linux.vnet.ibm.com>
|
||||
M: Balbir Singh <bsingharora@gmail.com>
|
||||
S: Maintained
|
||||
F: include/linux/delayacct.h
|
||||
F: kernel/delayacct.c
|
||||
|
|
@ -4929,6 +4949,7 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/epip/linux-2.6-unicore32.gi
|
|||
F: drivers/input/serio/i8042-unicore32io.h
|
||||
F: drivers/i2c/busses/i2c-puv3.c
|
||||
F: drivers/video/fb-puv3.c
|
||||
F: drivers/rtc/rtc-puv3.c
|
||||
|
||||
PMC SIERRA MaxRAID DRIVER
|
||||
M: Anil Ravindranath <anil_ravindranath@pmc-sierra.com>
|
||||
|
|
@ -5430,6 +5451,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 +5522,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 +5620,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>
|
||||
|
|
@ -5958,7 +5987,6 @@ F: Documentation/serial/specialix.txt
|
|||
F: drivers/staging/tty/specialix*
|
||||
|
||||
SPI SUBSYSTEM
|
||||
M: David Brownell <dbrownell@users.sourceforge.net>
|
||||
M: Grant Likely <grant.likely@secretlab.ca>
|
||||
L: spi-devel-general@lists.sourceforge.net
|
||||
Q: http://patchwork.kernel.org/project/spi-devel-general/list/
|
||||
|
|
@ -5986,7 +6014,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,8 +6090,19 @@ 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>
|
||||
M: Balbir Singh <bsingharora@gmail.com>
|
||||
S: Maintained
|
||||
F: Documentation/accounting/taskstats*
|
||||
F: include/linux/taskstats*
|
||||
|
|
@ -6395,9 +6434,8 @@ S: Maintained
|
|||
F: drivers/usb/misc/rio500*
|
||||
|
||||
USB EHCI DRIVER
|
||||
M: David Brownell <dbrownell@users.sourceforge.net>
|
||||
L: linux-usb@vger.kernel.org
|
||||
S: Odd Fixes
|
||||
S: Orphan
|
||||
F: Documentation/usb/ehci.txt
|
||||
F: drivers/usb/host/ehci*
|
||||
|
||||
|
|
@ -6411,9 +6449,10 @@ S: Maintained
|
|||
F: drivers/media/video/et61x251/
|
||||
|
||||
USB GADGET/PERIPHERAL SUBSYSTEM
|
||||
M: David Brownell <dbrownell@users.sourceforge.net>
|
||||
M: Felipe Balbi <balbi@ti.com>
|
||||
L: linux-usb@vger.kernel.org
|
||||
W: http://www.linux-usb.org/gadget
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
|
||||
S: Maintained
|
||||
F: drivers/usb/gadget/
|
||||
F: include/linux/usb/gadget*
|
||||
|
|
@ -6423,7 +6462,7 @@ M: Jiri Kosina <jkosina@suse.cz>
|
|||
L: linux-usb@vger.kernel.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git
|
||||
S: Maintained
|
||||
F: Documentation/usb/hiddev.txt
|
||||
F: Documentation/hid/hiddev.txt
|
||||
F: drivers/hid/usbhid/
|
||||
|
||||
USB ISP116X DRIVER
|
||||
|
|
@ -6455,9 +6494,8 @@ S: Maintained
|
|||
F: sound/usb/midi.*
|
||||
|
||||
USB OHCI DRIVER
|
||||
M: David Brownell <dbrownell@users.sourceforge.net>
|
||||
L: linux-usb@vger.kernel.org
|
||||
S: Odd Fixes
|
||||
S: Orphan
|
||||
F: Documentation/usb/ohci.txt
|
||||
F: drivers/usb/host/ohci*
|
||||
|
||||
|
|
@ -6683,6 +6721,14 @@ S: Maintained
|
|||
F: Documentation/filesystems/vfat.txt
|
||||
F: fs/fat/
|
||||
|
||||
VIDEOBUF2 FRAMEWORK
|
||||
M: Pawel Osciak <pawel@osciak.com>
|
||||
M: Marek Szyprowski <m.szyprowski@samsung.com>
|
||||
L: linux-media@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/media/video/videobuf2-*
|
||||
F: include/media/videobuf2-*
|
||||
|
||||
VIRTIO CONSOLE DRIVER
|
||||
M: Amit Shah <amit.shah@redhat.com>
|
||||
L: virtualization@lists.linux-foundation.org
|
||||
|
|
@ -6795,6 +6841,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
|
||||
|
|
@ -6953,6 +7006,13 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/mjg59/platform-drivers-x86.
|
|||
S: Maintained
|
||||
F: drivers/platform/x86
|
||||
|
||||
X86 MCE INFRASTRUCTURE
|
||||
M: Tony Luck <tony.luck@intel.com>
|
||||
M: Borislav Petkov <bp@amd64.org>
|
||||
L: linux-edac@vger.kernel.org
|
||||
S: Maintained
|
||||
F: arch/x86/kernel/cpu/mcheck/*
|
||||
|
||||
XEN HYPERVISOR INTERFACE
|
||||
M: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
|
||||
M: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue