Merge tag 'v3.4-rc3' into staging/for_v3.5
* tag 'v3.4-rc3': (3755 commits) Linux 3.4-rc3 x86-32: fix up strncpy_from_user() sign error ARM: 7386/1: jump_label: fixup for rename to static_key ARM: 7384/1: ThumbEE: Disable userspace TEEHBR access for !CONFIG_ARM_THUMBEE ARM: 7382/1: mm: truncate memory banks to fit in 4GB space for classic MMU ARM: 7359/2: smp_twd: Only wait for reprogramming on active cpus PCI: Fix regression in pci_restore_state(), v3 SCSI: Fix error handling when no ULD is attached ARM: OMAP: clock: cleanup CPUfreq leftovers, fix build errors ARM: dts: remove blank interrupt-parent properties ARM: EXYNOS: Fix Kconfig dependencies for device tree enabled machine files do not export kernel's NULL #define to userspace ARM: EXYNOS: Remove broken config values for touchscren for NURI board ARM: EXYNOS: set fix xusbxti clock for NURI and Universal210 boards ARM: EXYNOS: fix regulator name for NURI board ARM: SAMSUNG: make SAMSUNG_PM_DEBUG select DEBUG_LL cpufreq: OMAP: fix build errors: depends on ARCH_OMAP2PLUS sparc64: Eliminate obsolete __handle_softirq() function sparc64: Fix bootup crash on sun4v. ARM: msm: Fix section mismatches in proc_comm.c ...
This commit is contained in:
Mauro Carvalho Chehab
commit
d5aeee8cb2
5693 changed files with 147299 additions and 73259 deletions
|
|
@ -1,5 +1,5 @@
|
||||||
What: /sys/bus/usb/drivers/usbtmc/devices/*/interface_capabilities
|
What: /sys/bus/usb/drivers/usbtmc/*/interface_capabilities
|
||||||
What: /sys/bus/usb/drivers/usbtmc/devices/*/device_capabilities
|
What: /sys/bus/usb/drivers/usbtmc/*/device_capabilities
|
||||||
Date: August 2008
|
Date: August 2008
|
||||||
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||||
Description:
|
Description:
|
||||||
|
|
@ -12,8 +12,8 @@ Description:
|
||||||
The files are read only.
|
The files are read only.
|
||||||
|
|
||||||
|
|
||||||
What: /sys/bus/usb/drivers/usbtmc/devices/*/usb488_interface_capabilities
|
What: /sys/bus/usb/drivers/usbtmc/*/usb488_interface_capabilities
|
||||||
What: /sys/bus/usb/drivers/usbtmc/devices/*/usb488_device_capabilities
|
What: /sys/bus/usb/drivers/usbtmc/*/usb488_device_capabilities
|
||||||
Date: August 2008
|
Date: August 2008
|
||||||
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||||
Description:
|
Description:
|
||||||
|
|
@ -27,7 +27,7 @@ Description:
|
||||||
The files are read only.
|
The files are read only.
|
||||||
|
|
||||||
|
|
||||||
What: /sys/bus/usb/drivers/usbtmc/devices/*/TermChar
|
What: /sys/bus/usb/drivers/usbtmc/*/TermChar
|
||||||
Date: August 2008
|
Date: August 2008
|
||||||
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||||
Description:
|
Description:
|
||||||
|
|
@ -40,7 +40,7 @@ Description:
|
||||||
sent to the device or not.
|
sent to the device or not.
|
||||||
|
|
||||||
|
|
||||||
What: /sys/bus/usb/drivers/usbtmc/devices/*/TermCharEnabled
|
What: /sys/bus/usb/drivers/usbtmc/*/TermCharEnabled
|
||||||
Date: August 2008
|
Date: August 2008
|
||||||
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||||
Description:
|
Description:
|
||||||
|
|
@ -51,11 +51,11 @@ Description:
|
||||||
published by the USB-IF.
|
published by the USB-IF.
|
||||||
|
|
||||||
|
|
||||||
What: /sys/bus/usb/drivers/usbtmc/devices/*/auto_abort
|
What: /sys/bus/usb/drivers/usbtmc/*/auto_abort
|
||||||
Date: August 2008
|
Date: August 2008
|
||||||
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||||
Description:
|
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.
|
device is to be automatically aborted if there is any error.
|
||||||
For more details about this, please see the document,
|
For more details about this, please see the document,
|
||||||
"Universal Serial Bus Test and Measurement Class Specification
|
"Universal Serial Bus Test and Measurement Class Specification
|
||||||
|
|
|
||||||
16
Documentation/ABI/testing/debugfs-olpc
Normal file
16
Documentation/ABI/testing/debugfs-olpc
Normal file
|
|
@ -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.
|
||||||
25
Documentation/ABI/testing/sysfs-block-dm
Normal file
25
Documentation/ABI/testing/sysfs-block-dm
Normal file
|
|
@ -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
|
||||||
18
Documentation/ABI/testing/sysfs-block-rssd
Normal file
18
Documentation/ABI/testing/sysfs-block-rssd
Normal file
|
|
@ -0,0 +1,18 @@
|
||||||
|
What: /sys/block/rssd*/registers
|
||||||
|
Date: March 2012
|
||||||
|
KernelVersion: 3.3
|
||||||
|
Contact: Asai Thambi S P <asamymuthupa@micron.com>
|
||||||
|
Description: This is a read-only file. Dumps below driver information and
|
||||||
|
hardware registers.
|
||||||
|
- S ACTive
|
||||||
|
- Command Issue
|
||||||
|
- Allocated
|
||||||
|
- Completed
|
||||||
|
- PORT IRQ STAT
|
||||||
|
- HOST IRQ STAT
|
||||||
|
|
||||||
|
What: /sys/block/rssd*/status
|
||||||
|
Date: April 2012
|
||||||
|
KernelVersion: 3.4
|
||||||
|
Contact: Asai Thambi S P <asamymuthupa@micron.com>
|
||||||
|
Description: This is a read-only file. Indicates the status of the device.
|
||||||
|
|
@ -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.
|
||||||
75
Documentation/ABI/testing/sysfs-bus-rpmsg
Normal file
75
Documentation/ABI/testing/sysfs-bus-rpmsg
Normal file
|
|
@ -0,0 +1,75 @@
|
||||||
|
What: /sys/bus/rpmsg/devices/.../name
|
||||||
|
Date: June 2011
|
||||||
|
KernelVersion: 3.3
|
||||||
|
Contact: Ohad Ben-Cohen <ohad@wizery.com>
|
||||||
|
Description:
|
||||||
|
Every rpmsg device is a communication channel with a remote
|
||||||
|
processor. Channels are identified with a (textual) name,
|
||||||
|
which is maximum 32 bytes long (defined as RPMSG_NAME_SIZE in
|
||||||
|
rpmsg.h).
|
||||||
|
|
||||||
|
This sysfs entry contains the name of this channel.
|
||||||
|
|
||||||
|
What: /sys/bus/rpmsg/devices/.../src
|
||||||
|
Date: June 2011
|
||||||
|
KernelVersion: 3.3
|
||||||
|
Contact: Ohad Ben-Cohen <ohad@wizery.com>
|
||||||
|
Description:
|
||||||
|
Every rpmsg device is a communication channel with a remote
|
||||||
|
processor. Channels have a local ("source") rpmsg address,
|
||||||
|
and remote ("destination") rpmsg address. When an entity
|
||||||
|
starts listening on one end of a channel, it assigns it with
|
||||||
|
a unique rpmsg address (a 32 bits integer). This way when
|
||||||
|
inbound messages arrive to this address, the rpmsg core
|
||||||
|
dispatches them to the listening entity (a kernel driver).
|
||||||
|
|
||||||
|
This sysfs entry contains the src (local) rpmsg address
|
||||||
|
of this channel. If it contains 0xffffffff, then an address
|
||||||
|
wasn't assigned (can happen if no driver exists for this
|
||||||
|
channel).
|
||||||
|
|
||||||
|
What: /sys/bus/rpmsg/devices/.../dst
|
||||||
|
Date: June 2011
|
||||||
|
KernelVersion: 3.3
|
||||||
|
Contact: Ohad Ben-Cohen <ohad@wizery.com>
|
||||||
|
Description:
|
||||||
|
Every rpmsg device is a communication channel with a remote
|
||||||
|
processor. Channels have a local ("source") rpmsg address,
|
||||||
|
and remote ("destination") rpmsg address. When an entity
|
||||||
|
starts listening on one end of a channel, it assigns it with
|
||||||
|
a unique rpmsg address (a 32 bits integer). This way when
|
||||||
|
inbound messages arrive to this address, the rpmsg core
|
||||||
|
dispatches them to the listening entity.
|
||||||
|
|
||||||
|
This sysfs entry contains the dst (remote) rpmsg address
|
||||||
|
of this channel. If it contains 0xffffffff, then an address
|
||||||
|
wasn't assigned (can happen if the kernel driver that
|
||||||
|
is attached to this channel is exposing a service to the
|
||||||
|
remote processor. This make it a local rpmsg server,
|
||||||
|
and it is listening for inbound messages that may be sent
|
||||||
|
from any remote rpmsg client; it is not bound to a single
|
||||||
|
remote entity).
|
||||||
|
|
||||||
|
What: /sys/bus/rpmsg/devices/.../announce
|
||||||
|
Date: June 2011
|
||||||
|
KernelVersion: 3.3
|
||||||
|
Contact: Ohad Ben-Cohen <ohad@wizery.com>
|
||||||
|
Description:
|
||||||
|
Every rpmsg device is a communication channel with a remote
|
||||||
|
processor. Channels are identified by a textual name (see
|
||||||
|
/sys/bus/rpmsg/devices/.../name above) and have a local
|
||||||
|
("source") rpmsg address, and remote ("destination") rpmsg
|
||||||
|
address.
|
||||||
|
|
||||||
|
A channel is first created when an entity, whether local
|
||||||
|
or remote, starts listening on it for messages (and is thus
|
||||||
|
called an rpmsg server).
|
||||||
|
|
||||||
|
When that happens, a "name service" announcement is sent
|
||||||
|
to the other processor, in order to let it know about the
|
||||||
|
creation of the channel (this way remote clients know they
|
||||||
|
can start sending messages).
|
||||||
|
|
||||||
|
This sysfs entry tells us whether the channel is a local
|
||||||
|
server channel that is announced (values are either
|
||||||
|
true or false).
|
||||||
8
Documentation/ABI/testing/sysfs-cfq-target-latency
Normal file
8
Documentation/ABI/testing/sysfs-cfq-target-latency
Normal file
|
|
@ -0,0 +1,8 @@
|
||||||
|
What: /sys/block/<device>/iosched/target_latency
|
||||||
|
Date: March 2012
|
||||||
|
contact: Tao Ma <boyu.mt@taobao.com>
|
||||||
|
Description:
|
||||||
|
The /sys/block/<device>/iosched/target_latency only exists
|
||||||
|
when the user sets cfq to /sys/block/<device>/scheduler.
|
||||||
|
It contains an estimated latency time for the cfq. cfq will
|
||||||
|
use it to calculate the time slice used for every task.
|
||||||
|
|
@ -17,3 +17,21 @@ Description: Some Samsung laptops have different "performance levels"
|
||||||
Specifically, not all support the "overclock" option,
|
Specifically, not all support the "overclock" option,
|
||||||
and it's still unknown if this value even changes
|
and it's still unknown if this value even changes
|
||||||
anything, other than making the user feel a bit better.
|
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/
|
What: /sys/firmware/acpi/interrupts/
|
||||||
Date: February 2008
|
Date: February 2008
|
||||||
Contact: Len Brown <lenb@kernel.org>
|
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.
|
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
|
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,
|
Since it is optional for platforms to implement DMA_ATTR_WEAK_ORDERING,
|
||||||
those that do not will simply ignore the attribute and exhibit default
|
those that do not will simply ignore the attribute and exhibit default
|
||||||
behavior.
|
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
|
!Edrivers/i2c/i2c-core.c
|
||||||
</chapter>
|
</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>
|
</book>
|
||||||
|
|
|
||||||
|
|
@ -1,3 +1,3 @@
|
||||||
obj-m := DocBook/ accounting/ auxdisplay/ connector/ \
|
obj-m := DocBook/ accounting/ auxdisplay/ connector/ \
|
||||||
filesystems/ filesystems/configfs/ ia64/ laptops/ networking/ \
|
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
|
This file is used to set the second error parameter value. Effect of
|
||||||
parameter depends on error_type specified.
|
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
|
BIOS versions based in the ACPI 4.0 specification have limited options
|
||||||
to control where the errors are injected. Your BIOS may support an
|
to control where the errors are injected. Your BIOS may support an
|
||||||
extension (enabled with the param_extension=1 module parameter, or
|
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
|
sh Documentation/aoe/mkshelf.sh /dev/etherd 0
|
||||||
|
|
||||||
There is also an autoload script that shows how to edit
|
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.
|
necessary.
|
||||||
|
|
||||||
USING DEVICE NODES
|
USING DEVICE NODES
|
||||||
|
|
|
||||||
|
|
@ -1,8 +1,8 @@
|
||||||
#!/bin/sh
|
#!/bin/sh
|
||||||
# set aoe to autoload by installing the
|
# 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
|
if test ! -r $f || test ! -w $f; then
|
||||||
echo "cannot configure $f for module autoloading" 1>&2
|
echo "cannot configure $f for module autoloading" 1>&2
|
||||||
|
|
|
||||||
|
|
@ -49,7 +49,7 @@ you can put:
|
||||||
|
|
||||||
options floppy omnibook messages
|
options floppy omnibook messages
|
||||||
|
|
||||||
in /etc/modprobe.conf.
|
in a configuration file in /etc/modprobe.d/.
|
||||||
|
|
||||||
|
|
||||||
The floppy driver related options are:
|
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
|
The cpus and mems files in the root (top_cpuset) cpuset are
|
||||||
read-only. The cpus file automatically tracks the value of
|
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.,
|
automatically tracks the value of node_states[N_HIGH_MEMORY]--i.e.,
|
||||||
nodes with memory--using the cpuset_track_online_nodes() hook.
|
nodes with memory--using the cpuset_track_online_nodes() hook.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -34,8 +34,7 @@ Current Status: linux-2.6.34-mmotm(development version of 2010/April)
|
||||||
|
|
||||||
Features:
|
Features:
|
||||||
- accounting anonymous pages, file caches, swap caches usage and limiting them.
|
- accounting anonymous pages, file caches, swap caches usage and limiting them.
|
||||||
- private LRU and reclaim routine. (system's global LRU and private LRU
|
- pages are linked to per-memcg LRU exclusively, and there is no global LRU.
|
||||||
work independently from each other)
|
|
||||||
- optionally, memory+swap usage can be accounted and limited.
|
- optionally, memory+swap usage can be accounted and limited.
|
||||||
- hierarchical accounting
|
- hierarchical accounting
|
||||||
- soft limit
|
- soft limit
|
||||||
|
|
@ -154,7 +153,7 @@ updated. page_cgroup has its own LRU on cgroup.
|
||||||
2.2.1 Accounting details
|
2.2.1 Accounting details
|
||||||
|
|
||||||
All mapped anon pages (RSS) and cache pages (Page Cache) are accounted.
|
All mapped anon pages (RSS) and cache pages (Page Cache) are accounted.
|
||||||
Some pages which are never reclaimable and will not be on the global LRU
|
Some pages which are never reclaimable and will not be on the LRU
|
||||||
are not accounted. We just account pages under usual VM management.
|
are not accounted. We just account pages under usual VM management.
|
||||||
|
|
||||||
RSS pages are accounted at page_fault unless they've already been accounted
|
RSS pages are accounted at page_fault unless they've already been accounted
|
||||||
|
|
|
||||||
233
Documentation/clk.txt
Normal file
233
Documentation/clk.txt
Normal file
|
|
@ -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.
|
other cpus later online, read FAQ's for more info.
|
||||||
|
|
||||||
additional_cpus=n (*) Use this to limit hotpluggable cpus. This option sets
|
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
|
cede_offline={"off","on"} Use this option to disable/enable putting offlined
|
||||||
processors to an extended H_CEDE state on
|
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
|
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
|
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
|
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.
|
possible_cpus=n [s390,x86_64] use this to set hotpluggable cpus.
|
||||||
This option sets possible_cpus bits in
|
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.
|
constant even if the machine gets rebooted.
|
||||||
|
|
||||||
CPU maps and such
|
CPU maps and such
|
||||||
|
|
@ -76,7 +76,7 @@ CPU maps and such
|
||||||
[More on cpumaps and primitive to manipulate, please check
|
[More on cpumaps and primitive to manipulate, please check
|
||||||
include/linux/cpumask.h that has more descriptive text.]
|
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
|
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.
|
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
|
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
|
upfront can save some boot time memory. See below for how we use heuristics
|
||||||
in x86_64 case to keep this under check.
|
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
|
after a cpu is available for kernel scheduling and ready to receive
|
||||||
interrupts from devices. Its cleared when a cpu is brought down using
|
interrupts from devices. Its cleared when a cpu is brought down using
|
||||||
__cpu_disable(), before which all OS services including interrupts are
|
__cpu_disable(), before which all OS services including interrupts are
|
||||||
migrated to another target CPU.
|
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
|
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
|
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
|
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
|
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
|
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.
|
Never use anything other than cpumask_t to represent bitmap of CPUs.
|
||||||
|
|
||||||
#include <linux/cpumask.h>
|
#include <linux/cpumask.h>
|
||||||
|
|
||||||
for_each_possible_cpu - Iterate over cpu_possible_map
|
for_each_possible_cpu - Iterate over cpu_possible_mask
|
||||||
for_each_online_cpu - Iterate over cpu_online_map
|
for_each_online_cpu - Iterate over cpu_online_mask
|
||||||
for_each_present_cpu - Iterate over cpu_present_map
|
for_each_present_cpu - Iterate over cpu_present_mask
|
||||||
for_each_cpu_mask(x,mask) - Iterate over some random collection of cpu mask.
|
for_each_cpu_mask(x,mask) - Iterate over some random collection of cpu mask.
|
||||||
|
|
||||||
#include <linux/cpu.h>
|
#include <linux/cpu.h>
|
||||||
get_online_cpus() and put_online_cpus():
|
get_online_cpus() and put_online_cpus():
|
||||||
|
|
||||||
The above calls are used to inhibit cpu hotplug operations. While the
|
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
|
If you merely need to avoid cpus going away, you could also use
|
||||||
preempt_disable() and preempt_enable() for those sections.
|
preempt_disable() and preempt_enable() for those sections.
|
||||||
Just remember the critical section cannot call any
|
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:
|
/sys/devices/system/cpu/cpu0/cpuidle/state0:
|
||||||
total 0
|
total 0
|
||||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 desc
|
-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 latency
|
||||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 name
|
-r--r--r-- 1 root root 4096 Feb 8 10:42 name
|
||||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 power
|
-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:
|
/sys/devices/system/cpu/cpu0/cpuidle/state1:
|
||||||
total 0
|
total 0
|
||||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 desc
|
-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 latency
|
||||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 name
|
-r--r--r-- 1 root root 4096 Feb 8 10:42 name
|
||||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 power
|
-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:
|
/sys/devices/system/cpu/cpu0/cpuidle/state2:
|
||||||
total 0
|
total 0
|
||||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 desc
|
-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 latency
|
||||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 name
|
-r--r--r-- 1 root root 4096 Feb 8 10:42 name
|
||||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 power
|
-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:
|
/sys/devices/system/cpu/cpu0/cpuidle/state3:
|
||||||
total 0
|
total 0
|
||||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 desc
|
-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 latency
|
||||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 name
|
-r--r--r-- 1 root root 4096 Feb 8 10:42 name
|
||||||
-r--r--r-- 1 root root 4096 Feb 8 10:42 power
|
-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)
|
* 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)
|
* latency : Latency to exit out of this idle state (in microseconds)
|
||||||
* name : Name of the idle state (string)
|
* name : Name of the idle state (string)
|
||||||
* power : Power consumed while in this idle state (in milliwatts)
|
* 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
|
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
|
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
|
The largest size supported is 16GB: If the device is larger,
|
||||||
amounts of change, you may need find you need to increase this.
|
a warning will be issued and the excess space will not be used.
|
||||||
|
|
||||||
Reloading a pool table
|
Reloading a pool table
|
||||||
----------------------
|
----------------------
|
||||||
|
|
@ -167,6 +169,38 @@ ii) Using an internal snapshot.
|
||||||
|
|
||||||
dmsetup create snap --table "0 2097152 thin /dev/mapper/pool 1"
|
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
|
Deactivation
|
||||||
------------
|
------------
|
||||||
|
|
||||||
|
|
@ -189,7 +223,13 @@ i) Constructor
|
||||||
<low water mark (blocks)> [<number of feature args> [<arg>]*]
|
<low water mark (blocks)> [<number of feature args> [<arg>]*]
|
||||||
|
|
||||||
Optional feature arguments:
|
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
|
Data block size must be between 64KB (128 sectors) and 1GB
|
||||||
(2097152 sectors) inclusive.
|
(2097152 sectors) inclusive.
|
||||||
|
|
@ -237,16 +277,6 @@ iii) Messages
|
||||||
|
|
||||||
Deletes a thin device. Irreversible.
|
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>
|
set_transaction_id <current id> <new id>
|
||||||
|
|
||||||
Userland volume managers, such as LVM, need a way to
|
Userland volume managers, such as LVM, need a way to
|
||||||
|
|
@ -262,7 +292,7 @@ iii) Messages
|
||||||
|
|
||||||
i) Constructor
|
i) Constructor
|
||||||
|
|
||||||
thin <pool dev> <dev id>
|
thin <pool dev> <dev id> [<external origin dev>]
|
||||||
|
|
||||||
pool dev:
|
pool dev:
|
||||||
the thin-pool device, e.g. /dev/mapper/my_pool or 253:0
|
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
|
the internal device identifier of the device to be
|
||||||
activated.
|
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
|
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,
|
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
|
then you'll have no access to blocks mapped beyond the end. If you
|
||||||
|
|
|
||||||
194
Documentation/device-mapper/verity.txt
Normal file
194
Documentation/device-mapper/verity.txt
Normal file
|
|
@ -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
|
||||||
38
Documentation/devicetree/bindings/arm/atmel-aic.txt
Normal file
38
Documentation/devicetree/bindings/arm/atmel-aic.txt
Normal file
|
|
@ -0,0 +1,38 @@
|
||||||
|
* Advanced Interrupt Controller (AIC)
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible: Should be "atmel,<chip>-aic"
|
||||||
|
- interrupt-controller: Identifies the node as an interrupt controller.
|
||||||
|
- interrupt-parent: For single AIC system, it is an empty property.
|
||||||
|
- #interrupt-cells: The number of cells to define the interrupts. It sould be 2.
|
||||||
|
The first cell is the IRQ number (aka "Peripheral IDentifier" on datasheet).
|
||||||
|
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.
|
||||||
|
Valid combinations are 1, 2, 3, 4, 8.
|
||||||
|
Default flag for internal sources should be set to 4 (active high).
|
||||||
|
- reg: Should contain AIC registers location and length
|
||||||
|
|
||||||
|
Examples:
|
||||||
|
/*
|
||||||
|
* AIC
|
||||||
|
*/
|
||||||
|
aic: interrupt-controller@fffff000 {
|
||||||
|
compatible = "atmel,at91rm9200-aic";
|
||||||
|
interrupt-controller;
|
||||||
|
interrupt-parent;
|
||||||
|
#interrupt-cells = <2>;
|
||||||
|
reg = <0xfffff000 0x200>;
|
||||||
|
};
|
||||||
|
|
||||||
|
/*
|
||||||
|
* An interrupt generating device that is wired to an AIC.
|
||||||
|
*/
|
||||||
|
dma: dma-controller@ffffec00 {
|
||||||
|
compatible = "atmel,at91sam9g45-dma";
|
||||||
|
reg = <0xffffec00 0x200>;
|
||||||
|
interrupts = <21 4>;
|
||||||
|
};
|
||||||
92
Documentation/devicetree/bindings/arm/atmel-at91.txt
Normal file
92
Documentation/devicetree/bindings/arm/atmel-at91.txt
Normal file
|
|
@ -0,0 +1,92 @@
|
||||||
|
Atmel AT91 device tree bindings.
|
||||||
|
================================
|
||||||
|
|
||||||
|
PIT Timer required properties:
|
||||||
|
- compatible: Should be "atmel,at91sam9260-pit"
|
||||||
|
- reg: Should contain registers location and length
|
||||||
|
- interrupts: Should contain interrupt for the PIT which is the IRQ line
|
||||||
|
shared across all System Controller members.
|
||||||
|
|
||||||
|
TC/TCLIB Timer required properties:
|
||||||
|
- compatible: Should be "atmel,<chip>-pit".
|
||||||
|
<chip> can be "at91rm9200" or "at91sam9x5"
|
||||||
|
- reg: Should contain registers location and length
|
||||||
|
- interrupts: Should contain all interrupts for the TC block
|
||||||
|
Note that you can specify several interrupt cells if the TC
|
||||||
|
block has one interrupt per channel.
|
||||||
|
|
||||||
|
Examples:
|
||||||
|
|
||||||
|
One interrupt per TC block:
|
||||||
|
tcb0: timer@fff7c000 {
|
||||||
|
compatible = "atmel,at91rm9200-tcb";
|
||||||
|
reg = <0xfff7c000 0x100>;
|
||||||
|
interrupts = <18 4>;
|
||||||
|
};
|
||||||
|
|
||||||
|
One interrupt per TC channel in a TC block:
|
||||||
|
tcb1: timer@fffdc000 {
|
||||||
|
compatible = "atmel,at91rm9200-tcb";
|
||||||
|
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>;
|
||||||
|
};
|
||||||
11
Documentation/devicetree/bindings/arm/atmel-pmc.txt
Normal file
11
Documentation/devicetree/bindings/arm/atmel-pmc.txt
Normal file
|
|
@ -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>;
|
||||||
|
};
|
||||||
|
|
@ -28,3 +28,25 @@ Required root node properties:
|
||||||
i.MX6 Quad SABRE Lite Board
|
i.MX6 Quad SABRE Lite Board
|
||||||
Required root node properties:
|
Required root node properties:
|
||||||
- compatible = "fsl,imx6q-sabrelite", "fsl,imx6q";
|
- compatible = "fsl,imx6q-sabrelite", "fsl,imx6q";
|
||||||
|
|
||||||
|
Generic i.MX boards
|
||||||
|
-------------------
|
||||||
|
|
||||||
|
No iomux setup is done for these boards, so this must have been configured
|
||||||
|
by the bootloader for boards to work with the generic bindings.
|
||||||
|
|
||||||
|
i.MX27 generic board
|
||||||
|
Required root node properties:
|
||||||
|
- compatible = "fsl,imx27";
|
||||||
|
|
||||||
|
i.MX51 generic board
|
||||||
|
Required root node properties:
|
||||||
|
- compatible = "fsl,imx51";
|
||||||
|
|
||||||
|
i.MX53 generic board
|
||||||
|
Required root node properties:
|
||||||
|
- compatible = "fsl,imx53";
|
||||||
|
|
||||||
|
i.MX6q generic board
|
||||||
|
Required root node properties:
|
||||||
|
- compatible = "fsl,imx6q";
|
||||||
|
|
|
||||||
6
Documentation/devicetree/bindings/arm/mrvl.txt
Normal file
6
Documentation/devicetree/bindings/arm/mrvl.txt
Normal file
|
|
@ -0,0 +1,6 @@
|
||||||
|
Marvell Platforms Device Tree Bindings
|
||||||
|
----------------------------------------------------
|
||||||
|
|
||||||
|
PXA168 Aspenite Board
|
||||||
|
Required root node properties:
|
||||||
|
- compatible = "mrvl,pxa168-aspenite", "mrvl,pxa168";
|
||||||
27
Documentation/devicetree/bindings/arm/omap/intc.txt
Normal file
27
Documentation/devicetree/bindings/arm/omap/intc.txt
Normal file
|
|
@ -0,0 +1,27 @@
|
||||||
|
* OMAP Interrupt Controller
|
||||||
|
|
||||||
|
OMAP2/3 are using a TI interrupt controller that can support several
|
||||||
|
configurable number of interrupts.
|
||||||
|
|
||||||
|
Main node required properties:
|
||||||
|
|
||||||
|
- compatible : should be:
|
||||||
|
"ti,omap2-intc"
|
||||||
|
- interrupt-controller : Identifies the node as an interrupt controller
|
||||||
|
- #interrupt-cells : Specifies the number of cells needed to encode an
|
||||||
|
interrupt source. The type shall be a <u32> and the value shall be 1.
|
||||||
|
|
||||||
|
The cell contains the interrupt number in the range [0-128].
|
||||||
|
- ti,intc-size: Number of interrupts handled by the interrupt controller.
|
||||||
|
- reg: physical base address and size of the intc registers map.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
intc: interrupt-controller@1 {
|
||||||
|
compatible = "ti,omap2-intc";
|
||||||
|
interrupt-controller;
|
||||||
|
#interrupt-cells = <1>;
|
||||||
|
ti,intc-size = <96>;
|
||||||
|
reg = <0x48200000 0x1000>;
|
||||||
|
};
|
||||||
|
|
||||||
8
Documentation/devicetree/bindings/arm/spear.txt
Normal file
8
Documentation/devicetree/bindings/arm/spear.txt
Normal file
|
|
@ -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";
|
||||||
100
Documentation/devicetree/bindings/arm/tegra/emc.txt
Normal file
100
Documentation/devicetree/bindings/arm/tegra/emc.txt
Normal file
|
|
@ -0,0 +1,100 @@
|
||||||
|
Embedded Memory Controller
|
||||||
|
|
||||||
|
Properties:
|
||||||
|
- name : Should be emc
|
||||||
|
- #address-cells : Should be 1
|
||||||
|
- #size-cells : Should be 0
|
||||||
|
- compatible : Should contain "nvidia,tegra20-emc".
|
||||||
|
- reg : Offset and length of the register set for the device
|
||||||
|
- nvidia,use-ram-code : If present, the sub-nodes will be addressed
|
||||||
|
and chosen using the ramcode board selector. If omitted, only one
|
||||||
|
set of tables can be present and said tables will be used
|
||||||
|
irrespective of ram-code configuration.
|
||||||
|
|
||||||
|
Child device nodes describe the memory settings for different configurations and clock rates.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
emc@7000f400 {
|
||||||
|
#address-cells = < 1 >;
|
||||||
|
#size-cells = < 0 >;
|
||||||
|
compatible = "nvidia,tegra20-emc";
|
||||||
|
reg = <0x7000f4000 0x200>;
|
||||||
|
}
|
||||||
|
|
||||||
|
|
||||||
|
Embedded Memory Controller ram-code table
|
||||||
|
|
||||||
|
If the emc node has the nvidia,use-ram-code property present, then the
|
||||||
|
next level of nodes below the emc table are used to specify which settings
|
||||||
|
apply for which ram-code settings.
|
||||||
|
|
||||||
|
If the emc node lacks the nvidia,use-ram-code property, this level is omitted
|
||||||
|
and the tables are stored directly under the emc node (see below).
|
||||||
|
|
||||||
|
Properties:
|
||||||
|
|
||||||
|
- name : Should be emc-tables
|
||||||
|
- nvidia,ram-code : the binary representation of the ram-code board strappings
|
||||||
|
for which this node (and children) are valid.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Embedded Memory Controller configuration table
|
||||||
|
|
||||||
|
This is a table containing the EMC register settings for the various
|
||||||
|
operating speeds of the memory controller. They are always located as
|
||||||
|
subnodes of the emc controller node.
|
||||||
|
|
||||||
|
There are two ways of specifying which tables to use:
|
||||||
|
|
||||||
|
* The simplest is if there is just one set of tables in the device tree,
|
||||||
|
and they will always be used (based on which frequency is used).
|
||||||
|
This is the preferred method, especially when firmware can fill in
|
||||||
|
this information based on the specific system information and just
|
||||||
|
pass it on to the kernel.
|
||||||
|
|
||||||
|
* The slightly more complex one is when more than one memory configuration
|
||||||
|
might exist on the system. The Tegra20 platform handles this during
|
||||||
|
early boot by selecting one out of possible 4 memory settings based
|
||||||
|
on a 2-pin "ram code" bootstrap setting on the board. The values of
|
||||||
|
these strappings can be read through a register in the SoC, and thus
|
||||||
|
used to select which tables to use.
|
||||||
|
|
||||||
|
Properties:
|
||||||
|
- name : Should be emc-table
|
||||||
|
- compatible : Should contain "nvidia,tegra20-emc-table".
|
||||||
|
- reg : either an opaque enumerator to tell different tables apart, or
|
||||||
|
the valid frequency for which the table should be used (in kHz).
|
||||||
|
- clock-frequency : the clock frequency for the EMC at which this
|
||||||
|
table should be used (in kHz).
|
||||||
|
- nvidia,emc-registers : a 46 word array of EMC registers to be programmed
|
||||||
|
for operation at the 'clock-frequency' setting.
|
||||||
|
The order and contents of the registers are:
|
||||||
|
RC, RFC, RAS, RP, R2W, W2R, R2P, W2P, RD_RCD, WR_RCD, RRD, REXT,
|
||||||
|
WDV, QUSE, QRST, QSAFE, RDV, REFRESH, BURST_REFRESH_NUM, PDEX2WR,
|
||||||
|
PDEX2RD, PCHG2PDEN, ACT2PDEN, AR2PDEN, RW2PDEN, TXSR, TCKE, TFAW,
|
||||||
|
TRPAB, TCLKSTABLE, TCLKSTOP, TREFBW, QUSE_EXTRA, FBIO_CFG6, ODT_WRITE,
|
||||||
|
ODT_READ, FBIO_CFG5, CFG_DIG_DLL, DLL_XFORM_DQS, DLL_XFORM_QUSE,
|
||||||
|
ZCAL_REF_CNT, ZCAL_WAIT_CNT, AUTO_CAL_INTERVAL, CFG_CLKTRIM_0,
|
||||||
|
CFG_CLKTRIM_1, CFG_CLKTRIM_2
|
||||||
|
|
||||||
|
emc-table@166000 {
|
||||||
|
reg = <166000>;
|
||||||
|
compatible = "nvidia,tegra20-emc-table";
|
||||||
|
clock-frequency = < 166000 >;
|
||||||
|
nvidia,emc-registers = < 0 0 0 0 0 0 0 0 0 0 0 0 0 0
|
||||||
|
0 0 0 0 0 0 0 0 0 0 0 0 0 0
|
||||||
|
0 0 0 0 0 0 0 0 0 0 0 0 0 0
|
||||||
|
0 0 0 0 >;
|
||||||
|
};
|
||||||
|
|
||||||
|
emc-table@333000 {
|
||||||
|
reg = <333000>;
|
||||||
|
compatible = "nvidia,tegra20-emc-table";
|
||||||
|
clock-frequency = < 333000 >;
|
||||||
|
nvidia,emc-registers = < 0 0 0 0 0 0 0 0 0 0 0 0 0 0
|
||||||
|
0 0 0 0 0 0 0 0 0 0 0 0 0 0
|
||||||
|
0 0 0 0 0 0 0 0 0 0 0 0 0 0
|
||||||
|
0 0 0 0 >;
|
||||||
|
};
|
||||||
|
|
@ -0,0 +1,19 @@
|
||||||
|
NVIDIA Tegra Power Management Controller (PMC)
|
||||||
|
|
||||||
|
Properties:
|
||||||
|
- name : Should be pmc
|
||||||
|
- compatible : Should contain "nvidia,tegra<chip>-pmc".
|
||||||
|
- reg : Offset and length of the register set for the device
|
||||||
|
- nvidia,invert-interrupt : If present, inverts the PMU interrupt signal.
|
||||||
|
The PMU is an external Power Management Unit, whose interrupt output
|
||||||
|
signal is fed into the PMC. This signal is optionally inverted, and then
|
||||||
|
fed into the ARM GIC. The PMC is not involved in the detection or
|
||||||
|
handling of this interrupt signal, merely its inversion.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
pmc@7000f400 {
|
||||||
|
compatible = "nvidia,tegra20-pmc";
|
||||||
|
reg = <0x7000e400 0x400>;
|
||||||
|
nvidia,invert-interrupt;
|
||||||
|
};
|
||||||
48
Documentation/devicetree/bindings/arm/twd.txt
Normal file
48
Documentation/devicetree/bindings/arm/twd.txt
Normal file
|
|
@ -0,0 +1,48 @@
|
||||||
|
* ARM Timer Watchdog
|
||||||
|
|
||||||
|
ARM 11MP, Cortex-A5 and Cortex-A9 are often associated with a per-core
|
||||||
|
Timer-Watchdog (aka TWD), which provides both a per-cpu local timer
|
||||||
|
and watchdog.
|
||||||
|
|
||||||
|
The TWD is usually attached to a GIC to deliver its two per-processor
|
||||||
|
interrupts.
|
||||||
|
|
||||||
|
** Timer node required properties:
|
||||||
|
|
||||||
|
- compatible : Should be one of:
|
||||||
|
"arm,cortex-a9-twd-timer"
|
||||||
|
"arm,cortex-a5-twd-timer"
|
||||||
|
"arm,arm11mp-twd-timer"
|
||||||
|
|
||||||
|
- interrupts : One interrupt to each core
|
||||||
|
|
||||||
|
- reg : Specify the base address and the size of the TWD timer
|
||||||
|
register window.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
twd-timer@2c000600 {
|
||||||
|
compatible = "arm,arm11mp-twd-timer"";
|
||||||
|
reg = <0x2c000600 0x20>;
|
||||||
|
interrupts = <1 13 0xf01>;
|
||||||
|
};
|
||||||
|
|
||||||
|
** Watchdog node properties:
|
||||||
|
|
||||||
|
- compatible : Should be one of:
|
||||||
|
"arm,cortex-a9-twd-wdt"
|
||||||
|
"arm,cortex-a5-twd-wdt"
|
||||||
|
"arm,arm11mp-twd-wdt"
|
||||||
|
|
||||||
|
- interrupts : One interrupt to each core
|
||||||
|
|
||||||
|
- reg : Specify the base address and the size of the TWD watchdog
|
||||||
|
register window.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
twd-watchdog@2c000620 {
|
||||||
|
compatible = "arm,arm11mp-twd-wdt";
|
||||||
|
reg = <0x2c000620 0x20>;
|
||||||
|
interrupts = <1 14 0xf01>;
|
||||||
|
};
|
||||||
146
Documentation/devicetree/bindings/arm/vexpress.txt
Normal file
146
Documentation/devicetree/bindings/arm/vexpress.txt
Normal file
|
|
@ -0,0 +1,146 @@
|
||||||
|
ARM Versatile Express boards family
|
||||||
|
-----------------------------------
|
||||||
|
|
||||||
|
ARM's Versatile Express platform consists of a motherboard and one
|
||||||
|
or more daughterboards (tiles). The motherboard provides a set of
|
||||||
|
peripherals. Processor and RAM "live" on the tiles.
|
||||||
|
|
||||||
|
The motherboard and each core tile should be described by a separate
|
||||||
|
Device Tree source file, with the tile's description including
|
||||||
|
the motherboard file using a /include/ directive. As the motherboard
|
||||||
|
can be initialized in one of two different configurations ("memory
|
||||||
|
maps"), care must be taken to include the correct one.
|
||||||
|
|
||||||
|
Required properties in the root node:
|
||||||
|
- compatible value:
|
||||||
|
compatible = "arm,vexpress,<model>", "arm,vexpress";
|
||||||
|
where <model> is the full tile model name (as used in the tile's
|
||||||
|
Technical Reference Manual), eg.:
|
||||||
|
- for Coretile Express A5x2 (V2P-CA5s):
|
||||||
|
compatible = "arm,vexpress,v2p-ca5s", "arm,vexpress";
|
||||||
|
- for Coretile Express A9x4 (V2P-CA9):
|
||||||
|
compatible = "arm,vexpress,v2p-ca9", "arm,vexpress";
|
||||||
|
If a tile comes in several variants or can be used in more then one
|
||||||
|
configuration, the compatible value should be:
|
||||||
|
compatible = "arm,vexpress,<model>,<variant>", \
|
||||||
|
"arm,vexpress,<model>", "arm,vexpress";
|
||||||
|
eg:
|
||||||
|
- Coretile Express A15x2 (V2P-CA15) with Tech Chip 1:
|
||||||
|
compatible = "arm,vexpress,v2p-ca15,tc1", \
|
||||||
|
"arm,vexpress,v2p-ca15", "arm,vexpress";
|
||||||
|
- LogicTile Express 13MG (V2F-2XV6) running Cortex-A7 (3 cores) SMM:
|
||||||
|
compatible = "arm,vexpress,v2f-2xv6,ca7x3", \
|
||||||
|
"arm,vexpress,v2f-2xv6", "arm,vexpress";
|
||||||
|
|
||||||
|
Optional properties in the root node:
|
||||||
|
- tile model name (use name from the tile's Technical Reference
|
||||||
|
Manual, eg. "V2P-CA5s")
|
||||||
|
model = "<model>";
|
||||||
|
- tile's HBI number (unique ARM's board model ID, visible on the
|
||||||
|
PCB's silkscreen) in hexadecimal transcription:
|
||||||
|
arm,hbi = <0xhbi>
|
||||||
|
eg:
|
||||||
|
- for Coretile Express A5x2 (V2P-CA5s) HBI-0191:
|
||||||
|
arm,hbi = <0x191>;
|
||||||
|
- Coretile Express A9x4 (V2P-CA9) HBI-0225:
|
||||||
|
arm,hbi = <0x225>;
|
||||||
|
|
||||||
|
Top-level standard "cpus" node is required. It must contain a node
|
||||||
|
with device_type = "cpu" property for every available core, eg.:
|
||||||
|
|
||||||
|
cpus {
|
||||||
|
#address-cells = <1>;
|
||||||
|
#size-cells = <0>;
|
||||||
|
|
||||||
|
cpu@0 {
|
||||||
|
device_type = "cpu";
|
||||||
|
compatible = "arm,cortex-a5";
|
||||||
|
reg = <0>;
|
||||||
|
};
|
||||||
|
};
|
||||||
|
|
||||||
|
The motherboard description file provides a single "motherboard" node
|
||||||
|
using 2 address cells corresponding to the Static Memory Bus used
|
||||||
|
between the motherboard and the tile. The first cell defines the Chip
|
||||||
|
Select (CS) line number, the second cell address offset within the CS.
|
||||||
|
All interrupt lines between the motherboard and the tile are active
|
||||||
|
high and are described using single cell.
|
||||||
|
|
||||||
|
Optional properties of the "motherboard" node:
|
||||||
|
- motherboard's memory map variant:
|
||||||
|
arm,v2m-memory-map = "<name>";
|
||||||
|
where name is one of:
|
||||||
|
- "rs1" - for RS1 map (i.a. peripherals on CS3); this map is also
|
||||||
|
referred to as "ARM Cortex-A Series memory map":
|
||||||
|
arm,v2m-memory-map = "rs1";
|
||||||
|
When this property is missing, the motherboard is using the original
|
||||||
|
memory map (also known as the "Legacy memory map", primarily used
|
||||||
|
with the original CoreTile Express A9x4) with peripherals on CS7.
|
||||||
|
|
||||||
|
Motherboard .dtsi files provide a set of labelled peripherals that
|
||||||
|
can be used to obtain required phandle in the tile's "aliases" node:
|
||||||
|
- UARTs, note that the numbers correspond to the physical connectors
|
||||||
|
on the motherboard's back panel:
|
||||||
|
v2m_serial0, v2m_serial1, v2m_serial2 and v2m_serial3
|
||||||
|
- I2C controllers:
|
||||||
|
v2m_i2c_dvi and v2m_i2c_pcie
|
||||||
|
- SP804 timers:
|
||||||
|
v2m_timer01 and v2m_timer23
|
||||||
|
|
||||||
|
Current Linux implementation requires a "arm,v2m_timer" alias
|
||||||
|
pointing at one of the motherboard's SP804 timers, if it is to be
|
||||||
|
used as the system timer. This alias should be defined in the
|
||||||
|
motherboard files.
|
||||||
|
|
||||||
|
The tile description must define "ranges", "interrupt-map-mask" and
|
||||||
|
"interrupt-map" properties to translate the motherboard's address
|
||||||
|
and interrupt space into one used by the tile's processor.
|
||||||
|
|
||||||
|
Abbreviated example:
|
||||||
|
|
||||||
|
/dts-v1/;
|
||||||
|
|
||||||
|
/ {
|
||||||
|
model = "V2P-CA5s";
|
||||||
|
arm,hbi = <0x225>;
|
||||||
|
compatible = "arm,vexpress-v2p-ca5s", "arm,vexpress";
|
||||||
|
interrupt-parent = <&gic>;
|
||||||
|
#address-cells = <1>;
|
||||||
|
#size-cells = <1>;
|
||||||
|
|
||||||
|
chosen { };
|
||||||
|
|
||||||
|
aliases {
|
||||||
|
serial0 = &v2m_serial0;
|
||||||
|
};
|
||||||
|
|
||||||
|
cpus {
|
||||||
|
#address-cells = <1>;
|
||||||
|
#size-cells = <0>;
|
||||||
|
|
||||||
|
cpu@0 {
|
||||||
|
device_type = "cpu";
|
||||||
|
compatible = "arm,cortex-a5";
|
||||||
|
reg = <0>;
|
||||||
|
};
|
||||||
|
};
|
||||||
|
|
||||||
|
gic: interrupt-controller@2c001000 {
|
||||||
|
compatible = "arm,cortex-a9-gic";
|
||||||
|
#interrupt-cells = <3>;
|
||||||
|
#address-cells = <0>;
|
||||||
|
interrupt-controller;
|
||||||
|
reg = <0x2c001000 0x1000>,
|
||||||
|
<0x2c000100 0x100>;
|
||||||
|
};
|
||||||
|
|
||||||
|
motherboard {
|
||||||
|
/* CS0 is visible at 0x08000000 */
|
||||||
|
ranges = <0 0 0x08000000 0x04000000>;
|
||||||
|
interrupt-map-mask = <0 0 63>;
|
||||||
|
/* Active high IRQ 0 is connected to GIC's SPI0 */
|
||||||
|
interrupt-map = <0 0 0 &gic 0 0 4>;
|
||||||
|
};
|
||||||
|
};
|
||||||
|
|
||||||
|
/include/ "vexpress-v2m-rs1.dtsi"
|
||||||
30
Documentation/devicetree/bindings/dma/tegra20-apbdma.txt
Normal file
30
Documentation/devicetree/bindings/dma/tegra20-apbdma.txt
Normal file
|
|
@ -0,0 +1,30 @@
|
||||||
|
* NVIDIA Tegra APB DMA controller
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible: Should be "nvidia,<chip>-apbdma"
|
||||||
|
- reg: Should contain DMA registers location and length. This shuld include
|
||||||
|
all of the per-channel registers.
|
||||||
|
- interrupts: Should contain all of the per-channel DMA interrupts.
|
||||||
|
|
||||||
|
Examples:
|
||||||
|
|
||||||
|
apbdma: dma@6000a000 {
|
||||||
|
compatible = "nvidia,tegra20-apbdma";
|
||||||
|
reg = <0x6000a000 0x1200>;
|
||||||
|
interrupts = < 0 136 0x04
|
||||||
|
0 137 0x04
|
||||||
|
0 138 0x04
|
||||||
|
0 139 0x04
|
||||||
|
0 140 0x04
|
||||||
|
0 141 0x04
|
||||||
|
0 142 0x04
|
||||||
|
0 143 0x04
|
||||||
|
0 144 0x04
|
||||||
|
0 145 0x04
|
||||||
|
0 146 0x04
|
||||||
|
0 147 0x04
|
||||||
|
0 148 0x04
|
||||||
|
0 149 0x04
|
||||||
|
0 150 0x04
|
||||||
|
0 151 0x04 >;
|
||||||
|
};
|
||||||
36
Documentation/devicetree/bindings/gpio/gpio-omap.txt
Normal file
36
Documentation/devicetree/bindings/gpio/gpio-omap.txt
Normal file
|
|
@ -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;
|
||||||
|
};
|
||||||
23
Documentation/devicetree/bindings/gpio/gpio-twl4030.txt
Normal file
23
Documentation/devicetree/bindings/gpio/gpio-twl4030.txt
Normal file
|
|
@ -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;
|
||||||
|
};
|
||||||
20
Documentation/devicetree/bindings/gpio/gpio_atmel.txt
Normal file
20
Documentation/devicetree/bindings/gpio/gpio_atmel.txt
Normal file
|
|
@ -0,0 +1,20 @@
|
||||||
|
* Atmel GPIO controller (PIO)
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible: "atmel,<chip>-gpio", where <chip> is at91rm9200 or at91sam9x5.
|
||||||
|
- reg: Should contain GPIO controller registers location and length
|
||||||
|
- interrupts: Should be the port interrupt shared by all the pins.
|
||||||
|
- #gpio-cells: Should be two. The first cell is the pin number and
|
||||||
|
the second cell is used to specify optional parameters (currently
|
||||||
|
unused).
|
||||||
|
- gpio-controller: Marks the device node as a GPIO controller.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
pioA: gpio@fffff200 {
|
||||||
|
compatible = "atmel,at91rm9200-gpio";
|
||||||
|
reg = <0xfffff200 0x100>;
|
||||||
|
interrupts = <2 4>;
|
||||||
|
#gpio-cells = <2>;
|
||||||
|
gpio-controller;
|
||||||
|
};
|
||||||
|
|
||||||
32
Documentation/devicetree/bindings/gpio/gpio_i2c.txt
Normal file
32
Documentation/devicetree/bindings/gpio/gpio_i2c.txt
Normal file
|
|
@ -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>;
|
||||||
|
};
|
||||||
|
};
|
||||||
|
|
@ -1,8 +1,40 @@
|
||||||
NVIDIA Tegra 2 GPIO controller
|
NVIDIA Tegra GPIO controller
|
||||||
|
|
||||||
Required properties:
|
Required properties:
|
||||||
- compatible : "nvidia,tegra20-gpio"
|
- compatible : "nvidia,tegra<chip>-gpio"
|
||||||
|
- reg : Physical base address and length of the controller's registers.
|
||||||
|
- interrupts : The interrupt outputs from the controller. For Tegra20,
|
||||||
|
there should be 7 interrupts specified, and for Tegra30, there should
|
||||||
|
be 8 interrupts specified.
|
||||||
- #gpio-cells : Should be two. The first cell is the pin number and the
|
- #gpio-cells : Should be two. The first cell is the pin number and the
|
||||||
second cell is used to specify optional parameters:
|
second cell is used to specify optional parameters:
|
||||||
- bit 0 specifies polarity (0 for normal, 1 for inverted)
|
- bit 0 specifies polarity (0 for normal, 1 for inverted)
|
||||||
- gpio-controller : Marks the device node as a GPIO controller.
|
- gpio-controller : Marks the device node as a GPIO controller.
|
||||||
|
- #interrupt-cells : Should be 2.
|
||||||
|
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.
|
||||||
|
Valid combinations are 1, 2, 3, 4, 8.
|
||||||
|
- interrupt-controller : Marks the device node as an interrupt controller.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
gpio: gpio@6000d000 {
|
||||||
|
compatible = "nvidia,tegra20-gpio";
|
||||||
|
reg = < 0x6000d000 0x1000 >;
|
||||||
|
interrupts = < 0 32 0x04
|
||||||
|
0 33 0x04
|
||||||
|
0 34 0x04
|
||||||
|
0 35 0x04
|
||||||
|
0 55 0x04
|
||||||
|
0 87 0x04
|
||||||
|
0 89 0x04 >;
|
||||||
|
#gpio-cells = <2>;
|
||||||
|
gpio-controller;
|
||||||
|
#interrupt-cells = <2>;
|
||||||
|
interrupt-controller;
|
||||||
|
};
|
||||||
|
|
|
||||||
23
Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
Normal file
23
Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
Normal file
|
|
@ -0,0 +1,23 @@
|
||||||
|
* Marvell PXA GPIO controller
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible : Should be "mrvl,pxa-gpio" or "mrvl,mmp-gpio"
|
||||||
|
- reg : Address and length of the register set for the device
|
||||||
|
- interrupts : Should be the port interrupt shared by all gpio pins, if
|
||||||
|
- interrupt-name : Should be the name of irq resource.
|
||||||
|
one number.
|
||||||
|
- gpio-controller : Marks the device node as a gpio controller.
|
||||||
|
- #gpio-cells : Should be one. It is the pin number.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
gpio: gpio@d4019000 {
|
||||||
|
compatible = "mrvl,mmp-gpio", "mrvl,pxa-gpio";
|
||||||
|
reg = <0xd4019000 0x1000>;
|
||||||
|
interrupts = <49>, <17>, <18>;
|
||||||
|
interrupt-name = "gpio_mux", "gpio0", "gpio1";
|
||||||
|
gpio-controller;
|
||||||
|
#gpio-cells = <1>;
|
||||||
|
interrupt-controller;
|
||||||
|
#interrupt-cells = <1>;
|
||||||
|
};
|
||||||
48
Documentation/devicetree/bindings/gpio/sodaville.txt
Normal file
48
Documentation/devicetree/bindings/gpio/sodaville.txt
Normal file
|
|
@ -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>;
|
||||||
|
};
|
||||||
37
Documentation/devicetree/bindings/i2c/mrvl-i2c.txt
Normal file
37
Documentation/devicetree/bindings/i2c/mrvl-i2c.txt
Normal file
|
|
@ -0,0 +1,37 @@
|
||||||
|
* I2C
|
||||||
|
|
||||||
|
Required properties :
|
||||||
|
|
||||||
|
- reg : Offset and length of the register set for the device
|
||||||
|
- compatible : should be "mrvl,mmp-twsi" where CHIP is the name of a
|
||||||
|
compatible processor, e.g. pxa168, pxa910, mmp2, mmp3.
|
||||||
|
For the pxa2xx/pxa3xx, an additional node "mrvl,pxa-i2c" is required
|
||||||
|
as shown in the example below.
|
||||||
|
|
||||||
|
Recommended properties :
|
||||||
|
|
||||||
|
- interrupts : <a b> where a is the interrupt number and b is a
|
||||||
|
field that represents an encoding of the sense and level
|
||||||
|
information for the interrupt. This should be encoded based on
|
||||||
|
the information in section 2) depending on the type of interrupt
|
||||||
|
controller you have.
|
||||||
|
- interrupt-parent : the phandle for the interrupt controller that
|
||||||
|
services interrupts for this device.
|
||||||
|
- mrvl,i2c-polling : Disable interrupt of i2c controller. Polling
|
||||||
|
status register of i2c controller instead.
|
||||||
|
- mrvl,i2c-fast-mode : Enable fast mode of i2c controller.
|
||||||
|
|
||||||
|
Examples:
|
||||||
|
twsi1: i2c@d4011000 {
|
||||||
|
compatible = "mrvl,mmp-twsi", "mrvl,pxa-i2c";
|
||||||
|
reg = <0xd4011000 0x1000>;
|
||||||
|
interrupts = <7>;
|
||||||
|
mrvl,i2c-fast-mode;
|
||||||
|
};
|
||||||
|
|
||||||
|
twsi2: i2c@d4025000 {
|
||||||
|
compatible = "mrvl,mmp-twsi", "mrvl,pxa-i2c";
|
||||||
|
reg = <0xd4025000 0x1000>;
|
||||||
|
interrupts = <58>;
|
||||||
|
};
|
||||||
|
|
||||||
19
Documentation/devicetree/bindings/i2c/sirf-i2c.txt
Normal file
19
Documentation/devicetree/bindings/i2c/sirf-i2c.txt
Normal file
|
|
@ -0,0 +1,19 @@
|
||||||
|
I2C for SiRFprimaII platforms
|
||||||
|
|
||||||
|
Required properties :
|
||||||
|
- compatible : Must be "sirf,prima2-i2c"
|
||||||
|
- reg: physical base address of the controller and length of memory mapped
|
||||||
|
region.
|
||||||
|
- interrupts: interrupt number to the cpu.
|
||||||
|
|
||||||
|
Optional properties:
|
||||||
|
- clock-frequency : Constains desired I2C/HS-I2C bus clock frequency in Hz.
|
||||||
|
The absence of the propoerty indicates the default frequency 100 kHz.
|
||||||
|
|
||||||
|
Examples :
|
||||||
|
|
||||||
|
i2c0: i2c@b00e0000 {
|
||||||
|
compatible = "sirf,prima2-i2c";
|
||||||
|
reg = <0xb00e0000 0x10000>;
|
||||||
|
interrupts = <24>;
|
||||||
|
};
|
||||||
33
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
Normal file
33
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
Normal file
|
|
@ -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";
|
- compatible : must be "arm,versatile-flash";
|
||||||
- bank-width : width in bytes of flash interface.
|
- bank-width : width in bytes of flash interface.
|
||||||
|
|
||||||
Optional properties:
|
The device tree may optionally contain sub-nodes describing partitions of the
|
||||||
- Subnode partition map from mtd flash binding
|
address space. See partition.txt for more detail.
|
||||||
|
|
|
||||||
|
|
@ -3,6 +3,9 @@
|
||||||
Required properties:
|
Required properties:
|
||||||
- compatible : "atmel,<model>", "atmel,<series>", "atmel,dataflash".
|
- 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:
|
Example:
|
||||||
|
|
||||||
flash@1 {
|
flash@1 {
|
||||||
|
|
|
||||||
41
Documentation/devicetree/bindings/mtd/atmel-nand.txt
Normal file
41
Documentation/devicetree/bindings/mtd/atmel-nand.txt
Normal file
|
|
@ -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
|
read registers (tR). Required if property "gpios" is not used
|
||||||
(R/B# pins not connected).
|
(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:
|
Examples:
|
||||||
|
|
||||||
upm@1,0 {
|
upm@1,0 {
|
||||||
|
|
|
||||||
33
Documentation/devicetree/bindings/mtd/fsmc-nand.txt
Normal file
33
Documentation/devicetree/bindings/mtd/fsmc-nand.txt
Normal file
|
|
@ -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
|
GPIO state and before and after command byte writes, this register will be
|
||||||
read to ensure that the GPIO accesses have completed.
|
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:
|
Examples:
|
||||||
|
|
||||||
gpio-nand@1,0 {
|
gpio-nand@1,0 {
|
||||||
|
|
|
||||||
|
|
@ -23,27 +23,8 @@ are defined:
|
||||||
- vendor-id : Contains the flash chip's vendor id (1 byte).
|
- vendor-id : Contains the flash chip's vendor id (1 byte).
|
||||||
- device-id : Contains the flash chip's device 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
|
The device tree may optionally contain sub-nodes describing partitions of the
|
||||||
device tree may optionally contain additional information
|
address space. See partition.txt for more detail.
|
||||||
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.
|
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
|
|
|
||||||
7
Documentation/devicetree/bindings/mtd/nand.txt
Normal file
7
Documentation/devicetree/bindings/mtd/nand.txt
Normal file
|
|
@ -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
|
||||||
38
Documentation/devicetree/bindings/mtd/partition.txt
Normal file
38
Documentation/devicetree/bindings/mtd/partition.txt
Normal file
|
|
@ -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>;
|
||||||
|
};
|
||||||
|
];
|
||||||
31
Documentation/devicetree/bindings/mtd/spear_smi.txt
Normal file
31
Documentation/devicetree/bindings/mtd/spear_smi.txt
Normal file
|
|
@ -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>;
|
||||||
|
};
|
||||||
17
Documentation/devicetree/bindings/rtc/sa1100-rtc.txt
Normal file
17
Documentation/devicetree/bindings/rtc/sa1100-rtc.txt
Normal file
|
|
@ -0,0 +1,17 @@
|
||||||
|
* Marvell Real Time Clock controller
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible: should be "mrvl,sa1100-rtc"
|
||||||
|
- reg: physical base address of the controller and length of memory mapped
|
||||||
|
region.
|
||||||
|
- interrupts: Should be two. The first interrupt number is the rtc alarm
|
||||||
|
interrupt and the second interrupt number is the rtc hz interrupt.
|
||||||
|
- interrupt-names: Assign name of irq resource.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
rtc: rtc@d4010000 {
|
||||||
|
compatible = "mrvl,mmp-rtc";
|
||||||
|
reg = <0xd4010000 0x1000>;
|
||||||
|
interrupts = <5>, <6>;
|
||||||
|
interrupt-name = "rtc 1Hz", "rtc alarm";
|
||||||
|
};
|
||||||
4
Documentation/devicetree/bindings/serial/mrvl-serial.txt
Normal file
4
Documentation/devicetree/bindings/serial/mrvl-serial.txt
Normal file
|
|
@ -0,0 +1,4 @@
|
||||||
|
PXA UART controller
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible : should be "mrvl,mmp-uart" or "mrvl,pxa-uart".
|
||||||
49
Documentation/devicetree/bindings/usb/atmel-usb.txt
Normal file
49
Documentation/devicetree/bindings/usb/atmel-usb.txt
Normal file
|
|
@ -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".
|
- phy_type : Should be one of "ulpi" or "utmi".
|
||||||
- nvidia,vbus-gpio : If present, specifies a gpio that needs to be
|
- nvidia,vbus-gpio : If present, specifies a gpio that needs to be
|
||||||
activated for the bus to be powered.
|
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.
|
||||||
|
|
|
||||||
412
Documentation/devicetree/usage-model.txt
Normal file
412
Documentation/devicetree/usage-model.txt
Normal file
|
|
@ -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]
|
*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:
|
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
|
- *may* be exported to user space using "mmap" *ONLY* by exporter, outside of
|
||||||
this framework.
|
this framework.
|
||||||
- may be used *ONLY* by importers that do not need CPU access to the buffer.
|
- 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:
|
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
|
If the exporter chooses not to allow an attach() operation once a
|
||||||
map_dma_buf() API has been called, it simply returns an error.
|
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
|
- Any exporters or users of the dma-buf buffer sharing framework must have
|
||||||
a 'select DMA_SHARED_BUFFER' in their respective Kconfigs.
|
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:
|
References:
|
||||||
[1] struct dma_buf_ops in include/linux/dma-buf.h
|
[1] struct dma_buf_ops in include/linux/dma-buf.h
|
||||||
[2] All interfaces mentioned above defined 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_*_clut224.c
|
||||||
logo_*_mono.c
|
logo_*_mono.c
|
||||||
lxdialog
|
lxdialog
|
||||||
mach
|
|
||||||
mach-types
|
mach-types
|
||||||
mach-types.h
|
mach-types.h
|
||||||
machtypes.h
|
machtypes.h
|
||||||
|
|
|
||||||
|
|
@ -334,8 +334,8 @@ Sdram memory scrubbing rate:
|
||||||
|
|
||||||
Reading the file will return the actual scrubbing rate employed.
|
Reading the file will return the actual scrubbing rate employed.
|
||||||
|
|
||||||
If configuration fails or memory scrubbing is not implemented, the value
|
If configuration fails or memory scrubbing is not implemented, accessing
|
||||||
of the attribute file will be -1.
|
that attribute will fail.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -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 \
|
modprobe i810fb vram=2 xres=1024 bpp=8 hsync1=30 hsync2=55 vsync1=50 \
|
||||||
vsync2=85 accel=1 mtrr=1
|
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 \
|
options i810fb vram=2 xres=1024 bpp=16 hsync1=30 hsync2=55 vsync1=50 \
|
||||||
vsync2=85 accel=1 mtrr=1
|
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
|
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
|
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
|
What: CONFIG_APM_CPU_IDLE, and its ability to call APM BIOS in idle
|
||||||
When: 2012
|
When: 2012
|
||||||
Why: This optional sub-feature of APM is of dubious reliability,
|
Why: This optional sub-feature of APM is of dubious reliability,
|
||||||
|
|
@ -513,20 +505,6 @@ Who: Bjorn Helgaas <bhelgaas@google.com>
|
||||||
|
|
||||||
----------------------------
|
----------------------------
|
||||||
|
|
||||||
What: The CAP9 SoC family will be removed
|
|
||||||
When: 3.4
|
|
||||||
Files: arch/arm/mach-at91/at91cap9.c
|
|
||||||
arch/arm/mach-at91/at91cap9_devices.c
|
|
||||||
arch/arm/mach-at91/include/mach/at91cap9.h
|
|
||||||
arch/arm/mach-at91/include/mach/at91cap9_matrix.h
|
|
||||||
arch/arm/mach-at91/include/mach/at91cap9_ddrsdr.h
|
|
||||||
arch/arm/mach-at91/board-cap9adk.c
|
|
||||||
Why: The code is not actively maintained and platforms are now hard to find.
|
|
||||||
Who: Nicolas Ferre <nicolas.ferre@atmel.com>
|
|
||||||
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
|
|
||||||
|
|
||||||
----------------------------
|
|
||||||
|
|
||||||
What: Low Performance USB Block driver ("CONFIG_BLK_DEV_UB")
|
What: Low Performance USB Block driver ("CONFIG_BLK_DEV_UB")
|
||||||
When: 3.6
|
When: 3.6
|
||||||
Why: This driver provides support for USB storage devices like "USB
|
Why: This driver provides support for USB storage devices like "USB
|
||||||
|
|
@ -543,3 +521,21 @@ When: 3.5
|
||||||
Why: The old kmap_atomic() with two arguments is deprecated, we only
|
Why: The old kmap_atomic() with two arguments is deprecated, we only
|
||||||
keep it for backward compatibility for few cycles and then drop it.
|
keep it for backward compatibility for few cycles and then drop it.
|
||||||
Who: Cong Wang <amwang@redhat.com>
|
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>
|
||||||
|
|
||||||
|
----------------------------
|
||||||
|
|
||||||
|
What: setitimer accepts user NULL pointer (value)
|
||||||
|
When: 3.6
|
||||||
|
Why: setitimer is not returning -EFAULT if user pointer is NULL. This
|
||||||
|
violates the spec.
|
||||||
|
Who: Sasikantha Babu <sasikanth.v19@gmail.com>
|
||||||
|
|
|
||||||
|
|
@ -144,9 +144,6 @@ journal_async_commit Commit block can be written to disk without waiting
|
||||||
mount the device. This will enable 'journal_checksum'
|
mount the device. This will enable 'journal_checksum'
|
||||||
internally.
|
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
|
journal_dev=devnum When the external journal device's major/minor numbers
|
||||||
have changed, this option allows the user to specify
|
have changed, this option allows the user to specify
|
||||||
the new journal location. The journal device is
|
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
|
interoperability with older kernels which only
|
||||||
store and expect 16-bit values.
|
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
|
block_validity This options allows to enables/disables the in-kernel
|
||||||
noblock_validity facility for tracking filesystem metadata blocks
|
noblock_validity facility for tracking filesystem metadata blocks
|
||||||
within internal data structures. This allows multi-
|
within internal data structures. This allows multi-
|
||||||
|
|
|
||||||
|
|
@ -113,8 +113,8 @@ the fdtable structure -
|
||||||
if (fd >= 0) {
|
if (fd >= 0) {
|
||||||
/* locate_fd() may have expanded fdtable, load the ptr */
|
/* locate_fd() may have expanded fdtable, load the ptr */
|
||||||
fdt = files_fdtable(files);
|
fdt = files_fdtable(files);
|
||||||
FD_SET(fd, fdt->open_fds);
|
__set_open_fd(fd, fdt);
|
||||||
FD_CLR(fd, fdt->close_on_exec);
|
__clear_close_on_exec(fd, fdt);
|
||||||
spin_unlock(&files->file_lock);
|
spin_unlock(&files->file_lock);
|
||||||
.....
|
.....
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -114,7 +114,7 @@ members are defined:
|
||||||
struct file_system_type {
|
struct file_system_type {
|
||||||
const char *name;
|
const char *name;
|
||||||
int fs_flags;
|
int fs_flags;
|
||||||
struct dentry (*mount) (struct file_system_type *, int,
|
struct dentry *(*mount) (struct file_system_type *, int,
|
||||||
const char *, void *);
|
const char *, void *);
|
||||||
void (*kill_sb) (struct super_block *);
|
void (*kill_sb) (struct super_block *);
|
||||||
struct module *owner;
|
struct module *owner;
|
||||||
|
|
|
||||||
|
|
@ -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
|
power management, such as by powering down unused chip sectors and, more
|
||||||
easily, gating off unused clocks.
|
easily, gating off unused clocks.
|
||||||
|
|
||||||
Note that requesting a GPIO does NOT cause it to be configured in any
|
For GPIOs that use pins known to the pinctrl subsystem, that subsystem should
|
||||||
way; it just marks that GPIO as in use. Separate code must handle any
|
be informed of their use; a gpiolib driver's .request() operation may call
|
||||||
pin setup (e.g. controlling which pin the GPIO uses, pullup/pulldown).
|
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
|
Also note that it's your responsibility to have stopped using a GPIO
|
||||||
before you free it.
|
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_LOW - as output, set initial level to LOW
|
||||||
* GPIOF_INIT_HIGH - as output, set initial level to HIGH
|
* 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
|
since GPIOF_INIT_* are only valid when configured as output, so group valid
|
||||||
combinations as:
|
combinations as:
|
||||||
|
|
@ -310,8 +329,19 @@ combinations as:
|
||||||
* GPIOF_OUT_INIT_LOW - configured as output, initial level LOW
|
* GPIOF_OUT_INIT_LOW - configured as output, initial level LOW
|
||||||
* GPIOF_OUT_INIT_HIGH - configured as output, initial level HIGH
|
* GPIOF_OUT_INIT_HIGH - configured as output, initial level HIGH
|
||||||
|
|
||||||
In the future, these flags can be extended to support more properties such
|
When setting the flag as GPIOF_OPEN_DRAIN then it will assume that pins is
|
||||||
as open-drain status.
|
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
|
Further more, to ease the claim/release of multiple GPIOs, 'struct gpio' is
|
||||||
introduced to encapsulate all three fields as:
|
introduced to encapsulate all three fields as:
|
||||||
|
|
|
||||||
|
|
@ -11,7 +11,7 @@ Supported chips:
|
||||||
Socket S1G2: Athlon (X2), Sempron (X2), Turion X2 (Ultra)
|
Socket S1G2: Athlon (X2), Sempron (X2), Turion X2 (Ultra)
|
||||||
* AMD Family 12h processors: "Llano" (E2/A4/A6/A8-Series)
|
* AMD Family 12h processors: "Llano" (E2/A4/A6/A8-Series)
|
||||||
* AMD Family 14h processors: "Brazos" (C/E/G/Z-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'
|
Prefix: 'k10temp'
|
||||||
Addresses scanned: PCI space
|
Addresses scanned: PCI space
|
||||||
|
|
|
||||||
|
|
@ -118,6 +118,10 @@ Supported chips:
|
||||||
Addresses scanned: I2C 0x48 through 0x4F
|
Addresses scanned: I2C 0x48 through 0x4F
|
||||||
Datasheet: Publicly available at NXP website
|
Datasheet: Publicly available at NXP website
|
||||||
http://ics.nxp.com/products/interface/datasheet/sa56004x.pdf
|
http://ics.nxp.com/products/interface/datasheet/sa56004x.pdf
|
||||||
|
* GMT G781
|
||||||
|
Prefix: 'g781'
|
||||||
|
Addresses scanned: I2C 0x4c, 0x4d
|
||||||
|
Datasheet: Not publicly available from GMT
|
||||||
|
|
||||||
Author: Jean Delvare <khali@linux-fr.org>
|
Author: Jean Delvare <khali@linux-fr.org>
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -3,8 +3,11 @@ Kernel driver mc13783-adc
|
||||||
|
|
||||||
Supported chips:
|
Supported chips:
|
||||||
* Freescale Atlas MC13783
|
* Freescale Atlas MC13783
|
||||||
Prefix: 'mc13783_adc'
|
Prefix: 'mc13783'
|
||||||
Datasheet: http://www.freescale.com/files/rf_if/doc/data_sheet/MC13783.pdf?fsrch=1
|
Datasheet: http://www.freescale.com/files/rf_if/doc/data_sheet/MC13783.pdf?fsrch=1
|
||||||
|
* Freescale Atlas MC13892
|
||||||
|
Prefix: 'mc13892'
|
||||||
|
Datasheet: http://cache.freescale.com/files/analog/doc/data_sheet/MC13892.pdf?fsrch=1&sr=1
|
||||||
|
|
||||||
Authors:
|
Authors:
|
||||||
Sascha Hauer <s.hauer@pengutronix.de>
|
Sascha Hauer <s.hauer@pengutronix.de>
|
||||||
|
|
@ -13,20 +16,21 @@ Authors:
|
||||||
Description
|
Description
|
||||||
-----------
|
-----------
|
||||||
|
|
||||||
The Freescale MC13783 is a Power Management and Audio Circuit. Among
|
The Freescale MC13783 and MC13892 are Power Management and Audio Circuits.
|
||||||
other things it contains a 10-bit A/D converter. The converter has 16
|
Among other things they contain a 10-bit A/D converter. The converter has 16
|
||||||
channels which can be used in different modes.
|
(MC13783) resp. 12 (MC13892) channels which can be used in different modes. The
|
||||||
The A/D converter has a resolution of 2.25mV. Channels 0-4 have
|
A/D converter has a resolution of 2.25mV.
|
||||||
a dedicated meaning with chip internal scaling applied. Channels 5-7
|
|
||||||
can be used as general purpose inputs or alternatively in a dedicated
|
|
||||||
mode. Channels 12-15 are occupied by the touchscreen if it's active.
|
|
||||||
|
|
||||||
Currently the driver only supports channels 2 and 5-15 with no alternative
|
Some channels can be used as General Purpose inputs or in a dedicated mode with
|
||||||
modes for channels 5-7.
|
a chip internal scaling applied .
|
||||||
|
|
||||||
See this table for the meaning of the different channels and their chip
|
Currently the driver only supports the Application Supply channel (BP / BPSNS),
|
||||||
internal scaling:
|
the General Purpose inputs and touchscreen.
|
||||||
|
|
||||||
|
See the following tables for the meaning of the different channels and their
|
||||||
|
chip internal scaling:
|
||||||
|
|
||||||
|
MC13783:
|
||||||
Channel Signal Input Range Scaling
|
Channel Signal Input Range Scaling
|
||||||
-------------------------------------------------------------------------------
|
-------------------------------------------------------------------------------
|
||||||
0 Battery Voltage (BATT) 2.50 - 4.65V -2.40V
|
0 Battery Voltage (BATT) 2.50 - 4.65V -2.40V
|
||||||
|
|
@ -34,7 +38,7 @@ Channel Signal Input Range Scaling
|
||||||
2 Application Supply (BP) 2.50 - 4.65V -2.40V
|
2 Application Supply (BP) 2.50 - 4.65V -2.40V
|
||||||
3 Charger Voltage (CHRGRAW) 0 - 10V / /5
|
3 Charger Voltage (CHRGRAW) 0 - 10V / /5
|
||||||
0 - 20V /10
|
0 - 20V /10
|
||||||
4 Charger Current (CHRGISNSP-CHRGISNSN) -0.25V - 0.25V x4
|
4 Charger Current (CHRGISNSP-CHRGISNSN) -0.25 - 0.25V x4
|
||||||
5 General Purpose ADIN5 / Battery Pack Thermistor 0 - 2.30V No
|
5 General Purpose ADIN5 / Battery Pack Thermistor 0 - 2.30V No
|
||||||
6 General Purpose ADIN6 / Backup Voltage (LICELL) 0 - 2.30V / No /
|
6 General Purpose ADIN6 / Backup Voltage (LICELL) 0 - 2.30V / No /
|
||||||
1.50 - 3.50V -1.20V
|
1.50 - 3.50V -1.20V
|
||||||
|
|
@ -48,3 +52,23 @@ Channel Signal Input Range Scaling
|
||||||
13 General Purpose TSX2 / Touchscreen X-plate 2 0 - 2.30V No
|
13 General Purpose TSX2 / Touchscreen X-plate 2 0 - 2.30V No
|
||||||
14 General Purpose TSY1 / Touchscreen Y-plate 1 0 - 2.30V No
|
14 General Purpose TSY1 / Touchscreen Y-plate 1 0 - 2.30V No
|
||||||
15 General Purpose TSY2 / Touchscreen Y-plate 2 0 - 2.30V No
|
15 General Purpose TSY2 / Touchscreen Y-plate 2 0 - 2.30V No
|
||||||
|
|
||||||
|
MC13892:
|
||||||
|
Channel Signal Input Range Scaling
|
||||||
|
-------------------------------------------------------------------------------
|
||||||
|
0 Battery Voltage (BATT) 0 - 4.8V /2
|
||||||
|
1 Battery Current (BATT - BATTISNSCC) -60 - 60 mV x20
|
||||||
|
2 Application Supply (BPSNS) 0 - 4.8V /2
|
||||||
|
3 Charger Voltage (CHRGRAW) 0 - 12V / /5
|
||||||
|
0 - 20V /10
|
||||||
|
4 Charger Current (CHRGISNS-BPSNS) / -0.3 - 0.3V / x4 /
|
||||||
|
Touchscreen X-plate 1 0 - 2.4V No
|
||||||
|
5 General Purpose ADIN5 / Battery Pack Thermistor 0 - 2.4V No
|
||||||
|
6 General Purpose ADIN6 / Backup Voltage (LICELL) 0 - 2.4V / No
|
||||||
|
Backup Voltage (LICELL) 0 - 3.6V x2/3
|
||||||
|
7 General Purpose ADIN7 / UID / Die Temperature 0 - 2.4V / No /
|
||||||
|
0 - 4.8V /2
|
||||||
|
12 General Purpose TSX1 / Touchscreen X-plate 1 0 - 2.4V No
|
||||||
|
13 General Purpose TSX2 / Touchscreen X-plate 2 0 - 2.4V No
|
||||||
|
14 General Purpose TSY1 / Touchscreen Y-plate 1 0 - 2.4V No
|
||||||
|
15 General Purpose TSY2 / Touchscreen Y-plate 2 0 - 2.4V No
|
||||||
|
|
|
||||||
22
Documentation/hwmon/mcp3021
Normal file
22
Documentation/hwmon/mcp3021
Normal file
|
|
@ -0,0 +1,22 @@
|
||||||
|
Kernel driver MCP3021
|
||||||
|
======================
|
||||||
|
|
||||||
|
Supported chips:
|
||||||
|
* Microchip Technology MCP3021
|
||||||
|
Prefix: 'mcp3021'
|
||||||
|
Datasheet: http://ww1.microchip.com/downloads/en/DeviceDoc/21805a.pdf
|
||||||
|
|
||||||
|
Author: Mingkai Hu
|
||||||
|
|
||||||
|
Description
|
||||||
|
-----------
|
||||||
|
|
||||||
|
This driver implements support for the Microchip Technology MCP3021 chip.
|
||||||
|
|
||||||
|
The Microchip Technology Inc. MCP3021 is a successive approximation A/D
|
||||||
|
converter (ADC) with 10-bit resolution.
|
||||||
|
This device provides one single-ended input with very low power consumption.
|
||||||
|
Communication to the MCP3021 is performed using a 2-wire I2C compatible
|
||||||
|
interface. Standard (100 kHz) and Fast (400 kHz) I2C modes are available.
|
||||||
|
The default I2C device address is 0x4d (contact the Microchip factory for
|
||||||
|
additional address options).
|
||||||
|
|
@ -20,6 +20,7 @@ Supported adapters:
|
||||||
* Intel Patsburg (PCH)
|
* Intel Patsburg (PCH)
|
||||||
* Intel DH89xxCC (PCH)
|
* Intel DH89xxCC (PCH)
|
||||||
* Intel Panther Point (PCH)
|
* Intel Panther Point (PCH)
|
||||||
|
* Intel Lynx Point (PCH)
|
||||||
Datasheets: Publicly available at the Intel website
|
Datasheets: Publicly available at the Intel website
|
||||||
|
|
||||||
On Intel Patsburg and later chipsets, both the normal host SMBus controller
|
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:
|
parameter to your boot command line:
|
||||||
scx200_acb.base=0x810,0x820
|
scx200_acb.base=0x810,0x820
|
||||||
If the scx200_acb driver is built as a module, add the following line to
|
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
|
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
|
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
|
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
|
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
|
a USB keyboard works and is correctly connected to the kernel keyboard
|
||||||
driver.
|
driver.
|
||||||
|
|
||||||
Doing a cat /dev/input/mouse0 (c, 13, 32) will verify that a mouse
|
Doing a "cat /dev/input/mouse0" (c, 13, 32) will verify that a mouse
|
||||||
is also emulated, characters should appear if you move it.
|
is also emulated; characters should appear if you move it.
|
||||||
|
|
||||||
You can test the joystick emulation with the 'jstest' utility,
|
You can test the joystick emulation with the 'jstest' utility,
|
||||||
available in the joystick package (see Documentation/input/joystick.txt).
|
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
|
'j' 00-3F linux/joystick.h
|
||||||
'k' 00-0F linux/spi/spidev.h conflict!
|
'k' 00-0F linux/spi/spidev.h conflict!
|
||||||
'k' 00-05 video/kyro.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
|
'l' 00-3F linux/tcfs_fs.h transparent cryptographic file system
|
||||||
<http://web.archive.org/web/*/http://mikonos.dia.unisa.it/tcfs>
|
<http://web.archive.org/web/*/http://mikonos.dia.unisa.it/tcfs>
|
||||||
'l' 40-7F linux/udf_fs_i.h in development:
|
'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
|
2.5.): 1=on (default), 0=off
|
||||||
|
|
||||||
Depending on your distribution you may want to create a separate module
|
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
|
configuration file like /etc/modprobe.d/gigaset.conf for these.
|
||||||
custom file like /etc/modprobe.conf.local.
|
|
||||||
|
|
||||||
2.2. Device nodes for user space programs
|
2.2. Device nodes for user space programs
|
||||||
------------------------------------
|
------------------------------------
|
||||||
|
|
@ -212,8 +211,8 @@ GigaSet 307x Device Driver
|
||||||
|
|
||||||
options ppp_async flag_time=0
|
options ppp_async flag_time=0
|
||||||
|
|
||||||
to an appropriate module configuration file, like /etc/modprobe.d/gigaset
|
to an appropriate module configuration file, like
|
||||||
or /etc/modprobe.conf.local.
|
/etc/modprobe.d/gigaset.conf.
|
||||||
|
|
||||||
Unimodem mode is needed for making some devices [e.g. SX100] work which
|
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
|
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
|
modprobe usb_gigaset startmode=0
|
||||||
or by adding a line like
|
or by adding a line like
|
||||||
options usb_gigaset startmode=0
|
options usb_gigaset startmode=0
|
||||||
to an appropriate module configuration file, like /etc/modprobe.d/gigaset
|
to an appropriate module configuration file, like
|
||||||
or /etc/modprobe.conf.local.
|
/etc/modprobe.d/gigaset.conf
|
||||||
|
|
||||||
2.6. Call-ID (CID) mode
|
2.6. Call-ID (CID) mode
|
||||||
------------------
|
------------------
|
||||||
|
|
@ -310,7 +309,7 @@ GigaSet 307x Device Driver
|
||||||
|
|
||||||
options isdn dialtimeout=15
|
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:
|
Problem:
|
||||||
The isdnlog program emits error messages or just doesn't work.
|
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
|
The initial value can be set using the debug parameter when loading the
|
||||||
module "gigaset", e.g. by adding a line
|
module "gigaset", e.g. by adding a line
|
||||||
options gigaset debug=0
|
options gigaset debug=0
|
||||||
to your module configuration file, eg. /etc/modprobe.d/gigaset or
|
to your module configuration file, eg. /etc/modprobe.d/gigaset.conf
|
||||||
/etc/modprobe.conf.local.
|
|
||||||
|
|
||||||
Generated debugging information can be found
|
Generated debugging information can be found
|
||||||
- as output of the command
|
- as output of the command
|
||||||
|
|
|
||||||
|
|
@ -28,12 +28,10 @@ new (default) values, so you can use:
|
||||||
|
|
||||||
grep "(NEW)" conf.new
|
grep "(NEW)" conf.new
|
||||||
|
|
||||||
to see the new config symbols or you can 'diff' the previous and
|
to see the new config symbols or you can use diffconfig to see the
|
||||||
new .config files to see the differences:
|
differences between the previous and new .config files:
|
||||||
|
|
||||||
diff .config.old .config | less
|
scripts/diffconfig .config.old .config | less
|
||||||
|
|
||||||
(Yes, we need something better here.)
|
|
||||||
|
|
||||||
______________________________________________________________________
|
______________________________________________________________________
|
||||||
Environment variables for '*config'
|
Environment variables for '*config'
|
||||||
|
|
|
||||||
|
|
@ -1086,8 +1086,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
||||||
no_x2apic_optout
|
no_x2apic_optout
|
||||||
BIOS x2APIC opt-out request will be ignored
|
BIOS x2APIC opt-out request will be ignored
|
||||||
|
|
||||||
inttest= [IA-64]
|
|
||||||
|
|
||||||
iomem= Disable strict checking of access to MMIO memory
|
iomem= Disable strict checking of access to MMIO memory
|
||||||
strict regions from userspace.
|
strict regions from userspace.
|
||||||
relaxed
|
relaxed
|
||||||
|
|
@ -1701,6 +1699,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
||||||
The default is to send the implementation identification
|
The default is to send the implementation identification
|
||||||
information.
|
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=
|
objlayoutdriver.osd_login_prog=
|
||||||
[NFS] [OBJLAYOUT] sets the pathname to the program which
|
[NFS] [OBJLAYOUT] sets the pathname to the program which
|
||||||
|
|
@ -1871,6 +1875,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
||||||
shutdown the other cpus. Instead use the REBOOT_VECTOR
|
shutdown the other cpus. Instead use the REBOOT_VECTOR
|
||||||
irq.
|
irq.
|
||||||
|
|
||||||
|
nomodule Disable module load
|
||||||
|
|
||||||
nopat [X86] Disable PAT (page attribute table extension of
|
nopat [X86] Disable PAT (page attribute table extension of
|
||||||
pagetables) support.
|
pagetables) support.
|
||||||
|
|
||||||
|
|
@ -2147,8 +2153,14 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
||||||
the default.
|
the default.
|
||||||
off: Turn ECRC off
|
off: Turn ECRC off
|
||||||
on: Turn ECRC on.
|
on: Turn ECRC on.
|
||||||
realloc reallocate PCI resources if allocations done by BIOS
|
realloc= Enable/disable reallocating PCI bridge resources
|
||||||
are erroneous.
|
if allocations done by BIOS are too small to
|
||||||
|
accommodate resources required by all child
|
||||||
|
devices.
|
||||||
|
off: Turn realloc off
|
||||||
|
on: Turn realloc on
|
||||||
|
realloc same as realloc=on
|
||||||
|
noari do not use PCIe ARI.
|
||||||
|
|
||||||
pcie_aspm= [PCIE] Forcibly enable or disable PCIe Active State Power
|
pcie_aspm= [PCIE] Forcibly enable or disable PCIe Active State Power
|
||||||
Management.
|
Management.
|
||||||
|
|
@ -2156,6 +2168,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
||||||
force Enable ASPM even on devices that claim not to support it.
|
force Enable ASPM even on devices that claim not to support it.
|
||||||
WARNING: Forcing ASPM on may cause system lockups.
|
WARNING: Forcing ASPM on may cause system lockups.
|
||||||
|
|
||||||
|
pcie_hp= [PCIE] PCI Express Hotplug driver options:
|
||||||
|
nomsi Do not use MSI for PCI Express Native Hotplug (this
|
||||||
|
makes all PCIe ports use INTx for hotplug services).
|
||||||
|
|
||||||
pcie_ports= [PCIE] PCIe ports handling:
|
pcie_ports= [PCIE] PCIe ports handling:
|
||||||
auto Ask the BIOS whether or not to use native PCIe services
|
auto Ask the BIOS whether or not to use native PCIe services
|
||||||
associated with PCIe ports (PME, hot-plug, AER). Use
|
associated with PCIe ports (PME, hot-plug, AER). Use
|
||||||
|
|
|
||||||
|
|
@ -45,7 +45,7 @@ Status
|
||||||
Usage
|
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 :
|
see some lines like this :
|
||||||
|
|
||||||
Asus Laptop Extras version 0.42
|
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
|
devices are created by the driver. Additionally, loading the driver with the
|
||||||
debug option will report all events in the kernel log.
|
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:
|
Backlight control:
|
||||||
------------------
|
------------------
|
||||||
If your laptop model supports it, you will find sysfs files in the
|
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
|
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
|
alias char-major-10-250 sonypi
|
||||||
options sonypi minor=250
|
options sonypi minor=250
|
||||||
|
|
|
||||||
|
|
@ -38,11 +38,11 @@ if [ ! -e /proc/sys/fs/binfmt_misc/register ]; then
|
||||||
/sbin/modprobe binfmt_misc
|
/sbin/modprobe binfmt_misc
|
||||||
# Some distributions, like Fedora Core, perform
|
# Some distributions, like Fedora Core, perform
|
||||||
# the following command automatically when the
|
# 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
|
# Thus, it is possible that the following line
|
||||||
# is not needed at all. Look at /etc/modprobe.conf
|
# is not needed at all.
|
||||||
# to check whether this is applicable or not.
|
mount -t binfmt_misc none /proc/sys/fs/binfmt_misc
|
||||||
mount -t binfmt_misc none /proc/sys/fs/binfmt_misc
|
|
||||||
fi
|
fi
|
||||||
|
|
||||||
# Register support for .NET CLR binaries
|
# 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
|
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
|
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
|
driver from the insmod command line (or by means of an option line in
|
||||||
/etc/modprobe.conf).
|
/etc/modprobe.d/*.conf).
|
||||||
|
|
||||||
Examples:
|
Examples:
|
||||||
modprobe baycom_ser_fdx mode="ser12*" iobase=0x3f8 irq=4
|
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
|
Module options may be given as command line arguments to the
|
||||||
insmod or modprobe command, but are usually specified in either the
|
insmod or modprobe command, but are usually specified in either the
|
||||||
/etc/modules.conf or /etc/modprobe.conf configuration file, or in a
|
/etc/modrobe.d/*.conf configuration files, or in a distro-specific
|
||||||
distro-specific configuration file (some of which are detailed in the next
|
configuration file (some of which are detailed in the next section).
|
||||||
section).
|
|
||||||
|
|
||||||
Details on bonding support for sysfs is provided in the
|
Details on bonding support for sysfs is provided in the
|
||||||
"Configuring Bonding Manually via Sysfs" section, below.
|
"Configuring Bonding Manually via Sysfs" section, below.
|
||||||
|
|
@ -1021,7 +1020,7 @@ ifcfg-bondX files.
|
||||||
|
|
||||||
Because the sysconfig scripts supply the bonding module
|
Because the sysconfig scripts supply the bonding module
|
||||||
options in the ifcfg-bondX file, it is not necessary to add them to
|
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
|
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
|
arp_ip_target=+192.168.1.1 arp_ip_target=+192.168.1.2
|
||||||
|
|
||||||
is the proper syntax to specify multiple targets. When specifying
|
is the proper syntax to specify multiple targets. When specifying
|
||||||
options via BONDING_OPTS, it is not necessary to edit /etc/modules.conf or
|
options via BONDING_OPTS, it is not necessary to edit /etc/modprobe.d/*.conf.
|
||||||
/etc/modprobe.conf.
|
|
||||||
|
|
||||||
For even older versions of initscripts that do not support
|
For even older versions of initscripts that do not support
|
||||||
BONDING_OPTS, it is necessary to edit /etc/modules.conf (or
|
BONDING_OPTS, it is necessary to edit /etc/modprobe.d/*.conf, depending upon
|
||||||
/etc/modprobe.conf, depending upon your distro) to load the bonding module
|
your distro) to load the bonding module with your desired options when the
|
||||||
with your desired options when the bond0 interface is brought up. The
|
bond0 interface is brought up. The following lines in /etc/modprobe.d/*.conf
|
||||||
following lines in /etc/modules.conf (or modprobe.conf) will load the
|
will load the bonding module, and select its options:
|
||||||
bonding module, and select its options:
|
|
||||||
|
|
||||||
alias bond0 bonding
|
alias bond0 bonding
|
||||||
options bond0 mode=balance-alb miimon=100
|
options bond0 mode=balance-alb miimon=100
|
||||||
|
|
@ -1152,7 +1149,7 @@ knowledge of bonding. One such distro is SuSE Linux Enterprise Server
|
||||||
version 8.
|
version 8.
|
||||||
|
|
||||||
The general method for these systems is to place the bonding
|
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
|
appropriate for the installed distro), then add modprobe and/or
|
||||||
ifenslave commands to the system's global init script. The name of
|
ifenslave commands to the system's global init script. The name of
|
||||||
the global init script differs; for sysconfig, it is
|
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
|
specify a different name for each instance (the module loading system
|
||||||
requires that every loaded module, even multiple instances of the same
|
requires that every loaded module, even multiple instances of the same
|
||||||
module, have a unique name). This is accomplished by supplying multiple
|
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
|
alias bond0 bonding
|
||||||
options bond0 -o bond0 mode=balance-rr miimon=100
|
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
|
On systems with network configuration scripts that do not
|
||||||
associate physical devices directly with network interface names (so
|
associate physical devices directly with network interface names (so
|
||||||
that the same physical device always has the same "ethX" name), it may
|
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
|
be necessary to add some special logic to config files in
|
||||||
/etc/modprobe.conf (depending upon which is installed on the system).
|
/etc/modprobe.d/.
|
||||||
|
|
||||||
For example, given a modules.conf containing the following:
|
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
|
bonding is loaded. This command is fully documented in the
|
||||||
modules.conf manual page.
|
modules.conf manual page.
|
||||||
|
|
||||||
On systems utilizing modprobe.conf (or modprobe.conf.local),
|
On systems utilizing modprobe an equivalent problem can occur.
|
||||||
an equivalent problem can occur. In this case, the following can be
|
In this case, the following can be added to config files in
|
||||||
added to modprobe.conf (or modprobe.conf.local, as appropriate), as
|
/etc/modprobe.d/ as:
|
||||||
follows (all on one line; it has been split here for clarity):
|
|
||||||
|
|
||||||
install bonding /sbin/modprobe tg3; /sbin/modprobe e1000;
|
softdep bonding pre: tg3 e1000
|
||||||
/sbin/modprobe --ignore-install bonding
|
|
||||||
|
|
||||||
This will, when loading the bonding module, rather than
|
This will load tg3 and e1000 modules before loading the bonding one.
|
||||||
performing the normal action, instead execute the provided command.
|
Full documentation on this can be found in the modprobe.d and modprobe
|
||||||
This command loads the device drivers in the order needed, then calls
|
manual pages.
|
||||||
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.
|
|
||||||
|
|
||||||
8.3. Painfully Slow Or No Failed Link Detection By Miimon
|
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.
|
"ifconfig". If tested ok, continue the next step.
|
||||||
|
|
||||||
4. cp dl2k.ko /lib/modules/`uname -r`/kernel/drivers/net
|
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
|
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.
|
located at /etc/sysconfig/network-scripts or create it manually.
|
||||||
[see - Configuration Script Sample]
|
[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
|
Compiling the Driver
|
||||||
====================
|
====================
|
||||||
|
|
@ -154,8 +155,8 @@ Installing the Driver
|
||||||
-----------------
|
-----------------
|
||||||
1. Copy dl2k.o to the network modules directory, typically
|
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.
|
/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
|
2. Locate the boot module configuration file, most commonly in the
|
||||||
or modules.conf (for 2.4) in the /etc directory. Add the following lines:
|
/etc/modprobe.d/ directory. Add the following lines:
|
||||||
|
|
||||||
alias ethx dl2k
|
alias ethx dl2k
|
||||||
options dl2k <optional parameters>
|
options dl2k <optional parameters>
|
||||||
|
|
|
||||||
|
|
@ -2,16 +2,16 @@ Document about softnet driver issues
|
||||||
|
|
||||||
Transmit path guidelines:
|
Transmit path guidelines:
|
||||||
|
|
||||||
1) The hard_start_xmit method must never return '1' under any
|
1) The ndo_start_xmit method must not return NETDEV_TX_BUSY under
|
||||||
normal circumstances. It is considered a hard error unless
|
any normal circumstances. It is considered a hard error unless
|
||||||
there is no way your device can tell ahead of time when it's
|
there is no way your device can tell ahead of time when it's
|
||||||
transmit function will become busy.
|
transmit function will become busy.
|
||||||
|
|
||||||
Instead it must maintain the queue properly. For example,
|
Instead it must maintain the queue properly. For example,
|
||||||
for a driver implementing scatter-gather this means:
|
for a driver implementing scatter-gather this means:
|
||||||
|
|
||||||
static int drv_hard_start_xmit(struct sk_buff *skb,
|
static netdev_tx_t drv_hard_start_xmit(struct sk_buff *skb,
|
||||||
struct net_device *dev)
|
struct net_device *dev)
|
||||||
{
|
{
|
||||||
struct drv *dp = netdev_priv(dev);
|
struct drv *dp = netdev_priv(dev);
|
||||||
|
|
||||||
|
|
@ -23,7 +23,7 @@ Transmit path guidelines:
|
||||||
unlock_tx(dp);
|
unlock_tx(dp);
|
||||||
printk(KERN_ERR PFX "%s: BUG! Tx Ring full when queue awake!\n",
|
printk(KERN_ERR PFX "%s: BUG! Tx Ring full when queue awake!\n",
|
||||||
dev->name);
|
dev->name);
|
||||||
return 1;
|
return NETDEV_TX_BUSY;
|
||||||
}
|
}
|
||||||
|
|
||||||
... queue packet to card ...
|
... queue packet to card ...
|
||||||
|
|
@ -35,6 +35,7 @@ Transmit path guidelines:
|
||||||
...
|
...
|
||||||
unlock_tx(dp);
|
unlock_tx(dp);
|
||||||
...
|
...
|
||||||
|
return NETDEV_TX_OK;
|
||||||
}
|
}
|
||||||
|
|
||||||
And then at the end of your TX reclamation event handling:
|
And then at the end of your TX reclamation event handling:
|
||||||
|
|
@ -58,15 +59,12 @@ Transmit path guidelines:
|
||||||
TX_BUFFS_AVAIL(dp) > 0)
|
TX_BUFFS_AVAIL(dp) > 0)
|
||||||
netif_wake_queue(dp->dev);
|
netif_wake_queue(dp->dev);
|
||||||
|
|
||||||
2) Do not forget to update netdev->trans_start to jiffies after
|
2) An ndo_start_xmit method must not modify the shared parts of a
|
||||||
each new tx packet is given to the hardware.
|
|
||||||
|
|
||||||
3) A hard_start_xmit method must not modify the shared parts of a
|
|
||||||
cloned SKB.
|
cloned SKB.
|
||||||
|
|
||||||
4) Do not forget that once you return 0 from your hard_start_xmit
|
3) Do not forget that once you return NETDEV_TX_OK from your
|
||||||
method, it is your driver's responsibility to free up the SKB
|
ndo_start_xmit method, it is your driver's responsibility to free
|
||||||
and in some finite amount of time.
|
up the SKB and in some finite amount of time.
|
||||||
|
|
||||||
For example, this means that it is not allowed for your TX
|
For example, this means that it is not allowed for your TX
|
||||||
mitigation scheme to let TX packets "hang out" in the 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
|
This error can deadlock sockets waiting for send buffer room
|
||||||
to be freed up.
|
to be freed up.
|
||||||
|
|
||||||
If you return 1 from the hard_start_xmit method, you must not keep
|
If you return NETDEV_TX_BUSY from the ndo_start_xmit method, you
|
||||||
any reference to that SKB and you must not attempt to free it up.
|
must not keep any reference to that SKB and you must not attempt
|
||||||
|
to free it up.
|
||||||
|
|
||||||
Probing guidelines:
|
Probing guidelines:
|
||||||
|
|
||||||
|
|
@ -85,10 +84,10 @@ Probing guidelines:
|
||||||
|
|
||||||
Close/stop 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
|
not receive or transmit any data. All in flight packets must
|
||||||
be aborted. If necessary, poll or wait for completion of
|
be aborted. If necessary, poll or wait for completion of
|
||||||
any reset commands.
|
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.
|
if device is still UP.
|
||||||
|
|
|
||||||
|
|
@ -94,8 +94,8 @@ Additional Configurations
|
||||||
|
|
||||||
Configuring a network driver to load properly when the system is started is
|
Configuring a network driver to load properly when the system is started is
|
||||||
distribution dependent. Typically, the configuration process involves adding
|
distribution dependent. Typically, the configuration process involves adding
|
||||||
an alias line to /etc/modules.conf or /etc/modprobe.conf as well as editing
|
an alias line to /etc/modprobe.d/*.conf as well as editing other system
|
||||||
other system startup scripts and/or configuration files. Many popular Linux
|
startup scripts and/or configuration files. Many popular Linux
|
||||||
distributions ship with tools to make these changes for you. To learn the
|
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
|
proper way to configure a network device for your system, refer to your
|
||||||
distribution documentation. If during this process you are asked for the
|
distribution documentation. If during this process you are asked for the
|
||||||
|
|
@ -103,7 +103,7 @@ Additional Configurations
|
||||||
PRO/100 Family of Adapters is e100.
|
PRO/100 Family of Adapters is e100.
|
||||||
|
|
||||||
As an example, if you install the e100 driver for two PRO/100 adapters
|
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 eth0 e100
|
||||||
alias eth1 e100
|
alias eth1 e100
|
||||||
|
|
|
||||||
|
|
@ -604,15 +604,8 @@ IP Variables:
|
||||||
ip_local_port_range - 2 INTEGERS
|
ip_local_port_range - 2 INTEGERS
|
||||||
Defines the local port range that is used by TCP and UDP to
|
Defines the local port range that is used by TCP and UDP to
|
||||||
choose the local port. The first number is the first, the
|
choose the local port. The first number is the first, the
|
||||||
second the last local port number. Default value depends on
|
second the last local port number. The default values are
|
||||||
amount of memory available on the system:
|
32768 and 61000 respectively.
|
||||||
> 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.
|
|
||||||
|
|
||||||
ip_local_reserved_ports - list of comma separated ranges
|
ip_local_reserved_ports - list of comma separated ranges
|
||||||
Specify the ports which are reserved for known third-party
|
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.
|
Options for the ipv6 module are supplied as parameters at load time.
|
||||||
|
|
||||||
Module options may be given as command line arguments to the insmod
|
Module options may be given as command line arguments to the insmod
|
||||||
or modprobe command, but are usually specified in either the
|
or modprobe command, but are usually specified in either
|
||||||
/etc/modules.conf or /etc/modprobe.conf configuration file, or in a
|
/etc/modules.d/*.conf configuration files, or in a distro-specific
|
||||||
distro-specific configuration file.
|
configuration file.
|
||||||
|
|
||||||
The available ipv6 module parameters are listed below. If a parameter
|
The available ipv6 module parameters are listed below. If a parameter
|
||||||
is not specified the default value is used.
|
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
|
Configuring a network driver to load properly when the system is started is
|
||||||
distribution dependent. Typically, the configuration process involves adding
|
distribution dependent. Typically, the configuration process involves adding
|
||||||
an alias line to /etc/modprobe.conf as well as editing other system startup
|
an alias line to files in /etc/modprobe.d/ as well as editing other system
|
||||||
scripts and/or configuration files. Many popular Linux distributions ship
|
startup scripts and/or configuration files. Many popular Linux distributions
|
||||||
with tools to make these changes for you. To learn the proper way to
|
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
|
configure a network device for your system, refer to your distribution
|
||||||
documentation. If during this process you are asked for the driver or module
|
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
|
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=",
|
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
|
"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
|
alias lt0 ltpc # autoload the module when the interface is configured
|
||||||
options ltpc io=0x240 irq=9 dma=1
|
options ltpc io=0x240 irq=9 dma=1
|
||||||
|
|
|
||||||
|
|
@ -47,26 +47,25 @@ packets is preferred.
|
||||||
|
|
||||||
struct net_device synchronization rules
|
struct net_device synchronization rules
|
||||||
=======================================
|
=======================================
|
||||||
dev->open:
|
ndo_open:
|
||||||
Synchronization: rtnl_lock() semaphore.
|
Synchronization: rtnl_lock() semaphore.
|
||||||
Context: process
|
Context: process
|
||||||
|
|
||||||
dev->stop:
|
ndo_stop:
|
||||||
Synchronization: rtnl_lock() semaphore.
|
Synchronization: rtnl_lock() semaphore.
|
||||||
Context: process
|
Context: process
|
||||||
Note1: netif_running() is guaranteed false
|
Note: netif_running() is guaranteed false
|
||||||
Note2: dev->poll() is guaranteed to be stopped
|
|
||||||
|
|
||||||
dev->do_ioctl:
|
ndo_do_ioctl:
|
||||||
Synchronization: rtnl_lock() semaphore.
|
Synchronization: rtnl_lock() semaphore.
|
||||||
Context: process
|
Context: process
|
||||||
|
|
||||||
dev->get_stats:
|
ndo_get_stats:
|
||||||
Synchronization: dev_base_lock rwlock.
|
Synchronization: dev_base_lock rwlock.
|
||||||
Context: nominally process, but don't sleep inside an rwlock
|
Context: nominally process, but don't sleep inside an rwlock
|
||||||
|
|
||||||
dev->hard_start_xmit:
|
ndo_start_xmit:
|
||||||
Synchronization: netif_tx_lock spinlock.
|
Synchronization: __netif_tx_lock spinlock.
|
||||||
|
|
||||||
When the driver sets NETIF_F_LLTX in dev->features this will be
|
When the driver sets NETIF_F_LLTX in dev->features this will be
|
||||||
called without holding netif_tx_lock. In this case the driver
|
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.
|
o NETDEV_TX_LOCKED Locking failed, please retry quickly.
|
||||||
Only valid when NETIF_F_LLTX is set.
|
Only valid when NETIF_F_LLTX is set.
|
||||||
|
|
||||||
dev->tx_timeout:
|
ndo_tx_timeout:
|
||||||
Synchronization: netif_tx_lock spinlock.
|
Synchronization: netif_tx_lock spinlock; all TX queues frozen.
|
||||||
Context: BHs disabled
|
Context: BHs disabled
|
||||||
Notes: netif_queue_stopped() is guaranteed true
|
Notes: netif_queue_stopped() is guaranteed true
|
||||||
|
|
||||||
dev->set_rx_mode:
|
ndo_set_rx_mode:
|
||||||
Synchronization: netif_tx_lock spinlock.
|
Synchronization: netif_addr_lock spinlock.
|
||||||
Context: BHs disabled
|
Context: BHs disabled
|
||||||
|
|
||||||
struct napi_struct synchronization rules
|
struct napi_struct synchronization rules
|
||||||
========================================
|
========================================
|
||||||
napi->poll:
|
napi->poll:
|
||||||
Synchronization: NAPI_STATE_SCHED bit in napi->state. Device
|
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
|
all NAPI instances which will do a sleeping poll on the
|
||||||
NAPI_STATE_SCHED napi->state bit, waiting for all pending
|
NAPI_STATE_SCHED napi->state bit, waiting for all pending
|
||||||
NAPI activity to cease.
|
NAPI activity to cease.
|
||||||
|
|
|
||||||
|
|
@ -67,8 +67,8 @@ Module parameters
|
||||||
=================
|
=================
|
||||||
|
|
||||||
There are several parameters which may be provided to the driver when
|
There are several parameters which may be provided to the driver when
|
||||||
its module is loaded. These are usually placed in /etc/modprobe.conf
|
its module is loaded. These are usually placed in /etc/modprobe.d/*.conf
|
||||||
(/etc/modules.conf in 2.4). Example:
|
configuretion files. Example:
|
||||||
|
|
||||||
options 3c59x debug=3 rx_copybreak=300
|
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:
|
1) Increase the debug level. Usually this is done via:
|
||||||
|
|
||||||
a) modprobe driver debug=7
|
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
|
options driver debug=7
|
||||||
|
|
||||||
2) Recreate the problem with the higher debug level,
|
2) Recreate the problem with the higher debug level,
|
||||||
|
|
|
||||||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Add table
Reference in a new issue