apfs/linux-apfs
0
0
Fork 0
mirror of https://github.com/linux-apfs/linux-apfs.git synced 2026-05-01 15:00:59 -07:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'linus' into cpus4096

Browse Source 
Conflicts:

	drivers/acpi/processor_throttling.c

Signed-off-by: Ingo Molnar <mingo@elte.hu>
This commit is contained in:
Ingo Molnar
2008-07-18 22:00:54 +02:00
parent 82638844d9 5b664cb235
commit bb2c018b09
1704 changed files with 104274 additions and 193466 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Documentation/ABI/testing/sysfs-firmware-acpi
+87 -40
View File
@@ -29,46 +29,46 @@ Description:
$ cd /sys/firmware/acpi/interrupts
$ grep . *
error:0
ff_gbl_lock:0
ff_pmtimer:0
ff_pwr_btn:0
ff_rt_clk:0
ff_slp_btn:0
gpe00:0
gpe01:0
gpe02:0
gpe03:0
gpe04:0
gpe05:0
gpe06:0
gpe07:0
gpe08:0
gpe09:174
gpe0A:0
gpe0B:0
gpe0C:0
gpe0D:0
gpe0E:0
gpe0F:0
gpe10:0
gpe11:60
gpe12:0
gpe13:0
gpe14:0
gpe15:0
gpe16:0
gpe17:0
gpe18:0
gpe19:7
gpe1A:0
gpe1B:0
gpe1C:0
gpe1D:0
gpe1E:0
gpe1F:0
gpe_all:241
sci:241
error: 0
ff_gbl_lock: 0 enable
ff_pmtimer: 0 invalid
ff_pwr_btn: 0 enable
ff_rt_clk: 2 disable
ff_slp_btn: 0 invalid
gpe00: 0 invalid
gpe01: 0 enable
gpe02: 108 enable
gpe03: 0 invalid
gpe04: 0 invalid
gpe05: 0 invalid
gpe06: 0 enable
gpe07: 0 enable
gpe08: 0 invalid
gpe09: 0 invalid
gpe0A: 0 invalid
gpe0B: 0 invalid
gpe0C: 0 invalid
gpe0D: 0 invalid
gpe0E: 0 invalid
gpe0F: 0 invalid
gpe10: 0 invalid
gpe11: 0 invalid
gpe12: 0 invalid
gpe13: 0 invalid
gpe14: 0 invalid
gpe15: 0 invalid
gpe16: 0 invalid
gpe17: 1084 enable
gpe18: 0 enable
gpe19: 0 invalid
gpe1A: 0 invalid
gpe1B: 0 invalid
gpe1C: 0 invalid
gpe1D: 0 invalid
gpe1E: 0 invalid
gpe1F: 0 invalid
gpe_all: 1192
sci: 1194
sci - The total number of times the ACPI SCI
has claimed an interrupt.
@@ -89,6 +89,13 @@ Description:
error - an interrupt that can't be accounted for above.
invalid: it's either a wakeup GPE or a GPE/Fixed Event that
doesn't have an event handler.
disable: the GPE/Fixed Event is valid but disabled.
enable: the GPE/Fixed Event is valid and enabled.
Root has permission to clear any of these counters. Eg.
# echo 0 > gpe11
@@ -97,3 +104,43 @@ Description:
None of these counters has an effect on the function
of the system, they are simply statistics.
Besides this, user can also write specific strings to these files
to enable/disable/clear ACPI interrupts in user space, which can be
used to debug some ACPI interrupt storm issues.
Note that only writting to VALID GPE/Fixed Event is allowed,
i.e. user can only change the status of runtime GPE and
Fixed Event with event handler installed.
Let's take power button fixed event for example, please kill acpid
and other user space applications so that the machine won't shutdown
when pressing the power button.
# cat ff_pwr_btn
0
# press the power button for 3 times;
# cat ff_pwr_btn
3
# echo disable > ff_pwr_btn
# cat ff_pwr_btn
disable
# press the power button for 3 times;
# cat ff_pwr_btn
disable
# echo enable > ff_pwr_btn
# cat ff_pwr_btn
4
/*
* this is because the status bit is set even if the enable bit is cleared,
* and it triggers an ACPI fixed event when the enable bit is set again
*/
# press the power button for 3 times;
# cat ff_pwr_btn
7
# echo disable > ff_pwr_btn
# press the power button for 3 times;
# echo clear > ff_pwr_btn /* clear the status bit */
# echo disable > ff_pwr_btn
# cat ff_pwr_btn
7
Documentation/filesystems/configfs/configfs.txt
+6 -4
View File
@@ -233,10 +233,12 @@ accomplished via the group operations specified on the group's
config_item_type.
struct configfs_group_operations {
struct config_item *(*make_item)(struct config_group *group,
const char *name);
struct config_group *(*make_group)(struct config_group *group,
const char *name);
int (*make_item)(struct config_group *group,
const char *name,
struct config_item **new_item);
int (*make_group)(struct config_group *group,
const char *name,
struct config_group **new_group);
int (*commit_item)(struct config_item *item);
void (*disconnect_notify)(struct config_group *group,
struct config_item *item);
Documentation/filesystems/configfs/configfs_example.c
+8 -6
View File
@@ -273,13 +273,13 @@ static inline struct simple_children *to_simple_children(struct config_item *ite
return item ? container_of(to_config_group(item), struct simple_children, group) : NULL;
}
static struct config_item *simple_children_make_item(struct config_group *group, const char *name)
static int simple_children_make_item(struct config_group *group, const char *name, struct config_item **new_item)
{
struct simple_child *simple_child;
simple_child = kzalloc(sizeof(struct simple_child), GFP_KERNEL);
if (!simple_child)
return NULL;
return -ENOMEM;
config_item_init_type_name(&simple_child->item, name,
@@ -287,7 +287,8 @@ static struct config_item *simple_children_make_item(struct config_group *group,
simple_child->storeme = 0;
return &simple_child->item;
*new_item = &simple_child->item;
return 0;
}
static struct configfs_attribute simple_children_attr_description = {
@@ -359,20 +360,21 @@ static struct configfs_subsystem simple_children_subsys = {
* children of its own.
*/
static struct config_group *group_children_make_group(struct config_group *group, const char *name)
static int group_children_make_group(struct config_group *group, const char *name, struct config_group **new_group)
{
struct simple_children *simple_children;
simple_children = kzalloc(sizeof(struct simple_children),
GFP_KERNEL);
if (!simple_children)
return NULL;
return -ENOMEM;
config_group_init_type_name(&simple_children->group, name,
&simple_children_type);
return &simple_children->group;
*new_group = &simple_children->group;
return 0;
}
static struct configfs_attribute group_children_attr_description = {
Documentation/filesystems/ubifs.txt
+164
View File
@@ -0,0 +1,164 @@
Introduction
=============
UBIFS file-system stands for UBI File System. UBI stands for "Unsorted
Block Images". UBIFS is a flash file system, which means it is designed
to work with flash devices. It is important to understand, that UBIFS
is completely different to any traditional file-system in Linux, like
Ext2, XFS, JFS, etc. UBIFS represents a separate class of file-systems
which work with MTD devices, not block devices. The other Linux
file-system of this class is JFFS2.
To make it more clear, here is a small comparison of MTD devices and
block devices.
1 MTD devices represent flash devices and they consist of eraseblocks of
rather large size, typically about 128KiB. Block devices consist of
small blocks, typically 512 bytes.
2 MTD devices support 3 main operations - read from some offset within an
eraseblock, write to some offset within an eraseblock, and erase a whole
eraseblock. Block devices support 2 main operations - read a whole
block and write a whole block.
3 The whole eraseblock has to be erased before it becomes possible to
re-write its contents. Blocks may be just re-written.
4 Eraseblocks become worn out after some number of erase cycles -
typically 100K-1G for SLC NAND and NOR flashes, and 1K-10K for MLC
NAND flashes. Blocks do not have the wear-out property.
5 Eraseblocks may become bad (only on NAND flashes) and software should
deal with this. Blocks on hard drives typically do not become bad,
because hardware has mechanisms to substitute bad blocks, at least in
modern LBA disks.
It should be quite obvious why UBIFS is very different to traditional
file-systems.
UBIFS works on top of UBI. UBI is a separate software layer which may be
found in drivers/mtd/ubi. UBI is basically a volume management and
wear-leveling layer. It provides so called UBI volumes which is a higher
level abstraction than a MTD device. The programming model of UBI devices
is very similar to MTD devices - they still consist of large eraseblocks,
they have read/write/erase operations, but UBI devices are devoid of
limitations like wear and bad blocks (items 4 and 5 in the above list).
In a sense, UBIFS is a next generation of JFFS2 file-system, but it is
very different and incompatible to JFFS2. The following are the main
differences.
* JFFS2 works on top of MTD devices, UBIFS depends on UBI and works on
top of UBI volumes.
* JFFS2 does not have on-media index and has to build it while mounting,
which requires full media scan. UBIFS maintains the FS indexing
information on the flash media and does not require full media scan,
so it mounts many times faster than JFFS2.
* JFFS2 is a write-through file-system, while UBIFS supports write-back,
which makes UBIFS much faster on writes.
Similarly to JFFS2, UBIFS supports on-the-flight compression which makes
it possible to fit quite a lot of data to the flash.
Similarly to JFFS2, UBIFS is tolerant of unclean reboots and power-cuts.
It does not need stuff like ckfs.ext2. UBIFS automatically replays its
journal and recovers from crashes, ensuring that the on-flash data
structures are consistent.
UBIFS scales logarithmically (most of the data structures it uses are
trees), so the mount time and memory consumption do not linearly depend
on the flash size, like in case of JFFS2. This is because UBIFS
maintains the FS index on the flash media. However, UBIFS depends on
UBI, which scales linearly. So overall UBI/UBIFS stack scales linearly.
Nevertheless, UBI/UBIFS scales considerably better than JFFS2.
The authors of UBIFS believe, that it is possible to develop UBI2 which
would scale logarithmically as well. UBI2 would support the same API as UBI,
but it would be binary incompatible to UBI. So UBIFS would not need to be
changed to use UBI2
Mount options
=============
(*) == default.
norm_unmount (*) commit on unmount; the journal is committed
when the file-system is unmounted so that the
next mount does not have to replay the journal
and it becomes very fast;
fast_unmount do not commit on unmount; this option makes
unmount faster, but the next mount slower
because of the need to replay the journal.
Quick usage instructions
========================
The UBI volume to mount is specified using "ubiX_Y" or "ubiX:NAME" syntax,
where "X" is UBI device number, "Y" is UBI volume number, and "NAME" is
UBI volume name.
Mount volume 0 on UBI device 0 to /mnt/ubifs:
$ mount -t ubifs ubi0_0 /mnt/ubifs
Mount "rootfs" volume of UBI device 0 to /mnt/ubifs ("rootfs" is volume
name):
$ mount -t ubifs ubi0:rootfs /mnt/ubifs
The following is an example of the kernel boot arguments to attach mtd0
to UBI and mount volume "rootfs":
ubi.mtd=0 root=ubi0:rootfs rootfstype=ubifs
Module Parameters for Debugging
===============================
When UBIFS has been compiled with debugging enabled, there are 3 module
parameters that are available to control aspects of testing and debugging.
The parameters are unsigned integers where each bit controls an option.
The parameters are:
debug_msgs Selects which debug messages to display, as follows:
Message Type Flag value
General messages 1
Journal messages 2
Mount messages 4
Commit messages 8
LEB search messages 16
Budgeting messages 32
Garbage collection messages 64
Tree Node Cache (TNC) messages 128
LEB properties (lprops) messages 256
Input/output messages 512
Log messages 1024
Scan messages 2048
Recovery messages 4096
debug_chks Selects extra checks that UBIFS can do while running:
Check Flag value
General checks 1
Check Tree Node Cache (TNC) 2
Check indexing tree size 4
Check orphan area 8
Check old indexing tree 16
Check LEB properties (lprops) 32
Check leaf nodes and inodes 64
debug_tsts Selects a mode of testing, as follows:
Test mode Flag value
Force in-the-gaps method 2
Failure mode for recovery testing 4
For example, set debug_msgs to 5 to display General messages and Mount
messages.
References
==========
UBIFS documentation and FAQ/HOWTO at the MTD web site:
http://www.linux-mtd.infradead.org/doc/ubifs.html
http://www.linux-mtd.infradead.org/faq/ubifs.html
Documentation/ftrace.txt
+151 -152
View File
File diff suppressed because it is too large Load Diff
Documentation/i2c/chips/max6875
+1 -1
View File
@@ -49,7 +49,7 @@ $ modprobe max6875 force=0,0x50
The MAX6874/MAX6875 ignores address bit 0, so this driver attaches to multiple
addresses. For example, for address 0x50, it also reserves 0x51.
The even-address instance is called 'max6875', the odd one is 'max6875 subclient'.
The even-address instance is called 'max6875', the odd one is 'dummy'.
Programming the chip using i2c-dev
Documentation/i2c/chips/pca9539
+9 -1
View File
@@ -7,7 +7,7 @@ drivers/gpio/pca9539.c instead.
Supported chips:
* Philips PCA9539
Prefix: 'pca9539'
Addresses scanned: 0x74 - 0x77
Addresses scanned: none
Datasheet:
http://www.semiconductors.philips.com/acrobat/datasheets/PCA9539_2.pdf
@@ -23,6 +23,14 @@ The input sense can also be inverted.
The 16 lines are split between two bytes.
Detection
---------
The PCA9539 is difficult to detect and not commonly found in PC machines,
so you have to pass the I2C bus and address of the installed PCA9539
devices explicitly to the driver at load time via the force=... parameter.
Sysfs entries
-------------
Documentation/i2c/chips/pcf8574
+5 -7
View File
@@ -4,13 +4,13 @@ Kernel driver pcf8574
Supported chips:
* Philips PCF8574
Prefix: 'pcf8574'
Addresses scanned: I2C 0x20 - 0x27
Addresses scanned: none
Datasheet: Publicly available at the Philips Semiconductors website
http://www.semiconductors.philips.com/pip/PCF8574P.html
* Philips PCF8574A
Prefix: 'pcf8574a'
Addresses scanned: I2C 0x38 - 0x3f
Addresses scanned: none
Datasheet: Publicly available at the Philips Semiconductors website
http://www.semiconductors.philips.com/pip/PCF8574P.html
@@ -38,12 +38,10 @@ For more informations see the datasheet.
Accessing PCF8574(A) via /sys interface
-------------------------------------
! Be careful !
The PCF8574(A) is plainly impossible to detect ! Stupid chip.
So every chip with address in the interval [20..27] and [38..3f] are
detected as PCF8574(A). If you have other chips in this address
range, the workaround is to load this module after the one
for your others chips.
So, you have to pass the I2C bus and address of the installed PCF857A
and PCF8574A devices explicitly to the driver at load time via the
force=... parameter.
On detection (i.e. insmod, modprobe et al.), directories are being
created for each detected PCF8574(A):
Documentation/i2c/chips/pcf8575
+3 -6
View File
@@ -40,12 +40,9 @@ Detection
---------
There is no method known to detect whether a chip on a given I2C address is
a PCF8575 or whether it is any other I2C device. So there are two alternatives
to let the driver find the installed PCF8575 devices:
- Load this driver after any other I2C driver for I2C devices with addresses
in the range 0x20 .. 0x27.
- Pass the I2C bus and address of the installed PCF8575 devices explicitly to
the driver at load time via the probe=... or force=... parameters.
a PCF8575 or whether it is any other I2C device, so you have to pass the I2C
bus and address of the installed PCF8575 devices explicitly to the driver at
load time via the force=... parameter.
/sys interface
--------------
Documentation/ioctl/hdio.txt
+4 -3
View File
@@ -508,12 +508,13 @@ HDIO_DRIVE_RESET execute a device reset
error returns:
EACCES Access denied: requires CAP_SYS_ADMIN
ENXIO No such device: phy dead or ctl_addr == 0
EIO I/O error: reset timed out or hardware error
notes:
Abort any current command, prevent anything else from being
queued, execute a reset on the device, and issue BLKRRPART
ioctl on the block device.
Execute a reset on the device as soon as the current IO
operation has completed.
Executes an ATAPI soft reset if applicable, otherwise
executes an ATA soft reset on the controller.
Documentation/kernel-parameters.txt
+12 -2
View File
@@ -147,10 +147,14 @@ and is between 256 and 4096 characters. It is defined in the file
default: 0
acpi_sleep= [HW,ACPI] Sleep options
Format: { s3_bios, s3_mode, s3_beep }
Format: { s3_bios, s3_mode, s3_beep, old_ordering }
See Documentation/power/video.txt for s3_bios and s3_mode.
s3_beep is for debugging; it makes the PC's speaker beep
as soon as the kernel's real-mode entry point is called.
old_ordering causes the ACPI 1.0 ordering of the _PTS
control method, wrt putting devices into low power
states, to be enforced (the ACPI 2.0 ordering of _PTS is
used by default).
acpi_sci= [HW,ACPI] ACPI System Control Interrupt trigger mode
Format: { level | edge | high | low }
@@ -818,7 +822,7 @@ and is between 256 and 4096 characters. It is defined in the file
See Documentation/ide/ide.txt.
idle= [X86]
Format: idle=poll or idle=mwait
Format: idle=poll or idle=mwait, idle=halt, idle=nomwait
Poll forces a polling idle loop that can slightly improves the performance
of waking up a idle CPU, but will use a lot of power and make the system
run hot. Not recommended.
@@ -826,6 +830,9 @@ and is between 256 and 4096 characters. It is defined in the file
to not use it because it doesn't save as much power as a normal idle
loop use the MONITOR/MWAIT idle loop anyways. Performance should be the same
as idle=poll.
idle=halt. Halt is forced to be used for CPU idle.
In such case C2/C3 won't be used again.
idle=nomwait. Disable mwait for CPU C-states
ide-pci-generic.all-generic-ide [HW] (E)IDE subsystem
Claim all unknown PCI IDE storage controllers.
@@ -1534,6 +1541,9 @@ and is between 256 and 4096 characters. It is defined in the file
Use with caution as certain devices share
address decoders between ROMs and other
resources.
norom [X86-32,X86_64] Do not assign address space to
expansion ROMs that do not already have
BIOS assigned address ranges.
irqmask=0xMMMM [X86-32] Set a bit mask of IRQs allowed to be
assigned automatically to PCI devices. You can
make the kernel exclude IRQs of your ISA cards
Documentation/kprobes.txt
+1
View File
@@ -172,6 +172,7 @@ architectures:
- ia64 (Does not support probes on instruction slot1.)
- sparc64 (Return probes not yet implemented.)
- arm
- ppc
3. Configuring Kprobes
Documentation/laptops/acer-wmi.txt
-2
View File
@@ -174,8 +174,6 @@ The LED is exposed through the LED subsystem, and can be found in:
The mail LED is autodetected, so if you don't have one, the LED device won't
be registered.
If you have a mail LED that is not green, please report this to me.
Backlight
*********
Documentation/powerpc/booting-without-of.txt
+12 -1070
View File
File diff suppressed because it is too large Load Diff
Documentation/powerpc/bootwrapper.txt
+141
View File
@@ -0,0 +1,141 @@
The PowerPC boot wrapper
------------------------
Copyright (C) Secret Lab Technologies Ltd.
PowerPC image targets compresses and wraps the kernel image (vmlinux) with
a boot wrapper to make it usable by the system firmware. There is no
standard PowerPC firmware interface, so the boot wrapper is designed to
be adaptable for each kind of image that needs to be built.
The boot wrapper can be found in the arch/powerpc/boot/ directory. The
Makefile in that directory has targets for all the available image types.
The different image types are used to support all of the various firmware
interfaces found on PowerPC platforms. OpenFirmware is the most commonly
used firmware type on general purpose PowerPC systems from Apple, IBM and
others. U-Boot is typically found on embedded PowerPC hardware, but there
are a handful of other firmware implementations which are also popular. Each
firmware interface requires a different image format.
The boot wrapper is built from the makefile in arch/powerpc/boot/Makefile and
it uses the wrapper script (arch/powerpc/boot/wrapper) to generate target
image. The details of the build system is discussed in the next section.
Currently, the following image format targets exist:
cuImage.%: Backwards compatible uImage for older version of
U-Boot (for versions that don't understand the device
tree). This image embeds a device tree blob inside
the image. The boot wrapper, kernel and device tree
are all embedded inside the U-Boot uImage file format
with boot wrapper code that extracts data from the old
bd_info structure and loads the data into the device
tree before jumping into the kernel.
Because of the series of #ifdefs found in the
bd_info structure used in the old U-Boot interfaces,
cuImages are platform specific. Each specific
U-Boot platform has a different platform init file
which populates the embedded device tree with data
from the platform specific bd_info file. The platform
specific cuImage platform init code can be found in
arch/powerpc/boot/cuboot.*.c. Selection of the correct
cuImage init code for a specific board can be found in
the wrapper structure.
dtbImage.%: Similar to zImage, except device tree blob is embedded
inside the image instead of provided by firmware. The
output image file can be either an elf file or a flat
binary depending on the platform.
dtbImages are used on systems which do not have an
interface for passing a device tree directly.
dtbImages are similar to simpleImages except that
dtbImages have platform specific code for extracting
data from the board firmware, but simpleImages do not
talk to the firmware at all.
PlayStation 3 support uses dtbImage. So do Embedded
Planet boards using the PlanetCore firmware. Board
specific initialization code is typically found in a
file named arch/powerpc/boot/<platform>.c; but this
can be overridden by the wrapper script.
simpleImage.%: Firmware independent compressed image that does not
depend on any particular firmware interface and embeds
a device tree blob. This image is a flat binary that
can be loaded to any location in RAM and jumped to.
Firmware cannot pass any configuration data to the
kernel with this image type and it depends entirely on
the embedded device tree for all information.
The simpleImage is useful for booting systems with
an unknown firmware interface or for booting from
a debugger when no firmware is present (such as on
the Xilinx Virtex platform). The only assumption that
simpleImage makes is that RAM is correctly initialized
and that the MMU is either off or has RAM mapped to
base address 0.
simpleImage also supports inserting special platform
specific initialization code to the start of the bootup
sequence. The virtex405 platform uses this feature to
ensure that the cache is invalidated before caching
is enabled. Platform specific initialization code is
added as part of the wrapper script and is keyed on
the image target name. For example, all
simpleImage.virtex405-* targets will add the
virtex405-head.S initialization code (This also means
that the dts file for virtex405 targets should be
named (virtex405-<board>.dts). Search the wrapper
script for 'virtex405' and see the file
arch/powerpc/boot/virtex405-head.S for details.
treeImage.%; Image format for used with OpenBIOS firmware found
on some ppc4xx hardware. This image embeds a device
tree blob inside the image.
uImage: Native image format used by U-Boot. The uImage target
does not add any boot code. It just wraps a compressed
vmlinux in the uImage data structure. This image
requires a version of U-Boot that is able to pass
a device tree to the kernel at boot. If using an older
version of U-Boot, then you need to use a cuImage
instead.
zImage.%: Image format which does not embed a device tree.
Used by OpenFirmware and other firmware interfaces
which are able to supply a device tree. This image
expects firmware to provide the device tree at boot.
Typically, if you have general purpose PowerPC
hardware then you want this image format.
Image types which embed a device tree blob (simpleImage, dtbImage, treeImage,
and cuImage) all generate the device tree blob from a file in the
arch/powerpc/boot/dts/ directory. The Makefile selects the correct device
tree source based on the name of the target. Therefore, if the kernel is
built with 'make treeImage.walnut simpleImage.virtex405-ml403', then the
build system will use arch/powerpc/boot/dts/walnut.dts to build
treeImage.walnut and arch/powerpc/boot/dts/virtex405-ml403.dts to build
the simpleImage.virtex405-ml403.
Two special targets called 'zImage' and 'zImage.initrd' also exist. These
targets build all the default images as selected by the kernel configuration.
Default images are selected by the boot wrapper Makefile
(arch/powerpc/boot/Makefile) by adding targets to the $image-y variable. Look
at the Makefile to see which default image targets are available.
How it is built
---------------
arch/powerpc is designed to support multiplatform kernels, which means
that a single vmlinux image can be booted on many different target boards.
It also means that the boot wrapper must be able to wrap for many kinds of
images on a single build. The design decision was made to not use any
conditional compilation code (#ifdef, etc) in the boot wrapper source code.
All of the boot wrapper pieces are buildable at any time regardless of the
kernel configuration. Building all the wrapper bits on every kernel build
also ensures that obscure parts of the wrapper are at the very least compile
tested in a large variety of environments.
The wrapper is adapted for different image types at link time by linking in
just the wrapper bits that are appropriate for the image type. The 'wrapper
script' (found in arch/powerpc/boot/wrapper) is called by the Makefile and
is responsible for selecting the correct wrapper bits for the image type.
The arguments are well documented in the script's comment block, so they
are not repeated here. However, it is worth mentioning that the script
uses the -p (platform) argument as the main method of deciding which wrapper
bits to compile in. Look for the large 'case "$platform" in' block in the
middle of the script. This is also the place where platform specific fixups
can be selected by changing the link order.
In particular, care should be taken when working with cuImages. cuImage
wrapper bits are very board specific and care should be taken to make sure
the target you are trying to build is supported by the wrapper bits.
Documentation/powerpc/dts-bindings/fsl/board.txt
+29
View File
@@ -0,0 +1,29 @@
* Board Control and Status (BCSR)
Required properties:
- device_type : Should be "board-control"
- reg : Offset and length of the register set for the device
Example:
bcsr@f8000000 {
device_type = "board-control";
reg = <f8000000 8000>;
};
* Freescale on board FPGA
This is the memory-mapped registers for on board FPGA.
Required properities:
- compatible : should be "fsl,fpga-pixis".
- reg : should contain the address and the lenght of the FPPGA register
set.
Example (MPC8610HPCD):
board-control@e8000000 {
compatible = "fsl,fpga-pixis";
reg = <0xe8000000 32>;
};
Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm.txt
+67
View File
@@ -0,0 +1,67 @@
* Freescale Communications Processor Module
NOTE: This is an interim binding, and will likely change slightly,
as more devices are supported. The QE bindings especially are
incomplete.
* Root CPM node
Properties:
- compatible : "fsl,cpm1", "fsl,cpm2", or "fsl,qe".
- reg : A 48-byte region beginning with CPCR.
Example:
cpm@119c0 {
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <2>;
compatible = "fsl,mpc8272-cpm", "fsl,cpm2";
reg = <119c0 30>;
}
* Properties common to mulitple CPM/QE devices
- fsl,cpm-command : This value is ORed with the opcode and command flag
to specify the device on which a CPM command operates.
- fsl,cpm-brg : Indicates which baud rate generator the device
is associated with. If absent, an unused BRG
should be dynamically allocated. If zero, the
device uses an external clock rather than a BRG.
- reg : Unless otherwise specified, the first resource represents the
scc/fcc/ucc registers, and the second represents the device's
parameter RAM region (if it has one).
* Multi-User RAM (MURAM)
The multi-user/dual-ported RAM is expressed as a bus under the CPM node.
Ranges must be set up subject to the following restrictions:
- Children's reg nodes must be offsets from the start of all muram, even
if the user-data area does not begin at zero.
- If multiple range entries are used, the difference between the parent
address and the child address must be the same in all, so that a single
mapping can cover them all while maintaining the ability to determine
CPM-side offsets with pointer subtraction. It is recommended that
multiple range entries not be used.
- A child address of zero must be translatable, even if no reg resources
contain it.
A child "data" node must exist, compatible with "fsl,cpm-muram-data", to
indicate the portion of muram that is usable by the OS for arbitrary
purposes. The data node may have an arbitrary number of reg resources,
all of which contribute to the allocatable muram pool.
Example, based on mpc8272:
muram@0 {
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0 10000>;
data@0 {
compatible = "fsl,cpm-muram-data";
reg = <0 2000 9800 800>;
};
};
Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/brg.txt
+21
View File
@@ -0,0 +1,21 @@
* Baud Rate Generators
Currently defined compatibles:
fsl,cpm-brg
fsl,cpm1-brg
fsl,cpm2-brg
Properties:
- reg : There may be an arbitrary number of reg resources; BRG
numbers are assigned to these in order.
- clock-frequency : Specifies the base frequency driving
the BRG.
Example:
brg@119f0 {
compatible = "fsl,mpc8272-brg",
"fsl,cpm2-brg",
"fsl,cpm-brg";
reg = <119f0 10 115f0 10>;
clock-frequency = <d#25000000>;
};
Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/i2c.txt
+41
View File
@@ -0,0 +1,41 @@
* I2C
The I2C controller is expressed as a bus under the CPM node.
Properties:
- compatible : "fsl,cpm1-i2c", "fsl,cpm2-i2c"
- reg : On CPM2 devices, the second resource doesn't specify the I2C
Parameter RAM itself, but the I2C_BASE field of the CPM2 Parameter RAM
(typically 0x8afc 0x2).
- #address-cells : Should be one. The cell is the i2c device address with
the r/w bit set to zero.
- #size-cells : Should be zero.
- clock-frequency : Can be used to set the i2c clock frequency. If
unspecified, a default frequency of 60kHz is being used.
The following two properties are deprecated. They are only used by legacy
i2c drivers to find the bus to probe:
- linux,i2c-index : Can be used to hard code an i2c bus number. By default,
the bus number is dynamically assigned by the i2c core.
- linux,i2c-class : Can be used to override the i2c class. The class is used
by legacy i2c device drivers to find a bus in a specific context like
system management, video or sound. By default, I2C_CLASS_HWMON (1) is
being used. The definition of the classes can be found in
include/i2c/i2c.h
Example, based on mpc823:
i2c@860 {
compatible = "fsl,mpc823-i2c",
"fsl,cpm1-i2c";
reg = <0x860 0x20 0x3c80 0x30>;
interrupts = <16>;
interrupt-parent = <&CPM_PIC>;
fsl,cpm-command = <0x10>;
#address-cells = <1>;
#size-cells = <0>;
rtc@68 {
compatible = "dallas,ds1307";
reg = <0x68>;
};
};
Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/pic.txt
+18
View File
@@ -0,0 +1,18 @@
* Interrupt Controllers
Currently defined compatibles:
- fsl,cpm1-pic
- only one interrupt cell
- fsl,pq1-pic
- fsl,cpm2-pic
- second interrupt cell is level/sense:
- 2 is falling edge
- 8 is active low
Example:
interrupt-controller@10c00 {
#interrupt-cells = <2>;
interrupt-controller;
reg = <10c00 80>;
compatible = "mpc8272-pic", "fsl,cpm2-pic";
};

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