Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless
This commit is contained in:
John W. Linville
Коммит
8065248069
|
|
@ -55,7 +55,7 @@ What: /sys/bus/usb/drivers/usbtmc/devices/*/auto_abort
|
|||
Date: August 2008
|
||||
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
Description:
|
||||
This file determines if the the transaction of the USB TMC
|
||||
This file determines if the transaction of the USB TMC
|
||||
device is to be automatically aborted if there is any error.
|
||||
For more details about this, please see the document,
|
||||
"Universal Serial Bus Test and Measurement Class Specification
|
||||
|
|
|
|||
|
|
@ -0,0 +1,16 @@
|
|||
What: /sys/kernel/debug/olpc-ec/cmd
|
||||
Date: Dec 2011
|
||||
KernelVersion: 3.4
|
||||
Contact: devel@lists.laptop.org
|
||||
Description:
|
||||
|
||||
A generic interface for executing OLPC Embedded Controller commands and
|
||||
reading their responses.
|
||||
|
||||
To execute a command, write data with the format: CC:N A A A A
|
||||
CC is the (hex) command, N is the count of expected reply bytes, and A A A A
|
||||
are optional (hex) arguments.
|
||||
|
||||
To read the response (if any), read from the generic node after executing
|
||||
a command. Hex reply bytes will be returned, *whether or not* they came from
|
||||
the immediately previous command.
|
||||
|
|
@ -0,0 +1,25 @@
|
|||
What: /sys/block/dm-<num>/dm/name
|
||||
Date: January 2009
|
||||
KernelVersion: 2.6.29
|
||||
Contact: dm-devel@redhat.com
|
||||
Description: Device-mapper device name.
|
||||
Read-only string containing mapped device name.
|
||||
Users: util-linux, device-mapper udev rules
|
||||
|
||||
What: /sys/block/dm-<num>/dm/uuid
|
||||
Date: January 2009
|
||||
KernelVersion: 2.6.29
|
||||
Contact: dm-devel@redhat.com
|
||||
Description: Device-mapper device UUID.
|
||||
Read-only string containing DM-UUID or empty string
|
||||
if DM-UUID is not set.
|
||||
Users: util-linux, device-mapper udev rules
|
||||
|
||||
What: /sys/block/dm-<num>/dm/suspended
|
||||
Date: June 2009
|
||||
KernelVersion: 2.6.31
|
||||
Contact: dm-devel@redhat.com
|
||||
Description: Device-mapper device suspend state.
|
||||
Contains the value 1 while the device is suspended.
|
||||
Otherwise it contains 0. Read-only attribute.
|
||||
Users: util-linux, device-mapper udev rules
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
Where: /sys/bus/event_source/devices/<dev>/format
|
||||
Date: January 2012
|
||||
Kernel Version: 3.3
|
||||
Contact: Jiri Olsa <jolsa@redhat.com>
|
||||
Description:
|
||||
Attribute group to describe the magic bits that go into
|
||||
perf_event_attr::config[012] for a particular pmu.
|
||||
Each attribute of this group defines the 'hardware' bitmask
|
||||
we want to export, so that userspace can deal with sane
|
||||
name/value pairs.
|
||||
|
||||
Example: 'config1:1,6-10,44'
|
||||
Defines contents of attribute that occupies bits 1,6-10,44 of
|
||||
perf_event_attr::config1.
|
||||
|
|
@ -17,3 +17,21 @@ Description: Some Samsung laptops have different "performance levels"
|
|||
Specifically, not all support the "overclock" option,
|
||||
and it's still unknown if this value even changes
|
||||
anything, other than making the user feel a bit better.
|
||||
|
||||
What: /sys/devices/platform/samsung/battery_life_extender
|
||||
Date: December 1, 2011
|
||||
KernelVersion: 3.3
|
||||
Contact: Corentin Chary <corentin.chary@gmail.com>
|
||||
Description: Max battery charge level can be modified, battery cycle
|
||||
life can be extended by reducing the max battery charge
|
||||
level.
|
||||
0 means normal battery mode (100% charge)
|
||||
1 means battery life extender mode (80% charge)
|
||||
|
||||
What: /sys/devices/platform/samsung/usb_charge
|
||||
Date: December 1, 2011
|
||||
KernelVersion: 3.3
|
||||
Contact: Corentin Chary <corentin.chary@gmail.com>
|
||||
Description: Use your USB ports to charge devices, even
|
||||
when your laptop is powered off.
|
||||
1 means enabled, 0 means disabled.
|
||||
|
|
|
|||
|
|
@ -1,3 +1,23 @@
|
|||
What: /sys/firmware/acpi/bgrt/
|
||||
Date: January 2012
|
||||
Contact: Matthew Garrett <mjg@redhat.com>
|
||||
Description:
|
||||
The BGRT is an ACPI 5.0 feature that allows the OS
|
||||
to obtain a copy of the firmware boot splash and
|
||||
some associated metadata. This is intended to be used
|
||||
by boot splash applications in order to interact with
|
||||
the firmware boot splash in order to avoid jarring
|
||||
transitions.
|
||||
|
||||
image: The image bitmap. Currently a 32-bit BMP.
|
||||
status: 1 if the image is valid, 0 if firmware invalidated it.
|
||||
type: 0 indicates image is in BMP format.
|
||||
version: The version of the BGRT. Currently 1.
|
||||
xoffset: The number of pixels between the left of the screen
|
||||
and the left edge of the image.
|
||||
yoffset: The number of pixels between the top of the screen
|
||||
and the top edge of the image.
|
||||
|
||||
What: /sys/firmware/acpi/interrupts/
|
||||
Date: February 2008
|
||||
Contact: Len Brown <lenb@kernel.org>
|
||||
|
|
|
|||
|
|
@ -793,6 +793,35 @@ own custom mode, or may have some other magic method for making indentation
|
|||
work correctly.
|
||||
|
||||
|
||||
Chapter 19: Inline assembly
|
||||
|
||||
In architecture-specific code, you may need to use inline assembly to interface
|
||||
with CPU or platform functionality. Don't hesitate to do so when necessary.
|
||||
However, don't use inline assembly gratuitously when C can do the job. You can
|
||||
and should poke hardware from C when possible.
|
||||
|
||||
Consider writing simple helper functions that wrap common bits of inline
|
||||
assembly, rather than repeatedly writing them with slight variations. Remember
|
||||
that inline assembly can use C parameters.
|
||||
|
||||
Large, non-trivial assembly functions should go in .S files, with corresponding
|
||||
C prototypes defined in C header files. The C prototypes for assembly
|
||||
functions should use "asmlinkage".
|
||||
|
||||
You may need to mark your asm statement as volatile, to prevent GCC from
|
||||
removing it if GCC doesn't notice any side effects. You don't always need to
|
||||
do so, though, and doing so unnecessarily can limit optimization.
|
||||
|
||||
When writing a single inline assembly statement containing multiple
|
||||
instructions, put each instruction on a separate line in a separate quoted
|
||||
string, and end each string except the last with \n\t to properly indent the
|
||||
next instruction in the assembly output:
|
||||
|
||||
asm ("magic %reg1, #42\n\t"
|
||||
"more_magic %reg2, %reg3"
|
||||
: /* outputs */ : /* inputs */ : /* clobbers */);
|
||||
|
||||
|
||||
|
||||
Appendix I: References
|
||||
|
||||
|
|
|
|||
|
|
@ -31,3 +31,21 @@ may be weakly ordered, that is that reads and writes may pass each other.
|
|||
Since it is optional for platforms to implement DMA_ATTR_WEAK_ORDERING,
|
||||
those that do not will simply ignore the attribute and exhibit default
|
||||
behavior.
|
||||
|
||||
DMA_ATTR_WRITE_COMBINE
|
||||
----------------------
|
||||
|
||||
DMA_ATTR_WRITE_COMBINE specifies that writes to the mapping may be
|
||||
buffered to improve performance.
|
||||
|
||||
Since it is optional for platforms to implement DMA_ATTR_WRITE_COMBINE,
|
||||
those that do not will simply ignore the attribute and exhibit default
|
||||
behavior.
|
||||
|
||||
DMA_ATTR_NON_CONSISTENT
|
||||
-----------------------
|
||||
|
||||
DMA_ATTR_NON_CONSISTENT lets the platform to choose to return either
|
||||
consistent or non-consistent memory as it sees fit. By using this API,
|
||||
you are guaranteeing to the platform that you have all the correct and
|
||||
necessary sync points for this memory in the driver.
|
||||
|
|
|
|||
|
|
@ -446,4 +446,21 @@ X!Idrivers/video/console/fonts.c
|
|||
!Edrivers/i2c/i2c-core.c
|
||||
</chapter>
|
||||
|
||||
<chapter id="hsi">
|
||||
<title>High Speed Synchronous Serial Interface (HSI)</title>
|
||||
|
||||
<para>
|
||||
High Speed Synchronous Serial Interface (HSI) is a
|
||||
serial interface mainly used for connecting application
|
||||
engines (APE) with cellular modem engines (CMT) in cellular
|
||||
handsets.
|
||||
|
||||
HSI provides multiplexing for up to 16 logical channels,
|
||||
low-latency and full duplex communication.
|
||||
</para>
|
||||
|
||||
!Iinclude/linux/hsi/hsi.h
|
||||
!Edrivers/hsi/hsi.c
|
||||
</chapter>
|
||||
|
||||
</book>
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
obj-m := DocBook/ accounting/ auxdisplay/ connector/ \
|
||||
filesystems/ filesystems/configfs/ ia64/ laptops/ networking/ \
|
||||
pcmcia/ spi/ timers/ vm/ watchdog/src/
|
||||
pcmcia/ spi/ timers/ watchdog/src/
|
||||
|
|
|
|||
|
|
@ -53,6 +53,14 @@ directory apei/einj. The following files are provided.
|
|||
This file is used to set the second error parameter value. Effect of
|
||||
parameter depends on error_type specified.
|
||||
|
||||
- notrigger
|
||||
The EINJ mechanism is a two step process. First inject the error, then
|
||||
perform some actions to trigger it. Setting "notrigger" to 1 skips the
|
||||
trigger phase, which *may* allow the user to cause the error in some other
|
||||
context by a simple access to the cpu, memory location, or device that is
|
||||
the target of the error injection. Whether this actually works depends
|
||||
on what operations the BIOS actually includes in the trigger phase.
|
||||
|
||||
BIOS versions based in the ACPI 4.0 specification have limited options
|
||||
to control where the errors are injected. Your BIOS may support an
|
||||
extension (enabled with the param_extension=1 module parameter, or
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ CREATING DEVICE NODES
|
|||
sh Documentation/aoe/mkshelf.sh /dev/etherd 0
|
||||
|
||||
There is also an autoload script that shows how to edit
|
||||
/etc/modprobe.conf to ensure that the aoe module is loaded when
|
||||
/etc/modprobe.d/aoe.conf to ensure that the aoe module is loaded when
|
||||
necessary.
|
||||
|
||||
USING DEVICE NODES
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
#!/bin/sh
|
||||
# set aoe to autoload by installing the
|
||||
# aliases in /etc/modprobe.conf
|
||||
# aliases in /etc/modprobe.d/
|
||||
|
||||
f=/etc/modprobe.conf
|
||||
f=/etc/modprobe.d/aoe.conf
|
||||
|
||||
if test ! -r $f || test ! -w $f; then
|
||||
echo "cannot configure $f for module autoloading" 1>&2
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ you can put:
|
|||
|
||||
options floppy omnibook messages
|
||||
|
||||
in /etc/modprobe.conf.
|
||||
in a configuration file in /etc/modprobe.d/.
|
||||
|
||||
|
||||
The floppy driver related options are:
|
||||
|
|
|
|||
|
|
@ -217,7 +217,7 @@ and name space for cpusets, with a minimum of additional kernel code.
|
|||
|
||||
The cpus and mems files in the root (top_cpuset) cpuset are
|
||||
read-only. The cpus file automatically tracks the value of
|
||||
cpu_online_map using a CPU hotplug notifier, and the mems file
|
||||
cpu_online_mask using a CPU hotplug notifier, and the mems file
|
||||
automatically tracks the value of node_states[N_HIGH_MEMORY]--i.e.,
|
||||
nodes with memory--using the cpuset_track_online_nodes() hook.
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,233 @@
|
|||
The Common Clk Framework
|
||||
Mike Turquette <mturquette@ti.com>
|
||||
|
||||
This document endeavours to explain the common clk framework details,
|
||||
and how to port a platform over to this framework. It is not yet a
|
||||
detailed explanation of the clock api in include/linux/clk.h, but
|
||||
perhaps someday it will include that information.
|
||||
|
||||
Part 1 - introduction and interface split
|
||||
|
||||
The common clk framework is an interface to control the clock nodes
|
||||
available on various devices today. This may come in the form of clock
|
||||
gating, rate adjustment, muxing or other operations. This framework is
|
||||
enabled with the CONFIG_COMMON_CLK option.
|
||||
|
||||
The interface itself is divided into two halves, each shielded from the
|
||||
details of its counterpart. First is the common definition of struct
|
||||
clk which unifies the framework-level accounting and infrastructure that
|
||||
has traditionally been duplicated across a variety of platforms. Second
|
||||
is a common implementation of the clk.h api, defined in
|
||||
drivers/clk/clk.c. Finally there is struct clk_ops, whose operations
|
||||
are invoked by the clk api implementation.
|
||||
|
||||
The second half of the interface is comprised of the hardware-specific
|
||||
callbacks registered with struct clk_ops and the corresponding
|
||||
hardware-specific structures needed to model a particular clock. For
|
||||
the remainder of this document any reference to a callback in struct
|
||||
clk_ops, such as .enable or .set_rate, implies the hardware-specific
|
||||
implementation of that code. Likewise, references to struct clk_foo
|
||||
serve as a convenient shorthand for the implementation of the
|
||||
hardware-specific bits for the hypothetical "foo" hardware.
|
||||
|
||||
Tying the two halves of this interface together is struct clk_hw, which
|
||||
is defined in struct clk_foo and pointed to within struct clk. This
|
||||
allows easy for navigation between the two discrete halves of the common
|
||||
clock interface.
|
||||
|
||||
Part 2 - common data structures and api
|
||||
|
||||
Below is the common struct clk definition from
|
||||
include/linux/clk-private.h, modified for brevity:
|
||||
|
||||
struct clk {
|
||||
const char *name;
|
||||
const struct clk_ops *ops;
|
||||
struct clk_hw *hw;
|
||||
char **parent_names;
|
||||
struct clk **parents;
|
||||
struct clk *parent;
|
||||
struct hlist_head children;
|
||||
struct hlist_node child_node;
|
||||
...
|
||||
};
|
||||
|
||||
The members above make up the core of the clk tree topology. The clk
|
||||
api itself defines several driver-facing functions which operate on
|
||||
struct clk. That api is documented in include/linux/clk.h.
|
||||
|
||||
Platforms and devices utilizing the common struct clk use the struct
|
||||
clk_ops pointer in struct clk to perform the hardware-specific parts of
|
||||
the operations defined in clk.h:
|
||||
|
||||
struct clk_ops {
|
||||
int (*prepare)(struct clk_hw *hw);
|
||||
void (*unprepare)(struct clk_hw *hw);
|
||||
int (*enable)(struct clk_hw *hw);
|
||||
void (*disable)(struct clk_hw *hw);
|
||||
int (*is_enabled)(struct clk_hw *hw);
|
||||
unsigned long (*recalc_rate)(struct clk_hw *hw,
|
||||
unsigned long parent_rate);
|
||||
long (*round_rate)(struct clk_hw *hw, unsigned long,
|
||||
unsigned long *);
|
||||
int (*set_parent)(struct clk_hw *hw, u8 index);
|
||||
u8 (*get_parent)(struct clk_hw *hw);
|
||||
int (*set_rate)(struct clk_hw *hw, unsigned long);
|
||||
void (*init)(struct clk_hw *hw);
|
||||
};
|
||||
|
||||
Part 3 - hardware clk implementations
|
||||
|
||||
The strength of the common struct clk comes from its .ops and .hw pointers
|
||||
which abstract the details of struct clk from the hardware-specific bits, and
|
||||
vice versa. To illustrate consider the simple gateable clk implementation in
|
||||
drivers/clk/clk-gate.c:
|
||||
|
||||
struct clk_gate {
|
||||
struct clk_hw hw;
|
||||
void __iomem *reg;
|
||||
u8 bit_idx;
|
||||
...
|
||||
};
|
||||
|
||||
struct clk_gate contains struct clk_hw hw as well as hardware-specific
|
||||
knowledge about which register and bit controls this clk's gating.
|
||||
Nothing about clock topology or accounting, such as enable_count or
|
||||
notifier_count, is needed here. That is all handled by the common
|
||||
framework code and struct clk.
|
||||
|
||||
Let's walk through enabling this clk from driver code:
|
||||
|
||||
struct clk *clk;
|
||||
clk = clk_get(NULL, "my_gateable_clk");
|
||||
|
||||
clk_prepare(clk);
|
||||
clk_enable(clk);
|
||||
|
||||
The call graph for clk_enable is very simple:
|
||||
|
||||
clk_enable(clk);
|
||||
clk->ops->enable(clk->hw);
|
||||
[resolves to...]
|
||||
clk_gate_enable(hw);
|
||||
[resolves struct clk gate with to_clk_gate(hw)]
|
||||
clk_gate_set_bit(gate);
|
||||
|
||||
And the definition of clk_gate_set_bit:
|
||||
|
||||
static void clk_gate_set_bit(struct clk_gate *gate)
|
||||
{
|
||||
u32 reg;
|
||||
|
||||
reg = __raw_readl(gate->reg);
|
||||
reg |= BIT(gate->bit_idx);
|
||||
writel(reg, gate->reg);
|
||||
}
|
||||
|
||||
Note that to_clk_gate is defined as:
|
||||
|
||||
#define to_clk_gate(_hw) container_of(_hw, struct clk_gate, clk)
|
||||
|
||||
This pattern of abstraction is used for every clock hardware
|
||||
representation.
|
||||
|
||||
Part 4 - supporting your own clk hardware
|
||||
|
||||
When implementing support for a new type of clock it only necessary to
|
||||
include the following header:
|
||||
|
||||
#include <linux/clk-provider.h>
|
||||
|
||||
include/linux/clk.h is included within that header and clk-private.h
|
||||
must never be included from the code which implements the operations for
|
||||
a clock. More on that below in Part 5.
|
||||
|
||||
To construct a clk hardware structure for your platform you must define
|
||||
the following:
|
||||
|
||||
struct clk_foo {
|
||||
struct clk_hw hw;
|
||||
... hardware specific data goes here ...
|
||||
};
|
||||
|
||||
To take advantage of your data you'll need to support valid operations
|
||||
for your clk:
|
||||
|
||||
struct clk_ops clk_foo_ops {
|
||||
.enable = &clk_foo_enable;
|
||||
.disable = &clk_foo_disable;
|
||||
};
|
||||
|
||||
Implement the above functions using container_of:
|
||||
|
||||
#define to_clk_foo(_hw) container_of(_hw, struct clk_foo, hw)
|
||||
|
||||
int clk_foo_enable(struct clk_hw *hw)
|
||||
{
|
||||
struct clk_foo *foo;
|
||||
|
||||
foo = to_clk_foo(hw);
|
||||
|
||||
... perform magic on foo ...
|
||||
|
||||
return 0;
|
||||
};
|
||||
|
||||
Below is a matrix detailing which clk_ops are mandatory based upon the
|
||||
hardware capbilities of that clock. A cell marked as "y" means
|
||||
mandatory, a cell marked as "n" implies that either including that
|
||||
callback is invalid or otherwise uneccesary. Empty cells are either
|
||||
optional or must be evaluated on a case-by-case basis.
|
||||
|
||||
clock hardware characteristics
|
||||
-----------------------------------------------------------
|
||||
| gate | change rate | single parent | multiplexer | root |
|
||||
|------|-------------|---------------|-------------|------|
|
||||
.prepare | | | | | |
|
||||
.unprepare | | | | | |
|
||||
| | | | | |
|
||||
.enable | y | | | | |
|
||||
.disable | y | | | | |
|
||||
.is_enabled | y | | | | |
|
||||
| | | | | |
|
||||
.recalc_rate | | y | | | |
|
||||
.round_rate | | y | | | |
|
||||
.set_rate | | y | | | |
|
||||
| | | | | |
|
||||
.set_parent | | | n | y | n |
|
||||
.get_parent | | | n | y | n |
|
||||
| | | | | |
|
||||
.init | | | | | |
|
||||
-----------------------------------------------------------
|
||||
|
||||
Finally, register your clock at run-time with a hardware-specific
|
||||
registration function. This function simply populates struct clk_foo's
|
||||
data and then passes the common struct clk parameters to the framework
|
||||
with a call to:
|
||||
|
||||
clk_register(...)
|
||||
|
||||
See the basic clock types in drivers/clk/clk-*.c for examples.
|
||||
|
||||
Part 5 - static initialization of clock data
|
||||
|
||||
For platforms with many clocks (often numbering into the hundreds) it
|
||||
may be desirable to statically initialize some clock data. This
|
||||
presents a problem since the definition of struct clk should be hidden
|
||||
from everyone except for the clock core in drivers/clk/clk.c.
|
||||
|
||||
To get around this problem struct clk's definition is exposed in
|
||||
include/linux/clk-private.h along with some macros for more easily
|
||||
initializing instances of the basic clock types. These clocks must
|
||||
still be initialized with the common clock framework via a call to
|
||||
__clk_init.
|
||||
|
||||
clk-private.h must NEVER be included by code which implements struct
|
||||
clk_ops callbacks, nor must it be included by any logic which pokes
|
||||
around inside of struct clk at run-time. To do so is a layering
|
||||
violation.
|
||||
|
||||
To better enforce this policy, always follow this simple rule: any
|
||||
statically initialized clock data MUST be defined in a separate file
|
||||
from the logic that implements its ops. Basically separate the logic
|
||||
from the data and all is well.
|
||||
|
|
@ -47,7 +47,7 @@ maxcpus=n Restrict boot time cpus to n. Say if you have 4 cpus, using
|
|||
other cpus later online, read FAQ's for more info.
|
||||
|
||||
additional_cpus=n (*) Use this to limit hotpluggable cpus. This option sets
|
||||
cpu_possible_map = cpu_present_map + additional_cpus
|
||||
cpu_possible_mask = cpu_present_mask + additional_cpus
|
||||
|
||||
cede_offline={"off","on"} Use this option to disable/enable putting offlined
|
||||
processors to an extended H_CEDE state on
|
||||
|
|
@ -64,11 +64,11 @@ should only rely on this to count the # of cpus, but *MUST* not rely
|
|||
on the apicid values in those tables for disabled apics. In the event
|
||||
BIOS doesn't mark such hot-pluggable cpus as disabled entries, one could
|
||||
use this parameter "additional_cpus=x" to represent those cpus in the
|
||||
cpu_possible_map.
|
||||
cpu_possible_mask.
|
||||
|
||||
possible_cpus=n [s390,x86_64] use this to set hotpluggable cpus.
|
||||
This option sets possible_cpus bits in
|
||||
cpu_possible_map. Thus keeping the numbers of bits set
|
||||
cpu_possible_mask. Thus keeping the numbers of bits set
|
||||
constant even if the machine gets rebooted.
|
||||
|
||||
CPU maps and such
|
||||
|
|
@ -76,7 +76,7 @@ CPU maps and such
|
|||
[More on cpumaps and primitive to manipulate, please check
|
||||
include/linux/cpumask.h that has more descriptive text.]
|
||||
|
||||
cpu_possible_map: Bitmap of possible CPUs that can ever be available in the
|
||||
cpu_possible_mask: Bitmap of possible CPUs that can ever be available in the
|
||||
system. This is used to allocate some boot time memory for per_cpu variables
|
||||
that aren't designed to grow/shrink as CPUs are made available or removed.
|
||||
Once set during boot time discovery phase, the map is static, i.e no bits
|
||||
|
|
@ -84,13 +84,13 @@ are added or removed anytime. Trimming it accurately for your system needs
|
|||
upfront can save some boot time memory. See below for how we use heuristics
|
||||
in x86_64 case to keep this under check.
|
||||
|
||||
cpu_online_map: Bitmap of all CPUs currently online. Its set in __cpu_up()
|
||||
cpu_online_mask: Bitmap of all CPUs currently online. Its set in __cpu_up()
|
||||
after a cpu is available for kernel scheduling and ready to receive
|
||||
interrupts from devices. Its cleared when a cpu is brought down using
|
||||
__cpu_disable(), before which all OS services including interrupts are
|
||||
migrated to another target CPU.
|
||||
|
||||
cpu_present_map: Bitmap of CPUs currently present in the system. Not all
|
||||
cpu_present_mask: Bitmap of CPUs currently present in the system. Not all
|
||||
of them may be online. When physical hotplug is processed by the relevant
|
||||
subsystem (e.g ACPI) can change and new bit either be added or removed
|
||||
from the map depending on the event is hot-add/hot-remove. There are currently
|
||||
|
|
@ -99,22 +99,22 @@ at which time hotplug is disabled.
|
|||
|
||||
You really dont need to manipulate any of the system cpu maps. They should
|
||||
be read-only for most use. When setting up per-cpu resources almost always use
|
||||
cpu_possible_map/for_each_possible_cpu() to iterate.
|
||||
cpu_possible_mask/for_each_possible_cpu() to iterate.
|
||||
|
||||
Never use anything other than cpumask_t to represent bitmap of CPUs.
|
||||
|
||||
#include <linux/cpumask.h>
|
||||
|
||||
for_each_possible_cpu - Iterate over cpu_possible_map
|
||||
for_each_online_cpu - Iterate over cpu_online_map
|
||||
for_each_present_cpu - Iterate over cpu_present_map
|
||||
for_each_possible_cpu - Iterate over cpu_possible_mask
|
||||
for_each_online_cpu - Iterate over cpu_online_mask
|
||||
for_each_present_cpu - Iterate over cpu_present_mask
|
||||
for_each_cpu_mask(x,mask) - Iterate over some random collection of cpu mask.
|
||||
|
||||
#include <linux/cpu.h>
|
||||
get_online_cpus() and put_online_cpus():
|
||||
|
||||
The above calls are used to inhibit cpu hotplug operations. While the
|
||||
cpu_hotplug.refcount is non zero, the cpu_online_map will not change.
|
||||
cpu_hotplug.refcount is non zero, the cpu_online_mask will not change.
|
||||
If you merely need to avoid cpus going away, you could also use
|
||||
preempt_disable() and preempt_enable() for those sections.
|
||||
Just remember the critical section cannot call any
|
||||
|
|
|
|||
|
|
@ -36,6 +36,7 @@ drwxr-xr-x 2 root root 0 Feb 8 10:42 state3
|
|||
/sys/devices/system/cpu/cpu0/cpuidle/state0:
|
||||
total 0
|
||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 desc
|
||||
-rw-r--r-- 1 root root 4096 Feb 8 10:42 disable
|
||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 latency
|
||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 name
|
||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 power
|
||||
|
|
@ -45,6 +46,7 @@ total 0
|
|||
/sys/devices/system/cpu/cpu0/cpuidle/state1:
|
||||
total 0
|
||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 desc
|
||||
-rw-r--r-- 1 root root 4096 Feb 8 10:42 disable
|
||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 latency
|
||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 name
|
||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 power
|
||||
|
|
@ -54,6 +56,7 @@ total 0
|
|||
/sys/devices/system/cpu/cpu0/cpuidle/state2:
|
||||
total 0
|
||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 desc
|
||||
-rw-r--r-- 1 root root 4096 Feb 8 10:42 disable
|
||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 latency
|
||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 name
|
||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 power
|
||||
|
|
@ -63,6 +66,7 @@ total 0
|
|||
/sys/devices/system/cpu/cpu0/cpuidle/state3:
|
||||
total 0
|
||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 desc
|
||||
-rw-r--r-- 1 root root 4096 Feb 8 10:42 disable
|
||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 latency
|
||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 name
|
||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 power
|
||||
|
|
@ -72,6 +76,7 @@ total 0
|
|||
|
||||
|
||||
* desc : Small description about the idle state (string)
|
||||
* disable : Option to disable this idle state (bool)
|
||||
* latency : Latency to exit out of this idle state (in microseconds)
|
||||
* name : Name of the idle state (string)
|
||||
* power : Power consumed while in this idle state (in milliwatts)
|
||||
|
|
|
|||
|
|
@ -75,10 +75,12 @@ less sharing than average you'll need a larger-than-average metadata device.
|
|||
|
||||
As a guide, we suggest you calculate the number of bytes to use in the
|
||||
metadata device as 48 * $data_dev_size / $data_block_size but round it up
|
||||
to 2MB if the answer is smaller. The largest size supported is 16GB.
|
||||
to 2MB if the answer is smaller. If you're creating large numbers of
|
||||
snapshots which are recording large amounts of change, you may find you
|
||||
need to increase this.
|
||||
|
||||
If you're creating large numbers of snapshots which are recording large
|
||||
amounts of change, you may need find you need to increase this.
|
||||
The largest size supported is 16GB: If the device is larger,
|
||||
a warning will be issued and the excess space will not be used.
|
||||
|
||||
Reloading a pool table
|
||||
----------------------
|
||||
|
|
@ -167,6 +169,38 @@ ii) Using an internal snapshot.
|
|||
|
||||
dmsetup create snap --table "0 2097152 thin /dev/mapper/pool 1"
|
||||
|
||||
External snapshots
|
||||
------------------
|
||||
|
||||
You can use an external _read only_ device as an origin for a
|
||||
thinly-provisioned volume. Any read to an unprovisioned area of the
|
||||
thin device will be passed through to the origin. Writes trigger
|
||||
the allocation of new blocks as usual.
|
||||
|
||||
One use case for this is VM hosts that want to run guests on
|
||||
thinly-provisioned volumes but have the base image on another device
|
||||
(possibly shared between many VMs).
|
||||
|
||||
You must not write to the origin device if you use this technique!
|
||||
Of course, you may write to the thin device and take internal snapshots
|
||||
of the thin volume.
|
||||
|
||||
i) Creating a snapshot of an external device
|
||||
|
||||
This is the same as creating a thin device.
|
||||
You don't mention the origin at this stage.
|
||||
|
||||
dmsetup message /dev/mapper/pool 0 "create_thin 0"
|
||||
|
||||
ii) Using a snapshot of an external device.
|
||||
|
||||
Append an extra parameter to the thin target specifying the origin:
|
||||
|
||||
dmsetup create snap --table "0 2097152 thin /dev/mapper/pool 0 /dev/image"
|
||||
|
||||
N.B. All descendants (internal snapshots) of this snapshot require the
|
||||
same extra origin parameter.
|
||||
|
||||
Deactivation
|
||||
------------
|
||||
|
||||
|
|
@ -189,7 +223,13 @@ i) Constructor
|
|||
<low water mark (blocks)> [<number of feature args> [<arg>]*]
|
||||
|
||||
Optional feature arguments:
|
||||
- 'skip_block_zeroing': skips the zeroing of newly-provisioned blocks.
|
||||
|
||||
skip_block_zeroing: Skip the zeroing of newly-provisioned blocks.
|
||||
|
||||
ignore_discard: Disable discard support.
|
||||
|
||||
no_discard_passdown: Don't pass discards down to the underlying
|
||||
data device, but just remove the mapping.
|
||||
|
||||
Data block size must be between 64KB (128 sectors) and 1GB
|
||||
(2097152 sectors) inclusive.
|
||||
|
|
@ -237,16 +277,6 @@ iii) Messages
|
|||
|
||||
Deletes a thin device. Irreversible.
|
||||
|
||||
trim <dev id> <new size in sectors>
|
||||
|
||||
Delete mappings from the end of a thin device. Irreversible.
|
||||
You might want to use this if you're reducing the size of
|
||||
your thinly-provisioned device. In many cases, due to the
|
||||
sharing of blocks between devices, it is not possible to
|
||||
determine in advance how much space 'trim' will release. (In
|
||||
future a userspace tool might be able to perform this
|
||||
calculation.)
|
||||
|
||||
set_transaction_id <current id> <new id>
|
||||
|
||||
Userland volume managers, such as LVM, need a way to
|
||||
|
|
@ -262,7 +292,7 @@ iii) Messages
|
|||
|
||||
i) Constructor
|
||||
|
||||
thin <pool dev> <dev id>
|
||||
thin <pool dev> <dev id> [<external origin dev>]
|
||||
|
||||
pool dev:
|
||||
the thin-pool device, e.g. /dev/mapper/my_pool or 253:0
|
||||
|
|
@ -271,6 +301,11 @@ i) Constructor
|
|||
the internal device identifier of the device to be
|
||||
activated.
|
||||
|
||||
external origin dev:
|
||||
an optional block device outside the pool to be treated as a
|
||||
read-only snapshot origin: reads to unprovisioned areas of the
|
||||
thin target will be mapped to this device.
|
||||
|
||||
The pool doesn't store any size against the thin devices. If you
|
||||
load a thin target that is smaller than you've been using previously,
|
||||
then you'll have no access to blocks mapped beyond the end. If you
|
||||
|
|
|
|||
|
|
@ -0,0 +1,194 @@
|
|||
dm-verity
|
||||
==========
|
||||
|
||||
Device-Mapper's "verity" target provides transparent integrity checking of
|
||||
block devices using a cryptographic digest provided by the kernel crypto API.
|
||||
This target is read-only.
|
||||
|
||||
Construction Parameters
|
||||
=======================
|
||||
<version> <dev> <hash_dev> <hash_start>
|
||||
<data_block_size> <hash_block_size>
|
||||
<num_data_blocks> <hash_start_block>
|
||||
<algorithm> <digest> <salt>
|
||||
|
||||
<version>
|
||||
This is the version number of the on-disk format.
|
||||
|
||||
0 is the original format used in the Chromium OS.
|
||||
The salt is appended when hashing, digests are stored continuously and
|
||||
the rest of the block is padded with zeros.
|
||||
|
||||
1 is the current format that should be used for new devices.
|
||||
The salt is prepended when hashing and each digest is
|
||||
padded with zeros to the power of two.
|
||||
|
||||
<dev>
|
||||
This is the device containing the data the integrity of which needs to be
|
||||
checked. It may be specified as a path, like /dev/sdaX, or a device number,
|
||||
<major>:<minor>.
|
||||
|
||||
<hash_dev>
|
||||
This is the device that that supplies the hash tree data. It may be
|
||||
specified similarly to the device path and may be the same device. If the
|
||||
same device is used, the hash_start should be outside of the dm-verity
|
||||
configured device size.
|
||||
|
||||
<data_block_size>
|
||||
The block size on a data device. Each block corresponds to one digest on
|
||||
the hash device.
|
||||
|
||||
<hash_block_size>
|
||||
The size of a hash block.
|
||||
|
||||
<num_data_blocks>
|
||||
The number of data blocks on the data device. Additional blocks are
|
||||
inaccessible. You can place hashes to the same partition as data, in this
|
||||
case hashes are placed after <num_data_blocks>.
|
||||
|
||||
<hash_start_block>
|
||||
This is the offset, in <hash_block_size>-blocks, from the start of hash_dev
|
||||
to the root block of the hash tree.
|
||||
|
||||
<algorithm>
|
||||
The cryptographic hash algorithm used for this device. This should
|
||||
be the name of the algorithm, like "sha1".
|
||||
|
||||
<digest>
|
||||
The hexadecimal encoding of the cryptographic hash of the root hash block
|
||||
and the salt. This hash should be trusted as there is no other authenticity
|
||||
beyond this point.
|
||||
|
||||
<salt>
|
||||
The hexadecimal encoding of the salt value.
|
||||
|
||||
Theory of operation
|
||||
===================
|
||||
|
||||
dm-verity is meant to be setup as part of a verified boot path. This
|
||||
may be anything ranging from a boot using tboot or trustedgrub to just
|
||||
booting from a known-good device (like a USB drive or CD).
|
||||
|
||||
When a dm-verity device is configured, it is expected that the caller
|
||||
has been authenticated in some way (cryptographic signatures, etc).
|
||||
After instantiation, all hashes will be verified on-demand during
|
||||
disk access. If they cannot be verified up to the root node of the
|
||||
tree, the root hash, then the I/O will fail. This should identify
|
||||
tampering with any data on the device and the hash data.
|
||||
|
||||
Cryptographic hashes are used to assert the integrity of the device on a
|
||||
per-block basis. This allows for a lightweight hash computation on first read
|
||||
into the page cache. Block hashes are stored linearly-aligned to the nearest
|
||||
block the size of a page.
|
||||
|
||||
Hash Tree
|
||||
---------
|
||||
|
||||
Each node in the tree is a cryptographic hash. If it is a leaf node, the hash
|
||||
is of some block data on disk. If it is an intermediary node, then the hash is
|
||||
of a number of child nodes.
|
||||
|
||||
Each entry in the tree is a collection of neighboring nodes that fit in one
|
||||
block. The number is determined based on block_size and the size of the
|
||||
selected cryptographic digest algorithm. The hashes are linearly-ordered in
|
||||
this entry and any unaligned trailing space is ignored but included when
|
||||
calculating the parent node.
|
||||
|
||||
The tree looks something like:
|
||||
|
||||
alg = sha256, num_blocks = 32768, block_size = 4096
|
||||
|
||||
[ root ]
|
||||
/ . . . \
|
||||
[entry_0] [entry_1]
|
||||
/ . . . \ . . . \
|
||||
[entry_0_0] . . . [entry_0_127] . . . . [entry_1_127]
|
||||
/ ... \ / . . . \ / \
|
||||
blk_0 ... blk_127 blk_16256 blk_16383 blk_32640 . . . blk_32767
|
||||
|
||||
|
||||
On-disk format
|
||||
==============
|
||||
|
||||
Below is the recommended on-disk format. The verity kernel code does not
|
||||
read the on-disk header. It only reads the hash blocks which directly
|
||||
follow the header. It is expected that a user-space tool will verify the
|
||||
integrity of the verity_header and then call dmsetup with the correct
|
||||
parameters. Alternatively, the header can be omitted and the dmsetup
|
||||
parameters can be passed via the kernel command-line in a rooted chain
|
||||
of trust where the command-line is verified.
|
||||
|
||||
The on-disk format is especially useful in cases where the hash blocks
|
||||
are on a separate partition. The magic number allows easy identification
|
||||
of the partition contents. Alternatively, the hash blocks can be stored
|
||||
in the same partition as the data to be verified. In such a configuration
|
||||
the filesystem on the partition would be sized a little smaller than
|
||||
the full-partition, leaving room for the hash blocks.
|
||||
|
||||
struct superblock {
|
||||
uint8_t signature[8]
|
||||
"verity\0\0";
|
||||
|
||||
uint8_t version;
|
||||
1 - current format
|
||||
|
||||
uint8_t data_block_bits;
|
||||
log2(data block size)
|
||||
|
||||
uint8_t hash_block_bits;
|
||||
log2(hash block size)
|
||||
|
||||
uint8_t pad1[1];
|
||||
zero padding
|
||||
|
||||
uint16_t salt_size;
|
||||
big-endian salt size
|
||||
|
||||
uint8_t pad2[2];
|
||||
zero padding
|
||||
|
||||
uint32_t data_blocks_hi;
|
||||
big-endian high 32 bits of the 64-bit number of data blocks
|
||||
|
||||
uint32_t data_blocks_lo;
|
||||
big-endian low 32 bits of the 64-bit number of data blocks
|
||||
|
||||
uint8_t algorithm[16];
|
||||
cryptographic algorithm
|
||||
|
||||
uint8_t salt[384];
|
||||
salt (the salt size is specified above)
|
||||
|
||||
uint8_t pad3[88];
|
||||
zero padding to 512-byte boundary
|
||||
}
|
||||
|
||||
Directly following the header (and with sector number padded to the next hash
|
||||
block boundary) are the hash blocks which are stored a depth at a time
|
||||
(starting from the root), sorted in order of increasing index.
|
||||
|
||||
Status
|
||||
======
|
||||
V (for Valid) is returned if every check performed so far was valid.
|
||||
If any check failed, C (for Corruption) is returned.
|
||||
|
||||
Example
|
||||
=======
|
||||
|
||||
Setup a device:
|
||||
dmsetup create vroot --table \
|
||||
"0 2097152 "\
|
||||
"verity 1 /dev/sda1 /dev/sda2 4096 4096 2097152 1 "\
|
||||
"4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076 "\
|
||||
"1234000000000000000000000000000000000000000000000000000000000000"
|
||||
|
||||
A command line tool veritysetup is available to compute or verify
|
||||
the hash tree or activate the kernel driver. This is available from
|
||||
the LVM2 upstream repository and may be supplied as a package called
|
||||
device-mapper-verity-tools:
|
||||
git://sources.redhat.com/git/lvm2
|
||||
http://sourceware.org/git/?p=lvm2.git
|
||||
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/verity?cvsroot=lvm2
|
||||
|
||||
veritysetup -a vroot /dev/sda1 /dev/sda2 \
|
||||
4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076
|
||||
|
|
@ -30,3 +30,63 @@ One interrupt per TC channel in a TC block:
|
|||
reg = <0xfffdc000 0x100>;
|
||||
interrupts = <26 4 27 4 28 4>;
|
||||
};
|
||||
|
||||
RSTC Reset Controller required properties:
|
||||
- compatible: Should be "atmel,<chip>-rstc".
|
||||
<chip> can be "at91sam9260" or "at91sam9g45"
|
||||
- reg: Should contain registers location and length
|
||||
|
||||
Example:
|
||||
|
||||
rstc@fffffd00 {
|
||||
compatible = "atmel,at91sam9260-rstc";
|
||||
reg = <0xfffffd00 0x10>;
|
||||
};
|
||||
|
||||
RAMC SDRAM/DDR Controller required properties:
|
||||
- compatible: Should be "atmel,at91sam9260-sdramc",
|
||||
"atmel,at91sam9g45-ddramc",
|
||||
- reg: Should contain registers location and length
|
||||
For at91sam9263 and at91sam9g45 you must specify 2 entries.
|
||||
|
||||
Examples:
|
||||
|
||||
ramc0: ramc@ffffe800 {
|
||||
compatible = "atmel,at91sam9g45-ddramc";
|
||||
reg = <0xffffe800 0x200>;
|
||||
};
|
||||
|
||||
ramc0: ramc@ffffe400 {
|
||||
compatible = "atmel,at91sam9g45-ddramc";
|
||||
reg = <0xffffe400 0x200
|
||||
0xffffe600 0x200>;
|
||||
};
|
||||
|
||||
SHDWC Shutdown Controller
|
||||
|
||||
required properties:
|
||||
- compatible: Should be "atmel,<chip>-shdwc".
|
||||
<chip> can be "at91sam9260", "at91sam9rl" or "at91sam9x5".
|
||||
- reg: Should contain registers location and length
|
||||
|
||||
optional properties:
|
||||
- atmel,wakeup-mode: String, operation mode of the wakeup mode.
|
||||
Supported values are: "none", "high", "low", "any".
|
||||
- atmel,wakeup-counter: Counter on Wake-up 0 (between 0x0 and 0xf).
|
||||
|
||||
optional at91sam9260 properties:
|
||||
- atmel,wakeup-rtt-timer: boolean to enable Real-time Timer Wake-up.
|
||||
|
||||
optional at91sam9rl properties:
|
||||
- atmel,wakeup-rtc-timer: boolean to enable Real-time Clock Wake-up.
|
||||
- atmel,wakeup-rtt-timer: boolean to enable Real-time Timer Wake-up.
|
||||
|
||||
optional at91sam9x5 properties:
|
||||
- atmel,wakeup-rtc-timer: boolean to enable Real-time Clock Wake-up.
|
||||
|
||||
Example:
|
||||
|
||||
rstc@fffffd00 {
|
||||
compatible = "atmel,at91sam9260-rstc";
|
||||
reg = <0xfffffd00 0x10>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -0,0 +1,11 @@
|
|||
* Power Management Controller (PMC)
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "atmel,at91rm9200-pmc"
|
||||
- reg: Should contain PMC registers location and length
|
||||
|
||||
Examples:
|
||||
pmc: pmc@fffffc00 {
|
||||
compatible = "atmel,at91rm9200-pmc";
|
||||
reg = <0xfffffc00 0x100>;
|
||||
};
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
ST SPEAr Platforms Device Tree Bindings
|
||||
---------------------------------------
|
||||
|
||||
Boards with the ST SPEAr600 SoC shall have the following properties:
|
||||
|
||||
Required root node property:
|
||||
|
||||
compatible = "st,spear600";
|
||||
|
|
@ -0,0 +1,36 @@
|
|||
OMAP GPIO controller bindings
|
||||
|
||||
Required properties:
|
||||
- compatible:
|
||||
- "ti,omap2-gpio" for OMAP2 controllers
|
||||
- "ti,omap3-gpio" for OMAP3 controllers
|
||||
- "ti,omap4-gpio" for OMAP4 controllers
|
||||
- #gpio-cells : Should be two.
|
||||
- first cell is the pin number
|
||||
- second cell is used to specify optional parameters (unused)
|
||||
- gpio-controller : Marks the device node as a GPIO controller.
|
||||
- #interrupt-cells : Should be 2.
|
||||
- interrupt-controller: Mark the device node as an interrupt controller
|
||||
The first cell is the GPIO number.
|
||||
The second cell is used to specify flags:
|
||||
bits[3:0] trigger type and level flags:
|
||||
1 = low-to-high edge triggered.
|
||||
2 = high-to-low edge triggered.
|
||||
4 = active high level-sensitive.
|
||||
8 = active low level-sensitive.
|
||||
|
||||
OMAP specific properties:
|
||||
- ti,hwmods: Name of the hwmod associated to the GPIO:
|
||||
"gpio<X>", <X> being the 1-based instance number from the HW spec
|
||||
|
||||
|
||||
Example:
|
||||
|
||||
gpio4: gpio4 {
|
||||
compatible = "ti,omap4-gpio";
|
||||
ti,hwmods = "gpio4";
|
||||
#gpio-cells = <2>;
|
||||
gpio-controller;
|
||||
#interrupt-cells = <2>;
|
||||
interrupt-controller;
|
||||
};
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
twl4030 GPIO controller bindings
|
||||
|
||||
Required properties:
|
||||
- compatible:
|
||||
- "ti,twl4030-gpio" for twl4030 GPIO controller
|
||||
- #gpio-cells : Should be two.
|
||||
- first cell is the pin number
|
||||
- second cell is used to specify optional parameters (unused)
|
||||
- gpio-controller : Marks the device node as a GPIO controller.
|
||||
- #interrupt-cells : Should be 2.
|
||||
- interrupt-controller: Mark the device node as an interrupt controller
|
||||
The first cell is the GPIO number.
|
||||
The second cell is not used.
|
||||
|
||||
Example:
|
||||
|
||||
twl_gpio: gpio {
|
||||
compatible = "ti,twl4030-gpio";
|
||||
#gpio-cells = <2>;
|
||||
gpio-controller;
|
||||
#interrupt-cells = <2>;
|
||||
interrupt-controller;
|
||||
};
|
||||
|
|
@ -0,0 +1,32 @@
|
|||
Device-Tree bindings for i2c gpio driver
|
||||
|
||||
Required properties:
|
||||
- compatible = "i2c-gpio";
|
||||
- gpios: sda and scl gpio
|
||||
|
||||
|
||||
Optional properties:
|
||||
- i2c-gpio,sda-open-drain: sda as open drain
|
||||
- i2c-gpio,scl-open-drain: scl as open drain
|
||||
- i2c-gpio,scl-output-only: scl as output only
|
||||
- i2c-gpio,delay-us: delay between GPIO operations (may depend on each platform)
|
||||
- i2c-gpio,timeout-ms: timeout to get data
|
||||
|
||||
Example nodes:
|
||||
|
||||
i2c@0 {
|
||||
compatible = "i2c-gpio";
|
||||
gpios = <&pioA 23 0 /* sda */
|
||||
&pioA 24 0 /* scl */
|
||||
>;
|
||||
i2c-gpio,sda-open-drain;
|
||||
i2c-gpio,scl-open-drain;
|
||||
i2c-gpio,delay-us = <2>; /* ~100 kHz */
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
rv3029c2@56 {
|
||||
compatible = "rv3029c2";
|
||||
reg = <0x56>;
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,48 @@
|
|||
GPIO controller on CE4100 / Sodaville SoCs
|
||||
==========================================
|
||||
|
||||
The bindings for CE4100's GPIO controller match the generic description
|
||||
which is covered by the gpio.txt file in this folder.
|
||||
|
||||
The only additional property is the intel,muxctl property which holds the
|
||||
value which is written into the MUXCNTL register.
|
||||
|
||||
There is no compatible property for now because the driver is probed via
|
||||
PCI id (vendor 0x8086 device 0x2e67).
|
||||
|
||||
The interrupt specifier consists of two cells encoded as follows:
|
||||
- <1st cell>: The interrupt-number that identifies the interrupt source.
|
||||
- <2nd cell>: The level-sense information, encoded as follows:
|
||||
4 - active high level-sensitive
|
||||
8 - active low level-sensitive
|
||||
|
||||
Example of the GPIO device and one user:
|
||||
|
||||
pcigpio: gpio@b,1 {
|
||||
/* two cells for GPIO and interrupt */
|
||||
#gpio-cells = <2>;
|
||||
#interrupt-cells = <2>;
|
||||
compatible = "pci8086,2e67.2",
|
||||
"pci8086,2e67",
|
||||
"pciclassff0000",
|
||||
"pciclassff00";
|
||||
|
||||
reg = <0x15900 0x0 0x0 0x0 0x0>;
|
||||
/* Interrupt line of the gpio device */
|
||||
interrupts = <15 1>;
|
||||
/* It is an interrupt and GPIO controller itself */
|
||||
interrupt-controller;
|
||||
gpio-controller;
|
||||
intel,muxctl = <0>;
|
||||
};
|
||||
|
||||
testuser@20 {
|
||||
compatible = "example,testuser";
|
||||
/* User the 11th GPIO line as an active high triggered
|
||||
* level interrupt
|
||||
*/
|
||||
interrupts = <11 8>;
|
||||
interrupt-parent = <&pcigpio>;
|
||||
/* Use this GPIO also with the gpio functions */
|
||||
gpios = <&pcigpio 11 0>;
|
||||
};
|
||||
|
|
@ -0,0 +1,33 @@
|
|||
* TI Highspeed MMC host controller for OMAP
|
||||
|
||||
The Highspeed MMC Host Controller on TI OMAP family
|
||||
provides an interface for MMC, SD, and SDIO types of memory cards.
|
||||
|
||||
Required properties:
|
||||
- compatible:
|
||||
Should be "ti,omap2-hsmmc", for OMAP2 controllers
|
||||
Should be "ti,omap3-hsmmc", for OMAP3 controllers
|
||||
Should be "ti,omap4-hsmmc", for OMAP4 controllers
|
||||
- ti,hwmods: Must be "mmc<n>", n is controller instance starting 1
|
||||
- reg : should contain hsmmc registers location and length
|
||||
|
||||
Optional properties:
|
||||
ti,dual-volt: boolean, supports dual voltage cards
|
||||
<supply-name>-supply: phandle to the regulator device tree node
|
||||
"supply-name" examples are "vmmc", "vmmc_aux" etc
|
||||
ti,bus-width: Number of data lines, default assumed is 1 if the property is missing.
|
||||
cd-gpios: GPIOs for card detection
|
||||
wp-gpios: GPIOs for write protection
|
||||
ti,non-removable: non-removable slot (like eMMC)
|
||||
ti,needs-special-reset: Requires a special softreset sequence
|
||||
|
||||
Example:
|
||||
mmc1: mmc@0x4809c000 {
|
||||
compatible = "ti,omap4-hsmmc";
|
||||
reg = <0x4809c000 0x400>;
|
||||
ti,hwmods = "mmc1";
|
||||
ti,dual-volt;
|
||||
ti,bus-width = <4>;
|
||||
vmmc-supply = <&vmmc>; /* phandle to regulator node */
|
||||
ti,non-removable;
|
||||
};
|
||||
|
|
@ -4,5 +4,5 @@ Required properties:
|
|||
- compatible : must be "arm,versatile-flash";
|
||||
- bank-width : width in bytes of flash interface.
|
||||
|
||||
Optional properties:
|
||||
- Subnode partition map from mtd flash binding
|
||||
The device tree may optionally contain sub-nodes describing partitions of the
|
||||
address space. See partition.txt for more detail.
|
||||
|
|
|
|||
|
|
@ -3,6 +3,9 @@
|
|||
Required properties:
|
||||
- compatible : "atmel,<model>", "atmel,<series>", "atmel,dataflash".
|
||||
|
||||
The device tree may optionally contain sub-nodes describing partitions of the
|
||||
address space. See partition.txt for more detail.
|
||||
|
||||
Example:
|
||||
|
||||
flash@1 {
|
||||
|
|
|
|||
|
|
@ -0,0 +1,41 @@
|
|||
Atmel NAND flash
|
||||
|
||||
Required properties:
|
||||
- compatible : "atmel,at91rm9200-nand".
|
||||
- reg : should specify localbus address and size used for the chip,
|
||||
and if availlable the ECC.
|
||||
- atmel,nand-addr-offset : offset for the address latch.
|
||||
- atmel,nand-cmd-offset : offset for the command latch.
|
||||
- #address-cells, #size-cells : Must be present if the device has sub-nodes
|
||||
representing partitions.
|
||||
|
||||
- gpios : specifies the gpio pins to control the NAND device. detect is an
|
||||
optional gpio and may be set to 0 if not present.
|
||||
|
||||
Optional properties:
|
||||
- nand-ecc-mode : String, operation mode of the NAND ecc mode, soft by default.
|
||||
Supported values are: "none", "soft", "hw", "hw_syndrome", "hw_oob_first",
|
||||
"soft_bch".
|
||||
- nand-bus-width : 8 or 16 bus width if not present 8
|
||||
- nand-on-flash-bbt: boolean to enable on flash bbt option if not present false
|
||||
|
||||
Examples:
|
||||
nand0: nand@40000000,0 {
|
||||
compatible = "atmel,at91rm9200-nand";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
reg = <0x40000000 0x10000000
|
||||
0xffffe800 0x200
|
||||
>;
|
||||
atmel,nand-addr-offset = <21>; /* ale */
|
||||
atmel,nand-cmd-offset = <22>; /* cle */
|
||||
nand-on-flash-bbt;
|
||||
nand-ecc-mode = "soft";
|
||||
gpios = <&pioC 13 0 /* rdy */
|
||||
&pioC 14 0 /* nce */
|
||||
0 /* cd */
|
||||
>;
|
||||
partition@0 {
|
||||
...
|
||||
};
|
||||
};
|
||||
|
|
@ -19,6 +19,10 @@ Optional properties:
|
|||
read registers (tR). Required if property "gpios" is not used
|
||||
(R/B# pins not connected).
|
||||
|
||||
Each flash chip described may optionally contain additional sub-nodes
|
||||
describing partitions of the address space. See partition.txt for more
|
||||
detail.
|
||||
|
||||
Examples:
|
||||
|
||||
upm@1,0 {
|
||||
|
|
|
|||
|
|
@ -0,0 +1,33 @@
|
|||
* FSMC NAND
|
||||
|
||||
Required properties:
|
||||
- compatible : "st,spear600-fsmc-nand"
|
||||
- reg : Address range of the mtd chip
|
||||
- reg-names: Should contain the reg names "fsmc_regs" and "nand_data"
|
||||
- st,ale-off : Chip specific offset to ALE
|
||||
- st,cle-off : Chip specific offset to CLE
|
||||
|
||||
Optional properties:
|
||||
- bank-width : Width (in bytes) of the device. If not present, the width
|
||||
defaults to 1 byte
|
||||
- nand-skip-bbtscan: Indicates the the BBT scanning should be skipped
|
||||
|
||||
Example:
|
||||
|
||||
fsmc: flash@d1800000 {
|
||||
compatible = "st,spear600-fsmc-nand";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
reg = <0xd1800000 0x1000 /* FSMC Register */
|
||||
0xd2000000 0x4000>; /* NAND Base */
|
||||
reg-names = "fsmc_regs", "nand_data";
|
||||
st,ale-off = <0x20000>;
|
||||
st,cle-off = <0x10000>;
|
||||
|
||||
bank-width = <1>;
|
||||
nand-skip-bbtscan;
|
||||
|
||||
partition@0 {
|
||||
...
|
||||
};
|
||||
};
|
||||
|
|
@ -25,6 +25,9 @@ Optional properties:
|
|||
GPIO state and before and after command byte writes, this register will be
|
||||
read to ensure that the GPIO accesses have completed.
|
||||
|
||||
The device tree may optionally contain sub-nodes describing partitions of the
|
||||
address space. See partition.txt for more detail.
|
||||
|
||||
Examples:
|
||||
|
||||
gpio-nand@1,0 {
|
||||
|
|
|
|||
|
|
@ -23,27 +23,8 @@ are defined:
|
|||
- vendor-id : Contains the flash chip's vendor id (1 byte).
|
||||
- device-id : Contains the flash chip's device id (1 byte).
|
||||
|
||||
In addition to the information on the mtd bank itself, the
|
||||
device tree may optionally contain additional information
|
||||
describing partitions of the address space. This can be
|
||||
used on platforms which have strong conventions about which
|
||||
portions of a flash are used for what purposes, but which don't
|
||||
use an on-flash partition table such as RedBoot.
|
||||
|
||||
Each partition is represented as a sub-node of the mtd device.
|
||||
Each node's name represents the name of the corresponding
|
||||
partition of the mtd device.
|
||||
|
||||
Flash partitions
|
||||
- reg : The partition's offset and size within the mtd bank.
|
||||
- label : (optional) The label / name for this partition.
|
||||
If omitted, the label is taken from the node name (excluding
|
||||
the unit address).
|
||||
- read-only : (optional) This parameter, if present, is a hint to
|
||||
Linux that this partition should only be mounted
|
||||
read-only. This is usually used for flash partitions
|
||||
containing early-boot firmware images or data which should not
|
||||
be clobbered.
|
||||
The device tree may optionally contain sub-nodes describing partitions of the
|
||||
address space. See partition.txt for more detail.
|
||||
|
||||
Example:
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,7 @@
|
|||
* MTD generic binding
|
||||
|
||||
- nand-ecc-mode : String, operation mode of the NAND ecc mode.
|
||||
Supported values are: "none", "soft", "hw", "hw_syndrome", "hw_oob_first",
|
||||
"soft_bch".
|
||||
- nand-bus-width : 8 or 16 bus width if not present 8
|
||||
- nand-on-flash-bbt: boolean to enable on flash bbt option if not present false
|
||||
|
|
@ -0,0 +1,38 @@
|
|||
Representing flash partitions in devicetree
|
||||
|
||||
Partitions can be represented by sub-nodes of an mtd device. This can be used
|
||||
on platforms which have strong conventions about which portions of a flash are
|
||||
used for what purposes, but which don't use an on-flash partition table such
|
||||
as RedBoot.
|
||||
|
||||
#address-cells & #size-cells must both be present in the mtd device and be
|
||||
equal to 1.
|
||||
|
||||
Required properties:
|
||||
- reg : The partition's offset and size within the mtd bank.
|
||||
|
||||
Optional properties:
|
||||
- label : The label / name for this partition. If omitted, the label is taken
|
||||
from the node name (excluding the unit address).
|
||||
- read-only : This parameter, if present, is a hint to Linux that this
|
||||
partition should only be mounted read-only. This is usually used for flash
|
||||
partitions containing early-boot firmware images or data which should not be
|
||||
clobbered.
|
||||
|
||||
Examples:
|
||||
|
||||
|
||||
flash@0 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
|
||||
partition@0 {
|
||||
label = "u-boot";
|
||||
reg = <0x0000000 0x100000>;
|
||||
read-only;
|
||||
};
|
||||
|
||||
uimage@100000 {
|
||||
reg = <0x0100000 0x200000>;
|
||||
};
|
||||
];
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
* SPEAr SMI
|
||||
|
||||
Required properties:
|
||||
- compatible : "st,spear600-smi"
|
||||
- reg : Address range of the mtd chip
|
||||
- #address-cells, #size-cells : Must be present if the device has sub-nodes
|
||||
representing partitions.
|
||||
- interrupt-parent: Should be the phandle for the interrupt controller
|
||||
that services interrupts for this device
|
||||
- interrupts: Should contain the STMMAC interrupts
|
||||
- clock-rate : Functional clock rate of SMI in Hz
|
||||
|
||||
Optional properties:
|
||||
- st,smi-fast-mode : Flash supports read in fast mode
|
||||
|
||||
Example:
|
||||
|
||||
smi: flash@fc000000 {
|
||||
compatible = "st,spear600-smi";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
reg = <0xfc000000 0x1000>;
|
||||
interrupt-parent = <&vic1>;
|
||||
interrupts = <12>;
|
||||
clock-rate = <50000000>; /* 50MHz */
|
||||
|
||||
flash@f8000000 {
|
||||
st,smi-fast-mode;
|
||||
...
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
max17042_battery
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
Required properties :
|
||||
- compatible : "maxim,max17042"
|
||||
|
||||
Optional properties :
|
||||
- maxim,rsns-microohm : Resistance of rsns resistor in micro Ohms
|
||||
(datasheet-recommended value is 10000).
|
||||
Defining this property enables current-sense functionality.
|
||||
|
||||
Example:
|
||||
|
||||
battery-charger@36 {
|
||||
compatible = "maxim,max17042";
|
||||
reg = <0x36>;
|
||||
maxim,rsns-microohm = <10000>;
|
||||
};
|
||||
|
|
@ -0,0 +1,29 @@
|
|||
Anatop Voltage regulators
|
||||
|
||||
Required properties:
|
||||
- compatible: Must be "fsl,anatop-regulator"
|
||||
- anatop-reg-offset: Anatop MFD register offset
|
||||
- anatop-vol-bit-shift: Bit shift for the register
|
||||
- anatop-vol-bit-width: Number of bits used in the register
|
||||
- anatop-min-bit-val: Minimum value of this register
|
||||
- anatop-min-voltage: Minimum voltage of this regulator
|
||||
- anatop-max-voltage: Maximum voltage of this regulator
|
||||
|
||||
Any property defined as part of the core regulator
|
||||
binding, defined in regulator.txt, can also be used.
|
||||
|
||||
Example:
|
||||
|
||||
regulator-vddpu {
|
||||
compatible = "fsl,anatop-regulator";
|
||||
regulator-name = "vddpu";
|
||||
regulator-min-microvolt = <725000>;
|
||||
regulator-max-microvolt = <1300000>;
|
||||
regulator-always-on;
|
||||
anatop-reg-offset = <0x140>;
|
||||
anatop-vol-bit-shift = <9>;
|
||||
anatop-vol-bit-width = <5>;
|
||||
anatop-min-bit-val = <1>;
|
||||
anatop-min-voltage = <725000>;
|
||||
anatop-max-voltage = <1300000>;
|
||||
};
|
||||
|
|
@ -0,0 +1,49 @@
|
|||
Atmel SOC USB controllers
|
||||
|
||||
OHCI
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "atmel,at91rm9200-ohci" for USB controllers
|
||||
used in host mode.
|
||||
- num-ports: Number of ports.
|
||||
- atmel,vbus-gpio: If present, specifies a gpio that needs to be
|
||||
activated for the bus to be powered.
|
||||
- atmel,oc-gpio: If present, specifies a gpio that needs to be
|
||||
activated for the overcurrent detection.
|
||||
|
||||
usb0: ohci@00500000 {
|
||||
compatible = "atmel,at91rm9200-ohci", "usb-ohci";
|
||||
reg = <0x00500000 0x100000>;
|
||||
interrupts = <20 4>;
|
||||
num-ports = <2>;
|
||||
};
|
||||
|
||||
EHCI
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "atmel,at91sam9g45-ehci" for USB controllers
|
||||
used in host mode.
|
||||
|
||||
usb1: ehci@00800000 {
|
||||
compatible = "atmel,at91sam9g45-ehci", "usb-ehci";
|
||||
reg = <0x00800000 0x100000>;
|
||||
interrupts = <22 4>;
|
||||
};
|
||||
|
||||
AT91 USB device controller
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "atmel,at91rm9200-udc"
|
||||
- reg: Address and length of the register set for the device
|
||||
- interrupts: Should contain macb interrupt
|
||||
|
||||
Optional properties:
|
||||
- atmel,vbus-gpio: If present, specifies a gpio that needs to be
|
||||
activated for the bus to be powered.
|
||||
|
||||
usb1: gadget@fffa4000 {
|
||||
compatible = "atmel,at91rm9200-udc";
|
||||
reg = <0xfffa4000 0x4000>;
|
||||
interrupts = <10 4>;
|
||||
atmel,vbus-gpio = <&pioC 5 0>;
|
||||
};
|
||||
|
|
@ -11,3 +11,16 @@ Required properties :
|
|||
- phy_type : Should be one of "ulpi" or "utmi".
|
||||
- nvidia,vbus-gpio : If present, specifies a gpio that needs to be
|
||||
activated for the bus to be powered.
|
||||
|
||||
Optional properties:
|
||||
- dr_mode : dual role mode. Indicates the working mode for
|
||||
nvidia,tegra20-ehci compatible controllers. Can be "host", "peripheral",
|
||||
or "otg". Default to "host" if not defined for backward compatibility.
|
||||
host means this is a host controller
|
||||
peripheral means it is device controller
|
||||
otg means it can operate as either ("on the go")
|
||||
- nvidia,has-legacy-mode : boolean indicates whether this controller can
|
||||
operate in legacy mode (as APX 2500 / 2600). In legacy mode some
|
||||
registers are accessed through the APB_MISC base address instead of
|
||||
the USB controller. Since this is a legacy issue it probably does not
|
||||
warrant a compatible string of its own.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,412 @@
|
|||
Linux and the Device Tree
|
||||
-------------------------
|
||||
The Linux usage model for device tree data
|
||||
|
||||
Author: Grant Likely <grant.likely@secretlab.ca>
|
||||
|
||||
This article describes how Linux uses the device tree. An overview of
|
||||
the device tree data format can be found on the device tree usage page
|
||||
at devicetree.org[1].
|
||||
|
||||
[1] http://devicetree.org/Device_Tree_Usage
|
||||
|
||||
The "Open Firmware Device Tree", or simply Device Tree (DT), is a data
|
||||
structure and language for describing hardware. More specifically, it
|
||||
is a description of hardware that is readable by an operating system
|
||||
so that the operating system doesn't need to hard code details of the
|
||||
machine.
|
||||
|
||||
Structurally, the DT is a tree, or acyclic graph with named nodes, and
|
||||
nodes may have an arbitrary number of named properties encapsulating
|
||||
arbitrary data. A mechanism also exists to create arbitrary
|
||||
links from one node to another outside of the natural tree structure.
|
||||
|
||||
Conceptually, a common set of usage conventions, called 'bindings',
|
||||
is defined for how data should appear in the tree to describe typical
|
||||
hardware characteristics including data busses, interrupt lines, GPIO
|
||||
connections, and peripheral devices.
|
||||
|
||||
As much as possible, hardware is described using existing bindings to
|
||||
maximize use of existing support code, but since property and node
|
||||
names are simply text strings, it is easy to extend existing bindings
|
||||
or create new ones by defining new nodes and properties. Be wary,
|
||||
however, of creating a new binding without first doing some homework
|
||||
about what already exists. There are currently two different,
|
||||
incompatible, bindings for i2c busses that came about because the new
|
||||
binding was created without first investigating how i2c devices were
|
||||
already being enumerated in existing systems.
|
||||
|
||||
1. History
|
||||
----------
|
||||
The DT was originally created by Open Firmware as part of the
|
||||
communication method for passing data from Open Firmware to a client
|
||||
program (like to an operating system). An operating system used the
|
||||
Device Tree to discover the topology of the hardware at runtime, and
|
||||
thereby support a majority of available hardware without hard coded
|
||||
information (assuming drivers were available for all devices).
|
||||
|
||||
Since Open Firmware is commonly used on PowerPC and SPARC platforms,
|
||||
the Linux support for those architectures has for a long time used the
|
||||
Device Tree.
|
||||
|
||||
In 2005, when PowerPC Linux began a major cleanup and to merge 32-bit
|
||||
and 64-bit support, the decision was made to require DT support on all
|
||||
powerpc platforms, regardless of whether or not they used Open
|
||||
Firmware. To do this, a DT representation called the Flattened Device
|
||||
Tree (FDT) was created which could be passed to the kernel as a binary
|
||||
blob without requiring a real Open Firmware implementation. U-Boot,
|
||||
kexec, and other bootloaders were modified to support both passing a
|
||||
Device Tree Binary (dtb) and to modify a dtb at boot time. DT was
|
||||
also added to the PowerPC boot wrapper (arch/powerpc/boot/*) so that
|
||||
a dtb could be wrapped up with the kernel image to support booting
|
||||
existing non-DT aware firmware.
|
||||
|
||||
Some time later, FDT infrastructure was generalized to be usable by
|
||||
all architectures. At the time of this writing, 6 mainlined
|
||||
architectures (arm, microblaze, mips, powerpc, sparc, and x86) and 1
|
||||
out of mainline (nios) have some level of DT support.
|
||||
|
||||
2. Data Model
|
||||
-------------
|
||||
If you haven't already read the Device Tree Usage[1] page,
|
||||
then go read it now. It's okay, I'll wait....
|
||||
|
||||
2.1 High Level View
|
||||
-------------------
|
||||
The most important thing to understand is that the DT is simply a data
|
||||
structure that describes the hardware. There is nothing magical about
|
||||
it, and it doesn't magically make all hardware configuration problems
|
||||
go away. What it does do is provide a language for decoupling the
|
||||
hardware configuration from the board and device driver support in the
|
||||
Linux kernel (or any other operating system for that matter). Using
|
||||
it allows board and device support to become data driven; to make
|
||||
setup decisions based on data passed into the kernel instead of on
|
||||
per-machine hard coded selections.
|
||||
|
||||
Ideally, data driven platform setup should result in less code
|
||||
duplication and make it easier to support a wide range of hardware
|
||||
with a single kernel image.
|
||||
|
||||
Linux uses DT data for three major purposes:
|
||||
1) platform identification,
|
||||
2) runtime configuration, and
|
||||
3) device population.
|
||||
|
||||
2.2 Platform Identification
|
||||
---------------------------
|
||||
First and foremost, the kernel will use data in the DT to identify the
|
||||
specific machine. In a perfect world, the specific platform shouldn't
|
||||
matter to the kernel because all platform details would be described
|
||||
perfectly by the device tree in a consistent and reliable manner.
|
||||
Hardware is not perfect though, and so the kernel must identify the
|
||||
machine during early boot so that it has the opportunity to run
|
||||
machine-specific fixups.
|
||||
|
||||
In the majority of cases, the machine identity is irrelevant, and the
|
||||
kernel will instead select setup code based on the machine's core
|
||||
CPU or SoC. On ARM for example, setup_arch() in
|
||||
arch/arm/kernel/setup.c will call setup_machine_fdt() in
|
||||
arch/arm/kernel/devicetree.c which searches through the machine_desc
|
||||
table and selects the machine_desc which best matches the device tree
|
||||
data. It determines the best match by looking at the 'compatible'
|
||||
property in the root device tree node, and comparing it with the
|
||||
dt_compat list in struct machine_desc.
|
||||
|
||||
The 'compatible' property contains a sorted list of strings starting
|
||||
with the exact name of the machine, followed by an optional list of
|
||||
boards it is compatible with sorted from most compatible to least. For
|
||||
example, the root compatible properties for the TI BeagleBoard and its
|
||||
successor, the BeagleBoard xM board might look like:
|
||||
|
||||
compatible = "ti,omap3-beagleboard", "ti,omap3450", "ti,omap3";
|
||||
compatible = "ti,omap3-beagleboard-xm", "ti,omap3450", "ti,omap3";
|
||||
|
||||
Where "ti,omap3-beagleboard-xm" specifies the exact model, it also
|
||||
claims that it compatible with the OMAP 3450 SoC, and the omap3 family
|
||||
of SoCs in general. You'll notice that the list is sorted from most
|
||||
specific (exact board) to least specific (SoC family).
|
||||
|
||||
Astute readers might point out that the Beagle xM could also claim
|
||||
compatibility with the original Beagle board. However, one should be
|
||||
cautioned about doing so at the board level since there is typically a
|
||||
high level of change from one board to another, even within the same
|
||||
product line, and it is hard to nail down exactly what is meant when one
|
||||
board claims to be compatible with another. For the top level, it is
|
||||
better to err on the side of caution and not claim one board is
|
||||
compatible with another. The notable exception would be when one
|
||||
board is a carrier for another, such as a CPU module attached to a
|
||||
carrier board.
|
||||
|
||||
One more note on compatible values. Any string used in a compatible
|
||||
property must be documented as to what it indicates. Add
|
||||
documentation for compatible strings in Documentation/devicetree/bindings.
|
||||
|
||||
Again on ARM, for each machine_desc, the kernel looks to see if
|
||||
any of the dt_compat list entries appear in the compatible property.
|
||||
If one does, then that machine_desc is a candidate for driving the
|
||||
machine. After searching the entire table of machine_descs,
|
||||
setup_machine_fdt() returns the 'most compatible' machine_desc based
|
||||
on which entry in the compatible property each machine_desc matches
|
||||
against. If no matching machine_desc is found, then it returns NULL.
|
||||
|
||||
The reasoning behind this scheme is the observation that in the majority
|
||||
of cases, a single machine_desc can support a large number of boards
|
||||
if they all use the same SoC, or same family of SoCs. However,
|
||||
invariably there will be some exceptions where a specific board will
|
||||
require special setup code that is not useful in the generic case.
|
||||
Special cases could be handled by explicitly checking for the
|
||||
troublesome board(s) in generic setup code, but doing so very quickly
|
||||
becomes ugly and/or unmaintainable if it is more than just a couple of
|
||||
cases.
|
||||
|
||||
Instead, the compatible list allows a generic machine_desc to provide
|
||||
support for a wide common set of boards by specifying "less
|
||||
compatible" value in the dt_compat list. In the example above,
|
||||
generic board support can claim compatibility with "ti,omap3" or
|
||||
"ti,omap3450". If a bug was discovered on the original beagleboard
|
||||
that required special workaround code during early boot, then a new
|
||||
machine_desc could be added which implements the workarounds and only
|
||||
matches on "ti,omap3-beagleboard".
|
||||
|
||||
PowerPC uses a slightly different scheme where it calls the .probe()
|
||||
hook from each machine_desc, and the first one returning TRUE is used.
|
||||
However, this approach does not take into account the priority of the
|
||||
compatible list, and probably should be avoided for new architecture
|
||||
support.
|
||||
|
||||
2.3 Runtime configuration
|
||||
-------------------------
|
||||
In most cases, a DT will be the sole method of communicating data from
|
||||
firmware to the kernel, so also gets used to pass in runtime and
|
||||
configuration data like the kernel parameters string and the location
|
||||
of an initrd image.
|
||||
|
||||
Most of this data is contained in the /chosen node, and when booting
|
||||
Linux it will look something like this:
|
||||
|
||||
chosen {
|
||||
bootargs = "console=ttyS0,115200 loglevel=8";
|
||||
initrd-start = <0xc8000000>;
|
||||
initrd-end = <0xc8200000>;
|
||||
};
|
||||
|
||||
The bootargs property contains the kernel arguments, and the initrd-*
|
||||
properties define the address and size of an initrd blob. The
|
||||
chosen node may also optionally contain an arbitrary number of
|
||||
additional properties for platform-specific configuration data.
|
||||
|
||||
During early boot, the architecture setup code calls of_scan_flat_dt()
|
||||
several times with different helper callbacks to parse device tree
|
||||
data before paging is setup. The of_scan_flat_dt() code scans through
|
||||
the device tree and uses the helpers to extract information required
|
||||
during early boot. Typically the early_init_dt_scan_chosen() helper
|
||||
is used to parse the chosen node including kernel parameters,
|
||||
early_init_dt_scan_root() to initialize the DT address space model,
|
||||
and early_init_dt_scan_memory() to determine the size and
|
||||
location of usable RAM.
|
||||
|
||||
On ARM, the function setup_machine_fdt() is responsible for early
|
||||
scanning of the device tree after selecting the correct machine_desc
|
||||
that supports the board.
|
||||
|
||||
2.4 Device population
|
||||
---------------------
|
||||
After the board has been identified, and after the early configuration data
|
||||
has been parsed, then kernel initialization can proceed in the normal
|
||||
way. At some point in this process, unflatten_device_tree() is called
|
||||
to convert the data into a more efficient runtime representation.
|
||||
This is also when machine-specific setup hooks will get called, like
|
||||
the machine_desc .init_early(), .init_irq() and .init_machine() hooks
|
||||
on ARM. The remainder of this section uses examples from the ARM
|
||||
implementation, but all architectures will do pretty much the same
|
||||
thing when using a DT.
|
||||
|
||||
As can be guessed by the names, .init_early() is used for any machine-
|
||||
specific setup that needs to be executed early in the boot process,
|
||||
and .init_irq() is used to set up interrupt handling. Using a DT
|
||||
doesn't materially change the behaviour of either of these functions.
|
||||
If a DT is provided, then both .init_early() and .init_irq() are able
|
||||
to call any of the DT query functions (of_* in include/linux/of*.h) to
|
||||
get additional data about the platform.
|
||||
|
||||
The most interesting hook in the DT context is .init_machine() which
|
||||
is primarily responsible for populating the Linux device model with
|
||||
data about the platform. Historically this has been implemented on
|
||||
embedded platforms by defining a set of static clock structures,
|
||||
platform_devices, and other data in the board support .c file, and
|
||||
registering it en-masse in .init_machine(). When DT is used, then
|
||||
instead of hard coding static devices for each platform, the list of
|
||||
devices can be obtained by parsing the DT, and allocating device
|
||||
structures dynamically.
|
||||
|
||||
The simplest case is when .init_machine() is only responsible for
|
||||
registering a block of platform_devices. A platform_device is a concept
|
||||
used by Linux for memory or I/O mapped devices which cannot be detected
|
||||
by hardware, and for 'composite' or 'virtual' devices (more on those
|
||||
later). While there is no 'platform device' terminology for the DT,
|
||||
platform devices roughly correspond to device nodes at the root of the
|
||||
tree and children of simple memory mapped bus nodes.
|
||||
|
||||
About now is a good time to lay out an example. Here is part of the
|
||||
device tree for the NVIDIA Tegra board.
|
||||
|
||||
/{
|
||||
compatible = "nvidia,harmony", "nvidia,tegra20";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
interrupt-parent = <&intc>;
|
||||
|
||||
chosen { };
|
||||
aliases { };
|
||||
|
||||
memory {
|
||||
device_type = "memory";
|
||||
reg = <0x00000000 0x40000000>;
|
||||
};
|
||||
|
||||
soc {
|
||||
compatible = "nvidia,tegra20-soc", "simple-bus";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
ranges;
|
||||
|
||||
intc: interrupt-controller@50041000 {
|
||||
compatible = "nvidia,tegra20-gic";
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
reg = <0x50041000 0x1000>, < 0x50040100 0x0100 >;
|
||||
};
|
||||
|
||||
serial@70006300 {
|
||||
compatible = "nvidia,tegra20-uart";
|
||||
reg = <0x70006300 0x100>;
|
||||
interrupts = <122>;
|
||||
};
|
||||
|
||||
i2s1: i2s@70002800 {
|
||||
compatible = "nvidia,tegra20-i2s";
|
||||
reg = <0x70002800 0x100>;
|
||||
interrupts = <77>;
|
||||
codec = <&wm8903>;
|
||||
};
|
||||
|
||||
i2c@7000c000 {
|
||||
compatible = "nvidia,tegra20-i2c";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
reg = <0x7000c000 0x100>;
|
||||
interrupts = <70>;
|
||||
|
||||
wm8903: codec@1a {
|
||||
compatible = "wlf,wm8903";
|
||||
reg = <0x1a>;
|
||||
interrupts = <347>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
sound {
|
||||
compatible = "nvidia,harmony-sound";
|
||||
i2s-controller = <&i2s1>;
|
||||
i2s-codec = <&wm8903>;
|
||||
};
|
||||
};
|
||||
|
||||
At .machine_init() time, Tegra board support code will need to look at
|
||||
this DT and decide which nodes to create platform_devices for.
|
||||
However, looking at the tree, it is not immediately obvious what kind
|
||||
of device each node represents, or even if a node represents a device
|
||||
at all. The /chosen, /aliases, and /memory nodes are informational
|
||||
nodes that don't describe devices (although arguably memory could be
|
||||
considered a device). The children of the /soc node are memory mapped
|
||||
devices, but the codec@1a is an i2c device, and the sound node
|
||||
represents not a device, but rather how other devices are connected
|
||||
together to create the audio subsystem. I know what each device is
|
||||
because I'm familiar with the board design, but how does the kernel
|
||||
know what to do with each node?
|
||||
|
||||
The trick is that the kernel starts at the root of the tree and looks
|
||||
for nodes that have a 'compatible' property. First, it is generally
|
||||
assumed that any node with a 'compatible' property represents a device
|
||||
of some kind, and second, it can be assumed that any node at the root
|
||||
of the tree is either directly attached to the processor bus, or is a
|
||||
miscellaneous system device that cannot be described any other way.
|
||||
For each of these nodes, Linux allocates and registers a
|
||||
platform_device, which in turn may get bound to a platform_driver.
|
||||
|
||||
Why is using a platform_device for these nodes a safe assumption?
|
||||
Well, for the way that Linux models devices, just about all bus_types
|
||||
assume that its devices are children of a bus controller. For
|
||||
example, each i2c_client is a child of an i2c_master. Each spi_device
|
||||
is a child of an SPI bus. Similarly for USB, PCI, MDIO, etc. The
|
||||
same hierarchy is also found in the DT, where I2C device nodes only
|
||||
ever appear as children of an I2C bus node. Ditto for SPI, MDIO, USB,
|
||||
etc. The only devices which do not require a specific type of parent
|
||||
device are platform_devices (and amba_devices, but more on that
|
||||
later), which will happily live at the base of the Linux /sys/devices
|
||||
tree. Therefore, if a DT node is at the root of the tree, then it
|
||||
really probably is best registered as a platform_device.
|
||||
|
||||
Linux board support code calls of_platform_populate(NULL, NULL, NULL)
|
||||
to kick off discovery of devices at the root of the tree. The
|
||||
parameters are all NULL because when starting from the root of the
|
||||
tree, there is no need to provide a starting node (the first NULL), a
|
||||
parent struct device (the last NULL), and we're not using a match
|
||||
table (yet). For a board that only needs to register devices,
|
||||
.init_machine() can be completely empty except for the
|
||||
of_platform_populate() call.
|
||||
|
||||
In the Tegra example, this accounts for the /soc and /sound nodes, but
|
||||
what about the children of the SoC node? Shouldn't they be registered
|
||||
as platform devices too? For Linux DT support, the generic behaviour
|
||||
is for child devices to be registered by the parent's device driver at
|
||||
driver .probe() time. So, an i2c bus device driver will register a
|
||||
i2c_client for each child node, an SPI bus driver will register
|
||||
its spi_device children, and similarly for other bus_types.
|
||||
According to that model, a driver could be written that binds to the
|
||||
SoC node and simply registers platform_devices for each of its
|
||||
children. The board support code would allocate and register an SoC
|
||||
device, a (theoretical) SoC device driver could bind to the SoC device,
|
||||
and register platform_devices for /soc/interrupt-controller, /soc/serial,
|
||||
/soc/i2s, and /soc/i2c in its .probe() hook. Easy, right?
|
||||
|
||||
Actually, it turns out that registering children of some
|
||||
platform_devices as more platform_devices is a common pattern, and the
|
||||
device tree support code reflects that and makes the above example
|
||||
simpler. The second argument to of_platform_populate() is an
|
||||
of_device_id table, and any node that matches an entry in that table
|
||||
will also get its child nodes registered. In the tegra case, the code
|
||||
can look something like this:
|
||||
|
||||
static void __init harmony_init_machine(void)
|
||||
{
|
||||
/* ... */
|
||||
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
|
||||
}
|
||||
|
||||
"simple-bus" is defined in the ePAPR 1.0 specification as a property
|
||||
meaning a simple memory mapped bus, so the of_platform_populate() code
|
||||
could be written to just assume simple-bus compatible nodes will
|
||||
always be traversed. However, we pass it in as an argument so that
|
||||
board support code can always override the default behaviour.
|
||||
|
||||
[Need to add discussion of adding i2c/spi/etc child devices]
|
||||
|
||||
Appendix A: AMBA devices
|
||||
------------------------
|
||||
|
||||
ARM Primecells are a certain kind of device attached to the ARM AMBA
|
||||
bus which include some support for hardware detection and power
|
||||
management. In Linux, struct amba_device and the amba_bus_type is
|
||||
used to represent Primecell devices. However, the fiddly bit is that
|
||||
not all devices on an AMBA bus are Primecells, and for Linux it is
|
||||
typical for both amba_device and platform_device instances to be
|
||||
siblings of the same bus segment.
|
||||
|
||||
When using the DT, this creates problems for of_platform_populate()
|
||||
because it must decide whether to register each node as either a
|
||||
platform_device or an amba_device. This unfortunately complicates the
|
||||
device creation model a little bit, but the solution turns out not to
|
||||
be too invasive. If a node is compatible with "arm,amba-primecell", then
|
||||
of_platform_populate() will register it as an amba_device instead of a
|
||||
platform_device.
|
||||
|
|
@ -32,8 +32,12 @@ The buffer-user
|
|||
*IMPORTANT*: [see https://lkml.org/lkml/2011/12/20/211 for more details]
|
||||
For this first version, A buffer shared using the dma_buf sharing API:
|
||||
- *may* be exported to user space using "mmap" *ONLY* by exporter, outside of
|
||||
this framework.
|
||||
- may be used *ONLY* by importers that do not need CPU access to the buffer.
|
||||
this framework.
|
||||
- with this new iteration of the dma-buf api cpu access from the kernel has been
|
||||
enable, see below for the details.
|
||||
|
||||
dma-buf operations for device dma only
|
||||
--------------------------------------
|
||||
|
||||
The dma_buf buffer sharing API usage contains the following steps:
|
||||
|
||||
|
|
@ -219,10 +223,120 @@ NOTES:
|
|||
If the exporter chooses not to allow an attach() operation once a
|
||||
map_dma_buf() API has been called, it simply returns an error.
|
||||
|
||||
Miscellaneous notes:
|
||||
Kernel cpu access to a dma-buf buffer object
|
||||
--------------------------------------------
|
||||
|
||||
The motivation to allow cpu access from the kernel to a dma-buf object from the
|
||||
importers side are:
|
||||
- fallback operations, e.g. if the devices is connected to a usb bus and the
|
||||
kernel needs to shuffle the data around first before sending it away.
|
||||
- full transparency for existing users on the importer side, i.e. userspace
|
||||
should not notice the difference between a normal object from that subsystem
|
||||
and an imported one backed by a dma-buf. This is really important for drm
|
||||
opengl drivers that expect to still use all the existing upload/download
|
||||
paths.
|
||||
|
||||
Access to a dma_buf from the kernel context involves three steps:
|
||||
|
||||
1. Prepare access, which invalidate any necessary caches and make the object
|
||||
available for cpu access.
|
||||
2. Access the object page-by-page with the dma_buf map apis
|
||||
3. Finish access, which will flush any necessary cpu caches and free reserved
|
||||
resources.
|
||||
|
||||
1. Prepare access
|
||||
|
||||
Before an importer can access a dma_buf object with the cpu from the kernel
|
||||
context, it needs to notify the exporter of the access that is about to
|
||||
happen.
|
||||
|
||||
Interface:
|
||||
int dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
|
||||
size_t start, size_t len,
|
||||
enum dma_data_direction direction)
|
||||
|
||||
This allows the exporter to ensure that the memory is actually available for
|
||||
cpu access - the exporter might need to allocate or swap-in and pin the
|
||||
backing storage. The exporter also needs to ensure that cpu access is
|
||||
coherent for the given range and access direction. The range and access
|
||||
direction can be used by the exporter to optimize the cache flushing, i.e.
|
||||
access outside of the range or with a different direction (read instead of
|
||||
write) might return stale or even bogus data (e.g. when the exporter needs to
|
||||
copy the data to temporary storage).
|
||||
|
||||
This step might fail, e.g. in oom conditions.
|
||||
|
||||
2. Accessing the buffer
|
||||
|
||||
To support dma_buf objects residing in highmem cpu access is page-based using
|
||||
an api similar to kmap. Accessing a dma_buf is done in aligned chunks of
|
||||
PAGE_SIZE size. Before accessing a chunk it needs to be mapped, which returns
|
||||
a pointer in kernel virtual address space. Afterwards the chunk needs to be
|
||||
unmapped again. There is no limit on how often a given chunk can be mapped
|
||||
and unmapped, i.e. the importer does not need to call begin_cpu_access again
|
||||
before mapping the same chunk again.
|
||||
|
||||
Interfaces:
|
||||
void *dma_buf_kmap(struct dma_buf *, unsigned long);
|
||||
void dma_buf_kunmap(struct dma_buf *, unsigned long, void *);
|
||||
|
||||
There are also atomic variants of these interfaces. Like for kmap they
|
||||
facilitate non-blocking fast-paths. Neither the importer nor the exporter (in
|
||||
the callback) is allowed to block when using these.
|
||||
|
||||
Interfaces:
|
||||
void *dma_buf_kmap_atomic(struct dma_buf *, unsigned long);
|
||||
void dma_buf_kunmap_atomic(struct dma_buf *, unsigned long, void *);
|
||||
|
||||
For importers all the restrictions of using kmap apply, like the limited
|
||||
supply of kmap_atomic slots. Hence an importer shall only hold onto at most 2
|
||||
atomic dma_buf kmaps at the same time (in any given process context).
|
||||
|
||||
dma_buf kmap calls outside of the range specified in begin_cpu_access are
|
||||
undefined. If the range is not PAGE_SIZE aligned, kmap needs to succeed on
|
||||
the partial chunks at the beginning and end but may return stale or bogus
|
||||
data outside of the range (in these partial chunks).
|
||||
|
||||
Note that these calls need to always succeed. The exporter needs to complete
|
||||
any preparations that might fail in begin_cpu_access.
|
||||
|
||||
3. Finish access
|
||||
|
||||
When the importer is done accessing the range specified in begin_cpu_access,
|
||||
it needs to announce this to the exporter (to facilitate cache flushing and
|
||||
unpinning of any pinned resources). The result of of any dma_buf kmap calls
|
||||
after end_cpu_access is undefined.
|
||||
|
||||
Interface:
|
||||
void dma_buf_end_cpu_access(struct dma_buf *dma_buf,
|
||||
size_t start, size_t len,
|
||||
enum dma_data_direction dir);
|
||||
|
||||
|
||||
Miscellaneous notes
|
||||
-------------------
|
||||
|
||||
- Any exporters or users of the dma-buf buffer sharing framework must have
|
||||
a 'select DMA_SHARED_BUFFER' in their respective Kconfigs.
|
||||
|
||||
- In order to avoid fd leaks on exec, the FD_CLOEXEC flag must be set
|
||||
on the file descriptor. This is not just a resource leak, but a
|
||||
potential security hole. It could give the newly exec'd application
|
||||
access to buffers, via the leaked fd, to which it should otherwise
|
||||
not be permitted access.
|
||||
|
||||
The problem with doing this via a separate fcntl() call, versus doing it
|
||||
atomically when the fd is created, is that this is inherently racy in a
|
||||
multi-threaded app[3]. The issue is made worse when it is library code
|
||||
opening/creating the file descriptor, as the application may not even be
|
||||
aware of the fd's.
|
||||
|
||||
To avoid this problem, userspace must have a way to request O_CLOEXEC
|
||||
flag be set when the dma-buf fd is created. So any API provided by
|
||||
the exporting driver to create a dmabuf fd must provide a way to let
|
||||
userspace control setting of O_CLOEXEC flag passed in to dma_buf_fd().
|
||||
|
||||
References:
|
||||
[1] struct dma_buf_ops in include/linux/dma-buf.h
|
||||
[2] All interfaces mentioned above defined in include/linux/dma-buf.h
|
||||
[3] https://lwn.net/Articles/236486/
|
||||
|
|
|
|||
|
|
@ -158,7 +158,6 @@ logo_*.c
|
|||
logo_*_clut224.c
|
||||
logo_*_mono.c
|
||||
lxdialog
|
||||
mach
|
||||
mach-types
|
||||
mach-types.h
|
||||
machtypes.h
|
||||
|
|
|
|||
|
|
@ -211,7 +211,7 @@ Using the same setup as described above, load the module like this:
|
|||
modprobe i810fb vram=2 xres=1024 bpp=8 hsync1=30 hsync2=55 vsync1=50 \
|
||||
vsync2=85 accel=1 mtrr=1
|
||||
|
||||
Or just add the following to /etc/modprobe.conf
|
||||
Or just add the following to a configuration file in /etc/modprobe.d/
|
||||
|
||||
options i810fb vram=2 xres=1024 bpp=16 hsync1=30 hsync2=55 vsync1=50 \
|
||||
vsync2=85 accel=1 mtrr=1
|
||||
|
|
|
|||
|
|
@ -120,7 +120,7 @@ Using the same setup as described above, load the module like this:
|
|||
|
||||
modprobe intelfb mode=800x600-32@75 vram=8 accel=1 hwcursor=1
|
||||
|
||||
Or just add the following to /etc/modprobe.conf
|
||||
Or just add the following to a configuration file in /etc/modprobe.d/
|
||||
|
||||
options intelfb mode=800x600-32@75 vram=8 accel=1 hwcursor=1
|
||||
|
||||
|
|
|
|||
|
|
@ -6,14 +6,6 @@ be removed from this file.
|
|||
|
||||
---------------------------
|
||||
|
||||
What: x86 floppy disable_hlt
|
||||
When: 2012
|
||||
Why: ancient workaround of dubious utility clutters the
|
||||
code used by everybody else.
|
||||
Who: Len Brown <len.brown@intel.com>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: CONFIG_APM_CPU_IDLE, and its ability to call APM BIOS in idle
|
||||
When: 2012
|
||||
Why: This optional sub-feature of APM is of dubious reliability,
|
||||
|
|
@ -529,3 +521,13 @@ When: 3.5
|
|||
Why: The old kmap_atomic() with two arguments is deprecated, we only
|
||||
keep it for backward compatibility for few cycles and then drop it.
|
||||
Who: Cong Wang <amwang@redhat.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: get_robust_list syscall
|
||||
When: 2013
|
||||
Why: There appear to be no production users of the get_robust_list syscall,
|
||||
and it runs the risk of leaking address locations, allowing the bypass
|
||||
of ASLR. It was only ever intended for debugging, so it should be
|
||||
removed.
|
||||
Who: Kees Cook <keescook@chromium.org>
|
||||
|
|
|
|||
|
|
@ -144,9 +144,6 @@ journal_async_commit Commit block can be written to disk without waiting
|
|||
mount the device. This will enable 'journal_checksum'
|
||||
internally.
|
||||
|
||||
journal=update Update the ext4 file system's journal to the current
|
||||
format.
|
||||
|
||||
journal_dev=devnum When the external journal device's major/minor numbers
|
||||
have changed, this option allows the user to specify
|
||||
the new journal location. The journal device is
|
||||
|
|
@ -356,11 +353,6 @@ nouid32 Disables 32-bit UIDs and GIDs. This is for
|
|||
interoperability with older kernels which only
|
||||
store and expect 16-bit values.
|
||||
|
||||
resize Allows to resize filesystem to the end of the last
|
||||
existing block group, further resize has to be done
|
||||
with resize2fs either online, or offline. It can be
|
||||
used only with conjunction with remount.
|
||||
|
||||
block_validity This options allows to enables/disables the in-kernel
|
||||
noblock_validity facility for tracking filesystem metadata blocks
|
||||
within internal data structures. This allows multi-
|
||||
|
|
|
|||
|
|
@ -113,8 +113,8 @@ the fdtable structure -
|
|||
if (fd >= 0) {
|
||||
/* locate_fd() may have expanded fdtable, load the ptr */
|
||||
fdt = files_fdtable(files);
|
||||
FD_SET(fd, fdt->open_fds);
|
||||
FD_CLR(fd, fdt->close_on_exec);
|
||||
__set_open_fd(fd, fdt);
|
||||
__clear_close_on_exec(fd, fdt);
|
||||
spin_unlock(&files->file_lock);
|
||||
.....
|
||||
|
||||
|
|
|
|||
|
|
@ -271,9 +271,26 @@ Some platforms may also use knowledge about what GPIOs are active for
|
|||
power management, such as by powering down unused chip sectors and, more
|
||||
easily, gating off unused clocks.
|
||||
|
||||
Note that requesting a GPIO does NOT cause it to be configured in any
|
||||
way; it just marks that GPIO as in use. Separate code must handle any
|
||||
pin setup (e.g. controlling which pin the GPIO uses, pullup/pulldown).
|
||||
For GPIOs that use pins known to the pinctrl subsystem, that subsystem should
|
||||
be informed of their use; a gpiolib driver's .request() operation may call
|
||||
pinctrl_request_gpio(), and a gpiolib driver's .free() operation may call
|
||||
pinctrl_free_gpio(). The pinctrl subsystem allows a pinctrl_request_gpio()
|
||||
to succeed concurrently with a pin or pingroup being "owned" by a device for
|
||||
pin multiplexing.
|
||||
|
||||
Any programming of pin multiplexing hardware that is needed to route the
|
||||
GPIO signal to the appropriate pin should occur within a GPIO driver's
|
||||
.direction_input() or .direction_output() operations, and occur after any
|
||||
setup of an output GPIO's value. This allows a glitch-free migration from a
|
||||
pin's special function to GPIO. This is sometimes required when using a GPIO
|
||||
to implement a workaround on signals typically driven by a non-GPIO HW block.
|
||||
|
||||
Some platforms allow some or all GPIO signals to be routed to different pins.
|
||||
Similarly, other aspects of the GPIO or pin may need to be configured, such as
|
||||
pullup/pulldown. Platform software should arrange that any such details are
|
||||
configured prior to gpio_request() being called for those GPIOs, e.g. using
|
||||
the pinctrl subsystem's mapping table, so that GPIO users need not be aware
|
||||
of these details.
|
||||
|
||||
Also note that it's your responsibility to have stopped using a GPIO
|
||||
before you free it.
|
||||
|
|
@ -302,6 +319,8 @@ where 'flags' is currently defined to specify the following properties:
|
|||
|
||||
* GPIOF_INIT_LOW - as output, set initial level to LOW
|
||||
* GPIOF_INIT_HIGH - as output, set initial level to HIGH
|
||||
* GPIOF_OPEN_DRAIN - gpio pin is open drain type.
|
||||
* GPIOF_OPEN_SOURCE - gpio pin is open source type.
|
||||
|
||||
since GPIOF_INIT_* are only valid when configured as output, so group valid
|
||||
combinations as:
|
||||
|
|
@ -310,8 +329,19 @@ combinations as:
|
|||
* GPIOF_OUT_INIT_LOW - configured as output, initial level LOW
|
||||
* GPIOF_OUT_INIT_HIGH - configured as output, initial level HIGH
|
||||
|
||||
In the future, these flags can be extended to support more properties such
|
||||
as open-drain status.
|
||||
When setting the flag as GPIOF_OPEN_DRAIN then it will assume that pins is
|
||||
open drain type. Such pins will not be driven to 1 in output mode. It is
|
||||
require to connect pull-up on such pins. By enabling this flag, gpio lib will
|
||||
make the direction to input when it is asked to set value of 1 in output mode
|
||||
to make the pin HIGH. The pin is make to LOW by driving value 0 in output mode.
|
||||
|
||||
When setting the flag as GPIOF_OPEN_SOURCE then it will assume that pins is
|
||||
open source type. Such pins will not be driven to 0 in output mode. It is
|
||||
require to connect pull-down on such pin. By enabling this flag, gpio lib will
|
||||
make the direction to input when it is asked to set value of 0 in output mode
|
||||
to make the pin LOW. The pin is make to HIGH by driving value 1 in output mode.
|
||||
|
||||
In the future, these flags can be extended to support more properties.
|
||||
|
||||
Further more, to ease the claim/release of multiple GPIOs, 'struct gpio' is
|
||||
introduced to encapsulate all three fields as:
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ Supported chips:
|
|||
Socket S1G2: Athlon (X2), Sempron (X2), Turion X2 (Ultra)
|
||||
* AMD Family 12h processors: "Llano" (E2/A4/A6/A8-Series)
|
||||
* AMD Family 14h processors: "Brazos" (C/E/G/Z-Series)
|
||||
* AMD Family 15h processors: "Bulldozer"
|
||||
* AMD Family 15h processors: "Bulldozer" (FX-Series), "Trinity"
|
||||
|
||||
Prefix: 'k10temp'
|
||||
Addresses scanned: PCI space
|
||||
|
|
|
|||
|
|
@ -20,6 +20,7 @@ Supported adapters:
|
|||
* Intel Patsburg (PCH)
|
||||
* Intel DH89xxCC (PCH)
|
||||
* Intel Panther Point (PCH)
|
||||
* Intel Lynx Point (PCH)
|
||||
Datasheets: Publicly available at the Intel website
|
||||
|
||||
On Intel Patsburg and later chipsets, both the normal host SMBus controller
|
||||
|
|
|
|||
|
|
@ -28,5 +28,5 @@ If the scx200_acb driver is built into the kernel, add the following
|
|||
parameter to your boot command line:
|
||||
scx200_acb.base=0x810,0x820
|
||||
If the scx200_acb driver is built as a module, add the following line to
|
||||
the file /etc/modprobe.conf instead:
|
||||
a configuration file in /etc/modprobe.d/ instead:
|
||||
options scx200_acb base=0x810,0x820
|
||||
|
|
|
|||
|
|
@ -169,7 +169,7 @@ When using ide.c as a module in combination with kmod, add:
|
|||
|
||||
alias block-major-3 ide-probe
|
||||
|
||||
to /etc/modprobe.conf.
|
||||
to a configuration file in /etc/modprobe.d/.
|
||||
|
||||
When ide.c is used as a module, you can pass command line parameters to the
|
||||
driver using the "options=" keyword to insmod, while replacing any ',' with
|
||||
|
|
|
|||
|
|
@ -250,8 +250,8 @@ And so on up to event31.
|
|||
a USB keyboard works and is correctly connected to the kernel keyboard
|
||||
driver.
|
||||
|
||||
Doing a cat /dev/input/mouse0 (c, 13, 32) will verify that a mouse
|
||||
is also emulated, characters should appear if you move it.
|
||||
Doing a "cat /dev/input/mouse0" (c, 13, 32) will verify that a mouse
|
||||
is also emulated; characters should appear if you move it.
|
||||
|
||||
You can test the joystick emulation with the 'jstest' utility,
|
||||
available in the joystick package (see Documentation/input/joystick.txt).
|
||||
|
|
|
|||
|
|
@ -225,6 +225,7 @@ Code Seq#(hex) Include File Comments
|
|||
'j' 00-3F linux/joystick.h
|
||||
'k' 00-0F linux/spi/spidev.h conflict!
|
||||
'k' 00-05 video/kyro.h conflict!
|
||||
'k' 10-17 linux/hsi/hsi_char.h HSI character device
|
||||
'l' 00-3F linux/tcfs_fs.h transparent cryptographic file system
|
||||
<http://web.archive.org/web/*/http://mikonos.dia.unisa.it/tcfs>
|
||||
'l' 40-7F linux/udf_fs_i.h in development:
|
||||
|
|
|
|||
|
|
@ -97,8 +97,7 @@ GigaSet 307x Device Driver
|
|||
2.5.): 1=on (default), 0=off
|
||||
|
||||
Depending on your distribution you may want to create a separate module
|
||||
configuration file /etc/modprobe.d/gigaset for these, or add them to a
|
||||
custom file like /etc/modprobe.conf.local.
|
||||
configuration file like /etc/modprobe.d/gigaset.conf for these.
|
||||
|
||||
2.2. Device nodes for user space programs
|
||||
------------------------------------
|
||||
|
|
@ -212,8 +211,8 @@ GigaSet 307x Device Driver
|
|||
|
||||
options ppp_async flag_time=0
|
||||
|
||||
to an appropriate module configuration file, like /etc/modprobe.d/gigaset
|
||||
or /etc/modprobe.conf.local.
|
||||
to an appropriate module configuration file, like
|
||||
/etc/modprobe.d/gigaset.conf.
|
||||
|
||||
Unimodem mode is needed for making some devices [e.g. SX100] work which
|
||||
do not support the regular Gigaset command set. If debug output (see
|
||||
|
|
@ -237,8 +236,8 @@ GigaSet 307x Device Driver
|
|||
modprobe usb_gigaset startmode=0
|
||||
or by adding a line like
|
||||
options usb_gigaset startmode=0
|
||||
to an appropriate module configuration file, like /etc/modprobe.d/gigaset
|
||||
or /etc/modprobe.conf.local.
|
||||
to an appropriate module configuration file, like
|
||||
/etc/modprobe.d/gigaset.conf
|
||||
|
||||
2.6. Call-ID (CID) mode
|
||||
------------------
|
||||
|
|
@ -310,7 +309,7 @@ GigaSet 307x Device Driver
|
|||
|
||||
options isdn dialtimeout=15
|
||||
|
||||
to /etc/modprobe.d/gigaset, /etc/modprobe.conf.local or a similar file.
|
||||
to /etc/modprobe.d/gigaset.conf or a similar file.
|
||||
|
||||
Problem:
|
||||
The isdnlog program emits error messages or just doesn't work.
|
||||
|
|
@ -350,8 +349,7 @@ GigaSet 307x Device Driver
|
|||
The initial value can be set using the debug parameter when loading the
|
||||
module "gigaset", e.g. by adding a line
|
||||
options gigaset debug=0
|
||||
to your module configuration file, eg. /etc/modprobe.d/gigaset or
|
||||
/etc/modprobe.conf.local.
|
||||
to your module configuration file, eg. /etc/modprobe.d/gigaset.conf
|
||||
|
||||
Generated debugging information can be found
|
||||
- as output of the command
|
||||
|
|
|
|||
|
|
@ -28,12 +28,10 @@ new (default) values, so you can use:
|
|||
|
||||
grep "(NEW)" conf.new
|
||||
|
||||
to see the new config symbols or you can 'diff' the previous and
|
||||
new .config files to see the differences:
|
||||
to see the new config symbols or you can use diffconfig to see the
|
||||
differences between the previous and new .config files:
|
||||
|
||||
diff .config.old .config | less
|
||||
|
||||
(Yes, we need something better here.)
|
||||
scripts/diffconfig .config.old .config | less
|
||||
|
||||
______________________________________________________________________
|
||||
Environment variables for '*config'
|
||||
|
|
|
|||
|
|
@ -1699,6 +1699,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
|||
The default is to send the implementation identification
|
||||
information.
|
||||
|
||||
nfsd.nfs4_disable_idmapping=
|
||||
[NFSv4] When set to the default of '1', the NFSv4
|
||||
server will return only numeric uids and gids to
|
||||
clients using auth_sys, and will accept numeric uids
|
||||
and gids from such clients. This is intended to ease
|
||||
migration from NFSv2/v3.
|
||||
|
||||
objlayoutdriver.osd_login_prog=
|
||||
[NFS] [OBJLAYOUT] sets the pathname to the program which
|
||||
|
|
@ -1869,6 +1875,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
|||
shutdown the other cpus. Instead use the REBOOT_VECTOR
|
||||
irq.
|
||||
|
||||
nomodule Disable module load
|
||||
|
||||
nopat [X86] Disable PAT (page attribute table extension of
|
||||
pagetables) support.
|
||||
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ Status
|
|||
Usage
|
||||
-----
|
||||
|
||||
Try "modprobe asus_acpi". Check your dmesg (simply type dmesg). You should
|
||||
Try "modprobe asus-laptop". Check your dmesg (simply type dmesg). You should
|
||||
see some lines like this :
|
||||
|
||||
Asus Laptop Extras version 0.42
|
||||
|
|
|
|||
|
|
@ -17,6 +17,11 @@ subsystem. See the logs of acpid or /proc/acpi/event and
|
|||
devices are created by the driver. Additionally, loading the driver with the
|
||||
debug option will report all events in the kernel log.
|
||||
|
||||
The "scancodes" passed to the input system (that can be remapped with udev)
|
||||
are indexes to the table "sony_laptop_input_keycode_map" in the sony-laptop.c
|
||||
module. For example the "FN/E" key combination (EJECTCD on some models)
|
||||
generates the scancode 20 (0x14).
|
||||
|
||||
Backlight control:
|
||||
------------------
|
||||
If your laptop model supports it, you will find sysfs files in the
|
||||
|
|
|
|||
|
|
@ -110,7 +110,7 @@ Module use:
|
|||
-----------
|
||||
|
||||
In order to automatically load the sonypi module on use, you can put those
|
||||
lines in your /etc/modprobe.conf file:
|
||||
lines a configuration file in /etc/modprobe.d/:
|
||||
|
||||
alias char-major-10-250 sonypi
|
||||
options sonypi minor=250
|
||||
|
|
|
|||
|
|
@ -38,11 +38,11 @@ if [ ! -e /proc/sys/fs/binfmt_misc/register ]; then
|
|||
/sbin/modprobe binfmt_misc
|
||||
# Some distributions, like Fedora Core, perform
|
||||
# the following command automatically when the
|
||||
# binfmt_misc module is loaded into the kernel.
|
||||
# binfmt_misc module is loaded into the kernel
|
||||
# or during normal boot up (systemd-based systems).
|
||||
# Thus, it is possible that the following line
|
||||
# is not needed at all. Look at /etc/modprobe.conf
|
||||
# to check whether this is applicable or not.
|
||||
mount -t binfmt_misc none /proc/sys/fs/binfmt_misc
|
||||
# is not needed at all.
|
||||
mount -t binfmt_misc none /proc/sys/fs/binfmt_misc
|
||||
fi
|
||||
|
||||
# Register support for .NET CLR binaries
|
||||
|
|
|
|||
|
|
@ -93,7 +93,7 @@ Every time a driver is inserted into the kernel, it has to know which
|
|||
modems it should access at which ports. This can be done with the setbaycom
|
||||
utility. If you are only using one modem, you can also configure the
|
||||
driver from the insmod command line (or by means of an option line in
|
||||
/etc/modprobe.conf).
|
||||
/etc/modprobe.d/*.conf).
|
||||
|
||||
Examples:
|
||||
modprobe baycom_ser_fdx mode="ser12*" iobase=0x3f8 irq=4
|
||||
|
|
|
|||
|
|
@ -173,9 +173,8 @@ bonding module at load time, or are specified via sysfs.
|
|||
|
||||
Module options may be given as command line arguments to the
|
||||
insmod or modprobe command, but are usually specified in either the
|
||||
/etc/modules.conf or /etc/modprobe.conf configuration file, or in a
|
||||
distro-specific configuration file (some of which are detailed in the next
|
||||
section).
|
||||
/etc/modrobe.d/*.conf configuration files, or in a distro-specific
|
||||
configuration file (some of which are detailed in the next section).
|
||||
|
||||
Details on bonding support for sysfs is provided in the
|
||||
"Configuring Bonding Manually via Sysfs" section, below.
|
||||
|
|
@ -1021,7 +1020,7 @@ ifcfg-bondX files.
|
|||
|
||||
Because the sysconfig scripts supply the bonding module
|
||||
options in the ifcfg-bondX file, it is not necessary to add them to
|
||||
the system /etc/modules.conf or /etc/modprobe.conf configuration file.
|
||||
the system /etc/modules.d/*.conf configuration files.
|
||||
|
||||
3.2 Configuration with Initscripts Support
|
||||
------------------------------------------
|
||||
|
|
@ -1098,15 +1097,13 @@ queried targets, e.g.,
|
|||
arp_ip_target=+192.168.1.1 arp_ip_target=+192.168.1.2
|
||||
|
||||
is the proper syntax to specify multiple targets. When specifying
|
||||
options via BONDING_OPTS, it is not necessary to edit /etc/modules.conf or
|
||||
/etc/modprobe.conf.
|
||||
options via BONDING_OPTS, it is not necessary to edit /etc/modprobe.d/*.conf.
|
||||
|
||||
For even older versions of initscripts that do not support
|
||||
BONDING_OPTS, it is necessary to edit /etc/modules.conf (or
|
||||
/etc/modprobe.conf, depending upon your distro) to load the bonding module
|
||||
with your desired options when the bond0 interface is brought up. The
|
||||
following lines in /etc/modules.conf (or modprobe.conf) will load the
|
||||
bonding module, and select its options:
|
||||
BONDING_OPTS, it is necessary to edit /etc/modprobe.d/*.conf, depending upon
|
||||
your distro) to load the bonding module with your desired options when the
|
||||
bond0 interface is brought up. The following lines in /etc/modprobe.d/*.conf
|
||||
will load the bonding module, and select its options:
|
||||
|
||||
alias bond0 bonding
|
||||
options bond0 mode=balance-alb miimon=100
|
||||
|
|
@ -1152,7 +1149,7 @@ knowledge of bonding. One such distro is SuSE Linux Enterprise Server
|
|||
version 8.
|
||||
|
||||
The general method for these systems is to place the bonding
|
||||
module parameters into /etc/modules.conf or /etc/modprobe.conf (as
|
||||
module parameters into a config file in /etc/modprobe.d/ (as
|
||||
appropriate for the installed distro), then add modprobe and/or
|
||||
ifenslave commands to the system's global init script. The name of
|
||||
the global init script differs; for sysconfig, it is
|
||||
|
|
@ -1228,7 +1225,7 @@ network initialization scripts.
|
|||
specify a different name for each instance (the module loading system
|
||||
requires that every loaded module, even multiple instances of the same
|
||||
module, have a unique name). This is accomplished by supplying multiple
|
||||
sets of bonding options in /etc/modprobe.conf, for example:
|
||||
sets of bonding options in /etc/modprobe.d/*.conf, for example:
|
||||
|
||||
alias bond0 bonding
|
||||
options bond0 -o bond0 mode=balance-rr miimon=100
|
||||
|
|
@ -1793,8 +1790,8 @@ route additions may cause trouble.
|
|||
On systems with network configuration scripts that do not
|
||||
associate physical devices directly with network interface names (so
|
||||
that the same physical device always has the same "ethX" name), it may
|
||||
be necessary to add some special logic to either /etc/modules.conf or
|
||||
/etc/modprobe.conf (depending upon which is installed on the system).
|
||||
be necessary to add some special logic to config files in
|
||||
/etc/modprobe.d/.
|
||||
|
||||
For example, given a modules.conf containing the following:
|
||||
|
||||
|
|
@ -1821,20 +1818,15 @@ add above bonding e1000 tg3
|
|||
bonding is loaded. This command is fully documented in the
|
||||
modules.conf manual page.
|
||||
|
||||
On systems utilizing modprobe.conf (or modprobe.conf.local),
|
||||
an equivalent problem can occur. In this case, the following can be
|
||||
added to modprobe.conf (or modprobe.conf.local, as appropriate), as
|
||||
follows (all on one line; it has been split here for clarity):
|
||||
On systems utilizing modprobe an equivalent problem can occur.
|
||||
In this case, the following can be added to config files in
|
||||
/etc/modprobe.d/ as:
|
||||
|
||||
install bonding /sbin/modprobe tg3; /sbin/modprobe e1000;
|
||||
/sbin/modprobe --ignore-install bonding
|
||||
softdep bonding pre: tg3 e1000
|
||||
|
||||
This will, when loading the bonding module, rather than
|
||||
performing the normal action, instead execute the provided command.
|
||||
This command loads the device drivers in the order needed, then calls
|
||||
modprobe with --ignore-install to cause the normal action to then take
|
||||
place. Full documentation on this can be found in the modprobe.conf
|
||||
and modprobe manual pages.
|
||||
This will load tg3 and e1000 modules before loading the bonding one.
|
||||
Full documentation on this can be found in the modprobe.d and modprobe
|
||||
manual pages.
|
||||
|
||||
8.3. Painfully Slow Or No Failed Link Detection By Miimon
|
||||
---------------------------------------------------------
|
||||
|
|
|
|||
|
|
@ -45,12 +45,13 @@ Now eth0 should active, you can test it by "ping" or get more information by
|
|||
"ifconfig". If tested ok, continue the next step.
|
||||
|
||||
4. cp dl2k.ko /lib/modules/`uname -r`/kernel/drivers/net
|
||||
5. Add the following line to /etc/modprobe.conf:
|
||||
5. Add the following line to /etc/modprobe.d/dl2k.conf:
|
||||
alias eth0 dl2k
|
||||
6. Run "netconfig" or "netconf" to create configuration script ifcfg-eth0
|
||||
6. Run depmod to updated module indexes.
|
||||
7. Run "netconfig" or "netconf" to create configuration script ifcfg-eth0
|
||||
located at /etc/sysconfig/network-scripts or create it manually.
|
||||
[see - Configuration Script Sample]
|
||||
7. Driver will automatically load and configure at next boot time.
|
||||
8. Driver will automatically load and configure at next boot time.
|
||||
|
||||
Compiling the Driver
|
||||
====================
|
||||
|
|
@ -154,8 +155,8 @@ Installing the Driver
|
|||
-----------------
|
||||
1. Copy dl2k.o to the network modules directory, typically
|
||||
/lib/modules/2.x.x-xx/net or /lib/modules/2.x.x/kernel/drivers/net.
|
||||
2. Locate the boot module configuration file, most commonly modprobe.conf
|
||||
or modules.conf (for 2.4) in the /etc directory. Add the following lines:
|
||||
2. Locate the boot module configuration file, most commonly in the
|
||||
/etc/modprobe.d/ directory. Add the following lines:
|
||||
|
||||
alias ethx dl2k
|
||||
options dl2k <optional parameters>
|
||||
|
|
|
|||
|
|
@ -2,16 +2,16 @@ Document about softnet driver issues
|
|||
|
||||
Transmit path guidelines:
|
||||
|
||||
1) The hard_start_xmit method must never return '1' under any
|
||||
normal circumstances. It is considered a hard error unless
|
||||
1) The ndo_start_xmit method must not return NETDEV_TX_BUSY under
|
||||
any normal circumstances. It is considered a hard error unless
|
||||
there is no way your device can tell ahead of time when it's
|
||||
transmit function will become busy.
|
||||
|
||||
Instead it must maintain the queue properly. For example,
|
||||
for a driver implementing scatter-gather this means:
|
||||
|
||||
static int drv_hard_start_xmit(struct sk_buff *skb,
|
||||
struct net_device *dev)
|
||||
static netdev_tx_t drv_hard_start_xmit(struct sk_buff *skb,
|
||||
struct net_device *dev)
|
||||
{
|
||||
struct drv *dp = netdev_priv(dev);
|
||||
|
||||
|
|
@ -23,7 +23,7 @@ Transmit path guidelines:
|
|||
unlock_tx(dp);
|
||||
printk(KERN_ERR PFX "%s: BUG! Tx Ring full when queue awake!\n",
|
||||
dev->name);
|
||||
return 1;
|
||||
return NETDEV_TX_BUSY;
|
||||
}
|
||||
|
||||
... queue packet to card ...
|
||||
|
|
@ -35,6 +35,7 @@ Transmit path guidelines:
|
|||
...
|
||||
unlock_tx(dp);
|
||||
...
|
||||
return NETDEV_TX_OK;
|
||||
}
|
||||
|
||||
And then at the end of your TX reclamation event handling:
|
||||
|
|
@ -58,15 +59,12 @@ Transmit path guidelines:
|
|||
TX_BUFFS_AVAIL(dp) > 0)
|
||||
netif_wake_queue(dp->dev);
|
||||
|
||||
2) Do not forget to update netdev->trans_start to jiffies after
|
||||
each new tx packet is given to the hardware.
|
||||
|
||||
3) A hard_start_xmit method must not modify the shared parts of a
|
||||
2) An ndo_start_xmit method must not modify the shared parts of a
|
||||
cloned SKB.
|
||||
|
||||
4) Do not forget that once you return 0 from your hard_start_xmit
|
||||
method, it is your driver's responsibility to free up the SKB
|
||||
and in some finite amount of time.
|
||||
3) Do not forget that once you return NETDEV_TX_OK from your
|
||||
ndo_start_xmit method, it is your driver's responsibility to free
|
||||
up the SKB and in some finite amount of time.
|
||||
|
||||
For example, this means that it is not allowed for your TX
|
||||
mitigation scheme to let TX packets "hang out" in the TX
|
||||
|
|
@ -74,8 +72,9 @@ Transmit path guidelines:
|
|||
This error can deadlock sockets waiting for send buffer room
|
||||
to be freed up.
|
||||
|
||||
If you return 1 from the hard_start_xmit method, you must not keep
|
||||
any reference to that SKB and you must not attempt to free it up.
|
||||
If you return NETDEV_TX_BUSY from the ndo_start_xmit method, you
|
||||
must not keep any reference to that SKB and you must not attempt
|
||||
to free it up.
|
||||
|
||||
Probing guidelines:
|
||||
|
||||
|
|
@ -85,10 +84,10 @@ Probing guidelines:
|
|||
|
||||
Close/stop guidelines:
|
||||
|
||||
1) After the dev->stop routine has been called, the hardware must
|
||||
1) After the ndo_stop routine has been called, the hardware must
|
||||
not receive or transmit any data. All in flight packets must
|
||||
be aborted. If necessary, poll or wait for completion of
|
||||
any reset commands.
|
||||
|
||||
2) The dev->stop routine will be called by unregister_netdevice
|
||||
2) The ndo_stop routine will be called by unregister_netdevice
|
||||
if device is still UP.
|
||||
|
|
|
|||
|
|
@ -94,8 +94,8 @@ Additional Configurations
|
|||
|
||||
Configuring a network driver to load properly when the system is started is
|
||||
distribution dependent. Typically, the configuration process involves adding
|
||||
an alias line to /etc/modules.conf or /etc/modprobe.conf as well as editing
|
||||
other system startup scripts and/or configuration files. Many popular Linux
|
||||
an alias line to /etc/modprobe.d/*.conf as well as editing other system
|
||||
startup scripts and/or configuration files. Many popular Linux
|
||||
distributions ship with tools to make these changes for you. To learn the
|
||||
proper way to configure a network device for your system, refer to your
|
||||
distribution documentation. If during this process you are asked for the
|
||||
|
|
@ -103,7 +103,7 @@ Additional Configurations
|
|||
PRO/100 Family of Adapters is e100.
|
||||
|
||||
As an example, if you install the e100 driver for two PRO/100 adapters
|
||||
(eth0 and eth1), add the following to modules.conf or modprobe.conf:
|
||||
(eth0 and eth1), add the following to a configuraton file in /etc/modprobe.d/
|
||||
|
||||
alias eth0 e100
|
||||
alias eth1 e100
|
||||
|
|
|
|||
|
|
@ -604,15 +604,8 @@ IP Variables:
|
|||
ip_local_port_range - 2 INTEGERS
|
||||
Defines the local port range that is used by TCP and UDP to
|
||||
choose the local port. The first number is the first, the
|
||||
second the last local port number. Default value depends on
|
||||
amount of memory available on the system:
|
||||
> 128Mb 32768-61000
|
||||
< 128Mb 1024-4999 or even less.
|
||||
This number defines number of active connections, which this
|
||||
system can issue simultaneously to systems not supporting
|
||||
TCP extensions (timestamps). With tcp_tw_recycle enabled
|
||||
(i.e. by default) range 1024-4999 is enough to issue up to
|
||||
2000 connections per second to systems supporting timestamps.
|
||||
second the last local port number. The default values are
|
||||
32768 and 61000 respectively.
|
||||
|
||||
ip_local_reserved_ports - list of comma separated ranges
|
||||
Specify the ports which are reserved for known third-party
|
||||
|
|
|
|||
|
|
@ -2,9 +2,9 @@
|
|||
Options for the ipv6 module are supplied as parameters at load time.
|
||||
|
||||
Module options may be given as command line arguments to the insmod
|
||||
or modprobe command, but are usually specified in either the
|
||||
/etc/modules.conf or /etc/modprobe.conf configuration file, or in a
|
||||
distro-specific configuration file.
|
||||
or modprobe command, but are usually specified in either
|
||||
/etc/modules.d/*.conf configuration files, or in a distro-specific
|
||||
configuration file.
|
||||
|
||||
The available ipv6 module parameters are listed below. If a parameter
|
||||
is not specified the default value is used.
|
||||
|
|
|
|||
|
|
@ -274,9 +274,9 @@ Additional Configurations
|
|||
-------------------------------------------------
|
||||
Configuring a network driver to load properly when the system is started is
|
||||
distribution dependent. Typically, the configuration process involves adding
|
||||
an alias line to /etc/modprobe.conf as well as editing other system startup
|
||||
scripts and/or configuration files. Many popular Linux distributions ship
|
||||
with tools to make these changes for you. To learn the proper way to
|
||||
an alias line to files in /etc/modprobe.d/ as well as editing other system
|
||||
startup scripts and/or configuration files. Many popular Linux distributions
|
||||
ship with tools to make these changes for you. To learn the proper way to
|
||||
configure a network device for your system, refer to your distribution
|
||||
documentation. If during this process you are asked for the driver or module
|
||||
name, the name for the Linux Base Driver for the Intel 10GbE Family of
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ the driver will try to determine them itself.
|
|||
|
||||
If you load the driver as a module, you can pass the parameters "io=",
|
||||
"irq=", and "dma=" on the command line with insmod or modprobe, or add
|
||||
them as options in /etc/modprobe.conf:
|
||||
them as options in a configuration file in /etc/modprobe.d/ directory:
|
||||
|
||||
alias lt0 ltpc # autoload the module when the interface is configured
|
||||
options ltpc io=0x240 irq=9 dma=1
|
||||
|
|
|
|||
|
|
@ -47,26 +47,25 @@ packets is preferred.
|
|||
|
||||
struct net_device synchronization rules
|
||||
=======================================
|
||||
dev->open:
|
||||
ndo_open:
|
||||
Synchronization: rtnl_lock() semaphore.
|
||||
Context: process
|
||||
|
||||
dev->stop:
|
||||
ndo_stop:
|
||||
Synchronization: rtnl_lock() semaphore.
|
||||
Context: process
|
||||
Note1: netif_running() is guaranteed false
|
||||
Note2: dev->poll() is guaranteed to be stopped
|
||||
Note: netif_running() is guaranteed false
|
||||
|
||||
dev->do_ioctl:
|
||||
ndo_do_ioctl:
|
||||
Synchronization: rtnl_lock() semaphore.
|
||||
Context: process
|
||||
|
||||
dev->get_stats:
|
||||
ndo_get_stats:
|
||||
Synchronization: dev_base_lock rwlock.
|
||||
Context: nominally process, but don't sleep inside an rwlock
|
||||
|
||||
dev->hard_start_xmit:
|
||||
Synchronization: netif_tx_lock spinlock.
|
||||
ndo_start_xmit:
|
||||
Synchronization: __netif_tx_lock spinlock.
|
||||
|
||||
When the driver sets NETIF_F_LLTX in dev->features this will be
|
||||
called without holding netif_tx_lock. In this case the driver
|
||||
|
|
@ -87,20 +86,20 @@ dev->hard_start_xmit:
|
|||
o NETDEV_TX_LOCKED Locking failed, please retry quickly.
|
||||
Only valid when NETIF_F_LLTX is set.
|
||||
|
||||
dev->tx_timeout:
|
||||
Synchronization: netif_tx_lock spinlock.
|
||||
ndo_tx_timeout:
|
||||
Synchronization: netif_tx_lock spinlock; all TX queues frozen.
|
||||
Context: BHs disabled
|
||||
Notes: netif_queue_stopped() is guaranteed true
|
||||
|
||||
dev->set_rx_mode:
|
||||
Synchronization: netif_tx_lock spinlock.
|
||||
ndo_set_rx_mode:
|
||||
Synchronization: netif_addr_lock spinlock.
|
||||
Context: BHs disabled
|
||||
|
||||
struct napi_struct synchronization rules
|
||||
========================================
|
||||
napi->poll:
|
||||
Synchronization: NAPI_STATE_SCHED bit in napi->state. Device
|
||||
driver's dev->close method will invoke napi_disable() on
|
||||
driver's ndo_stop method will invoke napi_disable() on
|
||||
all NAPI instances which will do a sleeping poll on the
|
||||
NAPI_STATE_SCHED napi->state bit, waiting for all pending
|
||||
NAPI activity to cease.
|
||||
|
|
|
|||
|
|
@ -67,8 +67,8 @@ Module parameters
|
|||
=================
|
||||
|
||||
There are several parameters which may be provided to the driver when
|
||||
its module is loaded. These are usually placed in /etc/modprobe.conf
|
||||
(/etc/modules.conf in 2.4). Example:
|
||||
its module is loaded. These are usually placed in /etc/modprobe.d/*.conf
|
||||
configuretion files. Example:
|
||||
|
||||
options 3c59x debug=3 rx_copybreak=300
|
||||
|
||||
|
|
@ -425,7 +425,7 @@ steps you should take:
|
|||
1) Increase the debug level. Usually this is done via:
|
||||
|
||||
a) modprobe driver debug=7
|
||||
b) In /etc/modprobe.conf (or /etc/modules.conf for 2.4):
|
||||
b) In /etc/modprobe.d/driver.conf:
|
||||
options driver debug=7
|
||||
|
||||
2) Recreate the problem with the higher debug level,
|
||||
|
|
|
|||
|
|
@ -36,18 +36,17 @@ addresses should not be specified for supported PCI cards since they
|
|||
are automatically detected.
|
||||
|
||||
|
||||
KMod
|
||||
----
|
||||
modprobe
|
||||
--------
|
||||
|
||||
If you use kmod, you will find it useful to edit /etc/modprobe.conf.
|
||||
Here is an example of the lines that need to be added:
|
||||
If you use modprobe , you will find it useful to add lines as below to a
|
||||
configuration file in /etc/modprobe.d/ directory:.
|
||||
|
||||
alias parport_lowlevel parport_pc
|
||||
options parport_pc io=0x378,0x278 irq=7,auto
|
||||
|
||||
KMod will then automatically load parport_pc (with the options
|
||||
"io=0x378,0x278 irq=7,auto") whenever a parallel port device driver
|
||||
(such as lp) is loaded.
|
||||
modprobe will load parport_pc (with the options "io=0x378,0x278 irq=7,auto")
|
||||
whenever a parallel port device driver (such as lp) is loaded.
|
||||
|
||||
Note that these are example lines only! You shouldn't in general need
|
||||
to specify any options to parport_pc in order to be able to use a
|
||||
|
|
|
|||
|
|
@ -47,9 +47,9 @@ including the console 3270, changes subchannel identifier relative to
|
|||
one another. ReIPL as soon as possible after running the configuration
|
||||
script and the resulting /tmp/mkdev3270.
|
||||
|
||||
If you have chosen to make tub3270 a module, you add a line to
|
||||
/etc/modprobe.conf. If you are working on a VM virtual machine, you
|
||||
can use DEF GRAF to define virtual 3270 devices.
|
||||
If you have chosen to make tub3270 a module, you add a line to a
|
||||
configuration file under /etc/modprobe.d/. If you are working on a VM
|
||||
virtual machine, you can use DEF GRAF to define virtual 3270 devices.
|
||||
|
||||
You may generate both 3270 and 3215 console support, or one or the
|
||||
other, or neither. If you generate both, the console type under VM is
|
||||
|
|
@ -60,7 +60,7 @@ at boot time to a 3270 if it is a 3215.
|
|||
|
||||
In brief, these are the steps:
|
||||
1. Install the tub3270 patch
|
||||
2. (If a module) add a line to /etc/modprobe.conf
|
||||
2. (If a module) add a line to a file in /etc/modprobe.d/*.conf
|
||||
3. (If VM) define devices with DEF GRAF
|
||||
4. Reboot
|
||||
5. Configure
|
||||
|
|
@ -84,13 +84,12 @@ Here are the installation steps in detail:
|
|||
make modules_install
|
||||
|
||||
2. (Perform this step only if you have configured tub3270 as a
|
||||
module.) Add a line to /etc/modprobe.conf to automatically
|
||||
load the driver when it's needed. With this line added,
|
||||
you will see login prompts appear on your 3270s as soon as
|
||||
boot is complete (or with emulated 3270s, as soon as you dial
|
||||
into your vm guest using the command "DIAL <vmguestname>").
|
||||
Since the line-mode major number is 227, the line to add to
|
||||
/etc/modprobe.conf should be:
|
||||
module.) Add a line to a file /etc/modprobe.d/*.conf to automatically
|
||||
load the driver when it's needed. With this line added, you will see
|
||||
login prompts appear on your 3270s as soon as boot is complete (or
|
||||
with emulated 3270s, as soon as you dial into your vm guest using the
|
||||
command "DIAL <vmguestname>"). Since the line-mode major number is
|
||||
227, the line to add should be:
|
||||
alias char-major-227 tub3270
|
||||
|
||||
3. Define graphic devices to your vm guest machine, if you
|
||||
|
|
|
|||
|
|
@ -94,3 +94,5 @@ sym53c8xx_2.txt
|
|||
- info on second generation driver for sym53c8xx based adapters
|
||||
tmscsim.txt
|
||||
- info on driver for AM53c974 based adapters
|
||||
ufs.txt
|
||||
- info on Universal Flash Storage(UFS) and UFS host controller driver.
|
||||
|
|
|
|||
|
|
@ -215,7 +215,7 @@ The following information is available in this file:
|
|||
INCORRECTLY CAN RENDER YOUR SYSTEM INOPERABLE.
|
||||
USE THEM WITH CAUTION.
|
||||
|
||||
Edit the file "modprobe.conf" in the directory /etc and add/edit a
|
||||
Put a .conf file in the /etc/modprobe.d/ directory and add/edit a
|
||||
line containing 'options aic79xx aic79xx=[command[,command...]]' where
|
||||
'command' is one or more of the following:
|
||||
-----------------------------------------------------------------
|
||||
|
|
|
|||
|
|
@ -190,7 +190,7 @@ The following information is available in this file:
|
|||
INCORRECTLY CAN RENDER YOUR SYSTEM INOPERABLE.
|
||||
USE THEM WITH CAUTION.
|
||||
|
||||
Edit the file "modprobe.conf" in the directory /etc and add/edit a
|
||||
Put a .conf file in the /etc/modprobe.d directory and add/edit a
|
||||
line containing 'options aic7xxx aic7xxx=[command[,command...]]' where
|
||||
'command' is one or more of the following:
|
||||
-----------------------------------------------------------------
|
||||
|
|
|
|||
|
|
@ -66,7 +66,7 @@ recognized.
|
|||
If you want to have the module autoloaded on access to /dev/osst, you may
|
||||
add something like
|
||||
alias char-major-206 osst
|
||||
to your /etc/modprobe.conf (before 2.6: modules.conf).
|
||||
to a file under /etc/modprobe.d/ directory.
|
||||
|
||||
You may find it convenient to create a symbolic link
|
||||
ln -s nosst0 /dev/tape
|
||||
|
|
|
|||
|
|
@ -390,6 +390,10 @@ MTSETDRVBUFFER
|
|||
MT_ST_SYSV sets the SYSV semantics (mode)
|
||||
MT_ST_NOWAIT enables immediate mode (i.e., don't wait for
|
||||
the command to finish) for some commands (e.g., rewind)
|
||||
MT_ST_NOWAIT_EOF enables immediate filemark mode (i.e. when
|
||||
writing a filemark, don't wait for it to complete). Please
|
||||
see the BASICS note about MTWEOFI with respect to the
|
||||
possible dangers of writing immediate filemarks.
|
||||
MT_ST_SILI enables setting the SILI bit in SCSI commands when
|
||||
reading in variable block mode to enhance performance when
|
||||
reading blocks shorter than the byte count; set this only
|
||||
|
|
|
|||
|
|
@ -0,0 +1,133 @@
|
|||
Universal Flash Storage
|
||||
=======================
|
||||
|
||||
|
||||
Contents
|
||||
--------
|
||||
|
||||
1. Overview
|
||||
2. UFS Architecture Overview
|
||||
2.1 Application Layer
|
||||
2.2 UFS Transport Protocol(UTP) layer
|
||||
2.3 UFS Interconnect(UIC) Layer
|
||||
3. UFSHCD Overview
|
||||
3.1 UFS controller initialization
|
||||
3.2 UTP Transfer requests
|
||||
3.3 UFS error handling
|
||||
3.4 SCSI Error handling
|
||||
|
||||
|
||||
1. Overview
|
||||
-----------
|
||||
|
||||
Universal Flash Storage(UFS) is a storage specification for flash devices.
|
||||
It is aimed to provide a universal storage interface for both
|
||||
embedded and removable flash memory based storage in mobile
|
||||
devices such as smart phones and tablet computers. The specification
|
||||
is defined by JEDEC Solid State Technology Association. UFS is based
|
||||
on MIPI M-PHY physical layer standard. UFS uses MIPI M-PHY as the
|
||||
physical layer and MIPI Unipro as the link layer.
|
||||
|
||||
The main goals of UFS is to provide,
|
||||
* Optimized performance:
|
||||
For UFS version 1.0 and 1.1 the target performance is as follows,
|
||||
Support for Gear1 is mandatory (rate A: 1248Mbps, rate B: 1457.6Mbps)
|
||||
Support for Gear2 is optional (rate A: 2496Mbps, rate B: 2915.2Mbps)
|
||||
Future version of the standard,
|
||||
Gear3 (rate A: 4992Mbps, rate B: 5830.4Mbps)
|
||||
* Low power consumption
|
||||
* High random IOPs and low latency
|
||||
|
||||
|
||||
2. UFS Architecture Overview
|
||||
----------------------------
|
||||
|
||||
UFS has a layered communication architecture which is based on SCSI
|
||||
SAM-5 architectural model.
|
||||
|
||||
UFS communication architecture consists of following layers,
|
||||
|
||||
2.1 Application Layer
|
||||
|
||||
The Application layer is composed of UFS command set layer(UCS),
|
||||
Task Manager and Device manager. The UFS interface is designed to be
|
||||
protocol agnostic, however SCSI has been selected as a baseline
|
||||
protocol for versions 1.0 and 1.1 of UFS protocol layer.
|
||||
UFS supports subset of SCSI commands defined by SPC-4 and SBC-3.
|
||||
* UCS: It handles SCSI commands supported by UFS specification.
|
||||
* Task manager: It handles task management functions defined by the
|
||||
UFS which are meant for command queue control.
|
||||
* Device manager: It handles device level operations and device
|
||||
configuration operations. Device level operations mainly involve
|
||||
device power management operations and commands to Interconnect
|
||||
layers. Device level configurations involve handling of query
|
||||
requests which are used to modify and retrieve configuration
|
||||
information of the device.
|
||||
|
||||
2.2 UFS Transport Protocol(UTP) layer
|
||||
|
||||
UTP layer provides services for
|
||||
the higher layers through Service Access Points. UTP defines 3
|
||||
service access points for higher layers.
|
||||
* UDM_SAP: Device manager service access point is exposed to device
|
||||
manager for device level operations. These device level operations
|
||||
are done through query requests.
|
||||
* UTP_CMD_SAP: Command service access point is exposed to UFS command
|
||||
set layer(UCS) to transport commands.
|
||||
* UTP_TM_SAP: Task management service access point is exposed to task
|
||||
manager to transport task management functions.
|
||||
UTP transports messages through UFS protocol information unit(UPIU).
|
||||
|
||||
2.3 UFS Interconnect(UIC) Layer
|
||||
|
||||
UIC is the lowest layer of UFS layered architecture. It handles
|
||||
connection between UFS host and UFS device. UIC consists of
|
||||
MIPI UniPro and MIPI M-PHY. UIC provides 2 service access points
|
||||
to upper layer,
|
||||
* UIC_SAP: To transport UPIU between UFS host and UFS device.
|
||||
* UIO_SAP: To issue commands to Unipro layers.
|
||||
|
||||
|
||||
3. UFSHCD Overview
|
||||
------------------
|
||||
|
||||
The UFS host controller driver is based on Linux SCSI Framework.
|
||||
UFSHCD is a low level device driver which acts as an interface between
|
||||
SCSI Midlayer and PCIe based UFS host controllers.
|
||||
|
||||
The current UFSHCD implementation supports following functionality,
|
||||
|
||||
3.1 UFS controller initialization
|
||||
|
||||
The initialization module brings UFS host controller to active state
|
||||
and prepares the controller to transfer commands/response between
|
||||
UFSHCD and UFS device.
|
||||
|
||||
3.2 UTP Transfer requests
|
||||
|
||||
Transfer request handling module of UFSHCD receives SCSI commands
|
||||
from SCSI Midlayer, forms UPIUs and issues the UPIUs to UFS Host
|
||||
controller. Also, the module decodes, responses received from UFS
|
||||
host controller in the form of UPIUs and intimates the SCSI Midlayer
|
||||
of the status of the command.
|
||||
|
||||
3.3 UFS error handling
|
||||
|
||||
Error handling module handles Host controller fatal errors,
|
||||
Device fatal errors and UIC interconnect layer related errors.
|
||||
|
||||
3.4 SCSI Error handling
|
||||
|
||||
This is done through UFSHCD SCSI error handling routines registered
|
||||
with SCSI Midlayer. Examples of some of the error handling commands
|
||||
issues by SCSI Midlayer are Abort task, Lun reset and host reset.
|
||||
UFSHCD Routines to perform these tasks are registered with
|
||||
SCSI Midlayer through .eh_abort_handler, .eh_device_reset_handler and
|
||||
.eh_host_reset_handler.
|
||||
|
||||
In this version of UFSHCD Query requests and power management
|
||||
functionality are not implemented.
|
||||
|
||||
UFS Specifications can be found at,
|
||||
UFS - http://www.jedec.org/sites/default/files/docs/JESD220.pdf
|
||||
UFSHCI - http://www.jedec.org/sites/default/files/docs/JESD223.pdf
|
||||
|
|
@ -49,7 +49,7 @@ Hardware - If you have an ISA card, find a free interrupt and io port.
|
|||
|
||||
Note the hardware address from the Computone ISA cards installed into
|
||||
the system. These are required for editing ip2.c or editing
|
||||
/etc/modprobe.conf, or for specification on the modprobe
|
||||
/etc/modprobe.d/*.conf, or for specification on the modprobe
|
||||
command line.
|
||||
|
||||
Note that the /etc/modules.conf should be used for older (pre-2.6)
|
||||
|
|
@ -66,7 +66,7 @@ b) Run "make config" or "make menuconfig" or "make xconfig"
|
|||
c) Set address on ISA cards then:
|
||||
edit /usr/src/linux/drivers/char/ip2.c if needed
|
||||
or
|
||||
edit /etc/modprobe.conf if needed (module).
|
||||
edit config file in /etc/modprobe.d/ if needed (module).
|
||||
or both to match this setting.
|
||||
d) Run "make modules"
|
||||
e) Run "make modules_install"
|
||||
|
|
@ -153,11 +153,11 @@ the irqs are not specified the driver uses the default in ip2.c (which
|
|||
selects polled mode). If no base addresses are specified the defaults in
|
||||
ip2.c are used. If you are autoloading the driver module with kerneld or
|
||||
kmod the base addresses and interrupt number must also be set in ip2.c
|
||||
and recompile or just insert and options line in /etc/modprobe.conf or both.
|
||||
and recompile or just insert and options line in /etc/modprobe.d/*.conf or both.
|
||||
The options line is equivalent to the command line and takes precedence over
|
||||
what is in ip2.c.
|
||||
|
||||
/etc/modprobe.conf sample:
|
||||
config sample to put /etc/modprobe.d/*.conf:
|
||||
options ip2 io=1,0x328 irq=1,10
|
||||
alias char-major-71 ip2
|
||||
alias char-major-72 ip2
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ in the system log at /var/log/messages.
|
|||
|
||||
If installed as a module, the module must be loaded. This can be done
|
||||
manually by entering "modprobe rocket". To have the module loaded automatically
|
||||
upon system boot, edit the /etc/modprobe.conf file and add the line
|
||||
upon system boot, edit a /etc/modprobe.d/*.conf file and add the line
|
||||
"alias char-major-46 rocket".
|
||||
|
||||
In order to use the ports, their device names (nodes) must be created with mknod.
|
||||
|
|
|
|||
|
|
@ -139,8 +139,8 @@ secondary address 0x280 and IRQ 10.
|
|||
|
||||
You will probably want to enter this module load and configuration information
|
||||
into your system startup scripts so that the drivers are loaded and configured
|
||||
on each system boot. Typically the start up script would be something like
|
||||
/etc/modprobe.conf.
|
||||
on each system boot. Typically configuration files are put in the
|
||||
/etc/modprobe.d/ directory.
|
||||
|
||||
|
||||
2.2 STATIC DRIVER CONFIGURATION:
|
||||
|
|
|
|||
|
|
@ -2044,7 +2044,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
Install the necessary firmware files in alsa-firmware package.
|
||||
When no hotplug fw loader is available, you need to load the
|
||||
firmware via vxloader utility in alsa-tools package. To invoke
|
||||
vxloader automatically, add the following to /etc/modprobe.conf
|
||||
vxloader automatically, add the following to /etc/modprobe.d/alsa.conf
|
||||
|
||||
install snd-vx222 /sbin/modprobe --first-time -i snd-vx222 && /usr/bin/vxloader
|
||||
|
||||
|
|
@ -2168,10 +2168,10 @@ corresponds to the card index of ALSA. Usually, define this
|
|||
as the same card module.
|
||||
|
||||
An example configuration for a single emu10k1 card is like below:
|
||||
----- /etc/modprobe.conf
|
||||
----- /etc/modprobe.d/alsa.conf
|
||||
alias snd-card-0 snd-emu10k1
|
||||
alias sound-slot-0 snd-emu10k1
|
||||
----- /etc/modprobe.conf
|
||||
----- /etc/modprobe.d/alsa.conf
|
||||
|
||||
The available number of auto-loaded sound cards depends on the module
|
||||
option "cards_limit" of snd module. As default it's set to 1.
|
||||
|
|
@ -2184,7 +2184,7 @@ cards is kept consistent.
|
|||
|
||||
An example configuration for two sound cards is like below:
|
||||
|
||||
----- /etc/modprobe.conf
|
||||
----- /etc/modprobe.d/alsa.conf
|
||||
# ALSA portion
|
||||
options snd cards_limit=2
|
||||
alias snd-card-0 snd-interwave
|
||||
|
|
@ -2194,7 +2194,7 @@ options snd-ens1371 index=1
|
|||
# OSS/Free portion
|
||||
alias sound-slot-0 snd-interwave
|
||||
alias sound-slot-1 snd-ens1371
|
||||
----- /etc/modprobe.conf
|
||||
----- /etc/modprobe.d/alsa.conf
|
||||
|
||||
In this example, the interwave card is always loaded as the first card
|
||||
(index 0) and ens1371 as the second (index 1).
|
||||
|
|
|
|||
|
|
@ -232,7 +232,7 @@ The parameter can be given:
|
|||
# modprobe snd-usb-audio index=1 device_setup=0x09
|
||||
|
||||
* Or while configuring the modules options in your modules configuration file
|
||||
- For Fedora distributions, edit the /etc/modprobe.conf file:
|
||||
(tipically a .conf file in /etc/modprobe.d/ directory:
|
||||
alias snd-card-1 snd-usb-audio
|
||||
options snd-usb-audio index=1 device_setup=0x09
|
||||
|
||||
|
|
@ -253,7 +253,7 @@ CAUTION when initializing the device
|
|||
- first turn off the device
|
||||
- de-register the snd-usb-audio module (modprobe -r)
|
||||
- change the device_setup parameter by changing the device_setup
|
||||
option in /etc/modprobe.conf
|
||||
option in /etc/modprobe.d/*.conf
|
||||
- turn on the device
|
||||
* A workaround for this last issue has been applied to kernel 2.6.23, but it may not
|
||||
be enough to ensure the 'stability' of the device initialization.
|
||||
|
|
|
|||
|
|
@ -76,9 +76,9 @@ FIRMWARE
|
|||
when CONFIG_FW_LOADER is set. The mixartloader is necessary only
|
||||
for older versions or when you build the driver into kernel.]
|
||||
|
||||
For loading the firmware automatically after the module is loaded, use
|
||||
the post-install command. For example, add the following entry to
|
||||
/etc/modprobe.conf for miXart driver:
|
||||
For loading the firmware automatically after the module is loaded, use a
|
||||
install command. For example, add the following entry to
|
||||
/etc/modprobe.d/mixart.conf for miXart driver:
|
||||
|
||||
install snd-mixart /sbin/modprobe --first-time -i snd-mixart && \
|
||||
/usr/bin/mixartloader
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ the card number and the minor unit number. Usually you don't have to
|
|||
define these aliases by yourself.
|
||||
|
||||
Only necessary step for auto-loading of OSS modules is to define the
|
||||
card alias in /etc/modprobe.conf, such as
|
||||
card alias in /etc/modprobe.d/alsa.conf, such as
|
||||
|
||||
alias sound-slot-0 snd-emu10k1
|
||||
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ mpu_base I/O base address for activate MPU-401 mode
|
|||
(0x300, 0x310, 0x320 or 0x330)
|
||||
mpu_irq MPU-401 irq line (5, 7, 9, 10 or 0)
|
||||
|
||||
The /etc/modprobe.conf will have lines like this:
|
||||
A configuration file in /etc/modprobe.d/ directory will have lines like this:
|
||||
|
||||
options opl3 io=0x388
|
||||
options ad1848 io=0x530 irq=11 dma=3
|
||||
|
|
@ -51,11 +51,11 @@ Where the aedsp16 options are the options for this driver while opl3 and
|
|||
ad1848 are the corresponding options for the MSS and OPL3 modules.
|
||||
|
||||
Loading MSS and OPL3 needs to pre load the aedsp16 module to set up correctly
|
||||
the sound card. Installation dependencies must be written in the modprobe.conf
|
||||
file:
|
||||
the sound card. Installation dependencies must be written in configuration
|
||||
files under /etc/modprobe.d/ directory:
|
||||
|
||||
install ad1848 /sbin/modprobe aedsp16 && /sbin/modprobe -i ad1848
|
||||
install opl3 /sbin/modprobe aedsp16 && /sbin/modprobe -i opl3
|
||||
softdep ad1848 pre: aedsp16
|
||||
softdep opl3 pre: aedsp16
|
||||
|
||||
Then you must load the sound modules stack in this order:
|
||||
sound -> aedsp16 -> [ ad1848, opl3 ]
|
||||
|
|
|
|||
|
|
@ -143,11 +143,10 @@ CONFIG_SOUND_MSS=m
|
|||
|
||||
|
||||
|
||||
Alma Chao <elysian@ethereal.torsion.org> suggests the following /etc/modprobe.conf:
|
||||
Alma Chao <elysian@ethereal.torsion.org> suggests the following in
|
||||
a /etc/modprobe.d/*conf file:
|
||||
|
||||
alias sound ad1848
|
||||
alias synth0 opl3
|
||||
options ad1848 io=0x530 irq=7 dma=0 soundpro=1
|
||||
options opl3 io=0x388
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -167,8 +167,8 @@ in a file such as /root/soundon.sh.
|
|||
MODPROBE:
|
||||
=========
|
||||
|
||||
If loading via modprobe, these common files are automatically loaded
|
||||
when requested by modprobe. For example, my /etc/modprobe.conf contains:
|
||||
If loading via modprobe, these common files are automatically loaded when
|
||||
requested by modprobe. For example, my /etc/modprobe.d/oss.conf contains:
|
||||
|
||||
alias sound sb
|
||||
options sb io=0x240 irq=9 dma=3 dma16=5 mpu_io=0x300
|
||||
|
|
@ -228,7 +228,7 @@ http://www.opensound.com. Before loading the commercial sound
|
|||
driver, you should do the following:
|
||||
|
||||
1. remove sound modules (detailed above)
|
||||
2. remove the sound modules from /etc/modprobe.conf
|
||||
2. remove the sound modules from /etc/modprobe.d/*.conf
|
||||
3. move the sound modules from /lib/modules/<kernel>/misc
|
||||
(for example, I make a /lib/modules/<kernel>/misc/tmp
|
||||
directory and copy the sound module files to that
|
||||
|
|
@ -265,7 +265,7 @@ twice, you need to do the following:
|
|||
sb.o could be copied (or symlinked) to sb1.o for the
|
||||
second SoundBlaster.
|
||||
|
||||
2. Make a second entry in /etc/modprobe.conf, for example,
|
||||
2. Make a second entry in /etc/modprobe.d/*conf, for example,
|
||||
sound1 or sb1. This second entry should refer to the
|
||||
new module names for example sb1, and should include
|
||||
the I/O, etc. for the second sound card.
|
||||
|
|
@ -369,7 +369,7 @@ There are several ways of configuring your sound:
|
|||
2) On the command line when using insmod or in a bash script
|
||||
using command line calls to load sound.
|
||||
|
||||
3) In /etc/modprobe.conf when using modprobe.
|
||||
3) In /etc/modprobe.d/*conf when using modprobe.
|
||||
|
||||
4) Via Red Hat's GPL'd /usr/sbin/sndconfig program (text based).
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ force the card into a mode in which it can be programmed.
|
|||
If you have another OS installed on your computer it is recommended
|
||||
that Linux and the other OS use the same resources.
|
||||
|
||||
Also, it is recommended that resources specified in /etc/modprobe.conf
|
||||
Also, it is recommended that resources specified in /etc/modprobe.d/*.conf
|
||||
and resources specified in /etc/isapnp.conf agree.
|
||||
|
||||
Compiling the sound driver
|
||||
|
|
@ -67,11 +67,7 @@ address is hard-coded into the driver.
|
|||
|
||||
Using kmod and autoloading the sound driver
|
||||
-------------------------------------------
|
||||
Comment: as of linux-2.1.90 kmod is replacing kerneld.
|
||||
The config file '/etc/modprobe.conf' is used as before.
|
||||
|
||||
This is the sound part of my /etc/modprobe.conf file.
|
||||
Following that I will explain each line.
|
||||
Config files in '/etc/modprobe.d/' are used as below:
|
||||
|
||||
alias mixer0 mad16
|
||||
alias audio0 mad16
|
||||
|
|
|
|||
|
|
@ -128,7 +128,7 @@ CONFIG_SOUND_YM3812
|
|||
You can then get OPL3 functionality by issuing the command:
|
||||
insmod opl3
|
||||
In addition, you must either add the following line to
|
||||
/etc/modprobe.conf:
|
||||
/etc/modprobe.d/*.conf:
|
||||
options opl3 io=0x388
|
||||
or else add the following line to /etc/lilo.conf:
|
||||
opl3=0x388
|
||||
|
|
@ -158,5 +158,5 @@ following line would be appropriate:
|
|||
append="pas2=0x388,10,3,-1,0,-1,-1,-1 opl3=0x388"
|
||||
|
||||
If sound is built totally modular, the above options may be
|
||||
specified in /etc/modprobe.conf for pas2, sb and opl3
|
||||
specified in /etc/modprobe.d/*.conf for pas2, sb and opl3
|
||||
respectively.
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ Note that it is no longer necessary or possible to configure sound in the
|
|||
drivers/sound dir. Now one simply configures and makes one's kernel and
|
||||
modules in the usual way.
|
||||
|
||||
Then, add to your /etc/modprobe.conf something like:
|
||||
Then, add to your /etc/modprobe.d/oss.conf something like:
|
||||
|
||||
alias char-major-14-* sb
|
||||
install sb /sbin/modprobe -i sb && /sbin/modprobe adlib_card
|
||||
|
|
@ -36,7 +36,7 @@ options adlib_card io=0x388 # FM synthesizer
|
|||
Alternatively, if you have compiled in kernel level ISAPnP support:
|
||||
|
||||
alias char-major-14 sb
|
||||
post-install sb /sbin/modprobe "-k" "adlib_card"
|
||||
softdep sb post: adlib_card
|
||||
options adlib_card io=0x388
|
||||
|
||||
The effect of this is that the sound driver and all necessary bits and
|
||||
|
|
@ -66,12 +66,12 @@ args are expected.
|
|||
Note that at present there is no way to configure the io, irq and other
|
||||
parameters for the modular drivers as one does for the wired drivers.. One
|
||||
needs to pass the modules the necessary parameters as arguments, either
|
||||
with /etc/modprobe.conf or with command-line args to modprobe, e.g.
|
||||
with /etc/modprobe.d/*.conf or with command-line args to modprobe, e.g.
|
||||
|
||||
modprobe sb io=0x220 irq=7 dma=1 dma16=5 mpu_io=0x330
|
||||
modprobe adlib_card io=0x388
|
||||
|
||||
recommend using /etc/modprobe.conf.
|
||||
recommend using /etc/modprobe.d/*.conf.
|
||||
|
||||
Persistent DMA Buffers:
|
||||
|
||||
|
|
@ -89,7 +89,7 @@ wasteful of RAM, but it guarantees that sound always works.
|
|||
|
||||
To make the sound driver use persistent DMA buffers we need to pass the
|
||||
sound.o module a "dmabuf=1" command-line argument. This is normally done
|
||||
in /etc/modprobe.conf like so:
|
||||
in /etc/modprobe.d/*.conf files like so:
|
||||
|
||||
options sound dmabuf=1
|
||||
|
||||
|
|
|
|||
|
|
@ -241,9 +241,8 @@ command you are interested in.
|
|||
|
||||
* I have more questions, who can I ask?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
And I'll answer any questions about the registration system you got, also
|
||||
responding as soon as possible.
|
||||
-Crutcher
|
||||
Just ask them on the linux-kernel mailing list:
|
||||
linux-kernel@vger.kernel.org
|
||||
|
||||
* Credits
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
|
|||
|
|
@ -179,7 +179,8 @@ do:
|
|||
|
||||
modprobe usbcore autosuspend=5
|
||||
|
||||
Equivalently, you could add to /etc/modprobe.conf a line saying:
|
||||
Equivalently, you could add to a configuration file in /etc/modprobe.d
|
||||
a line saying:
|
||||
|
||||
options usbcore autosuspend=5
|
||||
|
||||
|
|
|
|||
|
|
@ -61,29 +61,19 @@ But that is my personal preference.
|
|||
2.2 Configuration
|
||||
|
||||
The configuration requires module configuration and device
|
||||
configuration. I like kmod or kerneld process with the
|
||||
/etc/modprobe.conf file so the modules can automatically load/unload as
|
||||
they are used. The video devices could already exist, be generated
|
||||
using MAKEDEV, or need to be created. The following sections detail
|
||||
these procedures.
|
||||
configuration. The following sections detail these procedures.
|
||||
|
||||
|
||||
2.1 Module Configuration
|
||||
|
||||
Using modules requires a bit of work to install and pass the
|
||||
parameters. Understand that entries in /etc/modprobe.conf of:
|
||||
parameters. Understand that entries in /etc/modprobe.d/*.conf of:
|
||||
|
||||
alias parport_lowlevel parport_pc
|
||||
options parport_pc io=0x378 irq=none
|
||||
alias char-major-81 videodev
|
||||
alias char-major-81-0 c-qcam
|
||||
|
||||
will cause the kmod/modprobe to do certain things. If you are
|
||||
using kmod, then a request for a 'char-major-81-0' will cause
|
||||
the 'c-qcam' module to load. If you have other video sources with
|
||||
modules, you might want to assign the different minor numbers to
|
||||
different modules.
|
||||
|
||||
2.2 Device Configuration
|
||||
|
||||
At this point, we need to ensure that the device files exist.
|
||||
|
|
|
|||
|
|
@ -255,7 +255,7 @@ Load zr36067.o. If it can't autodetect your card, use the card=X insmod
|
|||
option with X being the card number as given in the previous section.
|
||||
To have more than one card, use card=X1[,X2[,X3,[X4[..]]]]
|
||||
|
||||
To automate this, add the following to your /etc/modprobe.conf:
|
||||
To automate this, add the following to your /etc/modprobe.d/zoran.conf:
|
||||
|
||||
options zr36067 card=X1[,X2[,X3[,X4[..]]]]
|
||||
alias char-major-81-0 zr36067
|
||||
|
|
|
|||
Некоторые файлы не были показаны из-за слишком большого количества измененных файлов Показать больше
Загрузка…
Ссылка в новой задаче