mirror of
https://github.com/armbian/linux.git
synced 2026-01-06 10:13:00 -08:00
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
This commit is contained in:
Paul Mundt
7
Documentation/ABI/testing/sysfs-devices-node
Normal file
7
Documentation/ABI/testing/sysfs-devices-node
Normal file
@@ -0,0 +1,7 @@
|
||||
What: /sys/devices/system/node/nodeX/compact
|
||||
Date: February 2010
|
||||
Contact: Mel Gorman <mel@csn.ul.ie>
|
||||
Description:
|
||||
When this file is written to, all memory within that node
|
||||
will be compacted. When it completes, memory will be freed
|
||||
into blocks which have as many contiguous pages as possible
|
||||
15
Documentation/ABI/testing/sysfs-firmware-sfi
Normal file
15
Documentation/ABI/testing/sysfs-firmware-sfi
Normal file
@@ -0,0 +1,15 @@
|
||||
What: /sys/firmware/sfi/tables/
|
||||
Date: May 2010
|
||||
Contact: Len Brown <lenb@kernel.org>
|
||||
Description:
|
||||
SFI defines a number of small static memory tables
|
||||
so the kernel can get platform information from firmware.
|
||||
|
||||
The tables are defined in the latest SFI specification:
|
||||
http://simplefirmware.org/documentation
|
||||
|
||||
While the tables are used by the kernel, user-space
|
||||
can observe them this way:
|
||||
|
||||
# cd /sys/firmware/sfi/tables
|
||||
# cat $TABLENAME > $TABLENAME.bin
|
||||
@@ -639,6 +639,36 @@ is planned to completely remove virt_to_bus() and bus_to_virt() as
|
||||
they are entirely deprecated. Some ports already do not provide these
|
||||
as it is impossible to correctly support them.
|
||||
|
||||
Handling Errors
|
||||
|
||||
DMA address space is limited on some architectures and an allocation
|
||||
failure can be determined by:
|
||||
|
||||
- checking if dma_alloc_coherent returns NULL or dma_map_sg returns 0
|
||||
|
||||
- checking the returned dma_addr_t of dma_map_single and dma_map_page
|
||||
by using dma_mapping_error():
|
||||
|
||||
dma_addr_t dma_handle;
|
||||
|
||||
dma_handle = dma_map_single(dev, addr, size, direction);
|
||||
if (dma_mapping_error(dev, dma_handle)) {
|
||||
/*
|
||||
* reduce current DMA mapping usage,
|
||||
* delay and try again later or
|
||||
* reset driver.
|
||||
*/
|
||||
}
|
||||
|
||||
Networking drivers must call dev_kfree_skb to free the socket buffer
|
||||
and return NETDEV_TX_OK if the DMA mapping fails on the transmit hook
|
||||
(ndo_start_xmit). This means that the socket buffer is just dropped in
|
||||
the failure case.
|
||||
|
||||
SCSI drivers must return SCSI_MLQUEUE_HOST_BUSY if the DMA mapping
|
||||
fails in the queuecommand hook. This means that the SCSI subsystem
|
||||
passes the command to the driver again later.
|
||||
|
||||
Optimizing Unmap State Space Consumption
|
||||
|
||||
On many platforms, dma_unmap_{single,page}() is simply a nop.
|
||||
@@ -703,42 +733,25 @@ to "Closing".
|
||||
|
||||
1) Struct scatterlist requirements.
|
||||
|
||||
Struct scatterlist must contain, at a minimum, the following
|
||||
members:
|
||||
Don't invent the architecture specific struct scatterlist; just use
|
||||
<asm-generic/scatterlist.h>. You need to enable
|
||||
CONFIG_NEED_SG_DMA_LENGTH if the architecture supports IOMMUs
|
||||
(including software IOMMU).
|
||||
|
||||
struct page *page;
|
||||
unsigned int offset;
|
||||
unsigned int length;
|
||||
2) ARCH_KMALLOC_MINALIGN
|
||||
|
||||
The base address is specified by a "page+offset" pair.
|
||||
Architectures must ensure that kmalloc'ed buffer is
|
||||
DMA-safe. Drivers and subsystems depend on it. If an architecture
|
||||
isn't fully DMA-coherent (i.e. hardware doesn't ensure that data in
|
||||
the CPU cache is identical to data in main memory),
|
||||
ARCH_KMALLOC_MINALIGN must be set so that the memory allocator
|
||||
makes sure that kmalloc'ed buffer doesn't share a cache line with
|
||||
the others. See arch/arm/include/asm/cache.h as an example.
|
||||
|
||||
Previous versions of struct scatterlist contained a "void *address"
|
||||
field that was sometimes used instead of page+offset. As of Linux
|
||||
2.5., page+offset is always used, and the "address" field has been
|
||||
deleted.
|
||||
|
||||
2) More to come...
|
||||
|
||||
Handling Errors
|
||||
|
||||
DMA address space is limited on some architectures and an allocation
|
||||
failure can be determined by:
|
||||
|
||||
- checking if dma_alloc_coherent returns NULL or dma_map_sg returns 0
|
||||
|
||||
- checking the returned dma_addr_t of dma_map_single and dma_map_page
|
||||
by using dma_mapping_error():
|
||||
|
||||
dma_addr_t dma_handle;
|
||||
|
||||
dma_handle = dma_map_single(dev, addr, size, direction);
|
||||
if (dma_mapping_error(dev, dma_handle)) {
|
||||
/*
|
||||
* reduce current DMA mapping usage,
|
||||
* delay and try again later or
|
||||
* reset driver.
|
||||
*/
|
||||
}
|
||||
Note that ARCH_KMALLOC_MINALIGN is about DMA memory alignment
|
||||
constraints. You don't need to worry about the architecture data
|
||||
alignment constraints (e.g. the alignment constraints about 64-bit
|
||||
objects).
|
||||
|
||||
Closing
|
||||
|
||||
|
||||
@@ -130,6 +130,8 @@ Linux kernel master tree:
|
||||
ftp.??.kernel.org:/pub/linux/kernel/...
|
||||
?? == your country code, such as "us", "uk", "fr", etc.
|
||||
|
||||
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git
|
||||
|
||||
Linux kernel mailing list:
|
||||
linux-kernel@vger.kernel.org
|
||||
[mail majordomo@vger.kernel.org to subscribe]
|
||||
@@ -160,3 +162,6 @@ How to NOT write kernel driver by Arjan van de Ven:
|
||||
|
||||
Kernel Janitor:
|
||||
http://janitor.kernelnewbies.org/
|
||||
|
||||
GIT, Fast Version Control System:
|
||||
http://git-scm.com/
|
||||
|
||||
59
Documentation/acpi/apei/einj.txt
Normal file
59
Documentation/acpi/apei/einj.txt
Normal file
@@ -0,0 +1,59 @@
|
||||
APEI Error INJection
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
EINJ provides a hardware error injection mechanism
|
||||
It is very useful for debugging and testing of other APEI and RAS features.
|
||||
|
||||
To use EINJ, make sure the following are enabled in your kernel
|
||||
configuration:
|
||||
|
||||
CONFIG_DEBUG_FS
|
||||
CONFIG_ACPI_APEI
|
||||
CONFIG_ACPI_APEI_EINJ
|
||||
|
||||
The user interface of EINJ is debug file system, under the
|
||||
directory apei/einj. The following files are provided.
|
||||
|
||||
- available_error_type
|
||||
Reading this file returns the error injection capability of the
|
||||
platform, that is, which error types are supported. The error type
|
||||
definition is as follow, the left field is the error type value, the
|
||||
right field is error description.
|
||||
|
||||
0x00000001 Processor Correctable
|
||||
0x00000002 Processor Uncorrectable non-fatal
|
||||
0x00000004 Processor Uncorrectable fatal
|
||||
0x00000008 Memory Correctable
|
||||
0x00000010 Memory Uncorrectable non-fatal
|
||||
0x00000020 Memory Uncorrectable fatal
|
||||
0x00000040 PCI Express Correctable
|
||||
0x00000080 PCI Express Uncorrectable fatal
|
||||
0x00000100 PCI Express Uncorrectable non-fatal
|
||||
0x00000200 Platform Correctable
|
||||
0x00000400 Platform Uncorrectable non-fatal
|
||||
0x00000800 Platform Uncorrectable fatal
|
||||
|
||||
The format of file contents are as above, except there are only the
|
||||
available error type lines.
|
||||
|
||||
- error_type
|
||||
This file is used to set the error type value. The error type value
|
||||
is defined in "available_error_type" description.
|
||||
|
||||
- error_inject
|
||||
Write any integer to this file to trigger the error
|
||||
injection. Before this, please specify all necessary error
|
||||
parameters.
|
||||
|
||||
- param1
|
||||
This file is used to set the first error parameter value. Effect of
|
||||
parameter depends on error_type specified. For memory error, this is
|
||||
physical memory address.
|
||||
|
||||
- param2
|
||||
This file is used to set the second error parameter value. Effect of
|
||||
parameter depends on error_type specified. For memory error, this is
|
||||
physical memory address mask.
|
||||
|
||||
For more information about EINJ, please refer to ACPI specification
|
||||
version 4.0, section 17.5.
|
||||
@@ -12,6 +12,8 @@ Introduction
|
||||
of the s3c2410 GPIO system, please read the Samsung provided
|
||||
data-sheet/users manual to find out the complete list.
|
||||
|
||||
See Documentation/arm/Samsung/GPIO.txt for the core implemetation.
|
||||
|
||||
|
||||
GPIOLIB
|
||||
-------
|
||||
@@ -24,8 +26,60 @@ GPIOLIB
|
||||
listed below will be removed (they may be marked as __deprecated
|
||||
in the near future).
|
||||
|
||||
- s3c2410_gpio_getpin
|
||||
- s3c2410_gpio_setpin
|
||||
The following functions now either have a s3c_ specific variant
|
||||
or are merged into gpiolib. See the definitions in
|
||||
arch/arm/plat-samsung/include/plat/gpio-cfg.h:
|
||||
|
||||
s3c2410_gpio_setpin() gpio_set_value() or gpio_direction_output()
|
||||
s3c2410_gpio_getpin() gpio_get_value() or gpio_direction_input()
|
||||
s3c2410_gpio_getirq() gpio_to_irq()
|
||||
s3c2410_gpio_cfgpin() s3c_gpio_cfgpin()
|
||||
s3c2410_gpio_getcfg() s3c_gpio_getcfg()
|
||||
s3c2410_gpio_pullup() s3c_gpio_setpull()
|
||||
|
||||
|
||||
GPIOLIB conversion
|
||||
------------------
|
||||
|
||||
If you need to convert your board or driver to use gpiolib from the exiting
|
||||
s3c2410 api, then here are some notes on the process.
|
||||
|
||||
1) If your board is exclusively using an GPIO, say to control peripheral
|
||||
power, then it will require to claim the gpio with gpio_request() before
|
||||
it can use it.
|
||||
|
||||
It is recommended to check the return value, with at least WARN_ON()
|
||||
during initialisation.
|
||||
|
||||
2) The s3c2410_gpio_cfgpin() can be directly replaced with s3c_gpio_cfgpin()
|
||||
as they have the same arguments, and can either take the pin specific
|
||||
values, or the more generic special-function-number arguments.
|
||||
|
||||
3) s3c2410_gpio_pullup() changs have the problem that whilst the
|
||||
s3c2410_gpio_pullup(x, 1) can be easily translated to the
|
||||
s3c_gpio_setpull(x, S3C_GPIO_PULL_NONE), the s3c2410_gpio_pullup(x, 0)
|
||||
are not so easy.
|
||||
|
||||
The s3c2410_gpio_pullup(x, 0) case enables the pull-up (or in the case
|
||||
of some of the devices, a pull-down) and as such the new API distinguishes
|
||||
between the UP and DOWN case. There is currently no 'just turn on' setting
|
||||
which may be required if this becomes a problem.
|
||||
|
||||
4) s3c2410_gpio_setpin() can be replaced by gpio_set_value(), the old call
|
||||
does not implicitly configure the relevant gpio to output. The gpio
|
||||
direction should be changed before using gpio_set_value().
|
||||
|
||||
5) s3c2410_gpio_getpin() is replaceable by gpio_get_value() if the pin
|
||||
has been set to input. It is currently unknown what the behaviour is
|
||||
when using gpio_get_value() on an output pin (s3c2410_gpio_getpin
|
||||
would return the value the pin is supposed to be outputting).
|
||||
|
||||
6) s3c2410_gpio_getirq() should be directly replacable with the
|
||||
gpio_to_irq() call.
|
||||
|
||||
The s3c2410_gpio and gpio_ calls have always operated on the same gpio
|
||||
numberspace, so there is no problem with converting the gpio numbering
|
||||
between the calls.
|
||||
|
||||
|
||||
Headers
|
||||
@@ -54,6 +108,11 @@ PIN Numbers
|
||||
eg S3C2410_GPA(0) or S3C2410_GPF(1). These defines are used to tell
|
||||
the GPIO functions which pin is to be used.
|
||||
|
||||
With the conversion to gpiolib, there is no longer a direct conversion
|
||||
from gpio pin number to register base address as in earlier kernels. This
|
||||
is due to the number space required for newer SoCs where the later
|
||||
GPIOs are not contiguous.
|
||||
|
||||
|
||||
Configuring a pin
|
||||
-----------------
|
||||
@@ -71,6 +130,8 @@ Configuring a pin
|
||||
which would turn GPA(0) into the lowest Address line A0, and set
|
||||
GPE(8) to be connected to the SDIO/MMC controller's SDDAT1 line.
|
||||
|
||||
The s3c_gpio_cfgpin() call is a functional replacement for this call.
|
||||
|
||||
|
||||
Reading the current configuration
|
||||
---------------------------------
|
||||
@@ -82,6 +143,9 @@ Reading the current configuration
|
||||
The return value will be from the same set of values which can be
|
||||
passed to s3c2410_gpio_cfgpin().
|
||||
|
||||
The s3c_gpio_getcfg() call should be a functional replacement for
|
||||
this call.
|
||||
|
||||
|
||||
Configuring a pull-up resistor
|
||||
------------------------------
|
||||
@@ -95,6 +159,10 @@ Configuring a pull-up resistor
|
||||
Where the to value is zero to set the pull-up off, and 1 to enable
|
||||
the specified pull-up. Any other values are currently undefined.
|
||||
|
||||
The s3c_gpio_setpull() offers similar functionality, but with the
|
||||
ability to encode whether the pull is up or down. Currently there
|
||||
is no 'just on' state, so up or down must be selected.
|
||||
|
||||
|
||||
Getting the state of a PIN
|
||||
--------------------------
|
||||
@@ -106,6 +174,9 @@ Getting the state of a PIN
|
||||
This will return either zero or non-zero. Do not count on this
|
||||
function returning 1 if the pin is set.
|
||||
|
||||
This call is now implemented by the relevant gpiolib calls, convert
|
||||
your board or driver to use gpiolib.
|
||||
|
||||
|
||||
Setting the state of a PIN
|
||||
--------------------------
|
||||
@@ -117,6 +188,9 @@ Setting the state of a PIN
|
||||
Which sets the given pin to the value. Use 0 to write 0, and 1 to
|
||||
set the output to 1.
|
||||
|
||||
This call is now implemented by the relevant gpiolib calls, convert
|
||||
your board or driver to use gpiolib.
|
||||
|
||||
|
||||
Getting the IRQ number associated with a PIN
|
||||
--------------------------------------------
|
||||
@@ -128,6 +202,9 @@ Getting the IRQ number associated with a PIN
|
||||
|
||||
Note, not all pins have an IRQ.
|
||||
|
||||
This call is now implemented by the relevant gpiolib calls, convert
|
||||
your board or driver to use gpiolib.
|
||||
|
||||
|
||||
Authour
|
||||
-------
|
||||
|
||||
@@ -8,10 +8,16 @@ Introduction
|
||||
|
||||
The Samsung S3C24XX range of ARM9 System-on-Chip CPUs are supported
|
||||
by the 's3c2410' architecture of ARM Linux. Currently the S3C2410,
|
||||
S3C2412, S3C2413, S3C2440, S3C2442 and S3C2443 devices are supported.
|
||||
S3C2412, S3C2413, S3C2416 S3C2440, S3C2442, S3C2443 and S3C2450 devices
|
||||
are supported.
|
||||
|
||||
Support for the S3C2400 and S3C24A0 series are in progress.
|
||||
|
||||
The S3C2416 and S3C2450 devices are very similar and S3C2450 support is
|
||||
included under the arch/arm/mach-s3c2416 directory. Note, whilst core
|
||||
support for these SoCs is in, work on some of the extra peripherals
|
||||
and extra interrupts is still ongoing.
|
||||
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
@@ -209,6 +215,13 @@ GPIO
|
||||
Newer kernels carry GPIOLIB, and support is being moved towards
|
||||
this with some of the older support in line to be removed.
|
||||
|
||||
As of v2.6.34, the move towards using gpiolib support is almost
|
||||
complete, and very little of the old calls are left.
|
||||
|
||||
See Documentation/arm/Samsung-S3C24XX/GPIO.txt for the S3C24XX specific
|
||||
support and Documentation/arm/Samsung/GPIO.txt for the core Samsung
|
||||
implementation.
|
||||
|
||||
|
||||
Clock Management
|
||||
----------------
|
||||
|
||||
42
Documentation/arm/Samsung/GPIO.txt
Normal file
42
Documentation/arm/Samsung/GPIO.txt
Normal file
@@ -0,0 +1,42 @@
|
||||
Samsung GPIO implementation
|
||||
===========================
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
This outlines the Samsung GPIO implementation and the architecture
|
||||
specfic calls provided alongisde the drivers/gpio core.
|
||||
|
||||
|
||||
S3C24XX (Legacy)
|
||||
----------------
|
||||
|
||||
See Documentation/arm/Samsung-S3C24XX/GPIO.txt for more information
|
||||
about these devices. Their implementation is being brought into line
|
||||
with the core samsung implementation described in this document.
|
||||
|
||||
|
||||
GPIOLIB integration
|
||||
-------------------
|
||||
|
||||
The gpio implementation uses gpiolib as much as possible, only providing
|
||||
specific calls for the items that require Samsung specific handling, such
|
||||
as pin special-function or pull resistor control.
|
||||
|
||||
GPIO numbering is synchronised between the Samsung and gpiolib system.
|
||||
|
||||
|
||||
PIN configuration
|
||||
-----------------
|
||||
|
||||
Pin configuration is specific to the Samsung architecutre, with each SoC
|
||||
registering the necessary information for the core gpio configuration
|
||||
implementation to configure pins as necessary.
|
||||
|
||||
The s3c_gpio_cfgpin() and s3c_gpio_setpull() provide the means for a
|
||||
driver or machine to change gpio configuration.
|
||||
|
||||
See arch/arm/plat-samsung/include/plat/gpio-cfg.h for more information
|
||||
on these functions.
|
||||
|
||||
|
||||
@@ -13,9 +13,10 @@ Introduction
|
||||
|
||||
- S3C24XX: See Documentation/arm/Samsung-S3C24XX/Overview.txt for full list
|
||||
- S3C64XX: S3C6400 and S3C6410
|
||||
- S5PC6440
|
||||
|
||||
S5PC100 and S5PC110 support is currently being merged
|
||||
- S5P6440
|
||||
- S5P6442
|
||||
- S5PC100
|
||||
- S5PC110 / S5PV210
|
||||
|
||||
|
||||
S3C24XX Systems
|
||||
@@ -35,7 +36,10 @@ Configuration
|
||||
unifying all the SoCs into one kernel.
|
||||
|
||||
s5p6440_defconfig - S5P6440 specific default configuration
|
||||
s5p6442_defconfig - S5P6442 specific default configuration
|
||||
s5pc100_defconfig - S5PC100 specific default configuration
|
||||
s5pc110_defconfig - S5PC110 specific default configuration
|
||||
s5pv210_defconfig - S5PV210 specific default configuration
|
||||
|
||||
|
||||
Layout
|
||||
@@ -50,18 +54,27 @@ Layout
|
||||
specific information. It contains the base clock, GPIO and device definitions
|
||||
to get the system running.
|
||||
|
||||
plat-s3c is the s3c24xx/s3c64xx platform directory, although it is currently
|
||||
involved in other builds this will be phased out once the relevant code is
|
||||
moved elsewhere.
|
||||
|
||||
plat-s3c24xx is for s3c24xx specific builds, see the S3C24XX docs.
|
||||
|
||||
plat-s3c64xx is for the s3c64xx specific bits, see the S3C24XX docs.
|
||||
|
||||
plat-s5p is for s5p specific builds, more to be added.
|
||||
plat-s5p is for s5p specific builds, and contains common support for the
|
||||
S5P specific systems. Not all S5Ps use all the features in this directory
|
||||
due to differences in the hardware.
|
||||
|
||||
|
||||
Layout changes
|
||||
--------------
|
||||
|
||||
The old plat-s3c and plat-s5pc1xx directories have been removed, with
|
||||
support moved to either plat-samsung or plat-s5p as necessary. These moves
|
||||
where to simplify the include and dependency issues involved with having
|
||||
so many different platform directories.
|
||||
|
||||
It was decided to remove plat-s5pc1xx as some of the support was already
|
||||
in plat-s5p or plat-samsung, with the S5PC110 support added with S5PV210
|
||||
the only user was the S5PC100. The S5PC100 specific items where moved to
|
||||
arch/arm/mach-s5pc100.
|
||||
|
||||
|
||||
[ to finish ]
|
||||
|
||||
|
||||
Port Contributors
|
||||
|
||||
@@ -339,7 +339,7 @@ To mount a cgroup hierarchy with all available subsystems, type:
|
||||
The "xxx" is not interpreted by the cgroup code, but will appear in
|
||||
/proc/mounts so may be any useful identifying string that you like.
|
||||
|
||||
To mount a cgroup hierarchy with just the cpuset and numtasks
|
||||
To mount a cgroup hierarchy with just the cpuset and memory
|
||||
subsystems, type:
|
||||
# mount -t cgroup -o cpuset,memory hier1 /dev/cgroup
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -443,6 +443,8 @@ Your cooperation is appreciated.
|
||||
231 = /dev/snapshot System memory snapshot device
|
||||
232 = /dev/kvm Kernel-based virtual machine (hardware virtualization extensions)
|
||||
233 = /dev/kmview View-OS A process with a view
|
||||
234 = /dev/btrfs-control Btrfs control device
|
||||
235 = /dev/autofs Autofs control device
|
||||
240-254 Reserved for local use
|
||||
255 Reserved for MISC_DYNAMIC_MINOR
|
||||
|
||||
|
||||
@@ -646,3 +646,13 @@ Who: Thomas Gleixner <tglx@linutronix.de>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: old ieee1394 subsystem (CONFIG_IEEE1394)
|
||||
When: 2.6.37
|
||||
Files: drivers/ieee1394/ except init_ohci1394_dma.c
|
||||
Why: superseded by drivers/firewire/ (CONFIG_FIREWIRE) which offers more
|
||||
features, better performance, and better security, all with smaller
|
||||
and more modern code base
|
||||
Who: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
||||
|
||||
----------------------------
|
||||
|
||||
|
||||
@@ -380,7 +380,7 @@ prototypes:
|
||||
int (*open) (struct inode *, struct file *);
|
||||
int (*flush) (struct file *);
|
||||
int (*release) (struct inode *, struct file *);
|
||||
int (*fsync) (struct file *, struct dentry *, int datasync);
|
||||
int (*fsync) (struct file *, int datasync);
|
||||
int (*aio_fsync) (struct kiocb *, int datasync);
|
||||
int (*fasync) (int, struct file *, int);
|
||||
int (*lock) (struct file *, int, struct file_lock *);
|
||||
@@ -429,8 +429,9 @@ check_flags: no
|
||||
implementations. If your fs is not using generic_file_llseek, you
|
||||
need to acquire and release the appropriate locks in your ->llseek().
|
||||
For many filesystems, it is probably safe to acquire the inode
|
||||
mutex. Note some filesystems (i.e. remote ones) provide no
|
||||
protection for i_size so you will need to use the BKL.
|
||||
mutex or just to use i_size_read() instead.
|
||||
Note: this does not protect the file->f_pos against concurrent modifications
|
||||
since this is something the userspace has to take care about.
|
||||
|
||||
Note: ext2_release() was *the* source of contention on fs-intensive
|
||||
loads and dropping BKL on ->release() helps to get rid of that (we still
|
||||
|
||||
@@ -38,7 +38,8 @@ Hard link support: yes no
|
||||
Real inode numbers: yes no
|
||||
32-bit uids/gids: yes no
|
||||
File creation time: yes no
|
||||
Xattr and ACL support: no no
|
||||
Xattr support: yes no
|
||||
ACL support: no no
|
||||
|
||||
Squashfs compresses data, inodes and directories. In addition, inode and
|
||||
directory data are highly compacted, and packed on byte boundaries. Each
|
||||
@@ -58,7 +59,7 @@ obtained from this site also.
|
||||
3. SQUASHFS FILESYSTEM DESIGN
|
||||
-----------------------------
|
||||
|
||||
A squashfs filesystem consists of seven parts, packed together on a byte
|
||||
A squashfs filesystem consists of a maximum of eight parts, packed together on a byte
|
||||
alignment:
|
||||
|
||||
---------------
|
||||
@@ -80,6 +81,9 @@ alignment:
|
||||
|---------------|
|
||||
| uid/gid |
|
||||
| lookup table |
|
||||
|---------------|
|
||||
| xattr |
|
||||
| table |
|
||||
---------------
|
||||
|
||||
Compressed data blocks are written to the filesystem as files are read from
|
||||
@@ -192,6 +196,26 @@ This table is stored compressed into metadata blocks. A second index table is
|
||||
used to locate these. This second index table for speed of access (and because
|
||||
it is small) is read at mount time and cached in memory.
|
||||
|
||||
3.7 Xattr table
|
||||
---------------
|
||||
|
||||
The xattr table contains extended attributes for each inode. The xattrs
|
||||
for each inode are stored in a list, each list entry containing a type,
|
||||
name and value field. The type field encodes the xattr prefix
|
||||
("user.", "trusted." etc) and it also encodes how the name/value fields
|
||||
should be interpreted. Currently the type indicates whether the value
|
||||
is stored inline (in which case the value field contains the xattr value),
|
||||
or if it is stored out of line (in which case the value field stores a
|
||||
reference to where the actual value is stored). This allows large values
|
||||
to be stored out of line improving scanning and lookup performance and it
|
||||
also allows values to be de-duplicated, the value being stored once, and
|
||||
all other occurences holding an out of line reference to that value.
|
||||
|
||||
The xattr lists are packed into compressed 8K metadata blocks.
|
||||
To reduce overhead in inodes, rather than storing the on-disk
|
||||
location of the xattr list inside each inode, a 32-bit xattr id
|
||||
is stored. This xattr id is mapped into the location of the xattr
|
||||
list using a second xattr id lookup table.
|
||||
|
||||
4. TODOS AND OUTSTANDING ISSUES
|
||||
-------------------------------
|
||||
@@ -199,9 +223,7 @@ it is small) is read at mount time and cached in memory.
|
||||
4.1 Todo list
|
||||
-------------
|
||||
|
||||
Implement Xattr and ACL support. The Squashfs 4.0 filesystem layout has hooks
|
||||
for these but the code has not been written. Once the code has been written
|
||||
the existing layout should not require modification.
|
||||
Implement ACL support.
|
||||
|
||||
4.2 Squashfs internal cache
|
||||
---------------------------
|
||||
|
||||
@@ -94,11 +94,19 @@ NodeList format is a comma-separated list of decimal numbers and ranges,
|
||||
a range being two hyphen-separated decimal numbers, the smallest and
|
||||
largest node numbers in the range. For example, mpol=bind:0-3,5,7,9-15
|
||||
|
||||
A memory policy with a valid NodeList will be saved, as specified, for
|
||||
use at file creation time. When a task allocates a file in the file
|
||||
system, the mount option memory policy will be applied with a NodeList,
|
||||
if any, modified by the calling task's cpuset constraints
|
||||
[See Documentation/cgroups/cpusets.txt] and any optional flags, listed
|
||||
below. If the resulting NodeLists is the empty set, the effective memory
|
||||
policy for the file will revert to "default" policy.
|
||||
|
||||
NUMA memory allocation policies have optional flags that can be used in
|
||||
conjunction with their modes. These optional flags can be specified
|
||||
when tmpfs is mounted by appending them to the mode before the NodeList.
|
||||
See Documentation/vm/numa_memory_policy.txt for a list of all available
|
||||
memory allocation policy mode flags.
|
||||
memory allocation policy mode flags and their effect on memory policy.
|
||||
|
||||
=static is equivalent to MPOL_F_STATIC_NODES
|
||||
=relative is equivalent to MPOL_F_RELATIVE_NODES
|
||||
|
||||
@@ -401,11 +401,16 @@ otherwise noted.
|
||||
started might not be in the page cache at the end of the
|
||||
walk).
|
||||
|
||||
truncate: called by the VFS to change the size of a file. The
|
||||
truncate: Deprecated. This will not be called if ->setsize is defined.
|
||||
Called by the VFS to change the size of a file. The
|
||||
i_size field of the inode is set to the desired size by the
|
||||
VFS before this method is called. This method is called by
|
||||
the truncate(2) system call and related functionality.
|
||||
|
||||
Note: ->truncate and vmtruncate are deprecated. Do not add new
|
||||
instances/calls of these. Filesystems should be converted to do their
|
||||
truncate sequence via ->setattr().
|
||||
|
||||
permission: called by the VFS to check for access rights on a POSIX-like
|
||||
filesystem.
|
||||
|
||||
@@ -729,7 +734,7 @@ struct file_operations {
|
||||
int (*open) (struct inode *, struct file *);
|
||||
int (*flush) (struct file *);
|
||||
int (*release) (struct inode *, struct file *);
|
||||
int (*fsync) (struct file *, struct dentry *, int datasync);
|
||||
int (*fsync) (struct file *, int datasync);
|
||||
int (*aio_fsync) (struct kiocb *, int datasync);
|
||||
int (*fasync) (int, struct file *, int);
|
||||
int (*lock) (struct file *, int, struct file_lock *);
|
||||
|
||||
816
Documentation/filesystems/xfs-delayed-logging-design.txt
Normal file
816
Documentation/filesystems/xfs-delayed-logging-design.txt
Normal file
File diff suppressed because it is too large
Load Diff
@@ -9,11 +9,15 @@ Supported chips:
|
||||
* SMSC SCH3112, SCH3114, SCH3116
|
||||
Prefix: 'sch311x'
|
||||
Addresses scanned: none, address read from Super-I/O config space
|
||||
Datasheet: http://www.nuhorizons.com/FeaturedProducts/Volume1/SMSC/311x.pdf
|
||||
Datasheet: Available on the Internet
|
||||
* SMSC SCH5027
|
||||
Prefix: 'sch5027'
|
||||
Addresses scanned: I2C 0x2c, 0x2d, 0x2e
|
||||
Datasheet: Provided by SMSC upon request and under NDA
|
||||
* SMSC SCH5127
|
||||
Prefix: 'sch5127'
|
||||
Addresses scanned: none, address read from Super-I/O config space
|
||||
Datasheet: Provided by SMSC upon request and under NDA
|
||||
|
||||
Authors:
|
||||
Juerg Haefliger <juergh@gmail.com>
|
||||
@@ -36,8 +40,8 @@ Description
|
||||
-----------
|
||||
|
||||
This driver implements support for the hardware monitoring capabilities of the
|
||||
SMSC DME1737 and Asus A8000 (which are the same), SMSC SCH5027, and SMSC
|
||||
SCH311x Super-I/O chips. These chips feature monitoring of 3 temp sensors
|
||||
SMSC DME1737 and Asus A8000 (which are the same), SMSC SCH5027, SCH311x,
|
||||
and SCH5127 Super-I/O chips. These chips feature monitoring of 3 temp sensors
|
||||
temp[1-3] (2 remote diodes and 1 internal), 7 voltages in[0-6] (6 external and
|
||||
1 internal) and up to 6 fan speeds fan[1-6]. Additionally, the chips implement
|
||||
up to 5 PWM outputs pwm[1-3,5-6] for controlling fan speeds both manually and
|
||||
@@ -48,14 +52,14 @@ Fan[3-6] and pwm[3,5-6] are optional features and their availability depends on
|
||||
the configuration of the chip. The driver will detect which features are
|
||||
present during initialization and create the sysfs attributes accordingly.
|
||||
|
||||
For the SCH311x, fan[1-3] and pwm[1-3] are always present and fan[4-6] and
|
||||
pwm[5-6] don't exist.
|
||||
For the SCH311x and SCH5127, fan[1-3] and pwm[1-3] are always present and
|
||||
fan[4-6] and pwm[5-6] don't exist.
|
||||
|
||||
The hardware monitoring features of the DME1737, A8000, and SCH5027 are only
|
||||
accessible via SMBus, while the SCH311x only provides access via the ISA bus.
|
||||
The driver will therefore register itself as an I2C client driver if it detects
|
||||
a DME1737, A8000, or SCH5027 and as a platform driver if it detects a SCH311x
|
||||
chip.
|
||||
accessible via SMBus, while the SCH311x and SCH5127 only provide access via
|
||||
the ISA bus. The driver will therefore register itself as an I2C client driver
|
||||
if it detects a DME1737, A8000, or SCH5027 and as a platform driver if it
|
||||
detects a SCH311x or SCH5127 chip.
|
||||
|
||||
|
||||
Voltage Monitoring
|
||||
@@ -76,7 +80,7 @@ DME1737, A8000:
|
||||
in6: Vbat (+3.0V) 0V - 4.38V
|
||||
|
||||
SCH311x:
|
||||
in0: +2.5V 0V - 6.64V
|
||||
in0: +2.5V 0V - 3.32V
|
||||
in1: Vccp (processor core) 0V - 2V
|
||||
in2: VCC (internal +3.3V) 0V - 4.38V
|
||||
in3: +5V 0V - 6.64V
|
||||
@@ -93,6 +97,15 @@ SCH5027:
|
||||
in5: VTR (+3.3V standby) 0V - 4.38V
|
||||
in6: Vbat (+3.0V) 0V - 4.38V
|
||||
|
||||
SCH5127:
|
||||
in0: +2.5 0V - 3.32V
|
||||
in1: Vccp (processor core) 0V - 3V
|
||||
in2: VCC (internal +3.3V) 0V - 4.38V
|
||||
in3: V2_IN 0V - 1.5V
|
||||
in4: V1_IN 0V - 1.5V
|
||||
in5: VTR (+3.3V standby) 0V - 4.38V
|
||||
in6: Vbat (+3.0V) 0V - 4.38V
|
||||
|
||||
Each voltage input has associated min and max limits which trigger an alarm
|
||||
when crossed.
|
||||
|
||||
@@ -293,3 +306,21 @@ pwm[1-3]_auto_point1_pwm RW Auto PWM pwm point. Auto_point1 is the
|
||||
pwm[1-3]_auto_point2_pwm RO Auto PWM pwm point. Auto_point2 is the
|
||||
full-speed duty-cycle which is hard-
|
||||
wired to 255 (100% duty-cycle).
|
||||
|
||||
Chip Differences
|
||||
----------------
|
||||
|
||||
Feature dme1737 sch311x sch5027 sch5127
|
||||
-------------------------------------------------------
|
||||
temp[1-3]_offset yes yes
|
||||
vid yes
|
||||
zone3 yes yes yes
|
||||
zone[1-3]_hyst yes yes
|
||||
pwm min/off yes yes
|
||||
fan3 opt yes opt yes
|
||||
pwm3 opt yes opt yes
|
||||
fan4 opt opt
|
||||
fan5 opt opt
|
||||
pwm5 opt opt
|
||||
fan6 opt opt
|
||||
pwm6 opt opt
|
||||
|
||||
@@ -7,6 +7,11 @@ Supported chips:
|
||||
Addresses scanned: I2C 0x4c
|
||||
Datasheet: Publicly available at the National Semiconductor website
|
||||
http://www.national.com/pf/LM/LM63.html
|
||||
* National Semiconductor LM64
|
||||
Prefix: 'lm64'
|
||||
Addresses scanned: I2C 0x18 and 0x4e
|
||||
Datasheet: Publicly available at the National Semiconductor website
|
||||
http://www.national.com/pf/LM/LM64.html
|
||||
|
||||
Author: Jean Delvare <khali@linux-fr.org>
|
||||
|
||||
@@ -55,3 +60,5 @@ The lm63 driver will not update its values more frequently than every
|
||||
second; reading them more often will do no harm, but will return 'old'
|
||||
values.
|
||||
|
||||
The LM64 is effectively an LM63 with GPIO lines. The driver does not
|
||||
support these GPIO lines at present.
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user