redonkable
/
alistair23-linux
1
0
Fork 0
Code Releases Activity

Merge commit 'v3.0-rc1' into kbuild/kbuild

hifive-unleashed-5.1
Michal Marek 2011-06-07 15:37:51 +02:00
parent 163d3fe6a2 55922c9d1b
commit 2e483528ce
9467 changed files with 477380 additions and 392044 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
.mailmap
View File

@ -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
View File

@ -328,7 +328,7 @@ S: Haifa, Israel
N: Johannes Berg
E: johannes@sipsolutions.net
W: http://johannes.sipsolutions.net/
P: 1024D/9AB78CA5 AD02 0176 4E29 C137 1DF6 08D2 FC44 CF86 9AB7 8CA5
P: 4096R/7BF9099A C0EB C440 F6DA 091C 884D 8532 E0F3 73F3 7BF9 099A
D: powerpc & 802.11 hacker
N: Stephen R. van den Berg (AKA BuGless)
@ -1677,7 +1677,7 @@ W: http://www.codemonkey.org.uk
D: Assorted VIA x86 support.
D: 2.5 AGPGART overhaul.
D: CPUFREQ maintenance.
D: Fedora kernel maintainence.
D: Fedora kernel maintenance.
D: Misc/Other.
S: 314 Littleton Rd, Westford, MA 01886, USA
@ -2943,6 +2943,10 @@ S: Kasarmikatu 11 A4
S: 70110 Kuopio
S: Finland
N: Tobias Ringström
E: tori@unhappy.mine.nu
D: Davicom DM9102(A)/DM9132/DM9801 fast ethernet driver
N: Luca Risolia
E: luca.risolia@studio.unibo.it
P: 1024D/FCE635A4 88E8 F32F 7244 68BA 3958 5D40 99DA 5D2A FCE6 35A4
@ -3211,7 +3215,7 @@ N: James Simmons
E: jsimmons@infradead.org
E: jsimmons@users.sf.net
D: Frame buffer device maintainer
D: input layer developement
D: input layer development
D: tty/console layer
D: various mipsel devices
S: 115 Carmel Avenue
@ -3290,7 +3294,7 @@ S: USA
N: Manfred Spraul
E: manfred@colorfullife.com
W: http://www.colorfullife.com/~manfred
D: Lots of tiny hacks. Larger improvments to SysV IPC msg,
D: Lots of tiny hacks. Larger improvements to SysV IPC msg,
D: slab, pipe, select.
S: 71701 Schwieberdingen
S: Germany
@ -3913,6 +3917,10 @@ S: Flandernstrasse 101
S: D-73732 Esslingen
S: Germany
N: Roman Zippel
E: zippel@linux-m68k.org
D: AFFS and HFS filesystems, m68k maintainer, new kernel configuration in 2.5
N: Leonard N. Zubkoff
W: http://www.dandelion.com/Linux/
D: BusLogic SCSI driver

12
Documentation/00-INDEX
View File

@ -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
@ -206,8 +202,8 @@ laptops/
- directory with laptop related info and laptop driver documentation.
ldm.txt
- a brief description of LDM (Windows Dynamic Disks).
leds-class.txt
- documents LED handling under Linux.
leds/
- directory with info about LED handling under Linux.
local_ops.txt
- semantics and behavior of local atomic operations.
lockdep-design.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
@ -328,8 +326,6 @@ sysrq.txt
- info on the magic SysRq key.
telephony/
- directory with info on telephony (e.g. voice over IP) support.
uml/
- directory with information about User Mode Linux.
unicode.txt
- info on the Unicode character/font mapping used in Linux.
unshare.txt

10
Documentation/ABI/obsolete/sysfs-driver-hid-roccat-koneplus 100644
View File

@ -0,0 +1,10 @@
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/startup_profile
Date: October 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The integer value of this attribute ranges from 0-4.
When read, this attribute returns the number of the actual
profile. This value is persistent, so its equivalent to the
profile that's active when the mouse is powered on next time.
When written, this file sets the number of the startup profile
and the mouse activates this profile immediately.
Please use actual_profile, it does the same thing.

9
Documentation/ABI/obsolete/o2cb → Documentation/ABI/removed/o2cb
View File

@ -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.

64
Documentation/ABI/testing/sysfs-block
View File

@ -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.

31
Documentation/ABI/testing/sysfs-bus-bcma 100644
View File

@ -0,0 +1,31 @@
What: /sys/bus/bcma/devices/.../manuf
Date: May 2011
KernelVersion: 2.6.40
Contact: Rafał Miłecki <zajec5@gmail.com>
Description:
Each BCMA core has it's manufacturer id. See
include/linux/bcma/bcma.h for possible values.
What: /sys/bus/bcma/devices/.../id
Date: May 2011
KernelVersion: 2.6.40
Contact: Rafał Miłecki <zajec5@gmail.com>
Description:
There are a few types of BCMA cores, they can be identified by
id field.
What: /sys/bus/bcma/devices/.../rev
Date: May 2011
KernelVersion: 2.6.40
Contact: Rafał Miłecki <zajec5@gmail.com>
Description:
BCMA cores of the same type can still slightly differ depending
on their revision. Use it for detailed programming.
What: /sys/bus/bcma/devices/.../class
Date: May 2011
KernelVersion: 2.6.40
Contact: Rafał Miłecki <zajec5@gmail.com>
Description:
Each BCMA core is identified by few fields, including class it
belongs to. See include/linux/bcma/bcma.h for possible values.

2
Documentation/ABI/testing/sysfs-bus-css
View File

@ -29,7 +29,7 @@ Contact: Cornelia Huck <cornelia.huck@de.ibm.com>
linux-s390@vger.kernel.org
Description: Contains the PIM/PAM/POM values, as reported by the
channel subsystem when last queried by the common I/O
layer (this implies that this attribute is not neccessarily
layer (this implies that this attribute is not necessarily
in sync with the values current in the channel subsystem).
Note: This is an I/O-subchannel specific attribute.
Users: s390-tools, HAL

9
Documentation/ABI/testing/sysfs-bus-pci
View File

@ -74,6 +74,15 @@ Description:
hot-remove the PCI device and any of its children.
Depends on CONFIG_HOTPLUG.
What: /sys/bus/pci/devices/.../pci_bus/.../rescan
Date: May 2011
Contact: Linux PCI developers <linux-pci@vger.kernel.org>
Description:
Writing a non-zero value to this attribute will
force a rescan of the bus and all child buses,
and re-discover devices removed earlier from this
part of the device tree. Depends on CONFIG_HOTPLUG.
What: /sys/bus/pci/devices/.../rescan
Date: January 2009
Contact: Linux PCI developers <linux-pci@vger.kernel.org>

2
Documentation/ABI/testing/sysfs-class-led
View File

@ -33,5 +33,5 @@ Contact: Richard Purdie <rpurdie@rpsys.net>
Description:
Invert the LED on/off state. This parameter is specific to
gpio and backlight triggers. In case of the backlight trigger,
it is usefull when driving a LED which is intended to indicate
it is useful when driving a LED which is intended to indicate
a device in a standby like state.

32
Documentation/ABI/testing/sysfs-devices-system-cpu
View File

@ -183,21 +183,21 @@ Description: Discover and change clock speed of CPUs
to learn how to control the knobs.
What: /sys/devices/system/cpu/cpu*/cache/index*/cache_disable_X
Date: August 2008
What: /sys/devices/system/cpu/cpu*/cache/index3/cache_disable_{0,1}
Date: August 2008
KernelVersion: 2.6.27
Contact: mark.langsdorf@amd.com
Description: These files exist in every cpu's cache index directories.
There are currently 2 cache_disable_# files in each
directory. Reading from these files on a supported
processor will return that cache disable index value
for that processor and node. Writing to one of these
files will cause the specificed cache index to be disabled.
Contact: discuss@x86-64.org
Description: Disable L3 cache indices
Currently, only AMD Family 10h Processors support cache index
disable, and only for their L3 caches. See the BIOS and
Kernel Developer's Guide at
http://support.amd.com/us/Embedded_TechDocs/31116-Public-GH-BKDG_3-28_5-28-09.pdf
for formatting information and other details on the
cache index disable.
Users: joachim.deguara@amd.com
These files exist in every CPU's cache/index3 directory. Each
cache_disable_{0,1} file corresponds to one disable slot which
can be used to disable a cache index. Reading from these files
on a processor with this functionality will return the currently
disabled index for that node. There is one L3 structure per
node, or per internal node on MCM machines. Writing a valid
index to one of these files will cause the specificed cache
index to be disabled.
All AMD processors with L3 caches provide this functionality.
For details, see BKDGs at
http://developer.amd.com/documentation/guides/Pages/default.aspx

2
Documentation/ABI/testing/sysfs-driver-hid-roccat-kone
View File

@ -40,7 +40,7 @@ What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-
Date: March 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile holds informations like button
press of a button. A profile holds information like button
mappings, sensitivity, the colors of the 5 leds and light
effects.
When read, these files return the respective profile. The

27
Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus
View File

@ -1,9 +1,12 @@
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/actual_profile
Date: October 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When read, this file returns the number of the actual profile in
range 0-4.
This file is readonly.
Description: The integer value of this attribute ranges from 0-4.
When read, this attribute returns the number of the actual
profile. This value is persistent, so its equivalent to the
profile that's active when the mouse is powered on next time.
When written, this file sets the number of the startup profile
and the mouse activates this profile immediately.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/firmware_version
@ -33,7 +36,7 @@ Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_buttons holds informations about button layout.
profile_buttons holds information about button layout.
When written, this file lets one write the respective profile
buttons back to the mouse. The data has to be 77 bytes long.
The mouse will reject invalid data.
@ -47,7 +50,7 @@ Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_buttons holds informations about button layout.
profile_buttons holds information about button layout.
When read, these files return the respective profile buttons.
The returned data is 77 bytes in size.
This file is readonly.
@ -58,7 +61,7 @@ Date: October 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_settings holds informations like resolution, sensitivity
profile_settings holds information like resolution, sensitivity
and light effects.
When written, this file lets one write the respective profile
settings back to the mouse. The data has to be 43 bytes long.
@ -73,7 +76,7 @@ Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_settings holds informations like resolution, sensitivity
profile_settings holds information like resolution, sensitivity
and light effects.
When read, these files return the respective profile settings.
The returned data is 43 bytes in size.
@ -89,16 +92,6 @@ Description: The mouse has a tracking- and a distance-control-unit. These
This file is writeonly.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/startup_profile
Date: October 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The integer value of this attribute ranges from 0-4.
When read, this attribute returns the number of the profile
that's active when the mouse is powered on.
When written, this file sets the number of the startup profile
and the mouse activates this profile immediately.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/tcu
Date: October 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>

8
Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus
View File

@ -52,7 +52,7 @@ Date: January 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_buttons holds informations about button layout.
profile_buttons holds information about button layout.
When written, this file lets one write the respective profile
buttons back to the mouse. The data has to be 23 bytes long.
The mouse will reject invalid data.
@ -66,7 +66,7 @@ Date: January 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_buttons holds informations about button layout.
profile_buttons holds information about button layout.
When read, these files return the respective profile buttons.
The returned data is 23 bytes in size.
This file is readonly.
@ -77,7 +77,7 @@ Date: January 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_settings holds informations like resolution, sensitivity
profile_settings holds information like resolution, sensitivity
and light effects.
When written, this file lets one write the respective profile
settings back to the mouse. The data has to be 16 bytes long.
@ -92,7 +92,7 @@ Date: January 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_settings holds informations like resolution, sensitivity
profile_settings holds information like resolution, sensitivity
and light effects.
When read, these files return the respective profile settings.
The returned data is 16 bytes in size.

8
Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra
View File

@ -39,7 +39,7 @@ Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_settings holds informations like resolution, sensitivity
profile_settings holds information like resolution, sensitivity
and light effects.
When written, this file lets one write the respective profile
settings back to the mouse. The data has to be 13 bytes long.
@ -54,7 +54,7 @@ Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_settings holds informations like resolution, sensitivity
profile_settings holds information like resolution, sensitivity
and light effects.
When read, these files return the respective profile settings.
The returned data is 13 bytes in size.
@ -66,7 +66,7 @@ Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_buttons holds informations about button layout.
profile_buttons holds information about button layout.
When written, this file lets one write the respective profile
buttons back to the mouse. The data has to be 19 bytes long.
The mouse will reject invalid data.
@ -80,7 +80,7 @@ Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_buttons holds informations about button layout.
profile_buttons holds information about button layout.
When read, these files return the respective profile buttons.
The returned data is 19 bytes in size.
This file is readonly.

18
Documentation/ABI/testing/sysfs-firmware-dmi
View File

@ -14,14 +14,15 @@ Description:
DMI is structured as a large table of entries, where
each entry has a common header indicating the type and
length of the entry, as well as 'handle' that is
supposed to be unique amongst all entries.
length of the entry, as well as a firmware-provided
'handle' that is supposed to be unique amongst all
entries.
Some entries are required by the specification, but many
others are optional. In general though, users should
never expect to find a specific entry type on their
system unless they know for certain what their firmware
is doing. Machine to machine will vary.
is doing. Machine to machine experiences will vary.
Multiple entries of the same type are allowed. In order
to handle these duplicate entry types, each entry is
@ -67,25 +68,24 @@ Description:
and the two terminating nul characters.
type : The type of the entry. This value is the same
as found in the directory name. It indicates
how the rest of the entry should be
interpreted.
how the rest of the entry should be interpreted.
instance: The instance ordinal of the entry for the
given type. This value is the same as found
in the parent directory name.
position: The position of the entry within the entirety
of the entirety.
position: The ordinal position (zero-based) of the entry
within the entirety of the DMI entry table.
=== Entry Specialization ===
Some entry types may have other information available in
sysfs.
sysfs. Not all types are specialized.
--- Type 15 - System Event Log ---
This entry allows the firmware to export a log of
events the system has taken. This information is
typically backed by nvram, but the implementation
details are abstracted by this table. This entries data
details are abstracted by this table. This entry's data
is exported in the directory:
/sys/firmware/dmi/entries/15-0/system_event_log

58
Documentation/ABI/testing/sysfs-firmware-gsmi 100644
View File

@ -0,0 +1,58 @@
What: /sys/firmware/gsmi
Date: March 2011
Contact: Mike Waychison <mikew@google.com>
Description:
Some servers used internally at Google have firmware
that provides callback functionality via explicit SMI
triggers. Some of the callbacks are similar to those
provided by the EFI runtime services page, but due to
historical reasons this different entry-point has been
used.
The gsmi driver implements the kernel's abstraction for
these firmware callbacks. Currently, this functionality
is limited to handling the system event log and getting
access to EFI-style variables stored in nvram.
Layout:
/sys/firmware/gsmi/vars:
This directory has the same layout (and
underlying implementation as /sys/firmware/efi/vars.
See Documentation/ABI/*/sysfs-firmware-efi-vars
for more information on how to interact with
this structure.
/sys/firmware/gsmi/append_to_eventlog - write-only:
This file takes a binary blob and passes it onto
the firmware to be timestamped and appended to
the system eventlog. The binary format is
interpreted by the firmware and may change from
platform to platform. The only kernel-enforced
requirement is that the blob be prefixed with a
32bit host-endian type used as part of the
firmware call.
/sys/firmware/gsmi/clear_config - write-only:
Writing any value to this file will cause the
entire firmware configuration to be reset to
"factory defaults". Callers should assume that
a reboot is required for the configuration to be
cleared.
/sys/firmware/gsmi/clear_eventlog - write-only:
This file is used to clear out a portion/the
whole of the system event log. Values written
should be values between 1 and 100 inclusive (in
ASCII) representing the fraction of the log to
clear. Not all platforms support fractional
clearing though, and this writes to this file
will error out if the firmware doesn't like your
submitted fraction.
Callers should assume that a reboot is needed
for this operation to complete.

7
Documentation/ABI/testing/sysfs-firmware-log 100644
View File

@ -0,0 +1,7 @@
What: /sys/firmware/log
Date: February 2011
Contact: Mike Waychison <mikew@google.com>
Description:
The /sys/firmware/log is a binary file that represents a
read-only copy of the firmware's log if one is
available.

8
Documentation/ABI/testing/sysfs-kernel-fscaps 100644
View File

@ -0,0 +1,8 @@
What: /sys/kernel/fscaps
Date: February 2011
KernelVersion: 2.6.38
Contact: Ludwig Nussel <ludwig.nussel@suse.de>
Description
Shows whether file system capabilities are honored
when executing a binary

11
Documentation/ABI/testing/sysfs-kernel-mm-cleancache 100644
View File

@ -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

2
Documentation/ABI/testing/sysfs-platform-asus-laptop
View File

@ -27,7 +27,7 @@ KernelVersion: 2.6.20
Contact: "Corentin Chary" <corentincj@iksaif.net>
Description:
Some models like the W1N have a LED display that can be
used to display several informations.
used to display several items of information.
To control the LED display, use the following :
echo 0x0T000DDD > /sys/devices/platform/asus_laptop/
where T control the 3 letters display, and DDD the 3 digits display.

14
Documentation/ABI/testing/sysfs-power
View File

@ -158,3 +158,17 @@ Description:
successful, will make the kernel abort a subsequent transition
to a sleep state if any wakeup events are reported after the
write has returned.
What: /sys/power/reserved_size
Date: May 2011
Contact: Rafael J. Wysocki <rjw@sisk.pl>
Description:
The /sys/power/reserved_size file allows user space to control
the amount of memory reserved for allocations made by device
drivers during the "device freeze" stage of hibernation. It can
be written a string representing a non-negative integer that
will be used as the amount of memory to reserve for allocations
made by device drivers' "freeze" callbacks, in bytes.
Reading from this file will display the current value, which is
set to 1 MB by default.

98
Documentation/ABI/testing/sysfs-ptp 100644
View File

@ -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.

1
Documentation/DocBook/.gitignore vendored
View File

@ -8,3 +8,4 @@
*.dvi
*.log
*.out
media/

6
Documentation/DocBook/device-drivers.tmpl
View File

@ -96,10 +96,10 @@ X!Iinclude/linux/kobject.h
<chapter id="devdrivers">
<title>Device drivers infrastructure</title>
<sect1><title>The Basic Device Driver-Model Structures </title>
!Iinclude/linux/device.h
</sect1>
<sect1><title>Device Drivers Base</title>
<!--
X!Iinclude/linux/device.h
-->
!Edrivers/base/driver.c
!Edrivers/base/core.c
!Edrivers/base/class.c

8
Documentation/DocBook/dvb/dvbapi.xml
View File

@ -34,6 +34,14 @@
<revhistory>
<!-- Put document revisions here, newest first. -->
<revision>
<revnumber>2.0.4</revnumber>
<date>2011-05-06</date>
<authorinitials>mcc</authorinitials>
<revremark>
Add more information about DVB APIv5, better describing the frontend GET/SET props ioctl's.
</revremark>
</revision>
<revision>
<revnumber>2.0.3</revnumber>
<date>2010-07-03</date>

408
Documentation/DocBook/dvb/dvbproperty.xml
View File

@ -1,6 +1,330 @@
<section id="FE_GET_PROPERTY">
<section id="FE_GET_SET_PROPERTY">
<title>FE_GET_PROPERTY/FE_SET_PROPERTY</title>
<programlisting>
/* Reserved fields should be set to 0 */
struct dtv_property {
__u32 cmd;
union {
__u32 data;
struct {
__u8 data[32];
__u32 len;
__u32 reserved1[3];
void *reserved2;
} buffer;
} u;
int result;
} __attribute__ ((packed));
/* num of properties cannot exceed DTV_IOCTL_MAX_MSGS per ioctl */
#define DTV_IOCTL_MAX_MSGS 64
struct dtv_properties {
__u32 num;
struct dtv_property *props;
};
</programlisting>
<section id="FE_GET_PROPERTY">
<title>FE_GET_PROPERTY</title>
<para>DESCRIPTION
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl call returns one or more frontend properties. This call only
requires read-only access to the device.</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>SYNOPSIS
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(int fd, int request = <link linkend="FE_GET_PROPERTY">FE_GET_PROPERTY</link>,
dtv_properties &#x22C6;props);</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>PARAMETERS
</para>
<informaltable><tgroup cols="2"><tbody><row><entry align="char">
<para>int fd</para>
</entry><entry
align="char">
<para>File descriptor returned by a previous call to open().</para>
</entry>
</row><row><entry
align="char">
<para>int num</para>
</entry><entry
align="char">
<para>Equals <link linkend="FE_GET_PROPERTY">FE_GET_PROPERTY</link> for this command.</para>
</entry>
</row><row><entry
align="char">
<para>struct dtv_property *props</para>
</entry><entry
align="char">
<para>Points to the location where the front-end property commands are stored.</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>ERRORS</para>
<informaltable><tgroup cols="2"><tbody><row>
<entry align="char"><para>EINVAL</para></entry>
<entry align="char"><para>Invalid parameter(s) received or number of parameters out of the range.</para></entry>
</row><row>
<entry align="char"><para>ENOMEM</para></entry>
<entry align="char"><para>Out of memory.</para></entry>
</row><row>
<entry align="char"><para>EFAULT</para></entry>
<entry align="char"><para>Failure while copying data from/to userspace.</para></entry>
</row><row>
<entry align="char"><para>EOPNOTSUPP</para></entry>
<entry align="char"><para>Property type not supported.</para></entry>
</row></tbody></tgroup></informaltable>
</section>
<section id="FE_SET_PROPERTY">
<title>FE_SET_PROPERTY</title>
<para>DESCRIPTION
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl call sets one or more frontend properties. This call only
requires read-only access to the device.</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>SYNOPSIS
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(int fd, int request = <link linkend="FE_SET_PROPERTY">FE_SET_PROPERTY</link>,
dtv_properties &#x22C6;props);</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>PARAMETERS
</para>
<informaltable><tgroup cols="2"><tbody><row><entry align="char">
<para>int fd</para>
</entry><entry
align="char">
<para>File descriptor returned by a previous call to open().</para>
</entry>
</row><row><entry
align="char">
<para>int num</para>
</entry><entry
align="char">
<para>Equals <link linkend="FE_SET_PROPERTY">FE_SET_PROPERTY</link> for this command.</para>
</entry>
</row><row><entry
align="char">
<para>struct dtv_property *props</para>
</entry><entry
align="char">
<para>Points to the location where the front-end property commands are stored.</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>ERRORS
</para>
<informaltable><tgroup cols="2"><tbody><row>
<entry align="char"><para>EINVAL</para></entry>
<entry align="char"><para>Invalid parameter(s) received or number of parameters out of the range.</para></entry>
</row><row>
<entry align="char"><para>ENOMEM</para></entry>
<entry align="char"><para>Out of memory.</para></entry>
</row><row>
<entry align="char"><para>EFAULT</para></entry>
<entry align="char"><para>Failure while copying data from/to userspace.</para></entry>
</row><row>
<entry align="char"><para>EOPNOTSUPP</para></entry>
<entry align="char"><para>Property type not supported.</para></entry>
</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>
<programlisting>
#define DTV_UNDEFINED 0
#define DTV_TUNE 1
#define DTV_CLEAR 2
#define DTV_FREQUENCY 3
#define DTV_MODULATION 4
#define DTV_BANDWIDTH_HZ 5
#define DTV_INVERSION 6
#define DTV_DISEQC_MASTER 7
#define DTV_SYMBOL_RATE 8
#define DTV_INNER_FEC 9
#define DTV_VOLTAGE 10
#define DTV_TONE 11
#define DTV_PILOT 12
#define DTV_ROLLOFF 13
#define DTV_DISEQC_SLAVE_REPLY 14
#define DTV_FE_CAPABILITY_COUNT 15
#define DTV_FE_CAPABILITY 16
#define DTV_DELIVERY_SYSTEM 17
#define DTV_ISDBT_PARTIAL_RECEPTION 18
#define DTV_ISDBT_SOUND_BROADCASTING 19
#define DTV_ISDBT_SB_SUBCHANNEL_ID 20
#define DTV_ISDBT_SB_SEGMENT_IDX 21
#define DTV_ISDBT_SB_SEGMENT_COUNT 22
#define DTV_ISDBT_LAYERA_FEC 23
#define DTV_ISDBT_LAYERA_MODULATION 24
#define DTV_ISDBT_LAYERA_SEGMENT_COUNT 25
#define DTV_ISDBT_LAYERA_TIME_INTERLEAVING 26
#define DTV_ISDBT_LAYERB_FEC 27
#define DTV_ISDBT_LAYERB_MODULATION 28
#define DTV_ISDBT_LAYERB_SEGMENT_COUNT 29
#define DTV_ISDBT_LAYERB_TIME_INTERLEAVING 30
#define DTV_ISDBT_LAYERC_FEC 31
#define DTV_ISDBT_LAYERC_MODULATION 32
#define DTV_ISDBT_LAYERC_SEGMENT_COUNT 33
#define DTV_ISDBT_LAYERC_TIME_INTERLEAVING 34
#define DTV_API_VERSION 35
#define DTV_CODE_RATE_HP 36
#define DTV_CODE_RATE_LP 37
#define DTV_GUARD_INTERVAL 38
#define DTV_TRANSMISSION_MODE 39
#define DTV_HIERARCHY 40
#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>
<section id="DTV_FREQUENCY">
<title><constant>DTV_FREQUENCY</constant></title>
<para>Central frequency of the channel, in HZ.</para>
<para>Notes:</para>
<para>1)For ISDB-T, the channels are usually transmitted with an offset of 143kHz.
E.g. a valid frequncy could be 474143 kHz. The stepping is bound to the bandwidth of
the channel which is 6MHz.</para>
<para>2)As in ISDB-Tsb the channel consists of only one or three segments the
frequency step is 429kHz, 3*429 respectively. As for ISDB-T the
central frequency of the channel is expected.</para>
</section>
<section id="DTV_BANDWIDTH_HZ">
<title><constant>DTV_BANDWIDTH_HZ</constant></title>
<para>Bandwidth for the channel, in HZ.</para>
<para>Possible values:
<constant>1712000</constant>,
<constant>5000000</constant>,
<constant>6000000</constant>,
<constant>7000000</constant>,
<constant>8000000</constant>,
<constant>10000000</constant>.
</para>
<para>Notes:</para>
<para>1) For ISDB-T it should be always 6000000Hz (6MHz)</para>
<para>2) For ISDB-Tsb it can vary depending on the number of connected segments</para>
<para>3) Bandwidth doesn't apply for DVB-C transmissions, as the bandwidth
for DVB-C depends on the symbol rate</para>
<para>4) Bandwidth in ISDB-T is fixed (6MHz) or can be easily derived from
other parameters (DTV_ISDBT_SB_SEGMENT_IDX,
DTV_ISDBT_SB_SEGMENT_COUNT).</para>
<para>5) DVB-T supports 6, 7 and 8MHz.</para>
<para>6) In addition, DVB-T2 supports 1.172, 5 and 10MHz.</para>
</section>
<section id="DTV_DELIVERY_SYSTEM">
<title><constant>DTV_DELIVERY_SYSTEM</constant></title>
<para>Specifies the type of Delivery system</para>
<para>Possible values: </para>
<programlisting>
typedef enum fe_delivery_system {
SYS_UNDEFINED,
SYS_DVBC_ANNEX_AC,
SYS_DVBC_ANNEX_B,
SYS_DVBT,
SYS_DSS,
SYS_DVBS,
SYS_DVBS2,
SYS_DVBH,
SYS_ISDBT,
SYS_ISDBS,
SYS_ISDBC,
SYS_ATSC,
SYS_ATSCMH,
SYS_DMBTH,
SYS_CMMB,
SYS_DAB,
SYS_DVBT2,
} fe_delivery_system_t;
</programlisting>
</section>
<section id="DTV_TRANSMISSION_MODE">
<title><constant>DTV_TRANSMISSION_MODE</constant></title>
<para>Specifies the number of carriers used by the standard</para>
<para>Possible values are:</para>
<programlisting>
typedef enum fe_transmit_mode {
TRANSMISSION_MODE_2K,
TRANSMISSION_MODE_8K,
TRANSMISSION_MODE_AUTO,
TRANSMISSION_MODE_4K,
TRANSMISSION_MODE_1K,
TRANSMISSION_MODE_16K,
TRANSMISSION_MODE_32K,
} fe_transmit_mode_t;
</programlisting>
<para>Notes:</para>
<para>1) ISDB-T supports three carrier/symbol-size: 8K, 4K, 2K. It is called
'mode' in the standard: Mode 1 is 2K, mode 2 is 4K, mode 3 is 8K</para>
<para>2) If <constant>DTV_TRANSMISSION_MODE</constant> is set the <constant>TRANSMISSION_MODE_AUTO</constant> the
hardware will try to find the correct FFT-size (if capable) and will
use TMCC to fill in the missing parameters.</para>
<para>3) DVB-T specifies 2K and 8K as valid sizes.</para>
<para>4) DVB-T2 specifies 1K, 2K, 4K, 8K, 16K and 32K.</para>
</section>
<section id="DTV_GUARD_INTERVAL">
<title><constant>DTV_GUARD_INTERVAL</constant></title>
<para>Possible values are:</para>
<programlisting>
typedef enum fe_guard_interval {
GUARD_INTERVAL_1_32,
GUARD_INTERVAL_1_16,
GUARD_INTERVAL_1_8,
GUARD_INTERVAL_1_4,
GUARD_INTERVAL_AUTO,
GUARD_INTERVAL_1_128,
GUARD_INTERVAL_19_128,
GUARD_INTERVAL_19_256,
} fe_guard_interval_t;
</programlisting>
<para>Notes:</para>
<para>1) If <constant>DTV_GUARD_INTERVAL</constant> is set the <constant>GUARD_INTERVAL_AUTO</constant> the hardware will
try to find the correct guard interval (if capable) and will use TMCC to fill
in the missing parameters.</para>
<para>2) Intervals 1/128, 19/128 and 19/256 are used only for DVB-T2 at present</para>
</section>
</section>
<section id="isdbt">
<title>ISDB-T frontend</title>
<para>This section describes shortly what are the possible parameters in the Linux
@ -32,73 +356,6 @@
<para>Parameters used by ISDB-T and ISDB-Tsb.</para>
<section id="isdbt-parms">
<title>Parameters that are common with DVB-T and ATSC</title>
<section id="isdbt-freq">
<title><constant>DTV_FREQUENCY</constant></title>
<para>Central frequency of the channel.</para>
<para>For ISDB-T the channels are usally transmitted with an offset of 143kHz. E.g. a
valid frequncy could be 474143 kHz. The stepping is bound to the bandwidth of
the channel which is 6MHz.</para>
<para>As in ISDB-Tsb the channel consists of only one or three segments the
frequency step is 429kHz, 3*429 respectively. As for ISDB-T the
central frequency of the channel is expected.</para>
</section>
<section id="isdbt-bw">
<title><constant>DTV_BANDWIDTH_HZ</constant> (optional)</title>
<para>Possible values:</para>
<para>For ISDB-T it should be always 6000000Hz (6MHz)</para>
<para>For ISDB-Tsb it can vary depending on the number of connected segments</para>
<para>Note: Hardware specific values might be given here, but standard
applications should not bother to set a value to this field as
standard demods are ignoring it anyway.</para>
<para>Bandwidth in ISDB-T is fixed (6MHz) or can be easily derived from
other parameters (DTV_ISDBT_SB_SEGMENT_IDX,
DTV_ISDBT_SB_SEGMENT_COUNT).</para>
</section>
<section id="isdbt-delivery-sys">
<title><constant>DTV_DELIVERY_SYSTEM</constant></title>
<para>Possible values: <constant>SYS_ISDBT</constant></para>
</section>
<section id="isdbt-tx-mode">
<title><constant>DTV_TRANSMISSION_MODE</constant></title>
<para>ISDB-T supports three carrier/symbol-size: 8K, 4K, 2K. It is called
'mode' in the standard: Mode 1 is 2K, mode 2 is 4K, mode 3 is 8K</para>
<para>Possible values: <constant>TRANSMISSION_MODE_2K</constant>, <constant>TRANSMISSION_MODE_8K</constant>,
<constant>TRANSMISSION_MODE_AUTO</constant>, <constant>TRANSMISSION_MODE_4K</constant></para>
<para>If <constant>DTV_TRANSMISSION_MODE</constant> is set the <constant>TRANSMISSION_MODE_AUTO</constant> the
hardware will try to find the correct FFT-size (if capable) and will
use TMCC to fill in the missing parameters.</para>
<para><constant>TRANSMISSION_MODE_4K</constant> is added at the same time as the other new parameters.</para>
</section>
<section id="isdbt-guard-interval">
<title><constant>DTV_GUARD_INTERVAL</constant></title>
<para>Possible values: <constant>GUARD_INTERVAL_1_32</constant>, <constant>GUARD_INTERVAL_1_16</constant>, <constant>GUARD_INTERVAL_1_8</constant>,
<constant>GUARD_INTERVAL_1_4</constant>, <constant>GUARD_INTERVAL_AUTO</constant></para>
<para>If <constant>DTV_GUARD_INTERVAL</constant> is set the <constant>GUARD_INTERVAL_AUTO</constant> the hardware will
try to find the correct guard interval (if capable) and will use TMCC to fill
in the missing parameters.</para>
</section>
</section>
<section id="isdbt-new-parms">
<title>ISDB-T only parameters</title>
@ -314,5 +571,20 @@
</section>
</section>
</section>
<section id="dvbt2-params">
<title>DVB-T2 parameters</title>
<para>This section covers parameters that apply only to the DVB-T2 delivery method. DVB-T2
support is currently in the early stages development so expect this section to grow
and become more detailed with time.</para>
<section id="dvbt2-plp-id">
<title><constant>DTV_DVBT2_PLP_ID</constant></title>
<para>DVB-T2 supports Physical Layer Pipes (PLP) to allow transmission of
many data types via a single multiplex. The API will soon support this
at which point this section will be expanded.</para>
</section>
</section>
</section>
</section>

20
Documentation/DocBook/dvb/frontend.h.xml
View File

@ -176,14 +176,20 @@ typedef enum fe_transmit_mode {
TRANSMISSION_MODE_2K,
TRANSMISSION_MODE_8K,
TRANSMISSION_MODE_AUTO,
TRANSMISSION_MODE_4K
TRANSMISSION_MODE_4K,
TRANSMISSION_MODE_1K,
TRANSMISSION_MODE_16K,
TRANSMISSION_MODE_32K,
} fe_transmit_mode_t;
typedef enum fe_bandwidth {
BANDWIDTH_8_MHZ,
BANDWIDTH_7_MHZ,
BANDWIDTH_6_MHZ,
BANDWIDTH_AUTO
BANDWIDTH_AUTO,
BANDWIDTH_5_MHZ,
BANDWIDTH_10_MHZ,
BANDWIDTH_1_712_MHZ,
} fe_bandwidth_t;
@ -192,7 +198,10 @@ typedef enum fe_guard_interval {
GUARD_INTERVAL_1_16,
GUARD_INTERVAL_1_8,
GUARD_INTERVAL_1_4,
GUARD_INTERVAL_AUTO
GUARD_INTERVAL_AUTO,
GUARD_INTERVAL_1_128,
GUARD_INTERVAL_19_128,
GUARD_INTERVAL_19_256,
} fe_guard_interval_t;
@ -306,7 +315,9 @@ struct dvb_frontend_event {
#define DTV_ISDBS_TS_ID 42
#define DTV_MAX_COMMAND DTV_ISDBS_TS_ID
#define DTV_DVBT2_PLP_ID 43
#define DTV_MAX_COMMAND DTV_DVBT2_PLP_ID
typedef enum fe_pilot {
PILOT_ON,
@ -338,6 +349,7 @@ typedef enum fe_delivery_system {
SYS_DMBTH,
SYS_CMMB,
SYS_DAB,
SYS_DVBT2,
} fe_delivery_system_t;
struct dtv_cmds_h {

2
Documentation/DocBook/dvb/frontend.xml
View File

@ -139,7 +139,7 @@ consistently to the DiSEqC commands as described in the DiSEqC spec.</para>
<section id="frontend_sec_tone">
<title>SEC continuous tone</title>
<para>The continous 22KHz tone is usually used with non-DiSEqC capable LNBs to switch the
<para>The continuous 22KHz tone is usually used with non-DiSEqC capable LNBs to switch the
high/low band of a dual-band LNB. When using DiSEqC epuipment this voltage has to
be switched consistently to the DiSEqC commands as described in the DiSEqC
spec.</para>

82
Documentation/DocBook/genericirq.tmpl
View File

@ -191,8 +191,8 @@
<para>
Whenever an interrupt triggers, the lowlevel arch code calls into
the generic interrupt code by calling desc->handle_irq().
This highlevel IRQ handling function only uses desc->chip primitives
referenced by the assigned chip descriptor structure.
This highlevel IRQ handling function only uses desc->irq_data.chip
primitives referenced by the assigned chip descriptor structure.
</para>
</sect1>
<sect1 id="Highlevel_Driver_API">
@ -206,11 +206,11 @@
<listitem><para>enable_irq()</para></listitem>
<listitem><para>disable_irq_nosync() (SMP only)</para></listitem>
<listitem><para>synchronize_irq() (SMP only)</para></listitem>
<listitem><para>set_irq_type()</para></listitem>
<listitem><para>set_irq_wake()</para></listitem>
<listitem><para>set_irq_data()</para></listitem>
<listitem><para>set_irq_chip()</para></listitem>
<listitem><para>set_irq_chip_data()</para></listitem>
<listitem><para>irq_set_irq_type()</para></listitem>
<listitem><para>irq_set_irq_wake()</para></listitem>
<listitem><para>irq_set_handler_data()</para></listitem>
<listitem><para>irq_set_chip()</para></listitem>
<listitem><para>irq_set_chip_data()</para></listitem>
</itemizedlist>
See the autogenerated function documentation for details.
</para>
@ -225,6 +225,8 @@
<listitem><para>handle_fasteoi_irq</para></listitem>
<listitem><para>handle_simple_irq</para></listitem>
<listitem><para>handle_percpu_irq</para></listitem>
<listitem><para>handle_edge_eoi_irq</para></listitem>
<listitem><para>handle_bad_irq</para></listitem>
</itemizedlist>
The interrupt flow handlers (either predefined or architecture
specific) are assigned to specific interrupts by the architecture
@ -241,13 +243,13 @@
<programlisting>
default_enable(struct irq_data *data)
{
desc->chip->irq_unmask(data);
desc->irq_data.chip->irq_unmask(data);
}
default_disable(struct irq_data *data)
{
if (!delay_disable(data))
desc->chip->irq_mask(data);
desc->irq_data.chip->irq_mask(data);
}
default_ack(struct irq_data *data)
@ -284,9 +286,9 @@ noop(struct irq_data *data))
<para>
The following control flow is implemented (simplified excerpt):
<programlisting>
desc->chip->irq_mask();
handle_IRQ_event(desc->action);
desc->chip->irq_unmask();
desc->irq_data.chip->irq_mask_ack();
handle_irq_event(desc->action);
desc->irq_data.chip->irq_unmask();
</programlisting>
</para>
</sect3>
@ -300,8 +302,8 @@ desc->chip->irq_unmask();
<para>
The following control flow is implemented (simplified excerpt):
<programlisting>
handle_IRQ_event(desc->action);
desc->chip->irq_eoi();
handle_irq_event(desc->action);
desc->irq_data.chip->irq_eoi();
</programlisting>
</para>
</sect3>
@ -315,17 +317,17 @@ desc->chip->irq_eoi();
The following control flow is implemented (simplified excerpt):
<programlisting>
if (desc->status &amp; running) {
desc->chip->irq_mask();
desc->irq_data.chip->irq_mask_ack();
desc->status |= pending | masked;
return;
}
desc->chip->irq_ack();
desc->irq_data.chip->irq_ack();
desc->status |= running;
do {
if (desc->status &amp; masked)
desc->chip->irq_unmask();
desc->irq_data.chip->irq_unmask();
desc->status &amp;= ~pending;
handle_IRQ_event(desc->action);
handle_irq_event(desc->action);
} while (status &amp; pending);
desc->status &amp;= ~running;
</programlisting>
@ -344,7 +346,7 @@ desc->status &amp;= ~running;
<para>
The following control flow is implemented (simplified excerpt):
<programlisting>
handle_IRQ_event(desc->action);
handle_irq_event(desc->action);
</programlisting>
</para>
</sect3>
@ -362,12 +364,29 @@ handle_IRQ_event(desc->action);
<para>
The following control flow is implemented (simplified excerpt):
<programlisting>
handle_IRQ_event(desc->action);
if (desc->chip->irq_eoi)
desc->chip->irq_eoi();
if (desc->irq_data.chip->irq_ack)
desc->irq_data.chip->irq_ack();
handle_irq_event(desc->action);
if (desc->irq_data.chip->irq_eoi)
desc->irq_data.chip->irq_eoi();
</programlisting>
</para>
</sect3>
<sect3 id="EOI_Edge_IRQ_flow_handler">
<title>EOI Edge IRQ flow handler</title>
<para>
handle_edge_eoi_irq provides an abnomination of the edge
handler which is solely used to tame a badly wreckaged
irq controller on powerpc/cell.
</para>
</sect3>
<sect3 id="BAD_IRQ_flow_handler">
<title>Bad IRQ flow handler</title>
<para>
handle_bad_irq is used for spurious interrupts which
have no real handler assigned..
</para>
</sect3>
</sect2>
<sect2 id="Quirks_and_optimizations">
<title>Quirks and optimizations</title>
@ -410,6 +429,7 @@ if (desc->chip->irq_eoi)
<listitem><para>irq_mask_ack() - Optional, recommended for performance</para></listitem>
<listitem><para>irq_mask()</para></listitem>
<listitem><para>irq_unmask()</para></listitem>
<listitem><para>irq_eoi() - Optional, required for eoi flow handlers</para></listitem>
<listitem><para>irq_retrigger() - Optional</para></listitem>
<listitem><para>irq_set_type() - Optional</para></listitem>
<listitem><para>irq_set_wake() - Optional</para></listitem>
@ -424,32 +444,24 @@ if (desc->chip->irq_eoi)
<chapter id="doirq">
<title>__do_IRQ entry point</title>
<para>
The original implementation __do_IRQ() is an alternative entry
point for all types of interrupts.
The original implementation __do_IRQ() was an alternative entry
point for all types of interrupts. It not longer exists.
</para>
<para>
This handler turned out to be not suitable for all
interrupt hardware and was therefore reimplemented with split
functionality for egde/level/simple/percpu interrupts. This is not
functionality for edge/level/simple/percpu interrupts. This is not
only a functional optimization. It also shortens code paths for
interrupts.
</para>
<para>
To make use of the split implementation, replace the call to
__do_IRQ by a call to desc->handle_irq() and associate
the appropriate handler function to desc->handle_irq().
In most cases the generic handler implementations should
be sufficient.
</para>
</chapter>
<chapter id="locking">
<title>Locking on SMP</title>
<para>
The locking of chip registers is up to the architecture that
defines the chip primitives. There is a chip->lock field that can be used
for serialization, but the generic layer does not touch it. The per-irq
structure is protected via desc->lock, by the generic layer.
defines the chip primitives. The per-irq structure is
protected via desc->lock, by the generic layer.
</para>
</chapter>
<chapter id="structs">

2
Documentation/DocBook/kernel-locking.tmpl
View File

@ -1763,7 +1763,7 @@ as it would be on UP.
There is a furthur optimization possible here: remember our original
cache code, where there were no reference counts and the caller simply
held the lock whenever using the object? This is still possible: if
you hold the lock, noone can delete the object, so you don't need to
you hold the lock, no one can delete the object, so you don't need to
get and put the reference count.
</para>

10
Documentation/DocBook/libata.tmpl
View File

@ -1032,7 +1032,7 @@ and other resources, etc.
<listitem>
<para>
This is indicated by ICRC bit in the ERROR register and
means that corruption occurred during data transfer. Upto
means that corruption occurred during data transfer. Up to
ATA/ATAPI-7, the standard specifies that this bit is only
applicable to UDMA transfers but ATA/ATAPI-8 draft revision
1f says that the bit may be applicable to multiword DMA and
@ -1045,10 +1045,10 @@ and other resources, etc.
<term>ABRT error during data transfer or on completion</term>
<listitem>
<para>
Upto ATA/ATAPI-7, the standard specifies that ABRT could be
Up to ATA/ATAPI-7, the standard specifies that ABRT could be
set on ICRC errors and on cases where a device is not able
to complete a command. Combined with the fact that MWDMA
and PIO transfer errors aren't allowed to use ICRC bit upto
and PIO transfer errors aren't allowed to use ICRC bit up to
ATA/ATAPI-7, it seems to imply that ABRT bit alone could
indicate tranfer errors.
</para>
@ -1122,7 +1122,7 @@ and other resources, etc.
<para>
Depending on commands, not all STATUS/ERROR bits are
applicable. These non-applicable bits are marked with
&quot;na&quot; in the output descriptions but upto ATA/ATAPI-7
&quot;na&quot; in the output descriptions but up to ATA/ATAPI-7
no definition of &quot;na&quot; can be found. However,
ATA/ATAPI-8 draft revision 1f describes &quot;N/A&quot; as
follows.
@ -1507,7 +1507,7 @@ and other resources, etc.
<listitem>
<para>
CHS set up with INITIALIZE DEVICE PARAMETERS (seldomly used)
CHS set up with INITIALIZE DEVICE PARAMETERS (seldom used)
</para>
</listitem>

10
Documentation/DocBook/media-entities.tmpl
View File

@ -270,6 +270,7 @@
<!ENTITY sub-write SYSTEM "v4l/func-write.xml">
<!ENTITY sub-io SYSTEM "v4l/io.xml">
<!ENTITY sub-grey SYSTEM "v4l/pixfmt-grey.xml">
<!ENTITY sub-m420 SYSTEM "v4l/pixfmt-m420.xml">
<!ENTITY sub-nv12 SYSTEM "v4l/pixfmt-nv12.xml">
<!ENTITY sub-nv12m SYSTEM "v4l/pixfmt-nv12m.xml">
<!ENTITY sub-nv12mt SYSTEM "v4l/pixfmt-nv12mt.xml">
@ -292,8 +293,11 @@
<!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">
<!ENTITY sub-y10b SYSTEM "v4l/pixfmt-y10b.xml">
<!ENTITY sub-pixfmt SYSTEM "v4l/pixfmt.xml">
<!ENTITY sub-cropcap SYSTEM "v4l/vidioc-cropcap.xml">
<!ENTITY sub-dbg-g-register SYSTEM "v4l/vidioc-dbg-g-register.xml">
@ -370,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">

15
Documentation/DocBook/mtdnand.tmpl
View File

@ -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
@ -485,7 +484,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
Reed-Solomon library.
</para>
<para>
The ECC bytes must be placed immidiately after the data
The ECC bytes must be placed immediately after the data
bytes in order to make the syndrome generator work. This
is contrary to the usual layout used by software ECC. The
separation of data and out of band area is not longer
@ -629,7 +628,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
holds the bad block table. Store a pointer to the pattern
in the pattern field. Further the length of the pattern has to be
stored in len and the offset in the spare area must be given
in the offs member of the nand_bbt_descr stucture. For mirrored
in the offs member of the nand_bbt_descr structure. For mirrored
bad block tables different patterns are mandatory.</para></listitem>
<listitem><para>Table creation</para>
<para>Set the option NAND_BBT_CREATE to enable the table creation
@ -648,7 +647,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
<listitem><para>Table version control</para>
<para>Set the option NAND_BBT_VERSION to enable the table version control.
It's highly recommended to enable this for mirrored tables with write
support. It makes sure that the risk of loosing the bad block
support. It makes sure that the risk of losing the bad block
table information is reduced to the loss of the information about the
one worn out block which should be marked bad. The version is stored in
4 consecutive bytes in the spare area of the device. The position of
@ -1060,19 +1059,19 @@ data in this page</entry>
<row>
<entry>0x3D</entry>
<entry>ECC byte 21</entry>
<entry>Error correction code byte 0 of the eigth 256 Bytes of data
<entry>Error correction code byte 0 of the eighth 256 Bytes of data
in this page</entry>
</row>
<row>
<entry>0x3E</entry>
<entry>ECC byte 22</entry>
<entry>Error correction code byte 1 of the eigth 256 Bytes of data
<entry>Error correction code byte 1 of the eighth 256 Bytes of data
in this page</entry>
</row>
<row>
<entry>0x3F</entry>
<entry>ECC byte 23</entry>
<entry>Error correction code byte 2 of the eigth 256 Bytes of data
<entry>Error correction code byte 2 of the eighth 256 Bytes of data
in this page</entry>
</row>
</tbody></tgroup></informaltable>

4
Documentation/DocBook/regulator.tmpl
View File

@ -267,8 +267,8 @@
<sect1 id="machine-constraint">
<title>Constraints</title>
<para>
As well as definining the connections the machine interface
also provides constraints definining the operations that
As well as defining the connections the machine interface
also provides constraints defining the operations that
clients are allowed to perform and the parameters that may be
set. This is required since generally regulator devices will
offer more flexibility than it is safe to use on a given

2
Documentation/DocBook/uio-howto.tmpl
View File

@ -797,7 +797,7 @@ framework to set up sysfs files for this region. Simply leave it alone.
perform some initialization. After that, your hardware
starts working and will generate an interrupt as soon
as it's finished, has some data available, or needs your
attention because an error occured.
attention because an error occurred.
</para>
<para>
<filename>/dev/uioX</filename> is a read-only file. A

2
Documentation/DocBook/usb.tmpl
View File

@ -690,7 +690,7 @@ usbdev_ioctl (int fd, int ifno, unsigned request, void *param)
</para><para>
This request lets kernel drivers talk to user mode code
through filesystem operations even when they don't create
a charactor or block special device.
a character or block special device.
It's also been used to do things like ask devices what
device special file should be used.
Two pre-defined ioctls are used

2
Documentation/DocBook/v4l/common.xml
View File

@ -100,7 +100,7 @@ linux-kernel@vger.kernel.org, 2002-11-20. --></para>
<para>By convention system administrators create various
character device special files with these major and minor numbers in
the <filename>/dev</filename> directory. The names recomended for the
the <filename>/dev</filename> directory. The names recommended for the
different V4L2 device types are listed in <xref linkend="devices" />.
</para>

2
Documentation/DocBook/v4l/controls.xml
View File

@ -1243,7 +1243,7 @@ values are:</entry>
</row><row><entry spanname="descr">Mutes the audio when
capturing. This is not done by muting audio hardware, which can still
produce a slight hiss, but in the encoder itself, guaranteeing a fixed
and reproducable audio bitstream. 0 = unmuted, 1 = muted.</entry>
and reproducible audio bitstream. 0 = unmuted, 1 = muted.</entry>
</row>
<row><entry></entry></row>
<row id="v4l2-mpeg-video-encoding">

2
Documentation/DocBook/v4l/dev-subdev.xml
View File

@ -90,7 +90,7 @@
processing hardware.</para>
<figure id="pipeline-scaling">
<title>Image Format Negotation on Pipelines</title>
<title>Image Format Negotiation on Pipelines</title>
<mediaobject>
<imageobject>
<imagedata fileref="pipeline.pdf" format="PS" />

2
Documentation/DocBook/v4l/libv4l.xml
View File

@ -140,7 +140,7 @@ and is not locked sets the cid to the scaled value.
<para>int v4l2_get_control(int fd, int cid) -
This function returns a value of 0 - 65535, scaled to from the actual range
of the given v4l control id. when the cid does not exist, could not be
accessed for some reason, or some error occured 0 is returned.
accessed for some reason, or some error occurred 0 is returned.
</para></listitem>
</itemizedlist>
</section>

6
Documentation/DocBook/v4l/media-controller.xml
View File

@ -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;

2
Documentation/DocBook/v4l/media-ioc-setup-link.xml
View File

@ -34,7 +34,7 @@
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>MEDIA_IOC_ENUM_LINKS</para>
<para>MEDIA_IOC_SETUP_LINK</para>
</listitem>
</varlistentry>
<varlistentry>

147
Documentation/DocBook/v4l/pixfmt-m420.xml 100644
View File

@ -0,0 +1,147 @@
<refentry id="V4L2-PIX-FMT-M420">
<refmeta>
<refentrytitle>V4L2_PIX_FMT_M420 ('M420')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname><constant>V4L2_PIX_FMT_M420</constant></refname>
<refpurpose>Format with &frac12; horizontal and vertical chroma
resolution, also known as YUV 4:2:0. Hybrid plane line-interleaved
layout.</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>M420 is a YUV format with &frac12; horizontal and vertical chroma
subsampling (YUV 4:2:0). Pixels are organized as interleaved luma and
chroma planes. Two lines of luma data are followed by one line of chroma
data.</para>
<para>The luma plane has one byte per pixel. The chroma plane contains
interleaved CbCr pixels subsampled by &frac12; in the horizontal and
vertical directions. Each CbCr pair belongs to four pixels. For example,
Cb<subscript>0</subscript>/Cr<subscript>0</subscript> belongs to
Y'<subscript>00</subscript>, Y'<subscript>01</subscript>,
Y'<subscript>10</subscript>, Y'<subscript>11</subscript>.</para>
<para>All line lengths are identical: if the Y lines include pad bytes
so do the CbCr lines.</para>
<example>
<title><constant>V4L2_PIX_FMT_M420</constant> 4 &times; 4
pixel image</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="5" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start&nbsp;+&nbsp;0:</entry>
<entry>Y'<subscript>00</subscript></entry>
<entry>Y'<subscript>01</subscript></entry>
<entry>Y'<subscript>02</subscript></entry>
<entry>Y'<subscript>03</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;4:</entry>
<entry>Y'<subscript>10</subscript></entry>
<entry>Y'<subscript>11</subscript></entry>
<entry>Y'<subscript>12</subscript></entry>
<entry>Y'<subscript>13</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;8:</entry>
<entry>Cb<subscript>00</subscript></entry>
<entry>Cr<subscript>00</subscript></entry>
<entry>Cb<subscript>01</subscript></entry>
<entry>Cr<subscript>01</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;16:</entry>
<entry>Y'<subscript>20</subscript></entry>
<entry>Y'<subscript>21</subscript></entry>
<entry>Y'<subscript>22</subscript></entry>
<entry>Y'<subscript>23</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;20:</entry>
<entry>Y'<subscript>30</subscript></entry>
<entry>Y'<subscript>31</subscript></entry>
<entry>Y'<subscript>32</subscript></entry>
<entry>Y'<subscript>33</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;24:</entry>
<entry>Cb<subscript>10</subscript></entry>
<entry>Cr<subscript>10</subscript></entry>
<entry>Cb<subscript>11</subscript></entry>
<entry>Cr<subscript>11</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
<formalpara>
<title>Color Sample Location.</title>
<para>
<informaltable frame="none">
<tgroup cols="7" align="center">
<tbody valign="top">
<row>
<entry></entry>
<entry>0</entry><entry></entry><entry>1</entry><entry></entry>
<entry>2</entry><entry></entry><entry>3</entry>
</row>
<row>
<entry>0</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
<row>
<entry></entry>
<entry></entry><entry>C</entry><entry></entry><entry></entry>
<entry></entry><entry>C</entry><entry></entry>
</row>
<row>
<entry>1</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
<row>
<entry></entry>
</row>
<row>
<entry>2</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
<row>
<entry></entry>
<entry></entry><entry>C</entry><entry></entry><entry></entry>
<entry></entry><entry>C</entry><entry></entry>
</row>
<row>
<entry>3</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "pixfmt.sgml"
indent-tabs-mode: nil
End:
-->

43
Documentation/DocBook/v4l/pixfmt-y10b.xml 100644
View File

@ -0,0 +1,43 @@
<refentry id="V4L2-PIX-FMT-Y10BPACK">
<refmeta>
<refentrytitle>V4L2_PIX_FMT_Y10BPACK ('Y10B')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname><constant>V4L2_PIX_FMT_Y10BPACK</constant></refname>
<refpurpose>Grey-scale image as a bit-packed array</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is a packed grey-scale image format with a depth of 10 bits per
pixel. Pixels are stored in a bit-packed array of 10bit bits per pixel,
with no padding between them and with the most significant bits coming
first from the left.</para>
<example>
<title><constant>V4L2_PIX_FMT_Y10BPACK</constant> 4 pixel data stream taking 5 bytes</title>
<formalpara>
<title>Bit-packed representation</title>
<para>pixels cross the byte boundary and have a ratio of 5 bytes for each 4
pixels.
<informaltable frame="all">
<tgroup cols="5" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>Y'<subscript>00[9:2]</subscript></entry>
<entry>Y'<subscript>00[1:0]</subscript>Y'<subscript>01[9:4]</subscript></entry>
<entry>Y'<subscript>01[3:0]</subscript>Y'<subscript>02[9:6]</subscript></entry>
<entry>Y'<subscript>02[5:0]</subscript>Y'<subscript>03[9:8]</subscript></entry>
<entry>Y'<subscript>03[7:0]</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>

79
Documentation/DocBook/v4l/pixfmt-y12.xml 100644
View File

@ -0,0 +1,79 @@
<refentry id="V4L2-PIX-FMT-Y12">
<refmeta>
<refentrytitle>V4L2_PIX_FMT_Y12 ('Y12 ')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname><constant>V4L2_PIX_FMT_Y12</constant></refname>
<refpurpose>Grey-scale image</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is a grey-scale image with a depth of 12 bits per pixel. Pixels
are stored in 16-bit words with unused high bits padded with 0. The least
significant byte is stored at lower memory addresses (little-endian).</para>
<example>
<title><constant>V4L2_PIX_FMT_Y12</constant> 4 &times; 4
pixel image</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="9" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start&nbsp;+&nbsp;0:</entry>
<entry>Y'<subscript>00low</subscript></entry>
<entry>Y'<subscript>00high</subscript></entry>
<entry>Y'<subscript>01low</subscript></entry>
<entry>Y'<subscript>01high</subscript></entry>
<entry>Y'<subscript>02low</subscript></entry>
<entry>Y'<subscript>02high</subscript></entry>
<entry>Y'<subscript>03low</subscript></entry>
<entry>Y'<subscript>03high</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;8:</entry>
<entry>Y'<subscript>10low</subscript></entry>
<entry>Y'<subscript>10high</subscript></entry>
<entry>Y'<subscript>11low</subscript></entry>
<entry>Y'<subscript>11high</subscript></entry>
<entry>Y'<subscript>12low</subscript></entry>
<entry>Y'<subscript>12high</subscript></entry>
<entry>Y'<subscript>13low</subscript></entry>
<entry>Y'<subscript>13high</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;16:</entry>
<entry>Y'<subscript>20low</subscript></entry>
<entry>Y'<subscript>20high</subscript></entry>
<entry>Y'<subscript>21low</subscript></entry>
<entry>Y'<subscript>21high</subscript></entry>
<entry>Y'<subscript>22low</subscript></entry>
<entry>Y'<subscript>22high</subscript></entry>
<entry>Y'<subscript>23low</subscript></entry>
<entry>Y'<subscript>23high</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;24:</entry>
<entry>Y'<subscript>30low</subscript></entry>
<entry>Y'<subscript>30high</subscript></entry>
<entry>Y'<subscript>31low</subscript></entry>
<entry>Y'<subscript>31high</subscript></entry>
<entry>Y'<subscript>32low</subscript></entry>
<entry>Y'<subscript>32high</subscript></entry>
<entry>Y'<subscript>33low</subscript></entry>
<entry>Y'<subscript>33high</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>

4
Documentation/DocBook/v4l/pixfmt.xml
View File

@ -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">
@ -696,6 +697,8 @@ information.</para>
&sub-packed-yuv;
&sub-grey;
&sub-y10;
&sub-y12;
&sub-y10b;
&sub-y16;
&sub-yuyv;
&sub-uyvy;
@ -711,6 +714,7 @@ information.</para>
&sub-nv12m;
&sub-nv12mt;
&sub-nv16;
&sub-m420;
</section>
<section>

2
Documentation/DocBook/v4l/remote_controllers.xml
View File

@ -133,7 +133,7 @@ different IR's. Due to that, V4L2 API now specifies a standard for mapping Media
<row><entry><constant>KEY_LEFT</constant></entry><entry>Left key</entry><entry>LEFT</entry></row>
<row><entry><constant>KEY_RIGHT</constant></entry><entry>Right key</entry><entry>RIGHT</entry></row>
<row><entry><emphasis role="bold">Miscelaneous keys</emphasis></entry></row>
<row><entry><emphasis role="bold">Miscellaneous keys</emphasis></entry></row>
<row><entry><constant>KEY_DOT</constant></entry><entry>Return a dot</entry><entry>.</entry></row>
<row><entry><constant>KEY_FN</constant></entry><entry>Select a function</entry><entry>FUNCTION</entry></row>

105
Documentation/DocBook/v4l/subdev-formats.xml
View File

@ -456,6 +456,23 @@
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SGBRG8-1X8">
<entry>V4L2_MBUS_FMT_SGBRG8_1X8</entry>
<entry>0x3013</entry>
<entry></entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>g<subscript>7</subscript></entry>
<entry>g<subscript>6</subscript></entry>
<entry>g<subscript>5</subscript></entry>
<entry>g<subscript>4</subscript></entry>
<entry>g<subscript>3</subscript></entry>
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SGRBG8-1X8">
<entry>V4L2_MBUS_FMT_SGRBG8_1X8</entry>
<entry>0x3002</entry>
@ -473,6 +490,23 @@
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SRGGB8-1X8">
<entry>V4L2_MBUS_FMT_SRGGB8_1X8</entry>
<entry>0x3014</entry>
<entry></entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>r<subscript>7</subscript></entry>
<entry>r<subscript>6</subscript></entry>
<entry>r<subscript>5</subscript></entry>
<entry>r<subscript>4</subscript></entry>
<entry>r<subscript>3</subscript></entry>
<entry>r<subscript>2</subscript></entry>
<entry>r<subscript>1</subscript></entry>
<entry>r<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SBGGR10-DPCM8-1X8">
<entry>V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8</entry>
<entry>0x300b</entry>
@ -2159,6 +2193,31 @@
<entry>u<subscript>1</subscript></entry>
<entry>u<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-Y12-1X12">
<entry>V4L2_MBUS_FMT_Y12_1X12</entry>
<entry>0x2013</entry>
<entry></entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>y<subscript>11</subscript></entry>
<entry>y<subscript>10</subscript></entry>
<entry>y<subscript>9</subscript></entry>
<entry>y<subscript>8</subscript></entry>
<entry>y<subscript>7</subscript></entry>
<entry>y<subscript>6</subscript></entry>
<entry>y<subscript>5</subscript></entry>
<entry>y<subscript>4</subscript></entry>
<entry>y<subscript>3</subscript></entry>
<entry>y<subscript>2</subscript></entry>
<entry>y<subscript>1</subscript></entry>
<entry>y<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-UYVY8-1X16">
<entry>V4L2_MBUS_FMT_UYVY8_1X16</entry>
<entry>0x200f</entry>
@ -2463,5 +2522,51 @@
</tgroup>
</table>
</section>
<section>
<title>JPEG Compressed Formats</title>
<para>Those data formats consist of an ordered sequence of 8-bit bytes
obtained from JPEG compression process. Additionally to the
<constant>_JPEG</constant> prefix the format code is made of
the following information.
<itemizedlist>
<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>The following table lists existing JPEG compressed formats.</para>
<table pgwide="0" frame="none" id="v4l2-mbus-pixelcode-jpeg">
<title>JPEG Formats</title>
<tgroup cols="3">
<colspec colname="id" align="left" />
<colspec colname="code" align="left"/>
<colspec colname="remarks" align="left"/>
<thead>
<row>
<entry>Identifier</entry>
<entry>Code</entry>
<entry>Remarks</entry>
</row>
</thead>
<tbody valign="top">
<row id="V4L2-MBUS-FMT-JPEG-1X8">
<entry>V4L2_MBUS_FMT_JPEG_1X8</entry>
<entry>0x4001</entry>
<entry>Besides of its usage for the parallel bus this format is
recommended for transmission of JPEG data over MIPI CSI bus
using the User Defined 8-bit Data types.
</entry>
</row>
</tbody>
</tgroup>
</table>
</section>
</section>
</section>

4
Documentation/DocBook/v4l/videodev2.h.xml
View File

@ -311,6 +311,9 @@ struct <link linkend="v4l2-pix-format">v4l2_pix_format</link> {
#define <link linkend="V4L2-PIX-FMT-Y10">V4L2_PIX_FMT_Y10</link> v4l2_fourcc('Y', '1', '0', ' ') /* 10 Greyscale */
#define <link linkend="V4L2-PIX-FMT-Y16">V4L2_PIX_FMT_Y16</link> v4l2_fourcc('Y', '1', '6', ' ') /* 16 Greyscale */
/* Grey bit-packed formats */
#define <link linkend="V4L2-PIX-FMT-Y10BPACK">V4L2_PIX_FMT_Y10BPACK</link> v4l2_fourcc('Y', '1', '0', 'B') /* 10 Greyscale bit-packed */
/* Palette formats */
#define <link linkend="V4L2-PIX-FMT-PAL8">V4L2_PIX_FMT_PAL8</link> v4l2_fourcc('P', 'A', 'L', '8') /* 8 8-bit palette */
@ -333,6 +336,7 @@ struct <link linkend="v4l2-pix-format">v4l2_pix_format</link> {
#define <link linkend="V4L2-PIX-FMT-YUV420">V4L2_PIX_FMT_YUV420</link> v4l2_fourcc('Y', 'U', '1', '2') /* 12 YUV 4:2:0 */
#define <link linkend="V4L2-PIX-FMT-HI240">V4L2_PIX_FMT_HI240</link> v4l2_fourcc('H', 'I', '2', '4') /* 8 8-bit color */
#define <link linkend="V4L2-PIX-FMT-HM12">V4L2_PIX_FMT_HM12</link> v4l2_fourcc('H', 'M', '1', '2') /* 8 YUV 4:2:0 16x16 macroblocks */
#define <link linkend="V4L2-PIX-FMT-M420">V4L2_PIX_FMT_M420</link> v4l2_fourcc('M', '4', '2', '0') /* 12 YUV 4:2:0 2 lines y, 1 line uv interleaved */
/* two planes -- one Y, one Cr + Cb interleaved */
#define <link linkend="V4L2-PIX-FMT-NV12">V4L2_PIX_FMT_NV12</link> v4l2_fourcc('N', 'V', '1', '2') /* 12 Y/CbCr 4:2:0 */

2
Documentation/DocBook/writing-an-alsa-driver.tmpl
View File

@ -4784,7 +4784,7 @@ struct _snd_pcm_runtime {
FM registers can be directly accessed through the direct-FM API,
defined in <filename>&lt;sound/asound_fm.h&gt;</filename>. In
ALSA native mode, FM registers are accessed through
the Hardware-Dependant Device direct-FM extension API, whereas in
the Hardware-Dependent Device direct-FM extension API, whereas in
OSS compatible mode, FM registers can be accessed with the OSS
direct-FM compatible API in <filename>/dev/dmfmX</filename> device.
</para>

2
Documentation/HOWTO
View File

@ -209,7 +209,7 @@ tools. One such tool that is particularly recommended is the Linux
Cross-Reference project, which is able to present source code in a
self-referential, indexed webpage format. An excellent up-to-date
repository of the kernel code may be found at:
http://users.sosdg.org/~qiyong/lxr/
http://lxr.linux.no/+trees
The development process

17
Documentation/IRQ-affinity.txt
View File

@ -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.

4
Documentation/PCI/MSI-HOWTO.txt
View File

@ -253,8 +253,8 @@ In constrast, MSI is restricted to a maximum of 32 interrupts (and
must be a power of two). In addition, the MSI interrupt vectors must
be allocated consecutively, so the system may not be able to allocate
as many vectors for MSI as it could for MSI-X. On some platforms, MSI
interrupts must all be targetted at the same set of CPUs whereas MSI-X
interrupts can all be targetted at different CPUs.
interrupts must all be targeted at the same set of CPUs whereas MSI-X
interrupts can all be targeted at different CPUs.
4.5.2 Spinlocks

2
Documentation/RCU/00-INDEX
View File

@ -21,7 +21,7 @@ rcu.txt
RTFP.txt
- List of RCU papers (bibliography) going back to 1980.
stallwarn.txt
- RCU CPU stall warnings (CONFIG_RCU_CPU_STALL_DETECTOR)
- RCU CPU stall warnings (module parameter rcu_cpu_stall_suppress)
torture.txt
- RCU Torture Test Operation (CONFIG_RCU_TORTURE_TEST)
trace.txt

23
Documentation/RCU/stallwarn.txt
View File

@ -1,22 +1,25 @@
Using RCU's CPU Stall Detector
The CONFIG_RCU_CPU_STALL_DETECTOR kernel config parameter enables
RCU's CPU stall detector, which detects conditions that unduly delay
RCU grace periods. The stall detector's idea of what constitutes
"unduly delayed" is controlled by a set of C preprocessor macros:
The rcu_cpu_stall_suppress module parameter enables RCU's CPU stall
detector, which detects conditions that unduly delay RCU grace periods.
This module parameter enables CPU stall detection by default, but
may be overridden via boot-time parameter or at runtime via sysfs.
The stall detector's idea of what constitutes "unduly delayed" is
controlled by a set of kernel configuration variables and cpp macros:
RCU_SECONDS_TILL_STALL_CHECK
CONFIG_RCU_CPU_STALL_TIMEOUT
This macro defines the period of time that RCU will wait from
the beginning of a grace period until it issues an RCU CPU
stall warning. This time period is normally ten seconds.
This kernel configuration parameter defines the period of time
that RCU will wait from the beginning of a grace period until it
issues an RCU CPU stall warning. This time period is normally
ten seconds.
RCU_SECONDS_TILL_STALL_RECHECK
This macro defines the period of time that RCU will wait after
issuing a stall warning until it issues another stall warning
for the same stall. This time period is normally set to thirty
seconds.
for the same stall. This time period is normally set to three
times the check interval plus thirty seconds.
RCU_STALL_RAT_DELAY

295
Documentation/RCU/trace.txt
View File

@ -10,34 +10,46 @@ for rcutree and next for rcutiny.
CONFIG_TREE_RCU and CONFIG_TREE_PREEMPT_RCU debugfs Files and Formats
These implementations of RCU provides five debugfs files under the
top-level directory RCU: rcu/rcudata (which displays fields in struct
rcu_data), rcu/rcudata.csv (which is a .csv spreadsheet version of
rcu/rcudata), rcu/rcugp (which displays grace-period counters),
rcu/rcuhier (which displays the struct rcu_node hierarchy), and
rcu/rcu_pending (which displays counts of the reasons that the
rcu_pending() function decided that there was core RCU work to do).
These implementations of RCU provides several debugfs files under the
top-level directory "rcu":
rcu/rcudata:
Displays fields in struct rcu_data.
rcu/rcudata.csv:
Comma-separated values spreadsheet version of rcudata.
rcu/rcugp:
Displays grace-period counters.
rcu/rcuhier:
Displays the struct rcu_node hierarchy.
rcu/rcu_pending:
Displays counts of the reasons rcu_pending() decided that RCU had
work to do.
rcu/rcutorture:
Displays rcutorture test progress.
rcu/rcuboost:
Displays RCU boosting statistics. Only present if
CONFIG_RCU_BOOST=y.
The output of "cat rcu/rcudata" looks as follows:
rcu_sched:
0 c=17829 g=17829 pq=1 pqc=17829 qp=0 dt=10951/1 dn=0 df=1101 of=0 ri=36 ql=0 b=10
1 c=17829 g=17829 pq=1 pqc=17829 qp=0 dt=16117/1 dn=0 df=1015 of=0 ri=0 ql=0 b=10
2 c=17829 g=17829 pq=1 pqc=17829 qp=0 dt=1445/1 dn=0 df=1839 of=0 ri=0 ql=0 b=10
3 c=17829 g=17829 pq=1 pqc=17829 qp=0 dt=6681/1 dn=0 df=1545 of=0 ri=0 ql=0 b=10
4 c=17829 g=17829 pq=1 pqc=17829 qp=0 dt=1003/1 dn=0 df=1992 of=0 ri=0 ql=0 b=10
5 c=17829 g=17830 pq=1 pqc=17829 qp=1 dt=3887/1 dn=0 df=3331 of=0 ri=4 ql=2 b=10
6 c=17829 g=17829 pq=1 pqc=17829 qp=0 dt=859/1 dn=0 df=3224 of=0 ri=0 ql=0 b=10
7 c=17829 g=17830 pq=0 pqc=17829 qp=1 dt=3761/1 dn=0 df=1818 of=0 ri=0 ql=2 b=10
0 c=20972 g=20973 pq=1 pqc=20972 qp=0 dt=545/1/0 df=50 of=0 ri=0 ql=163 qs=NRW. kt=0/W/0 ktl=ebc3 b=10 ci=153737 co=0 ca=0
1 c=20972 g=20973 pq=1 pqc=20972 qp=0 dt=967/1/0 df=58 of=0 ri=0 ql=634 qs=NRW. kt=0/W/1 ktl=58c b=10 ci=191037 co=0 ca=0
2 c=20972 g=20973 pq=1 pqc=20972 qp=0 dt=1081/1/0 df=175 of=0 ri=0 ql=74 qs=N.W. kt=0/W/2 ktl=da94 b=10 ci=75991 co=0 ca=0
3 c=20942 g=20943 pq=1 pqc=20942 qp=1 dt=1846/0/0 df=404 of=0 ri=0 ql=0 qs=.... kt=0/W/3 ktl=d1cd b=10 ci=72261 co=0 ca=0
4 c=20972 g=20973 pq=1 pqc=20972 qp=0 dt=369/1/0 df=83 of=0 ri=0 ql=48 qs=N.W. kt=0/W/4 ktl=e0e7 b=10 ci=128365 co=0 ca=0
5 c=20972 g=20973 pq=1 pqc=20972 qp=0 dt=381/1/0 df=64 of=0 ri=0 ql=169 qs=NRW. kt=0/W/5 ktl=fb2f b=10 ci=164360 co=0 ca=0
6 c=20972 g=20973 pq=1 pqc=20972 qp=0 dt=1037/1/0 df=183 of=0 ri=0 ql=62 qs=N.W. kt=0/W/6 ktl=d2ad b=10 ci=65663 co=0 ca=0
7 c=20897 g=20897 pq=1 pqc=20896 qp=0 dt=1572/0/0 df=382 of=0 ri=0 ql=0 qs=.... kt=0/W/7 ktl=cf15 b=10 ci=75006 co=0 ca=0
rcu_bh:
0 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=10951/1 dn=0 df=0 of=0 ri=0 ql=0 b=10
1 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=16117/1 dn=0 df=13 of=0 ri=0 ql=0 b=10
2 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=1445/1 dn=0 df=15 of=0 ri=0 ql=0 b=10
3 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=6681/1 dn=0 df=9 of=0 ri=0 ql=0 b=10
4 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=1003/1 dn=0 df=15 of=0 ri=0 ql=0 b=10
5 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=3887/1 dn=0 df=15 of=0 ri=0 ql=0 b=10
6 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=859/1 dn=0 df=15 of=0 ri=0 ql=0 b=10
7 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=3761/1 dn=0 df=15 of=0 ri=0 ql=0 b=10
0 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=545/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/0 ktl=ebc3 b=10 ci=0 co=0 ca=0
1 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=967/1/0 df=3 of=0 ri=1 ql=0 qs=.... kt=0/W/1 ktl=58c b=10 ci=151 co=0 ca=0
2 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=1081/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/2 ktl=da94 b=10 ci=0 co=0 ca=0
3 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=1846/0/0 df=8 of=0 ri=1 ql=0 qs=.... kt=0/W/3 ktl=d1cd b=10 ci=0 co=0 ca=0
4 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=369/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/4 ktl=e0e7 b=10 ci=0 co=0 ca=0
5 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=381/1/0 df=4 of=0 ri=1 ql=0 qs=.... kt=0/W/5 ktl=fb2f b=10 ci=0 co=0 ca=0
6 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=1037/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/6 ktl=d2ad b=10 ci=0 co=0 ca=0
7 c=1474 g=1474 pq=1 pqc=1473 qp=0 dt=1572/0/0 df=8 of=0 ri=1 ql=0 qs=.... kt=0/W/7 ktl=cf15 b=10 ci=0 co=0 ca=0
The first section lists the rcu_data structures for rcu_sched, the second
for rcu_bh. Note that CONFIG_TREE_PREEMPT_RCU kernels will have an
@ -52,17 +64,18 @@ o The number at the beginning of each line is the CPU number.
substantially larger than the number of actual CPUs.
o "c" is the count of grace periods that this CPU believes have
completed. CPUs in dynticks idle mode may lag quite a ways
behind, for example, CPU 4 under "rcu_sched" above, which has
slept through the past 25 RCU grace periods. It is not unusual
to see CPUs lagging by thousands of grace periods.
completed. Offlined CPUs and CPUs in dynticks idle mode may
lag quite a ways behind, for example, CPU 6 under "rcu_sched"
above, which has been offline through not quite 40,000 RCU grace
periods. It is not unusual to see CPUs lagging by thousands of
grace periods.
o "g" is the count of grace periods that this CPU believes have
started. Again, CPUs in dynticks idle mode may lag behind.
If the "c" and "g" values are equal, this CPU has already
reported a quiescent state for the last RCU grace period that
it is aware of, otherwise, the CPU believes that it owes RCU a
quiescent state.
started. Again, offlined CPUs and CPUs in dynticks idle mode
may lag behind. If the "c" and "g" values are equal, this CPU
has already reported a quiescent state for the last RCU grace
period that it is aware of, otherwise, the CPU believes that it
owes RCU a quiescent state.
o "pq" indicates that this CPU has passed through a quiescent state
for the current grace period. It is possible for "pq" to be
@ -81,22 +94,16 @@ o "pqc" indicates which grace period the last-observed quiescent
the next grace period!
o "qp" indicates that RCU still expects a quiescent state from
this CPU.
this CPU. Offlined CPUs and CPUs in dyntick idle mode might
well have qp=1, which is OK: RCU is still ignoring them.
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.
@ -108,7 +115,7 @@ o "df" is the number of times that some other CPU has forced a
o "of" is the number of times that some other CPU has forced a
quiescent state on behalf of this CPU due to this CPU being
offline. In a perfect world, this might neve happen, but it
offline. In a perfect world, this might never happen, but it
turns out that offlining and onlining a CPU can take several grace
periods, and so there is likely to be an extended period of time
when RCU believes that the CPU is online when it really is not.
@ -125,6 +132,62 @@ o "ql" is the number of RCU callbacks currently residing on
of what state they are in (new, waiting for grace period to
start, waiting for grace period to end, ready to invoke).
o "qs" gives an indication of the state of the callback queue
with four characters:
"N" Indicates that there are callbacks queued that are not
ready to be handled by the next grace period, and thus
will be handled by the grace period following the next
one.
"R" Indicates that there are callbacks queued that are
ready to be handled by the next grace period.
"W" Indicates that there are callbacks queued that are
waiting on the current grace period.
"D" Indicates that there are callbacks queued that have
already been handled by a prior grace period, and are
thus waiting to be invoked. Note that callbacks in
the process of being invoked are not counted here.
Callbacks in the process of being invoked are those
that have been removed from the rcu_data structures
queues by rcu_do_batch(), but which have not yet been
invoked.
If there are no callbacks in a given one of the above states,
the corresponding character is replaced by ".".
o "kt" is the per-CPU kernel-thread state. The digit preceding
the first slash is zero if there is no work pending and 1
otherwise. The character between the first pair of slashes is
as follows:
"S" The kernel thread is stopped, in other words, all
CPUs corresponding to this rcu_node structure are
offline.
"R" The kernel thread is running.
"W" The kernel thread is waiting because there is no work
for it to do.
"O" The kernel thread is waiting because it has been
forced off of its designated CPU or because its
->cpus_allowed mask permits it to run on other than
its designated CPU.
"Y" The kernel thread is yielding to avoid hogging CPU.
"?" Unknown value, indicates a bug.
The number after the final slash is the CPU that the kthread
is actually running on.
o "ktl" is the low-order 16 bits (in hexadecimal) of the count of
the number of times that this CPU's per-CPU kthread has gone
through its loop servicing invoke_rcu_cpu_kthread() requests.
o "b" is the batch limit for this CPU. If more than this number
of RCU callbacks is ready to invoke, then the remainder will
be deferred.
@ -174,14 +237,14 @@ o "gpnum" is the number of grace periods that have started. It is
The output of "cat rcu/rcuhier" looks as follows, with very long lines:
c=6902 g=6903 s=2 jfq=3 j=72c7 nfqs=13142/nfqsng=0(13142) fqlh=6
1/1 .>. 0:127 ^0
3/3 .>. 0:35 ^0 0/0 .>. 36:71 ^1 0/0 .>. 72:107 ^2 0/0 .>. 108:127 ^3
3/3f .>. 0:5 ^0 2/3 .>. 6:11 ^1 0/0 .>. 12:17 ^2 0/0 .>. 18:23 ^3 0/0 .>. 24:29 ^4 0/0 .>. 30:35 ^5 0/0 .>. 36:41 ^0 0/0 .>. 42:47 ^1 0/0 .>. 48:53 ^2 0/0 .>. 54:59 ^3 0/0 .>. 60:65 ^4 0/0 .>. 66:71 ^5 0/0 .>. 72:77 ^0 0/0 .>. 78:83 ^1 0/0 .>. 84:89 ^2 0/0 .>. 90:95 ^3 0/0 .>. 96:101 ^4 0/0 .>. 102:107 ^5 0/0 .>. 108:113 ^0 0/0 .>. 114:119 ^1 0/0 .>. 120:125 ^2 0/0 .>. 126:127 ^3
1/1 ..>. 0:127 ^0
3/3 ..>. 0:35 ^0 0/0 ..>. 36:71 ^1 0/0 ..>. 72:107 ^2 0/0 ..>. 108:127 ^3
3/3f ..>. 0:5 ^0 2/3 ..>. 6:11 ^1 0/0 ..>. 12:17 ^2 0/0 ..>. 18:23 ^3 0/0 ..>. 24:29 ^4 0/0 ..>. 30:35 ^5 0/0 ..>. 36:41 ^0 0/0 ..>. 42:47 ^1 0/0 ..>. 48:53 ^2 0/0 ..>. 54:59 ^3 0/0 ..>. 60:65 ^4 0/0 ..>. 66:71 ^5 0/0 ..>. 72:77 ^0 0/0 ..>. 78:83 ^1 0/0 ..>. 84:89 ^2 0/0 ..>. 90:95 ^3 0/0 ..>. 96:101 ^4 0/0 ..>. 102:107 ^5 0/0 ..>. 108:113 ^0 0/0 ..>. 114:119 ^1 0/0 ..>. 120:125 ^2 0/0 ..>. 126:127 ^3
rcu_bh:
c=-226 g=-226 s=1 jfq=-5701 j=72c7 nfqs=88/nfqsng=0(88) fqlh=0
0/1 .>. 0:127 ^0
0/3 .>. 0:35 ^0 0/0 .>. 36:71 ^1 0/0 .>. 72:107 ^2 0/0 .>. 108:127 ^3
0/3f .>. 0:5 ^0 0/3 .>. 6:11 ^1 0/0 .>. 12:17 ^2 0/0 .>. 18:23 ^3 0/0 .>. 24:29 ^4 0/0 .>. 30:35 ^5 0/0 .>. 36:41 ^0 0/0 .>. 42:47 ^1 0/0 .>. 48:53 ^2 0/0 .>. 54:59 ^3 0/0 .>. 60:65 ^4 0/0 .>. 66:71 ^5 0/0 .>. 72:77 ^0 0/0 .>. 78:83 ^1 0/0 .>. 84:89 ^2 0/0 .>. 90:95 ^3 0/0 .>. 96:101 ^4 0/0 .>. 102:107 ^5 0/0 .>. 108:113 ^0 0/0 .>. 114:119 ^1 0/0 .>. 120:125 ^2 0/0 .>. 126:127 ^3
0/1 ..>. 0:127 ^0
0/3 ..>. 0:35 ^0 0/0 ..>. 36:71 ^1 0/0 ..>. 72:107 ^2 0/0 ..>. 108:127 ^3
0/3f ..>. 0:5 ^0 0/3 ..>. 6:11 ^1 0/0 ..>. 12:17 ^2 0/0 ..>. 18:23 ^3 0/0 ..>. 24:29 ^4 0/0 ..>. 30:35 ^5 0/0 ..>. 36:41 ^0 0/0 ..>. 42:47 ^1 0/0 ..>. 48:53 ^2 0/0 ..>. 54:59 ^3 0/0 ..>. 60:65 ^4 0/0 ..>. 66:71 ^5 0/0 ..>. 72:77 ^0 0/0 ..>. 78:83 ^1 0/0 ..>. 84:89 ^2 0/0 ..>. 90:95 ^3 0/0 ..>. 96:101 ^4 0/0 ..>. 102:107 ^5 0/0 ..>. 108:113 ^0 0/0 ..>. 114:119 ^1 0/0 ..>. 120:125 ^2 0/0 ..>. 126:127 ^3
This is once again split into "rcu_sched" and "rcu_bh" portions,
and CONFIG_TREE_PREEMPT_RCU kernels will again have an additional
@ -240,13 +303,20 @@ o Each element of the form "1/1 0:127 ^0" represents one struct
current grace period.
o The characters separated by the ">" indicate the state
of the blocked-tasks lists. A "T" preceding the ">"
of the blocked-tasks lists. A "G" preceding the ">"
indicates that at least one task blocked in an RCU
read-side critical section blocks the current grace
period, while a "." preceding the ">" indicates otherwise.
The character following the ">" indicates similarly for
the next grace period. A "T" should appear in this
field only for rcu-preempt.
period, while a "E" preceding the ">" indicates that
at least one task blocked in an RCU read-side critical
section blocks the current expedited grace period.
A "T" character following the ">" indicates that at
least one task is blocked within an RCU read-side
critical section, regardless of whether any current
grace period (expedited or normal) is inconvenienced.
A "." character appears if the corresponding condition
does not hold, so that "..>." indicates that no tasks
are blocked. In contrast, "GE>T" indicates maximal
inconvenience from blocked tasks.
o The numbers separated by the ":" are the range of CPUs
served by this struct rcu_node. This can be helpful
@ -328,6 +398,113 @@ o "nn" is the number of times that this CPU needed nothing. Alert
is due to short-circuit evaluation in rcu_pending().
The output of "cat rcu/rcutorture" looks as follows:
rcutorture test sequence: 0 (test in progress)
rcutorture update version number: 615
The first line shows the number of rcutorture tests that have completed
since boot. If a test is currently running, the "(test in progress)"
string will appear as shown above. The second line shows the number of
update cycles that the current test has started, or zero if there is
no test in progress.
The output of "cat rcu/rcuboost" looks as follows:
0:5 tasks=.... kt=W ntb=0 neb=0 nnb=0 j=2f95 bt=300f
balk: nt=0 egt=989 bt=0 nb=0 ny=0 nos=16
6:7 tasks=.... kt=W ntb=0 neb=0 nnb=0 j=2f95 bt=300f
balk: nt=0 egt=225 bt=0 nb=0 ny=0 nos=6
This information is output only for rcu_preempt. Each two-line entry
corresponds to a leaf rcu_node strcuture. The fields are as follows:
o "n:m" is the CPU-number range for the corresponding two-line
entry. In the sample output above, the first entry covers
CPUs zero through five and the second entry covers CPUs 6
and 7.
o "tasks=TNEB" gives the state of the various segments of the
rnp->blocked_tasks list:
"T" This indicates that there are some tasks that blocked
while running on one of the corresponding CPUs while
in an RCU read-side critical section.
"N" This indicates that some of the blocked tasks are preventing
the current normal (non-expedited) grace period from
completing.
"E" This indicates that some of the blocked tasks are preventing
the current expedited grace period from completing.
"B" This indicates that some of the blocked tasks are in
need of RCU priority boosting.
Each character is replaced with "." if the corresponding
condition does not hold.
o "kt" is the state of the RCU priority-boosting kernel
thread associated with the corresponding rcu_node structure.
The state can be one of the following:
"S" The kernel thread is stopped, in other words, all
CPUs corresponding to this rcu_node structure are
offline.
"R" The kernel thread is running.
"W" The kernel thread is waiting because there is no work
for it to do.
"Y" The kernel thread is yielding to avoid hogging CPU.
"?" Unknown value, indicates a bug.
o "ntb" is the number of tasks boosted.
o "neb" is the number of tasks boosted in order to complete an
expedited grace period.
o "nnb" is the number of tasks boosted in order to complete a
normal (non-expedited) grace period. When boosting a task
that was blocking both an expedited and a normal grace period,
it is counted against the expedited total above.
o "j" is the low-order 16 bits of the jiffies counter in
hexadecimal.
o "bt" is the low-order 16 bits of the value that the jiffies
counter will have when we next start boosting, assuming that
the current grace period does not end beforehand. This is
also in hexadecimal.
o "balk: nt" counts the number of times we didn't boost (in
other words, we balked) even though it was time to boost because
there were no blocked tasks to boost. This situation occurs
when there is one blocked task on one rcu_node structure and
none on some other rcu_node structure.
o "egt" counts the number of times we balked because although
there were blocked tasks, none of them were blocking the
current grace period, whether expedited or otherwise.
o "bt" counts the number of times we balked because boosting
had already been initiated for the current grace period.
o "nb" counts the number of times we balked because there
was at least one task blocking the current non-expedited grace
period that never had blocked. If it is already running, it
just won't help to boost its priority!
o "ny" counts the number of times we balked because it was
not yet time to start boosting.
o "nos" counts the number of times we balked for other
reasons, e.g., the grace period ended first.
CONFIG_TINY_RCU and CONFIG_TINY_PREEMPT_RCU debugfs Files and Formats
These implementations of RCU provides a single debugfs file under the
@ -394,9 +571,9 @@ o "neb" is the number of expedited grace periods that have had
o "nnb" is the number of normal grace periods that have had
to resort to RCU priority boosting since boot.
o "j" is the low-order 12 bits of the jiffies counter in hexadecimal.
o "j" is the low-order 16 bits of the jiffies counter in hexadecimal.
o "bt" is the low-order 12 bits of the value that the jiffies counter
o "bt" is the low-order 16 bits of the value that the jiffies counter
will have at the next time that boosting is scheduled to begin.
o In the line beginning with "normal balk", the fields are as follows:

2
Documentation/SecurityBugs
View File

@ -28,7 +28,7 @@ expect these delays to be short, measurable in days, not weeks or months.
A disclosure date is negotiated by the security team working with the
bug submitter as well as vendors. However, the kernel security team
holds the final say when setting a disclosure date. The timeframe for
disclosure is from immediate (esp. if it's already publically known)
disclosure is from immediate (esp. if it's already publicly known)
to a few weeks. As a basic default policy, we expect report date to
disclosure date to be on the order of 7 days.

2
Documentation/SubmittingDrivers
View File

@ -101,7 +101,7 @@ PM support: Since Linux is used on many portable and desktop systems, your
complete overview of the power management issues related to
drivers see Documentation/power/devices.txt .
Control: In general if there is active maintainance of a driver by
Control: In general if there is active maintenance of a driver by
the author then patches will be redirected to them unless
they are totally obvious and without need of checking.
If you want to be the contact and update point for the

11
Documentation/SubmittingPatches
View File

@ -714,10 +714,11 @@ Jeff Garzik, "Linux kernel patch submission format".
<http://linux.yyz.us/patch-format.html>
Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer".
<http://www.kroah.com/log/2005/03/31/>
<http://www.kroah.com/log/2005/07/08/>
<http://www.kroah.com/log/2005/10/19/>
<http://www.kroah.com/log/2006/01/11/>
<http://www.kroah.com/log/linux/maintainer.html>
<http://www.kroah.com/log/linux/maintainer-02.html>
<http://www.kroah.com/log/linux/maintainer-03.html>
<http://www.kroah.com/log/linux/maintainer-04.html>
<http://www.kroah.com/log/linux/maintainer-05.html>
NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people!
<http://marc.theaimsgroup.com/?l=linux-kernel&m=112112749912944&w=2>
@ -729,7 +730,7 @@ Linus Torvalds's mail on the canonical patch format:
<http://lkml.org/lkml/2005/4/7/183>
Andi Kleen, "On submitting kernel patches"
Some strategies to get difficult or controversal changes in.
Some strategies to get difficult or controversial changes in.
http://halobates.de/on-submitting-patches.pdf
--

38
Documentation/accounting/getdelays.c
View File

@ -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) {

5
Documentation/acpi/method-customizing.txt
View File

@ -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).

33
Documentation/arm/Booting
View File

@ -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)

4
Documentation/arm/IXP4xx
View File

@ -36,7 +36,7 @@ Linux currently supports the following features on the IXP4xx chips:
- Timers (watchdog, OS)
The following components of the chips are not supported by Linux and
require the use of Intel's propietary CSR softare:
require the use of Intel's proprietary CSR softare:
- USB device interface
- Network interfaces (HSS, Utopia, NPEs, etc)
@ -47,7 +47,7 @@ software from:
http://developer.intel.com/design/network/products/npfamily/ixp425.htm
DO NOT POST QUESTIONS TO THE LINUX MAILING LISTS REGARDING THE PROPIETARY
DO NOT POST QUESTIONS TO THE LINUX MAILING LISTS REGARDING THE PROPRIETARY
SOFTWARE.
There are several websites that provide directions/pointers on using

2
Documentation/arm/Samsung-S3C24XX/Suspend.txt
View File

@ -116,7 +116,7 @@ Configuration
Allows the entire memory to be checksummed before and after the
suspend to see if there has been any corruption of the contents.
Note, the time to calculate the CRC is dependant on the CPU speed
Note, the time to calculate the CRC is dependent on the CPU speed
and the size of memory. For an 64Mbyte RAM area on an 200MHz
S3C2410, this can take approximately 4 seconds to complete.

2
Documentation/arm/Samsung/GPIO.txt
View File

@ -5,7 +5,7 @@ Introduction
------------
This outlines the Samsung GPIO implementation and the architecture
specfic calls provided alongisde the drivers/gpio core.
specific calls provided alongisde the drivers/gpio core.
S3C24XX (Legacy)

2
Documentation/arm/Samsung/Overview.txt
View File

@ -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

2
Documentation/atomic_ops.txt
View File

@ -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.

4
Documentation/block/biodoc.txt
View File

@ -497,7 +497,7 @@ The scatter gather list is in the form of an array of <page, offset, len>
entries with their corresponding dma address mappings filled in at the
appropriate time. As an optimization, contiguous physical pages can be
covered by a single entry where <page> refers to the first page and <len>
covers the range of pages (upto 16 contiguous pages could be covered this
covers the range of pages (up to 16 contiguous pages could be covered this
way). There is a helper routine (blk_rq_map_sg) which drivers can use to build
the sg list.
@ -565,7 +565,7 @@ struct request {
.
int tag; /* command tag associated with request */
void *special; /* same as before */
char *buffer; /* valid only for low memory buffers upto
char *buffer; /* valid only for low memory buffers up to
current_nr_sectors */
.
.

15
Documentation/blockdev/cciss.txt
View File

@ -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

2
Documentation/cachetlb.txt
View File

@ -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

53
Documentation/cgroups/cgroups.txt
View File

@ -110,22 +110,22 @@ university server with various users - students, professors, system
tasks etc. The resource planning for this server could be along the
following lines:
CPU : Top cpuset
CPU : "Top cpuset"
/ \
CPUSet1 CPUSet2
| |
(Profs) (Students)
| |
(Professors) (Students)
In addition (system tasks) are attached to topcpuset (so
that they can run anywhere) with a limit of 20%
Memory : Professors (50%), students (30%), system (20%)
Memory : Professors (50%), Students (30%), system (20%)
Disk : Prof (50%), students (30%), system (20%)
Disk : Professors (50%), Students (30%), system (20%)
Network : WWW browsing (20%), Network File System (60%), others (20%)
/ \
Prof (15%) students (5%)
Professors (15%) students (5%)
Browsers like Firefox/Lynx go into the WWW network class, while (k)nfsd go
into NFS network class.
@ -236,7 +236,8 @@ containing the following files describing that cgroup:
- cgroup.procs: list of tgids in the cgroup. This list is not
guaranteed to be sorted or free of duplicate tgids, and userspace
should sort/uniquify the list if this property is required.
This is a read-only file, for now.
Writing a thread group id into this file moves all threads in that
group into this cgroup.
- notify_on_release flag: run the release agent on exit?
- release_agent: the path to use for release notifications (this file
exists in the top cgroup only)
@ -430,6 +431,12 @@ You can attach the current shell task by echoing 0:
# echo 0 > tasks
You can use the cgroup.procs file instead of the tasks file to move all
threads in a threadgroup at once. Echoing the pid of any task in a
threadgroup to cgroup.procs causes all tasks in that threadgroup to be
be attached to the cgroup. Writing 0 to cgroup.procs moves all tasks
in the writing task's threadgroup.
Note: Since every task is always a member of exactly one cgroup in each
mounted hierarchy, to remove a task from its current cgroup you must
move it into a new cgroup (possibly the root cgroup) by writing to the
@ -575,7 +582,7 @@ rmdir() will fail with it. From this behavior, pre_destroy() can be
called multiple times against a cgroup.
int can_attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
struct task_struct *task, bool threadgroup)
struct task_struct *task)
(cgroup_mutex held by caller)
Called prior to moving a task into a cgroup; if the subsystem
@ -584,9 +591,14 @@ task is passed, then a successful result indicates that *any*
unspecified task can be moved into the cgroup. Note that this isn't
called on a fork. If this method returns 0 (success) then this should
remain valid while the caller holds cgroup_mutex and it is ensured that either
attach() or cancel_attach() will be called in future. If threadgroup is
true, then a successful result indicates that all threads in the given
thread's threadgroup can be moved together.
attach() or cancel_attach() will be called in future.
int can_attach_task(struct cgroup *cgrp, struct task_struct *tsk);
(cgroup_mutex held by caller)
As can_attach, but for operations that must be run once per task to be
attached (possibly many when using cgroup_attach_proc). Called after
can_attach.
void cancel_attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
struct task_struct *task, bool threadgroup)
@ -598,15 +610,24 @@ function, so that the subsystem can implement a rollback. If not, not necessary.
This will be called only about subsystems whose can_attach() operation have
succeeded.
void pre_attach(struct cgroup *cgrp);
(cgroup_mutex held by caller)
For any non-per-thread attachment work that needs to happen before
attach_task. Needed by cpuset.
void attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
struct cgroup *old_cgrp, struct task_struct *task,
bool threadgroup)
struct cgroup *old_cgrp, struct task_struct *task)
(cgroup_mutex held by caller)
Called after the task has been attached to the cgroup, to allow any
post-attachment activity that requires memory allocations or blocking.
If threadgroup is true, the subsystem should take care of all threads
in the specified thread's threadgroup. Currently does not support any
void attach_task(struct cgroup *cgrp, struct task_struct *tsk);
(cgroup_mutex held by caller)
As attach, but for operations that must be run once per task to be attached,
like can_attach_task. Called before attach. Currently does not support any
subsystem that might need the old_cgrp for every thread in the group.
void fork(struct cgroup_subsy *ss, struct task_struct *task)
@ -630,7 +651,7 @@ always handled well.
void post_clone(struct cgroup_subsys *ss, struct cgroup *cgrp)
(cgroup_mutex held by caller)
Called at the end of cgroup_clone() to do any parameter
Called during cgroup_create() to do any parameter
initialization which might be required before a task could attach. For
example in cpusets, no task may attach before 'cpus' and 'mems' are set
up.

15
Documentation/cgroups/memory.txt
View File

@ -52,8 +52,10 @@ Brief summary of control files.
tasks # attach a task(thread) and show list of threads
cgroup.procs # show list of processes
cgroup.event_control # an interface for event_fd()
memory.usage_in_bytes # show current memory(RSS+Cache) usage.
memory.memsw.usage_in_bytes # show current memory+Swap usage
memory.usage_in_bytes # show current res_counter usage for memory
(See 5.5 for details)
memory.memsw.usage_in_bytes # show current res_counter usage for memory+Swap
(See 5.5 for details)
memory.limit_in_bytes # set/show limit of memory usage
memory.memsw.limit_in_bytes # set/show limit of memory+Swap usage
memory.failcnt # show the number of memory usage hits limits
@ -453,6 +455,15 @@ memory under it will be reclaimed.
You can reset failcnt by writing 0 to failcnt file.
# echo 0 > .../memory.failcnt
5.5 usage_in_bytes
For efficiency, as other kernel components, memory cgroup uses some optimization
to avoid unnecessary cacheline false sharing. usage_in_bytes is affected by the
method and doesn't show 'exact' value of memory(and swap) usage, it's an fuzz
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).
6. Hierarchy support
The memory controller supports a deep hierarchy and hierarchical accounting.

2
Documentation/cpu-hotplug.txt
View File

@ -196,7 +196,7 @@ the state as 0 when a cpu if offline and 1 when its online.
#To display the current cpu state.
#cat /sys/devices/system/cpu/cpuX/online
Q: Why cant i remove CPU0 on some systems?
Q: Why can't i remove CPU0 on some systems?
A: Some architectures may have some special dependency on a certain CPU.
For e.g in IA64 platforms we have ability to sent platform interrupts to the

2
Documentation/dell_rbu.txt
View File

@ -62,7 +62,7 @@ image file and then arrange all these packets back to back in to one single
file.
This file is then copied to /sys/class/firmware/dell_rbu/data.
Once this file gets to the driver, the driver extracts packet_size data from
the file and spreads it accross the physical memory in contiguous packet_sized
the file and spreads it across the physical memory in contiguous packet_sized
space.
This method makes sure that all the packets get to the driver in a single operation.

2
Documentation/device-mapper/dm-service-time.txt
View File

@ -37,7 +37,7 @@ Algorithm
=========
dm-service-time adds the I/O size to 'in-flight-size' when the I/O is
dispatched and substracts when completed.
dispatched and subtracts when completed.
Basically, dm-service-time selects a path having minimum service time
which is calculated by:

397
Documentation/devicetree/bindings/crypto/fsl-sec4.txt 100644
View File

@ -0,0 +1,397 @@
=====================================================================
SEC 4 Device Tree Binding
Copyright (C) 2008-2011 Freescale Semiconductor Inc.
CONTENTS
-Overview
-SEC 4 Node
-Job Ring Node
-Run Time Integrity Check (RTIC) Node
-Run Time Integrity Check (RTIC) Memory Node
-Secure Non-Volatile Storage (SNVS) Node
-Full Example
NOTE: the SEC 4 is also known as Freescale's Cryptographic Accelerator
Accelerator and Assurance Module (CAAM).
=====================================================================
Overview
DESCRIPTION
SEC 4 h/w can process requests from 2 types of sources.
1. DPAA Queue Interface (HW interface between Queue Manager & SEC 4).
2. Job Rings (HW interface between cores & SEC 4 registers).
High Speed Data Path Configuration:
HW interface between QM & SEC 4 and also BM & SEC 4, on DPAA-enabled parts
such as the P4080. The number of simultaneous dequeues the QI can make is
equal to the number of Descriptor Controller (DECO) engines in a particular
SEC version. E.g., the SEC 4.0 in the P4080 has 5 DECOs and can thus
dequeue from 5 subportals simultaneously.
Job Ring Data Path Configuration:
Each JR is located on a separate 4k page, they may (or may not) be made visible
in the memory partition devoted to a particular core. The P4080 has 4 JRs, so
up to 4 JRs can be configured; and all 4 JRs process requests in parallel.
=====================================================================
SEC 4 Node
Description
Node defines the base address of the SEC 4 block.
This block specifies the address range of all global
configuration registers for the SEC 4 block. It
also receives interrupts from the Run Time Integrity Check
(RTIC) function within the SEC 4 block.
PROPERTIES
- compatible
Usage: required
Value type: <string>
Definition: Must include "fsl,sec-v4.0"
- #address-cells
Usage: required
Value type: <u32>
Definition: A standard property. Defines the number of cells
for representing physical addresses in child nodes.
- #size-cells
Usage: required
Value type: <u32>
Definition: A standard property. Defines the number of cells
for representing the size of physical addresses in
child nodes.
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies the physical
address and length of the SEC4 configuration registers.
registers
- ranges
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies the physical address
range of the SEC 4.0 register space (-SNVS not included). A
triplet that includes the child address, parent address, &
length.
- interrupts
Usage: required
Value type: <prop_encoded-array>
Definition: Specifies the interrupts generated by this
device. The value of the interrupts property
consists of one interrupt specifier. The format
of the specifier is defined by the binding document
describing the node's interrupt parent.
- interrupt-parent
Usage: (required if interrupt property is defined)
Value type: <phandle>
Definition: A single <phandle> value that points
to the interrupt parent to which the child domain
is being mapped.
Note: All other standard properties (see the ePAPR) are allowed
but are optional.
EXAMPLE
crypto@300000 {
compatible = "fsl,sec-v4.0";
#address-cells = <1>;
#size-cells = <1>;
reg = <0x300000 0x10000>;
ranges = <0 0x300000 0x10000>;
interrupt-parent = <&mpic>;
interrupts = <92 2>;
};
=====================================================================
Job Ring (JR) Node
Child of the crypto node defines data processing interface to SEC 4
across the peripheral bus for purposes of processing
cryptographic descriptors. The specified address
range can be made visible to one (or more) cores.
The interrupt defined for this node is controlled within
the address range of this node.
- compatible
Usage: required
Value type: <string>
Definition: Must include "fsl,sec-v4.0-job-ring"
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: Specifies a two JR parameters: an offset from
the parent physical address and the length the JR registers.
- fsl,liodn
Usage: optional-but-recommended
Value type: <prop-encoded-array>
Definition:
Specifies the LIODN to be used in conjunction with
the ppid-to-liodn table that specifies the PPID to LIODN mapping.
Needed if the PAMU is used. Value is a 12 bit value
where value is a LIODN ID for this JR. This property is
normally set by boot firmware.
- interrupts
Usage: required
Value type: <prop_encoded-array>
Definition: Specifies the interrupts generated by this
device. The value of the interrupts property
consists of one interrupt specifier. The format
of the specifier is defined by the binding document
describing the node's interrupt parent.
- interrupt-parent
Usage: (required if interrupt property is defined)
Value type: <phandle>
Definition: A single <phandle> value that points
to the interrupt parent to which the child domain
is being mapped.
EXAMPLE
jr@1000 {
compatible = "fsl,sec-v4.0-job-ring";
reg = <0x1000 0x1000>;
fsl,liodn = <0x081>;
interrupt-parent = <&mpic>;
interrupts = <88 2>;
};
=====================================================================
Run Time Integrity Check (RTIC) Node
Child node of the crypto node. Defines a register space that
contains up to 5 sets of addresses and their lengths (sizes) that
will be checked at run time. After an initial hash result is
calculated, these addresses are checked by HW to monitor any
change. If any memory is modified, a Security Violation is
triggered (see SNVS definition).
- compatible
Usage: required
Value type: <string>
Definition: Must include "fsl,sec-v4.0-rtic".
- #address-cells
Usage: required
Value type: <u32>
Definition: A standard property. Defines the number of cells
for representing physical addresses in child nodes. Must
have a value of 1.
- #size-cells
Usage: required
Value type: <u32>
Definition: A standard property. Defines the number of cells
for representing the size of physical addresses in
child nodes. Must have a value of 1.
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies a two parameters:
an offset from the parent physical address and the length
the SEC4 registers.
- ranges
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies the physical address
range of the SEC 4 register space (-SNVS not included). A
triplet that includes the child address, parent address, &
length.
EXAMPLE
rtic@6000 {
compatible = "fsl,sec-v4.0-rtic";
#address-cells = <1>;
#size-cells = <1>;
reg = <0x6000 0x100>;
ranges = <0x0 0x6100 0xe00>;
};
=====================================================================
Run Time Integrity Check (RTIC) Memory Node
A child node that defines individual RTIC memory regions that are used to
perform run-time integrity check of memory areas that should not modified.
The node defines a register that contains the memory address &
length (combined) and a second register that contains the hash result
in big endian format.
- compatible
Usage: required
Value type: <string>
Definition: Must include "fsl,sec-v4.0-rtic-memory".
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies two parameters:
an offset from the parent physical address and the length:
1. The location of the RTIC memory address & length registers.
2. The location RTIC hash result.
- fsl,rtic-region
Usage: optional-but-recommended
Value type: <prop-encoded-array>
Definition:
Specifies the HW address (36 bit address) for this region
followed by the length of the HW partition to be checked;
the address is represented as a 64 bit quantity followed
by a 32 bit length.
- fsl,liodn
Usage: optional-but-recommended
Value type: <prop-encoded-array>
Definition:
Specifies the LIODN to be used in conjunction with
the ppid-to-liodn table that specifies the PPID to LIODN
mapping. Needed if the PAMU is used. Value is a 12 bit value
where value is a LIODN ID for this RTIC memory region. This
property is normally set by boot firmware.
EXAMPLE
rtic-a@0 {
compatible = "fsl,sec-v4.0-rtic-memory";
reg = <0x00 0x20 0x100 0x80>;
fsl,liodn = <0x03c>;
fsl,rtic-region = <0x12345678 0x12345678 0x12345678>;
};
=====================================================================
Secure Non-Volatile Storage (SNVS) Node
Node defines address range and the associated
interrupt for the SNVS function. This function
monitors security state information & reports
security violations.
- compatible
Usage: required
Value type: <string>
Definition: Must include "fsl,sec-v4.0-mon".
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies the physical
address and length of the SEC4 configuration
registers.
- interrupts
Usage: required
Value type: <prop_encoded-array>
Definition: Specifies the interrupts generated by this
device. The value of the interrupts property
consists of one interrupt specifier. The format
of the specifier is defined by the binding document
describing the node's interrupt parent.
- interrupt-parent
Usage: (required if interrupt property is defined)
Value type: <phandle>
Definition: A single <phandle> value that points
to the interrupt parent to which the child domain
is being mapped.
EXAMPLE
sec_mon@314000 {
compatible = "fsl,sec-v4.0-mon";
reg = <0x314000 0x1000>;
interrupt-parent = <&mpic>;
interrupts = <93 2>;
};
=====================================================================
FULL EXAMPLE
crypto: crypto@300000 {
compatible = "fsl,sec-v4.0";
#address-cells = <1>;
#size-cells = <1>;
reg = <0x300000 0x10000>;
ranges = <0 0x300000 0x10000>;
interrupt-parent = <&mpic>;
interrupts = <92 2>;
sec_jr0: jr@1000 {
compatible = "fsl,sec-v4.0-job-ring";
reg = <0x1000 0x1000>;
interrupt-parent = <&mpic>;
interrupts = <88 2>;
};
sec_jr1: jr@2000 {
compatible = "fsl,sec-v4.0-job-ring";
reg = <0x2000 0x1000>;
interrupt-parent = <&mpic>;
interrupts = <89 2>;
};
sec_jr2: jr@3000 {
compatible = "fsl,sec-v4.0-job-ring";
reg = <0x3000 0x1000>;
interrupt-parent = <&mpic>;
interrupts = <90 2>;
};
sec_jr3: jr@4000 {
compatible = "fsl,sec-v4.0-job-ring";
reg = <0x4000 0x1000>;
interrupt-parent = <&mpic>;
interrupts = <91 2>;
};
rtic@6000 {
compatible = "fsl,sec-v4.0-rtic";
#address-cells = <1>;
#size-cells = <1>;
reg = <0x6000 0x100>;
ranges = <0x0 0x6100 0xe00>;
rtic_a: rtic-a@0 {
compatible = "fsl,sec-v4.0-rtic-memory";
reg = <0x00 0x20 0x100 0x80>;
};
rtic_b: rtic-b@20 {
compatible = "fsl,sec-v4.0-rtic-memory";
reg = <0x20 0x20 0x200 0x80>;
};
rtic_c: rtic-c@40 {
compatible = "fsl,sec-v4.0-rtic-memory";
reg = <0x40 0x20 0x300 0x80>;
};
rtic_d: rtic-d@60 {
compatible = "fsl,sec-v4.0-rtic-memory";
reg = <0x60 0x20 0x500 0x80>;
};
};
};
sec_mon: sec_mon@314000 {
compatible = "fsl,sec-v4.0-mon";
reg = <0x314000 0x1000>;
interrupt-parent = <&mpic>;
interrupts = <93 2>;
};
=====================================================================

4
Documentation/devicetree/bindings/fb/sm501fb.txt
View File

@ -18,9 +18,9 @@ Optional properties:
- edid : verbatim EDID data block describing attached display.
Data from the detailed timing descriptor will be used to
program the display controller.
- little-endian: availiable on big endian systems, to
- little-endian: available on big endian systems, to
set different foreign endian.
- big-endian: availiable on little endian systems, to
- big-endian: available on little endian systems, to
set different foreign endian.
Example for MPC5200:

2
Documentation/devicetree/bindings/mtd/fsl-upm-nand.txt
View File

@ -15,7 +15,7 @@ Optional properties:
- gpios : may specify optional GPIOs connected to the Ready-Not-Busy pins
(R/B#). For multi-chip devices, "n" GPIO definitions are required
according to the number of chips.
- chip-delay : chip dependent delay for transfering data from array to
- chip-delay : chip dependent delay for transferring data from array to
read registers (tR). Required if property "gpios" is not used
(R/B# pins not connected).

61
Documentation/devicetree/bindings/net/can/fsl-flexcan.txt 100755
View File

@ -0,0 +1,61 @@
CAN Device Tree Bindings
------------------------
2011 Freescale Semiconductor, Inc.
fsl,flexcan-v1.0 nodes
-----------------------
In addition to the required compatible-, reg- and interrupt-properties, you can
also specify which clock source shall be used for the controller.
CPI Clock- Can Protocol Interface Clock
This CLK_SRC bit of CTRL(control register) selects the clock source to
the CAN Protocol Interface(CPI) to be either the peripheral clock
(driven by the PLL) or the crystal oscillator clock. The selected clock
is the one fed to the prescaler to generate the Serial Clock (Sclock).
The PRESDIV field of CTRL(control register) controls a prescaler that
generates the Serial Clock (Sclock), whose period defines the
time quantum used to compose the CAN waveform.
Can Engine Clock Source
There are two sources for CAN clock
- Platform Clock It represents the bus clock
- Oscillator Clock
Peripheral Clock (PLL)
--------------
|
--------- -------------
| |CPI Clock | Prescaler | Sclock
| |---------------->| (1.. 256) |------------>
--------- -------------
| |
-------------- ---------------------CLK_SRC
Oscillator Clock
- fsl,flexcan-clock-source : CAN Engine Clock Source.This property selects
the peripheral clock. PLL clock is fed to the
prescaler to generate the Serial Clock (Sclock).
Valid values are "oscillator" and "platform"
"oscillator": CAN engine clock source is oscillator clock.
"platform" The CAN engine clock source is the bus clock
(platform clock).
- fsl,flexcan-clock-divider : for the reference and system clock, an additional
clock divider can be specified.
- clock-frequency: frequency required to calculate the bitrate for FlexCAN.
Note:
- v1.0 of flexcan-v1.0 represent the IP block version for P1010 SOC.
- P1010 does not have oscillator as the Clock Source.So the default
Clock Source is platform clock.
Examples:
can0@1c000 {
compatible = "fsl,flexcan-v1.0";
reg = <0x1c000 0x1000>;
interrupts = <48 0x2>;
interrupt-parent = <&mpic>;
fsl,flexcan-clock-source = "platform";
fsl,flexcan-clock-divider = <2>;
clock-frequency = <fixed by u-boot>;
};

2
Documentation/devicetree/bindings/net/can/sja1000.txt
View File

@ -39,7 +39,7 @@ Optional properties:
- nxp,no-comparator-bypass : Allows to disable the CAN input comperator.
For futher information, please have a look to the SJA1000 data sheet.
For further information, please have a look to the SJA1000 data sheet.
Examples:

54
Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
View File

@ -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>;
};

76
Documentation/devicetree/bindings/powerpc/fsl/ifc.txt 100644
View File

@ -0,0 +1,76 @@
Integrated Flash Controller
Properties:
- name : Should be ifc
- compatible : should contain "fsl,ifc". The version of the integrated
flash controller can be found in the IFC_REV register at
offset zero.
- #address-cells : Should be either two or three. The first cell is the
chipselect number, and the remaining cells are the
offset into the chipselect.
- #size-cells : Either one or two, depending on how large each chipselect
can be.
- reg : Offset and length of the register set for the device
- interrupts : IFC has two interrupts. The first one is the "common"
interrupt(CM_EVTER_STAT), and second is the NAND interrupt
(NAND_EVTER_STAT).
- ranges : Each range corresponds to a single chipselect, and covers
the entire access window as configured.
Child device nodes describe the devices connected to IFC such as NOR (e.g.
cfi-flash) and NAND (fsl,ifc-nand). There might be board specific devices
like FPGAs, CPLDs, etc.
Example:
ifc@ffe1e000 {
compatible = "fsl,ifc", "simple-bus";
#address-cells = <2>;
#size-cells = <1>;
reg = <0x0 0xffe1e000 0 0x2000>;
interrupts = <16 2 19 2>;
/* NOR, NAND Flashes and CPLD on board */
ranges = <0x0 0x0 0x0 0xee000000 0x02000000
0x1 0x0 0x0 0xffa00000 0x00010000
0x3 0x0 0x0 0xffb00000 0x00020000>;
flash@0,0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "cfi-flash";
reg = <0x0 0x0 0x2000000>;
bank-width = <2>;
device-width = <1>;
partition@0 {
/* 32MB for user data */
reg = <0x0 0x02000000>;
label = "NOR Data";
};
};
flash@1,0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,ifc-nand";
reg = <0x1 0x0 0x10000>;
partition@0 {
/* This location must not be altered */
/* 1MB for u-boot Bootloader Image */
reg = <0x0 0x00100000>;
label = "NAND U-Boot Image";
read-only;
};
};
cpld@3,0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,p1010rdb-cpld";
reg = <0x3 0x0 0x000001f>;
};
};

38
Documentation/devicetree/bindings/powerpc/fsl/mpic-timer.txt 100644
View File

@ -0,0 +1,38 @@
* Freescale MPIC timers
Required properties:
- compatible: "fsl,mpic-global-timer"
- reg : Contains two regions. The first is the main timer register bank
(GTCCRxx, GTBCRxx, GTVPRxx, GTDRxx). The second is the timer control
register (TCRx) for the group.
- fsl,available-ranges: use <start count> style section to define which
timer interrupts can be used. This property is optional; without this,
all timers within the group can be used.
- interrupts: one interrupt per timer in the group, in order, starting
with timer zero. If timer-available-ranges is present, only the
interrupts that correspond to available timers shall be present.
Example:
/* Note that this requires #interrupt-cells to be 4 */
timer0: timer@41100 {
compatible = "fsl,mpic-global-timer";
reg = <0x41100 0x100 0x41300 4>;
/* Another AMP partition is using timers 0 and 1 */
fsl,available-ranges = <2 2>;
interrupts = <2 0 3 0
3 0 3 0>;
};
timer1: timer@42100 {
compatible = "fsl,mpic-global-timer";
reg = <0x42100 0x100 0x42300 4>;
interrupts = <4 0 3 0
5 0 3 0
6 0 3 0
7 0 3 0>;
};

4
Documentation/devicetree/bindings/powerpc/fsl/mpic.txt
View File

@ -190,7 +190,7 @@ EXAMPLE 4
*/
timer0: timer@41100 {
compatible = "fsl,mpic-global-timer";
reg = <0x41100 0x100>;
reg = <0x41100 0x100 0x41300 4>;
interrupts = <0 0 3 0
1 0 3 0
2 0 3 0
@ -199,7 +199,7 @@ EXAMPLE 4
EXAMPLE 5
/*
* Definition of an error interrupt (interupt type 1).
* Definition of an error interrupt (interrupt type 1).
* SoC interrupt number is 16 and the specific error
* interrupt bit in the error interrupt summary register
* is 23.

2
Documentation/devicetree/bindings/powerpc/nintendo/wii.txt
View File

@ -127,7 +127,7 @@ Nintendo Wii device tree
- reg : should contain the SDHCI registers location and length
- interrupts : should contain the SDHCI interrupt
1.j) The Inter-Processsor Communication (IPC) node
1.j) The Inter-Processor Communication (IPC) node
Represent the Inter-Processor Communication interface. This interface
enables communications between the Broadway and the Starlet processors.

54
Documentation/devicetree/booting-without-of.txt
View File

@ -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
@ -138,7 +139,7 @@ and properties to be present. This will be described in detail in
section III, but, for example, the kernel does not require you to
create a node for every PCI device in the system. It is a requirement
to have a node for PCI host bridges in order to provide interrupt
routing informations and memory/IO ranges, among others. It is also
routing information and memory/IO ranges, among others. It is also
recommended to define nodes for on chip devices and other buses that
don't specifically fit in an existing OF specification. This creates a
great flexibility in the way the kernel can then probe those and match
@ -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,
@ -385,7 +425,7 @@ struct boot_param_header {
among others, by kexec. If you are on an SMP system, this value
should match the content of the "reg" property of the CPU node in
the device-tree corresponding to the CPU calling the kernel entry
point (see further chapters for more informations on the required
point (see further chapters for more information on the required
device-tree contents)
- size_dt_strings
@ -553,7 +593,7 @@ looks like in practice.
This tree is almost a minimal tree. It pretty much contains the
minimal set of required nodes and properties to boot a linux kernel;
that is, some basic model informations at the root, the CPUs, and the
that is, some basic model information at the root, the CPUs, and the
physical memory layout. It also includes misc information passed
through /chosen, like in this example, the platform type (mandatory)
and the kernel command line arguments (optional).

97
Documentation/dmaengine.txt
View File

@ -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

58
Documentation/dontdiff
View File

@ -1,6 +1,8 @@
*.a
*.aux
*.bin
*.bz2
*.cis
*.cpio
*.csp
*.dsp
@ -8,6 +10,8 @@
*.elf
*.eps
*.fw
*.gcno
*.gcov
*.gen.S
*.gif
*.grep
@ -19,14 +23,20 @@
*.ko
*.log
*.lst
*.lzma
*.lzo
*.mo
*.moc
*.mod.c
*.o
*.o.*
*.order
*.orig
*.out
*.patch
*.pdf
*.png
*.pot
*.ps
*.rej
*.s
@ -39,16 +49,22 @@
*.tex
*.ver
*.xml
*.xz
*_MODULES
*_vga16.c
*~
\#*#
*.9
*.9.gz
.*
.*.d
.mm
53c700_d.h
CVS
ChangeSet
GPATH
GRTAGS
GSYMS
GTAGS
Image
Kerntypes
Module.markers
@ -57,15 +73,14 @@ PENDING
SCCS
System.map*
TAGS
aconf
af_names.h
aic7*reg.h*
aic7*reg_print.c*
aic7*seq.h*
aicasm
aicdb.h*
altivec1.c
altivec2.c
altivec4.c
altivec8.c
altivec*.c
asm-offsets.h
asm_offsets.h
autoconf.h*
@ -80,6 +95,7 @@ btfixupprep
build
bvmlinux
bzImage*
capability_names.h
capflags.c
classlist.h*
comp*.log
@ -88,7 +104,8 @@ conf
config
config-*
config_data.h*
config_data.gz*
config.mak
config.mak.autogen
conmakehash
consolemap_deftbl.c*
cpustr.h
@ -96,7 +113,9 @@ crc32table.h*
cscope.*
defkeymap.c
devlist.h*
dnotify_test
docproc
dslm
elf2ecoff
elfconfig.h*
evergreen_reg_safe.h
@ -105,6 +124,7 @@ flask.h
fore200e_mkfirm
fore200e_pca_fw.c*
gconf
gconf.glade.h
gen-devlist
gen_crc32table
gen_init_cpio
@ -112,11 +132,12 @@ generated
genheaders
genksyms
*_gray256.c
hpet_example
hugepage-mmap
hugepage-shm
ihex2fw
ikconfig.h*
inat-tables.c
initramfs_data.cpio
initramfs_data.cpio.gz
initramfs_list
int16.c
int1.c
@ -133,15 +154,19 @@ kxgettext
lkc_defs.h
lex.c
lex.*.c
linux
logo_*.c
logo_*_clut224.c
logo_*_mono.c
lxdialog
mach
mach-types
mach-types.h
machtypes.h
map
map_hugetlb
maui_boot.h
media
mconf
miboot*
mk_elfconfig
@ -150,23 +175,29 @@ mkbugboot
mkcpustr
mkdep
mkprep
mkregtable
mktables
mktree
modpost
modules.builtin
modules.order
modversions.h*
nconf
ncscope.*
offset.h
offsets.h
oui.c*
page-types
parse.c
parse.h
patches*
pca200e.bin
pca200e_ecd.bin2
piggy.gz
perf.data
perf.data.old
perf-archive
piggyback
piggy.gzip
piggy.S
pnmtologo
ppc_defs.h*
@ -177,10 +208,9 @@ r200_reg_safe.h
r300_reg_safe.h
r420_reg_safe.h
r600_reg_safe.h
raid6altivec*.c
raid6int*.c
raid6tables.c
recordmcount
relocs
rlim_names.h
rn50_reg_safe.h
rs600_reg_safe.h
rv515_reg_safe.h
@ -194,6 +224,7 @@ split-include
syscalltab.h
tables.c
tags
test_get_len
tftpboot.img
timeconst.h
times.h*
@ -210,10 +241,13 @@ vdso32.so.dbg
vdso64.lds
vdso64.so.dbg
version.h*
vmImage
vmlinux
vmlinux-*
vmlinux.aout
vmlinux.bin.all
vmlinux.lds
vmlinuz
voffset.h
vsyscall.lds
vsyscall_32.lds

19
Documentation/driver-model/bus.txt
View File

@ -3,24 +3,7 @@ Bus Types
Definition
~~~~~~~~~~
struct bus_type {
char * name;
struct subsystem subsys;
struct kset drivers;
struct kset devices;
struct bus_attribute * bus_attrs;
struct device_attribute * dev_attrs;
struct driver_attribute * drv_attrs;
int (*match)(struct device * dev, struct device_driver * drv);
int (*hotplug) (struct device *dev, char **envp,
int num_envp, char *buffer, int buffer_size);
int (*suspend)(struct device * dev, pm_message_t state);
int (*resume)(struct device * dev);
};
See the kerneldoc for the struct bus_type.
int bus_register(struct bus_type * bus);

17
Documentation/driver-model/class.txt
View File

@ -27,22 +27,7 @@ The device class structure looks like:
typedef int (*devclass_add)(struct device *);
typedef void (*devclass_remove)(struct device *);
struct device_class {
char * name;
rwlock_t lock;
u32 devnum;
struct list_head node;
struct list_head drivers;
struct list_head intf_list;
struct driver_dir_entry dir;
struct driver_dir_entry device_dir;
struct driver_dir_entry driver_dir;
devclass_add add_device;
devclass_remove remove_device;
};
See the kerneldoc for the struct class.
A typical device class definition would look like:

91
Documentation/driver-model/device.txt
View File

@ -2,96 +2,7 @@
The Basic Device Structure
~~~~~~~~~~~~~~~~~~~~~~~~~~
struct device {
struct list_head g_list;
struct list_head node;
struct list_head bus_list;
struct list_head driver_list;
struct list_head intf_list;
struct list_head children;
struct device * parent;
char name[DEVICE_NAME_SIZE];
char bus_id[BUS_ID_SIZE];
spinlock_t lock;
atomic_t refcount;
struct bus_type * bus;
struct driver_dir_entry dir;
u32 class_num;
struct device_driver *driver;
void *driver_data;
void *platform_data;
u32 current_state;
unsigned char *saved_state;
void (*release)(struct device * dev);
};
Fields
~~~~~~
g_list: Node in the global device list.
node: Node in device's parent's children list.
bus_list: Node in device's bus's devices list.
driver_list: Node in device's driver's devices list.
intf_list: List of intf_data. There is one structure allocated for
each interface that the device supports.
children: List of child devices.
parent: *** FIXME ***
name: ASCII description of device.
Example: " 3Com Corporation 3c905 100BaseTX [Boomerang]"
bus_id: ASCII representation of device's bus position. This
field should be a name unique across all devices on the
bus type the device belongs to.
Example: PCI bus_ids are in the form of
<bus number>:<slot number>.<function number>
This name is unique across all PCI devices in the system.
lock: Spinlock for the device.
refcount: Reference count on the device.
bus: Pointer to struct bus_type that device belongs to.
dir: Device's sysfs directory.
class_num: Class-enumerated value of the device.
driver: Pointer to struct device_driver that controls the device.
driver_data: Driver-specific data.
platform_data: Platform data specific to the device.
Example: for devices on custom boards, as typical of embedded
and SOC based hardware, Linux often uses platform_data to point
to board-specific structures describing devices and how they
are wired. That can include what ports are available, chip
variants, which GPIO pins act in what additional roles, and so
on. This shrinks the "Board Support Packages" (BSPs) and
minimizes board-specific #ifdefs in drivers.
current_state: Current power state of the device.
saved_state: Pointer to saved state of the device. This is usable by
the device driver controlling the device.
release: Callback to free the device after all references have
gone away. This should be set by the allocator of the
device (i.e. the bus driver that discovered the device).
See the kerneldoc for the struct device.
Programming Interface

18
Documentation/driver-model/driver.txt
View File

@ -1,23 +1,7 @@
Device Drivers
struct device_driver {
char * name;
struct bus_type * bus;
struct completion unloaded;
struct kobject kobj;
list_t devices;
struct module *owner;
int (*probe) (struct device * dev);
int (*remove) (struct device * dev);
int (*suspend) (struct device * dev, pm_message_t state);
int (*resume) (struct device * dev);
};
See the kerneldoc for the struct device_driver.
Allocation

2
Documentation/dvb/README.dvb-usb
View File

@ -138,7 +138,7 @@ Hotplug is able to load the driver, when it is needed (because you plugged
in the device).
If you want to enable debug output, you have to load the driver manually and
from withing the dvb-kernel cvs repository.
from within the dvb-kernel cvs repository.
first have a look, which debug level are available:

2
Documentation/dvb/ci.txt
View File

@ -47,7 +47,7 @@ so on.
* CI modules that are supported
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The CI module support is largely dependant upon the firmware on the cards
The CI module support is largely dependent upon the firmware on the cards
Some cards do support almost all of the available CI modules. There is
nothing much that can be done in order to make additional CI modules
working with these cards.

2
Documentation/dvb/faq.txt
View File

@ -106,7 +106,7 @@ Some very frequently asked questions about linuxtv-dvb
5. The dvb_net device doesn't give me any packets at all
Run tcpdump on the dvb0_0 interface. This sets the interface
into promiscous mode so it accepts any packets from the PID
into promiscuous mode so it accepts any packets from the PID
you have configured with the dvbnet utility. Check if there
are any packets with the IP addr and MAC addr you have
configured with ifconfig.

2
Documentation/dvb/udev.txt
View File

@ -1,7 +1,7 @@
The DVB subsystem currently registers to the sysfs subsystem using the
"class_simple" interface.
This means that only the basic informations like module loading parameters
This means that only the basic information like module loading parameters
are presented through sysfs. Other things that might be interesting are
currently *not* available.

4
Documentation/edac.txt
View File

@ -311,7 +311,7 @@ Total Correctable Errors count attribute file:
'ce_noinfo_count'
This attribute file displays the number of CEs that
have occurred wherewith no informations as to which DIMM slot
have occurred wherewith no information as to which DIMM slot
is having errors. Memory is handicapped, but operational,
yet no information is available to indicate which slot
the failing memory is in. This count field should be also
@ -741,7 +741,7 @@ were done at i7core_edac driver. This chapter will cover those differences
As EDAC API maps the minimum unity is csrows, the driver sequencially
maps channel/dimm into different csrows.
For example, suposing the following layout:
For example, supposing the following layout:
Ch0 phy rd0, wr0 (0x063f4031): 2 ranks, UDIMMs
dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400
dimm 1 1024 Mb offset: 4, bank: 8, rank: 1, row: 0x4000, col: 0x400

2
Documentation/eisa.txt
View File

@ -84,7 +84,7 @@ struct eisa_driver {
id_table : an array of NULL terminated EISA id strings,
followed by an empty string. Each string can
optionally be paired with a driver-dependant value
optionally be paired with a driver-dependent value
(driver_data).
driver : a generic driver, such as described in

4
Documentation/fb/viafb.txt
View File

@ -204,7 +204,7 @@ Notes:
supported_output_devices
This read-only file contains a full ',' seperated list containing all
This read-only file contains a full ',' separated list containing all
output devices that could be available on your platform. It is likely
that not all of those have a connector on your hardware but it should
provide a good starting point to figure out which of those names match
@ -225,7 +225,7 @@ Notes:
This can happen for example if only one (the other) iga is used.
Writing to these files allows adjusting the output devices during
runtime. One can add new devices, remove existing ones or switch
between igas. Essentially you can write a ',' seperated list of device
between igas. Essentially you can write a ',' separated list of device
names (or a single one) in the same format as the output to those
files. You can add a '+' or '-' as a prefix allowing simple addition
and removal of devices. So a prefix '+' adds the devices from your list

Some files were not shown because too many files have changed in this diff Show More