Merge commit 'linus/master' into HEAD
Conflicts: MAINTAINERS Signed-off-by: Vegard Nossum <vegard.nossum@gmail.com>
This commit is contained in:
Vegard Nossum
commit
722f2a6c87
|
|
@ -3,7 +3,7 @@
|
|||
# subdirectories here. Add them in the ".gitignore" file
|
||||
# in that subdirectory instead.
|
||||
#
|
||||
# NOTE! Please use 'git-ls-files -i --exclude-standard'
|
||||
# NOTE! Please use 'git ls-files -i --exclude-standard'
|
||||
# command after changing this file, to see if there are
|
||||
# any tracked files which get ignored after the change.
|
||||
#
|
||||
|
|
@ -25,6 +25,8 @@
|
|||
*.elf
|
||||
*.bin
|
||||
*.gz
|
||||
*.lzma
|
||||
*.patch
|
||||
|
||||
#
|
||||
# Top-level generic files
|
||||
|
|
@ -62,6 +64,12 @@ series
|
|||
cscope.*
|
||||
ncscope.*
|
||||
|
||||
# gnu global files
|
||||
GPATH
|
||||
GRTAGS
|
||||
GSYMS
|
||||
GTAGS
|
||||
|
||||
*.orig
|
||||
*~
|
||||
\#*#
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ hardware, for example, you probably needn't concern yourself with
|
|||
isdn4k-utils.
|
||||
|
||||
o Gnu C 3.2 # gcc --version
|
||||
o Gnu make 3.79.1 # make --version
|
||||
o Gnu make 3.80 # make --version
|
||||
o binutils 2.12 # ld -v
|
||||
o util-linux 2.10o # fdformat --version
|
||||
o module-init-tools 0.9.10 # depmod -V
|
||||
|
|
@ -48,6 +48,7 @@ o procps 3.2.0 # ps --version
|
|||
o oprofile 0.9 # oprofiled --version
|
||||
o udev 081 # udevinfo -V
|
||||
o grub 0.93 # grub --version
|
||||
o mcelog 0.6
|
||||
|
||||
Kernel compilation
|
||||
==================
|
||||
|
|
@ -61,7 +62,7 @@ computer.
|
|||
Make
|
||||
----
|
||||
|
||||
You will need Gnu make 3.79.1 or later to build the kernel.
|
||||
You will need Gnu make 3.80 or later to build the kernel.
|
||||
|
||||
Binutils
|
||||
--------
|
||||
|
|
@ -276,6 +277,16 @@ before running exportfs or mountd. It is recommended that all NFS
|
|||
services be protected from the internet-at-large by a firewall where
|
||||
that is possible.
|
||||
|
||||
mcelog
|
||||
------
|
||||
|
||||
In Linux 2.6.31+ the i386 kernel needs to run the mcelog utility
|
||||
as a regular cronjob similar to the x86-64 kernel to process and log
|
||||
machine check events when CONFIG_X86_NEW_MCE is enabled. Machine check
|
||||
events are errors reported by the CPU. Processing them is strongly encouraged.
|
||||
All x86-64 kernels since 2.6.4 require the mcelog utility to
|
||||
process machine checks.
|
||||
|
||||
Getting updated software
|
||||
========================
|
||||
|
||||
|
|
@ -365,6 +376,10 @@ FUSE
|
|||
----
|
||||
o <http://sourceforge.net/projects/fuse>
|
||||
|
||||
mcelog
|
||||
------
|
||||
o <ftp://ftp.kernel.org/pub/linux/utils/cpu/mce/mcelog/>
|
||||
|
||||
Networking
|
||||
**********
|
||||
|
||||
|
|
|
|||
|
|
@ -698,8 +698,8 @@ very often is not. Abundant use of the inline keyword leads to a much bigger
|
|||
kernel, which in turn slows the system as a whole down, due to a bigger
|
||||
icache footprint for the CPU and simply because there is less memory
|
||||
available for the pagecache. Just think about it; a pagecache miss causes a
|
||||
disk seek, which easily takes 5 miliseconds. There are a LOT of cpu cycles
|
||||
that can go into these 5 miliseconds.
|
||||
disk seek, which easily takes 5 milliseconds. There are a LOT of cpu cycles
|
||||
that can go into these 5 milliseconds.
|
||||
|
||||
A reasonable rule of thumb is to not put inline at functions that have more
|
||||
than 3 lines of code in them. An exception to this rule are the cases where
|
||||
|
|
|
|||
|
|
@ -676,8 +676,8 @@ this directory the following files can currently be found:
|
|||
dma-api/all_errors This file contains a numeric value. If this
|
||||
value is not equal to zero the debugging code
|
||||
will print a warning for every error it finds
|
||||
into the kernel log. Be carefull with this
|
||||
option. It can easily flood your logs.
|
||||
into the kernel log. Be careful with this
|
||||
option, as it can easily flood your logs.
|
||||
|
||||
dma-api/disabled This read-only file contains the character 'Y'
|
||||
if the debugging code is disabled. This can
|
||||
|
|
|
|||
|
|
@ -118,7 +118,7 @@ to another chain) checking the final 'nulls' value if
|
|||
the lookup met the end of chain. If final 'nulls' value
|
||||
is not the slot number, then we must restart the lookup at
|
||||
the beginning. If the object was moved to the same chain,
|
||||
then the reader doesnt care : It might eventually
|
||||
then the reader doesn't care : It might eventually
|
||||
scan the list again without harm.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ Copyright 2006, 2007 Simtec Electronics
|
|||
|
||||
The Silicon Motion SM501 multimedia companion chip is a multifunction device
|
||||
which may provide numerous interfaces including USB host controller USB gadget,
|
||||
Asyncronous Serial ports, Audio functions and a dual display video interface.
|
||||
asynchronous serial ports, audio functions, and a dual display video interface.
|
||||
The device may be connected by PCI or local bus with varying functions enabled.
|
||||
|
||||
Core
|
||||
|
|
|
|||
|
|
@ -91,6 +91,10 @@ Be as specific as possible. The WORST descriptions possible include
|
|||
things like "update driver X", "bug fix for driver X", or "this patch
|
||||
includes updates for subsystem X. Please apply."
|
||||
|
||||
The maintainer will thank you if you write your patch description in a
|
||||
form which can be easily pulled into Linux's source code management
|
||||
system, git, as a "commit log". See #15, below.
|
||||
|
||||
If your description starts to get long, that's a sign that you probably
|
||||
need to split up your patch. See #3, next.
|
||||
|
||||
|
|
@ -183,8 +187,9 @@ Even if the maintainer did not respond in step #4, make sure to ALWAYS
|
|||
copy the maintainer when you change their code.
|
||||
|
||||
For small patches you may want to CC the Trivial Patch Monkey
|
||||
trivial@kernel.org managed by Jesper Juhl; which collects "trivial"
|
||||
patches. Trivial patches must qualify for one of the following rules:
|
||||
trivial@kernel.org which collects "trivial" patches. Have a look
|
||||
into the MAINTAINERS file for its current manager.
|
||||
Trivial patches must qualify for one of the following rules:
|
||||
Spelling fixes in documentation
|
||||
Spelling fixes which could break grep(1)
|
||||
Warning fixes (cluttering with useless warnings is bad)
|
||||
|
|
@ -196,7 +201,6 @@ patches. Trivial patches must qualify for one of the following rules:
|
|||
since people copy, as long as it's trivial)
|
||||
Any fix by the author/maintainer of the file (ie. patch monkey
|
||||
in re-transmission mode)
|
||||
URL: <http://www.kernel.org/pub/linux/kernel/people/juhl/trivial/>
|
||||
|
||||
|
||||
|
||||
|
|
@ -405,7 +409,14 @@ person it names. This tag documents that potentially interested parties
|
|||
have been included in the discussion
|
||||
|
||||
|
||||
14) Using Tested-by: and Reviewed-by:
|
||||
14) Using Reported-by:, Tested-by: and Reviewed-by:
|
||||
|
||||
If this patch fixes a problem reported by somebody else, consider adding a
|
||||
Reported-by: tag to credit the reporter for their contribution. Please
|
||||
note that this tag should not be added without the reporter's permission,
|
||||
especially if the problem was not reported in a public forum. That said,
|
||||
if we diligently credit our bug reporters, they will, hopefully, be
|
||||
inspired to help us again in the future.
|
||||
|
||||
A Tested-by: tag indicates that the patch has been successfully tested (in
|
||||
some environment) by the person named. This tag informs maintainers that
|
||||
|
|
@ -444,7 +455,7 @@ offer a Reviewed-by tag for a patch. This tag serves to give credit to
|
|||
reviewers and to inform maintainers of the degree of review which has been
|
||||
done on the patch. Reviewed-by: tags, when supplied by reviewers known to
|
||||
understand the subject area and to perform thorough reviews, will normally
|
||||
increase the liklihood of your patch getting into the kernel.
|
||||
increase the likelihood of your patch getting into the kernel.
|
||||
|
||||
|
||||
15) The canonical patch format
|
||||
|
|
@ -485,12 +496,33 @@ phrase" should not be a filename. Do not use the same "summary
|
|||
phrase" for every patch in a whole patch series (where a "patch
|
||||
series" is an ordered sequence of multiple, related patches).
|
||||
|
||||
Bear in mind that the "summary phrase" of your email becomes
|
||||
a globally-unique identifier for that patch. It propagates
|
||||
all the way into the git changelog. The "summary phrase" may
|
||||
later be used in developer discussions which refer to the patch.
|
||||
People will want to google for the "summary phrase" to read
|
||||
discussion regarding that patch.
|
||||
Bear in mind that the "summary phrase" of your email becomes a
|
||||
globally-unique identifier for that patch. It propagates all the way
|
||||
into the git changelog. The "summary phrase" may later be used in
|
||||
developer discussions which refer to the patch. People will want to
|
||||
google for the "summary phrase" to read discussion regarding that
|
||||
patch. It will also be the only thing that people may quickly see
|
||||
when, two or three months later, they are going through perhaps
|
||||
thousands of patches using tools such as "gitk" or "git log
|
||||
--oneline".
|
||||
|
||||
For these reasons, the "summary" must be no more than 70-75
|
||||
characters, and it must describe both what the patch changes, as well
|
||||
as why the patch might be necessary. It is challenging to be both
|
||||
succinct and descriptive, but that is what a well-written summary
|
||||
should do.
|
||||
|
||||
The "summary phrase" may be prefixed by tags enclosed in square
|
||||
brackets: "Subject: [PATCH tag] <summary phrase>". The tags are not
|
||||
considered part of the summary phrase, but describe how the patch
|
||||
should be treated. Common tags might include a version descriptor if
|
||||
the multiple versions of the patch have been sent out in response to
|
||||
comments (i.e., "v1, v2, v3"), or "RFC" to indicate a request for
|
||||
comments. If there are four patches in a patch series the individual
|
||||
patches may be numbered like this: 1/4, 2/4, 3/4, 4/4. This assures
|
||||
that developers understand the order in which the patches should be
|
||||
applied and that they have reviewed or applied all of the patches in
|
||||
the patch series.
|
||||
|
||||
A couple of example Subjects:
|
||||
|
||||
|
|
@ -510,19 +542,31 @@ the patch author in the changelog.
|
|||
The explanation body will be committed to the permanent source
|
||||
changelog, so should make sense to a competent reader who has long
|
||||
since forgotten the immediate details of the discussion that might
|
||||
have led to this patch.
|
||||
have led to this patch. Including symptoms of the failure which the
|
||||
patch addresses (kernel log messages, oops messages, etc.) is
|
||||
especially useful for people who might be searching the commit logs
|
||||
looking for the applicable patch. If a patch fixes a compile failure,
|
||||
it may not be necessary to include _all_ of the compile failures; just
|
||||
enough that it is likely that someone searching for the patch can find
|
||||
it. As in the "summary phrase", it is important to be both succinct as
|
||||
well as descriptive.
|
||||
|
||||
The "---" marker line serves the essential purpose of marking for patch
|
||||
handling tools where the changelog message ends.
|
||||
|
||||
One good use for the additional comments after the "---" marker is for
|
||||
a diffstat, to show what files have changed, and the number of inserted
|
||||
and deleted lines per file. A diffstat is especially useful on bigger
|
||||
patches. Other comments relevant only to the moment or the maintainer,
|
||||
not suitable for the permanent changelog, should also go here.
|
||||
Use diffstat options "-p 1 -w 70" so that filenames are listed from the
|
||||
top of the kernel source tree and don't use too much horizontal space
|
||||
(easily fit in 80 columns, maybe with some indentation).
|
||||
a diffstat, to show what files have changed, and the number of
|
||||
inserted and deleted lines per file. A diffstat is especially useful
|
||||
on bigger patches. Other comments relevant only to the moment or the
|
||||
maintainer, not suitable for the permanent changelog, should also go
|
||||
here. A good example of such comments might be "patch changelogs"
|
||||
which describe what has changed between the v1 and v2 version of the
|
||||
patch.
|
||||
|
||||
If you are going to include a diffstat after the "---" marker, please
|
||||
use diffstat options "-p 1 -w 70" so that filenames are listed from
|
||||
the top of the kernel source tree and don't use too much horizontal
|
||||
space (easily fit in 80 columns, maybe with some indentation).
|
||||
|
||||
See more details on the proper patch format in the following
|
||||
references.
|
||||
|
|
|
|||
|
|
@ -51,7 +51,7 @@ PIN Numbers
|
|||
-----------
|
||||
|
||||
Each pin has an unique number associated with it in regs-gpio.h,
|
||||
eg S3C2410_GPA0 or S3C2410_GPF1. These defines are used to tell
|
||||
eg S3C2410_GPA(0) or S3C2410_GPF(1). These defines are used to tell
|
||||
the GPIO functions which pin is to be used.
|
||||
|
||||
|
||||
|
|
@ -65,11 +65,11 @@ Configuring a pin
|
|||
|
||||
Eg:
|
||||
|
||||
s3c2410_gpio_cfgpin(S3C2410_GPA0, S3C2410_GPA0_ADDR0);
|
||||
s3c2410_gpio_cfgpin(S3C2410_GPE8, S3C2410_GPE8_SDDAT1);
|
||||
s3c2410_gpio_cfgpin(S3C2410_GPA(0), S3C2410_GPA0_ADDR0);
|
||||
s3c2410_gpio_cfgpin(S3C2410_GPE(8), S3C2410_GPE8_SDDAT1);
|
||||
|
||||
which would turn GPA0 into the lowest Address line A0, and set
|
||||
GPE8 to be connected to the SDIO/MMC controller's SDDAT1 line.
|
||||
which would turn GPA(0) into the lowest Address line A0, and set
|
||||
GPE(8) to be connected to the SDIO/MMC controller's SDDAT1 line.
|
||||
|
||||
|
||||
Reading the current configuration
|
||||
|
|
|
|||
|
|
@ -58,7 +58,7 @@ same criteria as reads.
|
|||
front_merges (bool)
|
||||
------------
|
||||
|
||||
Sometimes it happens that a request enters the io scheduler that is contigious
|
||||
Sometimes it happens that a request enters the io scheduler that is contiguous
|
||||
with a request that is already on the queue. Either it fits in the back of that
|
||||
request, or it fits at the front. That is called either a back merge candidate
|
||||
or a front merge candidate. Due to the way files are typically laid out,
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ parameter.
|
|||
|
||||
For simplicity, only one braille console can be enabled, other uses of
|
||||
console=brl,... will be discarded. Also note that it does not interfere with
|
||||
the console selection mecanism described in serial-console.txt
|
||||
the console selection mechanism described in serial-console.txt
|
||||
|
||||
For now, only the VisioBraille device is supported.
|
||||
|
||||
|
|
|
|||
|
|
@ -76,9 +76,9 @@ Do the steps below to download the BIOS image.
|
|||
|
||||
The /sys/class/firmware/dell_rbu/ entries will remain till the following is
|
||||
done.
|
||||
echo -1 > /sys/class/firmware/dell_rbu/loading.
|
||||
echo -1 > /sys/class/firmware/dell_rbu/loading
|
||||
Until this step is completed the driver cannot be unloaded.
|
||||
Also echoing either mono ,packet or init in to image_type will free up the
|
||||
Also echoing either mono, packet or init in to image_type will free up the
|
||||
memory allocated by the driver.
|
||||
|
||||
If a user by accident executes steps 1 and 3 above without executing step 2;
|
||||
|
|
|
|||
|
|
@ -119,7 +119,7 @@ which takes quite a bit of time and thought after the "real work" has been
|
|||
done. When done properly, though, it is time well spent.
|
||||
|
||||
|
||||
5.4: PATCH FORMATTING
|
||||
5.4: PATCH FORMATTING AND CHANGELOGS
|
||||
|
||||
So now you have a perfect series of patches for posting, but the work is
|
||||
not done quite yet. Each patch needs to be formatted into a message which
|
||||
|
|
@ -146,8 +146,33 @@ that end, each patch will be composed of the following:
|
|||
- One or more tag lines, with, at a minimum, one Signed-off-by: line from
|
||||
the author of the patch. Tags will be described in more detail below.
|
||||
|
||||
The above three items should, normally, be the text used when committing
|
||||
the change to a revision control system. They are followed by:
|
||||
The items above, together, form the changelog for the patch. Writing good
|
||||
changelogs is a crucial but often-neglected art; it's worth spending
|
||||
another moment discussing this issue. When writing a changelog, you should
|
||||
bear in mind that a number of different people will be reading your words.
|
||||
These include subsystem maintainers and reviewers who need to decide
|
||||
whether the patch should be included, distributors and other maintainers
|
||||
trying to decide whether a patch should be backported to other kernels, bug
|
||||
hunters wondering whether the patch is responsible for a problem they are
|
||||
chasing, users who want to know how the kernel has changed, and more. A
|
||||
good changelog conveys the needed information to all of these people in the
|
||||
most direct and concise way possible.
|
||||
|
||||
To that end, the summary line should describe the effects of and motivation
|
||||
for the change as well as possible given the one-line constraint. The
|
||||
detailed description can then amplify on those topics and provide any
|
||||
needed additional information. If the patch fixes a bug, cite the commit
|
||||
which introduced the bug if possible. If a problem is associated with
|
||||
specific log or compiler output, include that output to help others
|
||||
searching for a solution to the same problem. If the change is meant to
|
||||
support other changes coming in later patch, say so. If internal APIs are
|
||||
changed, detail those changes and how other developers should respond. In
|
||||
general, the more you can put yourself into the shoes of everybody who will
|
||||
be reading your changelog, the better that changelog (and the kernel as a
|
||||
whole) will be.
|
||||
|
||||
Needless to say, the changelog should be the text used when committing the
|
||||
change to a revision control system. It will be followed by:
|
||||
|
||||
- The patch itself, in the unified ("-u") patch format. Using the "-p"
|
||||
option to diff will associate function names with changes, making the
|
||||
|
|
|
|||
|
|
@ -188,7 +188,7 @@ For example, you can do something like the following.
|
|||
|
||||
void my_midlayer_destroy_something()
|
||||
{
|
||||
devres_release_group(dev, my_midlayer_create_soemthing);
|
||||
devres_release_group(dev, my_midlayer_create_something);
|
||||
}
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -23,8 +23,8 @@ first time, it was renamed to 'EDAC'.
|
|||
The bluesmoke project at sourceforge.net is now utilized as a 'staging area'
|
||||
for EDAC development, before it is sent upstream to kernel.org
|
||||
|
||||
At the bluesmoke/EDAC project site, is a series of quilt patches against
|
||||
recent kernels, stored in a SVN respository. For easier downloading, there
|
||||
At the bluesmoke/EDAC project site is a series of quilt patches against
|
||||
recent kernels, stored in a SVN repository. For easier downloading, there
|
||||
is also a tarball snapshot available.
|
||||
|
||||
============================================================================
|
||||
|
|
@ -73,9 +73,9 @@ the vendor should tie the parity status bits to 0 if they do not intend
|
|||
to generate parity. Some vendors do not do this, and thus the parity bit
|
||||
can "float" giving false positives.
|
||||
|
||||
In the kernel there is a pci device attribute located in sysfs that is
|
||||
In the kernel there is a PCI device attribute located in sysfs that is
|
||||
checked by the EDAC PCI scanning code. If that attribute is set,
|
||||
PCI parity/error scannining is skipped for that device. The attribute
|
||||
PCI parity/error scanning is skipped for that device. The attribute
|
||||
is:
|
||||
|
||||
broken_parity_status
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
SH7760/SH7763 integrated LCDC Framebuffer driver
|
||||
================================================
|
||||
|
||||
0. Overwiew
|
||||
0. Overview
|
||||
-----------
|
||||
The SH7760/SH7763 have an integrated LCD Display controller (LCDC) which
|
||||
supports (in theory) resolutions ranging from 1x1 to 1024x1024,
|
||||
|
|
|
|||
|
|
@ -437,3 +437,13 @@ Why: Superseded by tdfxfb. I2C/DDC support used to live in a separate
|
|||
driver but this caused driver conflicts.
|
||||
Who: Jean Delvare <khali@linux-fr.org>
|
||||
Krzysztof Helt <krzysztof.h1@wp.pl>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: CONFIG_X86_OLD_MCE
|
||||
When: 2.6.32
|
||||
Why: Remove the old legacy 32bit machine check code. This has been
|
||||
superseded by the newer machine check code from the 64bit port,
|
||||
but the old version has been kept around for easier testing. Note this
|
||||
doesn't impact the old P5 and WinChip machine check handlers.
|
||||
Who: Andi Kleen <andi@firstfloor.org>
|
||||
|
|
|
|||
|
|
@ -369,7 +369,7 @@ The call requires an initialized struct autofs_dev_ioctl. There are two
|
|||
possible variations. Both use the path field set to the path of the mount
|
||||
point to check and the size field adjusted appropriately. One uses the
|
||||
ioctlfd field to identify a specific mount point to check while the other
|
||||
variation uses the path and optionaly arg1 set to an autofs mount type.
|
||||
variation uses the path and optionally arg1 set to an autofs mount type.
|
||||
The call returns 1 if this is a mount point and sets arg1 to the device
|
||||
number of the mount and field arg2 to the relevant super block magic
|
||||
number (described below) or 0 if it isn't a mountpoint. In both cases
|
||||
|
|
|
|||
|
|
@ -184,7 +184,7 @@ This has the following fields:
|
|||
have index children.
|
||||
|
||||
If this function is not supplied or if it returns NULL then the first
|
||||
cache in the parent's list will be chosed, or failing that, the first
|
||||
cache in the parent's list will be chosen, or failing that, the first
|
||||
cache in the master list.
|
||||
|
||||
(4) A function to retrieve an object's key from the netfs [mandatory].
|
||||
|
|
|
|||
|
|
@ -0,0 +1,158 @@
|
|||
Copyright 2009 Jonathan Corbet <corbet@lwn.net>
|
||||
|
||||
Debugfs exists as a simple way for kernel developers to make information
|
||||
available to user space. Unlike /proc, which is only meant for information
|
||||
about a process, or sysfs, which has strict one-value-per-file rules,
|
||||
debugfs has no rules at all. Developers can put any information they want
|
||||
there. The debugfs filesystem is also intended to not serve as a stable
|
||||
ABI to user space; in theory, there are no stability constraints placed on
|
||||
files exported there. The real world is not always so simple, though [1];
|
||||
even debugfs interfaces are best designed with the idea that they will need
|
||||
to be maintained forever.
|
||||
|
||||
Debugfs is typically mounted with a command like:
|
||||
|
||||
mount -t debugfs none /sys/kernel/debug
|
||||
|
||||
(Or an equivalent /etc/fstab line).
|
||||
|
||||
Note that the debugfs API is exported GPL-only to modules.
|
||||
|
||||
Code using debugfs should include <linux/debugfs.h>. Then, the first order
|
||||
of business will be to create at least one directory to hold a set of
|
||||
debugfs files:
|
||||
|
||||
struct dentry *debugfs_create_dir(const char *name, struct dentry *parent);
|
||||
|
||||
This call, if successful, will make a directory called name underneath the
|
||||
indicated parent directory. If parent is NULL, the directory will be
|
||||
created in the debugfs root. On success, the return value is a struct
|
||||
dentry pointer which can be used to create files in the directory (and to
|
||||
clean it up at the end). A NULL return value indicates that something went
|
||||
wrong. If ERR_PTR(-ENODEV) is returned, that is an indication that the
|
||||
kernel has been built without debugfs support and none of the functions
|
||||
described below will work.
|
||||
|
||||
The most general way to create a file within a debugfs directory is with:
|
||||
|
||||
struct dentry *debugfs_create_file(const char *name, mode_t mode,
|
||||
struct dentry *parent, void *data,
|
||||
const struct file_operations *fops);
|
||||
|
||||
Here, name is the name of the file to create, mode describes the access
|
||||
permissions the file should have, parent indicates the directory which
|
||||
should hold the file, data will be stored in the i_private field of the
|
||||
resulting inode structure, and fops is a set of file operations which
|
||||
implement the file's behavior. At a minimum, the read() and/or write()
|
||||
operations should be provided; others can be included as needed. Again,
|
||||
the return value will be a dentry pointer to the created file, NULL for
|
||||
error, or ERR_PTR(-ENODEV) if debugfs support is missing.
|
||||
|
||||
In a number of cases, the creation of a set of file operations is not
|
||||
actually necessary; the debugfs code provides a number of helper functions
|
||||
for simple situations. Files containing a single integer value can be
|
||||
created with any of:
|
||||
|
||||
struct dentry *debugfs_create_u8(const char *name, mode_t mode,
|
||||
struct dentry *parent, u8 *value);
|
||||
struct dentry *debugfs_create_u16(const char *name, mode_t mode,
|
||||
struct dentry *parent, u16 *value);
|
||||
struct dentry *debugfs_create_u32(const char *name, mode_t mode,
|
||||
struct dentry *parent, u32 *value);
|
||||
struct dentry *debugfs_create_u64(const char *name, mode_t mode,
|
||||
struct dentry *parent, u64 *value);
|
||||
|
||||
These files support both reading and writing the given value; if a specific
|
||||
file should not be written to, simply set the mode bits accordingly. The
|
||||
values in these files are in decimal; if hexadecimal is more appropriate,
|
||||
the following functions can be used instead:
|
||||
|
||||
struct dentry *debugfs_create_x8(const char *name, mode_t mode,
|
||||
struct dentry *parent, u8 *value);
|
||||
struct dentry *debugfs_create_x16(const char *name, mode_t mode,
|
||||
struct dentry *parent, u16 *value);
|
||||
struct dentry *debugfs_create_x32(const char *name, mode_t mode,
|
||||
struct dentry *parent, u32 *value);
|
||||
|
||||
Note that there is no debugfs_create_x64().
|
||||
|
||||
These functions are useful as long as the developer knows the size of the
|
||||
value to be exported. Some types can have different widths on different
|
||||
architectures, though, complicating the situation somewhat. There is a
|
||||
function meant to help out in one special case:
|
||||
|
||||
struct dentry *debugfs_create_size_t(const char *name, mode_t mode,
|
||||
struct dentry *parent,
|
||||
size_t *value);
|
||||
|
||||
As might be expected, this function will create a debugfs file to represent
|
||||
a variable of type size_t.
|
||||
|
||||
Boolean values can be placed in debugfs with:
|
||||
|
||||
struct dentry *debugfs_create_bool(const char *name, mode_t mode,
|
||||
struct dentry *parent, u32 *value);
|
||||
|
||||
A read on the resulting file will yield either Y (for non-zero values) or
|
||||
N, followed by a newline. If written to, it will accept either upper- or
|
||||
lower-case values, or 1 or 0. Any other input will be silently ignored.
|
||||
|
||||
Finally, a block of arbitrary binary data can be exported with:
|
||||
|
||||
struct debugfs_blob_wrapper {
|
||||
void *data;
|
||||
unsigned long size;
|
||||
};
|
||||
|
||||
struct dentry *debugfs_create_blob(const char *name, mode_t mode,
|
||||
struct dentry *parent,
|
||||
struct debugfs_blob_wrapper *blob);
|
||||
|
||||
A read of this file will return the data pointed to by the
|
||||
debugfs_blob_wrapper structure. Some drivers use "blobs" as a simple way
|
||||
to return several lines of (static) formatted text output. This function
|
||||
can be used to export binary information, but there does not appear to be
|
||||
any code which does so in the mainline. Note that all files created with
|
||||
debugfs_create_blob() are read-only.
|
||||
|
||||
There are a couple of other directory-oriented helper functions:
|
||||
|
||||
struct dentry *debugfs_rename(struct dentry *old_dir,
|
||||
struct dentry *old_dentry,
|
||||
struct dentry *new_dir,
|
||||
const char *new_name);
|
||||
|
||||
struct dentry *debugfs_create_symlink(const char *name,
|
||||
struct dentry *parent,
|
||||
const char *target);
|
||||
|
||||
A call to debugfs_rename() will give a new name to an existing debugfs
|
||||
file, possibly in a different directory. The new_name must not exist prior
|
||||
to the call; the return value is old_dentry with updated information.
|
||||
Symbolic links can be created with debugfs_create_symlink().
|
||||
|
||||
There is one important thing that all debugfs users must take into account:
|
||||
there is no automatic cleanup of any directories created in debugfs. If a
|
||||
module is unloaded without explicitly removing debugfs entries, the result
|
||||
will be a lot of stale pointers and no end of highly antisocial behavior.
|
||||
So all debugfs users - at least those which can be built as modules - must
|
||||
be prepared to remove all files and directories they create there. A file
|
||||
can be removed with:
|
||||
|
||||
void debugfs_remove(struct dentry *dentry);
|
||||
|
||||
The dentry value can be NULL, in which case nothing will be removed.
|
||||
|
||||
Once upon a time, debugfs users were required to remember the dentry
|
||||
pointer for every debugfs file they created so that all files could be
|
||||
cleaned up. We live in more civilized times now, though, and debugfs users
|
||||
can call:
|
||||
|
||||
void debugfs_remove_recursive(struct dentry *dentry);
|
||||
|
||||
If this function is passed a pointer for the dentry corresponding to the
|
||||
top-level directory, the entire hierarchy below that directory will be
|
||||
removed.
|
||||
|
||||
Notes:
|
||||
[1] http://lwn.net/Articles/309298/
|
||||
|
|
@ -294,7 +294,7 @@ max_batch_time=usec Maximum amount of time ext4 should wait for
|
|||
amount of time (on average) that it takes to
|
||||
finish committing a transaction. Call this time
|
||||
the "commit time". If the time that the
|
||||
transactoin has been running is less than the
|
||||
transaction has been running is less than the
|
||||
commit time, ext4 will try sleeping for the
|
||||
commit time to see if other operations will join
|
||||
the transaction. The commit time is capped by
|
||||
|
|
@ -328,7 +328,7 @@ noauto_da_alloc replacing existing files via patterns such as
|
|||
journal commit, in the default data=ordered
|
||||
mode, the data blocks of the new file are forced
|
||||
to disk before the rename() operation is
|
||||
commited. This provides roughly the same level
|
||||
committed. This provides roughly the same level
|
||||
of guarantees as ext3, and avoids the
|
||||
"zero-length" problem that can happen when a
|
||||
system crashes before the delayed allocation
|
||||
|
|
@ -358,7 +358,7 @@ written to the journal first, and then to its final location.
|
|||
In the event of a crash, the journal can be replayed, bringing both data and
|
||||
metadata into a consistent state. This mode is the slowest except when data
|
||||
needs to be read from and written to disk at the same time where it
|
||||
outperforms all others modes. Curently ext4 does not have delayed
|
||||
outperforms all others modes. Currently ext4 does not have delayed
|
||||
allocation support if this data journalling mode is selected.
|
||||
|
||||
References
|
||||
|
|
|
|||
|
|
@ -204,7 +204,7 @@ fiemap_check_flags() helper:
|
|||
|
||||
int fiemap_check_flags(struct fiemap_extent_info *fieinfo, u32 fs_flags);
|
||||
|
||||
The struct fieinfo should be passed in as recieved from ioctl_fiemap(). The
|
||||
The struct fieinfo should be passed in as received from ioctl_fiemap(). The
|
||||
set of fiemap flags which the fs understands should be passed via fs_flags. If
|
||||
fiemap_check_flags finds invalid user flags, it will place the bad values in
|
||||
fieinfo->fi_flags and return -EBADR. If the file system gets -EBADR, from
|
||||
|
|
|
|||
|
|
@ -100,7 +100,7 @@ Installation
|
|||
$ sudo cp utils/mount/mount.nfs /sbin/mount.nfs
|
||||
|
||||
In this location, mount.nfs will be invoked automatically for NFS mounts
|
||||
by the system mount commmand.
|
||||
by the system mount command.
|
||||
|
||||
NOTE: mount.nfs and therefore nfs-utils-1.1.2 or greater is only needed
|
||||
on the NFS client machine. You do not need this specific version of
|
||||
|
|
|
|||
|
|
@ -366,7 +366,7 @@ just those considered 'most important'. The new vectors are:
|
|||
RES, CAL, TLB -- rescheduling, call and TLB flush interrupts are
|
||||
sent from one CPU to another per the needs of the OS. Typically,
|
||||
their statistics are used by kernel developers and interested users to
|
||||
determine the occurance of interrupt of the given type.
|
||||
determine the occurrence of interrupts of the given type.
|
||||
|
||||
The above IRQ vectors are displayed only when relevent. For example,
|
||||
the threshold vector does not exist on x86_64 platforms. Others are
|
||||
|
|
@ -551,7 +551,7 @@ Committed_AS: The amount of memory presently allocated on the system.
|
|||
memory once that memory has been successfully allocated.
|
||||
VmallocTotal: total size of vmalloc memory area
|
||||
VmallocUsed: amount of vmalloc area which is used
|
||||
VmallocChunk: largest contigious block of vmalloc area which is free
|
||||
VmallocChunk: largest contiguous block of vmalloc area which is free
|
||||
|
||||
..............................................................................
|
||||
|
||||
|
|
|
|||
|
|
@ -72,7 +72,7 @@ The 'rom' file is special in that it provides read-only access to the device's
|
|||
ROM file, if available. It's disabled by default, however, so applications
|
||||
should write the string "1" to the file to enable it before attempting a read
|
||||
call, and disable it following the access by writing "0" to the file. Note
|
||||
that the device must be enabled for a rom read to return data succesfully.
|
||||
that the device must be enabled for a rom read to return data successfully.
|
||||
In the event a driver is not bound to the device, it can be enabled using the
|
||||
'enable' file, documented above.
|
||||
|
||||
|
|
|
|||
|
|
@ -124,10 +124,10 @@ sys_immutable -- If set, ATTR_SYS attribute on FAT is handled as
|
|||
flush -- If set, the filesystem will try to flush to disk more
|
||||
early than normal. Not set by default.
|
||||
|
||||
rodir -- FAT has the ATTR_RO (read-only) attribute. But on Windows,
|
||||
the ATTR_RO of the directory will be just ignored actually,
|
||||
and is used by only applications as flag. E.g. it's setted
|
||||
for the customized folder.
|
||||
rodir -- FAT has the ATTR_RO (read-only) attribute. On Windows,
|
||||
the ATTR_RO of the directory will just be ignored,
|
||||
and is used only by applications as a flag (e.g. it's set
|
||||
for the customized folder).
|
||||
|
||||
If you want to use ATTR_RO as read-only flag even for
|
||||
the directory, set this option.
|
||||
|
|
|
|||
|
|
@ -458,7 +458,7 @@ debugfs interface, since it provides control over GPIO direction and
|
|||
value instead of just showing a gpio state summary. Plus, it could be
|
||||
present on production systems without debugging support.
|
||||
|
||||
Given approprate hardware documentation for the system, userspace could
|
||||
Given appropriate hardware documentation for the system, userspace could
|
||||
know for example that GPIO #23 controls the write protect line used to
|
||||
protect boot loader segments in flash memory. System upgrade procedures
|
||||
may need to temporarily remove that protection, first importing a GPIO,
|
||||
|
|
|
|||
|
|
@ -20,6 +20,8 @@ platform_device with the base address and interrupt number. The
|
|||
dev.platform_data of the device should also point to a struct
|
||||
ocores_i2c_platform_data (see linux/i2c-ocores.h) describing the
|
||||
distance between registers and the input clock speed.
|
||||
There is also a possibility to attach a list of i2c_board_info which
|
||||
the i2c-ocores driver will add to the bus upon creation.
|
||||
|
||||
E.G. something like:
|
||||
|
||||
|
|
@ -36,9 +38,24 @@ static struct resource ocores_resources[] = {
|
|||
},
|
||||
};
|
||||
|
||||
/* optional board info */
|
||||
struct i2c_board_info ocores_i2c_board_info[] = {
|
||||
{
|
||||
I2C_BOARD_INFO("tsc2003", 0x48),
|
||||
.platform_data = &tsc2003_platform_data,
|
||||
.irq = TSC_IRQ
|
||||
},
|
||||
{
|
||||
I2C_BOARD_INFO("adv7180", 0x42 >> 1),
|
||||
.irq = ADV_IRQ
|
||||
}
|
||||
};
|
||||
|
||||
static struct ocores_i2c_platform_data myi2c_data = {
|
||||
.regstep = 2, /* two bytes between registers */
|
||||
.clock_khz = 50000, /* input clock of 50MHz */
|
||||
.devices = ocores_i2c_board_info, /* optional table of devices */
|
||||
.num_devices = ARRAY_SIZE(ocores_i2c_board_info), /* table size */
|
||||
};
|
||||
|
||||
static struct platform_device myi2c = {
|
||||
|
|
|
|||
|
|
@ -216,6 +216,8 @@ Other kernel parameters for ide_core are:
|
|||
|
||||
* "noflush=[interface_number.device_number]" to disable flush requests
|
||||
|
||||
* "nohpa=[interface_number.device_number]" to disable Host Protected Area
|
||||
|
||||
* "noprobe=[interface_number.device_number]" to skip probing
|
||||
|
||||
* "nowerr=[interface_number.device_number]" to ignore the WRERR_STAT bit
|
||||
|
|
|
|||
|
|
@ -35,6 +35,79 @@ new .config files to see the differences:
|
|||
|
||||
(Yes, we need something better here.)
|
||||
|
||||
______________________________________________________________________
|
||||
Environment variables for '*config'
|
||||
|
||||
KCONFIG_CONFIG
|
||||
--------------------------------------------------
|
||||
This environment variable can be used to specify a default kernel config
|
||||
file name to override the default name of ".config".
|
||||
|
||||
KCONFIG_OVERWRITECONFIG
|
||||
--------------------------------------------------
|
||||
If you set KCONFIG_OVERWRITECONFIG in the environment, Kconfig will not
|
||||
break symlinks when .config is a symlink to somewhere else.
|
||||
|
||||
KCONFIG_NOTIMESTAMP
|
||||
--------------------------------------------------
|
||||
If this environment variable exists and is non-null, the timestamp line
|
||||
in generated .config files is omitted.
|
||||
|
||||
______________________________________________________________________
|
||||
Environment variables for '{allyes/allmod/allno/rand}config'
|
||||
|
||||
KCONFIG_ALLCONFIG
|
||||
--------------------------------------------------
|
||||
(partially based on lkml email from/by Rob Landley, re: miniconfig)
|
||||
--------------------------------------------------
|
||||
The allyesconfig/allmodconfig/allnoconfig/randconfig variants can
|
||||
also use the environment variable KCONFIG_ALLCONFIG as a flag or a
|
||||
filename that contains config symbols that the user requires to be
|
||||
set to a specific value. If KCONFIG_ALLCONFIG is used without a
|
||||
filename, "make *config" checks for a file named
|
||||
"all{yes/mod/no/random}.config" (corresponding to the *config command
|
||||
that was used) for symbol values that are to be forced. If this file
|
||||
is not found, it checks for a file named "all.config" to contain forced
|
||||
values.
|
||||
|
||||
This enables you to create "miniature" config (miniconfig) or custom
|
||||
config files containing just the config symbols that you are interested
|
||||
in. Then the kernel config system generates the full .config file,
|
||||
including symbols of your miniconfig file.
|
||||
|
||||
This 'KCONFIG_ALLCONFIG' file is a config file which contains
|
||||
(usually a subset of all) preset config symbols. These variable
|
||||
settings are still subject to normal dependency checks.
|
||||
|
||||
Examples:
|
||||
KCONFIG_ALLCONFIG=custom-notebook.config make allnoconfig
|
||||
or
|
||||
KCONFIG_ALLCONFIG=mini.config make allnoconfig
|
||||
or
|
||||
make KCONFIG_ALLCONFIG=mini.config allnoconfig
|
||||
|
||||
These examples will disable most options (allnoconfig) but enable or
|
||||
disable the options that are explicitly listed in the specified
|
||||
mini-config files.
|
||||
|
||||
______________________________________________________________________
|
||||
Environment variables for 'silentoldconfig'
|
||||
|
||||
KCONFIG_NOSILENTUPDATE
|
||||
--------------------------------------------------
|
||||
If this variable has a non-blank value, it prevents silent kernel
|
||||
config udpates (requires explicit updates).
|
||||
|
||||
KCONFIG_AUTOCONFIG
|
||||
--------------------------------------------------
|
||||
This environment variable can be set to specify the path & name of the
|
||||
"auto.conf" file. Its default value is "include/config/auto.conf".
|
||||
|
||||
KCONFIG_AUTOHEADER
|
||||
--------------------------------------------------
|
||||
This environment variable can be set to specify the path & name of the
|
||||
"autoconf.h" (header) file. Its default value is "include/linux/autoconf.h".
|
||||
|
||||
|
||||
======================================================================
|
||||
menuconfig
|
||||
|
|
@ -60,10 +133,11 @@ Searching in menuconfig:
|
|||
|
||||
/^hotplug
|
||||
|
||||
|
||||
______________________________________________________________________
|
||||
Color Themes for 'menuconfig'
|
||||
User interface options for 'menuconfig'
|
||||
|
||||
MENUCONFIG_COLOR
|
||||
--------------------------------------------------
|
||||
It is possible to select different color themes using the variable
|
||||
MENUCONFIG_COLOR. To select a theme use:
|
||||
|
||||
|
|
@ -75,83 +149,13 @@ Available themes are:
|
|||
classic => theme with blue background. The classic look
|
||||
bluetitle => a LCD friendly version of classic. (default)
|
||||
|
||||
______________________________________________________________________
|
||||
Environment variables in 'menuconfig'
|
||||
|
||||
KCONFIG_ALLCONFIG
|
||||
--------------------------------------------------
|
||||
(partially based on lkml email from/by Rob Landley, re: miniconfig)
|
||||
--------------------------------------------------
|
||||
The allyesconfig/allmodconfig/allnoconfig/randconfig variants can
|
||||
also use the environment variable KCONFIG_ALLCONFIG as a flag or a
|
||||
filename that contains config symbols that the user requires to be
|
||||
set to a specific value. If KCONFIG_ALLCONFIG is used without a
|
||||
filename, "make *config" checks for a file named
|
||||
"all{yes/mod/no/random}.config" (corresponding to the *config command
|
||||
that was used) for symbol values that are to be forced. If this file
|
||||
is not found, it checks for a file named "all.config" to contain forced
|
||||
values.
|
||||
|
||||
This enables you to create "miniature" config (miniconfig) or custom
|
||||
config files containing just the config symbols that you are interested
|
||||
in. Then the kernel config system generates the full .config file,
|
||||
including dependencies of your miniconfig file, based on the miniconfig
|
||||
file.
|
||||
|
||||
This 'KCONFIG_ALLCONFIG' file is a config file which contains
|
||||
(usually a subset of all) preset config symbols. These variable
|
||||
settings are still subject to normal dependency checks.
|
||||
|
||||
Examples:
|
||||
KCONFIG_ALLCONFIG=custom-notebook.config make allnoconfig
|
||||
or
|
||||
KCONFIG_ALLCONFIG=mini.config make allnoconfig
|
||||
or
|
||||
make KCONFIG_ALLCONFIG=mini.config allnoconfig
|
||||
|
||||
These examples will disable most options (allnoconfig) but enable or
|
||||
disable the options that are explicitly listed in the specified
|
||||
mini-config files.
|
||||
|
||||
KCONFIG_NOSILENTUPDATE
|
||||
--------------------------------------------------
|
||||
If this variable has a non-blank value, it prevents silent kernel
|
||||
config udpates (requires explicit updates).
|
||||
|
||||
KCONFIG_CONFIG
|
||||
--------------------------------------------------
|
||||
This environment variable can be used to specify a default kernel config
|
||||
file name to override the default name of ".config".
|
||||
|
||||
KCONFIG_OVERWRITECONFIG
|
||||
--------------------------------------------------
|
||||
If you set KCONFIG_OVERWRITECONFIG in the environment, Kconfig will not
|
||||
break symlinks when .config is a symlink to somewhere else.
|
||||
|
||||
KCONFIG_NOTIMESTAMP
|
||||
--------------------------------------------------
|
||||
If this environment variable exists and is non-null, the timestamp line
|
||||
in generated .config files is omitted.
|
||||
|
||||
KCONFIG_AUTOCONFIG
|
||||
--------------------------------------------------
|
||||
This environment variable can be set to specify the path & name of the
|
||||
"auto.conf" file. Its default value is "include/config/auto.conf".
|
||||
|
||||
KCONFIG_AUTOHEADER
|
||||
--------------------------------------------------
|
||||
This environment variable can be set to specify the path & name of the
|
||||
"autoconf.h" (header) file. Its default value is "include/linux/autoconf.h".
|
||||
|
||||
______________________________________________________________________
|
||||
menuconfig User Interface Options
|
||||
----------------------------------------------------------------------
|
||||
MENUCONFIG_MODE
|
||||
--------------------------------------------------
|
||||
This mode shows all sub-menus in one large tree.
|
||||
|
||||
Example:
|
||||
MENUCONFIG_MODE=single_menu make menuconfig
|
||||
make MENUCONFIG_MODE=single_menu menuconfig
|
||||
|
||||
|
||||
======================================================================
|
||||
xconfig
|
||||
|
|
|
|||
|
|
@ -275,7 +275,7 @@ following files:
|
|||
|
||||
KERNELDIR := /lib/modules/`uname -r`/build
|
||||
all::
|
||||
$(MAKE) -C $KERNELDIR M=`pwd` $@
|
||||
$(MAKE) -C $(KERNELDIR) M=`pwd` $@
|
||||
|
||||
# Module specific targets
|
||||
genbin:
|
||||
|
|
|
|||
|
|
@ -108,7 +108,7 @@ There are two possible methods of using Kdump.
|
|||
|
||||
2) Or use the system kernel binary itself as dump-capture kernel and there is
|
||||
no need to build a separate dump-capture kernel. This is possible
|
||||
only with the architecutres which support a relocatable kernel. As
|
||||
only with the architectures which support a relocatable kernel. As
|
||||
of today, i386, x86_64, ppc64 and ia64 architectures support relocatable
|
||||
kernel.
|
||||
|
||||
|
|
@ -222,7 +222,7 @@ Dump-capture kernel config options (Arch Dependent, ia64)
|
|||
----------------------------------------------------------
|
||||
|
||||
- No specific options are required to create a dump-capture kernel
|
||||
for ia64, other than those specified in the arch idependent section
|
||||
for ia64, other than those specified in the arch independent section
|
||||
above. This means that it is possible to use the system kernel
|
||||
as a dump-capture kernel if desired.
|
||||
|
||||
|
|
|
|||
|
|
@ -887,11 +887,8 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
|
||||
ide-core.nodma= [HW] (E)IDE subsystem
|
||||
Format: =0.0 to prevent dma on hda, =0.1 hdb =1.0 hdc
|
||||
.vlb_clock .pci_clock .noflush .noprobe .nowerr .cdrom
|
||||
.chs .ignore_cable are additional options
|
||||
See Documentation/ide/ide.txt.
|
||||
|
||||
idebus= [HW] (E)IDE subsystem - VLB/PCI bus speed
|
||||
.vlb_clock .pci_clock .noflush .nohpa .noprobe .nowerr
|
||||
.cdrom .chs .ignore_cable are additional options
|
||||
See Documentation/ide/ide.txt.
|
||||
|
||||
ide-pci-generic.all-generic-ide [HW] (E)IDE subsystem
|
||||
|
|
@ -1076,7 +1073,7 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
|
||||
kgdboc= [HW] kgdb over consoles.
|
||||
Requires a tty driver that supports console polling.
|
||||
(only serial suported for now)
|
||||
(only serial supported for now)
|
||||
Format: <serial_device>[,baud]
|
||||
|
||||
kmac= [MIPS] korina ethernet MAC address.
|
||||
|
|
@ -1405,7 +1402,7 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
('y', default) or cooked coordinates ('n')
|
||||
|
||||
mtrr_chunk_size=nn[KMG] [X86]
|
||||
used for mtrr cleanup. It is largest continous chunk
|
||||
used for mtrr cleanup. It is largest continuous chunk
|
||||
that could hold holes aka. UC entries.
|
||||
|
||||
mtrr_gran_size=nn[KMG] [X86]
|
||||
|
|
|
|||
|
|
@ -132,7 +132,7 @@ kobject_name():
|
|||
const char *kobject_name(const struct kobject * kobj);
|
||||
|
||||
There is a helper function to both initialize and add the kobject to the
|
||||
kernel at the same time, called supprisingly enough kobject_init_and_add():
|
||||
kernel at the same time, called surprisingly enough kobject_init_and_add():
|
||||
|
||||
int kobject_init_and_add(struct kobject *kobj, struct kobj_type *ktype,
|
||||
struct kobject *parent, const char *fmt, ...);
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ NOTE: The Acer Aspire One is not supported hardware. It cannot work with
|
|||
acer-wmi until Acer fix their ACPI-WMI implementation on them, so has been
|
||||
blacklisted until that happens.
|
||||
|
||||
Please see the website for the current list of known working hardare:
|
||||
Please see the website for the current list of known working hardware:
|
||||
|
||||
http://code.google.com/p/aceracpi/wiki/SupportedHardware
|
||||
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ If your laptop model supports it, you will find sysfs files in the
|
|||
/sys/class/backlight/sony/
|
||||
directory. You will be able to query and set the current screen
|
||||
brightness:
|
||||
brightness get/set screen brightness (an iteger
|
||||
brightness get/set screen brightness (an integer
|
||||
between 0 and 7)
|
||||
actual_brightness reading from this file will query the HW
|
||||
to get real brightness value
|
||||
|
|
|
|||
|
|
@ -506,7 +506,7 @@ generate input device EV_KEY events.
|
|||
In addition to the EV_KEY events, thinkpad-acpi may also issue EV_SW
|
||||
events for switches:
|
||||
|
||||
SW_RFKILL_ALL T60 and later hardare rfkill rocker switch
|
||||
SW_RFKILL_ALL T60 and later hardware rfkill rocker switch
|
||||
SW_TABLET_MODE Tablet ThinkPads HKEY events 0x5009 and 0x500A
|
||||
|
||||
Non hot-key ACPI HKEY event map:
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
# This creates the demonstration utility "lguest" which runs a Linux guest.
|
||||
CFLAGS:=-Wall -Wmissing-declarations -Wmissing-prototypes -O3 -I../../include -I../../arch/x86/include -U_FORTIFY_SOURCE
|
||||
LDLIBS:=-lz
|
||||
CFLAGS:=-m32 -Wall -Wmissing-declarations -Wmissing-prototypes -O3 -I../../include -I../../arch/x86/include -U_FORTIFY_SOURCE
|
||||
|
||||
all: lguest
|
||||
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load Diff
|
|
@ -37,7 +37,6 @@ Running Lguest:
|
|||
"Paravirtualized guest support" = Y
|
||||
"Lguest guest support" = Y
|
||||
"High Memory Support" = off/4GB
|
||||
"PAE (Physical Address Extension) Support" = N
|
||||
"Alignment value to which kernel should be aligned" = 0x100000
|
||||
(CONFIG_PARAVIRT=y, CONFIG_LGUEST_GUEST=y, CONFIG_HIGHMEM64G=n and
|
||||
CONFIG_PHYSICAL_ALIGN=0x100000)
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ out of order wrt other memory writes by the owner CPU.
|
|||
|
||||
It can be done by slightly modifying the standard atomic operations : only
|
||||
their UP variant must be kept. It typically means removing LOCK prefix (on
|
||||
i386 and x86_64) and any SMP sychronization barrier. If the architecture does
|
||||
i386 and x86_64) and any SMP synchronization barrier. If the architecture does
|
||||
not have a different behavior between SMP and UP, including asm-generic/local.h
|
||||
in your architecture's local.h is sufficient.
|
||||
|
||||
|
|
|
|||
|
|
@ -73,13 +73,13 @@ this phase is triggered automatically. ACPI can notify this event. If not,
|
|||
(see Section 4.).
|
||||
|
||||
Logical Memory Hotplug phase is to change memory state into
|
||||
avaiable/unavailable for users. Amount of memory from user's view is
|
||||
available/unavailable for users. Amount of memory from user's view is
|
||||
changed by this phase. The kernel makes all memory in it as free pages
|
||||
when a memory range is available.
|
||||
|
||||
In this document, this phase is described as online/offline.
|
||||
|
||||
Logical Memory Hotplug phase is triggred by write of sysfs file by system
|
||||
Logical Memory Hotplug phase is triggered by write of sysfs file by system
|
||||
administrator. For the hot-add case, it must be executed after Physical Hotplug
|
||||
phase by hand.
|
||||
(However, if you writes udev's hotplug scripts for memory hotplug, these
|
||||
|
|
@ -334,7 +334,7 @@ MEMORY_CANCEL_ONLINE
|
|||
Generated if MEMORY_GOING_ONLINE fails.
|
||||
|
||||
MEMORY_ONLINE
|
||||
Generated when memory has succesfully brought online. The callback may
|
||||
Generated when memory has successfully brought online. The callback may
|
||||
allocate pages from the new memory.
|
||||
|
||||
MEMORY_GOING_OFFLINE
|
||||
|
|
@ -359,7 +359,7 @@ The third argument is passed by pointer of struct memory_notify.
|
|||
struct memory_notify {
|
||||
unsigned long start_pfn;
|
||||
unsigned long nr_pages;
|
||||
int status_cahnge_nid;
|
||||
int status_change_nid;
|
||||
}
|
||||
|
||||
start_pfn is start_pfn of online/offline memory.
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ registers and the stack. If the first argument is a 64-bit value, it will be
|
|||
passed in D0:D1. If the first argument is not a 64-bit value, but the second
|
||||
is, the second will be passed entirely on the stack and D1 will be unused.
|
||||
|
||||
Arguments smaller than 32-bits are not coelesced within a register or a stack
|
||||
Arguments smaller than 32-bits are not coalesced within a register or a stack
|
||||
word. For example, two byte-sized arguments will always be passed in separate
|
||||
registers or word-sized stack slots.
|
||||
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ byte 255: bit7 bit6 bit5 bit4 bit3 bit2 bit1 bit0 rp1 rp3 rp5 ... rp15
|
|||
cp5 cp5 cp5 cp5 cp4 cp4 cp4 cp4
|
||||
|
||||
This figure represents a sector of 256 bytes.
|
||||
cp is my abbreviaton for column parity, rp for row parity.
|
||||
cp is my abbreviation for column parity, rp for row parity.
|
||||
|
||||
Let's start to explain column parity.
|
||||
cp0 is the parity that belongs to all bit0, bit2, bit4, bit6.
|
||||
|
|
@ -560,7 +560,7 @@ Measuring this code again showed big gain. When executing the original
|
|||
linux code 1 million times, this took about 1 second on my system.
|
||||
(using time to measure the performance). After this iteration I was back
|
||||
to 0.075 sec. Actually I had to decide to start measuring over 10
|
||||
million interations in order not to loose too much accuracy. This one
|
||||
million iterations in order not to lose too much accuracy. This one
|
||||
definitely seemed to be the jackpot!
|
||||
|
||||
There is a little bit more room for improvement though. There are three
|
||||
|
|
@ -571,8 +571,8 @@ loop; This eliminates 3 statements per loop. Of course after the loop we
|
|||
need to correct by adding:
|
||||
rp4 ^= rp4_6;
|
||||
rp6 ^= rp4_6
|
||||
Furthermore there are 4 sequential assingments to rp8. This can be
|
||||
encoded slightly more efficient by saving tmppar before those 4 lines
|
||||
Furthermore there are 4 sequential assignments to rp8. This can be
|
||||
encoded slightly more efficiently by saving tmppar before those 4 lines
|
||||
and later do rp8 = rp8 ^ tmppar ^ notrp8;
|
||||
(where notrp8 is the value of rp8 before those 4 lines).
|
||||
Again a use of the commutative property of xor.
|
||||
|
|
@ -622,7 +622,7 @@ Not a big change, but every penny counts :-)
|
|||
Analysis 7
|
||||
==========
|
||||
|
||||
Acutally this made things worse. Not very much, but I don't want to move
|
||||
Actually this made things worse. Not very much, but I don't want to move
|
||||
into the wrong direction. Maybe something to investigate later. Could
|
||||
have to do with caching again.
|
||||
|
||||
|
|
@ -642,7 +642,7 @@ Analysis 8
|
|||
This makes things worse. Let's stick with attempt 6 and continue from there.
|
||||
Although it seems that the code within the loop cannot be optimised
|
||||
further there is still room to optimize the generation of the ecc codes.
|
||||
We can simply calcualate the total parity. If this is 0 then rp4 = rp5
|
||||
We can simply calculate the total parity. If this is 0 then rp4 = rp5
|
||||
etc. If the parity is 1, then rp4 = !rp5;
|
||||
But if rp4 = rp5 we do not need rp5 etc. We can just write the even bits
|
||||
in the result byte and then do something like
|
||||
|
|
|
|||
|
|
@ -221,7 +221,7 @@ ad_select
|
|||
|
||||
- Any slave's 802.3ad association state changes
|
||||
|
||||
- The bond's adminstrative state changes to up
|
||||
- The bond's administrative state changes to up
|
||||
|
||||
count or 2
|
||||
|
||||
|
|
@ -369,7 +369,7 @@ fail_over_mac
|
|||
When this policy is used in conjuction with the mii
|
||||
monitor, devices which assert link up prior to being
|
||||
able to actually transmit and receive are particularly
|
||||
susecptible to loss of the gratuitous ARP, and an
|
||||
susceptible to loss of the gratuitous ARP, and an
|
||||
appropriate updelay setting may be required.
|
||||
|
||||
follow or 2
|
||||
|
|
@ -1794,7 +1794,7 @@ target to query.
|
|||
generally referred to as "trunk failover." This is a feature of the
|
||||
switch that causes the link state of a particular switch port to be set
|
||||
down (or up) when the state of another switch port goes down (or up).
|
||||
It's purpose is to propogate link failures from logically "exterior" ports
|
||||
Its purpose is to propagate link failures from logically "exterior" ports
|
||||
to the logically "interior" ports that bonding is able to monitor via
|
||||
miimon. Availability and configuration for trunk failover varies by
|
||||
switch, but this can be a viable alternative to the ARP monitor when using
|
||||
|
|
|
|||
|
|
@ -327,7 +327,7 @@ solution for a couple of reasons:
|
|||
return 1;
|
||||
}
|
||||
|
||||
/* paraniod check ... */
|
||||
/* paranoid check ... */
|
||||
if (nbytes < sizeof(struct can_frame)) {
|
||||
fprintf(stderr, "read: incomplete CAN frame\n");
|
||||
return 1;
|
||||
|
|
|
|||
|
|
@ -129,7 +129,7 @@ PHY Link state polling
|
|||
----------------------
|
||||
|
||||
The driver keeps track of the link state and informs the network core
|
||||
about link (carrier) availablilty. This is managed by several methods
|
||||
about link (carrier) availability. This is managed by several methods
|
||||
depending on the version of the chip and on which PHY is being used.
|
||||
|
||||
For the internal PHY, the original (and currently default) method is
|
||||
|
|
|
|||
|
|
@ -158,7 +158,7 @@ Sample Userspace Code
|
|||
}
|
||||
return 0;
|
||||
|
||||
Miscellanous
|
||||
Miscellaneous
|
||||
============
|
||||
|
||||
The PPPoL2TP driver was developed as part of the OpenL2TP project by
|
||||
|
|
|
|||
|
|
@ -74,7 +74,7 @@ dev->hard_start_xmit:
|
|||
for this and return NETDEV_TX_LOCKED when the spin lock fails.
|
||||
The locking there should also properly protect against
|
||||
set_multicast_list. Note that the use of NETIF_F_LLTX is deprecated.
|
||||
Dont use it for new drivers.
|
||||
Don't use it for new drivers.
|
||||
|
||||
Context: Process with BHs disabled or BH (timer),
|
||||
will be called with interrupts disabled by netconsole.
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ Phonet packets have a common header as follows:
|
|||
On Linux, the link-layer header includes the pn_media byte (see below).
|
||||
The next 7 bytes are part of the network-layer header.
|
||||
|
||||
The device ID is split: the 6 higher-order bits consitute the device
|
||||
The device ID is split: the 6 higher-order bits constitute the device
|
||||
address, while the 2 lower-order bits are used for multiplexing, as are
|
||||
the 8-bit object identifiers. As such, Phonet can be considered as a
|
||||
network layer with 6 bits of address space and 10 bits for transport
|
||||
|
|
|
|||
|
|
@ -89,7 +89,7 @@ added to this document when its support is enabled.
|
|||
Device drivers who provide their own built regulatory domain
|
||||
do not need a callback as the channels registered by them are
|
||||
the only ones that will be allowed and therefore *additional*
|
||||
cannels cannot be enabled.
|
||||
channels cannot be enabled.
|
||||
|
||||
Example code - drivers hinting an alpha2:
|
||||
------------------------------------------
|
||||
|
|
|
|||
|
|
@ -75,9 +75,6 @@ may need to apply in domain-specific ways to their devices:
|
|||
struct bus_type {
|
||||
...
|
||||
int (*suspend)(struct device *dev, pm_message_t state);
|
||||
int (*suspend_late)(struct device *dev, pm_message_t state);
|
||||
|
||||
int (*resume_early)(struct device *dev);
|
||||
int (*resume)(struct device *dev);
|
||||
};
|
||||
|
||||
|
|
@ -226,20 +223,7 @@ The phases are seen by driver notifications issued in this order:
|
|||
|
||||
This call should handle parts of device suspend logic that require
|
||||
sleeping. It probably does work to quiesce the device which hasn't
|
||||
been abstracted into class.suspend() or bus.suspend_late().
|
||||
|
||||
3 bus.suspend_late(dev, message) is called with IRQs disabled, and
|
||||
with only one CPU active. Until the bus.resume_early() phase
|
||||
completes (see later), IRQs are not enabled again. This method
|
||||
won't be exposed by all busses; for message based busses like USB,
|
||||
I2C, or SPI, device interactions normally require IRQs. This bus
|
||||
call may be morphed into a driver call with bus-specific parameters.
|
||||
|
||||
This call might save low level hardware state that might otherwise
|
||||
be lost in the upcoming low power state, and actually put the
|
||||
device into a low power state ... so that in some cases the device
|
||||
may stay partly usable until this late. This "late" call may also
|
||||
help when coping with hardware that behaves badly.
|
||||
been abstracted into class.suspend().
|
||||
|
||||
The pm_message_t parameter is currently used to refine those semantics
|
||||
(described later).
|
||||
|
|
@ -351,19 +335,11 @@ devices processing each phase's calls before the next phase begins.
|
|||
|
||||
The phases are seen by driver notifications issued in this order:
|
||||
|
||||
1 bus.resume_early(dev) is called with IRQs disabled, and with
|
||||
only one CPU active. As with bus.suspend_late(), this method
|
||||
won't be supported on busses that require IRQs in order to
|
||||
interact with devices.
|
||||
1 bus.resume(dev) reverses the effects of bus.suspend(). This may
|
||||
be morphed into a device driver call with bus-specific parameters;
|
||||
implementations may sleep.
|
||||
|
||||
This reverses the effects of bus.suspend_late().
|
||||
|
||||
2 bus.resume(dev) is called next. This may be morphed into a device
|
||||
driver call with bus-specific parameters; implementations may sleep.
|
||||
|
||||
This reverses the effects of bus.suspend().
|
||||
|
||||
3 class.resume(dev) is called for devices associated with a class
|
||||
2 class.resume(dev) is called for devices associated with a class
|
||||
that has such a method. Implementations may sleep.
|
||||
|
||||
This reverses the effects of class.suspend(), and would usually
|
||||
|
|
|
|||
|
|
@ -178,5 +178,5 @@ Consumers can uregister interest by calling :-
|
|||
int regulator_unregister_notifier(struct regulator *regulator,
|
||||
struct notifier_block *nb);
|
||||
|
||||
Regulators use the kernel notifier framework to send event to thier interested
|
||||
Regulators use the kernel notifier framework to send event to their interested
|
||||
consumers.
|
||||
|
|
|
|||
|
|
@ -119,7 +119,7 @@ Some terms used in this document:-
|
|||
battery power, USB power)
|
||||
|
||||
Regulator Domains: is the new current limit within the
|
||||
regulator operating parameters for input/ouput voltage.
|
||||
regulator operating parameters for input/output voltage.
|
||||
|
||||
If the regulator request passes all the constraint tests
|
||||
then the new regulator value is applied.
|
||||
|
|
|
|||
|
|
@ -63,7 +63,7 @@ hardware during resume operations where a value can be set that will
|
|||
survive a reboot.
|
||||
|
||||
Consequence is that after a resume (even if it is successful) your system
|
||||
clock will have a value corresponding to the magic mumber instead of the
|
||||
clock will have a value corresponding to the magic number instead of the
|
||||
correct date/time! It is therefore advisable to use a program like ntp-date
|
||||
or rdate to reset the correct date/time from an external time source when
|
||||
using this trace option.
|
||||
|
|
|
|||
|
|
@ -109,7 +109,7 @@ unfreeze user space processes frozen by SNAPSHOT_UNFREEZE if they are
|
|||
still frozen when the device is being closed).
|
||||
|
||||
Currently it is assumed that the userland utilities reading/writing the
|
||||
snapshot image from/to the kernel will use a swap parition, called the resume
|
||||
snapshot image from/to the kernel will use a swap partition, called the resume
|
||||
partition, or a swap file as storage space (if a swap file is used, the resume
|
||||
partition is the partition that holds this file). However, this is not really
|
||||
required, as they can use, for example, a special (blank) suspend partition or
|
||||
|
|
|
|||
|
|
@ -1356,7 +1356,7 @@ platforms are moved over to use the flattened-device-tree model.
|
|||
- phy-map : 1 cell, optional, bitmap of addresses to probe the PHY
|
||||
for, used if phy-address is absent. bit 0x00000001 is
|
||||
MDIO address 0.
|
||||
For Axon it can be absent, thouugh my current driver
|
||||
For Axon it can be absent, though my current driver
|
||||
doesn't handle phy-address yet so for now, keep
|
||||
0x00ffffff in it.
|
||||
- rx-fifo-size-gige : 1 cell, Rx fifo size in bytes for 1000 Mb/sec
|
||||
|
|
@ -1438,7 +1438,7 @@ platforms are moved over to use the flattened-device-tree model.
|
|||
|
||||
The Xilinx EDK toolchain ships with a set of IP cores (devices) for use
|
||||
in Xilinx Spartan and Virtex FPGAs. The devices cover the whole range
|
||||
of standard device types (network, serial, etc.) and miscellanious
|
||||
of standard device types (network, serial, etc.) and miscellaneous
|
||||
devices (gpio, LCD, spi, etc). Also, since these devices are
|
||||
implemented within the fpga fabric every instance of the device can be
|
||||
synthesised with different options that change the behaviour.
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ Required properities:
|
|||
- reg : Should contain the address and the length of the GPIO bank
|
||||
register.
|
||||
- #gpio-cells : Should be two. The first cell is the pin number and the
|
||||
second cell is used to specify optional paramters (currently unused).
|
||||
second cell is used to specify optional parameters (currently unused).
|
||||
- gpio-controller : Marks the port as GPIO controller.
|
||||
|
||||
Example:
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ Example:
|
|||
reg = <119c0 30>;
|
||||
}
|
||||
|
||||
* Properties common to mulitple CPM/QE devices
|
||||
* Properties common to multiple CPM/QE devices
|
||||
|
||||
- fsl,cpm-command : This value is ORed with the opcode and command flag
|
||||
to specify the device on which a CPM command operates.
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ Required properties:
|
|||
"fsl,cpm1-pario-bank-c", "fsl,cpm1-pario-bank-d",
|
||||
"fsl,cpm1-pario-bank-e", "fsl,cpm2-pario-bank"
|
||||
- #gpio-cells : Should be two. The first cell is the pin number and the
|
||||
second cell is used to specify optional paramters (currently unused).
|
||||
second cell is used to specify optional parameters (currently unused).
|
||||
- gpio-controller : Marks the port as GPIO controller.
|
||||
|
||||
Example of three SOC GPIO banks defined as gpio-controller nodes:
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
* Freescale MSI interrupt controller
|
||||
|
||||
Reguired properities:
|
||||
Required properties:
|
||||
- compatible : compatible list, contains 2 entries,
|
||||
first is "fsl,CHIP-msi", where CHIP is the processor(mpc8610, mpc8572,
|
||||
etc.) and the second is "fsl,mpic-msi" or "fsl,ipic-msi" depending on
|
||||
|
|
|
|||
|
|
@ -15,8 +15,8 @@ Properties:
|
|||
compatible; all statements below that apply to "fsl,mpc8548-pmc" also
|
||||
apply to "fsl,mpc8641d-pmc".
|
||||
|
||||
Compatibility does not include bit assigments in SCCR/PMCDR/DEVDISR; these
|
||||
bit assigments are indicated via the sleep specifier in each device's
|
||||
Compatibility does not include bit assignments in SCCR/PMCDR/DEVDISR; these
|
||||
bit assignments are indicated via the sleep specifier in each device's
|
||||
sleep property.
|
||||
|
||||
- reg: For devices compatible with "fsl,mpc8349-pmc", the first resource
|
||||
|
|
|
|||
|
|
@ -225,7 +225,7 @@ For example, to match the 8323, revision 1.0:
|
|||
soc.major = 1
|
||||
soc.minor = 0
|
||||
|
||||
'padding' is neccessary for structure alignment. This field ensures that the
|
||||
'padding' is necessary for structure alignment. This field ensures that the
|
||||
'extended_modes' field is aligned on a 64-bit boundary.
|
||||
|
||||
'extended_modes' is a bitfield that defines special functionality which has an
|
||||
|
|
|
|||
|
|
@ -131,8 +131,8 @@ Example:
|
|||
}
|
||||
|
||||
/* Add new node and rebalance tree. */
|
||||
rb_link_node(data->node, parent, new);
|
||||
rb_insert_color(data->node, root);
|
||||
rb_link_node(&data->node, parent, new);
|
||||
rb_insert_color(&data->node, root);
|
||||
|
||||
return TRUE;
|
||||
}
|
||||
|
|
@ -146,10 +146,10 @@ To remove an existing node from a tree, call:
|
|||
|
||||
Example:
|
||||
|
||||
struct mytype *data = mysearch(mytree, "walrus");
|
||||
struct mytype *data = mysearch(&mytree, "walrus");
|
||||
|
||||
if (data) {
|
||||
rb_erase(data->node, mytree);
|
||||
rb_erase(&data->node, &mytree);
|
||||
myfree(data);
|
||||
}
|
||||
|
||||
|
|
@ -188,5 +188,5 @@ Example:
|
|||
|
||||
struct rb_node *node;
|
||||
for (node = rb_first(&mytree); node; node = rb_next(node))
|
||||
printk("key=%s\n", rb_entry(node, int, keystring));
|
||||
printk("key=%s\n", rb_entry(node, struct mytype, node)->keystring);
|
||||
|
||||
|
|
|
|||
|
|
@ -1984,7 +1984,7 @@ break *$pc
|
|||
|
||||
break *0x400618
|
||||
|
||||
heres a really useful one for large programs
|
||||
Here's a really useful one for large programs
|
||||
rbr
|
||||
Set a breakpoint for all functions matching REGEXP
|
||||
e.g.
|
||||
|
|
@ -2211,7 +2211,7 @@ Breakpoint 2 at 0x4d87a4: file top.c, line 2609.
|
|||
#5 0x51692c in readline_internal () at readline.c:521
|
||||
#6 0x5164fe in readline (prompt=0x7ffff810 "\177ÿøx\177ÿ÷Ø\177ÿøxÀ")
|
||||
at readline.c:349
|
||||
#7 0x4d7a8a in command_line_input (prrompt=0x564420 "(gdb) ", repeat=1,
|
||||
#7 0x4d7a8a in command_line_input (prompt=0x564420 "(gdb) ", repeat=1,
|
||||
annotation_suffix=0x4d6b44 "prompt") at top.c:2091
|
||||
#8 0x4d6cf0 in command_loop () at top.c:1345
|
||||
#9 0x4e25bc in main (argc=1, argv=0x7ffffdf4) at main.c:635
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ To sum it up: we always wanted to make nice levels more consistent, but
|
|||
within the constraints of HZ and jiffies and their nasty design level
|
||||
coupling to timeslices and granularity it was not really viable.
|
||||
|
||||
The second (less frequent but still periodically occuring) complaint
|
||||
The second (less frequent but still periodically occurring) complaint
|
||||
about Linux's nice level support was its assymetry around the origo
|
||||
(which you can see demonstrated in the picture above), or more
|
||||
accurately: the fact that nice level behavior depended on the _absolute_
|
||||
|
|
|
|||
|
|
@ -194,7 +194,7 @@ The following information is available in this file:
|
|||
- Packetized SCSI Protocol at 160MB/s and 320MB/s
|
||||
- Quick Arbitration Selection (QAS)
|
||||
- Retained Training Information (Rev B. ASIC only)
|
||||
- Interrupt Coalessing
|
||||
- Interrupt Coalescing
|
||||
- Initiator Mode (target mode not currently
|
||||
supported)
|
||||
- Support for the PCI-X standard up to 133MHz
|
||||
|
|
|
|||
|
|
@ -206,7 +206,7 @@ of MOVE MEMORY instructions.
|
|||
The 896 and the 895A allows handling of the phase mismatch context from
|
||||
SCRIPTS (avoids the phase mismatch interrupt that stops the SCSI processor
|
||||
until the C code has saved the context of the transfer).
|
||||
Implementing this without using LOAD/STORE instructions would be painfull
|
||||
Implementing this without using LOAD/STORE instructions would be painful
|
||||
and I didn't even want to try it.
|
||||
|
||||
The 896 chip supports 64 bit PCI transactions and addressing, while the
|
||||
|
|
@ -240,7 +240,7 @@ characteristics. This feature may also reduce average command latency.
|
|||
In order to really gain advantage of this feature, devices must have
|
||||
a reasonable cache size (No miracle is to be expected for a low-end
|
||||
hard disk with 128 KB or less).
|
||||
Some kown SCSI devices do not properly support tagged command queuing.
|
||||
Some known SCSI devices do not properly support tagged command queuing.
|
||||
Generally, firmware revisions that fix this kind of problems are available
|
||||
at respective vendor web/ftp sites.
|
||||
All I can say is that the hard disks I use on my machines behave well with
|
||||
|
|
|
|||
|
|
@ -206,7 +206,7 @@ characteristics. This feature may also reduce average command latency.
|
|||
In order to really gain advantage of this feature, devices must have
|
||||
a reasonable cache size (No miracle is to be expected for a low-end
|
||||
hard disk with 128 KB or less).
|
||||
Some kown old SCSI devices do not properly support tagged command queuing.
|
||||
Some known old SCSI devices do not properly support tagged command queuing.
|
||||
Generally, firmware revisions that fix this kind of problems are available
|
||||
at respective vendor web/ftp sites.
|
||||
All I can say is that I never have had problem with tagged queuing using
|
||||
|
|
|
|||
|
|
@ -460,6 +460,25 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
|
||||
The power-management is supported.
|
||||
|
||||
Module snd-ctxfi
|
||||
----------------
|
||||
|
||||
Module for Creative Sound Blaster X-Fi boards (20k1 / 20k2 chips)
|
||||
* Creative Sound Blaster X-Fi Titanium Fatal1ty Champion Series
|
||||
* Creative Sound Blaster X-Fi Titanium Fatal1ty Professional Series
|
||||
* Creative Sound Blaster X-Fi Titanium Professional Audio
|
||||
* Creative Sound Blaster X-Fi Titanium
|
||||
* Creative Sound Blaster X-Fi Elite Pro
|
||||
* Creative Sound Blaster X-Fi Platinum
|
||||
* Creative Sound Blaster X-Fi Fatal1ty
|
||||
* Creative Sound Blaster X-Fi XtremeGamer
|
||||
* Creative Sound Blaster X-Fi XtremeMusic
|
||||
|
||||
reference_rate - reference sample rate, 44100 or 48000 (default)
|
||||
multiple - multiple to ref. sample rate, 1 or 2 (default)
|
||||
|
||||
This module supports multiple cards.
|
||||
|
||||
Module snd-darla20
|
||||
------------------
|
||||
|
||||
|
|
@ -754,7 +773,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
single_cmd - Use single immediate commands to communicate with
|
||||
codecs (for debugging only)
|
||||
enable_msi - Enable Message Signaled Interrupt (MSI) (default = off)
|
||||
power_save - Automatic power-saving timtout (in second, 0 =
|
||||
power_save - Automatic power-saving timeout (in second, 0 =
|
||||
disable)
|
||||
power_save_controller - Reset HD-audio controller in power-saving mode
|
||||
(default = on)
|
||||
|
|
@ -925,6 +944,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
* Onkyo SE-90PCI
|
||||
* Onkyo SE-200PCI
|
||||
* ESI Juli@
|
||||
* ESI Maya44
|
||||
* Hercules Fortissimo IV
|
||||
* EGO-SYS WaveTerminal 192M
|
||||
|
||||
|
|
@ -933,7 +953,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
prodigy71xt, prodigy71hifi, prodigyhd2, prodigy192,
|
||||
juli, aureon51, aureon71, universe, ap192, k8x800,
|
||||
phase22, phase28, ms300, av710, se200pci, se90pci,
|
||||
fortissimo4, sn25p, WT192M
|
||||
fortissimo4, sn25p, WT192M, maya44
|
||||
|
||||
This module supports multiple cards and autoprobe.
|
||||
|
||||
|
|
@ -1093,6 +1113,13 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
This module supports multiple cards.
|
||||
The driver requires the firmware loader support on kernel.
|
||||
|
||||
Module snd-lx6464es
|
||||
-------------------
|
||||
|
||||
Module for Digigram LX6464ES boards
|
||||
|
||||
This module supports multiple cards.
|
||||
|
||||
Module snd-maestro3
|
||||
-------------------
|
||||
|
||||
|
|
@ -1543,13 +1570,15 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
Module snd-sc6000
|
||||
-----------------
|
||||
|
||||
Module for Gallant SC-6000 soundcard.
|
||||
Module for Gallant SC-6000 soundcard and later models: SC-6600
|
||||
and SC-7000.
|
||||
|
||||
port - Port # (0x220 or 0x240)
|
||||
mss_port - MSS Port # (0x530 or 0xe80)
|
||||
irq - IRQ # (5,7,9,10,11)
|
||||
mpu_irq - MPU-401 IRQ # (5,7,9,10) ,0 - no MPU-401 irq
|
||||
dma - DMA # (1,3,0)
|
||||
joystick - Enable gameport - 0 = disable (default), 1 = enable
|
||||
|
||||
This module supports multiple cards.
|
||||
|
||||
|
|
@ -1859,7 +1888,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
-------------------
|
||||
|
||||
Module for sound cards based on the Asus AV100/AV200 chips,
|
||||
i.e., Xonar D1, DX, D2, D2X, HDAV1.3 (Deluxe), and Essence STX.
|
||||
i.e., Xonar D1, DX, D2, D2X, HDAV1.3 (Deluxe), Essence ST
|
||||
(Deluxe) and Essence STX.
|
||||
|
||||
This module supports autoprobe and multiple cards.
|
||||
|
||||
|
|
|
|||
|
|
@ -36,6 +36,7 @@ ALC260
|
|||
acer Acer TravelMate
|
||||
will Will laptops (PB V7900)
|
||||
replacer Replacer 672V
|
||||
favorit100 Maxdata Favorit 100XS
|
||||
basic fixed pin assignment (old default model)
|
||||
test for testing/debugging purpose, almost all controls can
|
||||
adjusted. Appearing only when compiled with
|
||||
|
|
@ -85,10 +86,11 @@ ALC269
|
|||
eeepc-p703 ASUS Eeepc P703 P900A
|
||||
eeepc-p901 ASUS Eeepc P901 S101
|
||||
fujitsu FSC Amilo
|
||||
lifebook Fujitsu Lifebook S6420
|
||||
auto auto-config reading BIOS (default)
|
||||
|
||||
ALC662/663
|
||||
==========
|
||||
ALC662/663/272
|
||||
==============
|
||||
3stack-dig 3-stack (2-channel) with SPDIF
|
||||
3stack-6ch 3-stack (6-channel)
|
||||
3stack-6ch-dig 3-stack (6-channel) with SPDIF
|
||||
|
|
@ -107,6 +109,9 @@ ALC662/663
|
|||
asus-mode4 ASUS
|
||||
asus-mode5 ASUS
|
||||
asus-mode6 ASUS
|
||||
dell Dell with ALC272
|
||||
dell-zm1 Dell ZM1 with ALC272
|
||||
samsung-nc10 Samsung NC10 mini notebook
|
||||
auto auto-config reading BIOS (default)
|
||||
|
||||
ALC882/885
|
||||
|
|
@ -118,6 +123,7 @@ ALC882/885
|
|||
asus-a7j ASUS A7J
|
||||
asus-a7m ASUS A7M
|
||||
macpro MacPro support
|
||||
mb5 Macbook 5,1
|
||||
mbp3 Macbook Pro rev3
|
||||
imac24 iMac 24'' with jack detection
|
||||
w2jc ASUS W2JC
|
||||
|
|
@ -133,10 +139,12 @@ ALC883/888
|
|||
acer Acer laptops (Travelmate 3012WTMi, Aspire 5600, etc)
|
||||
acer-aspire Acer Aspire 9810
|
||||
acer-aspire-4930g Acer Aspire 4930G
|
||||
acer-aspire-8930g Acer Aspire 8930G
|
||||
medion Medion Laptops
|
||||
medion-md2 Medion MD2
|
||||
targa-dig Targa/MSI
|
||||
targa-2ch-dig Targs/MSI with 2-channel
|
||||
targa-2ch-dig Targa/MSI with 2-channel
|
||||
targa-8ch-dig Targa/MSI with 8-channel (MSI GX620)
|
||||
laptop-eapd 3-jack with SPDIF I/O and EAPD (Clevo M540JE, M550JE)
|
||||
lenovo-101e Lenovo 101E
|
||||
lenovo-nb0763 Lenovo NB0763
|
||||
|
|
@ -150,6 +158,9 @@ ALC883/888
|
|||
fujitsu-pi2515 Fujitsu AMILO Pi2515
|
||||
fujitsu-xa3530 Fujitsu AMILO XA3530
|
||||
3stack-6ch-intel Intel DG33* boards
|
||||
asus-p5q ASUS P5Q-EM boards
|
||||
mb31 MacBook 3,1
|
||||
sony-vaio-tt Sony VAIO TT
|
||||
auto auto-config reading BIOS (default)
|
||||
|
||||
ALC861/660
|
||||
|
|
@ -348,6 +359,7 @@ STAC92HD71B*
|
|||
hp-m4 HP mini 1000
|
||||
hp-dv5 HP dv series
|
||||
hp-hdx HP HDX series
|
||||
hp-dv4-1222nr HP dv4-1222nr (with LED support)
|
||||
auto BIOS setup (default)
|
||||
|
||||
STAC92HD73*
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ methods for the HD-audio hardware.
|
|||
The HD-audio component consists of two parts: the controller chip and
|
||||
the codec chips on the HD-audio bus. Linux provides a single driver
|
||||
for all controllers, snd-hda-intel. Although the driver name contains
|
||||
a word of a well-known harware vendor, it's not specific to it but for
|
||||
a word of a well-known hardware vendor, it's not specific to it but for
|
||||
all controller chips by other companies. Since the HD-audio
|
||||
controllers are supposed to be compatible, the single snd-hda-driver
|
||||
should work in most cases. But, not surprisingly, there are known
|
||||
|
|
|
|||
|
|
@ -88,26 +88,34 @@ card*/pcm*/info
|
|||
substreams, etc.
|
||||
|
||||
card*/pcm*/xrun_debug
|
||||
This file appears when CONFIG_SND_DEBUG=y.
|
||||
This shows the status of xrun (= buffer overrun/xrun) debug of
|
||||
ALSA PCM middle layer, as an integer from 0 to 2. The value
|
||||
can be changed by writing to this file, such as
|
||||
This file appears when CONFIG_SND_DEBUG=y and
|
||||
CONFIG_PCM_XRUN_DEBUG=y.
|
||||
This shows the status of xrun (= buffer overrun/xrun) and
|
||||
invalid PCM position debug/check of ALSA PCM middle layer.
|
||||
It takes an integer value, can be changed by writing to this
|
||||
file, such as
|
||||
|
||||
# cat 2 > /proc/asound/card0/pcm0p/xrun_debug
|
||||
# cat 5 > /proc/asound/card0/pcm0p/xrun_debug
|
||||
|
||||
When this value is greater than 0, the driver will show the
|
||||
messages to kernel log when an xrun is detected. The debug
|
||||
message is shown also when the invalid H/W pointer is detected
|
||||
at the update of periods (usually called from the interrupt
|
||||
The value consists of the following bit flags:
|
||||
bit 0 = Enable XRUN/jiffies debug messages
|
||||
bit 1 = Show stack trace at XRUN / jiffies check
|
||||
bit 2 = Enable additional jiffies check
|
||||
|
||||
When the bit 0 is set, the driver will show the messages to
|
||||
kernel log when an xrun is detected. The debug message is
|
||||
shown also when the invalid H/W pointer is detected at the
|
||||
update of periods (usually called from the interrupt
|
||||
handler).
|
||||
|
||||
When this value is greater than 1, the driver will show the
|
||||
stack trace additionally. This may help the debugging.
|
||||
When the bit 1 is set, the driver will show the stack trace
|
||||
additionally. This may help the debugging.
|
||||
|
||||
Since 2.6.30, this option also enables the hwptr check using
|
||||
Since 2.6.30, this option can enable the hwptr check using
|
||||
jiffies. This detects spontaneous invalid pointer callback
|
||||
values, but can be lead to too much corrections for a (mostly
|
||||
buggy) hardware that doesn't give smooth pointer updates.
|
||||
This feature is enabled via the bit 2.
|
||||
|
||||
card*/pcm*/sub*/info
|
||||
The general information of this PCM sub-stream.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,163 @@
|
|||
NOTE: The following is the original document of Rainer's patch that the
|
||||
current maya44 code based on. Some contents might be obsoleted, but I
|
||||
keep here as reference -- tiwai
|
||||
|
||||
----------------------------------------------------------------
|
||||
|
||||
STATE OF DEVELOPMENT:
|
||||
|
||||
This driver is being developed on the initiative of Piotr Makowski (oponek@gmail.com) and financed by Lars Bergmann.
|
||||
Development is carried out by Rainer Zimmermann (mail@lightshed.de).
|
||||
|
||||
ESI provided a sample Maya44 card for the development work.
|
||||
|
||||
However, unfortunately it has turned out difficult to get detailed programming information, so I (Rainer Zimmermann) had to find out some card-specific information by experiment and conjecture. Some information (in particular, several GPIO bits) is still missing.
|
||||
|
||||
This is the first testing version of the Maya44 driver released to the alsa-devel mailing list (Feb 5, 2008).
|
||||
|
||||
|
||||
The following functions work, as tested by Rainer Zimmermann and Piotr Makowski:
|
||||
|
||||
- playback and capture at all sampling rates
|
||||
- input/output level
|
||||
- crossmixing
|
||||
- line/mic switch
|
||||
- phantom power switch
|
||||
- analogue monitor a.k.a bypass
|
||||
|
||||
|
||||
The following functions *should* work, but are not fully tested:
|
||||
|
||||
- Channel 3+4 analogue - S/PDIF input switching
|
||||
- S/PDIF output
|
||||
- all inputs/outputs on the M/IO/DIO extension card
|
||||
- internal/external clock selection
|
||||
|
||||
|
||||
*In particular, we would appreciate testing of these functions by anyone who has access to an M/IO/DIO extension card.*
|
||||
|
||||
|
||||
Things that do not seem to work:
|
||||
|
||||
- The level meters ("multi track") in 'alsamixer' do not seem to react to signals in (if this is a bug, it would probably be in the existing ICE1724 code).
|
||||
|
||||
- Ardour 2.1 seems to work only via JACK, not using ALSA directly or via OSS. This still needs to be tracked down.
|
||||
|
||||
|
||||
DRIVER DETAILS:
|
||||
|
||||
the following files were added:
|
||||
|
||||
pci/ice1724/maya44.c - Maya44 specific code
|
||||
pci/ice1724/maya44.h
|
||||
pci/ice1724/ice1724.patch
|
||||
pci/ice1724/ice1724.h.patch - PROPOSED patch to ice1724.h (see SAMPLING RATES)
|
||||
i2c/other/wm8776.c - low-level access routines for Wolfson WM8776 codecs
|
||||
include/wm8776.h
|
||||
|
||||
|
||||
Note that the wm8776.c code is meant to be card-independent and does not actually register the codec with the ALSA infrastructure.
|
||||
This is done in maya44.c, mainly because some of the WM8776 controls are used in Maya44-specific ways, and should be named appropriately.
|
||||
|
||||
|
||||
the following files were created in pci/ice1724, simply #including the corresponding file from the alsa-kernel tree:
|
||||
|
||||
wtm.h
|
||||
vt1720_mobo.h
|
||||
revo.h
|
||||
prodigy192.h
|
||||
pontis.h
|
||||
phase.h
|
||||
maya44.h
|
||||
juli.h
|
||||
aureon.h
|
||||
amp.h
|
||||
envy24ht.h
|
||||
se.h
|
||||
prodigy_hifi.h
|
||||
|
||||
|
||||
*I hope this is the correct way to do things.*
|
||||
|
||||
|
||||
SAMPLING RATES:
|
||||
|
||||
The Maya44 card (or more exactly, the Wolfson WM8776 codecs) allow a maximum sampling rate of 192 kHz for playback and 92 kHz for capture.
|
||||
|
||||
As the ICE1724 chip only allows one global sampling rate, this is handled as follows:
|
||||
|
||||
* setting the sampling rate on any open PCM device on the maya44 card will always set the *global* sampling rate for all playback and capture channels.
|
||||
|
||||
* In the current state of the driver, setting rates of up to 192 kHz is permitted even for capture devices.
|
||||
|
||||
*AVOID CAPTURING AT RATES ABOVE 96kHz*, even though it may appear to work. The codec cannot actually capture at such rates, meaning poor quality.
|
||||
|
||||
|
||||
I propose some additional code for limiting the sampling rate when setting on a capture pcm device. However because of the global sampling rate, this logic would be somewhat problematic.
|
||||
|
||||
The proposed code (currently deactivated) is in ice1712.h.patch, ice1724.c and maya44.c (in pci/ice1712).
|
||||
|
||||
|
||||
SOUND DEVICES:
|
||||
|
||||
PCM devices correspond to inputs/outputs as follows (assuming Maya44 is card #0):
|
||||
|
||||
hw:0,0 input - stereo, analog input 1+2
|
||||
hw:0,0 output - stereo, analog output 1+2
|
||||
hw:0,1 input - stereo, analog input 3+4 OR S/PDIF input
|
||||
hw:0,1 output - stereo, analog output 3+4 (and SPDIF out)
|
||||
|
||||
|
||||
NAMING OF MIXER CONTROLS:
|
||||
|
||||
(for more information about the signal flow, please refer to the block diagram on p.24 of the ESI Maya44 manual, or in the ESI windows software).
|
||||
|
||||
|
||||
PCM: (digital) output level for channel 1+2
|
||||
PCM 1: same for channel 3+4
|
||||
|
||||
Mic Phantom+48V: switch for +48V phantom power for electrostatic microphones on input 1/2.
|
||||
Make sure this is not turned on while any other source is connected to input 1/2.
|
||||
It might damage the source and/or the maya44 card.
|
||||
|
||||
Mic/Line input: if switch is is on, input jack 1/2 is microphone input (mono), otherwise line input (stereo).
|
||||
|
||||
Bypass: analogue bypass from ADC input to output for channel 1+2. Same as "Monitor" in the windows driver.
|
||||
Bypass 1: same for channel 3+4.
|
||||
|
||||
Crossmix: cross-mixer from channels 1+2 to channels 3+4
|
||||
Crossmix 1: cross-mixer from channels 3+4 to channels 1+2
|
||||
|
||||
IEC958 Output: switch for S/PDIF output.
|
||||
This is not supported by the ESI windows driver.
|
||||
S/PDIF should output the same signal as channel 3+4. [untested!]
|
||||
|
||||
|
||||
Digitial output selectors:
|
||||
|
||||
These switches allow a direct digital routing from the ADCs to the DACs.
|
||||
Each switch determines where the digital input data to one of the DACs comes from.
|
||||
They are not supported by the ESI windows driver.
|
||||
For normal operation, they should all be set to "PCM out".
|
||||
|
||||
H/W: Output source channel 1
|
||||
H/W 1: Output source channel 2
|
||||
H/W 2: Output source channel 3
|
||||
H/W 3: Output source channel 4
|
||||
|
||||
H/W 4 ... H/W 9: unknown function, left in to enable testing.
|
||||
Possibly some of these control S/PDIF output(s).
|
||||
If these turn out to be unused, they will go away in later driver versions.
|
||||
|
||||
Selectable values for each of the digital output selectors are:
|
||||
"PCM out" -> DAC output of the corresponding channel (default setting)
|
||||
"Input 1"...
|
||||
"Input 4" -> direct routing from ADC output of the selected input channel
|
||||
|
||||
|
||||
--------
|
||||
|
||||
Feb 14, 2008
|
||||
Rainer Zimmermann
|
||||
mail@lightshed.de
|
||||
|
||||
|
|
@ -114,7 +114,7 @@ For writing a sequence of verbs, use snd_hda_sequence_write().
|
|||
|
||||
There are variants of cached read/write, snd_hda_codec_write_cache(),
|
||||
snd_hda_sequence_write_cache(). These are used for recording the
|
||||
register states for the power-mangement resume. When no PM is needed,
|
||||
register states for the power-management resume. When no PM is needed,
|
||||
these are equivalent with non-cached version.
|
||||
|
||||
To retrieve the number of sub nodes connected to the given node, use
|
||||
|
|
|
|||
|
|
@ -62,6 +62,7 @@ Audio DAPM widgets fall into a number of types:-
|
|||
o Mic - Mic (and optional Jack)
|
||||
o Line - Line Input/Output (and optional Jack)
|
||||
o Speaker - Speaker
|
||||
o Supply - Power or clock supply widget used by other widgets.
|
||||
o Pre - Special PRE widget (exec before all others)
|
||||
o Post - Special POST widget (exec after all others)
|
||||
|
||||
|
|
|
|||
|
|
@ -358,7 +358,7 @@ nr_pdflush_threads
|
|||
The current number of pdflush threads. This value is read-only.
|
||||
The value changes according to the number of dirty pages in the system.
|
||||
|
||||
When neccessary, additional pdflush threads are created, one per second, up to
|
||||
When necessary, additional pdflush threads are created, one per second, up to
|
||||
nr_pdflush_threads_max.
|
||||
|
||||
==============================================================
|
||||
|
|
@ -565,7 +565,7 @@ swappiness
|
|||
|
||||
This control is used to define how aggressive the kernel will swap
|
||||
memory pages. Higher values will increase agressiveness, lower values
|
||||
descrease the amount of swap.
|
||||
decrease the amount of swap.
|
||||
|
||||
The default value is 60.
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ by Intel and Microsoft which can be found at
|
|||
|
||||
Each HPET has one fixed-rate counter (at 10+ MHz, hence "High Precision")
|
||||
and up to 32 comparators. Normally three or more comparators are provided,
|
||||
each of which can generate oneshot interupts and at least one of which has
|
||||
each of which can generate oneshot interrupts and at least one of which has
|
||||
additional hardware to support periodic interrupts. The comparators are
|
||||
also called "timers", which can be misleading since usually timers are
|
||||
independent of each other ... these share a counter, complicating resets.
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ Timerstats sample period: 3.888770 s
|
|||
|
||||
The first column is the number of events, the second column the pid, the third
|
||||
column is the name of the process. The forth column shows the function which
|
||||
initialized the timer and in parantheses the callback function which was
|
||||
initialized the timer and in parenthesis the callback function which was
|
||||
executed on expiry.
|
||||
|
||||
Thomas, Ingo
|
||||
|
|
|
|||
|
|
@ -1834,4 +1834,4 @@ an error.
|
|||
-----------
|
||||
|
||||
More details can be found in the source code, in the
|
||||
kernel/tracing/*.c files.
|
||||
kernel/trace/*.c files.
|
||||
|
|
|
|||
|
|
@ -64,7 +64,7 @@ III. Quick usage guide
|
|||
CONFIG_KMEMTRACE).
|
||||
|
||||
2) Get the userspace tool and build it:
|
||||
$ git-clone git://repo.or.cz/kmemtrace-user.git # current repository
|
||||
$ git clone git://repo.or.cz/kmemtrace-user.git # current repository
|
||||
$ cd kmemtrace-user/
|
||||
$ ./autogen.sh
|
||||
$ ./configure
|
||||
|
|
|
|||
|
|
@ -84,7 +84,7 @@ The different logical parts of this driver are:
|
|||
|
||||
*UWB*: the Ultra-Wide-Band stack -- manages the radio and
|
||||
associated spectrum to allow for devices sharing it. Allows to
|
||||
control bandwidth assingment, beaconing, scanning, etc
|
||||
control bandwidth assignment, beaconing, scanning, etc
|
||||
|
||||
*
|
||||
|
||||
|
|
@ -184,7 +184,7 @@ and sends the replies and notifications back to the API
|
|||
[/uwb_rc_neh_grok()/]. Notifications are handled to the UWB daemon, that
|
||||
is chartered, among other things, to keep the tab of how the UWB radio
|
||||
neighborhood looks, creating and destroying devices as they show up or
|
||||
dissapear.
|
||||
disappear.
|
||||
|
||||
Command execution is very simple: a command block is sent and a event
|
||||
block or reply is expected back. For sending/receiving command/events, a
|
||||
|
|
@ -333,7 +333,7 @@ read descriptors and move our data.
|
|||
|
||||
*Device life cycle and keep alives*
|
||||
|
||||
Everytime there is a succesful transfer to/from a device, we update a
|
||||
Every time there is a successful transfer to/from a device, we update a
|
||||
per-device activity timestamp. If not, every now and then we check and
|
||||
if the activity timestamp gets old, we ping the device by sending it a
|
||||
Keep Alive IE; it responds with a /DN_Alive/ pong during the DNTS (this
|
||||
|
|
@ -411,7 +411,7 @@ context (wa_xfer) and submit it. When the xfer is done, our callback is
|
|||
called and we assign the status bits and release the xfer resources.
|
||||
|
||||
In dequeue() we are basically cancelling/aborting the transfer. We issue
|
||||
a xfer abort request to the HC, cancell all the URBs we had submitted
|
||||
a xfer abort request to the HC, cancel all the URBs we had submitted
|
||||
and not yet done and when all that is done, the xfer callback will be
|
||||
called--this will call the URB callback.
|
||||
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ Association and disassociation of URBs with anchors
|
|||
|
||||
An association of URBs to an anchor is made by an explicit
|
||||
call to usb_anchor_urb(). The association is maintained until
|
||||
an URB is finished by (successfull) completion. Thus disassociation
|
||||
an URB is finished by (successful) completion. Thus disassociation
|
||||
is automatic. A function is provided to forcibly finish (kill)
|
||||
all URBs associated with an anchor.
|
||||
Furthermore, disassociation can be made with usb_unanchor_urb()
|
||||
|
|
@ -76,4 +76,4 @@ usb_get_from_anchor()
|
|||
Returns the oldest anchored URB of an anchor. The URB is unanchored
|
||||
and returned with a reference. As you may mix URBs to several
|
||||
destinations in one anchor you have no guarantee the chronologically
|
||||
first submitted URB is returned.
|
||||
first submitted URB is returned.
|
||||
|
|
|
|||
|
|
@ -65,7 +65,7 @@ Accept or decline an interface. If you accept the device return 0,
|
|||
otherwise -ENODEV or -ENXIO. Other error codes should be used only if a
|
||||
genuine error occurred during initialisation which prevented a driver
|
||||
from accepting a device that would else have been accepted.
|
||||
You are strongly encouraged to use usbcore'sfacility,
|
||||
You are strongly encouraged to use usbcore's facility,
|
||||
usb_set_intfdata(), to associate a data structure with an interface, so
|
||||
that you know which internal state and identity you associate with a
|
||||
particular interface. The device will not be suspended and you may do IO
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ encoder chip:
|
|||
2) Some people have problems getting the i2c bus to work.
|
||||
The symptom is that the eeprom cannot be read and the card is
|
||||
unusable. This is probably fixed, but if you have problems
|
||||
then post to the video4linux or ivtv-users mailinglist.
|
||||
then post to the video4linux or ivtv-users mailing list.
|
||||
|
||||
3) VBI (raw or sliced) has not yet been implemented.
|
||||
|
||||
|
|
|
|||
|
|
@ -5,21 +5,51 @@ only the AMD64 specific ones are listed here.
|
|||
|
||||
Machine check
|
||||
|
||||
mce=off disable machine check
|
||||
mce=bootlog Enable logging of machine checks left over from booting.
|
||||
Disabled by default on AMD because some BIOS leave bogus ones.
|
||||
If your BIOS doesn't do that it's a good idea to enable though
|
||||
to make sure you log even machine check events that result
|
||||
in a reboot. On Intel systems it is enabled by default.
|
||||
Please see Documentation/x86/x86_64/machinecheck for sysfs runtime tunables.
|
||||
|
||||
mce=off
|
||||
Disable machine check
|
||||
mce=no_cmci
|
||||
Disable CMCI(Corrected Machine Check Interrupt) that
|
||||
Intel processor supports. Usually this disablement is
|
||||
not recommended, but it might be handy if your hardware
|
||||
is misbehaving.
|
||||
Note that you'll get more problems without CMCI than with
|
||||
due to the shared banks, i.e. you might get duplicated
|
||||
error logs.
|
||||
mce=dont_log_ce
|
||||
Don't make logs for corrected errors. All events reported
|
||||
as corrected are silently cleared by OS.
|
||||
This option will be useful if you have no interest in any
|
||||
of corrected errors.
|
||||
mce=ignore_ce
|
||||
Disable features for corrected errors, e.g. polling timer
|
||||
and CMCI. All events reported as corrected are not cleared
|
||||
by OS and remained in its error banks.
|
||||
Usually this disablement is not recommended, however if
|
||||
there is an agent checking/clearing corrected errors
|
||||
(e.g. BIOS or hardware monitoring applications), conflicting
|
||||
with OS's error handling, and you cannot deactivate the agent,
|
||||
then this option will be a help.
|
||||
mce=bootlog
|
||||
Enable logging of machine checks left over from booting.
|
||||
Disabled by default on AMD because some BIOS leave bogus ones.
|
||||
If your BIOS doesn't do that it's a good idea to enable though
|
||||
to make sure you log even machine check events that result
|
||||
in a reboot. On Intel systems it is enabled by default.
|
||||
mce=nobootlog
|
||||
Disable boot machine check logging.
|
||||
mce=tolerancelevel (number)
|
||||
mce=tolerancelevel[,monarchtimeout] (number,number)
|
||||
tolerance levels:
|
||||
0: always panic on uncorrected errors, log corrected errors
|
||||
1: panic or SIGBUS on uncorrected errors, log corrected errors
|
||||
2: SIGBUS or log uncorrected errors, log corrected errors
|
||||
3: never panic or SIGBUS, log all errors (for testing only)
|
||||
Default is 1
|
||||
Can be also set using sysfs which is preferable.
|
||||
monarchtimeout:
|
||||
Sets the time in us to wait for other CPUs on machine checks. 0
|
||||
to disable.
|
||||
|
||||
nomce (for compatibility with i386): same as mce=off
|
||||
|
||||
|
|
|
|||
|
|
@ -41,7 +41,9 @@ check_interval
|
|||
the polling interval. When the poller stops finding MCEs, it
|
||||
triggers an exponential backoff (poll less often) on the polling
|
||||
interval. The check_interval variable is both the initial and
|
||||
maximum polling interval.
|
||||
maximum polling interval. 0 means no polling for corrected machine
|
||||
check errors (but some corrected errors might be still reported
|
||||
in other ways)
|
||||
|
||||
tolerant
|
||||
Tolerance level. When a machine check exception occurs for a non
|
||||
|
|
@ -67,6 +69,10 @@ trigger
|
|||
Program to run when a machine check event is detected.
|
||||
This is an alternative to running mcelog regularly from cron
|
||||
and allows to detect events faster.
|
||||
monarch_timeout
|
||||
How long to wait for the other CPUs to machine check too on a
|
||||
exception. 0 to disable waiting for other CPUs.
|
||||
Unit: us
|
||||
|
||||
TBD document entries for AMD threshold interrupt configuration
|
||||
|
||||
|
|
|
|||
116
MAINTAINERS
116
MAINTAINERS
|
|
@ -681,6 +681,13 @@ M: sakoman@gmail.com
|
|||
L: linux-arm-kernel@lists.arm.linux.org.uk (subscribers-only)
|
||||
S: Maintained
|
||||
|
||||
ARM/H4700 (HP IPAQ HX4700) MACHINE SUPPORT
|
||||
P: Philipp Zabel
|
||||
M: philipp.zabel@gmail.com
|
||||
S: Maintained
|
||||
F: arch/arm/mach-pxa/hx4700.c
|
||||
F: arch/arm/mach-pxa/include/mach/hx4700.h
|
||||
|
||||
ARM/HP JORNADA 7XX MACHINE SUPPORT
|
||||
P: Kristoffer Ericson
|
||||
M: kristoffer.ericson@gmail.com
|
||||
|
|
@ -2105,6 +2112,15 @@ W: http://sourceforge.net/projects/lpfcxxxx
|
|||
S: Supported
|
||||
F: drivers/scsi/lpfc/
|
||||
|
||||
ENE CB710 FLASH CARD READER DRIVER
|
||||
P: Michał Mirosław
|
||||
M: mirq-linux@rere.qmqm.pl
|
||||
L: linux-kernel@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/misc/cb710/
|
||||
F: drivers/mmc/host/cb710-mmc.*
|
||||
F: include/linux/cb710.h
|
||||
|
||||
EPSON 1355 FRAMEBUFFER DRIVER
|
||||
P: Christopher Hoover
|
||||
M: ch@murgatroid.com
|
||||
|
|
@ -2351,7 +2367,7 @@ F: fs/freevxfs/
|
|||
|
||||
FREEZER
|
||||
P: Pavel Machek
|
||||
M: pavel@suse.cz
|
||||
M: pavel@ucw.cz
|
||||
P: Rafael J. Wysocki
|
||||
M: rjw@sisk.pl
|
||||
L: linux-pm@lists.linux-foundation.org
|
||||
|
|
@ -3376,6 +3392,10 @@ P: Catalin Marinas
|
|||
M: catalin.marinas@arm.com
|
||||
L: linux-kernel@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/kmemleak.txt
|
||||
F: include/linux/kmemleak.h
|
||||
F: mm/kmemleak.c
|
||||
F: mm/kmemleak-test.c
|
||||
|
||||
KMEMTRACE
|
||||
P: Eduard - Gabriel Munteanu
|
||||
|
|
@ -4163,6 +4183,69 @@ S: Maintained
|
|||
F: drivers/video/riva/
|
||||
F: drivers/video/nvidia/
|
||||
|
||||
OMAP SUPPORT
|
||||
P: Tony Lindgren <tony@atomide.com>
|
||||
M: tony@atomide.com
|
||||
L: linux-omap@vger.kernel.org
|
||||
W: http://www.muru.com/linux/omap/
|
||||
W: http://linux.omap.com/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
|
||||
S: Maintained
|
||||
F: arch/arm/*omap*
|
||||
|
||||
OMAP CLOCK FRAMEWORK SUPPORT
|
||||
P: Paul Walmsley
|
||||
M: paul@pwsan.com
|
||||
L: linux-omap@vger.kernel.org
|
||||
S: Maintained
|
||||
F: arch/arm/*omap*/*clock*
|
||||
|
||||
OMAP POWER MANAGEMENT SUPPORT
|
||||
P: Kevin Hilman
|
||||
M: khilman@deeprootsystems.com
|
||||
L: linux-omap@vger.kernel.org
|
||||
S: Maintained
|
||||
F: arch/arm/*omap*/*pm*
|
||||
|
||||
OMAP AUDIO SUPPORT
|
||||
P: Jarkko Nikula
|
||||
M: jhnikula@gmail.com
|
||||
L: alsa-devel@alsa-project.org (subscribers-only)
|
||||
L: linux-omap@vger.kernel.org
|
||||
S: Maintained
|
||||
F: sound/soc/omap/
|
||||
|
||||
OMAP FRAMEBUFFER SUPPORT
|
||||
P: Imre Deak
|
||||
M: imre.deak@nokia.com
|
||||
L: linux-fbdev-devel@lists.sourceforge.net (moderated for non-subscribers)
|
||||
L: linux-omap@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/video/omap/
|
||||
|
||||
OMAP MMC SUPPORT
|
||||
P: Jarkko Lavinen
|
||||
M: jarkko.lavinen@nokia.com
|
||||
L: linux-kernel@vger.kernel.org
|
||||
L: linux-omap@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/mmc/host/*omap*
|
||||
|
||||
OMAP RANDOM NUMBER GENERATOR SUPPORT
|
||||
P: Deepak Saxena
|
||||
M: dsaxena@plexity.net
|
||||
S: Maintained
|
||||
F: drivers/char/hw_random/omap-rng.c
|
||||
|
||||
OMAP USB SUPPORT
|
||||
P: Felipe Balbi
|
||||
M: felipe.balbi@nokia.com
|
||||
P: David Brownell
|
||||
M: dbrownell@users.sourceforge.net
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: linux-omap@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
OMFS FILESYSTEM
|
||||
P: Bob Copeland
|
||||
M: me@bobcopeland.com
|
||||
|
|
@ -4601,7 +4684,7 @@ F: drivers/media/video/pvrusb2/
|
|||
|
||||
PXA2xx/PXA3xx SUPPORT
|
||||
P: Eric Miao
|
||||
M: eric.miao@marvell.com
|
||||
M: eric.y.miao@gmail.com
|
||||
P: Russell King
|
||||
M: linux@arm.linux.org.uk
|
||||
L: linux-arm-kernel@lists.arm.linux.org.uk (subscribers-only)
|
||||
|
|
@ -4611,23 +4694,24 @@ F: drivers/pcmcia/pxa2xx*
|
|||
F: drivers/spi/pxa2xx*
|
||||
F: drivers/usb/gadget/pxa2*
|
||||
F: include/sound/pxa2xx-lib.h
|
||||
F: sound/soc/pxa/pxa2xx*
|
||||
F: sound/arm/pxa*
|
||||
F: sound/soc/pxa
|
||||
|
||||
PXA168 SUPPORT
|
||||
P: Eric Miao
|
||||
M: eric.miao@marvell.com
|
||||
M: eric.y.miao@gmail.com
|
||||
P: Jason Chagas
|
||||
M: jason.chagas@marvell.com
|
||||
L: linux-arm-kernel@lists.arm.linux.org.uk (subscribers-only)
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/ycmiao/pxa-linux-2.6.git
|
||||
S: Supported
|
||||
S: Maintained
|
||||
|
||||
PXA910 SUPPORT
|
||||
P: Eric Miao
|
||||
M: eric.miao@marvell.com
|
||||
M: eric.y.miao@gmail.com
|
||||
L: linux-arm-kernel@lists.arm.linux.org.uk (subscribers-only)
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/ycmiao/pxa-linux-2.6.git
|
||||
S: Supported
|
||||
S: Maintained
|
||||
|
||||
PXA MMCI DRIVER
|
||||
S: Orphan
|
||||
|
|
@ -5148,7 +5232,6 @@ P: Vincent Sanders
|
|||
M: support@simtec.co.uk
|
||||
W: http://www.simtec.co.uk/products/EB110ATX/
|
||||
S: Supported
|
||||
F: arch/arm/mach-ebsa110/
|
||||
|
||||
SIMTEC EB2410ITX (BAST)
|
||||
P: Ben Dooks
|
||||
|
|
@ -5339,11 +5422,12 @@ P: Liam Girdwood
|
|||
M: lrg@slimlogic.co.uk
|
||||
P: Mark Brown
|
||||
M: broonie@opensource.wolfsonmicro.com
|
||||
T: git git://opensource.wolfsonmicro.com/linux-2.6-asoc
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git
|
||||
L: alsa-devel@alsa-project.org (subscribers-only)
|
||||
W: http://alsa-project.org/main/index.php/ASoC
|
||||
S: Supported
|
||||
F: sound/soc/
|
||||
F: include/sound/soc*
|
||||
|
||||
SPARC + UltraSPARC (sparc/sparc64)
|
||||
P: David S. Miller
|
||||
|
|
@ -5561,20 +5645,6 @@ F: drivers/misc/tifm*
|
|||
F: drivers/mmc/host/tifm_sd.c
|
||||
F: include/linux/tifm.h
|
||||
|
||||
TI OMAP MMC INTERFACE DRIVER
|
||||
P: Carlos Aguiar, Anderson Briglia and Syed Khasim
|
||||
M: linux-omap@vger.kernel.org
|
||||
W: http://linux.omap.com
|
||||
W: http://www.muru.com/linux/omap/
|
||||
S: Maintained
|
||||
F: drivers/mmc/host/omap.c
|
||||
|
||||
TI OMAP RANDOM NUMBER GENERATOR SUPPORT
|
||||
P: Deepak Saxena
|
||||
M: dsaxena@plexity.net
|
||||
S: Maintained
|
||||
F: drivers/char/hw_random/omap-rng.c
|
||||
|
||||
TIPC NETWORK LAYER
|
||||
P: Per Liden
|
||||
M: per.liden@ericsson.com
|
||||
|
|
|
|||
26
Makefile
26
Makefile
|
|
@ -35,10 +35,8 @@ MAKEFLAGS += -rR --no-print-directory
|
|||
# To put more focus on warnings, be less verbose as default
|
||||
# Use 'make V=1' to see the full commands
|
||||
|
||||
ifdef V
|
||||
ifeq ("$(origin V)", "command line")
|
||||
KBUILD_VERBOSE = $(V)
|
||||
endif
|
||||
ifeq ("$(origin V)", "command line")
|
||||
KBUILD_VERBOSE = $(V)
|
||||
endif
|
||||
ifndef KBUILD_VERBOSE
|
||||
KBUILD_VERBOSE = 0
|
||||
|
|
@ -54,10 +52,8 @@ endif
|
|||
# See the file "Documentation/sparse.txt" for more details, including
|
||||
# where to get the "sparse" utility.
|
||||
|
||||
ifdef C
|
||||
ifeq ("$(origin C)", "command line")
|
||||
KBUILD_CHECKSRC = $(C)
|
||||
endif
|
||||
ifeq ("$(origin C)", "command line")
|
||||
KBUILD_CHECKSRC = $(C)
|
||||
endif
|
||||
ifndef KBUILD_CHECKSRC
|
||||
KBUILD_CHECKSRC = 0
|
||||
|
|
@ -69,12 +65,10 @@ endif
|
|||
ifdef SUBDIRS
|
||||
KBUILD_EXTMOD ?= $(SUBDIRS)
|
||||
endif
|
||||
ifdef M
|
||||
ifeq ("$(origin M)", "command line")
|
||||
KBUILD_EXTMOD := $(M)
|
||||
endif
|
||||
endif
|
||||
|
||||
ifeq ("$(origin M)", "command line")
|
||||
KBUILD_EXTMOD := $(M)
|
||||
endif
|
||||
|
||||
# kbuild supports saving output files in a separate directory.
|
||||
# To locate output files in a separate directory two syntaxes are supported.
|
||||
|
|
@ -98,10 +92,8 @@ ifeq ($(KBUILD_SRC),)
|
|||
|
||||
# OK, Make called in directory where kernel src resides
|
||||
# Do we want to locate output files in a separate directory?
|
||||
ifdef O
|
||||
ifeq ("$(origin O)", "command line")
|
||||
KBUILD_OUTPUT := $(O)
|
||||
endif
|
||||
ifeq ("$(origin O)", "command line")
|
||||
KBUILD_OUTPUT := $(O)
|
||||
endif
|
||||
|
||||
# That's our default target when none is given on the command line
|
||||
|
|
|
|||
11
README
11
README
|
|
@ -174,8 +174,17 @@ CONFIGURING the kernel:
|
|||
"make silentoldconfig"
|
||||
Like above, but avoids cluttering the screen
|
||||
with questions already answered.
|
||||
Additionally updates the dependencies.
|
||||
"make defconfig" Create a ./.config file by using the default
|
||||
symbol values from arch/$ARCH/defconfig.
|
||||
symbol values from either arch/$ARCH/defconfig
|
||||
or arch/$ARCH/configs/${PLATFORM}_defconfig,
|
||||
depending on the architecture.
|
||||
"make ${PLATFORM}_defconfig"
|
||||
Create a ./.config file by using the default
|
||||
symbol values from
|
||||
arch/$ARCH/configs/${PLATFORM}_defconfig.
|
||||
Use "make help" to get a list of all available
|
||||
platforms of your architecture.
|
||||
"make allyesconfig"
|
||||
Create a ./.config file by setting symbol
|
||||
values to 'y' as much as possible.
|
||||
|
|
|
|||
|
|
@ -256,5 +256,5 @@ static __inline__ int atomic64_add_unless(atomic64_t *v, long a, long u)
|
|||
#define smp_mb__before_atomic_inc() smp_mb()
|
||||
#define smp_mb__after_atomic_inc() smp_mb()
|
||||
|
||||
#include <asm-generic/atomic.h>
|
||||
#include <asm-generic/atomic-long.h>
|
||||
#endif /* _ALPHA_ATOMIC_H */
|
||||
|
|
|
|||
|
|
@ -0,0 +1,8 @@
|
|||
#ifndef __ASM_ALPHA_BITSPERLONG_H
|
||||
#define __ASM_ALPHA_BITSPERLONG_H
|
||||
|
||||
#define __BITS_PER_LONG 64
|
||||
|
||||
#include <asm-generic/bitsperlong.h>
|
||||
|
||||
#endif /* __ASM_ALPHA_BITSPERLONG_H */
|
||||
|
|
@ -93,6 +93,6 @@ typedef struct page *pgtable_t;
|
|||
VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC)
|
||||
|
||||
#include <asm-generic/memory_model.h>
|
||||
#include <asm-generic/page.h>
|
||||
#include <asm-generic/getorder.h>
|
||||
|
||||
#endif /* _ALPHA_PAGE_H */
|
||||
|
|
|
|||
|
|
@ -111,7 +111,7 @@ typedef unsigned long sigset_t;
|
|||
#define SIG_UNBLOCK 2 /* for unblocking signals */
|
||||
#define SIG_SETMASK 3 /* for setting the signal mask */
|
||||
|
||||
#include <asm-generic/signal.h>
|
||||
#include <asm-generic/signal-defs.h>
|
||||
|
||||
#ifdef __KERNEL__
|
||||
struct osf_sigaction {
|
||||
|
|
|
|||
|
|
@ -1,6 +0,0 @@
|
|||
#ifndef __ALPHA_SUSPEND_H
|
||||
#define __ALPHA_SUSPEND_H
|
||||
|
||||
/* Dummy include. */
|
||||
|
||||
#endif /* __ALPHA_SUSPEND_H */
|
||||
|
|
@ -25,9 +25,6 @@ typedef unsigned int umode_t;
|
|||
* These aren't exported outside the kernel to avoid name space clashes
|
||||
*/
|
||||
#ifdef __KERNEL__
|
||||
|
||||
#define BITS_PER_LONG 64
|
||||
|
||||
#ifndef __ASSEMBLY__
|
||||
|
||||
typedef u64 dma_addr_t;
|
||||
|
|
|
|||
|
|
@ -48,6 +48,27 @@ void sort_extable(struct exception_table_entry *start,
|
|||
cmp_ex, swap_ex);
|
||||
}
|
||||
|
||||
#ifdef CONFIG_MODULES
|
||||
/*
|
||||
* Any entry referring to the module init will be at the beginning or
|
||||
* the end.
|
||||
*/
|
||||
void trim_init_extable(struct module *m)
|
||||
{
|
||||
/*trim the beginning*/
|
||||
while (m->num_exentries &&
|
||||
within_module_init(ex_to_addr(&m->extable[0]), m)) {
|
||||
m->extable++;
|
||||
m->num_exentries--;
|
||||
}
|
||||
/*trim the end*/
|
||||
while (m->num_exentries &&
|
||||
within_module_init(ex_to_addr(&m->extable[m->num_exentries-1]),
|
||||
m))
|
||||
m->num_exentries--;
|
||||
}
|
||||
#endif /* CONFIG_MODULES */
|
||||
|
||||
const struct exception_table_entry *
|
||||
search_extable(const struct exception_table_entry *first,
|
||||
const struct exception_table_entry *last,
|
||||
|
|
|
|||
268
arch/arm/Kconfig
268
arch/arm/Kconfig
|
|
@ -34,15 +34,12 @@ config SYS_SUPPORTS_APM_EMULATION
|
|||
|
||||
config GENERIC_GPIO
|
||||
bool
|
||||
default n
|
||||
|
||||
config GENERIC_TIME
|
||||
bool
|
||||
default n
|
||||
|
||||
config GENERIC_CLOCKEVENTS
|
||||
bool
|
||||
default n
|
||||
|
||||
config GENERIC_CLOCKEVENTS_BROADCAST
|
||||
bool
|
||||
|
|
@ -55,7 +52,6 @@ config MMU
|
|||
|
||||
config NO_IOPORT
|
||||
bool
|
||||
default n
|
||||
|
||||
config EISA
|
||||
bool
|
||||
|
|
@ -126,11 +122,9 @@ config RWSEM_XCHGADD_ALGORITHM
|
|||
|
||||
config ARCH_HAS_ILOG2_U32
|
||||
bool
|
||||
default n
|
||||
|
||||
config ARCH_HAS_ILOG2_U64
|
||||
bool
|
||||
default n
|
||||
|
||||
config GENERIC_HWEIGHT
|
||||
bool
|
||||
|
|
@ -253,6 +247,14 @@ config ARCH_CLPS711X
|
|||
help
|
||||
Support for Cirrus Logic 711x/721x based boards.
|
||||
|
||||
config ARCH_GEMINI
|
||||
bool "Cortina Systems Gemini"
|
||||
select CPU_FA526
|
||||
select GENERIC_GPIO
|
||||
select ARCH_REQUIRE_GPIOLIB
|
||||
help
|
||||
Support for the Cortina Systems Gemini family SoCs
|
||||
|
||||
config ARCH_EBSA110
|
||||
bool "EBSA-110"
|
||||
select CPU_SA110
|
||||
|
|
@ -277,14 +279,6 @@ config ARCH_EP93XX
|
|||
help
|
||||
This enables support for the Cirrus EP93xx series of CPUs.
|
||||
|
||||
config ARCH_GEMINI
|
||||
bool "Cortina Systems Gemini"
|
||||
select CPU_FA526
|
||||
select GENERIC_GPIO
|
||||
select ARCH_REQUIRE_GPIOLIB
|
||||
help
|
||||
Support for the Cortina Systems Gemini family SoCs
|
||||
|
||||
config ARCH_FOOTBRIDGE
|
||||
bool "FootBridge"
|
||||
select CPU_SA110
|
||||
|
|
@ -293,6 +287,30 @@ config ARCH_FOOTBRIDGE
|
|||
Support for systems based on the DC21285 companion chip
|
||||
("FootBridge"), such as the Simtec CATS and the Rebel NetWinder.
|
||||
|
||||
config ARCH_MXC
|
||||
bool "Freescale MXC/iMX-based"
|
||||
select GENERIC_TIME
|
||||
select GENERIC_CLOCKEVENTS
|
||||
select ARCH_MTD_XIP
|
||||
select GENERIC_GPIO
|
||||
select ARCH_REQUIRE_GPIOLIB
|
||||
select HAVE_CLK
|
||||
help
|
||||
Support for Freescale MXC/iMX-based family of processors
|
||||
|
||||
config ARCH_STMP3XXX
|
||||
bool "Freescale STMP3xxx"
|
||||
select CPU_ARM926T
|
||||
select HAVE_CLK
|
||||
select COMMON_CLKDEV
|
||||
select ARCH_REQUIRE_GPIOLIB
|
||||
select GENERIC_TIME
|
||||
select GENERIC_CLOCKEVENTS
|
||||
select GENERIC_GPIO
|
||||
select USB_ARCH_HAS_EHCI
|
||||
help
|
||||
Support for systems based on the Freescale 3xxx CPUs.
|
||||
|
||||
config ARCH_NETX
|
||||
bool "Hilscher NetX based"
|
||||
select CPU_ARM926T
|
||||
|
|
@ -309,15 +327,6 @@ config ARCH_H720X
|
|||
help
|
||||
This enables support for systems based on the Hynix HMS720x
|
||||
|
||||
config ARCH_IMX
|
||||
bool "IMX"
|
||||
select CPU_ARM920T
|
||||
select GENERIC_GPIO
|
||||
select GENERIC_TIME
|
||||
select GENERIC_CLOCKEVENTS
|
||||
help
|
||||
Support for Motorola's i.MX family of processors (MX1, MXL).
|
||||
|
||||
config ARCH_IOP13XX
|
||||
bool "IOP13xx-based"
|
||||
depends on MMU
|
||||
|
|
@ -398,6 +407,7 @@ config ARCH_KIRKWOOD
|
|||
select CPU_FEROCEON
|
||||
select PCI
|
||||
select GENERIC_GPIO
|
||||
select ARCH_REQUIRE_GPIOLIB
|
||||
select GENERIC_TIME
|
||||
select GENERIC_CLOCKEVENTS
|
||||
select PLAT_ORION
|
||||
|
|
@ -405,6 +415,57 @@ config ARCH_KIRKWOOD
|
|||
Support for the following Marvell Kirkwood series SoCs:
|
||||
88F6180, 88F6192 and 88F6281.
|
||||
|
||||
config ARCH_LOKI
|
||||
bool "Marvell Loki (88RC8480)"
|
||||
select CPU_FEROCEON
|
||||
select GENERIC_TIME
|
||||
select GENERIC_CLOCKEVENTS
|
||||
select PLAT_ORION
|
||||
help
|
||||
Support for the Marvell Loki (88RC8480) SoC.
|
||||
|
||||
config ARCH_MV78XX0
|
||||
bool "Marvell MV78xx0"
|
||||
select CPU_FEROCEON
|
||||
select PCI
|
||||
select GENERIC_GPIO
|
||||
select ARCH_REQUIRE_GPIOLIB
|
||||
select GENERIC_TIME
|
||||
select GENERIC_CLOCKEVENTS
|
||||
select PLAT_ORION
|
||||
help
|
||||
Support for the following Marvell MV78xx0 series SoCs:
|
||||
MV781x0, MV782x0.
|
||||
|
||||
config ARCH_ORION5X
|
||||
bool "Marvell Orion"
|
||||
depends on MMU
|
||||
select CPU_FEROCEON
|
||||
select PCI
|
||||
select GENERIC_GPIO
|
||||
select ARCH_REQUIRE_GPIOLIB
|
||||
select GENERIC_TIME
|
||||
select GENERIC_CLOCKEVENTS
|
||||
select PLAT_ORION
|
||||
help
|
||||
Support for the following Marvell Orion 5x series SoCs:
|
||||
Orion-1 (5181), Orion-VoIP (5181L), Orion-NAS (5182),
|
||||
Orion-2 (5281), Orion-1-90 (6183).
|
||||
|
||||
config ARCH_MMP
|
||||
bool "Marvell PXA168/910"
|
||||
depends on MMU
|
||||
select GENERIC_GPIO
|
||||
select ARCH_REQUIRE_GPIOLIB
|
||||
select HAVE_CLK
|
||||
select COMMON_CLKDEV
|
||||
select GENERIC_TIME
|
||||
select GENERIC_CLOCKEVENTS
|
||||
select TICK_ONESHOT
|
||||
select PLAT_PXA
|
||||
help
|
||||
Support for Marvell's PXA168/910 processor line.
|
||||
|
||||
config ARCH_KS8695
|
||||
bool "Micrel/Kendin KS8695"
|
||||
select CPU_ARM922T
|
||||
|
|
@ -427,51 +488,15 @@ config ARCH_NS9XXX
|
|||
|
||||
<http://www.digi.com/products/microprocessors/index.jsp>
|
||||
|
||||
config ARCH_LOKI
|
||||
bool "Marvell Loki (88RC8480)"
|
||||
select CPU_FEROCEON
|
||||
select GENERIC_TIME
|
||||
select GENERIC_CLOCKEVENTS
|
||||
select PLAT_ORION
|
||||
help
|
||||
Support for the Marvell Loki (88RC8480) SoC.
|
||||
|
||||
config ARCH_MV78XX0
|
||||
bool "Marvell MV78xx0"
|
||||
select CPU_FEROCEON
|
||||
select PCI
|
||||
select GENERIC_GPIO
|
||||
select GENERIC_TIME
|
||||
select GENERIC_CLOCKEVENTS
|
||||
select PLAT_ORION
|
||||
help
|
||||
Support for the following Marvell MV78xx0 series SoCs:
|
||||
MV781x0, MV782x0.
|
||||
|
||||
config ARCH_MXC
|
||||
bool "Freescale MXC/iMX-based"
|
||||
select GENERIC_TIME
|
||||
select GENERIC_CLOCKEVENTS
|
||||
select ARCH_MTD_XIP
|
||||
select GENERIC_GPIO
|
||||
config ARCH_W90X900
|
||||
bool "Nuvoton W90X900 CPU"
|
||||
select CPU_ARM926T
|
||||
select ARCH_REQUIRE_GPIOLIB
|
||||
select HAVE_CLK
|
||||
help
|
||||
Support for Freescale MXC/iMX-based family of processors
|
||||
|
||||
config ARCH_ORION5X
|
||||
bool "Marvell Orion"
|
||||
depends on MMU
|
||||
select CPU_FEROCEON
|
||||
select PCI
|
||||
select GENERIC_GPIO
|
||||
select GENERIC_TIME
|
||||
select GENERIC_CLOCKEVENTS
|
||||
select PLAT_ORION
|
||||
select COMMON_CLKDEV
|
||||
help
|
||||
Support for the following Marvell Orion 5x series SoCs:
|
||||
Orion-1 (5181), Orion-VoIP (5181L), Orion-NAS (5182),
|
||||
Orion-2 (5281), Orion-1-90 (6183).
|
||||
Support for Nuvoton (Winbond logic dept.) ARM9 processor,You
|
||||
can login www.mcuos.com or www.nuvoton.com to know more.
|
||||
|
||||
config ARCH_PNX4008
|
||||
bool "Philips Nexperia PNX4008 Mobile"
|
||||
|
|
@ -495,19 +520,16 @@ config ARCH_PXA
|
|||
help
|
||||
Support for Intel/Marvell's PXA2xx/PXA3xx processor line.
|
||||
|
||||
config ARCH_MMP
|
||||
bool "Marvell PXA168/910"
|
||||
depends on MMU
|
||||
select GENERIC_GPIO
|
||||
select ARCH_REQUIRE_GPIOLIB
|
||||
select HAVE_CLK
|
||||
select COMMON_CLKDEV
|
||||
config ARCH_MSM
|
||||
bool "Qualcomm MSM"
|
||||
select CPU_V6
|
||||
select GENERIC_TIME
|
||||
select GENERIC_CLOCKEVENTS
|
||||
select TICK_ONESHOT
|
||||
select PLAT_PXA
|
||||
help
|
||||
Support for Marvell's PXA168/910 processor line.
|
||||
Support for Qualcomm MSM7K based systems. This runs on the ARM11
|
||||
apps processor of the MSM7K and depends on a shared memory
|
||||
interface to the ARM9 modem processor which runs the baseband stack
|
||||
and controls some vital subsystems (clock and power control, etc).
|
||||
|
||||
config ARCH_RPC
|
||||
bool "RiscPC"
|
||||
|
|
@ -576,6 +598,20 @@ config ARCH_LH7A40X
|
|||
core with a wide array of integrated devices for
|
||||
hand-held and low-power applications.
|
||||
|
||||
config ARCH_U300
|
||||
bool "ST-Ericsson U300 Series"
|
||||
depends on MMU
|
||||
select CPU_ARM926T
|
||||
select ARM_AMBA
|
||||
select ARM_VIC
|
||||
select GENERIC_TIME
|
||||
select GENERIC_CLOCKEVENTS
|
||||
select HAVE_CLK
|
||||
select COMMON_CLKDEV
|
||||
select GENERIC_GPIO
|
||||
help
|
||||
Support for ST-Ericsson U300 series mobile platforms.
|
||||
|
||||
config ARCH_DAVINCI
|
||||
bool "TI DaVinci"
|
||||
select CPU_ARM926T
|
||||
|
|
@ -587,6 +623,7 @@ config ARCH_DAVINCI
|
|||
select ZONE_DMA
|
||||
select HAVE_IDE
|
||||
select COMMON_CLKDEV
|
||||
select GENERIC_ALLOCATOR
|
||||
help
|
||||
Support for TI's DaVinci platform.
|
||||
|
||||
|
|
@ -600,24 +637,6 @@ config ARCH_OMAP
|
|||
help
|
||||
Support for TI's OMAP platform (OMAP1 and OMAP2).
|
||||
|
||||
config ARCH_MSM
|
||||
bool "Qualcomm MSM"
|
||||
select CPU_V6
|
||||
select GENERIC_TIME
|
||||
select GENERIC_CLOCKEVENTS
|
||||
help
|
||||
Support for Qualcomm MSM7K based systems. This runs on the ARM11
|
||||
apps processor of the MSM7K and depends on a shared memory
|
||||
interface to the ARM9 modem processor which runs the baseband stack
|
||||
and controls some vital subsystems (clock and power control, etc).
|
||||
|
||||
config ARCH_W90X900
|
||||
bool "Nuvoton W90X900 CPU"
|
||||
select CPU_ARM926T
|
||||
help
|
||||
Support for Nuvoton (Winbond logic dept.) ARM9 processor,You
|
||||
can login www.mcuos.com or www.nuvoton.com to know more.
|
||||
|
||||
endchoice
|
||||
|
||||
source "arch/arm/mach-clps711x/Kconfig"
|
||||
|
|
@ -681,9 +700,9 @@ source "arch/arm/mach-s3c6400/Kconfig"
|
|||
source "arch/arm/mach-s3c6410/Kconfig"
|
||||
endif
|
||||
|
||||
source "arch/arm/mach-lh7a40x/Kconfig"
|
||||
source "arch/arm/plat-stmp3xxx/Kconfig"
|
||||
|
||||
source "arch/arm/mach-imx/Kconfig"
|
||||
source "arch/arm/mach-lh7a40x/Kconfig"
|
||||
|
||||
source "arch/arm/mach-h720x/Kconfig"
|
||||
|
||||
|
|
@ -707,6 +726,8 @@ source "arch/arm/mach-ks8695/Kconfig"
|
|||
|
||||
source "arch/arm/mach-msm/Kconfig"
|
||||
|
||||
source "arch/arm/mach-u300/Kconfig"
|
||||
|
||||
source "arch/arm/mach-w90x900/Kconfig"
|
||||
|
||||
# Definitions to make life easier
|
||||
|
|
@ -859,8 +880,11 @@ source "kernel/time/Kconfig"
|
|||
|
||||
config SMP
|
||||
bool "Symmetric Multi-Processing (EXPERIMENTAL)"
|
||||
depends on EXPERIMENTAL && (REALVIEW_EB_ARM11MP || MACH_REALVIEW_PB11MP)
|
||||
depends on EXPERIMENTAL && (REALVIEW_EB_ARM11MP || REALVIEW_EB_A9MP ||\
|
||||
MACH_REALVIEW_PB11MP || MACH_REALVIEW_PBX || ARCH_OMAP4)
|
||||
depends on GENERIC_CLOCKEVENTS
|
||||
select USE_GENERIC_SMP_HELPERS
|
||||
select HAVE_ARM_SCU if (ARCH_REALVIEW || ARCH_OMAP4)
|
||||
help
|
||||
This enables support for systems with more than one CPU. If you have
|
||||
a system with only one CPU, like most personal computers, say N. If
|
||||
|
|
@ -878,6 +902,18 @@ config SMP
|
|||
|
||||
If you don't know what to do here, say N.
|
||||
|
||||
config HAVE_ARM_SCU
|
||||
bool
|
||||
depends on SMP
|
||||
help
|
||||
This option enables support for the ARM system coherency unit
|
||||
|
||||
config HAVE_ARM_TWD
|
||||
bool
|
||||
depends on SMP
|
||||
help
|
||||
This options enables support for the ARM timer and watchdog unit
|
||||
|
||||
choice
|
||||
prompt "Memory split"
|
||||
default VMSPLIT_3G
|
||||
|
|
@ -916,8 +952,10 @@ config HOTPLUG_CPU
|
|||
|
||||
config LOCAL_TIMERS
|
||||
bool "Use local timer interrupts"
|
||||
depends on SMP && (REALVIEW_EB_ARM11MP || MACH_REALVIEW_PB11MP || REALVIEW_EB_A9MP)
|
||||
depends on SMP && (REALVIEW_EB_ARM11MP || MACH_REALVIEW_PB11MP || \
|
||||
REALVIEW_EB_A9MP || MACH_REALVIEW_PBX || ARCH_OMAP4)
|
||||
default y
|
||||
select HAVE_ARM_TWD if (ARCH_REALVIEW || ARCH_OMAP4)
|
||||
help
|
||||
Enable support for local timers on SMP platforms, rather then the
|
||||
legacy IPI broadcast method. Local timers allows the system
|
||||
|
|
@ -979,7 +1017,6 @@ config OABI_COMPAT
|
|||
|
||||
config ARCH_HAS_HOLES_MEMORYMODEL
|
||||
bool
|
||||
default n
|
||||
|
||||
# Discontigmem is deprecated
|
||||
config ARCH_DISCONTIGMEM_ENABLE
|
||||
|
|
@ -1022,12 +1059,12 @@ source "mm/Kconfig"
|
|||
config LEDS
|
||||
bool "Timer and CPU usage LEDs"
|
||||
depends on ARCH_CDB89712 || ARCH_EBSA110 || \
|
||||
ARCH_EBSA285 || ARCH_IMX || ARCH_INTEGRATOR || \
|
||||
ARCH_EBSA285 || ARCH_INTEGRATOR || \
|
||||
ARCH_LUBBOCK || MACH_MAINSTONE || ARCH_NETWINDER || \
|
||||
ARCH_OMAP || ARCH_P720T || ARCH_PXA_IDP || \
|
||||
ARCH_SA1100 || ARCH_SHARK || ARCH_VERSATILE || \
|
||||
ARCH_AT91 || ARCH_DAVINCI || \
|
||||
ARCH_KS8695 || MACH_RD88F5182
|
||||
ARCH_KS8695 || MACH_RD88F5182 || ARCH_REALVIEW
|
||||
help
|
||||
If you say Y here, the LEDs on your machine will be used
|
||||
to provide useful information about your current system status.
|
||||
|
|
@ -1085,6 +1122,22 @@ config ALIGNMENT_TRAP
|
|||
correct operation of some network protocols. With an IP-only
|
||||
configuration it is safe to say N, otherwise say Y.
|
||||
|
||||
config UACCESS_WITH_MEMCPY
|
||||
bool "Use kernel mem{cpy,set}() for {copy_to,clear}_user() (EXPERIMENTAL)"
|
||||
depends on MMU && EXPERIMENTAL
|
||||
default y if CPU_FEROCEON
|
||||
help
|
||||
Implement faster copy_to_user and clear_user methods for CPU
|
||||
cores where a 8-word STM instruction give significantly higher
|
||||
memory write throughput than a sequence of individual 32bit stores.
|
||||
|
||||
A possible side effect is a slight increase in scheduling latency
|
||||
between threads sharing the same address space if they invoke
|
||||
such copy operations with large buffers.
|
||||
|
||||
However, if the CPU data cache is using a write-allocate mode,
|
||||
this option is unlikely to provide any performance gain.
|
||||
|
||||
endmenu
|
||||
|
||||
menu "Boot options"
|
||||
|
|
@ -1188,7 +1241,7 @@ endmenu
|
|||
|
||||
menu "CPU Power Management"
|
||||
|
||||
if (ARCH_SA1100 || ARCH_INTEGRATOR || ARCH_OMAP || ARCH_IMX || ARCH_PXA)
|
||||
if (ARCH_SA1100 || ARCH_INTEGRATOR || ARCH_OMAP || ARCH_PXA)
|
||||
|
||||
source "drivers/cpufreq/Kconfig"
|
||||
|
||||
|
|
@ -1213,14 +1266,11 @@ config CPU_FREQ_INTEGRATOR
|
|||
|
||||
If in doubt, say Y.
|
||||
|
||||
config CPU_FREQ_IMX
|
||||
tristate "CPUfreq driver for i.MX CPUs"
|
||||
depends on ARCH_IMX && CPU_FREQ
|
||||
default n
|
||||
help
|
||||
This enables the CPUfreq driver for i.MX CPUs.
|
||||
|
||||
If in doubt, say N.
|
||||
config CPU_FREQ_PXA
|
||||
bool
|
||||
depends on CPU_FREQ && ARCH_PXA && PXA25x
|
||||
default y
|
||||
select CPU_FREQ_DEFAULT_GOV_USERSPACE
|
||||
|
||||
endif
|
||||
|
||||
|
|
|
|||
|
|
@ -11,6 +11,9 @@
|
|||
# Copyright (C) 1995-2001 by Russell King
|
||||
|
||||
LDFLAGS_vmlinux :=-p --no-undefined -X
|
||||
ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
|
||||
LDFLAGS_vmlinux += --be8
|
||||
endif
|
||||
CPPFLAGS_vmlinux.lds = -DTEXT_OFFSET=$(TEXT_OFFSET)
|
||||
OBJCOPYFLAGS :=-O binary -R .note -R .note.gnu.build-id -R .comment -S
|
||||
GZFLAGS :=-9
|
||||
|
|
@ -99,64 +102,73 @@ CHECKFLAGS += -D__arm__
|
|||
#Default value
|
||||
head-y := arch/arm/kernel/head$(MMUEXT).o arch/arm/kernel/init_task.o
|
||||
textofs-y := 0x00008000
|
||||
|
||||
machine-$(CONFIG_ARCH_RPC) := rpc
|
||||
machine-$(CONFIG_ARCH_EBSA110) := ebsa110
|
||||
machine-$(CONFIG_FOOTBRIDGE) := footbridge
|
||||
machine-$(CONFIG_ARCH_SHARK) := shark
|
||||
machine-$(CONFIG_ARCH_SA1100) := sa1100
|
||||
ifeq ($(CONFIG_ARCH_SA1100),y)
|
||||
textofs-$(CONFIG_ARCH_CLPS711X) := 0x00028000
|
||||
# SA1111 DMA bug: we don't want the kernel to live in precious DMA-able memory
|
||||
textofs-$(CONFIG_SA1111) := 0x00208000
|
||||
ifeq ($(CONFIG_ARCH_SA1100),y)
|
||||
textofs-$(CONFIG_SA1111) := 0x00208000
|
||||
endif
|
||||
machine-$(CONFIG_ARCH_PXA) := pxa
|
||||
machine-$(CONFIG_ARCH_MMP) := mmp
|
||||
plat-$(CONFIG_PLAT_PXA) := pxa
|
||||
machine-$(CONFIG_ARCH_L7200) := l7200
|
||||
machine-$(CONFIG_ARCH_INTEGRATOR) := integrator
|
||||
machine-$(CONFIG_ARCH_GEMINI) := gemini
|
||||
textofs-$(CONFIG_ARCH_CLPS711X) := 0x00028000
|
||||
machine-$(CONFIG_ARCH_CLPS711X) := clps711x
|
||||
machine-$(CONFIG_ARCH_IOP32X) := iop32x
|
||||
machine-$(CONFIG_ARCH_IOP33X) := iop33x
|
||||
machine-$(CONFIG_ARCH_IOP13XX) := iop13xx
|
||||
plat-$(CONFIG_PLAT_IOP) := iop
|
||||
machine-$(CONFIG_ARCH_IXP4XX) := ixp4xx
|
||||
machine-$(CONFIG_ARCH_IXP2000) := ixp2000
|
||||
machine-$(CONFIG_ARCH_IXP23XX) := ixp23xx
|
||||
machine-$(CONFIG_ARCH_OMAP1) := omap1
|
||||
machine-$(CONFIG_ARCH_OMAP2) := omap2
|
||||
machine-$(CONFIG_ARCH_OMAP3) := omap2
|
||||
plat-$(CONFIG_ARCH_OMAP) := omap
|
||||
machine-$(CONFIG_ARCH_S3C2410) := s3c2410 s3c2400 s3c2412 s3c2440 s3c2442 s3c2443
|
||||
machine-$(CONFIG_ARCH_S3C24A0) := s3c24a0
|
||||
plat-$(CONFIG_PLAT_S3C24XX) := s3c24xx s3c
|
||||
machine-$(CONFIG_ARCH_S3C64XX) := s3c6400 s3c6410
|
||||
plat-$(CONFIG_PLAT_S3C64XX) := s3c64xx s3c
|
||||
machine-$(CONFIG_ARCH_LH7A40X) := lh7a40x
|
||||
machine-$(CONFIG_ARCH_VERSATILE) := versatile
|
||||
machine-$(CONFIG_ARCH_IMX) := imx
|
||||
machine-$(CONFIG_ARCH_H720X) := h720x
|
||||
machine-$(CONFIG_ARCH_AAEC2000) := aaec2000
|
||||
machine-$(CONFIG_ARCH_REALVIEW) := realview
|
||||
machine-$(CONFIG_ARCH_AT91) := at91
|
||||
machine-$(CONFIG_ARCH_EP93XX) := ep93xx
|
||||
machine-$(CONFIG_ARCH_PNX4008) := pnx4008
|
||||
machine-$(CONFIG_ARCH_NETX) := netx
|
||||
machine-$(CONFIG_ARCH_NS9XXX) := ns9xxx
|
||||
machine-$(CONFIG_ARCH_DAVINCI) := davinci
|
||||
machine-$(CONFIG_ARCH_KIRKWOOD) := kirkwood
|
||||
machine-$(CONFIG_ARCH_KS8695) := ks8695
|
||||
plat-$(CONFIG_ARCH_MXC) := mxc
|
||||
machine-$(CONFIG_ARCH_MX2) := mx2
|
||||
machine-$(CONFIG_ARCH_MX3) := mx3
|
||||
machine-$(CONFIG_ARCH_MX1) := mx1
|
||||
machine-$(CONFIG_ARCH_ORION5X) := orion5x
|
||||
plat-$(CONFIG_PLAT_ORION) := orion
|
||||
machine-$(CONFIG_ARCH_MSM) := msm
|
||||
machine-$(CONFIG_ARCH_LOKI) := loki
|
||||
machine-$(CONFIG_ARCH_MV78XX0) := mv78xx0
|
||||
machine-$(CONFIG_ARCH_W90X900) := w90x900
|
||||
|
||||
# Machine directory name. This list is sorted alphanumerically
|
||||
# by CONFIG_* macro name.
|
||||
machine-$(CONFIG_ARCH_AAEC2000) := aaec2000
|
||||
machine-$(CONFIG_ARCH_AT91) := at91
|
||||
machine-$(CONFIG_ARCH_CLPS711X) := clps711x
|
||||
machine-$(CONFIG_ARCH_DAVINCI) := davinci
|
||||
machine-$(CONFIG_ARCH_EBSA110) := ebsa110
|
||||
machine-$(CONFIG_ARCH_EP93XX) := ep93xx
|
||||
machine-$(CONFIG_ARCH_GEMINI) := gemini
|
||||
machine-$(CONFIG_ARCH_H720X) := h720x
|
||||
machine-$(CONFIG_ARCH_INTEGRATOR) := integrator
|
||||
machine-$(CONFIG_ARCH_IOP13XX) := iop13xx
|
||||
machine-$(CONFIG_ARCH_IOP32X) := iop32x
|
||||
machine-$(CONFIG_ARCH_IOP33X) := iop33x
|
||||
machine-$(CONFIG_ARCH_IXP2000) := ixp2000
|
||||
machine-$(CONFIG_ARCH_IXP23XX) := ixp23xx
|
||||
machine-$(CONFIG_ARCH_IXP4XX) := ixp4xx
|
||||
machine-$(CONFIG_ARCH_KIRKWOOD) := kirkwood
|
||||
machine-$(CONFIG_ARCH_KS8695) := ks8695
|
||||
machine-$(CONFIG_ARCH_L7200) := l7200
|
||||
machine-$(CONFIG_ARCH_LH7A40X) := lh7a40x
|
||||
machine-$(CONFIG_ARCH_LOKI) := loki
|
||||
machine-$(CONFIG_ARCH_MMP) := mmp
|
||||
machine-$(CONFIG_ARCH_MSM) := msm
|
||||
machine-$(CONFIG_ARCH_MV78XX0) := mv78xx0
|
||||
machine-$(CONFIG_ARCH_MX1) := mx1
|
||||
machine-$(CONFIG_ARCH_MX2) := mx2
|
||||
machine-$(CONFIG_ARCH_MX3) := mx3
|
||||
machine-$(CONFIG_ARCH_NETX) := netx
|
||||
machine-$(CONFIG_ARCH_NS9XXX) := ns9xxx
|
||||
machine-$(CONFIG_ARCH_OMAP1) := omap1
|
||||
machine-$(CONFIG_ARCH_OMAP2) := omap2
|
||||
machine-$(CONFIG_ARCH_OMAP3) := omap2
|
||||
machine-$(CONFIG_ARCH_OMAP4) := omap2
|
||||
machine-$(CONFIG_ARCH_ORION5X) := orion5x
|
||||
machine-$(CONFIG_ARCH_PNX4008) := pnx4008
|
||||
machine-$(CONFIG_ARCH_PXA) := pxa
|
||||
machine-$(CONFIG_ARCH_REALVIEW) := realview
|
||||
machine-$(CONFIG_ARCH_RPC) := rpc
|
||||
machine-$(CONFIG_ARCH_S3C2410) := s3c2410 s3c2400 s3c2412 s3c2440 s3c2442 s3c2443
|
||||
machine-$(CONFIG_ARCH_S3C24A0) := s3c24a0
|
||||
machine-$(CONFIG_ARCH_S3C64XX) := s3c6400 s3c6410
|
||||
machine-$(CONFIG_ARCH_SA1100) := sa1100
|
||||
machine-$(CONFIG_ARCH_SHARK) := shark
|
||||
machine-$(CONFIG_ARCH_STMP378X) := stmp378x
|
||||
machine-$(CONFIG_ARCH_STMP37XX) := stmp37xx
|
||||
machine-$(CONFIG_ARCH_U300) := u300
|
||||
machine-$(CONFIG_ARCH_VERSATILE) := versatile
|
||||
machine-$(CONFIG_ARCH_W90X900) := w90x900
|
||||
machine-$(CONFIG_FOOTBRIDGE) := footbridge
|
||||
|
||||
# Platform directory name. This list is sorted alphanumerically
|
||||
# by CONFIG_* macro name.
|
||||
plat-$(CONFIG_ARCH_MXC) := mxc
|
||||
plat-$(CONFIG_ARCH_OMAP) := omap
|
||||
plat-$(CONFIG_PLAT_IOP) := iop
|
||||
plat-$(CONFIG_PLAT_ORION) := orion
|
||||
plat-$(CONFIG_PLAT_PXA) := pxa
|
||||
plat-$(CONFIG_PLAT_S3C24XX) := s3c24xx s3c
|
||||
plat-$(CONFIG_PLAT_S3C64XX) := s3c64xx s3c
|
||||
plat-$(CONFIG_ARCH_STMP3XXX) := stmp3xxx
|
||||
|
||||
ifeq ($(CONFIG_ARCH_EBSA110),y)
|
||||
# This is what happens if you forget the IOCS16 line.
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ ifeq ($(CONFIG_PXA_SHARPSL),y)
|
|||
OBJS += head-sharpsl.o
|
||||
endif
|
||||
|
||||
ifeq ($(CONFIG_CPU_BIG_ENDIAN),y)
|
||||
ifeq ($(CONFIG_CPU_ENDIAN_BE32),y)
|
||||
ifeq ($(CONFIG_CPU_CP15),y)
|
||||
OBJS += big-endian.o
|
||||
else
|
||||
|
|
@ -78,6 +78,9 @@ EXTRA_AFLAGS := -Wa,-march=all
|
|||
# linker symbols. We only define initrd_phys and params_phys if the
|
||||
# machine class defined the corresponding makefile variable.
|
||||
LDFLAGS_vmlinux := --defsym zreladdr=$(ZRELADDR)
|
||||
ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
|
||||
LDFLAGS_vmlinux += --be8
|
||||
endif
|
||||
ifneq ($(INITRD_PHYS),)
|
||||
LDFLAGS_vmlinux += --defsym initrd_phys=$(INITRD_PHYS)
|
||||
endif
|
||||
|
|
|
|||
|
|
@ -438,6 +438,9 @@ __armv4_mmu_cache_on:
|
|||
mrc p15, 0, r0, c1, c0, 0 @ read control reg
|
||||
orr r0, r0, #0x5000 @ I-cache enable, RR cache replacement
|
||||
orr r0, r0, #0x0030
|
||||
#ifdef CONFIG_CPU_ENDIAN_BE8
|
||||
orr r0, r0, #1 << 25 @ big-endian page tables
|
||||
#endif
|
||||
bl __common_mmu_cache_on
|
||||
mov r0, #0
|
||||
mcr p15, 0, r0, c8, c7, 0 @ flush I,D TLBs
|
||||
|
|
@ -455,6 +458,9 @@ __armv7_mmu_cache_on:
|
|||
mrc p15, 0, r0, c1, c0, 0 @ read control reg
|
||||
orr r0, r0, #0x5000 @ I-cache enable, RR cache replacement
|
||||
orr r0, r0, #0x003c @ write buffer
|
||||
#ifdef CONFIG_CPU_ENDIAN_BE8
|
||||
orr r0, r0, #1 << 25 @ big-endian page tables
|
||||
#endif
|
||||
orrne r0, r0, #1 @ MMU enabled
|
||||
movne r1, #-1
|
||||
mcrne p15, 0, r3, c2, c0, 0 @ load page table pointer
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue